#snappy 2016-03-28
<farblue> hi all :) has anyone had success with snappy on scaleway VPS provisioning?
<prasad> what must be the value for "init" in bootargs for an armhf device? is it "init=/lib/systemd/systemd-udevd" ?
<prasad> it results in "Failed to read /proc/cmdline, ignsystemd-udevd[1]" error
<prasad> anyone?
<ogra_> prasad, http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files ... take a look at the uboot.env.in files in the subdirs of the arm based devices there
<popey> 12:19 < popey> http://imgur.com/RNyqX2C
<popey> resolved by pulling power cable out and powering again
<popey> not good
<kyrofa> Good morning!
<josepht> jdstrand: I'm getting checksum mismatch when unsquashfs'ing and resquashing my snap.  https://myapps.developer.ubuntu.com/dev/click-apps/4710/rev/10/
<jdstrand> josepht: how did you build your snap?
<josepht> jdstrand: with snapcraft on a rpi2
<josepht> jdstrand: 16.04
<jdstrand> josepht: what version of snapcraft?
<josepht> jdstrand: 2.6.1
<jdstrand> ok, the issue isn't obvious. I'll have to look into it
<josepht> jdstrand: ack, thanks.  What I tried was to unpack the squashfs and repack it.  'file' showed a 4 byte difference between the two.  'ls' and 'grep' couldn't find any difference between the two unpacked filesystems.
<sergiusens> kyrofa, elopio can we start 10 after?
<kyrofa> sergiusens, no problem :)
<kyrofa> elopio, is there a way to know that a PR is not up-to-date with master, but not make it _required_?
<popey> Is there some way I can force the writable filesystem to resize as it failed on my pi - 16GB card has only 3.4GB writable
<kyrofa> popey, you can do it manually
<popey> how?
<popey> (please don't say take the card out and put it in another computer and use gparted)
<leftyfb> popey: use fdisk, delete the partition, recreate the partition. Reboot. run: sudo resize2fs /dev/mmcblk0p2
<popey> leftyfb: will i lose any data?
<leftyfb> popey: no
<popey> sweet
 * popey will blame you if I do :)
<popey> actually
<popey> shouldn't need to delete the partition
<popey> /dev/mmcblk0p2      270336 31250000 30979665 14.8G 83 Linux
<popey> it is the right size, just looks like I need the resize2fs ?
<popey> /dev/mmcblk0p2   15G  3.4G   11G  24% /writable
<popey> \o/
<popey> thanks
<jdstrand> josepht: can you request a manual review? I'm going to accept it for now
<josepht> jdstrand: okay, thanks
<kgunn> jdstrand: hey, you running a xenial core? curious what 'snap find mir' returns you?
<kgunn> ...or anyone else who might be tinkering today  ^
<kgunn> i may have found a bug in the store
<kgunn> so i had mir 1 & 2 published, it returned 2....then published a mir 3, and unpublished 2...so only 1 & 3 are published...now find just says "no snaps found"
<kgunn> beuno: ^
<kgunn> beuno: oops...nvmd...it was me....channels!
<kgunn> but...i had to pick stable?
<kgunn> thot, if xenial is still rolling edge...it would appear in edge?
<jdstrand> kgunn: it seems you don't still need me?
<kgunn> jdstrand: yep, sorry for noise
<josepht> jdstrand: sorry, I requested the manual review for a bad upload (arm version with amd64 as the arch.) I re-request a review of revision 9
<kyrofa> sergiusens, I hit a snag trying to remove the ld.so.conf stuff. The libs still need to link up at build time, and that code was used for build- and run-time dependencies
<kyrofa> So it appears that we may still need it at least to build stuff with libs in non-standard places
<kyrofa> sergiusens, unless you can think of a better way to do that
<sergiusens> kyrofa, let's just leave it in for now
<kyrofa> sergiusens, okay. Let's keep it in the back of our minds anyway
<sergiusens> kyrofa, can you rebase with master btw (or my branch)?
<sergiusens> kyrofa, yeah let's get a bug report going
<kyrofa> sergiusens, will do
<popey> just updated my pi 2 edge and again it didn't come back after a reboot :(
<popey> Reboot to use canonical-pi2-linux version 4.4.0-1004-raspi2+20160321.17-52.
<popey> Reboot to use ubuntu-core version 16.04+20160321.17-37.
<popey> that update
<sergiusens> kyrofa, did you rebase?
<kyrofa> sergiusens, not yet... ran into another issue... working it out
<sergiusens> ack
<kyrofa> I swear the universe doesn't want me splitting the unpacking of stage packages out to be done in build
<kyrofa> sergiusens, alright, it's been rebased onto your branch and it's all finished
<sergiusens> kyrofa, gonna check it out
<kyrofa> sergiusens, ended up unpacking debs into an intermediate directory in pull and linking them in with build
<sergiusens> kyrofa, but after I get back from aikido which I'm returning to after my 2 month hiatus
<sergiusens> :-)
<kyrofa> sergiusens, sounds great! Want me to make a PR into your branch in your fork? Might make reviewing easier
<kyrofa> sergiusens, or we can push your branch to the official repo and I can make a PR there. Tests run that way
<kyrofa> Let me know-- dinner time, I'll be on telegram
<tedg> jdstrand: Are the SNAP_DATA directories mounted NOEXEC?
<jdstrand> they shouldn't be
<tedg> jdstrand: Okay, looking for a theory on why this snap isn't working. That's not it :-)
<jdstrand> /dev/vda3 on /var/lib/snaps type ext4 (rw,relatime,data=ordered)
<jdstrand> and there aren't separate mount points for SNAP_DATA for snaps (just verified) so that shouldn't be it
<tedg> Ironically the Java library giving me trouble is called Snappy.
<popey> Where do bugs in snappy classic go?
<popey> (I mean, where should I file them)
 * genii sips his coffee and ponders how snappy classic/new snappy reminds him of coke classic/new coke 
<genii> Hopefully we don't get a diet snappy
<leftyfb> snappy zero
<leftyfb> you know, for the pi zero :)
<genii> Hehe
#snappy 2016-03-29
<sergiusens> popey, I'd log them against snappy
<sergiusens> kyrofa, so when you rebased you missed a fetch ;-)
<sergiusens> no worries :-)
<sergiusens> cherry-picking ftw
<sergiusens> elopio, you around?
<stgraber> jdstrand: lxd 2.0 rc7 is awaiting review in the store (maybe the last rc before final 2.0, one can hope :))
<dholbach> good morning
<didrocks> good morning dholbach!
<dholbach> salut didrocks
<dholbach> hey davidcalle
<davidcalle> dholbach: hey o/ Good weekend?
<dholbach> davidcalle, yep, very much so - how was yours?
<davidcalle> dholbach: great :)
<davidcalle> dholbach: finishing my upgrade and trying to reproduce the issue with the snap
<dholbach> ok cool
<zyga> good morning
<davidcalle> dholbach: resolved by making the launcher executable :)
<dholbach> haha
<dholbach> nice one
 * dholbach hugs davidcalle 
<popey> https://bugs.launchpad.net/snappy/+bug/1563223
<ubottu> Launchpad bug 1563223 in Snappy "Some standard updates break on classic, breaking snapcraft" [Undecided,New]
<popey> dholbach: ^ this kinda blocks me using snapcraft in classic on my pi
<dholbach> mvo, ^ have you seen anything like this before?
<mvo> dholbach: I have not seen this, no, sorry, need to debug (trying to reproduce first)
<Guest38540> Hey guys. Anybody using snappy with Beaglebone Black
<Guest38540> ??
<dholbach> davidcalle, shall we catch up in a bit?
<davidcalle> dholbach: sure, but we can do a quick one now if you want/have time
<dholbach> yep. let's do it
<davidcalle> +1
<ogra_> ppisati, could you take a look at bug 1561920 ... that seems to actually be a kernel issue
<ubottu> bug 1561920 in Snappy "Seccomp error on recent builds of snappy" [Critical,Confirmed] https://launchpad.net/bugs/1561920
<ogra_> ppisati, i also see permission denied errors when simply running dmesg as a normal user
<ogra_> (probably related)
<ppisati> ogra_: me looking
<ogra_> thanks :)
<stevebiscuit> win 12
<stevebiscuit> oops
<ogra_> lose 3, keep 9
<popey> mvo: a dist-upgrade of the snappy classic install should be enough to reproduce it
<noizer> Hello everyone
<noizer> Just a short question is it necessary to do first a snapcraft clean and then snapcraft snap or is it good enough to do only the snapcraft snap?
<ogra_> apw, any idea whats holding back https://launchpad.net/ubuntu/+source/linux-raspi2/4.4.0-1005.6 ?
<davidcalle> noizer: from my experience, it depends which changes you have made. I've found it quite useful (and faster) to clean a specific part I've changed (eg. snapcraft clean <part>;snapcraft snap)
<noizer> oooh ok nicee
<noizer> davidcalle:  didn't knew that  you can clean only one part :p
<davidcalle> noizer: discovered it this morning ;)
<noizer> davidcalle: heheh xD
<ogra_> hrm
<ogra_> ubuntu@localhost:~$ ls -l /etc/network/interfaces.d/
<ogra_> total 8
<ogra_> -rw-r--r-- 1 root root 64 Mar 28 09:23 50-cloud-init.cfg
<ogra_> -rw-r--r-- 1 root root 40 Mar 28 09:19 eth0
<ogra_> so thats why i have no more network at all then
<jdstrand> stgraber: done
<popey> dholbach: when using snapcraft, I have an app which has pre-requisites which need pulling and building. I can use after:, and it pulls and builds them fine, but I need to set --prefix to where the main package is being built. Is there some env var for the build dir in snapcraft, so i can install them there?
<zyga> popey: use DESTDIR
<zyga> popey: prefix is irrelevant
<zyga> popey: but snapcrat will give you a DESTDIR to instal to
<mvo> popey: thanks, I have not managed to find time yet but I put it on my list of things to look at
<jdstrand> zyga: hey, so, a few of my PRs for the security interfaces landed, but most didn't. says there were failures witn 'integration tests', but when I click on the link to see the test result, it just spins and never shows me anything
<zyga> jdstrand: that's VPN for you, you have to be connected to see jenkins
<zyga> jdstrand: (hi btw)
<jdstrand> ah
<jdstrand> zyga: ok, well, now I get a 404 :)
<jdstrand> https://github.com/ubuntu-core/snappy/pull/723
<zyga> jdstrand: I reviewed a few of your branches, my suggestion would be to keep a few open and merge/rebase the rest so that it's easier to land them
<zyga> jdstrand: or try to not make them co-depend on each other
<zyga> jdstrand: well, jenkins ... reliable as usual
<popey> zyga: got an example?
<jdstrand> zyga: they have to co-depend on each other the way all* are written
<zyga> jdstrand: yeah, I know
<zyga> jdstrand: example of ... ?
<jdstrand> I mean, I guess I can have them all be separate and add all at the end, but that is not what you said you wanted
<popey> zyga: i need to install the libs so the subsequent build finds them
<zyga> jdstrand: right, I know, perhaps it'd be easier if we didn't
 * jdstrand redoes all the PRs
<zyga> popey: in the sname part?
<zyga> jdstrand: hmm, perhaps ask gustavo on telegram
<popey> oh, these should be separate parts
<zyga> jdstrand: he said he'll look at your branches
<popey> oh, they are...
<zyga> jdstrand: and we can always review individual patches
<zyga> popey: separate parts can use typical stuff, e..g. pkg-config
<zyga> popey: I don't think snapcraft gives you a way to do cross-part directory inspection easily
<popey> zyga: http://paste.ubuntu.com/15551251 this is what I have so far
<zyga> but don't quote me on that
<zyga> popey: that looks sane, I suspect you may want to ask sergiusens how to make it work while still looking pretty
<popey> zyga: is there some way to specify the build dependencies in the snapcraft yaml?
<zyga> popey: yes, sure
<jdstrand> oh my gosh
<zyga> popey: build-packages or something like that (on each part)
 * popey googles
<popey> ta
<zyga> popey: I don't remember, I always check the source
<popey> heh
<zyga> popey: googling is not useful IMHO
<zyga> popey: docs are old or useless
<jdstrand> tg is saying over and over 'Error: one of the params is missing or invalid'
<jdstrand> what param? /me is just trying to send a message
<zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/744 (for later)
<zyga> jdstrand: I'm iterating over feedback that gustavo left earlier today
<sergiusens> zyga, popey jdstrand `snapcraft help plugins` (and the reason I'm doing a pseudo rtfm is because I want feedback :-) )
<zyga> sergiusens: I know about that but it's always insufficient (could have been improved since I last looked)
<zyga> sergiusens: I'd personally prefer a man page that mentions that
<zyga> sergiusens: or other well-known way to discover this
<popey> sergiusens: thanks
<zyga> sergiusens: but I'm skewed already and I always read the source for up-to-date knowledge about each plugin
<popey> sergiusens: is qmake on your list of plugins to make sometime?
<popey> or some other way I can inject a "qmake" call before "make" using the make plugin?
<sergiusens> popey, yeah, we will make a qmake one; but we are working on foundation stuff right now
<popey> no workaround for now?
 * zyga recalls qmake sucking for not having standardized DESTDIR
<sergiusens> popey, in your project dir cp cmake.py -> parts/plugins/x-qmake.py
<sergiusens> and edit x-qmake.py to your liking (changing the cmake calls for qmake ones)
<jdstrand> sergiusens: imho, strip feels like a weird name for that step. I understand why-- you are taking away stuff from staging, but you are also adding meta. 2 cents
<sergiusens> and in snapcraft.yaml specify 'plugin: qmake'
<popey> project dir?
<sergiusens> popey, your project dir == where snapcraft.yaml is
<popey> ah
<jdstrand> sergiusens: I think this is quite handy. I would be even more so if there was an example that used each that you then tersely explained
<sergiusens> jdstrand, thanks for the tip; I think we can add individual topics for each of the keywords
<jdstrand> sergiusens: you could go that way, which would be handy, or(/and?) add a 'Putting it all together' section that has a larger example and how they all relate to each other, the timing of things, etc
<sergiusens> sounds good
<popey> sergiusens: the nodejs plugin seems to assume the thing I want is in npm.. what if it's something that's on github? the nodejs plugin doesn't support source:  ?
<sergiusens> popey, it does support source
<popey> "no handler to manage source" is what i guet
<sergiusens> popey, https://github.com/ubuntu-core/snapcraft/tree/master/examples/webchat
<popey> *get
 * popey looks
<sergiusens> popey, really?
<popey> ah, your source is in current dir
<popey> I'm trying to get it to grab from github for me, I'll do your way
<sergiusens> popey, you can do it your way too
<popey> wonder why it fails here
<sergiusens> popey, use source and "source-type: git"
<popey> ahhh
<popey> doh
<popey> ta
<sergiusens> or use the git uri instead of https
<popey> building \o/
<popey> thanks sergiusens
<popey> sorry for the newb questions :)
<sergiusens> \o/
<popey> this is all a new adventure for me ã
<ogra_> and dont use any left padding ;)
<sergiusens> popey, all good, if anything feels confusing a bug report is always welcome :-)
<popey> holy freole, it built
<sergiusens> popey, making it work is the hard part ;-)
<sergiusens> popey, node projects use the source dir as the place to land config
<sergiusens> popey, shout irc was sort of sane and had a flag to tell it where to store config
<ogra_> mvo, where do we stand with the release, it would be really helpful to finally have an all-snaps beta image at some point
<ogra_> (o5r even alpha)
<jdstrand> olli: fyi, bug #1562989 is fixed. upgrade to ubuntu-core-launcher 1.0.22 and ubuntu-clock-app.clock starts again
<ubottu> bug 1562989 in ubuntu-core-launcher (Ubuntu) "'aa_change_onexec failed with -1. errmsg: Permission denied'" [Critical,Fix released] https://launchpad.net/bugs/1562989
<popey> sergiusens: yeah, this is gonna be tricky I imagine.
<olli> jdstrand, most awesome!
<sergiusens> popey, just patches upstream :-)
<sergiusens> kyrofa, btw, did you see my comments, we need to sync
<ogra_> sigh
<ogra_> ubuntu@localhost:~$ snap find
<ogra_> error: cannot list snaps: cannot communicate with server: Get http://localhost/2.0/snaps?sources=store: dial unix /run/snapd.socket: connect: no such file or directory
<ogra_> aha ... a manual "sudo systemctl start ubuntu-snappy.snapd" fixes it
<kyrofa> Good morning
<sergiusens> kyrofa, hey!
<kyrofa> sergiusens, sorry, family is sick, just got in. You're right, looks like I was still out of date on that branch :P
<kyrofa> sergiusens, fixing now
<didrocks> good morning kyrofa, sergiusens :)
<kyrofa> didrocks, good afternoon!
<sergiusens> kyrofa, I squashed everything already; look at my comments in the PR though ;-)
<sergiusens> kyrofa, unpacking stage-packages into a different dir than installdir taxes python again
<kyrofa> sergiusens, ah, that explains the issues I'm having rebasing :P
<kyrofa> Alright I haven't caught up on email yet-- going to the PR now
<sergiusens> kyrofa, and no worries, my kid has some sort of a fever as well; I had a sleepless night again; it seems he is toothing
<kyrofa> sergiusens, oh yes, that's a fun stage. The molars are the worst
<sergiusens> kyrofa, for a minute I thought you were talking stage-packages and got all confused :-P
<kyrofa> Apparently I don't get good wifi in that room. sergiusens you're right, the unpackdir isn't going to work. So I'm going to simply make the build cleaning smarter and unpack the debs again. Not ideal, but I think it's the only way to make this work correctly
<sergiusens> kyrofa, yeah, that's what I wanted to sync on; so yeah, all good as I was thinking about double unpack
<kyrofa> sergiusens, easy, I'll get back to you
<kyrofa> I'm going to add a good integration test for this as well, make sure this continues to work
<elopio> kyrofa: answering your ping from yesterday, I see no way of showing that the branch is not merged with master without making it required.
<kyrofa> elopio, alright, thanks for getting back to me!
<elopio> kyrofa: if we handle the merge on jenkins, we could do anything we want. But without nice buttons, just comments with the bot back and forth on the PR.
<sergiusens> ogra_, mind looking at Jian LUO's email?
<ogra_> sergiusens, was there a new one (is my mailserver slow again ?)
<ogra_> i answered one on wednesday
<sergiusens> ogra_, no did not see any reply from you, there is a new one from an hour or go or so
<ogra_> https://lists.ubuntu.com/archives/snappy-devel/2016-March/001645.html
<ogra_> just me whining though ...
<ogra_> here is the proper answer: https://lists.ubuntu.com/archives/snappy-devel/2016-March/001642.html
<ogra_> ricmm, mvo i filed bug 1563358 for one of you :)
<ubottu> bug 1563358 in Snappy "snappy can only handle one bootloader (if grub is installed, uboot is completely ignored)" [Undecided,New] https://launchpad.net/bugs/1563358
<ogra_> (there was also the snappy list issue that falls apart if grub is installed on uboot systems, i sadly lost the logs for that one)
<elopio> mvo: sergiusens: following your discussion about snapcraft build... Shouldn't we move all the snappy build unittests to snapcraft?
<elopio> We can leave the build integration tests in snappy if snapcraft is installed in the os.
<sergiusens> elopio, oh, certainly
<sergiusens> it makes sense
<sergiusens> but what weird build unit tests are there in snappy?
<sergiusens> is there anything worth porting over?
<elopio> sergiusens: both have great coverage, so most tests should overlap. But I am not sure, we should compare them.
<sergiusens> elopio, want to take care of that? Not really do the work, just see if we are missing anything and add it to our suite
<sergiusens> err, kyrofa or me can add it to our suite that is
<kyrofa> Yeah, that makes sense
<josepht> sergiusens, kyrofa: would it be worthwhile for me to add support for configflags for the make plugin?
<kyrofa> josepht, just to add to the `make` invocation?
<sergiusens> josepht,  I would call the entry `make-parameters`; not a fan of the generic configflags name
<sergiusens> josepht, and what kyrofa asked
<Iot_developer> Hi, I'm new here :)
<kyrofa> Welcome Iot_developer
<Iot_developer> thanks
<Iot_developer> i'm developing IOT on BBB
<Iot_developer> and we have some problems wiht snappy
<Iot_developer> we build our app as a snapp
<Iot_developer> but we are not able to get bonescript working
<ogra_> doesnt that just need a working nodejs setup ?
<ogra_> snapcraft has a plugin for nodejs iirc
<elopio> sergiusens: sure
<Iot_developer> we done that
<Iot_developer> node is working fine
<awe> sergiusens, is there a way to list the files that a specific snap has installed?
<Iot_developer> when we build app with bonescript our service is dead
<awe> ( ie. the equivelent to running dpkg -L )?
<kyrofa> sergiusens, this is a separate bug I'll need to file, but cleaning the build step for python plugins doesn't work since it clears out the installdir which is written to in the pull step. Think it would work to do the pip stuff into another folder that can be copied into installdir on build?
<Iot_developer> when we build snap without bonescript module everything is working fine
<elopio> fgimenez: can we skip la media hora de la calidad today?
<ogra_> WOAH !
<fgimenez> elopio, sure, no problem
 * ogra_ just booted with "cloud-init=disabled" .... thats unbelivable fast !!!
<fgimenez> elopio, i have a couple of prs for you to review, other than that i've been preparing the connection to practitest, it'll be ready tomorrow
<elopio> fgimenez: I'll take a look at your profile and review them.
<ogra_> Iot_developer, theer should be info in the logfiles telling you why that happens
<fgimenez> elopio, thx, i've been also debugging the integration test coverage generation error, something's wrong with the current production server, it works fine in an older one
<sergiusens> ogra_, did you take care of password, ssh and all that mumbo jumbo?
<ogra_> sergiusens, i did set it after i had a firestboot done
<ogra_> so cloud-init still did set this up but doesnt run on subsequent boots
<ogra_> sergiusens, the cloud-init from the weekend completely broke outr boots
<Iot_developer> the logfile says that ( is missing, and we don't know what to do
<ogra_> looks like a syntax error in one of your files then
<Iot_developer> that is the problem, beacuse we run that program on ubuntu debian and everything works fine
<noizer> rpi 3 installation is just installing the image on a sd card?
<ogra_> noizer, just dd it to the card, yeah
<ogra_> there migth still be issues and glitches, thats a very first shot
<noizer> ogra_: Thx
<elopio> sergiusens: kyrofa: there is no good way to rebase the branch before merging, because the plugin uses the github API and we only have the equivalent of the green merge button.
<elopio> we could do it without the plugin all in bash, but it wouldn't be as nice. Anyway, it's ready if you want to try it. I can unprotect the branch now and you comment "merge this please" when you are happy.
<zyga> jdstrand: hey
<zyga> jdstrand: I think this is ready for another review https://github.com/ubuntu-core/snappy/pull/744
<sergiusens> elopio, kyrofa but without rebasing it feels weird
<kyrofa> And it doesn't really chance anything, right?
<kyrofa> change*
<jdstrand> ack. it'll be a little bit
<elopio> sergiusens: kyrofa:
<elopio> sorry.
<elopio> sergiusens: kyrofa: no, we still have to ask the author for a manual rebase.
<elopio> and when he rebases, the tests will be triggered. So this will just slow down the merge by re-running the tests again.
<elopio> I've asked the plugin author about adding rebase. I'll make a quick job with all manual, to see how it goes.
<kyrofa> elopio, alright so using this can we leave the rebase requirement in place to merge with github but allow merging via jenkins in case there's something we know doesn't need a rebase?
<kyrofa> If we remove the requirement there's no way to know if a rebase is needed without manual work
<elopio> kyrofa: that would work only if the github protection is not at the API level, just on the GUI. Which I doubt, but have to try.
<kyrofa> elopio, ahh, I see
<kyrofa> Yeah I'm not sure it's worth it just yet, then
<elopio> kyrofa: oh wait, I'm stupid. I can allow admins to ignore the required status checks.
<kyrofa> elopio, ah! And not being up-to-date is a status check?
<elopio> kyrofa: done. You can now click a red merge pull request button.
<kyrofa> elopio, I don't see it-- though I'm not actually sure I'm an admin
<elopio> kyrofa: right, you are not ^_^
<kyrofa> But that's exactly the kind of functionality I wanted! Good find :)
<elopio> kyrofa: take a look now.
<kyrofa> elopio, peeeerfect!
<elopio> so I guess that if I make snappy-m-o admin, the jenkins plugin merge would work. Now I think it's not useful, but good to know.
<kyrofa> elopio, yeah this is what I was hoping for :) . Thank you!
<AnInstanceOfMe> Following snappy tutorial on ubuntu dev site, but just get "Issues while validating snapcraft.yaml: The 'parts' property does not match the required schema: None is not of type 'object'" when running 'snapcraft stage'.  Any idea where I'm going wrong?
<kyrofa> AnInstanceOfMe, mind pasting your snapcraft.yaml on http://pastebin.ubuntu.com/ ?
<kyrofa> AnInstanceOfMe, also, what version of Snapcraft are you using?
<AnInstanceOfMe> kyrofa: It's version 2.6.1 and I'm running on Ubuntu Mate 16.04 beta. The snapcraft.yaml is just the example on the Ubuntu dev site.
<kyrofa> AnInstanceOfMe, okay, which tutorial then?
<AnInstanceOfMe> https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/
<josepht> kyrofa: yes
<josepht> sergiusens: make-parameters sounds fine to me :)
<kyrofa> josepht, sure. And I agree, the name "configflags" makes sense for autotools and cmake, but not make.
<kyrofa> AnInstanceOfMe, the tutorial works for me. So please paste your yaml
<AnInstanceOfMe> kyrofa: Rebooted the machine and that issue is no more. Sorry for the bother.
<kyrofa> AnInstanceOfMe, not a problem :)
<ogra_> popey, your system looks really odd
<ogra_> (snaps not removed on upgrade ... snaps that arent actually published installed etc)
<plars> ogra_: do you know if there are known problems with the dragonboard image? I am getting an error trying to boot it:
<plars> https://www.irccloud.com/pastebin/ptzM39TI/
<popey> ogra_: it's edge
<sergiusens> elopio, what is this about ERROR: No artifacts found that match the file pattern "adt-run-output/binaries/*.deb". Configuration error?
<sergiusens> elopio, in http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/296/console
<sergiusens> makes adt tests fail
<elopio> sergiusens: let me fix that
<sergiusens> elopio, I think I made a mistake in that process as well :-/
<sergiusens> elopio, you will see
<elopio> sergiusens: I don't see it.
<elopio> It's fixed, but I'm running the job to confirm. I forgot to add the -o parameter.
<joc_> elopio: will that make my branch pass again? :)
<elopio> joc_: yes, that's the same error you got on your last run.
<elopio> however...
<elopio> we have a new one:
<elopio> The following packages have unmet dependencies:
<elopio>  linux-generic : Depends: linux-image-generic (= 4.4.0.16.17) but it is not going to be installed
<elopio>                  Depends: linux-headers-generic (= 4.4.0.16.17) but 4.4.0.15.16 is to be installed
<joc_> :/
<elopio> let me see how to fix that.
<sergiusens> elopio, you don't see it; I'll share it privately
<elopio> that error is on the cloud image that autopkgtest uses. Not much I can do for it.
<elopio> I suppose it needs to be refreshed, somehow.
<kyrofa> sergiusens, alright I remember the insidious problem with simply unpacking again in build(), but I think I have a rather elegant solution
<ogra_> elopio, smells like you are enabling proposed
<ogra_> (thats a typical out-of-sync breakage of a half migrated package)
<ogra_> (you will see tha every now and then in -propoased, pretty normal)
<kyrofa> sergiusens, I just pushed up a new commit to my branch, which is up-to-date with yours
<sergiusens> kyrofa, \o/
<kyrofa> sergiusens, agh, wait I broke a few tests. Hold on a sec
<kyrofa> (just log messages)
<elopio> ogra_: not me. Maybe the image has proposed enabled. But we are just copying what they do on the distro, so everything should be failing now.
<ogra_> elopio, well, linux-generic just migrated
<elopio> right, just bad timing
<elopio> it's running now.
<ogra_> thats why i'm so critical about using -proposed ... it simply isnt reliable
<ogra_> you will have failures every now and then
<elopio> ogra_: please help me going again through the snappy release process.
<elopio> so, we put every day a deb build from the branch into xenial-proposed.
<elopio> we generate a ubuntu-core snap using proposed as the source and put it into edge.
<elopio> we test, test, test, and when we are happy to get it into stable, we move snappy and all it's dependencies from proposed to the archive.
<elopio> then we regenerate the snap without using proposed, and put it into stable.
<kyrofa> sergiusens, NOW it's all good
<elopio> is that right or am I missing something important?
<ogra_> elopio, we generate all kernel and os snaps on cdimage
<ogra_> elopio, i'm still working on auto-submission to the sotre for these daily builds
<ogra_> (just got disctracted by researching all the newly introduced cloud-init breakage today)
<elopio> ogra_: we can submit the snaps to the store on jenkins. I'm not sure if that would make your life easier.
<ogra_> elopio, i cant tell yet how tht will look in the store, but i was hoping that we can auto-publish the auto-uploaded snaps to edge
<ogra_> so you could roll edge images and teste them ... if they are good you can promote the snaps to the stable channel in the store
<ogra_> elopio, well, can you watch http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ (for changed MD5SUM file or some such) and pull from there with jenkins ?
<ogra_> as soon as there are updated snaps showing up ...
<elopio> ogra_: yes. We put a listener on that url and any changes will trigger a job.
<ogra_> that way would indeed work too
<ogra_> and save me from hacking snap uploading into our 12.04 cdimage server :)
<elopio> on the job I can put a snapcraft upload command with the credentials that we are storing in vault behind the vpn.
<ogra_> perfect
<elopio> what we would be missing is the publish command, but vila told me he'll be working on that.
<ogra_> you will need some name mapping i guess though
<ogra_> i.e. xenial-preinstalled-core-armhf.raspi2.kernel.snap   is in reality canonical-pi2-linux
<elopio> that's easy. We make one job per snap, and hardcode the name change.
<ogra_> and xenial-preinstalled-core-arm64.dragonboard.kernel.snap ... canonical-snapdragon-linux
<ogra_> you could grab the name from inside the snap ... but i think thats overkill (the true name is in the snap.yaml indeed)
<elopio> ogra_: I wonder if snapcraft is not doing that already.
<kyrofa> elopio, for the name of the upload?
<ogra_> when uploading ?  not sure ... it would either need to bind-mount the snap or extract the squashfs
<elopio> anyway, I'll get to it tonight, give it a try uploading to my account and give you the code for the job to review.
<ogra_> i guess thats quite time and space consuming
<kyrofa> elopio, it's parsing the in-tree yaml
<ogra_> yeah
<ogra_> there is no tree
<ogra_> its a binary snap ... the tree is long gone (an didnt exist on a machine that has outside world access)
<kyrofa> ogra_, yeah snapcraft's upload is pretty tied into the build steps (e.g. if the snap doesn't exist it'll try to build it, etc)
<ogra_> but you can upload an existing snap ?
<elopio> kyrofa: but if the snap exists, it will just upload it. I think.
<elopio> if not, I can write the code for that.
<ogra_> (worst case we could loop/bind mount the snap and extract the snap.yaml from it though)
<ogra_> (assuming jenkins can mount stuff)
<kyrofa> elopio, indeed, but it has to be named correctly (and it still needs the in-tree yaml). If we bind-mounted it and parsed the in-snap yaml, we could add a parameter for uploading any old snap
<sergiusens> elopio, kyrofa here's a reading one in the meantime https://github.com/ubuntu-core/snapcraft/pull/409
<ogra_> the naming wouldnt be the prob ... but the version would
<ogra_> so one way or the other we need to extract the snap.yaml
<ogra_> to get that info
<elopio> the version is not important. The store assigns an increasing revision for each new version.
<ogra_> the version is part of the name
<ogra_> so to have the file named correcly you need to know the version that was used in the snap.yaml afaik
<sergiusens> ogra_, unsquashfs -l
<ogra_> yeah, or loop mounting
<sergiusens> `unsquashfs  squashfs-root/meta/snap.yaml` to only get yaml
<elopio> well, bottom line is that on jenkins can do anything. I will make a first version with the least ugly thing.
<elopio> I think it would be nice for snapcraft upload to take an optional .snap argument.
<elopio> and if there's no tree, unsquash.
<ogra_> yeah, especially since you only need the snap.yaml after all
<kyrofa> elopio, agreed, and if we get the code to get the yaml out of the snap, don't use the in-tree yaml (since it could theoretically change)
<ogra_> sergiusens, btw, it would b nice if you could name your announcements a bit more careful in the future :)
<ogra_> "- support for building the os snap (from a directory)."
 * ogra_ waits for all these people that create random busybox rootfses and throw them into the store now 
<ogra_> (and file tons of bugs because snappy doesnt work :P )
<ogra_> s/name/phrase/
<plars> ogra_: so the dragonboard is known to be broken now?
<sergiusens> kyrofa, I created a PR for easier review; added one comment
<ogra_> plars, mine works ... why do you think that ?
<sergiusens> ogra_, oh; what happened?
<plars> ogra_: won't boot for me - elopio said it was broken for him when he tried it last too
<plars> ogra_: https://www.irccloud.com/pastebin/ptzM39TI/
<ogra_> sergiusens, nothing, but "- support for building the os snap (from a directory)." soinds liek we are encouragin these rootstock users to roll their own rootfses
<ogra_> plars, using the right kernel ?
<ogra_> canonical-snapdragon-linux is the one you want
<sergiusens> ogra_, oh, we allow that apparently; but it will never make it into the store ;-)
<ogra_> (we sadly cant delete old packages fromthe store)
<sergiusens> ogra_, ask beuno to do it for you
<plars> ogra_: I'm using core rolling --kernel=canonical-dragon-linux.canonical --gadget=canonical-dragon.canonical --os=ubuntu-core.canonical --developer-mode --channel edge
<ogra_> plars, yeah, thats the old kernel .. i told elopio last week that he needs to use the new one ;)
<plars> ogra_: ah, ok what's the new magic? :)
<ogra_> i guess that drowned in a lot of other conversation about the new snaps
<ogra_> canonical-snapdragon-linux.canonical
<plars> ogra_: I'll give it a try, thanks!
<ogra_> as kernel
<elopio> we have to update zyga's script.
<ogra_> or yu can just grab the snaps from http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
<ogra_> (though the naming isnt matching)
<elopio> ogra_: is the gadget still canonical-dragon.canonical?
<ogra_> yeah, that didnt change
<ogra_> someone uploaded a 4.4 package for canonical-dragon-linux though, i wonder where that comes from
<elopio> https://github.com/zyga/devtools/pull/1
 * ogra_ really hates that we are all using the same account for uploading ... no way to figure out wwho did that upload now 
<ogra_> anyway, off to the TV to watch germany lose vs italy
<sergiusens> kyrofa, replied to all the comments; wrt stage-pkg you said tests were in order?
<sergiusens> or is that not really needed
<sergiusens> ?
<sergiusens> ogra_, I've been complaining about the account issue for a while; but to be fair, we have the same problem with cdimage ;-)
<kyrofa> sergiusens, it's less magical now, I actually don't think the integration test is needed
<ogra_> sergiusens, well, depends if you use cdimage the right way (for code changes there ar proper trees that keep your name)
<ogra_> but yeah, it is hard to tell who tiggered an image build
<sergiusens> ogra_, true; so I bet whoever updated the gadget snap in the store did not update the bzr branch?
<ogra_> sergiusens, which gadget snap ?
<sergiusens> ogra_, the dragonboard one, but now I see you mention a kernel snap ;-)
<ogra_> (pi2 might by my fault, i'm holding back the branch til ppisati and i found out whats the issue with the console)
<ogra_> yeah, dragonboard gadget hasnt changed in a while
<ogra_> i'll do a final upload before 16.04 (with a final checkout of the dragon uboot tree) ... but didnt plan to touch it til then
<ogra_> yay ... goal
<elopio> ogra_: change the credentials, and start sharing the snap.
<elopio> yay!
<ogra_> elopio, and it will then still be a .canonical one ?
<elopio> ogra_: that's what I understood.
<ogra_> oh, neat !
 * ogra_ will look at that toorrow
<elopio> I will give it a try, because now I'm not so sure it's not only for installing.
<elopio> sergiusens: kyrofa: do you want to keep that comment by coveralls, or should I disable it?
<kyrofa> elopio, yeah it doesn't add much since we can see it in the checks
<kyrofa> sergiusens, done on the should_step_run refactor
<sergiusens> kyrofa, \o/
<sergiusens> elopio, kyrofa I don't mind the email telling me everything is good though; but I won't miss it if it is gone either
<joc_> sergiusens: i'd like to ask you about some snapcraft behaviour i've noticed recently when testing the plugin i'm trying to land for plainbox
<sergiusens> kyrofa, you inspired me to a small refactor (but different branch)
<kyrofa> sergiusens, hahaha
<joc_> sergiusens: i've noticed that if my part has some stage-packages the sys.path in which my manage.py script is run is different
<joc_> sergiusens: if there are stage-packages defined sys.path seems to search for modules in parts/part-name/install/..
<joc_> otherwise the sys.path is looking in locations in stage/..
<joc_> sergiusens: whats the reason for this?
<sergiusens> joc_, I'd have to look, maybe kyrofa know right off the bat
<sergiusens> a small snapcraft.yaml would be easier to follow
<joc_> ok, will try and come up with something
<kyrofa> joc_, only the python plugins touch the PYTHONPATH
<joc_> kyrofa: none of the parts in my yaml are using python plugins
<joc_> kyrofa: just this plugin https://github.com/jocave/snapcraft/blob/plainbox-provider-plugin/snapcraft/plugins/plainbox_provider.py
<joc_> kyrofa: i have been printing sys.path in manage.py (called in build function) to debug some failures of that script
<joc_> it seems to change depending on presence of stage-packages on the part
<attente> hi, could someone explain to me the difference between /usr/bin/snap and /usr/bin/snappy?
<pedronis> attente: /usr/bin/snap will be the main command in 16.04, /usr/bin/snappy is going away but the move isn't quite complete, they have somewhat different syntax for some things, and snap  does most things through the snappy daemon (snapd), while snappy was doing them directly
<attente> pedronis: great, thanks for the clear explanation
<sergiusens> elopio, mind testing this on armhf now https://github.com/ubuntu-core/snapcraft/pull/335 ?
<sergiusens> joc_, kyrofa it changes becase if you add stage-packages that have a hint of python in it, it will be the prefered interpreter
<kyrofa> sergiusens, how?
<sergiusens> the one that ends up in `stage` (or soon in `install` for the part if in the same part)
<sergiusens> kyrofa, say you use this plugin https://github.com/jocave/snapcraft/blob/plainbox-provider-plugin/snapcraft/plugins/plainbox_provider.py
<sergiusens> kyrofa, no stage-packages at all; that plugin will use the system plugin just fine
<sergiusens> kyrofa, now add a stage-package that depends on python3 you end up getting `stage/usr/bin/python3`
<sergiusens> kyrofa, I guess sys.path is dynamically set
<kyrofa> sergiusens, but what part of the code changes... ah
<kyrofa> sergiusens, because I didn't see anything in snapcraft itself that changes sys.path or PYTHONPATH to look in the stage directory
<sergiusens> kyrofa, we change sys.path iirc but to run from source
<kyrofa> sergiusens, indeed
<kyrofa> sergiusens, and to find local plugins. That's it
#snappy 2016-03-30
<dholbach> good morning
<dholbach> salut davidcalle
<dholbach> davidcalle, do you think we're all set with the doc?
<didrocks> hey dholbach!
<dholbach> salut didrocks
<didrocks> davidcalle: dholbach: which doc are you working on?
<dholbach> didrocks, one about snappy on classic
<didrocks> ah, is there a getting started as well for it? :)
<zyga> good morning
<didrocks> good morning zyga!
<davidcalle> dholbach: I think we are good for the examples, I'm a bit concerned about the security/confinement part
<dholbach> I talked to Jamie a few weeks back and he said it'd be updated in due time
<dholbach> maybe we should add a note saying that we are going to add a link to updated docs about security once they're available(?)
<davidcalle> dholbach: I'm adding a comment about it right now
<dholbach> thanks
<noizer> Hi short question where can I see the errors of seccomp?
<ogra_> syslog
<noizer> thx
<didrocks> jdstrand: hey, small questions about unconfined app
<didrocks> jdstrand: I have an unconfined command which is doing terminal content recording
<didrocks> I want to be able to launch other snap commands from
<didrocks> but even unconfined, I'm getting when executing another one: aa_change_onexec failed with -1. errmsg: Permission denied
<jdstrand> didrocks: you can't launch them from /snaps/bin, you have to launch them from /snaps/<snap>/...
<jdstrand> launching apps from /snaps/bin won't work for a ton of reasons
<ogra_> why would you define the path at all ?
<jdstrand> he wants to launch other snap binaries
<ogra_> oh, cheating oyu mean ?
<jdstrand> yes
<ogra_> heh, k
<jdstrand> well, I assume that is what he meant. otherwise, there is perhaps a bug
<jdstrand> didrocks: can you be more specific?
<jdstrand> davidcalle, dholbach: fyi, the PRs for the new security interfaces are now all acked so hopefully they'll be merged soon
<dholbach> jdstrand, awesome!
<jdstrand> davidcalle, dholbach: when that happens, the docs can be updated
<didrocks> jdstrand: basically, it's a snap to make demos and record talks
<didrocks> so, recording the terminal output and show how confinment works
<didrocks> and such
<jdstrand> didrocks: no, I mean, what are you executing-- your own binaries or binaries from other snaps?
<didrocks> my binary is executing a shell recording utility (unconfined)
<didrocks> that way, I want to run other commands
<didrocks> and record them
<didrocks> (from other snaps)
<didrocks> hence the unconfined profile
<jdstrand> is your binary launching something from /snaps/bin?
<didrocks> well, it's a shell, so yeah, I can run some to record how confinement works for other commands
<jdstrand> right
<jdstrand> that isn't going to work (see above)
<didrocks> there isn't any way for making it work? like having a shell capability like this doesn't sound a very crazy requirement
<jdstrand> no
<didrocks> it's like if I wanted to record the screen and we can't on snappy then
<jdstrand> you can record the screen
<jdstrand> you just need to do it from within your snap
<didrocks> yeah, but from this snap, I can't run a normal shell
<jdstrand> the launcher is doing a ton of things
<jdstrand> it isn't going to work
<didrocks> and no plan to make this kind of use case working in the future?
<jdstrand> no
<jdstrand> /snaps/bin is not the interface for apps to launch other apps
<didrocks> I don't hardcode /snaps/bin
<didrocks> I just run $command
<didrocks> which is in the PATH of the shell that is executed
<jdstrand> it doesn't matter
<didrocks> yeah
<jdstrand> /snaps/bin is in your PATH so that is what you get
<didrocks> but I mean, it's not like I was trying to do something funky there
<jdstrand> you are
<jdstrand> snaps are not allowed to launch other snap's binaries
<didrocks> well, I have things in PATH I can't execute
<didrocks> so we should remove it
<didrocks> once we launch a command
<jdstrand> there are lots of things in your PATH
<jdstrand> eg, 'mount'
<jdstrand> fsck
<jdstrand> you can't run those either
<didrocks> yeah, but it's telling permission error and I can run sudo to get access
<didrocks> here, it's really you can't do it
<didrocks> (in addition to that being a valid use case IMHO)
<jdstrand> unconfined is going away anyway
<jdstrand> it seems you are going to force me to tell you all the reasons why it won't work
<didrocks> I think it has something to do with apparmor and switching profile
<didrocks> like encapsulating a profile in a profile
<jdstrand> even if that were fixed, there would be something else
<jdstrand> there are like 20 things
<jdstrand> I'm telling you-- you aren't the first person to try this :)
<jdstrand> it is unsupported
<didrocks> as I'm not the first person, I think there are valid use cases :)
<didrocks> and if we tell snappy is the future of ubuntu, we should maybe think of a way of supporting this
<jdstrand> it isn't a valid use case-- apps aren't supposed to be unconfined
<didrocks> ok, how would you implement then a shell recorder
<didrocks> where you can record what happens on a screen
<didrocks> and then, show confinements of apps and such
<jdstrand> I want to be clear. I am saying that launching things from /snaps/bin/... will not be supported because the launcher does way too much and things break in all kinds of ways if the launcher launches the launcher
<jdstrand> there will be an interface available for people to use other snaps' bits
<jdstrand> that interface just won't be via /snaps/bin (it can't be)
<jdstrand> that interface is not defined atm
<didrocks> that doesn't cover my use case though, right?
<didrocks> like recording a talk
<didrocks> and having people having access to the shell commands that were ran
<jdstrand> I don't know what interfaces will be supported. I'm only saying that launching apps via /snaps/bin won't be. the future may have another mechanism
<jdstrand> today, you can launch stuff from /snaps/<other snaps>/current/path/to/whatever
<jdstrand> that isn't going to be confined though
<didrocks> right, however, that is an implement detail
<jdstrand> no it isn't
<didrocks> and doesn't show up confinement as intended here
<didrocks> (and confined by this snap confinement)
<jdstrand> your use case is not currently supported, sorry
<jdstrand> when the interfaces work is landed more fully, you can request a new interface to do what you want
<didrocks> yeah, I just feel those is dismissed and not going to be supported, which worries me once we switch everything to snappy
<jdstrand> and the snappy devs can discuss it
<didrocks> so basically, that would be possible through an interface?
<didrocks> (technically)
<didrocks> sounds like a "superpower one"
<jdstrand> no
<jdstrand> I'm sorry, I have to go to a meeting
<didrocks> "no" -> not possible? /me is puzzled
<jdstrand> the way the launcher works, it cannot launch itself
<jdstrand> you have a superpower one with unconfined, but the launcher will fail'
<didrocks> sounds like I should bring this use case on the ML and see if something can be discussed/planned
<jdstrand> snaps driving other snaps is what you want
<didrocks> yeah
<didrocks> a "shell" interface basically
<jdstrand> and that isn't supported in the manner you are trying to implement
<jdstrand> don't go to the mailing list yet
<jdstrand> let the interfaces stuff all land and then discuss
<jdstrand> if you bring it up now no one will be able to do anything about it
<jdstrand> what you are asking for is weird though
<didrocks> ok, I'll be patient. Quite frustrating though that my first demo snap for developers were already this vlc bug/systemd/snappy that we couln't debug
<jdstrand> you are asking for a completely unconfined shell via a snap
<didrocks> so I fallbacked to this (I need an demo without any hw and such)
<jdstrand> why not just login since you have an unconfined shell?
<didrocks> if you tell me how I can run that app directly installable for users on the system, yeah, I don't have any issue :)
<jdstrand> what you can do is ship a snap (fine), then launch a script in /snaps/<your snap>/current/... directly via your login shell rather than via /snaps/bin
<didrocks> or if we install by default screen recording capability in snappy
<didrocks> yeah, sounds like a workaround though
<jdstrand> dude :)
<didrocks> I'm just coming up with a real snap app and trying to figure out how it can work on this world :)
<jdstrand> I'm trying to tell you what you can do now and later you can request screen recording when people are ready to accept interface request
<jdstrand> s
<jdstrand> it isn't a real app snap
<jdstrand> you are totally violating a basec tenant of snappy
<didrocks> why, it's not? those kind of functionalities are valid and already running on ubuntu though?
<jdstrand> you must be unconfined (strike 1) and you must launch arbitrary commands from other snaps (strike 2)
<jdstrand> ubuntu core is not a replacement for classic ubuntu
<jdstrand> it is a whole different thing
<didrocks> when it's ubuntu personal, it's all snaps though
<didrocks> from what I understood
<jdstrand> and no snap is allowed to execute arbitrary other snaps :)
<jdstrand> snaps are isolated
<jdstrand> there will be controlled ways to provide other access
<didrocks> but we let bash from the ubuntu core snap, doing it though :p
<didrocks> as long as it's discussed and there is a plan, I'm fine
<didrocks> jdstrand: thanks for answering (and confirming) the no support for now though :)
<dduffey> Does someone have a Snappy 16.04 based image up and running and let me know what version of docker is included?
<kgunn> dduffey: is xenial from mar 25 ok?
<noizer> Is it possible to do some manual test into a snap?
<kgunn> dduffey: ubuntu@localhost:~$ snap find docker
<kgunn> Name             Version             Summary
<kgunn> docker.canonical 1.6.2.005-16.04.1-1 Docker
<dduffey> kgunn, yeah, thanks
<noizer> So i can execute some things into my snap for some test. Because its very slow to rebuild it all the time
<kgunn> noizer: i think the only way to do this now is something like....
<kgunn> unsquashfs foo.snap
<kgunn> cd squashfs-root
<kgunn> snappy build
<didrocks> jdstrand: so, I did try (full of hope ;)) /snaps/terminal-recorder-demo.sideload/current/record-terminal for instance, but then, whatever snap I'm running like (hello-world.echo), I'm getting a "failed to create user data directory. errmsg: Permission denied"
<didrocks> jdstrand: any idea?
<noizer> kgunn ok I will try it
<joc_> kyrofa: i would like to discuss the python problems i was having a bit more, see if i can work out how to handle build-packages etc
<didrocks> jdstrand: ah got it, snappy error message isn't accurate, but fixed it :)
<jdstrand> that is a different bug. I imagine ~/snaps was created when running a command as root. there is an open bug on that
<ZerownZ> yo''ll guys I have fear from you because you all are burro
<didrocks> jdstrand: yep, that was it :)
<morphis_> jdstrand: how far did you guys come with the new security/interfaces/plugs/ports/.. stuff?
<mvip> didrocks yt?
<jdstrand> morphis_: the move to replace old-security/caps are all in accepted PRs. they need to land and I was told today by mvo that the state engine changes need to land after that. I'm told in a few days
<jdstrand> morphis_: in other words, sit tight still
<morphis_> jdstrand: sounds good, so earlier next week it should be done?
<jdstrand> I hope so. I'm not driving those landings, but that is my understanding
<noizer> kgunn: Does it need to build?
<kgunn> noizer: yes this is my understanding...i only knew of this b/c i had asked the same question... so that method is at least a little faster than building on a host then copying over
<noizer> kgunn: How can i test it when i build it?
<didrocks> mvip: in some meetings, mind talking tomorrow?
<kgunn> noizer: not sure what you are trying to do, but you would make sure to stop your service, install your new one, start your service
<elopio> good morning
<elopio> fgimenez, sergiusens, kyrofa: I'm sorry I didn't make it to the standup.
<sergiusens> elopio, you also didn't see I moved it really early today ;-)
<sergiusens> elopio, it will happen in 2 hours approx
<elopio> so I'm on time!
<elopio> sergiusens: I need more details about that match check you want.
<elopio> I do the unsquash when there is no snapcraft.yaml, so do you mean you want a new unit test for the case without an argument?
<sergiusens> elopio, I'm going for the "else" part where you don't provide a SNAP_FILE
<sergiusens> elopio, to make sure name, version matches that of what we want to upload
<kyrofa> Hey sergiusens elopio
<elopio> sergiusens: like this? https://paste.ubuntu.com/15561413/
<sergiusens> elopio, yeah, without the typos ;-)
<sergiusens> kyrofa, hello
<elopio> taking out the typos is taking out the soul.
<wililupy> question: If I have kernel modules source code, do I need to precompile them and then add them to my kernel-device-trees or can I have it compile during the snapping process?
<elopio> pindonga: do you know if something changed on staging? I can't log in anymore:
<elopio> https://paste.ubuntu.com/15561995/
<elopio> oh, he's away. beuno ^
<beuno> >> nessita
<beuno> elopio, I've seen a bunch of issues with ssl certs on staging services today
<beuno> verterok might also have a clue
<verterok> o/
<verterok> elopio: ssl cert expired, working on fixing it ATM
<elopio> verterok: thank you!
<elopio> sergiusens: kyrofa: vila: ^ that blocks our landings.
<kyrofa> Uh oh
<verterok> should be solved shortly
<elopio> kyrofa: if we are in a hurry, we can land if the autopkgtest fail only on the login test. But I think we are not in a hurry.
<kyrofa> elopio, nah, should be good as long as people are aware :)
<nessita> otp but what verterok said
<verterok> elopio: try now please
<elopio> verterok: um, now it's messier: https://paste.ubuntu.com/15562052/
<verterok> elopio: yeah 1'
<verterok> fat fingers :P
<verterok> elopio: ready, enjoy
<elopio> verterok: great!
<wililupy> If I want to add kernel modules to my kernel snap, how best do I do that?
<josepht> sergiusens: is it possible to alter the PATH via snapcraft.yaml, for git the subcommands are in libexec/git-core.  Or should I be moving those binaries into the snap's path rather than trying to alter the path?
<kyrofa> josepht, or write wrapper scripts
<sergiusens> josepht, or use organize
<josepht> sergiusens, kyrofa: thanks :)
<josepht> it's nice that 'organize' works for directories too
<kgunn> robert_ancell: hey, sorry to pester, i just know you'll know :)
<kgunn> but if i've 2 of the same package installed
<kgunn> and i wanna toggle to the other version, what do i do?
<robert_ancell> kgunn, two versions of a snap?
<kgunn> e.g. i manually installed a deb from mvo
<kgunn> well...it's a deb
<kgunn> ubunt-core-launcher
<kgunn> robert_ancell: actually snaps i totally understand :)
<kgunn> i figure there's some dpkg -something i can do
<robert_ancell> kgunn, you can't have two versions of a .deb installed AFAIK - do the packages have different names?
<robert_ancell> kgunn, oh, do you mean revert to the archive version?
<kgunn> robert_ancell: yessir
<kgunn> like so
<robert_ancell> kgunn, you can do "apt install package=version" if you know the version from the archive
<kgunn> ubuntu-core-launcher:
<kgunn>   Installed: 1.0.23~mvo1
<kgunn>   Candidate: 1.0.23~mvo1
<kgunn>   Version table:
<kgunn>  *** 1.0.23~mvo1 100
<kgunn>         100 /var/lib/dpkg/status
<kgunn>      1.0.22 500
<kgunn>         500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
<kgunn> ah
<kgunn> thanks robert_ancell
<robert_ancell> or if it's a PPA you want to remove, you use ppa-purge to do that automatically
<kgunn> nope, not a ppa
<kgunn> i just thot maybe apt might not be cool with it
<kgunn> since i manually installed dpkg -i style
<robert_ancell> I've been meaning to find a command to apt install package=version-in-archive becuase surely it must exist
<robert_ancell> But it's normally easy enough to find the version you want
<moul> farblue, I work at Scaleway, I'm also interested if someone here had success with snappy on Scaleway (arm or x86_64) so I can package an image for everyone
#snappy 2016-03-31
<wililupy> Question: I'm trying to build a kernel snap from Kernel Source 4.5 and I need to build custom kernel modules for some drivers. I have successfully compiled the kernel on my build machine, built the headers, and compiled the drivers, but how do I do all of this using Snapcraft?
<wililupy> ...helllooo...
<stevebiscuit> wililupy: it's night time for a lot of the snappy people
<wililupy> yeah, I figured. I'm having issues building a kernel snap for a vendor, and was hoping to get some guidance.
<dholbach> good morning
<zyga> jdstrand: ping
<asac> sudo is broken now in classic?
<asac> (classic)ubuntu@localhost:~$ sudo apt-get install snapcraft bzr
<asac> sudo: no tty present and no askpass program specified
<asac> guess related to https://bugs.launchpad.net/snappy/+bug/1564316
<ubottu> Launchpad bug 1564316 in Snappy "classic dist-upgrade fails on sudo and tzdata..." [Critical,New]
<asac> e.g. to the upgrade that came in
<asac> https://bugs.launchpad.net/snappy/+bug/1564369
<ubottu> Launchpad bug 1564369 in Snappy "sudo broken in latest classic" [Undecided,New]
<asac> mdeslaur: ^
<asac> anything you can think of being wrong with your sudo upload?
<mdeslaur> asac: not off hand, no. needs investigating
<asac> its hard blocker on developing snappy
<asac> or on snappy
<asac> anyway, lets see if one of snappy folks gets on i
<asac> t
<asac> mdeslaur: no complains from normal ubuntuf olks?
 * asac doesnt have rthe latest sudo yet on xenial desktop and wonders if i should rather not upgrade
<mdeslaur> asac: nope, works fine on regular desktop
<asac> ok let me upgrade
<asac> :)
<asac> lets hope you are right
<asac> mdeslaur: were there any snappy changes in your merge?
<asac> or in the version that we had before :)
<mdeslaur> there's nothing snappy-specific in the sudo package, no
<asac> ok
<asac> odd
<mdeslaur> do you get any apparmor denials?
<asac> lets wait for snappy crew to come in
 * ogra_ sees the same on a rpi here
<mdeslaur> what's the output of "tty"
<ogra_> (classic)ubuntu@localhost:~$ tty
<ogra_> not a tty
<ogra_> (classic)ubuntu@localhost:~$
<mdeslaur> well, there you go
<ogra_> well, that was guessable from the error :P
<mdeslaur> and downgrading sudo works?
<mdeslaur> did you get a new glibc too?
<jdstrand> mdeslaur: fyi, 'snappy shell classic' does not run under apparmor (it is just a command to get into an ubuntu chroot)
 * ogra_ only just did "snappy enable-classic" ... this was a fresh install
<ogra_> you have to ask asac for an upgrade log
<jdstrand> bug #1564316 has the upgrade log
<ubottu> bug 1564316 in Snappy "classic dist-upgrade fails on sudo and tzdata..." [Critical,New] https://launchpad.net/bugs/1564316
<ogra_> ah
 * jdstrand notes he hasn't tried any of this yet
<jdstrand> I wonder if it is the pt_chown removal
<ogra_> well, i wonder why it mounts /etc/sudoers at all
<asac> we cnanot downgrade
<asac> i had to install fresh
<asac> because dist-upgrade failed
<asac> because sudoers cannot be written on snappy
<asac> ogra_: it does that so you can sudo apt-get install
<ogra_> yeah, it shouldnt bind mount it
<asac> we could have a copy
<asac> sure
<asac> think thats mvos work
<ogra_> why ?
<asac> just said... think we could create a copy :)
<ogra_> the relevant info isnt in there
<ogra_> on snappy
<asac> so i remember initially in classic you couldnt sudo apt-get install
<asac> then mvo landed something
<asac> maybe it was this :)
 * jdstrand is unable to enable classic
<ogra_> the relevant file is /etc/sudoers.d/90-cloud-init-users
<asac> jdstrand: it works well
<jdstrand> Get https://images.linuxcontainers.org/meta/1.0/index-system: dial tcp 192.99.34.219:443: i/o timeout
<asac> sudo snappy enable-classic
<asac> :)
<asac> oh we still use those images
<asac> heh
<ogra_> not /etc/sudoers
<jdstrand> heh, I know, except not :)
<asac> thast a critical bug too
<ogra_> yes :(
<asac> lets put bets on how likely this is still in when we release :)
<asac> anyway
<ogra_> well, we need an arm64 image at least
<asac> jdstrand: just try again
 * jdstrand has tried 8 times
<asac> its amateur server that probably will come back
<asac> :P
 * jdstrand keeps trying
<asac> (sorry for being ironic)
<jdstrand> ah, the 9th time's the charm
<asac> see
<asac> CDN
<asac> i am sure though its your internet net
<asac> :P
<asac> cool thanks for trying
<jdstrand> I can confirm the bug
<asac> great... that makes it three :)
<ogra_> sudo umount /writable/classic/etc/sudoers
<ogra_> sudo mount --bind /etc/sudoers.d /writable/classic/etc/sudoers.d
<ogra_> then try again
<asac> that works?
<ogra_> should work
<asac> the upgrade or the sudo?
<asac> ok
<ogra_> sudo
<asac> upgrade would work too i guess
<ogra_> yeah
<asac> or at least less likely to conflict aka break
<jdstrand> I can confirm ogra_'s commands fix it
<jdstrand> it is still not a tty, but sudo works
<asac> ogra_: added it as workaround giving credits to you
<asac> ogra_: https://bugs.launchpad.net/snappy/+bug/1564369
<ubottu> Launchpad bug 1564369 in Snappy "sudo broken in latest classic" [Critical,New]
<mdeslaur> huh, that's odd
<asac> think now we can wait for mvo to come back unless you guys know what to do
<ogra_> mdeslaur, nah, not odd
<ogra_> mdeslaur, /etc/sudoers lives in a squashfs and then gets bind mounted into the container
<asac> bah
<ogra_> so it is ro underneath
<asac> i cannot save the workaround
<asac> launchpad!!!
<asac> posting as comment instead then
<asac> also not working :(
<ogra_> re-login ?
<asac> why? i used lp a few minutes ago
<asac> WORKAROUND (credits to ogra):
<asac>   ubuntu@localhost:~$ sudo umount /writable/classic/etc/sudoers
<asac>   ubuntu@localhost:~$ sudo mount --bind /etc/sudoers.d /writable/classic/etc/sudoers.d
<ogra_> heh
<jdstrand> ogra_: that makes sense for 'sudo apt-get upgrade' in the chroot failing, but not sure how it explains sudo not working in a fresh 'enable-classic'
<asac> well needed to paste it somewhere so it doesnt get lost :)
<ogra_> jdstrand, yeah, thats indeed a bit weird, especially the tty bit
<jdstrand> but tty returns 'not a tty' before and after your workaround
<jdstrand> that doesn't seem to be the issue...
<mdeslaur> what's in the file in the sudoers.d directory?
<asac> o/
<asac> ffox is king of lp
<asac> mdeslaur: two files
<jdstrand> mdeslaur: with ogra's bind mount, it is empty
<ogra_> shouldnt
<jdstrand> sorry, I lied
 * ogra_ waits for apt-get install snapcraft to finish
<jdstrand> I wasn't root do didn't get bash completion
<asac> mdeslaur:
<asac> root@localhost:/home/ubuntu# cat /etc/sudoers.d/10-ubuntu-core-secure-path
<asac> Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snaps/bin"
<asac> root@localhost:/home/ubuntu# cat /etc/sudoers.d/90-cloud-init-users
<asac> # Created by cloud-init v. 0.7.7 on Thu, 31 Mar 2016 11:23:15 +0000
<asac> # User rules for ubuntu
<asac> ubuntu ALL=(ALL) NOPASSWD:ALL
<asac> and README
<asac> yay upgrading xenial proper also failed ;)
<mdeslaur> ah, no the NOPASSWD alleviated the need for a tty
<asac> cups-browsed :0
<ogra_> oh, indeed !
<asac> not sudo... so no panic :)
<asac> but why did this change?
<asac> where did we change something?
<asac> before we had sudoers bindmounted
<mdeslaur> it didn't change, it just never properly handled a sudo package upgrade properly
<asac> wait
<asac> tahts not true
<asac> i install fresh classic
<asac> which just downloads a prebuilt image and unpacks
<asac> no uptgrade etc.
<asac> and then i got the sudo problem
<asac> upgrading wasnt possible at all
<asac> so its not upgrade issue
<jdstrand> yeah, that is what I was saying
<asac> at least not an upgrade on my side
<ogra_> yeah, there must still be something wrt tty
<asac> something changed for sure
<asac> somewhere :)
<mdeslaur> hrm
<jdstrand> I wonder if 10-ubuntu-core-secure-path isn't being copied into place with enable-classic or something
<jdstrand> so then you need a password
<ogra_> remove the bind mount and check from outsuide the container ;)
<asac> maybe mr. graber though hacked up his container tarball ... just so we stop using those unsupported things
<ogra_> ubuntu@localhost:~$ sudo ls /writable/classic/etc/sudoers.d
<ogra_> README
<ogra_> but thats not the issue
<jdstrand> yeah
<ogra_> there is something wonky about ttys
<jdstrand> ogra_: I think that explains it
<ogra_> (classic)ubuntu@localhost:~$ tty
<ogra_> not a tty
 * ogra_ has a non upgraded container, gimme a minute
<jdstrand> ogra_: we aren't bind mounting /etc/sudoers.d so 90-cloud-init-users isn't getting in there
<ogra_> ubuntu@localhost:~$ mount|grep sudoers
<ogra_> /dev/mmcblk0p2 on /etc/sudoers.d type ext4 (rw,relatime,data=ordered)
<ogra_> /dev/loop0 on /writable/classic/etc/sudoers type squashfs (ro,relatime)
<ogra_> thats with the old classic container
<jdstrand> ogra_: but, why is 90-cloud-init-users there at all on my system...
<ogra_> ubuntu@localhost:~$ sudo ls /writable/classic/etc/sudoers.d/
<ogra_> README
<ogra_> ubuntu@localhost:~$ snappy shell classic
<ogra_> ...
<ogra_> (classic)ubuntu@localhost:~$ tty
<ogra_> not a tty
<jdstrand> like, why is the ubuntu user not supposed to enter a password?
<asac> jdstrand: we use cloud-init still no?
<ogra_> (classic)ubuntu@localhost:~$ sudo ls
<ogra_> [sudo] password for ubuntu:
<ogra_> ...
<ogra_> so here it works
<asac> jdstrand: i think we never ask for password in snappy for sudo?
<asac> asked
<ogra_> despite not having a tty
<asac> hmm
<asac> not true indeed
<jdstrand> asac: sure, but haven't we always required a password for sudo?
<asac> so in classic we dont
<ogra_> in classic we obviously did
<jdstrand> I'm talking outside the classic shell
<ogra_> outside we dont
<asac> ogra_: we asked for pass?
<ogra_> yeah
<asac> oh :)
<ogra_> see above
 * asac old
<ogra_> thats a container from about a week ago
<ogra_> not upgraded
<asac> so what is expected experience? i assume we want same behaviour for sudo in and outside container?
<ogra_> but even there tty says there is no tty
<asac> e.g. either pass or not?
<jdstrand> meh, even 15.04 has 90-cloud-init-users
<ogra_> inside the classic container ?
 * ogra_ has never tried classic on 15.04 
<asac> there isnt classic
<ogra_> right
<asac> on 15.04
<asac> cloud-init is our first boot tool
<ogra_> i thought i missed something
<asac> it has always been there
<jdstrand> ogra_: not what I meant. I got distracted by the fact that there is no password prompt for sudo at all in snappy
<ogra_> sadly, yeah :PO
<ogra_> jdstrand, thats a cloud init config thing
<jdstrand> ogra_: is that something with udf options?
<ogra_> nope, something with the cloud init defaults
<jdstrand> cause jeez, I have two live systems with this
<ogra_> /var/lib/cloud/seed/nocloud-net/user-data and /var/lib/cloud/seed/nocloud-net/meta-data are pre-created
<ogra_> and iirc theer is an option you can set in user-data to make it ask
 * jdstrand adds this as a todo to discuss with mvo
 * jdstrand edits this file on his live systems
<jdstrand> ogra_: ok, so, back to asac's issue
<ogra_> the ubuntu user is in the sudp group by default so dropping the 90-cloud-init-users would be fine
<jdstrand> ogra_: I guess something in earlier image worked and something in latest doesn't
<jdstrand> ogra_: I'm on 16.04+20160321.17-27 on the host here
<jdstrand> if I enable-classic and shell classic, I have the no tty issue
<ogra_> you could try sideloading a newer ubuntu-core (breaks upgrades though)
<jdstrand> ogra_: your bind mount papers over the underlying issue I think
<ogra_> it does
<jdstrand> but at least it allows people to keep working, so that's good :)
<jdstrand> ogra_: I can say that /usr/lib/pt_chown does not exist in the container
 * jdstrand wishes he had an earlier classic
<ogra_> wow
<jdstrand> /usr/lib/pt_chown is not supposed to exist btw
<ogra_> looking at the cloud-init docs it seems thats actually a default
<jdstrand> ogra_: right, I knew that is what they set
<ogra_> how awful
<jdstrand> I am a lot less sure that is the correct default for snappy
<jdstrand> ogra_: I forget their rationale. smoser could certainly remember
<ogra_> he's on vacation :)
<jdstrand> ugh
<ogra_> but i guess there is a reason and there were discussions ... so i wont bother :)
<jdstrand> that is why I want to bring it up with mvo rather than filing a bug, doing the mailing list, etc
<jdstrand> but it's a trap!
<jdstrand> :)
<ogra_> hah
<jdstrand> I have to know I need to edit that file
<jdstrand> I don't think the snappy docs mention this anywhere
<zyga> jdstrand: hey
<ogra_> you could boot with cloud-init=disabled on the kernel cmdline ;)
<jdstrand> zyga: hey
<ogra_> (though then you end up without ssh keys ... iirc thats the only thing we need cloud-init for nowadays)
<zyga> jdstrand: I posted some cleanups and seccomp
<zyga> jdstrand: and I'm about to post dbus
<jdstrand> zyga: I was actually going to respond to your ping and then all that ^ came up at the same time
<zyga> jdstrand: no worries :)
<zyga> jdstrand: I already forgot what I wanted then
<jdstrand> zyga: yeah, I was going through the emails for that
<jdstrand> ogra_: ah, so, interesting. I happened to have a vm with a previous enable-classic that hasn't been upgraded
<jdstrand> (classic)ubuntu@snappy-20160324-amd64:~$ tty
<jdstrand> not a tty
<jdstrand> (classic)ubuntu@snappy-20160324-amd64:~$ sudo uptime
<jdstrand> [sudo] password for ubuntu:
<jdstrand>  12:21:46 up 0 min,  1 user,  load average: 0.43, 0.11, 0.04
<ogra_> yeah
<ogra_> thats what i said above
<jdstrand> so, no tty but it still works
<jdstrand> password prompting works that is
<ogra_> the bind mounts are all the same on both
<jdstrand> there is no /usr/lib/pt_chown there either, so that should be unrelated
<ogra_> so nothing changed wrt /dev/pts or so
<jdstrand> I can confirm that
<jdstrand> /dev/ptmx is 0666 and nothing in /dev/pts
<jdstrand> I suspect we actually want to mount /dev/pts/ptmx though
<ogra_> yeah
<ogra_> ubuntu@localhost:~$ sudo mount --bind /dev/pts /writable/classic/dev/pts
<ogra_> ubuntu@localhost:~$ snappy shell classic
<ogra_> ...
<ogra_> (classic)ubuntu@localhost:~$ sudo ls
<ogra_> [sudo] password for ubuntu:
<ogra_> ...
<ogra_> ubuntu@localhost:~$ sudo umount /writable/classic/dev/pts
<ogra_> ubuntu@localhost:~$ snappy shell classic
<ogra_> (classic)ubuntu@localhost:~$ sudo ls
<ogra_> sudo: no tty present and no askpass program specified
<ogra_> so yes, that fixes it properly
<jdstrand> yeah, so bind mounting /dev/pts /writable/classic/dev/pts 'solves' the tty issue (I suspect we actually want a devpts newinstance,ptmxmode=0666,gid=5 mount instead of a bind mount though
<jdstrand> )
<ogra_> in any case something inside the snappy enable-classic chain ...
<jdstrand> yeah
<jdstrand> ok, I'm wandering off to look at zyga's PRs
<zyga> jdstrand: cool :)
<zyga> jdstrand: ah, I wanted to ask about dbus and developer mode
<zyga> jdstrand: do we have plans to support anything similar for dbus?
<jdstrand> zyga: I'll first say that I'm fairly in the dark wrt all things developer mode. All I know about it is that it is supposed to be per-snap complain mode for the security sandbox
<zyga> jdstrand: yes, that's accurate so far
<jdstrand> zyga: with that said, I think it is sufficient to have apparmor in complain mode for dbus
<zyga> jdstrand: ok
<jdstrand> ie, let's not fiddle with dbus bus policy
<zyga> jdstrand: we don't have any dbus snippets yet (nothing uses it) but I suspect we'll need something fairly soon
<jdstrand> zyga: I get pinged by the bluez, nm, pulse, mir, etc guys all the time and been telling them once this interfaces (and really the state engine) stuff all lands, we can circle back to them
<jdstrand> zyga: so very soon you and I will have an opportunity to check out the dbus interface
<jdstrand> zyga: I just looked at https://dbus.freedesktop.org/doc/dbus-daemon.1.html. dbus bus policy doesn't (currently) have a concept of complain mode. it is either deny or allow
<zyga> ok, that's good to know, thansk
<zyga> I'll put this into the code as a note
<jdstrand> zyga: so don't do anything for developer mode and dbus. I suspect a dbus service author is going to be just fine with tuning the bus policy as needed so long as we have apparmor in complain mode
<jdstrand> perhaps some day if it becomes a requirement dbus can be modified to allow but log (ie, support complain)
<zyga> jdstrand: I have one more issue (udev) but I wrote it down and we can discuss it when reviweing the patches
<jdstrand> zyga: I had some questions regarding udev, cgroups and the launcher that can probably wait until then. there is an interesting intersection of apparmor, udev and the launcher that we need to be careful about
<jdstrand> zyga: cause as it stands now, the launcher won't setup a cgroup if /var/lib/apparmor/clicks/%s.json.additional doesn't have a particular string
<zyga> _clicks_?
<jdstrand> yes
<zyga> that's not good
<zyga> given the time frame, do we have hands on the launcher?
<jdstrand> my hands are on the launcher all the time lately
<jdstrand> I'm not sure what you are referring to though
<jdstrand> I'll put it another way
<zyga> ah, I wasn't sure, I recall you were transitioning but were still busy as a manager
<jdstrand> I'm fine with updating the launcher, but it is going to need to make a choice to apply a cgroup or not
<jdstrand> zyga: I am functioning as interim manager. people have given me some space, but it is more like I have 1.5 jobs atm
<jdstrand> zyga: anyway, historically, as you know, constantly recompiling the apparmor profile because a usb device came up differently or was unplugged, etc, etc was not viable. so we came up with the idea to add devices to an app-specific cgroup (fine)
<zyga> yes
<jdstrand> zyga: the idea was then, when a device was assigned to the snap, apply lenient apparmor policy for /dev, and then just let device cgroups handle the mediation (also fine)
<zyga> right
<jdstrand> zyga: so, then docker came along and broke when it ws run under a cgroup (iirc)
<jdstrand> so the idea was, have the launcher conditionally setup the cgroup *if* it detected the lenient apparmor policy
<jdstrand> that lenient policy was applied to /var/lib/apparmor/clicks/%s.json.additional
<jdstrand> so the launcher would look in there
<zyga> ah
<zyga> man,
<jdstrand> I think what we could do instead is look in the udev db to see if any devices are assigned
<jdstrand> and make that the conditional
<zyga> I'm inclined to agree
<zyga> but I'd like to sit down and write down variou things we need to and can do and see if it all adds up
<jdstrand> sure
<jdstrand> cause the thing is, you'll want an apparmor snippet for the lenient /dev policy on device assignment since the launcher isn't going to modify policy
<jdstrand> device grant*
<jdstrand> and on revoke, remove that
<jdstrand> zyga: I'll add a card for my to adjust snappy_udev_setup_required() to check udev for assignments
<jdstrand> s/my/me/
<jdstrand> zyga: but I'll wait to act on it til I hear back from you
<jdstrand> I have several MPs for the launcher that are in play, so I can keep moving forward
<jdstrand> this area is admittedly too twisty, but whenever we get apparmor profile composition, we can get rid of this
<jdstrand> (there is a bug on this btw)
<jdstrand> that is almost certainly not a 16.10 thing
<jdstrand> so we'll need to get this right
<jdstrand> zyga: ^
 * jdstrand makes sure profile composition is in the planning doc tyhicks and I are putting together
<zyga> jdstrand: when you say it is not a 16.10 thing, do you mean it needs to be done for 16.04 or that it will take more time than 16.10?
<jdstrand> zyga: I mean I doubt it will even be done for 17.04 (yes, *17*)
<jdstrand> we need to live with this udev/cgroup stuff for a while yet
<zyga> ouch
<zyga> ok
<josepht> what is the preferred way on 16.04 to do initialization (think add user to extrausers, add ssh public keys, etc.) for a snap?
<zyga> jdstrand: you should join our standups
<zyga> jdstrand: perhaps not today (too late) but I think it would be useful
<jdstrand> if now is too late, then every day is too late
<jdstrand> I started very early today. my normal start of day is 9 minutes ago
<ogra_> josepht, you cant
<kyrofa> Good morning
<zyga> jdstrand: we just started, I think you could still join reguarly
<popey> should webdm start on boot? if not, how do I start it, and what port does it run on?
<ogra_> (and you shouldnt, everything inside a snap will run as root or if it is a user executable binary, as the user that execs it)
<beowulf> popey: snappy install webdm, then it should be on webdm.local:4200
<ogra_> popey, it should (but there seem to be issues with platforms that use WLAN) ... port is 4200
<popey> aha!
<popey> hm, all wired here. works on my pi 2 but not pi3, your image ogra_
<popey> didn't start it seems
<popey> I get no updates on that pi3 image either, wondering if I should expect any?
<jdstrand> zyga: fyi, https://bugs.launchpad.net/ubuntu/+source/ubuntu-core-launcher/+bug/1564401
<ubottu> Launchpad bug 1564401 in ubuntu-core-launcher (Ubuntu) "launcher does not apply cgroups on 16.04" [High,Triaged]
<zyga> jdstrand: since you already look at that area
<zyga> jdstrand: how would it work if two separate apps/snapps wanted to get a device in their cgroup?
<ogra_> popey, the one from my people.u.c ?
<zyga> jdstrand: the rules that we'd make today, from what I know about udev, would overwrite one another
<jdstrand> zyga: I assigned that to me already
<ogra_> popey, i think that still has sideloaded bits ... which would prevent automatic upgrades
<zyga> jdstrand: I might be getting this wrong
<zyga> jdstrand: but just something raised my eyebrow yesterday
<jdstrand> zyga: I'm not a udev expert, but would hope that the rules were written such that they would be cumulative. ie, a device has multiple tags. so a device is tagged with foo and bar, but not baz
<zyga> jdstrand: well, now there are no rules
<popey> ogra_: yeah, it's all listed as sideloaded
<jdstrand> zyga: I suggest asking pitti about that part (he came up with this snappy tagging scheme)
<zyga> jdstrand: but as soon as we want to write some, the simplistic snippets might require parsing/processing to really express this
<zyga> jdstrand: ok, noted
<jdstrand> zyga: that said, I think for 15.04 the decision was a device could only be assigned to a single snap
<zyga> jdstrand: mmmmmm
<zyga> jdstrand: that's good to know
<zyga> jdstrand: anyway, I've got this written down and I'll explore this further with udev code soon
<jdstrand> zyga: we need mvo and pitti to comment-- I was only on the periphery of that and reviewed the code
<ogra_> popey, right, so you could only update it manually ... (or re-build a fresh image witgh all bits from the store)
<popey> is there a plan to make a working image?
<ogra_> once i find the time
<ogra_> or once elopio gets the auto-uploading of snaps to work
<popey> ij
<ogra_> whatever happens first :)
<vila> elopio: https://github.com/ubuntu-core/snapcraft/pull/414 failed the example tests again, not sure I understand what is going on there, can you help ?
<josepht> ogra_: I'm trying to make a git snap.  It sounds like I'd only be able to do a basic read-only mirroring server or an HTTP[S] authenticated push/pull server by pulling in a static web server and somehow managing an application level authentication scheme.
<ogra_> josepht, yeah, i fear ... unless jdstrand can tell you a method to use users from the actual system in snaps
<ogra_> (i have a similar prob trying to package dovecot since a while)
<josepht> ogra_: I still wonder about initialization.  Perhaps I'm going at it wrong and should make my service idempotently setup it's directory structure, clone repos, etc.
<jdstrand> snappy doesn't currently provide access to the pam stack in this manner
<ogra_> package a bzr server instead, just needs sshd after all ;)
<zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/767 (dbus)
<jdstrand> niemeyer: hey, thanks for the merges. if there is anything for me to do in that card, please add me to it
<niemeyer> jdstrand: Thank you for the branches!
<niemeyer> jdstrand: I think some of the renames there make sense, but they are trivial and we can easily do on this side
<niemeyer> jdstrand: One thing I was just wondering which you might have some info on regards the "unity7" interface
<niemeyer> jdstrand: Is that unity7 or unity?
<niemeyer> jdstrand: In other words, do we expect unity7 software to talk to unity8?
<jdstrand> niemeyer: I chose unity7 to differentiate it from unity8 which would have completely different policy
<niemeyer> jdstrand: Why/how would it be different?
<jdstrand> unity7 is X and unity8 is mir. unity8 has things like content-hub, etc that unity7 doesn't. I was thinking unity8 is basically the existing touch policy whereas unity7 is something considerably more lenient
<zyga> jdstrand: remember that we can use "unity" as an interface and require "version" attribute to hide the nasty details
<jdstrand> I don't think they should be combined since we wouldn't want to give a designed for unity8 app the wide access required for unity7
<zyga> jdstrand: but then again we cannot yet require "unity version 7" on the consuming side
<jdstrand> zyga: ok, I actually didn't know that
<zyga> jdstrand: there's some support planned for $version: 7 (eg) on a plug
<zyga> jdstrand: but it's not 16.04 material
<zyga> jdstrand: but the snippets we hand out can easily look at attributes
<jdstrand> perhaps this is a refinement we can talk about once we are enforcing these interfaces and all the glue/etc is working?
<niemeyer> zyga: I'm not entirely sure it would make sense in the case described
<jdstrand> if you want to change it to 'unity', that's fine. we can add the version at a later date and if that doesn't pan out, add a unity8 separate from unity for that
<niemeyer> zyga: If indeed most software using one cannot use the other, there's little reason to munge them under a single name
<zyga> mmmm
<zyga> is that really true? I was under the impression that SDK apps work on both versions without modification
<niemeyer> zyga: It's not just a parameter (a path, a max speed limit, etc), but a different protocol altogether
<niemeyer> <jdstrand> unity7 is X and unity8 is mir.
<niemeyer> ?
<jdstrand> zyga: sdk apps may work without modification but the underlying systems in use are different
<zyga> jdstrand: right, that is true
<zyga> well, this was just a note that we have the ability, perhaps it doesn't makes sense to use it in this case
<jdstrand> and those underlying systems greatly change the access to the rest of the system
<jdstrand> sure
<jdstrand> we can discuss at a more appropriate time
<jdstrand> but, that is why I named it unity7
<niemeyer> jdstrand: Makes sense, thanks
<jdstrand> to differentiate between it and unity8. I envisioned unity7 is what I implemented and unity is unity8 down the line
<niemeyer> zyga: If the same software might use both, it's a question worth asking down the line.. today what we have is simpler
<jdstrand> but we can do unity as what is implemented and then decide if unity8 down the line vs unity with version if you prefer
<niemeyer> jdstrand: Yeah, "unity" being the new one makes sense
<zyga> yeah, let's get basics working now
<zyga> and polish this later if there's something we want to change
<niemeyer> jdstrand: Also, just for the record, note the interface might return different snippets (different policy) depending on a parameter of the interface
<niemeyer> jdstrand: Not that we should change this now, but it's a tricky that will come handy often
<niemeyer> s/tricky/trick
<jdstrand> niemeyer: ack
<jdstrand> niemeyer: curious on this point-- right now I thought we would have this
<jdstrand> apps:
<jdstrand>   foo:
<jdstrand>     plugs: [unity7]
<jdstrand> but what you are suggesting means:
<jdstrand> apps:
<jdstrand>   foo:
<jdstrand>     plugs: [unity]
<jdstrand> plugs:
<jdstrand>   unity:
<jdstrand>     interface: unity
<jdstrand>     version: 8
<jdstrand> is that right?
 * jdstrand has a followup question if it is
<zyga> jdstrand: (even without the interface: unity) (that's the default)
<niemeyer> jdstrand: That's right
<jdstrand> zyga: ok, I have two things I am getting at here. 1) the top-level 'plus' is not normally needed unless you are tweaking parameters and 2) if there are tweakable parameters (like version), is there a default (eg, '8') so that you don't need the top-level 'plugs'?
<niemeyer> jdstrand: Or, that's feasible, rather
<jdstrand> s/plus/plugs/
<zyga> jdstrand: there are no defaults yet
<niemeyer> zyga: Hm?
<zyga> niemeyer: no defaults for attributes
<niemeyer> zyga: The interface can trivially default to something
<niemeyer> zyga: "if version is unset, use 8"
<zyga> jdstrand: if the interface requires that attribute to be present (say) then it would not validate
<zyga> jdstrand: sure
<zyga> er
<zyga> niemeyer: ^ sure
<jdstrand> ok
<jdstrand> that might get interesting (I'm not blocking or anything, just observing)
<zyga> niemeyer: the interface can do that; what I meant to say is that we're not using this capability yet
<zyga> but it sure can, in Sanitize()
<niemeyer> zyga: That's not what jdstrand asked
<niemeyer> zyga: He asked whether it was possible.. yes, it's possible
<jdstrand> cause in the case of unity, version 7 is 'unsafe' and version 8 is 'safe' (whatever safe/unsafe ends up meaning in terms of store/snappy/etc notwithstanding)
<jdstrand> just mentioning that as something to think about with this sort of thing
<jdstrand> ok, I don't mean to distract. thanks! :)
<niemeyer> jdstrand: Right.. I think for the scenario we have at hand, your proposal is the easiest/cleanest
<jdstrand> cool
<niemeyer> jdstrand: the unity7 interface will likely just die a cold death
<jdstrand> hehe
<niemeyer> jdstrand: and "unity" will rule without all that extra complexity
<jdstrand> sounds great
<niemeyer> jdstrand: For your point (1) above, note that global interfaces are defined at the top level
<niemeyer> jdstrand: Without any per-app mentions
<jdstrand> sure
<niemeyer> jdstrand: to be clear, by global I mean "for all apps"
<jdstrand> you can do global plugs that are for all, or you can do per-app plugs
<niemeyer> Yeah
<jdstrand> I was mainly trying to get if you are doing per-app, you don't need the global if you are doing all defaults
<niemeyer> zyga, jdstrand: Question about the template clean up that is on the queue for review:
<niemeyer> +			// TODO: use modern variables when default template is compatible
<niemeyer>  +			// with them and the custom template is not used.
<zyga> yes?
<niemeyer> zyga, jdstrand: What's left to do about this?
<jdstrand> just have INSTALL_DIR
<jdstrand> remove the others for a future commit
<jdstrand> the idea is, those new variables should happen in the same commit as the policy changes
<niemeyer> jdstrand: Can you jump in with that?
<zyga> niemeyer: from my POV we need to patch the default template to use less variables (I"ll let jdstrand pick which) and commit this in one change as he just said
<jdstrand> sure
<zyga> niemeyer: then for legacy (old-security) we're covered - we can still use legacy variables and for all other cases we have a clean definition of what the policy depends on
<jdstrand> I'd like to wait until after we are using the interfaces code for generation and enforcement though
<jdstrand> ie, lets get all the interfaces and glue landed so it is doing stuff
<niemeyer> jdstrand: Sounds good
<jdstrand> then I can tweak the policy, etc
<niemeyer> jdstrand: Will add a card for that, thanks!
<jdstrand> I have a small queue of minor other updates. I'll add this to my list
<jdstrand> niemeyer: thanks! please assign it to me
<niemeyer> jdstrand: Will do, thank you
<jdstrand> zyga (and niemeyer): and to be clear about the launcher. I've got a number of things I'm working on: seccomp argument filtering, adding @complain, adding @deny, and fixing the cgroups issue on 16.04 we talked about earlier (LP: #1564401)
<ubottu> Launchpad bug 1564401 in ubuntu-core-launcher (Ubuntu) "launcher does not apply cgroups on 16.04" [High,Triaged] https://launchpad.net/bugs/1564401
<jdstrand> I have time to do these things, so you don't have to worry about them
<niemeyer> jdstrand: Thanks, certainly a relief
<niemeyer> zyga: #759 is ready for your attention again
<jdstrand> I even have a branch for arg filtering. that'll be a nice feature
<zyga> thanks, looking
<jdstrand> niemeyer: I also wanted you to know that I implemented and landed a change to the launcher that creates a devpts newinstance. I closed a card in some snappy trello board, but I feel like it might not be the board you are currently using
<jdstrand> niemeyer: regardless, that closed a hole in the confinement story that I really wanted addressed in 16.04
<jdstrand> niemeyer: just fyi for awareness
<niemeyer> jdstrand: Ah, nice!
<zyga> niemeyer: replied, have a look and tell me what to do about } issue
<jdstrand> morphis_: hey, I think the meeting you sceduled is premature
<niemeyer> zyga: I don't get the comment.. can you please expand on why that's not appropriate?  Starter for the conversation: the template has a curly brace in it, why are we taking it off?
<jdstrand> scheduled
<niemeyer> jdstrand: Your observation/input on that one would be welcome ^
<jdstrand> morphis_: I just had a meeting with jhodapp yesterday explaining things. and mentioned those things to kgunn, and awe, etc
<zyga> niemeyer: we take it off because this function returns the header of the full policy, then we inject any number of snippets and then the terminating }
<niemeyer> zyga: We take it off because we inject it again, yes.. why do we do that?
<zyga> niemeyer: to not remove } we'd have to know where to insert the snippets somehow
<zyga> niemeyer: the snippets have to be "in the middle" of the { }
<zyga> niemeyer: and there is no ### marker for where that is currently
<jdstrand> morphis_: can you sync up with jhodapp-- he has the whole story. the summary is: we can't do anything with bluez, nm, pulse, mir, etc until the interfaces/state engine stuff lands. it is close to landing (days). when it lands zyga and I will come knocking
<niemeyer> zyga: If only we had a variable system to do that.. :)
<zyga> niemeyer: yes but remember that this has to stay compatible with 3rd party templates
<jdstrand> I wanted to ask about that
<morphis_> jdstrand: did already sync with him, just wanted a pre-check so see if what we will get satisfies already the different bits we need
<zyga> niemeyer: I can easily define ###SNIPPETS### and replace it with the actual snippets. Then we don't have to parse the template in any way but then if anyone ships a custom policy it has to include that section.
<jdstrand> why are we supporting 3rd party templates? I thought we said that old-security/security-template was going away?
<zyga> niemeyer: and since we wanted to stay compatible with 15.04, I didn't do that by default
<morphis_> jdstrand: more technically sided talking, but fine if you don't have time, I think zyga can fill us in as well
<jdstrand> morphis_: it wasn't so much about time as the timing
<jdstrand> morphis_: if zyga thinks the timing is ok, that's fine (but note, the dbus bits are only under review right now)
<zyga> niemeyer: given the interfaces that are coming, is old-security something that will look relevant for 16.04?
<morphis_> jdstrand: I know that we're close to land this, but we still don't know what we really get when this lands, so just wanted to get an early heads up
<niemeyer> zyga: I'm not sure, to be honest.. perhaps we should close that down so we don't need to support that forever
<niemeyer> zyga: With the mechanism we have in place we can quickly cook new interfaces that support old logic
<niemeyer> jdstrand: What's your opinion on that one?
<jdstrand> zyga: in the meeting we had last month between you me and niemeyer we decided that old-security/security-override and old-security/security-policy must stay. old-security/caps and old-security/security-template could stay, but to use the interfaces code
<zyga> niemeyer: I think that doing ###SNIPPETS### as a mandatory thing is a quick and easy solution and is quite clearner than parsing the template
<jdstrand> zyga: as in, 'caps' just maps internally to plug the right thing and so does security-template. we don't read ubuntu-core-security files any more
<zyga> jdstrand: hmm, so we don't need custom apparmor policy in any way?
<zyga> jdstrand: (sorry not policy) custom base template?
<zyga> (woring is confusing sometimes)
<niemeyer> jdstrand: Right, but that implies having to parse third-party templates, which was zyga's point which you seemed to object about
<jdstrand> you misunderstand
<jdstrand> there are 4 directives:
<niemeyer> (I misunderstand too, I'm sure)
<jdstrand> old-security/caps: )possibly) support but with internal map to plugs
<jdstrand> old-security/security-template: (possibly) support but always use defaultTemplate
<jdstrand> old-security/security-override: support and adds to snippets
<jdstrand> old-security/security-policy: support for hand-crafted security policy
<zyga> ah
<zyga> yes, I misunderstood difference between template and policy
<jdstrand> the first two use ubuntu-core-security policy
<jdstrand> lets just get rid of old-security/security-template because we decided we don't want an unconfined template and that leaves only the default template
<jdstrand> it is your choice to keep old-security/caps, but if you keep it, map it to plugs under the hood. don't parse template policy groups from ubuntu-core-security
<niemeyer> jdstrand: What's the meaning of security-template again?  I misunderstand what it would mean to support it but force defaultTemplate usage (seems contradictory, so I probably misunderstand their meaning)
 * zyga feels the same, 
<jdstrand> old-security/security-policy would completely skip defaultTemplate. it probably needs support for snippets for interface grants
<zyga> we either respect the template given or we use default template
<jdstrand> niemeyer: in 15.04 you could specify a template from ubuntu-core-security
<jdstrand> let me back up
<jdstrand> in 15.04 policy was generated by picking a template and adding caps to it
<jdstrand> security-template was used to specify the template and caps was use to specify the caps
<jdstrand> in 16.04, policy is generated by adding interfaces to defaultTemplate
<jdstrand> so just make security-template go away
<jdstrand> in 15.04 there werre only two templates: default and unconfined
<niemeyer> Aha!
<jdstrand> unconfined was rarely used cause, well, it was unconfined and triggered manual review
<jdstrand> and we decided last month that if someone actually wanted unconfined in 16.04, they would use old-security/security-policy to handcraft a lenient policy (and also triggers manual review)
<zyga> I think I understand now
<niemeyer> jdstrand: and why did we ever feel the need to have security-policy?
<jdstrand> so there is no reason at all to support old-security/security-template in 16.04
<niemeyer> jdstrand: (vs. an override)
<jdstrand> niemeyer: old-security/security-override is not rich. it is easy to use. it is 'add this syscall' and 'add this file for reading'
<elopio> kyrofa: https://spi.canonical.com/assets/api-reference.html
<jdstrand> nessita: old-security/security-policy is raw security policy-- full apparmor, full list of seccomp. no templated policy
<jdstrand> niemeyer: ^
<jdstrand> nessita: sorry, nm
<niemeyer> jdstrand: Hmm
<elopio> kyrofa: and here are my notes for setting it up for ubuntu-core: http://pad.ubuntu.com/spi
<niemeyer> jdstrand: Okay.. thanks a lot.. have much better context now
<jdstrand> niemeyer: old-security/security-policy going forward is our escape hatch for when something must be done fast and interfaces aren't in place for it yet
<jdstrand> niemeyer: it will always trigger a manual review in the store and is not intended for normal use
<niemeyer> jdstrand: It's a dangerous one too
<jdstrand> oh yes
<niemeyer> jdstrand: Not in the sense you're thinking, though :)
<jdstrand> incredibly
<niemeyer> jdstrand: I mean it's dangerous because it's a cheap short cut for an otherwise well designed system
<jdstrand> niemeyer: well, yes, but time constraints...
<niemeyer> jdstrand: Well, exactly
<vila> elopio: https://github.com/ubuntu-core/snapcraft/pull/414 failed the example tests again, not sure I understand what is going on there, can you help ?
<jdstrand> niemeyer: but the plan is always to use interfaces and not that
<niemeyer> jdstrand: Why am I not trusting that too much? :)
<niemeyer> jdstrand: Time constraints win
<elopio> vila: it says: connection timed out. So the testbed died somehow. It's running again.
<jdstrand> niemeyer: I endup seeing all of the security manual reviews in the store for touch and snappy
<zyga> niemeyer: I think I will agree with you on this, the moment someone learns how to use old-security, there is no incentive to look at interfaces further
<zyga> "just use sudo"
<zyga> aka, old -secuirty
<jdstrand> niemeyer: they are exceedingly rare because the developer is blocked-- the upload doesn't go through. I say no a lot, etc
<jdstrand> so I wouldn't get hung up on developers just choosing it
<niemeyer> jdstrand: What if we instead tried to go without it?
<jdstrand> the store doesn't let them and I am very strict
<niemeyer> jdstrand: We can always put it back in
<niemeyer> jdstrand: It'll be very hard to remove it later
<jdstrand> niemeyer: I don't think it will be hard to remove in 17
<jdstrand> it would of course be hard to remove from 16
<zyga> I think that once the developer mode is in place we can give developers enough tools to do self-provisioning to the point where they can ask us to implement a proper interface
<jdstrand> but we discussed this last month
<jdstrand> I promise you that we'll need it for something
<niemeyer> jdstrand: Yeah, I know we discussed this
<jdstrand> someone will need an app for a demo tomorrow that will blow a sales call
<jdstrand> and the interfaces don't support it, etc
<niemeyer> jdstrand: developer mode..
<vila> elopio: thanks !
<jdstrand> as the one who always gets that call, I am very uncomfortable taking it out
<vila> elopio: Is re-running something I could have done ?
<zyga> (even if we don't give advice, just turn off process killing, developer mode sounds like the universal way out)
<jdstrand> niemeyer: sure, but someone will want to demo an app without having to go into that
<niemeyer> jdstrand: Well, to me this is a good reason for us to not have it
<niemeyer> jdstrand: Precisely because once we have the mechanism, people with bigger guns will be constantly forcing hacks in
<elopio> vila: only if you are in the whitelist. But we need to get more resources before we add people to the whitelist. fgimenez is on that.
<jdstrand> I mean we can take it out-- but when security blocks them and there is no escape hatch for the demo or for the client for a must have thingamajig, can I forward them to you? :)
<vila> elopio: nm then
<niemeyer> jdstrand: Yes!
<zyga> we'll setup a FAQ that says: $ snap enable developer-mode (or similar)
<jdstrand> one could make the same argument for security override then
<niemeyer> jdstrand: Yep
<niemeyer> jdstrand: My goal is to have quick turnarounds for real interfaces
<jdstrand> ok. don't say I didn't warn you :)
<zyga> niemeyer: hmm, so are you inclined to kill old-security right here, right now
<code1o6> ls
<niemeyer> jdstrand: I want to establish a process for us to release meaningful improvements every other week
<ogra_> no such file or directory
<jdstrand> niemeyer: sure. I think some interfaces will be fast. some will not. I think over time, hopefully they'll get faster and faster
<vila> ogra_: ha, thanks, exactly the bit I was missing from the error message
<niemeyer> zyga: Yes.. just thinking about the best way to do that
<niemeyer> zyga: Definitely before 16.04
<jdstrand> cause we'll have seen more and more exceptional cases, etc
 * ogra_ hugs vila ... happy to help :)
<zyga> niemeyer: is there a spec on how to enable / disable developer mode for a given snap?
<niemeyer> jdstrand: Right, agreed
<niemeyer> jdstrand: As a rule of thumb, I'd prefer to release a half-baked interface that is under the entire control of the security team, than a security policy that is hand coded
<niemeyer> jdstrand: hand-coded security policies break the whole system organization
<niemeyer> zyga: snap install ---devel, or similar
<vila> joke aside, I just did 'snapcraft upload wrong-filename' and the output was: 'wrong-filename' and nothing else. --debug told me it was FIleNotFound but I found --debug while already under pdb ;)
<zyga> niemeyer: I'll see if I can patch that in
<vila> ogra_: not sure how you knew that... ;)
<ogra_> intuition :)
<jdstrand> niemeyer: I agree. I will mention that the security team would review the hand-crafted policy (or flat refuse to accept it)
<niemeyer> jdstrand: I reckon, but it's still a different relationship
<niemeyer> jdstrand: It's something the security team can review, have an opinion about, and change
<niemeyer> jdstrand: vs. something lost inside a snap
<jdstrand> niemeyer: but anyhoo. to be clear, obviously the security team will take part in interface security policy, but the snappy team will be there for approval to add/design/non-security policy changes/etc, correct?
<jdstrand> niemeyer: ie, no interface will go through without collaborating?
<zyga> jdstrand: well, that would be hard to sneak in
<jdstrand> I'm not talking about a malicious actor
<niemeyer> jdstrand: Of course
<zyga> jdstrand: even non-malicious
<jdstrand> niemeyer: perfect
<niemeyer> jdstrand, zyga: So I think the easiest is to flip the switch when the new security logic is used
<jdstrand> zyga: I'm just getting at defining the process that if an interface is added by snappy core, there is (at least) security team ack and vice versa
<zyga> jdstrand: yes, I think we need to have a clearly documented process to create or alter interfaces
<jdstrand> niemeyer: my hope is that security-override will be needed less with seccomp arg filtering
<niemeyer> zyga: In other words, once the InterfaceManager goes live, old-security is obsoleted and starts to refuse installs
<zyga> niemeyer: woot, that's nice
<zyga> niemeyer: and simplifies many issues that were special cased
<jdstrand> cause we can add a few things that people get blocked on currently, but in a controlled way
<jdstrand> eg, setpriority
<jdstrand> kyrofa: ^
<jdstrand> :)
<niemeyer> jdstrand: Right, exactly
<zyga> niemeyer: I'll make that happen, and I know have the answer to }
<kyrofa> jdstrand, haha, your memory is scary
<niemeyer> zyga: +1
<zyga> niemeyer: is there a card for $ snap install --devel
<jdstrand> and I people are using security-override today mostly to work around seccomp policy. occasionally for an apparmor read or write here and there
<zyga> sergiusens: ^^ (old-security is dead)
<niemeyer> sergiusens: s/dead/dying/
<niemeyer> zyga: ^
<zyga> niemeyer: sure, I'll be hard at work to kill it entirely :)
<jdstrand> kyrofa: in fact, this is in my test in my branch: 'setpriority - 0 >=0'
<niemeyer> jdstrand: Right, there you go.. there are likely patterns already being established via the use of overrides which would be trivial to have an interface for
<niemeyer> jdstrand: But because it's so cheap, we never cooked it
 * zyga has some cool ideas
<jdstrand> niemeyer: well, note, there may be a pattern, but it is only for like 3 things :)
<kyrofa> jdstrand, nice :)
<zyga> but I'll let those wait for next week when it all works
<jdstrand> niemeyer: ie, people hate using these cause the upload gets hung up, but I mentioned that already
<niemeyer> jdstrand: It's okay.. migth be even just one thing to be clear.. we want to have people covered anyway
<jdstrand> so yeah, I'm fine with removing it. if developer mode is working right, that is the escape hatch. if someone complains and complains, I'll redirect to 'the decider' :)
<jdstrand> tyhicks: hey, so heads up on my queue of launcher changes: 1. sarnold's review fixes (MP awaiting review), 2. preprocessor review (will request MP this morning), 3. seccomp arg filtering (will be requesting MP soon), 4. support @deny rules (in progress), 5. support @complain mode (not started), 6. fix bug #1564401 (not started, likely start after preprocessor)
<ubottu> bug 1564401 in ubuntu-core-launcher (Ubuntu) "launcher does not apply cgroups on 16.04" [High,Triaged] https://launchpad.net/bugs/1564401
<beuno> pedronis, niemeyer, matiasb_, invite sent for our call!
<jdstrand> tyhicks: 2-6 depend on '1'. 4 and 5 depend on 2
<matiasb> ack
<jdstrand> tyhicks: I'd really like '1' to get reviewed soon (ideally today), but please advise on how to proceed
<jdstrand> tyhicks: I guess the review fixes aren't required for today, but I'd like to talk through the timing of these things
<wililupy> In my kernel snap, I have pre-built modules, if I use the copy plugin to install them to /lib/modules/`uname -r`/kernel/drivers/net/ethernet/igb and so on, does that have to happen before I run the kbuild and build my kernel?
<ogra_> wililupy, i would think so since you want them to be picked up by the depmod run that the kernel build does
<ogra_> else modprobe wont know about them
<wililupy> Thats what lool was saying, so will the copy plugin also create the uname -r directory I need?
<wililupy> ogra_: ^^
<wililupy> My snapcraft.yaml: https://pastebin.canonical.com/153091/
<ogra_> hmm, no idea, thats a sergiusens question
<ogra_> 456793
<lool> wililupy: checkout snapcraft/plugins/kernel.py in snapcraft
<lool> wililupy: it basically copies modules deps files directly
<lool> so can't use this plugin to compute new deps
<ogra_> oh, the kernel build process doesnt run depmod at the target dir ?
<lool> wililupy: you could extend the plugin or do some postprocessing, or use kbuild to rebuild the kernel (not sure how this will play with module deps either)
<lool> ogra_: there are two kernel plugins; I believe wililupy was trying to use a kernel .deb so the kernel plugin
<ogra_> we have a kernel plugin using debs ?
<wililupy> lool: I was going to use kbuild to build the kernel
<lool> now the kbuild module does basically a make install; I dont know if it would pickup third party vendor directories in the deps, it's possible
<lool> but in any case, you would need these to be installed before the kbuild plugin builds
<tyhicks> jdstrand: I'll do the review for #1 now
 * wililupy wonders if I put them in the right location in staging if that will work?
<jdstrand> tyhicks: well, I didn't mean for you to stop what you were doing (I mean it's fine if you want to review)
<jdstrand> tyhicks: I just wanted you to be aware of the queue and if you had opinions on how we should time the reviews, etc
<tyhicks> jdstrand: you've been waiting for a while and I don't want to pull sarnold off of MIRs so it falls in my lap
<tyhicks> jdstrand: it isn't a problem :)
<tyhicks> I'm in between things anyways
<jdstrand> ok, thanks
<zyga> jdstrand, niemeyer: ###SNIPPETS### https://github.com/ubuntu-core/snappy/pull/759/files
<kyrofa> wililupy, let me try to help
<wililupy> thank you kyrofa
<kyrofa> wililupy, so you have pre-built modules that your kernel requires?
<wililupy> yes. I built them against the kernel I will be using in snappy.
<sergiusens> zyga, niemeyer jdstrand can we sync after a call I have now? If not a snapcraft bug to keep track or anything would be welcome
<sergiusens> d
<zyga> sergiusens: we can file the bug on old-security when it is about to happen
<niemeyer> sergiusens: Happy to sync
<jdstrand> I also need to update the review tools
<sergiusens> zyga, thanks
<niemeyer> sergiusens: Let me know when you're available
<sergiusens> sync can just be, tell me what do do ;-)
<kyrofa> wililupy, why not ship them in the kernel itself?
<kyrofa> wililupy, closed-source stuff?
<wililupy> kyrofa, thats not a bad idea. It is closed source, so I can't put it upstream, but I can do it in my build environment.
<kyrofa> wililupy, right
<wililupy> what if my module has the same name as a current driver in the kernel, ie igb?
<kyrofa> wililupy, ah, which comes back to the depmod stuff I see above
<niemeyer> sergiusens: We're dropping old-security before 16.04.. that's the core of it
<niemeyer> sergiusens: It's there for the time being, so no immediate action needed
<niemeyer> sergiusens: Once the new security infra goes live, we'll kill old-security with it and reject snaps that attempt to be installed with it
<niemeyer> sergiusens: This should happen over the next week.. we'll ping you before released
<niemeyer> jdstrand: There's a note on https://github.com/ubuntu-core/snappy/pull/759/files which says // XXX: This needs to be verified by security team.
<niemeyer> jdstrand: It looks straightforward to me.. can you please +/-1 it so we can drop the note?
<sergiusens> niemeyer, ok, will we have replacements for what is currently done in old security for our examples or will they just not work at all?
<kyrofa> wililupy, at least on my ubuntu machine my /etc/depmod.d directory has a conf file containing "search updates ubuntu built-in"
<kyrofa> wililupy, assuming I understand that correctly (big assumption) one could get away with placing newer modules in the updates directory under modules
<wililupy> This is an interresting error: Issues while validating snapcraft.yaml: mapping values are not allowed here on line 19 of snapcraft.yaml
<zyga> jdstrand: is https://github.com/ubuntu-core/snappy/pull/759/files#diff-57dc34ab6f4bf9730b356d0439daa0fdR123 okay?
<zyga> (attach_disconnected,complain)
<kyrofa> wililupy, same YAML you pasted earlier?
<wililupy> kyrofa yes
<kyrofa> wililupy, the syntax looks okay, so try quoting the strings
<niemeyer> sergiusens: We have several of the old school profiles migrated already
<niemeyer> sergiusens: to first class interfaces
<niemeyer> sergiusens: https://github.com/ubuntu-core/snappy/tree/master/interfaces/builtin
<sergiusens> niemeyer, thanks for the link! this will help a lot :-)
<wililupy> kyrofa, sorry, that is my old snapcraft.yaml. Here is the current one I am using: https://pastebin.canonical.com/153114/
<kyrofa> wililupy, try not nesting the kconfigs in like that
<kyrofa> wililupy, the key `kconfigs` I mean
<wililupy> kyrofa, wow, it was that picky... lol
<kyrofa> wililupy, it's yaml
<wililupy> Here's an interresting error: Pulling kernel 'NoneType' object has no attribute 'headers'
<kyrofa> wililupy, run with the --debug flag
<wililupy> kyrofa: http://pastebin.canonical.com/153118
<kyrofa> wililupy, ah, https://bugs.launchpad.net/snapcraft/+bug/1560553
<ubottu> Launchpad bug 1560553 in Snapcraft "snapcraft error message is not very helpful when using storeapi without being logged in" [Medium,Fix committed]
<kyrofa> wililupy, you need to be authenticated to download the OS snap, so run `snapcraft login` first
<wililupy> kyrofa, thank you. May need to update the documentation so that others don't hit this easy mistake in the future... ;)
<kyrofa> wililupy, yeah that bug has been fixed, just not released
<jdstrand> zyga: yes
<zyga> jdstrand: perfect, thanks
<kyrofa> sergiusens, can you remind me why we need to be logged in at all to download that snap? No more anonymous snap downloads?
<jdstrand> zyga: though at line 138 aren't you undoing that change?
<zyga> jdstrand: hmm let's see
<wililupy> Building kernel!! See how long this takes. Time for lunch. Thanks kyrofa
<sergiusens> kyrofa, because that is going away
<kyrofa> sergiusens, ah, okay
<kyrofa> wililupy, no problem :)
<jdstrand> zyga: oh, no, I think its ok
<zyga> jdstrand: I don't see how
<zyga> jdstrand: that part is not a ### ... ### so we don't change it
<zyga> (in retrospective, we should)
<jdstrand> zyga: yeah, my mistake
<sergiusens> wililupy, there is no documentation for the kernel snap though, it is in experimental mode; once the core supports multiple initrds this download phase will go away
<wililupy> Got it. Thanks sergiusens
<niemeyer> zyga: So let's please drop the comment there
<zyga> niemeyer: gladly
<niemeyer> zyga, jdstrand: and I think it's ready to go in?
<zyga> niemeyer: removed now
<zyga> niemeyer: yes, I think so too :)
<zyga> niemeyer: I'll post some follow-up patches, one thing that's still a TODO is to remove cache elements but I have this written down and I'd like to first make use of this in snap install
<jdstrand> boy, took me a minute to wrap my head around the func(placehlder []... bits
<zyga> ok
<jdstrand> I think it's ready
<code1o6> guys is there any steps prior to running snappy login?
<niemeyer> zyga: Cool
<code1o6> *snapcraft login
<zyga> niemeyer: shall we merge with one +1
<code1o6> snapcraft: error: argument cmd: invalid choice: 'login'
<zyga> niemeyer: (we could count jdstrand's as a +1 though :-)
<code1o6> sergiusens, any ideas ^^?
<jdstrand> I didn't really do a go code review
<sergiusens> code1o6, snapcraft --version ?
<jdstrand> zyga, niemeyer: so, looking at this dbus PR I'm reminded that 'Type=dbus' dbus needs to be added to the systemd service file. is that handled properly with this new work or are we expecting the dev to set 'daemon: dbus' in their yaml?
<zyga> jdstrand: hmmmm, I'm not sure
<zyga> jdstrand: so does that mean that service file depends on interfaces?
<zyga> jdstrand: (the contents of the service file may needs to change when dbus is in use?)
<jdstrand> zyga: for a service that plugs a dbus bus policy interface, systemd won't start the service correctly without Type=dbus in the service file, no
<jdstrand> ie, bluez needs bluez bus policy
<jdstrand> it won't start correctly without Tyle=dbus
<jdstrand> Type=dbus
<jdstrand> but, we could say for the moment the dev needs to do:
<jdstrand> apps:
<jdstrand>   bluez:
<jdstrand>     plugs: [bluez5]
<jdstrand>     daemon: dbus
<jdstrand> and avoid magic
<zyga> niemeyer: ^^ opinions
<zyga> jdstrand: I like that much better
 * niemeyer reads
<zyga> jdstrand: I don't like the hidden magic dependency
<jdstrand> the review tools could try to help their too
<jdstrand> there*
<jdstrand> ie, they could know that bluez5 needs daemon: dbus
<niemeyer> jdstrand: What's the real effect of having Type: dbus in systemd?
<niemeyer> jdstrand: e.g. how will systemd know when to start the service?
<jdstrand> "Behavior of dbus is similar to simple; however, it is expected that the daemon acquires a name on the D-Bus bus, as configured by BusName=. systemd will proceed with starting follow-up units after the D-Bus bus name has been acquired. Service units with this option configured implicitly gain dependencies on the dbus.socket unit. This type is the default if BusName= is specified."
<jdstrand> https://www.freedesktop.org/software/systemd/man/systemd.service.html
<jdstrand> right, the service file also needs BusName
<jdstrand> hrmm, that means the service file generation does need to interact with interface
<jdstrand> interfaces*
<niemeyer> jdstrand: Yeah, that's what I was wondering.. it needs information about what is being listened on
<niemeyer> jdstrand: Note that it's also a slot above, not a plug
<jdstrand> no, this is a plug
<niemeyer> ?
<jdstrand> this isn't what bluez provides to clients, this is what bluez needs itself
<niemeyer> jdstrand: It doesn't make sense to me
<zyga> jdstrand: that's still a slot
<zyga> jdstrand: (think where plugs go to)
<niemeyer> jdstrand: bluez is consuming bluez?
<jdstrand> yes
<zyga> hmm?
<niemeyer> jdstrand: This seems a bit off
<jdstrand> I mean, it could be a different name
<jdstrand> ok let's back up
<zyga> jdstrand: I though that this is what permanent snippet on bluez slot would do
<jdstrand> the system needs to provide an interface (slot) that the bluez dbus service can use to run at all
<jdstrand> bluez provides a slot that clients can use to talk to bluez
<jdstrand> my plug referred to the former
<niemeyer> jdstrand: That's similar to the cases we discussed for x11 and mir
<zyga> jdstrand: what does the system need to provide and how is this different from what we managed to simplify with mir?
<jdstrand> we didn't simplify anything with mir
<niemeyer> jdstrand: We actually did, I think
<zyga> jdstrand: we replaced two interfaces with one
<zyga> jdstrand: no mir-server, mir-client; there's just a mir interface
<jdstrand> we haven't been able to explore any of these yet cause it is blocked on what you are trying to land
<zyga> jdstrand: and mir interface slot grants rights that would be granted by mir-server
<jdstrand> oh, maybe I am confused
<jdstrand> ok, regardless
<niemeyer> jdstrand: This feature is already in place in the interface system you're currently committing to
<jdstrand> if something is using a dbus interface in this manner, the service file needs Type=dbus and BusName=<something from the interface>
<niemeyer> jdstrand: As an interesting side note, we also need to restrict who offers those slots at all
<niemeyer> jdstrand: As offering the slot implies having access to resources already
<zyga> niemeyer: good point, it's also more iffy since there's no snap id yet
<niemeyer> zyga: The joys of implementing a non-trivial system under time pressure
<zyga> :-)
<jdstrand> that's fine. my head isn't totally wrapped around all that yet cause I haven't played with these things yet
<zyga> jdstrand: is it correct to assume that a snap may have many .service files?
<zyga> jdstrand: and it may need many bus names?
<zyga> jdstrand: so this is an app-level property
<jdstrand> zyga: I would think any entry under apps could potentially be a separate dbus service, yet
<jdstrand> yes
<niemeyer> jdstrand: Will that systemd auto-start feature work when there are multiple bus names involved?  It should, right?
<jdstrand> eg, a thick snap that provides ofono and nm
<zyga> right, so this is something that's aligned with what we have now;
<jdstrand> niemeyer: each is a different service file that is snap_app....service so yeah it should all be fine
<niemeyer> jdstrand: Don't think I get it..
<jdstrand> though, that assumes ordering of dbus services within the snap doesn't matter
<niemeyer> jdstrand: Question was what if one app provides multiple dbus services.. same process, multiple services
<jdstrand> niemeyer: perhaps I didn't understand your question
<zyga> hmmm
<jdstrand> that is unusual
<niemeyer> jdstrand: Per systemd documentation, BusName can apparently only be a single bus name
<niemeyer> jdstrand: But that's not a constraint on the dbus system
<jdstrand> you'd have to fork separate threads that each bind to a separate name
<niemeyer> jdstrand: It's trivial for a process to provide N dbus services
<jdstrand> BusName= is a well-known name that clients connect to
<jdstrand> then they can add any number of interfaces, etc
<niemeyer> jdstrand: Okay, I'll buy that and pretend it's all fine while breathing in a bag
<zyga> as long as systemd has the constrain that one bus name per process is the way to go, we can expect this not to be a problem for the immdeiate future where with existing snaps
<zyga> constraint*
<jdstrand> reading the systemd service specification, systemd doesn't seem to support multiple BusNames in a single service file
<zyga> I think this is fine, I wonder how interface details will look like for something like bluez or nm
<zyga> just <policy> ... blobs?
<zyga> or something more elaborate
<jdstrand> I think it is ok to say that is not supported
<jdstrand> or at least, if you do it, your have to deal with systemd not making sure things are ordered correctly
<niemeyer> zyga: We could in theory auto-assign the bus name to the application offering the bluez slot
<niemeyer> zyga: But it's easier to leave those disentangled
<niemeyer> At least for now
<zyga> niemeyer: I agree, I think this will need more love later, especially with an evolving snap (e.g. new bluez) the interface implementation might also have to change
<zyga> I feel there will be some lock-step necessary in general
<zyga> but a simple approach is enough for 16.04
<jdstrand> I agree that we'll need to refine dbus once we start looking at things like bluez
<jdstrand> I see in awe's bluez bus policy he has:
<jdstrand> <allow own="org.bluez"/>
<jdstrand> <allow own="org.bluez.obex"/>
<jdstrand> but he ships two different daemons
<jdstrand> bluez and obex
<jdstrand> both are 'daemon: simple'
<jdstrand> interesting
<jdstrand> so he is opting out of systemd integration
<zyga> jdstrand: maybe that's not deliberate
<jdstrand> and saying "just start me however you want". it starts, dbus-daemon looks at the bus policy (which is combined in one file here) and dbus allows it to start
<zyga> jdstrand: here we'd make two files (with the code I'm proposing)
<zyga> hmmm
<zyga> actually
<zyga> that's bad
<jdstrand> is it?
<zyga> and interesting but bad
<zyga> so bluez and obex are separate apps
<zyga> they need separate slots
<zyga> and separate interfaces
<jdstrand> they are, but he used one bus config
<jdstrand> but I think it would be ok to use 2 bus configs
<zyga> to get two xml snippets that's appropriate to each app
<zyga> then again dbus is not enforced per app really
<zyga> it's enforced per bus name
<zyga> right?
<jdstrand> I don't know what you mean by enforce there
<zyga> I feel that app/snippet/bus triplet is not so clean as in apparmor/seccomp
<zyga> jdstrand: sorry perhaps my language is wrong
<zyga> jdstrand: does dbus flitering care about our apps in _any_ way?
<zyga> jdstrand: (dbus policy files)
<jdstrand> traditionally, dbus policy files are plopped into a .d directory that dbus reads and decides what to do with it
<jdstrand> I don't know if first wins or last wins or if it is undefined
<jdstrand> so it is up to snappy to keep things clean
<zyga> jdstrand: so we currently do a file-per-app
<jdstrand> so the current approach I think is just fine
<jdstrand> yeah, sure
<zyga> jdstrand: (we could do something else but that's the status quo)
<zyga> jdstrand: but my point is that it's a bit subtle
<zyga> jdstrand: because from what I see we can have one app say "this and that bus policy applies"
<jdstrand> well, sorta
<zyga> jdstrand: and in reality that will affect *other* apps that just use that bus name
<zyga> jdstrand: right?
<jdstrand> with seccomp it is quite clear-- the file is what is the seccomp policy
<jdstrand> with apparmor it is like dbus. the contents of the file could technically be for something else, multiple things, etc
<jdstrand> we just need to add dbus files in a controlled way like we do with apparmor
<zyga> jdstrand: the thing we won't catch though is people misassigning slots to apps
<zyga> jdstrand: so looking at snap.yaml you will see that some interface is on some app
<jdstrand> we control the interfaces, we control how the dbus files are written, so we should be ok
<zyga> jdstrand: but in reality it will apply to a different app at runtime
<zyga> jdstrand: and unless all such cases flag for manual review
<zyga> jdstrand: we're going to miss it
<jdstrand> if I assign nm to the bluez daemon, is the system supposed to prevent that?
<zyga> jdstrand: well, that's a different problem, this is more like obex/bluez case above
<jdstrand> lets leave manual review out of it for now. that is a whole other conversation
<zyga> jdstrand: because it's not something that ubuntu-core-laucher applies / enforces on process startup
<zyga> jdstrand: I think it's not a major problem
<zyga> jdstrand: just a potential source of confusion
<jdstrand> (cause it gets into safe/unsafe, etc which would be a distraction for landing stuff)
<zyga> jdstrand: I'll take a break for home duties and I'll get back to udev and snap install support
<zyga> jdstrand: we now have apparmor backend, seccomp reviewed and dbus with some changes (comments mailny I think)
<jdstrand> zyga: the launcher doesn't, no. it is all dbus-daemon
<jdstrand> I'm not done with dbus. I got distracted wby this conversation
<zyga> jdstrand: so I think that's enough to get hello-world snap working :)
<zyga> jdstrand: that's okay, it's not essential for initial stab at install support
<zyga> jdstrand: I'll leave you to reviews and other work, ttyl
<jdstrand> I think we should keep pushing the current dbus direction and refine as we look at bluez, pulse, nm, etc
<jdstrand> zyga: bye, thanks!
<niemeyer> jdstrand: Hmm
<jdstrand> niemeyer: ?
<niemeyer> jdstrand: we have the x(11) interface in already.. what does it do?
<jdstrand> niemeyer: adds /etc/apparmor.d/abstractions/X
<niemeyer> jdstrand: Which will ...?
<jdstrand> niemeyer: essentially a few files in home for X to work, a few things in /usr and connection to the X socket
<niemeyer> jdstrand: Okay, that's not quite what we had in mind in that meeting, same reason as the bluez discussion above
<Netphreak> Hi, guys!
<jdstrand> I implemented it in the context of sdoc, not for providing an X server as a snap
<Netphreak> Any news om snappy om rpi3?
<niemeyer> jdstrand: Hmm.. so by "a few files in home for X to work" you actually mean "for X applications to connect to X" rather than "for the X server itself to work"
<niemeyer> ?
<jdstrand> niemeyer: yes, exactly
<jdstrand> niemeyer: this is the client part
<niemeyer> jdstrand: Aha, gotcha, thanks
<jdstrand> I want to run xeyes on classic
<niemeyer> jdstrand: Yep, got it.. that's fine then
<niemeyer> Stepping out for some sprint-related errands.. back later
<code1o6> I'm having issues publishing my app to the ubuntu store. I currently have version 1.1.0 in ubuntu 15.04. Should I add sudo add-apt-repository ppa:snappy-dev/snapcraft-daily ? I need my app to be for 15.04 snappy core systems
<code1o6> snapcraft login apparently doesn't exist in 1.1.0
<kyrofa> code1o6, you'll need to upload your snap via myapps
<kyrofa> code1o6, http://myapps.developer.ubuntu.com/
<kyrofa> Login to your account and upload your snap there
<kyrofa> code1o6, snapcraft 2.x will do that for you, 1.x does not
<code1o6> kyrofa, thank you
<code1o6> kyrofa, I already have an account where do you click next
<kyrofa> code1o6, click the Ubuntu Core tab at the top, and then the "New Package" button
<josepht> kyrofa: what's needed to run the snapcraft example_tests?  './runtests.sh examples' on 16.04 is trying to create 15.04 images with ubuntu-device-flash and snappy is failing with "Unknown command `internal-unpack'."
<kyrofa> josepht, try ./runtests.sh examples --skip-install
<kyrofa> josepht, by default it wants to install them into an ubuntu core machine and actually run them
<kyrofa> josepht, if you have one lying around you can use that too, of course
<kyrofa> josepht, check out examples_tests/__main__.py for the options
<josepht> kyrofa: ack, thank you
<sergiusens> kyrofa, josepht much better `python3 -m examples --help`
<kyrofa> sergiusens, josepht or that. If you like pretty help printouts instead of source code
<sergiusens> kyrofa, lol; I want to get rid of the runtests script; it has less options than running the package
<kyrofa> sergiusens, I'm on board with that
<sergiusens> josepht, if your snap is failing to build, run it in a cleanbuild; so `snapcraft cleanbuild`
<kyrofa> josepht, yeah good idea-- cleanbuild the git example and you'll probably find the missing dependencies
<code1o6> kyrofa, thanks for the help!
<code1o6> I got rejected for this error
<code1o6> required description field not specified snappy-systemd_package_yaml_description_present (webui)
<kyrofa> code1o6, your service needs a description
<code1o6> description: A basic webserver
<code1o6> https://github.com/arfvidsonUIS/unisys-test-snappy/blob/master/snapcraft.yaml
<code1o6> here is my snapcraft.yaml ^^
<code1o6> kyrofa, could you take a look
<kyrofa> code1o6, the webui service needs a description of its own
<code1o6> so just add description in line 13
<kyrofa> code1o6, right
<zyga> jdstrand: hey
<zyga> jdstrand: still around?
<code1o6> How long is the review process?
<code1o6> I'm using network-admin
<zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/768/files
<zyga> jdstrand: last one :)
<kyrofa> code1o6, yeah network-admin requires a manual review. It could take some time
<code1o6> hours, days, or months?
<code1o6> kyrofa, ^^
<zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/769/files
<kyrofa> code1o6, no clue. I'm not one of the reviewers, sorry
<code1o6> kyrofa, thanks for the information
<jdstrand> tyhicks: fyi, https://code.launchpad.net/~jdstrand/ubuntu-core-launcher/preprocessor/+merge/290652
<jdstrand> zyga: looking
<zyga> jdstrand: nice
<zyga> jdstrand: I'm working on one more patch for apparmor, to remove the binary cache
<tyhicks> jdstrand: I'm in the process of reviewing that MP
<jdstrand> cool, thanks
<josepht> sergiusens, kyrofa: thanks for the tips.  Sorry I got distracted by a baby squirrel that needed some help.
<zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/770
<zyga> jdstrand: I'm about to EOD (day is running out)
<zyga> jdstrand: I'll see you tomorrow
<jdstrand> zyga: have a nice evening :)
<zyga> jdstrand: likewise :)
<chiluk> Hey what arm64 boards are people getting for running snappy/ubuntu on?  right now it looks like pi3 and odroid-c2, and odroid-xu4
<chiluk> are all pretty awesome.
#snappy 2016-04-01
<netphreak> Evening, guys!
<netphreak> Any news on the Snappy RaspberryPi 3 support
<netphreak> ?
<manik_> netphreak: https://lists.ubuntu.com/archives/snappy-devel/2016-March/001639.html
<manik_> chiluk: we officially support plan to support the 96boards' dragonboard 410c for aarch64
<netphreak> Great news :)
<netphreak> I suppose bluetooth and wifi is supported?
<manik> netphreak: i haven't played with it myself, no h/w
<manik> please check with ogra tmrw and confirm
<netphreak> ok..
<beiriannydd> hello from snappy/docker
<beiriannydd> weird thing, I had problems building on snappy, so I exported the home volume to another docker container and built in that and everything worked
<beiriannydd> permissions being squashed?
<dholbach> good morning
<mvip> morning, didrocks :)
<mvip> was working on other things yesterday
<mvip> or asac maybe you know as well -- what's the deal with PPA builds for snaps?
<mvip> I've spoken to a few guys and they said that we should look into that for building our snaps, but I cannot seem to find any docs about that (i.e. building ARM snaps)
<asac> mvip: yes
<asac> i think that service is available in beta
<asac> let me check
<asac> let me try something
<asac> mvip: https://code.launchpad.net/~asac if you go to your code page (not asac)
<asac> do you see something about snap packages on the rigth?
<mvip> asac so hmm we haven't pushed any code there yet, so i'd have to first create a package. Give me a few
<mvip> but yes, i see a 'snap package' link
<asac> mvip: i just creawted a test package: https://code.launchpad.net/~asac/+snap/tomcat-webapp-demo
<asac> so just push sopmething with snapcraft.yaml there
<asac> you can also use git if you dont like bzr
<mvip> ah thank god ;)
<asac> then there is a link "request a snap package"
<asac> you hit that
<asac> and after you can navigate to that snap package and hit "request a build"
<asac> where you can select amd64 and i386 right now
<asac> at least thats the experience i get
<mvip> will this be integrated in the app store?
<asac> ah i can also request arm
<asac> you hav to configure processor
<asac> athen you have more acrchitecture
<asac> mvip: for sure at some point :)
<mvip> ;)
<asac> for now you have to upload yourself and sign it for 16 i guess
<mvip> cool alright let me play around with this for a bit
<mvip> ah right, there's a signing process too
<asac> but natural evolution of this is to allow you to directly opush to edge channel in store or so
<mvip> exactly
<asac> right. but surely this can be delgated to maybe  a builder key or something
<mvip> yeah let me play with this for a bit and bug you more later ;)
<didrocks> asac: mvip: hey! yeah, it's not in beta anymore, just need to push a bzr branch
<mvip> didrocks alright i just installed bzr on my box ;)
<mvip> going to test with some snappy sample code
<asac> didrocks: where is the announce mail?
 * asac tried to find it but the search DEITY wasnt on his side
<didrocks> asac: I don't think cjwatson made a public one
<asac> oh ok
<didrocks> I just read it written on IRC and some ML :)
<asac> didrocks: maybe  you wanna blocg about  it and update ML with the blog?
<asac> yeah well, i thought i saw an annoucne somewhere too
<asac> but couldnt find
<asac> *shrug*
<asac> wonder what happens if you build a snap for powerpc
<asac> :)
<asac> wonde why the tomcat example failed though
<asac> err where are the logs>?
<asac> didrocks: https://code.launchpad.net/~asac/+snap/tomcat-webapp-demo/+build/449
<mvip> didrocks OT, but here's a bash script that you can use for the updated marketing page for flashing out the disk image. https://gist.github.com/vpetersson/6346d67c8466ed513c3adb716a054cdd
<didrocks> asac: yeah, that would be great if some of us can blog about it, but already not enough time to do what I need to doâ¦
<mvip> it's a bit rough still but with some polish it could streamline the flashing a fair amount
<didrocks> mvip: oh nice, thaks! Yeah, I'll have a look
<didrocks> (this is on Mac, right? I see diskutils being used)
<mvip> didrocks i can put it in a github repo if you want
<mvip> didrocks yeah, but should be relatively easy to make it conditional to Linux too
<didrocks> mvip: just a note, bs=32M
<didrocks> that's better than 1Meg nowdays :)
<mvip> didrocks haha yeah
<mvip> didrocks let me throw it up in a github repo
<didrocks> ok ;)
<asac> ogra_: did yo guys find a real fix for the sudoers thing yesterday?
<ogra_> asac, sure, for both bugs ... a) dont loop mount sudoers with a readonly file ... b) mount /dev/pts in the container
<asac> ogra_: did you land the fix?
<ogra_> land ?
<asac> yes, is it fixed now>
<asac> ?
<ogra_> i have no idea where either of them would have to land
<asac> so wee dont want to fix it?
<ogra_> thats an mvo thing
<ogra_> jamie wanted to talk to him
<mvip> didrocks: https://github.com/vpetersson/sdflasher
 * ogra_ sighs
<ogra_> there must be a million of such scripts out there ... and every year someone writes a new one :P
<ogra_> i should re-vive ubuntu-imagewriter ;)
<didrocks> mvip: PR your way :)
<mvip> ogra_ i'm sure, but are any of them platform independent (OS X + Linux) and supports multiple formats of image files? :)
<ogra_> didrocks, make a note that widows users need windows 10 for bash scripts ;)
<mvip> ogra_ haha
<mvip> didrocks awesome
<ogra_> mvip, https://help.ubuntu.com/community/Installation/FromImgFiles
<didrocks> ogra_: good one :p
<ogra_> add the script there too if you want to officially promote it
<ogra_> thats where all other pages link to (for user documentation at least)
<ogra_> hmm, and the imagewriter bit should be removed
<mvip> ogra_ might as well add it there, yeah. Thanks
<ogra_> (would also be nice if you could make that script consistent .... thats half bash and half POSIX shell )
<mvip> ogra_: it says 'immutable page' for me
<ogra_> logged in ?
<mvip> ogra_ yup
<mvip> ogra_: yeah, this was just a hackish script i had laying around that has grown over time. Need to clean it up a bit more
<ogra_> just drop the [[]] from your if/elsif ....
<mvip> asac i was able to build a snap using the PPA. Yay! :)
<mvip> asac it's very slow however.
<mvip> asac been waiting for 15 min now for building the 'py3-test' example and it says 23 minutes remaining.
<mvip> (for arm build)
<mvip> hmm now i got 'Failed to build' but no error description at all.
<asac> mvip: yes i already flaggedt hat issue. folks say it happened during LP upgrade yesterday and said they will investigate asap
<asac> i dont know why arm is slow... if its slow building its probably not beefy builders or even emulators
<asac> if its just long wait before it gets build it just means long build queue
<asac> usually temporary because someone is doing an archive rebuild or something on the bilders
<mvip> asac got it. thanks
<mvip> asac well at least i know how to build it now.
<mvip> btw, can we create a (private) projects w/ multiple contributors somehow?
<asac> please shoot me a mail for that question. thanks
<mvip> asac sure thing
<ogra_> yeah, arm builders are non-native by default for PPAs unless you explicitly ask for native
<ogra_> (use the canonical-arm-dev PPA if you want native, i can add you to it if needed)
<mvip> ogra_ how do I ask for native ones?
<mvip> ah :)
<mvip> ogra_ yes please ('vpetersson')
<ogra_> mvip, oops,  sorry, that PPA is canonical only
 * ogra_ forgot about that
<mvip> ogra_ meh. ;(
<ogra_> sorry for that
<kyrofa> Good morning
<josepht> good morning
<kyrofa> jdstrand, I have a seccomp question for you when you get in
<jdstrand> kyrofa: go ahead
<kyrofa> jdstrand, good morning!
<kyrofa> jdstrand, simple question, I think: why do we use SCMP_ACT_KILL as opposed to SCMP_ACT_TRAP in the launcher?
<jdstrand> niemeyer, zyga: I've been looking at our udev tagging and there are several bugs on 16.04 (that's ok, zyga's udev branch hasn't landed yet so we'll just fix them)
<jdstrand> kyrofa: trap is racy
<zyga> jdstrand: in my branch or in the code outside of snappy?
<zyga> jdstrand: can you be more specific
<jdstrand> zyga: everywhere :)
<kyrofa> jdstrand, ah! It was indeed a simple question then, thank you :)
<zyga> jdstrand: can you please tell me more (just enough)
<jdstrand> zyga: on 15.04 we generate things like this:
<jdstrand> zyga: I'm getting there, hold on :)
<jdstrand> KERNEL=="kmsg", TAG:="snappy-assign", ENV{SNAPPY_APP}:="hello-world.canonical"
<jdstrand> that's fine
<jdstrand> in the current 16.04 code, we do something like:
<jdstrand> KERNEL=="kmsg", TAG:="snappy-assign", ENV{SNAPPY_APP}:="hello-world.echo"
<jdstrand> KERNEL=="kmsg", TAG:="snappy-assign", ENV{SNAPPY_APP}:="hello-world.env"
<jdstrand> KERNEL=="kmsg", TAG:="snappy-assign", ENV{SNAPPY_APP}:="hello-world.evil"
<jdstrand> ...
<zyga> jdstrand: and those overwrite?
<jdstrand> the idea was I'm assuming to allow each individual app access to the device
<zyga> jdstrand: (I mentioned that yesterday)
<jdstrand> yes, := overwrites. only one of those will work
<zyga> jdstrand: anyway, the other meeting is about to start, if you want we can jump there and we can continue this in a second
<jdstrand> ok
<kyrofa> jdstrand, is ERRNO also racy?
<jdstrand> kyrofa: no. I suggested errno as EPERM and was told that we prefer kill
<zyga> jdstrand: can we merge those so that we just say ENV{SNAPPY_APP}="hello-world.echo,hello-world.env,hello-world.evil" ?
<jdstrand> zyga: well, there seems to be some bugs on property match
<jdstrand> I'm not sure yet
<zyga> jdstrand: I see
<kyrofa> jdstrand, oh, that's too bad!
<zyga> jdstrand: thanks for mentioning this
<zyga> jdstrand: it's not used by any interface yet
<jdstrand> no
<zyga> jdstrand: but it will be required for various hw-assign-like scenarios
<jdstrand> I knew the review was coming and it is related to my 'remove needle detection from launcher' bug
<jdstrand> zyga: of course
<jdstrand> zyga: I wanted to talk to pitti about it, but still investigating
<jdstrand> I actually have a method that works
<zyga> jdstrand: let's join the hangout
<jdstrand> zyga: is per app device assignment a requirement?
<jdstrand> zyga: link?
<zyga> jdstrand: did you get it, I'm not nickserv-registered
<zyga> jdstrand: also sent on telegram
<jdstrand> I got it. I joined what you pasted
<zyga> morphis: hey, can we discuss the work you are doing here?
<elopio> sergiusens: can I change the mqtt parts in the wiki to use https?
<elopio> that won't break anything, afaics
<sergiusens> elopio, sure
<kyrofa> Is it possible to change the keyboard layout in snappy?
<kyrofa> I assume dpkg-reconfigure isn't going to work
<sergiusens> elopio, can you explain this http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/350/console ?
<sergiusens> kyrofa, it was possible in the past, not sure snappy config ubuntu-core still exposes it
<kyrofa> sergiusens, alright thanks, doesn't look like it
#snappy 2016-04-02
<tsimonq2> Can I make a metapackage with my snapcraft.yaml file, and if so, how?
<oparoz> Hello. How does one create a user using snapcraft?
<jospoortvliet> tsimonq2: a metapackage? you mean something that pulls in other stuff? no, snaps don't do dependencies
<jospoortvliet> you have to inclde everything
<jospoortvliet> oparoz: with everything running as root (aparently) I guess you don't need to :D
<oparoz> jospoortvliet: This worries me... You may want to have writable files for the sysadmin, but make sure PHP can't read or worse write to those files
<jospoortvliet> well the way snaps work is that no, you don't have writable files for the sysadmin, the snap with the code is read-only
<jospoortvliet> and only the actual datafiles are editable
<jospoortvliet> and if you want to edit config you create a new snap
<jospoortvliet> with your new config
<jospoortvliet> correct me if I'm wrong kyrofa
<jospoortvliet> oparoz: so all the config files we're fscking with like httpd.conf are read-only
<jospoortvliet> config.php of ownCloud is an exception but that's, well, of course.
<jospoortvliet> not different in any ownCloud installation
<jospoortvliet> even root can't doo much in a snap so it is safe to run as root
<jospoortvliet> *SOMEBODY TELL ME I'M WRONG* ;-)
<tsimonq2> jospoortvliet: but it pulls in stuff from GitHub?
<tsimonq2> and Ubuntu packages?
<oparoz> just checking the owncloud folder
<jospoortvliet> tsimonq2: aah ok, that is what you mean
<jospoortvliet> yeah, when building
<jospoortvliet> the snap
<jospoortvliet> not when installing the snap
<jospoortvliet> this will all be included in the snap
<tsimonq2> mhhhhmmmm...
<tsimonq2> yes
<tsimonq2> :)
<jospoortvliet> this is like a package build script
<jospoortvliet> the snapcraft.yaml I mean
<tsimonq2> *nod*
<jospoortvliet> I'm writing a blog about it, will try and get that finished... will drop what I have in a wiki page, gimme some minutes
<jospoortvliet> reading over that should help you get an idea of this weird stuff :D
<jospoortvliet> oparoz: I'll work what I wrote into https://github.com/owncloud/pi-image/wiki/Building-your-own-images
<jospoortvliet> good with you?
<oparoz> OK
<oparoz> It's now: Building your first image
<oparoz> We need additional articles about the specific parts
<qengho> oparoz: You can't create a user.
<oparoz> Thanks qengho. Does it matter if a script has a non-existing user then or should we modify all generic scripts we use so that they use root or www-data?
<qengho> oparoz: One package can't touch the files in another package or outside the system. As far as it's concerned, it is the only package installed on a whole simple machine that it has all to itself.
<oparoz> qengho: The problem is that if in a web app you have a mix of read-only and regular files, then you need to write some complex vhosts to only place those writeable files to the writeable "side"
<jospoortvliet> oparoz: I have turned the call you guys had Friday into a extensive how-to
<jospoortvliet> also explaining the basics of snappy etc
<oparoz> OK jospoortvliet
<jospoortvliet> would love to hear from tsimonq2 what he thinks once I've formatted the thing :D
<qengho> oparoz: it doesn't matter about the ownership, within reason. Don't use UIDs greather than 999 and you should be fine.
<oparoz> Thanks qengho, I'll give it a go
<jospoortvliet> oparoz: pls don't edit the file anymore
<jospoortvliet> damn I just lost all my changes :(
<oparoz> :(
<qengho> oparoz: Doesn't seem hard, but perhaps the usual Apache url=filesystem mapping plugin doesn't fit. Check if the resource is in one place. If not, check in another. If not, 404
<jospoortvliet> tsimonq2: here it is: https://github.com/owncloud/pi-image/wiki/Building-your-first-image
<jospoortvliet> I sadly have to leave now, taking my wife out for a dinner & concert. Ok, that is far from sad but it means I won't be back here today ;-)
<jospoortvliet> will work more on this tomorrow
<jospoortvliet> kyrofa: oparoz: please, review, check that wiki page
<jospoortvliet> it is based on pretty much the first half of your conversation friday
<jospoortvliet> should be a newbie-introduction to snappy
<oparoz> Thanks jospoortvliet! Enjoy the show!
<jospoortvliet> I will. Just fixed a layout issue, now I'm really out of here :D
<jospoortvliet> oparoz: there are some more layout issues with the page.
<oparoz> jospoortvliet: yep...
<oparoz> But I'm writing a daemon...
<jospoortvliet> go write your evil spirit, I will be happy to fix the page tomorrow
<jospoortvliet> or tsimonq2 fixes it while reading :D
<jospoortvliet> tsimonq2: you have access there?
<jospoortvliet> if not, pls email your github account name to frank@owncloud.com with jos@owncloud.com in cc, asking for access to the pi-image repo and you can edit as soon as F adds you!
<tsimonq2> jospoortvliet: :) I'll take a look
<tsimonq2> (not a Snappy dev by any means, just an Ubuntu enthusiast and member :) )
<jospoortvliet> tsimonq2: thanks a billion times, believe me, right now any knowledge is super helpful :D
<jospoortvliet> tsimonq2: and email me if you're interested in a Pi drive :P
<jospoortvliet> https://owncloud.org/blog/pioneer-our-owncloud-pi-drives/
<oparoz> kyrofa: Where are you telling Apache to load php7_module. It's not listed anywhere in snapcraft or the Apache plugin
<oparoz> kyrofa: I'm guessing all modules are automatically loaded, so we have to prevent the build of mod_php
<forker> Hello @here. Can someone help me to set forking type for service in package.yaml?
<forker> - name: subutai-agent    type: forking    security-policy:       apparmor: meta/agent.profile       seccomp: meta/agent.seccomp    description: "agent service"    start: bin/agent-wrapper
<forker> trying like this http://pastebin.com/EsvZyBru but it does not work :(
<forker> hm, is there a way to configure forking service on 15.04 snappy or it work only in 16.04?
<oparoz> How do you make a script executable in a snap?
<oparoz> Why is this an invalid argument on Snappy, when used in a daemon? -> ulimit -HSn 32768
<qengho> oparoz: "dmesg"
<qengho> oparoz: ^ look for logged errors or warnings that the kernel facilities blocked.
<qengho> oparoz: When you construct a snap, the execute bits that are set when you make the image are still on when you unpack and use the image.
<oparoz> Thanks qengho. Regarding the execute bits. I'm worried that it's going to be lost when I'm going to push my changes via git
<qengho> git preserves x bits.
<qengho> ...pretty sure.
<oparoz> qengho: If Windows keeps it...
<qengho> Sorry, never heard of it.
<oparoz> We'll see
<oparoz> How do you compile mod_mpm_event on snappy 16.04?  No rule to make target 'server/mpm/event/libevent.la', needed by 'httpd'
<oparoz> Neither libevent-dev or libev-dev work
<oparoz> Is it normal for ldd to report all binaries in an installed sna as broken?
<oparoz> Apparently it's normal  as the missing libs are in the snap
#snappy 2016-04-03
<Alton51> I happen to have a Dell Gateway 5000/5500 running Snappy, just updated.  Can't seem to get it to show anything available with "snappy search".
<Alton51> It's ok, because I can use the Python that came with it.  Just curious to learn more about the things, and Snappy.
<jospoortvliet> Alton51: a good start: https://github.com/owncloud/pi-image/wiki/Building-your-first-image
<jospoortvliet> ;-)
<qengho> Alton51: "snap find"?
<oparoz> Is there a "force" flag to remove snaps which can't be removed?
<ogra_> there is a purge command
<ogra_> usually only the system snaps cant be removed though
<oparoz> ogra_: The snap needs to be remove before it can be purged
<ogra_> (kernel, rootfs and gadget)
<oparoz> ogra_: I get an error when trying to remove the snap: remove /snaps/owncloud.sideload/LVSgNhfPknPQ/COPYING: read-only file system
<ogra_> did you manually change anything in that dir ?
 * ogra_ has only ever seen that in 15.04 whereyou
<ogra_> could actually make it rw
<oparoz> ogra_: No. I'm on 16.04
<ogra_> weird
<oparoz> ogra_: But I did use the fix mentioned here: https://bugs.launchpad.net/snappy/+bug/1564369
<ubottu> Launchpad bug 1564369 in Snappy "sudo broken in latest classic" [Critical,Confirmed]
<ogra_> sounds like a bug
<ogra_> That mount shouldn't affect the removal though... but try to unmount it before snappy remove
<oparoz> ogra_: I got the error when installing the snap, but things worked as expected
<ogra_> the sudo bug is only about the classic shell
<oparoz> ogra_: That's the error I get when installing: garbage collection impossible: prerequisites untrue: remove /snaps/owncloud.sideload/LVSgNhfPknPQ/COPYING: read-only file system
<ogra_> (where you usually do not use the snappy command)
<oparoz> ogra_: Yeah, I'm using two terminal windows
<oparoz> one for classic and one for installing
<ogra_> well, file a bug, I haven't seen anything like that before
<oparoz> ogra_: OK
<oparoz> https://bugs.launchpad.net/snappy/+bug/1565476
<ubottu> Launchpad bug 1565476 in Snappy "Can't remove snap" [Undecided,New]
<ogra_> Ah, at least there is a workaround
<oparoz> ogra_: Yeah, maybe it was the mount thing or the purge command. I'll confirm once I run purge again
<ogra_> k
<oparoz> ogra_: purge is not required, happens automatially after a while,  especially when the snap has some forking processes
<ogra_> Without purge your rw data persists... If you really want to remove the package thats the command to use... If you will later use a newer version you indeedwant to keep the data
<oparoz> ogra_: Maybe but people wanting to disable a snap temporarily will be hit by this bug
<oparoz> ogra_: And you can't purge without removing first
<ogra_> That sounds like a bug too... purge should remove and wipe the data in one go
<oparoz> ogra_: I get this: the given snap is still installed
<ogra_> Yeah, thats what i'd call a usability bug ;)
<oparoz> ogra_: :)
<oparoz> ogra_: Ah, it works if I deactivate...
<oparoz> ogra_: Ah, well, it's a mess, You can still use remove after purge... and the ro file is still there... I'll file a bug
<ogra_> +1
#snappy 2017-03-27
<mup> Bug #1676244 opened: Environment keyword not parsed correctly <Snappy:New> <https://launchpad.net/bugs/1676244>
<implite> does this package python stuff also? Im confused
<liuxg> in snap apps, is there any environment variable  get the path like /home/<username>/Pictures? thanks
<stub> liuxg: $SNAP_DATA is what is normally used for user data.
<stub> liuxg: Or use $HOME. In 'normal' snaps it is the same as $SNAP_DATA, and in 'classic' snaps it is the real $HOME
<mup> PR snapd#3085 opened: .travis.yml: remove travis matrix and do a single sequential run <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3085>
<mup> PR snapd#3002 closed: interfaces: add support for location-observe for dbus::ObjectManager session paths <Created by vosst> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3002>
<mup> PR snapd#3086 opened: interfaces: fix for access denied of opengl interface <Created by chunsangjeong> <https://github.com/snapcore/snapd/pull/3086>
<mup> PR snapd#3087 opened: overlord/snapstate: introduce tasks for aliases v2 semantics with temporary names for now <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3087>
<mup> PR snapd#3069 closed: snapstate:Â restart as needed if we undid unlinking aka relinked core or kernel snap <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3069>
<pstolowski> mardy, hey, i'm about to update your online-accounts interface branch for snapd for the latest API changes; do you have any changes you want to commit first?
<mardy> pstolowski: no, I cannot think of anything
<didrocks> it seems that ubuntu make (classic confinement) rev 2, 3 & 4 were accepted, but rev 1 was leftover which is amd64, can someone from the store team review it?
<pstolowski> mardy, ack, thanks
<morphis> Pharaoh_Atem: is "Request Approveacls" on https://admin.fedoraproject.org/pkgdb/package/rpms/golang-github-go-tomb-tomb/ what I want to get co-maintainership for that package?
<mup> PR snapd#3088 opened: snapstate:Â restart as needed if we undid unlinking aka relinked core or kernels snap <Created by pedronis> <https://github.com/snapcore/snapd/pull/3088>
<morphis> Pharaoh_Atem: one step closer: https://bugzilla.redhat.com/show_bug.cgi?id=1435616
<jdstrand> kyrofa: hey, sorry I missed you. I don't have experience writing gadget snaps, but can say that I susepect those need to be strings, yes, but there may also be a problem surrounding serialDeviceNodePattern is serial_port.go
<jdstrand> kyrofa: is /dev/kobuki a symlink or the actual device name? if a symlink, what does it point to?
<jdstrand> kyrofa: also serialUdevSymlinkPattern may get in the way
<jdstrand> kyrofa: it might work as is if you change to strings and use 'name: /dev/serial-port-kobuki' instead
<jdstrand> you might not need to change to strings
<mup> Bug #1670749 changed: classic confinement requires manually setting PATH and PYTHONPATH <openstack> <Snapcraft:New> <https://launchpad.net/bugs/1670749>
<mup> Bug #1672872 changed: error while loading shared libraries: libpython2.7.so.1.0 <openstack> <Snapcraft:New> <https://launchpad.net/bugs/1672872>
<mup> PR snapd#3088 closed: snapstate:Â restart as needed if we undid unlinking aka relinked core or kernels snap (2.23) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3088>
<kyrofa> jdstrand, thanks for the insight! I'll try that. I was under the impression that /dev/kobuki would be created as a symlink to the actual device
<jdstrand> kyrofa: it will, but /dev/kobuki doesn't match the serialUdevSymlinkPattern regex
<jdstrand> try /dev/serial-port-kobuki and see if that works
<kyrofa> Will do
<Pharaoh_Atem> morphis: you want to request approveacls and commit acls
<morphis> Pharaoh_Atem: aye
<morphis> Pharaoh_Atem: however we got the package updated in rawhide
<morphis> Pharaoh_Atem: and I am still waiting for my package requests to get approved
<Pharaoh_Atem> morphis: you should request it to be backported to F26 and F25
<Pharaoh_Atem> oh nevermind
<Pharaoh_Atem> he's already doing it
<morphis> Pharaoh_Atem: were do you see that?
<morphis> just saw the bug report update
<Pharaoh_Atem> https://bodhi.fedoraproject.org/updates/?packages=golang-github-go-tomb-tomb
<morphis> ah
<morphis> nice
<morphis> jdstrand: hey!
<jdstrand> morphis: hey :)
<morphis> jdstrand: regarding https://github.com/snapcore/snapd/pull/3086
<mup> PR snapd#3086: interfaces: fix for access denied of opengl interface <Created by chunsangjeong> <https://github.com/snapcore/snapd/pull/3086>
<Pharaoh_Atem> is mvo back yet?
<jdstrand> morphis: I commented a bit earlier
<morphis> jdstrand: my fear is that if we only update the opengl interface we break other apps already in the store
<morphis> so we have to better update all interfaces all-together to use udev-tagging
<morphis> and do this in a single snapd release to not cause any regression
<jdstrand> morphis: I'm fine with that approach too (in fact I prefer it)
<morphis> jdstrand: me too, and we will do that work afterwards
<morphis> already have a story for our next sprint
<jdstrand> morphis: at first I was thinking that this would affect few snaps, but I think your instinct is corrent. I suspect the vlc snap would break cause it uses opengl with optical-drive (for example)
<morphis> yeah
<jdstrand> correct*
<morphis> something like this, we could get a list from the store about used combinations etc.
<morphis> but that still has the chance of breaking unasserted snaps installed by people
<morphis> jdstrand: https://trello.com/c/bK7u2g7s
<jdstrand> morphis: it shouldn't break unasserted snaps. core gets updated and all the security policy (include the /etc/udev/rules.d files) get regenerated
<jdstrand> gets*
 * jdstrand is talking about if all the interfaces are updated
<morphis> jdstrand: yeah meant the case where we just update opengl
<morphis> jdstrand: so you're ok with updating just opengl for now with access to /dev/fb* and adjusting all interfaces in a second snap to use udev tagging?
<jdstrand> I guess you meant 'second step' there
<morphis> ah yeah .. too much 'snap' these days  :-)
<jdstrand> I really don't like adding /dev/fb* to opengl. opengl is autoconnected and framebuffer is not. /dev/fb gives privileged access to the console framebuffer
<jdstrand> and adding it to opengl will give all snaps that plugs it additional access that they shouldn't have. it is autoconnected so that is a security issue. then, while phase 2 is being worked out there might be a snap that depends on /dev/fb* in opengl and we break it with the next core update
<jdstrand> I think the snap that is affected by the snap should remove framebuffer from its yaml and wait for the proper fix
<jdstrand> and/or use devmode in the meantime
<jdstrand> by the bug*
<kyrofa> jdstrand, good news so far, changing the symlink to conform with that regex makes the slot show up in snap interfaces now, and the symlink is created
<kyrofa> jdstrand, do you know the rational behind that regex? It seems somewhat arbitrary
<jdstrand> kyrofa: it is so that the symlinks in /dev are namespaced in predictable ways. This was something niemeyer thought through and I agree with the approach. consider if we didn't have the regex and two interfaces could create /dev/something and a gadget (or with hotplugging, core) has both
<jdstrand> kyrofa: snapd can't really resolve that intelligently
<kyrofa> jdstrand, doesn't it just mean that we have the same problem with /dev/serial-port-something now?
<kyrofa> Less of an issue admittedly
<kyrofa> jdstrand, anyway, not a big deal to me so much as the total lack of feedback when I didn't match it
<kyrofa> I'm logging a bug for that
<jdstrand> kyrofa: that is within the same interface though. a gadget snap author can avoid that. it is possible that core and gadget could conflict when hotplugging is supported, but that is something that will need to be thought through in the hotplugging design
<kyrofa> jdstrand, fair enough, thanks for the explanation!
<jdstrand> kyrofa: note that the naming isn't arbitrary. the convention is '<interface>-<gadget-assignable>'
<kyrofa> jdstrand, indeed, that makes more sense
<mup> PR snapd#3086 closed: interfaces: fix for access denied of opengl interface <Created by chunsangjeong> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/3086>
<kyrofa> davidcalle, if I saw an issue with a codelab on tutorials.ubuntu.com, where would I log a bug?
<kyrofa> davidcalle, unping, you very nicely include a link there that answers my question
<mup> Bug #1676614 opened: snap install canonical-livepatch fails on system with nvidia driver <Snappy:New> <https://launchpad.net/bugs/1676614>
<roadmr> jdstrand: hey, r852 is now in production
<mup> PR snapcraft#1171 closed: beta <Created by snappy-m-o> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1171>
#snappy 2017-03-28
<mwhudson> who can i bribe to get https://github.com/snapcore/snapd/pull/3065 merged?
<mup> PR snapd#3065: Allow seeding a snap with classic confinement <Created by cyphermox> <https://github.com/snapcore/snapd/pull/3065>
<cyphermox> mwhudson: I can ping zyga in the morning to see what's missing with that merge.
<cyphermox> I meant to today, but when I thought of it it looks like it was too late, he wasn't online.
<mwhudson> cyphermox: fair enough
<cyphermox> mwhudson: if someone else answers before then... well we'll see here :)
<mwhudson> cyphermox: yeah pinging at this time of day is more in hope than expectation
<mup> PR snapcraft#1222 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1222>
<mup> PR snapcraft#1222 closed: beta <Created by snappy-m-o> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1222>
<mup> PR snapd#3089 opened: interfaces: drop udev tagging from framebuffer interface <Created by chunsangjeong> <https://github.com/snapcore/snapd/pull/3089>
<mup> PR snapd#3083 closed: tests: move unity test to nightly suite <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3083>
<didrocks> ubuntu-make classic snap is still not published on amd64 (but acked on all other archs) since yesterday. Is that an oversight?
<mup> PR snapd#3065 closed: Allow seeding a snap with classic confinement <Created by cyphermox> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3065>
<mup> PR snapd#3071 closed: many: ignore configure hook failures on core refresh <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3071>
<mup> PR snapd#3078 closed: tests: remove stale apt proxy leftover from cloud-init <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3078>
<mardy> pstolowski: hi! I'll address the chanegs requested by Jamie -- thanks for your other updates!
<mup> PR snapd#3090 opened: hookstate: add ability to report hook failures to the errtracker <Created by mvo5> <https://github.com/snapcore/snapd/pull/3090>
<pstolowski> mardy, cool, yw!
<mup> PR snapd#3064 closed: packaging: rename the file shipping snap-confine AA profile <Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3064>
<ptrtng> Question: How do I access data on a mounted ntfs partition from a snappy-packaged application on 16.04? paths on mounted drive don't show up.  fsstab uses fuseblk fs as per installation.
<ogra_> ptrtng, did you try using the removable-media interface ?
<ogra_> (assuming your partition mounts under /media this should be accessible)
<ptrtng> here is my current fstab entry:  UUID=XXXXXXXXXXXXXXXX /data ntfs  uid=1000,gid=1000,users,nodev,noexec,noatime  0   0
<ptrtng> note uid and gid are from my own tries to bend the user to my username. didn't work.
<ptrtng> the /data dir is accessible from bash and file manager.
<ptrtng> the current mount entry is:  /dev/sdb1 on /data type fuseblk (rw,nosuid,nodev,noexec,noatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
<ogra_> the /data dir wont be accessible by snaps ... as i said ... use something like /media/ntfsdrive to mount it and use the removable-media interface in your snap
<mup> PR snapd#3091 opened: interfaces/seccomp: add bind as part of the default seccomp policy for hooks <Created by morphis> <https://github.com/snapcore/snapd/pull/3091>
<ogra_> ppisati, should bluetooth work on the pi3 ? did you ever test that ?
<ptrtng> ok. I removed the fstab entry. mounted using dolphin. mount says: dev/sdb1 on /media/USERNAME/data type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2) .
<ogra_> ptrtng, goo, now make your snap use the removable-media interface and your snap apps should be able to see it
<chani> guys i have a fundamental question
<ogra_> *good even
<chani> does snaps use os level virtualization
<ptrtng> ok.  thats why the app doesn't see the /media directory.
<ogra_> no, snaps dont use virtualization by default
<ptrtng> BTW its not my own. I merely try to use it.
<ogra_> well, then you should probaly contact the developer so he/she adds that interface :)
<chani> so how is the isolation of snaps atchived
<ogra_> ppisati, bug 1674509 ... and i'm not sure if it shoudl work (i definitely see the devices created in dmesg if i load the module)
<mup> Bug #1674509: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 <Snappy:New> <https://launchpad.net/bugs/1674509>
<chani> *achieved
<ogra_> chani, via apparmor, seccomp and namespaces
<ogra_> chani, https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/ has all the dirty details
<ptrtng> @orgac thanks for your help.  I see me just using apt in this case. Pity.
<nothal> ptrtng: No such command!
<chani> thanks ogra
<ptrtng> pitty
<ogra_> ptrtng, what app was it ? i'm sure the maintainer would like to know about your issue
<ogra_> (i know i would if it was my app)
<chani> i have one more issue though
<ptrtng> the snap in question is:  openmvs   0.7.0-2a41453-0  2
<ptrtng> sorry I was wrong the app is: mve       20170210-0       1     mardy.
<chani> i have used apache as my stage-packages and once i have installed the app
<chani> i want the apache to start
<ptrtng> From the same people. I'll contact them by myself. Thanks for the help
<chani> i tried to start it through my terminal it seems to use my system path rather than snap application path to search for files
<ogra_> mardy, mind adding support for the removable-media interface to mve ? sounds like a valid addition if you want to use files from removable media
<mardy> ptrtng, ogra_: hi :-)
<ogra_> :)
<mardy> sure, I'll do that
<ptrtng> thanks!
<chani> like it fetches webpages from /var/www rather than /snap/my_app/current/var/www
<ogra_> chthen you need to adjust the config
<chani> so what should i do to make the root of my apache /snap/my_app/current/
<ogra_> choh, wait ... how do you start it ? you should have a daemon entry in your snapcraft.yaml for it and use systemctl if it is a daemon
<chani> so if i write a bash file and run it as a deamon it would by default use my /snap/my_app/current/ as root
<ogra_> yeah
<chani> did i get it right
<chani> ok thanks i will try that thanks :)
<ogra_> an example is at: https://github.com/snapcore/snapcraft/blob/master/demos/webcam-webui/snap/snapcraft.yaml and https://github.com/snapcore/snapcraft/blob/master/demos/webcam-webui/webcam-webui is a script it uses to run the httpd and a cam capturing service in a loop
<ppisati> ogra_: uhm, i don't remember testing it, and the problem on the rpi3 is that serial and bluetooth are contending the uart
<ppisati> ogra_: i need to test it
<ogra_> koza, see above ... we are not actually sure BT should work on the pi3 ...
<chani> the bash script uses #!/bin/bash as its shell right so when the deamon runs the bash file will it use bash shell to run the script
<chani> if so how is the root changed to /snap/my_app/current/
<ogra_> thats done by a builtin wrapper when the snap app gets executed
<ogra_> along with adding $SNAP/lib to your library path etc
<chani> where can i get the details of this implementation. just out of curiosity :P
<chani> is it in the whitepapers
<ogra_> i think there is some of it, yeah ... under FHS
<ogra_> and in "Snap security policy" too
<chani> thanks a lot ogra i was struck on the changing root dir for a day now it would have been a day or more if you didn't clarify it. :) :) :)
<mardy> ptrtng: try "snap refresh"
<mup> PR snapd#3092 opened: interfaces: capitalize Udev... as UDev <Created by zyga> <https://github.com/snapcore/snapd/pull/3092>
<mup> PR snapcraft#1223 opened: kernel plugin: check_config() and check_initrd() support <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1223>
<morphis> Pharaoh_Atem: looks like we have one minor issue left for i386 builds of snap-confine
<morphis> Pharaoh_Atem: https://copr-be.cloud.fedoraproject.org/results/mrmorph/snapcore/fedora-25-i386/00533426-snapd/build.log.gz
<koza> ogra_, hey, reading
<koza> unity
<didrocks> jdstrand: unsure if it's on your plate as well or not: ubuntu-make classic snap is not published on amd64 (but acked on all other archs) since yesterday. Is that an oversight?
<zyga> jdstrand: hey, can you review https://github.com/snapcore/snapd/pull/3091
<mup> PR snapd#3091: interfaces/seccomp: add bind to default seccomp template for hooks <Created by morphis> <https://github.com/snapcore/snapd/pull/3091>
<ptrtng> mardy: I just tried your meshlab-mardy snap. I am seeing the same external-disks-accessible' issue as with openmvg.  Would you care to fix that too?
<mardy> ptrtng: which version is it ("snap info")?
<mardy> ptrtng: for some reason it seems that "snap refresh" is not actually updating anything, weird
<zyga> mardy: snap refresh is not updating devmode snaps
<zyga> mardy: which OS is this?
<zyga> mardy: we had a bug where we'd mark everything as devmode unless confinement was on
<zyga> mardy: so no snaps would update
<zyga> mardy: we'd fix core as a special-case but not any other snap
<mardy> zyga: I'm on xenial, the snapcraft.yaml has "confinement: strict", but I don't remember if I used --devmode when installing it
<Son_Goku> mardy: check bash history :)
<mardy> Son_Goku: eh, that was long ago :-)
<zyga> mardy: snap info says tihs
<Son_Goku> if you didn't clobber ~/.bash_history, it should still be there
<zyga> mardy: if you see devmode there it's devmode
<ptrtng> mardy: I used 'meshlab-mardy  2016.12-20170302-2  4'
<mardy> zyga: oh, could it be that I installed it from a local snap? I see that "publisher" is empty: http://paste.ubuntu.com/24267528/
<ogra_> mardy, (x2) tells you it was local, yeah
<zyga> mardy: yes
<zyga> mardy: those won't refresh
<mardy> zyga, ogra_: ah ok, that's expected, sorry for the noise
<mup> PR snapd#3093 opened: cmd: discard the C implementation of snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3093>
<jdstrand> didrocks: it was approved but not released. I don't personally release snaps after they are approved since the I don't know what channel things should go in. I think popey may have approved these yesterday though. anyway, if you want to release it still (I see you have a new upload for amd64), you can use snapcraft to do so (or just tell me here what channels it should go to)
<jdstrand> zyga: hey, sure
<didrocks> jdstrand: yeah, I noticed that meanwhile, it was actually done, great!
<zyga> jdstrand: thank you
<morphis> zyga: ok, you're right, it is the missing largefile support: https://paste.ubuntu.com/24267713/
<zyga> morphis: glad to hear that was it
<ogra_> xfs ?
<ogra_> why the hell is anyone using xfs :P
<ogra_> (apart from IBM)
<Son_Goku> IBM would be using JFS
<morphis> ogra_: its for some constants coming from xfs/xqm.h for confinement
<Son_Goku> SGI was XFS
<ogra_> oh, right, not IBM
<zyga> yeah, just constants
<morphis> Son_Goku: btw. if you have a min, I've updated the templating PR
<mardy> ptrtng: done, please refresh meshlab
<davmor2> ogra_: would it annoy you if someone did use xfs.....if so they are probably using it because I paid them to annoy you sorry ;)
<mardy> ptrtng: there's a problem though: you need to explicitly type /media/<user> in the filename field, because the /media directory itself is not actually readable
<Son_Goku> morphis: you need to fix snapd.system-shutdown.service too
<Son_Goku> mvo: hey, you there?
<morphis> Son_Goku: you mean adding template vars to it?
<Son_Goku> morphis: yep
<morphis> Son_Goku: it's not going to be used on any classic system, that is why I skipped it
<Son_Goku> if you're going to do this, do it right :)
<Son_Goku> you never know
<morphis> and if you don't want people to use it another way than what it is supposed for then enforcement is better
<morphis> AFAIK we don't test it anywhere else and therefor shouldn't ship it as an option
<morphis> but leave this up to mvo and zyga
<Son_Goku> your makefile already installs it
<ogra_> davmor2, well, the paste was showing pokey-linux ... which is usually embedded ... using something like xfs or zfs in embedded would be rather insane (memory hog)
<Son_Goku> morphis, and it's better to not presume that you guys will be the only "Snappy" system producers
<davmor2> ogra_: hahahahaha
<Son_Goku> I know zyga keeps shooting me down about it, but I fully expect that someone will want to build a snappy system on CentOS or Yocto or whatnot
<ogra_> Son_Goku, we''ll just trademark it :P
<Son_Goku> ogra_: you already did :/
<morphis> Son_Goku: but you mean by "snappy" system? that word is already too overloaded :-)
<ogra_> clever us ;)
<Son_Goku> morphis: I mean that a system is composed as a snap-centric system like Ubuntu Core
<Son_Goku> except not being Ubuntu based
<ogra_> morphis, yeah, we should trademark "core" :)
<Son_Goku> ogra_: too generic :)
<morphis> :-)
<zyga> coreOS ;-)
<Son_Goku> Canonical holds trademarks for "Ubuntu Core" and "Ubuntu Snappy Core",  think
<ogra_> yeah
<ogra_> to specific :P
<Son_Goku> but if I want to make "Fedora Snappy Core", it's not particularly difficult
<morphis> zyga, mvo: its your call on templating for snapd.system-shutdown.service or not
<davmor2> ogra_: I think the gym guys beat you too it and intel and ..... well you know the list goes on
<zyga> Son_Goku: fedora core, like ubuntu core, mozilla ;-)
<zyga> Son_Goku: make it an user-agent problem
<Son_Goku> well, Fedora Core was a thing :)
<ogra_> ubuntu core was a thing since 6 years or so
<ogra_> but not the core you are looking for :)
<Son_Goku> ogra_: Fedora Core was the original name of the Fedora distribution :)
<Son_Goku> when Red Hat Linux was merged into the Fedora Project, "Fedora Core" represented the RHL bits
<Son_Goku> that name is still trademarked by Red Hat
<morphis> Son_Goku: btw. do you have packages for snapd-glib somewhere too?
<Son_Goku> in Fedora dist-git
<Son_Goku> that builds fine and can be upgraded
<Son_Goku> it just can't be installed because snapd isn't available
<Son_Goku> zyga is the maintainer of snapd-glib, you'll need to request comaint privs on pkgdb
<morphis> Son_Goku: ok, let me do that
<morphis> Son_Goku: still waiting for the golang-* packages to be added to pkgdb here .
<Son_Goku> morphis: poking people in #fedora-admin might be appropriate then
<morphis> Son_Goku: sounds like a good idea
<morphis> Son_Goku, zyga: ok also requested admin access for snapd / snapd-glib
<Son_Goku> zyga, morphis: I've approved snapd-glib ACLs, but I'm going to wait on snapd ones until after you have your golang stuff
<morphis> Son_Goku: aye
<morphis> Son_Goku: thanks
<morphis> zyga: ok, https://github.com/morphis/snapd/commit/26a1a4b695d608596c76ee84ee00e9ecf4188267 solves the xqm.h problem but it looks a bit clumpy
<zyga> looking
<zyga> morphis: you can alternatively use a custom checker and just #define the right stuff inside
<zyga> morphis: no need to touch CFLAGS
<morphis> zyga: no that doesn't work
<morphis> I tried it
<morphis> but can't explain yet why ..
<morphis> zyga: https://paste.ubuntu.com/24267906/
<zyga> morphis: no idea, autotools magic
<morphis> let me try one thing ..
<morphis> actually that paste is wrong one .. but anyway
<cyphermox> mvo: ta, this will really help
<mup> PR snapd#3094 opened: cmd: rework header check for xfs/xqm.h <Created by morphis> <https://github.com/snapcore/snapd/pull/3094>
<morphis> zyga: ^^
<zyga> morphis: checking
<steve_fi> Hey, I've created an Ubuntu Core LXD container and I want to be able to create users on it (which I think means I need to make the system writable) ... According to this man page (http://manpages.ubuntu.com/manpages/xenial/man5/writable-paths.5.html) I should be editing the file  /etc/system-image/writable-paths however, it doesn't exist and I cannot find it anywhere on the container, does anyone have any ideas?
<ptrtng> mardi: I've checked out your meshlab update: Fails. See https://pastebin.com/gafuPLAg for more info.
<mup> PR snapd#3093 closed: cmd: discard the C implementation of snap-update-ns <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3093>
<NicolinoCuralli> hi all is it possibile to bind udp/67 port in strict mode?
<mup> PR snapd#3095 opened: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095>
<kyrofa> jdstrand, if I publish a gadget and also publish a snap that uses a serial-port slot provided by that gadget, do I need an assertion to autoconnect those?
<jdstrand> kyrofa: you may need to today, but my understanding was that the gadget snap has a voice in autoconnection, so I think the design is you shouldn't
<kyrofa> jdstrand, alright, I may be pinging you about that in a bit, then
<jdstrand> kyrofa: if it doesn't work, I can issue a snap decl if needed, but please file a bug in that case
<kyrofa> Sounds good
<kyrofa> Yeah this has been a good exercise
<jdstrand> I don't have the specifics on gadgets and autoconnection. I think morphis has done a few though
<morphis> jdstrand, kyrofa: AFAIK this isn't possible today
<kyrofa> morphis, alright, thank you
<morphis> kyrofa: according to what I've heard from pedronis this should be possible in some way later
<morphis> kyrofa: btw. I've started to use the nextcloud snap recently and have it now in a production environment, awesome work :-)
<kyrofa> morphis, why thank you!
<morphis> kyrofa: I really liked how it did everything for me including the lets-encrypt setup
<morphis> magic :-)
<kyrofa> morphis, yeah that took some time to work out, heh
<morphis> coming from a 14.04 setup where I throw everything away no because they told me to install php5.6 from some ppa to be still able to install nextcloud 11
<morphis> s/no because/now because/
<kyrofa> Yeah it was always painful to maintain for me, too
<morphis> but having something coming officially from nextcloud is quite nice and is enough for my trust level :-)
<morphis> yeah
<morphis> its quite interesting that they officially still state they support 14.04 where they clearly don't unless you install php from a ppa which also ships a patched version of openssl ..
<kyrofa> Haha, "we support 12.04 too!"
<morphis> :-D
<morphis> kyrofa: I always only believe those things when I see and feel it them
<kyrofa> morphis, the only weirdness with the snap is that automatically updating will sometimes disable your apps
<kyrofa> morphis, keep that in mind, if they disappear, just re-enable them, you didn't lose anything
<kyrofa> morphis, they're working on fixing that in nextcloud itself, sounds like
<morphis> kyrofa: yeah .. had this with the regular install too
<morphis> always had my dad crying his calendar and contacts disappeared :-)
<kyrofa> Yeah... annoying
<morphis> kyrofa: but good to know they are fixing this at the root of the whole thing
<mup> PR snapcraft#1224 opened: tests: fix name registration window limit test to latest changes  <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1224>
<kyrofa> barry, in case you didn't notice, snapcraft v2.28 is in -updates
<barry> kyrofa: oh cool.  i don't see them in rmadison yet, but that might just be delay.  as soon as the autopkgtests w/o -proposed passes, i can land the branch and get u-i 1.0 classic snap uploaded
<barry> kyrofa: conveniently, it's lunch time :)
<kyrofa> barry, hmm... indeed, I may have lied
<kyrofa> barry, yeah it's verification-done, but not in -updates yet. I may have been fooled by an lxd container setup with proposed darnit, sorry
<mup> PR snapd#3096 opened: many: abstract path to /bin/{true,false} <Created by morphis> <https://github.com/snapcore/snapd/pull/3096>
<cachio> jdstrand, hey
<cachio> jdstrand, tyhicks , I was making some changes to the dbus performance tests and I noticed the big overhead is when the confinment is not strict
<cachio> jdstrand, tyhicks in case the confinement is strict the overhead is aroud 15 to 20 %
<tyhicks> cachio: when you say "when the confinement is not strict", are you referring to devmode, classic, or both of those confinement modes?
<cachio> devmode
<tyhicks> interesting
<cachio> tyhicks, I used to install it with --devmode
<cachio> then I removed that and I started getting results with 15-20$ of overhead
<tyhicks> cachio: to make sure I understand, the dbus mediation with strict confinement mode is within our expected range (15-20%)
<cachio> tyhicks, yes
<cachio> agree
<tyhicks> cachio: the dbus mediation with devmode confinement mode sometimes exceeds our expected range (> 25%)
<tyhicks> ok
<tyhicks> that could be really helpful when reviewing the code
<cachio> tyhicks, it is about 35% with devmod confinment
<tyhicks> cachio, jdstrand: this is starting to feel like an auditing overhead to me
<tyhicks> cachio: are audit messages being sent to /var/log/syslog for every message you send?
<tyhicks> cachio: you'll have a ton of apparmor="ALLOWED" messages if that's the case
<cachio> tyhicks, let me see
<cachio> tyhicks, well there are many entries for dbus in syslog
<cachio> tyhicks, but not sure if there are so many to cause that
<tyhicks> cachio: is there one that looks to repeat a lot?
<tyhicks> cachio: if so, please paste it
<cachio> tyhicks, this one http://paste.ubuntu.com/24268835/
<tyhicks> cachio: ok, that is definitely coming from dbus-daemon
<tyhicks> the in-code overhead for a devmode snap talking on dbus is two calls to this function: http://paste.ubuntu.com/24268842/
<tyhicks> however, if the message/signal is not allowed by the snappy policy, it'll generate an audit message through libaudit which could add significant overhead if a large number of messages/signals are sent
<cachio> tyhicks, something that also could help you is that I am also plugging the mount-observe interface
<cachio> tyhicks, could that affect in the results?
<Pharaoh_Atem> mvo: would it be possible to split the vendoring for snapd into an overlay tarball?
<Pharaoh_Atem> that is, a tarball that is overlaid on top of an unvendored snapd tarball
<tyhicks> cachio: I don't think so
<barry> kyrofa: cool.  if it's verification-done, it'll show up soon enough
<kyrofa> ogra_, I just noticed that the Dragonboard gadget has architectures: [armhf]
<kyrofa> ogra_, shouldn't that be arm64?
<zyga> jdstrand: hey
<jdstrand> zyga: hey
<zyga> jdstrand: can you please try to review https://github.com/snapcore/snapd/pull/3091 today, I think mvo wants this for an SRU
<mup> PR snapd#3091: interfaces/seccomp: add bind to default seccomp template for hooks <Created by morphis> <https://github.com/snapcore/snapd/pull/3091>
<jdstrand> zyga: I plan to
<zyga> jdstrand: it's a workaround for golang doing "bind" and snapctl
<jdstrand> I read it. I'm thinking about my response
<sergiusens> barry: kyrofa I haven't pulled the trigger yet on releasing to -updates
<zyga> jdstrand: aha, that's great, I just wanted to make sure you had an eye on this before it gets merged (it has two +1s)
<barry> sergiusens: what's the hold up?
<jdstrand> cachio: curious-- are you connecting the interface when in strict mode and not connecting the interface in devmode?
<jdstrand> tyhicks: ^
<Pharaoh_Atem> zyga: did you have a chance to talk to mvo about overlay tarballs?
<jdstrand> people sometimes forget to connect their interfaces in devmode...
<zyga> Pharaoh_Atem: no, because there was no release plan decision until today
<zyga> Pharaoh_Atem: I'll ask
<Pharaoh_Atem> zyga: cool
<zyga> mvo: Pharaoh_Atem had an idea that we could release vanilla git tree + the vendor/ directory separately as that would ease packaging
<zyga> Pharaoh_Atem: for vendorized builds we would consume both tarballs
<zyga> Pharaoh_Atem: and for de-vendorized builds just one
<zyga> Pharaoh_Atem: it shouldn't be be harder than what we do now (vendorized)
<zyga> er
<zyga> mvo: ^^
 * zyga is tired
<Pharaoh_Atem> it would make it much less painful for supporting EL7 builds along with Fedora builds
<zyga> mvo: and once we have a script for making this should be essentially free
 * zyga needs to walk again
<zyga> (offline)
<kyrofa> jdstrand, could you take a look at the dragonboard-turtlebot-kyrofa gadget when you're able, please?
<kyrofa> Same thing as the amd64 gadget (serial-port workaround)
<cachio> jdstrand, I am connecting in both
<cachio> jdstrand, it is the same execution
<cachio> jdstrand, the diff is the when I install
<jdstrand> kyrofa: done
<jdstrand> cachio: the diff is when you install? I don't understand. you mean you see a difference between when you install and when you connect the interfaces? as such, in strict mode before connecting and complain mode before connecting?
<kyrofa> jdstrand, thank you!
<jdstrand> (you see a difference)
<jdstrand> kyrofa: I made a change to the review tools as well. the pc gadget should now pass automated review, but this one will be a little while for prod
<kyrofa> jdstrand, indeed I've already experienced the pc passing, thank you :)
<cachio> jdstrand, I install, then I connect and then I run the tests
<cachio> jdstrand, that for strict and devmode
<cachio> jdstrand, all the steps are equal, but hte install
<cachio> jdstrand, the diff I see is when I run the tests
<cachio> it is once the whole snap setup is done
<jdstrand> ok
<jdstrand> tyhicks: ^ (you probably figured all that out already...)
<mup> PR snapd#3091 closed: interfaces/seccomp: add bind to default seccomp template for hooks <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3091>
<kyrofa> Hey barry, I just hit an interesting python problem if you have a sec
<barry> kyrofa: i do
<kyrofa> I have a plugin that ends up pulling two dependencies, one of which is python2, the other is python3
<kyrofa> barry, which means that I have two different python installs essentially contained in my part directory
<kyrofa> barry, however, I only have one PYTHONPATH. Is there a way for me to set an environment that says "python2 stuff look here, python3 stuff look there"?
<barry> kyrofa: unfortunately there isn't.  $PYTHONPATH is the same envar for both python2 and python3.  you'll have to put that on the command line, e.g. PYTHONPATH=foo:bar python2 whatever.py
<kyrofa> barry, hmm... the problem is that a third dependency drives the actual build process, so I can't get anything into the cli
<barry> kyrofa: hmm
<kyrofa> Nasty
<barry> yep :)
<barry> too bad you can't just port the py2 bits to py3 :)
<kyrofa> I didn't actually realize I had a python3 dependency in there until I saw a build failure happen on LP which apparently doesn't include lsb-release
<barry> kyrofa: can you arrange for a module to get imported early in the build process?
<kyrofa> barry, the build process is actually cmake. You would cry if you saw this
<barry> because that module could test for the python version and then hack sys.path accordingly
<barry> kyrofa: i'm tearing up just thinking about it ;)
<kyrofa> barry, alright, thanks for the insight! I'll mull this over
<barry> kyrofa: okay, good luck!
<anorgrull> hi, trying to install snapd on a raspberry pi 3 running raspbian. Any shortcut from installing go and building from sources ?
<kyrofa> anorgrull, I don't believe raspbian includes the necessary appamor kernel patches
<kyrofa> anorgrull, zyga or morphis could probably talk you through building the necessary bits while disabling confinement, if you want to go that route
<zyga> anorgrull: hey
<zyga> anorgrull: hmm, raspbian is based on which version of debian now?
<zyga> anorgrull: you may be able to just get it
<kyrofa> barry, I suppose PYTHONPATH will still be needed even if I use .pth files?
<zyga> anorgrull: in any case you can build snapd from source
<anorgrull> maybe recompiling kernel to add it seem possible, an other route is to swich to ubuntu
<zyga> anorgrull: I'd love to know how that feels like
<zyga> anorgrull: a while ago I wrote this: https://new.zygoon.pl/post/case-study-snapd-on-centos/
<zyga> anorgrull: it's a centos build but the main idea holds
<barry> kyrofa: ah, that's a good (as in evil :) hack.  if the .pth is on the normal import path you won't, but if you need to put that in a non-standard place, you will.  you can do a lot with .pth files (for better or worse ;)
<kyrofa> barry, I seem to remember that python checks in ~/.local somewhere by default as well as the system-wide location?
<barry> kyrofa: there are differences depending on whether you're running it interactively or not, but you can always find out definitively with `python3 -c "import sys; print(sys.path)"
<kyrofa> barry, wait... since the part owns the python in question I can create wrappers/aliases that set the right environment. Disgusting, but the best option yet I think
<kyrofa> It also owns the PATH, so I can make sure those are called
<barry> kyrofa: that's definitely the better way to go.  i've done $PATH hacking in my snapcraft.yaml (originally also needing to hack $PYTHONPATH but then found i didn't need it).  i'm not sure if the environment section can apply to a single part or to the whole thing (don't remember, didn't affect u-i)
<kyrofa> Good deal
<sergiusens> is this "ask barry"? If so, I have a question -> https://bugs.launchpad.net/snapcraft/+bug/1675479
<mup> Bug #1675479: python plugin doesn't work for namespace packages <openstack> <plugin> <Snapcraft:Confirmed> <https://launchpad.net/bugs/1675479>
<kyrofa> Hahaha
<sergiusens> we use pure upstream pip, setuptools and wheels... any weird thing you can think of?
<barry> python story time with the flufl
<sergiusens> the fix mentioned in there involved driving the install with setup.py instead of pip btw (in case you have better ideas)
<barry> sergiusens: that's odd because 2.7 doesn't have pep 420 style namespace packages.  it has a hacky thing but still requires __init__.pys
<barry> or it *can* have a hacky thing if the top-level package puts stuff in __init__.py
<barry> the paste deploy pastebin doesn't seem related to that because it's a top level package
<mup> PR snapd#3097 opened: interfaces/seccomp: add bind as part of the default seccomp policy (backport) <Created by zyga> <https://github.com/snapcore/snapd/pull/3097>
<barry> ah, nspkg.pth files.  yeah those are magical and problematic
<Pharaoh_Atem> zyga: so morphis' golang packages have been approved
<mup> PR core#30 opened: Update core snap cloud-init configuration <Created by raharper> <https://github.com/snapcore/core/pull/30>
<Pharaoh_Atem> they are awaiting his import of the packages
<Pharaoh_Atem> he should make sure that golang-sig and you are comaintainers of the golang packages
<Pharaoh_Atem> zyga: and you should also grant golang-sig similar privileges for your golang-* packages
<Pharaoh_Atem> only commit privileges, not approveacls and such
<sergiusens> barry: any clues on how to circumvent this or have the interpreter read these?
<kyrofa> jdstrand, alright, I've got two gadgets that both provide a `kobuki` serial-port slot, and one snap that has a `kobuki` serial-port plug. I'd like to get that snap to autoconnect to both gadgets
<kyrofa> jdstrand, how do I go about this?
<sergiusens> barry: but bottom line is packages added with .pth don't need __init__.py ?
<sergiusens> did I read that correctly?
<jdstrand> kyrofa: give me all the snap names and I'll do a snap declaration for them. please file a bug that you cannot do this with the gadget since that is the design
<kyrofa> jdstrand, will do. The app snap's name is turtlebot-demo-kyrofa
<kyrofa> jdstrand, the gadgets are pc-turtlebot-kyrofa and dragonboard-turtlebot-kyrofa
<barry> sergiusens: i believe that's the case, although it's dependent on a properly written .pth file.  i believe the standard ones hack the top-level module object's __path__ to include the path to the sub-package, which python's import machinery uses to find subpackages
<zyga> Pharaoh_Atem: sounds good, I will look into it
<barry> (it's kind of a trick for them to do that level of __path__ hackery)
<jdstrand> kyrofa: I've got several things I'm working on but will ping you when I add it
<kyrofa> jdstrand, no rush, this week will make me happy
<barry> sergiusens: it's all keyed off of sys.prefix and sys.exec_prefix.  i'm not sure what snapped python's do to those variables
<sergiusens> barry: nothing really to sys.prefix and sys.exec_prefix, we just rely on the interpreter figuring it out relative to its exec path
<barry> sergiusens: in that case it *should* find .pth files relative to those paths
<sergiusens> but now that you mention no __init__ I'll look into running coreycb's full example and see how it goes
<barry> sergiusens: cool.  let me know how it goes
 * zyga EODs
<zyga> Pharaoh_Atem: I'll work on golang-sig ACLs first thing tomorrow
<Pharaoh_Atem> okay
<anorgrull> <zyga>tanks for the tuto, but i'm stuck on getting some dependencies header's, will try ubuntu mate 16
<zyga> anorgrull: good luck,
<mup> PR snapd#3098 opened: cmd: Select what socket to use in cmd/snap{,ctl} <Created by mvo5> <https://github.com/snapcore/snapd/pull/3098>
<mwhudson> ahem
<mwhudson> $ snap info snapcraft | grep ^summary
<mwhudson> summary:   "Single-line elevator pitch for your amazing snap"
<kyrofa> Hahaha
<kyrofa> You can tell it's not done yet
<mwhudson> there is a certain irony here :)
<mwhudson> kyrofa: will launchpad use snapcraft 2.28 yet or only once it hits xenial-updates?
<kyrofa> mwhudson, depends on the pocket you use
<kyrofa> mwhudson, if updates, then yeah
<mwhudson> oh right
<kyrofa> mwhudson, you can of course use proposed
<kyrofa> mwhudson, but then everything comes from proposed
<mwhudson> yeah, that's ok for me i think
<mwhudson> i guess i could also copy 2.28 into a ppa and depend on that
<kyrofa> Indeed, though that sounds annoying
 * mwhudson shrugs
<jdstrand> pmcgowan: the ubuntu-app-platform issue should be resolved
<pmcgowan> jdstrand, great thanks, what was it
<jdstrand> pmcgowan: the review tools were correct. needed to tweak the snap decl slightly
<pmcgowan> I guess thats good
<pmcgowan> let me try to republish
<jdstrand> pmcgowan: hold on
<jdstrand> pmcgowan: let me just rerun the checks
<pmcgowan> holding
<jdstrand> pmcgowan: actually can you request a manual review in https://myapps.developer.ubuntu.com/dev/click-apps/6271/rev/42/ and https://myapps.developer.ubuntu.com/dev/click-apps/6271/rev/43/
<pmcgowan> jdstrand, 2 reviews requested
<jdstrand> ok, I triggered the autoreview
<jdstrand> pmcgowan: ok, armhf passed. running the autoreview for arm64
<pmcgowan> great
<jdstrand> pmcgowan: arm64 passed. feel free to release like normal
<jdstrand> pmcgowan: fyi, I added a task to a card to add a simple verification tool to the review tools so this doesn't happen again
<jdstrand> (to verify the snap decl)
<pmcgowan> ok
<pmcgowan> thanks
<jdstrand> the store itself only does rudimentary checks. perhaps it could be made to use this tool when its written
<kyrofa> Haha, eject has a security update? I must read this...
<kyrofa> Dang
<mup> PR snapd#3074 closed: configstate,hookstate: limit runtime of the configure hook to 5 minutes <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3074>
#snappy 2017-03-29
<kyrofa> jdstrand, I needed to push an update to the dragonboard-turtlebot-kyrofa gadget snap if you could take another look (changing the arch. For some reason the official one is armhf... ?)
 * mwhudson looks at the task of shuffling three releases and six architectures into tracks
<mup> PR snapd#3090 closed: configstate,hookstate: timeout the configure hook after 5 mins, report failures to the errtracker <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3090>
<mup> PR snapd#3099 opened: configstate,hookstate: timeout the configure hook after 5 mins, report failures to the errtracker <Created by mvo5> <https://github.com/snapcore/snapd/pull/3099>
<Son_Goku> morphis: yo
<morphis> Son_Goku: hey!
<Son_Goku> ugh, I hate being up this early, but w/e
<Son_Goku> once I'm up, I'm up
<morphis> :-)
<Son_Goku> morphis: did you do your initial import of the golang packages yet?
<morphis> Son_Goku: its on my list for this morning
<Son_Goku> morphis: the sooner, the better ;)
<morphis> yeah
<morphis> Son_Goku: first one builds for rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=18657838
<Son_Goku> shit, you didn't import for F24, too?
<Son_Goku> according to pkgdb, you only requested branches for Rawhide, F26, and F25
<morphis> Son_Goku: should I?
<Son_Goku> yes
<Son_Goku> I expect to be able to build snapd at least ONCE for F24
<morphis> ok
<morphis> let me change that
<morphis> Son_Goku: however, I get "BuildError: package golang-gopkg-retry not in list for tag f27-pending"
<morphis> any idea?
<Son_Goku> not really, no
<morphis> https://koji.fedoraproject.org/koji/taskinfo?taskID=18657838
<Son_Goku> you might want to pop into #fedora-releng and ask about it
<morphis> Son_Goku: done
<morphis> Son_Goku: I maybe have an idea ..
<morphis> Son_Goku: my fault, should be fixed now
<Son_Goku> morphis: did zyga show you how fedpkg workflow is supposed to work?
<morphis> Son_Goku: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Import.2C_commit.2C_and_build_your_package is what I am using
<Son_Goku> okay, good
<morphis> Son_Goku: but it doesn't tell if the package is now directly available in rawhide or not, just that I need to use bodhi for anything !rawhide
<Son_Goku> for rawhide (which currently is f27), it will automatically transition f27-pending -> f27
<morphis> ok
<Son_Goku> for branched releases, (f26 and below), it will transition from fXX-pending -> fXX-update-candidate
<Son_Goku> from there, you need to use "fedpkg update" to make them available
<morphis> Son_Goku: ok, let me get builds for f26-25
<Son_Goku> the pending tags refer to pending the packages being signed with the Fedora GPG key
<Son_Goku> in RPM distributions, we sign the packages themselves, so that they are cryptographically verifiable no matter how you got the package
<Son_Goku> uhh
<Son_Goku> morphis: you messed up golang-gopkg-retry-v1
<Son_Goku> https://koji.fedoraproject.org/koji/rpminfo?rpmID=9416927
<morphis> how?
<Son_Goku> look at the Provides
<morphis> %{import_path_sec} ?
<Son_Goku> yeah
<Son_Goku> you used a macro that's not defined
<morphis> hm
<morphis> time for an update then :-)
<Son_Goku> incidentally, please don't do commit reverts
<Son_Goku> you can just incrementally commit like any other git repo
<morphis> Son_Goku: isn't that what I do with a revert? but ok if that is considered a bad practise
<Son_Goku> well, for imports it's bad
<Son_Goku> because then no one can tell the actual change in the spec you did
<Son_Goku> btw, why does this obsolete gocheck?
<Son_Goku> morphis: I think you forgot to remove some stuff :)
<morphis> yeah
<morphis> Son_Goku: didn't we go through the review process :-)
<Son_Goku> you didn't tell me you didn't generate it with gofed
<Son_Goku> I don't look too much into gofed-generated specs because they're complex and usually correct
<morphis> Not this one, the gettext one is; this one didn't pass gofed because its using gopkg.in and has two identities
<morphis> Son_Goku: however, look at the top two commits in http://pkgs.fedoraproject.org/cgit/rpms/golang-gopkg-retry-v1.git/
<Son_Goku> looks good to me now
<morphis> lets see what the build says
<Son_Goku> you'll need to bump the release
<Son_Goku> and add to the changelog
<Son_Goku> once a successful koji build has occurred, you can never reuse the EVR again
<morphis> yeah on that already
<morphis> Son_Goku: f24 branches are there now too
<mup> PR snapd#3100 opened: tests: fix interfaces-cups-control for zesty (#3035) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3100>
<ogra_> kyrofa, indeed it should, but since it is full of binaries and ubuntu-image doesnt complain it does technically not matter if it is armhf ... thanks for the pointer though
<mup> PR snapd#3099 closed: configstate,hookstate: timeout the configure hook after 5 mins, report failures to the errtracker <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3099>
<zyga> morphis: hey, can you please have a look at https://github.com/snapcore/snapd/pull/3095
<mup> PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095>
<Son_Goku> zyga: mixing C and Go like this seems like it'd make things worse rather than better
<morphis> zyga: sure
<zyga> morphis: thanks
<mup> PR snapd#3100 closed: tests: fix interfaces-cups-control for zesty (#3035) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3100>
<morphis> zyga: so why are we mixing C and Go code here?
<zyga> morphis: because go cannot do what we want
<zyga> morphis: see the comment up fron the bootstrpa.go
<zyga> bootstrap.go
<zyga> morphis: if go had any control over threads we could
<zyga> morphis: but alas, no
<morphis> ah I see you use a constructor
<morphis> tricky ..
<morphis> was searching the actual call to bootstrap from the Go code
<zyga> morphis: yes, it's tricky but that's the only way we found to achieve this
<morphis> is that a limitation of setns?
<morphis> or a bug?
<zyga> morphis: note that this is the 2nd approach
<zyga> morphis: it's a feature, that's how setns is documented to work
<morphis> I see
<zyga> morphis: the 1st approach was all-C but the complexity of the code kept growning
<zyga> morphis: and we had 1000s of lines of tests and code that would be far far shorter in go
<mup> PR snapd#3029 closed: snapstate: introduce helper to apply to disk a alias states change for a snap (aliases v2) <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3029>
<morphis> zyga: reviewed
<morphis> Son_Goku: https://koji.fedoraproject.org/koji/rpminfo?rpmID=9416966 looks much better
<Son_Goku> yep
<morphis> Son_Goku: let me get builds for everything else
<zyga> morphis: thank you :-)
 * zyga has stuff to do now
<morphis> zyga: np
<morphis> zyga: btw. I see my deb builds for snapd failing because my shellcheck on xenial does not know about -x
<morphis> zyga: looks like you changed that recently
<morphis> zyga: is it intended that shellcheck isn't pulled in for the deb build?
<zyga> morphis: ah, I noticed that too
<zyga> morphis: yes, shellcheck is absent on 14.04 and I think it's not that critical anymore
<zyga> morphis: we have less and less shell code
<morphis> zyga: however with it installed the tests fail for me :-)
<zyga> morphis: yeah, we'd have to check if shellcheck groks -x
<mup> PR snapd#3101 opened: cmd: explicit use of snapd sockets (for 2.23) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3101>
<zyga> morphis: but I was too lazy to do that TBH (at the time)
<morphis> zyga: ok, so we should have an explicit --disable-shellcheck in debian/rules until we have that
<morphis> as otherwise a shellcheck present on the build host causes the build to fail
<zyga> morphis: well, that's also too much, just DTRT or remove shellcheck
<zyga> morphis: I wonder if shellcheck sans -x is actually useful
<zyga> morphis: maybe just check if shellcheck exists *and* supports -x
<zyga> morphis: than again, maybe not, -x is needed for out-of-tree builds AFAIR
<morphis> for now I removed shellcheck from my host but actually this is a problem we need to fix one or another way
<ogra_> ppisati, i have added a linux-raspi2 task to bug 1674509 ... seems the documented overlays that should switch UARTs for BT use do not work
<mup> Bug #1674509: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 <Snappy:Confirmed> <linux-raspi2 (Ubuntu):Confirmed> <https://launchpad.net/bugs/1674509>
<LinAGKar> I don't seem to be able to run any graphical snaps on OpenSUSE Tumbleweed
<ogra_> zyga, ^^ ?
<LinAGKar> For example when trying to run keepassxc I get:
 * LinAGKar sent a long message: LinAGKar_2017-03-29_11:21:22.txt - https://matrix.org/_matrix/media/v1/download/matrix.org/NYEoBtzLLcrJlbDYTqgPCHzA
<ogra_> LinAGKar, is the x11 interface connected for the app ? perhaps SuSE doesnt auto-connect it ... check with "snap interfaces"
<LinAGKar> It says:
<LinAGKar> :x11                      dwarf-fortress,keepassxc
<morphis> Son_Goku: which karma level should I set for my bodhi requests?
<King_InuYasha> morphis: "1"
<King_InuYasha> new packages can't possibly have any terrible effect on things, so setting stable karma to "1" is fine
<morphis> ok
<morphis> both for stable and unstable?
<King_InuYasha> morphis: for all branches you're making a bodhi update to, yes
<King_InuYasha> it should be 1 / -3 for the autokarma settings
<morphis> King_InuYasha: thanks!
<zyga> ogra_: hey, who had issues with X/Display?
<morphis> Son_Goku: ok, bodhi requests are out now; added all in https://docs.google.com/document/d/1l9xS8RqSSjASNEIcHAOanlURNrpmfodf4Fd79QXdLG4/edit
<LinAGKar> zyga: I did
<mup> PR snapd#3052 closed: overlord: remove snap config values when snap is removed <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3052>
<mup> PR snapd#3102 opened: interfaces/mount: add function for parsing mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3102>
<King_InuYasha> zyga, morphis: if you've tried the new build of golang-github-go-tomb-tomb like I have, you can leave positive feedback+karma to get the ball rolling: https://bodhi.fedoraproject.org/updates/?packages=golang-github-go-tomb-tomb
<morphis> King_InuYasha: sounds good!
<zyga> LinAGKar: hey
<zyga> LinAGKar: sorry for the lag, I was away
<zyga> LinAGKar: can you tell me more
<zyga> LinAGKar: I suspect you use KDE, is that correct?
<zyga> King_InuYasha: I'll try it back in the office, I didn't bring my VMs on the road today
 * ogra_ imagines zyga to have a bag with VMs in them ... 
<zyga> ogra_: really a HDD
<LinAGKar> Hi
<LinAGKar> zyga: I do use KDE
<LinAGKar> zyga: When I try to run keepassxc I get:
<LinAGKar> No protocol specified
<LinAGKar> QXcbConnection: Could not connect to display :0
<LinAGKar> Avbruten (SIGABRT)
<LinAGKar> Or for dwarf-fortress I get:
<LinAGKar> Gtk-Message: Failed to load module "canberra-gtk-module"
<LinAGKar> No protocol specified
<LinAGKar> Display not found and PRINT_MODE not set to TEXT, aborting.
<mup> PR snapd#3103 opened: interfaces/mount: add function for parsing fstab-like file <Created by zyga> <https://github.com/snapcore/snapd/pull/3103>
<LinAGKar> This is on OpenSUSE Tumbleweed, with snapd from the snappy OBS repo
<AndyS2> oh, seems like it builds on opensuse now. interesting, that's why I originally joined this channel. thanks for the info, LinAGKar
<LinAGKar> zyga: From snap interfaces I get this: https://pastebin.com/vqLxV0zd
<Son_Goku> niemeyer: does snapd's sources offer an API for things to build off of?
<Son_Goku> as a golang library, I mean
<niemeyer> Son_Goku: Heya
<niemeyer> Son_Goku: Yeah, let me get you a link
<Son_Goku> hey
<niemeyer> Son_Goku: https://godoc.org/github.com/snapcore/snapd/client
<zyga> LinAGKar: thanks, I think I know what this is about
<zyga> LinAGKar: can you check if you have /tmp/.Xauthority file?
<zyga> morphis: ^^
<zyga> LinAGKar: (sorry for being disconnected earlier)
<LinAGKar> zyga: I do not have that
<mup> PR snapd#3104 opened: tests: fix unity test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3104>
<zyga> LinAGKar: hmm, curious
<zyga> LinAGKar: ok, which distribution relaease are you on?
<LinAGKar> zyga: Tumbleweed, it's rolling release
<Son_Goku> zyga: I've got snapd built on Fedora for rawhide locally
<Son_Goku> 2.23.5
<Son_Goku> with nine patches
<coreycb> hi, for snappy config schema, am i right to assume that eventually i'll be able to snap install xyz with a specific config schema, in order to set specific configs at install time?
<zyga> LinAGKar: Ack, can you please report a bug on the systems:snappy repository
<zyga> LinAGKar: we'll try the KDE build and debug it
<zyga> LinAGKar: (I was using gnome out of habbit)
<zyga> Son_Goku: anything serious?
<zyga> Son_Goku: try out some snaps if you can
<zyga> Son_Goku: but this feels like something that we will release soon
<Son_Goku> I will, but I have to go to work first :)
<ogra_> zyga, could it be that our xauth setup is a bit more losely defined than suses ? iirc we have a pretty lose setup for localhost
<zyga> Son_Goku: understood, thank you, a *lot*  :-)
<zyga> ogra_: yes, perhaps
<zyga> ogra_: but I remember seeing something that fails in KDE
<zyga> ogra_: but works in GNOME
<ogra_> yeah, might not be that
<zyga> Son_Goku: FYI: https://forum.snapcraft.io/t/towards-working-snap-update-ns/23 :-)
<zyga> ogra_: because I checked tumbleweed in gnome and it was all good
<ogra_> right, was just a thought
<Son_Goku> zyga: I'd like to have most of these patches merged in some form in an upstream release :/
<Son_Goku> by the way, I don't see a PR or a commit resembling the change for making snap-confine internal lib use libtool?
<zyga> Son_Goku: I have that patch in suse, I'll try to merge it buuut we may not be able to
<zyga> Son_Goku: because there's another PR that adds fine-grained control (per lib) of what to link in statically
<Son_Goku> so that PR will supersede it?
<zyga> Son_Goku: anyway, I'm sure morphis will have a lot of fun upstreaming that :)
<LinAGKar> zyga: Bug report here: https://bugzilla.opensuse.org/show_bug.cgi?id=1031501
<mup> PR snapd#3098 closed: cmd: select what socket to use in cmd/snap{,ctl} <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3098>
<mup> PR snapd#3101 closed: cmd: explicit use of snapd sockets (for 2.23) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3101>
<morphis> Son_Goku, zyga: I am working through sorting all these patches so only have a minimal set downstream in the distributions
<morphis> that is also highly necessary to be able to build packages later on in CI
<zyga> morphis: can you please look into that bug ^^
<zyga> morphis: thanks for working on the patches!
 * zyga needs to get into the car, brb
<morphis> zyga: will do
<Son_Goku> morphis: https://github.com/Conan-Kudo/snapd/commit/ad2f6b49603b920b7de13b0431587857d31aca86 (clean), https://gitlab.com/Conan_Kudo/fedorapkgs-snapd/tree/snapd-pkg-dev (actual tree)
<Vktn> Somebody here?
<Vktn> I need help
<Vktn> I wanted to install deepin music player in linux mint 18.1
<Son_Goku> morphis: if it passes my basic sanity tests (that is, I can run some dead-simple snaps), then I'll prepare the update today
<morphis> Son_Goku: 0008, 0007 can be dropped once we have 2.24
<morphis> Son_Goku: awesome!
<morphis> Son_Goku: 0006 too
<Son_Goku> patches 0001, 0004, 0007, and 1001 have not been merged in some form
<Vktn> @Morphis can you help me
<nothal> Vktn: No such command!
<morphis> Son_Goku: for 0007 there is a PR
<Vktn> Buddy the thing is I am installing in snap form
<morphis> Son_Goku: https://github.com/snapcore/snapd/pull/3096
<mup> PR snapd#3096: many: abstract path to /bin/{true,false} <Created by morphis> <https://github.com/snapcore/snapd/pull/3096>
<Son_Goku> morphis: I'm aware, see comments :)
<morphis> Son_Goku: don't see any on that PR :-)
<Vktn> Its stuck on "run configure hook of core snap if present"
<morphis> Vktn: what is the problem you have?
<Son_Goku> look at my gitlab repo spec file: https://gitlab.com/Conan_Kudo/fedorapkgs-snapd/blob/snapd-pkg-dev/snapd.spec
<morphis> Vktn: on which distribution you see this problem?
<Vktn> Linux mint 18.1
<morphis> Son_Goku: ah good
<Vktn> I know snap is not completely supported
<morphis> Vktn: you seem to be running into a bug we're currently fixing
<Vktn> But I still tried to install by first installing package snapd as suggested by someone on reddit
<Vktn> Ok thanks buddy
<Vktn> It would be helpful if you give me some more information
<Vktn> Is it just because of linux mint
<Vktn> ?
<Son_Goku> Vktn: no, it's because snapd comes from Ubuntu for mint
<Son_Goku> and the bug affects ubuntu
<Vktn> Ok thanks buddy :)
<Vktn> Somebody's also having same problem on mail-archive.com
<mup> PR snapd#3105 opened: tests: download previous snapd package from published versions instead of specific PPA <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3105>
<ogra_> Son_Goku, we rolled back the affected core snap in the stable channel
<morphis> Son_Goku: not necessarily, this is more what we see where AppArmor doesn't work
<ogra_> so nobody should actualyl see it unless they are not using stable
<pedronis> mvo: niemeyer: do you think I can reapply the bits of my overlord reorg that I reverted to help with 2.23.6 ? IÂ need to make snapstate changes and I think they would be better done after that is reapplied
<Vktn> https://www.mail-archive.com/snapcraft@lists.snapcraft.io/msg02782.html
<morphis> ogra_: I feel this is more https://bugs.launchpad.net/snappy/+bug/1674193
<mup> Bug #1674193: core snap's configuration hangs on debian | openSUSE | mainline kernel <Snappy:In Progress by morphis> <snapd (Debian):New> <snapd (Fedora):In Progress> <snapd (openSUSE):Fix Released by morphis> <https://launchpad.net/bugs/1674193>
<niemeyer> pedronis: Can you open a topic for that with details?
<ogra_> morphis, ah, right, there were two issues
<niemeyer> pedronis: (what PRs, etc)
<morphis> ogra_: right, so in this case we run into the problem that the configure hook calls snapctl
<morphis> and AppARmor + Seccomp are enabled for the snapd package in Mint
<ogra_> yeah, i remember
<morphis> so snapctl gets killed by seccomp
<morphis> ogra_: and https://github.com/snapcore/snapd/pull/3101 is what should fix this
<mup> PR snapd#3101: cmd: explicit use of snapd sockets (for 2.23) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3101>
<morphis> ogra_: however in cases like Mint we now have the problem that people run into this problem still and I don't see a clear migration path
<ogra_> yeah
<ogra_> well, update snapd is obviously the path :)
<ogra_> we just need to release it
<morphis> ogra_: yes
<morphis> ogra_: and problem is that we can even recommend manually adding bind to the seccomp profile as it will be regenerated on every core snap updated ..
<morphis> Vktn: we're about to release snapd 2.23.5 which will fix that problem which mainly is one on distributions having AppArmor disabled and seccomp on which is the case for Mint
<Son_Goku> morphis: anyway, while I'm at work, please work on trying to get the patch situation resolved: https://gitlab.com/Conan_Kudo/fedorapkgs-snapd/blob/snapd-pkg-dev/snapd.spec#L49-65
<jdstrand> morphis: note https://github.com/snapcore/snapd/pull/3101 is the proper fix for this
<mup> PR snapd#3101: cmd: explicit use of snapd sockets (for 2.23) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3101>
<jdstrand> morphis: and https://github.com/snapcore/snapd/pull/3098
<mup> PR snapd#3098: cmd: select what socket to use in cmd/snap{,ctl} <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3098>
<Son_Goku> morphis: also leave feedback for the golang-github-go-tomb-tomb package in bodhi
<morphis> jdstrand: right, but will not help people being blocked by the bug it fixes right now unitl 2.23.6 lands
<jdstrand> morphis: both merged now
 * jdstrand nods
<morphis> Son_Goku: sure but we wont get them all in for 2.23.x
<morphis> we can drop them with followup upstream releases
<Son_Goku> morphis: I just want them all in master
<jdstrand> morphis: but it is nice that a simple core update will resolve it
<morphis> Son_Goku: before we release a package to fedora?
<jdstrand> that's all I meant
<Son_Goku> morphis: yes it's fine
<morphis> jdstrand: yes
<Son_Goku> morphis: well it doesn't matter about that
 * jdstrand hugs mvo for fixing that and the noisy denial in on shot
<Son_Goku> but ideally I need something for documenting all the patches
<Son_Goku> morphis ^
<Son_Goku> snapd moves too quickly for out of tree patches to be sustainable
<morphis> +1
<morphis> we only have on left so I will take care
<Son_Goku> so at the minimum, I need PRs
<Son_Goku> ideally, they would all be merged into master :)
<Son_Goku> anyway, g2g
<Son_Goku> bye
<zyga> Son_Goku: o/
<Son_Goku> zyga: hi
<Son_Goku> zyga: quick catchup: I need at least all patches listed here to have PRs: https://gitlab.com/Conan_Kudo/fedorapkgs-snapd/blob/snapd-pkg-dev/snapd.spec#L49-65
<Son_Goku> ideally, all of those should be merged in master
<Son_Goku> I do not mind carrying patches, I do mind carrying them forever
<morphis> Son_Goku: if you just need a PR, that's a minute work :-)
<Son_Goku> morphis: at LEAST a PR
<mup> PR snapd#3106 opened: tests: enable docker test for more ubuntu-core systems <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3106>
 * mvo hugs jdstrand for his excellent analysis of the problem
<pedronis> going ahead (https://forum.snapcraft.io/t/finish-overlord-reorg-to-enable-further-work/37/3)
<kyrofa> ogra_, if you use snapcraft to build and then release, it ends up in the armhf set of channels, which means when you use ubuntu-image to build (and specify arm64), ubuntu-image doesn't find it. Are you building in a different way?
<ogra_> nope, weridly it pulls the right stuff from the store for me
<ogra_> kyrofa, you are using https://github.com/snapcore/dragonboard-gadget right ?
<kyrofa> ogra_, indeed
<ogra_> oh, and i see you changed it there
<kyrofa> ogra_, well, I _offered_ to change it there ;)
 * zyga goes to pick up kids from school
<ogra_> yeah, mvo was fast and already merged it
<kyrofa> Oh nice. I haven't gone through my emails yet
<ogra_> ogra@dragonboard:~$ snap info dragonboard|grep refresh
<ogra_> refreshed:   2016-10-28 13:04:19 +0200 CEST
<ogra_> ugh
 * ogra_ notes that we have actually never used the GH one then
<ogra_> so tomorrows dragonboard edge image will be interesting :)
<kyrofa> Ha!
<mup> PR snapd#3107 opened: overlord: finish reorg, revert "be more conservative until we have cut 2.23.x" <Created by pedronis> <https://github.com/snapcore/snapd/pull/3107>
<pmcgowan> jdstrand, crap does unity8 trigger manual review? I added it back thinking it was ok now
<jdstrand> pmcgowan: yes, it is reserved for Canonical employees
<jdstrand> "The 'unity8' interface is in development and not yet ready for production. Please remove from your snap's plugs and feel free to reupload. After that your snap should pass automated review."
<jdstrand> that is what we say to non-Canonical ^
<pmcgowan> jdstrand, ok but I need to wait for a review now? would be happy to reupload
<jdstrand> pmcgowan: you are a Canonical employee. you can either remove it, or I can add a snap decl
<jdstrand> note if I grant it, you'll get an email that says "Granting use of the 'unity8' interface to Canonical employee. Note that this interface is not complete and subject to break applications at any time."
<jdstrand> :)
<pmcgowan> :)
<pmcgowan> let me remove it and re-upload jdstrand
* ogra changed the topic of #snappy to: Package any app for any Linux desktop, server, cloud or device. Read how on http://www.snapcraft.io | File a bug: https://bugs.launchpad.net/snappy/+filebug, join the snapcraft discussion https://rocket.ubuntu.com/channel/snapcraft | Join the forum: https://forum.snapcraft.io
<pedronis> mvo: niemeyer: proposed https://github.com/snapcore/snapd/pull/3107
<mup> PR snapd#3107: overlord: finish reorg, revert "be more conservative until we have cut 2.23.x" <Created by pedronis> <https://github.com/snapcore/snapd/pull/3107>
<pmcgowan> jdstrand, how do I get those out of the review queue? I rejected the first one
<mup> PR snapd#3108 opened: cmd: use libtool for the internal library <Created by morphis> <https://github.com/snapcore/snapd/pull/3108>
<pmcgowan> rejected them all then
<jdstrand> pmcgowan: ok. yeah, there is a mechanism in the web frontend of the store to reject them that it seems you found
* ChanServ changed the topic of #snappy to: Join the forum: https://forum.snapcraft.io/t/when-to-use-forum-vs-irc/38
<ogra> err
* ogra changed the topic of #snappy to:  Package any app for any Linux desktop, server, cloud or device. Read how on http://www.snapcraft.io | File a bug: https://bugs.launchpad.net/snappy/+filebug, join the snapcraft discussion https://rocket.ubuntu.com/channel/snapcraft | Join the forum: https://forum.snapcraft.io
<mup> PR snapd#3109 opened: Merge 2.23.6 release back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/3109>
<kyrofa> Hey jdstrand, what is the rationale for requiring manual review of gadget snaps? They're completely unusable without creating an image seeded with it, right?
<ogra> kyrofa, probably to make sure nobody steals the name
<jdstrand> kyrofa: cause the necessary assertions dictated by the design of the system aren't implemented yet
<jdstrand> kyrofa: in other news, I approved your snap earlier if you didn't see
 * ogra saw it on G+ :)
<ogra> uappexplorer is very helpful there :)
<kyrofa> ogra, that's registration
<ogra> yeah, indeed
<kyrofa> jdstrand, ahh, makes sense okay
<kyrofa> jdstrand, I did see, thank you! Now my images generate
<morphis> mvo: does 2.23.6 enable reexecution from core again?
<morphis> mvo: seeing snap crashing in cmd.ExecinCoreSnap() on Yocto with 2.23.6
* ChanServ changed the topic of #snappy to: Join the forum: https://forum.snapcraft.io/t/when-to-use-forum-vs-irc/38
<morphis> mvo: this is when using the current beta core snap
<niemeyer> ogra: Can we please keep the simpler topic for a while.. we can revert after a few days, once the regulars here are aware
<niemeyer> (or we can keep it as well.. let's see what happens)
<mvo> morphis: it has not chnaged anything, maybe we need to blacklist on yocto
<mvo> morphis: blacklist re-exec there - what kind of crash do you get?
<niemeyer> mvo, morphis: Good topic for the forum thread?
<ogra> niemeyer, well, that sigles out the snapcraft people as well as hiding the docs
<morphis> mvo: https://mm.gravedo.de/files/crash-yocto.png
<niemeyer> ogra: The topic is dynamic.. we can bring it back later
<morphis> niemeyer: :-)
<zyga> morphis: you need to add yocto to a blacklist to have that
<niemeyer> ogra: My hope is also that the snapcraft developers come along
<zyga> morphis: reexec is on by default
<morphis> ahh
<niemeyer> ogra: For the same reasons stated in that topic
<ogra> niemeyer, well, a forum is not a chat ...
<ogra> but we'll see
<niemeyer> ogra: Actually, according to the real definition of "chat", it is
<ogra> heh, well, lets agree to disagree on that one :)
<niemeyer> ogra: You'll need to disagree with the dictionary rather than with me
<niemeyer> ogra: We could be having that unnecessary discussion there just as well.. I'm glad we're not, though. :)
 * niemeyer steps out for lunch
<ogra> heh
<morphis> mvo, zyga: where is the blacklist in snapd?
<zyga> morphis: I think in cmd/cmd.go
<morphis> ok
<morphis> zyga: and here it gets tricky ..
<morphis> we can't really predict what the release id is for Yocto based systems
<morphis> so SNAP_REEXEC it means here
<zyga> morphis: that's fine, we will support a reference yocto image
<zyga> morphis: and over time the reasons for having the blacklist will go away
<zyga> morphis: it's just a temporary measure
<morphis> zyga: what means temporary? one release cycle?
<niemeyer> Sorry, came back quickly just to not leave snapcraft in a bad place in the forum
<niemeyer> kyrofa, sergiusens, ogra: https://forum.snapcraft.io/c/snapcraft
<zyga> morphis: a few cycles
<niemeyer> Let's please have a hangout at some point today to discuss more details of this initiative
 * niemeyer back to lunch
<morphis> zyga: sounds like "later this year"
<zyga> morphis: once we have CI for yocto (reference) we can add that
<zyga> morphis: and once the issues are fixed we can remove that entirely
<zyga> niemeyer: the forum died?
<zyga> https://forum.snapcraft.io/ gives me "network error"
<ogra> works here
<zyga> morphis: with you on board I think that's faster
<morphis> zyga: hah :-)
<zyga> morphis: we have snap-confine that's detached from reexec
<zyga> morphis: and we have known ways to fix that
<zyga> morphis: we also need to have snap-confine talk to snapd better
<zyga> morphis: then we have no issues
<morphis> zyga: let me do a distro-patch for now
<zyga> morphis: for blacklist? feel free to merge that back
<morphis> will do
<morphis> zyga: btw. the open-suse bug exists on 42.2 too, so its not wayland
<zyga> morphis: are you sure? maybe 42.2 has wayland too/
<zyga> morphis: btw, fedora 25 has wayland/gnome as default
<zyga> morphis: worth checking
<morphis> it doesn't
<morphis> its using xcb platform here so no wayland natively in KDE
<zyga> morphis: aha
<zyga> morphis: well, so it's not wayland
<pedronis> niemeyer: IÂ created a topic around the things we discussed after standup: https://forum.snapcraft.io/t/transactionality-locking-and-other-concurrency-coordination/50
<zyga> morphis: curious what it might be
<morphis> zyga: looking
<mup> PR snapd#3110 opened: cmd: add poky to the list of distros which don't support reexec <Created by morphis> <https://github.com/snapcore/snapd/pull/3110>
<morphis> zyga: ^^
<zyga> morphis: perfect, thanks
<niemeyer> pedronis: Woah, sweet!
<morphis> zyga: this is a KDE specific problem, same distro using gnome shell those apps work
<morphis> zyga: I have the feeling there is some disagreement between what the Qt/gtk version in those snaps expect and what they get from KDE in this case
<niemeyer> pedronis: Do you have at hand the etherpad link for the snap aliases discussion we had?  I want to complete the topic about it including the user experience we discussed (or a tweaked version of it)
<pedronis> niemeyer: we have the gdoc , it probably needs a bit of edits after what we discussed yesterday though
<niemeyer> pedronis: Found it, thanks!
<morphis> seb128: ping
<mup> PR snapd#3111 opened: snapd: initial implementation for systemd software watchdog for snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/3111>
<mup> PR snapd#3107 closed: overlord: finish reorg, revert "be more conservative until we have cut 2.23.x" <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3107>
<LinAGKar> zyga: I don't seem to be able to run those apps under GNOME either (I'm now on my desktop with Leap 42.2 BTW). Maybe it has something to do with, KDE being installed first, or with SDDM?
<morphis> Pharaoh_Atem: I've pushed a PR for the last patch without a PR reference, see https://github.com/snapcore/snapd/pull/3108
<mup> PR snapd#3108: cmd: use libtool for the internal library <Created by morphis> <https://github.com/snapcore/snapd/pull/3108>
<jdstrand> kyrofa: hey, can you see if installing turtlebot-demo-kyrofa auto-connects the interface? either pc or dragonboard is fine
<kyrofa> jdstrand, sure, I'll generate a new image now and try it
<jdstrand> kyrofa: curious. is the demo snap preinstalled?
<kyrofa> jdstrand, indeed
<jdstrand> I don't know if this is going to help then. morphis saw issues with preinstalled snaps and auto connection
<jdstrand> and that was without a snap decl involved
<kyrofa> Hmm... that somewhat defeats the purpose of my blog series, haha! Let me try and see
<kyrofa> jdstrand, I guess it depends on how snapd deals with that on boot, eh?
<kyrofa> If this image doesn't work, I'll make an image without it preinstalled and see if it auto-connects upon install
<jdstrand> kyrofa: I could do the snap decl for the gadget (slot) or the app (plug). I chose the gadget, but can also try it for the app
<kyrofa> jdstrand, alright, I'll keep you in the loop here, see if we can't get this to happen
<jdstrand> kyrofa: fyi, here is the bug about not being able to do this in the gadget snap: https://bugs.launchpad.net/snappy/+bug/1644074
<mup> Bug #1644074: auto connect none auto-connect interfaces of snaps in gadget snap <Snappy:New> <https://launchpad.net/bugs/1644074>
<kyrofa> jdstrand, oh darn, I logged one too against snapd
<jdstrand> I didn't know the one I just pasted existed (just found it looking for another bug)
<kyrofa> Yeah, I've stopped looking in the snappy project :P
<kyrofa> I logged bug #1677015
<mup> Bug #1677015: My app snap's plug is not auto-connected to my gadget snap's slot <snapd:New> <https://launchpad.net/bugs/1677015>
<kyrofa> jdstrand, hey hey, your snap decl change worked
<jdstrand> oh!
<jdstrand> nice :)
<kyrofa> jdstrand, did you do it for both gadgets?
<jdstrand> I did
<kyrofa> jdstrand, wonderful, thank you :)
<jdstrand> np
 * jdstrand updates wiki for instructions on working around lack of gadget auto-connect with snap decls
<kyrofa> jdstrand, what is the logic in the snap decl exactly: "this app snap can automatically connect to my slot" ?
<kyrofa> Similarly, if you did it from the app snap side: "I can automatically connect to that gadget snap's slot" ?
<jdstrand> kyrofa: in each of the gadget snaps, there is this snap decl: http://paste.ubuntu.com/24275679/
<jdstrand> kyrofa: (for the slot)
<kyrofa> Ah ha, okay same page
<jdstrand> kyrofa: from the app's side, I'd use the slot-snap-id in the plugs
<kyrofa> With the gadget's snap ID
<jdstrand> kyrofa: I chose the gadget's snap decl since I figured that it is better mimicking what we are working around: ie, the gadget saying what can autoconnect
<kyrofa> Indeed
<kyrofa> And agreed
<kyrofa> jdstrand, I'm going to write the list with a summary email with some of the issues encountered during this process, just want to make sure I understand
<jdstrand> kyrofa: sounds great
<kyrofa> jdstrand, does that snap decl apply to updates, as well?
<kyrofa> jdstrand, pedronis any idea what this means? task.go:303: DEBUG: 2017-03-29T17:26:45Z ERROR cannot deliver device serial request: Cannot process serial request for device with brand "4tSgWHfAL1vm9l8mSiutBDKnnSQBv0c8", store can sign serial only for brand "canonical"
<kyrofa> My demo snap stops running after that, it seems
<zyga> kyrofa: it means that you have a custom gadget snap
<zyga> kyrofa: and as the brand owner you need to deploy a serial vault to sign assertions from your devices
<zyga> kyrofa: the one from canonical doesn't sign assertions from other brands
<kyrofa> zyga, any reason why that would halt my app service?
<zyga> kyrofa: it would not
<zyga> kyrofa: this is just a debug log from snapd
<mup> PR snapd#3110 closed: cmd: add poky to the list of distros which don't support reexec <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3110>
<zyga> kyrofa: but maybe a bug related to this fact is affecting something else
<zyga> kyrofa: suggestion to use the forum :)
<jdstrand> kyrofa: fyi, I see the same thing on bbb from ogra. it doesn't seem to affect anything functionally
<ogra> what did i break ?
<ogra> :)
<zyga> ogra: you didn't deploy a serial vault for bbb
<jdstrand> ogra: nothing. just saying your bbb gadget throws up the same debug message as kyrofa's gadget
<ogra> yeah, because my last name isnt canonical
<ogra> :)
 * jdstrand notes that kyrofa thought the debug message might be causing a problem. I was reassuring him it doens't seem to
<kyrofa> jdstrand, I'm not sure... whenever I first boot, my service starts running fine, then I see http://pastebin.ubuntu.com/24275842/
<kyrofa> The service spams the logs, but once that print happens it stops showing anything and the bot stops moving
<kyrofa> The service is still running though.... something weird is happening here
<zyga> ogra: you make a mistake here, it's *your* brand now, the bbb gadget is not owned by canonical
<ogra> zyga, ?
<zyga> ogra: you said your last name is not canonical
<ogra> yes, the model assertion is completely created by me
<jdstrand> kyrofa: idk, just saying I have a service that doesn't suffer from that
<zyga> ogra: so you own it
<ogra> zyga, yeah, my last name is grawert ;)
<zyga> ogra: and you can deploy a serial valut
<ogra> oh, can i ? (and should i )
<jdstrand> zyga: is that documented somewhere? /me wonders if kyrofa would want to document that as well
<jdstrand> meh
<ogra> brand and authority id's are min as is the gadget
<zyga> ogra: you can and probably should over time
<ogra> **mine
<jdstrand> if kyrofa would want to blog about that as well
<ogra> zyga, i never had any probs due to it
<kyrofa> jdstrand, zyga I don't even know enough about the serial vault to know why I'd want one
<zyga> jdstrand: I don't think it is; I know CE makes some customer documentation that could be read and trascribed into a public format
<zyga> ogra: yet :)
<zyga> kyrofa: it's something that signs your serial assertion
<kyrofa> zyga, why do I care?
<zyga> kyrofa: when a new device shows up it creates a serial assertion
<ogra> (i noticed the message above though ... but since all bits of the image work reliable i never bothered about it)
<zyga> kyrofa: and asks the brand "here, sign this so that you ack my existence"
<zyga> kyrofa: and then you know that you have a device that the brand really blessed
<zyga> kyrofa: (not a knock-off or something)
<pedronis> kyrofa: that should be a read herring, not something that blocks anything else in the system
<ogra> right
<pedronis> s/read/red/
<ogra> though we should have documentation for it :)
<zyga> kyrofa: your brand seems like random garbage though
<zyga> ogra: yes, definitely
<kyrofa> zyga, isn't that why the model assertion is an assertion, so that I know I'm booting a real image?
<ogra> in case you actually want it blessed
<zyga> kyrofa: model assertion is just a model assertion
<zyga> kyrofa: anyone can slap that on a fake device
<kyrofa> zyga, but it's signed
<zyga> kyrofa: but anyone can copy it :)
<pedronis> kyrofa: not really, assertions are not secrets, they don't grant auth without some context
<ogra> right, the brand-id needs to match the signer of the gadget
<pedronis> you can take a device copy out it's model assertion etc
<ogra> so at least on that level there is some blessing going on
<zyga> kyrofa: e.g. company inc makes 1000 devices in factory inc; the factory now runs 2nd batch and sells them for 30% off
<zyga> kyrofa: now company inc has twice the support cost and no QA over half of the laptop with its logo
<zyga> kyrofa: serial assertion lets you see and respond to that
<ogra> pedronis, well, we just learned that your firstboot wont set up the gadget if the signatures dont match
<pedronis> ogra: well yes, your brand-id and auth-id on the model must match
<ogra> pedronis, so there is *some* brand-id vs gadget signature
<kyrofa> zyga, is this something done store side? Or is the "vault" some third-party software?
<zyga> kyrofa: because if you ordered 1000 devices and you see 2000 boot you know someone's faking something
<zyga> kyrofa: vault is a 3rd party software
<pedronis> ogra: yes, but has nothing to do with tha log or the serial
<ogra> indeed
<zyga> kyrofa: it's literally called serial-vault AFAIR
<ogra> thats cherry on top stuff :)
<zyga> kyrofa: (well, 1st party but not the store)
<pedronis> ogra: it's the new rule IÂ was asked to implement that gadget publisher and model signer need to match unless the gadget comes from canonical
<kyrofa> zyga, right, heh, same page
<zyga> kyrofa: CE wrote tat
<zyga> that*
<ogra> pedronis, yeah, and i remember when we discussed that in heidelberg ... serial is just an additional security measure on top
<pedronis> serial is super relevant mostly if you want to have controlled access to a branded store
<ogra> right
<pedronis> (we really would like most thing to have a serial, but that's the main purpose atm)
<ogra> but not for a home brewed developer image
<pedronis> no
<pedronis> as I said that log be benign
<ogra> so kyrofa and i should both be fine as is
<pedronis> if other things are not aligned it's a different matter
<ogra> yeah
 * zyga EODs
<zyga> see you later guys
<pedronis> kyrofa: model assertion authority-id must == brand-id  and gadget publisher ( != canonical) must be == brand-id , if the gadget is from canonical doesn't matter
<pedronis> same for custom kernels well
<kyrofa> pedronis, right
<mup> PR snapd#3094 closed: cmd: rework header check for xfs/xqm.h <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3094>
 * pedronis afk
<kyrofa> Alright, nevermind guys-- seems to be an issue with the USB passthrough to my VM. As soon as I disconnect/reconnect it things start working
<kyrofa> pmcgowan, did I see that you were able to unpublish a single revision of your snap?
<kyrofa> pmcgowan, if so, how? I don't see an obvious way to do it
<pmcgowan> kyrofa, I cleared a failed one from the review queue
<pmcgowan> kyrofa, button way at the bottom of the page
<kyrofa> pmcgowan, oh, not an already published rev?
<pmcgowan> no but I know there is a way to do that, isnt it just the button at the top?
<kyrofa> pmcgowan, doesn't that unpublish the entire snap?
<kyrofa> pmcgowan, I was afraid to press it :P
<pmcgowan> kyrofa, I havent done it but I know it can be done
<jdstrand> don't press that
<pmcgowan> lol
<jdstrand> :)
<kyrofa> Hahaha
<pmcgowan> kyrofa, I was going to offer to try one here
<kyrofa> jdstrand, do you know how to do this?
<jdstrand> I thought it was in there too and I just looked but didn't see it
<kyrofa> Huh. Maybe I need nessita to do it manually?
<jdstrand> I thought it was specific to a revision. I suspect it can't have ever been released
<kyrofa> I released my gadget on the wrong arch at first. I'd like to remove that rev
<pmcgowan> kyrofa, I just unpublished all my versions :(
<kyrofa> pmcgowan, agh, I knew that was a dangerous-looking button
<pmcgowan> but I know you can do it
<kyrofa> Hey nessita, I accidentally published revision 1 of dragonboard-turtlebot-kyrofa targeting armhf, when it should have been arm64. Revision 2 is correct, but rev 1 is still available for armhf. There doesn't seem to be a way for me to remove it myself-- can you help me?
<nessita> kyrofa, right, unpublishing is not defined for snaps, you need to release a new revision to that channel, or close the channel
<kyrofa> nessita, can I close all channels for a given arch?
<nessita> kyrofa, hum, no, channel closing is per channel :-/
<nessita> kyrofa, what channel you released to?
<kyrofa> nessita, stable, for both armhf and arm64. I just want the arm64 one
<pmcgowan> kyrofa, so once they are all unpublished you can selectively release them again
<pmcgowan> kyrofa, but rather tricky since the dates not listed in the summary
<kyrofa> pmcgowan, ah ha! Brilliant! I only have two revs, that's easy
<nessita> kyrofa, hum, I can't change the status of the revision in any simple way. Can you try closing stable and then releasing a new amd64 revno to stable?
<kyrofa> nessita, pmcgowan's suggestion seems to have worked-- I just unpublished the whole thing, and then published only rev 2
<kyrofa> Thanks pmcgowan :)
<pmcgowan> great
<nessita> kyrofa, ahaha that button is super closed to be removed, you just reminded me :-D
<nessita> thanks
<nessita> (is just there for clicks)
<kyrofa> nessita, whew, made it just in time! :P
<nessita> yeah :-)
<kyrofa> nessita, thanks for your time
<nessita> kyrofa, sorry I couldn't be of more help
<kyrofa> My upload speed to people.canonical is so bad...
<kyrofa> Oh what do you know, as soon as I whine it perks up a bit
<kyrofa> Nope... back to 100k
<pmcgowan> nessita, which button, unpublish? that seems quite useful, would be better if it was version/arch specific
<nessita> pmcgowan, the snap design does not allow for unpublishing (unreleasing), and is really a risk that someone unpublishes without wanting to
<nessita> pmcgowan, people have complained about how risky it is
<pmcgowan> nessita, I would concur on that, but sometimes we have reverted a publish
<pmcgowan> guess it will require a new version now
<nessita> pmcgowan, yes, you need to release a new revision to the channel, or close it
<pmcgowan> nessita, how is closing a channel different from unpublishing
<pmcgowan> risk wise
<nessita> pmcgowan, unpublishing removes all revnos from all channels. Closing a branch makes it show the content of the channel "above" it because of channel tracking (this is valid for all channels but stable, when closing stable it just gets emptied)
<nessita> pmcgowan, imagine a very complex matrix of released revnos to many series, many archs, many channels including tracks and hotfixes
<nessita> you can have more than 100 released revisions
<pmcgowan> indeed
<nessita> imagine unpublishing them all
<nessita> *by mistake*
<nessita> imagine you have paying customer depending on availability of that snap
<nessita> so, way too risky
<pmcgowan> agreed
<nessita> while closing a specific channel affects only revision in that track/risk/hotfix channel
<kyrofa> jdstrand, I made a forum post instead of a ML post: https://forum.snapcraft.io/t/issues-encountered-while-creating-custom-gadget-and-image/66
<mup> PR snapcraft#1225 opened: channels: Fix staging store test for Tracks <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1225>
<jdstrand> kyrofa: nice
<mup> PR snapcraft#1205 closed: asset-tracking: track source VCS details <Created by josepht> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1205>
<cachio> jdstrand, any idea about this error ?
<cachio> [81414.597898] audit: type=1400 audit(1490820896.938:1993): apparmor="DENIED" operation="exec" profile="snap.kpi-ubuntu-app-platform-tests.load" name="/lib/x86_64-linux-gnu/ld-2.23.so" pid=10908 comm="ldd" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
<cachio> jdstrand, snappy debug is giving me this http://paste.ubuntu.com/24277039/
<jdstrand> cachio: that should be allowed by this rule: /lib/@{multiarch}/ld{,32,64}-*.so    mrix,
<jdstrand> cachio: where are you seeing this? what is the output of apparmor_parser -p /var/lib/snapd/apparmor/profiles/snap.kpi-ubuntu-app-platform-tests.load |grep multiarch | grep '/ld'
<cachio> jdstrand,  /{usr/,}lib/@{multiarch}/ld{,32,64}-*.so    mr,
<cachio> I see this executing "sudo snappy-debug.security scanlog"
<jdstrand> cachio: what ubuntu release?
<cachio> zesty
<cachio> jdstrand, zesty
<jdstrand> cachio: ok, so classic distro?
<cachio> jdstrand, yes
<jdstrand> cachio: oh, the rule you have doesn't include 'ix'
<cachio> jdstrand, I see that, but how I should do to add that ix
<cachio> jdstrand, I am using content interface to read the libs directory
<jdstrand> that rule comes from the apparmor base abstraction
<jdstrand> let me see if I can track it down
<mwhudson> hi is there an eta on the next snapd release?
<jdstrand> cachio: is kpi-ubuntu-app-platform-tests not published anywhere?
<cachio> jdstrand, no yet
<cachio> I can share it
<kyrofa> jdstrand, the review tools flag a symlink to libc6 on ppc64 as an error
<kyrofa> jdstrand, no other arch, though
<kyrofa> jdstrand, specifically, a symlink to /lib/powerpc64le-linux-gnu/ld-2.23.so
<jdstrand> cachio: it's an apparmor bug introduced in r3593.1.6
<cachio> jdstrand, ok, bad news for me
<cachio> any workaround?
<cachio> jdstrand, do you have the bug id?
<jdstrand> cachio: you can sed the profile in /var/lib/snapd/apparmor/profiles to add back the ix. can you file a bug?
<cachio> jdstrand, sure, where in snappy?
<jdstrand> cachio: no, apparmor
<jdstrand> https://bugs.launchpad.net/apparmor/+filebug
<jdstrand> tyhicks: the zesty apparmor upload is breaking snaps due to r3593.1.6
<jdstrand> tyhicks: see cachio's denial
<cachio> jdstrand, sorry but I have to leave now, I'll be back in 1 hour
<cachio> jdstrand, I'll raise that issue, thanks for the support
<kyrofa> jdstrand, note that the symlink itself is named lib64/ld64.so.2
<jdstrand> kyrofa: do you have the snap?
<kyrofa> jdstrand, I do
<kyrofa> Let me make it available
<jdstrand> kyrofa: is it in the store?
<jdstrand> you can just give me the link to the revision
<kyrofa> jdstrand, actually wait... is the click-reviewers-tools in the xenial archives up to date?
<jdstrand> kyrofa: no
<jdstrand> zesty is
<jdstrand> kyrofa: but I think I see the issue. I just need the snap
<kyrofa> jdstrand, sent via PM
<tyhicks> jdstrand: I'm busy with something else at the moment but I'll be able to read backscroll soon
<jdstrand> kyrofa: ok, fixed in trunk. if the publisher/you request a manual review, I can accept it
<kyrofa> jdstrand, excellent, thank you!
<jdstrand> tyhicks: we should probably discuss in #apparmor
<jdstrand> cachio_afk: fyi, we are discussing this in #apparmor on OFTC. I'm not able to reproduce. when you file the bug, please give complete instructions, ideally with a downloadble snap and access to its source code
<kyrofa> jdstrand, alright, if I want to test a profile change, I add it to the profile in /var/lib/snapd/apparmor/profiles, and then... what? How do I reload it again?
<jdstrand> kyrofa: sudo apparmor_parser -r /path/to/profile
<kyrofa> jdstrand, thank you!
<kyrofa> jdstrand, sweet, /dev/input/js* is all I need
<kyrofa> jdstrand, you mentioned to refer to framebuffer for implementation and gave me a link to bug #1675738, but it seems like work is ongoing to remove udev tagging. Should I not worry about that aspect, then?
<mup> Bug #1675738: OpenGL interface should udev tag all /dev/fb* files <snapd-interface> <snapd:In Progress> <https://launchpad.net/bugs/1675738>
<mup> PR snapcraft#1166 closed: tests: Fix name registration window limit test to latest changes <Created by fgallina> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1166>
<mup> PR snapd#3112 opened: interfaces: add a joystick interface <Created by kyrofa> <https://github.com/snapcore/snapd/pull/3112>
<kyrofa> jdstrand, there's my crack at it ^^
<slangasek> does someone here know why I have /etc/ld.so.conf.d/conjure-up.conf on my system, pointing at /snap/conjure-up/156/usr/lib/x86_64-linux-gnu/ ?
<slangasek> a directory which contains an incompatible version of libapt-pkg.so?
<cachio_afk> jdstrand, sure, I'll upload the snap
#snappy 2017-03-30
<mup> Bug #1677417 opened: /etc/ld.so.conf.d/conjure-up.conf breaks apt on host system <Snappy:New> <conjure-up (Ubuntu):New for adam-stokes> <https://launchpad.net/bugs/1677417>
<mwhudson> who can help me with tracks in the store?
<zyga> mwhudson: maybe open a store side question on the forum?
<mwhudson> zyga: did the forum get mentioned on the mailing list yet?
<zyga> mwhudson: it's metioned in the topic here :)
<mwhudson> yes, that's the only place i've seen it mentioned
<zyga> mwhudson: I think it will replace the mailing list entirely
 * mwhudson gives an old man sign
<mwhudson> *sigh
<mwhudson> https://forum.snapcraft.io/t/can-someone-set-up-guardrails-for-the-go-snaps-tracks/72
<mwhudson> also autopublishing to tracks from launchpad would save me a lot of effort :)
<morphis> mwhudson: ping
<mwhudson> morphis: hi
<morphis> mwhudson: hey! how are things? :-)
<mwhudson> morphis: not bad!
<morphis> mwhudson: sounds good, I saw you're one of the maintainers of snapd in debian
<mwhudson> morphis: yeah
<morphis> mwhudson: any concrete plans to update the package real soon?
<mwhudson> morphis: no, debian is in freeze
<morphis> don't we have a package in unstable too?
<mwhudson> morphis: i thought re-execing in the core snap mostly meant i didn't have to
<mwhudson> well yeah but life is easier if stable and unstable don't diverge aiui
<zyga> mwhudson: I think we could file an RC bug because we need to ship something or the package is totally broken :/
<mwhudson> i could upload a newer one to experimental
<mwhudson> zyga: right, if we need to fix this core snap hanging thing with a new package, we need to do that
<morphis> mwhudson: we had a few serious issues recently which are now patched in snapd 2.23.6, though I didn't checked yet if debian is affected
 * zyga reboots to try new pulseaudio 
<morphis> mwhudson: let me try the current snapd package in testing
<mwhudson> morphis: i've not dealt with the politics of getting a release exception in debian
<morphis> mwhudson: ok, so lets see if we an avoid this :-)
<mwhudson> morphis: but it's at least possible that targeted fixes will be an easier sell than a wholesale upgrade
<mwhudson> or not, i don't know
<morphis> mwhudson: I think if there are single fixes needed to get snapd in debian re-exec into the one coming from the core snap we can do that
<morphis> zyga: https://bugzilla.opensuse.org/show_bug.cgi?id=1031501#c3
<zyga> morphis: looking
<zyga> morphis: so 1) this will only work if home interface is connected (it doesn't even have to be used)
<zyga> morphis: why does every non-snap app work?
<zyga> morphis: there must be a different auth mechanism that is being tried
<zyga> morphis: it fails and xauthority is a workaround
<morphis> maybe
<morphis> that is what I am currently looking into
<morphis> zyga: it wouldn't even work with the home interface connected as it doesn't allow you to use .XAuthority
<morphis> it only works in this case because we have no confinement at all
<zyga> morphis: ah, right
<morphis> zyga: ok, it gets interesting, XAUTHORITY is set to /tmp/xauth-1000-_0 in KDE on suse
<morphis> zyga: are we doing any processing of the env vars when we spawn up the snap environment?
<morphis> no, as it seems, it ends up the snap in the snap env
<zyga> morphis: aha
<zyga> morphis: see
<zyga> morphis: it is /tmp related :)
<morphis> zyga: flatpak is doing some extra stuff here
<morphis> see https://sources.debian.net/src/flatpak/0.8.4-3/common/flatpak-run.c/?hl=1944#L1924
<zyga> morphis: yes, I think we need to extra stuff for x11 and pulseaudio
<zyga> morphis: that feels like snap-confine's work
<zyga> morphis: you could read the xauth config on startup
<zyga> morphis: and after dropping privs write the file into the fresh /tmp
<zyga> morphis: (remember that tmp is empty)
<morphis> zyga: right
<morphis> similar to what flatpak does
<zyga> morphis: yeah
<zyga> morphis: right now I'd code it in C directly
<zyga> morphis: but I sooomewhat worry about how many hacks like this we'll need
<zyga> morphis: I suspect that a bound set so this is oK
<zyga> morphis: if it starts to look like each new interface needs this we may have to think about snapd assisting via a backend
<morphis> zyga: right
<morphis> zyga: lets start with a hack into snap-confine
<morphis> actually this is kind of a problem and wondering if the KDE guys didn't experienced this problem with their snaps
<morphis> zyga: let me take this problem as part of my cross-distro work
<morphis> Son_Goku: ping
<Son_Goku> pong
<Son_Goku> :/
<morphis> Son_Goku: you saw the PR for the missing not upstream patch?
<Son_Goku> yes
<Son_Goku> I already added the comment to my spec
<morphis> good
<Son_Goku> I'm rebasing to 2.23.6, since you guys released that yesterday :/
<morphis> Son_Goku: :-)
<Son_Goku> and I've already been bitten patchwise
<morphis> in which way?
<Son_Goku> the systemd unit template PR doesn't apply cleanly onto 2.23.6
<Son_Goku> the rules file hunks all fail
<Son_Goku> so I've been purging those manually from the patch
<morphis> yeah those things are nasty
<morphis> Son_Goku: so really time to get them all dropped :-)
<morphis> Son_Goku: I am trying to get that solved with 2.24
<Son_Goku> is seccomp still broken for 2.23.6?
<Son_Goku> morphis ^
<morphis> Son_Goku: we have fixed one bug but I fear there might be more
<Son_Goku> so still broken, yay :(
<morphis> not directly broken
<morphis> but as AppARmor is disabled we may run into situatuions where things would have been blocked already by AppArmor and not run into seccomp denials which lead to hanging processes like we had for snapctl
<morphis> Son_Goku: once we're done with the basic packaging bits I will start working on getting proper CI up for fedora/debian/suse/..
<morphis> then we have a much safer way of handling and testing those things and can ensure they keep working
<Son_Goku> I feel like banging my head into the ground with all this shit... :/
<Son_Goku> alright, I'm turning back on seccomp and damn the consequences
<morphis> Son_Goku: things will be much easier once we have all patches upstream
<morphis> and confinement is on my list too
<Son_Goku> I hate golang so much
<Son_Goku> it just adds so much complication to things
<morphis> :-)
<Son_Goku> I used to merely dislike golang, now I hate it
<seb128> hey morphis, sorry I was not around when you pinged yesterday and it was a contentless ping so couldn't reply when I came back ... I guess it was about that KDE/opensuse issue you are discussing on the list and now here?
<morphis> seb128: right, I thought you might be one who knows what is going on but I've figured the real problem already: https://bugs.launchpad.net/snapd/+bug/1677513
<mup> Bug #1677513: snap-confine does not pass file referenced by XAUTHORITY env variable into the snap environment <snapd:Confirmed for morphis> <https://launchpad.net/bugs/1677513>
<morphis> seb128: didn't checked KDE on Ubuntu yet but they might set XAUTHORITY to something in /run or /home too
<morphis> seb128: but thanks for the late pong :-)
<seb128> np, glad that you figured it out :-)
<Son_Goku> well, here we go...
<Son_Goku> morphis: https://koji.fedoraproject.org/koji/taskinfo?taskID=18678557
<morphis> Son_Goku: awesome!
<pedronis> mvo: #3109 is mergeable, no?
<morphis> Son_Goku: will give this some testing once ready
<Son_Goku> oh crap
<Son_Goku> I just realized something
<morphis> ?
<Son_Goku> I need to pull in my snapctl patch
<Son_Goku> for selinux
<Son_Goku> that was almost certainly not merged back in to 2.23.6
<Son_Goku> not knocking on mvo, but this was not exactly something he cared about for merging back into releases before
<morphis> Son_Goku: ah, is that one already in master?
<Son_Goku> yes
<morphis> ok, another one we can drop with 2.24 then..
<Son_Goku> since the debubuntu packages don't ship the selinux module as a subpackage yet, he has no way of knowing or caring about changes to it
<morphis> right
<morphis> Son_Goku: this will get better once we have CI also caring about fedora
<Son_Goku> I doubt it
<Son_Goku> it'll be hard to spot selinux backport things because the domain is in permissive mode
<morphis> I see
<morphis> something I need to dive into at a later point
<Son_Goku> generally, selinux policy module changes should be assumed to be backported, I think
<Son_Goku> as they are generally reactive from when you guys change something, rather than proactive
<mvo> Son_Goku: hey, sorry that some bits did not get backported, we want to do a 2.24 soon though. we did the 2.23.6 mostly to ensure we have some important bugfixes out before moving on. once 2.24 lands things should move more normal again, i.e. things in master also go into the release etc
<Son_Goku> mvo: no worries
<Son_Goku> I blame morphis anyway :P
<Son_Goku> (not really!)
<morphis> Son_Goku: :-D
<Son_Goku> anyway, I expect that this will get better, vis-a-vis the selinux module, once someone adds the packaging for it to debubu packaging
<Son_Goku> what I'm going to hate doing is packaging DNF debian-style for snapcraft
<Son_Goku> I despise Debian-style packaging (I consider it way more complicated than it should be)
<Son_Goku> it's not that I don't know how to do it... I certainly do
<Son_Goku> after all, I used to use Ubuntu for years and almost became a Debian/Ubuntu contributor many years ago
<Son_Goku> fuck
<Son_Goku> snapd FTBFS on i686
<Son_Goku> and ppc64
<Son_Goku> well, at least it built on ppc64le
<Son_Goku> https://koji.fedoraproject.org/koji/taskinfo?taskID=18678723
<morphis> Son_Goku: ah, I have a fix for that one
 * Son_Goku groans
<morphis> Son_Goku: https://github.com/snapcore/snapd/pull/3094
<mup> PR snapd#3094: cmd: rework header check for xfs/xqm.h <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3094>
<Son_Goku> yay
<Son_Goku> more patches
<morphis> Son_Goku: with that everything should build fine, verified with https://copr.fedorainfracloud.org/coprs/mrmorph/snapcore/
<Son_Goku> you don't have a fix for ppc64, though
<morphis> which doesn't build for ppc but for i386
<morphis> yeah looking into that one ..
<morphis> Son_Goku: can I easily cross build with mock?
<Son_Goku> no
<Son_Goku> mock does not support foreign arches like that yet
<Son_Goku> BUT
<Son_Goku> Fedora offers contributors access to ppc64 VMs
<morphis> ah
<Son_Goku> morphis: I suggest hopping into #fedora-ppc and asking about it
<morphis> Son_Goku: will do, need to care about a few other things first
<morphis> pedronis: what retry interval do we have in snapd currently to reach the serial-vault as configured from the prepare-device hook?
<pedronis> morphis: 1 minutes for dynamic errors,  for things that look like the vault is not understanding a back off starting from 5 minutes and then doubling up to a max
<Son_Goku> morphis: and joy of joys
<Son_Goku> armv7hl failed too
<morphis> pedronis: ok, but we don't block the further first-boot process when we can't the server, right?
<morphis> Son_Goku: wonderful ..
<Son_Goku> full list of failures: https://koji.fedoraproject.org/koji/taskinfo?taskID=18678723
<pedronis> morphis: first boot is completely independent, they are even two different changes
<pedronis> morphis: what we block is the fist refresh for a bit
<pedronis> we try to refresh witha serial if possible
<pedronis> but after a while try anyway
<Son_Goku> morphis: it looks like arm failed because of same issue with i686
<morphis> pedronis: ok, just wanted a confirmation on this
<morphis> Son_Goku: yeah, which is a "good" thing :-)
<Son_Goku> morphis: added patch, and trying again: https://koji.fedoraproject.org/koji/taskinfo?taskID=18678977
<morphis> Son_Goku: great
<zyga> mvo: can you please have a 2nd look at https://github.com/snapcore/snapd/pull/3102
<mup> PR snapd#3102: interfaces/mount: add function for parsing mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3102>
<Son_Goku> morphis: now i686 just fails to compile :(
<Son_Goku>   /usr/include/xfs/xfs.h:51:12: error: size of array 'xfs_assert_largefile' is too large
<Son_Goku>  extern int xfs_assert_largefile[sizeof(off_t)-8];
<Son_Goku> morphis: you need to go back to the drawing board on this
<zyga> I see you two are having fun :)
 * Son_Goku groans
<Son_Goku> I wanted this to be released already
<Son_Goku> I want the buildsys to stop telling me that snapd-glib is broken
<zyga> I start to see light at the end of my tunnel
<zyga> with the move to go the coding moves faster than before
<morphis> Son_Goku: hm, this worked for me well in Yocto ..
<Son_Goku> I see crushing sadness and dispair
<Son_Goku> morphis: Yocto is bullshit
<morphis> Son_Goku: lets not get into this discussion, please :-)
<Son_Goku> Yocto can be whatever you want, so it doesn't really serve as a great means of comparison
<morphis> Son_Goku: you have a link to the last build?
<zyga> Son_Goku: I think the more interesting fact is that it built on 32bit debian
<Son_Goku> zyga: Debian has older compiler
<zyga> Son_Goku: sid?
<zyga> Son_Goku: very doubtful
<Son_Goku> has debian moved onto GCC 7 yet?
<Son_Goku> as far as I knew, they were still on 6.3.x
<zyga> Son_Goku: yes
<Son_Goku> are you using hardened build flags there?
<zyga> https://packages.debian.org/experimental/gcc-7
<Son_Goku> because Fedora does by default
<zyga> Son_Goku: I don't know
<Son_Goku> I know Debian does not
<zyga> but dones't look like related to what the error above says
<zyga> it does look like the size of off_t is the relevant factor here
<zyga> but TBH
<zyga> this is all load of BS
<Son_Goku> zyga: anyway, gcc-defaults in sid is gcc6
<zyga> because we should just check if that header file exists
<Son_Goku> https://packages.debian.org/sid/gcc
<zyga> all we need are _constants_
<zyga> morphis: feel free to hardcode those as those are kernel constants and kernel is not insane to change
<zyga> morphis: and drop libxfsprogs-devel from dependencies
<Son_Goku> morphis, zyga: https://koji.fedoraproject.org/koji/taskinfo?taskID=18678977
<Son_Goku> the green, orange, and red links are clickable :)
<zyga> the ppc one is interesting, checking
<morphis> zyga: you propose that as an upstream change? :-)
<Son_Goku> here's a previous failed build, too, prior to adding snap-confine patch: https://koji.fedoraproject.org/koji/taskinfo?taskID=18678723
<zyga> morphis: as a distro change and upstream change later
<zyga> morphis: I see no reason to check linkability or work around this issue
<zyga> morphis: if we care about a hanful of constants
<morphis> Son_Goku: ok, this looks different now
<Son_Goku> the failures are possibly caused by newer libxfs
<morphis> maybe
<Son_Goku> Fedora has xfsprogs 4.10.0
<Son_Goku> Debian has xfsprogs 4.9.0
<Son_Goku> since we update the kernel, we also update the tools too
<morphis> Son_Goku: my guess is that we should get this building with add -D_FILE_OFFSET_BITS=64 to CFLAGS
<Son_Goku> patch?
<morphis> Son_Goku: something like https://paste.ubuntu.com/24280132/ but didn't tested it yet
<Son_Goku> easy to test, I can just fire off a scratch build for it
<Son_Goku> okay, I'm getting super sick of this
<Son_Goku> someone needs to turn off OpenID auth on raw pastes
<Son_Goku> morphis: if no one fixes that, please stop using paste.ubuntu.com
<morphis> :-)
<zyga> Son_Goku: I bet there's a reason for that
<Son_Goku> zyga: I don't care
<Son_Goku> it's stupid and aggravating and I can't curl anything
<Son_Goku> morphis: please use paste.fedoraproject.org, if you need an alternative
<Son_Goku> there's also a handy fpaste utility for pasting from the CLI :)
<Son_Goku> https://pagure.io/fpaste
 * zyga wonders why not pastebinit + config
<Son_Goku> well, I didn't know about pastebinit :)
<zyga> it supports many paste services
<zyga> simple python script AFAIR
<Son_Goku> it has a fpaste config
<Son_Goku> though I don't know if it works with the new pastebin software fedora deployed recently: https://fedoramagazine.org/hello-modern-paste/
<morphis> Son_Goku: looks nice
<zyga> Son_Goku: I honestly don't like the new paste, there was a looot of negative feedback after it was rolled out
<zyga> Son_Goku: I need to try it again though, I think/hope some of that feedback was addressed
<Son_Goku> I don't care for it's look and the superlong URLs
<zyga> Son_Goku: the URLs were totally broken wrt basic usaility
<zyga> *usability
<Son_Goku> morphis: trying a scratch build with your diff: https://koji.fedoraproject.org/koji/taskinfo?taskID=18679354
<morphis> ok
<morphis> ah
<morphis> it wont work
<morphis> needs to be = instead of +=
<morphis> Son_Goku: sorry for that
<morphis> Son_Goku: https://paste.fedoraproject.org/paste/-NaL-TKvNct9~lx1tvVDdl5M1UNdIGYhyRLivL9gydE=
<Son_Goku> does that mean all the hardening flags are clobbered?
<morphis> no
<morphis> if we add AM_CFLAGS then they are there
<morphis> Son_Goku: so something like https://paste.fedoraproject.org/paste/k6OU-DUhS5tSIQ5cglQP7F5M1UNdIGYhyRLivL9gydE= is more correct
<morphis> Son_Goku: this fork functionality is quite nice
<Son_Goku> yes, it is
<zyga> ogra: how do you reply with a quote on discourse?
<ogra> zyga, just mark something in the text then a "quote" thing pops up
<ogra> you also earn a new badge with it ;)
<zyga> aah, nice!
<zyga> thanks!
<Son_Goku> morphis: take 2: https://koji.fedoraproject.org/koji/taskinfo?taskID=18679427
<morphis> Son_Goku: lets hope this now works ..
<Son_Goku> since arm takes too long, I'm going to assume it works if i686 does
<Son_Goku> then you can prepare a formal PR and I can have a formal patch and we can try again for all arches
<zyga> ogra: heh, my quote didn't really work :)
<Son_Goku> I wish our discourse supported social sign on
<zyga> fixed now
<zyga> ogra: have a look at https://github.com/snapcore/core-build
<Son_Goku> (not Ubuntu SSO, but normal SSO, like Google, Twitter, GitLab, GitHub, etc.)
<zyga> ogra: what else do we need there?
<zyga> Son_Goku: I think it doesn't upstream and that's why we don't have it here
<Son_Goku> weird
<zyga> Son_Goku: and as a plugin it is not supported from what I heard
<zyga> Son_Goku: I think there's a thread about that actually
<Son_Goku> hm
<zyga> Son_Goku: no, let's start one
<Son_Goku> the Rust forum uses social sign-on, I think
<Son_Goku> yeah, Rust uses GitHub
<zyga> https://forum.snapcraft.io/t/support-for-sso-on-forum-snapcraft-io/75
<Son_Goku> one of the other ones I know of uses Google
<morphis> Son_Goku: looks like the patch apply failed this time
<Son_Goku> :/
<zyga> ogra: https://forum.snapcraft.io/t/gardening-in-github-com-snapcore-core-build/76
<Son_Goku> morphis: fixed the patch, but it didn't work
<morphis> Son_Goku: you have the full patchset somewhere?
<morphis> let me create the patch on top of that
<Son_Goku> morphis: the patch set is http://pkgs.fedoraproject.org/cgit/rpms/snapd.git/tree/ + https://da.gd/qUH4P
<morphis> Son_Goku: https://paste.fedoraproject.org/paste/AFR94F40CNQwmk3eFcy4Rl5M1UNdIGYhyRLivL9gydE= should cleanly apply on top of the patchset
<Son_Goku> yes, but it still doesn't fix the problem
<Son_Goku> oh wait
<Son_Goku> la
<ogra> zyga, if you mention me in the post you dont need to ping on IRC ;)
<ogra> (was already writing an answer when you pinged)
<zyga> ogra: aha, you get destkop notifications on @-mentions?
<Son_Goku> morphis: take 4: https://koji.fedoraproject.org/koji/taskinfo?taskID=18679552
<ogra> zyga, yeah
<morphis> Son_Goku: we're coming closer :-)
<morphis> Son_Goku: ok, this didn't help
<morphis> Son_Goku: need to scratch my head around this when I am done with my meetings
<mup> PR snapd#3113 opened: overlord/snapstate: unlock/relock the state less, especially not across mutating the SnapState of a snap <Created by pedronis> <https://github.com/snapcore/snapd/pull/3113>
<pedronis> Chipaca: you might want to look at snapd#3113 when one have a moment, it's not big, it's the changes about locking discussed yesterday
<mup> PR snapd#3113: overlord/snapstate: unlock/relock the state less, especially not across mutating the SnapState of a snap <Created by pedronis> <https://github.com/snapcore/snapd/pull/3113>
<Chipaca> pedronisâ looking
<mvo> pedronis: yes, 3109 is mergable
<mvo> zyga: sure, I have a look at the fstab thing
<mup> PR snapd#3109 closed: Merge 2.23.6 release back into master <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3109>
<pedronis> mvo: done
<ogra> zyga, https://github.com/snapcore/core-build/pull/1
<mup> PR core-build#1: adjust README file to proper reflect repo content <Created by ogra1> <https://github.com/snapcore/core-build/pull/1>
<mvo> pedronis: ta
<zyga> ogra: +1
<Chipaca> pedronisâ +1; lgtm and good start
<zyga> Chipaca: care to do a 2nd review of https://github.com/snapcore/snapd/pull/3102
<mup> PR snapd#3102: interfaces/mount: add function for parsing mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3102>
<Chipaca> zygaâ nah
 * Chipaca grins
<zyga> Chipaca: et tu Brutus?
<zyga> ;-)
<Chipaca> zygaâ et ideam habent quam multa.
<jdstrand> morphis, Son_Goku: things will also get much better when we don't kill the process for a seccomp denial and instead return something like EPERM. this is in progress
<morphis> jdstrand: yeah, that would help
<morphis> jdstrand: however I still fear we will run into multiple bugs with just seccomp and no AppArmor
<morphis> so having some extensive testing before we enable this would be good
<jdstrand> morphis: the sandbox is definitely designed for both to be enabled. enabling seccomp without apparmor isn't really gaining you much
<morphis> jdstrand: right
<jdstrand> morphis: I mean, sure, you can't load a kernel module, but you can write a file to /etc/modules.d
<morphis> jdstrand: so for other systems we need SELinux + Seccomp or nothing
<jdstrand> /etc/modules-load.d
<Chipaca> zygaâ +1 (with a comment)
<jdstrand> morphis: re selinux> yes, though selinux only has rudimentary dbus mediation compared to apparmor
<morphis> jdstrand: yeah sadly, but this is something we need to talk in the near future
<morphis> jdstrand: having this on my road map for cross-distro after I am through all the others things :-)
<jdstrand> morphis: this was actually discussed a good bit in the Hague
<zyga> jdstrand: FYI, overlayfs got good selinux support lately, is that because LSMs got improved or and so apparmor "groks" overlayfs automatically or is that selinux specific, do you know?
<morphis> jdstrand: oh great, seems like I missed that session :-)
<morphis> jdstrand: are there any notes available?
<jdstrand> morphis: I suspect that the list of interfaces available will need to be different for an apparmor enabled system vs an selinux system
<morphis> jdstrand: yeah, maybe
<jdstrand> morphis: it was inconclusive. various problems were identified because of the capabilities of each system and how they both approach MAC differently
<zyga> Chipaca: thanks for the hint, applied!
<jdstrand> morphis: when you are starting to write selinux policy, you'll want to do a hangout with at least me, Tyler and jj
<morphis> jdstrand: absolutely
<Chipaca> zygaâ as i said the compiler is probably good enough nowadays to not make it necessary, but sometimes (like here) it's probably clearer anyways
<zyga> Chipaca: yeah, I really like it, feels pythonic in good way :)
<Chipaca> :-)
<morphis> jdstrand: this is currently somewhere on the horizon but I want to have proper CI for those systems in place first
<Chipaca> zygaâ yeah
<zyga> morphis: I think you could start by trying to run unit tests on snapd build on fedora
<zyga> morphis: that will show looooots of red because of /snap shift
<morphis> zyga: yeah :-)
<zyga> morphis: niemeyer suggested that we add a mock call so that those tests assume /snap is still in place
<zyga> morphis: for spread you will need a different tactics I fear, as those are integration tests
<jdstrand> morphis: it is possible to do things like: the process with this label can talk to the process with that label over dbus with selinux (eg, I can talk to all of network-manager or I can't talk to network-manager at all), but for carving out parts of the dbus api-- no
<zyga> morphis: while not perfect, I had an idea with snapd-fhs package that puts a /snap -> /var/lib/snapd/snap symlink in place
<morphis> zyga: yeah, mock call sounds good, will need to look into that once we're through the current phase of getting distros into shape
<zyga> morphis: as a $0.01 solution
<morphis> zyga: depends if we can that approved by the other distros
<jdstrand> morphis: but there are other issues that aren't at the top of my head
<jdstrand> (even with dbus)
<zyga> jdstrand: are you sure? I saw some fine-grained mediation for dbus + selinux lately (but maybe I was confused)
<zyga> morphis: for spread testing
<zyga> morphis: not for anything else
<morphis> jdstrand: I think we should come together at some point and just brainstorm to see what problems we have and to guess possible solutions
<jdstrand> zyga: patches to dbus deamon?
<morphis> zyga: flatpak uses a proxy for that, maybe they added selinux to that
<zyga> jdstrand: I think to selinux, I saw policy language that was referring to specific methods
 * zyga googles
<jdstrand> if you're talking flatpak, they either write services where the whole api is safe or use a proxy
<morphis> jdstrand: right
<zyga> jdstrand: no, not flatpak
<zyga> jdstrand: I know they use a proxy, it's a different approach altogether
<pedronis> fgimenez: mvo: we are hittingÂ /dev/ram0 issues now in the spread tests
<zyga> pedronis: https://forum.snapcraft.io/t/spread-tests-fail-on-lack-of-dev-ram0/77
<zyga> jdstrand: I cannot find it, all I can find now confirms what you said earlier (no per-method control)
<zyga> it would be nice if selinux supported that actually
<jdstrand> zyga: indeed it would :)
<zyga> jdstrand: the proxy based approach has one advantage, it can be rolled out on any old kernel
<zyga> jdstrand: (and any old dbus)
<zyga> jdstrand: do you think we should write such proxy?
<jdstrand> zyga: but the kdbus discussions showed that people weren't really interested in it
<zyga> jdstrand: in selinux over dbus?
<zyga> jdstrand: I saw that kdbus disposed the xml language too
<zyga> jdstrand: but I wasn't aware of any other details
<jdstrand> zyga: I can't make that recommendation. putting a proxy in front of dbus-daemon would slow things down. it would have to be measured. it is certainly possible
 * Chipaca ~> lunch
<jdstrand> zyga: the gist of the kdbus conversations was that "selinux doesn't do interface/path/member mediation, why should we allow apparmor to do that? either the service is safe or it isn't"
<zyga> jdstrand: hmm, who expressed this view? kernel developers or kdbus developers?
<jdstrand> it's an interesting argument that has merit, but we fell on different sides. we felt it was useful to go to that depth, they (kdbus guys) did not
<jdstrand> zyga: yes
<jdstrand> if you recall, the kdbus discussions were lennart, kay and greg
<zyga> jdstrand: well, I think I agree with kdbus developers for _new_ services written by security aware developers but that's not a good coverage of the software people want to use
<jdstrand> Dan got into it a little bit, but not too much
<zyga> jdstrand: what was his view?
<zyga> (and the flatpak dbus proxy is a perfect example of that)
<jdstrand> you should read the thread
<zyga> jdstrand: is that the kdbus thread? any hints on what to google?
<zyga> mvo: I applied your feedback on https://github.com/snapcore/snapd/pull/3102
<mup> PR snapd#3102: interfaces/mount: add function for parsing mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3102>
<zyga> mvo: if we could merge that I have two more proposals to do on top
<jdstrand> zyga: apparmor and kdbus
<zyga> OK
<zyga> thanks!
<cachio> jdstrand, hey, fyi https://bugs.launchpad.net/apparmor/+bug/1677587
<mup> Bug #1677587: apparmor is denying access to executables shared through content interface <AppArmor:New> <https://launchpad.net/bugs/1677587>
<Son_Goku> jdstrand: there's already a bit of a rudimentary selinux policy in data/selinux
<Son_Goku> it needs beefing up, but at least it's enough to get snapd working
<Son_Goku> snapd can't yet run properly confined :(
<mvo> zyga: looking now, sorry for the delay
<zyga> no worries
 * zyga is a sad panda
<zyga> can't load package: package github.com/snapcore/snapd/cmd/snap-update-ns: use of cgo in test /home/zyga/go/src/github.com/snapcore/snapd/cmd/snap-update-ns/bootstrap_test.go not supported
<mup> PR snapd#3102 closed: interfaces/mount: add function for parsing mount entries <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3102>
<Chipaca> mvo, niemeyer, I'll be missing the standup today
<mvo> Chipaca: no worries
<fgimenez> ogra: snap kernel on edge is ok again \o/ https://travis-ci.org/snapcore/spread-cron/builds/216734158
<mvo> fgimenez: what happend? how did it get fixed?
<zyga> mvo: it was reverted
<zyga> mvo: look at this thread: https://forum.snapcraft.io/t/spread-tests-fail-on-lack-of-dev-ram0/77/16
<zyga> mvo: specifically this https://forum.snapcraft.io/t/spread-tests-fail-on-lack-of-dev-ram0/77/13
<mvo> ta
<jdstrand> cachio: thanks, responded
<jdstrand> Son_Goku: yeah, I was talking about the steps after that-- snap confinement and snap to snap communications
<fgimenez> mvo: yep, it was finally fixed, i'll file a bug about the problem, ogra where should i report it?
<ogra> fgimenez, against linux i guess
<fgimenez> ogra: ok thanks
<sergiusens> stgraber: hey, `lxc image list ubuntu:` doesn't return any 16.04 image (and it seems the aliases are all wonky too)
<jdstrand> roadmr: hi! can you pull r865? this isn't urgent and has code changes (tested of course :). I suggest not rolling out before weekend (ie, follow whatever staging procedures you'd normally use for code changes)
<niemeyer> Chipaca: Ack, thanks for the note
<niemeyer> Hello all
<roadmr> jdstrand: sure! ok, let me check the commit log to see what the changes are about. But I'll have it in SCA trunk in a sec.
<jdstrand> roadmr: code changes aren't extensive, it is just more than the last few pulls I've requested,
<mup> PR snapd#3114 opened: interfaces/mount: add function for saving fstab-like file <Created by zyga> <https://github.com/snapcore/snapd/pull/3114>
<morphis> Son_Goku: hm, when I try to build snapd with mock for rawhide, shouldn't it fetch the golang-* packages we already pushed there?
<morphis> always fails with saying it can't find those deps
<Son_Goku> mirror sync is not complete, I suspect
<Son_Goku> you can create custom mock targets to use
<Son_Goku> I have a fedora-rawhide-x86_64-koji config that I use to access Koji's internal repos, since they are publicly accessible
<Son_Goku> I'll paste it for you
<morphis> thanks
<Son_Goku> morphis: https://da.gd/Oh2U
<Son_Goku> save it as "fedora-rawhide-x86_64-koji.cfg"
<Son_Goku> then do "mock -r </path/to/fedora-rawhide-x86_64-koji.cfg> </path/to/package.src.rpm>"
<morphis> ok
<zyga> Chipaca: hey
<zyga> Chipaca: you around?
<Chipaca> zygaâ with some latency yes
<zyga> Chipaca: can you please eyeyball https://github.com/snapcore/snapd/pull/3103/files
<mup> PR snapd#3103: interfaces/mount: add function for parsing fstab-like file <Created by zyga> <https://github.com/snapcore/snapd/pull/3103>
<zyga> Chipaca: if not too inconvenient
<Chipaca> no probs
<fgimenez> hey pstolowski during the 2.23.6 candidate validation vigo got this error on dragonboard http://paste.ubuntu.com/24281125/ afaik you have been working in this area, could you please take a look when you have a moment?
<zyga> niemeyer: do you think we should have a "casual" category for posts that would not be related to snaps in any way?
<ogra> "gossip"
<ogra> :)
<niemeyer> Hmm.. not sure.. problem is that they'd show in forum.snapcraft.io nevertheless..
<niemeyer> Let me see if there's some sort of "only inside category" setting
<zyga> niemeyer: https://forum.snapcraft.io/t/should-we-have-category-casual-for-daily-chatter/80/1
<zyga> niemeyer: I see longue
<zyga> niemeyer: but not sure if that's one post
<zyga> niemeyer: or a category
<Chipaca> zygaâ +1'ed, with two ignorable notes
<pedronis> niemeyer: I added the comment blocked to snapd#3113 if you want to review
<mup> PR snapd#3113: overlord/snapstate: unlock/relock the state less, especially not across mutating the SnapState of a snap <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3113>
<pedronis> niemeyer: I put the PR link also in the forum
<pedronis> s/blocked/block/
<fgimenez> ogra: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677622
<mup> Bug #1677622: missing ramdisks in latest amd64 kernel snap <linux (Ubuntu):New> <https://launchpad.net/bugs/1677622>
<ogra> fgimenez, great, thx
<niemeyer> pedronis: Ack, thanks
<pstolowski> fgimenez, sorry, i was in another meeting and missed your message. will take a look
<fgimenez> pstolowski: np thanks
<mup> PR snapd#3115 opened: interfaces/unity7: support unity messaging menu <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3115>
<King_InuYasha> zyga: morphis: make sure you guys give feedback on tomb updates: https://bodhi.fedoraproject.org/updates/?packages=golang-github-go-tomb-tomb
<King_InuYasha> morphis: ahh, I see you did
<pstolowski> fgimenez, this is super weird, I don't see a reason for it too fail on one arch and not others. any chance the tests were executed against an older revision of snapd for some reason?
<King_InuYasha> zyga: please do so, so that it'll sync out to stable
<pstolowski> vigo, ^ ?
<fgimenez> pstolowski: i don't think so, dragonboard is notably slower than other platforms, afaik is the only diference, vigo can give you more details
<pstolowski> fgimenez, ah, interesting
<ogra> oh ? dragonboard is slower ?
<ogra> (nobody told me yet)
<vigo> pstolowski, my mistake I though I switched to the new branch
<pstolowski> vigo, ah, so all good?
<vigo> pstolowski, re-running spread tests
<roadmr> hey folks, who can help me with the discourse.snapcraft.io forum? I tried signing up but it's not sending me the confirmation e-mail, so I can't really use it yet :(
<ogra> niemeyer, is the admin ^^^
<roadmr> thanks!
<niemeyer> roadmr: Heya
<niemeyer> roadmr: Let me test the email sending
<roadmr> thanks niemeyer!
<roadmr> let me know if you need me to do anything
<niemeyer> roadmr: Problem is in the system.. I'm probably blowing some quota
<roadmr> oops :(
<stgraber> sergiusens: that would be a CPC problem, the LXD team doesn't control the ubuntu: remote
<mup> PR snapd#3116 opened: interfaces: allow executing ld.so (needed with new AppArmor base abstraction) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3116>
<mup> PR snapd#2833 opened: many: allow core refresh.schedule setting <Created by mvo5> <https://github.com/snapcore/snapd/pull/2833>
<vigo> pstolowski, ping
<vigo> I ran again against current branch in i386 and failed again
<vigo> https://pastebin.canonical.com/184322/
<niemeyer> roadmr: Looks like it was actually my own provider that crashed.. they have a critical announcement saying they're working on it
<niemeyer> roadmr: I've shifted it to Canonical's SMTP.. can you please give it a try now?
<roadmr> oh whoops :)
<roadmr> niemeyer: sure thing, here I go
<niemeyer> roadmr: You _migth_ have received the email already, actually
<roadmr> niemeyer: none of the previous attempts have arrived, I just requested a new one, will wait a bit for it
<niemeyer> roadmr: Thanks
<pstolowski> vigo, hmm ok let me try it locally
<roadmr> niemeyer: still nothing. ~10 mins feels slowish for an e-mail, right?
<ogra> niemeyer, is there a setting in discourse that would open links in additional tabs or new windows ? currently a link i click replaces the forum ....
<ogra> would be nice to have that opening in external pages
<niemeyer> roadmr: Yeah
<pstolowski> vigo, I just run this specific test against master and it passed here; are you running it against current master or a tagged version?
<niemeyer> roadmr: There's definitely something broken, and I'm having  a slightly harder time debugging because my own email is broken due to the provider
<niemeyer> roadmr: Or there's just a big queue
<vigo> pstolowski, np I updated to a non existing branch and lacked tests
<vigo> it is correctly set now
<roadmr> maybe queue + retries
<niemeyer> kyrofa: Did you just get an email from the forum?
<pstolowski> vigo, hmm ok I'm confused now :), so is it all good and passing now after all?
<kyrofa> niemeyer, just now? No
<niemeyer> popey: What about you?
<niemeyer> According to the logs the queue is slowly going out.. but I'm not sure about whether the SMTP host from Canonical has any constraints in terms of origin, etc
<popey> hmm?
<niemeyer> Yep, there we go..
<niemeyer> 	[Sender] 550 relay not permitted
<roadmr> oops :)
<niemeyer> Will need to do something else
<popey> yeah, I have no emails for a while
<popey> I'd recommend using a cloud email provider. flexiondotorg has done this at scale, and knows a good option
<ogra> niemeyer, google smtp ...
<flexiondotorg> No, don't use Google SMTP. Bad thing _will_ happen.
<ogra> oh ?
<flexiondotorg> I use Sendgrid. It's brilliant.
<popey> yeah, you get blocked from google for using it too much
<ogra> what are these bad things ?
<popey> they have very strict limits
<niemeyer> ogra: What is the password there?
<ogra> oh
<flexiondotorg> Google rejects lots of mail.
<flexiondotorg> So the mailing list features of Discourse become unreliable and notifications don't work properly.
<ogra> niemeyer, well, obviously gmail is a bad idea ...
<niemeyer> flexiondotorg: Yeah, that was my idea too (sendgrid), except they deactivated my account for inactivity
<flexiondotorg> Sendgrid is the way to go.
<flexiondotorg> I have tried them all with Discource.
<niemeyer> and guess what, I need email to re-activate it.. #FML
<ogra> lol
<roadmr> hehe :)
<morphis> Pharaoh_Atem, King_InuYasha: lets give https://paste.fedoraproject.org/paste/DMpW-ZW11QIB76FA9DBnEF5M1UNdIGYhyRLivL9gydE= a try
<lool> cjwatson: Hey
<lool> cjwatson: I hope you had a good leave (if you're not back ignore this)
<lool> cjwatson: I had a "store upload failed" for one snap build out of 4, I pressed "Retry" button, upload worked, but snap wasn't published to the channels it was supposed to be published in
<lool> cjwatson: really minor but thought I'd mention it; would you like me to report this somewhere?
<ogra> lool, are you sure it wasnt published ? note there is quite a delay
 * ogra fell for that multiple times in the past 
<lool> ogra: it passed review, and then was ready to publish
<lool> I just clicked in the web UI to do so
<ogra> right, and then between 10 and 20min later it publishes ...
<lool> it had the "thumb up" icon
<ogra> yeah
<lool> and no channel selected
<ogra> i see that at times for the core snap daily build ... but as i said, afetr a while it publishes then
<cjwatson> lool: sure, report that as a Launchpad bug
<kyrofa> ogra, lool I've seen the same 10 minute delay or so
<lool> cjwatson: ok, seems to be normal; perhaps I only saw it because of the retry
<roadmr> jdstrand: hello! oops, "unexpected output" from tools r865...
<cjwatson> lool: so I mean there's the standard problem that we currently have to poll the store to find out when it's done with processing the actual upload, and we don't want to lock up a worker waiting for it, so we poll every so often
<morphis> Pharaoh_Atem, King_InuYasha: lets see how it goes: https://koji.fedoraproject.org/koji/taskinfo?taskID=18684002
<lool> cjwatson: fine with me; I thought I had uncovered a weird case
<jdstrand> roadmr: how did you invoke it?
<jdstrand> roadmr: (I think I know the issue though)
<roadmr> jdstrand: from latest trunk: $ PYTHONPATH=$PWD ./bin/click-review /tmp/hello-classic-tomechangosubanana-1_foo48_amd64.snap
<roadmr> jdstrand: maybe you forgot to bzr add overrides?
<roadmr> because "ImportError: No module named 'clickreviews.overrides'"
<Pharaoh_Atem> morphis: you've already started a scratch build?
<morphis> Pharaoh_Atem: yes
<roadmr> jdstrand: (and I guess the trace is what the store is complaining about).
<morphis> Pharaoh_Atem: tried to a local vm for i386 up but failed .. somehow vbox doesn't want to boot the fedora i386 images
<jdstrand> did I forget to bzr add the file?
<morphis> Pharaoh_Atem: and mock doesn't want to work on lxd
<Pharaoh_Atem> morphis: you could have just done a mock build for i386 on x86_^4
<Pharaoh_Atem> *x86_64
<jdstrand> crap I did
<roadmr> jdstrand: maybe :( so it'd work locally...
<morphis> Pharaoh_Atem: tried this but failed :-)
<morphis> Pharaoh_Atem: need to play a little bit more and look at what I am doing than just doing it next to a meeting
<jdstrand> roadmr: r866. sorry
<roadmr> jdstrand: no problem, at least we caught it quickly :)
<morphis> Pharaoh_Atem: we're coming closer: https://koji.fedoraproject.org/koji/taskinfo?taskID=18684268
<morphis> Pharaoh_Atem: for the ppc64 build I don't have any idea yet
<Pharaoh_Atem> morphis: did you ask for a VM in #fedora-ppc yet?
<morphis> Pharaoh_Atem: not yet
<morphis> mvo, zyga: are we building snapd in ubuntu for ppc64?
<Pharaoh_Atem> morphis: you're not in Debian
<Pharaoh_Atem> but in Ubuntu, you're building against powerpc and ppc64el
<morphis> yeah, just saw that
<morphis> just want to get a baseline for things to look in
<Pharaoh_Atem> I'm *guessing* that powerpc is the < POWER 7 big endian architectures
<Pharaoh_Atem> aka, the 32-bit ones
<nacc> Pharaoh_Atem: yes, BE power
<Pharaoh_Atem> old BE POWER, but yes
<Pharaoh_Atem> morphis: so endianness shouldn't break it :/
<morphis> Pharaoh_Atem: it shouldn't
<morphis> but also we have go 1.6 vs. 1.8
<Pharaoh_Atem> right
<morphis> latest we have in ubuntu is 1.7 in zesty
<morphis> Pharaoh_Atem: sad that the build log doesn't give any error
<morphis> Pharaoh_Atem: also interesting is that this (if the log can be trusted) fails when building golang.org/x/net/context/ctxhtt
<Pharaoh_Atem> well, time to test a theory, I guess
<morphis> Pharaoh_Atem: drop the guy (sharkcz) a mail to get VM access
<Pharaoh_Atem> morphis: you mean you sent him an email
<morphis> yes
<morphis> s/drop/dropped/
<zyga> morphis: yes we do build snapd for ppc64
<morphis> zyga: any idea why https://kojipkgs.fedoraproject.org//work/tasks/4273/18684273/build.log fails?
<morphis> zyga: our last issue on the way to have snapd in rawhide :-)
<renatu> jdstrand, could you please :D? https://myapps.developer.ubuntu.com/dev/click-apps/6676/rev/2/
<zyga> morphis: checking
<zyga> morphis: sorry, where is the error there?
<zyga> that's pretty uncomprehensible to me
<morphis> zyga: that is the question :-)
<zyga> it looks like /usr/lib/golang/pkg/tool/linux_ppc64/compile -o $WORK/golang.org/x/net/context/ctxhttp.a -trimpath $WORK -p golang.org/x/net/context/ctxhttp -complete -buildid dd5b033021ca065fee8c7c29c22a9306c1500731 -D _/usr/share/gocode/src/golang.org/x/net/context/ctxhttp -I $WORK -I /usr/share/gocode/pkg/linux_ppc64 -pack ./ctxhttp.go fails to compile
<morphis> yeah, trying to add a -v to that right now to get more details
<zyga> i'd add --quiet to see less noise
<zyga> and see just "this is what failed"
<morphis> Pharaoh_Atem: did you saw this with your bundled builds too?
<jdstrand> renatu: done
<Pharaoh_Atem> the patches don't apply
<morphis> Pharaoh_Atem: ah
<zyga> why would that be only on one arch?
<Pharaoh_Atem> it's the only big endian arch
<morphis> "patch unexpectedly ends in middle of line"
<morphis> but if something wouldn't apply it would fail the build
<renatu> jdstrand, thanks
<zyga> Pharaoh_Atem: how does that matter for patches?
<renatu> jdstrand, did you add it to whitelist?
<zyga> Pharaoh_Atem: note that this builds on ubuntu, we don't know what really fails as that log is garbage-ish
<jdstrand> renatu: yes
<Pharaoh_Atem> zyga: since the systemd unit patches fail to apply, the build stops
<zyga> Pharaoh_Atem: aha, do we have any arch-specific patches?
<renatu> jdstrand, thanks twice ;)
<Pharaoh_Atem> nope
<Pharaoh_Atem> the patch that failed was the one that rewrites the systemd unit files to use templates
<Pharaoh_Atem> apparently it couldn't find the location to apply the files
<zyga> Pharaoh_Atem: I still don't understand how that only fails on ppc64
 * Pharaoh_Atem shrugs
<zyga> Pharaoh_Atem: I bet I'm missing something :/
<morphis> Pharaoh_Atem: where do you see that in the logs?
<morphis> + /usr/bin/cat /builddir/build/SOURCES/PR3084-packaging-use-templates-for-systemd-units.patch
<morphis> doesn't give any error
<Pharaoh_Atem> https://koji.fedoraproject.org/koji/taskinfo?taskID=18685116
<Pharaoh_Atem> https://kojipkgs.fedoraproject.org//work/tasks/5116/18685116/build.log
<morphis> ah, that is a different build
<Pharaoh_Atem> it fails because mvo strips .gitignore
<morphis> ah so you're talking about the vendorized build?
<Pharaoh_Atem> yes
<morphis> ah :-)
<morphis> that confused zyga I guess
<Pharaoh_Atem> you asked about bundled/vendorized build
<morphis> yeah I know
<morphis> however close to EOD, will look again into this tomorrow morning
<zyga> morphis: you know, just kill ppc64
<zyga> and revisit next time
<morphis> Pharaoh_Atem: ^^
<Pharaoh_Atem> fine
<Pharaoh_Atem> I'll do that for now
<morphis> zyga: you know, I am pragmatic, I am all in for those things :-)
<zyga> while I'd like to see ppc64 flourish the arch is dead dead dead and will stay dead unless something happens
<morphis> :-)
<Pharaoh_Atem> zyga: we do not support s390x, I guess?
<Pharaoh_Atem> or mips?
<zyga> Pharaoh_Atem: s390x is "supported"
<zyga> Pharaoh_Atem: I think at least
<zyga> Pharaoh_Atem: mips no because there's no mips build of ubuntu
<zyga> Pharaoh_Atem: mips would be cool but it seems to be dominated by 4MB flash crap devices
<Pharaoh_Atem> zyga: Fedora is in the middle of a MIPS bootstrap, which is why I asked
<zyga> Pharaoh_Atem: do you know what kind of hardware is used?
<Pharaoh_Atem> not yet, no
<Pharaoh_Atem> I've not talked to Michel about it
<zyga> Pharaoh_Atem: I have a ci20 but I must sadly say it's crap
<zyga> Pharaoh_Atem: the kernel crashes in minutes
<mup> PR snapd#3116 closed: interfaces: allow executing ld.so (needed with new AppArmor base abstraction) <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/3116>
<Pharaoh_Atem> zyga: I need you to retire snap-confine for me
<zyga> Pharaoh_Atem: how do I do that?
<Pharaoh_Atem> zyga: fedpkg co snap-confine && fedpkg switch-branch f24 && fedpkg retire "Merged into snapd" && fedpkg switch-branch f25 && fedpkg retire "Merged into snapd" && fedpkg switch-branch f26 && fedpkg retire "Merged into snapd" fedpkg switch-branch master && fedpkg retire "Merged into snapd"
<Pharaoh_Atem> err
<Pharaoh_Atem> fedpkg co snap-confine && cd snap-confine && fedpkg switch-branch f24 && fedpkg retire "Merged into snapd" && fedpkg switch-branch f25 && fedpkg retire "Merged into snapd" && fedpkg switch-branch f26 && fedpkg retire "Merged into snapd" fedpkg switch-branch master && fedpkg retire "Merged into snapd"
<zyga> Pharaoh_Atem: thanks!
<zyga> Pharaoh_Atem: I'll do that shortly :)
<Pharaoh_Atem> actually, need to change command slightly
<Pharaoh_Atem> one second
<Pharaoh_Atem> I'm going to merge the commit I already made to all branches
<morphis> Pharaoh_Atem: you're going to trigger new builds for snapd now or is that a thing for tomorrow?
<Pharaoh_Atem> I'm doing it now, yes
<morphis> Pharaoh_Atem: great, then we can call out for testing in the community tomorrow
<Pharaoh_Atem> zyga: pkgdb-cli orphan --retire snap-confine f24 && pkgdb-cli orphan --retire snap-confine f25 && pkgdb-cli orphan --retire snap-confine f26
<Pharaoh_Atem> zyga: run this asap
<zyga> Pharaoh_Atem: ack
<Pharaoh_Atem> zyga: I've already retired it from rawhide, and you're the only person who can run it for the older branches
<Pharaoh_Atem> building F26 package now
<Pharaoh_Atem> at least now the buildsystem will stop bitching about the snapd-glib broken dep
<zyga> 60 seconds
<zyga> Pharaoh_Atem: it said I must use fedpkg retire first
<Pharaoh_Atem> then do that
<zyga> ay
<zyga> Pharaoh_Atem: push got rejected
<zyga> hmmm
<zyga> Pharaoh_Atem: hook declined update
<Pharaoh_Atem> did you do it with a fresh checkout?
<zyga> Pharaoh_Atem: no, with one I had on disk
<Pharaoh_Atem> it should already have "dead.package" files on every branch from f24 on up
<zyga> Pharaoh_Atem: shall I try with a fresh one?
<Pharaoh_Atem> yes
<zyga> ok
<Pharaoh_Atem> actually a fresh checkout may let you just use pkgdb CLI
<Pharaoh_Atem> but try with fedpkg retire
<Pharaoh_Atem> if fedpkg retire works, more power to us :)
<zyga> Pharaoh_Atem: said I'm not allowed to retire f25
<zyga> hmmm
<zyga> trying pkgdb
<zyga> nope
<zyga> any ideas?
<Pharaoh_Atem> zyga: pop into #fedora-releng and ask about it
<zyga> Pharaoh_Atem: "dead.package found" but then says "no `dead.package' for snap-confine on f24"
<zyga> OK
<jdstrand> ogra: can you kick off a build for linux-generic-bbb?
<Pharaoh_Atem> morphis, zyga: snapd FTBFS on F24 and F25
<Pharaoh_Atem> oh wait, I know why
<Pharaoh_Atem> because I need buildroot overrides
<Pharaoh_Atem> duh
<Pharaoh_Atem> zyga: drop your watch commits and approvacls here: https://admin.fedoraproject.org/pkgdb/package/rpms/snap-confine/
<zyga> Pharaoh_Atem: trying
<zyga> Pharaoh_Atem: I managed to orphan in f24/25
<zyga> Pharaoh_Atem: can you check
<zyga> Pharaoh_Atem: I'm not sure what to do
<Pharaoh_Atem> change your watchcommits to obsolete here: https://admin.fedoraproject.org/pkgdb/package/rpms/snap-confine/acl/watchcommits/
<zyga> that's done
<Pharaoh_Atem> there, that's taken care of
<niemeyer> roadmr: Should be all sorted out, btw
<niemeyer> ogra: core-build reporting here too
<Pharaoh_Atem> zyga: could you give positive karma on https://bodhi.fedoraproject.org/updates/?packages=golang-github-go-tomb-tomb ?
<Pharaoh_Atem> that way it'll cycle out to stable quickly?
<zyga> sure
<Pharaoh_Atem> all the ones with +2 need good karma
<Pharaoh_Atem> that way, they'll sync out with stable updates push in an hour or so
<Pharaoh_Atem> at least, I think it's in an hour
<Pharaoh_Atem> then I don't have to do too many buildroot overrides
<zyga> Pharaoh_Atem: done
<zyga> Pharaoh_Atem: gee, I should manage something myself, this feels good
<zyga> Pharaoh_Atem: just golang packages are not very interesting "works for me" is hard to tes
<zyga> test
<jdstrand> kyrofa: to save you time: https://github.com/snapcore/snapd/pull/3112#discussion_r109008576
<mup> PR snapd#3112: interfaces: add a joystick interface <Created by kyrofa> <https://github.com/snapcore/snapd/pull/3112>
<kyrofa> jdstrand, hahaha, right after I commented, I saw "AppArmor pcre syntax (currently not supported)" in the reference
<kyrofa> Felt dumb
<kyrofa> jdstrand, the "Documentation of language syntax" above is what misled me
<jdstrand> no worries. it looks like regex sometimes, but it isn't
<zyga> jdstrand: could you do a quick review for getmntent replacement?
<zyga> https://github.com/snapcore/snapd/pull/3103#discussion_r108927742
<mup> PR snapd#3103: interfaces/mount: add function for parsing fstab-like file <Created by zyga> <https://github.com/snapcore/snapd/pull/3103>
<jdstrand> zyga: I cannot, I'm time-shifting today and will be on the road in a few minutes. if you need it today, perhaps ask tyhicks to see if he can put someone on it, otherwise it will have to wait
<kyrofa> jdstrand, wait, I'm a little confused. The PR in its current state will allow /dev/input/js. Is your snippet different?
<zyga> jdstrand: OK
<zyga> jdstrand: it's okay, it's not urgent
<kyrofa> jdstrand, you say "if you want to support /dev/js"
<zyga> kyrofa: maybe you? it's super short and I have one review already
<jdstrand> kyrofa: sorry I wrote the comment too fast. I meant to have input/ in all reference to /dev/js
<kyrofa> jdstrand, I know what you meant-- I'm really talking about js with no numbers following
<jdstrand> kyrofa: do you want no numbers to be supported too?
<kyrofa> jdstrand, at least in my experimentation, it always has a number
<jdstrand> kyrofa: then leave it as is. reading https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/devices.txt it seems it always has a number
<kyrofa> jdstrand, good deal
<zyga> jdstrand: note that update-ns is not setuid root
<zyga> jdstrand: it's just a program
<Pharaoh_Atem> zyga: I'm sure you have some other interesting software you'd like in Fedora :)
<zyga> jdstrand: if someone makes it crash, well, fine (though I think the current code is written in a way that won't easily crash)
<jdstrand> kyrofa: actually in reading that I'm reminded that you also want: /run/udev/data/c13:{[0-9],[12][0-9],3[01]} r,
<kyrofa> zyga, sorry man, I have no context for that review, I couldn't do it justice
<zyga> Pharaoh_Atem: I'll think of something, maybe made in C, without many deps
<zyga> kyrofa: no worries, thanks
<kyrofa> jdstrand, whoa :P
<zyga> kyrofa: I think your brain just exploded
<jdstrand> zyga: I know it isn't setuid root. but if an unprivileged user can make snapd call update-ns with arbitrarily controlled arguments, then the unpriv user can try to attack update-ns
<kyrofa> zyga, he says it so casually. "By the way, I should probably mention you need this insane glob in there"
<zyga> jdstrand: update-ns is only called when we connect/disconnect content
<zyga> jdstrand: and the argument is always just the snap name
<zyga> jdstrand: no input
<kyrofa> jdstrand, is that just where udev places the in-affect rules?
<jdstrand> kyrofa: no, that is just some udev info on the device that some libraries like to read. go ahead and cat /run/udev/data/c13:0 if js0 is plugged in
<jdstrand> zyga: can you add a comment to the PR that the arguments to update-ns are not user-controllable (like you just did here)
<kyrofa> jdstrand, huh, neat
<jdstrand> ok, heading out, 'see' you monday :)
<zyga> yes
<zyga> o/
<jdstrand> thanks
<pedronis> niemeyer: have you looked at snapd#3113 ?
<mup> PR snapd#3113: overlord/snapstate: unlock/relock the state less, especially not across mutating the SnapState of a snap <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3113>
<niemeyer> pedronis: Not yet.. after solving a couple of details in the forum, I'm now running through the new threads and opening the PR review requests I found there in new tabs.. then will look through them all
<niemeyer> pedronis: I can look at that one now if you can make good use of immediate feedback
<JamieBennett> niemeyer: can we please enable other forms of auth on the forum for new users? Apparently its pretty easy to do.
<niemeyer> JamieBennett: https://forum.snapcraft.io/t/support-for-sso-on-forum-snapcraft-io/75/5
<JamieBennett> Right but it would be good to enable that early no?
<pedronis> mvo: there's a bunch of autopkgtest failing with something like: 2017/03/30 18:00:26 Discarding autopkgtest:ubuntu-16.04-amd64, cannot connect: cannot connect to autopkgtest:ubuntu-16.04-amd64: ssh: must specify HostKeyCallback
<roadmr> thanks niemeyer ! I just got the confirmation e-mail. Awesome :)
<niemeyer> pedronis: Reviewed, if you're not watching the forum
<pedronis> niemeyer: yes, answered you concerens in the review and the forum
<niemeyer> pedronis: vvv
<niemeyer> Man.. that never works well.. it's merged.
<mup> PR snapd#3113 closed: overlord/snapstate: unlock/relock the state less, especially not across mutating the SnapState of a snap <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3113>
<niemeyer> mup: You're late!
<mup> niemeyer: Roses are red, violets are blue, and I don't understand what you just said.
<pedronis> niemeyer: thanks, was about to merge it
<pedronis> niemeyer: about the aliases gdoc, IÂ was a bit confused by your comments, are you planning to move to a wiki entry in the forum?Â or something IÂ shoul do?
<niemeyer> pedronis: I will.. I have it half-way done and ended up being distracted by other concerns yesterday
<niemeyer> pedronis: Should be there by tomorrow
<pedronis> ok
<pedronis> np
<pedronis> niemeyer: I updated snapd#3044 to follow current direction
<mup> PR snapd#3044: snapstate: more helpers to work with alias states (aliases v2) <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3044>
 * pedronis calls it a day
<niemeyer> pedronis: Sweet, thanks!
<niemeyer> I'm going to (try to) step out as well.. haven't had much sleep lately
<cachio> jdstrand, do you know if there is a way to uninstall + install thte same snap without download it again?
<kyrofa> cachio, snap download it first
<kyrofa> cachio, that will obtain both the snap and its assertion. If you `snap ack` the assertion before installing it, you don't need --dangerous and it'll still update from the store
<cachio> kyrofa, awesome, I'll try that, thanks
<kyrofa> cachio, I believe you'll only need to `snap ack` once, and install however many times, but don't quote me on that. Removing the snap could possibly remove the assertion
<cachio> kyrofa, ok
<mwhudson> i don't think assertions are removed at all currently?
<mwhudson> not sure either
<kyrofa> mwhudson, I suspect you're right, just unverified
<mwhudson> what's the easiest way to set up a daily build of a snap in launchpad?
<mwhudson> in the case where the branch containing the snapcraft.yaml does not change
<mwhudson> presumably i could call the launchpad api from a cronjob but wondering if there is anything neater
<kyrofa> mwhudson, I use Travis daily jobs to make a new commit to change the version and force-push to a branch in LP which has a snap building/publishing on changes
<kyrofa> mwhudson, gnarly
<mwhudson> kyrofa: yeah, that doesn't sound much better than what i said
<kyrofa> mwhudson, in fact, I prefer your solution
#snappy 2017-03-31
<mwhudson> kyrofa: it's not that bad http://paste.ubuntu.com/24284541/
<slangasek> zyga, elopio: LP: #1673568 and LP: #1626359 are linked from the changelog of the SRU for snapd 2.23.6, but neither bug has an SRU template.  Will someone be adding test cases to these bugs, or should the source be reuploaded without the bug refs?
<mup> Bug #1673568: snapd 2.23.6 SRU tracking bug <snapd:New> <https://launchpad.net/bugs/1673568>
<mup> Bug #1626359: Cannot authorise quotactl syscall for Q_GETQUOTA <snapd-interface> <verification-done> <Snappy:In Progress by jdstrand> <snapd (Ubuntu):Triaged> <snapd (Ubuntu Trusty):Triaged> <snapd (Ubuntu Xenial):Triaged> <snapd (Ubuntu Yakkety):Triaged> <https://launchpad.net/bugs/1626359>
<slangasek> zyga, elopio: sorry, LP: #1673568 is clearly an SRU tracking bug from the title - so only LP: #1626359 is at issue
<morphis> Son_Goku: hah, https://koji.fedoraproject.org/koji/buildinfo?buildID=874052 ; that is awesome! great work!
<morphis> zyga: hey! can you give https://github.com/snapcore/snapd/pull/3096 a review today?
<mup> PR snapd#3096: many: abstract path to /bin/{true,false} <Created by morphis> <https://github.com/snapcore/snapd/pull/3096>
<zyga> morphis: hey
<zyga> morphis: looking
<morphis> zyga: thanks
<morphis> zyga: and not sure if you saw https://koji.fedoraproject.org/koji/buildinfo?buildID=874052 already :-)
<zyga> morphis: done
<zyga> very nice!
<zyga> morphis: what was the problem with ppc64? I see it's green now
<zyga> morphis: btw, why two binary packages?
<zyga> morphis: snap-confine / snapd
<morphis> zyga: good question for Son_Goku
<morphis> zyga: ppc64le was green before too
<Son_Goku> ppc64le is green
<morphis> ppc64 was failing and still is
<morphis> so the be variant
<zyga> aah
<zyga> ok
<zyga> Son_Goku: I'd rather have one binary package (snapd/snap-confine)
<morphis> Son_Goku: any reason why I don't see snapd yet with dnf on my rawhide vm? still need to wait for the sync?
<zyga> Son_Goku: it will always be tightly coupled anyway so why splitting it
<zyga> thanks for working on this guys! awesome work
<zyga> I need to help with kids to get them out to school
<zyga> ttyl
<Son_Goku> zyga: because I needed the old RPM to go away in the F26 and Rawhide trees
<Son_Goku> I'll merge snap-confine into snapd for 2.24, probably
<morphis> Son_Goku: so why do I not see snapd in rawhide yet? is there any special trick like adding kojii repos?
<Son_Goku> morphis: it depends on your local mirror
<Son_Goku> it is definitely in the Koji internal repos
<morphis> Son_Goku: according to https://apps.fedoraproject.org/packages/snapd it should be there
<Son_Goku> it may not have been mashed out to the mirrors yet
<morphis> Son_Goku: where do I check which mirror I am using?
<Son_Goku> dnf will tell you when it starts doing stuff
<Son_Goku> but you can also check with #fedora-releng about these things
<Son_Goku> morphis: anyway, I just updated snapd-glib as well
<Son_Goku> we need snapd-xdg-open for desktop apps to work
<morphis> Son_Goku: is there a spec file for it already?
<Son_Goku> morphis, zyga had a review that he never responded to... https://bugzilla.redhat.com/show_bug.cgi?id=1369560
<morphis> hah
<morphis> Son_Goku: then let me put that on my list
<Son_Goku> I'd like to have snapd, snapd-glib, and snapd-xdg-open all pushed in the same update
<morphis> sounds good
<morphis> Son_Goku: will clean the spec file today and integrate your review
<morphis> looks like we don't do proper releases for snapd-xdg-open
<Son_Goku> yeah
<Son_Goku> anyway, must sleeps
<Son_Goku> I've been up this whole time...
<zyga> Son_Goku: makes sense
<Son_Goku> ?
<zyga> Son_Goku: I replied to your earlier comment about snap-confine
<zyga> Son_Goku: sorry, daughter had damp moo
<zyga> Son_Goku: didn't want to go to school; didn't want to stay at home
<zyga> Son_Goku: decided to actually get dressed and eat breakfast as we were leaving
<zyga> hey pstolowski
<zyga> let me know if you have something to review
<mup> PR snapd#3117 opened: tests: parameterize gadget snap channel <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3117>
<pstolowski> zyga, hi!
<pstolowski> zyga, yeah, i'll have 3070 in a moment, something landed and it has new conflicts
<zyga> pstolowski: sounds good
<pedronis> pstolowski: sorry, my fault, IÂ landed the locking changes we were discussing yesterday, https://forum.snapcraft.io/t/transactionality-locking-and-other-concurrency-coordination/50/8
<pstolowski> pedronis, no worries, nice change btw and conflicts were trivial
<pstolowski> zyga, pedronis #3070 ready for re-review
<mup> PR snapd#3118 opened: cmd: import snapd-xdg-open and integrate with our infrastructure <Created by morphis> <https://github.com/snapcore/snapd/pull/3118>
<morphis> Son_Goku: didn't you say you need some sleep? :-)
<zyga> pstolowski: looking now
<pstolowski> thx
<fgimenez> hey zyga a new kernel snap was promoted to beta yesterday, we had this new test error https://travis-ci.org/snapcore/spread-cron/builds/216891204#L392 could you please take a look?
<zyga> fgimenez: hey
<zyga> fgimenez: looking
<zyga> fgimenez: can you in turn tell me what you think about this
<zyga> 2017/03/30 19:17:29 Discarding autopkgtest:ubuntu-17.04-amd64, cannot connect: cannot connect to autopkgtest:ubuntu-17.04-amd64: ssh: must specify HostKeyCallback
<zyga> fgimenez: I got this on https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-image/zesty/amd64/s/snapd/20170330_191740_5aeb7@/log.gz
<zyga> fgimenez: aha, let me prepare a quick PR, the test needs to be disabled; it will not work without another kernel change
<fgimenez> zyga: sure looking
<fgimenez> zyga: great thank you
<mup> PR snapd#3119 opened: interfaces: API additions for interface hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3119>
<fgimenez> zyga: i've never seen before the autopkgtest error, it seems to happen at a very early stage, maybe something changed in zesty recently that makes the ssh connection fail, let me try to reproduce locally
<zyga> fgimenez: I just pushed a change to https://github.com/snapcore/snapd/pull/3076, once it passes we should merge this
<mup> PR snapd#3076: cmd: disable the re-associate fix as requested by jdstrand <Created by zyga> <https://github.com/snapcore/snapd/pull/3076>
<mup> PR snapd#3120 opened: [WIP] interfaces: expose attrs to the interface API, snapctl enhancements (step #4) <Created by stolowski> <https://github.com/snapcore/snapd/pull/3120>
<fgimenez> zyga: if you could execute the failing test locally using the beta kernel snap that would be great to be extra sure, "export SPREAD_KERNEL_CHANNEL=beta" and then run spread with the failing test filter
<zyga> fgimenez: you mean 1644439 or the earlier one?
<zyga> fgimenez: I mean that test is definitely off for the next few weeks, we can only release this after the _next_ kernel gets released
<pstolowski> only for the brave: #3119, #3120
<zyga> haha, is that the hook code?
<zyga> the attribute things
<pstolowski> yes
<pstolowski> the 2nd PR isnt really as big as it may seem (it includes the 1st one)
<fgimenez> zyga: aha if it's going to be disabled it's ok then, thanks
<morphis> zyga: you had a chance to look at https://build.opensuse.org/request/show/483839 already?
<zyga> morphis: no, still on my queue
<zyga> pstolowski: I just reviewed 3070
<zyga> pstolowski: have a look, I think you want to clarify locking and maybe think how this will scale
<zyga> pstolowski: we won't have *that* many revisions but we can have any number of snaps
<zyga> morphis: looking now
<zyga> morphis: nice, too easy :)
<zyga> morphis: thank you!
<morphis> :-)
<zyga> morphis: can you look at https://github.com/snapcore/snapd/wiki/Distributions#support-matrix
<zyga> morphis: I think it needs a small lifting :)
<pstolowski> zyga, thanks, looking. yes, that's a valid point although this is a general problem of state now, i think we need to solve this globally. with config snapshots we will have ~3 configs per snaps
<zyga> pstolowski: yes, though I wonder how this works now, does golang json marshaller support partial encoding/decoding or is it all just smoke and mirros?
<zyga> pstolowski: there's this json.RawMessage thing but I didn't look at the implementation to see what happens there
<pstolowski> zyga, dunno, but I'd be surprised if it was that smart
<zyga> pstolowski: and locking?
<pstolowski> zyga, locking is fine, done by the caller, i'm adding a comment to these methods
<zyga> pstolowski: I assumed as much because Get/Set check locking AFAIR
<zyga> pstolowski: but I wanted to be sure
<pstolowski> yes
<zyga> pstolowski: can you look at https://github.com/snapcore/snapd/pull/3103
<mup> PR snapd#3103: interfaces/mount: add function for parsing fstab-like file <Created by zyga> <https://github.com/snapcore/snapd/pull/3103>
<zyga> pstolowski: it's super short, 2nd review
<pstolowski> zyga, sure
<zyga> fgimenez: I think the issue affects everything now `2017/03/31 08:43:13 Discarding autopkgtest:ubuntu-16.04-amd64, cannot connect: cannot connect to autopkgtest:ubuntu-16.04-amd64: ssh: must specify HostKeyCallback`
 * ogra curses ... so why does core fail to build today 
<zyga> ogra: must be Friday
<ogra> heh, yeah
<fgimenez> zyga: running now, let's see..
<zyga> fgimenez: maybe ssh changed recently?
<fgimenez> pedronis: hi, i've uploaded the expect snap to staging, these are the results on the ubuntu-core system http://paste.ubuntu.com/24286896/ could you please take a look when you have a moment? i think you mentioned we needed to run security-devpts in there, and it is failing
<mup> PR snapd#3076 closed: cmd: disable the re-associate fix as requested by jdstrand <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3076>
<zyga> ok, I've merged the patch that disabled 1644439 regression test
<zyga> pstolowski: quick shot: https://github.com/snapcore/snapd/pull/3092
<mup> PR snapd#3092: interfaces: capitalize Udev... as UDev <Created by zyga> <https://github.com/snapcore/snapd/pull/3092>
<zyga> pstolowski: let's land it
<zyga> morphis: 2nd review ^: this is a 1 char rename across the tree
<zyga> (capitalization change)
<morphis> zyga: aye
<zyga> niemeyer: I'd like to land https://github.com/snapcore/snapd/pull/3039
<mup> PR snapd#3039: many: add support for partially static builds <Created by zyga> <https://github.com/snapcore/snapd/pull/3039>
<pedronis> fgimenez: mvo:Â hi, I was getting this on all my PRs from autopkgtests: Discarding autopkgtest:ubuntu-16.04-i386, cannot connect: cannot connect to autopkgtest:ubuntu-16.04-i386: ssh: must specify HostKeyCallback  do you know what it is about ?
<zyga> niemeyer: I think all the feedback is addressed now, please have a 2nd look
<zyga> pedronis: I don't see mvo here today
<zyga> pedronis: is he off/
<morphis> zyga: btw. is there a way to invoke snap-confine manually?
<zyga> morphis: sure
<zyga> morphis: `make hack` in the tree
<zyga> morphis: then you can use it
<zyga> morphis: alternatively just run it, you need two things:
<zyga> morphis: export SNAP_NAME=...
<fgimenez> pedronis: looking into it right now, zyga pointed it out too
<zyga> morphis: and call it with a security tag (snap.$SNAP_NAME.$APP_NAME)
<morphis> ah
<zyga> morphis: make hack is nice as it just works
<zyga> morphis: replaces system snap-confine
<zyga> morphis: very useful for iteration
<morphis> zyga: yeah, but SNAP_NAME=.. is enough for now
<zyga> morphis: sure but you need to call it with the mandatory argument ^_^
<morphis> yeah
<morphis> works already :-)
<ogra> slangasek, looks like your live-build change scrwed up our core snap builds (it tries to switch the image over to upstart)
<zyga> upstart ?
<ogra> yes
<zyga> wow, blast from the past :)
<zyga> retro base :)
<ogra> http://launchpadlibrarian.net/309249343/live-build_3.0~a57-1ubuntu25.1_3.0~a57-1ubuntu25.2.diff.gz
<ogra> ++# remove all installed packages that are Prio: required in the release
<ogra> ++# pocket but something else in the latest version
<zyga> so we remove systemd and get upstart to satisfy some dependencies?
<ogra> in the logs i see the builds remove systemd-sysv and try to install all upstart packages
<zyga> right
<ogra> https://launchpadlibrarian.net/313704330/buildlog_snap_ubuntu_xenial_amd64_core_BUILDING.txt.gz
<ogra> zyga, and it seems you were right ... its friday (that looks like something to fill the day :/ )
<zyga> I could also use a review for https://github.com/snapcore/snapd/pull/3114
<mup> PR snapd#3114: interfaces/mount: add function for saving fstab-like file <Created by zyga> <https://github.com/snapcore/snapd/pull/3114>
<zyga> it's even smaller and would allow me to start doing real stuff (tm) in update-ns
<zyga> pstolowski: 3119 reviewed
<zyga> pstolowski: have a look
<zyga> pstolowski: get a 2nd review and lets land it
<pstolowski> zyga, thanks, looking
<zyga> pstolowski: I'll review the 2nd one after this lands, I need to focus on a branch I want to land today
<mup> PR snapd#3092 closed: interfaces: capitalize Udev... as UDev <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3092>
<zyga> morphis: test seem to fail on https://travis-ci.org/snapcore/snapd/builds/217086502
<zyga> aha, timeout :/
<zyga> some trouble allocating VMs
<zyga> morphis: maybe restart it when more tests are quiet
<morphis> zyga: yeah let me do a force push to trigger another run ..
<mup> PR snapd#3097 closed: interfaces/seccomp: add bind as part of the default seccomp policy (backport) <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3097>
<zyga> morphis: maybe merge master
<zyga> morphis: that should cure some failures
<zyga> morphis: I'm going for a small walk now
<zyga> morphis: I'll check back in half an hour :)
<zyga> morphis: please pleaes please review the two fstab PRs, they are tiny and I need them today
<zyga> pstolowski: tell me if you want me to the Validate helpers that cuts boilerplate
<zyga> pstolowski: and get a 2nd review and land your PR
<zyga> pstolowski: I'll do it on otp
<zyga> top
<zyga> ttyl
<mup> PR snapd#3121 opened: WIP: cmd/snap-confine: always pass xauth file through regardless where it is located <Created by morphis> <https://github.com/snapcore/snapd/pull/3121>
<ogra> Bug #1678042
<mup> Bug #1678042: removal of priority changed packages breaks builds of the core snap <live-build (Ubuntu):New> <https://launchpad.net/bugs/1678042>
<ogra> sigh ...
<fgimenez> pedronis: not sure what's going on with the autopkgtest failure, using locally a prebuilt xenial image, without updating spread and running autopkgtest with snapd from the archive i still get the same error, checking changes in the dependencies now..
<Chipaca> ok, back to work for me
<Chipaca> not 100% yet but getting there
<Chipaca> anything on fire? :-)
<zyga> Chipaca: hey :)
<zyga> Chipaca: autopkgtests are all broken, something changed in ssh
<zyga> Chipaca: but nothing on fire, just faint smoke
<zyga> Chipaca: how are you?
<morphis> Son_Goku, Pharaoh_Atem, King_InuYasha: when you're back, https://github.com/snapcore/snapd/pull/3118 is something we should consider instead of creating another package we will drop real soon
<mup> PR snapd#3118: cmd: import snapd-xdg-open and integrate with our infrastructure <Created by morphis> <https://github.com/snapcore/snapd/pull/3118>
<Chipaca> zygaâ headache died down, stomach settling, bored out of my mind but until recently couldn't turn my head fast
<zyga> morphis: reviewed 3121
<zyga> Chipaca: ouch :/
<zyga> Chipaca: I had a rough evening, that youghurt *was* expired but ... well
<zyga> Chipaca: it was still tasty though ;-)
<Chipaca> heh
<zyga> Chipaca: I could use some reviews on the fstab PRs
<Chipaca> me it's like a hangover, but without the fun
<zyga> Chipaca: and later on if you have a sec, I could use some hints on how to test some tricky code
<Chipaca> zygaâ https://thisisagoodsign.files.wordpress.com/2014/08/do_not_feed_hallucinogens_to_the_alligators.jpg
 * Chipaca looks at PRs
<zyga> Chipaca: poor crocks :)
<Chipaca> well, at least it was mushrooms and not nutmeg
<Chipaca> zygaâ what's the expected use case for `SaveFSTab`?
<zyga> Chipaca: snap-update-ns will write the things it did to /run
<zyga> Chipaca: it will be a file in /run/snapd/ns/$SNAP_NAME.fstab
<Chipaca> so, /run doesn't need atomicity in the sense we mean there
<zyga> Chipaca: it should match /var/lib/snapd/mount/
<Chipaca> but /var does
<zyga> Chipaca: but if it crashes the code will pick up from the start
<zyga> Chipaca: and see if it needs to mount anything
<Chipaca> ah, if snapd crashes? yeah
<zyga> Chipaca: not snapd, this will be in a separate process
<Chipaca> k
<Chipaca> i was thinking of the machine crashing, not the program crashing
<zyga> Chipaca: if machine crashes it's all good
<zyga> Chipaca: this is purely ephemeral
<Chipaca> yes
<Chipaca> zygaâ in what sense should things in run match things in var?
<zyga> if all is good yes
<zyga> some changes can be rejected
<zyga> so they will not be mounted
<zyga> and such entries won't show up
<zyga> some entries can fail for various reasons
<zyga> this is just a helper for the algorithm we merged earlier
<zyga> that descries 'current' state
<zyga> the desired state is always in /var/
<zyga> written by snapd
<zyga> using all the nice atomic helpers
<zyga> and the current file will be only written by this thing
<zyga> and maybe by snap-confine but this is really optional since it will cross-check with mountinfo to see what is really mounted
<Chipaca> zygaâ ok. Can you add a note about this to the method?
<zyga> Chipaca: sure
<Chipaca> zyga, thanks
<pstolowski> oh my how quickly my branches fall into conflicts recently ;)
<pstolowski> I guess this is what you get if you touch 10*n files (where n>1)
<zyga> Chipaca: added
<zyga> pstolowski: try touching n**10 files ;)
<pstolowski> ;)
<zyga> woow
<zyga> snow in the pyreneeyes
<Chipaca> zygaâ +1
<Chipaca> now i need to person up and go get lunch going before the boys get home ravenous
<zyga> so much snow :)
<mup> PR snapd#3103 closed: interfaces/mount: add function for parsing fstab-like file <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3103>
<Chipaca> (term's out)
<Son_Goku> morphis: I'm not a fan of this whole merging everything into snapd
<zyga> Son_Goku: why not?
<zyga> Son_Goku: it really belongs together
 * zyga small break
<morphis> Son_Goku: that is the future and just follows what we're already doing
<morphis> Son_Goku: so what do you think about integrating that as a patch now into the 2.23 package instead of doing the migration with 2.24 of a then to be dropped snapd-xdg-open package?
<mup> PR snapd#3122 opened: packaging: do not compile spread for autopkgtests <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3122>
<mup> Bug #1678076 opened: console-conf crashes with eth0 and wlan0 on Pi 3 <Snappy:New> <https://launchpad.net/bugs/1678076>
<zyga> Chipaca: hmm, how do I pass a []byte to a C function that gets a char *?
<zyga> Chipaca: I see C.CBytes
<zyga> is that it?
<zyga> NOTE: I need an out argument (I want the C function to populate the buffer)
<CoderEurope> watched the video - but didn't feel it completed well : https://youtu.be/GiRbILdIVnA?t=15m58s
<Son_Goku> morphis: no
<zyga> garh
<zyga> I don't know how to get this to work
<Chipaca> zygaâ ?
<ogra> yay ... core builds fixed again ... phew
<zyga> Chipaca: having C function; ssize_t read_cmdline(char* buf, size_t buf_size)
<sborovkov> Hi, I am getting this apparmor error using dbus in strict: [  816.152055] audit: type=1400 audit(1490957861.012:208): apparmor="DENIED" operation="connect" profile="snap.screenly-client.websocket" name="/run/dbus/system_bus_socket" pid=3893 comm="python3" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
<sborovkov> any idea what can it be caused by? I connect to dbus plug. So it works in devmode at least.
<Chipaca> zygaâ unsafe.Pointer(&buf[0]) ?
<zyga> Chipaca: I tried that, cgo says no
<zyga> ./bootstrap.go:64: cannot use unsafe.Pointer(&buf[0]) (type unsafe.Pointer) as type *C.char in argument to _Cfunc_read_cmdline
<Chipaca> zygaâ show me da code?
<zyga> Chipaca: pushed as 'WIP' to setns-on-startup branch
<zyga> Chipaca: have a look
<zyga> Chipaca: note that place is also a bit bogus as len != cap
<zyga> Chipaca: and even if I get this to work via the pointer somehow it will not change len
<zyga> sborovkov: hmmm
<ogra> sborovkov, sounds like a question for jdstrand
<zyga> sborovkov: yes (who is off today)
<zyga> let me look
<sborovkov> so I am running a daemon. And this happens when connecting to system bus
<Chipaca> zygaâ ah, convert them to the right type and you're set
<Chipaca> zygaâ https://play.golang.org/p/BLn0jYkDmX
<zyga> sborovkov: that seems to be covered by dbus-strict abstraction
<zyga> sborovkov: so no idea, please report a bug
<zyga> d'oh :))
<sborovkov> zyga: is it supposed to be used manually somehow in the snapcraft.yaml's code? just for reference that's what I have https://hastebin.com/apaxuseyob.lua
<Chipaca> zygaâ type safety goes out the window, very obviously
<zyga> Chipaca: who cares about safety ;-)
<zyga> Chipaca: this is just for unit testing
<Chipaca> o/
<ogra> sborovkov, you want "daemon: dbus" i belive
<ogra> looking at https://github.com/snapcore/snapd/blob/4ef0a46ea8ee10f45e73a91925cbfa5fdfbbe2e5/snap/validate.go#L137
<zyga> Chipaca: trying, thanks
<sborovkov> ogra: ahh, alright I will try converting all my services that use dbus to that type from simple then. Thanks.
<zyga> wooot
<zyga> Chipaca: thanks!!
<zyga> Chipaca: two things
<zyga> Chipaca: casting "backwards" (C habbit)
<ogra> sborovkov, well, perhaps i'm wrong, try with one first :)
<zyga> Chipaca: and mandatory () around *C.char
<zyga> and all backwards type syntax ;)
<Chipaca> zygaâ it's not casting, it's converting
<Chipaca> there's a copy involved
<Chipaca> but yes, it gets awkward quickly
<zyga> Chipaca: copy of a pointer is OK
<zyga> Chipaca: let me see if this works
<zyga> yes!!
<Chipaca> zygaâ but then you get a copy of a copy and it starts to degrade :-p
<Chipaca> suddenly all the halftones are gone
<Chipaca> i swear it was just ibuprophene
<Chipaca> ibuprofen*
<CoderEurope> Chipaca: meds ? What are you telling the group ?
<Chipaca> CoderEuropeâ ?
<Chipaca> telling which group?
<Chipaca> use small words
<CoderEurope> Chipaca: you mentioned ibuprofen on a packaging channel ?
<Chipaca> CoderEuropeâ I am not well, today
<Chipaca> CoderEuropeâ so I've got an excuse for my usual non-sense
<CoderEurope> Chipaca: have you tried the 4-7-8 rule ?
<Chipaca> CoderEuropeâ that's for sleeping?
<CoderEurope> yeah, --okay well try this sometime, bye-ya https://redd.it/5zyykt
<sborovkov> ogra: hmm, no that does not seem to work. Issues while validating snapcraft.yaml: The 'apps/websocket/daemon' property does not match the required schema: 'dbus' is not one of ['simple', 'forking', 'oneshot', 'notify'] Or it's in new snapcraft.. I updated it like last week
<zyga> sborovkov: that is not supported I think
<sborovkov> zyga: alright I will try asking jdstrand when he is around, and if it's not something I am doing wrong then I will file a bug.
<zyga> sborovkov: I think we had a PR to support dbus deamones
<sborovkov> ah, ok
<ogra> zyga, https://github.com/snapcore/snapd/blob/4ef0a46ea8ee10f45e73a91925cbfa5fdfbbe2e5/snap/validate.go#L137
<ogra> zyga, is that not released yet ?
<ogra> (that is what i just pointed sborovkov to)
<zyga> niemeyer: I think I'm a bit too much out in the nature today
<zyga> niemeyer: my connection is not sufficient for the hangout because of latency
<zyga> niemeyer: I can do my update here
<niemeyer> zyga: Remember that topic in the cafe? :)
<zyga> niemeyer: yes, yes
<zyga> ogra: what is the name of the amd64 kernel snap?
<zyga> ogra: run "snapcraft history $that_snap_name"
<ogra> pc-kernel
<ogra> edge is at v55 currently
<zyga> ogra: I cannot query forthat apparently
<ogra> whats the query you use, i should be able to
<zyga> ogra: that what I said
<zyga> ogra: snapcraft history $SNAP_NAME
<zyga> ogra: try that
<ogra> damn .. that only works with a logged in machine
<ogra> fgimenez, that was only candidate you wanted rolled back ?
<fgimenez> ogra: yep thank you, that would make the old validation process work again, although i think things have moved because of this problem to prevent situations like this in the future
<ogra> fgimenez, candidate is back to rev57 for amd64 now, should be good again
<fgimenez> ogra: thanks! :)
<fgimenez> pedronis: about https://github.com/snapcore/snapd/pull/3117#issuecomment-290711403 what would happen when the CHANNEL env vars are different? for instance, a gadget snap is promoted to beta
<mup> PR snapd#3117: tests: parameterize gadget snap channel <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3117>
<mup> PR snapd#3123 opened: osutil: introducing GetenvInt64, like GetenvBool but Int64er <Created by chipaca> <https://github.com/snapcore/snapd/pull/3123>
<Chipaca> #3123 is a super easy review if you're bored
<Chipaca> (used by the next commit on #2895)
<pedronis> fgimenez: you do what you wanted to do on the branch
<pedronis> fgimenez: well there are various options
<pedronis> fgimenez: sorry, I'm probably not understanding the question
<fgimenez> pedronis: you suggested that, when the env vars are the same, we shouldn't download each snap and add them as --extra-snaps, with your previous comment all is clear now i think, when they are different we should download and as extra snaps right?
<fgimenez> well except core, it should be added always as extra-snap because it's modified
<pedronis> fgimenez: yes
<fgimenez> pedronis: ok thank you, i'll push the changes shortly
<pedronis> fgimenez: also you always get kernel from the store IÂ suppose if we want
<pedronis> whatever is easier really
<fgimenez> pedronis: ok when KERNEL_CHANNEL is edge makes sense of course
<kyrofa> mwhudson, thanks for sharing the LP build snippet, that could prove handy down the road
<pedronis> fgimenez: sorry, what IÂ mean is that probably we can always avoid using "snap download"Â for all 3
<pedronis> fgimenez: because we can always pass the channel of one to ubuntu-image if the other two have the same channel or are sideloaded anyway
<elopio> slangasek: fgimenez takes care of the snapd bugs, I do the snapcraft ones.
<fgimenez> pedronis: great thanks, on it
<kyleN> jdstrand, hi we have a blocking issue just reported to snapcraft list subject: "Issues using dbus in strict". Can you please take a look?
<morphis> Son_Goku, Pharaoh_Atem: so what is your call on the snapd-xdg-open integration?
<Son_Goku> morphis: for now, actually package it
<Son_Goku> it's got a review request, just finish that
<morphis> even if we have to drop that package soon after it?
<davidcalle> @niemeyer hey, I haven't received the confirmation email for discourse, can you help?
<nothal> davidcalle: No such command!
<Son_Goku> morphis: you really want to merge more things into snapd?
<morphis> Son_Goku: why not?
<davidcalle> niemeyer: ^
<morphis> naturally that is where it belongs to
<Son_Goku> not really
<Son_Goku> it's not like snap-confine where it's actually tightly coupled with it
<morphis> so it needs to follow the same release process, needs the same test setup etc.
<morphis> only makes sense to share that with the existing snapd infrastructure
<Son_Goku> fine, whatever
<Son_Goku> fuck it all, but I wouldn't add it until you've already merged snapd-xdg-open into the master
<Son_Goku> it's not worth arguing over this...
<morphis> sure, I am just trying to get this whole thing into a good shape and polished
<Son_Goku> morphis: propose the patch merge and get niemeyer or mvo to merge it in today, then *after*, I will backport it
<morphis> Son_Goku: the PR is already there, but we wont get it in by today
<morphis> Son_Goku: if you say its fine to take a package in and pull it out afterwards from fedora that is ok for me
<morphis> just trying to safe us necessary work
<Son_Goku> if you're absolutely certain that this will be merged in this way, I'll do it this way
<morphis> let me see if I get a final vote from niemeyer today
<morphis> niemeyer: ping
<mup> PR snapd#3118 closed: cmd: import snapd-xdg-open and integrate with our infrastructure <Created by morphis> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3118>
<niemeyer> morphis, Son_Goku: I need to have lunch now or will miss the family, but I think we need to fix the situation of xdg-open in a proper way
<niemeyer> I'll follow through in the forum after lunch
<ogra> ppisati, will we get an explanation on bug 1674509 why it is invalid for the kernel ?
<mup> Bug #1674509: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 <Snappy:Confirmed> <linux-raspi2 (Ubuntu):Invalid by p-pisati> <https://launchpad.net/bugs/1674509>
<morphis> niemeyer: thanks!
<ogra> ppisati, ah, sorry for being impatient :)
<morphis> zyga: hey! what is your final call of integrating snapd-xdg-open into snapd?
<morphis> zyga: were just talking with Son_Goku about it and if we should push a separate snapd-xdg-open package into fedora if we're going to change this with a next release anyway
<morphis> Pharaoh_Atem, King_InuYasha: btw. feel free to put your points to the discussion at https://forum.snapcraft.io/t/integrate-snapd-xdg-open-into-snapd-repository/100/
<slangasek> elopio: ah, thanks for the info.  In that case, fgimenez: LP: #1626359 is linked from the changelog of the SRU for snapd 2.23.6, but has no SRU template. Will someone be adding test cases to these bugs, or should the source be reuploaded without the bug refs?
<mup> Bug #1626359: Cannot authorise quotactl syscall for Q_GETQUOTA <snapd-interface> <verification-done> <Snappy:In Progress by jdstrand> <snapd (Ubuntu):Triaged> <snapd (Ubuntu Trusty):Triaged> <snapd (Ubuntu Xenial):Triaged> <snapd (Ubuntu Yakkety):Triaged> <https://launchpad.net/bugs/1626359>
<fgimenez> hey slangasek, i think jibel is the right person to take a decision about this, he and his team are now working on snapd's SRUs
<slangasek> jibel: ping ;)
<fgimenez> jibel: could you please take a look to bug #1626359 when you have a moment?
<mup> Bug #1626359: Cannot authorise quotactl syscall for Q_GETQUOTA <snapd-interface> <verification-done> <Snappy:In Progress by jdstrand> <snapd (Ubuntu):Triaged> <snapd (Ubuntu Trusty):Triaged> <snapd (Ubuntu Xenial):Triaged> <snapd (Ubuntu Yakkety):Triaged> <https://launchpad.net/bugs/1626359>
<fgimenez> slangasek: sorry for the annoyance :)
<jibel> fgimenez, slangasek how can I help?
<jibel> fgimenez, last time mvo reuploaded snapd without bug references
<slangasek> jibel: I can handle the reupload to remove the bug ref, I just need a decision that this is what is wanted
<jibel> slangasek, yes, that's what mvo did for a previous release
<slangasek> I think this one was missed by whatever scripts he uses to clean the changelog because the 'LP' and bug # were split across lines
<jibel> slangasek, so go ahead, and reupload without the bug ref. It's the only bug mentioned in the changelog
<slangasek> jibel: already done
<jibel> thanks
<lutostag> hey all, curious if this is intended... paste (http://pastebin.ubuntu.com/24288480/) tracking is set to stable even if I specify a revision to pin to
<lutostag> (so that when I snap refresh it gets stable instead of specifically rev'd version I installed)
<mup> PR snapcraft#1226 opened: Better check of the error code in StatusTracker <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1226>
<mup> PR snapcraft#1193 closed: repo: track per-part build-packages <Created by josepht> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1193>
<mup> PR snapcraft#1212 closed: store: better retry strategy for GETs <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1212>
<Pharaoh_Atem> morphis: you're not going to like what I have to say about this
<Chipaca> in fixing this error message, i've hit an issue, maybe: if you say âsnap install fooâ is the message âerror: "foo": access denied (try with sudo)â better, or worse, for having â"foo"â in there?
<qengho> Chipaca: If the "foo" part is not the cause of the problem, then it's worse. If changing "foo" to something else would succeed, or you need to distinguish between "foo" an a "bar" in the same place, then it'OCs better to keep.
<Chipaca> yeah, that was my reading of it too
<Chipaca> it make syou think the fact that it's "foo" is the cause of your disgrace
<Chipaca> âmaybe if I try "bar" it'll installâ
<Chipaca> on the *other* hand, if you say âsnap install foo barâ and you get back âerror: "bar": configure hook failedâ, that's super clear
<Chipaca> and, alas, our errors aren't contextual enough to tell the difference between "this failed because you tried to do something unpossible" and "this failed because this step of this snap failed"
<morphis> Pharaoh_Atem: :-)
<morphis> Pharaoh_Atem: I am prepping the spec file nevertheless
<mup> PR snapd#3124 opened: interfaces/mount: small tweaks <Created by zyga> <https://github.com/snapcore/snapd/pull/3124>
<morphis> zyga: still there?
<zyga> morphis: yep, I need to figoure out some better IRC story
<zyga> IRC is so unreliable
<zyga> and this client (irssi) is a compromise between crappiness and more crappiness
<morphis> zyga: it is ..
<morphis> zyga: thanks for merging!
<CoderEurope> zyga, It's on the wishlist :D #WeeChat https://redd.it/62148w
<Pharaoh_Atem> morphis, zyga: I've decided to be less scathing in my response: https://forum.snapcraft.io/t/integrate-snapd-xdg-open-into-snapd-repository/100/16?u=conan_kudo
<Pharaoh_Atem> taking an hour away to eat lunch has made me feel less awful about this
<zyga> ha
<zyga> 19:58 < zyga> Pharaoh_Atem, morphis: how would you guys feel if we move to rocket
<zyga> 19:58 < zyga> IRC is constantly disconnecting me (on 3/4G)
<zyga> 19:59 < zyga> and I don't see messages or have any confidence my messages arrived
<ogra> zyga should stop using 3/4G ... and use a full 1G network at least :)
<Pharaoh_Atem> It's so exhausting dealing with so many different chat systems
<Pharaoh_Atem> between Slack, Rocket, Gitter, IRC, Hangouts, and so many others I had to juggle...
<ogra> well, it is always a good excuse to get another monitor for your desktop machine ...
<ogra> need more space for $new_chat_tool
<Pharaoh_Atem> I have three already
<ogra> same here ...
<Pharaoh_Atem> I don't think I can handle more
<ogra> make it five and rotate them all  ;)
<ogra> gives you a bigger screen in the end
<Pharaoh_Atem> if I were going to do that, I might as well get three 4K screens like some other people
<mup> PR snapd#3124 closed: interfaces/mount: small tweaks <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3124>
<CoderEurope> https://www.youtube.com/watch?v=g4-tu-td5xU Is this the right youtube & is #snappy the right channel for discussion | in 10minutes - it starts.
<kyrofa> CoderEurope, no, in rocket
<CoderEurope> ah okay
<kyrofa> https://rocket.ubuntu.com/channel/snapcraft
<brunch875> damn, I better haste with dinner
<brunch875> is popey going to host it?
<kyrofa> I believe so
#snappy 2017-04-01
<mup> Bug #1678342 opened: snapd udev rules are incompatible with unified cgroup hierarchy <Snappy:New> <snapd (Fedora):Unknown> <https://launchpad.net/bugs/1678342>
<chengdanhao> can i ask question about Ubuntu Core hereï¼
<chengdanhao> first time to use this
<wsnipex> is there a plug in snapd that allows access to the joystick api? i.e. /dev/input/js*
<wsnipex> I see that mir provides it, but what about X11 apps?
<wsnipex> nvm: https://github.com/snapcore/snapd/pull/3112
<mup> PR snapd#3112: interfaces: add a joystick interface <Created by kyrofa> <https://github.com/snapcore/snapd/pull/3112>
<mup> PR snapd#3044 closed: snapstate: more helpers to work with aliases state (aliases v2) <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3044>
<_28Kb> ogre
<_28Kb> ogre not working on amd64, unity8-session not working also
<_28Kb> snaps runs by typing snap name in terminal?
<_28Kb> or i don't know how to use this thing at all
<_28Kb> that hello snap will work i guess...
<_28Kb> and i would easily make my own goodbye snap
<CoderEurope> pmcgowan: Mornin' ~How's the power-mac laptop w/unity going ?
<pmcgowan> CoderEurope, sorry I dont know, havent got one
<CoderEurope> pmcgowan: of, thought you had a macbook pro ?
<pmcgowan> nope, samsung
<CoderEurope> samsung ? ultrbook ?
<pmcgowan> CoderEurope, yes
<pmcgowan> all intel components and slim, works well for me
<CoderEurope> pmcgowan: cool beans.
<CoderEurope> pmcgowan: are things getting closer to zesty release, soon ?
<pmcgowan> CoderEurope, indeed zesty is locking down now
<pmcgowan> next week is final freeze
<mup> PR snapcraft#1227 opened: docs: remove docs and link to snappy-docs <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1227>
<ahoneybun> https://chakralinux.org/news/index.php?/archives/197-The-return-of-the-bundles-Switching-all-applications-in-Chakras-repositories-to-snap-packages.html
<ahoneybun> \o/ Aprils Fools
<CoderEurope> ahoneybun: dunno if ever saw the animated one ? https://www.youtube.com/watch?v=0Ikda3eQDuI
#snappy 2017-04-02
<brunch875> $ telegram-sergiusens.telegram
<brunch875> damn, can't paste the message report
<brunch875> snap/telegram-sergiusens/26/command-telegram.wrapper: 6: exec: /snap/telegram-sergiusens/26//usr/bin/env: not found
<brunch875> preceed by a slash
<ogra> ogra@styx:~$ snap info telegram-sergiusens|grep refresh
<ogra> refreshed:   2017-04-01 19:32:23 +0200 CEST
<ogra> brunch875, probably an april fools joke from sergio ;)
<ogra> brunch875, open a topic on the forum in the snaps category to make him know it is broken (i see the same here)
<ogra> s/snaps/snap/
<ogra> (or ping him on rocket.ubuntu.com)
<brunch875> orgra: forums?
<brunch875> we have forums?
<ogra> see topic ;)
<brunch875> oh! :D
<brunch875> is rocket the new IRC nowadays? There seem to be a couple of alternatives...
<ogra> well, it is rocket, IRC, forum and mailing lists ...
<ogra> the latter two might merge at some point
<brunch875> I've also seen matrix.org trying to standardize protocols through restful apis, but this all reminds me of https://xkcd.com/927/
<ogra> yeah, a bit
<ogra> we used to use a closed telegram group for snapd development, that bit moved to the forum so you can finally have some more insight
<ogra> i think thats a big improvement
<ogra> (doing opensource development behind closed doors is never good)
<brunch875> I fully agree with that
<mup> PR snapd#3087 closed: overlord/snapstate: introduce tasks for aliases v2 semantics with temporary names for now (aliases v2) <Critical> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/3087>
<farribeiro> help to build a snap package... I want build firefox + deb package (as daemon)... not have any document for this
<farribeiro> help to build a snap package... I want build firefox + deb package (as daemon)... not have any document for this
<CoderEurope> farribeiro: https://wiki.ubuntu.com/snapcraft/parts
<farribeiro> I taking a look just this section, but don undestanding
<farribeiro> I have built a Dockerfile with this scenario
<CoderEurope> farribeiro: have you tried here ? https://rocket.ubuntu.com/channel/snapcraft
<farribeiro> I'm a baby with snappy... docker not well
<farribeiro> no... in rocket, no
<farribeiro> My snapscrafty... https://gist.github.com/farribeiro/602bd0a2a15ea30c9a36651698627dee
<CoderEurope> well put your question there - thats where all the developers hang on !
<farribeiro> my Dockerfile https://github.com/farribeiro/wscef-docker/blob/master/Dockerfile
<CoderEurope> farribeiro: please refer you question to: https://rocket.ubuntu.com/channel/snapcraft
<farribeiro> Ok
<farribeiro> Done.
<lifeless> .win goto #openstack-neutron
#snappy 2018-03-26
<mup> Bug # changed: 1663615, 1667359, 1681328, 1682550
<mup> Bug #1667408 changed: docker container command XXXX could not be invoked <docker> <Snappy:Expired> <https://launchpad.net/bugs/1667408>
<Lin-Buo-Ren> https://forum.snapcraft.io/t/how-to-create-a-lxd-container-for-snap-development/4658
<Lin-Buo-Ren> RFC
<mborzecki> morning
<zyga> hey
 * zyga will be a little late due to DST change
<mborzecki> zyga: hey
<zyga> hey ho
<zyga> so this week will be, hopefully, more at ease than the last one
 * zyga -> breakfast
<kalikiana> good morning
<pstolowski> morning guys!
<kalikiana> o/ pstolowski
<zyga> Hey hey
<mup> PR snapd#4929 opened: cmd/snap-confine: apparmor: allow creating prefix path for gl/vulkan <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4929>
<zyga> Looking
<mborzecki-ubuntu> there's probably a nicer way to write this rule, would appreciate suggestions
<zyga> Not in a major way
<zyga> It is fine
<mborzecki-ubuntu> oh, ok ;)
<mborzecki-ubuntu> zyga: can you take a look at https://github.com/snapcore/snapd/pull/4908 too?
<mup> PR #4908: [RFC] cmd/snap-confine: attempt to detect if multiarch host uses arch triplets <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4908>
<mborzecki-ubuntu> zyga: a thought i had during the weekend, maybe we should dump all the figuring out of nvidia dirs from snap-confine and do it in snap command instead, only pass the paths we detected in some predefined environment variables
<zyga> Yes, that is the goal
<zyga> I think we have all the means now
<mborzecki-ubuntu> something SC_NVIDIA_LIB=/usr/lib/..., SC_NVIDIA_METHOD=symlink, or SC_NVIDA_LIB=/usr/lib/nvidia-340xx, SC_NVIDIA_METHOD=bind, simiarly for 32bit variants
<zyga> No no
<zyga> Just use the mount profile
<zyga> No need for more variables
<mborzecki-ubuntu> .fstab files?
<zyga> Yes they have all the bits needed now
<zyga> I wanted to do this for quite some time now
<zyga> Move the existing system over
<zyga> Let snapd handle this
<zyga> Rip the c code out
<zyga> Nvidia mode gets added to system key
<zyga> Later on it just becomes nvidia snap
<mborzecki-ubuntu> zyga: yes, this will work
<mborzecki-ubuntu> meanwhile, 4908 fixes nvidia not working at all with 18.04 :/
<mborzecki-ubuntu> running new gnome, they seem to half-respect LC_DATE, it currently shows 'poniedziaÅek, 26 March 2018'
<zyga> mborzecki-ubuntu: oh? maybe it's IPC'd over from gnome-something-something
<zyga> mborzecki-ubuntu: looking at 4908 now
 * zyga got back from a walk
<zyga> how did the failure look like?
<mborzecki-ubuntu> zyga: which failure?
<zyga> the 4908 fix for nvidia on ubuntu
<mborzecki-ubuntu> zyga: well, no 3d with nvidia on 18.04
<mborzecki-ubuntu> zyga: some details https://forum.snapcraft.io/t/nvidia-gl-libs-access-broken-on-ubuntu-18-04/4440
<zyga> let me read that
<zyga> so I'm puzzled, you said that your triplet branch made it work on 18.04
<zyga> or was that still on arch?
<mborzecki-ubuntu> zyga: arch fixes are already merged
<zyga> and what happens on ubuntu with that multi-arch branch?
<mborzecki-ubuntu> zyga: triplet is for ubuntu, but uses the same thing as is used on arch
<zyga> does it crash, does it just not do anything?
<mborzecki-ubuntu> zyga: without the branch there's no 3d, eg. ohmygiraffe hangs, glxinfo shows swrast
<zyga> right
<zyga> that's expected now that 18.04 uses libglvnd
<mborzecki-ubuntu> zyga: with the branch, if nvidia libs are in /usr/lib/<arch-tiplet>, they'll get symlinked, otherwise /usr/lib/nvidia-xxx is bind mounted (if it exists)
<zyga> right
<zyga> and what happens on 18.04? we get the symlinks, right?
<mborzecki-ubuntu> zyga: yes
<zyga> and?
<mborzecki-ubuntu> zyga: and it works
<zyga> oh
<zyga> I must be sleepy then, I misunderstood you
<mborzecki-ubuntu> zyga: heh, no worries, I might be sleepy too and talking garbage :P
<pedronis> hi,  a 2nd review of #4928  would be appreciated  (should solve at least of most tests/main/layout failures)
<mup> PR #4928: tests: disentangle etc vs extrausers in core tests <Critical> <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4928>
<mwhudson> good morning
<zyga> hey mwhudson
<zyga> pedronis: yes, thank you for pointing that out, pstolowski, mborzecki-ubuntu can you please look at 4928
<pedronis> mborzecki-ubuntu: did you see this https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/1239/22
<pstolowski> looking
<mborzecki-ubuntu> pedronis: yes, that's the 5minute ensure interval playing tricks, i recall asking about that back when i was double checking that it works, but the behavior (and the code) looked so specific that i did not view it as a bug
<pedronis> well, it's an easy fix
<mborzecki-ubuntu> zyga: hm pretty much any pr to master touchich apparmor profiles has a problem with temp profile files left behind
<pedronis> mborzecki-ubuntu: I can prepare a PR if you are busy with nvidia debugging
<mborzecki-ubuntu> pedronis: that'd be great if that's not a big problem for you :)
<zyga> mborzecki-ubuntu: can you reproduce that with -debug?
<zyga> something must have changed to cause this
<mborzecki-ubuntu> zyga: i have 3 prs for master, 4875, 4908, 4929, each touching apparmor profile and all fail tests/main/snap-confine, i was able to get a debug shell in 4875 using the same -seed, but i was only able to confirm there were temp files in /etc/apparmor.d and those files were not in snapd state snapshot
<zyga> interesting
<zyga> perhaps the key to trigger it is to change the apparmor profile
<zyga> that would trigger the code that updates it
<mborzecki-ubuntu> pedronis: btw. that's just calling EnsureBefore() at the right place?
<pedronis> yes
<pedronis> the most annoying bit is writing the unit test
<pedronis> anyway I started already
<mborzecki-ubuntu> pedronis: great, thank you!
<mup> Bug #1758849 opened: Snap not able to enable ssh after core upgrade  <Snappy:New> <https://launchpad.net/bugs/1758849>
 * zyga tests the community update to the opensuse package
<mborzecki-ubuntu> `VK_ICD_FILENAMES=/var/lib/snapd/lib/vulkan/icd.d/nvidia_icd.json` snap run  graphics-debug-tools-bboozzoo.vulkaninfo makes it find nvidia icd now
<mup> PR snapd#4930 opened: skip test that requires internet when not present <Created by rkitover> <https://github.com/snapcore/snapd/pull/4930>
<mup> PR snapd#4931 opened: configcore: give a chance to immediately recompute the next refresh time when schedules are set <Created by pedronis> <https://github.com/snapcore/snapd/pull/4931>
<pedronis> mborzecki: ^
<pedronis> we probably need to revisit  validateRefreshSchedule  , it has grown convoluted
<pedronis> pstolowski: still looking at 4928, any questions?
<pstolowski> pedronis: yes, i've a qustion
<pstolowski> pedronis: just got sidetracked.. give me a sec
<pstolowski> pedronis: commented
<jamesh> zyga: hi.  Now that jdstrand seems mostly happy with the "secure bind mount" implementation, what's next as far as integrating it?
<pedronis> pstolowski: yes, the tail/head usage is preexisting, we could use grep  (at least for root and test), the issue is that afaict the user called ubuntu, is not called like that, it depens on the cloud
<pedronis> so it's a win some/lose some kind of situation
<pedronis> pstolowski: I suppose we can use a mixed approach, grep for root,  and sanity check for test  (but copy the two users, the "cloud" one as well)
<pedronis> pstolowski: seems like a follow material though
<pedronis> *follow up
<pstolowski> pedronis: yes, 'test' user would be worth checking for
<pstolowski> pedronis: ok
<pedronis> I'll do a 2nd PR this afternoon
<pedronis> I'm squash merging it, because we probably want it in 2.32 if we have more development to do there, or if we get in trouble for this problem with the validations
<pedronis> pstolowski: thank you for the review
<mup> PR snapd#4928 closed: tests: disentangle etc vs extrausers in core tests <Critical> <Squash-merge> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4928>
<mborzecki> pedronis: just to be sure, each EnsureBefore(0) causes one iteration of this loop https://github.com/snapcore/snapd/blob/master/overlord/overlord.go#L257 right?
<pedronis> mborzecki: not each,  if you call EnsureBefore(0) many times before the loop has a chance to run, they coalesce to one request
<pedronis> that's why it's time based
<flexiondotorg> zyga mvo Morning
<zyga> hey flexiondotorg
<zyga> mvo is off this week
<flexiondotorg> Last week before I left for the US I mentioned that snapd 2.32 caused some serious regressions on 18.04.
<flexiondotorg> Is there a new release to resolve that?
<flexiondotorg> I'm still experiencing problems.
<flexiondotorg> niemeyer: ^
<mborzecki> pedronis: i'm a bit slow today, where are the calls coalesced into one? iirc calling time.Timer.Reset(0) makes it expire immediately, so if the call is made from a handled in one of the .Ensure() calls in overlord/.. the loop will wait (from what i saw those are run in the same goroutine), but if a call like this was made from daemon api, then the loop could turn (different gouroutines), or am i missing
<mborzecki> something?
<mborzecki> zyga: hm got these 2 files: etc/apparmor.d/snap.core.4321.usr.lib.snapd.snap-confine  /etc/apparmor.d/snap.core.4321.usr.lib.snapd.snap-confine.pXJnJ6rsK7wX
<zyga> mborzecki: do you have a debug session?
<mborzecki> zyga: jest
<mborzecki> zyga: notice this:
<zyga> can you stat both of the files
<mborzecki> -rw-r--r-- 1 root root 21297 Mar 26 09:33 /etc/apparmor.d/snap.core.4321.usr.lib.snapd.snap-confine
<zyga> and diff them
<mborzecki> -rw-r--r-- 1 root root 21297 Mar 26 09:26 /etc/apparmor.d/snap.core.4321.usr.lib.snapd.snap-confine.pXJnJ6rsK7wX
<zyga> so the garbage one is slightly older
<mborzecki> this host executed tests/main/snap-seccomp around 9:26
<zyga> I wonder if we don't do some error checking
<zyga> aha
<mborzecki> (have this special patch to spread that logs machine names running each test)
<zyga> there is nothing in that test that looks like it would touch snap-confine
<zyga> and we only make that file when snapd starts up
<zyga> actually, and when it installs new core snap
<mborzecki> zyga: hmm 2018-03-26 11:26:12 Executing google:ubuntu-16.04-64:tests/main/snap-seccomp (1/230) (google:ubuntu-16.04-64 (mar261114-742037))...
<pedronis> mborzecki: we move reset only if the next is before the current next, but yes usually calls from api.go will provoke many ensures
<mborzecki> pedronis: thanks for confirming :)
<Caelum> zyga: sorry, for some reason I only got your email now
<Caelum> zyga: about opensuse package
<zyga> hey!
<zyga> haha, I'm running "osc build" now :)
<zyga> welcome Caelum :)
<Caelum> I fixed the spaces in the PR, I'll update the patch
<zyga> thanks, I'll test it and see what is going on there
<zyga> we have some packaging in the git tree
<zyga> but it's aimed at our CI loop
<zyga> it would be great if you could see how to unify the. two
<zyga> Caelum: and again, thank you so much for doing this!
<Caelum> what was that about the udev rules, just remove those files?
<zyga> mmm, which one was that? let me look
<Caelum> hey, I was only doing this so I could run spotify :D
<zyga> I think we don't need to ship the repair service at all
<zyga> it's a feature that is only for core devices (distribution that is using just snaps for everything)
<zyga> here we can always update snapd with the regular rpm
<zyga> ah, I see -%{_udevrulesdir}/80-snappy-assign.rules
 * zyga looks at that file
<zyga> so that file we do need
<zyga> it's there so that devices that are udev-tagged to a specific snap are actually added to the device cgroup of that snapo
<zyga> what made you remove that?
<Caelum> I didn't touch that
<zyga> looking at https://build.opensuse.org/request/show/590994
<zyga> I see -%{_udevrulesdir}/80-snappy-assign.rules
<Caelum> oh I must have removed it because the dist didn't install it
<zyga> oh, I see
<zyga> but we still need it, it's also a little bit more complex as it was renamed recently
<zyga> let me see what I get in the built rpm now
<Caelum> do you want me to update to 2.32 ? I didn't do that yet because it wasn't listed as a release
<zyga> yes, I think we want that as it brings in a lot of fixes and new features
<zyga> but
<zyga> let's see if we can get 2.31.x out first
<zyga> note that we want to do 2.31.2 probably
<zyga> as it's a minor bug fix release and should be the same for packaging
<Caelum> ah ok, I will update this
<flexiondotorg> zyga: Regarding snapd in 18.04.
<flexiondotorg> I've just tested core snap from edge and *all* strictly confined desktop snaps fail to execute.
<flexiondotorg> `failed to create prefix path: /tmp/snap.rootfs_wo6vzw/var/lib/snapd/lib/vulkan/icd.d: Permission denied`
<zyga> mborzecki: ^ is that covered by your recent work?
<zyga> or do we need a new PR to update the profiles to match?
<mborzecki> zyga: flexiondotorg: #4929 fixes that
<mup> PR #4929: cmd/snap-confine: apparmor: allow creating prefix path for gl/vulkan <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4929>
<flexiondotorg> mborzecki: Thanks. When is that due to land?
<Caelum> zyga: well ran into a snag already, the vendor releases have the go libs bundled, but the github tarball does not
<zyga> Caelum: oh, I see, we didn't make a .vendor tarball?
<flexiondotorg> OpenGL apps on 18.04 using core from stable either fail to execute or attempt to regression to swrast.
<Caelum> I think I had a similar problem and I solved it by creating the /var/lib/snapd/lib directory
<zyga> flexiondotorg: opengl is well known and not fixed yet
<mborzecki> flexiondotorg: hopefully as sonn as jdstrand gives it a green light (and the build is green)
<zyga> Caelum: no, the issue here is much more complex
<mborzecki> flexiondotorg: proposal for fixing opengl is in #4908
<mup> PR #4908: [RFC] cmd/snap-confine: attempt to detect if multiarch host uses arch triplets <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4908>
<zyga> Caelum: I'll try to get that corrected
<Caelum> zyga: awesome, because I have no idea how I'd get the go libs otherwise :)
<zyga> Caelum: ./get-deps.sh does that
<zyga> but I think we can get the vendor tarball done
<Caelum> is it standard for go to use real tabs? I don't know much about go yet
<zyga> Caelum: I think this is what the default "go fmt" formatting does
<Caelum> ah
<Caelum> zyga: also you said in the original email, which I only got now for some reason, to remove snap.mount and snap-repair units, should I do that?
<zyga> yes
<mup> PR snapd#4932 opened: RFC: Content-interface: add rule so slot can access shared directory using plug's namespace <Created by gerboland> <https://github.com/snapcore/snapd/pull/4932>
<greyback> zyga: jdstrand: when you have a moment, I'd appreciate your opinions on this: https://github.com/snapcore/snapd/pull/4932
<mup> PR #4932: RFC: Content-interface: add rule so slot can access shared directory using plug's namespace <Created by gerboland> <https://github.com/snapcore/snapd/pull/4932>
<zyga> greyback: ack, I'll read this and get back to you
<greyback> thank you
<zyga> Caelum: so, I know how to make the vendor tarball now, I will make one for 2.31.2 now
<zyga> Caelum: and then we can look at 2.32.1 later today
<zyga> 2.32 has a small known issue that we must address first
<zyga> Caelum: I will let you know when it is available and I will test your package and approve it in the end
<zyga> Caelum: perhaps with small tweaks if needed
<Caelum> zyga: awesome thank you!
<mup> PR snapd#4933 opened: tests: copy or sanity check core users using usernames <Created by pedronis> <https://github.com/snapcore/snapd/pull/4933>
<pedronis> pstolowski: ^
 * cachio afk
<pstolowski> pedronis: thanks
<pstolowski> +1
 * zyga curses at backspace-goes-back-in-history in firefox
<zyga> and erases *all* form input
<mup> PR snapd#4933 closed: tests: copy or sanity check core users using usernames <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4933>
<zyga> pedronis: hey
<zyga> pedronis: mborzecki figured out why we have the garbage filenames in snap-confine profile
<zyga> pedronis: I think you will need to review that change, it's not big by any standards but it's curious
<mborzecki> so far it's looking good, i'll start another spread run and open a PR
<zyga> mborzecki: then we need to rebase/merge the vulcan PR so that it passes
<pedronis> ok,  given that the standup has moved, I will have walk now but can review after the standup
<zyga> pedronis: sounds good, thank you
<mup> PR snapd#4934 opened: cmd/snapd: make sure signal handlers are established during early daemon startup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4934>
<mborzecki> pedronis: ^^
<greyback> zyga: go to "about:config", search for backspace, and change to 2. Disable backspace=back in FF
<zyga> greyback: +1 on your PR
<zyga> I added it to 2.32
<zyga> we will do a 2.32.x release soon
<greyback> zyga: cool thanks
 * greyback waves https://github.com/snapcore/snapd/pull/4545 seductively
<mup> PR #4545: interfaces/x11: allow X11 slot implementations <Created by gerboland> <https://github.com/snapcore/snapd/pull/4545>
<zyga> greyback: for 2.33 I'm afraid
<greyback> zyga: fair enough
<zyga> greyback: can you check if I answered all the open questions that are addressed at me
<greyback> zyga: you did, thanks
<zyga> thank you jdstrand
<mborzecki> jdstrand: thanks
<jdstrand> np
<mborzecki> zyga: #4939 first, once merged rebase #4929 on top and we should be good, right?
<mup> PR #4929: cmd/snap-confine: apparmor: allow creating prefix path for gl/vulkan <Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4929>
<jdstrand> and hi
<zyga> yes
<mborzecki> i meant #4934
<mup> PR #4934: cmd/snapd: make sure signal handlers are established during early daemon startup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4934>
 * kalikiana lunch
<jdstrand> mborzecki: I noticed that there was a 'conflicting profile for snap-confine.XXXXXX. I restarted the test, but it seems like there are temporary files still on disk when the test runs...
<zyga> jdstrand: the PR mborzecki just mentioned (4934) fixes that
<jdstrand> ok cool
<zyga> hence the rebase dance
<jdstrand> nice
<mup> PR snapcraft#2010 closed: Release/2.40+18.04 <do-not-merge-yet> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2010>
<zyga> pedronis: do you think we should include the fix for //deleted mounts for 2.32.1
<zyga> pedronis: it was just test code but could save us some issues in autopkgtest
<pedronis> zyga: yes
<pedronis> I squashed thinking it might need backporting
<zyga> pedronis: thank you
<mup> Issue snapcraft#2025 opened: Proper error on held packages <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/2025>
<mup> Issue snapcraft#2026 opened: Implement a passthrough feature <bug> <enhancement> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/2026>
<mup> Issue snapcraft#2027 opened: Properly crawl tree of remote parts <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/2027>
<mup> Issue snapcraft#2028 opened: When asking to release to a branch that's too long, a traceback is printed that gives no hints as to the source of the error <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/2028>
<mup> Issue snapcraft#2029 opened: Proper error for apt hash sum mismatches <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/2029>
<mup> Issue snapcraft#2030 opened: Properly invalidate the cache if sources change <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/2030>
<mup> Issue snapcraft#2031 opened: Inconsistent results when building, cleaning stage and rebuilding <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/2031>
<mup> Issue snapcraft#2032 opened: Can not use NodeJS 8 <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/2032>
<mup> Issue snapcraft#2033 opened: LP: #1752344 <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/2033>
<zyga> mborzecki: I have a fix for the atomic file thing
<mborzecki> zyga: pr?
<mup> Issue snapcraft#1682 closed: Refactor grammar to be compatible with Python 2 <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1682>
<mup> Issue snapcraft#1683 closed: Make grammar processing available in pypi <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1683>
<mup> Issue snapcraft#1684 closed: Vendor grammar logic into snapcraft <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1684>
<mup> PR snapd#4935 opened: tests: disentangle etc vs extrausers in core tests (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4935>
<mup> Issue snapcraft#1708 closed: Implement new design for travis CI UX <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1708>
<popey> mborzecki: i saw you mention you'd update snapd in arch recently. On my manjaro system I'm only seeing 2.30. Do I need to do some voodoo to get updated?
<mborzecki> popey: build snapd from aur https://aur.archlinux.org/packages/snapd
<popey> mborzecki: is that the 'recommend' way going forward to get the latest version?
<mup> Issue snapcraft#1670 closed: Change file migrations such that files move from stage to prime rather than coming from the part each time <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1670>
<mup> Issue snapcraft#1690 closed: Design quilt support <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1690>
<mup> Issue snapcraft#1691 closed: Implement quilt design <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1691>
<mup> Issue snapcraft#1692 closed: snapcraft quilt tutorial <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1692>
<mborzecki> popey: yes, at least on arch
<mborzecki> popey: manjaro maintains a set of prebuilt packages from aur, but i have no clue when they get updated
<popey> mborzecki: ok, what's the command to install it? Because that's not the way we have documented how to install snapd on arch.. https://docs.snapcraft.io/core/install-arch-linux
<popey> ah okay
<popey> maybe we need a guide for vanilla arch and one for manjaro?
<popey> oh duh, we have one for manjaro
<popey> https://docs.snapcraft.io/core/install-manjaro
<popey> thanks mborzecki
<mborzecki> zyga: so #4934 is timing out...
<mup> PR #4934: cmd/snapd: make sure signal handlers are established during early daemon startup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4934>
<zyga> mborzecki: fun
<zyga> mborzecki: I need to break for a moment now but I will propose a fix for the atomic issue when I'm back
<mborzecki> zyga: yeah, fun fact, passing when i run it from spread directly (using google backend obviously)
<mborzecki> zyga: i'll update tests/main/snap-confine to check rules vulkan
<mborzecki> vulkan glob rules
<zyga> mborzecki: see if we can mock enough of the logic to break
<zyga> as in
<zyga> mock the environment
<zyga> not the logic
<mborzecki> zyga: yeah, i'm dumping a canary into /usr/share/vulkan/icd.d/
<zyga> it would be cool to install real package with driver deps
<zyga> and mock something in sysfs to have snap-confine go the nvidia path
<mborzecki> zyga: afaik nvidia libs are the only driver that ships icd files, but our rules pick up any file for that matter
<zyga> mborzecki: can we install nvidia libs in a test?
<zyga> in case some pattern is off and only real files cause the issue
<zyga> Caelum: you can now get the 2.31.2 tarball
<mborzecki> zyga: then the code path would be executed only on artful (nvidia-384) and bionic (libnvidia-gl-390)
<zyga> mborzecki: it's better than nothing
<zyga> niemeyer: can you please look at https://github.com/snapcore/snapd/compare/master...zyga:fix/apparmor-tilde?expand=1
<zyga> this is for the ~ in apparmor profiles
<zyga> I will write some unit tests but I wanted to get your quick feedback on how this is done
<pedronis> zyga: there's a typo  in the fedora spec on 2.32
<pedronis> mmh, also the changelog
<zyga> ah, in the changelog
<mborzecki> pedronis: what typo? 'relevant'?
<zyga> I saw that
<pedronis> yes
<zyga> I thought it was fixed with the 2.32 merge back to master
<zyga> but we should fix it in the release branch too
<pedronis> zyga: I did  thebackport but is failing
<zyga> it will annoy tests
<pedronis> on that
<pedronis> zyga:   https://github.com/snapcore/snapd/pull/4935 is my backport
<mup> PR #4935: tests: disentangle etc vs extrausers in core tests (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4935>
<zyga> pedronis: just rename it in your PR
<zyga> (fix the typo)
<zyga> I think it's fine to do
<niemeyer> zyga: What's the current suffix?
<zyga> random alphanumeric AFAIR
<pedronis> zyga: was there a corresponding PR on master?
<zyga> strutil.MakeRandomString(12)
<zyga> pedronis: I suspect mvo fixed that in the 2.32 merge but I didn't see a dedicated PR ; it had to be done within the release ->master merge
<niemeyer> zyga: Why not just appending the ~ at the end?
<zyga> niemeyer: I'm doing that now
<pedronis> zyga: that's not even merged yet
<zyga> are you saying unconditionally?
<zyga> pedronis: ahh, I must have seen wrong
<niemeyer> zyga: Yes, the "just" part :)
<pedronis> #4927
<mup> PR #4927: release 2.32 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4927>
<zyga> niemeyer: sure, that works too
<zyga> it's a nice thing to do in general
<zyga> maybe more tools skip ~
<zyga> pedronis: so there's no fixing PR yet, sorry
<niemeyer> zyga: Yeah..
<pedronis> zyga: I need to have some tea, IÂ will think what to do
<zyga> pedronis: thank you
<pedronis> we probably want to take care of 4927 as well
<zyga> niemeyer: I'll do that, thanks!
 * zyga needs to lunch too
<niemeyer> np, and lunch is a pretty good idea
<mborzecki> zyga: hm vulkan code is gated by nvidia driver check too
<mborzecki> let me try the simplest tring, i.e. to load the driver without the card, if that doesn't work well, we could somehow try to mock the path to sys, or try to override it at runtime
<mborzecki> modprobe: ERROR: could not insert 'nvidia_384': No such device
<mup> PR snapd#4936 opened: packaging: fix changelogs' typo (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4936>
<zyga>  mborzecki you can perhaps mount tmpfs in a place in sysfs and make it appear to be loaded?
<zyga> re
 * zyga returns to updating the PRs
<Caelum> zyga: was passed out on the couch, will update things now, did you want me to pull the udev file from the old dist and add it back in?
<zyga> Caelum: yes, please
<zyga> Caelum: I will review your update shortly but I have some things to finish
<Caelum> ok will do :)
<zyga> Caelum: just try 2.31.2
<zyga> look at the release page for info
<Caelum> wait until I update everything
<zyga> we added snapd-generator binary
<zyga> thats a new thing
<zyga> and it replaces the snap.mount unit
<zyga> please package that one, it fixes snapd running inside containers
<zyga> other than that it should be fairly similar
<Caelum> got it
<cachio> mborzecki, hey, could you please tellme what of all this is not needed for the arch images?
<cachio> https://github.com/sergiocazzolato/compute-archlinux-image-builder/blob/master/arch-image.py
<cachio> mborzecki, they are doing many thinks but I am not sure what's really needed
<cachio> mborzecki, I am starting from this image http://mirror.rackspace.com/archlinux/iso/2018.03.01/archlinux-bootstrap-2018.03.01-x86_64.tar.gz
<mup> PR snapd#4937 opened: osutil: use tilde suffix for temporary files used for atomic replacement <Created by zyga> <https://github.com/snapcore/snapd/pull/4937>
<zyga> niemeyer: ^ that's the simplified version
<niemeyer> zyga: Reviewed
<zyga> niemeyer: thanks, updated now
 * kalikiana heading out for the day
<zyga> mborzecki: ^
<sergiusens> stgraber nacc: hey, I think I got you covered already, but just in case, want to try out https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-40/4643 ?
<sergiusens> diddledan: thanks for the updates to the ref :-)
<zyga> mborzecki: I wonder why the signal handler change is causing things to hang though
<zyga> mborzecki: did you try it in qemu?
<mborzecki> zyga: no, it'd be useful to compare how long each test takes now
<zyga> mborzecki: you can run qemu with the qemu gui on
<zyga> and then log in and watch/interact
<zyga> bionic looks different...
<mborzecki> zyga: 'fake' nvidia test https://github.com/bboozzoo/snapd/commit/2c8aa956b3ffe68d98fd446988472db81dbd4c51
<zyga> mmm
<mborzecki> need to wrap it up for today, my wife is really unamused with me now
<zyga> mborzecki: thank you!
<zyga> mborzecki: I gave you a quick review
<zyga> mborzecki: can you propose that?
<mborzecki> pedronis: pushed a patch with buffered channel as you suggested
<kaliy> hi there! is there a way of changing the display name for the developer of a snap, other than transferring ownership? I tried adding a 'company' name to my profile, but to no avail
<mborzecki> zyga: i'll drop the daemon patch from 4929 and push the test there instead
<zyga> thanks
<nacc> sergiusens: is it in xenial-updates already?
<sergiusens> nacc: xenial-proposed
<nacc> sergiusens: ah ok
<nacc> i'll check it out
<Caelum> the tests take a really long time, would be nice if you could run a smaller subset of important tests
<mup> PR snapd#4936 closed: packaging: fix changelogs' typo (2.32) <Created by pedronis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4936>
<mup> PR snapd#4937 closed: osutil: use tilde suffix for temporary files used for atomic replacement <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4937>
<thresh> hello.  I'm having different sets of staged packages (almost) every time I run snapcraft prime;  what do I use to debug that?
<thresh> the snap does not change, the iamge I build in the snap is the same, too.
<thresh> s/the snap/snapcraft.yaml/
<zyga> Caelum: unit tests? They should run pretty quickly. What are you getting?
<pedronis> zyga: IÂ updated   #4927 to include the typo fix,  #4935 is green
<mup> PR #4927: release 2.32 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4927>
<mup> PR #4935: tests: disentangle etc vs extrausers in core tests (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4935>
<zyga>  Thank you, looking
<zyga> We are only missing one thing now. The fix for apparmor profiles
<mup> PR snapd#4935 closed: tests: disentangle etc vs extrausers in core tests (2.32) <Created by pedronis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4935>
<zyga> It should be mergable soon
<thresh> maybe there is a ML where I can post so it wont get scrolledback into oblivion?
<zyga> thresh: use forum.snapcraft.io please
<thresh> fancy :-)
<sergiusens> nacc: thanks
<Caelum> zyga: the tests take longer for me than the whole build, although I have an old laptop
<zyga> I see, I think you will be happy to know our integration tests run for a few hours
<Caelum> heh
<mup> PR snapd#4938 opened: release-tools: add repack-debian-tarball.sh <Created by zyga> <https://github.com/snapcore/snapd/pull/4938>
<zyga> Caelum: I think unit tests are worth keeping
<zyga> it's the minimalistic line of defence
<Caelum> oh sure, they are definitely worth having, I just meant that you have like a "quick sanity check mode" and "all unit tests" mode
<Caelum> zyga: so I'm done with the changes, updated to 2.31.2, re-added udev rule, removed snap-repair units
<zyga> excellent
<zyga> I will build, review and test it today and tomorrow
<zyga> we can release it tomorrow
<zyga> try as many snaps as you can
<Caelum> sweet
<zyga> and see if something breaks
<Caelum> yeah I already have mailspring and spotify working nicely
<zyga> :-)
<zyga> would you like to help me get snapd into opensuse proper?
<zyga> into factory and tumbleweed and leap?
<Caelum> yes
<zyga> woot, fantastic
<zyga> are you familiar with the process?
<zyga> hey mvo
<mvo> hey zyga
<zyga> 700/2000 tests
<zyga> I reverted a spread test for nvidia that isn't ready
<mvo> zyga: neat
<zyga> sorry :/
<mvo> zyga: what pr is it?
<zyga> https://github.com/snapcore/snapd/pull/4929
<mup> PR #4929: cmd/snap-confine: apparmor: allow creating prefix path for gl/vulkan <Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4929>
<zyga> mvo: I updated 2.31.2 release page https://github.com/snapcore/snapd/releases/tag/2.31.2
<mvo> zyga: great, thank you!
<Caelum> zyga: I'm not, this is the first package for oS I've worked on, but from what I can tell from the wiki you just submit the package and it gets reviewed and added, and I know some people in oS who can help me
<zyga> Caelum: that's good, I think we can help too
<zyga> Caelum: I think we can try to propose 2.32.x once that's ready this week
<mup> PR snapd#4927 closed: release 2.32 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4927>
<zyga> mvo: did you see my question here: https://github.com/snapcore/snapd/pull/4927#discussion_r176911637
<mup> PR #4927: release 2.32 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4927>
<mvo> zyga: I did not, sorry - too trigger happy :(
<mvo> zyga: but that is ok, the exact verison in the postinst needs to be adjusted for each upload anyway. but only once
<zyga> no worries, what's the answer?
<zyga> oh?
<zyga> why only once?
<mvo> zyga: we need it to match the exact version of the upload (so e.g. 2.32.1+17.10)
<mvo> zyga: after that (when we release 2.32.2) it will be enough to test for "less-than" 2.32.2 I think
<mvo> zyga: any news on the nvivia 18.04 work?
<zyga> not more than earlier today, maciej needs to add the scoping and the tests for this
<zyga> I think it can all happen tomorrow
<zyga> I think the last PR looks happy now
<zyga> discarding machines
<mvo> zyga: yay, no errors?
<mvo> zyga: cool, once its merged I will cherry-pick
<zyga> yes
<zyga> it's green now
<zyga> merging
<zyga> drat, I didn't squash
<zyga> mvo: please take just https://github.com/snapcore/snapd/pull/4929/commits/5f1762b0b8ab52b7e60fcce377e24c5ce025b219
<mup> PR #4929: cmd/snap-confine: apparmor: allow creating prefix path for gl/vulkan <Critical> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4929>
<mup> PR snapd#4929 closed: cmd/snap-confine: apparmor: allow creating prefix path for gl/vulkan <Critical> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4929>
<zyga> mvo: and f3f77d9ac192e78523c82a15d368dea943ed8841
<zyga> and that's the release
<mvo> zyga: ok, thanks
<mvo> zyga: nothing from beta validation that needs fixing? all green there?
<zyga> no, all green there
<mvo> zyga: cool
<zyga> mvo: you can consider https://github.com/snapcore/snapd/pull/4934 if you want but I'm not pushing for that
<mup> PR #4934: cmd/snapd: make sure signal handlers are established during early daemon startup <Squash-merge> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4934>
<mvo> zyga: the "~" pr is a bit of a workaround ;)
<zyga> it's 2.32.2 material
<zyga> haha, yes
<zyga> I read apparmor source code
<zyga> anything else is worse
<zyga> like .rej
<zyga> or .dpkg-new
<mvo> zyga: ;)
<zyga> or .rpm-something
<mvo> zyga: ideally we would figure out why we have the leftovers but I think we are in agreement here :)
<mvo> zyga: I looked at the singal PR, it looks harmless, does it fix a real issue?
<mvo> zyga: I mean, anything that was reported by users etc?
<zyga> oh
<zyga> we did
<zyga> it is the real issue
<zyga> we have logs where we start initializing stuff
<zyga> and then get killed with SIGINT
<zyga> this and the ~ PRs fix the same issue from two ways
<zyga> or sides
<zyga> we will only process signal and shutdown after snapd is constructed
<zyga> and we will write files that are ignored by apparmor anyway
<zyga> this is a test issue but it can affect real systems too
<zyga> in tests it's just shutting down snapd being unreliable
<zyga> squash it please
<mup> PR snapd#4934 closed: cmd/snapd: make sure signal handlers are established during early daemon startup <Squash-merge> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4934>
<zyga> mvo: if you prepare the debian part I can make the release page look nice again :)
<zyga> mvo: I need to take Bit out for a walk
<zyga> (Bit is how our dog is called :)
<mvo> zyga: sure, I prepare things and we sync up when you are back. cu
<mup> PR snapd#4939 opened: release: 2.32.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4939>
<mvo> zyga: its building in ppa:snappy-dev/image now, once that is done I will trigger beta build etc
<zyga>  Super
<zyga> mvo: back
<mvo> zyga: waiting for publication
<zyga> mvo: I'm seeing the same thing
<zyga> mvo: we need to be careful in typos in changelog
<zyga> they cause test failures
<zyga> I think it's fine now,  just saying
<zyga> mvo: published
<mvo> zyga: yeah, triggered the build
<zyga> mvo: so that's it now, just -> beta publishing once it's out
<mvo> zyga: yeah
<mvo> zyga: and ideally merge the changelog pr so that we have a edge build again :)
<zyga>  yeah
<zyga> you can merge https://github.com/snapcore/snapd/pull/4938
<mup> PR #4938: release-tools: add repack-debian-tarball.sh <Created by zyga> <https://github.com/snapcore/snapd/pull/4938>
<mup> PR snapcraft#2023 closed: repo: catch error due to broken build packages <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2023>
<mup> Issue snapcraft#2025 closed: Proper error on held packages <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/2025>
<mup> PR snapd#4939 closed: release: 2.32.1 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4939>
<mvo> zyga: pushed to beta
<zyga> great, then that's today
<zyga> have a peaceful night :-)
<mvo> zyga: thank you, you too! keep me posted if things work or if we need a .2 :)
 * mvo waves
<mup> PR snapcraft#2034 opened: pluginhandler: organize correcly for targets with leading / <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2034>
<Caelum> zyga: fwiw, this is the page I was following the past few days, and it also describes how to add stuff to Factory (TW) I think we can start with the process of requesting a new devel project or finding an appropriate top-level space right now https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory
<mup> PR snapcraft#2035 opened: ci: cache core and lxd to avoid redownloading <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2035>
<zyga> Caelum: I think we have a nice devel project already
<zyga> Caelum: system:snappy is a good place
<Caelum> zyga: yeah then it's just one osc command to submit to Factory
<Caelum> That's the beauty of OpenSUSE
<kyrofa> zyga, thought you'd like to know, I'm now a sublime text user
<mup> Issue snapcraft#1974 closed: organize with forward slashes should be stripped <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1974>
<mup> PR snapcraft#2034 closed: pluginhandler: organize correcly for targets with leading / <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2034>
<sergiusens> nacc: hey, did you have an opportunity to look into 2.40? Personally I setup my own buildd for git-ubuntu and ran the self-tests succesfully, not sure what more could be done
<nacc> sergiusens: i haven't had a chance yet; if you've run the above, though, that's what i'd do
<nacc> so i'm +1 if that passed
<nacc> (which is what didn't before :)
<sergiusens> nacc: yes, fwiw https://forum.snapcraft.io/t/snapcraft-snap-building-sanity-checks-for-build-snapcraft-io/4632/1
<sergiusens> I still need to hook more of it up in some orchestration system, but this will be part of our release testing
#snappy 2018-03-27
<mborzecki> morning
<zyga> Hey Hey
<mborzecki> so we have 2.32.1
<zyga> Indeed we do
<zyga> The urgent fire should be out now
<mborzecki> got a review on 4908 from jdstrand last night, think he got confused with all the arrays getting passed to sc_mkdir_and_mount_and_glob_files()
<zyga> 2.32.2 could add your nvidia support
<mborzecki> landing this, with a test, would be nice
<zyga> Yes. Your test yesterday was a good start
<mborzecki> that thing on 14.04 was a bit worrying, idk why you'd get permission denied when trying to mount tmpfs inside <root>/var/lib/snapd/lib/vulkan
<mborzecki> zyga: per your comment, the same flags to configure for all ubuntu variants right?
<zyga> re
 * zyga is done with kids & dog
 * zyga notices new systemd release in artful
<mborzecki> btw. i've bumped aur package to 2.32.1
<zyga> mborzecki: thank you!
<zyga> I will review the update to the othe PR soon
<mborzecki> i'll be switching to ubuntu in a couple of mins to double check that things still work fine
<Guest90825> hello
<Guest90825> nick
<zyga> hey Guest90825
 * zyga updated https://github.com/snapcore/snapd/releases/tag/2.32.1
<zyga> mborzecki: thanks
<CN_vic> hellp
<CN_vic> ?
<zyga> CN_vic: how can we help you?
<CN_vic> åå
<CN_vic> no
<CN_vic>  thanks
<CN_vic> bye
<pedronis> pstolowski: I did another pass over interface hooks,  as IÂ noted we are not very consistent with returning xxxRef types wrt pointer or not, not here, but a follow up should clean that up I think
<pstolowski> pedronis: thank you, yes i just saw your comments. will address in a followup, thanks again
<zyga> hmm
<zyga> did anyone see
<zyga> 2018-03-27 08:21:40 Cannot allocate google:ubuntu-14.04-64: cannot perform Google request: Get https://www.googleapis.com//compute/v1/projects/computeengine/zones: oauth2: cannot fetch token: Post https://accounts.google.com/o/oauth2/token: net/http: TLS handshake timeout
<mborzecki-ubuntu> zyga: retry?
<zyga> greyback: can you please merge master into 4545
<greyback> zyga: ack, on it
<zyga> greyback: and please run go fmt
<zyga> x11.go is off
<zyga> greyback: you also have small comment on 4932
<greyback> yep, saw that
<zyga> https://github.com/snapcore/snapd/pull/4920 needs a 2nd review
<mup> PR #4920: timeutil: in Human, count days with fingers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4920>
<zyga> perhaps mborzecki-ubuntu or pstolowski
<om26er> popey: ping
<zyga> pstolowski: what's the plan on https://github.com/snapcore/snapd/pull/4917 ?
<mup> PR #4917: repo: added repo ConnectionsInfo method (for the new snap connections API) <Created by stolowski> <https://github.com/snapcore/snapd/pull/4917>
<popey> om26er: pong!
<om26er> popey: new Android Studio is out, could you please merge this PR https://github.com/snapcrafters/android-studio/pull/17
<mup> PR snapcrafters/android-studio#17: Release version 3.1.0.16 <Created by om26er> <https://github.com/snapcrafters/android-studio/pull/17>
<popey> om26er: on it!
<om26er> also kindly provide input on https://github.com/snapcrafters/sublime-text/pull/8
<mup> PR snapcrafters/sublime-text#8: Remove '3' from snap name <Created by om26er> <https://github.com/snapcrafters/sublime-text/pull/8>
<mborzecki-ubuntu> heh, I already viewed 4920 but didn't click 'submit review'
<om26er> popey: ^
<mborzecki-ubuntu> it'd be useful if github had a notification or sth that you have unfinished reviews
<popey> hehe, that one again. okay!
<om26er> popey: I have added my input on that one, I consulted the upstream as well.
<popey> ok, will take a look.
<pedronis> #4931 needs a second review
<mup> PR #4931: configcore: give a chance to immediately recompute the next refresh time when schedules are set <Created by pedronis> <https://github.com/snapcore/snapd/pull/4931>
<pstolowski> zyga: i'll address your comments soon, not sure about PlugInfo/SlotInfo vs refs suggestion
<zyga> sure, it was just a suggestion
<pedronis> mborzecki-ubuntu:   #4571 needs to be closed?
<mup> PR #4571: data, cmd, packaging: use autotools to generate artifacts under data <Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4571>
<mborzecki-ubuntu> pedronis: i'll close it
<pedronis> zyga: seems we have quite a few interface PRs in need changes since a while
<zyga> pedronis: yeah, I'm looking at PRs now
<zyga> I hope to garden somse
<mup> PR snapd#4571 closed: data, cmd, packaging: use autotools to generate artifacts under data <Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4571>
<zyga> We hit some timeouts on pulling snaps from the store
<mborzecki-ubuntu> Fetching pc-kernel ...  <kill-timeout reached>
<greyback> zyga: 4545 has master merged, gofmt was happy wiht x11.go for me? 4932 has comment addressed
<mborzecki-ubuntu> if 4908 fails again i should probably use this as an occasion to merge master :/
<zyga> thank you, it's looking good
<mup> PR snapd#4940 opened: RFC: added UDevMonitor for future hotplug support <Created by stolowski> <https://github.com/snapcore/snapd/pull/4940>
<mup> PR snapd#4941 opened: vendor: update gopkg.in/yaml.v2 to the latest version <Created by zyga> <https://github.com/snapcore/snapd/pull/4941>
<zyga> pstolowski: reviewed 4940
<pstolowski> zyga: thanks!
<pstolowski> zyga: 4923 needs de-conflicting
<zyga> pstolowski: it needs investigation what to do, it was just a test PR
<zyga> I will close it for now
<pstolowski> ack
<mup> PR snapd#4923 closed: spread.yaml: look for signs of //deleted mounts <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4923>
<mborzecki-ubuntu> zyga: pushed a fix for autogen in 4908
<zyga> mborzecki-ubuntu: can you do the master dance with https://github.com/snapcore/snapd/pull/4875 please
<mup> PR #4875: cmd/snap-confine: fix ptrace rule with snap-confine peer <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4875>
<zyga> it should be green now
<mborzecki-ubuntu> zyga: it can be closed now, 2.32 was merged back to  master, and this change was part of 2.32 already
<mup> PR snapd#4875 closed: cmd/snap-confine: fix ptrace rule with snap-confine peer <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4875>
<zyga> mborzecki: sorry, I'm slow todat
<mborzecki> zyga: hm?
<zyga> can you please walk me through 4844
<zyga> https://www.irccloud.com/pastebin/okBoncVR/
<zyga> pedronis: is the store experiencing any issues?
<pedronis> not particularly at this moment
<pedronis> there were some issues with downloads, not sure if they were fully resolved
<pedronis> zyga: I also need to review 4844
<zyga> mborzecki: you have feedback from jdstrand on https://github.com/snapcore/snapd/pull/4509
<mup> PR #4509: interfaces/builtin: add support for software-watchdog interface <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4509>
<zyga> ikey: hey
<zyga> ikey: long time no talk (or see)
<zyga> I'm going through various PRs and I noticed there's some feedback on https://github.com/snapcore/snapd/pull/4538 (steam support)
<mup> PR #4538: interfaces/builtin: Add new steam-support interface <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4538>
<zyga> is this waiting on updates from you?
<ikey> zyga, yes, just not a good time at the moment sorry
<zyga> greyback: I added one more idea to your x11 PR
<zyga> greyback: have a look and tell me if I'm nuts
<zyga> ikey: that's all right, I just wanted to catch up
<zyga> ikey: how are you doing?
<ikey> not good, hence not good time. sorry. you?
<zyga> ikey: I would say never better but that's not true
<zyga> ikey: but it's been worse too so that's a charm :)
<ikey> handy when you've an upside :]
<zyga> pedronis: more core download issues
<zyga> pedronis: I restarted the affected tests
<pedronis> zyga: yea, I think there are still download issues
<zyga> + tar -C/ -xf /home/gopath/src/github.com/snapcore/snapd/snapd-state.tar.gz
<zyga> tar: /home/gopath/src/github.com/snapcore/snapd/snapd-state.tar.gz: Cannot open: No such file or directory
<zyga> I wonder what could cause the spotify snap on opensuse not to support high-dpi while the same snap works on ubuntu 17.10
<zyga> maybe distro patches missing somewhere?
<zyga> but unlikely since all of opensuse works ok
<mup> PR snapd#4942 opened: cmd/snap: user session application autostart v3 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4942>
<mborzecki> off to pick up my daughter from school, bb for standup
<zyga> Caelum: I updated my review of your package updates
<jdstrand> mborzecki (cc zyga): I did get confused initially, but then mentioned in 'Update:' what you could do. however, the refactor is good enough for me
<zyga> Iâm afk for now
<mborzecki> jdstrand: thanks for the review :)
<mup> PR snapd#4871 closed: cmd/snap-confine: fix Archlinux compatibility <Created by Erick555> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4871>
<jdstrand> mborzecki: np, thanks for working on it!
<mup> PR snapd#4943 opened: tests: adding debian sid to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4943>
<zyga> standup time
 * kalikiana going for half a lunch break
<zyga> error: cannot install "core": cannot query the store for updates: got
<zyga>        unexpected HTTP status code 404 via POST to
<zyga>        "https://api.snapcraft.io/v2/snaps/refresh"
<zyga> pedronis: ^ that's unexpected, right?
<pedronis> zyga: where?
<pedronis> that's my PR, yes it's expected until I rerun the tests
<zyga> https://travis-ci.org/snapcore/snapd/builds/356519762?utm_source=github_status&utm_medium=notification
<zyga> yeah
<zyga> ok
<zyga> jdstrand: I think https://github.com/snapcore/snapd/pull/4932 is ready now and your feedback is applied
<mup> PR #4932: interfaces/content: add rule so slot can access writable files at plug's mountpoint <Created by gerboland> <https://github.com/snapcore/snapd/pull/4932>
<pedronis> niemeyer: IÂ labeled all those branches critical
<zyga> https://github.com/snapcore/snapd/pull/4844 made me realise we have overloaded the term system key
<mup> PR #4844: overlord/snapstate: allow core defaults configuration via 'system' key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4844>
<mborzecki> zyga: yeah, it's a 'nickname'
<mborzecki> zyga: as agreed during the sprint ;), '$core' was another candidate
<mborzecki> zyga: master already has some bits for making `snap set system foo.bar=baz` and `snap get system` work
<jdstrand> mborzecki: I was thinking about code clarity and added https://github.com/snapcore/snapd/pull/4908/files#r177422132 (not a blocker)
<mup> PR #4908: [RFC] cmd/snap-confine: attempt to detect if multiarch host uses arch triplets <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4908>
<zyga> hey jdstrand, how are you doing? :-)
<zyga> mborzecki: yeah, that's fine, I just found it funny
<mborzecki> jdstrand: thanks, i can push it in a while, this part is tricky so comments are obviously helpful
<vidal72[m]> zyga: jdstrand should I make PR with patch proposed in https://forum.snapcraft.io/t/apparmor-issues-with-default-install-dir/4568/2
<jdstrand> zyga: hey, pretty good. how are you?
<jdstrand> mborzecki: thanks
<jdstrand> zyga: re 4932> done
<jdstrand> vidal72[m]: oh, I thought you were in the process of that. if you are so inclined, sure, if not, I can.
<zyga> jdstrand: thank you (for both); I'm feeling a bit uneasy with my back lately but long walks with the dog make it go away
<jdstrand> vidal72[m]: also, I liked '@{INSTALL_DIR}="{/snap,/var/lib/snapd/snap}"' cause I felt it was slightly clearer in this case, but both yours and mine are equivalent policy-wise
<pedronis> zyga: I recheck that error will go away if I rerun the tests, but that branch  needs  a merge from master and IÂ would prefer to wait a bit for feedback on the prereqs
<jdstrand> zyga: if you don't already, you might consider a standing desk
<jdstrand> I found it helped me a lot. bonus points if you add an under-the-desk treadmill
<zyga> jdstrand: oh, I have, it's planned already
<jdstrand> nice
<zyga> jdstrand: once we save some money we plan to transform a tarrace into my office, make it habitable all year and put a standing desk there
<zyga> that will also move me out of the living room :)
<jdstrand> heh, nice
<zyga> that's for spring next year though
<zyga> for now, it's the walks :)
<jdstrand> zyga: it's really just about not sitting for long periods all day, so yeah, a dog walk works for that perfectly :)
<zyga> yeah, I agree
<zyga> plus, he's very happy not to be in a shelter anymore :)
<jdstrand> :)
<mup> PR snapd#4944 opened: interfaces: add /var/lib/snapd/snap to @{INSTALL_DIR} <Created by Erick555> <https://github.com/snapcore/snapd/pull/4944>
<mup> PR snapcraft#2036 opened: errors: remove stack data when sending to sentry <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2036>
<niemeyer> kalikiana: https://forum.snapcraft.io/t/support-for-passthrough-into-snap-yaml/4698
<mup> Issue snapcraft#2037 opened: core refresh in container build breaks build <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/2037>
<zyga> cachio: I reviewed https://github.com/snapcore/snapd/pull/4721#pullrequestreview-107307595 and have one suggestion but let's please do it in a follow-up
<mup> PR #4721: tests: update interface tests to remove extra checks and normalize tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4721>
<kalikiana> niemeyer: Awesome +1
<zyga> pstolowski: did you see the ping on the forum?
<pstolowski> zyga: yes. looking into the code and where it comes from
<zyga> it's an un-handled ErrNoState
<petan> hello, I am getting Built, failed to release
<petan> is there any way to debug why?
<petan> there are no errors in logs
<zyga> petan: can you please provide some more information/
<petan> https://build.snapcraft.io/user/huggle/huggle3-qt-lx/176724
<petan> that's the build log
<petan> it doesn't say anything else than Build failed to release
<petan> btw I managed to build the .snap file using snapcraft on my own PC without any issues
<pstolowski> zyga: yes i see that
<zyga> kalikiana: ^
<zyga> kalikiana: is that when the store for whatever reason fails to release a snap to a channel?
<zyga> petan: it feels like a store side fluke
<zyga> petan: but please talk to kalikiana about it
<zyga> pstolowski: I think we want to check the state from evan
<petan> hmm so solution is to wait and try to click rebuild later?
<zyga> pstolowski: to see if this is broken state
<zyga> petan: as I said, I don't know fully, please wait for a response from kalikiana or sergiusens who know this part better
<petan> ok
<zyga> pstolowski: or correct state and broken code
<zyga> pstolowski: unless you find some obviously broken piece of code somewhere
<pstolowski> zyga: yes, i was going to suggest that. note, this error is actually not fatal, just logged, i'm not sure what's the reasoning behind that logic
<kalikiana> zyga: petan Hmmm the build seems fine indeed.
<sergiusens> zyga: that looks more like a store issue, roadmr ^
<zyga> pstolowski: dunno, but it looks fundamental and we need to get to the bottom of it
<roadmr> sergiusens, zyga : yes, we're looking at intermittent upload/download issues
<pstolowski> zyga: sure
<zyga> pstolowski: if you see ev, can you ask him about state.json please
<pstolowski> zyga: I did via the forum
 * zyga -> dinner
<niemeyer> pedronis: #4931 reviewed.. I suggested a simpler and more general approach there
<mup> PR #4931: configcore: give a chance to immediately recompute the next refresh time when schedules are set <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4931>
<niemeyer> pedronis: LGTM if you're happy with that as well
<jdstrand> pstolowski: hi! fyi, my comments in https://forum.snapcraft.io/t/please-help-testing-2-32-in-beta/4696/7
<pstolowski> jdstrand: yep, saw that, thanks! did you ever have dotnet-sdk installed?
<jdstrand> pstolowski: yes (I just updated my comment to say that)
<jdstrand> I don't recall when though...
<pstolowski> jdstrand: can you send me your state?.json?
<jdstrand> sure
<jdstrand> pstolowski: should I stop snapd before sending it?
<pstolowski> jdstrand: yes
<mup> Bug #1759294 opened: Please display confinement level information in 'snap info' command output <Snappy:New> <https://launchpad.net/bugs/1759294>
<jdstrand> pstolowski: emailed
<cachio> zyga, sure I'll take a look now
<pedronis> niemeyer: so doing it even on errors?
<pedronis> for any config change
<niemeyer> pedronis: Yeah
<pedronis> ok
<niemeyer> pedronis: Shouldn't be a problem, and it's a pretty rare and manual event.. much easier for us to reason about
<zyga> cachio: thank you for doing that PR, it's pretty big!
<zyga> woah
<zyga> jdstrand: do you see the dotnet-sdk snap in snap interfaces anywhere?
<jdstrand> zyga: no
<zyga> this is very interesting and odd
<zyga> pstolowski: let me know what you find out
<mup> PR snapcraft#2038 opened: Add an option for setting npm flags option <Created by guilhem> <https://github.com/snapcore/snapcraft/pull/2038>
<nessita> petan, hey, were you asking about the huggle snap?
<petan> yes, it builds but doesn't release now, it always worked
<petan> https://build.snapcraft.io/user/huggle/huggle3-qt-lx/176724
<nessita> petan, we are having some issues with our snap storage access that is being worked on, and that caused the review of your revision 640 to be stuck. I unstucked it and now the rest of the revisions are being processed, see https://dashboard.snapcraft.io/snaps/huggle/
<petan> ok thanks
<nessita> petan, you may need to go to dashboard and release the revisions manually
<zyga> thank you nessita !
<nessita> zyga, \o/
<pstolowski> zyga: ok, so the problem is we have 4 stray connections for a removed snap in the state; these were auto-connections from the snap to core, so we consider  that snap affected by core upgrade. now i need to find out why we didn't remove these connections when snap was removed
<pstolowski> niemeyer: ^
<zyga> pstolowski: that's nice
<zyga> I wonder if those were super old and were always there (but nobody noticed the error or the error did not surface) or it this is something we recently broke
<mup> Bug #1759294 changed: Please display confinement level information in 'snap info' command output <Snappy:Invalid> <https://launchpad.net/bugs/1759294>
<pedronis> niemeyer: this made me think something,  we should really call EnsureBefore after we have committed the transaction, which is outside this package
<cachio> zyga, it is a big change the add -i interface in all the "snap interfaces"
<cachio> zyga, is it ok if I do it in another PR
<cachio> I also agree it is more robust
<cachio> zyga, but I need to update 90 different places
<om26er> when does snapd 2.31.2  leave -proposed on stable Ubuntu releases ?
<ackk> mvo, zyga, hi, WRT 'nobody' user for snaps, was the idea we discussed at the sprint agreed upon?
<niemeyer> pedronis: +1
<zyga> cachio: Yes, lets do it in a new PR
<zyga> Ackk, I forgot what the agreement was, was it to ship a user with snapd or do something else?
<ackk> zyga, yeah I think it was that snapd would create a "snaps-nobody" user that is used to remap the nobody user
<ackk> zyga, (or whatever username is decided)
<ackk> zyga, we really just need a non-root user
<zyga> Ackk remap how?
<zyga> Remember
<zyga> Remember that etc passwd is from the host today, right?
<pstolowski> zyga: see my latest answer to the stray connections bug
<pstolowski> in the forum
<zyga> pstolowski: looking
<ackk> zyga, doesn't snapd remap uids?
<zyga> Ackk, no we donât do that
<zyga> pstolowski: is there anything we can add to snapd to fix people with broken state
<ackk> zyga, ah I see. anyway, that doesn't really matter, I just seemed to remember you talked about user mapping
<ackk> zyga, you guys, not you specifically :)
<zyga> Sorry, my memory is rusty. I need to review the notes from that week
<zyga> Yam
<pstolowski> zyga: yes, I think we need to remove these stray connections in InterfaceManager::initialize
<pstolowski> zyga: does that sound sensible?
<niemeyer> Okay! Let's do some more reviews..
<zyga> Hmmm, I think so but what is a stray connection? One without one or the other snap?
<pstolowski> zyga: yes
<pstolowski> zyga: ok, I think i know why we didn't see that before
<pstolowski> adding one more comment
<zyga> pstolowski: I think there's a deeper bug in refresh code in interfaces
<cachio> mborzecki, when you have some time coiuld you please take a look to #4721
<mup> PR #4721: tests: update interface tests to remove extra checks and normalize tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4721>
<zyga> oh
 * zyga waits for your new comment
<zyga> pstolowski: some code should not reach the state where it got ErrNoState
<zyga> pstolowski: probably our reconnect code is buggy tyhere
 * kalikiana wrapping up for the day
<pstolowski> zyga: commented
<zyga> right
<zyga> thanks, I'm looking forward to the PR
<pstolowski> zyga: yep, working on it, besides fixing reloadConnection I'll also add this cleanup on startup, wdyt?
<zyga> pstolowski: skip the cleanup for now
<pstolowski> zyga: ok
<zyga> pstolowski: let me think about that some more
<zyga> or propose it separatel
<zyga> y
<pstolowski> zyga: the cleanup could actually happen in reloadConnection, almost for free - Connect fails only if either plug or slot is missing
<zyga> let's be conservative for now, this can be cherry picked into the release
<zyga> we can always clean it up later
<pstolowski> ok
<zyga> pedronis, niemeyer: can you please ack 4941
<vidal72[m]> I wrote a post in forum. This raises my eyebrows https://forum.snapcraft.io/t/bogus-apps-in-store/4703
<niemeyer> #4941
<mup> PR #4941: vendor: update gopkg.in/yaml.v2 to the latest version <Created by zyga> <https://github.com/snapcore/snapd/pull/4941>
<zyga> Thank you!
<niemeyer> zyga: Tests pass, previously discussed in the meeting, and not much to review.. I've just merged
<zyga> thanks, I just wanted to ack this
<niemeyer> zyga: Thanks for doing so
<mup> PR snapd#4941 closed: vendor: update gopkg.in/yaml.v2 to the latest version <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4941>
<niemeyer> pedronis: I'm getting to the end of #4900 btw
<mup> PR #4900: many: use the new install/refresh API by switching snapstate to use store.InstallRefresh <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4900>
<niemeyer> vidal72[m]: You got a response there
<nacc> niemeyer: well, for part of the post
<nacc> probably the less important part, though :)
<zyga> hmmm, I get this on a clean tree
<zyga> https://www.irccloud.com/pastebin/WAMjnnmK/
<vidal72[m]> so if I publish with invalid license it can stay this way forever? Nobody verify, nobody care?
<zyga> is my govendor foo not great or is there a real problem?
<niemeyer> nacc: Yes, there are about 10 questions on that post.. :) I've answered a few more of them
<mup> PR snapd#4945 opened: vendor: update gopkg.in/yaml.v2 to the latest version <Created by zyga> <https://github.com/snapcore/snapd/pull/4945>
<nacc> niemeyer: heh
<niemeyer> vidal72[m]: Please ask any other questions there so we can have a single conversation
<niemeyer> nacc: Feel free to participate as well
<niemeyer> nacc: Assuming you have points other than "heh", of course
<nacc> niemeyer: sure
<vidal72[m]> niemeyer: ok
<mup> PR snapd#4946 opened: Ignore bad connections in reloadConnections, don't surface them outsiâ¦ <Created by stolowski> <https://github.com/snapcore/snapd/pull/4946>
<pstolowski> zyga: ^
<pedronis> niemeyer: fwiw, that one contains everything, it has prereqs
<niemeyer> pstolowski: That PR title looks quite broken
<niemeyer> pedronis: Too late :)
<pstolowski> niemeyer: ah, sorry, fixed
<niemeyer> pedronis: For the best I suppose, in this case
<pedronis> it's quite large (though more than half is tests)
<jdstrand> roadmr: hi! not at all urgent, but can you pull in r1016 of CRT? (just another override)
<zyga> pstolowski: reviewed
<zyga> small change requested
<zyga> let me know if you think this is okay or if it turns out bigger than small
<pedronis> zyga: notice that reconnect on refresh doesn't exist in master,  it's a new thing in the interace hooks branch
 * cachio afk
<zyga> pedronis: hmmm, but we do reload connections on upgrade
<zyga> otherwise people on beta would not hit this case, no?
<pedronis> zyga: reloading connections,  and reconnect are two different things
<pedronis> we always been reloading connections
<pedronis> afaik
<pstolowski> zyga: Connect() can fail only if either: plug or slot is missing, or interfaces on them don't match. we need to ignore both these cases and not add to affectedSnaps. the error message that people reported will not be visible anymore, we will only log to the logger
<pstolowski> zyga: changing error reporting in Connect will affect ifacestate and api tests, so not exactly a small change
<zyga> no, the error on interface mismatch is one thing
<zyga> but when something is just *gone* that's the error we don't want to show
<niemeyer> pedronis: Review is out
<pedronis> niemeyer: thanks, this was the big one so you covered also the prereqs.  (4896, 4772 and 4771)
<pedronis> niemeyer: #4873 is for delaying registration
<mup> PR #4873: many: delay classic registration until first store interaction <Critical> <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4873>
<mborzecki> quit
<niemeyer> pedronis: Looking
<pstolowski> zyga: how about this: https://pastebin.ubuntu.com/p/YyrYQY8FBw/ ?
<niemeyer> pedronis: Okay, I think I can grasp it
<niemeyer> pedronis: Do you have some time for a short call?
<niemeyer> pedronis: About the PR
<pedronis> niemeyer: yes
<niemeyer> pedronis: Okay, let's hop onto snappy-devel
<pedronis> niemeyer: I'm there
<kyrofa> niemeyer, do you have any time today to meet about architectures?
<pstolowski> zyga: i've pushed the above change to the PR, eod
<roadmr> jdstrand: sure, 1016 going in the queue \o/
<jdstrand> thanks! :)
<niemeyer> kyrofa: In a call for the last hour.. tomorrow might be easier if it works for you
<kyrofa> niemeyer, sergiusens will be on vacation after today, but I can be there
<mup> PR snapcraft#2036 closed: errors: remove stack data when sending to sentry <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2036>
<jdstrand> stokachu: did you update lxd to work around the environment scrubbing issue (ie, the not being able to find liblxc.so.1)?
<jdstrand> stokachu: nm
<jdstrand> stgraber: hey, did you update lxd to work around the environment scrubbing issue (ie, the not being able to find liblxc.so.1)?
<jdstrand> stgraber: I'm trying to reproduce. I thought all I needed was an upstream kernel with apparmor enabled, but maybe I am misremembering
<stgraber> jdstrand: we might have accidentally worked around it
<stgraber> jdstrand: let me check
<stgraber> jdstrand: yeah, we did, we had to set LD_LIBRARY_PATH for zfs to be happy in some cases, so that's effectively masking the bug you're looking at
<stgraber> jdstrand: "snap run --shell lxd" and then running "aa-exec -p unconfined" should let you reproduce it though
<jdstrand> stgraber: that would explain it
<jdstrand> I'm wondering how important this is to fix in snapd then
<jdstrand> I filed the apparmomr bug so we'll get a fix eventually
<stgraber> that'd still break all classic snaps though wouldn't it?
<stgraber> classic snaps on distros with similarly lacking apparmor support that is
<stgraber> as the same profile as LXD would be used and LD_LIBRARY_PATH would get stripped as a result
<stgraber> whether that'd break such a snap is another matter though, a lot of them may be fine not using any of the core snap's libs?
<jdstrand> stgraber: classic snaps have all kinds of weirdness with their libs and don't set LD_LIBRARY_PATH
<jdstrand> we've also not seen any reports against them
<stgraber> ok, anyway, yes, for LXD this isn't a problem anymore because we always consider whatever snap-confine sets to be bad and override it ourselves in our wrappers
<jdstrand> stgraber: so, what I was thinking was that I'd have a lxd-support specific fix in snapd while we wait for the kernel to be fixed
<jdstrand> but if you don't care any more...
<stgraber> we can probably wait for the kernel fix, we're only likely to run into this again if we add a new command and forget about it, which is somewhat likely but also a pretty quick workaround to put in place on our side once someone reports it
<jdstrand> stgraber: I don't mind looking at an lxd-support fix for at least a little bit, but trying to find the correct aa-exec -p unconfined -- ??? invocation to demonstrate the issue
<stgraber> I "think" the reproducer on Sergio's system was:
<stgraber> snap exec --shell lxd
<stgraber>   export LD_LIBRARY_PATH=foo
<stgraber>   aa-exec -p unconfined bash
<stgraber>     echo ${LD_LIBRARY_PATH}
<stgraber> which would then show up empty rather than containing "foo"
<jdstrand> stgraber: sure, I know about that part (that is in the bug I filed and have all the reproducer's etc)
<jdstrand> stgraber: but I'm looking for the liblxc issue specifically
<stgraber> ok, the liblxc issue is because prior to us always setting LD_LIBRARY_PATH ourselves, we'd rely on snap-confine doing that for us, so it looked like 1) user runs "lxd init" 2) calls snap-confine which sets LD_LIBRARY_PATH 3) The wrappers/commands/lxd is execed 4) Script re-execs itself through aa-exec -p unconfined loosing its LD_LIBRARY_PATH 5) Script exec bin/lxd which is linked against liblxc, causing
<stgraber> loader error due to missing library
<jdstrand> fyi, snap-confine doesn't do anything with LD_LIBRARY_PATH
<jdstrand> alright, I'll keep playing with it
<stgraber> oh, then whatever sets it :) the snap binary itself I guess?
<jdstrand> it's a weird call stack, but it is snapenv.go that keep sit from getting stripped when going through setuid snap-confine
<jdstrand> anyhoo, I'll look at this a bit, but may end up moving to something else
<jdstrand> oh, I could install an affected revision
<jdstrand> stgraber: was the change in lxd-pkg-snap.git or lxd.git?
<stgraber> jdstrand: it was in lxd-pkg-snap, when we started including multiple zfs versions
<jdstrand> db211759
<jdstrand> ok, cool
<stgraber> jdstrand: http://paste.ubuntu.com/p/s4gMQvB9dx/
<stgraber> jdstrand: applying that and then building the snap should give you a build that'll have the issue when running "lxd init"
<jdstrand> right
<jdstrand> cool, thanks!
<zyga> Hmmm
<zyga> On a phone
<zyga> Ld library path is reset because of at secure
<jdstrand> stgraber: fyi, the 2.0 channel is still affected:
<jdstrand> $ sudo /snap/bin/lxd init
<jdstrand> lxd: error while loading shared libraries: liblxc.so.1: cannot open shared object file: No such file or directory
<zyga> But we have a system where certain variables are saved and restored as Snappy prefix $varname
<jdstrand> zyga: that isn't the issue
<zyga> Oh sorry just noticed notification from my phone
<stgraber> jdstrand: oh, that'd make sense since we haven't done the multi-zfs version trick there yet
<stgraber> jdstrand: well, that makes it easier to test :)
<jdstrand> zyga: it is related to at secure of course, but the bug is this: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1759346
<mup> Bug #1759346: ix scrubs environment when it shouldn't <aa-kernel> <apparmor (Ubuntu):New> <https://launchpad.net/bugs/1759346>
<jdstrand> stgraber: indeed
<zyga> Looking
<jdstrand> stgraber: it also means you can workaround it easy enough in the 2.0 packaging
<zyga> I see
<zyga> Still we have a system where snap run and snap exec cooperate and can save restore environment
<stgraber> jdstrand: yeah, got to update a whole bunch of stuff in 2.0, haven't done too much of it given our tiny snap user base for it vs deb
 * jdstrand nods
<jdstrand> zyga: yep
<Caelum> zyga: I updated my two PRs, will look at package issues later tonight
<zyga> Thank you!
<Caelum> zyga: I don't know why you saw snap-repair, because I definitely remove those, you may have been looking at an older revision
<zyga> Oh
<zyga> Perhaps, I will check out and see tomorrow
<zyga> Did you get Spotify to open browser links
<Caelum> no let me try that
<zyga> That requires the service files
<Caelum> yeah it doesn't work
<Caelum> firefox opened a second spotify and didn't open the track
<jdstrand> zyga: note that the issue happens after the snap run/snap env business. ie, LD_LIBRARY_PATH is preserved. The act of running aa-exec, which has ix, strips LD_LIBRARY_PATH such that the thing it execs doesn't see it
<zyga> I see jdstrand
<jdstrand> zyga: also, this is *only* partial apparmor support which gets the '/** pix,' rule
<jdstrand> which applies to aa-exec
<jdstrand> anyway. thinking through how to fix it. I have ideas
<zyga> Do we need a user space workaround
<jdstrand> I'm thinking about a snapd change to partial policy
<zyga> Ok
<jdstrand> really, we need the kernel fixed, and it will be
<jdstrand> it is possibly a documentation change only
<mup> PR snapcraft#2039 opened: Release changelog for 2.40.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2039>
<mup> PR snapd#4945 closed: vendor: update gopkg.in/yaml.v2 to the latest version <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4945>
<nacc> kyrofa: sigh, sergiusens mentioned they had used the git-ubuntu.self-test, but it looks like maybe it's busted again -- (our CI flagged it, it passed on one run that was using 2.39.3+really2.35 (https://jenkins.ubuntu.com/server/job/git-ubuntu-ci/345/consoleFull) and failed one that used 2.40 (https://jenkins.ubuntu.com/server/job/git-ubuntu-ci/349/consoleFull). The former branch had the latter as an
<nacc> ancestor, so it implies not a ocding error (and neither touches the gpgv paths)
<nacc> kyrofa: hrm, now i had a job succeed with 2.40
<nacc> ... that's not great either
#snappy 2018-03-28
<sergiusens> nacc: if you are seeing failures to upload; this has been going on all day (not related to 2.40) and something snapstore related
<nacc> sergiusens: no, wasn't that -- and now i'm thinking it is something else (possibly worse, in that some jobs succeeded and some failed). I'm retriggering all 4 so they use 2.40 hopefully and we'll see what happens
<nacc> sergiusens: urgh ... unsquashfs failures? https://jenkins.ubuntu.com/server/job/git-ubuntu-ci/350/console
<nacc> i just had two of the four fail that way
<nacc> sergiusens: but the other two got past that point, it seems
<sergiusens> nacc: that is a corrupted download of the core snap; this is part of the general store slow down we are all waiting to get fixed
<nacc> sergiusens: oh ok, retry should work?
<nacc> sergiusens: or is there a better ... solution?
<sergiusens> nacc: I am not in the store team, but a retry could work, yes
<nacc> sergiusens: thanks!
<nacc> we'll see what it does :)
<sergiusens> nacc: btw, why aren't you using launchpad buildd and such?
<cjwatson> I can understand people not doing so for per-commit CI
<cjwatson> Though I hope we'll support that kind of thing at some point
<nacc> sergiusens: what cjwatson said
<nacc> sergiusens: in any case, some jobs are showing the link error for libgpg-error still
<nacc> but not all
<nacc> sergiusens: which feels like a worse place to be than we were
<nacc> i'll start debugging in the AM
<mup> PR snapcraft#2039 closed: Release changelog for 2.40.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2039>
<mup> PR snapcraft#2040 opened: lifecycle: always prime dependencies <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2040>
<mborzecki> morning
<mborzecki> something wrong with the store? the download seems to be capped at 50-60kBps
<zyga> good morning
 * zyga goes to wake the kids
<zyga> mborzecki: yes, store is affected by ceph issue
<mborzecki> ceph has fallen apart/
<mborzecki> ?
<zyga> mborzecki: not sure what happened really
<zyga> it's online but very slow apparently
 * zyga is almost done with the kids
<zyga> not if only kids made me breakfast in return :)
<zyga> good morning pedronis, is #4931 ready to go? it has 2 "+1"s and it is green but you expressed an idea that there's perhaps more to be done in that area
<mup> PR #4931: configcore: give a chance to immediately recompute the next refresh time when schedules are set <Blocked> <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4931>
<zyga> pstolowski|afk: I'll play with #4946
<mup> PR #4946: ifacestate: don't surface stale connections <Created by stolowski> <https://github.com/snapcore/snapd/pull/4946>
<pstolowski> morning
<kalikiana> moin moin
<kalikiana> o/ pstolowski
<pstolowski> hey kalikiana
<pedronis> zyga: yes, it needs to be done differently to be correct
<zyga> pedronis: thanks for confirming that
<pedronis> that's why IÂ marked it blocked
<mup> PR snapd#4920 closed: timeutil: in Human, count days with fingers <Created by chipaca> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4920>
<zyga> pstolowski: hey, I pushed to https://github.com/snapcore/snapd/pull/4946/files
<mup> PR #4946: ifacestate: don't surface stale connections <Created by stolowski> <https://github.com/snapcore/snapd/pull/4946>
<zyga> can you please have a look
<pstolowski> zyga: thanks, looking
<pstolowski> zyga: looks good, thanks for extra test
<pstolowski> zyga: thinking about this stale connections problem.. as i mentioned on the forum, discard-conns is the last task on snap-removal, it may never get executed if a task before it fails; if think we should run this task regardless of any earlier error (use Lanes?)
<zyga> pstolowski: can you walk me through an example please
<zyga> (sorry for the lag, my daughter is just leaving for school now)
<pstolowski> zyga: we run stop-snap-services, remove-aliases, unlink-snap, remove-profiles, remove hook, discard-conns is last; in particular remove-hook can easily pose problems; discard-conns should be executed always I think
<pstolowski> zyga: and nb, i wonder if remove hook shouldn't be called earlier in the sequnce, it's probably run too late
<zyga> pstolowski: when remove hook fails, what happens then?
<pstolowski> zyga: ah, ignore remove-hook failure, no problem there, we set ignoreError:true on it
<pstolowski> zyga: so yeah, the only problem is if any other task fails and discard-conns is not reached
<pstolowski> I need to run to the dentist, bbl
<zyga> pstolowski: sure
<zyga> pstolowski|denti: when you are back, do we undo stuff when any of those fail?
<pstolowski|denti> zyga: no, we don't have undo on snap removal, afair it's very hard to undo those
<pstolowski|denti> (something we discussed on different occasion with pedronis afair)
<mup> PR snapcraft#2013 closed: tests: run tests on Trusty on Travis <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/2013>
<pedronis> zyga, mborzecki: #4931 is updated
<mup> PR #4931: configcore: give a chance to immediately recompute the next refresh time when schedules are set <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4931>
<zyga> lookinbg
<pedronis> zyga: the change is simple, testing it a bit less so
<mup> PR snapcraft#1800 closed: grammar: on..to statement <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1800>
<mup> PR snapcraft#1900 closed: many: handle copying of symlink permissions gracefully <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1900>
<mborzecki> zyga: do you know what the plan for nvidia is?
<zyga> mborzecki: review your branch with gustavo
<zyga> mborzecki: and I think we'll do 2.32.2 with this
<mborzecki> zyga: oh ok
<zyga> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1648681.html
<zyga> not a happy store day
<sparkiegeek> zyga: we're just helping you improve your error handling ;)
<zyga> sparkiegeek: oh yes, we need to get creative on the word "http" :-)
 * zyga hugs sparkiegeek 
<zyga> it's good that we have plenty of reviews to make :)
<om26er> popey: kindly register the name 'sublime-text' under snapcrafters as I don't have the permissions to do so.
 * zyga would love to see sublime-text with subl alias 
<popey> om26er: someone else has registered it, back in 2016
<popey> but never uploaded anything
<popey> I'll ping them a mail to let them know we'd like to take it over
<om26er> popey: yeah, that would make sense
<om26er> zyga: the app name is already subl in the yaml file, so we only need the alias (that I'll request once we upload it).
<zyga> pedronis: I reviewed #4931
<mup> PR #4931: configstate: give a chance to immediately recompute the next refresh time when schedules are set <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4931>
<popey> om26er: mail sent
<popey> lets give it a few days for them to respond
<zyga> om26er: perfect!
<zyga> om26er: I use the deb still but I  use sublime everywehre so I'm super happy to switch
<zyga> it would be nice if there was a way for github to add a banner to pull request page saying "we know about XXX issue, tests are red while that happens"
<om26er> aha, so you are our first user ;-)
<popey> well crap, their email bounces
<om26er> zyga: I also contacted upstream, so you got anything to add there: https://forum.sublimetext.com/t/modern-instalation-snap-package/31123
<zyga> is wbond the upstream?
<om26er> zyga: yes
<om26er> popey: bummer, wonder what's next for us.
<mup> PR snapd#4921 closed: skip test if no user "daemon" in build jail <Created by rkitover> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4921>
<popey> I'm going to take it.
<popey> if you registered a snap over a year ago, never uploaded anything and deleted your email address...
<zyga> pedronis: can you please look at https://github.com/snapcore/snapd/pull/4911
<mup> PR #4911: daemon,client: add build-id to /v2/system-info <Created by mvo5> <https://github.com/snapcore/snapd/pull/4911>
<zyga> I'm inclined to merge it but I wanted to double check
<pedronis> do we still know if we need it?
<zyga> I don't think we need it but it's actually very useful for other reasons
<zyga> snap version is how we ask people to report bugs and give us initial hints
<popey> om26er: done, snapcrafters has sublime-text now
<om26er> popey: do we need to ask for 'classic' confinement again ?
<om26er> also what about remove the name sublime-text-3 completely, is that possible ?
<popey> Yes, I would recommend asking for both the alias and classic confinement in one post
<popey> we can just unpublish the sublime-text-3 so nobody can see it
<om26er> popey: we already have a alias request in forum.snapcraft.io, so only created a new request for classic confinement
<popey> Awesome
<popey> Nice work om26er :)
<pstolowski> back
<om26er> popey: have you also enabled auto builds for that new name ?
<popey> not yet.
<om26er> hmm, I think for classic confinement request to proceed we would need to have something in the build queue.
<om26er> ...same goes for alias request
<popey> one moment, I have to remve s-t3 first
<popey> https://usercontent.irccloud-cdn.com/file/JzviDh1g/
<popey> ^
<pedronis> zyga: I will re-look in a bit,  I'm in a twisty maze of conflicts and also it getting close to lunch
<zyga> pedronis: ack, thank you and enjoy your lunch :)
<popey> https://usercontent.irccloud-cdn.com/file/fNwd5Kq9/
<popey> ^ om26er
<greyback> was there a CI wobble? https://github.com/snapcore/snapd/pull/4932
<mup> PR #4932: interfaces/content: add rule so slot can access writable files at plug's mountpoint <Created by gerboland> <https://github.com/snapcore/snapd/pull/4932>
<greyback> log complaining of odd things
<mborzecki> zyga: pushed updates to #4942
<mup> PR #4942: cmd/snap: user session application autostart v3 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4942>
<popey> om26er: all done from here?
<greyback> mborzecki: yay, thanks for that, I'm looking forward to using it
<om26er> popey: seems so, yes
<popey> awesome
<popey> o/ thanks again!
<om26er> popey: add me as a collaborator ?
<zyga> om26er: can you please ping me once the snap is published
<om26er> zyga: sure, will do.
<mup> PR snapd#4947 opened: spread: disable StartLimitInterval option on opensuse-42.3 <Created by stolowski> <https://github.com/snapcore/snapd/pull/4947>
<om26er> popey: whenever you read this: 1. Kindly add me as a collaborator to sublime-text, 2. I can still `snap info sublime-text-3` so its not really gone.
<om26er> zyga: the build failed because it requires classic confinement, that I believe will be granted by jdstrand (and also the alias).
<zyga> om26er: did it fail or just got flagged on upload?
<om26er> zyga: the latter.
 * zyga reviews 4772
<zyga> that's a biggie
<zyga> I'm reading and scrolling and scrolling
<zyga> and thinking, gee, how long is this
<zyga> then noticed the header :)
<pstolowski> E: Unable to locate package linux-image-extra-4.15.0-12-generic on ubuntu 18.04 in spread
<zyga> pstolowski: missing update perhaps?
<pstolowski> or archive not fully sync? i've restarted the test, let's see if it persists
<zyga> nowadays archive cannot be partially synced
<pedronis> zyga:  I have a nitpick about #4911
<mup> PR #4911: daemon,client: add build-id to /v2/system-info <Created by mvo5> <https://github.com/snapcore/snapd/pull/4911>
<zyga> pedronis: I'll tweak tha
<zyga> that
<zyga> pedronis: done
<zyga> pedronis: review on the big store PR
 * zyga breaks for 15 minutes
 * zyga debugs current 18.04 issue
<mborzecki> off to pick up my daughter from school, bb for standup
<zyga> hmm
<zyga> I know what's wrong now
<zyga> cachio: ping
<cachio> zyga, hey
<zyga> cachio: two questions
<zyga> what is our kernel in google ubuntu bionic image?
<zyga> I get Linux mar281357-854414 4.15.0-12-generic #13-Ubuntu SMP Thu Mar 8 06:24:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
<mup> PR #13: Bugfix/review tools reenable <Created by mvo5> <Merged by elopio> <https://github.com/snapcore/snapd/pull/13>
<zyga> which is very odd
<zyga> second
<zyga> we need to regenerate that image
<zyga> and get a more recent kernel
<zyga> because modules for this kernel are no longer in the package
<zyga> this must be done ASAP or we must disable bionic tests
<zyga> we fail because essentially this happens:
<zyga> google:ubuntu-18.04-64 ...# apt-cache policy linux-image-extra-4.15.0-12-generic
<zyga> N: Unable to locate package linux-image-extra-4.15.0-12-generic
<zyga> N: Couldn't find any package by glob 'linux-image-extra-4.15.0-12-generic'
<zyga> N: Couldn't find any package by regex 'linux-image-extra-4.15.0-12-generic'
<cachio> zyga, the ubuntu bionic image is not generated by us
<cachio> zyga, let me try with the last image
<zyga> cachio: ah, I see
<zyga> yeah, let's try today's image
<cachio> yes
<zyga> if this works I'll send the PR
<mup> PR snapd#4721 closed: tests: update interface tests to remove extra checks and normalize tests <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4721>
<zyga> cachio: have a look at 4948
<mup> PR snapd#4948 opened: spread: use more recent bionic snapshot <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4948>
<cachio> zyga, aoorived
<cachio> zyga, just wait to see the test results
<zyga> thanks, let's see if something blows up along the way
<zyga> I'm running it locally here and it's past the point where it broke earlier
<cachio> zyga, this images are being updated every day with latest changes
<zyga> yeah, it's something w may have to repeat until release
<cachio> previously I made to detect automatically the last one and use it
<zyga> after release I assume our image will be an alias to the latest stable bionic image
<cachio> but we had problems too
<cachio> yes
<pedronis> zyga: IÂ upadted #4931 , let me know if it's clearer
<mup> PR #4931: configstate: give a chance to immediately recompute the next refresh time when schedules are set <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4931>
<zyga> thanks, looking
<mup> PR snapd#4877 closed: snap-confine: fallback to /lib/udev/snappy-app-dev if the core is older <Created by mvo5> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4877>
 * kalikiana lunch
 * zyga considers closing https://github.com/snapcore/snapd/pull/4349
<mup> PR #4349: Make snapd.autoimport configurable <Blocked> <Decaying> <Created by ogra1> <https://github.com/snapcore/snapd/pull/4349>
<zyga> we have plenty of PRs and this one doesn't seem to move now
<zyga> ogra_: ^
<ogra_> zyga, what should move there ?
<zyga> ogra_: the PR got NACKed, is there ongoing discussion or other reason to keep it open?
<zyga> note that we can always reopen things
<ogra_> zyga, it ends with a question from alex to gustavo that got never answered
<zyga> we're just struggling with the number of open PRs
<ogra_> zyga,  we need this feature for a customer ...
<ogra_> one way or the other
<niemeyer> What's the PR?
<ogra_> my suggestion was turned down, a question was asked what a better approach would be and that is where it stands now
<zyga> niemeyer: #4349
<mup> PR #4349: Make snapd.autoimport configurable <Blocked> <Decaying> <Created by ogra1> <https://github.com/snapcore/snapd/pull/4349>
<mup> PR snapd#4948 closed: spread: use more recent bionic snapshot <Critical> <Created by zyga> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4948>
<zyga> thanks Sergio!
<zyga> we need to merge master into most important PRs that are ready to land now
<ogra_> zyga, niemeyer, the way more important one is #4819 though ... thats slowly getting urgent
<mup> PR #4819: interfaces/serial: change pattern not to exclude /dev/ttymxc* <Created by bergotorino> <https://github.com/snapcore/snapd/pull/4819>
<zyga> cachio: I made a back port of the google update for 3.32 but it seems we are still using linode there
<ogra_> (i think koza adjusted it properly to be mergeable)
<zyga> ogra_: I'll look now
<ogra_> ... that one also has an open alex question :)
<zyga> that one looks mergeable now, with the updates given it adds one specific new pattern and corresponding tests
<zyga> hmm
 * zyga needs to read the tests in detail though
<mup> PR snapd#4349 closed: Make snapd.autoimport configurable <Blocked> <Decaying> <Created by ogra1> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/4349>
<ogra_> right, but we need to do something about the fact that it will bite us again with the next customer
<ogra_> so long term a more graceful regex is needed
<ogra_> (manufacturers tend to invent their own tty names for serial ports ... thats not uncommon)
<zyga> ogra_: what names those serial ports? that's a specific kernel driver picking such name?
<ogra_> zyga, the BSP kernel typically
<ogra_> or the devicetree
<niemeyer> ogra_: Closed, commented, let us know
<zyga> ogra_: I believe it will largely fix itself with hotplug
<ogra_> zyga,  point is ... vendors tend to make up new ttyXXX names when introducing a new board
<ogra_> and customers using the image tend to waste hours and hours trying to find out why the serial interface they defined does not work at all ... there is no actual valid reason to have a whitelist there
<zyga> ogra_: there are some reasons, it's not as clear cut as you claim IMO; still I think work on hot plug will change how we do this thing, it may be that for devices that are automatically detected we will trust the path
<ogra_> (but i'm preaching that since we started adding this list in #2626 ... )
<mup> PR #2626: interfaces: relax path requirements for serial <Created by jocave> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2626>
<zyga> koza: hey
<zyga> koza: looking at #4819, can you tell me what the various test changes are for
<mup> PR #4819: interfaces/serial: change pattern not to exclude /dev/ttymxc* <Created by bergotorino> <https://github.com/snapcore/snapd/pull/4819>
<zyga> koza: I was expecting just some new test chunk
<mup> PR snapd#4672 closed: tests: adding test for removable-media interface <Go! Go! Go!> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4672>
<zyga> koza: not alterations to existing tests
<ogra_> zyga, FYI note that the customer is stuck working on their own features due to this since a week before the sprint ... (the devices are needed for some of their BT addo boards that everything else depends on)
<ogra_> *addon
<ogra_> zyga, it would be good if we didnt run into this again ... if hotplug helps with serial terminals etc then fine ... if we cant get it in time fore the next customer loosening the whitelist would be helpful though
<zyga> ogra_: we cannot open it up to arbitrary tty string AFAIR but I understand what you are saying
<ogra_> zyga, can you explain why we cannot open it up with a less strict regex ?
<ogra_> (nobody explained the reason for this ever... which caused alex' question in that PR)
<mborzecki> zyga: fwiw yocto keeps a list of 'known' tty names in the project tree https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-extended/shadow/files/securetty
<zyga> mborzecki: that's pretty useful
<mborzecki> probably covers most of what you'd see in the wild
<ogra_> zyga, i understad that we do not want to open access to tty[0-n] here ... but everything else *is* a serial tty
<zyga> ogra_: as chipaca there commented, /dev/tty, /dev/ttyN are off-limits
<ogra_> yes
<ogra_> so a regex that makes sure you have a letter there would suffice
<zyga> oh
<zyga> standup
<mborzecki> zyga: gogogo
<ogra_> zyga,  having to wait one full snapd release cycle fore every customer that has a new serial tty name is costly and not really practical ... and there seems to be n reason for that strictness
<ogra_> *no
<zyga> ogra_: I'll work on landing this PR and we can discuss with jdstrand if a more open regex is ok
<ogra_> zyga, great (i talked to jdstrand in budapest and he said he would support opening it up)
<zyga> ok
<ogra_> (if you read the old PR he already supported it there ;) )
<jdstrand> it's true. we shouldn't do it without niemeyer though since the current approach is based on his decision
<ogra_> yes
<jdstrand> note the other day I mentioned a middle ground: take ogra_'s list and expand the regex for everything we know about
<jdstrand> if we had done that, the latest one would've already been allowed
<ogra_> yep :)
<jdstrand> so I suspect future boards will tend to just work if we do that
<ogra_> unless a vedor adds a new name :)
<jdstrand> hence 'tends' :)
<ogra_> (which happens more frequent than one would think sadly :) )
<ogra_> (i admittedly never understood that ... ttyS* used to be sufficient for like 15 years ... but apparently branding on a device node level became a thing at some point)
<alexlarsson> jamesh: hey, did you see https://github.com/flatpak/xdg-desktop-portal/issues/167#issuecomment-376810447
<koza> zyga, answered
<kalikiana> re
<koza> zyga: thanks and sorry for confusing ;-)
<zyga> nah, ok
<zyga> I'm just dumb today
<pedronis> niemeyer:  btw the first PRÂ of the chain is #4771,  the rename to SnapAction etc is there
<mup> PR #4771: store: add Store.SnapAction to support the new install/refresh api endpoint <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4771>
<pedronis> niemeyer: I scheduled something with Bret after your lunch break
<niemeyer> pedronis: Thank you!
<ondra> kyrofa is sergio around or on holidays?
<kyrofa> ondra, sergio is on holidays for the rest of this week and next. Can I help?
<om26er> popey: Hey! did you add me as a collaborator for sublime-text ?
<popey> om26er: no. I don't think we should. The requirements for classic confinement prohibit it.
<popey> om26er: sorry, been on and off the keyboard as I'm on holiday
<popey> (currently getting my car tyres replaced) :)
<om26er> alright ok. I had rights to android studio and sublime previously ;-)
 * zyga break
<ondra> kyrofa already chatted to ev https://bugs.launchpad.net/snapcraft/+bug/1759592
<mup> Bug #1759592: kernel build fails for lack of modprobe <Snapcraft:New> <https://launchpad.net/bugs/1759592>
<jdstrand> roadmr: two snaps have a weird runtime error: https://dashboard.snapcraft.io/snaps/tiled/revisions/61/ and https://dashboard.snapcraft.io/snaps/huggle/revisions/651/
<roadmr> jdstrand: yes :(
<jdstrand> roadmr: what is that about?
<roadmr> jdstrand: we've been having wobbly/slow transfers (uploads/downloads) since yesterday.
<jdstrand> ok
<kyrofa> ondra, and that's a regression from 2.35, sounds like?
<ondra> kyrofa just getting frustrated that yet another break for kernel snap build in LP. Close to give up on LP builds
<jdstrand> roadmr: so retriggering the review should allow it to continue?
<roadmr> jdstrand: what's happening is that, as the store server tries to pull the snap for review, it times out resulting in an incomplete transfer...
<roadmr> jdstrand: that constitutes an invalid squashfs causing those errors you see.
<ondra> kyrofa this is for deb, so before builds were failing because of wrong initrd location
 * jdstrand nods
<roadmr> jdstrand: sometimes, yes; if the retry manages to get a full download, it'll work. Worth a try.
<roadmr> jdstrand: it'll all normalize once our storage goes back to full speed
<roadmr> jdstrand: I'll try to get an ETA on that
<jdstrand> roadmr: yep, cool. thanks!
<ondra> kyrofa locally this is unlikely to fail, as usually you have modprobe installed
<kyrofa> ondra, okay, we need to SRU another quick fix as well, so I'll get this fix in there as well, hang tight
<jdstrand> roadmr: with the r1015, I wanted to not assume anything (not that those changes would cause this)
<cachio> zyga, which info do you need for #4943
<mup> PR #4943: tests: adding debian sid to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4943>
<ondra> kyrofa may be add LP build as part of release test
<roadmr> jdstrand: yes, makes sense, but I'm certain it's unrelated. We've been seeing this since before 1015 was rolled out
<roadmr> jdstrand: (things broke yesterday morning, 1015 rolled out today wee hours)
<jdstrand> roadmr: yep. not saying it was related, just wanted to touch base
<roadmr> jdstrand: appreciated :) thanks
<cachio> zyga, https://paste.ubuntu.com/p/B5QY2GDBkB/
<cachio> zyga, I don't see errors on logs
<kyrofa> cjwatson, if I set the "source archive" when requesting a snap build in LP to a PPA containing a newer snapcraft, will that use the newer snapcraft?
<cachio> zyga, https://paste.ubuntu.com/p/kM7zMJtQHB/
<popey> om26er: we should fix that :S
<popey> om26er: sublime-text amd64 is in edge
<cjwatson> kyrofa: Yes
<popey> i need to put an icon in the store om26er
<om26er> popey: yeah and a screenshot as well
<cjwatson> ondra: One of the purposes of the work in progress to allow LP builds to consume snapcraft as a snap is to make it easier to do LP-build-based QA as part of release tests
<cjwatson> Not immediately helpful to you, but it is definitely something we've discussed and have work in progress to improve
<kaliy> hi. who could I ping to transfer ownership of a snap in the store?
<popey> om26er: i have also closed the sublime-text-3 channels
<popey> kaliy: nessita  is who usually processes mine, and requires an email to proove ownership
<popey> -typos
<zyga> I will be back soon
<popey> om26er: tested locally, the snap works fine, subl alias works
<popey> om26er: ok, added icon and a screenshot.
<ondra> cjwatson yeah using snapcraft snap in LP build will be so much better and predictable
<popey> om26er: want me to push to stable?
<ondra> cjwatson and if we can specify channel to use, that would be dream :D
<nessita> popey, hey there, can I help with anything?
<popey> nessita: hi, kaliy was asking about snap re-ownership
<nessita> kaliy, hey there. If you own the snap, we'll need an email sent from the same email address owning the snap, including the target owner, and getting some ack'd from the new owner
<nessita> kaliy, with that I can proceed with the snap transfer
<niemeyer> pedronis: #4771 LGTM with some additional suggestions
<mup> PR #4771: store: add Store.SnapAction to support the new install/refresh api endpoint <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4771>
<cjwatson> ondra: That's exactly what we're working on, yes
<ondra> cjwatson yeah!
<popey> om26er: i need to go afk in a bit, want me to publish this snap? :)
<zyga> re
<mup> PR snapd#4949 opened: tests: fix quoting issues in econnreset test <Created by zyga> <https://github.com/snapcore/snapd/pull/4949>
<pedronis> niemeyer: meeting?
<kaliy> nessita: ack! to which email should I send that?
<niemeyer> There!
<nessita> kaliy, pinging privately to give you the email
 * kalikiana out
<niemeyer> mborzecki: Where's the nvidia PR?
<mborzecki> niemeyer: https://github.com/snapcore/snapd/pull/4908
<mup> PR #4908: [RFC] cmd/snap-confine: attempt to detect if multiarch host uses arch triplets <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4908>
<niemeyer> mborzecki: DO you have a moment for a call?
<mborzecki> niemeyer: give me a sec
<mborzecki> niemeyer: standup ho?
<niemeyer> Okay.. I need to change clothes as well as it's getting unreasonably warm.. will be there in a minute
<cachio> zyga, is it ok the change for #4943 ?
<mup> PR #4943: tests: adding debian sid to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4943>
<mup> PR snapd#4682 closed: tests: new spread test for physical-memory-control interface <Decaying> <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4682>
<zyga> cachio:  Iâm afk shopping for groceries
<zyga> Looking now
<cachio> hehe, it is ok
<zyga> Nice
<zyga> Thank you!
<mup> PR snapd#4950 opened: test: move interfaces-removable-media to manual until issue on fedora is fixed <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4950>
<cachio> pedronis, could you plase see this #4950
<mup> PR #4950: test: move interfaces-removable-media to manual until issue on fedora is fixed <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4950>
<cachio> we have the master broken for this issue
<cachio> pedronis, I am working in a solution be I moved that to manual to unblock other PRs
<pedronis> cachio: if it takes a while we should probably switch not to manual but have an if at the beginning of the sections
<pedronis> IÂ mean take a while to fix
<cachio> pedronis, you mean to skip just that part?
<cachio> for fedora
<pedronis> yes
<pedronis> mmh
<cachio> not sure how long it will take as the snap is failing
<cachio> it is not seem to be a test issue
<cachio> I can do that change
<pedronis> cachio: sorry, now that IÂ think of it
<pedronis> should we use the systems filter?
<cachio> yes
<pedronis> systems: [-fedora-*]  or something like that?
<cachio> updated
<pedronis> thanks
<cachio> pedronis, thanks to you for reviewing
<mup> PR snapcraft#2041 opened: kernel plugin: add kmod as build-package <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2041>
<Caelum> zyga: I update my second PR and now I'm looking at your notes on the package
<mup> PR snapd#4950 closed: test: move interfaces-removable-media to manual until issue on fedora is fixed <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4950>
<niemeyer> Taking a break for exercising.. back for a meeting at the top of the hour
<niemeyer> o/
<jdstrand> zyga: hi! fyi, on 16.04 system with up to date master:
<jdstrand> $ ./run-checks --static
<jdstrand> ...
<jdstrand> Running vet
<jdstrand> interfaces/apparmor/spec.go:129: arg l for printf verb %s of wrong type: *github.com/snapcore/snapd/snap.Layout
<jdstrand> exit status 1
<zyga> jdstrand: oh, looking
<zyga> looks like a bug in vet
<zyga> does this fix it for you?
<zyga> https://www.irccloud.com/pastebin/90wGfR4u/
<cachio> niemeyer, #4943 ready
<mup> PR #4943: tests: adding debian sid to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4943>
<kyrofa> zyga, are snaps confined on Debian?
<mup> PR snapd#4951 opened: interfaces/desktop-legacy: allow access to gnome-shell screenshot/screencast <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4951>
<mup> PR snapd#4896 closed: store: support macaroon refreshes in store.SnapAction <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4896>
<mup> PR snapd#4771 closed: store: add Store.SnapAction to support the new install/refresh api endpoint <Critical> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/4771>
<mup> PR snapd#4772 closed: tests/lib/fakestore/store:  teach the fake store to fake the new install/refresh endpoint <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/4772>
<niemeyer> cachio: \o/
<mup> PR snapd#4943 closed: tests: adding debian sid to google backend <Created by sergiocazzolato> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4943>
<cachio> niemeyer, just fedora remains in linode
<cachio> niemeyer, I could disable selinux for the google image and it should work, while we can work on fix the issues around it
<cachio> niemeyer, so we have all the machines in google
<niemeyer> cachio: How is it working in Linode
<niemeyer> ?
<cachio> selinux disabled
<niemeyer> cachio: So disabling in Google sounds fine
<cachio> niemeyer, it is gonna be temporal
<cachio> I'll make the change in that case
<niemeyer> cachio: Yeah, we can work on this spearately
<niemeyer> separately
<niemeyer> cachio: If Linode doesn't have it we won't lose anything and can migrate and work on that later
<cachio> niemeyer, yes, that's the idea
<cachio> otherwise we will never end with the movement
<niemeyer> Yep
 * cachio afk
<Caelum> this go stuff is weird, I can't even figure out how to build anything out of a git clone
#snappy 2018-03-29
<koala_man> how does snapcraft determine the version number from a git repository? my version number is way off
<diddledan> koala_man: it doesn't by default. You can set the version to "git" and it'll use the commit hash as the version string. Otherwise it uses whatever you set in the yaml. You can also use a version-script to code the rules for your application's source
<diddledan> Caelum: doesn't `go build` work?
<koala_man> diddledan: ok.. so where does v0.3.0 come from in https://build.snapcraft.io/user/koalaman/shellcheck/177997 ?
<diddledan> weird, it looks like it's picked up v0.3.0 from git via a tag somewhere, but then appended a commit hash on it (right at the bottom of the log):
<diddledan> https://www.irccloud.com/pastebin/sftr0qcu/
<koala_man> yes, but why did it pick 0.3.0 and not e.g. the latest 0.4.7 or the earliest 0.1.0?
<diddledan> that I'm not sure about
<diddledan> perhaps the commit history on master doesn't match any of those other tags?
<diddledan> so 0.3.0 is the latest tag that is in sync with master
<diddledan> in sync - I mean has a shared most recent commit in the tag with a commit that exists in master
<diddledan> might have to wait till the european daytime to get some more concrete answers from sergiusens when he awakens
<diddledan> or kyrofa if he's still awake?
<koala_man> I'm not entirely sure what you mean but `git log master` definitely shows other tags
<mborzecki> morning
<mup> PR snapd#4908 closed: [RFC] cmd/snap-confine: attempt to detect if multiarch host uses arch triplets <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4908>
<zyga> good morning
<zyga> mborzecki: I see that yesterday evening was fruitful
<mborzecki> zyga: hey, yes
<zyga> can you please prepare a backport for 2.32 as well
<mborzecki> yup, already have it, checked it on ubuntu too
<zyga> great, what's the PR for that?
<zyga> we could prepare another release today
<mup> PR snapd#4952 opened: [2.32] cmd/snap-confine: attempt to detect if multiarch host uses arch triplets <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4952>
<zyga> the media test is failing on fedora
<zyga> looks like a real bug
<mborzecki> zyga: might need the same treatment as media-sharing test on fedora
<mborzecki> zyga: idk if you recall, that's /media vs /run/media
<zyga> + test-snapd-removable-media.sh -c 'ls /media/testdir'
<zyga> ls: cannot access '/media/testdir': No such file or directory
<zyga> yes, I know exactly
<zyga> I had to code that difference
<zyga> :/
<zyga> ok, looking at what's there
<zyga> I _really_ wish fedora shipped a /media -> /run/media symlink
<zyga> but ... well
<mborzecki> i fixed media-sharing ~3 weeks ago, but iirc removable-media test was opened long before that
<zyga> mborzecki: were there any changes to the nvidia multiarch fix since I read that
<mborzecki> zyga: just one commit, i dropped some debug messages per niemeyer's request
<zyga> great
<zyga> ok, brb for coffee (I woke up waaay to late today)
<mborzecki> zyga: oh and maybe a commit with some comments (as suggested by jdstrand)
<zyga> when wife and kids don't go to school
<zyga> I'll review it shortly
<kalikiana> moin moin
<pstolowski> mornings!
<mborzecki> kalikiana: pstolowski: morning
<zyga> hey kalikiana
<jamesh> zyga: re. the safe bind mount branch, I had some new thoughts about simplifying it but am not sure of the security concerns
<jamesh> zyga: what if we did a bind mount from /proc/self/fd/$source_fd to /proc/self/fd/$target_fd?
<jamesh> it'd avoid the need for the stash directory, and it ensures the source and destination are anchored at the expected locations
<zyga> jamesh: hmm, that's interesting
<zyga> did you try it?
<jamesh> giving it a go.
<zyga> jamesh: that's pretty interesting I must say
<zyga> would be awesome if it works
<jamesh> it'd also handle bind mounting files
<jamesh> since there's no more fchdir()
<zyga> yes, iff this works it's pretty interesting
<zyga> I wonder what happens to /proc/pid/fd in this scenario
<zyga> open a directory with O_DIRECTORY (and with or without O_PATH)
<zyga> inspect the fd in /proc
<zyga> mv the directory around, replace with symlink or whatever
<zyga> inspect the fd in proc
<zyga> jamesh: I also found /proc/pid/root as useful thing but kernel folks broke it because OMG security :/
<zyga> jamesh: it would allow mounting from one ns to another
<zyga> (it did until it was changed)
<zyga> mborzecki: 4952 reviewed
<zyga> mborzecki: question: what do we need to do to remove nvidia as compile time option entirely, and make it fully dynamic
<mborzecki> zyga: imo we'd need to interpret data coming os-release, pick the right location based on known paths
<zyga> what kind of choices would we make? can you walk me through this please?
<jamesh> zyga: using a simple Python example, it mounted the expected directory after a move
<zyga> that's super promising!
<jamesh> so the mount followed the file descriptor rather than the name
<zyga> jdstrand: ^^ FYI, I think jamesh found the holy grail of mounting
<mborzecki> zyga: choosing the location where the libraries are, i.e /usr/lib/ & /usr/lib32 on arch, /usr/lib/<arch-tiplet> on debian/ubuntu, /lib64(?) on fedora (although i think this might be close to arch), historically some drivers would install under their /usr/{libdir}/nvidia{-maybe-suffix} path, that also varies from distro to distro and release to release
<jamesh> zyga: here's the test program I used: https://paste.ubuntu.com/p/zvpjCcmcjm/
<mborzecki> zyga: don't recall what suse does, it's probably close to fedora (or the reference layout of systemd distros)
<zyga> mborzecki: I see, thanks
<zyga> mborzecki: I'm weighting this against need for nvidia-xxx snap
<zyga> and the pros/cons
<jamesh> zyga: I tried extending it to do the read only remount, but that fails.  Presumably because dest_fd references the directory underneath the mount point rather than the mount point itself
<zyga> after the mount we can open another fd
<mborzecki> zyga: do you mind if i fix https://github.com/snapcore/snapd/pull/4952#discussion_r177972590 in master once we merge the release branch back?
<mup> PR #4952: [2.32] cmd/snap-confine: attempt to detect if multiarch host uses arch triplets <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4952>
<zyga> mborzecki: not at all
<mborzecki> ok, thx
<zyga> I'm looking at fedora failure now
<mborzecki> removable media?
<zyga> yes
<mborzecki> ok
<mborzecki> btw. just restarted the build on 4952 for the 2nd time now, first one failed fetching stuff from github/gopkg.in, now it failed fetching the snaps from store
<zyga> noise][, hey, is the store operational again?
<Caelum> zyga: the rpm build is doing a test even if I don't have a %check section, do you know how to not do that?
<zyga> what kind of test?
<Caelum> it's running: + /usr/lib/rpm/golang.sh test github.com/snapcore/snapd/...
<zyga> ah
<zyga> looks like something built into the rpm macro for golang itself
<mborzecki> Caelum: maybe it's golang rpm stuff?
<Caelum> yeah
<zyga> no, no idea how to turn it off, you'd have to look at expansion of the macro
<Caelum> ok thanks!
<zyga> one question
<zyga> what's the original macro in the spec file?
 * zyga is rusty on that
<zyga> Caelum: are you sure it's %gobuild that is doing that
<zyga> I see %gotest in %check
<Caelum> I commented it out and it still happens
<Caelum> that's the thing I don't get
<Caelum> oh I figured it out, I need a %check section with some command
<zyga> hmmm
<zyga> well, not sure
<zyga> maybe ask in #opensuse-buildservice, people there may be able to help more than I can
<zyga> I tried to expand %gobuild with 'rpm -E' but it didn't expand
<zyga> mborzecki: question about /media vs /run/media
<zyga> it fails becasue snap-confine on fedora bind mounts /run/media
<zyga> now my idea is as follows
<zyga> inside snap execution environment we could make /media == /run/media
<zyga> so
<zyga> snap authors will have easier way to reason about how things work
<mborzecki> zyga: sounds good
<mborzecki> zyga: will both locations be avaialble?
<zyga> yes
<mborzecki> zyga: ok
<zyga> yeah, I think this is easier than hacking the test
<zyga> which should not depend on the host
<mborzecki> right
<mborzecki> media-sharing test will need an update then
<zyga> no, actually it should work just the same
<zyga> my point is that host's native $MEDIA_DIR just becomes both /media and /run/media inside the execution environment
<zyga> in core18 we could perhaps make /media as symlink into /run/media
<mborzecki> zyga: yes, but the test tries to figure out what host it's running on and chooses /media or /run/media, if we make those equivalent, it would make sense to update the test to either always look in /media or compare both locations (maybe the latter)
<zyga> it does so on the outside
<zyga> that's all fine
<zyga> we'll only make things equivalent on the inside
<mup> PR snapd#4931 closed: configstate: give a chance to immediately recompute the next refresh time when schedules are set <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4931>
<zyga> hmm
<zyga> though there may be one complication
<zyga> ah, no
<mup> PR snapd#4953 opened: configstate: give a chance to immediately recompute the next refresh time when schedules are set (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4953>
<pedronis> zyga: does #4932 needs again a master merge or a rerun ?
<mup> PR #4932: interfaces/content: add rule so slot can access writable files at plug's mountpoint <Created by gerboland> <https://github.com/snapcore/snapd/pull/4932>
<zyga> pedronis: I think master is broken again, let me look
<zyga> (I'm fixing master now)
<zyga> yes
<zyga> econnreset is fixed in one PR
<zyga> and removable media is in progress
<zyga> so don't rerun things for now please
<mup> PR snapd#4954 opened: store: Sections and WriteCatalogs need to strictly send device auth only if the device has a custom store (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4954>
<pedronis> ok
<Caelum> zyga: so I can run %gobuild userd but I have no idea what to do with it afterwards, it doesn't get installed anywhere, do you know?
<zyga> %foo is a RPM macro
<Caelum> yeah
<Caelum> well it does a go install
<zyga> it can be expanded with rpm -E '%foo'
<zyga> it installs into $GOPATH/
<zyga> but I don't know what the macros do nowadays, they changed recently
<Caelum> there is a userd and userd.a
<zyga> .a is an archive
<Caelum> yeah
<Caelum> but what do I do with userd, where do I put it
<zyga> mborzecki: look at  https://github.com/snapcore/snapd/pull/4955 please
<mup> PR #4955: cmd/snap-confine: establish equivalence of /{,run/}media <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4955>
<mup> PR snapd#4955 opened: cmd/snap-confine: establish equivalence of /{,run/}media <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4955>
<zyga> Caelum: hmmm, hold on, what is userd?
<zyga> pedronis: ^ this PR should fix master
<zyga> but it cannot land alone because of econnreset bug with store being wonky
<Caelum> there's a directory in git called userd, I was guessing this is the userd daemon you wanted me to add
<zyga> no no, that's not what I meant
<zyga> the userd is part of the "snap" binary
<zyga> you want to package the systemd / dbus service files
<zyga> that's why I hinted at missing files compared to the debian package
<zyga> another point of refence is the fedora package
<zyga> you can compare the list of files there
<zyga> lastly we have packaging for opensuse in packaging/opensuse-42.3
<zyga> (inside the git tree)
<zyga> that last packaging is what we run tests agains
<Caelum> oh I see
<zyga> you can use that as another reference, ideally they would be identical
<zyga> (though sometimes it is not easy as test builds have some extra requirements)
<zyga> but have a look at those all and see what they do differnetly
<zyga> *differnetly
<Caelum> ok I know what to do now
<zyga> let me know if you get stuck on anything
<zyga> thank you :-)
<zyga> I'm running a run of fedora 27 on linode now, let's see if my fix is sufficient
<pedronis> zyga: you are aware that    one of the tests is now skipped on fedora?
<pedronis> if it's about that you need to unskip it
<zyga> pedronis: no, I wasn't
<zyga> which test was that?
<pedronis> zyga:  https://github.com/snapcore/snapd/commit/0848363411c07c47580a6d64594911b3a5511595
<zyga> thanks
<zyga> tests passed (before re-enabling)
<zyga> all of main passed
<zyga> running that single test after re-enabling it now
<pstolowski> zyga: do you have a moment for quick HO? i'd like to talk about udev
<zyga> yes
<zyga> sure, I'll join the standup HO
<zyga> pstolowski: ready
<zyga> you are missing a show with my daughter who tries her best to annoy me today
<Caelum> zyga: currently snapd-generator is installed to /usr/lib/snapd/snapd-generator but should it be installed to /usr/lib/systemd/system-generators/snapd-generator instead?
<Caelum> or is that a unit file?
<zyga> Caelum: one sec, on a cal
<zyga> call
<Caelum> yeah it looks like that's what I need to do
<zyga> yes
<zyga> it should be where systemd looks for generators
<zyga> pstolowski: a bit old but perhaps still relevant https://people.redhat.com/nhorman/papers/netlink.pdf
<zyga> pstolowski: question
<zyga> pstolowski: have we closed the previous socket correctly
<zyga> it _feels_ like we did not
<pstolowski> zyga: yes, I close the socket
<pstolowski> zyga: ok, the doc you linked seems to be pretty clear about setting pid to own pid
<mup> PR snapd#4947 closed: spread: disable StartLimitInterval option on opensuse-42.3 <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4947>
<mup> PR snapcraft#2042 opened: Vendoring lxd <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2042>
<zyga> pstolowski: https://tools.ietf.org/html/rfc3549 is also interesting
<Caelum> zyga: I have all the missing files now, except for the userd unit file, where do I get that? It's not in ubuntu.
<zyga> Caelum: it should be made by "make install" in data/
<zyga> let me look
<zyga> look at data/dbus
<zyga> if you make install -C data DESTDIR=... you should get something useful out
<zyga> those are the two io.snapcraft.* things there
<Caelum> the dbus services? I got those.
<zyga> so which file is missing still?
<Caelum> I didn't know that's what the userd service was
<zyga> ah
<zyga> yeah
<zyga> that's it
<zyga> commit and I'll build and try it out :)
<zyga> mborzecki: thinking about media
<zyga> I think I will only do one thing
<zyga> on /run/media systems /media will be a fixed alias
<zyga> on /media systems /run/media will not
<zyga> because host /run is shared and there's no guarantee that /run/media exists
<zyga> and we should not attempt to create it just because you are using snaps
<zyga> (especially that on the outside /run/media woul be empty)
<zyga> we can rely on /media in ways we cannot rely on /run/media
<zyga> what do you think?
<mborzecki> hm, so basically, no /run/media if there was none on the host?
<zyga> yes
<zyga> I pushed the branch over, have a look
<zyga> jamesh: hey, if still there, so do you plan to use the /proc/pid/fd idea?
<zyga> jamesh: I can discuss this with jdstrand and jjohansen today
<zyga> I actually totally love it
<jamesh> zyga: yes.  I'm integrating it into my branch and updating tests
<jamesh> zyga: I added a note about it to the PR too
<zyga> sweet, thank you!
<Caelum> zyga: I figured out my problem with tests, you can't comment out rpm macros with # they still get expanded and run
<zyga> ah :D
<zyga> yes
<zyga> I ran into that too, I recall now
<zyga> what's the issue with the tests?
<zyga> are they failing because of DNS?
<Caelum> no they're fine, I was just trying to disable them while testing builds because they take a really really long time
<zyga> ah
<zyga> ok
<Caelum> but there is one test there that randomly fails like 30% of the time
<Caelum> when I see it again I'll let you know
<mborzecki> zyga: i'll rebase the PR with plain make thing
<zyga> mborzecki: thanks
<zyga> mborzecki: I had a look already
<zyga> but not in detail
<mborzecki> zyga: aand force pushed
<zyga> thanks
<zyga> I want to unbreak master and then work on my stuff
<zyga> but I promise to build and test your PR today
<zyga> pedronis: we need a 2nd review on https://github.com/snapcore/snapd/pull/4955
<mup> PR #4955: cmd/snap-confine: make /run/media an alias of /media <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4955>
<zyga> please merge if you agree
<pedronis> it needs a review by jamie, no?
<zyga> pedronis: hmmm, yes, it should get one
<zyga> I'll wait for his review to merge
<mborzecki> zyga: shall we land https://github.com/snapcore/snapd/pull/4952 ?
<mup> PR #4952: cmd/snap-confine: attempt to detect if multiarch host uses arch triplets (2.32) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4952>
<cachio> hey zyga
<zyga> hey
<cachio> zyga, beta is it gonna change?
<cachio> or I can promote it?
<zyga> cachio: I think it's fine to promote
<zyga> cachio: we will do .2 but that's unscheduled still
<zyga> to candidate?
<cachio> yes
<cachio> to candidate
<Caelum> zyga: well I updated the package, having laptop overheating issues here on linux
<zyga> Caelum: ouch, sorry to hear that
<zyga> I will pull and test
<zyga> mborzecki, morphis: does anyone want to do a 2nd review on opensuse package refresh?
<mborzecki> zyga: i can take a look
<mborzecki> obs link?
<zyga> https://build.opensuse.org/request/show/592282
<zyga> I'm building locally now
<zyga> cachio: +1 from me
<mborzecki> heh reddit witch hunt https://www.reddit.com/r/linux/comments/87ssdw/why_i_use_flatpak_for_3rd_party_apps/
<zyga> Caelum: the userd service works fine now
<zyga> I'll reboot my suse box and play some more
<zyga> Caelum: installation of snaps without sudo also works now
<zyga> I will try a few more snaps now
<zyga> Caelum: 42.2 build fails
<zyga> I think you can hardcode the systemd generator location
<zyga> [  176s]     File must begin with "/": %{_systemdgeneratordir}/snapd-generator
<wadadli> Hi there, attempting to install.  Here's the error that I am getting: error: cannot install "anbox-installer": classic confinement requires snaps under /snap or symlink from /snap to /var/lib/snapd/snap
<zyga> wadadli: hey
<zyga> wadadli: some distributions chose not to ship the /snap directory and on such distributions snaps that are using classic confinement cannot function
<zyga> you can make a symlink from /snap to /var/lib/snapd/snap to fix this issue on your machine
<leftyfb> wadadli: what version of ubuntu are you running?
<wadadli> Fedora
<leftyfb> :/
<zyga> leftyfb: that's expected and supported
<zyga> wadadli: just make that symlink and you will be fine
<leftyfb> zyga: yeah, but they originally asked for help in #ubuntu
<wadadli> no luck despite running ln -s /var/lib/snapd/snap /snap
<zyga> wadadli: note that anbox is not the full snap, just the installer
<zyga> wadadli: what are you getting now?
<mborzecki> w8, doesn't anbox require kernel modules too?
<wadadli> same here.
<wadadli> same thing**
<mborzecki> (not to install, but to run)
<zyga> mborzecki: I don't remember, I think so
<mup> PR snapd#4952 closed: cmd/snap-confine: attempt to detect if multiarch host uses arch triplets (2.32) <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4952>
<zyga> wadadli: same as in?
<wadadli> cannot install "anbox-installer": classic confinement requires snaps under /snap or symlink from /snap to /var/lib/snapd/snap
<jamesh> zyga: I've pushed the changes to remove the stash dir to https://github.com/snapcore/snapd/pull/4868 now
<mup> PR #4868: cmd/snap-update-ns: add secure bind mount implementation for use with user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4868>
<mborzecki> wadadli: are you using gnome software to install anbox?
<wadadli> nope, anyways got the installer to install.
<wadadli> now the installer complains that Fedora isn't supported.
<zyga> wadadli: that's what I expected
<zyga> wadadli: it requires some kernel modules AFAIR, morphis would know
<zyga> jamesh: thank you
<zyga> wadadli: the snap distributes just the installer, not the full application
<wadadli> Would have been fun just to try. :)
<wadadli> Any suggestions for running android apps on Linux?
<zyga> wadadli: sorry, not a clue
<zyga> maybe use ubuntu and anbox
<zyga> or talk to morphis about what would it take to work on fedora
<zyga> maybe the issue is just temporary
<zyga> Caelum: let me know if you run into any issues
<zyga> pedronis, mborzecki: trivial cleanup PR https://github.com/snapcore/snapd/pull/4956
<mup> PR #4956: cmd/snap-update-ns: rename i to segNum <Created by zyga> <https://github.com/snapcore/snapd/pull/4956>
<mup> PR snapd#4956 opened: cmd/snap-update-ns: rename i to segNum <Created by zyga> <https://github.com/snapcore/snapd/pull/4956>
<zyga> mborzecki: more thoughts on the media issue
<zyga> mborzecki: remove the config option
<zyga> mborzecki: if /run/media exists it is aliased as /media and bind mounted
<zyga> mborzecki: otherwise /media is just bind mounted to /media and that's it
<zyga> mborzecki: one less compile time choice
<zyga> mborzecki: the only other one would be nvidia
<zyga> mborzecki: WDYT?
<mborzecki> zyga: sounds good, but it's probably worth double checking that for instance debian does not have both /media and /run/media, each being a different thing :)
<zyga> yeah, I plan to check
<zyga> HMMM
<mborzecki> iirc this depends on how udisks2 was compiled
<zyga> fedora 27 doesn't have /run/media
<zyga> mborzecki: yes
<zyga> mborzecki: it's a bit insane and sad we have this difference
<zyga> opensuse tumbleweed has /run/media
<mborzecki> haha
<mborzecki> try installing udisks2 in fedora
<zyga> drat, /run/media is created dynamically
<zyga> when something is mounted
<zyga> well, that's this idea then
<zyga> sucks to be snapd
<mborzecki> heh ;)
<mborzecki> the year of linux desktop is upon us
<zyga> at least we don't need to support that weird distribution that had /Applications after macos
<mborzecki> we'd get /Snapd
<mborzecki> or /SnapD
<vidal72[m]> zyga: jdstrand : I fixed failing tests in https://github.com/snapcore/snapd/pull/4944 , hope it's ok now
<mup> PR #4944: interfaces: add /var/lib/snapd/snap to @{INSTALL_DIR} <Created by Erick555> <https://github.com/snapcore/snapd/pull/4944>
<zyga> vidal72[m]: thank you
<zyga> vidal72[m]: we will look at merging it when master is fixed
<vidal72[m]> zyga: ok
<vidal72[m]> I had also fix /media on Arch https://github.com/snapcore/snapd/commit/0d69cb8015e0c42037a7cf9b27f87856e05c0a23#diff-798ce6f0668878eda67847b4ab492745R144
<pstolowski> niemeyer: i may be a few minutes late to the standup
<niemeyer> Heya
<niemeyer> I will be late as well, as there's a conflicting meeting
<zyga> hey
<zyga> niemeyer: ack
<zyga> vidal72[m]: oh, interesting, looking
<zyga> ah, right
<zyga> vidal72[m]: thanks, that's a seprarate issue and I hope we can merge that soon
<mup> PR snapd#4953 closed: configstate: give a chance to immediately recompute the next refresh time when schedules are set (2.32) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4953>
<zyga> ah, it's merged already
<vidal72[m]> zyga: yeah
<vidal72[m]> Arch handling of media is the same as fedora
<vidal72[m]>  /run/media is created dynamically
<jdstrand> jamesh, zyga: it is an interesting idea, but I think it is still racy. eg, if I have /proc/self/fd/5 -> /tmp/foo, and I do from outside the process 'mv /tmp/foo /tmp/bar', then /proc/self/fd/5 -> /tmp/bar. this means that when you open /tmp/foo, you can race mount for when it resolves the fd symlink
<zyga> jdstrand: we did that test
<zyga> the fd follows
<zyga> well
<zyga> we may still see the race
<zyga> I see your point
<zyga> jdstrand: I agree in the sense that mount the syscall may still race
<zyga> and our simple look from the ouside may be insufficient to observe that
<jdstrand> zyga: feel free to try to prove me wrong, but mount() doesn't take open fds. it takes paths. therefore, at the time the mount() call is made, the symlink could point to something else. I would be surprised if the kernel kept the context for your symlink around
<jdstrand> zyga: ie, I doubt that: fd = open(/tmp/foo), then from outside move /tmp/foo /tmp/bar, then mount(/proc/self/fd/<the fd>, ...) that mount() will see /tmp/foo
<jdstrand> it would be easy to test with some strategic sleep() calls
<zyga>  James Henstridge so the mount followed the file descriptor rather than the name
<zyga> jdstrand: yep
<zyga> jamesh: ^
<jdstrand> if it did see that (and again, I doubt it does), I wouldn't trust that it is by design and we'd need to deeply investigate that we could trust it
<kalikiana> re
<zyga> jdstrand: hey, can you please have a quick look at https://github.com/snapcore/snapd/pull/4955
<mup> PR #4955: cmd/snap-confine: make /run/media an alias of /media <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4955>
<jamesh> jdstrand: /proc/$pid/fd/NNN paths aren't standard symlinks though: they'll even work across separate mount namespaces
<zyga> master is broken now and this is the fix
<zyga> niemeyer: we're done, we can repeat the standup if you want and you are back
<jamesh> jdstrand: opening that path (as opposed to doing readlink()) is directed to the inode of the file descriptor
<niemeyer> zyga: Ack, thanks
<niemeyer> zyga: Still going here
<jdstrand> jamesh: you are saying that when mount() opens that file, it opens the inode associated with said file descriptor?
<jamesh> jdstrand: I am not certain of what happens in the kernel
<jamesh> jdstrand: in the simple case of moving the directory between opening the fd and calling mount() though, it uses the new location
<jdstrand> right, so that is doing as I described. am I misunderstanding?
<zyga> I think that there's still raciness but it not measurable with this test
<zyga> the race is not between the rename and the mount
<zyga> well
<zyga> that's wrong
<zyga> the race is not in the rename, the sleep and them ount
<zyga> but with racing rename and mount
<zyga> the thing that I thin _is_ averted
<zyga> is symlink attack on the leaf
<zyga> jdstrand: that's how I understand what the kernel is doing
<jdstrand> if you can give me C code for what you want to do, I can blackbox the kernel. if it seems safe, then we can investigate if that is by design and can be relied upon
<zyga> jdstrand: does this qualify https://paste.ubuntu.com/p/zvpjCcmcjm/
<zyga> it's not C but as close as you probably want
<jamesh> I can put together a C example, but it'll have to wait until after the easter long weekend
<jamesh> it is late here in .au
<jdstrand> I guess python would be ok. this is going to be in the go code
<jdstrand> it'll be a bit before I can look at this
<zyga> I can make the C part if you want
<zyga> jdstrand: yeah, that's fine
<zyga> jdstrand, jamesh: we can use the old approach for now
 * jdstrand is also busy :)
<zyga> and explore this as v2
<jdstrand> right
<jdstrand> we have an approved approach
<jdstrand> if this works and can be relied upon, then it would be cool
<jamesh> zyga, jdstrand: I updated the PR to use this new approach, but that's just in the top revision
<zyga> yep
<jamesh> uncommitting that has the two step version you reviewed previously
<zyga> jamesh: can you open a 2nd pr with that commit
<zyga> and force push the old one to the original
<jamesh> sure.
<zyga> we can have two converstations separately then
<zyga> thank you!
<mup> PR snapd#4954 closed: store: Sections and WriteCatalogs need to strictly send device auth only if the device has a custom store (2.32) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4954>
<jamesh> zyga: here's the version with the last commit: https://github.com/snapcore/snapd/pull/4957
<mup> PR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957>
<mup> PR snapd#4957 opened: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957>
<zyga> ack
<jamesh> and the old PR has been rewound
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/4958 (rather long but mechanical)
<mup> PR #4958: cmd/snap-update-ns: allow path guardian to inspect fs ops <Created by zyga> <https://github.com/snapcore/snapd/pull/4958>
<mup> PR snapd#4958 opened: cmd/snap-update-ns: allow path guardian to inspect fs ops <Created by zyga> <https://github.com/snapcore/snapd/pull/4958>
<zyga> this doesn't do anything at all, just gives us an argument in the right spot, so that we can avoid the global hack I did
 * zyga -> walk
<zyga> jamesh: What is the symlink path when you remove a file?
<niemeyer> zyga, pedronis, cachio, pstolowski: Do you want to have a quick call?
<cachio> niemeyer, sure
<zyga> Ups, Iâm on a walk
<pedronis> niemeyer: I'm available if quick
<niemeyer> Saviq: I won't be around tomorrow, and perhpas not next week either (will send an email in the latter case).. we have several backends in the code of spread itself, which should be very easy to read and follow.. would that be enough to give you an idea of what it needs?
<niemeyer> pedronis, cachio: Okay, let's jump in
<cachio> mborzecki, are you comming?
<Saviq> niemeyer: probably, we can get through that and let's sync up week after next?
<zyga> jdstrand: thank you, I replied on both comments
<zyga> jdstrand: I'll rename the variable but I think it's okay as-is, see my rationale please
<mup> PR snapd#4819 closed: interfaces/serial: change pattern not to exclude /dev/ttymxc* <Created by bergotorino> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4819>
<niemeyer> zyga: Can we please have this one in as well ^
<niemeyer> zyga: Trivial addition to the regexp pattern, so regression chance is pretty much nil
<zyga> niemeyer: ack
<niemeyer> zyga: and we have people on the line for that one
<zyga> I'll backport it
<niemeyer> Thanks
<niemeyer> !
<zyga> jdstrand: pushed
 * zyga gets dinner and then back to release
<niemeyer> Saviq: Yeah, happy to sync
<niemeyer> Saviq: We can have a call today as well if you want
<niemeyer> Saviq: That might be more productive
<Saviq> niemeyer: I'm EOD in an hour, and I think we can get the most important data out of the current spread providers, so we can re-sync after to see what's missing
<niemeyer> Saviq: Let's have a quick call now then
<niemeyer> Saviq: Are you available?
<niemeyer> Saviq: 5-10 minutes tops
<Saviq> niemeyer: just getting into our team sync, are you ok 15 mins from now? your calendar says busy?
<niemeyer> I'll be at lunch by then
<niemeyer> Either now, or 1h from now, or 9 days from now :)
<Saviq> niemeyer: ok, 1h from now then
<niemeyer> Saviq: Deal
<thiras> electrum package is unbelievably old and has SERIOUS security issues at the version
<thiras> for maintainers instance  it's not proper to have that on the market
<nacc> thiras: you should contact the 'Contact" link in the info?
<thiras> where can i find it?
<nacc> thiras: snap info electrum
<kyrofa> nacc, feel like confirming this bug? Another one that I think will help you https://bugs.launchpad.net/snapcraft/+bug/1759875
<mup> Bug #1759875: Parts should be handled in a consistent order through multiple runs <Snapcraft:New> <https://launchpad.net/bugs/1759875>
<nacc> kyrofa: yeah that looks reasonable and helpful for us
<thiras> also my atom has just stopped working
<thiras> without a reason
<thiras> no error log on console
<nacc> thiras: there is also a contact url for that
<mup> PR snapd#4959 opened: interfaces/serial: change pattern not to exclude /dev/ttymxc (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/4959>
<thiras> seriously... it should be universal and plugnplay
<thiras> i only got 3 snap packages and seen 4 critical error in one week
<nacc> thiras: what should be?
<thiras> something is very very wrong with snaps for sure
<mup> PR snapd#4959 closed: interfaces/serial: change pattern not to exclude /dev/ttymxc (2.32) <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4959>
<thiras> it's worse than apt
<mup> PR snapd#4960 opened:  interfaces/serial: change pattern not to exclude /dev/ttymxc (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/4960>
<zyga> thiras: hey
<zyga> thiras: can you please open your terminal
<zyga> thiras: and run: snap run atom
<zyga> thiras: please tell me what happens
<thiras> nothing
<thiras> return to bash
<thiras> instantly
<thiras> i got the same issue with skype. somehow it started work this weak
<thiras> week*
<zyga> can you please tell me your "snap version"
<thiras> snap    2.31.2
<thiras> snapd   2.31.2
<thiras> series  16
<thiras> ubuntu  17.10
<thiras> kernel  4.13.0-37-generic
<zyga> ok
<zyga> one sec, let me refresh my core snap
<thiras> why do we love debian based distros? because it's stable as earth
<roadmr> omg an earthquakeee
<thiras> if it's not ready you shouldn't push into production
<zyga> thiras: let's please focus on the issue at hand, we're all trying to make something better
<thiras> and as i can see it's clearly not ready
<zyga> roadmr: a real earthquake?
<thiras> ok
<zyga> thiras: so, both atom and skype are classic snaps
<thiras> 99.999999% of the time its stable roadmr
<roadmr> zyga: I'm joking re: debian is stable as earth :)
<zyga> so they cannot use many of the benefits of the system that make it more stble
<zyga> I'll switch to 3.31.2 and see if I can run them
<zyga> (I'm also on 17.10)
<zyga> thiras: is your atom and skype from stable channels?
<zyga> (snap info skype; snap info atom)
<thiras> yes i assume. directly downloaded from that "ubuntu software"
<zyga> thiras: I can reproduce this
<zyga> it looks like atom broke their snap
<zyga> popey: ^
<zyga> flexiondotorg: ^
<thiras> tracking:    stable
<thiras> installed:   1.25.0 (136) 144MB classic
<popey> zyga: broken how?
<zyga> writev(2, [{iov_base="/snap/atom/136/usr/share/atom/at"..., iov_len=34}, {iov_base=": ", iov_len=2}, {iov_base="error while loading shared libra"..., iov_len=36}, {iov_base=": ", iov_len=2}, {iov_base="libgconf-2.so.4", iov_len=15}, {iov_base=": ", iov_len=2}, {iov_base="cannot open shared object file", iov_len=30}, {iov_base=": ", iov_len=2}, {iov_base="No such file or directory", iov_len=25}, {iov_base="\n", iov_len=1}], 10) = 149
<zyga> atom cannot find libgconf-2.so.4
<zyga> trying skype now
<popey> wfm
<thiras> skype is working
<popey> zyga: i am on atom from edge, try that
<thiras> i don't know how but few days ago it started to work magically
<popey> (I added a dep)
<zyga> popey: can you try stable
<zyga> popey: if edge works that is gret
<popey> if edge works I'll promote it
<zyga> but if stable doesn't work, that's bad
<zyga> ok
<thiras> it was exactly like that snap run command returns nothing
<zyga> thiras: you can try that with "snap refresh --edge atom"
<zyga> this will let you test the more recent version
<thiras> FFS at least provide some error log at the output of run command
 * zyga tries as well
<thiras> it was like nightmare when i try to debug
<zyga> thiras: I'm not sure why the log didn't come out TBH
<zyga> normally it would show something
<zyga> thiras: tip: snap run --strace atom
<zyga> :-)
<zyga> popey: no, edge is equally broken
<thiras> still same zyga
<popey> wat
<zyga> I noticed new gnome runtime platform
<zyga> maybe that's a factor
<popey> I'm on 16.04 and it works fine here
<popey> it's a classic snap
<zyga> popey: on 17.10 it is broken
<popey> (I am on KDE)
<popey> how is that the snaps fault?
<zyga> popey: nothing ships libgconf-2.so.4
<zyga> popey: the snap must ship libgconf-2.so.4
<zyga> it's a broken snap that runs on 16.04 by acciddent
<zyga> *accident
<popey> alan@KinkPad-K450:/snap/atom/current$ find . | grep  libgconf-2.so.4
<popey> ./usr/lib/x86_64-linux-gnu/libgconf-2.so.4
<popey> it does ship it
<popey> (in edge)
<zyga> popey: perhaps it's not setting some flags to load it
<zyga> pstolowski: ^ can you run snap run atom
<zyga> pstolowski: and tell me which ubuntu release you are on
<pstolowski> zyga: sure, 1 sec
<zyga> popey: I confirm that the snap ships the so file
<zyga> pstolowski: thank you
<zyga> popey: but it still doesn't start
<zyga> because it cannot load that lib
<zyga> popey: looking at the command it doesn't set any environment
<zyga> popey: please adjust it to set LD_LIBRARY_PATH  based on $SNAP
<thiras> by the way contact address of electrum is not working
<zyga> popey: snap run --shell atom
<popey> why should I have to do that? Surely snapd should set that correctly?
<zyga> popey: no
<zyga> popey: snapd _never_ did that
<thiras> dude seriously do you allow everybody to craft those non working package and put it into ubuntu software?
<thiras> it's a nightmare
<pstolowski> zyga: works here. i'm on 16.04
<zyga> thiras: please calm down, we're doing our best, there are 100s of working snaps
<zyga> pstolowski: on 16.04 it would work by accident, thank you for checking
<zyga> popey: all classic snaps must alter their environment knowingly
<flexiondotorg> zyga: o/
<zyga> please review the snaps we publish for this
<thiras> if it's open to eveybody we have much much much more serious security issues than simple broken packages
<popey> flexiondotorg: zyga is reporting atom broken in 17.10 - even edge which has the extra libgconf
<zyga> flexiondotorg: tl;dr; atom doesn't set LD_LIBRARY_PATH, doesn't start on many distributioins
<zyga> *distributions
<zyga> the reason for that is on 16.04 it finds and loads host's libgconf
<pedronis> did snapcraft switch to elf patching instead of LD_LIBRARY_PATH ?
<popey> flexiondotorg: we use a very basic launcher in atom (classic remember)
<zyga> as a classic snap it runs without a mount namespace
<zyga> pedronis: great question
<nacc> pedronis: i believe 2.40 does that
<flexiondotorg> zyga: I was advised by sergio to drop desktop helpers and LD_LIBRARY_PATH munging when build classic snaps with snapcraft 2.39 and newer, since snapcraft should DTRT.
<kyrofa> pedronis, yes
<flexiondotorg> popey: Atom is build built by build.snapcraft.io, right?
<popey> yes
<flexiondotorg> So will be using snapcraft 2.35.
<zyga> flexiondotorg: I see that we set rpath to $ORIGIN:$ORIGIN/lib
<kyrofa> pedronis, but classic snaps haven't had LD_LIBRARY_PATH automatically set for a while
<flexiondotorg> It will require a local cleanbuild using snapcraft 2.40.
<zyga> flexiondotorg: but not $ORIGIN/lib/x86_64-linux-gnu/
<zyga> that's why it's not starting
<nacc> flexiondotorg: why does b.s.io use 2.35?
<zyga> popey, flexiondotorg: please disregard my comments about LD_LIBRARY_PATH, it's really snapcraft ORIGIN that needs the tweak
<flexiondotorg> Because b.s.io use LP and LP get snapcraft via apt.
<zyga> it's really broken because of multiarch path for libraries
<cjwatson> (currently)
<popey> cjwatson: that's changing soon. right?
<zyga> thiras: sorry for the noise, the issue is understood now, I'm sure the team will publish a working atom snap shortly
<cjwatson> t
<kyrofa> 2.40 was SRUd, build.snapcraft.io should be using it now, no?
<nacc> flexiondotorg: snapcraft is at 2.40 in all releases?
<cjwatson> oh, yes, it would be 2.40 now
<nacc> flexiondotorg: so it would depend on *when* it built
<popey> I can certainly trigger a new edge build of atom
<cjwatson> 2.39 was rolled back but 2.40 seems to have stuck for now
<cjwatson>  snapcraft | 2.40         | xenial-updates/universe  | source, all
<flexiondotorg> Yep, seem it was built before the SRU completed.
<popey> latest build in edge was 2018-03-24 23:27 - 4 days, 16 hours ago
<nacc> yeah, that is something I have meant to ask folks here
<nacc> snapcraft chnages can really change how the snap works
<nacc> (sometimes breaking it :)
<nacc> i wonder if there needs to be abetter connection between snapcraft updates (that affect b.s.io/LP) and snap builds
<nacc> as without changing your snap, all of a sudden your snap might change
<nacc> debugging it can be a pain (hat-tip to kyrofa )
<popey> I've just pressed the "build now" button so look for a new edge build of atom shortly
<cjwatson> nacc: the work in progress includes being able to control the channel used for snapcraft on a per-snap (even per-build) basis, which we plan to use to construct better QA
<popey> (I wish I could tell build not to do an armhf/i386 build)
<nacc> cjwatson: ah nice
<nacc> cjwatson: oh right and you're switching to the snapcraft snap, right?
<cjwatson> popey: waiting for the architectures work to land in snapcraft ...
<popey> ok
<cjwatson> nacc: that's the plan, though of course there'll be a transitional period
 * popey looks at kyrofa :)
<nacc> cjwatson: yep
<kyrofa> Ah, right, speaking of that: niemeyer any chance you have some time to day to meet before you leave?
<thiras> zyga, let me ask something
<thiras> is snap repos are open to everybody?
<thiras> if so please leave that package alone and start restate security policy
<thiras> it's one click away for everybody who use ubuntu
<zyga> thiras: what do you mean by repos?
<zyga> thiras: the snap storeis open to everyone, yes, but snaps without confinement require a public vote to approve
<thiras> i don't know snap equivalent of repository
<zyga> thiras: normally all snaps are confined
<zyga> thiras: go ahead, make a snap, have it do something and push it to the store (or just install locally to test)
<zyga> and see what happens if you try to attack the host
<popey> cjwatson: is it normall that a huge number of builders are "cleaning"?
<popey> (I was just looking to see what the queue for builders was like, and it looked odd)
<thiras> zyga, sometimes you don't have to attack
<cjwatson> popey: no, stabbing now
<popey> ta
<thiras> outdated software can become the problem itself
<thiras> like in electrum
<ogra_> they are oreparing for easter ... showering, brushing their teeth etc
<zyga> thiras: do you mean electron?
<nacc> zyga: no there's an electrum app (bitcoin related)
<zyga> thomi: snaps can be updated more frequently than distribution packages
<thiras> if you cannot guaranteed freshness of packages then the system has major security issue
<zyga> ah, I see
<nacc> thiras: this is no different than outdated debs
<thiras> electrum bitcoin client
<nacc> thiras: but it does take someone to actually do the work, in this case the contact info link
<thiras> the domain is dead
<thiras> debs can be outdated too of course
<thiras> but it's guaranteed by the canonical and/or the team to get fixed 99% chance
<thiras> at least you have somebody you can talk
<thiras> that's why we have official repos and ppa's
<thiras> sorry guys but complete disaster
<popey> ppa's are mostly very unofficial
<thiras> yeah thats what i mean
<popey> they're somewhat wild-west compared to the repo
<thiras> offical repos and pps they are completey diffrent
<nacc> thiras: you mean *main* ?
<nacc> thiras: so you should only use canonical snaps :)
<thiras> and you cannot access ppa's by mistake
<pedronis> IÂ think we will grow some policy about decayed snaps (not updated in along while) but we haven't discussed it yet (likely default snap find will not find them)
<thiras> nacc, i can guaranteed 99% of the people won't notice the maintainer of tthe package you if put all of them into one place
<thiras> FFS
<thiras> i'm using linux since 2.4 kernel
<nacc> thiras: i can't parse that sentence
<thiras> even I didn't notice it's not official snapcraft package
<nacc> what do you mean by official?
<thiras> you guys just remove the barrier between offical repos and ppa's
<thiras> do you understand that sentence?
<ogra_> well, the snap store is neither of them
<popey> We spend a lot of time talking to upstream developers, to get them to "own" their own snap.
<popey> So you can have confidence that the snap came from the real ISV
<thiras> and the barrier has a purpose
<popey> e.g. slack, skype, spotify, firefox all come from their respective 'vendors'
<ogra_> the snap store is typically "unrelated upstream packages"
<popey> but sometimes that conversation doesn't pan out, such as with Atom.
<thiras> so goodbye stable OS
<ogra_> ??
<popey> So we published it, because there's a demand for it. We publish the snap from upstream packages.
<ogra_> its exactly the opposite
<ogra_> this is why snaps exist
<ogra_> they are completely separate from the OS
<popey> the snaps are isolated form the host OS, making it _more_ stable
<thiras> yeah they said it for KVM too
<thiras> and meltdown
<popey> cjwatson: thanks!
<cjwatson> yep, build queue is ~drained now
<thiras> ok let me understand again. i just downloaded electrum bitcoin client with very very few click from ubuntu software
<thiras> it wasn't maintained by the original developer but just a random guy
<thiras> and i've imported my old wallet into that outdated client
<thiras> can you provide guarantee that my wallet didn't stolen?
<popey> zyga: can you please refresh atom from edge?
<popey> revision 141 just finished building
<ogra_> thiras, ask the maintainer ...
<popey> thiras: the repo version could have done the same. repo debs don't get deep code reviews.
<thiras> sure
<thiras> but it guaranteed original source code
<cjwatson> that electrum snap should probably just be removed - it manages to be older than the version in Debian jessie, which is kind of moderately hilarious
<thresh> so I've filled a forum thread on my issue with snapcraft stage packages, https://forum.snapcraft.io/t/snapcraft-stage-packages-inconsistent-behaviour/4746
<thresh> (also hello)
<ogra_> thiras, we can guarantee that nothing from that snap can take over your host and can not steal any data from it ... we can not gurantee anything for the content *inside* the snap, that is the responsibility of the maintainer
<popey> thresh: hi
<thiras> great
<thiras> really great
<nacc> cjwatson: heh
<cjwatson> unless there's some kind of fork in the version numbering I suppose
<thiras> you guys are crazy really i'll just close down snapd and never use it again
<nacc> thiras: that is obviously your choice
<popey> ok then
<roadmr> +1
<thresh> hey popey I've got some poorly drawn banners for you
<thiras> https://postimg.org/image/60fvg33y3/
<popey> yay!
<thiras> default size of ubuntu software
<popey> thresh: scroll down
<popey> oops, thiras scroll down
<thiras> again 99% of the users won't notice it's not from developer it's NOT guaranteed distributed source code from devs
<popey> thresh: sorry :)
<popey> thiras: you could file a bug against gnome-software? To highlight this problem with the developers who maintain that UI?
<cjwatson> the packaging metadata for electrum was added upstream (https://github.com/spesmilo/electrum/pull/2521)
<mup> PR spesmilo/electrum#2521: Add the packaging metadata to build the electrum snap <Created by elopio> <Merged by ecdsa> <https://github.com/spesmilo/electrum/pull/2521>
<cjwatson> not sure what happened to it after that
<thiras> do you have verification process of the maintainers like twitter verification? how can i know if it's really firefox foundation?
<cjwatson> sounds like upstream merged the PR but then didn't want to deal with actually maintaining the build
<ogra_> or simply wasnt able to take over the name in the store
<thiras> does bash client warns the users if package owner not verifed?
<thiras> i bet it's not
<cjwatson> ogra_: see the URL I posted
<ogra_> cjwatson, ah, right ...
<zyga> thiras: what doe you mean by verified?
<niemeyer> kyrofa: Yeah, let's talk
<thiras> sorry guys but i see only fast and definatly not very well thought moniterization of package distribution.
<niemeyer> Saviq: Ready?
<ogra_> well, someone should probably talk to https://forum.snapcraft.io/u/tomascw to either get the snap updated,, removed or ransferred to someone who wants to actively maintain it
<popey> zyga: please update your atom :)
<zyga> popey: snapd does that for me :)
<zyga> but let's try
<popey> eye roll emoji
<thiras> i was very excited when saw snaps first
<zyga> thiras: to be fair
<zyga> thiras: it's all new and exciting and complex
<zyga> thiras: we really get your feedback
<zyga> thiras: the best way to complain about things is to report issues, discuss issues and help fixing them
<thiras> obviously you are not the guys who decide because it's not a software bug or something
<zyga> popey: atom runs now!
<thiras> it's huge policy issue
<popey> \o/
<ogra_> thiras, you can contact the maintainer via https://forum.snapcraft.io/u/tomascw obviously ...
<zyga> thiras: but notice what just happend
<zyga> thiras: you just showed us how atom was broken
<zyga> and it was fixed in _minutes_
<zyga> that's impossible in classic packaging
<thiras> i should talk someone from canonical not you
<zyga> and it was not just fixed for ubuntu
<zyga> it's for everyone
<popey> zyga: thanks, released
<popey> flexiondotorg: ^ atom fixed
<zyga> thiras: I hate to tell you that bit I'm working on snapd as my day job
<popey> thiras: everyone you have been talking to so far works for canonical
<thiras> oh great
<zyga> thiras: run "snap refresh atom"
<zyga> thiras: and enjoy :)
<ogra_> thiras, how would talking to canonical help ... the snap is outdated, the guy who owns it didnt update it
<thiras> i cannot
 * zyga hugs popey and flexiondotorg 
<ogra_> talking to that guy wuld be way more effective, dont you think ?
<thiras> because i don't know who is maintaining that package
<zyga> thankys guys
<ogra_> thiras, https://forum.snapcraft.io/u/tomascw
<thiras> i could install wrong package who read my keystrokes
<popey> zyga: thanks for the ping
<thiras> which
 * popey goes back to vacation ;)
<thiras> -
<ogra_> thiras, no. you cant
<flexiondotorg> zyga: np :-)
<thiras> tell me how
<thiras> that was my first question anyway
<zyga> popey, flexiondotorg: is there a bug to report on snapcraft about the ORIGIN and multi-arch dirs?
<thiras> i confirm atom has fixed
<thiras> last word. it's quite dangerous to have 3rd party maintainers packages on the store WITHOUT ANY WARNING
<thiras> i just download electrum from mr nobody
<thiras> it's much easier to access than PPA's
<thiras> it's quite dangerous for avarage user
<zyga> thiras: I think what the real issue is, is that no equivalent of "snap info package" for accounts
<thiras> good day
<zyga> so that people can inspect the maintainer
<thiras> so until have that system
<flexiondotorg> zyga: Best ask kyrofa about that.
<thiras> you shouldn't put this thing into production
<thiras> simple debian approach
<zyga> flexiondotorg: ack, will do
<zyga> kyrofa: if you are around, do you have a moment to chat about ORIGIN
<zyga> thiras: there's never a good way to put something into production, IMO we are doing fine and improving rapidly
<cjwatson> FWIW I've heard exactly the same criticisms levelled at .debs from Debian - plus Ã§a change, plus c'est la mÃªme chose
<thiras> zyga, we have
<thiras> called apt
<thiras> it worked for millions of years
<thiras> since dinosours
<nacc> thiras: lol, you're being ridiculous now ... stick to facts please
<zyga> thiras: we know, we have some people who wrote it on the snapd team
<thiras> the tech is great
<nacc> thiras: also, there have been and will be broken debs too
<thiras> logic is perfect
<nacc> thiras: it still involves humans, so no it's not.
<thiras> but until we don't have warnings about the 3rd party devs it ruins everything
<nacc> thiras: which is the same problem you have with snaps
<thiras> we have*
<cjwatson> .debs have no warnings about third-party developers
<thiras> it's signed by canonical
<thiras> right?
<cjwatson> which doesn't mean every line of code has been inspected by Canonical
<zyga> thiras: debs are not signed
<thiras> yes of course
<zyga> thiras: archives are signed
<cjwatson> zyga: semantics
<thiras> ok can i put some snap packages into store
<nacc> thiras: canonical is vouching that the file you download is what you intended to
<nacc> thiras: that does not mean canonical has reviewd the content of every line of every source of every package
<thiras> but please keep it private so maybe you will understand with example
<thiras> yeah
<thiras> but
<nacc> thiras: snaps are no different
<thiras> but
<thiras> but
<thiras> official repos doens't have EVERYTHING
<thiras> usually
<thiras> it has well tested
<cjwatson> the majority of .debs in the Ubuntu archive come from source packages synced unmodified from Debian; it's certainly a higher barrier to entry than snaps, but you're putting them on a pedestal that's ... interesting
<thiras> proven packages
<nacc> thiras: lol
<cjwatson> also, please could you stop using the enter key as punctuation, it's quite annoying :)
<nacc> thiras: you clearly don't look at actual code quality metrics, or what is being tested in the archive (or the state of debian's CI)
<thiras> that's why we have ppa
<thiras> i have bitcoin client
<thiras> can i put it as deb package into offical repos?
<thiras> fully compromised will you accept it?
<cjwatson> if you'd gone to the effort of becoming a developer first, then yes; like I say, higher barrier to entry but it's certainly no guarantee of authenticity, and 
<nacc> thiras: no, and neither would the snap store
<thiras> thank you
<cjwatson> no doubt you would have to be at least a little bit subtle about it
<thiras> nacc, how so
<cjwatson> but we should not delude ourselves that it is impossible
<thiras> voting system?
<nacc> thiras: snaps get reviewed, iirc
<nacc> *new snaps
<thiras> there is nothing impossible cjwatson i agreee
<thiras> but we still use locks on our doors
<cjwatson> the review for new packages in the Ubuntu archive doesn't include a technical cryptographic review of bitcoin protocol nonsense or whatever
<nacc> heh
<zyga> I figured out a nice way to find classic snaps that depend on host libs at runtime
<zyga> I will implement that tomorrow
<nacc> zyga: nice!
<nacc> that would be helpful too
<thiras> do you have plans to have that accounts info thingy?
<thiras> like you said in snap info xxx
<zyga> I found some more
<zyga> thiras: I think it is sensible, pedronis would know if the store proviees enough meta-data today
<thiras> i would close down the store until have that IMO. quite critical.
 * kalikiana wrapping up for the week
<thiras> i hope see it live soon
<zyga> flexiondotorg, popey: run atom on your machines
<zyga>  cat $(for pid in $(pgrep atom); do echo /proc/$pid/maps; done) | grep -v -E '/snap/(core|atom)/' | grep '/usr/lib' | awk '{ print $6 }' | sort -u
<zyga> this shows which host libs they depend on
<zyga> repeat for classic snaps
<zyga> kyrofa: ^
<zyga> (fun, no?)
<popey> -> afk
<zyga> cat $(for pid in $(pgrep atom); do echo /proc/$pid/maps; done) | grep -v -E '/snap/.*/' | grep '/usr/lib' | awk '{ print $6 }' | sort -u
<nacc> zyga: nice
<zyga> this is generalized for not just atom, replace atom in the first part
<kyrofa> zyga, I'm around, but you're third in the queue, give me a few
<zyga> kyrofa: just enqueue this, ORIGIN replacement should handle multiarch
<kyrofa> It does. Well, should anyway
<zyga> the long shell thing above is a nice way to test against real-world snaps at runtime
<zyga> kyrofa: apparently not in atom, sync with popey for details
<kyrofa> Will do
<mup> PR snapd#4956 closed: cmd/snap-update-ns: rename i to segNum <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4956>
<zyga> jdstrand: can you please do a 2nd look on https://github.com/snapcore/snapd/pull/4955 - I think I addressed your concerns there
<mup> PR #4955: cmd/snap-confine: make /run/media an alias of /media <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4955>
<Anthaas> Anywhere to view popular snaps?
<zyga> Anthaas: gnome-software shows featured snaps on some distributions
<zyga> pstolowski: around?
<zyga> pstolowski: I need a simple review for 4958
<zyga> I just add an argument in lots of places
<zyga> pedronis: if you can as well
<zyga> pedronis: this is the helper to remove the global variable hack from that other pR
<pedronis> zyga: I'm looking at it, the code org feels a bit strange
<niemeyer> kyrofa: Wanna talk now?
<kyrofa> niemeyer, sure!
<niemeyer> kyrofa: https://hangouts.google.com/hangouts/_/canonical.com/snap-architectures
<pedronis> zyga: it feels like   there should be something carrying state that exposes the  secure*  instead of passing this in this way and then passing it in to the secure* functions
<zyga> pedronis: so making them all instances of some type
<pedronis> well methods of some stateful struct
<zyga> right
<pedronis> IÂ mean, so far they didn't need state
<pedronis> now it seems they do
<pedronis> is it the only state they will need?
<pedronis> a bit unclear
<zyga> it seems so
<zyga> we never assumed mkdir would need state
<pedronis> now it does though
<pedronis> anyway my 2cts
<zyga> pedronis: I can do as you said
<zyga> pedronis: or we could iterate on this concept, it's fine either way
<zyga> thanks!
<zyga> mborzecki: hey, can I grab you for a moment
<cachio> zyga, when you have any time #4832
<mup> PR #4832: tests: move fedora 27 to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4832>
<cachio> it is to close the fedora one
<zyga> looking
<zyga> cachio: have a look
<cachio> tx
 * zyga breaks until the 2.32.2 release can be made
<zyga> Caelum: hey
<zyga> Caelum: if you don't have time to update the leap builds I can do that too
<zyga> I'd like to release your package to tumbleweed
<zyga> aand I just did
 * zyga goes to fix LEAP
<cachio> zyga, fedora branch updated
<cachio> thanks for reviewing this
<zyga> thanks, approved
<cachio> \o/
 * zyga wonders where the sublime-text snap is
<zyga> om26er: do I recall correctly you were interested in that?
<om26er> zyga: its uploaded but there is a bug
<om26er> ...in the snap. I fixed that, there is a pending PR
<om26er> https://github.com/snapcrafters/sublime-text/pull/9
<mup> PR snapcrafters/sublime-text#9: ship gtk2 and fix desktop file shortcuts <Created by om26er> <https://github.com/snapcrafters/sublime-text/pull/9>
<om26er> @zyga: ^^
<om26er> the bug is because something changed in latest version of snapd (?) for classic snaps
<kyrofa> niemeyer, just realized we didn't discuss the `ignore-failure` bit-- does that seem okay?
<niemeyer> kyrofa: Hmm..
<zyga> OH
<niemeyer> kyrofa: We should probably refactor it a bit so it can be expanded.. hmm
<zyga> looking
<niemeyer> I think we can do something like "build-errors: ignore"
<niemeyer> kyrofa:
<kyrofa> niemeyer, ah, in case we want an option besides ignore in the future?
<niemeyer> kyrofa: But there's a detail here.. it's awkward to see the third-person verb next to a noun
<niemeyer> Or an adjective I guess
<niemeyer> kyrofa: So maybe we should say "build-on" and "run-on"
<niemeyer> kyrofa: So that "build-foo" looks nice
<niemeyer> build-on: blah
<niemeyer> build-errors: foo
<kyrofa> niemeyer, yeah I'm fine with that. A little more... functional instead of sentence-y
<niemeyer> Right
<zyga> om26er: that's interesting, that change was in snapcraft though as snapd didn't change how classic snaps run in ages
<niemeyer> Imperative.. do this!
<kyrofa> Indeed
<kyrofa> Okay, build-error: ignore it is
<pedronis> zyga: btw release/2.32  is read atm, not quite sure why, it seems a build error on fedora
<pedronis> *is red
<zyga> pedronis: yeah, we're not lucky :/
<zyga> pedronis: I think the media thing is a factor
<pedronis> it's not an test error
<pedronis> is failing on prepare
<zyga> oh, what was the error?
<pedronis> something building godbus and os/signal
<pedronis> zyga: let me give you the end
<pedronis> zyga:  https://pastebin.ubuntu.com/p/d6rgHVVXSK/  I'm not quite sure what the error is
<zyga> hmm, is it that thing that failed, maybe the error is earlier?
<pedronis> maybe  fedora prepare is super verbose
<pedronis> zyga:  full log is here:  https://api.travis-ci.org/v3/job/359849295/log.txt
<zyga> reading
<zyga> hmm
<zyga> indeed
<pedronis> it seems a genuine like it's failing to make an archive fail
<pedronis> *file
<zyga> I wonder what "pack" there is
<pedronis> not sure why now, in that branch
<zyga> is that gong internal stuff?
<pedronis> yes
<zyga> so yeah, looks real, needs some investigation
<pedronis> https://golang.org/cmd/pack/
<pedronis> it's also exploding far away from the what the PR changed   (code in store)
<zyga> I wonder why it started exploding
<zyga> especially on linode
<zyga> cachio: did we move anything on our linode fedora images?
<pedronis> zyga: we don't know if  https://github.com/snapcore/snapd/commit/eed6d62f9eb1d02af8e65927ae844aff31b69f55 built cleanly though
<pedronis> because it was cancelled
<pedronis> on 2.32
<zyga> I can run and reproduce
<pedronis> IÂ mean, at least that one is changing build stuff
<pedronis> still not clear the relation though
<zyga> I'm doing -debug on the release branch now
<zyga> let's see
<zyga> I think release tonight is unlikely
<zyga> travis is starving us
<zyga> and there are open PRs
<koala_man> diddledan: my version issues were because snapcraft only looked for annotated tags, while all my later tags were lightweight
<pedronis> zyga: it's not only the release, I got  the same on my PR for master
<zyga> on master on google?
<pedronis> zyga: did fedora get a new golang version?
<zyga> F27 would not but let me check
<zyga> well
<pedronis> no still linode
<zyga> I'll check
<zyga> go version go1.9.4 linux/amd64
<zyga> checking changeling now
<pedronis> anyway failure is the same as on release/2.32
<zyga> hum
<zyga> I just got this on F27 on a casual go test ./...
<zyga> https://www.irccloud.com/pastebin/tD6mlgYu/
<pedronis> master is now also red
<pedronis> same error
<pedronis> zyga: you need gcc-multiarch to run those tests
<pedronis> sorry
<pedronis> gcc-multilib
<zyga> there's no such thing apparently
<pedronis> that's been there since a long while
<pedronis> that's the name of the ubuntu package
<pedronis> I don't think it relates to the current error
<zyga> hmm, yeah
<zyga> I got to the same error in -debug build
<pedronis> what did change?
<pedronis> it seems master was green until this morning ~ 2h ago
<zyga> no idea what changed, I don't know how to find the changelogs in RPM world
<zyga> let me update the VM and see if I can reproduce it
<zyga> Pharaoh_Atem: ping
<zyga> if you are around, we could use some help
<Pharaoh_Atem> zyga: pong?
<zyga> hey
<zyga> golang started to fail on us recently
<zyga> any idea if there's widespread fire in F27?
<zyga> or some major changes to golnag
<zyga> or how to find a changelog for the toolchain
<zyga> to reproduce just run: spread -debug -v linode:fedora-27-64/tests/main/
<zyga> it will fail on rpmbuild -ba ...
<zyga> rpmbuild --with testkeys -ba packaging/fedora-27/snapd.spec
 * zyga runs a build with updated fedora VM
<Pharaoh_Atem> there's the revamp of the golang macros
<Pharaoh_Atem> but that shouldn't break snapd... I think
<zyga> Pharaoh_Atem: in F28 or F27 too?
<Pharaoh_Atem> everything
<zyga> ok
<zyga> reproduced on up-to-date F27
<zyga> https://www.irccloud.com/pastebin/G2rCOdVh/
<Pharaoh_Atem> go has the worst debug messages
<pedronis> as in no message
<pedronis> is just dieing there
<zyga> to be fair, I don't know what's really happening in the rpm build macros
<zyga> going to src/os/signal I can "go build"
<pedronis> pack r $WORK/os/signal.a $WORK/os/signal/_obj/sig.o # internal   shows up also normally
<pedronis> is not an error message
<pedronis> alone
<pedronis> it might be what dies (maybe)
<zyga> interestingly
<zyga> sig.o is from sig.s
<zyga> and sig.s is empty
<zyga> well
<zyga> https://www.irccloud.com/pastebin/mEogC2QN/
<zyga> maybe some of the rpm build macros dont handle this correctly?
<pedronis> that hasn't change recently IÂ think
<zyga> the .s file? yeah
<zyga> but the macros
<jdstrand> zyga: it seems you didn't see that I already responded to 4955 a while ago: https://github.com/snapcore/snapd/pull/4955#discussion_r178084121
<mup> PR #4955: cmd/snap-confine: make /run/media an alias of /media <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4955>
<pedronis> sig.s  is like that also in go 1.6
<zyga> Pharaoh_Atem: can you point us to a changelog or some description of what is changing?
<pedronis> that's from the stdlib
<pedronis> btw
<zyga> jdstrand: oh, looking
<zyga> jdstrand: no, github didn't show that :/
<zyga> thanks
<jdstrand> I don't know why github comments are sometimes lossy
<jdstrand> it is annoying
<zyga> jdstrand: yeah, no disagreement there
<zyga> so I'll just check that altpath is not a symlink
<zyga> that's easy, thank you
<zyga> (if only everything was not on fire :)
<zyga> pedronis: yes, I think rpm side broke, not the go side
<pedronis> yes, what I'm saying is that that thing is not an obscure
<pedronis> 3rd party package
<pedronis> is a piece of the stdlib
<zyga> ack, right
<zyga> Pharaoh_Atem: I will take any ideas or patches you can give me
<zyga> I think the release plan for today is to EOD and rest
<zyga> and read a book about something not work related
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/4955/commits/7ef58f6c315e13557f2e8c318980e7bcdfc8d316
<mup> PR #4955: cmd/snap-confine: make /run/media an alias of /media <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4955>
<jdstrand> zyga: approved with comment
<zyga> reading
<jdstrand> it's only a nitpick
<zyga> sure, will tweak in a sec, rebooting VMs
<mup> PR snapd#4961 opened: cmd: make fmt (indent 2.2.11) <Created by zyga> <https://github.com/snapcore/snapd/pull/4961>
<cachio> zyga, https://travis-ci.org/snapcore/snapd/builds/359989484#L2706
<cachio> could be cause because we set selinux permissive
<cachio> ?
<cachio> it starting failing after last chnage that was totally unrelated
<zyga> cachio: no
<zyga> cachio: it's some golang bug, we don't know yet
<zyga> cachio: to be precise, according to Pharaoh_Atem rpm macros changed recently, not sure what to do
<cachio> zyga, ah, ok
<cachio> zyga, I'll wait so
<cachio> zyga, tell me if you need any help to fix/validate that
<zyga> i took a break for today
<zyga> Ideas welcome
<zyga> Iâll try tomorrow
<cachio> zyga, sure
<cachio> I'll be off tomorrow but I'll be connected
<pedronis> zyga: so I tried to run of that by hand, interestingly is not pack that fails, afaict the sig.o is added to the archive
<pedronis> is the wrapper program or whatever comes next
<pedronis> it produces no output of its own though :/
<pedronis> *run some of that
<pedronis> apparently it dies just before building snapd itself
<pedronis> it makes no sense
<kyrofa> Snapd 2.31.2 has been in xenial-proposed for a while, is something holding it up?
<nacc> kyrofa: http://people.canonical.com/~ubuntu-archive/pending-sru.html bunch of test regressions?
<nacc> and in dep-wait for 14.04, it seems
<kyrofa> I suppose that'd do it
<nacc> kyrofa: i'd get all of that green :)
<vidal72[m]> I wonder how daemon snap package integrate with system - i.e. when I install network-manager snap - can I manage it from systemd services?
<popey> vidal72[m]: systemctl status snap.network-manager
<popey> or similar
<vidal72[m]> popey: thx
<kyrofa> zyga, I don't suppose you're still around
<kyrofa> On trusty I'm getting "error: unable to contact snap store"
<kyrofa> Whenever I try to refresh or install anything
<noise][> kyrofa: network outage
<noise][> generally, not just store
<kyrofa> noise][, oh, what a coincidence!
<jdstrand> zyga, jamesh: fyi, I approved the approach of https://github.com/snapcore/snapd/pull/4957. I'm eod now-- I'll respond to comments in the PR as needed
<mup> PR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957>
<kyrofa> niemeyer, the lxd backend in spread fails every time for be with 17.10 and 18.04, always giving me this:
<kyrofa> 2018-03-29 15:47:11 Discarding lxd:ubuntu-18.04 (spread-31-ubuntu-18-04), cannot connect: cannot connect to lxd:ubuntu-18.04 (spread-31-ubuntu-18-04): ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain
<kyrofa> 2018-03-29 15:48:03 Discarding lxd:ubuntu-17.10 (spread-33-ubuntu-17-10), cannot connect: cannot connect to lxd:ubuntu-17.10 (spread-33-ubuntu-17-10): ssh: handshake failed: ssh: unable to authenticate, attempted methods [password none], no supported methods remain
<kyrofa> Curious if that rings any bells. 16.04 works fine
#snappy 2018-03-30
<zyga_> kyrofa: ack, I will try tomorrow
<zyga_> jdstrand: ack
<zyga> pedronis: ack
<mup> Bug #1684014 changed: LibreOffice in snap won't print <libreoffice (Ubuntu):New> <https://launchpad.net/bugs/1684014>
<zyga> Good morning
<pstolowski> morning zyga!
<zyga> Hey hey
<zyga> It is Friday and everything looks terrible :-)
<pstolowski> zyga: no kidding
<zyga> pstolowski: fedora builds are broken
<zyga> pstolowski: travis slots last night were all gone
<zyga> pstolowski: and I didn't manage to release snapd
<pstolowski> gosh
<pstolowski> zyga: what's going on with fedora this time?
<pedronis> pstolowski: afaict go build itself (wich is mostly a wrapper process) dies with exit 2 just before doing the steps of building snapd main itself (after having built all other packages)
<pedronis> without printing any useful info
<pedronis> fun :/
 * pedronis -> afk
<pedronis> pstolowski: zyga:   I tried to strace it,   it was late so maybe IÂ missed something, but afaict no smoking gun there, just after it writes sig.o to signal.a  (the internal pack, internal meaningÂ IÂ discovered is code inside go build not an external exec) it just starts unlinking stuff from the work dir and then you get the exit 2
<pedronis> so it's a sorf of unexplained semi orderly death
 * pedronis really afk
<pstolowski> were there any updates to fedora?
<pedronis> IÂ don't know,   golang claims to be from Mar 5  (so we should have been using it already?  but I don't know how updates percolates there)
<zyga> hmm
<pedronis> rpmbuild seems the same
<pedronis> but maybe some lib changed
<zyga> hey pedronis, thank you for the analysis
<pedronis> zyga: for details, what I did sofar   is set the few GO env vars and rerun  the "go build" line   in a -debug spread session,   with -n  (to see how far we go, as I said very far)  and then with strace -f
<pedronis> it's also very consistent
<pedronis> dies the same way each time
<zyga> pedronis:  do you remember what you set?
<pedronis> I also double checked the content of the work dir ,  as I said signal.a  looks right  but   ... /cmd/snapd/_obj is not yet created
<pedronis> zyga: it's in the log
<pedronis> just GOPATH  and GOFLAGS
<pedronis> I think
<zyga> ok
<pedronis> after of course cd-ing into /root/rpmbuild/....
 * zyga goes to reproduce this with fresh head
<zyga> so, the list of updates is on https://bodhi.fedoraproject.org/updates/?releases=F27
<zyga> I'll see if there's something recently that could explain it
<pstolowski> zyga: looking into this too
<zyga> if we don't find anything quickly let's split focus and not all try to solve this
<zyga> I went back 10 days and there's nothing that would indicate any relationship
<zyga> the closest I saw was a clang update to ship a versioned compiler-version binary
<zyga> I noticed that on 18.04 high-dpi regressed as compared to 17.10 (for snaps)
<pstolowski> zyga: fwiw I got that error when building signal.a; then I executed /var/tmp/rpm-tmp.5TbNku manually and it succeeded
<pstolowski> zyga: (fedora on linode)
<zyga> interesting, I wonder what that tells us
<pstolowski> exactly
<pstolowski> zyga: i've rebuilt manually like that 3 times, worked
<zyga> pstolowski: I'm doing a mock build to see how that works
<pstolowski> zyga: do you know what creates and calls /var/tmp/rpm-tmp.5TbNku ?
<zyga> I think it's part of some RPM macro but I don't know which
<zyga> it could also be a recovery mechanism
<zyga> when rpm fails, it writes "reproduce me" shell
<pstolowski> zyga: yeah, ok, it's assembled from snapd.spec
<zyga> Breakfast break
<zyga> After that I will mock build
<zyga> And try koji next
<pedronis> pstolowski: that is interesting because if  IÂ run the go build part alone again and again is still fails
<pstolowski> pedronis: wow, interesting
<pstolowski> pedronis, zyga and i'v just run the build via rpmbuild --with testkeys -bs and it failed
<zyga> yes, I got that too
<pedronis> so repeating rpmbuild  fails (different state each time),     repeating go build   fails (afaict)
<pedronis> but repeating the tmp script works?
<pedronis> fascinating
<pstolowski> pedronis: i'm just going to try tmp script again
<pedronis> is it succedding in the sense of exit 0
<pedronis> or in the sense it build a snapd binary?
<zyga> I tried to remove the spread + linode|google magic out of the equation
<zyga> I built an source tarball and srpm
<zyga> now building it in mock
<zyga> this is essentially how all of fedora is normally built
<zyga> iff this fails
<zyga> we can give this srpm to people and ask for help
<pstolowski> pedronis: yes, exit 0, no error around signal.a, the execution ends with https://pastebin.ubuntu.com/p/gtHJGPbPmV/
<zyga> + mock is nicer than rpmbuild directly
<pstolowski> pedronis: so, tmp script just succeeded again
<zyga> so
<zyga> ah, I didn't use test keys so maybe that's why
<zyga> the source rpm + mock fail on pack but in a different spot
<zyga> BUILDSTDERR: /usr/lib/golang/pkg/tool/linux_amd64/compile -o $WORK/golang.org/x/net/context/ctxhttp.a -trimpath $WORK -shared -goversion go1.9.4 -p golang.org/x/net/context/ctxhttp -complete -installsuffix shared -buildid ab9e3e1669ce2ef40183ac44ed64b157e02355b9 -D _/usr/share/gocode/src/golang.org/x/net/context/ctxhttp -I $WORK -I /usr/share/gocode/pkg/linux_amd64_shared -pack ./ctxhttp.go
<pedronis> pstolowski: how are you running it again,  I get  failed to create symbolic link because the link alreday exists
<zyga> Pharaoh_Atem: hey
<zyga> Pharaoh_Atem: so I have a srpm I can reproducibly fail to build in mock
<pedronis> pstolowski: are you rm -rf something before running it again?
<pstolowski> pedronis: I get that symink error too but that doesn't interrupt the build
<pedronis> heh
<pedronis> it definitely does here
<pedronis> pstolowski: ah, are you running without -e ?
<pedronis> that's why it finishes
<pedronis> it ignores errors
<pedronis> nothing magic
<pstolowski> ah
<pstolowski> dammit
<pedronis> indeed
<pedronis> too bad
<pedronis> zyga: I have no clue what dimension changed (our code,  fedora bit) though ... it stopped working quite randomly yesterday afaict
<zyga> yes, I'm totally puzzled
<zyga> I will try with -testkeys now
<zyga> as my failure looks the same but in different spot
<pedronis> it seems a go build bug
<pedronis> but unclear why it appears now
<pedronis> what it triggers it
<pedronis> s/what it/what7
 * pedronis ->Â off
<pedronis> zyga: one thing to try would also be  to copy over the BUILD directory to bionic and see if that go build command fails there too with 1.9,  fwiw it failed for me also when I didn't pass some of the ldflags stuff
<pedronis> anyway as said, from the strace it seems to fail in the boring bits of driving the build
<zyga> on my host it consistently fails elsewhere
<zyga> maybe it depends number of CPUs?
<zyga> oh, I'll try koi first
<zyga> koji
<pstolowski> fwiw it fails also with go1.9.5 and 1.10.1 on fedora
<Caelum> zyga: my btrfs died, I submitted that request from the console on a half-broken system, just reinstalled now and picking up the pieces, on ext4 this time
<pedronis> even just this fails:   cd /root/rpmbuild/BUILD/snapd-1337.2.31.1  ;  cd cmd/snapd;  go build -v -x .   with or without -a
<pedronis> it just exit 2 before building main
<zyga> Caelum: ouch
<zyga> sorry to hear that
<zyga> Caelum: I made some changes since your patches
<Caelum> excellent
<zyga> pedronis: I submitted a koji build https://koji.fedoraproject.org/koji/taskinfo?taskID=26057356
<Caelum> so .32 is out
<pedronis> pstolowski: would be interesting to copy over the BUILD to an ubuntu system and see if it fails too,   as I show there it seems to fail even without fancy options or anything
<pstolowski> pedronis: yes, i'm going to try that next
<pedronis> it just refuses to build cmd/snapd(/maing.go) on fedora
<zyga> the log is a little bit more useful
<zyga> https://koji.fedoraproject.org/koji/getfile?taskID=26057357&volume=DEFAULT&name=build.log&offset=-4000
<zyga> (tail of the build log)
<zyga> tail feature == good thing to copy
<zyga> does this cp $WORK/b150/_pkg_.a /builddir/.cache/go-build/92/92ebdb22b8c38b43994a36a864adc877e4e85517bc1f1a7c1b22ee610a1af86d-d # internal
<zyga> error: Bad exit status from /var/tmp/rpm-tmp.MIqip3 (%build)
<zyga> say it is actually cp that failed?
<pedronis> that's a completely different kind of failure
<pedronis> though
<pedronis> we don't know
<pedronis> usually the last thing printed might have work or not
<pedronis> as I said in the other failure
<pedronis> the pack works
<pedronis> is the next step that is not taken
<zyga> this is in koji, the fedora build service
<pedronis> IÂ understand
<pedronis> just saying that looks like a failure
<zyga> if this is kernel related they are (perhaps) on a different version of that
<pedronis> but a different failure
<pedronis> it's also an exit 1 vs exit 2
<zyga> note that the same SRPM was failing on pack on my host
<pedronis> IÂ note that on linode the failure mode is very deterministic
<pedronis> as I said it seems to refuse to go to the last bit
<pedronis> and build cmd/snapd itself
<pedronis> (the pack itself works)
<pedronis> indeed it fails like that, exit 2 refusing to build main even in builds that don't have a pack bit
<pedronis> late
<pedronis> zyga: as I said the failure in that  log, looks very different, it seems to be failing building one the prereq packages
<pedronis> on snapd itself
<pedronis> s/on snapd/not snapd/
<pedronis> what   golang is that btw?
<pedronis> 1.10?
<zyga> I switched from F28 to F27 and now it's the same error I saw on my host
<zyga> let me check
<zyga> https://koji.fedoraproject.org/koji/getfile?taskID=26057448&volume=DEFAULT&name=build.log&offset=-4000 (the F27 build tail)
<zyga> DEBUG util.py:439:   golang                              x86_64 1.9.4-2.fc27            build 622 k
<zyga> 1.9.4
<pedronis> on F27 ?
<pedronis> onÂ F28 ?
<zyga> this is on F27 now
<zyga> the prior build was on F28 and this is why it was different, it was also on using more recent golang
<pedronis> it just feels like they brok all go building
<pedronis> it's very strange
<pedronis> also the errors are all different
<zyga> I'll ask around
<zyga> I asked on fedora-devel
<zyga> not sure what to do now
<zyga> I feel we should disable fedora for the time being
<zyga> this would unblock the release
<pedronis> zyga: interesting, not sure if related but  I see,    /usr/share/gocode/src/%{go_import_path}  like that in the filesystem
<pedronis> like some package is really broken
<zyga> oh
<zyga> that looks like RPM macro that didn't expand
<zyga> that's very interesting, let me look
<zyga> pedronis: I'll disable fedora now
<zyga> let's see if that passes
<mup> PR snapd#4962 opened: spread.yaml: switch Fedora 27 tests to manual <Created by zyga> <https://github.com/snapcore/snapd/pull/4962>
<zyga> Iâm debugging this in fedora-devel
<pedronis> zyga: pstolowski:Â so if I copy over to ubuntu the  gocode dir and the rpmbuild dir and set GOPATH to those, even old go 1.6 fails to build cmd/snapd with exit 2
<zyga> cool find
<zyga> but does that tree include effectively golang 1.9 source?
<pedronis> no
<pedronis> gocode has only our deps
<pedronis> goroot is the 1.6 one
<pstolowski> pedronis: and that gocode dir contains that suspicious unexpanded macro?
<pedronis> yes
<pedronis> but yes, it would be better to try this with ubuntu go 1.9
<pedronis> less moving parts
<pedronis> but is interesting nevertheless
<pedronis> it really seems is some issue with src code  (ours or the one brought in by dep packages)
<pedronis> and to be clear, this is just a plain:   go build -a -v -x .
<pedronis> nothing fancy
<pedronis> from cmd/snapd
<zyga> let's try building older tree
<pedronis> anyway  the %{}  thing for sure cannot bring any good
<zyga> # cd /home/zyga/go/.cache/govendor/gopkg.in/yaml.v2; git reset --hard 86f5ed62f8a0ee96bd888d2efdfd6d4fb100a4eb
<zyga> fatal: Could not parse object '86f5ed62f8a0ee96bd888d2efdfd6d4fb100a4eb'.
<zyga> mmmm
<zyga> ./get-deps.sh failed
<zyga> worked after I removed ~/go/.cache
<zyga> pedronis: "go build ./cmd/snapd" works
<pedronis> ?
<pedronis> where, in which sense?
<pedronis> you mean with our usual vendor dir?
<zyga> yes
<zyga> in a checkout on F27
<zyga> not in the whole build machinery
<pedronis> so it seems some packages  are broken
<pedronis> and render this %{} nonsense
<zyga> I ran "go build -a -v -x" next and it printed a wall of text and exited with 130
<thresh> good morning
<pedronis> and that breaks things
<pedronis> (strangely in a very non visible way)
<zyga> hey thresh
<zyga> pedronis: go build -a -v -x in cmd/snapd also works
<zyga> from our checkout
<zyga> ls
<zyga> pedronis: https://github.com/snapcore/snapd/pull/4962
<mup> PR #4962: spread.yaml: switch Fedora 27 tests to manual <Created by zyga> <https://github.com/snapcore/snapd/pull/4962>
<zyga> let's land this
<pstolowski> +1
<pedronis> zyga: pstolowski:  yes definitely switching the share/gocode stuff with out usual deps makes thing work again
<pedronis> even using them not through vendor to be clear, but just in the GOPATH
<pedronis> zyga: pstolowski:  so  yesterday one of the deps packages was updated?   or something changed in the rpm go stuff that affects one happens when they are installed?
<pedronis> IÂ mean in fedora
<zyga> pedronis: I looked at the list of changes published in bodhi and I dind't notice anything golang at all
<zyga> pedronis: let's merge my PR and unblock master
<pstolowski> and i've just removed that bogus /usr/share/gocode/%{go_import* path from fs but that didn't make a difference, must be something else in gocode dif
<pstolowski> *dir
<pstolowski> lunch break
<pedronis> pstolowski: yea, I tried the same,  IÂ don't get a missing package error, but even without the %{} nonsese, it still exit 2
<pedronis> even go 1.6
<zyga> pedronis: I think it may be yaml related
<zyga> https://zero.crans.org/?3e5975e22418a02e#Xv5Juf3UYkZ0FgzYq9Uu2h9AFG4FKFMWqbITXDLVZno=
<pedronis> I was thinking the same
<pedronis> a bit unclear exactly what
<zyga> this is something fedora developer was helping me with
<zyga> I'll revert the yaml version bump and build
<pedronis> but the run that bumped it was green ??
<zyga> reverted, no change
<zyga> so back to where we started :/
<vidal72[m]> zyga: I fixed trailing " and there is no more backend_test.go failure in https://github.com/snapcore/snapd/pull/4944
<zyga> pedronis: shall we merge 4962 or do you want to resolve this before master can move
<mup> PR #4944: interfaces: add /var/lib/snapd/snap to @{INSTALL_DIR} <Created by Erick555> <https://github.com/snapcore/snapd/pull/4944>
<pedronis> zyga: I should be off, I'm not taking decisions
<zyga> ok
<pedronis> zyga: anyway it's not a bug in our code afaict
<zyga> yes, that is clear, I thin
<zyga> *think
<mup> PR snapd#4962 closed: spread.yaml: switch Fedora 27 tests to manual <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4962>
<thresh> woah, my forum post is flagged as spam
<thresh> verynice
<thresh> > Multiple community members flagged this post before it was hidden
<thresh> what
<thresh> seriously?
 * zyga -> walk
<thresh> how is https://forum.snapcraft.io/t/snapcraft-stage-packages-inconsistent-behaviour/4746 a spam ?!
<thresh> and/or advertisement
<thresh> is there a saner platform to collaborate with devs?
<jdstrand> niemeyer: hi! quick 'snap switch' question. I have canonical-livepatch on a system. it was tracking stable, r26. yesterady I did 'sudo snap refresh --edge canonical-livepatch'. this refreshed to r38 and marked the snap as starting to track edge (based on snap info). this is all fine
<jdstrand> niemeyer: then I did 'sudo snap switch --channel=stable canonical-livepatch'. this did not refresh the snap (good) and marked the snap as tracking stable (as seen with snap info. also good)
<jdstrand> niemeyer: so at this point, I thought that everything was all set for the snap to only refresh the next time stable refreshed, however, at some point later in the day, the snap refreshed automatically in the background and downgraded to stable. is this expected behavior?
<jdstrand> s/stable refreshed/stable's revision changed/
<vidal72[m]> thresh_: someone doesn't like you :)
<vidal72[m]> thresh:  ^
<jdstrand> niemeyer: here is a little more detail:
<jdstrand> $ sudo snap changes canonical-livepatch
<jdstrand> ID   Status  Spawn                 Ready                 Summary
<jdstrand> 551  Done    2018-03-29T13:17:24Z  2018-03-29T13:17:31Z  Refresh "canonical-livepatch" snap from "edge" channel
<jdstrand> 552  Done    2018-03-29T13:18:04Z  2018-03-29T13:18:04Z  Switch "canonical-livepatch" snap to stable
<jdstrand> 553  Done    2018-03-29T20:49:59Z  2018-03-29T20:50:02Z  Auto-refresh snap "canonical-livepatch"
<jdstrand> 554  Done    2018-03-30T12:20:37Z  2018-03-30T12:20:40Z  Refresh "canonical-livepatch" snap from "candidate" channel
<jdstrand> niemeyer: it is '553' that did the downgrade back to stable
<jdstrand> niemeyer: if it is operating as designed, that's fine (though, I wonder about the utility of 'switch' then), I just want to make sure it is working correctly
<pedronis> jdstrand: no, that's the correct behavior, it will refresh to whatever is on stable
<pedronis> s/correct/expected/
<pedronis> remember there's no order in revisions
<pedronis> jdstrand: switch is more useful if say candidate and revision have the same revision, but I also think we changed refresh to work more like switch in that case
<pedronis> so it might not be as useful as it was
<thresh> vidal72[m], but I'm amazing and nice
<vidal72[m]> :)
<zyga> Which post is that
<thresh> I linked it half and hour ago here
<thresh> afraid to post it twice now lol
<jdstrand> niemeyer: nm, pedronis answered
<jdstrand> pedronis: sure, I realize there is no order with revisions, but if I was on r26/stable then refreshed to r38/edge, then snap switched to stable, I didn't expect to go to r26/stable. I expected to go to !26/stable
<jdstrand> pedronis: I'm not sure of the utility of snap switch then tbh. it ends up being a delayed refresh
<jdstrand> pedronis: where I want a delayed refresh to a new thing in the switched to channel
 * zyga is back from his walk
<zyga> popey: what blocks sublime-text from release?
<zyga> thresh: I didn't see the link, can you please re-post?
<mup> PR snapd#4955 closed: cmd/snap-confine: make /run/media an alias of /media <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4955>
<popey> zyga: actually realised that we should store rename s-t3 to s-t, otherwise the hundreds of people with st3 won't get updates
<zyga> can we even do this?
<zyga> I don't think we can
<popey> I believe the store people can rename a snap yes
<popey> it keeps the id
<zyga> ah, in that case, all for it
<zyga> can I help somehow
<zyga> I'd love to just use s-t from snaps already
<popey> are store people working today?
<popey> yeah, sorry, been on vacation the last few days so it's been back burner
<pstolowski> zyga: standup, or skip?
<zyga> oh
<zyga> sorry
<popey> thresh: dunno why the forum is marking your posts as spam. I have unflagged them as such. Maybe niemeyer knows
<zyga> pstolowski: let's skip maybe
<zyga> pstolowski: google signed me out
<zyga> pstolowski: is it just you and me?
<zyga> ok, found my token
<zyga> thank you popey
<popey> wtf. i just installed a snap and as soon as the apparmor connections were made the session exploded
<popey> i didnt even launch the snap, it ended immediately after install finished
<jdstrand> popey: eom?
<popey> eom?
<zyga> popey: probably udev
<zyga> or oom
<zyga> (out of memory)
<popey> unlikely
<popey> it has 64GB
<zyga> but I saw people reporting bugs about touchpad issues when installing a snap
<zyga> woah, nice machine!
<popey> just logged back in and I get a "xorg crashed" bug reporter
<zyga> and it feels like udevadm trigger is not good
<zyga> popey: can you ssh in
<zyga> and run journalctl -f
<zyga> and reproduce?
<popey> i logged back in, on a desktop
<popey> I'm on core beta
<zyga> popey: is that a wayland session
<zyga> when wayland crashes it takes the session with it
<popey> hah, not on your life
<zyga> well, review your log
<zyga> there's gotta be a backtrace somewhere :)
<popey> juat waiting for whoopsie to do its thing
<popey> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/1760104  whoospie says it's an nvidia driver bug, so who knows
<zyga> popey: *bam*
<zyga> maybe it's our bug
<zyga> I got 404, it's marked as security
<popey> I wlll try and reproduce it
<zyga> popey: look at your journal first
<popey> given I am building a new rev of the snap
<zyga> there is likely a backtrace there already
<popey> will that be already attached to the bug?
<zyga> I cannot see the bug
 * zyga is super happy today
<popey> https://www.irccloud.com/pastebin/Ic5TwB7Y/
<popey> that's all i see in journal
<zyga> â¨no no, that's -f
<zyga> that's "follow"
<zyga> run journalctl
<zyga> and page it
<zyga> until you see something that's clearly a backtrace
<zyga> it should be from this boot only
<zyga> so not _too_ long perhaps
 * zyga is super happy because his T470 has a working modem now :)
<zyga> it's internal, antennas work and I have 100GB of data plan to use
<popey> wow
<zyga> so I can now do what I love doing
<zyga> work outside :)
<popey> work anywhere
<zyga> the modem I got before was not on the whitelist (curse you lenovo)
<zyga> but this one is flawless :)
<zyga> I'm slowly getting used to the T series, X was way smaller
<zyga> but this is not huge either, it's the okay size for work
<zyga> and it's not heavy which is what I was worried about
<popey> https://paste.ubuntu.com/p/3FbykZXbx2/
<popey> not a lot interesting in there?
<thresh> many thanks popey
 * thresh wanders off to friday evening endeavours
<popey> \o/
<zyga> Mar 30 14:15:58 hal compiz[23168]: XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":1"
<zyga> but this is after X died
<zyga> Mar 30 14:15:34 hal audit[1042]: AVC apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.dosbox-x.dosbox-x" pid=1042 comm="apparmor_parser"
<zyga> Mar 30 14:15:35 hal systemd[22791]: Starting Notification regarding a crash report...
<zyga> Mar 30 14:15:36 hal update-notifier-crash[1108]: Xorg
<zyga> we have the same mouse :)
<popey> hah
<jdstrand> popey: haha 'eom'. I meant oom, yes :)
<popey> "End of memory" :D
<zyga> hmmm
<jdstrand> End Of Memory. hehe
<zyga> Mar 30 14:15:33 hal systemd-udevd[689]: Process '/usr/lib/snapd/snap-device-helper change snap_vidcutter_vidcutter /devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0 226:0' failed with exit code 2.
<zyga> Mar 30 14:15:33 hal systemd-udevd[689]: Process '/usr/lib/snapd/snap-device-helper change snap_vlc_vlc /devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0 226:0' failed with exit code 2.
<zyga> Mar 30 14:15:33 hal systemd-udevd[689]: Process '/usr/lib/snapd/snap-device-helper change snap_writefull_writefull /devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0 226:0' failed with exit code 2.
<zyga> Mar 30 14:15:33 hal systemd-udevd[689]: Process '/usr/lib/snapd/snap-device-helper change snap_zzt_zzt /devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0 226:0' failed with exit code 2.
<zyga> jdstrand: ^ does this ring a bell
<zyga> remember the nvidia udev bug?
<zyga> is this back in some way?
<zyga> then X crashes on udev
<jdstrand> zyga: what size is it?
<zyga> size?
<zyga> the mouse?
<jdstrand> zyga: your system. I was reading backscroll
<jdstrand> zyga: but, yes, it does ring a bell. let me look
<zyga> jdstrand: it's popey's system, we just share the same mouse :)
<zyga> I bought my yesterday, wanted something that had a working wheel for games
<popey> I get it on weekends
<zyga> pstolowski: there is a broken gopkg.in/yaml.v2 upload 10 days ago
<zyga> it broke us
<zyga> pstolowski: people in fedora-devel are fixing it
<pstolowski> \o/
<pstolowski> zyga: thanks for info
 * zyga painfully goes through secure code and makes all the functions into methods
<jdstrand> zyga: this is what I was thinking of: https://github.com/snapcore/snapd/pull/4022/files
<mup> PR #4022:  interfaces/opengl: don't udev tag nvidia devices and use snap-confine instead (2.28) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4022>
<zyga> yeah
<jdstrand> actually this: https://github.com/snapcore/snapd/pull/3938
<mup> PR #3938: interfaces/opengl: don't udev tag nvidia devices and use snap-confine instead <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3938>
<zyga> popey: ls /dev/nvidia* /dev/nv*
<zyga> maybe with -l
<zyga> but it appears we are tagging something
<zyga> and then failing
<popey> http://paste.ubuntu.com/p/PRpFNNqc29/
<jdstrand> no new devices there
<jdstrand> popey: ls -lR /dev/dr[im]
<popey> http://paste.ubuntu.com/p/PBx2T3XCTh/
<zyga> jdstrand: are you sure?
<zyga> ah
<zyga> nvme
 * zyga is a moron
<jdstrand> popey: udevadm info /dev/dri/card0
<popey> http://paste.ubuntu.com/p/C875ZW9MPB/
<zyga> well, it's tagged for sure
<zyga> popey: is this a dual-gpu machine?
<popey> nope
<jdstrand> and it's not the same bug since there is udev information on it
<zyga> yes
<zyga> that's a very good point
<zyga> jdstrand: I kind of feel we should hash the udev tag, it's a leak of all the snaps on popeys's system
<jdstrand> there are other leaks of that
<zyga> I also wonder if there's something we could do to make the list of tags shorter
<zyga> especially for udev
<zyga> we could tag "capability" more than "snap"
<zyga> but that's unrelated to the bug
<jdstrand> I think we should consider hashes when we have fine-grained network mediation and/or inode labelling since we'll need to hash for both
<zyga> jdstrand: can we run the device helper
<zyga> to see the error?
<jdstrand> zyga: sure, go ahead
<zyga> I mean, I cannot :)
<zyga> let me come up with the command to run
<jdstrand> it's in the logs
<jdstrand> /usr/lib/snapd/snap-device-helper change snap_zzt_zzt
<jdstrand>               /devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0 226:0
<jdstrand> popey: do you have zzt installed?
<zyga> yeah, I see now
<zyga> usr/lib/snapd/snap-device-helper change snap_writefull_writefull /devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0 226:0
<popey> of course I do :D
<zyga> popey: can you please run: /usr/lib/snapd/snap-device-helper change snap_writefull_writefull /devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0 226:0
<zyga> as root
<jdstrand> popey: snap list shows it?
<popey> jdstrand: yes
<jdstrand> ok
<popey>  /usr/lib/snapd/snap-device-helper: 31: /usr/lib/snapd/snap-device-helper: cannot create /sys/fs/cgroup/devices/snap.writefull.writefull/devices.allow: Directory nonexistent
<jdstrand> interesting
<jdstrand> I have issues like this here without nvidia
<jdstrand> Mar 30 06:33:32 localhost systemd-udevd[23812]: Process '/usr/lib/snapd/snap-device-helper change snap_test-policy-app-consumer_opengl /devices/pci0000:00/0000:00:02.0/drm/card0 226:0' failed with exit code 2.
<jdstrand> /usr/lib/snapd/snap-device-helper: 31: /usr/lib/snapd/snap-device-helper: cannot create /sys/fs/cgroup/devices/snap.test-policy-app-consumer.opengl/devices.allow: Directory nonexistent
<jdstrand> oh right
<jdstrand> so, the cgroup isn't created unless the snap is started
<jdstrand> so the 'change' operation fails
<zyga> oh
<zyga> interesting
<zyga> I doubt this crashes x
<zyga> but we should fix it
<jdstrand> we should probably just check that and exit 0
<zyga> we should bail
<jdstrand> that would not crash x
<zyga> if there's no group at all
<jdstrand> it is a spurious log entry
<jdstrand> it's harmless
<zyga> I agree
<jdstrand> popey: you naming your system 'hal' when looking at udev events feels really weird
<popey> hah :)
<zyga> popey: the private bug you reported, does it contain a backtrace?
<popey> zyga: added you as a subscriber, can you see it now? https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/1760104
<jdstrand> this has nothing to do with snappy afaics:
<jdstrand> SegvAnalysis:
<jdstrand>  Segfault happened at: 0x7f6b00000008: Cannot access memory at address 0x7f6b00000008
<jdstrand>  PC (0x7f6b00000008) not located in a known VMA region (needed executable region)!
<jdstrand>  Stack memory exhausted (SP below stack segment)
<jdstrand> SegvReason: executing unknown VMA
<jdstrand> Signal: 11
<zyga> popey: I can
<zyga> I agree with jdstrand
<mborzecki> hellos
<mborzecki> zyga: 2.32.2 coming later today?
<zyga> hey hey
<jdstrand> seems like a 'normal' crasher
<zyga> yes, slowly
<zyga> well, let me check PRs
<jdstrand> popey: depending on how adventurous your are feeling, you could revert to the previous core, remove the current core, then refresh core and see if it triggers it
<mup> PR snapd#4949 closed: tests: fix quoting issues in econnreset test <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4949>
<popey> It wasnt core that triggered it
<jdstrand> popey: you could remove/install then. the core idea is that it wuld stress test all the security systems
<popey> hm, can't reproduce it with the same snap again
<jdstrand> I suspect it is poor timing
<jdstrand> right
<jdstrand> I would see random stuff like that with intel until the drivers settled down
<jdstrand> it seemed to be triggerable by clicking on a tab in chromium
<zyga> mborzecki: hey
<jdstrand> but most of the time I could click on tabs fine. it is probably memory that is usually set right but occasionaly gets overwritten with garbage
<zyga> mborzecki: I have a small request if you can spare a moment
<jdstrand> popey: good luck! (I wish I could be of more help)
<popey> :)
<popey> Thanks for the time chaps :)
<zyga> mborzecki: 4963 CC pedronis
<zyga> this is the nicer variant of the guardian
<zyga> I'm just wondering if I should prefer the short "sec" or the longer "secure" for variable name :)
<mup> PR snapd#4963 opened: cmd/snap-update-ns: convert Secure* family of functions into methods <Created by zyga> <https://github.com/snapcore/snapd/pull/4963>
<zyga> jdstrand: ^ nothing to worry about, just small code tweak to avoid a global in an upcoming fix
<zyga> https://src.fedoraproject.org/rpms/golang-gopkg-yaml/pull-request/1#request_diff fixes snapd in fedora :)
<mup> PR snapcraft#1995 closed: options: introduce Project and ProjectInfo <enhancement> <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1995>
<zyga> jdstrand: how do you feel about https://github.com/snapcore/snapd/pull/4399
<mup> PR #4399: rewrite snappy-app-dev <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4399>
<jdstrand> zyga: it's in backlog to pickup. I will not get to it for a while yet
<zyga> ok
<jdstrand> I have to some Ubuntu stuff (apparmor, ufw), finish some policy updates PRs (snapd) and move to snap/usn notifications
<jdstrand> I'll try to get to it after those things
<zyga> that's all right, I'm not pushing for it, I'm just going through PRs to see where we are in general
 * jdstrand nods
<zyga> eh
<zyga> + MATCH 'Machine is not enabled'
<zyga> + canonical-livepatch status
<zyga> 2018/03/30 14:42:51 cannot use livepatch: your kernel "4.13.0-1011-gcp" is not eligible for livepatch updates
<zyga> error: pattern not found, got:
<zyga> that sucks for sure
<zyga> now I have to disable that test to unbreak master
<zyga> why does everything break
<zyga> and how did this ever pass?
<zyga> (on GCE)
<mup> PR snapd#4964 opened: tests: adjust canonical-livepatch test on GCE <Created by zyga> <https://github.com/snapcore/snapd/pull/4964>
 * zyga wonders how this even landed
<zyga> pstolowski, jdstrand: ^ (because you're the only pair of reviewers today)
<cmars> zyga: might be that gce changed their kernel since that test was written?
<zyga> I strongly doubt that
<cmars> just an idea, dk
<zyga> I'll check with cachio next week
<pstolowski> zyga: kk
<zyga> the livepatch test failed all master PRs
<zyga> not a great release day either
<pstolowski> +1
<cmars> oh, we did just release a new version of the lp client to stable.. it might be doing a better job of checking compatibility than the older version.
<zyga> ahhh
<zyga> thank you for explaining that! that's useful
<jdstrand> zyga: you're keeping me busy today. +1
<zyga> sorry :)
 * zyga -> dinner
<mup> PR snapd#4965 opened: ifacestate: injectTasks helper <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4965>
<Pharaoh_Atem> zyga: ???
<popey> is nvidia on 18.04 still busted?
<popey> (yes)
<popey> i am on core from beta, and can't launch ohmygiraffe
<zyga> popey: ish, we have a fix if stars align I will release it to beta today
<zyga> Pharaoh_Atem: all good now
<popey> ok, thanks
<zyga> Pharaoh_Atem: golang package in fedora was busted but fantastic people from #fedora-devel figured it out
<zyga> and now travis slots are not ready
<zyga> popey: can you try edge?
<zyga> popey: it should be fine on edge now
<popey> now?
<zyga> yes
<popey> ok
<zyga> though
<zyga> well, let's see
<popey> doing now
<zyga> thank you
<zyga> btw, sublime-text?
<zyga> it's in edge now
<popey> didnt we discuss this like 3 hours ago?
<zyga> yeah but I want to understand what's the next step
<zyga> sorry, I didn't mean to be nagging
<popey> ask store people if they can rename st3 to st
<zyga> just impatient
<popey> np
<popey> edge works with my nvidia application
<zyga> great news
<zyga> so that's coming in beta
<zyga> soon (tm
<zyga> well, I can take an hourly nap now, it looks like travis is starving us after the series of failed builds
 * zyga EOWs
<zyga> I'll do the release tomorrow
<zyga> happy easter everyone :)
<koza> zyga, happy easter and which version you release?
<zyga> koza: 2.32.2
<zyga> popey: sublime-text from edge doesn't start on 18.04
<zyga> I'll check why and get bakc to you
<popey> pretty sure it worked here when i tried it
<zyga> the rpath
<zyga>  0x000000000000000f (RPATH)              Library rpath: [/snap/core/current/lib/x86_64-linux-gnu:/snap/core/current/usr/lib/x86_64-linux-gnu]
<zyga> it doesn't mention sublime-text the snap?
<zyga> ah, there's nothing inside
<zyga> no GTK anything
<zyga> subl after removing the deb and using snap from edge on bionic https://www.irccloud.com/pastebin/oveW053Y/
<zyga> popey: since neither the snap nore core ships them
<zyga> popey: and since the snap has rpath set to just core
<zyga> popey: those are expected to fail
<zyga> but I don't know why it works for you
<zyga> can you run it
<zyga> and run my magic classic bug finding shell line?
<popey> huh, not on this machine, maybe I tested on 16.04 laptop
<zyga> I should make that a snap itself
 * zyga does so
<zyga> jdstrand: can system-observe grant r on /proc/pid/environ
<zyga> jdstrand: in addition /proc/pid/maps would be nice
<zyga> there's nothing that provides that onw
<zyga> *now
<jdstrand> zyga: I'm uneasy about environ, but added it to my todo to think about
<jdstrand> well, I added both things
<zyga> jdstrand: thanks
<zyga> jdstrand: I'm seeing something odd on bionci
<zyga> I'm editing the profile by hand
<zyga> and I see a lot of this
<zyga> ^[[AMar 30 19:44:17 t470 kernel: [25362.426443] audit: type=1400 audit(1522431857.647:15305): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap.classic-snap-analyzer.classic-snap-analyzer" pid=11067 comm="apparmor_parser"
<zyga> after clearly making some changes
<zyga> and I get a denial
<zyga> I added "/proc/*/environ r,"
<zyga> recompiled and got this message and a denial
<zyga> I will try on artful next
<jdstrand> zyga: please file a bug against apparmor with a reproducer and jj can take a look next week (he is off this week)
<zyga> ack, thanks
<zyga> it is obviously broken on the -13 kernel ;-)
 * zyga found a bug with system key
<zyga> :-(
<zyga> build-id mismatch in system-key https://www.irccloud.com/pastebin/YbDY7GB9/
<zyga> ah, this is "okay"
<zyga> hmm hmm hmm
<Caelum> zyga: getting an error trying to add our project as a repo: [snappy|http://download.opensuse.org/repositories/system:/snappy/openSUSE_Tumbleweed/] Valid metadata not found at specified URL
<zyga> oh
 * zyga looks
<zyga> those are the docs we have: https://docs.snapcraft.io/core/install-opensuse
<zyga> sudo zypper addrepo http://download.opensuse.org/repositories/system:/snappy/openSUSE_Tumbleweed/ snappy
<zyga> though we should really update that to enable auto refresh
<Caelum> that's what I was looking at and it gives me that error
<Caelum> once I do a zypper in -y snapd
<zyga> hmm hmm
<zyga> no idea, I'm AFK from my suse box now
<Caelum> I'll ask on #opensuse-factory
<mup> PR snapcraft#2043 opened: cli: support exporting login to stdout <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2043>
<zyga> Caelum: checking now
<Caelum> the addrepo command works fine, it's once you try to install snapd
<zyga> aha
<zyga> booting now
<zyga> 487 updates from tumbleweed :)
<mup> Issue snapcraft#1675 closed: Base logic for metadata setters set- <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1675>
<mup> PR snapcraft#2002 closed: many: add snapcraftctl command for scriptlets <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2002>
<zyga> Caelum: I cannot reproduce your issue
<zyga> I used "zypper update" to refresh the database
<zyga> I trusted the key for the system:snappy repo
<zyga> then I zypper installed snapd
<zyga> installing Spotify
<mup> Issue snapcraft#1671 closed: Rename prepare/build/install to pre-build/build/post-build, and deprecate prepare/build/install <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1671>
<zyga> Caelum: and spotify starts and works correctly
<mup> PR snapd#4960 closed:  interfaces/serial: change pattern not to exclude /dev/ttymxc (2.32) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4960>
<mup> PR snapd#4964 closed: tests: adjust canonical-livepatch test on GCE <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4964>
#snappy 2018-03-31
<Caelum> zyga: here is the zypper output: https://gist.github.com/rkitover/f4b1c61d3ce841355974f37b893a1449
<Caelum> oh I know what the problem is
<Caelum> zyga: the addrepo command needs to have --refresh
<Caelum> zyga: like in these instructions: https://en.opensuse.org/SDB:NVIDIA_drivers
<mcm_> how do you report a bugs against a specific package?
<mup> Bug #1760252 opened: starting slack crashes xwayland on 18.04 <bionic> <Snappy:New> <https://launchpad.net/bugs/1760252>
<mup> PR snapd#4963 closed: cmd/snap-update-ns: convert Secure* family of functions into methods <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4963>
<mup> PR snapd#4946 closed: ifacestate: don't surface errors from stale connections <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4946>
<mup> PR snapd#4958 closed: cmd/snap-update-ns: allow path guardian to inspect fs ops <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4958>
<mup> PR snapd#4944 closed: interfaces: add /var/lib/snapd/snap to @{INSTALL_DIR} <Created by Erick555> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4944>
<mup> PR snapd#4932 closed: interfaces/content: add rule so slot can access writable files at plug's mountpoint <Squash-merge> <Created by gerboland> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4932>
<vidal72[m]> zyga: thx
<zyga> I'll merge some more for release
<zyga> just Saturday so no schedule promised
<vidal72[m]> release will be 2.33 or 2.32.2 ?
<zyga> 2.32.2
<zyga> 2.33 is still sometime away and has lots of new things
<zyga> this is a conservative release to bring in fixes
<Caelum> zyga: should we start working on new suse package for 2.32.1 ?
<Caelum> zyga: also the instructions on snapcraft.io need to be changed to add --refresh to the addrepo command
<zyga> Caelum: let's do 2.32.2, .1 is has known issues
<zyga> the instructions are on some GitHub page but I forgot which, if you remember please remind me next week as there are people then who can change it instantly
<zyga> although...
<zyga> maybe..
<zyga> found it
<zyga> Caelum: https://github.com/canonical-docs/snappy-docs/blob/master/core/install-opensuse.md
<zyga> Caelum: please fork and provide a PR, we can merge it soon
<zyga> ah wait
<zyga> it's an archived repo :/
<zyga> ok, let's wait till next week
<zyga> I don't know where this is
<zyga> actually
<zyga> https://github.com/canonical-docs/snappy-docs/blob/master/core/install-opensuse.md this is fine
<zyga> https://github.com/canonical-docs/snappy-docs/pull/380
<mup> PR canonical-docs/snappy-docs#380: Use address --refresh on openSUSE <Created by zyga> <https://github.com/canonical-docs/snappy-docs/pull/380>
<zyga> Caelum: like this?
<Caelum> zyga: also the instructions on snapcraft.io need to be changed to add --refresh to the addrepo commandyup
<zyga> github is too easy, I didn't even have to open a terminal to edit that
<Caelum> err sorry scrollback
<Caelum> yeah
<zyga> I cannot merge it but it will get merged soon
<zyga> just easter and weekend :)
<mup> PR snapd#4961 closed: cmd: make fmt (indent 2.2.11) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4961>
<mup> Bug #1575053 opened: Please move the "$HOME/snap" directory to a less obtrusive location <julyshakedown> <snapd:Confirmed> <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1575053>
<Caelum> lol, I can't spell anything correctly anymore
<zyga> popey: can we get https://github.com/canonical-docs/snappy-docs/pull/380 merged please :-)
<mup> PR canonical-docs/snappy-docs#380: Use address --refresh on openSUSE <Created by zyga> <https://github.com/canonical-docs/snappy-docs/pull/380>
<mup> PR snapd#4966 opened: interfaces/content: add rule so slot can access writable files at plug's mount point <Created by zyga> <https://github.com/snapcore/snapd/pull/4966>
<mup> PR snapd#4966 closed: interfaces/content: add rule so slot can access writable files at plug's mount point <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4966>
<mup> Bug #1575053 changed: Please move the "$HOME/snap" directory to a less obtrusive location <julyshakedown> <snapd:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1575053>
<mup> PR snapd#4967 opened: release: 2.32.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4967>
#snappy 2018-04-01
<wh00nixR59H2R> ââââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  voyohydla: tinwood ââââââââââââââââââ
<wh00nixR59H2R> ââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  zknjyuufnx: pjdc ââââââââââ
<wh00nixR59H2R> ââââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  xezxmuxl: seyeongkim ââââââââââââââââââââ
<wh00nixR59H2R> âââââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  qihhtabxv: cmars ââââââââââ
<wh00nixR59H2R> âââââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  uphmcpdmc: noise][1 ââââââââââââââââââ
<wh00nixR59H2R> âââââââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  lezxdgh: gouchi ââââââââââââââââââ
<wh00nixR59H2R> âââââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  isrjdqy: coreycb ââââââââââââââââââ
<wh00nixR59H2R> ââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  hmefg: d_ed âââââââââââââââ
<wh00nixR59H2R> ââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  wrywp: aimileus ââââââââââââââ
<wh00nixR59H2R> âââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  xpsuwb: coreycb ââââââââââ
<wh00nixR59H2R> ââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  kfoxybzixb: larreamikel[m] ââââââââââââââââââââ
<wh00nixR59H2R> ââââââââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  rwhcvy: gavinlin âââââââââââââââ
<wh00nixR59H2R> ââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  kbprozcg: devil__ ââââââââââââââââââ
<wh00nixR59H2R> ââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  upyzjx: deanman ââââââââââââââââ
<wh00nixR59H2R> âââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  xlbzmqtobs: luk3yx âââââââââââââââââ
<wh00nixR59H2R> ââââââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  wtdwafu: svij âââââââââââââââ
<wh00nixR59H2R> âââââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  jwystrhmua: Son_Goku ââââââââââââââââââââ
<wh00nixR59H2R> âââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  bacgqj: karlthane âââââââââââââââââ
<wh00nixR59H2R> ââââââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  dcxnqpq: enoch85 âââââââââââââââââââ
<wh00nixR59H2R> âââââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  xmiijtjxbc: kirkland âââââââââââââ
<wh00nixR59H2R> ââââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  bgvfho: kristbaum âââââââââââââââ
<wh00nixR59H2R> âââââââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  mtxsrsq: m4sk1n âââââââââââââââââ
<wh00nixR59H2R> ââââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  xdjxo: pcdummy ââââââââââââââââââ
<wh00nixR59H2R> ââââââââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  yfjqiouf: ejat âââââââââââââââââ
<wh00nixR59H2R> âââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  dfyzcrefg: tinwood ââââââââââââââââ
<wh00nixR59H2R> ââââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  xiayhvxh: ahasenack ââââââââââââââââââ
<wh00nixR59H2R> ââââââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  dvvuq: zoni ââââââââââââââââââââ
<wh00nixR59H2R> âââââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  yjlwmqpnl: itsfemme[m] âââââââââââââââ
<wh00nixR59H2R> âââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  ynycbnwker: pbek ââââââââââââââââ
<wh00nixR59H2R> ââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  fpgbzjbh: niemeyer âââââââââââââââââââ
ile (standard input) matches
#snappy 2019-03-25
<mborzecki> morning
<zyga> Hey mborzecki
<mborzecki> zyga: hey
<mborzecki> zyga: see you've had a productive weekend?
<zyga> Busy on my bije
<zyga> Bike
<zyga> I did 27km yesterday
<zyga> Other than that just house work :-)
<zyga> How was your weekend
<mborzecki> zyga: quite packed, didn't manage to do do anyting i planned, but did plenty of unplanned stuff
<mborzecki> zyga: oh, and finally was able to try the kimchi i made, turned out quite good :)
<zyga> This week is bug fix week for me
<zyga> Plenty of little things to resolve
<zyga> I will be in the office before 9:30, I still have one kid to handle and send to school
<mborzecki> btw. shouldn't we update the opensuse images to 15.1 now?
<zyga> Yeah
<mborzecki> again, 2019-03-25 06:27:04 Error preparing google:opensuse-15.0-64 :
<mborzecki> it'd gcc now, https://paste.ubuntu.com/p/KRpjVpwndT/ wtf?
<mborzecki> we're using zypper in -y, that should be non interactive
<mborzecki> maybe we should allow downgrades?
<mborzecki> mvo: morning
<mvo> hey mborzecki
<mborzecki> https://github.com/snapcore/snapd/pull/6644 simple PR <--- should fix opensuse package installs
<mborzecki> btw. github triggers don't work anymore?
<mvo> mborzecki: looking
<mvo> mborzecki: oh?
<mvo> mborzecki: how do you mean they don't work anymore? manual trigger? or travis picking up tests on changed prs?
<mborzecki> mvo: or just mup_ is silent
<mvo> mborzecki: aha, mup probably unhappy
<mvo> mup_: hi
<mvo> mborzecki: yeah, I think mup_ needs a restart, maybe niemeyer can restart mup for us :)
<pstolowski> morning
<mborzecki> pstolowski: hey
<zyga> back in the office
<zyga> how are you chaps?
<mvo> hey zyga and pstolowski
<mvo> zyga: good, good!
<mborzecki> https://status.opensuse.org/ says there is partial outage of mirroring infra, but it's nto clear what that means exactly
<mborzecki> isn't opensuse using metalink now?
<mvo> iirc yes
<mborzecki> ehh, so zypper times out on gcp, but works just fine locally, either a different mirror, or gcp has some caching behind the scenes
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6485/files#r268526837
<abeato> mvo, morning! is the fix for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728 in the core snap already?
<mborzecki> zyga: adding the file is too simple :)
<zyga> mborzecki: wrong coment
<zyga> mborzecki: the one at the top
<zyga> I'm not talking about the one 20 days ago
<mborzecki> ah, i see now
<mvo> abeato: it was initially, the backport of #8803 - however when we did a SRU validation we noticed that it breaks (segfaults) under some circumstance, this is an upstream bug and lead to PR#11121 which was a bit harder to backport. I just finished the xenial build and will now run the package against our autopkgtests, if that is successful I will push to the PPA and for the SRU
<mvo> abeato: sorry that it takes a bit, its delicate code and the "heart" of systemd (deeep in the job handling) so we are a bit cautious
<abeato> mvo, nw, indeed it is something to be very careful about, thanks
<mvo> abeato: do you already get asked? I will update the bug with the info here
<mborzecki> zyga: hm maybe i should just drop that last commit, too many things to check to find out whether snapd or core is used, extracting directly from source does away with all this
<abeato> mvo, not yet, but maybe today they were going to ask, so I wanted to know the current status
<zyga> mborzecki: shall we prototype "snap tool snap-{confine,seccomp,discard-ns}
<zyga> I would love not to have to source dirs.sh
<mvo> abeato: yeah, the updated debdiff for xenial should be in the SRU bug today and I think we will push it to the "edge" core snap for testing
<abeato> mvo, nice!
<mborzecki> zyga: would that work reliably with core.experimental.snapd-snap?
<mvo> abeato: I will also test i386 with spread, for 8803 this was the one where the segv manifested itself
<mborzecki> hmmm https://forum.snapcraft.io/t/gadget-snaps-for-mtd-devices/10554
<zyga> mborzecki: I saw that
<abeato> hm, interesting that it was in i386, was that second issue something provoked by the first change or something completely unrelated?
<zyga> afaik not supported :/
<mborzecki> zyga: yeah, we had a similar issue with mender, started with just block device support, but then people came asking for mtd
<zyga> the only way I would see this work is ubifs or something simialar to map mdt to block devices
<mborzecki> mhm
<mborzecki> even some of the implicit structure labels would make sense if aplied to volumes
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/6629#pullrequestreview-218199245
<pstolowski> zyga: ty!
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6634#issuecomment-476095124
<mborzecki> arrrgh Package glibc-32bit-2.26-lp150.11.9.1.x86_64 (openSUSE-Leap-15.0-Update) seems to be corrupted during transfer. Do you want to retry retrieval?
<pedronis> pstolowski: hi, I had to contracdict a comment zyga made in 6629
<pstolowski> pedronis: just saw it, sure, thanks!
 * Chipaca â more coffee
 * tobias_ says hi
<thresh> Wimpress, ping rpi & vlc
<Wimpress> thresh: o/
<Wimpress> Building VLC for the Pi requires two things.
<mborzecki> just me or does github feel slow adding comments today?
<Wimpress> libraspberry-dev and libraspberry0, only available for armhf.
<Wimpress> And the MMAL patches for VLC, which currently only available for VLC 3.0.6
<thresh> that's weird it needs patches, since we do ship mmal in the code
<thresh> in 3.0, that is, and in 4.0 (the upcoming version)
<Wimpress> thresh: Patches are here - https://github.com/RPi-Distro/vlc in debian/patches
<thresh> that's a big patch
<Wimpress> Yep.
<niemeyer> mvo: I'm off today, but will give mup some love when I get back home later today
<niemeyer> sorry for the trouble there
<mvo> niemeyer: thank you and sorry for bothering you on your day off
<niemeyer> mvo: np, thanks for letting me know
<dot-tobias> What's the best way to debug snap hooks? I'm adding some commands to a post-install hook and would like to identify thinkos or unexpected errors without the whole âinstall old rev, build new rev, install new rev, repeatâ. I found âsnap run --hookâ, but since my hook contains âsnapctl stop --disable my-snap.my-serviceâ, it complains about âunknown flag: disableâ. I presume it's something to do how the hook is called by
<dot-tobias>  âsnap runâ, the same command in my install hook runs without complaints.
<Chipaca> dot-tobias: it looks like snapctl stop doesn't have a --disable
<Chipaca> the help might be wrong though
 * Chipaca looks inside
<Chipaca> ah look at that, it does
<dot-tobias> Chipaca: That's what I've been wondering as well (comparing âsnapctl helpâ with âsnap help stopâ), got it from here: https://forum.snapcraft.io/t/support-for-snapctl-stop-start-restart-services/1908/17?u=tobias
<dot-tobias> And the disable flag works fine in an install hook; presumably as well in the post-refresh â just throws the error if called with âsnap run --hook=post-refresh my-snapâ
<dot-tobias> Chipaca: And if I interpret https://github.com/snapcore/snapd/pull/5777 correctly, the fix that keeps disabled services disabled after refresh is not in yet, right?
<Chipaca> correct
<zyga> pstolowski: https://bugs.launchpad.net/snapd/+bug/1606674 is something you could assign to yourself
<dot-tobias> Chipaca: As for my initial question, just figured out that I can run âsnap tryâ over an already mounted try snap and it will run like a refresh â including hooks. The snapctl command works fine with --disable.
<zyga> pstolowski: the serial port hotplug work seems like good test case for desktop users
<Chipaca> dot-tobias: 'run --hook' is internal, AFAIK without the context setting up that's done by snapd before calling it, things will fail
<Chipaca> dot-tobias: but yes both 'snap try' and 'snap install --dangerous ./some-local.snap' are actually refreshes
<Chipaca> dot-tobias: i mean of a previously installed thing with the same name
<dot-tobias> Chipaca: Noted ð http://www.addletters.com/pictures/bart-simpson-generator/bart-simpson-generator.php?line=I+won%27t+assume+undocumented+CLI+flags+are+always+public.
<Chipaca> dot-tobias: undocumented are probably fine; undocumented and explicitly hidden, are â¦ who knows :-)
<Chipaca> OTOH the completion thing doesn't hide hidden flags
<Chipaca> â¦ or does it
 * Chipaca checks
<zyga> mborzecki: perhaps something you can update https://bugs.launchpad.net/snapd/+bug/1750872 :)
<mborzecki> haha
 * zyga mvo: this is probably fixed now, right? https://bugs.launchpad.net/snapd/+bug/1791182
<Chipaca> mborzecki: an excellent opportunity to use "whelm"
 * zyga pstolowski: wasn't this fixed already? https://bugs.launchpad.net/snapd/+bug/1806447
<thresh> Wimpress, doesnt look mergeable in such a form, I mean thousands lines of code, copied avcodec.c plugin, zero commit logs...
<thresh> maybe if split properly, and submitted by someone who cares and who wrote it, we can go forward
<mvo> zyga: yes, I think this is fixed
<zyga> mvo: should I update it or will you?
 * zyga Chipaca: UX bug on snap info: https://bugs.launchpad.net/snappy/+bug/1814971 I believe this should be fixed now?
 * zyga pstolowski: I believe this is fixed now, right? https://bugs.launchpad.net/snappy/+bug/1812751
<mvo> zyga: please do
<zyga> sure
<Chipaca> zyga: fixed how?
<zyga> Chipaca: isatty vs pipe
<zyga> the arrows become ^ when piped
<zyga> so ... parsable )
<zyga> :)
<Chipaca> zyga: that's not what that bug is about
<Chipaca> it even mentions carets as equivalently unparsable
<zyga> ah, I see now
<Chipaca> and I agree, the channel map is not meant to be parseable
<Chipaca> (the bug calls them carrots, which I refuse to edit)
<MattJ> :)
<zyga> thanks, I'll leave it as is
<Chipaca> zyga: in fact just last week I was saying "yeah that is not meant to be parseable really"
<Chipaca> or words to that effect
<pedronis> Chipaca: yes, the only solution to that bug is --format
<Chipaca> or talk-to-the-hand^Wsocket
<Wimpress> thresh: I was in a meeting.
<Chipaca> talking to the socket is really not hard nor unfriendly
<Wimpress> thresh: I have good contacts at the Raspberry Pi Foundation. I'll see if I can get them to submit clean PRs upstream.
<zyga> we have a loooot of bugs to go through
<Chipaca> zyga: https://forum.snapcraft.io/t/use-of-snap-command-line-in-scripts-other-programs/10471/2 fwiw
 * Chipaca hugs zyga 
 * zyga looks
 * zyga hugs Chipaca back :)
<Chipaca> zyga: we don't have bugs! we have â¦ features that are trying their best
<thresh> Wimpress, np, and thanks!
<pstolowski> zyga: i've updated the two bugs you asked (both fixed)
<zyga> pstolowski: super, thank you!
<zyga> mborzecki: a small bug you could assign to yourself for tracking
<zyga> mborzecki: https://bugs.launchpad.net/snappy/+bug/1574103
<zyga> I think your work will fix it
<zyga> pstolowski: does this ring a bell? I recall something similar happening recently: https://bugs.launchpad.net/snappy/+bug/1805170
<zyga> degville: a typo in docs, probably stale by now but perhaps you can have a quick look? https://bugs.launchpad.net/snapd/+bug/1801735
<pstolowski> zyga: yes, we've been considering enhancing snapctl to show changed values for current transaction. no concrete plan as far as snapctl is concerned. should be easy to add
<degville> zyga: yep, of course - looking now.
<mvo> hey degville! nice to see you :)
<degville> mvo: thanks! good to be back :)
<pedronis> Chipaca: some small comments on 6635
<mborzecki> so the opensuse install fix PR did not fail on opensuse, but this failed instead: https://paste.ubuntu.com/p/XWMd4vMGVw/
<mborzecki> isn't there a ticket about that?
 * pstolowski lunch
<zyga> mborzecki: yes, mvo is working on that
<zyga> mvo: https://bugs.launchpad.net/snapd/+bug/1769669 looks like something that was fixed now, shall I mark it as such?
<zyga> (at least based on the forum chatter)
<Chipaca> pedronis: on it
<mvo> zyga: yeah, this should be more robust now
<zyga> mvo: shall I close the bug?
<mvo> zyga: +1
<zyga> mvo: halp
<zyga> mvo: do we have a regression?
<zyga> https://www.irccloud.com/pastebin/8c8TlMgh/
<zyga> --extrausers broke on core
<zyga> (core16)
<mvo> zyga: this is edge? let me check
<mborzecki> zyga: i'm guesing this is where it broke https://people.canonical.com/~mvo/core-changes/html/edge/2.38r6678_2.38+git1203.52b6d65~ubuntu16.04.1r6685.html
<zyga> mvo: that's the critical pr that fixes master
<zyga> mvo: from maciej
<mvo> mborzecki: indeed
<mvo> zyga: yeah on it
<zyga> mborzecki: when exactly?
<mborzecki> 6673 seem sok
<mborzecki> seems ok
<zyga> mborzecki: before 1:4.2-3.1ubuntu5.4
<zyga> (version from hell)
<mvo> zyga: let me sort this out
<zyga> super, thank you!
<mvo> zyga: there must be some confusion, my original SRU added all the missing patches :/
<zyga> yeah
<zyga> that's why I'm puzzled
<zyga> maybe CVE fix dropped them?
<mvo> zyga: anyway, fix should be there soon
<zyga> or maybe image ppa woe?
<zyga> I don't get it
<mvo> zyga: I think the PPA is confused, I manually uploaded a no-change version to hopefully fix it
<mvo> zyga: this version was briefly in ppa:snappy-dev/image but then I removed it again because I wanted to SRU the full version with all pending changes to the real archive instead of the PPA (I did that on friday but iirc no sru review yet)
<mvo> zyga: anyway, hopefully a gentle kick will fix it
<mborzecki> ok, so this, then opensuse branch, then merge master to the PRs and we can finally start seeing some green :P
<zyga> mvo: ideally the fix is that the main version in the archive is ok
<zyga> mvo: and we can drop this from the ppa forever
<Chipaca> mborzecki: things are broken right now?
 * Chipaca was about to push
<mborzecki> Chipaca: yeah
<zyga> mvo: shadow failed to upload in the snappy-dev/ubuntu/image ppa just now
<zyga> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/16527935
<Chipaca> mborzecki: I'll hold back then :-)
<Chipaca> maybe i should have lunch
<pedronis> pstolowski: I mand an high-level remark in 6629
<pedronis> *made
<mvo> zyga: yeah, its more confused, I uploaded anohter fix
<mvo> zyga: main archive>yeah, I was working on exactly that, i.e. SRU our two pending patches plus the new userdel one
<mvo> zyga: its iirc in unapproved
<zyga> mvo: there's a thing I need to discuss with you
<zyga> mvo: maybe after you are done with this you could give me a ping?
<mvo> zyga: https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text= (fwiw)
<mvo> zyga: we can talk in ~2min, just want to double check the build and then trigger core rebuild
<mvo> zyga: I'm in the standup channel
<zyga> joining
<pstolowski> pedronis: thanks
<mvo> new core build triggered, should be ready in some minutes with fixed useradd
<cachio> Chipaca, hey
<Chipaca> cachio: 'sup
<cachio> I am testing the core revert test
<Chipaca> cachio: ok
<cachio> perhaps you can help me
<cachio> after I refresh the core snap
<cachio> it cannot make a snap refresh
<Chipaca> did it reboot after refreshing?
<cachio> I see an error like https://paste.ubuntu.com/p/nJkkcVhVWy/
<Chipaca> cachio: is this on core, or on classic?
<cachio> yes
<cachio> it is core
<cachio> core 16
<Chipaca> cachio: ah, that looks like a network issue
<cachio> could it be related to the catalog refresh?
<Chipaca> cachio: what's in the log? (is it running with DEBUG_SNAPD_HTTP)
<Chipaca> or was it SNAPD_DEBUG_HTTP
<cachio> I added core to ping api.snapcraft.io before make the refresh
<cachio> and it can reach the endpoint
<Chipaca> the logs should have more info about what's going on
<Chipaca> if debug is on
<cachio> it I wait like a minute the snap refresh command does not fail anymore
<cachio> I'll add the debug in that case
<Chipaca> cachio: you're not running with SNAPD_DEBUG already?
<cachio> no
<cachio> Chipaca, the test is running in a vm inside other vm in google
<cachio> Chipaca, it is part of the nested test suite
<Chipaca> cachio: what's in the logs _without_ debug?
<Chipaca> or does the vm die
<cachio> it is running without debug beacuse I test the core which I get from edge
<cachio> on that suite
<Chipaca> cachio: but can you get the logs?
<cachio> Chipaca, yes
<Chipaca> cachio: please do
<Chipaca> cachio: even without debug there might be something useful
<cachio> Chipaca, I am running again the test
<cachio> I'll have the logs in 5 minutes
<pstolowski> cachio: hey, #6491 fails repeatedly on google:ubuntu-14.04-64:tests/main/interfaces-daemon-notify and it's unclear why (it's completely unrelated to the PR); do you have a moment to help with that?
<cachio> pstolowski, hi, checking
<mborzecki> off to pick up the kids
<cachio> pstolowski, I see errors related to opensuse which I am trying to fix
<cachio> pstolowski, I think best is disable it until the solution is in place
<pstolowski> cachio: yes, this time opensuse failed as well. but the problem is that test i mentioned, it failed many times in a row
<cachio> I am executing it now
<cachio> seems to be something new
<cachio> pstolowski, I am trying to reproduce it here
<pstolowski> cachio: ta! it seems something with journal cursor? but it's unclear why it's failing on the PR which adds this nested vm test
<cachio> pstolowski, it is not related to your change
<cachio> Chipaca, the logs are not good :( https://paste.ubuntu.com/p/GFtrm7TWYf/
<Chipaca> cachio: sigh
<cachio> I have a debug session on that machine
<cachio> could I get something else?
<Chipaca> cachio: if you do the refresh agian does it work?
<pedronis> cachio: both mvo and me made some comments in 6625
<cachio> Chipaca, yes
<Chipaca> cachio: sounds like actual network hiccup, then
<Chipaca> cachio: can you turn on debug permanently in the nested tests? (you can do it by just adding a file)
<cachio> pedronis, I saw those, I'll answer and start a new test for ssh config
<cachio> Chipaca, Environment=SNAPD_DEBUG_HTTP=7 SNAPD_DEBUG=1 is ok for the configÂ¡
<cachio> ?
<Chipaca> cachio: yes
<Chipaca> cachio: it goes in a [Service] section
<cachio> Chipaca, /etc/systemd/system/snapd.service.d/local.conf ?
<Chipaca> cachio: y
<cachio> niemeyer, hey, could you please take a look to https://github.com/snapcore/spread/pull/75
<zyga> pedronis: can you ack / change https://github.com/snapcore/snapd/pull/6636#discussion_r268661433 after the call please?
<pedronis> zyga: done
<mborzecki> cachio: https://github.com/snapcore/snapd/pull/6644
<cachio> mborzecki, I'll try that
<cachio> thanks
<cachio> Chipaca, https://paste.ubuntu.com/p/Dw4vPh9PpY/
<cachio> Chipaca, api.snapcraft.io works before make snap refresh
<zyga> I need to grab lunch and maybe exercise a bit, I will be back later
<mborzecki> off to pick up the kids
<mborzecki> damn, wrong terminal
<niemeyer> cachio: Heya
<niemeyer> Will look tomorrow.. off today
<mborzecki> mvo: restarted #6644 too early probably as it failed with --extrausers again, running it again
<Chipaca> cachio: it looks like the network wasn't fully up?
<Chipaca> cachio: dns was failing at 14:22:19, and still at 14:22:23, then that came up by 14:22:24 but still not healthy
<mvo> mborzecki: ok
<Chipaca> cachio: how are you testing you can reach api.snapcraft.io?
<cachio> Chipaca, https://paste.ubuntu.com/p/KKHXZgxJCm/
<cachio> Chipaca, does it make sense?
<Chipaca> cachio: the output of 'snap debug connectivity' would be helpful, if you could
<Chipaca> cachio: and you could 'while ! snap debug connectivity; do sleep 1; done'
<cachio> Chipaca, https://paste.ubuntu.com/p/3JfKfZb4wc/
<cachio> this is what I have
<cachio> I could print all the output, but I need to rexecute
<Chipaca> cachio: I mean, with what you have, my veredict is the network had a hiccup
<Chipaca> cachio: it happening every time makes me think it's actually something in the vm that hasn't finished coming up
<Chipaca> cachio: but I don't know
<cachio> Chipaca, ok, makes sense
<cachio> I'll try to install a snap and see if it works or fail
<mborzecki> mvo: fwiw, i ran google:ubuntu-core-16-64:tests/main/ubuntu-core-create-user separately now, so i expect #6644 to be green this time :)
<mvo> mborzecki: cool
<cachio> mborzecki, seems to work well the change for opensuse
<cachio> I'm updating the image now
<cachio> in this case we dont need to diable opensuse
<mborzecki> 6644 landed
<Chipaca> mborzecki: is that the fix-all-the-things one?
<pedronis> zyga: there's a conflict as well in #6636
<mborzecki> Chipaca: yeah, it should make things green again
 * cachio lunch
 * zyga returned home, rain + bike != fun
<Chipaca> zyga: not with that attitude
<zyga> pedronis: does https://github.com/snapcore/snapd/pull/6636 look good now or do you want to see some changes around the go part?
<zyga> ups, bad push :/
<pedronis> zyga: I need to go have a walk, will look when I'm back
<zyga> ok
<mvo> zyga: 6642 has conflicts now
<Chipaca> pedronis: wrt common-id search, should I make it reject q+cid searches?
<zyga> mvo: yes, expected
<zyga> I just fixed the base branch
<mvo> ta
<zyga> I need to mend the network again
<zyga> time to actually connect that backup modem I have
<zyga> brb
<zyga> I need a 2nd review for https://github.com/snapcore/snapd/pull/6597
<zyga> mvo, mborzecki ^
<cachio> pedronis, hey, #6625 updated
<cachio> but it fails with ssh.disable: true
<cachio> pedronis, is it expected, right?
<mvo> zyga: I can check tomorrow, need to play hockey soon(ish) :)
<zyga> sure
<mborzecki> heh, so now spread jobs hit the travis time limits
<cachio> mborzecki, do you have a linkÂ¡
 * Chipaca knows cachio's keyboard layout, and hates it
<cachio> :)
<Chipaca> https://www.dsi-keyboards.com/wp-content/uploads/2015/03/KA-Latin-American-20867.jpg
<Chipaca> hate hate hate
<Chipaca> how can you program on that
<Chipaca> :-)
<Chipaca> having the logical not right there is cool tho
<cachio> Chipaca, I don't know, well perhaps because I use it since long time :):)
<Chipaca> cachio: obvs :-)
<Chipaca> i just never could get used to it
<cachio> Chipaca, I used to work for argentinian clients
<cachio> Chipaca, I needed the Ã±
<cachio> Chipaca, :)
<Chipaca> cachio: i'm still upset there never was ubuntu Ã±oÃ±o Ã±andÃº
<cachio> Chipaca, and i also used to share the computer with my wife
<Chipaca> cachio: my condolences
<cachio> hehehe
<Chipaca> anyhoo, back to breaking stuff
<Chipaca> actually, no
<Chipaca> i'm going for a walk before the sunshine goes
 * Chipaca afk
<pedronis> cachio: actually, not, I thought it would work with recent code changes, we'll need to dig
<pedronis> Chipaca: I don't have a strong opinion, do we think the store will drop support for that? on our side it's easier to add things than to remove them
<pedronis> which is an argument to not allow it unless there's a strong use case
<Chipaca> pedronis: yeah, that's what i was thinking, particularly with rob saying they're not goingt o use it
<Chipaca> I'll drop support for the combo
<Chipaca> but first i'll walk
 * Chipaca really afk now
<cachio> pedronis, this is the output https://paste.ubuntu.com/p/KbxSxbYGZP/
<pedronis> cachio: that is weird,  we probably need pstolowski to help debug that
<cachio> pedronis, this ire the defaults that we use
<cachio> https://github.com/snapcore/snapd/blob/8c8af3731b6feeb781bb477208c526755ac435a3/tests/main/ubuntu-core-gadget-config-defaults/gadget-ssh-oneline.yaml
<cachio> pedronis, is it ok?
<pedronis> cachio: yes, it was asked, we'll discuss tomorrow with pstolowski
<pedronis> sorry, it is what I asked
<cachio> pedronis, nice
<pstolowski> Im afk, will check tomorrow morning
<cachio> pedronis, thanks
 * zyga EODs
<zyga> cachio, pedronis: feels like missing path in handleServiceDisableConfiguration, specifically when output is ""
<cachio> zyga, nice, thanks for take a look to that
<juliank> I finally decided to start building the apt snap: https://paste.ubuntu.com/p/XvgPpKGgqQ/ :D
<juliank> I think I had a problem with an unclean rebuild in between, as the apt snap ended up with
<juliank> E: The method driver /apt/lib/apt/methods/mirror+file could not be found.
<juliank> but let's see what the next revision brings
<juliank> Hmm, so it builds the snap to install to the snap's /, but then apt looks up methods in /lib/apt, when it should be looking in /snap/apt/<id>/lib/apt
<juliank> so I guess I can specify - -DCMAKE_INSTALL_LIBEXECDIR=/snap/apt/current but I'd like the id instead of current
 * cachio afk
<juliank> How do other classic snaps handle running helpers from their own libexecdir?
<zyga> jdstrand: updated https://github.com/snapcore/snapd/pull/6642
<zyga> jdstrand: I kept the permission as they were, I will discuss this with pedronis tomorrow
<zyga> jdstrand: but everything else should be good now
 * zyga really EOD now
<zyga> juliank: that's not an ID
<zyga> juliank: that's a revision that changes  with each build
<jdstrand> zyga: ack, thanks
<juliank> zyga: well, yes
<juliank> zyga: that's where it should look for its helper programs
<juliank> Currently I'm snapping a caldav server, but I don't feel safe having the root daemon, so I think maybe not ship a daemon, and just the command in the snap. oh well...
<pgnd> I've installed snapd on Opensuse, per instructions here: https://forum.snapcraft.io/t/installing-snap-on-opensuse/8375
<pgnd> There, degville mentions the need to "systemctl enable snapd.apparmor".
<pgnd> Afaict, there's no such service installed ...  Is that^^ still current instruction, and a dep has changed?
#snappy 2019-03-26
<zyga> mvo: good morning
<zyga> fun test failure
<zyga> no  void  directory on core18 https://www.irccloud.com/pastebin/hjyPHGW5/
<mvo> zyga: uh, fun indeed
<mvo> zyga: and easy to fix
<mvo> zyga: thanks for finding this!
<zyga> mvo: so
<zyga> mvo: I have a problem
<zyga> mvo: how  do we  fix this?
<zyga> by hacking core18/
<zyga> mvo: can we create a package that is designed for core18-like systems?
<zyga> mvo: that has the right  startup core and mounting points
<zyga> mvo: I would rather not have this conversation in core20
<mvo> zyga: I would add it to the build tree of UC18, this will become the build tree of UC20
<zyga> mvo: if we make the right package it will be simply inistalled in core18 systems and that will be enough
<zyga> mvo: add it how? I'm arguing that it should be a standalone package built out of  snapd source package, that is then installed in core18 system
<mvo> zyga: yeah, it could be snap-skeleton-dirs or something but I'm not sure this is more robust, we might also forgot add things there instead of in the main snapd package just like we could forgot adding things to the UC18/uc20 snaps. or do you have something different in midn?
<mvo> mind
<zyga> mvo: we can very well  forget but if we fix it the fix goes to core16, core18 and core20
<zyga> mvo: in one patch
<zyga> mvo: and it would be in the snapd repo, not somewhere else
<mvo> zyga: how would that look like in pratcise? what would the package be called and what would the dependencies be?
<zyga> mvo: it  would not depend on anything but it  would conflict with snapd.deb
<zyga> mvo: the name is irrelevant, maybe  snapd-bootstrap-and-skeleton?
<zyga> mvo: it would ship /var/lib/snapd structure, the /bin/snap symlink, the /usr/lib/snapd mount point and perhaps your bootstrap script
<zyga> mvo: (anything appropriate)
<mvo> zyga: it would be separate from the main package snapd which (afaics) has the same risk of getting our of getting out of sync. maybe we pull something from snapd git in to create the dirs/perms and use exactly this in the main snapd package build(s)?
<zyga> mvo: hmm?
<zyga> mvo: the snapd source package would have snapd.deb  binary package and snapd-skeleton.deb binary (arch all) package
<zyga> mvo: is that sufficient or do I misundertand your worry?
<zyga> *misunderstand
 * zyga preps breakfast for kids, responses may be slower
<mvo> zyga: snapd/snapd-skeleton may get out of sync if we are not careful
<mvo> zyga: because we add a new dir (or something) to snapd but forget to add it to snapd-skeleton
<mvo> zyga: so we need something that ensures that this can't happen, one way would be to use a makefile/script/whatever as part of the snapd package build and use exactly the same script as part of the uc18/uc20 build
<mvo> zyga: alternatively we could create some of these missing dirs ourselfs maybe? /var/lib/snapd is fully writable
<mvo> zyga: (create them if missing)
<mvo> zyga: I actually like this as it means its easier if people try to run snapd from a snapd git checkout etc (slightly easier I admit :)
<mborzecki> morning
<mborzecki> wow, some prs are actually green
<zyga> hmmm
<zyga> I'm not sure
<mborzecki> zyga: hey
<zyga> this shoud run before  snap
<zyga> before snapd
<mvo> hey mborzecki
<mborzecki> mvo: hey
<mborzecki> zyga: idk if you noticed, but there's quite a few directories missing under /var/lib/snapd between core and core18
<mvo> mborzecki: yeah, zyga and I discussed ways to fix this, zyga had some ideas how to make sure we have the layout inside our tree somehow so that its used in uc18/uc20 and we are exploring which one is the best
<zyga> funny that we noticed just now
<mborzecki> in most cases those are created on demand
<mvo> yeah, I think on demand-creation is a nice way out of this
<mvo> and it has the advantage of making it easy to run from e.g. checkouts
<mvo> but *shrug* there are downsides too
<zyga> mvo: I don't disagree in principle but not everything can be created on demand
<mborzecki> iirc void has some special permissions too, so this would have to be accounted for when we create it on the fly
<zyga> mborzecki: can you do a 2nd review on https://github.com/snapcore/snapd/pull/6645 please?
<mborzecki> haha looking at it just now :)
<zyga> thank you :)
<zyga> I want the rush of adrenalin from landing a PR
<mborzecki> still, suprising usb.ids doesn't list oneplus
<zyga> maybe it's a fake request?
<mborzecki> zyga: no, i found some pages describing the process of getting oneplus working on linux and they list the same vendor id
<zyga> aha, that's a good find
 * zyga reviews https://github.com/snapcore/snapd/pull/6634
<mvo> mborzecki: silly question - what is needed for 6606 ? a second review or is there more ?
<mborzecki> mvo: 2nd review
<mborzecki> zyga: added some links under 6645 in case you're curious, there's even a patch from lineageos
<zyga> mborzecki: looking
<mvo> mborzecki: thanks, maybe pstolowski can do a second review on 6606, it looks pretty much ready to me
<mvo> mborzecki: added my .0002Â¢ I think its fine but would feel better if pstolowski  could do  a final pass on 6606
<mborzecki> mvo: thanks!
<zyga> brb, coffee
<zyga> https://github.com/snapcore/snapd/pull/6597 <- 2nd review needed in case someone wants to look
<mvo> just a quick service announcement - we have an updated systemd in the edge core with a race fix, if anyone notices anything strange in the tests related to systemd please shout
<mvo> zyga: I can look
<zyga> mvo: thank you
<zyga> mvo: alternatively look at https://github.com/snapcore/snapd/pull/6621/files
<zyga> it's much smaller
<zyga> and more on the critical path
<zyga> mvo: ack, about systemd, thank you for that!
<mvo> zyga: ha! thanks, I take 6621 I think :)
<mvo> zyga: the other one is *big* it seem
<mvo> zyga: hopefully both, but for that I need more tea
<zyga> yeah, this one is very small, just tests and a few lines of new code
<mvo> pedronis: do you want to review 6630 again (snap warnings yamlish) or can I merge? john addressed your review points
<pstolowski> morning
<mvo> pstolowski: good morning!
<mborzecki> pstolowski: heya
 * dot-tobias says hi
<pedronis> mvo: hi, please merge
<mvo> pedronis: ta
<abeato> ppisati, morning!
<abeato> ppisati, which is the apparmor status for 4.9 kernels? Is there any patch needed to run ubuntu core/snapd with it?
<ppisati> abeato: not that i'm aware
<zyga>  mvo I will merge 6605 after adding the extra comment
<ppisati> abeato: *none, that i'm aware of
<zyga> mvo: just wrapping up a small new branch you asked for
<zyga> mvo: thank you for the review!
<abeato> ppisati, ok, thanks
<pstolowski> pedronis: i've debugged the ssh.disabled issue
<mvo> zyga: ta
<pstolowski> pedronis: we don't support dotted notation at the nested level of the defaults definition, we expand dotted path at the root level only, e.g. that would work (works in a unit test i made):
<pstolowski> defaults:
<pstolowski>   test-snap-ididididididididididid:
<pstolowski>       service.ssh.disabled: true
<pedronis> pstolowski: it sounds like we should error or do something though ?
<pedronis> we don't support dots in name in principle?
<pedronis> pstolowski: where is ther relevant code?
<pstolowski> pedronis: and consequently, with the config that Sergio created you end up with unexpanded key in the config: map[string]interface {}{"ssh.disabled":true}
<pedronis> yea, that looks wrong
<pstolowski> pedronis: also, this works fine in unit test:
<pstolowski> defaults:
<pstolowski>   test-snap-ididididididididididid:
<pstolowski>       service:
<pstolowski>           ssh:
<pstolowski>               disabled: true
<pedronis> that I know
<pstolowski> pedronis: we do support dots in name, but it needs to start at the root level. you cannot define map and then have dotted path deep inside
<pedronis> pstolowski: I understand, you said it already
<pstolowski> and yes we should error out i suppose
<pedronis> yes,  "ssh.disabled" should't be a valid key
<pedronis> we should not get there
<pstolowski> let me see if i can find where it happens exactly in the code
<zyga> mvo: https://github.com/snapcore/snapd/pull/6650 :-)
<pedronis> zyga: shouldn't we try to land 6583 first?
<pstolowski> pedronis: i think the important bit is the "for key, value := range patch" loop in func (h *configureHandler) Before(). we call tr.Set there for top-level patch entries, but inside transaction's Set we only ParseKey once (for that top level)
<pedronis> pstolowski: so we are missing a check for dots in key (where unexpected) somewhere?
<zyga> pedronis: I will be working on that today
<pedronis> zyga: you have 17 open PRs , that's not a feature :)
<zyga> pedronis: I know but many of them are very close to landing
<pedronis> zyga: then please try to land before opening new ones
<pedronis> or I will start to close new ones
<zyga> pedronis: with regards to landing: we need a decision on what to do here https://github.com/snapcore/snapd/pull/6642#discussion_r268780713
<pedronis> zyga: I agree with jdstrand if there's a way to keep it working without security issues it's better, we have been bitten already by taking stuff away from people
<zyga> pedronis: so moving to void if we cannot stay in the current directory due to permission checks?
<pedronis> yes
<zyga> ok, I'll make the change
<zyga> thanks, can you add a comment saying that in the PR, it will be easier for jamie to see
<pedronis> done
<zyga> Thanks
<pstolowski> pedronis: yes, you could say that. i think we could support that in PatchConfig, although the fix is not immediately obvious
<pedronis> pstolowski: anyway is not quite a priority right now, but we should plan to do something at some point
<pstolowski> pedronis: ack
<pedronis> pstolowski: I'm also not sure if it's better to error or to make it work
<pedronis> (but splitting on dot9
<pedronis> (by splitting on dots)
<pedronis> mvo: do we use the standup ?
<zyga> pedronis: https://github.com/snapcore/snapd/pull/6649 is a low hanging fruit
<pedronis> ok
<pedronis> degville: do you know where the meeting is?
<degville> pedronis: nope. standup location? mvo is running a little late.
<zyga> https://forum.snapcraft.io/t/ubuntu-18-04-fresh-install-default-snaps-are-updated-but-runtime-isnt/10579 this is interesting in a bad way
<mborzecki> damn, Failed for "golang.org/x/crypto/cast5" (failed to clone repo): exit status 128
<mborzecki> shal we land https://github.com/snapcore/snapd/pull/6623 ?
<pedronis> mborzecki: seems so
<mborzecki> it's sufficiently ripe :)
<pedronis> it has a jdstrand +1  and other reviews
<pedronis> at some point it sounded it needed to touch snap-confine, but is not the case
<mborzecki> landed
<zyga> eh
<zyga> my tests also failed
<zyga> 50 minutes of wasted time
<zyga> fatal: unable to access 'https://go.googlesource.com/crypto/': Failed to connect to 2607:f8b0:400c:c06::52: Network is unreachable
<zyga> this is why we need spread --fail-fast
<zyga> this just sucks
 * Chipaca hates all of the interfaces-many- spread tests
<pstolowski> zyga: +1
<niemeyer> mup_: So.. what's up with you?
<niemeyer> mup: How're you doing now?
<mup> niemeyer: I apologize, but I'm pretty strict about only responding to known commands.
<mborzecki> 2019-03-26 10:33:46 Cannot allocate google:debian-sid-64: cannot perform Google request: Get https://www.googleapis.com/compute/v1/projects/computeengine/zones: oauth2: cannot fetch token: Post https://accounts.google.com/o/oauth2/token: dial tcp 74.125.126.84:443: i/o timeout
<mborzecki> hmmm
<mborzecki> gcp broke?
<Chipaca> mborzecki: nevah!
<Chipaca> also, spread takes too long, so: while true; do printf "\u$(printf "%x" $((0x2571 + RANDOM%2)))"; done
<mborzecki> heh, and i got into a little mess with the 'gadget' package, some code is on review right now, and merging the branches breaks all of it :P
<mborzecki> aand another job hit the time limit
<mborzecki> it's quite intersting, so prepare fails on some nodes because golang.org is flaky and times out, then the nodes that actually made it execute all the tests and the job hits travis time limits
<mborzecki> maybe it's because of https://twitter.com/MehreenKhn/status/1110509604176384000
 * zyga goes to the doctor
<zyga> ttyl
<mup> PR snapcraft#2515 closed: build providers: support for provider setup <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2515>
<Chipaca> mvo: question about the snapd snap when you have a bit
<cachio> pstolowski, https://api.travis-ci.org/v3/job/511064184/log.txt
<Chipaca> mvo: the question is whether building with snapcraft from the snap (instead of from the deb), and adding -b -Zgzip to the dpkg-buildpackage in the plugin, make sense to you
<cachio> this is the log for the ssh.disable: true
<Chipaca> mvo: the first is because otherwise it leaves behind a bunch of packages that break the invariant
<Chipaca> mvo: the second is because 300s â 90s
<Chipaca> mvo: (I could just change the first, the second is merely opportunistic)
<pstolowski> cachio: i know, i debugged it in the morning and discussed with pedronis; we don't currently support dotted paths nested deep inside defaults; it would work only from top-level, e.g. service.ssh.disabled: true. we should at the very least provide a meaningful error message or make it smarter
<mvo> Chipaca: +1 on the second, I'm not fully getting the first one, sorry (probably a bit slow today)
<pstolowski> cachio: btw i think it found the cause of interfaces-daemon-notify failure in my nested vm PR; i think it fails because of "plan: n1-standard-2" (?!); i run this single test a couple of times today with and without this change (also with just master) and it seems to be it. if that plan is enabled, then "journalctl -u snap.test-snapd-daemon-notify.notify.service" that we execute at the end of the test doesn't return any
<pstolowski> output for that service. i debugged this manually and when it fails, system log has the expected "Permission denied" errors in it, it's just not reported by journalctl for whatever reasons. systemd/journalctl versions appear to be the same both with and without that plan.
<pstolowski> i've juse reverted this plan from https://github.com/snapcore/snapd/pull/6491 and it passed
<mup> PR #6491: interfaces: hotplug nested vm test, updated serial-port interface <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6491>
<pstolowski> pedronis: ^ is green
<pedronis> cachio: I'll comment in the PR when I have a bit of time today
<pedronis> (about ssh.disable)
<Chipaca> mvo: only builds the binary deb, uses gzip to compress it (instead of also building source and using xz)
<Chipaca> mvo: oh wait
<Chipaca> mvo: the first one, changing deb for snap, because 'apt install snapcraft" pulls in e.g. python3-crypto, which autoremove can't
<Chipaca> can't autoremove i mean
<Chipaca> because things recommend it or maybe suggest it i guess
<cachio> pstolowski, which is the PR?
<mvo> Chipaca: +1
<cachio> pedronis, thanks
<mvo> Chipaca: oh, so "snap install snapcraft"?
<Chipaca> mvo: yar
<pstolowski> cachio: #6491
<mvo> Chipaca: this is the change? if so, yes, lets do it
<Chipaca> ok
<mup> PR #6491: interfaces: hotplug nested vm test, updated serial-port interface <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6491>
<mvo> Chipaca: thank you! I think htis is just old code from the time when we had no snap (ironically)
<Chipaca> mvo: it'll be part of the invariant pr unless you'd rather it went in alone
<mvo> Chipaca: and nice idea on the dpkg-buildpackage one
<pstolowski> cachio: can you think on any reason why this more performant plan makes that test fail? any difference in the images?
<mvo> Chipaca: fine for me
<Chipaca> k
<mvo> Chipaca: its not a big change :)
<mvo> Chipaca: thank you!
<cachio> pstolowski, did you change the plan?
<cachio> I didn't see that
<pstolowski> cachio: yes i reverted that change innym PR to make it pass
<pstolowski> cachio: see last commit
<pstolowski> cachio: just apply it on master and it should fail the interfaces-daemon-notify test
<mup> PR snapd#6651 opened: tests: all the systems for google backend with 6 workers <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6651>
 * zyga off to the doctor
 * Chipaca off to have lunch
<Chipaca> zyga: lunch > doctor
 * Chipaca wins
<cachio> pstolowski, mmmm, ok
<cachio> pstolowski, we can't change the plan
<zyga> What is the status of spread / cloud?
<zyga> Did we run out of money?
<pstolowski> cachio: hmm hey not? How Is It affecting 14.04?
<mup> PR snapd#6606 closed: selinux, systemd: support mount contexts for snap images <SELinux> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6606>
<mborzecki> zyga: do you want to take a look at https://github.com/snapcore/snapd/pull/6485 ?
<mup> PR #6485: interfaces/seccomp: regenerate changed profiles only <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6485>
<dot-tobias> jdstrand: Is there a way to force an NTP resync using the timezone-control DBus interface? https://www.freedesktop.org/wiki/Software/systemd/timedated/ indicates that SetNTP() method restarts systemd-timedated, but timedatectl still reports âNTP in sync: noâ. Use case: Our device is offline until configured via an access point, so the device is booting without network. System does not seem to pick up the available network connection in the
<dot-tobias>  minutes after its established.
<zyga> back from doctor
<zyga> bikes are amazing :)
<zyga> mborzecki: sure, looking
 * Chipaca â cuppa
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<jdstrand> dot-tobias: I'm not an expert on timedated. If I were to guess, I'd guess the clock is maybe too far off or that your device is unable to communicate with the configured server. you might also check your logs for policy violations, but it sounds like timedatectl is working ok and it is something else
<dot-tobias> jdstrand: Yes, the clock was off > 12h because that's the time when the image was created. Didn't know that in order to sync the clock has to be near the actual date. Will look into workarounds how to get in re-sync.
<dot-tobias> jdstrand: Thanks!
<mup> PR snapd#6329 closed: cmd/snap-confine, packaging: support SELinux <SELinux> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6329>
<jdstrand> dot-tobias: cool. ogra may have some thoughts on that as well
<zyga> hey jdstrand :)
<zyga> jdstrand: I'm glad you noticed "goto the void" :-)
<zyga> initially it was an else statement but then it was too good to pass :-)
<jdstrand> zyga: hey, yeah :)
<zyga> :-)
<zyga> jdstrand: we also managed to uncover that core18 is missing some directories in that test, it's better late than never
<jdstrand> zyga: I saw that, wild :)
<zyga> jdstrand: I implemented the next branch but I will defer until my set of open PRs shrinks sufficiently
<zyga> jdstrand: btw, not sure if you saw https://github.com/snapcore/snapd/pull/6649
<mup> PR #6649: snap: reject layouts to /lib/{firmware,modules} <Created by zyga> <https://github.com/snapcore/snapd/pull/6649>
<mup> PR snapd#6652 opened: sanity: use proper SELinux mount context when sanity checking squashfs mounts <SELinux> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6652>
 * zyga -> tea / coffee
<mborzecki> super simple selinux PR ^^
<ogra> zyga, mvo, do you gys know if anyone actually tested pi core18 images with wlan ? seems i dont get proper DNS resolution to finish console-conf here (network is up and i can ping the board but user creation times out with DNS issues finding the login.u.c api stuff)
<ogra> this is with the stable released image...
<mvo> ogra: I'm not sure we did, sorry. is this the dragonboard or pi3?
<ogra> jdstrand, in case dot-tobias comes back while i'm not around ... https://github.com/ogra1/ntpcontrol
<mvo> ogra: or both?
<ogra> mvo, pi image on a pi 3 A+
<ogra> core 16 works fine
<ogra> (i resorted to that in the end)
<mvo> ogra: we need to look into this, in a meeting now unfortunately
<ogra> mvo, all fine, just wanted to check if it was tested before
<ogra> i also resoted to core16 for the project i needed the board for ... but i have another A+ for any tests if required
<mvo> ogra: added to test/debug this to our trello, thanks for reporting
<mup> PR snapd#6649 closed: snap: reject layouts to /lib/{firmware,modules} <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6649>
 * cachio lunch
<cwayne> ogra: sorry if this message is doubled, my ircs been weird but we do test wlan on Pi's, but using nm
<ogra> well, that wont help much if NM isnt preinstalled :P
<ogra> (also ... does console-conf actually support NM ??)
<niemeyer> cachio: spread#75 reviewed again
<mup> PR spread#75: Make spread tests for spread project run on google backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/75>
<mup> PR snapcraft#2516 opened: readme: add snap store badge <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2516>
<zyga> s pedronis renamed https://github.com/snapcore/snapd/pull/6621
<mup> PR #6621: overlord/snapstate: track time of postponed refreshes <Created by zyga> <https://github.com/snapcore/snapd/pull/6621>
<zyga> pedronis: to "inhibit"
<zyga> it is green so I'm very tempted to merge it :)
<zyga> everyone: I need 2nd review for https://github.com/snapcore/snapd/pull/6597
<mup> PR #6597: cmd/snap-update-ns: refactor of profile application (1/N) <Created by zyga> <https://github.com/snapcore/snapd/pull/6597>
<pedronis> zyga: it doesn't have 2 +1
<zyga> pedronis: I know :)
<zyga> that's why I'm saying
<zyga> if that was your only reservation I'd love to get a 2nd one
<pedronis> zyga: I asked Chipaca to review it
<zyga> great, I'll wait for the review then
<pedronis> Chipaca: could you look at #6621
<mup> PR #6621: overlord/snapstate: track time of postponed refreshes <Created by zyga> <https://github.com/snapcore/snapd/pull/6621>
<pedronis> when you have time
<Chipaca> yes
<cachio> niemeyer, thanks
<ijohnson> fyi to anybody using the go remote part, I just updated it in the wiki, so if anything breaks ping me
<zyga> thank you ijohnson
<Chipaca> huh
<zyga> Chipaca: hmm?
<Chipaca> zyga: what permissions should snap-confine have?
<zyga> Chipaca: as in UNIX?
<Chipaca> zyga: ye
<zyga> for now u+rwXs,g+rXs,o:+rX
<zyga> though I will drop the g+S part
<zyga> why?
<Chipaca> zyga: because it starts at 06755, as you say
<Chipaca> zyga: but snap-confine-from-core sets it to 04755
<zyga> wait, what?
<zyga> why?
 * zyga hugs Chipaca for fixing the tests
<Chipaca> restore: |
<Chipaca>     echo "Restoring host snap-confine"
<Chipaca>     chmod 4755 /usr/lib/snapd/snap-confine
<Chipaca> zyga: ^
<zyga> la la la
<zyga> man
<zyga> ...
<zyga> what just happened
<zyga> I spent 10 minutes debugging
<zyga> why snapd doesn't build
<zyga> on ... macos
<Chipaca> zyga: snap does :-) but not snapd :-(
<zyga> wrong terminal tab on a common shared source
<zyga> lol
 * Chipaca is still happy that snap does :-)
<zyga> I aborted a rebase in progress because I got fed up with this and wanted to think why everything is broken
<Chipaca> zyga: what was it telling you wasn't implemented?
<zyga>  /Users/zyga/go/src/github.com/snapcore/snapd/interfaces/mount/backend.go:97:84: undefined: osutil.MountEntry
<zyga> I totally ignored the path
 * Chipaca nods
<mborzecki> fwiw there was this crazy linux distro that didn't use the usual / layout, they could have had /User too
<Chipaca> it's just noise
<Chipaca> noise][1: no offense
<Chipaca> :-)
<zyga> mborzecki: yeah, I used it once
<zyga> it had /Users and /Applications like on macos
<pedronis> mborzecki: I did a pass over the gadget validation PR
<mborzecki> pedronis: thanks, sorry for it being so long
<pedronis> mborzecki: we'll need another layer of validation that looks at actual content for sizes as well?
<mborzecki> pedronis: yes, that will need to access actual snap data
<pedronis> ok
<pedronis> zyga: are you waiting for review from me on anything but #6642 atm ?
<mup> PR #6642: cmd/snap-confine: prevent cwd restore permission bypass <Created by zyga> <https://github.com/snapcore/snapd/pull/6642>
<zyga> checking
<zyga> we need  to look at https://github.com/snapcore/snapd/pull/6583
<mup> PR #6583: cmd/snap-confine: move ubuntu-core fallback checks <Created by zyga> <https://github.com/snapcore/snapd/pull/6583>
<zyga> but perhaps tomorrow morning
<pedronis> I'm not entirely happy with the code I saw the there the last time I looked
<pedronis> we can chat tomorrow
<zyga> today I want to finish mending existing branches that I know  what needs to  happen wiht
<zyga> ok
<pedronis> I'll try to still look at 6642 tonight
<zyga> thank you!
<zyga> it should go green once I fix core18 later  today
<mup> PR snapcraft#2516 closed: readme: add snap store badge <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2516>
<mup> PR snapd#6485 closed: interfaces/seccomp: regenerate changed profiles only <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6485>
<Chipaca> zyga: how is having RefreshInhibitedTime be zero on success useful?
<zyga> it is  useful because that is correct
<zyga> we had refreshed
<zyga> whee
<zyga> kill the  inhibit time value, if we had  any set
<zyga> next time when refresh is inhibited we can  check for non-zero inhibit time
<zyga> and if the time of  initial inhibition goes beyond certain duration
<Chipaca> hold on
<zyga> we can take action (kill apps etc)
<Chipaca> if the refresh wasn't inhibited, the task will be Done
<zyga> and?
<Chipaca> zyga: currently, if a refresh is inhibited, the task doesn't reach Done, right?
<zyga> it's not implemented in this  branch but something along those lines, correct
<zyga> we don't get to create those tasks in some cases
<zyga> things just bail out early
<zyga> sometimes we will create tasks and bail out late
<Chipaca> zyga: where do you track the inhibited time when you don't create the task?
<zyga> it's in the snap state all along
<zyga> it's not tracked in tasks
<zyga> the one in tasks is just for undo handler
<zyga> Chipaca: does it make sense?
<Chipaca> zyga: if you don't create the task, won't the refresh by retried much much later than intended?
<Chipaca> zyga: why would you not download the snap i mean
<mup> PR snapd#6646 closed: interfaces/adb-support: account for hubs on sysfs path <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6646>
<Chipaca> zyga: but yes, the code makes sense now, I somehow thought you were keeping it in the task (d'oh)
<Chipaca> I didn't realie this was super-task
<zyga> Chipaca: initially not creating the tasks is the easy way out
<Chipaca> I'm not sure how that works though (hence my last question)
<zyga> Chipaca: I will download the revision as an update to that flow
<zyga> Chipaca: but I want to have the basic version in first
<zyga> Chipaca: I will use the soft check (in another PR) to determine if we create tasks or not
<zyga> Chipaca: then the hard check after stopping services to see if we abort or not
<Chipaca> after stopping services?
<zyga> Chipaca: then if soft  or hard checks go over $MAGIC_DURATION  we carry on regardless
<zyga> Chipaca: ah, sorry, before
<Chipaca> ah
<zyga> (in this model it is before)
<zyga> no, no wait
<zyga> after
<zyga> yeah, I was right the  first time
<zyga> we do a hard check after stopping services because this is the moment we can migrate the data safely
<zyga> though I may be tired and talk nonsense, that part is not proposed yet and I haven't ran it in weeks
<pstolowski> pedronis: zyga can we land https://github.com/snapcore/snapd/pull/6491 ?
<mup> PR #6491: interfaces: hotplug nested vm test, updated serial-port interface <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6491>
<Chipaca> buuuuh, github is being silly
<zyga> pstolowski: looking
<Chipaca> zyga: I tried to +1 with a "blocked" tag, but github isn't letting me
<Chipaca> zyga: so I set it to 'changes requested', because i do request changes in fact, but my bigger concern is not landing it before the pr that uses it is ready to land
<zyga> Chipaca: why is that a concern?
<Chipaca> zyga: because without that, it's just cruft :)
<zyga> I wanted to land this deliberately before so that in case someone turns the feature off the data in  state is  correct
<Chipaca> it does nothing useful on its own
<Chipaca> ?
<Chipaca> wat
<zyga> when the rest of the  code lands that new  chunk will be behind a feature  flag
<zyga> but that's fine, it can land later
<Chipaca> zyga: what in the state would be incorrect if somebody enabled and then disabled this?
<zyga> Chipaca: if this ships but the  rest is in edge, going to  stable will give you correct state
<zyga> Chipaca: though I agree it's a bit silly and not strictly tied to the follow up branch being present
<Chipaca> zyga: if that is a concern, you need an epoch
<zyga> Chipaca: I will work on the  follow up as soon as the hard/soft branch lands
<zyga> Chipaca: no, it's not a concern,  just pedantry
<Chipaca> zyga: what happens if they enable this, get the flag in state, go back to stable, time passes, and they get the feature?
<Chipaca> zyga: and they had something inhibited when they went back to stable
<Chipaca> what happens then
<zyga> if the  inhibit time is  zero
<zyga> nothing
<zyga> if they had some value they may get a forced refresh if it goes over 90  days or something similar
<Chipaca> doesn't sound too bad. OTOH you could zero them in a subpatch
<Chipaca> ?
<zyga> yeah
<zyga> once we enable the feature perhaps/
<zyga> Chipaca: fixed, thank you
<zyga> pstolowski|afk: I will review it again, sorry for the lagg
<mup> PR snapd#6653 opened: tests: try to be a little bit invariant <Created by chipaca> <https://github.com/snapcore/snapd/pull/6653>
<om26er> Is this channel still connected to Slack ? if so, what technology is used for the bridge ?
<mup> PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mup> PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<zyga> om26er: I don't  believe it  ever was
<om26er> zyga, ok, I think I confused it with another channel
<zyga> jdstrand: please enqueue https://github.com/snapcore/snapd/pull/6605 if you have some time, it has 2 +1s and just needs your review
<mup> PR #6605: cmd/libsnap,osutil: fix parsing of mountinfo <Created by zyga> <https://github.com/snapcore/snapd/pull/6605>
<juliank> hmm, how does snapctl work?
<juliank> sudo snapctl stop radicale
<juliank> error: error running snapctl: cannot stop without a context
<juliank> $ sudo snapctl services
<juliank> error: error running snapctl: cannot query services without a context
<ijohnson> juliank: are you using snapctl outside of a snap?
<juliank> ah, it's just for use by snaps?
<ijohnson> it's only usable inside a snap
<juliank> it should maybe say so :)
<ijohnson> outside of a snap you should just use `snap`
<ijohnson> i.e. snap stop radicale
<juliank> So I did sudo snap stop --disable radicale.daemon
<juliank> will that persist after an upgrade of the snap?
<ijohnson> it is supposed to but there's currently a bug where refreshes always re-enable services
<juliank> Because with my local testing snap, if I do snap install my.snap --dangerous, it would override it :)
<juliank> hmm
<juliank> that's suboptimal
<ijohnson> see https://bugs.launchpad.net/snapd/+bug/1818306
<mup> Bug #1818306: disabled daemons are started after refresh <snapd:New> <https://launchpad.net/bugs/1818306>
<juliank> I'm thinking about running radicale for caldav/carddav on my server, so I sanpped the current version - but I don't wanna run the daemon as root (even in strict confinement), so I wanted to disable the daemon and just run it as a user program (well, from a systemd service)
<juliank> I do want to ship the daemon because duh, that's more useful for the store :)
<ijohnson> how would you run it as a user program from a systemd service?
<juliank> I don't know, I have not tried yet
<juliank> Exec=/snap/bin/radicale I guess?
<juliank> with User=radicale
<ijohnson> hmm I guess that would probably work
<ijohnson> there is upcoming snapd work that would allow the daemon to drop from root to a specific "daemon" user instead, but that's not done yet
<juliank> it would confine it to access to ~radicale/snap/common instead of /var/snap/radicale/common, but that's fine
<juliank> (it's a strict snap :D)
<juliank> ijohnson: I read about that
<juliank> (the only plug it needs is network-bind :D)
 * cachio afk
<jdstrand> zyga: ack
#snappy 2019-03-27
<mborzecki> morning
<mborzecki> hmm https://github.com/snapcore/snapd/pull/6652 travis job is finished (and green), gh status is still pending :/
<mup> PR #6652: sanity: use proper SELinux context when mounting squashfs <SELinux> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6652>
<zyga> good morning
<zyga> mborzecki: sucky night, my dog is sick, keeps throwing up all night
<zyga> mborzecki: I'm tired and not sure how the day will unfold
<mborzecki> zyga: uhh, sucks, make him fast a bit, always helps with my dog pack
<zyga> back in the office
<mup> PR snapd#6654 opened: packaging/fedora, tests/upgrade/basic: patch existing mount units with SELinux context on upgrade <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6654>
<mborzecki> almost there with selinux
<mborzecki> just one more PR on top of what's already open
<mborzecki> mvo: morning
<mvo> hey mborzecki
<mvo> mborzecki: how are you? how are the tests this morning?
<mborzecki> mvo: undecided, had to restart a spread job bc ubuntu-16.04-32 was taking too long a hit a kill-timeout:?
<mborzecki> mvo: maybe a trivial review to start the day? https://github.com/snapcore/snapd/pull/6652
<mup> PR #6652: sanity: use proper SELinux context when mounting squashfs <SELinux> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6652>
<mvo> mborzecki: sounds great
<mvo> mborzecki: doing that now
<mborzecki> mvo: thanks!
<zyga> eh, the dog keeps throwing up
<zyga> hey mvo
<zyga> mvo: a quick one please: https://github.com/snapcore/snapd/pull/6650
<mup> PR #6650: cmd/libsnap: neuter variables in cleanup functions <Created by zyga> <https://github.com/snapcore/snapd/pull/6650>
<mvo> zyga: sure, looking
<pstolowski> morning
<zyga> hey pawel
<mborzecki> pstolowski: hey
<mup> PR snapd#6650 closed: cmd/libsnap: neuter variables in cleanup functions <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6650>
<pedronis> mvo: hi,  #6602 could use a 2nd review
<mup> PR #6602: cmd,interfaces: replace local helpers with cmd.InternalToolPath <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6602>
<mvo> pedronis: looking
<pedronis> mvo: zyga: it seems you found some kind of agreement in #6410  , is that implemented? is it close to land?
<mup> PR #6410: release-tools: add debian-package-builder <Created by zyga> <https://github.com/snapcore/snapd/pull/6410>
<mup> PR snapd#6559 closed: pkg/apparmor: scratch documentation of apparmor <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6559>
<zyga> pedronis: yes, I will try to get to it today,
<zyga> pedronis: the agreement is that we simply take the script's essential part and add it as a debug section in the sid task
<zyga> pedronis: so that if it fails, people know how to debug
<pedronis> zyga: mvo wrote something else at the end
<pedronis> (so maybe there is not an agreement)
<zyga> pedronis: looking
<zyga> ah, that's even easier
 * zyga goes to do that now
<zyga> sorry, today is not great, my dog is sick and makes all kinds of mess :/
<pedronis> zyga: it's fine, I was just trying to understand if there was a bit of clarity there, otherwise at this point I would have close it
<pedronis> zyga: I don't think you are particularly blocked by me anymore right this moment, I need to go back to mvo's remodel PRs
<zyga> pedronis: I'm okay now, thank you!
<pedronis> zyga: sorry for the poor dog
<ppisati> mvo: does the dtb update mechanism work in core18 now?
<ackk> hi, I'm hitting this error since yesterday when trying to build with snapcraft in bionic containers: https://paste.ubuntu.com/p/bhYGfpj8Rc/ anyone could advise?
<Chipaca> ackk: Recursivity.  Call back if it happens again.
 * Chipaca puts away his BOFH excuse generator again
<pedronis> pstolowski: hi, 6491  can be landed
<pstolowski> pedronis: great, ty! zyga - last chance to have a look
<ackk> Chipaca, I can reprooduce constantly, I can't seem to build the snap
<zyga> pstolowski: I looked a little last night and it is ok
<Chipaca> ackk: it was meant as a joke, sorry
<zyga> approved just now
<pedronis> pstolowski: I'm sure we can improve the test over time, but I don't think it should be a blocker
<Chipaca> ackk: snapcrafters should be alive shortly to help you out
<ackk> Chipaca, ok, thanks
<Chipaca> ackk: have you tried with snapcraft from candidate?
 * ackk tries
<pstolowski> pedronis: yep
<mup> PR snapd#6652 closed: sanity: use proper SELinux context when mounting squashfs <SELinux> <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6652>
<ackk> Chipaca, same error
<ackk> Chipaca, does snapcraft need to run under sudo with --destructive-mode?
<ackk> uhm, it seems so it's trying to do apt stuff
<Chipaca> ackk: I think when snapcraft runs it, it runs as rot
<Chipaca> root
<Chipaca> but i'm not 100% on that
<zyga> ackk: --destructive-mode mangles your system
<pstolowski> pedronis: i've sent hotplug docs to you & Graham; i've deliberately omitted HotplugKey method that the interfaces could implement due to the slightly undefined story with versioning of keys that we talked about
<ackk> oh it seems I had some stuff owned by root in ~/.cache/snapcraft
<pedronis> pstolowski: I'll try to look later today
<pedronis> thx
<mup> PR snapd#6491 closed: interfaces: hotplug nested vm test, updated serial-port interface <Hotplug ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6491>
<mvo> ppisati: we are working on the firmware update mechanism, but its not done yet, do you have a use-case where you need it?
<mup> PR snapd#6651 closed: tests: all the systems for google backend with 6 workers <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6651>
<Chipaca> degville: mo'in!
<degville> Chipaca: morning!
<ackk> Chipaca, there's currently no way of having "snapctl set" execute hooks automatically, right?
<Chipaca> degville: the 'squiggly road' paragraph i added, i added it to clarify what i thought was maybe confusing, but not sure how successful i was
<Chipaca> ackk: what do you mean?
<ackk> Chipaca, if I run "snapctl set" from within a snap, it won't run the config hook right?
<pedronis> correct
<ppisati> mvo: yes, a bionic/snapdragon update that contains a heavily modified dtb
<Chipaca> ackk: you're holding it from the wrong end
<pedronis> mvo: a did a pass on the first and last of the current remodel PRs
<Chipaca> ackk: if you're inside the snap, call the configure hook and let it call snapctl set
<ackk> Chipaca, the configure hook reacts to the set, doesn't set things
<pedronis> Chipaca: ?  the configure hook doesn't call snapctl set (usually)
<ppisati> mvo: but if there's no dtb update mechanism, we can't pull it in
<Chipaca> (the hook needs to behave differently when not called as a hook tho
<Chipaca> pedronis: we have tests for that use case
<Chipaca> pedronis: so i presumed it was a'ight
<pedronis> it can do that
<pedronis> is just not typical
<pedronis> anyway it's not the first time we had that request
<ackk> Chipaca, in my case the config hook reads the config and generates some config files, I don't want/need it to set snap configs
<pedronis> we cannot really change the default though
<pedronis> s/default/default mode of operation inside a snap/
<ackk> Chipaca, pedronis, I have a case where a script in the snap would need to set setuff via "snapctl set", and trigger the hook. I can call it manually, I was just wondering if there was a way to have snapctl do it
<pedronis> Chipaca: we could introduce snapctl set --configure  (it would need to error if called that way from inside the configure hook itself)
<Chipaca> ackk: is this from inside a hook inside the snap?
<ackk> Chipaca, not from a hook, just from a script shipped within the snap
<ackk> Chipaca, it's basically a "init" script
<ackk> as in, to initialize the service configuration
<Chipaca> gotcha
<degville> Chipaca: I think the squiggly road is a valuable addition. I may have a small question I'll add to the doc.
<Chipaca> degville: it's definitely advanced usage, but needs to be documented (and an attempt at explaining it) somewhere because people will butt against this at some point (and it will make their heads wobble)
<degville> thanks Chipaca, that's good to know.
<Chipaca> pedronis: --configure would have to be async though, right?
<Chipaca> or weird if already inside a hook
<ackk> Chipaca, I don't think it should be allowed from a hook
<ackk> Chipaca, what I'm talking about is calling snapctl set from within the snap, but not in a hook, like from a app in the snap
<Chipaca> ackk: yes
<Chipaca> ackk: but 'snap set' kicks off a 'configure-snap' change
<Chipaca> ackk: if you're in a hook, you're running from a task
<pedronis> Chipaca: it would need care implementation wise
<Chipaca> ackk: so either it's weird because it will work in a snap and not a hook (surprising developers trying to do it), or needs extra care
<Chipaca> pedronis: ye
<ackk> Chipaca, setting configs in a config hook seems a bit weird to me
<Chipaca> ackk: agreed, but what about a refresh hook, to set config defaults say?
<Chipaca> ackk: what about in an install hook to run 'init'?
<ackk> that's a different hook though, so you could allow that
<Chipaca> where's the emoji for 'turtles all the way down'
<ackk> heh
<ackk> I agree it's tricky, I'm just saying I don't think it would be really surprising if config hook doesn't trigger itself
<ackk> whereas triggering the config hook from other hooks makes more sense
<mvo> ppisati: ok, thank, looks like this will be our first test for the new feature then
<mvo> pedronis: thanks, I will go over them
<pedronis> degville: Chipaca: let me know when the epoch docs is ready for another pass from me
<degville> pedronis: will do, thanks!
<pedronis> thx
<ppisati> mvo: well, but if we push the kernel now and the mechanism is not working yet, we are going to break people's installation
<mvo> ppisati: right, then we can't push it yet :/
<mvo> ppisati: how is it organized on the dragonboard? the dtbs there are part of the gadget?
<degville> Chipaca: I've just left one quick q in the doc I can't get my head around.
<Chipaca> degville: that's ok, i can't get my head around the q :-)
<degville> Chipaca: ahahaha!
<ppisati> mvo: last time i talked with ogra, when ubuntu-image build an image, it picks them from the kernel snap
<ppisati> ogra: ^
 * ogra reads backlog
<Chipaca> degville: let me rephrase the paragraph and see if it helps
<degville> thank you!
<mvo> ppisati: kernel snap sounds promising - if they get loaded from /boot/dragonboard-kernel_121/foo.dtb we would be good but I doubt somehow this is the case
<ogra> mvo, yeah, as ppisati said, dragonboard uses the kernel snap (as every other board except the pi)
<ogra> (for dtb's that is)
<Chipaca> degville: did that help?
<degville> looking now.
<degville> Chipaca: yes, thanks!
<Chipaca> degville: it feels more stuttery now
<Chipaca> zyga: ooh, ooh, post-merge reviews!
<Chipaca> is that a song
<mvo> ogra: does that mean the dtb gets unpacked from the kernel snap to /boot/$kernel/foo.dtb already? if so we should be good, no?
<ogra> mvo, well, you wrote that code :P ... but yes, the dtbs dir from the kernel should be copied 1:1 into /boot/uboot/<snapname>/
<ogra> IIRC it copoes the whole dir
<ogra> *copies
<mvo> ogra: yeah, I can look into the code if its DTRT but it sounds very promising
<ogra> and uboot.env should be set up tp load it from $snap_kernel/dtbs/
<mvo> ogra: cool
<ogra> only the pi differs
<ogra> (and some of my dev images where i pull dtbs from linux-next explicitly into the gadget)
<mvo> ppisati: so given what ogra wrote we should be good because the dtb is part of the kernel snap and the kernel extraction etc, this needs double checking, unfortunately I don't have a dragonboard myself but if you hvae the updated kernel, you could make it available in a store branch and I can ask our QA team to test
<mvo> ogra: ok
<mvo> ogra: that sounds all good, thanks for checking
<ogra> mvo, ppisati also, ondra is usually surrounded by dragonboards and clones if you need a tester ;)
<ackk> Chipaca, has $HOME always been set to $SNAP_USER_DATA?
<Chipaca> ackk: yes
<ogra> not in 15.04 :P
<Chipaca> I'm wishing we had a way to say 'no thanks'
<Chipaca> ogra: yes in 15.04
<Chipaca> AFAIR at least
<ogra> (there the variable was called differently :P )
<Chipaca> HOME was set to SNAPPY_USER_DATA_WITH_POTATOES_AND_A_SIDE_OF_WTF
<ogra> yeah
 * Chipaca tickles ogra 
<ogra> a hilariously long name
 * ogra laughs 
<Chipaca> to be clear, we've been setting HOME to a-per-revision-place-the-snap-can-write-to since before snapd existed
<Chipaca> it's just not been called SNAP_USER_DATA all the time
<ogra> yup
<Chipaca> it used to be $SNAP_APP_USER_DATA_PATH
<ogra> and before that s/SNAP/SNAPPY/
<ogra> but that was early on
<ackk> Chipaca, ogra so if an app with :home plug wants to refer to the actual user home, it would have to assume it's /home/$USER (or /root) right?
<ogra> unless it is a daemon or run by root, yes
<Chipaca> ackk: what I do in an app where I need to write to the user's home dir, is getent
<ackk> Chipaca, ah, I see
<Chipaca> ackk: https://github.com/chipaca/icdiff/blob/master/snap/snapcraft.yaml#L73
<Chipaca> export HOME=$(perl -we "print((getpwuid $>)[7])")
<ogra> hah
<ogra> perl
 * Chipaca whistles innocently
<pedronis> mvo: when you have time, what's the status of #6594 ?
<mup> PR #6594: [RFC] tests: run smoke tests on (almost) pristine systems <Created by mvo5> <https://github.com/snapcore/snapd/pull/6594>
<ogra> HOME="$(getent passwd $USER | cut -d: -f6)"
<ogra> (for a shell variant)
<Chipaca> but, i was tempted to offer some sort of a no-home-squash flag for apps, because it is a bit silly in those cases
<Chipaca> pedronis: wdyt?
<pedronis> Chipaca: about what?
<Chipaca> pedronis: having a way of telling snapd not to rewrite HOME
<Chipaca> per app
<pedronis> Chipaca: in the snap(craft).yaml ?
<Chipaca> pedronis: because when your app needs to honestly access the user's home, currently you need to look it up
<Chipaca> pedronis: yea
<Chipaca> example is icdiff's git-icdiff app, which needs to read ~/.gitconfig
<Chipaca> and ~/.config/git/config
<pedronis> Chipaca: why did we go with the current approach?   should it be tied to having a home plug?
<pedronis> setting the flag but not having the home plug will not do any good
<Chipaca> pedronis: current approach is because a lot of legacy apps just work if you point home to someplace they can write
<Chipaca> pedronis: an app could have a personal-files without having home though
<Chipaca> but maybe personal-files and home are the only two cases
<mvo> pedronis: 6594 is on hold, I need a good idea basicly, we can have a HO about the issue if you want or I can write something up, in a nutshell I want to ensure that the smoke tests are still run at every spread run but also that they run reliable in adt without surprises when I upload, so they should be as close as possible
 * dot-tobias says hi
<mvo> ogra: if ondra could test this kernel update, that would be great (cc ppisati)
<pedronis> mvo: ok,  I need to look at this carefully then before it makes sense to chat, worst case we'll chat next week about it
<mvo> pedronis: we can chat so that you don't need to do the digging yourself and then we can chat again
<mvo> pedronis: but either way is fine
<mvo> pedronis: its not urgent its just something that nags me
<pedronis> mvo: let's try to progress a bit on remodel stuff first
<pedronis> Chipaca: sounds it needs a forum post,  I'm not against , at the moment I'm unsure how to spell it sensibly in the yaml.
<Chipaca> be-all-the-home-you-can-be: <integer>
<Chipaca> if it's 42, don't overwrite HOME
<Chipaca> \o/
<pedronis> Chipaca: :)
 * Chipaca reaches consensus and moves on to implement
<pedronis> Chipaca: also will people learn about this
<Chipaca> pedronis: maybe in the forum we should poke popey/wimpress/bad-jokes-igor
<pedronis> Chipaca: unrelated, what is scope in search?  I forgot it seems or never knew
<Chipaca> pedronis: scope=wide â cross-channel
<pedronis> ah
<pedronis> I had forgotten
<Chipaca> pedronis: snap find --narrow â not wide
<pedronis> Chipaca: I'm staring at this https://github.com/snapcore/snapd/blob/master/store/store.go#L1094 and wondering if Prefix is in a good position in the struct or not, totally nitpicky state of mind
<pedronis> Chipaca: anyway while doing that I noticed that this comment seems reversed: https://github.com/snapcore/snapd/blob/master/store/store.go#L1127
<pedronis> Chipaca: it's all common-id fault
<Chipaca> pedronis: I don't think so
<pedronis> Chipaca: should that comment say public?
<Chipaca> 1 sec
<pedronis> it seems if you mix Prefix and Private it fails
<Chipaca> pedronis: right, you can only do fuzzy search of private
<Chipaca> pedronis: that is, you can't do name=foo private=true
<pedronis> ???
<pedronis> I'm totally confused
<Chipaca> 1 sec
<pedronis> is "name" fuzzy search?  is q fuzzy search?
<Chipaca> pedronis: q is fuzzy
<Wimpress> Chipaca pedronis What was this regarding?
<Chipaca> pedronis: name is prefix
<Wimpress> $HOME?
<Chipaca> Wimpress: having a way to say 'this app needs the real $HOME, not $SNAP_POTATOES'
<Wimpress> Interesting.
<Chipaca> Wimpress: i'll write a topic later
<Wimpress> Excellent!
<Chipaca> so we can hash it out if-n-when
<Chipaca> pedronis: I was trying to show you an easy example, but searching private snaps with names=... is hard :-)
<pedronis> Chipaca: anyway maybe that comment should say "cannot do private prefix searches"
<pedronis> or maybe is just me
<Chipaca> pedronis: it's never just you
<Chipaca> pedronis: you're one in a million, meaning there's seven thousand of you
<Chipaca> :-p
<pedronis> :)
<pedronis> Chipaca: related to the other nitpicking thought, I wonder if the struct(s) shouldn't look like:  https://pastebin.ubuntu.com/p/cYbTtB7fjX/
<Chipaca> zyga: did you see https://github.com/snapcore/snapd/pull/6614#pullrequestreview-219370705 ?
<mup> PR #6614: cmd/snap-confine: use fixed private tmp directory <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6614>
<zyga> Chipaca: looking
<zyga> Chipaca: no, I haven't
<zyga> interesting
<zyga> neat
<pedronis> Chipaca: need to go for lunch, that struct(s) suggestion and maybe changing that comment could be in a follow up, if the common-id one turns great
<zyga> suse folks are going through the patches I've sent
<pedronis> Chipaca: heh, s/great/green/
<Chipaca> pedronis: ack
<degville> Chipaca: when you get a moment, I've tried to replicate that squiggly road para into a table, which I hope is easier to parse (if accurate).
<Chipaca> degville: i'll look in a few
<degville> thanks!
<mvo> Chipaca: everybody wants a piece of you today :)
<Chipaca> mvo: it's my fault for being awesome
<mvo> Chipaca: it totally is!
<mvo> Chipaca: also see /msg :)
 * Chipaca hopes mvo didn't have a mouthful of tea just tehre
<mvo> Chipaca: haha
<mup> PR snapd#6655 opened: timings: SetTag and SetTagFromChange helpers <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6655>
<cachio> mvo, hey
<ogra> ogra@anubis:~$ hello-world.sh
<ogra> SNAP_INSTANCE_NAME is not set
<ogra> hmm, whats that ?
<ogra> did we break the hello-world snap ?
<cachio> niemeyer, the https://github.com/snapcore/spread/pull/75 is updated, could you please take a look? thanks
<mup> PR spread#75: Make spread tests for spread project run on google backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/75>
<mborzecki> ogra: seems to work fine here
<pstolowski> ogra: works here; what versions do you have?
<ogra> yeah, weird, works fine on my arm boards too
<ogra> ogra@anubis:~$ snap list hello-world
<ogra> Name         Version  Rev  Tracking  Publisher   Notes
<ogra> hello-world  6.3      27   stable    canonicalâ  -
<ogra> latest stable it seems
<pstolowski> snap version?
<ogra> ogra@anubis:~$ snap version
<ogra> snap    2.37.4
<ogra> snapd   2.37.4
<ogra> series  16
<ogra> ubuntu  16.04
<ogra> kernel  4.4.0-141-generic
<zyga> ogra: is that an ancient instalation
<zyga> ogra: and hello-world.sh is using the /snap/bin/hello-world.sh shell script?
<ogra> ogra@anubis:~$ /snap/bin/hello-world.sh
<ogra> SNAP_INSTANCE_NAME is not set
<ogra> ogra@anubis:~$
<mvo> hey cachio - sorry for the delay, was in a call
<zyga> ogra: which hello-world.sh
<ogra> ogra@anubis:~$ which hello-world.sh
<ogra> bah
<ogra> ogra@anubis:~$ which hello-world.sh
<ogra> /snap/bin/hello-world.sh
<ogra> IRC and slashes ... pfft
<Chipaca> ogra: snap run --shell hello-world
<Chipaca> ogra: printenv | grep SNAP | sort
<Chipaca> ogra: please
<ogra> https://paste.ubuntu.com/p/CwwHxvqJm7/
<ogra> obviously has that var
<cachio> mvo, no problem
<cachio> mvo, about core18
<cachio> there are several problems with the beta validation
<cachio> mvo, but most important ones
<cachio> the core18/snapd-refresh test fails on all the architectures
<Chipaca> ogra: the 'SNAP_INSTANCE_NAME is not set' error comes from snap-confine
<cachio> ansd it is because after the revert, the test reboots and when it happens we loose the network configuration on the device
<zyga> Chipaca: I know
<Chipaca> ogra: do you have a wonky snap-confine :-)
<cachio> mvo, basically, the board has ip: 127.0.0.1
<cachio> and not way to contact it
<zyga> Chipaca: but remember how we used to generate launcher scripts
<zyga> those would set SNAP_NAME
<zyga> Chipaca: that would be one way of having this issue
<ogra> Chipaca, dunno, my other snaps seem to work (i'm obviously typing here ... hexchat is from the snap)
<zyga> ogra: is /snap/bin/hello-world.sh a symlink or a script?
<cachio> mvo, then I see a similar behaviour
<mvo> cachio: oh, nasty
<Chipaca> ogra: ls -l `which hello-world.sh`
<cachio> mvo, installed the stable and tried to refresh with the core from bet
<cachio> a
<ogra> Chipaca, zyga, aha ! its a script !!!
<cachio> and it fails
<Chipaca> ogra: you installed hello-world in 1674
<mvo> cachio: what is the error message?
<Chipaca> ogra: :-)
<zyga> ogra: hahaha
<zyga> ogra: can you can the script here
<cachio> mvo, the same, network is list
 * zyga was right :)
<cachio> lost
<ogra> i installed it whenever ... but yeah, its oooold
<mvo> cachio: it fails because there is no network anymore?
 * zyga high-fives
<zyga> ogra: I can add a workaround
<cachio> mvo, mvo yes
<mvo> cachio: woah
<zyga> but it would be best if snapd rewrote those things
<ogra> https://paste.ubuntu.com/p/twdYDGmGk6/
<cachio> mvo, in the logs I  don't see nothing about errors
<mvo> cachio: this is on our pc-amd64, right? no network-manager snap or anything like this
<cachio> also in the chnage everything is ok
<Chipaca> ogra: snap disable hello-world && snap enable hello-world
<cachio> mvo, yes
<ogra> i can just re-move/re-install it, just wondering if there should be an automatic transition
<Chipaca> not without epochs
<ogra> ah
<Chipaca> bah, epochs + revert not reverting to an incompat epoch
<ogra> Chipaca, thanks, that works
<mvo> cachio: that is surprising, can you please pastebin the output "snap change <fail-change-id>" and the journalctl output after the refresh failed? but it sounds like I need to try to reproduce this myself ./
<cachio> mvo, the good part is that is really easy to reproduce
<cachio> mvo, just create a vm with the stable image
<cachio> and refresh core18
<cachio> that's it
<cachio> mvo, I'll give you that info in few minutes
<cachio> I need to recreate the vm
<pedronis> Chipaca: #6635 is green
<mup> PR #6635: client, daemon, store: search by common-id <Created by chipaca> <https://github.com/snapcore/snapd/pull/6635>
<Chipaca> pedronis: yes. Was wondering whether i should reorder te structs now
<Chipaca> or just land it and forget about it :-)
<pedronis> Chipaca: first of all, does that struct restructuring make sense to you as well?
<Chipaca> pedronis: I like it
<Chipaca> pedronis: even if it wastes a few bytes :-p
<Chipaca> (this is not a thing we'd hold hundreds of :) )
<pedronis> Chipaca: anyway at this point a follow up is fine
<pedronis> I'm also double checking something anyway
<Chipaca> pedronis: double-checking what?
<pedronis> Chipaca: I wonder if it's true that you cannot mix prefix and private
<Chipaca> pedronis: easy enough to check
<Chipaca> gimme a mo'
<pedronis> Chipaca: I mean I'm sure it was true at some point
<Chipaca> huh, this is new
<Chipaca> cannot run daemon: cannot obtain snap-seccomp version information: error: unsupported argument "version-info"
<niemeyer> cachio: Thanks, will do
<zyga> Chipaca: that's the new snap-seccomp work from maciej
<zyga> mborzecki: ^ we run the wrong snap-seccomp?
<mborzecki> hmmm
<Chipaca> no probs
<Chipaca> i just compiled snap-seccomp and dropped it in as well
<mborzecki> we shouldn't be, it's at the same location as currently executed snapd
<mborzecki> Chipaca: ah, yes, if it's like a custom build you'll need to drop the updated snap-seccomp too
<Chipaca> pedronis: it is not true that private + name don't mix, in the store
<Chipaca> mborzecki: will the new snap-seccomp work with the old snapd?
<zyga> Chipaca: ahh
<Chipaca> pedronis: IOW we can drop the restriction, if it's a promise
<mborzecki> Chipaca: yes, it's just a new command line switch that's added, nothign was removed
<zyga> Chipaca: try make hack
<zyga> it's good for things like that
<Chipaca> every time I try 'make hack' i need to then manually remove a bunch of gromf from cmd/
<pedronis> Chipaca: do you remember if we decide that snapd side? my theory it was some restriction from the old elasticsearch backend
<pedronis> Chipaca: I would drop it, but double check with cprov first
<pedronis> *decided
<Chipaca> pedronis: it's from elasto-search days ,yes
<pedronis> Chipaca: anyway that's also why the comment confused me, it's a weird restriction, if had to have a restriction at all,  not allowing query  but only allowing exact or prefix for private would make more sense
<mup> PR snapd#6635 closed: client, daemon, store: search by common-id <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6635>
<cachio> mvo, https://paste.ubuntu.com/p/dcv8YmFVn2/
<cachio> mvo, this is about the changes
<cachio> I installed stable image and refresh core18 to beta
<cachio> mvo, log https://paste.ubuntu.com/p/rZh668v8FK/
<cachio> mvo, dmesg ourput https://paste.ubuntu.com/p/syvtCK48nN/
<mvo> cachio: thank you
<mvo> cachio: out of curiosity, if you restart snapd manually does it have network again? does the entire system is without network or just snapd?
<joc> cachio: I've just hit the problem you're describing on a device I was testing, network failing to come up
<pedronis> Chipaca: so sounds we can drop that restriction to simplify that code a bit and do the change to struct(s)
<pedronis> Chipaca: when you have a moment
<cachio> mvo, no
<Chipaca> pedronis: card material?
<cachio> joc, using core18?
<pedronis> Chipaca: yessish
<pedronis> Chipaca: especially if you cannot do it very soon
<joc> cachio: yes, flashed this morning with 20190327 image
<cachio> joc, nice, and you refresh the core18 snap?
<joc> cachio: i dont think i manually requested a refresh at any point
<Chipaca> pedronis: I could do it right now, but i probably shouldn't :-)
<cachio> mvo, the whole systems is without network
<cachio> mvo, ping: google.com: Temporary failure in name resolution
<mup> PR snapcraft#2517 opened: project: ensure yaml load returns a dictionary <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2517>
<cachio> joc, in that case, autorefresh happened
<cachio> joc, this is weird because autorefresh should refresh to stable
<cachio> joc, do you have access to this board/machine?
<joc> cachio: do you happen to know easiest way to get back in to this device without network?
<cachio> joc, serial?
<cachio> joc, which device is it?
<joc> cachio: its a thin client pc on my desk so i have physical access
<joc> is serial console on by default?
<cachio> joc, but is it core18 systems?
<cachio> or it is bionic?
<joc> cachio: core18
<mvo> cachio: ta - in a meeting right now, but will look at it after that
<mvo> cachio: super strange that the network goes down :(
<cachio> so, and you didnt create a user right?
<cachio> joc, you just have the one that you used by ssh?
<joc> cachio: exactly
<cachio> joc, in that case I don't know
<cachio> joc, I use to creata another user with pass to be able to connect through the console
<zyga> Chipaca: what kind of stuff do you have to remove?
<Chipaca> zyga: barnacles
<zyga> ?
<roadmr> https://en.wikipedia.org/wiki/Barnacle
<Chipaca> pedronis: in health checks, is 'unknown' only when the hook isn't there, or also when it errors out?
<Chipaca> e.g. if the user does 'snapctl set-health --code=123 blocked', which will fail, is that `unknown`? or is it `error`?
<mup> PR snapd#6631 closed: tests: split travis spread execution in 2 jobs for ubuntu and non ubuntu systems <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6631>
<pedronis> Chipaca: so juju charm cannot set error by themselves, but here we allow that
<pedronis> Chipaca: I would be conservative,  if the hook errors/doesn't set the snap we don't really know if the snap overall is healthy or not
<pedronis> s/the snap/the health status/
<pedronis> Chipaca: the question is a bit, would we rollback a snap that has  a failing health hook?
<Chipaca> i would not
<Chipaca> pedronis: hook errors / doesn't set the snap -> health is unknown
<Chipaca> pedronis: do we list unknown in notes? only if it's not 'no hook'?
<pedronis> Chipaca: yea, so we can start with unknown,  otherwise we would need to use error with one of the reserved snapd codes
<pedronis> which we can got to later
<pedronis> s/got/go/
<pedronis> Chipaca: you mean in snap list?
<mup> PR snapd#6656 opened: tests: split travis spread execution in 2 jobs for ubuntu and non ubuntu systems <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6656>
<zyga> cachio: I found a fix for the zypper issue
<zyga> cachio: --force-resolution
<cachio> zyga, nice, I'll try that now
<cachio> thanks
<mborzecki> zyga: multipass doesn't work too well on arch now :/
<zyga> mborzecki: what's wrong?
<zyga> I had to chmod the socket
<zyga> but other than that it worked ok
<zyga> (on tumbleweed)
<mborzecki> zyga: https://paste.ubuntu.com/p/3yQZXXWm3c/
<mborzecki> maybe i'm missing some local libs
<zyga> wow
<zyga> multipass is classic
<zyga> so probably badly linked?
<zyga> ldd?
<zyga> and report to Saviq :)
<Saviq> mborzecki, zyga: yes, we know, httpsÂ âÂ http, sorry guys
<mborzecki> ok
<mborzecki> Saviq: thanks!
<mborzecki> Saviq: do you know which dep i'm missing locally?
<Saviq> mborzecki: it's about it being incompatible, not missing, I'm afraid
<Saviq> classic snaps...
<Saviq> we'll soon be rid of that ;)
<mvo> cachio: so for some reason "systemd-networkd" service is dead after the uc18 refresh, its totally unclear why, manually starting it brings network back
<mup> Bug #1821944 opened: Chromium is unable to start after todays snapd upgrade 1.37.4ubuntu0.1 with 'mkdir: cannot create directory '/run/user/0': Permission denied'  <chromium> <directory> <permission> <update> <Snappy:New> <https://launchpad.net/bugs/1821944>
<cachio> mvo, nice
<cachio> mvo, I saw the same here
<cachio> could be related to the systemd change?
<ondra> mvo ppisati sorry I was with client, what dragonboard do you want to test kernel on? db410c?
<ondra> and what kernel, 4.15?
<ogra> ondra, check your mail
<cachio> zyga, work much better with force-resolution
<cachio> mvo, thanks for digging
 * cachio lunch
<zyga> cachio: +1, please propose that
<Chipaca> degville: does the table i created make any sense to you?
<mborzecki> zyga: some trouble with 6410 on my machine
<degville> Chipaca: yes, it does. Thank you for doing it! I do think it makes things much clearer by being explicit about what happens, though we may have to hide/fold it so as to not scare too many readers away.
<Chipaca> https://bugs.launchpad.net/snappy/+bug/1821944 seems bad
<mup> Bug #1821944: Chromium is unable to start after todays snapd upgrade 1.37.4ubuntu0.1 with 'mkdir: cannot create directory '/run/user/0': Permission denied'  <chromium> <directory> <permission> <update> <Snappy:New> <https://launchpad.net/bugs/1821944>
<cachio> zyga, doesn't work well with tumbleweed https://travis-ci.org/snapcore/spread-cron/builds/510954310#L1952
<pedronis> jdstrand: hi, does this ring any bells  https://bugs.launchpad.net/snappy/+bug/1821944 ?
<mup> Bug #1821944: Chromium is unable to start after todays snapd upgrade 1.37.4ubuntu0.1 with 'mkdir: cannot create directory '/run/user/0': Permission denied'  <chromium> <directory> <permission> <update> <Snappy:New> <https://launchpad.net/bugs/1821944>
<mborzecki> cachio: zyga: shouldn't that job be using zypper dup?
<Chipaca> degville: in that table, is it clear that after the first install the next rows are what happens on refresh?
<cachio> makes update and then dup
<cachio> mborzecki,
<zyga> cachio: update is  dup but weaker
<zyga> it should du dup
<zyga> just do dup :)
<mborzecki> du dup
<cachio> ok
 * zyga needs to run now
<cachio> ehhee
<cachio> zyga, mborzecki I'll try dup and if it works i'll push to snapd too
<ondra> mvo ppisati 4.15 test kernel snap booting fine on DB410 device
<ondra> mvo ppisati for more rigorous testing we would need cwayne's team's run, for which i can share test image
<cwayne> ondra: core?
<ondra> cwayne yep
<degville> Chipaca: yes, I think so. I've tweaked the intro sentence slightly.
<cwayne> ondra: link me and we'll kick some off
<ondra> cwayne ah but I have image for emmc and you guys test sdcard, right?
<Chipaca> degville: ta
<Chipaca> degville: good for a pedronis read i think
<cwayne> ondra: yea
<degville> Chipaca: Yep!
<ondra> cwayne for sdcard it's almost easier you build it yourself
<pedronis> Chipaca: degville: I made some comments, suggestions
<degville> pedronis: thank you!
<Chipaca> pedronis: lgtm :-)
<cwayne> ondra: what if I pay you in beer to build it for me
<pedronis> degville: Chipaca: the table needs a bit more intro, maybe just me but it took me a bit to parse it (maybe because two column have the same header but are different timelines)
<degville> pedronis: yeah, I completely see what you mean. Trying to tweak it now.
<pedronis> Chipaca: I did another small suggestion
<pedronis> degville: answered to your comments
<ondra> cwayne in beer? How many images do you want?
<degville> pedronis: great, thanks.
<cwayne> ondra: 1?
<ondra> cwayne and how many beers is that?
<degville> Chipaca: are you ok with me moving the epoch gdoc over to the Discourse topic? We can obviously still make changes there.
<Chipaca> degville: go for it
<degville> coolio.
<zyga> I just realized that not sleeping last night will ruin my the value of studying in the evening:/
<mup> PR snapd#6657 opened: tests: enable opensuse 15 and add force-resolution installing packages <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6657>
<cachio> zyga, PR created
<zyga> Reviewed
<zyga> :-)
<cachio> zyga, thanks :)
<zyga> Pleasure
<cwayne> ondra: 3
<cwayne> ondra: so this is just a core18 yeah? Since it's only 4.15?
<ondra> cwayne nah you can do core16 with 4.15
<ondra> cwayne this is how I quickly tested here
<ondra> cwayne http://people.canonical.com/~okubik/ubuntu-core-18-dragonboard-20190327-00.img.xz
<ondra> cwayne 3 beers pls :P
<cwayne> lol
<ondra> cwayne I have not tested this one yet
<cwayne> What could go wrong
<zyga> https://forum.snapcraft.io/t/building-applications-for-both-snap-and-flatpak-at-once/10608 <- this
<mvo> cachio: hey, I tried the following: created a stable image with "ubuntu-image ubuntu-18-amd64.signed", then ran "snap refresh --beta snapd" on that image. when doing that my network stayed up.
<mvo> cachio: when you did this test you used the current released core18 image, is that correct?
<mvo> cachio: I need to have dinner but I will keep poking at this, I'm not sure if it is snapd itself or something else causing this, I definitely see if when I upgrade from an older image (that was also using edge)
<mvo> cachio: I think we need to gather more data
<mvo> cachio: i.e. create a stable image then update things one by one and see what breaks network
<cwayne> mvo: for us it was core18
<mvo> cwayne: oh, core18 - ok
<mvo> cwayne: the one in beta
<cwayne> Yep
<pedronis> Chipaca: degville: thanks for the work on the epochs docs
<degville> Chipaca: pedronis: no problem - thanks for your feedback.
<mvo> cwayne, cachio, pedronis yeah, upgrading snapd in isolation seems to be fine. but upgrading core18 to current beta is not, this looses networking. one of the changes there is indeed systemd
<jdstrand> pedronis: wrt https://bugs.launchpad.net/snappy/+bug/1821944; yes, this is an old bug where the snap is not allowed to create the parent dirs of XDG_RUNTIME_DIR. normally systemd creates that directory upon session login (eg /run/user/1000/...) but in this case tht command is run under sudo and thus XDG_RUNTIME_DIR is set to /run/user/0/snap...., and /run/user/0 doesn't exist
<mup> Bug #1821944: Chromium is unable to start after todays snapd upgrade 1.37.4ubuntu0.1 with 'mkdir: cannot create directory '/run/user/0': Permission denied'  <chromium> <directory> <permission> <update> <Snappy:New> <https://launchpad.net/bugs/1821944>
<mup> Bug #1821959 opened: File name breaking go modules <Snappy:New> <https://launchpad.net/bugs/1821959>
<jdstrand> pedronis: this is why the mir snap has a special rule to create that dir. I've long felt if systemd isn't going to do it, then snapd should
<jdstrand> s/mir snap/mir interface/
<jdstrand> pedronis: there are forum topics and bugs on this
<jdstrand> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1751634, https://bugs.launchpad.net/snapd/+bug/1738197, https://bugs.launchpad.net/snappy/+bug/1656340
<mup> Bug #1751634: Unable to launch program (installed as snap) as root <apport-bug> <artful> <bionic> <xenial> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1751634>
<mup> Bug #1738197: Daemons do not have an /run/user/* dir created <snapd:Fix Released> <https://launchpad.net/bugs/1738197>
<mup> Bug #1656340: XDG_RUNTIME_DIR is not created on app startup <bionic> <cosmic> <eco-team> <xenial> <Snappy:Triaged by zyga> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1656340>
<cwayne> mvo: sounds right
<mvo> cwayne: ta
<cachio> mvo, hey, so
<cachio> mvo, what can I test to help
<cachio> ?
<mvo> cachio: if you could just double check my findings that would be great. so an update of snapd itself should be fine with the core18 r782. well, anything with core18 782 should be fine
<mvo> cachio: but once core18 goes to beta/edge things go bad (no network)
<cachio> mvo, sure
<mvo> cachio: once we know its not snapd we are good for core
<mvo> cachio: and then we need to figure out why core18 is busted :/
<mvo> cachio: might involve diff -uNr /snap/core18/782/etc /snap/core18/828/etc
<mvo> cachio: anyway, some quesitons still :)
<cachio> mvo, hice, I'll start digging
<jdstrand> pedronis: there are also references to that topic in the forum
<pedronis> jdstrand: yea, but then I read the bug closer, is not clear is about sudo,
<pedronis> seems there's a core dump as well
<jdstrand> pedronis: I've always asserted that if systemd isn't going to do it, snapd should because snapd is setting up the env var. there was a comment from jamesh somewhere (I can't find it in LP, the forum or github) where he had a differing opinion, but I can't remember what it was. I think he was fine about creating some dir that a snap could use, but didn't think /run/user/0 was correct cause it wasn't a
<jdstrand> proper session. I can't recall the details
<pedronis> jdstrand: yes, I don't see how that in particular would help, running sudo chromium is I suspect going to fail in other ways
<jdstrand> pedronis: the only way I can think of that he'd get that denial is if he ran it under sudo, cause snapd is seeting XDG_RUNTIME_DIR to /run/user/0/...
<pedronis> jdstrand: it says us much in the bug
<jdstrand> pedronis: a snap not run with sudo trying to access /run/user/0 would be denied because /run/user is root:root 755 and /run/user/0, when created, would be 700
<jdstrand> pedronis: I asked for more info
<pedronis> I asked the same :)
<jdstrand> oh, heh
<jdstrand> I'd love to see someone make a decision on snap-confine doing a mkdir /run/user/0 fwiw
<jdstrand> unrelated to this bug
<jdstrand> there is even commented out/ifdef'd out code to do it
<pedronis> jdstrand: I thought we discussed it in Malta
<pedronis> jdstrand: in the context of https://github.com/snapcore/snapd/pull/6327
<mup> PR #6327: Allowing sockets under /run/user/0/$SNAP_NAME <Created by kubiko> <https://github.com/snapcore/snapd/pull/6327>
<cachio> mvo, is it any way to refresh the core18 to a specified revision?
<jdstrand> pedronis: I read that PR and that is different from the point I am making today. we may havev discussed today's point in Malta, but idr an outcome (or that conversation). I do recall reading something from jameh on the subject recently-ish
<jdstrand> jamesh evevn
<jdstrand> pedronis: the question in that PR is the yaml declaration of specifying that path explicitly as /run/user/*0*/snap.foo.sock
<cachio> mvo, updated to core18 rev 798 and worked fine
<jdstrand> pedronis: my point in that PR is that ondra should instead use $XDG_RUNTIME_DIR/sock (or something)
<cachio> mvo, trying now with 810
<jdstrand> pedronis: in this case, systemd should create all the parent dirs. so this is a different issue than what I describe as a problem
<jdstrand> pedronis: which is trying to use XDG_RUNTIME_DIR as a root is broken because nothing is creating it
<jdstrand> pedronis: the snap can create XDG_RUNTIME_DIR, but not dirname XDG_RUNTIME_DIR
<jdstrand> anyway
<jdstrand> the bugs describe the issue
<pedronis> jdstrand: it sounds like we need a forum post to explain the use cases
<cachio> mvo, http://people.canonical.com/~mvo/core18-changes/html/edge/unknownr818_unknownr821.html
<pedronis> jdstrand: and your recommendation
<cachio> mvo, I refresh from 818 to 821 and fails
<cachio> mvo, I tested refresh to all the revisions from 782
<cachio> mvo, 782, 788, 791, 193, 798, 808, 810, 818, 821
<cachio> mvo, and with 821 fails
<jdstrand> there is but one use case that is described by the open bug, https://bugs.launchpad.net/snappy/+bug/1656340
<cachio> and in the change log
<jdstrand> pedronis: ^
<mup> Bug #1656340: XDG_RUNTIME_DIR is not created on app startup <bionic> <cosmic> <eco-team> <xenial> <Snappy:Triaged by zyga> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1656340>
<cachio> mvo, we have something interesting
<jdstrand> pedronis: if you prefer a forum post, I can do that
<pedronis> jdstrand: yes, for this, I would prefer a forum post
<jdstrand> pedronis: I have to focus on the 'daemon user' work item for the maas team so I'll add to my todo
<pedronis> jdstrand: that's fine, to clear I just think it merits some trail and context, even if I will just end up agreeing
<pedronis> *to be clear
<pedronis> I feel I am a bit lacking context/full picture atm
<jdstrand> pedronis: that's fine. the idea is simple but I suspect followups that require some discussion and archaeology that I'll want to have time for so will wait a bit
<pedronis> jdstrand: it's ok,  a daemon user is definitely a priority
<jdstrand> pedronis: fyi, per joemcmanus, I'm going to be pretty heads down on this for the next little while. I'm mostly caught up on all store reviews (barring anything from last night) and PRs (a couple are in my inbox)
<jdstrand> pedronis: if there is something that you feel is very urgent, please let me know and I can set the daemon user aside, otherwise I'm going to focus on that for a couple/few days
<mvo> cachio: that is interessting - the change from 818->821 is glib and systemd
<mvo> cachio: so that is very interessting
<cachio> mvo, netplan too
<mvo> cachio: ohhhhhhh
<mvo> cachio: netplan sounds super suspicious
<mvo> cachio: its also a huge update
<mup> PR snapcraft#2518 opened: snapcraft/extractors/setuppy.py: match setuptools metadata keys <Created by anonymouse64> <https://github.com/snapcore/snapcraft/pull/2518>
<cachio> mvo, .4 to 0.96
<mvo> cyphermox: hey, we noticed that on core18 with the current beta/edge snap we have no network anymore, we pinned it down to a systemd update or a netplan.io update. netplan.io in proposed is a big update so this looks we might want to dig into this a bit more
<mvo> cyphermox: do you have any hints for us how to debug?
<pedronis> jdstrand: that's fine,  will you write something in the forum about the daemon user design, or is that capture in the old forum post?  I remember Gustavo wanted to double check on it
<jdstrand> pedronis: the old forum post is the complete design. this is I've affectionately called it, phase 0.25 of the design. there is no declaring in the snap yaml or anything. just simply, 'the security policy allows you to drop to/chown/chgrp etc to daemon user/group'. similar to now where we simply allow chown to root. the work I do will also add the implied rule of dropping to the SUDO_USER
<jdstrand> pedronis: put another way, this is a way to expand security permissions to use the daemon user and group. you don't have to do anything special in the snap
<jdstrand> pedronis: this is snap-seccomp work primarily
<pedronis> jdstrand: I had the vague understanding that from how Gustavo talked about it, you would have to declare something in the snap
<jdstrand> pedronis: actually, you are right, that is in the trello card
<niemeyer> jdstrand: pedronis is correct.. we need to review the plan as the goal is to have users declared
<jdstrand> I'm focusing only on the snap-seccomp bits for the moment since those are the hard bits
<jdstrand> I can create that post after this low level work
<niemeyer> jdstrand: We'll fake the underlying implementation, but we need to get the overall design right so that we can fake it properly on that initial phase, just for the daemon user
<zyga> I am going home from classes
<jdstrand> yes, that is in the card
<niemeyer> zyga: o/
<zyga> I see the chat backlog is interesting
<niemeyer> jdstrand: Cool, thanks for checking
<zyga> I will read everything here
<jdstrand> I forgot about that cause I knew I wanted to focus on seccomp first
<jdstrand> anyway, that's all fine
<cyphermox> mvo: I'd start by looking at whether there are files in /run/systemd/network
<mvo> cyphermox: thanks, yes, there is a file 10-netplan-eth0.network which looks valid
<mvo> cyphermox: but it looks like systemd-network (the service) is dead - does netplan fiddle with this one?
<cyphermox> uh, yes, to enable it
<cyphermox> making a link in /run/systemd/system/network-online.target.wants/systemd-networkd.service from the look of things
<mvo> cyphermox: ha! I just found this and it seems like the pervious netplan did create the symlink in "multi-user.target.wants"
<mvo> cyphermox: so it looks like on UC18 in beta network-online.target is also dead for some reason
<mvo> cyphermox: so it looks like we don't configure this target on UC18 to be enabled, that would explain it, right?
<cyphermox> oops, yeah that would explain it
<mvo> cyphermox: silly question (forgive me, its late) - what should we do? should netplan go back to the old target? or should we in UC18 enable network-online.target? and if the later, are there any risks?
 * cachio afk
<mvo> (and if the later, whats the easiest way to do that ?)
<cyphermox> I don't know how this was handled in UC originally; I moved it to network-online when revising things to remove delays at booting with wifi on raspberry pis
<cyphermox> let's see
<cyphermox> AFAICT network-online is the more correct way to handle this; but I'm not certain what the risk is in changing this
<cyphermox> mvo: you're getting this on bionic right now, right?
<cyphermox> ie. UC18, so building from bionic, presumably with proposed enabled, otherwise you wouldn't have that change
<mvo> cyphermox: yeah, this is UC18
<mvo> cyphermox: correct
<mvo> cyphermox: these changes broke it http://people.canonical.com/~mvo/core18-changes/html/beta/unknownr818_unknownr821.html
<mvo> cyphermox: well "broke"
<mvo> cyphermox: its just in edge/beta for now
<cyphermox> mvo: is network-online.target enabled?
<mvo> cwayne: silly question, can we have some minimal gating for core18 edge->beta to prevent e.g. broken networking from entering beta? or is it too difficult?
<mvo> cyphermox: it says "static; vendor present: enabled"
<mvo> cyphermox: but also "Active: inactive (dead)"
<cwayne> mvo: no reason we couldn't
<mvo> cwayne: its not urgent but I think this issue here with core18 highlights that a minimum amount of checks (initially "do we have network") would be cool before we allow core18 from edge->beta (cc sil2100)
<mvo> cyphermox: hm, this is a special target, let me try to figure out if I can enable this at all or if it is â¦ well â¦ special :)
<mvo> cyphermox: or do you happen to know if/how to enable this?
<cyphermox> as I recall nothing special need to be done to enable it
<mvo> cyphermox: :/ it tells me "Active: inactive (dead)"
<cwayne> mvo: yep, I think cachio already does some similar testing on our devices
<cyphermox> mvo: check /etc/systemd/system; see if there's a symlink by that name there (network-online.target)
<mvo> cyphermox: manually running "systemctl start network-online.target" makes things happy
<cyphermox> that's not a permanent fix though
<mvo> cyphermox: no symlink
<cyphermox> AAUI it just gets run...
<mvo> cyphermox: yeah, not a permanent fix for sure, just another data point
<mvo> cwayne: thanks, we should sync on this later this week, would love to explore options
<cwayne> mvo: absolutely
<cyphermox> mvo: where can I get an image or this particular core snap?
<mvo> cyphermox: aha - I'm just reading up on network-online.target (in man:systemd.special(7)) and it says here that network-online.target is only pulled in if a unit requires it
<mvo> cyphermox: but this is a pretty empty system and nothing requires it
<mvo> cyphermox: from reading the man-page maybe "network.target" might be a better option?
<cyphermox> no; I'll just revert to what it was before
<mvo> cachio, pedronis fwiw, it looks like the network issue on core18 is netplan.io related so I think we don't need to block the core snap promotion for uc16
<mvo> cyphermox: thats fine as well, thank you!
<mvo> cyphermox: one last question (sorry for the flurry of questions) - will this revert happen soon or shall we (snapd team) patch netplan ourself in the UC18 edge ppa to unblock uc18 beta/edge snaps?
<cyphermox> mvo: I need to upload to disco and make new revisions for the SRUs in progress; it can be in tomorrow
<mvo> cyphermox: thats great, thank you
<mvo> cyphermox: that time frame is totally fine
<ondra> pedronis I agree with jdstrand  that PR needs to be updated and use $XDG_RUNTIME_DIR instead, so we are not hardcoding path there. I just need to find time to update PR for this. I think if we use XDG_RUNTIME_DIR it needs change in two places, validation check and then using actual XDG_RUNTIME_DIR value when creating systemd socket definition
<mup> PR snapcraft#2517 closed: project: ensure yaml load returns a dictionary <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2517>
<Son_Goku> niemeyer, hey is the forum broken?
<Son_Goku> it seems to time out for me
<niemeyer> Son_Goku: Heya
<niemeyer> Son_Goku: Seems okay from here
<Son_Goku> well, I can't get it to load
<Son_Goku> so I can't post about the snapd and snapd-glib updates :(
<Son_Goku> F30: https://bodhi.fedoraproject.org/updates/FEDORA-2019-1a613fbede
<Son_Goku> F29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-a93e7637d2
<Son_Goku> F28: https://bodhi.fedoraproject.org/updates/FEDORA-2019-2d75eaae81
<Son_Goku> EL7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-be55f1a139
#snappy 2019-03-28
<mborzecki> morning
<zyga> Good morning
<mvo> hey zyga
<zyga> Hey :-)
<zyga> Starting later because I started assisting my son to school on a bike
<zyga> Very nice way to start the day
<zyga> mvo: I got green on that pwd test I added. I tweaked core in test prepare though
<zyga> I donât think it is sufficient for production yet because vanilla core is not right
<zyga> But it shows promise :-)
<zyga> I will be in the office soon
<mvo> zyga: good, is the fix for core18 (git) difficult?
<zyga> We will see
<zyga> I have not done that yet
<mvo> ok
<mborzecki> mvo: zyga: morning guys
<mvo> mborzecki: good morning
<mup> PR snapd#6658 opened: testutil: run mocked commands through shellcheck <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6658>
<mvo> pedronis: 6628 has two plus - is that something you want to review as well or can we go ahead and merge?
<mborzecki> fun PR btw ^^^
<mborzecki> and super simple too :)
<zyga> Woooot
<zyga> Super
<mborzecki> yeah, some nice things caught too
<mvo> mborzecki: nice one
<mborzecki> wonder how udevmon mocking worked without __END__
<mborzecki> the impact is small on my mock, but i can look into some caching if needed
<zyga> mborzecki: reviewed :-)
<mborzecki> zyga:  thanks!
<pstolowski> morning
<pstolowski> mborzecki: nice catch with udevmon mock , thanks!
<mborzecki> pstolowski: hey
<mvo> hey pstolowski
<pedronis> mvo: no, I skimmed it originally
<pedronis> (about 6628)
<pedronis> and morning
<pedronis> mvo: I answered in #6404
<mup> PR #6404: snapstate: auto transition on experimental.snapd-snap=true <Created by mvo5> <https://github.com/snapcore/snapd/pull/6404>
<mvo> thanks pedronis
<mvo> pedronis: I am working on the remodel feedback and get back to this one enext
<mup> PR snapd#6628 closed: overlord/snapshotstate: support auto flag (automatic snapshots 1/N) <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6628>
<Chipaca> moin moin
<Chipaca> ogra: who can best answer https://forum.snapcraft.io/t/question-about-going-to-production/10609 ?
<ogra> Chipaca, i'll take a look after the meeting
<ogra> Chipaca, also ... https://forum.snapcraft.io/t/disabling-console-conf-from-gadget-or-core-config-option/4358
<pedronis> mborzecki: hi, does your work help with this https://forum.snapcraft.io/t/selinux-blocking-socket-activation-on-fedora/6931/9  or could that be addressed in the context of SELinux new stuff?
<mborzecki> pedronis: it works with the upcoming selinux changes, i still want to try if there's a workaround for the latest 2.38 that neal relased though
<pedronis> mborzecki: ok,  thanks for the info
<mborzecki> pedronis: fwiw the selinux clean test has a socket activation check that was added specifically because of this :)
<pedronis> mborzecki: great :)
<mborzecki> hmm systemctl 219 on centos exits with 1 when we ask for a property that doesn't exist for a given unit type
<mborzecki> so snap services output is garbage if there is a socket activated service
<mborzecki> pstolowski: pushed the updates to #6654
<mup> PR #6654: packaging/fedora, tests/upgrade/basic: patch existing mount units with SELinux context on upgrade <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6654>
<pstolowski> mborzecki: thanks, will take a look in a moment
<pedronis> pstolowski: 6629 just needs two review nows, I don't need to explicitly review it
<pstolowski> pedronis: ack, thanks
<zyga> mvo: this is what I meant yesterday https://github.com/snapcore/snapd/pull/6642/commits/758c968ced00023d98da61c457add8c04498781b
<mup> PR #6642: cmd/snap-confine: prevent cwd restore permission bypass <Created by zyga> <https://github.com/snapcore/snapd/pull/6642>
<mvo> zyga: ta
<zyga> mvo: I'm sure it will need more work because we didn't realise it was broken before
<zyga> but this should now pass
<zyga> and since it is now tested, we will not see this mistake again
<zyga> (core18 caveat applies)
<zyga> (core18 is mostly untested)
 * mvo nods
<mup> PR snapd#6659 opened: snapcraft: build static fontconfig in the snapd snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/6659>
<mup> PR core#104 opened: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
<mborzecki> any idea why we prefer to put completion files under /usr/share/bash-completion/completion rather than /etc/bash_completion.d/ ?
<cjwatson> /etc/bash_completion.d/ is an old compatibility directory
<cjwatson> and it's not just a matter of location, it's actually handled differently
<cjwatson> files in the compat directory are all loaded up-front, whereas files in /usr/share/bash-completion/completion/ are loaded dynamically when needed
<cjwatson> so installing files in the compat directory imposes a cost on every interactive shell (that loads bash-completion, anyway)
<Facu> Muy buenos dÃ­as a todos!
<mborzecki> cjwatson: thanks!
<cjwatson> np, happened to be reading up about that recently for something else
<Chipaca> cjwatson: mborzecki: also files in /etc/bash_completion.d are _only_ loaded up front, meaning you get no completion for a snap you install until you start a new (login, some places) shell
<Chipaca> also the /usr/share path is more cross-distro than the /etc one
<cjwatson> Yeah, that too
<Chipaca> mvo: your triage on https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1821956 makes me think you think it's something we should fix
<mup> Bug #1821956: snapd can't start in WSL (Windows Subsystem for Linux) <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1821956>
<Chipaca> mvo: I thought supporting WSL was a non-goal
<mborzecki> Chipaca: that would actually be intersting :)
<Chipaca> mborzecki: would it?
<Chipaca> no services and no GUIs
<Chipaca> and no confinement
<mborzecki> i mean intersting challenge, though feels a bit academic
<Chipaca> and no squashfs
<mup> Bug #1821959 changed: File name breaking go modules <snapd:New> <https://launchpad.net/bugs/1821959>
<Chipaca> mvo: what's 'cmd/snap-confine/spread-tests/distros/debian.' about? (why the ending period?)
<zyga> Chipaca: that's sid
<zyga> Chipaca: because no version id
<Chipaca> i know it's sid
<zyga> and that is dead
<zyga> the ending period is because it is id.version_id
<zyga> mvo: can you please look at https://github.com/snapcore/snapd/pull/6410 again
<mup> PR #6410: release-tools: add debian-package-builder <Created by zyga> <https://github.com/snapcore/snapd/pull/6410>
<zyga> mvo: https://github.com/snapcore/snapd/pull/6643 is the fix that was under embargo before, I think we should just land this patch for historical reference and iterate on anything we planned to (e.g. generator)
<mup> PR #6643: tests: deny ioctl - TIOCSTI with garbage in high bits <Created by zyga> <https://github.com/snapcore/snapd/pull/6643>
<zyga> I need a 2nd review for https://github.com/snapcore/snapd/pull/6597
<mup> PR #6597: cmd/snap-update-ns: refactor of profile application (1/N) <Created by zyga> <https://github.com/snapcore/snapd/pull/6597>
<zyga> I also need a 2nd review for https://github.com/snapcore/snapd/pull/6502
<mup> PR #6502: dirs,overlord/snapstate: add Soft and Hard refresh checks <Created by zyga> <https://github.com/snapcore/snapd/pull/6502>
<zyga> jdstrand: I need your 3rd review on https://github.com/snapcore/snapd/pull/6605
<mup> PR #6605: cmd/libsnap,osutil: fix parsing of mountinfo <Created by zyga> <https://github.com/snapcore/snapd/pull/6605>
<jdstrand> zyga: it is on my todo. may not happen today, will try to get to it soon
<zyga> jdstrand: thanks, that's all I need
<mup> PR snapd#6658 closed: testutil: run mocked commands through shellcheck <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6658>
<mvo> pedronis: is 6621 something you want to review again? it got two +1 and your naming suggestion is applied
<pedronis> mvo: I think John preferred it not to land before it's used
<pedronis> mvo: it's marked blocked
 * mvo nods
<mup> PR snapd#6660 opened: [RFC] cmd/debug: integrate new task timings with "snap debug timings" <Created by stolowski> <https://github.com/snapcore/snapd/pull/6660>
<pedronis> mvo: I just noticed we have a bunch of places that depend on osutil.CommandFromCore
<zyga> pedronis: hey, I made some tweaks to https://github.com/snapcore/snapd/pull/6583/files
<mup> PR #6583: cmd/snap-confine: move ubuntu-core fallback checks <Created by zyga> <https://github.com/snapcore/snapd/pull/6583>
<zyga> pedronis: I wonder if we could discuss what's wrong in that idea now and see how to move onwards
<zyga> pedronis: to unblock core18 fixes and core16 transition
<pedronis> mvo: that doesn't seem to support snapd at all, also I don't remember it, and osutil feels a bit the wrong place for it
<pstolowski> mvo: hey, can you have another look at https://github.com/snapcore/snapd/pull/6629 ?
<mup> PR #6629: overlord/snapshotstate: helpers for dealing with snapshot expirations (automatic snapshots 2/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/6629>
 * Chipaca lunches
<pedronis> zyga: it's better than the last time I looked
<pedronis> zyga: I don't like _fallback and forcing all the code to use a helper though
<pedronis> it defeats a bit the original goal of having the struct at all
<zyga> pedronis: perhaps I can just set "effective"
<zyga> and always use that
<pedronis> zyga: I'm making a suggestion
<zyga> ok
 * zyga missed the suggestion about "original" field instead
<zyga> it would have equivalent semantics I guess
<mup> PR snapd#6661 opened: data/selinux, tests/main/selinux-clean: fine tune the policy, make sure that no denials are raised <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6661>
<mborzecki> hopefully a final SELinux related PR ^^
<pedronis> zyga: I commented in the PR
<zyga> pedronis: thanks, that looks great
<pedronis> zyga: btw, relatedly bu drive-by,  should classic.c  be called  distro.c instead ? it doesn't seem to be just about classic
<sergiusens> Chipaca: hello there, I have a question about this message "Channel latest/stable for lxd is closed; temporarily forwarding to stable.". Is that going to be fixed at any point in time?
<pedronis> sergiusens: it should have been fixed
<sergiusens> pedronis: 2.38? candidate I guess? I can switch and verify if so
<sergiusens> I am currently on 2.37.4+18.04.1
<pedronis> sergiusens: yes, 2.38
<pedronis> 2.37 doesn't have the new code
<pedronis> anyway 2.38 will go to stable today
<zyga> pedronis: yeah, it's an ancient name
<zyga> pedronis: perhaps it can be folded further into something else
<pedronis> zyga: lost context, what is an ancient name?
<zyga> pedronis: classic.c
<pedronis> ah
<pedronis> ok
<pedronis> it doesn't seem to match the content anymore
<zyga> pedronis: it's from the day when snap-confine was ubuntu-core-launcher, mostly all in one C file
<zyga> pedronis: and was not very friendly to work with
<zyga> pedronis: so as first instinct to understand I started to decompose it
<pedronis> yea, it's fine
<pedronis> I just noticed given we were looking into it again
<zyga> that's good, I'm very happy to make changes to it, my main demotivator in the past was that it would require a security review and slow everything down to a crawl
<mup> PR snapd#6662 opened: overlord/snapstate,snapshotstate: create snapshot automatically on snap removal <Created by stolowski> <https://github.com/snapcore/snapd/pull/6662>
<zyga> pedronis: updated
<mborzecki> hm travis jobs are progressing rather slow today
<pedronis> zyga: last pass,  couple more comments
<zyga> I saw, doing now :)
<mvo> pedronis: thanks, I check commandFromCore
<mvo> pstolowski: yeah, I have a look
<pstolowski> ty
<ondra> cwayne any luck testing that core18 image? shall I rev for you also core16 image with that kernel?
<cwayne> ondra: so it did boot, but the usb -> eth dongle were using wasnt supported with that kernel
<ondra> cwayne OK that would be something to ask ppisati if there there is right driver included
<mup> PR snapcraft#2512 closed: many: better handling of appstream icons <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2512>
<zyga> mvo: after the call, can you have a 2nd look at https://github.com/snapcore/snapd/pull/6583
<mup> PR #6583: cmd/snap-confine: move ubuntu-core fallback checks <Created by zyga> <https://github.com/snapcore/snapd/pull/6583>
 * zyga needs to grab some food
<mvo> zyga: yes
<jdstrand> pedronis, niemeyer (cc mvo, joemcmanus, amurray): I wrote https://forum.snapcraft.io/t/phase-1-of-opt-in-per-snap-users-groups-aka-the-daemon-user/10624. I am not currently blocked and have a lot to work on that isn't dependent on that. so, feel free to ponder
<mvo> jdstrand: thank you
<pedronis> jdstrand: thanks, I will look at it early next week the latest
<jdstrand> pedronis: ack. that works well for me. I can go with the 'easiest-to-change-later' option in my coding until then
<mup> PR core18#123 opened: hooks: remove /etc/apt/sources.list.d/proposed.list <Created by mvo5> <https://github.com/snapcore/core18/pull/123>
<mup> PR snapd#6655 closed: timings: AddTag helper <Simple ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6655>
 * cachio afk 
<pstolowski> can https://github.com/snapcore/snapd/pull/6657 land?
<mup> PR #6657: tests: enable opensuse 15 and add force-resolution installing packages <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6657>
<zyga> pstolowski: looking
<zyga> yes!
<pstolowski> g8
<pstolowski> ty
<mup> PR snapd#6657 closed: tests: enable opensuse 15 and add force-resolution installing packages <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6657>
<mup> PR snapd#6663 opened: cmd: make fmt <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6663>
 * zyga goes for a bike ride 
<zyga> I'll be back after dark
<zyga> I have a few PRs that need 2nd review and a few more that just wait for green
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37
<mup> PR snapd#6664 opened: cmd/snap,client,daemon,store: layout and sanity tweaks for find/search options <Created by pedronis> <https://github.com/snapcore/snapd/pull/6664>
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#104 closed: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#104 opened: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
<cachio> mvo, pedronis 2.38 is stable now
<cachio> smoke tests have passed
<mvo> cachio: thank you!
<cachio> mvo, yaw
<cachio> mvo, is it ok if I fix https://github.com/snapcore/snapd/pull/6594 ?
<mup> PR #6594: [RFC] tests: run smoke tests on (almost) pristine systems <Created by mvo5> <https://github.com/snapcore/snapd/pull/6594>
<mvo> cachio: sure, much appreicated actually
<ondra> cwayne when  I did another run on that 4.15 kernel I saw some usb errors, and USB hub was dead. You better check if usb was working at all, might not have been incompatibility of you usb->eth
<ondra> you-your
 * cachio afk
 * zyga noticed odd failure to debug tomorrow
<zyga> time to get some sleep, good night!
#snappy 2019-03-29
<mwhudson> uh it seems you can use the snapd api to switch a snap to the '' channel
<zyga> mwhudson: I will tell John
<mborzecki> morning
<mborzecki> hmm 2019-03-28 22:17:21 Error preparing google:ubuntu-18.04-64:tests/main/ :
<mborzecki> core                       6673  stable    canonical*         broken
<mborzecki> mvo: morning
<mborzecki> mvo: master seems broken now
<mvo> mborzecki: hey, morning
<mborzecki> mvo: for some reason there are no mount units for the snaps
<mvo> mborzecki: what is the error?
<mvo> mborzecki: woah
<mborzecki> mvo: https://paste.ubuntu.com/p/3Kqjg7j76W/
<mvo> mborzecki: the core18 snap changed since yesterday
<mborzecki> mvo: snapd log https://paste.ubuntu.com/p/fNmpTNYMFj/
<mvo> http://people.canonical.com/~mvo/core18-changes/html/edge/unknownr828_unknownr834.html
<mvo> but nothing that would explain why mount units are missing
<mvo> mborzecki: what do you see in ls /etc/systemd/system/snap* ?
<mborzecki> mvo: no mount units, only snapd.{service,socket} overrides
<mvo> mborzecki: woah
<mvo> mborzecki: according to travis it started with the most recent master merge but that was just enabling suse again
<mvo> mborzecki: so that does not make much sense
<mvo> mborzecki: is it just ubuntu-18.04?
<mborzecki> mvo: yes, but sa the same on 18.10
<mborzecki> s/sa/saw/
<mvo> mborzecki: but not older ubuntus or other distros?
 * mvo scratches head
<mborzecki> mvo: come to think of it, i only saw 18.*
<mvo> mborzecki: it does not make much sense, does it :)
<mvo> mborzecki: the joy of debugging things
<mvo> mborzecki: I will try to reproduce and look for clues
<mborzecki> mvo: checked 4 PRs, only 18.04
<zyga> good morning!
<zyga> mvo: hey, I found some odd things last night
<zyga> I came to check on my tests and found that core18 failed
<zyga> while it passed (though I ran the test in isolation) earlier that day
<mborzecki> zyga: hey
<mborzecki> mvo: installing hello-world actually works (?!)
<zyga> mborzecki: because snapd thinks core is there
<mborzecki> and refreshing core from --edge worked too, thereis a mount unit now and all
<pstolowski> morning
<mborzecki> heh ausearch -m AVC --checkpoint <file> doesn't work on centos :/
<zyga> pstolowski: fusion update today
<mvo> mborzecki: very strange, anyway, qemu running here, I'm curious about the results. maybe one of our scripts goes wild?
<mvo> mborzecki: in the tests restore/prepare
<zyga> pstolowski: I'm just installing it
<mvo> mborzecki: but then we did not change those in a while
<zyga> pstolowski: word of caution, it restarts session apps
<mvo> iirc
<pstolowski> zyga: ah, thanks for hint, indeed. installing as well
<zyga> pstolowski: it will restart browser / etc
<zyga> careful :)
<pstolowski> zyga: ha.. ok
<zyga> https://docs.vmware.com/en/VMware-Fusion/11/rn/fusion-1103-release-notes.html just fixes
<zyga> https://www.bing.com/th?id=OHR.AurovilleIndia_ROW0132522166_1920x1080.jpg <- amazing wallpaper of the day
<mborzecki> lxd from snaps doesn't work on centos :/
<zyga> rm: cannot remove '/var/cache/snapd/aux': Is a directory
<zyga> what is aux?
<zyga> is that the auxiliary store stuff?
<mvo> yeah
<zyga> so, public service announcement: I'm off today
<zyga> perhaps I should look at why the world is so red today
<mborzecki> zyga: do you want to take a last look at https://github.com/snapcore/snapd/pull/6634 or can i land it?
<mup> PR #6634: snap: add validation of gadget.yaml <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6634>
<zyga> mborzecki: looking
<zyga> let me just page through quickly
<mborzecki> ok
<mborzecki> zyga: i see you're wodnering too about the name/label thing in gadget.yaml
<zyga> yeah
<zyga> I didn't notice it before
<zyga> because of go fmt's reshuffling of the whole blog
<zyga> block
<mborzecki> heh
<mborzecki> maybe renaming it to FilesystemLabel would be useful
<mborzecki> zyga: though, a follow up mabye? i'd like to avoid the full ci cycle again, given that it's fragile today
<zyga> but what is the difference?
<zyga> sure
<pedronis> mborzecki: hi, name is also used in relative offsets, no?
<zyga> mborzecki: almose done
<zyga> mborzecki: reviewed
<zyga> mborzecki: can you help me get https://github.com/snapcore/snapd/pull/6597 landed
<mup> PR #6597: cmd/snap-update-ns: refactor of profile application (1/N) <Created by zyga> <https://github.com/snapcore/snapd/pull/6597>
<zyga> it needs a 2nd review
<zyga> alterenatively https://github.com/snapcore/snapd/pull/6502
<mup> PR #6502: dirs,overlord/snapstate: add Soft and Hard refresh checks <Created by zyga> <https://github.com/snapcore/snapd/pull/6502>
<zyga> mvo can  you review https://github.com/snapcore/snapd/pull/6410 please
<mup> PR #6410: release-tools: add debian-package-builder <Created by zyga> <https://github.com/snapcore/snapd/pull/6410>
<mvo> zyga: sure
<zyga> thank you
<mvo> mborzecki: hm, strange, "spread qemu:ubuntu-18.04-64" works here with master, thats odd
<mvo> zyga: I looked at 6583, it fails to build right now but I can take care of this if you want
<zyga> looking
<zyga> mvo: hmm
<zyga> hmm
<zyga> odd
<zyga> please let me dig at this
<zyga> I have a few PRs that need a 2nd  review
<zyga> those would be good to land instead :)
<mborzecki> pedronis: yes, name is also used for refrring to structures in relative addressing
<mup> PR snapd#6410 closed: release-tools: add debian-package-builder <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6410>
<zyga> \o/ thanks mvo
<zyga> mvo: perhaps  this one https://github.com/snapcore/snapd/pull/6502 <- it's not that long
<mup> PR #6502: dirs,overlord/snapstate: add Soft and Hard refresh checks <Created by zyga> <https://github.com/snapcore/snapd/pull/6502>
<mborzecki> haha revolut is preparing for no-deal brexit :P
<zyga> what are they doing?
<mborzecki> zyga: need to verify your identity again if you previously used a driver's license for verification
<zyga> odd
<zyga> how is that related?
<mborzecki> zyga: because they'd apparently need to migrade to a seaprate legal entity taht's in the eu (right now it's uk based)
<zyga> lol
<zyga> I feel sorry for people in the UK
<zyga> monty python live show
 * Chipaca notes he isn't working today
 * mvo hugs Chipaca and shushes him away
<mup> PR snapd#6665 opened: overlord/ifacestate: implement String() method of HotplugDeviceInfo for better logs/messages <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6665>
<zyga> brb, need some food
<zyga> mborzecki: I'll review  in a m oment
<pstolowski> zyga: can you finish the review of https://github.com/snapcore/snapd/pull/6629 when you have a moment (needs second +1)
<mup> PR #6629: overlord/snapshotstate: helpers for dealing with snapshot expirations (automatic snapshots 2/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/6629>
<pstolowski> ?
<zyga> pstolowski: sure
<zyga> pstolowski: looking now
<pstolowski> zyga: ty!
<zyga> pstolowski: done
<zyga> pstolowski: you resolved https://github.com/snapcore/snapd/pull/6629#discussion_r270354045 without  commenting
<mup> PR #6629: overlord/snapshotstate: helpers for dealing with snapshot expirations (automatic snapshots 2/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/6629>
<zyga> ah, sorry, wrong link
<zyga> https://github.com/snapcore/snapd/pull/6629/files#r268534384
<zyga> this one
<pstolowski> zyga: hmm it shows me entire PR. do you mean the discussion where you proposed having "snapshots" key defined at the global level to avoid typos?
<zyga> pstolowski: cutoff  vs cut-off
<zyga> line 130 of snapshotstate.go
<pstolowski> zyga: yes, sorry about that, i thought i added it to the batch of github commits but didn't. should be fixed now
<pstolowski> zyga: thanks for the review!
<zyga> no worries, it's a bikeshed comment so you can always contend that :)
<zyga> pstolowski: reviewed https://github.com/snapcore/snapd/pull/6665#pullrequestreview-220472935
<mup> PR #6665: overlord/ifacestate: implement String() method of HotplugDeviceInfo for better logs/messages <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6665>
 * zyga watches https://www.theguardian.com/politics/blog/live/2019/mar/29/brexit-debate-latest-developments-live-news-may-at-risk-of-fresh-defeat-as-mps-debate-withdrawal-agreement-for-third-time-live-news
<zyga> any more reviews I can do
<zyga> please shoot URLs at me
<zyga> anyone
<zyga> pstolowski: does hotplug help here? https://forum.snapcraft.io/t/snapd-interfaces-dev-tty-0-9-read-write/10645
<mup> PR snapd#6666 opened: Change file names that are breaking go modules <Created by slimjim777> <https://github.com/snapcore/snapd/pull/6666>
<pstolowski> zyga: sorry, i had 1-1, will take a look in a moment
<zyga> sure
<mborzecki> hm trying to track down one selinux denial, idk why it happens, but snap is poking /proc/<pid>/stat of some process
<mborzecki> i have a hunch that it's hooks and go runtime related
<zyga> what does the denial look like?
 * cachio afk
<mborzecki> zyga: https://paste.ubuntu.com/p/SMP6VzNR6r/
<zyga> oh, from snapd itself
<zyga> interesting
<mborzecki> yeah
<mborzecki> my bet is go runtime doing something funny
<zyga> yes
<zyga> what is that pid?
<zyga> is 5612 still running
<mborzecki> no
<mborzecki> and it isn't the pid of the shell tha ran snap install|remove
<mborzecki> on top, it's centos, can't perf record what's starting :/
<zyga> maybe it is related to snapctl and peers over sockets somehow
<zyga> mborzecki: I'm doing some IO so I cannot search now
<zyga> but perhaps check for "proc" and "stat" in golang tree?
<zyga> looking gnow
<mborzecki> hmmmm
<mborzecki> switched the policy to non-permissive, and, calling systemctl daemon-reload failed :/
<pstolowski> zyga: yes, i think we could have a new tty interface that utilizes hotplug and creates single slot for every ttyN
<zyga> mborzecki: funn
<zyga> mborzecki: I cannot find anything in the tree that does this
<zyga> perhaps in our vendor tree?
<zyga> mborzecki: polkit
<zyga> ./polkit/pid_start_time.go:     filename := fmt.Sprintf("/proc/%d/stat", pid)
<zyga> it must be polkit
<zyga> pstolowski: can you update the thread please?
<mborzecki> omg
<pstolowski> zyga: will do
 * pstolowski lunch
<mvo> zyga, mborzecki I have a theory about why ubuntu-18.04 is now failing - I suspect we started seeding cloud-sdk
<mvo> in the official images
<zyga> oh
<zyga> can you tell me moree
<zyga> so ubuntu 18.04 in the cloud has  changed?
<zyga> and what does cloud-sdk do?
<mborzecki> interesting
<mborzecki> that's google cloud sdk?
 * zyga afk
<mborzecki> ok, so disabling dontaudit and disabling permissive mode is actually enlightening
<mborzecki> i can now install remove lxd snap with selinux in enforcing and without permissive flags in our policy
<zyga> Wooot
<zyga> That is a great milestone mborzecki
<ijohnson> mborzecki: nice \o/
<cachio> mvo, 18.04 error should be fixed once the new image is generated
<cachio> it could take 20/30 minutes
<mvo> cachio: yeah, I think I found the issue, the snapd purge does not work
<mvo> cachio: because /var/cache/snapd/aux cannot be removed
<mvo> cachio: and new images will fix that so yay!
<cachio> mvo, I think so, so far all the tests are passing, also I added some checks to validate the imgae
<mvo> cachio: yeah
<mvo> cachio: thanks
<cachio> mvo, yaw
<Saviq> zyga: one for you: https://github.com/CanonicalLtd/multipass/pull/702#issuecomment-478036255
<mup> PR CanonicalLtd/multipass#702: [snap] add libssl1.1 from bionic for Qt's consumption <Created by Saviq> <https://github.com/CanonicalLtd/multipass/pull/702>
<Saviq> zyga: I'll trade you for https://forum.snapcraft.io/t/chaining-dependencies/10581 ;)
 * cachio lunch
<zyga> Saviq: looking
<zyga> nice, thank you :)
<zyga> I'm looking at that in relation to another mount namespace behavior
<zyga> but I'm off today so not much progress
<Saviq> slacker ;)
<zyga> Saviq: that last year's quota has to burn :)
<alan_g> mvo, we've encountered a problem with mir-kiosk starting on core18. With ogra's help I've traced it to "vt.handoff=2" in system-boot/cmdline.txt. Could you remove that please? https://github.com/MirServer/mir/issues/779
<mvo> alan_g: could you please add a github issue against https://github.com/snapcore/pc-amd64-gadget ?
<mvo> alan_g: and/or provide a patch there :) technically this is the foundations team now (sil2100 is the main contact currently)
<mvo> alan_g: but we still like to help
<alan_g> mvo, sure. (I get into this so seldom I don't know who to ask)
<ogra> mvo, thats a pi issue, not amd64 ;)
<alan_g> mvo, that should be https://github.com/mvo5/pi-gadget/blob/master/configs/cmdline.txt
<alan_g> I think
<ogra> https://github.com/snapcore/pi-gadget
<ogra> that one (i think :) )
<alan_g> Ah yeah, too many repos,
<ogra> yup
<mvo> ogra: oh, sorry
<alan_g> Hm that one doesn't have any issues.
<mvo> alan_g: so you can be the first one!
<ogra> and wint a price !
<mvo> alan_g: thanks for raising this btw and no worries, we are here to help
<ogra> *win
<alan_g> mvo, as in nowhere to put them
<ogra> send a postcard to sil2100 then
<mvo> alan_g: oh, let me look
<alan_g> It has PRs, so I'll do that
<alan_g> (after tea break)
<mvo> alan_g: \o/ and I will investigate why there are no issues enabled
<mvo> alan_g: I actually think this was deliberate that they are disabled. LP seems to be the bugtracker. however it also seems like we need to communicate this better. I will sync with lukasz about this
<alan_g> mvo, ogra FYI https://github.com/snapcore/pi-gadget/pull/12
<mup> PR pi-gadget#12: Enable mir-kiosk to start on Ubuntu Core 18/RPi 3 <Created by AlanGriffiths> <https://github.com/snapcore/pi-gadget/pull/12>
<mvo> alan_g: \o/
<mvo> alan_g: thank you
<alan_g> mvo, np - the hard part was tracking down where.
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37
<mup> PR snapcraft#2506 closed: schema, tests: add more detail wrt numeric version errors <Created by adanhawth> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2506>
 * cachio afk
<mup> PR snapcraft#2519 opened: packaging: use local patchelf <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2519>
#snappy 2019-03-30
<kreyren> more info so that i dont have to read docs to fix it? http://dpaste.com/3XRWS0X
#snappy 2020-03-23
<mborzecki> morning
<zyga> good morning
<zyga> mborzecki: how was your weekend?
<mborzecki> zyga: indoors mostly ;)
<mborzecki> zyga: is it equally cold in waw?
<zyga> me too, what a coincidence :)
<zyga> I see we had a 2.44.1
<zyga> anything special on Friday?
<mborzecki> zyga: idk, spent almost whole friday fighting console conf
<zyga> re
<pstolowski> mornings
<mvo> good morning zyga and pstolowski
<zyga> hey pawel, hey mvo
<zyga> I'm not sure how it's around where you live
<mborzecki> pstolowski: mvo: morning guys
<zyga> but when I walked outside earlier today
<zyga> it was so so incredibly quiet
<zyga> I heard birds chirping and not much else
<zyga> I saw maybe four cars on a wide artery that is normally stuck in traffic at this time
<zyga> it's so surreal
<zyga> travis very non responsive today
<zyga> at least for me
<mvo> zyga: yeah, travis had half-a-day of database upgrade at saturday
<zyga> uh
<mvo> zyga: and I no longer have the "rebuild" button
<zyga> what could possibly go wrong now
<zyga> I'm trying to open or restart runs
<mvo> zyga: can you still restart runs?
<zyga> no, I cannot get the pages to load
<zyga> travis times out, gh is responding fast
<mup> PR snapd#8315 opened: tests: ensure session agent service is ready in prepare <Created by mvo5> <https://github.com/snapcore/snapd/pull/8315>
<mup> PR snapd#8316 opened: github: add prototype workflow running unit tests <Created by zyga> <https://github.com/snapcore/snapd/pull/8316>
<pedronis> jamesh: hi, we sometimes see failures of snap-session-agent-service-control , https://api.travis-ci.org/v3/job/665599033/log.txt
<jamesh> looking
<pedronis> jamesh: seems mvo was also looking in that: https://github.com/snapcore/snapd/pull/8315
<mup> PR #8315: tests: ensure session agent service is ready in prepare <Created by mvo5> <https://github.com/snapcore/snapd/pull/8315>
<mvo> jamesh: yeah, if you could review that PR 8315 that would be great
<mup> PR #8315: tests: ensure session agent service is ready in prepare <Created by mvo5> <https://github.com/snapcore/snapd/pull/8315>
<mvo> jamesh: it might be too simplistic
<jamesh> mvo: is there a systemctl invocation to wait for a unit to be started?
<jamesh> e.g. I wonder if we could do "systemctl --user start sockets.target"?
<mvo> jamesh: maybe, this is also about socket activation so start might test less than what we tested before?
<jamesh> mvo: the tests expect that sockets.target has completed: i.e. systemd has created the unix domain socket and is prepared to start the session agent when someone connects to it
<zyga> hey pedronis, good morning
<zyga> pedronis: do you remember that A=$B; B=$C; C=foo; problem my earlier implementation of environment untangled?
<jamesh> I don't think this would meaningfully change what is being tested, and might get rid of the race
<pedronis> zyga: yes
<pedronis> is somebody trying to do that?
<zyga> pedronis: it seems snapcraft has a bug where it would be useful, it reorders environment entires, it sorts them :|
<zyga> pedronis: I filed a bug for snapcraft
<pedronis> it's definityl a snapcraft bug
<zyga> yeah
<zyga> just found this ironic
<mvo> jamesh: ok, feel free to push something else to the PR or a new one, happy with a better fix :)
<jamesh> mvo: I don't think I can edit other peoples' PRs, so I'll create a new one
<mvo> jamesh: thank you
<mup> PR core20#28 opened: Add iptables package <Created by alfonsosanchezbeato> <https://github.com/snapcore/core20/pull/28>
<mup> PR snapd#8317 opened: many: make sure ephemeral failover snapd does not open sockets <Created by pedronis> <https://github.com/snapcore/snapd/pull/8317>
<zyga> please review https://github.com/snapcore/snapd/pull/8316
<mup> PR #8316: github: add prototype workflow running unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8316>
<zyga> last run was one minute and 55 seconds
<zyga> for "go test" results
<mup> PR snapd#8298 closed: many: enumerate system seeds, return them on the /v2/systems API endpoint <UC20> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8298>
<zyga> brb
<mup> PR snapd#8318 opened: tests: ensure sockets target is ready in session agent spread tests <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8318>
<mup> PR snapd#8318 closed: tests: ensure sockets target is ready in session agent spread tests <Created by jhenstridge> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8318>
<pedronis> mvo: I think you closed the wrong PR ^  8318 sees it was closed in favor of 8318
<pedronis> s/sees/says/
<mvo> pedronis: oh, sorry, /me is a muppet
<mup> PR snapd#8318 opened: tests: ensure sockets target is ready in session agent spread tests <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8318>
<mup> PR snapd#8315 closed: tests: ensure session agent service is ready in prepare <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8315>
<pstolowski> pedronis: hi, i pushed some changes to search v2 wrt error-list. it turned out to be slightly annoying and the change may look a bit confusing, happy to discuss
<pedronis> pstolowski: thx, in a meeting atm
<mup> PR snapd#8319 opened: github: run unit tests and spread via github actions <Created by zyga> <https://github.com/snapcore/snapd/pull/8319>
<zyga> wow, github actions runner is FOSS
<zyga> https://github.com/actions/runner
<zyga> and can run on hosted machines
<zyga> this is neat https://github.com/actions/labeler
<zyga> action to put labels based on what's changed in the tree
<ackk> zyga, hi, any chance https://github.com/snapcore/snapd/pull/8265 can be merged? I'd be happy to test a snapd snap with that fix
<mup> PR #8265: tests: add regression test for MAAS refresh bug <Created by zyga> <https://github.com/snapcore/snapd/pull/8265>
<zyga> ackk: this is just a regression test, there's no fix there
<zyga> the fix has been merged and is behind a feature flag, long ago
<ackk> zyga, the https://trello.com/c/QjX63wGx/201-4-document-snap-downgrade ?
<ackk> zyga, I'm still seeing that issue with it enabled
<ackk> zyga, it happens all the time for me
<ackk> install/refresh/remove
<zyga> I cannot see that
<ackk> actually,even when I connect interfaces
<zyga> let me log in
<ackk> zyga, sorry, wrong link
<alvesadrian> good morning
<alvesadrian> zyga
<ackk> zyga,  I meant if it's robust-mount-namespace-updates
<alvesadrian> there is way to sort this with jetty
<ackk> copy/paste is a  bit messed up in focal
<zyga> ackk: I'm sorry, is this different from any of the earlier fixes we did recently?
<alvesadrian> zyga https://pastebin.com/W9iT0sF3
<ackk> zyga, wdym?
<zyga> ackk: I'm confused
<zyga> ackk: can you tell me if the thing that is failing is one of the things we inspected last week
<alvesadrian> Starting Jetty: chown: changing ownership of '/tmp/oxauth.pid': Operation not permitted
<alvesadrian> su: must be run from a terminal
<zyga> alvesadrian: I'm sorry, I cannot debug things for you
<ackk> zyga, https://paste.ubuntu.com/p/mjV2zR4Pcn/ is an example of failure
<alvesadrian> zyga is not a debug
<alvesadrian> am not asking for that
<zyga> ackk: does this represent one of the failures we've inspected before or is a new failure?
<alvesadrian> is how or why snap is failing to run a jetty app using jetty and the app in the same yaml
<ackk> zyga, I'm not sure. one question I have is, does snap-discard-ns clean up everything? I wonder if running that might cause issues with later operations
<alvesadrian> zyga where i can find snapcraft.yaml
<zyga> ackk: yes it does
<alvesadrian> zyga for java server apps
<zyga> ackk: it should be invoked when there are no processes around, otherwise you fracture the view, some inhabit old world, some new
<zyga> alvesadrian: I don't know, did you try checking on the forum?
<alvesadrian> yes
<zyga> alvesadrian: since you mentioned chown, snaps should not change ownership of files
<alvesadrian> if course i already open a ticket
<zyga> ticket?
<alvesadrian> sorry a post
<ackk> zyga, so, just rebooted the container, I get this: https://paste.ubuntu.com/p/NVQ34Jvwxw/
<zyga> ackk: I'm not entirely sure what rebooting a container does
<zyga> does it really discard mount namespaces?
<alvesadrian> zyga https://forum.snapcraft.io/t/issues-with-different-users-chown-and-su/16129
<ackk> zyga, well, it should? I mean it's like a a machine reboot
<zyga> I don't know
<zyga> that's a lxd question
<zyga> alvesadrian: please familiarize yourself with https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461
<alvesadrian> i already read that
<ackk> zyga, what should I check to see if the correct namespaces are set up?
<alvesadrian> i cannot find a snapcraft.yaml file as example of people bullding a java app with the tocamcat or jetty on it
<zyga> great, then you should understand that you cannot chown anything to 1000 or most other values
<zyga> I cannot help you beyond that, I don't even know what jetty is
<alvesadrian> that will be great for me but i cannot find it like nobody did an snap of hat
<alvesadrian> jetty==tomcat
<zyga> ackk: it's hard because of startup services,
<zyga> ackk: can we spin it another way? can you report a bug with reproducer?
<zyga> ackk: I cannot promise I will look instantly
<zyga> as we have some other fires
<zyga> but I will do my best
<ackk> zyga, sure I'll try
<alvesadrian> couldnt find any example of snaocraft.yal for a java app containing a tomcat on it
<alvesadrian> or a java server app to serve the app
<zyga> I don't know anything about tomcat but I googled some results
<zyga> did you go over the first few hits?
<alvesadrian> nothing man
<alvesadrian> being the whole weekend digging
<alvesadrian> its like nobody build it a snappy for tomcat app or java server app
<alvesadrian> forget about tomcat, just mean a java server app
<alvesadrian> nobody builds java server apps on snaps
<zyga> alvesadrian: did you check out https://snapcraft.io/docs/java-applications ?
<alvesadrian> course
<zyga> can you post some feedback about that to the forum
<zyga> I'm sorry, I"m not the spokesperson for snapd :)
<zyga> I cannot help everyone
<alvesadrian> didnt mention anything about using an external java serer as source
<alvesadrian> i know
<alvesadrian> just wondering if u know something about it
<zyga> I don't know what an external java server is (is that tomcat?)
<alvesadrian> thans
<alvesadrian> external means dont using the plug of jdk
<alvesadrian> thata what i mean getting from source
<alvesadrian> download it and running
<alvesadrian> thats what i mean
<zyga> what does "the plug of jdk" mean?
<alvesadrian> like a snap that fetch tomcat(java server) and run the app inside
<zyga> why fetcH?
<zyga> why not bundle tomcat at build time?
<alvesadrian> the pluging for the jdk framework
<alvesadrian> what u mean?
<alvesadrian> an example?
<zyga> maybe I misunderstand but from what you are saying the snap package would, after being installed, download tomcat and do something with it
<alvesadrian> nope
<alvesadrian> snap has a part tomcat and anotehr part for the java app
<zyga> I see
<zyga> and what is the problem there?
<zyga> downloading tomcat?
<ackk> zyga, fwiw https://paste.ubuntu.com/p/wQpmk2mkcS/ reproduces it for me. I'm not sure whether to file a new bug or it's just a manifestation of the previous one?
<alvesadrian> i cant find an example about how to
<zyga> alvesadrian: is tomcat special? is downloading it different from downloading other files?
<alvesadrian> place it and run it with the java app
<alvesadrian> nope
<alvesadrian> just a source zip file
<alvesadrian> static
<zyga> alvesadrian: did you check the snapcraft documentation for parts?
<alvesadrian> it will run a daemon
<zyga> there's a way to download things there
<zyga> source: URL
<alvesadrian> yes
<zyga> it can fetch tomcat, or whatever
<zyga> so?
<zyga> ackk: at this rate, I'd say please file one
<zyga> even if it's a dupe
<ackk> zyga, ok
<zyga> it's easier for me to keep a TODO list this way
<zyga> ackk: I'm sorry for the issues, it's likely that maas has found more bugs than an average snap by now :)
<ackk> zyga, we like to live on the bleeding edge :)
<zyga> alvesadrian: so can you download tomcat using snapcraft part or not?
<alvesadrian> yes
<alvesadrian> as a part
<zyga> ok, so what's the problem again?
<alvesadrian> not tomcat specially jetty but they are similar
<alvesadrian> after download
<alvesadrian> move the java app into the webapp folder
<alvesadrian> but not cluu how to run it
<zyga> with a service declaration
<ackk> alvesadrian, add an app: with daemon:simple and command pointing to a script which runs tomcat?
<zyga> (remember to exec in the last line of the script)
<alvesadrian> where i can get a snapcraft.yaml with an example
<alvesadrian> about how to do it?
<zyga> I really think you should slow down and look at snapcraft docs
<ackk> zyga, oh, so maybe I'm still hitting https://bugs.launchpad.net/snapd/+bug/1867752 actually
<mup> Bug #1867752: Unable to remove snap with content interface (with robust namespace update) <snapd:Fix Committed by zyga> <https://launchpad.net/bugs/1867752>
<zyga> https://snapcraft.io/docs/services-and-daemons
<ackk> zyga, is this available in a snapd snap?
<alvesadrian> so i need to create a service declaration to run the script that start tomcat?
<ackk> alvesadrian, yes
<zyga> alvesadrian: ^ please check that page
<alvesadrian> zyga thanks thats enough
<zyga> ackk: this should be in edge
<ackk> zyga, ok, I'll test with that, see if it solves the issue. thanks
<alvesadrian> ackk also thanks
<zyga> thanks!
<ackk> zyga, that seems to work, thanks!
<alvesadrian> zyga final question
<alvesadrian> SNAP_DATA SNAP_USER_DATA SNAP_COMMON
<alvesadrian> those contaiing dirs writeables
<alvesadrian> can be chown?
<alvesadrian> teh files inside fo those?
<alvesadrian> ackk also if you know this ^^^
<ackk> alvesadrian, yes those are writable. why do you need chown?
<alvesadrian> java developers are asking me
<alvesadrian> why we cannot chown to jetty or tomcat user
<alvesadrian> why it needs to run as root
<ogra> where would that user live
<ackk> alvesadrian, services run as "root" in the container
<ackk> alvesadrian, that's a confined root user though, so it's safe
<alvesadrian> no clue why they complaing about that
<ogra> iirc fchown and chown syscalls are blocked by seccomp by default
<ogra> you can make them a no-op by using snapcraft-preload if you can not change the code
<ogra> if your developers heavily insist to drop to a user (which is pretty much nonsense inside confinement, but some apps can not be changed) you can use https://forum.snapcraft.io/t/system-usernames/13386
<ogra> ... but need to change your app to use this username ...
<alvesadrian> ogra the problem is they want to run jetty services
<alvesadrian> with user jetty
<ogra> well, and they can not run it as root ?
<ogra> it is inside confinement ... switching to that user brings no benefit
<alvesadrian> ogra here is teh case
<alvesadrian> https://pastebin.com/Uwe6vF8r
<alvesadrian> ogra https://pastebin.com/Uwe6vF8r
<ogra> but they *can* switch to an unprivileged user if needed ... as described in the doc i just gave you above
<ogra> so make them use that and configure it in the snapcraft.yaml
<ogra> or convince them to run it as root
<ackk> it should be possible to run jetty as root
<ackk> there are few apps that really can't be convinced to run as root (postgres being one of them)
<ogra> right
<alvesadrian> ackk https://pastebin.com/Uwe6vF8r
<alvesadrian> thats an exxample of whats going on
<ackk> that's a flask app though? I don't see how is it relevant
<alvesadrian> su - jetty
<alvesadrian> I also set JETTY_USER=jetty for command
<ogra> well, su or sudo inside snaps dont work anyway
<alvesadrian> Jython 2.7.2rc1 (v2.7.2rc1:1fcef1abf1d6, Mar 1 2020, 16:27:06)
<alvesadrian> [OpenJDK 64-Bit Server VM (Amazon.com Inc.)] on java1.8.0_222
<alvesadrian> Type "help", "copyright", "credits" or "license" for more information.
<alvesadrian> >>>
<alvesadrian> >>> f=open("/tmp/text.txt",'w')
<alvesadrian> >>> f.write("test")
<alvesadrian> >>> f.close()
<alvesadrian> >>> import os
<alvesadrian> >>> os.getuid()
<alvesadrian> 1000
<alvesadrian> >>> os.system('chown 1000 /tmp/text.txt')
<alvesadrian> chown: changing ownership of '/tmp/text.txt': Operation not permitted
<alvesadrian> 1
<alvesadrian> Even see this:
<alvesadrian> >>> os.stat("/tmp/text.txt").st_uid
<ogra> and chown is blocked by seccomp
<alvesadrian> 1000
<alvesadrian> so we need to fix rthat app code?
<ogra> run jetty as root, run the commands as root ...
<pedronis> or use snap_daemon if possible
<ogra> the snap confinement is designed to be root safe
<ackk> alvesadrian, is that chown a test or actual code you have ?
<ogra> right, if you really cant use root, use snap_daemon ...
<alvesadrian> code
<ogra> the point is, there is no jetty user on systems you install your snap on ... and nothing in snaps that allows to create such a user
<alvesadrian> thats real code
<ackk> alvesadrian, maybe unrelated but, you shouldn't really need to chown the file to the same user that created it?
<alvesadrian> am not the developer
<alvesadrian> just packaging
<ogra> use snapcraft-preload to make chown a no-op then
<ogra> https://github.com/sergiusens/snapcraft-preload
<ackk> alvesadrian, fwiw if the service is running as root in the snap, that chown will succeed (assuming you replace 1000 with os.getuid()): https://paste.ubuntu.com/p/v88DXT45bh/
<ackk> 1000 won't as you can only chown to the same user
<ackk> (and root doesn't have CAP_DAC_OVERRIDE in the snap)
<mup> PR snapd#8320 opened: Updates to login-session-observe and network-manager interfaces <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/8320>
<pedronis> pstolowski: commented, let me know
<mup> PR snapd#8312 closed: many: fix packages having mistakenly their copyright as doc <Simple ð> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8312>
<pedronis> pstolowski: also ping me when is ready for re-review, I saw there bits still not addressed. thanks
<pedronis> pstolowski: I did a pass on #8309
<pedronis> thanks for it
<mup> PR #8309: o/configcore: implement Apply method for early configuration of core <Created by stolowski> <https://github.com/snapcore/snapd/pull/8309>
<pstolowski> pedronis: thanks! i just replied to one of your search v2 comments
<pedronis> pstolowski: answered
<pedronis> pstolowski: I'm sure we can do something but yes touching the global helper is delicate so we can postone
<pstolowski> pedronis: thanks. yes it's all messy and super confusing already. nb, error-list vs error_list in struct storeErrors, but that's probably historical?
<pedronis> pstolowski: yes, that's used in the bit that we should drop when we can
<mborzecki> pedronis: do you think we could stay after the standup and discuss integration of snap-recovery-chooser with console-conf?
<pedronis> mborzecki: yes, if the standup doesn't take too long
<mborzecki> ack
<ijohnson> morning folks
<cmatsuoka> hey ijohnson
<ijohnson> hey cmatsuoka how was your weekend ?
<cmatsuoka> confined, and yours?
<ijohnson> haha yep same, but we did a lot of cleaning so that's nice
<cwayne> cmatsuoka: thats a whole new level of eating your own dogfood man
<cmatsuoka> cwayne: haha indeed
<pedronis> ijohnson: I answerd to you comments in 8314, we cannot write a snap-failure that assumes only new snapds
<ogra> jdstrand, if i added "/dev/usb/lp[0-9]* rwk," to the raw-usb interface to allow a customer to use a receipt printer (writing  to the device directly, no cups or so) ... would you object that ? (raw-usb seems like the correct place, if thats wrong we'll likely need a "raw-usbprinter" interface or so)
<jdstrand> ogra: sure, for the same reason as we allow "# Allow access to all ttyUSB devices too"
<ogra> yeahm that was my rationale to pick that place :) create
<ogra> s/create/great/
 * ogra glares at his fingers
<ijohnson> mvo: #8287 is the PR for 2.44 of my initial snap-failure changes that pedronis's changes are based on top of FYI
<mup> PR #8287: tests, many: don't use StartLimitInterval anymore, unify snapd-failover variants, build snapd snap for UC16 tests (2.44) <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8287>
<mvo> ijohnson: thanks, checking it now
<cachio> mvo, hey
<cachio> I am creating the cloud config in this place currently system-data/var/lib/cloud/seed/nocloud-net/
<cachio> for uc20
<cachio> mvo, this right? ubuntu-seed/data/etc/cloud/cloud.cfg.
<cachio> d
<pedronis> cachio: it depends what kind of data are you creating
<pedronis> is it user-data?
<cachio> user-data and meta-data
<pedronis> yea, your place is correct
<pedronis> and we need more code
<pedronis> (I mean correct about to /data)
<pedronis> mvo: ^
<pedronis> what we discussed last week actually
<cachio> pedronis, i tried to merge #8299 but still out of sync
<mup> PR #8299: devicestate,sysconfig: support "cloud.cfg.d" in uc20 for grade: dangerous <Squash-merge> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8299>
<cachio> I did re-login
<cachio> but didnt work
<cachio> on github and travis as well
<cachio> pedronis, any other idea?
<mvo> pedronis, cachio indeed, the current PR only supports cloud.cfg.d - I can extend the code for user-data and meta-dat
 * mvo added a todo for himsef
<pedronis> mvo: we need to extend for seed/* at least for dangerous, for non-dangerous we need to be a bit more careful
<cachio> mvo, if it is in a following pr should be nice
<ngaio> Hello everyone, where do the MOTU team chat? IRC? The MOTU information on the Ubuntu wiki is many years out of date (seriously!)
<mvo> pedronis: yeah
<mvo> cachio: yeah, put on my todo
<cachio> thanks
<ngaio> I'm asking because I have a request about a specific package in Universe that is packaged in Debian
<ngaio> (not because I'm looking to update the Ubuntu Wiki ;-) )
<mup> PR snapd#8314 closed: cmd/snap-failure,tests: try to make snap-failure more robust <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8314>
<mup> PR snapd#8287 closed: tests, many: don't use StartLimitInterval anymore, unify snapd-failover variants, build snapd snap for UC16 tests (2.44) <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8287>
<zyga> hmm
<zyga> test failure in 2.44.1+ git build
<zyga> ... error string = "Get http://42/v1/session-info: context deadline exceeded"
<zyga> ... regex string = "Get \\\"?http://1000/v1/session-info\\\"?: context deadline exceeded"
<zyga> mvo: ^ perhaps this is what was blocking edge builds?
<zyga> FAIL: client_test.go:101: clientSuite.TestAgentTimeout
<zyga> there's also a c.Check(err, IsNil) that should be c.Assert
<zyga> and a panic after that
<zyga> PANIC: client_test.go:287: clientSuite.TestSnapdClientIntegration
<zyga> I can send a patch that quickly
<mup> PR snapd#8321 opened:  cmd/snap-failure,tests: try to make snap-failure more robust (2.44) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8321>
<mup> PR snapd#8322 opened: client: use Assert when checking for error <Simple ð> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8322>
<zyga> https://github.com/snapcore/snapd/pull/8322
<mup> PR #8322: client: use Assert when checking for error <Simple ð> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8322>
<ackk> zyga, is it possible to make "snap run --strace" work in a container?
<ackk> it doesn't seem it is by default
<zyga> ackk: IIRC no without lxd changes
<ackk> zyga, ok, thanks
<mup> PR snapd#8299 closed: devicestate,sysconfig: support "cloud.cfg.d" in uc20 for grade: dangerous <Squash-merge> <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8299>
<mup> PR snapd#8323 opened: many: improve comments, naming, a possible TODO <Created by pedronis> <https://github.com/snapcore/snapd/pull/8323>
<pedronis> ijohnson: ^ tries to apply your feedback and turns a point of it into a TODO
<ijohnson> thanks pedronis just approved it
<ijohnson> hmm pedronis (hopefully quick) question about refactoring the logic from snap-bootstrap to boot pkg, should snap-bootstrap/cmd_initramfs_mounts.go pass in the bootloader and modeenv to a function in boot, or should the function in boot get that stuff itself ?
<pedronis> ijohnson: this is for run mode right?
<ijohnson> pedronis: yes
<ijohnson> the logic to pick the base snap and kernel snap to mount and also for the base to update the modeenv
<pstolowski> pedronis: can you clarify on #8309 (just replied)?
<mup> PR #8309: o/configcore: implement Apply method for early configuration of core <Created by stolowski> <https://github.com/snapcore/snapd/pull/8309>
<ijohnson> I'll save the bikeshedding about function names for the PR itself, but while coding it just occurred to me  maybe it would be easier/make more sense if the book package picked that stuff up itself instead of getting that state passed to it from snap-boostap's code
<pedronis> ijohnson: yes, I don't think that passing in the bootloader is useful,  it's more like MakeBootable really
<pedronis> ijohnson: but what's the input and the output?
<pedronis> ijohnson: if we look at how install works,  the input would be []snap.Type and the output paths?
<ijohnson> well the input for now was just which snap (base or kernel) and the bootloader and the modeenv, the output is what snap to mount as a string and an error
<ijohnson> oh hmm
<pedronis> I mean, there's more to the input than []snap.Type,  definitely the bootloader is not needed
<ijohnson> right sure ignore that
<ijohnson> then I have this (ignore the name)
<ijohnson> `func InitramfsSnapToMount(snapT snap.Type) (snapFilename string, err error) {`
<pedronis> that seems ok fine, it might or might not need to take the model? maybe not? there' the wrinkle that we need to mutate modeenv
<pedronis> sometimes
<ijohnson> right so the other thing I was doing here just for simplicity is that this function would mutate the modeenv and write that out, so in generateMountsModeRun, we wouldn't have that step "4.1 Write the modeenv out again"
<ijohnson> but I suppose I could return the modeenv and keep that step 4.1
<ijohnson> also where would we get the model from during snap-bootstrap ?
 * ijohnson looks
<pedronis> pstolowski: answered
<pstolowski> ty
<pedronis> ijohnson: do we need the model?
<ijohnson> pedronis: not right now AFAICT ?
<pedronis> ok, so ignore me
<pedronis> pstolowski: let me know if my comment is still confusing
<ijohnson> okay, but do you have thoughts on step 4.1 in snap-bootstrap ?
<ijohnson> pedronis: i.e. should we still write the modeenv at the very end, or could we write it sooner?
<pedronis> ijohnson: I think we could write it sooner afaiu,  the issue then is more that function name doesn't scream I'm mutating stuff
<ijohnson> yeah let's figure out a good name in the PR review :-)
<ijohnson> I should have it open this afternoon, need to break now for lunch though
<pedronis> ijohnson: I might not get to look at it today though, trying to have a short day for a change :)
<ijohnson> pedronis: that's perfectly fine I understand :-)
<pstolowski> pedronis: looks good,ty
<mup> PR snapd#8324 opened: github: cache go build cache and pkg dirs <Created by zyga> <https://github.com/snapcore/snapd/pull/8324>
<pedronis> pstolowski: I made a list of the follow ups if I see things correctly
<pstolowski> pedronis: great, thanks. none of that is sophisticated, mostly a matter of diff size for the review / avoiding loosely related changes in this PR
<pedronis> pstolowski: yea, no proble, small PRs that can go in quickly are good
<pstolowski> eod, o/
 * zyga eds
<pedronis> mvo: this didn't even trigger travis in any way: https://github.com/snapcore/snapd/pull/8321 seems something really confused there
<mup> PR #8321:  cmd/snap-failure,tests: try to make snap-failure more robust (2.44) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8321>
<mvo> if someone could eyeball/approve 8321 that would be nice, maybe the approval is what's missing from triggering a travis run?
<ijohnson|lunch> mvo I approved it
<ijohnson|lunch> still no travis though :-/
<mvo> ijohnson|lunch: meh, silly travis
<ijohnson|lunch> mvo: what I've done before is to close and re-open the PR
<mvo> ijohnson|lunch: thanks, let me try this
<mvo> that helped
<mvo> thanks pedronis
<pedronis> I tried it, but didn't help
<pedronis> afaict
<pedronis> actually it did
<pedronis> it took a little bit
<ijohnson|lunch> I reapproved anyways just to make sure it didn't be weird
<pedronis> so travis and github got desynced again
<pedronis> for me
<pedronis> :/
<cachio> mvo, I am creating cloug condiguration like this https://paste.ubuntu.com/p/Mz3PHrtZJ6/
<cachio> is it ok?
<zyga> Travis has a very bad day
<cachio> mvo, then I copy that file to /ubuntu-seed/data/etc/cloud/cloud.cfg.d/
<cachio> on the image
<sergiusens> zyga: Travis had a very bad weekend!
<mvo> cachio: yeah, that should work
<mvo> cachio: good luck, keep me updated
<cachio> mvo, and which is hte path in uc18 and uc16?
<cachio> the same should work as well?
<mup> PR snapd#8316 closed: github: add prototype workflow running unit tests <Skip spread> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8316>
<mup> PR snapd#8316 opened: github: add prototype workflow running unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8316>
<pedronis> cachio: mvo: in the image you don't want the ubuntu-seed bit (that's the partition mount point)
<cachio> pedronis, currently I mount the partition and then copy to /ubuntu-seed/data/etc/cloud/cloud.cfg.d/
<cachio> in uc20
<cachio> there are 2 partitions and the second one contains /ubuntu-seed
<cachio> pedronis, is that ok?
<ijohnson|lunch> cachio: yes the put the data/etc/... files in the ubuntu-seed partition
<cachio> ijohnson, thanks
<ijohnson> cachio: if you are mounting ubuntu-seed at /ubuntu-seed then that directoriy you have is correct
<cachio> ijohnson, ye
<cachio> s
<cachio> I am running now, reults will be ready in few minutes
<ijohnson> great cachio
<mup> PR snapd#8325 opened: snap-bootstrap: copy auth data from real ubuntu-data in recovery mode <Created by mvo5> <https://github.com/snapcore/snapd/pull/8325>
<mup> Bug #1868620 opened: Snaps based on Wine fail with nvidia driver 440  <Snappy:New> <https://launchpad.net/bugs/1868620>
<cmatsuoka> zyga: do you have plans to work on LP:1868450? should I assign it back to you?
<cmatsuoka> ijohnson: do you know who worked with timers more recently?
<ijohnson> cmatsuoka: I think mborzecki or pstolowski
<cmatsuoka> ijohnson: thanks, I'll check with them
<pedronis> cachio: hi, the issues here seems real, one missing/changed package?, issue with the urls we get from the store, the store is changing how they handle downloads so something might have changed there, please talk to them: https://api.travis-ci.org/v3/job/665954535/log.txt
#snappy 2020-03-24
<mup> PR snapd#8326 opened: [wip] boot: move initramfs-mounts logic to boot pkg <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8326>
<mborzecki> morning
<mborzecki> ayy new kernel, brb
<mborzecki> re
<zyga> Good morning
<zyga> I will make coffee first
<mborzecki> zyga: hey
<jamesh> mborzecki: thanks for your feedback on the xdg-open-to-portal PR.  The test is now successfully running on Arch.
<jamesh> mvo: I think https://github.com/snapcore/snapd/pull/8318 is ready, although it hit two unrelated spread test failures
<mup> PR #8318: tests: ensure sockets target is ready in session agent spread tests <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8318>
<mborzecki> jamesh: thanks for updating the PRs!
<mborzecki> zyga: do you remember whether spread sets nullglob in bash?
<mvo> jamesh: yeah, pushed one fix for this test failure
<mup> PR snapd#8327 opened: tests: update proxy-no-core to match latest CDN changes <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8327>
<mvo> jamesh: looking at the other now
<jamesh> mvo: the other is a "google-unstable" task, so perhaps doesn't matter
<mvo> jamesh: yeah, the unstable ones are not blocking merges
<mborzecki> mvo: hm gperf seems to be gone from our 18.04 images, causing snap-seccomp-syscalls tests to fail
<jamesh> mborzecki: the xdg-open-portal spread test fails when I was running it on debian-9 and opensuse-15.1.  I'm not sure if it is down to the old xdg-desktop-portal versions, or if fakeportalui is using some Python API not available in those release
<zyga> mborzecki: I don't know what nullglob is
<zyga> espanding non-matching glob to nothing?
<zyga> hey mvo
<mborzecki> zyga: yes
 * zyga checks if travis responds 
<zyga> yesterday I could not get travis-ci.io to load at all
<zyga> I see it's fixed now
<mborzecki> zyga: so foo* gives nothing instead of 'foo*' ;)
<zyga> yeah
<zyga> huh
<zyga> master failed
<zyga> please install gperf
<zyga> what the f***
<zyga> configure: error: please install gperf
<zyga> *why* do we need g-frelling-perf now
<mborzecki> zyga: on it now
<zyga> thank you
<zyga> sigh
<zyga> I want to get us off autotools
<mborzecki> zyga: seems it was preinstalled in 18.04 images before, but is no longer there
<zyga> we're not using it, why is it mandatory?
<zyga> thank you maciek
 * zyga tries something new
<mborzecki> zyga: we build libseccomp upstream and they use gperf, since like 3 months now ;)
<zyga> ah
<zyga> oh boy
<zyga> man
 * zyga is unusually grumpy today, sorry
<mup> PR snapd#8328 opened: tests/main/snap-seccomp-syscalls: install gperf <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8328>
<zyga> mborzecki: but it's weird that we depend on it
<zyga> it's usually a build-dep
<zyga> not a runtime dep
<mborzecki> zyga: the test depends on it, not snapd
<zyga> ah
<zyga> sorry, I missed that we build libseccomp upstream
<mborzecki> zyga: look at what the test does
<zyga> btw, why do we do that? to check for upcoming regressions?
<mborzecki> zyga: yes, and we know when the list of syscalls we know of needs to be updated
<mborzecki> zyga: the part of not rebuilding seccomp profiles when not needed
<mborzecki> zyga: haha so found something interesting in #8316 build log
<mup> PR #8316: github: add prototype workflow running unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8316>
<mborzecki> wtf is riscv_flush_icache syscalls?
<zyga> mborzecki: riscv flush instruction cache?
<zyga> mborzecki: what did you find?
<mborzecki> zyga: left a comment there
<zyga> ok
<pstolowski> morning
<zyga> hahaha
<zyga> mborzecki: that's funny
<zyga> I wonder how they do it
<zyga> but they apparently do a better job than we do :D
<mborzecki> zyga: hopefully #8295 will fix that
<mup> PR #8295: osutil: do not leave processes behind after the test run <Created by mvo5> <https://github.com/snapcore/snapd/pull/8295>
<zyga> mhm
<mvo> mborzecki: yeah, looking at the snap-seccomp-syscalls test right now - unless someone else was faster, then I will stop
<mborzecki> mvo: i'm on it already
<zyga> thank you guys :)
<mvo> mborzecki: cool
<mvo> mborzecki: aha, nice
<mborzecki> ouch, our PR title checker just got `urllib.error.HTTPError: HTTP Error 429: too many requests`
<mup> PR snapd#8321 closed:  cmd/snap-failure,tests: try to make snap-failure more robust (2.44) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8321>
<mborzecki> hmm, actually why is oldwait4 removed?
<mvo> mborzecki: yeah, this is strange
<mvo> mborzecki: also, why did this change, what package changed?
<pedronis> mvo: hi, did you see my comment in 8325 ?
<mborzecki> mvo: hmm https://github.com/seccomp/libseccomp/commit/4bd8de391d5920bdbdb639b1d81ddd7bfe4d7549
<mvo> mborzecki: I didn't, let me look
<mvo> mborzecki: oh, interessting
<mborzecki> mvo: i'll check the list of syscalls from HEAD and one before that commit
<mvo> pedronis: yeah, will fix, makes sense
<mvo> pedronis: I want to look at improving unit tests too but otherwise that would be the recover mode
<mvo> mborzecki: aha, we git checkout to test for the syscalls, right? so we are always git-fresh?
<mborzecki> mvo: yes
<zyga> mvo: so, I guess we can kind of do nvidia tests
<zyga> mvo: and pi tests
<zyga> mvo: or aarch64 tests on specific board even if we wanted to
<mvo> zyga: we can or we can't ?
<zyga> we *can* :)
<mborzecki> mvo: so this commit introduces the list of syscalls that is used right now, oldwait4 is no longer there https://github.com/seccomp/libseccomp/commit/f5b3166d6126f4a45b59d6af6780b5e00a0e9867
<mvo> mborzecki: ok
<mborzecki> there is no __NR_oldwait4 in my system either
<zyga> mborzecki: does it spell trouble?
<pedronis> mvo: you might or not conflict with Ian draft PR, otoh that one needs work, it feels too complicated atm
<mvo> pedronis: ok
<mborzecki> zyga: mvo: intersting, we have that syscall in our template
<zyga> har har
<zyga> I wonder why they removed it
<zyga> is it really gone
<zyga> was it ever available
<mborzecki> zyga: mvo: and snap-seccomp ignores the syscalls that are unknown to libseccomp library, maybe the test should be smarter about checking?
<zyga> on 14.04?
<zyga> it only ignores because error checking in seccomp is not great
<zyga> we have not way to differentiate "this is a valid syscall but your arch doesn't have it" from "lol, no, that is bogus"
<mvo> it's a bit mysterious, linux famously never breaks abi with userland so just removing it if it was there sounds strange
<mborzecki> zyga: fwiw, i don't see that syscall in my kernel source tree either
<zyga> mborzecki: try 14.04
<pedronis> mvo: I noticed the problem in #8237 last night, I pinged cachio about it
<mup> PR #8237: interfaces/{docker,kubernetes}-support: updates for lastest k8s - 2.44 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8237>
<pedronis> grumble, 8327
<zyga> ?
<mvo> pedronis: what problem in 8237 is that? the k8s update looks ok to me, what am I missing?
<mvo> oh, sorry
<pedronis> mvo: I mistyped
<mvo> pedronis: let me look at 8327 instead :)
<mvo> pedronis: but sergio did not do a pr yet, did he?
<pedronis> seems not
<pedronis> it was late for him as well I suppose
<mvo> ok, should be fine, the fix is trivial
<mborzecki> zyga: mvo: we should be fine afaict https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a0673fdbcd42105261646cd4f3447455b5854a32
<pedronis> pstolowski: hi, what's the state of the search v2 PR? there are still some comments to address, right?
<mborzecki> mvo: zyga: this was done in 4.17
<mborzecki> i'll update the commit message
<mvo> mborzecki: hm,hm, we support 4.4 back in 16.04, still harmless?
<pedronis> UC 18 is 4.15
<pedronis> that's also older than 4.17
<pedronis> only 20 is newer than 4.17 at 5.4
<mborzecki> mvo: aiui it's only used on 'score' architecture, which got removed in 4.17 as well
<zyga> brb, some stuff at home
<pstolowski> pedronis: i think i addressed all the comments except for potential specialial-casing of some errors from error-list, let me reply to all comments
<mvo> mborzecki: ok, spread should tell us is there is any issue
<pstolowski> pedronis: ah, sorry, missed one about copyNonZero..
<pedronis> pstolowski: I added 2 more comments to #8309
<mup> PR #8309: o/configcore: implement Apply method for early configuration of core <Created by stolowski> <https://github.com/snapcore/snapd/pull/8309>
<pstolowski> ty
<pedronis> pstolowski: but let's try to wrap search v2 first
<pstolowski> pedronis: okay; we will need to wait for store rename still
<pedronis> pstolowski: yes, but let's try to get the rest in order and also get a 2nd review
<pstolowski> sure
<pedronis> mvo: mborzecki: when you have a moment can you review #8253
<mup> PR #8253: snap-bootstrap: expand data partition on install <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8253>
<mborzecki> mvo: just to be sure, i pinged jdstrand and updated the commit message with relevant links
<mborzecki> mvo: as i understand it, unless we supported that architecture (which nobody did?), the syscall should not come up
<mborzecki> pedronis: sure
<zyga> re
<pedronis> mvo: so my comment in your recover auth PR was really about the original one? #8010
<mup> PR #8010: snap-bootstrap: add support for "recover" mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8010>
<mvo> pedronis: yes, but it's fine, we can use only a single PR, the copy auth data is a bit complex so I was splitting but it's not long so either way is fine with me
<mup> PR snapd#8327 closed: tests: update proxy-no-core to match latest CDN changes <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8327>
<pedronis> mvo: no, let's try to merge 8010 first?
<mvo> pedronis: +1
<pedronis> but the Buffer stuff needs fixing
<mup> PR snapd#8313 closed: release: 2.44.1 <Simple ð> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8313>
<pedronis> mvo: what happens right now in recover mode? do we run console-conf or did we turn that off?
<mvo> pedronis: right now recover mode just errors, with 8010 as is we would run console-conf and allow you to create a new login (it's unmanaged) and then you could ssh into it and inspect recovery-ubuntu-data
<mvo> pedronis: so we want the auth commit too
<mvo> pedronis: (that was the question, right?)
<pedronis> mvo: did we turn off console-conf in install?
<mvo> pedronis: let me quickly check, iirc we have a ConditionKernelCommandline for it, but not sure how targeted that is
<mvo> pedronis: it looks like it's active, I checked the released source and I see no kernelcommandline condition, let me double check with git
<mup> PR snapd#8295 closed: osutil: do not leave processes behind after the test run <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8295>
<mvo> no kernel commandline condition in git either
<pedronis> pstolowski: you already have those apiV1 checks at the end of the test, the commented bits just needed removing afaict
<pstolowski> pedronis: ahh, of course, you're right, thanks, missed them
<pedronis> mvo: we need to do something about that
<pedronis> mvo: either with the unit or setting something from bootstrap
<pedronis> mvo: remember that we use it for the chooser as well now? mborzecki
<pedronis> so we need to be careful what we do?
<zyga> mvo: do you want to merge https://github.com/snapcore/snapd/pull/8328 before jamie review (it fixes master)
<mup> PR #8328: tests/main/snap-seccomp-syscalls: install gperf <Simple ð> <â  Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8328>
<mvo> pedronis: right, so I think we need to not run it in install mode, for recover mode we probably don't want to run it either, the only corner case would be if the device has no user
<mvo> zyga: yes
<pedronis> mvo: yes, but I think it has code that checks for managed vs not, the problem is that your copying of auth alone will not have snapd give the right answer
<pedronis> because that requires users in state
<mvo> pedronis: exactly, fixing this would be hard, we would have to have some smarts to just extract the users from state and copy that over to the ephemeral part
<mvo> pedronis: but then a state.json would prevent the first time seeding so :(
<pedronis> mvo: that's not true, seeding is based on seed flag
<pedronis> mvo: anyway first we need to decide what is the right thing to do, 2nd what we can do now
<mvo> pedronis: right
<mvo> pedronis: indeed, I was thinking of https://github.com/snapcore/core20/blob/master/static/usr/lib/core/run-snapd-from-snap#L57 but ian fixed it a while ago so we can actually transfer the user
<mvo> pedronis: in this case it seems like the right thing would be to transfer the "user" part of the state to the ephemeral state in "run" mode, yes? and disable console-conf in install mode as it's meaningless here
<pedronis> mvo: yes, something like that
<pedronis> while keeping the chooser working
<mup> PR snapd#8318 closed: tests: ensure sockets target is ready in session agent spread tests <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8318>
<mvo> pedronis: indeed
<mvo> mborzecki: if we want to disable console-conf in "install" mode (but keep the recovery-chooser) what is the right thing to do? can we just add a "kernel command line not snapd_recover_mode=install" or will that break the chooser now that they are more interwined?
<mup> PR snapd#8322 closed: client: use Assert when checking for error <Simple ð> <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8322>
<mup> PR snapd#8323 closed: many: improve comments, naming, a possible TODO <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8323>
<mborzecki> mvo: the chooser doesn't really run in install mode
<mvo> mborzecki: aha, nice
<mvo> mborzecki: what prevents it from running?
<mborzecki> mvo: hm maybe i wasn't clear, it does not need to run in install mode, probably the same for trigger
<mborzecki> mvo: so we could add ConditionKernelCommandLine=!snapd_recovery_mode=run right?
<mborzecki> uh, way
<mup> PR snapd#8319 closed: github: run unit tests and spread via github actions <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8319>
<mup> PR snapd#8324 closed: github: cache go build cache and pkg dirs <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8324>
<mborzecki> mvo: snapd_recovery_mode=run, and we need to make sure that run is always passed in the mode
<mvo> mborzecki: yeah, I think we don't prevent it from running right now and should. so adding your suggestion sounds right
<mvo> mborzecki: pretty sure we always set snapd_recover_mode
<pedronis> pstolowski: +1 to #8309 but with some final suggestions which I hope make sense
<mup> PR #8309: o/configcore: implement Apply method for early configuration of core <Created by stolowski> <https://github.com/snapcore/snapd/pull/8309>
<pstolowski> pedronis: thanks!
<pedronis> mvo: made a couple of suggestions: https://github.com/snapcore/snapd/pull/8325#discussion_r397044896
<mup> PR #8325: snap-bootstrap: copy auth data from real ubuntu-data in recovery mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8325>
<mvo> pedronis: thank you!
<mup> PR snapd#8316 closed: github: add prototype workflow running unit tests <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8316>
<zyga> please let me know if the new github actions misbehaves
<mborzecki> opened the chooser PR https://github.com/CanonicalLtd/subiquity/pull/655 ;)
<mup> PR CanonicalLtd/subiquity#655: console_conf: implement UC20 recovery chooser <Created by bboozzoo> <https://github.com/CanonicalLtd/subiquity/pull/655>
<mborzecki> i should probably add some tests, because there's none for console-conf atm
<mborzecki> at the same time, there's some snapd work to do still
<mup> PR snapd#8329 opened: allow raw access to USB printers <Created by ogra1> <https://github.com/snapcore/snapd/pull/8329>
<zyga> mvo: ping
<ogra> zyga, hmm, your actions port writes werid emails ... i just got sent a link to someone elses merge it seems
<zyga> what?
<zyga> can you be more specific please
<ogra> zyga, i added a PR ... https://github.com/snapcore/snapd/pull/8329 ... and got a mail https://paste.ubuntu.com/p/G5bFF7TyJk/ ... clicking the link in the mail gets me to: https://github.com/ogra1/snapd/runs/530255923
<mup> PR #8329: allow raw access to USB printers <Created by ogra1> <https://github.com/snapcore/snapd/pull/8329>
<zyga> interesting
<zyga> what was in the mail?
<zyga> ah, one sec
<ogra> the tests for my PR seems to be fine though
<zyga> yeah, it's weird
<zyga> I can see the test passed just fine
<ogra> the pastebin has all the content of the mail
<zyga> wait
<zyga> that's different
<ogra> subject was: 	[ogra1/snapd] Run failed: Quick Go unit tests - master (ff4e1ba)
<zyga> it failed on _your_ master
<ogra> why would it run anything on my master ?
<zyga> because you pulled actions
<zyga> https://github.com/ogra1/snapd/runs/530255923
<ogra> bah
<zyga> ha
<zyga> funny
<zyga> ok, I know how to fix it
<zyga> thank you for reporting
<zyga> I will handle it :)
<zyga> go's very picky about repository name
<zyga> thanks ogra :)
<ogra> np :)
<zyga> ogra: done
<zyga> https://github.com/snapcore/snapd/pull/8330
<mup> PR #8330: github: always checkout to snapcore/snapd <Created by zyga> <https://github.com/snapcore/snapd/pull/8330>
<mup> PR snapd#8330 opened: github: always checkout to snapcore/snapd <Created by zyga> <https://github.com/snapcore/snapd/pull/8330>
<zyga> can you cherry-pick this into your master
<zyga> to see if it fixes
<zyga> just fetch from my remote and cherry pick and push to your fork's master branch please
<cachio> mvo, pedronis sorry, yesterday I missed the comment about the proxy
<cachio> mvo, I just promoted core to candidate
<mvo> cachio: nice, thanks
<mvo> cachio: proxy> no worries, it's fixed now
<cachio> mvo, about cloud config https://paste.ubuntu.com/p/TbTrf4Dcfp/
<mvo> cachio: is that working?
<cachio> I am doing that to update the image
<cachio> but It didnt work yesterday
<cachio> now I am going to boot locally the image
<cachio> mvo, then I could not continue because of 2.44.1
<cachio> mvo, do you see anything that could be improved in that code?
<mup> PR snapd#8331 opened: github: run spread via github actions <Created by zyga> <https://github.com/snapcore/snapd/pull/8331>
<mvo> cachio: it llooks ok
<mup> PR snapd#8332 opened: gadget: CoreDefaults helper for FilesystemOnlyApply (2/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8332>
<cachio> mvo, ok, I'll boot the image here in that case because yesterday didn't work
<mvo> cachio: uh, ok - would be nice to inspect the resulting image, i.e. if the file is in the right place on ubuntu-seed and ubuntu-data
<mvo> cachio: maybe it's something silly during the data copy
<cachio> mvo, sure, I'll check that
<mup> PR snapd#8330 closed: github: always checkout to snapcore/snapd <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8330>
<zyga> ta
<mup> PR snapd#8328 closed: tests/main/snap-seccomp-syscalls: install gperf <Simple ð> <â  Critical> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8328>
<zyga> mvo: ^ fyi, I think master should be not broken anymore
<ijohnson> hello folks
<roadmr> ijohnson!!!!!!!!!!!!!!!!!!!!!!
<roadmr> hello!
<roadmr> hehe :)
<ijohnson> hey roadmr
 * ijohnson thinks about running away with that many exclamation marks
<roadmr> yes it's typically followed by a very complicated ask or something
<roadmr> but no - just saying hi :)
<ijohnson> :-)
<ijohnson> pedronis: do you want to chat after the SU today? I realize my PR is a bit complicated, but I rather like the fact that all the base snap modeenv changes is done in bootstate20 alongside all the other boot state changes we do during normal running
<ijohnson> pedronis: I will try to look at your comments before the SU
<pedronis> ijohnson: I don't the issue is bootstate20 vs not, the issue is that is following patterns that are bit overkill for it inside it, I think there should be a complexity middle ground, but yes, happy to chat
<ijohnson> pedronis: okay
<pedronis> ijohnson: the other issue is that boot doesn't care about snapd so far, and that I think we should keep it that way
<ijohnson> pedronis: but for uc20, now the snapd snap is part of the boot process on first boot run mode and in install mode
<pedronis> snapd itself doesn't require to touch bootloader states or modeenv anyway atm
<jdstrand> mborzecki: I looked at the PR and said it LGTM
<mborzecki> jdstrand: thanks!
<ijohnson> pedronis: the snapd snap here is a bit of an odd egg, but it feels cleaner to me IMHO
<pedronis> ijohnson: it's not cleaner, in my opinion, without moving even more stuff
<pedronis> and the win is unclear at this point
<pedronis> cleanliness is only one factor here
<ijohnson> right one of the points I made in the PR is that I wanted to move more stuff from cmd_initramfs_mounts.go to the boot package
<ijohnson> i.e. install mode mount choosing
<pedronis> ijohnson: formulated in those terms is not a win or not
<pedronis> why is it good or bad?
<pedronis> ijohnson: anyway my recommendation is to leave snapd alone at this point
<ijohnson> alright I will bring my reasoning with to our meeting
 * ijohnson still needs to have breakfast
<pedronis> ijohnson: refactoring is to fix other TODOs properly, is not a goal in itself (especially at this point in time)
<pedronis> ijohnson: anyway if you worry that you'll have to start this from scratch, I don't think so
<ijohnson> well fwiw I can easily ressuect the simpler version of this that I started with which just moves code to the boot package but it feels much more mechanical and at that point it seems what's the point if we just move the same code from one file to another
<pedronis> ijohnson: that we can call it from tests
<pedronis> ijohnson: anyway, I'm happy to discuss, I'm not sure what the mechnical version does
<pedronis> so I can't say it's better or worse
<pedronis> ijohnson: I can see where the current code as proposed could go
<mup> PR snapcraft#2991 opened: yaml_utils: don't sort keys when dumping <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2991>
<mvo> zyga: yay
<zyga> re :)
<cachio> cmatsuoka, hey
<cmatsuoka> hi cachio
<sergiusens> zyga: if we implement https://bugs.launchpad.net/snapcraft/+bug/1868460 then this stops being yaml https://yaml.org/spec/1.2/spec.html#id2765608
<mup> Bug #1868460: environment sections are reordered <Snapcraft:Confirmed for cjp256> <https://launchpad.net/bugs/1868460>
<cjp256> sergiusens/zyga:  i was just writing something like that up for LP :D  at first i thought it may have been a change in behavior either due to something I did, or the recent pyyaml uprev, but I think not
<zyga> sergiusens: I'm okay if that stops being yaml in a way
<zyga> sergiusens: I think we cannot reorder it to be a sequence now
<zyga> cc pedronis ^
<ijohnson> let's just all move everything to toml and call it a day
<sergiusens> zyga: you can accept both inputs or get degville to fix the docs to say this is NOT yaml, but yaml-like
<zyga> sergiusens: I think we can be reasonable, it's yaml but we respect the order
<zyga> sergiusens: if we need to fix this snapd side we can but I would rather have snapcraft maintain the order
<sergiusens> zyga: well, I would have preferred that snapd had implemented a sequence, as I bet kyrofa would have too
<zyga> sergiusens: sure but that's too late, the spec is set
<sergiusens> zyga: you know that YAML spec is also set
<zyga> sergiusens: I know, I'm not asking you to change that spec
<sergiusens> zyga: we will make the change, but fix the docs
<zyga> sergiusens: ack, I think environment is not documented (I could not find it) so I'll see what we can do about that first
<mup> PR snapcraft#2988 closed: tests: add two more workers to the 18.04 systems <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2988>
<mborzecki> mvo: can you upload 2.44.1 release tarballs?
<rbasak> ijohnson: thank you for your answer (on refresh hook exit status https://forum.snapcraft.io/t/supported-snap-hooks/3795/12) - should the behaviour be documented then? It's only alluded to in the official docs.
<mvo> mborzecki: uh, sorry, sure
<mborzecki> pedronis: cmatsuoka: there is a bug with generating timer schedules, but i can't really reproduce the OOM thing
<mborzecki> pedronis: cmatsuoka: the bug is that we don't effectively generate a schedule if if it's a single `mon` thing (but we have a plenty of weird, complicated schedules)
<pstolowski> mborzecki: hey, i was just talking with mvo about https://bugs.launchpad.net/snapd/+bug/1868706, can you help with this?
<mup> Bug #1868706: Snapd postinst script hangs <snapd:Triaged> <https://launchpad.net/bugs/1868706>
 * zyga -> lunch
<pstolowski> any idea if .postinst stdout goes to a log file somewhere?
<ijohnson> rbasak: yes it should be documented somewhere, degville perhaps can help with that
<mborzecki> pstolowski: let me see
<mborzecki> pstolowski: wow
<mborzecki> pstolowski: hmm that's the interactive ask for password prompt right?
<pstolowski> mborzecki: whoot? where?
<pstolowski> 2388?
<mborzecki> pstolowski: systemd-tty-ask
<mborzecki> pstolowski: afaik it's actually calling systemctl start which is added by dh-systemd
<mvo> the systemd-tty-ask might be a red herring
<cachio> mvo, I just see mnt/system-data/etc/cloud/cloud-init.disabled
<mborzecki> mvo: it might, but it will block further operations
<mvo> cachio: aha, interessting. is this a grade dangerous model?
<cachio> mvo, yes
<kyrofa> sergiusens, "I would have preferred that snapd had implemented a sequence, as I bet kyrofa would have too" -> you know it
<cachio> mvo, this is the partions https://paste.ubuntu.com/p/x9n6wmNtQQ/
<mvo> mborzecki: interessting, keep me updated please
<mvo> cachio: odd, can you point me to the full branch that you use? I will try to run it here
<cachio> mvo, https://github.com/sergiocazzolato/snapd/tree/tests-extend-uc20-nested-suite
<ijohnson> pedronis: wdyt of adding a "Rewrite()" to modeenv, turns out we have places we need to artificially create a modeenv then write it out somewhere, so I think we should have two methods, Rewrite() for writing to where we read it, and Write() for writing to anywhere
<cachio> mvo, this is the test https://github.com/sergiocazzolato/snapd/blob/tests-extend-uc20-nested-suite/tests/nested/manual/uc20-smoke/task.yaml
<mvo> cachio: thanks
<ijohnson> pedronis: i.e. https://pastebin.ubuntu.com/p/gdQdfxCt3V/
<ijohnson> actually slightly more sensible version https://pastebin.ubuntu.com/p/FJwFQzgXcd/
<tkamppeter> ijohnson, jdstrand, pedronis: We have our meeting now.
<ijohnson> tkamppeter: I thought the meeting was in 30 minutes?
<ijohnson> tkamppeter: that's what the calendar invite says?
<tkamppeter> I have a calendar invite for 4:30pm.
<jdstrand> tkamppeter: mine also says 30 minutes from now
<ijohnson> I mean I'm free now if we want to meet now I guess
<tkamppeter> So then let us have it in 30 minutes, no problem.
<ijohnson> okay, in 30 minutes, thanks tkamppeter
<mup> PR snapd#8333 opened:  wrappers: fix timer schedules that are days only <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8333>
<pedronis> ijohnson: sounds ok, either that or Write and WriteTo
<ijohnson> ah I like WriteTo and Write better
<ijohnson> thanks
<mborzecki> pedronis: cmatsuoka: please take a look at #8333
<mup> PR #8333:  wrappers: fix timer schedules that are days only <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8333>
<pedronis> mborzecki: looks alright
<tkamppeter> ijohnson, jdstrand, pedronis: If you are all free we could start right away now.
<ijohnson> give me a few minutes to wrap up what I'm doing right now
<tkamppeter> OK.
<pstolowski> zyga: does this https://bugs.launchpad.net/snappy/+bug/1868620 fall into the category of any known nvidia/GL issues?
<mup> Bug #1868620: Snaps based on Wine fail with nvidia driver 440  <Snappy:New> <https://launchpad.net/bugs/1868620>
<zyga> I noticed that bug a moment ago, I would have to check
<tkamppeter> ijohnson, jdstrand, pedronis: I am connected now.
<ijohnson> sorry pulseaudio problems
 * jdstrand shakes fist at pulseaudio
<mvo> cachio: fwiw, I did a manual test, created a new image, copied things onto it and the cloud-init data.cfg got copied to the right place. the user is not created and I'm not sure why but the file is in the right place. I will collect the steps and pastebin them
<cachio> mvo, ahh, thanks for testing that
<mvo> cachio: http://paste.ubuntu.com/p/gMTKqZxPSt/
<mvo> cachio: I look now why the user is not there, maybe the cloud-init logs have hints
<cachio> snapd on esge already has the cloud init code right?
<mvo> cachio: yes, I created the image with --channel=edge
<mvo> cachio: I see in /run/cloud-init/cloud-init-generator.log: "cloud-init is enabled but no datasource foudn, disabling"
<mvo> cachio: looks like either you need to write a more complex data source or I need to implement the uc16 compatbile cloud-init overrides, I think this is what we want anyway so probably a good idea to wait for this
<mvo> cachio: unless tweaking the data.cfg is easy
 * mvo does not know
<cachio> mvo, ahh, ok
<cachio> I'll update the cfg and then once we have that in place I'll revert the config
<cachio> thanks for the info
<mvo> cachio: my pleasure
<zyga> cachio: is ubuntu-20.04-64 using a desktop image?
<zyga> cachio: it's significantly slower than other systems
<cachio> I found some interesting stuff
<cachio> zyga, the most important was related to systemd
<cachio> all the systemd operations took more time on ubuntu 20.04
<zyga> cachio: so it's not a desktop image?
<zyga> cachio: no gdm, no extra packages?
<cachio> it uses the cloud image published by ubuntu
<zyga> vanilla?
<cachio> no deskto
<cachio> p
<zyga> IIRC we had our own images derived form cloud
<cachio> zyga, right
<cachio> we are using one which is a copy from the published by ubuntu-cloud
<zyga> and we have not, by any chance, installed gdm?
<cachio> zyga, gcloud compute images list --project ubuntu-os-cloud-devel | grep ubuntu-2004-lts
<cachio> zyga, I can check manually that
<zyga> cachio: thanks, I remember seeing gdm in some logs
<zyga> on 20.04 classic
<zyga> which made me wonder if there's something odd that would also explain the extra time
<cachio> zyga,
<cachio> google:ubuntu-20.04-64 .../tasks/google/start-instance# apt-cache policy gdm3
<cachio> gdm3:
<cachio>   Installed: 3.34.1-1ubuntu1
<cachio>   Candidate: 3.34.1-1ubuntu1
<cachio>   Version table:
<cachio>  *** 3.34.1-1ubuntu1 500
<cachio>         500 http://us-east1.gce.archive.ubuntu.com/ubuntu focal/main amd64 Packages
<cachio>         100 /var/lib/dpkg/status
<zyga> woot
<zyga> so it's there?
<zyga> can you try to guess why
<zyga> I wonder if the 20.04 images are wrong
<zyga> or we pulled it via dependencies somehow
<cachio> let me check the base image
<zyga> super, thank you
<mvo> mborzecki: any clues re bug 1868706 ?
<mup> Bug #1868706: Snapd postinst script hangs <snapd:Triaged> <https://launchpad.net/bugs/1868706>
<zyga> mvo: maybe seeding bug on old focal images?
<mborzecki> mvo: left some ideas for pstolowski
<cachio> zyga, look at this https://paste.ubuntu.com/p/N7Fc5KsWY2/
<zyga> looking
<mvo> mborzecki: nice
<mborzecki> mvo: but imo it's the systemd-ttyu-ask-password is runnig and waiting for prompt
<zyga> O M G
<zyga> installing evolution-data-server pulls in GDM and the desktop
<zyga> gosh
<mborzecki> mvo: which is weird because systemctl believes it's runnign on tty and not under uid 0
<zyga> can you file a bug on that
<zyga> and we can fight it later
<zyga> now we can at least remember
<zyga> thank you for checking!
<cachio> zyga, is it a bug?
<zyga> I think we don't want to run the desktop session in our images
<zyga> we should adjust our tests
<zyga> and the script that regenerates images
<zyga> so that we don't have gdm3 installed
<zyga> look at what this pulled
<zyga> mvo: ^ fyi
<zyga> why stuff is slower
<cachio> I compare systemd  on 18.04 nad 20.04
<cachio> and takes much more time on focal than in bionic
<cachio> zyga, let me cehck if I can find the source data
<cachio> I addded that to the standup notes but I think i was purged
<zyga> ok
<cachio> mvo, in 1~2 hour snapd will be ready to go to candidate
<cachio> mvo, internet is very slow today
<cachio> zyga, lp:1868857
<zyga> thank you :)
<cachio> zyga, yaw
<mvo> cachio: ok
<mup> PR snapd#8334 opened: many: add core.resiliance.vitality-hint config setting <Created by mvo5> <https://github.com/snapcore/snapd/pull/8334>
 * zyga EODs
<zyga> o/
<cachio> pedronis, I am debugging uc20 with encription which is still rebooting constantly
<cachio> pedronis, any idea why it could restart almost always after showing in the console output the line
<cachio> [   21.191888] systemd[1]: Starting Create Static Device Nodes in /dev...
<pedronis> no, not sure
<pedronis> cmatsuoka maybe knows more or can help
<cachio> pedronis, ok, thanks
<cmatsuoka> cachio: is it rebooting in a loop, or just once after it reaches run mode?
<cmatsuoka> cachio: could you make an image available for me to test locally?
<mup> PR snapd#8335 opened: many: introduce naming.WellKnownSnapID <Created by pedronis> <https://github.com/snapcore/snapd/pull/8335>
<cachio> cmatsuoka, it is not reaching run mode
<cachio> keeps rebooting in install mode
<cmatsuoka> cachio: oh, that's something we didn't see before, right?
<cachio> cmatsuoka, I reproduce it with this https://paste.ubuntu.com/p/HJQt9Rxh7g/
<cachio> in gce it fails 100% of the times
<cachio> cmatsuoka, I'll try the same now but using ubuntu image snap instead
<cmatsuoka> cachio: just for me to understand where we are, what was changed since the last image that worked?
<cachio> cmatsuoka, I think the problem is ubuntu-image
<cachio> works different using the snap and the deb
<cachio> cmatsuoka, confirmed
<ijohnson> cachio: yes the deb is definitely behind the snap
<cachio> works bad when the image is created using ubuntu-image from deb
<cachio> ijohnson, agree, but   I though both should work
<ijohnson> yeah I think eventually they both will work, but it takes time for the deb to get all the features that the snap gets
<cmatsuoka> mm, something strange in #8333, travis test passed but github thinks it's still in progress
<mup> PR #8333:  wrappers: fix timer schedules that are days only <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8333>
<ijohnson> cmatsuoka: yeah that has been happening recently
<ijohnson> cmatsuoka: what fixed it last time is to close and re-open
<cmatsuoka> ouch
<mup> PR snapd#8336 opened: boot,many: add modeenv.WriteTo, make Write take no args <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8336>
<cmatsuoka> ijohnson: well it seems that closing/re-opening didn't work this time :\
<ijohnson> oh sorry what I meant is that closing /re-opening would make the tests re-run and then after running they would update travis properly
<cmatsuoka> ijohnson: and it spawned another set of github quick tests
<ijohnson> err travis would update github properly after re-running
<cachio> cmatsuoka, using the ubuntu image snap I can reproduce the error https://paste.ubuntu.com/p/CyqDHtrvPF/
<cmatsuoka> ijohnson: ah ok, I'll wait to see if it works
<ijohnson> cachio: did you try edge channel of ubuntu-image snap ?
<cachio> ijohnson, no
<cachio> ijohnson, I'll try
<cachio> reset
<cachio> ijohnson, same error
<ijohnson> hmm
<cachio> ijohnson,
<cachio> trying with an image with is not updated
<cachio> a pure one
<cachio> cmatsuoka, that could affets?
<cachio> affect
<cachio> if I add a file to the image and the vm is using secure boot?
<cmatsuoka> hmm, it shouldn't unless your file is something used in the boot process
<cachio> cloud init config
<cmatsuoka> cachio: and we're not measuring anything yet, so sb should only check shim and friends
<cachio> cmatsuoka, I see
<cmatsuoka> cachio: at which point it reboots? does it boot the target system and seeds?
<cachio> BdsDxe: loading Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x3,0x0)
<cachio> BdsDxe: starting Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x3,0x0)
<cachio> error: file `/EFI/ubuntu/grubenv' not found.
<cachio> error: no such device: ubuntu-boot.
<cachio> error: no such device: ubuntu-boot is new
<cmatsuoka> cachio: I think the missing grubenv is only a warning and it's not fatal
<cmatsuoka> no ubuntu-boot is interesting, because it's created during install
<cmatsuoka> cachio: and you said it fails in install mode?
<cachio> yes
<cachio> once I went to run mode
<cachio> but it is really randome
<cachio> sometimes goes to run mode sometimes still rebooting in install mode
<cmatsuoka> ah, so you actually reboot in run mode and then it fails?
<cmatsuoka> ah
<cachio> now it is not going to run mode
<cmatsuoka> and are you able to reproduce this behavior locally?
<cachio> cmatsuoka, didn't try
<cmatsuoka> because maybe it's not completing the install?
<cachio> cmatsuoka, because my internet sucks today
<cachio> cmatsuoka, let my try
<mup> PR snapd#8337 opened: cmd/snap-bootstrap/initramfs-mounts/tests: use dirs.RunMnt over s.runMnt <Simple ð> <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8337>
<pedronis> ijohnson: I tried to answer your question,  I think we should try to get rid of the modeEnv hanging on DeviceManager at some point soon
<pedronis> we don't keep a bootloader around like that
<mup> PR snapcraft#2992 opened: [WIP] repo: ubuntu implementation refactoring with initial package-management <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2992>
#snappy 2020-03-25
<zyga> o/
<zyga> day of apple updates
<zyga> everything has an update today
<mborzecki> morning
<mborzecki> mvo: mroning
<mborzecki> mvo: could you take a look at https://github.com/snapcore/snapd/pull/8289 ?
<mup> PR #8289: xdgopenproxy: forward requests to the desktop portal <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8289>
<mvo> mborzecki: good morning
<mvo> mborzecki: sure
<zyga> good morning guys
<zyga> I need to help with breakfast
<zyga> thank you for reviewing the actions PR
<zyga> I'll be around soon
<mvo> zyga: good morning
<mvo> mborzecki: what is the best snap to test the xdg branch with? just want to give it a quick test run for realz on my focal system
<mborzecki> mvo: hm i think some browser, download a file and then choose to open it or open the download directory, firefox or chromium should work
<mborzecki> mvo: or just a snap with desktop plug, run xdg-open <somefile>
<mborzecki> or <some-dir>
<mvo> mborzecki: ok
<pstolowski> morning
<mvo> hey pstolowski
<mborzecki> pstolowski: pedronis: hey
<mborzecki> hm soemthing broken with travis <-> gh
<zyga> re
<mborzecki> the travis job in #8333 was green, but the status in gh page was still in-progress, i've restarted one of the jobs to see if the status will get updated, but we should monitor whether this is a wider problem :/
<mup> PR #8333:  wrappers: fix timer schedules that are days only <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8333>
<zyga> mvo: can you please land https://github.com/snapcore/snapd/pull/8331
<mup> PR #8331: github: run spread via github actions <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8331>
<zyga> there's a 2nd run of travis pending there
<zyga> and it's just a waste of time to wait
<mvo> zyga: if we land it as is, don't we generate twice the GCE cost?
<zyga> mvo: hmm hmm
<zyga> indeed
<zyga> what do you suppose we should do
<mvo> zyga: if we switch to GH action we should disable travis integration tests
<zyga> mvo: how do we do that?
<zyga> just edit the yaml?
<mborzecki> zyga: yeah, i think so
<zyga> ok, let me
<zyga> mvo: I can move the macos build over as well
<mvo> zyga: I think that makes sense, can GH actions do that?
<zyga> yes
<mvo> zyga: if we don't disable this we still have to wait for travis
<zyga> mvo: libzt has tests for windows, macos and linux this way
<mvo> zyga: we also need to make sure we don't regress
<zyga> mvo: little by litte, let me move travis spread over first
<zyga> yeh
<zyga> I won't do it in one big change
<mvo> zyga: in the sense that the static tests need to run shellcheck and all that
<mvo> zyga: sure
<zyga> yeah
<mvo> zyga: just stating the obvious I guess :)
<zyga> being careful is good :)
<zyga> but I'm happy that this will save the team a *lot* of time
<pedronis> mborzecki: I'm going to pick #8336, if I understand correctly you reviewed the one after, and are mostly happy with it?
<mup> PR #8336: boot,many: add modeenv.WriteTo, make Write take no args <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8336>
<zyga> mvo: pushed https://github.com/snapcore/snapd/pull/8331
<mup> PR #8331: github: run spread via github actions <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8331>
<zyga> just watch how they run
<ijohnson> pedronis: sorry I missed your ping last night I am working now and will address your comments in that PR if you are not already done
<zyga> ijohnson: good morning? !
<ijohnson> hey zyga
<zyga> how are you up at this time?
<pedronis> ijohnson: well, I didn't expect you to be up at this time
<ijohnson> eh it's not a big deal, didn't get much done last night so making up the time now
<pedronis> ijohnson: I'm kind of half way, if you can work continue downstream it's fine, I also want to remove DeviceManager.modeEnv in an immediate follow up
<pedronis> s/work continue/continue work/
<zyga> could someone please tell me how google-tpm backends used?
<zyga> do we only run them manually?
<mborzecki> pedronis: yeah, i think it looks ok, devicemgr seems to be the only place where we may need add a consistency check
<pedronis> mborzecki: I'm just going reread it, as I said I want to remove it
<pedronis> in the next one
<mborzecki> ok
<pedronis> mborzecki: ijohnson: pushed, please take a look
<pstolowski> #8335 needs a second review if anyone has a moment, and it will help with one of my PRs
<mup> PR #8335: many: introduce naming.WellKnownSnapID <Created by pedronis> <https://github.com/snapcore/snapd/pull/8335>
<zyga> I'm seeing failures on core16 reboot test
<zyga> kill timeout reached
<zyga> is anyone else seeing this?
<pstolowski> mborzecki: #8333 can land?
<mup> PR #8333:  wrappers: fix timer schedules that are days only <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8333>
<mborzecki> pstolowski: it's finally green?
<pstolowski> yes
<mborzecki> squash merged it
<mvo> mborzecki: \o/ will cherry-pick (in a meeting right now)
<mup> PR snapd#8333 closed:  wrappers: fix timer schedules that are days only <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8333>
<mborzecki> mvo: ^^
<mvo> mborzecki: done
<mborzecki> mvo: thank you!
<mvo> mborzecki: thank *you* :)
 * mborzecki is just fixing the bugs he introduced ;)
<pedronis> yes #8335 needs a 2nd review
<mup> PR #8335: many: introduce naming.WellKnownSnapID <Created by pedronis> <https://github.com/snapcore/snapd/pull/8335>
<pedronis> mborzecki: ijohnson: thanks for looking 8336, will work on a follow up to remove DeviceManager.modeEnv
<Laney> hi, I've got a snap that is complaining about $XDG_RUNTIME_DIR not existing
<Laney> that is true, but I'm wondering what I'm supposed to do about it; shouldn't snapd be creating this?
<zyga> Laney: do you have some more details, is is a strict orclassic snap?
<Laney> hey zyga
<zyga> Laney: how are you running it (ssh/desktop/etc)
<zyga> hey :)
<Laney> It's a strict one that I've been working with ximion on creating over the last few days (we've been running with dev mode up until now)
<Laney> ok, so I created an LXD container running bionic, used `lxc shell` to get into that, installed the snap and then tried to run its binary
<Laney> as the 'ubuntu' user
<zyga> ok
<zyga> how did you do that?
<Laney> run the binary?
<zyga> specifically the last past
<zyga> *part
<Laney> I just ran the thing that is in $PATH
<zyga> as the ubuntu user
<Laney> appstream-generator <some arguments>
<zyga> lxc shell drops you as a root into the container
<zyga> what did you do next?
<Laney> sudo -u ubuntu -i
<zyga> ok
<Laney> ah ok, are you saying that I didn't get a full PAM sessino and the snap requires that?
<zyga> did that define $XDG_RUNTIME_DIR?
<zyga> I suspect that's the case
<zyga> it's a mess/zoo, depending on how one looks
<Laney> well no, but snapd sets it anyway ;-)
<zyga> yes but we assume it was there to begin with since we use a subdirectory
<zyga> Laney: can you try with runuser -l ubuntu please
<zyga> or runuser -l - ubuntu
<zyga> it's gimmicky
<jamesh> Laney: it's probably because snap-confine modifies XDG_RUNTIME_DIR (setting it to $XDG_RUNTIME_DIR/snap.$SNAP_NAME), but doesn't create that directory
<jamesh> that would be my guess
<zyga> jamesh: yeah, I'm sure it's that
<Laney> correct
<zyga> I guess we could be smarter
<Laney> so I've been given an invalid value there
<jamesh> there is a workaround in snapcraft-desktop-helpers to try and create it
<zyga> by not setting it
<zyga> if it's unset
<zyga> it's not like we're pam
<zyga> we don't want to be
<zyga> we're in self-isolation mode
<jamesh> snap-confine used to create it, but the setup_user_xdg_runtime_dir call is commented out for some reason
<zyga> jamesh: it's been dead for years
<jamesh> yep
<zyga> jamesh: I think we cannot really create it because it's a part of a bigger setup process
<zyga> I would prefer to understand why we're not getting one
<jamesh> and been tripping people up for years
<mup> PR snapd#8336 closed: boot,many: add modeenv.WriteTo, make Write take no args <Simple ð> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8336>
<Laney> got a call, hang on, I'll be back with you in a little minute
<pstolowski> i need to do some shopping while it's quiet in the shops. will be back in ~1h
 * pstolowski goes to grocery
<Laney> zyga: Right, ok, so if I have a PAM session then the regular $XDG_RUNTIME_DIR is created but the snap-specific one isn't - is it up to me to make that atm?
<zyga> Laney: hmmm
<zyga> Laney: no, that's a known bug :)"
<zyga> but usually apps kind of handle that (sometimes0
<zyga> that bug we should fix
<zyga> it was in the dark days of how do we fix this
<zyga> and endless discussions on how to proceed
<zyga> mvo: offtopic, unstable workers actually pass
<Laney> heh
<Laney> ok
<mvo> zyga: haha
<mvo> zyga: nice
<zyga> can you merge 8331
<zyga> I think waiting for travis there is not useful
<zyga> especially that reboot test seems to be failing
<zyga> Laney: not to leave you hanging, I think this is our bug
<mup> PR snapd#8331 closed: github: run spread via github actions <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8331>
<Laney> zyga: ok, thanks, that part is at least not too hard to deal with though
<mup> PR snapd#8338 opened: boot/bootstate20: rm bootState20Base.loadModeenv() <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8338>
<mup> PR snapd#8339 opened: dirs,many: add EarlyBootUbuntu{Data,Boot,Seed} <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8339>
<mup> PR snapd#8340 opened: boot, snap-bootstrap: move initramfs-mounts logic to boot pkg <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8340>
<ijohnson> pedronis: ok, I finished the middle ground implementation, see ^ it is stacked on 8339, so I'd recommend looking at that one first
 * ijohnson needs to go eat something, biab
<mup> PR snapd#8326 closed: [wip] boot: move initramfs-mounts logic to boot pkg <UC20> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8326>
<mup> PR snapd#8019 closed: [RFC] interfaces/apparmor: don't emit deny rules in devmode confinement <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8019>
<zyga> brb
<mup> PR snapd#8341 opened: github: don't fail-fast <Simple ð> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8341>
<pstolowski> re
<mup> Issue core20#27 closed: iptables is missing <Created by alfonsosanchezbeato> <Closed by xnox> <https://github.com/snapcore/core20/issue/27>
<mup> PR core20#28 closed: Add iptables package <Created by alfonsosanchezbeato> <Closed by xnox> <https://github.com/snapcore/core20/pull/28>
<mup> PR snapd#8342 opened: client, daemon, overlord/devicestate: request system action API and stubs <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8342>
<mborzecki> pedronis: ^^
<zyga> uh
<zyga> getting a qemu image on focal run into this bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951766
<mup> PR snapd#8343 opened: config, features: move and rename config.GetFeatureFlag helper to features.Flag <Created by stolowski> <https://github.com/snapcore/snapd/pull/8343>
<pedronis> ijohnson: mborzecki: https://github.com/snapcore/snapd/pull/8344
<mup> PR #8344: overlord/devicestate,boot: do not hold to the originally read modeenv <Created by pedronis> <https://github.com/snapcore/snapd/pull/8344>
<mup> PR snapd#8344 opened: overlord/devicestate,boot: do not hold to the originally read modeenv <Created by pedronis> <https://github.com/snapcore/snapd/pull/8344>
<pedronis> #8309 needs a 2nd review
<mup> PR #8309: o/configcore: FilesystemOnlyApply method for early configuration of core (1/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8309>
<zyga> brb
<mup> PR snapd#8341 closed: github: don't fail-fast <Simple ð> <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8341>
<zyga> ta
<pedronis> pstolowski: I have quite a few meetings today after the standup, can we talk about the code reorg in conficore before the standup?
<mup> PR snapcraft#2972 closed: catkin plugins: remove bash workaround for catkin cmake args <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2972>
<pedronis> mborzecki: some initial quick comments on #8342
<mup> PR #8342: client, daemon, overlord/devicestate: request system action API and stubs <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8342>
<mborzecki> pedronis: thanks, let me see
<mborzecki> pedronis: hm sytem label isn't part of SystemAction but we could use /v2/systems/{label}, wdyt?
<pedronis> mborzecki: ah, sorry
<pedronis> mborzecki: yes, that would be fine. you can do snap install foo  with /snaps/foo action=install
<mborzecki> cool
<pedronis> mborzecki: so DoSystemAction(sysLabel, sysAction) ?
<mborzecki> pedronis: yes, and {"action":"do", "mode": "<action>"} POST'ed to /v2/systems/{label}
<mborzecki> pedronis: we can probably skip the "title" bit which is part of SystemAction in the request
<pedronis> mborzecki: I think is much easier to give back what we received
<pedronis> we just can make some bits optional
<pedronis> but I doube we just simply  pass mode along forever
<pedronis> *doubt
<mborzecki> ok
<pstolowski> pedronis: yes, i'm having a quick lunch atm, will be available in ~20 minutes
<pedronis> pstolowski: ok, ping me
 * zyga is happy to see green spread on unstable systems so often
<pstolowski> pedronis: i'm ready
<pedronis> pstolowski: going to the standup
<zyga> I think I know why session-tool _sometimes_ fails its spread test
<mup> PR snapd#8345 opened: boot/overlord: rename operating mode to system mode  <Created by pedronis> <https://github.com/snapcore/snapd/pull/8345>
<pedronis> zyga: got some apt failure there ^ with gh actions
<pedronis> do I need to merge master?
<zyga> ijohnson saw this once as well
<zyga> let me look
<zyga> hmm
<zyga> no, no need
<zyga> I have an idea how to avoid this entirely
<zyga> oh, standup
<zyga> pedronis: I'll send a patch after the call
<mup> PR snapd#8346 opened: github: try caching apt archive <Created by zyga> <https://github.com/snapcore/snapd/pull/8346>
<zyga> pedronis: fixed
<zyga> I added apt-get update
<zyga> and added caching so we should only fetch it once for now
<zyga> until debian/control changes
<mvo> pstolowski: please try https://paste.ubuntu.com/p/73PbWvsTfy/
<mvo> pstolowski: looks like a very silly bug if it's that
<mup> PR snapcraft#2993 opened: repo: remove dead code from deb implementation <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2993>
<mborzecki> so azure.archive.ubuntu.com is still out of sync now?
<pedronis> pstolowski: I forgot, this is the PR to pick up: https://github.com/snapcore/snapd/pull/8160 once the configcore stuff is a bit more settled (target is 2.45)
<mup> PR #8160: overlord/configstate: add backlight option <Created by EthanHsieh> <https://github.com/snapcore/snapd/pull/8160>
<pstolowski> pedronis: ack
<pstolowski> mvo: yes, that fixes it!
<ijohnson> ugh well I guess I have to live with 100% scaling on my high dpi monitors for a little while :-/
<cachio> mvo, which is the lp for the upgrade error?
<pstolowski> mvo: are you going to propose that fix?
<ijohnson> cachio: it's https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1865063 and/or  https://bugs.launchpad.net/snapd/+bug/1868706
<mup> Bug #1865063: snapd package hangs on deb postinst <focal> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1865063>
<mup> Bug #1868706: Snapd postinst script hangs <snapd:Triaged> <dpkg (Ubuntu):New> <systemd (Ubuntu):New> <https://launchpad.net/bugs/1868706>
<cachio> ijohnson, thanks
<pstolowski> mvo: nb, it's this bug https://bugs.launchpad.net/snapd/+bug/1864197
<mup> Bug #1864197: errtracker unit tests interact with real whoopsie.service <snapd:Confirmed> <https://launchpad.net/bugs/1864197>
<mborzecki> ijohnson: i use the 1.25 scaling factor in gnome tweaks in my 4k setup
<mvo> pstolowski: thanks, will do a PR shortly
<mborzecki> ijohnson: otherwise it's too small, and can't really use fractional scaling as that's wayland only and then sharing windows doesn't work :/ yay for linux desktop
 * zyga breaks for lunch
<mup> PR snapcraft#2994 opened: repo: move filtered package list from manifest.txt into a python list <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2994>
<ijohnson> mborzecki: I use 150% normally with the experimental x11 fractional scaling which worked great for me up until an update this morning
<mborzecki> ijohnson: heh, abandon all hope ;)
<ijohnson> someone is helping me debug the issue in #ubuntu-desktop though, so probably can at least figure out what to revert for now :-)
<mborzecki> ijohnson: hm you're using wyaland right?
<ijohnson> mborzecki: no x11
<mborzecki> ijohnson: hmmmm assumed that when you wrote x11 you actually meant wayland :) but that's interesting, do you know if it's part of upstream mutter on x11 or just patched in ubuntu?
<mborzecki> i remember upstream was wayland only
<ijohnson> I don't remember, but I've been using the experimental scaling since like 17.10 I think ?
<mup> PR snapd#8347 opened: errtracker: add missing mocks <Simple ð> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8347>
<ijohnson> pedronis: ok so I have the dirs refactored, one question though, should the callback take the new rootdir as an arg, I assume yes, but also I have a test to make sure it works to just reference a derived var (i.e. dirs.RunMnt) in the callback and that works too, since I think that will be the most common case
<pedronis> ijohnson: yes, it should take the rootdir, that seems the natural thing
<ijohnson> pedronis: ok sure
<ijohnson> will push up changes shortly then
<pedronis> ijohnson: but do we use RunMnt for anything that is not boot related?
<pedronis> because otherwise it should move too
<ijohnson> oh did you want me to remove RunMnt too
<ijohnson> sorry I missed that, I just renamed it to RunMntDir
<ijohnson> let me look and see where all we use it
<pedronis> ijohnson: sorry, but we it's only use cases, yes I would move it until we have a reason to do otherwise
<pedronis> *if boot is the only use case
<ijohnson> so RunMnt is used in devicestate for cloud-init config dirs during install mode, as well as snap-bootstrap and boot
<ijohnson> but in devicestate we could refactor to use boot.EarlyUbuntuSeed instead
<ijohnson> so yeah I think we could safely move RunMnt to boot as well
<pedronis> ijohnson: it's used to make one of those dirs
<pedronis> I think
<pedronis> yes
<ijohnson> right devicestate does `cloudCfg := filepath.Join(dirs.RunMnt, "ubuntu-seed/data/etc/cloud/cloud.cfg.d")` but it could just as easily do:
<ijohnson> `cloudCfg := filepath.Join(boot.EarlyUbuntuSeed, "data/etc/cloud/cloud.cfg.d")`
<pedronis> yes
<ijohnson> ack ok I will work a bit more to untangle these then
<pedronis> ijohnson: did you fix sysconfig , just checking ?
<ijohnson> pedronis: yes like this https://pastebin.ubuntu.com/p/V6cqksVFm5/
<ijohnson> well, am fixing need to fix some unit tests too
<pedronis> ijohnson: ok
<pedronis> anyway I'll be around hacking a bit and doing review for a while today
<pedronis> but off tomorrow
<ijohnson> okay sure I am trying to wrap up the dirs thing ASAP for you to look at
<mborzecki> mvo: conflicts in https://github.com/snapcore/snapd/pull/8010
<mup> PR #8010: snap-bootstrap: add support for "recover" mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8010>
<ijohnson> pedronis: should we have a helper var in boot for `filepath.Join(boot.EarlyUbuntuData,"system-data")` ?
<ijohnson> I'm having to write that a lot in fixing things to not use dirs.RunMnt
<pedronis> ijohnson: yes, if we find a good name for it, maybe mvo as a suggestions, that's basically writable inside data ?
<ijohnson> to pedronis what about `EarlyWritableDir` ?
<pedronis> sounds okish
<ijohnson> alright I'll go with that for the PR, if anybody thinks of something different it's easy to rename later
 * mvo is not good with names
<pedronis> zyga: mvo: can we reach some conclusion here: https://github.com/snapcore/snapd/pull/8346  , I'm getting an email about each of my PRs saying it failed
<mup> PR #8346: github: cache Debian dependencies for unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8346>
<mvo> pedronis, zyga we should do one that just adds "apt update"
<mvo> zyga, pedronis this will make the failure go away
<zyga> mvo: let me do that quickly
<mvo> ta
<clmsy> hi everyone
<clmsy> i am in need of a bit help
<clmsy> i am building an image that contains some snaps (with the ubuntu-image tool)
<clmsy> this image is going to be an image to flash other images to devices
<clmsy> thus i want to include godd with it
<clmsy> and i can do this by
<clmsy> --snap godd=beta
<zyga> https://github.com/snapcore/snapd/pull/8348/files
<mup> PR #8348: github: apt-get update before installing build-deps <Skip spread> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8348>
<clmsy> giving this arg to ubuntuimage tool
<mup> PR snapd#8348 opened: github: apt-get update before installing build-deps <Skip spread> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8348>
<clmsy> but this doesnt work for me because it somehow ends up in strict confinement
<zyga> mvo: I love how those tests just start *instantly*
<zyga> I feel so discouraged by travis sometimes
<clmsy> the tool says i can describe risk with the decleration ( ubuntu-image snap --help)
<clmsy> it says i need to do this ===>   <snap>=<channel|risk>
<clmsy>  
<clmsy> so i tried a lot of things
<clmsy> --snap godd=beta/devmode
<zyga> mvo: it passed the github action, please merge it
<clmsy> --snap godd=beta|devmode
<clmsy> non of it works
<zyga> clmsy: risk level is not devmode
<zyga> clmsy: you are asking to install a snap in devmode
<mvo> clmsy: it sounds like godd should get an update, i.e. to non-devmode and using the home and block-devices interfaces or something like this
<clmsy> yeah so the image is in /writable/system-data/snap/blahblah
<clmsy> godd cannot see this path
<clmsy> :(
<clmsy> i was trying to give it global access
<clmsy> so when i do sudo godd if=/writable/blahblah it can access it
<zyga> hmm
<zyga> so you put some extra files in /writable?
<clmsy> yes basically i am baking an image that has an image already included in it
<clmsy> this image will be used to flash the inside image to devices permanently
<clmsy> there is an .img file there under writable
<clmsy> i need to make godd access it
<clmsy> but audit logs show that its kinda restricted
<clmsy> i thought i can just do --snap godd=beta/devmode
<zyga> I understand
<zyga> nope, IIRC there's no switch for that
<mvo> clmsy: would using good old "dd" as a workaround work for you?
<clmsy> ill try that i guess
<mup> PR snapd#8348 closed: github: apt-get update before installing build-deps <Skip spread> <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8348>
<zyga> pedronis: it should be better now
<mup> PR snapd#8349 opened: tests: cleanup security-private-tmp properly <Simple ð> <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8349>
<ijohnson> pedronis: #8339 is updated now, it grew quite a bit though
<mup> PR #8339: dirs: rm RunMnt; boot: add vars for early boot env layout <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8339>
<ijohnson> should be pretty simple to review though
<pedronis> thx
<ijohnson> hey folks, my travis <-> github link isn't working, so I can't restart jobs, can someone restart https://travis-ci.org/github/snapcore/snapd/builds/666710776?utm_source=github_status&utm_medium=notification for me? debian-sid just failed because a network error
<mup> PR snapd#8346 closed: github: cache Debian dependencies for unit tests <Skip spread> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8346>
<mup> PR snapd#8350 opened: github: cache Debian dependencies for unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8350>
<mvo> pedronis: is 8010 something you want to review too or are the existing +2 it has enough? it has a conflcit right now so I need to do some work on it anyway first :)
<ijohnson> mvo: note that 8010 will conflict with 8339, just fyi. I'm happy to fix my branch if that one lands first
<pedronis> mvo: sorry, I need to talk what is 8010
<pedronis> s/talk/look/
<pedronis> mvo: it needs my +1, you need to answer my question in the check-list actually :)
<mvo> pedronis: uh, I missed this question, trying to find it now
<pedronis> mvo: maybe my reasoning in the check-list is off, but we need to agree what are the constraints on recover
<mvo> pedronis: looking now, sorry
<mvo> ijohnson: thanks, yeah, it sounds like someone needs to do some more conflict resolving :)
<pedronis> ijohnson: at this point 8010 needs probably to wait next early next week
<ijohnson> pedronis: ack, mvo if you're okay with it I can re-de-conflict 8010 when my PR lands to make it use the new shiny things, it should be easy
<mvo> pedronis: replied
<mvo> ijohnson: sure, works for me
<pedronis> mvo: I suppose that the sealing will put a lock on things so maybe we are safe anyway
<pedronis> we will not enable it until we add the right command line to the policies
<mvo> pedronis: aha, good idea
<pedronis> but we need to be careful
<mvo> pedronis: really nice idea :)
<mvo> +1 for careful
<pedronis> ijohnson: I did a pass on #8339,  my biggest (naming) wondering there is this: https://github.com/snapcore/snapd/pull/8339#discussion_r398043578
<mup> PR #8339: dirs: rm RunMnt; boot: add vars for early boot env layout; sysconfig: take targetdir arg <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8339>
<ijohnson> hmm yes I did forget to add a Dir suffix on all of those
<ijohnson> I'm not sure how else to rename the vars to make it clear they are meant to be used in early boot, I guess we could say something like InitramfsRunMnt maybe ?
<ijohnson> err InitramfsRunMntDir
<ijohnson> pedronis: ^
<mup> PR snapd#8351 opened: config: apply vitality-hint immediately when the config changes <Created by mvo5> <https://github.com/snapcore/snapd/pull/8351>
<pedronis> yes, it's boring and long, but maybe it's what we need
<mvo> :like: fwiw - even though it's long
<ijohnson> ok I will rename to InitramfsRunMntDir
<pedronis> s/Early/Initramfs/ basically
<pedronis> to be clear
<pedronis> not just the first one
<ijohnson> yes
<pedronis> the rest of comments should be more directly applicable
<ijohnson> pedronis: but I should add a Dir suffix to all of them, correct ?
<pedronis> yes
<ijohnson> so we have InitramfsUbuntuSeedDir for example
<pedronis> it's consistent with what dirs itself does
<ijohnson> yes good point
<pedronis> zyga: should we land https://github.com/snapcore/snapd/pull/8265 ? and then replace it when we can?
<mup> PR #8265: tests: add regression test for MAAS refresh bug <Created by zyga> <https://github.com/snapcore/snapd/pull/8265>
<zyga> pedronis: yeah, that sounds acceptable
<zyga> pedronis: I can look quickly tomorrow morning at changing the test, the snap content is not that complex IIRC
<zyga> just "curious"
<mvo> grrr travis gree - 8347 is green since a while but travis did not report this back to GH
<mup> PR snapd#8347 closed: errtracker: add missing mocks <Simple ð> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8347>
<mup> PR snapd#8352 opened: wrappers: generate service files with EnsureDirState [WIP] <Created by zyga> <https://github.com/snapcore/snapd/pull/8352>
<zyga> mvo: travis just loves us today
<ijohnson> pedronis: ok renamed everything in 8339, do you need to re-review it or is it okay if I get 2 other +1s while you're off the rest of the week ?
 * zyga EODs
<zyga> pedronis: I cleared up the archive issue with IS
<zyga> pedronis: apt-get update is correct, the archive just moved and the worker wakes up with older cache
<pedronis> ijohnson: I need to go have dinner, but then I'll be around some more, I can try to give it a look
<zyga> pedronis: so that's good, it's not (hopefully) unreliable
<ijohnson> ok, thanks, I will break for lunch now too
<pedronis> ijohnson: yes, I would close #8338 for now, I'm not completely against but also not super +1
<mup> PR #8338: boot/bootstate20: rm bootState20Base.loadModeenv() <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8338>
<mup> PR snapd#8338 closed: boot/bootstate20: rm bootState20Base.loadModeenv() <Simple ð> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8338>
<mup> PR snapd#8265 closed: tests: add regression test for MAAS refresh bug <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8265>
<zyga> pedronis: I'd like to land https://github.com/snapcore/snapd/pull/8089
<mup> PR #8089: features: enable robust mount ns updates <Created by zyga> <https://github.com/snapcore/snapd/pull/8089>
<zyga> given that 2.45 is open
<zyga> pedronis: also, but this is potentially a longer read, https://github.com/snapcore/snapd/pull/8123 given that it's 2.45 and we landed the simple version for 2.44
<mup> PR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>
<zyga> pedronis: but no rush on this one, not a priority
<pedronis> zyga: yes, #8123 is on my queue
<mup> PR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>
<pedronis> ijohnson|lunch: done, +1 with some final comments
<pedronis> https://www.traviscistatus.com/
<mvo> pedronis: fun
<pedronis> not
<mvo> :P
<mvo> it seems like this whole GH actions comes at the right time
<ijohnson> thanks pedronis
<mup> PR snapd#8353 opened: interfaces/docker-support: make containerd abstract socket more generic <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8353>
 * ijohnson EODs early
#snappy 2020-03-26
<arnatious> I'm almost done snapping up qbittorrent but I'm running into an issue where it's showing no network connection. I fed it a torrent via a url and it fetched that fine. It's on strict confinement and I've attached network, network-bind, and network-manager and connected the last one.
<arnatious> Fetched the torrent metadata* it hasn't been able to start downloading it
<zyga> arnatious: this is insufficient information to debug, do you see any confinement denials in you log files?
<mborzecki> morning
<mborzecki> out for a bit to do groceries, before there's more people arriving at the store
<zyga> mborzecki: o/
<zyga> mvo: good morning :)
<mvo> zyga: good morning
<zyga> how are you feeling today?
<mvo> zyga: good, thanks
<mvo> zyga: you?
<zyga> yeah, I'm trying to sleep more recently
<zyga> I think it works
<mvo> zyga: totally agreed, the right sleep is important :)
<mvo> zyga: what's new? how are the gh actions doing?
<zyga> I'm looking at https://github.com/snapcore/snapd/pull/8350
<mup> PR #8350: github: cache Debian dependencies for unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8350>
<zyga> mvo: not much new yet, I would like to work on feature stuff today
<zyga> mvo: and squeeze one more github action that runs C unit tests and various misc chcecks
<zyga> mvo: and combine the actions into dependency chains, so that we don't spin up spread for sure-failing PRs
<zyga> mvo: I was also wondering if we could move one of the non-failing spread runs over, something that would help others with quick feedback
<zyga> core20?
<zyga> or something like that
<zyga> mvo: apart from that I need to just focus on stuff I have pending
<mvo> zyga: yeah, I think dep-chain is super welcome
<zyga> I noticed that each .yaml file is a separate workflow
<zyga> and you can only have dependency chains within one
<mvo> hm, slightly sad
<zyga> why?
<zyga> it's okay, just splice yaml together
<zyga> speaking about load, I was wondering if having a master commit action useful
<zyga> we test each PR
<zyga> then it lands and gets tested again
<zyga> probably not useful
<zyga> I would much rather have this on the release branches
<zyga> where it is more prudent to be careful
<mvo> zyga: yeah, the master merge test is mostly wasteful
<mup> PR snapd#8337 closed: cmd/snap-bootstrap/initramfs-mounts/tests: use dirs.RunMnt over s.runMnt <Simple ð> <Test Robustness> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8337>
<zyga> mvo: https://github.com/snapcore/snapd/pull/8354 quick one to start the day then
<mup> PR #8354: github: run spread tests on PRs only <Created by zyga> <https://github.com/snapcore/snapd/pull/8354>
<mup> PR snapd#8354 opened: github: run spread tests on PRs only <Created by zyga> <https://github.com/snapcore/snapd/pull/8354>
<mup> PR snapd#8339 closed: dirs: rm RunMnt; boot: add vars for early boot env layout; sysconfig: take targetdir arg <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8339>
<mup> PR snapd#8344 closed: overlord/devicestate,boot: do not hold to the originally read modeenv <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8344>
<mup> PR snapd#8349 closed: tests: cleanup security-private-tmp properly <Simple ð> <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8349>
<mup> PR snapd#8353 closed: interfaces/docker-support: make containerd abstract socket more generic <Simple ð> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8353>
<mvo> zyga: hm, I just noticed something like "skip-spread" would be nice in the actions :)
<zyga> yeah
<zyga> but it couldn't have been in the initial run which also set skip :)
<zyga> you can read labels
<mup> PR snapd#8355 opened: github: run C unit tests <Created by zyga> <https://github.com/snapcore/snapd/pull/8355>
<zyga> let me just check the syntax on how to skip jobs that have a label
<zyga> it's nice that this doesn't have the API bottleneck problem
<zyga> we can just check whatever property we need to
<mvo> yeah
<mup> PR snapd#8354 closed: github: run spread tests on PRs only <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8354>
<zyga> thanks :)
<zyga> mvo: I replied on https://github.com/snapcore/snapd/pull/8350
<mup> PR #8350: github: cache Debian dependencies for unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8350>
<mup> PR snapd#8356 opened: cmd/snap: Implement a "snap routine file-access" command <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8356>
<zyga> jamesh: ^ reviewed
<zyga> jamesh: if you rebase on master there will be less failing tests
<jamesh> zyga: thanks.  I think it already is instance aware though
<zyga> ah, snap.Name has both parts?
<jamesh> yeah.  see cmd/snapinfo.go
<mborzecki> re
<mborzecki> turns out there was more people than i anticipated
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> zyga: when you restart the spread workflow in gh action, does it restart all jobs or just one?
<mborzecki> zyga: i mean all jobs of that workflow (if it's a matrix)
<mborzecki> damn, my trackball buttons are malfunctioning
<mborzecki> zyga: btw failure in spread test that checks file group ownership https://paste.ubuntu.com/p/Y5RrfjxhY6/
<zyga> mvo has fixed that one
<zyga> Currently everything is restarted. Restarting fine grained bits is on the roadmap
<mborzecki> aah
<mvo> uh, that's bit of a downer
<mborzecki> what if we use separate workflows for each system instead of matrix?
<zyga> Same
<zyga> All fine grained bits are coming
<zyga> Although
<zyga> You may be right with separate workflows
<zyga> But then no dependencies
<mborzecki> hmm bummer
<mborzecki> thn maybe we should wait a bit before doing a complete switch
<zyga> trading some for some :)
<zyga> if spread is one big fat target we could restart that
<dot-tobias> hi everyone
<pstolowski> so, wrt https://bugs.launchpad.net/snapd/+bug/1868706 i've tested with lxd & microk8s snaps installed and snapd deb upgraded without issues (along with lots of other debs as i was again testing with a slightly outdated focal). also, Mark wrote that there were no snaps installed
<mup> Bug #1868706: Snapd postinst script hangs <snapd:Triaged> <dpkg (Ubuntu):Confirmed> <systemd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1868706>
<pstolowski> so perhaps it's something with one of snapd's own services
<mborzecki> interesting
<zyga> re
<zyga> okay let's get to coding
<zyga> mvo: can I convince you to +1 https://github.com/snapcore/snapd/pull/8350 ?
<mup> PR #8350: github: cache Debian dependencies for unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8350>
<zyga> it saves a little bit of time
<zyga> and will be more prominent with the next cache PR where go unit tests runtime will shrink
<zyga> (so go tests << 1 minute)
<zyga> uh, I need to pick up a delivery
<zyga> AFK for 15
<pstolowski> wrt 1868706 just tested without any snaps (snap-mgmt purge, and removed all seeds), the upgrade worked as well
<zyga> back now
<zyga> pstolowski: I saw a police patrol checking why people are outdoors
<zyga> that's a new for me!
<pstolowski> zyga: right, they announced it yesterday
<zyga> too bad they are ignoring the hobos hanging around benches :P
<mup> PR snapd#8355 closed: github: run C unit tests <Skip spread> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8355>
<mvo> mborzecki: do you think 8342 needs a samuele review? it looks pretty good from my pov
<mup> PR snapd#8309 closed: o/configcore: FilesystemOnlyApply method for early configuration of core (1/N) <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8309>
<mborzecki> mvo: we can always tweak the naming later, but the endpoint and data POSTed there was discussed and agreed on, so i think it's fine to land it with another review
<mborzecki> pstolowski: maybe you could take a look at #8342 as well?
<mup> PR #8342: client, daemon, overlord/devicestate: request system action API and stubs <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8342>
<mvo> mborzecki: +1
<pstolowski> mborzecki: sure
<mborzecki> pstolowski: thanks!
<zyga> mvo: I've changed how we cache .deb files, seems to be passing;
<zyga> mvo: I'll send one more patch that runs spread after unit tests
<zyga> mvo: and that's all from me on gh actions today
<mvo> zyga: ok
 * zyga pushes to see if it uses the cache
<mup> PR snapd#8335 closed: many: introduce naming.WellKnownSnapID <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8335>
<dot-tobias> mvo: quick ping about zyga's https://github.com/snapcore/snapd/pull/8089#issuecomment-599914100 from affected snap developer :)
<mup> PR #8089: features: enable robust mount ns updates <Created by zyga> <https://github.com/snapcore/snapd/pull/8089>
<zyga> dot-tobias: what about it?
<zyga> dot-tobias: it needs to be reviewed and merged
<mup> PR snapd#8277 closed: asserts,o/devicestate: support model specified alternative serial-authority <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8277>
<zyga> pstolowski: ping
<pstolowski> zyga: pong
<zyga> pstolowski: should I push a tiny branch with this change: https://github.com/snapcore/snapd/pull/8352/files#diff-08088787360fb3ca74a0aed4c6103b22R264
<mup> PR #8352: wrappers: generate service files with EnsureDirState [WIP] <Created by zyga> <https://github.com/snapcore/snapd/pull/8352>
<zyga> the part after, and including &&
<mborzecki> zyga: yeah, jsut had to restart the spread run on opensuse-15 and all spread jobs in gh action got restarted :(
<pstolowski> zyga: ah, this is the err cleanup bug you pinged me about some time ago? yes, it's fine, thank you!
<zyga> mborzecki: right
<zyga> pstolowski: k, doing so
<pstolowski> zyga: it escaped me
<mborzecki> zyga: so the question now is, can we still merge the PRs when one of the unstable systems fails?
<dot-tobias> zyga: Yes, maybe I should've been more elaborate: Just wanted to ask if that's on the plate for 2.44, as I'm getting quite a few requests from wpe-webkit-mir-kiosk users after the last snap revision release. Most of them struggle with the required console commands to discard the namespace and refresh again, but at least I could tell them that this won't be an issue after snapd 2.44. Sorry if I came across bugging! I know that things slip under the
<zyga> mborzecki: note that those are not mandatory
<dot-tobias>  radar quickly, and thought like with 7655 a friendly ping might help ð
<zyga> mborzecki: you can totally ignore it
<mborzecki> ah ok
<zyga> dot-tobias: I don't know, it's a question to mvo
<zyga> dot-tobias: maybe?
<zyga> mborzecki: there's a way to set passing/failing status and other thing via actions but I didn't go that deep yet
<zyga> mborzecki: so we could have a run matrix that chooses what must pass
<zyga> mborzecki: or what cannot fail
<zyga> mborzecki: but instead of having YAML for it there's just the API you can reach
<dot-tobias> zyga: That's who the ping msg was intended for, should've left out your handle â sorry
<pstolowski> mborzecki: one wondering re your PR, otherwise +1
<zyga> dot-tobias: no worries, I hope you can get it in
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8357
<mup> PR #8357: wrappers: respect pre-seeding in error path <Bug> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8357>
<zyga> mvo: ^ for 2.44
<mup> PR snapd#8357 opened: wrappers: respect pre-seeding in error path <Bug> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8357>
<zyga> man, this is so weird
<zyga> you push something
<zyga> and green tick shows up a moment later
<zyga> that's too werid
<zyga> can we go back to days of waiting for the red cross?
<mborzecki> zyga: you mean the 1940s?
<zyga> mborzecki: is that what travis is?
<mborzecki> zyga: it feels like it at times
<mborzecki> pstolowski: hmm good question about the label, right now we only check whether it's not empty
<pstolowski> mborzecki: a-zA-Z check or some such would do
<mborzecki> pstolowski: we should probably enforce some validity checks, probably [a-zA-Z0-9]+
<pstolowski> yeah
<ogra> zyga, mvo, should i make a minor commit (adding a full stop to the end of the comment or whatnot) to the usbprinter PR so the auto-testing kicks in again ?
<zyga> ogra: please do
<ogra> ok
<zyga> I was unable to restart testing
<zyga> ogra: or better
<zyga> ogra: merge master
<mborzecki> pstolowski: looked at seed, but there's no checks either
<mborzecki> pstolowski: hm it probably makes most sense to add it in the seed 'seed' packge, in a follow up though
<ogra> zyga, bah i hadn't reloaded the page ... seems mborzecki already managed to restart the test anyway
<zyga> cool, that's ok
<zyga> I need to improve caching today
<mborzecki> ogra: yeah, though i doubt it stated given the usual job queue length
<zyga> most of the extra waste is each spread run checking out a git tree
<ogra> it seems to be running
<zyga> I need to just have a local copy as accelerator
<ogra> interesting though that you are the only one being able to trigger them
<zyga> ogra: me or maciek?
<ogra> maciek
<jamesh> mvo: fyi, checks for https://github.com/snapcore/snapd/pull/8289 have passed except for OpenSUSE 15.1 -- there it is the unrelated session-tool spread test that failed
<mup> PR #8289: xdgopenproxy: forward requests to the desktop portal <Squash-merge> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8289>
<zyga> jamesh: I am close to fixing the session-tool issue
<zyga> jamesh: please just ignore that test failure
<zyga> jamesh: also, sessions are hard :)
<jamesh> zyga: I wonder if it would be better to implement this kind of thing in spread itself?
<zyga> jamesh: not sure, it's a bit of a volatile problem
<zyga> jamesh: only if we can be perfect about it
<jamesh> zyga: e.g. have a task marked as requiring a user session, and have its prepare/execute/restore run as a user in a session
<zyga> jamesh: and I doubt we can
<zyga> jamesh: that would be nice but that's a bigger change and it's still unclear how to _get_ a user session reliably
<mup> PR snapd#8358 opened: seed: validate UC20 seed system label <Simple ð> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8358>
<mborzecki> pstolowski: mvo: ^^
<pstolowski> ty
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8358#pullrequestreview-381913798
<mup> PR #8358: seed: validate UC20 seed system label <Simple ð> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8358>
<mup> PR snapd#8359 opened: config: add new Transaction.GetPristine{,Maybe}() function <Created by mvo5> <https://github.com/snapcore/snapd/pull/8359>
<cachio> xnox, hey
<pstolowski> cachio: hi! did you have time to try reproduce https://bugs.launchpad.net/snapd/+bug/1868706 ?
<mup> Bug #1868706: Snapd postinst script hangs <snapd:Triaged> <dpkg (Ubuntu):Invalid> <systemd (Ubuntu):Invalid> <https://launchpad.net/bugs/1868706>
<cachio> pstolowski, yesterday I ran lot of tests but no luck
<cachio> now I am going to run in a desktop vm
<cachio> pstolowski, this test https://paste.ubuntu.com/p/FxXDys9KkT/
<zyga> hmm
<cachio> pstolowski, if you want to take a look and propose anything else should be great
<zyga> we cannot create warnings through the API, can we?
<pstolowski> cachio: ok. note Mark said in the comments that there are no snaps when this happened
<zyga> pstolowski: could it be seeding
<zyga> pstolowski: when using focal you may end up with bad seeding
<zyga> pstolowski: and then snap update from the deb archive will indeed "hang"
<zyga> pstolowski: as the postinst script waits for seeding to complete
<pstolowski> zyga: it's an existing system afaiu
<zyga> pstolowski: I know
<zyga> pstolowski: but think if this is possible
<cachio> pstolowski, ah, yerday I cloneed a vm
<cachio> and started upgrading
<zyga> pstolowski: normally seeding being broken shows up as 1) no snaps 2) hang during update
<cachio> like 10 times
<cachio> but coulnd reproduce
<cachio> zyga, something that I noticed is that postinst script tahngs like 1 minute or more until it finishes
<cachio> it happened many times
<cachio> but then it finishes
<zyga> cachio: did you check what was going on then?
<pstolowski> zyga: hmm that's an interesting observation. i thought about seeding but then the fact it wasn't a new installation (apparently) confused me. otoh, no snaps at all looks weird as well nowadays. indeed if seeding never completed then perahps it's causing an issue
<zyga> yeah
<zyga> I'm 90% sure that's that
<zyga> 0 snaps
<cachio> yes, but didnt see the error reported by mark
<zyga> unless he actually removed snaps
<cachio> I can check that again
<zyga> mvo: can we land https://github.com/snapcore/snapd/pull/8350 now?
<mup> PR #8350: github: cache Debian dependencies for unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8350>
<zyga> all green and adjusted
<pstolowski> zyga: thanks for the idea, i'll try to break seeds and see
<zyga> pstolowski: I have 20.04 seed that's broken
<zyga> if you want it
<zyga> tarballed it u0
<zyga> in case I needed to :)
<zyga> it's the one from one of the broken dailies
<zyga> daily images
<pstolowski> zyga: thanks, i'll quickly try to break it myself, will ask you for image if that doesn't work ;)
<zyga> k
<mup> PR snapd#8360 opened: tests: adding more workers for ubuntu 20.04 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8360>
<pstolowski> zyga: hmm i cannot provoke seed error, i'm probably breaking it wrong ;). share your tarball pls
<zyga> pstolowski: sure
<zyga> pstolowski: it's ~300MB
<zyga> pstolowski: let me try something
<pstolowski> zyga: it's fine, i'm on fiber here
<zyga> man really?
<zyga> you should run the spread cluster then ;D
<zyga> I'm on LTE
<pstolowski> 300Mb/s, from orange
<zyga> I wish it was on my street
<zyga> anyway
<zyga> I have the file now
<zyga> sending away
<mup> PR snapd#8342 closed: client, daemon, overlord/devicestate: request system action API and stubs <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8342>
<zyga> brb
<cachio> zyga, when postinit script runs I see this
<cachio> root       10026    9998  0 10:20 pts/0    00:00:00 /bin/systemd-tty-ask-password-agent --watch
<cachio> it hangs for some seconds
<zyga> cachio: ha
<zyga> that's polkit
<zyga> mborzecki: ^
<zyga> remember what you told me yesterday
<zyga> is that what you saw?
<mborzecki> ouch
<mborzecki> wow
<mborzecki> perhaps it's always started (doesn't make sense though?)
<mborzecki> cachio: have you seen it on focal only?
<cachio> also I see this
<cachio> message+     429       1  0 10:08 ?        00:00:01 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
<cachio> just checked that on focal
<zyga> mborzecki: mvo told us recently that apt (or dpkg) always creates a pty
<zyga> so perhaps systemd thinks, gee let me ask the user
<zyga> and spawns some text polkit prompt
<zyga> anyway
<zyga> I need to brb
<zyga> for real
 * zyga afk
<mborzecki> hm idk, maybe it systemctl shoudl be called with --no-ask-password?
<mborzecki> zyga: looking at the code it's started always if you're on local bus (i.e. talking to the local systemd) and there wa no --no-ask-password
<mborzecki> hmmmm
<pstolowski> zyga: you were right!!
<pstolowski> how can i buy you a beer? ;)
<pstolowski> mvo: ^ mistery of Mark's bug solved i think
<zyga> pstolowski: ha
<zyga> pstolowski: I could use a coffee :D
<zyga> I just tried making one
<zyga> but my son, Janek, is upstairs with remote teacher video call
<zyga> I guess it's the age were everyone pretty much does what I do, sit in front of a screen all day
<zyga> write type talk to people
<zyga> I need to move the coffee machine here :D
<pstolowski> apt is now hanging on snapd debs
<zyga> lovely
<pstolowski> pstree shows similiar output
<zyga> pstolowski: what does pstree show?
<pstolowski> zyga: it matches the one from bug report https://pastebin.ubuntu.com/p/74XywhJfwc/
<zyga> yeah
<pstolowski> snapd.seeded.service makes it wait i presume
<zyga> the problem is that we should not start the seeding unit
<zyga> it's a debhelper thing
<zyga> it's not sane in our case
<pstolowski> mhm. we should probably do something sane
<zyga> I think we need to adjust that debhelper line
<pstolowski> cachio: so, problem understood ^
<zyga> mvo: 2.44.1 is failing to build in the edge ppa
<mvo> zyga: uh, all of it?
<zyga> https://www.irccloud.com/pastebin/yjTrMeXv/
<zyga> just this test
<zyga> we've seen it before, didn't you say it was some package in the archive thing?
<mvo> pstolowski: oh, mystery solved? I like that!
<mvo> pstolowski: can you give me the tl;dr summary please? or explain in the standup maybe
<ijohnson> good work pstolowski
<ijohnson> and zyga too :-)
<ijohnson> and morning folks
<zyga> good morning :)
<zyga> oh
<zyga> standup time
<pstolowski> mvo: focal image with broken seeds; seeds never completes; snapd deb update blocks on snapd.seeded.service
<pstolowski> i've updated https://bugs.launchpad.net/snapd/+bug/1868706
<mup> Bug #1868706: Snapd postinst script hangs <snapd:Triaged> <dpkg (Ubuntu):Invalid> <systemd (Ubuntu):Invalid> <https://launchpad.net/bugs/1868706>
<pstolowski> hey ijohnson
<mvo> pstolowski: ha! fun, just like last time. also *so* sad
 * ijohnson stands up while sitting down
<zyga> mvo: /dev/fuse has a new meaning
<zyga> there's an IOCTL to explode the pC
<mvo> zyga: haha
<zyga> I wrote the instructions for github actions runner
<zyga> who wants to work with me to try it ouy?
<zyga> degville: perhaps you? (it's a wall of text)
<zyga> but anyone who wants to is totally welcome to
<degville> zyga: yes, of course.
<zyga> mvo: ok, it's in progress :)
<ijohnson> mvo is it okay for me to de-conflict #8010 now ?
<mup> PR #8010: snap-bootstrap: add support for "recover" mode <Needs Samuele review> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8010>
<mvo> ijohnson: sure
<ijohnson> ack
 * zyga -> food
<mup> PR snapd#8358 closed: seed: validate UC20 seed system label <Simple ð> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8358>
<mup> PR snapd#8357 closed: wrappers: respect pre-seeding in error path <Bug> <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8357>
<mup> PR snapd#8361 opened: o/devicestate: rename readMaybe* to maybeRead* <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8361>
<zyga> re
<mup> PR snapd#8350 closed: github: cache Debian dependencies for unit tests <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8350>
<zyga> ta!
<zyga> I'll propose the last step in a sec, let me just organize myself after the break
<mup> PR snapd#8362 opened: github: fix order of go get caches <Simple ð> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8362>
<mup> PR snapd#8363 opened: github: combine tests into one workflow <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8363>
<ijohnson> mborzecki: is #8305 ready to review now?
<mup> PR #8305: cmd/snap-recovery-chooser: add recovery chooser <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8305>
<mborzecki> ijohnson: yes, there will be some tweaks to the data that's passed back, but the overall shape should not change at this point
<ijohnson> ack I'll review that today then
<Saviq> zyga: you should know thisâ¦ following https://snapcraft.io/docs/installing-snap-on-fedora on F31
<zyga> yeah?
<Saviq> $ snap install hello-world
<Saviq> error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:
<Saviq>        /tmp/sanity-mountpoint-444060033: unknown filesystem type 'squashfs'.
<zyga> yeah
<zyga> also known as rpm sucks at dependencies
<zyga> you are installing the modules for the kernel
<zyga> but not the one you are running
<zyga> IIRC rebooting will fix it
<zyga> because now kernel and modules match
<Saviq> DUH
<Saviq> https://forum.snapcraft.io/t/installing-snap-on-fedora/6755/9?u=saviq
<zyga> Saviq: try rebooting and tell me if that helped
<Saviq> nope
<Saviq> zyga: â
<zyga> Saviq: hmmmmmm
<zyga> Saviq: is that a cloud vm?
<zyga> or a desktop system
<Saviq> zyga: cloud
<zyga> ah
<zyga> so cloud is more complex - their kernel seems to lack that
<zyga> and we cannot express the dependency clearly IIRC
<zyga> there's a package you should be able to install though, one moment
<Saviq> zyga: ack, I will reply to the forum thread with a reproducer
<zyga> Saviq: try installing kernel-modules
<Mirv> you may be interested in checking if this is something on snap side or fwupd side: https://github.com/fwupd/fwupd/issues/1915
<Saviq> whois Mirv
<Saviq> Timo!
<Saviq> o/
<Mirv> (likely fwupd, as it's a regression, but I guess something in snap when using classic mode could also assume ubuntuish ca-certifates)
<Mirv> :D Saviq!!
<zyga> Mirv: opensuse uses different /etc/ssl layout than debian
<zyga> Mirv: perhaps we need to look
<zyga> it' a classic snap?
<zyga> so it should be less so but still
<Mirv> zyga: yes it does, I haven't bumped into such problem before with any snap though, and fwupd also used to work correctly
<zyga> can you reproduce that or is that someone else reporting?
<Mirv> it's my report
<zyga> does /etc/ssl/certs/ca-certificates.crt exist?
<Mirv> so simply installing fwupd currently on Tumbleweed shows it
<Mirv> no, there's no such thing on openSUSE
<zyga> do you know what is trying to read that file?
<zyga> is it some kind of hard-coded feature of the library bundled in the snap/
<zyga> I'm also surprised it worked before
<zyga> nothing changed in that regard in many months
<Mirv> not really.
<Mirv> it was my guess it'd be something changed in fwupd, but thought to mention here too if it'd immediately ring some bell
<Mirv> strace https://pastebin.ubuntu.com/p/FRzNVPM9QJ/
<zyga> Mirv: where are the certs on your system?
<zyga> Mirv: IIRC it's just a "hard thing" to make classic snaps
<zyga> I don't think snapd can do anything about this
 * cachio lunch
<mup> PR snapd#8364 opened: github: offload self-hosted workers <Created by zyga> <https://github.com/snapcore/snapd/pull/8364>
<Mirv> zyga: around /usr/share/pki/trust/ , the system is very different from Debian/Ubuntu indeed
<zyga> Mirv: can you try to summarize how it looks like, perhaps it will allow us to come up with some ideas
<Mirv> zyga: right, thanks, that's mostly what I wanted to hear that it's up to snap package to (try to) keep cross-distro compatibility in a classic snap
<zyga> Mirv: and it is also useful because mvo is working on a ssl-related feature CC mvo  ^
<Mirv> zyga: I'm not very familiar with that either https://unix.stackexchange.com/questions/80131/how-do-i-install-a-system-wide-ssl-certificate-on-opensuse
<zyga> Mirv: can you respond to https://github.com/fwupd/fwupd/issues/1915
<zyga> Mirv: I'm not familiar with the snap
<Mirv> Access by specifying a revision is not allowed for this Snap. ... hmm, ok, I'd have liked to triage
<Mirv> answered yes, maybe superm1 can debug it if he's maintaining the snap
<ijohnson> zyga: have you ever looked at `spread -abend` ?
<ijohnson> seems to do what you were wanting in this morning's SU
<zyga> yeah
<zyga> can you remind me?
<zyga> ah
<zyga> the log?
<zyga> or ... no?
<zyga> I don't recall
<ijohnson> you wanted a way to stop the spread run on the first failure
<zyga> ah
<zyga> oh!
<zyga> then I must have not remembered the name right, I dind't know it exits
<zyga> oh that's perfect
<zyga> I'll use that
<zyga> thank you  :)
<ijohnson> :-)
<Mirv> zyga: turns out I was able to install older versions after all, which also failed.. so then it turned out it's actually openSUSE bug of some sort, to which I documented a workaround
<cachio> zyga, did yo usee the values I left in the standup doc?
<zyga> cachio: yes but they are too opaque, we should check out what's taking that time
<zyga> yes numbers are bigger
<zyga> why?
<cachio> zyga, do you know a way to trace systemd and get times?
<zyga> cachio: I would look at perf
<zyga> I think it is not systemd
<zyga> but many components of the system and their interaction
<zyga> cachio: if you work with maciek on this he should be able to help you, he's pretty good at using perf
<cachio> zyga, sure
<zyga> ok, I need to EOD soon
<cachio> mborzecki, do you have any suggestion to see what's going on with systemd calls?
<mup> PR snapcraft#2984 closed: plugins: move the existing plugin to a new package <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2984>
<mup> PR snapcraft#2993 closed: repo: remove dead code from deb implementation <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2993>
<mup> PR pc-amd64-gadget#35 closed: grub.cfg-boot: drop compatibility mode <Created by anonymouse64> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/35>
<mborzecki> cachio: not really, probably we'd have to start with a single call, eg systemctl <some>.service and then observe the bus traffic between the old version and new one, probably gather a bunch of samples too
 * zyga EODs
<mborzecki> yeah, me too
<mborzecki> now the 'home schooling' shift starts :/
<mup> PR snapcraft#2994 closed: repo: move filtered package list from manifest.txt into a python list <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2994>
<mup> PR snapd#8361 closed: o/devicestate: rename readMaybe* to maybeRead* <Simple ð> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8361>
<mup> PR snapd#8359 closed: config: add new Transaction.GetPristine{,Maybe}() function <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8359>
<mup> PR snapcraft#2995 opened: Add gcc to the build-packages for the gnome-3-34 extension <Created by hellsworth> <https://github.com/snapcore/snapcraft/pull/2995>
<mup> PR snapd#8365 opened: seed: add Info() method for seed.Snap <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8365>
<mup> PR snapd#8366 opened: cmd/snap-bootstrap/initramfs-mounts: verify the seed snap matches bootloader env <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8366>
<mup> PR snapd#8367 opened: snap/cmd: the model command needs just a client, no waitMixin <Simple ð> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8367>
<mup> PR snapd#8345 closed: boot,overlord: rename operating mode to system mode  <Reviewed> <Skip spread> <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8345>
<mup> PR snapd#8360 closed: tests: adding more workers for ubuntu 20.04 <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8360>
#snappy 2020-03-27
<zyga> Hello
<zyga> mborzecki: today is the switch day
<mborzecki> zyga:  hey
<mborzecki> zyga: 'the switch day' ?
<zyga> Hi :-)
<mborzecki> from/to what?
<zyga> Check my PRs
<jamesh> snaps on the Nintendo Switch?
<mborzecki> hahah ;)
<zyga> Haha
<zyga> That would be fun
<mborzecki> zyga: didn't look yet, responding to some posts in the forum
<zyga> Ok
<zyga> Iâm on a walk
<zyga> Will start as usual
<zyga> jamesh: but I want to mention something
<zyga> Imagine if we embedded desktop metadata in an early block in each snap
<zyga> Name, icon, etc
<jamesh> can you meaningfully control order in the squashfs?
<jamesh> or are you thinking of something outside of the squashfs structure?
<zyga> Outside
<zyga> You can make the FS leave a hole up front
<zyga> It could be the same data we have later
<zyga> But easier to extract for preview
<jamesh> So this would just be for the case of a user browsing a snap file in Nautilus?
<zyga> For the most part
<jamesh> for installed snaps, we can just go through the mount point, and stuff in the store we can depend on store APIs
<zyga> Well, I would love not having to mount unused snaps
<zyga> Imagine we have 100s of revisions around
<zyga> Or it is a phone again
<zyga> You run only some at a time
<zyga> Having access to metadata without mounting would be good
<zyga> Mounting is costly and racy
<jamesh> so, icons could be many files if the snap takes advantage of icon theming
<zyga> (We still tracks bugs in loop back devices and mount races)
<jamesh> I could definitely see other metadata be interesting
<zyga> Yeah
<zyga> Iâm not super keen on theming.
<zyga> I see this as a small container
<zyga> A zip probably
<zyga> Easy to discover and reas
<zyga> Read*
<zyga> That has some sort of meta/ directory copy
<jamesh> the icon theming is both to provide icons at multiple sizes and icons that look at home in different themes
<zyga> I strongly believe in apps with curated icons that are never themed
<zyga> Skype logo, ff logo
<zyga> Etc
<zyga> So Iâm not focusing on that
<jamesh> right, but you may still want a different shape for 16x16 vs. 512x512
<zyga> We could presumably have several icons and enough information to use them
<jamesh> remove details, align to pixel grid, etc
<zyga> Yes, agreed
<zyga> I would love for snap list to. It have to mount snaps
<zyga> *not
<zyga> Anyway, just an idea
<zyga> Some snaps would have to be mounted presumably
<zyga> But most would not IMO
<jamesh> the current handling of desktop files and themed icons rely on copying data out of the snap during the install process
<jamesh> so could allow the shell to display launchers for snaps before they're mounted
<zyga> Sure but snapd heavily relies on access to snap metadata directory of each revision
<zyga> Yeah, that too
<zyga> Like app image a little
<jamesh> (e.g. if the mount was delayed until "snap run"
<zyga> Exactly!
<jamesh> You're probably going to need to temporarily mount the snap during the install process anyway though, right?
<zyga> During install yes
<zyga> Well
<zyga> Maybe
<zyga> For store snap not really
<zyga> If we have assertions I donât see why we would have to
<zyga> Unless they have hooks
<zyga> My point is that snapd would not need to anymore
<zyga> Snap run would
<zyga> So that is transparent
<jamesh> zyga: while you're playing around with github actions, a spread problem matcher could be a good addition
<zyga> Oh yeah!
<jamesh> Jump right to the errors in the log
<zyga> Indeed
<zyga> I need to make spread and action anyway
<mborzecki> zyga: so your basement data center is up and operational now? :)
<zyga> To handle post
<zyga> mborzecki: not required
<jamesh> I'm not sure we'd be able to link the errors to files, but at least it would recognise that there were errors in the log
<mborzecki> btw. now that spread is part of thw tests workflow, if one job fails we'll restart the whole forkflow right? unit tests and all
<jamesh> (if the full file name isn't in the log message, then it's not there to extract via a regexp)
<zyga> Yeah we can do that
<mborzecki> zyga: heh ok i see why you're doing this in #8363
<mup> PR #8363: github: combine tests into one workflow <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8363>
<mborzecki> zyga: so we need the ability to restart single job in workflow or dependencies between workflows right (then spread workflow* would depend on unit tests succeeding)
<zyga> re
<zyga> mborzecki: that's already done
<zyga> mborzecki: restarting single jobs is coming in next actions release IIRC
<zyga> mborzecki: so we can just wait
<zyga> mvo: good morning
<zyga> I love how our PRs that move workload from travis to github actions are blocked by travis
<mvo> zyga: good morning
<zyga> mvo: could you please look at 8362, 8364 and 8364
<zyga> mvo: I think you will find there's a logical progression towards the result there
<zyga> mvo: this doesn't change the status quo yet, I'll make one shortly that does
<mvo> zyga: checkin
<zyga> mvo: switching off travis entirely in the process
<mvo> g
<zyga> thank you very much sir :)
<mup> PR snapd#8362 closed: github: fix order of go get caches <Simple ð> <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8362>
 * zyga politely asks for reviews of a +3,-2 PR: https://github.com/snapcore/snapd/pull/8089
<mup> PR #8089: features: enable robust mount ns updates <Created by zyga> <https://github.com/snapcore/snapd/pull/8089>
<mup> PR snapd#8363 closed: github: combine tests into one workflow <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8363>
<zyga> mvo: jamesh gave me an idea, we could use a feature of github actions to spot errors in spread
<zyga> there's a way to run a scanner over the log
<zyga> and say "here, there is something interesting here'
<zyga> and this is the label"
<zyga> we could extract each error even without looking at the logs ourselves
<zyga> it requires some javascript to be written though
<zyga> so not today
<zyga> but it's totally doable and many actions use this
<jamesh> zyga: shouldn't require any javascript
<zyga> jamesh: oh?
<zyga> IIRC most actions require that
<zyga> but maybe I missed something
<zyga> I need to use javascript anyway, to implement post: ...
<zyga> mvo: please check my comment on -abend
<jamesh> you just need a json file containing the problem matcher, and you can issue a command to enable it with the appropriate "echo" incatation
<zyga> jamesh: but that requires a proper action
<jamesh> zyga: no
<zyga> or are you saying this is something any run: ... thing can do?
<zyga> that would be amazing, can you point me to any examples or docs for this?
<zyga> I didn't know about this
<jamesh> all the javascript does is print a specially formatted command to stdout
<jamesh> let me see
<mvo> jamesh: do you know if there is something like "fail-ok" like on travis? we have som eunstable systems that we consider failures to be ok but the summary on the /pulls list has a red "x" once one action fails
<jamesh> zyga: problem matcher json example: https://github.com/actions/toolkit/blob/master/docs/problem-matchers.md
<jamesh> zyga: command to enable problem matcher: https://github.com/actions/toolkit/blob/master/docs/commands.md#problem-matchers
<zyga> ah
<zyga> that's super useful
<zyga> thank oyu
<zyga> I wonder what's that weird ::foo syntax they have
<zyga> I've seen it used to set env variables
<zyga> but I didn't find a reference of what else you can do
<jamesh> it's the syntax for steps to issue commands to the runner
<zyga> thank you :)
<jamesh> there's similar stuff in Travis with different syntax
<jamesh> (for e.g. reporting timing or folding sections of output)
<jamesh> The main reason they push JS for reusable actions is because it is portable across linux, macosx, and Windows
<jamesh> It doesn't actually have any special powers you can't do through a simple shell script "run:" step
<zyga> mvo: pushed
<zyga> jamesh: my view on that https://twitter.com/zygoon/status/1243239498101768192
<jamesh> zyga: I did "snap install node"
<zyga> I will try
<jamesh> actually, "snap install --channel 13/stable node"
<zyga> I suspect I still need to get the million shitty dependencies from non
<zyga> Npm
<jamesh> --classic too, actually
<jamesh> each project is going to install its own dependencies
<jamesh> the same as go projects
<jamesh> this is just the way the world works these days :-)
<zyga> Except go has a stdlib
<jamesh> so does node
<zyga> Maybe go has a better one :-)
<zyga> I meant almost 300 dependencies
<zyga> Each one with a small lib
<jamesh> the node one has some serious warts
<zyga> Yeah, I think node itself is just one big wart with smaller warts you can add on top :-)
<zyga> (I donât like that stack)
<jamesh> I'm not sure why the .deb version is pulling in so many dependencies
<jamesh> zyga: I'd recommend taking Github's typescript-action template and work from there
<jamesh> that'll give you a working npm project with code reformatting and linting built in, plus TypeScript's type annotation checking
<jamesh> makes things slightly less error prone
<zyga> Good idea
<jamesh> That's what I did, and then just pretended it was weird looking Python
<pstolowski> morning
<zyga> good morning pawel
<mborzecki> pstolowski: hey!
<mup> PR snapd#8367 closed: cmd/snap: the model command needs just a client, no waitMixin <Simple ð> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8367>
<mup> PR snapd#8368 opened: github: goodbye travis <Created by zyga> <https://github.com/snapcore/snapd/pull/8368>
<zyga> mvo: heh
<zyga> mvo: spread without -v prints preparing, restoring
<zyga> and executing too
 * zyga wonder if something is broken
<zyga> it's not any more quiet for sure
<pstolowski> we need --quiet then :/
<mborzecki> zyga: hm iirc -v only adds some extra bits about packing the tarball
<zyga> uh?
<zyga> weird
<mvo> pstolowski: is 8270 ready? it's still mark blocked but got a +1 from samuele already?
<mborzecki> and -vv does the backend query dumps
<zyga> so we need -q
<zyga> or something like that
<pstolowski> mvo: yes it's ready, it was only blocked because of endpoint name change (which was done). we can contemplate specializing some errors based on the list from Tony, but I think it can be a followup
<pstolowski> mvo: and maybe it won't be needed (i haven't analyzed the list yet)
<mvo> pstolowski: ok, please remove the blocked label then and I will try to get to it later today (but tons of meetings)
<pstolowski> mvo: sure, done
<pstolowski> and thanks\
<mvo> ta
<zyga> our static checks run slower than our unit tests
<zyga> needs some polish there
<zyga> mborzecki: check out 8368
<zyga> static checks, then unit tests, then two canary spread runs (16.04 and core16) then all remaining stable spread systems then unstable (non-failing)
<mup> PR snapd#8369 opened: boot, overlord/devicestate, daemon:  <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8369>
<mborzecki> mvo: ^^
<mborzecki> zyga: some static checks could be written in go linters, but hard to say whether that'd make them faster
<zyga> mborzecki: no, it's mostly silliness in how we run them
<zyga> mborzecki: we can make it near-instant
<zyga> mborzecki: need to decouple from run-checks monster
<mborzecki> run-monster-checks
<zyga> mborzecki: but not super priority, I wanted to switch over away from travis
<zyga> so nobody has to wait
<zyga> then we can polsh
<zyga> so people are amazed that we didn't do it earlier
<zyga> f... travis build failed again
<zyga> google:debian-9-64:tests/main/interfaces-packagekit-control failed https://www.irccloud.com/pastebin/RJNxNY3y/
<zyga> please review https://github.com/snapcore/snapd/pull/8364 :)
<mup> PR #8364: github: offload self-hosted workers <Created by zyga> <https://github.com/snapcore/snapd/pull/8364>
<mborzecki> hmm spread-shellcheck could run the MATCH -v and multiline checks, and it's already parallel, so at least locally there could be a difference
<zyga> mborzecki: we need to break down big chunks into separate steps
<zyga> then we see time
<zyga> then we optimize
<zyga> then we win
<zyga> mborzecki: we should aim to get both get better total throughput and responsiveness - I think careful decomposition, dependencies and not duplicating work gets us there
<zyga> also, not running things over and over and over and over and over again like often do
<zyga> brb, need tissue, my nose is running like crazy (each spring the same story)
<zyga> sorry :|
<zyga> re
<zyga> I'd like to merge https://github.com/snapcore/snapd/pull/8364
<mup> PR #8364: github: offload self-hosted workers <Created by zyga> <https://github.com/snapcore/snapd/pull/8364>
<zyga> to make my home network more compatible with home learning
<zyga> mvo: ^
<zyga> mborzecki: ^
<mvo> zyga: was in a meeting, looking
<zyga> ta
<dot-tobias> are snapcraft forum notifications working for anyone here? I neither get push notifications in the browser, nor the email notifications. Didn't change my settings.
<mborzecki> dot-tobias: they are
<mcphail> Hi. What plugs do I need to declare for access to /dev/uinput and /sys/bus/usb/devices/ ?
<zyga> mcphail: hello, currently nothing exposes /dev/uinput
<zyga> mcphail: as for /sys/bus/usb/devices therer are a few depending on what you need (read/write?)
<zyga> you can use hardware-observe or raw-usb or a few others
<mcphail> zyga: aargh. That's a shame. Trying to get sc-controller to run confined. I think I just need read to the usb devices
<zyga> sc-controller?
<zyga> mcphail: new interfaces can be added
<mcphail> app to get steam controllers running on non-steam games. Doesn't work on 20.04 because of no real python2 support
<zyga> I'm trying to debug something now but if you leave us the details, ideally on the forum, a new interface can be crafted rather quickly
<mcphail> Will do. Thanks zyga
<zyga> brb
<mup> PR snapd#8364 closed: github: offload self-hosted workers <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8364>
<zyga> ta!
<zyga> mvo: I will do more about gh actions over weekend
<zyga> mvo: but not today
<zyga> mvo: some preview is in that draft branch that has proper sequencing and no longer uses travis
<zyga> mvo: but I need to port misc stuff and improve things
<zyga> mvo: unless you say this is a priority
<popey> mvo: you're right lzo compressed snaps get held for review. https://paste.ubuntu.com/p/Z7YnNPKd3h/
<zyga> re
<zyga> mborzecki: I want to add a parser for /proc/PID/cgroup
<zyga> mborzecki: shall the parser to to osutils and the high-level use to sandbox/cgroup?
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8369 has a weird title (empty)
<mup> PR #8369: boot, overlord/devicestate, daemon:  <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8369>
<mborzecki> zyga: hmm sandbox/cgroup feels like a better fit
<zyga> spread feature I would kill for (not really): preserving history
<mvo> popey: yeah, the review is expected, should be possible to manually override I hope
<mvo> zyga: not a priority, we need to make sure we also have the static tetss etc
<zyga> mvo: I ported static tests over, I need to port CLA check and some misc bits though
<mvo> zyga: nice
 * zyga figured out how to handle session-tool reliably, more so than before :)
<zyga> ha, and also for root user
<cmatsuoka> mborzecki: https://github.com/snapcore/snapd/pull/8370
<mup> PR #8370: snap-bootstrap: fix disk layout sanity check <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8370>
<mup> PR snapd#8370 opened: snap-bootstrap: fix disk layout sanity check <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8370>
<mborzecki> cmatsuoka: thanks!
<cmatsuoka> mborzecki: hopefully this will solve the issue and the crash-before-mkfs scenario as well
<mvo> zyga: https://bugs.launchpad.net/ubuntu/+source/xchat/+bug/1869332 is what I reported
<mup> Bug #1869332: Fails to launch correctly with gnome-shell in focal <xchat (Ubuntu):New> <https://launchpad.net/bugs/1869332>
<mvo> zyga: what bugreport did you see?
<zyga> mvo: the bug I ran into was different, it was locale dependent
<zyga> the .mo file contained a translation that segvfaulted
<zyga> but
<zyga> the locale was different in the session and in the terminal somehow
<zyga> in the end I fixed that one, but that was years ago and I stopped using xchat since
<zyga> oh well
<mup> PR snapd#8371 opened: overlord/devicestate, daemon: record the seed current system was installed from <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8371>
 * cachio lunch
<mborzecki> cmatsuoka: just before i leave, some good news, the branch seems to work
<cmatsuoka> \o/
<mborzecki> cmatsuoka:  i was able to reboot form run to install again, get eveyrthing reinstalled and back to new run ;)
<cmatsuoka> great! thanks
<mborzecki> cmatsuoka: thanks for the patch!
<mborzecki> and time to EOD
<cmatsuoka> lunch time for me, bbl
 * zyga tries to get stuff finished 
<zyga> no weekend yet :)
<ijohnson> zyga: could you quick re-review #8365 ? it would be great to get that in today
<mup> PR #8365: seed: add Info() method for seed.Snap <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8365>
<zyga> sure
<ijohnson> thanks!
<zyga> +1
<zyga> but red on travis :/
<ijohnson> yeah needs some travis wrangling
<zyga> mvo: one more suprpsing advantage of github actions - virtually no time limit
<zyga> mvo: jobs can run up to 72 hours IIRC
<ijohnson> wow that's both awesome and a bit scary
<mvo> zyga: woah
<zyga> mvo: ? :-)
<zyga> ah
<zyga> ;D
<zyga> yeah
<zyga> it was a surprise to me :)
<zyga> no more 50 minute death
<mvo> zyga: yeah, very cool
<zyga> mvo: have we switched to the key for c20?
<zyga> cmatsuoka: do you know if systemd reads any configuration from EFI?
<zyga> stracing a random busctl tool revealed
<zyga> openat(AT_FDCWD, "/sys/firmware/efi/efivars/SystemdOptions-8cf2644b-4b0b-428f-9387-6d876050dc67", O_RDONLY|O_NOCTTY|O_CLOEXEC) = -1 ENOENT (
<zyga> it would be unfortunate if our secure boot + encryption scheme was foiled by a debug=1 in EFI var somewhere
<cmatsuoka> zyga: mm interesting
<zyga> cmatsuoka: do we measure EFI?
<zyga> xnox: ^ FYI
<zyga> anyway, now you know
 * zyga is back to digging
<cmatsuoka> it's measured, I believe
<xnox> zyga:  why are you pinging me?
<zyga> xnox: sorry, you are someone who I associate with systemd knowledge
<xnox> zyga:  but what is your ping? it has no context, and no questions =)
<zyga> ah, sorry
<xnox> zyga:  just because i idle in the channel, i don't actually read it =)
<zyga> xnox: the question is this, is there any EFI variable that could, unmeasured, defeat the encryption in core 20
<xnox> i just camp out for pings
<zyga> e.g. something that could give you systemd debug shell
<xnox> zyga:  nothing to do with me, is it?
<zyga> or similar
<xnox> debug-shell.service will not start, if measurements are bad
<zyga> that's reassuring
<ijohnson> xnox: also didn't you just disable debug-shell entirely unless dangerous is on the cmdline ?
<zyga> thanks, I just bumped into this in a strace
<zyga> and was surprised
<xnox> EFI firmware is measured, but currently is not part of the sealing policy => ask security about that
<xnox> (i.e. we don't seal to it)
<xnox> ijohnson:  yes
<ijohnson> right
<xnox> and we do seal keys to the cmdline measurement
<zyga> right, I remember cmdline
<zyga> I was worried that EFI is a hidden 'cmdline' that's not measured somehow
<zyga> (EFI == EFI variables)
<mvo> zyga: I'm not sure what c20 is? uc20? and what key?
<zyga> core 20
<zyga> mvo: the signing key for the kernel
<mvo> zyga: aha, not yet
<mvo> zyga: do you know what broken seed pawel was using?
<zyga> yes I do
<mvo> zyga: for bug https://bugs.launchpad.net/snapd/+bug/1868706
<mup> Bug #1868706: Snapd postinst script hangs <snapd:Triaged> <dpkg (Ubuntu):Invalid> <systemd (Ubuntu):Invalid> <https://launchpad.net/bugs/1868706>
<zyga> mine :)
<mvo> zyga: nice, can you mail/make this available?
<mvo> zyga: trying to write a regression test right now
<zyga> can I TG it?
<mvo> sure
<zyga> it's 350MB tarball
<mvo> whatever works for you
<zyga> and it's already on telegeram
<mvo> *cough*
<zyga> done
<zyga> check your TG please
<mvo> zyga: and I just unpack it over the existing /var/lib/snapd/seed ?
<zyga> enjoy :)
<zyga> I think so
<zyga> stop snapd
<zyga> stash your seed
<zyga> unpack this
<zyga> and marvel at the bugs
<mvo> zyga: nice
<mvo> zyga: if you have a system in that state, what do you see in snap changes?
<zyga> (I would not overwrite your current seed)
<zyga> no, I don't
<mvo> zyga: do you actually see a failed seeding change?
<zyga> I fixed it long ago :/
<mvo> zyga: ok, no worries
<zyga> you see an endless list of seeding things
<zyga> I forgot, pawel fixed that
<zyga> but the broken seed was still, at the time, not allowing snapd do do anything else
<zyga> is there a shell set option that would quote strings?
<zyga> like set -x
<zyga> echo " surprise "
<zyga> and see " surprise " back?
<mvo> zyga: hrm, I can't break the right way in my tests it's very annoying
<zyga> did you break it at all?
<zyga> as in did it get to a snapd that's not seeded?
<zyga> remember you need to move your state aside too
<mvo> zyga: working with your state in a vm right now
<mvo> zyga: but what I mean is that I struggle right now with a spread test that breaks it
<mvo> zyga: I can break it but then the change is never in error state, it's very annoying
<zyga> just to be clear: you are trying to reproduce this as a spread test?
<zyga> if it helps you in any way
<mvo> zyga: yes
<zyga> I just discovered a whole new layer of quoting in shell I never knew about
<mvo> zyga: without the need for a 350mb tarfile ideally :)
<zyga> sure
<zyga> do you know why the seed in that tarball is broken?
<mvo> zyga: not yet
<zyga> I could remember wrong
<zyga> but IIRC it was either wrong order
<zyga> or missing base
<zyga> or something like that
<zyga> what happens when you seed with it?
<zyga> what does snapd say?
<zyga> and if I get hit by a bus
<zyga> foo=" surprise "
<zyga> echo "${foo@Q}"
<zyga> (insert appropriate emoji)
<ijohnson> cmatsuoka: so we are entirely blocked on the latest uc20 changes
<ijohnson> none of the uc20 spread tests can pass on travis
<ijohnson> I'm not sure which snap changed recently, but we need to revert something because master will be entirely red until it's fixed
<ijohnson> cc mvo if you're still around
<cmatsuoka> ouch
<mvo> ijohnson: hi
<ijohnson> hey
<mvo> ijohnson: uh, that's sad
<mvo> ijohnson: so all uc20 tests are failing right now?
<ijohnson> I'm looking into it now, and xnox said he's working on it
<mvo> ijohnson: thank you so much
<ijohnson> mvo: yes all uc20 tests fail because we can't get out of the initrd
<ijohnson> so basically the kernel snap is to blame here I guess
<mvo> ijohnson: so the rebuild of the kernel broke things? so our initrmafs-mounts may have changed in a way that broke it?
<ijohnson> mvo: we don't even get to the point where snap-bootstrap runs
<mvo> ijohnson: uh, woah
<ijohnson> mvo: xnox said that there's another kernel cmdline or something that needs to be added due to a newer systemd ?
<mvo> ijohnson: keep me updated, I have dinner and check back
<ijohnson> I'm looking into building with an older ubuntu-core-initramfs instead of what's currently there
<ijohnson> okay so the version of ubuntu-core-initramfs that went into pc-kernel 431 is fine, the problem is when we re-pack the initrd we use the ubuntu-core-initramfs from the archive, which is newer and has the problem
<cmatsuoka> ijohnson: did you see this happening on a local boot?
<ijohnson> cmatsuoka: yes I can reproduce
<ijohnson> if you do like the repack-kernel script from maciej does and use the skeleton of the initramfs from the ubuntu-core-initramfs package that exists right now, you will be broken
<cmatsuoka> mm, so we can use an older version when we repack and we don't need to wait for a fix?
<ijohnson> I am going to try and look into a way to fully extract the skeleton from the kernel snap instead of the using the one from the distro package
<ijohnson> yes an older version of ubuntu-core-initramfs package is what we need to boot with
<cmatsuoka> ok thanks ian
<cmatsuoka> do you need any help/assistance there?
<ijohnson> I'm good for now I think, but thanks for the offer
 * ijohnson also needs to get lunch soon
<mup> PR snapcraft#2996 opened: requirements: uprev mypy to 0.770 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2996>
<mup> Bug #1867090 opened: IBus 1.5.21 Chinese input in Ubuntu 19.10 not working with Atom 1.45.0 as snap <chinese> <Snappy:New> <ibus (Ubuntu):Confirmed> <https://launchpad.net/bugs/1867090>
<mup> Bug #1867090 changed: IBus 1.5.21 Chinese input in Ubuntu 19.10 not working with Atom 1.45.0 as snap <chinese> <ibus (Ubuntu):Confirmed> <https://launchpad.net/bugs/1867090>
 * zyga EOWs
<xnox> ijohnson:  why are you using a different ubuntu-core-initramfs when repacking?
<xnox> (during spread tests)
<ijohnson> xnox: we use the one from the distro package
<ijohnson> I am testing using the one from the kernel snap instead
<xnox> ijohnson:  again, why?
<ijohnson> tbh I don't know why we use the distro skeleton instead of the initrd from the kernel snap, mborzecki would know the details as he last touched that code
<ijohnson> but he already EOD'd
<xnox> ijohnson:  back when we talked about repacking kernel.snap, we did talk about unpacknig kernel.efi, unpacking initrd, upacking initrd, updating anyting one wants to update, and reusing that as the skeleton dir again.
<xnox> ijohnson:  cause otherwise, one is not introducing "just the new snap-bootstrap" one upgrades all the other things too.
<xnox> ijohnson:  plus i only have the one PPA at the moment, so I don't have anywhere else to upload ubuntu-core-initramfs as edge and then promote somewhere else as beta
<ijohnson> xnox yes if the run I have right now works with just replacing snap-bootstrap we will do that
<mup> PR snapd#8372 opened: devicestate: generate warning if seeding fails <Created by mvo5> <https://github.com/snapcore/snapd/pull/8372>
<xnox> ijohnson:  awesome! because that is closer in spirit what you want to do longer term too.
<mup> PR snapd#8373 opened: tests/lib/prepare.sh: use only initrd from the kernel snap <UC20> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8373>
#snappy 2020-03-28
<mup> PR snapcraft#2996 closed: requirements: uprev mypy to 0.770 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2996>
<HiSPeed> hey. is there any way to convince the snappy installer to use /proc/1/mounts instead of the nonexisting /proc/1/ns/mnt ?
<HiSPeed> -> debian 9
<HiSPeed> oh, with snap we re back to rolling out our own custom kernels again.. enterprise-grade upgrading !
<HiSPeed> well wont hold it against you idlers :p
<HiSPeed> later!
<zyga> HiSPeed: hi
<zyga> But those proc files are not the same
<zyga> One is a list of partial information about mount points
<zyga> And the other is a mount namespace
<zyga> You cannot use one for the other
<zyga> Snapd requires mount namespaces to operate
<mup> PR snapd#8340 closed: boot, snap-bootstrap: move initramfs-mounts logic to boot pkg <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8340>
<mup> PR snapd#8340 opened: boot, snap-bootstrap: move initramfs-mounts logic to boot pkg <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8340>
<mup> PR snapcraft#2710 closed: Add setting to remove the "jar" option in the gradle command <Created by LyzardKing> <Closed by LyzardKing> <https://github.com/snapcore/snapcraft/pull/2710>
<mup> PR snapcraft#2991 closed: yaml_utils: don't sort keys when dumping <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2991>
#snappy 2020-03-29
<thresh> hi.  clicking "jack1" from https://snapcraft.io/docs/supported-interfaces leads to https://snapcraft.io/t/the-jack1-interface/13093, which is 404.
<thresh> where can I read about what is that interface about?
<thresh> same 404 from "network-manager-observe" -> https://snapcraft.io/t/the-network-manager-observe-interface/13096
<Lukewh> thresh: try searching in the docs section on https://forum.snapcraft.io. the docs are generated from there
<thresh> thanks Lukewh
<thresh> since https://snapcraft.io/docs/personal-files-interface says it requires snapd 2.37+, how can I check for snapd version in the wrapper script that launches my app?
<Lukewh> thresh, I'm not sure whether or not the version of snapd is available. check https://snapcraft.io/docs/environment-variables, specifically the bit about running env in the snaps environment
<thresh> Lukewh, well, I have tried snap run --shell $myproject, and then env| grep -i snap
<thresh> hence why I asked
