#snappy 2015-06-01
<miken> I've just pulled the snappy-examples and built the hello-world, but get a bunch of errors and warnings about files which don't exist: http://paste.ubuntu.com/11488439/ Is that expected, or related to my env?
<miken> (it does build the snap, but unsure why I see those errors/warnings)
<dholbach> good morning
<fgimenez> hi mvo, i'm trying the examples at https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-examples
<mvo> hey fgimenez, good morning
<fgimenez> mvo, morning :)
<fgimenez> mvo, on rolling/edge i'm getting the same aa_change_on_exec error you just reported for every snap
<mvo> fgimenez: yeah, please use 15.04/edge for now, the rolling images are literally only ~30min old :) I enabled wily this morning on them and this was the first bug I noticed
<mvo> fgimenez: I have not investigated further but it appears the apparmor profiles are not created
<fgimenez> mvo, ok thx :) on 15.04/stable i'm getting this http://paste.ubuntu.com/11491522/ when trying to use the config hook, have you seen that before?
<fgimenez> mvo, in the config-example snap
<fgimenez> mvo, didn't try 15.04/edge though, doing it now
<mvo> fgimenez: does the directory /var/lib/apps/config-example/1.0.6  exist?
<mvo> fgimenez: it does not ring a bell, I will have to install/test in a VM to debug further
<fgimenez> mvo, no, the one that exists includes the origin /var/lib/apps/config-example.sideload/1.0.6
<dholbach> mvo, ogra_, asac: http://ubucon.de/2015 :)
<mvo> woah, berlin
<dholbach> the cfp has started and they'd be happy if we could talk about all the new stuff we're doing and maybe do a workshop or two
<mvo> fgimenez: aha, thanks. thats the bug then, the .sideload is not taken into account :/
<mvo> fgimenez: would you mind to file a short bug (this irc log is enough) so that its not forgoten?
<mvo> fgimenez: should be easy to fix :)
<fgimenez> mvo, of course thx :)
<elopio> good morning.
<davidcalle> Morning all
<beowulf> morning
<D_Cent> hi - i have trouble connecting to wi-fi with snappy ubuntu on a raspi2. i followed the wifi tutorial and installed the wireless-tools, etc. but if i connect the wifi dongle via usb, dmesg only shows that a new device was connected without loading any drivers or firmware. the interface wlan0 or similar also doesn't exist. how can i make it work? i had it running previously on an older image, so it should be working
<JamesTait> Good morning all; happy Monday, and happy Say Something Nice Day! ð
<ogra_> mvo, beuno, hulp ! ... can one of you let chatroom through ? seems the review tools seem to be messed up ("ports is pbsolete in package.yaml")
<ogra_> *obsolete
<beowulf> ogra_: do you need this asap?
<ogra_> beowulf, mectors does i think ... i'm just trying an upload with changed ports directive though
<ogra_> mvo, could you take a look at https://myapps.developer.ubuntu.com/dev/click-apps/1526/ ?
<ogra_> i dont get why it spits out the two warnings (my snap overview page tells me 0.1-8 is published btw ... only the details page tells me it isnt)
<zyga> can I freely change the hostname of a snappy core system?
<beuno> om26er, on it
<beuno> er
<beuno> ogra, on it
<beuno> (who is not in the channel :))
<mvo> ogra_: hi, you can ignore those warnings for now, we need to stop generating those .snappy-systemd files, they are no longer needed
<beuno> ogra_, I approved it
<beuno> the fix is on the store side
<beuno> I have it pending
<ogra_> beuno, ok, thanks ... if now the snap would actually work :/
<ogra_> beuno, btw, where do i file store bugs ?
<beuno> ogra_, https://bugs.launchpad.net/software-center-agent/
 * ogra_ has 5 pairs of identical mails for the last uploads ... no mention which version which mail belongs to 
<ogra_> and my front apps page said the whoile time that 0.1-8 was accepted
 * beuno nods
<ogra_> now why the heck does the chatroom not work anymore :/
<sergiusens> ogra_: maybe seccomp
<ogra_> sergiusens, hmm, i dont see any special messages about syscalls
<ogra_> what i see is:
<ogra_> Jun  1 12:23:01 localhost kernel: [ 2188.201850] audit: type=1400 audit(1433161381.662:146): apparmor="DENIED" operation="open" profile="chatroom.sideload_chatroom_0.1-8" name="/" pid=2356 comm="nodejs" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<ogra_> but that has always been there
 * ogra_ has an old install around that works fine on an old snappy 
<sergiusens> ogra_: why would you want to read / anyways ;-)
<ogra_> node does for whatever reason
<sergiusens> ogra_: amd64 or armhf, I can try and install to see
<ogra_> but that never did any harm
<ogra_> this is currently amd64
<ogra_> in kvm
<Chipaca> mvo: any luck reproducing the issue wrt install not working?
<ogra_> my RPi is using a messed up image because i try to fix it :P
 * ogra_ tries an older node-snapper tarball 
<mvo> Chipaca: no, but I didn't try further, sorry, I will try again in a little bit
<sergiusens> ogra_: the one on the store works fine on 1.8
<sergiusens> ogra_: err
<Chipaca> sergiusens: does 'snappy install' work for you in a vm?
<sergiusens> ogra_: the one on the store, 1.8, works fine on bbb
<ogra_> ARGH !!!
<ogra_> sergiusens, because i'm the super idiot today
 * ogra_ tested with firefox :P
<sergiusens> ogra_: no binary for amd64?
<ogra_> (only works with chromium)
<ogra_> sure, it is multi arch
<sergiusens> ogra_: ah, I tried on chrome fwiw
<ogra_> yeah, man, i wasted 2h on that :/
 * ogra_ adds that info to readme.md for next time :P
 * ogra_ takes a break, phew ... 
 * Chipaca realises he hasn't updated in ages
<rsalveti> hm, our builders are in a funny state
<ogra_> rsalveti, which ones ? images ?
<rsalveti> normal lp builders
<rsalveti> some are busy with the haskell uploads
<rsalveti> but at our ppa all I get is 'start on'
<rsalveti> no estimation at all
<ogra_> hmm
<rsalveti> like https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/7492026
<rsalveti> mvo: hm, ubuntu-snappy is also ftbfs on i386 for vivid
<rsalveti> https://launchpadlibrarian.net/207810741/buildlog_ubuntu-vivid-i386.ubuntu-snappy_1.0.1-1%2B443~ubuntu15.04.1_BUILDING.txt.gz
<ogra_> yeah, i just saw the mail
<mvo> rsalveti: I noticed but couldn't make sense of the failure yet
<ogra_> rsalveti, for the hanging build we should poke cjwatson i think
<ogra_> oh, thats a different error ...
 * ogra_ had some with dependency issues on the weekend
<rsalveti> ogra_: yeah, let's wait a bit more and ping him if still stuck
<ogra_> yup
<rsalveti> yeah, why TestUpdateTimestamp would fail
<rsalveti> wonder if a rebuild will make any difference
<ogra_> 2015-05-30 02:46:51 ERROR snappy logger.go:199 hello-app.potato failed to install: a package by that name is already installed
<ogra_> what about that one ?
<rsalveti> wonder if that is testing the error itself
<ogra_> does it re-run the test in a loop or some such ?
<rsalveti> since the test passed
<ogra_> ah
<rsalveti> just a guess, didn't yet see the code :-)
<rsalveti> let me open a bug for this guy
 * ogra_ sighs ... i upgraded my laptop to vivid on the weekend ... got close to unusable now :(((
<ogra_> constantly to hot (80-90Â°C)
<rsalveti> https://bugs.launchpad.net/snappy/+bug/1460650
<ubottu> Ubuntu bug 1460650 in Snappy "(15.04) Rev 443 FTBFS on i386" [Undecided,New]
<rsalveti> ogra_: any process in particular eating your cpu?
<rsalveti> maybe new browsers
<ogra_> no, not at all
<rsalveti> vivid is mostly fine for me
<ogra_> but starting chromium with no page open bumps the load to 12.00 ... while chromium only takes ~20% of one of the cpu cores (the rest is idle)
<ogra_> the frequesncy scaling seems pretty messed up
<mterry> mvo, you should open up ownership of lp.net/ubuntu-core-launcher
<mterry> Wanted to configure its bug tracker to show its bugs (right now I can't see bugs assigned to it because it's not set up)
<sergiusens> nessita: what's the difference between price and prices, if the answer is, 'price' is legacy it's a good answer already :-)
<Chipaca> so
<Chipaca> on my system
<sergiusens> mterry: I just ubuntu bug'ed it
<Chipaca> snappy is bailing because it can't read /etc/localtime?
<Chipaca> ah, no, it's before that
<Chipaca> rats
<nessita> sergiusens, correct! (price is legacy and is the price for the default currency(
 * Chipaca carries on
<nessita> __
<nessita> ))
<mterry> sergiusens, you did...?
<rsalveti> mvo: mterry: just put ubuntu-core-launcher under https://launchpad.net/~snappy-dev
<mvo> rsalveti: excellent, thanks
<Chipaca> i don't understand this failure :(
<ogra_> BAH ... i seem to have half a mobile desktop installed ... no wonder that laptop misbehaves !
<rsalveti> mvo: oh, sorry, I wanted to say that you could put it under ~snappy-dev :-)
<rsalveti> only you can change it
<sergiusens> nessita: I did.... nothing?
<mvo> rsalveti: ups, sure
<sergiusens> Chipaca: what's the issue?
<sergiusens> Chipaca: btw, can you review my u-d-f change?
<Chipaca> sergiusens: snappy internal unpack dies with "operation not supported"
<Chipaca> and the strace shows no syscall failure
<sergiusens> Chipaca: amd64 or bbb?
<Chipaca> sergiusens: mad64
<mvo> rsalveti: updated, the project is now owned by ~snappy-dev
<nessita> sergiusens, you meant mterry?
<rsalveti> mvo: cool, thanks (mterry ^)
<sergiusens> nessita: I did!
<mterry> mvo, thanks!  :)
<sergiusens> mterry: ubuntu-bug ubuntu-core-launcher
<rsalveti> but that will use the package bug
<sergiusens> rsalveti: yes
<Chipaca> the setuid/setgid fails
<Chipaca> the setgid, in particular
<Chipaca> can i say WAT?
<mvo> Chipaca: uh, hope its not something silly as setuid and then setgid :/ in this particular revision
<mvo> (i.e. order wrog)
<Chipaca> no, it does setgid and then setuid
<mvo> wrong even
<mvo> ok
<Chipaca> and the setgid fails
<Chipaca> this is beyond weird, because the snappy we ship works
<mterry> mvo, I also see that someone subscribed snappy-dev to snappy bugs.  Maybe snapcraft and ubuntu-core-launcher should get the same treatment?
<sergiusens> Chipaca: hmm, I face this problem when locally building snappy (I think)
<rsalveti> mterry: I did that, yup, makes sense
<mterry> rsalveti, thanks!
 * Chipaca files bug #1460658
<ubottu> bug 1460658 in Snappy "errors returned by syscall are not user-friendly, should not be shipped raw to the user" [Undecided,New] https://launchpad.net/bugs/1460658
<Chipaca> sergiusens: and how did you fix it?
<sergiusens> Chipaca: I haven't, sorry
 * Chipaca -> school run
<sergiusens> nessita: can I use the 'id' for a package to get results for it?
<sergiusens> nessita: as in using 2277 (id) instead of https://search.apps.ubuntu.com/api/v1/package/beagleblack
<nessita> sergiusens, nopes, ID is retured by mistake,never rely on that
<mvo> jdstrand: do you know why livecd-rootfs uses the "-M /var/cache/apparmor/.features" flag in ubuntu-touch? this file is not available in our chroot it seems
<sergiusens> nessita: so the resource name is always the package_name.origin or alias, correct?
<jdstrand> mvo: what is -M an argument to?
<mvo> jdstrand: apparmor_parser -M (--features-file) I think
<mvo> jdstrand: I'm not sure why its there for touch when they pre-build the /etc/apparmor.d/cache
<jdstrand> ah, that is not in the manpage it seems
<mvo> yes, I only found it with apparmor_parser -h and have no idea what its doing
<jdstrand> mvo: iirc, if you specify a different --cache-loc (-L), then you need to have a .features file in it
<mvo> ok
<jdstrand> since there is /etc/apparmor.d/cache for system and /var/cache/apparmor for apps, we have a .features file in both
<ogra_> echo "I: precompiling click apparmor policies"
<ogra_> /sbin/apparmor_parser -M ${FEATURES} -Q --write-cache --cache-loc=/var/cache/apparmor/ `find /var/lib/apparmor/profiles/ -maxdepth 1 -type f -not -path '*/\.*'`
<ogra_> (thats from the code)
<ogra_> looking in the last image build log it seems to run fine without complaints
<ogra_> (touoch that is)
<jdstrand> perhaps it is putting a .features file in place so that the compiler will use it instead of querying the kernel?
<ogra_> https://launchpadlibrarian.net/207811375/buildlog_ubuntu_wily_armhf_ubuntu-touch_BUILDING.txt.gz
<ogra_> i wouldnt know what would put that file there
<jdstrand> I think rsalveti and/or jjohansen would know
<jdstrand> I know that a .features file is put in place on the running system in each cache directory
<jdstrand> the running non-livecd system that is
<mterry> tedg, we should try to define a minimal set of snapcraft bits that we think we can move forward with this week
<ogra_> jdstrand, what puts it there ? the upstart job ?
<jdstrand> and I know you can specify a different features file to adjust cache output
<jdstrand> so you could compile caches for another kernel
<ogra_> there is definitely no code in livecd-rootfs putting that file in place
<ogra_> and i doubt it actually exists in the chroot after bootstrapping
<nessita> sergiusens, yes
<jdstrand> I'm not sure. I think the parser might
<tedg> mterry, Yes, I haven't looked at the current code. I would like to get some stuff starting to work-ish
<tedg> mterry, I think we can do that even if all the spec parts aren't perfected.
<jdstrand> yes
<jdstrand> If cache/.features is missing, create it if --write-cache
<mterry> tedg, current code is an empty branch
<jdstrand> I'm still going to defer to jjohansen
<ogra_> that makes it at least bugfree
<tedg> mterry, tabula rasa
<ogra_> jdstrand, well, it doesnt seem to do any harm
<ogra_> (not sure what mvo's prob is with it)
<Chipaca> sergiusens: mvo: it fails when compiled with golang 1.4 (!)
<Chipaca> mvo: does this match the failures you were seeing in arm64?
<Chipaca> or gogcc
<Chipaca> maybe i just need to rebuild my go 1.4
<Chipaca> or switch to wily already
<mvo> Chipaca: ohhhh, I have not tried that
<mvo> Chipaca: in a meeting right now :/ so can't help just yet
<Chipaca> mvo: is this the "15.04.1 release" meeting?
<mvo> Chipaca: yes, I almost missed it fighting with gccgo
<sergiusens> Chipaca: right, I'm using 1.4 here (locally installed)
<Chipaca> sergiusens: vivid's 1.3 worked
<Chipaca> sergiusens: locally installed 1.3 also works
<Chipaca> I guess I won't be running snappy on my http://wiki.openwrt.org/toh/kingston/mlw221 any time soon
<mvo> 16mb flash is going to be hard
<ogra_> pfft
<ogra_> just write a proper compression that allows pushing 4G into 16M ...
<mvo> 4gb of /dev/zero surely
<Chipaca> mvo: so, the manifest branch is the one causing the apparmor failures
<mvo> Chipaca: the reduce-manifest one?
<Chipaca> mvo: yaarp
<mvo> ok
<elopio> fgimenez: tomorrow I can escape at 11:30, london time.
<Chipaca> mvo: still trying to understand why, but i'll get there :)
<tedg> Where are the package lists for the default core image?
<tedg> seed I guess?
<tedg> Is it this? https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-core.wily
<fgimenez> elopio, fine, that is 10:30 my time. i'm already taking a look at the doc
<fgimenez> elopio, ping me when you are ready
<jdstrand> mvo, Chipaca: if I were to hazard a guess, I would think it has something to do with the 'namespace' changes in click.go
<Chipaca> jdstrand: nope :)
<jdstrand> oh, what is it?
<elopio> fgimenez: great, thanks.
<Chipaca> jdstrand: in revision 465 i switched some bits to use the yaml manifest instead of the click manifest
<Chipaca> jdstrand: without noticing that things that appeared equal were not so
<Chipaca> in my defence, in build we assign the click manifest's Hooks to be the yaml's Integration
<Chipaca> but before doing that we do add some things to Integration that are not in the package.yaml
<Chipaca> so, I *think* what we want is to grow Integration in the same way every time we load it
<Chipaca> I need to check though :)
<jdstrand> mvo: fyi, and this doesn't have anything to do with snappy internals, I have adjust the review tools to error if a snap uses 'integration' in its yaml
<jdstrand> adjusted*
<jdstrand> sergiusens: hey, I'm reflashing my bbb, is udf 0.21-1+174~ubuntu15.04.1 ok to use?
<sergiusens> jdstrand: let me check
<sergiusens> jdstrand: yes
<tedg> So, I thought I'd go to the docs, didn't find my answer there either :-)
<tedg> Where is the script/tool/etc that builds the core snap?
<jdstrand> sergiusens: thanks
<jdstrand> df
<tedg> 1243 GB
<ogra_> 640k are enough for everyone !
<jdstrand> heh
 * ogra_ upgrades ubuntu-device-flash
 * jdstrand hrms
<jdstrand> rsalveti, mvo: hello-dbus-app is broken on edge r72. is this the candidate for promotion?
<jdstrand> rsalveti, mvo: (on bbb)
<damjan> what would it take to port UbuntuCore to the Kindle Paperwhite
<ogra_> damjan, depends what bootloader it uses ... if the specs would work etc
<damjan> hardware specs?
<ogra_> yes
<ogra_> you need 4G diskspace and the ability to partition it the right way... we currently only support u-boot on arm as bootloader ...
<damjan> it's an 1Ghz imx 508
<damjan> 256MB ram
<damjan> there's the 2GB and 4GB flash versions
<ogra_> that might eb a little low on ram ... but givenn that there is no UI support in any way yet, perhaps not
<ogra_> (i guess for plain cmdline 256M would work)
<damjan> afaik it's u-boot
<damjan> why does it matter btw?
<ogra_> because the automation for rollbacks lives in the bootloader
<ogra_> (if you upgrade and something goes wrong the system automatically rolls back to the last working setup)
<damjan> it's uboot
<jdstrand> rsalveti, mvo: fyi, there is a trello card to add hello-dbus-* to the self tests. if is in 'snappy core stackholders backlog' 'incoming propposals'. I just now added instructions on what to do (should be a very simple test)
<jdstrand> rsalveti, mvo: s/if is/it is/
<rroy> Trying to do basic install of docker app on snappy.    Installation completes w/o error however a simple `docker ps` fails:
<rroy> ubuntu@localhost:~$ sudo snappy install docker Installing docker Starting download of docker.canonical 8.36 MB / 8.36 MB [======================================] 100.00 % 483.05 KB/s  Done Name        Date       Version   Developer  ubuntu-core 2015-04-10 146                  docker      2015-06-01 1.6.1.002            ubuntu@localhost:~$ docker ps aa-exec: ERROR: profile 'docker_docker_1.6.1.002' does not exist  ubuntu@localhost:~$
<rroy> Ugh ... sorry about the formatting.
<rroy> As you can see the complaint is regarding a missing "profile" file.    I'm guessing I can get away w/ an empty profile file but ... what is the file name/location?
<kgunn> seb128: you around ?
<seb128> kgunn, yes
<rsalveti> jdstrand: ogra_: we only have the features file for touch
<rsalveti> ubuntu-touch/includes.chroot/var/cache/apparmor/.features
<rsalveti> so I'd guess the pre-cached apparmor stuff is kind of useless for core atm
<rsalveti> jdstrand: broken on 15.04/edge?
<jjohansen> rsalveti: that does sound broken
<jdstrand> rsalveti: yes, r72
<jdstrand> rsalveti: I think it is surrounding the unshare in the launcher because I am getting a disconnected path apparmor denial
<rsalveti> jdstrand: and thanks for updating the card, will move it around later today
<jdstrand> but it is weird, because it is on run/
<rsalveti> but iirc it was working a few days ago
<jdstrand> rsalveti: cool, thanks
<jdstrand> I wonder what landed
<rsalveti> now don't remember if that was indeed stable or edge
<jdstrand> do we have a clear way to see what has changed?
<rsalveti> not an easy way, no, ogra_ was working on that
<rsalveti> we only got the manifest, but from a few images
<jdstrand> I just reflashed my bbb today with edge and got this denial: audit(1433179950.388:19): apparmor="DENIED" operation="connect" info="Failed name lookup - disconnected path" error=-13 profile="hello-dbus-app.canonical_client_1.0.1" name="run/dbus/system_bus_socket" pid=1215 comm="dbus_message.ar" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=0
<jdstrand> notice 'name=run/...'
<jdstrand> that should have a '/' in front of it
<rsalveti> indeed
<jdstrand> so, we knew we would need to adjust the apparmor template to use 'attach_disconnected'
<jdstrand> and in fect, that is done in wily
<jdstrand> fact*
<jdstrand> but, I wasn't expecting this on 15.04, so I'm curious about the changes that went in
<jdstrand> rsalveti: so, the launcher hasn't changed in vivid...
<jdstrand> rsalveti: ah, 1.0.2~ppa1 is on the image
<rsalveti> right
<jdstrand> rsalveti: 'Set up a private mount namespace for /tmp'
<jdstrand> so, this means we need a policy update
<rsalveti> we use vivid + https://launchpad.net/~snappy-dev/+archive/ubuntu/image
<jdstrand> yep, that is where I'm looking
 * jdstrand sees the old unused libseccomp and deletes it
<rsalveti> also noticed we're over the repo size limit in there
<rsalveti> maybe because of gcc
<jdstrand> oh yeah
<jdstrand> rsalveti: so, at this point there is a choice, pull the launcher or have me do a policy update. I'm fine with doing an ubuntu-core-security update-- I can do it tomorrow. this was the other part of the sru I was talking about
<jdstrand> rsalveti: but if we go that route, you should block the promotion on that
<rsalveti> yeah
<rsalveti> jdstrand: that same version is also available in wily (core-launcher)
<rsalveti> so I guess we'd need a policy update for both
<jdstrand> rsalveti: wily has 1.0.2
<jdstrand> wily already has the policy update
<rsalveti> got it
<jdstrand> 15.10.1 has: "add attach_disconnected for default policy in preparation of new /tmp
<jdstrand>       handling"
<rsalveti> guess it'd be fine to get this in the ppa and then work on getting the official src in place
<jdstrand> that is what I was thinking
<rsalveti> cool
<rsalveti> jdstrand: do we have a bug for this already?
<rsalveti> just so I can put at the milestone
<jdstrand> no
<jdstrand> I'll file one
<rsalveti> awesome, thanks
<jdstrand> rsalveti: bug 1460810
<ubottu> bug 1460810 in Snappy "1.0.2 launcher needs corresponding apparmor policy update" [Undecided,New] https://launchpad.net/bugs/1460810
<rsalveti> jdstrand: thanks
<jdstrand> rsalveti: fyi, ubuntu-core-security - 15.04.12~ppa1 uploaded to the ppa
<rsalveti> jdstrand: awesome, thanks for that
<jdstrand> np
<rsalveti> got the extra ppa space just in time
 * Chipaca looks at sys/unix/syscall_linux_arm64.go
 * Chipaca goes to bed
<nessita> sergiusens, so, I have this item to sync with you, about snappy oauth-signing every single request to the index. Any pointers who should I ping about this?
<Chipaca> nessita: for snappy?
<beowulf> Chipaca: is your snap removed from the store?
<Chipaca> beowulf: unpublished
<Chipaca> beowulf: should i republish?
<Chipaca> people seemed to not like it being there
<beowulf> Chipaca: no, it exposed some wonderful errors :)
<Chipaca> hee hee :)
<beowulf> Chipaca: so i was using it in webdm, then it was unpublished, then i tried to uninstall...
<Chipaca> beowulf: webdm doesn't like things disappearing from the store?
<beowulf> Chipaca: no sir
<Chipaca> *shock*
<beowulf> Chipaca: i'm wondering if the store should dissappear metadata, or should webdm handle it, or should i go to bed
<beowulf> i think the latter
<Chipaca> jdstrand: is https://01.org/intel-kgt relevant to us?
<Chipaca> beowulf: the magic 8-ball says "go to bed already"
<sergiusens> Chipaca: beowulf this is a similar error to the offline case; I need to fix it
<sergiusens> nessita: how soon is that timeline? I think you want to sync with beuno first on the whole concept for ssl/tls
#snappy 2015-06-02
<beuno> sergiusens, soon, but orthogonal to ssl/tls
<dstokes> is there any way to install packages from file, without having to upload to canonical?
<miken> dstokes: yes, you can side-load... let me find the relevant docs
<tedg> dstokes, Yes, you just need to set --allow-unauthenticated to avoid it checking for the store key.
<dstokes> tedg: what's the command / args for installing? cant find anything in the docs
<miken> snappy-remote --url=ssh://you@device install ./hello-world_1.0.5_all.snap
<miken> tedg: Is that correct? ^^ That's what I used, from
<miken> https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/
<tedg> I haven't used remote, but on the image it's just "snappy install --allow-unauthenticated foo.snap"
<tedg> Well, sudo
<dstokes> oic
<dholbach> good morning
<miken> Morning dholbach
<fgimenez> good morning
<dholbach> hi miken
<dholbach> mvo_, sergiusens, rsalveti: do you think anyone of you can reply to seb128's mail on snappy-devel? he's still looking for a way to boot
<seb128> dholbach, thanks! yeah, still failing to boot snappy on that uefi machine
<seb128> which blocks me for working on the new unity8 desktop snappy iso
<mvo_> seb128: I'm not sure what the status here is, we have wily images since yesterday that might help, but in any case I create a card and try to find if I have a machien with uefi bios
<seb128> mvo_, hey! where can I get the wily image? I'm happy to try that
<mvo_> seb128: sudo ubuntu-device-flash core rolling --channel edge --output wily.img
<mvo_> seb128: that should be dd-able
<mvo_> seb128: and I added a trello card
<seb128> mvo_, ok, great, I'm going to give that a try in a bit and let you know how that works
<seb128> thanks!
<mvo_> yw
<zyga> good morning
<beowulf> morning
<elopio> good morning.
<JamesTait> Good morning all; happy Leave the Office Earlier Day! ð
<ogra_> lol
<tbr> good moaning
<dholbach> ogra_, in the node-snapper example it looks like the tool gets stuck in some point during the installation
 * tbr starts to write a brief blog post on how to make snappy work on real x86 embedded hardware
<dholbach> ogra_, http://pastebin.ubuntu.com/11516722/
<ogra_> dholbach, it compiles
<dholbach> then it's compiling for a very long time :)
<ogra_> therr should be a spinner in the bottom left though
<ogra_> tbr, wheee  !
<dholbach> no spinner here
<ogra_> then kill it and start over
<dholbach> http://pastebin.ubuntu.com/11516757/ - I guess something is happening
<ogra_> it uses qemu-arm-static, thats sometimes a little rough
<ogra_> whats your host release ?
<dholbach> 15.04
<ogra_> (qemu-arm-static stability sadly varies ... it is rock solid in trusty, i saw issues sometimes in utopic and havent built under vivid yet)
<ogra_> so if you dont see a spinner, kill it and start over i'd say
<ogra_> (we should note that in the doc)
<tbr> ogra_: luckily it's fairly simple. install version >x of toos, build image, boot image manually (or by adding startup.nsh), use efibootmgr to set boot order properly (and check on every boot)
<dholbach> ogra_, now it succeeds :-/
<ogra_> dholbach, right ...
<dholbach> Chipaca, mvo_, do you have an idea what's happening here? http://pastebin.ubuntu.com/11516932/
<dholbach> ogra_, https://code.launchpad.net/~dholbach/node-snapper/not-world-writable/+merge/260806
<dholbach> Chipaca, mvo_: http://pastebin.ubuntu.com/11516978/
<Chipaca> yep
<ogra_> dholbach, cool., thanks ... i also noticed yesterday that snappy nor kills the symlinks in $arch/bin/ ... need to find a fix for that one (start-service.sh points to $arch/bin/node which is a symlink to $arch/bin/nodejs)
<ogra_> s/nor/now/
<Chipaca> dholbach: remember how we don't support things that are apps becoming frameworks, or viceversa?
<Chipaca> dholbach: bottom line, remove the old webdm and install the new one, until we fix that
<dholbach> ok
<ogra_> for me "snappy update webdm" (on the 15.04 release kvm image) just works
<dholbach> I can't quite remember which image it was I used back then
<dholbach> "Tags are free form, but some can gain special use, such as an external/ui one which would be picked up by the webdm and used to open the application through the web."
<dholbach> ^ is the above true right now?
<beowulf> dholbach: what's the source?
<beowulf> dholbach: as of this minute, webdm doesn't provide links to external ui, but i don't know what tags are
<beowulf> s/but/and
<dholbach> beowulf, that's in https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/
<dholbach> (just search for webdm)
<beowulf> dholbach: ah right, so the 'ui' tag isn't working right now
<dholbach> ok
<beowulf> dholbach: it will be by end of today, and then it'll be available on the next version of webdm
<dholbach> <3
<elopio> fgimenez: ping, I can start the exploratory now. Are you ready?
<beowulf> dholbach: that's much easier to read now :)
<beowulf> dholbach: do you know why the icon section says "only SVG"?
<dholbach> no, I don't
<dholbach> davidcalle, ^ do you know why the icon section on https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/ says "only SVG"?
<beowulf> the store converts SVG to PNG, and I don't think we should allow SVG
<fgimenez> elopio, yup, ready!
<elopio> fgimenez: do you use firefox? want to try meeting using hello?
<dholbach> ogra_, can you pull from lp:~dholbach/+junk/chatroom?
<dholbach> (can't create an MP for a +junk branch)
<davidcalle> dholbach, probably because the branch doc (eg. https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/meta.md) specify the svg format for icons (line25)
<fgimenez> elopio, not tried yet, let me set it up
<dholbach> davidcalle, ah ok... sorry - it says that in the 15.04 branch as well, just not as "only svg" which I couldn't find in there
<dholbach> beowulf, looks like it's currently spec'ed that way, cf https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/meta.md and https://bazaar.launchpad.net/~snappy-dev/snappy/15.04/view/head:/docs/meta.md
<elopio> getting some water here and finding a good place. Give me a couple of minutes.
<davidcalle> dholbach, beowulf, the doc itself is not from snappy trunk, it's one of the first doc uploaded with the initial snappy announcement, afair it has been reviewed to be kind-of up-to-date with the latest release
<davidcalle> I don't know if snappy actually cares about the format, though :)
<davidcalle> beowulf, do you know what the plan is for high-res screens and the store? Do we need (or will we need) several png sizes?
<elopio> fgimenez: https://hello.firefox.com/zAxKYb3AqB8
<fgimenez> elopio, ok give me a second..
<beowulf> davidcalle: i don't know what the plan is, but the current icon size is 256x256, that's quite large already
<elopio> fgimenez: http://pad.ubuntu.com/testing-snappy
<ogra_> dholbach, oh, didnt i push that yet ? (i have the same on disk and in the store) ....
<davidcalle> beowulf, thanks, can confirm, just tried at 3200x1800, various scalings, looking sharp :)
<elopio> fgimenez and I will be doing exploratory testing on snappy here, in case somebody wants to join: https://hello.firefox.com/zAxKYb3AqB8
<dholbach> ogra_, apparently not :)
<Chipaca> mvo_: you around?
<mvo_> Chipaca: yes
<Chipaca> mvo_: hiya!
<mvo_> Chipaca: good morning!
<Chipaca> mvo_: what happens if a service has no description?
<Chipaca> currently we're using the second line of the readme for that
<mvo_> Chipaca: a good question - using that is probably not a great idea :/
<Chipaca> but we're only storing it in the click manifest (and in the systemd service file)
<Chipaca> until i got to that, i had high hopes of making things work without reverting the "limit click manifest use" branch
<mvo_> Chipaca: maybe we should just generate something like "service for {pkgname} - {servicename}" or something
<Chipaca> mvo_: "service {servicename} of {qualified name}"?
<mvo_> Chipaca: yeah, much better
<ogra_> dholbach, pushed this and other changes
<Chipaca> k
<dholbach> ogra_, and the node-snapper MP?
<ogra_> dholbach, no, chatroom
<Chipaca> mvo_: not qualified name; we don't know the origin in build :)
<mvo_> Chipaca: my brain is still on this gccgo senfile failure, but I think I nailed it now, I feel a bit silly for not spotting the real problem earlier
<Chipaca> mvo_: that's good, right?
<mvo_> Chipaca: indeed you are right
<mvo_> Chipaca: its good that its fixed, not good that I feel silly, but I guess I should relax and celebrate the fix instead :)
<ogra_> dholbach, doing node-snapper now ... i'm just totally distracted by http://people.canonical.com/~alan/ogra_loading.gif
<Chipaca> mvo_: feeling silly is good
<Chipaca> mvo_: because it only happens *after* the "aha"
<mvo_> lol
<mvo_> very true
<dholbach> ogra_, yes, I can imagine
<elopio> fgimenez: still 10 minutes to download, it doesn't go down :(
<dholbach> ogra_, take your time :)
<elopio> and makes the video choppy. I'll go and get more water and the charger...
<fgimenez> elopio, np, the video is frozen for me.. ping me when ready
<ogra_> dholbach, merged and pushed
<dholbach> ogra_, cool, I'll do another test run now
<ogra_> wait one sec, i have another change
 * dholbach waits
<ogra_> dholbach, done
<elopio> fgimenez: 2 mins.
<ogra_> mvo_, http://bazaar.launchpad.net/~ogra/node-snapper/trunk/revision/7 ... why do my symlinks vanish when packaging the snap ? is that intentional ?
<elopio> fgimenez: I can see you, but you can't hear me.
<elopio> the download is ready.
<elopio> I'll rejoin...
<fgimenez> elopio, nope, and you are frozen
<mvo_> ogra_: I suspect need a update version of snappy, symlinks got fixed by Chipaca some days ago
 * ogra_ guesses that kind of goes against de-duplication :)
<ogra_> ah, cool
<mvo_> it was a silly bug
 * mvo_ notices that its silly to use silly all the time
 * ogra_ will revert that change once that migrated everywhere then ...
<elopio> fgimenez: can you kick me or something?
<elopio> It says I can't rejoin.
<Chipaca> mvo_: giving up, reverting the manifest thing
<fgimenez> elopio, i'm alone in the conversation
<mvo_> Chipaca: meh, let me know if I can help in any way :(
<Chipaca> unless...
<elopio> fgimenez: crazy shit. Now I'm alone in the conversation :)
<elopio> fgimenez: lets go to hangouts, this doesn't seem ready: https://plus.google.com/hangouts/_/grwijm4jm7pbk5vu6fg5dgiknaa?hl=es
<mvo_> Chipaca: btw, if we ever decide to backport the cp_linux thing to 15.04 you will need to remind me that we need to port the upstream gccgo fix as well
<Chipaca> mvo_: or, or, we could make the default non-cp_linux implementation be the fallback
<Chipaca> mvo_: but then we'd never find these bugs :)
<Chipaca> unless we printed a big fat warning before calling the fallback
<mvo_> :
<mvo_> :)
<dholbach> ogra_, looks like chatroom doesn't start up after installation - do you know how I can debug this?
<ogra_> dholbach, syslog ... and you can hack the start script "export NODE_DEBUG=*"
<elopio> rsalveti: why is the image in http://cdimage.ubuntu.com/ubuntu-snappy/15.04/edge/ older than the one you get with ubuntu-device-flash?
<ogra_> dholbach,  did you use the start script unmodified ?
<ogra_> dholbach, it might point to node ... if you didnt re-run node-snapper with the last change thats a dead symlink
<ogra_> point the script to nodejs instead
<dholbach> ogra_, let me check
<dholbach> ogra_, still no dice
<dholbach> ogra_, how can I emulate the startup of the service?
<ogra_> dholbach, show me your start-service.sh
<dholbach> ./chatroom.sideload/current/start-service.sh: 27: ./chatroom.sideload/current/start-service.sh: /amd64/bin/nodejs: not found
<ogra_> uh
<dholbach> ogra_, could it be that "./amd64.." would help there?
<ogra_> it uses $SNAPP_APP_PATH/$ARCH/bin/node $MY_EXECUTABLE
<ogra_> try dropping a P there
<ogra_> seems something changed in the ubuntu-core-launcher that doesnt set the variable anymore
<ogra_> (i thought we'd keep that for backwards compatibility ... hmm)
<dholbach> ./amd64/bin/nodejs: error while loading shared libraries: libcares.so.2: cannot open shared object file: No such file or directory
<ogra_> geez
<ogra_> what did you do
<ogra_> you see that in syslog when starting it via systemctl ?
 * ogra_ pushes a change for SNAPP vs SNAP to the branch
<sergiusens> beowulf: dholbach yes, tags are true, if a package uses that, webdm will hint it in the package payload
<dholbach> ogra_, does it work for you?
<dholbach> no... I ran this:
<dholbach> (amd64)ubuntu@localhost:/apps/chatroom.sideload/current$ ./amd64/bin/nodejs current/site/server.js
<Chipaca> mvo_: do we still support setting apparmor in Integration?
<dholbach> not sure if that was the wrong way to do it
<ogra_> dholbach, i uploaded it to the store yesterday, yes
<ogra_> dholbach, the path to the server.js is wrong ... drop the "current/" there
<mvo_> Chipaca: I think we do, we could kill it
<ogra_> dholbach, but you cant just run it withouth the ubuntu-core-launcher environment ... use systemctl and syslog
<mvo_> i think
<Chipaca> mvo_: meh. i've made a note.
<dholbach> ogra_, ok, I'll have another look
<ogra_> dholbach, also, show me your start-service.sh
<dholbach> ogra_, I'll start from scratch - I was just following your instructions
<ogra_> me too yesterday :)
<dholbach> ogra_, it works! :)
<dholbach> shipit!
<ogra_> haha
<ogra_> note it wonly works properly with chromium
 * ogra_ just added that info to readme.md
<Chipaca> mvo_: still needs tests, but http://bazaar.launchpad.net/~chipaca/snappy/mangle/revision/482?start_revid=482 fixes it; could you take a look and see if the approach seems sane to you?
<Chipaca> mvo_: at question is whether i hate clickManifest too much :)
<mvo_> Chipaca: looking
<mvo_> Chipaca: oh, you can kill the createion of .snappy-systemd in handleServices entirely
<mvo_> Chipaca: looks like a good approach, I assume you fix the names ;) ? we should probably do deprecation warnings if we encounter stuff we need to mangle
<Chipaca> mvo_: i can? kill snappy-systemd i mean
<mvo_> Chipaca: yes, that is only used by the snappy-systemd hook which is no longer in use at all
<Chipaca> mvo_: so binaries and services look identical :)
<mvo_> heh :) thats good, right?
<Chipaca> yep
<zyga> hey, is there an api for snappy
<zyga> so that I can get stuff like 'snappy list' programmatically without screen-scraping
<dholbach> ogra_, I guess there's no way around editing start-service.sh as root, right?
<ogra_> dholbach, only by editing it before rolling the snap :)
<dholbach> ogra_, the file is owned by root
<dholbach> before the rolling of the snap, because node-snapper runs as root
<ogra_> ah,. we can change that indeed
<zyga> anyone?
<zyga> (I'm just after a yes / no answer)
<beuno> zyga, yes*
<beuno> * sergiusens can tell you more
<zyga> beuno: thanks!
<zyga> sergiusens: any links on where I can find snappy API?
<zyga> sergiusens: (for apps that want to talk to snappy and get data from it)
<nessita> beuno, o/ so I mentioned to Sergio the goal to have every request to the store being oauth signed, and he replied that we should first decide on the ssl/tls front
<nessita> Chipaca, o/ yes, for snappy
<beuno> nessita, I think he's mixing topics
<ogra_> zyga, there is work for some REST api ... not sure thats snappy itself or a webdm thing
<zyga> ogra_: isn't webdm optional?
<zyga> ogra_: I'm looking for alternative to parsing snappy list output
<ogra_> zyga, it is optional .. for a remote API you need a webserver though ... which webdm conveniently ships
<zyga> ogra_: is app-to-app IPC constrained?
<beuno> zyga, the plan is for snappy to provide a rest api, which everything that wants to display data will use
<zyga> ogra_: can I write an app that talks to webdm and it will not be broken down the line?
<zyga> ok
<ogra_> zyga, ask sergio, he designs that :)
<beuno> webdm, the cli. etc
<zyga> ogra_: will do, thanks!
<zyga> sergiusens: I'll be the inner voice in your head
<zyga> sergiusens: asking you questions ;)
<zyga> ogra_: why is python2.7 on the snappy image btw? is it so that 2.7 webapps can be deployed easily or is there another reason?
<ogra_> zyga, by accident ... cloud-init isnt fully ported yet
<zyga> ogra_: ah, I see
<ogra_> (final target is to get rid of languages )
<zyga> ogra_: and down the line, do you see it becoming a framework of sorts, so that people can do 2.7 webapps?
<ogra_> (in the core)
<zyga> ogra_: or will it be killed
<zyga> ogra_: I see
<zyga> ogra_: so all runtimes (perl, pythons) go away and maybe move to frameworks
<ogra_> i assume it can be a framework ... or you can just bundle it
<zyga> ogra_: are frameworks well defined? is it okay for a framework to ship a language runtime?
<ogra_> i'm not so sure :)
 * ogra_ still hasnt looked at the exact framework definition 
<zyga> ogra_: is that discussion happening somewhere?
<dholbach> ogra_, how do you want to change the permissions?
<zyga> ogra_: who makes the calls?
<ogra_> in hangouts :P
<zyga> ogra_: ok, I'll start showing up in yours
<dholbach> ogra_, or shall I just go and write the docs so people use 'sudo' to edit the file?
<ogra_> dholbach, oh, i see why that happens, because you chaned world writability :)
<ogra_> we could chown the dir to $USER i guess ... shouldnt do harm to the final snap
<ogra_> (for the tarball contents and the start script)
<ogra_> (snappy chowns everything to the clickpkg user at install time)
<dholbach> ogra_, ah yes, that's right :)
<dholbach> ogra_, so maybe just change it to $USER once node-snapper is done?
<ogra_> yeah, for the arch tarballs before they get tarred up and for the three final files
<ogra_> so that the user has all permissionns in case he wants to edit something inside these tarballs manually
<dholbach> ogra_, https://developer.ubuntu.com/en/snappy/tutorials/node-to-snap/ - looking good? :)
<ogra_> dholbach, in a meeting, gimme a bit
<dholbach> ogra_, sure
<dholbach> ogra_, I'll hold off of blogging about it for a bit
<sturmflut2> https://i.imgur.com/rntFSWS.jpg Awww
<beowulf> dholbach: the last paragraph hasn't formatted with a <p>
<ogra_> sturmflut2, thats what you get with the intel snap ?
<ogra_> cute :)
<sturmflut2> ogra_: Yes, a webserver on port 8888 hosting a lot of JavaScript, and I think there's more
<sturmflut2> I have to say it was surprisingly painless to boot the Snappy KVM image and install the package
<dholbach> thanks beowulf - I'm not sure if I fixed the right way now(?)
<ogra_> dholbach, i dont really like the hack in point 6 (where i mv the contents of chatroom/*) ... i wonder if we could make that more elegant
<beowulf> dholbach: yep, fixed now :)
<ogra_> (that was just a quick hack when elopio found an issue with the original howto, i never cleaned that up)
<ogra_> dholbach, but thats only cosmetic, looks great otherwise !
<dholbach> thanks beowulf
<dholbach> ogra_, let me think about it
<ogra_> it would need some serious re-ordering so we branch into package/
<ogra_> not sure thats worth it
<davidcalle> dholbach, do you mind if I make a small layout tweak to your tuto?
<dholbach> davidcalle, I'd be happy if you'd do that :-D
<davidcalle> dholbach, specifically code -> twelve-col
<dholbach> <3
 * dholbach writes a quick blog entry
<jdstrand> Chipaca, mvo_: fyi, I made it so the review tools error when finding integration in the yaml. that will be in the 0.28 version I am preparing
<Chipaca> niiice :)
<jdstrand> so +1 on removing it from snappy
<zyga> sergiusens: what is snapcraft?>
<ogra_> zyga, a magic wand
<ogra_> zyga, you want to interview tedg or mterry about it ;)
<zyga> ogra_: I tried googling for it but the name kind of hits minecraft instead
<tedg> It's a dream :-)
<zyga> what is is, in one line?
<ogra_> zyga, a magic wand
<tedg> zyga, It's the tool we're working on to make building snaps really easy.
<ogra_> (in one line ... no wraps)
<tedg> zyga, Handle things like pulling in a runtime and packaging it along with your app.
<zyga> ah, so ubuntu component store for snappy, kind of?
<tedg> Eh, kinda. More like allowing you to use the component stores you're already happy with. Be it PIP or apt or npm.
<zyga> sergiusens: quick question for the "by design", I get that security is there by design, I don't disupte that, I'm looking for what the recommendation is for us, should we just ignore confinement and run entirely unconfined or should we seek some options to work within the confinement?
<zyga> tedg: is it reasonable to use snapcraft to pull in pulseaudio
<zyga> tedg: and make it really work
<zyga> tedg: (with hardware access and all the permissions)
<zyga> tedg: so that my app can have some sound?
<ogra_> sure
<tedg> zyga, No, pulse should really be a framework. It's something that shares hardware.
<ogra_> no need for snapcraft to do that
<zyga> ok
<ogra_> https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/
<Chipaca> zyga: for a hardware testing tool, i'd expect it to be unconstrained or have a custom apparmor profile
<ogra_> that has some hints about HW access
<tedg> zyga, Frameworks are more about services that multiplex HW.
<zyga> Chipaca, tedg: that both makes sense, thanks
<ogra_> orm for system tests you might actually want unconfined, yeah
<zyga> I have a feeling we should help drive this so that eg. pulse exists as a framework and we and use it for testing, that python exists as a framework and we can use it (or that snapcraft can bundle it)
<ogra_> the latter will be what will happen
<zyga> one other idea I had is to have a flag day and rewrite _everything_ on top of some qt api
<ogra_> (snapcraft bundling stuff for you)
<zyga> but I don't know if that's a good solution even if we did it (does qt really have an API for everything?)
<Chipaca> zyga: just to be sure you understand it, frameworks are for hardware access, not for sharing libraries
<Chipaca> zyga: having a library in a framework will not enable things that depend on that framework to use that library
<zyga> Chipaca: yes, I get that, it's just not clear to me exactly if there will be exactly zero non-hardware frameworks as this seems to be up in the air a little
<zyga> Chipaca: ok
<davidcalle> dholbach, hah, nevermind, this break numbered lists... Â¯\_(ã)_/Â¯
<zyga> Chipaca: is snapcraft something that I can try now?
<mterry> zyga, no
<Chipaca> zyga: snapcraft is in the design phase right now. Or vapourware if you will.
<zyga> I see
<zyga> so while python exists on the image it's not so critical
<zyga> it's more important to understand what's down the line and how the roadmap looks like
<ogra_> zyga, but if you use some mechanism to bundle your stuff, let the two guys know so they can take that into account in snapcraft :)
<zyga> and to know how we plan to fit in
<zyga> mterry, tedg: one mechanism we do use now, is to just have a package in a PPA or in the archive (and use known tooling for building it) and to extract bits and pieces from it (.so files) so that we don't have to worry about cross-compilation or daily builds
<zyga> as there are no "ppas" for clicks or snaps and many people are working on the project we do rely on some kind of automatic build process
<zyga> and limiting that to "run this script and it fetches and repackages stuff from the archive" does simplify it for us
 * dholbach hugs davi
 * dholbach hugs davidcalle
<zyga> obviously we could rewrite that to build our stuff but then it's a bit more complicated (cross compiling) and time consuming
<tedg> zyga, So basically our goal is to make the cross compiling and pulling in dependencies easy. So then you can do that all the time.
<zyga> tedg: how do you plan on achieving that?
 * ogra_ hugs dholbach 
<tedg> zyga, magic wand :-)
<zyga> tedg: and in reality? :-)
<zyga> tedg: one thing I'm interested in is this use case
<zyga> tedg: you pip install somethig
<zyga> tedg: that builds a .so file
<zyga> tedg: how do you make that cross-compilable?
<tedg> zyga, We plan on doing it by you providing us with a yaml file describing what you want and providing plugins that understand those cases and install them into a snap.
<tedg> zyga, We build two of them in and put them in directories appropriate for the architecture they're built for.
<zyga> tedg: hmm?
<zyga> tedg: I mean, pip, do you plan to patch pip and python to make that work?
 * dholbach hugs ogra_ back
<zyga> tedg: I know theory that it can work, I want to understand if you have any concrete plans for specific cases
<zyga> tedg: all python extension build natively so far
<zyga> tedg: and it does seem like patch-the-world problem to me
<tedg> zyga, We have concrete plans to make that work, we started writing code for it yesterday.
<zyga> tedg: without a solution like qemu-arm-static or simiar
<zyga> similar*
<mterry> zyga, we plan to cross compile in chroots like the sdk does yeah
<tedg> zyga, I'm hoping we don't have to patch pip, but if so, we'll work with upstream to make it handle cross-compiling better.
<tedg> Honestly, I think that multi-architecture support is something everyone wants (upstreams too) but no one has the time to work on it. It's a priority for us.
<zyga> mterry, tedg: I'd love to dogfood anything you can share, my use cases are stuff like python3-lxml2
<zyga> tedg: I agree
<zyga> tedg: it's ironic that only debian did it in any sensible capacity
<tedg> zyga, Cool, we'll probably harass you in a couple weeks after we start to get things off the ground. We're working with simpler use cases right now to get the basics together.
<zyga> tedg: gnu hello? :)
<tedg> BSD Hello, we're not handling complex licensing yet ;-)
<zyga> haha
<zyga> tedg: note that an eula is hardly needed for gnu hello
<zyga> tedg: no license needed
<dholbach> ogra_, our names are put next to python tutorial thing - is that on your list of things to do right now?
<ogra_> python tutorial  ? nope
<ogra_> i thought barry did one
<barry> ogra_: hello? :)
<ogra_> i'll have tzo take care for the RPi image for the rest of the week
<dholbach> ogra_, barry: I was looking at barry's blog post, but it looks like asac preferred ricmm's approach (https://code.launchpad.net/~ricmm/+junk/example-python-snap/) and we wouldn't have to require python 3.5
<barry> dholbach: python 3.5 isn't required for my approach, it just enables some fancy debugging and hackery
<barry> has ricmm published any articles or docs on his approach?
<barry> (his is py27 based; i'm firmly py3 :)
<barry> also, mine is more of a framework for providing py3 snaps, rather than just an example of one
<dholbach> ok... I wasn't siding with any solution, just trying to figure out where to go next
<barry> dholbach: sure.  let many flowers bloom :)  happy to help
<asac> dholbach: yes ricmms approach is trivial... works everwhere, doesnt solve everything though, but for getting started its absolutely fine imo
<asac> it solves the problem: how to assemble a complete python dependency tree easily. it doesnt solve the native libs etc. parts
<asac> or the how to include the intepreter
<asac> but since we have python in OS image having that approach as the _simple_ way of getting started sounds good
<ogra_> asac, not at all ... if the interpreter is gone from the system all packages that foillowed such a howto will break
<ogra_> asac, the point dholbach tries to solve if giving developers something in their hands right now
<ogra_> so we either take barry's approach or actually finish ricmm's to pull in the interpreter etc
<beowulf> @reviewlist
<nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir/+merge/260620 | No reviews (3 days old)
<nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/fix-tests/+merge/260618 | Approve: 1 (3 days old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-banner/+merge/260836 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/link-to-external-ui/+merge/260833 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/remove-not-uninstall/+merge/260775 | No reviews (less than a day old)
<dholbach> barry, ^ not sure if you saw the discussion above...
<barry> dholbach: nope, thanks
<ogra_> beowulf, does the description in webdm come from thr redme.md now (it used to come from the store UI description before)
<ogra_> *the
<barry> ogra_: that's why i emphasized py3 because it probably will be a while before it disappears, although if mvo_ does port the entire system-image infrastructure to the store + a new client, that will change of course
<barry> plus...py2 blech
<ogra_> yeah, i wouldnt suggest to anyone to rely on interpreters in the core image
<ogra_> we should have a tool that bundles it properly for your snap
<barry> ogra_: certainly that's the right long term solution.  plus it lets app developers ship whatever crazy configuration that's different than ubuntu's crazy configuration of their interpreter they want
<barry> ogra_: there have been *lots* of upstream discussion around this approach
<ogra_> i think it should also be the short term solution ...
<barry> as it's not just applicable to snappy of course
<barry> maybe
<ogra_> if we once start allowin such a habit (relying on core bits) it will be really hard to get that gone again
<barry> ogra_: it's just that i'd like to see upstream work continue.  i'd like us to drive that so our needs are addressed, but in a fashion that's generally useful, rather than we bake our on solution that's different than everyone elses
<ogra_> well, i dont see a problem with that ... for the time being we should have a tool that fulfills the purpose, then gets merged into snapcraft as a plugin and once upstream work is done we can replace the plugin
<ogra_> i just dont want to encourage using core components, thats all
<beowulf> ogra_: still store, afaik
<ogra_> hmm
<beowulf> ogra_: maybe sergiusens looks in the readme if there's nothing in the store?
<ogra_> well, there is a lot in the store for chatroom
<ogra_> (like a full paragraph)
<beowulf> ogra_: yes, so i see
<ogra_> and i dont find the line that webdm displays in the sotre at all
<ogra_> *store
<beowulf> ogra_: yup, let me check what's happening there
<jdstrand> beuno: fyi, r473 of the review tools is the *one* (aka, I'm cutting 0.28 now) :) feel free to pull that whenever
<beowulf> sergiusens: hey, is 'description' in snappy/webdm package api coming from? (and if readme.ms, is it possible it's being truncated on the first newline)?
<beowulf> sergiusens: *where
<sergiusens> beowulf: ogra_ this is from early snappy days, beuno and mvo_ are the intellectual authors for readme.md; I think the store reads the first line and it's supposed to be char limited
<sergiusens> in any case, I think it's bad that the store let's you override anything from package.yaml
<ogra_> sergiusens, hmm, thats pretty bad now that we dont have a "click" way to get to the used ports
<sergiusens> it should either be free form or part of the package
<dholbach> asac, barry, ogra_: where do we go from here regarding the python tutorial? Jamie also added his suggestion to https://trello.com/c/vbQTdIYQ/5-development-snappy-tutorial-for-python-2-3
<sergiusens> ogra_: there is a click way, beowulf just needs to hook to the ui, ogra_ did you add the 'ui' port?
<ogra_> i.e. hos is the user supposed to know chatroom runs on port 6565 and only works under chrome/chromium
<ogra_> *how
<ogra_> sergiusens, yep, i did
<beowulf> sergiusens: ogra_: https://code.launchpad.net/~stephen-stewart/webdm/link-to-external-ui/+merge/260833
<ogra_> external ui ...
<ogra_> ah, ood
<sergiusens> ogra_: great, then http://webdm.local:4200/api/v2/packages/chatroom.ogra will have ui_port (I see it here)
<ogra_> *good even
<sergiusens> ogra_: just need to hook up in the js side which I guess is what beowulf's MP is all about
<beowulf> ogra_: the only bit missing is the description to tell the user it's chromium only
<beowulf> ogra_: which you have in the store
<ogra_> beowulf, right
<sergiusens> beowulf: ogra_ I guess we can add a http://webdm.local:4200/api/v2/packages/chatroom.ogra/documentation that exposes the readme.md
<ogra_> +1
<beowulf> sergiusens: why not the store description?
<beowulf> oh, i know
<barry> dholbach: not sure, but i subscribed to that card so i can follow the discussions.
<ogra_> dholbach, i guess thats something for tomorrows community sync meeting
<sergiusens> beowulf: 2 reasons; when you upload an app, readme.md pre fills the store description (it shouldn't allow you to change it IMO); second one is to use the installed resource instead of going over the web
<beowulf> sergiusens: yeah, no 2 came back to my mind as i hit return
<beowulf> sergiusens: on 1, the store needs to be able to set a description per store
<barry> ogra_, dholbach should i attend that meeting?
<ogra_> if you feel like ... 14:00 UTC (if my math isnt wrong)
<barry> ogra_: that's doable.  where is it?
<dholbach> sent you an invitation
<dholbach> barry, ^
<barry> dholbach: awesome, thanks
<zyga> it seems that name/executable are not working quite well and assumptions are made that name is identical to executable
<beowulf> what are 'caps'? https://developer.ubuntu.com/en/snappy/guides/security-policy/ are they described somewhere?
<asac> dholbach: is there a proposed text already?
<asac> for the tutorial i mean
<dholbach> asac, I was starting to work from http://www.wefearchange.org/2015/04/creating-python-snaps.html
<dholbach> asac, for ricmm's example we basically just have the code
<asac> dholbach: that thing is far too complex imo
<asac> super hard and not working for everything but 3.5... its clearly the future, but not the short term solution
<asac> we should put out as the easy way to get started
<ogra_> asac, right, but we should definitely not suggest to people to rely on the py interpreter in core
<dholbach> asac, barry just clarified: the 3.5 bits are for additional debugging
<jdstrand> beowulf: they are not documented yet (this is a todo). we want something like this: https://developer.ubuntu.com/en/publish/security-policy-groups/ for snappy
<jdstrand> beowulf: well, they are sorta documented
<jdstrand> let me get that
<zyga> ogra_: why is /tmp restricted when we can just make /tmp private to the application?
<ogra_> zyga, it sitn restricted ... you have /tmp/snaps/<appname> for your own convenience afaik
<jdstrand> dholbach: curious-- is there a trello card for the docs team to do the tutorial I mentioned on the list and something for ^
<ogra_> *isnt
<zyga> ogra_: it seems pretty broken to make /tmp read only (and teach everything not to use it) if we can just put it in a private namespace
<zyga> ogra_: well, it sure seems to be:
<zyga> ogra_: FileNotFoundError: [Errno 2] No usable temporary directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/apps/stubbox.sideload/0.21.2']
<zyga> ogra_: now I can patch that but I feel I should not have to
<ogra_> zyga, only the toplevel is restricted, but TMPDIR always points to the app dir anyway
<zyga> ogra_: yes, and that's what I'm talking about
<seb128> mvo_, the command you gave me earlier, it complains that there is no channel named "edge"?
<ogra_> the launcher should create it
<zyga> ogra_: well, my question stands
<ogra_> iirc there was a bug in older images with that, but i think that has been fioxed quite recently
<zyga> ogra_: since we are using containers making a app-private /tmp seems obvious
<ogra_> zyga, for more details ask the security team :)
<jdstrand> beowulf: https://developer.ubuntu.com/en/snappy/guides/security-policy/ has quite a bit of detail. there are two caps now: network-client (which can also be referred to as 'networking') and 'network-service'
<mvo_> seb128: oh, what version of ubuntu-device-flash are you using?
<ogra_> zyga, who uses containers ?
<zyga> ogra_: how many libraries need patches to make non-writable /tmp work?
 * ogra_ hasnt used a container since he started playing with snappy
<seb128> mvo_, I've vivid + the ppa updated on friday
<zyga> ogra_: don't we use namespace for devices already?
<jdstrand> beowulf: if you don't specify caps at all, you get 'networking' (aka, client networking)
<beowulf> jdstrand: thanks, we should link the first 'caps' to one of this doc
<zyga> ogra_: s/containers/namespaces/ (which is mostly the same thing)
<seb128> mvo_, I need wily?
<ogra_> zyga, container means to me its an independent system ...
<ogra_> closer to a VM
<jdstrand> fyi, we aren't using full blown containers
<mvo_> seb128: hm, that should be ok - give me a sec to double check
<jdstrand> nither a system container nor an app container
<jdstrand> ie, we aren't reinventing docker. if you need an app container, use docker on snappy
<mvo_> seb128: could you pastebin the ubuntu-device-flash version you are using?
<jdstrand> we do use a few containery techniques though
<seb128> mvo_, how do I get it?
<dholbach> jdstrand, sorry, which tutorial?
 * jdstrand ->meeting
<zyga> ogra_: nomenclature aside, it is broken
<jdstrand> dholbach: let me forward you the email in a bit
<seb128> mvo_, oh, there is an update, let me try that
<dholbach> thanks jdstrand
<seb128> mvo_, sorry and I guess you meant package version, I though it was a binary bundled with other things ;-)
<ogra_> zyga, talk to the security team ... i'm sure there is a rationale
 * zyga looks at why python crashes there, it does seem to look at TMPDIR
 * ogra_ would be surprised if it didnt
<barry> dholbach: i'm not sure what's "too complex" about it.  i tried to make it super easy for people
<zyga> jdstrand: a non-writable /tmp is rather harsh, is there a rationale for it?
<zyga> jdstrand: (understanding app separation)
<mvo_> seb128: no worries
<seb128> mvo_, k, still not working
<dholbach> barry, I didn't say it was "too complex"
<jdstrand> zyga, ogra_: I didn't read all backscroll, but see the change to the launcher in https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages
<barry> sure, we want to not rely on the base interpreter, but that's tractable i think
<barry> dholbach: oh, sorry, i think asac might have
<seb128> mvo_, it gives me "Channel edge not found on server http://system-image.ubuntu.com"
<seb128> mvo_, version is 0.20snappy7-0ubuntu1.2
<jdstrand> zyga: the app is supposed to have a writable tmp area. that is why TMPDIR was set. apps should not be able to read each others temp files, so they are in different dirs. the change to the launcher now creates a private mount namespace for /tmp
<zyga> ogra_: TEMPDIR is set but TMPDIR is not
<zyga> it's set but doens't make it through
<ogra_> sounds liek a bug
<zyga> ogra_: yep
<ogra_> file it then :)
<zyga> lp:snappy?
<ogra_> https://bugs.launchpad.net/snappy
<ogra_> (as the topic says)
<zyga> thanks
<ogra_> though i guess its a launcher bug
<mvo_> seb128: confusing http://paste.ubuntu.com/11523152/ seems to work for me - maybe I had a typo in my earlier command?
<zyga> https://bugs.launchpad.net/snappy/+bug/1461146
<ubottu> Ubuntu bug 1461146 in Snappy "TMPDIR is set by the generated launcher, doesn't make it to executable" [Undecided,New]
<jdstrand> zyga: is that for a systemd service or a cli command?
<zyga> jdstrand: cli
<ogra_> looks like cli
<jdstrand> ok
<zyga> jdstrand: I can give you the snap if you want to
<jdstrand> no, that's ok
<seb128> mvo_, http://paste.ubuntu.com/11523181/ here :-(
<seb128> mvo_, do you use the same server?
<jdstrand> I was thinking it might be another bug but if it is cli, then it isn't
<mvo_> sergiusens: are there multiple  0.20snappy7-0ubuntu1.2  ubuntu-device-flash versions around :/ ?
<ogra_> looks simply like a typoed var
<mvo_> sergiusens: see seb128 question
<beowulf> @reviewlist
<nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir/+merge/260620 | No reviews (3 days old)
<nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/fix-tests/+merge/260618 | Approve: 1 (3 days old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-banner/+merge/260836 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/link-to-external-ui/+merge/260833 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/remove-not-uninstall/+merge/260775 | No reviews (less than a day old)
<beowulf> mvo_: :)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-more-errors-15.04/+merge/260111 | No reviews (6 days old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-merge-integration-tests/+merge/259592 | Needs Information: 1, Approve: 1 (12 days old)
<nothal> https://code.launchpad.net/~jamesodhunt/snappy/install.yaml/+merge/256925 | Needs Information: 1, Needs Fixing: 1 (41 days old)
<seb128> mvo_, sergiusens, sorry, it works now after the upgrade
<mvo_> ok
<seb128> mvo_, sergiusens, I had the previous binary copied over to try something and I forgot about it :-/
<seb128> mvo_, thanks and sorry again ;-)
<mvo_> beowulf: bad luck, dinner time here
<mvo_> seb128: no worries
<seb128> mvo_, no luck with the wily iso, boots ok on an old laptop but is not recognized by my uefi laptop config
 * zyga hopes snappy adopts git
<zyga> bzr changes are pretty hard to follow
 * tbr never really grok'd bzr nor hg
<zyga> bzr/hg/git aside, readable patches are relevant
<mvo_> seb128: meh
<seb128> mvo_, yeah :-/
<mvo_> seb128: maybe worth talking to slangasek about this, I might misremember but  I think he created uefi bootable image before for snappy
<seb128> mvo_, k, thanks
<seb128> slangasek, hey, do you have hints about how to get a snappy iso to boot on an uefi/secure boot laptop config? the standard iso seems to not do the job
<slangasek> iso?
<slangasek> seb128: iso, or disk image?
<slangasek> seb128: assuming it's a disk image that you're booting from USB, my first question would be, what version of udf did you use to master the image.  The second question (assuming you're using a suitably recent udf with UEFI support) is what the contents of partition 2 are
<seb128> slangasek, I created an iso today using u-d-f 0.20snappy7-0ubuntu1.2 calling udf core rolling --channel edge -o img and dd-ed that to an usb stick
<slangasek> ok, so... not an iso
<seb128> k, "image"
<seb128> sorry ;-)
<Chipaca> what's the "official" url for meta.md ?
<seb128> you want details about one of the partitions?
<zyga> sergiusens: https://lists.launchpad.net/checkbox-dev/msg00298.html
<zyga> ogra_: quick question about shared libraries
<zyga> ogra_: with rpath it's almost easy to get this to wrok
<zyga> ogra_: but .sideload vs non-sideload thing makes it problematic to hard-code /apps/$name/current/lib as rpath
<slangasek> seb128: I'm checking the changelog for 0.20snappy7-0ubuntu1.2 now, but to my knowledge, support for UEFI lands in ubuntu-device-flash 0.21
<zyga> ogra_: I know $ORIGIN exists, I need to see if I can use it (will it be /usr/bin/ or /apps/$name/current (?)
<zyga> sergiusens: that's plainbox on snappy
<zyga> I kind of like snappy
<zyga> I just wish it was 5 years later, when it's all mature
<zyga> and tooling is good
<zyga> :-)
<seb128> slangasek, k, I'm using vivid + the ppa, maybe that's not uptodate enough
<slangasek> seb128: confirmed, the last update to goget-ubuntu-touch in the production ppas was April 23, and UEFI support landed on May 8
<slangasek> so the snappy team needs to update goget-ubuntu-touch in the beta and 15.04 ppas
<seb128> mvo_, ^
<slangasek> seb128: if you need it for testing, you can use the version in the tools ppa: https://launchpad.net/~snappy-dev/+archive/ubuntu/tools/
<seb128> slangasek, k, I'm going to try that, thanks
<mvo_> sergiusens: -^
<mvo_> thanks slangasek and sorry for the noise
<slangasek> mvo_: no worries :)
<mvo_> sergiusens: tl;dr - could you please release ubuntu-device-flash with the uefi support? or is somethng blocking and if so, how can I help :)
<mvo_> ?
<sergiusens> mvo_: I was going to release it as soon as someone approved an MP I created on Saturday, it's unreviewed still
<sergiusens> mvo_: also, I'm really scared of rebuilding now if we deviate from 15.04 compatibility in trunk
<sergiusens> Chipaca: can you review https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/properDeviceFiltering/+merge/260646 ?
<Chipaca> sergiusens: yes
<Chipaca> sergiusens: no tests in this, no?
<sergiusens> Chipaca: no
<Chipaca> ok, off to make dinner for me
<Chipaca> o/
<mvo_> sergiusens: thanks and sorry for the lack of reviews
 * rsalveti finally reads backlog
<tedg> jdstrand, So it seems that by default we give access to sed but not xargs, which one of this is the mistake? :-)
<jdstrand> tedg: xargs is the mistake. can you file a bug against ubuntu-core-security?
<jdstrand> tedg: is this blocking you?
<jdstrand> I mean, I know it literally is blocking access, but, I'd like to know how fast you need it
<tedg> jdstrand, Naw, I'll just copy it into my package.
 * tedg *snaps*
<jdstrand> hehe
<tedg> jdstrand, bug 1461243
<ubottu> bug 1461243 in ubuntu-core-security (Ubuntu) "Get DENIED for xargs" [Undecided,New] https://launchpad.net/bugs/1461243
<jdstrand> great, thanks!
<tedg> jdstrand, Is there a way we could give a utility access to a specific directory?
<tedg> jdstrand, The use case is that we have this snapcraft tool which will call other plugins for a language. But they need to access the user's home directory for what they're building.
<tedg> jdstrand, It'd be nice if we didn't have to give them full access to everything, but instead snapcraft could say "oh, now this guy can have this"
<tedg> (for this run)
<sergiusens> zyga: I don't really follow your email, but I may need to read it with more time to grab some context
<sergiusens> zyga: and we will switch to git once we have a nice tarmac replacement (no need for fancy stuff, can be polling based even as tarmac is today)
 * sergiusens isn't sure what the ETA for webhooks is
 * sergiusens isn't sure the launchpad api can list MPs for git branches
<zyga> sergiusens: tarmac/git is in progress
<zyga> sergiusens: the mail is just my ramblings, sorry for making it hard to read
<zyga> sergiusens: I just wanted to show you plainbox snappyified :)
<zyga> sergiusens: and ask if the $name.sideload vs $name could be resolved somehow
<zyga> sergiusens: so that libraries can be used by using rpath
<zyga> sergiusens: webhooks are not needed, AFAIR the git stuff is not exposed in the api yet
<zyga> sergiusens: have a nice evening, bye :-)
<sergiusens> zyga: not really; you shoulnd't rely on that path not changing
<sergiusens> bye
<jdstrand> tedg: if the snapcraft tool were confined, it would be possible, yes
<jdstrand> tedg: or, the snapcraft tool could be apparmor aware and change to a profile for the plugin
<tedg> jdstrand, I was figuring the snapcraft tool would call a binary registered by the plugin.
<tedg> jdstrand, So that'd be effectively confined by the core launcher
<jdstrand> hmm, I may not understand how the snapcraft tool is supposed to work. it might make sense to schedule a meeting with me and tyhicks
<tedg> Czech Stop in West ?
<jdstrand> heh. that would be nice :)
<tedg> jdstrand, I think we're determining how it could work. So, if you think it shouldn't work like that, it's fine.
 * tyhicks was there 2 days ago
<tyhicks> :)
<tedg> I think that the thing we want is "super easy to make snaps" everything else is negotiable :-)
<tedg> But I was thinking the language plugins could be "apps" in the traditional sense.
<tedg> Hoping they'll have to be as little special as possible.
<tyhicks> tedg: is there a design doc for snapcraft at this point?
<tedg> tyhicks, We have more of an ideas document: https://docs.google.com/document/d/166fzfKp6YIZ839KyeNj2rO976ahLxWM35_fodwbPo1U/edit#heading=h.sta78u24yxr7
<tyhicks> tedg: thanks - I'll read up on it
<rsalveti> elopio: we're not yet automatically updating the image published at http://cdimage.ubuntu.com/ubuntu-snappy/15.04/edge/ (which I have an action to check why)
<rsalveti> sergiusens: I should know more about webhooks in a few days, when we get stakeholders meeting for launchpad
<rsalveti> zyga: who is porting tarmac to git?
<rsalveti> zyga: and for python, kind of the idea we had is that we'd have a devpack (that gets consumed when creating your snap) that would bundle the interpreter (but you could as well bring your own interpreter)
<rsalveti> zyga: we don't want to use interpreters as frameworks necessarily
<rsalveti> sergiusens: is there any sort of incompatibility with current ubuntu-device-flash related with 15.04 and rolling?
<rsalveti> sergiusens: saw you pushed to wily, wonder if that will get stuck in proposed since we got a ftbfs for powerpc
<sergiusens> @reviewlist
<nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir/+merge/260620 | No reviews (3 days old)
<nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/fix-tests/+merge/260618 | Approve: 1 (3 days old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-banner/+merge/260836 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/link-to-external-ui/+merge/260833 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/remove-not-uninstall/+merge/260775 | No reviews (less than a day old)
<sergiusens> rsalveti: yeah, it's stuck http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<sergiusens> rsalveti: oh, and no, there's incompat today yet... key word, yet ;-)
<rsalveti> sergiusens: right :-)
<rsalveti> good making the release anyway since it's easier to tell people that they should be using a more recent version
<sergiusens> rsalveti: right, I'm not sure I should be just using the ppa, most of the people we care about are on trusty
<rsalveti> sergiusens: right, but they are all using the ppa, right?
<sergiusens> rsalveti: and I guess all the uefi confusion was because we never migrated to the beta ppa
<sergiusens> rsalveti: yup, they all use the ppa
<rsalveti> right
<rsalveti> yeah, I'll fix this ppa confusion soon
<sergiusens> rsalveti: do you know wha the ETA is on powerpc? Or can we just blanket it through?
<rsalveti> sergiusens: it seems doko/foundations doesn't have the time to fix the ppc builds atm, so I believe we should just ask for an override for it
<rsalveti> so it's not blocked in proposed
<sergiusens> rsalveti: great, so is that #ubuntu-release or #ubuntu-devel?
<rsalveti> sergiusens: #ubuntu-release should work
#snappy 2015-06-03
<sergiusens> rsalveti: check #ubuntu-release :-P
<sergiusens> @reviewlist
<nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir/+merge/260620 | No reviews (4 days old)
<nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/fix-tests/+merge/260618 | Approve: 1 (4 days old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/link-to-external-ui/+merge/260833 | Needs Information: 1 (less than a day old)
<nothal> https://code.launchpad.net/~sergiusens/snappy/trunkBackport470/+merge/260884 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~sergiusens/snappy/forgetGocheck/+merge/260890 | No reviews (less than a day old)
<rsalveti> sergiusens: Chipaca: don't we have auto-merge for snappy/15.04?
<rsalveti> checking https://code.launchpad.net/~mvo/snappy/snappy-lp1449032-poor-mans-rsync-15.04/+merge/260556 , not sure what are the missing steps in there
<miken> rsalveti: missing commit message?
<dholbach> good morning
<dholbach> seb128, so you finally got an answer? :)
<seb128> dholbach, hey, yeah, thanks for nagging mvo for me ;-)
<dholbach> :)
<zyga> good morning
<fgimenez> good morning
<davidcalle> Morning snappy o/
<seb128> hey davidcalle
<beowulf> morning
<beowulf> sergiusens: hey, you asked if 'service ui' was a good name for the link to a snaps running web ui from webdm, it's the least bad name i could come up with
<beowulf> i am open to suggestions as to what that link should be called, but i think the design of this area needs work
<beowulf> sergiusens: also, thanks for the reviews :)
<ogra_> mvo, hmm, seems the image builds all failed tonight looking for that apparmor features file
<mvo> ogra_: let me look into this
<ogra_> i dont get why
<ogra_> neither apparmor nor livecd-rootfs changed
<mvo> ogra_: I think its because I added the cache generation
<ogra_> (or am i looking at the wrong archive ?)
<ogra_> oh, i see ... the PPA
<mvo> ogra_: I think I know whats going on, I will check
<ogra_> k, thanks :)
<elopio> good morning.
<JamesTait> Good morning, folks! Happy Repeat Day, and happy Repeat Day! ð
<mvo> jdstrand: hey, for later. I put some ideas and a proof-of-concept for the apparmor cache file handling in https://bugs.launchpad.net/snappy/+bug/1460152/comments/6
<ubottu> Ubuntu bug 1460152 in Snappy 15.04 "apparmor cache not updated when apparmor.d rules change (breaks 15.04/stable -> 15.04/edge updates)" [Critical,In progress]
<mvo> jdstrand: I added a different fix, but it might be a option to consider changing apparmors behavior here
<mvo> jdstrand: one example where the current behavior is not ideal is if a backup file is restored for a policy with the original (backup) mtime, then the cache is not re-generated either
<miken> Hi people. I created this bug the other day, but wasn't sure if it's a webdm bug or more generally how snappy itself sets up /tmp/snaps/ the first time a framework is installed. Can someone pls check? https://bugs.launchpad.net/bugs/1460517
<ubottu> Ubuntu bug 1460517 in webdm "Cannot run other snaps after first installing webdm" [Undecided,New]
<sergiusens> rsalveti: I see it merged
<sergiusens> rsalveti: oh yeah, lp-propose's bug where the commit message is actually the description ;-)
<sergiusens> beowulf: how about just ui or web ui... or we can go back in time and call it 'web portal' :P
<beowulf> sergiusens: web portal is possibly the most human, still doesn't accurately explain what's going on (because we can't explain what's going on, unless the user can give a string to explain what's at the end of that url?)
<beowulf> i'll change it to anything though, just pick some words :)
 * ogra_ curses vivid and reboots his overheating laptop for the nth time today :(((
<sergiusens> ogra_: go back to precise!
<sergiusens> beowulf: maybe ogra_ has better words for it
<ogra_> for what ? renaming webdm ?
<sergiusens> ogra_: no, let me get a screenshot ;-)
<ogra_> (if i can open a browser without my laptop sutting down :P )
<ogra_> *shutting
<sergiusens> ogra_: http://imgur.com/grZ72cS
<beowulf> ogra_: in your webrtc snap, you define a ui port, in webdm we create a button for this
<sergiusens> the mouse is over "Service UI"
<beowulf> ogra_: what should that button say?
<beowulf> (talking buttons, who knew)
<ogra_> just "Open" ?
<ogra_> service Ui sounds confusingly as if i would access a configuration option there
<beowulf> ogra_: you might, in some snaps
<ogra_> (somehow like "Management UI")
<ogra_> well, then call it "Manage/Open" or some such ...
<beowulf> "Open" is actually open ended enough to cover all options, or about "Open $name"
<ogra_> its a bit tricky to find a unique name for a multi purpose button :)
<ogra_> yeah, i guess Open is the best here unless you want to indicate management/configuration can be accessed through it
<ogra_> but i guess thats up to the app
<beowulf> http://bazaar.launchpad.net/~stephen-stewart/webdm/link-to-external-ui/revision/155
<beowulf> sergiusens: ^
<sergiusens> beowulf: compromise :-)
<sergiusens> @reviewlist
<nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir/+merge/260620 | No reviews (4 days old)
<nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/fix-tests/+merge/260618 | Approve: 1 (4 days old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-list-row/+merge/260837 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~sergiusens/snappy/trunkBackport470/+merge/260884 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1449032-poor-mans-rsync/+merge/260931 | No reviews (less than a day old)
<sergiusens> mvo: mind checking ^ ?
<mvo> sergiusens: yes! I wanted to get to this list this afternoon anyway :)
 * Chipaca adds https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934 to the pile
<Chipaca> mvo: wrt https://code.launchpad.net/~mvo/snappy/snappy-lp1449032-poor-mans-rsync/+merge/260931
<Chipaca> mvo: the comment about "xxx on trunk yadda yadda" might be worth addressing
<Chipaca> given that this is for trunk an' all
<mvo> Chipaca: *cough*
<mvo> Chipaca: indeed
<mvo> Chipaca: its good that I have you
<mvo> Chipaca: meh, extra work, I need to add a new CopyFlagArchive or CopyFlagPreserverUtimes, CopyFlagPreserverPermissions
<Chipaca> mvo: ah
<Chipaca> mvo: leave it for now then
<mvo> Chipaca: ok
<mvo> Chipaca: I will update the comment to say why its not using the internal one at least
<Chipaca> rsalveti: wrt "don't we have automerge for 15.04", we do, but the branch was missing a mommit cessage
<mvo> yes, my bad
<rsalveti> morning
<rsalveti> Chipaca: got it
<Chipaca> speaking of morning, lunch.
<rsalveti> sergiusens: man, you're waking up quite early
<rsalveti> need to start doing the same
<rsalveti> hm, actually, my irc server is in a different timezone
<rsalveti> that explains the log timestamp
<rsalveti> seb128: were you able to get uefi to work in the end?
<seb128> rsalveti, no, I upgraded to the 0.22 version uploaded to wily this night and generated a new image/dd-ed that to a key but the device is still not listed a valid boot one
<seb128> I was waiting on slangasek to be around to ask him how I can debug that more
<rsalveti> right, yeah
<rsalveti> @reviewlist
<nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir/+merge/260620 | No reviews (4 days old)
<nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/fix-tests/+merge/260618 | Approve: 1 (4 days old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-list-row/+merge/260837 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-oauth-quoting/+merge/260909 | No reviews (less than a day old)
<rsalveti> sergiusens: Chipaca: mvo: anyone to review mterry's mrs?
<rsalveti> guess also something to backport to 15.04
<Chipaca> rsalveti: looking at them right now
<rsalveti> Chipaca: awesome
<mvo> rsalveti: I just did
<rsalveti> great
<Chipaca> mterry: why dir = strdup(dir)?
<mterry> Chipaca, that's the main focus of the bug fix.  strtok changes its argument.  And getenv returns the real live environment memory
<mterry> Chipaca, so we have to copy the environment memory so strtok doesn't ruin it
<Chipaca> two things:
<Chipaca> (1) ahh
<Chipaca> (2) aaaaaah
<mterry> :)
<rsalveti> mvo: https://launchpadlibrarian.net/208158748/livecd-rootfs_2.306%2Bppa1_2.306%2Bppa2.diff.gz
<rsalveti> mvo: you're creating the cache without the features file
<rsalveti> I believe that means it would use the features file from the builder (host)
<Chipaca> mterry: about EEXIST, that's a can'thappen, btw
<mterry> Chipaca, it did for me!
<Chipaca> mterry: wat
<mterry> Chipaca, the test didn't pass if you ran it multiple times
<Chipaca> mterry: tell me more!
<mterry> Chipaca, if you try to mkdir a directory that exists, it gives you EEXIST
<Chipaca> mterry: yes
<Chipaca> mterry: but that mkoldtmpdir is called after you have a private /tmp/
<mvo> rsalveti: oh, let me look at this and its implications
<mterry> Chipaca, oh huh.  OK.  Fair.  Then it just affects the test code
<Chipaca> i guess in tests we don't run as root?
<mterry> Chipaca, right
<Chipaca> chicken
<Chipaca> :-p
<mterry> :)
<rsalveti> mvo: that could mean that the cache is incompatible with our targets
<rsalveti> and that would make the cache to be generated again during first boot
<mvo> rsalveti: makes sense, meh - I need to figure out now why it was not working with the feature file. oh well :) I would actually really like to change the way the caching works to tie the cache stronger to the original file. I did a patch but need to wait for jdstrand as its a bit of a depature from the current way the caching works.
<Chipaca> mterry: um, just realised one thing: not checking the return value of that strdup
<mterry> Chipaca, ah!  ok.  I've lived in a g_strdup world so long that I forgot I needed to
<Chipaca> mterry: :)
<mterry> Chipaca, added a check and a comment on why we strdup (since that interaction really isn't obvious).  hence the bug I guess :)
<Chipaca> mterry: if the strdup fails, maybe die("wtf") is in order?
<mterry> Chipaca, sure could.  The other error cases were more mild in that function, but they were more mild errors
<Chipaca> ah, wait, it's mkoldtmpdir
<Chipaca> i'm not sure i care ;)
<mterry> yeah
<Chipaca> otoh, if the strdup failed, you're running on a c-64 or sth
<mterry> although it doesn't bode well for the future of the run
<Chipaca> yup
<mterry> I think a die() is appropriate
<Chipaca> ok
<mterry> Chipaca, done
<jdstrand> mvo: re caching-- I think we need to pull in jjohansen
<sergiusens> mvo: can't we add the kernel and os snap versions to the cache file and have ubuntu-core-launcher add them to the mix to determine which to load?
<sergiusens> just throwing out an idea
<mvo> sergiusens: yeah, I need to dig deeper, but I would love something like this
<jdstrand> we should probably have tyhicks involved too
<jdstrand> mvo: maybe it makes sense to setup a hangout?
<jdstrand> caching seems like it isn't that complicated, but it is actually quite complicated and understanding all the requirements, etc is key
<mvo> jdstrand: probably, I can also write up something by mail and start a discussion with that?
<jdstrand> mvo: mail will be too slow in this case. there is a lot to digest-- between distro, touch and snappy requirements, history and systemd, planned work and new ideas, I think we need to have a hangout
<mvo> ok
<jdstrand> mvo: feel free to send an email detailing the snappy requirements and your thoughts-- that would definitely be useful
<mvo> ok
<jdstrand> that can springboard the conversation
<rsalveti> mvo: right, we can have that script with a known/working features file and then land your change to improve the cache handling
<rsalveti> I believe the the features files should be stable for the generic kernel
<rsalveti> my main concern in there is once we start getting other kernels
<rsalveti> but we can handle this later on
<rsalveti> mvo: we could just land that other approach we had which is not pre-caching and cleaning up the cache when updating
<rsalveti> then work with the security team next week to land a better fix
<rsalveti> since we'd need a fix already for 15.04.1, what do you think?
<mvo> rsalveti: yeah, I think that is ok, I am not overly happy with the options so far, removing the cache files after the upgrade feels like too much of a special case for my taste and the generate-on-image is also problematic once we have hte kernel snap. ideal would be to solve it in apparmor_parse IMO
<rsalveti> right, I agree, mostly concerned with the time that it would take to land that
<mvo> rsalveti: right, cleaning that dir works as a short-term, I am not really liking it, but of course its fine as a stop-gap. I would love to keep the upgrade free of special cases, it should (IMO) just be a untar
<mvo> rsalveti: time is a good point
<mvo> rsalveti: I look into the rm solution then
<rsalveti> mvo: cool, but let's plan something for earlier next week to discuss this in depth
<kyrofa> beowulf, ping
<mterry> mvo, re: my envvars branch.  Thanks for the review!  You commented on needing a dep on ubuntu-core-launcher if I'm going to remove the TMPDIR creation.  But I didn't remove it, I just moved it lower in that file.  So I think I can skip the dep.  You mentioned that the env vars would make sense in the snappy package.  I don't disagree, but then I run into circular dependencies (that code is used in 3 total packages).  Is there a nice neutral place tha
<mterry> t isn't helpers?  Lastly, I'll add SNAP_ARCH
<mvo> mterry: thanks, looks like I missed that the dir is created, all good then :)
<mvo> mterry: you could create a new package just for this, it seems to be a bit overkill though, so maybe helpers is good enough. I leave that to you, if it stays in helpers a small comment why its there would be cool (i.e. mention the circular deps)
<mterry> OK
<beowulf> kyrofa: pong
<kyrofa> beowulf, quick question: The webdm download_size and install_size-- they're in bytes?
<beowulf> kyrofa: yes
<kyrofa> beowulf, just wanted to make sure. Thanks!
<beowulf> kyrofa: did you see the default icon i added?
<beowulf> kyrofa: default-package-icon.svg, let me know if it works for you or needs changing
<kyrofa> Why yes I did! It's lovely, thank you :)
<kyrofa> beowulf, ^^ it works perfectly
<beowulf> \o/
<mterry> mvo, ok updated and merged from trunk
<mvo> mterry: thanks a bunch, just top-approve yourself (as its already approved), tarmac will merge
<mvo> automatically
<mterry> mvo, done, though it feels dirty  :)
<mterry> I'm curious what capacity/interest we have for sunsetting these deprecated variables
<ogra_> well, did we change to the new ones before or after the store was flushed
<slangasek> seb128: ok, so now I'd like to see a recursive directory listing for partition 2 of this image
<Chipaca> @reviewlist
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-list-row/+merge/260837 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-oauth-quoting/+merge/260909 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~chipaca/snappy/unsetActiveClick/+merge/260570 | No reviews (4 days old)
<nothal> https://code.launchpad.net/~chipaca/snappy/setActiveClick/+merge/260569 | No reviews (4 days old)
<Chipaca> nothal: something is very wrong with you, somewhere
<sergiusens> Chipaca: somehow somewhere something is wrong
 * sergiusens feels as if it were a Friday
<Chipaca> sergiusens: something other than nothal finding half the branches?
<seb128> slangasek, hey, sorry I was in a call ...  http://paste.ubuntu.com/11544712/
<slangasek> seb128: no .efi executables.  So this version of udf is /also/ broken.
<seb128> slangasek, is there anything on the image saying what version of udf was used to generate it, in case for some reason something didn't work?
<slangasek> seb128: not that I know of
<seb128> slangasek, do you have any suggestion what to do next about the uefi thing?
<seb128> did anyone got it to work?
<slangasek> seb128: well the version I pointed you to yesterday still works
<slangasek> the one in the tools ppa
<seb128> the wily one is supposed to have the same changes no?
<seb128> the changelog includes
<seb128>   [ Steve Langasek ]
<seb128>   * Add UEFI support for grub.
<slangasek> of course it's supposed to, but clearly somebody regressed something there
<slangasek> it's good to know about this regression, and the snappy team should fix that; but if you're trying to get unblocked for your own work, use the version I know is tested :)
<seb128> k, going to do that next
<sergiusens> slangasek: there are 4 unrelated commits between that and what follows though
<sergiusens> I'll check for regressions in any case
<slangasek> I've just re-confirmed locally that udf 0.21-1+175~ubuntu15.04.1 sets up the boot partition correctly
<slangasek> # ubuntu-device-flash core 15.04 -o ubuntu-15.04-snappy-amd64-generic.img -s 4 --channel stable --oem generic-amd64 --enable-ssh
<slangasek> # kpartx -a ubuntu-15.04-snappy-amd64-generic.img
<slangasek> # mount /dev/mapper/loop0p2 /mnt
<slangasek> # ls /mnt/EFI/BOOT/
<slangasek> BOOTX64.EFI  grub.cfg
<seb128> sergiusens, slangasek: I've had issue with that usbkey so trying again on another one, it's almost done writing, going to let you know if that one worked better in a bit
<sergiusens> seb128: slangasek (amd64)ubuntu@localhost:~$ ls /boot/efi/EFI/BOOT/
<sergiusens> BOOTX64.EFI  grub.cfg
<sergiusens> that's with the latest wily one
<slangasek> seb128: have you checked the contents of the generated image, /before/ flashing it to the usb stick?
<slangasek> to rule out an incomplete usb write
<sergiusens> running in kvm though
<slangasek> seb128: ^^ ok so sergiusens shows the wily version working
<seb128> slangasek, no, but it seems it worked this time
<seb128> so I guess things were wrong puting the image on the first key :-/
<sergiusens> well, I don't know if it boots for uefi, I can attest the files are there at least :-)
<seb128> slangasek, sergiusens: the laptop lists the key as a boot device this time, so it looks good ;-)
<seb128> sorry for the noise :-/
<seb128> yeah, and it boots!
<sergiusens> no worries, you are the first live user ;-)
<sergiusens> for uefi that is
<seb128> :-)
<seb128> great, so that works
<seb128> tomorrow to try to resolve desktop image package conflicts
<sergiusens> great, as soon as that wily powerpc issue is gone I'll propagate this to all the ppa's
<seb128> slangasek, sergiusens, thanks!
<mterry_> Is tarmac not hooked up for ubuntu-core-launcher?
<sergiusens> mterry_: I don't think so, no
<mterry_> sergiusens, should we push to trunk manually once we're approved?
<sergiusens> mterry_: I can setup a no build merge for it with tarmac; can setup a bzr bd/sbuild thing for tomorrow or later
<mterry_> sergiusens, that would be awesome
<tedg> sergiusens, When you do core launcher can you do snapcraft too please? :-)
#snappy 2015-06-04
<dholbach> good morning
<fgimenez> good morning
<dholbach> hi fgimenez
<JamesTait> Good morning all; happy Hug Your Cat Day! ð
<elopio> good morning.
<elopio> hey fgimenez: what do you think about the latest version, ready to promote to stable?
<fgimenez> elopio, hi, yes, seems good so far
<fgimenez> elopio, i'm finishing the script for the complete upgrade path proposed by rsalveti, that will give us more confidence
<elopio> fgimenez: nice, thank you.
<sergiusens> rsalveti: mind doing a no change rebuild upload of the archive version of 'ubuntu-snappy' to get the powerpc binaries built? It seems we never built them
<Chipaca> rsalveti: where was the 15.04.x blueprint?
<sergiusens> Chipaca: https://trello.com/c/wxQzJ9uT/18-create-15-04-1-stable-image
<rsalveti> sergiusens: wonder if we would need a no change upload
<rsalveti> yeah, that's the one
<sergiusens> Chipaca: and the bug task i there
<rsalveti> sergiusens: since it was copied from vivid
<Chipaca> k
<rsalveti> https://launchpad.net/snappy/+milestone/15.04.1
<rsalveti> as well
<sergiusens> rsalveti: yeah, it was copied from a ppa that probably didn't build for powerpc
<sergiusens> rsalveti: yeah, I just gave him the parent link ;-)
<sergiusens> Chipaca: from the work items, do you know of anything that can be crossed out?
<Chipaca> sergiusens: some of them should be landing about now
<sergiusens> Chipaca: do you know anything about the backporting ones?
<Chipaca> sergiusens: i've jused approved several backporting MPs
<Chipaca> s/jused/just/, and by just i mean an hour or so ago
<Chipaca> before lunch
<sergiusens> Chipaca: these specifically Backport lp:~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/add-sync-calls
<sergiusens> Chipaca: and yeah, I saw :-)
<Chipaca> and mvo's 15.04 moar-errors one could land if he's not going to be around
<rsalveti> sergiusens: want to do another release and I can sponsor your upload?
<rsalveti> sergiusens: or just a rebuild is fine?
<sergiusens> rsalveti: just a rebuild, a release forces a lot of catching up on u-d-f
<rsalveti> sergiusens: right, sure
<sergiusens> rsalveti: I can confirm in a bit though
<sergiusens> to triple check why powerpc isn't there
<rsalveti> sure, will wait then
<Chipaca> do we need to do anything with bug #1449625 for it to be SRUable?
<nothal> Bug #1449625: systemd and bin-path exported variables are not in sync <Snappy:Fix Committed> <Snappy 15.04:Fix Committed> <http://launchpad.net/bugs/1449625>
<ubottu> bug 1449625 in Snappy 15.04 "systemd and bin-path exported variables are not in sync" [High,Fix committed] https://launchpad.net/bugs/1449625
<Chipaca> marked it "done" in the trello, but then thought to ask, because it explicitly says SRU there :)
<sergiusens> Chipaca: we should probably SRU everything that's making it into lp:snappy/15.04
 * Chipaca marks it "done"
<Chipaca> do we really support "upgrading to edge"?
<Chipaca> i thought that was a corner case brought about by fiddling with files
<rsalveti> edge 15.04 or rolling?
<sergiusens> Chipaca: we want to support upgrading to edge when we have proper channels and os/kernel snaps
<mterry> sergiusens, you mentioned being able to set up tarmac for ubuntu-core-launcher?  Can you also do it for snapcraft?
<sergiusens> mterry: yeah, I saw tedg's request :-)
<sergiusens> will do it in a bit
<mterry> sergiusens, oh didn't know he asked too  :)
<sergiusens> Chipaca: nagging welcome ;-) https://code.launchpad.net/~sergiusens/snappy/YouShallNotPass/+merge/261079
 * Chipaca prepares the nag
<Chipaca> sergiusens: +1'ed with a nit
<sergiusens> Chipaca: nice catch ;-)
<Chipaca> sergiusens: which makes me realise
<sergiusens> Chipaca: pushed
<Chipaca> sergiusens: you're not testing the use of it
<sergiusens> uh oh :-P
<sergiusens> Chipaca: right! Not the error, which I guess I'll do now
<Chipaca> :)
<sergiusens> Chipaca: o, now I need interpackage architecture stubbing, yay
<Chipaca> ...
<Chipaca> no, no you don't
<Chipaca> just test with "xyzzy" architecture
<Chipaca> that is, in the package, put architectures: foo, bar, baz
<Chipaca> but properly ;)
<sergiusens> Chipaca: oh, I was going to build a test snap, not test the error only ;-)
<Chipaca> sergiusens: you're already testing that you detect the "right" arch in the unit test
<Chipaca> sergiusens: you just need to test that you report the error in the integration test
<Chipaca> sergiusens: yes, i meant in the package.yaml
<sergiusens> Chipaca: right, but I rely on UbuntuArchitecture() which depends on the system where you run the test ;-) That's why I said interpackage :-)
<sergiusens> so I'll do what I was going to do ;-)
<Chipaca> sergiusens: not sure i follow
<sergiusens> helpers.UbuntuArchitecture() uses the systems arch, it's all fine if we all run on amd64 but this will all fail when using a different system
<sergiusens> meh, I understand myself ;-)
<sergiusens> I just need to mock UbuntuArchitecture
<Chipaca> sergiusens: um
<Chipaca> sergiusens: i don't see that need
<Chipaca> hence my questioning it
<sergiusens> Chipaca: I'm a lazy typer today https://plus.google.com/hangouts/_/canonical.com/seetheneed
<sergiusens> Chipaca: see if you like it now
<Chipaca> sergiusens: top-approved
<Chipaca> purrfect :)
<sergiusens> Chipaca: thanks
<sergiusens> Chipaca: I always spend some time figuring out which "test helper" we want :-P not sure if the same happens to you
<Chipaca> sergiusens: "write a new one every time" is probably a suboptimal strategy
<sergiusens> Chipaca: https://code.launchpad.net/~sergiusens/snappy/YouShallNotPassBeforeEither/+merge/261097
<elopio> rsalveti: do you think we will need to test something on the phones in the next months?
<elopio> I'm wondering if I can leave them here so somebody else gets them.
<rsalveti> elopio: you never know
<rsalveti> elopio: I'd suggest you to keep them with you
<rsalveti> unless requested by someone else
<sergiusens> rsalveti: elopio you only really need one; I guess we will mostly be doing the core work (os and kernel snap)
<sergiusens> but would leave ui work to others
<rsalveti> right
<elopio> yes. That's what I was thinking. I need a phone to call my mother too :)
<elopio> I'll ask how hard would it be to get the others back if we happen to need them later.
<kyrofa> Chipaca, ping
<rickspencer3> jdstrand, so it is it totally legit for me to let to snaps to talk to each other over localhost:whateverports?
<sergiusens> rsalveti: how was https://bugs.launchpad.net/snappy/+bug/1424586 Fix Released? Asking in the sense of backporting ;-)
<ubottu> Ubuntu bug 1424586 in Snappy 15.04 "snappy-selftest: fake newer version for upgrade test" [High,Triaged]
<sergiusens> or is that what fgimenez is working on?
<sergiusens> if that's the case, mterry just took over the last bug in that list that is !apparmor
<sergiusens> rickspencer3: there is language to prevent that in package.yaml but it is not enforced yet (internal vs external)
<fgimenez> sergiusens, i'm using the upgrade script just for testing one of the upgrade paths, anyway seems to be a different approach from that bug
<jdstrand> rickspencer3: yes, for external ports (see https://developer.ubuntu.com/en/snappy/guides/package-metadata/). for internal ports there are ideas in the vision doc to create firewall rules that could interfere
<fgimenez> sergiusens, the bug fix implements what we were talking about in yesterday's standup, modifying channel.ini to allow an update from the current version
<jdstrand> rickspencer3: so internal today would work too. also note, ports is in meta.md but we don't do anything with it yet afaik
<sergiusens> fgimenez: yeah, that's in selftests iirc
<jdstrand> rsalveti: btw, is there a card for that ^. it seems like we should at least have ingress filtering for anything in 'ports/internal'
<jdstrand> actually, that gives me a thought
<fgimenez> sergiusens, yep, it's one of them
<jdstrand> I thinks ports is not implemented in part because we wanted a ports service to say whether or not something was assigned
<jdstrand> what if we used netfilter as the database? ie, if you specify 'ports/external' then you get an ACCEPT rule with an id/comment as the PKGNAME_APPNAME and an DROP rule for external interfaces for ports/internal with an id/comment
<jdstrand> sergiusens, rsalveti: ^ idea for whoever implements something more with 'ports'
<Chipaca> kyrofa: pong
<jdstrand> sergiusens, rsalveti: in this manner, snappy can parse iptables output and determine if something on the system is assigned a port
<kyrofa> Chipaca, I'm just getting started on a dbus daemon in golang, and I see you've contributed to go-dbus. Do you recommend that lib?
<Chipaca> kyrofa: last time i checked, it was the better of the go dbus wrappers
<Chipaca> kyrofa: what's your daemon interfacing with?
<kyrofa> Chipaca, the Unity8 QML progress widget
<Chipaca> kyrofa: so you're binding qt/qml?
<jdstrand> rickspencer3: in case it isn't obvious, if you open a port, anyone can connect to it, so things would have to be designed with that in mind
<kyrofa> Chipaca, no, I mean that's what it's communicating with via dbus. Perhaps I misunderstood the question?
<Chipaca> kyrofa: ah, ok :)
<sergiusens> jdstrand: so DENY by default and if declared as an external port we add an ACCEPT and if negotiable we find a free slot and assign it there and somehow send that back to the package
<Chipaca> kyrofa: i was just asking because if you were binding qt or glib anyway, it might make more sense to use their dbus implementation
<jdstrand> future internal ports intend to help-- you declare an internal port and what apps can connect to it
<sergiusens> jdstrand: but iptables doesn't solve the app1 <-> app2 problem though
<jdstrand> sergiusens: yes, essentially
<kyrofa> Chipaca, ahh, gotcha :)
<Chipaca> sergiusens: how "stable" are data dirs? can i tell a guy to ship a symlink to their data dir in their app?
<kyrofa> Chipaca, alright, I appreciate your help! I'll dive into using go-dbus :)
<jdstrand> sergiusens: no it doesn't yet-- that would come later
<sergiusens> jdstrand: we should probably add this to the backlog
<jdstrand> sergiusens: that is in the vision doc
<Chipaca> kyrofa: enjoy! holler when it breaks :)
<kyrofa> Chipaca, ha! Will do ;)
<jdstrand> sergiusens: it would probably make sense to look at ufw's default setup, how it sets up chains, etc for inspiration
<jdstrand> if you want, I can help with the design
<jdstrand> or at least review/comment on it
<jdstrand> sergiusens: alternatively to default DROP, you setup only the rules that are specific to what is declared in ports
<jdstrand> that might be a safer first step until we understand frameworks better
<jdstrand> but we can talk about it
<sergiusens> jdstrand: tracked now https://trello.com/c/p8g9U2cV/80-internal-and-external-port-acl
<jdstrand> sergiusens: awesome (commented)
<jdstrand> sergiusens: it probably will make sense to discuss with th architects team since there will be interactions between snaps and frameworks
<jdstrand> sergiusens: eg, a router framework and an unrelated snap. I'd like to be invited to that call with the architects
<jdstrand> sergiusens: so, for the vision work (additional filtering of internal ports for app to app filtering), the basic idea is create a net cgroup that tags the network traffic, and then you have rules that reference the tag
<jdstrand> sergiusens: I think that should be done as a second step
<jdstrand> sergiusens: ok, I'll stop talking here-- I added my thoughts to the card
<jdstrand> since it is clear that is what you want ;P
<sergiusens> jdstrand: oh, sorry, I'm preparing lunch ;-)
<sergiusens> jdstrand: we can discuss here in a bit and then I'll summarize neatly in the card
<sergiusens> but food first since it's almost 2pm and I need to eat ;-)
<jdstrand> sergiusens: I was just teasing. Everything I have time to discuss today is in the card so I think we are good for nowe
<jdstrand> now*
<mterry> sergiusens, added a .tarmac.sh to lp:snapcraft
<mterry> Missed that in lp:snappy
<rsalveti> sergiusens: for bug 1424586, only trunk is fix released
<ubottu> bug 1424586 in Snappy 15.04 "snappy-selftest: fake newer version for upgrade test" [High,Triaged] https://launchpad.net/bugs/1424586
<rsalveti> the 15.04 task is still opened
<rsalveti> sergiusens: can you check if we can backport the selftests as well?
<rsalveti> then we drop the older separated branch completely
<rsalveti> and I believe the current self tests are compatible with both 15.04 and rolling
<rsalveti> jdstrand: sergiusens: thanks for creating the card
<rsalveti> I think ricmm will own that from the arch side of things
<rsalveti> ricmm: https://trello.com/c/p8g9U2cV/80-internal-and-external-port-acl
<rsalveti> he's our network architect :-)
<rsalveti> let me add this as a topic for the archs call to make sure we don't forget
<ricmm> rsalveti: yea please add that to go over it tomorrow
<rsalveti> already did
<ricmm> thx
<sergiusens> rsalveti: right, but there is no link to any code so I have no idea what work was done for that
<sergiusens> wrt to the bug
<rsalveti> right, mvo just added a comment pointing out the branch
<rsalveti> but didn't link to the bug
<sergiusens> ricmm: rsalveti I also need an 'am I online API' where online can be, lan, wan, internet
<rsalveti> https://bugs.launchpad.net/snappy/+bug/1424586/comments/6
<ubottu> Ubuntu bug 1424586 in Snappy 15.04 "snappy-selftest: fake newer version for upgrade test" [High,Triaged]
<sergiusens> rsalveti: ok
<rsalveti> sergiusens: hm, right
<sergiusens> rsalveti: there, I linked to the bug
<rsalveti> thanks
<rsalveti> for 15.04 we hopefully can just backport the selftests merge
<sergiusens> rsalveti: selftests though, those are cross release still, so there shouldn't be any backport work
<sergiusens> rsalveti: since this landed in the selftest series and not in trunk
<rsalveti> sergiusens: right, but we still need to merge under the 15.04 branch, right?
<rsalveti> sergiusens: but thought selftests were later merged
<sergiusens> rsalveti: I don't think selftests are in trunk yet
<rsalveti> man, I hate this code browse interface for bzr
<rsalveti> yeah, thought mvo had merged that
<sergiusens> rsalveti: nope, and I don't see an MP anymore
<rsalveti> so all good then
<rsalveti> we'll merge for 15.04.2 I guess
<sergiusens> rsalveti: I know there were commens from elopio in an original let's "merge it" MP
<rsalveti> right
<sergiusens> I guess this may have died in relation to his work into converting to go
<rsalveti> could be
<rsalveti> sergiusens: https://code.launchpad.net/~mvo/snappy/snappy-merge-integration-tests/+merge/259592
<rsalveti> yeah, still wip
<rsalveti> @reviewlist
<nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir-15.04/+merge/261104 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-list-row/+merge/260837 | No reviews (1 day old)
<nothal> https://code.launchpad.net/~mterry/snappy/rollback-reboot/+merge/261114 | Needs Information: 1 (less than a day old)
<nothal> https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1449032-poor-mans-rsync/+merge/260931 | Approve: 1 (less than a day old)
<rsalveti> why is it not there?
<sergiusens> rsalveti: the webui isn't showing it either (which is why I thought it was destroyed)
<rsalveti> weeeeeird
<rsalveti> hm, showing fine here
<rsalveti> https://code.launchpad.net/~snappy-dev/snappy/snappy/+activereviews
<rsalveti> lp:~mvo/snappy/snappy-merge-integration-tests â lp:snappy
<sergiusens> rsalveti: oh, right, I'm looking at lp:snappy/+activereviews
<sergiusens> rsalveti: you don't see it in the reviewlist because it's WiP
<sergiusens> that should be @worklist ;)
<rsalveti> oh, got it
<rsalveti> makes sense
<rsalveti> it's just that it's really uncommon for people to let the status as wip
<mterry> I'm getting "operation not supported" and a failure to install hello-world on latest rolling image
<mterry> Anyone else seeing that or is my image just borked?
<rsalveti> iirc latest rolling is still not properly in shape
<rsalveti> so might just be a valid bug
<sergiusens> mterry: rsalveti that's a go 1.4 bug (from Chipaca's findings)
<sergiusens> rsalveti: nah, this team does the right thing ;-) If it's not ready for review WiP is the right status :-)
<sergiusens> @reviewlist
<nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir-15.04/+merge/261104 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-list-row/+merge/260837 | No reviews (1 day old)
<nothal> https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1449032-poor-mans-rsync/+merge/260931 | Approve: 1 (less than a day old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-oauth-quoting/+merge/260909 | Needs Fixing: 1 (less than a day old)
<mterry> sergiusens, I'm looking at this rollback code
<mterry> sergiusens, and actually, we output "Setting %s to version %s" AFTER we rollback
<mterry> sergiusens, so there's no feedback for a bit
<mterry> sergiusens, I'm going to modify my branch to move that up
<sergiusens> mterry: meh
<sergiusens> mterry: I think it's too late :-/
<mterry> sergiusens, I caught it  :)
<mterry> sergiusens, no i didn't
<mterry> sergiusens, sight
<mterry> oh well
<sergiusens> mterry: just leave it, we should have a proper spinner in place
<mterry> sergiusens, fair enough
<sergiusens> mterry: we can reset trunk if you want ;-)
<mterry> yes pls
<sergiusens> mterry: ok, one sec
<mterry> :)
<sergiusens> mterry: done
<mterry> sergiusens, wait what?  That is a thing we do?
<mterry> sergiusens, I thought you were joking
<sergiusens> mterry: sometimes, yes
<sergiusens> mterry: we once had someone (not naming names) do something bad with trunk
<mterry> sergiusens, you crazy.  OK, let me set branch status
<sergiusens> mterry: anyways, no smilies or anything and I take you seriously ;-)
<sergiusens> sorry
<mterry> sergiusens, that's fair.  I just didn't think it was a real thing, so I didn't take you seriously  :)
<mterry> I mean
<mterry> I know you can always push --overwrite
<mterry> But I thought we had protections against that
<sergiusens> mterry: oh, yeah, I know what you mean; but yeah, it's doable and very easy to make a mistake
<sergiusens> a common mistake, bzr branch <code>; cd <code>; bzr merge <branch>; bzr push <code>; sleep (a lot); write_core; bzr commit; bzr push (oops)
<sergiusens> mterry: it's solvable by putting trunk under a different team and only having the merge bot there
<rickspencer3> sergiusens, not sure if you are still here, but are you saying that if I try to send data over localhost:n ... that it will stop working when the security policy is fully implemented?
<mterry> sergiusens, yeah I try to never reuse branch directories for that reason
<sergiusens> mterry: I can't wait for our git migration ;-)
<sergiusens> rickspencer3: I am
<sergiusens> rickspencer3: and yes, it would stop if you declare your port as internal (I don't recall the spec completely from the top of my head right now)
<rickspencer3> sergiusens, ok, I'll wait until the proper implementation for socket communication
<rickspencer3> is there a standard way that folks are parsing yaml in Go?
<sergiusens> rickspencer3: we use gopkg.in/yaml.v2
<sergiusens> rickspencer3: http://godoc.org/gopkg.in/yaml.v2
<mterry> rsalveti, I think we may want bug 1457183 in 15.04.1 too
<ubottu> bug 1457183 in Snappy Launcher 15.04 "TMPDIR is being lost for snap commands" [Undecided,In progress] https://launchpad.net/bugs/1457183
<rsalveti> mterry: yeah, makes sense, thanks
<mterry> When is lp:snappy/selftest run?
<rsalveti> sergiusens should know if enabled as part of the merging process
<rsalveti> but generally we want to run it as part of proposed-migration and after the image gets published
<rsalveti> but that is currently disabled, since we had the ps4 outage
<sergiusens> rsalveti: I can't run it yet as part of the merging process, well I could but it would take a couple of hours I guess (vm inside a vm)
<rsalveti> right
<rsalveti> so the goal is to have that, eventually
<rsalveti> mterry: so your answer is only when manually testing it
<mterry> rsalveti, fair
<mterry> but the plan is more
<Chipaca> sergiusens: suggestions for "integrate()"?
<Chipaca> sergiusens: generateIntegration()?
<Chipaca> sergiusens: ohblahdeeOhblahdahIntegrationLalalalalalala()
<Chipaca> sergiusens: antiderivative()
<sergiusens> Chipaca: doStuff()
<Chipaca> sergiusens: doPerformHelpWorker()
<sergiusens> Chipaca: legacyIntegrationHooks?
<sergiusens> @bugs
<nothal> sergiusens: No such command!
<sergiusens> @help
<nothal> "list" To see the available commands ; "help cmd" for specific command help
<Chipaca> well, some of it is legacy, some isn't
<sergiusens> @help list
<nothal> Lista las Ã³rdenes disponibles.
<Chipaca> @list
<nothal> The available commands are: ['bug', 'critical', 'help', 'last', 'list', 'more', 'ping', 'reviewlist', 'seen']
<Chipaca> @critical
<sergiusens> yay, half translations
<sergiusens> @bug
<sergiusens> hmmm
<Chipaca> bug is for âbug # yaddaâ
<sergiusens> Chipaca: !hal broke
<Chipaca> but @critical isn't
<Chipaca> these python programs, coming here, using up all the bugs
<sergiusens> @help bug
<nothal>  Search a bug and show it's id, title and status
<sergiusens> Chipaca: yeah, I want @bugs :-P
<Chipaca> @help critical
<nothal> show the crtical bugs for self.project (could be a meta project)
<Chipaca> verterok: @critical ne marche plus?
<sergiusens> Chipaca: do you know about https://bugs.launchpad.net/snappy/+bug/1460152 ?
<ubottu> Ubuntu bug 1460152 in Snappy 15.04 "apparmor cache not updated when apparmor.d rules change (breaks 15.04/stable -> 15.04/edge updates)" [Critical,In progress]
<Chipaca> verterok: also, why doesn't @reviewlist list everything?
<Chipaca> ubottu: i know since i last lucked, mvo picked it up somehow?
<ubottu> Chipaca: I am only a bot, please don't think I'm intelligent :)
<Chipaca> or maybe somebody assigned to it
<Chipaca> ubottu: sorry, i meant sergiusens
<ubottu> Chipaca: I am only a bot, please don't think I'm intelligent :)
<Chipaca> ubottu: i never assume that which i am interacting with is intelligent
<ubottu> Chipaca: I am only a bot, please don't think I'm intelligent :)
<sergiusens> Chipaca: I am only a human, pleaase don't think I'm intelligent :-)
<Chipaca> ubottu: it's merely a convenient abstraction
<verterok> Chipaca: what do you mean it doesn't list everything?
<ubottu> Chipaca: I am only a bot, please don't think I'm intelligent :)
<Chipaca> verterok: compare
<Chipaca> @reviewlist
<nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir-15.04/+merge/261104 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-list-row/+merge/260837 | No reviews (1 day old)
<nothal> https://code.launchpad.net/~mterry/snappy/rollback-reboot-15.04/+merge/261135 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1460152-workaround/+merge/261144 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934 | No reviews (less than a day old)
<Chipaca> verterok: and code.launchpad.net/snappy/+activereviews
<nothal> https://code.launchpad.net/~chipaca/snappy/removeClick/+merge/260560 | Needs Information: 1 (5 days old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1459212-check-required-fields/+merge/260509 | Needs Fixing: 1 (6 days old)
<nothal> https://code.launchpad.net/~sergiusens/snappy/frameworkPath/+merge/260202 | Needs Information: 1, Approve: 1 (8 days old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-more-errors-15.04/+merge/260111 | Approve: 1 (8 days old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-merge-integration-tests/+merge/259592 | Needs Information: 1, Approve: 1 (14 days old)
<Chipaca> verterok: in particular, two of mvo's branches and two of my branches don't show up
<verterok> Chipaca: help me here, which ones? :)
<Chipaca> verterok: of mine, lp:~chipaca/snappy/setActiveClick and lp:~chipaca/snappy/unsetActiveClick
<Chipaca> verterok: of mvo, dunno, i just counted
 * Chipaca is bad at making set differences
<verterok> Chipaca: k, one example is ok
<Chipaca> verterok: this is without looking at mvo's git one :)
<verterok> yeah, no git branches/repo support last time I checked launchpadlib
<Chipaca> no worries
 * Chipaca hopes that will come
<Chipaca> sergiusens: before i started the ubottu nonesense, did you read my reply?
<sergiusens> Chipaca: I think rsalveti said it was on cjwatson's list
<sergiusens> Chipaca: about me not being intelligent?
<sergiusens> Chipaca: or this new goodie? https://code.launchpad.net/~mvo/snappy/snappy-lp1460152-workaround/+merge/261144
<Chipaca> sergiusens: yes. I mean no, about mvo being on the bug
<sergiusens> Chipaca: which shows up on the list ;-)
<Chipaca> yeah, that one
<Chipaca> sergiusens: noticed it suddenly had a patch and a branch on the milestone list
<sergiusens> Chipaca: wrt to integrate() add some comment or the word legacy there, we are planning on getting rid of it, right?
<Chipaca> sergiusens: we had a drive-by mvo it seems
<Chipaca> sergiusens: maybe :) it's mostly for generating the click manifest, so yes
<sergiusens> Chipaca: I know of people that had enough mana to summon him :-)
<Chipaca> i found a good place to have a sprint!
<Chipaca> http://www.waterwaysholidays.com/detail/alvdove15.htm
<mterry> jdstrand, where is docker packaging?  I wanted to get the same error you did in bug 1442410
<ubottu> bug 1442410 in Snappy 15.04 "insufficient logging with snappy install errors" [High,Triaged] https://launchpad.net/bugs/1442410
<Chipaca> mvo: boo!
<mvo> hey Chipaca
<mvo> Chipaca: how are you?
<Chipaca> me? I'm fine. My irc client doesn't crash all the time.
<sergiusens> lol
<Chipaca> so, given http://www.washingtonpost.com/blogs/the-switch/wp/2015/06/04/fbi-official-companies-should-help-us-prevent-encryption-above-all-else/
<Chipaca> when do we start encrypting snappy?
<verterok> Chipaca: it seems the bot was in a weird state, kicked it a bit
<verterok> @reviewlist
<nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir-15.04/+merge/261104 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-list-row/+merge/260837 | No reviews (1 day old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1460152-workaround-15.04/+merge/261148 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1460152-workaround/+merge/261144 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934 | No reviews (less than a day old)
 * Chipaca kicks nothal 
 * nothal kicks Chipaca 
<verterok> @reviewlist
<nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir-15.04/+merge/261104 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-list-row/+merge/260837 | No reviews (1 day old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1460152-workaround-15.04/+merge/261148 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1460152-workaround/+merge/261144 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934 | No reviews (less than a day old)
<verterok> Chipaca: something is broken. sorry. will redeploy it
<Chipaca> k...
<verterok> @critical
<Chipaca> sergiusens: afaict lp:~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/add-sync-calls and lp:~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/use-os-sync
 * verterok kicks harder
<mvo> hey Chipaca, sorr,y looks like my network is a bit unreliable
<Chipaca> sergiusens: are meregd already into ubuntu:vivid/ubuntu-core-upgrader
<mvo> Chipaca: did you say anything?
<Chipaca> <mvo> Chipaca: how are you?
<Chipaca> * mvo has quit (Client Quit)
<Chipaca> <Chipaca> me? I'm fine. My irc client doesn't crash all the time.
<Chipaca> <sergiusens> lol
<mvo> my irc client is fine, my network is not ;)
<Chipaca> fair enough
<mvo> I heard ubuntu-core-upgrader, whats up with that?
<mvo> seems to be ok now though (the network), fingers crossed ;)
<Chipaca> mvo: afaict lp:~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/add-sync-calls and lp:~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/use-os-sync are meregd already into ubuntu:vivid/ubuntu-core-upgrader
<mvo> cool, yeah, quite possible
 * mvo can't remember but it rings a bell
<Chipaca> mvo: that is, i bzr branch'ed ubuntu:vivid/ubuntu-core-upgrader, and merging those two branches gave me no diff
<Chipaca> mvo: does this mean the task wrt the upgrader for 15.04.1 is done?
<Chipaca> mvo: or is there more to it?
 * Chipaca has no idea
<mvo> Chipaca: let me quickly double check
<Chipaca> mvo: should i be letting you work at all?
<mvo> Chipaca: heh :)
<mvo> Chipaca: so its merged but it seems like its not uploaded yet, I will push to the PPA for now and we need a proper SRU
<Chipaca> mvo: ok. I thought it landed in ubuntu:yadda after being in the archive proper, but obviously not
<mvo> Chipaca: I land it now
 * rsalveti waves to mvo 
<rsalveti> yeah, we can take care of the SRU side later
<rsalveti> guess that would include core-upgrader and core-launcher
<mvo> hey rsalveti
<mvo> rsalveti: yeah
<mterry> sergiusens, you said earlier that install problems on rolling were "a go 1.4 bug (from Chipaca's findings)"
<mterry> sergiusens, is there a workaround or a bug to track?
<Chipaca> mterry: well, well
<Chipaca> mterry: there is no bug for the 1.4 thing afaik, maybe there should be
<Chipaca> mterry: we'd have to check with a "proper" go 1.4 first
<Chipaca> as this was just with my locally-compiled go 1.4, which might have other issues
<Chipaca> (it hasn't been a problem before, but)
<Chipaca> mterry: what exactly are you seeing?
<mterry> Chipaca, when I try to "sudo snappy install" something, I get "operation not supported" and then a message about unpack from /tmp to the real place failed
<Chipaca> ah, yes, that sounds exactly like the thing that happened with my 1.4
<mvo> Chipaca, mterry: AIUI lp:~mterry/ubuntu-core-launcher/tmpdir-15.04 needs to land in the PPA as well (its not yet, correct?)
<Chipaca> mvo: correct
<mterry> mvo, I'd like it to land yeah
<mvo> cool, shall I do the merge/upload-to-ppa dance or is someone already on it?
<mvo> (sorry, I'm a bit out of the loop)
<Chipaca> I've +1'ed and top-approved
<rsalveti> one other we need review https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir-15.04/+merge/261104
<rsalveti> and then upload as well
<Chipaca> rsalveti: that's the one mvo just asked about
<Chipaca> rsalveti: and the review is done
<rsalveti> indeed, sorry, was going over my tabs
<Chipaca> (as i'd reviewed the original one, it was quick)
<rsalveti> mvo: I can do as well, you should not even be here :-)
<rsalveti> the workaround for the apparmor mr should be automatically merged and uploaded, so that is fine
<rsalveti> guess we just need to create the backporting branch once that lands in trunk
<rsalveti> Chipaca: lol, that article would be a good one for the onion
<Chipaca> rsalveti: :-/
<mvo> rsalveti: I have a backport branch pushed as well :)
 * rsalveti hugs mvo 
<mvo> rsalveti: I can do the merge/upload, thats fine (unless you already started that or I duplicate the work of someone else)
<rsalveti> didn't yet start, unless Chipaca is on it, I don't think anyone is on it yet
<Chipaca> i can't upload, i don't think
<rsalveti> you should be able to
<rsalveti> you're part of ~snappy-dev
<Chipaca> Excellent.
 * Chipaca did not just do his mr burns impression
<rsalveti> I'll trigger another image once everything is there
<rsalveti> and hopefully we should have our first RC
<mterry> mvo, I saw your comment about helpers/, which I also helped make worse with my EnvVar stuff
<mterry> mvo, maybe we need a second "general" package
<Chipaca> mterry: what was the comment?
<mvo> mterry: yeah! or maybe I'm overthinking this, I'm not sure yet :)
<mterry> on lp:~sergiusens/snappy/YouShallNotPass merge, just saying a func maybe doesn't belong in helpers/
<mterry> Chipaca, ^
<mvo> but I would love to have a tiny bit more structure in helpers as its a bit of a misc/ dir right now and at some point it was meant to be stuff-missing-in-stdlib or something like that
<mterry> Chipaca, so wait.  About the go1.4 bug.  no workaround yet?  Should I just go back to 15.04 for testing?
<Chipaca> mterry: given the bug, yes, go back to 15.04
<Chipaca> especially as that's what we're releasing rsn :)
<Chipaca> mterry: or, compile snappy with 1.3 for W
<Chipaca> mterry: until we've sorted that one out
<mvo> rsalveti: once the workaround branch lands (assuming it gets a ok fromthe reviewers) we need to trigger the daily build for that branch, let me quickly search the url for that
<mterry> Chipaca, pfft, 15.04 is old hat, even if we are shipping a point release  :)
<Chipaca> go's "compatibility promise", on which they base not supporting releases for more than ~6 months, has bit us before now, so
<mvo> rsalveti: https://code.launchpad.net/~snappy-dev/+recipe/snappy-daily/ <- thats the page
 * mvo wishes we had git-dch for bzr or git so that it would auto-create the debian/changelog from the vcs comments
<rsalveti> mvo: awesome, thanks
<rsalveti> yeah
<rsalveti> Chipaca: can I just cross lp:~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/add-sync-calls and lp:~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/use-os-sync ?
<Chipaca> rsalveti: AIUI if you're asking, no
<Chipaca> rsalveti: mvo said he could do it, you told him you could and that he shouldn't be here
<Chipaca> rsalveti: or maybe i misunderstood
 * mvo is confused now ;)
<rsalveti> Chipaca: sorry, you said earlier that you tried merging jhunt's branches and got a 0 diff
 * rsalveti reads backlog
<mvo> yeah, the use-os-sync was merged but not uploaded, I uploaded that now to the ppa and to wily
<rsalveti> yeah, then all good
<rsalveti> crossing then
<mvo> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages should have the info looks like its indeed there
<rsalveti> awesome
<mvo> Chipaca: I need to buy you tea (or beer) for all the silly mistakes you need to endure in my branches, thanks a lot for spotting these issues
 * Chipaca blushes
<Chipaca> mvo: you've put up with a lot of nonsense in my branches, glad to be finally paying it back :D
<mvo> lol
<Chipaca> still have to learn to do reviews like yours though; almost makes me want to put more mps up just to get them :)
<Chipaca> ANYway, i should put down the computer and go wash the dishes and get the house ready for the night
<mvo> Chipaca: a more serious question about the oauth signing branch, you point out (correctly) that buf.Grow(len(inputString)*3) may be too small and I need to count the bytes. should I simply use len(s)*3 (quotes) *4 (utf-8 len) - or convert the str to bytes before checking the len?
<Chipaca> mvo: you're converting it to bytes anyway
<Chipaca> mvo: might as well do it earlier
<mvo> Chipaca: do that, I will call it a day soon too
<mvo> Chipaca: yeah, sounds sensible
<mvo> Chipaca: thanks a bunch
<mvo> rsalveti: its hopefully all prepared for the release-candidate, just ping me again if there is anything that needs work. I will keep a eye on my mail to see if my MPs get approved
<rsalveti> mvo: sure, thanks so much
<mvo> your welcome!
 * mvo &
<rsalveti> sergiusens: https://code.launchpad.net/~mvo/snappy/snappy-lp1460152-workaround/+merge/261144 would only work if the base image (stable) already had such changes, right?
<rsalveti> it seems our problem is that we'll be updating from stable to edge using the tools that are currently available at stable
<rsalveti> so it would only work after doing another update
<rsalveti> guess that's the usual problem of updating using the tools available from the older image (like we had with touch)
<rsalveti> added a comment to the MR (for lp:snappy)
#snappy 2015-06-05
<sergiusens> rsalveti: I need to download the full diff, but yeah, we need a systemd unit to do something on boot
<rsalveti> sergiusens: right, this change is just something post update
<sergiusens> mvo: mterry helpers to me feels like a drop zone for things that have no home yet; same for handler, helpers and handlerhelpers... but yeah, I wouldn't mind moving it but I don't want to affect Chipaca's big refactor
<sergiusens> affect or be affected
<rsalveti> sergiusens: do we have a way to get systemd units that would only be executed at first boot/after updates
<rsalveti> ?
<sergiusens> rsalveti: we would have to do the flag trick (like snappy firstboot)
<rsalveti> right
<rsalveti> seems to be the only remaining bug we have
<rsalveti> jdstrand: sergiusens: Chipaca: hm, installed image 78 (15.04/edge), clean, then webdm and tried to install a few snaps, but they are all failing
<rsalveti> Jun  5 05:08:14 localhost kernel: [   39.097383] audit: type=1400 audit(1433480894.752:22): apparmor="DENIED" operation="mkdir" profile="/usr/bin/ubuntu-core-launcher" name="/tmp/snaps/" pid=1024 comm="ubuntu-core-lau" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
<rsalveti> Jun  5 05:08:14 localhost kernel: [   39.117912] audit: type=1400 audit(1433480894.772:23): apparmor="DENIED" operation="capable" profile="snake.mectors_snake_0.0.5" pid=1024 comm="snakeweb" capability=12  capname="net_admin"
<rsalveti> xkcd-webserver.canonical gave package not found
<rsalveti> system-status.victor: failed to install: package name with namespace not supported
<rsalveti> xkcd-webserver installed fine via cmdline though
<rsalveti> this is not bug 1460152 since I didn't do any image update
<ubottu> bug 1460152 in Snappy 15.04 "apparmor cache not updated when apparmor.d rules change (breaks 15.04/stable -> 15.04/edge updates)" [Critical,In progress] https://launchpad.net/bugs/1460152
<miken> rsalveti: it's not related to bug 1460517 is it? (I created that last week, trying to get someone to check whether it's webdm or snappy itself setting those perms)
<ubottu> bug 1460517 in webdm "Cannot run other snaps after first installing webdm" [Undecided,New] https://launchpad.net/bugs/1460517
<rsalveti> miken: yeah, looks like it
<miken> Although, that was with stable.
<rsalveti> hm, will investigate a bit more tomorrow
<dholbach> good morning
<fgimenez> good morning
<zyga> good morning
<dholbach> is it possible to change channels within a core instance?
<elopio> rsalveti: sergiusens: I would like to get that snappy-merge-integration-tests merged first.
<elopio> the only thing that was missing from my review like two weeks ago was that it wanted to sign the deb.
<elopio> any idea how to get out from emergency mode?
<elopio> or how did I get into it
<elopio> I see: Welcome to emergency mode! After logging in, typroot@localhost:~#
<Chipaca> elopio: where? wha?
<JamesTait> Good morning, people! Happy Friday, and happy World Environment Day! ð
<elopio> Chipaca: my bbb was working two days ago. But today it went nuts.
<Chipaca> elopio: I don't think we have an emergency boot thing; that sounds like it's booting the debian
<Chipaca> our emergency boot thing is "boot the other one"
<elopio> Chipaca: without the sd card it boots to debian without problems.
<Chipaca> elopio: reflash the sd?
<Chipaca> elopio: get a new sd?
<elopio> Chipaca: I'm reflashing.
<Chipaca> elopio: have it exorcised?
<Chipaca> :)
<elopio> I see messages like:
<elopio> [   24.948063] FAT-fs (mmcblk0p1): IO charset iso8859-1 not found
<elopio> I'll just start all over again.
<ogra_> hmm
<Chipaca> ogra_: hmm?
<ogra_> Chipaca, i was wondering about http://paste.ubuntu.com/11584783/
<ogra_> (which i see on a really old RPi image here)
<Chipaca> ogra_: people have been getting those, and we looked into it a bit and got nowhere and blamed the sd card
<Chipaca> ogra_: tbh reflashing seems to fix it
<ogra_> yeah, i should stop using the expensive branded ones i guess :P
<Chipaca> ogra_: if it *isn't* the sd card feeling sorry for itself, i don't know
<ogra_> it doesnt seem to do any harm for a normal boot ... i'm juzst wondering what happens on upgrades if it goes readonly
<Chipaca> ogra_: only one way to find out
<ogra_> well, not really ... at least not on a RPi ... not sure the BBB exposes the same thing
<fgimenez> elopio, rsalveti i've just received the boards =)
<elopio> fgimenez: nice :)
<elopio> I've just ran the failed update on my beagle. Works fine here.
<fgimenez> elopio, good,  on kvm all seems to be fine too for rev 78
<fgimenez> elopio, i'm finishing some changes in the script to allow the delta upgrade from edge -1 to edge that mentioned sergiusens
<sergiusens> Chipaca: elopio ogra_ I was hoping that my fix to only right to the sdcard when necessary would alleviate this problem
<sergiusens> oh, the charset issue, there was an initramfs missmatch somewhere along the lines
<mattyw> afternoon everyone
<fgimenez> sergiusens, about the delta upgrades, they are only available from rev -1 to rev, right?
<ogra_> sergiusens, the above inst a charset issue ... it is actually bad filesystem blocks ... but as i said, the install is ancient
<fgimenez> elopio, the full upgrade path stable -> edge -1 (using script) -> edge (using snappy update) works fine too with the latest image in kvm
<sergiusens> ogra_: oh, that can be it
<sergiusens> fgimenez: rev -1 from the system running snappy's point of view is $version, so you should only be able to update to $version+n
<fgimenez> sergiusens, ok, i've added already the check to prevent updating to previous versions, i've also added code to download delta files if available for the current_version -> requested_version transition
<fgimenez> sergiusens, let me know what do you think https://code.launchpad.net/~fgimenez/+junk/system_upgrader
<jdstrand> rsalveti: capability net_admin is not allowed in any policy, so that is expected
<jdstrand> rsalveti: oh-- the core launcher policy has: /tmp/snap.*/ w,
<jdstrand> rsalveti: that does *not* match /tmp/snaps
<jdstrand> rsalveti: I believe miken is right about bug #1460517 and so I added information there
<nothal> Bug #1460517: Cannot run other snaps after first installing webdm <Snappy:New> <Snappy Launcher:New> <http://launchpad.net/bugs/1460517>
<ubottu> bug 1460517 in Snappy Launcher "Cannot run other snaps after first installing webdm" [Undecided,New] https://launchpad.net/bugs/1460517
 * jdstrand updated the description for bug #1460517
<mterry> How do I switch channels for snappy?  Like, say I wanted to go from rolling to 15.04/edge
<mterry> I would have assumed it's system-image-cli, but I recall hearing that doesn't work the same on snappy
 * mterry tries anyway
<kyrofa> beowulf, ping
<beowulf> kyrofa: pong
<kyrofa> beowulf, in order to test webdm, I used ubuntu-device-flash to create a rolling image
<kyrofa> beowulf, is it somehow automatically updated? Webdm, at least?
<beowulf> kyrofa: you'll get the latest released one from the store, or you can checkout and build it and get tip
<kyrofa> So when you release a new version to the store, I automatically get it?
<beowulf> kyrofa: good question, i'll have to refer you to sergiusens or someone who knows more
<beowulf> kyrofa: (i don't know about automatic updates)
<kyrofa> beowulf, the reason I ask: this morning I'm not able to get webdm to install anything
<beowulf> kyrofa: what was the error?
<kyrofa> beowulf: DEBUG: [/usr/bin/snappy internal-unpack /tmp/snaps/webdm/0.8/tmp/xkcd-webserver811585830 /apps/xkcd-webserver.canonical/0.5 /] failed: operation not supported
<kyrofa> beowulf, and webdm returns a 500
<kyrofa> beowulf, but it was working fine yesterday... so I'm confused
<rsalveti> jdstrand: nice, that seems to be it
<kyrofa> beowulf, the web interface seems to break too
<kyrofa> beowulf, stuck at installing 100%
<beowulf> kyrofa: yeah, that's a bug
<kyrofa> beowulf, then it prints "ERROR: xkcd-webserver.canonical failed to install: unpack /tmp/snaps/webdm/0.8/tmp/xkcd-webserver298198856 to /apps/xkcd-webserver.canonical/0.5 failed with exit status 1 "
<beowulf> kyrofa: the 500 causes that
<kyrofa> beowulf, you handle it better than the scope does :P
<beowulf> kyrofa: the bug is the install behaviour does nothing after the 500, so remains in whatever state it was before the 500, which is install progress 100% (which means the download happened and then we died)
<kyrofa> beowulf, can you verify that webdm is broken?
<beowulf> snappy tells webdm the error and webdm does the popup, but then should reset the button or something... basically i'm not sure what to do so have yet to fix it
<sergiusens> mterry: change channels.ini, the qa doc explains how to do it step by step
<beowulf> kyrofa: give me a sec to get a new image
<sergiusens> kyrofa: beowulf as soon as something updates you get the update
<kyrofa> sergiusens, good deal, so I'm not going insane
<sergiusens> rsalveti: I think your webdm broken on edge scenario is related to the core launcher changes
<rsalveti> right
<beowulf> kyrofa: so there you go, it was his fault *points at random person*
<sergiusens> rsalveti: jdstrand we are at a point where any change we make needs to work everywhere
<mterry> sergiusens, sorry but do you know where that qa doc lives?
<sergiusens> beowulf: kyrofa I'm guessing it's the latest changes to the core launcher that landed
<sergiusens> mterry: I will try and search my drive :-P
<sergiusens> mterry: yay, wasn't so hard https://docs.google.com/document/d/1R_Tw0N0QbEpjFeYf9XnVV8Gp8ldT2Ig0PO6MfR-kuSM/edit
<mterry> sergiusens, thank you!
<sergiusens> u r welcome!
<mterry> sergiusens, I ran "sudo system-image-cli --switch ubuntu-core/15.04/edge" which sat there for a while and finally exited with no message.  And didn't do anything
<mterry> sergiusens, seems like that should have worked  :-/
<kyrofa> sergiusens, alright, good to know. I'm happy to help in any way I can!
<mterry> or at least errored out
<jdstrand> sergiusens: that's fine... I think I am missing context. the rule change I gave in the bug doesn't remove anything, only add /tmp/snaps/
<jdstrand> sergiusens: therefore it should meet the criteria you just gave
<fgimenez> elopio, while trying to get the current installed version on kvm in my first attempt i copied code from ubuntu-ota-tests, the dbus client
<fgimenez> elopio, it fails trying to find com.canonical.SystemImage, do you know why?
<elopio> fgimenez: I don't. barry is your friend.
<longsleep> Hi folks, when running Ã`snappy update` it fails with `Unable to determine bootloder`. Any help? I am new to snappy, managed to build my own image though.
<sergiusens> mterry: you want to change channels.ini and then run snappy update
 * barry is everyone's friend
<mterry> sergiusens, yeah I figured it out and it's working now
<mterry> sergiusens, not friendly experience, having to remount and all that jazz
 * mterry wants s-i to work
<ogra_> heh, what for, it is going away
<sergiusens> jdstrand: good then, I was just going down the path something incompatible changing, but it seems the rule is incorrect; I'll propose an MP
<mterry> ogra_, well then I want its replacement to work  :)
<sergiusens> mterry: it's not friendly at all; but this is all influx now (channels and os/kernel updates)
<mterry> sergiusens, yeah I know.  humph
<sergiusens> mterry: the reason for the document to exist is its unfriendliness :-)
<ogra_> mterry, the replacement wont know about channels anymore :)
<mterry> ogra_, oh really?  What's the replacement?
<mterry> I heard s-i was on the outs but didn't hear what's new
<ogra_> mterry, snaps are the replacement
<fgimenez> elopio, ok :) barry, it seems that part of the code that we used in ubuntu-ota-tests doesn't work on snappy running in kvm, seems to be unable to find com.canonical.SystemImage
<ogra_> mterry, the whole image will come from the store in the future
<mterry> ogra_, ...  but channels still exist with snaps
<ogra_> assembled from snaps
<mterry> hm
<barry> fgimenez: you mean, it can't find the dbus service?
<fgimenez> barry, yes, wait, i'll paste the error
<sergiusens> longsleep: you are missing either a proper entry in the gadget snap (called oem in current releases), valid content in /boot/uboot or /boot/grub ... if you built your image manually make sure you have everything correctly
<sergiusens> ogra_: channels will be per snap; in a sense, we are splitting the concept of channel and release (and moving away from customization channel as well)
<longsleep> sergiusens: Thanks. Is there any way to debug this - i have put my image builder up at https://github.com/longsleep/snappy-odroidc - i would like to see it working 100%
<barry> fgimenez: i bet i know why, but do pastebin the error
<ogra_> sergiusens, right, so there wont be a way to switch
<ogra_> what you build from is your "channel"
<sergiusens> longsleep: I'm working on release activities so I can't help today, but maybe ogra_ can ;-)
<mterry> Where is the docker snappy packaging?
 * sergiusens tries to deflect ogra_ from asking hard questions
<sergiusens> or weird statements :-P
<longsleep> sergiusens: all right - thanks for the hints though :)
<ogra_> lol ... well, i'm up to my ears in the RPi2 image currently
<sergiusens> mterry: it's in snappy-hub somewhere
<mterry> awesome
<sergiusens> mterry: https://code.launchpad.net/~snappy-dev/snappy-hub/docker
<mterry> yup, thanks
 * mterry hugs sergiusens
<fgimenez> barry, here it is http://paste.ubuntu.com/11589316/
 * sergiusens hugs back
<longsleep> If anyone wants to take a look, https://github.com/longsleep/snappy-odroidc/blob/master/oem/meta/package.yaml, https://github.com/longsleep/snappy-odroidc/blob/master/device/hardware.yaml - feedback highly appreciated
<barry> fgimenez: does /usr/sbin/system-image-dbus exist?
<fgimenez> barry, nope, no system-image-* under /usr/sbin/
<barry> fgimenez: okay, so here's what i think is going on...
<barry> fgimenez: while system-image 3.0 was working its slow way to landing in the archive, mvo forked the project for snappy.  but he didn't need the dbus api so i believe the fork does not install system-image-dbus.  the -cli gained some additional functionality so that mvo wouldn't have to call into the dbus service, which he didn't like (he can give you rationale for that).  what i think needs to happen is to *un*fork si 3.0 for snappy,
<barry> and then install both the system-image-cli and system-image-dbus (and of course system-image-common) packages into the base os.  i think mvo agrees, at least with the unforking, but it hasn't been high enough on his list to get to yet.  si 3.0 is in wily now so there should be no blockers other than round tuits to doing the unfork
<longsleep> sergiusens, ogra_ : So valid content in /boot/uboot .. looks good to me "a b boot.ini snappy-system.txt"
<barry> well, maybe if you need si 3.0 in another channel, but it should be backportable
<ogra_> longsleep, http://people.canonical.com/~ogra/snappy/odroidc/ thats very old but i think the file contents in the device tarball should still be fine
<fgimenez> barry, ok thanks a lot, for now i think that we can go ahead with the current state, but we'll probably need si 3.0 sooner or later, what do you think elopio?
<barry> fgimenez: you'll definitely want si 3.0.  i guess when mvo gets back online we can talk about a plan to unfork
<longsleep> ogra_: Thanks - only difference to mine i see is that i am not using flashtool-assets and uEnv.txt (shipping boot.ini instead). Booting works, maybe the snappy tool checks on uEnv.txt on update or something?
<ogra_> longsleep, snapopy requites uEnv.txt in the right place (at least it did once) to recognize the system as booted from uBoot
<longsleep> ogra_: well it does not require it to boot - but maybe some tools check for it.
<ogra_> thats what i meant
<ogra_> snappy expects it
<longsleep> ogra_: So you think its worth a shot to ship an empty uEnv.txt and update might work?
<ogra_> longsleep, update of what exactly ?
<ogra_> snappy update ubuntu.-core cant work ... unless the image is on the official system-image server (i think at least)
<longsleep> ogra_: sorry - running 'snappy update' fails with Unable to determin bootloader
<ogra_> try: touch /boot/uboot/uEnv.txt
<ogra_> (well, with sudo)
<barry> fgimenez: maybe send an email to the relevant parties and we can discuss an unfork plan/schedule
<longsleep> ogra_: yeah that does something now
<longsleep> ogra_: soe somewhere seems to be a check for uEnv.txt
<ogra_> yes, as i said above
<longsleep> ogra_: Thanks for the help - i will add an empty one to the image builder for now.
<ogra_> <ogra_> longsleep, snapopy requites uEnv.txt in the right place (at least it did once) to recognize the system as booted from uBoot
<ogra_> ;)
<longsleep> ogra_: yeah - i got it now - you meant the 'snappy tool' - for me snappy was the whole system. Misunderstanding on my side sorry.
<ogra_> longsleep, lolo, no, bad naming on our side :)
<ogra_> *lol even
<ogra_> we just call everything snappy nowadays :)
<fgimenez> barry, ack, thanks!
<beuno> my dog responds to snappy now as well
<longsleep> ogra_: hehe i think things could be worse than that. Snappy is a nice word too - i like it.
<longsleep> ogra_: its at Applying update now - so things look good!
<ogra_> yay
<longsleep> ogra_: lets see if it reboots though :)
<ogra_> it should just ignore the uEnv.txt
<longsleep> ogra_: It booted just fine - awesome!
<ogra_> :D
<mattyw> dholbach, ping?
<dholbach> mattyw, pong
<mattyw> dholbach, hey there, just looking at your email about improving the snappy docs, I was about to submit a bug for a nitcpick, but I thought I'd ping instead
<dholbach> either way you like it
<mattyw> dholbach, the instructions for snappy-remote on this page https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/ states 8022 for the port to use in ssh, but that's only the port used when doing the redirecting described using the kvm image. I'd be tempted to state explicitly that the port would just be 22 if you were using it directly
<dholbach> ok, I'll file a bug
<dholbach> thanks for reporting
<dholbach> bug 1462408
<ubottu> bug 1462408 in Ubuntu Developer Portal "Correct snappy-remote port" [Undecided,New] https://launchpad.net/bugs/1462408
<mattyw> dholbach, it seems obvious, but there's a lot of new stuffy in snappy, it's nice to know that there are some things that aren't new :)
<mattyw> dholbach, thanks very much for listening :)
<dholbach> yeah... thanks a bunch for spotting it :)
<sergiusens> mattyw: dholbach more to the point, not putting a port defaults to 22
<elopio> fgimenez: yes, please send the email.
<elopio> fgimenez: sounds like remerging is important. And if mvo has reasons not to use the dbus api, maybe on the tests we should use the cli too. Lets wait for his reply about why...
<elopio> fgimenez: did you report any bugs from the exploratory testing?
<sergiusens> elopio: fgimenez no, we don't use the dbus api, we took great lengths to remove it
<sergiusens> elopio: fgimenez sorry, I forgot to mention that in the standup
<fgimenez> sergiusens, me too :) then, what should we use instead?
<sergiusens> fgimenez: system-image cli in json writer mode
<sergiusens> fgimenez: system-image-cli --machine-readable
<sergiusens> fgimenez: but I'm not sure what you want to do either
<fgimenez> sergiusens, yep, i've seen that through the code
<fgimenez> sergiusens, we have code we used for testing ota on touch, that relies in the dbus api  for querying and calling methods
<fgimenez> sergiusens, if we want to reuse some of that we need to adapt the calls to system-image-cli
<sergiusens> fgimenez: yes, I think you want that; in any case, I'm more worried about the core upgrader logic more than the s-i side of things
<sergiusens> fgimenez: as in testing the core upgrader (which just cares about the files being in the right place)
<sergiusens> fgimenez: also, if you use dbus, you won't be testing with what snappy uses at all
<fgimenez> sergiusens, ok thanks, of course the tests should exercise the real system as is, doesn't make sense use dbus then
<fgimenez> elopio, no more bugs from the exploratory testing, now i'm with the "write snappy app" document
<kyrofa> sergiusens, ping
<sergiusens> kyrofa: | pong
<rsalveti> fgimenez: great (just saw the message you got the boards)
<kyrofa> sergiusens, currently the webdm API doesn't contain any information regarding snap cost, so my scope currently has "FREE" hard-coded in. Does the store support non-free snaps?
<elopio> sergiusens: so, we are making the release today?
<sergiusens> kyrofa: non free snaps for snappy doesn't exist yet, we don't have an implementation in snappy (client) itself either
<sergiusens> kyrofa: we know what needs to be done though
<sergiusens> kyrofa: just needs to happen
<kyrofa> sergiusens, good deal, I just wanted to touch base on it
<fgimenez> rsalveti, yep :) i haven't put hands on them yet
<sergiusens> kyrofa: I guess that rest api needs some concept (planned at least to deal with this)
<kyrofa> sergiusens, good call
<elopio> fgimenez: /me tries the webcam appliance builder.
<fgimenez> elopio, ok, you may hit the apparmor issue about the /tmp/snaps/ directory
<rsalveti> elopio: we currently have 3 known blocking things for the release
<rsalveti> let me find the links
<rsalveti> https://bugs.launchpad.net/ubuntu-core-launcher/+bug/1460517
<ubottu> Ubuntu bug 1460517 in Snappy Launcher 15.04 "ubuntu-core-launcher apparmor denial when creating /tmp/snaps" [Undecided,New]
<rsalveti> https://bugs.launchpad.net/snappy/+bug/1460152
<ubottu> Ubuntu bug 1460152 in Snappy 15.04 "apparmor cache not updated when apparmor.d rules change (breaks 15.04/stable -> 15.04/edge updates)" [Critical,In progress]
<rsalveti> and investigate if we can land https://trello.com/c/YkdrYyX6/79-rootdelay-300-for-azure-images
<rsalveti> fgimenez: did you find any other major issue with latest image?
<fgimenez> rsalveti, nope so far
<rsalveti> fgimenez: I also built 2 extra armhf ones yesterday to align the image number, just to make it easier to identify the version
<rsalveti> great
<elopio> rsalveti: thanks, that's useful.
<elopio> rsalveti: do we need to do some testing on raspberrypi?
<rsalveti> elopio: not yet, we're waiting ogra_ to produce a newer image first
<fgimenez> leaving, have a nice weekend everyone o/
<sergiusens> rsalveti: given that https://code.launchpad.net/~mvo/ubuntu/vivid/ubuntu-core-config/lp1460152-workaround/+merge/261179 is an ubuntu package I will need your help
<sergiusens> rsalveti: but I approved it as it's working as expected
<rsalveti> sergiusens: sure
<rsalveti> sergiusens: I can take care of uploading that to our ppa
<rsalveti> and rolling/wily
<sergiusens> rsalveti: not sure what the procedure is here; since it is an ubuntu package does it require an SRU to merge?
<rsalveti> sergiusens: yeah, this is the udd branch
<rsalveti> I'll just upload to wily, then to our ppa and have another wi for next week to do SRUs for our PPA changes
<sergiusens> rsalveti: the origin is vivid but the target is trunk so it's all so confusing :-)
<Chipaca> back! sorry for this. How can I help?
 * Chipaca reads a bit of backlog
<sergiusens> Chipaca: sorry for what?
<Chipaca> sergiusens: being late back
<sergiusens> Chipaca: oh, not a problem :-)
<rsalveti> there are 2 main things now
<rsalveti> bug https://bugs.launchpad.net/ubuntu-core-launcher/+bug/1460517
<ubottu> Ubuntu bug 1460517 in Snappy Launcher 15.04 "ubuntu-core-launcher apparmor denial when creating /tmp/snaps" [Undecided,New]
<rsalveti> and https://trello.com/c/YkdrYyX6/79-rootdelay-300-for-azure-images
<sergiusens> rsalveti: yeah, going to propose the fix for the core launcher now
<rsalveti> if you flash latest, then install webdm and try to install snaps it will eventually fail
<rsalveti> great
<sergiusens> rsalveti: I bet eventually means after rebooting?
<rsalveti> sergiusens: don't remember if I rebooted or not
<sergiusens> Chipaca: want to take a look at the trello one?
<rsalveti> but can easily test again
<rsalveti> let me upload the other package and will give it a try
<sergiusens> rsalveti: I bet it's an ordering issue
<Chipaca> already looking
<rsalveti> right
<Chipaca> sergiusens: doesn't 15.04 have private /tmp with this update?
<Chipaca> sergiusens: https://bugs.launchpad.net/ubuntu-core-launcher/+bug/1460517 is about webdm creating /tmp/snaps without -m 01777, right?
<ubottu> Ubuntu bug 1460517 in Snappy Launcher 15.04 "ubuntu-core-launcher apparmor denial when creating /tmp/snaps" [Undecided,New]
<Chipaca> gah, dunno
<Chipaca> anyway, rootdelay. sure.
<Chipaca> rootdelay=300 according to the docs ask the kernel to wait 5 minutes before mounting root
<Chipaca> that seems excessive
<Chipaca> rootdelay=	[KNL] Delay (in seconds) to pause before attempting to
<Chipaca> 			mount the root filesystem
<sergiusens> rsalveti: with the new way for tmpdirs to be created, webdm and any other app should have independent paths
<sergiusens> Chipaca: yeah, we need to see if that can be added only for azure images
<sergiusens> Chipaca: either in u-d-f or in livecd-rootfs
<Chipaca> people really think waiting 5 minutes for a cloud image is reasonable?
 * Chipaca boggles
<rsalveti> utlemming: ^?
<rsalveti> 300 is indeed a lot
<Chipaca> rsalveti: you know you suck at this "taking the day off" thing, right?
<rsalveti> Chipaca: I'm doing that, not being a manager today :P
<rsalveti> but in reality just waiting to get off for lunch
<Chipaca> :)
<rsalveti> sergiusens: comparing core-launcher from wily and from our ppa, the only extra thing we have at wily is "Allow executing from /frameworks"
<rsalveti> sergiusens: is that wily only?
<sergiusens> rsalveti: that is wily only
<rsalveti> great
<sergiusens> rsalveti: until we decide to do a big backport ;-)
<rsalveti> right :-)
<Chipaca> jdstrand: once /tmp is a (private) bind mount, do apparmor rules apply to the path as the process "sees" it?
<Chipaca> if so, /tmp/ should be "do whatever"
<Chipaca> although you're talking about the launcher rules
<Chipaca> and the launcher is not the one mkdir'ing /tmp/snaps/
<Chipaca> jdstrand: either I am confused, or you are, or a linear combination of both
<jdstrand> Chipaca: this is for the laucnher
<Chipaca> jdstrand: right; the launcher doesn't mkdir /tmp/snaps; it mkdir's /tmp/snap.%d_%s_XXXXXX
<Chipaca> the "permission denied" for /tmp/snaps/ is for a pre-private-/tmp
<jdstrand> the launcher is trying to make /tmp/snaps
<Chipaca> is not :)
<jdstrand> the launcher that is causing that denial that is
<jdstrand> I don't know what launcher that is
<Chipaca> jdstrand: the thing that would mkdir /tmp/snaps was the wrapper, not the launcher
<Chipaca> unless you're saying there were actualy apparmor denies, it's just regular unix permissions
<Chipaca> because webdm would mkdir /tmp/snaps/ without setting it to 01777
<Chipaca> then anything after that would fail
<jdstrand> https://bugs.launchpad.net/snappy/+bug/1460517
<ubottu> Ubuntu bug 1460517 in Snappy Launcher 15.04 "ubuntu-core-launcher apparmor denial when creating /tmp/snaps" [Undecided,New]
<sergiusens> Chipaca: people are complaining that the latest webdm has these issues though
<sergiusens> Chipaca: and the latest webdm has 01777 in it
<jdstrand> meh, the denial isn't in the bug
 * jdstrand hunts it down
<Chipaca> sergiusens: if they didn't reboot after updating, the bug will still be there
<sergiusens> Chipaca: right, that could be it
<Chipaca> sergiusens: because (i presume) webdm doesn't clean up the old bug, just stops creating it
<jdstrand> this is the reported denial:
<jdstrand> Jun  3 11:20:10 localhost kernel: [  134.805380] audit: type=1400
<jdstrand> audit(1433330410.595:12): apparmor="DENIED" operation="mkdir"
<jdstrand> profile="/usr/bin/ubuntu-core-launcher" name="/tmp/snaps/" pid=895
<jdstrand> comm="ubuntu-core-lau" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
<Chipaca> however
<jdstrand> profile="/usr/bin/ubuntu-core-launcher"
<Chipaca> the new launcher, with private /tmp/, should make it all just go away
<rsalveti> failing
<rsalveti> <rsalveti> Jun  5 05:08:14 localhost kernel: [   39.097383] audit: type=1400 audit(1433480894.752:22): apparmor="DENIED" operation="mkdir" profile="/usr/bin/ubuntu-core-launcher" name="/tmp/snaps/" pid=1024 comm="ubuntu-core-lau" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
<rsalveti> what I had earlier today
<jdstrand> also, profile="/usr/bin/ubuntu-core-launcher"
<sergiusens> Chipaca: jdstrand on edge I don't see this issue and my tmp's are /tmp/snap.0_hello-dbus-fwk_JuFKMH snap.0_snake.mectors_Dfz11P
<sergiusens> no /tmp/snaps/ at all
<rsalveti> the bug I had was on a clean image
<rsalveti> just installed some snaps, then installed webdm, then tried to install additional snaps from the webdm interface
<rsalveti> I did reboot once, just don't remember exactly when
<sergiusens> rsalveti: are you perhaps mixing up bugs?
<Chipaca> rsalveti: what versions of everything?
<rsalveti> let me try to reproduce again
<sergiusens> rsalveti: there is no /tmp/snaps on edge
<rsalveti> image 78
<rsalveti> that was the denial I had
<rsalveti> but anyway, let me try reproducing it
<Chipaca> sergiusens: well, well. well.
<sergiusens> Chipaca: what did I do now? :(
<Chipaca> there *is* a /tmp/snaps, *if* apparmor sees it as from "inside"
<Chipaca> that is: the launcher mounts a private /tmp/ and then creates /tmp/snaps inside that
<Chipaca> this is after dropping privs, fwiw
<Chipaca> so if we're seeing DENIEDs with the new code, that's why
<Chipaca> (face. desk. etc.)
<sergiusens> Chipaca: but that's up to the profile of the snappy package itself, not the core launcher
<Chipaca> no, this is still in the launcher
<sergiusens> Chipaca: so we need to allow for both
<Chipaca> before the aa_change_onexec call even
<Chipaca> sergiusens: which is what jdstrand said
<Chipaca> man, he's so ahead of us, he should buy us beer
<sergiusens> Chipaca: so this is good /tmp/snap{s,.*}/ w,
<jdstrand> wait, if I'm ahead, why am I buying beer?
<jdstrand> :P
<Chipaca> jdstrand: you arrived at the bar first
<rsalveti> lol
<jdstrand> ah
<jdstrand> I figured you'd buy my beer since I patiently waited for you
<jdstrand> :)
<rsalveti> 32.40 KB/s from the store
<ogra_> did someone mention free beer ?
<rsalveti> annoying
<Chipaca> ogra_: that's what i heard
 * ogra_ thought he got a highlight
<Chipaca> sergiusens: in case an answer was necessary: yes, that should be perfect
<sergiusens> Chipaca: https://code.launchpad.net/~sergiusens/ubuntu-core-launcher/tmpmor/+merge/261252
<sergiusens> there then
<jdstrand> sergiusens, Chipaca: thanks for taking care of this
<Chipaca> sergiusens: there ya go
 * rsalveti kicks the store
<sergiusens> Chipaca: heh, tarmac chose to go nuts :/
<jdstrand> sergiusens: with that merge, what is TMPDIR set to? and, are apps able to write to it?
<jdstrand> sergiusens: I'm thinking 'no' and there will need to be a corresponding ubuntu-core-security update
<sergiusens> jdstrand: http://paste.ubuntu.com/11591737/
<sergiusens> jdstrand: wrt to this whole movement, Chipaca and tyhicks where managing it
<Chipaca> jdstrand: i think u-c-security still has /tmp/snaps/app.origin/tmp/
<Chipaca> jdstrand: and AIUI that will work
<jdstrand> Chipaca: it for sure does
<Chipaca> jdstrand: we could/should drop it to all of /tmp/ later down th eline
<Chipaca> jdstrand: but, baby steps
<jdstrand> ah
<jdstrand> that was the bit I was missing
<Chipaca> the whole idea of making the old tmp was to not have to do the update in lockstep
<jdstrand> ok, no I am catching up :)
<jdstrand> see, this little game we are playing is fun
<jdstrand> gotcha
 * Chipaca never likes it when security people talk about "game" and "fun"
<jdstrand> so, we need a policy update whenever we set TMPDIR to /tmp
<Chipaca> s/whenever/before/
<Chipaca> :)
<jdstrand> yeah
<jdstrand> :)
<jdstrand> let me know when you are working on that :)
 * Chipaca 'll try
<elopio> ok, I'm tired. I'll EOD.
<rsalveti> Jun  5 16:58:21 localhost kernel: [  865.945352] audit: type=1400 audit(1433523501.755:19): apparmor="DENIED" operation="mkdir" profile="/usr/bin/ubuntu-core-launcher" name="/tmp/snaps/" pid=4059 comm="ubuntu-core-lau" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
<elopio> will check back later, and continue testing on monday.
<rsalveti> jdstrand: Chipaca: sergiusens: when trying to install snake from webdm
<elopio> enjoy your day.
<jdstrand> yes
<jdstrand> rsalveti: yes
<rsalveti> first boot -> installed webdm -> from webdm tried to install snake
<rsalveti> but it installed fine
<jdstrand> rsalveti: the launcher is creating /tmp/snaps inside the private mount before the change profile
<rsalveti> right
<jdstrand> rsalveti: so we need the fix. sergiusens did an MP and it is moving forward now
<rsalveti> yeah, makes sense now
 * rsalveti is still getting used with all this
<rsalveti> but this is so freaking awesome
<rsalveti> elopio: have a nice weekend!
<rsalveti> Jun  5 17:03:38 localhost ubuntu-core-launcher[703]: 2015-06-05 17:03:38 ERROR snappy logger.go:199 system-status.victor failed to install: package name with namespace not supported
<elopio> you too.
<rsalveti> namespace?
<sergiusens> rsalveti: if it's a framework, it's not allowed
<sergiusens> if not, not sure
<rsalveti> it's not a framework
<sergiusens> rsalveti: that package has a dot in it's package name most likely
<rsalveti> hm, right
<jdstrand> mterry: fyi, I don't recall if I mentioned it, but inotify_* calls were add to wily and 15.04/edge some time ago
<rsalveti> wonder if we should have any sort of store validation
<rsalveti> to see if the user can at least install it
<mterry> jdstrand, oh nice...
<rsalveti> having broken snaps in there is kind of annoying
<sergiusens> rsalveti: it shouldn't be there if so, maybe beuno knows
<jdstrand> note, the new review tools are going to show an error if there is a dot in the yaml 'name' field
<jdstrand> of course, I got totally sidetracked from them this week (unfortunately)
<sergiusens> rsalveti: care to do some dputting for https://code.launchpad.net/~snappy-dev/ubuntu-core-launcher/trunk ?
<rsalveti> sergiusens: sure
 * sergiusens takes advantage of rsalveti's dput service :-)
<beuno> rsalveti, sergiusens, what what?
<rsalveti> beuno: system-status.victor snap is failing to even install
<rsalveti> but it's available in the store
<rsalveti> so was wondering about ways to validate that before even making it available in there
<beuno> rsalveti, I don't think you get to control what crazy stuff people put in the store
<beuno> :)
<rsalveti> beuno: that's fine, but we can do some sort of validation
<rsalveti> beuno: if it fails to even install
<rsalveti> why should we publish it?
<beuno> rsalveti, we just run the review scripts
<beuno> those don't try to install
<rsalveti> right, then what jdstrand said should fix it at least
<rsalveti> for this case
<beuno> that's a heavy-weight process, I think, trying to install
<beuno> we can, and I'm sure we will
<beuno> but it's not trivial
<rsalveti> right, later as part of CI and so on
<beuno> no, not CI at all
<beuno> people will upload random broken stuff that they won't pay for CI
<rsalveti> sure, in this case, yes
<rsalveti> guess channels will at least help
<beuno> so you probably want ratings and reviews as part of this soon
<beuno> so people can give feedback to the developer
<rsalveti> yup
<beuno> and hit at others that it's broken
<rsalveti> sergiusens: will you propose an MR for https://code.launchpad.net/~snappy-dev/ubuntu-core-launcher/15.04 as well?
<rsalveti> ubuntu-core-config and ubuntu-core-launcher uploaded to wily
<rsalveti> core-config also uploaded to our ppa
<rsalveti> just missing core-launcher
<sergiusens> rsalveti: ah, got it
<rsalveti> sergiusens: I can create it
<rsalveti> the mr
<rsalveti> sergiusens: Chipaca: https://code.launchpad.net/~rsalveti/ubuntu-core-launcher/15.04-tmpmor/+merge/261254
<rsalveti> similar to https://code.launchpad.net/~sergiusens/ubuntu-core-launcher/tmpmor/+merge/261252
<rsalveti> if all good I can upload that and trigger a new image
<sergiusens> rsalveti: oh, I just created the same :-P
<Chipaca> rsalveti: I approve.
<Chipaca> sergiusens: go have lunch
<sergiusens> yay
<rsalveti> yeah, thought you were having lunch already :-)
 * sergiusens will go have lunch
<rsalveti> Chipaca: thanks
<rsalveti> Chipaca: do we have auto-merge and so on for this guy?
<sergiusens> rsalveti: Chipaca I just set it up
<rsalveti> great
<jdstrand> rsalveti: heh, I was going through irc trying to see where I wrote up my suggestions on a tutorial for creating/debugging snaps and I only just now saw you asked me to dump the info in https://wiki.ubuntu.com/Snappy/ somewhere. I did so now: https://wiki.ubuntu.com/Snappy/Debugging
<jdstrand> rsalveti: the other day I wanted to give this to dholbach and the docs team, but now thinking it needs a card. what is your opinion?
<zyga> can snapps publish systemd units (e.g. a timer unit)
<zyga> or in other words, how do I write a simple snap that does something every $interval
<zyga> just loop manually
<zyga> or is there a better way?
<Chipaca> zyga: we don't expose an easy way for that
<Chipaca> zyga: the systemd unit we create for services has some hooks, but nothing that you could use as a timer afaik
<zyga> Chipaca: ok, so if I write a program that just waits by itself
<jdstrand> rsalveti: oh, I didn't realize you were off-- please ignore me here and check your inbox on monday :)
<zyga> Chipaca: and it crashes
<zyga> Chipaca: does snappy restart it via the unit?
<Chipaca> zyga: if it's a service, systemd should take care of that yes
<zyga> rsalveti: https://git.launchpad.net/~zyga/+git/pmr/tree/process-merge-requests
<zyga> Chipaca: cool, thanks
<Chipaca> zyga: what does a timer unit look like?
<zyga> rsalveti: very early stuff, tarmac will be my target next week
<Chipaca> maybe we want to expose that
<zyga> Chipaca: it's a cron replacement unit, let me give you a link
<zyga> Chipaca: http://www.freedesktop.org/software/systemd/man/systemd.timer.html
<zyga> Chipaca: it has some nice features
<Chipaca> ah, so systemd.timer(5)
<Chipaca> nice
<zyga> Chipaca: e.g. I'd love to be able to wake the machine up from suspend to do nightly maintenance
<Chipaca> zyga: that'd be cool, there are lots of things that could use this
<Chipaca> zyga: something for our architects :)
<zyga> yep
 * Chipaca resisting to ad-hoc it now that there are people in charge of not ad-hocing stuff
<Chipaca> zyga: want to drop a card in the "incoming proposals" on the trello?
<Chipaca> zyga: https://trello.com/b/4PQViyUQ/snappy-core-stakeholders-backlog
<zyga> Chipaca: wow, gladly
<Chipaca> personal will be needing this anyway
<Chipaca> i've got to go make dinner; sergiusens, will bbl to carry on with the webcam thing
<zyga> Chipaca: I cannot add anything to the board there, sorry
<sergiusens> Chipaca: fwiw, snappy autopilot is a systemd timer unit
<sergiusens> rsalveti: did you trigger a build?
<hokkos> where is the package list of ubuntu snappy core ?
<kgunn> question on uploading a snap to the store....the country thing is confusing, it says pick countries you don't want to distribute in, pick countries to only distribute in...
<kgunn> does that mean there's a default if you don't select anythnig ? and what is that default ?
<kgunn> beuno: ^
<beuno> kgunn, default, I think, is everything
<kgunn> k
<kgunn> mterry: you still about ?
<kgunn> was just curious about the 2 yaml files in mir, i get the mir-demo one...but i guess the second has me wondering
<kgunn> chat on monday i suppose
#snappy 2015-06-06
<rsalveti> sergiusens: yup, there should be a new image with the core changes
<longsleep> Hi folks, quick question - how does one submit OEM packages to the Snappy store?
<beuno> longsleep, same as any other package
<beuno> but it'll get sent to a manual review queue
<longsleep> beuno: All right, i figured that - i was just confused that i could not select OEM or something. It is in review now.
<longsleep> beuno: What about device tarballs, these are not to be supposed to be added to the store i figured. Seems a little strange to me though as not devices might not work with standard kernel.
<beuno> longsleep, all pieces will be snap pacakges soon  :)
<longsleep> beuno: Really? Is there some doc i can read on this?
#snappy 2016-06-06
<didrocks> good morning!
<noizer> Hi guys
<noizer> I have just a question for my boss. when will Snappy be released on the raspberry pi 3?
<jamiebennett> Hi noizer, you can roll your own image today using our tools. There was a post about this recently on the mailing list - https://lists.ubuntu.com/archives/snapcraft/2016-May/000021.html
<jamiebennett> noizer: Official images will come later
<noizer> jamiebennett: But is it officialy released because its to know when we can go in production
<jamiebennett> noizer: Official releases are not available yet, we are still working on solidifying the apis
<noizer> But i just needs a average date (month) when it will be official
<jamiebennett> noizer: At the moment we are still putting a lot into the images. Something more stable will be available at the end of the month but we will continue to work on them beyond that.
<jamiebennett> noizer: What is the device you are taking to production?
<jamiebennett> noizer: Feel free to shoot me an email if you want to discuss specifics
<jamiebennett> jamie.bennett@canonical.com
<wligtenberg> Hi, I have created a snap, from a package. I have installed it, but how do I run it? (I also have the same application installed normally on my system)
<wligtenberg> Do I run it by the name of the snap, or the exported command, or the name of the application in apps: ... (in the snapcraft.yaml)?
<gouchi> wligtenberg: according to the article app.command https://developer.ubuntu.com/en/desktop/examples
<matteo> hi
<davidcalle> gouchi: wligtenberg , one thing that's not mentioned yet on this doc: if "app"=="command", you only need to run app, to run the app.command.
<wligtenberg> davidcalle, thanks that is where I got confused.
<wligtenberg> It is running the right command now, but that currently has an issue. Thanks!
<davidcalle> wligtenberg: np :)
<gouchi> davidcalle: thank you for the info
<_morphis> jdstrand: ping
<ogra_> pitti, i'm poking around with locales in snaps since the weekend ... do you have an idea why http://paste.ubuntu.com/16925059/ works in trusty but not in xenial (doesnt seem like the bindtextdomain function changed in gettext, so i dont get why it stopped working)
<jdstrand> _morphis: hi!
<_morphis> jdstrand: you had time to get the modem-manager interface another review round?
<pitti> ogra_: not off the top of my head; xenial has a much newer glibc version, perhaps LOCALEDIR doesn't exist any more? it doesn't appear in strings libc.so.6 at least
<jdstrand> _morphis: oh, I thought we were waiting on the ppp interface... is there more for me to review as it stands?
<_morphis> abeato: as I said, deadlock :-)
<ogra_> pitti, well, the preloading of the bindtextdomain.so binary should simplay add it
<_morphis> jdstrand: abeato is currently adding that but can you look at the other parts already?
<ogra_> it replaces the gettext function dues to the perloading
<pitti> ah, it's from that
<ogra_> *pre
<jdstrand> _morphis: ok
 * ogra_ glares at his fingers 
<_morphis> jdstrand: thanks
<jdstrand> mvo: hi! iirc, you marked snapd 2.0.6 as verification-failed (for the systemd timer issue I think)
<jdstrand> mvo: I don't believe 2.0.6 had home autoconnect in place (at least, I didn't see it in the changelog)
<jdstrand> mvo: not sure what your plan was for the next xenial upload, but whatever it is, can you include the home autoconnect commit?
<jdstrand> niemeyer_: fyi ^
<mvo> jdstrand: the plan is to do a new 2.0.7 today that fixes the systemd unit and also fixes an issue with nvidia
<jdstrand> mvo: cool, so that sounds like it will have the commit since it was in last week. thanks! :)
<mvo> jdstrand: yeah, once I get my two bugfix branches in I'm ready to release
<niemeyer_> jdstrand, mvo: +1
<mvo> jdstrand: do you remember if there was a bug associcated with home autoconnect
<jdstrand> mvo: I don't think so. let me check something though
<mvo> jdstrand: ta
<jdstrand> ah there was
<jdstrand> mvo: bug 1588886
<ubottu> bug 1588886 in Snappy "no indication that a user needs to connect the home Plug to the home Slot to make a snap access files in the homedir" [High,Fix committed] https://launchpad.net/bugs/1588886
<mvo> jdstrand: \o/
<didrocks> sergiusens: elopio: hey! I guess you saw that I fixed the unit tests btw!
<elopio> didrocks: haven't seen that yet, but yay. I'll take a look after the meeting.
<sergiusens> didrocks yes, I'm still trying to get an archive admin to accept 2.10 into xenial-proposed though (I am a one thread person) :-P
<didrocks> sergiusens: one thread? so much disappointment :)
<ysionneau> Hi
<sergiusens> didrocks yes, bureaucracy makes me go single thread ;-)
<sergiusens> didrocks thanks btw
<ysionneau> I'm trying to use "kernel-initrd-firmware" for kernel snaps
<ysionneau> tldr: the firmwares do not end up being embedded in initrd
<didrocks> sergiusens: yw! :-)
<ogra_> ysionneau, siunds like a bug in the kernel plugin
<ogra_> ysionneau, why do you need the firmware in the initrd though ... the initrd should only make sure you find your rootfs
<ysionneau> http://pastebin.com/zV2Q8i31 <=
<ogra_> do you actually need any extra firmware for your disk controller ?
<ysionneau> ogra_: my kernel seems to need the usb host controller FW very early
<ysionneau> it doesn't work if it's in the rootfs
<ysionneau> it works when it'sin the initrd
<ysionneau> that's what we do on our proprietary firmware
<ysionneau> s/on/in.
<ogra_> hmm
<sergiusens> ysionneau this should just work, have you seen my 96boards example?
<ogra_> well, first of all, file a bug ...
<ogra_> looking at your paste it seems that some fw is actually installed
<ysionneau> yes
<ysionneau> I added some print() for shutil.copy
<ysionneau> it's copied somewhere, but definetely not in the initrd
<ysionneau> btw, the snapcraft.yaml http://pastebin.com/baN37dPF
<ysionneau> maybe I should just stop using kernel-initrd-firmware and use the tar or copy plugin like sergiusens in 96boards ?
<sergiusens> ysionneau all it does is select firmware already built and puts it in initrd
<ogra_> sergiusens, but does it copy full paths ?
<ysionneau> weird because I've used the correct relative path and it does not end up in initrd
<ogra_> looks like ysionneau tries that in his snapcraft.yaml
<sergiusens> ogra_ not full paths
<ogra_> right, thats what i thought
<ysionneau> ah, ok I guess I understand, because of my ../../.. prefix, the fw don't end up in the correct destination directory
<ysionneau> and don't get embedded
<ysionneau> right?
<netphreak> Hi, guys! when is snapd 2.0.6 ready for test?
<sergiusens> ysionneau it should be relative to the part's installdir
<ysionneau> sergiusens: I mean, my path is indeed a relative one, and it is indeed pointing to the correct files
<ysionneau> so I should be OK
<ysionneau> but I'm not :o
<sergiusens> ysionneau yeah, relative as in 'firmware/bcm43602'
<ysionneau> and by reading the code I understand why : https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/plugins/kernel.py#L248
<ysionneau> by looking at how dst is constructed
<sergiusens> ysionneau or else we need to introduce a new key to say source->destination
<sergiusens> ysionneau right now it is implied for the path in that list and that is where it lands
<ysionneau> should I file a bug? or am I just doing things not supposed to work at all?
<sergiusens> ysionneau you can log a bug if you manage to tell me how that firmware file is supposed to make it in initrd into the correct path within initrd
<sergiusens> ysionneau I would use the organize keyword I guess
<sergiusens> ysionneau or is this unmanaged source?
<sergiusens> th organize keyword seems to be the way to go
<alm_> why am i SOL with my PI 3 without a 64bit ARM?
<ogra_> "SOL" ?
<alm_> Sh*t Outof Luck
<dougb> Hello All--On BeagleBone Black, only ttyO0, the console serial, is enabled. How do I enable the other available serial ports in Snappy?
<ysionneau> sergiusens: I honestly don't know, or maybe by using the "copy plugin" like syntax
<ogra_> alm_, the only arm64 builds we have today are for the 96boards dragonboard ... and afaik not even broadcom plans to actually support arm64 on the pi3, you can use ubuntu-device-flash to roll armhf pi3 images today though
<ysionneau> ogra_: you want to use arm64 kernel + armhf user space ? :)
<ogra_> ysionneau, what would be the benefit of that ?
<sergiusens> ysionneau we want to kill the copy plugin syntax in favor of organize
<ysionneau> sergiusens: I don't know what that is :/
<ogra_> sergiusens, but everybody *loves* the copy plugin !
<sergiusens> ysionneau it shuffles bits around
<sergiusens> ogra_ the plugin is staying, the syntax is going to be deprecated
<ogra_> (just teasing ;) )
<alm_> yes and no - i need to install apache Cassandra db and found it challenging to say the least. Someone told me that i have to wait for a new kernel to be compiled for armel
<elopio> fgimenez: can we skip today?
<ysionneau> ogra_: dunno, rpi3 comes with armhf kernel when you buy it?
<ogra_> ysionneau, i think so, yes
<fgimenez> elopio, sure, np
<elopio> thanks.
<ogra_> ysionneau, the only area where arm64 would actually be helpful would be if you have >3GB RAM really ...
<ogra_> or if you have to use binary blob drivers that are arm64 only ...
<ogra_> effectively 64bit binaries will be bigger and consumke more ram though ... so it is only helpful if you actually *have* more ram :)
<ogra_> (armhf can handle up to 3GB just fine)
<alm_> yes i see the point about ram..and since i don't have the >3GB..but i have been trying for 2 weeks to get it working trying every distro and ugh
<ysionneau> so far we only compile our nvidia kernel as arm64, never tested as armhf
<ysionneau> dunno if it even works :o
<ysionneau> it's not upstream, it's nvidia code release
<ysionneau> so most likely crappy code
<ogra_> i dont think the kernel cares actually
<ysionneau> if the nvidia SoC device code is not 64/32 bit proof I guess you can have surprises
<ogra_> your userspace would fall over if you tried arm64 on an armhf only kernel, but never the other way round
<ysionneau> note, I'm only talking about kernel here
<ogra_> right, whatever gets you booting :)
<ysionneau> I know that I can use armhf user space, that's what I'm using in fact
<ysionneau> but i'm just saying I never tried an armhf-toolchain compiled kernel on my 64 bit soc
<ogra_> :)
<alm_> going to try one more time tonight -  and try snappy core - see if works
<ogra_> well, i dont think tegh kernel is actually picky in any way in that regard
<ogra_> alm_, well, there is no arm64 for the pi3 in snappy ... so you will have to live with armhf
<alm_> ya that's the trouble
 * ogra_ doesnt get why 
<alm_> cause everytime i go to install says will not support the arch
<ogra_> "go to install"
<ogra_> what exactly do you try to install ?
<ysionneau> alm_: do you use an arm64 kernel snap with an armhf ubuntu-core with ubuntu-device-flash ?
<alm_> yes - ysionneau - i dl from ubuntu..dont have all the info here as i am at work
<alm_> orga - the apache cassandra db
<ysionneau> alm_: please, paste what you're doing, with the error message
<ogra_> well, you would have to create snap packages of that first if you want to use it under snappy
<ogra_> an armhf image that can run on the pi3 is at http://people.canonical.com/~mvo/all-snaps/rpi2-all-snap.img.xz
<ogra_> just uncompress it and dd it to an SD card ... then boot the board
<ogra_> (ignore the pi2 in the name, it runs fine on the pi3)
<ogra_> but then youz will still need to produce a cassandra/apache snap package for it to use it
<ogra_> (there is no apt or dpkg in snappy)
<alm_> dont have error or would post..somthing like can not find armhf arch..
<alm_> thanks for this though..got to go
<ogra_> just come back again if you sit near the board :)
<ogra_> ah ... there he goes
<ysionneau> sergiusens: so, I guess that if I use this https://github.com/ubuntu-core/snapcraft/blob/master/demos/96boards-kernel/snapcraft.yaml#L29 , it won't end up in initrd, right? :(
<sergiusens> ysionneau no it would not
<ysionneau> hmmm maybe I can just copy my firmware directory inside linux-x1/firmware
<ysionneau> and use the normal kernel fw mechanism
<sergiusens> elopio you are not on #ubuntu-release
<elopio> I didn't know that was a thing.
<ogra_> ysionneau, well, i think "kernel-initrd-firmware:" will just work if you give it the right options (full path to .bin files instead of declaring directories)
<ogra_> your issue is simply that you dont define the files but directories
<ysionneau> ogra_: hmmm I don't think so, I've just tried, it does the same
<ysionneau> the ../../.. prefix makes my file end up out of the initrd-staging directory
<ysionneau> here is the os.link log :
<ysionneau> os.link(/home/fallen/dev/packages/paros_kernel/parts/kernel/install/../../../firmware/tegra21x_xusb_firmware, /home/fallen/dev/packages/paros_kernel/parts/kernel/build/initrd-staging/../../../firmware/tegra21x_xusb_firmware)
<ogra_> ysionneau, and tegra21x_xusb_firmware is actually a file ?
<ogra_> also, where exactly  does the firmware end up in your kernel snap (default path is /lib/firmware)
<ysionneau> ogra_: yes
<ysionneau> right now, the fw does not end up at all in the kernel snap
<gnosys> hi all
<gnosys> looking for a good discussion of environment variable configuration in the snapcraft.yaml file
<gnosys> trying to work on building a snap for gimp-git as an alternative to the gimp-edge ppa
<sethj> mhall119, is the snappy playpen today or tomorrow? The blog post says tomorrow, but the Google calendar on the G+ post you shared says today.
<mhall119> sethj: it is tomorrow
<mhall119> the calendar might be having timezone fun
<sethj> Okay. Probably can't make it then :/
<sethj> mhall119, hah, must be. Although how it made that jump is beyond me.
<mhall119> hmm, it shows today for me too
<mhall119> I wonder if dholbach set it for midnight his time
<mhall119> is CET UTC+2?
<mhall119> yeah, I bet that's it
<mhall119> sethj: what time does it show for you?
<sethj> mhall119, June 6th, 1500.
<mhall119> it shows 6pm today for me, which is 0:00 CEST
<sethj> I'm in GMT-8 (or -7, I can't remember 'cause DST)
<mhall119> yeah, that looks to be what's happening
<rharper> if one wanted to grant a snap access to a system dir in say var, is there a way to express that in snapcraft.yaml ?  any examples would be helpful to this snapcraft noob
<sethj> rharper, sounds like a job for an interface, but you might have to write your own. Take a read through zyga's nice 3 part blog series on them: Zygmunt Krynicki
<sethj> oops, copy paste fail. Here's the link: http://www.zygoon.pl/2016/04/snappy-snapcraft-and-interfaces.html
<rharper> sethj: cool, I'll give that a read and see how far I get
<rharper> sethj: thanks, I think the key for me was --devmode runs complain mode, but won't help a user do let's say root things.  for example, I'll looking to read/write to a var dir which is owned by the system;  are there any plans to work on an interface for those sorts of things?
<sergiusens> rharper there is a content sharing interface in the pipeline, kyrofa I think will be working on it
<sergiusens> rharper but I am not so sure this is intended for "writing"
<rharper> right; I guess this would be more a long the lines of say firewall-control which would delegate some system level config to a trusted snap
<kyrofa> sergiusens, rharper indeed, I agree, I'm not sure on the writing aspect, though it's not yet been spec'd
<sergiusens> rharper then the matter gets interesting as in, are you looking into writing to a classic system (desktop) or the core snap itself
<rharper> sergiusens: I'm playing around with cloud-init; which is already part of the os snap IIUC, which runs and inits some stuff;  if it were to run as a snap and called via hooks, then it would be confined as a snap rather than running in the system
<rharper> so I'm trying to poke on the various points in the system that cloud-init would like to (as it's current written) to muck with etc.  all to help tease out which sorts of interfaces we might want to have for other "system config" style snaps that would have hooks called
<sergiusens> rharper so cloud-init as a snap to run on a regular server install is what you are trying to do?
<rharper> sergiusens: yeah, for now;
<rharper> http://paste.ubuntu.com/17065056/ is as far as it goes, which runs into non-root wanting to poke at /var/lib/cloud/data
<sergiusens> rharper if this is to get the seeds in place, have you considered being able to provide an alternate path for that?
<rharper> cloud-init expects to run as root
<rharper> sergiusens: that's possible, the cloud-init code owns that path but it could be changed if needed;
<sergiusens> it can run as root, well, at least it believes it does, we're are slowly making our ways to the "root" role solaris once had
<rharper> interesting
<sergiusens> rharper if it can check for $SNAP_DATA it would be free to dump anything there
<rharper> sergiusens: right;  I think the integration might need to be deeper than that;  rather, think of this as a gadget or os snap delegating configuration control to this snap;  the data it generates likely wants to be retained in the gadget or os snap independent of the delegated snap itself
<rharper> for example if you wanted to switch out the snap that runs the delegated hook for "configure networking" or whatever that hook may be
<sergiusens> rharper yeah, that I cannot answer as lightly as the previous question :-)
<sergiusens> rharper there's an interface for snapd management which could hook you into all that but I am far away from that problem space these days
<rharper> yeah; I didn't expect there is an answer yet;  I suppose next I'm wondering how much further one can explore on the snap app side
<sergiusens> rharper I think Chipaca should be your goto person there, but he's off for today to bbq some meat I've been told
<rharper> mmm, bbq
<rharper> best excuse ever
<sgclark> Hi all. I am making good progress on kde snaps, but I am haing issues with apparmor failures and home plug. Is there some good doc on how plugs actually work? I was under the impression home plug would allow acces the /home/user but that does not appear to be case.
<sergiusens> sgclark it does indeed allow access to $HOME
<sergiusens> sgclark what it doesn't do today but should be added soon is autoconnection
<sergiusens> sgclark you can run `snap interfaces` to see what is currently connected
<sgclark> ahh ok.
<sergiusens> then just run `<snap>:<plug> <snap>:<slot>`
<sgclark> it seems to create a snap directory in home but like for example digikam cannot access Pictures in home so I am confused
<sergiusens> err `snap connect ...`
<sgclark> ok
<sergiusens> sgclark yeah, it is rather confusing, the only thing the app can see by default now (without home) is $HOME/snaps/<snap-name>/<snap-revision>
<kyrofa> sgclark, that $HOME/snaps/<snapname>/<revision> directory is the $SNAP_USER_DATA environment variable for the snap
<sgclark> ok but with home it should be able to see Pictures? what did I do wrong?
<kyrofa> sgclark, can you pastebin the output of `snap interfaces` ?
<jdstrand> sgclark: if you haven't yet, run: sudo snap connect <your snap name>:home ubuntu-core:home
<jdstrand> and if that doesn't work, yes, give the output of 'snap interfaces'
<sgclark> ok will do, thanks all
<sgclark> Ok so that worked..
<sgclark> but expecting users to do that... lol
<sgclark> anyway to auto achieve that?
<kyrofa> sgclark, yeah it's in progress
<sgclark> cool :) I accept that answer.
<kyrofa> jdstrand, do the review tools currently allow spaces, colons, periods, or underscores in the app names?
<jdstrand> nope
<kyrofa> Nice, okay. That's what I was trying to ask in that bug-- same page now
<jdstrand> kyrofa: http://bazaar.launchpad.net/~store-reviewers/click-reviewers-tools/trunk/view/head:/clickreviews/sr_common.py#L165
<jdstrand> that is for snap name, the next function is for app name
<jdstrand> snapd and the review tools should definitely be made to agree on this point :)
<kyrofa> Nice, okay that's pretty close
<kyrofa> snapd won't allow a trailing hyphen (or two hyphens), nor will it allow a +
<kyrofa> Actually the package name isn't quite right either
<jdstrand> kyrofa: in either?
<kyrofa> Indeed
<jdstrand> ok, I can fix that
<kyrofa> jdstrand, package name: ^[a-z](?:-?[a-z0-9])*$
<kyrofa> jdstrand, app name: ^[a-zA-Z0-9](?:-?[a-zA-Z0-9])*$
<jdstrand> ok
<mhall119> jdstrand: have you seen this before? File: /usr/bin/scmp_sys_resolver (read)
<mhall119> Suggestions:
<mhall119> * adjust snap to ship 'scmp_sys_resolver'
<mhall119> * adjust program to use relative paths if the snap already ships 'scmp_sys_resolver'
<jdstrand> mhall119: snappy-debug?
<jdstrand> mhall119: what is generating that?
<mhall119> jdstrand: plank, the Elementary dock
<mhall119> and yes, that output is from snappy-debug
<mhall119> Log: apparmor="ALLOWED" operation="file_mprotect" profile="snap.snappy-debug.security//null-/usr/bin/scmp_sys_resolver" name="/usr/bin/scmp_sys_resolver" pid=1589 comm="scmp_sys_resolv" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<jdstrand> mhall119: that isn't plank
<jdstrand> mhall119: profile="snap.snappy-debug.security...
<mhall119> oh, hmmm
<jdstrand> mhall119: you can filter by specifying: snappy-debug scanlog plank
<jdstrand> er
<jdstrand> snappy-debug.security scanlog plank
<jdstrand> mhall119: once 2.0.7 lands, log-observe will be fixed for snappy-debug btw (ie, you can run it without --devmode)
<mhall119> ok
<mhall119> jdstrand: ok, on to the next one:
<mhall119> Failed to register: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.1688" (uid=1000 pid=8133 comm="/snap/plank/100009/bin/plank ") interface="org.freedesktop.DBus" member="RequestName" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)
<mhall119> also, is there any interface or setting that will let it read files from /usr/share/icons/?
<jdstrand> mhall119: /usr/share/icons is allowed by unity7
<jdstrand> mhall119: the other denial is that it is trying to be a dbus service. that isn't allowed without creating an interface. I think this is likely it trying to create a well-known name for other apps to connect to it, but again, that isn't allowed. please file a bug with snapd-interface, but I don't know how that will be fixed in a generic way
<jdstrand> mhall119: (what the app is doing is at odds with what the system design allows-- it is trying to create a session service for anything to use. snappy is about isolating apps and letting them connect in controlled ways)
<jdstrand> there might be something we can do with attributes... please file a bug
<qengho> Hi. Suppose I have a upstream that doesn't need building, just unpacking. How can I include that?
<qengho> "nil" doesn't take a source. "copy" overwrites source to ".".
<popey> qengho: see my flightgear fgdata part http://bazaar.launchpad.net/~popey/+junk/flightgear/view/head:/snapcraft.yaml
<popey> should be able to put source: http://example.com/foo.tgz
<popey> I _think_
<popey> maybe with source-type tar
<qengho> Tar has a big warning that tells me I'm likely to be eaten by a grue.
<qengho> tar contents plugin, that is.
<popey> jdstrand: oh.
<popey> er, qengho oh
<qengho> I like tar_contents. It does what I think it should.
<popey> jdstrand: for you though... http://paste.ubuntu.com/17071527/ - udev one first - is there anything I can do there, or does it really need patching in the upstream program? The pulse one I imagine is fixed in snapd at some point?
<qengho> I get that un-tarring is built in to ever source: line, though. It's orthogonal. But JUST UNTAR sounds like "nil" functionality, and that hates source lines.
<mhall119> jdstrand: does the unity7 interface also give access to /usr/share/applications/?
<jdstrand> popey: the first one is problematic. can you file a bug against the opengl interface adding the snapd-interface tag?
<jdstrand> popey: with snapd 2.0.7 you can add 'pulseaudio' to your plugs
<jdstrand> mhall119: no, that is almost always non-fatal though
<popey> jdstrand: looking forward to that!
<jdstrand> popey: I suspect your udev access may be non-fatal as well
<popey> well, the app segfaults
<popey> but I don't know why
<jdstrand> that might be because of pulseaudio denials
<popey> ah
<popey> where do you want the bug filed?
<popey> https://bugs.launchpad.net/snappy ?
<jdstrand> the pulseaudio denials are fixed in 2.0.7 when you plugs: [ pulseaudio ]
<popey> ok
<jdstrand> for opengl, yes, https://bugs.launchpad.net/snappy
<jdstrand> popey: are you on yakkety or xenial?
<popey> xenial
<jdstrand> yeah, 2.0.7 isn't in xenial-proposed yet
<popey> k
<jdstrand> let me get you some rules to workaround it
<popey> done https://bugs.launchpad.net/snappy/+bug/1589671
<ubottu> Launchpad bug 1589671 in Snappy "apparmor failure on udev with opengl interface" [Undecided,New]
<mhall119> jdstrand: yeah, plank is a bit of an edge case, since it's a dock
<jdstrand> popey: add this to /var/lib/snapd/apparmor/profiles/snap.your.app: http://paste.ubuntu.com/17071856/ (in between the {})
<jdstrand> popey: then do: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.your.app
<popey> ok
<popey> jdstrand: ok, progress, no errors, but still segfaults :)
<jdstrand> popey: then my job is done! :P
<jdstrand> popey: note I left a question for you in the bug
<jdstrand> popey: does mame work with --devmode?
<jdstrand> this may be related to the opengl issues mvo and zyga have been working on (iirc)
<popey> jdstrand: will i have to undo what you suggested I do to apparmor to test that?
<jdstrand> popey: no. just do that from a terminal outside of the snap
<jdstrand> popey: you are talking about the 'cat' command, right?
<popey> no, you asked me if it works with --devmode
<popey> not looked at the question on the bug
<jdstrand> ah
<jdstrand> popey: you have to uninstall, then install with --devmode
<jdstrand> popey: if you do that, it will remove those changes, yes
<popey> okay
<popey> doing
<popey> jdstrand: well, i get no errors now with --devmode
<popey> (but still the segfault ã )
<popey> jdstrand: added output of cat to bug
<jdstrand> right, so it is probably the opengl issue that mvo and zyga are (I think) working through
<jdstrand> (as a guess)
<popey> sweet
 * popey leaves that with you
<sabdfl> hello all
<sabdfl> great to see 200 folks here :)
<vejmarie> good evening everybody, I just have a quick question does snap distribution is integrated within ubuntu-software GUI ?
<vejmarie> Or does the GUI is still "deb" dependant
<kallisti5> "Building images for ubuntu-core 16.04 will be supported by this tool soon.
<kallisti5> :-D
<kallisti5> any preview versions of the tool that supports making an ubuntu-core image
<kallisti5> https://people.canonical.com/~mvo/all-snaps/
<kallisti5> :-DF
<ayan> is there a way to write a plugin that extends an existing plugin (like nil or copy)?
#snappy 2016-06-07
<qengho> ayan: Yes. Instead of extending snapcraft.BasePlugin, extend snapcraft.plugins.existingpluginmodulename.ExistingPluginClassName
<ayan> ah  -- so also import snapcraft.plugins.existingplugin as well?
<ayan> for for nil:
<ayan> import snapcraft.plugins.nil
<ayan> class Foo(snapcraft.plugins.nil.NilPlugin):
<ayan>   ...
<qengho> ayan: Yeah, s.plugins doesn't import all of its children or something, perhaps because it's trying not to pretend to know all of them that could be found, because plugins. Import the whole thing instead of trying to walk down the path from "snapcraft".
<qengho> ^whole thing^specific thing
<qengho> Zzzz
 * ayan nods.
<lathiat> when does snappy day start, uk time?
<Hichhiker> do snaps allow/designed for permanent data storage across updates? I see $SNAP_APP_DATA_PATH - but it appears that that is a per-version location. Where does one place data to be kept with the app but not be lost due to update
<didrocks> good morning
<stevebiscuit> lathiat: the core team is mostly in mainland Europe, UK and S. America
<popey> morning
<didrocks> hey popey
<dholbach> hello hello
<didrocks> hey dholbach
<popey> what's the most advanced (in terms of working) GTK app which has been snappified, which I could use as a template for another app? Is it seb128's GNOME calculator work from Prague?
<popey> I assume Krita is the most advanced (in terms of working) KDE app?
<dpm> good question - I think we really need at least one GTK app in the playpen, seb128 (morning!) where does the code for the desktop's team snaps live?
<didrocks> argh, if I snapcraft clean an older project with newer snapcraft, it doesn't clean the parts/ directory
<didrocks> I guess it's because they renamed it to prime but didn't handle older formats
<dholbach> dpm, https://code.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap
<dpm> thanks dholbach :)
<dpm> I wonder if we should make http://bazaar.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap/view/head:/calc a part as we did with the qt5 wrapper
<dpm> I mean a wiki part
<didrocks> that was my plan (but it seems my plan for the day changed)
<dpm> hey, morning didrocks! - you mean you no longer think it's a good idea, or something in snapd has changed... or that you've got other things to do for the day?
<didrocks> dpm: other things that happened unexpectly
<dpm> ok ok
<dpm> I was originally planning to have a go ad snapping Dekko, but I might actually give this a go instead
<popey> The reason I asked is because there's a couple of gnomeish apps like Ardour and Inkscape which would be interesting to snap.
<popey> and some KDEish ones like Kdenlive.
 * dpm tries to build GNOME calc first
<seb128> hey dpm dholbach popey
<dholbach> salut seb128
<popey> morning!
<seb128> dpm, we don't have a shared space for snaps, just one main example which is the one dholbach pointed
<seb128> and it's not hackish enough yet
<dholbach> maybe we can add it to snappy playpen too?
<seb128> like translations, input methods, etc don't work
<dholbach> it'll be a WIP snap
<seb128> dholbach, your call, as long as those ^ are not working I'm not "advertizing" anything
<dholbach> right
<dholbach> we want to collect best practices in there
<seb128> "best"
<seb128> don't use that calculator snap then :p
<seb128> that's hackiest hacks
<dholbach> I feel like we're currently in the stage, where we need to find hacks to make stuff work
<dholbach> and then figure out how to make things work more generally
<dpm> indeed
<seb128> yeah, I'm just not able to find hacks that work for some of the things
<seb128> I feel like hacks are not enough to get things fully working
<seb128> we need more support from snappy itself
<seb128> dpm, dholbach, I'm fine moving things to another place if you feel like it would be better
<dpm> thanks seb128, for now we'll try to make a gtk part that can be edited in one place and reused by gtk apps
<seb128> good luck getting one to work
<seb128> I'm not wanting to recommend anyone to copy the shell hacks in the calculator used to copy schemas&co though
<dpm> ok ok :)
<d_ed> is there a way of handling i18n in the snapcraft descriptions?
<ogra_> d_ed, see http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/nethack.sh and http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/snapcraft.yaml
<ogra_> that deals with basic locale support
<didrocks> ogra_: I think d_ed is asking about the snapcraft.yaml file itself
<didrocks> getting that translated
<ogra_> didrocks,  well, there was support added for env vars inside snapcraft.yaml ....
<ogra_> but i'm not sure that got released yet
<didrocks> ogra_: how is it related to translating strings in snapcraft.yaml itself?
<didrocks> like description
<didrocks> or summary
<ogra_> so 2/3 from the script above could live in snapcraft.yaml
<ogra_> didrocks, aaah !
<ogra_> got it :)
<ogra_> (ignore me then :) )
<d_ed> AFAIK debian packages didn't, but it's an important part of appstream
<didrocks> :p
<d_ed> and snapcraft metadata is sort of halfway between the two
<ogra_> d_ed, definitely worth having a whishlist bug against snapcraft for that
<didrocks> yeah
<JamesTait> ð  Morning, folks!
<d_ed> ack, will do
<d_ed> launchpad?
<ogra_> yep
<JamesTait> Can anybody offer advice to help me package ejabberd? https://github.com/jamestait/snappy-playpen/blob/master/ejabberd/snapcraft.yaml is what I have so far, but I then need to tweak a couple of files in snap/ to prepend $SNAP to some file locations.
<ogra_> https://bugs.launchpad.net/snapcraft
<JamesTait> I've got as far as an installable snap for amd64 with that, but only with the default config (I just need to relocate the config dir to $SNAP_DATA I think).
<ogra_> JamesTait, use a wrapper script that parses the config ?
<ogra_> (i'd use the config from SNAP_DATA, then have a startup wrapper script that checks if the target has a config file, if not, parse $SNAP/etc/ejabberd into $SNAP_DATA/etc/ejabberd and adjust the paths)
<JamesTait> ogra_, maybe!  I'm not quite sure what the "standard" approach would be.  ejabberdctl is a bash script, which sets up some environemtn and calls erl, which is another bash script that sets up some environment and calls erlexec.
<JamesTait> ogra_, so a wrapper would definitely work, but I wasn't sure it was the right approach - it feels a lot like replicating the functionality of ejabberdctl, so I wondered if I could just set some autoconf parameters and have it all magically work.
<JamesTait> But for handling the config file, that makes a lot of sense - "if none exists, copy from the default location."
<ogra_> well, if the builtin scripts can be handled by vars you can indeed just set the vars
<ogra_> and use the default scripts
<JamesTait> I'll give that a try then, as a next step.  I think I tentatively poked at that before and got some complaint about something needing to be an absolute path.
<sabdfl> hi all, nice to be visiting the playpen from tokyo :)
<dpm> \o/
<sabdfl> hi dpm
<dpm> hi
<dpm> we're at https://gitter.im/ubuntu/snappy-playpen too, getting more apps added to the playpen
<sabdfl> sergiusens, you were right, moving those deps to build-packages cleared the issue on gpsd
<ogra_> hmm, i wonder ... if i put a desktop ... say lubuntu inside a snap ... and add aethercast and bluetooth support and some scrpitery ... if that could become a wireless thing client server ...
<ogra_> thin
<kyrofa> Too many chat clients open...
<ogra_> heh
<AndyWojo> Are system monitoring tools not great to make snaps of? Can they see the performance counters within the kernel?
<AndyWojo> I wanted to create a snap of nmon
<ogra_> you will definitely bbe able to use it in --devmode
<ogra_> beyond that you will likely need some interfaces that might not be there yet ... (but without you creating a snap we wont know which ones you need, so go ahead, start with the snap and file bugs for the non --devmode cases)
<AndyWojo> Great
<AndyWojo> Thanks
<sgclark> hi all
<kyrofa> Hey there sgclark
<dpm> morning sgclark o/
<dpm> d_ed, not as far as I know. However, the store supports translations for descriptions of phone clicks, so I'm thinking it should support translations for descriptions of snaps too
<dpm> JamesTait, that might be a question for you? ^
<netphreak> Hi, guys!
<ogra_> hey netphreak
<dpm> hi netphreak :)
<kgunn> mvo: you about?
<kgunn> mvo: not sure what's going on (altho i was an early user?) but snap on classic i'm getting
<kgunn> https://pastebin.canonical.com/158168/
<JamesTait> dpm, sorry, what was the question?
<mvo> kgunn: does it make a difference if you run this with sudo?
<JamesTait> Metadata translations?
<d_ed> JamesTait: yeah
<JamesTait> There's a translations section in the package details page on myapps where you can add localised metadata for the phone scope and snap client to use.
<dpm> JamesTait, exactly, are these supported in the store for snaps?
<dpm> excellent
<JamesTait> The snaps API works in exactly the same way as the clicks API in that regard - if the client sends the Accept-Language header, the response should be automatically translated.
<JamesTait> Assuming the developer has entered the translations, of course.
<kgunn> mvo: nope, same response
<JamesTait> We currently don't support extracting translations from, say, snap.yaml or .desktop files.
<ogra_> looks like snapd isnt running ?
<mvo> kgunn: hm, in a meeting right now, could you please check the last few lines of /var/log/syslog
<kgunn> ack
<mvo> kgunn: and if there is nothing interessting in there, could you mail me the full syslog ? I will inspect it then and see if it gives me some clues
<dpm> thanks JamesTait, d_ed hopefully that answers your question?
<d_ed> yep
<dpm> in short, you can enter translations in the store's web UI
<dpm> ok, cool
<kgunn> mvo: ta
<kgunn> mvo: i just uploaded it here https://drive.google.com/a/canonical.com/file/d/0B4GvOYxwuvpFTllJdk9QYS1vQUk/view?usp=sharing
<kgunn> mvo: fwiw, a couple of confessions...i have stable-phone-overlay ppa applied
<kgunn> for unity8
<kgunn> desktop-session-mir, and i also ran the little script for "early users" as advertised in
<kgunn> https://docs.google.com/document/d/1LsWd76jH9pEep8tz1SI4UPBFmbFTJGec9u518UJnW9Y/edit#heading=h.qxx7ico5okhd
<mvo> kgunn: ta, I can't see anything obvious here, hmmm
<slvn> sergiusens, Hello! you suggested me to set an env variable for this issue. https://bugs.launchpad.net/snapcraft/+bug/1575582
<ubottu> Launchpad bug 1575582 in Snapcraft "Snap package, using SDL2, needs access to libGL.so and DRI dependencies" [Undecided,Incomplete]
<slvn> I tried, but there is still some erros ... If you have some more ideas ..
<sergiusens> slvn have you checked for any errors and/or debug messages?
<sergiusens> so vejmarie solve gl a while back, my recomendation was based on what was done for freecad
<slvn> sergiusens, I don't know much about gl ... I have written the new errors on the tickets
<sergiusens> sabdfl using build-packages you also get a smaller snap :-)
<sergiusens> kyrofa agreed, it is like to many channels but worse as each has its own mechanics :-P
<kyrofa> sergiusens, no kidding
<ogra_> hmm, so how do i convinnce my snap to have a .desktop file
<kgunn> mvo: i'll take any advice, i did a remove and reinstall of ubuntu-snappy-cli and ubuntu-core.... but i'd like to get back to a state where i can work on unity8 interfaces with ted
<dpm> ogra_, perhaps with something like this? (files under setup/gui) -> http://bazaar.launchpad.net/~dpm/ubuntu-clock-app/snap-all-things/files/head:/setup/gui/
<ogra_> dpm, ah, that was the bit i was missing
<ogra_> thanks
<dpm> excellent
<netphreak> Has the classic mode been reintroduced again?
<mvo> kgunn: can you please run sudo systemctl stop snapd.service snapd.socket  ;  sudo /lib/systemd/systemd-activate -E SNAPD_DEBUG=1 -l /run/snapd.socket /usr/lib/snapd/snapd on a terminal and run snap list in a different terminal and see if this debug switch helps and prints something useful?
<kyrofa> stevebiscuit, I forgot we had wgrant there, he could tell you everything about the builders
<kyrofa> stevebiscuit, https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way if you haven't done it before
<kgunn> mvo: hmmm, now list works :) https://pastebin.canonical.com/158171/
<kgunn> the debug out for snapd is here https://pastebin.canonical.com/158172/
<kgunn> in case your interested
<sergiusens> ogra_ if you need help go to gitter :-P
<ogra_> sergiusens, i am there ...
<ogra_> sergiusens, my prob is that i start running out of free space on my desktop for the different chat clients :P
<Mikaela> is gitter also open for curious idlers?
<kyrofa> ogra_, make more virtual workspaces, duh
<kyrofa> Mikaela, certainly!
<ogra_> kyrofa, i have 6 already :)
<kyrofa> Mikaela, https://gitter.im/ubuntu/snappy-playpen
<ogra_> Mikaela, definitely !
<kyrofa> ogra_, try 9
<ogra_> haha
<Mikaela> thanks, I will take a look on PC
<kyrofa> ogra_, it will satisfy your desire for symmetry
<ogra_> i guess then i'll slowly start running out of ram for snapcraft
<kyrofa> Hahaha
<kyrofa> And now my wife starts talking to me on hangouts. Now I have telegram, xchat, gitter, and hangouts
<ogra_> kyrofa, join us on slack in the warthogs chat !
<ogra_> :P
<kyrofa> Oh man, I was on there but forgot about it
<mvo> kgunn: hm, list works but it is empty, is that expected?
<kgunn> mvo: got distracted with a meeting...lemme check more
<mvo> kgunn: same problem, long phonecall :)
<kgunn> mvo: so weird, find worked ok, but install problematic
<kgunn> https://pastebin.canonical.com/158177/
<mvo> kgunn: hm, 500 error is a store side thing
<mvo> kgunn: is that reproducable?
<seb128> kgunn, is your (hotel?) internet filtered in some ways?
<kgunn> seb128: well, we're on classic canonical wifi
<seb128> k, asking in case
<seb128> you might have reconnected to the hotel one or something
<seb128> oh
<seb128> kgunn, mvo, install errors 500 here as well
<seb128> seems like a store issue
<seb128> nessita, ^
<sergiusens> kyrofa tell her to use telegram :-P
<kgunn> dpm: hey what's the lp branch where i can rebuild calc/clock snap to attempt side load ?
<dpm> kgunn, `bzr branch lp:~dpm/ubuntu-clock-app/snap-all-things`
<kgunn> ta
<dpm> `bzr branch lp:~dpm/ubuntu-calculator-app/snap-all-things`
<dpm> np
<kyrofa> sergiusens, :P
<nessita> seb128, sorry otp, can you please join the internal store channel and report there?
<seb128> kgunn, ^
<Sutter> Hi!..
<Sutter> So... How Can i Do a snappy app?:D
<elopio> Sutter: hello.
<elopio> Sutter: you can start here: https://developer.ubuntu.com/en/snappy/build-apps/
<jamieben_> Sutter: you could also join the playpen initiative going on right now with experts to guide you through the experience - https://lists.ubuntu.com/archives/snapcraft/2016-June/000090.html
<jamieben_> Sutter: and the details on how to connect - https://lists.ubuntu.com/archives/snapcraft/2016-June/000119.html
<Sutter> wow!..ok! tnx
<ogra_> Sutter, all conversation currently happens in https://gitter.im/ubuntu/snappy-playpen
<ogra_> oh, he's gone
<ogra_> (or she)
<ev> kgunn: is snap install working for you now?
<kgunn> bout to check
<ev> cheers
<kgunn> ev: appears to be working....
<ev> excellent
<ev> really sorry that this happened. Weâre working on an incident report now to ensure it doesnât repeat
<kgunn> ev mvo fwiw, interesting i was trying to install sideload style...but grabbed from the store?
<kgunn> https://pastebin.canonical.com/158193/
<kgunn> but at least the store works ;)
<sethj> can someone confirm this is a bug in snapcraft and not in Unity Tweak Tool? https://bugs.launchpad.net/snapcraft/+bug/1587193
<ubottu> Launchpad bug 1587193 in snapcraft (Ubuntu) "build of python3 snap fails with 'error: option --single-version-externally-managed not recognized'" [Undecided,New]
<ev> kgunn: I donât think thatâs correct. Your first pastebin tries to install a snap from the store and fails
<ev> oh wow no
<ev> I see what you mean now
<ev> mvo: https://pastebin.canonical.com/158193/ - any idea why itâs fetching from the store instead of sideloading here?
<mvo> ev: does it make a difference if you do sudo snap install ./ubuntu-calculator-app_2.1+snap3_amd64.snap
<mvo> kgunn: -^
<mvo> ev: this looks like a bug I'm not entirely sure yet about the details
<kgunn> mvo: yes, ./ worked to sideload...i shoulda tried that
<dpm> hey, can someone help us answer this question from the community team Q&A?
<dpm> <ahayzen> QUESTION: Due to snappy using A/B partitioning, when we get system updates will that mean that we will have to reboot to install these? Or will we be able to have live system updates?
<dholbach> hey attente - how are you? do you have any experience with qt4 apps?
<dpm> ahayzen, ^ :-)
<dholbach> qt4 snaps I should say
<ahayzen> dpm, \o/
<dholbach> I'm working on https://github.com/ubuntu/snappy-playpen/tree/musique right now
<dholbach> and it looks for /etc/xdg/Trolltech.conf instead of its $SNAP/... counterpart
<dholbach> and I can't find that in its source code
<mvo> kgunn: thanks for confirming still a bug on our side
<kgunn> mvo: want me to file one?
<kgunn> just to have it...
<kgunn> realize not a huge deal
<dpm> dholbach, you might wanto to have a look at how we deal with qt5.conf in the qt5-launcher part. Perhaps we can do something similar for qt4 apps?
<dholbach> dpm, it's what I borrowed a lot of ideas from :)
<dpm> ok ok :)
<attente> dholbach: can you try setting $XDG_CONFIG_DIRS in the wrapper script?
<attente> dholbach: alternatively, maybe there's some way to set $sysconfdir at build time?
<dholbach> attente, like this?
<dholbach> export XDG_CONFIG_DIRS=$SNAP/etc/xdg:$XDG_CONFIG_DIRS
<dholbach> export XDG_CONFIG_DIRS=$SNAP/usr/xdg:$XDG_CONFIG_DIRS
<attente> dholbach: yeah, does that do anything?
<dholbach> no
<dholbach> I couldn't find the lookup in the source, so I suspect its further down the stack somewhere
<dholbach> but $sysconfdir sounds like something I should try
<dholbach> no mention of sysconf anywhere
<dholbach> attente, ^ do you know of any other qt4 snaps?
<attente> dholbach: no, sorry. if you want, i can help take a look at your snap
<verterok> mvo: doing a rollout, might get a couple 500's from downloads ATM
<dholbach> attente, I'll need to run in a few, but if you have a bit of time, that'd be great
<dholbach> I suspect this might be similar in other qt4 apps
<seb128> dholbach, attente, http://sources.debian.net/src/qt4-x11/4:4.8.7%2Bdfsg-8/src/corelib/io/qsettings.cpp/?hl=2672#L3531
<seb128> dholbach, attente, basically you need to rebuild your qt4 with different buildtime option
<dholbach> ouch
<attente> seb128: thanks
<seb128> that's back to the issue I'm trying to point on the mailing list
<ogra_> seb128, well, but datadir is defined at build time ... you can just set it to the right snap dir :)
<dholbach> ok, I'll take a look at that tomorrow morning
<dholbach> and see if that helps
<seb128> rebuilding?
<seb128> or the list discussion?
<ogra_> seb128, all your complaints assume you just (ab)use the debs
<seb128> ogra_, no they don't
<ogra_> would you build from source you could adjust the built time env
<seb128> right
<seb128> but that wouldn't work
<ogra_> which would immediately solve all yoour issues
<ogra_> why not ?
<seb128> no
<seb128> because what value would you use?
<seb128> --sysconfdir=/snap/currrent/software/etc ?
<ogra_> yeah,something like that ...
<seb128> that directory has no garantie to not change in a futur snapd version
<seb128> and that would make the file installed in "/snap/currrent/software/etc
<ogra_> i thinnk it is supposed to stay stable over the iteration of 16
<seb128> in the squashfs
<seb128> so be on "/snap/currrent/software//snap/currrent/software/etc"
<seb128> in the mounted snap
<ogra_> an you cant use ./software/etc ?
<seb128> well then the code would try to open /software/etc/config
<seb128> which doesn't exist
<ogra_> it would remove the dot ?
<ogra_> that sounds like a broken build system
<seb128> I don't understand what you mean
<seb128> it tries to open the conf at $sysconfdir/config
<ogra_> make your dirs relative, cd too the workdir from a wrapper script
<attente> think ogra_ is suggesting using a relative path for $sysconfdir
<ogra_> yeah
<ogra_> for all dirs
<seb128> so your program would only work if you start if from some specific dir?
<seb128> also I don't think that would work
<ogra_> well, from its confined dir ...
<seb128> make install would get confused
<ogra_> it cant work anywhere else anyway
<zyga> o/
<seb128> k
<seb128> well, make install is the issue there
<seb128> it's going to try to install to a relative path
<ogra_> i'm sure you can trick it sommehow to DTRT
<seb128> it's like the locales right?
<seb128> again I'm happy if you find the "somehow"
<attente> is there a way to tell qt4 to check a different dir at runtime? no envvar?
<ogra_> (i totally agree about the distro patch complaint btw)
<ogra_> qt4 ? is that still a thing ?
<seb128> attente, seems not, did you see the url I shared?
 * ogra_ thought qt4 would have been gone the way of gtk1.2 by now :)
<attente> seb128: yeah, i saw. but i was wondering if there's some codepath that overrides it at runtime
<seb128> not that I found
<attente> seb128: what about https://sources.debian.net/src/qt4-x11/4:4.8.7%2Bdfsg-8/src/corelib/io/qsettings.cpp/?hl=2672#L1107
<seb128> attente, that's only for the user config?
<ogra_> grrr ... upstreams ... even canonical peoplle hardcode paths in their upstream code !!!
 * ogra_ tries to cook up a patch for the webbrowser app so it becomes usable in snaps
<seb128> lol
<ogra_> and this one is really evil ... "cant find my app in /usr/share/webbrowser-app ... so i *must* be on a developer system ... lets hardcode all paths to ./src then !"
<seb128> that's common practice
<seb128> well not unseen at least
<ogra_> (but indeed lets expand the path to the full absolute one starting at / before we inject it into the binary)
<attente> seb128: XDG_CONFIG_HOME=/ASDF strace musique 2>&1 | grep ASDF
<ev> mvo, kgunn: heads up that the store is down again
<attente> it seems to be looking there after defining it
<ev> weâre in the process of rolling back the bad deployment
<seb128> attente, yes, that's what the url I share was documenting?
<attente> seb128: yes, but it doesn't require a rebuild of qt4
<seb128> attente, well it's the user config
<seb128> attente, it's trying to append .config to it no?
<seb128> like /ASDF/.config/Trolltech.conf ?
<seb128> (I didn't try here, just my reading)
<seb128> unsure if relative paths would work
<attente> seb128: it looks at "/ASDF/Trolltech.conf" for me
<seb128> oh oh
<seb128> ah, makes sense
<attente> so i guess just defining XDG_CONFIG_HOME=/snap/<name>/current/etc/xdg should work
<seb128> that seems wrong
<seb128> but yeah, could work
<seb128> well it would need to be made a list
<seb128> so it still find the real user config if there is one
<attente> yeah
<wililupy> Question: Is anyone else getting http error 500 when trying to snap refresh ubuntu-core?
<wililupy> I'm getting this error on my 16.04 laptop and from my Ubuntu-core KVM's.
<popey> wililupy: i just tried and it worked here
<wililupy> Interresting....
<popey> not in a kvm, but on bare metal, if that matters
<wililupy> That is so weird, I have been trying for 30 minutes and as soon as I question it here it is working.
<popey> hah
<popey> magic
<wililupy> I should have asked sooner ;P
<wililupy> Thanks popey
<seb128> there was an issue with the store earlier it seems
<seb128> but yeah, it has been fixed
<popey> np
<ogra_> ev, is the store supposed to be ok again ? all my phones just spin endless "looking for updates" now
<ogra_> hmm, snap find on the desktop also hangs hard
<noise][> ogra_: looks like a connectivity outage
<ogra_> ah, finally timed out with a horrible 5 line traceback error message
<ogra_> Chipaca, ^^ could we make that a little less scary looking ?
<ogra_> noise][, lovely
<hichhiker> hi, what is the _proper_ location to store snap-specific data to make it keep across version updates (in Snappy)? Specifically I am playing around with making a Redis snap package - but want to know where do I put the data dumps, etc
<hichhiker> APP_USER_DATA seems to be versioned along with the app, so each time I update the app I seem to get a new user data directory :-(
<kyrofa> hichhiker, indeed, each version gets a new directory, but the old version's data should be copied into the new one
<kyrofa> hichhiker, this helps in case the snap needs to be rolled back
<hichhiker> hmm,  I will check on that. How does old data in USER_DATA is cleaned up then? I get current and 1 last version of the app, but it seems that every version of the user data is still there
<kyrofa> hichhiker, I believe it will keep three versions before pruning them
<hichhiker> kyrofa, thanks, I am just starting out with Core/Snappy and find the learning curve is a bit steep - (mostly because of lack of documentation and conflicting docs)
<kyrofa> hichhiker, yeah docs are a known weak point-- we're working on that :)
<hichhiker> kyrofa, not the case on my box, I get at least 16 versions of data
<kyrofa> hichhiker, hmm, that may have changed. Or it may only apply to snaps in the store
<hichhiker> kyrofa, could be... I am on 15.04 if it matters (could not find 16.04 release to download) - also, for whatever reason my snap version is ignored and version looks like a hash of some sort - like this: 'IVMeYWXTaHdc' - the package.yaml has the right value, so not sure why that is happening
<kyrofa> Oh!
<kyrofa> That's the difference then
<hichhiker> 15.04 or hash?
<kyrofa> You should just use snappy on 16.04 desktop or server while waiting for images
<kyrofa> The fact that you're using 15.04 invalidates a lot of assumptions I was making. The hash means your app is sideloaded
<hichhiker> the key thing I need from it is the Core read-only OS deployment - is that part of desktop now?
<kyrofa> No, the desktop OS is not read-only, but you can use snaps on it just like you can in the images
<hichhiker> BTW, the device I am working on will not be connected directly(or more likely at all) to internet - is there a way to deliver snaps beside sideloading?
<kyrofa> There are probably other ways that will be supported, but sideloading is likely the easiest
<hichhiker> Ok, my hope is to deliver snaps (preferably signed/encrypted) on removable media that is automatically recognized on insert and updated if needed - but I am sure we are far away from that dream yet :-)
<hichhiker> 16.04 seems like it is going to be drastically different, but since it is not out yet, I may switch back to using ubuntu server for now as a half-way step. It is just too tempting to just give up on snaps and go back to .debs once I do that :-/ I really like the Core idea for appliances
<hichhiker> I assume server 16.04 has snappy as well?
<qengho> Yes.
<qengho> Not "snappy" program. Some renaming. Just "snap".
<hichhiker> quengho - is that true of Core 16.04 as well?
<hichhiker> one more question, is the Grub for Core custom or off-the-shelf? It is possible to replace it with another grub fork or is there Core specific stuff there?
<sergiusens> hichhiker if you do snaps now, you will be ready for when ubuntu core comes out
<sergiusens> you will be able to migrate transparently
<gouchi> is it possible to know if you are in mobile or desktop environment with snapcraft ? So that we can push different configuration file ?
<qengho> hichhiker: Yes. Ubuntu 16.04 was released with our progressing work on snappy. It's the best place to work on snaps.
<hichhiker> Thanks
<kyrofa> hichhiker, the grub question is one for ogra_ I think
<qengho> hichhiker: ubuntu-core will want to manage the bootloader configuration, so I would be scared of messing around with it much.
<hichhiker> qungho - I wanted to see if I can get TrustedGrub(1 or 2) to work (it uses TPM to store drive encryption/boot signing keys) - but it is another pipe dream :-/
<qengho> hichhiker: I know pretty much nothing about this, but I am pretty sure there will be a way for you. It might be that you create your own os or grub package too.
<wililupy> I'm trying to build a .snap for armhf so I tried snapcraft --target-arch armhf snap and I get the following error: http://pastebin.ubuntu.com/17098210/
<wililupy> its the hello world example from snapcraft-examples git.
<wililupy> Not sure what it means. Do I need to add the arch to the snapcraft.yaml for the hello part?
<qengho> wililupy: The "hello" plugin doesn't implement building another architecture. It lacks a function that says it supports it, and it lacks test and settings in build() that implement it.
<mrasif> hello sir
<mrasif> I developed an app.
<qengho> wililupy: You need a armhf machine or to borrow one from launchpad's builders for branches there.
<sergiusens> wililupy is there a hello plugin in there?
<mrasif> then I upload it to ubuntu distro
<mrasif> but it still in review section
<wililupy> sergiusens: no, the hello-world example uses cmake plugin
<niemeyer_> jdstrand: Curious about why my spread snap hit the review queue
<wililupy> qengho: so your saying I should build my .snap on an armhf device instead of an amd64 server?
<niemeyer_> jdstrand: Are we reviewing for home?
<qengho> wililupy: The best thing is to help implement cross-platform support, but the fastest thing is to use a real or virtual machine to make your package.
<dpm> jdstrand, do you use askubuntu?
<dpm> jdstrand, if so, what you just posted in the mailing list would be a perfect answer to http://askubuntu.com/questions/783979/how-to-debug-snaps ? :)
<jdstrand> niemeyer_: I approved
<qengho> wililupy: in a plugin, implement enable_cross_compilation(), which peeks at self.project to set values in self that inform the build() about architecture.
<wililupy> I'm using the cmake plugin, shouldn't that already be implemented?
<wililupy> qengho ^^
<qengho> wililupy: cmake doesn't mean anything about what you're compiling. Are you passing the right flags to the Fortran compiler or whatever?
<qengho> wililupy: That's my way of saying, no, knowing that you're running cmake to run a compiler doesn't mean the compiler knows enough to switch architecture targets.
<qengho> It *could* be enough. It might not be.
<wililupy> qengho, that makes sense, which is why snapcraft wants me to make sure that I have the arch in the hello parts section.
<qengho> wililupy: and today, the cmake plugin doesn't try to know...
<wililupy> That is extremely helpful qengho.
<qengho> wililupy: waaaait, snapcraft doesn't require arch. Not any recent version. Are you on 16.04?
<wililupy> qengho. Yes.
<qengho> wililupy: make a new dir. and cd there. Run "snapcraft init". Does the new yaml have arch in it?
<wililupy> qengho no.
<qengho> wililupy: it's not required.
<wililupy> the snapcraft.yaml file I was using was from a clone from github.com/ubuntu-core/snapcraft-examples
<wililupy> I'm just trying to snap the hello world cli example, which works fine from amd64, but when I try to make it for armhf I get the errors.
<qengho> wililupy: I'm very sorry, but that example must be older than dirt.
<wililupy> most of the examples are ;)
<sergiusens> wililupy cmake plugin has no cross compilation support either
<sergiusens> wililupy we don't expect it any time soon either
<wililupy> sergiusens: ok. I'm going to try to build my .snap on my pi2 running 16.04 server.
<erio> Hello
<erio> Couldn't solve the locale error the other day
<erio> http://askubuntu.com/questions/783758/snap-build-fail-on-locale-error
<erio> Leaving here in case someone has seen this already and know how to solve
<wililupy> sergiusens, qengho: I successfully got the hello world example to build on my pi2 and it works on my test device. I'm going to read more up on the --target-arc flag on snapcraft to see what exactly it does work on.
<sergiusens> wililupy it only really works for building kernels
<sergiusens> it is rather low priority everywhere else
<wililupy> sergiusens: Ok. I was just hoping that porting a app snap or gadget snap from one arch to another would be as simple as just the --target-arch flag in snapcraft. Its like you say, not a high priority since I can build on either arm or x86.
<eriow> Could one use ELDK to build, throw the binaries in the same folder and call snapcraft snap after?
<eriow> https://wiki.ubuntu.com/ARM/RootfsFromScratch
<eriow> Good luck wililupy
#snappy 2016-06-08
<erio> Hi
<erio> I lost connection later...
<stevebiscuit> kyrofa: great post, cheers!
<ayan> stevebiscuit: which article?
<stevebiscuit> ayan: I'm in the process of getting Launchpad to build snaps of WebDM so this was useful: https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way
<ayan> stevebiscuit: ah -- that is useful.
<dholbach> hey hey
<didrocks> morning dholbach
<dholbach> salut didrocks
<seb128> lut dholbach
<dholbach> salut seb128
<seb128> dholbach, did you change from https://github.com/ubuntu/snappy-playpen/commit/7c6f2275 work as you wanted?
<seb128> I though about that yesterday evening and now I see you already did it :p
<dholbach> no, it doesn't :-/
<zyga> o/
<joc_> morning zyga
<joc_> zyga: just a reminder that I would like your feedback on latest serial interface, when you have time :)
<_morphis> zyga: snapcraft@lists.ubuntu.com being the right one these days to discuss that?
<zyga> joc_: I know, believe me
<zyga> _morphis: yes, I think so
<_morphis> zyga: ok
 * zyga had a super rough night, is barely awake
<_morphis> .-)
<joc_> zyga: sure, look after yourself
<pmp> I asked this two weeks ago and couldn't work on it - as things are changing fast currently I'm asking again ;-)
<pmp> I'd like to boot a custom kernel (4.7-rc2) for raspberry pi2
<pmp> I build one for raspian and it works as I'd like to
<ogra_> use snapcraft and the snapcraft kernel plugin to create a snap
<ogra_> here is a demo snapcraft.yaml using that plugin https://github.com/ubuntu-core/snapcraft/tree/master/demos/96boards-kernel
<pmp> ogra_: thx, that's what you told me two weeks ago, I somehow hope there now a faster-better-newer way to do it - OK I go with snapcraft
<ogra_> pmp, i doubt there will be any easier and faster way (i actually doubt it is easier to solve than via such a snapcraft.yaml )
<pmp> ogra_: iirc, you told me that currently the pi2-kernel.snap is generated as a side-product of the deb-build
<ogra_> nope
<ogra_> it is created as a side product of the os snap build
<pmp> is there a dedicated snapcraft.yaml in there for building a kernel for pi?
<seb128> dholbach, sorry I didn't see you reply earlier, what doesn't work?
<seb128> with the troltech conf
<pmp> ogra_: I'm afraid starting from the 96boards-kernel won't give me a nice working snap...
<ogra_> pmp, well, it works for many other people ... why do you think it wouldnt work for you ?
<pmp> ogra_: good question ;-)
<dholbach> seb128, copying the file over
<seb128> dholbach, I can have a look if you want
<pmp> ogra_: actually what I meant was I don't know what to put into the snapcraft.yaml
<pmp> ogra_: I'd like to use the standard raspi2-kenrel and just add the missing CONFIG_'s
<dholbach> seb128, it's basically https://github.com/ubuntu/snappy-playpen/tree/musique/musique
<ogra_> pmp, well, isnt the snapcraft.ymal in the demo self explaning ? ...
<seb128> dholbach, k, just finishing something else and having a look
<dholbach> thanks a lot seb128
<ogra_> for defconfig: [defconfig, distro.config] you probably only want "defconfig" and define the additional bits in kconfigs ... you wont need any initrd firmware so you can remove that block and can also drop the last few lines that are about specific dragonboard firmware
<seb128> dholbach, yw!
<ogra_> and indeed you want to point the source option to your own kernel tree
<ogra_> (as well as adjusting the device trees to point to the right ones)
<pmp> ogra_: you see, not that easy.. for example: dtbs/overlays.tgz
<ogra_> ignore that for the start
<pmp> no, I need an overlay
<ogra_> well, but the rpi doesnt allow overlays anywhere but in the bootloader ... so they need to go into the gadget snap anyway
<ogra_> so ignore that bit ... you will later need to use your own gadget for that
<ogra_> *after* you have a kernel snap that boots
<pmp> ok
<ogra_> ('m currently trying to play with the new dtb loading feature from uboot, that might solve this issue but it is still in its early stages)
<bsperes> What is the correct way to go about deleting the default ubuntu user from snappy? I'm able to create a new user using useradd with the --extrausers flag, but there doesn't seem to be such a flag for the userdel comand.
<seb128> dholbach, the config file is there for me ... what error do you get?
<dholbach> seb128, can you launch musique?
<seb128> yes
<dholbach> oh?
<dholbach> in my case it explodes and wants to access /etc/xdg/Trolltech.conf
<ogra_> bsperes, i'd just leave it around and simply use "passwd -l" to lock it down
<seb128> dholbach, I used --devmode though
<ogra_> bsperes, http://paste.ubuntu.com/17116610/ is a script i used to use in 15.04 installs
<dholbach> seb128, ok
<ogra_> (when snappy config was still a thing though)
<seb128> dholbach, works without devmode as well
<dholbach> hohum...
<dholbach> in that case I must be doing it wrong :)
<seb128> dholbach, ignore me, I didn't test right
<seb128> dholbach, the host /etc is mounted on the snap and I've qt4 installed
<seb128> let me try to move that away
<seb128> dholbach, still work though
<seb128> Fontconfig error: Cannot load default config file
<seb128> QGtkStyle could not resolve GTK. Make sure you have installed the proper libraries.
<seb128> QSqlDatabase: QSQLITE driver not loaded
<seb128> it displays those but starts
<dholbach> ok... I'll test it locally again
<dholbach> it starts now as well
<dholbach> ... with --devmode that is
<seb128> and without?
<bsperes> ogra_, ok sounds good, thanks for your help!
<seb128> dholbach, well in any case let me know if you get the error again
<dholbach> seb128, tries to access /etc/xdg/Trolltech.conf
<seb128> but it errors out on that?
<dholbach> yep
<dholbach> Bad system call
<dholbach> and tries to write to /snap/musique/100001/usr/share/data/...
<dholbach> which is something I guess I can patch in the source, or there might be a config for it
<dholbach> but the XDG thing is something which might be a problem deeper down the stack
<seb128> dholbach, does it work if you edit /var/lib/snapd/seccomp/profiles/snap.musique.musique and uncomment the "socketcall" line before starting it?
<seb128> when does it try to write
<seb128> I wonder why I don't get those issues :-/
<dholbach> seb128, it's a message on stdout when you start it with --devmode
<dholbach> wants to create a .db there
<dholbach> in which case would the socketcall bit help?
<dholbach> (it doesn't change anything)
<seb128> I don't know, I just need to do that because I'm on i386 and there is a seccomp bug
<seb128> I was wondering if the workaround was making me not see your bug
<dholbach> ok
<seb128> well, wfm :-/
<dholbach> can you import a small directory of files and does it show up next time you start?
<seb128> no, import seems to fail
<seb128> I get those writable share warning now
<seb128> dholbach, I think it's because it can't connect to the database
<dholbach> I'm trying to figure out which variable to change to make it use $SNAP_USER_DATA instead
<kyrofa> sergiusens, how would you feel about a `godeps_file` key being added to the go plugin to pull down godeps for a package before building?
<seb128> dholbach, you mean the write to /usr error?
<dholbach> yep
<seb128> dholbach, that's because of export XDG_DATA_HOME=$SNAP/usr/share
<kyrofa> `godeps-file` I guess. The name is of course up for discussion
<dholbach> seb128, ok, let me see
<seb128> dholbach, see https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
<seb128> that's supposed to be a writable directory
<seb128> but indeed, seems that export is copied around
<seb128> it was in the calculator snap from jdstrand when we picked it up as well
<dholbach> even removing them doesn't make it work
<dholbach> I think the path is put together by using QDesktopServices::DataLocation in src/database.c
<seb128> dholbach, for me unsetting XDG_DATA_HOME removes the warning
<seb128> but adding files doesn't work because it can't access the database
<dholbach> I'm doing a clean build again
<dholbach> seb128, it works :)
<seb128> nice
<sergiusens> kyrofa should it be a new plugin or an extension of the go plugin?
<sergiusens> kyrofa a new plugin would make more sense or we will soon get parameter overload
<kyrofa> sergiusens, probably a good point-- lots of ways to handle go dependencies
<kyrofa> sergiusens, but then you need to filter code out of the stage dir
<kyrofa> Rather, you need to filter it using the `prime` keyword so it doesn't end up in the snap
<sergiusens> kyrofa huh? Why can't the plugin take care of that?
<kyrofa> sergiusens, hmm. Do you mean make a `go-with-godeps` plugin or some kind?
<kyrofa> of some kind*
<kyrofa> sergiusens, I thought you meant a `godeps` plugin
<sergiusens> kyrofa yeah, a `godeps` plugin
<sergiusens> kyrofa what does that have to do with `prime`?
<pmp> ogra_: I build the snap with snapcraft --target-arch=armhf snap
<pmp> ogra_: I snap install
<kyrofa> sergiusens, I may be missing something here. If we have a `godeps` plugin, the `go` part will need to use the after keyword to make sure it uses the stuff pulled in by godeps, which would put the deps in the stagedir. No?
<ogra_> pmp, i dont think that works ... you would need to use ubuntu-device-flash to actually create an image with it
<ogra_> not sure if/how well sideloading kernel snaps actually works
<pmp> ogra_: and uboot now says: Bad ARM zImage magic or similar
<kyrofa> sergiusens, which means the code pulled by godeps will by default end up in the snap
<ogra_> pmp, is that with our gadget snap in use ?
<dholbach> ok, music playback doesn't work in musique now, but I guess that's a known issue, even with --devmode?
<ogra_> pmp, i really think you need to create the image from scratch with that kernel snap in use
<kyrofa> sergiusens, though now that I mention it, I think adding to that filter is in the plugin API
<pmp> ogra_: I'm u-d-f'ing just now
<pmp> Even after u-d-f'ing I have Bad Linux ARM zImage magic
<ogra_> hmm, did it actually produce a proper vmlinuz ?
<pmp> Well, in the same folder I build the image I used ealier with raspbian
<pmp> I
<pmp> will check
<ogra_> oh, you might need "kernel-image-target: zImage"
<ogra_> in your snapcraft.yaml
<ogra_> arm64 devices can not use compressed kernel binaries ... so the 96boards demo uses a plain Image ... not zImage
<pmp> can I just re-run the install-part of the installation?
<pmp> instead of recompiling everything
<pmp> (which takes a long time - unfortunately)
<ogra_> not sure, i think you need to fully clean the tree
<ogra_> really ?
<ogra_> i thought you cross-build
<pmp> yeah, it seems the bcm2709-defconfig for 4.7 has enabled much more modules than the one of 4.6 (and before)
<pmp> And I'm running Ubuntu inside a docker
<ogra_> ah
<episensor> hi all - quick question. we're running some tests with snapcraft. with out current build system, our .jar files are located in /lib/ - is it reasonable to edit line 48 of the ant.py plugin and point it at /lib/? is there any other location where this can be configured?
<episensor> *our
<dholbach> episensor, maybe file a bug?
<ogra_> i guess running the copy plugin first to get the files copied in place might work
<dholbach> or that... right
<ogra_> not sure though if that can actually pull from outside the snapcraft tree
<croepha> What are some good ways to manage several similar sanppy  installations?  Are things like Chef and Puppet recommended? what would be the recommended way to install snappy on a device with some set configurations? (like versions of things installed, configurations...) What would be the recommended way push new configurations to existing snappy installations?
<mhall119> where do snaps put their .desktop files?
<ogra_> mhall119, inside the snap your mean ?
<ogra_> or after install
<mhall119> I mean, where does the Dash find them
<mhall119> after install
<ogra_> /var/lib/snapd/desktop
<ogra_> see XDG_DATA_DIRS in your env
<ogra_> croepha, once snappy config is back you should be able to use the REST api of snapd to manage configs i guess ... Chipaca might know more
<croepha> Sweet thanks, I didn't know about snapd, now I got something to research!
<ogra_> croepha, though if you talk about appliance devices that all use the same/a similar image, you would do all this inside a specific gadget snap for your image
<ogra_> in either case i think snappy config coming back is required first though
<ogra_> (it is on the TODO, i dont know with what prio though)
<mhall119> thanks ogra_
<netphreak> hi, guys!
<croepha> hi netphreak
<netphreak> has snappy enable-classic been reintroduced?
<pmp> ogra_: the kernel boots - thanks for your help - what to do now with the overlay? could it be as simple as unsquashing the gagdet and then squashing it again after add the overlay
<pmp> ogra_: recreating the overlay.tgz with the *-overlay.dtb from my kernel?
<ogra_> pmp, well, the gadget also only allows a tgz file ... that wont help you to load the overaly in the end
<ogra_> just create an overlay subdir in the system-boot partition and copy the dtbs there
<ogra_> the rest is config.txt hacking
<atriv> Hi all, Not sure if any core devs are in... I noticed recently that gpio and i2c support was added for the raspberry pi. i'm curious if there's support for samsung's artik modules and if not if there's a roadmap
<arosales> Hello, is this the place for the Snap Caffe?
<elopio> arosales: welcome, have a sit.
 * arosales waves at elopio
<elopio> atriv: hello. I bet you'll get better luck with your question in the mailing list.
<elopio> people who know more details about that seem to be afk now.
<atriv> thanks elopio
<arosales> I wanted to check here if Caffe would be a good candidate to snap
<arosales> I have been following http://caffe.berkeleyvision.org/install_apt.html
<arosales> to get it built myself I have that done with GPU support, and I am working on non-gpu support
<arosales> note, compilation steps continue @ http://caffe.berkeleyvision.org/installation.html#compilation
<arosales> so its not a super straight forward process
<arosales> thoughts?
<elopio> arosales: everything is a good candidate. That one seems awesome.
<elopio> arosales: you can start trying that cmake they mention there. We have a cmake plugin in snapcraft.
<arosales> elopio: thanks for the feedback, do you have a pointer to plugins in general and the cmake one specifically?
<elopio> arosales: snapcraft help cmake
<elopio> and there are some examples using cmake in https://github.com/ubuntu/snappy-playpen
<arosales> elopio: thanks. I'll take a whack at it
<marcoceppi> Does snappy work on S390X ?
<qengho> marcoceppi: No. Nothing technical in the way. Just demand and attention. You can use: amd64, i386, armhf, arm64
<marcoceppi> qengho: I have a demand ;)
<qengho> marcoceppi: come back with 1e6 others.
 * marcoceppi registers 1e6 more irc accounts
<elopio> marcoceppi: I haven't tested it there yet.
<qengho> marcoceppi: It is probably possible, and we would love to see it. Please contribute something.
<marcoceppi> qengho: like what?
<qengho> marcoceppi: I am wrong. I apologise! We do have s390x images. http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
<marcoceppi> \o/
<ogra_> marcoceppi, only snappy on classic, we dont build boot images for s390x IoT devices ;)
<ogra_> marcoceppi, i havent found anyone to test them yet, so please report bugs
<AndyWojo> Wow mark is really active on the snappy mailing lists. That's cool.
<mhall119> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1590599 has been killing me all day
<ubottu> Launchpad bug 1590599 in Snapcraft "snapcraft prerequites are slow to resolve" [Undecided,New]
<sergiusens> mhall119 yeah, that can be troublesome on bigger projects. kyrofa want to have a look at that one?
<sergiusens> mhall119 it is not the prereq itself btw, it is the calculation involved to really know the prereq has really run or became dirty along the way
<mhall119> sergiusens: is there any way it would become dirty between one check and the next?
<mhall119> in the same call
<mhall119> sergiusens: kyrofa: anyway, I hope the profile data helps, I can give you the raw cProfile data file if you want
#snappy 2016-06-09
<sergiusens> elopio are you around?
<elopio> sergiusens: yup.
<sergiusens> elopio can you look at the last PR comment I made (the tour one)
<sergiusens> elopio and for your branches. It may be late, but I want to land them :-)
<elopio> sure, the night is young.
<elopio> there's a duplicated line in there :/
<sergiusens> elopio should we land #551?
<croepha> so... been looking at snapcraft.yaml examples, it looks all of them are building from source... can you not simply say, install xyz packages from apt?
<elopio> sergiusens: yes, we can move to the common setup in a different branch.
<elopio> hum, the all-snaps servers are not working.
<sgclark> mhall119: sergiusens: in regards to https://bugs.launchpad.net/snapcraft/+bug/1590599 I have been working on that snapcraft.yaml and it seems faster. Unfortunately, that one I did much experimenting and it had some cruft.
<ubottu> Launchpad bug 1590599 in Snapcraft "snapcraft prerequites are slow to resolve" [Undecided,New]
<sgclark> I will commit my changegs by the end of my night. Which of course should have been hours ago.
<sgclark> snappy is addicting as I thought it would be :)
<elopio> sgclark: I'm so glad you are enjoying it :)
<sgclark> :)
<sgclark> erg nope, still lots of qt4 going across and I am tired! I will sort this out tomorrow.
<dougb> On BeagleBone Black, only ttyO0, the console serial, is enabled. How do I enable the other available serial ports in Snappy?
<ogra_> mvo, the new dir you added in livecd-rootfs ... is that supposed to become the mountpoint ?
<mvo> ogra_: its for zyga
<mvo> ogra_: its a confusing name
<mvo> ogra_: it should probably be "hostsystem" or something
<ogra_> why didnt you call it "zygas-dir" then :P
<mvo> ogra_: :)
<ogra_> ah,, k ... other way around then
<ogra_> yeah, "host" or "hostfs" would be clearer
<mvo> ogra_: lets rename it then, i will tell zyga
<ogra_> sounds good :)
<jennym> Hi, I am trying out some java projects in snapcraft. I would like to build two separate jar files from two java files, one of which depends on the other. I have a wrapper script which invokes java : java -cp HelloWorld-helper.jar:HelloWorld.jar oata.HelloWorld. However this doesn't run under snappy. I get a Error: Could not find or load main class error. It looks like I shouldn't set the classpath in the script like this. Any suggest
<ogra_> jennym, there are maven and jdk plugins for snapcraft (i guess you could use the latter)
<ogra_> there is a "java-hello-world" demo package at https://github.com/ubuntu-core/snapcraft/tree/master/demos, that might be of help
<jennym> ogra_, thanks. I am using the ant plugin which works fine for a single source file/single jar file example.
<jennym> ogra_, Yes my example is based on that but I extended it by making a src2 directory which resulted in a second jar being generated.
<ogra_> and you modified the makefile and build.xml to take that into account ?
<jennym> Yes. I also modified the wrapper script.
<ogra_> didrocks, didnt you package java stuff before ^^^ ?
 * ogra_ didnt
<didrocks> elopio: sergiusens: once you are around, I think the "tour" part is done for next release. There are 3 related PR (note that the examples tests are failing in the image creation): https://github.com/ubuntu-core/snapcraft/pull/551, https://github.com/ubuntu-core/snapcraft/pull/558 and https://github.com/ubuntu-core/snapcraft/pull/559)
<didrocks> jamiebennett: FYI, those are the 3 we need in next snapcraft release ^
<didrocks> ogra_: I didn't, what's up?
<ogra_> didrocks, well, just looking for someone who can help jennym
<didrocks> hum, classpath and so on, I'm afraid I don't know enough java about this
<jamiebennett> didrocks, OK, I presume sergiusens is well aware of these?
<ogra_> yeah, same here ...
<didrocks> maybe sergiusens or kyrofa may help (as they wrote the plugin) once around?
<ogra_> yeah
<didrocks> jamiebennett: with the above ping (the first PR was from some days ago, the last 2 from this morning)
<jamiebennett> didrocks, OK
<didrocks> jamiebennett: better if you double check as I guess we'll talk about release time and such, I didn't bother him with this yet
<didrocks> jamiebennett: FYI, sergiusens is awake (but hiding) ;) first PR merged!
<jamiebennett> didrocks, Ah
<jamiebennett> :)
<ogra_> didrocks, he is just sleepwalking
<ogra_> s/walking/merging/
<didrocks> heh
<didrocks> I guess that's it, inded
<didrocks> indeed*
<sergiusens> jamiebennett didrocks yes, I always hide in the mornings ;-)
<didrocks> ;)
<didrocks> the silent merger!
<sergiusens> didrocks ogra_ I think lool or mvo or mterry wrote those maven and ant plugins fwiw
<sergiusens> didrocks well if it is all good, what noise is there to make :-)
<ogra_> didrocks, probably with a quiet snoring ;)
<didrocks> sergiusens: indeed :) keep me posted on the next 2 PR btw
<didrocks> so that we can get 2.11 with the tour released and done
<sergiusens> didrocks don't worry, if you EOD, we will do what we always do ;-)
<didrocks> sergiusens: ah nice, seems that it can recreate now the vm (I retried it already this morning, it couldn't)
 * didrocks does the same on the other PR
<jennym> didrocks, sergiusens, ogra_ : I have solved my problem. Actually I didn't need to change the wrapper script (this is in reference to the original java-hello-world example). When there are two jar files generated by the ant task, the are both added to the classpath by snapcraft.
<sergiusens> didrocks yeah, we run out of instances fast, at least the jobs fail fast
<ogra_> jennym, cool !
<didrocks> jennym: excellent! so default are good! :)
<didrocks> sergiusens: ah, ok, that's the reason
<sergiusens> oh, sorry jennym I didn't even read what your problem was. I was just stating a fact that I didn't write the plugin. It does add every jar it builds to CLASSPATH indeed
<jennym> By adding a -cp argument to the java command in the wrapper script I was probably upsetting the previously set classpath.
<jennym> I am now going to try another extension to the example by including a jar file which is built externally. So I might get back about that. Thanks all.
<gouchi_> hi
<gouchi_> any tips how to fix this apparmor denied access http://www.hastebin.com/unuyijupiy.vhdl ?
<ogra_> gouchi_, i think popey filed a bug for exactly that
 * ogra_ cant find the number atm
<ogra_> gouchi_, bug 1589671
<ubottu> bug 1589671 in Snappy "apparmor failure on udev with opengl interface" [Undecided,Confirmed] https://launchpad.net/bugs/1589671
<gouchi_> ogra_: thank you
<dholbach> seb128, attente: have you seen anything like this already? https://files.gitter.im/ubuntu/snappy-playpen/9taf/ristretto.png
<dholbach> that's with https://github.com/ubuntu/snappy-playpen/tree/ristretto/ristretto
<seb128> dholbach, seems like fonts missing
<seb128> do you have the fontconfig hacks in your wrapper?
<seb128> # Font Config
<seb128> export FONTCONFIG_PATH=$SNAP/etc/fonts/config.d
<seb128> export FONTCONFIG_FILE=$SNAP/etc/fonts/fonts.conf
<seb128> seems you have
<seb128> any command line error?
<ogra_> dont you need to generate a font cache too ?
<ogra_> or am i living in the past
<ogra_> iirc there used to be a command
<didrocks> seb128: that was exactly my answer gitter :p
<ogra_> update-fonts-dir ...
<ogra_> that was the one
<ogra_> and -alias
<ogra_> hmm
<ogra_> or was it fc-cache
<seb128> ogra_, unsure, it works for other gtk and qt apps with no extra update command
<ogra_> lundmar, bug 1566604
<ubottu> bug 1566604 in Snappy "the snap command has no autocompletion" [Medium,Triaged] https://launchpad.net/bugs/1566604
<lundmar> ogra_: not quite the same issue.
<ogra_> well, then file a new bug :)
<lundmar> snap is installed using apt and I assume its completion script is installed the convetional way.
<dholbach> ogra_, I copied the bits from the galculator snap
<lundmar> The questions is, how do we support enablement of completion scripts included in snaps?
<lundmar> question*
<ogra_> dholbach, right,, and i dont see any font cache generatin in that script ... thats why i mentioned it
<dholbach> ok
<lundmar> I've just create the "tio" snap. However, the system does not pick up on the completion script that the snap installs?
<ogra_> lundmar, ah, you mean /snap/bin binaries ?
<lundmar> created*
<lundmar> ogra_: exactly
<ogra_> well, it works for the binaries in there
<ogra_> ogra@styx:~$ free<tab><tab>
<ogra_> free             freecad.FreeCAD  freetype-config
<ogra_> freecad.FreeCAD is from a snap
<seb128> dholbach, do you want me to have a look to the font thing?
<dholbach> I think that was fixed in your version of the snap
<lundmar> sure, but the actual app completion is not working because the system only sources the apt installed completion scripts
<dholbach> I just filed https://github.com/ubuntu/snappy-playpen/issues/46 for this
<ogra_> (it cant autocomplete options though)
<dholbach> I'll try to fix it in both snaps
<ogra_> lundmar, well, file a bug :)
<lundmar> ogra_: will do .)
<ogra_> :)
<lundmar> source /snap/*/current/usr/share/bash-completion/completions/*
<ogra_> well, i doubt we want it *that* generic
<lundmar> well, thats the gist of it :)
<ogra_> rather have snapd bind-mount /snap/*/current/usr/share/bash-completion/completions/ content to some system dir to de-couple it
<ogra_> i think that goes into the same category as manpages ... iirc jdstrand discussed the security side yesterday somewhere
<ogra_> (for manpages that is)
<lundmar> its kind of a layering issue, probably completion scripts or even man pages intalled by system (apt) should take precedence.
<kyrofa> mhall119, nice bug, thank you!
<lundmar> in my case I've just created a snap "tio" which includes a completion script. Would be nice if the completion script could be automatically enabled.
<ogra_> lundmar, well, the thing is that the snap itself doesnt not actually run on your system but inside the ubuntu-core snap ... all logic to hook something up to the outside world needs to happen in snapd and under special security observation
<ogra_> does not
<lundmar> it runs as a container?
<ogra_> no
<ogra_> but with the core snap as execution environment
<ogra_> or s/execution environment/rootfs/ ... however you want to put it :)
<lundmar> well, I did discover the snap is basically a squashfs so I did learn that haha
<lundmar> so snaps gets mounted and run by snapd within its own environment.
<lundmar> got it
<ogra_> yeah ... and interfaces allow them to talk to the outside world (or to specific acpects of the core snap)
<ogra_> aspects
<lundmar> still, the current completion system is outside. So I would figure this case simply requires and exception to the rule
<ogra_> indeed, but you also want to prevent a malicious snap from shipping some completion rule that can exploit some security issue in the bash-completion system to take over  your host system
<ogra_> so this needs very careful crafting
<lundmar> true
<lundmar> maybe the solution would be to qualify snaps somehow but that would kind of go against the agility of snaps I guess.
<lundmar> https://bugs.launchpad.net/snappy/+bug/1590767
<ubottu> Launchpad bug 1590767 in Snappy "Support snap installed completion scripts" [Undecided,New]
<ogra_> good
<lundmar> since it is pre-runtime it is difficult to see a solution that does not somehow require trusting that the application completion script is good.
<jdstrand> container/not container... ehh... it isn't a doc container. it is a snappy container if you will-- we use a bunch of things from the container world and then wrap it in apparmor (which can be thought of as a container) and seccomp
<jdstrand> s/doc/docker/
<jdstrand> basically, we use whatever we can to make things secure :)
<lundmar> ok, so simple a process with limited resources ^^
<ogra_> :)
<lundmar> simply*
<jdstrand> lundmar: bash completion is an interesting problem. I'm not sure if you saw the 'Man-pages in snaps' thread on snapcraft@, but ogra is right. hooking into completion means there is a way to execute code outside of the snap's confinement
<jdstrand> lundmar: can you file a bug and add the snapd-interface tag?
<ogra_> unlike man this isnt easily solvable by having a snapped binary in this case though
<lundmar> I figure it is kind of the same issue, maybe worse for completion but both are outside the reach of containers
<jdstrand> I can imagine ways to possibly do this
<jdstrand> ogra_: right
<jdstrand> lundmar: yes-- since it is a script
<lundmar> exactly
<jdstrand> but imagine we had a new executable: snap-completion
<lundmar> so, how to trust the completion script?
<jdstrand> imagine that runs under a restrictive apparmor profile
<jdstrand> bash is modified to call snap-completion <script> if <script> is in say //var/lib/snapd/completion
<jdstrand> or something
<jdstrand> basically, we get bash to run the script confined
<jdstrand> I'm not saying that is the way we would do it, but I think there are possibilities for making it work
<lundmar> bash ro to run the script confied? what does that mean? in the end the completion script will reside in the memory of the running bash session right?
<lundmar> confined*
<lundmar> I mean, once the bash completion script is sourced by the bash session it can do whatever it likes, just like the system installed scripts.
<ogra_> but your confined script would parse it first (under heavy restrictions)... and also run some content checks before it gets to bash
<lundmar> I think the question is, how safe are regular completion scripts and should snap comletion scripts be safer?
<lundmar> you can make checks if you like but any safeguards I suspect will be easy to circumvent
<lundmar> it is a tough seurity problem but snaps without man pages and completion scripts quickly gets painful I think.
<lundmar> security*
<ogra_> well
<ogra_> that really depends on the target audience
<ogra_> i guess 98% of computer users in the world do not know what a manpage is
<lundmar> sure, and for the point and click end users it is a non-issue.
<lundmar> but for experienced users it is
<lundmar> I figure snap caters for both
<ogra_> well, curretly snap focuses on attracting developers by making their life as easy as possible ... long term i think the point and click users are the target ...
<ogra_> but for the first we need to give the devs a comfortable way to ship manpages and completion scripts ... so it definitely is part of it
<ogra_> even if both features will pprehaps never be used by the final target audience
<lundmar> wouldnt be a proper package system without it ;)
<ogra_> *perhaps
<ogra_> well, i think since a long time that documentation should not be part of a package :)
<davidcalle> sergiusens: can you join us in 10-ish minutes on a hangout to talk about the blog post? (if not, that's alright, email will do)
<ogra_> but thats personal opinion
<lundmar> well, it is a set that needs to match so decoupling those is troublesome.
<ogra_> not if your packaging system would for example have an automated way to turn your shipped docs into versioned online docs and simply rip them out from the package
<lundmar> you cant trust online to be "online", bad idea - you can always trust man :)
<ogra_> i often enough find myself googling for a manpage instead of using my terminal ... and in the end read it on manpages.ubuntu.com
<ogra_> (though in the majority of cases where i need docs --help is even enough and that doesnt need any special system)
<lundmar> tsk tsk, and the you find an out of date man page and you don't even notice it.
<lundmar> then*
<ogra_> manpages are kind of and intersection between --help and a proper hwto
<ogra_> *howto
<lundmar> man pages are much more complete while --help is more or less just a listing.
<ogra_> yes, thats what i meant with "intersection"
<lundmar> I wouldn't do without manpages
<lundmar> neither completion scripts ^^
<ogra_> :)
<lundmar> anyway, I've created the bug report. I don't expect to see a solution due to the potential security issues.
<jdstrand> and I commented
<jdstrand> I think there might be a way to do it, but it would require a bit of design and engineering (and would need to be prioritiezed)
<lundmar> it surely requires some bash magic and maybe even internals changes
 * jdstrand nods
<lundmar> I guess if you could use a pipe to somehow bridge the normal bash session with a confined bash session running the actual completion function that might do the trick
<lundmar> but jez, it would take time to dig into that crusty ol code base of bash ^^
<lundmar> only problem is, what if the string feed is malicious?
<lundmar> tricky tricky tricky :)
<jdstrand> indeed
<seb128> what does "no handler to manage source" mean from snapcraft?
<jdstrand> we'd probably have to have an aggressive output filter, but I would think legitimate completion commands would pass that filter easily
<lundmar> jdstrand: probaly filtering out non-readable chars would solve the problem of malicious feed from the confined session
<lundmar> jdstrand: oh, we thought the same hehe
<jdstrand> non-readable, shell metachars
<jdstrand> yep
<lundmar> so, in the end it will depend on the state of bash internals ^^
<kgunn> jdstrand: i finally got round to a pr for mir
<kgunn> https://github.com/snapcore/snapd/pull/1299
<kgunn> i see zyga is out...
<kyrofa> seb128, it means you put something in the `source` key that snapcraft can't figure out
<kyrofa> seb128, or it uses a version control system that it doesn't currently support (e.g. svn)
<seb128> kyrofa, thanks, the error could be more descriptive :-)
<lundmar> what, snapcraft doesn't support CVS?? :D
<kyrofa> seb128, please log a bug! You're right, it could be more helpful
<seb128> kyrofa, I had "source: https://git.gnome.org/browse/gucharmap" works with "source-type: git"
<kyrofa> seb128, ah, yeah autodiscovery problem
<kyrofa> seb128, it doesn't hit the URL and figure it out, it does it by pattern on the source itself
<kyrofa> seb128, the only way it figures git out without `source-type` is if it ends in .git
<seb128> kyrofa, if the url contains "git" it could assume it's a git repo
<seb128> but fair enough
<kyrofa> seb128, also fair
<seb128> at least the message could state "can't figure source type, please specify one using source-type:"
<kyrofa> seb128, agreed
<ogra_> lundmar, write a plugin, patches accepted !
<lundmar> CVS is an abomination to be left behind.
<lundmar> chocked to still dicsover foss projects using it
<seb128> kyrofa, https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1590797
<ubottu> Launchpad bug 1590797 in snapcraft (Ubuntu) ""no handler to manage source" is not an helpful error" [Undecided,New]
<seb128> kyrofa, unsure if I should open another one for the " if the url starts with "http(s)://git" it could probably be autoguessed as being a git source" part?
<seb128> kyrofa, I would probably got as far as 'if contains "git"' but I guess 'start with http://git..." is a safe bet
<seb128> if you provide a svn repo on a git.something url you are asking for issues :p
<croepha> anyone here having trouble running docker containers under privileged mode? im getting `Error response from daemon: Cannot start container test: open /dev/dri: permission denied` I already tried chmod a+rwx /dev/dri  with no avail... any suggestions?
<ogra_> oooh
<didrocks> jdstrand: hey! in case you didn't notice, I asked a contributor to open a bug he's having on neovim: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1590720
 * ogra_ just noticed the "Price" column in snap find output
<ubottu> Launchpad bug 1590720 in snapd (Ubuntu) "neovim snap package freezes when saving a file (fchown)" [Undecided,New]
<ogra_> heh, old topic
<zyga> o/
<zyga> hello snappers :)
<ogra_> yo
<didrocks> hey zyga!
<dougb> Good morning all
<dougb> On BeagleBone Black, only ttyO0, the console serial, is enabled. How do I enable the other available serial ports in Snappy?
<didrocks> ogra_: do you know? ^
<ogra_> didrocks, i dont, sorry ...
<ogra_> seems you need to set a kernel cmdline var
<ogra_> hmm or not ... that seems to only work with hacked kernels that suppport capemgr
<ogra_> ours kernel is plain mainline without these patches
<croepha> so, is the snap that is a part of the 15.04 ubuntu core release the same snap that is part of the ubuntu 16.04 (non core) release?
<dougb> ogra_:Does that mean weâll have to wait for built-in functionality to be able to connect through the other serial ports?
<ogra_> dougb, well, i fear you would need a different kernel ... or find out how to enable UARTs on a non capemgr kernel
<dougb> That sounds like there are currently no plans for implementing this.
<ogra_> well, someone should probably create an rcn-ee kernel for the beaglebone
<ogra_> based off his tree
<ogra_> (building a kernel snap is rather trivial ... )
<croepha> im just jumping in here mid conversation, but if there is a kernel that works you can diff the configs to find out what you need to customize, might make thing easier
<ogra_> well, this is more about patch sets than configs
<ogra_> the beaglebone uses a patchset that has never made it upstream
<croepha> ahh ok
<ogra_> the only kernel we have in the store for beagle is rather close to mainline (the ubuntu generic kernel built for armhf actually ... )
<ogra_> so someone would have to roll a kernel with the capemanager patches specifically for the beaglebone and push it to the store
<jkridner> ogra_: those patches have gotten pretty small now that device tree overlays are mainline.
<croepha> so, is the snappy that is part of the 16.04 desktop release significantly newer than what is available in the latest core release? (15.04)
<ogra_> jkridner, ah, but i guess not in 4.4
<jkridner> not completely.
<ogra_> croepha, yes, there were no core images for 16 yet
<ogra_> they are about to happen soon
<ogra_> everyone focuses on desktop atm so people can create snaps ... images come once desktop has all the basics
<croepha> ogra_, I can wait, im just trying to understand the current state of things, would like to play around, but was confused by the differences between desktop and core
<ogra_> well, 15.04 was rather a first shot ...
<ogra_> the 16 series is the real thing ... and will be around for 5 years
<jdstrand> didrocks: responded
<didrocks> jdstrand: thanks a bunch! :)
<jdstrand> np
<dougb> ogra_: and the rest, thanks for the feedback. Iâll let you know what we come up with.
<ogra_> if you need any help, dont hold back your questions ;)
<dougb> Great!
<croepha> it seems like docker is missing from "snap find" on 16.04
<ogra_> yep
<croepha> haven't gotten to that one yet?
<ogra_> yeah, i guess ...
<ogra_> not sure who does it ...
<ogra_> lxc and lxd are also missing
<didrocks> elopio: hey! I don't see other command integration tests in integration_tests/* (apart from the lifecycle ones, but nothing about build and so onâ¦), am I looking at the right directory to add it?
<aatchison> Hmm, I canna get ubuntu-core to run on the pi 2 or 3 right now...
<aatchison> Are there any crazy daily builds or ultimate unstable beta images I could get my hands on? :D
<ogra_> aatchison, http://people.canonical.com/~mvo/all-snaps/ ... a bit outdated though
<ogra_> you can also use the ubuntu-device-flash from there to create more recent images
<aatchison> awesome! Thanks
<ogra_> note though that the gadget and kernel stuff is in flux ... so you will likely have to re-flash before we release the first official images
<aatchison> That's quite alright. I'm developing on the edge of chaos as well
<ogra_> :D
<croepha> so, in a snapcraft.yaml, is there a way to simply say, "install these apt packages" ?
<ogra_> yeah, stage-packages
<croepha> cool, thanks
<mhall119> sergiusens: I'm not the only one who's been bit by https://bugs.launchpad.net/snapcraft/+bug/1590834
<ubottu> Launchpad bug 1590834 in Snapcraft "cleanbuild leaves abandoned LXC containers" [Undecided,New]
<ogra_> mhall119, shhh ... dont reveal our secret contracts with seagate to trick people into buying larger disks fast !
<mhall119> also, is snapd supposed to remove old versions of snaps?
<ogra_> it does if you snap remove
<mhall119> but what if I'm just installing new versions?
<ogra_> it seems to not do it when you manually sideload snaps over and over
<mhall119> I currently have 5 versions of plank loop-mounted
<ogra_> right
<ogra_> i think thats a bug
<mhall119> ogra_: will it at least do it if you install updates from the store?
<ogra_> no idea, i know they are all wiped if you snap remove
<mhall119> yeah, but that's not ideal :)
<ogra_> i think if you have the store invlved you will always only have two revisions installed
<ogra_> (ICBW though)
<davidcalle> Well, first you collect planks, then you build cubes, then houses...
<mhall119> ogra_: https://bugs.launchpad.net/snapcraft/+bug/1590842 for that one
<ubottu> Launchpad bug 1590842 in Snapcraft "snapcrafting eats up disk space /dev/loop" [Undecided,New]
<davidcalle> Oh sorry, it's the snapcraft channel, not minecraft :p
<mhall119> davidcalle: :-P
<sgclark> yeah I have been snapcrafting tons, and I woke up this morning to a very cranky hard drive
<ogra_> we can probably get you a discount at seagate for a nice little raid array :)
<sgclark> lol
<ogra_> :)
<sgclark> I am eying a partition I do not use much anymore haha
<didrocks> elopio: I went ahead and added one in the integration_tests/ dir
<kyrofa> sgclark, the bug you just logged-- that's from `snap try`, yes?
<sgclark> no, have not heard of snap try
<sgclark> that is snap install
<kyrofa> sgclark, oh *cough* ignore me
<sgclark> what is snap try?
 * sgclark tries snap try next build
<kyrofa> So you're just installing the built snaps and finding that they stick around forever essentially?
<sgclark> yes
<sgclark> remove does indeed clear that all up, I am starting to get me disk space back lol
<kyrofa> sgclark, `snap try` will let you run directly out of the snap/ directory
<sgclark> ah ok
<kyrofa> sgclark, but it's not perfect yet-- if you `snap try` something and then `snapcraft clean` it up, snapd barfs all over you
<sgclark> oh haha
<kyrofa> sgclark, snapd will automatically clean that up soon, but for now, be aware: if `snap try`ing, `snap remove` it before `snapcraft clean`ing
<sgclark> would not be my first barf, but noted :)
<sgclark> k
<kyrofa> Regarding the snaps hanging around forever, that surprises me a little. I swear I saw code that only kept three revisions
<kyrofa> But maybe that doesn't apply to sideloaded snaps
<ogra_> kyrofa, well, has that landed in xenial yet ?
<kyrofa> ogra_, snap try?
<ogra_> the cleanup code
<sgclark> oh yeah I am in xenia;
<sgclark> xenial*
<kyrofa> ogra_, heh, sorry, which cleanup code? Cleaning up snap try, or cleaning up old revisions?
<ogra_> old revisions
<ogra_> :)
<sgclark> ok all cleaned up lol
<kyrofa> ogra_, I saw it like a month ago, so I'd say yes. But it may have been removed since then :P
<ogra_> heh, or renamed and nobody knew :)
<kyrofa> Maybe. I'll check
<kyrofa> Anyway, sgclark thanks for the report
<sgclark> np, happy to help
<kyrofa> ogra_, sgclark sounds like I saw old code that didn't apply anymore. It's planned though. I'm going to reassign the bug to snapd
<ogra_> yeah, i knew it was planned and i saw it discussed ... but it is definitely still here :)
<aatchison> Ok. I'm going to dig in as deep as I can here. I want to get my launch pad stuff all set up, including building debs.
<kyrofa> Hey aatchison!
<aatchison> hey!
<ogra_> hmm ... why dont we have a wine plugin yet ...
<ogra_> having such a thing would open up a completely new world for delivering windows apps to users :)
<sgclark> ooh indeed
<ogra_> (but also a can of legal worms most likely )
<sgclark> lol
<sgclark> there is that
<popey> i tried packaging wine itself
<popey> it almost works, might play again over the weekend
<ogra_> yeah, having it as a template to actually bundle apps might be interesting
<ogra_> you can bundle the actually working wine version then
<croepha> is there an online search for the snappy store?
<sergiusens> seb128 thanks for those bug reports, really helpful stuff!
<seb128> sergiusens, yw!
<wililupy> Question: Is there a way to build a kernel snap from a deb package?
<jdstrand> niemeyer: hi! would you mind commenting on https://bugs.launchpad.net/snappy/+bug/1590679/comments/6 ? I don't need it this second but would like to work on it tomorrow
<ubottu> Launchpad bug 1590679 in snapd (Ubuntu) "Apps can't own session bus names (unity7 interface)" [High,Confirmed]
<niemeyer> jdstrand: Will have a look later today
<jdstrand> awesome, thanks
<niemeyer> jdstrand: I need to step out now or will miss the window of sun :)
<jdstrand> get some vitamin D! :)
<sergiusens> elopio should this work `super(snapcraft.BasePlugin, self).build()` ?
<elopio> sergiusens: I'm wondering about the arguments of super in there. I suppose you are adding that because you are not in the snapcraft.BasePlugin class ?
<elopio> anyway, if you are not in the build method, and you can't just call it super().build(), it will probably do weird things. It might work for what you need, but I doubt it's a good idea.
<sergiusens> elopio I inherited a plugin for most of what it does, but I want to skip the parent's implementation and call the grandparent directly
<elopio> super().super().build()
<elopio> sergiusens: it's not so good either, you should doubt about your inheritance tree at this moment, because it's not a tree. But should work.
<sergiusens> elopio so I'll just copy then
<josepht> sergiusens: if you can modify the parent code you could add a method that invokes the grandparent's build() and nothing else
<sergiusens> josepht as super_build() :-)
<sergiusens> josepht feels dirty, but I guess that works
<sgclark> hi all, I see this quite often http://paste.ubuntu.com/17155796/ and I have network and network-bind plug, what am I missing?
<sgclark> most of our stuff has a newstuff feature for addons and the like
<sergiusens> elopio kyrofa https://github.com/ubuntu-core/snapcraft/pull/561
<sergiusens> sgclark that is dbus, right? network-* won't solve that, but jdstrand can
<sergiusens> :-)
<sgclark> lol
<sgclark> and yes
<sgclark> dbus
<sergiusens> sgclark for now I guess devmode is the fastrack path
<sgclark> yeah that works
<wililupy> How do I get ethtool and bridge-utils to be native? Should I add an app: section to my yaml to allow me to run these? also does snappy not look for other network devices other than ethx?
<wililupy> I added a udev rule to the system, but it doesn't seem to be working.
<jdstrand> sgclark: you need to specify 'plugs: [ network-manager ]' and after install do: sudo snap connect <snapname>:network-manager ubuntu-core:network-manager
<sgclark> jdstrand: ok thank you
<jdstrand> sure thing
<jdstrand> I'm stepping away now, but I read backscroll
#snappy 2016-06-10
<stevebiscuit> croepha: https://uappexplorer.com/apps?type=snappy is a community effort that accesses the store API, you can also install https://github.com/snapcore/snapweb
<tsimonq2> how would I go about using SVN with snappy?
<davidcalle> kyrofa: sergiusens ^
<tsimonq2> I don't prefer SVN, I'm just trying to make a snap for an application that uses SVN :)
<tsimonq2> from the looks of https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/sources.py , doesn't look like it
<ogra_> yeah, we dont have SVN or CVS support yet
<ogra_> two options:
<ogra_> 1) file a bug and wait
<ogra_> 2) write a plugin yourself and send a patch
<ogra_> (or 3 ... do bboth ;) )
<ogra_> *both
<tsimonq2> ogra_: would https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/internal/sources.py and https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/sources.py be the files to patch?
<ogra_> i never wrote a plugin myself ... but here is the commit that added support for zip files, perhaps you can deduct something from it https://github.com/ubuntu-core/snapcraft/pull/523
<tsimonq2> ogra_: BTW while I have you here, I submitted this a couple months ago, mind taking a look? :) https://github.com/ubuntu-core/snapcraft/pull/467
<tsimonq2> oh okay
<tsimonq2> I was just reading https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/internal/sources.py
<ogra_> tsimonq2, for that merge you want sergiusens or kyrofa
<tsimonq2> ogra_: alright :)
<tsimonq2> sergiusens, kyrofa: could you please take a look at https://github.com/ubuntu-core/snapcraft/pull/467 when you have the chance?
<ogra_> (not sure if we parse the output of apt-get or some such ... apt has definitely different output )
<ogra_> note that both of them are in US timezones ... might still take a bit til one of them gets up
 * tsimonq2 is in one too ;)
<tsimonq2> my sleep schedule is jsut a bit weird right now
<ogra_> heh
<seb128> dholbach, hey
<dholbach> salut seb128
<dholbach> comment Ã§a va?
<seb128> bien et toi ?
<seb128> dholbach, did you get issues with fonts being showing as squares in the galculator snap?
<dholbach> bien aussi, merci :)
<dholbach> seb128, I fixed it in ristretto by just adding fonts-freefont-ttf to stage-packages
<dholbach> for galculator I filed https://github.com/ubuntu/snappy-playpen/issues/46
<seb128> dholbach, k, you can fix it in the galculator one by uncommenting that line
<seb128> #ln -sf $SNAP/usr/share/{fontconfig,fonts,fonts-*,themes} $XDG_DATA_HOME
<seb128> unsure why you commented it
<seb128> I assume that line was copied from our gnome-calculator wrapper
<seb128> except we have it uncommented :p
<seb128> but maybe the stage package thing work too, thanks for the hint
<seb128> dholbach, commented on the issue ticket, thanks
<dholbach> seb128, I don't think *I* commented it
<dholbach> doing a test-build now
<dholbach> thanks seb128
<seb128> dholbach, sorry, the "you" was meant for whoever did those changes
 * seb128 hugs dholbach
<dholbach> right :)
<dholbach> always blaming me
<dholbach> seb128, maybe you can comment on https://github.com/ubuntu/snappy-playpen/pull/48?
<seb128> dholbach, done
<dholbach> cool, I'll just let the travis build pass, then merge it
<dholbach> thanks for the help!
<dholbach> seb128, I'm going to announce another event on tuesday, especially inviting upstreams and flavours
<dholbach> maybe in the week after that we can do some cleanup and see if we can agree on some common things to do in launchers and stuff
<seb128> dholbach, nice, I'm going to try to hang around with you guys
<seb128> yeah
<dholbach> awesome
<dholbach> not sure if you saw it, but we're also here: https://gitter.im/ubuntu/snappy-playpen
<dholbach> quite a few folks joined us through that channel
<dholbach> also the guy Andrew, who's working on the gimp-from-git snap
<tsimonq2> I'll finish SVN support and a Sylpheed snap later, off to bed, o/
<seb128> dholbach, I saw it mentioned, but I feel like etoomanycomchannel, irc/emails/telegram/hangouts/...
<beowulf> hi, anyone seen "cannot remove 'foo': snap 'foo' has changes in progress" and know how to fix it? :) https://pastebin.canonical.com/158483/
<seb128> dholbach, but I guess I can try to join a bit see how it feels
<seb128> beowulf, what version of snapd do you use? that was supposed to be fixed/improved in recent updates afaik
<dholbach> seb128, no worries - you can always open or close the tab whenever you feel like it ;-)
<dholbach> seb128, maybe you can take a look at https://github.com/ubuntu/snappy-playpen/pull/47 too?
<beowulf> seb128: how do i get the version?
<seb128> beowulf, dpkg -l | grep snapd
<seb128> dholbach, k, trying to do that in a bit
<beowulf> seb128: https://pastebin.canonical.com/158488/
<seb128> beowulf, sorry, "snap"
<dholbach> seb128, cool!
<beowulf> seb128: won't make a difference :)
<seb128> ?
<seb128> it should be installed
<seb128> oh
<seb128> not from inside the snap env
<seb128> if that's what you did
<seb128> from your machine
<beowulf> seb128: aaah, this is an ubuntu-core image as vm, running on vmware fusion on os x
<beowulf> seb128: the image was created from https://github.com/zyga/devtools about ~4 weeks ago
 * ogra_ is off to the dentist ... BBL
<seb128> beowulf, k, that's not a part of snap I'm familiar with, better to try to get a reply from mvo or zyga
<seb128> but snap has known issue around that which got fixed/improved in recent updates
<beowulf> seb128: no worries, thanks anyway :)
<seb128> maybe your version still had those
<beowulf> seb128: yep, will build a new image
<seb128> you might need to wipe your snap state/image :-/
<beowulf> seb128: yes, i've had this bug before and that's all i could do :(
<beowulf> seb128: powering off in the middle of snap install caused it the first time, this time it was uninstall
<beowulf> (not powering off during uninstall, just uninstall)
<seb128> yeah, I had the issue once on uninstall
<seb128> some process was still active which made the unmount fail
<seb128> and snapd was stucked from there on
<willcooke> Anyone know if the store will show (eventually?) show paid apps in the list of snaps *before* auth?  i.e. can I see all the paid apps before I've signed in to U1 in order to purchase them?
<mvo> jdstrand: I get seccomp killing of go-example-webserver on i386, the syscall is 123 - modify_ldt (which sounds scary). anything we can do ? or no golang on i386?
<dholbach> mvo, do you know if "snap refresh" (to update all installed snaps) is a priority?
<dholbach> people keep asking for it
<dholbach> or niemeyer1 ^
<zyga_> dholbach: it's implemented
<zyga_> dholbach: it's not released (in proposed now)
<dholbach> go go go
<dholbach> nice one
<dholbach> then we can update http://askubuntu.com/questions/760823/how-to-update-all-snap-packages again :)
<dholbach> Do we keep two ubuntu-core snap versions on the Desktop too?
<mvo> dholbach: its in 2.0.8 xenial-proposed
<dholbach> rollback too? :-)
<mvo> dholbach: almost ;) https://github.com/snapcore/snapd/pull/1275
<mvo> dholbach: need a second review ;) give it a +1 and it can land
<dholbach> haha
<dholbach> http://herbookthoughts.reads-it.com/wp-content/uploads/2014/06/d6a1143f571184db25f94613edd43b40af6d3a629221aba00d9efdcfef5efd84.jpg
<mvo> lol
 * mvo hugs dholbach
 * dholbach hugs mvo back
 * dholbach shows his ID: dholbach, head of rubberstamp deparment
<sergiusens> tsimonq2 we have a bug open for that, it would require someone to add it to snapcraft.internal.sources
<sergiusens> ogra_ we already have a bug, tsimonq2 it wouldn't be a plugin, just an extension to the core
<sergiusens> tsimonq2 I am hesitant to move to `apt` as it prints out it is not meant to be scripted yet
<sergiusens> mvo already tried that trick once :-P
<jdstrand> mvo: I read the man page and it says: EFAULT ptr points outside the address space.
<jdstrand> mvo: I think it is safe to use but I'll check with others
<ogra_> re ..
<ogra_> sergiusens, well, then just duplicate it :)
<mvo> jdstrand: ok, that would make the go-example-webserver work
 * jdstrand nods
<sergiusens> ogra_ it is hard from the tablet :-P
<ogra_> heh, i know what you mean :)
 * ogra_ has all new teeth \o/ ... still need to wait 1h til i can use them ... 
<tedg> Trying to install snapcraft on classic on snappy, getting this error. Not sure how to work around it.
<tedg> $ sudo apt-get install snapcraft
<tedg> sudo: no tty present and no askpass program specified
<ogra_> tedg, there is no classic on snappy
<ogra_> just about to be re-implemented ... gone since a few months already ...
<ogra_> i assume your image is really old
<tedg> Oh
<tedg> Perhaps that is why it doesn't work.
<tedg> Guess I'm going to have to figure out how to build things on Launchpad then.
<dholbach> jamiebennett, I'll create a tag for bugs called 'snap-docs', which we can use for snapd, snapcraft and developer-ubuntu-com, so we have one common tag to look at across the different projects and can organise a docs blitz - sounds good or would you prefer a different name?
<jamiebennett> dholbach: sounds good
<dholbach> cool
<dholbach> I'll go through the bug lists now and send an update to the list once I'm done
<ogra_> tedg, just use aa classic (server or desktop) install and install snapcraft there
<ogra_> we should have classic images for all arches
<tedg> ogra_: Was building to deploy on my raspi
<tedg> ogra_: So using it for arm builds
<ogra_> so use the mate image
<tedg> I was figuring I could use lxd
<ogra_> not sure we still have a working lxd snap ... i think that was dropped until it gets updated to the new world order
<dholbach> davidcalle, popey: where would you suggest we host a "top snap questions from askubuntu" list? (it'd be a cheap FAQ)
<davidcalle> dholbach: by "top" do you mean using AskUbuntu score or something we curate manually?
<popey> hmmmm
<davidcalle> dholbach: what about in snapcraft doc tree, as FAQ.md?
<davidcalle> (cheapFAQ.md ;-))
<dholbach> davidcalle, curated manually - I just went through the list
<dholbach> davidcalle, or just in the CMS?
<dholbach> some of the questions were related to snapd too
<roadmr> ey folks, I'm trying to snap a tool which consists of a backend with several possible frontends (f1, f2...). I could snap backend and frontends separately but this replicates the .deb pattern. I could also bundle one or more frontends with the backend. But the snaps would look like backend-f1, backend-f2... which is confusing. OR I could name the snaps after each frontend (f1, f2) and implicitly include the
<roadmr> same backend in all. Which pattern makes the most sense?
<qengho> roadmr: You could have several commands in one package called "roadmr":  roadmr.frontend1, roadmr.frontend2
<roadmr> qengho: righto, but do you think it's ok to ship the frontends in a package named after the backend?
<qengho> roadmr: I think you have to decide if a user is likely to use more than one frontend. If not, and if it saves a lot of space, separate.
<qengho> roadmr: Hmm, if you separate, I'd have a daemon run silently and name the package roadmr-frontend1
<roadmr> qengho: good idea... a user is likely to prefer the frontend which works best with their desktop environment. I can see if the 2-3 most popular ones can be included without making the snap too huge :D
<qengho> roadmr: One of our assumptions with Snappy is that storage is dirt cheap. But, embedded storage and bandwitdth isn't necessarily cheap. Pick what's sensible for your audience.
<roadmr> qengho: will do :) this is a strictly desktop package, so I can more or less safely assume cheapish resources. Time to think... thanks!
<qengho> roadmr: Yeah, in desktop land 1 GB is about US$0.05, so....
<croepha> stevebiscuit: Thanks
<croepha> so, will there be a good upgrade path from core 15.04 to 16.10? Could one ship on 15.04 and then do a snappy update and be running 16.10 ?
<netphreak> hi, guys!
<netphreak> where can i find the latest Ubuntu snappy for rpi3?
<ogra_> netphreak, you can generate one using ubuntu-device-flash
<ogra_> grab the binary from http://people.canonical.com/~mvo/all-snaps/
<netphreak> I suppose this one should do the trick?
<netphreak> rpi2-all-snap.img.xz
<ogra_> well, thats pretty old, but yes, it should boot
<ogra_> kenrel and gadget are currently the same for both pi images
<netphreak> well. i suppose it's updatable afterwards?
<ogra_> no guarantees
<ogra_> gadget and kernel are currently being reworde (and ubuntu-device-flash is being deprecated soon) ...
<netphreak> ok.. lots of stuff happening..
<ogra_> they can break on updates (which is why we have no officially released images yet)
<ogra_> **reworked
<netphreak> Any indication when a supported/stable rpi3 image will se the light of day?
<ogra_> a few week we should have a first one
<ogra_> *in a few weeks
<netphreak> nice to hear..
<ogra_> good enough to not break on upgrades but most likely not feature complete
<netphreak> Until then.. I need a rpi3 image to experiment with snaps etc.
<sergiusens> stevebiscuit where is webdm these days, I have a gulp plugin almost ready
<ogra_> sergiusens, for all arches ?
<netphreak> ok.. i will try it out.. I suppose it can upgrade to the latest snap and snapcraft packages?
 * ogra_ remembers that he gave up trying to get gupl building on arm64 back when he tried
<ogra_> *gulp
<sergiusens> ogra_ is there node for arm64?
<ogra_> sure
<sergiusens> then it could work, yes
<ogra_> but i think there were deps that couldnt build for gulp ...
<ogra_> some filesystem support bits
<ogra_> iirc gulp has a horridly long list of deps
<sergiusens> ogra_ I need regular ubuntu on my dragon board and then I can test ;-)
<sergiusens> ogra_ or 64bit on my tablet :-P
<ogra_> there should be a d-i image ... ask infinity
<qengho> I'm worried about armhf support. Without a tight update/feedback loop, it's going to have tons of bugs on release day.
<ogra_> well, the images will be fine ... we'll make sure
<ogra_> snaps .. probably nnot so much
<netphreak> has classic mode been introduced in snappy?
<ogra_> not yet
<netphreak> how would i go about it if i need apt-get dependencies and snappy/snapcraft swell?
<ogra_> use the mate image
<netphreak> thx.. wil try this out.
<ogra_> or pull an ubuntu-base tarball from cdimage and scp it to your snappy install
<qengho> snappy on classic?
<ogra_> yep
<qengho> It doesn't still try to set the bootloader and crash on installing ubuntu-core snap?
<ogra_> shouldnt
<ogra_> (on classic at leaast)
<netphreak> i'll try the mate..
<netphreak> can't seem to find a mate image for armhf?! on rolling?
<ogra_> https://ubuntu-mate.org/
 * ogra_ needs to go out for some errands ... back later ...
<qengho> ogra_: Just tried. Mate can't run snaps either. Not snapd=2.0.5 or =2.0.8~ppa123-1 .
<qengho> netphreak: I'm interested in what you get.
<netphreak> i'm still downloading a mate image..
<ogra_> qengho, hmm, i thought flexiondotorg preinstalls snapd on the mate images
<flexiondotorg> ogra_, I do.
<ogra_> flexiondotorg, on armhf too ?
<flexiondotorg> ogra_, Known issue.
<ogra_> oh, ok
<flexiondotorg> The Raspberry Pi images used the Rpi Foundation Kernel.
<flexiondotorg> So snappy is not an option.
<ogra_> ah, right
<ogra_> yeah, we need to sync up about that
<ogra_> i need the userspace bits and you need my kernel with pproper graphics support
<flexiondotorg> I am working on making alternate images that use a proper Ubuntu kernel, the raspi2-kernel you use.
 * qengho cries for nightly images and no assumptions.
<flexiondotorg> But, as you say, some hardware support is absent from the Ubuntu kernel right now.
<ogra_> right
<ogra_> i'll be at the kernel sprint next week and will try to get this sorted
<ogra_> (and probably pick your brain during the week :) )
<ogra_> qengho, everyone does
<flexiondotorg> I was contacted on Telegram by another Ubuntu dev who said, perhaps you, were working on the Ubuntu kernel for the Pi?
<ogra_> thats probably ppisati
<flexiondotorg> ogra_, Please do.
<ogra_> though i wasnt aware he is a telegram user :)
<flexiondotorg> Ill dig our some communication I've had from the Raspberry Pi Foundation regarding patches that are required for Pi 3 support.
<flexiondotorg> However, bluetooth is a mess.
<flexiondotorg> The patches for BlueZ are Pi 3 specific and will break Bluetooth for some other devices.
<ogra_> well, the rapi2 kernel works pretty well on the pi33 ... for the generic stuff at least
<flexiondotorg> So I maintain a patch BlueZ package for the Pi 3 in a PPA.
<flexiondotorg> We can't put it in the archive because *it will* break stuff.
<ogra_> well, a snap will help ;)
<kyrofa> sgclark, can I safely assume you're a qmake wizard?
<sgclark> I am not lol
<kyrofa> sgclark, heh, darn
<sgclark> sorry :(
<kyrofa> sgclark, do any of the projects you're snapping use qmake?
<sgclark> nah cmake
<kyrofa> Ah, a real build system ;)
<sgclark> well there was qt, but I gave up on that one for a bit
<kyrofa> sgclark, alrighty-- I was just working on a qmake plugin for snapcraft, so if you come across a qmake project I'm sure it could use a good test
<sgclark> ok, I do know we have some deps that use qmake. Just have not got to one yet. I will let you know when I do.
<seb128> hum
<seb128> is that a known issue?
<seb128> error: cannot list snaps: cannot list local snaps! cannot find mounted snap "cap-test" at revision 9
<kyrofa> Alright, I'd appreciate it!
<kyrofa> seb128, were you using `snap try` by any chance?
<seb128> kyrofa, not that I remember, but I didn't use that laptop for some weeks
<seb128> I just dist-upgraded earlier
<seb128> and I tried to install freshly built local snap
<kyrofa> Oh, huh. Not sure then... you can try manually unmounting the snap?
<seb128> snap remove cap-test?
<seb128> error: cannot remove "cap-test": cannot find mounted snap "cap-test" at revision 9
<kyrofa> seb128, is cap-test contained within /snap/ ?
<seb128> $ ls /snap/
<seb128> bin  gucharmap  ubuntu-core  webchat
<kyrofa> Huh... it sounds like the client and server are out of sync
<kyrofa> Some state issue
<kyrofa> You probably need mvo
<kyrofa> Or niemeyer
<seb128> mvo, hey :-)*
 * niemeyer raises head
<niemeyer> seb128: Did you use "snap try"?
<niemeyer> nm, see the same question/answer above
<seb128> niemeyer, not that I remember, but ...
<seb128> right
<niemeyer> kyrofa, seb128: Issue is known, generally happens when something is fiddled with by hand, or snap try now
<niemeyer> We know what we want to do to fix it, but didn't get to it yet
<seb128> any workaround?
<niemeyer> seb128: Try this hack please:
<niemeyer> mount --bind /snap/ubuntu-core/current /snap/cap-test/9
<niemeyer> You'll need to mkdir -p /snap/cap-test/9 first
<seb128> niemeyer, works now!
<seb128> niemeyer, thanks
<niemeyer> seb128: Okay, please try removing snap-cap now
<niemeyer> Erm
<niemeyer> cap-test
<niemeyer> seb128: snap remove cap-test
<jdstrand> mvo: fyi, https://github.com/snapcore/snapd/pull/1304 for modify_ldt and others
<seb128> error: cannot remove "cap-test": snap "cap-test" is not removable
<niemeyer> Haha.. bad choice of me
<seb128> I guess I can do the same with another snap
<niemeyer> seb128: Yes, please.. please be careful as it may actually remove the real snap.. I didn't try that locally yet
<niemeyer> seb128: Clearly on that one instance above it looked at the real name instead of one it was looking for
<niemeyer> seb128: Let me know if it works, please
<seb128> niemeyer, 2016-06-10T19:05:11+02:00 ERROR cannot remove snap file "cap-test", will retry: remove /snap/cap-test/9/command-gucharmap.wrapper: read-only file system
<seb128> niemeyer, I'm going to use the wipe script I think and start fresh
<seb128> thanks for the help
<seb128> but going to be easier this way
<niemeyer> seb128: Wait wait..
<seb128> k
<seb128> $ sudo snap changes
<seb128> ID      Status  Spawn                 Ready                 Summary
<seb128> MJ8qKQ  Undo    0001-01-01T00:00:00Z  2016-06-10T17:06:19Z  Remove "cap-test" snap
<seb128> k1Kq78  Undo    0001-01-01T00:00:00Z  2016-06-10T17:06:19Z  Install "webchat" snap from "" channel
<seb128> nbW67x  Undo    0001-01-01T00:00:00Z  2016-06-10T17:06:19Z  Install "cap-test" snap from "" channel
<niemeyer> seb128: That makes no sense.. it shouldn't be removing content inside that directory. This is typically read-only.
<niemeyer> seb128: Whaaaaaat
<niemeyer> seb128: Those IDs!
<seb128> go figure...
<niemeyer> seb128: Those dates!
<niemeyer> seb128: This is a *super* old snapd release.. as in, pre 16.04
<seb128> niemeyer, ii  snapd                                                2.0.5                                               amd64        Tool to interact with Ubuntu Core Snappy.
<niemeyer> seb128: This is definitely not 2.0.5
<seb128> but that system was used pre xenial
<niemeyer> _definitely_
<seb128> is there a "snap -v" or "snap version"?
<niemeyer> seb128: Not on that release :)
<niemeyer> seb128: But you can trust me on that one.. the snapd process that is in your memory is ancient
<seb128> I'm pretty sure I rebooted after this morning dist-upgrade
<niemeyer> seb128: Again, it's not a this morning thing
<niemeyer> seb128: The 16.04 image did not ship with that release
<seb128> well, I did sytemctl stop/start snapd
<seb128> as said that laptop is older than xenial
<seb128> but is on current uptodate xenial today
<niemeyer> seb128: Have a look at the hash and compare to the 2.0.5 package
<seb128> but maybe the core image or whatever is left in the past
<niemeyer> seb128: If it matches, please have a look at the process uptime on ps
<seb128> niemeyer, http://paste.ubuntu.com/17177210/
<seb128> sorry the output got cut earlier
<seb128> which created the confusionb
<seb128> so I guess version/status is normal
<seb128> it's just stucked on "doing" because of the umount error
<seb128> I tried to abort it
<niemeyer> seb128: Aha!
<niemeyer> seb128: Look at the transition here:
<niemeyer> nbW67x  Undo    0001-01-01T00:00:00Z  2016-06-10T17:06:19Z  Install "cap-test" snap from "" channel
<niemeyer> 1       Done    2016-06-10T16:48:10Z  2016-06-10T16:49:42Z  Install "gucharmap" snap from file "./gucharmap_9.0_amd64.snap"
<niemeyer> Specifically, note the Ready timestamp
<niemeyer> seb128: You had a pre-release snapd running on your system until today
<seb128> right
<seb128> I upgraded this morning
<seb128> rebooted
<niemeyer> Yep
<niemeyer> All good
<seb128> and then tried to install a snap i built today
<niemeyer> Reset the state please.. it's the right thing to do in this case specifically
<seb128> k
<seb128> thanks
<seb128> and sorry for the noise
<jdstrand> roadmr: curious, did the revew tools changes land?
<niemeyer> seb128: Please don't do that in general to get you out of trouble, please
<seb128> can somebody remind me the url of the reset script?
<jdstrand> roadmr: and hi!
<niemeyer> seb128: We very much want to follow up on any problems closely
<seb128> niemeyer; right, issues on current versions should be properly  looked at
<niemeyer> Yeah
<seb128> thanks again for the help!
<tsimonq2> sergiusens: about apt, understood
<tsimonq2> sergiusens: and yeah, I'm not writing it as a plugin, I'm adding it to the same file as Git or Bazaar
<tsimonq2> (etc.)
<tsimonq2> sergiusens: and is there an open bug I can assign myself to?
 * tsimonq2 looks around quick
<sergiusens> tsimonq2 yeah, kyrofa created one
<tsimonq2> yep found it
<tsimonq2> bug 1543243
<ubottu> bug 1543243 in Snapcraft "Sources missing support for Subversion" [Wishlist,Triaged] https://launchpad.net/bugs/1543243
<kyrofa> tsimonq2, awesome! I didn't know anyone else cared about that one, heh
<seb128> sergiusens, kyrofa, do you remember where I can find the snappy wipe script?
<qengho> seb128: if a snap isn't unmountable, use "lsof" to find processes with open files beneath its mountpoint.
<kyrofa> seb128, indeed: https://github.com/zyga/devtools/
<seb128> kyrofa, thanks
<seb128> qengho, yeah, but in this case the snap state is from a prerelease version I better wipe it
<tsimonq2> kyrofa: I really really hate it and I want Git for everything, but I want a Sylpheed snap
<tsimonq2> so I can manage :D
<kyrofa> tsimonq2, indeed, there are simply some things that are still using svn
<qengho> seb128: At "apt purge snapd", you'll get a list of four dirs that are not emptied. "rm" all of those. Then install snapd. That resets.
<tsimonq2> yep kyrofa
<seb128> qengho, thanks, using https://raw.githubusercontent.com/zyga/devtools/master/reset-state which does the job (I used it before)
<roadmr> jdstrand: hello! hey sorry for not letting you know - yes, as of yesterday
<roadmr> jdstrand: the store should be at r678 of click-reviewers-tools
<ogra_> niemeyer, it would probably make sense to ship the reset script somewhere hidden in /usr/lib/snapd though, so people dont need to fiddle so much until this prob doesnt show up anymore
<ogra_> (i.e. we can tell them to use that script after they submitted a bug)
<niemeyer> ogra_: Definitely not
<ogra_> niemeyer, oh, why ?
<niemeyer> ogra_: This specific problem does not exist in practice.. it was a pre-16.04 snapd in use
<ogra_> (i dont mean anywhere in PATH)
<ogra_> oh
<niemeyer> ogra_: and I've been trying to strongly discourage people from resetting state
<ogra_> sorry then, i thought that was recent->recent
<niemeyer> ogra_: np.. the state there was indeed super old in this case
<ogra_> missed that bit above
<ogra_> yeah
<ogra_> 0001-01-01 :) ... baby jesus ... :)
<seb128> sergiusens, kyrofa, does snapcraft autotools plugin allows to specify extra cflags?
<mvo> jdstrand: \o/
<tsimonq2> sergiusens: come onnn, the least you could do is change apt-get to apt in the HACKING.md..?
<tsimonq2> :P
<tsimonq2> sergiusens: or would you accept a patch for that?
<sergiusens> tsimonq2 sure, that is fine :-)
<sergiusens> tsimonq2 I use `apt` everywhere fwiw and mvo gave me the magic bits to pass to `apt-get` to make it pretty print like `apt`
<tsimonq2> oh alright :)
<sergiusens> elopio mind looking at the skipped test here? https://github.com/ubuntu-core/snapcraft/pull/563
<sergiusens> beowulf mind taking a look at this as well https://github.com/ubuntu-core/snapcraft/pull/563 ?
<seb128> sergiusens, saw my question. :-)
<tsimonq2> sergiusens: your PR :) https://github.com/ubuntu-core/snapcraft/pull/564
<kyrofa> sergiusens, elopio how do I edit the parts wiki?
<kyrofa> Do I need special permissions?
<kyrofa> popey, do I need special permissions to edit the snappy parts wiki?
<kyrofa> josepht, leo is coming now :P
<josepht> kyrofa: k, otw
<kyrofa> josepht, thanks for coming back :)
<josepht> kyrofa: my pleasure
<beowulf> sergiusens: i added a couple of comments
<sergiusens> seb128 sorry, what question?
<roadmr> so I'm snapping a gtk2.0 app and when it comes up, all the text in the gui shows as empty squares. Any idea what I need to do for this snap to work? I included a zillion libs as stage-packages but to no avail.
<tsimonq2> sergiusens: didn't dholbach have the same problem? do you know who might know? ^
<sergiusens> tsimonq2 I am not a freedesktop.org expert
<tsimonq2> alright sergiusens :)
<popey> roadmr: have you seen the gnome calculator example in snappy-playpen?
<roadmr> popey: no!! where is that?
 * roadmr gets all giddy
<roadmr> popey: oh I found it!
<roadmr> ugh, that's horrible...
<tsimonq2> sergiusens: sorry for the direct ping, but I'm kinda stuck in getting svn support, I'm getting the following error when trying to run snapcraft snap with an svn part: Could not find a required package in 'build-packages': "The cache has no package named 'svn'"
<tsimonq2> works fine otherwise
<tsimonq2> where am I missing integration
<tsimonq2> I mean, doesn't it have to be missing somewhere?
<tsimonq2> http://paste.ubuntu.com/17187288/
<tsimonq2> that's my working snapcraft.yaml file
<sergiusens> tsimonq2 it is `subversion` what you want to install, not svn
<sergiusens> iirc
<sergiusens> yup, change that in snapcraft.internal.sources
<sergiusens> should be good after that
<tsimonq2> \o/
<tsimonq2> let's see now
<roadmr> popey: so that wrapper script is horrendous but it worked - many thanks :)
<tsimonq2> yay now errors I have to fix :|
<tsimonq2> sergiusens: thank you :)
<tsimonq2> sergiusens: is there a place that logs are kept for builds?
<roadmr> dumb question - each snap is mounted in /dev/loopXX. Is there a limit to how many loop devices there can be?
<roadmr> (which, seems to me, would limit the number of installable snaps)
<popey> roadmr: yay
<tsimonq2> upon Googling, you can adjust it
<tsimonq2> which, if the developers weren't aware that > 64 needs a tweak, then they need to know!
<stgraber> that's what loop-control is for IIRC
<tsimonq2> stgraber: really? what's that?
<tsimonq2> and imho it's annoying when I try to use loop devices for something :P
<roadmr> good night folks!
<tsimonq2> YES! FINALLY! jeez, that took 3 hours, SVN support PR incoming!
<tsimonq2> s/3/\> 3/g
<tsimonq2> https://github.com/ubuntu-core/snapcraft/pull/567
<elopio> tsimonq2: much appreciated. I left some comments in the PR, and I'll be around for a couple more hours.
<elopio> actually, maybe more. I'm trapped in a restaurant and there's a storm outside :( I want to leave!!!
<tsimonq2> elopio: will you be around tomorrow?
<tsimonq2> I'm off to a party very soon, but I wanted to check in here before I go
<elopio> tsimonq2: probably.
<tsimonq2> then expect it to be all shiny tomorrow :)
<tsimonq2> I'm off o/
<sergiusens> elopio I forgot to add the unit tests which I wanted you to look at, can you look again at the gulp one
 * sergiusens is not hear, sneaking from the family to send this :-P
<elopio> sergiusens: I think you would be better setting the env var with the fixture, instead of trying to patch. But go back to the family, this is for monday.
<mhall119> d_ed: sgclark: Is snappy going to be part of the distribution discussions happening at Randa next week? Is there any information or resources we can provide you ahead of time to make that more productive?
<d_ed> mhall119: yeah.
<d_ed> mhall119: there's gonna be a group working on deployment from windows, to OS X to flatpak to snappy
<d_ed> trying to find some more common things, as currently everyone is doing their own thing
<d_ed> as for Snappy, I think we're only going to know what extra info we need when we hit it
<d_ed> and I know that's not a very helpful response
<d_ed> oh, one huge question:
<d_ed> sandboxing and DBus
<d_ed> I go the impression the session and system socket were completely blocked off
<d_ed> *got
#snappy 2016-06-11
<mhall119> d_ed: they aren't completely blocked, but access to them is mediated so apps can be given what they need and nothing more
<d_ed> mediated by apparmor in the dbus server?
<mhall119> access is determined by what "interface" they have a plug for, and that plug being connected (either automatically or with user concent, depending on the interface) to the appropriate slot
<mhall119> d_ed: I believe it's apparmor, yes, but jdstrand or mdeslaur can probably confirm
<mhall119> on distros without apparmor, snaps will have to run without confinement until an alternative can be integrated
<d_ed> oh that's another topic I want clarifying:
<d_ed> do you intent for snaps to be a thing on non Ubuntu platforms?
<mhall119> absolutely
<d_ed> most the snaps are linking against libs from the system aren't they?
<mhall119> at the very least, other Linux platforms
<d_ed> rather than all being in the snap layers
<mhall119> no, they link against the "core" snap, which is a stripped down Ubuntu
<mhall119> and soon they will be able to link to libs in a common shared snap
<mhall119> so the snappy system should be insulated from the host system
<mhall119> which would allow snaps to run on Fedora, for example, without knowing or caring that they're on Fedora
<mhall119> d_ed: importantly, snappy as a project is welcoming to any changes/patches that are needed to make it work on other distros
<d_ed> ok, and when buidling with snapcraft we can link .deb depencies, that'll always be Ubuntu ones because it's all from that core snap
<sgclark> mm I don't think so
<sgclark> I am using Neon debs atm
<mhall119> I don't think the deb dependencies are necessarily related to the core snap, that was just a shortcut to getting pre-build binaries into the snap filesystem
<sgclark> and I am going to be so overwehlmingly busy next week, I don't know that anything can help me lol. I also have to get all these things on my kde ci
<sgclark> but hey, can't complain, I will be busy in the comfort of the Swiss alps.
<mhall119> yeah, that's a pretty sweet sprint location
<d_ed> RE DBus: It is restricted in the apparmor profile of the relevant snap
<d_ed> with a lovely whitelist for gtk things
<sgclark> hah
<d_ed> but we can ship our own apparmor profiles, so that's quite good
<sgclark> ok cool
<mhall119> d_ed: ideally for KDE apps we would minimize most of the .deb dependencies, and build frameworks and qt
<sgclark> I think we might go the opposite
<sgclark> actually. to reduce repeat work
<d_ed> we're building our for flat-pak
<mhall119> d_ed: it's in the profile, yes, the snap's meta-data is used to generate a custom profile from a pre-defined template
<sgclark> I am getting the latest and greatest using neons debs
<sgclark> anyway, i am trying it, sitter asked me too and I have a hard time saying no to him lol
<d_ed> allows us to tweak a few things to be better suited for running containerised (KDE_FORK_SLAVES for example, as we can't reach klauncher)
<d_ed> :D
 * mhall119 is in over his head with that
<mhall119> d_ed: you're building apparmor profiles for flatpak?
<d_ed> no, no, we build our own frameworks and Qt
<mhall119> oh, ok
<mhall119> then yes, that can be reused to build snaps
<d_ed> flatpak doesn't use apparmor for DBus filtering, instead you have a proxy process (per "pak") that acts as a gateway between two busses
<d_ed> it's a bit over complex
<mhall119> do apps need to target that proxy specifically, or is it like a transparent proxy that looks like dbus?
<d_ed> in theory or in practice?
<mhall119> you mean they're not the same? :)
<sgclark> lol
<d_ed> the difference between theory and in practice, is that in theory, they're both the same
 * mhall119 loves that saying
<sgclark> lol
<sgclark> ok I have to finish packing, leave tomorrow, see you Sunday d_ed!
<d_ed> see you
<d_ed> mhall119: I assume adding custom plugs/slots would be changes to snappy?
<mhall119> d_ed: so snapd defined "interfaces", on one side of which is a plug and the other side is a slot
<mhall119> interfaces for now are built into snapd itself
<mhall119> but any snap can provide a plug or a slot for one of those interfaces
<d_ed> ah! that's quite nice
<mhall119> an example I'm looking at currently is Elementary's Contractor dbus service. That we would add to snapd as an interface, then they would provide a pantheon slot for that interface, and geary would provide a plug for it, and then snappy would connect the two together
<mhall119> interfaces are fairly new, and I don't think anybody knows yet how we're going to scale that out, but having more use-cases like Contractor will help us figure that out
<mhall119> sgclark: have a safe trip
<mhall119> and you too d_ed :)
<d_ed> more questions: My Ubuntu box runs snaps with "ubuntu-core-launcher" is this replaced by "smap-confine" ?
<mhall119> sgclark: d_ed: I will be off work on Monday, though probably online, you can ping me if you need more information. Or just ask in here, which should be more active during Randa's daytime :)
<mhall119> d_ed: that I don't know, several things are being renamed to be less "ubuntu-" and more distro-agnostic, so it could be
<d_ed> edit, git logs says it is
<d_ed> should have done that first
<mhall119> snappy is evolving rapidly right now, which is part of the reason we want to have as many examples and use-cases from outside of Ubuntu and our apps as we can, so they can help direct that evolution
<mhall119> d_ed: sgclark: something else you might be interested in, the snap store has beta-testing channels now, and snapcraft can push updates there from the command-line, so it's possible to use your CI infrastructure to publish the very latest updates to people who want to subscribe to that channel
<d_ed> fyi, snapd doesn't appear on the repo listings of https://github.com/ubuntu-core
<sgclark> mhall119: oh cool!
<d_ed> but typing it manually works
<mhall119> d_ed: It's on https://github.com/snapcore
<d_ed> s/snapd/snappy
<mhall119> again, moving away from ubuntu-* naming for this
<d_ed> ah ok
<d_ed> makes sense
<d_ed> then I'm finally out of questions
<mhall119> I'm sure that will chance come Monday :)
<sgclark> yes
<mhall119> as I said, folks in here on Monday will be able to answer any other questions you have, and I will be off-and-on around on Monday and then back fully on Tuesday
<mhall119> I hope you both enjoy the Alps
<sgclark> ty
<tsimonq2> so when I try to execute snaps, I get the following error thrown at me: failed to create user data directory. errmsg: Permission denied
<tsimonq2> anyone know what's going on here?
<zyga> o/
 * zyga gets to work
<lundmar> hi, is it possible in a snap .yaml to somehow reuse eg. the version as a value in eg. source?  For example: source: https://github.com/tio/tio/releases/download/v$version/tio-$version.tar.xz ?
<lundmar> *variable
<lundmar> hmm, why does a 1.20 version collapse into 1.2? Does snapcraft really force this type of version scheme?
<lundmar> hmm, version: "1.20" did the trick so it does not collapse to 1.2
<lundmar> yaml magic aye
<zyga> lundmar: not today. but recall that snapcraft generates snap.yaml
<zyga> lundmar: so there's a lot of room for variables and other stuff
<zyga> lundmar: but the proper layer is above snap.yaml,
<zyga> lundmar: so that complexity on snapd is not increased
<lundmar> zyga: it's one of those convenience things. Would be nice not having to change the .yaml in multiple places just to bump version.
<zyga> lundmar: and it is possible, just do it in snapcraft
<lundmar> zyga: I'm not sure what you mean, I'm already using snapcraft - here is my snap: http://pastebin.com/zPZ62zyE
<lundmar> I don't know of any way to reuse version in eg. source but I'm not yaml expert either.
<zyga> lundmar: sorry, I meant that this is something that snapcraft could support
<zyga> lundmar: then the variable could be used in snapcraft.yaml
<lundmar> zyga: got it.
<zyga> lundmar: and then snapcraft would replace the variable and generate the same snap.yaml we support today
<zyga> lundmar: putting the complexity where it hurts less
<lundmar> it would probably be a good feture for select key variables like version, name etc.
<lundmar> feature*
<zyga> jdstrand: do we have to support ~/.config/pulse/cookie?
<tsimonq2> sorry for the repeat, but when I try to execute snaps, I get the following error thrown at me: failed to create user data directory. errmsg: Permission denied
<tsimonq2> anyone know what's going on here?
<tsimonq2> that's for multiple snaps
<tsimonq2> I even have a snap *I* created in devmode that doesn't work because of that error
<tsimonq2> I'll fire up a clean VM and try, but it's just really...annoying
<qengho> tsimonq2: $ apt policy snapd; dmesg     # to pastebin
<tsimonq2> qengho: http://paste.ubuntu.com/17222462/
<tsimonq2> that's apt policy snapd
<tsimonq2> http://paste.ubuntu.com/17222480/ - and this is dmesg
<qengho> tsimonq2: You should have 2.0.5 if you're on 16.04.
<tsimonq2> qengho: I'm on Yakkety
<tsimonq2> qengho: do I have to install a PPA then?
<qengho> Oh, then you should have 2.0.8 or something!  :)
<qengho> Actually, I don't know that^. I'll verify.
<tsimonq2> !info snapd yakkety
<ubottu> snapd (source: snapd): Tool to interact with Ubuntu Core Snappy.. In component main, is optional. Version 2.0.2 (yakkety), package size 2745 kB, installed size 14700 kB
<tsimonq2> !info snapd xenial
<ubottu> snapd (source: snapd): Tool to interact with Ubuntu Core Snappy.. In component main, is optional. Version 2.0.5 (xenial), package size 2693 kB, installed size 14624 kB
<tsimonq2> qengho: ^ :)
<tsimonq2> O_O huh?
<qengho> Ugh.
<tsimonq2> well how does that work? :P
<tsimonq2> I'll manually install the Xenial packages for now
<qengho> It's technically possible, but weird because updating stable released (especially LTS!) is really hard, but updating the devel line is dead easy.
<tsimonq2> yeah
<tsimonq2> in fact, it probably should have went to Yakkety first
<tsimonq2> because wouldn't it require an SRU?
<qengho> Yes, unless it has an exception, and this might have one because it's new and not "released" yet. I don't know, here.
<qengho> tsimonq2: Anyway, after .5, let us know if it still happens.
<tsimonq2> I'm getting .8 from Launchpad :D
<tsimonq2> :/ still
<tsimonq2> [54353.152981] audit: type=1400 audit(1465669563.399:43): apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/home/.ecryptfs/simon/.Private/" pid=9481 comm="ubuntu-core-lau" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
<tsimonq2> [54353.152986] ecryptfs_dir_open: Error attempting to initialize the lower file for the dentry with name [/]; rc = [-13]
<qengho> $ systemctl restart snapd.service   # try this
<tsimonq2> nope still
<tsimonq2> does it help to know that I have an encrypted home directory?
<qengho> tsimonq2: That second message is really weird.
<qengho> I can tell you have one, silly.
<tsimonq2> [54445.418517] audit: type=1400 audit(1465669655.670:44): apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/home/.ecryptfs/simon/.Private/" pid=9549 comm="ubuntu-core-lau" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
<tsimonq2> [54445.418521] ecryptfs_dir_open: Error attempting to initialize the lower file for the dentry with name [/]; rc = [-13]
<tsimonq2> again... :P
<qengho> "r" attempt, fail, that's fine.
<qengho> read
<tsimonq2> so apparmor can't read anythong off of my home directory?
<qengho> tsimonq2: $ mkdir ~/snap/YOURSNAPPACKAGENAME
<tsimonq2> *anything
<tsimonq2> oh okay
<tsimonq2> $ mkdir ~/snap/liferea
<tsimonq2> mkdir: cannot create directory '/home/simon/snap/liferea': File exists
<qengho> Oh, good.
<qengho> Huh!
<qengho> "ls" to make sure that's a dir, not a regular file.
<tsimonq2> yup
<tsimonq2> FWIW: drwxrwxr-x 3 simon simon 4.0K Jun 11 02:06 liferea
<tsimonq2> and drwxrwxr-x 2 simon simon 4.0K Jun 11 02:06 100001 inside of that
<qengho> tsimonq2: I have no idea, offhand. Time to look at source code, or "strace" it.
<tsimonq2> qengho: I'll try getting off of an encrypted home directory
<qengho> tsimonq2: er, okay, but I have one too, and it works for me.
<tsimonq2> if that magically fixes it, I'll file a bug
<qengho> (I do get ugly dmesg about that^.)
<tsimonq2> weird
<tsimonq2> okay
<tsimonq2> thanks :)
<qengho> tsimonq2: I don't know if it'll work.
<tsimonq2> well i'll try
<tsimonq2> I'll also Google around
<qengho> $ strace -f -o snaptrace -e trace=file -p $(pidof snapd)
<qengho> Do as root, probably.
<qengho> It it install time, or run time?
<qengho> "execute". hmm
<qengho> Okay, that's harder.
<qengho> And I have some things to do in Real Life. Back later.
<tsimonq2> o/
#snappy 2016-06-12
<jdstrand> zyga: re pulse cookie-- I think so, yes. what happens if you don't usinclude it?
<jdstrand> tsimonq2: that is a known bug. I believe zyga is planning an upload for something else that includes the fix
<zyga> jdstrand: so far things seem to work but I didn't do any deep tests
<tsimonq2> jdstrand: thanks :)
#snappy 2017-06-05
<Hilikus> i'm trying to create a snap for a raspberry pi but it seems crosscompiling is not supported yet. i created a classic environment on my pi but i can't install snapcraft in it, the .deb package is not found. this is the procedure recommended for cross compiling but it's not working, am i missing something?
<ahoneybun> anyone having issues with discord not starting back up once you reboot?
<zyga> o/
<zyga> Chipaca: o/
<Chipaca> \o
<zyga> Chipaca: what do you think about https://github.com/snapcore/snapd/pull/3410
<mup> PR snapd#3410: cmd/hotfix: add hotfix tool <Created by zyga> <https://github.com/snapcore/snapd/pull/3410>
<zyga> (just the concept, not the code)
<Chipaca> zyga: I'm not sure about it at all
<Chipaca> zyga: that's not a roundabout way of saying I don't like it; I honestly am not sure
<Chipaca> zyga: on the one hand I understand why it'd be useful; on the other I don't know how it'd be packaged, and I wonder how it'd be misused, and why we need it as opposed to having a web doc or something
<zyga> Chipaca: yeah, I agree on packaging
<zyga> Chipaca: I was thinking about providing a double-click unwedge.sh to download that does everything automatically
<zyga> Chipaca: but not sure if there's actual demand
<zyga> Chipaca: I jumped on this because initially it was apparently urgent
<fgimenez> hey pstolowski, i've worked a little bit more on the weird issue with snapctl called from the hook, i've checked that with our current setup it is indeed the old one (the one that comes with the core snap and not the one built from the branch)
<fgimenez> pstolowski: i've also checked that SNAP_COOKIE is correctly set in the configure hook  environment but snapctl doesn't understand it; its md5sum is different from /usr/bin/snapctl and /snap/core/current/usr/bin/snapctl (the latter two are equal after the hook execution)
<Chipaca> I wonder whether 'snap run' could catch errors in a snap' apps and push them (a snap hook or in its absence) to errors.u.c
<pstolowski> fgimenez, hey! oh, that's interesting. are you sure it's old snapctl? they look the same to me, yet for reasons I don't understand it seems as if old one was run
<fgimenez> pstolowski: yep, it turns out that calling "systemctl daemon-reload" after modifying the core snap and before starting the daemin again fixes the issue, somehow the snapctl binary used by the hook is cached, if you could give it a try that would be great to confirm, something like this https://github.com/snapcore/snapd/pull/3430/files#diff-556bb7431481e375713ea3e0883a771aR139
<mup> PR snapd#3430: tests: modify core before calling set <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3430>
<pstolowski> fgimenez, and yes, I modified core manually and added debug to configure hook, it gets SNAP_COOKIE env var
<pstolowski> fgimenez, ah!
<zyga> can I get a 2nd look on a new test? https://github.com/snapcore/snapd/pull/3428
<mup> PR snapd#3428: tests: add snap-confine privilege test <Created by zyga> <https://github.com/snapcore/snapd/pull/3428>
<pstolowski> fgimenez, bummer, thanks for finding! i was pulling my hair already
<fgimenez> pstolowski: yep :) for debugging, given that we already unpack core, i modified the configure hook to write out info to files, it's been quite helpful
<fgimenez> pstolowski: what i don't understand yet is why the snapctl used is always the one from core, and never outer
<fgimenez> never the outer
<pstolowski> fgimenez, that's "by design", our PATH setup afair
<pstolowski> zyga, hey, moved yet?
<fgimenez> pstolowski: aha, great thanks, good to know
<zyga> pstolowski: half way
<zyga> pstolowski: most of our things have arrived an hour ao
<zyga> ago*
<pstolowski> fgimenez, I'm not sure if that's good or bad, we may want to change that soon
<zyga> fgimenez: this is caused by us mounting the core snap
<zyga> fgimenez: changing it
<pstolowski> zyga, sounds like fun :)
<zyga> fgimenez: and unmounting it
<zyga> fgimenez: but exsting mount namespace may be kept
<zyga> fgimenez: and is reused
<zyga> fgimenez: this is a variant of this bug:
<zyga> fgimenez: https://bugs.launchpad.net/snapd/+bug/1667479
<mup> Bug #1667479: mount namespace is not discarded when core snap changes revision <snapd:In Progress by zyga> <https://launchpad.net/bugs/1667479>
<fgimenez> zyga: thx! looking
<pstolowski> fgimenez, hmm daemon-reload doesn't seem to make difference here
<fgimenez> pstolowski: let me doublecheck, maybe i had yet in place the code for modifying the configure hook in place when it succeeded
<fgimenez> pstolowski: indeed, it was passing because of the modified configure hook, given zyga's comments above we need to discard the previous namespace before remounting, this is working here https://github.com/snapcore/snapd/pull/3430/files#diff-556bb7431481e375713ea3e0883a771aR60
 * zyga has another crazy day
<mup> PR snapd#3430: tests: modify core before calling set <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3430>
<pstolowski> fgimenez, I see. many thanks for figuring that out!
<pstolowski> fgimenez, are you going to propose this change to prepare.sh independet of my PR?
<fgimenez> pstolowski: np, thanks to zyga :) if you could confirm that would be great
<Chipaca> FWIW what daemon-reload does it tells systemd that a file (e.g. a unit file, but also maybe a config file like e.g. timesyncd.conf) has changed, and it should re-read them
<fgimenez> pstolowski: i've already proposed it, but yes, makes sense to add it to your PR, i can retarget to it
<pstolowski> fgimenez, no no
<pstolowski> fgimenez, I think it makes sense to land it immediately
<pstolowski> fgimenez, not sure how long before my PR lands
<fgimenez> pstolowski: ok, it is snapd#3430
<mup> PR snapd#3430: tests: modify core before calling set <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3430>
 * zyga looks at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-snappy-dev-image/artful/amd64/s/snapd/20170605_085919_dd5dc@/log.gz trying to figure out why we didn't re-execute
<fgimenez> zyga: we are getting quite a few "DEBUG: re-exec disabled by user" errors lately, not sure what's going on
<zyga> fgimenez: aha, I see this as well in this log
<zyga> I was confused about this because AFAIR we re-pack the core snap and *not* disable re-exec, right?
<fgimenez> zyga: yes, by default it is enabled
<fgimenez> we disable it for specific tests, but at the beginning of each test it is, or should be, enabled
<zyga> fgimenez: maybe a restore bug somewhere?
<zyga> fgimenez: anyway, thank you, this looks like a sequence bug
<zyga> I'll try to debug it
<fgimenez> zyga: np, yep maybe something is left behind
<fgimenez> afaik this started happening about 1w ago, snapd-reexec and snap-confine-from-core fail randomly in different systems
<zyga> fgimenez: I think we could use a feature in spread that tries to run a command before and after
<zyga> fgimenez: and ensures that the output is the same (like run md5sum of some files)
<zyga> fgimenez: I bet we are still missing something but it's not breaking all the tests so we didn't stop the line
<fgimenez> zyga: sounds good, it could be helpful in cases like this
<pstolowski> fgimenez, I can confirm discard-ns fixes the issue \o/
<fgimenez> pstolowski: \o/
<zyga> fgimenez: indeed, I made a similar (like) patch earlier but I think we could learn from it
<zyga> fgimenez: I added a way to snapshot a manifest (whatever the spread.yaml says)
<zyga> fgimenez: and diff that (or analyze in way way) after the test
<zyga> fgimenez: but the size of the manifest was pretty significant so I think we'd like to just process the tests in flight and not keep all the manifests during the duration of the test (it would fill in the storage on travis and locally easily)
<Chipaca> dh_install: usr/bin/uboot-go exists in debian/tmp but is not installed to anywhere
<Chipaca> do i need to merge something?
<zyga> Chipaca: I saw that too
<zyga> Chipaca: I forgot TBH
<zyga> Chipaca: but I think it was in mvo's branch somewhere
<zyga> Chipaca: I remember commenting on that as I didn't know debian/noinstall (or something like that) is a thing
<fgimenez> zyga: yes, do it just for one test at a time if needed
<fgimenez> Chipaca:  "rm -rf vendor/*/" fixes it here
<zyga> Chipaca: ah, right
<zyga> Chipaca: stale govendor
<zyga> Chipaca: mvo added his uboot code so we don't need to vendor it anymore
<Chipaca> ah, ok
<Chipaca> fgimenez, zyga: thanks!
<mup> PR snapcraft#1351 closed: cli: remove double congrats messaging <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1351>
<mup> PR snapcraft#1347 closed: cli: do not duplicate errors <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1347>
<Chipaca> https://goplay.space/ looks interesting
<zyga> Chipaca: interesting
<Chipaca> snappable, also :-)
<mup> PR snapcraft#1352 opened: Allow source-type to specify local <Created by jocave> <https://github.com/snapcore/snapcraft/pull/1352>
<Chipaca> is there an interface that lets you read the MSRs, /proc/$pid/net/psched, and other juicy /proc and /sys stuff?
<zyga> Chipaca: let me check
<zyga> Chipaca: it doesn't look like it
<Chipaca> - Setup snap "powertop" (unset) security profiles (cannot update mount namespace of snap "powertop": cannot update preserved namespace of snap "powertop": cannot update snap namespace: cannot switch mount namespace: invalid argument)
<Chipaca> ^ 'make hack' time?
<zyga> mmmmm
<zyga> it looks like something else
<Chipaca> glad i asked first :-)
<zyga> setns fails with EINVAL
<zyga> oh boy
<zyga> man setns
<zyga> look for EINVAL
<zyga> gee, than you for being specific linux
<zyga> (error reporting on linux is utterly terrible)
<zyga> anything in your syslog?
<Chipaca> [269732.013362] audit: type=1400 audit(1496664970.988:633): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.powertop.powertop" pid=4654 comm="apparmor_parser"
<zyga> that is ok
<Chipaca> yeah
<zyga> but that's odd
<zyga> maybe make hack will fix it
<zyga> because EINVAL is just "let's not do anything" in snap-update-ns
<Chipaca> zyga: related to this i now have a left-behind mount: none on /tmp/snap.rootfs_HcWPu8 type tmpfs (rw,relatime)
<mup> PR snapcraft#1353 opened: cli: default options for the implicit snap command <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1353>
<zyga> Chipaca: hmmmmm
<zyga> Chipaca: so that says that snap-confine failed mid-way
<zyga> Chipaca: there's a small window where certain operations are not undone if things fail as they normally should not fail and we may do more damage trying to fix that
<zyga> Chipaca: can you still reproduce that?
<zyga> Chipaca: and can you do so with SNAP_CONFINE_DEBUG=yes
<Chipaca> zyga: I can try
<Chipaca> zyga: that env, in snapd, or in snap?
<zyga> Chipaca: snap
<zyga> Chipaca: well, just set it in your shel
<zyga> Chipaca: it's read by snap-confine
<Chipaca> right, but they're different shells, snapd and snap :-)
<Chipaca> zyga: where does snap-confine come into running 'snap try'?
<zyga> Chipaca: it doesn't, snap try is just that
<zyga> Chipaca: but then you may run configure hooks
<zyga> Chipaca: are you on encrypted fs?
<Chipaca> no
<Chipaca> I installed a snap, removed it; try'd it, removed it, try'd it with --devmode; the last one is upset
<zyga> Chipaca: interesting, well, let's see what you get
<Chipaca> zyga: already did that, got nothing
<Chipaca> there is no configure hook in the snap fwiw
<zyga> no interface hooks :) ? (just kidding)
<zyga> what does the last one say?
<Chipaca> zyga: http://pastebin.ubuntu.com/24783714/
<Chipaca> zyga: that's snapd
<Chipaca> snap just prints the two errors you see in the log anyway
<zyga> hmm hmm hmm
<zyga> nothing rings a bell
<zyga> but it looks like update-snap-ns is old
<zyga> look at cmd/snap-update-ns/bootstrap.go
<zyga> it maps EINVAL to "nothing to do"
<zyga> (well that's in main.go)
<zyga> but you get the idea
<zyga> this should not happen
<Chipaca> sigh
<Chipaca> ok
 * Chipaca does 'make hack'
 * Chipaca does 'reboot'
<zyga> fwupd uses 100% cpu, hmmmm
<magicaltrout> hello folks, quick one about the maven plugin, if you have a multi module maven build any one know how to tell it where to find the jars?
<zyga> magicaltrout: sergiusens or kyrofa might know
<cachio> zyga, /etc/systemd/system/snapd.service.d/ and /etc/environment are the places where we should clean?
<cachio> zyga, is there any other place?
<zyga> cachio: I think we should look at all the .service units, just in case a test modifies it
<cachio> all?
<cachio> zyga, ok
<zyga> cachio: well, just in case
<zyga> cachio: all the snap services for sure
<cachio> zyga, ok, I'll start with the snap ones
<magicaltrout> thanks zyga...... sergiusens or kyrofa any idea if maven multimodule support exists?
<sergiusens> magicaltrout: what is maven multi module? Can you post on forum.snapcraft.io with an introduction and some flow, if this is not implemented we can work on it from that post and keep everyone updated
<magicaltrout> thanks sergiusens, in a nutshell its where you have a parent pom file that controls a bunch of different maven modules in a tree beneath it. The build works fine, but snapcraft then doesn't seem to know where to find jars cause they aren't in the top level /target directory
<magicaltrout> anyway, i'll stick something on the forums
<magicaltrout> other stupid question for snaps, if I push something to the store, is there an website version of the snap store page that I can point people to rather than just `snap find` on the cli?
<zyga> magicaltrout: not officially
<magicaltrout> for people who don't know or have snappy installed it would be nice to be able to point them somewhere
<zyga> magicaltrout: but there's the uxexplorer
<zyga> but I cannot find it now :/
<magicaltrout> oh well thanks zyga
<zyga> https://uappexplorer.com/
<zyga> https://uappexplorer.com/apps?type=snappy
<zyga> magicaltrout: ^
<magicaltrout> nice
<magicaltrout> thanks!
<abeato> zyga, hey, any stopper for merging https://github.com/snapcore/snapd/pull/3353 ?
<mup> PR snapd#3353: Add support for reboot parameter <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3353>
<zyga> abeato: looking
<zyga> merged
<abeato> zyga, nice, thanks!
<mup> PR snapd#3353 closed: Add support for reboot parameter <Created by alfonsosanchezbeato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3353>
<zyga> Chipaca: question
<magicaltrout> other random question, if you have 2 parts can a file from part 2 see the file in part 1?
<Chipaca> zyga: cryptic answer
<zyga> Chipaca: open api.go please, go to getSnapInfo, look at the first InternalError there
<zyga> Chipaca: what is the variable name there?
<Chipaca> zyga: err?
<zyga> Chipaca: let me show you in github
<zyga> ohh
<zyga> weird
 * zyga looks at local code
<Chipaca> zyga: it's err on github too :-D
<zyga> ah
<Chipaca> zyga: what's going on?
<zyga> sorry :D
<zyga> I pasted something in my tree that confused me
<magicaltrout> snapcraft validation file is missing from installation path <- snapcraft seems to have ground to a halt
<magicaltrout> is it possible to flush it without restarting my laptop?
<zyga> Chipaca: still there?
<Chipaca> zyga: yes
<zyga> Chipaca: is muxVars the right way to get at variables encoded in the path of the URL?
<Chipaca> zyga: it is the way that gorilla affords us
<Chipaca> I have my reservations about it being "right"
<zyga> right
<zyga> hmmm
<zyga> I must be doing something wrong
<Chipaca> zyga: whacha doin'?
<zyga> the code works (uses muxVars) in practice
<zyga> but my tests gives me "" as the value
<zyga> (unit tests)
<zyga>     req, err := http.NewRequest("GET", "/v2/interface/test", nil)
<zyga>     c.Assert(err, check.IsNil)
<zyga>     rec := httptest.NewRecorder()
<zyga>     interfaceDetailCmd.GET(interfaceDetailCmd, req, nil).ServeHTTP(rec, req)
<Chipaca> zyga: are you setting s.muxVars?
<zyga> and the "test" thing gets empty
<zyga> no, should I?
<Chipaca> ah, see, no, that doesn't go via gorilla
<Chipaca> zyga: yeah
<zyga> ahh
<zyga> weird
<Chipaca> zyga: look for s.muxVars in api_test.go
<Chipaca> come the revolution, â¦ :-)
<zyga> just one hit
<zyga> ah
<zyga> s.vars
<zyga> thanks!!
<zyga> (ugly but well :)
 * zyga is spoiled by djanog
<zyga> django
<Chipaca> s.muxVars; where is it s.vars?
<zyga> Chipaca: in many places, just look
<zyga> assert tests
<zyga> state change
<zyga> etc etc
<mup> PR snapcraft#1333 closed: state: search for the dependencies in the archive <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1333>
<zyga> Chipaca: is that a bug?
<Chipaca> zyga: in many places that aren't apiBaseSuite or that embed abiBaseSuite?
<Chipaca> oh wait
<Chipaca> zyga: sorry, i was confused
<Chipaca> zyga: it's totally .vars
<Chipaca> niemeyer: https://forum.snapcraft.io/t/rest-service-endpoint/892 <- for your consideration
<niemeyer> Looking
<niemeyer> Yeah, interesting.. thinking
<Chipaca> niemeyer: no hurry to it, as the rest of the work remains unchanged
<niemeyer> Chipaca: I can't avoid punning "the rest of the work"
<Chipaca> niemeyer: i'll allow it
<zyga> Chipaca: question, spread test that runs a command and ensures that the output matches a canned text?
<zyga> Chipaca: multi-line
<zyga> Chipaca: can MATCH -F do it?
<cachio> zyga, snapd is reading just the local.conf file? or it is reading any conf file in the /etc/systemd/system/xxunit/?
<zyga> dunno
<zyga> probably both
<cachio> ok
<Chipaca> cachio: snapd reads systemd conf files?
<Chipaca> zyga: MATCH -z lets you do that; probably zF would work but let me check
<zyga> Chipaca: I'll check, I'm looking for recommendation
<Chipaca> zyga: you can't use -F and -E together
<zyga> ah
<zyga> Chipaca: I'll use diff
<Chipaca> -z works though
<zyga> Chipaca: no worries, the canned output will be better even
<cachio> Chipaca, no
<Chipaca> zyga: -z and $'multi-\nline\nstuff\n' works, even
<zyga> thanks
<cachio> I mean, but I does through systemd
<cachio> Chipaca, is it right?
<cachio> Chipaca, because in the local.conf can be set environment=xxxxx
<Chipaca> cachio: I'm afraid I don't know what local.conf is
<cachio> Chipaca, it is just a confiig file for the service unit that the tests are creating
<Chipaca> ah! found it
<zyga> I think it all works now
<zyga> just spread run and I'll push
<Chipaca> cachio: so yes if that file is created, and systemd gets daemon-reload'ed after its creation, snapd will have whatever extra environ is set in there
<cachio> Chipaca, yes
<zyga> so
<zyga> I have a small thing to fix in other places, but finally feel like I climb out of a focus hole
<cachio> git push
<zyga> cannot push to joke/master, humor exhausted
<zyga> gosh my network is slow today
<zyga> core 8.42 MB / 80.45 MB   10.47% 30.50 KB/s 40m17s46s
<zyga> I want a store proxy
<zyga> I cannot work like that
 * zyga looks at store proxy 
<zyga> Chipaca: I know nothing about the store, I'm going to write a store proxy for caching core downloads and what not, is this insane?
<zyga> Chipaca: or should I be able to do it?
<Chipaca> zyga: uhmmm
<Chipaca> zyga: it isn't insane
<Chipaca> zyga: but you will have to write an application-level proxy
<Chipaca> zyga: because the download url is returned in the json response itself, so you'll need to modify those as they go past
<zyga> hmm
<zyga> cannot I just cache everything blindly?
<zyga> maye my questions make no sense yet, I'm still trying to grok how things work
<Chipaca> zyga: if you're willing to tinker with certificates, you can probably get it to work as a proxy
<zyga> ok
<zyga> yeah
<Chipaca> zyga: otherwise, an app-level proxy should be reasonably straightforward
<Chipaca> as in, "i could probably write one in two about an hour if it weren't past my EOD" :-)
<zyga> Chipaca: I think it's badly needed
<zyga> but let me play around
<zyga> you know this better
<zyga> but for me it will be a learning exericse
<Chipaca> zyga: OTOH, making snapd itself cache things could work :-)
<zyga> and I can grok our store interactions more
<Chipaca> it's probably dropping one os.Remove :-)
<zyga> Chipaca: perhaps but it would not help testing mcuh
<zyga> Chipaca: I want spread + qemu to be mostly offline
<zyga> if not fully (I understand it will go to github to fetch things)
<Chipaca> ah so not just downloads but the whole thing
<zyga> Chipaca: I want to "freeze" the world and then have tests talk to a very agressive proxy
<zyga> yes
<Chipaca> sounds more like a recorder of sorts
<Chipaca> anyway, sgtm
<zyga>        
<zyga> https://search.apps.ubuntu.com/api/v1/snaps/details/snapd-hacker-toolbelt?channel=stable&fields=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha3_384%2Csummary%2Cdescription%2Cdeltas%2Cbinary_filesize%2Cdownload_url%2Cepoch%2Cicon_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Cscreenshot_urls%2Csnap_id%2Csupport_url%2Ccontact%2Ctitle%2Ccontent%2Cversion%2Corigin
<zyga> %2Cdeveloper_id%2Cprivate%2Cconfinement%2Cchannel_maps_list:
<zyga>        x509: certificate signed by unknown authority
<zyga> a bit mouthful error
<Chipaca> zyga: https://forum.snapcraft.io/t/network-ish-error-messages/862?u=chipaca
<Chipaca> niemeyer: you too ^ :-)
 * niemeyer looks
<zyga> mmm
 * zyga has 18MB of traffic left 
<zyga> well
<zyga> that explains things
 * zyga EODs
<zyga> no network, no way to work until wifi is back
<zyga> which might as well be tomorrow
<zyga> niemeyer: hey
<zyga> niemeyer: can you please make me an editor on the forum?
<zyga> niemeyer: I'd like to fix syntax / quoting in a post (*the* post I'd say)
<lazyPower> zyga: o/ need me to do something?
<niemeyer> zyga: You're now a moderator.. please use it with moderation :)
<zyga> lazyPower: hey
<zyga> niemeyer: thank you!
<zyga> lazyPower: I replied on the forum
<zyga> lazyPower: I'd like to know where your lxd is coming from and which kernel is this running on
<lazyPower> ah just got your reply on the forum, will keep the thread there
<zyga> lazyPower: lastly is this your laptop/device or some specialized cloud environment, I'm just asking because I want to reproduce everything
<niemeyer> zyga: Thanks for caring!
<lazyPower> its my laptop zyga . i installed ubuntu desktop 16.04.2 this weekend, and have run apt-get update && apt-get upgrade. So the packages i have should be coming from archive, not from ppa's.
<lazyPower> let me sort through the feedback and add more details
<zyga> lazyPower: can you apt-cache policy lxd
<zyga> I'm also on 16.04 and I don't see the same version
<lazyPower> oh snap
<lazyPower> http://paste.ubuntu.com/24785892/
<zyga> aha
<lazyPower> i didnt explicitly enable a ppa, i'm curious how that got there now
<zyga> ok, this should be enough, let me fire a VM for experiments and I'll get back to you!
<lazyPower> ty zyga  i appreciate you taking a look
<lazyPower> zyga: yeah, looks like that lxd from ppa came from the conjure-up snap package in the stable channel. thats where the mixup in lxd versions came from and how i got seated on the ppa.
<zyga> interesting
<zyga> thanks
 * zyga has working eGPU for testing nvidia/amd on *distro for snapd!
<zyga> not perfect but... works
<zyga_> Pharaoh_Atem: hey
<zyga_> Pharaoh_Atem: any advice on nvidia on F26?
<Pharaoh_Atem> on what?
<zyga_> I got a card I can use on my fedora box
<Pharaoh_Atem> ah
<zyga_> but performance is beyond terrible, I cannot even run terminal comfortably
<zyga_> I found https://negativo17.org/nvidia-driver/
<zyga_> but nothing official (fedora/nvidia0
<Pharaoh_Atem> negativo17 or rpmfusion are both options for the nvidia driver
<zyga_> why aren't those in Fedora proper?
<Pharaoh_Atem> because it is against the ethos of Fedora
<zyga_> which is?
<Pharaoh_Atem> Fedora only ships free and open source software that isn't impaired by software patents or other legal encumberences
<zyga_> hmm, too bad there's no place for official but "external" things like thiat
<Pharaoh_Atem> rpmfusion is the closest to that
<Pharaoh_Atem> it mimics Fedora infrastructure and packaging structures
<Pharaoh_Atem> it just doesn't exist under Fedora itself
<adfad666> Fedora is a PITA, really unstable on my XPS 15
<adfad666> I was experimenting today too
<mup> PR snapd#3433 opened: tests: restoring the /etc/environment and service units config for each test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3433>
<om26er> Hi guys, when will https://build.snapcraft.io/ support more arches ? specifically arm64 in this case.
<om26er> popey, do you know ?
<cjwatson> om26er: https://github.com/canonical-websites/build.snapcraft.io/issues/556
<popey> om26er: no plans at the moment
<popey> oh, cjw beat me to it :)
<om26er> cjwatson, popey thanks.
#snappy 2017-06-06
<mup> PR snapcraft#1354 opened: catkin plugin: fix pythonpath for catkin_find <Created by mrjogo> <https://github.com/snapcore/snapcraft/pull/1354>
<mup> PR snapcraft#1353 closed: cli: default options for the implicit snap command <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1353>
<mup> PR snapcraft#1355 opened: go plugin: filter the main packages go-packages are defined <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1355>
<morphis> mvo: ping
<mvo> morphis: pong
<morphis> mvo: how was the long weekend? :-)
<mvo> morphis: very nice, thank you! for you as well?
<morphis> mvo: yeah, happily quite sunny yesterday so a great end :-)
<morphis> mvo: one quick question for you: should we ship the snap-repair systemd units on classic systems?
<mvo> morphis: we don't need to, its disabled there anyway
<morphis> mvo: good!
<mvo> morphis: so far we use the same debs to build classic and core this is why they are included currently
<morphis> yeah, guesses that already but let me exclude these units for other distros then
<morphis> doesn't make much sense to have them installed there
<mvo> morphis: +1
<NicolinoCuralli> hi guy i need to use ssh-pass and i need to access /dev/tty : is serial-port the right interface?
<morphis> NicolinoCuralli: for serial-port you need to define a slot on the gadget snap for that specific tty, if that is an option, then the answer is yes
<NicolinoCuralli> thanks morphis
<morphis> mvo: thanks
<morphis> mvo: can you merge https://github.com/snapcore/snapd/pull/3427 ?
<mup> PR snapd#3427: interfaces/builtin: silence ptrace denial for network-manager <Created by morphis> <https://github.com/snapcore/snapd/pull/3427>
<mvo> morphis: looking
<mvo> morphis: thank you
<mup> PR snapd#3427 closed: interfaces/builtin: silence ptrace denial for network-manager <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3427>
<zyga_> mvo: good morning!
<mvo> hey zyga_!
<zyga_> mvo: lots has happened since Friday :-)
<morphis> zyga: morphis!
<morphis> mvo: thanks
<zyga_> hey hey :-)
<mvo> zyga_: oh? tell me more? I'm slowly catching up (reading forum etc)
<zyga_> mvo: mainly we know how to reproduce the error from last week
<zyga_> mvo: looks like apparmor/lxd bug, still working on it (just got to the office)
<zyga_> mvo: thank you for participating in the arch bug, I think the arch package needs to be improved slightly, I suspect we may be missing something simple just because the package is broken
<mvo> zyga_: awesome!
<zyga_> morphis: I wonder if we could do arch (after suse) CI next
<morphis> zyga: why not, but lets land suse/fedora first :-)
<mvo> zyga_: aha, thanks, the arch bug was a bit of a drive-by-comment. so the lock-error happens inside lxd?
<morphis> zyga: I have mint on my list too
<kunal> Hello dear community .... I need help regarding snapcraft of a python app
<kunal> please help me
<zyga_> mvo: not sure yet but what it looks like is that apparmor profile from the host confines the guest
<morphis> kunal: best is if you post your specific question on https://forum.snapcraft.io
<mvo> zyga_: great, thanks a lot for chasing this further. out of curiosity, how did you find this out?
<zyga_> mvo: it was reported on the forum actually
<mvo> zyga_: sweet
<zyga_> mvo: so all the credits go to the reporter :)
 * mvo takes a short tea break
<morphis> zyga: why are you asking about ARch? anything specific?
<zyga_> but forum is so nice to engage with, not like ML where you cannot reply to stuff you didn't see before easily
<zyga_> morphis: to run spread tests on it
<zyga_> morphis: even in nightly mode if we can
<morphis> sure, but is there anything which brought this up or just in general?
<zyga> morphis: ah, I wonder if the error reported on the forum is pointing out something deeper that's broken there
<morphis> zyga: ?
<kunal> My problem is - I am working on a snap for my python app... I am unable to understand why doesn't it download python packages available through apt-get
<kunal> why doesn't snap download the python modules from main repository.
<zyga> morphis: I mean this one https://forum.snapcraft.io/t/cannot-locate-core-snap-error/884
<zyga> kunal: hey, what did you expect to happen and how did you express this in your snapcraft yam?
<zyga> yaml*
<kunal> or if it does not download some module for python, then how will my program/app run. It only downloads from pypi . It may be a stupid type question, but dear community members ... I need your help here... Please help me
<morphis> kunal: that hardly depends on how you structure your snapcraft.yaml
<zyga> kunal: apt is available through "stage packages"
<zyga> kunal: why do you prefer apt over python package index?
<kunal> I specified/ included espeak under python-packages in my snapcraft.yaml but then it gave me an error... the same thing happend with scipy .
<zyga> kunal: I think you should open a question on the forum, include the error message and relevant parts of your snapcraft.yaml
<kunal> I do not prefer apt over pypi but i just want to know that if some python module is not dowloaded by snapcraft then, how will my program run , because it requires those python module at runtime...
<morphis> zyga: did you finish the changes for snap-confine we talked about last week?
<zyga> morphis: almost, I ended up finishing something I already got a review of
<zyga> morphis: (which grew slightly so took whole day)
<zyga> morphis: I finished making the structural changes but I need to comment on everything heavily to guide the reviewers
<zyga> morphis: though on the bright side almost all changes are in snap-confine.c so it's not a revolution
<morphis> zyga: ok
<morphis> zyga, mvo, pedronis, Pharaoh_Atem: another review on https://github.com/snapcore/snapd/pull/3222 would be much appreciated, getting really tired of merging/fixing that with master again and again :-)
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<morphis> and the PR is now pending for nearly 1,5 months
 * zyga_ sees re-exec disabled by user again
<morphis> zyga: Linode has an prebuilt Arch image so shouldn't be much work
<NicolinoCuralli> morphis: i tell you wrong device : i need to use a pty device from my snap: actually is it possible ?
<zyga> NicolinoCuralli: each snap gets private ptys
<NicolinoCuralli> zyga: i have an error as this : debug1: read_passphrase: can't open /dev/tty: No such device or address
<NicolinoCuralli> it seems as if the command can't access the device
<NicolinoCuralli> zyga: some hint on the problem?
<zyga> I don't think you can open /dev/tty
 * zyga looks
<zyga> yep
<zyga> it's not allowed
<NicolinoCuralli> zyga: neither enabling a new interface?
<zyga_> NicolinoCuralli: a new interface could allow it but I think it is disallowed for a reason now
<zyga_> NicolinoCuralli: can you please start a forum topic
 * zyga_ is busy with some other things now and cannot actively look at why /dev/tty was left out of current interfaces
<NicolinoCuralli> zyga: thanks for your help : I find another solution to implement what I make with sshpass, but I think to start a forum topic for document this restriction
<morphis> fgimenez: is there any specific reason why you're using -q for nc in the networking spread tests for snapd?
<fgimenez> morphis: iirc it was meant to limit the time the test waits, let me check
<morphis> fgimenez: as -q is not really portable across distributions
<fgimenez> morphis: feel free to tweak it as needed, maybe we can do the same with another portable option, perhaps -w?
<morphis> maybe
<morphis> let me play with that
<om26er> where can i find documentations about delta uploads ? I have been looking around but didn't find them also google doesn't bring up anything related to that.
<fgimenez> hey zyga_, snapd#3430 should be fixed now for 14.04, i was getting http://paste.ubuntu.com/24791901/ after the error, pls take another look when you have a moment
<mup> PR snapd#3430: tests: modify core before calling set <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3430>
<zyga> ok
<zyga> hmm
<zyga> not sure what to say
<zyga> fgimenez: what think is missing is snap-confine's /snap sharing
<zyga> fgimenez: is this done before snap-confine gets a chance to run?
<ogra> fgimenez, ls /var/lib/snapd/snaps/core_*.snap will explode if there are more than one core snap (for whatever reason)
<fgimenez> zyga: this is done after snapshoting the state, when restarting the units https://github.com/fgimenez/snappy/blob/cb71389e43b5aa0708715721faad1880c7629161/tests/lib/prepare.sh#L173
<fgimenez> ogra: thx! at this point it is not expected to have more than one core, we are at a very early stage of suite preparation, but the check can indded be more robust, i'll push changes for that
<ogra> :)
<fgimenez> zyga: it is done also with the daemon stopped, not sure if that matters
<zyga> fgimenez: is this easy to reproduce?
<zyga> fgimenez: it should not matter
<fgimenez> zyga: yep, from the branch seems to be very consistent
<zyga> fgimenez: I'm happy to take a look after exploring the juju/lxd issue
<fgimenez> zyga: great, thank you
<pedronis> morphis: maybe I'm misreading but in snapd#3222 it seems you did exactly the opposite of what Gustavo asked
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<pedronis> morphis: https://github.com/snapcore/snapd/pull/3222#discussion_r116286335  soundes like ...Join(rootdir,... should be there, anyway IÂ don't have a strong opinion, but sounds you need his re-review
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<morphis> pedronis: thanks, yeah I need his review again
<morphis> pedronis: there are two different parts
<morphis> there is CoreLibExecDir which never has a prefix
<morphis> and in all others cases I am using dirs.StripRootDir like in https://github.com/snapcore/snapd/pull/3222/files#diff-6dd6f3a48b395a14870975240679b8cdR86
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
 * zyga experiments with juju and has his head spinning
<zyga> I think this is the perfect time for a coffee
<tai271828_> haha
<zyga> hey tai271828_ :)
 * zyga looks at juju output and waits for more things to install
<tai271828_> \o zyga did you get your coffee
<mup> PR snapd#3434 opened: tests: add staging snap-id <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3434>
<fgimenez> hi pedronis, we are missing another snap-id for staging, see ^^^, however i'm still getting an error after adding the right id http://paste.ubuntu.com/24792792/, i've just uploaded the same prod snap to staging, is something else missing?
<zyga> tai271828_: yes I did
<mup> PR core#35 closed: move xdg-open to proper paths <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/core/pull/35>
<mvo> if someone could have a second look at https://github.com/snapcore/core/pull/48 that would be great
<mup> PR core#48: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <https://github.com/snapcore/core/pull/48>
<pedronis> fgimenez: you need to change the python in that test as well
<fgimenez> pedronis: aha! thx on it
<pedronis> fgimenez: sorry, not the python
<pedronis> fgimenez: but the yaml has this:  environment:
<pedronis>     TEST_SNAP_ID: aLcJorEJZgJNUGL2GMb3WR9SoVyHUNAd
<fgimenez> pedronis: that should be addressed with the changes in snapd#3434
<mup> PR snapd#3434: tests: add staging snap-id <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3434>
<fgimenez> pedronis: hmm i see a typo in there, let me fix it
<Chipaca> \o
 * Chipaca appears in a cloud of post-physio exhaustion
<ogra> clouds are the future i heard
<zyga> unless it rains
<Chipaca> I think people who used to gravitate towards torturer and executioner roles in the past now just pick up physio
<Chipaca> "you'll feel a little stretch" <turns the rack wheel>
<zyga> "you will fell a little sting"
<fgimenez> pedronis: works fine now, sorry for the noise
<mvo> flexiondotorg: hey, do you have an example app that uses gnome-keyring that could be used to do a real world test for a new interfaces for gnome-keyring?
<flexiondotorg> Hi
<flexiondotorg> I do.
<flexiondotorg> Skype for Linux
<zyga> flexiondotorg: skype for linux beta or the one that was de-comissioned just now/
<mvo> flexiondotorg: great, where can I find the snapcraft.yaml to add the right ifcace for testing?
<flexiondotorg> The new Electron version.
<mup> PR snapd#3435 opened: interfaces: add password-manager-service implicit interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/3435>
<flexiondotorg> ANd also Nylas Mail (the newer open source version), also Electron.
<mvo> fgimenez: I have a new snap-test-security-service-consumer snap, what was the central place for those again so that they are all auto-build/uploaded?
<flexiondotorg> mvo I'll just make sure both yamls are current.
<flexiondotorg> Give me a few mins...
<mvo> flexiondotorg: no worries, I will soon have lunch anyway, so no rush :)
 * ogra glares at snapd 3432 ... how can a journald run on 14.04 (which doesnt have systemd)
<zyga> ogra: snapd pulls it in
<zyga> ogra: we have systemd on 14.04 but it is a special build
<ogra> and that is a fully working systemd (providing logging )
<ogra> i thought that was just a stub
<zyga> ogra: oh, journald is there?
<zyga> I thought journald did not work
<zyga> nice :)
<ogra> zyga, thats what i mean
<ogra> how can https://github.com/snapcore/snapd/pull/3432 actually work on a 14.04
<mup> PR snapd#3432: tests: clean journalctl logs on trusty <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3432>
<ogra> where we have no fully working systemd
<ogra> (and thus no journald)
<ogra> tvoss, is the 14.04 systemd thing actually starting a journald ??
<ogra> (iirc you worked on that)
<morphis> ogra: I doubt that
<ogra> morphis, hmm, curious ... why is that needed then ...
<morphis> not sure
<zyga> lazyPower: hey, I'm trying to reproduce the issue we spoke of yesterday
<zyga> lazyPower: how long should conjure-up be doing its thing?
<zyga> lazyPower: I'm currently seeing "waiting for applicationto start"
<zyga> lazyPower: juju status spews a lot of output, some things being active, some in maintenance
<zyga> lazyPower: (it all means nothing to me unfortunately)
<zyga> hmm, actually, I think it is making progress
<fgimenez> mvo: thx for the heads up! we are uploading the source files here https://code.launchpad.net/~snappy-dev/snappy-hub/ and from there they are published to production, i'll register and upload it to staging
<fgimenez> mvo: btw we need two more test snaps in prod undere the shared account, i'll ping you later about this
<ogra> wow, someone still uses snappy-hub ?!?
<pedronis> all our test snaps are built under it I think
<pedronis> test snaps, as used by spread tests
<ogra> ah ... interesting
<ogra> i thogught even that was moved to GH
<zyga> lazyPower: almost all apps are active now, I see that kubernetes-master is still "waiting"
<zyga> lazyPower: with a message "waiting for kube-system podto start"
<zyga> lazyPower: still looks OK-ish
<zyga> lazyPower: I did start with snapd 2.25 as that's what I got after update from 2.0.10
<zyga> lazyPower: I'll let this finish and try again with manually started 2.21
<zyga> lazyPower: you said you had 2.21 on the host and 2.25 in lxd, can you explain which of the machines had 2.25 exactly? how can I check that?
<zyga> lazyPower: in the end it failed with "step requires paswordless sudo"
<zyga> and a python backtrace
<zyga> in the end I can see a few denials that are not caused by snapctl
<zyga> let me add this to the forum
<morphis> pedronis: can I set the device-service.url configuration item for the gadget snap after the firstboot process still if the device does not have a serial-assertion yet?
<pedronis> morphis: in which context?
<morphis> pedronis: in a case where a customer has it's own local serial-vault and we have a generic image and we want to point that now to the local serial-vault
<pedronis> morphis: well generic image will have a generic model
<pedronis> something doesn't compute there
<pedronis> generic in which sense?
<morphis> generic in a sense of that we want to cover a bigger set of devices with the same image to save costs of doing n different images
<morphis> so we have an image generic for a brand
<pedronis> morphis: in principle atm yes,  device registration is retried
<morphis> ok
<lazyPower> zyga: thats an unrelated thing, conjure-up is trying to fetch snap packages required to maintain the application
<lazyPower> zyga: i had 2.21 on the host, each container would have had 2.25. after upgrading to 2.25 on my host yesterday it appears to have resolved itself as well
<ogra> sounds like a re-exec vs non-rexec issue
<zyga> lazyPower: aha, I see
<zyga> lazyPower: I'll do another pass now, using 2.21 on the host
<zyga> lazyPower: I think the bug is still there, it is just masked by 2.25 on the host
<lazyPower> masked huh :)
<mvo> fgimenez: sounds good, thank you
<iliv> hi, when I run "snap alias" command as an unprivileged user it displayes the following "error: access denied (try with sudo)". is this expected or a problem?
<ogra> iliv, well, that will also be the message when you snap install and such
<iliv> well, I'm reading this https://insights.ubuntu.com/2017/01/28/ubuntu-core-how-to-enable-aliases-for-your-snaps-commands/ and it leads me to believe snap alias can be run as an unprivileged user (?)
<ogra> iliv, it should also say that you can "snap login" instead of using only sudo ...
<ogra> iliv, yes, an unprivileged user that used snap login before
<iliv> hm
<ogra> i dont think we support actual per-user aliases yet ... ( pedronis may correct me) which wouldnt need snap login or sudo
<pedronis> aliases are global
<iliv> pedronis, which user manages them? root?
<pedronis> snapd so root
<pedronis> iliv: anyway when 2.25/2.26 come out that blog post is not valid anymore
<iliv> ogra, after issuing snap login I was able to "snap alias" as an unprivilged user
<pedronis> things work differently
<ogra> iliv, yeah :)
<iliv> pedronis, I hope you guys will update it then
<iliv> pedronis, btw I run 2.25
<pedronis> davidcalle: hi, did you see my ping in the foru about that btw  ?
<iliv> for both snap and snapd
<pedronis> iliv: then you need to read: https://forum.snapcraft.io/t/improving-the-aliases-implementation/18/33
 * zyga -> lunch
<davidcalle> pedronis: I don't think I did :/
<pedronis> davidcalle: we need a new post or to update the old one about aliases once 2.26 is on stable
<pedronis> given that things have changed
<iliv> davidcalle, and if you add now "snap login is required before running all the commands below" it can save some time anyone who is reading that blog post. no need to wait for 2.26.
<davidcalle> iliv: good point
<davidcalle> pedronis: what's the eta on this? Two weeks?
<pedronis> davidcalle: don't know,  mvo what's the eta on 2.6.4 going stable ?
<zyga> davidcalle: I think this is in the hands of fgimenez now
<mvo> pedronis, davidcalle: no firm deadline but ASAP. we need QA approval from fgimenez and the CE team. AIUI the CE team is currently testing the new core (correct federico?)
<fgimenez> mvo yep, the validation on beta was successful, it was promoted yesterday to candidate and now CE QA and Cert are validating it, as soon as they finish with it and you and JamieBen_ give your ok it can be promoted to stable
<mvo> fgimenez: excellent ! thank you
<iliv> hm okay, so I've just created an alias for postgresql93.psql and "whereis psql" points to /snap/bin/psql. However, when I run "psql --version" /usr/bin/psql is called. what gives?
<iliv> here's my terminal history that illustrates this problem: https://dpaste.de/62Vk/raw
<mup> PR snapd#3434 closed: tests: add staging snap-id <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3434>
<iliv> oh, I see
<iliv>  I needed to relogin
<iliv> that's weird anyway
<iliv> once I exited and relogined psql started to resolve to /snap/bin/psql
<iliv> this looks like a bug to me. normally system wouldn't require a shell logout to pick up a new location of a binary.
<iliv> ogra, pedronis davidcalle
<ogra> iliv, did you have a deb installed before ?
<iliv> correct
<ogra> sounds more like bash is caching something to me then
<ogra> (not really like a snap issue)
<iliv> right
<iliv> I have just been ables to reproduce it the other way around
<iliv> i.e. install snap package first, then deb
<iliv> same issue
<ogra> but yeah, sounds like a bug ... would be nice to know if that also happens when you have a deb where a binary moves from /usr/bin to /bin or some such
<iliv> I guess a shell logout/reinitialization is required after all
<ogra> (to prove it isnt actually snap related)
<iliv> mhm
<pedronis> davidcalle: so sounds a bit less thant 2 weeks in the good, more like this one or the next
<davidcalle> pedronis: sounds good, thanks. I'll be in the snapcraftio sprint this week, I'll make it part of it
<pedronis> thank you
<pedronis> let me know if you have questions
<davidcalle> +1
<zyga_> mvo: https://github.com/snapcore/snapd/pull/3370
<mup> PR snapd#3370: many: derive implicit slots from interface meta-data <Created by zyga> <https://github.com/snapcore/snapd/pull/3370>
<zyga> mvo: that's the implicit pr, if this lands your pr won't have to change implicit anymore
<zyga> mvo: and the last thing will be the base declaration
<zyga> I cannot reconnect to the call
<zyga_> I cannot re-connect
<zyga_> fgimenez: hey
<zyga_> fgimenez: I have one more idea about the 14.04 issue with mounted core
<zyga_> fgimenez: I think /etc/mtab is a file, not a symlink to /proc/mtab
<zyga_> fgimenez: and this is causing this issue
<zyga_> fgimenez: if I'm right we may have to ensure we always keep those two in sync
<fgimenez> zyga_: aha, that would make a lot of sense, when i try to unmount core it gives an error saying it wasn't mounted (that's the reason of the "|| true" in the PR), but it was reported by "mount"; after the call to umount all is good, seems that both versions are in sync
<fgimenez> zyga_: and the original error messaage refers to mtab http://paste.ubuntu.com/24791901/
<zyga> fgimenez: right, because on 14.04 mtab is a file maintained by userspace tools but later on it was changed to a symlink to kernel's mtab which is always correct
<morphis> mvo: shouldn't the tests/main/snap-repair spread test case be ubuntu-core-* specific?
<fgimenez> zyga_: should i raise a bug about this? also, about the PR, is there a better solution, maybe copying /proc/mtab to /etc/mtab?
<zyga> fgimenez: I'm not sure yet, I think it is partially a "feature" of 14.04 but I wonder which changes triggered the problem now
<zyga> fgimenez: if it is just affecting tests we can do something about it in spread, I wonder (and worry) about 14.04 outside of test environment
<fgimenez> zyga_: the only difference is the call to snap-discard-ns core afaik
<fgimenez> without it 14.04 doesn't give this error
<mvo> morphis: yes, it should be
<morphis> mvo: ok, will mark it as such
<icey> so, after a forum post about getting a default alias (with several +1s), how long would be normal to wait? https://forum.snapcraft.io/t/ripgrep-aliased-as-rg/351
<Chipaca> noise][: who deals with setting up aliases?
<pedronis> jdstrand mostly
<Chipaca> icey here has had a request for aliases open for over a month, with a +1 from jdstrand and niemeyer for nearly as long
<Chipaca> that won't do :-(
<icey> Chipaca: hence me coming to bug people about it :)
<Chipaca> icey: yeah
<Chipaca> icey: thanks!
<Chipaca> so my question is, what do we do to avoid this from happening again
<icey> maybe I shoudl make a forum/IRC bot to bug people when there are a lot of +1 (especially from some names) on the forums
<zyga> Chipaca: I mentioned this once before but I really really think this should always be a bug on the snappy store project
<icey> s/shoudl/should
<zyga> https://launchpad.net/snapstore
<noise][> zyga: i don't think that's the right place since my team doesn't handle those approvals
<zyga> noise][: what do you suggest then?
<Chipaca> right, if it's jdstrand, we need to bug him :-)
<Chipaca> mup: pester jdstrand until morale improves!
<mup> Chipaca: I apologize. I'm a program with a limited vocabulary.
<noise][> need to chat w/jdstrand
<noise][> the process is clearly leaky, but we've agreed (at least thus far) that we want the forum discussion for those requests, and not just a queue in the store
<ogra> the prob with the forum discussions is that they vanish over time
<ogra> (not physically but they simply scroll off the overview eventually)
<zyga> noise][: maybe we just need both
<ogra> some kind of remonder system would be nice there
<zyga> noise][: file a bug and open a forum thread
<icey> I wonder if there's some way to unite these two ideas, so that you have a forum discussion with some kind of queue that proposals can be removed from when handled
<ogra> *reminder
<zyga> mvo: hey, I read your new interface PR
<zyga> mvo: I have two comments/suggestion
<pedronis> people can bookmark things in the forum fwiw
<mvo> zyga: excellent, I check them out
<zyga> mvo: one is that you need to tweak tests to pass on fedora and other non-deb systems
<jdstrand> icey, et al, let me look
<zyga> mvo: ah, I didn't send them there :)
<mvo> zyga: indeed
<mvo> zyga: aha, ok :)
<zyga> mvo: and the other one, which is just a suggestion, is to perhaps open a forum thread and document the interface there
<zyga> mvo: my branch adds a DocsURL meta-data, so you can document the interface and people will be able to find that by saying "snap interface password-manager-service"
<mvo> zyga: nice, I will do that
<zyga> mvo: and if you +1 https://github.com/snapcore/snapd/pull/3370 we can also define implicitness through the meta-data, one less file to edit
<mup> PR snapd#3370: many: derive implicit slots from interface meta-data <Created by zyga> <https://github.com/snapcore/snapd/pull/3370>
<Chipaca> jdstrand: icey: it looks like what happened is that the request came in just as we were (re)defining the process for this, and fell through the cracks
<icey> Chipaca: I'm good at finding those cracks apparently :-P
<mvo> zyga: thanks, I check that branch out now too
<icey> and it wasn't high enough on my priority list to follow up on
 * ogra hands icey  a pot with plaster to close them :P
<zyga> mvo: thank you! note that those are just suggestions (the docs at least)
<zyga> mvo: so don't feel blocked by this
<jdstrand> Chipaca: well, we defined the process, but there is a not great part of circling around after a week. that didn't happen with this one. there are a couple of others I'm going to follow up on too
<Chipaca> jdstrand: i panicked for a moment thinking we were leaving people in limbo, but it looks like i was wrong; sorry if i was too pushy or something there
<jdstrand> Chipaca: the circling around bit did slip through so thank you for the reminder
<icey> Chipaca: limbo can be relaxcing too ;-)
<jdstrand> icey: as mentioning in the forum, sorry for the delay
<jdstrand> menioned*
<jdstrand> meh
<icey> no worries jdstrand, partially on me too for not following up
<jdstrand> mentioned*
<ogra> i really think remindesr should be a forum feature ...
<ogra> reminders
<niemeyer> Heya
<niemeyer> For the requests queue, we already have a check mark we use when the request is handled
<niemeyer> What's missing is a proper view that lists only such requests so it's obvious what's pending
<niemeyer> I think either a category or a tag will do
<ogra> niemeyer, well, couldnt it also send some reminder mail if such a request is open and untouched for a certain amount of time ?
<niemeyer> Perhaps "upcoming" + "jdstrand"?
<ogra> (or a forum notification, doesnt need to be mail indeed)
<niemeyer> I expect this list to never be empty.. anything over a week needs resolution or continued discussion until we resolve it
<niemeyer> So it's more a continuous process than something we need to be reminded about
<mup> PR snapd#3436 opened: tests: fix econnreset on staging <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3436>
<ogra> k
<mvo> stgraber: hey, I wrote a simple lxd snap integration test so that we don't break it accidnetly https://github.com/snapcore/snapd/pull/3372 - however I get errors on 14.04 and 16.04-32, one looks like this "error: Get http://unix.socket/1.0/operations/a59c76b5-5f7c-4b39-b8c8-05315404a32a/wait: EOF" the other one (14.04) s a timeout. are those platforms supposed to work? if so, what can I do to help debugging?
<mup> PR snapd#3372: tests: add basic lxd test <Created by mvo5> <https://github.com/snapcore/snapd/pull/3372>
<zyga_> mvo: I think 14.04 is not going to work (CC jdstrand )
<jdstrand> if 14.04 is using the lts kernel, I don't know why it wouldn't work
<jdstrand> assuming it has all the required debs installed
<cachio_> mvo, the change to move the prepare_each_classic to project level has broken the upgrade tests
<cachio_> mvo, I am gonna revert the change
<mup> PR snapd#3428 closed: tests: add snap-confine privilege test <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3428>
<mvo> cachio_: ok, thanks for trying it!
<cachio_> mvo, sure
 * zyga reboots to test something
<mup> PR snapd#3430 closed: tests: modify core before calling set <Created by fgimenez> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3430>
<iliv> davidcalle, I continue exploring aliases and I've just realised one doen't even need aliases: in snapcraft.yml to set up manual aliases. Was it different in some prior version to 2.25?
<Pharaoh_Atem> morphis: I'll take a look at the PR later today
<morphis> Pharaoh_Atem: thanks
<stgraber> mvo: sorry, sprinting. We run daily tests of the LXD snap on 14.04 and 16.04, works on both for us.
<stgraber> mvo: https://jenkins.linuxcontainers.org/job/lxd-test-snap/
<zyga_> jdstrand: do you have a chance to give me a +1 here: https://github.com/snapcore/snapd/pull/3370
<mup> PR snapd#3370: many: derive implicit slots from interface meta-data <Created by zyga> <https://github.com/snapcore/snapd/pull/3370>
<kyrofa> zyga, any idea what's happening here? https://askubuntu.com/questions/922484/how-to-install-telegram-snap-on-ubuntu-16-04-2
<zyga_> kyrofa: looing
<zyga_> well, DNS
<zyga_> no idea why
<kyrofa> That error is... awful
<cachio_> mvo, the env cleanup PR passing
<zyga_> kyrofa: yes, chipaca opened a thread about this already
<zyga_> https://forum.snapcraft.io/t/network-ish-error-messages/862
<zyga_> kyrofa: here ^
<jdstrand> zyga_: probably a bit later today, if not first thing tomorrow
<mvo> stgraber: thank you, what is the link to see the source of your test?
<zyga_> niemeyer: the lock issue is unlocked: https://forum.snapcraft.io/t/test-failures-with-cannot-create-lock-directory-run-snapd-lock/390/19
<zyga_> lazyPower: ^
<lazyPower> zyga_: thats consistent with my findings
<zyga_> lazyPower: can you explain why are you using lxd without apparmor?
<zyga_> lazyPower: is this something that was recommended to you?
<lazyPower> zyga_: namely because of flannel networking
<zyga_> lazyPower: can you comment on the forum please, we can look for a solution together
<zyga_> and I'm sorry it took so long to find
<zyga_> niemeyer: my initial hunch was right (wrong profile) but the origin of the profile is very very unexpected
<lazyPower> zyga_: certainly let me wrap up what i'm working on and i'll context switch back over to lend some detail
<niemeyer> \o/
<zyga_> lazyPower: thank you!
<zyga_> JamieBennett: hey
<Shannon_> might not be the best channel, but I'm trying to put snaps into a docker contrainer, and I'm having some problems.
<lazyPower> zyga_: ok i hope that helps. i looped in some additional names on that thread to cover their specific domains if you have any questions about them specifically that i didn't answer in the generalized response.
<zyga_> lazyPower: I saw, I already replied to your question
<lazyPower> +1 understood
<zyga_> lazyPower: I think we need to look at our options but I don't have a good idea of how to make it nice
<zyga_> lazyPower: apart from disabling confinement for snap-confine on the host as well
<lazyPower> yeah, i just want to make sure we aren't opening pandoras box in terms of both security and usability
<lazyPower> i'm good at that for whatever reason, opening cans of worms i never intended to open.
 * zyga_ calls it a dat
<zyga_> day*
<mup> PR snapcraft#1355 closed: go plugin: filter the main packages go-packages are defined <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1355>
<cachio_> niemeyer, there?
<nacc> so I just tried to update my classic snap to build on zesty 17.04 and got the following error https://launchpadlibrarian.net/322816537/buildlog_snap_ubuntu_zesty_amd64_git-ubuntu_BUILDING.txt.gz
<nacc> specifically: W:GPG error: http://ppa.launchpad.net/snappy-dev/tools/ubuntu zesty InRelease: The following signatures couldn't be verified...
<mup> PR snapcraft#1356 opened: common: find data files via sys.prefix <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1356>
<sdrobertw> kyrofa: I still have that summary blog in the pipeline, been super busy. Maybe 1-2 more weeks please :) I will keep you posted once it is ready.
<sdrobertw> kyrofa: have not forgot about it...
<mup> PR # closed: snapd#2592, snapd#2837, snapd#3051, snapd#3111, snapd#3120, snapd#3222, snapd#3260, snapd#3317, snapd#3340, snapd#3346, snapd#3348, snapd#3365, snapd#3370, snapd#3372, snapd#3383, snapd#3391, snapd#3398, snapd#3399, snapd#3405, snapd#3406, snapd#3409, snapd#3410, snapd#3411,
<mup> snapd#3412, snapd#3414, snapd#3416, snapd#3420, snapd#3429, snapd#3431, snapd#3432, snapd#3433, snapd#3435, snapd#3436
<mup> PR core-build#13 closed: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>
<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-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#13 opened: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>
<mup> PR # opened: snapd#2592, snapd#2837, snapd#3051, snapd#3111, snapd#3120, snapd#3222, snapd#3260, snapd#3317, snapd#3340, snapd#3346, snapd#3348, snapd#3365, snapd#3370, snapd#3372, snapd#3383, snapd#3391, snapd#3398, snapd#3399, snapd#3405, snapd#3406, snapd#3409, snapd#3410, snapd#3411,
<mup> snapd#3412, snapd#3414, snapd#3416, snapd#3420, snapd#3429, snapd#3431, snapd#3432, snapd#3433, snapd#3435, snapd#3436
<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 # opened: snapcraft#1183, snapcraft#1258, snapcraft#1277, snapcraft#1291, snapcraft#1298, snapcraft#1302, snapcraft#1313, snapcraft#1314, snapcraft#1316, snapcraft#1318, snapcraft#1331, snapcraft#1332, snapcraft#1335, snapcraft#1337, snapcraft#1340, snapcraft#1342, snapcraft#1343,
<mup> snapcraft#1345, snapcraft#1346, snapcraft#1348, snapcraft#1349, snapcraft#1350, snapcraft#1352, snapcraft#1354, snapcraft#1356
#snappy 2017-06-07
<mup> PR snapd#3437 opened: tests: apt autoclean <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3437>
<zyga> good morning!
<zyga> mvo: hey, did you see the resolution of the lock bug?
<icey> any idea why a snap would not list its aliases in `snap aliases`?
<zyga> icey: that's something pedronis would know
<icey> to expand a bit, the app in the snapcraft.yaml hasthe alias listed (aliases: [rg]), but it isn't listed at all with the snap installed
<mvo> hey zyga - good morning
<mvo> zyga: yeah, looks like the root cause is found which is great
<mup> PR snapd#3436 closed: tests: fix econnreset on staging <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3436>
<mup> PR snapd#3432 closed: tests: clean journalctl logs on trusty <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3432>
<mup> PR snapd#3414 closed: tests: show available entropy on error <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3414>
<mvo> morphis: which PR did you asked me to review yesterday? sorry, forgot about it and want to do it now
<mvo> apw: hey, good morning! are there any blockers for 2.26.4 into -propsed left? the artful arm build failure is fixed and afaics autopkgtests on artful are also happy
<morphis> mvo: hey!
<morphis> mvo: https://github.com/snapcore/snapd/pull/3365 and https://github.com/snapcore/snapd/pull/3222 are the most relevant ones
<mup> PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<morphis> mvo: where I would really like to get #3222 merged as its pending for nearly 1.5 months now
<mvo> if someone could do a second review on #3348 that would be great
<mvo> morphis: thanks, checking
<morphis> mvo: let me look at
<morphis> #3348
<mvo> morphis: isn't 3365 blocking on a second gustavo review?
<morphis> mvo: it is
<morphis> mvo: both PRs are
<morphis> but I hope we can spot all minor things until he has time to look again
<mvo> morphis: :) makes sense
<morphis> mvo: thanks for the review on the suse PR
<morphis> mvo: fixed the things you pointed out in https://github.com/snapcore/snapd/pull/3406
<mup> PR snapd#3406: tests,packaging: add package build support for openSUSE <Created by morphis> <https://github.com/snapcore/snapd/pull/3406>
<mvo> thanks morphis
<morphis> np
 * zyga will soon have time to do some reviews
<Chipaca> Tribaal: i like where (i imagine) you're going with your 'how to make a very simple deb package' post :-)
<zyga> oookay
 * zyga has 93 patches
<mup> PR snapd#3111 closed: snapd: initial implementation for systemd software watchdog for snapd <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3111>
<mvo> zyga: 93 patches for what?
<zyga> mvo: for allowing base declaration to be declared alongside each interface
<mvo> zyga: once you did that, I would love to talk about base-snaps and snap-confine, the next step for 3317 is snap-confine support
<zyga> excellent
<zyga> ho in 10 min?
<mvo> zyga: yeah, something like this, I'm in the middle of a branch myself, so make that ~15min :)
<apw> mvo, so do i take it the build failure was triggered by an external artful specific issue which has been fixed and those builds retried ?
<Chipaca> pedronis: is this https://forum.snapcraft.io/t/auto-aliasing-and-duplicate-aliases/907 a question for you?
<mvo> apw: correct, arm/armhf is now building with PIC by default and that required a non-change rebuild of apparmor, I did that and things are fine
<apw> mvo, then no i don't think there are any blockers, and i'll go sort that out
<mvo> apw: yay, thanks a lot!
<morphis> zyga: can you add your PRs for snap-confine to https://forum.snapcraft.io/t/including-snapd-in-the-opensuse-factory-branch/863 ?
<zyga> morphis: I haven't pushed them yet but I will do, I'm adding the last part of the base-policy work
<morphis> zyga: didn't you push at least the spread test one?
<zyga> morphis: then I'll have a call with mvo and then I'll resume snap-confine work, sorry for keeping you waiting
<morphis> I am sure I saw one
<morphis> zyga: np
<zyga> morphis: ah, yes, that one landed I think
 * zyga looks
<pedronis> Chipaca: yes,  have bookmarked will answer to it
<Chipaca> pedronis: ok
<zyga> morphis: done
<morphis> zyga: thanks!
<zyga> Chipaca: hey, how to use http to POST some data to /v2/debug endpoint
<zyga> Chipaca: I try the naive "http snapd:///v2/debug '...'" but this fails on invalid header name
<Chipaca> 1 sec, let me try it here :-)
<zyga> Chipaca: should I redirect the actual input via < and make it look like a http request?
<zyga> Chipaca: I added a new debug method and I want to play with it
<zyga> Chipaca: if you can post things like "ensure-state-soon" that's enough
<zyga> Chipaca: ah, I got it
<Chipaca> zyga: http snapd:///v2/debug action=ensure-state-soon
<zyga> :D
<zyga> thanks!
<Chipaca> np!
<zyga> I used more brute force way
<zyga> << EOF
<zyga> and then I typed the JSON
<Chipaca> yes, that also works
<Chipaca> but http knows about json body POSTs
<Chipaca> :-)
<mvo> zyga: I need to have lunch soon, so we need to postpone the HO
<zyga> mvo: sure
<mup> PR snapd#3438 opened: daemon: make snapd a "Type=notify" daemon and notify when startup is done <Created by mvo5> <https://github.com/snapcore/snapd/pull/3438>
<zyga> mvo: I'm in the HO for some time, just join me when you can :)
<zyga> mvo: one more thing
<zyga> mvo: to get base snaps to work on core systems we will need to treat them the same way as we do on classic
<zyga> mvo: with pviot root and what not
<zyga> mvo: (which is actually nice)
<zyga> mvo: I won't make that change today
<Saviq> hey all, any idea where did https://developer.ubuntu.com/snappy/guides/mir-snaps go?
<ogra> Saviq, i think davidcalle was working on getting it back
<zyga> mvo: ok, I have a branch with the --base snap option
<zyga> mvo: now to glue it to snap-exec
<zyga> mvo: did you land your branch that adds information about the base snap to snap info?
<zyga> mvo: ^ pushed as 3439
<zyga> mvo: let's land your earlier branch and iterate
<mup> PR snapd#3439 opened: cmd/snap-confine: add support for --base snap <Created by zyga> <https://github.com/snapcore/snapd/pull/3439>
<davidcalle> Saviq: should be online by EOD or tomorrow
<zyga> mvo, Chipaca: can you please +1 a trivial 3440
<zyga> I'll merge it when it goes green, I have some stuff I want to propose on top
<mup> PR snapd#3440 opened: interfaces: move base declaration to the policy sub-package <Created by zyga> <https://github.com/snapcore/snapd/pull/3440>
<mup> PR snapcraft#1314 closed: catkin plugin: add support for rosinstall files <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1314>
<pedronis> Chipaca: I tried to answer
<mup> PR snapcraft#1357 opened: tests: do not break a systems `bzr whomai` <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1357>
 * Chipaca ~> lunch
<morphis> mvo: looks like we don't have .vendor.tar.* tarballs for the 2.26.4, right?
<morphis> only see one for 2.26.1 on https://github.com/snapcore/snapd/releases
<jdstrand> ogra: hi! friendly ping that 4.4.0-79 is out for bbb
<ogra> jdstrand, friendl pong that edge already has the new package ;)
<jdstrand> I see it is in edge (nice!)
<ogra> (waiting for my bbb to auto-upgrade
<ogra> )
<jdstrand> ah
<ogra> (because i want to test something alongside)
<jdstrand> ogra: curious if edge is auto-uploaded?
<ogra> once i see it boots i'll push it to the other channels
<ogra> yeah, it is
<jdstrand> nice
<ogra> with my work on split-initrd i plan to re-ork the whole process to actually use build.snapcraft.io though
<ogra> *re-work
<ogra> and move linux-generic-bbb to GH
<mvo> morphis: 2.26.4 is missing indeed, I take care of it today
<morphis> mvo: thanks!
<zyga> Chipaca, pedronis: 3441 is for you
<mup> PR snapd#3441 opened: cmd,daemon: add debug command for displaying the base policy <Created by zyga> <https://github.com/snapcore/snapd/pull/3441>
<mvo> zyga: re one more thing> indeed, it will behave like on classic right now
<zyga> mvo: yes, I agree
<mvo> zyga: ta
<mvo> zyga: and thanks for the branch!
<zyga> mvo: I think it's not a big deal (less code actually) but some stuff will need to change
<mvo> zyga: I check it out now
<zyga> mvo: I will do that but not today, I need to work on stuff for openSUSE for morphis first
<zyga> mvo: and then I want to return to the core/base snap staleness issue
<zyga> mvo: but if you are blocked by anything please ping me, it should be easy :)
<mvo> zyga: yeah, I think we need richer yam (as we talked about) in the medium term
<mvo> zyga: no worries, thanks! lets aim for EOW for some progress with bases
<zyga> mvo: I'm pretty sure we can run stuff today if you land your other branch that has the name of the base snap in snap info, and pull the base snap on install
<zyga> mvo: I can quickly patch snap run to pass --base next
<mvo> zyga: no worries, I can do the --base PR
<mvo> zyga: I will also need to look at some 2.26.4 releated release work :/
<zyga> oh? more fun?
<mvo> zyga: yeah, need to investigate a potential trusty bug
<zyga> mvo: oh, anything I can help with?
<zyga> mvo: is it related to rshare of /snap/
<mvo> zyga: the snap confine profile rewrite is looking for "snap.confine.real" but on trusty it looks like we don't call it .snap-confine.real :/
<mvo> zyga: andy spotted this while reviewing the diff
<zyga> mvo: oh, interesting
<mvo> zyga: I have not looked at the details yet, I will finish 3438 and continue then
<zyga> mvo: I changed that later to always call it .real
<zyga> mvo: at least in testing
<zyga> mvo: but hmm hmm, indeed
<mvo> zyga: plus it looks like a test for this is missing or incorrect (in spread)
<zyga> mvo: are you talking about maintainer script or the code in snapd that relates to core and reexec
<mvo> zyga: feel free to grab it if you want :)
<mvo> zyga: core and re-exec
<mvo> zyga: but like I said, I have not looked into the details yet, just got word from andy that it may be fishy
<zyga> mvo: hmm, but isn't the core always 16.04 so the profile name is fixed?
<zyga> aha
<zyga> I'm jumping into a slot of calls, I can look with you after the standup
<mvo> zyga: aha, indeed, i think you are right, will double check
<mup> PR snapd#3412 closed: tests: fix for snapd-reexec test cheking for restart info on debug log <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3412>
<Saviq> davidcalle, thanks
<Chipaca> HO is having one of those days it seems
<didrocks> jdstrand: hey, I'm having a weird issue/question on apparmor vs desktop snap
<didrocks> jdstrand: so, there are some theme properties (like dark theme) which are in a file ~/.config/gtk-3.0/settings.ini
<didrocks> it's basically gtk-application-prefer-dark-theme=1
<didrocks> I was going to test before adding access to that file in the unity7 interface
<didrocks> the snap is a confined one (gtk3-demo), which has the home plug. I create a symlink at launch in SNAP_USER_DATA/.config/gtk-3.0/settings.ini
<didrocks> if I snap run --shell
<didrocks> and $ cat $SNAP_USER_DATA/.config/gtk-3.0/settings.ini
<didrocks> cat: /home/didrocks/snap/gtk3-demo/x1/.config/gtk-3.0/settings.ini: Permission denied
<didrocks> as expected (as you told, .* are forbidden by default in the apparmor profile)
<didrocks> same with direct cat /home/didrocks/.config/gtk-3.0/settings.ini
<didrocks> however, running gtk3-demo, it applies the dark and white themes based on that file!
<didrocks> if gtk-application-prefer-dark-theme=1 in settings.ini -> running gt3-demo -> dark
<didrocks> if gtk-application-prefer-dark-theme=0 in settings.ini -> running gt3-demo -> white
<didrocks> and that's the only thing I change!
<didrocks> I'm wondering how come I can't cat it, but in some way, gtk is able to read it (and wonder if we don't have some security apparmor profile issues)
<zyga> didrocks: reading is done differently than writing in gsettings, no?
<didrocks> zyga: this isn't gsettings, it's a plain file
<didrocks> (that's why I'm giving file path above, not gsettings schema path ^)
<zyga> didrocks: can you show the apparmor denial you are getting?
<didrocks> zyga: there is none in sudo snappy-debug.security scanlog
<didrocks> when launching gtk3-demo
<didrocks> but if I cat in snap run gtk3-demo --shell, I'm getting the expected:
<didrocks> Log: apparmor="DENIED" operation="open" profile="snap.gtk3-demo.gtk3-demo" name="/home/didrocks/.config/gtk-3.0/settings.ini" pid=21903 comm="cat" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
<didrocks> File: /home/didrocks/.config/gtk-3.0/settings.ini (read)
<zyga> didrocks: dmesg | grep DENIED
<zyga> aha
<zyga> right
<didrocks> so, basically, gtk has access to this file content, which sounds weirdâ¦
<zyga> didrocks: note that dot-files in the real home are forbidden
<zyga> didrocks: but in the remapped home you can do anything
<morphis> mvo: updated https://github.com/snapcore/snapd/pull/3222
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<didrocks> zyga: yes, but that doesn't explain why gtk3 can read the original file in real ~/ though
<zyga> is it getting that via dbus perhaps?
<didrocks> nope
<didrocks> as told above, the only change is done via that file between 2 launchs that are applied
<zyga> well, that doesn't rule out dbus
<didrocks> zyga: no, it can clearly access the file
<didrocks> [pid 22370] access("/home/didrocks/.config/gtk-3.0/settings.ini", F_OK) = 0
<didrocks> [pid 22370] open("/home/didrocks/.config/gtk-3.0/settings.ini", O_RDONLY) = 10
<jdstrand> didrocks: it sounds like the one where it reads the file is not running under confinement
<jdstrand> didrocks: how are you launcing it? when it is running, what does 'ps auxwwZ' tell you the profile name is for that process?
<didrocks> jdstrand: ohhhhhhhhhhhhhhhh, sorry to have bothered you, the snap path is still after the system one, well, scratch thatâ¦
<jdstrand> heh, that would do it :)
<didrocks> jdstrand: I was soooooooooooooooo puzzled
<jdstrand> hehe :)
<Tribaal> Chipaca: shhhh don't spill the beans about my master plan (yet) :)
<cachio_> zyga, I left  a comment on https://github.com/snapcore/snapd/pull/3433
<mup> PR snapd#3433: tests: restoring the /etc/environment and service units config for each test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3433>
<cachio_> zyga, in the state dir we can store the snapd state, and also en env file and other stuff that could be needed independently
<mvo> morphis: do you have a suse or fedora vm where snapd is not started by default? if you run there: "snapctl is-active snapd.service", what output do you get?
<mvo> zyga: or you maybe -^ ?
<psftw> is there an official AMI or method to produce one for ubuntu core?
<psftw> I've googled a bit and saw this was announced in 2014, but couldn't actually find an AMI today
<Pharaoh_Atem> mvo: why do we use /etc/environment for the snapd units in Ubuntu?
<Pharaoh_Atem> in Fedora, we use /etc/sysconfig/snapd
<Pharaoh_Atem> (if it exists)
<Pharaoh_Atem> the Debianish counterpart would be /etc/default/snapd
<Pharaoh_Atem> (though imo, /etc/default is a horrible name for this directory and what it does)
<morphis> mvo: let me check
<mvo> Pharaoh_Atem: this is used for a systemd environment, a typical use case is a system-wide proxy environment. its typically set there on debian/ubuntu. is /etc/environment not used in fedora at all?
<mvo> morphis: thank you
<Pharaoh_Atem> mvo: it exists, it's just empty
<Pharaoh_Atem> in Fedora, we don't really use it
<morphis> mvo: https://paste.ubuntu.com/24801073/
<mvo> Pharaoh_Atem: if someone wants to configure a systemwide proxy (e.g. via http_proxy=http://proxy.internal) - whats the typcial way to do that?
<cachio_> zyga, at the end I am implementing what you suggested
<mvo> morphis: thank you
<morphis> mvo: that is on opensuse
<Pharaoh_Atem> mvo: you can set that in NetworkManager
<Pharaoh_Atem> it applies network wide
<Chipaca> Pharaoh_Atem: how?
<mvo> Pharaoh_Atem: do people use this on server too via nmcli? mostly curious
<Pharaoh_Atem> mvo: Yep
<Pharaoh_Atem> it's the preferred way to manage networking since RHEL 7 / Fedora 16
<Chipaca> Pharaoh_Atem: i mean, how does it set things "network wide", such that e.g. curl picks it up?
<mvo> Pharaoh_Atem: thank you! yeah, my next question is the one that Chipaca already asked, i.e. what do we need to do in snapd to honor this :)
<Pharaoh_Atem> afaik, it's exposed via pacrunner?
<Pharaoh_Atem> and libproxy
<Pharaoh_Atem> and a few other means
<mvo> Pharaoh_Atem: thanks, sounds like we need to research that a bit deeper then, we definitely want to have seamless proxy support for nm
<Pharaoh_Atem> I moved the snapd units to read /etc/sysconfig/snapd because you can set things other than proxy stuff to have snapd process it
<Pharaoh_Atem> and since snapd doesn't support a config file, it's the best I have
 * mvo nods
<Chipaca> we'll have a config file someday
<Chipaca> â¦ but not today
<Pharaoh_Atem> mvo: not to mention, I can also forbid things other than snapd from manipulating the file
<Pharaoh_Atem> through SELinux (or in your case, AppArmor)
<mvo> Pharaoh_Atem: heh, indeed!
<Pharaoh_Atem> the SELinux policy module already does this by default for distros that use /etc/sysconfig (RH, SUSE, Gentoo, Arch) and /etc/default (Debian, Ubuntu)
 * Pharaoh_Atem wishes /etc/default was renamed to /etc/sysconfig, as he thinks it's more accurate in purpose
<mup> PR snapd#3440 closed: interfaces: move base declaration to the policy sub-package <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3440>
<zyga> cachio_: thanks, I'll chek that out
<morphis> Pharaoh_Atem: btw. you made any progress on snap-mgmt.sh?
<zyga> mvo: let me check
<zyga> mvo: I'm typing from suse :)
<morphis> Pharaoh_Atem: mvo brought this up at https://forum.snapcraft.io/t/share-code-between-debian-postrm-purge-and-snap-mgmt-sh/915/2 earlier today
<Pharaoh_Atem> morphis: I made changes but no one tested to tell me if it's all good yet
<Pharaoh_Atem> morphis: I submitted updates to snapd in Fedora that have been sitting in updates-testing with more changes
<morphis> Pharaoh_Atem: ah nice! based on 2.26.4?
<Pharaoh_Atem> not yet
<Pharaoh_Atem> I wanted to know whether snap-mgmt.sh does all the things right first
<Pharaoh_Atem> if there's something to fix, I was going to bundle it with snapd 2.26.4 update
<Pharaoh_Atem> snapd-2.26.3-3.fc{24,25,26} is the current build
<Pharaoh_Atem> the last time you gave me feedback was a month ago
<zyga> pedronis: hey, I'm looking at the assertion response but I think it was actually easier first time around
<zyga> pedronis: it seems that now I cannot just use Client().Debug() as I need to poke at headers and fire a custom decoder
<morphis> Pharaoh_Atem: hm, then I forgot to press the button
<zyga> pedronis: where all I want is the simple string for security team to review
<morphis> but I've tested 2.26.3 and it was working but left an empty /var/lib/snapd dir
<zyga> pedronis: I adapted the code to load assertion from the state as suggested
<zyga> pedronis: am  I missing something simple that lets me just access the response data as-is?
<Pharaoh_Atem> morphis: even 2.26.3-3?
<morphis> zyga, mvo, Pharaoh_Atem: can you guys give a vote on https://github.com/snapcore/snapd/pull/3365 by your EOD?
<mup> PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>
<morphis> Pharaoh_Atem: hm, let me power up my fedora VM and check
<coreycb> is there any way to share files among different parts in a snap?  for example I want to use the dump plugin to dump patches. and then in another part use those patches to patch upstream code.
<zyga> morphis: maybe, I'll try :/
<coreycb> ok i answered my question. yes it's possible to share files amoung parts. was having trouble getting it going due to my own error.
<mup> PR snapd#3442 opened: snap: ensure security polices are re-created <Created by mvo5> <https://github.com/snapcore/snapd/pull/3442>
 * zyga feels so-so and goes back to sleep
<pedronis> zyga: sorry, I forgot about Client.Debug, what you were doing make sense, though you probably want to add a level more of indirection
<pedronis> {"base-declaration": ... } or something
<cachio_> zyga, change pushed
<cachio_> zyga, question, how do you usually set a dependency between branches?
<Chipaca> so... i have a first pass at the services branch
<Chipaca> https://github.com/snapcore/snapd/compare/master...chipaca:snap-services
<Chipaca> one thing i'm unsure about
<Chipaca> is the lack of overlord in that code :-)
<Chipaca> niemeyer: is that ^ how you imagined it working, or were you thinking that this would happen via tasks?
<niemeyer> Chipaca: Sounds like we can start without tasks, and move there if/when we need to
<Chipaca> niemeyer: excellent
<Chipaca> but now eod
<morphis> Pharaoh_Atem: 2.26.3-3 still gives me the empty /var/lib/snapd
<Pharaoh_Atem> anything in the logs that indicate why?
<morphis> niemeyer: you have time to approve https://github.com/snapcore/snapd/pull/3365 today?
<mup> PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>
<morphis> Pharaoh_Atem: not really
<morphis> Pharaoh_Atem: will have a more close look tomorrow morning
<Pharaoh_Atem> okay, cool, thanks
<kyrofa> sdrobertw, I know how that goes! Thanks for keeping me on the loop :)
<kyrofa> sdrobertw, the idea was raised to put the series on https://www.96boards.org/projects/ . What do you think?
<sdrobertw> There is an AWS live stream going on right now (around IoT) for anyone who is interested: https://live.awsevents.com/IoTevent
<ogra> jdstrand, https://dashboard.snapcraft.io/dev/snaps/7788/rev/1/ one for you :)
<ogra> (finally an ubuntu core board with proper SATA and gigabit ethernet ;) )
<ogra> (and it uses linux-generic-bbb!)
<jdstrand> ogra: done
<ogra> whee !
<ogra> i guess auto-approavl only after the next review-tools update as usual ?
<niemeyer> morphis: Yes, I can look again
<niemeyer> morphis: What's the status there?  I've seen conversations about it in the last couple of days
<jdstrand> ogra: yes. I updated the tools, but ping me until it auto-updates
<jdstrand> (we need a store sync)
<ogra> jdstrand, no hurry, i'm fine with waiting
<sdrobertw> kyrofa: would love to have the series on project page.
<sdrobertw> kyrofa, is there any way you could send me an email with all links/resources consolidated into one place? robert.wolff@linaro.org
<sdrobertw> This would make things much easier for me
<kyrofa> sdrobertw, sure, though that sounds like the stuff that will be contained in the pull request I make to get it into projects. Want me to just do that?
<kyrofa> (happy to send an email as well)
<sdrobertw> kyrofa: sure! That work just fine actually. Please let me know if I can help with anything. You will be second person to test this process.
<sdrobertw> It is all very new
<kyrofa> sdrobertw, seems well-documented so far
<sdrobertw> :)
<niemeyer> morphis: LGTM... tests are broken with an error that seems real
<morphis> niemeyer: yeah saw that already, comes from a merge with master, will fix tomorrow
<morphis> niemeyer: thanks!
<niemeyer> morphis: np, and thanks for pushing it forward
<sergiusens_> niemeyer: hey, if you are still on, can I get your insight on this one https://forum.snapcraft.io/t/snapcraft-build-on-hint-for-builders/939?u=sergiusens ? I am trying to be future proof here and the build.snapcraft.io guys are interested in this to start supporting more arches out of the box
<mup> PR snapcraft#1349 closed: plugins: clarify wording of cross-compilation unsupported error <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1349>
<mup> PR snapcraft#1356 closed: common: find data files via sys.prefix <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1356>
#snappy 2017-06-08
<mup> PR snapcraft#1340 closed: state: save all the build packages as global <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1340>
<mup> PR snapcraft#1343 closed: go plugin: Cross compile with CGo <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1343>
<mup> PR snapcraft#1358 opened: release changelog for 2.31 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1358>
<Amorris> Is it possible to install snap on Arch Linux without pacman?
<Amorris> Such as through a .tar.gz file?
<morphis_> mvo: would be awesome if you can look at https://github.com/snapcore/snapd/pull/3365 again this morning and if you're ok, merge it now that niemeyer approved it
<mup> PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>
<morphis_> CI is already green
<zyga> good morning
<mup> PR snapd#3443 opened: Unity7 interface grows gtk2/3 settings and user's specific ini <Created by didrocks> <https://github.com/snapcore/snapd/pull/3443>
<mvo> fgimenez: 2.26.4 is in -proposed now everywhere, could you please kick of the SRU verification?
<fgimenez> mvo: sure! on it, the automated tests were actually triggered a few days ago but there was a problem in the logic that determines the release branch to execute the tests from https://travis-ci.org/snapcore/spread-cron/builds/238479940#L300 i'll fix that and retrigger
<mvo> fgimenez: thank you
<fgimenez> mvo: np i'll begin too with the changelog review, will keep you posted
<mvo> morphis_: do you happen to know if the "proxy" helper is installed on fedora/suse by default?
<fgimenez> mvo: btw i see that the deb was detected in -proposed about 6 days ago, is that correct? has it been updated since then? (just to make sure that we are detecting changes in proposed correctly)
<mvo> fgimenez: updates arrived yesterday
<mvo> fgimenez: 6 days looks not quite right
<fgimenez> mvo: ok thx i'll take a look
<mvo> fgimenez: https://launchpad.net/ubuntu/+source/snapd has the exact times, ~21h ago
<icey> flexiondotorg: cholcombe and I have already done some poking around on https://github.com/rust-lang-nursery/rustup.rs/issues/1144
<fgimenez> mvo: ok thanks, in spread-cron we are currently watching http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html (interestingly there's no snapd in that page now, and it seems that it was there 6 days ago..), i'll update it to look into https://launchpad.net/ubuntu/+source/snapd
<morphis_> mvo: proxy helper?
<mvo> morphis_: its a binary from libproxy called "proxy"
<morphis_> ah, let me check
<mvo> morphis_: is that there by any chance?
<morphis_> not installed by default
<morphis_> but libproxy-bin provides it
<morphis_> let me try
<mvo> morphis_: if its not there by default, thats all I need to know. that is on fedora or suse?
<morphis_> mvo: fedora 25
<morphis_> mvo: let me try suse
<mvo> morphis_: thank you
<morphis_> mvo: if you're adding a dependency can you add it for suse and fedora in packging too?
<mvo> morphis_: I will explore it a bit, maybe dlopen(libproxy) is fine
<morphis_> mvo: is that for adding proxy support system wide?
<morphis_> mvo: libproxy-tools it is on suse and not installed by default
<Chipaca> interestingly proxy itself doesn't look at the usual env vars
<mvo> morphis_: yeah
<mvo> Chipaca: oh? that sounds very wrong
<Chipaca> Â¯\_(ã)_/Â¯ a matter of looking at the env and falling back to libproxy i guess?
<mvo> morphis_: I talked to Son_Goku yesterday and he mentioned that fedora is not setting the systemwide proxy via environment but instead uses network-manager and the best option to talk to it seems to be libproxy
<mvo> Chipaca: indeed
<morphis_> mvo: yeah libproxy looks really good for this
<mvo> Chipaca: it will also mean we need to (potentially) create a new http.Client{} for each request as the proxy is per-url in this model
<Chipaca> http.Transport
<Chipaca> but yes
<mvo> morphis_: the cheapest option is the exec.Command("proxy", url).Output() but adding a dependencies feels slightly ugly
<mvo> Chipaca: yeah, sorry, a transport into the client of course
<zyga> it's terrible that after decades of broad deployments proxy support in linux is not in libc
<zyga> and everyone has to muck around with their special little snowflake
<morphis_> mvo: implementing our own libproxy isn't much better, isn't it?
<zyga> (contrasting other platforms that do this right)
<morphis_> zyga: yeah, bionic has this AFAIK
<mvo> morphis_: of course not :) sorry, what I mean is adding a hard dependency, I was curious to see if we could just dlopen(libproxy) and just ignore if its not there
<morphis_> mvo: however, how would applications get the proxy configuration?
<morphis_> mvo: ah
<morphis_> why not
<mvo> morphis_: looking again it is probably ok nowdays, it used to be heavy on further dependencies but it seems like all of those are now pulled in via plugns. to support "pac" proxy configuration a JS interpreter is needed iirc
<Chipaca> mvo: the biggest problem i see with all this is the "here's a list of proxies, try them in order" idea
<mvo> Chipaca: hm, we could simply not support that (initially at least)?
<Chipaca> mvo: also note proxy can return something that looks like socks://....
<Chipaca> lel
<mvo> Chipaca, morphis_: thinking about it some more I guess we need to call an external helper or we pull in cgo again into the deamon
<mvo> Chipaca: yeah
 * mvo scratches head
<Chipaca> this sounds like *fun*!
<morphis_> mvo, zyga: I would like to get https://github.com/snapcore/snapd/pull/3365 merged now
<mup> PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>
 * zyga looks
<Chipaca> mvo: one more fun thing about using libproxy
<Chipaca> it brings lin libstdc++
<ogra> hmm
<ogra> ogra@sabrelite:~$ snap info core |grep refreshed
<ogra> refreshed:   2017-06-08 04:24:21 +0000 UTC
<ogra> ogra@bbb:~$ snap info core|grep refreshed
<ogra> refreshed:   2017-06-07 04:23:44 +0000 UTC
<ogra> why is that different ? isnt the refreshed value coming from the server ?
<pedronis> no, that's refreshed as in the device refreshed
<pedronis> IÂ think
<ogra> that doesnt match uptime
<ogra> 4:20 UTC is actually the time the cron job runs for armhf
<ogra> so that should be generation time
<ogra> oh ... but the bbb didnt refresh ... it is the generation time of the currently installed snap
<zyga> morphis_: merged
<mvo> Chipaca: yeah, ugly but we also have that I think
<morphis_> zyga: you're my hero!
<mup> PR snapd#3365 closed: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3365>
<Chipaca> mvo: have that where?
<morphis_> zyga: lets wait until the suse one finishes then we can merge that one too
<mvo> Chipaca: in the core snap
<mvo> Chipaca: libstdc++ I mean
<Chipaca> mvo: ah! i meant into the snapd binary itself
<zyga> mvo: ok to land the --base branch?
<mvo> Chipaca: yeah, I think we don't want this directly, probably via helper
<mvo> zyga: which one? 3439? or the older 3317 ?
<zyga> 3439
<mvo> zyga: it needs reviews first, no? I will do the first review next
<flexiondotorg> icey Excellent!
<zyga> mvo: yes, I meant that I wanted you to review it :)
<mvo> zyga: aha, yes, will do
<iliv> why does build.snapcraft.io needs access to organizations?
<ogra> iliv, to put webhooks into the tree
<zyga> iliv: for hooks
<ogra> (well, endpoints(
<iliv> well..
<iliv> my account has access to a number of organizations that have nothing to do with my repos that I'd like to use with build.snapcraft.io
<zyga> iliv: I see, I think it would make sense to allow partial access to just the things that are needed
<iliv> I kinda trust you people but most of those organizations will not be happy seeing build.snapcraft.io having access to their accounts
<ogra> it is only needed to put the hook in place once though ...
<ogra> theyx could turn it off afterwards (i know that doesnt help much in most cases)
<iliv> so, what exactly will be done to those organization accounts?
<iliv> you say a webook will be created.. but in which repo (if there are more than one)?
 * ogra doesnt know the tech details, perhaps cjwatson can help 
<cjwatson> iliv: the github access page lets you control this on a per-org basis; you don't have to grant access to all your orgs.  build.snapcraft.io will only install a webhook in repositories that you specifically enable there.
<fgimenez> mvo: zyga Chipaca can we land snapd#3348? it has two +1 and is almost green (just an autopkgtest failure due to the reexec flakiness), it will fix two nightly suites and unblock the spread-cron branches for executing the core-revert test automatically
<mup> PR snapd#3348: tests: add core revert test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3348>
<mup> PR snapd#3348 closed: tests: add core revert test <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3348>
<cjwatson> and in fact the org access is only needed so that BSI can list org-owned repos through the github API; there's a separate permission for installing webhooks
<fgimenez> mvo: thanks! :)
<iliv> cjwatson, I can't control it, though. All I see is a green check mark against organization name and it is not interactive.
<cjwatson> (we ask for admin:repo_hook read:org, in the github scopes language)
<cjwatson> iliv: you can control it on https://github.com/settings IIRC (I would check more specifically but my internet connection is being unusually terrible today)
<zyga> fgimenez: looking
<zyga> fgimenez: that PR had my upublished review
<zyga> darn github
<cjwatson> iliv: oh, I think if it's just a green tick then that's because the org owner has allowed it
<cjwatson> iliv: we don't get to control any of this stuff, it's all up to github
<zyga> fgimenez: can you please look at the PR again?
<cjwatson> https://help.github.com/articles/about-oauth-app-access-restrictions/ has some more details
<fgimenez> zyga: sure, thanks! i'll prepare a follow addressing your comments
<zyga> fgimenez: thank you, I'm sorry I didn't realize I never submitted this review
<zyga> the snap-confine-from-core and the other re-exec tests keep failing randomly
<zyga> I don't remember any branch that didn't fail on this in the past week
<zyga> I'll try to figure out WTF is going on there :/
<mup> PR snapd#3370 closed: many: derive implicit slots from interface meta-data <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3370>
<fgimenez> thank you zyga, i think sergio is also lookign into it
<cjwatson> anyway, as far as I can tell we ask for the absolute bare minimum that we need to install webhooks and see any org-owned repos at all
<zyga> does anyone know of a vim extension that would add a tab to an exsiting vim whenever vim is invoked from command line but another process exists somewhere?
<iliv> cjwatson, yes, it seems to work like you said. kinda weird...
<morphis_> mvo, zyga: approval and a merge of https://github.com/snapcore/snapd/pull/3406 would be  nice :-)
<mup> PR snapd#3406: tests,packaging: add package build support for openSUSE <Created by morphis> <https://github.com/snapcore/snapd/pull/3406>
<zyga> morphis_: looking
<mup> PR snapd#3444 opened: interfaces: compose the base declaration from interfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3444>
<zyga> morphis_, mvo: can you please look at 3444
<morphis_> zyga: sure
<zyga> morphis_: can you merge master into 3406?
<morphis_> zyga: I did this 45min ago
<zyga> morphis_: merging it now would shorten the diff
<morphis_> sure
<zyga> morphis_: correct me if I'm wrong but I still see the fedora changes there
<morphis_> I merged before the merge of the fedora branch
<morphis_> isn't travis doing an automatic merge with master when it runs?
<morphis_> zyga: but merge now
<zyga> morphis_: it's optional
<zyga> morphis_: and we don't do it
<morphis_> zyga: shouldn't travis fail when a merge with master breaks any tests?
<mvo> zyga: base snap branch looks good
<pedronis> morphis_: well if the run is old you don't know because master has moved
<morphis_> pedronis: right but at the point where travis starts, shouldn't it start testing from a combination of master + branch? otherwise test results will always be a lie if master has evolved
<pedronis> it does afaik
<morphis_> ok
<pedronis> but we might still break master because the check is not done on the merging
<zyga> mvo: thanks!
<zyga> Chipaca: can you do a 2nd review so that mvo can iterate on base snaps?
<zyga> morphis_: github has a setting where you can enable a check that disables merging if master has moved
<zyga> morphis_: bue we're not using it
<zyga> morphis_: as it requires a rebase-based workflow
 * zyga hugs rebase
<morphis_> zyga: reviewed #3444
<morphis_> zyga: I see
<Chipaca> zyga: on which pr?
<zyga> Chipaca: on 3439
<mup> PR snapd#3439 closed: cmd/snap-confine: add support for --base snap <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3439>
<zyga> morphis_: reviewed
<mup> PR snapd#3445 opened: tests: add linode-sru backend <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3445>
<zyga> morphis_: updated
<morphis_> zyga: ok
<zyga> morphis_: sorry for being so picky about those comments but I think it is essential
<zyga> morphis_: in a few weeks nobody will remember why fedora or suse is not included in a given test
<morphis_> zyga: commented on all and fixed most
<morphis_> zyga: np, but basically we have all test cases disabled right now
<morphis_> that is why we switched from a blacklist to a whitelist approach
<zyga> morphis_: thanks, ping me and I'll re-read it
<morphis_> a followup PR will clean this up and enable most tests
<morphis_> zyga: ping :-)
<zyga> aha :D
<zyga> reading then
<morphis_> thanks
<morphis_> zyga: approved #3444, thanks for doing the cahnges!
<zyga> morphis_: thank you!
<zyga> morphis_: re-reviewed
<zyga> morphis_: fix one typo and +1
<zyga> morphis_: some heavy conflicts on 3411
<ogra> zyga, hmm
<ogra> "On core systems we don't pivot_root and that
<ogra> has to change before base snaps are fully operational"
<ogra> zyga, can we make sure to get proper ram usage statistics before implementing such a thing (or do i mis-read that ... you want to exec every snap on a core install in pivot_root ?)
<mup> PR snapd#3446 opened: errtracker: Include /etc/apparmor.d/usr.lib.snap-confine md5sum in err reports <Created by mvo5> <https://github.com/snapcore/snapd/pull/3446>
<zyga> ogra: yes, this is required for base snaps
<zyga> ogra: core and classic will behave (finally) exactly the same
<ogra> zyga, well, why do we need base snaps on core installs ... i though they are a lib layer on top of core
<zyga> ogra: no, they are not
<zyga> ogra: base snaps are needed so that we can run snaps that use base snaps (which will soon be most snaps, I think)
<ogra> zyga, in any case we are supporting embedded boards and i suspect pivot_root means there will be more copies of libs and env in ram that we should really measure before
<zyga> ogra: base snaps, roughly, will just use snaps other than core as the root filesystem
<ogra> right, so whats the use case on a core install for that ?
<zyga> ogra: note that we will have less things in the core snap this way
<zyga> ogra: *every* snap will use a base snap
<zyga> ogra: have you been following the base snap discussions on the forum/
<ogra> not closely the last days
<zyga> ogra: core will become a snap with just snapd in it
<ogra> but that sounds really awkward for low end
<zyga> ogra: and what is currently in core will become ubuntu-16 base snap
<ogra> ok
<zyga> ogra: it is required for 16-18 migration
<ogra> that is what i grokked before
<zyga> ogra: and to allow running snaps with different bases on one system
<ogra> but that you plan to pivot_root each and every snap is new to me
<zyga> ogra: how would those work otherwise?
<ogra> or that you want to support different base snaps on some 256M 200MHz IoT board installs
<zyga> ogra: yes, we don't want to have 2nd class devices that don't support an essential feature
<ogra> by simply merging the rootfs on boot
<zyga> what do you mean by merging?
<ogra> and keeping the snaps as they are without duplicating the world in ram
<zyga> why do you think we'd be duplicating something in ram?
<mup> PR snapd#3447 opened: debian: unify built_using between the 14.04 and 16.04 packaging branch <Created by mvo5> <https://github.com/snapcore/snapd/pull/3447>
<ogra> merge core and base on booot ... execute natively
<ogra> like we do today ... just with an additional split of the snapd bits into another snap
<mvo> fwiw, libraries are mapped into ram based on inode number, if that stays the same nothing will be duplicated (someone needs to double check that)
<ogra> if you want to go that route that really should see some measurements
<zyga> ogra: I'm open to suggestions but IMO there is no other route
<mvo> (double check that the inode number stays the same, the mmap mechanism is well understood)
 * zyga checks
<ogra> mvo, thats what i'm saying ... not saying it is wrong or anything but on that low end we shouldnt operate without ameasurments and data
<ogra> *measurements
<ogra> i'm sure pivot_root will have overheard, the question is if that is bytes or megabytes
<ogra> *overhead
<zyga> inode number is the same
<zyga> ogra: why would pivot_root have overhead?
<ogra> because it wraps around something, it is an additional layer
<zyga> I don't think that's true
<zyga> it's a chroot on steroids
<ogra> yes
<zyga> (kind of)
<zyga> ogra: the only overhead is that as core and bases diverge we will see extra copy of libc used by the few services in the core snap, for everything else they will operate exactly the same as today
<ogra> zyga, well, still, it would be good to measure the differences between with and without pivot_root regarding system resources ... we're in embedded territory here ...
<zyga> ogra: that I agree with
<zyga> ogra: it'd be good to come up with a benchmark we can repeat
<ogra> well, just measure rem and cpu usage for the same app snap in both cases
<ogra> *ram
<zyga> ogra: specific snap (revision), specific board, specific script
<ogra> sure
<zyga> so that we can just run this via spread and stay aware
<ogra> well, not needed to do it regulary ..â¦ thats simply stuff you should research before coming up with such an implementation ... once you know if there is a difference and how big it is thats enough
<ogra> it wont change over time so doesnt need to be a regular test
<ogra> ppisati_, do you have a sabrelite ?
<ogra> ppisati_, i'm seeing weird console distrotion when i boot with hdmi and console=tty0 with the current linux-generic from xenial
<zyga> ogra: note that we came up with pivot_root last year, this is nothing new
<zyga> ogra: given what we need to do there's no other way to implement base snaps
<zyga> ogra: I suspect we actually use less memory now as before persistent mount namespaces *each process* would independently pivot_root
<ogra> zyga, well, we get along without base snaps today ... and merging core and base on boot with keeping the native execution would work too ... core specific indeed
<morphis_> zyga: fixe
<zyga> ogra: no it would not work because the whole idea of base snaps is to have more than one
<ogra> zyga, note that i'm not saying anything is wrong though ... but we should have numbers before jumping ahead with implementation
<zyga> ogra: so you cannot use your current rootfs as the rootfs for snaps
<pedronis> zyga: either we way we likely need a root filesystem,  there still the question what really goes into core vs base
<zyga> pedronis: I agree, I think this will clear up as we come closer to the sprint
<ogra> zyga, we do that today ... and why would you want to support multiple base snaps on super-low-end devices ?
<ogra> i always understood that this is not wanted for ubuntu core
<zyga> ogra: we cannot do that once we have more than one  base snap
<zyga> ogra: and we want to have more than one base snap so that we can transition to 18 series
<ogra> sure we can ... we can restrict what can be installed on a core installation
<zyga> ogra: and to allow other distributions to equally participate in the snap distribution
<zyga> ogra: if we restrict we will have to have a flag day for 18 transition and we don't want that
<ppisati_> ogra: nope, i don't have one
<ppisati_> ogra: what is that?
<ogra> imagine you have something like a beaglebone, your ram is limited, your cpu is limited ... do you really want to allow people that install three snaps to have three oses running on that setup because the three snaps use three different bases ?
<pedronis> zyga: notice also that because of the configure hook  the core snap will need a base snap too
<zyga> ogra: yes, if that's what those people want to run I don't want to stand in their way
<ogra> ppisati_, they renamed it to nitrogen6 ... its an IMX board
<pedronis> (at least the configure hook is a likely reason to need one)
<zyga> pedronis: configure hook for which snap?
<pedronis> for teh core snap
<pedronis> the core snap has a hook
<pedronis> nowadays
<zyga> pedronis: right, I was just checking
<ogra> zyga, well, then we can simply give up on IoT boards will just come to hang and crawl with that
<zyga> pedronis: yes, it is likely that the core snap will be special cased to be its own base snap
<zyga> ogra: I doubt that
<pedronis> zyga: well that start to be weird
<pedronis> I fear duplication then
<zyga> duplication of?
<pedronis> stuff that needs to be in the core snap and the base snap
<pedronis> like python or something
<zyga> pedronis: the good thing that base snaps will allow us to do is to almost freely shape the core snap
<pedronis> not really
<zyga> pedronis: as it will no longer affect how anything runs
<pedronis> if the core snap isn't really minimal
<ogra> zyga, well, if i install the mysql snap from that fedora guy, along with the webserver snap from this arch guy on top of my ubuntu core board, i end up with three OSes on disk and in ram
<zyga> pedronis: the initial ubuntu-16 will fork from the current core (snaps snapd)
<ogra> zyga, thats definitely not feasible
<zyga> ogra: yes but this is what you _wanted_
<zyga> ogra: if you don't want to do that, don't do that
<ogra> zyga, how did i know ?
<zyga> ogra: or get the stack from one vendor
<zyga> ogra: snap info will tell you that
<ogra> zyga, you are saying that a user of our SW should know the source in and out ?
<zyga> ogra: anyway, I think this discussion is moot now
<ogra> and why would i look at snap info
<zyga> ogra: same could be said for base-16 and base-18
<ogra> all i wanted was the webserver to act as frontend to a mysql db ...
<ogra> on my $mini-board
<ogra> so i just picked the packages ... done
<ogra> and then notice that the whole thing eats my disk and ram
<pedronis> zyga: anyway there's a problem that likely some core snap config should be part of a base snap configure, but that concept doesn't make sense
<zyga> pedronis: can you give me an example?
<ogra> we could surely make that an optional switch to allow additional base snaps ..â¦ but thats definitely nothing we should have OOTB
<zyga> pedronis: I suspect that base snaps won't have much configuration at first
<pedronis> where would sshd live?
<zyga> pedronis: in the base snap
<pedronis> see
<zyga> er
<zyga> core snap
<zyga> unless we start to allow apps and services on base
<pedronis> see
<zyga> which is something we never discussed
<zyga> base snaps won't have any configuration intially because they won't run any services
<ogra> where else would system services live ?
<pedronis> in the core snap it seems
<ogra> err
<zyga> if we choose to move them to a blessed base snap
<pedronis> but I think we also had a different vision
<zyga> we could do that
<pedronis> where the core snap was mostly just snapd
<pedronis> and its deps
<_28Kb> services must be snaps i guess
<ogra> <zyga> ogra: core will become a snap with just snapd in it
<zyga> pedronis: yes, but that is the road ahead, for now we can start with just a copy of the current core as core and base and then trim them as we go
<ogra> so the system services must be in the base snap
<zyga> ogra: _will become_ :)
<ogra> (in that setup at least)
<pedronis> well or we have a services snap
<abeato> ogra, mvo could we move forward https://github.com/snapcore/core-build/pull/13 ?
<mup> PR core-build#13: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>
<zyga> I think it is all doable but we need to discuss one more thing at the sprint: if we are going to get rid of bootable bits from the core snap
<ogra> well
<ogra> we cant get rid of them ... we can probably move them around though
<zyga> it those go to a new helper snap (ubuntu-core maybe) then this will resolve other questions
<zyga> that's what I meant
<zyga> then on classic systems you'd need base snaps only
<zyga> not even core or ubuntu-core
<zyga> on systems that re-exec you'd pull in core and base snaps
<zyga> and on core systems we'd pull in everything
 * ogra isnt so worried about the resulting rootfs and how we assemble it, thats all easily solvable 
<ogra> but the "multiple base snaps allowed" is really bothering on core
<zyga> ogra: do you have a plan for 18 transition?
<ogra> thats fine if you have endless ressources like on a PC
<ogra> zyga, allow exactly one base snap
<zyga> ogra: that doesn't involve running both 16 and 18 snaps at the same time?
<ogra> or allow two ... still better than "any"
<zyga> ogra: that's one way to make sure nobody can transition until *everything* has a 18 snap as well
<zyga> ogra: if we allow two we might as well allow any
<zyga> ogra: until we measure and show this is terrible (doubtful) I think this is not a thing worth discussing now
<ogra> what i really dont like is that you end up with the fedora, arch, suse base snaps being pulled in silently when installing some app snap
<ogra> (on core that is)
<zyga> ogra: we could lazily mount snaps to save memory (keep old revisions unmounted)
<zyga> ogra: it's just like docker really, but more integrated and better
<ogra> zyga, you will still have multiple libs and envs in ram
<zyga> ogra: we can put confirmations in place but it doens't change that users are in control
<ogra> core should simply be restricted by default to only use ubuntu base snaps (16 and 18 if you feel thats needed)
<ogra> but using foreign bases should be a switch rthat is disabled by default
<ogra> we have very limited resources on core
<ogra> and that implementationm is very wasteful
<ogra> (and did you wonder why people dont run their whole OS in docker n raspberry pi's ? :) )
<mvo> a second review for https://github.com/snapcore/core/pull/48 would be great
<mup> PR core#48: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <https://github.com/snapcore/core/pull/48>
<zyga> mvo: some comments there
<mvo> zyga: ta
<zyga> mvo: don't mind the -1, just a voice of concern for the hook
<zyga> mvo: do you think we could write it in go instead?
<zyga> mvo: you know (remember) better the discussion around that AFAIR
<mvo> zyga: well, I wrote it in python but that got shoot down, I can give it another go in go. it just a bit of work
<mvo> zyga: and yeah, no disagreement that sh sucks for this kind of things
<zyga> mvo: what was the reason for the python _1?
<zyga> oho
<mvo> zyga: there is a forum discussion
<mvo> zyga: that has the discussion
<zyga> look at this
<zyga> https://travis-ci.org/snapcore/snapd/builds/240716712?utm_source=github_status&utm_medium=notification
<zyga> https://paste.gnome.org/pvdpi4vbu
<zyga> some crazy linode stuff is going on there
<zyga> fgimenez: ^^ did you ever see a failure like that?
<morphis_> zyga: happy to merge https://github.com/snapcore/snapd/pull/3406?
<mup> PR snapd#3406: tests,packaging: add package build support for openSUSE <Created by morphis> <https://github.com/snapcore/snapd/pull/3406>
<fgimenez> zyga: nope, seems that the linode api stopped working for a while and started returning html instead of json, anyway "Our development team has been alerted to this error.  If you continue to have problems please contact support <a href="mailto:support@linode.com">support@linode.com</a>"
<zyga> morphis_: we need a 2nd review but yes
<morphis_> mvo: you have time for second review on #3406? or fgimenez?
<mup> PR snapd#3438 closed: daemon: make snapd a "Type=notify" daemon and notify when startup is done <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3438>
<morphis_> Pharaoh_Atem: can you have a look at https://github.com/snapcore/snapd/pull/3398 ?
<mup> PR snapd#3398: env: set XDG_DATA_DIRS for wayland et.al <Created by sergiusens> <https://github.com/snapcore/snapd/pull/3398>
<morphis_> Pharaoh_Atem: is there some better place in Fedora to do this kind of thing?
<zyga_> morphis_: there's a new systemd thing
<morphis_> zyga_: you have a link?
<zyga_> yes, one sec
<morphis_> new as in too old for 14.04?
<morphis_> 16.04 I mean
<zyga_> morphis_: starting with systemd 233 you can use /run/environment.d/ http://in.waw.pl/~zbyszek/blog/environmentd.html
<morphis_> interesting
<zyga_> cachio_: some comments on 3409
<zyga_> mvo: I +1 3317, if you can get a 2nd review (perferrably from niemeyer as it affects snap.yaml syntax) I'd love to have it
<zyga_> mvo: I also wonder about the tech review board
<zyga_> mvo: we should get an approval from them from snap format changes, right?
<zyga_> mvo: but I wouldn't like to block R&D on that
<zyga_> mvo: perhaps we can create a branch (say base-snaps) where we land things in anticipation of the sprint
<zyga_> mvo: where we can prepare and brew enough of this to run a base snap for real
<zyga_> mvo: and get the experience and measurements we need
<mvo> zyga_: good point, we need approval from niemeyer at least
<zyga_> ok, since nothing can land because of reexec mystery I'll look at that instead of anything else now
 * ogra glares ...
<ogra> ogra@anubis:~/datengrab/hikey-lemaker$ ls /mnt/
<ogra> dtbs  hikey-kernel_0.snap  install.yaml  snappy-system.txt  uboot.env
<ogra> wow
<ogra> so thats an all-snap image ... but using an install.yaml for ubuntu-device-flash
<ogra> kind of a hybrid between actual all-snap and old a/b partition setup
<ogra> (and uboot.env is full of snappy_* variables ... this will explode really badly on first upgarde i guess)
<ogra> (if it would even upgrade at all ... it installs ubuntu-core 111 )
<zyga_> pstolowski: hey, I added some comments to 3340
<fgimenez> zyga_: i'm getting this error on 14.04 with the 2.26.4 deb installed http://paste.ubuntu.com/24807633/ (executing the tests from the release/2.26 branch) could you please take a look?
<zyga_> sure
<zyga_> looking
<zyga_> fgimenez: which kernel are you on?
<fgimenez> zyga_: aah let me check, probably an old one, the new kernel debs should be in place but the reboot didn't happen
<cachio_> zyga_, nice
<pstolowski> zyga, thanks, looking
<cachio_> zyga_, the 3433 is ready if you have a minute
<zyga_> cachio_: sure, I'm doing PRs anyway (while chasing the re-exec bug)
<fgimenez> zyga_: indeed, it had installed 4.4.0-79 but was still using 3.13.0-119 http://paste.ubuntu.com/24807695/ trying now with a reboot after the upgrade, thanks!
<zyga_> fgimenez: my pleasure, I may add a feature to snap-confine to bail out with a nicer message
<zyga_> cachio_: +1
<cachio_> zyga_, awesome
<zyga_> cachio_: did you trace that as a possible cause of the re-exec issue?
<mup> PR snapd#3433 closed: tests: restoring the /etc/environment and service units config for each test <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3433>
<fgimenez> zyga_: sounds good, btw snapd#3391 takes care of the reboot during the sru validation for 14.04, a review would be great
<mup> PR snapd#3391: tests: reboot after upgrading to snapd on the -proposed pocket <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3391>
<zyga_> fgimenez: sure
<cachio_> zyga_, I could not reproduce it, and I added some debugs to get information but I didn't get much more
<zyga_> cachio_: it hapepns many times a day
<zyga_> cachio_: but yes, reproducing it is hard sometimes
<zyga_> fgimenez: done
<cachio_> zyga_, could you reproduce it?
<zyga_> cachio_: I'm still trying, I have some tools to help me find the possible cause
<cachio_> zyga_, I would like to see if after this change in the environemnt variables the bug is being reproduced
<zyga_> allocation failed on all instances on https://travis-ci.org/snapcore/snapd/builds/240716184?utm_source=github_status&utm_medium=notification
<zyga_> cachio_: indeed, I want to see new test runs
<fgimenez> zyga_: thx!
<cachio_> niemeyer, I'll be 3 minutes late
<niemeyer> cachio_: Thanks for the note
<niemeyer> Chipaca, pstolowski: Stand up?
<Chipaca> oops
<Chipaca> omw
<mvo> jdstrand: did you had a chance to look (high level) on https://github.com/snapcore/snapd/pull/3431 yet?
<mup> PR snapd#3431: interfaces: simplify snap-confine by just loading pre-generated bpf code <Created by mvo5> <https://github.com/snapcore/snapd/pull/3431>
<Chipaca> pedronis: before I forget again, could you revisit snapd#3420 ?
<mup> PR snapd#3420: many: slight improvement of some snap error messaging <Created by chipaca> <https://github.com/snapcore/snapd/pull/3420>
<cachio_> zyga_, https://travis-ci.org/snapcore/snapd/builds/240775990#L4193
 * Chipaca ~> reboot because busted snap-confine
 * zyga_ runs for lunch
<pedronis> Chipaca: are you sure tr.Get returns ErrNoState ?
<fgimenez> niemeyer: could you please give another shot at snapd#3391 ? sru tests were failing on 14.04 because of the issue this PR fixes
<mup> PR snapd#3391: tests: reboot after upgrading to snapd on the -proposed pocket <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3391>
<zyga_> Chipaca: what happened?
<Chipaca> zyga_: same as the other day?
<Chipaca> but this time it won't go away
<fgimenez> niemeyer: your input on snapd#3445 would be great too
<mup> PR snapd#3445: tests: add linode-sru backend <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3445>
<zyga_> Chipaca: what was it?
<jdstrand> mvo: I haven't yet, but I finished the thing that was in front of it so plan to get to it today
<niemeyer> fgimenez: Ack, will look, thanks
<jdstrand> well, finished is strong. I'm blocked, but that is neither here nor there for you request
<jdstrand> your*
<fgimenez> niemeyer: thx!
<Chipaca> zyga_: http://pastebin.ubuntu.com/24808074/
<zyga_> Chipaca: unmount /run/snapd/ns/core.mnt
<zyga_> Chipaca: I think that should cure it
 * zyga_ runs to eat for real
<Chipaca> zyga_: when you get back from eating for real, why is it getting confused by that?
<Chipaca> I mean, it created that mountpoint in the first place
<Chipaca> zyga_: and no that has not fixed it
<jdstrand> mvo: there was talk of a meeting with me to discuss race-free profile loads. I see https://github.com/snapcore/snapd/pull/3442 but it falls back to old profiles (thus not addressing my concern). did a meeting happen without me? is something else being done?
<mup> PR snapd#3442: snap: ensure security polices are re-created <Created by mvo5> <https://github.com/snapcore/snapd/pull/3442>
<Chipaca> although the error is slightly different
<pedronis> Chipaca: I don't see tr.Get producing ErrNoState, can you check if we have a test for doing conf get on a missing snap
<Chipaca> pedronis: ack
<Chipaca> zyga_: http://pastebin.ubuntu.com/24808102/
<pedronis> Chipaca: and sorry, anyway what I spotted was the other one
<morphis_> mvo: do you have an idea about what could be wrong in https://paste.ubuntu.com/24808137/ ?
<morphis_> mvo: snapd seems to be terminated at the end
<morphis_> wondering if this is related to re-execution
<morphis_> zyga: ^^
<mvo> morphis_: definitely strange, systemctl shows its up in the log, re-exec appears to be disabled (as it should)
<morphis_> mvo: yes, wondering what happens here and what causes snapd to terminate
<mvo> jdstrand: no worries, the seccomp PR is just one step, there is one more https://github.com/snapcore/snapd/pull/3442
<mup> PR snapd#3442: snap: ensure security polices are re-created <Created by mvo5> <https://github.com/snapcore/snapd/pull/3442>
<morphis_> mvo: just running the test again, to do a few more checks
<mvo> morphis_: are you in the system? or is that just output from e.g. linode?
<mvo> morphis_: if you can run with -debug that might be helpful
<morphis_> it's from linode, yes
<mvo> jdstrand: but gustavo was keen to do some more changes there I think, I was mostly asking about seccomp to see if there are concerns from a security POV
<morphis_> mvo: have a shell again in a few min
<jdstrand> mvo: I realize seccomp 3431 was the first step. I saw 3441 and wasn't sure if it was the 2nd or final step. if final, again, it doesn't address my concerns. note I commented in 3441
<jdstrand> mvo: thanks for the update. I'm not terribly sure we are in alignment as the meeting never happened... I guess I'll just try to keep an eye on things
<mvo> jdstrand: aha, thank you. so its just about the timeout (your concern). thta should be straightforward to fix
<jdstrand> mvo: for that PR, there is a concern about the timeout, yes
<jdstrand> mvo: but I don't know what a reasonable value is there
<jdstrand> mvo: to me, if you do that pr and instead of falling back to old profiles, trigger the regeneration for that snap, then that would address all of my concerns (I realize there is a lock contention there, but that is surmountable)
<iliv> are amd64 and armhf the only architecutre currently supported by build.snapcraft.io?
<mvo> jdstrand: I see, thank you. so intead of the current PRs wait-for-all-profiles approach it would be snap run would trigger *just the current* profile? which would be a no-op if its current. and if snapd is not up snap run would still continue (to avoid it being in the criticial path)?
<mvo> jdstrand: did I understand this correctly?
<mvo> jdstrand: maybe its better to continue in the forum, let me write up something there
<ogra> iliv, afaik yes ... you can mirror your branch to launchpad (with a regular scheduled auto-sync) to have the more exotic arches
<iliv> also, there appears to be a problem with snap package installation example. once a package was built the page showed me this: "To test this snap on your PC or cloud instance: sudo snap install --edge iliv-test-0". Running this command results in "error: cannot install "iliv-test-0": snap not found".
<jdstrand> mvo: yes. if snap run can call out to something that is able to regenerate the profiles without snapd, then yes-- snapd is out of the critical path, the normal case is snapd loaded everything and the lose the race case is handled
<iliv> however, when I clicked on the green text link "Built and published", it took me to a page where the same command example was a little different: "sudo snap install --edge iliv-test-0 --revision=1". this works.
<jdstrand> mvo: I am *not* saying that is required for 3441. I am saying that if 3441 did that, all concerns would be addressed. if it is in a future PR, I'd like that PR to be sooner than later so the concerns are addressed
<mvo> jdstrand: this out-of-snapd profile handling is slightly tricky currently, we store a bunch of important information about this in the state.json and we do not support concurrent access to this currently
<jdstrand> right-- I knew there was locking contention so certainly not blocking on that
<mvo> jdstrand: thanks in update the forum now and then scratch my head a bit more over this
<zyga_> mvo: I was thinking about it
<zyga_> mvo: and perhaps we are OK
<mvo> jdstrand: one more - the systemctl check could also be done inside snap-confine, the upside would be that it works reliable on 14.04 then, the downside that systemctl would be something we allow in the snap-confine apparmor profile. how do you feel about that?
<zyga_> mvo: the state is rewritten atomically
<zyga_> mvo: so a open fd + flock (shared) is sufficient to know that snapd is done updating and you see an atomic snapshot
<zyga_> mvo: in fact, even just fd
<mvo> interessting
<zyga_> mvo: right? no flock needed
<jdstrand> mvo: I don't feel great about that since snap-confine is setuid root. that means that if there is a problem with snap-confine, the user could potentially be able to access systemctl as root
<zyga_> mvo: snapd is the only writer
<zyga_> mvo: snapd does the rename
<zyga_> mvo: any reader can open state.json to see the snapshot
<mvo> jdstrand: yeah, I have the same feeling, so lets go with the snap run approach
 * zyga_ really goes to eat lunch
<zyga_> but I'll be back :)
<ogra> hehg, you had lunch at least two times already :P
<zyga_> except I didn't go :/
<zyga_> I was working
<ogra> yeah
<ogra> go!
<cachio_> mvo, I see the postrm test is deleting /var/lib/snapd and it is making fail the restore
<jdstrand> mvo: and to be crystal clear-- I really don't care about the implementation details of the profile loading so long as it is race free (not talking about systemctl here, but the forum topic where Gustavo and I never seemed to sync)
<cachio_> so the test postrm-purge is failing
<jdstrand> mvo: so when I'm suggesting something on that topic, it is more ideas of what could be done rather than proposals of what should be done
<niemeyer> jdstrand: I think you're downplaying it a bit, in the sense that "race free" is obviously a strict requirement of anything we do
<mvo> jdstrand: ok
<cachio_> mvo, /var/lib/snapd
<cachio_> https://travis-ci.org/snapcore/snapd/builds/240775990#L4193
<jdstrand> niemeyer: it depends on what we are talking about as racing
<jdstrand> niemeyer: profile loading at all vs profile loads that match the running snapd/snap-confine
<niemeyer> jdstrand: What I said above is true for any accepted meaning of "race" in software development
<cachio_> mvo, did it change last days? I did not see this error before
<jdstrand> niemeyer: ok, well then if we all agree that 'profile loads that match the running snapd/snap-confine' is what we want to get to, fantastic! it wasn't clear to me based on submitted PRs that was the case
<cachio_> mvo, and it is cause because of the cleanup that I did
<mvo> cachio_: I don't think so, I'm curious what it is deleting that causes the problem
<niemeyer> jdstrand: That's the key.. this is not just a race :)
<niemeyer> jdstrand: But yes, that's the goal, and it's not solely about snap-confine or snapd either
<niemeyer> jdstrand: The kernel also plays a role
<jdstrand> sure
<niemeyer> jdstrand: and the kernel is outside the control of anything internal to the system
<niemeyer> jdstrand: The user can pick a different kernel to load behind the back of snapd
<jdstrand> yep
<niemeyer> jdstrand: Which makes the whole problem more delicate
<jdstrand> sure
<niemeyer> jdstrand: So, we'll need to introduce profile generation at boot because of that, at least in specific circumstances
<cachio_> mvo, well it is doing "rm -rf /var/lib/snapd"
<jdstrand> niemeyer: and that is what I was saying about alignment-- I understand all that. I was saying we are aligned on the *goals* for where we want to be
<jdstrand> even if we don't yet know the implementation
<niemeyer> jdstrand: No, at least in that topic you did not understand
<niemeyer> jdstrand: You specifically said we could generate the profile ahead of time in all cases
<jdstrand> I was not considering the kernel the whole time, no, but when you mentioned it, I figured that is something that could be part of the whole thing
<niemeyer> jdstrand: That's why the topic never ended in agreeement
<jdstrand> fair enough
<mvo> cachio_: I know its doing that :) snapd should be able to re-generate all files/dirs in there if any is missing, this is why I wonder why it is chocking
<cachio_> mvo, ah, ok
<jdstrand> niemeyer, mvo: not sure why it took so long to sync on the goals this time around (sorry for my part in that), but I'm happy that we agree on the end goal. for my part in reviews, I'll keep that in mind
<niemeyer> jdstrand: No problem, we should just have hopped into a hangout..
<jdstrand> niemeyer: yeah, it was funny cause it felt like we were getting close, then we darted away, then got close again, etc :)
<jdstrand> still, that email thread did at least solidify what the goals are for everyone (even if it wasn't the most efficient means to get there)
<mvo> jdstrand, niemeyer: thanks. I updated the forum with the approach for 3442 and the snap-geneate-profiles ideas we have so far
<Chipaca> jdstrand: what needs happening for services that are type=notify to be able to do their notifyish thing? (currently getting a DENIED because of trying to sendmsg to /run/systemd/notify)
<Chipaca> jdstrand: (is this on your radar at all)
<jdstrand> Chipaca: it is not. if you point me at a PR/bug, I can take a look
<jdstrand> Chipaca: I need to step away for a little bit (and then have a meeting), but can look after
<Chipaca> ok
<Chipaca> jdstrand: I'll probably not get around to doing the paperwork until tomorrow, fwiw
<Chipaca> it's not a new breakage
<niemeyer> mvo: Thanks for the update
<mvo> niemeyer: I can make this branch much smarter my main question now is if we want it at all or if we should jump straight for the profile-regenerate helper
<niemeyer> mvo: I'll add some notes in the forum
<mvo> ta
<mvo> cachio_: would be nice to get the systemctl status snapd.service output when this error happens
<cachio_> mvo, sure, I'll add it
<ogra> mvo, is snapd actually re-creating the dir ? sems it comes in the deb with a lot of content actually
<ogra> *seems
<ogra> at least according to dpkg -L snapd
<niemeyer> mvo: Sent
<morphis_> mvo, fgimenez: can one of you do a second review on https://github.com/snapcore/snapd/pull/3406/ ?
<mup> PR snapd#3406: tests,packaging: add package build support for openSUSE <Created by morphis> <https://github.com/snapcore/snapd/pull/3406>
<fgimenez> morphis_: sure on it
<morphis_> fgimenez: awesome!
<cachio_> going to lunch
<mvo> niemeyer: thank you, I will ponder over this
<niemeyer> mvo: np, and thanks!
<zyga_> re
 * zyga_ reads backlog
<mvo_> niemeyer: I replied, if it sounds sensible I can start hacking on it.
<zyga_> cachio_: hey, did you see postrm-purge failures?
<stgraber> kyrofa: around?
<zyga_> morphis_: one conflict on https://github.com/snapcore/snapd/pull/3406
<mup> PR snapd#3406: tests,packaging: add package build support for openSUSE <Created by morphis> <https://github.com/snapcore/snapd/pull/3406>
<ogra> stgraber, you got a sabrelite, right ? did you ever use it with HDMI attached with a recent 4.x kernel ?
<stgraber> kyrofa: snapcraft is failing autopkgtest and is blocking LXD from being pushed to the release pocket
<stgraber> kyrofa: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/s/snapcraft/20170608_070900_635cb@/log.gz
<stgraber> kristbaum: AFAICT that's not LXD related so I'm about to push an archive hint to work around this
<stgraber> ogra: I've got a wandboard (imx6 quadcore), but I use it as the LXC/LXD armhf buildd so it's never seen an hdmi display :)
<ogra> yeah, thought so :)
<niemeyer> mvo_: Thanks, I'll step out for lunch and ponder meanwhile
<morphis_> zyga_: can you merge https://github.com/snapcore/snapd/pull/3406/ now that we have two approvals?
<mup> PR snapd#3406: tests,packaging: add package build support for openSUSE <Created by morphis> <https://github.com/snapcore/snapd/pull/3406>
<zyga_> morphis_: looking
<zyga_> morphis_: it has a conflict
<morphis_> narf
<mup> PR snapcraft#1359 opened: tests: replace grub-doc with haskell-doc in build-packages tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1359>
<kyrofa> stgraber, sorry for the delay, I am now
<kyrofa> stgraber, we're on it
<cachio_> zyga, yes I saw that
<cachio_> zyga, we were discussing that with mvo
<zyga> cachio_: aha, is this solved in master? should I merge and try again?
<cachio_> I am adding sthe snapd.service status
<cachio_> zyga, https://travis-ci.org/snapcore/snapd/builds/240775990#L4193
<cachio_> this is the error
<cachio_> zyga, not sure why snapd is not creating this directory
<zyga_> cachio_: is this issue solved now, can I help somehow?
<pedronis> Chipaca: what the's plan about my comment on your PR ? revert that bit? add a test?Â change the logic to do snapstate.Get first?
<cachio_> zyga_, it is not
<zyga_> ok
<cachio_> zyga_, I am making working on this one
<cachio_> zyga_, I'll ping you as soon as I have any info
<Chipaca> pedronis: does it make sense for config to return a different error if trying to get something for which there is no snap?
<Tribaal> Chipaca: so in relation to my article - can I ask you for a snappy question?
<Tribaal> Chipaca: what is the best solution to put a simple file in /usr/share/backgrounds/ ?
<Tribaal> Chipaca: right now I have something that's working -ish but it's a bit ugly in that it has classic confinement
<Chipaca> Tribaal: right now, you don't
<Tribaal> that's not going to be a great article then :)
<pedronis> Chipaca: maybe, anyway that chaneg is also not backward compatible
<pedronis> sorry maybe not
<pedronis> Chipaca: maybe reverting that bit is the easiest until we have a reason to do something else
<zyga_> Tribaal: hey
<zyga_> Tribaal: I have code for that but it's not finished
<pedronis> Chipaca: if you want to distinguish BadRequest vs InternalError there's, config.IsNoOption I think
<pedronis> or something like that
<zyga_> Tribaal: I discussed this with jdstrand earlier, it will be a new interface and a new security backend
<cachio_> zyga_, this is the info I get  when I run the status https://paste.ubuntu.com/24809011/
<Tribaal> zyga_: ah, that was my next attempt at code - writing a new interface
<zyga_> Tribaal: given that I'm busy on other things and there's an upcoming sprint I suspect the code for making this work will be mid july
<zyga_> Tribaal: it's not just a new interface
<Chipaca> pedronis: right, IsNoOption is returned if the snap doesn't exist, or if it exists and isn't configurable, or if it exists, is configurable, and has no config set for that key
<Tribaal> zyga_: was the interface you had in mind *just* for backgrounds, or did you think of a wider permission?
<zyga_> Tribaal: unless you are happy to jump into the frays of daily snapd development I'd recommend against it as it is unlikely to land
<zyga_> Tribaal: I was thinking of a wider system where snaps can provide content to the classic system
<zyga_> Tribaal: but it is not trivial, it involves several things that don't exist yet
<zyga_> cachio_: do you have more logs?
<zyga_> cachio_: what does systemd say?
 * ogra would add a "journalctl -u snapd.service"
<pedronis> Chipaca: which seems the original intention of that code, you asked for the wrong thing  (but I agree that's not the only failure mode, so check and InternalError otherwise)
<ogra> to get that output
<zyga_> Tribaal: I have some initial code for that on my fedora workstation where I'm hacking on it, my goal is to provide the generic framework and an interface designed for shipping backgrounds
<Chipaca> pedronis: fair 'nuf
<Chipaca> pedronis: i'll get to it
<Tribaal> zyga_: ok, so my end goal is to write a blog post about how to do the equivalent of another post I wrote using snaps. I'd like the comparaison to be favorable, so it's probably best for me to just wait for the way to be "clean" before I write anything
<pedronis> Chipaca: thx
<Chipaca> knee deep in other stuff right now, and close to eod
<zyga_> Tribaal: yes, I think you just need to wait, this is a new concept that snaps have traditionally not supported
<pedronis> Chipaca: fwiw I didn't see that path, just spotted the NotFound on setConf
<pedronis> which was sying snap not found
<Tribaal> zyga_: ack
<zyga_> popey: big big hug for the wethr snap!!!
<zyga_> I love everything about it
<zyga_> popey: does it support any options?
<ogra> like "--make-it-not-rain" ?
<ogra> :)
<zyga_> ogra: only with sudo :DD
<zyga_> hehe
<zyga_> godo
<ogra> :)
<cachio_> zyga_, it is getting stuck on the start
<cachio_> zyga_, https://paste.ubuntu.com/24809096/
<cachio_> this is the log that I have
<cachio_> zyga_, error: fatal: directory "/var/lib/snapd" must be present
<cachio_> https://paste.ubuntu.com/24809119/
<cachio_> mvo_, https://paste.ubuntu.com/24809119/
<cachio_> mvo_,  if I manually delete /var/lib/snapd
<cachio_> and restart snapd
<cachio_> it fails
<cachio_> mvo_, with the same error
<ogra> yeah, as i said above, that dir is usually shipped with the deb
<ogra> the postrm should instead do a rm -rf /var/lib/snapd/*
<ogra> so only content gets removed
<ogra> the dir would go away anyway if the deb is removed
<Chipaca> hah! found a bug in getSnapConf because i dared to write a test for it :-D
<cachio_> ogra, ok
<ogra> (or alternatively snapd should do a mkdir on startup if the dir doesnt exist)
<cachio_> it seems to be better
<cachio_> mvo_, zyga_ your opinion is welcome :)
<cachio_> niemeyer, your too
<mup> PR snapcraft#1360 opened: cli: stop leaking green text <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1360>
<Chipaca> pedronis: I think that should do it (let me know if I got it wrong _again_)
 * Chipaca EOD
<mup> PR snapcraft#1359 closed: tests: replace grub-doc with haskell-doc in build-packages tests <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1359>
<cachio_> niemeyer, there?
<niemeyer> cachio_: Yep
<cachio_> niemeyer, there is an issue with the snapd.postrm scrnpt
<cachio_> it is doing "rm -rf /var/lib/snapd"
<niemeyer> cachio_: Oh?
<niemeyer> cachio_: Well, that by itself is not an issue
<cachio_> and then if I do systemctl start snapd.service
<cachio_> niemeyer, we get this https://paste.ubuntu.com/24809119/
<cachio_> not sure why this test could not be reproduced before
<niemeyer> cachio_: We need some more context.. it doesn't make sense to purge the snap and then start it
<cachio_> niemeyer, make sense that, so I should fix postrm-purge test
<cachio_> because after the clean of environment variables was merged, this test started to fail
<cachio_> niemeyer, in ci
<niemeyer> cachio_: It would be good to understand what's going on there..
<niemeyer> cachio_: Why was it not failing before?
<niemeyer> cachio_: The lack of understanding in those cases generally means we're not seeing the whole picture
<cachio_> niemeyer, agree, I would take a look to the last code merge in the master before this restore was merged
<cachio_> niemeyer, something has to be changed in the master between the last rebase I did against the master and the moment it was merged
<niemeyer> cachio_: Yeah, perhaps related to the Fedora changes, which were quite spread out
<niemeyer> cachio_: Still, the outcome seems a bit surprising.. that doesn't seem related to the environment
<cachio_> niemeyer, it is not, do you have a convention for the tests about how should the the snapd state after the restore?
<cachio_> niemeyer, because I see snapd is reseted in the prepare
<cachio_> niemeyer, but some tests like the postrm-purge are leaving snapd in a bad state
<cachio_> niemeyer, no, not sure if I need to fix this test to leave snapd working, or I just move the environment variables clean up to the reset
<niemeyer> cachio_: We restore a number of things, such as the core snap and the entire snapd state via that tarball which you have probably passed by
<niemeyer> cachio_: These are the things tests don't need to care about
<cachio_> niemeyer, ok, in that case I'll move the environment variables restore to the reset where the snapd state is restored
<niemeyer> cachio_: Sounds sensible.. I even assumed that was happening as part of the tarball
<cachio_> niemeyer, in the tarball is being saved /etv/environment
<cachio_> but also I am cleaning up the systemd unit directories
<cachio_> because some tests are creating files with environment variables to be used by the systemd unit on there
<cachio_> this part is being done suring the restore of the test
<cachio_> to leave the systemd configuration as it was received
<niemeyer> Ah, nice
<cachio_> zyga_, there=
<cachio_> ?
<zyga> yes
<cachio_> about the reexec issue
<cachio_> in the prepare.sh prepare_each_classic
<cachio_> do you know why it is being created this reexec.conf file
<cachio_> ?
<cachio_> if then snapd service is not restarted?
<zyga> cachio_: let me look
<cachio_> it is wird
<cachio_> weird
<zyga> cachio_: no idea, I just had a look at it, maybe check git log or ask federico in the morning
<zyga> cachio_: I was thinking that perhaps we should revert whatever change broke master
<cachio_> zyga something changed during the last days, after I did the last rebase and before the envinroment cleanup cranch was landed
<cachio_> zyga, becasuse the tests were not failing or the branch
<cachio_> zyga, I can do a mkdir in the restore of the postrm-purge to make that test pass leaving a comment and create a bug to fix
<zyga> cachio_: let's do it
<cachio_> zyga, where should I create the issue? in the forum or in launchpad?
<zyga> cachio_: just make a PR :)
<zyga> cachio_: and let's get it fixed tomorrow as well
<zyga> cachio_: I think nothing creates /var/snap today
<zyga> cachio_: if you want to discuss this a forum topic is the best, it works way better than bug trackers
 * zyga will be back later
<cachio_> zyga_, when you have a minute, PR 3448
<cachio_> zyga_, this is to fix the error in master
<mup> PR snapd#3448 opened: tests: fix for the test postrm-purge <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3448>
<ssbash> hi
<ssbash> does anyone here have experience building python snaps for large python projects?
<Chipaca> ssbash: only a small python thing, myself
<ssbash> I'm having trouble getting my pythong packages to build as wheels
<ssbash> python-packages: [lockfile==0.12.2, lxml==3.6.4, msgpack-python==0.4.8, pexpect==4.2.1,    psutil==5.0.0, pyshark==0.3.6.1, requests==2.12.2, xmltodict==0.9.2, bottle==0.10.2, ecdsa=    =0.13, rsa==3.4.2, pyOpenSSL==16.2.0, pygtail==0.7.0, python-dateutil==2.6.0, beautifulsoup    4==4.5.1, robobrowser==0.5.3, pytest==3.0.4, pytest-cov==2.4.0]
<ssbash> this is what i have in my snapcraft.yaml file
<popey> maybe paste your yaml at http://paste.ubuntu.com/
<ssbash> http://paste.ubuntu.com/24811130/
<ssbash> thats my yaml file ^
<Chipaca> ssbash: some of those specifiers seem wrong
<Chipaca> e.g. the beautifulsoup one
<Chipaca> ssbash: see if this fares better: http://pastebin.ubuntu.com/24811186/
<Chipaca> popey: ^ cleaned it up a little
<Chipaca> ssbash: (just to be clear, I don't know if this is right, i've never used python-packages in snapcraft.yaml)
<ssbash> are you allowed to list packages like that? the documentations refers to a list https://snapcraft.io/docs/reference/plugins/python
<popey> i think it's syntactically valid
<Chipaca> ssbash: yes, both are valid yaml
<Chipaca> ssbash: when it's short, the inline one is arguably better
<popey> ssbash: it's a bit late here, I'd recommend posting to http://forum.snapcraft.io/ - you'll get more visibility there tbh
<Chipaca> ssbash: but as soon as it gets long it's unreadable
<ssbash> ah i see
<Chipaca> yeah, i'm only up because elections
<ssbash> thanks for your help, I'll see if it works now
<Chipaca> ssbash: I thought I'd try running this locally but it asks me for a bitbucket account and stuff
<Chipaca> Â¯\_(ã)_/Â¯
<ssbash> yea unfortunately i can't share the code, its a private repo
<Chipaca> no worries
<Chipaca> let me know if it works (if i'm still around)
<Chipaca> ssbash: if in doubt about yaml, I've found http://yaml-online-parser.appspot.com/ very useful
<cachio_> Chipaca, if you have 1 minute to check this https://github.com/snapcore/snapd/pull/3448
<mup> PR snapd#3448: tests: fix for the test postrm-purge <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3448>
<cachio_> this is to fix a problem in the master
<Chipaca> cachio_: I'm eagerly waiting for it to go green
<Chipaca> as the problem in master is blocking a branch of mine :-)
<Chipaca> 838/842, should be done soon
<Chipaca> and no error yet :-)
<cachio_> Chipaca, great, final version is running
<cachio_> Chipaca, Successful tasks: 842 :)
<Chipaca> cachio_: +1'ed, and a vote to merge as is
<Chipaca> cachio_: (also a diatribe on logs because typing is cheap)
<cachio_> Chipaca, awesome
<cachio_> Chipaca, so, this is going to be merged once all the tests pass?
<Chipaca> cachio_: I think it's fine to merge right now, but it's your call -- you're the one that'll be left holding the pieces if it breaks :-)
<cachio_> Chipaca, just wait until all the tests pass
<ssbash> Chipaca I was able to fix my issue, i was missing my libffi package
<Chipaca> ssbash: ah, ok
<mup> PR snapcraft#1358 closed: release changelog for 2.31 <Created by sergiusens> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1358>
#snappy 2017-06-09
<cachio_> Chipaca, all the tests passed
<Chipaca> cachio_: merge away!
<cachio_> Chipaca, I cant
<Chipaca> cachio_: oh!
<cachio_> Chipaca, tx :)
<mup> PR snapd#3448 closed: tests: fix for the test postrm-purge <Created by sergiocazzolato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3448>
<mup> PR snapd#3446 closed: errtracker: Include /etc/apparmor.d/usr.lib.snap-confine md5sum in err reports <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3446>
<mup> PR snapd#3420 closed: many: slight improvement of some snap error messaging <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3420>
<zyga> good morning
 * zyga had a terrible dream 
<morphis> morning!
<morphis> zyga, mvo: one of you can merge https://github.com/snapcore/snapd/pull/3406 now?
<mup> PR snapd#3406: tests,packaging: add package build support for openSUSE <Created by morphis> <https://github.com/snapcore/snapd/pull/3406>
<zyga> morphis: yes, just fiddling with expired github login
<morphis> :-)
<zyga> morphis: good morning, how are you?
<morphis> zyga: fine, you?
<zyga> so so, weather has deteriorated today it seems
<morphis> gets stormy again :-)
<mvo> morphis: done
<mvo> morphis: thank you for this work!
<morphis> mvo: awesome!
<mup> PR snapd#3406 closed: tests,packaging: add package build support for openSUSE <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3406>
<morphis> mvo: it's just the beginning
<morphis> https://forum.snapcraft.io/t/spread-testing-for-fedora-and-opensuse/950
 * zyga cannot login to github
<zyga> drat
<zyga> this will be a boring day if I cannot log in
<mup> PR snapd#3449 opened: tests/lib: generalize RPM build support <Created by morphis> <https://github.com/snapcore/snapd/pull/3449>
<morphis> zyga: what did you do?
<zyga> 2fa I cannot access
<zyga> well, I have backup but I cannot reach it yet
<zyga> (backup is in Poland)
<zyga> I'll try again soon
<mup> PR snapd#3450 opened: packaging/{opensuse,fedora}: allow package build with testkeys included <Created by morphis> <https://github.com/snapcore/snapd/pull/3450>
<mup> PR snapd#3451 opened: tests/main: use dir abstraction in a few more test cases <Created by morphis> <https://github.com/snapcore/snapd/pull/3451>
<zyga> oh, nice
<zyga> morphis: https://github.com/snapcore/snapd/pull/3450/files seems like a copy-paste comment
<mup> PR snapd#3450: packaging/{opensuse,fedora}: allow package build with testkeys included <Created by morphis> <https://github.com/snapcore/snapd/pull/3450>
<mup> PR snapd#3452 opened: tests/main: check for confinement in a few more interface tests <Created by morphis> <https://github.com/snapcore/snapd/pull/3452>
<morphis> zyga: :-)
<morphis> feel like a few smaller PRs are better
<morphis> keeps travis busy but the review small and focused
<zyga> +1
<mup> PR snapd#3453 opened: tests/main/manpages: install missing man package <Created by morphis> <https://github.com/snapcore/snapd/pull/3453>
<mup> PR snapd#3454 opened: spread: add fedora snap bin dir to global PATH <Created by morphis> <https://github.com/snapcore/snapd/pull/3454>
<morphis> zyga: complete list: https://forum.snapcraft.io/t/spread-testing-for-fedora-and-opensuse/950/2?u=morphis
<mup> PR snapd#3455 opened: tests/main: use pkgdb function in more test cases <Created by morphis> <https://github.com/snapcore/snapd/pull/3455>
<mup> PR snapd#3411 closed: tests/main: enable a first set of test cases for Fedora and openSUSE <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/3411>
 * zyga tries to recover hist 2fa 
<zyga> re
<zyga> ok, access regained
<abeato> ogra_, hey, wdyt about refactoring mentioned in https://github.com/snapcore/core-build/pull/13 ? Where should a file with common functions reside? scripts/?
<mup> PR core-build#13: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>
<mup> PR snapd#3442 closed: snap: ensure security polices are re-created <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3442>
<zyga> morphis: quick review on https://github.com/snapcore/snapd/pull/3452#pullrequestreview-43087627
<mup> PR snapd#3452: tests/main: check for confinement in a few more interface tests <Created by morphis> <https://github.com/snapcore/snapd/pull/3452>
<zyga> and doing others
<morphis> zyga: fixe
<popey> morphis: morning, any chance you can help out an arch user? https://www.reddit.com/r/linuxquestions/comments/6euoj8/snaps_are_not_running/
<morphis> Antergos .. what is that? :-)
<morphis> popey: ah based on Arch
<morphis> yeah the snapd package on arch is somewhat broken
<morphis> something somebody needs to look into, it's on my list which is quite full already
<popey> sorry to hear that
<zyga> morphis: I installed arch and could tweak some things but I cannot commit it
<morphis> me neither, we need Timothy for that
<morphis> tried to reach out to him again but no reply
<ogra_> abeato, scripts/ sounds fine, then source it respectively
<popey> morphis: is it possible to find someone else if we're blocked on Timothy's time?
<morphis> popey: not sure, zyga may know
<morphis> my Arch times are long over and never really looked into the snapd situation there yet
<morphis> popey: but the basic problem is that he is the maintainer so we need to him or an override from someone else to take the package over
<morphis> popey, zyga: maybe we should start reporting bugs against that package
<morphis> https://bugs.archlinux.org/index.php?string=snapd
<zyga> popey: I think any trusted packager can update it
<zyga> morphis: we might just file a bug with "packaging enhancements"
<zyga> (and a diff attached)
<morphis> zyga: yeah
<mup> PR snapd#3456 opened: many: add interfaces.SystemKey() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/3456>
<popey> zyga: morphis yeah, i think we need some way to move forward on arch. We keep pimping snaps and see people complaining that they don't work on arch, which doesn't look good.
<morphis> popey: +1
<morphis> zyga: so can you update hte package and file a bug?
<mup> PR snapd#3457 opened: tests: add refresh --time output check <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3457>
<mup> PR snapd#3383 closed: tests: fix spread flaky tests linode <Created by sergiocazzolato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3383>
<morphis> travis hates me again ..
<mup> PR snapd#3458 opened: tests: check that locale-control is not present on core <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3458>
<zyga_> exit
<zyga> popey: I'll see what I can do about the package
<mup> PR snapd#3459 opened: tests: add whoami check <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3459>
<zyga> hey fgimenez, I just had a look at https://github.com/snapcore/snapd/pull/3459/files
<mup> PR snapd#3459: tests: add whoami check <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3459>
<zyga> fgimenez: could you please change that to more "regular" shell [ ] && [ ] syntax
<fgimenez> hey zyga sure, np, i blindly c&p it from tests/main/login
<zyga> fgimenez: thank you, I don't mind bashisms that much but I prefer to use them only when there's no equivalent shell feature and it is justified
<fgimenez> zyga: agreed, i'll update login too
<zyga> Thanks!
<fgimenez> thank you zyga, pushed
<zyga> oh master why do you hate my PRs
<zyga> did you hear the latest joke?
<zyga> I pushed a PR and tests passed on the first go
<zyga> fgimenez: you can use `-n` instad of `! -z`
<fgimenez> zyga: sure! let me fix it
<zyga> fgimenez: or just "$a" != ""
<zyga> whatever you like :)
<zyga> ok, while waiting for spread I'll look at refreshing the arch package a little
<popey> zyga: thanks
<fgimenez> zyga: just [ "$a" ] is enough, right?
<zyga> fgimenez: I don't think it is
<zyga> or maybe it is
<zyga> but feels more murky
<zyga> STRING is equivalent to -n STRING
<fgimenez> zyga: ok, i'll go for the -n then, thx
<zyga> my comment was motivated by doing simple and obvious things (hence the suggestion for -n over ! -n or for using != "" explicitly)
<mup> PR snapd#3460 opened: ifacestate: only re-generate all security profiles if the system-key changes <Created by mvo5> <https://github.com/snapcore/snapd/pull/3460>
<zyga> mvo: reviewed
<zyga> mvo: I only feel strongly about the need to refresh other security backends (we do only two today)
<zyga> mvo: and the need to treat "unknown" as special
<zyga> Thank you for fighting this!
<abeato> mvo, ogra, https://github.com/snapcore/core-build/pull/13 re-pushed
<mup> PR core-build#13: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>
<ogra> ondra, hey ... trying your avahi snap on ym arm boards i get "/snap/avahi/44/meta/hooks/configure: line 48: /bin/nc: Permission denied" ... you probably want to ship nc as stage-packages and adjust the path in the script to use the in-snap one
<zyga> popey: do you know where the git source of snapd packaging for arch is?
<zyga> I cannot find this anyomre
<mvo> abeato: thank you , I have a look
<mvo> zyga: thank you too!
<abeato> mvo, cool, thanks
<fgimenez> zyga: sure, thanks for pointing that out! already pushed
<zyga> fgimenez: thank you!
<popey> zyga: no idea, sorry
<zyga> I think I have it in my browser history, I was looking at it yesterday
 * zyga looks
<mvo> abeato: the PR looks much better, thanks a bunch for the refactor! once the points from zyga are addressed I think it can go in
<abeato> mvo, nice!
<ondra> ogra yeah, that part is harmless, I'm having more changes in pipeline for avahi
<ogra> ondra, well, it makes it fail to start
<mvo> zyga: if you want unknown to be different every time, it might be easiest to make it "unknown (random-XXXXXX)"
<mvo> zyga: then nothing in the higher layers needs to care
<ondra> ogra that call there was just to  lift up device name from model, so it can add it to service description, so once can search for core devices and see actual device model name
<zyga> mvo: or just return nil, when it is nil we should regenerate
<zyga> mvo: this feels even easier than deserialization
<ondra> ogra hmm, let me quickly remove it
<mvo> zyga: yeah, that works too
<ogra> ondra, it should really not do that
<ondra> ogra should not do what?
<ogra> ondra, i'm working on a hostnamectrl option for the core snap so that the hostname can be set by that ... so you should actually query the real hostname not something from the model
<ondra> ogra BTW I'm preparing avahi-control interface, so once can configure avahi over that
<ogra> (and even without the core option i dont have a single board in my house where i didnt use "sudo hostnamectl set-hoostname ..." as the first thing after initial setup to tell the boards apart
<ogra> )
<ogra> (and i assume other people do that too)
<ondra> ogra problem with host name is that that is same on all fresh images
<ondra> ogra model will at least give you what type of device it is
<ogra> ondra, yes, but you hardcode it ... if the hostname isnt localhost it should not use the model then
<ogra> (in my network with three pi3 boards always online it would already explode badly)
<ondra> ogra well this one is on configure hook anyway, so it will track hostname changes
<ogra> ok
<ondra> ogra no t won't explode
<ondra> ogra this is only addition string on service
<ogra> well, it will pick random boards for pi3.local
<ondra> ogra so you can have 100 devices with same additional string
<ondra> ogra no, it will set set pi3 there
<ogra> on all three boards
<ondra> ogra it only attaches tag to ssh service with device name
<morphis> zyga: any idea about https://paste.ubuntu.com/24814501/ ? this isn't about seccomp, there are no denials
<ogra> ondra, oh, so it isnt actual avahi ?
<ondra> ogra it's not using it for hostname
<ogra> is that why i dont see a daemon ?
<morphis> zyga: hm wait, I broke something
<ondra> ogra it is in avahi, but it's not using that string( device name) for avahi host name
<ogra> ah
<zyga> morphis: dmesg | grep 1326
<ondra> ogra ssh service already has text tag so you can identify all ubuntu core devices
<ondra> ogra well all avahi instances running from snap
<ogra> yeah, but that doesnt  help if the actual mdns daemon isnt running
<ondra> ogra if it's failing that is bug
<ondra> ogra that tag is used by snappy-discover
<ogra> ah
<morphis> zyga: what is 1326?
<ondra> ogra which will list you all devices on your network which run avahi as snap
<ogra> right ...
<ondra> ogra and in that list, idea was not to just have it as snappy device, but at least also see what model it is
<zyga> AUDIT_SECCOMP
<ogra> so looking at the snap i see an command-avahi-daemon.wrapper ... but systemctl doesnt show it
<ondra> ogra so it will show you 5 snappy device, where 3 will have pi3 tag
<ogra> seems there is actually a bug then
<ogra> ogra@sabrelite:~$ systemctl |grep avahi|grep service
<ogra> ogra@sabrelite:~$
 * zyga breaks for quick breakfast
<ondra> ogra just did clean install in amd64 core and avahi runing
<ogra> well, not on armhf
<ondra> ogra will test arm
<ogra> ogra@sabrelite:~$ ps ax|grep avahi
<ogra>  3848 pts/0    S+     0:00 grep --color=auto avahi
<ogra> ogra@sabrelite:~$
<ogra> ogra@sabrelite:~$ snap list avahi
<ogra> Name   Version  Rev  Developer  Notes
<ogra> avahi  0.6.32   44   ondra      -
<zyga> mvo: very unusual error https://travis-ci.org/snapcore/snapd/builds/241117099?utm_source=github_status&utm_medium=notification
<ondra> ogra is there any safe way to lift model or gadget name?
<zyga> snap confine did not refuse to run
<ogra> ondra, only if your hok could call "snap" which we deny i think
<zyga> isn't this in some way related to us generating the profile for snap-confine now?
<zyga> (from core0
<zyga> may be a race
<ogra> zyga, wow, that was really a quick breakfast ... only 2min
<ogra> :P
<mvo> zyga: indeed, *sigh*
<ondra> ogra hmm clean install on cm3 and works
<ogra> " Failed to open file '/var/snap/avahi/common/etc/avahi/avahi-daemon.conf': No such file or directory"
<ogra> (from sudo journalctl -u snap.avahi.avahi-daemon)
<ondra> ogra I get /snap/avahi/44/meta/hooks/configure: line 48: /bin/nc: Permission denied but it continues, installs and runs
<ogra> doesnt here
<NicolinoCuralli> hi guys: is the snap-id for core 99T7MUlRhtI3U0QFgl5mXXESAiSwt776?
<ogra> 99T7MUlRhtI3U0QFgl5mXXESAiSwt776
<ogra> yep
<ogra> btw .... "snap info core" shoudl show it
<NicolinoCuralli> only on edge
<ogra> ah, indeed
<NicolinoCuralli> i need a confirm
<mvo> yes, only on edge
<mvo> I mean only there it is visible currently
<ogra> well. snap-id is the same in all channels :)
<ogra> so yes, the one above is fine
<ogra> ondra, wow ... so uninstall and reinstall of the snap works ... sems there is some kind of race
<ondra> ogra damn too late
<ondra> ogra wanted to ask you for one log file
<ogra> ah, crap, sorry
<ondra> ogra hook at first install populates default config in writable path
<ondra> ogra which for some reason failed on your device
<ondra> ogra that call which you saw failing is on the end, so no matter what by that time default config should have been there, but it was not
<ondra> ogra no worries :)
<ogra> well, i'm re-installing often, i'll keep an eye out for oother issues like this next time
<ondra> ogra but if you see it again, then check /var/snap/avahi/common/configure-hook.log
<ogra> i assume you want the configure-hook.log ?
<ondra> ogra this should tell us what happened in configure hook
<ogra> heh ... *snap*
<ondra> ogra yeah when it fails, then grab that log
 * zyga sees a new VCS in 2017 and wonders if this is a good thing
<zyga> https://pijul.org/
<zyga> oh, darcs is back
<zyga> interesting
<zyga> maybe without haskel it will actually perform
<pstolowski> interesting indeed that people still see the need for new vcs
<zyga> well
<zyga> darcs was amazing
<zyga> it just didn't get a decent implementation
<zyga> (at the time when I tried it, darcs2 was feeling better but we moved to hg then)
<zyga> but the vcs itself is less and less interesting
<zyga> where is the tooling for it?
<zyga> still, interesting
<zyga> is there a snap? :D
<zyga> there should be one
<pstolowski> :)
<zyga> mvo: can you please have a look at https://github.com/snapcore/snapd/pull/3444
<mup> PR snapd#3444: interfaces: compose the base declaration from interfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3444>
<ogra> abeato, that boot=bootloader-script ... why do you need that ? if you have detected there is an androidboot with abootimg -i $RECOVERY and you see that snap_mode is set to try, why do you need to additionally modify the commandline ... the idea was to actually not have to invent new vars like this but be able to work with what we already have
<zyga> mvo: I feel this has 1.9 already (since jdstrand didn't give me a full approval)
<zyga> mvo: I replied to his concern (there's one more branch behind this) and if I could land it I can propose the final piece of the puzzle
<zyga> (and then fix existing interface PRs!)
<abeato> ogra, there is a difficulty here, which is that the initramfs does not know if it has been loaded from recovery or from boot partition
<abeato> ogra, the only easy way I found to know that was via kernel command line
<ogra> i'm sure we can somehow find that out
<abeato> sure, but how? :)
<ogra> doesnt the kernel hand through the boot reasoon when it is called with reboot recovery ?
<abeato> nope
<abeato> no extra args added
<ogra> well, but snap_mode knows we were rebooted into recovery
<ogra> because it is set to try
<ogra> so just match on that
<abeato> ogra, except when it is "trying", but failed...
<ogra> a) check if we are androidboot ... b) check if snap_mode is non-empty ... then you can be sure you should invoke the script to actually deal with snap_mode
<abeato> snap_mode is for detecting the install status of core/kernel, using it for other stuff is a slippery slope
<ogra> well, i dont really like to modify the cmdline twice
<ogra> especially the currently working one
<abeato> ogra, that will not work, if non-emtpy it can be that we are recovery or boot, that is unknown
<abeato> ogra, no, boot=bootloader-recovery is only in the boot partition cmdline (which is not the one that contains the booting kernel as we are always doing boot->recovery->uc16)
<ogra> worst case we could touch a file in the initrd when creating it as recovery ... that still better than changing the safe cmdline
<ogra> ah, so you hardcode it there ?
<ogra> technically that variable is set in initramfs.coonf
<abeato> yes, for the boot partition only, which is not updated anytime (remeber, it is the bootloader to all effects)
<ogra> (the BOOT variable i mean)
<ogra> whcih you can actually set dynamicall yat build time of the initrd
<abeato> yes, hardcoded in the boot partition
<ogra> so when creating the recovery initrd we can simply set the var there ... and it will default to BOOT=boot-script
<ogra> that way you dont need it at all on any cmdline
<ogra> abeato, https://github.com/snapcore/core-build/blob/master/initramfs/conf/ubuntu-core-rootfs
<ogra> we just need to replace that file dynamically when creating the recovery-initrd.img
<ogra> so recovery always has BOOT=boot-script and noon-recovery does BOOT=ubuntu-core-rootfs
<abeato> ogra, ok, it can be done that way or via kernel command line, in fact it is not very important. The only important thing is that the boot image will have this difference wiht the recovery image
<ogra> that saves the extra var and the additiopnal cmdline fiddling
<abeato> *has
<ogra> (wheer did you plan to do that btw)
<ogra> (the setting oof the cmdline i mean)
<abeato> we have build scripts for the images, they create boot.img and recovery.img, being the only difference that boot.img has cmdline with boot=bootloader-script
<ogra> well, i'D still like us to stay consistent here ... we dont set boot= anywhere in ubuntu except via the initramfs.conf file
<abeato> (remeber we switched boot with recovery, the kernel is updated in the recovey partition)
<ogra> right
<abeato> ogra, it is perfectly fine to modify the conf file instead of the kernel cmdline for boot.img in our build scripts
<ogra> the point that bothers me is that we set soimething on the cmdline :)
<abeato> if you think that is better
<abeato> so no issue here :)
<ogra> i think it is consistent with the rest of the distro
<abeato> it does not affect the PR anyway
<ogra> right
<abeato> sure, I will change that
<ogra> regarding the PR you will have too fight with zyga over his request for unittests ... i'm fine with it as is (once it has seen sopme real world tesing)
<zyga> I'll contribute some in a moment
<abeato> re: real testing, it has had quite a bit, I simulated update failures in different ways, for instance
<ogra> adding unit tests there will be some giant work i fear ... to do that right you surely want to run them in the environment they will later run
<ogra> so you want an initrd, unpack it ... and run the unittests chroooted inside that at the very least
<zyga> ogra: we will see, I don't know yet
<ogra> else you dont really test if i.e. the binaries your scripts use are there etc
<ogra> and you need to fake all the device bits ... findfs checking for labels etc
<ogra> i'm not sure that buys us much TBH ... over actual testing of a boot and shellcheck to make sure there are no typos
<daker> hi, snapcraft question: how can i tell snapcraft to put folders/files in the $SNAP_USER_DATA ?
<mvo> ogra: I think its definitely wort checking adding unit tests fwiw, I think its not something that abeato needs to do as its beyond the scope of the PR but something we should look into in the core team. I'm very happy that zyga looks at it
<ogra> daker, with a wrapper script
<mvo> worth even
<daker> ogra: any example ?
<ogra> mvo, oh, yeah, not saying they arent worth it but he asked for them in context of the PR :)
<zyga> daker: not automatically, but you can with the configure script
<ogra> mvo, and i meant what i said above, they will be useless ifwe dont run them in the right env ... which means an unpacked initrd and chrooted into that with the change applied on top ... thats a rather complex thing to set up
<zyga> daker: though it will run _after_ services started
<zyga> daker: ah, for SNAP_USER_DATA (not the USER) you need a wrapper
 * abeato happy to leave that for other PRs ;)
<daker> zyga: example :)
<ogra> daker, https://github.com/ogra1/laidout (doesnt copy anything ... a cp $SNAP/default-config $SNAP_USER_DATA/config would be needed)
<daker> ogra: thanks! i'll try it
<ogra> daker, ah, here i copy some java config in place in line 31 https://github.com/ogra1/jtiledownloader/blob/master/wrapper
<zyga> daker: wrap the real command you want to run in a helper program (script) that does the initial setpu
<daker> zyga: ogra ok
<mup> PR snapd#3461 opened: debian: add missing "make -C data/systemd clean" <Created by mvo5> <https://github.com/snapcore/snapd/pull/3461>
<mup> PR snapd#3462 opened: systemd: refactor service ops to also be exposed more directly <Created by chipaca> <https://github.com/snapcore/snapd/pull/3462>
<Chipaca> ouh
 * Chipaca smacks forehead
<mup> PR snapd#3463 opened: Snap services 2 <Created by chipaca> <https://github.com/snapcore/snapd/pull/3463>
 * Chipaca smacks github's forehead
<ogra_> is it forehead-friday ?
<Chipaca> ogra_: yes
<Chipaca> very yes, in fact
 * ogra_ slaps his forehead too in solidarity with the UK
<Chipaca> ogra_: uff... if it were for the uk shenanigans my forehead would have a berm around the edge from all the slapping
<ogra_> heh
<mup> PR snapcraft#1361 opened: pluginhandler: don't clobber path on local import failure <Created by zyga> <https://github.com/snapcore/snapcraft/pull/1361>
<ogra_> koza, hey ... http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ or http://people.canonical.com/~ogra/snappy/all-snaps/daily-stable/current/ have the hummingboard images ... we're still missing interfaces in the gadget ... https://github.com/ogra1/hummingboard-gadget/ has the gadget source
<ogra_> koza, i started working with fabo on getting proper build scripts in place in the linaro lite setup (which requires to build in docker, i'm waiting for him to get us a proper setup)
<morphis> fgimenez: do you have time to do a review on my PRs listed in https://forum.snapcraft.io/t/spread-testing-for-fedora-and-opensuse/950/2 ?
<fgimenez> morphis: sure, i'm finishing the sru verification, once that's done i'll take a look
<morphis> fgimenez: thanks!
<koza> ogra_, hey and thanks for mail; got disconnected and my ssh/irssi to linode setup reacts with a delay to such events
<ogra_> koza, no worries ... i just wanted to make sure you definitely get the answer ...
<koza> ogra_, appreciated
<ogra_> koza, note the last line in the model assertion paste is wrong (in case you want to use it to build an image yourself) i only just noticed that my server spilled a message there ...
<koza> ogra_, oh right email notification :-)
<ogra_> yeah :)
<fgimenez> morphis: btw, the suite is failing on opensuse and fedora when running against the staging store, could you please take a look? https://travis-ci.org/snapcore/spread-cron/builds/240983847
<morphis> fgimenez: interesting
<fgimenez> morphis: ok opensuse this seems to be the problem http://paste.ubuntu.com/24815216/
<fgimenez> on opensuse
<morphis> hm, I see
<morphis> maybe go is too old?
<fgimenez> morphis: no idea, also not sure if the quoting is right in that case
<morphis> hm
<niemeyer> Chipaca: Standup?
<Chipaca> niemeyer: yes!
<om26er> Hi! who is the contact to talk about https://build.snapcraft.io/ ?
<mup> PR snapd#3444 closed: interfaces: compose the base declaration from interfaces <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3444>
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/3464 :-)
<mup> PR snapd#3464: interfaces: put base policy fragments inside each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3464>
<zyga> om26er: many people, can you be more specific?
<mup> PR snapd#3464 opened: interfaces: put base policy fragments inside each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3464>
<abeato> ogra_, hey, I've created a script for better dates, see https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1696981
<mup> Bug #1696981: fixrtc is ineffective when there is no battery for the RTC <initramfs-tools (Ubuntu):New> <https://launchpad.net/bugs/1696981>
<jdstrand> zyga: ack, added to list
<zyga> jdstrand: thank you!
<ogra_> abeato, ummm ... the description is weird
<zyga> jdstrand: it's pretty tedious but should be easy to review patch by patc
<zyga> jdstrand: as those are structured sanely, I hope
<jdstrand> I haven't looked at it, but know what to expect
<jdstrand> :)
<ogra_> abeato, fixrtc is exactly only for the one usecase where no RTC battery is around ...
<ogra_> abeato, that makes your changelog entry a bit weird
<abeato> ogra_, yeah, but as discussed it does not work that well. see my comments in https://github.com/snapcore/core-build/pull/13
<mup> PR core-build#13: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>
<om26er> zyga, we need to publish our software and it build.snapcraft currently builds for 2 arches, amd64 and armhf, we need support for arm64
<om26er> so wanted to know if that will come in future
<zyga> om26er: it's available already AFAIK
<zyga> om26er: you can build a snap for aarch64 aka arm64
<ogra_> abeato, yes, i remember them ... my point is that the missing RTC isnt what makes the local-top fixrtc not work but broken mount data of the disk ...
<zyga> om26er: (via build.snapcraft.io)
<abeato> ogra_, I can change the description, tbh it is not clear to mee if the current fixrtc script really fixes the issue if there is no rtc battery
<abeato> ogra_, it does not for this device at least
<ogra_> abeato, and i would still like to find out why the original fixrtc doesnt DTRT
<ogra_> instead of just adding anothr script
<om26er> zyga, hmm, by default it built for amd64 and armhf, do we need to change something ?
<ogra_> abeato, can you capture the data from dumpefs from the initrd when in local-top at least ?
<zyga> om26er: I think that's something you can tweak on the website
<ogra_> abeato, and attach that to the bug
<zyga> om26er: not sure, but I know the builders for aarch64 are around
<om26er> zyga, ok, will look into that.
<abeato> ogra_, the explantion on why it does not work is that the mount time is always wrong, as "/" is being mounted always in a moment near to the epoch
<abeato> ogra_, but let me paste that
<ogra_> abeato, yes, and the current fixrtc script should take that into account
<ogra_> abeato, we originally developed it for android partitioning for never booted devices so it should work in any case ... if it doesnt, we should try to fix what we have, not add something new (that only as last resort)
<abeato> ogra_, we could access files by moving fixrtc to local-bottom
<ogra_> abeato, well, but that is to late
<ogra_> we need the clock set before we try to mount
<abeato> ogra_, then we need this other script
<ogra_> and there is no reason why you shouldnt get that info
<ogra_> dumppe2fs should always return *something* and we should be able to react to that
<ogra_> abeato, i think we just dont handle this special case corretly in the current script ... but to adjust we need the data
<abeato> ogra_, http://paste.ubuntu.com/24815516/
<ogra_> Last mount time:          Thu Jan  1 03:42:04 1970
<abeato> yep
<ogra_> that should be enough to do something about it
<ogra_> we know we're at the epoch
<abeato> sure, and we want something better, isn't it? ;)
<abeato> test@localhost:~$ date
<abeato> Fri Jun  9 13:44:22 UTC 2017
<abeato> that is the current time in the machine, it is not like it is in the epoch ^^
<ogra_> abeato, http://paste.ubuntu.com/24815530/ line 99 and following
<ogra_> we just need to make the if a bit broader
<ogra_> and if you feel like push the hardcoded timestamp a bit forward ...
<abeato> ogra_, 1999 is still not good enough, I want the snap assertions to be valid
<ogra_> well, push it to 2017 then
<ogra_> effectively it gains you nothing anyway ... you need to be online to initialize the device ... if you are online you will get a proper date anyway
<abeato> ogra_, that is true, but I am thinking about the factory case here, no network, and somebody adding system-user assertions with a USB stick
<ogra_> and if you are not and your image is a month old the hardcoded date will still be wrong
<abeato> getting a date from the filesystem helps there
<abeato> and it is not wrong
<ogra_> not much
 * zyga lunch
<ogra_> it will be stuck at the image creation date
<abeato> yeah, but that is in fact enough to make sure the assertions are valid, ad they are part of the image
<ogra_> so depending how old your image is it will still not have a proper date for a freshly created assertion
<ogra_> (the one on the usb stick)
<abeato> well, yes, but is an improvement (time to think now in time assertions to update time in non-connected devices ;)
<ogra_> abeato, well, your script also only uses "2017-06-09" ...
<ogra_> which is the date it will always fall back to
<ogra_> so i dont see why we cant use that in the actual fixrtc script
<abeato> ogra_, that is an initial hint, then in searches for better dates in the file system
<ogra_> i also dont like to tie it to snap packages
<ogra_> i.e. *if* you check a file (which is shuddering ugly, but if there is no other way ...) then check creation time of / on the fs or of /etc or something else generic
<abeato> well, it is not perfect, but nothing but a network connection would do things right. It is just an improvment on the current situation
<abeato> ogra_, I check "/"
<abeato> +        if [ -d "$rootfolder" ]; then
<ogra_> you check /root :)
<abeato> that is moved to "/" later in the initramfs
<ogra_> oh, ignore me :P
<ogra_> indeed
<abeato> :)
<ogra_> well, could we just limit limit that bottom script to this ?
<abeato> ogra_, ok, I can remove the snapsfolder part
<ogra_> and fix the -premount script accordingly to react to the epoch in line 91
<abeato> alright
<ogra_> and have another test in the bottom script ... if th edtae we did set in -premount is new enough just skip
<ogra_> *the date
<ogra_> i.e. if the date is as new as the creation time of /
<abeato> that is actually done with the current logic, but yeah
<ogra_> also ... if you check /root ... doesnt that actually return the creation time of the mountpoint (i.e. the initrd creation time) ?
<ogra_> perhaps you should check the stamp of /root/etc
<abeato> nope
<ogra_> ok
<ogra_> then it is fine
<abeato> cool
<abeato> will do the changes, thanks
<ogra_> thanks for doing it (and for putting up with me :) )
<abeato> :)
<abeato> ogra_, where is http://paste.ubuntu.com/24815760/ coming from? It is actually not part of the fixrtc scrip in the initramfs-tools package
<ogra_> abeato, from the one we have in the image PPA
<ogra_> the "n/a" isnt upstreamed yet
<abeato> oh, I see
<ogra_> abeato, https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
<ogra_> (yes, i' an evil lazy slacker ... should have SRUed that long ago)
<abeato> lol, we all are...
<mup> PR snapd#3465 opened: hooks: re-org of some hooks types <Created by stolowski> <https://github.com/snapcore/snapd/pull/3465>
<pstolowski> niemeyer, ^ the hooks re-org branch I talked about in the standup
<om26er> zyga, fyi, there is no UI to change which arches to build on build.snapcraft.
<ogra_> no, it always builds amd64 and armhf regardless
<om26er> would be really great we were able to distribute our package for arm64 as well as our target is embedded systems.
<ogra_> for other arches use LP
<ogra_> (or wait until build.s.io grew such a feature)
<om26er> does LP also support auto publish to store ?
<ogra_> yes
<om26er> we could probably wait a bit, if arm64 build support is planned for build.snapcraft
<ogra_> om26er, https://github.com/snapcore/pi2-gadget mirrors to -> https://code.launchpad.net/~canonical-foundations/snap-pi2/+git/github-mirror ... then builds -> https://code.launchpad.net/~canonical-foundations/+snap/pi2
<ogra_> (and that fgoes automatically into the edge channel)
<ogra_> *goes
<fgimenez> hey zyga, i'm getting this denial http://paste.ubuntu.com/24815879/ while trying to test this rule https://github.com/snapcore/snapd/blob/master/interfaces/builtin/system_observe.go#L70, any idea what might be going on?
<fgimenez> mvo: the core-revert test including bluez is about to finish (I needed to retrigger it to set up the env vars properly to do stable -> candidate -> stable) will keep you posted
<daker> popey: https://forum.snapcraft.io/t/nginx-rtmp-streaming-server-snap/961
<fgimenez> mvo: btw the sru validation is finished, should i wait for the results or mark it as verification-done now?
<mvo> fgimenez: lets wait a tiny bit for the results of bluez
<abeato> ogra_, new patch uploaded to lp: #1696981
<mup> Bug #1696981: fixrtc is ineffective when there is no battery for the RTC <initramfs-tools (Ubuntu):New> <https://launchpad.net/bugs/1696981>
<niemeyer> pstolowski: Thanks, replied there
<pstolowski> niemeyer, I saw your comment, thank you
<pstolowski> zyga, responded to your comments to 3340
<fgimenez> mvo: ok, i get the same timeout reported in the bug, these are the syslog contents http://paste.ubuntu.com/24815993/ looks like we have now "hsearch_r failed for NETLINK_KOBJECT_UEVENT: No such process"
<fgimenez> mvo: the session is open in case you want to take a look
<zyga> re
<zyga> fgimenez: looking now
<zyga> fgimenez: looks like missing dbus abstraction, looking
<fgimenez> zyga: thanks! the test snap used is in this changeset in case you want to look into it https://github.com/snapcore/snapd/compare/master...fgimenez:extend-system-observe-test-dbus-introspection?expand=1
<zyga> fgimenez: yes, looking at https://github.com/snapcore/snapd/blob/master/interfaces/builtin/system_observe.go I don't see the abstractions included
<zyga> jdstrand: ^ should there be #include <abstractions/dbus-session-strict> in system_observe.go?
 * jdstrand looks
<jdstrand> zyga, fgimenez: it is missing and should have "#include <abstractions/dbus-strict>"
<fgimenez> zyga: jdstrand, yep, system bus
<jdstrand> (that is for the system bus. not dbus-session-strict, which is for the session bus)
<fgimenez> thank jdstrand, for the sru this can't be considered a regression, right? although there was another rule already there that shouldn't work before
<fgimenez> *thanks
<jdstrand> fgimenez: no it is not a regression. even if both dbus rules were added this time it still isn't a regression, it is just an incomplete set of rules
<morphis> kyrofa: do you know if there is any way during a build with snapcraft to find out which architecture we're building for?
<fgimenez> jdstrand: cool thx! i can propose the fix together with the test and ping you for the review, is that ok?
<jdstrand> fgimenez: absolutely. thanks!
<kyrofa> morphis, depends on where "we" are: in snapcraft (e.g. a plugin)? Or the thing being built?
<morphis> kyrofa: right now I am doing a wget call into a install: statement
<morphis> s/into/in/
<kyrofa> morphis, and what happens there needs to change depending on arch?
<morphis> kyrofa: I need to download a different file per arch, let say test_amd64.img on x86 and test_armhf.img on armhf
<kyrofa> morphis, I'm afraid snapcraft doesn't export any variables relating to target arch. However, doing different things depending on arch is a feature we have on the roadmap... just not there yet
<morphis> kyrofa: ok, nice!
<kyrofa> morphis, as a workaround, you can create a local plugin for that part and then you can use the plugin API to get that information
<morphis> kyrofa: I can workaround by doing different snap builds from different branches for now
<kyrofa> That works too, but is annoying, I'm sorry
<morphis> kyrofa: hm, you have any good example for that?
<kyrofa> morphis, no, but it's easy enough I'll write one for you ;)
<kyrofa> One minute
<morphis> kyrofa: my hero :-)
 * kyrofa turns on mission impossible music
<morphis> :-D
 * zyga feels sick again
<zyga> darn food
<jdstrand> zyga: :( feel better
<zyga> jdstrand: thank you
<kyrofa> morphis, here: https://github.com/kyrofa/arch-specific-plugin
<kyrofa> morphis, that will error out because it's trying to pull a tarball from https://arch-specific, but you get the idea
<zyga> kyrofa: hey, when is the next release of snapcraft?
<morphis> kyrofa: nice, thanks!
<kyrofa> zyga, dput just happened, trying to get into proposed
<zyga> aha
<zyga> nice!
<zyga> kyrofa: can you have a quick look at https://github.com/snapcore/snapcraft/pull/1361
<mup> PR snapcraft#1361: pluginhandler: don't clobber path on local import failure <Created by zyga> <https://github.com/snapcore/snapcraft/pull/1361>
<zyga> I'm not sure why tests are failing
<zyga> and you could review it, it's tiny
<kyrofa> zyga, yeah looks good to me. Probably a store flake as usual
<kyrofa> zyga, yep. We usually have to rerun our tests at least twice
<kyrofa> I restarted them
<zyga> thanks!
<zyga> kyrofa: because of store issues?
<kyrofa> zyga, yeah
<zyga> wow
<kyrofa> It wastes literally hours a day
<zyga> what kind of store issues are you seeing?
<kyrofa> connection resets
<kyrofa> zyga, https://forum.snapcraft.io/t/101-connection-resets/775
<pstolowski> niemeyer, I've added a comment to my hooks re-org, I think this situation is more complicated than we had in configstate (but i'm happy to stand corrected)
<niemeyer> pstolowski: We have several cases of cross dependency between these packages already.. I'd be surprised to see this case being unlike all of them
<mup> PR core-build#13 closed: Androidboot support <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/13>
<zyga> niemeyer: can you have a 2nd look on https://github.com/snapcore/snapd/pull/3399 please
<mup> PR snapd#3399: many: add the interface command <Created by zyga> <https://github.com/snapcore/snapd/pull/3399>
<niemeyer> pstolowski: If it is, can we please have a proper analysis about why that's the case?
<zyga> niemeyer: I believe it is as you requested  now
<niemeyer> Yep, will look, thanks
<zyga> thank you!
 * zyga gets back to feeling sick and testing
<ogra_> kyrofa, just stop routing through norway ... then Peer can reset your connection all the time
<ogra_> *can not
<ogra_> (sorry, already in EOW mood :P )
<kyrofa> :P
<kyrofa> That darn peer
<ogra_> alsoo if you get 101 resets, just write a looop with 102 iterations :P
<ogra_> (really sorry, i should stop for the day :P )
<kyrofa> ogra_, haha, that's how I read that thread, too
<kyrofa> 101 paper cuts, 101 connection resets
<ogra_> yeah :)
<Chipaca> hmmm
<Chipaca> zyga: you there?
<zyga> yes
<zyga> what's up?
<Chipaca> zyga: snap refresh --channel edge core
<Chipaca> zyga: and then
<Chipaca> zyga: snap refresh --channel beta core
<zyga> refreshing
<zyga> oh
<Chipaca> zyga: does the "preserve namespace" nastyness i was getting
<zyga> intereting
<mup> PR snapd#3459 closed: tests: add whoami check <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3459>
<Chipaca> zyga: huzzah for reproducers!
<zyga> edge snapd
<zyga> Chipaca: thank you
<zyga> Chipaca: I think we nailed that to us following current symlink
<zyga> Chipaca: vs knowing the rev to internal tools in cmd/cmd.go
<zyga> Chipaca: just not fixed
<zyga> yes
<zyga> it's definitely that
<pstolowski> niemeyer, oh, I found a little trick we do in configstate with setting snapstate.Configure function pointer. that "solves" the dependency issue which would otherwise arise with snapstate setting up hooks
<mup> PR snapd#3466 opened: tests: extend core-revert test to cover bluez issues <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3466>
<fgimenez> mvo: i've just proposed the changes to reproduce the bluez issue snapd#3466
<mup> PR snapd#3466: tests: extend core-revert test to cover bluez issues <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3466>
<pstolowski> zyga, any chance you have another look at https://github.com/snapcore/snapd/pull/3340 ?
<mup> PR snapd#3340: many: snapctl outside hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3340>
<zyga> looking
<zyga> pstolowski: done
<zyga> pstolowski: almost there
<mvo> fgimenez: thank you! I have a look monday, slightly sad about this. but many thanks for finding a reproducer
 * mvo dinner
<zyga> fgimenez: do you have a log of what is going on when the bluez code fails?
<zyga> fgimenez: any denials or something similra?
<zyga> *similar
<fgimenez> zyga: this is syslog http://paste.ubuntu.com/24815993/ there are some denials in there but the relevant error seems to be "hsearch_r failed for NETLINK_KOBJECT_UEVENT: No such process" after the revert
<zyga> aha
<zyga> yes, that looks like another new thing related to netlink mediation
 * zyga wonders what mvo's revert plan for that will be
<zyga> fgimenez: thank you!
<fgimenez> zyga: yw :)
<pstolowski> zyga, done
<zyga> pstolowski: I noticed, reading already
<zyga> pstolowski: +1
<zyga> thank you :)
<pstolowski> zyga, thanks :)
<mup> PR snapd#3340 closed: many: snapctl outside hooks <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3340>
<niemeyer> zyga-suse: Sent a review on the interface PR.. let me know if you want to talk about it please
<zyga-suse> sure
<zyga-suse> let me de-conflict and look
<zyga-suse> niemeyer: nothing controversial, I will iterate on this quickly, maybe it can land before your EOD
<zyga-suse> niemeyer: one question, are we OK with changing the response this way without changing the URL?
<zyga-suse> niemeyer: snap /v2/interface vs /v3/interface (for instance)
<niemeyer> zyga-suse: We're not *changing* the response
<Chipaca> v3wha
<niemeyer> zyga-suse: See the note about compatibility there
<niemeyer> zyga-suse: We're not breaking any behavior for existing clients
<niemeyer> zyga-suse: That's what v3 would be about
<zyga-suse> ah, I see
<zyga-suse> hmm
<zyga-suse> niemeyer: what would be the response though? currently it is a single object
<zyga-suse> niemeyer: and in the proposal it would have to be a list
<zyga-suse> niemeyer: do you mean if some options are not given we return the legacy response
<zyga-suse> niemeyer: and if they are, we return the new response
<niemeyer> zyga-suse: That's expllcitly what is stated there I think:
<niemeyer> """
<niemeyer> We can provide "connected" via a "select" field, analogous to the one we use for snaps, and then allow specifying "select=all" so that we preserve the result as-is when "select" is not provided, preserving compatibility with existing clients (including the current Interfaces method which will now become Connections). Eventually we can obsolete that result as we'll likely kill the "interfaces" command and introduce a more
<niemeyer> polished "connections" one, per our conversations.
<niemeyer> """
<zyga-suse> I don't get it, the result, right now, is a single object that has two lists inside (plugs and slots)
<zyga-suse> how does that allow us to return information about a single non-plug, non-slot interface?
<zyga-suse> by returning a shim object with one element?
<zyga-suse> sorry if I'm asking silly things, just tired I guess
<niemeyer> zyga-suse: Can you point out what is unclear in the above statemnet?
<niemeyer> zyga-suse: it's explicitly stating how and when we change the result
<niemeyer> zyga-suse: You should probably take some good rest.. we can discuss this again on Monday
<zyga-suse> I guess I'm not familiar with the /snaps endpoint
<zyga-suse> yeah, I think you are right
<zyga-suse> I'll review the snaps API
<zyga-suse> and fight this fresh tomorrow
<niemeyer> zyga-suse: Monday!  Go take some rest :)
<zyga-suse> oh, it's Friday
<zyga-suse> man
<zyga-suse> yes :)
 * zyga-suse lost track
<ssbash> hi guys
<niemeyer> ssbash: Heya
<ssbash> I'm having trouble having my python script accessing a custom python lib. Do you guys know what I can do to fix it in my snapcraft.yaml file?
<ssbash> http://paste.ubuntu.com/24817687/
<ssbash> My guess is that it should be a stage package, but im not sure how to configure that since its a local lib.
<niemeyer> ssbash: Looks like traditional Python module path issues
<niemeyer> ssbash: You probably need to fiddle with sys.path to tell Python whre your libraries are located
<ssbash> ok ill give that a try. Thanks for your feedback.
<mup> PR snapd#3467 opened: interfaces/greengrass-support: add support for Amazon Greengrass as a snap <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3467>
<mup> PR snapcraft#1362 opened: Only install golang-go if it is not found in PATH <Created by chrisglass> <https://github.com/snapcore/snapcraft/pull/1362>
<Tribaal> hi snappies, that PR ^^ is mine - happy to discuss in here if needed
#snappy 2017-06-10
<francis[m]> what should i look at if i wanted to know more about how to convert debs to snap?
<francis[m]> https://github.com/mikix/deb2snap looks as abandoned
#snappy 2017-06-11
<mup> PR snapcraft#1363 opened: tests: use pyramid as a router for the fake servers <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1363>
#snappy 2018-06-04
<mborzecki> morning
<mborzecki> mvo: hey
<mvo> mborzecki: good morning
<mvo> mborzecki: how are things? anything important I missed last week?
<mborzecki> mvo: no, don't think so, no fires or anything
<mvo> mborzecki: great
 * mvo dives into core18 and reviews then
<mvo> mborzecki: anything exciting happened? how are parallel installs coming along, I'm quite excited about this one
<mborzecki> mvo: i've bastardized snap-confine and snap-update-ns to accept the _ in snap names, then on friday i was looking into mounting foo_bar as foo
<mborzecki> mvo: i should be opening some PRs today with some introductory changes in structs
<mvo> mborzecki: sweet!
<mvo> mborzecki: I was wondering how the internal changes will look like, was it a lot of fiddling?
<mborzecki> let me show you a patch
<mborzecki> mvo: https://paste.ubuntu.com/p/xNBgYhWcMp/ that's a work in progress version
<mvo> mborzecki: aha, nice. StoreName() is a good helper
<mvo> mborzecki: that is surprisingly short, nice
<mborzecki> mvo: tried to make it least invasive :P
<mvo> mborzecki: heh :) looks like a success to me
<mborzecki> mvo: s-c bits are a bit fiddly, the mounts, i'm trying tmpfs over $SNAP_MOUNT_DIR, oh an the store part, you can't really install foo and foo_bar right now, because the store complains that you have the same snap appearing twice in the request
 * mvo nods
<mborzecki> https://www.bloomberg.com/news/articles/2018-06-03/microsoft-is-said-to-have-agreed-to-acquire-coding-site-github wat?
<mvo> mborzecki: I heard rumors about this on the weekend
<mvo> mborzecki: definitely in the waaat catgeory
<mvo> mborzecki: source-safe-2018
<mvo> 5251 is an easy win if someone wants to review
<mborzecki> hahah, well, at leas this one  is usable :)
<mvo> mborzecki: yeah :)
<mup> PR snapd#5251 closed: tests: reprioritise a few tests that are known to be slow <Created by chipaca> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5251>
<zyga> good morning!
<mvo> zyga: hey, good morning
<zyga> hey hey, how are things
<mborzecki> zyga: hey
<zyga> so Microsoft keeps snapd source safe ;)
<mup> PR snapd#5249 closed: interfaces/home: remove redundant common interface assignment <Simple> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5249>
<zyga> I will be here shortly, need to set the little one for a school trip
<mvo> mborzecki: there is one open question by zyga in 5244 otherwise it looks good afaict
<mborzecki> mvo: just pushed a fix
<mvo> mborzecki: ta
<mup> PR snapd#5238 closed: tests: skip appstream-id test for core systems 32 bits <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5238>
<mup> PR snapd#5232 closed: interfaces/tpm: Allow access to the kernel resource manager <Created by yphus> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5232>
<mborzecki> https://www.youtube.com/watch?v=VYOXuOg9tQI haha look at the publish date
<mvo> mborzecki: hahaha
<zyga> tests are not happy :/
<zyga> unattended upgrades?  https://www.irccloud.com/pastebin/Txy5hEt3/
<mvo> zyga: possible, yes
<pstolowski> morning
<zyga> ok
 * zyga got stressed because of sudden call that the school trip rule sheet must be brought by all children
<zyga> school is so poorly organised
<zyga> I signed that paper last week
<zyga> and suddenly they tell me I need to keep it (I got a blank copy) and -bring it-, as if they couldn't find their own copy
<zyga> sigh
<zyga> but all is good now
 * zyga tries to forget about non coding stuff
<zyga> could anyone please review https://github.com/snapcore/snapd/pull/5245
<mup> PR #5245: cmd/snap-update-ns: add PathIterator <Created by zyga> <https://github.com/snapcore/snapd/pull/5245>
<mborzecki> zyga: i'll do it in a while
<zyga> thanks
<mborzecki> any clues what happened to lxd? restoring google:ubuntu-16.04-32:tests/main/lxd seems to consistently fail across a number of jobs
<mborzecki> the job hits a kill-timeout when issuing `lxd.lxc stop my-ubuntu`
<mvo> mborzecki: I saw this as well, I have not looked yet but probably worthwhile to do a local spread run with -debug
<mborzecki> Chipaca: hey, thanks for pushing the fixes for shellchecks :)
<Chipaca> mborzecki: I was very bored :-)
<mup> PR snapd#5252 opened: store, jsonutil: move store.getStructFields to jsonutil.StructFields <Created by chipaca> <https://github.com/snapcore/snapd/pull/5252>
<mborzecki> damn, that lxc issue does not reproduce when running locally :/
<Chipaca> mborzecki: the one where it doesn't stop?
<mborzecki> Chipaca: yes
<Chipaca> mborzecki: it's not 100% on spread either
<Chipaca> that is, it's racy
<mborzecki> heh, i must be super lucky then :)
<Chipaca> i've seen it sporadically since friday
<Chipaca> (while iterating on those shellcheck tests)
<Chipaca> mvo: extra bonus idea for --format=help: use tags to add brief explanation to fields
<Chipaca> mvo: I can push a tweaked helper to grab you that if we agree on a format for 'em
<Chipaca> (or, you can, it's not brain rocketry)
<pstolowski> 2018-06-04 08:29:45 Failed task restore: 1
<pstolowski>     - google:ubuntu-16.04-32:tests/main/lxd
<pstolowski> i saw that over the weekend too
<pstolowski> mborzecki: ah, it seems like what you mentoned above
<mvo> Chipaca: feel free to do that, I'm wrestling firstboot to skip looking for core
<Chipaca> mvo: aw
<Chipaca> mvo: wrestl wrestl
 * zyga -> tea
<mup> PR snapd#5253 opened: snap: introduce new fields for parallel snap installation <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5253>
<pstolowski> and now i got a failure on journal cursor in the google:ubuntu-14.04-64:tests/main/snap-confine-from-core test
<pedronis> mborzecki: hi, could you write in a forum topic how you plan to refactor things on the way to parallel installs, small PRs are good but is hard to guess the full picture.
<mborzecki> pedronis: sure
<mborzecki> pedronis: btw. https://paste.ubuntu.com/p/xNBgYhWcMp/ if you'd like a quick peek at the current changes
<mborzecki> pedronis: as you commented in the PR, SnapSetup.Name() has been updated too, just that it's not included int the patchset
<pedronis> mborzecki: there are no changes to tests there, bit hard to judge if those changes are sufficient, also the change in store is a bit strange
<pedronis> mborzecki: any place dealing with info.Name needs a new test
<pedronis> in theory not, but in practice it sort of does
<mborzecki> pedronis: hmm i think i'm more afraid of the places that poke the struct directly rather than calling its methods, iirc there was one place where SuggestedName was accessed this way (store?)
<pedronis> mborzecki: wrappers I think
<zyga> pstolowski: I think the journal change is racy and it somehow doesn't always work
<pedronis> mborzecki: anyway new tests in managers_test and spread are probably welcome
<pstolowski> zyga: yes.. and somehow it's only on 14.04 (afair)
<mborzecki> pedronis: sure, will be adding those
<zyga> I don't know,  think I saw that across the board
<pstolowski> hmm ack
<zyga> offtopic, so the GitHub news seems true,
<zyga> I wonder what this means for us
<pstolowski> zyga: what is it about github?
<zyga> pstolowski: ms bought it
<pstolowski> woot
<ogra_> zyga, they did ? i thought they only think aloud about it yet ... was there an official statement ?
<ogra_> (they also said they might only invest in shares and not buy the whole company afaik)
<pedronis> mborzecki: also store changes are a bit buggy ,  that code was sometimes  assuming that instanceKey == snapID which is not true anymore and doesn't seem fully updated
<zyga> ogra_: I don't know for sure, there's plenty of news but also rumour around this topic
<zyga> I think we'll just wait and see
<ogra_> yeah
<ogra_> afaik most is speculation atm
<ogra_> (what is clear is that MS has "some interest" in GH ... but perhaps thats only to the level like they had interest in imagination tech. where they hold a third to have influence on the graphics driver development)
<zyga> http://www.bloomberg.com/news/articles/2018-06-03/microsoft-is-said-to-have-agreed-to-acquire-coding-site-github
<mborzecki> ogra_: heh, how imagination tech. handled being up for sale was a fiasco :) at least for imagination...
<ogra_> yeah, totally
<ogra_> haha "Bill Gates and Paul Allen co-founded the company to give hobbyists a way to program a new micro-computer kit, the MITS Altair."
<ogra_> thats soo ... LOL ...
<ogra_> s/to give hobbyists a way/to lock in hobbyists that already had ways to/
<ogra_> heh, this one is also great:
<ogra_> "GitHub preferred selling the company to going public and chose Microsoft partially because it was impressed by Nadella ..."
<ogra_> ... "he looks so good" ... :P
<zyga> <trump voice>you look good, are you exercising?</trump voice>
<ogra_> haha
<mvo> pedronis: good morning! I updated 5217 based on your feedback
<pedronis> mvo: hi, looking
<mvo> pedronis: thank you. I'm looking at the firstboot changes right now, I think I will need to reuse bits from 5217 here :)
<mup> PR snapd#5162 closed: overlord/hookstate: support undo for hooks <Critical> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5162>
<pedronis> mvo: I think snapd should come first in the snaps installed sequence
<mvo> pedronis: ok, let me fix this
<pedronis> we then take care again of that in first boot
<pedronis> but we should keep being consistent I think
<mvo> pedronis: yeah, makes sense
<mvo> pedronis: updated
<pedronis> pstolowski: is your -1 because of the last comment, it wasn't super clear (the other one is wondering and one is a nitpick so IÂ suppose so)
<pstolowski> pedronis: yes just about Empty(); and i prefer to call it "requesting a change", not -1 because I'm +1 for you change overall :)
<pedronis> pstolowski: well, it really means "requesting a change and wanting to look again"
<pstolowski> fair enough, it's just a minor thing, that's all i'm saying
<rbasak> I'm under the impression that I can download any revision of a previously published store if I have the right developer access. Is that correct, or is there some kind of retention/expiry policy?
<rbasak> I'm trying to download r429 of git-ubuntu from the store, since r430 in edge broke what previously worked.
<rbasak> snap download --revision=430 git-ubuntu
<rbasak> worked
<rbasak> snap download --revision=429 git-ubuntu
<rbasak> says: error: cannot find snap "git-ubuntu": snap not found
<rbasak> I tried logging in with snap login, but after credentials that failed and suggested sudo
 * cachio afk
<rbasak> sudo snap login works, with both credentials and a further prompt for 2fa
<rbasak> But even then, both snap download and sudo snap download still fail
<thresh> hello
<thresh> is there a "install" button widget or something I could add on my website to point to snapcraft.io/vlc ?
<rbasak> I found https://dashboard.snapcraft.io/snaps/git-ubuntu/revisions/429/ which has a download link which works. But that gives me only the snap, not the assertion.
<pedronis> rbasak: that's correct, it should be possible if you have developer access
<pedronis> rbasak: can you open a bug https://launchpad.net/snapstore/+bugs
<rbasak> pedronis: thanks. The dashboard link shows me "
<rbasak> Submitted by
<rbasak> nacc (nish.aravamudan@gmail.com)
<rbasak> "
<rbasak> Which isn't me.
<rbasak> Could that be the reason?
<rbasak> Some kind of team/individual confusion.
<rbasak> It should all be handed over to me, and this was done before that revision was pushed.
<rbasak> I remember having to re-auth Launchpad to the store.
<pedronis> rbasak: if you can push to it it shouldn't matter
<mup> PR snapd#5244 closed: tests: shellchecks part 3 <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5244>
<Chipaca> rbasak: what architecutre is the snap?
<Chipaca> rbasak: if you are logged in, you can ask for any published revision, as long as it's for the current architecture
<rbasak> All amd64
<Chipaca> rbasak: 'snapcraft revisions git-ubuntu' agrees?
<Chipaca> oh
<Chipaca> wait
<Chipaca> *snap download*
<pedronis> ah, download
<pedronis> me missed that
<rbasak> As opposed to what - publish?
<Chipaca> rbasak: install
<rbasak> Ah
<Chipaca> rbasak: download doesn't talk to snapd to get your tokens
<rbasak> Let me explain a little more what's going on
<rbasak> edge was working
<rbasak> I made an innocuous push to master in our codebase, which triggered a Launchpad build recipe to push to edge
<rbasak> That tripped some kind of non-determinism in snapcraft and pushed a broken snap to edge
<Chipaca> rbasak: QOTM right there
<rbasak> I'd like to do two things: 1) restore edge; 2) examine the snap that Launchpad produced, which is broken, since that isn't what our CI did, which was OK
<Chipaca> âI made an innocuous push to master in our codebaseâ :')
<rbasak> :)
<Chipaca> rbasak: ok, so if edge is currently broken and that's the one you want to download, why not snap download it right now?
<Chipaca> there's a bit of a dance to be done to get it to use the right tokens otherwise
<rbasak> https://forum.snapcraft.io/t/launchpad-post-build-pre-upload-testing/5545 has some broken
<rbasak> Chipaca: I've downloaded the broken one no problem.
<Chipaca> ah ok
<rbasak> Chipaca: I'd like to download the previous good one too
<rbasak> I have managed to get the snap from the dashboard UI
<Chipaca> rbasak: once you have the bad one, use snapcraft to re-pubish the good one, and download that one
<rbasak> But I was confused as to why "snap download" didn't work since I was under the impression that it would
<rbasak> Also that the dashboard web UI didn't give me the assertion file, but I presume I will just get a new one when I re-publish the good one?
<pedronis> sorry, IÂ misunderstooed,  download doesn't work in that case (unless you pass it tokens manually)
<pedronis> but that's known bug,  not prioritized for a fix yet though
<rbasak> https://dashboard.snapcraft.io/snaps/git-ubuntu/revisions/429/ has a Release button
<pedronis> https://forum.snapcraft.io/t/improvements-in-snap-download/1422/8
<rbasak> Can I stick it back in edge through there?
<Chipaca> rbasak: yes
<rbasak> Great! I think I know how to do everything I need then.
<rbasak> Thank you for your help - it's much clearer to me now what is going on.
<zyga> pstolowski|lunch, mborzecki: updated 5245
<zyga> and I have a working follow-up that uses it extensively
<zyga> and drops all segments from the code
<mborzecki> zyga: ok, looking
<jdstrand> skomorokh: it isn't currently possible to do what you want. I suggest creating a forum topic at https://forum.snapcraft.io
<zyga> pstolowski|lunch, mborzecki: I pushed the other PR to https://github.com/snapcore/snapd/pull/5254
<mup> PR #5254: cmd/snap-update-ns: discard the concept of segments <Created by zyga> <https://github.com/snapcore/snapd/pull/5254>
<mup> PR snapd#5254 opened: cmd/snap-update-ns: discard the concept of segments <Created by zyga> <https://github.com/snapcore/snapd/pull/5254>
<zyga> jdstrand: hey, good morning :)
<jdstrand> hey zyga :)
<zyga> jdstrand: I'm working on trespassing, went on a small tangent to clean up validation interface, ended up killing segments
<jdstrand> cool
<zyga> I have one last cleanup on top, to make error messages less duplicated, shorter and to the point
<zyga> then the stack unwinds and validation is back, also with fuse validation
<zyga> I didn't see fuse as a problem but now I do :/
<zyga> anything fuse has one filesystem type number
<zyga> so we no longer know read-only squashfs from writable fuse-exfat or whatever
<zyga> I'd love if there was a way to see if a filesystem is read-only without trying to write to it
<Chipaca> zyga: doesn't statfs's ST_RDONLY work?
<zyga> mmmm :D
<zyga> maybe, I didn't think about that !
<zyga> Thank you John, I'll check that
<Chipaca> wouldn't be surprised if it didn't,  because it being fuse means somebody would have to care :-)
<mup> PR snapd#5255 opened: cmd/snap-confine: applied make fmt <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5255>
<mup> PR snapd#5256 opened: cmd/libsnap-confine-private: helper for extracting store snap name from local-name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5256>
<zyga> mborzecki: can we not use the word base there
<zyga> it's not about the code but the word would become overloaded and confusing
<zyga> what's the terminology for the instances/parallel installation etc
<mborzecki> haha ok ;)
<mborzecki> if we had a list of forbidden words, i'd nominate classic
 * zyga should take the dog for a walk
<Chipaca> mborzecki: you should call it 'root', that way it's unambiguous
<mborzecki> Chipaca: sc_snap_root_name sounds good
<Chipaca> mborzecki: I was being facetious
<mborzecki> Chipaca: heh, given the limited possibilities root actually make sense :)
<Chipaca> mborzecki: sc_snap_uninstanciate_name
<Chipaca> mborzecki: sc_snap_deinstance_name
<Chipaca> mborzecki: sc_snap_get_rid_of_this_instance_nonsense_in_the_name
<mborzecki> sc_snap_drop_instance_name
<Chipaca> mborzecki: sc_snap_what_is_this_instance_stuff_just_i_dont_even
<mborzecki> sc_snap_why_u_name
<Chipaca> mborzecki: sc_snap_wat
<Chipaca> mborzecki: putting my serious hat on for a moment, sc_snap_drop_instance_name might be the best one so far
<zyga> pstolowski: can you look at the iterator PR again please
<pstolowski> zyga: will do
<zyga> feel free to open more points there, I changed the code much after really using it
<zyga> niemeyer: $7.5B in stock
<pedronis> niemeyer: the PR IÂ mentioned is here:  https://github.com/snapcore/snapd/pull/5221
<mup> PR #5221: [RFC] snap: parse connect instructions in gadget.yaml <Created by pedronis> <https://github.com/snapcore/snapd/pull/5221>
<niemeyer> zyga: How much is that divided by the number of developers?
<niemeyer> Just trying to figure how much I'm worth :P
<zyga> niemeyer: ~100 AFAIK
<zyga> ah sorry
<zyga> 745 exactly
<zyga> man, that's even nice to divide :P
<zyga> 10M each, even for the guy mending the coffee machine
<niemeyer> pedronis: Looking
<mborzecki> cachio: is gce cleaner using timer services?
<cachio> mborzecki, yes
<mborzecki> nice
<cachio> mborzecki, :)
<cachio> working very well so far
<mborzecki> noticed the banner at the top of the github page?
<cachio> mborzecki, yes
<niemeyer> pedronis: Reviewed.. probably needs a quick sync, on that last question.. going into a call now, and we can sync after it
<mup> PR snapd#5257 opened: snapstate: ensure fakestore returns TypeOS for the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/5257>
<zyga> back from the walk
<zyga> so so so hot
 * zyga made some ice coffee and gets back to work
<zyga> @niemeyer eh
<zyga> https://gitlab.com/Zyga
<zyga> :-(
<zyga> who is pawel z?
<pstolowski> zyga: uh...new face of cybersquatting
 * zyga enjoys some brief breeze of wind
<pedronis> niemeyer: oops, I got confused and thought your meeting was 1h
<niemeyer> pedronis: It wasn't too far from it :)
<mup> PR snapd#5258 opened: tests: fix lxd test which hangs on restore <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5258>
<mup> PR snapd#5217 closed: asserts,image: add support for models with bases <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5217>
<Chipaca> robert_ancell: o/
<zyga> pstolowski: updated
<zyga> pstolowski: the error from the constructor fits the rest very nicely, I will now update the remaining PR
<jdstrand> cachio: hey, can you take a look at https://github.com/snapcore/snapd/pull/5248? The only issue with travis is that the lxd fix hasn't made it to 2.33
<mup> PR #5248: tests: add test to ensure /dev/input/event* for non-joysticks is denied - 2.33 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5248>
<cachio> }jdsure
<pstolowski> zyga: great, thanks
<jdstrand> at least I think I'm remembering that right
<jdstrand> cachio: thanks
<Chipaca> mvo: let me know if I'm bikeshedding too much on your RFC PR
<Chipaca> oops
<mup> PR snapd#5259 opened:  devicestate: support seeding from a base snap instead of core  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5259>
<mvo> Chipaca: just read it, its great
<mvo> Chipaca: thank you!
<zyga> pstolowski: can you re-review that PR please, it would get me unblocked
<pedronis> niemeyer: I'm available for the next hour for that chat, otherwise tomorrow
<pstolowski> zyga: doing
<zyga> Thanks :)
<pstolowski> zyga: looks good, although you made it strict in all cases now, that's intended? i thought you would have to variants?
<pstolowski> *two
<pstolowski> ah, cleanpath should succeed generally
<zyga> pstolowski: no, I thought so too but the usage down the line is fine as-is
<pstolowski> +1
<zyga> \o/ thanks!
<zyga> let's hope tests are lucky now
<mup> PR snapcraft#2153 opened: project_loader: allow loading null parts <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2153>
<niemeyer> pedronis: Hey, give me a couple and will be with you
<mup> PR snapd#5245 closed: cmd/snap-update-ns: add PathIterator <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5245>
<niemeyer> pedronis: https://meet.google.com/ftn-sqmv-kwy
<zyga> pstolowski: follow-up in #5254
<mup> PR #5254: cmd/snap-update-ns: discard the concept of segments <Created by zyga> <https://github.com/snapcore/snapd/pull/5254>
<zyga> now shorter and just to the point
<mup> PR snapcraft#2151 closed: Debian <Created by transdigiware> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2151>
<pstolowski> zyga: i'll take a look tomorrow morning
<zyga> pstolowski: sure
<cachio> pedronis, hey, any idea why it could be happening? https://paste.ubuntu.com/p/F8fwwrYHVt/
<cachio> it is not retrying the assertions
<Trel> I'm having some problems understanding how to create a snap.  I have a binary, a few depencencies, and a wrapper script.  Nothing is being compiled.  I'm not sure how to go about doing this.  I'm looking at the site, but not having much luck understanding it.
<zyga> jdstrand: hey, do you have some time for a small refactor review?
<jdstrand> zyga: which PR?
<zyga> Trel: see what snapcraft does, it allows you to bundle your binary (using the copy plugin AFAIK but kalikiana can correct me), you can also define your dependencies which will be added to your snap
<zyga> Trel: with some iteration you should get it going
<zyga> jdstrand: #5254 please
<mup> PR #5254: cmd/snap-update-ns: discard the concept of segments <Created by zyga> <https://github.com/snapcore/snapd/pull/5254>
<zyga> jdstrand: this is related to trespassing, the segment verification was unable to verify rootfs and was super confusing with off-by-ones
<Trel> zyga: I've been trying to use snapcraft the entire time.  I'm not getting it
<zyga> Trel: snapcraft defines how various parts should be combined (perhaps built, perhaps not) into a snap and what the snap itself should export
<zyga> Trel: I'd suggest installing hello-world
<zyga> looking at what the snap actually contains (in /snap/hello-world/current)
<zyga> specifically focus on meta/snap.yaml
<zyga> Trel: then run snap run --shell hello-world
<zyga> and explore how the filesystem looks like, it's not the same as before
<zyga> this should give you some feeling of how snaps execute
<zyga> after that the question is "how to build one for myself"
<zyga> there are many paths, snapcraft is the most complete and automated one
<zyga> but for experimentation and learning you can hand-make one with a few commands
<zyga> all you need is meta/snap.yaml
<zyga> some files you want to have in your snap
<zyga> then you can "snap try" from the directory containing the "meta" directory (this becomes the top level directory in your snap)
<zyga> and see what happens
<zyga> "snap try" is fantastic for iteration IMO
<zyga> you can even get started by copying hello-world snap into a directory of your own
<zyga> and tweaking some things
<zyga> and "snap try" that
<zyga> once you are more comfortable research snapcraft and see how you can take your binary and ship it as a snap
<zyga> and people here will no doubt help you out with specific questions
<Trel> See, I'm not following any of what you said.
<zyga> Trel: ok, start from the top,
<zyga> run "snap install hello-world"
<zyga> then see that you can run it
<Trel> would it be possible to not base it off another?
<zyga> then look at how it is defined by looking at various files present in /snap/hello-world/current/
<zyga> Trel: sure but I'm trying to show you how snaps look like
<cachio> Chipaca, do you have any idea why it could be happening? https://paste.ubuntu.com/p/F8fwwrYHVt/
<zyga> you don't have to start from hello-world, this was just a working example you can tweak
<Trel> I'll try that but without understanding what I'm looking at, I'm not sure what I'll get out of it that I'm not getting from the docs
<cachio> Chipaca, it is not retrying the assertions
<zyga> Trel: do you have some basic understanding of how snaps operate?
<zyga> Trel: I think snapcraft docs _may_ explain that but I'm not the best person to judge that given I develop snapd
<zyga> Trel: having this basic feeling of what snaps do will let you build an understanding of what it takes to build one
<zyga> Trel: and finally how to use snapcraft to accomplish your goals
<Trel> depends on what you mean, I get the general concept, but not the operation.
<Trel> But I'm not understanding what I'm doing to try and add this at all
<zyga> Trel: ok, then exploring hello-world will be useful IMO
<zyga> Trel: you should learn about what meta/snap.yaml does, looking at hello-world is a good quick idea
<Trel> I installed hello-world, I'll look, but I get the feeling it's not going to help me understand because I'm not understanding the examples that use it in the docs either
<zyga> Trel: you should also understand how snaps execute, running a command is nice but running "snap run hello-world --shell" is eye-opening
<zyga> hint: it's not like your regular system, this is what makes snaps so portable
<zyga> Trel: e.g. go to / and run "ls" in that shell, it's not your root filesystem
<Trel> Also when I do snapcraft init, I don't get a meta directory at all
<zyga> Trel: in the end snap really just ship arbitrary binaries and have a meta-data file describing what those are, snapcraft will let you build snaps ranging from most trivial to most complex but the documentation may use concepts that are unfamiliar at first
<zyga> Trel: the source layout is not the same as binary layout, if you follow the snapcraft tutorial and build the first snap there, look at the contents of the prime/ directory
<zyga> that is what is inside a built binary snap
<zyga> Trel: most of what is in snapcraft.yaml ends up in meta/snap.yaml
<zyga> (except for the parts that define how to build it)
<zyga> Trel: did you follow this, for example? https://docs.snapcraft.io/build-snaps/your-first-snap
<Trel> That's what I'm looking at and not getting.  It's talkign about parts, and snapcraft says parts is required, but hello-world has none
<zyga> Trel: parts only exist at build time
<zyga> after your snap is built parts play no role
<Trel> yes....that's the whole portion I'm not getting
<zyga> compare snapcraft.yaml with prime/meta/snap.yaml
<zyga> well, now you do :)
<zyga> parts only exist at build time
<zyga> at runtime you only have a snap
<Trel> I honestly am not getting it
<Trel> hold on a sec
<zyga> Trel: are you familiar with any classic packages (like deb/rpm?)
<zyga> Trel: maybe I can make an analogy if you are
<Chipaca> cachio: not sure why i didn't see the notification for your question, sorry
<Chipaca> cachio: what command are you running, there?
<Trel> I'm not, no.
<Trel> https://pastebin.ca/4037224  here's what I put in snap.yaml
<zyga> that's what you would put in a snapcraft.yaml
<Trel> that's what I meant
<Trel> sorry
<zyga> snapcraft uses snapcraft.yaml to build a snap and generate an appropriate snap.yaml file
<zyga> ah, perfect then
<cachio> Chipaca, we run
<cachio> su -c "/usr/bin/env SNAPD_DEBUG=1 snap download --edge test-snapd-huge 2>snap-download.log" test &
<Chipaca> cachio: if it's the same 'snap download' from econnreset/task.yaml, .... i don't know
<zyga> Trel: the plugin on line 17 is what tells snapcraft how to build a given part
<zyga> Trel: you used nil which literally does nothing at all
<cachio> Chipaca, yes, it is the same
<Chipaca> cachio: but
<zyga> Trel: you probably want one that builds the program or one that copies a pre-made binary from somewhere else
<Chipaca> cachio: the assert is downloaded after the snap
<zyga> https://docs.snapcraft.io/build-snaps/plugins has more info about plugins
<Chipaca> cachio: but we only wait for the snap
<Trel> zyga: pre-made, and I thought that's what I'm doing there
<zyga> Trel: almost, the nil plugin is not the right one
<zyga> kalikiana: around?
<zyga> kalikiana: can you please help Trel ^
<cachio> Chipaca, so, in this case it is ok the assert is not retried
<cachio> because in the error, it is not starting the download
<Chipaca> cachio: which is the failure?
<cachio> it is creation el partial file
<zyga> Trel: AFAIR you want to use "dump" plugin
<zyga> https://docs.snapcraft.io/reference/plugins/dump
<cachio> but emprty
<zyga> https://docs.snapcraft.io/reference/plugins/ is also useful
<Chipaca> cachio: ah!
<Trel> I looked there and googled around, from what I read if I was supplying the binary, I should've been using nil
<Trel> let me switch it to dump and try
<zyga> Trel: you want to switch nil to dump and add a source line that defines where to get the pre-build binary
<cachio> Chipaca, the problem is that the snap does not start to be downloaded
<zyga> I think nil would work iff you'd keep the binary in the same place as snapcraft.yaml
<Chipaca> cachio: maybe 20 seconds is too short a time, and we should wait more?
<zyga> but I'm a snapd person not a snapcraft person so I may not be fully used to how things are done on the build side
<zyga> Trel: please ask kyrofa_, sergiusens or kalikiana as they know this code inside out
<cachio> Chipaca, I don't know if it is the problem
<cachio> Chipaca, we could try
<Trel> Can I run the snap it generates without installing it to see what it does?
<cachio> wait more time and see if the problem is this one
<zyga> Trel: yes, (well), "snap try" does that
<zyga> it is like "snapcraft && snap install *.snap" but much faster
<kyrofa_> Hey there Trel
<zyga> as long as you don't change snapcraft.yaml (or meta/snap.yaml) you can also change the snap in your source tree live
<Trel> needs sudo to try?
<zyga> yes
<zyga> or sudo snap login
<zyga> then snap works without sudo
<kyrofa_> Trel, indeed, as zyga was saying the nil plugin literally does nothing. You can still use it, but you'd have to do all the copying yourself, whereas the dump plugin sounds more like what you want
<kyrofa_> ("take this tarball and dump it all into the snap")
 * zyga hugs kyrofa_ 
<Trel> kyrofa_: I thought I DID do all the copying, which is what I'm really not getting here
<kyrofa_> Trel, let me take a look at the pastebin
<kyrofa_> It's taking quite some time to load for me
<Trel> and hold on I'll also pastebin a recursive ls
<Trel> there a better pastebin site?
<kyrofa_> Trel, mind using pastebin.ubuntu.com?
<kyrofa_> About as simple as it gets
<zyga> Trel: there's a pastebinit command that helps :)
<Trel> Dir listing: https://pastebin.ubuntu.com/p/Dx7G84c7V4/, snapcraft: https://pastebin.ubuntu.com/p/Y22k9QpD7V/
<zyga> I think the "filesets" is confusing there
<zyga> its meant to help organise how a given part contributes to the snap
<zyga> not how to install files in general
<zyga> jdstrand: is that code sensible?
<zyga> jdstrand: I have some cleanups on top of that
<zyga> mainly error handling that's nicer
<jdstrand> zyga: I haven't had a chance to look at it yet
<jdstrand> hopefully in a bit
<zyga> ack
<zyga> thank you :)
<Trel> but what is the RIGHT way to do it, I've found a lot of ways that aren't working ><
<kyrofa_> Trel, yeah, so you have a good start here, but you're using some more advanced features (filesets) without actually doing the basics. So let's start simpler
<kyrofa_> Trel, you have a bin directory that you want in the snap, right?
<Trel> yes
<kyrofa_> You can do that in two easy ways
<Trel> And if it's doing it virtually, I'd prefer that it considers it /usr/bin but that's not necessary, thought it would be good in the case of libraries that I can't reloacte
<Trel> *relocate
<kyrofa_> One is using the dump plugin like this: https://pastebin.ubuntu.com/p/zhDMDmDBBS/
<kyrofa_> Saying "copy the root of my project (which only contains the bin directory) into the snap"
<Trel> What about with nil?
<kyrofa_> The other one, which I don't recommend but illustrates that the nil plugin isn't doing anything for you, looks like this: https://pastebin.ubuntu.com/p/GnDjR9Fb8T/
<Trel> But where should I be putting the binary directory in that case
<kyrofa_> Both accomplish the same thing with the bin directory in the place you have it now
<kyrofa_> And both place it into the root of the snap
<kyrofa_> If you want to reorganize it, you can copy it to a different place using the nil plugin, or you can use the `organize` keyword with the dump plugin
<Trel> kyrofa_: except where I have it now, with nil, doesn't work
<kyrofa_> Trel, even using the code I gave you?
<Trel> Wait, I'm confused, does nil do nothing or does it execute that line?
<Trel> I tried both ways, I get a snap, but it doesn't run
<zyga> mborzecki: hey
<zyga> mborzecki: small review on #5256
<mup> PR #5256: cmd/libsnap-confine-private: helper for extracting store snap name from local-name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5256>
<zyga> Trel: does it contain the files you expected?
<Trel> I think so, and running them from /snap/qrencode/x1/bin/ works
<zyga> excellent
<Trel> nope
<zyga> what does your binary link with?
<zyga> you need to bring those dependencies into your snap
<Trel> should just be libpng was the only non-static part
<Trel> cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied
<Trel> that's what I get when I try to run it normally
<zyga> Trel: hmm, what is your "snap version"?
<zyga> and can you paste "dmesg | grep DENIED"
<Trel> 2.32.8
<zyga> Trel: please provide the rest of the version output, it's useful
<Trel> dmesg: https://pastebin.ubuntu.com/p/FcwChNF28V/ version: https://pastebin.ubuntu.com/p/HHzBvMWBQN/
<zyga> kernel  3.13.0-35-generic this is unusual
<zyga> or maybe I'm forgetting what's in xenial
<zyga> is this a cloud machine?
<zyga> you should be on a 4.4 kernel
<zyga> not on a 3.13 one
<Trel> nope, machine I built a while back
<zyga> 3.13 won't work AFAIR
<Trel> but snapcraft does
<zyga> xenial ships with a 4.4 kernel, did you update from 14.04?
<zyga> (aka trusty)
<Trel> I may have
<Trel> it's been a while
<Trel> Is there a way to check that?
<zyga> can you update all of your packages, including the kernel and then reboot
<zyga> you should see a boot selection if you have multiple kernels
<zyga> but the most recent one should be default
<zyga> unless you changed that
<zyga> mvo: should we add minimum kernel detection to self-tests?
<zyga> mvo: I think this could be perhaps, somewhat disruptive
<zyga> but I think it would be worth it
<Trel> The server is remote to where I am.  I won't see the boot screen.  I can do all but that part (in that way). I'm looking right now at grub.cfg and don't see any entries referencing 4.x?
<Trel> BTW, apt doesn't seem to be offering a kernal update
<zyga> Trel: you can install linux-image-generic, that should pull in the right kernel
<Trel> yeah, I'm about to try that, that will boot me from IRC though when I reboot, I'm going to quit now gracefully prior to doing this, be back in a bit
<mup> PR snapcraft#2154 opened: tests: disable sentry <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2154>
<mvo> zyga: can we detect this reliable?
<zyga> mvo: well, we can do some things that are smart, e.g. recommend a reboot when using ubuntu 14.04 and 3.13 kernel, say that 2.x kernels are not supported and a few others
<zyga> I'm looking at your self-test PR as base, let me post some RFC ideas
<Trel> I think the kernel bit worked
<Trel> I need to try the build again
<zyga> Trel: excellent
<Trel> Ok, one thing to ask before I try testing, if I have a script, that refers to a binary in the snap, how does the path relate inside?
<zyga> Trel: you can use the $SNAP variable
<zyga> it refers to the top-level directory in your snap
<zyga> so if your snap has bin/someniceapp to run
<zyga> you can have your wrapper script run $SNAP/bin/someniceapp
<zyga> mvo: this is what I was thinking about https://github.com/snapcore/snapd/pull/5260/commits/50119c96a87952b4af92a8d224cece1bc90e292a
<mup> PR #5260: sefltest: advise reboot into 4.4 on trusty running 3.13 <Created by zyga> <https://github.com/snapcore/snapd/pull/5260>
<zyga> mvo: but the concept can be extended into new areas
<mup> PR snapd#5260 opened: sefltest: advise reboot into 4.4 on trusty running 3.13 <Created by zyga> <https://github.com/snapcore/snapd/pull/5260>
<zyga> like flagging ancient openvz kernels that don't work
<zyga> since it is restricted to classic it should not harm any product kernels that may have kept old version id but have all the extra patches that make snaps work
<Trel> ok, let me try that, if it works, is there anywhere I can the resulting snap file assuming it works on my machine?
<zyga> Trel: just ensure that you run your snap as "snap run yoursnapname"
<zyga> as running the binary from /snap/yoursnapname/bin/whatever doesn't really use snaps
<zyga> once your snap works you can share it with a friend for quick testing
<zyga> or register the name on the store and upload it there
<zyga> (the binary that is)
<zyga> snapcraft has commands for all of that
<Trel> I added /snap/bin to my path, is that the same as snap run?
<zyga> Trel: yex
<zyga> yes, exactly the same
<zyga> if you look at what is in /snap/bin
<Trel> I THINK it's working
<zyga> you will find symbolic links to /usr/bin/snap
<zyga> which detects this and behaves as if you ran "snap run"
<Trel> ah, so I should now try it with strict mode I'm guessing
<zyga> for strict mode you will need to start using some interfaces,
<zyga> switch your snap to strict mode (confinement: strict)
<zyga> re-build it
<zyga> install it
<zyga> and see what happens when you run your app
<zyga> but congratulations, in development mode your application is already a snap :D
<Trel> What do you mean by interfaces in this case?
<zyga> Trel: snapd interfaces are a system that allows to change the set of things that snaps can run and to allow snaps to work together
<zyga> https://docs.snapcraft.io/core/interfaces
<zyga> https://docs.snapcraft.io/reference/interfaces is also useful
<Trel> I'll give them a look, though I'm not sure how necessary they'll be for this one
<zyga> Trel: it depends on what your snap does
<mup> PR snapd#5261 opened: tests: wait more time until snap start to be downloaded <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5261>
<Trel> In my case, it uses a pre-compiled binary, with a wrapper script.  I will try later to have it compile it rather than use a pre-compiled one
<Trel> it's wrapping this specifically: https://github.com/fukuchi/libqrencode
<zyga> Trel: it's not about the binary being precompiled or not
<zyga> it's about what the resulting process tries to do
<zyga> which system calls it wants to access, which files it wants to access, which IPC system it wants to access
<zyga> it is all about runtime
<Trel> I'm not sure how'd I'd even determine that let alone work with it
<zyga> Trel: you run your app and see what happens
<zyga> we have tools and people that can help
<Trel> it ran
<Trel> which is to say, I have no clue if that means I'm done or there's something else I'd need with what you're saying about interfaces?
<zyga> Trel: interfaces allow snaps to do things, at runtime, that are not allowed by default; if your application was never confined it could do anything it wanted.
<zyga> the App Store model is built on confinement so untrusted applications can be used without code review
<zyga> as long as the set of permissions they have is understood and managed
<zyga> that's what interfaces allow
<zyga> if the confinement system gets in the way from accessing some critical resource then you will need to look at interfaces for solutions
<Trel> Since my wrapper script passes text either as a parameter or piped in, and the result is just spit to the terminal, I'm guessing it doesn't apply for this usage?
<zyga> almost
<zyga> piping things means the process inherits a file descriptor
<zyga> it depends on where it is coming from
<zyga> but just try it and see
<zyga> jdstrand: will you have time for that review today?
<jdstrand> zyga: my today, yes
<zyga> jdstrand: thank you, perfect, I will iterate with cleanups on top
<mborzecki> zyga: jdstrand: thanks for the reviews on #5256, pff silly me :/, i've pushed fixes just now
<mup> PR #5256: cmd/libsnap-confine-private: helper for extracting store snap name from local-name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5256>
<zyga> mborzecki: can you patch tests to ensure that things are correct
<zyga> like with the off by one
<Trel> zyga: I'm a bit lost there, I've tried it both ways and it works
<Trel> without anything else so far
<zyga> Trel: that's fine then
<zyga> Trel: I'm not sure what your app is doing
<zyga> Trel: but if it works, that's what you want :)
<zyga> it works, ship it
<Trel> taking text as a parameter or piped and generating a QRCode using unicode characters, and outputting it to the terminal  (the actual libqrencode can make files as well) but my wrapper is what resticts it ot just doing text
<zyga> that should be fine
<zyga> it might be more complex if you want to redirect to/from a file in ~/.ssh/secret for example
<zyga> but for normal usage it should work just fine
 * cachio afk
<Trel> There any way to avoid "Copying needed target link from the system", I'm guessing I'd need to add the package somewhere, but I'm not sure where.
<zyga> can you please be more specific, which command gave you that error?
<mborzecki> zyga: i've added more tests, also the temp buffer is filled with some known pattern to check for the code doing proper termination with \0
<zyga> thanks!
<Trel> This is if I try to compile it rather than copy the binary directly
<Trel> full line is: Copying needed target link from the system /lib/x86_64-linux-gnu/libz.so.1.2.8
<zyga> that's something for kyrofa_ I think
<Trel> I thought it was just adding it to build-packages or similar but I can't seem to reference it anywhere that stops that line
<zyga> build packages are the packages you need to build
<zyga> stage packages are the packages you need to run
<Trel> yes, that's to build, not run
<Trel> precompiled doesn't seem to need it
<zyga> but does your binary link to libz in the end?
<zyga> what does ldd say?
<Trel> not sure, that I can check when I'm back on the pc
<zyga> just run ldd /path/to/your/binary
<Trel> Can't run it on my phone ><
<zyga> :-)
<Trel> (weechat relay, not actually at the machine)
<mup> PR snapcraft#2155 opened: build_providers: support for communicating with a qemu VM <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2155>
<kyrofa_> Trel, that means whatever you're building depends on libz.so, but you're not staging it
<kyrofa_> So it takes it from the system instead. You can disable this behavior by adding `build-attributes: [no-system-libraries]` to the part definition
<kyrofa_> But then that part will be broken, so I suggest you stage that lib
<kyrofa_> jdstrand, what does this review error mean?
<kyrofa_> The store was unable to accept this snap.
<kyrofa_>   - found binaries for architecture 'all'
<kyrofa_> (and then it gives a list of stuff)
<kyrofa_> This is an `architectures: [all]` snap, does that have something to do with it?
<kyrofa_> The error message is very opaque
<kyrofa_> roadmr, do you know what that ^ means?
<roadmr> kyrofa_: let me see
<Trel> kyrofa_: testing that out now
<roadmr> kyrofa_: non-gadget snaps with architectures: all can't have compiled binaries inside, because a single binary to rule all architectures is not possible
<roadmr> kyrofa_: it should either be arch-specific or not have anything compiled inside (i.e. should contain only interpreted code, .py, .sh, and so on)
<Luke> hey guys, i'm trying to build my first snap of mastodon which has a ruby, nodejs, and nginx component. my question is first: can i use a nodejs AND ruby plugin in the same part?
<Luke> my second question is, for building ruby packages, I need some extra apt repos for the build-packages. what's the right way to add those?
<kyrofa_> roadmr, so it's impossible to ship multiple binaries along with a shell script to decide which to run?
<kyrofa_> I thought that was the definition of "fat" snap
<Trel> kyrofa_: I see what happened, I forgot I got the pre-compiled one mostly static, that's why it didn't need that lib.  Looks like it may be good now
<kyrofa_> Trel, well, it looks like it _think_ it needs that lib ;)
<kyrofa_> (ldd)
<Luke> what's the relation between snappy and snapcraft?
<Luke> is snappy a deprecated name?
<diddledan> snapcraft is the command line tooling that builds snap packages to run via snapd
<diddledan> snappy ubuntu core is a distribution of Ubuntu that relies entirely on snaps
<roadmr> kyrofa_: I think so, that's at least the logic in the reviewer tools, jdstrand might definitely know more
<kyrofa_> Luke, more and more the entire system is referred to as "Snapcraft" with the CLI tool being known as "the snapcraft CLI"
<kyrofa_> Alright, thanks roadmr. jdstrand curious to get your thoughts on that
<Luke> cool thanks
<Luke> is there a snapcraft specific channel?
<mup> PR snapcraft#2146 closed: project_loader: process parts in consistent order <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2146>
<kyrofa_> Luke, nah, we're all together here! Do you have snapcraft-specific questions?
<Luke> yeah 1) can I use multiple plugins for a single part and 2) what's the right way to apt-add-repository for build-packages?
<Luke> thanks btw!
<kyrofa_> (1) yes, just use the same `source` for multiple parts, (2) this is not recommended
<Luke> ok cool on #1. the source is a tar to be downloaded. I'm assuming it will be cached?
<Luke> kyrofa_: for #2, it's because I'm trying to build ruby stuff. It needs all these rbenv things (I don't know much about building ruby packages)
<kyrofa_> Luke, use the ruby plugin, it'll build a specific version from source
<Luke> and the #3 question is actually: I need to run pgsql and nginx as a part of this app, should I just jam that into it's own part?
<kyrofa_> Luke, that's up to you, you can ship them on their own, but then they need to communicate with each other somehow. Depending on your requirements, it may be easiest to just bundle everything together
<kyrofa_> That way you can update them all in one go as well
<Luke> yes I want to bundle all together for sure
<kyrofa_> So yeah, just new parts
<Luke> just not sure the right way to represent bundling in one snap
<Luke> ok thanks
<kyrofa_> yeah you're spot on: anything that's supposed to be in the snap is a part
<Luke> great
<Luke> you've saved me like 3-5 days of experimenting and forum questions :)
<Luke> is there any ruby-specific snaps you recommend looking at? it seems the least well-represented in snapcraft given the ruby plugin is in beta?
<Luke> is the concept that anyone should be able to run the build part of the snap on any box or is the portability just for the snap once it's packaged?
<kyrofa_> I don't know of any off the top of my head, but the idea is that the build process should be able to run in CI, a clean xenial image
<Luke> ok thought so. that was my goal
<Luke> i just dont know what I'll do about these build deps for ruby then
<Luke> rbenv and ruby-build
<Luke> https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Production-guide.md here's the build guide i'm following btw if you're interested
<Trel> kyrofa_: what file would I be using ldd on in that case?
<kyrofa_> Trel, well, you can start with the one in bin
<Trel> you're talking about AFTER it builds right?  My pre-compiled one is what I'm saying doesn't link to the external version of that file
<Trel> One other question, which command for would display the 'description' field.  Info (even with verbose) is only showing the summary.
<mup> PR snapcraft#2153 closed: project_loader: allow loading null parts <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2153>
<mup> PR snapcraft#2154 closed: tests: disable sentry <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2154>
<jdstrand> roadmr: hi! hey, can you pull r1086? when that is live, we can turn on resquash
<roadmr> jdstrand: hehe sure! tomorrow, most likely; I've just deployed r1082
<jdstrand> roadmr: thanks! tomorrow sounds good
<mup> PR snapcraft#2156 opened: snap: use apt from the archive instead of compiling <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2156>
#snappy 2018-06-05
<zyga> good morning
<mborzecki> morning
<mvo> hey zyga and mborzecki
<zyga> Hey guys
 * zyga has a doctor appointment on the other side of the city at 12:30, wondering if he should go now and wait there or wait and then go when it's hotter outside
<zyga> mborzecki: can you look at 5254 please? :)
<zyga> mvo: I sent the kernel RFC idea we talked about last night to 5260
<mborzecki> btw. i think we should merge #5258
<mup> PR #5258: tests: fix lxd test which hangs on restore <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5258>
<zyga> +1
<zyga> mborzecki: 5257 is a short low hanging fruit in need of a 2nd review
<mvo> zyga: ok
<mup> PR snapd#5258 closed: tests: fix lxd test which hangs on restore <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5258>
<mborzecki> zyga: 5257 is magic, had to go through snapstate for it to make sense :)
<zyga> jdstrand:
<mvo> mborzecki: thank you! it was sightly annoying because it poped up in the middle of something totally different
<mup> PR snapd#5257 closed: snapstate: ensure fakestore returns TypeOS for the core snap <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5257>
<mborzecki> mvo: hah, i can imagine it was tricky :)
<mborzecki> zyga: can you take another look at #5256?
<mup> PR #5256: cmd/libsnap-confine-private: helper for extracting store snap name from local-name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5256>
<mup> PR snapd#5261 closed: tests: wait more time until snap start to be downloaded on econnreset test <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5261>
<mup> PR snapd#5241 closed: interfaces/udev: call 'udevadm settle --timeout=10' after triggering events <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5241>
<mup> PR snapd#5255 closed: cmd/snap-confine: applied make fmt <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5255>
<zyga> mvo: can I merge https://github.com/snapcore/snapd/pull/5248#pullrequestreview-125842002
<mup> PR #5248: tests: add test to ensure /dev/input/event* for non-joysticks is denied - 2.33 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5248>
<zyga> it is a 2.33 branch
<zyga> with LXD test failing
<pstolowski> morning
<zyga> pstolowski: good morning
<mborzecki> mvo: can you cherry-pick https://github.com/snapcore/snapd/commit/7f4d533166b73551317bf421bc88f65cfd6b12f9 to 2.33 ?
<mborzecki> or let me open a PR with it
<mborzecki> (that's the lxd bit)
<mvo> mborzecki: if you open a PR please also cherry-pick the econnreset thing
<mborzecki> mvo: ok
<mup> PR snapd#5262 opened: tests: backport lxd force stop and econnreset fixes (2.33) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5262>
<mborzecki> mvo: zyga: ^^
<zyga> thanks
<mvo> mborzecki: ta
<pstolowski> jeez, got google:ubuntu-14.04-64:tests/main/econnreset failure this time; it seems to be flaky as well, i saw occasional failures before
<mvo> pstolowski: master should have a workaround (timeout got increased)
<pstolowski> mborzecki: hey, would you like to take another look at #5215 ?
<pstolowski> mvo: ah, great, ty
<mup> PR #5215: ifacestate: improved conflict and error handling when creating autoconnect tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/5215>
<justasking> hello everybody
<justasking> will firefox snap touch my existing firefox profile (ESR 52)?
<zyga> Hey
<zyga> Iâm going offline for a few hours, at least till 14
<zyga> Ping me on irc if urgent
<zyga> I have an older laptop without a modem with me
<zyga> And I will be gardening my old branches
<mvo> 5204 needs a review
<mvo> it would unblock some more core18 work
<mborzecki> mvo: left some comments in 5204
<mborzecki> pedronis: you're breaking my heart, can't use gorename for that Name() -> LocalName() job now :)
<pedronis> mborzecki: ?
<mborzecki> pedronis: your comment about parallel installs and using a different name for the method to actually go through all the code locations where it's used at
<mborzecki> pedronis: it's a valid concern btw
<pedronis> mborzecki: well, I'm trying to make suggestions not to break the software
<pedronis> I understand they are annoying, maybe
<pedronis> as I said, it's likely that you might learn that most places were fine
<pedronis> but is a bit unclear
<mborzecki> yeah i tried to jot down some places where i'm certain we'll need the non-local name (eg. apparmor profiles, sice we'll hide the local name inside the mount ns)
<pstolowski> pedronis: hey, about disconnect hooks, i think that if the snap on either end of connection is not active, we should either error out (but not with retry, it doesn't make much senso imho) or we should run the disconnect hook only on the active side and ignore the inactive one. both options are a little bit problematic though - we don't want to leak resources by not running a hook, but at the same time you may have good
<pstolowski> reason to have snap disabled. and I don't think we want to block snap removal on not being able to run disconnect hook on the other end (because snap on the other end is not active)
<pedronis> pstolowski: mmh, we have static inactive and dynamic inactive though
<pstolowski> pedronis: what do you mean, don't we have a single Active flag?
<pedronis> pstolowski: yes, but remember a refreshed snap is inactive for a while
<pedronis> and then gets back to active
<pedronis> that's why we have the complexity in autoconnect
<pedronis> pstolowski: afaik you need the same kind of code as autoconnect, but anyway all of this shows we really need to implement some of my recommendations or something similar. it's clear it's hard to keep in mind this stuff
<pstolowski> yes
<pstolowski> pedronis: btw I've read your recommendations twice last week, very well written, i've yet to read it once more
<pedronis> pstolowski: but yes, if the other side has no pending link*Â task and its inactive you have to skip its hooks
<pedronis> that's probably true for autoconnect as well (unless it's not listed anyway for other reasons)
<pedronis> pstolowski: as we discussed the behavior of disable and connections is probably a bit buggy already
<pstolowski> yes
<mup> PR snapd#5263 opened: errtracker: do not send duplicated reports <Created by mvo5> <https://github.com/snapcore/snapd/pull/5263>
<Chipaca> how would root know what a user's XDG_CONFIG_HOME is?
<mvo> Chipaca: in what context do you want to know?
<mvo> Chipaca: inspect /proc/$pid/environ
<mvo> Chipaca: of the user
<Chipaca> mvo: daemon running as root needing to look at a user's config
<mvo> Chipaca: but even then nfs-root-squash may squash us
<mvo> Chipaca: maybe running a helper as this user?
<Chipaca> :-( yeah
<Chipaca> mvo: there might be a way to refactor things to take away the need, also
<mup> PR snapd#5215 closed: ifacestate: improved conflict and error handling when creating autoconnect tasks <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5215>
<mup> PR snapd#5248 closed: tests: add test to ensure /dev/input/event* for non-joysticks is denied - 2.33 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5248>
<mvo> Chipaca: quick question about 5176 - this need to be reworked to just do a net.Dial() - is that correct? and also a new api command?
<Chipaca> mvo: I understand that for some of them, yes
<Chipaca> mvo: but not for all
<Chipaca> mvo: the 'get the details and check the cdn' thing is still full http
<Chipaca> so really just the auth check
<mvo> Chipaca: ok
<Chipaca> mvo: and one of the auth checks needs dropping entirely
<mvo> Chipaca: do you have any thoughts about the API to use? apparently /v2/debug is out
<pedronis> mvo: we need to discuss,  I think it could go in some for under system-info
<pedronis> inventing tons of new api is not sane either
<pedronis> I think
<Chipaca> mvo: so... I'd either like to add a system-info command that better mapped /v2/system-info, with options of all sorts
<Chipaca> mvo: or, maybe, have version grow options
<pedronis> Chipaca: yes, that was my proposoal
<Chipaca> the second one feels weird
<pedronis> but didn't discuss it with Gustavo
<pedronis> is in a note in the PR
<pedronis> s/note/commnet/
<Chipaca> and then, whatever the command, i think a /v2/system-info option would be best for this and the verbose sandboxing thing
<Chipaca> sandbox-features i mean
<pedronis> that one landed already though
<pedronis> but maybe it's in .33 ?
<Chipaca> e.g. /v2/system-info?select=connectivity and /v2/system-info?select=sandbox-features
<Chipaca> yep, landed, but could be hidden and deprecated
 * pedronis needs to go have lunch
<mvo> 2.33 is not released outside of beta yet so that should be fine
<pedronis> mvo: anyway we should have a chat at standup about this
<mvo> pedronis: ok
 * pedronis lunch is a bit delayed
<pedronis> mvo: btw discussing  with Gustavo he also proposed that maybe we just continue to stick system config to "core" as key  (even if it's not there), it might work, but it might mean disallowing config on any base until we have understand more/have a use case
<mvo> pedronis: oh, interessting idea
<mvo> pedronis: I was starting to look at the config once 5259 is ready (unless the concensus is that we should solve both in a single PR)
<mborzecki> what would be the easiest way to stick custom snap-exec into core? bind mount my local copy over the real one?
<mvo> mborzecki: for testing? yeah, bind mount sounds like the easiest option
<mborzecki> mvo: yup for testing only
<mvo> mborzecki: yeah, manual testing should be fine this way. alternative you can unpack the core snap and repack it
<mvo> (but no need I think)
<mborzecki> i actually make the tmpfs for /snap work somehow, snap-exec is the last bit standing in the way
<pstolowski> ugh, unit test error on debian-9-64:tests/unit/go in master, on undo hooks test; i'm looking at it
<mup> PR snapd#5252 closed: store, jsonutil: move store.getStructFields to jsonutil.StructFields <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5252>
<mup> PR snapd#5264 opened: many: use ~/.config/snap if it exists, instead of ~/.snap <Created by chipaca> <https://github.com/snapcore/snapd/pull/5264>
<Chipaca> law of preservation of the number of chipaca PRs
<mborzecki> Chipaca: you should aim for 2, no more, no less, one big one small
<mborzecki> your own rule of two
 * Chipaca checks
<Chipaca> yep, that's where I'm at
<Chipaca> now if we all did this, we'd be *fine*
<pedronis> mborzecki: afair  Gustavo explicitly said he expected to force the dir to always exist, not to use a tmpfs (that might be an issue on systems not having /snap though)
<mborzecki> pedronis: the /snap/<snap-name> dir?
<pedronis> yes
<mborzecki> ack
 * Chipaca lunches
<zyga> mborzecki: hey, would you mind reviewing 5254?
<pstolowski> fyi, my isp seems to be experiencing a major outage, even their own website is down and their phone is completely busy right now
<zyga> pstolowski: orange?
<pstolowski> zyga: awacom, a local provider
<zyga> ah
<zyga> wired network?
<pstolowski> Yes
<mvo> 5225 needs a second review, should be simple
 * zyga looks
<zyga> mvo: are we putting snapfuse on PATH?
<mvo> zyga: yes and iirc we have to so that fuse finds it
<Chipaca> mborzecki: The proposed constrains <- constraints
<Chipaca> mborzecki: and I'd expect to be able to know the local key from inside the snap, as a debugging aid if nothing more
<Chipaca> hm, i'll repeat this on the forum
 * pstolowski back online
<mborzecki> Chipaca: please do
<mup> PR snapd#5225 closed: selftest: add new selftest package that tests squashfs mounting <Squash-merge> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5225>
<mvo> zyga: was 5225 a squash merge or a regular one?
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/5260/files needs a 2nd review and is pretty simple
<zyga> mvo: I don't know, whatever was default on my system :/
<mup> PR #5260: sefltest: advise reboot into 4.4 on trusty running 3.13 <Created by zyga> <https://github.com/snapcore/snapd/pull/5260>
<zyga> probably regular
<zyga> do you need a cherry pick ?
<mvo> zyga: ok, I will do some cherry picks then
<mvo> zyga: yeah, I want this for 2.33 as it may help with the protocol problem issues we see on errors.u.c
<zyga> mvo: hold on, we can revert
<zyga> and squash
<zyga> shall I try?
<mvo> zyga: its ok, its not that many commits
<zyga> I'm sorry, I just read the diff and didn't noice the squash label
<mvo> zyga: no worries
<Chipaca> zyga: don't forget the 360 fun
<zyga> Chipaca: already done it
<zyga> oops
<zyga> I will skip standup today
<mup> PR snapd#5265 opened:  selftest: add new selftest package that tests squashfs mounting (2.33) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5265>
<zyga> I actually should file the day as off as I wasn't of much use (doctor visit)
<Chipaca> zyga: hmmm!
 * Chipaca scribbles in his little black book
<zyga> my daughter is returning from overnight school trip
<zyga> and I need to pick her up in 20 minutes
<sil2100> mvo: hey! Hope that you don't mind that to save you some time after I review some smaller merges from you and approve, I'll also merge them?
<mvo> sil2100: sounds great
<sil2100> mvo: also, my work hours will be a bit strange this week as my team is in Portland
<mvo> sil2100: aha, right. the sprint
<mvo> sil2100: have fun, I understand that you will be less available during the sprint
<sil2100> So I'm working in the morning and then to be with them on all the meetings I'm sticking around till after midnight
<zyga> sil2100: Portland sounds just like Poland, there was a joke about that somewhere ;)
<sil2100> (since I stayed home)
<mvo> sil2100: ok
<sil2100> zyga: almost like home!
<zyga> Chipaca: some comments on 5264
<mborzecki> Chipaca: SNAP_HKEY_LOCAL_MACHINE and we're ready for being bought by MS
<Chipaca> mborzecki: \o/
<pstolowski> :)
<zyga> mborzecki: you will implement snapd active directory integration
<zyga> and local group policy
 * sil2100 AFK for a bit, will try to be back for standup
<Chipaca> As part of that  effort, I'll implement counting the dosh
<zyga> dosh?
<Chipaca> zyga: money
<mborzecki> zyga: i can do the LDAP login bits, leave the rest for you :P
<zyga> Chipaca: cash++
<Son_Goku> nooooo!
 * Son_Goku runs away from the insanity
 * zyga observes Son_Goku run around in a room where all walls are plastered with big-brand company names
 * Son_Goku runs screaming with his eyes bugging out
<Chipaca> also we need to move from squashfs to that filesystem that was actually just ms's sql
 * Son_Goku dies
<mborzecki> Chipaca: the one that never made its way to windows?
<Son_Goku> WinFS
<Son_Goku> https://en.wikipedia.org/wiki/WinFS
<Son_Goku> DBaaFS
 * zyga goes to pick up his daughter
<zyga> mvo: I'm skipping standup, sorry
<mvo> zyga: ok
<mvo> zyga: (fun fact right next to ok (if you shift one row to the right): pl)
<Chipaca> mvo: so you're saying pl is not ok because it's too far east
<mvo> Chipaca: the opposite, its very ok, spelled ok one column on the keyboard to the east actually
<Chipaca> mvo: if you want ok, but you're from the far right, you get pl
<Chipaca> mvo: got it
<mup> PR snapd#5266 opened: interfaces/builtin/docker: use commonInterface over specific struct <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5266>
<mup> PR snapd#5264 closed: many: use ~/.config/snap if it exists, instead of ~/.snap <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/5264>
<mup> PR snapd#5260 closed: sefltest: advise reboot into 4.4 on trusty running 3.13 <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5260>
<mborzecki> pstolowski: is this something you are looking into https://paste.ubuntu.com/p/qkNvVZcZZ6/ ?
<pstolowski> mborzecki: yes!
<mborzecki> ack
<pstolowski> mborzecki: where do you see it?
<mborzecki> pstolowski: saw it here https://github.com/snapcore/snapd/pull/5256 (restarted the build already)
<mup> PR #5256: cmd/libsnap-confine-private: helper for extracting store snap name from local-name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5256>
<pstolowski> mborzecki: debian or something else?
<mborzecki> pstolowski: ubuntu-16.04-32
<Chipaca> https://github.com/snapcore/snapd/pull/5266 seems wrong to me, but I don't know enough to explain (or even count) the ways
<mup> PR #5266: interfaces/builtin/docker: use commonInterface over specific struct <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5266>
<pstolowski> mborzecki: ah, ok. that's good i guess
<Chipaca> probably a zyga or jdstrand thing ^^
 * zyga looks
<Trel> I had one question after continuing to read up on this, what interfaces need to be request for access to dotfiles in a user's home directory?
<zyga> done
<zyga> Trel: there's no generic interface for all of them
<zyga> Trel: which dot files are you after, specifically?
<zyga> https://github.com/snapcore/snapd/pull/5230 needs a second review
<mup> PR #5230: interfaces/udisks2: also implement implicit classic slot <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5230>
<Trel> In this case the ability to write new dotfiles to a user's home directory (or another they specify) as well as read ones that are already there, specifically .profile and .bashrc
<Trel> maybe also .bash_profile
<Trel> I saw "home" gives homedir access, but not to hidden files
<zyga> Trel: there is no interface for that
<zyga> because that is very dangerous
<zyga> you can use it to essentially bypass confinement
<zyga> why do you need to write to bash/sh profile files?
<Trel> I'm assuming because of . and ..?
<Trel> In this case, I was thinking of converting my new machine/account setup script(s) to a snap
<Trel> Part of it is adding my standard dotfiles like .vimrc, adding to my PATH and adding some bits to .profile and .bashrc
<zyga> because any interface that would allow this is pretty much equivalent to becoming unconfined it would not be something we hand out easily
<zyga> I would instead suggest to rework the application to show how to add anything to one's profile scripts
<zyga> part of the appeal of snaps is that they don't have real root/superpower over one's machine anymore
<zyga> and we don't want to break the trust by creating an interface that can be easily abused
<zyga> even if the intentions were pristine
<Trel> I'm a confused about other than the .. directory entry, how accessing dotfiles in user's home is dangerous to anything other than the user
<Trel> Or is that the reason why?
<zyga> Trel: let me explain
<zyga> Trel: if you can write to ~/.profile
<zyga> then you can insert a payload that runs the next time a terminal is open
<zyga> (or the next time any login shell starts)
<zyga> that code is no longer confined so it could, for instance, wget a script from somewhere
<zyga> and pipe it to sh
<zyga> and that can do anything
<zyga> so this is effectively a way to break out of the sandbox
<Trel> Still restricted to that user's permissions though, right? That doesn't get you root access for example
<zyga> no, but you can steal user's secrets, install malware, exploit a kernel issue to become root or anything else
<zyga> (malware doesn't have to be root)
<Trel> Yes, I meant full system compromise vs user compromise is all
<Trel> I suppose I could have it generate a finalize script and drop it in their home that they'd have to run after manually.
<Trel> In this case it's for my use primarily to expidite new setups, so I'd trust it since I wrote it.
<zyga> right
<zyga> well,  you can always make a private devmode snap
<zyga> but if you want to ship it to everyone you need to play by the sandbox rules
<Trel> That's not something that'd be depreciated right?  I have no problem using devmode for this since it's primarily personal.  I'd distribute manually to anyone (non-me) who'd want it
<niemeyer> sergiusens: I won't be around at that time today.. can we have it right now?
<niemeyer> Otherwise it'll probably be too late for Evan
<zyga> Trel: I don't think devmode for private snaps is something that is going to become deprecated
<sergiusens> niemeyer: I set it for tomorrow, it is 7am for kyrofa_ right now
<sergiusens> starting next week, it is on Tuesdays,
<niemeyer> sergiusens: Ah, that works, thanks
<sergiusens> does that work niemeyer or should I reschedule?
<sergiusens> ah, great :-)
<sergiusens> I had an issue yesterday with family and scheduling the meeting earlier flew by me, sorry for that
<Trel> Then I guess that's fine for this one then.  Most of the others I wanted to do are simple text transforms which I have to pipe text into, so I don't think those would need anything at all
<Trel> I'm thinking of bundling a bunch of the text transforms into a single one and publishing that.
<mup> PR snapd#5262 closed: tests: backport lxd force stop and econnreset fixes (2.33) <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5262>
<zyga> mborzecki: thank you for the review
<sergiusens> Chipaca: what's the progress on getting the snap command split out and ported over for us to use for `snap pack`?
 * zyga -> lunch
<Chipaca> sergiusens: "ported over"?
<Chipaca> sergiusens: snap pack has had --check-skeleton for a while now (i thought you'd reviewed that?)
<Chipaca> sergiusens: we haven't split it into its own .deb yet though
<sergiusens> Chipaca: I had not reviewed AFAIK. We only discussed early March. "ported over", we currently support `snapcraft pack` on osx (and windows)
<sergiusens> Chipaca: yeah, I cannot really use it until it is standalone
<Chipaca> sergiusens: sorry, getting mixed messages
<Chipaca> sergiusens: you wouldn't use the .deb on windows nor osx
<Chipaca> sergiusens: so as far as those are concerned, it's unclear to me what you need
<Chipaca> sergiusens: there are no code changes afaik to make it standalone, unless i'm misremembering
<Chipaca> it's just packaging
<sergiusens> Chipaca: let me state the requirement so I don't impose how you deliver it; I the `snap pack` to be runnable on Windows, OSX and Linux
<Chipaca> sergiusens: ok. Done!
<sergiusens> just tell me how to get it on each platform and we are good :-)
<Chipaca> sergiusens: I don't have access to those platforms, but I assume you do. Do you have a go build env?
<mvo> Chipaca: I did the changes as discussed in the standup to connectivity check, what about authConnCheck() - should this become a net.Dial() only check? if so I will delete a lot of code now
<Chipaca> sergiusens: I seem to recall we explicitly agreed that we weren't on the hook for delivering binaries to windows and osx; if that's not correct, then we have a bunch of busywork to have that happen
<Chipaca> sergiusens: so my question is, i think, how do you get the rest of the snapcraft build environ onto windows and osx
<sergiusens> Chipaca: not immediately, no. I don't think it is as important now, but it would be a regression to not support it anymore
<sergiusens> Chipaca: `brew install snapcraft` and on windows in a venv for now
<sergiusens> brew install snapcraft is essentially a venv, just wrapped nicely into a higher order package manager
<Chipaca> sergiusens: how does 'brew install snapcraft' or the venv pull in squashfs-tools?
<sergiusens> Chipaca: https://formulae.brew.sh/formula/snapcraft
<Chipaca> sergiusens: and that builds mksquashfs from source?
<sergiusens> Chipaca: it is easy to create a formula for the snap command, I can scaffold it and get the first version if you promise to maintain it ;)
<sergiusens> Chipaca: only on "upload", you would get it in what homebrew calls a "bottle"
<Chipaca> sergiusens: if by "it" you mean the formula or whatnot, that's exactly what I'm trying to understand who owns it
<sergiusens> which is like a wheel in python
<sergiusens> Chipaca: https://github.com/Homebrew/homebrew-core/blob/master/Formula/snapcraft.rb
<Pharaoh_Atem> brew formulae are similar to rpm specs or Arch PKGBUILDs
<mvo> Chipaca: did my earlier question get lost? or are you just busy?
<Pharaoh_Atem> main difference is that unlike the latter two, formulae are based on Ruby rather than shell
<mvo> Chipaca: (busy is fine, just asking to ensure its not lost)
<Chipaca> mvo: I'm trying to understand if we're on the hook for windows and osx binaries of snap and the surrounding build infra or not
<Chipaca> I wouldn't even start to hazard a guess at how to integrate that with our CI
<Pharaoh_Atem> Chipaca: you are probably not
<sergiusens> Chipaca: I own the snapcraft formula (maintain it), someone else the squash one. Once there is a snap command on homebrew I can replace the squashfs in "depends_on" to whatever the snap thing is called.
<mvo> Chipaca: hm,hm,we will need a minimal snap pack in this case, we use too much syscall imports right now for GOOS=windows (but you know this already :)
<sergiusens> Chipaca: alternatively, I can condition the code to just use the snap command on Linux and fallback to mksquashfs on other OS
<Pharaoh_Atem> sergiusens: it'd be simpler to just test for the /usr/bin/snap command, and if it doesn't exist, always fall back
<sergiusens> Pharaoh_Atem: yeah, an actual call with parameter checks to be honest as the `snap` command namespace is quite busy ;-)
<sergiusens> there is no `snap` formula yet at least
<Chipaca> mvo: yes, authConnCheck should be a single net.Dial to the macaroon endpoint
<Chipaca> sergiusens: do you know how to build things for osx and windows from travis?
 * Chipaca googles
<sergiusens> Chipaca: look at our .travis.yml and appveyor.yaml
<mup> PR snapd#5267 opened: tests: retry 'restarting into..' match in the snap-confine-from-core test <Created by stolowski> <https://github.com/snapcore/snapd/pull/5267>
<morphis> mvo: ping
<Chipaca> sergiusens: ok, i'll take a stab at it
<mvo> morphis: pon
<mvo> morphis: h
<mvo> morphis: pong
<mvo> Chipaca: I updated the PR in question fwiw, but no rush
<mvo> zyga: do you think you could look at 5204 again?
<mvo> zyga: you asked for changes and I think I addressed things now
<zyga> Chipaca: sure
 * zyga looks
<morphis> mvo: I tried to create a base snap recently and wanted to check if I was running into a bug or if what I was trying to do is simply not supported yet
<morphis> mvo: basically I was setting `type: base` in my snap, build it and then installed it
<morphis> however after running $ snap run --shell snap.app I was still seeing the core snap mounted on /
<zyga> morphis: we didn't anticipate bases with apps so bases use core for their apps
<zyga> (which is odd)
<morphis> isn't that the core principle of a base?
<zyga> morphis: no, the principle of bases (so far) is to host other snaps
<zyga> not saying that it's a bad idea
<zyga> but it is something we didn't anticipate
<zyga> that's all
<morphis> isn't that what ubuntu-core will require snapd to do?
<zyga> I don't understand, can you rephrase please?
<zyga> snapd won't ship any apps either
<zyga> (in the sense of snap declared apps)
<morphis> in terms of ubuntu-core core18 will be a base snap, right?
<zyga> yes
<zyga> but it won't have apps or services
<morphis> none which are exposed through the snap, right
<morphis> but something still has to provide systemd which is handled by the initramfs mounting core18 as / and running systemd outside of a snap environment
<zyga> yes, that is whatever has booted, my only point is that snap applications from bases were unanticipated
<zyga> it's a bug
<zyga> but we need to think what it means if we allow it
<morphis> so basically snapd ignores all apps defined in a base snap, correct?
<zyga> I don't think it does
<zyga> Chipaca: ^ does it
<Chipaca> hmmmm
<zyga> I think we need to decide if we should ignore all apps / hooks or if we should handle them consistently with the same snap used as base
<Chipaca> I'd have to check, as I don't remember offhand, but it's quite possible there's an "if snap.type is app"
<morphis> I saw the apps exported as I could do `$ snap run --shell snap.app`
<zyga> mvo: review on 5204
<morphis> Chipaca, zyga: let me get that base snap back installed and try again
<zyga>  morphis can you open a thread about this
<Chipaca> morphis: it's also possible there _isn't_ one
<zyga> so that we don't forget
<morphis> zyga: sure
<zyga> I think it's a valid use case
<zyga> but I want to be formal about it
<zyga> my gut feeling is that bases _must_ use themselves as base
<zyga> I need to walk my dog quickly, 15 min AFK
<morphis> zyga: if they don't I see weird things happening
<morphis> what if a fedora base snap has an app defined which then is executed against the Ubuntu core snap
<zyga> Yeah
<zyga> I agree
<Chipaca> graaaahgh
<Chipaca> I think I'm going to start from the other end, and move stuff around for pack, instead of trying to make osutil build everywhere
 * Chipaca gets more tea
<morphis> zyga: Chipaca: but thanks for the insights
<morphis> zyga, Chipaca: ok, both services and apps work when `type: base` is set, however my base is more or less Ubuntu 16.04 as its more or less an app snap relabeled as a base
<mup> PR snapd#5268 opened: tests: fix flaky test for hooks undo <Critical> <Simple> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5268>
<pstolowski> zyga, mvo ^ a trivial that should fix flaky test that we currently have
<zyga> Thank you :-)
<pstolowski> zyga: thanks for review, I enhanced the description, hope it makes more sense
<mvo> pstolowski: nice
<pstolowski> cachio: addressed your suggestion re #5267
<mup> PR #5267: tests: retry 'restarting into..' match in the snap-confine-from-core test <Created by stolowski> <https://github.com/snapcore/snapd/pull/5267>
<pstolowski> mvo, zyga ^ and that's another trivial re flaky tests
<mvo> morphis: sorry, had to step out for a bit, that sounds like something to discuss in the forum, I'm not against having apps for bases but we need to discuss this at least with gustavo
<zyga> Ok
<mvo> zyga: re review> $< iirc only takes the first "dependency" of a make rule
<zyga> yes, did I suggest that?
<zyga> I meant $^
<zyga> sorry
<mvo> zyga: aha, sure
 * zyga tea and fixing branches
<mvo> zyga: thanks for the review, I will think about the name a bit over dinner (snapd.manager, snapd.entrypoint, snapd.run-from-snapd, snapd.start-me-up, ...) ideas welcome :)
<zyga> snapd.stargate
<zyga> snapd.snapd.snapd
<zyga> snapd.make-it-so
<zyga> snapd.startup
<zyga> maybe just snapd.run-from-snapd-snap
<morphis> mvo: thanks! I will open a forum topic tomorrow
<mup> PR snapcraft#2157 opened: nodejs plugin: update to the latest 6.x LTS point release <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2157>
<mvo> zyga: updated, thanks for your suggestions
<zyga> Super, i will check in a sec, finishing my supper
<zyga> Which name did you pick?
<mvo> pedronis: just to double check - we can kill authConnCheck entirely?
<mvo> zyga: your suggestion from earlier: snapd.run-from-snap
<pedronis> mvo: afaiu yes,   all those bits are activate/relevant only on "snap login"
<zyga> +1
<pedronis> *activated
<mvo> pedronis: great, less code is always better. I removed those bits now
<zyga> mvo: review on 5204
<cachio> zyga, https://paste.ubuntu.com/p/tqghBCHfb6/
<cachio> any idea why the configure hook is giving me this?
<alphawarrior> Hello everyone. Can I update snapcraft from an older version using itself? I'm on gentoo and the "latest" package linked by the snapcraft tutorial on installing only has a 2 year old version :(
<nacc> alphawarrior: snapcraft is itself available as a snap
<alphawarrior> oh thanks ^^
<jzzz> Hello. I'm having trouble getting new vanilla canonical kubernetes installed into lxd containers on my ubuntu host to come back up after a restart. Wondering if anyone might be able to help me. The error msgs seem to point towards apparmor/snap.
<jzzz> I'm thinking apparmor/snap is the root cause because `dmesg` shows entries like `[90947.819924] audit: type=1400 audit(1528228545.536:2983): apparmor="DENIED" operation="change_onexec" info="label not found" error=-2 profile="/usr/lib/snapd/snap-confine" name="snap-update-ns.kube-apiserver" pid=24205 comm="snap-confine"`
<zyga> Iâm afk but I will check it out soon
<jzzz> with snap-update-ns errors for kube-apiserver and etcd, and similar snap.kubelet.kubelet errors.
<jzzz> thx @zyga. pls let me know whatever I can do on my system for more clues.
<zyga> Ack
<jzzz> the stacktrace from `juju debug-log` looks like it might be kicking off a subprocess that is running a sanity check command (giving back the version) to determine that the service is installed in the container. Here's a pastebin: https://pastebin.com/60VR7gSi
<jzzz> so I'm not sure if the apparmor/snap error is a cause or a symptom. :\
<jzzz> ``` $ uname -r 4.4.0-127-generic  $ lsb_release -a  No LSB modules are available. Distributor ID: Ubuntu Description:    Ubuntu 16.04.4 LTS Release:        16.04 Codename:       xenial ```
<mup> PR snapd#5265 closed:  selftest: add new selftest package that tests squashfs mounting (2.33) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5265>
<cachio> niemeyer, hey, did you see this https://travis-ci.org/snapcore/snapd/builds/388466179 ?
<Luke> hey guys, is there a recommended way for dealing with creating and using multiple users within a single snap? For example, nginx + pgsql + the app all being on different users?
<mup> PR snapd#5269 opened: systemd: adjust TestWriteMountUnitForDirs() to use squashfs.MockUseFuse(false) <Simple> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5269>
<jdstrand> Luke: not yet. you probably want to follow https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461
<Luke> jdstrand: thanks!
<Luke> jdstrand: this is the perfect answer to my question. thanks for taking the time to write this up
<jdstrand> Luke: np. it is roadmapped and getting closer to implementing, but it'll be a little while yet
<Luke> jdstrand: I think with this post I can work my way around it without too much compromise
<jdstrand> cool
<zyga> re
<niemeyer> cachio: No, fix is due
<zyga> jdstrand: can you have another look at 5254 please, I'm still pondering one aspect (has suffix check) but I think I addressed all the points you have raised
#snappy 2018-06-06
<cachio> niemeyer, I am running with -vv trying to reproduce the error locally
<cachio> let's see if it give us more information about the response which is causing that
<tismith> Hi guys - I'm trying to build a rust program using snap craft, and the rust plugin is working ... sort of, but when I do a 'snapcraft clean build' I have trouble with cargo not finding rustc
<tismith> The build log is here: https://build.snapcraft.io/user/tismith/device-checkout-rs/239825
<tismith> it looks like it's a problem with the rust plugin, but if so, I'm wondering why I'm hitting it and seemingly no-one else
<tismith> I've also posted this to the forum: https://forum.snapcraft.io/t/problem-building-rust-based-snap/5776
<mborzecki> morning
<alphawarrior> Hello everyone. I have some ancient old snapcraft installed on my gentoo and I can't upgrade with (snap install snapcraft) as it fails with Mount snap "snapcraft" (1594) (info failed to parse: invalid confinement type: "classic". How could I upgrade the confinement app?
<mup> PR snapd#5204 closed: data: add helper that can generate/start/stop the snapd service <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5204>
<mup> PR snapd#5269 closed: systemd: adjust TestWriteMountUnitForDirs() to use squashfs.MockUseFuse(false) <Simple> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5269>
<mup> PR snapd#5267 closed: tests: retry 'restarting into..' match in the snap-confine-from-core test <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5267>
<mvo> mborzecki: hey, whats the status of 5030? should this be labeled blocked, i.e. is it waiting for input from e.g. neal?
<zyga> good morning
 * zyga overslept 
<pstolowski> morning
<mvo> hey zyga and pstolowski
<mborzecki> pstolowski: zyga: hey
<mborzecki> gitlab continues playing bad-MS card https://about.gitlab.com/2018/06/05/gitlab-ultimate-and-gold-free-for-education-and-open-source/
<jamesh> zyga: hi.  Is there anything more you'd want on https://github.com/snapcore/snapd/pull/5184 ?
<mup> PR #5184: interfaces: add {contacts,calendar}-service interfaces <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5184>
<zyga> jamesh: no, it looks good now, I will approve it
<jamesh> zyga: thanks
<jamesh> zyga: it has niemeyer's interface name changes in now, so I don't think it needs to go back to him
<zyga> I agree
<zyga> and really, thank you for this work :)
<mup> PR snapd#5184 closed: interfaces: add {contacts,calendar}-service interfaces <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5184>
<zyga> https://github.com/snapcore/snapd/pull/5268 needs a 2nd review and is marked as critical
<mup> PR #5268: tests: fix flaky test for hooks undo <Critical> <Simple> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5268>
<pstolowski> #5268 needs second review, it's a trivial
<mup> PR #5268: tests: fix flaky test for hooks undo <Critical> <Simple> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5268>
<Chipaca> pstolowski: I'm looking at 5268
<Chipaca> pstolowski: I don't understand the change
<Chipaca> pstolowski: (good morning!)
 * zyga is not the only one then
<zyga> Chipaca: I think looking at broader context helps
<Chipaca> I'm looking at the whole file
<Chipaca> still don't get it :-)
<pstolowski> Chipaca: see the description. the test was adding things to s.change and s.task, but TestSetup adds configure hook
<pstolowski> the test doesn't account for configure hook
<pstolowski> it's not linked to other tasks created by the test itself
<Chipaca> pstolowski: you can't get the configure hook task?
<zyga> mborzecki: what is the term that we want to use for snap name with possibly an instance name?
<zyga> mborzecki: surely not snap name
<pstolowski> Chipaca: i don't need configure, i don't care about it for this test
<mborzecki> zyga: heh, i'm using InstanceName and StoreName now
<zyga> hello-world_demo
<mborzecki> the PR i proposed used LocalName and StoreName
<zyga> is that an instance name or a store name?
<mborzecki> hello-world_foo -> instance/local name
<mborzecki> hello-world -> store name
<zyga> and foo?
<zyga> :)
<mborzecki> again, in the PR i proposed it was LocalKey, now it's InstanceKey
<zyga> will you adjust the snap-confine PR as well?
<zyga> I'm happy with instance key
<zyga> store name
<zyga> and ... local name (or is that instance)
<zyga> as long as we are consistent
<mborzecki> s-c PR is using sc_snap_drop_instance_name (maybe it should be key?)
<zyga> I made some comments there too, please look
<zyga> so if you adjust please let's keep the terminology
<zyga> and before it sinks in, document the terminology in the function description please
<mborzecki> zyga: can you take a look at https://forum.snapcraft.io/t/parallel-snap-installs/5763 ? it's using 'local name' and 'local key'
<mborzecki> and it's based on the notes we took during the sprint
<mborzecki> i'll be updating the post as we come to agreements on the naming and stuff :)
<zyga> ack
<mborzecki> zyga: just to be sure, the paths in apparmor profiles are all mount-ns local right?
<zyga> ish
<zyga> it's more complicated
<zyga> they are local to the namespace because we pivot root
<Chipaca> robert_ancell: morning sir
<mborzecki> 'it's complicated' ;)
<zyga> so you can think about it as such
<mborzecki> ack
<zyga> but I don't know if this is just apparmor not knowing about pivot root
<zyga> or apparmor handling pivot root in this specific way
<Chipaca> robert_ancell: is it Bluefin you're at this week? I can go in _today_
<Chipaca> no afternoon school run, suddenly
<mborzecki> zyga: i'm asking cause the profiles will be referencing store-name, while we bind mount the local-name on top of it
<zyga> for this purpose yes, you can think of the paths as those that are visible inside the mount namespace
<robert_ancell> Chipaca, I am in Bluefin!
<Chipaca> robert_ancell: would me going in make sense? right now, or after lunch?
<robert_ancell> Chipaca, we're in the middle of a design process - so you could come in if you want to be involved
<Chipaca> robert_ancell: i'm too much of a chicken (in the chicken-and-pigs sense) for that, i suspect
<Chipaca> sounds fun though :-)
<mup> PR snapd#5268 closed: tests: fix flaky test for hooks undo <Critical> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5268>
<mvo> Chipaca: did we ever discuss client/packages.go:Snap.Developer ? the daemon/snaps.go code assigns the publisher to it
<mvo> Chipaca: so now I wonder how to describe what we do in the new l`snap list --format=help`
<Chipaca> mvo: note there isn't a 'publisher' field
<mvo> Chipaca: I wonder if a) I should use something neutral like owner b) remove the help and add Snap.Publisher c) something else
<mvo> Chipaca: yeah, I noticed that too :)
<Chipaca> mvo: it gets more fun
<Chipaca> mvo: because the snap.Info.Publisher is set from the store's Developer
<mvo> Chipaca: meh, I remember trying to untangle this and failing badly
<mvo> Chipaca: I think I go with something neutral then for now
<mvo> Chipaca: I also vaguely remember that once the new api is available things could be untangled(?)
<zyga> caretaker
<robert_ancell> Chipaca, you should come in though!
<pedronis> they untangled in the server yes, there's is only publisher
<mvo> zyga: The name of a ca\
<mvo> retake of the snap"
<Chipaca> mvo: in the current details api, 'origin' is the developer username, 'publisher' is the developer's display name, and developer_id is noise
<mvo> pedronis: nice
<pedronis> Chipaca: mvo: we discussed a bit about with Gustavo as well, I think for a while we want both Developer and Publisher in our own API
<zyga> Chipaca: noise owns all the snaps ;)
<pedronis> Chipaca: an to rename the list header in snap list to publisher
<pedronis> Chipaca: mvo: bit of a question, is the timing of this
<Chipaca> mvo: in the next-gen details api :) 'publisher' is an object, with username,  id, and display-name
<mvo> pedronis: so we would have client:Snap.{Developer,Publisher} and both would set to the correct value?
<mvo> Chipaca: oh, ok
<pedronis> mvo: they would be set to the same value for a while
<Chipaca> mvo: let's not touch the client api for a bit please?
<pedronis> we really don't have uploaders in the api
<pedronis> so far
<Chipaca> mvo: i need to move us to the v2 info api
<mvo> pedronis: would it hurt if I add "Publisher" to client now?
<mvo> Chipaca: meh, ok
<Chipaca> mvo: so any change now will need to get reworked
<pedronis> mvo: no, but best to double check again with Gustavo
<Chipaca> and you risk going in the wrong direction :-)
<mvo> Chipaca: I was thinking if I add "Publisher" and only expose help there things would improve
<Chipaca> mvo: ah, this is for --format?
<Chipaca> hmm hmmmm
<mvo> Chipaca: mostly
<Chipaca> this is more user-facing than the client api
<mvo> Chipaca: I mean, I think it would be a good idea in general
<mvo> Chipaca: but I am touching it because of --format
<pedronis> as I said  the column itself s/Developer/Publisher/  afaict
<pedronis> from discussion
<Chipaca> right, but having the client api have both for compatibility is fine; having both in the user-facing world is ugly
<mvo> Chipaca: i.e. no helper for "Developer" (so its not displayed via format=help) and publisher with help and the right values
<Chipaca> ok, let's do the other thing and change it to be Publisher everywhere that's user-facing?
<mvo> pedronis: s/Developer/Publisher/ in the column is something I can do in the same go
<Chipaca> robert_ancell: I'll go in, to be there around noon.
<mvo> Chipaca: ok, sounds good. I can prepare a tiny PR for this
<Chipaca> robert_ancell: the gods of trains willing
<Chipaca> mvo: pedronis: sounds good
<Chipaca> mvo: tag me on the PR, if it's not the format one
<mvo> Chipaca: will do, I will do it as a separate one for easier review
<Chipaca> ok
<Chipaca> I'm off for a while, will bbl
<mvo> Chipaca: see you
<mup> PR snapd#4917 closed: repo: added repo ConnectionsInfo method (for the new snap connections API) <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/4917>
<mup> PR snapd#5270 opened: snap,client: Show "publisher" in `snap list` and expose in client API <Created by mvo5> <https://github.com/snapcore/snapd/pull/5270>
<mvo> pedronis: good morning - do you have an opinion on 5259 at this point? should I work on the "core" config handling as part of this PR or in a followup?
<pedronis> mvo: well, as it is it will use snapd which we said is not what we want initially, so I think it might need a prequel more than a follow up
<pedronis> mvo:  the prequel should make snapd a synonym of core like system for config, and block doing config on bases
<pedronis> mvo: unless I'm confused there's a bit of stuff we don't need if we continue hanging config on "core" in 5259 atm
<pedronis> mvo: not sure it makes sense to land it to remove it again
<pedronis> mvo: it's also relatively small so you could do everything there, but I wouldn't land it as is
<mvo> pedronis: thank you! I will do a prequel then first. was mostly wondering because I'm exploring creating spread images which of course need firstboot support but I agree the order you have in mind makes more sense
<mborzecki> zyga: pushed changes to #5256
<zyga> ack
<mup> PR #5256: cmd/libsnap-confine-private: helper for extracting store snap name from local-name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5256>
<zyga> mvo: failure on #5270
<mup> PR #5270: snap,client: Show "publisher" in `snap list` and expose in client API <Created by mvo5> <https://github.com/snapcore/snapd/pull/5270>
<mvo> zyga: thank you, looking
<mvo> zyga: aha, I think we have a bunch of spread tests
<mup> PR snapd#5256 closed: cmd/libsnap-confine-private: helper for extracting store snap name from local-name <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5256>
<abeato> mvo, hey, I have created https://forum.snapcraft.io/t/denials-when-opening-libraries-appear-after-snapcraft-change/5783 , I would appreciate if you can take a quick look
<morphis_> zyga, mvo: https://forum.snapcraft.io/t/base-snaps-with-defined-applications/5784
<zyga> thanks
<morphis_> I left it pretty generic but can detail my use case if needed
<zyga> commented on the forum, thanks for starting this
<mvo> abeato: thank you, I suspect that snapcraft did some patchelf magic to set the rpath in your binary
<abeato> dough!
<mvo> abeato: this is a regular snap, right? not classic or anything
<abeato> mvo, yes, a confined one
<mvo> abeato: iirc there is an option to disable it, let me quickly check
<mvo> abeato: I mean there is an option to disable patchelf
<abeato> sure
<mvo> abeato: please try: parts:\n part-name:\n  build-attributes: [no-patchelf]"
<mvo> abeato: I will also reply in the forum for reference
<abeato> mvo, thanks! so, which is the rationale for using patchelf? should not be *not* using it the default?
<mvo> abeato: I don't know, sorry. thats probablay a question for sergio. can you quickly quick with "objdump -x /path/to/your/binary | grep RPATH?
<mborzecki> github having a hard time?
<mvo> abeato: or readself -d
<mvo> mborzecki: yeah, for me as well
<zyga> mvo, abeato: the snapcraft team have requested that all questions go to the forum
<zyga> please ask your question there abeato
<zyga> it will both allow snapcraft team members to respond when they are around (different timezone) and make the question useful to others that may search for it
<mvo> mborzecki: I will avoid comments about prematurely  moving the servers to windows nt
<mborzecki> mvo: yeah, just restarted the travis job on master branch :/
<zyga> mvo: windows NT is very efficient if you use less than 10 files
<mborzecki> mvo: i wouldn't mind winnt, unless they don't use iis to host anything
<abeato> mvo, https://pastebin.canonical.com/p/zNTbNmg6gn/ there is something called $ORIGIN there
<zyga> abeato: that's defined by the ELF standard
<abeato> mvo, zyga sure, will ask in the forum, thanks
<mvo> zyga, abeato I think this is new
<zyga> abeato: http://man7.org/linux/man-pages/man8/ld.so.8.html
 * zyga needs to break to take a shower and take the dog out, bbl
<abeato> interesting...
<mvo> abeato: yeah, pretty sure this is snapcrafts patchelf magic
<mvo> abeato: anyway I replied. sorry that I'm not more helpful, Sergio (sergiusens) hopefully can tell you more about the background, i.e. why this was changed
<abeato> mvo, thanks a lot, I'll create a new post. As /snap/core was around I asked you first ;)
<mvo> abeato: heh, sure
<mvo> abeato: hm,hm, but $ORIGIN/../lib in the rpath still does not quite explain why it picked /snap/core/ - please let me know if disabling patchelf helps or if you still get the same denials
<zyga> abeato: what's the issue?
<mvo> niemeyer: is 5234 (support for dynamic list output via user provided templtaes like: snap list --format="{{.ID}}|{{.Name") something you want to review at a high level ? as its very user facing? (probably no need for an in-depth code review, just want to make sure you are happy on the high-level)
<mvo> zyga: https://forum.snapcraft.io/t/denials-when-opening-libraries-appear-after-snapcraft-change/5783/
<abeato> mvo, will let you know
<mvo> abeato: ta
<abeato> zyga, https://forum.snapcraft.io/t/denials-when-opening-libraries-appear-after-snapcraft-change/5783
<mvo> zyga: ld tries to load stuff from /snap/core/$rev/usr/lib
<mvo> zyga: and its a bit unclear where this comes from
<mvo> zyga: I mean, why this is happening, it was not happening before
<zyga> mvo: in normally confined snaps?
<mvo> zyga: correct
<zyga> abeato: what's readelf -a ?
<zyga> (pastebin that please)
<mvo> zyga: https://pastebin.canonical.com/p/zNTbNmg6gn/ is readelf -d
<abeato> zyga, https://pastebin.canonical.com/p/gW7QXgdynQ/
 * abeato has to go, back in a bit
 * zyga didn't notice this is in Spanish
<zyga> I should go back to school one day
<zyga> mvo, abeato: your pastes differ
<zyga> one has RPATH while the other does not
<zyga> in any case, neither specify /snap/core directly
<zyga> the use of /snap/core is not allowed
<zyga> apps must use the rootfs paths like /lib
<zyga> so I don't know what's causing that yet
<zyga> anyway -> walk
<zyga> thanks for the pastebins to both of you
<mvo> ppisati: I updated the bionic ppa, sorry for the delay, will reply also to the mail (after lunch). might not be published yet
<ppisati> mvo: k
<mup> PR snapd#5271 opened: [WIP] cmd: attempt to start the document portal if running with a session bus <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5271>
 * cachio afk
<mborzecki> jdstrand: travis job in 5250 is currently failing due to eperm/eaccess
<jdstrand> mborzecki: yes, I know. I'm in the process of looking at it
<jdstrand> thanks
<jdstrand> (I saw the PR comments)
<zyga> re
<zyga> jdstrand: hey, can you please look at the segment PR again
<zyga> I think it's ready and it just needs your ack
<abeato> zyga, ah, silly me, this is the real thing: https://pastebin.canonical.com/p/9tpKb52fqj/ (sorry for the locale, I think they should not translate this sort of stuff :D
<zyga> I'm still working on validation in two branches down the pipe, while on a walk I found a bug in my previous idea and I think I have (I think) the right thing that will solve all the current constraints (trespassing, tmpfs origin, squashfs, fuse) but I need to code it to try
<zyga> abeato: no worries, I understand Spanish well enough for that :)
<abeato> :)
<niemeyer> mvo: Seems reasonable.. one small concern I have is marrying with the language
<mvo> niemeyer: ok, happy to address that
<niemeyer> mvo: Maybe not so much of a practical concern
<niemeyer> mvo: The text template in Go has a nice feeling to it.. down side is we'd need to reimplement if we ever move elsewhere
<Chipaca> mvo: niemeyer: hello from bluefin
<niemeyer> Chipaca: Hey!
<Chipaca> i'm not going to make the standup today
<jdstrand> zyga: yes
<Chipaca> but i'll be syncing with gnome software and in particular robert_ancell
<zyga> jdstrand: thank you :)
<niemeyer> Chipaca: Nice, please let us know
<Chipaca> niemeyer: mvo: meanwhile I'm working on small branches to make a cross-platform snap-packer
<Chipaca> small detour :-)
<mvo> niemeyer: hm, hm, that is a fair point
<niemeyer> Chipaca: Isn't that "snap pack"?
<mvo> niemeyer: it is except that "GOOS=windows go build github.com/snapcore/snap/cmd/snap" is unhappy right now because of too much syscall. use. aiui Chipaca  build something that can be cross build more easily
<mvo> niemeyer: do you think we should limit the use of the template language, i.e. only allow {{.XXX}} as constructs?
<niemeyer> mvo: That's one possibility.. another idea might be to outsource the actual formatting by providing json
<niemeyer> About the packer, should we make a goal to not have syscall in snap itself
<niemeyer> ?
<niemeyer> Instead of having a different tool?
<niemeyer> This is the client, after all..
<mvo> niemeyer: outsource - you mean snap list would just output all json and the user deals with how to format it using something like jq?
<niemeyer> mvo: Yeah
<zyga> mvo: if we go down that path I would suggest that we add a generic way to see the raw output of API requests over CLI
<zyga> this would make sense to many query-type commands
<zyga> snap list, snap changes, snap...
<zyga> lots of them could just grow a --raw=json
<zyga> (or something appropriate)
<mvo> zyga: yeah, I'm not actually sure we need a command, then we can as well document curl --unix-socket etc (just thinking alout)
<zyga> and then instead of providing their usual output, give the raw json object on stdout
<niemeyer> zyga: Sort of.. the idea is nice, but commands also do some processing, often with multiple calls.. I wonder if we can get something sensible
<zyga> mvo: a command is more natural IMO
<zyga> niemeyer: that's true, things that poll/wait
<niemeyer> zyga: I agree with the principle that we shouldn't have to rethink the output format, though
<zyga> still, my point is that if we do the raw idea it should not be list specific, it's really nice for integration with other languages as they don't need to use glib bindings if they can just naturally process CLI output without writing a parser
<zyga> at the same time, yes, we have the socket
<zyga> but perhaps it is still nice to use a CLI (e.g. when we grow remote calls and more auth)
<mvo> niemeyer: I might also implement a trivial template engine to avoid our dependency on the (quite rich) golang templating package
<niemeyer> zyga, mvo: Maybe something in between.. we might offer an additional command that talks to the API, does some basic processing (auth, errors, etc), and otherwise offers the raw API
<zyga> niemeyer: snap json /v2/snaps/
<zyga> {...}
<niemeyer> Yeah, something along those lines
<zyga> this is also nice because it's not that suddenly you notice some commands have a --json switch and some don't i
<niemeyer> mvo: What's the use case?
<niemeyer> zyga: Yeah, literally everything is available from day one
<zyga> instead you can look at what the json command supports (e.g. via json --help)
<niemeyer> It's a nice way to play as well
<niemeyer> (and learn)
<zyga> niemeyer: and a day layer you'd have python-snaps packages or snapd-js or whatever people use
<zyga> and a zoo of things that grow on top, which is nice for ecosystem
<niemeyer> Perhaps not the zoo part, but otherwise yes :P
<mvo> niemeyer: the use case is a user request to have something like dpkg-query --format or rpm --whatever-the-option-is-called-there
<niemeyer> What are they trying to do?
<mup> PR snapcraft#2157 closed: nodejs plugin: update to the latest 6.x LTS point release <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2157>
<mvo> niemeyer: its for the sos system and it just includes the installed software (debs, snaps) as part of a support request aiui
<niemeyer> Ah, interesting
<zyga> mvo: so presumably they could just as well consume json directly
<zyga> unless it's written in shell :/
<mvo> niemeyer: "dpkg-query -W -f='${Package}|${Version}\\n' # debian" is what they are doing today
<zyga> (is it?)
<niemeyer> I see
<mvo> zyga: they can, I'm fine either way. to me it feels more user friendly to have --format={{Name}} etc. but I am biased :) learning jq is not hard, ist just one more step
<mvo> zyga: I would not be surprised if written in shell, let me see
<zyga> mvo: for users it is less friendly but for developers that integrate it is more because it unlocks more APIs
<mvo> zyga: sure, its orthogonal to some extend. in any case, I just need a decision, I can also work on the `snap json` thing
 * zyga agrees
<mvo> zyga: and I'm biased, I have grown to like the snap list --format=help and so. but thats a poor reason to not go for something better
<zyga> mvo: I think it's not a sin if we do both
<zyga> it's a client side thing anyway
<zyga> and would help people with ad-hoc scripts in shell
 * mvo nods
<niemeyer> mvo: We should at least write down how that would look like with the "snap api" call or whatever it is
<niemeyer> mvo: If it feels like a monster, that's a sign :)
<jdstrand> mborzecki: ok, I tacked on the time-control bit at the end of last week and forgot to run it through spread. I've fixed it. I'll remove the blocked tag after the tests pass (they do locally)
<mborzecki> halfway done, 38 files changed, 456 insertions(+), 293 deletions(-)  <-- that's after introducing InstanceName() & StoreName() instead of info.Name(), hopefully the review will be rather simple (albeit long)
<mup> PR snapd#4889 closed: cmd/snap-update-ns: don't trespass on host filesystem <Blocked> <Squash-merge> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4889>
<mup> PR snapd#4767 opened: interfaces: disconnect hooks <Critical> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>
<mup> PR snapd#5254 closed: cmd/snap-update-ns: discard the concept of segments <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5254>
<zyga> jdstrand: thanks, I just opened the 1st batch of error cleanups
<mup> PR snapd#5272 opened: cmd/snap-update-ns: improve wording in many errors <Created by zyga> <https://github.com/snapcore/snapd/pull/5272>
<jdstrand> np
<zyga> https://github.com/snapcore/snapd/pull/5272 is small, green and could land easily :)
<mup> PR #5272: cmd/snap-update-ns: improve wording in many errors <Created by zyga> <https://github.com/snapcore/snapd/pull/5272>
 * zyga cleaned up after lunch now 
<mborzecki> zyga: we should have 'alien' tag for those, small, green..
<zyga> hahaha
<zyga> they are _grey_
<zyga> didn't you shoot enough to know ;)
<zyga> (offtopic, x-com remake was free on GOG yesterday)
<mborzecki> zyga: yup, got it :P
<mborzecki> also bought swos, mk123, crusader and pharaoh :)
<zyga> oooh man
<zyga> I don't have time to play any games anymore
<zyga> I bought one game actually, I hope to try it this weekend
 * zyga checks
<zyga> foxtail
<zyga> it's a point-and-click game
<zyga> with lovely hand-pixelated graphics
<zyga> I'd love to write a game like that one day
<mborzecki> zyga: heh, don't have much time to play either, treating it as a reminder how games used to be :P hopefully the kids will pick it up and have as much fun as i had
<Chipaca> popey: 'snap info sudo'
<popey> wat
<Chipaca> robert_ancell: https://forum.snapcraft.io/t/spooling-old-changes/5787?u=chipaca
<mup> PR snapd#5273 opened: testutil: add test support for Fstatfs <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5273>
<zyga> popey: offtopic, could we ship atom as a snap?
<zyga> the old text mode adom
<cachio> niemeyer, about removing linode, we need to fix this https://travis-ci.org/snapcore/spread-cron/builds/388108696#L536
<cachio> niemeyer, currently we trigger from a vm the branches by doing git push
<cachio> niemeyer, then travis run the tests automatically when a change is pushed to a branch
<cachio> but, seems to be missing the google key for this project
<cachio> niemeyer, if you have the key I could update all the branches
<popey> zyga: never heard of it
<zyga> popey: it's a netback-like game that was very popular in the 90s-00s
<zyga> nethack*
<zyga> it's a single elf file that just runs
<zyga> I wonder if we can package a free but non FOSS game
<mup> PR snapd#5274 opened: configstate: deny configuration of base snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/5274>
<mvo> pedronis: in a meeting right now so maybe I don't get this straight, but I wonder if we can simply disable config on snapd as well maybe? and just use "core" everywhere for the config
<niemeyer> cachio: Ack
<niemeyer> cachio: Let's sit down together at some point to fix it
<pedronis> mvo: that's an option (keep only core/system, prohibit bases/snapd), don't know if niemeyer has opinions on that
 * zyga looks at his PR which failed on econreset 
<zyga> https://api.travis-ci.org/v3/job/388796612/log.txt
<mvo> pedronis: it might make things easier at least in the short term because the alias/unalias is a bit simple right now
<popey> zyga: got a link?
<zyga> sure, one sec
<zyga> https://www.adom.de/home/index.html in general
<zyga> but the specific binary is
<zyga> https://www.adom.de/home/download/current/adom_linux_ubuntu_64_3.0.6.tar.gz
<zyga> there's a 32 bit version (for intel) as well
<zyga> there's a graphical build as well at around 500MB
<cachio> niemeyer, ok, just ping me when you want
<cachio> niemeyer,  I am trying to reproduce the error on spread
<cachio> but no luck so far
<pedronis> mvo: it's fine for me, I think on core18 systems people should really do snap set system
<mvo> pedronis: +1
<mvo> pedronis: I will disable snapd for now and ask for a review from gustavo on this specifically (and address your points too :)
<roadmr> hey folks! how can I ask snapd to tell me which architecture the current system uses?
<zyga> hmm
<roadmr> or should I just use uname --hardware-platform for this?
<zyga> I don't think you can today
<zyga> there's some translation we do internally
<zyga> e.g. amd64 and not x86_64
<roadmr> hmm
<roadmr> at a high level what I want is to help someone determine whether their system is arm64 from snapd's point of view
<zyga> perhaps we should add "snap debug architecture"
<zyga> roadmr: just that?
<zyga> aarch64 => yes
<roadmr> https://forum.snapcraft.io/t/can-not-install-snap-app/5790 not to be mysterious about it :) I think he's just on arm64 but I asked point blank "what's your arch?" and he didn't seem to parse that
<zyga> ask for name -a
<zyga> uname -a
<roadmr> zyga: ok, I'll go that way then. Not a problem! thanks!
<Chipaca> mvo: so is --format=... not happening?
<zyga> Chipaca: can you please do a quick pass over https://github.com/snapcore/snapd/pull/5273
<mup> PR #5273: testutil: add test support for Fstatfs <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5273>
<niemeyer> cachio: The panic should give us a nice clue already.. if you restart the test in Travis, please just make sure to copy the panic elsewhere so we can have a look
<mvo> Chipaca: it looks like there is some resistance, i.e. snap list | awk can archive the use case. I'm a bit biased because I have grown to like it but in general less code is a plus (even though I think this was a particular nice pr)
<Saviq> cachio: hey, are you planning to provide ubuntu devel (18.10 today) images in the google project for spread? or are they there already?
<Chipaca> zyga: i'll try
<Chipaca> mvo: I like it as well, especially if we implement the current list as just the default format
<cachio> Saviq, we are not planning to provide them
<cachio> but the ubuntu devel project should have
<cachio> let me check
<Saviq> cachio: thanks, we've been using the latest release and `do-release-upgrade -d`, but that stopped working, was wondering if there's something quicker we may do
<cachio> Saviq, if you run > gcloud compute images list --project ubuntu-os-cloud-devel
<cachio> Saviq, daily-ubuntu-1804-bionic-v20180531
<cachio> I think this is pretty new
<Saviq> right, so ubuntu-1810 should work
<Saviq> cachio: how do I reference that in spread.yaml?
<cachio> you specify a new system, something like ubuntu-18.04-64-daily
<cachio> and then image: ubuntu-os-cloud-devel/daily-ubuntu-1804-bionic
<cachio> or ubuntu-os-cloud-devel/daily-ubuntu-1804-bionic-v20180531
<cachio> if you don't specify the -vxxxxx
<cachio> it should take the last one publish
<Saviq> ah was wondering if the FAMILY field would work
<Saviq> I'll try things out, thanks!
<cachio> Saviq, yes
<cachio> I would work
<cachio> it is better if you use the family
<Saviq> ack, thanks!
<cachio> Saviq, try this ubuntu-os-cloud-devel/ubuntu-1804-lts
<cachio> if it does not work, please let me know
<Saviq> will do
<Saviq> cachio: seems good, thanks!
<cachio> Saviq, great, just make sure the image allocated is the one you want
<Saviq> cachio: it's cosmic, that's all I need ;)
<cachio> Saviq, nice
<Saviq> it also failed to build, as expected
<cachio> hehe :)
<Saviq> popey: you'll probably know, I'm snapping subsurface and missing usb/serial hotplug makes it miss a bunch of functionality - would you say it's a case for classic or devmode until we have hotplug? both have (dis)advantages...
<popey> Saviq: there's usbraw, which might help?
<popey> Saviq: i hear usb hotplug is on the list for this cycle - pstolowski|afk  is on it
<Saviq> popey: will that give me access to /dev/ttyUSB0 do you know?
<Saviq> yeah I know about hotplug... can't get there soon enough ;)
<popey> Serial interface might
<Saviq> only gadget
<popey> Sorry, I don't know any more on that.i am channelling chipaca
<Saviq> nw, thanks!
<popey> As we walk to the pub
<Saviq> enjoy!
<cachio> niemeyer, https://paste.ubuntu.com/p/73CftWjqdz/
<cachio> niemeyer, spread is receiving a 500
<niemeyer> cachio: Nice, thanks.. should be easy to fix.. should just be a mishandling of the error in our side
<kyrofa> niemeyer, build VM meeting now if you're available
<niemeyer> kyrofa: Hoping calls.. omw
<jdstrand> mvo: hey, it seems like the shared account's email address has changed to snaps@canonical.com. do you know what this is about? (looking at snap usns)
<mvo> jdstrand: mostly because its user visible in snap info core
<mvo> jdstrand: and the old name was a bit long
<jdstrand> mvo: ok, that's fine. I have some logic to map the shared account email to groups of people depending on the snap name so that, say, the desktop team gets desktop snap usn notifications and the snapd team gets snappy ones
<jdstrand> mvo: I just need to update that (no biggie, just confirming)
 * cachio afk
 * zyga woke up
<zyga> mvo: hey, are you still around?
<zyga> jdstrand: or you perhaps
<jdstrand> zyga: what's up?
<zyga> hey! I was wondering if you could do a small review for error cleanups https://github.com/snapcore/snapd/pull/5272/files
<mup> PR #5272: cmd/snap-update-ns: improve wording in many errors <Created by zyga> <https://github.com/snapcore/snapd/pull/5272>
<zyga> the diff is small but there are also three patches that show what's going on with more detail
<jdstrand> zyga: sure. you don't have to do it now, but fyi PR 5240 has addressed your comments
<mup> PR #5240: tests: add test to ensure /dev/input/event* for non-joysticks is denied <Created by jdstrand> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5240>
<jdstrand> sorry
 * zyga looks
<jdstrand> PR 5250
<mup> PR #5250:  interfaces/udev,misc: only trigger udev events on input subsystem as needed <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5250>
<jdstrand> zyga: ^
<zyga> jdstrand: I did a partial pass over that code now
<jdstrand> zyga: I'm satisfied for what it aims to do in that it will provide a real benefit to people
<jdstrand> zyga: I didn't care for having to unconditionally trigger joysticks (it is cheap so not a problem, but don't like it)
<jdstrand> zyga: for disconnect
<jdstrand> zyga: not that we should implement it right now, but I was wondering if you had thoughts about callouts to backends on disconnect
<jdstrand> zyga: the ensure dir concept means we dont usually have to care. but in this one case, it would be nice
<jdstrand> zyga: we can chat about that tomorrow. I have another small topic to discuss too
<zyga> jdstrand: mmm, as to the question of callouts to backends on disconnect, no I didn't think about that, currently the code is setup (pun not intended) is that Setup would do the right thing (perhaps at a price). We could arrange it so that a new method Adjust/Amend/Update or similar is available to tweak an existing state. It might (perhaps I'm reading it too shallowly though) also play nicely with composed apparmor profiles later
<zyga> down the line
<zyga> jdstrand: yeah, let's chat tomorrow morning your time
<om26er> popey: hey! is everything ok with the build system now, can we publish axel ?
<kjackal> Hi people, is the output of the hooks stored somewhere? I have a few print messages, plus I need to be some debugging
<zyga> kjackal: AFAIR... no
<zyga> but please ask pstolowski tomorrow
<zyga> I'm heading to bed so I won't jump into the code to check now, sorry
<kjackal> thanks zyga goodnight
<zyga> kjackal: (to be precise, the output is _probably_ stored but discarded unless something errors)
<kjackal> we do not know where it stored
<zyga> stored in memory I mean
<zyga> I doubt it's stored anywhere on disk
<Odd_Bloke> Is there a way for me to exclude my .tox directory when I `snapcraft cleanbuild`?
#snappy 2018-06-07
<mup> PR snapcraft#2158 opened: rust plugin: fix cargo builds and run tests <Created by tismith> <https://github.com/snapcore/snapcraft/pull/2158>
<mborzecki> morning
<zyga> hey hey :)
<mborzecki> zyga: hey
<mup> PR snapd#5273 closed: testutil: add test support for Fstatfs <Simple> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5273>
<zyga> woot, thank you!
<mborzecki> so are we doing the `snap list --format=..` thing or not?
<zyga> I ... don't know
<zyga> I think not
<zyga> mborzecki: 5266 is simple and green
<mvo> mborzecki: it looks like no, lets see if the bugreport is happy about the snap list|awk|tail +2 solution
<mborzecki> it was a nice feature :(
<mvo> mborzecki: yeah, I have grown to like it as well
<mborzecki> there was a panic from spread in #5271 https://paste.ubuntu.com/p/XXqr7TY9KM/
<mup> PR #5271: [WIP] cmd: attempt to start the document portal if running with a session bus <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5271>
<mborzecki> niemeyer: ^^
<zyga> mborzecki: I think we saw a few panics yesterday and gustavo is aware of them
<zyga> but I'm not sure if those are the same panics or if spread was changed but some panics remained
<zyga> hey mvo, good morning
<mup> PR snapd#5266 closed: interfaces/builtin/docker: use commonInterface over specific struct <Created by anonymouse64> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5266>
<zyga> https://github.com/snapcore/snapd/pull/5230 needs a 2nd review
<mup> PR #5230: interfaces/udisks2: also implement implicit classic slot <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5230>
<mvo> zyga: good morning to you as well!
<zyga> mvo: what's the state of https://github.com/snapcore/snapd/pull/5250
<mup> PR #5250:  interfaces/udev,misc: only trigger udev events on input subsystem as needed <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5250>
<zyga> there's a conflict but I see that you took care of the feedback
<zyga> are you working on this or is the conflict recent
<zyga> er
<zyga> sorry
<zyga> bad PR
<zyga> https://github.com/snapcore/snapd/pull/5226
<mup> PR #5226: data: add systemd user environment generator <Created by mvo5> <https://github.com/snapcore/snapd/pull/5226>
<zyga> this is what I meant
<mvo> zyga: the user envirronment generator? iirc it had some packaging issues I need to look at them
<zyga> ack,
<zyga> I asked some follow up packaging questions there
<mvo> ta
<zyga> +1 on everything if it works :)
<mvo> taÂ²
<zyga> unicode :D
<Lin-Buo-Ren-alt1> https://forum.snapcraft.io/t/organize-another-dir-causes-the-items-under-host-root-directory-to-be-copied-in-another-dir/5806
<mup> PR snapd#5259 closed:  devicestate: support seeding from a base snap instead of core  <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5259>
<pstolowski> morning o/
<mborzecki> pstolowski: hey
<mvo> hey pstolowski
<zyga> hey pawel
 * zyga -> walk
<zyga> or maybe in 15 minutes
<mup> PR snapd#5275 opened: cmd/snap: use snaptest.MockSnapCurrent in `snap run` tests <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5275>
<mborzecki> trivial pr ^^
<mup> PR snapd#5276 opened: devicestate: support seeding from a base snap instead of core <Created by mvo5> <https://github.com/snapcore/snapd/pull/5276>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/5277 :)
<mup> PR #5277: cmd/snap-update-ns: add helper for checking for read-only filesystems <Created by zyga> <https://github.com/snapcore/snapd/pull/5277>
<zyga> I'll take your PR for snap run
<mup> PR snapd#5277 opened: cmd/snap-update-ns: add helper for checking for read-only filesystems <Created by zyga> <https://github.com/snapcore/snapd/pull/5277>
<mborzecki> haha ;) trade PRs
<zyga> spread still panics
<zyga> can we revert spread somehow?
<mborzecki> i'm looking into spread right now
<zyga> +1 on the PR
<zyga> and I need to go or my dog will hate me
<mborzecki> zyga: it won't hate you, it'll just piss on the floor :P
<zyga> and *then* he will hate me ;)
<zyga> no, he's too humble for that I'm not that evil
 * zyga -> walk
<mvo> the spread crash is not happening all the time, right? I saw at least one green PR from me this morning
<mvo> mborzecki: can I restart your failed MockSnapCurrent PR? or do you want to keep it for the error ?
<mborzecki> mvo: go ahead
<pedronis> mvo: some comments on #5274
<mup> PR #5274: configstate: deny configuration of base snaps and for the "snapd" snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/5274>
<mborzecki> niemeyer: https://github.com/snapcore/spread/pull/59
<mup> PR spread#59: spread: do not panic if error message from google backend is empty <Created by bboozzoo> <https://github.com/snapcore/spread/pull/59>
<mvo> pedronis: great, thank you!
<pedronis> mvo: I don't understand the changer about errDoNothing in 5276
<pedronis> mvo: I probably read the new code wrong but it's a bit unclear what's the intention of it
<mvo> pedronis: let me double check
<pedronis> just avoid calling trivialSeeding twice?
<pedronis> I mean from two places
<pedronis> but then the comment in import Assertion is misleading
<mvo> pedronis: thanks, let me rework this
<pedronis> mvo: IÂ mean we will not use the model returned by importAssertionsFromSeed in that case
<pedronis> also it doesn't get set in state anyway so it wouldn't help later code that needs a model in all cases
<pachulo> Hi! Does anybody knows something the vim snap? https://forum.snapcraft.io/t/vim-snap/5573
<mvo> pedronis: yeah, I think this was a misconception my part, these bits can be undone
<pedronis> mvo: I suppose maybe because at some point you were passing model in trivialSeeding ?
<mvo> pedronis: exactly
<mvo> pedronis: using "core" for the config makes all of this much simpler
<pedronis> I see, anyway as I said return a model that way from importAssertionsFromSeed breaks its invariant so we would needed to do something else anyway
 * pedronis errands
<mvo> pedronis: there will be some small complications in the followups because some code checks for that the snap is installed when getting config
<mvo> pedronis: thank you, I will update the PRs
<zyga> re
<zyga> pachulo: hey
<zyga> pachulo: since snap crafters are the publisher I would suggest asking popey about it
<zyga> mborzecki: my PR is green :)
<zyga> no better chance to review it than now :)
<zyga> oh I see it's reviewed already
 * zyga will forever ponder what is the condition under GitHub updates the page without a reload 
<zyga> mvo: ^ quick 2nd review on 5277
<mborzecki> heh, github ui is terrible
<zyga> I _like_ the way it looks but _hate_ the way it is stale without apparent reason
<mborzecki> the funniest is when you comment on a hunk that gets changed in another patch, and you forgot to switch to 'show all patches'
<zyga> thank you for the review on 5272 pawel
<pachulo> thanks zyga !
<zyga> pachulo: note that you also got a response on the foruom
<zyga> *forum
<zyga> jamie there is right that there should be a repository under snapcrafters on github
<zyga> mvo: thank you mvo
<zyga> mborzecki: to the point about GitHub UX being not too great, I got a comment (approval) from mvo and it was shown as a comment but the comment / approval count below was stale
<mup> PR snapd#5277 closed: cmd/snap-update-ns: add helper for checking for read-only filesystems <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5277>
<mvo> pedronis: thanks again for the review(s), I update the PRs, I added a testcase that loads a snap-setup without a type. interesstingly this does not crash, it only crashes if there is an empty (or invalid) "type":"" in the json
<mvo> pedronis: but maybe you have something different in midn?
<mvo> mind
<mup> PR snapd#5275 closed: cmd/snap: use snaptest.MockSnapCurrent in `snap run` tests <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5275>
<popey> pachulo: wassup?
<zyga> popey: is the vim snap owned by snapcrafters/
<zyga> popey: and if so, where is the snapcraft.yaml
<popey> sergio initially created the snap, sergiusens ^
<zyga> mborzecki: one more helper before the main meat of the validation logic
<zyga> mborzecki: #5278
<mup> PR #5278: cmd/snap-update-ns: add IsTrustedTmpfs and tests <Created by zyga> <https://github.com/snapcore/snapd/pull/5278>
<pedronis> mvo: ah see, no, nothing different,  just forgot that behavior of the json umarshaller
<mup> PR snapd#5278 opened: cmd/snap-update-ns: add IsTrustedTmpfs and tests <Created by zyga> <https://github.com/snapcore/snapd/pull/5278>
<mvo> pedronis: thank you! I feel much better having a test for this :)
<pedronis> mvo: I will re-review after lunch
<Chipaca> Hi all. A notice and reminder that I'm off work today and tomorrow.
<zyga> Chipaca: ack
<mvo> pedronis: ta
<mvo> Chipaca: enjoy! we miss you already
<Chipaca> mvo: :-)
 * zyga considers lunch for a change
<robert_ancell> Chipaca, after implementing the /v2/snaps?select=...&snaps=... API in snapd-glib, can you think of any reason to ever have a client use the /v2/snaps/[name] API? I'm thinking of deprecating those old methods.
<robert_ancell> I guess we continue to use it with POST, but not GET
<Chipaca> robert_ancell: I'd say if there is it's because of a bug
<robert_ancell> Chipaca, so be clear, /v2/snaps/[name] is really redundant now?
<Chipaca> robert_ancell: well, it's going to be faster but probably not an issue in practice
<Chipaca> robert_ancell: but, yeah
<Chipaca> and it might not even be measurably faster -- i'd have to try to measure
<ondra> zyga ping
<zyga> Go
<robert_ancell> ah, there is a bit of a difference /v2/snaps?snaps=blah returns 200 and /v2/snaps/blah returns 404
<ondra> zyga do we treat kernel snap differently when it comes to interfaces used by hooks?
<zyga> Not that I know of
<zyga> Kernel should not have interfaces or hooks AFAIR
<mborzecki> hmm snapshots separate elements using _ in snaphot file names, will need some extra care for parallel installs
<ondra> zyga I think joc spotted my error here
<ondra> zyga indeed it's a bit special case I have here, but let's see :)
<zyga> What is the use case?
<ondra> zyga pi3 kernel update :)
<zyga> Oj
<zyga> Tell me more please
<ondra> zyga let me proof tested first :)
<zyga> Ok
<mvo> zyga: I updated 5263 based on your feedback (thanks for this btw). also thanks to mborzecki
<zyga> Ack
<zyga> I will check after lunch
<sergiusens> zyga, popey: that was my first classic snap ever, we didn't even have a build service yet iirc
<mborzecki> one huge renames patch coming up, 97 files changed, 875 insertions(+), 702 deletions(-)
<zyga> What is that
<zyga> Switching to under_score ;-))
<zyga> Iâm almost done with lunch
<zyga> Will be home soon
<pedronis> mborzecki: why renaming the dir ones ?
<pedronis> me is probably missing something
<mborzecki> pedronis: because some paths end up using StoreName() instead of InstanceName(), hence *Dir() were changed to make me go though each place and update it accordingly
<pedronis> mborzecki: why would a path use StoreName ?
<pedronis> genuine question
<mborzecki> pedronis: eg. inside snap-exec after remount, apparmor profiles which refer to the paths inside the mount ns
<pedronis> mborzecki: but there is no store variant of them,  you then do snap.MountDir(snapName, rev) and similar ?
<mborzecki> pedronis: yes
<mborzecki> and the Instance*Dir() use the same snap.*Dir() helpers
<pedronis> mborzecki: I suppose we could mount files at some point, not sure the it easy though
<pedronis> sorry
<pedronis> I mean share mount files
<mborzecki> it'd be nice
<mborzecki> right now each instance will get own copy
<pedronis> that's an easier starting point
<pedronis> there are fun questions also about conflicts
<mborzecki> given that they can be on different revisions that's also a bit easier to handle
<pedronis> mborzecki: anyway afaiu snap-confine and snap-exec are the only things that need to deal with dirs without instance-key, right?
<mborzecki> pedronis: and apparmor backend so far
<pedronis> mborzecki: I see an StoreName indeed, why ?
<pedronis> to repelace SNAP_NAME, but unclear SNAP_NAME can still be used in profiles?
<pedronis> ah, it's because inside vs outside?
<pedronis> mborzecki: ok, I see, we could really sort of keep the old names, but maybe the new names are clearer
<pedronis> because of this inside vs outside issue
<mborzecki> pedronis: yup
<mborzecki> pedronis: we can roll back the *Dir() renames later on when the store vs instance name thing is sorted out
<pedronis> mborzecki: anyway it's not tragically big, just a bit,  anyway will need a span of quite time to go over it
<pedronis> mborzecki: did you see test that needed doubling, or did you still not look into that?
<mborzecki> pedronis: i doubled only few tests, mostly in snap
<pedronis> mborzecki: most places that need StoreName probably need one, places using InstanceName it depends I suppose
<zyga> re
<mvo> zyga: what comment should I add to 5263
<zyga> that there's no locking done by specific functions
<zyga> (so that we don't forget this)
<mvo> zyga: aha, ok
<zyga> hmm
<zyga> spread keeps crashing
<mvo> zyga: will do
<mvo> yeah, spread is not happy today
<zyga> which is odd because some PRs are just ireland-grass-green
<zyga> while others fail after 1st minute
<jdstrand> mborzecki: I haven't really been following the conversation (I was conducting and interview-- note to channel: there are open positions on the Ubuntu Security team!)
<jdstrand> mborzecki: but otoh the things to think about are file paths (both where snaps live, things are mounted, but also apparmor, seccomp, udev, dbus policy files)
<jdstrand> mborzecki: then the security label ('profile foo' in apparmor policy) and the udev tag (which annoyingly must use underscores)
<mborzecki> jdstrand: do the underscores have any special meaning there?
<jdstrand> mborzecki: yes! :) they are the delimiter instead of '.'. udev tags can't have periods
<jdstrand> mborzecki: eg: SUBSYSTEM=="drm", KERNEL=="card[0-9]*", TAG+="snap_0ad_0ad"
<jdstrand> mborzecki: that's ok though. we are very strict that it is 'snap_name_cmd'
<jdstrand> mborzecki: so to date, there will only ever be exactly two underscores
<mborzecki> jdstrand: right, but then if you have snap_0ad_local_0ad it's fine too right?
<jdstrand> that would be difficult
<jdstrand> snap_0ad_0ad_local would be better
<jdstrand> well
<jdstrand> you could do it
<mborzecki> i mean, the snap is named 0ad_local in this case
<jdstrand> if count(underscores) == 3, then name is 0ad_local
<jdstrand> it does mean we'll need to adjust that parsing everywhere though
<jdstrand> and to finish my PSA for security team position: https://boards.greenhouse.io/canonical/jobs/1158266. it's a great team to work for! :)
<mborzecki> jdstrand: hmm snap-device-helper seems to do some funny stuff with those names
<mvo> jdstrand: I would totally apply if I hadn't a great team already
<jdstrand> hehe
<jdstrand> I'm not trying to poach snapd team members :)
<jdstrand> there are others in the channel who may see it ;)
<mvo> jdstrand: I know :)
<mvo> jdstrand: still you guys have a great team
<jdstrand> mvo: that said, you would be a wonderful addition, as would any of the snapd devs (but I'm not poaching-- I just love working with all of you. good thing I get to continue doing so :)
<jdstrand> mvo: thanks! it's true. the security team is awesome
<mvo> heh :)
 * mvo blushes
<jdstrand> mborzecki: right, it needs to convert back to '.' for the device cgroup name in /sys/fs/cgroup/devices
<jdstrand> mborzecki: eg: /sys/fs/cgroup/devices/snap.firefox.firefox
<jdstrand> mborzecki: so it would have to learn to do snap_firefox_local_firefox -> snap.firefox_local.firefox
<mborzecki> jdstrand: right, so another small update there :/
<zyga> mborzecki: btw do you have that huge rename PR ready?
<jdstrand> mborzecki: we try to use '.' as the delimiter everywhere we can for consistency (I tried to use '_' in the early days, but '.' was deemed prettier (is is))
<jdstrand> it* is
<mborzecki> zyga: yes, #5253
<mup> PR #5253: snap: introduce new fields for parallel snap installation <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5253>
<zyga> I'll review it after standupo
<mborzecki> jdstrand: use # and watch as the world burns :P
<jdstrand> hehe
<mvo> zyga: I think you made me write locking code in the errtracker "db". its just too embarassing to write a comment that there is none
<mvo> zyga: smart move ;)
<zyga> hahaha
 * zyga mutters "success" ;)
<jdstrand> mborzecki: note that in the apparmor profile itself, the security label is set in various apparmor variables at the top:
<jdstrand> @{SNAP_NAME}="0ad"
<jdstrand> @{SNAP_REVISION}="18"
<jdstrand> @{PROFILE_DBUS}="snap_2e0ad_2e0ad"
<jdstrand> @{INSTALL_DIR}="/{,var/lib/snapd/}snap"
<jdstrand> profile "snap.0ad.0ad" (attach_disconnected,mediate_deleted) {
<jdstrand> mborzecki: you probably saw that, but I mention it specifically for PROFILE_DBUS
<zyga> this is such an old concept it will take a while to change everywhere
<jdstrand> mborzecki: that will probably just work, but do make sure you get snap_2e0ad_2elocal_2e0ad when have snap.0ad.0ad
<jdstrand> mborzecki: sorry
<mborzecki> jdstrand: SNAP_NAME=0ad_local, then PROFILE_DBUS will be snap_2e0ad_local_2e0ad
<jdstrand> mborzecki: that will probably just work, but do make sure you get snap_2e0ad_2elocal_2e0ad when have snap.0ad_local.0ad
<mborzecki> jdstrand: and profile "snap.0ad_local.0ad"
<mborzecki> jdstrand: snap_2e0ad_2elocal_2e0ad instead of snap_2e0ad_local_2e0ad then?
<jdstrand> snap.0ad_local.0ad translated to dbus is snap_2e0ad_2elocal_2e0ad
<jdstrand> oh no
<jdstrand> _2e is '.'
<jdstrand> gimme a sec
<pedronis> mborzecki: seems SNAP_NAMEÂ is sometimes used in places that really need the instance name in the templates
<jdstrand> what you use depends on how the mounts are setup
<pedronis> not all uses are for directories in the namespace
<zyga> standup time
<jdstrand> right
<jdstrand> I don't know what is happening at the filesystem level
<jdstrand> but you'll the security label to include _local for IPC, etc
<jdstrand> you'll want
<jdstrand> mborzecki: it would be easiest if the file accesses looked like /snap/foo_local/... instead of /snap/foo/...
<mborzecki> jdstrand: hm well, it was requested that we bind mount to /snap/foo
<jdstrand> mborzecki: but if that isn't possible/desirable, you'll need to introduce another apparmor variable: SNAP_NAME_FILE (or something)
<jdstrand> eg:
<jdstrand> @{SNAP_NAME}="0ad_local"
<jdstrand> @{SNAP_NAME_FILE}="0ad"
<jdstrand> with file accesses using @{SNAP_NAME_FILE} and everything else @{SNAP_NAME}
<jdstrand> mborzecki: that is tricky though. $SNAP is easy enough, but SNAP_DATA, SNAP_COMMON and especially SNAP_USER_DATA and SNAP_USER_COMMON are going to be harder, since you'll have to manage all those addition bind mounts
<jdstrand> it is possible, just more complexity
<jdstrand> it is only possible because of the recent user mount work btw since a root processes will be mucking around in the user's home for SNAP_USER_DATA and SNAP_USER_COMMON
<zyga> mvo: https://github.com/snapcore/snapd/pull/5263 is green and has +2
<jdstrand> we are setting ourselves up for if there is a bug, then 0ad_local might be able to write to 0ad's user data. from a complexity/secure design perspective, I recommend 0ad_local everywhere
<mup> PR #5263: errtracker: do not send duplicated reports <Created by mvo5> <https://github.com/snapcore/snapd/pull/5263>
<jdstrand> mborzecki: ^. that doesn't mean I would block the design. but I think that there needs to be an active decision that the benefit outweighs the complexity/risk
<jdstrand> mborzecki: I would like to be involved in the PR reviews as they pertain to security
<mborzecki> jdstrand: sure
 * jdstrand adds a card to trello so ratliff is aware
<jdstrand> ratliff: this'll be a blue item
 * ratliff reads back to understand the priority
<jdstrand> mborzecki: hmm, I'm not sure how parallel installs are going to work with IPC. eg, two network-managers or two dockers installed
<jdstrand> mborzecki: they necessarily need to have their service in the global namespace, so will conflict with each other...
<mborzecki> jdstrand: i suppose common sense will have to prevail here, unless the other docker instance is configured to listen on different path things will break
<mborzecki> jdstrand: maybe postgres usecase is simpler, local snaps on different ports (docker mangles some kernel state so it's probably not the best thing to be installed mulitple times)
<jdstrand> mborzecki: yes... perhaps we can start be saying "if you implement a slot, you can't do this"
<jdstrand> mborzecki: that said, gnome apps all need to slot a dbus interface for the well-known name
<jdstrand> mborzecki: so they are going to break if parallel installed
<jdstrand> (and it isn't just gnome)
<mborzecki> jdstrand: this, probably snaps that have socket activation too
<jdstrand> yeah
<mborzecki> at least using abstract socket paths
<jdstrand> mborzecki: can you describe the feature of parallel installs? is it documented somewhere?
<mborzecki> jdstrand: https://forum.snapcraft.io/t/parallel-snap-installs/5763
<jdstrand> mborzecki: well, any path where the client expects to find the server somewhere specific. it could be a dbus well-known name, abstract socket, named socket, pipe, ... all kinds of stuff
<niemeyer> jdstrand, mborzecki: Can we have a quick sync up call shortly? (after standup, on going)
<mborzecki> niemeyer: ok
<jdstrand> niemeyer: maybe after that we can discuss update-alternatives and interface docs
<niemeyer> jdstrand: Sounds good!
<jdstrand> ratliff: I created a preliminary card in trello
<zyga> uhhh
<zyga> my coffee machine erupted :/
<pedronis> niemeyer: pstolowski: this can be re-reviewed now:  https://github.com/snapcore/snapd/pull/5221
<mup> PR #5221: snap: parse connect instructions in gadget.yaml <Created by pedronis> <https://github.com/snapcore/snapd/pull/5221>
<pstolowski> ok
<zyga> it punctured the capsule incorrectly and all the coffee went outside the wrong way
<genii> zyga: Perhaps it's one of those recalled Keurigs
<zyga> no, I'm not familiar with those
<mborzecki> zyga: just get a moka pot ;)
<zyga> I'll get a mop and a pot ;)
<pstolowski> guys, if you see econnreset test failure again please let me know, i lost yesterday's log when I re-loaded the tab with travis log today
<pedronis> pstolowski: should we add some logging to the retry logic to see the error when we don't retry?
<pstolowski> pedronis: yep, that may help
<jdstrand> niemeyer, mborzecki: I tried to summarize much of the above in https://forum.snapcraft.io/t/parallel-snap-installs/5763/3
<mborzecki> jdstrand: thanks!
<mvo> zyga: a second review for 5274 would be great, you did a first pass already afaict
<zyga> ACLU
<zyga> Ack
<zyga> I wonder what spellchecker contains ACLU
<jdstrand> niemeyer, mborzecki: I'm ready whenever you are
<niemeyer> jdstrand: Just finishing a pre-scheduled meeting I had until the half hour.. should be off in 20 or so
<jdstrand> ack
<mup> PR snapd#5279 opened: interfaces/builtin: create socketcan interface <Created by jocave> <https://github.com/snapcore/snapd/pull/5279>
<jdstrand> fyi, I've added a review of PR 5279 to my list. I have a number of questions. others might want to wait until I do my first review
<mup> PR #5279: interfaces/builtin: create socketcan interface <Created by jocave> <https://github.com/snapcore/snapd/pull/5279>
<jdstrand> joc: fyi ^ (and thanks for the PR. I'm stepping into a meeting so it'll be a bit)
<joc> np, thanks for looking at it jdstrand
<niemeyer> jdstrand, mborzecki: https://meet.google.com/dnp-muwd-mng
<mup> PR snapd#5280 opened: httputil: extra debug if an error is not retried <Created by stolowski> <https://github.com/snapcore/snapd/pull/5280>
<greyback> who can I poke to get a human reviewer for https://launchpad.net/~gerboland/+snap/chromium-mir-kiosk/+build/241717
<mup> PR snapcraft#2128 closed: project_loader: stop setting LD_LIBRARY_PATH <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2128>
<greyback> ah, there's a button. ignore me
<didrocks> jdstrand: hey, around
<jdstrand> didrocks: hey, so we were thinking we were going to have the update-alternatives meeting now, but it'll be in an hour or so
<jdstrand> didrocks: your attendance isn't stricly required, so if you can't attend that's ok, but if you can that would be great. is that an ok time?
<didrocks> jdstrand: hum, I can't be around at that time, I have some family duties
<didrocks> jdstrand: I don't think indeed that I'm required, you know update-alternatives as well as I do if not better :)
<jdstrand> didrocks: that's fine. I understand the problem and even the specifics of the access you desire
<didrocks> jdstrand: the only thing to remember is that the alternative isn't on a binary, but on a css file used by gdm via gnome-shell
<didrocks> gdm3.css
<jdstrand> yep
<didrocks> which doesn't match the snap name
<jdstrand> nope
<jdstrand> :)
<didrocks> I guess that's all you need to know :)
<jdstrand> ok, thanks!
<didrocks> jdstrand: ah, and you got why I separated that in 2 snaps, one arch:all and the other one?
<jdstrand> didrocks: I'll summarize the outcome in the forum after the meeting
<didrocks> perfect!
<jdstrand> didrocks: actually, I forgot that detail
<jdstrand> there is gsettings and update alternatives
<didrocks> jdstrand: basically, I built the theme via Travis CI
<didrocks> which is using the docker image
<cachio> niemeyer, PR for gc ready https://github.com/snapcore/spread/pull/60
<didrocks> and so, I need to have the theme snap arch: all
<mup> PR spread#60: Garbage collection for google backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/60>
<cachio> niemeyer, and tested
<didrocks> I can't use snapcraft.io because the theme is made of 5 github projects
<didrocks> and any commit in any of those can trigger a new revisino
<didrocks> if you are interested into the glory detail, the snapcraft.yaml is: https://github.com/ubuntu/communitheme-snap-helpers/blob/master/snap/snapcraft.yaml
<didrocks> and the build script is https://github.com/ubuntu/communitheme-snap-helpers/blob/master/build/prepare-build-snap (pulled by the 5 projects in Travis)
<didrocks> Note: sed -i "s#    source: .*$TRAVIS_REPO_SLUG\.git#    source: \.#" snap/snapcraft.yaml
<didrocks> which means "for the current project, take the local branch" (handling PR)
<didrocks> I guess that's it, more details about what I do for the theme and CI is at https://didrocks.fr/2018/04/10/welcome-to-the-ubuntu-bionic-age-new-wip-ubuntu-theme-as-a-snap/
<jdstrand> didrocks: it seems you could instead of pointing at 5 repositories, point at one (yours, has files from all 5), and then pull in git commits from the 5 into your one as desired. then you can hook that up and do arch specific builds
<didrocks> jdstrand: it won't work easily for proposed changes though
<jdstrand> didrocks: it still isn't clear why the 5 trees requires arch stuff..
<didrocks> jdstrand: see https://github.com/ubuntu/gtk-communitheme/pull/526#issuecomment-395422606
<mup> PR ubuntu/gtk-communitheme#526: Made suggested action label button more visible when disabled <Created by clobrano> <https://github.com/ubuntu/gtk-communitheme/pull/526>
<jdstrand> it would be maintenance overhead, so would have to weigh the options
<didrocks> thanks to this, on each project, I can detect PR in Travis
<didrocks> and build a particular snap with that changes on those PR
<didrocks> that people can switch to, testâ¦
<pstolowski> #5280 hit that spread panic
<didrocks> you can't really do that with snapcraft.io, which is only one branch on one project
<mup> PR #5280: httputil: extra debug if an error is not retried <Simple> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5280>
<jdstrand> didrocks: perhaps that is more of an ev thing then
<jdstrand> didrocks: but the two-snaps approach doesn't really change the conversation regarding update-alternatives/gsettings, right?
<didrocks> jdstrand: got the confirmation that's not planned/doable right now on the store side, and I have a solution which works. All this, I mean, "I have to use Travis CI, so docker image, so one arch build, hence arch: all, hence 2 snaps"
<didrocks> jdstrand: no, it's just to explain why there are 2 snaps instead of one :)
<pstolowski> mborzecki: how far is your spread fix from landing? do you need a review?
<jdstrand> I see. ok, well, if it comes up, I can refer back to this
<jdstrand> thanks!
<didrocks> jdstrand: thank you! :)
<mborzecki> pstolowski: niemeyer said he'll do a slightly different fix, we'll have to wait a bit
<pstolowski> ok
<jdstrand> mborzecki: re hard link vs symlink> of course, you can't hard link a dir. since we are only talking about $SNAP, you could symlink from the local ones to /snap/foo/current then adjust the template policy as needed
<jdstrand> mborzecki: that could probably be made to work
<mvo> hrm, 5274 consistently fails with a spread panic here :/
 * mvo takes a break
<mborzecki> jdstrand: afaiu hardlinking was in the context of *.snap (the squashfs images)
<jdstrand> mborzecki: that would work. it does mean the kernel then has 3 different mount points. I wonder if it will dedupe?
<pedronis> mborzecki: I left some more input into the PR,  some of it is really note about areas that will need attention,  might want to add a TODO now or keep a note
<pedronis> but didn't go to the end of it
<cachio> niemeyer, did you fixed the spread panic issue ?
<cachio> niemeyer, I can work on that if you want
<niemeyer> No, have been in calls all morning, and having lunch now.. sure, if you have a clear view of the fix, please open a PR.. otherwise I can quickly look at it
<cachio> niemeyer, ok, I'll take a look now
<Saviq> jdstrand: hey, re: https://forum.snapcraft.io/t/classic-confinement-for-subsurface/5795 - should raw-usb give me access to /dev/ttyUSB0? any idea why I'm not seeing denials even though the app can't open the serial port?
<mborzecki> cachio: you can take a look at https://github.com/snapcore/spread/pull/59 niemeyer mentioned he wanted something more informative (maybe some logging there as well?)
<mup> PR spread#59: spread: do not panic if error message from google backend is empty <Created by bboozzoo> <https://github.com/snapcore/spread/pull/59>
<mborzecki> cachio: don't know if spread is doing direct http calls to the api, if you suspect it's due to 500s the maybe it'd be possible to catch the problem earlier
<jdstrand> Saviq: if you aren't seeing logged denials, I'm not sure why unless you are non-root or the device didn't end up in the snap's device cgroup
<jdstrand> Saviq: the raw-usb interface uses var rawusbConnectedPlugUDev = []string{`SUBSYSTEM=="usb"`}
<jdstrand> Saviq: it does not have /dev/ttyUSB*, but I would expect a denial to be logged
<jdstrand> Saviq: you can see what is allowed to the snap in the cgroup with: cat /sys/fs/cgroup/devices/snap.name.cmd/devices.list
<cachio> mborzecki, sure, I'll take a look
<jdstrand> Saviq: (but you will need to have run the snap once for that to show anything)
<mborzecki> cachio: this will only prevent the panic, if you can catch the problem earlier that'd be great
<zyga> jdstrand: hey, can you please enqueue https://github.com/snapcore/snapd/pull/5278/files
<mup> PR #5278: cmd/snap-update-ns: add IsTrustedTmpfs and tests <Created by zyga> <https://github.com/snapcore/snapd/pull/5278>
<pedronis> mborzecki: btw another thing to consider is that there might be places that assume there is one local snap name for each snap-id,  which will no longer be true, UpdateMany and helpers is example (but problably not the only one), they use a stateByID map
<pedronis> atm
<jdstrand> ok
<zyga> thank you
<rbasak> nacc: o/
<rbasak> nacc: oh, I'm wrong
<rbasak> gpgrt_get_syscall_clamp appears in usr/lib/libgpg-error.so.0.22.0 both the good and bad snaps
<niemeyer> mborzecki, cachio: No logging at this point.. we already have logging.. it's the creation of the error that is wrong
<rbasak> That doesn't seem right
<nacc> rbasak: yeah it's right :)
<nacc> rbasak: the only thing i've been able to determine is when _pygit2's ldd shows the wrong libgpg-error
<nacc> where determine == indicates a good or bad snap
<nacc> rbasak: it's what makes me think our build is fine and it's a bug in snapcraft :)
<zyga> mvo: did another pass over 5274
<cyphermox> ogra_: poke; ubuntu-core-libs, do you want to get that seeded somewhere (tbh, I'm not sure where) so it ends up in main?
<cyphermox> (bug LP: #1572539)
<rbasak> nacc: yes, that does look different: https://pastebin.ubuntu.com/p/xtnYDMhYR7/
<rbasak> nacc: OK, I think I might be caught up with you now :)
<mup> Bug #1572539: [MIR] ubuntu-core-libs <ubuntu-core-meta (Ubuntu):Fix Committed> <https://launchpad.net/bugs/1572539>
<nacc> rbasak: sorry, otp right now; and thit is almost exactly what we hit before, so i had a lot of context in my head
<nacc> rbasak: and yep, that's exactly the symptom i see
<nacc> i think it's a bug in the rpath/patchelf usage by snapcraft
<rbasak> Would you agree it's non-deterministic in snapcraft? And I'm just unlucky that it only happens on Launchpad and not locally?
<nacc> rbasak: that's my suspicion; did you notice one of my CI runs failed the way your didn't?
<nacc> and in the same way as LP's build did
<rbasak> I didn't, but I guess you're just luckier than I am then :)
<nacc> kyrofa: mentioned that the deterministic ordering stuff is in a PR now
<rbasak> Even if it's made deterministic, how do we make sure that the one used is the one we want?
<nacc> like i mentioned in #launchpad, it might make us fully broken or it might fully fix it :)
<rbasak> Right :)
<zyga> mborzecki: can you do a quick pass over 5287
<zyga> er
<zyga> 5278
<nacc> yeah, it depends on what the bug we're hitting actually is, and for that i think we need kyrofa or sergiusens to look
<rbasak> I think we also need snapcraft to follow our ignores from the stage directive
<nacc> rbasak: i think it does, right? do we ever see the wrong libgpg-error in stage?
 * zyga has some mental thing where sometimes last two characters and almost always last two digits get swapped
<nacc> rbasak: *possibly* the rpath needs to respect the eliding
<rbasak> I don't know what's present in stage in the broken case since I can't reproduce a broken build tree
<nacc> yeah
<rbasak> But I don't see anything in stage/lib/ in the successful case, which is where I'd expect that one to go
<rbasak> So I think the ignore is working, but it's later being unignored.
<nacc> right, could be
<nacc> this was a pain to debug, and kyrofa just understood the details a lot better than i did and was able to figure it out faster than i could :)
<rbasak> So I guess we're broken until this can be addressed in snapcraft. In the meantime, the best I can do is manually build the snap locally and upload after verification that it's OK.
<rbasak> I wonder if I can hack an actual deletion of the file from parts/
<rbasak> And if that would break anything
<rbasak> Not that I could test that since I can't reproduce :(
<kyrofa> rbasak, nacc yeah I think the first thing we need is a way to reproduce
<kyrofa> rbasak, have you tried using edge, by any chance? One (of two) deterministic-fixing things has landed there
<cachio> mborzecki, niemeyer the PR works well
<cachio> niemeyer, but there is something else which is causing this 500
<rbasak> kyrofa: I could try locally where I can't reproduce, but I'm not sure where that'll get me
<kyrofa> rbasak, i.e. with edge, you should notice that snapcraft handles parts in the same order between runs
<kyrofa> rbasak, it may allow you to reproduce every time, or it may fix LP, haha
<zyga> jdstrand: #5279 is interesting
<mup> PR #5279: interfaces/builtin: create socketcan interface <Created by jocave> <https://github.com/snapcore/snapd/pull/5279>
<rbasak> I don't think I have any choice about what LP runs
<rbasak> But I can see if it reproduces every time, sure :)
<kyrofa> Indeed, and it won't be fixed there yet anyway
<kyrofa> Yeah see if changes anything for you locally
<rbasak> I'm running out of time today. I'll try that tomorrow.
<niemeyer> cachio: What PR?
<cachio> niemeyer, https://github.com/snapcore/spread/pull/59
<mup> PR spread#59: spread: do not panic if error message from google backend is empty <Created by bboozzoo> <https://github.com/snapcore/spread/pull/59>
<rbasak> kyrofa, nacc: thank you for your help.
<jdstrand> zyga: yes I mentioned that earlier
<kyrofa> Of course. I'll chat with sergiusens and see if we can get the other deterministic thing sorted as well
<zyga> oh, sorry I missed trhat
<kyrofa> (library search order)
<niemeyer> cachio: No it doesn't work well.. an error value that says "error" is quite pointless
<nacc> rbasak: np, sorry for not documenting what i found better
<sergiusens> rbasak, nacc: since you are building with jenkins, I would suggest you use the snap instead of the deb. We are waiting for that change to happen for buildd's as well
<joc> zyga: the question about whether to use network interfaces is indeed interesting, i'll wait to see what you all think!
<zyga> jdstrand: AFAIK some filesystems are toying with hardlinking directories but it's not mainline yet
<zyga> joc: I'm +0.8 on making it a socket type and going with existing interfaces
<mvo> pstolowski|afk: here is a econnereset https://api.travis-ci.org/v3/job/389153950/log.txt for you (you asked earlier)
<zyga> jdstrand: oh and totally forgot to ask you
<pstolowski|afk> mvo: great, thanks, i'll save it and inspect tomorrow
<zyga> jdstrand: the new seccomp deferral to userspace feature that was on LWN looks super juicy
<zyga> jdstrand: do you think we should eye supporting that?
<mvo> zyga: 5263 is also ready for another look
<mvo> pstolowski|afk: yw
<zyga> mvo: I was reading it already
<zyga> just approved it again
<zyga> (with two questions)
<mup> PR snapd#5272 closed: cmd/snap-update-ns: improve wording in many errors <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5272>
<zyga> pstolowski|afk: econreset: https://api.travis-ci.org/v3/job/389153950/log.txt
<pstolowski|afk> zyga: yep, just got it from mvo above, thanks
<zyga> do you want me to save the log and restart?
<zyga> mvo: shall we close https://github.com/snapcore/snapd/pull/5234 ?
<mup> PR #5234: snap: add `snap list --format=...` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/5234>
<jdstrand> zyga: I think that is the bit that lxd and other container managers wanted. tyhicks could probably comment further. iirc, that is potentially interesting for prompting, but iirc, jjohansen mentioned that it wasn't sufficient. jjohansen already started apparmor prompting
<zyga> I was wondering about how fast it is and if it could be used to make changes to seccomp "profiles" instant without process recycling
<jdstrand> https://lwn.net/Articles/754789/ is what I presume you looked at
<zyga> _perhaps_ https://lwn.net/Articles/756233/
<zyga> jdstrand: this is also potentially super useful for... classic confinement
<zyga> we could do smart exec interception
<zyga> execing inside $SNAP would give you the dynamic linker interception with correct flags
<jjohansen> its interesting, arguments from it are still a problem
<zyga> execing outside would give you the regular behaviour
<zyga> (so finally we could ship bash as a classically confined app)
<zyga> jjohansen: yes, I understand it's still WIP
<zyga> I'd love if some work to copy the arguments for inspection was applied to seccomp as this would make it x10 more useful
<cachio> niemeyer, yes, that's true, I am still researching what it is causing that google returns the error
<jdstrand> hmm, apparently my subscription expired
<zyga> jjohansen: hey :-) how are you?
<jjohansen> hey zyga
<jdstrand> that's weird
<niemeyer> cachio: I don't think that's critical in this case.. a 500 is an error on Google side.. it's blowing up beyond our control.. what we need is to simply be able to display that, and to retry if needed.
<niemeyer> cachio: Most backends, and I suspect Google included, already have logic for retrying on such errors
<zyga> jdstrand: I sent you a subscriber link
<zyga> niemeyer: spread broke google? :-)
<zyga> next up, azure!
<niemeyer> zyga: Apparently..
<cachio> hehehe
<jdstrand> I would have to believe there would be a significant performance hit
<zyga> jdstrand: people in the thread there say it's next to none
<jdstrand> zyga: like, we have the old policy in the kernel and ask userspace if it has something new?
<zyga> I didn't read the patches or anything, it just looks interesting on the outside
<jjohansen> zyga: the problem with seccomp args is that copying them is TOCTTOU race
<zyga> jdstrand: I think the point is that there is no policy
<jjohansen> which is always bad for security
<zyga> it's a decision that goes to userspace to ack (perform) and return a result / error / fd
<zyga> jjohansen: I know but I was hinting at a way to copy them out once
<zyga> jjohansen: and then pass them to other layers already in the kernel
<cachio> niemeyer, it is nice to this this comment in the code
<cachio> / Repeat on 500s. Comes from Linode logic, not observed on Google so far.
<zyga> jjohansen: it's doable, just nobody is doing that apparently
<zyga> jjohansen: perhaps not everything can be copied but common string / stat buffers should be ok
<jjohansen> sure, problem is you need to rewrite the whole syscall stack todo that
<zyga> :D
<cachio> I should update it too
<zyga> I understand that's probably the reason
<zyga> jjohansen: it's the kernel, I don't doubt it will happen, initially people will hate it, then several years later it will be better than sliced bread
<zyga> just after more drivers in userspace and other microkernel things ;)
<jjohansen> zyga: uhmmm, probably not ever going to happen
<zyga> jjohansen: well, isn't that _already_ happening?
<jjohansen> it might happen on a couple syscalls
<jjohansen> zyga: no
<zyga> elf in userspace
<zyga> ah, the syscall thing
<zyga> but the syscall data has to be copied out anyway
<zyga> well, I'm not a kernel hacker, I'm sure it's not trivial and very performance sensitive
<jjohansen> zyga: they are just copying the 6 register values for the syscall, regardless of whether the syscall actually uses 6 register values
<zyga> it's just that I don't believe in "no" anymore as the kernel has crazier stuff thrown into it every year
<niemeyer> cachio: Do you have that debug output which observed the 500 at hand?
<jjohansen> zyga: eg. ioctl, that syscall has different params values sizes, .. based on which ioctl it is and new ones are always being added
<cachio> niemeyer, this it what I have https://paste.ubuntu.com/p/HMvvxNMq9G/
<zyga> jjohansen: that's a good point
<jjohansen> its a complete mess, and only the specific ioctl handler deals with it
<zyga> jjohansen: still, handling open and a few related calls this way would make seccomp incredibly more powerful
<jjohansen> some syscalls maybe will get the treatment but not all of them
<zyga> ioctl can stay as is
<jjohansen> zyga: there are other reasons it problematic for seccomp to access the args
<jjohansen> like it needs to do the copy from user but its in the syscall assembly code level
<niemeyer> cachio: Nice, thanks.. let me cook something up quickly
<jjohansen> its not impossible, but it sure makes things uglier
<Saviq> jdstrand: so ttyUSB0 seems to be 188:0 AFAICT and devices.list does not have that
<Saviq> but agreed I don't understand why no DENIED
<jdstrand> Saviq: DAC is evaluated first, so if it isn't in the device cgroup, then no denial
<jdstrand> Saviq: what is the output of: udevadm info /dev/ttyUSB0
<Saviq> jdstrand: http://paste.ubuntu.com/p/vtxzQHHVWQ/
<jdstrand> Saviq: it isn't tagged: E: TAGS=:systemd:
<zyga> btw, jdstrand I don't know if you are aware of an issue with systemd and the recent introduction of bind/unbind events
<jdstrand> Saviq: what is the output of: snap interfaces -i raw-usb
<zyga> it apparently has caused issues with udev tagging
 * zyga stumbled upon systemd bug report about this
<jdstrand> zyga: I'm not on that specific issue. when was it introduced? I needed to redo things some time ago for a change in behavior
<jdstrand> niemeyer: is now a good time to meet?
<cachio> niemeyer, I am not getting the panic anymore with this change https://paste.ubuntu.com/p/VhKjqwdnyf/
<jdstrand> Saviq: fyi, the device.list with c:188:0 is 'character device' with major 188 and minor 0. ls -l /dev/ttyUSB0 will of course give you major minor. I don't have a USB serial plugged in so didn't confirm 188:0
<cachio> niemeyer, basically because the error message is comming empty
<niemeyer> jdstrand: Just finishing the proposed change and will be with you
<jdstrand> Saviq: but, clearly the device isn't udev-tagged so I wouldn't expect it in there
<niemeyer> cachio: I don't know how to say that more clearly.. we discussed this in the meeting, and I just explained above.. of course the error is gone if you kill the error message
<niemeyer> cachio: We don't want that
<niemeyer> cachio: We want to fix the error message instead.. please leave it with me.. I'll push a change in a minute
<zyga> jdstrand: let me find the bug link
<zyga> jdstrand: it's already deployed to bionic
<zyga> jdstrand: the summary of the bug is: systemd sees bind/unbind events and treats them as add/remove, dropping tags
<zyga> https://github.com/systemd/systemd/issues/8221
<zyga> the comments indicate that this has caused widespread issues
<jdstrand> zyga: this seems different from what I saw and that systemd will need a patch
<mup> PR snapd#5280 closed: httputil: extra debug if an error is not retried <Simple> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5280>
<niemeyer> cachio: Please give this a shot and let me know how it goes: https://github.com/snapcore/spread/commit/9aa319e
<niemeyer> cachio: It's in master
<niemeyer> mborzecki: ^
<cachio> niemeyer, sure
<niemeyer> Most of the change in the loop is just indenting it in  so we can repeat the call from later on
<niemeyer> jdstrand: I'm ready
<niemeyer> jdstrand: https://meet.google.com/ipr-very-aqb
<jdstrand> ok
<cachio> niemeyer, it is working
<cachio> spread images was failing 100% of the runs and now it does not fail anymore
<niemeyer> cachio: Nice, so retrying is working as well
<cachio> yes
<Saviq> jdstrand: so devices.list http://paste.ubuntu.com/p/x6h58TrPPk/ does not have 188:0 in it, where would you say the missing piece is? udev rules?
<mup> PR snapd#5281 opened: snap: reject more layout locations <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5281>
 * zyga -> teak
<zyga> tea
<zyga> Pharaoh_Atem: https://www.linux.com/learn/intro-to-linux/2018/5/get-started-snap-packages-linux :-)
<zyga> nice
<Pharaoh_Atem> well then
<Pharaoh_Atem> that's surprising
<zyga> on Fedora :)
<cachio> niemeyer,  with this error on spread I could test the garbage colletion very well
<cachio> Currently I am running it
<cachio> niemeyer, I am cleaning more than 400 machines
<niemeyer> cachio: Wow
<niemeyer> cachio: How come we have that many leftovers?
<cachio> niemeyer, all the builds that failed in travis because of the issue left all the machines alive
<cachio> and the testing I did to reproduce errors too
<niemeyer> Ah, makes sense
 * zyga breaks for some book reading
<mup> PR snapd#5263 closed: errtracker: do not send duplicated reports <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5263>
<cachio> Pharaoh_Atem, hey, did you see this one?
<cachio> https://travis-ci.org/snapcore/snapd/builds/389407059#L1973
<Pharaoh_Atem> looks like someone needs to fix the sed command
<Pharaoh_Atem> I think that was originally added by mvo
<Pharaoh_Atem> also, bogus date should be fixed too
<jdstrand> niemeyer: ok, I sketched out a pretty complete design that someone could run with here: https://forum.snapcraft.io/t/classic-confinement-request-communitheme-set-default/5146/24
<cachio> Pharaoh_Atem, ok, I'll try
<jdstrand> niemeyer: please review and ack since I made a couple tweaks and thought about future iterations that might affect the yaml
<mvo> zyga: did my answers to 5274 look reasonable? I whish there was a "stack this PR on top of the other" feature in GH, I have a nice cleanup pending on top of 5274
<jdstrand> Saviq: sorry, I was in a meeting. what is the output of: snap interfaces -i raw-usb?
<zyga> Mvo: I didnât check yet. My computer is occupied by the family
<nacc> rbasak: fwiw, i thought i had a brilliant idea, that maybe we weren't specifying that pygit2 needed to be built/staged after libgpg-error, but afaict, pygit2 comes from git-ubuntu's dependencies, which is after devscripts which is after gnupg2 which is after libgpg-error.
<nacc> rbasak: but i think that might be the way to debug it, if we can get a failure and success log
<zyga> jdstrand: will alternatives allow coping of binaries out?
<jdstrand> zyga: not by a strict definition of what you just said, but yes it allows confinement escape. the post discusses that
<cachio> niemeyer, did you already updated spread on amazonaws?
<zyga> Rather than escape I was wondering about just working outside of the namespace
<cachio> niemeyer, some builds still failing with the spread issue
<cachio> last error that I saw was 30 minutes ago
<Saviq> jdstrand: http://paste.ubuntu.com/p/Zpq4mKT6vt/
<jdstrand> zyga: the mechanism would allow substituting, say, /usr/bin/vim, for something copied from the snap into /var/lib/snapd/alternatives. the process regulating the use of the interface would not
<jdstrand> Saviq: ok, and what is in /etc/udev/rules.d/70-snap.subsurface.rules
<zyga> I donât follow how a binary copied out of a snap would operate
<jdstrand> zyga: it wouldn't
<zyga> Shared libraries, data, etc
<jdstrand> zyga: we wouldn't allow it
<zyga> Ah
<zyga> So what would we allow
<jdstrand> but the interface is general
<zyga> I assume the copy is for a specific purpose
<jdstrand> did you read the topic?
<jdstrand> :)
<zyga> On the forum
<jdstrand> yeah
<zyga> Yes, maybe misread or missed the point
<jdstrand> it is prompted to change out the the gdm css theme file
<zyga> Or probably just sleeping :-)
<jdstrand> s/the the//
<zyga> Yeah data would work fine
<zyga> Btw
<zyga> Could this be the general exports mechanism?
<jdstrand> from a mount namespace perspective, yes, not for confinement escape. that is why it is manual
<zyga> Eg export wallpapers/man pages/themes/other data
<zyga> With alternatives on top
<jdstrand> zyga: general exports> no, it is specifically for updating symlinks in the 'update-alternatives' system (see the man page if you are unfamiliar with it)
<zyga> Right
<jdstrand> zyga: I mean, maybe
<zyga> Ok
<jdstrand> it depends on how it is all put together. it might be good, it might not
<Saviq> jdstrand: http://paste.ubuntu.com/p/bH6cXrmqFx/
<zyga> Btw: very nice write-up
<jdstrand> zyga: alternatives is about files, not directories, so for a general export mechanism it wouldn't work well. for a handful of files, sure
<zyga> I was thinking just about the copy part
<zyga> And perhaps about /var/lib/snapd/e ports
<jdstrand> Saviq: that looks correct. what happens if in one terminal you do: 'sudo udevadm monitor --subsystem-match=usb' and then you unplug and plug in the device
<jdstrand> Saviq: then, give my the output of the monitor command and 'sudo udevadm info /dev/ttyUSB0'
<jdstrand> zyga: the locations and dir structure in /var/lib/snapd/alternatives could change. I had to make that up as I wrote it cause I realized gdm might crash if it starts before the communitheme-set-defaults snap was mounted
<zyga> Mmm
<jdstrand> (we initially said that the alternative would point to /snap/name/current/...
<jdstrand> )
<jdstrand> that won't work great for a number of things
<zyga> I will watch this closely, I can help with the code as well
<jdstrand> I don't know who will work on it. I just participated in the design. if I am to do it, would need to get it prioritized with stakeholders, etc, etc
<jdstrand> but I tried to lay it all out so someone could run with it
<jdstrand> but we need a final approval on the design/write-up
<zyga> Agreed
<Saviq> jdstrand: https://pastebin.ubuntu.com/p/34x4k6RjxW/
<jdstrand> zyga: I added a note to the writeup that only files are supported
<zyga> Thanks
<jdstrand> Saviq: oh, this is on bionic?
<jdstrand> Saviq: I think you hit zyga's bug: https://github.com/systemd/systemd/issues/8221
<jdstrand> Saviq: I suspect this might work on a xenial system (or perhaps bionic with just the xenial kernel). can you file this against systemd in Ubuntu if it works on xenial and not bionic
<zyga> I really wonder how something this huge went under everyoneâs radar since 4.12
<jdstrand> zyga: it looks like it is subsystem dependent. eg, the input subsystem has no bind/unbind event if I plugin a joystick
<zyga> Mm
<zyga> I see a swarm of bins/unbind messages but I didnât check the details
<zyga> It may also explain why my ..  battery doesnât work
<zyga> I have a battery that ought to charge a ThinkPad via usb-c pd
<zyga> It supposedly works in windows
<zyga> But when I plug it I see a bazillion of errors and bind/unbind calls
<zyga> Oh well
<zyga> Software
<jdstrand> seems this would plausibly be it. the bug had a patch you could run locally if you were desperate :)
<zyga> As long as we donât have GNU/Linux toilets
<zyga> Yeah, I think Iâll pass for now. I mostly work on a desktop
<jdstrand> heh
<jdstrand> we might be able to work around this in snapd based on https://github.com/freedesktop/ModemManager/commit/c07382a486f53e1b3cf729b41518d2a0ba528f5a
<Saviq> jdstrand: oh!
 * Saviq boots xenial up
 * jdstrand tries to find his usb serial
<mup> PR snapcraft#2143 closed: lifecycle: don't clean priming area if the snap is being tried <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2143>
<cachio> niemeyer, https://travis-ci.org/snapcore/snapd/builds/389166279
<cachio> niemeyer, it is not happening in all the builds, it is more sporadic now
<jdstrand> Saviq: actually, I figured it out
<jdstrand> zyga: you may want to listen
<zyga> I'm here actually
<jdstrand> Saviq (cc zyga): snapd isn't affected by that systemd issue because while bind and unbind come through, snap-device-helper ignores them
<jdstrand> Saviq (cc zyga): the problem is that udevadm info /dev/ttyUSB0 is reporting the subsystem as tty
<zyga> do we need to update any bundled udev rules that don't involve just tagging via s-d-h ?
<jdstrand> zyga: probably
<jdstrand> someone should look at that. modem-manager was specifically affected
<jdstrand> Saviq (cc zyga); but if I change the rules file in /etc/udev/rules.d/70... to have something like this, it works (on 18.04 and 4.15):
<jdstrand> SUBSYSTEM=="usb", TAG+="snap_test-policy-app-consumer_raw-usb"
<jdstrand> SUBSYSTEM=="tty", ENV{ID_BUS}=="usb", TAG+="snap_test-policy-app-consumer_raw-usb"
<jdstrand> TAG=="snap_test-policy-app-consumer_raw-usb", RUN+="/usr/lib/snapd/snap-device-helper $env{ACTION} snap_test-policy-app-consumer_raw-usb $devpath $major:$minor"
<jdstrand> Saviq (cc zyga): it is the second rule that I added
<jdstrand> Saviq: I'll create a PR
<zyga> hmmmm?
<zyga> wait
<zyga> so we append a tag (to a set of tags)
<zyga> then if tag is .. what we added we run the helper
<zyga> is this exploiting the fact that bind/unbind reset tags?
<jdstrand> zyga: huh?
<jdstrand> no
<jdstrand> the subsystem doesn't match
<jdstrand> the first is what we have now
<zyga> this is what I don't understand https://www.irccloud.com/pastebin/vLHFJYLd/
<jdstrand> udevadmin info /dev/ttyUSB0 shows the subsystem as E: SUBSYSTEM=tty
<jdstrand> therefore the first rule will never match
<jdstrand> so we add a tty rule that only adds tty devices that are usb
<jdstrand> zyga: what's the problem?
<zyga> I think I just need sleep
<zyga> :)
<zyga> I will read it with fresh mind tomorrow
<jdstrand> if subsystem is tty and the property ID_BUS is set to usb, tag the device
<zyga> I perhaps need to see it on a wider screen
<zyga> not on IRC
<zyga> and check where the newlines are
<jdstrand> well, you'll see it in a PR in a moment
<zyga> as wrapping and udev using most horrid syntax makes it confusing
<zyga> systemd guys, really, udev rules are the worst
<mup> PR snapd#5282 opened: interfaces/raw-usb: also allow usb serial devices <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5282>
<jdstrand> Saviq, zyga: ^
<zyga> jdstrand: can you please review https://github.com/snapcore/snapd/pull/5281 :)
<mup> PR #5281: snap: reject more layout locations <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5281>
<zyga> it's just a rescue from a PR I closed
<mup> PR snapcraft#2159 opened: many: extract lifecycle ordering into own module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2159>
<niemeyer> cachio: No, haven't updated the Travis binaries.. will do so today still
<mup> PR snapcraft#2156 closed: snap: use apt from the archive instead of compiling <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2156>
<niemeyer> cachio: Updated.. please let me know how it goes
<niemeyer> Just restarted that build as well
<cachio> niemeyer, great, thanks
<Matthew-S> Does anyone know how stage-packages are resolved? Do they refer to regular Ubuntu packages or something else? Thanks
#snappy 2018-06-08
<Saviq> Matthew-S: yes, Ubuntu package names today
<Matthew-S> okay, thanks. Another question, if that's the case, how can I go about debugging why an executable behaves differently inside the snap than it does when apt-get installing it?
<Matthew-S> Specifically, I'm trying to get `git` to work inside the snap, but it's complaining with `fatal: Unable to find remote helper for 'https'1
<Saviq> Matthew-S: https://git-scm.com/docs/git-remote-helpers
<Saviq> looks like git doesn't know where to find those
<Lin-Buo-Ren-alt1> Just reproduced this one: https://bugs.launchpad.net/snapcraft/+bug/1695882
<mup> Bug #1695882: cleanbuild loses scripted version <cleanbuild> <Snapcraft:Triaged by kalikiana> <https://launchpad.net/bugs/1695882>
<mborzecki> morning
<zyga> o;
<zyga> o/
<mborzecki> zyga: hey
<mborzecki> 2nd time in a row i saw google:ubuntu-core-16-64:tests/main/snap-repair fail on master, looking into it
<zyga> real failure or logging issue?
<mborzecki> looked like real failure, the test lists the timers and one it's looking for was not there
<mborzecki> zyga: https://paste.ubuntu.com/p/8GYQR6z49D/
<zyga> mmmm
<zyga> yeah
<zyga> looks like it is really broken
<mborzecki> but it doesn't reproduce :/
<zyga> good, it won't spread ;)
<zyga> like all races
<zyga> it's a whack-a-mole
<zyga> my son stays at home today
<zyga> it's so good not to have to wake him
<zyga> and drag him off to school
<zyga> mborzecki: can you please look at https://github.com/snapcore/snapd/pull/5281
<zyga> it's 7 lines and has +1 from jamie
<mup> PR #5281: snap: reject more layout locations <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5281>
<zyga> mborzecki: can I restart the PR where snap-repair failed?
<mborzecki> which one is it?
<zyga> 5282
<mborzecki> zyga: yeha, go ahead and restart it
<mborzecki> wonder if it has something to do with sequence of jobs
<zyga> oh
<zyga> probably yes
<zyga> + systemctl is-active snapd.snap-repair.timer
<zyga> inactive
<zyga> on unrelated branch
<zyga> more of the log https://www.irccloud.com/pastebin/3hQc0OMj/
<mup> PR snapd#5281 closed: snap: reject more layout locations <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5281>
<zyga> good morning mvo
<mvo> zyga: good morning
<mvo> zyga: 5274 should have some answers for you :)
<zyga> looking :")
<mup> PR snapd#5282 closed: interfaces/raw-usb: also allow usb serial devices <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5282>
<zyga> mvo: approved
<mvo> zyga: \o/
<zyga> for clarity about canConfigure
<zyga> I recently wrote functions like this: https://github.com/snapcore/snapd/pull/5278/files#diff-4480ffd44957efa3395867c929f88014R99
<mup> PR #5278: cmd/snap-update-ns: add IsTrustedTmpfs and tests <Created by zyga> <https://github.com/snapcore/snapd/pull/5278>
<mup> PR snapd#5274 closed: configstate: deny configuration of base snaps and for the "snapd" snap <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5274>
<zyga> and it made me think about giving a yes-or-no answer
<mvo> zyga: looking, I need to do a followup anyway
<zyga> and being able to say "error" as a third option
<zyga> I'm not saying you need to do the same
<zyga> but I just wanted to show how encoding "no" in a an error may or may not be natural, depending on context
<zyga> (and my PR needs changes too, I'm on that now)
<mvo> zyga: right, in this func its just two states: configuration is ok or there is some error that needs reporting
 * mvo gets breakfast
<mborzecki> mvo: hey
<jamesh> zyga: thanks for the extra review feedback on my PR.  The SUSE failure is due to package naming (I checked the website for the most recent version, which differs from what we're running in Spread). I'm doing some tests to see why it is failing on 14.04
<zyga> jamesh: as for suse, I will open a PR to see if we can use tumbleweed
<zyga> tumbleweed is a better indication of things working or not working in upcoming releases of leap so it will be very useful for testing
<jamesh> zyga: I was looking at OpenSUSE Leap 15 (which is newer than Leap 42.3)
<zyga> yeah :-)
<zyga> if you want to test on one machine, use tumbleweed
<zyga> it's still close to leap and it stays current
<mvo> jdstrand: just fyi, I cherry picked "interfaces/raw-usb: also allow usb serial devices"
<mvo> jdstrand: I think its a really nice fix
<mup> PR snapd#5283 opened: snapstate: get rid of needsMaybeCore <Created by mvo5> <https://github.com/snapcore/snapd/pull/5283>
<mborzecki> suggestions on how to pass a name for parallel installation when installing with `snap install --dangerous foo.snap` ?
<zyga> interesting
<zyga> snap install --dangerous foo.snap --as foo_prod
<zyga> --instance prod
<zyga> but also foo_prod.snap
<mborzecki> hm afaict we ignore the name of the *.snap file and only look at the contents
<zyga> we should be careful in case someone builds a snap like foo-2_amd64.snap
<mborzecki> snap install --dangerous foo.snap:foo_prod maybe? slightly unintuitive
<mborzecki> --as sounds nice
<mborzecki> zyga: btw. that snap-repair.timer did not reproduce when running with the same seed as travis, so maybe it's not the order of tests after all
<zyga> but if we ignore the filename and use meta/snap.yaml name
<zyga> then --instance feels more appropriate
<mborzecki> --dangerous foo.snap --instance foo_bar?
<zyga> I'd just say --instance prod
<zyga> as we would ignore the foo_ part anyway
<mborzecki> we do enforce single snap installation when using *.snap file, so --instance/--as might be ok
<zyga> mborzecki: then the only remaining issue is that "snap install foo bar --instance ..." is perhaps confusing
<zyga> and should be disallowed
<pstolowski> mornings
<zyga> hej pawel
<mvo> hey pstolowski and mborzecki
<OlofL> I use ubuntu and onlyoffice. But i can not use local printers. only print2pdf is available. any suggestions?
<zyga> OlofL: it _may_ be unsupported
<zyga> OlofL: can you please open a terminal and run "snap interfaces | grep cups" and paste that here
<OlofL> :cups-control                              - -                                          notepad-plus-plus:cups-control -                                          onlyoffice-desktopeditors:cups-control
<zyga> sorry, can you please paste that to pastebin.ubuntu.com
<zyga> the newlines matter and I cannot see them clearly here
<mborzecki> pedronis: thank you for your review on 5253
<OlofL> zyga:  https://pastebin.ubuntu.com/p/TPrkrb8JF9/
<zyga> right
<zyga> thank you
<zyga> this says that the snap is _not_ connected to cups-control interface
<zyga> I would suggest you do
<zyga> sudo snap connect onlyoffice-desktopeditors:cups-control
<zyga> and restart the application
<zyga> this should give it access to your printers
<pedronis> mborzecki: hi, IÂ have not finished though as I wrote, IÂ will list some of the areas IÂ mentioned also in the topic
 * pedronis breakfast
<mborzecki> pedronis: thanks!
<jamesh> zyga: is google:ubuntu-core-16-64:tests/main/ubuntu-core-services known to be flaky, or is that likely to be something from my PR?
<zyga> jamesh: perhaps flaky, mborzecki is investigating a failure today
<jamesh> zyga: okay.  That's the only one failing on my PR, and I can't think of how it'd be related.
<jamesh> that said, changing "snap run" has the potential for unintended side effects ...
<mborzecki> heh, ran the whole ubuntu-core test suite twice now, not reproduced :/
<OlofL> zyga: it worked. Only to discover onlyoffice print options just suck. it ended up printing 1 A4 page to 6 pages!
<zyga> well, little by little, there's some progress :)
<OlofL> meh. :P Installed libreoffice instead. CBA with all the issues
<mup> PR snapd#5284 opened: data/systemd/snapd.run-from-snap: ensure snapd tooling is available <Created by mvo5> <https://github.com/snapcore/snapd/pull/5284>
<mup> PR snapd#5285 opened: tests/main/{snap-repair,ubuntu-core-services}: add debug information <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5285>
<mborzecki> let's see if it reproduces in this one ^^
<mborzecki> pedronis: do you think it would be helpful if i shove the changes that make use if instance key in snapsup into the current PR?
<pedronis> mborzecki: yes, it would be definitely more consistent  (given that is using the original fields atm)
<mborzecki> ok
<pstolowski> all, please let me know if you see econnreset test failure again; the PR that adds extra debug was merged yesterday so we might see some more info
<pedronis> mborzecki: I added the notes I had in mind to the topic, let me know if you have questions, I'm not sure you are familiar with some of things IÂ mention there
<mborzecki> pedronis: thanks, well i will have questions :)
<pedronis> mborzecki: :),  I suspect working on this is a bit of a crash course in all things snapd,  IÂ mean *all* things
<mborzecki> pedronis: yup, but it's fun
<zyga> mborzecki: then you hit a kernel bug and the fun continues on level 2
<mup> PR snapd#5286 opened: snapstate: fix assumptions about core in setup phase2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5286>
 * zyga -> short walk
<mvo> 5176 needs a second review
<mvo> should be (hopefully) simple
<newbee> Hi guys, I have a java program that list the Serial-port in my Ubuntu 16.4 LTS system, its working fine, listing all the serial ports in my system . Then I created the snap of the same project as per the snapcraft instruction, after install the snap in my Ubuntu 16.4 LTS system , its not list the serial ports. As per the documentation I also create custom gadget snap. But when iI install the gadget. snap it shows error,"cannot insta
<newbee> Please someone help me to solve this...
<zyga> back
<zyga> way too hot todaty
<zyga> newbee: you cannot install gadget snaps on normal systems
<zyga> newbee: since you ask this question over and over I will respond clearly: you cannot make this work on a regular (laptop/desktop) system yet
<zyga> newbee: you must run unconfined for now (use --devmode)
<zyga> newbee: eventually it will work but the work on hot plug devices is just beginning
<zyga> newbee: your snap would work on a dell edge gateway for example
<zyga> newbee: where it would get serial port definitions from the gadget
<zyga> newbee: because that system is a "core" system (unlike a classic system that most people run)
<zyga> and as a core system it has a gadget snap pre-installed
<zyga> mborzecki: https://api.travis-ci.org/v3/job/389629553/log.txt
<zyga> pstolowski: ^
<zyga> econreset failed
<zyga> as well as ubuntu-core-services
<pstolowski> ty!
<mborzecki> jackpot
<pstolowski> very nices, DEBUG: Not retrying: &net.OpError{Op:"dial", Net:"tcp", Source:net.Addr(nil), Addr:(*net.TCPAddr)(0xc8203b8e70), Err:(*os.SyscallError)(0xc82042cb80)}
<pstolowski> *nice
<mvo> woah, syscall error
<newbee> @Zyga : Ok, Thanks...
<zyga> that syscall error is ... probably.. EINTR
<zyga> but hard to know
<zyga> is there something more that shows it?
<pedronis> I woudl expect the go runtime to handle EINTR
<pstolowski> indeed
<pedronis> seems we need more debugging code, to extract those things
<pstolowski> or just retry if on op error = dial, there is no harm in retrying is it?
<mvo> zyga: could you please set the series to "xenial" forhttps://code.launchpad.net/~canonical-foundations/+snap/pc-i386  ?
<mvo> zyga: and the same for pc-amd64 ?
<mvo> zyga: and rebuild both?
<zyga> mhm
<zyga> hmm
 * zyga looks for any edit controls
<zyga> I cannot
<zyga> mvo: I gave this up to foundations and no longer control it
<zyga> slangasek: ^
<mvo> zyga: oh, you no longer own that - ok
<mvo> sil2100, slangasek could you please set https://code.launchpad.net/~canonical-foundations/+snap/pc-i386 and (-amd64) to series "xenial" and build again? we landedhttps://github.com/snapcore/pc-i386-gadget/pull/5  and would like to update the gadget with that in the store
<mup> PR pc-i386-gadget#5: grub.cfg: allow customizing the menuentry via a new "snap_menuentry" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/pc-i386-gadget/pull/5>
<sil2100> mvo: I'll be on it in a few!
<mvo> sil2100: thank you
<mvo> sil2100: but no rush, its not OMGnow priority :)
<newbee> @Zyga Once again thanks.. Now I am able read the serial-port in ubuntu 16.04 LTS system using snap application.
<zyga> newbee: I understand this is frustrating, I suspect you will be able to use fully confined application with serial ports on 16.04 in 2-3 months from now
<mvo> a second review for 5176 would be great, that would unblock a new 2.33 upload
<zyga> mvo: is the nack from gustavo fixed?
<zyga> mvo: asked one wrench-in-the-gear question
<zyga> mvo: or in other words, reboot your router and run the connectivity check
<pstolowski> caution to anyone doing self-review... browser session in the tool times-out in very annoying manner, if you hit save after a long period of inactivity on the page, it logs you out and whatever you typed is lost! best to prepare it in a text editor first...
<zyga> thanks pawel
<zyga> I haven't done mine yet so I will use this for sure
<mvo> zyga: I think the gustavo nack is resolved
<mvo> zyga: and answered the question :)
<zyga> mvo: ping is not a good example as it is a synchronous process doing the test
<zyga> I can approve this but my gut feeling says it should be async
<zyga> and AFAIK we cannot change the API later because users
<mvo> zyga: maybe I'm not understanding, but what is the concern about this being sync? that the user waits for some seconds on a reply?
<zyga> it can take very long to respond
<mvo> zyga: for a consumer script an async interface is more work, it would be "snap debug connectivity; snap changes --last=debug; snap list etc"
<zyga> and we don't do long things in a sync way
<zyga> not quite, the command could poll
<zyga> the UX could stay the same
<zyga> (though it could get smarter as well, e.g. by reporting progress in real time)
<mvo> zyga: is the concern about the server side that its sync there?
<zyga> but my main gripe is with the call me and wait for unbound amount of time for a response
<zyga> yes
<zyga> this feels the same like install
<zyga> and I fear that changing it later would suck
<zyga> (for complexity)
<mvo> zyga: don't we run this inside a goroutine? the request handling? and we unlock the state while doing this
<zyga> perhaps but the client may just time out waiting
<zyga> perhaps pedronis should decide
<zyga> as I said, if you feel strongly about it I can approve
<zyga> the code looks okay otherwise
<mvo> zyga: its fine, I am just trying to understand the concern
<mvo> zyga: a bit of a shame that chipaca is not around today, he knows this probably best
<mvo> zyga: I just checked the code, we don't do a timeout in the client for sync methods. and I added a 30s delay (just to test things) and snapd is fine, both responsive and no observable issue on the client side
<mvo> zyga: but maybe pedronis has an opinion about whether "debug connectivity" should be a sync or async reply - just to ensure that we carefully looked at this
<mvo> zyga: or we can talk during the standup. thanks for your review in any case :)
<mborzecki> pedronis: is it intentional that when store.SnapAction.Action == "refres" the Name field is not used?
<pedronis> mborzecki: yes
<pedronis> refreshes are purely instance-key and snap-id based
<mborzecki> pedronis: is it ok if i pass name nonetheless? i need to construct unique instance keys, snap-id is the same, so appending name would give me the unique part
<pedronis> mborzecki: pass where?
<mborzecki> down to store.SnapAction()
<pedronis> mborzecki: as I wrote we have two options with the store interface
<pedronis> either we make all the store apis take instance names
<pedronis> or we tweak SnapAction to take instance keys explicitly
<pedronis> and deal with things one level up
<mborzecki> i'm tweaking SnapAction :)
<pedronis> mborzecki: I think tweaking SnapAction is less magic so probably easier, but both are ok, as long as we consistent
<pedronis> mborzecki: but as I said if you tweak SnapAction is not a matter of passing name
<mborzecki> pedronis: so basically suggesting is to extend store.CurrentSnap with InstanceKey explicitly?
<pedronis> mborzecki: yes
<pedronis> and action too
<mborzecki> pedronis: right
<pedronis> mborzecki: if we start passing down instance keys, we need to do the same with the info stuff
<pedronis> but I can see pros and cons for both
<pedronis> you need to see a bit
<pedronis> mborzecki: btw probably a good time to kill a couple of left overs apis that are not used
<mborzecki> pedronis: i'm doing the changes right now, so we'll see in a bit whether this feels ok or not
<mborzecki> pedronis: which ones?
<pedronis> ListRefresh and LookupRefresh
<pedronis> they should be unused now
<pedronis> (SnapAction took over)
<mborzecki> pedronis: ok, let me note that down and i'll look into it
<pedronis> mborzecki: probably best done on its own branch, but especially if you decide to pass in instance names
<pedronis> then you don't want to have to fix those
<mborzecki> ack
<pedronis> mborzecki: to be clear they are still there because the switch to SnapAction happened late in 2.32, and there was a chance to have to revert it, also it would have a lot more late churn to remove them
<pedronis> mborzecki: but 2.33/2.34 is a good time to remove them, now that we known happy with SnapAction
<mborzecki> ok
<mborzecki> i'm off for a while, bbl, will miss the standup today, see the note in the forum
<niemeyer> mvo: Heya
<niemeyer> mvo: Haven't seen the updated PR, but as a minor, if you implemented a restricted language, I suggest just sticking to the field names we use in the API
<niemeyer> mvo: So we have a single set of those to keep promises on
<mup> PR snapd#5287 opened: testutil: syscall sequence checker <Created by zyga> <https://github.com/snapcore/snapd/pull/5287>
<jdstrand> mvo: thanks! I wasn't sure if it could make it into 2.33 :)
<zyga> jdstrand: hey, could you please look at https://github.com/snapcore/snapd/pull/5278
<zyga> this would unblock the next chunk
<mup> PR #5278: cmd/snap-update-ns: add IsTrustedTmpfs and tests <Created by zyga> <https://github.com/snapcore/snapd/pull/5278>
<zyga> one new function with tests and docs
<zyga> jdstrand: also (though not security sensitive so no need to use your time) 5287 will aid in writing tests
<zyga> but it's Friday so .. maybe :)
 * cachio afk
<jdstrand> zyga: I started looking at 5278 yesterday and I was trying to imagine who the consumers of the API will be
<zyga> this is the trespassing issue again
<zyga> with a richer fix that works in containers
<jdstrand> zyga: I guess I'm slightly uncomfortable with the word 'trusted'
<zyga> the rule is that we allow writing to read-only filesystems (mounted ro or squashfs)
<zyga> and the tmpfs'es that we have mounted ourselves
<zyga> and since none of the tmpfses that we mount are visible outside, we trust that they don't show up in the host
<jdstrand> IsSnapdCreatedTmpfs?
<zyga> I can rename it, sure no
<zyga> *no problem
<jdstrand> isSnapdCreatedPrivateTmpfs?
<zyga> even better
<jdstrand> let's see how many words we can cram into the variable :P
<zyga> any, but they must fit in 8 characters ;)
<zyga> ShouldWriteToTmpfs?
<jdstrand> iscpt()
<jdstrand> is cape town?
<jdstrand> hee
<zyga> haha
<jdstrand> anyhoo, I'll trust you on a rename. trusted is perhaps unsurprisingly a loaded word for me
<zyga> understood :)
<jdstrand> I'll add 5287 too
<jdstrand> :w
<pedronis> afaik so far we use it only in the contest of assertions for the root keys/accounts
<zyga> woah
<zyga> a fire extinguisher just exploded downstairs
<mup> PR snapd#5288 opened: tests: econnreset/retry tweaks <Created by stolowski> <https://github.com/snapcore/snapd/pull/5288>
<pstolowski|lunch> zyga: woah, i thought it was only possible in duke nukem when you shot them ;)
<zyga> we are just as surprised
<mvo> jdstrand: heh, today is the day for final tweaks for 2.33, this one was just too nice to pass up
<cwayne> mvo: aha, so should I be expecting some test results soon then?
<mvo> pedronis: do you happen to have an opinion about the sync/async reply (zyga question in 5176). I would love to do something about this one as its the last piece misisng for 2.33
<mvo> cwayne: yeah, hopefully a new beta later today, one open PR though that has some discussion right now :)
<pstolowski> mvo: thanks for the review! i wonder if it would be better to log %#v instead of "Retrying because of: %s" for all retried errors
<mvo> cwayne: but I hope it can go all the way from beta->candidate today (if not Monday is fine as well)
<pedronis> mvo: we don't have set a timeout on daemon response right? given that is a debug command IÂ think sync is fine, unless it would break, we are not keeping the lock
<mvo> pedronis: yeah, no timeout for sync responses. great, I think we are in agreement.
<mvo> zyga: ^- thanks again for raising/discussing this! if the PR is otherwise ok I would love to move forward with it
<zyga> mvo: +1 then
<cwayne> mvo: sounds good, I'll make sure we're on the lookout for results
<mvo> zyga: ta
<mvo> cwayne: ta to you as well :)
<mup> PR snapd#5176 closed: many: add `snap connectivity-check` command <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5176>
<zyga> uh
<zyga> the dust is so irrating
<zyga> the air filter has gone crazy
<zyga> 269 PM2.5
<zyga> like in the suburbs in the winter ;)
<niemeyer> Hey there
<niemeyer> Stopped for a cuppa
<niemeyer> cachio: How's Travis?
<niemeyer> mvo: All good on the front of the format thing? Not sure if you saw the earlier note
<niemeyer> Happy standup :)
<mup> PR snapd#5289 opened: cmd/snap-update-ns: fix a leaking file descriptor in MkSymlink <Critical> <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5289>
<zyga> jdstrand: ^ trivial leak fix
<mup> PR snapd#5290 opened: packaging: use official bolt in the errtracker <Created by mvo5> <https://github.com/snapcore/snapd/pull/5290>
<zyga> jdstrand: also interesting that unit tests that mock the system call level help to find issues like that
<pstolowski> mvo: the PR I talked about when we started the standup - #5215
<mup> PR #5215: ifacestate: improved conflict and error handling when creating autoconnect tasks <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5215>
<cachio> mvo, about the symliinks test
<cachio> it is needed a fix for that yet
<cachio> could you reproduce it?
<mvo> cachio: I couldn't but let me try again. what was the link to your script again ? the one you use to build the image?
<mvo> cachio: I will try to reproduce in a clean VM this time
<mvo> cachio: to ensure no contamination :)
<cachio> mvo, https://github.com/sergiocazzolato/validator/blob/master/create.sh
<mvo> cachio: ta
<sil2100> mvo: kicked the builds now (sorry for the wait!)
 * zyga goes out until the dust is filtered/vented
<zyga> mvo: I'm always available on telegram/irc and I can return earlier if needed
<mvo> zyga: thanks, should be fine. see you
<mvo> cachio: channel is beta, right?
<zyga> more errors with snap-repair
<zyga> https://api.travis-ci.org/v3/job/389723922/log.txt
<cachio> mvo, yes
<mvo> cachio: ok, on it (in a fresh vm)
<cachio> mvo, great, thanks
<mvo> cachio: I tried in a clean vm, installed ubuntu-image using apt, installed snap via snap install --beta core and the created image has symlinks
<sil2100> huh, store authorization failure for the pc-* snaps
<ogra_> token needs refresh most likely
<ogra_> there is a LP UI for that
<sil2100> Doing that, was surprised as I didn't see that before
<sil2100> Maybe I'm not using LP to build snaps enough
<ogra_> yeah, happens very rarely (but happens)
<cachio> mvo, I don't do that
<cachio> mvo, I create the beta image with this script
<cachio> the I create a vm with this image
<cachio> then I login and I dont see the symlinks
<cachio> kvm -snapshot -smp 2 -m 2000 -redir tcp:8022::22 -nographic -serial mon:stdio <PATH-TO-IMG>
<mvo> cachio: if you run "which ubuntu-image" - what do you get?
<cachio> I create the vm with this command
<cachio> this /usr/bin/ubuntu-image
<mvo> cachio: ok, this looks fine. and snap version?
<mvo> cachio: how big is the image file? ls -lh for the amd64 image?
<cachio> mvo, 3,0G may 29 14:49 pc.img
<cjwatson> sil2100: there's (unfortunately, out of LP's control) a hard one-year expiry on store macaroons
<cjwatson> sil2100: so that can make you have to reauth even if you use it frequently
<mvo> cachio: hm, I just downloaded the image I created in the vm, booted it and still see the symlinks in /var/lib/snapd/snaps. confusing
<cachio> mvo, I create the image in my pc
<cachio> mvo, did you try that
<cachio> then create the vm in your pc as well
<cachio> that's what I am doing
<mvo> cachio: I create the image in a clean 16.04 VM to make sure its not my local environment that changes things. I can also try that in a bionic VM if that is useful.
<sil2100> cjwatson: ah, so that's why, thanks for the info
<cachio> mvo, I'll try the same
<mvo> cachio: thank you, I try bionic now
<mvo> 5290 needs a review (should be trivial)
<mvo> cachio: same in my bionic vm with ubuntu-image from the deb and core from beta I get the "small" image iwth the symlinks. sorry :/
<cachio> mvo, still creating the image here
<mvo> cachio: ok, good luck
<cachio> I'll let you know once it is finished
<mvo> mborzecki: thanks for your review
<mvo> cachio: fingers crossed, really curious that we get different results
<pedronis> mvo: do you have a sense of which snapd version will be in 18.04.01,  2.33,  .34 ?
<mvo> pedronis: should be .34
<mvo> pedronis: worst case we can do a point release of 2.33 - do you need anything specific in it?
<cachio> mvo, sale issue
<cachio> sergio-j-cazzolato@localhost:~$ readlink -f /var/lib/snapd/snaps/core_4734.snap
<cachio> -> /var/lib/snapd/snaps/core_4734.snap
<mvo> cachio: oh, symlinks. that looks good, no?
<cachio> mvo, based on the test it should point to /var/lib/snapd/seed/snaps/core_4734.snap
<cachio> I tested that in a vm on google and it works fine
<cachio> in a core 16
<pedronis> mvo: I think we want the switch to /v2/info and download action by it
<pedronis> mvo: I'll talk with John on monday and see if he wants to work on that or it's on me
<mvo> pedronis: ok
<mvo> cachio: oh, sorry, misread. so no symlinks in (ls -al /var/lib/snapd/snaps)?
<cachio> exactly
<cachio> mvo, snap-core-symlinks test failing
<mvo> cachio: what is output of "snap version" and "apt list ubuntu-image" where the image was created? could you please pastebin that?
<cachio> snap    2.33~rc1
<cachio> snapd   2.33~rc1
<cachio> series  16
<cachio> kernel  4.4.0-128-generic
<mvo> cachio: and "apt list ubuntu-image"?
<cachio> this is in the vm which I used to create the image
<cachio> ubuntu-image/xenial-updates,xenial-updates,now 1.3+16.04ubuntu2 all [installed]
<cachio> ubuntu@vm-16:~/src/validator$ snap version
<cachio> snap    2.32.9
<cachio> snapd   2.32.9
<cachio> series  16
<cachio> ubuntu  16.04
<cachio> kernel  4.13.0-32-generic
<mvo> cachio: the first version looks fine, the second "snap version" output is a version that does not have the new functionatlity for the symlink creation yet
<mvo> cachio: could you please try to "snap refresh --beta core" in this machine with the second output and create the image again?
<mvo> cachio: the machine should have output like the first (i.e. snap version 2.33~rc1)
<cachio> mvo, sure
<mvo> cachio: thank you
<mup> PR snapd#5290 closed: packaging: use official bolt in the errtracker on fedora <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5290>
<cachio> mvo, working now
<cachio> with beta core on the machine where I built the image
<cachio> thanks!!
<mvo> cachio: great!
 * cachio lunch
<kyrofa> Hey zyga, any chance you've made some progress experimenting with CUDA? https://forum.snapcraft.io/t/nvidia-cuda-on-ubuntu-core/292/4
<pstolowski> mvo, zyga Retrying because of: &net.OpError{Op:"dial", Net:"tcp", Source:net.Addr(nil), Addr:(*net.TCPAddr)(0xc420509080), Err:(*os.SyscallError)(0xc42044f1c0)} (syscall error: 0x6f); it's ECONNREFUSED
<pstolowski> mvo: zyga however, my PR just failed on econnreset test (bummer)
<zyga> kyrofa: no, not at all actually :-(
<zyga> kyrofa: mborzecki has the hardware now
<mup> PR snapd#5291 opened: release: 2.33 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5291>
<zyga> pstolowski: connection refused, curious
<zyga> Is that taking to the real store or to the fake store?
<mvo> pstolowski: interessting
<pstolowski> there is something more going on when this happens... i see my changes kick in with assertions (the above error), but the actual download attempt that we match on in the test is attempted with attempt=1 only (but multiple times)
<pstolowski> i save the log and will look at it with fresh mind on monday
<pstolowski> have a good weekend!
<cachio> mvo, are you creating a new beta today?
<jdstrand> roadmr: hi! can you pull r1089 of the review-tools. not urgent
<roadmr> jdstrand: totally!
<jdstrand> greyback: that has the override fixes we discussed ^
<greyback> jdstrand: awesome, thanks!
<jdstrand> roadmr: curious on the status of the requash enablement? I see r1086 is deployed
<cachio> zyga, quick question https://paste.ubuntu.com/p/WRyvxWqXFj/
<cachio> zyga, quick question https://paste.ubuntu.com/p/WRyvxWqXFj/
<cachio> there is a problem with apparmor parser executing the test interfaces-calendar-service
<zyga> Uname -a?
<cachio> should we consider this error?
<cachio> Linux jun081014-974428 4.4.104-39-default #1 SMP Thu Jan 4 08:11:03 UTC 2018 (7db1912) x86_64 x86_64 x86_64 GNU/Linux
<zyga> Most likely yes
<zyga> Yes
<cachio> it is opensuse-42.3-64
<zyga> Looks like a bug
<cachio> ok
<mvo> cachio: yes, 2.33 is in the beta channel now (cc cwayne)
<zyga> re
<mup> PR snapd#5289 closed: cmd/snap-update-ns: fix a leaking file descriptor in MkSymlink <Critical> <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5289>
<slizard> hi folks. I'm seeing some funny stuff in dmesg about apparmor denying the Telegram app do do "mknod" (http://termbin.com/i7eb). Not too familiar with the internals of snaps, but this is somewhat unexpected. Thoughts?
<zyga> slizard: looking
<zyga> most likely harmless
<zyga> ideally we'd look at telegram source code to see what's the impact though
<mup> PR snapd#5287 closed: testutil: syscall sequence checker <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5287>
<mup> PR snapd#5291 closed: release: 2.33 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5291>
<mvo> zyga: \o/ thanks for the merge
<zyga> :-)
<zyga> thank you for the release
<zyga> btw, the tooling PR
<mvo> my pleasure
<zyga> I asked for a mount unit instead but if you feel strongly or it is just important to land quickly I can also ack that as-si
<zyga> *as-is
<zyga> mvo: some build failures in the ppa
<zyga> tests
<slizard> <zyga>: thanks for checking.
<mvo> zyga: oh, do you have a link?
<zyga> https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+build/14994462
<mvo> zyga: hm, hm, FAIL: devicestate_test.go:488: deviceMgrSuite.TestFullDeviceRegistrationHappyClassicFallback
<jdstrand> slizard: I think that the telegram snap may have been updated underneath your running telegram. if you stop and restart, that should go away
<mvo> zyga: might be a racy test
<slizard> <zyga>: let me check/
<jdstrand> slizard: it is a known issue that will be addressed
<jdstrand> roadmr: not sure you saw my question re turning resquashfs back to enforce. I see r1086 is in the store (thanks!). let's wait til Monday to flip the switch, that way we'll be around if needed
<zyga> jdstrand: mmm, same refresh problem as always?
<jdstrand> zyga: yes
<roadmr> jdstrand: right, best to wait for monday, and apologies, I missed the question earlier :(
<jdstrand> zyga: the snap has write access to that directory. the only thing it could be was the revision changed from under the running snap
<jdstrand> roadmr: I'll be starting my holiday on friday (through all of the following week), so I think 4 days of burn in would be a fine indicator
<jdstrand> it worked really well last time except for electron, which is now fixed upstream and the tools tell people which electron to get, etc, etc, etc
<roadmr> jdstrand: agreed and we can always flip it off if in doubt and you're not around or somethiing
<jdstrand> yeah
<jdstrand> roadmr: I don't know if we'll have something quite like this again, but it is a nice mechanism
<roadmr> yep :)
<mup> PR snapcraft#2128 opened: project_loader: stop setting LD_LIBRARY_PATH <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2128>
<slizard> <jdstrand>: thanks! Restart indeed showed update message and warning is gone.
<jdstrand> slizard: cool. sorry for the issue; it's on the roadmap to get cleaned up
<slizard> <jdstrand>: no worries. just wanted to check whether there is an issue that requires attention.
 * jdstrand nods
<jdstrand> there is ;)
 * cachio afk
 * zyga prepares a monster patch
<mborzecki> zyga: challenge? :) is it larger than 5253?
<zyga> mborzecki: we shall see :>
<mborzecki> hehe
<zyga> probably not though :)
<mborzecki> 5258 finally failed the way i wanted it to, apparently snapd.snap-repair.timer is stopped right before the test (?) https://paste.ubuntu.com/p/tD7xrcqPb2/
<mborzecki> Fri Jun  8 17:33:49 UTC 2018 is when debug section is entered, while InactiveEnterTimestamp=Fri 2018-06-08 17:32:22 UTC
<mup> PR snapd#5292 opened: Update docker-support interface for 18.05 <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5292>
<mup> PR snapd#5293 opened: tests: add retry until the xdg dir can be removed on interfaces-calendar <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5293>
#snappy 2018-06-09
<Danawar[UK]> Hi Snappy after updating last night a couple of my snaps are no longer working can any one advise - https://pastebin.com/c7CR0iZr
<zyga> Danawar[UK]: hey, does it help if you restart the apps?
<Danawar[UK]> zyga: Cant start the apps to restart them?
<zyga> Danawar[UK]: are you saying you can no longer run snap applications?
<popey> Are you in a Wayland session where previously you were not?
<popey> Maybe log out and back in, and make sure your session is xorg
<Danawar[UK]> zyga: Some run some don't
<Danawar[UK]> popey: I believe i have tried using Wayland and not i don't either work
<Danawar[UK]> let me start another session and try
<popey> It looks very like X isn't running
<Danawar[UK]> Sorry a noob question relating to the above from a tty how can i start a new login screen and login with out wayland?
<Danawar[UK]> It looks like I was in xorg am now in snappy still have the same issue.
<Danawar[UK]> I am now in wayland*
<Danawar[UK]> Hi snappy i am having issues running 2 programs after an update this morning if any one could help it would be greatly appreciated. https://pastebin.com/c4JiUEBB
<Danawar[UK]> Further to my above question it looked like reinstall both snaps work so could be an issue there.
#snappy 2018-06-10
<cjwatson> popey: hey, do you have any examples of electron-builder snaps that fail to build for networky sorts of reasons on BSI?
<cjwatson> popey: elopio filed a bug about one of those a while back, but the GH repository for it is gone
<popey> cjwatson: we generally don't hook e-b apps to bsi. Because it doesn't build with a yaml in the root
<cjwatson> popey: Can you explain that a bit further?
<popey_> cjwatson: sorry for the delay, irccloud-desktop from edge is segfaulting and I'm on 50K/s wifi
<popey_> cjwatson: so, electron-builder knows how to build snaps. A single line in the package.json in the root of an electron-builder based project is often enough to spit out a valid snap
<popey_> cjwatson: sometimes you need extra stuff like interfaces listed, or stage-packages, but often not.
<popey_> cjwatson: internally e-b will build the application with npm/yarn or whatever, and then bundle the built assets into a snap (I think using snapcraft)
<popey_> cjwatson: so e-b projects don't actually have a snapcraft.yaml anywhere in their source tree, it gets generated (I think) at build time, and then thrown away.
<cjwatson> popey_: Ah, so https://bugs.launchpad.net/launchpad-buildd/+bug/1732811 was an anomaly?
<mup> Bug #1732811: glowing-bear fails to build, but it works on container build <launchpad-buildd:Incomplete> <https://launchpad.net/bugs/1732811>
<cjwatson> I assumed from that bug that there was some kind of wrapper boilerplate in snapcraft.yaml that called electron-builder.
<popey_> yeah, i dunno what it did, we nuked it because it was all broken
<popey_> so it could well be an anomoly, I'd close it and we can re-open if we see it again
<cjwatson> popey_: OK, would you mind doing that?  Always good to have the user('s team) withdraw rather than the nasty evil maintainer wontfixing :)
<cjwatson> popey_: I think my proxy work will likely take care of the specific download problem there in any case
<popey> :D
<cjwatson> (well, maybe; or else it'll require the same kind of more heroic measures that bloody maven-ant-tasks will)
<popey> oh. you've fixed maven? :)
<cjwatson> ... sort of, in some cases
<cjwatson> maven-ant-tasks is a special snowflake
<popey> ah okay.
<cjwatson> I have a fix for the general case of stuff that doesn't work with authed proxies
<cjwatson> but maven-ant-tasks is terrible and is just ignoring me no matter what I try
<cjwatson> I think I must have insulted its ancestors or something
<popey> More free software developers should have to live behind proxy servers. This stuff would happen less often.
<cjwatson> I do find it astonishing that Java stuff doesn't work right, given the corporate world
<popey> yeah
<cjwatson> the internet is full of half-complete threads to the effect of "how do I get maven to work behind my proxy" that sort of tail off
<popey> :(
<cjwatson> anyway, I have an evil plan
<cjwatson> it may involve iptables and redsocks
<popey> evil plans are best plans
<cjwatson> http://grokbase.com/t/ant/user/166fc12046/maven-ant-tasks-proxy-issue is one of the threads I mentioned and is somebody with essentially the same requirements we do
<cjwatson> i.e. put a proxy in place without changing the actual project's build config
<vidal72[m]> is something like this ok to be allowed on snapstore? https://snapcraft.io/juan-test-number-1
<Luke> hey guys. is there a comprehensive doc on the $SNAP variables available for snapcraft?
<Luke> hey guys. is there a comprehensive doc on the $SNAP variables available for snapcraft?
<Luke> (sorry if I sent that twice, wasn't sure if I was online yet)
<Luke> ah I found it!
<Luke> https://docs.snapcraft.io/reference/env
<Luke> how do I just copy a file form src into the install dir?
<binarycreations> Hello there
<Luke> hey
<binarycreations> For better or worse I am running on Arch atm, trying to create my first snap. Followed the wiki to symlink /snap to the right location and read the same on the forum. However still can't install snapcraft as I am getting the --classic isn't supported error.
<binarycreations> Listing snap --version gives me an Unknown version but the installed package is 2.26.1-3
<binarycreations> Sorry I can't provide any more information.
<binarycreations> Is there any way I can get more detailed logging or output from the snap command? More than happy to spend a bit of time walking through this a bit more
<binarycreations> Okay, I have rebuilt the latest package from the AUR manually. The same error still exists
<binarycreations> Okay... so re-installed the snap again, deleted existing snaps first and now that appears to have worked. Output from snap --version looks much better. snap and snapd report version 2.32.9-1, I will assume stupidity but perhaps there was an issue with older installation.
<binarycreations> snap aur*
#snappy 2019-06-03
<mborzecki> morning
<mborzecki> mup_ needs a little nudge
<zyga> hey
<zyga> mborzecki: mvo is offline
<zyga> mborzecki: he asked to relay to the team
<zyga> mborzecki: over weekend I noticed master is broken
<zyga> mborzecki: ineffectual assignment in shlex.go
<zyga> mborzecki: I'll start around ~10 today, moving downtown to work from a cafeteria, it's super hot in the office today, I have no AC here
<mborzecki> zyga: hey, there's a PR fixing this up already
<zyga> mborzecki: super, looking
<zyga> mborzecki: let's land it and notify chipaca when he's around
<mborzecki> zyga: ok
<zyga> mborzecki: can you please review https://github.com/snapcore/snapd/pull/6940 -- I will need it today
<zyga> it's just python compatibility for mountinfo-tool
<mborzecki> zyga: ack, looking
<zyga> I didn't commit that because I'm not quite sure where to put it
<zyga> but I have a makefile there that does
<zyga> black, flak8, mypy -2 and mypy checks
<zyga> (and shellcheck on the shell script)
<zyga> and this is 100% green
<mborzecki> heh
<mborzecki> need more python linters
<mborzecki> zyga: that's because of 14.04 right?
<zyga> not even that
<zyga> it's mainly because we need 2.7 for places like amazon
<zyga> on the upside, now it's compatible with everything
<mborzecki> zyga: yeah, but the looks of it :/
<zyga> mborzecki: it's not too bad
<zyga> mborzecki: I actually think that function signatures are nicer when they are on the following line
<zyga> only python byte/unicode quirks are ugly IMO
<zyga> ok
<zyga> packing up and going
<mborzecki> zyga: let's agree to disagree :)
<zyga> this office is nice but during summer time it's an oven :)
<zyga> mborzecki: don't get me wrong
<zyga> mborzecki: I'd love not to have to do this :D
<zyga> mborzecki: the details we can have opinions on that diverge
<mborzecki> zyga: makes me wonder, how people actually get python3 on centos
<mborzecki> zyga: i see 3.6 in epel :)
<zyga> maybe EPEL
<mborzecki> on rh it's probably software collections
<mborzecki> zyga: so centos has python34 & python36 from epel, amzn2 has python 3.7 directly from their repos :P
<zyga> mborzecki: the tool required 3.6 before this patch
<mborzecki> zyga: right, so there's a quesion of 14.04 then
<zyga> mborzecki: hmm?
<zyga> mborzecki: it works on 14.04, I think
<zyga> I think it passed all spread locally
<pstolowski> morning
<zyga> good morning pawel
 * zyga commutes to work for a change :)
<mborzecki> pstolowski: hey
<mborzecki> looks like it's going to be quite warm today
<mborzecki> mvo: hey
<zyga> Hey mbo
<zyga> mvo:
<zyga> Working from afar today?
<zyga> okay, arrived and setting up for work
<zyga> ah --version changed across  python versions
<zyga> drat :)
<mvo> thanks for merging 6928 mborzecki
<mvo> is mup down?
<mvo> mup_: hello, how are you today?
<mborzecki> mvo: yup, it is
<zyga> mvo: mup is off today :)
 * dot-tobias says hi
<mborzecki> mvo: probably since friday, iirc there was a split during the day
<mvo> hey dot-tobias
<mvo> mborzecki: I cherry picked the ppc build fixes to 2.39 now (just fyi)
<mborzecki> mvo: can you cherry pick ineffassign fix too?
<mvo> mborzecki: sure, what pr number is/was that?
<mborzecki> mvo: it's 8d883ae66
<mvo> ta
<zyga> mvo: lets bump delta ref to 2.39.1
<mvo> mborzecki: thanks for this one! was it needed because of a new go vet?
<mborzecki> mvo: recent changes in ineffassign
 * mvo nods
<mborzecki> mvo: this commit https://github.com/gordonklaus/ineffassign/commit/8863c8f9d746c0e28d65c1bc46c8d3aa8ab1ee82 :)
<mvo> mborzecki: nice! and nice^2 for tracking the exact change down
<pstolowski> mvo: i've made the measurement before- and after- maxprocs patch, see comments below https://github.com/snapcore/snapd/pull/6933 ; unfortunately no improvement
<pstolowski> mvo: and hi btw :)
<mvo> pstolowski: goooood morning :)
<mvo> pstolowski: you rock!
<mvo> pstolowski: thank you so much, let me look at the data
<mvo> pstolowski: is there a tl;dr ?
<mvo> pstolowski: aha, looks like zero effect ?
<pstolowski> mvo: yep, random fluctuations, nothing more
<mborzecki> mvo: pstolowski: wonder if there'd be an observable change in reaching seeded target
<mvo> pstolowski: a shame - oh well
<mvo> pstolowski: what cmdline did you use to limit the cpu?
<pstolowski> mvo: setenv snappy_cmdline net.ifnames=0 init=/lib/systemd/systemd ro panic=-1 fixrtc maxcpus=1
<pstolowski> mvo: followed by saveenv
<pstolowski> mvo: verified with lscpu afterwards
<mvo> pstolowski: cool, thanks!
<zyga> mvo: https://github.com/snapcore/snapd/pull/6937/files
 * Chipaca goes for more coffee
<pstolowski> mvo: https://github.com/snapcore/snapd/pull/6925 can land?
 * zyga breaks for lunch
<zyga> Setting in
<cmatsuoka> mvo, pedronis, zyga: spike successfully installs using writable on tmpfs
<zyga> cmatsuoka: hey
<zyga> cmatsuoka: that's cool :)
<zyga> cmatsuoka: I'm progressing  towards go-only initrd that can hand off to existing stack
 * cmatsuoka notices he can't read IRC and code at the same time, he just typed "build_zyga" as a function name
<zyga> hahaha
<zyga> make -j 2
<cmatsuoka> zyga: nice! I ported writable preparation steps from shell script to go for the spike and sometimes it's a bit annoying
<cmatsuoka> I just exec.Command().Run() in some places just to keep things going
<cmatsuoka> with proper infrastructure it will be much nicer
<zyga> +1
<zyga> that's good for the spike IMO
<cmatsuoka> there are a number of hacks there that must be solved in a better way, such as console-conf telling snapd that it's done
<cmatsuoka> and when I request a reboot it takes a really long time to reboot
<mborzecki> off to pick up the kids
<mvo> cmatsuoka: awesome!
<ackk> hi, I'm trying to get chrony to work in a snap, I added the time-control interface, but getting a permission denied from adjtimex
<ackk> I'm getting no denials in logs
<cmatsuoka> mvo: we were previously injecting stuff into kernel initramfs, I'm now injecting into core and adding a custom snapd from my writable-ramdisk branch
<cmatsuoka> also core-build from writable-ramdisk branch
<mvo> cmatsuoka: so core-build is the branch I need to look at?
<cmatsuoka> you need the writable-ramdisk branch in spike-tools, core-build and snapd
<cmatsuoka> all of them are in github.com/cmatsuoka
 * mvo looks
<cmatsuoka> mvo: hmm, and I think I broke something because I can't log into the installed system anymore
 * cmatsuoka investigates
<mvo> ok
<pstolowski> #6935 needs 2nd review
<ackk> mvo, hi, any idea off the top of your head for the issue above?
<Chipaca> pstolowski: if you have a chance, can you give #6905 a look to see if your LGTM still stands? (and make it an actual +1)
<pstolowski> Chipaca: ok
<mvo> ackk: just read it, let me think for a minute
 * zyga goes to find some shade
<mvo> ackk: it sounds like its a missing syscall in the interface, let me look at the code
<ackk> mvo, thanks
<ackk> mvo, I have a simple snap which shows the issue, if it could be useful
<mvo> ackk: see #6943
<ackk> mvo, that doesn't seem like an LP bug# :)
<ackk> oh you mean https://github.com/snapcore/snapd/pull/6943
<ackk> mvo, thanks!
<mvo> ackk: yes, sorry, usually mup expands this but it seems to be off today :P
<ackk> heh
<mvo> ackk: lets see if this is enough, if you need more just let me know, hopefully will land in edge soon
<ackk> mvo, how do I get that ? via a PPA?
<ackk> (once it lands of course)
<mvo> ackk: snap install --edge core (or snapd if you use that already) should be enough
<mvo> ackk: once you are happy you can always "snap refresh --beta core" (or snapd) (or candidate/stable) to get off edge of course
<ackk> mvo, cool, thanks
<Chipaca> pstolowski: does my review make sense?
<cmatsuoka> mvo: during the spike it could be good to add systemd.debug-shell=1 to the gadget grubenv as well
<pstolowski> Chipaca: absolutely, thank you!
<pedronis> Chipaca: thx for looking at that
<mvo> cmatsuoka: yeah, I think so
 * cachio lunch
<zyga> back in the office
<zyga> sorry for the lag, had dinner too
<cmatsuoka> mvo: I'm fixing seed installation on the real writable
<jdstrand> zyga: hey, do you know who was working on '(cannot find required base "core")'? I thought that was supposed to be fixed in 2.39, but I'm seeing it
 * jdstrand has core installed
<zyga> jdstrand: I think eventually that was mvo
<zyga> how about .1?
<zyga> oh
<zyga> hmmm
<jdstrand> snap version says 2.39
<jdstrand> $ snap list core
<jdstrand> Name  Version  Rev   Tracking  Publisher   Notes
<jdstrand> core  16-2.39  6964  stable    canonicalâ  core
<jdstrand> $ sudo snap refresh review-tools
<jdstrand> error: cannot perform the following tasks:
<jdstrand> - Mount snap "review-tools" (857) (cannot find required base "core")
<jdstrand> huh
<jdstrand> so, 847 doesn't have 'base: core', but 857 does have 'base: core'
<jdstrand> hmmm, remove and install, same thing
<zyga> jdstrand: hmmm
<zyga> jdstrand: can you report it please, I'll check it out tomorrowm orning
<jdstrand> zyga (cc pedronis): https://forum.snapcraft.io/t/cannot-find-required-base-core-when-installing-refreshing-when-using-base-core/11641
<jdstrand> zyga: fyi, I refreshed to --beta (2.39.1) and it was the same thing
<jdstrand> sergiusens[m]: fyi ^ (not sure if you have anything to add to that, so just fyi)
<jdstrand> sergiusens[m]: hi btw :)
<sergiusens> hi jdstrand
<sergiusens> jdstrand: answered on the post
<jdstrand> sergiusens: thanks! trying that. is that true for snaps that use 'base: core18' too?
<jdstrand> zyga: fyi, nm, sergiusens fixed it for me (see forum)
<sergiusens> jdstrand: yes, it is true for core18 as well, let me see if I can find the launchpad bug for this
<jdstrand> sergiusens: interesting. I have some core18 snaps and didn't see this before
 * jdstrand fixes those
<ijohnson_> hey jdstrand do you think we can merge https://github.com/snapcore/snapd/pull/6805 or do we need to fix that erroneous test?
<jdstrand> ijohnson_: I'm not comfortable doing that. I recommend clicking through to the failing job and doing 'Restart job' until it passes
<jdstrand> ijohnson_: if that doesn't work after a few times, ping mvo or cachio or someone for assistance (they may have insight on the failing test that I don't)
<ijohnson_> okay, well I don't have permission to restart the jobs, do you have permissions to restart the tests on that PR?
<ijohnson_> jdstrand: ^
<jdstrand> I do
<jdstrand> let me do it
<jdstrand> ok, done. I'll keep an eye on it
<ijohnson_> ack, thanks
 * cachio afk
<ijohnson_> hey jdstrand it looks like those tests passed, do you still want another review before merging?
<jdstrand> ijohnson_: there need to be two approvals
<jdstrand> needs*
<ijohnson_> ah okay wasn't aware of that, I will ping someone else tomorrow morning
<ijohnson_> thanks!
<Pharaoh_Atem> zyga, looks like we have a problem... https://bugzilla.redhat.com/show_bug.cgi?id=1716397
#snappy 2019-06-04
<mborzecki> morning
<zyga> mborzecki: fire fire
<mborzecki> zyga: hi, yeah, looking into it
<zyga> https://bugzilla.redhat.com/show_bug.cgi?id=1716397
<zyga> Thank you!
<mborzecki> zyga: makes me wonder, why snapd attempts to remount /var/lib/snapd/snap
<mborzecki> zyga: maybe it's because it's trying to put some services in separate ns?
<mborzecki> mborzecki: must be because of Private* directives in service files
<mborzecki> zyga: ^^
<zyga> Remount?
<zyga> Aha!
<mborzecki> zyga: PrivateMounts=yes probably
<zyga> Private directives is a systemd feature
<zyga> Is it on by default?
<mborzecki> zyga: then systemd sets up a mount namespace for the service
<mborzecki> zyga: i think now (at least not on arch), but some services, like resolved have it enabled
<zyga> So what is the interplay with snapd?
<mborzecki> snaps are mounted with snappy_snap_t context, but init_t does not have permission to remount this
<zyga> Ahhhh
<zyga> Meh
<zyga> Selinux is too complex!
<zyga> So now we have to fix systemd policy?
<mborzecki> zyga: no, just selinux
<mborzecki> zyga: http://paste.ubuntu.com/p/fZ2hp7Y9hC/ the fix
<mborzecki> i supose that's the best we can do outside of core/contrib policy
<zyga> Why did our test suite not catch that?
<zyga> And how does it cause peopleâs machines to become unresponsive? Is systemd hanging?
<mborzecki> zyga: we don't reboot in the tests mostly, and it affects external services that need to be restarted, eg resolved, which we don't do
<mborzecki> zyga: i guess sddm and such have PrivateHome or similar
<zyga> mborzecki: letâs add a test that reboots
<zyga> It is essential to provide good service
<mborzecki> zyga: running a regression test spread test
<mvo> hey mborzecki and zyga!
<mborzecki> mvo: hey, some fire in fedora-land
<mvo> mborzecki: uhoh, whats up?
<mborzecki> mvo: https://bugzilla.redhat.com/show_bug.cgi?id=1708991
 * mvo looks
<zyga> Hey mvo
<zyga> I didnât manage to do that review for avahi changes
<zyga> Sorry, fighting uphill battle with kids
<zyga> Iâll start around 10
<mvo> zyga: ok
<mborzecki> zyga: about that spurious SELinux failure in tests, it's caused by the upgrade test, which installs snapd from the repo, a version we know to break with symlinks in /etc/
<mvo> mborzecki: I read the bugzilla now, do we have an idea about the fix already?
<mborzecki> mvo: yes, i'm running a regression test under spread now
<mvo> cool
<pstolowski> morning
<mvo> hey pstolowski ! good morning
<mborzecki> pstolowski: hey
<mborzecki> mvo: zyga: https://github.com/snapcore/snapd/pull/6946
<mvo> mborzecki: we will do a 2.39.2 for this one
<mvo> mborzecki: it sound critical enough, yes?
<mborzecki> mvo: yeah, neal asked whether we could do .2
<mborzecki> funny that there is no issue on centos
<mvo> mborzecki: do you need the logs from #6944 ? I would like to restart it
<mborzecki> mvo: no, go ahead
<mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/6946 ?
<zyga> Arriving in 10 min
<pstolowski> mborzecki: ok
<mborzecki> pstolowski: thanks!
<zyga> Almost ready
<zyga> re
<zyga> okay
<zyga> mborzecki: looking
<mvo> mborzecki: I added some comments for 6946
<zyga> mborzecki: reviewed
<mborzecki> zyga: can't push to fedora
<zyga> why not?
<zyga> ENOPERM?
<zyga> if so we should fix that
<zyga> but I can help meantime
<mborzecki> zyga: yeah, no permissions :P
<zyga> trying to log in on https://bugzilla.redhat.com/show_bug.cgi?id=1716736
<zyga> gets bounced via id.fedora*
<zyga> then nothing
<zyga> still not logged in
<zyga> eh
<zyga> browser woes
<mborzecki> zyga: you can mark it as a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1708991
<mborzecki> pstolowski: are you using the nested spread suite?
<pstolowski> mborzecki: i used it for hotplug test, yes
<zyga> mborzecki: sure
<mborzecki> pstolowski: that's good
<zyga> mborzecki: done
<pstolowski> mborzecki: i haven't run it for a while; but i believe it's now run overnight (unless Sergio changed something)
<mborzecki> pstolowski: hm no clue where those are started
<mborzecki> pstolowski: there's no indication in travis.yaml or travis project page, probably sergio knows
<mborzecki> got a quick errand to run, back in 30
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6946 is green
<pstolowski> mborzecki: i don't know how this is all wired up with spread-cron, but i found a run from 6h ago here: https://travis-ci.org/snapcore/spread-cron/builds/541031798, you can see nested stuff is run there
 * zyga moves  somewhere  quiet
<pstolowski> pedronis: can https://github.com/snapcore/snapd/pull/6935 land (has +2 now) or do you want to take a look?
<pedronis> pstolowski: it's fine
<pstolowski> ty
<pstolowski> pedronis: btw, load-state was too fast in my tests to get saved in the state and was not reported, likely due to small size
<mborzecki> re
 * zyga is back home
<zyga> apparently no good place for work today
<zyga> ETOOHOT ETOOLOUD
<ogra> ogra@localhost:~$ sudo hostnamectl set-hostname pi2
<ogra> Could not set property: Failed to set static hostname: Read-only file system
<ogra> ogra@localhost:~$ ls /etc/writable/
<ogra> ogra@localhost:~$ ls -l /etc/hostname
<ogra> lrwxrwxrwx 1 root root 17 Feb 11 14:50 /etc/hostname -> writable/hostname
<ogra> mvo, i thought that was fixed (core18)
<ogra> (just downloaded from cdimage stable)
<mvo> ogra: can you please refresh core18? maybe the image is old?
<ogra> it did just auto-refresh it seems
<ogra> creating writable/hostname works fine btw
<Chipaca> ogra: is there an /etc/writable ?
<ogra> Chipaca, yes, but not the empty files
<ogra> just touching hostname, localtime and timezone in the dir usually makes  it work
<ogra> oh, lovely ... and while i was just apt installing something under the classic snap, snapd decided to reboot in the middle of it
 * Chipaca hands ogra a wand of shutdown -c
<ogra> Chipaca, hard to do if the console is occupied by apt output :P
<Chipaca> ogra: and 'tmux' is a classic snap :-(
<ogra> (i know i can open a second ssh session but you have to be really fast since the shutdown happens so quickly in 18)
 * Chipaca goes for coffee
 * zyga is tired today
<zyga> sorry everyone, next year I'm getting A/C
<zyga> I'll get that coffee
<zyga> but first some paperwoor
<zyga> work
<zyga> mvo: can you commit this suggestion please https://github.com/snapcore/snapd/pull/6945#discussion_r290222845
<mvo> zyga: already done
<zyga> thank you
<Chipaca> grah, there's a bug in a test :-(
 * Chipaca grahs
 * Chipaca restarts the test because it's a racy bug but looks into fixing it anyway
<mborzecki> looks like i've hijacked all build slots on travis :)
<zyga> mborzecki: *used* :)
<zyga> it's good to keep things going
 * zyga iterates locally
<zyga> my mind is melting today
<mborzecki> zyga: well +30 in shade here, summer came early?
<zyga> mborzecki: I'm working from within an oven
<zyga> tried to work from a cafeteria but the insane requirement to keep ultra loud music drove me away
<zyga> I really hate that brand owners force branded stores to play loud music all day long
<zyga> I got a headache and left
<mborzecki> zyga: should have played some vader on your laptop to counter the ambient noise :)
<zyga> the staff hates it
<zyga> but they cannot turn it down
<zyga> they literally cannot I was told
<ogra> mvo, digging a bit deeper regarding the hostname/timezone/localtime stuff, i see the files in /snap/core/current/etc/writable/ and also only have one core installed yet ... seems the content of /etc/writable did not get copied for me
<ogra> ogra@pi2:~$ grep etc/writable /etc/system-image/writable-paths
<ogra> /etc/writable                           auto                    persistent  none        none
<ogra> hmm, shouldnt the second arg ne "transition" ?
<ogra> ok ... here is core16:
<ogra> ogra@stream:~$ grep /etc/writable /etc/system-image/writable-paths
<ogra> /etc/writable                           auto                    synced      none        none
<ogra> why did we remove the "synced" between core 16 and 18 ?
<zyga> ogra: perhaps, I recall some changes there
<zyga> mvo: do you remember?
<zyga> ogra: the problem with writable paths is that it is non-obvious what happens when a file is removed
<ogra> well, "persistent none" is definitely wrong
<zyga> and that it's pretty niche so we don't all have experience with it
<ogra> well, if persistent is set nothing happens if a file is removed from the writable area ... if synced is set the one from the core(18) snap will be copied in place
<ogra> http://manpages.ubuntu.com/manpages/xenial/man5/writable-paths.5.html is pretty clear about the bahaviour
<ogra> *behaviour
<ogra> or do you mean removed from the readonly part (it will not have any effect, we had a userspace removal service for that on the phone to make sure the writable side gets removed as well if needed)
<ogra> in any case the current behaviour is wrong, the dir needs to be copied once on firstboot (whihc either "synced none" or "persistent transition" achieves", with synced you have a permaent connection between the two while "persistent transition" will only copy once on first boot)
<zyga> ogra: I'm deep in another place, sorry I cannot help with this now
<ogra> i didnt expect you to ... but i had the impression that was fixed a while (months ?) ago
 * pstolowski lunch
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/6946 landed
 * zyga debugs stuff
<zyga> gnome, how I hate your interactions
<zyga> I cannot wait for WSL2
<zyga> I will happily run WSL2 and windows terminal
<zyga> sorry gnome, you're full of great tech and you were surely made with love
<zyga> it's me, it's not you
<cachio> mvo, hey
<mborzecki> zyga: how about garden gnomes? :)
<zyga> mborzecki: same level of adoration
<cachio> mvo, is it ok if I do some modifications to the autopkgtests change?
<zyga> cachio: I think so, what do you want to change?
<cachio> zyga, move the test to the new nightly suite
<zyga> cachio: what are you aiming to achieve with that move?
<mborzecki> off to pick up the kids
<cachio> zyga, it is mainly because the find of tests we have in the nightly suite
<cachio> zyga, but we can do it in a following PR
<cachio> zyga, I am running the test now to see how it works within the nested suite
<mvo> cachio: sure, what do you have in mind?
<pstolowski> zyga: i failed to rework retry error handling, but come up with this https://github.com/snapcore/snapd/pull/6949 ; keen to see how travis likes it. local runs with network ns & spread tests on select machines were succesful
<mvo> mborzecki: thanks, cherry-picked
<mvo> ogra: hey, sorry for the delay. re "synced"> we don't have synced anymore as it was a source of confusion and issues, having transition there is fine if its missing of course
<mvo> ogra: let me look at the issue at hand
<ogra> mvo, yeah, we should definitely add transition to get the dir initially filled with files ... interestingly hostnamectl seems to behave differently on x86 (for lool ) and actually just creates the missing file (while it seems to try to modify /etc/hostname directly on my pi install)
<ogra> so there seems to be an additional issue that doesnt show up if the filesystem is set up as expected
<zyga> hmm
<zyga> mborzecki: do you know when you are in debug shell
<zyga> and then you run a command like foo.sh
<zyga> when sh is a simple app that does exec /bin/sh "$@"
<zyga> and then you end up in a loop with /bin/sh: 0: Bad substitution
<zyga> and you cannot interrupt that
<zyga> is that that app running itself?
<zyga> I bump into this once in a while
<zyga> and it is infuriating when it happens
<zyga> (I just lost all state I had in this machine)
<cachio> mvo, as the test is failing at least on ubuntu-16.04 running on nested vm
<cachio> I though on moving it to the nightly suite
<mvo> ogra: I created #131 against core18
<cachio> and there run spread with autopackgtest backend
<mvo> cachio: meh, ok, I ran it only on 16.04 - what is the error?
<cachio> mvo line 65: autopkgtest-buildvm-ubuntu-cloud: command not found
<mvo> cachio: aha, ok - I think I know what to do
 * zyga tries some more debugging
<mvo> cachio: nightly is an interessting idea, we can test on more distro release then too, right? lets talk about it in a bit, need to talk to zyga first about something unrelated
<cachio> mvo, sure
<ogra> mvo, thanks !
<mvo> ogra: thanks for raising it
<zyga> mborzecki: it's curious, just running spread -shell-before and running "sh" kills the system
<zyga> checking
<zyga> mborzecki: it's PS1
<zyga> mborzecki: it's not compatible with sh
<Eighth_Doctor> zyga, mborzecki: so are we going to have a 2.39.2, or should I cherry-pick on top of 2.39.1?
<zyga> Eighth_Doctor: I would recommend cherry picking
<zyga> we just discussed this
<zyga> .2 would be for autopkg test
<zyga> that's not really anything relevant
<Eighth_Doctor> ð¤·ââï¸
<zyga> and I think it's really better to cherry pick in both cases (maybe .2 is not needed at all)
<Eighth_Doctor> I'll work on cherry-picking later today then
<mborzecki> Eighth_Doctor: .1 also has a fix for symlinks in /etc/
<Eighth_Doctor> yeah, I saw that
<zyga> Eighth_Doctor: thank you!
<zyga> I'm suspending my desktop and going to look for shade in the bedroom; this place is at +40C now
<cachio> mvo, hey
<Eighth_Doctor> zyga: you should get air conditioning
<Eighth_Doctor> I would have figured after last year, you would have bought an AC unit and set that up
<cachio> so am also getting out of snpace issues runing autopkgtests on gce
<cachio> mvo, perhaps the best is to remove the test from that PR, and I'll continue wotking on this on a following PR
<cachio> otherise it is going to break the nested suite
<cachio> otherwise
<cachio> mvo, does it makes sense?
<cachio> mvo, I'll need to create new images to support this new test
<ijohnson> hey folks, is it possible to get https://github.com/snapcore/snapd/pull/6805 pulled into a 2.39.x ? or do we need to wait until 2.40 hits stable?
<pstolowski> zyga: #6949 is green; are you able to test it on a suse build infra?
<zyga> pstolowski: sure, let me try
<mvo> cachio: yes, I can do this - fwiw, I got the same error you got - testbed failure due to timeout, I think we need to run "autopkgtest --timeout-factor=3" or something
<mvo> cachio: I will remove the test now and force push and then we can do that in a separate PR
<mvo> ijohnson: hey, let me look
<mvo> ijohnson: that looks ok for 2.39.2
<ijohnson> thanks mvo! do you want me to file a PR against release/2.39 for that branch?
<mvo> ijohnson: let me see if I can cherry pick cleanly, if so no need for a PR
<cachio> mvo, nice, thanks
<mvo> ijohnson: cherry pick worked, so all good, its part of release/2.39 now
<ijohnson> mvo: thank you!
<cachio> mvo, in the nightly suite is not giving that error but at some point the vm is going out of space
<cachio> mvo and breaks
<mvo> ijohnson: thank *you* for the PR :)
<mvo> cachio: oh, woah
<mvo> cachio: the nested VM? or the "parent" VM?
<cachio> I think the nested
<cachio> mvo, https://paste.ubuntu.com/p/G9qhxwcn5W/
<cachio> I mean the parent
<mvo> cachio: thanks and *meh* thats annyoing, I can see why, the nested vm will also need quite a bit of space :/
<mvo> cachio: I removed all but the "integrationtest" commit
<cachio> mvo, I'll updates those images with more space
<mvo> cachio: thanks
<cachio> mvo, nice
<mvo> cachio: I will run adt manually now on all our supported distro releases to unblock this PR
<cachio> nice
<cachio> mvo, thanks
<zyga> pstolowski: building now
<pstolowski> zyga: ty
<zyga> pstolowski: I need to rebase the patch, hold on
<pstolowski> mborzecki: can you take a look at #6900 if you have a moment?
<mborzecki> pstolowski: sure
<zyga> pstolowski: some typos in the patch, check your editor please
<zyga> pstolowski: rebased, not sure which other patches should be present
<zyga> testing now
 * cachio lunch
<pstolowski> zyga: typos?
<zyga> pstolowski: yes, commit message has several
<zyga> pstolowski: the  tests have failed:
<zyga> https://www.irccloud.com/pastebin/GlYDnpJR/
<zyga> pstolowski: also the 1st line is too long for git commit messages
<zyga> pstolowski: anyway, the essence  is different
<zyga> pstolowski: I pushed opensuse/2.39.1-patches
<zyga> this is what  I tested
<zyga> please look at  the patches, I can nuke any easily
<pstolowski> zyga: ah, but this is something else, i haven't seen such failure when running with net ns
<zyga> pstolowski: correct, I think inside obs there are  more things changed
<zyga> specifically the DNS server
<pstolowski> wonderful
<zyga> pstolowski: fun, right?
<zyga> pstolowski: if you want I can show you how to set up for local testing
<zyga> it's not complex actually
<pstolowski> zyga: okay, i need some way of triggering this
<pstolowski> zyga: need to got to vet now, bbiab
<zyga> pstolowski: k, ping me later please
<pstolowski> zyga: back
<zyga> in a call now
<zyga> pstolowski: install tumbleweed in a vm
<zyga> pstolowski: maybe pick ext4 over btrfs
<zyga> pstolowski: that's all you'll need
<pstolowski> k
<pstolowski> zyga: ok, i've it nwo
<pstolowski> *now
<zyga> pstolowski: you want to install whatever provides osc
<zyga> pstolowski: osc checkout system:snappy
<zyga> pstolowski: then osc build
<zyga> it's fairly well documented
<zyga> you will likely need to create a suse account
<zyga> it's hand-holdy all the way so I think it should be smooth
<zyga> once you have that I can show you how to trigger the failure
<pstolowski> k
<zyga> pstolowski: pstolowski: we can HO if you want to do  that interactively
<pstolowski> zyga: i've a checkout now
<zyga> pstolowski: try osc build
<zyga> that should  pass
<zyga> if you comment-out some of the patches you can osc build again and see the failures happen
<pstolowski> zyga: ok, got successfull build as you said, trying without patches now
<zyga> pstolowski: ok
<zyga> pstolowski: you only need to change two lines
<zyga> one that says Patch: ... at the top of the file
<zyga> and another one  slightly lower that says %patch3 ...
<zyga> pstolowski: using a git branch, like the one I sent, is convenient
<zyga> pstolowski: because you can then git format-patch 2.39.1..HEAD and simply copy them over
<zyga> pstolowski: you can also tweak the spec file, so when it runs tests it will run that test only, that's somewhere around %check
<pstolowski> zyga: good hint with git branch, thanks
<pstolowski> zyga: ok, got test failure now as expected. good
<zyga> pstolowski: ok, great!
<zyga> pstolowski: if you want I can  dig around to understand what exactly is going on when osc build runs
<zyga> pstolowski: I didn't look that deep yet
<pstolowski> zyga: looks like a chroot in /var/tmp/build-root/openSUSE_Tumbleweed-x86_64 ?
<zyga> pstolowski: yep, likely
 * zyga jumps back at mount issues
<pstolowski> will continue digging tomorrow
<zyga> sure, thank you pstolowski|afk
<cachio> mvo, should we merge the autopkgtests PR now?
<mvo> cachio: I think so, we need a test too but that can be in a followup, I will do 2.39.2 with those fixes in my morning then
<cachio> mvo, perfect
<Chipaca> EOD here ð
<Pharaoh_Atem> zyga: 2.39.1 updates proposed
<Pharaoh_Atem> F30: https://bodhi.fedoraproject.org/updates/FEDORA-2019-3c4eec8250
<Pharaoh_Atem> F29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-02e160af16
<Pharaoh_Atem> EL7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-91a080fd55
 * cachio afk
<zyga> Pharaoh_Atem: thank you
<Pharaoh_Atem> zyga: I need testing and karma
<Pharaoh_Atem> otherwise this update will not ship anytime soon
#snappy 2019-06-05
<mborzecki> morning
<mvo> good morning! and yay, only 2 pages of open PRs :)
<zyga> Good morning
<zyga> I had a dream about a raspberry pi, booting over usb into uboot sent from a separate computer, then loading kernel and initrd over lan and booting into initrd for testing
<zyga> Is that normal?
<zyga> I will start by booting Fedora and testing the update
<mvo> hey zyga ! good morning
<mborzecki> zyga: mvo: hey
<mvo> hey mborzecki
<mborzecki> zyga: the lan part is doable (now even?), don't know about uboot from usb though
<mvo> xnox: speaking of empty etc, may I interesst you in LP 1736744
<mvo> xnox: one tiny step forward (one less file there)
<pstolowski> morning
<mborzecki> pstolowski: hey
<zyga> mborzecki: yes, totally
<mborzecki> zyga: heh, the dnf command in snapd page in bodhi does not install anything here, i guess mirrors aren't synced yet
<zyga> Aha, Iâll check soon
<zyga> Janek goes for a school trip
<zyga> I will start at 10, need to go to school with him today
<mborzecki> hm i should really fix the upgrade test on fedora, but since 39.1 is already in testing i could wait a little bit
<zyga> back in the office
<zyga> it's a **hot** day
<ackk> mvo, hi, in the currently implemented work for  https://forum.snapcraft.io/t/phase-1-of-opt-in-per-snap-users-groups-aka-the-daemon-user/10624, do you know if the daemon user also has a group it can be used in the snap?
<mvo> ackk: iirc it will have a group as well ("daemon") but take it with a gain of salt, jdstrand is leading the implementation, he is the authority here :)
<ackk> mvo, ok, thanks, will give it a try and see if it works :)
<ackk> mvo, if you have a snap that's been installed from the store with --devmode and it gets updated (also from the store), how do you drop the devmode flag?
<Chipaca> ackk: you remove it and reinstall it?
<Chipaca> ackk: we have no --un-devmode
<Chipaca> for any of those flags
<ackk> Chipaca, ok, I thought so but wanted to confirm
<Chipaca> ackk: if you have data, snapshot and restore will work
<Chipaca> (automatic snapshot if your snapd is new enough)
<ackk> Chipaca, currently the maas snap does some 'chown nobody:nogroup' in the configure hook, we'd have to transition that to the daemon user, but I guess it should be fine because if you're doing a clean install you won't need --devmode, and if you're upgrading from one that had devmode, you can still change the ownership
<Chipaca> ackk: tell me more about this "upgrading devmode"
<Chipaca> because AFAIK devmode still does not auto-refresh
<ackk> Chipaca, wdym?
<ackk> Chipaca, it doesn't?
<Chipaca> (yes we have a TODO item to make that happen but AFAIK it does not)
<ackk> Chipaca, note that the snap is not marked as devmode
<ackk> (if that's what you mean)
<Chipaca> ackk: snap install --devmode foo  results in foo not getting refreshed
<Chipaca> ackk: irrespective of whether the snap itself needs devmode
<ackk> Chipaca, can you manually refresh via snap refresh <snap> ?
<ackk> or do you have to snap install /
<Chipaca> hmmmmmmm
<Chipaca> we've dithered a bit on this so i'd have to check
<Chipaca> AKshully, maybe a manual 'snap refresh thesnap' (without --devmode) drops the devmode flag
<Chipaca> maybe
<ackk> Chipaca, to clarify, the maas snap is published to the store and it's grade:stable confinement:strict, but it only works if you snap install --devmode maas
<Chipaca> ackk: it looks like 'snap refresh' without --devmode, *as long as there actually is an update*, drops the devmode flag
<Chipaca> ackk: um
<Chipaca> ackk: to be clear, 'snap refresh thesnap', not a bare 'snap refresh'
<Chipaca> I'll check if it's actually dropping devmode from the profiles, but if it's not then that's a bug :)
<ackk> Chipaca, I see you can also snap refresh --devmode
<Chipaca> ackk: yes, and that will preserve devmode for the refresh
<Chipaca> so that's how you drop the devmode flag -- there is no --un-devmode, but if you can make it do an actual refresh you can do it this way
<Chipaca> (it doesn't work with a no-op refresh)
<ackk> Chipaca, that makes sense, thanks for clarifying
<Chipaca> maybe it should
<Chipaca> but that's one for pedronis :)
<ackk> Chipaca, do epochs work if you're refreshing with/from devmode ?
<Chipaca> ackk: always
<Chipaca> ackk: epochs are orthogonal to the sandbox
<Chipaca> ackk: devmode is about the sandbox
<ackk> Chipaca, ok, so I guess since we need to move from nobody to the deamon user, we'll have to use an epoch and upgrade via --devmode to be able to make the chmod
<ackk> err, chown
<Chipaca> that sounds awful
<Chipaca> :-/
<ackk> is there a better way?
<Chipaca> ackk: what is it you need to do?
<ackk> (it does sound awful)
<Chipaca> ackk: currentl the snap only works with --devmode?
<ackk> Chipaca, so i have $SNAP_DATA/foo which is nobody:nogroup (and the snap is --devmode)
<ackk> Chipaca, correct
<ackk> Chipaca, I need to chown that to daemon:daemon so we can use system-users: [daemon] and drop devmode
<Chipaca> ackk: can't you switch the devmode snap to use the daemon user before using system-users?
<ackk> Chipaca, how?
<Chipaca> ackk: how is it today using nobody:nogroup?
<ackk> Chipaca, ah yeah that's what I'm saying
<Chipaca> ah
<ackk> Chipaca, swithc to daeamon:daemon and then drop devmode
<ackk> Chipaca, but that's an intermediate requires step
<ackk> and you have to snap refresh --devmode to it
<Chipaca> ackk: yeah
<ackk> and then snap refresh without
<ackk> then you're free
<Chipaca> ackk: hmm
<ackk> Chipaca, maybe it'd be easier to snap remove, restore the snapshot, reinstall and chown manually :)
<Chipaca> ackk: you could have the non-devmode snap copy the data instead of chowning it
<ackk> Chipaca, but that will leave files that the snap can't do anything with?
<Chipaca> ackk: i mean: have an ad-hoc miration daemon
<ackk> unless you can still chown in a confined snap from a different user to yours
<Chipaca> ackk: that runs as root
<Chipaca> ackk: that copies the data over, removes the old data, and kicks the new 'daemon' daemon
<ackk> Chipaca, will root in the snap be able to chown? I thought it wouldn't
<Chipaca> ackk: no, not chown, but copy
<ackk> Chipaca, can it remove the old data?
<Chipaca> should be able to yes
<Chipaca> runs as root an' all
<ackk> mhm yeah that might be easier yes
<Chipaca> chown/chuid is forbidden but not r/w/chmod
<Chipaca> so you shold be able to get it working
<Chipaca> hmm hmm
<Chipaca> ackk: is the old data world-readable?
<ackk> Chipaca, it should be yes. I can give a try at copying
<ackk> Chipaca, thanks
<Chipaca> ackk: if the old data is world-readable, the 'daemon' daemon could do the copy
<Chipaca> ackk: how much data is it?
<ackk> Chipaca, mhm actually that's the problem, it's mostly the squid and postgres dirs
<ackk> so, potentially a lot
<Chipaca> yeah that might make it unworkable
<Chipaca> ackk: TBH sounds like telling somebody to 'snap refresh --devmode maas && snap refresh maas' is about the same as 'chown -R daemon:daemon /the/data && snap refresh maas' and a lot less work for you
<Chipaca> the latter is less work i mean
<ackk> Chipaca, yeah, it's ugly either way, although the first one is "safer" as we can make sure the right commands are run
 * Chipaca nods
<Chipaca> ackk: you can at least use epochs to raiload people through that
<ackk> Chipaca, right
<Chipaca> ackk: give the new devmode-needing snap an epoch of 1*, and the new strict snap an epoch of 1
<Chipaca> ackk: then people installing from scratch will get the epoch:1 one
<ackk> Chipaca, right, that was my thinking
<Chipaca> ackk: and people that are on the old no-epoch (ie epoch 0) snap can't go to the epoch:1 one
<Chipaca> they need to go through the 1* one
<Chipaca> tadaa, or something
<Chipaca> :)
<Chipaca> ackk: and, and, you can update the epoch:1* snap and not stomp on the epoch:1 snap in the same channel
<ackk> Chipaca, heh. yeah we already need epochs anyway as the new snap has to upgrade the db (the current stable one has postgres9 , the new pg10)
<Chipaca> (i.e. even if the last snap you pushed was the epoch:1* snap, people will still get the epoch:1 one
<Chipaca> )
<Chipaca> people doing new installs*
<Chipaca> mvo: pstolowski: do you know what uses the snap-install-hook-broken snap? (from tests/lib/snaps/)
<Chipaca> mvo: pstolowski: because it fails to install for a completely different reason than what I suspect it means to fail to install
<ackk> Chipaca, can you explain the last sentence? if you have a 1 and a 1* in the same channel, whhy would you get the 1 ?
<ackk> (in a new install)
<Chipaca> ackk: 1* is {read:[0,1] write:[1]}
<Chipaca> ackk: 1 is {read:[1], write:[1]}
<ackk> Chipaca, right, but why do you care on a new install?
<pedronis> zyga: hi, did you see my comment in #6714 btw?
<mvo> Chipaca: idk, I suspect its a leftover?
<zyga> pedronis: hi, I haven't yet, looking
<Chipaca> ackk: so the upgrade epoch path thing is 0 â 1* â 1
<zyga> I will try to return to that branch soon, thank you
<Chipaca> ackk: when you install or refresh you always get the rightmost snap in that â series
<pstolowski> Chipaca: hmmm apparently it's not used. wonder if it was replace by snap-hooks-bad-install
<pstolowski> *replaced
<Chipaca> ackk: the rightmost snap that you can use i mean
<Chipaca> ackk: on a new install, that's always the rightmost one
<ackk> Chipaca, right, so if you make a clean install you get "1"
<ackk> Chipaca, ok, I thought you said you'd get 1*
<Chipaca> ackk: exactly
<Chipaca> ackk: independently of what the last snap you pushed to the channel was
<Chipaca> ackk: that's important because otherwise a new user might get a 1* which is just a fix for a bug in a migration snap when the latest and greatest is 4 or something
<ackk> Chipaca, aah I see you mean if you push 30: 1 and then 31: 1*, a new install still gets 30
<Chipaca> ackk: yep
<ackk> Chipaca, I see yeah that wworks
<Chipaca> pedronis: wdyt of in-cohort?
<pedronis> Chipaca: sounds reasonable
<Chipaca> k
 * Chipaca gets on it
<pedronis> mborzecki: I did another pass on some of the gadget update PRs
<mborzecki> pedronis: thanks
<mborzecki> pedronis: i've udpated https://github.com/snapcore/snapd/pull/6836 with feedback from yesterday
<pedronis> mborzecki: ok, I'll look again later, need to do some forum answering
<mborzecki> pedronis: sure, thank you for taking time to do the reviews, there's a quite bunch of those :)
 * zyga has a small breakthrough in ideas about mount propagation
<zyga> let's quickly code that
 * Chipaca puts https://mobile.twitter.com/LightfootJaime/status/1135970988217249793 gently down and walks away whistling
<zyga> Chipaca: wow, that's cool
<zyga> I love the front panel
<Chipaca> zyga: I was going to point you at it directly but didn't want to interrupt :)
<mborzecki_> forum has spilled to reddit https://www.reddit.com/r/kde/comments/bwxij9/since_when_did_qtkde_snaps_become_better/
<zyga> oh?
<mvo> cmatsuoka: hey, do we need to update the spike-tools repo ? I get a make error in e2fsprogrs right now but iirc you mentioned those are no longer needed ?
<mvo> Chipaca: silly question - how long is the cohort key?
<pedronis> mvo: ~148
<mvo> ta
<mvo> pedronis: I guess there is a good reason for this, would love to hear a td;lr summary (maybe in the standup)
<zyga> brb, coffee
<cmatsuoka> mvo: yes, it should be in the writable-ramdisk branch as well
<zyga> brb, rebooting
<cmatsuoka> mvo: my plan is to add the recovery chooser today for install and recovery modes
<mvo> cmatsuoka: what do I need to add/change to prepare.sh to get writable-ramdisk? is that from your core-build repo?
<cmatsuoka> mvo: let me run it here in a clean dir, it was supposed to work
<mvo> cmatsuoka: ok, maybe its my 19.04, I can try on a 18.04
<cmatsuoka> mvo: I don't know how sensitive it is to environment variations, but it's possible
<cmatsuoka> my build box here is 18.04
<cmatsuoka> mvo: hmm, in fact mke2fs shouldn't be there since it's not needed anymore
<jdstrand> ackk (cc mvo): there will be a group too
<ackk> jdstrand, nice, thanks!
<mvo> cmatsuoka: it builds on 18.04
<ackk> jdstrand, unrelated, not sure if it was mentioned at the sprint, but would it make sense to have an interface to allow reading /run/uuidd/request?
<mvo> cmatsuoka: but if we don't need e2fs anyway, I can remove it
<cmatsuoka> mvo: I just noticed that build-image.sh complains about go/snapd, you'll have to build it as well
<cmatsuoka> I'm pushing an updated prepare
<mvo> cmatsuoka: thank you! I check it after lunch
<zyga> pstolowski: I will try to review https://github.com/snapcore/snapd/pull/6923 today
<jdstrand> ackk: we did talk about it. it is in openvswitch-support, believe it or not, but @{PROC}/sys/kernel/random/uuid is already in the default template which is going to be more robust since uuidd may not (necessarily) be everywhere
<pstolowski> zyga ty
<lss8> so, is there now a way to disable automatic snap update checks?
<lss8> I'd like to not auto update my snaps as this is a potential security issue
<Chipaca> lss8: _updating_ your snaps is a security issue?
<Chipaca> lss8: please explain?
<Chipaca> lss8: if you have specific concerns, and are planning to test for these concerns in a controlled environment before releasing things to a large network, there are tools for this
<Chipaca> lss8: but as i say, please explain
<ackk> jdstrand, yeah I'm not sure what's actually using it in the maas snap, I've seen denials, but we don't use it explicitly
<jdstrand> ackk: I think blake_r or roaksoax thought it was something in a python lib that could be switched out or something
<mborzecki> pedronis: update gadget task handler also checks whether a snap is installed, we can do it in both places though
<pedronis> mborzecki: yes, I think best it to do it both places
<mborzecki> pedronis: ack
<ackk> jdstrand, yeah not sure, afaik we always use the python uuid module, which does stuff on its own
<kenvandine> cwayne: i haven't gotten a testflinger email lately
<zyga> kenvandine: more fixes for mount profiles coming soon
<kenvandine> zyga: great
<Greyer> hi ppl, at monday I have installed recent snapd-2.39-1.el7.x86_64 on CentOS 7 (OS is with SELinux in Enforced mode) and after that my LXD was unavailable, I've looked into audit and saw lot of permission errors. Switching into Permissive regain me access to lxd daemon. Is this a known issue or I should create ticket in bugzilla for this?
<mborzecki> pedronis: fakestore new-snap-revision --snap-rev-json right?
<zyga> Greyer: hello
<zyga> mborzecki: ^
<mborzecki> Greyer: hey
<Greyer> hey :)
<zyga> Greyer: based on what you just described it doesn't seem like the issue that we fixed yesterday but I will defer to mborzecki's opinion
<mborzecki> Greyer: what's the problem?
<Greyer> mborzecki: CentOS 7 in Selinux Enforced mode on newest snapd (snapd-2.39-1.el7.x86_64) gets LXD broken, lxd daemon pid is not available
<zyga> Greyer: what kind of denials are you seeing?
<mborzecki> Greyer: interesting, we have an integration test targeting this, let me check it locally
<zyga> Greyer: is it broken straight away of after reboot?
<zyga> perhaps it's the same bug
<Greyer> zyga: straight away
<Greyer> I've made yum update and lxc list stopped working saying that daemon is not available
<Greyer> let me check
<mborzecki> Greyer: installing now
<pedronis> mborzecki: yes
<Greyer> btw, I've jumped from snapd-2.38-1.el7.x86_64 to snapd-2.39-1.el7.x86_64
<Greyer> but I don't think there was any other version between in epel repository
<Greyer> what is odd, my lxd containers were still running without problems, just I couldn't use the commands
<mborzecki> Greyer: w8, so you had lxd installed, and updated to 2.39, that's when it broke, right?
<Greyer> yes, lxd was installed, containers were running
<Greyer> I have updated snapd from 2.38 to 2.39 (epel7 repository)
<Greyer> and all lxc commands stopped working saying that lxd daemon is not working
<Greyer> but containers were workin
<Greyer> g
<Greyer> I have downgraded to 2.38 everything worked again
<Greyer> so reuptaded to 2.39
<Greyer> and again no permissions, then setenforce 0, lxc commands started working
<Greyer> Jun 03 08:32:27 sheldon.szary.sh lxd.daemon[2215]: cmd_run.go:375: restoring default SELinux context of /root/snap
<Greyer> Jun 03 08:32:27 sheldon.szary.sh lxd.daemon[2215]: execv failed: Permission denied
<mborzecki> Greyer: can you upload `ausearch -m AVC -ts 08:32` somewhere?
<Greyer> mborzecki: yes, sec
<Greyer> mborzecki: I see only logs from today, audit.log was rotated, so let me change
<Greyer> mborzecki: http://tmp.szary.sh/audit.log-20190603-0830-0840
<Greyer> here
<mborzecki> Greyer: looking
<mborzecki> Greyer: what does `mount |grep snap` show?
<mborzecki> Greyer: for the record, when updating to 2.39 you need to reboot for the mount points to be recreated with proper selinux contexts
<mborzecki> Greyer: it's a one off thing, we previously did not have any selinux contexts for mounted snaps, but now we have
<mborzecki> Greyer: restarting mounts will likely not help, unless you can make sure that the mount point is not used in any mount ns, kernel denies remounting a block device with a different security context
<Greyer> [root@sheldon.szary.sh] 15:42:06 ~ # mount | grep snap | column -t
<Greyer> tmpfs                                on  /run/snapd/ns                  type  tmpfs     (rw,nosuid,nodev,seclabel,mode=755)
<Greyer> /var/lib/snapd/snaps/lxd_10601.snap  on  /var/lib/snapd/snap/lxd/10601  type  squashfs  (ro,nodev,relatime,seclabel)
<Greyer> /var/lib/snapd/snaps/lxd_10756.snap  on  /var/lib/snapd/snap/lxd/10756  type  squashfs  (ro,nodev,relatime,seclabel)
<Greyer> /var/lib/snapd/snaps/core_6673.snap  on  /var/lib/snapd/snap/core/6673  type  squashfs  (ro,nodev,relatime,context=system_u:object_r:snappy_snap_t:s0)
<Greyer> /var/lib/snapd/snaps/core_6818.snap  on  /var/lib/snapd/snap/core/6818  type  squashfs  (ro,nodev,relatime,context=system_u:object_r:snappy_snap_t:s0)
<Greyer> /var/lib/snapd/snaps/core_6964.snap  on  /var/lib/snapd/snap/core/6964  type  squashfs  (ro,nodev,relatime,context=system_u:object_r:snappy_snap_t:s0)
<Greyer> /var/lib/snapd/snaps/lxd_10526.snap  on  /var/lib/snapd/snap/lxd/10526  type  squashfs  (ro,nodev,relatime,context=system_u:object_r:snappy_snap_
<Greyer> /var/lib/snapd/snaps/lxd_10526.snap  on  /var/lib/snapd/snap/lxd/10526  type  squashfs  (ro,nodev,relatime,context=system_u:object_r:snappy_snap_t:s0)
<Greyer> proc                                 on  /run/snapd/ns/lxd.mnt          type  proc      (rw,nosuid,nodev,noexec,relatime)
<mborzecki> Greyer: looks good, you're on 2.39 now, right?
<Greyer> mborzecki: so You advise to reboot?
<Greyer> yes, I'm on 2.39 now with Permissive Selinux mode
<Greyer> I can switch to Enforced and reboot to see if it'll work
<mborzecki> Greyer: just to make sure, can you systemctl cat var-lib-snapd-snap-lxd-10756.mount ? there should be snappy_snap_t in mount options
<mborzecki> Greyer: if it's there, then you can reboot
<zyga> Greyer: any luck?
<pedronis> mvo: pstolowski: seems the store has added the 'snapd' type already
<pstolowski> pedronis: great!
<ijohnson> davdunc: hi! have you considered making aws-cli a strict snap with the personal-files interface to access $HOME/.aws instead of classic?
<Greyer> ah, mborzecki is out, I got dragged to solve issue
<Greyer> there is snappy_snap_t in mount options
<Greyer> I will reboot in a few minutes, first need to take kid from preschool
<Eighth_Doctor> zyga: could you please test and give karma for F29 and EL7 snapd builds?
<Eighth_Doctor> they need +2 in order to make it in the distro, and F29 has 0, while EL7 has +1
<zyga> Eighth_Doctor: sure, let me boot fedora
<zyga> I noticed the ping in the morning but mborzecki said the update was not ready somehow yet
<davdunc> ijohnson: I have.
<Eighth_Doctor> it wasn't at his mirrors
<Eighth_Doctor> but it has been pushed to the mirror network
<davdunc> ijohnson: it's on my roadmap, just not completed.
<pedronis> mvo: pstolowski: snapcraft doesn't though, we need to ask for that
<zyga> re-running regressed test
<zyga> I need to think some more but I think this will be good
<pstolowski> ok
<zyga> more work required :/
<zyga> the idea is good but the algo is simplistic
<zyga> need to think
<pedronis> mvo: I proposed #6957
<mvo> pedronis: thank you!
<ogra> mvo, do we have any plans for a classic snap on UC18 ? (do we even ship the tarball with the removed files at all in 18 ?)
<ackk> does each snap have a namespaced view of /dev/shm?
<ogra> yes, but not under that node name IIRC
<ogra> (there is a snap specific prefix)
<mvo> ogra: have you tried "snap install classic --channel=18/edge" ?
<ogra> mvo, ah, no, does it exist already ?
<ogra> abeato, ^^^
<mvo> ogra: yes, I'm not sure how good and well tested it is
<mvo> ogra: but we did some work on this a good while ago
<mvo> ogra: its probably super out-of-date :(
<ogra> awesome, i wasnt aware of the status
<ackk> ogra, so I see https://paste.ubuntu.com/ on my machine, where those squid entries are from a squid in the snap. does that mean you can't run more than one?
<mvo> ogra: I can look into this soon(ish)
<ogra> mvo, well, alfonso asked for it, i use mostly lxd nowadays (but then i also rarely need gdb against the os itself)
<ogra> (which classic makes easy)
<ijohnson> davdunc: okay, thanks. I made a version of the snap using the personal-files interface a while ago but didn't push up to the store I could share with you if you're interested
<abeato> ogra, mvo oh very nice, so there is something, that's a good start
<mvo> abeato: please keep me posted, its been a while since I looked at this
<ogra> abeato, yeah ... happy to help with fixes if there are anyy needed
<abeato> sure
<ackk> ogra, also if I ls /dev/shm from another confined snap, I do see those files
<ogra> ackk, well, thats a jdstrand topic then :)
<ogra> ackk, FWIW https://forum.snapcraft.io/t/shared-memory-in-dev-shm-rewriting/2023
<ackk> ogra, thanks
 * cachio lunch
<davdunc> ijohnson: that would be much appreciated. https://github.com/davdunc/aws-cli-snap
<davdunc> I love it when there's less work for me to do to get to the same goal.
<davdunc> and I appreciate all the help I have gotten so far.
<ackk> ogra, thanks, the thing is I'm trying to fix the case where preexisting shm files exist
<Saviq> jdstrand: hey, we've been getting more "outdated packages" emails recently and were wondering if we could somehow automate the rebuilds, is the data available somewhere other than in the email? could we get it ourselves in CI maybe?
<jdstrand> Saviq: you might be interested in https://blog.strandboge.com/2019/02/01/monitoring-your-snaps-for-security-updates/
<Saviq> jdstrand: aha! pity that would require us to download the snaps from the store to run :/
<jdstrand> Saviq: ideally the store would provide something, but it doesn't and this is all separate atm
<Chipaca> EOD from me ð
<ijohnson> davdunc: I opened https://github.com/davdunc/aws-cli-snap/pull/3 to use the personal-files interface
<davdunc> thanks.
#snappy 2019-06-06
<mborzecki> morning
<mborzecki> brb, new kernel
<mborzecki> arch packages updated
<zyga> Hi
<zyga> Nice :-)
<zyga> Biking home, 15 min
<mborzecki> zyga: hey
<jamesh> zyga: thanks for the review comments on the user session agent branch yesterday.  It looks like this will need to be a separate process to userd though :-(
<jamesh> not a huge deal, but means we don't have everything sitting under one roof.
<zyga> re
<zyga> jamesh: hey, because of the second socket?
<zyga> jamesh: I thought that system can model that
<zyga> jamesh: I'm catching up with the comments on the PR
<zyga> jamesh: ah, is it because of xenial's systemd user oddity?
<zyga> jamesh: hmm, that's unfortunate
<zyga> hmm hmm hmm
<zyga> jamesh: thank you for iterating on the branch
<zyga> jamesh: it would be good to try to dig why systemd behaves this way on 16.04 and if that is something we can remedy, either on snapd side or by changing the distribution package a little
<zyga> mborzecki: yesterday I implemented prediction of event propagation for snap-update-ns
<zyga> mborzecki: I need to tweak it some more and add more tests but it is promising
<mborzecki> zyga: nice, let me know when you ahve something to review
<zyga> mborzecki: thank you, it doesn't pass all tests yet so I need to address that first
<mborzecki> mhm
<zyga> mborzecki: maybe it is a dead end but it is seductive that it doesn't require major changes in s-u-n
<mborzecki> zyga: see, at least you did something useful, i instead was at a meetup about migration from c++11 to c++14, not sure if that was the presenter's goal, but i left with the conclusion that you should not let clerks and lawyers design a language
<zyga> hahaha
<zyga> what's the issue with C++ 11 -> C++14
<zyga> I recently used a C11 feature and I loved it (not C++)
<zyga> standard atomics
<mborzecki> zyga: s/is/are/
<mborzecki> zyga: i'm still waiting for a meetup about some large codebase introducing c++17 that should be even more questionable fun
<jamesh> zyga: it would probably be possible to update the dbus upstart job to do a "systemctl --user set-environment" call, but I don't know how likely it would be for that to be accepted
<pstolowski> morning
<jamesh> zyga: also, I suspect we'd have problems due to two ways for "snap userd" to be started: directly by dbus-daemon if a D-Bus call comes in, or managed by systemd for socket activation
<zyga> jamesh: I think it's worth checking to ensue consistency of the snap platform
<zyga> mmm
<zyga> jamesh: tricky business, thank you for staying on top of that
<zyga> good morning pstolowski
<mborzecki> pstolowski: heyah
<jamesh> zyga: and I suspect the the dbus-daemon invoked userd won't be able to take over the socket systemd created
<jamesh> zyga: in contrast, having two processes should work the same everywhere.
<zyga> jamesh: true though I wonder if we should design this so that a OS version on the way out dictates how it behaves everywhere in the future
<jamesh> zyga: is there much benefit to multiplexing it all into a single process though?
<zyga> jamesh: that I don't know, my whole point is we should be thoughtful about the design
<zyga> there may be good reasons to do either approaches
<jamesh> zyga: the systemd env on xenial is pretty bare.  So in addition to not seeing the session bus, user units won't see the display
<zyga> jamesh: please capture that in the thread, I think it is relevant for reviewers
<zyga> brb
<zyga> re
<pedronis> mborzecki: hi, I looked again at #6680
<mborzecki> pedronis: hi, thanks for the the comments
<Chipaca> mup_: you ok there?
<Chipaca> niemeyer: can you tickle mup? it's feeling down
<Paddy_NI> If I wanted others to test an app that I have snapped what would be the best practise for sharing the "snap" package?
<jamesh> Paddy_NI: do you care who in particular tests it?
<Paddy_NI> Not at all
<Paddy_NI> :-)
<jamesh> if you plan to eventually release it on the store, just register its name and publish the snap to the beta channel
<jamesh> it won't show up in search results, and you can just tell people to run "snap install --beta myapp"
<jamesh> when it's ready for general use, publish to stable
<Paddy_NI> Okay, well the app is under MIT license and it's not mine.  I have reached out to the developer via email and he has not responded.  I just feel uneasy about publishing someone else's app.
<Paddy_NI> I am also not sure just how "secure" or "safe" this app is, I have been using it for a very long time and think it's great but my own personal experience is not of much value when it comes to the safety of others
<jamesh> you've to two options then: (1) publish it with a different name (e.g. suffix it with your own name), or (2) register it with the real name and get the name transferred later if the upstream wants to take over.
<Paddy_NI> Okay, I might just add my name that seems like less hassle :-)
<Paddy_NI> Thank you jamesh
<Paddy_NI> Would I add my name as a suffix to the snapcraft.yaml too?
<jamesh> yes.  The "name" field in the snapcraft.yaml should match what you're publishing it as.
<Chipaca> jamesh: beta does appear in search results
<Paddy_NI> Okay good to know :-)
<Chipaca> jamesh: from 'snap find' that is
<jamesh> Chipaca: oh?  I thought it was only stable
<Chipaca> won't appear in gnome software
<Chipaca> but will appear on the terminal
<Chipaca> jamesh: search is now broad by default
<Chipaca> jamesh: (old behaviour is --narrow)
<Chipaca> Paddy_NI: it's probably best to register the final name
<Chipaca> Paddy_NI: otherwise, people will get stranded
<jamesh> Chipaca: thank you for the review comments yesterday.  Converting to the new http.Server Shutdown() method turned out to be pretty easy
<Chipaca> Paddy_NI: that is, say you register fooapp-paddy
<Chipaca> Paddy_NI: people install it and love it
<Chipaca> Paddy_NI: fooapp notices and starts doing their own, official, snap
<Chipaca> Paddy_NI: so you stop maintaining fooapp-paddy
<Chipaca> Paddy_NI: the users of which are now abandoned
<Paddy_NI> That does not sound ideal
<Chipaca> Paddy_NI: instead, if you grab fooapp, when they notice and want to pick it up it's a forum post and a couple of emails to get it transferred
<Paddy_NI> Chipaca, Okay I'll do that instead :-)
<Chipaca> Paddy_NI: it is a little bit more work for the handoff, but it doesn't suck for users as much when things go well :)
<Chipaca> go well == upstream picks it up
<Paddy_NI> That makes lots of sense
<Chipaca> but we've tried to make it easy (as popey and/or Wimpress can attest)
<Chipaca> jamesh: i'm glad that refactor is easy as i've been dreading it for daemon itself :0
<Chipaca> meant to write :) but :0 is also appropriate
<Paddy_NI> This app can be used in conjunction with other applications using "--vlc" or "--mpv" or whatever really, is there a "plug" for this functionality as I am pretty sure it does not work at the moment in my snap?
<jamesh> Chipaca: https://github.com/jhenstridge/snapd/blob/user-session-agent/userd/session_agent.go#L121 <- it's just a few lines longer, plus ignoring http.ErrServerClosed in the Serve goroutine
<pedronis> Chipaca: there should be an explicit way to ask not to appear in searches though
<Chipaca> pedronis: yes but AFAIK that's not implemented yet?
<Chipaca> pedronis: at some point there was talk of not showing things that were only in edge, but I don't think that got done either
<Chipaca> e.g. 'snap find wine' finds 'paladins' which is edge-only
<pedronis> no now find gets everything
<pedronis> but I thought we added a flag to hide from search
<Paddy_NI> I wonder if all those plugs are necessary or if there is some overlapping, here is the contents of my yaml https://paste.ubuntu.com/p/8ngT32WpFQ/
<Chipaca> Paddy_NI: no plugs for vlc nor mpv, and typically those things would get bundled in a snap (unless it's a classic-mode snap which has its own drawbacks)
<zyga> afk for a moment
<Paddy_NI> Ah I see, so I would need to choose for the user.  It would be a bit mad to bundle in VLC, MPV etc
<pedronis> Chipaca: it's there, got to https://snapcraft.io/YOUR-SNAP/settings
<Chipaca> pedronis: ooh nice
<pedronis> remember that nowadays most publisher UI is in the store
<Paddy_NI> Perhaps then the snap would have the bundled player suffixed to the name
<Paddy_NI> "peerflix-mpv"
<Chipaca> Paddy_NI: there's an "unlisted" option in the 'settings' tab of your snap on the web
<Chipaca> Paddy_NI: as pedronis pointed out
<Chipaca> pedronis: I didn't know that was implemented, that's neat
<Paddy_NI> Chipaca, Alan Pope mentioned that in one of the snapcraft.io videos on youtube
<Chipaca> psh, what does he know
<Chipaca> :-Ã¾
<Paddy_NI> I just wasn't sure about etiquette
<Paddy_NI> :-)
<Chipaca> pedronis: we should make all the test-snapd-* snaps unlisted (unless we use them for 'snap find' integration tests)
<Chipaca> Paddy_NI: wrt plugs etc that sounds more like a forum topic so you can get the right people's time to look
<pedronis> Chipaca: maybe
<Chipaca> Paddy_NI: some of those are gnarly interfaces
<Paddy_NI> Chipaca, I was thinking that, I am very hesitant about sharing this with people
 * Chipaca is people too!
<Paddy_NI> I also noticed an "issue" on the github page which has went unaddressed
<Paddy_NI> I'll stick it on the snap store unlisted and see who wants to try it
 * popey_ looks at Chipaca -_-
<jamesh> Paddy_NI: I wouldn't expect a bittorrent client to need firewall-control, network-control, or fwupd
<jamesh> at a minimum
<jamesh> try removing them and see if your snap still functions
<Chipaca> jamesh: that's probably for poking holes to get incoming connections
<Paddy_NI> jamesh, It streams the video over your lan you see
<Chipaca> but i dunno
<Paddy_NI> Unless that still does not matter
 * Chipaca ignores popey_ and hopes for the best
<Paddy_NI> So for instance I would do 'peerflix "magnet_link_here"' and I can stream the video or whatever using the ip address of the computer being used on port 8888
<Paddy_NI> Very handy
<jamesh> Paddy_NI: fwupd has nothing to do with firewalling
<Paddy_NI> Okay I'll remove it and continue testing
<jamesh> it is a tool for updating firmware
<jamesh> in general you should ask for the minimal set of permissions the app needs, rather than just adding them just in case
<Paddy_NI> If I don't use the "home" plug then I cannot do 'peerflix path/to/torrent.torrent'
<jamesh> that one is fine
<Paddy_NI> jamesh, I started with none
<Paddy_NI> The output from snapcraft security log told me those
<jamesh> Paddy_NI: if the app runs unconfined as a regular user, it probably doesn't need the *-control plugs
<Paddy_NI> Or rather those snappy-debug.security scanlog
<Paddy_NI> cool
<Paddy_NI> Okay I have lost count now of how many times I have watched the opening sequence to "Big Buck Bunny"
<Paddy_NI> The app works minus the aforementioned plugs. Thanks guys :-)
<Paddy_NI> Bundling in mpv would probably be wise
<Paddy_NI> It's not how I would use it but that's irrelevant I suppose.
<Chipaca> Paddy_NI: there was somebody else looking into bundling mpv just yesterday
<Chipaca> Paddy_NI: check the channel logs :)
<Paddy_NI> Oh excellent :-)
<Paddy_NI> Chipaca, I've just checked the logs from 4th, 5th and 6th of June. No mention of mpv.
<Paddy_NI> Maybe I'm just stupid
<Chipaca> Paddy_NI: i started searching myself as well and can't find it either
<Chipaca> maybe i imagined it Â¯\_(ã)_/Â¯
<Paddy_NI> Chipaca, lol
<Chipaca> wonder how
<Paddy_NI> I'm going to google a bit
<Chipaca> Paddy_NI: https://forum.snapcraft.io/t/classic-confinement-request-syncplay/11189
<Chipaca> Paddy_NI: not on irc :)
<Paddy_NI> Ah great, cheers Chipaca
<Paddy_NI> I suppose there is tons of work going on with regard interfaces "plugs"?  It would be nice if there was a generic media player "plug" although that's most likely easier said than done.
<Paddy_NI> If someone snaps a web browser and the user installs and uses this browser then clicks on say a "mailto" link is that able to summon the external mail client?
<Chipaca> Paddy_NI: yes
<Chipaca> Paddy_NI: through a magic proxying of xdg-open
 * Chipaca â runch
<Paddy_NI> Chipaca, I suppose this works the same for magnet links etc?
<Chipaca> Paddy_NI: i honestly don't know
<Chipaca> when we wrote the first iteration, no
<Chipaca> but it's seen work since and i lost track of it
<Paddy_NI> Chipaca, That's no worries, I wonder if the same process is all that would be needed for peerflix
<Chipaca> sounds reasonable to me
<Paddy_NI> ultimately it's just telling the media player to open "http://localhost:8888"
<Chipaca> jamesh: is that something you worked on? ^
<jamesh> Chipaca: I don't think the existing portals APIs will help much here.  It'll probably just open the URL in a web browser too
<Paddy_NI> Ah I see
<ogra> Paddy_NI, if you cant see big buck bunny anymore ... https://durian.blender.org/download/ is also fine for testing
<Paddy_NI> lol
<Paddy_NI> Thanks for that :-)
<ogra> :)
<Paddy_NI> @ogra, I am using this list https://webtorrent.io/free-torrents
<Paddy_NI> Amazing level of work has went into those videos, blows my mind.
<ogra> ah, there is sintel on the list nevermind then
<Paddy_NI> @ogra, I specifically need magnet links and torrent files to test this any how :-)
<ogra> ah
<Paddy_NI> It would be shoddy of me to stick peerflix on the store in it's current form as it is technically broken.
<Paddy_NI> I could try moving on to "mps-youtube" however I believe I shall be facing the exact same issue with regards calling external media players
<Paddy_NI> Which then brings me back to electing one that I bundle in
<Paddy_NI> MPV of course would be my desired player but this might not be true of others.  Also "mps-youtube" typically only works if both it and "youtube-dl" have been installed via "pip3"
<Paddy_NI> Installing youtube-dl via apt creates problems with paths, mps-youtube expects it to be somewhere else.
<ogra> well, you can trivially add mplayer to your stage-packages and use that ...
<Paddy_NI> @ogra, oh I like that idea
<ogra> like i do here in my wasp player https://github.com/ogra1/video-kiosk-snap/blob/master/snap/snapcraft.yaml ... https://github.com/ogra1/video-kiosk-snap/blob/master/launcher
<Paddy_NI> I might actually try that now with peerflix actually
<Paddy_NI> @ogra, Thank you :-)
<Paddy_NI> We are getting crazy amounts of rain here, I find it quite soothing.
<pedronis> Chipaca: mborzecki: as I said I don't think checking for nil in constructors is that typical
<mborzecki> off to pick up the kids
<zyga> I have a chaotic day, feel like is should take the day off to be fair
<zyga> Sorry. Iâm logged around to help with paperwork I must do in person
<zyga> mborzecki: Iâll skip standup, in traffic now
<pedronis> Chipaca: standup?
<zyga> (Not attending now, crying baby, in traffic)
<zyga> back in the office
<zyga> they are shooting a film outside again
<pstolowski> zyga: too bad it's not GoT ;)
<zyga> pstolowski: my character would die in episode two
<zyga> ;)
<Chipaca> pedronis: dunno if you saw that I addressed your feedback from #6951
<pedronis> Chipaca: yes, but no, thank you, I put it back into my queue
<ogra> Chipaca, with snap interfaces being deprecated, whats the replacement that will show me all available interfaces on a UC install (for GPIO or I2C i need to find the exact name, snap interfaces properly lists that)
<Chipaca> wat
<Chipaca> oh you mean 'snap interfaces'
<Chipaca> phew
<ogra> eh, yes, thats why i wrote snap interfaces :)
<Chipaca> ogra: snap interfaces aren't deprecated
<Chipaca> ogra: snap interfaces is deprecated
<Chipaca> these two sentences are both true
<ogra> lol
<Chipaca> the plural is important
<ogra> ok
<Chipaca> :)
<Chipaca> 'sanp interfaces', the command, is deprecated
<ogra> well, i obviously mean the deprecated command
<Chipaca> i read your original question as that plugs/slots ("interfaces") were deprecated
<Chipaca> obviously
<Chipaca> in retrospect
<Chipaca> anyway
<Chipaca> zyga: ^^^
<zyga> mmm?
<zyga> haha
<ogra> something like "snap connections --available-plugs" or so would be nice
<Chipaca> zyga: snap interfaces for properties
<Chipaca> ogra: this is specifically about the properties of the interfaces, right?
<zyga> snap interfaces for which properties?
<ogra> err ... --available-slots indeed, sorry
<Chipaca> ogra: maybe 'snap interface --attrs'?
<zyga> snap interface --attrs shows stuff
<ogra> Chipaca, this is simply to find all offered slots on a UC device
<zyga> but I really think we want snap <plug,slot> instead
<ogra> well, i dont know the slot name and i dont know what slots are available
<ogra> so i cant really hand the command a slot name
<zyga> ogra: so you want smart tab completion that shows you what is available, in a way?
<ogra> no
<zyga> I agree it'd be nice to say snap what-can-I-connect-to <plug-or-slot>
<ogra> i just want *some way* to list the available slots on a device
<zyga> ogra: snap slots is that
<ogra> no need for fancy tab completion
<zyga> it's just not implemented
<zyga> but it's agreed upon
<zyga> maybe we can do a pass for .41
<ogra> ogra@stream:~$ snap interfaces|grep i2c
<ogra> pi3:i2c-0                 -
<ogra> pi3:i2c-1                 -
<ogra> pi3:i2c-2                 -
<Chipaca> snap install zyga
<Chipaca> zyga.slots
<zyga> :D
<ogra> something that gives me that output
<zyga> Chipaca: I have one slot but it says "insert A/C"
<ogra> (even unfiltered)
<Chipaca> ogra: what's 'snap connections system'?
<Chipaca> ogra: (at the same time maybe it's premature; interfaces isn't going away yet)
<ogra> that only seems to list a subset
<ogra> none of the gadget ones
<zyga> ogra: it shows implicit slots
<ogra> yes
<zyga> ogra: it shows slots that are not associated with any installed snap
<ogra> snap connections pi3 ... that works
<ogra> an internal alias would be cool here "snap connections gadget"
<Chipaca> ogra: also note --all (dunno if it helps, don't have fancy hardware here)
 * Chipaca hugs his xeon before it gets offended
<ogra> --all also shows a subset but at least includes the gadget ones
<ogra> thanks, i think i can go with that ... perhaps the "snap interfaces" error should point to some possible alternatives to get the same info
<zyga> ogra: --all shows disconnected things AFAIK
<ogra> seems to show connected and disconnected stuff (i cant see a pattern here what it shows/doesnt show though)
<ogra> https://paste.ubuntu.com/p/GSRTXxvJ3V/
<ogra> as i said i can go with "snap connections pi3" for the particular use-case where i need to find out the interface name from a gadget ad-hoc
<Chipaca> mborzecki worked on the ux of connections
<Chipaca> i remember it being tricky to get right
<Chipaca> (and maybe it still needs work in some cases?)
<ogra> but it also means i need to know what the gadget name is ... thats why an alias might be cool here
<mborzecki> iirc we discused snap slots or similar
<zyga> brb
<ackk> jdstrand, hi I'm using the patched snapd with support for system users you built, I have supervisord configured to run a process as daemon:daemon (which is configured in the snap as system user), but I see messages like this in log: supervisor: couldn't setuid to 1: Could not set groups of effective user
<zyga> Exhausted by heat.
<jdstrand> ackk: I suspect it is calling setgroups(). see privmsg
<zyga> Maybe I should turn nocturnal
<cachio> zyga, hey
<cachio> found a problem running beta validation for amg64 http://paste.ubuntu.com/p/pzHMzjRZPG/
<cachio> runtime/cgo: pthread_create failed: Resource temporarily unavailable
<ackk> jdstrand, ah, we do use a preload which overrides setgroups/initgroups, for nginx at the moment. I guess I need to do the same for squid then
<mborzecki> cachio: Jun 05 21:52:38 localhost.localdomain snapd[20219]: runtime/cgo: pthread_create failed: Resource temporarily unavailable
<mborzecki> Jun 05 21:52:48 localhost.localdomain snapd[20219]: SIGABRT: abort
<cachio> mborzecki, yes
<mborzecki> ahh that's the policy-app-consumer, the one with bandwagon of apps
<cachio> mborzecki, any idea why it could be happening?
<cachio> mborzecki, I have the machine here
<cachio> with a debug session
<ackk> jdstrand, but, this won't help with apps like supervisors trying to run other commands with a specifi user, will it?
<ackk> jdstrand, I added the preload to squid but I see the same error
<mborzecki> cachio: this one is interesting too: snap-repair[4812]: runtime/cgo: pthread_create failed: Resource temporarily unavailable
<mborzecki> cachio: what does ps -efT | wc -l show?
<cachio> 112
<cachio> mborzecki,
<jdstrand> ackk: there should be a policy violation in the journal, what is it?
<ackk> jdstrand, dmesg or journalctl?
<ackk> jdstrand, I don't see any
<jdstrand> ackk: journalctl
<jdstrand> well, really either
<ackk> jdstrand, no denial
<jdstrand> ackk: are you using snappy-debug?
<ackk> no
<ackk> jdstrand, how does that work?
<jdstrand> ackk: sudo snap install snappy-debug ; sudo journalctl --output=short --follow --all | sudo snappy-debug
<jdstrand> ackk: that will tail the journal. then you exercise your application
<jdstrand> ackk: and it will pop out denials with suggestions if there are logged policy violations
<jdstrand> ackk: one thing it does is turn off kernel rate limiting
<jdstrand> which might be why you aren't seeing a denial
<ackk> ah, I see it now
<jdstrand> what is the denial?
<ackk> jdstrand, https://paste.ubuntu.com/p/xbbC2pJDbF/
<jdstrand> ackk: what is the name of the snap command invocation? maas.what?
<ackk> jdstrand, it's a daemon maas.supervisord
 * jdstrand notes he has a meeting in 4 minutes (coincidentally on this PR)
<ackk> sorry, maas.supervisor
<jdstrand> ackk: what is the output of grep setgroups /var/lib/snapd/seccomp/bpf/snap.maas.supervisor ?
<ackk> $ grep setgroups /var/lib/snapd/seccomp/bpf/snap.maas.supervisor.src
<ackk> # allow use of setgroups(0, NULL)
<ackk> setgroups 0 0
<ackk> setgroups32 0 0
<ackk> jdstrand, ^
<jdstrand> ackk: ok, so something with your LD_PRELOAD isn't working
<ackk> jdstrand, well supervisor doesn't have LD_PRELOAD
<jdstrand> ackk: setgroups needs to be called with setgroups(0, NULL)
<ackk> jdstrand, does it also need it?
<ackk> oh ok
<ackk> then I'll add it there too
<jdstrand> ackk: *any* setgrroups denial needs the preload
 * jdstrand -> meeting
<ackk> jdstrand, cool, thanks
<ackk> ah, and now squids actually fails to create the shm files
<ackk> I guess I need snapcraft-preload after all
<ogra> hmm, is there something with the store today ... i see a lot 503 errors why installing snaps (they dont show up on the second install attempt)
<ogra> s/why/while/
<Chipaca> woo, woo
<Chipaca> cohort pr #N is in, #(N+1) is up for review
<Chipaca> woo
<Chipaca> now running a little late for my train but, woo :)
<roadmr> ð
<roadmr> ogra: https://status.snapcraft.io/ ð
<Chipaca> pedronis: thank you for the review :)
<ogra> roadmr, well ... Download snap "chromium-mir-kiosk" (32) from channel "edge" (received an unexpected http response code (503) when trying to download https://fastly.cdn.snapcraft.io/download-origin/fastly/pKicqh8BMdA6Y6jbtWYBdI2QwhRH4v6T_32.snap?token=1559847600_743804ce162b2329f8ec18078bdcdd62d67273c6)
<roadmr> ogra: if you're consistently seeing 503s and you could turn on snapd debugging and shoot me some logs of what the store is saying, I'd be grateful - can look deeper if I have that info
<roadmr> ogra: oh! perfect! let's see
<ogra> this took three attempts ... third one was the charm and it installs now
<roadmr> ogra: oh that's the problem - you need juju if you want to install charms ð
<ogra> lol
<Chipaca> pedronis: dunno if you want to add this to your queue or not (it's low impact tbh): "overlord/snapstate, & fallout: give Install a *RevisionOptions" #6961 https://github.com/snapcore/snapd/pull/6961
 * Chipaca goes to catch that train
<ahasenack> ogra: I also got a couple of 503s today
<ahasenack> and also worked on the third attempt only
<roadmr> ahasenac, ogra: hey sooo.. yes, looks like our cdn provider is having some trouble, that explains your failure. We'll post an update in the forum/status page shortly
<ogra> well, it still works ... just needs some run-on :)
<roadmr> ogra: we've kicked the offending server, things should be copacetic now. Thanks for the report!
<ogra> thanks for fixing !
<jdstrand> pedronis: oh, I said next week I would work on the snap_daemon PR, but I forgot I will be at the snapcraft summit
<zyga> a newline in the wrong spot of debian/rules makes one funny debugging session as to WTF
<zyga> specifically the *first* line when /bin/sh executes a makefile
<albertosottile> jdstrand: Hi, we read your last comment about the Syncplay classic confinement request... we honestly do not believe that we will add <<more functionality in the realm of taking âinput from over the internet to run arbitrary commandsâ>> in the foreseeable future. So, what should we do now?
<stgraber> jdstrand: hey there, just moved lxd-demo-server from being an old core16 snap to being a snap using the core18 base and looks like this somehow triggered a manual review?
<stgraber> jdstrand: human review required due to 'allow-installation' constraint (bool) declaration-snap-v2_plugs_installation (daemon, lxd)
<stgraber> jdstrand: so looks like it's because it's using the lxd interface (normal as it drives LXD) but that's not a change from any of the previous revisions, so a bit confused as to why this is getting flagged now
<jdstrand> albertosottile: comment to that effect in the topic, then pedronis will make the final call
<jdstrand> albertosottile: and hello to you too :)
<albertosottile> jdstrand: We will, thanks :)
<jdstrand> stgraber: this doesn't have to do with the move to core18 but new tests in the review-tools. I'll grant the snap decl for you
<stgraber> jdstrand: thanks, so I guess it's just because I didn't upload that one in a while then :)
<jdstrand> stgraber: yeah, exactly
<jdstrand> stgraber: ok done. both now pass automated review. you'll need to release them to a channel
<stgraber> jdstrand: done, thanks
<jdstrand> np
<zyga> jdstrand: I'm sorry about missing the call today, I was tired and frustrated by chaotic home schedule and the heat
<jdstrand> zyga: no worries. I marked you optional and figured you simply opted out :)
<jdstrand> zyga: hope things are getting better
<zyga> jdstrand: I'm looking forward to coldness of canada
<jdstrand> zyga: hehe :)
<roadmr> zyga: the weather is amazing here, temps should be well above 20C next week, check the 7-day forecast: https://weather.gc.ca/city/pages/qc-147_metric_e.html (oh well, rainy tuesday)
<jdstrand> zyga: it's been pretty warm and humid here too
<zyga> roadmr: thank you!, looking
<zyga> temps here are looking at close to 30 all the time
<zyga> and my office behaves like a small oven with me inside
<roadmr> zyga: ouch. We'll be there in about a month; July/August can be uncomfortably warm/humid
<roadmr> summer is a crazy thing :)
<jdstrand> roadmr: hmm, it that my recent review-tools builds are stuck in 'Uploading build': https://code.launchpad.net/~myapps-reviewers/+snap/review-tools
<roadmr> jdstrand: maybe due to this morning's store trouble?
<roadmr> oh this is happening right now - that's odd
<jdstrand> I'm not aware of that trouble... if it's just catching up, that's fine. fyi since it is unusual
<roadmr> jdstrand: right, there was some network saturation, let's give them a few and see if they catch up
<roadmr> jdstrand: I see some of the stuck uploads finally uploaded - things may just be sluggish :/
<ijohnson> roadmr: fyi I have had snaps stuck in ci jobs for the past 2.5 hours trying to upload, so whatever the issue was this morning it seems to still be happening
<roadmr> ijohnson: oh thanks.... where is this ci you speak of? ð¤
<ijohnson> uhh you mean physically? I think actually it's somewhere near you in Canada, it's a jenkins server the Linux Foundation uses
<roadmr> ijohnson: well I meant whether it was e.g. travis
<ijohnson> oh haha well no it's a custom jenkins server
<ijohnson> roadmr: see for example https://jenkins.edgexfoundry.org/view/Snap/job/edgex-go-snap-edinburgh-stage-snap/10/console
<roadmr> ijohnson: ah :)
<roadmr> ijohnson: oh I see what happened - looks like revision 935 of that snap failed to complete auto-review, so that upload held the queue, subsequent uploads are awaiting review as well
<roadmr> ijohnson: I've retriggered 935; btw the timing on 935 matches when we were having bandwidth problems
<ijohnson> roadmr: hmm, but previously even when a previous snap was stuck in review snapcraft would at least stop and explain that it failed due to the queue
<ijohnson> roadmr: are you saying that because the revision failed with auto-review during the bandwidth problem time period this new upload got stuck?
<roadmr> ijohnson: yep, that could be it. btw 935 just passed, so the rest are being processed now
<ijohnson> roadmr: ack thanks, btw any idea why they failed auto-review?
<roadmr> ijohnson: probably network-related; e.g. the worker unit that runs the autoreview tries to download the snap, but it was slow/faily at that time, so it barfed, then retried... etc. They do a limited number of retries before giving up
<ijohnson> ok that makes sense, because I don't think we added anything new to that revision that would have failed review
<ijohnson> thanks for explaining
<roadmr> yep, this was "task failed to complete because I couldn't download the snap", compare to "task succeeded but obtained a failed review from the review tools"
<ijohnson> ð
#snappy 2019-06-07
<mborzecki> morning
<zyga> Hi
<mborzecki> zyga: hey hey
<zyga> mborzecki: being so tired somehow I am not looking forward to that 7AM flight tomorrow
<jamesh> zyga: so, after refactoring the session agent code as its own process, I've got something that even runs on Ubuntu Core 16
<jamesh> fails on Core 18 due to missing unit files.  I guess this is another thing that would need to be symlinked in if we wanted it to work.
<mvo> good morning! did I miss anything important yesterday?
<mborzecki> mvo: hey
<mborzecki> mvo: nothing i'm aware of, somneone found a nice bug in the forums though: https://forum.snapcraft.io/t/snap-help-install-unexpectedly-performs-the-install/11686
<mvo> mborzecki: thanks!
<pstolowski> mornings
<mborzecki> pstolowski: hey
<mvo> hey pstolowski ! good morning
<zyga> jamesh: hey
<zyga> jamesh: which unit files are missing on core18?
<zyga> jamesh: but that refactor sounds like good progress! thank you
<zyga> mvo: hey, good morning
<jamesh> zyga: it looks like it is something I could probably fix in wrappers/core18.go, after a bit more investigation
<zyga> mvo: I will file yesterday off, personal stuff and I ended up not doing much
<zyga> jamesh: I will review your branch soon
<jamesh> zyga: I also ran into problems with your "replace ! with not" suggestion.  I was calling a shell function I had defined, which is not available in the context of your "not" shell script
<zyga> jamesh: ah indeed
<jamesh> but the "not" shell script successfully inverted the "command not found" error into a success
<zyga> for shell functions you must refactor the code a little
<jamesh> so I didn't notice it until looking at the failures on core18
<zyga> jamesh: thank you for reporting that, I will special-case command-not-found to make it less surprising
<mvo> zyga: sure, no worries
<zyga> mvo: compound iza's school change (meeting the parents) and paperwork for lucy (both parents must be present)
<zyga> sorry, it will carry on today for the part of morning, I should be back at noon;
<jamesh> zyga: for what it is worth, the following shell function looks like it'd work as a a "not" implementation: not() { ! "$@"; }
<jamesh> that can see shell functions, and correctly exits on failure
<zyga> jamesh: interesting, perhaps it's worth switching over
<zyga> jamesh: thank you
<jamesh> it also has 10 consecutive pieces of punctuation, so is almost perl
<Paddy_NI> Yaay!
<Paddy_NI> First snap https://snapcraft.io/peerflix
<Paddy_NI> Some of the functionality is broken for now and there is no "official" icon.
<zyga> Paddy_NI: congratulations! How did it feel like?
<Paddy_NI> zyga, It's pretty cool, I want to do more. lol
<popey_> Paddy_NI: that's rather cool!
<Paddy_NI> popey_, I know right!  My wife doesn't get it :-(
<popey_> hah :)
<Paddy_NI> She's more excited about her new job
<Paddy_NI> X-D
<Chipaca> popey_: easter egg for you
<Chipaca> popey_: snap --help install bofh
<popey_> I was just reading that thread :)
<Chipaca> popey_: heh
<popey_> nice try ;)
 * Chipaca would put on a dunce hat but it won't fit over the donkey ears
<popey_> reminds me of the time i told someone on the desktop team to hold down the printscreen button. (bug meant it ddosed your laptop with printscreens trying to do gl photo effect). that was fun. I should have warned them :)
<Chipaca> popey_: where's the fun in warning people
<popey_> exactly
<Chipaca> what I'd _rather_ have happen is that 'snap --help foo' and 'snap foo --help' mean the same thing
<Chipaca> but, sadly, go-flags does not let me do that
<Chipaca> so you get the global help Â¯\_(ã)_/Â¯
<zyga> ok, back in some degree
<jamesh> Chipaca: maybe what the world needs is another command line parsing library?
<zyga> anyone using qemu for testing: log into your vm (without -snapshot), apt-get build-dep  -d  snapd
<zyga> that will save you 0.5GB each time you boot
<zyga> obviously setting up apt-cacher-ng is even better but this is low-tech
<mvo> mup_: hello
<Chipaca> jamesh: I've got one on my list to look into
<mvo> niemeyer: hey, could you please restart mup_ ? it seems to be unhappy
<Chipaca> jamesh: but it is very tempting
<Chipaca> jamesh: 'kingpin' i'm told is alright
<zyga> hello mvo
<mvo> hello zyga
<zyga> mvo: small update, I've created more tests and more feature code for MS_SHARED bug
<zyga> it's not fixed yet, I'm struggling with the bit related to propagation and delta algorithm
<zyga> on the up side: i've prepared matching unit and integration tests that allow easy iteration
<zyga> I'll push it all up today even if it doesn't fix the bug completely
<mvo> zyga: thanks for the update!
<Chipaca> pedronis: you got a minute?
<Chipaca> pedronis: about /v2/downloads
<Chipaca> pedronis: should we make it a GET method?
<Chipaca> current proposal has it as a POST but that feels weird
<Chipaca> pedronis: especially because post -> needs auth or user or sth
 * zyga goes offline for a while
<ogra> You should not run jhbuild as root.
 * ogra shakes fist !
<ogra> silly thing ... doesnt pick up JHBUILD_RUN_AS_ROOT=1 from the environment :(
 * Chipaca â lunch
<Eighth_Doctor> mborzecki: hey, so what kind of talk do we want to propose for Flock?
<zyga> back onine
<pedronis> Chipaca: I was at my doctor appt, if I remember we had reasons to make it a POST, we can discuss after the standup if it's not too long
<ackk> mvo, hi, the core18 snap doesn't seem to contain iptables, is that expected?
<zyga> random failure in device manager:
<zyga> https://www.irccloud.com/pastebin/pqgs1A3O/
 * zyga dinner
 * cachio lunch
<zyga> re
 * zyga runs some more spread tests
<ogra> is there any known issue with core18 currently ? seems i'm not alone in hitting:
<ogra> Press enter to configure.
<ogra> bah ... IRC
<ogra> /usr/share/subiquity/console-conf-wrapper: line 13: snap: command not found
<ogra> /usr/share/subiquity/console-conf-wrapper: line 13: snap: command not found
<ogra> Press enter to configure.
<ogra> looking at the SD i see that snapd definitely did its seeding ... so the snapd snap should be there (which makes me think that also the snap command should be there)
<ogra> could it be that snap isnt in PATH anymore ?
<ogra> (did anything change here ?)
<cachio> ogra, I saw that but time ago
<cachio> and couldn't reproduce it anymore
<ogra> i have reports from customers trying out their own core18 images seeing the same in the stable channel (i see it in edge here)
<ogra> and kyleN did hit it too apparently
<cachio> ogra, I didn't see the for a while
<ogra> strange
<cachio> I think I could reproduce it when accidentally caused an ethernet error
<cachio> and the board stayed in a weird state
<ogra> my ethernet is fine ... i'll re-flash the SD ...
<cachio> but then I was trying to reproduce it and I had no luck
<ogra> ogra@localhost:~$ fw_printenv
<ogra> -bash: fw_printenv: command not found
<ogra> sigh ... this is so overly annoying in core18 :(
<cachio> zyga, raised the lp:1832024
<cachio> I am trying to identify which test executed before is causing the error
<cachio> because when I run thtat test alone it works well
<zyga> cachio: thank you!
<Saviq> hey all, is there somewhere a list of the required / recommended kernel options for snapd to operate?
<Saviq> I'm seeing "AppArmor status: apparmor is enabled but required kernel features are missing: file" now, would like to let the ISP know what to enable (I'm in a container)
<ogra> Saviq, https://github.com/snapcore/sample-kernels/tree/master (old but still mostly valid)
<zyga> Saviq: it's ubuntu sauce patches
<zyga> Saviq: ask jjohansen  about those, or anyone from the kernel team
<jjohansen> Saviq: can you see /sys/kernel/security/apparmor from in your container?
 * zyga EOWs
<jjohansen> Saviq: we can't even at this point say the issue is ubuntu's sauce patches
<jjohansen> more likely is your ISP is not setting up apparmor for your container. It needs securityfs mapped in, or at least the apparmor subdirectory (/sys/kernel/security/apparmor)
<jjohansen> that needs to be done with a bind mount
<jjohansen> and it will need an apparmor namespace
<jjohansen> currently lxd is the only container that I know of that is setting up the apparmor namespace and bind mounting securityfs into the container
<Saviq> jjohansen: sorry for the delay, the dir is there, but yeah I'm getting ENOPERM trying to list its contents
<jjohansen> Saviq: yeah apparmor needs access to the contents, that is how it loads policy
#snappy 2019-06-08
<zigford> Hi everyone. Question about how snapd finds snap-secomp. Someone on here helped me a month or so ago with an issue on Gentoo. Gentoo have released an update which now splits /usr/lib into lib32 and lib64. I've updated the lib prefex everywhere I could find (a Makefile in snap/data and a Makefile in snap/cmd to put everything in lib64. However, on starting the snapd daemon, it is still looking for snap-seccomp in /usr/lib/snapd rather than /usr/lib64.
<zigford> I did some searching of the go files to see if the path is hardcoded and there were a few reference, but they may be related to the internals of a snap itself.
<zyga> zigford: hey
<zyga> Iâm about to take off for a trans Atlantic flight but please stick around next week. I can help you out
<zyga> Snapd is complex and there are way more aspects than prefix path
<zyga> You can chase seccomp by looking at interfaces/seccomp/backend.go
<zyga> But there is more to this than a simple fix
<zyga> zigford: you can also grab mborzecki here next week in case I am unavailable (conference)
<zigford> righto, cheers zyga. Have a good flight and conference
<Eighth_Doctor> zyga: https://pagure.io/flock/issue/163
#snappy 2019-06-09
<zyga> Eighth_Doctor: that's great!
<zyga> Eighth_Doctor: (also hi from Montreal)
<Eighth_Doctor> zyga: hey! do you think you'd also maybe be able to go to Flock this year again?
<zyga> Eighth_Doctor: it's possible but not certain
<zyga> Eighth_Doctor: I tried to look up the schedule but I could not find it
<Eighth_Doctor> August 8-11 in Budapest, Hungary
<zyga> Eighth_Doctor: the main issue is the extent of travel I already do, my family and my main work commitments
 * zyga loooks
<zyga> I'll discuss this next week
#snappy 2020-06-01
<mup> PR snapd#8773 opened: overlord/configstate: add sysctl option <Created by EthanHsieh> <https://github.com/snapcore/snapd/pull/8773>
<mborzecki> morning
<pstolowski> morning
<mborzecki> pstolowski:hey
<mborzecki> what's the fuss about openttd disappearing from the store?
<zyga> good morning
<zyga> mborzecki: ooh?
<zyga> what happened?
<mborzecki> https://forum.snapcraft.io/t/openttd-is-gone/17860/2
<zyga> interesting
<mborzecki> heh too bad the tweet went out on 30.05
 * zyga returns to tool changes
<zyga> https://github.com/snapcore/snapd/pull/8691/files looks interesting!
<mup> PR #8691: tests: plan to improve the naming and uniformity of utilities <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>
<zyga> pstolowski, mborzecki: do you guys want to have a look before I merge https://github.com/snapcore/snapd/pull/8691
<mup> PR #8691: tests: plan to improve the naming and uniformity of utilities <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>
<mborzecki> zyga: it's 2 tabs away from me looking at it
<pstolowski> zyga: i'm happy with it
<zyga> ok
<mup> PR snapd#8691 closed: tests: plan to improve the naming and uniformity of utilities <Created by pedronis> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8691>
<zyga> mborzecki: replied on https://github.com/snapcore/snapd/pull/8770 but not going to change things until there's some more usage
<mup> PR #8770: snap/naming: add ParseSecurityTag and friends <Created by zyga> <https://github.com/snapcore/snapd/pull/8770>
<zyga> mborzecki: my goal is to shring the 2K+ diff of refresh-app-awareness-v2
<zyga> mborzecki: I'm open to renaming this later on though
<zyga> mborzecki: mainly for practicality but also because I'd like to see how we use security tags across the codebase
<zyga> pstolowski: ^
<zyga> pstolowski: not sure if you saw that PR yet
<zyga> + systemd-run --system --service-type=forking --unit=qemu-ndb-preseed.service '' --fork -c /dev/nbd0 /home/gopath/src/github.com/snapcore/snapd/tests/main/preseed/cloudimg.img
<zyga> Job for qemu-ndb-preseed.service failed because the control process exited with error code.
<zyga> See "systemctl status qemu-ndb-preseed.service" and "journalctl -xe" for details.
<zyga> pstolowski: ^ should '' have had a value?
<zyga> to czesc https://github.com/snapcore/snapd/pull/8764
<mup> PR #8764: tests: add ubuntu 20.10 to spread tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8764>
<zyga> sorry, that's a part of https://github.com/snapcore/snapd/pull/8764 :)
<pstolowski> zyga: it shouldn't fail, something is not ready for 20.10, i'll find out, thanks
<zyga> ok
<pstolowski> zyga: yes, i've #8770 opened and started reviewving
<mup> PR #8770: snap/naming: add ParseSecurityTag and friends <Created by zyga> <https://github.com/snapcore/snapd/pull/8770>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8733 is fixed now
<mup> PR #8733: tests: port document-portal-activation to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8733>
<zyga> mborzecki: I have 3 more patches (2 ready, one needs an hour to polish) and no more dbus-daemon leaks
<mup> PR snapd#8713 closed: interfaces/avahi*: update avahi-daemon labelling to also allow "avahi-daemon" <Needs security review> <Squash-merge> <Created by jetpackdanger> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8713>
<zyga> sigh
<zyga> why no os.ModeRegular
<mborzecki> haha
<mborzecki> no other mode == regular
<mborzecki> btw. ModeIrregular is quite interesting tho
<zyga> mborzecki: yeah
<zyga> aka "unix says something but we cannot map it"
<zyga> pstolowski, mborzecki: as for https://github.com/snapcore/snapd/pull/8770 -- I'd like to rename those later as they are unused now and the PR is green
<mup> PR #8770: snap/naming: add ParseSecurityTag and friends <Created by zyga> <https://github.com/snapcore/snapd/pull/8770>
<zyga> if you don't mind that
<mborzecki> anyone using fish shell?
<zyga> nope
<mborzecki> zyga: https://forum.snapcraft.io/t/how-to-use-default-commands-from-those-apps-which-are-installed-using-snap-without-having-to-use-snap-run-infront-of-original-command/17878/7 idk seems to work here quite fine
<mborzecki> heh i still find it funny when when the coolness factor is what makes the choice ;)
<zyga> mborzecki: I wonder if there's a difference if fish is your default shell
<zyga> wow
<zyga> arguably fish looks awesome
<mborzecki> zyga: idk, tried `fish -l` should give me a login shell, so a vanilla setup then?
<zyga> no
<zyga> doubt it
<zyga> well, maybe
<zyga> but I doubt it :)
<mborzecki> ok, let me switc the shell and try again
<zyga> I just did
<mborzecki> pffff
<mborzecki> doesn't work
<zyga> It matters
<zyga> No snaps in sight
<zyga> heh
<mborzecki> hmm
<mborzecki> ok maybe we could drop somethign in /etc/fish/conf.d/snapd.fish ?
<mborzecki> os better /usr/share/fish/vendor_conf.d
<ogra> does anyone knwo who creates the lxd user if i install the lxd snap ? is that lxd itself or snapd on behalf ?
<zyga> ogra: I think there was a hack of some kind
<zyga> maybe snapd.deb does it
<zyga> I don't recall
<zyga> brb
<zyga> back pain
<zyga> suck a f*** annoying always-on pain :/
<ogra> zyga, well, it makes appliances with lxd preseeded unable to create a user
<ogra> i'm wondering against whom to file a bug ð
<ogra> oh man ... get well
<mborzecki> zyga: hm looked at /usr/share/fish/config.fish but i can't tell where the PATH could get set
<zyga> when in doubt
<zyga> strace and grep the source
<zyga> doing that now
<zyga> but really, fish is nice
<mborzecki> zyga: config.fish seems to do soemthing, but it's not immediately obvious
<zyga> it handles path internally
<zyga> at least a little
<zyga> let me look at the source for a moment
<mborzecki> anyways, fish env seems a bit off, even eshell includes the snap path, can't get more weird than that
<zyga> https://fishshell.com/docs/current/tutorial.html#path
<zyga> fish has some weird ideas though
<zyga> maybe we should use that fish_user_paths thing
<zyga> mborzecki: check that out https://fishshell.com/docs/current/tutorial.html#universal-variables
<mborzecki> zyga: hm interesting, stil it'd be nice to have it working, bu ti don't feel we need to fix it, i'm sure fish users have more experience as to what should be set where
<mborzecki> or at least i hope so
<pstolowski> zyga: +1 for the security tag PR
 * pstolowski lunch
<zyga> ta
<zyga> fish_xdm_login_hack_hack_hack_hack
<zyga> that's a function name:D
<mborzecki> prelude to a lot of fun i presume?
<zyga> nah, not this time
<zyga> but funny
<zyga> it runs for login shells
<zyga> hmm
<zyga> mborzecki: this is unexpected
<zyga> systemctl --user show-environment
<zyga> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
<zyga> no snap
<zyga> what the?!
<mborzecki> hm?
<mborzecki> intersting
<zyga> fish is not the problem something happened when I switched shells
<zyga> I strongly think it's systemd
 * zyga looks
<zyga> interestingly XDG_DATA_DIRS=/usr/local/share/:/usr/share/:/var/lib/snapd/desktop
<zyga> (from the same output)
<mborzecki> zyga: i did chsh and the only change i had is missing snap from path, user session looked ok
<mborzecki> i mean user session env
<mborzecki> but i did not reboot
<zyga> I rebooted
<zyga> but this is good because nothing in fish itself seems broken
<zyga> I wonder if setting a shell like "gulash" which is just a hardlink to bash would change something
<mborzecki> zyga: idk, show-environment showed the right PATH, fish had differetn PATH, seems broken to me
<zyga> mborzecki: for me show-environment shows that
<zyga> https://www.irccloud.com/pastebin/4Y7rV8b6/
<mborzecki> zyga: is snapd installed? are there any other user-session-env generators running?
<zyga> everything is installed
<zyga> this is my regular systewm
<zyga> I just changed shell and rebooted
<mborzecki> can't reboot this system, but i'll try a fedora vm
<zyga> ok,
<zyga> I'll keep digging
<zyga> just need to stretch
<zyga> grab coffee
<zyga> and take the dog out
<zyga> see you in 1 ~ h
<mborzecki> zyga: fish looks broken to me: https://paste.ubuntu.com/p/DMcVX2CBnW/
<zyga> Why did our results differ?
<zyga> in the office
<zyga> what a lousy day :/
<pstolowski> re
 * ogra files #1881588
<mup> Bug #1881588: pre-seeding lxd on Core appliances breaks snap create-user <snapd:New> <https://launchpad.net/bugs/1881588>
<mborzecki> zyga: i have no clue, that's f32 with fish shell set as default
<zyga> mborzecki: mmm, I'll dig later
<mborzecki> zyga: but guess what, on arch after a reboot there's no snap in PATH in show-environment
<zyga> mborzecki: oh?
<zyga> mborzecki: so arch and fedora differ
<mborzecki> zyga: hah, check this out
<mborzecki> zyga: this is on arch: https://paste.ubuntu.com/p/Btwnx85TM8/
<zyga> o_O
<zyga> pam talking to systemd?
<mborzecki> zyga: something imported environment when i logged in via gdsm
<zyga> check out /etc/pam.d/
<zyga> for both the login session getty
<zyga> and the one for the display manager
<mborzecki> zyga: should i be looking for anything in particular?
<zyga> yes, diff the two files used
<zyga> one will import more things
<zyga> can you find the shorter one first
<zyga> the one from getty
<zyga> how did you log in?
<zyga> via getty or via ssh?
<mborzecki> zyga: ssh
<zyga> ssh is easy to find
<zyga> find the other one
<mborzecki> when logged in via getty, the env is ok too
<mborzecki> zyga: hmm there's like 4-5 gdm-* files though
<mborzecki> i guess gdm-password is the one
<mborzecki> zyga: https://paste.ubuntu.com/p/gT3dCBB5gJ/
<mborzecki> zyga: seems pretty similar, only difference is gdm opens gnome-keyring
<zyga> hmmm
<zyga> hmm
<mborzecki> there's also gdm-launch-environment but no clue when that applies
<mborzecki> it clearly looks like something pulls in the environment from the shell and plugs it into the session
<zyga> re
<zyga> wife home, sorry
<mborzecki> heh, need to change shell to somethinf sane, the completion that fish does is super annoying
<zyga> https://twitter.com/zygoon/status/1266427249781334018
<zyga> small distraction
<zyga> food time :)
<pstolowski> hmm debian-sid failing on nfs-support test? anyone seen this?
<pstolowski> mount.nfs: an incorrect mount option was specified
<pstolowski> it's "+ mount -t nfs localhost:/home /home -o nfsvers=3,proto=udp"
<zyga> hmmm
<zyga> maybe something changed
<pstolowski> i'll find out
<ijohnson> zyga: yes I think qemu on arm64 rpi should work with "new" kernels, i.e. the one on 20.04+ I think
<ijohnson> zyga: as per https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1783961 should be in 5.3.0+ actually
<mup> Bug #1783961: CONFIG_KVM is disabled for linux-raspi2 (aarch64) <linux-raspi2 (Ubuntu):Fix Released> <linux-raspi2 (Ubuntu Eoan):Fix Released> <https://launchpad.net/bugs/1783961>
<zyga> Iâll check that shortly
<zyga> Installing gobs of packages
<mup> Issue pc-amd64-gadget#48 opened: console=ttyS0 is too slow and useless <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/issues/48>
<cachio> pstolowski, hey, #8764 updated
<mup> PR #8764: tests: add ubuntu 20.10 to spread tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8764>
<pstolowski> cachio: thanks, will take a look
<cachio> pstolowski, tx
<mup> PR snapd#8774 opened: tests: disable test of nfs v3 with udp proto on debian-sid <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8774>
<pstolowski> ^ this should unblock master
<ijohnson> thanks pstolowski
<pstolowski> cachio: there is a typo in you find command, qemu-nbd vs qemu-ndb, perhaps it is in qemu-utils after all?
<zyga> thanks pawel
<cachio> pstolowski, ouch, let me check
<pstolowski> cachio: it's confusing because we have this typo in a f ew places (e.g. unit names), but we call the right command at the end
<cachio> ah, I'll check
<oSoMoN> ogra, the zoom snap was refreshed yesterday on my wife's laptop and it stopped working (wouldn't start at all), IÂ had to revert it
<oSoMoN> known issue?
<ogra> oSoMoN, nope, havent heard of it
<oSoMoN> ogra, the laptop is in use right now so I can't get details, but I will poke at it later
<ogra> oSoMoN, https://github.com/ogra1/zoom-snap/issues/new ... and attach ~/snap/zoom-client/current/.zoom/logs/zoom-terminal.log from a failing run please
<oSoMoN> ack, will do
<mborzecki> ijohnson: would appreciate if you could later take a look at https://github.com/snapcore/snapd/pull/8775
<mup> PR #8775: [RFC] bootloader, boot: boot scripts, edition <Needs Samuele review> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8775>
<mborzecki> i can split it later to smaller bits if that helps land it sooner
<mup> PR snapd#8775 opened: [RFC] bootloader, boot: boot scripts, edition <Needs Samuele review> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8775>
<cachio> pstolowski, you were righ
<cachio> right
<cachio> test paseed
<pstolowski> cachio: nice!
<cachio> I reverted part of the change and pushed again
<cachio> thanks
<pstolowski> yw
<ijohnson> mborzecki: sure will take a look at that today
<mborzecki> ijohnson: thanks!
<ijohnson> mborzecki: hmm from first glance were we going to install both ubuntu-seed and ubuntu-boot grub.conf's though?
<ijohnson> I thought we were only going to do ubuntu-boot
<mborzecki> ijohnson: it's called for boot only now, but eventually we'd do both
<ijohnson> hmm
<ijohnson> mborzecki: but how would that work for i.e. custom u-boot in a gadget ?
 * cachio lunch
<mborzecki> ijohnson: that's tbd, it will likely be limited to gadgets we control
<ijohnson> mborzecki: mmm I see
<mborzecki> ijohnson: iow grub only for the time being ;)
<ijohnson> right :-)
<mborzecki> anywyas, eod time, going to take the kids out for some ice cream
<mup> PR snapcraft#3150 opened: cli: error/warn when using sudo <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3150>
<zyga> diddledan: openttd --edge crashes on pi4
<abeato> I'm seeing this problem with the docker snap, both in my laptop and in an arm64 machine: docker: Error response from daemon: OCI runtime create failed: container_linux.go:345: starting container process caused "exec: \"docker\": executable file not found in $PATH": unknown.
<abeato> https://paste.ubuntu.com/p/4MthKrcd3w/
<abeato> really weird
<zyga> abeato: are you seeing any denials?
<abeato> zyga, some, but I do not think they are related: https://paste.ubuntu.com/p/RHpfd7fRQ8/
<mup> PR snapcraft#3151 opened: cli: disable --target-arch support on core20 <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3151>
<mup> PR snapcraft#3152 opened: cli: disable --target-arch for multipass/lxd <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3152>
<zyga> hmm
<zyga> I think it is trying to execute /snap/bin/docker
<zyga> abeato: does this make sense to you? I think PATH is set up wrong and it searches and finds itself instead of the embedded binary
<pstolowski> oh fun, debian-sid now failed on google:debian-sid-64:tests/main/command-chain:reexec1
<zyga> pstolowski: how?
<pstolowski> zyga:  https://pipelines.actions.githubusercontent.com/xS8oSnypZkPEQZqiZgDaRp2kdvQJKbOY08TesHp7E8vn7g4hYR/_apis/pipelines/1/runs/6044/signedlogcontent/59?urlExpires=2020-06-01T16%3A11%3A12.8468116Z&urlSigningMethod=HMACV1&urlSignature=Ip%2BQIctB93sO65jma2G8J0FSRPdRG2xYwo2iB6MJdY4%3D
<abeato> zyga, not sure - but it looks like a problem with the docker snap: I saw this on an arm64 machine, then I tried and saw the same in my laptop. I'll post in the forum anyway
<zyga> pstolowski: expired URL
<pstolowski> weird.. copy: https://paste.ubuntu.com/p/R74RtVYXkd/
<pstolowski> zyga: ^
<zyga> hmmm
<zyga> no idea
<zyga> but look a that uber long line
<zyga> with recent test history
<mup> Bug #1611424 changed: Additional "lts" channel or support for upstream series <landscape> <lxd> <nova-lxd> <openstack> <Snappy:Fix Released> <https://launchpad.net/bugs/1611424>
<mup> Bug #1611424 opened: Additional "lts" channel or support for upstream series <landscape> <lxd> <nova-lxd> <openstack> <Snappy:Fix Released> <https://launchpad.net/bugs/1611424>
<mup> Bug #1611424 changed: Additional "lts" channel or support for upstream series <landscape> <lxd> <nova-lxd> <openstack> <Snappy:Fix Released> <https://launchpad.net/bugs/1611424>
<zyga> ijohnson: hey, not sure if you have a moment, I'd like to land https://github.com/snapcore/snapd/pull/8770 to open some follow-ups
<mup> PR #8770: snap/naming: add ParseSecurityTag and friends <Created by zyga> <https://github.com/snapcore/snapd/pull/8770>
<ijohnson> zyga: hey
<ijohnson> sure I can take a look this PM
<zyga> it's an extension of the existing validator to a parser for security tags
<ijohnson> that was broken out of the big refresh app awareness PR right?
<zyga> yes
<zyga> I will tweak naming in follow ups
<ijohnson> cool, yeah I remember the code as it was in that PR so hopefully shouldn't be too alien, my memory allowing :-)
<zyga> I'm trying to land pawel's PR to unbreak master so I'd rather not push more here until that lands :)
<ijohnson> of course
<zyga> ijohnson: it's not that much new code, thanks!
<ijohnson> btw, how does the github caching work when a PR is closed / re-opened ?
<ijohnson> I assume some keys set per the job are different so nothing gets cached
<zyga> ijohnson: I think it works the same way but the key is in the hash key
<zyga> and IIRC we use the github job ID
<zyga> so I think this gives us a new job
<ijohnson> hmm yeah that's kinda what I would expect
<ijohnson> not sure if it would be desirable to have jobs cached across closing/re-opening
<ogra> zyga, in case you are bored with your pi4 ... here is something to play with https://people.canonical.com/~ogra/snappy/appliances/fabrica/
<cmatsuoka> ijohnson: adding a new group to extragroups with the same gid solved the audio access problem
<ijohnson> cmatsuoka: nice, did you have to remove the one from /etc/group too ?
<ijohnson> or did everything just work with the duplicated definitions ?
<cmatsuoka> ijohnson: no, I just added a new one. Probably the name doesn't matter as long as it has the same id
<cmatsuoka> (in my case I added another audio group)
<zyga> eh, mouse stopped working
<zyga> thinkpads with linux :|
<ijohnson> mmmm
 * ijohnson -> short break
<mup> PR snapcraft#3149 closed: elf: search dynamic tags within sections, not segment <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3149>
<mup> Bug #1875493 changed: [core] log rotation doesn't properly restart rsyslogd <Snappy:Invalid> <rsyslog (Ubuntu):Invalid> <https://launchpad.net/bugs/1875493>
<ijohnson> thanks for the review jdstrand!
<jdstrand> np
<mup> Bug #1875493 opened: [core] log rotation doesn't properly restart rsyslogd <Snappy:Invalid> <rsyslog (Ubuntu):Invalid> <https://launchpad.net/bugs/1875493>
<mup> Bug #1875493 changed: [core] log rotation doesn't properly restart rsyslogd <Snappy:Invalid> <rsyslog (Ubuntu):Invalid> <https://launchpad.net/bugs/1875493>
<mup> PR snapcraft#3152 closed: cli: disable --target-arch for multipass/lxd <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3152>
<mup> Bug #1875493 opened: [core] log rotation doesn't properly restart rsyslogd <Snappy:Invalid> <rsyslog (Ubuntu):Invalid> <https://launchpad.net/bugs/1875493>
<mup> Bug #1875493 changed: [core] log rotation doesn't properly restart rsyslogd <Snappy:Invalid> <rsyslog (Ubuntu):Invalid> <https://launchpad.net/bugs/1875493>
<ijohnson> zyga: #8770 is approved, shall I merge it for you?
<mup> PR #8770: snap/naming: add ParseSecurityTag and friends <Created by zyga> <https://github.com/snapcore/snapd/pull/8770>
<mup> Bug #1875493 opened: [core] log rotation doesn't properly restart rsyslogd <Snappy:Invalid> <rsyslog (Ubuntu):Invalid> <https://launchpad.net/bugs/1875493>
<mup> Bug #1875493 changed: [core] log rotation doesn't properly restart rsyslogd <Snappy:Invalid> <rsyslog (Ubuntu):Invalid> <https://launchpad.net/bugs/1875493>
#snappy 2020-06-02
<mup> PR snapd#8774 closed: tests: disable test of nfs v3 with udp proto on debian-sid <â  Critical> <Created by stolowski> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8774>
<mborzecki> morning
<mborzecki> hmm https://forum.snapcraft.io/t/linux-mint-20-will-forbid-snapd-from-installing-and-snaps-growing-external-adoption-problem/17913
<mborzecki> and https://blog.linuxmint.com/?p=3906
<mborzecki> errand, back in 30 or so
<pstolowski> morning
<zyga> o/
<mborzecki> re
<mborzecki> zyga: pstolowski: hey
<zyga> o/
<mborzecki> mvo wrote he's going to start later today
<zyga> yeah, I noticed
<mborzecki> zyga: seen the bad press? :)
<zyga> mborzecki: it's not bad press
<zyga> (when a competitor makes a press release, it's not press, it's just a statement)
<zyga> I wish them good luck on maintaining chromium as a deb
<mborzecki> zyga: from what i understand they won't maintain a deb
<mborzecki> zyga: but rather complain about snaps each time one tries to install chromium?
<zyga> heh
<pedronis> interesting
<mborzecki> i guess a blog post is less work than packaging chromium
<zyga> the blog post clearly states commercial inteterests
<zyga> "it becomes a threat"
<pedronis> pstolowski: unit tests failing on #8567
<mup> PR #8567: o/devicestate: core20 early config from gadget defaults <UC20> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8567>
<pstolowski> pedronis: ah, thanks, weird, go test ./... didn't run those
<mborzecki> in the context of https://forum.snapcraft.io/t/snapd-cannot-run-daemon-cannot-read-state-unexpected-eof/17908/2 should we keep a backup of state.json?
<mborzecki> last known good state is likely better than scrubbing all of it
<mborzecki> we'd need to carefully select which scenarios restoring from backup could be useful
<pstolowski> yes, would be good to avoid a single point of failure like this
<mup> PR snapd#8776 opened: bootloader: rename test helpers to reflect we are mocking EFI boot locations <Simple ð> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8776>
<pstolowski> i think we scrapped any plans to migrate from json to a db?
<mborzecki> trivial PR ^^
<mborzecki> pstolowski: i don't see it in trello, so probably longer term goal?
<mborzecki> pedronis: do you remember whether we dropped json -> db?
<pedronis> I don't thinkd dropped it the right way to put it, we don't have any immediate plan, for sure not this cycle
<pedronis> it's also not clear we have a db choice
<mborzecki> diddledan: hi, pushed a little fix for the openttd snap https://github.com/diddlesnaps/openttd/pull/2
<mup> PR diddlesnaps/openttd#2: snap/gui: fix desktop file Exec <Created by bboozzoo> <https://github.com/diddlesnaps/openttd/pull/2>
<zyga> drat
<zyga> my thinkpad keeps shutting down all of a sudden
<zyga> stuff like that always happens when you look at new thinkpads
<mborzecki> zyga: anything in journal?
<zyga> 4 times today
<mborzecki> or dmesg? maybe a hardware problem?
<zyga> mborzecki: it doesn't even reset, it just goes "off"
<zyga> https://www.irccloud.com/pastebin/sHPeZkTd/
<zyga> but that's not even the last thing
<zyga> just stood out of the oridinary
<zyga> hmmm
<zyga> I'm seeing more and more failures from restarting journald
<zyga> https://www.irccloud.com/pastebin/W6kTcLLE/
<mup> PR snapd#8776 closed: bootloader: rename test helpers to reflect we are mocking EFI boot locations <Simple ð> <Skip spread> <Created by bboozzoo> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8776>
<ijohnson> morning folks
<mborzecki> ijohnson: hey, thanks for merging the PR
<ijohnson> hey mborzecki
<zyga> ijohnson: good morning!
<ijohnson> hey zyga
<ijohnson> how are you doing this morning
<zyga> heh, I was about to tell mvo about my health
<zyga> better, not well, painkillers work reliably now
<ijohnson> well that's good you're feeling better than yesterday
<zyga> I really need to see a doctor but I want to stay clear of any hospital for the next few weeks, at least
<zyga> it's so annoying, my left leg is heavily impacted by this
<zyga> I mostly work from bed, apart from standups and other calls
<zyga> I had re-lapses of this a few times but none that would be this long
<ijohnson> sorry to hear that, I know others who are in a similar situation, not wanting to go to any hospitals right now and it's quite unfortunate :-(
<mvo> zyga: ok, thank you!
<zyga> I think our government is not really doing a good job with this, and prefers to pretend the situation is good by not testing
<ijohnson> heh sounds familiar
<zyga> if it would deteriorate more I would definitely go despite the risk
<zyga> last time that saved me from a wheelchair :|
<mborzecki> zyga: do you work seated?
<zyga> mborzecki: now?
<zyga> mborzecki: no, I'm on the floor
<mborzecki> zyga: i mean in general, i recall you bought a standing desk
<zyga> yes, I use it
<ijohnson> I'm pretty strongly considering buying a standing desk or at least retro fitting my current desk to work standing
<mborzecki> i remember when i started working from home full time i had some backpain, but then with the standing desk it's no longer an issue
<mup> PR snapd#8777 opened: Enable riscv64 builds in the edge PPA <Created by xnox> <https://github.com/snapcore/snapd/pull/8777>
<zyga> mborzecki: but now standing up is not great either, I keep getting those phantom pains in my left leg
<zyga> that only go away when I'm curled up or at least not standing straight
<mborzecki> i work seated maybe 1-1.5h a day, partially caused by my super uncomfortable chair
<zyga> it was much worse before but I wonder if I will need some real help later on
<zyga> oh, my main chair broke :|
<zyga> we bought it looong time ago, when I met my wife
<zyga> so it's ~15-18 years old now
<mborzecki> zyga: yeah, better check it, sciatica is no joke if untreated
<zyga> we've ordered parts but the company making them has some issues
<zyga> mborzecki: I know
<zyga> mborzecki: spent half a year in bed crawling to the bathroom
<zyga> mborzecki: fun days
<zyga> mborzecki: how do you work for the reminder of the day?
<mborzecki> zyga: i'm available now, i need to go pick up some stuff right after the standup and be back for a bit ~5pm
<zyga> mborzecki: no no, I mean
<zyga> you said that you work seted for a fraction of the day
<mborzecki> ah, though you wanted to discuss something on HO ;)
<zyga> do you use a standing desk otherwise?
<zyga> (please forgive my terrible english phrases)
<mborzecki> zyga: yeah standing, sprints are probably the only time when i work seated (hence enjoying walking around later in the day)
<zyga> I see :)
<zyga> yeah, standing desk is really worth it :)
<zyga> I like biking so much because the position on a bike is really close to curled up "neutral" for me, so I can just go and go and go without any pain
<zyga> mborzecki: btw, I'm still using fish, I grew to like it more than zsh
<mborzecki> zyga: haha, maybe you can fix that problem then ;)
<mborzecki> zyga: the biking thing probably depends on the bike type/frame geometry, i can totally see how most people would find a road bike uncomfortable
<mup> PR snapd#8778 opened: tests: modernize and use snapd.tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8778>
<zyga> mborzecki: not being a biking expert I'm not sure how to call my bike :)
<mborzecki> zyga: not an expert either, i just enjoy riding bikes :P
<zyga> I think it's a mountain bike
<zyga> though now with all the bike lanes that grow like grass after rain, I think a city bike would be good too
<zyga> mborzecki: could you look at https://github.com/snapcore/snapd/pull/8733
<mup> PR #8733: tests: port document-portal-activation to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8733>
<zyga> I addressed your comments there
<mup> PR snapcraft#3153 opened: review-tools: add --allow-classic flag for local review <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3153>
<zyga> more journal failures
<zyga> I will look after the branch I'm working on is odne
<zyga> *done
<mup> PR snapd#8733 closed: tests: port document-portal-activation to session-tool <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8733>
<mup> PR snapd#8779 opened: osutil: Enable riscv64 build <Created by xnox> <https://github.com/snapcore/snapd/pull/8779>
<cachio> mvo, hey
<cachio> mvo, any idea why test-snapd-rsync-core20 is not published for arm64?
<ijohnson> cachio: wasn't that the one I built locally for you and sent to you ?
<cachio> ijohnson, yes, but then mvo fixed that and published for all the archs
<cachio> but arm64 is missing
<ijohnson> ah ok
<cachio> don't know if mvo forgot to upload or there is a problem
<cachio> not sure
<mup> PR snapd#8780 opened: tests: core20 early defaults spread test <Created by stolowski> <https://github.com/snapcore/snapd/pull/8780>
<mup> PR snapd#8781 opened: tests: modernize tests.session and port everything using it <Created by zyga> <https://github.com/snapcore/snapd/pull/8781>
<mvo> cachio: let me check, maybe something failed somewhere
<cachio> mvo, thanks
<mup> PR snapd#8770 closed: snap/naming: add ParseSecurityTag and friends <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8770>
<zyga> this is ready now https://github.com/snapcore/snapd/pull/8778
<mup> PR #8778: tests: modernize and use snapd.tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8778>
<mup> PR snapd#8779 closed: osutil: enable riscv64 build <Created by xnox> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8779>
<ijohnson> cachio: pstolowski: thoughts on https://github.com/snapcore/snapd/pull/8780/files#r433896786 ?
<mup> PR #8780: tests: core20 early defaults spread test <Created by stolowski> <https://github.com/snapcore/snapd/pull/8780>
<cachio> ijohnson, thanks
 * cachio afk
<ijohnson> degville: when you have a chance could you review the wording in my message here for `snap remove --help`?
<ijohnson> https://github.com/snapcore/snapd/pull/8782
<mup> PR #8782: cmd/snap/remove: mention snap restore/automatic snapshots <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8782>
<mup> PR snapd#8782 opened: cmd/snap/remove: mention snap restore/automatic snapshots <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8782>
<degville> ijohnson: yes, of course. Looking now.
<ijohnson> thank you!
<zyga> pedronis: could you please look at https://github.com/snapcore/snapd/pull/8778
<mup> PR #8778: tests: modernize and use snapd.tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8778>
<zyga> just to make sure the snapd.tool exec <TOOL> thing is what you expected
<ijohnson> gosh I still just can't believe how cool it is that when I restart a spread run all the successful runs are cached
<zyga> yeah :D
<zyga> move from travis was worth it
<diddledan> zyga, it looks like the crash in openttd is because pulseaudio isn't being used on the pi default desktop?
<zyga> diddledan: I installed ubuntu-desktop (note: this was not raspbian)
<diddledan> oh
<diddledan> hmm
<zyga> diddledan: I also installed the deb and that did work
<diddledan> no idea then
<zyga> though there was no sound as my speaker was connected over usb and probably not default
<diddledan> it looks to be crashing immediately after trying to access pulse on my raspberry pi os install
<diddledan> s/pulse/alsa/
<mvo> zyga: what's the current way to format our c code?  clang-format?
<zyga> mvo: we use a hybrid approach to avoid flag days, make fmt will use both clang format and indent depending on the file name
<zyga> mvo: I strongly prefer clang format but I don not want to enforce it as the format also shifts from time to time and it's just not worth it
<mvo> zyga: that's fine, it's for a new file
<zyga> mvo: ideally new files should be clang, existing files should be using whatever was used
<pstolowski> ijohnson: thanks, replied
<zyga> pstolowski: https://bugs.launchpad.net/bugs/1881350 is interesting
<mup> Bug #1881350: snap seeding fails with libc6-lse <glibc (Ubuntu):New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1881350>
<zyga> does anyone know what libc6-lse is?
<pstolowski> zyga: indeed
<diddledan> zyga: not existing in the archive?
<diddledan> .. at least I can't find it
<zyga> diddledan: the report mentions 20.10
<diddledan> oh. must be new then
<ijohnson> lse is a new arm64 feature AFAIK
<ijohnson> "Large System Extensions"
<ijohnson> see also https://launchpad.net/ubuntu/+source/glibc/2.31-0ubuntu9
<zyga> heh
<ijohnson> also https://en.wikichip.org/wiki/arm/armv8.1
<zyga> pstolowski: new custom weird stuff :)
<diddledan> aah
<zyga> https://github.com/snapcore/snapd/pull/8781 is ready for review
<mup> PR #8781: tests: modernize tests.session and port everything using it <Created by zyga> <https://github.com/snapcore/snapd/pull/8781>
<mup> PR snapd#8784 opened: snap: add new `snap run --gdbserver` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8784>
<mup> PR snapd#8640 closed: wrappers: pass 'disable' flag to StopServices wrapper (2/N) <Services âï¸> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8640>
<zyga> https://github.com/snapcore/snapd/pull/8778 needs a 2nd review though perhaps I can merge it as-is as it's really boring and should not linger
<mup> PR #8778: tests: modernize and use snapd.tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8778>
<mborzecki> mvo: did you get gdbserver working for a regular user then?
<mborzecki> if it works it'd be a great improvement
<mborzecki> then i can polish some of the manual solib-search-path/sysroot tweaks and turn those into a script you could load from gdb
<mvo> mborzecki: ohhh, that would be nice
<mvo> mborzecki: well, gdbserver runs as root as it needs to attach via ptrace :(
<mvo> mborzecki: but the app runs as user, the gdb that attaches is run as user
<mborzecki> mvo: i'll play with the branch a bit
<pstolowski> zyga: see last comments https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1881350
<mup> Bug #1881350: snap seeding fails with libc6-lse <glibc (Ubuntu):New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1881350>
<zyga> looking
<zyga> ooohh
<zyga> interesting :)
<zyga> onse sec
<zyga> *one sec
<mvo> mborzecki: cool, keep me updated
<zyga> btw, are there more complete logs in that bug report?
<mborzecki> mvo: btw. we need gdbserver in core20
<mvo> mborzecki: it will use the gdbserver from the outside
<mvo> mborzecki: to avoid the ptrace problem inside the confinement
<mborzecki> ah cool
<zyga> pstolowski: snap-confine has this permission
<zyga>     /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libpthread{,-[0-9]*}.so* mr,
<zyga> pstolowski: I commented on the bug but it looks like something is more seriously broken
<zyga> I suspect we need a different apparmor permission for the different binary
<zyga> and it just manifests itself as that pthread thing
<zyga> the fix is likely a one liner in the apparmor profile
<zyga> I will EOD soon
<zyga> need to go for a bike ride or I will go insane
<pstolowski> zyga: i see. thanks
<zyga> pstolowski: thank you!
<mup> PR snapd#8769 closed: dbusutil: move all D-Bus helpers and D-Bus test helpers <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8769>
 * cachio lunch
<pstolowski> cachio: +1 for your 20.10 PR
<zyga> one last PR today: https://github.com/snapcore/snapd/pull/8785
<mup> PR #8785: sandbox/cgroup: move FreezerCgroupDir from dirs.go <Created by zyga> <https://github.com/snapcore/snapd/pull/8785>
<zyga> breaking parts of the big sandbox/cgroup patch from the backend branch
<zyga> it's super small and straightforward
<mup> PR snapd#8785 opened: sandbox/cgroup: move FreezerCgroupDir from dirs.go <Created by zyga> <https://github.com/snapcore/snapd/pull/8785>
 * zyga EODs with a warm encouragement to merge https://github.com/snapcore/snapd/pull/8781 and avoid further suffering during the transition
<mup> PR #8781: tests: modernize tests.session and port everything using it <Created by zyga> <https://github.com/snapcore/snapd/pull/8781>
<cachio> Psi-Jack, tx
<Psi-Jack> Huh?
<diddledan> Psi-Jack, is that a "huh? I didn't do nuffin. you can't prove I did it. wasn't me."
<mup> PR snapd#8786 opened: arch: add riscv64 <Created by xnox> <https://github.com/snapcore/snapd/pull/8786>
<mvo> cachio: test-snapd-rsync-core20 should be available for arm64 now
<cachio> mvo, yes I saw that
<cachio> thanks
<mvo> yw
<cachio> mvo, I created #8787
<mup> PR #8787: tests: install test-snapd-rsync snap from edge channel <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8787>
<mvo> cachio: ta
<cachio> which is needed for uc20
<Psi-Jack> More like a "huh? Why are you telling me to transmit randomly?"
<mup> PR snapd#8787 opened: tests: install test-snapd-rsync snap from edge channel <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8787>
 * Psi-Jack glares to cachio.
<cachio>  :), sorry about thatpstolowski -> Psi-Jack
<cachio> pstolowski left and I didn't noticed
<Psi-Jack> Hehe. It's all cool. :)
<cachio> ijohnson, zyga? could yo please take a quick look to #8787 ?
<mup> PR #8787: tests: install test-snapd-rsync snap from edge channel <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8787>
<zyga> yes
<cachio> I need it for rpi4 validation on uc20
<cachio> it is super simple
<zyga> cachio: I don't understand the "idea is to use edge"
<zyga> is edge different from stable here?
<cachio> it is the same
<cachio> but we are publishing just on edge for the new snaps
<zyga> I see
<cachio> I'll remove them from stable
<zyga> ok
<cachio> the test snapd should be just published on edge
<cachio> when possible
<zyga> cachio: reviewed
<cachio> zyga, ijohnson thanks!!
<ijohnson> cachio: yaw
<mup> PR snapcraft#3153 closed: review-tools: add --allow-classic flag for local review <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3153>
 * zyga EODs for real this time
<mup> PR snapd#8788 opened: cmd/snap-confine: add support for libc6-lse <Bug> <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8788>
<cmatsuoka> cachio: where is MATCH defined in our tests?
<cmatsuoka> cachio: ah, just found it
<cachio> cmatsuoka, there are 2 MATCH
<cachio> 1 in testslib/bin
<cachio> another defined inside spread
<cachio> also we have NOMATCH
<cachio> defined inside spread
<cmatsuoka> cachio: yes, I now see that in spread.yaml we overwrite the dummy definition
<ijohnson> mvo: if you have time yet today, could you sudo git merge https://github.com/snapcore/snapd/pull/8782 ? it is stuck waiting for travis, I could close and re-open if you wanted instead but seems wasteful
<mup> PR #8782: cmd/snap/remove: mention snap restore/automatic snapshots <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8782>
 * cachio -> cofee
<mvo> ijohnson: sure
<mup> PR snapd#8782 closed: cmd/snap/remove: mention snap restore/automatic snapshots <Simple ð> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8782>
<mup> PR snapd#8764 closed: tests: add ubuntu 20.10 to spread tests <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8764>
<mup> PR snapd#8781 closed: tests: modernize tests.session and port everything using it <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8781>
<mup> PR snapd#8789 opened: interfaces/docker: use implicitOnClassic: true <Needs Samuele review> <â Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8789>
<mup> PR snapcraft#3150 closed: cli: error/warn when using sudo <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3150>
<mup> PR snapcraft#3151 closed: cli: disable --target-arch support on core20 <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3151>
<mup> PR snapd#8787 closed: tests: install test-snapd-rsync snap from edge channel <Simple ð> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8787>
<cachio> ijohnson, hey
<ijohnson> hi cachio
<cachio> about the comment you left in the review
<ijohnson> on stolowski's PR?
<cachio> I dont get the first part
<cachio> yes
<ijohnson> yes sorry I was confused
<ijohnson> I read the wrong section in the spread.yaml
<cachio> ah, ok
<cachio> because in the past I created some images in gce with nested vms precreated and running
<cachio> I dont know if you were suggesting something like this
<ijohnson> no sorry for the confusion
<cachio> ijohnson, np
<cachio> ijohnson, I have a question
<ijohnson> sure
<cachio> in pi4 I see this error https://paste.ubuntu.com/p/rsGWsBWJ2r/
<cachio> preparing the main suite
<cachio> any idea?
<ijohnson> huhu
<ijohnson> huh
<ijohnson> no I don't let me look in the prepare for that suite
<ijohnson> perhaps it's checking for a particular dtb
<cachio> dindt found nothing about dtb in prepare
<cachio> first time I see that issue
<ijohnson> cachio: do you have more logs ?
<ijohnson> yes it is very odd indeed I've never seen it either
<ijohnson> cachio: is it maybe from get_boot_path ?
<cachio> ijohnson, this is the full log https://paste.ubuntu.com/p/RP3wNqJvvC/
<cachio> it is the rpi with 8gb
<cachio> ijohnson, running now with the 4gb version
<cachio> ijohnson, using this image http://cdimage.ubuntu.com/ubuntu-core/20/dangerous-beta/current/ubuntu-core-20-arm64+raspi.img.xz
<ijohnson> cachio: I'm inclined to think it's failing with the get_boot_path but for some reason it clips the output
<ijohnson> cachio: I see similar end of output when I run that same command on my uc pi, i.e. `ls -alR /boot` shows similar output of
<ijohnson>  /boot/uboot/pi-kernel_162.snap/dtbs/overlays:
<ijohnson> total 385
<ijohnson> drwxr-xr-x 2 root root 15360 May 29 07:11 .
<ijohnson> drwxr-xr-x 4 root root   512 May 29 07:10 ..
<ijohnson> -rwxr-xr-x 1 root root   569 May 27 13:45 act-led.dtbo
<cachio> ijohnson, in restore I see this boot_path='Cannot determine boot path
<ijohnson> cachio: right that makes sense that would cause the prepare error you see
<ijohnson> let me look at the logs more
<ijohnson> not sure what the issue is yet
<ijohnson> cachio: I don't see that `Cannot determine boot path` message in the full log you sent, where do you see that?
<cachio> ijohnson, hehe, I read the previous error log
<cachio> 1 sec
<cachio> ijohnson, https://paste.ubuntu.com/p/KCdkWyt4ND/
<ijohnson> cachio: do you have a shell to this system ?
<cachio> ijohnson, no
<ijohnson> cachio: but you are using the released image?
<cachio> yes
<ijohnson> err rather the images published on cdimage
<ijohnson> ok
<cachio> the one from beta
<cachio> http://cdimage.ubuntu.com/ubuntu-core/20/dangerous-beta/current/ubuntu-core-20-arm64+raspi.img.xz
<ijohnson> let me download it and try to flash it, it will take me a while though
<cachio> well
<cachio> I know
<cachio> total 5
<cachio> drwxr-xr-x 3 root root  512 Jun  2 20:16 .
<cachio> drwxr-xr-x 6 root root   70 May 27 15:05 ..
<cachio> -rwxr-xr-x 1 root root 4096 Jun  2 20:16 boot.sel
<cachio> drwxr-xr-x 3 root root  512 May 15 21:06 pi-kernel_155.snap
<cachio> this is what we have
<ijohnson> hmmmm
<cachio> if [ -f /boot/uboot/uboot.env ] || [ -f /boot/uboot/uboot.sel ]; then
<cachio> and we check that
<ijohnson> cachio: is this shell maybe being run in install mode ?
<cachio> boot.sel vs uboot.sel
<ijohnson> ahhhh I see
<ijohnson> cachio: yes it should be boot.sel
<cachio> I'll create a quick pr for that
<ijohnson> sure, let me know and I can approve it
<cachio> ijohnson, thanks
<cachio> ijohnson, I don't know why it is not failing in pi3
<cachio> ijohnson, any idea if in pi3 we have uboot.sel?
<cachio> or boot.sel?
<cachio> I can't get any pi3 on the lab
<ijohnson> cachio could be a typo in the gadget maybe?
<ijohnson> Let me look
<ijohnson> cachio no it should not be uboot.sel on pi3
<cachio> ok, thnanks
<cachio> ijohnson, https://github.com/snapcore/snapd/pull/8790
<mup> PR #8790: tests: update the file used to detect the boot path on uc20 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8790>
<mup> PR snapd#8790 opened: tests: update the file used to detect the boot path on uc20 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8790>
 * cachio afk
<mup> PR snapd#8791 opened: snap/prepare_image: Add support for append/remove <Created by xnox> <https://github.com/snapcore/snapd/pull/8791>
<mup> PR snapd#8792 opened: interfaces: miscellanious policy update xlv <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8792>
<mup> PR snapd#8793 opened: interfaces: miscellanious policy update xlv - 2.45 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8793>
<mup> PR snapd#8794 opened: boot/bootstate16.go: clean snap_try_* vars when not in Trying status too <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8794>
<mup> PR snapd#8795 opened: cmd/snap-bootstrap/initramfs-mounts: also copy systemd clock + netplan files <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8795>
#snappy 2020-06-03
<mborzecki> morning
<mvo> hey mborzecki
<mborzecki> mvo: hey
<mup> PR snapd#8777 closed: packaging: disable buildmode=pie for riscv64 <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8777>
<mborzecki> mvo: there is no docs for the snapd API besides the code, right? i recall we discussed tools to use for documenting it nicely, but i don't recall seeing any readmes or whatnot
<mvo> mborzecki: sorry for the delay, did not see the msg - here are the docs https://github.com/snapcore/snapd/wiki/REST-API
<mvo> mborzecki: but very outdated
<mborzecki> mvo: thanks!
<mborzecki> mvo: hm maybe we should move that to the forum
<mborzecki> mvo: added the snapd REST API docs page in the forum  https://forum.snapcraft.io/t/snapd-rest-api/17954 we'll need to update it though
<mvo> mborzecki: oh, nice
<mvo> mborzecki: yes, it needs updating but having it here is a good step, I wonder if we can delete the wiki version or if we can redirect it or something
<mborzecki> funny, i've never looked in the wiki section in the snapd repo, immediately assumed that forums is where it would live since we have all the docs there
<mborzecki> mvo: perhaps we can discuss that quickly during the standup?
<mvo> mborzecki: +1
<mvo> mborzecki: yeah, the issue was that we always wanted to move it but there was never time and the perfect was (maybe) the enemey of the good
<mvo> mborzecki: i.e. just moving it to the forum as is not that much work and beneficial but we always wanted to do more (like auto-generating it) hence the delay :/
<mvo> mborzecki: anyway, thanks for doing this!
<mborzecki> mvo: with gh actions, maybe we could update the forum doc automatically? :)
<mvo> mborzecki: heh - nice idea!
<zyga> o/
<mvo> good morning zyga
<zyga> mborzecki: actions can trigger on directories
<zyga> good morning
<zyga> though it's bad, I can barely stand :/
<mvo> zyga: oh no :(
<mborzecki> zyga: nice, so we'd need to agree on a format of the doc, swagger or maybe just plain markdown, and then push that to the forum automatically from master?
<mborzecki> same markdown should work on github wiki if we want to keep maintaining that
<pstolowski> morning
<zyga> eh, thinkpad died on the spot again
<pedronis> mvo: mborzecki: what is this https://forum.snapcraft.io/t/snapd-rest-api/17954 ?
<mborzecki> pedronis: tried moving the snapd api docs from github wiki to the forum where they can be found, quick HO to discuss what to do with this?
<mvo> pedronis: it's the old rest API from the wiki, mborzecki  moved it over to the forum this morning
<pedronis> I would really like to involved in this kind of things
<pedronis> mvo: there are bit that we probably don't want to document anymore at all
<mborzecki> pedronis: sorry, maybe i was a bit quick to move that
<mvo> pedronis: sure, what do you recommend? hiding the post? or "fixing", i.e. marking the bits we don't want as obsolete or removing them?
<pedronis> mvo: did we plan to work on this right now?
<pedronis> but yes, moving it over without a plan of how to improve it doesn't seem a great idea to me, but my 2cts
<mvo> pedronis: we did not plan this
<mup> PR snapd#8520 closed: data: fix shellcheck warnings in snapd.sh.in <Simple ð> <Created by jelovac> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8520>
<mvo> pedronis: if you think it's a net-negative we can just hide/remove it again
<pedronis> mvo: did you at least talk with Graham?
<mborzecki> pedronis: i'm happy to have a chat about that, the reason i moved it was that it was not easy to find them, so if they're in the forum could start updating them incrementally
<pedronis> mborzecki: the problem is, we should discuss what to simply scrub before moving it over at least
<mvo> pedronis: I did not, this happend this morning. but I think the intention is good and give us a chance to improve things. I understand your concerns though, maybe we can hide it and tweak it with the help of graham and then add it back? how does that sound?
<pedronis> mvo: it should have been put in some place easier to edit at least initially
<mborzecki> pedronis: ok, let me find out where degville keeps the pages for editing, move it to that location and we can take it from ther, wdyt?
<mup> PR snapd#8767 closed: snap: (small) refactor of `snap download` code for testing/extending <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8767>
<mborzecki> mvo: small tweak https://github.com/snapcore/snapd/pull/8722#discussion_r434363214
<mup> PR #8722: tests: check that host settings like hostname are settable on core <Created by mvo5> <https://github.com/snapcore/snapd/pull/8722>
<mvo> mborzecki: let's do that then, move into degville queue and hide until it's a bit nicer (we need to remove some bits like "buy")
<mborzecki> ack
<zyga> mvo: https://github.com/snapcore/snapd/pull/8722#pullrequestreview-423293055
<mup> PR #8722: tests: check that host settings like hostname are settable on core <Created by mvo5> <https://github.com/snapcore/snapd/pull/8722>
<degville> mborzecki / mvo / pedronis: (morning!) it's great we're updating those API docs (thanks mborzecki!) - they've been on my mind for a long time. I think it's ok marking them WIP on the forum for now until we can go over them. They won't be published outside the forum until we add the page to the whitelist. They're currently only as broken as the GH wiki version :)
<mborzecki> degville: hi, thanks for the tip, was about to add the header you have in other docs but i see you're already editing the page
<degville> mborzecki: yeah, I just expanded on your note a little.
<mborzecki> degville: great, thank you
<pedronis> degville: there are really some things that we want to stop documenting, that's the part I'm unhappy about
<pedronis> becaue they are again in fron of people
<degville> pedronis: ok. would you rather I unlist the page? or would you simply prefer us to move it to a google doc for now?
<pedronis> degville: well unlist for now and we talk in the standup about what needs removing and we decide how to proceed?
<degville> pedronis: yep, np.
<degville> done
<mborzecki> pedronis: should we unlist the wiki page too? https://github.com/snapcore/snapd/wiki/REST-API
<mborzecki> mvo: playing with your gdbserver branch, i think i've hit: https://sourceware.org/bugzilla/show_bug.cgi?id=18945
<mborzecki> mvo: maybe it'd also be nice to pass a port number in --gdbserver[=<port>], otherwise the gdb command is different for each invocation
<mvo> mborzecki: looking, sorry
<pedronis> mborzecki: we can do that once we have decided what to do with the moving to the forum
<mborzecki> pedronis: ok
<mup> PR snapd#8773 closed: overlord/configstate: add sysctl option <Created by EthanHsieh> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8773>
<mvo> mborzecki: reading this bug makes me wonder if the approach is doomed
<mvo> mborzecki: actually, hm
<mvo> mborzecki: maybe a quick ho?
<mborzecki> mvo: ok
<mborzecki> standup?
<mvo> mborzecki: yeah, 1min
<mvo> mborzecki: ready when you are
<zyga> pedronis: can you look at https://github.com/snapcore/snapd/pull/8778 again please
<mup> PR #8778: tests: modernize and use snapd.tool <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/8778>
<pedronis> zyga: not now, just mark it unblocked I suppose
<zyga> ok
<zyga> I put it on PATH
<zyga> I guess that's okay
<mborzecki> mvo: pushed some tweaks to https://github.com/snapcore/snapd/pull/8784 please take a look when you have a slot
<mup> PR #8784: snap: add new `snap run --gdbserver` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8784>
<mvo> mborzecki: \o/ thank you, looking
<mvo> mborzecki: thanks for https://github.com/snapcore/snapd/pull/8784#discussion_r434384356 - I like this idea a lot
<mup> PR #8784: snap: add new `snap run --gdbserver` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8784>
<mvo> mborzecki: I really like your idea of breaking at exec and avoid the raise(SIGTRAP) but that's for later I guess :)
<mborzecki> hmm actually surprised, i'm looking at the backtrace from a segfault in snap-store
<mborzecki> target:/snap/snap-store/467/gnome-platform/usr/lib/x86_64-linux-gnu/libgdk-3.so.0 gtk3 in gnome platform snap are built with symbols?
<mborzecki> the entries in backtrace are pretty detailed, eg `#5  0x00007f473cedab04 in gtk_label_get_preferred_layout_size (label=0x5612253d4ef0, smallest=0x7ffcf00c89b0, widest=0x7ffcf00c89a0) at ../gtk/gtklabel.c:3725`
<mborzecki> heh, info sharedlibrary definitely lists some of the libraries in snap-store & gnome snaps are cotnainig debug symbols
<zyga> pedronis: do you have a moment to summarize what you want to do about snapd tools?
<zyga> pedronis: you said you want them to behave more like in classic
<zyga> are you thinking about making whatever tools we have available in the initial mount ns and then just inheriting all of that (and change propagation) into snap namespaces?
<pedronis> zyga: probably better to chat tomorrow
<zyga> pedronis: I may be off tomorrow for a medical visit, if you have the time just summarize this in an email and share that when you have the time
<zyga> pedronis: but that's fine, I have things to do
<zyga> just wanted to understand your ideas better
<mup> PR snapd#8796 opened: tests: modernize retry tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8796>
<mborzecki> zyga: https://forum.snapcraft.io/t/gimp-broken/17958
<zyga> hmm
 * zyga tries
<zyga> mborzecki: I wonder if we released robust mount namespace updates?
<mborzecki> wasn't that in 2.44 already?
<mborzecki> ah no, it was but disabled, 2.45 made it default in https://github.com/snapcore/snapd/commit/716ec3de3526e7c6eb1b22e3d077b4fc48d69a6e
<zyga> mborzecki: works on my machine :/
<mborzecki> heh ;)
<mborzecki> quick errand, back in 30
<mborzecki> re
<zyga> pstolowski: follow up from the parsed security tag branch https://github.com/snapcore/snapd/pull/8797
<mup> PR #8797: snap/naming: add helpers to parse app and hook security tags <Created by zyga> <https://github.com/snapcore/snapd/pull/8797>
<pstolowski> zyga: ty!
<mup> PR snapd#8797 opened: snap/naming: add helpers to parse app and hook security tags <Created by zyga> <https://github.com/snapcore/snapd/pull/8797>
<mborzecki> zyga: something is wrong with the spread jobs, ther's a bunch of queued jobs, some from 15h ago
<zyga> mborzecki: checking
<zyga> hmmm
<zyga> odd
<mborzecki> zyga: https://github.com/snapcore/snapd/actions?query=workflow%3ATests
<zyga> yeah, I looked
<zyga> I saw something similar yesterda
<zyga> when after a unit test job was finished
<zyga> all of a sudden *all* the spread jobs started
<zyga> maybe it's somehow related to slot allocation
<pedronis> mborzecki: I did a pass on #8775, it's a bit unclear what should happen with the recovery partition scripts
<mup> PR #8775: [RFC] bootloader, boot: boot scripts, edition <Needs Samuele review> <UC20> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8775>
<pedronis> it seems to support updates but not installing
<pedronis> but then updates are called install
<zyga> mborzecki: ha, it just happened
<zyga> brb
<mborzecki> pedronis: thanks, will check the comments
<mborzecki> zyga: anything interesting there? did the spread jobs start?
<jdstrand> mvo, pstolowski: is tests/lib/nested.sh supposed to be shellcheck clean on bionic?
<pstolowski> jdstrand: it should be clean everywhere, yes
<jdstrand> let me get you a paste
<jdstrand> (me dev container is still bionic)
<jdstrand> my*
<jdstrand> pstolowski: https://paste.ubuntu.com/p/wPYVVt4VdX/
<jdstrand> pstolowski: you did touch that line recently, but if I change it back, more errors are unconvered
<pstolowski> jdstrand: that's unexpected, should have been caught on travis; thanks, i'll check it
<jdstrand> pstolowski: thank you. note, it had been a while (weeks?) since I last ran run-checks (tasked with work that didn't involve submitting PRs), so not sure when it was introduced
<zyga> hmmm
<zyga> mborzecki: lxd refreshed and we ran out of memory
<zyga> we allocated all the memory and the system was in limbo state after oom killer went hunting
<pstolowski> jdstrand: ok,  weird.. even recently i had a shellcheck error there and it was preventing merging. very weird it get through
<pstolowski> *got
<mborzecki> zyga: hm, w8, how much mem does this system have?
<zyga> I'm looking though the logs now
<zyga> 8GB
<zyga> mborzecki: but it's not usually staturated, it's happened the moment lxd refresh ran
<zyga> https://usercontent.irccloud-cdn.com/file/DTVVZl9c/overnight%20lxd%20refresh%20crash
<zyga> load average approaching 1K?
<mborzecki> hmm auto update ;)
<zyga> maybe I should configure lxd with memory limits
<mborzecki> zyga: can you see what got killed by oom?
<zyga> https://usercontent.irccloud-cdn.com/file/j5i39wAk/dashboard%20over%20last%20two%20weeks
<jdstrand> pstolowski: I noticed that shellcheck is only conditionally run on if it is installed. not sure if that helps track things down for you...
<pstolowski> jdstrand: interesting.. thanks!
<pedronis> pstolowski: should we re-run things to land #8567? or do you want to see #8780 green first?
<mup> PR #8567: o/devicestate: core20 early config from gadget defaults <UC20> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8567>
<mup> PR #8780: tests: core20 early defaults spread test <Created by stolowski> <https://github.com/snapcore/snapd/pull/8780>
<pstolowski> pedronis: restarted. i don't think it needs to wait for 8780
<pedronis> ok
<mup> PR snapd#8798 opened: data/selinux: allow checking /var/cache/app-info <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8798>
<mup> PR snapd#8799 opened: interfaces/system-packages-doc: fix typo in variable names <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8799>
<pedronis> jdstrand: I tried to answer your questions in a couple of open PRs
<xnox> mvo:  what needs to happen to have https://github.com/snapcore/bolt/pull/1 merged & then vendorized version updated?
<mup> PR bolt#1: Enable riscv64 build <Created by xnox> <https://github.com/snapcore/bolt/pull/1>
<xnox> given it is #1 i fear this has never been excercised =)
<zyga> pedronis: updated the parsed tag PR
<zyga> I need to reboot, my thinkpad is acting up again, x input broke
<zyga> eh
<jdstrand> mvo: fyi, https://github.com/snapcore/snapd/pull/8398#issuecomment-638175977 (I deconflicted but there are cla-check issues still)
<mup> PR #8398: usersession/userd: add "slack" to the white list of URL schemes handled by xdg-open <Created by troyready> <https://github.com/snapcore/snapd/pull/8398>
<zyga> jdstrand: o/ 8788 is not more strict (the hwcaps PR)
<zyga> is *now* more strict
<jdstrand> pe
<mvo> xnox: merged now, now it just needs an update to the vendor.json in snapd, I can do that after the meeting
<jdstrand> pedronis: thanks! I responded to PR 8789 (note, that isn't urgent so if you're busy, feel free to circle back)
<mup> PR #8789: interfaces/docker: use implicitOnClassic: true <Needs Samuele review> <â Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8789>
<zyga> mvo: I don't really feel able to attend the meeting today
<xnox> mvo:  tah. I don't know how to correctly do govendor stuff. and plus then the ci will run against this bolt change for the first time.
<xnox> it better not regress anything on non-riscv64!
<mborzecki> pstolowski: https://github.com/snapcore/snapd/blob/master/.github/workflows/test.yaml#L74-L78
<mborzecki> maybe we should use --edge there
<mvo> zyga: no worries, get well!
<mvo> xnox: no worries
<pstolowski> mborzecki: thanks, is it run only on 16.04 or am I reading it wrong?
<pstolowski> jdstrand: turns out we run shellcheck from a snap (which is shellcheck 0.7.0). bionic has shellcheck 0.4.6
<pstolowski> jdstrand: can you try with the version from snap?
<jdstrand> oh!
<mup> PR snapd#8800 opened: usersession/userd: add "slack" to the white list of URL schemes handled by xdg-open - 2.45 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8800>
<jdstrand> pstolowski: absolutely yes. I was thinking I needed to backport shellcheck from focal, but then when you said it was supposed to work everywhere, I stopped
<jdstrand> mvo: ok, sorry to keep pinging you. as mentioned, I deconflicted PR 8398. The submitter signed the cla (see my PR comment) but cla-check is still failing. so I milestoned that to 2.46 and then created PR 8800 for 2.45 with 'Original-Author: troyready <troy@troyready.com>'
<mup> PR #8398: usersession/userd: add "slack" to the white list of URL schemes handled by xdg-open <Created by troyready> <https://github.com/snapcore/snapd/pull/8398>
<mup> PR #8800: usersession/userd: add "slack" to the white list of URL schemes handled by xdg-open - 2.45 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8800>
<jdstrand> mvo: but it failed with: 'troy@troyready.com (https://api.launchpad.net/1.0/~troyready) has NOT signed the CLA'
<pstolowski> jdstrand: ok, good; so for clarity, we only care about latest shellcheck
<jdstrand> mvo: oh, actually, I see troyready signed the code of conduct, I don't know about the cla, but he has a screenshot in the original PR
<jdstrand> mvo: so, yeah, I'll defer to you on how to proceed
<jdstrand> pstolowski: yep, understood
<zyga> gah, another sudden power off
<mvo> xnox: I pushed 8801 with the bolt update
<mvo> jdstrand: thanks, I have a look why the cla is acting up, it's unfortunately a constant hassle :(
<mup> PR snapd#8801 opened: vendor: update to latest github.com/snapcore/bolt for riscv64 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8801>
<jdstrand> mvo: :\
 * cachio afk
<zyga> cmatsuoka: when would be a good time to update spread?
<zyga> do you need the new master deployed?
<cmatsuoka> zyga: let me update the yaml and prepare a PR to update the secure-boot attribute
<zyga> cmatsuoka: I think we should burn through the current queue first
<zyga> cmatsuoka: can we agree on a a time, perhaps tonight when europe stops working
<cmatsuoka> zyga: sounds good, I'll leave the PR ready and then we can switch at any convenient time
<zyga> ok
<cmatsuoka> zyga: https://github.com/snapcore/snapd/pull/8802
<mup> PR #8802: spread.yaml: update secure boot attribute name <Simple ð> <Skip spread> <â Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8802>
<zyga> hmm perhaps skip spread is undesired :)
<zyga> but I think we can close and reopen without it
<zyga> that's fine, I'll do this late at night when there is less activity
<mup> PR snapd#8802 opened: spread.yaml: update secure boot attribute name <Simple ð> <Skip spread> <â Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8802>
<cmatsuoka> zyga: it will fail with the current spread, but we can remove the skip tag after spread is updated
<zyga> ok
<zyga> yeah, we learned that the tags tend to stick though :)
<zyga> that's fine
<zyga> we can use the close / open trick
<cmatsuoka> oh really? well ok then
 * zyga breaks for some time to just rest and avoid pain 
<zyga> yeah, we noticed when the tag was first used in actions but perhaps this was not common knowledge in the team yet
<cmatsuoka> if everything else fails we can close it and open another PR :)
<zyga> or run it manually and land :)
<pstolowski> cachio: could you take a look at the new spread test in https://github.com/snapcore/snapd/pull/8780  ?
<mup> PR #8780: tests: core20 early defaults spread test <Created by stolowski> <https://github.com/snapcore/snapd/pull/8780>
<mup> PR snapcraft#3154 opened: cmake v2 plugin: take source-subdir into account <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3154>
<pedronis> ijohnson: you froze for me
<ijohnson> yes rejoingin one moemnt sorry
 * cjp256 laughed at`Download snap "snapcraft" (4852) from channel "latest/edge"  0%  0B/s ages!` 
<cjp256> Specifically at the 'ages!', not the fact it's not downloading anything :)
<mup> PR snapd#8803 opened: tests: port interfaces-many-core-provided to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8803>
<cachio> pstolowski, sorry, I was with the doctor
<cachio> pstolowski, I'll check it now
<cmatsuoka> cjp256: at 0B/s it should really be never, not ages
<pstolowski> cjp256: haha, i've never seen this; interestingly i've just checked, and we have a TODO there saying "// TODO: figure out exactly what overflow causes the ==0"
<cjp256> cmatsuoka: I think it is being optimistic ;)
<cjp256> hah
<pstolowski> yeah, it wants to give hope
<cachio> pstolowski, review done
<cachio> just minor changes required.
<pstolowski> cachio: thanks!
<cachio> pstolowski, yaw
<zyga> the day of constant pain is not a good day
<zyga> hrm
<zyga> I have a patch I cannot find
<zyga> where did I put it
<mup> PR snapd#8804 opened: tests: port xdg-settings test to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8804>
<zyga> I'll make some coffee and get painkillers
<zyga> and then do one more PR
<zyga> and maybe help drain the queue by running more workers
<zyga> afk
<zyga> re
<pstolowski> cachio: hey, re your comment for " 2 functions: 1 for unsign and 1 for sign "
<pstolowski> cachio: do you think just one function that does sbattach --remove & sbsign would be ok? i'm not sure we need more granularity
<cachio> pstolowski, yes
<pstolowski> ok
<cachio> the idea is to have that as a function so the tests are more easy to read / understand
<cachio> in the future
<cachio> thanks
<zyga> https://github.com/snapcore/snapd/pull/8805 is the last one :)
<mup> PR #8805: tests: port interfaces-calendar-service to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8805>
<mup> PR snapd#8805 opened: tests: port interfaces-calendar-service to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8805>
<zyga> please look at the two "test robustness" PRs
<zyga> no more leaking dbus
<om26er> Is there a place to track progress of UbuntuCore 20, its "what's new" and an expected timeline for its release ?
<zyga> om26er: good question
<zyga> om26er: it's a bit hazy, apart from what's in the PRs that are landing
<zyga> om26er: I heard that beta is coming soon but there are still some TODOs in the code
<om26er> maybe there is a public kanban I could look at ?
<zyga> nope
<zyga> I wish we used github projects for the public side but that didn't go far
<zyga> you can expect ongoing releases to broaden core20 support
<mup> PR snapd#8806 opened: tests: install/run the lzo test snap too <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8806>
 * cachio -> app with doctor part 2
<pstolowski> cachio: updated #8780
<mup> PR #8780: tests: core20 early defaults spread test <Created by stolowski> <https://github.com/snapcore/snapd/pull/8780>
<zyga> hmm
<zyga> I will fight the pain and go and turn on some extra workers
<zyga> this queue is not shrinking fast enough
<cmatsuoka> hmm, tests stalled again
<zyga> sorry, I was not able to go down
<zyga> back hurts badly and affects leg
<cmatsuoka> ah ugh, yeah, don't do anything that could make it worse
<mup> PR snapcraft#3155 opened: storeapi: specify Content-Type for icon <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3155>
<mup> PR snapcraft#3156 opened: log: trace HTTP connections with developer debug <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3156>
<cachio> zyga, any idea why jobs for #8790 are queued?
<mup> PR #8790: tests: update the file used to detect the boot path on uc20 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8790>
<zyga> because we are burning through this backlog: https://github.com/snapcore/snapd/actions?query=is%3Aqueued
<cachio> zyga, I see
<jdstrand> degville (cc emitorino): hi! is https://github.com/snapcore/snapd/wiki/REST-API the right place to look at the rest api of /run/snapd.socket? I expected something more like https://api.snapcraft.io/docs/info.html but for snapd's socket (also, what about a similar page for snapctl?)
<degville> jdstrand: unfortunately, yes, right now. Moving it to somewhere more appropriate is on our immediate to do list, and we're meeting this week to discuss it.
<degville> And of course updating it and the process to keep it updated.
<jdstrand> degville: oh, heh. nice. AIUI, the snapctl api could probably live on the same page since it will largely be a subset of the snapd api
<emitorino> ack jdstrand
<jdstrand> degville: but emitorino and I were talking about how there is a lack of documentation on the security properties of /run/snapd.socket (snap) vs /run/snapd-snap.socket (snapctl), so perhaps some verbiage on that could be included? 2 cents
<jdstrand> degville: thanks for all your doc work btw :)
<degville> jdstrand / emitorino: yes, definitely. after we've sorted its location and how we'll keep it updated, maybe i could ping you for your thoughts. Also, thanks for the snapctl api (oh, thanks :) still lots to do!)
<jdstrand> degville: perhaps add userd's DBus API to the list as well (along with its security properties, if it makes sense there)? (sorry, that is the last one I had in my mind)
<jdstrand> degville: and yes, emitorino and I would be happy to chat about the security aspects whenever it makes sense for you
<degville> jdstrand: ok. Thank you!
<zyga> I managed to get downstaris and I lit up 32 more nodes
<zyga> we should eat the rest of the queue quickly now
<cachio> zyga, awesome, thaks a lot
<cmatsuoka> zyga: thanks, but be careful, the impact will be much larger if you get worse
<zyga> cmatsuoka: thank you, I really want to get better
 * cmatsuoka just ordered a new NAS
<zyga> neat :)
<zyga> degville: I bought SC-D70 earlier today
<zyga> cmatsuoka: I joined the midi party
<cmatsuoka> zyga: oh haha, what did you get there?
<zyga> cmatsuoka: a vintage roland midi module
<cmatsuoka> the canvas? or mt?
<zyga> the canvas
<zyga> canvas D70
<cmatsuoka> oh nice!
<zyga> it's the most modern of the pack
<cmatsuoka> haha, that's great
<zyga> and does a bit more than the older guys
<degville> zyga: awesome!
<zyga> all the workers are lit up but they are not receiving jobs from github
<cmatsuoka> humm, that's odd
<mup> PR snapd#8807 opened: Revert "Enable riscv64 builds in the edge PPA without PIE" <Created by xnox> <https://github.com/snapcore/snapd/pull/8807>
<mup> PR snapd#8808 opened: riscv64: bump timeouts <Created by xnox> <https://github.com/snapcore/snapd/pull/8808>
#snappy 2020-06-04
<mborzecki> morning
<zyga> o/
<mup> PR snapd#8809 opened: tests: fix and trim debug section in xdg-open-portal <Simple ð> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8809>
<zyga> some weird failures related to snap-mgmt script
<zyga> chasing one now
<mup> PR snapd#8799 closed: interfaces/system-packages-doc: fix typo in variable names <Simple ð> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8799>
<mup> PR snapd#8805 closed: tests: port interfaces-calendar-service to tests.session <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8805>
<mup> PR snapd#8806 closed: tests: install/run the lzo test snap too <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8806>
<zyga> hey mvo
<zyga> mvo: note: please don't merge the retry PR as it needs updates now
<mborzecki> zyga: mvo: hey
<mvo> zyga: hey
<mvo> zyga: can you mark it blocked please?
<mvo> mborzecki: good morning
<zyga> ok
<mup> PR snapd#8792 closed: interfaces: miscellanious policy updates xlv <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8792>
<mup> PR snapd#8793 closed: interfaces: miscellanious policy updates xlv - 2.45 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8793>
<mborzecki> wow, 74 PRs, it was lower 60s yesterday
<mup> PR snapd#8788 closed: cmd/snap-confine: add support for libc6-lse <Bug> <Needs security review> <Squash-merge> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8788>
<mup> PR snapd#8801 closed: vendor: update to latest github.com/snapcore/bolt for riscv64 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8801>
<zyga> + snap install --channel=edge core20
<zyga> error: too early for operation, device not yet seeded or device model not acknowledged
<zyga> this is from https://github.com/snapcore/snapd/pull/8798/checks?check_run_id=734681152
<mup> PR #8798: data/selinux: allow checking /var/cache/app-info <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8798>
<zyga> missing wait in our code somewhere?
<mvo> mborzecki: 8798 has some failures in centos, looks like related to the diff?
<mborzecki> zyga: yes, apaprently the centos 7 policy is quite old
<mborzecki> well entirely unexpected, but it's missing the interface, hope it has the right types at least
<mup> PR snapd#8778 closed: tests: modernize and use snapd.tool <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8778>
<mborzecki> zyga: heh, so there's something about optional_policy() i don't understand, maybe #fedora-selinux folks can help
<pedronis> zyga: hi, you could also add a retry-tool symlink to 8796 with no spread and land it, and do another one to fix the other tests and remove the symlink later
<zyga> pedronis: good idea, I'll do that
<ogra> hmm, it is really hard to get the available disk space from a snap on core ... seems /writable is nowhere to be seen from inside the snap
<ogra> and the size of /var/lib/snapd/hostfs is the size of / ... which is the core snap
<zyga> ogra: I replied to something similar from a customer before, one simple way is to check the size of $SNAP_DATA and $SNAP_USER_DATA
<zyga> as in statfs
<ogra> oh, i actually remember that discussion, hah
<ogra> thanks !!
<ogra> root@pi4ðhome/ogra# df -h $SNAP_DATA
<ogra> Filesystem      Size  Used Avail Use% Mounted on
<ogra> /dev/sda1       458G   68G  367G  16% /var/snap
<ogra> yeah, that works fine
<ogra> (looks like hexchats emoji pligun needs fixing too ...)
<ogra> *plugin
<zyga> hmmm
<zyga> curious failures
<zyga> https://www.irccloud.com/pastebin/WxFz0F8w/
<zyga> I've seen this many times today
<zyga> must be something recently introduced
<zyga> hmm hmm h
<pedronis> would be good to know what is in there that makes it non-empty
<pedronis> it would give us a clue
<pedronis> what system is that on?
<mborzecki> didn't we have a find/ls -l /var/lib/snapd/ in the spread.yaml level debug section?
<pedronis> not atm afaict
<zyga> pedronis: it seems it was one of the first things this test did
<zyga> it was still preparing the suite
<zyga> I'll add a debug section to this
<zyga> back from random power failure on x240 :(
<zyga> I tried reproducing it with seed but failed twice
<zyga> so it may not be test related but another kind of race that is just inside the system
<zyga> .... and I know that holding my x240 close to the right side of the hinge shuts it down instantly
<zyga> some cable is getting pinched?
<zyga> not the best moment for this
<mup> PR snapd#8809 closed: tests: fix and trim debug section in xdg-open-portal <Simple ð> <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8809>
<mup> PR snapd#8810 opened: spread.yaml: show /var/lib/snapd in debug <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8810>
<zyga> no luck reproducing locally, I opened a PR to see if that has more luck
<zyga> huh
<zyga> we're not lucky today
<zyga> check out this *unit test* failure
<zyga> FAIL: cmd_export_key_test.go:60: SnapKeysSuite.TestExportKeyAccount
<zyga> cmd_export_key_test.go:65:
<zyga>     c.Assert(err, IsNil)
<zyga> ... value *errors.errorString = &errors.errorString{s:"/usr/bin/gpg2 --batch --list-secret-keys --fingerprint --with-colons --fixed-list-mode failed: exit status 2 (\"gpg: starting migration from earlier GnuPG versions\\ngpg: can't connect to the agent: IPC connect call failed\\ngpg: error: GnuPG agent unusable. Please check that a GnuPG agent can be started.\\ngpg: migration aborted\\n\")"} ("/usr/bin/gpg2 --batch
<zyga> --list-secret-keys --fingerprint --with-colons --fixed-list-mode failed: exit status 2 (\"gpg: starting migration from earlier GnuPG versions\\ngpg: can't connect to the agent: IPC connect call failed\\ngpg: error: GnuPG agent unusable. Please check that a GnuPG agent can be started.\\ngpg: migration aborted\\n\")")
<zyga> perhaps we should do something about ~/.gnupg in github actions startup
<zyga> or perhaps we should mock gpg entirely and only test it in spread tests
<zyga> mvo, pedronis: ^ any preference?
<mvo> zyga: in a meeting
<mup> PR snapd#8796 closed: tests: modernize retry tool <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8796>
<zyga> hmmm
<zyga> "too early for operation" *after* waiting for seeding https://www.irccloud.com/pastebin/faUH8YSh/
<pedronis> zyga: don't we have code to make sure we shutdown the agent?
<zyga> pedronis: this is during the go test ./... phase in github action itself, not in spread
<zyga> pedronis: it seems the image we are running on top of, needs to perform the migration
<zyga> (2nd topic: this failure occurred in prepare.sh:664
<zyga> which is weird, because there's clearly a "snap wait system seed.loaded" above
<pedronis> zyga: I see, sounds like we need to wait for something gpg related then in the action. I think we have code in the spread stuff related to that
<zyga> pedronis: I'll look around
<zyga> pedronis: the wait thing is more mysterious, it suggests there's a bug in snapd
<pedronis> pstolowski: seems there's a real unit test error on 14.04 in core 20 defaults PR
<pstolowski> pedronis: looking
<pstolowski> hmm interesting
<pstolowski> will investigate in a sec
<mup> PR snapd#8795 closed: cmd/snap-bootstrap/initramfs-mounts: also copy systemd clock + netplan files <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8795>
<mup> PR snapd#8797 closed: snap/naming: add helpers to parse app and hook security tags <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8797>
<mup> PR snapd#8807 closed: Revert "Enable riscv64 builds in the edge PPA without PIE" <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8807>
<zyga> thanks mvo!
<zyga> I will have more cgroup patches shortly
<zyga> pstolowski: the preseed-lxd test has a small bug, I'll send a patch shortly
<mborzecki> ehh, selinux is so arcane
<pstolowski> zyga: thanks
<mborzecki> 2h+ of fighting with selinux policy, optional_policy(), ifndef(), m4 and make
<mborzecki> #8798 is a trivial fix but making it work on all distros we built it on, with the limitations of how kernel policy files are compiles is a pita
<mup> PR #8798: data/selinux: allow checking /var/cache/app-info <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8798>
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8811
<mup> PR #8811: tests: autoremove after removing lxd in preseed-lxd test <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8811>
 * zyga break, need to try to move a little 
<pstolowski> zyga: thank you! i think i saw this once when working on this test and running entire testsuite, then it couldn't reproduce
<mup> PR snapd#8811 opened: tests: autoremove after removing lxd in preseed-lxd test <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8811>
<pstolowski> pedronis: pushed a fix to #8567, it was missing mocking for systemctl
<mup> PR #8567: o/devicestate: core20 early config from gadget defaults <UC20> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8567>
<mborzecki> so what's the policy of adding snaps under tests/lib/snaps vs under the test directory?
<mborzecki> there's test-snapd-sh in tests/lib/snaps and another one under tests/main/interfaces-appstream-metadata
<mborzecki> oh and there's one in the store too
<zyga> mborzecki: IIRC the current preference is to not share snaps if they are really specific to a test
<zyga> you can create a shared snap if you think it makes sense to do so
<zyga> sharing snaps is problematic because we had a pattern of sharing and then changing the snap
<zyga> that had unexpected consequences
<zyga> I have a feeling we could unshare an number of snaps
<zyga> and then be left with a small pool of really shared snaps
<zyga> that have well defined semantics
<pedronis> likely yes, but probably not a good time for that change, we don't have even a good story how we mantain those snaps
<zyga> interesting, there's also a subset that is in the store
<zyga> that are there for assertions
<zyga> yeah, it's a bit messy, my recommendation is not to make it worse :)
<zyga> mvo: question on https://github.com/snapcore/snapd/pull/8804#discussion_r435155159
<mup> PR #8804: tests: port xdg-settings test to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8804>
<mvo> zyga: replied
<mup> PR snapd#8785 closed: sandbox/cgroup: move FreezerCgroupDir from dirs.go <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8785>
<mup> PR snapd#8790 closed: tests: update the file used to detect the boot path on uc20 <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8790>
<mup> PR snapd#8810 closed: spread.yaml: show /var/lib/snapd in debug <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8810>
<zyga> thanks!
<zyga> please alert me if tests fail on dpkg
<zyga> we might find out what was there now
<mborzecki> heh, shellcheck complains about tests/main/lxd https://paste.ubuntu.com/p/6pzGfwKC2n/
<mborzecki> mvo: zyga: i've updated https://github.com/snapcore/snapd/pull/8798 since you reviewed it before, please take another look
<mup> PR #8798: data/selinux: allow checking /var/cache/app-info <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8798>
<zyga> sure
<mvo> ta
<mborzecki> it'd still be nice to get it into 2.45.1
<mborzecki> ok, back to review
<zyga> mborzecki: do you need the optional_policy now that you have the ifdef?
<mborzecki> zyga: in theory it's nth
<zyga> ?
<mborzecki> nice to have, i should probably take a look at other interface uses and wrap them as well
<zyga> mborzecki: what is the rename? github truncates things
<zyga> ah, I see it in a tooltip
<mborzecki> test-snapd-sh -> test-snapd-appstream-metadata
<zyga> Could you update the snap to have less apps and the "sh" app actually holds the interface you want
<zyga> otherwise it's a bit weird
<zyga> or is it the only app there?
<zyga> it's kind of verbose for no good reason saying the same thing twice
<mborzecki> like test-snapd-apptream-metadata.sh?
<zyga> yeah
<zyga> personal preference, if you like it
<zyga> ok, I need to take a break
<zyga> try to move around a little
<mborzecki> Eighth_Doctor: about the label https://paste.ubuntu.com/p/ZyzpPrZDHx/ unless it's owned by multiple packages, but not sure to make rpm query to show that
<zyga> next up more cgroup branches
<zyga> please remember to merge master and report test failures
<Eighth_Doctor> mborzecki: rpm -qf /var/cache/app-info
<zyga> if claudio asks: I did *not* deploy spread upgrade yet, because we had a backlog of tests to run through and I wanted to avoid interruptions, since everything is back to normal now I will do it tonight
<Eighth_Doctor> offhand, appstream and PackageKit own that too
<mborzecki> Eighth_Doctor: it shown only packagekit,
<Eighth_Doctor> and actually... fwupd does not own that directory
<Eighth_Doctor> ugh
<Eighth_Doctor> I love SELinux, but god damn it
<mborzecki> hahah
<zyga> heheh
<zyga> some humor in grim days
 * zyga afk
<mborzecki> Eighth_Doctor: feels like there should be a separate label, appstream_cache_t or somesuch
<Eighth_Doctor> yes
<mborzecki> Eighth_Doctor: also, the file contexts are defined in fwupd policy module :P
<Eighth_Doctor> GAAH
<Eighth_Doctor> that's definitely a bug
<Eighth_Doctor> the label is wrong, and the ownership is broken
<mborzecki> Eighth_Doctor: filed https://bugzilla.redhat.com/show_bug.cgi?id=1843881
<mborzecki> Eighth_Doctor: notice how /var/cache/fwupd inherits var_t :P
<Eighth_Doctor> ð¤¦ââï¸
<mup> PR snapd#8591 closed: secboot,cmd/snap-bootstrap: add tpm sealing support to secboot <Needs Samuele review> <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8591>
<mup> PR snapd#8812 opened: o/snapstate: service-control task handler (4/N) <Needs Samuele review> <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8812>
<mborzecki> yay sealing landed
<mborzecki> wonder it'd be possible to chop #8340 into smaller bits
<mup> PR #8340: boot, snap-bootstrap: move initramfs-mounts logic to boot pkg <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8340>
<mup> PR snapd#8813 opened: gadget,cmd/snap-bootstrap: move partitioning to gadget <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8813>
<mup> PR snapd#8811 closed: tests: autoremove after removing lxd in preseed-lxd test <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8811>
<zyga> I'm seeing some network woes in gce
<zyga> both on snap install/download and apt install
<zyga> - Download snap "test-snapd-dbus-provider" (6) from channel "beta" (Get https://canonical-bos01.cdn.snapcraft.io/download-origin/canonical-lgw01/vnDT8UYR44P8qyBwRSiXHHCoaoq9pz9z_6.snap?token=1591286400_c8896515d76222f533efc97384292fa6e4826cc6: dial tcp 91.189.91.42:443: connect: connection timed out)
<zyga> reported internally
<zyga> interactively I cannot install any snap from the store, from GCE
<zyga> https://github.com/snapcore/snapd/pull/7825/files is now at sub 2K additions,
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Needs security review> <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> I will trim it some more soon
<clmsy> hi everyone
<clmsy> i just build the core16 image use to flash some devices for test purposes
<clmsy> but something is wrong
<clmsy> snap list returns an empty list
<clmsy> under /var/lib/snapd/seed/snaps/  all snaps are here but they are not installed
<clmsy> snap warnings say that seeding failed with assertion is signed with expired public key
<clmsy> it says go here check it out https://forum.snapcraft.io/t/incorrect-seed-yaml-for-some-system/16341
<clmsy> the mv command tells me to move the whole folder that includes snaps as well
<clmsy> this does not make that much sense to me
<clmsy> does the topic owner meant move the seed.yaml file or something
<zyga> clmsy: that topic was about a bug in some seeds that were produced in development releases
<zyga> how are you building your uc16 image?
<zyga> the instructions there are correct
<zyga> I think we need to understand what is wrong in your case
<clmsy> i have a kernel snap and a gadget snap based on core16 and i bundle them together with ubuntu-image tool
<clmsy> i can confirm this has worked multiple times before
<clmsy> but today i get this message:
<clmsy> "no matching public key "BWDE***********redacted" for signature by "canonical"
<zyga> hmmm
<zyga> is the key in the image?
<zyga> not sure, maybe some new bug
<clmsy> if i try to do snap install something it says  "too early for operation, device not yet seeded or device model not acknowledged"
<clmsy> hm
<ogra> clock off ?
<ogra> (does the device have an RTC ? does that have the correct time )
<clmsy> maybe its time related let me double check that
<ogra> expired key is pretty typical if your clock is completely off
<zyga> heh
<zyga> it's ironic that the message says
<zyga> "too early for operation"
<zyga> :D
 * zyga small break
<ogra> hmpf ... that store outage isnt nice ... (my PRs fail with download errors in travis)
 * ogra considers a break too
<clmsy> haha
<clmsy> anyway yes you are correct
<clmsy> it was clock related issue
<clmsy> was a very new device i did not expect the date to be in 2016
<clmsy> apologies
<clmsy> ..
<ogra> heh, no problem ð
<ogra> (i have run into that 1000s of times already ... though usually only on RTC-less devices)
<clmsy> same to be honest, sometimes we forget the "time" :)
<cachio> mvo_, hey, in 2.45.1 is included the support for core.experimental.user-daemons right?
<cachio> because it is affecting the tests for uc20
<zyga> ogra, clmsy: https://github.com/snapcore/snapd/pull/8814
<mup> PR #8814: sanity: check for unsynchronized real time clock <Created by zyga> <https://github.com/snapcore/snapd/pull/8814>
<clmsy> <3
<ijohnson> hey zyga and mborzecki do you have any suggestions on how to get the machine arch on non-debian machines i.e. fedora/arch and map those to our snap arch values ?
<ijohnson> I was using dpkg --print-architecture, but obvs that won't work on non-debian distros
<mup> PR snapd#8814 opened: sanity: check for unsynchronized real time clock <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/8814>
<zyga> ijohnson: fedora uses kernel names IIRC
<zyga> ijohnson: uname -m
<ijohnson> zyga: you mean just `uname -m` ?
<ijohnson> right
<zyga> ijohnson: would use that
<zyga> you can map from that to debian arch names relatively easily
<zyga> at least, it's a bound problem
<ijohnson> zyga: ok that's what I was thinking of doing
<ijohnson> zyga: do you have or know where I could find such a mapping?
<zyga> I *think* we have a few implementations of that in the gree
<zyga> yes :)
<zyga> one sec
<ijohnson> thank you
<zyga> it's a cool find from last few weeks
<zyga> it's right on your system in...
<zyga> two files: /usr/share/perl5/Dpkg/Arch.pm and /usr/share/dpkg/cputable
<zyga> the former has some more logic
<zyga> the latter is a map that will have most instant answers
<zyga> good luck :)
<mborzecki> hm aren't we mapping that already somewhere?
<zyga> pedronis: I think it would help if a blocked label had an accompanying comment
<mborzecki> ijohnson: some comments in https://github.com/snapcore/snapd/pull/8340 i think we need a diagram or something to capture the whole of bootloader/initramfs/userspace snapd interaction
<mup> PR #8340: boot, snap-bootstrap: move initramfs-mounts logic to boot pkg <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8340>
<ijohnson> mborzecki: sure I can try to break it up and clarify the interaction between the interactions
<pedronis> zyga: my hunch is that is not great idea as is, but I don't have time to think it through or formulate it right now, I don't want it to land it why I'm not paying attention
<pedronis> s/why/while/
<mborzecki> ijohnson: i mean not for this PR, but in general, maybe when we're done with the refactor
<zyga> pedronis: sure, that's fine, making such comment on the page can help when others come and look
<mup> PR snapd#8567 closed: o/devicestate: core20 early config from gadget defaults <UC20> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8567>
<pedronis> pstolowski: ^ great!
<pstolowski> yes..
<pstolowski> ijohnson: hey, do you have a moment for another look at #8780?
<mup> PR #8780: tests: core20 early defaults spread test <Created by stolowski> <https://github.com/snapcore/snapd/pull/8780>
<ijohnson> pstolowski: I will try to look at it in my PM today
<pstolowski> thanks!
<zyga> mvo_: bump about https://github.com/snapcore/snapd/pull/8352 -- should I close it or do you see it as something useful and worth rebasing?
<mup> PR #8352: wrappers: generate service files with EnsureDirState [WIP] <Created by zyga> <https://github.com/snapcore/snapd/pull/8352>
 * zyga EODs and goes to the doctor 
<mup> PR snapd#8352 closed: wrappers: generate service files with EnsureDirState [WIP] <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8352>
 * cachio lunch
<zyga> back from doc
<zyga> but afk due to pain
<ogra> un 04 17:00:34 pi4 kernel: audit: type=1400 audit(1591290034.897:477ð apparmor="DENIED" operation="capable" profile="/snap/snapd/7779/usr/lib/snapd/snap-confine" pid=4626 comm="snap-confine" capability=4  capname="fsetid"
<ogra> hmm
<ogra> thats new on my pi4 ... (freshly booted)
<jdstrand> ogra: it isn't a new thing. it was reintroduced with snap-confine refactor
<jdstrand> ogra: it is harmless but on my list to investigate
<ogra> ok, i just had never noticed it ... and it shows up along with only two (expected) app denials ... that got my attention
<jdstrand> well, it might be new in 2.45, but I've been seeing it for a while (we used to have it and I fixed it, but then some snap-confine changes (ie, the removal of setgid stuff) added it back
<jdstrand> ogra: yes, thanks for bringing it up :)
<ogra> the magic word was "harmless" ð
<ogra> i'll appily ignore it
<diddledan> "mostly harmless"
<mup> PR snapd#8815 opened: tests: port snap-handle-link test to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8815>
<mup> PR snapd#8816 opened: tests: port 2 uc20 part1 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8816>
#snappy 2020-06-05
<mup> PR snapcraft#3157 opened: spread: use absolute path to lxd <tooling> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3157>
<mup> PR snapd#8817 opened: tests: new test to validate refresh and revert of kernel and gadget on uc20 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8817>
<mborzecki> morning
<zyga> Hey
<mborzecki> zyga: hey hey
<mvo> hey mborzecki and zyga
<pstolowski> morning
<zyga> hey, I just had to do something weird to log in
<zyga> can you guys please check if you are a member of group "video"
<zyga> and if /dev/dri/card0 is group-owned by that file
<zyga> er
<zyga> group
<zyga> I had to add myself to the video group
<zyga> as otherwise gdm would fail to start the session for my account
<mvo> zyga: I'm not in video
<mvo> zyga: on 20.04
<zyga> thanks
<zyga> hmm (I'm on 20.10)
<zyga> what's the ownership of /dev/dri/card0?
<mvo> zyga: root:video
<zyga> thanks
<zyga> I talked in #ubuntu-devel a little and normally logind would grant extra permissions to my account
<zyga> so something on that line is broken
<zyga> oh well, the fun of running devel :)
<zyga> thank you for checking
<zyga> I will finish coffee and jump into PRs
<mborzecki> zyga: funny, i'm in video group
<mborzecki> wonder what happens when i drop that
<mborzecki> zyga: do you have any other ideas about https://forum.snapcraft.io/t/notification-on-reboot-initiation-or-coming-up-from-reboot/18005 ?
<zyga> looking
<zyga> mborzecki: /tmp as seen by a snap is not discarded on refresh
<mborzecki> zyga: ha, so maybe that could be used then
<mborzecki> anyways, this feels like thin ice
<ackk> hi, how do I get a snap out of --devmode without reinstalling?
<zyga> mborzecki: yeah, I replied
<zyga> ackk: hmmm good question
<mborzecki> zyga: thanks!
<zyga> I think there's no way actually, maybe refresh --strict but I don't remember if we forward that
<pedronis> ackk: maybe snap revert --revision but not sure
<pstolowski> pedronis: hey, wdyt about mechanical splitting of snapstate_test.go by "topics", e.g. snapstate_install_test.go, snapstate_update_test.go, snapstate_try_test.go etc? no new test suites to be clear. it's 16K+ lines, very hard to navigate :(
 * ackk tries
<ackk> --strict is not accepted by refresh
<ackk> revert also doesn't seem to work if you try to revert to the same revision
<pedronis> pstolowski: it's a good idea, but we would need to think a bit how to tackle it
<pstolowski> pedronis: how about if i propose just a few obvious ones? do you have particular concern in mind?
<pedronis> pstolowski: mostly conflict for wip work
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/8722#issuecomment-639319127 heh a bit unexpected
<mup> PR #8722: tests: check that host settings like hostname are settable on core <Created by mvo5> <https://github.com/snapcore/snapd/pull/8722>
<pedronis> also there might be some corner cases where is not clear but maybe that isn't true
<mvo> pedronis: I updated the netplan thing
<mvo> mborzecki: oh, woah, unexpected indeed!
<pstolowski> pedronis: yes, would be good to avoid conflicts with wip. and i suppose we will have some tests that cross many boundaries, in which case they fall into a "generic" category, i.e. snapstate_test.go
<zyga> mborzecki: updated https://github.com/snapcore/snapd/pull/8815
<mup> PR #8815: tests: port snap-handle-link test to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8815>
<pedronis> pstolowski: I would start with snapstate_install_test.go I suppose ?
<pedronis> that would be tests that involve mainly snapstate.Install and snapstate.InstallPath
<pedronis> I suppose
<pstolowski> pedronis: yes,  that's a good candidate
<pedronis> notice though sometimes they are used to setup conflicts for other things, but hopefully the test name/content makes that clear
<ackk> zyga, pedronis so I guess the only way to get out of devmode is to wait for an update and then refresh without devmode, right?
<pedronis> seems so, though is a legitimate request (not super high prio) to have a local way
<zyga> perhaps snap switch could grow an option
<pedronis> mabye but switch never unlink/link atm
<pedronis> and this would need to
<pedronis> or some subset of that
<zyga> mmmm
<zyga> why would we have to unlink?
<pedronis> well, it would need to stop all services for example
<pedronis> it's refresh like in some ways
<zyga> yeah, stop, flip flags,  setup security, start
<pedronis> just saying it's not super clear that switch is a good syntax for it
<zyga> ackk: I think filing a bug and letting us eventually get to it is the way forward
<ackk> zyga, ok, thanks
<pedronis> given how it works, I actually switch would probably just change the flag for the next refresh
<pedronis> *actually think
<zyga> pedronis: ideed, you are right
<pedronis> that would break some invariants though, so not sure we can add it to switch
<pedronis> anyway some form of revert or refresh would do
 * zyga afk for a moment, I'll try to move to the office today
<zyga> maybe no
<zyga> I cannot stand for a while even
<zyga> mvo: updated https://github.com/snapcore/snapd/pull/8804
<mup> PR #8804: tests: port xdg-settings test to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8804>
<ackk> zyga, filed https://bugs.launchpad.net/snapd/+bug/1882214
<mup> Bug #1882214: No way to move out of devmode without updates or reinstall <snapd:New> <https://launchpad.net/bugs/1882214>
<zyga> thanks!
<mup> PR snapd#8819 opened: tests: move install tests from snapstate_test.go to snapstate_install_test.go <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8819>
<pstolowski> ^ for obvious reason would be nice to land it soon ;)
<pedronis> pstolowski: verifyInstallTasks should move too?
<pedronis> or is it used for update as well?
<pstolowski> pedronis: it's used by transition and installmany tests
<pstolowski> pedronis: and by gadgetupdate tests
<pedronis> pstolowski: I think I would move it anyway, also move the InstallMany ones
<pedronis> I forgot about them
<pstolowski> okay
<pedronis> of course git diff is weird and looks like you changed things and not just removed them :/
<mborzecki> heh all spread jobs passed, but the travis job failed on osx :P
<pstolowski> pedronis: heh, indeed, complete mess
<zyga> mborzecki: how?
<pedronis> pstolowski: I'm busy now, but I'll try to look at it again immediately after lunch
<zyga> mborzecki: maybe spend a moment to port the macos job over
<mborzecki> zyga: some random bit about osx host not coming up
<zyga> even more reason to do it
<zyga> just add a new job for it and that should be it
<mborzecki> iirc we saw this happen couple of times
<mborzecki> zyga: gh can do osx too?
<zyga> I used this in libzt if that helps: https://github.com/zyga/libzt/blob/master/.github/workflows/build.yml#L18
<zyga> yes :)
<zyga> go is preinstalled IIRC
<zyga> mborzecki: and it's macos for a few years now :)
<zyga> osx was the old name
<pedronis> mborzecki: yes, it has different limits than other jobs, not sure it/how it matters
<pstolowski> pedronis: thanks
<zyga> pedronis: there are no different limits *but* a macos job is like 2 other jobs
<mborzecki> pedronis: zyga: i can try and port it over, should be a quick job
<zyga> but it shold not matter much as our tests are quick and won't use the slots for long
<mborzecki> mvo: can you cherry-pick https://github.com/snapcore/snapd/pull/8798 to 2.45? should apply cleanly
<mup> PR #8798: data/selinux: allow checking /var/cache/app-info <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8798>
<mvo> mborzecki: sure, will do
<mborzecki> mvo: thanks!
<mup> PR snapd#8798 closed: data/selinux: allow checking /var/cache/app-info <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8798>
<zyga> if you encounter a "cancelled" test just restart, sorry my fault
<mvo> mborzecki: meh, 7 commit, I will create a 2.45 branch for this
 * mvo should have marked this squash-merge
<mborzecki> mvo:  i can do that
<mvo> mborzecki: yes please!
<zyga> mvo: I need to show you how to cherry pick ranges
<zyga> it's not a problem really
<mvo> zyga: :)
<mborzecki> zyga: what do you use for that? it's easy for a branch that was not landed, but my usual incantation is not useful when a branch got merged upstream
<mborzecki> (probably because i list commits that are not part of a branch, and once landed that no longer lists anything)
<zyga> mborzecki: look at the branch, get the base and the tip,
<zyga> I did it a few times
<zyga> worked okay
<mup> PR snapd#8820 opened: data/selinux: allow checking /var/cache/app-info (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8820>
<mborzecki> zyga: at the base i use `git log --oneline --decorate HEAD '^<other-branch|rev>'`, but the helpers i use cannot automatically figure out to use the the commit before the merge that included the changes upstream
<mup> Bug #1882221 opened: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221>
<mup> Bug #1882221 changed: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221>
<mup> Bug #1882221 opened: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221>
<zyga> mborzecki: huh
<zyga> https://bugs.launchpad.net/snappy/+bug/1882221 is bad
<mup> Bug #1882221: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221>
<zyga> I need to go afk, I'll look soon
<mborzecki> hmm
<mup> Bug #1882221 changed: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221>
<mup> Bug #1882221 opened: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221>
<mup> Bug #1882221 changed: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221>
<mup> Bug #1882221 opened: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221>
<mup> PR snapd#8821 opened: github: port macOS sanity checks from travis <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8821>
<pstolowski> mborzecki: do you have any fail logs for ^ /
<pstolowski> ?
<pstolowski> i have homebrew locally and can check something out, but don't know yet how it maps to github actions
<zyga> mborzecki: https://formulae.brew.sh/formula/squashfs is the forumla
<zyga> I' -1 on using a 3rd party action
<zyga> especially if it is just "brew install"
<zyga> mborzecki: maybe you need brew install --with-xz --with-zstd
<zyga> pstolowski: ^ can you check
<zyga> I should just install brew I guess
<pstolowski> ah, the question is about how to install manually
<pstolowski> brew install squashfs
<pstolowski> works
<zyga> so that's all we need
<zyga> brew is preinstalled in those images
<zyga> right/
<pstolowski> installs squashfs-4.4
<pstolowski> no args needed
<zyga> pstolowski: maybe check if it has xz and zstd
<zyga> can it unsquash a test .snap
<pstolowski> zyga:  Installing dependencies for squashfs: lz4, lzo and zstd
<pstolowski> no mention of xz
<zyga> maybe xz is preinstalled
<zyga> anyway
<zyga> just check with any snap if you can
<zyga> btw, I just noticed brew works on linux
<zyga> maybe a nice way to build ... snaps
<pstolowski> interesting
<zyga> just bake a custom prefix, something brew can do
<mborzecki> hm looks like you can fix whatever needed there ;)
<pstolowski> zyga: i find brew a must on mac
<mborzecki> hmmm
<mborzecki> w8, why there's no job there?
<mborzecki> does mvo need to enable something?
<zyga> because you called this job cla-check
<zyga> :)
<mvo> hm?
<mborzecki> w8, wat?
<mborzecki> pfff
<zyga> hah
<zyga> look at the PR
<mborzecki> hhahah
<zyga> I commented
<zyga> a sneaky way to pass cla checks;D
<pstolowski> zyga, mborzecki i'll check if ^ works on mac after 1-1
<zyga> https://github.com/snapcore/snapd/actions/runs/125815205
<zyga> it's also wrong
<zyga> IIRC args are []
<zyga> but check the docs please
<zyga> mborzecki: some early opinion on https://github.com/snapcore/snapd/pull/7700 would be great
<mup> PR #7700: cmd/snap: wait while inhibition file is present <Created by zyga> <https://github.com/snapcore/snapd/pull/7700>
<zyga> it's WIP code
<zyga> pedronis: and for you https://github.com/snapcore/snapd/pull/8573 -- equally WIP and super tiny - just to start the conversation
<mup> PR #8573: overlord/snapstate: inhibit startup while unlinked <Created by zyga> <https://github.com/snapcore/snapd/pull/8573>
<zyga> mborzecki: did you see https://github.com/snapcore/snapd/pull/8821/files#r435820550
<mup> PR #8821: github: port macOS sanity checks from travis <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8821>
<zyga> mborzecki: this is what GH says https://github.com/snapcore/snapd/actions/runs/125824530
<mborzecki> zyga: yeah, but i'm not sure what's wrong there, yaml is valid, the entrypoint in the action is basically `brew $*`
<zyga> yeah but that's not the right yaml
<zyga> there's a different way to say that
<zyga> let me find that
<mborzecki> hm maybe it shoudl be under `with:`
<zyga> look at https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions
<zyga> yeah
<zyga> exactly :)
<zyga> I think you can also drop the ""
<zyga> hmm
<zyga> maybe just do that manually
<zyga> I don't know what that action does
<zyga> did you read the code?
<mborzecki> zyga: yeah, it literally calls brew $*
<mborzecki> https://github.com/artemnovichkov/action-homebrew
<zyga> then really just do it yourself
<zyga> less magic
<mborzecki> in the meantime, i'm not sure how https://bugs.launchpad.net/snappy/+bug/1882221 happened
<mup> Bug #1882221: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221>
<ijohnson> zyga: hey o/
<ijohnson> zyga: should snap-seccomp re-exec ?
<zyga> hey ian :)
<mborzecki> ijohnson: snapd should call it from the same location as the snapd binary is running
<ijohnson> mborzecki: but what about for folks that are developing their own profiles
<zyga> IIRC we call it with full path
<ijohnson> i.e. you are hacking on a seccomp / apparmor snapd profile to test things
<mborzecki> ijohnson: what do you mean?
<zyga> jamesh: are you asking about https://bugs.launchpad.net/snappy/+bug/1882221?
<mup> Bug #1882221: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221>
<zyga> er
<zyga> ijohnson: ^
<ijohnson> like locally changing the profile.bin in /usr/lib/snapd/seccomp/snap....src
<ijohnson> and then compiling it
<ijohnson> zyga: yes
<ijohnson> also https://forum.snapcraft.io/t/cannot-parse-seccomp-profile-in-snapd-update/18007/5
<zyga> right
<zyga> so no
<ijohnson> I can reproduce the error here
<mborzecki> ijohnson: they should call whatever version is appropriate i suppose
<zyga> how?
<ijohnson> right but how would they know which version is appropriate ?
<mborzecki> ijohnson: they're already ahcking the profile so i would guess they can figure that out ? :)
<zyga> developing a profile is something like what developers do
<zyga> so minimal requirement is probably awareness of snapd source / build
<ijohnson> zyga: to reproduce, launch a bionic VM/lxd container, then downgrade snapd as a deb to bionic-security, (and ensure all snaps are removed), then try to use snap-seccomp
<zyga> though
<zyga> I'm really curious
<zyga> ah
<zyga> ok
<ijohnson> but snapd re-exec semantics can be quite confusing
<mborzecki> ijohnson: so snap-seccomp from 2.37 then?
<zyga> you answered my question
<ijohnson> mborzecki: yes
<ijohnson> before we supported chown stuff for system-usernames
<zyga> ijohnson: my answer is don't do that I think
<ijohnson> :-(
<mborzecki> hm it might have been built with a different libseccomp version even
<zyga> ijohnson: don't do development on top of really old snapd
<mborzecki> (and probably was)
<ijohnson> zyga: they are not on an old version of snapd
<ijohnson> zyga: they have the core / snapd snap installed and have 2.45
<zyga> 2.37 is old
<ijohnson> but the deb on their system is old
<zyga> that's what I mean
<ijohnson> zyga: but `snap version` says 2.45 ?
<zyga> I think we should move everone over to snapd.snap, then the anwer is really easy
<ijohnson> zyga: so what you're saying is that if folks are developing they need to keep both their normal snapd version up to date AND also keep the deb up to date even though no actual snaps / snapd the daemon are using the deb?
<ijohnson> zyga: tbc, this person's machine only has bionic-security pocket enabled
<ijohnson> zyga: so they won't ever get the deb unless they upgrade out of that pocket
<mborzecki> w8, something is weird i think
<ijohnson> (or we push an update to the bionic-security pocket with a new snapd I suppose)
<ijohnson> I think the user experience here is quite poor
<ijohnson> either snap-seccomp should re-exec or we should have snap-seccomp complain when it is not a matching version to the one that snapd the daemon is using
<mborzecki> ijohnson: hm or no, so snapd is updated to 2.45, snapd and snap rexxec, snapd gnerates the profile that can be complied by snap-seccomp from the snapd/core snap, but it does not imply that the old snap-seccomp from the deb can do that
<ijohnson> mborzecki: yes all the snaps work on their system right now
<ijohnson> mborzecki: but they are developing changes to an interface in snapd
<ijohnson> mborzecki: and the documented best practice to change seccomp is broken
<mborzecki> ijohnson: where's that doc? maybe we need to update it
<ijohnson> mborzecki: but what would you update it to ?
<zyga> to tell people re-exec happens
<mborzecki> ijohnson: use snapd from the ppa/roll out your own & disable reexec
<ijohnson> mborzecki: say "if you have snapd snap use /snap/snapd/current/... if you have core snap use /snap/core/current/... if you have snapd distro pkg, use /usr/lib/snapd/..."
<mborzecki> ijohnson: i mean that's what i do :P
<zyga> and the snap-seccom binary is in /snap/{snapd,core}/current/usr/lib/snapd/snap-seccomp
<ijohnson> but I mean you see how that's a frustrating and confusing user experience
<ijohnson> right?
<mborzecki> ijohnson: it's should probably be look at /proc/<snapd-pid>/exec to find out which snapd binary is runnig, call snap-seccomp from the same location
<mborzecki> (this is what snapd does iirc)
<zyga> IMO that's all a bit too magic
<zyga> I would not do that
<ijohnson> zyga: it's not too magic to you because you've worked on snapd too long :-D
<zyga> I mean, it is too magic
<zyga> the re-exec logic is complex
<zyga> I would not teach people about it
<mborzecki> a snap debug command then?
<ijohnson> right so why shouldn't we just make snap-seccomp do the same magic ?
<zyga> I would rather have them know where the tools come from
<zyga> ijohnson: because not all tools re-exec
<ijohnson> a snap debug command makes sense to me
<zyga> I really would not go overboard with this
<ijohnson> zyga: but why don't all tools re-exec though
<zyga> because it's hard and they cannot for other reasons
<ijohnson> if some things re-exec and some things don't re-exec that is confusing and unexpected
<zyga> snap-update-ns and snap-confine probably never well
<zyga> *will
<zyga> ijohnson: that's just the nature of the beast
<ijohnson> :-(
<zyga> I would argue that re-exec could be a helper tool that is used by everything
<zyga> (that re-execs)
<zyga> not by everything
<zyga> so then this is more visible
<zyga> maybe with maciek's idea to merge snapd and snap
<mborzecki> ijohnson: the reexec thing is a tad complicated imo, it looks at the env, then at the distro, we'd ahve to bake it into each binary
<zyga> snapd is just "snap <debug> snapd"
<zyga> or snap exec-tool snapd
<zyga> or something similar
<mborzecki> snap debug exec-tool ?
<zyga> it's not debug if we'd use it to run snapd :)
<zyga> I would actually call it something else
<zyga> snap exec-tool ...
<zyga> and not reexec or debug
<zyga> it's just a way to run a tool
<zyga> a bit like snapd.tool
<mborzecki> anyways, for starters we cold probably document the 'magic' thing first to make it clear
<zyga> then it could do the right thing
<mborzecki> ijohnson: do you know where the istructions for compiling profiles are?
<zyga> mborzecki: offtopic: https://github.com/snapcore/snapd/pull/8821/checks?check_run_id=741848615
<mup> PR #8821: github: port macOS sanity checks from travis <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8821>
<ijohnson> mborzecki: let me find it it was on docs.ubuntu.com/core somewhere
<mborzecki> ijohnson: the search on docs.snapcraft.io comes up empty
<zyga> I think some environment is not set up right
<zyga> or perhaps something else is wrong
<zyga> look at the import failures
<mborzecki> ijohnson: there's some tips towrads the end of this page https://docs.ubuntu.com/core/en/guides/intro/security
<ijohnson> mborzecki: yes that page
<ijohnson> mborzecki: there's also https://github.com/snapcore/snapd/wiki/snap-confine-Overview
<zyga> 2017
<pstolowski> mborzecki: unsquashfs from homebrew seems to work fine
<mborzecki> ijohnson: cool, we can talk with degville to add something to the tips section in the core docs
<ijohnson> mborzecki: yeah I marked the bug as confirmed and low priority, and added reproducer instructions
<ijohnson> mborzecki: degville: also it would be good to move the snap-confine wiki page to the forum too, doesn't need a doc page, but that is the only place we have the snap-seccomp input format documented and also it should be updated to mention the new system-usernames changes for i.e. `chown -1`
<pedronis> mvo: have we setup the meeting about REST docs?
<degville> ijohnson / mborzecki: yes, I totally agree. I didn't know about that page until I just saw the link.
<degville> pedronis / mvo: not yet.
<zyga> more random failures shows service leaks
<zyga> I see two at least: broken document portal still mounted
<zyga> and a service that sleeps for 3133731337
<zyga> randomly breaking totally unrelated test
<zyga> ok, let's fix those
<mborzecki> degville: a little bit of text with examples you could use for the doc https://paste.ubuntu.com/p/TMHPJwd85W/
<mborzecki> ijohnson: ^^ please take a look too
<degville> mborzecki: that's brilliant, thanks - I'll just push some changes to the core docs and create a new forum post for the seccomp stuff.
<ijohnson> mborzecki: looks good to me
<zyga> degville: there's a second snap-confine doc
<zyga> but it's much more raw
<zyga> though more up-to-date
<mborzecki> pstolowski: thanks for checking, looks like the GOPATH is messed up in the PR though
<degville> zyga: oh, thanks - have you got a link? I'll try to merge the two?
<zyga> sure, one sec
<zyga> https://forum.snapcraft.io/t/snapd-2-36-snap-confine-logic-walkthrough/7843
<zyga> I forgot it is on the forum
<degville> zyga: thank you!
<pstolowski> mborzecki: where do you see that? have you just pushed another chage?
<pstolowski> *change
<mborzecki> pstolowski: yeah, force pushed it
<zyga> mborzecki: we set GOPATH in the other yaml IIRC
 * pstolowski lunch
<sergiusens> zyga: ijohnson cachio hey, asking you as the most knowledgeable spread people, can you tell me what is going on on https://travis-ci.org/github/snapcore/snapcraft/jobs/694864341#L433 ?... started last Monday evening
<zyga> looking
<zyga> stat: cannot stat '/snap/bin/lxd': No such file or directory hmm
<zyga> *hmm*
<zyga> no idea, can you add a debug section that does "snap changes" and "ls -l /snap" - you may also want to hash -r after setting PATH
<sergiusens> zyga: only on core20 and non deterministic
<zyga> ah wait, this is *core* 20
<zyga> no, sorry
<zyga> classic
<zyga> I think I know
<sergiusens> zyga: well, yeah, sorry, 20.04
<zyga> we see it too
<zyga> ubuntu 20.04 only too
<zyga> we get an error from install
<zyga> "not ready for operation yada yada"
<zyga> even though we do an explicit "snap wait system seeded"
<zyga> also random
<zyga> no idea why, but look like a real bug
<zyga> I did not debug it more
<zyga> perhaps escalate to mvo
<sergiusens> zyga: you just did :-)
<sergiusens> this is sort of blocking our releases and we are blocking the multipass release I just heard
<zyga> mvo: ^
 * zyga runs
<sergiusens> lol
<mvo> I heard my name?
<sergiusens> only because it is Friday https://www.youtube.com/watch?v=H9vHwW9_1Oo
<mvo> sergiusens: heh - I can look at the backlog but I need to have lunch (have a meeting soon)
<sergiusens> mvo: so, our issue, which is more prominent since last Monday evening (no single test of ours has passed since then) is that on the 20.04 spread/google images, after we install LXD we get stat: "cannot stat '/snap/bin/lxd': No such file or directory"
<zyga> mvo: we seem to have a bug in seeding on ubuntu 20.04
<mborzecki> zyga: it's green ;)
<mborzecki> https://github.com/snapcore/snapd/pull/8821/checks?check_run_id=742006278
<mup> PR #8821: github: port macOS sanity checks from travis <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8821>
<zyga> we wait for seeding
<mvo> sergiusens: oh? is that reproducible? i.e. can I spread -debug that?
<zyga> then snap install fails on "not ready yet"
<zyga> mvo: it's reproducible on our tree but not frequently
<zyga> I've seen it maybe 5-8 times
<zyga> always ubuntu-20.04-64
<sergiusens> mvo: it is non deterministic, but we setup N instances and one of those always fails
<mvo> zyga: but this "cannot stat /snap/bin/lxd" sounds very different
<ijohnson> mborzecki: does that mean we don't need travis for anything any more ?
<zyga> it'd be super hilarious if it was related to https://github.com/snapcore/snapd/pull/8814
<mup> PR #8814: sanity: check for unsynchronized real time clock <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/8814>
<zyga> mvo: no, it just says lxd did not install
<zyga> mvo: we snap install core in our case
<zyga> or core20 maybe, sorry
<mvo> sergiusens: do you have a log for me ?
<mvo> zyga: shouldn't this error already on the "snap install lxd" then?
<sergiusens> mvo: "spread -debug google:ubuntu-20.04-64:"
<mvo> zyga: maybe I just need to see a log
<zyga> mvo: maybe they don't check
<zyga> we set -e in various helpers
<sergiusens> mvo: https://travis-ci.org/github/snapcore/snapcraft/jobs/694864341#L433
<zyga> but set -e is easily lost
<mborzecki> ijohnson: right, we can dro the extra cla check that runs on travis and were fully vendor locked to gh :)
<ijohnson> \o/
<mvo> zyga, sergiusens ohhh: "snap "lxd" is already installed, see 'snap help refresh'"
<mup> PR snapcraft#3158 opened: spread: add snap watch <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3158>
<mvo> zyga, sergiusens so the snap is installed but maybe not working yet - so this indicates that we are indeed not finished seeding yet and ssh just comes in too quickly
<zyga> ah, interesting
<zyga> mborzecki: reviewed
<mvo> sergiusens: can you try to add "snap wait system seed.loaded" ?
<mvo> sergiusens: to your prepare?
 * mvo really needs to have a lunch now, will read backlog
<ijohnson> does this ubuntu 20.04 image maybe not even have the snapd deb
<ijohnson> and just the snapd snap ?
<sergiusens> mvo: sure
<zyga> ijohnson: ohhh
<zyga> interesting
<zyga> ijohnson: but...
<zyga> how?
<zyga> actually I don't think we can do that
 * ijohnson doesn't know just throwing random guesses over the wall
<zyga> yeah but that might explain things
<cjp256> is the deb required?
<sergiusens> ijohnson: it is the one cachio maintains
<ijohnson> hmm let me look at the spread output again
<cjp256> actually the deb is explicitly installed: https://github.com/snapcore/snapcraft/pull/3158/files#diff-3c11e56e5f7f82b0f352d0fe1851a107R203
<mup> PR snapcraft#3158: spread: add snap watch <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3158>
<zyga> sergiusens: btw, you should look at our actions
<ijohnson> ah nvm
<zyga> they seriously rock
<zyga> way better than travis now
<ijohnson> https://www.irccloud.com/pastebin/Yrvil8sI/
<sergiusens> zyga: I asked ijohnson to document, if there is a place we can run spread without needing to maintain infra I am all for it
<zyga> sergiusens: there is
<zyga> sergiusens: our place :)
<mborzecki> pstolowski: can you do one more pass over https://github.com/snapcore/snapd/pull/8821 ?
<mup> PR #8821: github: port macOS sanity checks from travis <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8821>
<sergiusens> zyga: how do you build Windows binaries though? Or when is the snap command coming to Windows for us to passthrough "snap pack"? :-)
<zyga> sergiusens: you can also use github actions directly without our ifra
<zyga> sergiusens: I don't know, though actions supports both macos and windows
<sergiusens> zyga: we are using actions for release drafter
<zyga> mborzecki: wow and it passed now :)
<zyga> hmm
<zyga> mborzecki: I'm confused
<sergiusens> zyga: in any case, our issue today does not involve Travis at all
<zyga> mborzecki: did you change get-deps?
<zyga> sergiusens: that's true
<zyga> mborzecki: ah, sorry, I misread bits
<zyga> you said "done" https://github.com/snapcore/snapd/pull/8821/files#r435859512
<mup> PR #8821: github: port macOS sanity checks from travis <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8821>
<zyga> but I guess not on the right comment
<zyga> anyway +1
<zyga> it's much nicer now
<mborzecki> haha right
 * zyga afk
<jdstrand> degville: note, https://bugs.launchpad.net/bugs/1874156. I was planning on doing it but it sounds like you are? (which is fine)
<mup> Bug #1874156: Outdated docs on "Ubuntu security tips" for seccomp <snap-docs> <Snappy:Confirmed for jdstrand> <https://launchpad.net/bugs/1874156>
 * jdstrand isn't here yet
<degville> jdstrand: ah, I hadn't seen that. I don't mind making the first attempt and bringing it all over to the forum, but it would be great to have your review/edit when it's in place.
<mup> PR snapd#8821 closed: github: port macOS sanity checks from travis <Skip spread> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8821>
<clmsy> hi everyone
<clmsy> i have a question about using snapctl manually
<clmsy> we use this in prepare-device script : snapctl set device-service.headers='{"api-key": "redacted"}'
<clmsy> to set api key for serial vault integration etc
<clmsy> can i change the api key on a provisioned device
<clmsy> when i manually run this command i receive an error saying snapctl cannot set without context
<ijohnson> clmsy: no you can't change the api key on a device that already has a serial assertion
<ijohnson> clmsy: can you explain your use case a bit more why do you want to change the api key ?
<mup> PR snapcraft#3159 opened: cli: improve sudo detection with euid check for warnings/errors <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3159>
<clmsy> there was a mistake on setting the api key, it was set to the wrong value
<ijohnson> clmsy: does the device have a serial ?
<ijohnson> clmsy: err rather does the device with the incorrect api key have a serial assertion ?
<ogra> you can surely easily use snap set to change the variable value ... but that wont gain you much since the value has already been used/processed during first boot
<ijohnson> ogra: but if the device already has a serial assertion then changing the api key won't re-trigger that iiuc
<ogra> ijohnson, i wonder if re-modeling might help here
<ogra> yes, thats what i said ð
<ijohnson> ogra: remodeling only would help if it had a serial assertion
<ogra> you can change it but it wont have much effect
<ogra> ah, right
<clmsy> ok thank you!
<mup> PR snapcraft#3157 closed: spread: use absolute path to lxd <tooling> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3157>
<mup> PR snapcraft#3158 closed: spread: add snap watch <tooling> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3158>
<mup> PR snapd#8820 closed: data/selinux: allow checking /var/cache/app-info (2.45) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8820>
<zyga> mborzecki: found a curious bug
<mborzecki> hm?
<zyga> context is tests/main/services-stop-mode-sigkill
<zyga> we issue snap remove test-snapd-service
<zyga> that works
<zyga> but leaves this
<zyga>              ââsnap.test-snapd-service.test-snapd-sigterm-service.service
<zyga>              â ââ12053 sleep 3133731337
<zyga>              â ââ12660 sleep 3133731337
<zyga> (that is systemctl status)
<zyga> if you ask systemd about the unit it doesn't know anything (due to daemon reload)
<zyga> the service is defined as
<zyga>     test-snapd-sigterm-service:
<zyga>         command: bin/start-stop-mode-sigterm
<zyga>         daemon: simple
<zyga>         stop-mode: sigterm
<zyga> which means it should not do anything fancy and should really stop
<zyga> and go away
<zyga> this is on arch
<zyga> and I think it's not deterministic
<zyga> I ran this test a few times already
<zyga> logs are super spammy
<zyga> hmm, too large for pastebin
<zyga> how do I lift a meg of logs off a spread vm
<zyga> mborzecki: https://pastebin.com/Fv3Y364F gzipped
<zyga> nah, broken
<zyga> https://pastebin.com/RQhRtfJz
<zyga> eh
<zyga> that's base64
<zyga> so triggered spam detection
<zyga> https://paste.ubuntu.com/p/jJf77HTTdc/
<mborzecki> zyga: wormhole?
<zyga> that last link worked
<zyga> but good idea
<zyga> ugh, damn pain
<zyga> had to reach for 2fa to get this
<zyga> the log contains this:
<zyga> Jun 05 13:15:26 jun051257-936988 systemd[1]: Stopping Service for snap application test-snapd-service.test-snapd-sigterm-service...
<zyga> Jun 05 13:15:26 jun051257-936988 systemd[1]: snap.test-snapd-service.test-snapd-sigterm-service.service: Succeeded.
<zyga> Jun 05 13:15:26 jun051257-936988 systemd[1]: Stopped Service for snap application test-snapd-service.test-snapd-sigterm-service.
<zyga> what do you make of this?
<zyga> should this happen?
<zyga> the processes are still alive and their cgroup data clearly shows they belong to the snap
 * zyga looks at the systemd code
<zyga> huh
<zyga> Jun 05 13:06:14 jun051257-936988 systemd[1]: snap.test-snapd-service.test-snapd-sigterm-service.service: Found left-over process 12053 (sleep) in control group while starting unit. Ignoring.
<zyga> WHAT?!
<zyga> Jun 05 13:06:14 jun051257-936988 systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
<ogra> ... or a really tired service ...
 * zyga goes to trim that test to bare essentials
<zyga> so the test re-installs the snap
<zyga> I think what happens is that stop doesn't really finish
<zyga> before we continue
<zyga> otherwise I cannot explain this
<zyga> ah, wait
<zyga> I think this is actually correct
<zyga> the service doesn't terminate all the processes
<zyga> this is expected
<zyga> mborzecki: sorry, alarm over
<mborzecki> ijohnson: did you try btrfs too?
<ijohnson> mborzecki: no
<zyga> but oddly it happened only on some systems, indicating that there's still something racy there
<zyga> https://github.com/snapcore/snapd/pull/8815 needs a 2nd review
<mup> PR #8815: tests: port snap-handle-link test to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8815>
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8819#pullrequestreview-425315738
<mup> PR #8819: tests: move install tests from snapstate_test.go to snapstate_install_test.go <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8819>
<pedronis> zyga: sorry, had other things this morning, if I understand I should look at #8573? I put it in my queue, likely monday at this point
<mup> PR #8573: overlord/snapstate: inhibit startup while unlinked <Created by zyga> <https://github.com/snapcore/snapd/pull/8573>
<zyga> pedronis: yes, getting some advice on how to proceed would help with the front-end side
<zyga> thanks, Monday is fine
<zyga> with some luck I will be feeling better as well
<zyga> mvo: would you mind a quick look at https://github.com/snapcore/snapd/pull/8804
<mup> PR #8804: tests: port xdg-settings test to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8804>
<zyga> dbus-daemon clean is so close
<mup> PR snapcraft#3160 opened: project loader: fix v1 plugin repository installation on host <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3160>
<sergiusens> mvo: just to circle back, the seed wait did seem to work
<zyga> is there a simrefinery snap yet?
<mvo> sergiusens: \o/ thank you
<jdstrand> degville: emitorino and I are happy to review. are you planning on updating https://forum.snapcraft.io/t/security-policy-and-sandboxing/554 (ie, the Tips section) or writing something new? if new, keep in mind https://forum.snapcraft.io/t/security-policy-and-sandboxing/554 seems to be used by a lot of people, so we'll need to adjust that accordingly to read the new doc
<jdstrand> degville: s/if new/or are you planning on writing a new doc? if new/
<mup> PR snapcraft#3154 closed: cmake v2 plugin: take source-subdir into account <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3154>
<degville> jdstrand: (sorry, just in a meeting). I was only planning to update it, but I often end up re-writing large sections when I get into it. I'll definitely ping you, and please let me know if there's bits you know will need special attention. I'll make sure they're fixed.
<jdstrand> degville: cool, I preferred updating. yes, happy to review :)
<pedronis> pstolowski: I reviewed #8819
<mup> PR #8819: tests: move install tests from snapstate_test.go to snapstate_install_test.go <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8819>
<pstolowski> pedronis: ty
<mup> PR snapd#8819 closed: tests: move install tests from snapstate_test.go to snapstate_install_test.go <Test Robustness> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8819>
<mup> PR snapcraft#3159 closed: cli: improve sudo detection with euid check for warnings/errors <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3159>
 * cachio lunch
<mup> PR snapd#8780 closed: tests: core20 early defaults spread test <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8780>
<pstolowski> finally
<mvo> pstolowski: nice weekend gift \o/
<pstolowski> yes indeed :)
<mup> PR snapcraft#3161 opened: npm v2 plugin: always include $SNAPCRAFT_PART_INSTALL/bin in $PATH <bug> <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3161>
<ijohnson> cachio: is #8816 ready to review ?
<mup> PR #8816: tests: port 2 uc20 part1 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8816>
<cachio> ijohnson, yes
<cachio> ijohnson, thanks
<sergiusens> mvo: did you in the past 4 hours change any github permissions? Our Travis<->GH link just broke too
<mup> PR snapcraft#3160 closed: project loader: fix v1 plugin repository installation on host <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3160>
<mvo> sergiusens: I did not change anything
<mup> PR snapd#8822 opened: release: 2.45.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8822>
<mup> PR snapcraft#3161 closed: npm v2 plugin: always include $SNAPCRAFT_PART_INSTALL/bin in $PATH <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3161>
<mup> PR snapd#8786 closed: arch: add riscv64 <Created by xnox> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8786>
<mup> PR snapcraft#3162 opened: tests: remove scenario usage from lifecycle order <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3162>
<mup> PR snapd#8823 opened: asserts/internal: limit Grouping size switching to a bitset representation <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8823>
<mup> PR snapcraft#3163 opened: cli: remove the hidden inspect command <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3163>
<mup> PR snapcraft#3164 opened: cli: remove enable-ci command <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3164>
<mup> PR snapd#8824 opened: many: move encryption and installer from snap-boostrap to gadget <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8824>
#snappy 2020-06-06
<zyga> FYI, spread workers are down for maintenance
<Mirv> 'unknown kernel arch "armv5tel"' I'm probably not in a very good position here on Debian regarding snaps :D
<ogra> well, not with armel
<Mirv> yes I formulated that poorly, indeed specifically on armel
<ogra> debian armhf should be fine ... there simply is no armel core snap (which is the underlying rootfs snaps use)
<ogra> mips would have the same issue ... riscv might work already though ð
<wgrant> riscv64 core snap isn't quite there, but close!
<Mirv> funnily it downloaded core18 for me first before erroring out
<ogra> well, it probably tries its best ð
<Mirv> ah, it downloaded armhf
