#snappy 2015-10-19
<dholbach> good morning
<clobrano> buongiorno all :)
<dholbach> hey mvo, who do I ping about Snappy Personal?
<dholbach> tedg, looks like snapcraft builds currently fail: https://code.launchpad.net/~snappy-dev/+recipe/snapcraft-daily
<mvo> dholbach: seb128 probably, not sure who else is wokring on this
<seb128> not me, I worked on the image back then but it was lower in priority and I basically moved back to other things
<dholbach> seb128, do you know who I could ping? willcooke and kgunn maybe?
<seb128> lol
<seb128> trying to make that fallback on me forced through managers? ;-)
<dholbach> no
<seb128> that image is just unmaintained atm
<dholbach> I would just like to know who is working on it and what the state of things is
<dholbach> a quick answer is really enough
<seb128> but talk to kgunn if you think it should have more resources assigned
<seb128> nobody is
<dholbach> I wasn't after "hey, somebody fix my X, Y and Z issue" :)
<dholbach> I'll ping Kevin later on
<dholbach> thanks
<seb128> that's basically what I said, it was lowered in priority and resources moved away afaik
<dholbach> seb128, it's just a question I'd like to have answered for a presentation on the weekend
<dholbach> ok
<seb128> let me know what kevin says
<dholbach> will do
<dholbach> thanks
 * dholbach relocates to the office, brb
<clobrano> Hi Chipaca, I wouldn't be pedantic, but any news about Bug #1496319 and udev rules? :)
<ubottu> bug 1496319 in Snappy "Could not create symlink to hw device with udev rules" [Undecided,New] https://launchpad.net/bugs/1496319
<seb128> you guys are aware that https://launchpad.net/ubuntu/+source/ubuntu-snappy/1.6ubuntu1 didn't migrate out of wily-proposed because it fails to build?
<JamesTait> Good morning all; happy Monday, and happy Clean Your Virtual Desktop Day! ð
<mvo> ogra_: hi, I accidently triggered your initird partition resize in one of my image on wily, I get "parted: invalid option -- '1' in resize-writable.log. the image may be older, just wanted to let you know
<ogra_> mvo, hmm
<ogra_> do you know how you actually triggered that ?
<seb128> mvo, ogra_, did you see that ubuntu-snappy is still on 1.5 in wily because 1.6 fails to build?
<seb128> unsure if that's something you want to fix before release
<ogra_> "release" heh
<ogra_> but yeah ... for the devs that use wily desktops that probably makes sense :)
<mvo> ogra_: I removed system-a and system-b
<mvo> :P
<ogra_> mvo, ah, so a typical usecase then :)
<mvo> ogra_: *cough*
<mvo> ogra_: this why I said "fyi"
<ogra_> did you leave writable intact ?
<mvo> ogra_: it may become one, this is a system booting from a kernel snap
<mvo> ogra_: I did, I wanted to double check if my system keeps booting just from kernel/os snap and the resize was a bit of a unexpected thing (a nice one though)
<mvo> ogra_: but like I said, could be a much older image
<ogra_> there might be a check missing
<ogra_> (i think the findfs runs only after the free space check and there might be nothing checking if it actually returned something
<ogra_> )
<mvo> ogra_: oh, fun - so something returns "-1" for size and parted assumes its a parameter :) ?
<ogra_> yeah, something like that .... i'll have to check the code, just a theory
<mvo> ok, not important, like I said, not relevant now, but might be a nice feature for 15.04->16.04 upgrades that your script can reclaim the space
<ogra_> ah, no. wait-for-root for "writable" and findfs run first
<ogra_> so it isnt that
<Chipaca> clobrano: that's not what "pedantic" means. And if it were my bug, I would've had less patience than you :)
<Chipaca> good morning all
<Chipaca> mvo: are we on github yet?
<Chipaca> JamesTait: I am starting to suspect you're making up these Days
<JamesTait> Chipaca, it's also Evaluate Your Life Day....
<Chipaca> dammit
<mvo> Chipaca: I asked to wait 1 week, i.e. do the release with LLP
<Chipaca> mvo: ahh, i missed that
<Chipaca> mvo: that is entirely sensible! thanks
<davmor2> Chipaca: on a plus side it did trigger this as my tune for JamesTait day https://www.youtube.com/watch?v=WUOtCLOXgm8
<Chipaca> i'm going to need bigger speakers
<davmor2> Chipaca: virtual cleaning, with virtual woman, in a virtual environment, it was as close to virtual desktop as I could get :)
<ogra_> panic: can not set option description for "package name"
<ogra_> ...
<ogra_> FAIL	launchpad.net/snappy/cmd/snappy	0.022s
<ogra_> mvo, Chipaca ^^^ thats the ubuntu-snapy FTBFS
<ogra_> (in wily)
<Chipaca> ogra_: noice
<ogra_> https://launchpadlibrarian.net/218629818/buildlog_ubuntu-wily-amd64.ubuntu-snappy_1.6ubuntu1_BUILDING.txt.gz
<mvo> ogra_: thanks
<ogra_> same failure on all arches but powerpc
<Chipaca> interestingly, doing bzr-builddeb locally gives me a different ftbfs :)
<Chipaca> bah. There's the same one also.
<Chipaca> src/launchpad.net/snappy/daemon/daemon_test.go:87: d.router.Walk undefined (type *mux.Router has no field or method Walk)
 * Chipaca pokes
<mvo> Chipaca: the way we set the options is different between different version of flags
<ogra_> this build is old ...
<mvo> Chipaca: for the other one you need a updated version of mux, its in the image ppa
<ogra_> so could well be that another FTBFS joined the party over time
<Chipaca> ah
<mvo> Chipaca: I wonder why its failing now, can't rmember changing the goflags code or the goflags package
<Chipaca> ah, schroot builddeb has the ppa set up already, going with that one
<Chipaca> sergiusens: mo'in!
<Chipaca> mvo: got the same error in schroot. Also an error in one of the helper tests...
<mvo> Chipaca: could you pastebin the other error please?
<Chipaca> http://pastebin.ubuntu.com/12859201/
<mvo> Chipaca: heh, ok. that looks a lot like sbuild being special
<Chipaca> mvo: oh yeah :)
<Chipaca> probably need a .Skip() there
<sergiusens> Chipaca, morning
<Chipaca> sergiusens: you already answered a bit in the branch, but: would it be ok for u-d-f to use snapd?
<Chipaca> directly, that is
<Chipaca> or would you need a client library
<sergiusens> Chipaca, only if snapd has SetArch or  similar
<sergiusens> Chipaca, and ExtractSnap for the gadget as that has all the information on how to setup partitions, which snaps to bring in, etc
<Chipaca> ExtractSnap?
<sergiusens> Chipaca, this is where everything breaks btw. As this snapd on the host would need to support 15.04 and rolling builds
<dholbach> hey sergiusens
<Chipaca> sergiusens: not necessarily
<sergiusens> Chipaca, right now we do 'snappy.Install' to a fake location
<Chipaca> sergiusens: need to think about it a bit, but, you can have multiple snapds and only one rest client, and things should work
<Chipaca> we'd need to have tests to that effect though
<dholbach> sergiusens, shall we talk through the clinic later on? or are we good to go? I think I'd just snappify something simple like ddate, do the introductions and relay questions if that's all right.
<Chipaca> there isn't a set architecture, and there isn't a way to setrootdir to have an install work, but they should be easy to add as cmdline args
<sergiusens> dholbach, for the last step?
<dholbach> sergiusens, we can do more if you like
<sergiusens> Chipaca, right, I think we need to have more than an irc discussion to get this going. I need to order my brain on all the permutations that we need to cover
<sergiusens> dholbach, I thought tedg was preparing something with cmake
<sergiusens> dholbach, I do have a cmake/plugin override example in the works
<dholbach> sergiusens, ok cool - I'll leave the example around, just in case
<Chipaca> sergiusens: sprint at mvo's, the last week of october \o/
<Chipaca> sergiusens: ie next week
<Chipaca> 2015/10/19 11:26:18.407658 common.go:45: PANIC can not set option description for "package name"
<Chipaca> mvo: ^ that is output in a *successful* test run
<Chipaca> mvo: so it's a red herring
<ogra_> Chipaca, nah, at dholbach's, then yoiu guys cal also come to ubucon ;)
<Chipaca> i'll disable log in that panic-checking test
<ogra_> *can
<Chipaca> ogra_: +1
<Chipaca> aren't they, like, neighbours?
<sergiusens> Chipaca, next week is too soon to get a good fare ;-)
<dholbach> sergiusens, or do ddate in a bit more detail, then quickly explain how fatcat is done (although that's probably not the best example as we have to have it ship its own libstdc++6) - not sure... what do you think?
<Chipaca> sergiusens: no no; fares dip this soon before
<ogra_> Chipaca, for american standards perhaps :)
 * Chipaca remembers travelling 1Mm for an asado
<sergiusens> dholbach, well if you do it from vivid no need to ship it :-P
<mvo> Chipaca: yeah, the output is confusing its testing that its panicing if it can't find the option
<ogra_> (but then under that standard berlin lies next to paris too :) )
<sergiusens> dholbach, but I see your point
<dholbach> sergiusens, I'm happy either way - it might generally illustrate how to do and when to consider it
<Chipaca> mvo: https://code.launchpad.net/~chipaca/snappy/skip-homedir-no-schroot/+merge/274870
<Chipaca> mvo: 1. skip that test in schroot; 2. turn off logs in that panic test
<mvo> Chipaca: \o/
<sergiusens> Chipaca, btw, did you see my messages from Friday about the megaMR and docopt?
<Chipaca> sergiusens: megaMR?
<Chipaca> sergiusens: wrt docopt, you linked me to docopt.go, is that the one you mean? otherwis eno
<sergiusens> Chipaca, mega MR https://code.launchpad.net/~sergiusens/snapcraft/cleanup/+merge/274801
<sergiusens> Chipaca, and docopt, it looks really nice but there is no i18n support (dev allude that all cli's are in English) and implementing subcommands is rather ugly
<sergiusens> Chipaca, ugly as in the subcommand does a subprocess.call on a subcommand
<sergiusens> Chipaca, e.g.; https://github.com/docopt/docopt/blob/master/examples/git/git.py
<Chipaca> sergiusens: after pointing you at it i wondered about how/whether they'd support subcommands modularly
<sergiusens> Chipaca, after seeing the presentation I really wanted that one to be the one (would of been a prince charming Disney story if so) :-)
<ogra_> mvo, hmm, looking at your initramfs-tools MP ... why the insmod ? mount should properly triger a modprobe event here
<mvo> ogra_: I don't know why, sorry, it did not figure it out automatically for me, but I can re-test and see if it was a one-time fluke
<ogra_> thats surely a bug if it doesnt ...
<ogra_> mvo,  if we cant get the kernel fixed we should add squashfs to the initramfs config instead of calling insmod though
<sergiusens> Chipaca, I like this one, name clash and all, it is calling you http://click.pocoo.org/5/
<mvo> ogra_: let me try again
<Chipaca> sergiusens: ugh. the "i just discovered decoraters they are the best!!1!one!" library
<mvo> lol
<sergiusens> Chipaca, then there's https://github.com/zyga/guacamole ;-) (the syntax is a bit more complicated but is the same without decorators)
<ogra_> mvo, also: http://paste.ubuntu.com/12859786/
<ogra_> (not sure about loop, might be compiled int nowadays .... )
<ogra_> ah, yeah, loop is builtin
<mvo> ogra_: it looks like I don't need it anymore, I removed the insmod and it seems to be still happy. thanks for the diff, I addd it now
<ogra_> mvo, yeah, drop the loop line though (got that from casper)
<mvo> ta
<ogra_> mvo, also in line 80 (root="LABEL=writable") you might want to use $writable_label instead of hardcoding the name (you use $writable_mnt in that function too, so it would be good to have all in variables)
<mvo> ogra_: excellent suggesitons, thanks, will fix right after lunch
<Chipaca> mvo: any idea why golint is suddenly mad at my branch? what changed in tarmac?
<ogra_> mvo, beyond that, the code looks fine to me, will approve then ;)
<ogra_> (indeed assuming it actually works :) )
<mvo> ogra_: heh :) it does for me, but I will double check after lunch again
<ogra_> i'll keep staring at it a bit, probably i find other nitpicks :)
<ogra_> oh
<ogra_> mount --move "$writable_mnt" "${rootmnt}/writable"
<Chipaca> mvo: wrt lint, seems an updated golint is what happened
<ogra_> with the new way "$writable_mnt" is "${rootmnt}" already ... not sure this line is clever
<ogra_> (movind ourselves one level down ... )
<ogra_> ah, no ignore that ... but there is something wonky here
 * ogra_ will breed over it 
<ogra_> hmm, we are essentially pullin out the carpet underneath ourselves with that line
<Chipaca> mvo: updated the branch to pass lint again, care to give it a once-over?
<Chipaca> sergiusens: wrt snapd and u-d-f, what i'm thinking is of making it easy for u-d-f to start snapd using systemd-activate and talking to it over a pipe or whatever is simplest in that scenario
<sergiusens> Chipaca, and snapd will run fine on ubuntu classic?
<Chipaca> sergiusens: today now, because there isn't a way to setrootdir
<Chipaca> s/now/no/
<Chipaca> sergiusens: but that's why i'm asking what's needed :)
<sergiusens> Chipaca, right, if it runs fine in ubuntu classic and you don't forget to push the debs to tools-proposed, it's all going to be good
<sergiusens> Chipaca, given all snaps, I don't know anymore
<Chipaca> sergiusens: sounds like setrootdir, set arch, and a way to make apps not be sideloaded
<Chipaca> s/apps/snaps/
<sergiusens> Chipaca, but if we forget about all snaps, install to alternate locations, inhibit hooks, set the release to query the store
<sergiusens> Chipaca, apps coming from the store should not be marked as sideloaded though
<sergiusens> Chipaca, I think that is an introduced bug
<sergiusens> recent one
<sergiusens> Chipaca, but yay, origin
<Chipaca> ah, of course, you don't sideload them, you tell snappy to install them (or do actually sideload, in which case you *want* them to be sideloaded)
<sergiusens> Chipaca, they shouldn't be sideloaded, right,because of what you just said ;-)
<Chipaca> sergiusens: apps coming from the store aren't marked as sideloaded. If you've found a case when that happens, drop everything and let me know :)
<dholbach> sergiusens, tedg: I filed https://bugs.launchpad.net/snapcraft/+bug/1507573
<ubottu> Launchpad bug 1507573 in Snapcraft "AttributeError: 'module' object has no attribute 'tests'" [Undecided,New]
<sergiusens> dholbach, I was going to ask you what the heck that meant as bzr bd works just fine
<dholbach> sergiusens, let me see if I can reproduce it
<sergiusens> dholbach, this is probably related to the test_suite='snapcraft.tests' line I added to setup.py
<dholbach> sergiusens, try with and without python3-autopilot
<dholbach> that might be the issue
<dholbach> yep
<dholbach> https://code.launchpad.net/~dholbach/snapcraft/1507573/+merge/274889
<tedg> sergiusens: dholbach: I finally got my ginac example working last night, but it required a fix, and ended up being autotools.
<dholbach> tedg, cool - are you going to present it later on?
<tedg> dholbach: At the clinic, right?
<dholbach> yeah
<jdstrand> mvo: hi! ping re snappy-debug
<Chipaca> jdstrand: hi! ping re killing click-apparmor with fire :-p
<mvo> jdstrand: uh, sorry, we plan a new snappy release for end of this week, I got a bit distracted because of this
<jdstrand> Chipaca: I think I mentioned I would very much appreciate help with that ;)
<jdstrand> Chipaca: but yes, it is definitely something we need to do
<jdstrand> unfortunately, higher priority items keep getting added to our plate that trump that one
<Chipaca> jdstrand: ok, here's the thing: i wouldn't know where to start :-/
<jdstrand> mvo: I'm not sure what you are communicating. do you want me to remove valgrind, fix up the packaging and upload?
<mvo> jdstrand: if you could do that, that would rock, sorry for being not clear, I just tried to say that I had not had time to work on this yet :/
<jdstrand> mvo: I'm wondering if I should just upload it without gdb, etc since it would be nice if this was available on arm
<mvo> jdstrand: +1
<mvo> jdstrand: and we add the other bits later
<sergiusens> dholbach, why would I want python3-autopilot? Do we use anything from that at all?
<balloons_> dholbach, perhaps we should broach the topic in here instead with the rest of the team.
<dholbach> sergiusens, i don't know
<sergiusens> dholbach, lol, it does not make sense :-)
<dholbach> sergiusens, it makes it work :)
<sergiusens> dholbach, right, I don't have anything autopilot locally here
<dholbach> then one of its deps?
<jdstrand> mvo: ok, I'll just do that then
<sergiusens> dholbach, oh, maybe testutils
<dholbach> aha?
<dholbach> sergiusens, I'll investigate
<sergiusens> dholbach, http://trac.10920.n7.nabble.com/Can-t-run-the-unit-tests-ImportError-No-module-named-tests-td31160.html
<sergiusens> maybe that
<jdstrand> mvo: ok, I created https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-debug
<jdstrand> mvo: that has what is in the store. I will now remove the non snappy-security bits, commit and upload to the store. that way, it'll be easy to revert and pick up later
<tedg> sergiusens: Can you look at this before the clinic today? https://code.launchpad.net/~ted/snapcraft/autoreconf/+merge/274893
<tedg> sergiusens: Bugs found in making the demo :-)
<sergiusens> tedg, you can add build packages to the yaml itself, but sure lets look at this
<mvo> jdstrand: \o/
<tedg> sergiusens: Oh, I thought that was only for plugins.
<sergiusens> tedg, I guess all or mostly all of the autotools based projects will use libtools, not sure about bison
<tedg> sergiusens: Yeah, makes sense. Let me refactor.
<sergiusens> tedg, in trunk I think build-packages can even go into the part (instead of top level snapcraft.yaml)
<tedg> sergiusens: Yup, verifying by building now.
<tedg> sergiusens: So this looks a little weird, I mean libfoo-dev seems like it shoudl be a "build-package" but yet, that doesn't seem like what we want.
<tedg> sergiusens: Curious if it should be "host-packages" or something.
<tedg> sergiusens: Or handle build packages by installing them onces, but stage-packages twice. So then you only get some into stage
<sergiusens> tedg, I see your point and yes it is confusing if you come from debian/control
<sergiusens> tedg, I think of it as build-package just drives the build
<sergiusens> tedg, stage-packages is anything you want in the part/snap (a -dev will bring in the lib which you would want).
<tedg> sergiusens: Yeah, I think it would be nice though, just to make the snap smaller.
<sergiusens> but certainly confusing
<sergiusens> I worked around my line of thinking to get used to it
<tedg> sergiusens: The current build-packages sucks because if you're using a different distro version from the host it won't work.
<sergiusens> tedg, and no fileset usage I bet ;-)
<jdstrand> oh noes
<jdstrand> how does one recover from this: http://paste.ubuntu.com/12861487/
<jdstrand> this is on a bbb
<mvo> jdstrand: uh, sorry - this is a transient bug
<mvo> jdstrand: you need to manually rename the full named kernels in /boot/uboot/{a,b}/  to the short (vmlinuz) name
<mvo> jdstrand: same for initrd
<jdstrand> mvo: this is then fixed after this upgrade?
<tedg> sergiusens: bison dropped
<dholbach> sergiusens, https://code.launchpad.net/~dholbach/snapcraft/1507573/+merge/274889 updated
<mvo> jdstrand: yes, its a version of snappy that gets this wrong
<ogra_> tedg, if you drop bisons you have to add wombats ... thats an old rule :)
<jdstrand> erf
<jdstrand> I got past that, now:
<jdstrand> error from system-image-cli: [Errno 2] No such file or directory: '/etc/system-image/archive-master.tar.xz'
 * jdstrand copies from /writable/cache/system/etc/system-image/
<tedg> ogra_: Are you using the Alix board as a router and then putting a WAP on the other side?
<doctorSnappy> oh, 1h early
 * doctorSnappy i'm not a real doctor
<cmk> any1 online?
<sergiusens> tedg, added  comment to your MP
<vmayoral> sergiusens: morning, we've tested what we discussed last week
<sergiusens> vmayoral, sdcard?
<sergiusens> vmayoral, how did it go?
<vmayoral> sergiusens: pretty much the same, no big changes
<sergiusens> vmayoral, have you tried disconnecting everything from the usb bus as well?
<vmayoral> yes, boot time reduces a bit ~15 seconds but the "snappy info" command takes the same
<vmayoral> the issue that we saw with the autopilot (for the drones) remains active
<sergiusens> vmayoral, so even disconnecting everything from the bus (wifi, vide camera, etc) has no impact?
 * sergiusens invokes ogra
<vmayoral> sergiusens: yes, tests have been made with only Erle-Brain 2 (RPi2 + shield with power electronics for actuators)
<sergiusens> vmayoral, what about just the rpi2 with no shield?
<sergiusens> dholbach, I have bad news, my network connection seems to be degrading
<vmayoral> sergiusens: haven't tried that but i doubt that's the issue since Debian FS works perfectly with the shield
<sergiusens> dholbach, I'll keep you posted
<dholbach> thanks sergiusens
<ogra_> vmayoral, snappy info takes long for you ?
<tedg> sergiusens: Done. bug 1507648
<ubottu> bug 1507648 in Snapcraft "Autotools doesn't work without autogen.sh" [Undecided,New] https://launchpad.net/bugs/1507648
<vmayoral> ogra_: in the tests, the first time it took 16 seconds, following attempts about 4 seconds each
<elopio> I'm going to upgrade my openwrt.
<elopio> I might be away for a month. Wish me luck.
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ time snappy info|grep real
<ogra_> real    0m0.495s
<ogra_> this is on an unmodified snappy RPi2 image
<Guest42341> QUESTION: Can i have my private snappy app store?
<ogra_> so it must be related to some changes you make
<sergiusens> Guest42341, you are early
<Guest42341> oh, thanks sergiusens
<Guest42341> :))
<Guest42341> how much early?
<sergiusens> Guest42341, 40'
 * sergiusens restarts router again
<Guest42341> phew
<ogra_> vmayoral, can you prefix the snappy info with "time" like i did above, so we can see if it is slow in user or sys time (sys would actually point to IO)
<cmk> how to install apps on snappy personal desktop so that they appear in the UX/appbar?
 * ogra_ doubts you can yet 
<vmayoral> ogra_: can't put time into it now but will do. Ehat really concerns me is the issue with the autopilot binary in the Snappy FS
<ogra_> personal is also not a project atm ... that image build was a one-off test thing
<ogra_> vmayoral, well, the snappy fs isnt slow as you can see above ...
<ogra_> so there must be something with your changes that snappy doesnt get along with
<vmayoral> ogra_: not saying it's Snappy, probably we're doing something wrong
<ogra_> well, or snappy is
<ogra_> :)
<ogra_> the point is that a default snappy isntall flies (oh the pun) on RPi
<Chipaca> ok, i've got to go out for a bit, will bbl
<vmayoral> ogra_: what really confuses me is that the same config produces a kernel on De
<shuduo> i am tring to install mir.mvp-demo on a snappy instance from virtual machine but it always fails with "something went wrong :(". can anyone confirm it's expected or not?
<vmayoral> *produces a kernel that works perfectly in Debian and gets issues in Snappy
<vmayoral> t
<ogra_> vmayoral, well, you cant really compare the two
<shuduo> actually i'm trying to reproduce running qt snap application on snappy personal.
<ogra_> different userspace ... kernel options might be missing between them etc
<ogra_> kgunn, can you help shuduo ?
<ogra_> is the Mir snap supposed to work ?
<tedg> shuduo: I don't think the mir snap will work on personal.
<tedg> Personal I believe has Mir bundled into the core.
<shuduo> tedg, ogra_, kgunn, i refer to a doc "Snappy GUI Anyone?" but it's out of date. but it says mir snap works with virtual machine.
 * Guest42341 live in 25 min
<kgunn> shuduo: virtual machine of ubuntu core (not personal)
<kgunn> shuduo: ubuntu personal image has not had the work/attention to support snap as a mir client download/installation
<jdstrand> mvo: fyi, bbb is back in action
<kgunn> shuduo: fwiw, i can confirm the mir.mvp-demo installs/runs fine on ubuntu core in vm or booted from thumb drive even
<jdstrand> mvo: so, snappy-debug was set as a framework. is this so one doesn't have to type 'snappy-debug-snappy-security'?
<kgunn> problem is currently the running of the mir client snaps (on top of  that)
<shuduo> kgunn: hmm, i managed to run a recompiled mir snap on qemu now. but failed with virtualbox
<jdstrand> mvo: wouldn't an alias in the store do the same thing?
<kgunn> shuduo: i can only speak to the vm i used
<jdstrand> mvo: or am I misremembering that point?
 * kgunn gets on the phone so responses will be slower
<mvo> jdstrand: yes, just for that, just for the short names to work
<jdstrand> mvo: I really don't like this being a framework-- it isn't. there are no services, no framework-policy, no apps will consume it
<mvo> jdstrand: a alias will mean you need to type "snappy-debug.strace" which is probably a good thing
<mvo> jdstrand: yeah, I agree
<shuduo> kgunn: i'm curious what vm you are using. can you see graphics screen show up with a big mouse cursor?
<jdstrand> mvo: ok, so I'll remove the framework bit. maybe some thought needs to be put around something that is an app but with binaries with short name? I'm not sure. it is easy to commit to thinking about it though :)
<kgunn> shuduo: virtual machine manager which can download from the sw store
<kgunn> https://virt-manager.org/
<kgunn> and yes, i can see the big mouse cursor
<shuduo> kgunn: yes, i'm using vmm now and i can see graphic screen with a mouse cursor
<mvo> jdstrand: :)
<kgunn> shuduo: right, and there is a problem with running of mir client on that demo do some install pathing changes i believe
<kgunn> and tbh, i am thinking we need to move our effort over to snapcraft
<shuduo> kgunn: let me try install mir.mvp-demo again. i'm trying to reproduce what Darren Landoll did as he said he managed to make QT app snap working with snappy personal
 * ogra_ points out again that there is no actuallyy snappy personal image ... it was an experimental proof of concept thing to prove it can be built 
<ogra_> *no actual
<dholbach> we are going to start the broadcast on ubuntuonair.com in about 10 mins
<genii> dholbach: Do you have an URL for that?
<dholbach> genii, http://ubuntuonair.com :)
<genii> Heh, OK
<cmk> https://youtu.be/0Ma4Wvppzcs
<dholbach> does the video work? everything working fine so far?
<jeffesquivels> dholbach: yes
<dholbach> if you have questions, please prefix them with QUESTION:
<dholbach> so we can more easily pick them up :)
<shuduo> kgunn: i installed a fresh new instance on vm. it still got failure on install mir from store as before. i wonder the command line 'snappy install mir' output 'package not found' even it can be search out.
<fgimenez> nice evening everyone o/
<dholbach> any questions so far?
<tedg> http://www.ginac.de/
<Rlyeh> QUESTION:Do plugins shipped with snapcraft or we can make it ourselfs?
<ogra_> Rlyeh, you can indeed create your own like sergiusens just demonstarated
<ogra_> *demonstrated
<dockydo> you have an error
<Rlyeh> Thanks, i have some delay, sorry
<dholbach> no worries :)
<dholbach> we'll answer it on the hangout in a sec as well, just to be sure
<ogra_> QUESTION: why do you need -dev packages for runtime deps ?
<Rlyeh> QUESTION:would you please describe how to define architecture? I defined "armhf", but the package built for amd64(my pc)
<shuduo> kgunn: sorry install mir.mvp-demo can be processed. pls ignore prev msg
<kgunn> QUESTION: so with the stage packages, when you pull, you only need to call out the first level of dependencies? it'll grab all the sub-deps...
<kgunn> ?
<tedg> http://paste.ubuntu.com/12862605/
<kgunn> (sorry i may be laggy)
<LarreaMikel> QUESTION: If I undestand well, to build snaps for rp2, you have to develop them on the rp2?
<ogra_> LarreaMikel, you have to develop them on armhf
<ogra_> LarreaMikel, that can as well be a qemu-static-arm chroot (built via qemu-deboostrap) on your PC ... sadly that doesnt work for all languages (i.e. go and .net wouldnt work) which is why we cant make a wrapper as default thing for it
<LarreaMikel> ogra_ thanks ;)
<mattyw> LarreaMikel, if you use go you can cross compile out of the box
<mattyw> more or less
<ogra_> well, snapcraft doesnt support it
<ogra_> as sergio just explains :)
<dockydo> what does EINFUGEN means?
<ogra_> INSERT
<ogra_> :)
<dockydo> thanks :D
<dholbach> sorry
<dholbach> I hit the wrong button
<dockydo> np
<dockydo> is really over?
<LarreaMikel> QUESTION: If you do "snap run" on the rp2, it tries also to run on an emulator?
<tedg> dockydo: Just a sec, dholbach hit the wrong button.
 * ogra_ expects them to come back :)
<sergiusens> dockydo, no, technical issues with hangouts
<dholbach> sorry
<dockydo> np :))
<sergiusens> will come back in a minutes
<sergiusens> minute
<ogra_> LarreaMikel, you mean snapcraft run ?
<dockydo> ok them, time to check for ota7
<sergiusens> LarreaMikel, I'll answer that one in the hangout ;-)
<LarreaMikel> ogra_: yes, sorry
<ogra_> (it might try to, havent checked :) )
<ogra_> dockydo, the phone will notify you anyway ;)
<dockydo> ogra_: i know but it can't help myself :))
<ogra_> haha
<dholbach> sorry, we're back on https://ubuntuonair.com/ now
<dholbach> http://www.youtube.com/watch?v=a0yK8ZeYcZg
<ogra_> popey, ^^^ we need to put some tetris into the check for updates dialog on the phone ;)
<dholbach> you might have toload the ubuntuonair.com page
<dockydo> that would be nice :))
 * ogra_ reloads
<ogra_> "Starting soon..."
<ogra_> someone take away these buttons from dholbach !
<dockydo1> snappy remove buttons
<dholbach> :-)
<dockydo1> any plans for ubuntu home routers? (i'll buy 3)
<ogra_> sergiusens, you can do it in a chroot easily (install snapcraft on rpi snappy)
<ogra_> dockydo1, jdstrand has an experimental ufw snap already ... so you should eb able to easily build one
<elopio> dockydo1: +1 or 2 here.
<dockydo1> ogra_: first i have to figure it out how to install ubuntu snappy on my router :D
<ogra_> dockydo1, http://pcengines.ch/ i like to use these for servers and routers etc
<dholbach> developer.ubuntu.com/snappy/
<dholbach> developer.ubuntu.com/snappy/snapcraft/
<ogra_> i have one here running snappy realyl happily
<dockydo1> thanks ogra_
<ogra_> (the ALIX boards/systems)
<dholbach> any more questions so far? :)
<LarreaMikel> QUESTION: Maybe this is a silly question, but what will be the proper way to develop with snapcraft for the rp2? I mean, to develop and install the snap in the rp2?
<nullagent__> QUESTION: which day was the ROS workshop?
<dholbach> thanks a bunch everyone!
<Rlyeh> QUESTION: Is it possible to write apps in c++?
<sergiusens> LarreaMikel, hey, I'm just noticing your question, not sure it was answered, was it?
<dholbach> nullagent__, we'll send out an email on the list about it and on the @ubuntudev social media accounts
<dholbach> Rlyeh, sure
<sergiusens> Rlyeh, what tedg demo'd was a c++ app
<elopio> thank you.
<tedg> nullagent__: Roughly two weeks
<sergiusens> nullagent__, eagerly wait for the announcement from dholbach ;-)
<dholbach> Rlyeh, you can use whatever's in Ubuntu - no matter if it's python or c++, go or java or anything else
<nullagent__> Awesome thanks, using an overly complicated approach for ROS today can't wait to see what you guys came up with
<Rlyeh> I think i missed it, I have to review the video, Thank you all, very useful
<LarreaMikel> sergiusens: if you have answered it, i didn't realize... sorry
<dholbach> and sign up for the mailing list here: https://lists.ubuntu.com/mailman/listinfo/snappy-app-devel
<dholbach> it's low-traffic and you should be able to get answers for your questions there
<ogra_> thanks guys !!!
<dholbach> and sorry about me pressing the wrong button
<dholbach>  /o\
<ogra_> boys and buttons ... :)
<popey> ogra_: I certainly believe we need more easter eggs in the phone :)
<ogra_> :)
<jdstrand> mvo: fyi, ok, see email on snappy-debug (both in the thread and on snappy-app-devel). I also filed https://bugs.launchpad.net/snappy/+bug/1507693 for adding the removed tools back. I did a preliminary triage; please reassign/adjust as necessary
<ubottu> Launchpad bug 1507693 in Snappy "please add gdb, strace, ltrace, etc to snappy-debug" [High,Triaged]
<dholbach> all right my friends - I call it a day - see you all tomorrow! :)
<mvo> thanks jdstrand
<sergiusens> elopio, any chance in looking at https://code.launchpad.net/~sergiusens/snapcraft/cleanup/+merge/274801
<elopio> sergiusens: sure.
<sergiusens> Chipaca, can you check if the two latest commits to https://code.launchpad.net/~sergiusens/snapcraft/cleanup/+merge/274801 satisfy your comments please?
<sergiusens> elopio, hey, when you say hard to ready
<sergiusens> elopio, is it the one liner or the longer paragraph?
<sergiusens> elopio, your text proposal does not fit one line btw ;-)
<elopio> it's the one liner.
<elopio> I mean, it's to replace the one liner + the paragraph for just one line.
<elopio> sergiusens: yes, what you pushed seems nice to me.
<sergiusens> elopio, I edited to make it fit thought ;-)
<sergiusens> elopio, if it is ok, a +1 would be great ;-)
<elopio> sergiusens: I +1'ed 25 minutes ago
<sergiusens> elopio, I didn't get the email :-) sorry
<sergiusens> elopio, I didn't ask you yet, but what do you think about http://click.pocoo.org/5/ ?
<sergiusens> elopio, and https://github.com/zyga/guacamole
<sergiusens> elopio, I discarded docopt as it has no translations nor easy support for subcommands
<kgunn> sergiusens: tedg so the clinic was timely for me, i was going to use my afternoon to get my mir dependencies sorted...so is it correct that the cmake snapcraft plugin
<kgunn> is actually only using the stuff in the stage area to check for dependencies ?
<kgunn> like, if i have all the dependencies for building mir on my machine...it won't think "ok"
<sergiusens> kgunn, pkconfig and such? mostly yes
<sergiusens> kgunn, if not it should be a bug
<kgunn> sergiusens: nope, was just double checking my thinking
<kgunn> thanks!
<sergiusens> kgunn, it is rather hard to separate it, so there are corner cases where the system stuff is picked up but mostly a problem when doing python
<kgunn> sergiusens: ok, i'll keep an eye out for it
<kgunn> sergiusens: so i was using mir's debian/control file as a guide for dependencies....is that ok-ish or wrong ?
<kgunn> as i end up adding a lot of -devs
<kgunn> and i noticed someone say in ted's example that was naughty
<sergiusens> kgunn, naughty? why?
<kgunn> dunno
<kgunn> :)
<sergiusens> kgunn, Ideally, all your libs will be parts in the future
<kgunn> sergiusens: you mean instead of pulling with apt ?
<sergiusens> kgunn, and those parts will live in the wiki and you would just get 'build-packages'
<sergiusens> kgunn, right, so for libraries it is mostly fine to use stage-packages as they don't have complex debian hooks running
<sergiusens> but I do want to think that using debs is an intermediate solution to get there faster
<kgunn> yeah i see what you mean
<kgunn> it does feel like a crutch a little
<tedg> sergiusens: I'm not sure that's the right message, I think that we should focus on debs being there for dependencies you want shared maintenance of.
<tedg> sergiusens: And then you can use parts for dependencies you want to track yourself.
<sergiusens> tedg, that's ok, but you buy into all the cruft debs bring in too
<sergiusens> you can't fine tune the build and have to use the lib with all the config flags turned on
<sergiusens> reason I consider it a shortcut
<kgunn> sergiusens: just to confirm, there's a list i notice when i run stage called "blacklisted from manifest packages:"
<kgunn> what's that about ?
<tedg> sergiusens: Sure, and I think that if you want all the config flags turned on, you have a dependency that you care enough about to track.
<tedg> kgunn: It's about the core level packages that are mostly taken care of by core. Like you don't need your own init daemon.
<tedg> kgunn: It does need some fine tuning though. If you find one you think you need, tell us.
<sergiusens> kgunn, those are depending packages that if installed, will create havok; you can explicitly call them out if wanted
<sergiusens> kgunn, most of what is in that list comes from deb2snap
<sergiusens> kgunn, the only important one is libc, we can't bundle that one without breaking things
<kgunn> sergiusens: tedg i noticed libstdc++6 is in the list...i thot c++ stuff wasn't in the core (as i learned last week) ?
<kgunn> or will you say, it is, but you can't link to it
<kgunn> ?
<tedg> I think that you end up pulling the one from teh build system in that case. But that's probably a bug in snapcraft.
<tedg> Hmm, it didn't seem to get pulled into my ginac snap.
<sergiusens> kgunn, tedg you indeed need libstdc++
<tedg> Uhg, it's grabbing the system one: http://paste.ubuntu.com/12866379/
<sergiusens> tedg, right, we saw that issue with dholbach last Friday
<sergiusens> tedg, we indeed need to remove that from the list
<tedg> jdstrand: Does the apparmor policy allow read access to /usr/lib/* or do we whitelist specific libraries?
<tedg> Seems like we should match a white list in the apparmor profiles and the list in snapcraft.
<sergiusens> tedg, we have a bug for that already
<sergiusens> tedg, the review tools will whitelist libc dangling symlinks
<sergiusens> all else is supposed to be in the snap
<sergiusens> the, 'copy from the system' thing is to ease development
<sergiusens> but that fails if working on wily and deploying to vivid
<tedg> That's for the review tools, but it seems also that the apparmor profiles shouldn't allow reading the other libs that are in core to support core stuff.
<sergiusens> tedg, it is allowed today, not sure about plans to block it
<jdstrand> tedg: apparmor policy in the default template use the base abstraction (/etc/apparmor.d/abstractions/base). that allows, among other things, read access to /usr/lib/* and mmap for libraries under /usr/lib
<jdstrand> we have no plans to block it currently. we allow a whole bunch of (safe) stuff in /usr/bin for shell scripting
<jdstrand> and that will use various libs
<jdstrand> (for example)
<sergiusens> jdstrand, we could start blocking python2/3 soon though (not without previous agreement but it is a posibility)
<jdstrand> we could list specific libraries, but that is going to be very hard to maintain and will create an antagonistic relationship with ddevelopers
<jdstrand> yes
<jdstrand> we could drop the python abstraction and the interpreter
<jdstrand> same for perl
<jdstrand> I would caution you to not do it in 15.04 though
<jdstrand> unless you want to break people
<jdstrand> or don't mind it
<sergiusens> jdstrand, I do not want to break people, no :-)
<sergiusens> elopio, simple one, not sure if the right thing, but I prefer it https://code.launchpad.net/~sergiusens/snapcraft/lifecycle/+merge/274947
<jdstrand> sergiusens: other than my already expressed but reiterating now 'forcing bundling python adds 40M to the snap per arch', if the snappy folks feel like removing it from the policy is the way to go, file a bug and I'll do it
<jdstrand> it would be a shame to have ufw be a 120MB package though
<jdstrand> maybe it is 30M, not 40. still
<sergiusens> jdstrand, well python was on its way out of the image, at least a desire for a while now
<jdstrand> yes, I understand
<jdstrand> sergiusens: but note previous conversation between me and Chipaca from earlier today
 * sergiusens runs lastlog
 * sergiusens guesses its about timeframe for appamor click
<jdstrand> sergiusens: well, the move can be tied to the go absorption of policy generate (ie, no more python) or not (just get click compat off the image)
<jdstrand> sergiusens: considering resources, I'll (once again) try to get it off the image, then snappy devs can rewrite it whenever it makes sense
<kgunn> sergiusens: tedg so back to the pulling stage-packages, is the thinking that you'd really only do that once for a project (at least until you wanted to get "new" packages)
<kgunn> like you wouldn't think people would regularly pull and rebuild their snap
<tedg> kgunn: Generally yes, I'm not sure many people will build their snaps regularly themselves when we have support for builders.
<tedg> kgunn: I think they'll only do that when testing various things, otherwise they'll align a builder to branch and have it do it.
<elopio> sergiusens: $ sudo snappy install licensed.canonical
<elopio> Installing licensed.canonical
<elopio> licensed failed to install: snappy package not found
<sergiusens> elopio, it might have been blocked, let me check
<elopio> I think you tricked me :p
<sergiusens> elopio, try now
<elopio> sergiusens: thanks!
<sergiusens> elopio, mind looking at https://code.launchpad.net/~sergiusens/snapcraft/maven/+merge/274964
<sergiusens> elopio, it is pretty simple ;-)
<elopio> sergiusens: looks good, but no test.
<sergiusens> elopio, that is a hard one; integration or unit?
<sergiusens> both are hard, first one implies a pom which I need to figure out, unit is, well, maybe unit ;-)
<elopio> sergiusens: I'd say integration. But at this moment I'm only concerned about coverage, so make the one that gives you more confidence in preventing regressions.
#snappy 2015-10-20
<sergiusens> elopio, I pushed an integration test
 * sergiusens waves goodnight and calls it a day
<dholbach> good morning
<shuduo> kgunn: just want to update what i did yesterday and today. i finally made qt clock demo work with vm. the early error msg might be lead by network problem. I used command line to install mir.mvp-demo few times and got it installed at last. then I followed Darren Landoll's method to change mir-run and install qt clock demo and see it run perfect now.
<fgimenez> good morning
<Chipaca> oh, that's nice
<mvo> hm?
<Chipaca> fmt doesn't check the return value of its internal buffer handling
<Chipaca> ie, do fmt.Println or fmt.Printf
<clobrano> morning all :)
 * Chipaca reads further
<Chipaca> ah, it's not a bytes, but a []byte with their own implementation of write that never returns error
<Chipaca> ok, fair enough
<Chipaca> ooh, and bytes.Buffer's write also has âerr is always nilâ
 * Chipaca throws away some ifs
<JamesTait> Good morning all; happy Tuesday, and happy Brandied Fruit Day! ð  ð
<Chipaca> jdstrand: ogra_: mvo: https://code.launchpad.net/~chipaca/snappy/config-modules/+merge/274987
<Chipaca> jdstrand: ogra_: as it says in the branch, please do comment
<Chipaca> looking for feedback
<ogra_> Chipaca, why is potato a boolean ?
 * ogra_ would expect a list instread ... 
<Chipaca> ogra_: because you potato, or you no potato
<Chipaca> :-p
<Chipaca> ogra_: why a list?
<Chipaca> (if you say the above with a pseudo-latvian accent, we could do the whole shtick)
<ogra_> Chipaca, because for i.e. firewalling i have to load a bunch of modules having a list makes it a lot easier for the admin
<ogra_> vs calling the same command over and over to load them all
 * ogra_ commented on the MP
<Chipaca> i'll reply in the mp for jamie's benefit
<ogra_> ogra@anubis:~/datengrab/images$ ls /lib/modules/3.13.0-65-generic/kernel/net/netfilter/|wc -l
<ogra_> 115
<ogra_> there is a module for each and every sub-function of the firewall ...
<Chipaca> ogra_: replied
<ogra_> me too :)
<Chipaca> ogra_: thanks!
<Chipaca> i'll leave it un-topapproved so jamie can get a word in
<ogra_> yep
<Chipaca> @remindme 3h top-approve modules config
<nothal_> Chipaca: No such command!
<ogra_> needs the core-config change too anyway
<Chipaca> yes
<Chipaca> ogra_: no time like the present :-p
<sergiusens> Chipaca, hey, mind looking at https://code.launchpad.net/~sergiusens/snapcraft/maven/+merge/274964
<sergiusens> mvo, if you don't mind https://code.launchpad.net/~sergiusens/snapcraft/1507814/+merge/275021 your input would be good
 * Chipaca branches *all* the things
<mvo> Chipaca: and I will start with the make it things instead of if a|b|c{
<Chipaca> mvo: is that a reasonable thing to do this week?
<Chipaca> i mean, me no likey, but deadlines
<mvo> Chipaca: good point, you seemed to suffer so much during the reviews that it looked like a good idea
<mvo> Chipaca: let me time box it
<mvo> Chipaca: and at least outline it
<Chipaca> mvo: ok. I made my suffering explicit just so you knew i wasn't ok with it being like that forever, not for you to fix it now :)
<sergiusens> mvo, apt has a big ft warning saying it shouldn't be used when scripting; is that no longer the case?
<sergiusens> s/ft/fat/
<sergiusens> ah, apt install doesn't just search
<mvo> sergiusens: oh, well, its  a bit of a cry-baby
<mvo> sergiusens: but it should be ok, no plans for changes in the cli for 16.04
<sergiusens> mvo, maybe a different MP? This doesn't look very nice http://paste.ubuntu.com/12876464/
<mvo> sergiusens: hm, ok
<sergiusens> mvo, there, fixed; maybe approve now :-)
<sergiusens> mvo, now that the meeting is over, approve my MP :-)
<mvo> sergiusens: sorry I misclicked and did not notice
<mvo> sergiusens: this was never "needs-fixing"
<sergiusens> mvo, ah, well I abide to what the reviewer told me or it would be just bureaucracy to ask for reviews :-D
<elopio> ogra_: can you help me making sense of this? "Debian supports the runtime modification of the Device Tree which is a feature required by BeagleBone-IO"
<elopio> that's the dtoverlay you enabled for rpi, right?
<ogra_> elopio, where is that from ?
<ogra_> oh, BBB
<elopio> ogra_: https://github.com/julianduque/beaglebone-io
<ogra_> well, thats a BBB feature
<ogra_> i doubt the Pi can support it
<ogra_> BBB does that through capemgr ... (which seems to have gotten a replacement in 4.2 that ppisati perhaps knows the name for :) )
<tedg> ogra_: davidm was trying to make a library to have standard GPIO across boards.
<tedg> ogra_: Focusing on the 96boards, but might be something useful.
<elopio> ogra_: I'm not looking after pi support for it. I just want to run beaglebone-io on bbb. But U didn't understand that requirement.
<elopio> I don't have a /sys/devices/bone_capemgr.*
<elopio> s/U/I/
<ogra_> elopio, right, thats a hack ... and it got replaced by some new mechanism in the mainline kernel afaik
<ogra_> (capemgr is a hack i mean)
<elopio> ogra_: ok. Let me give it a try.
<ogra_> tedg, i wish him good luck with that :) (given that each and every board manages them different and in different layers of the system)
<tedg> ogra_: Yeah, his goal was to align it with what users see on the board. i.e. on the header the first pin, because that could be any number of GPIO.
<tbr> ogra_: cape manager is essentially back, now that it's mainline
<ogra_> tbr, ah, then i dont get why we dont have it in our 4.2 kernel
<tbr> check with rcn?
<tbr> probably different api/incantations now
<ogra_> ppisati, ^^^ ?
<tbr> the official debian bbb images with 4.x kernel should support dynamical dtbo loading
<ppisati> ogra_: nope, there's no cape manager in 4.2
<ppisati> if they pulled it in 4.3+, i didn't notice that
<ppisati> but i might have missed it
<ogra_> ppisati, well, i wonder how to dynamically load dtbs then
<ppisati> ogra_: i don't think there's any replacement fir that
<ppisati> ogra_: my bet is tht they are running with a patched kernel
<ogra_> well, see what tbr said above ... seems rcn-ee might know something here
<ogra_> if we need a patch we're indeed screwed
<ppisati> tbr: i don't see the capemanager in mainline, where is it?
<tbr> ppisati: I'm not familiar with details, but I know overlays should work in 4.2 or 4.3. ask rcn-ee for details, he knows which patches he needs on top of which kernel version
<tbr> or just look at the BBB scripts
<ppisati> tbr: overlays are a way to change a single field in a DT node, cape manager builds on that
<ppisati> tbr: and AFAICS, cape manager is not in mainline
<tbr> ppisati: I didn't say that the 3.8.x kernel cape manager was 1:1 available in mainline now...
<elopio> fgimenez: my only complaint about that waffle is that it's not free. Doesn't taiga give us something similar?
<tbr> I do know though that rcn has been working on making things work in a *similar* fashion with his builds of mainline for BBB which seemed to have a fairly thin patchset (composition unknown)
<fgimenez> elopio, mm it's free unless you use github enterprise https://waffle.io/pricing. maybe taiga also integrates with github, i'll take a look
<elopio> fgimenez: gratis, no libre :)
<fgimenez> elopio, yep :) iirc there was another project like this hosted in github itself, let me check
<fgimenez> elopio, this one has an Apache License https://github.com/TWtablero/tablero, haven't tried it though
<elopio> sergiusens: tedg: nexe creates a single file for nodejs projects. That seems like a nice shortcut :)
<elopio> https://github.com/jaredallard/nexe
<tedg> Seems like wrapping your JS in Python might be the definition of crazy :-)
<tedg> Though certainly up for stealing code ideas.
<davmor2> tedg: but if he wraps the python in bash it's ideal right?
<tedg> I think it should *compile* the Python to Bash.
<elopio> all the cool kids are compiling interpreted languages.
<Rlyeh> Hi
<Rlyeh> I cant run apps under docker :(
<Rlyeh> This is my system information: http://paste.ubuntu.com/12877538/
<Rlyeh> I cant start cgproxy, here is the status: http://paste.ubuntu.com/12877531/
<Rlyeh> And this is my apps and their ports: http://paste.ubuntu.com/12877540/
<Rlyeh> Docker cant run apps, why?
<Rlyeh> How can I run apps under docker?
<Chipaca> hmm, i don't remember who worked on the docker snap
<ogra_> Rlyeh, you mean ther eis no owncloud running if you try to connet to it ?
<ogra_> works fine here
<Rlyeh> Yes
<sergiusens> kickinz1|away, ^
<Rlyeh> I'm in Iran, recently, docker applied some restriction for Iran and I cant login and pull images
<Rlyeh> However owncloud is a local image
<Rlyeh> But I cant run it
<ogra_> no, the snap pulls from docker i think
<ogra_> you should see info in syslog
<ogra_> and it should tell you there if it cant startz
<ogra_> *start
<Rlyeh> Snappy downloaded the image, it was about 22MB
<ogra_> thats only the env ... it then pulls the docker owncloud install on first startup i think
<Rlyeh> OK, let me check the log...
<ogra_> in any case, kickinz1|away is your man ... he m,aintains both packages
<ogra_> theoretically snappy install docker and then snappy install owncloud should give you a working owncloud install though
<ogra_> hmpf ...
<ogra_> i think wer need to do something about our initrd ...
<ogra_> booting with no root= arg set drops me into a shell ... while i would expect it to reboot on panic instead
<ogra_> mvo, i'm wondering, does dropping to an initrd shell ever make sense in snappy ? i wonder if we should rewrite the panic() function for this to force a reboot instead
<Guest42341> why am i on this channel??? wtf
<mvo> ogra_: there is a open bug about this and pitti has some suggestions what we can do to make it do a reboot instead
<Rlyeh> Ogra_, I didn't see anything wrong, but can you please check my log? http://paste.ubuntu.com/12877687/
<ogra_> well, we just need to replace initrd's panic function
<ogra_> Rlyeh, syslog, not dmesg
<ogra_> dmes will only have kernel messages
<ogra_> nothing from services usually
<Rlyeh> By what command? syslog is not valid
<ogra_> sudo less /var/log/syslog ?
<ogra_> or some such
<Rlyeh> oga_, you were right, the package was not pulled: http://paste.ubuntu.com/12877810/
<Rlyeh> Damn it, why did they blocked Iran? :(
<Chipaca> ogra_: do you recall offhand why we have pycurl on the image?
<ogra_> i think that predates me
<ogra_> but let me bet .,... zyga ?
<ogra_> Chipaca, hmm, was snappy itself not initially python ?
<Chipaca> yes
<ogra_> could be a leftover from that
<Chipaca> we've got pycurl, urllib3, and requests
<ogra_> to download snaps
<sergiusens> Chipaca, I know
<sergiusens> Chipaca, system image
<Chipaca> sergiusens: it uses all those?
<ogra_> oh
<sergiusens> Chipaca, it uses pycurl
<Chipaca> ah, k
<Chipaca> and requests?
<sergiusens> Chipaca, is that directly seeded
<Chipaca> dunno :)
<ogra_> likely not
<Chipaca> i just happened to ls /usr/lib/python*/dist-pacakges
<Chipaca> and saw more than i was expecting
<Chipaca> including jinja (!??)
<sergiusens> Chipaca, urllib3 is a dep for requests; I don't think anyone is using urllib3 directly
<Chipaca> ah, ok
<sergiusens> we just need to figure out who uses requests :-)
<sergiusens> ogra_, where is the package manifest for the latest build?
<ogra_> just ubseed it and see what fails ;)
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/wily-preinstalled-core-amd64.manifest
<sergiusens> ogra_, it isn't directly seeded, is it?
<ogra_> wily
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/current/vivid-preinstalled-core-amd64.manifest
<ogra_> vivid
<sergiusens> Chipaca, ogra_ so cloud-init depends on python3-requests ;-)
<ogra_> and no, i dont see it in the seeds
<ogra_> oh man
<mvo_> ogra_: I suspect there is something with the resize script, if I remove system-ab my system hangs forever in what appears to be the resize script. is there a way to enable debug mode, i.e. see what its doing?
<kgunn> sergiusens: so y;day we were discussing how snapcraft shouldn't look outside it's proj directory for pulled libs...and i ran into something just want to chat thru
<kgunn> so for mir, i got snapcraft to the point of actually compiling on my wily machine (where boost is installed on the system)
<kgunn> so went to lxc for vivid, started there...didn't get past cmake...
<kgunn> well, mir has a FindBoost.cmake that searches for boost based on $boostroot or some such, if it can't find it goes to /usr where it finds it...
<kgunn> in this case, should i simply create a plugin extension specific to mir, to pass in a Boost_DIR=<dir>  as part of the cmake .. call ?
<kgunn> also...kind of interesting that the cmake file went and looked for stuff outside the project dir, not sure how snapcraft would fight against that...
<tedg> kgunn: We can't fight against it other than when you push it to LP it won't work.
<tedg> kgunn: The cmake plugin has a parameter I believe for build flags, let me check.
<kgunn> tedg: i mean that's not awful...but if i hadn't tried it in lxc, i wouldn't have realized
<tedg> kgunn: Yeah, it's an array, configflags, those will get passed to cmake
<tedg> I think we need to figure out a warning or something. Not sure how we'd implement it.
<tedg> But yeah, I've had that problem.
<gchristensen> Hi, is there documentation on making a snappy package for a docker image?
<tedg> I think that kirkland wrote a blog post on that... let me look.
<gchristensen> another thing is, is there a way to install ruby? :/ `search` isn't showing anything.
<tedg> gchristensen: You wouldn't install ruby in the base system, it would be included in the application that uses it.
<tedg> Ah, there it is. gchristensen: http://blog.dustinkirkland.com/2015/07/prime-time-docker-juju-and-snappy.html
<gchristensen> ok, thank you for the help and information tedg. I don't think snappy is a good fit for this project, though.
<gchristensen> cheers, good luck -- I look forward to checking it out again in a year or so.
<sergiusens> tedg, kgunn the best way to circumvent that is to put snapcraft under apparmor and restrict access to /include and /usr/include ;-)
<sergiusens> not the best way, just a quick way
<tedg> Yeah, I figured that wouldn't be flexible enough. As we'd want the libc headers from there, for instance.
<tedg> Perhaps if we could make it only give a warning or something like that.
<sergiusens> right
#snappy 2015-10-21
<dholbach> good morning
<clobrano> good morning all
<fgimenez> good morning
<ogra_> mvo, the resize script logs to /run/initramfs/resize-writable.log
<mvo> ogra_: right, I don't get a shell when this happens. is there a way to make it dump the log on the screen or the serial port?
<ogra_> hmm, no
<mvo> ok, not important right now, its a bit of a courner case that partition in the middle of the disk disappear
<ogra_> (i mean, beyond hacking the script indeed)
<ogra_> thats on a GPT system i assume ?
<Chipaca> mvo: mo'in!
<Chipaca> mvo: wrt "autovivifying", is it the word you didn't know of, or the concept?
<mvo> hey Chipaca - a word I did not know of
<Chipaca> ah :)
<Chipaca> i blame perl
<mvo> indeed
<ogra_> poor perl
<JamesTait> Good morning all; happy Wednesday, and happy Back To The Future Day! ð The future is now!
<ogra_> not only now ... it is TODAY !
<Chipaca> everybody's going on about hoverboards, and all i want is climate control
 * Chipaca tweets it
<ogra_> you could team up and do climate controlled hoverboards though
<Chipaca> sell hoverboards to londoners, with a note saying they only actually hover when it's dry
<Chipaca> rake in millions
<Chipaca> actually be selling roof tiles
<morphis> anybody had time to have a look at https://bugs.launchpad.net/snappy/+bug/1501638?
<ubottu> Launchpad bug 1501638 in Snappy "Removing a snap doesn't clean up generated files" [Undecided,New]
<morphis> with that we see also https://bugs.launchpad.net/snappy/+bug/1452848
<ubottu> Launchpad bug 1452848 in Snappy "snappy fails to update snap if previous version systemd stop action failed" [Critical,Incomplete]
<morphis> joc_: ^^
<dpm> davidcalle, morning!
<dpm> davidcalle, do you have everything you need to start with the snappy docs IA work?
<davidcalle> dpm o/
<davidcalle> dpm, yep
<dpm> davidcalle, excellent, thanks
<asac> ogra_: mvo: anything i need to do on milestone creation still?
<ogra_> asac, not really
<ogra_> and welcome back daddy !
<Chipaca> morphis: do you have steps to reproduce bug 1452848?
<ubottu> bug 1452848 in Snappy "snappy fails to update snap if previous version systemd stop action failed" [Critical,Incomplete] https://launchpad.net/bugs/1452848
<morphis> Chipaca: yes
<Chipaca> morphis: could you add them to the bug please?
<morphis> yes
<morphis> joc_: does https://bugs.launchpad.net/snappy/+bug/1452848/comments/4 apply to what you did to end up with that bug?
<ubottu> Launchpad bug 1452848 in Snappy "snappy fails to update snap if previous version systemd stop action failed" [Critical,Incomplete]
<morphis> Chipaca: what about https://bugs.launchpad.net/snappy/+bug/1501638 ?
<ubottu> Launchpad bug 1501638 in Snappy "Removing a snap doesn't clean up generated files" [Undecided,New]
<joc_> morphis: yes sounds about right
<morphis> good
<Chipaca> morphis: i haven't looked
<Chipaca> morphis: can you put the generated snap somewhere? I don't have vivid.
<ogra_> mvo, i uploaded an initramfs-tool-ubuntu-core to the PPA that will print all resize output to the console if "debug" is set on the kernel cmdline
<ogra_> (next image should have it)
<Chipaca> morphis: I'm not seeing that, here
<Chipaca> morphis: what are you running it on?
<morphis> Chipaca: joc_ saw it
<Chipaca> joc_: what are you running it on?
<miken> dholbach: Hi there! mvo says you're the person to chat with about getting a click-reviewers-tools branch landed? I've got this MP which intended to just add a new test which *didn't* use any mocks, but ended up refactoring the test base class to get rid of a small test isolation issue. More details on the MP if you've time: https://code.launchpad.net/~michael.nelson/click-reviewers-tools/add-test-without-mocks/+merge/274509
<asac> ogra2: thx :)
<dholbach> miken, I'll have a chat with jdstrand about landing it later on
<miken> Great, thanks dholbach
<Chipaca> fgimenez: which is the image that doesn't bring up eth on first boot in kvm?
<fgimenez> Chipaca, 15.04/edge from 212 at least, 209 was good
<dholbach> jdstrand, are https://code.launchpad.net/click-reviewers-tools/+activereviews MPs you want to give an extra thorough review yourself or are you fine with maybe pindonga and myself reviewing them?
<dholbach> sergiusens, tedg: shall we do a clinic at UOS?
<tedg> sergiusens: Does that make sense? I thought UOS was for planning?
<sergiusens> tedg, uos has evolved
 * tedg can't keep track of what the kids are doing these days
<jdstrand> dholbach: they all either have issues I need to comment on or need a thorough review
<dholbach> ok
<dholbach> thanks jdstrand
<dholbach> miken, mvo, shawnwang: ^
<mvo> wuuut, issue :P ?
<mvo> my branch has no issues
<dholbach> mvo, typos maybe :-P
<mvo> lol
 * dholbach hugs mvo
<dholbach> tedg, sergiusens: so yeah, there's planning and there's "show & tell" sessions
<dholbach> I think at UOS we're going to get some additional eyeballs
<ogra_> crap
<ogra_> seems snappy update on the rpi is not so happy
<Chipaca> pitti: you got a bit?
<ogra_> or a byte :)
<mvo> pitti: hi, can I ask silly systemd questions again? so I have a snappy system (wily) here that tells me startup has finished but I get no getty on tty1, only on 2-6. should I be concerned?
<cmk> any1 get snappy GUI on snappy desktop to work?
<ogra_> cmk, i think tedg did a QML app on top of Mir once
<ogra_> and no. desktop is still a bit away
<tedg> Yeah, but that wasn't snappy desktop.
<tedg> Just snappy core.
<ogra_> well, it was a snappy GUI :)
<ogra_> (app)
<ogra_> ppisati, hmm ... i just accidentially flashed a rpi image that still had 3.19 ... ran snappy upgrade which worked fine, but after reboot i end up with: http://paste.ubuntu.com/12886195/
<ogra_> doesnt even uncompress 4.2
<ppisati> ogra_: 99% you have to update the dtb
<cmk> k thx
<ogra_> ppisati, hrm
<ogra_> thats tricky since the dtb doesnt actually liuve in the device tarball but in the oem (bootloader) snap
<ogra_> also then we wouldnt be able to roll back
<ogra_> mvo, sergiusens ^^^ thats a problem
<ogra_> (nothing we need to tackle today but the RPi HW reqs wont work with the current snappy design as soon as we get a major bump of the kernel)
<ppisati> ogra_: don't we handle the rollback via the a/b thing?
<ogra_> and thanks to vfat i cant just use a link to the a or b dtb
<ogra_> ppisati, yes, after the blob loaded the dtb
<ppisati> ogra_: and since a/b doesn't work in rpi2 due to the bcm bootloader
<ogra_> a b works fine
<ogra_> this is why we have uboot
<ogra_> it handles all that
<ogra_> but the blob loads the dtb before we load uboot
<ogra_> and it doesnt load it from a or b either but from /boot
<ppisati> ogra_: right, so my point was that we hanlded going back and forth using two different kernels/initrd/dtb
<ogra_> not on the Pi
<ppisati> right
<ogra_> because the dtb is loaded by the blob
<ppisati> since we use the bcm bootloader
<ogra_> yeah
<ppisati> so that feature is broken there
<ogra_> which isnt acceptable for a fully supported snappy arch
<ogra_> rollback needs to work
 * ogra_ sighs
<ogra_> the blob also doesnt knwo if we boot a or b ... because the logic for that happens later
<tedg> vmayoral: Trying to think about how we explain better the whole deb vs. snap thing on the mailing list. Here's my thought dump as a graphic, thoughts?  https://usercontent.irccloud-cdn.com/file/26hwfJt2/deb-vs-snap
<vmayoral> hi tedg, that's good one
<vmayoral> tedg: in a general way, that's what Snappy (AFAIK) is doing
<ogra_> ppisati, oh ! ignore me, thats probably a red herring ... i just see it installed the -generic kernel during the upgrade :P
<vmayoral> tedg: ROS-wise, there's the  issue of "extending" a robot's behavior based on other snaps. I've been doing a bit of thinking on that but haven't been able to come up with anything solid but a few hacks
<vmayoral> tedg: will keep thinking though :)
<ogra_> so the hard hang at uncompressing  definitely comes from that
<ogra_> (wont fix the dtb issue indeed)
<vmayoral> tedg: thanks for clarifying the OSRF claim btw, appreciate that.
<tedg> vmayoral: Cool, no problem, sorry I misspoke originally.
<vmayoral> tedg: I'm interested about your thoughts on the snappy environment for ROS
<tedg> Overally I'm worried people are mis-understanding Snappy and so we're not communicating.
<tedg> Overall
<tedg> Feel like we need some new language there.
<tedg> vmayoral: For ROS I'm kinda leaning towards thinking about ROS2 and keeping ROS1 contained in a snap. Which we can then support for ROS2 (i.e. bundle the bridge)
<vmayoral> tedg: that'll be sweet and pretty smart. ROS 2 is still on its infancy but it'll take over really soon and will define the next 10 years of robotics
<vmayoral> (that's my personal thinking at least)
<vmayoral> tedg: my feeling is that there're some things that quite don't fully match, how do you see the following scenario: "Erle-Spider is delivered based on Snappy with a single snap containing roscore and our ROS packages. A developer in Japan wants to create a visual odometry snap and make money out of it. How can he do it without hacking the snap released by us?"
<tedg> vmayoral: I'll start by saying I'm relatively new to ROS :-)
<tedg> vmayoral: But it seems to me that's basically the problem ROS2 is trying to solve.
<tedg> vmayoral: In that in ROS1 you need all kinds of access and assumptions about the underlying system to do that.
<tedg> vmayoral: Where ROS2 seems to think about associations and connection points between robots, which could be internally as well.
<vmayoral> tedg: i'd say the same applies to RO2. ROS 2 replaces the communication layer by DDS and adopts a standard but several problems still will apply with the snappy aproach
<vmayoral> let me put it this way:
<vmayoral> tedg: "Erle-Spider is delivered based on Snappy with a single snap containing roscore and our ROS packages to make it move around. In a later stage, Erle Robotics deliver a 'visual_odometry' snap that provides odometry information to developers exposed in a new ROS node. A developer in Japan wants to create an app with Erle-Spider an for that he wants to use visual the odometry snap released by Erle Robotics."
<vmayoral> How do you see this happening?
<ogra_> your odometry data would have to be exposed on a (domain|network) socket ... from where he picks it up
<vmayoral> ogra_: but since snaps can't depend on snaps, there should be a way to enforce it, shouldn't it?
<tedg> vmayoral: So I think that there will have to be some amount of frameworks, and frameworks are going to have to know something about the applications that use them.
<vmayoral> ogra_: i mean, right, UDP comms should be allowed between snaps, but dependencies aren't AFAIK.
<ogra_> right
<tedg> vmayoral: For instance, an app on the desktop needs to install and setup its icon. Same idea.
<tedg> vmayoral: There'll be a certain amount of "handshaking," declarative of course, between the two.
<vmayoral> tedg: mmm well that convinces a bit. Not sure, i'd like to do more thinking about it
<vmayoral> what seems clear to me are the benefits of adopting Snappy on a final (commercial) product.
<vmayoral> The fact that you guys deal with security is actually a great complement to the lack of it in ROS
<tedg> Yes, I was a little shocked by that when I started researching how ROS works :-)
<ogra_> well, dont blame ROS
<ogra_> after all this is how *all* embedded development worked for the past 20-30 years
<ogra_> (which is why it is so easy to hack into nuclear power plants or industrial controllers today :P )
<tedg> Let's not talk about that, I want to sleep tonight :-)
<ogra_> haha
<ogra_> http://themcphails.uk/snappy.jpg
<kgunn> tedg: ok, back to our discussion yday, configflags is supported by cmake....so i'd suppose i type something like snapcraft build Boost_DIR=./parts/mir-demo-server/install/usr/lib/x86_64-linux-gnu/
<kgunn> just checking incantation syntax
<kgunn> what would it be
<tedg> kgunn: No, no, a field in the snapcraft.yaml
<tedg> kgunn: plugin: cmake\nconfigflags:\n-Boost_DIR=./parts/mir-demo-server/install/usr/lib/x86_64-linux-gnu/
<tedg> kgunn: (whitespace left as an exercise for the reader)
<kgunn> tedg: lol @whitespace
<kgunn> thanks
<kgunn> tedg: so i added like so  https://pastebin.canonical.com/142330/ but got a
<kgunn> Issues while validating snapcraft.yaml: mapping values are not allowed here on line 18 of snapcraft.yaml
<kgunn> so possibly failed your whitespace quiz :)
<tedg> kgunn: Yes, you did :-)
<ogra_> heh
<tedg> kgunn: Two spaces away from configflags.
<ogra_> and you thought python was insane, eh ?
<tedg> Yeah, I find writing YAML so error prone. I really don't like it most of the time.
<ogra_> well, json isnt that much better
<kgunn> tedg: 2 spaces away from configflags ? sorry...more context?
<ogra_> unless you have a properly highlightingv editor that shows the matching bracket .... and a gigantically big screen
<tedg> kgunn: http://pastebin.ubuntu.com/12886920/
<tedg> ogra_: Being able to use '%' in VIM helps me there.
<kgunn> tedg: damn it! :)
<ogra_> yep
<tedg> Though, I have a gigantically big screen too ;-)
<ogra_> i only have three vertically small ones
<ogra_> which doesnt exactly help with that issue
<pitti> mvo: "systemctl status -l getty@tty1.service"?
<lool> sergiusens: do you have a recent example of custom plugin?
<lool> sergiusens: I've put x_custom.py under parts/plugins, but it's not finding the custom_cmd option in self.options at runtime
<mvo> pitti: many thanks, I think I found the underlying issue, has to do with writable-paths
<sergiusens> lool, look at the last snappy clinic
<sergiusens> :-)
<sergiusens> lool, name the module x_custom.py but call it plugin: custom
<lool> sergiusens: I figured the schema thing out
<sergiusens> lool, show me your plugin
<lool> sergiusens: I  needed a schema
<sergiusens> lool, ah, there we go
<sergiusens> lool, yeah
<lool> I took it from the autotools plugin
<sergiusens> lool, the base plugin is a lot more simple in 0.4 btw
<sergiusens> lool, http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/snapcraft/__init__.py
<sergiusens> elopio, https://code.launchpad.net/~sergiusens/snapcraft/1481122/+merge/275237 mind looking at that?
<jdstrand> Chipaca: hey, fyi, I had some time today to look at the click-apparmor removal. I decided to go with the go rewrite in the same pass since it occurred to my that cranking up the python interpreter twice (once for apparmor and once per seccomp) was going to really stink on arm
<jdstrand> twice per app within the snap
<jdstrand> that was not going to be nice
<jdstrand> Chipaca: so, I have some code, nowhere near ready for merging, that actually generates apparmor and seccomp policy for security-template/caps and security-policy
<jdstrand> Chipaca: but when I'm done, .click/ will be gone, the .json files will be gone, aa policy will move to /var/lib/snappy, and in general everything is going to be clean and nice
<jdstrand> like how seccomp is now. but even that is going to be better cause we won't use sc-filtergen any more and the policy generation logic will have a clean internal api
<Chipaca> jdstrand: yaaay!
<jdstrand> so snappy install is cleaned up too
<Chipaca> jdstrand: i needed this news :)
<Chipaca> not because i was this desperate for click-apparmor removal
<Chipaca> but because it's been a long, sucky day
<Chipaca> and this is good :)
<jdstrand> :(
<jdstrand> glad I could give you some good news
<jdstrand> it is going to take quite a bit of work for me to get everything in order, but I have a plan and even some code that is doing good things
<jdstrand> so, hopefully in a couple weeks I'll have something to review
<jdstrand> Chipaca: oh, and the weird security-override is going to be revamped
<jdstrand> Chipaca: you won't specify a json file any more. you'll express the overrides directly in the package.yaml
<jdstrand> eg:
<Chipaca> jdstrand: that sounds nice
<jdstrand> binaries:
<jdstrand>   foo:
<jdstrand>     security-override:
<jdstrand>       apparmor:
<jdstrand>         read-paths: [ /foo, /bar ]
<jdstrand> that sort of thing
<jdstrand> so it is all going to be nice and clean :)
<Chipaca> excellent
<jdstrand> security-override has been bugging me for a while
<jdstrand> well, really, all of it has
<jdstrand> anyhoo
<jdstrand> :)
<Chipaca> :)
<Chipaca> thanks
<Chipaca> ogra_: elopio: so, wrt 15.04 edge not bringing up eth0, i have a fix
<Chipaca> ogra_: elopio: https://code.launchpad.net/~chipaca/snappy/firstboot-ordering/+merge/275244
<Chipaca> ogra_: elopio: but that's not the whole story
<Chipaca> we also need to tweak cloud-init's service file
<Chipaca> ogra_: that's where i think you come in? (not sure) (i know you just luuurve cloud-init)
<Chipaca> i'll comment on that mp so it isn't lost
<Chipaca> and then zz
<cmk> hi
<cmk> ogra are you online?
<lool> sergiusens, beuno: what's the quickest way to download a snap from the public store?
<Chipaca> lool: do you know the package name?
<Chipaca> lool: if you do, then, https://search.apps.ubuntu.com/api/v1/package/hello-world.canonical
<Chipaca> lool: and look for anon_download_url
<lool> Chipaca: yup
<Chipaca> lool: GET $( GET https://search.apps.ubuntu.com/api/v1/package/mir.mvp-demo | jq -r .anon_download_url )
<Chipaca> lool: for example
<lool> Chipaca: thanks
<Chipaca> lool: not a long-term solution as anon downloads should go away at some point
<manik> Chipaca: there's no URL to download from at the hello-world link
<manik> it just begins downloading directly
<Chipaca> manik: sorry, what?
<cmk> anon_download_url: "https://public.apps.ubuntu.com/anon/download/canonical/hello-world.canonical/hello-world.canonical_1.0.18_all.snap",
<manik> Chipaca: my bad, found it
<Chipaca> k. g'night.
<cmk> on ubuntu core 14.04 edge... i can see a cursor, but the screen is black
<cmk> *snappy ubuntu core
<cmk> suggestions?
#snappy 2015-10-22
<fgimenez> good morning
<dholbach> good morning
<mvo> ogra_: good morning, it looks like we have dnsmasq and tss both with uid 109 in the image right now, could you have a look please? in wily, not sure about stable, just noticed on wily
<mvo> hey dholbach
<mvo> fgimenez: good morning
<dholbach> hey mvo
<fgimenez> hey mvo, dholbach :) mvo, do we have a rc image?
<mvo> fgimenez: not yet, sorry, I'm working on it now, Chipaca almost fixed the network bug (which is great)
<fgimenez> mvo, awesome! ok np
<dholbach> hola fgimenez :)
<davidcalle> Morning o/
<clobrano> buongiorno :)
<JamesTait> Good morning all; happy Thursday, and happy Wily Werewolf welease day! ð
<dasjoe> JamesTait always seems like the most enthusiastic morning person
<JamesTait> It's all a charade.  I'm a grumpy old curmudgeon really. ð
<Chipaca> mvo: do you have a branch of almost-next-15.04?
<mvo> Chipaca: 15.04 is up-to-date for the release, I think the one outstanding issue is the ordering
<Chipaca> mvo: and is the latest edge built on that?
<Chipaca> just to minimise the delta i'm working with
<mvo> Chipaca: yes, well, I can build a new image now
<Chipaca> mvo: i mean, will u-d-f build it with that
<Chipaca> or is that what you offered to build?
<mvo> Chipaca: biulding a new amd64 15.04/edge image with todays lp:snappy/15.04 branch so that you have something super close to the stable release
<mvo> Chipaca: does that help you?
<Chipaca> mvo: indeedly it does :)
<Chipaca> and i'll branch that and propose a branch on that
<mvo> Chipaca: thanks, you can also work on trunk right now, we have no delta and I inspected the changes (of course) before merging trunk to 15.04 and it looks very sane (famous last words!)
<Chipaca> ah! perfect then
<mvo> Chipaca: I triggered the image build, new 15.04/edge image should be ready in ~30min or so
<mvo> Chipaca: image build
<mvo> Chipaca: now it just needs to get imported
<Chipaca> mvo: it seems there was a 15.04/edge built overnight
<Chipaca> mvo: working with that for now
<mvo> yeah
<mvo> sure, that will be fine as well, the delta is small
<ogra_> mvo, whats bad about that ? (tss)
<ogra_> and yes, i seeded nss3 for a test because it showed up on some list from olli
<mvo> ogra_: two usernames with the same uids
<ogra_> uh ?
<ogra_> thats not possible
<mvo> ogra_: yeah, olli asked me to revert that seeding and he said he will follow up
<mvo> ogra_: let me double check about the uid, maybe its something local
<ogra_> right, as i said, it was for testing (and obviously worth it :) )
<ogra_> /etc/passwd is readonly
<ogra_> and checked during build
<ogra_> argh
<ogra_> so no, tss is a requirement for the rootfs encryption stuff
<ogra_> not related to my nss3 seeding
<ogra_> and yes, seems thats my bug :(
<ogra_> (didnt check enough that the tss uid is not already there)
 * ogra_ bumps the UID to 110
<mvo> ogra_: thanks, no worries. is this 15.04 too?
<ogra_> yes
<ogra_> well, let me check :P
<mvo> ok, please let me know once the fix is upload and I trigger a new amd64 image
<mvo> there is also a fix from Chipaca pending, so no worries we are not golden anyway yet :)
<ogra_> mvo, not in stable .... phew
<mvo> yay
<ogra_> now i wonder why we dont have dnsmasq there
<ogra_> oh, because ubuntu-fan only landed in rolling back then
<ogra_> (on purpose)
<ogra_> that was before all the crazy reqs. came in, we shoudl ask if we need fan on stable too now
<ogra_> uploaded to the PPA
<Chipaca> https://code.launchpad.net/~chipaca/snappy/firstboot-ordering/+merge/275244 is ready for review gents
<Chipaca> fgimenez: if you could try this ^ wrt firstboot bringing up eth0, that'd be cool
<fgimenez> Chipaca, ok on it
<Chipaca> fgimenez: much appreciated!
<Chipaca> fgimenez: i've fake-firstbooted ~20 times and it worked every time, fwiw
<ogra_> would be nice to know if this by chance also fixes the BBB
<ogra_> seems racy enough to be possible :)
<ogra_> /join #ubuntu-release-party
<ogra_> oops :P
<mvo> Chipaca: \o/ once you fix lands we should have a golden image
<Chipaca> ogra_: this should be less racy than before
<Chipaca> ogra_: so maybe :)
<fgimenez> Chipaca, works great on kvm \o/
<mvo> Chipaca: (I said it before, but I say it again) \o/
<Chipaca> fgimenez: and ... bbb? :)
<fgimenez> Chipaca, ogra i'll try bbb now
<Chipaca> whee :)
<fgimenez> Chipaca, yep :)
<Chipaca> fgimenez: could you put a +1 on the branch based on the success of kvm tests?
<fgimenez> Chipaca, sure
<Chipaca> fgimenez: even if it doesn't fix bbb, it fixes amd64, so we can build/release that at least
<fgimenez> Chipaca, there's one error in the test suite on kvm, but not related to eth0 on first boot "Error: open /etc/default/watchdog.wvUpOFylUogg: read-only file system"
<Chipaca> hm!
<Chipaca> eeeep
<Chipaca> ogra_: you around?
<Chipaca> mvo: this might be bad
<ogra_> what ?!?
<Chipaca> ogra_: we have just /etc/default/watchdog as rw, not the directory itself?
<ogra_> wh would anything write to it on boot ?
<Chipaca> not boot, this is the integration test suite
<Chipaca> testing setting watchdog
<ogra_> yeah, makin the directory writable would kind of defeat the purpose
<mvo> uh, atomicWrite ?
<ogra_> yeah
<ogra_> needs special hacks
<ogra_> (like hostname)
<Chipaca> mvo: yes
<mvo> bÃ¤Ã¤Ã¤
<ogra_> yup
<Chipaca> mea culpa, i broke that
<mvo> well, its the right thing to do :/
<ogra_> oh is that a function you control (doing the atomic write ?=
<Chipaca> yes
<Chipaca> well
<Chipaca> ogra_: it used to not do an atomic write at all
<Chipaca> ogra_: not even a sync
<Chipaca> maybe the right thing to do is to edit it in writable?
<ogra_> well, if we want to keep it we need to handle the file like the others in /etc/writable
<Chipaca> would that work?
<ogra_> i.e. copy it over at image build time and create a link
<Chipaca> i meant edit /writable/system-data/etc/default/watchdog directly
<Chipaca> mvo: ogra_: would editing that directly, from snappy config, be reasonable?
<Chipaca> and would the rename work with the mount
<Chipaca> augh
<Chipaca> mvo: or i just revert the atomicwrite
<Chipaca> and we think about what we've done
<mvo> Chipaca: directly editing /w/s-d/e/d/watchdog would work indeed
<mvo> Chipaca: lets do that for now, we need to re-investigate the writable paths system anyway before 16.04
<Chipaca> mvo: i'm not sure it'll work
<ogra_> mvo, Chipaca http://paste.ubuntu.com/12893223/
<ogra_> that should work
 * Chipaca hugs ogra_ 
<ogra_> i assume we want that in stable too ?
<Chipaca> mvo: editing it in /writable doesn't work because the file is the thing mounted, by inode. New file -> new inode
<Chipaca> mvo: afacit at least
<mvo> ogra_: thanks
<mvo> Chipaca: uh, you are right of course
<Chipaca> ogra_: let me check the others i switched over to atomic, just in case
<ogra_> well, it would work if you made the whole dir writable ... but that means all /etc/default files become writable which isnt so great
<Chipaca> ogra_: the timezone file, the network files (interfaces and pp), the modprobe file, the modules-load file, the watchdog file, and the hostname file
<ogra_> intefaces has the whole dir writable
<ogra_> modprobe stuff too
<Chipaca> mvo: we still need a branch for this
<ogra_> hostname and timezone are already handled
<Chipaca> mvo: (on it)
<ogra_> so we shoudl eb fie
<ogra_> *shouold be
<Chipaca> ogra_: but the timezone file is not written to /etc/writable
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ ls /etc/writable/
<ogra_> hostname  localtime  timezone
<ogra_> my install disagrees :)
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ ls -lh /etc/timezone
<ogra_> lrwxrwxrwx 1 root root 17 Jul 24 16:36 /etc/timezone -> writable/timezone
<Chipaca> ogra_: yes, but when you set it, it's written to /etc/timezone directly
<ogra_> which is a link
<Chipaca> ogra_: which means the atomic code will try to create /etc/timezone.somecrap
<ogra_> no, it should do the atomic write in /etc/writable
<ogra_> (this is why we have that dir at all :) )
<Chipaca> ogra_: what about localtime?
<ogra_> we should have called it /etc/atomic insztead, to make the purpose more clear ;)
<ogra_> same thing
<ogra_> as well as hostname
<Chipaca> ogra_: and watchdog.conf
<ogra_> the filesystem takes care here
<ogra_> ah, not only the /etc/default/watchdog file ?
<ogra_> ok, adding
<Chipaca> ogra_: i think that covers it
<ogra_> good
<ogra_> uploaded to the PPA for wily ... now doing stable
<Chipaca> mvo: https://code.launchpad.net/~chipaca/snappy/use-etc-writable-for-atomics/+merge/275302
<mvo> Chipaca: thanks
<ogra_> stable uploaded too
<mvo> ogra_: \o/
<Chipaca> interesting that the bbb tests caught this and not the kvm ones
<ogra_> http://themcphails.uk/snappy.jpg
<ogra_> :)
<ogra_> Chipaca, errr
<ogra_> no
<Chipaca> ogra_: no?
<ogra_> you want to edit the original places
<ogra_> the filesystem should care for the rest
<ogra_> dont edit in /etc/writable
<Chipaca> ogra_: buh.. buh... ?
<ogra_> your atomic write should follow the link before doing the backup copy
<ogra_> and the filesystem should manage that for you, so there should eb no need to touch /etc/writable directly
<Chipaca> siiigh
<mvo> Chipaca, ogra_: I'm not sure if our code is doing that, I think it would replace the link (but thats from memory only)
<ogra_> (at least all other writin tools do it like rthat ... this setup comes from the phone where it exists since years )
<Chipaca> mvo: it isn't, but it should perhaps
<ogra_> it definitely should
<ogra_> everythjing else does
<Chipaca> mvo: so, abort, abort, etc
<mvo> done
<Chipaca> mvo: tarmac didn't care and merged it anyway. NEver mind, follow up branch will revert.
<Chipaca> mvo: https://code.launchpad.net/~chipaca/snappy/atomic-follow-symlinks/+merge/275310
<ogra_> looks good
<fgimenez> Chipaca, first boot works fine in bbb too, now running the suite
<ogra_> fgimenez, no mopre missing address ?
<fgimenez> ogra_ iirc that was happening on rolling only, let me check
<ogra_> it could be the same cause
<fgimenez> ogra_, yes, rolling/edge https://bugs.launchpad.net/snappy/+bug/1503329, i'll try the fix there too
<ubottu> Launchpad bug 1503329 in Snappy "not getting an ipv4 address on the first boot" [Critical,Confirmed]
<ogra_> fgimenez, though it could also be the double UID (for dnsmasq vs tss) which would be fixed in the next image
<ogra_> especially if it is rolling only ... only rolling has this UID bug
<fgimenez> ogra_, ack thanks
 * ogra_ sighs about the RPi devicetree issues :/
<ogra_> mvo, please remind me that we talk about that once the release is out ... ^^^
<mvo> ogra_: ok
<mvo> Chipaca: thanks!
<Chipaca> augh
<mvo> Chipaca: more crisis?
<mvo> hm, apparently
<Chipaca> mvo: :)
<Chipaca> or :-/
<Chipaca> depending on the flavour of your cynicism
 * mvo hugs Chipaca
<mvo> all good
<Chipaca> mvo: there's an explicit test for us not following symlinks there
<mvo> Chipaca: geh
<mvo> Chipaca: let me check that, I wonder why
<mvo> Chipaca: I have some vague memory why this might be useful to not follow symlinks
<Chipaca> mvo: security, usually
<mvo> Chipaca: yeah, I think so, I think it came up as part of the recent click issue
<Chipaca> mvo: for example :)
<mvo> Chipaca: hmmmmmmmmmmmm, so indeed we added this recently as a result of click issue
<Chipaca> yep
<mvo> Chipaca: so lets not merge it and use /etc/writable and look into this after the reelease again
<mvo> Chipaca: its a mess anyway
<mvo> Chipaca: or do you have an alternative suggestion :) ?
<Chipaca> mvo: adding a flags parameter to AtomicWriteFile, which defaults to nofollow
<mvo> Chipaca: even better
<Chipaca> mvo: updated lp:~chipaca/snappy/atomic-follow-symlinks if you want to take a look
<mvo> Chipaca: done, thanks again
<mvo> fgimenez: r223 for amd64 is ready, if you could give this a early testrun
<mvo> elopio: -^
<mvo> I will build arm/i386 too now
<fgimenez> mvo, thanks on it
<mvo> thank you!
<fgimenez> mvo, the watchdog config test is still failing with a different error now "Error: open /etc/default/writable/default: no such file or directory"
<mvo> fgimenez: aha, thanks. let me check
<mvo> Chipaca: -^
<mvo> or maybe ogra_ ---^ ?
<ogra_> hrn
<ogra_> yeah, that might be  wrong link ...
<mvo> http://paste.ubuntu.com/12894264/
<ogra_> hmm, no, that looks right
<ogra_> how does /etc/writable look like ?
<mvo> ogra_: http://paste.ubuntu.com/12894275/
<ogra_> looks fine too
<mvo> ogra_: that looks right? isn't there a "/" missing in the first one?
<ogra_> oooh !!
<ogra_> no
<ogra_> there would be a ../ missing
<ogra_> damned
<ogra_> that needs more logic in livecd-rootfs :/
<ogra_> will fix after meeting
<mvo> ta
<elopio> fgimenez: why don't you do a show and tell on the next ubuntu summit?
<fgimenez> elopio, well, i doubt i have anything interesting to show or tell ;)
<elopio> I think it would be cool to show the integration suite on kvm. But maybe the stuff you did on snappy-tests-job, or some other cool thing you liked.
<elopio> fgimenez: it doesn't have to be a full hour. I'd be interested also in things like the api test suite, or the cli one, or the failover tests.
<elopio> balloons: help me out here :)
<fgimenez> elopio, ok i'll have a look, are you going to do something for the summit?
<balloons> fgimenez, definitely! You can demo something for 5-10 mins and take a couple questions. It can be really quick if you wish
<elopio> fgimenez: no. I prefer to help you with yours, if you need a hand.
<ogra_> mvo, http://paste.ubuntu.com/12894355/ does that look ok to you ?
<mvo> ogra_: yes, thank you
<ogra_> (assuming we might get more files in /etc/default to be writable one day)
<ogra_> uploading then
<elopio> fgimenez: any chance you have an old 15.04 edge around? like #142?
<fgimenez> balloons, elopio ok thanks, let's see if there's something interesting enough (or at all :) in all this stuff..
<fgimenez> elopio, nope, i've seen the bug, maybe from old stables?
<elopio> fgimenez: I'll try re-updates from different stables. If the bug doesn't happen there, then it's not important.
<fgimenez> elopio, sgtm
<elopio> fgimenez: have you confirmed if Chipaca's fix solves the problem?
<fgimenez> elopio, yes, eth0 is up on first boot for both amd64 and bbb, it's already included in r223
<elopio> cool. Then I'll go and take a walk with the dog while the automated suite runs here.
<fgimenez> elopio, haven't tried it yet on rolling/edge bbb, maybe it solves the ipv4 issue too
<elopio> bbs
<elopio> fgimenez: ah, I'll leave that one flashing and check.
<elopio> fgimenez: hey, btw, I started getting tls handshake timeouts when doing u-d-f.
<elopio> I still think that's a problem in the store servers. Just not sure what to do about it to prove it.
<fgimenez> elopio, from udf too? i think i saw that some time ago, yes, it seems to be a problem of the store
<Chipaca> ogra_: mvo: status update wrt symlinks plz (but no rush)
<ogra_> Chipaca, fix is in the PPA ... waiting for promotion and new image
<Chipaca> neat-o
<Chipaca> i'll go get myself a cuppa tea then
<kgunn> tedg: hey so, made some good headway last night on the mir yaml, but wondering...at least one of the paths wanted arch specific input, is there a way to late bind that in the yaml ? so it'd insert whatever arch your building on?
<tedg> kgunn: No, I don't think we have anything for that.
<tedg> kgunn: One design floating around had variables, but I don't think they've made it to a final design.
<tedg> kgunn: We need to do some more thinking around cross-building and architectures, we're weak there right now.
<kgunn> tedg: ok..understood
<kgunn> just felt naughty
<tedg> kgunn: In a good way? ;-)
<kgunn> lol
<kgunn> no, most definitely not
<ogra_> new stable image building
<ogra_> fgimenez, elopio ^^^ with a fix for /etc/default/watchdog
<ogra_> Xenial-changes Subscription results
<ogra_> Your subscription request has been received, and will soon be acted upon....
<ogra_> :D
<elopio> fgimenez: I'm getting an error on the config test: open /etc/default/writable/default: no such file or directory
<ogra_> elopio, yes, thats is what we are doing the current re-spin for
<ogra_> 225 should be fixed
<elopio> ogra_: oh, I thought that was already on 225.
<elopio> sorry, on 224
<ogra_> aaand ... 225 hit the system-image server this second :)
<ogra_> so happy testing :)
<elopio> ok good, the tests work :)
 * elopio u-d-fs
<ogra_> let me know how it goes ... i *belive* it is fixed ... but religion might not help here ;)
<elopio> I bet religion will just make it worse ;)
<ogra_> heh, yeah
<fgimenez> elopio, ogra_ it still fails for me "Error: rename /etc/writable/watchdog.conf.HGxhokjLnsKB /etc/writable/watchdog.conf: device or resource busy"
<ogra_> huh ?
<ogra_> thats a different file though
<ogra_> Chipaca, ^^^ did your atomic write fix not land yet ?
<ogra_> "device or resource busy" is also a very interesting error message here
<elopio> Error: rename /etc/writable/watchdog.conf.elXUoCIALnmQ /etc/writable/watchdog.conf: device or resource busy
<elopio> same here.
<ogra_> yeah
<ogra_> so the fix for /etc/default/watchdog works ...
<ogra_> but we are back at the initial error from this morning
<ogra_> weird
<ogra_> i thought Chipaca's fix had landed already
<Chipaca> ogra_: that looks like the one with my fix
<ogra_> so why do we get that weird error ?
<Chipaca> "device or resource busy" is not the error from this morning
<Chipaca> because
<Chipaca> it's still mounted
<Chipaca> i'd wager
<ogra_> why would it not be mounted
<Chipaca> ogra_: i mean, we used to mount /etc/watchdog.conf
<ogra_> ooooh !
<ogra_> crap
<Chipaca> oooh.
<Chipaca> :)
<Chipaca> ogra_: only guessing, but that's what i'd look at, myself
<ogra_> yeah
<ogra_> nobody updated ubuntu-core-config
<Chipaca> silly nobody
<ogra_> uploaded (for vivid yet)
<fgimenez> leaving, good evening o/
<ogra_> bah, and i cant land it for wily
<ogra_> oh, i can
<ogra_> hah
<ogra_> ok, wily fix uploaded too
<seb128> wah, nobody fixed 1.6 so wily released with 1.5?
<ogra_> seb128, seemingly slipped through, we'Re all super busy doing a release :)
<Chipaca> off to a parents' evening, will bbl
<ogra_> elopio, 226 building
<elopio> testing 226 now
<ogra_> yay, thanks
 * ogra_ was about to ping that it is done :) 
<elopio> ogra_: Chipaca: the test now passes. Trying the rest.
<ogra_> YAY !
 * ogra_ relaxes 
<elopio> ogra_: oh, don't relax. I have food for thought for you: how can we put a regression test that doesn't require us to regenerate an image to check it?
<ogra_> elopio, well, you could replace the changed parts if yu know exactly which are the ones ... but that only works if neither initrd nor firstboot is involved
<ogra_> (and indeed if it isnt bootloader or kernel stuff)
<ogra_> in the watchdog case this wouldnt have helped
<elopio> ogra_: where can I see what you changed to fix it?
<ogra_> usually in the MPs but for certain packages like livecd-rootfs or ubuntu-core-config you can only see it in the package diff of the PPA
<ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages ... if you expand either of the "ubuntu-core-config" packages on that page there is a diff below
<elopio> I see. This is pretty hard, because it's not like an api that snappy consumes.
<ogra_> yeah, thats plumbing ...
<elopio> ogra_: will this core-config be a snap eventually too?
<ogra_> what you can definitely look at is http://people.canonical.com/~ogra/core-image-stats/
<ogra_> no, its one of the debs we create the rootfs from
<ogra_> the rootfs will become a snap but not the parts used to build it
<ogra_> for 226 the changelog is http://people.canonical.com/~ogra/core-image-stats/vivid/20151022.5.changes
<elopio> ogra_: so this goes back to being able to create a rootfs on demand. Once we build it, we can plug it into an existing image and check.
<elopio> not perfect, but will reduce the feedback time.
<ogra_> elopio, well, why not generate a complete image then ?
<elopio> ogra_: I guess you are right. But we need to isolate the changes as much as possible.
<elopio> maybe we can make a contract between snappy and what ubuntu-core-config produces. And then test just that.
<elopio> anyway, I think that the next step would be to generate a complete image, as you say.
<elopio> ogra_: what's wrong with this? http://pastebin.ubuntu.com/12896455/
<elopio> I don't understand the error.
<mvo> elopio: hi, so whats the status? how is the imgae looking?
<mvo> ogra_: or you maybe, how is the image looking?
<elopio> mvo: all good with kvm, already a couple of full successful runs + exploring.
<elopio> tests are currently running on bbb and rpi.
<elopio> mvo: I think we are good to publish to alpha to test the upgrade and rollback
<mvo> elopio: excellent, let me do that then
<elopio> mvo: so, will you trigger staging tomorrow?
<elopio> and who should we notify to get the cert team testing alpha?
<mvo> elopio: I can stay up some more to release today, depends a bit how long the test runs will take
<mvo> elopio: and when its stable I will tell the cert guys to use it (thats how we usually do it)
<mvo> elopio: amd64/armhf/i386 ready in alpha
<elopio> mvo: great. I'll download and flash
<mvo> elopio: thanks, just keep me updated, I will be around for ~1h at least, otherwise I will continue (early) in my morning
<ogra_> mvo, its all fine (like elopio said) ... had to do a re-spin because we forgot to drop the watchdog stuff from ubuntu-core (so it was still bind mounted)
<mvo> ogra_: aha, thanks
<elopio> mvo: tested alpha 14 -> 15, rollback, update again, and then the full suite on kvm
<elopio> the boards in progress. But that's a lot slower. Things look good.
<mvo> elopio: yay, thanks
<elopio> I think last time ricmm told us to notify the chinese team to test the alpha before the release, but I'm not sure about that part of the process.
<mvo> elopio: let me ask
#snappy 2015-10-23
<dholbach> good morning
<fgimenez> good morning
<mvo> hey fgimenez, good morning
<mvo> ogra2: hi, around?
<mvo> or ogra_
<fgimenez> hey mvo
<mvo> fgimenez: could you please add a card that we add  a integration test that basicly checks for "systemctl status | grep State: degraded"? It looks like opencryptoki is failing right now
<mvo> hey dholbach, good morning!
<mvo> dholbach: are you at ubucon already?
<mvo> dholbach: did you guys had a great release party?
<dholbach> mvo, nope - it's starting tomorrow
<mvo> aha, ok
<dholbach> mvo, there's a social event tonight though
 * mvo nods
<dholbach> so there'll be time for everyone to have some of their favourite beverages
<mvo> sounds like a lot of fun
<fgimenez> mvo, sure! :) we have already some tests that query systemctl status, should we be waiting/polling for that condition?
<mvo> fgimenez: well, we want to make sure that it does not boot into this degraded mode, i.e. that no unit fails :) pardon my ignorance on how the integration test for systemctl status works right now, I would (naively) assume that after you waited for boot-ok and before rebooting would be a good time to check that no unit failed
<fgimenez> mvo, indeed, currently we ask systemctl for status of restarted services, for instance, in which case makes sense to wait for the service to be up. As you say after booting we can assert that all the units are ok
<mvo> fgimenez: great, thanks a bunch
<davidcalle> morning o/
<Chipaca> mvo: hoe gaat het?
<JamesTait> Good morning all; happy Friday, and happy Mole Day! ð
<Chipaca> JamesTait: also happy UN day!
<JamesTait> Chipaca, do they make holes in your lawn as well?
<Chipaca> JamesTait: I'm not sure. Bosnia made me think they do.
<Chipaca> JamesTait: but that might have been all the other guys doing the holes and UN trying to fill them
<mvo> Chipaca: hey, not too bad, one glitch in the release with opencryptoki, otherwise all good
<mvo> Chipaca: how are you?
<Chipaca> mvo: relaxed :)
<Chipaca> perhaps prematurely :D
<mvo> great!
<mvo> no, all good
<ogra_> mvo, on my way out ... whats up ?
<mvo> ogra_: I was wondering how important opencryptoki is
<mvo> ogra_: but no worries, drive, I have it all under control
<ogra_> it was part of the reqs for the encryption
 * mvo nods
<ogra_> you gotta ask ricmm
<dholbach> mvo, snapcraft is just used for app snaps, right?
<dholbach> so documenting meta/package.yaml for let's say gadget snaps still makes sense
<mvo> dholbach: it does, yes. long term this may change though
<dholbach> ok, thanks
 * Chipaca goes for lunch
<tedg> dholbach: I think that it is being used for the Mir framework snap
<tedg> dholbach: It doesn't provide any help there, but also won't get in the way.
<dholbach> tedg, hum...
<dholbach> tedg, I can't quite remember what you're referring to right now O:-)
<tedg> dholbach: Sorry, didn't read the timestamps, just the last few messages :-)
<tedg> dholbach: About snapcraft only doing app snaps.
<dholbach> oh ok
<dholbach> thanks
<dholbach> do we have any docs on how to sign snaps or is this something we say just the store does?
<elopio> fgimenez: there was already a card for that: https://trello.com/c/kyipW838/260-add-a-test-to-check-that-no-service-failed-to-load
<elopio> we can just drop this one and keep the new one.
<fgimenez> elopio, sorry didn't know. ok, we can keep any of them, the check proposed by mvo would catch any service not being loaded
<elopio> fgimenez: and we are upstream, finally \o/ https://github.com/testing-cabal/subunit-go
<fgimenez> elopio, great! \o/
<elopio> now that niemeyer is working with us, it might be easier to get better integration with go check.
<fgimenez> elopio, i've archived the new card about the services and added a comment with the check to the existing one
<elopio> fgimenez: ok. And about scalignstack, we were sooo close, but now we are back to convincing people why we need them :(
<fgimenez> elopio, yep, i've seen, some day maybe... :) it seems that we are back to square one, but they haven't responded yet to your last email, let's see
<noise][1> where can I find the source for the pi2 snap from http://people.canonical.com/~platform/snappy/raspberrypi2/ ?
<noise][1> ogra_: you were building these images right?
<elopio> noise][1: ogra is travelling to a conference today. If you only need the source, just open the snap with file-roller.
<elopio> or do you need to do something in the repository?
<noise][1> elopio: did that, but then found that the package.yaml doesn't include webdm and now i'm wondering precisely how those images are rolled
<noise][1> basically I want to be able to duplicate the released image so I know i'm starting from a good place, then make some mods
<elopio> noise][1: like this? https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/
<elopio> udf takes all the snaps, and combines them. You can pass a local snap in --oem.
<elopio> udf takes all the snaps, and combines them. You can pass a local snap in --oem.d0n_pa!a\/ra*
<dholbach> all right my friends - I call it a day - see you all on Monday!
<elopio> bye dholbach. Enjoy the weekend.
<dholbach> you too
<dholbach> still need to prepare my demo for Ubucon DE :)
<dholbach> see you :)
<noise][1> elopio: that page just isn't clear exactly what is used to create the images because they have webdm but it's not part of the oem snap, so I'm assuming it's done via u-d-f's âinstall webdm.canonical, but wanted to get confirmation of that
<elopio> noise][1: I suppose you are right, but can't confirm.
<noise][1> when i tried that, webdm didn't seem to start, but i'm still working through this so it's quite possible i just did something wrong
<jdstrand> hmm
<jdstrand> Chipaca: hey, I see bug #1498842. I just uploaded snappy-debug 0.3 to the store and snappy update isn't detected it. I had 0.2 installed. snappy-debug has a store alias of 'snappy-debug'
<ubottu> bug 1498842 in Snappy "Packages without aliases don't get updates" [Critical,Fix committed] https://launchpad.net/bugs/1498842
<jdstrand> Chipaca: so it seems I am seeing the inverse of that bug. ie, a package with an alias isn't updating
<jdstrand> Chipaca: seeing this on stable r9 and edge r229. file a bug?
<Chipaca> jdstrand: try again?
<jdstrand> Chipaca: I tried 5 times
<Chipaca> echo '{"name":["snappy-debug.canonical"]}' | POST -H 'Accept: application/json' -H 'X-Ubuntu-Frameworks: ubuntu-core-15.04-dev1' -H 'X-Ubuntu-Architecture: amd64' -H 'X-Ubuntu-Release: 15.04-core' 'https://search.apps.ubuntu.com/api/v1/click-metadata'|jq .
<Chipaca> jdstrand: ^ that's what snappy does
<jdstrand> snappy search sees it and I can install it
<Chipaca> jdstrand: I see 0.3 here
<jdstrand> yes
<jdstrand> so do I
<jdstrand> but snappy update doesn't install it
<jdstrand> I can search it fine, I can install it fine, it won't update
<jdstrand> $ snappy list|grep debug
<jdstrand> snappy-debug  2015-10-19 0.2          canonical
<jdstrand> $ sudo snappy update
<jdstrand> $
<jdstrand> $ snappy list|grep debug
<jdstrand> snappy-debug  2015-10-19 0.2          canonical
<Chipaca> jdstrand: snappy list -u ?
<jdstrand> $ snappy search snappy-debug|grep debug
<jdstrand> snappy-debug          0.3                snappy-debug
<jdstrand> ~$ snappy list -u
<jdstrand> Name          Date       Version
<jdstrand> ubuntu-core   2015-10-23 9
<jdstrand> hello-world   2015-10-01 1.0.18
<jdstrand> minecraft     2015-10-10 0.4
<jdstrand> snappy-debug  2015-10-19 0.2
<jdstrand> ufw           2015-10-12 IDDaHcdMFHdS
<jdstrand> generic-amd64 2015-09-30 1.4
<Chipaca> nessita or matiasb, you guys around?
<jdstrand> Chipaca: just for perfect clarity-- snappy-debug has a store alias
<Chipaca> jdstrand: and it's a framework
<jdstrand> no, it isn't
<Chipaca> jdstrand: ok
<nessita> yes
<Chipaca> nessita: hola! Can i pester you with a question about cpi?
<nessita> of course
<jdstrand> Chipaca: it started as one, but we changed that. 0.2 was not a framework and neither is 0.3
<Chipaca> nessita: jdstrand has a snap at version 0.2, published 0.3, but snappy update can't find it
<Chipaca> nessita: but
<Chipaca> nessita: the url snappy update hits returns 0.3
<Chipaca> nessita: so i'm missing something :-/
<nessita> Chipaca, let me check the store data
<Chipaca> nessita: thanks
<nessita> Chipaca, snappy-debugis the package name?
<Chipaca> nessita: .canonical
<nessita> from myapps 0.3 should be published in every channel, debugging further
<nessita> Chipaca, what would mean "snappy can't find it"? I see the metadata OK (https://search.apps.ubuntu.com/api/v1/package/snappy-debug.canonical) perhaps you can't download?
<Chipaca> nessita: well, search works and finds 0.3, so i assume it's not that
<Chipaca> nessita: if nothing jumps out at you, never mind
<Chipaca> i'll dig into this later
<Chipaca> jdstrand: bug time!
<nessita> Chipaca, what is weird is that browsing https://public.apps.ubuntu.com/download/canonical/snappy-debug.canonical/snappy-debug.canonical_0.3_all.snap I get nothing
<nessita> Chipaca, so let me check our package storage status
<Chipaca> jdstrand: hold off on the bug :)
<nessita> Chipaca, so https://public.apps.ubuntu.com/download/canonical/snappy-debug.canonical/snappy-debug.canonical_0.3_all.snap is giving 401
<nessita> Chipaca, so it requires auth, so somehow is not matching criteria for "allow unathenticated". Let me dig more.
<Chipaca> jdstrand: you haven't paid your store subscription! I'll transfer you to accounts. Please hold.
<nessita> Chipaca, in any case, while I debug, the snappy install should check return codes when downloading a package, to help debugging
<nessita> (and do retries on network errors)
<nessita> just mentioning in case you can build ToDos
<Chipaca> nessita: looking at the code i'd tell you it does report errors
<Chipaca> so if this is because a 401, somehting's awry
<Chipaca> but it's not even that
<Chipaca> because it'd print "Updating <package>..."
<Chipaca> but it's not even getting that far
<nessita> Chipaca, any chance you can try to pin point where is failing in that end?
<Chipaca> the only thing i can see where it would fail silently like this
<Chipaca> is if the store is returning json that doesn't fit into the expected struct
<nessita> Chipaca, ok, so enigma solved for the 401, we need to use the anon URL
<nessita> Chipaca, so I would say nothing stands out in our end
<Chipaca> nessita: thanks
<nessita> Chipaca, let me know if you can detect the exact point of failure to debug our end
<Chipaca> jdstrand: file a bug, i'll dig on monday
<jdstrand> Chipaca: ok
<jdstrand> Chipaca: https://bugs.launchpad.net/snappy/+bug/1509451
<ubottu> Launchpad bug 1509451 in Snappy "snappy update is not updating snappy-debug" [Undecided,New]
<Chipaca> umm
<Chipaca> jdstrand: it just udpated for me, fwiw
<Chipaca> so.
<Chipaca> augh
 * Chipaca should leave
<Chipaca> jdstrand: i installed a fake 0.2, and snappy updated it to 0.3
<Chipaca> jdstrand: is this a vm?
<Chipaca> jdstrand: if it is, please preserve the disc image
<jdstrand> Chipaca: it isn't a test vm
<Chipaca> jdstrand: any chance you can make an image of the disc?
<Chipaca> for monday
<Chipaca> i'm out
<Chipaca> o/
<jdstrand> Chipaca: well, not trivially. ping me on monday and we'll work something out
#snappy 2015-10-25
<gartral> hey all, I'm finally getting around to playing with snappy, and i got to say, i'm loving it so far! but I ran into a snag... I installed a snap "system-status.victor" and I have NOOOO clue what port it runs on! any command I can issue to discover that?
<gartral> hey all, I'm finally getting around to playing with snappy, and i got to say, i'm loving it so far! but I ran into a snag... I installed a snap "system-status.victor" and I have NOOOO clue what port it runs on! any command I can issue to discover that?
<miken> gartral: let me see if I can find out...
<miken> Hi gartral . Did you install system-status.victor from the store (I don't see it, but do see other apps by the author - wunderground.victor, but perhaps it's my location etc.). Anyway, just looking at the source for the system-status.victor package at http://bazaar.launchpad.net/~vthompson/+junk/system-status/view/head:/README
<miken> gartral: according to http://bazaar.launchpad.net/~vthompson/+junk/system-status/view/head:/main.go it's 8081
#snappy 2016-10-24
<not_MartinWimpre> woof
<mup> PR snapd#2204 opened: Allow hostnamed access for network-manager and bluez <Created by morphis> <https://github.com/snapcore/snapd/pull/2204>
<morphis_> mvo: ping
<mvo> morphis_: pong
<morphis_> mvo: you rested a bit over the weekend? :-)
<mvo> morphis_: yes, thank you! I feel much better
<morphis_> great!
<morphis_> mvo: I am wondering if we support BIOS-only systems today or just EFI ones
<mup> PR snapd#2072 closed: cmd/snap: have 'snap autoimport' consider unmounted devices <Created by mwhudson> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2072>
<mvo> morphis_: we do support both, I test regularly with the stock qemu which is bios only AFAIK
<morphis_> so using regular pc gadget for amd64 should give me BIOS support too?
<mvo> morphis_: correct
<mvo> morphis_: is that not working for you? or are you just curious :) ?
<morphis_> I tried to setup my HP Microserver Gen 8 with Ubuntu Core this morning but somehow it doesn't want to boot
<mvo> morphis_: hm, strange. what errors do you see?
<morphis_> but if general support is there then it must be something specific to the box
<mvo> morphis_: I have not tested it much on real HW, davmor2 has tested it on a laptop
<morphis_> mvo: it falls back to network-based boot on startup so somehow it doesn't detect the image on the USB stick
<mvo> morphis_: interessting
<morphis_> but let me check further
<mvo> ok
<mup> PR snapd#2201 closed: spread.yaml: Ensure ubuntu user has passwordless sudo for autopkgtests <Created by plars> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2201>
<mup> PR snapd#2205 opened: snap, image: fix `snap download` and `snap prepare-image` running as user <Created by mvo5> <https://github.com/snapcore/snapd/pull/2205>
<morphis_> davmor2: ping
<mup> PR snapd#2206 opened: docs: less details about cloud.cfg <Created by mvo5> <https://github.com/snapcore/snapd/pull/2206>
<morphis_> mvo: actually looks like the BIOS on the board can't boot the disk I get with the RC image, it works fine on my laptop though
<morphis_> mvo: it always says "no system disk or disk error"
<morphis_> mvo: also I am not sure to which degree gpt is the problem here
<mvo> morphis_: oh, indeed - gpt sounds like a likely issue
<morphis_> mvo: can I easily change that with a custom gadget?
<morphis_> never really looked into that part yet
<mvo> morphis_: I think so
<morphis_> hm
<morphis_> mvo: hm, this makes ubuntu-image pretty unhappy
<mvo> morphis_: what is the error
<morphis_> looks like it just is not really safe against giving incorrect values in gadget.yaml
<darrenwu> morphis_, How to enable wake_on_lan by network-manager? I got a "permission denied".   https://paste.ubuntu.com/23373570/
<morphis_> darrenwu: the best way to do this is to drop the netplan config file and configure ethernet directly through nm rather than via netplan
<morphis_> darrenwu: that is the only way currently but please file a bug
<darrenwu> morphis_, ok, I had filed a bug which on LP #1635122 already.
<morphis_> darrenwu: I am off today, but will look into this one tomorrow when I am back
<darrenwu> morphis_, thanks! Do I need to assign to you?
<morphis_> darrenwu: please
<darrenwu> morphis_, thx
<mup> Bug #1569892 changed: /etc/profile.d/apps-bin-path.sh comment talks about /snaps/bin (which doesn't exist) when in reality it uses /snap/bin <amd64> <apport-bug> <xenial> <One Hundred Papercuts:Fix Released> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1569892>
<rvr> ogra_: Good morning, do you have new images for the Pi and Dragonboard?
<ogra_> rvr, every day ;) http://people.canonical.com/~ogra/snappy/all-snaps/daily/
<ogra_> oh
<ogra_> not today it seems
 * ogra_ goes to check why
<ogra_> Building: /home/ogra/datengrab/images/snappy/daily/20161024/ubuntu-core-16-amd64.img
<ogra_> error: cannot find snap "pc": Get https://search.apps.ubuntu.com/api/v1/snaps/details/pc?channel=edge&confinement=strict: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
<ogra_> grr, network issue
<mup> Bug #1587477 changed: snapd should not use /tmp to unpack snaps on systems where /tmp is a tmpfs (and thus limited in size) <Snappy:Fix Released> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1587477>
<mup> PR snapd#2207 opened: store: check hash in store.Download() (if we have a hash) <Created by mvo5> <https://github.com/snapcore/snapd/pull/2207>
<ogra_> (building new ones now)
<rvr> ogra_: Ack :)
<ogra_> rvr, new dailies are up
<rvr> Wee!
<vigo> ogra_, great :)
<mup> PR snapd#2208 opened: store: add support to resume partial downloads <Created by mvo5> <https://github.com/snapcore/snapd/pull/2208>
<rvr> vigo: I don't get wifi connectivity on the Dragonboard. You?
<mvo_> ogra_: I put a new godd into the store that supports reading from stdin (and writing to stdout) via "-" as the magic filename. iirc you asked about this
<mvo_> ogra_: its in "edge" if you want to give it a go
<vigo> rvr, I'm not with db yet
<ogra_> mvo_, whee, will definitely do !
<mvo_> :) great, let me know and if it works for you I will promote to beta
<rvr> vigo: It is working after reboot
<rvr> Hmm
<vigo> rvr, cool
<rvr> vigo: It is not :-/
<rvr> I did a trick
<rvr> I plugged a USB to ethernet adaptor
<vigo> rvr, so does not work every fresh boot?
<ogra_> interesting, wifi always works for me on the dragonboard ... never on the pi3 though
<ogra_> (on first boot that is ... on second, they both work fine)
<rvr> Hi fgimenez :)
<rvr> ogra_: It's very weird. If the network credentials are introduced, console-conf saves them but doesn't apply it. However, after reboot, they are applied correctly.
<fgimenez> hey rvr
<ogra_> yes, that suonds indeed weird
<rvr> ogra_: and now snap list lists nothing
<ogra_> no error ?
<rvr> ogra_: https://pastebin.canonical.com/168739/
<rvr> Failed to get key ID_VENDOR_FROM_DATABASE from interface wlan0
<vigo> fgimenez, should we keep using your spread binary?
<ogra_> rvr, i meant for snap list
<fgimenez> vigo, spread's snap must work, if not you should talk with niemeyer
<vigo> fgimenez, ok have you the link to the spread doc you shared last week?
<vigo> I missed it
<rvr> ogra_: http://paste.ubuntu.com/23374088/
<fgimenez> vigo, mm about spread? not sure which document is that, the best source for spread info is its readme https://github.com/snapcore/spread, i shared a doc about image creation, the reference for image creation is available here https://github.com/CanonicalLtd/snappy-docs/blob/master/core/images.md
<vigo> fgimenez, thanks =)
<ogra_> mvo_, so is " xzcat img-file | godd - /dev/sdX " the right syntax ? (the godd help is rather cryptic)
<ogra_> (well, seems to have worked and not dd'ed over my harddisk ... :) )
<ogra_> hmm
<ogra_> [  OK  ] Reached target Login Prompts.
<ogra_> [FAILED] Failed to start Generate default network config.
<ogra_> See 'systemctl status snapd.generate-network-conf.service' for details.
<ogra_> pitti, ^^^ i get this with the first boot of todays core image on dragonboard ...
<ogra_> console-conf shows wlan0 fine though
<ogra_> ... but times out when trying to configure wlan0
<ogra_> rvr, are these the same symptoms you see ?
<pitti> ogra_: is there something I need to fix on my end to make this work?
<rvr> ogra_: Yes
<rvr> ogra_: It times out when trying to configure the network, but if you reboot, those credentials will be used and the net interface will show the IP in console-conf.
<ogra_> mvo_, that looks like some regression with network setup ... the dragonboard used to work last week
<ogra_> yeah, no way to get networking at all on dragonboard :(
<ogra_> thats really bad
<ogra_> even after reboots or re-starting console-conf
<vigo> fgimenez, still getting invalid error name with spread snap
<ogra_> pitti, i wish i knew ... but snapd.generate-network-conf.service is netplan, no ?
<pitti> ogra_: no
<ogra_> rvr, it didnt keep my credentials
<pitti> ogra_: snapd.* is snappy :)
<ogra_> pfft ... names ... as if anyone would read them :P
<ogra_> (sorry ... i could have guessed that)
<pitti> hehe
<pitti> ogra_: "nap" or "ystem", all the same
<ogra_> haha
<ogra_> yeah
 * ogra_ tries a pi3 image
<ogra_> doesnt find its wlan device at all :(((
<popey> ogra_: was there a bodge I can do on my pi3 to get snap working again?
<ogra_> popey, same as before ... fw_setenv to point to the right snap_core
<ogra_> but thats only a temporary workaround, i fear long term you need to re-flash
<popey> ok, will nuke it
<ogra_> the channel switching bug is supposed to be fised though, so it should not happen again
<popey> groovy
<ogra_> *fixed
<ogra_> hmm, so for me wifi times out on all devices in console-conf .... the pi3 finds its wifi device after reboot
<ogra_> (but i still cant configure it)
 * ogra_ checks what changed ... this used to work at some point
<popey> which edge image would you recommend for pi3 today?
<popey> :)
<ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/daily/
<ogra_> always "current" indeed :)
<popey> kk
<mvo_> ogra_: what is the error from "systemctl status snapd.generate-network-conf.service" ?
<ogra_> mvo_,no idea, i cant get into the runn8ing os at that point
<mvo_> ogra_: that is some new stuff that landed late (mostly morphis)
<ogra_> that error shows up before the "press enter"
<mvo_> ogra_: can you set "systemd.debug-shell" in the kernel commandline? or is that not possible with the dragonboard?
<ogra_> and only on very first boot
<mvo_> ogra_: this will give you a debug shell on tty7
<ogra_> i'll try ... might be a bit tricky since i need to poke the uboot.env directly
<ogra_> pi would be easier (cmdline is in a txt file) but that didnt expose the error
<ogra_> i see that subiquity network handline had a ton of changes on thu as well
<ogra_> from mwhudson
<ogra_> Oct 24 09:37:21 localhost sh[2084]: message repeated 29 times: [ sed: can't read /run/systemd/netif/leases/*: No such file or directory]
<ogra_> AHA !
<ogra_> Oct 24 09:32:39 localhost systemd[1668]: /lib/systemd/system-generators/netplan failed with error code 1.
<ogra_> hmm
<Elleo> jdstrand: heya, any idea if there are snappy equivalents for @{APP_PKGNAME} and @{APP_ID_DBUS}, all I could find was ${SNAP_NAME} which I could sort of mangle into a pkgname
<niemeyer> Hello all
<niemeyer> morphis: ping
<ogra_> Oct 24 12:32:25 localhost systemd[1]: Starting Network Service...
<ogra_> Oct 24 12:32:25 localhost systemd-networkd[1483]: Could not load configuration files: Permission denied
<ogra_> Oct 24 12:32:26 localhost systemd[1]: systemd-networkd.service: Main process exited, code=exited, status=1/FAILURE
<ogra_> Oct 24 12:32:26 localhost systemd[1]: Failed to start Network Service.
<ogra_> aha
<Son_Goku> niemeyer: good morning!
<ogra_> mvo_, hmm, looking at https://launchpadlibrarian.net/290433383/ubuntu-core-config_0.6.40+ppa18_0.6.40+ppa19.diff.gz ... are you sure that "sync" is actually in $PATH everywhere ?
<mvo_> ogra_: its in /bin
<ogra_> i know
<ogra_> i just see that all other lines in that script use a full path
<ogra_> might not be relevant though ...
<mvo_> ogra_: in a meeting right now, I have a look what the systemd default PATH is afterwards
<ogra_> mvo_, well, its perhaps a red herring ...
<ogra_> mvo_, on a sidenote ... godd works very nicely, promote it :)
<mvo_> yay
<ogra_> i have a slight suspicion ...
<ogra_>  def main():
<ogra_> +    os.umask(0o0077)
<ogra_>      opts = parse_options(sys.argv[1:])
<ogra_> that line in subiquity might make it impossible for systemd-networkd to read the configs
<mvo_> ogra_: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Environment%20variables%20in%20spawned%20processes fwiw
<mvo_> ogra_: autsch, thanks!
<mvo_> ogra_: i.e. PATH should be fine
<ogra_> yeah
<ogra_> i guess its the permission change ... though i'm not sure the umask has any influence on netplan which should be the one to write the actual systemd configs
<ogra_> heh, no, this is worse
<ogra_> so i just configured a dragonboard with USB eth0 plugged in ... selected "do not use" for eth0 and properly configured wlan0 as default interface ....
<ogra_> this is what i got on first login: http://paste.ubuntu.com/23374356/
<ogra_> seems console-conf never actually applies the chosen network settings
<ogra_> at least not without a reboot
<mvo_> ogra_: this is edge?
<ogra_> mvo_, yep
<ogra_> todays daily
<ogra_> the other thing is that /usr/lib/snapd/generate-network-conf only ever generates a setup for eth0
<ogra_>  /usr/lib/snapd/generate-network-conf runs before console-conf comes up ... this is why it works fine when i boot the dragonboard with eth0 attached but causes issues when only wlan0 is there
<ogra_> a...
<ogra_> ...ha !
<ogra_> sooo  ...
<ogra_> running "sudo /usr/sbin/netplan apply" after first logging in gets me the actually picked network configuration from console-setup
<ogra_> could it be that console-conf simply not calls "netplan apply"  ?
<davmor2> ogra_, mvo_: is there a way to only list snap names when using snap find?
<ogra_> like a --short option or so ?
<ogra_> i dont think so
<davmor2> ogra_: I wanted to write a script to install all the app for the letter e so snap find e however this will currently try and install everything for name version description and so on
<davmor2> ogra_: I can cobble something together probably
<ogra_> snap find e|cut -d' ' -f1|sed '/^Name$/d'
<ogra_> something like that would be a quick hack
<davmor2> ogra_: yeah I was thinking something similar to slice to get it
<rvr> ogra_: Nice detective work :)
<ogra_> rvr, well ... except that console-setup actually has code to run "netplan apply" ... not sure why it isnt executed though
<davmor2> ogra_: that work beautifully thanks :)
<ogra_> :)
<ogra_> ok ... running console-setup once ... unplugging the SD ... checking that the netplan config is correct ... booting afresh *and* making sure to configure the wlan part again, makes it work then
<ogra_> if i dont re-config the wlan settings, it will create an entry for the SSID without key
<rvr> ogra_: The image is still not resized in the Dragonboard
<ogra_> works fine here (and for everyone else)
<ogra_> rvr, we really need to find whats different in your setup, but all people i have asked to check it had no issues the whole week
<ogra_> so thats somehow specific to you ....
<ogra_> rvr, can you try flashing the SD from a desktop machine instead of the macbook ? perhaps it is related to that
<rvr> ogra_: I use a MacBook Pro as desktop instead of the Air as laptop, but same results :P
<ogra_> well, only you can repro it ... however you write the SD could be related here ... are both your machines running xenial ?
<rvr> Yup
<ogra_> mvo_, heh ... with the piping into godd it seems like the progress bar gets kind of confused ... does it only show read progress by default ?
<ogra_> (it seems to be very fast ... i.e. reading the input into ram)
<ogra_> (and then it sits silent for 1min before it returns to the prompt and is done)
<rvr> ogra_: On the Pi 2, it was resized correctly
<ogra_> interesting ... same SD ?
<rvr> Right
<ogra_> wow
<mvo_> ogra_: yeah, I need to fix the progress, it stats the "file" stdin and gets "0" so the progress looks quick, it really needs to do a spinner in this case
<ogra_> yep
<ogra_> hmpf ... rebooting the pi3 before console-setup is done gets me a hanging boot :/
 * ogra_ tries for the third time
<josharenson> What are some reasons that snapcraft register might fail?
<ogra_> the name could be taken already
<josharenson> ogra_: I
<josharenson> ogra_: I've tried several unique names...
<rickl_> Hello
<didrocks> josharenson: you are logged in, correct?
<didrocks> hey rickl_
<josharenson> didrocks: yes
<josharenson> didrocks: even tried that twice
<didrocks> what's the exact message? (can you try as well with --debug?)
<josharenson> didrocks: sure 1 moment
<rickl_> Does someone knows an Ubuntu Snappy webserver package?
<didrocks> rickl_: you have multiple examples embedding webservers as part of a bigger app
<josharenson> didrocks: http://pastebin.ubuntu.com/23374723/
<rharper> is there a reason why the core and pc snap are in the -rc image twice? http://paste.ubuntu.com/23374721/   got this from http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/current/
<josharenson> rickl_: I've used the one built into go, but that might not suit your needs
<ogra_> rharper, so that you can roll back
<rharper> ogra_: gotcha, cool
<ogra_> rharper, (admittely, after a fresh install you can only roll back to the same version :) )
<didrocks> josharenson: you are getting a forbidden 403, which may sounds like your credentials aren't recognized. Maybe when you tried to login again, you didn't logout in between? try: snapcraft logout && snapcraft login again to generated new macaroons (creds cache)
<rharper> the fresh install could possible not include those then ?
<ogra_> it includes them once and copies them on first boot afaik
<rickl_> I just need a small webpage with a shutdown button haha
<ogra_> mvo_ could explain that in detail i think
<rharper> ogra_: that's the image mounted up
<ogra_> ah, then ubuntu-image is already clever and does that
<rharper> I downloaded it, unxz, kpartx  the image file and then mount up partition3
<josharenson> didrocks: I'll try logging out, maybe even a few times.. I also filed lp:1636023 last night hoping that the error message can be more helpful :-)
<mvo_> rharper: we should hardlink those on the actual system, its on the list of things to fix but iirc its not done yet
<didrocks> josharenson: agreed, it should be more helpful :)
<rharper> mvo_: ok
<josharenson> didrocks: I get the same error :-/
<didrocks> josharenson: hum, we need to wait for the store team (like nessita) to be online I guess thenâ¦
<didrocks> unsure why you get a permission error
<josharenson> didrocks: ok, no worries
<mvo_> rharper: is it a big concern for you?
<didrocks> (added more info on your bug btw)
<rharper> mvo_: no; just looked odd to me because I didn't know why both were there
<rharper> mvo_: that and it seems like it could save some downloading
<xnox> mvo_, is it normal that $PATH is weird for sudo?
<xnox> http://paste.ubuntu.com/23374747/
<josharenson> didrocks: I think I got it... Since it was my first snap, I had never created a developer namespace. Registering my snap through the webUI asked me for a developer namespace, and then successfully registered my snap name
<ogra_> xnox, hmm, that was fixced in our sudo package a while ago
<rbnswartz> Is there anyway that I can allow a snap to access a drive besides using dev mode?
<xnox> ogra_, in xenial?
<ogra_> yeah
<xnox> ogra_, all packages are up to date for me :-(
<ogra_> xnox, check secure_path in /etc/sudoers
<didrocks> josharenson: oh, interesting, mind adding that to your bug report?
<ogra_> it should contain /snap/bin by default
<josharenson> didrocks: sure
<didrocks> josharenson: we want to have the whole workflow working from snapcraft only
<xnox> ogra_, does not have shnaps
<ogra_> xnox, hmm, i wonder if ucf got in your way here ... did you ever edit sudoers ?
<ogra_> (instead of using sudoers.d snippets)
<xnox> ogra_, Â¯\_(ã)_/Â¯
<kissiel_> ogra_: hey! do you know where I could find images for rpi3 that are proven to work?
<ogra_> ogra@anubis:~/datengrab/devel/packages/subiquity-0.0.20~xenial$ sudo grep secure_path /etc/sudoers
<ogra_> Defaults	secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
<ogra_> ogra@anubis:~/datengrab/devel/packages/subiquity-0.0.20~xenial$
<xnox> ogra_, i'll reinstall and will force configuration file reinstallation and see what happens.
<ogra_> kissiel_, if you can get along without wifi http://people.canonical.com/~ogra/snappy/all-snaps/daily/ has daily builds
<kissiel_> ogra_: definitely, thanks!
<ogra_> pitti, hmm, do you have much insight in how /var/lib/systemd/rfkill functions ? i have the feeling the missing file for the wlan device causes me to get no wifi offered on first boot (the file exists on second boot and i can see wlan0 on pi and dragoboard)
<cmars> hi, is there a guide on how to set up a CI build to automatically push to an edge channel for my snap?
<ogra_> cmars, you can tell launchpad to create your snap ... it has features to auto-submit to the store
<cmars> ogra_, it sources from github repos though.. is there a way i can delegate authority to a jenkins bot account to be able to push my snaps?
<xnox> ogra_, $ sudo apt -o Dpkg::Options::="--force-confask" install --reinstall sudo
<xnox> ogra_, fixed the world for me, I had an extra whitespace line in my sudoers.
<ogra_> oh my
<josharenson> Successfully published my first snap (hooray!). How long until it shows up via `snap find` (or is installable via the snap name)
<ogra_> should be pretty immediate after you clicked the publish button
<josharenson> humm let me double check that it actually published..
<josharenson> ogra_: not to be stupid, but all channels are searched by default?
<ogra_> only stable
<josharenson> ogra_: ah
<ogra_> snap install can take --edge/--beta etc ...
<ogra_> but find can not
<niemeyer> morphis: ping
<mup> PR snapd#2206 closed: docs: less details about cloud.cfg <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2206>
<niemeyer> joc_: ping
<mup> Bug #1636260 opened: make snappy executable on macOS <Snappy:New> <https://launchpad.net/bugs/1636260>
<mmphosis> help
<mmphosis> anyone here?
<dasjoe> niemeyer, asac: I sent an email a few days ago to snapcraft-owner@, about how lists.snapcraft.io breaks dmarc for some users
<pitti> ogra_: I don't know/remember details, but AFAIR this just saves/restores the rfkill state on shutdown/boot -- so if it's not there at all, the state shouldn't be changed; is it blocked in 'sudo rfkill list'?
<Croepha> you guys ever get a message from snap like "cannot set next boot: cannot determine bootloader" ?
<perrito666> nite all, coulkd anyone give me a hand with this? https://launchpadlibrarian.net/290730459/buildlog_snap_ubuntu_yakkety_i386_caddy_BUILDING.txt.gz
<perrito666> I have no clue why its pulling a ppa for snappy
#snappy 2016-10-25
<mup> Bug #1616833 changed: need new interface: time-hardware <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1616833>
<mup> Bug #1616833 opened: need new interface: time-hardware <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1616833>
<liuxg> does anyone know a configure hook example for snappy? I want to make use of it in my project. thanks
<liuxg> didrocks, ping
<didrocks> hey liuxg
<dholbach> good morning
<didrocks> liuxg: do you run snapd master?
<didrocks> you need it to have configure hook support
<didrocks> hey dholbach
<dholbach> salut didrocks
<liuxg> didrocks, it was nice to meet you there in Netherlands.  yes, I just read the doc at https://github.com/snapcore/snapd/blob/master/docs/hooks.md. it was not so clear to me.
<didrocks> liuxg: yeah, it's not in the current xenial snapd version, but will be in next release
<liuxg> didrocks, what should I do in the snapcraft.yaml file? How to implement it in practice? should I create a directory like the "setup" in for the desktop file? or I need to do sth in the snapcraft.yaml file?
<liuxg> didrocks, the document is not clear to me, and I think it may be confusing to others as well.
<didrocks> liuxg: documentation remarks is for davidcalle :)
<didrocks> liuxg: but you can contribute to them as well!
<didrocks> liuxg: you were in the session about hook and snapcraft IIRC
<didrocks> as told there, nothing is supported yet
<liuxg> didrocks, yeah, I know. if I know how to do it, I can definitely contribute to it.
<liuxg> didrocks, ok. then it is clear to me.
<didrocks> for now, the only thing right now is to ship a "configure" file in the correct place
<didrocks> and it will be executed
<liuxg> didrocks, I see. thanks
<didrocks> liuxg: then snap set <snap_name> key value will execute it
<liuxg> didrocks, I think I can use "dump" to set the file into the right place. do you mean that the current snapd does not support it yet, right? if this is the case, I have no way to test it.
<didrocks> liuxg: IIRC, there was a piece missing for the current snapd to execute it (I didn't test it myself). You can compile master git version and replace your snapd with it though
<didrocks> liuxg: yeah, dump plugin is possible
<didrocks> liuxg: I'll spend some times in the following week to provide an example and shape best practices FYI
<liuxg> didrocks, ok. I'll try it to see how it goes.
<liuxg> didrocks, that would be cool :)
<didrocks> liuxg: keep me posted! ;)
<didrocks> yep
<mup> Bug #1636383 opened: autoupdate.md needs an update <snap-docs> <Snappy:New> <https://launchpad.net/bugs/1636383>
<didrocks> we need best practices to have all hooks similars
<liuxg> didrocks, yes, definitely
<liuxg> didrocks, I used to use config to do that in 15.04
<didrocks> right! It's not that different
<zyga> o/
<liuxg> didrocks, I did not update the snapd, when I tried to configure my hello example. it complained that "- Run configure hook for hello (cannot snap-exec: cannot find hook "configure" in "hello")". The configure file is located inside the package http://paste.ubuntu.com/23377809/
<didrocks> liuxg: yeah, so I guess you need latest tip master
<liuxg> didrocks, I think I might need to wait for the latest snapd. interestingly, it did search for the hook.
<morphis_> mwhudson: you know when subiquity 0.20 will land in xenial-updates?
<ogra_> morphis_, it is in the image PPA since friday
<ogra_> so in all recent core snaps
<ogra_> morphis_, i also dont see any upload to xenial at all for 0.20 beyond this
<mvo> ogra_: hey, how are things looking today on pi2/pi3/dragon - anything new? or still network issues? if so, what are the details? just wifi or wired as well?
<ogra_> mvo, only wifi ... though ewhen you try to config wifi the whole network setup breaks (cant configure wired anymore, needs reboot)
<ogra_> mvo, it seems also that console-conf never actually applies the changed config (i get the default network setup that was applied during boot before console-conf ran unless i call "netplan apply" or do a reboot)
<ogra_> so it looks like two issues ... wifi ... and applying the config without reboot
<mvo> ogra_: hmm, ok. do we have bugs for this yet? if so, I will add them to trello to ensure we have it as a blocker
<ogra_> beyond this, there is still the slowness when creating the user that i try to dig down since a while
<mvo> ogra_: thanks! so wifi means its not possible to configure it at all? or does it crash?
<ogra_> both ...
<ogra_> it is not possible at all ... if you then restart the network config often enough you finally get a traceback (10-20x)
<mvo> hrm hrm
<ogra_> (but i guess most people reboot before they get into that area to actually see a crash, since you cant really do anything)
<mup> PR snapd#2209 opened: interface hooks: confirm plug slot hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/2209>
<ogra_> there is definitely interaction issuesbetween netplan and console-conf on some layer ...
<ogra_> what seems to work is: configure with wired interface, reboot and then run sudo console-conf again, that actually lets you re-configure to use wlan only
<ogra_> there is something in the firstboot that plays into the wlan issue here ... on second boot the interface is there
<ogra_> (all very obscure)
<ogra_> mvo, bug 1632387
<mup> Bug #1632387: console-conf wifi only setup on pi3 beta3 image not possible <Snappy:New> <https://launchpad.net/bugs/1632387>
<ogra_> bug 1624322
<mup> Bug #1624322: console-conf wlan race on pi3 <Snappy:New> <subiquity (Ubuntu):Confirmed> <https://launchpad.net/bugs/1624322>
<morphis_> ogra_: hm, then we need to get it into xenial-updates soon otherwise the release on thursday is without it
<ogra_> morphis_, ?
<rvr> ogra_: Is the Dragonboard network problem fixed?
<ogra_> morphis_, it is in the core snap
<ogra_> morphis_, in the one we'll push to stable
<morphis_> ogra_: from what I've heard stable will be be only build from xenial and not the overlay ppa
<morphis_> so everything from the overlay needs to go into the archive
<ogra_> morphis_, yeah, we wish to do that ... but if that doesnt work we wont artificially regress the core rootfs :)
<morphis_> ogra_: its just a wish? :-)
<morphis_> niemeyer sounded different on this last week
<ogra_> we'll try our best ... but do you really think we'll rip things out on release day if they dont land in time ?
<morphis_> not really :-)
<mwhudson> morphis_: np
<mwhudson> er
<mwhudson> morphis_: no
<morphis_> mwhudson: ok
<mwhudson> morphis_: i didn't realize that it was particularly desired
<ogra_> well, we want stable images to come from the archive
<mvo> mwhudson: hey, nice to see you :) did you/your team had a chance to look at the issues that ogra outlined with networking with console-conf?
<mwhudson> mvo: the only issues i've seen mention of seem completely inscrutable
<mwhudson> mvo: but to be clear, which issues do you mean?
<ogra_> mwhudson, see the two bugs above as a start
<mwhudson> ogra_: so https://bugs.launchpad.net/snappy/+bug/1632387 is the one that makes no sense at all
<mup> Bug #1632387: console-conf wifi only setup on pi3 beta3 image not possible <Snappy:New> <https://launchpad.net/bugs/1632387>
<mvo> mwhudson: I'm just the messanger, I don't have a pi3/dragonboard but AIUI from ogra_ these are blockers on these boards
<mwhudson> ogra_: i have a plan for https://bugs.launchpad.net/snappy/+bug/1624322 but going to be quite involved
<mup> Bug #1624322: console-conf wlan race on pi3 <Snappy:New> <subiquity (Ubuntu):Confirmed> <https://launchpad.net/bugs/1624322>
<mwhudson> (i.e not this week)
<ogra_> mwhudson, i think either console-conf starts to early or there is something missing in the first boot at all ... that might be a systemic thing
<ogra_> mwhudson, but in general wifi config is impossible since last subiquity update
<ogra_> for that we dont have a bug yet
<mwhudson> i can try it on my (still serial-less :-( ) dragonboard tomorrow
<mwhudson> filing a bug definitely makes it more likely that i will not forget
<ogra_> indeed ... i spent all day digging into that yesterday, sorry, havent filed that one yet
<ogra_> mwhudson, also if you restart the network config bit often enough (cancel->start) you eventually get greetet with a two page traceback
<ogra_> (only found that one yesterday evening)
<mwhudson> ogra_: huh
<mwhudson> i don't suppose you were actually able to read the traceback?
<mwhudson> (for some reason you get this annoying doubled traceback whenever console-conf crashes)
<ogra_> something about "file exists" ... seemed to come from netplan
<ogra_> or from netplan interaction at least
<ogra_> it only happens on failed config if you repeat it a few times
<ogra_> (and i have only seen it with multiple network devices (dragon + USB NIC or rpi3 which has two by default)
<ogra_> )
<mwhudson> the file exists thing is the "extra" traceback
<mwhudson> there would have been one about that
<ogra_> mwhudson, also, netplan apply is never called when console-conf finishes ...
<mwhudson> it's probably something stupid in probert
<mwhudson> *one above that
<mwhudson> ogra_: ??
<ogra_> i can see the /etc/netplan config changed, but not the interface setiup
<vigo> ogra_, I hit bug #1624322 also with dragonboard, with an image build by me wlan0 was not offered and when using your latest image it gives me the network timeout
<mup> Bug #1624322: console-conf wlan race on pi3 <Snappy:New> <subiquity (Ubuntu):Confirmed> <https://launchpad.net/bugs/1624322>
<ogra_> mwhudson, it keeps the same setup i got from the initial boot before console-conf was up ... if i call "netplan apply" manually after ssh'ing in for the first time, it applies it
<ogra_> mwhudson, or on reboot
<mwhudson> ogra_: i definitely did not deliberately delete the code to call netplan apply...
<ogra_> no, i can definitely see it in the tasks enumeration in the code
<ogra_> vigo, thanks for confirming !
<rvr> https://bugs.launchpad.net/snappy/+bug/1636419
<mwhudson> if for some reason it's not being called that would certainly explain why the wlan is never connecting...
<mup> Bug #1636419: Network settings aren't set in Dragonboard <Snappy:New> <https://launchpad.net/bugs/1636419>
<mup> Bug #1636419 opened: Network settings aren't set in Dragonboard <Snappy:New> <https://launchpad.net/bugs/1636419>
<mwhudson> ogra_: can you dig out the /var/log/console-conf/subiquity-debug.log file?
<ogra_> mwhudson, right ... if i reboot it shows me the SSID ... but if i re-rty without going to "configure wlan" again it tries to apply it without key
<deadlock> Hello, guys. Someone knows how to install snap on openSUSE Tumbleweed correctly? That doesn't works here: http://snapcraft.io/docs/core/install#opensuse The snapd service doesn't starts.
<vigo> rvr, I passed the network screen
<rvr> vigo: With today's image?
<rvr> vigo: Without rebooting?
<vigo> rvr, just after reboot ehehe
<vigo> yes
<rvr> vigo: Then it's not the same test case ;)
<rvr> vigo: Yeah, I could too after rebooting, because the credentials are stored and applied
<ogra_> mwhudson, http://paste.ubuntu.com/23378076/ ... btw ... you should really hide the WPA key from that log :)
<vigo> rvr, that's it
<mwhudson> ogra_: yeah, probably, at least its -r-------- now
<ogra_> deadlock, i guess zyga could help, but i dont know if he is around today
<rvr> mwhudson: ogra_: Yeah, he should, I sent you mine WPA password yesterday :D
<rvr> s/mine/my/
<ogra_> mwhudson, right, but i have to edit it to attach it to bugs or pastebin
<mwhudson> ogra_: yes, fair, file a bug pls?
<ogra_> will do
<rvr> ogra_: mwhudson: I already did, see above
<mwhudson> well it sure looks like it calls netplan apply and it returns status == 0 and nothing on stdout or stderr
<mwhudson> rvr: about the WPA PSK being in the log?
<rvr> mwhudson: Nope, about the network in the Dragonboard
<mwhudson> rvr: right, that's not what i meant
<deadlock> ogra_, thank you.
<deadlock> zyga, can you help me?
<jgdx> question: if I were to snap latexlive-full, how would one use pdflatex on an all-snappy system? Would some content transfer be necessary? Usually there's a bunch of files involved, not just the .tex file
<ogra_> mwhudson, bug 1636421
<mup> Bug #1636421: console-conf should hide WLAN keys from logfiles <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1636421>
<ogra_> rvr, ^^^ feel free to confirm
 * ogra_ is afk for 20min
<rvr> ogra_: Done
<mup> Bug #1636421 opened: console-conf should hide WLAN keys from logfiles <Snappy:Confirmed> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1636421>
<mwhudson> ogra_: ta
<vigo> rvr, I'm confirming your bug ok?
<rvr> vigo: Thanks!
<mvo> deadlock: hello, zyga may be able to help with snapd on suse
<deadlock> mvo, thank you
<zyga> re
<zyga> ah, sorry, lost connection there for a sec
<zyga> deadlock: how can I help you
<mup> PR snapd#2203 closed: snap: switch the auto-import dir to /run/snapd/auto-import <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2203>
<mup> Bug #1635604 opened: console-conf should be localized <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1635604>
<Son_Goku> deadlock & zyga: snapd has been FTBFS for Tumbleweed for a while now
<Son_Goku> as has snap-confine
<Son_Goku> actually, most of the snappy project is broken across Leap and Tumbleweed: https://build.opensuse.org/project/monitor/system:snappy
<zyga> Son_Goku: yep, I'm guiding deadlock on fixing that
<deadlock> Son_Goku, thank you. I'm talking with zyga in private
<Son_Goku> okay, :)
<zyga> Son_Goku: I'm looking at https://github.com/zyga/mounted-fs-memory-checker
<zyga> Son_Goku: there's something super weird going on
<zyga> Son_Goku: same kernel, same snap, memory usage on UP system is 131MB per mounted snap vs 7MB on a 4-core system
<zyga> Son_Goku: no idea why yet
<Son_Goku> ~_~
<mup> PR snapd#2210 opened: debian: only install share/locale if available (missing on powerpc) <Created by mvo5> <https://github.com/snapcore/snapd/pull/2210>
<zyga> Son_Goku: I'm checking on fedora kernel now
<morphis_> mvo: where do you guys get the -core image for spread from you have configured in https://github.com/snapcore/snapd/blob/master/spread.yaml#L44 ?
<mvo> morphis_: the qemu ones? check https://github.com/snapcore/snapd/blob/master/HACKING.md#running-the-spread-tests
<morphis_> let me see
<morphis_> mvo: so they are no real core images?
<morphis_> with kernel and gadget snap etc.
<zyga> morphis_: they are but they are made each time
<morphis_> interesting
<mvo> morphis_: they are morphed into them, we need to modify some key aspects (like the snapd) of the image to generate them
<mvo> morphis_: you should look at the code, its quite fun how we do it
<morphis_> looking already but that gives me a idea of what the code is doing
<mvo> morphis_: https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L80
<morphis_> wow, you boot a classic image first and then reflash the image on the firstboot?
<Son_Goku> mvo, is the core snap still called "ubuntu-core" or is it just called "core"?
<morphis_> mvo: one other quick thing, joc_ currently has problems importing a key into the snap keyring, is that something you can help with?
<joc_> looks like i need to be using --homedir to get to the correct keyring
<joc_> yep that did it
<ogra_> Son_Goku, you should only use "core" for anything new ... the ubuntu-core is still built in parallel but will eventually vanish
<Son_Goku> ah okay
<Son_Goku> how is the core snap built?
<ogra_> https://code.launchpad.net/~snappy-dev/+snap/core
<ogra_> http://bazaar.launchpad.net/~snappy-dev/core-snap/trunk/files has the Makefile this uses
<ogra_> (there is also a readme)
<ogra_> Son_Goku, we use livecd-rootfs/live-build as our creator backend ... i guess for fedora you want to use sommething like anaconda (or whatever the successor is since i had to deal last with that stuff)
<Son_Goku> we have lorax for building things like this: http://lorax.readthedocs.io/en/latest/intro.html
<Son_Goku> it uses anaconda as the engine
<ogra_> ah, k
<ogra_> on the first link, if you click on any of the "Successfully built" links you get to the build details, there is a manifest file that lists all the debs included
<Son_Goku> cool
<ogra_> i also have a summary page (mainaly for my own overview) that screen-scrapes launchpad and summarizes everything at http://people.canonical.com/~ogra/core-builds/
<ogra_> (super hackish, but helpful :) )
<Son_Goku> that's useful
<zyga> Son_Goku: any luck with the policy? I wanted to see if we can push snapd forward today
<Son_Goku> not yet, no
<Son_Goku> I'm about to send an email asking for some help with this
<zyga> thank you, that would be very useful!
<morphis_> joc_: great!
<zyga> morphis_: hey did you guys get a chance to try udisks2 last week?
<ogra_> rvr, regarding bug 1636419 ... it works for me on second boot (but you need to do all of the configuration again, even if console-conf seems to already have your WLAN credentials)
<mup> Bug #1636419: Network settings aren't set in Dragonboard <Snappy:Confirmed> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1636419>
<morphis_> zyga: I started with it but I am testing it again today
<zyga> morphis_: anything broken yet?
<rvr> ogra_: Yes, after reboot it works
<morphis_> zyga: not yet :-)
<ogra_> rvr, mention that in the bug then ;)
<rvr> ogra_: vigo did in a comment
<ogra_> oh, i see it now ... sorry ... blind man here
<zyga> morphis_: knock on wood, let's hope it stays okay
<zyga> morphis_: there's some odd memory usage I'm still debugging
<morphis_> zyga: flashing the rc image for x86 again right now, lets see what comes then
<vigo> ogra_, hehe for me sometimes it takes more than just one reboot I don't know why sometimes is not saving the network conf
<ogra_> vigo, i noted that it doesnt apply the ppassword if i dont go through the whole wlan config again on second boot
<vigo> ogra_, yeap :(
<ogra_> (i.e.. it has the SSID in the config file in /etc/netplan but not the password)
<mup> Bug #1624913 changed: Ubuntu-Core does not list any snaps on newly installed device <Snappy:New> <https://launchpad.net/bugs/1624913>
<mup> PR snapcraft#869 closed: Bring docs/upload-your-snap.md in line with http://snapcraft.io/docs/â¦ <Created by dholbach> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/869>
<mup> Bug #1635170 opened: No warnings of what's unclean paths leads to terrible UX <Snappy:Triaged> <https://launchpad.net/bugs/1635170>
<Son_Goku> zyga, gah
<Son_Goku> this is all your fault!
<Son_Goku> the label never applies to /run/snapd.sock
<Son_Goku> that's where snapd.socket is creating the file
<Son_Goku> GAHHH
<zyga> Son_Goku: why and how is that my fault?
<Son_Goku> your snapd.socket file has the wrong path
<Son_Goku> which broke everything :P
<Son_Goku> also apparently the hello snap can't find the core snap
<Son_Goku> it pulled in ubuntu-core instead of core, as well
<Son_Goku> [root@f24-kde-skuld-vm run]# snap run hello
<Son_Goku> cannot locate the core snap. errmsg: No such file or directory
<zyga> Son_Goku: I still don't see how that's my fault or how finger pointing helps but lets not dwell ;)
<ogra_> there is no coire in the stable channel yet ...
<zyga> Son_Goku: are you using the new snap-confine from master?
<Son_Goku> no
<ogra_> it might be looking for stable ...
<Son_Goku> I'm using the latest you built in Koji
<zyga> Son_Goku: that's the right one
<zyga> Son_Goku: can you run anything with SNAP_CONFINE_DEBUG=yes please
<zyga> Son_Goku: it is probably something very trivial
<Son_Goku> sure
<Son_Goku> https://paste.fedoraproject.org/460616/39587114/
<Son_Goku> zyga ^
<zyga> and the output of "snap list" please
<zyga> and lastly see the mounted snaps please
<Son_Goku> with the debug stuff, right?
<zyga> that is separate
<Son_Goku> [root@f24-kde-skuld-vm run]# snap list
<Son_Goku> Name         Version  Rev  Developer  Notes
<zyga> I mean, the environment variable above only affects snap-confine
<Son_Goku> hello        2.10     20   canonical  devmode
<Son_Goku> ubuntu-core  16.04.1  423  canonical  -
<zyga> ok
<zyga> where is it mounted?
<Son_Goku> tmpfs on /run/snapd/ns type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
<zyga> ubuntu-core
<Son_Goku>  /var/lib/snapd/snaps/ubuntu-core_423.snap on /var/lib/snapd/snap/ubuntu-core/423 type squashfs (ro,relatime,seclabel)
<Son_Goku>  /var/lib/snapd/snaps/hello_20.snap on /var/lib/snapd/snap/hello/20 type squashfs (ro,relatime,seclabel)
<zyga> that looks good
<zyga> can you check if snap-confine is built with /var/lib/snapd/snap
<zyga> no typos or anything
<zyga> or mising trailing slash
<Son_Goku> certainly
<zyga> it might be something as trivial as this
<Son_Goku> also, debugging selinux policy module in #fedora-selinux now too :)
<Son_Goku> ugh
<Son_Goku> yeah, I know what happened
<Son_Goku> [root@f24-kde-skuld-vm run]# rpm -E "%{_sharedstatedir}/lib/snapd/snap"
<Son_Goku>  /var/lib/lib/snapd/snap
<Son_Goku> zyga, take off the "/lib" in http://pkgs.fedoraproject.org/cgit/rpms/snap-confine.git/tree/snap-confine.spec#n41
<Son_Goku> it should be "%{_sharedstatedir}/snapd/snap"
<zyga> ah :D
<zyga> do we need the trailing slash?
<zyga> Son_Goku: so? :) does it work?
<Son_Goku> dunno, I'm about to rebuild and try
<zyga> ++ thank you
<Son_Goku> no trailing slash required
<Son_Goku> it works
<zyga> !!!
<zyga> wooooot
<Son_Goku> also... https://gitlab.com/Conan_Kudo/snapcore-selinux/commit/eefa7cedd11ad91da8e240732e474124282f5846
<zyga> merge it back!
<Son_Goku> I will, one sec
<zyga> what's -s vs --
<Son_Goku> socket vs regular file
<zyga> ah, I see
<Son_Goku> I've pushed new snap-confine builds to koji
<Son_Goku> I'm going to test my changes for the selinux policy
<zyga> Son_Goku: thank you
<popey> ogra_: you recall I re-flashed my busted pi3 again yesterday. Today I wake to find it's no longer on the network. Serial console shows localhost login:
<popey> ogra_: I think it did an update overnight.
<abeato> jdstrand, hi, https://github.com/snapcore/snapd/pull/2058 should be ready when you have a slot to take a look :)
<mup> PR snapd#2058: interfaces: add ofono interface <Created by alfonsosanchezbeato> <Conflict> <https://github.com/snapcore/snapd/pull/2058>
<diddledan_> does cleanbuild create multiple architectures if they're defined in the yaml file?
<diddledan_> I'm investigating a snap just build and it seems to only have the amd64 stuff
<Son_Goku> zyga, did you contact the package maintainer of the dep that's broken in f23 for snapd?
<diddledan_> I've added `architectures: [amd64, i386]` to the yaml
<zyga> Son_Goku: not yet
<zyga> Son_Goku: I don't know which one it is
<zyga> Son_Goku: it was network related but that's all I know
<zyga> diddledan_: no, there's no general cross-building
<zyga> diddledan_: you can use launchpad to build your snap for any architecture if that helps
<diddledan_> ok. feature request :-)
<diddledan_> thanks zyga
<zyga> well, hard to do
<diddledan_> yeah, I've done manual cross compiling in the distant past and it was painful
<Son_Goku> cross compiling is always painful
<Son_Goku> most tooling isn't designed to handle host and target being different :/
<Son_Goku> nope, still not working
<Son_Goku> yay, I broke the hello snap by simply uninstalling and reinstalling snapd
<jdstrand> abeato: ack
<abeato> thnaks
<ogra_> popey, wired or wlan ?
<zyga> Son_Goku: what happened when you did that?
<Son_Goku> I get "command not found"
<zyga> isn't the snap removed when you do that?
<Son_Goku> yes, but it's not removed
<Son_Goku> all the mounts are broken now, though
<zyga> Son_Goku: the postup script probably needs to be adjusted
<popey> ogra_: wired, it came back after a reboot.
<ogra_> weird
<zyga> Son_Goku: anything I can merge?
<Son_Goku> not yet
<Son_Goku> hopefully soon, though
<ogra_> popey, did you ever reboot it before (i.e. after console-conf)
<Son_Goku> still working out kinks in initial policy
<popey> ogra_: don't think so.
<ogra_> popey, might be fallout of console-conf not running netplan apply
<ogra_> (which is then called on reboot apparently)
<diddledan_> this bug #1580740 is marked as fixed for xenial but seems to have been missed for yakkety
<mup> Bug #1580740: [SRU] Cannot open a browser link from a snap that provides a link <snap-desktop-issue> <verification-done> <xenial> <yakkety> <Snappy:Triaged> <snapd-xdg-open (Ubuntu):Fix Released> <snapd-xdg-open (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1580740>
<diddledan_> oic, it's present in the archive but hasn't been pulled automatically
<diddledan_> I think it should be depended upon by something?
<zyga> Son_Goku: thank you!
<morphis_> ogra_: you had a site where you listed all content of all core snaps, can you give me the link again?
<ogra_> morphis_, http://people.canonical.com/~ogra/ubuntu-core-builds/ ?
<morphis_> ogra_: yea!
<ogra_> morphis_, note though that this only lists auto-built snaps ... if mvo uses the LP ui for a build that wont show up
<morphis_> hm
<ogra_> (it only parses the log of the auto-build script)
<ogra_> so there can be gaps
<zyga> jdstrand: hey, good morning
<zyga> jdstrand: how are you doing?
<jdstrand> hey zyga :)
<jdstrand> zyga: I'm good. glad to be back home. trying to get through a mount of email and sprint outcomes to translate to actual work items :)
<jdstrand> zyga: how are you?
<zyga> jdstrand: do you remember our converstation? I ran some tests and ended up with ... for the same .snap, 1MB all the way up to 131MB
<zyga> jdstrand: my health is not very good after that week but I hope it improves, usual issues with my spine, but mood is good
<jdstrand> zyga: sorry to here-- hope you feel better soon
<zyga> jdstrand: I asked the kerel team for assistance and I'm working on measuring memory usage with snap-confine environment set up for each snap
<jdstrand> hear*
<jdstrand> sounds good
<zyga> jdstrand: I made https://github.com/zyga/mounted-fs-memory-checker in case you want to try
<zyga> jdstrand: the numbers I get are consistent in each VM/box but differ widely for no apparent reason
<jdstrand> oh neat
<mup> PR snapd#2211 opened: tests: test-snapd-fuse-consumer needs python-fuse as a build-package <Created by mvo5> <https://github.com/snapcore/snapd/pull/2211>
<jdstrand> zyga: fyi, I passed this information on to the security team. I know they were interested in this topic
<jdstrand> (the rest of the security team that is)
<zyga> jdstrand: thanks!
<ogra_> ppisati, hmm, any idea why i end up with evbug auto-loaded all the time on the rpi  ? its spilling a lot of crap to the logs
<mup> PR snapd#2212 opened: spread tests: fix snap mode check <Created by stolowski> <https://github.com/snapcore/snapd/pull/2212>
<ppisati> ogra_: nope
<mup> PR snapd#2213 opened: tests: skip tests that use expect when expect is not working (like on ppc64el) <Created by mvo5> <https://github.com/snapcore/snapd/pull/2213>
<ogra_> ppisati, also ... i just booted the pi3 with systemd debug console and see that despite having the brcmfmac module loaded there is no wlan device in /proc/net/dev ... that happens only on first boot though ... the devices shows up once i modprobe -r/modprobe the module
<ogra_> mvo, when exactly do we bind mount /lib/firmware in the boot process ?
<ppisati> ogra_: do you see any message of fmac complaining about the lack of fw files?
<ogra_> nope
<mvo> ogra_: pretty early, right after we mounted writable rw
<ogra_> the output actually looks all happy in dmesg and syslog
<ogra_> mvo, so initrd ? or systemd ?
<mvo> ogra_: initrd
<ogra_> k
<ogra_> then its not that
<mvo> ogra_: unless there are bugs of course, but nothing indicates that
<ppisati> dmesg | grep brcm
<ogra_> i would really like to know why it only happens on first boot
<ogra_> i just re-flashed, gimme a sec
<ppisati> k
<ogra_> (pretty annoying that i can only repro it on the very first boot, so if i manage to get the device show up i need to re-flash)
<ppisati> even better
<ppisati> dmesg | grep -e fmac -e brcm
<tyhicks> zyga: I have been wondering if spitting the snap (squashfs image) out to disk on each boot is acceptable instead of mounting the snap on each boot
<ogra_> i get 4 lines ... (cant copy paste from tty console)
<ogra_> first one is usbcore telling me it loads the module
<ogra_> second is the firmware loading which looks all fine
<zyga> tyhicks: I don't think we want that, we want to know what's broken
<tyhicks> zyga: I don't see much of an advantage to actually have these things mounted versus unsquashed
<zyga> tyhicks: my tests include ext4 and even vfat and there memory usage is next to nothing
<zyga> tyhicks: integrity, simplicity, efficiency
<ogra_> ppisati, the next two are "brcmf_cfg80211_reg_notifier: not a ISO3166 code"
<zyga> tyhicks: I've started comitting traces to the tree
<zyga> tyhicks: you can now run the simple analyze.py script to see
<tyhicks> zyga: I think these results are an argument against efficiency
<tyhicks> zyga: I do agree with simplicity
<zyga> tyhicks: well, efficiency vs copying
<zyga> tyhicks: but honestly we need to know more, why is squashfs different from all the other fs'es
<zyga> tyhicks: I asked the kernel team for support
 * tyhicks nods
<tyhicks> zyga: I peeked through the code a bit - there's quite a bit of overhead involved in the squashfs metadata cache
<ppisati> ogra_: something like this?
<ppisati> ogra_: http://pastebin.ubuntu.com/23379090/
<tyhicks> zyga: the metadata is read from the image, decompressed, and sorted appropriately in an internal-to-squashfs cache
<ogra_> ppisati, yes, exactly this
<ppisati> ogra_: good, then the wlan was initiliazed correctly
<zyga> tyhicks: what is considered meta-data? my snaps have two files inside
<zyga> and one directory
<tyhicks> zyga: it is cached so that they, hopefully, don't have to go through decompression again later when something like an inode needs to be read in from the squashfs image
<ppisati> ogra_: is the module still loaded?
<ogra_> yep
<ppisati> me thinks
<ppisati> maybe we can check via the dt tree
<ogra_> i see the module, have that output, but no trace of wlan0 in /proc/net/dev
<tyhicks> zyga: see "3. SQUASHFS FILESYSTEM DESIGN" in https://www.kernel.org/doc/Documentation/filesystems/squashfs.txt
<ppisati> let me reach for my board
<zyga> tyhicks: hmmm
<zyga> tyhicks: my 1MB snap caues 131 of memory to be used on mounting
<zyga> tyhicks: thanks, I'll have a look
<zyga> (1MB decompressed)
<zyga> tyhicks: pull the project and run
<zyga> ./analyze.py ubuntu 16.04 4.4.0-45-generic size-1m.squashfs.xz.heavy
<zyga> tyhicks: now compare that to 0m (empty snap)
<zyga> there's no difference
<zyga> with smallest possible block size and dictionary size (size-1m.squashfs.xz.smallest) I get 1.3MB
<zyga> with ext4 I get close to 0
<zyga> anyway
<zyga> time for dinner
<tyhicks> crazy
<tyhicks> I'll poke at the project a bit
<ogra_> pitti, what reads /run/systemd/netif/leases on boot ... i get a bunch of shell errors (seems nothing checks if the dir is empty and sed is tried to run)
<ogra_> i wonder if that blocks my wlan0 (like basic networking not coming up or so)
<pitti> ogra_: ah, that's our xenial hack for updating resolvconf with networkd-picked up DNS servers; can you please file a bug? should be simple to fix
<pitti> (but also just cosmetical)
<ogra_> pitti, ok, nothing that could cause my issue then apparently
<pitti> that service doesn't block anything, it's just being triggered via inotify
<ogra_> ok
<pitti> ogra_: it could cause missing DNS servers in /etc/resolv.conf
<mup> PR snapd#2214 opened: overlrod/snapstate: fix revert followed by refresh to old-current <Created by chipaca> <https://github.com/snapcore/snapd/pull/2214>
 * ogra_ sighs ... what a mystery
<pitti> if that's what you mean by "block"
<pitti> i. e. the interface could be up and you can talk to stuff by IP address, but no DNS resolution
<ogra_> pitti, nah ... i dont get wlan0 in /proc/net/dev on a very first boot of a snappy image ...
<ogra_> the driver is loaded, firmware too
<pitti> dmesg?
<ogra_> but only the second boot gives me the actual device
<mup> PR snapd#2215 opened: tests: spread system user autoimport <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2215>
<ogra_> nothing in dmesg
<pitti> does the first boot install some firmware or so?
<ogra_> (beyond the expected lines for the driver)
<ogra_> nope
<pitti> there isn't anything in userspace other than providing firmware files (or kernel .ko drivers) which would influence that
<ogra_> shouldnt
<ogra_> but i'm not sure, thats why i poke around a little blindly
<pitti> ... or rfkill
<ogra_> thats why i asked you before ... but it comes up with 0 in the file (we dont have the rfkill binary on the image though)
<pitti> ogra_: no need for the binary, you can check in /sys/class/rfkill/
<ogra_> empty
<pitti> hm, that's a bit surprising
<pitti> ogra_: /sys/class/net/w* ?
<ogra_> yeah
<ogra_> nope
<pitti> if the kernel says something about the detection of it (as you said above), there should at least be a device for it
<ogra_> then it would also be in /proc/net/dev
<pitti> ogra_ | (beyond the expected lines for the driver)
<pitti> i. e. just the driver, but no detected devices
<ogra_> well, the kernel doesnt talkj about "wlan0" or anything
<ogra_> (but it never does that to my knowledge)
<pitti> ogra_: maybe the first boot loads the firmware, and then on the next reboot the device actaully works and is detected?
<pitti> but loading the fw doesn't bring it up immediately or so?
<ogra_> and the driver isnt in /etc/modules or anything, so something triggered the loading
<pitti> but I'm a n00b on the kernel side of this, I'm afraid
<ogra_> nah, i think that works in classic images
<ogra_> i suspect it is caused by userspace
<mup> Bug #1587448 opened: Can't reboot device from snap <snapd-interface> <Snappy:Fix Committed> <https://launchpad.net/bugs/1587448>
<ogra_> but i'm running out of clues where to look
<ogra_> re-loading the module fixes it ...
<ogra_> but we cant do that indeed
<ogra_> (as a default)
<pitti> oh
<pitti> ogra_: so maybe it is due to not re-poking the device after loading the firmware, or the latter doesn't cause the driver to re-attempt detection
<ogra_> i also tried an udevadm trigger ... in the hope there is a race or some such ... but no result either
<pitti> no, that wouldn't help
<pitti> that only would do the userspace reaction to new kernel devices
<zyga> tyhicks: on fedora I get 4MB instead of 131
<pitti> but the problem is lower, the kernel device doesn't exist at all
<ogra_> right, but only on first boot of an ubuntu core all-snap image
<ogra_> second boot is fine ... classic images are fine
<zyga> tyhicks: I just pushed the trace
<zyga> pull and run this to see: ./analyze.py fedora 24 4.7.9-200.fc24.x86_64 size-1m.squashfs.xz.heavy
<ogra_> to me it looks more like something is created on the filesystem on that first boot ... and ignored
<ogra_> until i re-load the module or reboot
<pitti> ogra_: any crazy bind mounts on the root partition that are done in userspace again?
<pitti> I mean "during boot as opposed to initrd"
<ogra_> well, systemd processes the fstab ... for everything but /etc
<pitti> although device detection happens during initrd alread
<ogra_> we dont have network modules there
<ogra_> so it wouldnt have any effect
<ogra_> (we only have a handfull of hardcoded modules for disk controllers in there by default)
<tyhicks> zyga: wow, that's quite a difference :)
 * ogra_ wonders why we bind mount /var/lib7initramfs-tools 
<iliv> where do I check what $HOME is set to from perspective of a program shipped as a snap package?
<ogra_> iliv, snap install hello-world ... then run hello-world.env
<ogra_> pitti, hmmm ... machine-id is only generated after systemd did the /var/lib/dbus bindmount, could that have any effect ?
<pitti> if /etc/machine-id is not there, systemd generates a temporary one and bind-mounts it if it cannot be written
<pitti> but I wouldn't know how that would affect device detection by kernel drivers
<ogra_> right, i just wonder if a driver could depend on it
<iliv> ogra_, uh, looks like a custom program?
<ogra_> ?
<iliv> env
<iliv> I mean, my packages don't have it. Am I supposed to include one?
<ogra_> it calls "env" indoes a snap environment and prints it
<ogra_> *inside
<ogra_> it is just the shell env command
<ogra_> you can also try hello-world.sh
<ogra_> that starts a shell inside the snap environment
<iliv> are env, evil, sh and echo part of snap environment and avaiable to all packages by default?
<ogra_> (exist it with ctrl-d or the exit command)
<ogra_> no, they are scripts shipped in hello-world
<ogra_> you can just read them in /snap/hello-world/current/
<iliv> does that mean if my package doesn't include those AND hello-world isn't installed there is no (easy?) way to see what $HOME is set to?
<ogra_> you can always call env from a wrapper script in your snap to have it printed
<ogra_> pitti, hmm, some dependency pulled wireless-regdb and crda into the image ... i wonder if that could cause it
 * ogra_ sees crda udev rules 
<pitti> ooh
<pitti> ogra_: yes, that's very plausible -- some drivers refuse to work until you set a CRDA area
<ogra_> well, nothing sets an area code (and actually the config dirs are all readonly) .,... also it works on second boot/load of the module ... but perhaps it blocks altogether if it cant write or so
<ogra_> aha !
<ogra_> systemd-udevd "/sbin/crda" failed with exit code 234
<ogra_> hmm, that just measn "no country code set"
<pitti> I have a /sys/devices/platform/regulatory.0/ on my laptop, so /lib/udev/rules.d/85-regulatory.rules woudl call /sbin/crda
<pitti> and for sure /lib/crda/setregdomain runs to (from /lib/udev/rules.d/40-crda.rules)
<pitti> but I don't see any crda error codes in the logs
<pitti> REGDOMAIN= in /etc/default/crda (i. e. unchanged file)
<ogra_> yeah, same here
<pitti> ogra_: do you still have that exit code 234 on the second boot when it works? if so, it's a red herring, if not it's a strong clue that crda is the reason?
<ogra_> well, let me try
<ogra_> (that means i need to re-flash though ... i can only test once)
<pitti> ogra_: or search through teh writable area for anything that looks crda related or REGDOMAIN etc?
<ogra_> pitti, definitely no crda error on second boot
<ogra_> pitti, http://paste.ubuntu.com/23379264/ i dont see anything that could be realted :/
<mup> Bug #1636540 opened: please support creating pipes via mknod <snapd-interface> <Snappy:Triaged> <https://launchpad.net/bugs/1636540>
<pitti> ogra_: not /media/ogra/writable/system-data/etc/modprobe.d/modprobe.d/iwlwifi.conf or so?
<pitti> /media/ogra/writable/system-data/etc/dbus-1/system.d/org.freedesktop.timedate1.conf o_O
<pitti> why would this be writable, and not in the r/o section?
<ogra_> would be surprising if that had any influence on a rpi
<pitti> (unrelated, but caught my eye)
<ogra_> (iwlwifi is intel only, no ?)
<pitti> ah, yes
<ogra_> hmm ... seems "iw reg get" is what i should try after first boot ... to see if there is anything at all
 * ogra_ re-flashes once again ... poor SD ... 
<ogra_> well
<ogra_> iw reg get doesnt show any different output
<ogra_> lol
<ogra_> the output of "crda --help" is highly informative
<mup> PR snapd#2204 closed: interfaces/builtin: network-manager and bluez can change hostname <Critical> <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2204>
<MikeB> I posted a question to devices mailing list last week but no answers.  https://www.mail-archive.com/devices@lists.snapcraft.io/msg00145.html   Anyone here think they could help?
<MikeB> Basically creating custom kernel snap and custom image.  Boots fine, but snapd failes to start after I install my first snap.
<tyhicks> zyga: how many CPU cores did your ubuntu test machine have and how many did the fedora machine have?
<Croepha> f
<Croepha> f
<Croepha> oops, disregard that pls :(
<zyga> tyhicks: UP machines had one
<tyhicks> zyga: they all had 1 cpu core?
<zyga> tyhicks: 16.10 system had dual cores
<ogra_> MikeB, and you are building from edge or beta channel ? (note that there has not been a stable core snap in a long time, you dont want to use stable until there has actually been a series 16 snappy release)
<tyhicks> zyga: the ubuntu kernels have CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU=y
<zyga> tyhicks: yes, I saw that
<tyhicks> zyga: that results in squashfs creating one set of internal caches per possible CPU
<zyga> tyhicks: lots of buffers
<zyga> tyhicks: I'm running on 4 core system to compare now
<MikeB> ogra_ I tried both edge and beta.
<MikeB> Same results.
<zyga> (also xenial)
<tyhicks> zyga: it looks like the fedora kernel config uses the default (CONFIG_SQUASHFS_DECOMP_SINGLE), which only uses one set of caches
<MikeB> I'm unable to build from stable since the gadgest aren't available.
<ogra_> MikeB, using the snapcraft kernel plugin to create your kernel ?
<MikeB> I have a workaround to grab the gadgests from ~vorlon, but that one fails too.
<zyga> tyhicks: woah!?!
<ogra_> i think they are outdated ... slangasek (vorlon) might be able to comment
<zyga> tyhicks: on 4 way system I get _less_ memory than on UP
<MikeB> Yes, snapcraft 2.19 kernel plugin.  I have some changes to the config which is why I need the custom kernel.
<zyga> tyhicks: 7MB per size-1m.squashfs.xz.heavy
<ogra_> right, my question was more to make sure you get the right initrd
<zyga> tyhicks: I'll adjust the test to embed the number of CPUs in the directory
<zyga> tyhicks: does this make any sense to you, less CPUs, way more buffers?
<ogra_> though ... hmmm
<tyhicks> zyga: it doesn't - that's something for the kernel team to figure out :/
<ogra_> sergiusens, ppisati, does the current snapcraft kernel plugin pull from stable or from edge ?
<zyga> tyhicks: I'm cross-checking the fedora config now
<zyga> tyhicks: CONFIG_SQUASHFS_DECOMP_SINGLE=y
<zyga> that checks out, good hunch
<ogra_> could indeed be that you have an outdated initrd ... which can result in having a totally wrong clock ... which in turn fails to use the certificates for the initial setup of snapd
<zyga> may be a bug in the CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU
<tyhicks> could be
<MikeB> ogra_ I was thinking it was something like that.  The kernel plugin doesn;t give option to pull from alternate channels.  I get what I get.
<ogra_> yes, i never use it so i dont know which one it pulls
<slangasek> ogra_: I don't know if they're outdated, because there's no official publication of the signed model assertions so I only know if they're outdated if I poll.  I gather there is now a way to download them from the store by name, perhaps we should be migrating everybody to that
<ogra_> yeah
<MikeB> Looking at the source for kernel.py, it looks like it is pulling from edge
<ogra_> ppisati, fyi, i'm pretty sure the regulatory subsystem is getting in our way with the wlan0 device ... not sure why yet though
<ogra_> "iw reg get" looks identical no matter if wifi works or not
<MikeB> That is, it is pulling ubuntu-core from the edge.
<ogra_> then it should be fine
<ogra_> what arch is that ?
<MikeB> amd64
<ogra_> ah, then the initrd shouldnt have so much influence anyway (regarding the clock etc)
<liuxg> kyrofa, good evening. May I check with you whether configure hook is fully working? thanks
<MikeB> using canonical-pc-amd64 for for model and 'pc' for gadget
<kyrofa> liuxg, it is as of 2.16
<MikeB> snapd version on first-boot is 2.16+ppa64.70c490f6-1 when I build the image from edge.
<liuxg> kyrofa, thanks for your reply. my desktop installed the version 2.16. However, it seems not working in my place. I have a test project at https://github.com/liu-xiao-guo/helloworld-configure. would you please help to take a look? thanks
<kyrofa> liuxg, ah, snapcraft doesn't support hooks yet
<kyrofa> liuxg, if you want to use them, you need to place them yourself
<liuxg> kyrofa, I have place the a configure file located at meta/hooks/configure. I used the same code as in the hooks.md document. it does not work for me.
<kyrofa> liuxg, is it executable
<kyrofa> ?
<liuxg> kyrofa, let me check. ...
<liuxg> kyrofa, yes, I just changed it to executable, it gave me "Run configure hook for hello (cannot snap-exec: cannot find hook "configure" in "hello")"
<liuxg> kyrofa, this is how it looks like http://paste.ubuntu.com/23379594/ in my place
<ppisati> ogra_: if you saw those 'fw loading ...' and 'ISO code blabla' in dmesg, it means wlan0 was setup correctly, but then something removes it
<ppisati> ogra_: i'm more inclined to think it's a PM issue
<ppisati> ogra_: like, someone puts the interface to sleep and it gets removed
<ogra_> ppisati, hmm
<ogra_> can i force it to stay on somehow ?
<ppisati> ogra_: that's what if was happening in BBB image with the oops
<ppisati> uhm
<ogra_> ah, right, i remember
<ogra_> we probably dont really want it to sleep by default at all
<ogra_> given it is our only way to access a provisioned device
<liuxg> kyrofa, after installing the snap, it looks like http://paste.ubuntu.com/23379606/
<kyrofa> liuxg, yeah I've duplicated here... not sure what's happening, I'm investigating
<ogra_> (i.e. the default for PM should be off ... but witjh the option that people can toggle it if needed)
<ogra_> ppisati, though why only on very first boot and never again ?
<liuxg> kyrofa, OK. thanks for your help. do you mean snapcraft will support it in the future, and it will put the file into the right place, right?
<kyrofa> liuxg, indeed
<ppisati> ogra_: IMO is netplan/netconf/the configuration thing/ that puts all the interfaces to sleep
<ogra_> pitti, ^^^ ?
<ogra_> is that a possibility ?
<liuxg> kyrofa, thanks for letting me know. I am going to sleep. have a nice day.
<ogra_> ppisati, neither runs before you press enter ...
<kyrofa> liuxg, you as well!
<ogra_> (the "press enter" is just a shell script wrapped around getty ... only if you actualyl press the console-conf/netplan stuff starts)
<ogra_> i am on a system where enter has not been pressed yet
<sergiusens> ogra_ stable, always stable
<ogra_> sergiusens, well, MikeB says edge
<sergiusens> darn
<ogra_> :)
<sergiusens> indeed "            'ubuntu-core', 'edge', self.os_snap, self.project.deb_arch)"
<sergiusens> this is wrong
<ogra_> well, you really dont want the initrd from ubuntu-core 425
<ogra_> thats half a year old or so
<sergiusens> well, I don't want any of this
<ogra_> hold back the fix til we have something modern in stable
<sergiusens> I want to not need to do this intrd dance and have core take care of it
<ogra_> yeah
<ogra_> add some more hours to my days :P
<iliv> jdstrand, hey, I'm here as well so if you prefer to discuss that bugreport here just send me a pm or highlight me in this channel
<rharper> ogra_:  do you know mounts the second partition to /boot/grub (or /boot/uboot) ?
<rharper> *what* mounts the second partition
<ogra_> rharper, the initrd
<rharper> is that in the initramfs packages in core snap ?
<rharper> or part of the kernel snap build ?
<ogra_> in the binary initrd in the kernel snap
<rharper> ok, but the scripts in the initrd are found in which source?
<ogra_> but the binary initrd is created during build of the core snap currently
<ogra_> initramfs-tools-ubuntu-core in the image ppa
<rharper> ogra_: excellent, thanks!
<ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
<ogra_> the script itself also lives on disk of a running system in /usr/share/initramfs-tools/
<ogra_> (under scripts/ubuntu-core-rootfs )
<rharper> triple thanks !
<kyrofa> sergiusens, learned something interesting
<kyrofa> sergiusens, you can indeed add other Nextcloud instances as external storage, which means you might be able to get some replication going
<niemeyer> dasjoe: Thanks for the note on DMARC
<niemeyer> dasjoe: Given the docs on https://wiki.list.org/DEV/DMARC, I'm not sure how much we can improve the situation, I've sent a note to our admin team to see what they might be able to pull off
<pitti> ogra_: not sure -- what would tell the interface to go to sleep at boot? "sleep" as in "suspend"?
<ogra_> pitti, good question ... i dont think ppisati's idea flies though ... nothing should touch the state before console-conf even runs and it only happens on very first boot
<ogra_> i still find crda more plausible
<ogra_> i'll do a bit more debugging tomorrow, my post-sprint-cold is really hitting badly today
 * ogra_ goes to find some hot tea and honey
<kyrofa> ogra_, yeah it sucked huh?
<kyrofa> ogra_, just on the tail end here
<ogra_> me too ... luckily no fever ... but it is at a point where the coughing hurts in the muscules
<kyrofa> ogra_, yep, same cold it seems
<mup> PR snapd#2214 closed: overlord/snapstate: fix revert followed by refresh to old-current <Critical> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2214>
<mup> PR snapd#2210 closed: debian: only install share/locale if available (missing on powerpc) <Critical> <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2210>
<zyga> OerHeks: hey, how are you feeling?
<zyga> hmm
<zyga> ogra_: ^^
<zyga> OerHeks: (sorry0
<mvo> ogra_: quick question - pi2 from edge seems busted for me, no networking. do you see that as well or am I just unlucky?
<ogra_> mvo, using my daily ?
<ogra_> mvo, it worked for me on sunday, havent tested pi2 since
<mvo> ogra_: freshyl build, I explore it a bit
<ogra_> no networking at all ? like no eth0 in console-conf ?
<mvo> ogra_: still exploring, no console-conf, but maybe a bad sd card, let me re-run, especially if its not anything known
<ogra_> no console-conf ?
<ogra_> how long did you wait ?
 * mvo reflashes
<mup> PR snapd#2216 opened: snap: skip all ram disks when auto-importing assertions <Created by mvo5> <https://github.com/snapcore/snapd/pull/2216>
<mvo> ogra_: aha, new flash on fresh card looks much better
<ogra_> phew
<mvo> ys
<mvo> yes
<ogra_> pi2 should be pretty good ... (at least that was my impression on sunday)
<mvo> ogra_: yeah, I think there was a short hickup but edge is looking good, I will wait for QA to verify but I think new images can be released soon (hopefully tomorrow) with the final fixes. and then I guess we will need something later for pi3/dragonboard. unless mwhudson gets your two bugs under control while I sleep :) I would love to see that!
<ogra_> mvo, well, GA is not this week :)
<ogra_> see the ML thread
 * mwhudson waves
<ogra_> mvo, we have some time left for the arm images
<mwhudson> ogra_: so because i'm lazy and to save time, which image should i use to reproduce wlan issues on dragonboard?
<ogra_> if we have the fixes by next monday we're fine i'd say
<mvo> mwhudson: hey, good morning! you are up early(?)
<mwhudson> ogra_: http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ubuntu-core-16-dragonboard-410c.img.xz
<mwhudson> mvo: it's 0900 so not really
<mvo> (me is confused about TZ)
<mvo> mwhudson: oh, then I'm just confused :)
<ogra_> mwhudson, http://people.canonical.com/~ogra/snappy/all-snaps/daily/
<mwhudson> mvo: we're in summer time now, you are not any more?
<ogra_> whatever latest you find there
<mwhudson> ogra_: ok
<ogra_> mwhudson, regarding the rpi i have a strong suspicion that we do not set up some bits for crda that are only in place on second boot (which is why the device then has a wlan0) ... but i'm to sick to move on today and need some rest
<mvo> mwhudson: I think I just looked at the wrong city :) in any case, great to hear that you are looking into it
<ogra_> there is a small possibility that the wifi timeout on the dragonboard is related ... but debugging the dragon is a lot harder
<mwhudson> ogra_: i don't have any pi hardware
<ogra_> yeah
<ogra_> well, the systemd.debug-shell arg helps a lot ... but for that you need to change uboot.env on the SD
<mwhudson> yeah
<mwhudson> can i just edit that with vi or do i have to clown about with mkimage and stuff?
<ogra_> you can re-generate it http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/dragonboard/README
<mwhudson> ah, thanks
<ogra_> grab the uboot.env.in from that tree, edit mmcargs between the quotes and re-generate the uboot.env ... then copy it on the system-boot partition
 * ogra_ needs to go ... 
<mwhudson> ogra_: sleep well
<mup> Bug #1613572 changed: sandbox denials for snaps on BTLE device <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1613572>
<mup> Bug #1627309 changed: bluetooth-control noble.js not working <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1627309>
<mwhudson> cyphermox: hey
<cyphermox> mwhudson: hey
<mwhudson> cyphermox: i've reproduced the wlan problem on my dragonboard too
<mwhudson> pretty sure it's not console-conf's fault, the config looks fine
<cyphermox> right
<mwhudson> cyphermox: do you know what "sed: can't read /run/systemd/netif/leases/*: No such file or directory" in syslog is about?
<cyphermox> mwhudson: there is no file in that directory?
<cyphermox> no idea what tries to do that though
<mwhudson> well sure but why is it in syslog
<mwhudson> bah my board doesn't boot when i try to enable debug shell, i guess i'm doing something wrong
<cyphermox> what's before that line in syslog?
<cyphermox> like, what is the full context?
<mwhudson> ah sorry gone now
<mwhudson> it was after the wlan associated though
<mwhudson> mmcargs=setenv bootargs "${args} console=ttyMSM0,115200n8 root=${mmcroot} systemd.debug-shell"
<mwhudson>  <- looks right?
<cyphermox> yeah, looks fine
<mwhudson> actually i think it's the uboot.env.in -> uboot.env thing that's breaking me
<mwhudson> maybe
<rharper> mmm, core boot debugging fun;  misery loves company
<mwhudson> heh
<bschaefer> hello, so for the snap cmake plugin the root level CMakeLists.txt file is not in the root dir ... and slightly dependent on its location. Any news on that coming to the plugin anytime soon :)?
<mwhudson> cyphermox: so stranger and stranger, i rebooted and the device was associated but it fell off the network when i tried to enter my email address
<mwhudson> Oct 25 21:16:00 localhost systemd-networkd[1510]: Could not load configuration files: Permission denied
<mwhudson> waaait umask is inherited, right?
<mwhudson> yes
<mwhudson> ok this is all my fault
<mwhudson> ogra_: sorry!
<mup> Bug #1611978 changed: Incomplete x11 interface <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1611978>
<mup> Bug #1636633 opened: Content interface supports multiple sources, but only one destination <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1636633>
<mwhudson> cyphermox: https://github.com/CanonicalLtd/subiquity/pull/176 if you want a look
<mup> PR CanonicalLtd/subiquity#176: remove setting of umask, redact wifi password from log file <Created by mwhudson> <https://github.com/CanonicalLtd/subiquity/pull/176>
<mwhudson> uh do i have to run ubuntu-image as root ?
<mwhudson> it was working as me for a long time
<mup> Bug #1636229 opened: Allow programs to write hidden files in home directory <snapd-interface> <Snappy:Incomplete> <https://launchpad.net/bugs/1636229>
<cyphermox> mwhudson: +1 on the merge, thanks
<mwhudson> cyphermox: going to cut a release, do we want anything else?
<cyphermox> don't think so
<cyphermox> make sure to  make it without ~xenial
<cyphermox> only change it after ;)
<mwhudson> yeah ok :)
<cyphermox> ie. the real tag shouldn't have a tilda, etc. etc.
<mwhudson> ok uploading to zesty
<mwhudson> and the ppa
#snappy 2016-10-26
<mup> Bug #1633289 changed: network-observe plug is not working for dracnmap snap <Snappy:Fix Released> <https://launchpad.net/bugs/1633289>
<mup> Bug #1636657 opened: spread not able to run the snapd test suite <Snappy:New> <https://launchpad.net/bugs/1636657>
<liuxg> when I run a shell command like "sudo snap run --shell hello-xiaoguo.env", it gives me the error like "sudo: no tty present and no askpass program specified". Does anyone know why?
<vigo> morning snappy
<vigo> niemeyer, ping
<dholbach> good morning
<mwhudson> good morning
<mup> PR snapd#2216 closed: snap: skip all ram disks when auto-importing assertions <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2216>
<Chipaca> ogra_, o/
<vigo> fgimenez, ubuntu-core-reboot failed again with core 279 on dragonboard
<vigo> fgimenez, https://pastebin.canonical.com/168964/
<fgimenez> vigo, when the suite has finished you can open a shell for inspection after the failing test with "spread -v -reuse -debug external:ubuntu-core-16-arm-64:tests/main/ubuntu-core-reboot"
<akey> need advice, what snap should i choose - postgresql96 or postgresql-9-6
<akey> first have "cmd" in field developer and second - "stub"
<stub> akey: cmd are apparently command prompt, so I'd go with that if it works. I haven't had a chance to look at it yet
<stub> akey: I'll be deprecating mine in favour of cmd if it works as intended, so I'd love to hear how you go.
<akey> will try
<akey> thanks
<vigo> fgimenez, sure give me some minutes(meeting) ;)
<ogra_> Chipaca, yo !
<Chipaca> ogra_, oh hi
<Chipaca> ogra_, since pinging you we decided to rewrite the thing i was struggling with in C
<ogra_> Chipaca, console-conf ?
<ogra_> :D
<Chipaca> ogra_, sadly, no
<Chipaca> ogra_, the shutdown script thingie
<ogra_> ah
<Chipaca> ogra_, basically the busybox in initrd isn't enough, and it's dynamically linked so it'd be a pain to set up
<ogra_> we have a busybox-static package for this
<Chipaca> ogra_, yes, which would add over a meg to the initrd
<ogra_> 2M actually
<ogra_> yeah, do it in C :)
<Chipaca> $ ls -lh bin/busybox /bin/busybox
<Chipaca> -rwxr-xr-x  1 root root 1.9M Aug 19  2015 /bin/busybox
<Chipaca> -rwxr-xr-x 91 john john 325K Oct 25 22:50 bin/busybox
<ogra_> yep
<Chipaca> that's just over 1.5M
<Chipaca> anyway! yeah
<ogra_> Installed-Size: 2.058 kB
<Chipaca> most of the hard work has already been done by zyga in snap-confine
<ogra_> from apt show
<Chipaca> hah, if you're looking at apt show i probably win
 * Chipaca looks
<Chipaca> Installed-Size: 376 kB
<ogra_> well, apt show means i dont neeed to install it :) and it lists all package files
<Chipaca> dammit
 * Chipaca concedes
<ogra_> s/lists/counts/
<ogra_> anyway C sounds good
<Chipaca> ogra_, anyway, every time i look at initrd i want to get my chainsaw out
<Chipaca> ogra_, e.g. it ships two libcs
<ogra_> that is currently being fixed
<Chipaca> ogra_, https://www.youtube.com/watch?v=A52p9jc-gOo
<ogra_> for zesty though ... but i guess we can backport some bits
<vigo> fgimenez, running it I'll paste it here
<hiseni> Hi, guys! I want to package an app, but it uses Maven Build System: https://github.com/mesonbuild/meson and I can't find any info about using this one w/ spapcraft
<ogra_> heh
<hiseni> Anyone can help me desidehow to do it better?
<mup> Bug #1636762 opened: [snapd] Failures in the spread test suite <Snappy:New> <https://launchpad.net/bugs/1636762>
<mup> Bug #1636764 opened: Snapd is not correctly initialized with UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL=1 and model assertion is invalid <Snappy:New> <https://launchpad.net/bugs/1636764>
<MikeB> Is this channel archived anywhere?  I looked on snapcraft.io but couldn't find a reference.
<ogra_> MikeB, https://irclogs.ubuntu.com/2016/10/26/%23snappy.txt
<ogra_> or https://irclogs.ubuntu.com/2016/10/26/%23snappy.html
<ogra_> :)
<MikeB> ogra_ Thanks!
<chihchun> higgins: check out this project, which use maven. https://github.com/ubuntu/snappy-playpen/tree/master/wallpaperdownloader
<ogra_> mwhudson, dragonboard seems all fine again, thanks a lot !
<vigo> ogra_, this bug https://bugs.launchpad.net/snappy/+bug/1636762
<mup> Bug #1636762: [snapd] Failures in the spread test suite <Snappy:New> <https://launchpad.net/bugs/1636762>
<vigo> I tried to debug it but no way to do it it fails all the time
<vigo> https://pastebin.canonical.com/168977/
<vigo> fgimenez, have you any idea why it stucks when "Starting shell to debug"?
<fgimenez> vigo, nope, haven't tried it myself, will let you know how it goes
<ogra_> vigo, i havent much clue about spread ... but i can imagine the dragonboard kernel lacks fuse support which could cause the fuse interface issue in that list
<vigo> ogra_, is there a bug for that already?
<ogra_> a bug about my imagination ? not yet, no :)
<ogra_> (i havent checked if thats true ... just a guess )
<fgimenez> vigo, ogra_ updated info about bug #1636762, now trying to debug tests/main/ubuntu-core-reboot but doesn't seem worrying
<mup> Bug #1636762: [snapd] Failures in the spread test suite <Snappy:New> <https://launchpad.net/bugs/1636762>
<ogra_> fgimenez, isnt that what Chipaca currently works on (the reboot fixes) ?
<vigo> ogra_, fgimenez thanks
<fgimenez> ogra_, not sure, we have issues with this test before, it checks for a snap service to be up after a reboot and we weren't waiting long enough, now it works fine on other platforms and only fails on dragonboard
<ogra_> fgimenez, ah ... weird though ...
<mvo> ogra_: hey, I shared a gdoc with you, curious to  know if I understand the dtb problem correctly
<ogra_> yeah, just got the mail
 * ogra_ goes reading
<mvo> ogra_: great, thank you! feel free to correct my assumptions in there if I got something wrong
<ogra_> mvo, updated
<mvo> ogra_: thanks
<mvo> ogra_: iirc you also mentioned the binary bootloader added stuff to the dtb in memory, so we really need to use the version in memory, do I remember correctly?
<ogra_> right
<ogra_> board serial and MAC
<ogra_> you need to serial in /proc/cpuinfo because if you purchase a codec for the board it uses this to validate the codecs
<mvo> ogra_: great, added that as well
<ogra_> and only the first stage loader can read it from ROM
<mvo> ogra_: this really sounds like there is no way out of it, i.e. we can not revert to a previous kenrel without rewrting the dtb and reloading it. maybe via some scripting in uboot.env?
<mvo> ogra_: anyway, thanks a bunch, I think the problem is much clearer now, the solution is still tricky, will discuss in todays standup
<ogra_> mvo, well, there might be ways with a newer uboot ... the main issue here is the overlay handling ... i could cheat a lot from uboot (loading from disk and overwrite parts of the dtb in ram etc)  but uboot cant load the overlays
<ogra_> there was work in newer uboot to start supporting overlays generically but i dont know where that stands
<iliv> what is revision really? i just installed a package with the same name but different version number without removing a previous version. I noticed that revision number incresed, even though it's a newer version that is installed now. this kinda doesn't make any sense. if it's a new version, just installed, revision should be x1, not x2.
<ogra_> just overwriting the basic dtb from disk and keeping the info from ROM still around is possible afaik
<mvo> ogra_: oh, so we could always keep the one that was used on install and load a kernel specific one into memory and ship that as part of the kernel snap?
<ogra_> mvo, well, you would need to merge them ... since you need what the binary loader artificially writes to the ram one when reading the rom
<ogra_> i.e. serial and MAC
<ogra_> mvo, but to use any addon board on the Pi you need an overlay DTB ... and for that only the binary loader works ... you could only get the overlay loaded for the original DTB, not for the current one
<mvo> ogra_: I add to the gdoc: stuff gets even more complicated with overlay dtbs ;)
<ogra_> heh, yeah, i also added a description at the top paragraph about that
<fgimenez> vigo, ogra_ confirmed that for tests/main/ubuntu-core-reboot we need to wait a little bit more on dragonboard http://paste.ubuntu.com/23383345/
<ogra_> hmm, i wonder why ... it isnt like the dragonboard boots particulary slower than a pi2 or 3
<vigo> ogra_, with latest image I  noticed it takes more time than before
<vigo> but at least, I can now use wifi :)
<vigo> fgimenez, ack thank you
<mup> Bug #1636847 opened: unexpectedly large memory usage of mounted snaps <Snappy:New> <https://launchpad.net/bugs/1636847>
<niemeyer> vigo: Hi
<niemeyer> morphis: On the standup call, but will be with you in a few mins
<liuxg> kyrofa, good morning what was your finding yesterday regarding the configure hook?
<mup> Bug #1636864 opened: ubuntu-image 0.10+real1 is broken <Snappy:New> <https://launchpad.net/bugs/1636864>
<dobey> how can i boot the snappy core image without logging in to u1?
<zyga> dobey: you can create a different brand (e.g. by forking the gadget and model assertion) and then using the system-user assertion to create an user on first boot
<zyga> dobey: AFAIK
<dobey> zyga: no idea how to do that. on first boot i get the initial setup thing and it's requiring me to log in, and i can't actually type the e-mail address in the field
<zyga> dobey: what happens when you try?
<dobey> zyga: "nothing" i guess. i can type an e-mail, but i can't type a + character for some reason, so i can't type the test e-mail to log in with
<zyga> dobey: keyboard setup is not done beffore this is finished, I suspect you can type + if you use a US / international keyboard
<ogra_> we switched to only support chinese keyboards and utf16 :P
<dobey> zyga: i AM using a US keyboard
<zyga> dobey: then I don't know
<ogra_> (kidding indeed, it defaults to US only kbd though)
<dobey> trying to boot the image in a kvm
 * ogra_ does that ten times a week ... 
<dobey> https://developer.ubuntu.com/en/snappy/guides/mir-snaps/
<ogra_> but i never had a + sign in my mail address
<dobey> trying to follow the instructions there to get it booted; but can't type + and can't log in
<dobey> err and can't skip the login
<ogra_> well, no, there is no local way to log in anymore
<ogra_> the user creation pulls your ssh key from your LP account and puts it in place
<dobey> :-/
<ogra_> you can then ssh in and use "sudo passwd $USER" in case you need a console login
<ogra_> but by default the local logins are locked
<ogra_> kvm -m 1500 -redir tcp:8022::22 amd.img
<ogra_> thats what i use here to set it up ... keystrokes work fine
<dobey> you can type a + char in the login field in the initial setup?
<ogra_> well, i can type a + when i'm logged in on console
<rharper> dobey: it's a bug
<ogra_> which should be the same
<rharper> it's not
<rharper> there's an input box with a regex filter
<rharper> dobey: I can reproduce
<ogra_> oh, really ?
<ogra_> ah
<rharper> in console-conf
<ogra_> right, input wise it shopuld be the same ... i wasnt aware there is a regex
<ogra_> rharper, does mwhudson know already ?
<zyga> dobey: can you please report this?
<zyga> dobey: just in case
<zyga> dobey: you an also try this
<zyga> dobey: boot your VM with -display curses
<zyga> dobey: log in this way
<zyga> dobey: and then shut down and boot with SDL
<ogra_> zyga, how does that help if the + is filtered out in the user creation input field
<ogra_> it is console-conf itself filtering that
<ogra_> no frontend switch will fix that
<dobey> well there's no information in the setup stuff either, so i guess even if i can log in it doesn't help me much
<zyga> ogra_: I don't know, maybe it helps, maybe it doesn't
<zyga> ogra_: I see
<ogra_> unlikely ... being an app bug
<rharper> ogra_: probably not;
<ogra_> well, it would help if someone filed a bug against subiquity :)
<rharper> console-conf/ subiquity, whatever
<dobey> so where?
<ogra_> https://bugs.launchpad.net/ubuntu/+source/subiquity/+filebug
<ogra_> and open a task against the snappy project too please
<zyga> ogra_: is this it? https://github.com/CanonicalLtd/subiquity
<ogra_> i guess so
<dobey> https://bugs.launchpad.net/snappy/+bug/1636891
<mup> Bug #1636891: Unable to log in using email with + character <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1636891>
<mup> Bug #1636891 opened: Unable to log in using email with + character <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1636891>
<rharper> dobey: thanks
<mup> Bug #1636894 opened: [raspberry pi3]pi3 snap is removable  <Snappy:New> <https://launchpad.net/bugs/1636894>
<mup> PR snapd#2217 opened: tests: increase wait time for service to be up <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2217>
<mup> PR snapcraft#861 closed: python plugin: install from wheel for local setup.py <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/861>
<kyrofa> liuxg, ping
<mup> Bug #1634803 opened: snapcraft register-key doesn't use U1 SSO login credentials <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1634803>
<ppisati> ogra_: the wifi card on your rpi3 board is broken, i tried several different combinations
<ppisati> ogra_: but with none of them it shows up
<ppisati> ogra_: i even tried raspbian, but nothing
<ogra_> ppisati, it shows up after reboot
<ppisati> ogra_: no no, i mean your board
<ogra_> just on on first boot
<ppisati> ogra_: do you remeber that we exchanged board at the sprint?
<ogra_> oh, yeah!
<ppisati> ogra_: i can't get the wifi to show up _at_all_
<ogra_> thats what you mean
<ogra_> wow
<ogra_> that used to work
<ppisati> ogra_: classic, snappy, raspbian, etc
<ppisati> ogra_: i expensed a new rpi3 board
<ogra_> creap
<ogra_> i guess i owe you a beer then, i bet it was the "plug HDMI whiloe on power"
<ppisati> ogra_: probably, the spi/i2c expansion bus is busted too, so...
<kgunn> kyrofa: hey, if i have a branch i'm building in a snap, and i just wanna cheat & save time...a-la snap clean thing --step=build
<ogra_> (i always forget that there is no proper grounding)
<kgunn> where do i modify the source?.... in the part folder?
<kyrofa> kgunn, you want to modify the pulled source?
<kyrofa> kgunn, yeah, it's in parts/<partname>/src
<ogra_> ppisati, i still cant imagine why it would be PM though ...
<kyrofa> kgunn, though note that if the source is local, they're hard links. That might help a little
<ogra_> ppisati, i.e. why does it only happen on the very first boot
<ogra_> i would expect it to have similar issues after reboot
<kgunn> kyrofa: right, just the pulled src
<kgunn> yeah, it's not local...
<kyrofa> Then yeah, that's what you want
<kgunn> avoiding the separate change+push
<kyrofa> Careful not to kill your changes by cleaning completely, though!
<kgunn> will push later when i figure it out :)
<kgunn> @complete clean...right!
<nothal> kgunn: No such command!
<ogra_> defiant bot ... doesnt want to clean
<mhall119> sergiusens: do we have a method yet to copy a .desktop file produced by a part's build step into ./setup/gui/ ?
<sergiusens> mhall119 that was only discussed last week during a session
 * mhall119 wishes we had videos of those sessions
<ogra_> mvo, bug 1636894 smells a bit critical
<mup> Bug #1636894: [raspberry pi3]pi3 snap is removable  <Snappy:Confirmed> <https://launchpad.net/bugs/1636894>
<kgunn> kyrofa: got a minute? wanna describe something and see if you've got an idea i can try...
<kyrofa> kgunn, yeah, what's up?
<kgunn> kyrofa: ok, so, i've got 2 snaps (it's a form of mir-server and mir-client, but not exactly)....
<kgunn> i can build these in classic on the core, and it works without a flaw...
<kgunn> however, when i run the exact same sceario on snaps...here's how it goes down
<kgunn> the mir-server comes up fine, nothing strange in logs....but the minute i launch the client the server crashes immediately
<kgunn> and again, nothing really showing up in logs
<kgunn> so...wondering, can i include gdb inside my mir-server snap and run it ?
<kgunn> or some trick like that you might recomment
<kgunn> recommend even
<ogra_> snap run --shell $command_inside_your_snap
<ogra_> then use gdb from that shell
<kyrofa> ogra_, that's still under the same confinement though, no?
<kgunn> ogra_: well, i can run unconfined, the trouble occurs no matter waht
<ogra_> also, the classic snap (that i demoed at the sprint) allows attaching to PIDs
<ogra_> so just apt install gdb and debug away i guess
<kyrofa> kgunn, as ogra_ mentions, could you run gdb as normal and attach to the PID of the app?
<ogra_> kyrofa, yeah, inside the confinement ... but your gdb runs inside the same sandbox at least
<kyrofa> kgunn, I've also included strace in my snaps before, I can't imagine why gdb wouldn't also work
<kgunn> ogra_: kyrofa cool...i'll try that, thanks guys
<kyrofa> ogra_, I mean it doesn't have access to gdb
 * kgunn already has classic setup on the image
<ogra_> not to one you dont ship indeed
<kgunn> oh while i'm here... ogra_ flexiondotorg do either of you have a recommended power supply to use with pi3
<ogra_> as many amps as you can get :P
<ogra_> current is key .... beyond that ... not really
<kgunn> i got one...but it came with w a charger that has a micro usb...and i don't think its strong enough to drive the display
<ogra_> ah, attached usb display powered from the onboard usb hub ?
<kgunn> ogra_: right
<ogra_> s/usb/hdmi/
<kgunn> ogra_: i guess i could try an externally powerd display first...
<ogra_> i'd go with something like 4A
<kgunn> cool
<ogra_> that should be able to even drive a rotary usb disk
<kgunn> :)
<kgunn> uh, i guess i should also include dbg syms into my snap
<ogra_> heh, yeah, that helps
<mvo> ogra_: right, super important, not quite critical as you need to do manually disable it first, will work on a fix now
<ogra_> heh, i didnt mean to cause work for you, i just wanted to set the severity :)
<mvo> ogra_: thats fine, I think its also high++ priority :)
<ogra_> true :)
<mup> PR snapcraft#867 closed: Handle 'broken' validations that don't match refresh-control <Created by ralsina> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/867>
<liuxg> kyrofa, ping
<kyrofa> liuxg, pong
<Croepha> So, if I wanted ubuntu core to have grub that had serial console enabled, I would have to make a new pc snap, ( i think thats the gadget snap) is that right?
<ogra_> Croepha, we do have serial enabled by default i think
<ogra_> (if not, we probably should)
<Croepha> It looks like its enabled for the kernel, but not grub
<Croepha> although, with pretty much everything snappy related, im pretty sure its not working right, because I probably did something to mess it up
<mup> PR snapcraft#873 opened: Release changelog for 2.20 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/873>
<ogra_> ah, yeah, not sure about serial support in grub itself
<ogra_> we definitely have a console= arg for serial on all images
<Croepha> nice
<mup> PR snapd#2218 opened: snapstate: ensure gadget/core/kernel can not be disabled <Created by mvo5> <https://github.com/snapcore/snapd/pull/2218>
<Croepha> btw, hypothetically, is core setup for PXE booting? seems like there is a lot of really cool potential to have the snaps mounted on a RO nfs mount and have writable portion be on a RW nfs mount or using aufs or something? is this an explored subject? or unexplored? or determined to be out of scope? just curious?
<mup> Bug #1636931 opened: Configure hook not running <Snappy:New> <https://launchpad.net/bugs/1636931>
<mup> PR snapd#2219 opened: asserts: limit to 1y only if len(models) == 0 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2219>
<pmcgowan> ogra_, two questions if you have a min
<pmcgowan> $ snappy config core
<pmcgowan> qemu-system-x86_64: could not set up host forwarding rule ':4200::4200'
<pmcgowan> qemu-system-x86_64: Device 'user' could not be initialized
<pmcgowan> oh thats an old command, bad docs
<pmcgowan> er
<flexiondotorg> kgunn, Pi3 power requires minimum of 2.4amp
<kgunn> ack
<kyrofa> mvo, I seem to remember discussions about more `snap run` options, like --gdb and --strace, is that right?
<ogra_> pmcgowan, heh, happy i could be of help :)
<pmcgowan> ogra_, but my real question
<pmcgowan> my refresh service isnt running, seems it should be?
<pmcgowan> how do I check the autoupdate config?
<ogra_> uh, i dont know ... i know it is a timer
<ogra_> systemctl | grep timer
<ogra_> ?
<pmcgowan> ogra_,  systemctl status -l snapd.refresh.service
<pmcgowan> says its inactive
<pmcgowan> and systemctl list-timers snapd.refresh.timer
<ogra_> well, not sure the service contains the timer, i think that is what the timer calls actually
<pmcgowan> says 0 timers
<pmcgowan> no snap timers
<pmcgowan> ogra_, there is a refresh timer on dragonbaord
<ogra_> i think Chipaca is our specialist for that bit ... bt he doesnt seem to be around
<pmcgowan> not on pc
<ogra_> weird
<ogra_> same image ?
<pmcgowan> image?
<ogra_> (i mean ... installed from the same image ... i.e. around the same time)
<ogra_> yeah
<pmcgowan> core versions are the sam
<pmcgowan> e
<ogra_> that doesnt matter, the timers are part of the firstboot setup
<pmcgowan> this is on my laptop though
<ogra_> and that might have improved between different image builds (or core versions if you want it like that)
<ogra_> oh
<ogra_> i thought you talk kvm vs dragonboard all-snap images
<pmcgowan> no sorry
<pmcgowan> apple orange
<ogra_>   snapd.refresh.timer                                                                                loaded active waiting   Timer to automatically refresh installed snaps
<ogra_> that is whyt i get on my laptop
<ogra_> *what
<pmcgowan> hmm
<pmcgowan> thats what I see on db
<ogra_> not sure why yours is disabled ... i think there was a bug once
<pmcgowan> how do I enable it now
<ogra_> bug 1588977
<mup> Bug #1588977: [2.0.6] snapd.refresh.timer fails <regression-proposed> <verification-done> <xenial> <snapd (Ubuntu):Fix Released by carrol1> <snapd (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1588977>
<pmcgowan> ogra_, let me try t enable it
<mup> PR snapd#2218 closed: snapstate: ensure gadget/core/kernel can not be disabled <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2218>
<mup> PR snapd#2219 closed: asserts: limit to 1y only if len(models) == 0 <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2219>
<pmcgowan> ogra_, its working now and I got the update I expected
<ogra_> yay
<mup> Bug #1610001 changed: Regression: snap run no longer runs hooks <Snappy:Fix Released by kyrofa> <https://launchpad.net/bugs/1610001>
<mup> PR snapd#2220 opened: overlord/snapstate: fix missing argument to Noticef <Created by zyga> <https://github.com/snapcore/snapd/pull/2220>
<mvo> kyrofa: yes, we talked about this
<kyrofa> mvo, still planned, then?
<kyrofa> Just wanted to make kgunn aware, but wanted to make sure I remembered correctly first :)
<mvo> kyrofa: yes but no dates or priority attached to it
<kyrofa> Sure
<kyrofa> Thanks mvo :)
<mvo> yw
<kgunn> ack
<kyrofa> So kgunn as ogra_ mentioned we have `snap run --shell <app>`. That enables you to debug if you include strace/gdb/etc. in your snap, but eventually we'll have `snap run --gdb <app>` and `snap run --strace <app>` and the like
<kgunn> cool
<kgunn> fwiw, i just tried from classic snap...i attached to the pid ok, but then nothing...at least when i crashed the process...no output (altho could be user idiocy)
<ogra_> check syslog
<ogra_> if there is any seccomp blocking or anything
<kgunn> when doing snap run --shell <app> ....is <app> really the service name ?
<kgunn> e.g. is snap run going to launch my service?
<kyrofa> kgunn, it won't run anything if you use --shell, but yeah, it can be a service
<kyrofa> At least... I assume (not tried myself)
<kyrofa> ogra_, are you still around?
<ogra_> semi :)
<kyrofa> ogra_, dumb question: if the kernel snap updates, does the device reboot?
<ogra_> hmm, i would expect so ...
<ogra_> but mvo knows the code ...
<mvo> kyrofa: it does - after a delay of some minutes
<ogra_> (i definitely had a reboot today after the new kernels landed)
<kyrofa> mvo, ogra_ good deal, thanks. I figured that was the case, I just realized that hasn't happened to me yet on a core-based image, so wanted to double-check
<ogra_> kyrofa, use dailies if you like reboots ;)
<kyrofa> ogra_, :P
<ogra_> edge gets a new core every day
<kyrofa> ogra_, a core update doesn't cause a reboot, right?
<ogra_> it does
<kyrofa> Huh, I didn't know that
<ogra_> you can intercept with shutdown -c
<ogra_> (it warns you)
<kyrofa> Why? Just because we figure running services are using libs from it?
<mwhudson> rharper, dobey: oops (re email addresses)
<mwhudson> rharper, dobey: are any other characters missing?
<rharper> mwhudson: I went searching (briefly) for reasonable email regex and I couldn't find anything definitive
<mwhudson> https://github.com/CanonicalLtd/subiquity/pull/178
<mup> PR CanonicalLtd/subiquity#178: allow + in email addresses <Created by mwhudson> <https://github.com/CanonicalLtd/subiquity/pull/178>
<mwhudson> rharper: i guess i could look at what lp itself allows...
<rharper> yeah
<rharper> or see if any of the security folks have a good best practices
<dobey> mwhudson: almost definitely. + is what broke for me though. but i'm a boring USian
<mwhudson> apparently = is allowed too
<kyrofa> mwhudson, tons of things are allowed-- the common advice I find is "beyond checking for @, don't bother validating. Just email to confirm."
<kyrofa> mwhudson, https://davidcel.is/posts/stop-validating-email-addresses-with-regex/
<kyrofa> mwhudson, best quote: "Look at all these spaces!"@example.com is a valid email address
<mwhudson> kyrofa: well you couldn't create an account on lp with such an address
<mwhudson> and i assume sso is the same but i haven't checked there
<kyrofa> mwhudson, yeah just trying to save you some googling for definitive regex, because there isn't one :)
<mwhudson> i am aware of that :)
<mwhudson> rharper, dobey, ogra_: is this worth doing a new release / upload for?
<mwhudson> i guess so, it blocks some people and is low risk
<ogra_> mwhudson, only if you want dobey as a uaer i guess :P
<ogra_> **user
<dobey> well i'm sure i'll find more bugs after i get past that ;)
<ogra_> word
<Croepha> is this the right way to use a ubuntu flavour in a snap kernel snapcraft.yaml: kdefconfig: kdefconfig: ['flavour=my_flavour', 'config']
<mwhudson> hm i guess mvo is asleep
<Snappin> Hi. Can anyone provide ANY info on backing up data created from a snappy app? Nextcloud for ex?
<kyrofa> Snappin, there are a limited number of places snaps can write. Nextcloud for example will always dump its data into /var/snap/nextcloud/common (unless you change it in the config)
<kyrofa> data = nextcloud raw data. The config, apps, etc. go elsewhere
<kyrofa> (/var/snap/nextcloud/current to be exact)
<Snappin> kyrofa: so let's say I dump that directory and want in case i have a server failure. So I rebuild my server, do the snap install nextcloud. So I just dump the backup there and call it a day?
 * Snappin is baffled backup & restore isn't covered ANYWHERE in the docs....
<kyrofa> Snappin, well, ignoring the snap, how does one backup a nextcloud install?
<kyrofa> Snappin, it's because it's always going to be application-specific, not snap-specific
<Snappin> it's a multi-step process and is documented.
<Snappin> kyrofa: ok I understand that. so is it safe to assume there isn't or never will be a common procedure to backup/recover of snappy install critical data?
 * Snappin is trying to decide if diving further into snappy tech is worth it...not trying to be rude or critical.
<kyrofa> Snappin, you can always copy it off and paste it back, but the application may not pick it up like that
<Snappin> ok. that's sounds too risky for me. I see the appeal of snaps but not if there is going to be an unpredictable outcome of data recovery.
<Snappin> Do you know if future roadwork with snappy will involve my concerns regarding backup/recovery?
<kyrofa> So in order to migrate a Nextcloud install, what do you do? You dump the database, copy the raw data and the config, and then apply in reverse order
<Snappin> i only know how to backup/restore nextcloud by hand if i install it by hand.. this is well documented on the web.
<Snappin> Thanks though, i think i've found my answers.
<jdstrand> sergiusens: hey, would you mind approving https://myapps.developer.ubuntu.com/dev/click-apps/5063/rev/3/ ?
<jdstrand> sergiusens: I made some changes to the review tools so that will pass, but that needs a store sync
<hindle> I'm trying to package with snappy (confinement: strict) a application (not service) that opens unix sockets at say /tmp/socket1 - Currently I get access dennied errors. I see that for services I can use "caps:" property but I can't find any documentation on how it can be done for apps.
<qengho> hindle: You don't get access to /tmp . You can get a personal, ephemeral tmpdir. If you're trying to do something that has some system-wide known name, you want a service.
<hindle> qengho: thanks - I'm trying to do IPC via unix sockets - between different apps in the same snappy packge.
<hindle> qengho: but I still can't seem to open a unix socket at a writtable path for the snappy application.
<hindle> qengho: so I assumed I need to add some privilage to the app.
<jdstrand> hindle: you can do that fine if you create it in one of the writable areas for the snap
<jdstrand> (other than /tmp)
<hindle> jdstrand: thanks
#snappy 2016-10-27
<qengho> hindle: If it's between the same system user's running apps, just use $SNAP_USER_DATA/socket1
<josharenson> Does anyone know anything about a snapcraft.yaml for unity8?
<josharenson> I know it doesn't really work yet, but I'm trying not to reinvent the wheel.
<ahoneybun> mhall119: that RocketChat snap is really bad on mainline kernels
<ahoneybun> apparmor complains all over
<ahoneybun> someone in here told me I have to recompile the kernel with the patches but that is just too much work
<mup> Bug #1637046 opened: requesting "quiet" mode <canonical-is> <Snappy:New> <https://launchpad.net/bugs/1637046>
<dholbach> good morning
<didrocks> hey dholbach
<dholbach> salut didrocks
<mup> Bug #1637093 opened: docs/config.md needs an update <snap-docs> <Snappy:New> <https://launchpad.net/bugs/1637093>
<vigo> ogra_,  morning, I got "Can't find valid F2FS filesystem" in pi3 after runnning spread
<ogra_> vigo, hmm, i thought mvo fixed that yesterday, thats an old warning
<mvo> ogra_: not quite fixed, the branch was up but tests need some serious rethinking (we use the ramdisks in the tests to simulate block devices)
<vigo> mvo,  morning, have you a bug for it?
<vigo> mvo, I watched the rc2 images, the one for pi3 is building right?
<mvo> vigo: http://people.canonical.com/~mvo/all-snaps/rc2/ is the current place for them
<vigo> mvo, great :) flashing dragonboard
<bzoltan> hi folks. Is there a way to trigger an action in the snapcraft after the stage to tar.gz up a part of the stage?
<didrocks> bzoltan: I would go for a custom plugin, which will be set "after: <other-parts>". This plugin can then access to the stage/ directory (and so tar.gz it)
<didrocks> does this make sense to you?
<bzoltan> didrocks: not really :)
<didrocks> ok, so you have multiple partsâ¦
<bzoltan> didrocks:  Ok, so you mean that i should create a snapcraft plugin for this feature?
<didrocks> yep
<didrocks> you create on part which is "tarring-stage", which is using your custom snapcraft plugin "tarring-stage"
<didrocks> this plugin, in the install phase for instance, do only one thing: take the stage/ directory and tar it up
<didrocks> to ensure this is ran after all other parts have done their jobs
<didrocks> you will need to specifying in tarring-stage:
<didrocks>   after: [list-of-other-parts]
<didrocks> to ensure all other parts have run the "install" step first (you may want rather to try "stage" btw)
<bzoltan> didrocks: is there a plugin template or a reasonable simple plugin I could use as pattern?
<didrocks> bzoltan: sure, look at the dump plugin for instance
<bzoltan> didrocks:  okey, I will look at that and others too. Thanks :) i kind of hoped for a ready feature for hooking up scripts
<didrocks> bzoltan: yeah, I know that was discussed, but not scheduled AFAIK
<didrocks> the plugin should be straightforward, do not hesitate to ask if you need any help
<bzoltan> didrocks:  no probs... it is doable
<didrocks> bzoltan: yeah, should be a couple of hours at max (with the example) :)
<bzoltan> didrocks: :)
<didrocks> bzoltan: again, do not hesitate if you need help with this, I'm happy to have a look
<bzoltan> didrocks:  I am fairly new to snapcraft internals... i was reading the scripts this week. There are few strange things there... but i will figure out
<ogra_> mvo, why is the dragonboard built from edge ?
<rvr> ogra_: Not correct?
<ogra_> rvr, well, after all we want to release candidate/beta
<rvr> ogra_: Ok, I will create an image with beta channel
<ogra_> rvr, no, that wont help if the snaps have not been updated
<rvr> ogra_: Oh
<ogra_> (i would have expected they move to candidate, then we get an image from there, test it and move them to beta )
<ogra_> (and do a final smoke test with a beta built image)
<mvo> ogra_: because I want to test it first before I promote it to candidate, once its promoted that snap goes out to all the candidate people
<ogra_> uuuh
<mvo> ogra_: we will have to do a final run after the image is in candidate
<mvo> ogra_: eh, build from candidate
 * ogra_ just hit crtl-alt-delete in console-conf
<ogra_> bad stuff ...
<ogra_> mvo, ah, we're not that far yet, ok
<mvo> ogra_: yeah, just dragonboard is missing, the other arches got promoted to candidate but I have no positive report from the dragon sofar
<ogra_> so my rpi3 hops from service to service on reboot ... 2x it sat there "waiting for job to stop" with a 2min timeout
<ogra_> one of them said "Snappy services" (whatever that is)
<ogra_> the other was something with "Sync from Network"
<ogra_> mvo, oh, btw ... if the gadget doesnt update files in /boot is that also true for all possible extra files it ships /the ones that get copied to /writable/system-data at image build time)
<ogra_> i envision we want to be able to update firmware files or binary blobs from the gadget
<mvo> ogra_: correct, this is currently not possible
<ogra_> ouch
<mvo> ogra_: we want this, its also very dangerous because if it goes wrong -> brick
<ogra_> well, i meant more extra files in /lib/frimware and graphics drivers we can not ship with the kernel snap
<ogra_> (that first sentence sounded wrong)
<mvo> ogra_: oh, ok. yeah, well, we need to add code for this, its not supported yet.
<ogra_> i.e. nothing bootloader related that could hard-brick anything
<mvo> yeah, thats fine, thats something we can easily add
<mvo> ogra_: if you want, plesae create a trello card
<ogra_> grrr ... wlan on pi3 still times out even on second boot ...
<ogra_> it is funny, i can configure eth0, ssh in and *then* run sudo console-conf and reconfiguring the network works just fine ... i get wlan and all
<bzoltan> didrocks: kind of starting with this - http://pastebin.ubuntu.com/23387537/ i wonder how I can know wherethe stage is?
<ogra_> just not when i do it on the first console-conf run
<ogra_> thats a joke !
<ogra_> so third attempt of configuring wlan on the pi3 the system boots and console-conf shows me the IP for wlan0 ...
<ogra_> yet ... configuring the network still times out
 * ogra_ wonders if we should have a skip button in the network settings of console-conf
<ogra_> i can actually ping the system until i hit "Done" in console-conf
<ogra_> mwhudson, ^^^ any idea ? seems a configured wlan gets messed up on second boot if i have not set up a user yet
<mup> PR snapd#2221 opened: tests: skip tests that use /dev/ptmx on ppc64el - it does not work here <Created by mvo5> <https://github.com/snapcore/snapd/pull/2221>
<cellash> Hello everyone, I have an issue with Snap that is frustrating me. I am trying to snapcraft the Telegram app (we have a repo on LaunchPad where we've added all the required files etc.) which snaps up perfectly fine on 16.04 Unity 7 however I'm currently on 16.10 and I keep getting this error and cannot resolve the problem and wondered if anyone on here would know what this error means or shed some light to how to resolve this? Heres what the console returns:
<cellash> http://pastebin.ubuntu.com/23387557/ Appreciate your time.
<ogra_> mwhudson, bah, i still see my wlan password in the console-conf logs ... right before the netplan yaml gets printed
<ogra_> hmm, actually multiple times
<ogra_> the actual yaml output says "REDACTED"
<joc_> cellash: is it the error on line 443 of your pastebin? missing intltool build-package possibly?
<ogra_> mwhudson, bug 1637145 for you ... (logs attached)
<mup> Bug #1637145: console-conf breaks working wifi when rebooting before user is created <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1637145>
<mup> Bug #1637145 opened: console-conf breaks working wifi when rebooting before user is created <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1637145>
<cellash> joc_: Installing intltool fixed the error! Thank you so much joc_!!
<joc_> yw :)
<mvo> ogra_: I think morphis found the bug
<ogra_> "the bug" ?
<vigo> ogra_, just confirmed that bug, it happened to me with db first and now with the pi3 :\
<ogra_> well, the pi3 still has other wifi probs
<ogra_> but yeah it is annoying
<bzoltan> didrocks: got it working http://paste.ubuntu.com/23387713/
<dhiraj> Hello guys!
<dhiraj> I would like to know if it is possible to use DDS middleware for communication between various snaps
<dhiraj> has anybody tried something similar? if not DDS then any other data sharing middlewares  like zeromq, rabbitmq of sorts?
<ogra_> mwhudson, and Bug #1637153 for you ...
<mup> Bug #1637153: plugging in a network cable when wifi config failed causes a traceback when restarting console-conf <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1637153>
<rvr> ogra_: mvo: Image is not resized again in the dragonboard :(
<ogra_> rvr, works fine here again :)
<rvr> /dev/mmcblk1p9  488M  477M     0 100% /writable
<mup> Bug #1637153 opened: plugging in a network cable when wifi config failed causes a traceback when restarting console-conf <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1637153>
<ogra_> rvr, yeah ... but unless anyone can reproduce it ....
<ogra_> rvr, i switched to godd recetly, try the same so we can rule out any dd options or weirdness
<ogra_> (snap install godd ...)
<rvr> ogra_: Ack
<ogra_> xzcat ./ubuntu-core-16-pi3.img.xz | sudo godd - /dev/sdc
<ogra_> thats what i do with it
<mup> PR snapd#2222 opened: tests: do not hardcode the size of /dev/ram0 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2222>
<didrocks> bzoltan: nice! :)
<bzoltan> didrocks:  i am hacking it forward to add the exludes and stuff... the idea is to provide a generic way to produce API packages.
<didrocks> bzoltan: yeah, I got what you wanted to do regarding SDK from your questions :)
<bzoltan> didrocks: :)
<mvo> ogra_: hi, sorry for not getting back earlire. what was the status of the dragonboard with networking? is it possible to generate a wlan config now? (that works)?
<ogra_> mvo, yeah
<ogra_> pi3 is still broked ... dragon works
<rvr> mwhudson: Hi. Does console-conf has any test suite?
<mvo> ogra_: pi3 is broken in what way? wireless not working at all, but wired works?
<ogra_> mvo, yep
<ogra_> mvo, no wlan0 on first boot ... and on every subsequent boot console-conf falls over when trying to configure the device ... funnily once you attempted to set it up it will be online just fine on reboot before console-conf touches it ... if it does thouh, the worlld falls apart (tracebacks, timeouts etc)
<rvr> lol
<rvr> If I configure incorrectly the network, I have no way to log in the machine
<rvr> 127.0.0.1 after reboot. Nice.
<ogra_> what board ?
<rvr> Dragonboard
<ogra_> is it just not showing the right IP or is it really not up ?
<rvr> I was re-running console-conf via ssh
<ogra_> ah
<ogra_> i have only done that on pi3 yet (because then wlan works just fine)
<rvr> ogra_: And pressed Done to re-apply the same settings
<ogra_> check /etc/netplan/, i think that doesnt store your wireless key anymore then
<ogra_> i have seen that
<rvr> I can't check anything :P
<ogra_> you cant yank out the SD ?
<rvr> Oh, that way
<ogra_> ogra@localhost:~$ uname -a
<ogra_> Linux localhost.localdomain 4.4.0-1032-snapdragon #36-Ubuntu SMP Wed Oct 19 14:37:43 UTC 2016 aarch64 aarch64 aarch64 GNU/Linux
<ogra_> ogra@localhost:~$ df -h /writable/
<ogra_> Filesystem      Size  Used Avail Use% Mounted on
<rvr> Reflashing now, will reproduce later
<ogra_> /dev/mmcblk1p9   57G  341M   54G   1% /writable
<ogra_> all fine here
<ogra_> (regarding resize
<ogra_> )
<rvr> ogra_: Weird :-/
<ogra_> yes, and nobody at the sprint could repro it
<sitter> hey. I am trying to upload the kde-frameworks-5 content share, it's being auto rejected based on 2 fails https://paste.kde.org/pty2tu57i the first I sounds like content interface is being rejected and the second I have no clue about. any help would be appreciated :/
<ogra_> i really dont get what your write process does to make this break
<mvo> sitter: when jdstrand is around he can probably help you. the content interface seems to need adding
<mvo> sitter: the other one is about a bunch of files with "sticky" bit, a bit strange, if you click on "request manual review" we can investigate more
<sitter> mh, I think the +s comes from the docker volume we build on. not that I'd know why it would be +s to begin with ^^
 * sitter investigates
<mardy> pstolowski: hi! Do you have a minute for a question on interface hooks?
<rvr> ogra_: Well, not it is resized (used godd)
<didrocks> sitter: for the first one, jdstrand is already aware about it (he had to approve mine manually)
<didrocks> not sure about the second one as well, you have quite some sticky bits, and I guess in doesn't like it
<ogra_> ppisati, bah
<ogra_> ppisati, did the beaglebone fix get reverted when the CVE fix landed ?
<ogra_> the oops is back
<sitter> didrocks: right, I'll try to get the stickies sorted and request a manual review then. cheers
<ogra_> ppisati, http://paste.ubuntu.com/23387924/
<ogra_> (not sure it is the same one)
<ogra_> ppisati, yeah, seems to be the same oops, the system moves on and i dont have any network device in console-conf
<ogra_> ppisati, oh sigh, i think the same issue like on rpi did hit us here, the proposed kernel was wiped for the CVE and only re-uploaded to proposed on friday, so the fix for the OOPS didnt make it to the archive
 * ogra_ hacks the bbb kernel snap to default to proposed
<pstolowski> mardy, hey! sure, what is it?
<mardy> pstolowski: AFAIU, the builtin interfaces are interfaces were the slot is implemented by snapd itself (correct me if I'm wrong). Will it be possible to have hooks for these slots too (in snapd)?
<mardy> s/were/where/ :-)
<ogra_> mvo, mind approving https://myapps.developer.ubuntu.com/dev/click-apps/5912/rev/6/ ?
<ogra_> ( jdstrand did add it to the exception list but seems that did still not land yet)
<mvo> ogra_: sure
<ogra_> thx
<mvo> ogra_: if you have a usb network card, could you please check if the dragonboard tgets an dhcp from that on firstboot
<ogra_> will do
<mvo> ogra_: thanks
<rvr> Dragonboard boots and sets up the wifi with rc2
<pstolowski> mardy, what you're referring to are slots "provided" by the os. i haven't thought about it yet and it wasn't raised in any of the discussions we had internally. I think it may make sense if we have use cases.
<rvr> ogra_: and filesystem is correctly resized
<ogra_> rvr, oho !!
<rvr> ogra_: Cool dd be the culprit?
<rvr> Could
<ogra_> rvr, thats the first time since last week ?
<rvr> ogra_: I think yesterday it worked for me sometimes
<rvr> I could run the spread test suite
<ogra_> and this time you used godd ?
<rvr> ogra_: Yes
<ogra_> well, yeah, then this could be the issue
<ogra_> (if it keeps working now :) )
<ogra_> mvo, all fine with USB nic on the dragonboard for me (configuring wired only)
<mvo> ogra_: cool - it also got an IP on firstboot?
<ogra_> yes, before console-conf
 * ogra_ runs sudo console-conf to see if he can switch over to wlan now
<mardy> pstolowski: I was thinking that bug 1633520 could be solved by interface hooks, see comments 2 & 3
<mup> Bug #1633520: Support dbus runtime relocation <patch> <D-Bus:Unknown> <dbus (Ubuntu):New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1633520>
<ogra_> yeah, works but needs a reboot, else the new config doesnt get applied
<mvo> ogra_: \o/
<ogra_> hmm, beagle doesnt though :(
<ogra_> interface is not pre-confoigured from first boot and times out trying to apply console-conf settings
<faenil> hey guys
<faenil> isn't "snap find" supposed to show the snaps in the store?
<faenil> (or at least that's what some guides report)
<ogra_> nope, it is supposed to find them
<ogra_> i.e. a blind "snap find" wont show anything
<faenil> although it used to
<ogra_> you need to give some search info
<ogra_> i dont think "snap" did
<ogra_> snappy did though
<faenil> I see
<ogra_> it also only searches the stable channel
<faenil> suer
<faenil> so, how do you list apps in the stable channel nowadays?
<ogra_> you dont
<faenil> I see....ok
<ogra_> not sure if uappexplorer can filter by channel
<faenil> alright, thanks ogra_
<faenil> is that intentional?
<ogra_> well, the prob is once the stable channel has 87234582 packages, what do you do ?
<faenil> is it because it doesn't scale?
<faenil> yeah
<ogra_> right
<pstolowski> mardy, yes, this sounds sensible to me. but this needs discussing. what i'm working on right now is to allow hooks on plug/slot sides of regular snaps; special handling for OS will come next
<faenil> ogra_: is there a plan to make it possible to search the other channels, that you know of?
<ogra_> nope, not that i know of
<faenil> ok
<faenil> cheers
<mardy> pstolowski: OK; how can I make sure that this is not forgotten? Should I file a bug?
 * ogra_ really loves to see the beaglebone only using 42MB ram in htop ... 
<ogra_> (of which 6.5MB is actually used by htop alone :) )
<ogra_> i wonder if we could boot with less than 50MB RAM
<ppisati> ogra_: i see all the patches are queued in x/master-next, yes, it appears that CVE hit the BBB too
<ogra_> ppisati, well, with the snap built from proposed everything is fine
<ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ubuntu-core-16-beaglebone.img.xz works pretty well
<ppisati> ogra_: oh good
<ogra_> luckily the bbb isnt supported so i can do such stuff there ;)
<ogra_> (and just re-bump the kernel once it went to updates)
<pstolowski> mardy, don't worry, it won't be forgotten ;)
<mardy> pstolowski: OK, thanks :-)
<ogra_> mvo, so apart from the pi3 wlan issues, all arm images look fine to me
<ogra_> (apart from the known slowness of console-conf and such)
 * ogra_ takes a break
<mhall119> ahoneybun: that's not the rocket.chat snap, that's snapd/snap-confine itself
<mhall119> since mainline doesn't yet have all the apparmor patches merged in
<mvo> ogra_: great, thank you
<jdstrand> ogra_: I see linux-generic-bbb was approved. yes, the fix is in the tools, no it isn't sync'd yet
<jdstrand> ogra_: speaking of bbb, is there a model assertion for it? I created one using linux-generic-bbb and bbb and it seemed to work, but not sure if I should be using something else
<ogra_> jdstrand, no official one (since we dont officially support it) ... i'm using a self created one for the daily images
<jdstrand> ogra_: ah, where are those daily images?
<ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ubuntu-core-16-beaglebone.img.xz should be golden though ... in case you want to try
<jdstrand> cool
<jdstrand> ogra_: I guess soon they will be moved to stable? I forget if it was the gadget or kernel (or both) that wasn't(/weren't) in stable
<ogra_> yeah, with the release
<ogra_> i could move them to beta already i guess ... will do that later today
<jdstrand> mvo: hey at some time that is convenient, would you mind approving https://myapps.developer.ubuntu.com/dev/click-apps/5063/review/rev/3/? I've made a change to the review tools so that will pass
<jdstrand> mvo: but that isn't in the store yet
<jdstrand> ogra_: no need on my account-- just curious
<mvo> jdstrand: sure
<jdstrand> ogra_: where will pi2, pi3 and dragonboard official images end up? http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/current/ with i386 and amd64?
<jdstrand> ogra_: (I'm updating my images and also updating the security team's documentation)
<jdstrand> mvo: thanks! :)
<ogra_> jdstrand, good question ... perhaps mvo has an idea
 * mvo is in a meeting
<popey> Pi3 disappeared from network *again* on update
<ogra_> we used to release under ubuntu-snappy in 15.04 ... but now we own the ubuntu-core name so i guess it will be somewhere under ubuntu-core
<ogra_> popey, wireless ?
<popey> wired only
<ogra_> very weird, doesnt happen to me with wlan
<popey> and I have no way of logging in on serial cable because no user ID
<popey> so I cannot debug this
<jdstrand> I need to look up how to setup wireless on series 16
<sitter> jdstrand: hey kde-frameworks-5 content snap filed for manual review as it fails lint due to content interface
<popey> ethernet light is on, on the switch
<popey> ogra_: should I file a bug, this has happened multiple times
<ogra_> jdstrand, doesnt work on pi3 ... so set up wired, make sure to reboot, ssh in, run sudo console-conf again and disable wired and configure wireless ... another reboot and you rshould be good
<jdstrand> sitter: approved, but you need to press the publish button. fyi, there is a fix for that in trunk, it just isn't sync'd with the store yet
<jdstrand> ogra_: oh, console-conf can do wireless too?
<jdstrand> after initial bringup?
<sitter> jdstrand: thanks
<ogra_> popey, definitely ... i suspect it doesnt shut down properly ... but that would need a serial console permanently attached to see
<ogra_> jdstrand, yeah, it should theoretically even work on first boot but there is some bug on the pi ... dragonboard works OOTB with wifi
<ogra_> still trying to hunt that down before release next week
<jdstrand> an interesting side-effect of the whole user from LP stuff is that there is no way to set a password for the user (not so much for ssh logins, but for serial console logins). I guess the default is reasonable cause it is easy enough to do 'sudo passwd <id>', but perhaps it is interesting in console-conf...
<ogra_> sudo passwd $USER
<jdstrand> of course, then you'd want to tweak sshd_config and likely /etc/sudoers.d/create-user-<id>...
<ogra_> (indeed you need to ssh in once for this)
<jdstrand> ogra_: yeah, I mentioned that :)
<popey> ogra_: no, it's rebooted fine i think, but comes back without network
<ogra_> ah, didnt see it :)
<jdstrand> anyway, I don't feel strongly enough to advocate for a change to console-conf
<ogra_> popey, smells like some race then
<ogra_> i never see it with wlan
<popey> ok filed 1637196
<mup> Bug #1637196 opened: Pi 3 drops off network on update <Snappy:New> <https://launchpad.net/bugs/1637196>
<sitter> jdstrand: I also requested the reserved name 'kblocks' in case you can have a look at that ^^
<jdstrand> sitter: you'll need a store admin for that (I am a store reviewer)
<jdstrand> nessita: can you help sitter? ^
<jdstrand> hmm, /etc/rsyslog.d is still read-only and no way to setup log forwarding yet
<jdstrand> same with /etc/systemd/timesyncd.conf
<popey> jdstrand: i thought you had rights to allow names too?
<popey> (I just approved it) sitter
<popey> sitter: feel free to ping me also next time you want a reservation approved
<sitter> thanks
<popey> np
<jdstrand> popey: if I do, I don't know how or the processes surrounding allowing it
<popey> ok
<faenil> looking at http://bazaar.launchpad.net/~ubuntu-calendar-dev/ubuntu-calendar-app/trunk/view/head:/snapcraft.yaml#L9
<faenil> I should be able to run the app just by running "ubuntu-calenda-app" from terminal, after installing the snap, right?
<faenil> I updated a laptop (not mine) to Zesty, and I can't get snaps to run
<popey> that should work, yes.
<faenil> it says command not found
<faenil> can anyone confirm if snaps are running ok on zesty?
<faenil> desktop-launch also does not exist
<faenil> (maybe that's expected though?)
<faenil> if anyone has an idea on how to debug this, please let me know ;)
<pmcgowan> faenil, I saw similar behavior when my snapd was out of date
<pmcgowan> or was it my core snap, forget
<faenil> 2.16+16.10ubuntu1
<faenil> core 16.04.1
<faenil> rev423
<faenil> pmcgowan: ubuntu-calendar-app.ubuntu-calendar-app says command not found (same if I just run ubuntu-calendar-app). While "snap run ubuntu-calendar-app" works! (thanks dobey) but trying to run it from the apps scope results in an endless spinner
<Son_Goku> zyga: I fixed it!
<dobey> faenil: i think the problem there is that command:
<pmcgowan> faenil, seems broken for sure, just running u-c-a should work
<faenil> I guess I should report a bug :P
<faenil> tentatively snapd
<dobey> so, the .desktop file is broken, which is why it doesn't start from the dash i guess
<Son_Goku> zyga: https://github.com/zyga/snapcore-fedora/pull/9
<mup> PR zyga/snapcore-fedora#9: Update SELinux subpackage packaging <Created by Conan-Kudo> <https://github.com/zyga/snapcore-fedora/pull/9>
<faenil> dobey: or is it not that the dash fails because the command is not found?
<faenil> or does it go through snap run?
<faenil> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1637220
<mup> Bug #1637220: Command not found when launching snaps via terminal on Zesty <snapd (Ubuntu):New> <https://launchpad.net/bugs/1637220>
<faenil> who should I ping? zyga ?
<dobey> faenil: no, the dash does the same as running "ubuntu-app-launch $APP_ID"
<faenil> ok
<dobey> but the .desktop file doesn't have $SNAP/bin/ in the Exec= line, or at least, doesn't have bin/. i don't know why the window stays around and you can't close it though.
<dobey> the .desktop file has full paths to icons too, which seems wrong
<faenil> dobey: should desktop-launch be availble from cmd? or is it just something that is preprocessed?
<dobey> faenil: no idea. but it's not used for launching from the dash anyway since the .desktop file doesn't mention it
<dobey> faenil: for all i know that could be some magic thing in snapcraft itself
<faenil> sure
<faenil> yeah
<dobey> faenil: maybe in your ~/.cache/upstart/unity8-dash.log there is some error about calendar app, when you tried to start it from dash
<faenil> dobey: nope
<alex-abreu> faenil, you are trying in the unity8 session?
<faenil> yep
<mup> PR snapd#2223 opened: image: init "snap_mode" on image creation time to avoid ugly messages <Created by mvo5> <https://github.com/snapcore/snapd/pull/2223>
<sitter> jdstrand, popey: I think #2 of kblocks is marked for manual review. if you could kick that please. I think it's holding up autoreview of #3
<jdstrand> sitter: I rejected r2. r3 was auto-approved (perhaps just now) and you need only press the publish button
<sitter> jdstrand: thanks
<mup> PR snapd#2224 opened: overlord/snapstate: update ux around explicit refresh of reverted, anâ¦ <Created by chipaca> <https://github.com/snapcore/snapd/pull/2224>
<mup> PR snapd#2221 closed: tests: skip tests that use /dev/ptmx on ppc64el - it does not work here <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2221>
<mup> PR snapd#2225 opened: Implement lxd-client interface exposing the lxd snap <Created by kalikiana> <https://github.com/snapcore/snapd/pull/2225>
<mup> PR snapd#2226 opened: Eds <Created by renatofilho> <https://github.com/snapcore/snapd/pull/2226>
<alex-abreu> nessita, trying to use the staging store to reach the new endpoints (sections, featured snaps, etc.) but I get a 404, are they in place ?
<mup> PR snapcraft#873 closed: Release changelog for 2.20 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/873>
<sergiusens> alex-abreu in the snapcraft we have a tools/staging_env.sh which we source to avoid the confusion of all the endpoints
<sergiusens> try and use that as a reference
<alex-abreu> sergiusens, ah great,  I was manually setting the env vars, let me check that
<alex-abreu> sergiusens, the URLs look reasonnably similar to what I have been using, although setting them manually
<mup> PR snapcraft#834 closed: Remove the debian packaging <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/834>
<sitter> mhall119: sudo snap install --edge kde-frameworks-5 && sudo snap install --edge --devmode kblocks
<sitter> I do have a feeling that we are missing some "automatic dependency install" system for content sharing (i.e. one can install kblocks without having frameworks installed)
<kyrofa> Hey ogra_, what is the difference between the pi2 RC and pi3?
<Pharaoh_Atem> zyga: ping
<mhall119> sitter: auto-dependency installation is being worked on, IIRC it will check if you already have something installed that fulfills the content need, and if not it will look for the defined default snap and install that
<mhall119> zyga: ^^ is that correct?
<Pharaoh_Atem> mhall119: this morning, I managed to get the selinux policy to let snapd start and run :)
<mhall119> Pharaoh_Atem: \o/
<mhall119> sitter: are the edge channel builds coming from our CI now?
<mup> PR snapcraft#874 opened: Remove the debian packaging <Created by elopio> <https://github.com/snapcore/snapcraft/pull/874>
<zyga> Pharaoh_Atem: hey
<zyga> sitter: that's correct, it's planned but not implemented yer
<Pharaoh_Atem> zyga: the systemd units need to be refreshed
<Pharaoh_Atem> they're wrong vs the canonical (pun intended) ones
<ogra_> kyrofa, about 30 lines of uboot code
<kyrofa> ogra_, ah, okay. Still 32-bit, right?
<ogra_> yeah
<kyrofa> ogra_, is it "officially" supported?
<ogra_> ppisati already landed an arm64 kernel but i didnt find the time to tinker with that
<zyga> Pharaoh_Atem: how can I do that?
<ogra_> yeap, pi2 and 3 are official ... drgoboard too ...
<Pharaoh_Atem> zyga: first, pull in my PR
<ogra_> beaglebone is community supported
<zyga> yep
<jdstrand> ogra_: hey-- in the snapcraft@ mailing list you mention a README for flashing the dragonboard. I created an image, dd'd it to a device then botted up be get some qualcomm thing. is there more information on how to boot from the sd card?
<Pharaoh_Atem> then next, regenerate that patch with new systemd units based on the ones from upstream, merging in the differences from the old units to the new ones (paths, environmentfile, etc.)
<jdstrand> ogra_: I don't see that README file anywhere
<ogra_> jdstrand, well ... use mvo's godd snap ;)
<Pharaoh_Atem> zyga: also, keep in mind, stuff that refers to /snap will need to change to /var/lib/snapd/snap
<ogra_> jdstrand, beyond that ... the only thing you need to do is to turn the dip switch for SD booting on the bottom of the board on
<zyga> Pharaoh_Atem: ack
<jdstrand> ogra_: ah!
<zyga> Pharaoh_Atem: merged
<ogra_> jdstrand, xzcat ./ubuntu-core-16-dragonboard.img.xz | sudo godd - /dev/sdc
<ogra_> jdstrand, thats how i flash it
<elopio> pitti: ping. Can you help me debugging why the autopkgtests from snapcraft github are not running?
<pitti> elopio: oh, welcome back! I was going to ask you how that went some weeks ago
<elopio> I've just updated the branches now that we are clean after a release, but I don't see any results
<elopio> https://github.com/snapcore/snapcraft/pull/874
<mup> PR snapcraft#874: Remove the debian packaging <Created by elopio> <https://github.com/snapcore/snapcraft/pull/874>
<pitti> elopio: in the middle of building psql updates and running out for dinner, but sure
<elopio> pitti: I can wait until tomorrow.
<pitti> elopio: well, whatever these tests are, it's not the autopkgtest.u.c. infra
<pitti> these are pointing to some jenkins?
<Pharaoh_Atem> elopio: errm, what do I do about this? https://travis-ci.org/snapcore/snapcraft/jobs/170776507#L2096
<elopio> Pharaoh_Atem: hello. Looking.
<Pharaoh_Atem> elopio: Hi :)
<elopio> pitti: ignore all those failing tests. They are for our existing jenkins, which will fail of course because they are expecting a debian directory.
<elopio> My idea is to replace the four of them with your infrastructure.
<elopio> Pharaoh_Atem: oh, sucks. Do you get that out of memory error running locally?
<pitti> elopio: I don't see a recent snapcraft related error in the logs; can you prod the web hook on your side? does a ping work?
<pitti> elopio: i. e. maybe some mismatch in the password?
<elopio> pitti: I can't change the hook because I'm not admin. But sergiusens can.
<elopio> Sergio, are you around?
<pitti> bbl
<pitti> (back in ~ 3 hours)
<elopio> pitti: have a good night!
<sitter> mhall119: not from CI yet. I hope to have everything done on automation earlier next week so I can write a blog post and invite more of our devs to join in improving their snaps.
<Pharaoh_Atem> elopio: hmm, weird, I get an OOM error locally now too
<elopio> Pharaoh_Atem: you are using a scary library there :)
<Pharaoh_Atem> :S
<sergiusens> elopio for a bit
<gQuigs> is it just me or does snapd.firstboot.service start up every boot?
<mup> PR snapd#2198 closed: tests: only check pc model for the ubuntu-core-16-64 system <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2198>
<mup> PR snapd#2217 closed: tests: increase wait time for service to be up <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2217>
<gQuigs> a /var/lib/snapd/firstboot/stamp is never created....
<mup> PR snapcraft#875 opened: Add the test upstream rules <Created by elopio> <https://github.com/snapcore/snapcraft/pull/875>
<mup> PR snapcraft#875 closed: Add the test upstream rules <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/875>
<Pharaoh_Atem> elopio: okay, this is retarded
<Pharaoh_Atem> I can only have a list of one object, or it breaks
<Pharaoh_Atem> mugh
<elopio> sergiusens: there's something wrong in our autopkgtest hook, but I'm not sure how to debug it.
<elopio> Pharaoh_Atem: not funny. Is that a bug on the library?
<Pharaoh_Atem> I think so, yes
<Pharaoh_Atem> I have a tiny reproducer test case sample, so I'll probably file a bug with python-libarchive-c about it
<Pharaoh_Atem> but :S
<elopio> Pharaoh_Atem: alright! one point for the test suite, it's even finding bugs in libarchive :D
<mup> PR snapd#2227 opened: overlord/snapstate: add dynamic snapdX.Y assumes <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2227>
<Pharaoh_Atem> elopio: libarchive is scary :(
<Pharaoh_Atem> but the alternative of having to detect every single possible compression algorithm that could be used in an rpm payload is simply not worth it
<elopio> Pharaoh_Atem: I agree. Any possible workaround while they release a fix?
<MikeB> sergiusens, a couple days ago we chatted about the issues surrounding the kernel plugin pulling from edge...
<MikeB> As an experiment, I changed it to pull from stable.
<MikeB> Thane ran ubuntu-image pulling from stable.
<MikeB> s/thane/then/
<Croepha> Where can I find the snapcraft.yaml for the official vanilla kernel that comes with core 16?
<MikeB> Still didn't work - get the error about snapd being too old.
<MikeB> Any suggested workaround?
<jdstrand> ogra_: my dragonboard gets a dhcp address, but ssh connection is slow and I see it asking for an ip frequently. is this known? I guess it could be this: wcn36xx: ERROR hal_remove_bsskey response failed err=16
<ogra_> weird, i dont have such things here
<ogra_> ogra@wall2:~$ grep DHCPREQ /var/log/syslog|grep dragon
<ogra_> Oct 27 12:29:36 wall2 dhcpd: DHCPREQUEST for 192.168.2.69 (192.168.2.2) from 02:00:25:af:71:aa (dragon) via p4p1
<ogra_> Oct 27 13:17:55 wall2 dhcpd: DHCPREQUEST for 192.168.2.56 (192.168.2.2) from 02:00:25:af:71:aa (dragon) via p4p1
<ogra_> Oct 27 15:17:54 wall2 dhcpd: DHCPREQUEST for 192.168.2.56 from 02:00:25:af:71:aa (dragon) via p4p1
<ogra_> Oct 27 17:17:52 wall2 dhcpd: DHCPREQUEST for 192.168.2.56 from 02:00:25:af:71:aa (dragon) via p4p1
<sergiusens> MikeB said it was wrong, but ogra_ told me to leave it there for a bit
<ogra_> right, until stable isnt so outdated anymore ... i doubt the initrd would successfully boot
<MikeB> sergiusens, understood.  Just looking for an interim workaround I could implement if there is one.
<ogra_> (or it might boot but things would fail during boot due to missing mounts etc)
<ogra_> MikeB, if you tell ubuntu-image to use stable *everything* comes from stable
<MikeB> Any idea when stable may be modernized?
<ogra_> in ~7 days
<ogra_> build from edge,beta or candidate until then
<MikeB> ogra_, Great.  I can wait.
<ogra_> candidate should largely be what will go to stable next week
<elopio> Croepha: http://bazaar.launchpad.net/~snappy-dev/pc-kernel-snap/trunk/view/head:/snapcraft.yaml
<MikeB> I've had no luck with edge and beta.  Haven't tried candidate.  I'll give that a try.  Thanks.
<Croepha> elopio: Thank you so much ! :)
<Croepha> wow, thats really different then the ones in the examples
<ogra_> MikeB, well, edge and beta work for all other images ... su better track down why exactly it fails, jumping around on different channels wont solve that
<ogra_> Croepha, that is because it needs to use the deb package from the archive
<ogra_> other kernels do not need that
<ogra_> (the binaries in the deb are signed with the ubuntu archive key, which is essential for secure boot environments to work)
<ogra_> mvo, yummy ! betas with pi and more !
<Croepha> hmm, well, maybe instead of trying to emulate what the vanilla core kernel is doing, maybe i should just say what my problem is... I tried to build a custom kernel for the intel compute stick based on a source tree I found on github (linuxium) ive used their binaries before and they work... When I booted off the drive there isn't any drivers in the initramfs just squashfs (probably just because that was the one listed in the 96boards kernel
<Croepha>  snapcraft.yaml that I copied over...) , I want the image to be general purpose so I want a good set of drivers....
<ogra_> no, you dont :)
<MikeB> ogra_ I think the problem is related to using a custom kernel to build the image.  The error message implies a version/channel mismatch somewhere...
<ogra_> you want a handfull of controller drivers and filesystems ... we do not support anything more than detecting your rootfs from the initrd
<ogra_> (no netbooting or any such fancy stuff)
<ogra_> you can try to grab the config from a xenial ubuntu desktop install and base on that ... then add a few basic controller drivers to the snapcraft..yaml and be done
<Croepha> ogra_, ok I'll try that, thanks
<mhall119> sitter: sounds great, let me know when the blog post is up, I'd love to share it around
<Croepha> ogra_: btw, it looks like a full set of drivers got built and made it into the .snap, they just didn't make it into the initrd
<ogra_> on purpose
<elopio> sergiusens: pitti: oh it's running, it's awesome! I used the retry script, so the problem is in our hook for sure.
<ogra_> we dont want big initrds on IoT devices
<Croepha> makes sense
<Croepha> just saying its not a kernel .config problem
<ogra_> we put ahci, usbstrorage and a few MMC controller drivers into the pc-kernel snap initrd currently
<ogra_> all filesystems are builtin
<Croepha> so i just add that to "kernel-initrd-modules" section and that should be it right?
<ogra_> yep
<Croepha> sweet
<Croepha> Thanks for the help :)
<mup> PR snapd#2220 closed: overlord/snapstate: fix missing argument to Noticef <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2220>
<jdstrand> well, I reflashed the dragonboard with mvo's images and it's the same thing. if there is network traffic, it starts disassociating and reassociating
<ogra_> strange
<ogra_> jdstrand, are you using the default power supply ??
<ogra_> might be a low current issue
<jdstrand> ogra_: I was sent the board with a power supply in a box. I guess it is default for me
<ogra_> yeah, same here
<ogra_> do you have any 5GHz in your house (only 2.x here)
<ogra_> perhaps that makes some difference
<jdstrand> I do
<jdstrand> and it is connecting to it. is there a way in console-conf to prefer 2.4?
<jdstrand> 5G and 2.4G use the same ssid
<ogra_> i dont think there is a way, no
<ogra_> you'd hack it yourself into the wpa-supplicant config i fear
<jdstrand> ogra_: hrmm... of course, I don't have a reliable console to do that. maybe if I can set a password then I can hook up a keyboard and login
<ogra_> yep
<jdstrand> that's a big if at this point :)
<dobey> wrap the antenna in a physical filter that blocks 5GHz but allows 2.4GHz?
<kyrofa> jdstrand, the wifi driver in my dell M3800 periodically disconnected from 2.4 and connected to 5 (like every 10 minutes) when they had the same SSID
<kyrofa> I had to change it
<dobey> why does everything have crappy wifi chips
<kyrofa> dobey, I think that every time I install ubuntu on something and cross my fingers
<jdstrand> most of my devices are pretty happy with it. I guess I'll need to consider that
<kyrofa> jdstrand, took me way too long to figure out that was the cause
<dobey> kyrofa: i just only buy laptops with intel wifi and only buy phones with qualcomm. works pretty well then :)
<kyrofa> jdstrand, and historically, the dragonboard wifi driver has been terrifyingly bad
<dobey> though i guess dragonboard is qualcomm
<jdstrand> dobey: interestingly, my wife's wifi has iwlwifi (intel) and I had to disable 5g on it and this is a qualcomm :P
<kyrofa> Hahaha
<jdstrand> (this meaning the dragonboard)
<dobey> the dragonboard is weird though i guess becuase unlike the phones we don't have the android device tree binary blobs
<jdstrand> this is slowly killing me. now it won't associate at all
<dobey> so we're stuck with the reverse engineered open source drivers
<stgraber> sergiusens: hey there, would I be right in assuming that stage-packages will be a bit unhappy if a package isn't available (architecture specific)?
<kyrofa> stgraber, yeah it'll fail
<dobey> heh
<stgraber> well, that sucks :)
 * stgraber goes to file another snapcraft bug
<dobey> i guess someone could build a 3.10 kernel snap for dragonboard using the lollipop device tree for it
<dobey> bet wifi might work better then
<bzoltan> sergiusens: I am working on a snapcraft plugin. How can I know the main project's name  and how can I copy out stuff from the parts to the same place where the result .snap is placed?
<pstolowski> kyrofa, ping
<kyrofa> Hey pstolowski!
<kyrofa> What's up?
<jdstrand> ok, I give up. it was connecting to 2.4G, I tried forcing to 5G, it just doesn't work
<jdstrand> I tried using a usb wifi, nope. I tried unloading the other module, segfault
 * jdstrand goes to be productive somewhere
<mup> PR snapcraft#876 opened: Allow for architecture-specific packages <Created by stgraber> <https://github.com/snapcore/snapcraft/pull/876>
<pitti> elopio: hmm, "running", I don't see it queued or running?
<pitti> elopio: what's the PPA you run these tests with? I'd like to check swift if there's any result, i. e. whether it's the request or the status_url end
<dobey> i presume that attempting to do "snap login" with an e-mail address that i've already logged in with, returning an error about username/password being wrong, is a bug?
<kyrofa> dobey, what... that's not expected behavior?
<dobey> kyrofa: ah i miss your sarcasm ;)
<kyrofa> dobey, nice to see you around, too ;) . Yeah, log a bug
<kyrofa> Now I wonder how snapcraft handles that
<dobey> yeah, i'm trying to decide how to deal with all these weird little conditions, to make the u1 online-accounts plug-in log in via snapd, and not cause the world to implode
<kyrofa> dobey, are you using the REST API for that, then?
<dobey> kyrofa: yeah, to snapd
<kyrofa> dobey, and that's saying wrong username/password if you're already logged in?
<dobey> kyrofa: presumably it is. i haven't got that code implemented yet. i was just trying with snap cli to see what happens
<dobey> kyrofa: or maybe it's just bloody confusing and i typed the wrong password
<kyrofa> dobey, hmm, looking at the "error kinds" in rest.md, there doesn't seem to be one for invalid login info
<kyrofa> dobey, there's invalid-auth-data, but the example it gives is an invalid email address
<dobey> kyrofa: because when you type "sudo ..." and the only line is "Password:" it's not entirely clear which password one needs to type
<dobey> so i can log in a second time just fine, it seems
<dobey> but the cli is a bit unclear
<kyrofa> dobey, whoops, just sent your sudo password to the store eh?
<dobey> kyrofa: well, the password for the user in the vm :)
<kyrofa> dobey, heh
<dobey> https://bugs.launchpad.net/snappy/+bug/1637299
<mup> Bug #1637299: sudo snap login "Password:" prompt unclear what password to type <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1637299>
<mup> Bug #1637299 opened: sudo snap login "Password:" prompt unclear what password to type <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1637299>
<pitti> sergiusens, elopio: still here for about an hour or so, if you want to look at the snapcraft tests
<Pharaoh_Atem> elopio: I've worked around the issue with libarchive
<Pharaoh_Atem> the integration test passes now
<Croepha> is there a known issue where snapcraft'ing a kernel can lead to a "File exists" error when building the initrd?
<pitti> elopio: oh look, a snapcraft upstream request in http://autopkgtest.ubuntu.com/running#queue-upstream-xenial-amd64
<pitti> (doing maintenance, will run soon)
<mup> Bug #1637324 opened: snapd does not provide a REST API to log out <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1637324>
<mup> Bug #1637325 opened: snapd provides no way to register a new account <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1637325>
<sethj> does snappy put $SNAP in XDG_CONFIG_DIRS?
<kyrofa> sethj, I don't believe so. Nothing defined that config files should go there
<mup> Bug #1637328 opened: Ubuntu Core 16 includes libnss-resolve from universe <Snappy:New> <https://launchpad.net/bugs/1637328>
<kyrofa> e.g. they might be in SNAP_DATA
<sethj> kyrofa, sorry, just realized I meant XDG_DATA_DIRS, not CONFIG_DIRs.
<sethj> I'm trying to figure out how to make my app work with snaps without too much source change, since it's looking in /usr/share/app-name for stuff.
<kyrofa> sethj, the answer still applies. Nothing says you have data in $SNAP/, or $SNAP/data, or $SNAP/usr/share/app-name
<josharenson> How can I increase the size of my snappy core image? I think I made the /writable device larger, but "/" is still out of space
<kyrofa> sethj, but if you know where the data is, you can define it, no?
<sethj> kyrofa, I'm not sure I understand what you are saying. The app puts files in /usr/share/app-name. snappy puts them in /snap/app-name/#######/usr/share/app-name, but that doesn't work because the app itself looks in /usr/share/app-name. I thought if I changed the app to look in XDG_DATA_DIRS it might work, but it has been a long time since I thought about that and I lost my source.
<kyrofa> sethj, ah, I see what you're saying. I thought you had an app that looked in XDG_DATA_DIRS and was confused why it wasn't working as a snap
<kyrofa> sethj, there's no FHS enforced or even suggested when it comes to snaps. You can format them however you wish. The only requirement is that it's self-contained (i.e. everything is inside $SNAP somewhere)
<kyrofa> sethj, you have an application that sounds like it's hard-coded to assume the presence of a FHS
<kyrofa> sethj, if you're considering a patch, might I suggest simply supporting a cli flag (--data-dir or similar) to redirect it?
<kyrofa> josharenson, not only do you have to make the partition larger, but you have to resize the filesystem as well
<kyrofa> josharenson, e.g. resize2fs
<sethj> kyrofa, I may be ignorant, but the app is a collection of shell/python scripts. How else would I find config files/scripts it placed other than hard coded the location? I put them there, after all..
<kyrofa> sethj, but the hard-coded path is in /usr/share, which isn't contained in the snap
<sethj> right
<sethj> but that's snappy's problem, not the apps.
<sethj> I'm not the one doing semi-sandboxing ;) I didn't explicitely put the files in $SNAP/usr/share. I put them in /usr/share. snappy decided to put them under $SNAP (which makes sense) but how good is a packaging format if I have to edit the code so it works? Neither debian nor rpm packaging makes it that hard.
<dobey> well it's the app developer making the assumptiong that XDG_DATA_DIRS is available/used everywhere
<josharenson> kyrofa: ah thanks... that grew the writable partition, but installing snaps still results in "no space left on device"
<sethj> dobey, you'll note I haven't even used XDG_DATA_DIRS yet. But hard coding $SNAP into my paths is just as bad, no, worse, than hard coding /usr/share.
<dobey> sethj: snap is not simply a "packaging format" in the traditional sence of the word
<dobey> sense
<dobey> sethj: i'm not saying that's what you should, or implying that you are using XDG_DATA_DIRS directly. glib for example has no idea about containment, and is the owner of the implementation that a great many things use when it comes to finding files that those things have installed to the system
<dobey> so you would need a patched glib that handles the $SNAP for you
<sethj> that's insane.
<dobey> no, it's different
<sethj> they aren't mutually exclusive.
<dobey> well, not that different really. distributors have had to take upstream source code and patch it to fit into a productized system for decades
<sethj> ;)
<sethj> dobey, yes and I have my fair share of experience with that, but not quite like this.
<sethj> I hate to be "that guy", but I can't be the only person having this problem and the lack of solutions makes me wonder what the goal is here.
<pitti> you aren't
<pitti> I've seen crazy patches like https://code.launchpad.net/~morphis/netplan/+git/netplan/+merge/306607 :)
<dobey> well i don't quite understand what your problem is. you're saying that the way you package things for a different system doesn't work for this system. this is no different than if you were to package your thing for native windows. the way files are placed and discovered by the installer and application there works completely differently from debs and rpms too
<sethj> dobey, no, I'm saying snappy puts my files in places I didn't put them, but provides me no method of finding them unless I hard code my app to figure out where snappy puts things (which is NOT where I put them)
<dobey> yes, some applications and libraries may be more difficult to fit into the snap world than others
<dobey> but that doesn't make it insane
<dobey> sethj: it puts them exactly where you put them. that's the problem
<sethj> you guys express shock at my hard coded paths but then tell me the only way to get my files is to hard code the snappy path...
<dobey> i didn't say anything about hard coded paths
<dobey> there are many solutions to this problem
<kyrofa> sethj, I never suggested hard-coding anything. I suggested making the app more flexible via cli-flags (find my data there, find my configs there, etc.)
<dobey> you could fix your application to resolve file paths relatively
<kyrofa> sethj, darktable does it this way, apache does it this way, etc.
<dobey> you could compile your data into the application as resources
<dobey> getenv("SNAP") is also not at all "hard coding a path"
<sethj> yes it is. since snappy is the only thing that sets snap. Hence my desire to use XDG_DATA_DIRS (which I still think would work) because it already works with Debian/Ubuntu and should work with Fedora and Arch too.
<kyrofa> sethj, indeed, that would work, but you'll need to set it
<sethj> kyrofa, fair enough. I apologize if I come across upset.
<dobey> well snapdir = getenv("SNAP"); setenv("XDG_DATA_DIRS", sanpdir)
<dobey> whatever
<kyrofa> sethj, you're having understandable frustrations. One of the biggest complications when snapping something can be the requirement that it should be relocatable. This is historically not something to which projects are accustomed
<dobey> you need to fix your app to be relocatable (work as installed in a different root path) and to work in a confined world
<sethj> again, I don't mean to be "that guy" (I've dealt with him enough), but I really don't see how this is supposed to catch on. I've already had to hack font and gtk support, now this...
<sethj> dobey, but there is no way to do that without hard coding your list of root paths. at least not in snappy's case if it doesn't set any env variables to help (unless it does and I missed something somewhere?)
<dobey> yes there is
<dobey> it sets $SNAP
<dobey> the system doesn't know where the files are inside your snap that you need to find, so it can't possibly set XDG variables to something inside your snap for you
<sethj> which is practically the same thing as hard coding the root path as only snappy will ever set $SNAP. Oh well.
<dobey> it can only tell you the root to your snap, and then you have to find things under it yourself
<sethj> dobey, right. shouldn't it add $SNAP/usr/share to XDG_DATA_DIRS?
<dobey> well, nothing other than snappy is going to install or run your thing that's a snap
<dobey> no
<kyrofa> sethj, no, $SNAP/usr/share isn't a standard path
<dobey> maybe snapcraft could have some convenience things that does something like that, to make it easier to migrate things
<dobey> but once your app is installed in the system, all that should be inside your snap, in a wrapper script or something
<kyrofa> dobey, indeed, I suspect some of the desktop-helper parts do that
<dobey> if you want to migrate something and aren't using snapcraft, it's going to be a fair bit more work to do, but if done right, will be closer to what an ideal snapped application should be
<sethj> is the ideal snapped application layed out somewhere? I am using snapcraft, but tbh I have no way of knowing how well I am using it. The documentation isn't great. Or at least it wasn't 6 months ago when I started this.
<dobey> for gui applications on ubuntu, the "ideal" snap of an app i suspect won't be terribly far off from what clicks are on the phone today
<sethj> if only I knew anything about clicks.
<dobey> there are certainly things about how gtk+ and traditional applications work, that makes confining such applications quite difficult
<kyrofa> sethj, snapcraft has a concept of remote parts (i.e. parts defined by others). There are several out there for gtk- and qt-based apps. Have you seen those? Or the examples in the playpen?
<sethj> kyrofa, I think I've seen some. I started this a few days before the playpen became a thing though. I should look at it again.
<dobey> anyway, time for me to go. good luck
<kyrofa> sethj, the gtk parts define a slew of environment variables that might interest you
<kyrofa> sethj, an example: https://github.com/ubuntu/snappy-playpen/blob/master/hexchat/snapcraft.yaml
<nacc> sethj: i would recommend refreshing the documentation, as it's quite a bit more updated (not perfect by any means) than it was 6 months ago
<kyrofa> Note that the app is launched with a wrapper provided by the desktop-gtk2 part called `desktop-launch`
<sethj> alright, I'll give it a shot.
<kyrofa> Alright, EOD here as well. Have a great day everyone!
#snappy 2016-10-28
<mup> PR snapcraft#877 opened: [WIP] Add new "source-commit" field for VCS sources <Created by stgraber> <https://github.com/snapcore/snapcraft/pull/877>
<dholbach> good morning
<zyga> o/
<om26er> Can I install Ubuntu Core on the Dragonboard eMMC ?
<mup> Bug #1637445 opened: The serial vault fails to connect to serial-vault.canonical.com <Snappy:New> <https://launchpad.net/bugs/1637445>
<ogra_> pitti, hmm, i cant remember the bugnumber but i am sure there was a bug that seeding libnss-resolve fixed
<pitti> ogra_: it certainly came up as part of debugging something, but it's really by far not ready in xenial
<ogra_> sadly there is no info why exactly it was added but it looks like it was related to cloud-init ... http://paste.ubuntu.com/23392138/
<pitti> i. e. someone thought "oh, yakkety uses resolved with this, so let's try this", but this was probably bug 1620559 or so
<mup> Bug #1620559: /etc/resolv.conf is empty on snappy <hw-specific> <verification-done> <Snappy:New> <systemd (Ubuntu):Fix Released> <systemd (Ubuntu Xenial):Fix Released by pitti> <https://launchpad.net/bugs/1620559>
<ogra_> mvo added it to livecd-rootfs .... i later moved it to the metapackage during a cleanup
<pitti> yeah, I think this was just chinese whispers/a misunderstanding
<kalikiana_> Are there any "real world" tests for snapd? By which I mean, not just formal verification but "try x, see if it worked"
<kalikiana_> My practical example would be a tiny Go test snap using the lxd-client interface I added
<kalikiana_> Which is what I've got, but manually
<kalikiana_> balloons: Incidentally, as you were interested in it, https://github.com/snapcore/snapd/pull/2225 is in a state that you can try out if you'd like
<mup> PR snapd#2225: Implement lxd-client interface exposing the lxd snap <Created by kalikiana> <https://github.com/snapcore/snapd/pull/2225>
<fgimenez> hi kalikiana_, take a look at snapd's spread test suite, there are lots of real world usage examples https://github.com/snapcore/snapd/tree/master/tests/main
<kalikiana_> (I removed my attempted access to the executables, it's socket-only now)
<kalikiana_> fgimenez: Oh, thanks, it seems I didn't look properly, I saw the _test.go files all over the places but didn't reaize there was another suite entirely
<fgimenez> kalikiana_, yep, both suites, unit and integration, are run with each PR, let me know if you need any help writing the spread test for the case you mentioned
<sitter> I'm looking for some input on dbus confinement. KDE has lots of apps that (semi-implicitly; as in: devs might not even know dbus is involved) access the session bus and claim a service name on it. This is how we implement unique application behavior (e.g. user starts foo, foo claims org.kde.foo, when foo is invoked again by whatever means it will first check if org.kde.foo is claimed and if so send a raiseWindow to that instead of starting a second
<sitter> instance of foo). I am wondering if it would be possible to have a common interface which allows a snap to connect to the session bus and interact with a specific service name there (i.e. its own).
<bzoltan> didrocks: yo man. I wonder if the main project name would be available in the snapcruft plugins? The other question I have in mind is of it is possible to move out the tar.gz created during the build to the same place as the final .snap is put.
<qengho> bzoltan: If your build tool is defined to "install"
<sparkiegeek> I'm trying to build a snap of a Python app, I'm having trouble with one of it's libraries which I have as a part: but fails to "snapcraft build" because of what seems to be peculiarities in the setup.py. Is there a one-liner I can use to reproduce what the Python plugin is doing? I want to add debugging and logging to the src and retry the build
<qengho> all that, then it could easily.
<qengho> sparkiegeek: Does the "--debug" param on "snapcraft" give you enough?
<bzoltan> qengho: how to define it to "install"?
<sparkiegeek> qengho: not quite - it shows me it's running ['/bin/sh', '/tmp/tmpcuv22g6y', 'pip', 'wheel', ...] but I don't get to see inside that tmp file, nor see the environment it's running in (PWD, os.environ etc.)
<didrocks> bzoltan: hey! there is no restriction, so move it to .. ;) Unsure about the main project name, let me check the code
<sparkiegeek> qengho: I've been cleanbuild --debug'ing and get dropped into the LXC - great - but struggling to iterate - if I use system python it Just Worksâ¢ but am failing to use the python in parts/install
<qengho> bzoltan: What is it you want to move, exactly?
<didrocks> bzoltan: so, you can do:
<didrocks> config = snapcraft.internal.load_config(project_options)
<didrocks> then config.data['name'] has the snap name
<bzoltan> qengho: I have a plugin what wraps up a part of the stage for further use. I made a simple plugin to ride the build ... it creates the tar.gz to the parts
<didrocks> project_options is available in your plugin
<bzoltan> didrocks: \o/
<didrocks> bzoltan: this is just from reading snapcraft source code, might be wrong ;)
<bzoltan> didrocks: it is          config = snapcraft.internal.load_config(self.project)
<bzoltan> didrocks:  perfect :)
<didrocks> bzoltan: sweet! :)
<qengho> sparkiegeek: Just to peek, I suggest  "sudo -e /usr/lib/python3/dist-packages/snapcraft/internal/common.py"  and adding  subprocess.check_call(['/bin/cat', f.name])  after the two f.flush()es.
<sparkiegeek> qengho: hah! I'm doing something similar right now :)
<sparkiegeek> qengho: thanks
<ogra_> pitti, hrm hrm
<ogra_> http://paste.ubuntu.com/23392478/
<foxmask> hi
<foxmask> i try to make a snapcraft package but in my project I need to provide pypandoc (a python wrapper of pandoc) but the python3 installation try to use a bdist_wheel that is not supported by pypandoc. Is there a way to tell to snapcraft to not for the usage of wheel with the python3 plugin ?
<qengho> foxmask: does it fail, or just look ugly when it tries something not supported?
<foxmask> qengho: its ending like this
<foxmask> Failed to build pypandoc
<qengho> Oh man.
<foxmask> even if i can use it with import python
<foxmask> "ERROR: Failed to build one or more wheels
<om26er> ogra_: is there a way to install Core on snapdragon' internal storage ?
<om26er> or boot from sdcard is the recommended and the only way ?
<ogra_> the latter
<Son_Goku> zyga: ping
<ogra_> theoretically it would be easy (you can do it on the beaglebone for example) but for dragonboard you would have to re-build the first stage bootloader to initialize the MMC instead of the SD
<vigo> ogra_, I'm writing some test cases for console-conf but there are somethings not clear yet, hope you can help me :)
<om26er> hmm, I was curios to check if the DB internal storage performs faster than my sdcard. I'll wait, maybe in future we'll have some kind of wizard to achieve that.
<qengho> Is my Pandaboard useless?
<vigo> ogra_, for example when we setup the network config, are all the changes suposed to be saved even if I reboot?
<Son_Goku> can anyone answer where snap(1) man page is?
<Son_Goku> because it's referenced in the systemd units
<ogra_> ppisati, ooooh !!! look what i just hit on the pi3 http://paste.ubuntu.com/23392621/
<ogra_> vigo, i think when you did hit the "done" button they should be saved in a file in /etc/netplan/
<ogra_> ppisati, so it smells like you are right about a powering issue ... the above actually happens when console-conf (or netplan) tries to bring the wlan0 device down and up again
<DonOregano> Sorry if I'm "reposting", but I think I got disconnected: I'm the maintainer of an open source SDK for distributed systems (Safir SDK Core), and I've been thinking about whether Snap is suitable for packaging it. The product consists of a bunch of executables and programming interfaces in C++ (libs and headers), Java (jars) and C# (assemblies). A developer is meant to download the SDK and start using my interfaces in his/her programs. I've been readin
<srle> hello
<srle> how can I get git repo of ubuntu core
<vigo> ogra_, great thanks, so that means that once you have set the network config it should appear already configured after reboot right?
<qengho> DonOregano: A snapped program can't write outside of some very specific places, so perhaps it's not a good fit for a tool like a compiler, but it might be nice to make the software that your SDK makes to be easily snap-able.
<DonOregano> Ok, that was kind of what I was suspecting.
<ogra_> vigo, theoretically even without reboot, but that seems broken atm
<vigo> ogra_, excellent now I can write it :) thank you
<ppisati> ogra_: how did you get that?
<qengho> DonOregano: How can we help make your software-maker generate snaps?
<ogra_> ppisati, i ran "sudo console-conf" on an already configured snappy pi3 ... to reconfigure for wlan
<vigo> ogra_, this is one of the bugs related? https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1636419
<ogra_> (i.e. i can only finish the install using eth0 currently ... then i reboot and do the above to turn off eth0 and turn on wlan0)
<mup> Bug #1636419: Network settings aren't set in Dragonboard <Snappy:Confirmed> <subiquity (Ubuntu):Fix Released> <https://launchpad.net/bugs/1636419>
<DonOregano> qengho: Well, that is not so much the issue. Whatever the user/developer that uses my SDK does with packaging is not likely to be SNAP-friendly, since it is mainly defense industry management systems, so easy deployment to "people on the internet" is not really their cup of tea....
<ogra_> vigo, no, that should work (it surely does here )
<DonOregano> qengho: I was just hoping to find an easier way of getting my SDK to my users... Especially to be able to get new users :-)
<ogra_> vigo, not sure we have a bu for that yet .. console-conf calls "netplan apply" but that doesnt seem to actually restart the network interfaces in the new configuration without reboot ... perhaps pitti can tell you if thats actually supposed to happen
<ogra_> *bu
<ogra_> bah
<ogra_> *bug
<pitti> ogra_: netplan apply simulates an unplug/replug for interfaces that are down; networkd doesn't touch interfaces which are already up
<qengho> DonOregano: Three features DI folks would like are 1) roll-backs to known good versions, 2) internalized dependencies so updates of A don't affect B, and 3) compartmentalized execution, so an adversary breaking one pieces doesn't mean he can break more.
<ogra_> pitti, well, if i enable wlan in console-conf (logging in via ssh through eth0) and call ifconfig afterwards, the wlan0 device isnt up
<ogra_> pitti, eth0 is gone and wlan0 is up after a reboot though
<pitti> apply is supposed to bring it up then, so if that doesn't work, it's a bug
<qengho> DonOregano: That updating part is easily turned off.
<pitti> ogra_: (works here, though)
<pitti> i. e. needs precise logs and config files
<ogra_> pitti, ok ... not sure if its consoleconf, netplan or the driver though
<pitti> ogra_: someone added a blacklisting to one driver, though, bug 1630285
<mup> Bug #1630285: mwifiex_pcie crashes after several bind/unbind <kernel-da-key> <originate-from-1623583> <plano> <verification-needed> <HWE Next:New> <linux (Ubuntu):Triaged> <https://launchpad.net/bugs/1630285>
<DonOregano> genqho: Yeah, I agree! And I can see that Snaps would be useful for a "finished product" based on my SDK. I may look in to that as a suggestion for one of my users. But that wasn't really what I was after today.
<pitti> ogra_: so if it's that driver, that would explain it
<ogra_> pitti, yeah, no PCIe on my boards here :)
<pitti> well, at least half of it; if it's down and you have a config then it should still be brought up
<pitti> ok, that's the only one I'm aware of
<ogra_> pitti, i see it in a Pi3 ...
<ogra_> which is bradcom wlan
<DonOregano> genqho: Today I was after getting out of maintaining separate packaging for Ubuntu, Debian, RHEL/Centos and Arch, etc.
<ogra_> ogra@pi3:~$ lsmod
<ogra_> Module                  Size  Used by
<ogra_> brcmfmac              282624  0
<ogra_> brcmutil               20480  1 brcmfmac
<ogra_> cfg80211              548864  1 brcmfmac
<ogra_> pitti, but that could indeed also die due to bind/unbind loops
<qengho> DonOregano: Cool. We'll be here when you're ready. IF the sdk always builds in the user's $HOME, it could fit, but I can imagine build bots in /data and such not working.
<DonOregano> qengho: But if snaps are not suited for exposing APIs in C++/Java/C# to developers then I will stay where I am.
<DonOregano> qengho: Thanks. I'll keep checking out where things are headed with Snaps. I do like the idea...
<qengho> DonOregano: Snaps aren't that specifically restricted. It could do all that, but it would have an opinion about where it is allowed to write, which is a feature, and possibly hated by some fraction of your users.
<qengho> DonOregano: So, not now. Yes, try again later.
<DonOregano> qengho: Hehe. Yeah, I would really like to avoid aggravating my users with "newfangled stuff" :-)
<ppisati> ogra_: can you open me a bug for that? my rpi3 is still dead, but i can start looking at it (and then we keep track of it)
<ogra_> ppisati, bug 1637505
<mup> Bug #1637505: power error under ubuntu core when running console-conf <Snappy:New> <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1637505>
<mup> Bug #1637505 opened: power error under ubuntu core when running console-conf <Snappy:New> <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1637505>
<Son_Goku> zyga: https://github.com/zyga/snapcore-fedora/pull/10
<mup> PR zyga/snapcore-fedora#10: Refresh patches for snapd spec <Created by Conan-Kudo> <https://github.com/zyga/snapcore-fedora/pull/10>
<tsdgeos_> hi, there, how is one supposed to debug a snappy program?
<tsdgeos_> http://paste.ubuntu.com/23392842/ is what i get at the moment
<tsdgeos_> http://askubuntu.com/questions/783979/how-do-i-debug-snaps
<tsdgeos_> not sure that helps me
<tsdgeos_> let's try
<dobey> tsdgeos_: afaik, debugging something in a snap is mostly the same as debugging something not in a snap, it's just that the logs and locations of various things are all different; and you can't debug symbols from .debs necessarily
<tsdgeos_> dobey: well, i can't gdb it
<tsdgeos_> so debuggin it is not "as you would do it without a snap"
<tsdgeos_> unless people don't use a debugger to debug stuff nowadays :D
<dobey> tsdgeos_: why can't you gdb it?
<ogra_> you can, but you need to ship gdb inside your snap
<tsdgeos_> dobey: http://paste.ubuntu.com/23392842/
<tsdgeos_> ogra_: lol
<tsdgeos_> very useful :D
<ogra_> then you can use "snap run --shell $app_in_the_snap"
<dobey> ogra_: or use the classic snap or be running on a classic system?
<ogra_> that gives you a shell you can run gdb in
<ogra_> dobey, the classic snap only works on all-snap systems, but yeah, thats possible too
<ogra_> apt install gdb and attach to the pid
<ogra_> (dont try to install the classic snap on a classic system ... wont work)
<dobey> ogra_: right, i'm saying that's an option if you're doing that. if you're on a classic system, gdb from the host should be usable. the main issue is getting the env set up and running the right thing
<ogra_> i dont think gdb from the host will work, apparmor and seccomp will get in your way
<dobey> i mean, running gdb from the host, not from within a shell in the confined snap
<ogra_> yes, me too :)
<dobey> ie SNAP=/snap/foo/8 gdb /snap/foo/8/bin/baz
<ogra_> anyway, since you need debug symbols anyway, i'd just build a debug snap with gdb included and use snap run
<Croepha> is there a way to put the /init that resided in the initrd into a debug/verbose mode? i built a kernel using snapcraft, and its behaving differently than the vanilla binary does... it boots to systemd and I can get a debug shell, but its like the system doesn't fully come up, and if I boot with init=/bin/bash then the environment is pretty different upon boot, my custom kernel has a bunch of /tmpmnt_.... left on the root, while the vanilla version
<Croepha>  looks like it swapped root correctly....
<ogra_> Croepha, put "break=bottom (or =top or =premount) on your kernel cmdline ... that gives yoou a shell iside the initrd
<ogra_> if you ctrl-d it moves on with the boot
<Croepha> ogra_: ok cool thanks, i'll give that a try
<Croepha> the only thing I can think of, unless there is an error, is just to extract both the initrds and diff them
<ogra_> they should hopefully be 100% identical (apart from the modules shipped)
<mup> PR snapd#2228 opened: Allow fwupdmgr refresh <Created by timchen119> <https://github.com/snapcore/snapd/pull/2228>
<Croepha> wow, looks like break=top did the trick, it stopped on an error
<Pharaoh_Atem> zyga: ping
<Croepha> maybe it doesn't have anything to do with the contents of the initrd...
<Croepha> im getting a "No such file or directory" fir /tmpmnt_writable/system-data/var/lib/snapd/snaps/core_324.snap
<Croepha> my vanilla version has a "ubuntu-core_758.snap"
<ogra_> that sounds like your ubuntu-imae is very outdated
<ogra_> ubuntu-core is dead, new images should all be using "core"
<Croepha> ahh ok
<ogra_> (we still build ubuntu-core but only for classic installs until there is a proper migration path)
<ogra_> so snap refresh your ubuntu-image snap ;)
 * ogra_ goes afk for a while
<vigo> pitti, what I asked ogra_is if once the network configuration is done, it's saved in a way that reboot will keep changes?
<Croepha> ogra_ Thanks!
<Pharaoh_Atem> has anyone seen zyga today?
<vigo> pitti, will it save the access point name so there is no need to enter it again after reboot
<pitti> vigo: no, it should be saved somewhere in /etc/netplan/*.yaml
<bzoltan> ogra_:  do we have separate image for RPi3?
<ogra_> bzoltan, yes, the one with pi3 in the name
<bzoltan> ogra_:  where does it live? Not listed here - http://cdimage.ubuntu.com/ubuntu/releases/16.04/release/
<ogra_> https://lists.ubuntu.com/archives/snapcraft/2016-October/001463.html
<vigo> pitti, yes, that's what ogra_ told me, so we must re-enter the whole network config if console-conf did not finish?
<ogra_> you should really read your mails
<pitti> vigo: I don't knwo that part
<bzoltan> ogra_: danke
<ogra_> np :)
<Pharaoh_Atem> elopio: I'm not sure how to write unit tests for https://github.com/snapcore/snapcraft/pull/870
<mup> PR snapcraft#870: sources: Add RPM source <Created by Conan-Kudo> <https://github.com/snapcore/snapcraft/pull/870>
<Pharaoh_Atem> I have integration tests but I don't have a unit test for it
<Pharaoh_Atem> the integration test works, btw
<vigo> pitti, after wlan0 config I pressed done, and reboot before typing the e-mail. This way seems to work fine because after reboot it remembers the wi-fi ap, IP etc
<vigo> so fine for me :)
<Trevinho> hey, If I set a package in stage-packages, is there a way to ensure that the recomends for that hare pulled too?
<qengho> Trevinho: I don't think so. Why not an explicit depends, if it's a hard requirement for you?
<Trevinho> qengho: well, of course I can, but having a flag that allows to do that would be nicer :-)
<Trevinho> than listing all the packages that might change with time...
<Croepha> woah, i updated ubuntu-image and my output file is way smaller than before, either this is a really cool feature, or my stuff is borken now
<bzoltan> ogra_:  is there a way to create custom core image with certain pre-configured network profile?
<Croepha> bzoltan: im sure there is a better way to do it, but what I have been doing is mounting the image and adding a script to run on a first boot to set the network config
<mup> PR snapd#2229 opened: interfaces/sytemd: enable/disable generated service units <Created by morphis> <https://github.com/snapcore/snapd/pull/2229>
<bzoltan> Croepha: that would make the job for me :) Do you have that script to share? - sans credentials of course :)
<jdstrand> morphis__ (cc niemeyer): notice my updated comment: https://github.com/snapcore/snapd/pull/2228#issuecomment-256955020
<mup> PR snapd#2228: Allow fwupdmgr refresh <Critical> <Created by timchen119> <https://github.com/snapcore/snapd/pull/2228>
<jdstrand> morphis__: so I backed out my approval after thinking about it
<morphis__> jdstrand: aye, didn't looked much into it yet, just got that from Tim
<jdstrand> morphis__: if you guys go the plugs route, then I'll need to adjust the snap declaration (which I'm happy to do)
<morphis__> jdstrand: I am not really sure why Tim added it on the plug side
 * jdstrand nods
<Croepha> bzoltan, I haven't tested this on uptodated core yet, still trying to get my custom kernel working, but this is what I did: https://gist.github.com/croepha/d006ec1f62dd4dcb1774c5116d1cebff
<Croepha> also, I kinda quickly just through that together so, hopefully it has everything you need and isn't messed up... let me know if you need help
<Croepha> bzoltan: basically sudo touch ${DIR4_}/custom_image/system-data/var/lib/console-conf/complete prevents the normal ubuntu config from running
<Croepha> bzoltan: and cat <<EOF | sudo tee ${DIR4_}/custom_image/system-data/etc/network/interfaces.d/wlan0 writes the network config
<mup> PR snapd#2230 opened: Add an interface that allows clients to use media-hub over dbus <Created by jhodapp> <https://github.com/snapcore/snapd/pull/2230>
<bzoltan> Croepha: cool, thank you. I will try that
<mup> PR snapcraft#878 opened: Added a fix for cases where modpbrobe append options to the line, ie.â¦ <Created by croepha> <https://github.com/snapcore/snapcraft/pull/878>
<josharenson> So I've added a package to my snaps build-packages. How do I get snapcraft to pull that? Snapcraft pull <part> doesn't seem to work and I can't tell if the package is broken or if it was never pulled...
<josharenson> it doesn't seem to be pulling any of the "build-packages" is there a way to debug this?
<bzoltan> Croepha:  the file system layout is rather different with the RPi3 latest image -> http://pastebin.ubuntu.com/23393529/
<kyrofa> josharenson, build-packages are installed on the host-- you realize this?
<Croepha> bzoltan, the systemd/network dirs might not exist before first boot
<mup> Bug #1637445 changed: The serial vault fails to connect to serial-vault.canonical.com <Snappy:Invalid> <https://launchpad.net/bugs/1637445>
<bzoltan> Croepha: Ahh... so I better play with the once booted images.
<Croepha> that might be a good place to start, but if you actually just create the dirs after building the image that works too
<josharenson> kyrofa: yeah, I think its actually just, yet another,  path issue
<mup> Bug #1637596 opened: Configure hook in tried snap with ecryptfs: permission denied <Snappy:New> <https://launchpad.net/bugs/1637596>
<Croepha> well, even after updating ubuntu-image i still have a problem, it looks like with my custom kernel, there is a problem with mounting the fs for boot.... IO charset iso8859-1 not found... going to compare the kernel configs now
<ogra_> Croepha, you wand vfat builtin ... (and the right nls codepage for iso8859-1)
<bzoltan> Croepha:  yeps, just creating that wlan0 file did the trick. Thanks for your help.
<Croepha> bzoltan: ok, no proble,
<Croepha> no problem*
<bzoltan> ogra_:  lame question... how can I turn this beast to be in a dev mode. I would like to apt stuff there
<Croepha> bzoltan: are you use that DNS is working, i had to start a systemd-resolve service tooo
<ogra_> you cant ... you can install the classic snap to have a classic "chroot"
<ogra_> sudo snap install classic --devmode --edge
<ogra_> then: sudo classic
<ogra_> that sets it up and gives you a shell where you can use apt
<bzoltan> ogra_:  cool, thanks
<bzoltan> ogra_:  I guess I need a classic env in order to snapcraft projects for armhf locally
<ogra_> yep
 * ogra_ vanishes again
<Croepha> ogra_ so the kernel I built has CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" which seems to match the vanilla kernel
<Croepha> im going to double check to make sure I didn't like bundle the wrong kernel or something really stupid
<Croepha> it looks like nls_iso8859-1 is a module in the vanilla kernel, and I guess I just forgot to include that one
<Croepha> building a new snap now, hopefully this time it works
<mup> Bug #1637611 opened: UTF-8 local via ssh is poorly handled <Snappy:New> <https://launchpad.net/bugs/1637611>
<tealeg> yes
<barry> what's the current blessed way of defining the license for a snap?  the docs still talk about a `license:` key in snapcraft.yaml, but snapcraft says that's deprecated and if it's included you get an error on second and subsequent builds
<barry> oh, i found the discussion in the mailing list.  docs are lagging
<barry> https://lists.ubuntu.com/archives/snapcraft/2016-September/000978.html
#snappy 2016-10-29
<bzoltan> ogra_:  silly questions :) 1) is there a way to create users on snapp device? 2) Can I run a single command (or /bin/bash) in classic just as in a chroot? Like ssh root@device_ip '/snap/bin/classic /bin/bash -c "foo"' ?
<Son_Goku> zyga: ping
<ogra_> bzoltan, 1) adduser with the --extrausers option .. 2) indeed, but not as root@$ip .... you need sudo (passwordless by default though)
<bzoltan> ogra_: surprisingly the `ssh root@192.168.1.116 '/snap/bin/classic 'df -h''` works for me
<ogra_> how could that be
<ogra_> (on an unmodified image)
<qengho> Those ' quotes look funny too.
<ogra_> bzoltan, by default the root account is locked and you cant set a password (readonly passwd file), so if you didnt hack up the imae to put a root ssh key in place or some such this should definitely not work
<ogra_> (and would be a totally unsupported path too)
<bzoltan> ogra_: I have set up the ssh auth
<qengho> This works for me: ssh Addr -l Me 'sudo /snap/bin/classic df'
<ogra_> surely not via the config tools
<qengho> Without 'sudo', complains.
<ogra_> yep
<ogra_> bzoltan, either use a system-user assertion, or run through the config UI, or use cloud-init, everything else is completely broken and will cause misbehaviour (all tools set up the user via snapd which does a bunch of more stuff than just adding a user to the passwd file)
<bzoltan> ogra_: I see
<ogra_> just hacking up the image like that will not behave like any other snappy install
<bzoltan> ogra_:  make sense
<bzoltan> ogra_: I am just hacking around :) and collect thoughts.
<ogra_> (sadly i dont know much about the system-user assertions, but thats likely your way to go ...)
<bzoltan> ogra_:  what is that config UI?
<ogra_> well, console-conf ... the cli UI that starts on every tty on first boot of the image
<bzoltan> ogra_:  hmmm... I have no hdmi display, neither usb keyboard
<ogra_> well, every tty includes serial ;)
<bzoltan> ogra_:  Have you seen the RPi osmc image installation?
<ogra_> nope
<bzoltan> ogra_:  I love that ... it is a desktop tool. You select the sd card device, define what wlan you want to be default and it flashes the OS on teh sdk card with that... after that you have ssh
<ogra_> ah, something like that is in the TODO list ... but further out
<bzoltan> ogra_:  with our stuff it is a bit too much hacking for a newcomer
<bzoltan> ogra_:  do you want my team to work on making the RPi/DB installation more convenient?
<ogra_> well, you dd, boot the board, run through the config ... done
<bzoltan> ogra_:  It is kind of SDK stuff... making developer's life easy
<ogra_> bzoltan, talk to sabdfl ;)
<ogra_> there are frameworks (very roughly) defined already that were designed at the snappy sprints
<ogra_> i.e. you would have a UI that actually creates the model assertion, the system-user assertion and calls ubuntu-image in the end to create a matchin img that you can provision with the created system-user assertion
<bzoltan> ogra_: how 'run thru the config' works without keyboard and and display?
<ogra_> it doesnt
<ogra_> you need access to a tty atm
<ogra_> typically embedded/IoT people use serial consoles for that though
<ogra_> (thats the current target audience)
<ogra_> a commercial vendor would ship a USB key with system user assertion i guess ... that you can plug in on first boot to have the setup run automagically
<ogra_> (or have an online assertion creation tool where you can put in your credentials to have the assertion created for a usb key)
<bzoltan> ogra_:  I assume that for tty I need a GPIO-USB cable ...
<ogra_> something like https://www.amazon.de/gp/product/B00KVUSI30
<bzoltan> ogra_: yeps, I am familar with that.
<ogra_> (thats the one i have)
<bzoltan> ogra_: I need to dig up my inventory for that :) or make one...
 * bzoltan is not in soldering mood
<ogra_> heh
<ogra_> you dont need to solder anything with the one above
<ogra_> (there are little plugs at the ends of the cables, you just plug them onto the right pins)
<bzoltan> ogra_: not if you have one :)
<bzoltan> ogra_:  I know GPIO, I have all those cables and plugs for the headers. It is fairly easy to solder one...
<ogra_> well, you need the FTDI electronics that are hidden in the USB plug
<ogra_> its not a stragit usb cable
<ogra_> *straight
<bzoltan> ogra_: True, it is easier to buy one
<mup> Bug #1637611 changed: snappy images should not ship /etc/profile.d/Z99-cloud-locale-test.sh <Snappy:Fix Released by ogra> <livecd-rootfs (Ubuntu):Fix Released by ogra> <https://launchpad.net/bugs/1637611>
<qengho> Are there any docs on how app authors should be using "snap set"?
<foxmask> someone use snapcraft for a django project ? i'd like to see how snapcraft.yaml looks like
<qengho> foxmask: I haven't, but I can imagine it. Have you made anything with snapcraft yet?
<foxmask> i try but I am not satisfied
<ogra_> yay, my new kbd just got delivered
 * ogra_ dances
<qengho> Clicky?
<ogra_> super clicky, super small :)
<ogra_> vortex pok3r
<qengho> ogra_: Photo plz.
<ogra_> https://mechanicalkeyboards.com/shop/images/products/large_1239_IMG_0984.jpg
<qengho> foxmask: Let's start with your yaml. Pastebin it?
<ogra_> full metal body
<qengho> ogra_: that's hot.
<qengho> ogra_: I've been meaning to put braille caps on my keys so that I learn to read blind as I type.
<ogra_> haha
<ogra_> cool idea
<ogra_> well, i'm still looking for a good set of SA or DSA caps for it now
<ogra_> like https://pbs.twimg.com/media/CpyKqqEWYAUpvbY.jpg
<ogra_> (probably less colorful)
<ogra_> going back to commodore VIC20 typing ;)
<ogra_> thats more like it https://imgur.com/S3N6i0L
<foxmask> qengho: https://gist.github.com/foxmask/4d6ab10571a4d500778d70b336877ed2
<qengho> foxmask: Those look great!
<qengho> foxmask: For your command, you might find what you're looking for with...
<foxmask> qengho: if only :)
<foxmask> i searched here https://github.com/search?o=desc&p=5&q=filename%3Asnapcraft.yaml+%22plugin%3A+python3%22+&s=indexed&type=Code&utf8=%E2%9C%93
<qengho> $ find /snap/trigger-happy/current -type f -name python2 -o -name manage.py
<ogra_> try dropping the python in fromt of the command, let it use the shebang
<ogra_> *front
<qengho> foxmask: If it's python3, use that name to search, of course.
<ogra_> and perhaps make it ./manage.py if the script isnt in PATH (i.e. $SNAP/bin )
<foxmask> qengho: there is no python* on manage.py script in that path
<foxmask> ogra_: i also tried command: manage.py  but here too, the command is not found
<ogra_> where in your snap does it end up ?
<qengho> foxmask: pastebin  $ find /snap/trigger-happy
<foxmask> qengho: return nothing :)
<foxmask> ogra_: how can I check the content of the snap ?
<ogra_> if it gets put into $SNAP/bin it will be in your path ... if not, you should add the path to the line relative to $SNAP
<qengho> foxmask: it returned something.
<ogra_> build it, install it and look in /snap/$packagename/current/
<foxmask> qengho: ok
<foxmask> qengho: log exceeded the max size everywhere I paset :) I come back ; afk do 30m,
<foxmask> paste*
<ogra_> just use paste.ubuntu.com
<qengho> and we don't need everything. ...
<qengho> foxmask: pastebin  $ find /snap/trigger-happy -type f -executable
<clobrano> Hi there, I just observed that the ubuntu-core snap in my ubuntu 16.04 is "broken". What does it means specifically, and how can I fix it? Thanks
<foxmask> qengho: http://0bin.net/paste/C5xRZcgI3Fm6Otb2#l-0oY43Oxh8pds9dL1lijoTx5ioHwjUUGpl8WGmY/8B
 * foxmask bacj
 * foxmask back
<foxmask> qengho: forget all of that . that will wait :)
<foxmask> cu
<linuxhiker> Is there a way to pass shell variables in a snapcraft.yml? For example... CC="-static" ./configure
<linuxhiker> curious why I am getting this: make: *** No rule to make target 'world'.  Stop.
<linuxhiker> Command '['/bin/sh', '/tmp/tmp6aq0q9nt', 'make', 'world', '-j1']' returned non-zero exit status 2
<linuxhiker> this comes when I use snapcraft but the command itself: make world -j1 works from the command line
#snappy 2016-10-30
<mup> PR snapcraft#868 closed: Parametrize call args for pluginhandler <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/868>
<zyga> Son_Goku: hey
<zyga> Son_Goku: greetings from bucharest
<zyga> Son_Goku: how's stuff?
<Son_Goku> you're alive!
<Son_Goku> *\o/*
<zyga> gee, dude, shave ;-)
<zyga> this is the last week of my journes
<zyga> I saw some warnings that snap-confine doesn't build in master
<zyga> Son_Goku: how are you doing?
<Son_Goku> I'm alright
<Son_Goku> I've been getting pings about snapd for Fedora though
<Son_Goku> and you missed me getting the policy working
<zyga> Son_Goku: \o/
<zyga> Son_Goku: wooot, what's next?
 * zyga hugs Son_Goku :)
<Son_Goku> https://github.com/zyga/snapcore-fedora/pull/10
<mup> PR zyga/snapcore-fedora#10: Refresh patches for snapd spec <Created by Conan-Kudo> <https://github.com/zyga/snapcore-fedora/pull/10>
<Son_Goku> first, merge that
<zyga> Son_Goku: I was broken during wekeend and partially last week, trying to get some health back
<zyga> checking that out now :)
<Son_Goku> then update https://bugzilla.redhat.com/show_bug.cgi?id=1367825 with a new spec
<Son_Goku> and SRPM
<zyga> yep, with pleasure!
<Son_Goku> and since the service files have changed a bit, check to be sure if additional services need to be requested for the preset: https://bugzilla.redhat.com/show_bug.cgi?id=1367932
<zyga> Son_Goku: yeah, I was just thinking about that
<Son_Goku> I think snapd.autoimport.service needs to be enabled as well
<zyga> Son_Goku: no, not really, it's just for core AFAIK
<zyga> Son_Goku: I need to check with mvo when he's here today but I don't think we need it
<zyga> well. think :)
<zyga> Did you get it to work all the way?
<zyga> with snaps installing and stuff?
<zyga> `+2.8.4 (Apple Git-73)
<Son_Goku> well, I need to retest on a fresh VM to be certain, but yes
<zyga> was that you or me? :)
<Son_Goku> https://github.com/snapcore/snapd/blob/master/debian/rules#L66
<zyga> that's amazing :)
<Son_Goku> that's where I checked to see the services that should be enabled
<zyga> yeah, I know we run them everywhere
<zyga> but I think this was just us hurrying with image readiness
<zyga> I'll double check with mvo
<Son_Goku> ah
<zyga> I'd rather not enable that service unless we have to
<Son_Goku> right
<Son_Goku> if it's not necessary, then leave it be
<Son_Goku> I've already updated the patches to have new versions of the services :)
<Son_Goku> O.o
<Son_Goku> ffs
<Son_Goku> the store doesn't work now!
<Son_Goku> because it uses port 53
<Son_Goku> nowhere was that documented :(
<zyga> Son_Goku: what's the .foo syntax in %patchN
<zyga> what?!?
<Son_Goku> zyga, if the patch fails, the buildroot maintains a backup copy of the original with that prefix
<zyga> port 53?
<zyga> ah, nice
<Son_Goku> makes it easier for rediffing
<Son_Goku> wtf is it using port 53 for?!
<zyga> Son_Goku: DNS?
<zyga> Son_Goku: can you point me to some code that does this?
<Son_Goku> I just tried to do "sudo snap install hello"
<Son_Goku> try it in a Fedora VM with the package and latest stuff
<Son_Goku> ah, I think it is DNS lookup
<Son_Goku> why is snapd doing its own DNS lookup?
<zyga> Son_Goku: probably because it's golang but I'm checking
<zyga> Son_Goku: yes, internal DNS
<zyga> Son_Goku: does that need selinxu tweaks?
<Son_Goku> yes
<Son_Goku> are there any other TCP/UDP things that I need to do as well?
<zyga> I don't know of any
<zyga> just https and DNS
<zyga> Son_Goku: as a side comment, working on confinement of any kind makes you re-learn how the stack _really_ works
<zyga> Son_Goku: I find that refreshing
<zyga> Son_Goku: merged
<Son_Goku> I'm working on adding rules for dns and http cache ports
<Son_Goku> I have a feeling it'd be a good idea to add cache ports too
<zyga> Son_Goku: http cache?
 * zyga is starving, had u-breakfast only 
<Son_Goku> ports like 8080, etc.
<Son_Goku> often used by proxies and stuff
<zyga> ah, I understand
<zyga> sure
<zyga> Son_Goku: ok, we don't want autoimport
<zyga> Son_Goku: I'll ript it out (both the service and udev)
<Son_Goku> okay
<zyga> Son_Goku: this means the approvals are okay now
<Son_Goku> just don't install the files, but leave the patches alone
<zyga> Son_Goku: I'll do this and redo the SRPM :)
<zyga> OK
<Son_Goku> what are they used for, btw?
<zyga> they are used to claim a headless device
<zyga> plug a drive with stuff you made elsewhere
<Son_Goku> ah
<Son_Goku> useless then
<zyga> it sucks assertions
<zyga> yes
<zyga> and "acks" them
<Son_Goku> but yeah, leave the patch alone
<zyga> (imports and checks signatures and cross-signatures and stuff)
<Son_Goku> as it can eventually be applied to snapd once the debian packaging is gutted from the package
<Son_Goku> technically, it could be applied now, as it doesn't conflict
<Son_Goku> but... meh
<zyga> Son_Goku: pushed a small patch, please look at it
<zyga> Son_Goku: this week I'll try to merge snap-confine into snapd and we _may_ finally get dist tarballs
<Son_Goku> neh
<Son_Goku> not particularly enthused about that *shrugs*
<zyga> well, it will simplify a lot though
<zyga> one package
<Son_Goku> at least from my point of view, not really
<Son_Goku> if we really wanted to build everything as one thing, we could have, since rpmspec supports multiple sources
<Son_Goku> technically, so does dsc built debian packages
<zyga> Son_Goku: yeah, that's true, this is more of an upstream change though, it will make changes easier
<zyga> close coupling between the two packages
<Son_Goku> zyga, you know, I'm surprised you guys don't just use systemd presets in the packaging of snapd for Debian/Ubuntu
<Son_Goku> it makes things a lot simpler
<Son_Goku> then you don't even *need* dh-systemd to do much
<zyga> Son_Goku: I suspect because those are not used in debian but I don't know
<zyga> Son_Goku: the first time I even realized this feature existed was when I started working with fedora
<zyga> Son_Goku: I'm building everything locally for testing
<zyga> Son_Goku: I'll do a small release of snap-confine to fix some issues and integrate patches with packaging, probably 1.0.44.1
<zyga> Son_Goku: but only after this works :)
<zyga> Son_Goku: I think we should do f24+ only for now
<zyga> Son_Goku: until 23 is resolved
<zyga> Son_Goku: right now I think I broke 23 because of older libc (trivial patch already merged into master)
<zyga> Son_Goku: and we need to update something (still unsure what) to get store interaction to work
<Son_Goku> well, Fedora 23 is EOL in December
<zyga> Son_Goku: but again, I'll focus on 23 when 24+ is done
<zyga> Son_Goku: are there any stats available to know how many users moved to 24 already?
 * Son_Goku shrugs
<zyga> OK
<zyga> well, I think 23 shoudl be easy-ish
<zyga> fingers crossed :)
<zyga> Son_Goku: what should I say for bodhi type= when there's just a new upstream release?
<Son_Goku> use bugfix as the type unless it's an enhancement
<zyga> Son_Goku: I want to update snap-confine in f24 with the new patches and snap runtime layout
<Son_Goku> or a security fix
<Son_Goku> bugfix
<Son_Goku> use bugfix
<zyga> Son_Goku: is there a bug? I think we can only refer to snapd tracking bug itself (/snap change)
<Son_Goku> bugfix doesn't require a bug
<zyga> Son_Goku: do I need a bug number or will it ignore it?
<zyga> ah, OK
<Son_Goku> it'll ignore it if no bugs are listed
<zyga> Son_Goku: any karma tweaks I should apply?
<Son_Goku> change the positive karma version from 3 to 1
<zyga> thanks, done
<Son_Goku> though I hadn't been pushing snap-confine updates through bodhi because I figured we'd want to ship snap-confine and snapd in the same update
<zyga>   https://bodhi.fedoraproject.org/updates/FEDORA-2016-c579dae0b4
<zyga> well, not today :)
<zyga> today I just want both out
<Son_Goku> well, fortunately, we can edit an existing update :)
<zyga> and this is 25
<zyga>   https://bodhi.fedoraproject.org/updates/FEDORA-2016-f3b947ec5d
 * zyga reboots with enforcing policy :)
<zyga> "make selinux enforcing again"
<zyga> I'll bump snap-confine dependeny to .44
<zyga> Son_Goku: more selinxu denials
<zyga> paÅº 30 15:25:38 fedora24 setroubleshoot[3400]: SELinux is preventing snapd from read access on the directory /etc/systemd/system. For complete SELinux messages. run sealert -l 3dc56126-a462-4305-8495-d9bb54be3740
<zyga> Son_Goku: can you please include that in the policy?
<Son_Goku> why does it need to read /etc/systemd/system?
<zyga> Son_Goku: you made it :)
<zyga> ah
<zyga> well, sorry
<zyga> my bad :)
<zyga> it needs to because it looks there for systemd units
<zyga> and knows which one to make and which to remove
<zyga> (snap specific untis)
<Son_Goku> so it needs read/write access to /etc/systemd/system
<zyga> Son_Goku: correct
<zyga> Son_Goku: one more denial
<zyga> paÅº 30 15:25:29 fedora24 setroubleshoot[3400]: SELinux is preventing snapd from node_bind access on the tcp_socket port None. For complete SELinux messages. run sealert -l 73e31352-953f-4156-8ab0-7b67ce1db019
<zyga> paÅº 30 15:25:29 fedora24 python3[3400]: SELinux is preventing snapd from node_bind access on the tcp_socket port None.
<zyga> that's internal golang thing that probes for ipv6
<zyga> Son_Goku: does this look ok? http://paste.ubuntu.com/23402604/
<Son_Goku> that's fine
<zyga> (I switched to ubuntu pastebin as the one on fedora didn't work for some reason)
<zyga> Son_Goku: pushed
<zyga> Son_Goku: if you fix the policy I think we can get this in now :)
<zyga> Son_Goku: can I help you in any way?
<Son_Goku> hmm
<Son_Goku> this is annoying
<Son_Goku> I may have to grant access to unlabeled files because snaps don't have the label applied to them :(
<zyga> Son_Goku: can you be more specifc?
<zyga> Son_Goku: snapd doesn't touch (I think) snap files, just systemd units it creates, udev rules it creates and a few other similar things (dbus xml stuff)
<zyga> Son_Goku: can those inherit the label from snapd somehow?
<Son_Goku> not sure
<Son_Goku> I wonder if systemd mounts can be set up to mount with a label?
<zyga> Son_Goku: maybe, let me look
<zyga> Son_Goku: nothing in systemd.mount
<zyga> er, systemd.unit
<zyga> morphis: hey
<zyga> morphis: are you working today?
 * zyga inspects failures on f26 and ppc64
<zyga> DEBUG util.py:421:  Error: nothing provides kernel-headers >= 2.2.1 needed by glibc-headers-2.24.90-13.fc26.ppc64.
<zyga> DEBUG util.py:421:  nothing provides kernel-headers >= 2.2.1 needed by glibc-headers-2.24.90-13.fc26.ppc64
<zyga> looks like something that's more general
<zyga> Son_Goku: I'll step outside to have a snack
<Son_Goku> urgh
<Son_Goku> Ubuntu Core does way too much
<linuxhiker> I am trying to figure out how to get the following to happen: ./configure; make world
<linuxhiker> I have configure working just fine
<linuxhiker> and make without world just fine
<linuxhiker> I figured out that if I use the make plugin, I can use a parent make file that can call world
<linuxhiker> but that is outside of the source tree as it is part of the snapcraft build system, not the software I am actually trying to build
<qengho> linuxhiker: Is that "configure" autoconf?
<qengho> linuxhiker: That "world" bit seems weird. Does it have a "install" target?
<linuxhiker> qengho: yes the configure is autoconf (that part works) and in fact the basic build works fine
<linuxhiker> qengho: but "world" is needed to build a secondary part of the source tree that only builds with either "world" or something like make -C contrib/Makefile
<zyga> Son_Goku: hey
<zyga> Son_Goku: so what did you manage to do with the policy?
<Son_Goku> I hate Ubuntu Core
<Son_Goku> I got enough for snapd, but apparently ubuntu-core wants to stick its fingers everywhere
<zyga> Son_Goku: can you be more specific and less dramatic
<Son_Goku> also, is ~/snap a directory created by snapd?
<zyga> indirectly, through snap run or snap-confine
<Son_Goku> zyga, ubuntu-core installs udev rules, etc.
<zyga> (currently both do)
<Son_Goku> okay, so I need to define a snap_home_t
<zyga> Son_Goku: yes, it manages the system
 * zyga pats Son_Goku on the back
<zyga> you can do it :)
 * Son_Goku sighs
<Son_Goku> also, apparently something wants to talk to NetworkManager
 * Son_Goku is tired
<Son_Goku> I'm taking a break from playing whack-a-mole
<Son_Goku> zyga, are there any specific directories I need to know about for the home directory?
<zyga> Son_Goku: no, just ~/snap
#snappy 2017-10-23
<mlw> Anyone here running the krita snap?
<zyga-ubuntu> good morning
<mvo> hey zyga-ubuntu , good morning
<zyga-ubuntu> mvo: hey, what a autumn-ish monday :)
<zyga-ubuntu> mvo: how are you doing?
<zyga-ubuntu> mvo: I'll get to reviews in a moment, just making tea
<mvo> zyga-ubuntu: things are going well, I start 2.29~rc1 today
<mup> PR snapcraft#1638 opened:  tests: reorganize unit and integration suites to make them easier to split for travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1638>
<zyga-ubuntu> mvo: do you think we will make it with all the PRs marked as a part of 2.29?
<mvo> zyga-ubuntu: not for ~rc1, but we can cherry-pick them all for ~rc2
<zyga-ubuntu> mvo: all right then
<kalikiana> o/
<zyga-ubuntu> jamesh: hello
<mvo> Chipaca: hey, quick question - the structured epochs branch has landed for 2.29 - does that mean our side is complete or will we have to do client side work still?
<Chipaca> mvo: there's no business logic
<mvo> Chipaca: aha, and we need that client side?
<jamesh> zyga-ubuntu: hi
<Chipaca> mvo: as i understand it the client needs to sanity-check epochs as part of validation, yes
<mvo> Chipaca: ok, thats fine then. was wondering if it should go into the 2.29 release notes draft or not :)
<zyga-ubuntu> jamesh: hey! :)
<Chipaca> mvo: i'd keep mum about it until both sides are done, in any case
<kalikiana> elopio: still awake? mind reviewing snapcraft#1627 ?
<mup> PR snapcraft#1627: lxd: split container classes into different files <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1627>
<zyga-ubuntu> jamesh: how are you doing
<zyga-ubuntu> jamesh: I'd like to sync on our work around mount features
<mvo> zyga-ubuntu: do you happen to know if there is a workaround for classic snaps not working on artful? the __libc_dl_error_tsd issue?
<zyga-ubuntu> mvo: I don't know of any workaround
<jamesh> zyga-ubuntu: I still need to get my user-mounts branch properly working for fuse mounts.  I got side tracked on some other bugs (there have been a few gnome-software/snap related issues that came up in the last week or so)
<zyga-ubuntu> jamesh: I'm working on overlay support and I think it could now be used for improved content interface
<zyga-ubuntu> jamesh: I'll probably look at a quick attempt to implement the new content interface ideas
<zyga-ubuntu> jamesh: (the one with saner one-to-many connections)
<zyga-ubuntu> jamesh: I could also try the idea where snap-update-ns is called for user mounts, if any exist, and see if that can be made to work
<pedronis> hi
<jamesh> zyga-ubuntu: so, the main issue I can see with using snap-update-ns for the user mounts is that we either (a) need to have snap-confine set up inheritable capabilities so snap-update-ns can do its job as a normal user, or (b) have snap-update-ns do the capability manipulation and setuid itself
<jamesh> zyga-ubuntu: with (a), we'd need to make absolutely sure those capabilities didn't leak out to the confined process.  With (b), we'd need to have Go bindings for the capability APIs
<zyga-ubuntu> jamesh: why does snap-confine need to run as a user the 2nd time? can it run as root and pass some arguments to the mount operation?
<jamesh> zyga-ubuntu: let's say that /foo is a fuse file system, and I want to do "mount --bind /foo/bar /mountpoint"
<jamesh> zyga-ubuntu: if "/foo" was mounted as an ordinary user, running the mount command as root will fail because root can't see "/foo/bar"
<kalikiana> c-lobrano: Did you see snapcraft#1636 ?
<mup> PR snapcraft#1636: internal: more gracefully determine host OS <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1636>
<jamesh> the kernel will only let the user that mounted the fuse file system see files and directories within
<zyga-ubuntu> jamesh: I see, how are they mounted by bubblewrap then? through capabilities?
<jamesh> zyga-ubuntu: yeah.  add  CAP_SYS_ADMIN to permitted set, setuid(real_uid), reacquire CAP_SYS_ADMIN, mount
<c-lobrano> Hey kalikiana, yes I saw it. Unfortunately I was to slow :D
<zyga-ubuntu> jamesh: could we do that with the C preamble?
<jamesh> zyga-ubuntu: using cgo might be the best option, yeah.
<zyga-ubuntu> jamesh: snap-update-ns has a non-trivial C preamble to do various pre-go manipulations
<ackk> niemeyer, hi, could you have another look at https://github.com/snapcore/snapd/pull/3916 ?
<mup> PR #3916: snap,wrappers: add support for socket activation <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916>
<Chipaca> pedronis: you're alive! \o/
 * Chipaca was starting to worry
<Chipaca> pedronis: how're you doing?
<pedronis> Chipaca: better
<Chipaca> pedronis: does that mean 'not 100% yet'?
<pedronis> not 100%,  but back to work,  still haven't finished my treatments (some more days of pills)
<Chipaca> pedronis: blagh :-/
<Chipaca> pedronis: during the NYC sprint I advanced on having tab completion for aliases done. I've got it working, but there are a lot of tests for aliases from foo to foo that, because of the simplistic way i implemented it, don't pass for completion. i wanted to check with you about the rationale for those tests to see if it made sense to skip them for this, or if i needed to fix the implementation to treat it specially
<pedronis> Chipaca: I'm probably missing context,   why doing tab completetion would break tests?
<pedronis> and what are aliases from foo to foo
<Chipaca> pedronis: aliases := []*backend.Alias{{"x", "x"}}
<Chipaca> that's an alias for something that already exists, right?
<pedronis> I suppose
<pedronis> I still don't understand why that then breaks when you add completion
<Chipaca> pedronis: i mis-spoke, the aliases don't break; matchingAliases et al don't return that as an alias, which means it's not returned
<Chipaca> i mean
<Chipaca> pedronis: should i push the branch and you read code, or should i continue trying to explain?
<Chipaca> pedronis: i tweaked the helpers to return the matching aliased commands and completions
<Chipaca> pedronis: commands is what was there before, those still work fine
<pedronis> which helpers?
<Chipaca> pedronis: completions will all be missing these auto-entries (the {"x", "x"} ones)
<Chipaca> pedronis: matchingAliases, missingAliases
<pedronis> matchingAliases is a test only helper
<Chipaca> yes
<Chipaca> as i say, it works, my doubt was with tests
<Chipaca> so i wanted to check with you about the intent of those {"x", "x"} ones before just removing them from the completion checks
<pedronis> can you give a  test file name  ?  (there's a lot of tests)
<Chipaca> pedronis: https://github.com/snapcore/snapd/compare/master...chipaca:complete-aliased#diff-66a739a11ce504d9bc94df4adb1e8bcdR377
<Chipaca> pedronis: the last two lines on that test
<Chipaca> one is for the command aliases, which is as it was before
<Chipaca> ie c.Check(matchingAs, DeepEquals, []*backend.Alias{{"baz", "y.baz"}, {"y", "y"}})
<pedronis> why completers need tests in backend?
<Chipaca> pedronis: because they're created there?
<pedronis> ah,  this is not about completeing aliases
<pedronis> this as about completing aliases args ?
<pedronis> we were on completely different thoughts
<Chipaca> this is about creating the completion snippet symlinks for aliased commands
<Chipaca> that is, when you alias foo.bar to bar, you want bar<tab> to run the completer for foo.bar
<pedronis> will not Alias{x,x} create a circular symlink ?
<pedronis> you are probably reading too much in those tests
<mup> PR snapcraft#1412 closed: lxd: snapcraft refresh in containers <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1412>
<Chipaca> pedronis: Alias{x,x} wouldn't work because it either doesn't exist, or already exists, so in either case it won't get touched
<Chipaca> pedronis: I thought they were probably the trivial case, but I don't know enough to be sure so rather than investigate i paused the work to ask you when you got back
<pedronis> I have as much clue as you on this
<Chipaca> hah
<Chipaca> pedronis: i thought you were mr aliases :-) but ok
<Chipaca> (it's not worrying that i was wrong -- but everybody else thought so too, and that might be a little worrying)
<pedronis> Chipaca: wrong abotu what?
<Chipaca> pedronis: about you being the person who knew about this bit
<pedronis> I wrote that code
<pedronis> it doesn't mean IÂ remember why a unit tests is some way or another
<pedronis> after months
<pedronis> afaict  Alias{x,x} will create a circular symlink
<mup> PR snapd#4065 opened: servicestate: use taskset <Created by stolowski> <https://github.com/snapcore/snapd/pull/4065>
<Chipaca> pedronis: fair enough. I'll go ahead and fix the tests to pass then, as the errors make sense
<Chipaca> pedronis: thank you
<Chipaca> pedronis: (my doubt was because maybe there were situations where that alias was attempted and something special needed to be done with it, but if it's just an easy test it's fine)
<pedronis> Chipaca: well it might be that we don't defend about somebody trying to set up such an alias, IÂ don't remember
 * kalikiana break
<pedronis> Chipaca: so it might be worth checking what happens
<pedronis> in that case
<Chipaca> ok
<pedronis> ah, you get  - Setup manual alias "spread" => "spread" for snap "spread" (cannot enable alias "spread" for "spread", it conflicts with the command namespace of installed snap "spread")
<pedronis> so we don't get there because of that
<pedronis> fwiw
<pedronis> Chipaca: ^
<Chipaca> pedronis: ack
<jamesh> zyga-ubuntu: by the way, I noticed that your devtools scripts don't work with the latest snapd.  Is there a newer way to test out changes on my dev system?
<zyga-ubuntu> no, not really
<zyga-ubuntu> I mostly use make hack
<jamesh> that doesn't really help for snapd changes though
<zyga-ubuntu> snapd is fine to run just from shell
<zyga-ubuntu> go build && sudo ./snapd
<Chipaca> zyga-ubuntu: no, because it panics if it's not running from /usr/lib/snapd/
<jamesh> I was getting this error: https://github.com/zyga/devtools/issues/25
<zyga-ubuntu> Chipaca: what? I never got that
<zyga-ubuntu> Chipaca: maybe I had no-reexec key set
<Chipaca> zyga-ubuntu: then you're not running it like that enough
<Chipaca> zyga-ubuntu: i get this with no-reexec set
<zyga-ubuntu> hmmm
<Chipaca> zyga-ubuntu: when trying to install something
<zyga-ubuntu> is that new?
<Chipaca> zyga-ubuntu: a month? two?
<Chipaca> super old
<zyga-ubuntu> I really think it's a bit shooting ourselves in the foot
<zyga-ubuntu> Chipaca: weird
<zyga-ubuntu> maybe my braches are just equally old
<zyga-ubuntu> maybe make hack should do more?
<zyga-ubuntu> (make hack == ~~ make install)
<mup> PR snapd#4066 opened: overlord/snapstate: support completion for command aliases <Created by chipaca> <https://github.com/snapcore/snapd/pull/4066>
<Chipaca> ok, i think i should go for a run
 * Chipaca goes
<niemeyer> ackk: Will do, thanks for the ping
<ackk> thanks niemeyer
<mvo> mwhudson: hey, if you happen to be around, I wonder if you have any idea about a symbol ' out of range error on zesty/ppc64el (go1.7)
<mvo> mwhudson: aha, nevermind, found the forum topic about it
<mup> PR snapd#4067 opened: packaging,spread: fix and re-enable opensuse builds <Created by zyga> <https://github.com/snapcore/snapd/pull/4067>
<leocadio_> Hello. I need to make some changes in the mac80211 and ath9k modules. Does anyone know how can I compile a new kernel snap with my changes, to replace the legacy kernel snap available in the Ubuntu Core distro?
<cachio> jdstrand, hey I am doing a test for the gsttings interface
<leocadio_> Is this possible?
<cachio> jdstrand, I see that the gsettings command is not able to access the schemas
<cachio> jdstrand, any idea about the configuration needed for that? is it ok to use the gsettings too to test that interface?
<cachio> jdstrand, I already tried with a python script but had a lot of issues with dependencies and showed similar problems with the schemas
<Chipaca> booo, something changed in travis and the "all good" thing is now even more garbled
 * Chipaca will fix, sometime
<Chipaca> mvo: how are we for adding things to 2.29?
<cachio> mvo, Chipaca are we still adding things to 2.29?
<Chipaca> cachio: that's what i asked, more or less :-)
<cachio> I already started beta testing on this
<mvo> Chipaca, cachio first rc1 is out but there will most certainly a rc2 so things are still open
<Chipaca> although my question would be "are we still doing that thing where we can sneak branches into the next point release if it happens"
<mvo> but we already catching the first issues (ftbfs on ppc64el/zesty for example)
<Chipaca> ok, if #4066 is as low drama as i think it is, i'll suggest it for point inclusion
<mup> PR #4066: overlord/snapstate: support completion for command aliases <Created by chipaca> <https://github.com/snapcore/snapd/pull/4066>
<Chipaca> otherwise .30 is fine
<pedronis> mvo: cachio: seeems we have a couple of assertions signed by an account/key from federico, not sure how they are used execatly, auto-import.assert is one of them, there's a bunch of model assertions too
<pedronis> if we redo the auto-import.assert one we probably need to redo some of the models too
<pedronis> mvo: is this related to the fact that there's a limit on how long a system-user can last ?
<mvo> pedronis: I think its unrelated but I have not looked in detail
<pedronis> mmh, no, the limit is only if no models
<pedronis> not sure why federico set it so
<pedronis> but maybe we changed that in between
<mvo> I suspect its and old test, that was one of the early ones
<mup> PR snapd#4068 opened: interfaces/builtin: add support for content "source" section <Created by zyga> <https://github.com/snapcore/snapd/pull/4068>
<jdstrand> cachio: you need to use the desktop part and its desktop-launch wrapper to generate the schema files aiui. you might talk to the desktop team for more specifics (eg, kenvandine)
<cachio> jdstrand, good, thanks
<cachio> mvo, 2.28.5 in stable
<cachio> \o/
<zyga-ubuntu> I need to pick up my daughter
<zyga-ubuntu> cachio: woot, thank you
<ogra_> heh, looking at snap info core looks cnfising with beta and edge now
<zyga-ubuntu> jdstrand: o/
<jdstrand> zyga-ubuntu: hi! fyi, 4008 and other PRs are at top of list today (after one thing I'll finish this morning)
<ogra_> mvo, should that beta build not also have gone to edge at the same time ? seems weird that beta has a higher versioon (and revision) than edge
<zyga-ubuntu> jdstrand: thank you! :-)
<zyga-ubuntu> jdstrand: I'm still working on some tweaks to the content one but I will post it as soon as 4008 is merged; I'll probably iterate with you today/tomorrow to land 4008
<mvo> ogra_: yeah, I think its confusing, edge is actually also new but the version does not reflect it. I will fix in a wee bit
<mvo> cachio: yay, thank you so much!
<cachio> mvo, np
<cachio> niemeyer, this week could you take a look to the PRs in spread-cron?
<cachio> niemeyer, taht would be grat if we can merge it soon
 * kalikiana need.. more.. coffee..
<kalikiana> kyrofa: elopio Are we having our weekly between the three of us then?
<kalikiana> in 15min
<kyrofa> kalikiana, I was assuming so after our discussion on Friday, but we honestly didn't make much more progress after you had to jet
<kalikiana> kyrofa: Ah. Should we maybe schedule another one for that? I can work late tomorrow so we have more time.
<mup> PR snapd#4069 opened: debian: do not build static snap-exec on powerpc <Created by mvo5> <https://github.com/snapcore/snapd/pull/4069>
<zyga-ubuntu> re
<kalikiana> kyrofa: The other thing I was thinking, maybe if you want we could chat about the OsRelease class a bit - I made some suggestions in my comments, but maybe we want to check if we're on the same page there?
<kyrofa> kalikiana, fine by me-- I'm always happy to meet regardless
<kyrofa> let's do it
<kalikiana> Okay
<kyrofa> I mean the one today. As for tomorrow, let's ask sergio when he's back
<kyrofa> I do think we need to continue breaking it down, but not sure when
<sergiusens> kyrofa what's up?
<sergiusens> kyrofa I added comments to the OsRelease stuff too
<sergiusens> kyrofa is snapcraft#1632 ready to go? this would be my final gripe to go to the stable channel :-)
<mup> PR snapcraft#1632: libraries: exclude the full set of libc6 <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1632>
<kyrofa> sergiusens, indeed it is
<kyrofa> sergiusens, I think we can improve that lib method, but it causes no harm in that PR
<kyrofa> And I've tested it pretty extensively at this point
<kyrofa> sergiusens, I'll go +1 it
<kyrofa> sergiusens, you realize though that those other two PRs are required for trusty support, right?
<sergiusens> kyrofa I have a PR refactor to change that module from `libraries` to `elf` and do some neat things in there
<kyrofa> sergiusens, excellent
<sergiusens> but I'd rather do minimal changes here so the test surface is not so broad to get a stable release out first
<kyrofa> sergiusens, fair enough. +1d
<zyga-ubuntu> niemeyer: I realized that due to a way apparmor is behaving we may need to have apparmor and mount kernels coordinate on the rename
<zyga-ubuntu> niemeyer: I'll make a test case to examine this
<mup> PR snapcraft#1632 closed: libraries: exclude the full set of libc6 <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1632>
<zyga-ubuntu> niemeyer: I also think that we must be careful in mixing slots that use source and those that don't
<kyrofa> sergiusens, I of course have some vested interest in trusty support. While I've got you: do you think it's possible to support using the snap (once it works) in the trusty builder? I've been getting some questions about this
<zyga-ubuntu> niemeyer: as this will cripple plug side
<zyga-ubuntu> niemeyer: I was thinking about an attribute that would let the plug side define and control one-to-many expectations: only-one, allow-many
<niemeyer> zyga-ubuntu: Which renames?
<sergiusens> kyrofa I think it should be possible with these changes; non classic confinement at least
<kyrofa> sergiusens, yeah that's a whole different ballgame
<niemeyer> zyga-ubuntu: Yeah, we'll need that at some point, but I suggest not doing that now so we don't get lost from the key priorities
<zyga-ubuntu> niemeyer: https://forum.snapcraft.io/t/improvements-in-the-content-interface/2387
<kyrofa> cjwatson, if the snapcraft snap worked on trusty, is that a capability you'd be able to expose in the LP builders, or build.snapcraft.io?
<zyga-ubuntu> niemeyer: ack
<zyga-ubuntu> niemeyer: on that page look for "renamed"
<kyrofa> cjwatson, the snapcraft in the archive is v1, targeting 15.04
<kyrofa> But there are people who actually need to build series 16 snaps on trusty
<kyrofa> Oh sorry kalikiana got caught up in coffee
<kyrofa> On my way
<kalikiana> haha
<kalikiana> no worries
<niemeyer> zyga-ubuntu: By "kernels" you mean "backend" I suppose?
<cjwatson> kyrofa: s/, or build.snapcraft.io// (they're the same thing).  maybe?  it'd need some thought; it would be complicated if it had to be selectable
<kyrofa> cjwatson, well, the builders expose a lot more capability-- different archs, etc
<kyrofa> cjwatson, curious to see if anyone is using it for v1
<kyrofa> (anyone using them today is either using v1 or expecting it to be v2 and giving up)
<cjwatson> kyrofa: right, but BSI is strictly more limited, it doesn't have its own special build code or anything over and above what's on LP
<kyrofa> cjwatson, right, which is why I specified them both
<cjwatson> kyrofa: actually BSI would be out of scope here anyway since it's xenial-only
<kyrofa> Ah
<zyga-ubuntu> niemeyer: yes, not sure why I said "kernels" :)
<cjwatson> kyrofa: we do have the notion of permitted combinations of Ubuntu series and snappy series in LP
<niemeyer> zyga-ubuntu: We should be able to do without actual coordination between the backends.. the interface itself is the one that has needs across both, and should be able to inform both of what it needs
<cjwatson> kyrofa: right now, the snappy series (e.g. 16) isn't passed through to the builder, but it could be
<cjwatson> kyrofa: that's probably how we'd do that kind of thing if we needed to
<zyga-ubuntu> niemeyer: yes, I was thinking we just need to supply the backends with the same information so that they can come up with the same decision in the end
<cjwatson> kyrofa: (I don't suppose I could persuade somebody from the snapcraft side to have a go at contributing the necessary changes?  more than happy to help with mentoring, but it seems that it'd be good for more people on the snapcraft side to know how the moving parts work)
<kyrofa> cjwatson, actually yeah, that doesn't sound like a bad idea
<cjwatson> it would involve carefully-sequenced changes to both launchpad-buildd and LP itself, but apart from that it's pretty isolated
<cjwatson> actually maybe not much sequencing
<cjwatson> basically just a matter of adding the snap's store_series name to the build args in SnapBuildBehaviour, passing that through to the backend script in launchpad-buildd's SnapBuildManager, and adding the necessary conditional behaviour to launchpad-buildd's BuildSnap.install.  As long as launchpad-buildd tolerates the key being missing from the build args, there's no sequencing involved
<cjwatson> and then we could add the trusty/16 combination to SnappyDistroSeries via an API POST request once we've verified that it works
<kyrofa> cjwatson, good deal, once a few of our PRs make it into a release, I'll look into that
<kyrofa> (right now the snap doesn't run)
<cjwatson> cool - let me know
<cjwatson> I expect we'll want the builders to know the snappy series eventually for other reasons too
<zyga-ubuntu> man
<zyga-ubuntu> I wish to thank everyone for introducing the automatic and smart "night mode"
<zyga-ubuntu> with almost no direct sun nowadays, it's always "dark and gloomy"
<zyga-ubuntu> but at least my eyes hurt less
<Chipaca> zyga-ubuntu: the redshift developers disagree :-)
<zyga-ubuntu> Chipaca: the coverflow developers you say? ;-)
<Chipaca> zyga-ubuntu: (because gnome wrote their own and made them redundant)
<cachio> mvo, I am taking a look to the snap-confine issue that seems to be failing on autopkgtest:ubuntu-*
<zyga-ubuntu> Chipaca: all software falls into the back hole of "built-in feature"
<zyga-ubuntu> cachio: hmm, which issue is that?
<cachio> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-image/zesty/amd64/s/snapd/20171023_140008_52dda@/log.gz
<zyga-ubuntu> aha that one
<zyga-ubuntu> I suspect it's a very very slow VM
<zyga-ubuntu> unless you can reproduce it
<cachio> something related to module:nvidia_modeset
<zyga-ubuntu> cachio: does it only fail in that place?
<zyga-ubuntu> cachio: that error is a very indirect way of saying "3 seconds elapsed but we took longer to finish stuff"
<zyga-ubuntu> cachio: did you see it in any interactive work?
<mup> PR snapd#4067 closed: packaging,spread: fix and re-enable opensuse builds <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4067>
<zyga-ubuntu> hmm
<zyga-ubuntu> but something is indeed fishy
<kyrofa> cjwatson, agreed, that seems generally useful
<zyga-ubuntu> lots of tests are failing on this
<zyga-ubuntu> mvo: maybe we should increase that timeout to 6 seconds
<cachio> zyga-ubuntu, sorry, I was having lunch
<cachio> zyga-ubuntu, well, that could be a reason, I'll try to reproduce it on a vm here
<niemeyer> cachio: Reviewed both PRs there
<cachio> niemeyer, tx
<ogra_> niemeyer, hrm ... when we switched to the forum were all the old mailing lists archives simply wiped ?
<niemeyer> ogra_: I don't think anything happened to the ML other than blocking subscriptions and postings.
<ogra_> well, it seems gone from lists.ubuntu.com
<ogra_> anyway, no biggie (the stuff i searched for is in my local archives)
<ogra_> https://lists.ubuntu.com/mailman/listinfo/snappy-devel ... should (theoretically) get me to the archives ... though
<cachio> niemeyer, please tell me if the doc that I added in the PR help to understand the change
<niemeyer> cachio: Thanks, looking
<ogra_> cachio, sorry that you have to suffer from my shell-like pyton stuff :)
<cachio> ogra_, np :)
<ogra_> (even though sergiusens claims that my python looks like perl ... :P )
<kyrofa> ogra_, hahaha
<niemeyer> cachio: Replied
<niemeyer> ogra_: Are you looking for this: https://lists.ubuntu.com/mailman/listinfo/snapcraft
<sergiusens> ogra_ perl 6 even
<ogra_> niemeyer, oooh, it was originally snappy-devel and got renamed ... (i simply clicked the link at the bottom of an old list mail in my mail app) ... yeah, thats it
<ogra_> thanks !
<niemeyer> ogra_: That's the actual mailing list we used before the move to the forum
<ogra_> yeah
<niemeyer> ogra_: It got renamed 20 years ago.. shortly after Linus came up with the  Linux kernel
<ogra_> hahaha
<kyrofa> ogra_, I need to see an example then. I can't imagine python that looks like an AES-encrypted message
<sergiusens> cjwatson kyrofa we would want to take advantage of base declarations in snapcraft.yaml when they come, those would be mapped to builder instances and if we really really want to support building on trusty, I would try to get a trusty base going too
<ogra_> kyrofa, well, i hate curly brackets ... so it wont be perl ever again :)
<kyrofa> sergiusens, that's a great point, I wonder how hard it would be
<sergiusens> kyrofa we wrote it down on a forum post already, somewhere at some point in time ;-)
<kyrofa> sergiusens, haha, good luck finding it
<ogra_> sudo snap install forum-crawler ...
<ogra_> :P
<kyrofa> $ snap find forum-crawler
<kyrofa> The search "forum-crawler" returned 0 snaps
<kyrofa> ogra_, you got my hopes up
<ogra_> haha
<ogra_> sorry
<niemeyer> kyrofa: I find the forum search surprisingly effective actually
<kyrofa> niemeyer, I've had pretty poor experiences with it, but I could also blame that on human error
<ogra_> which human exactly though ?
<kyrofa> Yes I will leave that nebulous
<ogra_> :)
<ogra_> only 4 billion choices...
<cachio> niemeyer, answers in the forum, now I have a kinesiology appointment but when I am back I'll finish the refactor for the python code.
 * Pharaoh_Atem groans in tiredness
<kyrofa> snappy-m-o, autopkgtest 1583 xenial:amd64 xenial:armhf artful:amd64
<snappy-m-o> kyrofa: I've just triggered your test.
<niemeyer> zyga-ubuntu: ping
<niemeyer> jdstrand: ping.. maybe you might know the answer
<zyga-ubuntu> niemeyer: yes?
<zyga-ubuntu> (not here full time anymore)
<niemeyer> zyga-ubuntu: Oh, hay
<zyga-ubuntu> how can I help? :)
<niemeyer> zyga-ubuntu: Sorry, I realize it's a bit late
<zyga-ubuntu> that's ok, I'm trying to solve a problem and I came to give it another try
<niemeyer> zyga-ubuntu: I'm about to merge #3958, and was wondering about the fact we have something about encryption file systems related to that apparmor/snap-confine, according to docs in the template of snap-confine
<mup> PR #3958: many: add support for /home on NFS <Created by zyga> <https://github.com/snapcore/snapd/pull/3958>
<niemeyer> zyga-ubuntu: But I cannot see any code related to this
<niemeyer> zyga-ubuntu: My only concern right now is not breaking something else because e.g. we remove some other file (think * glob + EnsureDir)
<zyga-ubuntu> niemeyer: right, thank you for checking
<zyga-ubuntu> niemeyer: right now we don't have any generated include files for encrypted files systems but indeed this feature was planned so that we could add one next to NFS
<niemeyer> zyga-ubuntu: Aha, ok.. that makes sense
<zyga-ubuntu> niemeyer: some of those, similar to NFS, leak through the abstractions apparmor gives us
<niemeyer> zyga-ubuntu: Merging then, thanks
<zyga-ubuntu> niemeyer: we have some workarounds but AFAIK what doesn't work very well is "snap try" on top of one
<zyga-ubuntu> thank you!
<niemeyer> zyga-ubuntu: Do you have anything on top of this, or can I squash?
<zyga-ubuntu> niemeyer: no, nothing on top
<zyga-ubuntu> feel free to squash/not squash :)
<niemeyer> Ok, here we go
<zyga-ubuntu> woot, thank you
<zyga-ubuntu> I'm sure CE will like that aspect of 2.29 :)
<mup> PR snapd#3958 closed: many: add support for /home on NFS <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3958>
<pstolowski> niemeyer, hey, can you take a look at my 2 interfaces-related PRs before your vacation?
<niemeyer> pstolowski: Yeah, will do, thanks for the ping
<pstolowski> cool
<zyga-ubuntu> woot
<mup> PR snapd#4070 opened: hooks/configure: queue service restarts <Created by stolowski> <https://github.com/snapcore/snapd/pull/4070>
<pstolowski> niemeyer, ^ I decided to simplify the approach with the above (compared to what I was trying to explain in the standup)
<pstolowski> niemeyer, happy to discuss/explain if needed
<niemeyer> pstolowski: Sounds good, thanks!
<niemeyer> pstolowski: Reviewing now
<zyga-ubuntu> niemeyer: woot, no need to sync anything, I got one thing wrong; apparmor needs the original path :)
<zyga-ubuntu> niemeyer: and de-clashing of plugins should now be oK
<zyga-ubuntu> pushed and EODing
<zyga-ubuntu> well,
<zyga-ubuntu> one more small patch
<zyga-ubuntu> then EOD
<niemeyer> zyga-ubuntu: Which original path?
<zyga-ubuntu> niemeyer: let me show you an example
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/4068/files#diff-7d64932a9164eaac515f310a2759e820R506
<mup> PR #4068: interfaces/builtin: add support for content "source" section <Created by zyga> <https://github.com/snapcore/snapd/pull/4068>
<zyga-ubuntu> here, this is exactly what I was trying to solve
<zyga-ubuntu> one app, two plugins (via content)
<zyga-ubuntu> in the mount entry they are renamed to unclash
<skjensen> Evening guys, sorry to interrupt but got a bit of a weird error when trying to build my image.. The error is: panic: runtime error: slice bounds out of range
<zyga-ubuntu> in the apparmor profile they are not renamed because apparmor needs a rule for the source (which is the original path) because of AF_UNIX shortcomings
<zyga-ubuntu> and I just saw a typo :)
<skjensen> Full error description can be found here: https://pastebin.com/5aUPQXcB
<zyga-ubuntu> there
<zyga-ubuntu> (I wrote "indented" instead of "intended")
<zyga-ubuntu> jdstrand: I think 4068 is also interesting for you, in the same vein as other PRs lately
 * zyga-ubuntu EOds
<cachio> niemeyer, I got disconnected, did you see what I wrote?
<kyrofa> elopio, ever seen this? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-snappy-dev-snapcraft-daily/artful/amd64/s/snapcraft/20171023_200736_fda75@/log.gz
<kyrofa> Ruby failures on artful autopkgtests
<elopio1> segmentation fault :S kyrofa: that's new to me.
#snappy 2017-10-24
<mup> PR snapcraft#1480 closed: beta <Created by snappy-m-o> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1480>
<mup> PR snapcraft#1497 closed: ci: release snap to a branch for every PR <Created by sergiusens> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1497>
<mup> Bug #1687079 changed: cannot change profile for the next exec call: No such file or directory <Snappy:Expired> <https://launchpad.net/bugs/1687079>
<mup> PR snapd#4071 opened: release: merge 2.29~rc1 changelog <Created by mvo5> <https://github.com/snapcore/snapd/pull/4071>
<mvo> ogra_: thanks for your suggestion from yesterday, with -^ the changelogs in edge should be sensible again
<kira> Hello need to install ubuntu core 16 on dell edge gateway
<Guest79466> http://www.dell.com/support/manuals/in/en/indhs1/dell-edge-gateway-5000/dell-edge-gateway-5000_users_guide/factory-os-recovery-image?guid=guid-0506c333-601f-413c-bc47-90bc656d27eb&lang=en-us
<Guest79466> Using the below link which suggest  15.04
<Guest79466> http://www.dell.com/support/manuals/in/en/indhs1/dell-edge-gateway-5000/dell-edge-gateway-5000_users_guide/flashing-new-ubuntu-os-image?guid=guid-e9835159-7baf-4a32-9b2a-a3fe1a027224&lang=en-us
<Guest79466> Hello need to install ubuntu core 16 on dell edge gateway
<elopio1> snappy-m-o autopkgtest 1630 xenial:amd64:integration
<snappy-m-o> elopio1: I've just triggered your test.
<mup> PR snapd#4072 opened: daemon: use newChange() in changeAliases for consistency <Created by mvo5> <https://github.com/snapcore/snapd/pull/4072>
<kalikiana> o/
<Chipaca> core 16-2.28.5+ppa9 3304 canonical core
<Chipaca> HMMMM
<mwhudson> mvo: thanks for the golang fixery, sorry for being slack
<Chipaca> mvo: is this a new 'make edge version better'?
<Chipaca> mwhudson: hey
<mwhudson> Chipaca: hello
<zyga-ubuntu> mvo: hey, I assume you know about listing/main, is the version change intended and we should change the test or should we put a new RC build with different version string?
<mvo> mwhudson: no worries
<Chipaca> mvo: i think zyga-ubuntu's quesiton and mine are the same
<mvo> mwhudson: you did the hard work by pointing me to the right fix :)
<mvo> Chipaca, zyga-ubuntu sorry, let me quickly rebuild hte core and see if that fixes things. there was a leftover package in the edge ppa which is fixed since
<zyga-ubuntu> aha, thanks! :)
<mvo> Chipaca, zyga-ubuntu please give it ~30min or so that is hopefully enough, if not we need to whitelist "~" in the listing version
<Chipaca> mvo: should we do that anyway? or is it good as a safety net?
<mvo> Chipaca: in this case it was a good safety net, it choked on the "+" in there, right?
<Chipaca> yes
<zyga-ubuntu> + MATCH '^core .* [0-9]{2}-[0-9.]+(~[a-z0-9]+)?(\+git[0-9]+\.[0-9a-f]+)? +[0-9]+ +canonical +core *$'
<zyga-ubuntu> core              16-2.28.5+ppa9  3301  canonical  core
<zyga-ubuntu> yep, looks like it
<mvo> yeah, I think that is ok, it should die on that, thats wrong content in our ppa
<Chipaca> âYour server, "finley", has been scheduled to be upgraded to the newest version of Ubuntu! You will receive an email notification when the process begins. Please see the Knowledge Base article below for any possible changes that may affect youâ
<Chipaca> wooo
<Chipaca> â¦ except it's upgrading to 14.04
<Chipaca> (from 12.04, so yay i guess?)
 * zyga-ubuntu works on overlayfs-free variant of layout 
 * ogra_ hugs zyga-ubuntu 
 * Chipaca -> physio
<Chipaca> zyga-ubuntu: is that because we can't go ahead with the overlayfs one? traversal issues?
<Chipaca> or is it a fallback?
<zyga-ubuntu> Chipaca: as a fallback
<Chipaca> cool
<Chipaca> ok
<zyga-ubuntu> Chipaca: I want to at least have a plan B that works
<zyga-ubuntu> Chipaca: overlay is much nicer and easier to work with but if we cannot do it (see the forum discussion) or it's unsafe, I need a fallback
<Chipaca> zyga-ubuntu: people on the dusty long tail say thank you
<zyga-ubuntu> fallback is also easy but undo is tricky
<zyga-ubuntu> Chipaca: that's what we're here for :)
<Chipaca> :-)
 * Chipaca -> really, physio
<zyga-ubuntu> mvo: do you know if spread-cron PR 49 python code is for python3 or python2?
<mup> PR #49: allow (optional) snappy update $pkgname <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/49>
<mvo> zyga-ubuntu: I don't know I would assume py3
<mvo> zyga-ubuntu: actually looking at this its probably pretty old
<mvo> zyga-ubuntu: so might be written for py2, but we can/could moderinize it
<zyga-ubuntu> aha
<zyga-ubuntu> mvo: yeah, I'm a bit of a junkie for statically typed python
<zyga-ubuntu> mvo: I could ... you know, ... improve it :)
<mup> PR snapd#4073 opened: snap: add io.snapcraft.Settings to proxy to xdg-settings <Created by mvo5> <https://github.com/snapcore/snapd/pull/4073>
<MuffinPimp[m]> I asked this in #ubuntu but I figure I'll ask in here too: Is there an easy way to install an Ubuntu Core image from PXE?
<zyga-ubuntu> MuffinPimp[m]: I don't think we support that yet but technically if you have a working image you can use any PXE bootable automated installer that will simply copy it and reboot
<zyga-ubuntu> MuffinPimp[m]: but note that the first-boot on ubuntu core is special and requires interaction
<zyga-ubuntu> MuffinPimp[m]: or special assertion that will complete the setup
<MuffinPimp[m]> Yeah I was thinking of something like that but I don't know of such a tool.
<MuffinPimp[m]> And yeah, I have access to a console so that wouldn't be a problem.
<mup> PR core#62 opened: create xdg-settings inside the core snap <Created by mvo5> <https://github.com/snapcore/core/pull/62>
<MuffinPimp[m]> I'm considering just caving and running Ubuntu Server instead since googling hasn't led me anywhere, but I figured I would ask first.
<Chipaca> MuffinPimp[m]: I forget how PXE worked, does it work to boot an image, or does it need something bootable with a size limit?
<Chipaca> last time i played with pxe was to boot some hppa box
<zyga-ubuntu> Chipaca: it's a pice of code that boots over LAN, then cna pull in (you are in control) other stuff
<Chipaca> i mean, you can boot iso images with pxe, so you should be able to boot a core image
<MuffinPimp[m]> Yeah, but I want to install it.
<zyga-ubuntu> I agree with Chipaca, it's possible and once someone glues all the bits together, should be a generic solution
<vadi> Hello - my snaps are broken, and reinstalling like answers suggest isn't helping: https://hastebin.com/aqewojiseh.sql
<vadi> What can I do?
<zyga-ubuntu> vadi: hello
<zyga-ubuntu> vadi: can you run "snap version" pleaes?
<zyga-ubuntu> *please
<Chipaca> MuffinPimp[m]: clonezilla?
<MuffinPimp[m]> Hrmm
<vadi> Sure, here is the output: https://hastebin.com/oxomogivil.rb
<Chipaca> MuffinPimp[m]: AIUI that lets you PXE boot and then image a local drive with a network image
<zyga-ubuntu> vadi: I see
<Chipaca> vadi: what's that kernel?
<zyga-ubuntu> vadi: you are running a mainline kernel,
<Chipaca> ah :-)
<zyga-ubuntu> vadi: your kernel has probably caused us not to load apparmor support code for snap-confine
<vadi> I have to use the mainline kernel because the Ubuntu kernel does not let me unlock the encryption on the laptop anymore
<MuffinPimp[m]> Chipaca: Lol I can't believe I didn't think of clonezilla before, thanks!
<zyga-ubuntu> vadi: unfortunately those kernels are not supported yet, I think 2.29 should be better in that regard but you need to wait for a nightly build in the edge channel
<Chipaca> vadi: what encryption is that? sounds like a regression we'd want to know about?
<Chipaca> we == ubuntu people, not just snapd
<vadi> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1724564, I can't type the password in for the crypt setup. Either nothing appears or my password starts getting printed top-left of the screen...
<mup> Bug #1724564: Cannot enter password to unlock encryption in 4.10 <apport-collected> <kernel-da-key> <zesty> <linux (Ubuntu):Confirmed> <https://launchpad.net/bugs/1724564>
<Chipaca> vadi: gah
<vadi> Luckily I had a mainline kernel installed for something else that still lets me use my work laptop
<Chipaca> vadi: try booting without the splash screen
<vadi> How can I do that?
<Chipaca> vadi: that is, change "splash" to "nosplash" in grub
<Chipaca> vadi: or, boot in rescue mode and then continue the normal boot
<vadi> I'll try the rescue and normal.
<vadi> It took my password but it got stuck on this: https://photos.app.goo.gl/5QcAeGxOKj3RwTzQ2
<skjensen> Hi guys, anyone who can help me with this? https://forum.snapcraft.io/t/issue-with-ubuntu-image-panic-runtime-error-slice-bounds-out-of-range/2571
<skjensen> Issue with ubuntu-image: panic: runtime error: slice bounds out of range
<Chipaca> niice
<Chipaca> vadi: it said your password was ok?
<zyga-ubuntu> skjensen: hey
<skjensen> Hey
<zyga-ubuntu> skjensen: hmmm, no idea
<vadi> Yeah, I think it took it in and it went further. At least it scrolled off the screen rather quick.
<Chipaca> skjensen: zyga-ubuntu: that's a bug, no matter what it is
<Chipaca> i'll look into it
<skjensen> Great thanks.. :) If you need any help to replicate or see the files I used please let me know.
<Chipaca> skjensen: to be clear: the bug is that instead of returning an error, it panics
<Chipaca> skjensen: the distinction probably doesn't make much difference to you unfortunately
<skjensen> Okay.. Hopefully the new error message will help me get my problem fixed..
<vadi> Gives you hope that it's not a blocker!
<skjensen> absolutely
<Chipaca> skjensen: the error is because it looks for two zero bytes in a boot file, and doesn't find it
<Chipaca> in the header
<skjensen> Chipaca: what does that mean?
<Chipaca> mvo: you remember ubootenv?
<Chipaca> skjensen: i'm not familiar with this bit of the code to give you the proper context, but mvo might remember (but it's lunchtime for him)
<Chipaca> skjensen: what i see in the code is that we get a 'payload': 	payload := contentWithHeader[headerSize:]
<Chipaca> skjensen: then we check the CRC on it, and that passes
<Chipaca> skjensen: then we look for two null bytes in the header, and that fails, but we don't check it before using it as an index
<Chipaca> and that panics
<Chipaca> "in the header" -> in the payload i mean
<Chipaca> *not* the header
<Chipaca> that is, we skip the header, d'oh :-)
<Chipaca> _which_ file it is, is what i hope mvo can tell me (because the panic doesn't)
<Chipaca> ogra_: is the uboot env file a binary file?
<ogra_> Chipaca, yes, it gets created by mkenvimage from the uboot tree, out of uboot.env.in
<ogra_> it has to have a fixed size and format
<pstolowski> guys, i'm not feeling well today, got flu or something, gonna call it a day
<pstolowski> o/
<Chipaca> ogra_: and it uses two null bytes as an EOF marker or something?
<skjensen> I'm using this device-tree: tegra124-apalis but no extra uboot.env.in file in my gadget.. Can that be the reason?
<ogra_> Chipaca, not sure, mvo played with hexedit on it ... but we have a fixed commend that needs to be used to create it, if you use that as required it will be the correct format
<ogra_> mkenvimage -r -s 131072 -o uboot.env uboot.env.in
<Chipaca> skjensen: if the file were missing you would've seen an explicit error about that
<ogra_> this is what you have to use (and what all our reference snapcraft.yaml's have)
<Chipaca> this is: the file exists, the payload CRC is alright, but it's missing an end-of-payload marker
<ogra_> skjensen, yes, thats definitely the reason
<ogra_> you need to have a uboot.env.in as input for mkenvimage
<Chipaca> I shall write a PR to make this a nice error instead of a panic
<skjensen> Okay thanks ogra_
<ogra_> skjensen, there needs to also be the uboot.conf link pointing to uboot.env in yur gadget source
<skjensen> But following your blog post about uboot I can't really figure out what to put into the uboot.env.in file?
<ogra_> ubuntu-image reads the link, it does not directly use uboot.env
<ogra_> skjensen, boot with the created uboot once (by manually setting up an SD as your board docs require) ... then run "printenv" in an attached serial terminal from the uboot commend prompt ...
<ogra_> copy/paste the output into a text file you call uboot.env.in ...
<ogra_> thats your base for it
<ogra_> then you add the snap and snappy vars to it
 * zyga-ubuntu -> Lunch
<skjensen> Thanks ogra_ I will give that a go... :)
<Chipaca> ogra_: missing the \0\0, would it be better to error out, or to consume the rest of the file?
<ogra_> Chipaca, well, it smells like the file is missing completely there ...
<Chipaca> yes, here yes
<Chipaca> bah
<Chipaca> it's not missing, otherwise it wouldn't've panic'ed
<Chipaca> it exists, has the right header, but is missing the eof marker
<Chipaca> end-of-payload marker
<Chipaca> which might actually just be "fill with nul bytes until the given size"
<Chipaca> i'll wait for mvo's advice, i think
<ogra_> so yes ... then it should print a proper error ... but we should also make sure that mkenvimage doesnt even create such a file if no uboot.env.in exists
<ogra_> i wonder why it didnt error during build for the gadget
<Chipaca> Â¯\_(ã)_/Â¯
 * Chipaca afk for a bit
<ogra_> ogra@styx:~$ mkenvimage -r -s 131072 -o uboot.foo uboot.foo.in
<ogra_> Can't open "uboot.foo.in": No such file or directory
<ogra_> hmm, it should definitely have errored without input file
<MuffinPimp[m]> Another couple of questions, how do I prevent Ubuntu Core from rebooting automatically? If I wanted to use ZFS would installing TH"classic"
<ogra_> (and even if the build moved on, the uboot.conf link would point nowhere, so i wonder how it got into that state)
<ogra_> MuffinPimp[m], you cant currently ... (prevent the reboot) ... and there is no ZFS suppport for core
<ogra_> well
<ogra_> ZFS for / that is
<ogra_> for attached removable devices it might perhaps work (depends on the kernel)
<MuffinPimp[m]> I CAN'T SEEM TO STOP TYPING IN CAPS, I REALLY NEED TO SEND THIS COMPUTER IN FOR REPAIRS SORRY
<MuffinPimp[m]> IT JUST STARTED HAPPENING, NOT AN UBUNTU ISSUE JUST A REALLY INCONVENIENT TIME
<ogra_> no worries, we'll all just plug our ears while you talk :P
<skjensen> I might have completely skipped the mkenvimage part of the process.. and that's why ubuntu-image is throwing a panic.. Just in case you want to look into improving the error messages..
<MuffinPimp[m]> YEAH, I KNOW I WAS THINKING FOR NON ROOT PARTITIONS
<MuffinPimp[m]> LET ME TRY RESTARTING :/
<ogra_> MuffinPimp[m], well, that then depends on the kernel (i'm not super familiar with ZFS, do you also need a userspace part ? thats probably missing as well)
<ogra_> ogra@dragonboard:~$ grep ZFS /snap/dragonboard-kernel/current/config-4.4.0-1078-snapdragon
<ogra_> ogra@dragonboard:~$
<ogra_> i definitely dont see it in an arm64 kernel of our supported set
<MuffinPimp[m]> That was annoying
<MuffinPimp[m]> Yeah, the userspace tools aren't installed so I'm thinking the best way to install them would be "classic mode" idk if that has any gotchas though.
<MuffinPimp[m]> that or just repackage the deb as a snap
<ogra_> classic mode cant run any daemons
<ogra_> it is really just for building stuff on the device
<ogra_> so if your userspace tools require any service or systemd units it cant work in classic
<MuffinPimp[m]> Hrm
<ogra_> i guess a snap would be best though it would likely have to be unconfined / devmode or some such, i doubt there is an interface that could provide such a deep system level access
<ogra_> (i could be wrong though)
<oSoMoN> mvo, can you advise on https://forum.snapcraft.io/t/call-for-testing-chromium-62-0-3202-62/2569/6 ? Looks like snapd is being overly strict
<mvo> oSoMoN: sure, let me check
<mvo> oSoMoN: meh, yeah, snapd got stricter and now you are bitten by this :/ let me check in more detail
<oSoMoN> mvo, I've fixed the incorrect entries in the desktop file and pushed a new revision out to the candidate channel, but the problem is that snapd refuses to upgrade from the revision currently installed because of the incorrect entries
<Chipaca> mvo: is that a change in 2.29?
<mup> PR snapd#4065 closed: servicestate: use taskset <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4065>
<ogra_> oSoMoN, it is funny that snapcraft didnt error the same way, afaik it checks all executables and binaries that get called from the apps section and from shipped .desktop files
<oSoMoN> ogra_, IÂ didn't check the snapcraft output, maybe it simply issues a warning instead of erroring out?
<ogra_> that might be ...
<cachio> ogra_, hey
<ogra_> hey
<ogra_> (morning ... i guess :) )
<cachio> ogra_, tx, good afternoon for you, I got disconnected, did you see what I wrote?
<ogra_> nope
<cachio>  yesterday I was diving in all the building infrastructure :)
<cachio> why the core snap is not automatically built by launchpad?
<ogra_> it is
<ogra_> lp-build-core is just the trigger script, see my last comments on the forum thread
<cachio> but it is possible to setup in launchpad to do what the python script is doing, right?
<ogra_> no
<ogra_> there is no cron support in LP itself
<ogra_> so you need something that "clicks" the request builds button
<ogra_> (and feeds the info requred by the form this button brings up)
<cachio> ogra_, ah, ok, so the reason is to be able to schedule the builds and not do it with any change in the repo, right?
<ogra_> (arches, archives and such)
<ogra_> the reason we use cron is because that was enough back when i implemented it ... but when this setup was designed it was designed with the ability in mind to be able to use other PPAs or other triggers
<ogra_> there are just none yet :)
<cachio> ogra_, I am trying to understand :)
<ogra_> (we were still running 15.04-snappy when i did the original implementation and had not even switched to github )
<ogra_> (so the setup was similar to how we roll isos ... simply once a day by cron ... )
<cachio> ogra_, could we on here https://code.launchpad.net/~snappy-dev/+snap/core/+edit to set "Automatically build when branch changes" and point it to the edge ppa?
<ogra_> cachio, the "branch" is not snapd but the build scripts ...
<ogra_> cachio, so yes, you could do that but that would only re-build when the build env changes, as i understand you want a rebuild when snapd changes though
<cachio> ogra_, but if in the "Source archive for automatic builds:" we add the snappy-edge ppa
<ogra_> cachio, so what i'd do is to create a "watcher" tool that monitors the edge PPA ... (which as i understand has been set up by elopio1 and federico to always build a new deb when the snapd tree changes)
<ogra_> and simply replace the cron part with that
<ogra_> *and* point to the edge PPA
<cachio> ogra_, but launchpad is offering to watch a ppa
<ogra_> as additional build source
<ogra_> ah
<ogra_> well, if thats possible, tnen do that
<ogra_> *then
<ogra_> i didnt know that ...
<ogra_> you need to make sure the PPA is also used alongside with the image PPA and xenial-updates though
<ogra_> not sure how you can do that without using lp-lib ... since there is no such feature in the snap form of LP
<cachio> ogra_, I would use this ppa https://code.launchpad.net/~snappy-dev/+archive/ubuntu/edge
<ogra_> yes
<niemeyer> ackk: Reviewed #3916 again
<mup> PR #3916: snap,wrappers: add support for socket activation <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916>
<niemeyer> ackk: A few more notes, probably the last ones
<ackk> niemeyer, thanks!
<niemeyer> ackk: If you can go through these quickly, I'm happy to re-review before I'm off
 * ackk takes a look
<cachio> ogra_, I sent you an email with the configuration that we could try
<ogra_> cachio, what i dont see is how you define a PPA as trigger on https://code.launchpad.net/~snappy-dev/+snap/core or on https://code.launchpad.net/~snappy-dev/+snap/core/+request-builds
<ogra_> and there is no way to set up two PPAs as build source on the second page
<ogra_> this is why i use that lp-build-core script, because lp-lib is the only way to do this
<ogra_> (or has been, if there are other ways then i simply dont know about them)
<cachio> ogra_, you mean, to trigger when there is a change in the core project itself?
<ogra_> cachio, ah, i see what you mean .. you should read the text under "Automatically build when branch changes"
<cachio> ogra_, yes
<ogra_> that does not refer to the PPA, it refers only to the git branch
<ogra_> and the git branch is not snapd but https://github.com/snapcore/core (which contains the whole build env)
<ogra_> so it would only auto-build if the build tools change, not if snapd changes
<cachio> ogra_, ah, ok, and we don't have snapcraft.yaml in the edge ppa
<ogra_> a PPA is a package archive for debs
<ogra_> no, there is no snapcraft.yaml in the PPA
<cachio> f
<cachio> ogra_, I know, but I would use it just as the trigger
<ogra_> cachio, what we have (what federico and elopio1 did set up once) is an auto-build of the snapd deb in the edge PPA ... the core build scripts use debs to create the core snap ... so what you actually want to watch is when the snapd deb in the edge PPA is getting refreshed ...
<ogra_> then you want to trigger a new build of core and actually use that deb (by adding the additional edge PPA to the snap build)
<ogra_> right
<ogra_> you can use it as trigger but you cant do that without some lp-lib coding
<ogra_> there is no way to use a PPA as trigger for a snap build automatically
<cachio> ogra_, agree
<ogra_> the way i described in my last forum post on that topic should work with the existing setup ... which doesnt mean there isnt perhaps a better way i dont know about though
<cachio> ogra_, I already updated the python code
<ogra_> good
<mup> PR snapd#4074 opened: partition/ubootenv: don't panic when uboot.env is missing the eof marker <Created by chipaca> <https://github.com/snapcore/snapd/pull/4074>
<ogra_> cachio, the trickiest part here is to hide the credentials from the rest of the world ... since they give 100% access to all team stuff, which is why i'd recommend to do it all from your home people.canonical.com or from some other machine in the datacenter that outsiders can not browse
<ogra_> (people.c.c is the easiest though ... )
<cachio> ogra_, well, so far I just have access to that machine
<cachio> ogra_, I just have the certs needed
<cachio> ogra_, the launchpad credentials saved are just for that machine, right?
<ogra_> i think so
<ogra_> yeah, looking at the credentials file in my home on lillipilly i see:
<ogra_> consumer_key = System-wide: Ubuntu (lillypilly)
<ogra_> as the first line
<ogra_> so it creates a system token when you run it for the first time
<cachio> ogra_, yes
<cachio> ogra_, and in launchpad you can define how to use it, just once, until you disable it, etc
<ogra_> yeah
<ogra_> you dont want the access_secret public from that file though
<ogra_> (not sure if thats any valuable without the token but i wouldnt want to try it either :) )
<ogra_> cachio, oh, and note that lillipilly is a 12.04 machine ... the default python is 2 ...  (i just noticed zyga-ubuntu's complaint on your PR for lp-build-core)
<mvo> oSoMoN: I put it on my list to investigate today
 * kalikiana going for lunch
<ackk> niemeyer, so, to confirm, we only want to accept $SNAP_DATA and $SNAP_COMMON as path prefixes for listen-stream, no absolute paths
<oSoMoN> mvo, thanks!
<mvo> Chipaca: will you mention your PR in https://forum.snapcraft.io/t/issue-with-ubuntu-image-panic-runtime-error-slice-bounds-out-of-range/2571 ?
<Chipaca> mvo: done
<ackk> niemeyer, addressed all your comments, but I have a question on the last one (on the PR)
<JonelethIrenicus> how can i add to a path variable of a snappy package I have installed
<Chipaca> JonelethIrenicus: what do you mean?
<JonelethIrenicus> $PATH
<JonelethIrenicus> i want to add a directory to the path
<mup> PR snapd#4066 closed: overlord/snapstate: support completion for command aliases <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4066>
<Chipaca> JonelethIrenicus: what for?
<JonelethIrenicus> Chipaca: because I want to
<Chipaca> JonelethIrenicus: is this a regular binary app in the snap, or a service?
<JonelethIrenicus> its pycharm
<ogra_> http://markshuttleworth.com/archives/1518
 * ogra_ hugs sabdfl 
<ogra_> thanks for giving the child a name :)
<kalikiana> woot. bionic beaver is a name I did not expect. I love it :-D
<niemeyer> ackk: Shoot
<niemeyer> mvo: Updated the core opts doc to include the proxy.* options
<ackk> niemeyer, see my last comment on the PR
<ackk> niemeyer, I'm not sure what you're referring to wrt systemd creating paths
<mvo> niemeyer: thank you
<niemeyer> ackk: I see, it's fine to keep the MkdirAll
<zyga-ubuntu> jdstrand: hey
<niemeyer> ackk: I don't quite recall whether we remap into /etc or whether we're using /etc/systemd elsewhere in core devices
<ackk> niemeyer, I think I had it there because the older implamentation had it
<ackk> niemeyer, but as said, /etc/systemd/system should always be there
<niemeyer> ackk: Yeah, and that might be the reason.. it's fine to keep it
<niemeyer> ackk: Thanks for the changes.. I'll re-review after lunch
<jdstrand> zyga-ubuntu: hey. actively looking at 4008
<niemeyer> mvo: np!
<ackk> niemeyer, ok, then the branch should be good
<ackk> niemeyer, ty for looking at it
<zyga-ubuntu> jdstrand: not sure how your commitments look like
<zyga-ubuntu> jdstrand: aha, thank you! :)
<zyga-ubuntu> jdstrand: then I'll get out of your way :)
<cachio> mvo, about the user assertion, any update on that?
<mvo> cachio: meh, not yet
<mvo> sorry
<cachio> mvo, can I help?
<mvo> cachio: yes, you could create it via a json input file or by looking how we do those nowdays in the other tests. but I need to dig into that myself a bit to be more helpful :/
<mvo> oSoMoN: if chromium has access to xdg-settings, will that be used to make itself the default browser?
<pedronis> davidcalle: I see people still referring to https://insights.ubuntu.com/2017/01/28/ubuntu-core-how-to-enable-aliases-for-your-snaps-commands/ , it probably needs updating to reflect the changes happened to how aliases work
<gokr> Anyone used the content interface?
<zyga-ubuntu> gokr: hey, what do you need?
<gokr> I have been battling this but... I think I now may know what the problem is.
<gokr> We are making a proof of concept - with one snap being a kind of web server, that serves other snaps. And those others are exposed via content interface.
<gokr> Unfortunately... I am not sure its a viable approach - since... I don't know if they will autoconnect unless both are from the same publisher. And... that feels like a restriction in this case.
<davidcalle> pedronis: hmm, thanks, you are right
<gokr> zyga-ubuntu: I make the connection, but I am having a hard time knowing where the content is supposed to be mounted.
<gokr> It would be nice if I somehow could use some snap command or something that shows the actual mounts.
<kyrofa> elopio1, the ruby autopkgtest doesn't seem to work on armhf either
<sborovkov> Hi. Can someone point me to some documentation on launchpad build farm for snaps?
<gokr> Woa, it worked. So... ok, the mount point must exist.
<ogra_> sborovkov, hmm, i dont think there is much actual documentation, if you have a branch in LP you get a "create snap package" button, that takes you a form which is pretty self explaining ... not sure if cjwatson can point to something more detailed
<sborovkov> Ok understood
<kyrofa> sborovkov, ogra_ this is still mostly up-to-date: https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way
<ogra_> ah, perfect !
<sborovkov> thanks
<kyrofa> Some of the UI has changed since I took the screenshots, but it'll get you there
<ogra_> yeah, it is really self explaining after all ...
<zyga-ubuntu> gokr: re
<ogra_> (i personally found it harder to set up the git tree import from GH to LP than to create the snap package from it afterwards)
<pedronis> davidcalle: yes, IÂ had this in mind and forgot a couple of times to ping you, let me know if I can help somehow
<zyga-ubuntu> gokr: yes, that's a limitation in 2.28.5, in 2.29 or 2.30 the target won't have to exist
<pedronis> davidcalle: thanks
<zyga-ubuntu> gokr: you can see the actual mounts using a little trick but I agree it's not easy to find
<gokr> zyga-ubuntu: Ok, followup question. I want to mount into $SNAP_DATA/apps - but... oh? Hmmm, what version do I have...
<zyga-ubuntu> gokr: you can run "sudo nsenter -m/run/snapd/ns/nameofthesnap.mnt"
<gokr> 2.28.5, right
<zyga-ubuntu> gokr: then you can run mount or look at /proc/self/mountinfo
<gokr> great, thanks.
<zyga-ubuntu> gokr: in 2.29.2 (perhaps) or 2.03 you will have the benefit of this pull request:
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/4008
<mup> PR #4008: cmd/snap-update-ns: create missing mount points automatically <Created by zyga> <https://github.com/snapcore/snapd/pull/4008>
<zyga-ubuntu> gokr: you can look at the tests to get an idea, look here: https://github.com/snapcore/snapd/pull/4008/files#diff-3112a3d1998c61825cfbcd270e9ecf15
<zyga-ubuntu> gokr: as you can see there's a pair of snaps, for plugs and for slots
<zyga-ubuntu> gokr: and they share data and code by using the content interface
<zyga-ubuntu> gokr: (actually, I spoke too soon, code is shared in a follow-up PR)
<zyga-ubuntu> gokr: look at what is being done
<zyga-ubuntu> gokr: I'll gladly answer questions or take your suggestions
<cjwatson> ogra_: *cough* been meaning to write something up on help.launchpad.net for about two years now
<ogra_> cjwatson, just link to kyrofa's blog ;)
<cjwatson> blogs aren't docs :)
<kyrofa> cjwatson, happy to clean up what I've got there if you want some help with that
<mup> PR snapd#4075 opened: many: reorg things in preparation to make handling of the base url in store dynamic  <Created by pedronis> <https://github.com/snapcore/snapd/pull/4075>
<cjwatson> if you aren't already in ~launchpad-doc I would not object if you emailed me a chunk of wiki markup to drop somewhere :)
<kyrofa> I'm not in launchpad-doc, but I will apply
<kyrofa> Done
<gokr> zyga-ubuntu: So... either I make an install hook (evidently) to create the $SNAP_DATA/apps dir (but still not sure that's done before the content connections are made?) - or I get a newer snap. How do I get a newer snap?
<zyga-ubuntu> gokr: no, you cannot use an install hook
<gokr> ok
<zyga-ubuntu> gokr: install hook runs in the execution environment for the snap
<zyga-ubuntu> gokr: and that already has the mount namespace prepared
<gokr> right, as I suspected
<zyga-ubuntu> gokr: long story short, you need to wait for 2.29.2 or 2.30 and then it will not be a problem anymore
<oSoMoN> mvo, re xdg-settings, yes: https://cs.chromium.org/chromium/src/chrome/browser/shell_integration_linux.cc?type=cs&sq=package:chromium&l=86
<gokr> So currently I can only mount to $SNAP_DATA/ ?
<zyga-ubuntu> gokr: yes, I'm afraid so :/
<gokr> Or to $SNAP/whatever - if readonly?
<zyga-ubuntu> yes
<zyga-ubuntu> but $SNAP/whatever must be in the snap already (it must be an empty directory)
<gokr> Right, but that may be doable.
<gokr> ok, cool
<zyga-ubuntu> well, those things are getting improvements
<zyga-ubuntu> gokr: please look at this thread, where we discuss how to improve the content interface
<cachio> mvo, is it any reason why we sync github and snapd-vendor in launchapd for any green in master?
<zyga-ubuntu> https://forum.snapcraft.io/t/improvements-in-the-content-interface/2387
 * kalikiana waves at kyrofa 
<cachio> mvo, we could do it nightly based on the last green on master too
<kyrofa> Good afternoon kalikiana
<kalikiana> kyrofa: Can you merge snapcraft#1627 ?
<mup> PR snapcraft#1627: lxd: split container classes into different files <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1627>
<gokr> zyga-ubuntu: So... I am presenting tomorrow around this idea - and hopefully with a small demo. It would be nice to verify it with you.
<mvo> cachio_lunch: we are mostly doing it because this way we get quicker test cycles. we could do it nightly only too
<kyrofa> kalikiana, looks like it's out of date
<kalikiana> huh?
<kyrofa> kalikiana, it's behind master. Sometimes that's okay, but since the PR is not small, I'd like to run tests against an updated branch
<kyrofa> So I just updated it
<kyrofa> If it's still green, I'll merge it
<kalikiana> Oh. D'uh :-D Sounds sensible
<kalikiana> Thanks
 * ogra_ sees the most recent forum post and thinks someone runs in circles ... 
<ikey> the dollahz one?
<ikey> oh christ
<ikey> if people could get over recreating the android success story that'd be swell
<zyga-ubuntu> ogra_: ?
<zyga-ubuntu> oh
<zyga-ubuntu> I see
<ogra_> yeah,, Chipaca bit the bullet already
<Chipaca> Â¯\_(ã)_/Â¯
<zyga-ubuntu> Chipaca: thank you: )
<zyga-ubuntu> I'm off to my parents, but I'm working on snapd on the way :)
<zyga-ubuntu> ttyl
<zyga-ubuntu> man, I wish irssi knew my network status and could do the right thing
<zyga-ubuntu> I'm so lazy not to script it
<zyga-ubuntu> anyway, ttyl
<kyrofa> Chipaca, you're our hero
 * Chipaca actually LOLs
 * zyga-ubuntu got a USB thumb drive that is 67GB big
<Pharaoh_Atem> hey ikey
<zyga-ubuntu> should I trust that?
<zyga-ubuntu> looks very ... odd
<ikey> Pharaoh_Atem, rawr
<Chipaca> niemeyer: augh. joining those threads makes things worse imho :-(
 * Chipaca gives up and takes a break
<niemeyer> Chipaca: I've literally answered that very question already
<niemeyer> Chipaca: IN that topic
 * kalikiana waves at Pharaoh_Atem 
 * Pharaoh_Atem waves back at kalikiana
<niemeyer> Chipaca: It sounds worse to have N topics repeating the same questions and then copy & paste responses
<ogra_> niemeyer, it feels like you answered that question at least 20 times ...
<ogra_> (just that it was differently phrased each time)
<zyga-ubuntu> maybe it's one of those questions that need to be a video
<ogra_> lol
<zyga-ubuntu> wait, I found one
<ogra_> well, helloween isnt far out ... could be a funny video ... :)
<zyga-ubuntu> https://www.youtube.com/watch?v=WWaLxFIVX1s
 * zyga-ubuntu gets back to writing tests
<ogra_> yeah, that fits
<kyrofa> snappy-m-o, autopkgtests 1583 xenial:amd64
<snappy-m-o> Command "," / ", autopkgtests" not found.
<snappy-m-o>  Did you mean "/snappy-m-o autopkgtest" ?
<kyrofa> snappy-m-o, autopkgtest 1583 xenial:amd64
<snappy-m-o> kyrofa: I've just triggered your test.
<ikey> https://media.giphy.com/media/vk7VesvyZEwuI/giphy.gif
<kyrofa> snappy-m-o, I only ever use you for one thing. You should know what I want
<snappy-m-o> Command "," / ", I" not found.
<kyrofa> ikey, :P
<ogra_> ikey, lol
<ikey> ^_^
<zyga-ubuntu> jamesh: hey
<zyga-ubuntu> jamesh: it's a bit early but maybe you're around now
<zyga-ubuntu> Chipaca: o/
<Chipaca> zyga-ubuntu: \o
<pedronis> Chipaca: are you off tomorrow?Â or only Thu?
<Chipaca> pedronis: thu an' fri
<Chipaca> why?
<Chipaca> i can also take tomorrow off if you want :-D
<pedronis> Chipaca: IÂ need a review :)
<pedronis> that's why
<Chipaca> :-)
<Chipaca> pedronis: i'll be here tomorrow
<pedronis> ok, thank you
<Chipaca> i'll make sure i mark the pr as 'changes requested' over some typo in a comment, just before i EOW
<pedronis> I should also try to do some reviews tomorrow, it seems our queue is growing again
<Chipaca> ogra_: http://www.webtender.com/db/drink/4197
<Chipaca> dunno why it's for you, but it's clearly for you
<ogra_> cheers !
 * kalikiana going to find something for dinner
<cachio> mvo, sorry, which tests are triggered when we sync with snapd-vendor?
<elopio1> kyrofa: are you going to join the new ubuntu on air thing? https://community.ubuntu.com/t/ubuntu-hour-friday-october-27th/1019 :D
<kyrofa> elopio1, I saw the post but hadn't read it yet, let me do so
<cachio> mvo, If we sync once a day, we will almost make sure the core we have in snapd-vendor repo is the code used to build the core snap
<cachio> So, I can detect a new core snap in edge and run the tests using snapd-vendor and it should work
<cachio> mvo, is it ok if I propose a PR with that change?
<cachio> then the commits information won't be longer needed
<kyrofa> elopio1, I'll be there!
<kyrofa> snappy-m-o, autopkgtest 1636 xenial:amd64
<snappy-m-o> kyrofa: I've just triggered your test.
<elopio1> kyrofa: great! Please reply on the topic, to start moving it and so I know who to send the link on friday.
<elopio1> what about you zyga-ubuntu ? We have a new testing-day like show ^
<zyga-ubuntu> re
<zyga-ubuntu> Chipaca: sorry for bothering you at this time
<zyga-ubuntu> Chipaca: are you still working, can I trick you into a tiny review? (really small)
<pedronis> mvo: niemeyer:Â IÂ just remembered we also need to do something about firstboot and core config, atm we apply optionally default config for core from the gadget  at first boot but that depends on configstate and the configure hook
<pedronis> mvo:Â it suggests, one option would be to hook/redirect just below/behind configstate.Configure
<zyga-ubuntu> anyway
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/4068 if anyone wants
<mup> PR #4068: interfaces/builtin: add support for content "source" section <Created by zyga> <https://github.com/snapcore/snapd/pull/4068>
<zyga-ubuntu> jdstrand: thank you for the review
<zyga-ubuntu> jdstrand: I'm making comments and I'll tweak the comments in the code shortly
<zyga-ubuntu> jdstrand: I'm eating supper but if you can re-review this after ~45 min it should be all ready
<cachio> zyga-ubuntu, if you have 2 minutes could you please take a look to PR
<cachio> 4064
<cachio> just to confirm if it is an issue or not
<kalikiana> kyrofa: snapcraft#1627 seems to be green
<mup> PR snapcraft#1627: lxd: split container classes into different files <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1627>
<kyrofa> kalikiana, done
<kalikiana> woot
<zyga-ubuntu> looking
<kalikiana> kyrofa: Thank you so much, sir!
<mup> PR snapcraft#1627 closed: lxd: split container classes into different files <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1627>
<zyga-ubuntu> cachio: ah, I bet you that the interface actually relies on apparmor alone and thus won't have any effect on fedora, debian and likely, opensuse
<zyga-ubuntu> cachio: check for partial confinement in the test and then skip that other half of the test that would fail if it were disconnected
<cachio> zyga-ubuntu, ok, but in debian the files don0t exist, so I suppose it is not supported by the kernel
<cachio> zyga-ubuntu, is it true?
<kyrofa> snappy-m-o, autopkgtest 1636 xenial:amd64
<snappy-m-o> kyrofa: I've just triggered your test.
<cachio> zyga-ubuntu, in debian it is failing when we execute the snap
<zyga-ubuntu> cachio: interesting, I wasn't aware of that
<zyga-ubuntu> cachio: I'll check and get back to you but that will be tomorrow
<cachio> zyga-ubuntu, sure
<jdstrand> zyga-ubuntu: I'm going to go for a walk and when I come back, I'll take a look at the PR again
<zyga-ubuntu> jdstrand: done :)
<zyga-ubuntu> jdstrand: thank you :)
<zyga-ubuntu> jdstrand: assuming tests are happy this will be a major improvement to content interface
<zyga-ubuntu> enjoy your walk :)
<kyrofa> snappy-m-o, autopkgtest 1583 xenial:amd64
<snappy-m-o> kyrofa: I've just triggered your test.
#snappy 2017-10-25
<zyga-solus> good morning
<zyga-solus> mwhudson: I'll look into packaging this week
<zyga-solus> mwhudson: sorry for not having any time for that lately
<zyga-solus> good morning mvo :)
<zyga-solus> mvo: I got a +1 from jdstrand on 4008, could you please do 2nd review?
<zyga-solus> mvo: that branch is on the critical path towards layouts
<zyga-solus> mvo: and I'd love it if we could pull it into 2.29.2
<mvo> hey zyga-solus - good morning
<mvo> zyga-solus: pr looks very good, I added some cosmetic suggestions and I'm fine pulling this in for 2.29
<zyga-solus> thank you
<kalikiana> good morning, snappy
<zyga-solus> good morning kalikiana
<mwhudson> zyga-solus: me neither
<mwhudson> zyga-solus: i refreshed the patches, so i think it's build-dep updates and try to build
<zyga-solus> thank you, that sounds good
<mwhudson> let me check i pushed that much to alioth :)
<zyga-solus> thank you :)
<mwhudson> seems i did!
<Tribaal> hi folks! I just got an extra rasperri pi 3 and would love to use it for Ubuntu core. What would you all use it for? Nextcloud?
<Tribaal> what's the new snapped hotness? :p
<zyga-solus> mvo: hey
<zyga-solus> mvo: I updated 4008
<zyga-solus> mvo: could you please look at secureMkdirAll again? I'm not using defer but if you feel strongly about it I can reiterate
<mvo> zyga-solus: thanks, I check it out. out of curiosity, whats wrong with defer there?
<zyga-solus> mvo: nothing technically, there are two reasons (perhaps three) that I didn't use defer for
<zyga-solus> mvo: it was a rewrite from C and I kept the style
<zyga-solus> mvo: I check for all possible errors, including from close (unless already handling an error)
<zyga-solus> mvo: and defer would keep more FDs open then we need (one for each path segment)
<zyga-solus> mvo: if you prefer defer I can re-work the code to use defer and adjust tests to match
<mvo> zyga-solus: ok, that makes sense. I was thinking the fd usage would be it
<zyga-solus> mvo: it's not a very strong argument arguably as in typical cases it would keep a handful of FDs open at most
<zyga-solus> mvo: I'll try defer quickly, if it's not too ugly we can merge that ;)
<zyga-solus> mvo: pushed with defer
<zyga-solus> mvo: have a look at patch here please: https://github.com/snapcore/snapd/pull/4008/commits/1a4d21279aedfbad71357ee031cca068af8e4850
<mup> PR #4008: cmd/snap-update-ns: create missing mount points automatically <Created by zyga> <https://github.com/snapcore/snapd/pull/4008>
 * zyga-solus -> ENOTEA brb
<mvo> zyga-solus: it says "done" to the rename of EnsureMountPointImpl but the name is still EnsureMountPointImpl not EnsureMountPoint ?
<mvo> zyga-solus: I like it but no super strong opinion either, just feel more "natural"
<zyga-solus> mvo: oh, I must have missed it, I renamed the other Impl, correcting now
<skjensen> Morning guys, I have got past the error I had yesterday building the image for the jetson tk1. I'm now at step 8: populate_filesystems. But I'm missing the  MLO.
<zyga-solus> no, wait, I dropped that patch entirely :/
<skjensen> I have tried to go through the uboot build steps in a terminal and it isn't building the MLO, anyone who can point me in the right direction of figuring out how to build a MLO or why ubuntu-image build expects to find one?
<zyga-solus> skjensen: sorry, I don't know much about uboot :/
<zyga-solus> mvo: ok, all done now
 * zyga-solus didn't make tea but instead walked his daughter to school to help
<Chipaca> zyga-solus: to help what?
<zyga-solus> Chipaca: to help her, it's raining all the time and her backpack was very heavy today
<Chipaca> zyga-solus: you're supposed to let the rain water get out of the backpack
<zyga-solus> :D
<zyga-solus> Chipaca: how would they have their swimming classes if I did?
<Chipaca> zyga-solus: fair point
<pedronis> mvo: hi, did you see my comment from last evening?
<zyga-solus> Chipaca: can I frame you into a review of one function?
<Chipaca> zyga-solus: you can try
<zyga-solus> Chipaca: can you please have a look at secureMkdirAll in 4008 please
<zyga-solus> Chipaca: it's very sensitive to get right and mvo found a bug already today
<mvo> pedronis: yeah, I think it makes sense. I have no managed to start with it though but I think I'm done with the xdg-settings for now until I get a review from jamie again so I will look at it next
<pedronis> mvo: thx
<Chipaca> zyga-solus: I don't understand your answer wrt path vs path/filepath
<pstolowski> mvo, hey, the autokpgtest failure on 4072 look unrelated to the change (spread passed), i think it's safe to merge isn't it?
<Chipaca> zyga-solus: filepath is path for filesystem stuff, path is a more generic thing (for, say, the web)
<pedronis> Chipaca: snapd#4075 needs a review, it's mostly undoing a previouw checking and starting going in a different direction (in store/ )
<mup> PR #4075: many: reorg things in preparation to make handling of the base url in store dynamic  <Created by pedronis> <https://github.com/snapcore/snapd/pull/4075>
<zyga-solus> Chipaca: aha
<Chipaca> pedronis: a'ight, i'll get to it after looking at zyga's
<zyga-solus> Chipaca: I didn't get that, I'll switch to filepath
<zyga-solus> Chipaca: done
<mvo> pstolowski: indeed, thank you
<mup> PR snapd#4072 closed: daemon: use newChange() in changeAliases for consistency <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4072>
<Chipaca> zyga-solus: path.go still uses path though
<zyga-solus> Chipaca: path.go?
<zyga-solus> ah I see
<Chipaca> OTOH grepping shows a few places
<Chipaca> maybe i should fix in a separate pr
<zyga-solus> done
<zyga-solus> pushed
<Chipaca> zyga-solus: jamie asked that you add a comment about why secureMkdirAll doesn't take relative paths, and you said 'done', but i don't see the comment; is it somewhere else?
<zyga-solus> Chipaca: man, I added that comment, did I break my rebase?
 * zyga-solus looks
<zyga-solus> yep
<zyga-solus> it's not there :/
 * zyga-solus looks at reflog
<zyga-solus> pushed
 * Chipaca worries
<zyga-solus> I just checked, nothing else is lost
<mvo> mwhudson: could you please check https://bugs.launchpad.net/ubuntu/+source/golang-1.7/+bug/1726706 and comment if that is safe? there is concern from the sru team that this changes existing behavior on unrelated architectures
<mup> Bug #1726706: Fails to build snapd on ppc64el <golang-1.7 (Ubuntu):Fix Released> <golang-1.7 (Ubuntu Zesty):New> <https://launchpad.net/bugs/1726706>
<Chipaca> zyga-solus: how much bikeshedding is acceptable on this?
<Chipaca> zyga-solus: 3? :-)
<zyga-solus> Chipaca: any amount, what else did you find?
<mwhudson> mvo: sure
<pstolowski> mvo, looks like Sergio has been waiting for your feedback on 3994 (and it's a very small change)
<Chipaca> zyga-solus: i'll comment on the pr
<mvo> pstolowski: thanks, I just checked and have the same question as you :)
<pstolowski> good :)
<mwhudson> mvo: where did the sru team express their concerns?
<mvo> mwhudson: on irc via /query *cough*
<mwhudson> mvo: hooray
<seb128> mvo, hey, do you know what's the status of making classic snaps to work on 17.10?
<mvo> mwhudson: I will ask apw to voice his concern about https://launchpad.net/bugs/1726706  in the bug :) but if you can just confirm its an ok change (with your golang maintainer/upstream head on, that would be great)
<mup> Bug #1726706: Fails to build snapd on ppc64el <golang-1.7 (Ubuntu):Fix Released> <golang-1.7 (Ubuntu Zesty):New> <https://launchpad.net/bugs/1726706>
<mwhudson> mvo: done
<mvo> seb128: I'm not sure we are tracking this right now, aiui snapcraft is working on a fix, maybe kalikiana knows more?
<mvo> mwhudson: thank you!
<seb128> mvo, seems like an important issue? we have projects that were trying to go the snap way and are considering not doing that after all and going back to some other format since snaps don't work for them on current Ubuntu :-/
<mvo> seb128: yes, it sucks. I will raise it during the standup to make sure it gets attention and a proper analysis. is there a forum topic already?
<ogra_> seb128, i think snapcraft works on droopping all LD_LIBARY_PATH stuff for that and to make all classic snaps use rpath ...
 * ogra_ looks fo the PR ... 
<Chipaca> zyga-solus: i was wrong :-)
<zyga-solus> Chipaca: about what?
<ogra_> seb128, https://github.com/snapcore/snapcraft/pull/1632 and https://github.com/snapcore/snapcraft/pull/1635 (seems both are merged in master already... though i guess all existing classic snaps need to be re-built)
<mup> PR snapcraft#1632: libraries: exclude the full set of libc6 <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1632>
<mup> PR snapcraft#1635: snap: remove leaking LD_LIBRARY_PATH <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1635>
<seb128> mvo, ogra_, thanks
<kalikiana> mvo: Fix for...?
<seb128> mvo, https://forum.snapcraft.io/t/classic-snaps-failing-on-ubuntu-17-10/2324/ is the forum post ... from what ogra_ replied it seems to be worked, would still be good to make sure it's properly tracked and know when it might land
 * kalikiana reading the backlog
<seb128> kalikiana, ^
<seb128> ogra_, kalikiana, mvo , could somebody post an update on that forum topic? it has several users asking for a status update in the course of the recent weeks and they just got silence in return so far
<kalikiana> seb128: Good call. We've got some fixes for library exclusion and LD_LIBRARY_PATH handling in the pipeline. Will have to check exactly which bits apply to this topic
<ogra_> seb128, well, kyrofa and sergiusens have been working on it ... either of them should be able to give updates (i dont know more than whats in the discussion and the PRs)
<seb128> kyrofa, sergiusens, ^ could you update that forum post before we get people who consider stopping their snap actually doing that because they feel like the system is buggy and nobody cares to update them on the issues?
<Chipaca> zyga-solus: curse you! why am i reading open_by_handle_at(2) at this time of the morning
<ogra_> Chipaca, dude! now you made us all read it !
<Chipaca> ogra_: it's all dem bionic badgers
<ogra_> heh
<zyga-solus> Chipaca: haha
<zyga-solus> Chipaca: I read it too, did you find anything interesting?
<Chipaca> zyga-solus: no, it nerdsniped me, is all
<Chipaca> zyga-solus: commented on the pr
<zyga-solus> Chipaca: thank you
<zyga-solus> Chipaca: I can add O_PATH easily
<zyga-solus> Chipaca: please look at the defer vs hand-made cleanup response
<mup> PR snapd#4052 closed: tests: check for invalid udev files during all tests <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4052>
<Chipaca> zyga-solus: yes i know you added the defers
<Chipaca> zyga-solus: i thought the better solution would be to move the body of the loop to a helper, but it doesn't help
<pstolowski> Chipaca, hey, 4050 has a conflict
<Chipaca> (that's why it took me some time to review: i wrote what i thought would help, and it didn't)
<Chipaca> pstolowski: lies!
 * Chipaca looks
<pstolowski> :)
<Chipaca> a PR that's been open for over a week, having a conflict? i'm shocked
<Chipaca> fixing...
<zyga-solus> Chipaca: yes, I was thinking about that but there's no nicer way with defer
<zyga-solus> Chipaca: python refcount would be better
<mup> PR snapd#4007 closed: interfaces: add plugRef/slotRef helpers for PlugInfo/SlotInfo <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4007>
<Chipaca> zyga-solus: not really, as the refcount cleanup is not deterministic
<Chipaca> zyga-solus: at least with defers when you're done you're done
<zyga-solus> Chipaca: in CPython it is deterministic
<Chipaca> true
<Chipaca> but who still uses cpython :-p
 * Chipaca knows the answer is 'everybody'
<Chipaca> mvo: remember `tidyNoticef`? did you have a better name in mind?
<Chipaca> i'm touching that pr anyway to resolve a conflict so i might as well address this
<seb128> kalikiana, thanks for posting on that forum discussion
<kalikiana> Sure. Thanks for bring it up. I try to follow what's going on but sometimes it's just a lot to read.
<Chipaca> i hadn't noticed github's favicon now shows the state of the tests
<Chipaca> nice
<skjensen> Is it possible to unpack a gadget snap?
<mvo> Chipaca: hm, I need to think about a better name but names are hard
<Chipaca> skjensen: you can unpack it with unsquashfs, or you can mount it by hand
<zyga-solus> Chipaca: updated again
<Chipaca> skjensen: snaps are just squashfs
<skjensen> Excellent.. Thanks I will try that and try understand what I have packed down into the gadget.. :)
<Chipaca> :-)
<Chipaca> zyga-solus: ack. On samuele's pr now, i'll check back later (unless i forget :-)
<zyga-solus> thank you!
<zyga-solus> I'll look at my other PRs that are close to landing
<Chipaca> mvo: I'll just call it noticef, and add a comment
<mvo> Chipaca: ok
<pstolowski> Chipaca, got travis failure on completion test https://travis-ci.org/snapcore/snapd/builds/292510395?utm_source=github_status&utm_medium=notification , thought you might want to know
<Chipaca> pstolowski: in prepare
<Chipaca> nice one
<Chipaca> 'tar: /var/lib/snapd: file changed as we read it'
<niemeyer> pedronis: About your comment yesterday, perhaps the right place is indeed the handler of the "configure" task handler
<niemeyer> pedronis: Oh, wait.. the task is actually a hook task
<niemeyer> Hmm
<pedronis> niemeyer: yea, so a level up
<pedronis> configstate.Configure
<pedronis> which needs to create the hook task or a different one
<pedronis> unless we had overriding pluggability into hooks themselves
<pedronis> which seems a bit overkill unless we have another use case
<niemeyer> pedronis: The cheapest seems to be intercepting it within the hook handler itself
<niemeyer> pedronis: Well.. or we just have a new handler inside configstate
<pedronis> the 2nd one was my idea
<pedronis> IÂ mean hacking in doRunHook is probably cheap but is strange unless we do it as a general mechanism, but then is not that cheap anymore
<niemeyer> pedronis: Sounds good.. these other options in HookSetup probably don't make much sense either way
<niemeyer> pedronis: "configure-snapd"?
<pedronis> sounds reasonable
<pedronis> mvo: ^
<Facu> elopio, sergiusens, hello! do you know how could I get reviews here? https://github.com/snapcore/snapcraft/pull/1634 thanks!
<mup> PR snapcraft#1634: Push metadata to the Store <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1634>
<kalikiana> Facu: For some reason there was no GitHub notifications of your replies... let me have another look now.
<kalikiana> So thanks for pinging on that!
<Facu> kalikiana, :)
<kalikiana> The other guys will be around later. I can check also who would help review
<niemeyer> pedronis, mvo: https://forum.snapcraft.io/t/special-casing-the-core-configuration/2594
<kalikiana> Facu: I added some comments - I'm still slightly confused, though, regarding the arch in update_metadata... what relevance does it have there, if it's unused in the failing code path?
<kalikiana> Maybe the error should be changed?
<niemeyer> pedronis: When you have a moment, would you mind to pass your eyes over #4070.. I think it's good to go, but it wouldn't heart to have another pair of eyes there to check we didn't miss something
<mup> PR #4070: hooks/configure: queue service restarts <Created by stolowski> <https://github.com/snapcore/snapd/pull/4070>
<pstolowski> thanks niemeyer
<niemeyer> pstolowski: np
<Facu> kalikiana, mmm... I see that SnapNotFoundError supports *not* receiving the arch
<pstolowski> niemeyer, btw, any chance to have your eyes on #4013 before your holidays?
<mup> PR #4013: repo, daemon: use PlugInfo, SlotInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/4013>
<mvo> niemeyer, pedronis thanks for this, I'm working on this now
<Facu> kalikiana, OTOH, see for example the function get_snap_status in that file; it builds the error with the arch even if the situation that led to the error has nothing to do with the arch (it happened to have the arch because it's just used later)
<pedronis> niemeyer: I'll look at 4070 in a bit
<niemeyer> pedronis: Thanks!
<niemeyer> mvo: np
<niemeyer> ackk: PR reviewed, and LGTM
<niemeyer> ackk: We need a second review on it
<niemeyer> I don't recall who was involved in the socket activation conversations..
<kalikiana> Facu: I'd say rather not use it if nothing in the method does. It makes a lot more sense to me anyway
<niemeyer> Ah, Chipaca would be a great reviewer here I think
<niemeyer> Chipaca: #3916!
<mup> PR #3916: snap,wrappers: add support for socket activation <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916>
<Facu> kalikiana, let's do that
<niemeyer> pstolowski: Yeah, I'm hoping so.. it's looking like a long day :)
<Facu> kalikiana, do you have any idea about that ACL failure in Travis?
<ackk> thanks niemeyer
<kalikiana> Facu: You mean CLI? Try merging master. The check can get confused when there's new commits.
<kalikiana> CLA, even
<ogra_> skjensen, MLO is only expected if you defined it ... if your board doesnt use one you indeed dont need to add it to the gadget.yaml (sorry, only saw you now in the backlog)
<ogra_> skjensen, here is an example gadget without MLO https://github.com/ogra1/nanopi-neo-gadget ... note that you need to find the right size and offset values for your board indeed ...
<pedronis> niemeyer: pstolowski:  about #4070, +1 with some comments
<mup> PR #4070: hooks/configure: queue service restarts <Created by stolowski> <https://github.com/snapcore/snapd/pull/4070>
<pedronis> and questions
<pedronis> pstolowski: it seems some of your "upcoming"Â were in 2.28, time to remove the tags ?
<niemeyer> pedronis: Good points
<niemeyer> Definitely worth testing, and documenting in the snapctl description
<niemeyer> pedronis, pstolowski: The flag also seems useful for the near future.. I'd wait until we have some experience, though, even to make sure we won't have to revert this decision based on user feedback
<niemeyer> I'd name it as --now if it comes
<pedronis> yea
<pedronis> updated my comment
<niemeyer> Thanks!
<Facu> kalikiana, ack, will merge master, thanks
<skjensen> ogra_ thanks I will try to build the snap without.. :)
<skjensen> ogra_ how do you find the correct size and offset values?
<ogra_> skjensen, i think i wrote about thet in my blog ...
<ogra_> *that
<skjensen> okay, I will have another read through the blog.. :)
<ogra_> https://ograblog.wordpress.com/2017/05/30/building-u-boot-gadget-snap-packages-from-source/
<ogra_> under "creating the gadget.yaml "
<ogra_> you need to know the values typically used for your board ... then you can convert them to byte offsets and size
<skjensen> yes..
<skjensen> ogra_ any chance you know the difference between u-boot.img u-boot-tegra.bin u-boot-dtb-tegra.bin u-boot-nodtb-tegra.bin I see you used the u-boot.img in your example for the bbb but the nanopo is using u-boot-sunxi-with-spl.bin so a bin file.. I got both from building u-boot so which to choose?
<ogra_> skjensen, oh, no idea, i'd start with u-boot-tegra.bin
<ogra_> try to find some docs about that from someone wh has done this before
<skjensen> Okay..
<jdstrand> willcooke: hey, I had an idea about speeding up gnome snaps on first launch
<jdstrand> willcooke: it isn't fully formed or anything, but snappy has this thing 'userd' that runs as the user in the user's session. it seems plausible that it could be the thing that compiles the gschemas
<willcooke> jdstrand, we're planning on layouts allowing us to use the compiled schemas which should shave a couple of seconds at least of start-up
<willcooke> jdstrand, I'll ask jamesh to sync with you on that topic
<jdstrand> willcooke: I'm actually involved in the layouts work, so if he can solve it there, even better
<willcooke> jdstrand, nice one.  I'll drop James an email now anyway
<pstolowski> pedronis, thanks for the review, good points. i'll check my 'upcoming' tags, thanks
<Chipaca> anybody know a snap that has a service and a command?
<pedronis> Chipaca: network-manager
<pedronis> Chipaca: it's an interesting example though, because we don't want (for now) people installing it on classic
<zyga-ubuntu> Chipaca: fun fact: no fchown with O_PATH
<zyga-ubuntu> Chipaca: also, standup
<noise][> Chipaca: postgresql?
<arubislander> Hi, I have a question. Say I have a snap that needs access to /tmp what interface(s) should it connect to?
<zyga-ubuntu> arubislander: hey
<zyga-ubuntu> arubislander: /tmp is always available but it is private to the snap
<zyga-ubuntu> arubislander: no snap can use the real host-side /tmp directory
<zyga-ubuntu> arubislander: there is no interface that controls this currently
<zyga-ubuntu> arubislander: why do you need access to the host-side /tmp?
<arubislander> Well, it was more that I am using the libreoffice snap, and every time I want to directly open a file downloaded in firefox I get a permissions error thrown. I need to save the file first to a location in my home folder.
<arubislander> So I was thinking that maybe there should be an interface for /tmp access just like there is for removable media access.
<arubislander> zyga-ubuntu: O, I see the convention here is to make it explicit who you are talking too. Apologies for the previous omissions.
<Chipaca> noise][: the postgres snaps have no daemons
<Chipaca> noise][: i suspect this is a bug
<noise][> odd.
<noise][> Chipaca: etcd has both
<Chipaca> yes yes it does
<jdstrand> zyga-ubuntu: 'daemon is not so portable actually'. what failed with daemon?
<jdstrand> it is defined by the LSB as required
<jdstrand> I'm curious because of something I am working on
<zyga-ubuntu> jdstrand: solus
<zyga-ubuntu> jdstrand: I switched to nobody nogroup
<zyga-ubuntu> arubislander: no worries :)
<zyga-ubuntu> arubislander: real /tmp is in /var/lib/snapd/hostfs/tmp but it's not accessible
<zyga-ubuntu> jdstrand: I think ikey would know why daemon group is not available there :)
<zyga-ubuntu> jdstrand: thank you for the reviews, I think the two branches are much better now
<zyga-ubuntu> jdstrand: I'm curious to know what you are working on now
<jdstrand> well, the uid/gid priv dropping work
<jdstrand> but it isn't something I have much time to focus on unfortunately
<zyga-ubuntu> jdstrand: uid/gid priv dropping where? I'm not familiar with this topic
<zyga-ubuntu> ah
<zyga-ubuntu> you mean in-snap users?
<zyga-ubuntu> (users and grops)
<zyga-ubuntu> *groups)
<jdstrand> zyga-ubuntu: that is one of 4 use cases, yes
<jdstrand> https://forum.snapcraft.io/t/snappy-users-and-groups-take-2/1461
<jdstrand> the topic was renamed to focus on only one use case though...
<jdstrand> ikey: fyi> http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/usernames.html
<jdstrand> ikey: 'daemon' is listed under 'Required User & Group Names'
<jdstrand> zyga-ubuntu: you might consider the fact that 'nobody' is optional under LSB and 'nogroup' is not lised as anything (I think 'nogroup' is a Debian-ism iirc)
<jdstrand> zyga-ubuntu: perhaps your PR should use 'bin/bin' or continue to use 'daemon/daemon' and pick something else on solus?
<jdstrand> anyway, I'm not blocking on that. it is just the test code
<pedronis> niemeyer: would be good to have your input here https://forum.snapcraft.io/t/new-install-refresh-api-with-the-store/2269/6 if you have any immediate feedback
<zyga-ubuntu> jdstrand: eh, good point
<zyga-ubuntu> jdstrand: maybe I cna put a list of things and if any of those work, pass the tset
<zyga-ubuntu> *test
<mup> PR snapcraft#1639 opened: grammar: to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1639>
<zyga-ubuntu> mvo: FYI, I just want to get this under someone's radar: https://bugs.launchpad.net/snappy/+bug/1723881
<mup> Bug #1723881: [Feature Request] Support pre-invoke and post-invoke commands as DPkg::Pre-Invoke and DPkg::Post-Invoke in APT <Snappy:New> <https://launchpad.net/bugs/1723881>
 * zyga-ubuntu breaks for lunch
<arubislander> zyga-ubuntu: thanks for the info. /tmp not being accessible, is that a confinement security based decision?
 * jdstrand -> errands and lunch
<Chipaca> mvo: can i nominate #4050 for 2.19rcN?
<mup> PR #4050: cmd/snap: tell translators about arg names and descs req's <Created by chipaca> <https://github.com/snapcore/snapd/pull/4050>
<Chipaca> mvo: also can i have a review of it :-)
<om26er> hey popey, can you share the snapcraft.yaml of yakyak, probably a comment here: https://github.com/yakyak/yakyak/issues/741 would be nice.
<zyga-ubuntu> arubislander: yes
<zyga-ubuntu> arubislander: for isolation each snap sees a private /tmp
<om26er> popey: someone actually proposed snap packaging a few months ago for yakyak: https://github.com/yakyak/yakyak/pull/752 but that didn't go much far. (and the diff looks weird)
<mup> PR yakyak/yakyak#752: Added Snap Support <Created by OctoPenguin> <https://github.com/yakyak/yakyak/pull/752>
<cachio> mvo, is this the error that you mentioned in trusty https://paste.ubuntu.com/25817308/
<cachio> ?
<zyga-ubuntu> darn, I didn't plug my laptop and it suspended
<kyrofa> ogra_, kalikiana seb128 mvo not completely fixed yet, but definitely a high priority
<kyrofa> ogra_, kalikiana seb128 mvo we've landed a few PRs that make progress, but we're still missing patchelf changes
<kyrofa> Which is in progress
<kyrofa> I'll update the forum thread
<kalikiana> +1
<kyrofa> seb128, thank you for the ping, we should have been updating it as we made progress
<mvo> cachio: I have not seen this one yet :/
<cachio> mvo, ok
<seb128> kyrofa, thanks
<mup> PR snapd#3989 closed: client, daemon: rest api to configure store api <Blocked> <Created by atomatt> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/3989>
<elopio> snappy-m-o 1630 xenial:amd64:integrationtests
<mup> PR snapd#3990 closed: cmd/snap,client,daemon: support set/unset of store front <Blocked> <Created by atomatt> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/3990>
<elopio> snappy-m-o autopkgtest 1630 xenial:amd64:integrationtests
<snappy-m-o> elopio: I've just triggered your test.
<zyga-ubuntu> hrm
<pedronis> Chipaca: any reason not to merge #4062,  you addressed the objection afaict.
<mup> PR #4062: cmd/snap: warn when a snap is not from the tracking channel <Created by chipaca> <https://github.com/snapcore/snapd/pull/4062>
<Chipaca> pedronis: I did, but I don't like to merge while it's still 'changes requested'
<Chipaca> although I now see a "dismiss review" button
 * Chipaca grins evily
<kyrofa> snappy-m-o, autopkgtest 1636 xenial:amd64
<snappy-m-o> kyrofa: I've just triggered your test.
<mup> PR snapd#3965 closed: interfaces/mount: add support for parsing x-snapd.{mode,uid,gid}= <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3965>
<mup> PR snapd#3999 closed: cmd/snap-confine: add detection of stale mount namespace <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3999>
<mup> PR snapd#4062 closed: cmd/snap: warn when a snap is not from the tracking channel <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4062>
<Chipaca> snappy-m-o: dance for us
<snappy-m-o> Command ":" / ": dance" not found.
<arubislander> zyga-ubuntu: check
<pedronis> mvo: what's the status of #4060, I see it has two +1 but some open nitpicks ?
<mup> PR #4060: interfaces: clean system apparmor cache on core device <Created by mvo5> <https://github.com/snapcore/snapd/pull/4060>
<kyrofa> seb128, update given
<mvo> pedronis: indeed, I will get to it later, forgot about those
<seb128> kyrofa, thanks
<popey> om26er: kk
 * Chipaca hugs pedronis 
<Chipaca> thank you for doing this
<kyrofa> Hey jdstrand, review-wise, can I claim the same dbus common name in two snaps?
<mvo> zyga-ubuntu: do you have any idea about https://bugs.launchpad.net/snapd/+bug/1721518 ? the most interessting part if #3 actually, on trusty apprently sometimes interface connections get lost
<mup> Bug #1721518: Latest snapd in Trusty is broken after reboot because of systemd units start ordering <snapd:In Progress by inaddy> <https://launchpad.net/bugs/1721518>
<zyga-ubuntu> mvo: looking
<zyga-ubuntu> mvo: that's very interesting
<zyga-ubuntu> mvo: no idaa, come to think of it, maybe something we are doing is wiping our state
<zyga-ubuntu> mvo: maybe some 1st boot logic?
<mvo> zyga-ubuntu: interessting idea
<zyga-ubuntu> mvo: nothing that I can think of would remove connections
<zyga-ubuntu> mvo: especially if the snap is present
<zyga-ubuntu> mvo: and it seems it is as there are slots there from core
<mvo> zyga-ubuntu: the annoying part is that its on trusty and we have lost the knowledge about the details there
<zyga-ubuntu> mvo: yes but I think we are not in a terrible situation, the set of units is closed, it's just deputy-systemd and snapd systemd units
<zyga-ubuntu> mvo: we can see what starts when and what happens
<zyga-ubuntu> mvo: the downside is that last time I looked there was no logging on 14.04
<zyga-ubuntu> mvo: I can look but I'm in a car now
<zyga-ubuntu> mvo: tell me what you know
<mvo> zyga-ubuntu: heh, no worries
<zyga-ubuntu> mvo: did you manage to reproduce it?
<mvo> zyga-ubuntu: I don't know anything at this point :( I have not yet found time to reproduce/debug. was mostly wondering if you saw any of this before, if not, thats fine. I can look tomorrow morning if I can reproduce (some people from landscape wait for this)
<zyga-ubuntu> mvo: I saw one instance
<zyga-ubuntu> mvo: but it was _not_ on 14.04
<mvo> zyga-ubuntu: oh?!?
<zyga-ubuntu> mvo: sergio reported it on his surface
<zyga-ubuntu> mvo: not sure what the conditions were but it wasn't 14.04 for sure
<kalikiana> kyrofa: Perhaps you'd like to have a look at snapcraft#1639 - as written in the description that's not implementing the "on..to.." yet. I'm still working on that (and still pondering how to not make it too ugly, haha). Was wondering if it should be done in one bigger PR or rather two separate ones...
<mup> PR snapcraft#1639: grammar: to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1639>
<zyga-ubuntu> mvo: I can setup a test loop
<zyga-ubuntu> mvo: just not sure what the steps are, boot trusty, <snapshot> install snapd, reboot, test hello world, <rollback>
<zyga-ubuntu> mvo: at each time hello-world should have iface connections
<mvo> cachio_lunch: hey, if you have a free slot in between the other work, would you mind to try to reproduce https://bugs.launchpad.net/snapd/+bug/1721518 ?
<mup> Bug #1721518: Latest snapd in Trusty is broken after reboot because of systemd units start ordering <snapd:In Progress by inaddy> <https://launchpad.net/bugs/1721518>
<zyga-ubuntu> mvo: I can also install other snaps (maybe the one used in the report matters)
<zyga-ubuntu> mvo: I can tweak my python script for snapshots to test this very quckly (many loops)
<cachio> mvo, sure
<zyga-ubuntu> mvo: but that looks like a half day effort tomorrow morning
 * kalikiana will be leaving in a few minutes, but feel free to respond here anyway
<mvo> zyga-ubuntu: canonical-livepatch is the important one. if you or cachio (timezone wise it might be better for him as its earlier there) could check that would be great
<mvo> zyga-ubuntu: yeah, lets see if cachio  can easily reproduce and then we decide what to do
<mup> PR snapd#4076 opened: many: handle core configuration internally instead of using the core configure hook <Created by mvo5> <https://github.com/snapcore/snapd/pull/4076>
<zyga-ubuntu> mvo: ok, Ill let cachio work on this today and I'll attack it first thing tomorrow
<mvo> zyga-ubuntu: \o/ lets sync on it in the morning
<zyga-ubuntu> I'm working on the overlayfs PR now but I have some tests to adjusts after rebasing
<zyga-ubuntu> mvo: sounds good,
<kyrofa> kalikiana, will do
<mvo> zyga-ubuntu: ta
<kalikiana> Thanks!
<kalikiana> sergiusens: Maybe you wanna check this one? It's store-related and needs another reviewer snapcraft#1634
<mup> PR snapcraft#1634: Push metadata to the Store <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1634>
<pedronis> mvo: IÂ left some initial comments in #4076, but looking code afaict
<mup> PR #4076: many: handle core configuration internally instead of using the core configure hook <Created by mvo5> <https://github.com/snapcore/snapd/pull/4076>
<niemeyer> pedronis: Thanks, will definitely look today
<mup> PR snapd#4077 opened: spdx: fix for WITH syntax, require a license name before the operator <Created by matiasb> <https://github.com/snapcore/snapd/pull/4077>
<pedronis> mvo, IÂ meant "looking good"
<niemeyer> pedronis: I'm slightly confused about the question about epoch
<niemeyer> pedronis: How can the server possibly respect the epoch if it doesn't know it?
<cachio> mvo, I could reproduce the error
<kyrofa> snappy-m-o, autopkgtest 1583 xenial:amd64
<snappy-m-o> kyrofa: I've just triggered your test.
<cachio> mvo, http://paste.ubuntu.com/25818102/
<cachio> mvo, I don't see anything weird apart of that
 * zyga-ubuntu is stuck in a traffic jam
<zyga-ubuntu> running spread tests
<zyga-ubuntu> watching the rain
<zyga-ubuntu> ...
<cachio> zyga-ubuntu, I could reproduce the error in trusty
<cachio> raining here too :)
<cachio> falling hail now
<cachio> kenvandine, hey
<pedronis> niemeyer: I think, they are thinking of going from revision to the epoch info looking at the info in the store
<niemeyer> pedronis: I see.. but that wouldn't work for the local case
<cachio> kenvandine, trying to access to gsettings schemas from a test snap
<kenvandine> hey cachio
<cachio> kenvandine, I am using the desktop interface but I can just access by using devmode
<pedronis> niemeyer: yes, but the local case doesn't quite fit into things, it's really special, we don't have a snap-id either for that case, it's really a cross of an install and refresh
<kenvandine> cachio, you need the gsettings interface too
<cachio> kenvandine, yes
<cachio> kenvandine, I can access to if I manually set the schemas dir to /var/lib/snapd/hostfs/usr/share/glib-2.0/schemas
<cachio> kenvandine, and I am in devmode
<cachio> kenvandine, is there any other way to access the user schemas?
<mvo> pedronis: yay, thanks a lot for your review!
<mvo> cachio: thanks, thats great. well, not great but at least easy to reproduce
<cachio> mvo, yes, first attempt
<mvo> cachio: what comments did you run? exactly the same as in the bugreport? I wonder why none of our existing tests caught this :(
 * mvo gets the feeling that however many tests you have, its never enough
<kenvandine> cachio, i haven't needed to change any schemas dir
<kenvandine> all my gnome snaps work just fine
<kenvandine> cachio, which snap are you working on?
<cachio> kenvandine, do you have an example?
<cachio> kenvandine, I would like to see how you are building the snaps, tx
<kenvandine> http://bazaar.launchpad.net/~ubuntu-desktop/gnome-calculator/snap/view/head:/snapcraft.yaml
<cachio> mvo, I have the same question
<kenvandine> cachio, is an example
<cachio> kenvandine, tx
<kenvandine> cachio, and it has to be built with the ubuntu-desktop/gnome-3-26 PPA enabled
<cachio> mvo, I'll gonna make a review of the tests to see if we need a new tests or what happened
<zyga-ubuntu> cachio: can you tell me what you did to reproduce? I will do the same
<cachio> zyga-ubuntu, just updated with apt
<zyga-ubuntu> caa
<mvo> cachio: thanks for chasing this, much appreciated
<zyga-ubuntu> cachio: aha, just that? did you have any set of snaps installed?
<cachio> and then followed the steps in the bug
<zyga-ubuntu> ah, ok, so the canonical-livepatch is relevant to the bug?
<mvo> cachio: I will look into it in my morning (in ~11h) to see if I can find the root cause
<cachio> I removed snapd, and then installed 2.27.5 from the archive
<zyga-ubuntu> cachio: so the steps are:
<zyga-ubuntu> cachio: boot 14.04
<zyga-ubuntu> cachio: install/update snapd
<zyga-ubuntu> cachio: install canonical-livepatch
<cachio> 2.27.5
<zyga-ubuntu> cachio: ... ?
<zyga-ubuntu> cachio: can you tell me which kernel you had around when the bug happened
<zyga-ubuntu> cachio: (running)
<cachio> zyga-ubuntu, 4.4.0-89-generic
<zyga-ubuntu> cachio: ok
<cachio> then you rebboot
<cachio> then install hello-world and see that everything goes ok
<cachio> then you reboot again
<zyga-ubuntu> cachio: so after reboot is's okay
<zyga-ubuntu> cachio: aha, go on
<cachio> and when you do snap intergaces, you see there are not interfaces listed
<zyga-ubuntu> cachio: when you started and before the 1st reboot, were you on 4.x already?
<cachio> zyga-ubuntu, yes
<mvo> the instructions sound like a spread test is not too hard to write for this (which is nice)
<cachio> mvo, should be easy
<cachio> I'll try to do it
<mvo> \o/
<pedronis> mvo: seems the change about configure made it so that we run it also on classic but now it fails seeing it cannot be, but we want some bits run also on classic, we need to reorg that somehow
<pedronis> or we ignore errors differently
<niemeyer> pedronis: Indeed, but ideally we'd still try to handle it correctly
<jdstrand> kyrofa: review-wise, yes, so long as it makes sense for both
<niemeyer> pedronis: Based on the name
<niemeyer> pedronis: and we might prevent obvious breakage by not allowing the epoch to go through
<pedronis> niemeyer: yes, but unclear we would put epoch in the context (the context doesn't have names, just snap-id), as I see it it woulb be a special case of "install" or its own "refresh-local" or something
<niemeyer> pedronis: Hmm
<pedronis> we could support both snap-ids and names in context
<pedronis> but not a fan of that
<niemeyer> pedronis: Yeah, I guess it'd be special indeed, and we probably don't want to send names at all cases
<niemeyer> pedronis: So sounds worth not bothering for now
<pedronis> yes, IÂ think it's special enough, we can fit it in later but with some special casing
<pedronis> but not worth making general changes based on it
<pedronis> niemeyer: IÂ think the conclusion is tha we don't strictly need epoch in context, I don't know if we still want to be explict though, or better leave the server to do revision->epoch lookup
<niemeyer> pedronis: I think it wouldn't hurt to have it either way
<niemeyer> pedronis: But I also can't argue for it with a good argument
<pedronis> I think it's best to leave it out, at least there's no situation in which the client can send somebody that is "wrong"
<pedronis> s/somebody/something/
<mcphail> ogra_: is porting ubuntu core to a new ARM device something a semi-technical semi-literate numpty like me would be capable of doing? I'd love to run core on my sheevaplug device, instead of debian
<kyrofa> You're still using a sheevaplug? Nice, I've got my old one sitting here
<kyrofa> However, I seem to remember that being arm6
<kyrofa> Which Ubuntu doesn't support
<mcphail> kyrofa: I have yet to find anything more reliable, to be honest. It just keeps working.
<kyrofa> mcphail, yeah I was on that train for a while as well. Used a few different plug computers. They kept eating my SD cards, though
<kyrofa> mcphail, the Mirabox was the best
<kyrofa> Dual USB 3, dual gigabit ethernet
<mcphail> I use the SD card for as little as possible. Most of my stuff is on the internal flash with an external usb drive bind-mounted over it
<kyrofa> Ah, good idea
<mcphail> It is a PITA to update when a new debian version comes out, though. Messing about with uboot is never fun. That's why the snappy model is attractive
<kyrofa> mcphail, just to double-check, can I see a `cat /proc/cpuinfo` ?
<mcphail> http://termbin.com/1tev
<mcphail> Does core require a certain feature set?
<kyrofa> mcphail, armv5
<kyrofa> mcphail, Ubuntu hasn't supported that since... what... 9.10?
<kyrofa> mcphail, and by extension, Ubuntu Core
<mup> PR snapd#4070 closed: hooks/configure: queue service restarts <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4070>
<mcphail> kyrofa: aah. But I can build my own kernel snap, can't I?
<kyrofa> mcphail, ogra_ is the expert here of course, but I don't think your quest will end in happiness
<mcphail> shame
<kyrofa> mcphail, oh sure. But consider the core snap, and the support archs in the store
<kyrofa> s/support/supported/
<mcphail> Hmm. Isn't armhf backwards compatiblke?
<kyrofa> Backwards compatible to... what?
<zyga-ubuntu> a armv5 binary to run on arvm7
<zyga-ubuntu> an*
<mcphail> armel
<mcphail> debian moved from armel to armhf with ARMv7 CPUs. That's when Ubuntu dropped sheevaplug support, but debian continued its armel port as well. I _think_ I've run armhf packages on the asheevaplug in the past (certainly, I run syncthing which is just packaged in a generic "arm" repo). I don't really understand this stuff ;)
<youngc> Can anyone here help with a snapcraft make error?
<kyrofa> mcphail, I don't think it works that direction-- I suspect hard-float instructions aren't supported on soft-float hardware, but the other way around might be possible
<kyrofa> mcphail, but yeah, I don't pretend to be an expert either
<kyrofa> I also think it's beyond just the floating point hardware
<kyrofa> youngc, hit me :)
<mcphail> kyrofa: thanks. You're probably right. I've just run "readelf -h syncthing | grep Flags" and it looks like it is ARM EABI v5. I suspect they release it that way and it will probably be forward compatible
<youngc> here we go... As far as using make goes it works, but... when I use the following command "make -f ./Makefile-Linux.x86_64 all" the make fails. Mind you I can manually go to the folder and type make and it works.
<youngc> more info just a sec
<youngc> it seems to be failing due to the actual folder is trying to run from
<youngc> but not sure
<youngc> the code is here: https://github.com/chadyoungdell/benchmark.io.iometer.snap
<kyrofa> youngc, when you "manually go to the folder and type make", it uses a different Makefile
<kyrofa> youngc, unless you're missing a step?
<kyrofa> Let me pull this thing real quick
<kyrofa> elopio, loving all the bitesize bugs
<kyrofa> youngc, try `makefile: src/Makefile-Linux.x86_64`
<kyrofa> youngc, it's relative to the root of the source
<kyrofa> youngc, which in the tarball, has that makefile in the `src/` dir
<youngc> I did that before this and had the same failure - let me try again real quick
<kyrofa> youngc, it still doesn't build, looks like the makefile is missing some things, but that'll get you unblocked anyway
<kyrofa> youngc, I get "make: *** No rule to make target 'IOGlobals.o', needed by 'dynamo'.  Stop."
<youngc> thats what I get to
<kyrofa> youngc, definitely not the same error
<youngc> if you open the file Makefile-Linux.x86_64 and modifiy IOGlobals.o to src/IOGlobals.o that file actually compiles
<youngc> sorry, I meant after I chaned the file to what you asked
<kyrofa> youngc, you might find this works better: https://pastebin.ubuntu.com/25818987/
<kyrofa> youngc, sounds like the cwd needs to be in src/ basically
<kyrofa> youngc, so that will help
<kyrofa> youngc, note the `source-subdir`
<youngc> ok, let me try that
<kyrofa> youngc, also note the removal of `src` from `makefile`
<kyrofa> basically that will run `cd src && make -f Makefileblahblah` instead
<youngc> cool!! that works
<kyrofa> Good deal
<youngc> I did not know that you could add the source-subdir to something other than git
<youngc> thanks for the help
<kyrofa> youngc, any time :)
<Odd_Bloke> sergiusens: o/ Am I doing something wrong, or are dots not allowed in app names?
<kyrofa> Odd_Bloke, app names consist of upper- and lower-case alphanumeric characters and hyphens. They cannot start or end with a hyphen
<kyrofa> No periods
<Odd_Bloke> Hmph.
<Odd_Bloke> Fair enough.
<popey> sergiusens: https://forum.snapcraft.io/t/snapcraft-unable-to-install-core-snap/2599 - what am I doing wrong?
<elopio> kyrofa these two PRs have been very challenging for my English. They will need many of your reviews.
<kyrofa> elopio, my pleasure, of course
<kyrofa> elopio, oh! Your regular nick again, eh?
<elopio> I had to change my password...
<elopio> Matrix is fun.
<kyrofa> Yeah, top-of-the-line user experience, I've noticed
<jdstrand> roadmr: fyi, https://dashboard.snapcraft.io/dev/snaps/7385/rev/995/ got stuck too. I requested to re-review
<roadmr> jdstrand: let's have a look
<jdstrand> roadmr: that didn't seem to help
<jdstrand> (the re-review)
<jdstrand> roadmr: https://dashboard.snapcraft.io/dev/snaps/8324/rev/51/ too. 19 hours ago, review tools passed
<jdstrand> roadmr: could this have something to do with the pacemaker bug?
<roadmr> pacemaker bug??
<mup> PR snapd#4078 opened: tests: new test to check interfaces after reboot the system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4078>
<roadmr> so - 8324 does seem stuck but 7385 doesn't
<roadmr> give me a sec to check the admin
<roadmr> oh, 7385 too, I was looking at wrong rev
<jdstrand> roadmr: https://launchpadlibrarian.net/342811432/pacemaker_1.1.14-2ubuntu1.2_1.1.14-2ubuntu1.3.diff.gz
<jdstrand> roadmr: I'm just curious-- cj watson mentioned something dying before that fix
<roadmr> jdstrand: probably not, this seems related to celery processes in the store's application units grabbing tasks which they then don't process
<jdstrand> roadmr: ok, 7385-- it just took longer than I expected. looks like my re-review request got it unstuck
<roadmr> jdstrand: ok - I do see 8324 in the "stuck" queue
<roadmr> jdstrand: do you have the "run the automated review again" button in https://dashboard.snapcraft.io/dev/snaps/8324/rev/51/ ?
<jdstrand> roadmr: ok, I won't touch 8324 and let you do whatever you need
<jdstrand> roadmr: I do
<jdstrand> I can do that. I didn't know if you wanted to look at 8324 more closely
<roadmr> jdstrand: give me a sec to just check if it correlates with a rollout (which is when we see celery weirdness happening)
<roadmr> jdstrand: ok, I kicked 8324 so we don't block it. We did match it with a rollout yesterday, so we'll figure out a way to keep this from happening
<roadmr> but it might, while we do figure out a way :) so let me know of any weirdness
<kyrofa> jdstrand, I just got a bug report from a user trying to install my snap on digitalocean, but getting "cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied"
<jdstrand> roadmr: ackc
<kyrofa> jdstrand, any clues regarding what might be the issue there?
<jdstrand> kyrofa: sounds like the kernel blocked snap-confine. are there any security denials?
<jdstrand> kyrofa: fyi, this is line 132 in cmd/snap-confine/ns-support.c
<kyrofa> jdstrand, I'll check
<jdstrand> kyrofa: if there is no denial, this is code zyga wrote so he may be more familiar with it. but would likely need a forum post with kernel version, etc
<kyrofa> jdstrand, does this look odd? Oct 25 17:40:26 portfolio kernel: [  223.174251] type=1400 audit(1508967626.765:94): apparmor="DENIED" operation="ptrace" profile="/snap/core/3247/usr/lib/snapd/snap-confine" pid=2427 comm="snap-confine" requested_mask="read" denied_mask="read" peer="unconfined"
<jdstrand> kyrofa: it does
<jdstrand> kyrofa: I'm curious if this rule would fix it: ptrace (read) peer=unconfined,
<jdstrand> kyrofa: we already have this rule which is meant to cover this: ptrace trace peer=unconfined,
<jdstrand> kyrofa: so it is possible that the Digital Ocean kernel is behaving differently
<jdstrand> kyrofa: (in snap-confine's profile)
<kyrofa> jdstrand, it's not re-execing using the profile in the core snap?
<jdstrand> kyrofa: hmm? I don't know anything about the vm that this would be running in
<kyrofa> jdstrand, sorry, rephrasing: where is snap-confine's profile?
<jdstrand> kyrofa: yes, that is the question. and the answer depends on if it is re-execing :)
<kyrofa> Oh! So I DID ask the right question, haha
<kyrofa> jdstrand, I believe it's good old Ubuntu 16.04
<jdstrand> kyrofa: well, if that was your question, I didn't understand it :P
<jdstrand> anyhoo
<kyrofa> jdstrand, boo :(
<jdstrand> so, if Ubuntu 16.04, then it should be reexecing
<kyrofa> But I can still copy the profile off, edit it, and load it
<jdstrand> you'll want to obtain the version of core. look at /snap/core/current and see what it is pointing to
<kyrofa> jdstrand, 3247 given the denial above, no?
<jdstrand> then it will be /etc/apparmor.d/snap.core.3247.usr.lib.snapd.snap-confine
<jdstrand> kyrofa: I suggest copying that file to ~
<jdstrand> then modify it, then do: sudo apparmor_parser -r ~/snap.core.3247.usr.lib.snapd.snap-confine
<kyrofa> jdstrand, excellent, thank you
<kyrofa> I'll get back to you
<jdstrand> that was harsh. I had a terminal open with an ssh session to a vm. I start to type in it and I didn't notice that typing into showed the connection was broken. then I sudo shutdown the 'vm' and tore down my session
<jdstrand> fun!
<kyrofa> Oouuch
<kyrofa> jdstrand, teach YOU to type looking at your fingers
<jdstrand> kyrofa: so, what I was going to say was make sure you add the rule to the main profile, not the mount-helper child profile
<jdstrand> well, the vm is stopped now
<jdstrand> so I achieved at least that much :)
<jdstrand> kyrofa: if that works, let me know and give the output of cat /proc/version_signature
<kyrofa> jdstrand, I only see one `ptrace trace peer=unconfined` in there
<kyrofa> jdstrand, I'm just replacing it... no?
<jdstrand> kyrofa: don't replace. add
<kyrofa> Just right below?
<jdstrand> yeah
<kyrofa> jdstrand, double-checking: the filename that I hand to apparmor_parser doesn't matter, right?
<jdstrand> kyrofa: correct
<kyrofa> jdstrand, one more double-check: https://pastebin.ubuntu.com/25819686/
<kyrofa> Haha, dangit, flip the args
<jdstrand> kyrofa: the diff is backwards, but yes
 * jdstrand nods
<kyrofa> Okay good
<jdstrand> kyrofa: wait whoops
<jdstrand> kyrofa: you forgot the trailing comma
<kyrofa> Ah, good catch
<jdstrand> kyrofa: this is also a safe action. if you jack it up, a reboot gives you the profile on the system since you didn't modify it
<kyrofa> jdstrand, indeed, thank you!
<jdstrand> kyrofa: did it work?
<kyrofa> jdstrand, working on it, this is async I'm afraid
<jdstrand> gotcha
<kyrofa> jdstrand, side note, I was trying to tweak the profile myself and send it to him, only to learn that I seemingly can't access anything in my home directory with "snap-confine" in the name from a confined snap
<kyrofa> jdstrand, is that true?
<kyrofa> jdstrand, https://pastebin.ubuntu.com/25819750/
<jdstrand> kyrofa: you are within a confined snap?
<kyrofa> jdstrand, indeed
<jdstrand> kyrofa: and the home interface is connected?
<jdstrand> kyrofa: it seems it would be since foo-bar-baz is there
<kyrofa> jdstrand, yep. Note the pastebin. It works as long as "snap-confine" isn't part of the file name :P
<kyrofa> jdstrand, wait, no sorry, only if snap-confine is starting the file name
<jdstrand> ok
<jdstrand> I was going to say, I couldn't see how foo-bar-snap-confine wouldn't work
<jdstrand> kyrofa: it is this gem: http://paste.ubuntu.com/25819780/
<kyrofa> jdstrand, haha, ouch
<jdstrand> kyrofa: it's incomplete
<jdstrand> I'll add a todo for that
<kyrofa> jdstrand, thank you!
<kyrofa> jdstrand, that profile tweak did the trick
<kyrofa> jdstrand, another interesting tidbit: this box was upgraded from trusty
<jdstrand> kyrofa: ok, what is the kernel? cat /proc/version_signature
<kyrofa> jdstrand, Ubuntu 3.13.0-71.114-generic 3.13.11-ckt29
<jdstrand> kyrofa: alright, so that there is your problem. you need the xenial kernel
<jdstrand> I'm surprised things are working as well as it is
<kyrofa> So do-release-upgrade doesn't upgrade the kernel?
<jdstrand> kyrofa: it absolutely should have
<jdstrand> kyrofa: perhaps the kernel was pinned? something went awry in the upgrade? grub didn't get updated?
<jdstrand> there are a lot of things that could've gone wrong
<jdstrand> kyrofa: sudo apt-get install linux-generic
<jdstrand> that may provide a clue if it is pinned. beyond that, they need to upgrade their kernel
<kyrofa> Thanks jdstrand there are actually two people saying this happened on digitalocean
<kyrofa> Something weird is happening over there
<jdstrand> yeah. huh
<jdstrand> kyrofa: is this a xen environment?
<kyrofa> jdstrand, great question, I have no idea how they do it
<jdstrand> cause maybe it is Digital Ocean's kernel (that happens to be an Ubuntu kernel)
<jdstrand> some hosting environments do things like that
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#58 closed: use `snapctl internal configure-core` to configure core <Created by mvo5> <https://github.com/snapcore/core/pull/58>
<mup> PR core#62 closed: create xdg-settings inside the core snap <Created by mvo5> <https://github.com/snapcore/core/pull/62>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#58 opened: use `snapctl internal configure-core` to configure core <Created by mvo5> <https://github.com/snapcore/core/pull/58>
<mup> PR core#62 opened: create xdg-settings inside the core snap <Created by mvo5> <https://github.com/snapcore/core/pull/62>
<kyrofa> jdstrand, finally, all resolved now
<kyrofa> jdstrand, https://www.digitalocean.com/community/tutorials/how-to-update-a-digitalocean-server-s-kernel
<kyrofa> jdstrand, tl;dr older droplets manage their kernel differently, outside the machine in the dashboard
<kyrofa> jdstrand, so even after updating, while the new kernel was installed, it wasn't booting into it
<nacc> kyrofa: yeah, it's a pretty regular FAQ in #ubuntu sadly
<kyrofa> jdstrand, once we got that sorted, snaps work fine
<kyrofa> nacc, brutal man
<kyrofa> Weird way to structure a system
<nacc> kyrofa: we'll be debugging some weird issue and it'll turn out they are runnig some random kernel :)
<kyrofa> But it sounds like they know that, and don't do it anymore
<nacc> kyrofa: VPS are a pain in that regard
<kyrofa> nacc, oh yeah, that happens all the time, definitely
<kyrofa> nacc, but trying to figure out why a kernel isn't being booted, despite grub looking perfect... ?
<kyrofa> nacc, do you see that often?
<nacc> kyrofa: not off the top of my head -- but i often default to blaminng the VPS provider if they are on any kind of VPS
<nacc> :)
<kyrofa> nacc, heh
<jdstrand> kyrofa: interesting, thanks!
<kyrofa> jdstrand, thank YOU
<kyrofa> Didn't even consider asking about the kernel
<kyrofa> Sorry for the wild goose chase
<kyrofa> Now I know
#snappy 2017-10-26
<mup> PR snapd#4079 opened: daemon: Allow Polkit authorization to cancel changes <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/4079>
<pjdc> fyi, starting RT#106813: Production SSO rollout (r1583) shortly
<pjdc> er, sorry, wrong channel
<mup> PR snapcraft#1640 opened: cli: add what, why, and how to fix to the common errors <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1640>
<Guest54752> I have to get started with development of qt Application on ubuntu core how to proceed with snap please help
<zyga-solus> mvo: good morning
<mvo> hey zyga-solus
<zyga-solus> mvo: I'm ready to help with 14.04
<zyga-solus> mvo: I'll start by reproducing the problem unless you have some other suggestions
<mvo> zyga-solus: cool, I tried to reproduce the error in https://bugs.launchpad.net/snapd/+bug/1721518 but failed so far
<mup> Bug #1721518: Latest snapd in Trusty is broken after reboot because of systemd units start ordering <snapd:In Progress by inaddy> <https://launchpad.net/bugs/1721518>
<mvo> zyga-solus: so if you can reproduce that would be great
<zyga-solus> ok, let's see what I can do
<mvo> zyga-solus: I used the autopkgtest generated image, maybe that is the problem. its a very minimal image. I suspect some boot race but its all very foggy
<zyga-solus> mvo: I'll start with a desktop image as I have that around
<mvo> zyga-solus: aha, cool
<kalikiana> moin moin
<zyga-solus> mvo: how did you get 2.27.6? from launchpad somewhere or from the core snap revision?
<zyga-solus> mvo: hmm, I cannot install 2.27.6 and 2.28.5 is OK
<mvo> zyga-solus: I used 2.27.5 and then installed core
<mvo> zyga-solus: so maybe/probably I did not test .6
<mvo> zyga-solus: did you manage to reproduce anything?
<zyga-solus> mvo: no
<mvo> zyga-solus: :(
<zyga-solus> mvo: I'll disable reexec and see
<mvo> feels like a wild goose chase
<zyga-solus> mvo: though that's hardly what the OP did
<mvo> zyga-solus: yeah, exactly. once you are happy (or unhappy) please followup in bug
<mvo> zyga-solus: I give this one more try in a less minimal image and then give up
<mvo> zyga-solus: interessting that cachio  reproduced it
<zyga-solus> mvo: with 2.27.5 I get the same behavior
<zyga-solus> mvo: I bet there is something we're missing that is making this relevant
<mvo> zyga-solus: yeah, hopefully that is also the glue what is wrong :)
<zyga-solus> I'll reboot a few times
<zyga-solus> maybe it really is timing
<mvo> zyga-solus: no luck with a full trusty image either, disappointing
<zyga-solus> mvo: woaaah
<zyga-solus> mvo: it happened
<zyga-solus> mvo: not exactly like in the report but out of 3 installed snaps I lost some interfaces!
<zyga-solus> mvo: I just set up auto logging
<zyga-solus> mvo: and I was rebooting and running "snap interfaces"
<zyga-solus> mvo: I disabled reexec so this is stock 2.27.5
<zyga-solus> mvo: I'm investigating the state now
<pstolowski> woot
<pstolowski> zyga-solus, !
<zyga-solus> so the sad stuff is that I don't see any logs from snapd
<zyga-solus> zilch
<zyga-solus> not a single line
<zyga-solus> oh, wait I actually have something now
<zyga-ubuntu> http://pastebin.ubuntu.com/25822002/
<zyga-ubuntu> theyory
<zyga-ubuntu> *theory
<zyga-ubuntu> very weak at the moment
<zyga-ubuntu> there's a real bug where on certain systems YAML parsing is exploding in unexpected ways
<zyga-ubuntu> what if it's just a race that for kernel config + vm reasons are making it more or less likely
<zyga-ubuntu> and at random we cannot read yaml's
<zyga-ubuntu> another theory: those are not mounted soon enough
<zyga-ubuntu> and end up "broken" when the interface repository is setup
<zyga-ubuntu> I'll look at the code to see what happens there
<zyga-ubuntu> I think we are just saying "ooops, problem but not going to die on this"
<zyga-solus> I'll paste my logs in case someone can fish out facts out of timing
<zyga-solus> one sec
<zyga-ubuntu> syslog: http://paste.ubuntu.com/25822015/
<zyga-ubuntu> journalctl http://paste.ubuntu.com/25822015/
<zyga-ubuntu> journalctl status snapd.service http://pastebin.ubuntu.com/25822002/
<zyga-ubuntu> oh, hold on, one of those is wrong
<zyga-ubuntu> http://paste.ubuntu.com/25822017/
<zyga-ubuntu> that's journalctl (2nd paste)
<zyga-ubuntu> snap list: http://paste.ubuntu.com/25822020/
<mvo> zyga-ubuntu: nice! yeah, the things-are-not-mounted-in-time is what the reporter also suggested
<zyga-ubuntu> mvo: so my snapd process is in this state now
<mvo> zyga-ubuntu: maybe systemd orders things differently in trusty
<zyga-ubuntu> I'll keep it as such for now
<zyga-ubuntu> I'll inspect units
<zyga-ubuntu> mvo: if you have ideas for experiments to make do say, I'll dig around
<zyga-ubuntu> zyga@ubuntu-trusty:~$ systemctl
<zyga-ubuntu> Failed to issue method call: No such method 'ListUnits'
<zyga-ubuntu> hmm, unexpected
<zyga-ubuntu> is our systemd compiled correctly?
<mvo> sudo ?
<mvo> or maybe systemd is in a funny state
<mvo> and it just happens to trigger this issue in snapd as a side-effect
<zyga-ubuntu> aha, interesting
<mvo> (just a very weak theory)
 * zyga-ubuntu would love for snapd to log everything to a file manually
<zyga-ubuntu> I've tweaked journal settings and rebooted
<zyga-ubuntu> I'll try to reproduce the bug again
<zyga-ubuntu> but hopefully with full output from snapd
<zyga-ubuntu> mvo: is there a thread for this? I'd like to respond
<mvo> zyga-ubuntu: https://bugs.launchpad.net/snapd/+bug/1721518
<mup> Bug #1721518: Latest snapd in Trusty is broken after reboot because of systemd units start ordering <snapd:In Progress by inaddy> <https://launchpad.net/bugs/1721518>
<sergiusens> Odd_Bloke the `.` is used to namespace the app name with the snap name
<zyga-ubuntu> thanks!
<zyga-ubuntu> mvo: hmm, why are there /etc/systemd/upstart/snapd.service and /etc/systemd/system/snapd.service?
<sergiusens> popey your issue with lxd should be looked at by kalikiana, I feel that the general user experience on lxd has decayed a bit in the past months :-/
<popey> thank you
<zyga-ubuntu> (sorry, those are /lib, not /etc0
<mvo> zyga-ubuntu: I have no idea, I did not work on the trusty part of snapd :/
<mvo> zyga-ubuntu: sudo systemctl gives you the same error?
<mvo> zyga-ubuntu: i.e. that systemctl is busted? anything in the logs that might indicate whats wrong? is systemctl status snapd working?
<zyga-ubuntu> yes
<zyga-ubuntu> one sec
<zyga-ubuntu> ah, with sudo they work OK
<mvo> ok
<mvo> so not systemd
<mvo> zyga-ubuntu: let me try something
<zyga-ubuntu> I've tweaked the snapd unit
<zyga-ubuntu> I now have logs each time we start
<zyga-ubuntu> I'm in a reboot loop
<zyga-ubuntu> let's see what we get
<zyga-ubuntu> mvo: and it just happened again :)
<zyga-ubuntu> http://pastebin.ubuntu.com/25822085/
<zyga-ubuntu> I'll enable debug
<mvo> zyga-ubuntu: I wonder if something trivial like http://paste.ubuntu.com/25822089/ would be enough?
<zyga-ubuntu> heh, maybe :-)
<zyga-ubuntu> don't we do that?
<mvo> zyga-ubuntu: maybe you can add it manually to the mount units that exist
<zyga-ubuntu> how do we guarantee that those mount before snapd?
<zyga-ubuntu> yep
<mvo> zyga-ubuntu: I don't think so :(
<zyga-ubuntu> let me enable debug and reproduce again before doing htis
<mvo> zyga-ubuntu: I think in our systemd the mount stuff happens before multi-user target (where snapd is started). maybe (maybe!) this is different in old systemd?
<mvo> zyga-ubuntu: thanks a lot
<zyga-ubuntu> mvo: I was assuming that when there's a mount unit
<zyga-ubuntu> systemd sets up automount thing
<zyga-ubuntu> so that there cannot be a race if you simply attempt to access files s there
<zyga-ubuntu> but maybe I'm wrong and that's not default at all
<zyga-ubuntu> mvo: honestly another reason I'd cache the snap.yaml files
<zyga-ubuntu> mvo: we could operate without mounted units
<zyga-ubuntu> mvo: we could even mount them on demand
<mvo> zyga-ubuntu: right
<mvo> zyga-ubuntu: please keep me updated about if the before=snapd.service helps, that might be an easy fix
<zyga-ubuntu> ok
<zyga-ubuntu> yes, definitely a 2.29.x material if that helps
<pedronis> mvo: zyga-ubuntu:  well on 14.04 systemd is not really pid 1, so not even sure when itself is started and what multi-user.target means there
<mup> PR snapcraft#1616 closed: store: guide to account creation upon login <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1616>
<pedronis> mvo: don't at least the proxy.*Â config make sense on classic too? or is the code to set them too dangerous there?
<sergiusens> kyrofa for when you come in snapcraft#1607 should be your priority for the week
<mup> PR snapcraft#1607: python plugin: use extracted pip <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1607>
<zyga-ubuntu> mvo: I added Before=snapd.service now, trying to reproduce
<zyga-ubuntu> oh!
<zyga-ubuntu> and on the 3rd boot it failed again!
<zyga-ubuntu> in super weird way where core didn't load but others did
<sergiusens> kyrofa kalikiana elopio every PR has a milestone now, DO NOT merge those marked 2.36 or we will never cut a release; focus on getting the 2.35 stuff finalized please
<mvo> zyga-ubuntu: uhh, so strange
<mup> PR snapd#4080 opened: snapctl: added long help to stop/start/restart command <Created by stolowski> <https://github.com/snapcore/snapd/pull/4080>
<kalikiana> sergiusens: Alright. 5 PRs to get in by the looks of it. Let's push those hard!
<pedronis> zyga-ubuntu: does systemd  own logs tells something about the order it did things?
<zyga-ubuntu> pedronis: no, things are very crippled
<zyga-ubuntu> pedronis: but let me look at one thing, it may indicate time
<zyga-ubuntu> so...
<zyga-ubuntu> core mounted on
<Saviq> mvo: hey, when you have a bit of time, can you point me at how you took care of the "autopkgtests" results in snapd's PRs?
<zyga-ubuntu>    Active: active (mounted) since czw 2017-10-26 11:16:39 CEST; 1min 51s ago
<zyga-ubuntu> snapd started on
<zyga-ubuntu>    Active: active (running) since czw 2017-10-26 11:16:41 CEST; 10min ago
<zyga-ubuntu> so core *was* mounted at the time snapd was started
<zyga-ubuntu> I added this to the bug report
<mvo> Saviq: sure, what do you mean with "took care of" ? how we added autpkgtests to the PRs?
<mvo> zyga-ubuntu: sounds like we need more debug in why it fails to find core then
<zyga-ubuntu> mvo: yes, I'm building snapd from 2.27.5 now
<Saviq> mvo: yes
<zyga-ubuntu> I'll add verbose logging to that part
<mvo> zyga-ubuntu: \o/
<zyga-ubuntu> where we add interfaces from snaps
<mvo> Saviq: I talked to martin pitt, however nowdays you will need to talk to laney or sil2100 afaik, then your projects gets whitelisted and you add a webhook
<Saviq> mvo: aha so it's a feature of autopkgtests, nice :0
<Saviq> .u.c, that is
<mvo> Saviq: yeah
<Saviq> mvo: thanks!
<mvo> yw
<ogra_> mcphail, i dont think the sheevaplug is ARMv7 ... (so same thing as RPi-1 ... Ubuntu wont run on it)
<mcphail> Thanks ogra_
<mwhudson> arm9 woo
<ogra_> i guess with the upcoming base snaps we could eventually have an armbian-base snap though ...
<ogra_> that would be v6
<ogra_> (though might not work if snapd in the core snap isnt also built for v6)
<mcphail> ogra_: thought this through with kyrofa last night and realised i was not on to a winner
<zyga-ubuntu> ok, so I have a logging build of 2.27.5
<zyga-ubuntu> no change apart from printfs in a few spots
 * zyga-ubuntu is in a reboot loop again
<zyga-ubuntu> wooooah
<zyga-ubuntu> mvo: I know what the bug is now!
<zyga-ubuntu> wow, that's golden :D
<zyga-ubuntu> mvo: you'll love this
<zyga-ubuntu> http://paste.ubuntu.com/25822364/
<zyga-ubuntu> so
<zyga-ubuntu> we load snaps _after_ loading connections *somehow*
<mvo> ohhh
<mvo> a race on our side, how strange
<zyga-ubuntu> yes
<zyga-ubuntu> but that's almost crazy
<zyga-ubuntu> I don't recall any goroutines or tasks there
<pedronis> load snaps?
<mvo> zyga-ubuntu: yeah
<zyga-ubuntu> pedronis: I updated the bug again
 * zyga-ubuntu looks at what could cause this
<mvo> zyga-ubuntu: silly question, could it still be snap.yaml missing for some reason? i.e. still the mount ordering race?
<zyga-ubuntu> no
<zyga-ubuntu> I verified that we started after the mount was ready
<zyga-ubuntu> I suspect that starting snapd itself can trigger this
<zyga-ubuntu> after everything else is settled
<zyga-ubuntu> I'm looking at the code to see what happens there, I'll verify this later
<mvo> zyga-ubuntu: ok, re mount unit - it might be the thing that system reports that it started the mount unit but the mount is not fully done when systemd returns and starts snapd or is that not a possibility?
<zyga-ubuntu> mvo: look at my last pastebin
<zyga-ubuntu> mvo: it's irrelevant because we do stuff on interfaces before we even loaded them
<zyga-ubuntu> mvo: and we load all of them correctly later
<mvo> zyga-ubuntu: ok
<mvo> zyga-ubuntu: could you please pastebin your diff to produce this debug output?
<zyga-ubuntu> no diff but I can pastebin the one file
<zyga-ubuntu> http://paste.ubuntu.com/25822405/
<zyga-ubuntu> that's all the modifications I did on top of the 14.04 package
<zyga-ubuntu> (maybe I could ask dpkg to get a diff somehow)
<mvo> ta
<zyga-ubuntu> sorry, IRL interrupts
<zyga-ubuntu> back now
<mvo> no worries
<zyga-ubuntu> so no goroutines in how overlord starts
<pstolowski> zyga-ubuntu, some quick feedback on your content interface pr
<zyga-ubuntu> I'll look at what can cause the first output
<zyga-ubuntu> pstolowski: thank you!
<zyga-ubuntu> (the one where we are missing the snaps and go setup stuff)
<zyga-ubuntu> mvo: hmmm
<zyga-ubuntu> mvo: I think I made a mistake
<zyga-ubuntu> mvo: there are two files, stdout and stderr
<zyga-ubuntu> so odering is not what appears in the log file
<zyga-ubuntu> I'll add more debug
<zyga-ubuntu> mvo: it's clear we are loading the three snaps
<zyga-ubuntu> and it's also clear that when reloadConnections is called we cannot find them
<zyga-ubuntu> although
<zyga-ubuntu> I just noticed this;
<zyga-ubuntu> Plugs:map[string]*snap.PlugInfo(nil),
<zyga-ubuntu> so they are indeed not present
<zyga-ubuntu> how can we load a yaml
<zyga-ubuntu> and not that !?
<zyga-ubuntu> this version does not have that fancy validation that's using backchannels, right?
<mvo> zyga-ubuntu: fwiw, I just unmount my /snap/*/* and added your debug info and ran snapd and I see similar behaviour, my debug info looks similar and I also get the "cannot connect plug..." messages
<zyga-ubuntu> mvo: down to the list of snaps but no plug/slot?
<zyga-ubuntu> mvo: something else is not showing an error message then
<zyga-ubuntu> mvo: maybe another case of logger.Noticef not working
<zyga-ubuntu> mvo: I know for a fact that it doesn't log in some cases (not sure what triggers this)
<zyga-ubuntu> mvo: maybe we fail earlier but don't show it
<mvo> zyga-ubuntu: I think what I see is similar, not sure if equal because I still haven't reproduce it on my box a single time :/
<zyga-ubuntu>                         logger.Noticef("cannot retrieve info for snap %q: %s", snapName, err)
<zyga-ubuntu> this is how we log that failure
<zyga-ubuntu> I'll patch logger to fmt.Printf just without any other fanciness
<mvo> zyga-ubuntu: +1
<mvo> zyga-ubuntu: so yeah, if I manually umount and restart snapd I think I see exactly what is happening here. but but I'm super puzzled that before=snapd.service does not work in the mount units
<zyga-ubuntu> mvo: let me paste my unit
<zyga-ubuntu> maybe I did it incorrectly
<zyga-ubuntu> (rebooting now)
<zyga-ubuntu> with new logger
<zyga-ubuntu> mvo: and BTW< the null loger is just MEH
<zyga-ubuntu> why did we even have that?
<zyga-ubuntu> early logger should be buffered
<zyga-ubuntu> and replayed after configuration
<zyga-ubuntu> ha
<zyga-ubuntu> I'm lucky
<zyga-ubuntu> boot and fail
<mvo> zyga-ubuntu: nice! looking forward for the pastebin
<mup> PR snapd#4075 closed: many: reorg things in preparation to make handling of the base url in store dynamic  <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4075>
<zyga-ubuntu> actually, nothing logged :/
<zyga-ubuntu> nothing more that is
<zyga-ubuntu> I see my logging patch being there bug nothing, no errors
<zyga-ubuntu> I wonder if this is a problem:
<zyga-ubuntu> ...failed snap epoch cannot be empty
<zyga-ubuntu> mvo: how are you running 14.04?
<mvo> zyga-ubuntu: how does your boot unit look like? where you added the "before" thing? could you please pastebin one
<mvo> zyga-ubuntu: in a qemu VM
<zyga-solus> mvo: SMP or UP?
<zyga-solus> mvo: I'll pastebin in a sec
<zyga-ubuntu> log from failure: http://paste.ubuntu.com/25822552/
<zyga-ubuntu> http://paste.ubuntu.com/25822556/
<mvo> j
<mvo> zyga-solus: defaults, so probably UP
<mvo> zyga-ubuntu: before= needs to go into the [unit]
<zyga-ubuntu> mvo: aha
<zyga-ubuntu> mvo: so...
<zyga-ubuntu> mvo: how can we load a yaml
<zyga-ubuntu> see the apps
<zyga-ubuntu> and not the plugs!?
<zyga-ubuntu> look at line 6
<mvo> zyga-ubuntu: I suspect it did not load the yaml, but maybe I am wrong
<mvo> zyga-ubuntu: try manually umount core
<mvo> zyga-ubuntu: and restart snapd
<zyga-ubuntu> apps are not in the snap state, are they?
<mvo> zyga-ubuntu: I need to check, I don't know off-hand
<zyga-solus> mvo: my qemu is SMP
<zyga-solus> mvo: maybe that's relevant
<zyga-solus> I added logging to snap yaml loading
<mvo> zyga-solus: I can try that. I also wonder if moving the before= helps
<zyga-ubuntu> http://paste.ubuntu.com/25822591/
<zyga-ubuntu> shttp://paste.ubuntu.com/25822590/
<zyga-ubuntu> http://paste.ubuntu.com/25822590/
<zyga-solus> mvo: look at this please
<zyga-solus> mvo: here canonical-livepatch did not load
<mvo> zyga-solus: in which one of the three?
<mvo> zyga-solus: aha, in the middle one, right?
<zyga-solus> mvo: just two
<zyga-solus> we didn't load canonical-livepatch
<zyga-solus> the other log is the same as before but with very verbose output when we load a yaml
<zyga-solus> snapstate.ActiveInfos() returned: []*snap.Info{(*snap.Info)(0xc82027c000), (*snap.Info)(0xc82027c780), (*snap.Info)(0xc82027cf00)}
<zyga-solus> this returns three infos
<zyga-solus> but only two yamls were loaded
<zyga-solus> a moment later we do something else that loads yamls
<zyga-solus> and then we load all three correctly
<zyga-solus> something is still not failing when meta/snap.yaml is absent
<zyga-solus> I'll look at snap manager now
<zyga-solus> Broken:"cannot read snap \"canonical-livepatch\": cannot find installed snap \"canonical-livepatch\" at revision 26
<zyga-solus> mvo: I think you were right
<zyga-solus> I'll move the Before thing now
<mvo> zyga-solus: yay, thank you, its a wild chase
<zyga-solus> mvo: we don't log that
<zyga-solus> mvo: because it goes into Broken: reason
<zyga-solus> I think we should be super vocal about broken snaps at startup
<mvo> yes
<mvo> *YES* :)
 * mvo tries the SMP thing
<zyga-solus> mvo: btw, this also means that sometimes machies may not reexec
<zyga-solus> mvo: which is crazy bad if you think about it
<mvo> zyga-solus: :( that is something we need to inspect too
<mvo> zyga-solus: I can reproduce it now I think with -smp 4 in my qemu :-D
<zyga-solus> woot
<zyga-solus> great
<zyga-solus> so far so good, no failures
<popey> I appear to have a corrupt core snap on my system. https://forum.snapcraft.io/t/snapcraft-unable-to-install-core-snap/2599/27
<popey>  pedronis helped debug this, but I wonder how I got in this state and how one gets out of it
<zyga-solus> popey: what is the sha of the snap?
<zyga-solus> mvo: no failures
<zyga-solus> mvo: so good news and bad news
<mvo> zyga-solus: sweet
<zyga-solus> mvo: good news is this is a simple fix
<mvo> zyga-solus: what is the bad news here :) ?
<zyga-solus> mvo: bad news is that we never rewrite mount units
<zyga-solus> mvo: we need to switch to EnsureFiles.. for that
<mvo> zyga-solus: meh, ok
<zyga-solus> and perhaps even restart snapd if we bot and found that we modified them (the function will tell us)
<zyga-solus> mvo: ok, I have no failures and I bet this is this now
<mvo> zyga-solus: thank you so much for trakcing this down. I pushed a trivial PR to fix it for new units, I get lunch now, lets talk at the standup about the rewriting
<zyga-solus> oh
<mup> PR snapd#4081 opened: systemd: run all mount units before snapd.service to avoid race <Created by mvo5> <https://github.com/snapcore/snapd/pull/4081>
<zyga-solus> I was just pushing :)
<zyga-solus> haha
<zyga-solus> ok
<zyga-solus> thank you
<mvo> zyga-solus: autsch, sorry
<zyga-solus> no worries, can you please edit the commit message to explain what we found\
<zyga-solus> I'll break too, I need to go to school (1st time, more later)
<zyga-solus> and pay for food there
<mvo> zyga-solus: sure, I update the commit message and force push
<zyga-solus> mvo: after lunch I can explore updating mount units in the field
<zyga-solus> mvo: thank you!
<zyga-solus> mvo: or get back to content
<zyga-solus> mvo: I wonder what to do with 4008
<zyga-solus> land it or wait until gustavo returns :/
<zyga-solus> mvo: please think about it, it blocks everything I do for layouts/content
<mvo> zyga-solus: yeah, lets talk priorities during the standup
<mvo> zyga-solus: thanks, I will
<popey> zyga-solus: how do i calculate the sha? (honestly)
<popey> (on 16.04)
<zyga-solus> I think it is tricky popey
<zyga-solus> naive command returns bad data
<zyga-solus> pedronis: ^
 * zyga-solus AFK
<pedronis> zyga-solus: that's what I asked him to do the sha is wrong
<pedronis> we already know that
<pedronis> zyga-solus: what IÂ don't know if the file is shorter or some bytes are different
<pedronis> I asked about that
<pedronis> he managed to download the same file again and get the right stuff
<pedronis> popey: the fix is easyish, stop snapd and any snap with daemons,  replace the file and reboot or start again... doesn't give us a clue how you got in that state though
<pedronis> worst scenarios would be some kernel bug that writes back to a read-only squashfs :/    we obvisouly don't do any kind of writing to .snap files after downloading them
<pedronis> popey: you could also try to see (before fixing) if you have other corrupt snaps
<popey> how would I test every snap?
<pedronis> popey: something like:  ls /var/lib/snapd/snaps/*.snap|xargs -n 1  snap info --verbose|grep -E "path|sha3-384"
<pedronis> give you all the hashes
<popey> sha3-384 doesn't exist on 16.04 AFAICT
<pedronis> ?
<pedronis> that's why I'm using snap info --verbose
<popey> oh duh, sorry
<popey> ok, so that dumps me out a bunch of snaps and sha3-384s, how do I know which are good/bad?
<pedronis> popey: try to see which ones gives a match with snap known ---remote  snap-revision snap-sha3-384=SHA3-384
<popey> that'll be fun with 90+ snaps installed :)
<popey> Thanks.
<popey> I could just switch channels then delete the broken snap I guess, and switch channel again to trigger a re-download?
<pedronis> well if you switch channel with refresh it will download something new
<pedronis> but it would be good to know if you have other broken snaps
<pedronis> it's a bit scary this issue
<popey> it didnt re-download
<popey> i switched and switched back earlier, it used the local snap
<kalikiana> sergiusens, kyrofa, elopio: FYI I'll be taking a late longer break in ~2h in place of my  lunch break, and working later tonight
<pedronis> popey:  this one liner might work to do the check:  ls /var/lib/snapd/snaps/*.snap|xargs -n 1  snap info --verbose|grep "sha3-384:"|cut -c10-|grep -Eo "[^ ]*"|xargs -n1 -I {}  snap known --remote snap-revision snap-sha3-384={}
<pedronis> popey: we do caching now, that might be related, mvo might know more
<Odd_Bloke> sergiusens: Well, the first . is, sure.  Any later dots would surely be fine?
<mvo> popey: what version of snapd are you running?
<ogra_> mvo, hrm
<ogra_> what happened to my PATH?
<ogra_> ogra@styx:~$ echo $PATH
<ogra_> /home/ogra/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin:/var/lib/snapd/snap/bin
<mvo> ogra_: you mean thta there are two /snap/bin in there now?
<ogra_> (where do the latter two entries come from all of a sudden ? this is xenial 2.28.5)
<ogra_> /etc/profile.d/apps-bin-path.sh has not changed
<mvo> ogra_: I would suspect https://github.com/snapcore/snapd/pull/3398/files#diff-ba91021c40c2949f09b89cbc853a17daR1 is the relevant PR, however why you have /var/lib/snapd/snap/bin is a bit strange
<mup> PR #3398: env: set XDG_DATA_DIRS for wayland et.al <Created by sergiusens> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3398>
<ogra_> ogra@styx:~$ locate snapd.sh
<ogra_> ogra@styx:~$
<ogra_> hmm
<ogra_> and definitely not in /etc/profile.d ...
<ogra_> mvo, hmm, that last file in that PR looks suspiciously as if nothing gets installed to /etc/profile.d anymore (packaging/ubuntu-16.04/snapd.install )
<ogra_> that smells wrong
<mvo> ogra_: https://github.com/snapcore/snapd/pull/3398/files#diff-f86ccdfbe771a0164e1e0c116db70386R174 should do that now
<mup> PR #3398: env: set XDG_DATA_DIRS for wayland et.al <Created by sergiusens> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3398>
<mvo> ogra_: (i.e. line 174)
<ogra_> mvo, thats debian/rules ... but the .install file explicitly doesnt install the dir
<ogra_> also thats a conffile ...
<ogra_> that would need some debhelper  postinst love, wouldnt it (to update the file on my disk)
<ogra_> ogra@styx:~$ cat /etc/profile.d/apps-bin-path.sh
<ogra_> # Expand the $PATH to include /snap/bin which is what snappy applications
<ogra_> # use
<ogra_> PATH=$PATH:/snap/bin
<ogra_> i surely dont have the new file ... so it is still a bit beyond me where that PATH comes from
<mvo> ogra_: check "wget https://launchpad.net/ubuntu/+archive/primary/+files/snapd_2.28.5_amd64.deb && (dpkg -c snapd_2.28.5_amd64.deb|grep etc/)" to see that the new file is in the package. what version of snapd are you running currenlty (apt list snapd and snap version) please?
<mvo> popey: if it is the download cache thing that broke stuff, could you please pastebin "sudo ls /var/lib/snapd/cache"
<mvo> popey: I wonder if that gives a hint
<mvo> popey: also, do you still have the snap that has the wrong hash? if so, could you please put it somewhere so that I can download it?
<popey> i do, one moment
<mvo> popey: thank you
<mvo> popey: and this all happend with 2.29~rc1 ?
<mvo> popey: or a different version?
<popey> core 3291
<popey> so yes, 16-2.29~rc1
<mvo> ta
<popey> mvo: http://people.canonical.com/~alan/core_3291.snap
<mvo> popey: ta
 * ogra_ shakes fist at his DSL
<ogra_> mvo, sorry, i got disconnected ... i dont have the new stuff in my /etc/profile.d here so i'm not sure where the additional PATH entries could come from ...
<ogra_> also, my deb is still at 2.27.5 ...
<mvo> popey: http://paste.ubuntu.com/25823191/ is what I found - I hexdumped both the snap download core --beta and your snap. the difference are 4 bytes (32bit) so I suspect corruption when writing to disk
<popey> wow
<mvo> ogra_: any hints in sudo grep -r var\/lib\/snapd\/snap\/bin /etc ?
<pedronis> mvo: remember that we check the hash before mounting, so this happened after the first use
<pedronis> mvo: the file was fine, and then later 4 bytes changed :/
<mvo> pedronis: hm, we check the hash during the download (the hash from the data streaming via the download). do we check the on-disk file as well again? I vaguely remember we discussed this
<pedronis> we do
<ogra_> GRMBL ... whats up with my DSL
<ogra_> mvo, did you get my last lines ?
<mvo> yeah, in this case its more alarming, the file was fine on disk at least once then
<mvo> ogra_: not sure, lsat that I wrote was: <mvo> ogra_: any hints in sudo grep -r var\/lib\/snapd\/snap\/bin /etc ?
<ogra_> <ogra_> mvo, sorry, i got disconnected ... i dont have the new stuff in my /etc/profile.d here so i'm not sure where the additional PATH entries could come from ...
<ogra_> <ogra_> also, my deb is still at 2.27.5 ...
<ogra_> thats the last i typed
<mvo> ogra_: yeah 2.28.5 is still in proposed
<ogra_> right
<ogra_> so i cant have the new stuff yet
<ogra_> though i do have these PATH entries ... let me try that grep
<ogra_> ogra@styx:~$ sudo grep -r var\/lib\/snapd\/snap\/bin /etc
<ogra_> ogra@styx:~$
<ogra_> nope
<ogra_> /etc/nevironment looks normal too ... nothing in /etc/bash* or so ...
<mvo> pedronis: you are right (of course :) - we download and then seek to zero and take the hash. then we rename. so the on-disk data was valid. unless of course we never read back from disk but instead linux just gave us what was in the memory cache. i.e. the bits on disk were wrong but because the file was fully in the cache we never read it back
<pedronis> mvo: we do in validate-snap
<pedronis> mvo: it's not a fun bug, unless popey has more general filesystem/disk issues
<mvo> pedronis: could it be the same problem though? I mean, could it be that because its all in the linux disk cache we did not detect that the on-disk bits are wrong?
<mvo> pedronis: i.e. linux itself never hit the disk to read it back in (because it was in the cache already)?
<pedronis> mvo: could be, but darkest fear would be some obscure bug when the kernel decide to write back to the squashfs for reason
<mvo> pedronis: yeah, that would be *wuuuarh* :)
<pstolowski> standup?
<mup> PR snapcraft#1641 opened: lxd: catch CalledProcessError in _container_run <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1641>
<zyga-solus> mvo: your PR fails tests
<zyga-solus> mvo: I think some tests failed (unit test)
<zyga-solus> does go test in systemd/ works?
<mvo> zyga-solus: checking
<pedronis> mvo:  this is topic: https://forum.snapcraft.io/t/snapcraft-unable-to-install-core-snap/2599 btw
<mvo> pedronis: thank you
<ryebot> snapcraft.io down?
<mvo> ryebot: looks like it :/
<ryebot> kk thanks
<mvo> ryebot: looks like more infra is affected :/
<ryebot> yeah, just failed to hit jujucharms as well
<ryebot> whee
<zyga-solus> darn
<zyga-solus> tests cannot run now
<mvo> weeeh :(
<zyga-solus> mvo: also does --resend cache core snap?
<mvo> zyga-solus: uh, I don't know
<ryebot> looks like things are back up
 * kalikiana back later
<mup> PR snapd#4077 closed: spdx: fix for WITH syntax, require a license name before the operator <Created by matiasb> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4077>
<mup> PR snapd#4071 closed: release: merge 2.29~rc1 changelog <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4071>
<mup> PR snapd#4061 closed: daemon, store: forward SSO invalid credentials errors as 401 Unauthorized responses <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4061>
<mup> PR snapd#4055 closed: daemon: generate a forbidden response message if polkit dialog is dismissed <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4055>
<mup> PR snapd#4050 closed: cmd/snap: tell translators about arg names and descs req's <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4050>
<mup> PR snapd#4053 closed: tests,po: sync translations from LP and add regression test for LP:1723974 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4053>
<mvo> yay, back to 25 open PRs!
<mvo> jdstrand: a second review for 4054 would be great. I applied your feedback
<jdstrand> mvo: ok
<jdstrand> mvo: is the xdg-settings one ready for me to review again?
<jdstrand> mvo: also, I'm going to have another policy updates PR that I'd like to get into 2.29. if I submit to master and 2.29, will that be a problem?
<mvo> jdstrand: the xdg-settings one is not yet ready, need to address the open point about info disclousure
<jdstrand> mvo: 4054 approved. did you see my question about 2.29?
<mvo> jdstrand: I have not seen your question
<mvo> jdstrand: 4060 is also ready (review points addressed)
<jdstrand> 09:25 < jdstrand> mvo: also, I'm going to have another policy updates PR that I'd like to get into 2.29. if I submit to master and 2.29, will that be a problem?
<jdstrand> 4060 was already on my list for today. let me take a look now
<pedronis> jdstrand: what impact on preexisting snaps will that policy change have?
<jdstrand> pedronis: only more access
<mvo> jdstrand: if you submit to master and tag 2.29, that should be fine
<jdstrand> mvo: ok thanks. need to get out from under PR reviews and forum discussions, then will submit. striving for eod tomorrow
 * jdstrand crosses fingers
<mvo> ta
<mvo> jdstrand: no worries we have still some critical 2.29 prs pending so no worries
<jdstrand> mvo: 4060 done (note, see my comment on missing assert)
<mvo> jdstrand: ta
 * mvo takes a short break while waiting for tests
<pstolowski> pedronis, mvo added help for --long options to 4080, can you take a quick look and let me know wdyt?
<pedronis> in a bit
<pedronis> pstolowski: commented
<pedronis> I have no idea if it's ok to refer to systemd there or not
<pstolowski> pedronis, thanks, I've just fixed caitalization.
<pstolowski> pedronis, yeah, me neither, but it's difficult not to since we depend so much on i
<pstolowski> *it
<pstolowski> mvo, your thoughts on that? ^
<zyga-solus> re
<zyga-solus> I'm still AFK, working with kids
<zyga-solus> jdstrand: hey, how's life?
<zyga-solus> jdstrand: no updates from me yet, I think we will see a PR tomorrow though
<mup> Bug #1727787 opened: segmentation fault <Snappy:New> <https://launchpad.net/bugs/1727787>
<gsilvapt> elopio, you around=
<gsilvapt> s/=/?
<elopio> gsilvapt: yes. Hello
<gsilvapt> Can I talk to you via pvt?
<gsilvapt> elopio ^ (I can forgetting to reference people, sorry :P )
<elopio> gsilvapt: sure.
<jdstrand> zyga-solus: hey, things going fine here. just trying to get through the PR reviews and forum discussions. how about you?
<zyga-solus> jdstrand: trying to catch up with my son's classes and all the things he needs to learn in this school; otherwise pondering about overlayfs, I may have made a mistake and not realized it
<zyga-solus> jdstrand: but no conclusions yet, I just realized something but I didn't finish investigating
<mup> Bug #1727787 changed: segmentation fault <Snapcraft:New> <https://launchpad.net/bugs/1727787>
<kyrofa> snappy-m-o, autopkgtest 1583 xenial:amd64
<snappy-m-o> kyrofa: I've just triggered your test.
<kyrofa> elopio, I've seen this error several times now: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-snapcraft-daily/xenial/amd64/s/snapcraft/20171025_182047_d2762@/log.gz
<kyrofa> plainbox test failing, unable to find pyramid
<kyrofa> And ROS ones, looks like
<elopio> Mmm, let me see...
<kyrofa> elopio, wait, no-- plainbox has a valid-looking match error
<kyrofa> Like something changed out from under us
<kyrofa> 2013.com.canonical.plainbox::collect-manifest versus no 2013
<kyrofa> But the ROS ones suddenly can't find pyramid
<kalikiana> kyrofa: I realized I hadn't actually approved snapcraft#1637 but this is good to go
<mup> PR snapcraft#1637: repo: add elementary to deb distros <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1637>
<jdstrand> stgraber: hey, I see this denial: apparmor="DENIED" operation="open" profile="snap.lxd.lxc" name="/var/lib/snapd/hostfs/usr/lib/os-release" pid=10047 comm="snap-exec" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<jdstrand> stgraber: you can fix that by plugging 'system-observe' in the lxc command
<nanodrone> is snappy installable on puppylinux?
<stgraber> jdstrand: why would I need that though?
<stgraber> jdstrand: snap.lxd.lxc runs through "aa-exec -p unconfined"
<stgraber> jdstrand: the line above seems to indicate that it's "snap-exec" which is attempting to read that file, not our script, so it'd point to a profile issue for snap-exec rather than lxc
<elopio> kyrofa: pyramid is not on debian/tests/control for snapstests.
<elopio> What I don't know is what changed to require it now.
<kyrofa> elopio, huh, no kidding
<elopio> kyrofa: you are adding a dependency on the integration tests with that skip_unless_codename
<kyrofa> elopio, ohhhhhhhh
<kyrofa> Dangit!
<elopio> to be honest, I dislike the skip annotations. But, with my refactor on the suites, you would be able to put it in snapcraft/tests/skips, and just import that.
<elopio> actually, you could do that right now, no need to wait.
<kyrofa> elopio, you mean you don't like the decorators?
<elopio> for the plainbox thing, I'll report a bug for joc to see. It's late for him, and I'm not sure if we can just update the expected result.
<elopio> kyrofa: yes, the decorators.
<kyrofa> elopio, you'd rather be using self.skipTest or whatever in the body of the test?
<kyrofa> I feel like that adds code to the test that has nothing to do with the test
<elopio> that is more readable to me. I'm not strongly opposing to the decorators, I just don't like them.
<kyrofa> elopio, so to be clear, you want me to create a new snapcraft/tests/skips.py and put the skip code in there, then import from there for both the integration_tests and the units?
<elopio> kyrofa: yes, I think that's the future. Things common will go in there, things specific will go in snapcraft/tests/unit or snapcraft/tests/integration.
<kyrofa> elopio, good deal
<kyrofa> elopio, and yeah, that was my favorite part of your refactor
<elopio> my favorite part is when we get rid of snaps_tests completely. I will use this chance to move the plainbox test.
<elopio> kyrofa, can you land snapcraft#1630 ?
<mup> PR snapcraft#1630: tests: allow to select a suite when running autopkgtests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1630>
<elopio> I want to start experimenting with the adt-lxd.
<kyrofa> elopio, sure thing-- done
<elopio> :D
<mup> PR snapcraft#1630 closed: tests: allow to select a suite when running autopkgtests <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1630>
<mup> PR snapcraft#1637 closed: repo: add elementary to deb distros <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1637>
<kalikiana> 3 more to go til we can release :-D https://github.com/snapcore/snapcraft/pulls?q=is%3Aopen+is%3Apr+milestone%3A2.35
<kyrofa> kalikiana, still need autopkgtests to pass...
<kyrofa> plainbox seems busted
#snappy 2017-10-27
<mup> PR snapcraft#1642 opened: tests: move the plainbox test to the integration suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1642>
<mup> PR snapcraft#1643 opened: [WIP] tests: run daily autopkgtest in travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1643>
<zyga-ubuntu> good morning
<mvo> zyga-ubuntu: good morning !
<mvo> zyga-ubuntu: master is broken currently :/ https://travis-ci.org/snapcore/snapd/builds/293175118#L5810 - looks like something for pawel
<mup> PR snapcraft#1644 opened: lxd: fix the push in container builds <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1644>
<mup> PR snapd#4079 closed: daemon: allow Polkit authorization to cancel changes <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4079>
<mup> PR snapd#4082 opened: cmd/snap: tell translators about arg names and descs req's (2.29) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4082>
<mup> PR snapd#4083 opened:  snap-{confine,seccomp}: make @unrestricted fully unrestricted (2.29) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4083>
<mup> PR snapd#4084 opened: interfaces: clean system apparmor cache on core device (2.29) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4084>
<Guest63697> Hello currently working on ubuntu core 16 need to build qt application which works on postgres database do
<Guest63697> on need to create a separate snaps for it
<Guest63697> and is any document for qt and postgres
<zyga-solus> Guest63697: hello
<zyga-solus> Guest63697: I don't know about postgres but there's something for a kiosk qt app
<zyga-solus> Guest63697: my suggestion would be to get postgress up and running
<zyga-solus> Guest63697: and then move on to qt
<zyga-solus> Guest63697: also, not sure why you want separate snaps for that but that's ok, you will just need to use content interface to share data/sockets so that they can talk to each other
<mup> PR snapd#4085 opened:  debian: do not build static snap-exec on powerpc (2.29) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4085>
<Guest63697> zyga-solus: Hi for more details i am currently working on dell edge gateway 5000 with ubntu core16 installd
<zyga-solus> Guest63697: right, you can prototype this on a typical ubuntu system (16.04 is ideal) and then just install the resulting snap on the device
<zyga-ubuntu> mvo: o, looking
<Guest63697>  zyga-solus: I am new to the core os i just tried running hello world application so needed jus help to move my existing application to core :)
<zyga-ubuntu> mvo: aha, I see that service management test failed
<zyga-solus> Guest63697: I suggest you start by learning about snapcraft, using snaps on your 16.04 desktop/laptop (classic system) and playing with your core system with a few snaps
<zyga-solus> Guest63697: build a hello-world.c from source, see how that looks like
<zyga-solus> Guest63697: then look at what it would take to run postgres
<zyga-solus> Guest63697: or separately at kiosk-style Qt (this is documented on the forum)
<zyga-solus> Guest63697: in the end all the pieces will come together and you should get it to work fine
<zyga-solus> Guest63697: stick around, join the forum, experiment. read, and ask :)
<zyga-solus> oh, and welcome :-)
<zyga-ubuntu> mvo: I'll ignore that master failure for now unless pawel comes around and asks for help
<zyga-ubuntu> mvo: I need to finish apparmor changes for overlayfs
<zyga-ubuntu> mvo: and expand the spread tests for that
<Guest63697>  zyga-solus: I have been searching on the web a multiple links can you please suggest any useful and just for curiosity should i put all the application and its dependecy under one snp
<zyga-solus> Guest63697: try forum.snapcraft.io
<zyga-solus> Guest63697: we also have a snapcraft tutorial on ...
<zyga-solus> https://docs.snapcraft.io/build-snaps/your-first-snap
<mvo> zyga-ubuntu: yeah, just a heads up about the failure not a request-for-action :)
<zyga-solus> note that you can use a classic "regular" ubuntu system for all of this
<zyga-solus> that's the beauty of snaps :)
<Guest63697>  zyga-solus: sure thanks
<zyga-solus> in the end you just deploy it on core
<zyga-ubuntu> mvo: ack, thank you :)
<mup> PR snapd#4081 closed: systemd: run all mount units before snapd.service to avoid race <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4081>
<zyga-ubuntu> mvo: I was asking my son if he would like to wake up at 3AM tomorrow to look at sunirse in the nearby fields, we could take some photos of the birds nesting there
<zyga-ubuntu> mvo: I was talking about this the whole week
<zyga-ubuntu> mvo: and while earlier he was "yeah dad, that would be fun"
<zyga-ubuntu> mvo: today he said "but if we stay at home, can we sleep longer"
<zyga-ubuntu> mvo: I think I lost that one :)
<zyga-ubuntu> mvo: if you want I can work on mount unit refresh later today
<zyga-ubuntu> mvo: I'd like to think how to approach that: as a fixup type thing or as a change in how we maintain them
<mup> PR snapd#4086 opened: snap-confine: increase sanity_timeout to 6s <Created by mvo5> <https://github.com/snapcore/snapd/pull/4086>
<mvo> zyga-ubuntu: it seems conceptually cleaner to do the later
<zyga-ubuntu> mvo: I agree but then my conclusion was, if this is something that will run in ensure (that is, all the time)?
<zyga-ubuntu> mvo: and if so, what should we do after we notice that the files were chaned
<zyga-ubuntu> mvo: I was thinking that this is where it gets hairy
<zyga-ubuntu> mvo: we could log "discrepancy in unit %q"
<zyga-ubuntu> mvo: and do nothing at all (for this specific case that's fine)
<zyga-ubuntu> mvo: but it feels like a stretch of the concept
<zyga-ubuntu> mvo: we also don't have similar ensure for interfaces
<zyga-ubuntu> mvo: but
<zyga-ubuntu> mvo: if we actually do this then the system is self-healing in a nice way
<mvo> zyga-ubuntu: well, if its a one-off thing we should handle it like this and not complicate things, just a "fixupMountUnits()" somewhere
<zyga-ubuntu> mvo: ^ commented on the PR, I think you need to change a few tests too
<mvo> zyga-ubuntu: 2.29 is super close this healing thing may not even make it
<zyga-ubuntu> mvo: yes, I agree we absolutely have to have something for 2.29, so a fixup is good
<mvo> zyga-ubuntu: aha, thanks. we have two autopkgtest failures where the alarm goes of
<zyga-ubuntu> mvo: maybe 2.31 target for generic healing
<mvo> zyga-ubuntu: 2.29 is super close, candiate targeted monday so it may not even make it
<mvo> zyga-ubuntu: but if it does even better
<mvo> zyga-ubuntu: I plan ~rc2 today
<mvo> zyga-ubuntu: and hopefully that is the last one
<zyga-ubuntu> mvo: for the tests we need "make check" to pass
<zyga-ubuntu> mvo: what about 4008?
<mvo> zyga-ubuntu: its still hanging there, I wanted to see where things are at lunchtime, if everything else is in and ready +1
<mvo> zyga-ubuntu: thanks, I adjusted the test now. I did a force push to make it easier to cherry-pick (either way)
<zyga-ubuntu> mvo: no worries, I approve of --force ;D
<mup> PR snapd#4087 opened: cmd: downgrade log message in InternalToolPath to Debugf() <Created by mvo5> <https://github.com/snapcore/snapd/pull/4087>
<mvo> pstolowski: hey, good morning. you have two 2.29 targeted PRs, could you please create a branch based on upstream/release/2.29 and cherry-pick your commits to it so that we merge to 2.29?
<mvo> pstolowski: also master is failing right now
<pstolowski> mvo, sure
<pstolowski> mvo, what is failing?
<kalikiana> o/
<Guest63697>  zyga-ubuntu: I am trying run the qt4 text editor example on from snapcraft github it is giveing error as application cannot connect to x server
<zyga-solus> Guest63697: on core or on classic?
<Guest63697>  zyga-ubuntu: on core
<zyga-solus> on core there's no display stack
<zyga-solus> you need to look at qt + kiosk mir demos for that
<mvo> pstolowski: sorry for the delay, I was distracted: master is broken currently :/ https://travis-ci.org/snapcore/snapd/builds/293175118#L5810
<mvo> pstolowski: maybe racy?
<mvo> pstolowski: line 5810 (takes forever to load for me :/
<mvo> pstolowski: maybe https://travis-ci.org/snapcore/snapd/builds/293175118#L5758 works better?
<mvo> pstolowski: the gist is http://paste.ubuntu.com/25828740/
<pstolowski> mvo, thank you
<pstolowski> mvo, oh damn.. this indeed might be racy. i wonder what to do about that test :(
<mvo> pstolowski: sleep 10 - what we always do (kidding of course)
<pstolowski> i guess we need a function that tries a couple of times until a timeout passed, then it gives up
<mvo> pstolowski: yeah, I think that is sensible
<pstolowski> mvo, ok, i'll work on this, sorry about the problem
<mvo> pstolowski: no worries, thank you
<pstolowski> mvo, when cherry-picking for 2.29, is it ok to squash?
<mvo> pstolowski: if it is merge in master already then please cherry-pick individually otherwise the merge of 2.29 into master will be infected with conflicts
<mvo> pstolowski: if it is not merged yet the easiest is to squash merge when merging into master to get any easy cherry-pick
<pstolowski> mvo, ack
<pedronis> mvo: hi,  I'm trying to finish something not to lose state, let's talk about ignore-validation after lunch
<mvo> pedronis: +1
<mup> PR snapd#4082 closed: cmd/snap: tell translators about arg names and descs req's (2.29) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4082>
<ackk> is there a way for a snap to know the underlying os version? (not the core snap one)
<zyga-solus> ackk: mmm, no I don't think there is
 * zyga-ubuntu -> coffee
<mvo> pstolowski: while you fix the test I can help with the 2.29 cherry-picks for 4070 - we need this for 2.29, right? its a bugfix aiui?
<mup> PR snapd#4088 opened: snapctl: cherry pick service commands changes <Created by stolowski> <https://github.com/snapcore/snapd/pull/4088>
<pstolowski> mvo, ^
<pstolowski> mvo, yes, it's kind of a bugfix
<pstolowski> mvo, nb, i think 4080 is not very important for 2.29
<mvo> pstolowski: thank you
<mvo> pstolowski: what branches does 4088 cover? i.e. which of the previous PRs that were tagged 2.29?
<pstolowski> mvo, 4070 and 4065 (the latter for prerequisite for the former anyway)
<zyga-solus> oooh
<zyga-solus> man
<zyga-solus> after using vim for what, 20 years
<zyga-solus> I learned what "x" is for when in directory listing mode
<mvo> pstolowski: do we need to cherry-pick b693557 in 4088 as well? its the last commit in 4070?
<pstolowski> mvo, oh yes, that a test only, but yes. done
<mvo> ta
<ackk> zyga-solus, do you think that adding an interface for allowing that would be accettable?
<zyga-solus> ackk: not sure how such an interface would look like
<zyga-solus> ackk: why do you need this information?
<zyga-solus> ackk: and how would you expect to read it?
<ackk> zyga-solus, for an app to expose the information. perhaps reading /etc/os-release from the host (possibly linked somewhere else)
<zyga-solus> ackk: most apps I know of don't read or expose /etc/os-release, I'm sure there must be some special cases though that's why I'd like to understand the need better
<zyga-solus> ackk: /etc/os-release says you are on ubuntu core
<ackk> yeah
<pstolowski> mvo, ok, i've a tentative fix for test race, let's see how travis likes it, i've never experieced it locally
<mvo> pstolowski: great
<pstolowski> and i hope it's a race, nothing else
<mvo> pstolowski: looking forward to it, my top priority for today is to get the 2.29 branches in and release 2.29~rc2 to beta so that it can go to candidate monday. having master in good shape is vital .)
<mvo> pstolowski: yeah
<zyga-solus> man, it's cold today
<mup> PR snapd#4088 closed: snapctl: cherry pick service commands changes <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4088>
<mup> PR snapd#4089 opened: tests: wait for service status change & file update in the test to avoid races <Created by stolowski> <https://github.com/snapcore/snapd/pull/4089>
<pstolowski> mvo, ^
<mvo> pstolowski: thanks a bunch, lets see if travis is happy with this
<zyga-solus> ok
<zyga-solus> fingers crossed
<zyga-solus> mvo: so just to confirm, 4008 should be squash merged today
<mvo> zyga-solus: if we want it in, yes
<zyga-solus> mvo: ok, please tell me when
<kalikiana> zyga-solus: ackk /etc/os-release is already exposed in apparmor afair
<zyga-solus> kalikiana: yes but it doesn't show you the real /etc/os-release file
<zyga-solus> kalikiana: it shows the one from the core snap
<kalikiana> zyga-solus: Hmm classic snaps can see the real file... but I guess in that case apparmor doesn't apply anyway
<zyga-solus> kalikiana: can you show me how you determined that?
<zyga-solus> kalikiana: I just saw the file from core snap on a 16.04 test vm
<kalikiana> zyga-solus: snapcraft can read the file. From checking interfaces/apparmor/template.go in snapd sources it's not obvious, though, if that applies or not
<kalikiana> To me at least
<zyga-solus> kalikiana: I didn't say that it is not unreadable, it *is* readable
<zyga-solus> kalikiana: I said that it should almost always contain the /etc/os-release file from the core snap or other base snap that is used by a given app snap
<zyga-solus> kalikiana: thus when read on fedora it will not say "fedora"
<zyga-solus> kalikiana: it will consistently say "ubuntu core" or whatever the base snap says
<kalikiana> zyga-solus: Right. I didn't mean to contest that... maybe bad wording on my part
<zyga-solus> kalikiana: no worries, I just wanted to explain what I meant earlier :)
<kalikiana> zyga-solus: I think it technically makes sense so long as you have no access to the underlying system. Tho it would make something like a user agent that's used for statistical purposes impossible
<mup> PR snapd#4089 closed: tests: wait for service status change & file update in the test to avoid races <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4089>
<zyga-solus> kalikiana: yes, I agree
<zyga-solus> technically we have the real file in /var/lib/snapd/hostfs/{etc,lib}/os-release but it is not readable in strictly confined apps
<mup> PR snapd#4087 closed: cmd: downgrade log message in InternalToolPath to Debugf() <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4087>
<zyga-solus> hrm
<zyga-solus> some good and some bad news
<zyga-solus> let's make a PR
<jdstrand> zyga-solus, kalikiana: /var/lib/snapd/hostfs/{etc,lib}/os-release is actually allowed via system-observed
<jdstrand> system-observe*
<mup> PR snapd#4090 opened: interfaces/mount: exspose mount.{Escape,Unescape} <Created by zyga> <https://github.com/snapcore/snapd/pull/4090>
<zyga-solus> jdstrand: oh!
<zyga-solus> jdstrand: that's neat, I didn't know
<zyga-solus> (and didn't check apparently :)
<zyga-solus> mvo: I'm merging 4008 (squash)
<zyga-solus> mvo: speak now to stop me please
<zyga-solus> mvo: 3...
<mup> PR snapd#4086 closed: snap-confine: increase sanity_timeout to 6s <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4086>
<zyga-solus> mvo: 2...
<zyga-solus> mvo: 1...
<zyga-solus> merging
<mup> PR snapd#4008 closed: cmd/snap-update-ns: create missing mount points automatically <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4008>
<mup> PR snapd#4060 closed: interfaces: clean system apparmor cache on core device <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4060>
<mup> PR snapd#4091 opened: cmd/snap-update-ns: allow fault injection to provide dynamic result <Created by zyga> <https://github.com/snapcore/snapd/pull/4091>
<mvo> zyga-solus: ok, no worries
<zyga-solus> mvo: you can cherry pick for 2.29
<kalikiana> jdstrand: Does system-observed change which one /etc/os-release points to? Is it still the one from the core snap?
<zyga-ubuntu> kalikiana: no, it doesn't
<mup> PR snapd#4069 closed: debian: do not build static snap-exec on powerpc <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4069>
<mup> PR snapd#4092 opened: cmd/snap-update-ns: allow Change.Perform to return changes <Created by zyga> <https://github.com/snapcore/snapd/pull/4092>
<mup> PR snapd#4080 closed: snapctl: added long help to stop/start/restart command <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4080>
<mup> PR snapd#4085 closed:  debian: do not build static snap-exec on powerpc (2.29) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4085>
<mup> PR snapd#4083 closed:  snap-{confine,seccomp}: make @unrestricted fully unrestricted (2.29) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4083>
<mup> PR snapd#4084 closed: interfaces: clean system apparmor cache on core device (2.29) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4084>
<mvo> zyga-ubuntu: just to double check - freezeSnapProcess() is now called everytime snap-update-ns is run, right? with 4008?
<zyga-solus> yes
<cachio> kenvandine, hey
<zyga-solus> mvo: I have one more for 2.29.2
<mvo> zyga-solus: which one?
<zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/4093
<mup> PR #4093: cmd/snap-update-ns: initialize logger <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4093>
<zyga-ubuntu> just one liner
<zyga-ubuntu> but it will help us in case 4008 explodes in the field
<kenvandine> cachio, hey
<mvo> zyga-ubuntu: ok
<mup> PR snapd#4093 opened: cmd/snap-update-ns: initialize logger <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4093>
<cachio> kenvandine, I copied the approach you use for the calculator
<cachio> kenvandine, but still it can't access to the gsettings schema
<cachio> I it copying the schema to the correct place
<kenvandine> cachio, can i get a checkout of your yaml?  I'll try it myself
<cachio> kenvandine, https://github.com/sergiocazzolato/snapd/tree/tests-interface-gsettings/tests/lib/snaps/test-snapd-gsettings
<kenvandine> cachio, i have a bunch of snaps all using gsettings
<cachio> kenvandine, I know
<jdstrand> kalikiana: system-observe doesn't change the system. you can either look at /etc or /usr/share/... for what the os-release is for the snap's runtime (you have access to this by default), or you can plugs system-observe and look in hostfs to see what the host system is
<jdstrand> zyga-solus: re new> yes, it is a recent update
<kenvandine> cachio, oh... you aren't using the desktop helpers
<kenvandine> i bet that has something to do with it
<cachio> kenvandine, how should I add it?
<kenvandine> the desktop helpers probably tweak the schema env
<kenvandine> after: [desktop-gtk3]
<kenvandine> for example
<kenvandine> and command: desktop-launch check-schema
<kenvandine> or you can look at the launcher script and reproduce that in your own script
<cachio> kenvandine, ok, I'll try that
<kenvandine> that helpers sets lots of env needed for desktop stuff
<cachio> kenvandine, thanks
<kenvandine> np
<kalikiana> jdstrand: Alright, that makes sense, thanks for clarifying! I guess even in that case it's best to have both available and not just change behavior.
<mup> PR snapcraft#1625 closed: tests: use the snapcraft snap for integration tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1625>
<zyga-ubuntu> jdstrand: hey
<zyga-solus> jdstrand: do you have 15 minutes to consider and answer a question?
<zyga-solus> jdstrand: it would require you to have spread (local or remote) and checkout my branch, run it, get a denial and see what you think about it
<zyga-solus> jdstrand: I suspect you know the answer without running it
<zyga-solus> jdstrand: but I wanted to check
<cachio> kenvandine, works with the desktop-lunch
<cachio> launch
<om26er> popey: hey! was looking at this yaml a few days ago but couldn't find it today. Do you have a copy ? https://github.com/snapcrafters/pycharm-community/blob/master/snap/snapcraft.yaml
<cachio> thanks
<om26er> (need that yaml file to snap a related project)
<kenvandine> cachio, cool
<popey> hi om26er
<popey> i deleted the repos from snapcrafters because it's owned upstream now. I have a backup though, can pastebin if you need it?
<om26er> popey: yes, that would do.
<popey> http://paste.ubuntu.com/25830418/
<mup> PR snapd#4094 opened: tests: cherry pick the fix for services test into 2.29 <Created by stolowski> <https://github.com/snapcore/snapd/pull/4094>
<pstolowski> mvo, ^
<mvo> pstolowski: ta!
<pstolowski> mvo, the changes to help docs seem to already be there in 2.29, guess you merged them
<mvo> pstolowski: yeah, I cherry picked
<pstolowski> cool, thanks
<om26er> popey: I would need the .desktop file as well :)
<popey> http://paste.ubuntu.com/25830453/
<popey> sorry
 * zyga-solus lunches
<mup> PR snapd#4093 closed: cmd/snap-update-ns: initialize logger <Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4093>
<zyga-solus> thank you :)
<pedronis> mvo: is Chi-paca supposed to be back Monday?
<mvo> pedronis: AFAIK he is
<mvo> zyga-solus: thank *you* and cherry-picked into 2.29
<mup> PR snapd#4095 opened: debian: make packaging/ubuntu-14.04/copyright a real file again <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4095>
<mattyw> hey folks, is it possible to have private snaps using the public store?
<om26er> when will build.snapcraft respect `architectures` config ?
<jdstrand> kenvandine: hey, fyi I noticed an issue with the gedit snap
<ogra_> om26er, https://forum.snapcraft.io/t/snapcraft-build-on-hint-for-builders/939
<kenvandine> jdstrand, oh?
<noise][> mattyw: yes, but just keep in mind a private snap is just for the publisher and collaborators, e.g. for QA prior to release. Collaborators have full read-write access to the snap.
<jdstrand> kenvandine: if you go to open a file and get the gtk3 file chooser, in the upper left the 'Documents', etc don't work as expected because they are expecting those folders to be under SNAP_USER_DATA (ie, what HOME is set to)
<mattyw> noise][, is it possible to define who the collaborators are - like if I have a snap that I just want people in my team to have access to?
<jdstrand> kenvandine: the Documents, etc in the lower left all work fine
<kenvandine> jdstrand, yeah, i haven't figured out what to do with that
<kenvandine> portals will help
<noise][> mattyw: yes - on your snap details page on dashboard.snapcraft.io, there's a "Collaboration" link in the side nav
<jdstrand> kenvandine: it should. another idea is to symlink from SNAP_USER_DATA/Documents to /home/user/Documents
<kenvandine> jdstrand, oh... we could do that in the helpers
<kalikiana> kyrofa: when you're up, perhaps we can chat about snapcraft#1641 briefly?
<mup> PR snapcraft#1641: lxd: catch CalledProcessError in _container_run <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1641>
<jdstrand> right
<jdstrand> zyga-solus: can you just show me the denial, the spread test and the branch of the code?
<kyrofa> kalikiana, let me take a look here...
<kenvandine> jdstrand, i'll take a swing at that
<kyrofa> kalikiana, alright, want to HO real quick?
<zyga-solus> jdstrand: ha, no denial, this is overlayfs
<kalikiana> kyrofa: Yeah, gimme 1 minute to fetch my headset
<kyrofa> Sure thing
<zyga-solus> jdstrand: I can show you the branch if you want to try
<zyga-solus> one sec
<kenvandine> jdstrand, actually the helpers run from within the snap and don't have access to $HOME
<zyga-ubuntu> jdstrand: fetch my remote please, go to feature/transparent-overlayfs and pop one patch off, that is go to bc687e812a693afe532f51803645cc41d027de00 - then run SPREAD_DEBUG_EACH=0 spread -debug -v -reuse qemu:ubuntu-16.04-64:tests/main/interfaces-content-mkdir-writable:snap
<kyrofa> kalikiana, haha you're ringing my phone, hold on, I need to learn how to use hangouts
<kalikiana> kyrofa: https://hangouts.google.com/hangouts/_/ygq3wu36wzebfjotr7gdj7ofhye
<kenvandine> we'd have to do some mangling of the paths like in $SNAP_USER_DATA
<kalikiana> kyrofa: Oh, heh. Wasn't my intention. Just created a hangout ( I think...)
<kyrofa> Ah excellent
<zyga-ubuntu> jdstrand: I'm running it here
<jdstrand> kenvandine: gedit plugs the home interface
<kenvandine> yes
<kenvandine> but we don't have proper $HOME i meant
<kenvandine> so we would need to strip out part of the path
<kenvandine> doable though
<jdstrand> use getent. there is already stuff in there
<kenvandine> oh cool
 * zyga-ubuntu is a bit preoccupied and worried about Spain vs Catalonia just now; Catalonia has just declared independence 
<jdstrand> kenvandine: getent passwd $UID | cut -d ':' -f 6
<kenvandine> jdstrand, yeah, thanks!
 * kenvandine always forgets about getent :)
<jdstrand> zyga-ubuntu: you asked me to look at something with overlayfs. what is it you want me to look at?
<zyga-ubuntu> jdstrand: yes
<zyga-ubuntu> jdstrand: that's exactly that branch and that is exactly what I'm running as well
<jdstrand> note, this is not going to take only 15 minutes if you are asking me to verify that it is going to dtrt with apparmor
<zyga-ubuntu> jdstrand: to ensure we're seeing the same thing
<zyga-ubuntu> 2017/10/27 14:31:17.262504 main.go:154: 	cannot apply mount change mount (/snap/test-snapd-content-advanced-slot/x1/source /snap/test-snapd-content-advanced-plug/x1/target none bind 0 0): cannot open path segment "x1" (got up to "/snap/test-snapd-content-advanced-plug"): permission denied
<zyga-ubuntu> jdstrand: this is the error I'm seeing
<zyga-ubuntu> jdstrand: and there are no denials
<jdstrand> istr something with overlayfs and private mounts
<zyga-ubuntu> jdstrand: now in that same branch there's one more patch that lets this test pass
<zyga-ubuntu> jdstrand: it makes snap-update-ns unconfined
<zyga-ubuntu> jdstrand: note: when s-u-n is unconfined it can complete the work and then let regularly confined apps work
<zyga-ubuntu> jdstrand: I'm trying to understand if the failure I'm seeing is a result of missing apparmor support for overlayfs
<jdstrand> zyga-ubuntu: I'll try the spread test, but note, I'm not keen on spending a lot of time on overlayfs until niemeyer or mvo say that the change in direction is what we want in the PR. I laid out many questions about this and didn't get a response that pertains to them. morphis then followed up but no response
<zyga-ubuntu> jdstrand: I suspect the answer is "yes"
<zyga-ubuntu> jdstrand: gustavo strongly wants me to pursue this, I'll review your questions and ensure they are all answered
<jdstrand> s/in the PR/in the forum/
<zyga-ubuntu> jdstrand: ack
<jdstrand> zyga-ubuntu: that is a complete 180 in terms of direction wrt overlayfs. it has always been "no, because it can't be backported"
<jdstrand> tyhicks: fyi ^
<jdstrand> ratliff: ^
<jdstrand> zyga-ubuntu: you mentioned something about a fallback to !overlayfs. if that is supposed to work as well as (from the pov of the user) overlayfs, why not just focus on that instead? you can answer that in the forum (it was one of my questions)
<kalikiana> fg
<kalikiana> Oops
<morphis> zyga-ubuntu: this means we will always have two different implementations inside snapd for the layouts feature?
<kenvandine> seb128, the user-dirs.defaults directories, are the actual directory names translated?  Or just the presentation of them?
<kenvandine> s/are the/are they
<seb128> kenvandine, the actual dirs
<kenvandine> bummer
<kenvandine> ok
<kenvandine> is there an easy way to get those names?  Or do i need to parse them out of user-dirs.defaults?
<zyga-ubuntu> morphis: I don't know yet
 * kenvandine thought there was an easy way
<seb128> kenvandine, g_get_user_special_dir ()
<kenvandine> yeah, but nothing available in a shell script
<seb128> you can use the binding from python
<kenvandine> i guess i can look at the g_get_user_special_dir implementation
<kenvandine> ah
<kenvandine> seb128, although i doubt starting a python interpretor in the desktop helpers would be a good idea speed wise
<morphis> zyga-ubuntu: please let me know once you guys are closer to a decision on this as this will have quite some impact on system enablement etc.
<seb128> kenvandine, $ python -c "from gi.repository import GLib; print(GLib.get_user_special_dir(GLib.USER_DIRECTORY_DOCUMENTS))"
<zyga-ubuntu> morphis: right, I think this will happen one gustavo is back
<tyhicks> zyga-ubuntu: I'm sure you are aware of this but there will be a considerable lead time before apparmor and overlayfs can be fully working together and the one or two people that can work on that are committed to other work
<seb128> kenvandine, it wouldn't be the slowest thing in there...
<zyga-ubuntu> morphis: in the meantime I'll work on options
<seb128> kenvandine, but yeah, probably easier to just shell parse the .config
<zyga-ubuntu> tyhicks: noted,
<kenvandine> seb128, thx!
<seb128> kenvandine, yw
<morphis> zyga-ubuntu: aye
<zyga-ubuntu> tyhicks: ultimately it is not my decision, I'll just collect facts and help make the descision clear
<tyhicks> zyga-ubuntu: that makes sense - just be sure to point that out if you're in a conversation where the decision is being made
<om26er> popey: for you: https://forum.snapcraft.io/t/please-allow-my-android-studio-snap/2634 :-)
<zyga-ubuntu> tyhicks: you will be in the call I'm sure
<tyhicks> sometimes it works out like that, sometimes not :)
<tyhicks> (in all projects - not just snappy)
 * zyga-ubuntu breaks for some follow-the-news time
<jdstrand> kenvandine, seb128: in the past we have said that we won't support translatable directories in the filesystem (how they are presented to the user is entirely different of course). that hasn't changed, has it?
<kyrofa> Huh. elopio what might be causing this? https://travis-ci.org/snapcore/snapcraft/jobs/292341577
<kyrofa> Any chance it's from the "use the snap for integration tests" PR?
<mup> Bug #1728076 opened: Initialize Device transaction incorrect "Done" status <Snappy:New> <https://launchpad.net/bugs/1728076>
<kenvandine> jdstrand, i remember some discussions on that, but i don't recall the details
<kenvandine> jdstrand, i've found an easy way to get those from xdg-user-dirs
<kenvandine> in practice what it gives me might not be translated though
<kenvandine> jdstrand, seb128: http://paste.ubuntu.com/25830955/
<kenvandine> that seems to work
<kenvandine> but i need to try that with a different LANG now
<jdstrand> kenvandine: this came up a long time ago wrt click. basically, upstream and Ubuntu felt that translating those at the filesystem level was a mistake. ie, it should always be /home/foo/Documents, not /home/foo/SomeTranslatedThing
<jdstrand> kenvandine: so we don't support translated dirs officially. as it happens, with the home interface and because all of $SNAP_USER_DATA is usable by the snap, this hasn't been an issue on snappy
<jdstrand> kenvandine: that said, I don't think user-dirs.dirs is readable today
<jdstrand> kenvandine: no it isn't. I'm getting lose to writing a PR that will make it readable
<jdstrand> close*
<seb128> jdstrand, who is "we"? translated directories are a xdg reality for 10 years...
<ogra_> s/reality/annoyance/ :P
<kyrofa> kalikiana, commented on snapcraft#1641
<mup> PR snapcraft#1641: lxd: catch CalledProcessError in _container_run <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1641>
<seb128> ogra_, says a german speaker...
<ogra_> who has to type "ArbeitsflÃ¤che" instead of Desktop on one machine ... i hate that
<jdstrand> seb128: you were in the conversation. I remember discussing it in person with you and Allison. we all agreed it was a mistake even if they've been there for 10 years. and we agreed click wouldn't support them. I can pull up bugs to remind you if needed :P
<kalikiana> kyrofa: Thanks!
<seb128> jdstrand, you might be right, I vaguely remember discussing it but not in the snap context, maybe it was clicks
<seb128> jdstrand, issue is that for snaps you have to deal with existing apps
<jdstrand> seb128: no, it wasn't the snap context. only clicks
<ogra_> (i dont mind Bilder vs Pictures and the like ... but translating the Desktop dir always puts me off)
<jdstrand> seb128: I was saying with snaps we inherited non-support initially, but now with home and SNAP_USER_DATA, it mostly doesn't matter
<jdstrand> only if we decide to carve up the home interface would it be an issue
<kenvandine> seb128, i guess this is the first time i've run a snap using a different lang... so snaps aren't showing as translated?
<ogra_> on the phone we could do the translation on the UI level because we had the content-hub and friends
 * jdstrand notes that the gtk3 file chooser or nautilus or whatever could present anything they want (that was what we concluded unity8 might end up doing)
<seb128> kenvandine, they do if built properly
<ogra_> that is why it wasnt a problem there ... there was a way bigger separation
<kenvandine> seb128, so i guess mine aren't :)
<kenvandine> seb128, what's the magic?
<seb128> kenvandine, do you use the --prefix build hack?
<kyrofa> kalikiana, did you approve snapcraft#1644 ?
<mup> PR snapcraft#1644: lxd: fix the push in container builds <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1644>
<kenvandine> seb128, yes
<kyrofa> Rather, I know you didn't, but DO you approve
<seb128> kenvandine, then translations should work...
<jdstrand> ogra_: right
<jdstrand> but again, it isn't actually a problem here
<ogra_> yeah
<jdstrand> cause we don't separate ~/Videos from ~/Documents
<kenvandine> jdstrand, ${XDG_CONFIG_HOME:-~/.config}/user-dirs.dirs is readable because it's under $SNAP_USER_DATA
<kenvandine> and we run xdg-user-dirs-update after setting that
<kenvandine> so it should do the right thing
<jdstrand> if we did, and if translated xdg dirs are still a thing (and it sounds like they are; I guess upstream didn't pursue something better), then there would be work to do make them work in the policy (which is possible)
<jdstrand> kenvandine: yeah, but, where are you getting that?
<jdstrand> kenvandine: https://forum.snapcraft.io/t/xdg-user-dirs-and-dconf-apparmor-denials/2390/3
<jdstrand> kenvandine: in addition to that, I also need to add ~/.config/user-dirs.conf
<kenvandine> the desktop helper runs xdg-user-dirs-update after setting $XDG_CONFIG_HOME properly
<jdstrand> kenvandine: in addition to that, I also need to add ~/.config/user-dirs.dirs?
<kenvandine> jdstrand, that would be good
<jdstrand> ok
<jdstrand> I was talkingn about .conf
<jdstrand> but we should also allow /etc/xdg/user-dirs.defaults
<kenvandine> yeah
<elopio> kyrofa: ugh, you broke it :( it worked less than a day.
<kyrofa> elopio, hahahahaha
<elopio> Let me check the logs to see if I can understand something there. But more likely I'll have to debug.
<jdstrand> zyga-ubuntu: I gave spread the wrong args and it is running all the tests. I can't seem to kill it
<zyga-solus> jdstrand: qemu or linode?
<jdstrand> zyga-ubuntu: I bg'd it and tried -discard, but it held the lock
<zyga-solus> jdstrand: if qemu just kill qemu process
<jdstrand> zyga-ubuntu: linode
<zyga-solus> jdstrand: ah
<jdstrand> (hence the wrong argument
<zyga-solus> jdstrand: kill spread and -discard then
<kenvandine> seb128, confirmed gedit is using the prefix hack but not showing up as translated for me
<zyga-solus> (run the same thing bug pass -discard)
<kenvandine> seb128, can you please confirm?
<jdstrand> ok, wasn't sure that would work
<zyga-solus> yes, all you need is in that local .spread.* file
<zyga-solus> it just kills the node from the lindoe API
<sergiusens> kyrofa can you look at my comment on snapcraft#1641, the objective is to not print an error, not to capture and print the same error again
<mup> PR snapcraft#1641: lxd: catch CalledProcessError in _container_run <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1641>
<jdstrand> zyga-solus: did you disable rate limiting? I think we are doing that by default now in spread, but worth asking
<seb128> kenvandine, indeed, (gedit:8296): Gtk-WARNING **: Locale not supported by C library.
<seb128> 	Using the fallback 'C' locale.
<kyrofa> sergiusens, right, capturing it would cause it to _not_ be printed
<zyga-solus> jdstrand: no, I didn't! that's a good think to check
<kyrofa> sergiusens, and give us the ability to print it
<kyrofa> sergiusens, rather than traceback, we can simply use the stderr
<kalikiana> kyrofa: Yes. I was reluctant to give my v here since I changed the unit tests. But the fix is good to my mind
<seb128> kenvandine, I had my ghex snap working with that wrapper http://bazaar.launchpad.net/~ubuntu-desktop/+junk/ghexudt/view/head:/ghex.wrapper
<jdstrand> zyga-solus: note that if it is a capability denial, apparmor itself might be rate limiting it (it actually rate limits quite a few things. see: https://bugs.launchpad.net/apparmor/+bug/1707743). capability is the only one that really seems to be a problem
<mup> Bug #1707743: denied capability logged only after profile load <aa-kernel> <AppArmor:New> <https://launchpad.net/bugs/1707743>
<jdstrand> zyga-solus: perhaps you could add a base capability rule and see if it passes? 'capability,'
<jdstrand> s/base/bare/
<seb128> kenvandine, the desktop launcher has https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports#L127 ... did you try to stage locales-all?
<zyga-solus> jdstrand: trying
<seb128> kenvandine, that might take space though, the hack in ghex was only needing libc-bin/locales iirc which is smaller
<sergiusens> kyrofa kalikiana why is it not possible to NOT traceback and NOT print?
<sergiusens> kyrofa on a cli, you will run something, it will be seen as a double error being printed
<kyrofa> sergiusens, we're saying the same thing, perhaps we should jump on a HO?
<ogra_> to say the same thing aloud ?
<kyrofa> ogra_, in harmony
<ogra_> yeah, thats what i imagined
<jdstrand> zyga-solus: I see the same thing. no denial
<kenvandine> seb128, i'll play around with it
<kenvandine> seb128, thx
<zyga-solus> capability didn't change it
<kenvandine> seb128, i can probably add locales-all to the platform
<jdstrand> zyga-solus: try removing this: deny capability fsetid,
<zyga-solus> k
<jdstrand> zyga-solus: or turn it into an allow by removing 'deny'
<zyga-solus> jdstrand: running, though it is on the parent profile so probably not a factor
<jdstrand> removing the rule would still have it deny of course
<zyga-solus> sure
<sergiusens> kyrofa I think you want to handle the printing the exception handler which requires all of what you mentioned is needed. I am just saying, from whatever calls lxc exec, raise a specific exception that will be caught and handled differently
<jdstrand> zyga-solus: that should be unrelated anyway, but, like I said, there are some weird bugs
<jdstrand> (with overlayfs and apparmor)
<kyrofa> sergiusens, handled differently i.e. just exit non-zero and don't say anything extra?
<kyrofa> I think we can do that just by raising a SnapcraftError(), but I'll check
<kyrofa> We'll need a SnapcraftError with a __str__ that is empty
<sergiusens> kyrofa yes, exactly; given that the run was owned by the instance of snapcraft run inside the container; if we go a different path this will be exceedingly complex to handle; that said, in a future PR we could just use the piping mechanism to create a .log of the build when using containers (should be straightforward)
<kyrofa> sergiusens, yeah that seems to be the direction we're heading overall anyway
<kyrofa> sergiusens, when it comes to the nested snapcraft I totally agree
<kyrofa> sergiusens, but doing the same for the setup stuff isn't quite as clear. How do you feel about hiding that behind a progress bar?
<zyga-solus> jdstrand: no change
<kyrofa> It'll take two PRs to do that, this one using essentially a dumb exception, and another one splitting the setup tasks out
<jdstrand> zyga-solus: I've dropped to the shell in spread. I should just be able to edit the profile and run stuff, right? I tried to run test-snapd-content-advanced-slot.sh' but things went terribly wrong
<jdstrand> /bin/sh: 0: Bad substitution
<jdstrand> repeated forever. I couldn't recover and had to kill the vm
<zyga-solus> yes
<zyga-solus> yes, that breaks, paste the same line you saw in the test and it will work
<zyga-solus> so
<zyga-ubuntu> test-snapd-content-advanced-plug.sh -c 'test -d $SNAP/target'
<zyga-ubuntu> this will re-try
<zyga-ubuntu>  /usr/lib/snapd/snap-discard-ns test-snapd-content-advanced-plug; test-snapd-content-advanced-plug.sh -c 'test -d $SNAP/target'; echo $?
<zyga-ubuntu> this is even better
<sergiusens> kyrofa what setup stuff?
<jdstrand> zyga-solus: unfortunately I was winging it cause I did 'reset' :)
<kyrofa> sergiusens, installing squashfuse, injecting snaps, the stuff that failed for popey that spawned that PR
<sergiusens> kyrofa oh, that should be handled the way we usually handle exceptions in our code base
<kyrofa> sergiusens, right, which is what kalikiana did. Problem is, the codepath is the same
<kyrofa> sergiusens, so my suggestion is: if we're splitting them out, might as well put that stuff behind a progress bar
<mup> PR snapd#4094 closed: tests: cherry pick the fix for services test into 2.29 <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4094>
<sergiusens> kyrofa code path the same being, the sequence of steps comes one after the other?
<sergiusens> they just need to be handled differently then, a progressbar could do, but I would hold off on that until we have a better separation of cli/logic
<kyrofa> sergiusens, no, they all go through `_container_run`, which is where the exception-handling logic has been added. They just need to be, yeah, treated differently
<kyrofa> sergiusens, okay, I'll summarize on the PR
<sergiusens> thanks
<kalikiana> kyrofa: treat differently how? I'm a bit lost now
<kyrofa> kalikiana, don't worry, I will try to make all things clear in my summary
<kalikiana> Okay thanks
<mup> PR snapd#4096 opened: spread: welcome bionic beaver <Created by mvo5> <https://github.com/snapcore/snapd/pull/4096>
<kalikiana> btw wrapping up for today now - I'll be off most of next week (you can see it in the team view) but will be checking in here and there for comments etc
<mvo> cachio: finally! 2.29~rc2 for i386,amd64 - arm is still pending, no idea what is going on with the arm autobuilders currently, super slow
<ogra_> i guess you are fighting with doko ;)
<ogra_> initial import of bionic etc
<jdstrand> zyga-solus: I've spent way more than 15 minutes on this. unfortunately, my desktop crashed and I lost all state (/me shakes fist at wayland/mutter not being able to restart)
<jdstrand> zyga-solus: I don't think there is enough information to definitively say it is apparmor. however, you could try different bare rules to see what is the issue
<zyga-solus> jdstrand: thank you for the effort
<zyga-solus> jdstrand: I think this is enough for now
<jdstrand> zyga-solus: eg, add 'file,'
<jdstrand> then mount,
<jdstrand> then ptrace,
<jdstrand> etc
<zyga-solus> I'll try
<jdstrand> maybe one of them will work and that will provide a clue
<jdstrand> could be a logging bug
<jdstrand> could be a poor interaction between attach_disconnected and overlayfs
<jdstrand> it would not surprise me at all if attach_disconnected is mapping something to the wrong place
<jdstrand> zyga-solus: ^
<zyga-solus> aha
<zyga-solus> I'll try all and we'll know more next time
<zyga-solus> thank you for investigating this
<jdstrand> remember, attach_disconnected is a hack. overlayfs would ideally be giving us the proper locations. attach_disconnected just says connect anything that is disconnected to '/'
<jdstrand> zyga-solus: ^
<jdstrand> ok, yw
<zyga-solus> I see, I didn't know it's a hack
<cachio> mvo, could you please upload the snap https://github.com/sergiocazzolato/snapd/tree/tests-interface-gsettings/tests/lib/snaps/test-snapd-gsettings
<kyrofa> sergiusens, snapcraft#1636 is ready, but you put 2.36 on there. Does that mean you don't want it in just yet?
<mup> PR snapcraft#1636: internal: more gracefully determine host OS <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1636>
<kyrofa> It's not approved yet either, to be clear
<kyrofa> I'm also good with snapcraft#1593 if you want to take a look
<mup> PR snapcraft#1593: catkin tools plugin: add catkin tools support <Created by cratliff> <https://github.com/snapcore/snapcraft/pull/1593>
<cachio> mvo, I am running beta validation now
<kyrofa> elopio, also, what do you think about the plainbox tests? Do you agree that we should remove the years?
<om26er> why do classic snaps need manual approval ?
<ogra_> because they have full system access
<om26er> when does ogra_ actually go offline ?
<ogra_> heh
<om26er> anyways, I have a android-studio snap waiting manual review because its a classic snap. Hopefully that'll get figured out soon.
<elopio> kyrofa: yes, I'll update my branch. Sorry the day.got complicated and I'm in a bus.
<kyrofa> elopio, quite alright, I'm happy to update it if you like, I just wanted to make sure you agreed
<elopio> kyrofa and your PR has the snap stage after.that integration test. That way it will never work. I'm not sure what's going on, I'll keep digging.
<kyrofa> elopio, huh...
<elopio> kyrofa yes please, go for it
<sergiusens> kyrofa if you provide a list of all the systems you've checked then maybe yes; but I put 2.36 on most so the focus would stay on things for 2.35 and potentially the pip/python stuff (which is the only thing we could think about backing into 2.35)
<kyrofa> sergiusens, alright I figured, just wanted to make sure we were on the same page
<sergiusens> the "just one more thing" is what is causing all these release delays ;-)
<kyrofa> Haha, amen
<kyrofa> If you want to just lock down the release now that's fine too. Focus on autopkgtests
<kyrofa> sergiusens, remember we can always make a release branch for stabilizing if we don't want to hold up landings
<kenvandine> jdstrand, are you actively working on adding access to user-dirs related paths?
<sergiusens> kyrofa I don't mind as we all have things to work on for 2.35; this is not a big team :-)
<jdstrand> kenvandine: yes. I'm preparing a branch with various updates that includes that as we speak
<sergiusens> I really want our small team to focus on 2.35
<kenvandine> jdstrand, excellent
<kyrofa> sergiusens, alright will do. I'll focus on autopkgtests
<mvo> cachio: thanks! core build still tells me in 1h/2h for armhf/arm64 :(
<mvo> cachio: I keep an eye one it
<cachio> ok, np
<cachio> mvo, ce you updaload the snap I'll create the PR
<sergiusens> kyrofa feel free to make the ocd change in snapcraft#1644
<mup> PR snapcraft#1644: lxd: fix the push in container builds <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1644>
<kyrofa> sergiusens, haha, okay
<elopio> alright, back on my machine
<stokachu> noise][: can you give cory johns @canonical.com access to charmtools snap?
<elopio> kyrofa: I will start the hangout in a few minutes. Let me know if you want to join to test. Also sergiusens where in the world are you? You are welcome to join us, of course.
<mup> PR snapd#4097 opened: interfaces/many: miscellaneous updates based on feedback from the field <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4097>
<kyrofa> elopio, awesome
<sergiusens> elopio I am finally home, since yesterday!
<stokachu> noise][: sorry the snap is "charm"
<stokachu> noise][: or maybe give ownership to the same group you did with conjure-up
<zyga-ubuntu> mvo: hey, still there?
<jdstrand> mvo: hey, I know its late, but there is the PR I was talking about. no need to review now, but I add the 2.29 milestone-- is that what you wanted me to do?
<zyga-ubuntu> mvo: sorry for going AWOL, tracking unfolding events in spain now
<stokachu> nessita: or if you're available to give access to charm for the canonical group (same group set for conjure-up)
<stokachu> sergiusens: seen https://pastebin.ubuntu.com/25830958/ before?
<nessita> stokachu, hey there. I can't add collaborators, you need mvo for that, sorry
<stokachu> nessita: ok ty!
<stokachu> mvo: if you got a minute from the spain madness :)
<zyga-ubuntu> stokachu: mvo or me?
<stokachu> zyga-ubuntu: can you give store access to people?
<zyga-ubuntu> stokachu: I don't think I can
<stokachu> ok
<sergiusens> stokachu seems like request's raise_for_code did not get triggered and status was not returned in the json results. Mind logging a bug? Is this a one time thing?
<sergiusens> Facu any idea about that scenario ^ in stokachu's pastebin?
<stokachu> sergiusens: cory_fu is the one that hit this issue
<jdstrand> kenvandine: fyi, https://github.com/snapcore/snapd/pull/4097
<mup> PR #4097: interfaces/many: miscellaneous updates based on feedback from the field <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4097>
<kyrofa> elopio, give me the link when you have it
<elopio> one second
<cory_fu> sergiusens: Pretty sure it's because I don't have access to the snap yet (there's an invite pending, but I never got the email nor can I find it via the Dashboard)
<Facu> sergiusens, nop
<Facu> cory_fu, but you can repeat it, right?
<sergiusens> cory_fu ah, no snap access, that should return some sort of 5xx I believe, but let me try and release a snap I don't have listed here and see what happens; if you don't mind a bug might help this from falling into the cracks
<cory_fu> sergiusens: Yep, filing one to LP now
<cory_fu> Facu: Yes, I can reproduce it
<cory_fu> https://bugs.launchpad.net/snapcraft/+bug/1728121
<mup> Bug #1728121: Traceback from snapcraft release <Snapcraft:New> <https://launchpad.net/bugs/1728121>
<elopio> kyrofa, sergiusens and anybody else who would like to join the ubuntu hour: https://hangouts.google.com/hangouts/_/jdpkqoaaz5fw7f6b2jlmhy5auie
<mup> PR snapd#4098 opened: snap-confine: allow reading uevents from any where in /sys <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4098>
<jdstrand> mvo: same question for ^
<Facu> cory_fu, sergiusens, will track this server side, thanks
<kenvandine> jdstrand, cool, i'll watch that
<kenvandine> jdstrand, also i have a WIP branch for the helpers https://github.com/kenvandine/snapcraft-desktop-helpers/commit/9be256f76362a4f109890e033d9fc5467144f715
<sergiusens> Facu stokachu cory_fu I can totally reproduce this https://pastebin.ubuntu.com/25831852/
<jdstrand> kenvandine: come to think of it, `id -u` will be more robust than $UID. istr not always having $UID
<Facu> sergiusens, also trying to release something you don't have permissions?
<jdstrand> kenvandine: and cool! :)
<sergiusens> I will look at the responses a bit closer (we could add one more call before release to get the account info and verify you can release to that snap if it comes to it).
<sergiusens> Facu yes, I have no access to conjure-up :-)
<Facu> sergiusens, I would have thought that the server is not 200ing in this case, will check
<sergiusens> Facu ah, it is the exception that is at fault
<sergiusens> we have if not response.ok and pass the response to our own exception implementation
<sergiusens> Facu I'll take it from here :-)
<Facu> sergiusens, so, server is returning that you can not access it, right?
<sergiusens> Facu at least returning something saying it is not ok
<mvo> jdstrand: what was the question?
<mvo> jdstrand: I think thats reasonable
<jdstrand> mvo: you said to 'tag' the PR with 2.29. I don't see 'tag's in the github interface, so I milestoned it
<jdstrand> mvo: I just wanted to make sure I was doing what you asked :)
<mvo> jdstrand: yeah, sorry, milestoned is the right thing
<jdstrand> ok, cool
<mvo> jdstrand: thanks! this is fine for 2.29
<jdstrand> thank you :)
<jdstrand> mvo: note it is 4097 and 4098 (both only add access so not risky)
<mvo> jdstrand: aha, thank you
<mvo> cachio: armhf/arm64 is now ready as well
<cachio> mvo, great
<cachio> I'll run that now
<mvo> cachio: thanks a lot!
<mvo> cachio: keep me updated please :)
<cachio> mvo, so far everything passed
<cachio> mvo, l run the devices now
<mup> PR snapd#4054 closed: snap-{confine,seccomp}: make @unrestricted fully unrestricted <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4054>
<mup> PR snapd#4099 opened: merge 2.29~rc2 release back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/4099>
<om26er> does the dump plugin support dynamic `source` parameter ?
<om26er> maybe a script that resolves to a url ?
<kyrofa> om26er, no, can you explain your use-case?
<om26er> kyrofa: There is no direct link for the source zip that I want to download from. The url is resolved after a script is executed.
<kyrofa> om26er, can you execute it locally and then copy/paste that URL?
<om26er> I am setting version using version-script but was looking for a way to set the `source` as well.
<kyrofa> om26er, you always do it in a local plugin
<kyrofa> om26er, inherit from the dump plugin but make the source dynamic
<kyrofa> you CAN always, rather
<om26er> kyrofa: that could work but I was thinking to full automate it. i.e. whenever I know there is a new release available, just do a dummy commit to my snap package and push so that auto build kick in
<kyrofa> om26er, yeah this doesn't preclude that
<kyrofa> I do the same thing for daily builds, although in my case the URL is just a symlink
<kyrofa> I just change the version and push
<om26er> kyrofa: can you share examples of a local plugin ?
<kyrofa> om26er, sure thing, one sec
<kyrofa> om26er, here's an example: https://github.com/nextcloud/nextcloud-snap/blob/master/snap/plugins/x-php.py
<kyrofa> You just need to put them in snap/plugins and snapcraft will find them
<kyrofa> (like they are there)
<om26er> kyrofa: so when I refer them in my yaml I prepend `x-` ?
<kyrofa> om26er, no actually-- refer to the YAML in that same project
<om26er> kyrofa: you got an example to override dump plugin somewhere ?
<kyrofa> The naming pattern is confusing, so just trust me: name your plugin x-<plugin name>.py and then refer to it in the YAML as <plugin name>
<kyrofa> om26er, I don't, but simply import snapcraft.plugins.dump and inherit from snapcraft.plugins.dump.DumpPlugin
<kyrofa> om26er, then overwrite the `pull` method, but not the `build`
<om26er> looking into this.
<mup> PR snapcraft#1546 closed: cli: update parts cache in the container <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1546>
<sergiusens> elopio what is that close/open attempt all about on snapcraft#1607 ?
<mup> PR snapcraft#1607: python plugin: use extracted pip <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1607>
<elopio> sergiusens: kyle broke the order of the stages. I turned it on and off again to fix it.
<kyrofa> elopio, wait... what?
<kyrofa> How did that fix things? :P
<elopio> (shrug)
<mup> PR snapd#4100 opened: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4100>
<elopio> kyrofa I saw only yours was failing that way, and restarting didn't help
<elopio> I was just touching buttons. It might be necessary to do this for the ones that have been open before the change.
<elopio> I'm going to propose the transfer nicety now.
<kyrofa> elopio, quick plug for the `transfer` snap
<sergiusens> kyrofa why transfer when you can wormhole it ;-)
<kyrofa> sergiusens, one to many versus one to one
<kyrofa> sergiusens, elopio is talking about making the snapcraft snap available for each PR by uploading it to transfer.sh
<sergiusens> kyrofa ah, it would be much nicer to have a webhook sent to some infra we control that would end up pushing and releasing to a branch :-)
<sergiusens> but one step at a time
<elopio> Quick cheat until build.snapcraft.io makes it nicer for us
<sergiusens> kyrofa is transfer.sh the one from mozilla?
<elopio> sergiusens: the bot can't release to a branch yet
<sergiusens> ah, no, it was send (the one from mozilla)
<sergiusens> elopio btw, how is the bot protected?
<elopio> sergiusens ssh-only on Google cloud.
<elopio> ACLs for the commands, but the commands can't expose the password.
#snappy 2017-10-28
<rocklegend> @kyrofa is that you?
<nothal> rocklegend: No such command!
<kyrofa> rocklegend, indeed :)
<kyrofa> rocklegend, welcome!
<kyrofa> rocklegend, I'm sorry, SO tends to frown on side conversations in comments
<kyrofa> rocklegend, so let's ignore ROS for a moment. How would you write a C++ library using CMake do be used by third-parties?
<kyrofa> s/do/to/
<kyrofa> You would install the .so, as well as any headers, using install rules, no?
<kyrofa> Just because ROS1 implements a devel space, doesn't mean you can ignore this requirement
<kyrofa> (note that ROS2 doesn't even have one)
#snappy 2017-10-29
<mup> PR snapcraft#1645 opened: Ruby plugin: new stable release 2.4.2 <Created by nathanhaines> <https://github.com/snapcore/snapcraft/pull/1645>
#snappy 2018-10-22
<mup> PR # closed: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#1905, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2289, snapcraft#2354, snapcraft#2359, snapcraft#2369
<mborzecki> morning
<zyga> good morning
<zyga> mborzecki: hey :)
<mborzecki> zyga: hey hey
<zyga> I walked my daughter to school today
<zyga> it's so misty I was afraid of letting her go by herself
<zyga> how are you doing?
<mborzecki> and  it's cold too
<mborzecki> glad i swapped the tyres in the car on friday
<zyga> yeah, scarfs, hand gloves and caps
 * zyga reads some news about the election yesterday
<zyga> then back to patches
<mborzecki> zyga: heh, elections, the situation in lodz is 'stable' :)
<zyga> mborzecki: so nothing changed?
<mborzecki> zyga: yeah, exit polls suggest the same president as before with 70+% votes
<zyga> I signed up to Apple Music yesterday as a trial to show my dad how it works
<zyga> I'm in love :) it's fantastic
<mborzecki> zyga: btw. https://status.github.com/messages
<zyga> DRM free music, everything in iTunes seems to be available, 19zÅ a month
<zyga> oh
<zyga> github is down? I'm reading reviews now and it's ok so far
<zyga> woah
<zyga> data corruption
<zyga> well
<zyga> monday :)
<mborzecki> zyga: appl music? basically like spotify?
<zyga> no
<zyga> it's like iTunes (you buy music, it's DRM free on your disk)
<zyga> all you can eat
<zyga> you can stream but you can also just download and keep offline forever
<zyga> I usually spend 20-50 a month per music
<zyga> so this is much cheaper
<zyga> there's also a family plan but I didn't look at that yet, for up to six people
<mborzecki> zyga: download as some format and keep forever elsewhere or are you forced to use the app?
<zyga> it's just mp4
<zyga> normal format
<zyga> one sec
<mborzecki> zyga: heh, have you tried doing reviews today?
<dot-tobias> Good morning everyone
<zyga> well, I'm trying now
<zyga> hey dot-tobias :-)
<zyga> mborzecki: what are you observing?
<mborzecki> zyga: ui getting stuc waiting for response when adding comemnts
<mborzecki> zyga: and got a unicorn erorr page :P
<mborzecki> haha and the review was not sent
<mborzecki> omg
<mborzecki> so much for reviews
<zyga> re
<zyga> that's not encouraging :/
<dot-tobias> quite possibly a dumb question, but â¦ can I assume that the âlast modifiedâ date for edge images (http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/) can be completely ignored and the build is in fact âdailyâ?
<zyga> hmmm, good question dot-tobias
<zyga> it looks fishy to me
<zyga> I think it's not the latest one
<pstolowski> morning
<mborzecki> pstolowski: hey
<mup> PR snapcraft#2378 opened: Release chagelog for 3.0 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2378>
<Chipaca> mo'in
<zyga> oi
<Chipaca> mborzecki: https://pastebin.ubuntu.com/p/B6QY2h3gwB/
<mborzecki> Chipaca: nice
<Chipaca> I wish we had a "can run things from such-n-such snap" interface
<mup> PR snapcraft#2378 closed: Release chagelog for 3.0 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2378>
<Chipaca> then taht wouldn't need classic :-)
<zyga> Chipaca: we could
<zyga> we have the capability
<Chipaca> mborzecki: if you want to push it feel free; otherwise i could
<Chipaca> zyga: it's like a content interface but different
<zyga> haha
<zyga> yes
<zyga> not content ;)
<zyga> it'd be an interface where we'd have a set of snap commands that a given snap can run
<zyga> enforced at snap-confine level, I suspect
<Chipaca> mborzecki: otoh we could also package shellcheck into the snap ourselves
<Chipaca> mborzecki: or offer spread-shellcheck upstream
<Chipaca> mborzecki: the latter needs a bit of paperwork
<mborzecki> Chipaca: shellcheck gets frequent updates, at least here on arch, it's probably upstream pushing new changes
<Chipaca> on a completely unrelated subject: WTH https://i.imgur.com/YcjvITL.png
<zyga> Chipaca: promoted!
<zyga> WAT
<Chipaca> exactly
<Chipaca> somebody paid money to do that
 * zyga puts on pants
<zyga> must be important
<Chipaca> zyga: maybe it's a US/UK thing
<mborzecki> Chipaca: no pants?
<Chipaca> mborzecki: https://en.wiktionary.org/wiki/pants
<Chipaca> mborzecki: look at the pics
<mup> PR snapcraft#2378 opened: Release chagelog for 3.0 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2378>
<zyga> hmmm
<zyga> github is indeed wonky
<Chipaca> oh, nice, github's databases are eventually inconsistent right now
<zyga> chipaca's critical PR is marked as approved
<zyga> but if you click on it, it is not, no comment history
<Chipaca> https://mobile.twitter.com/TheRegister/status/1054267789232431104
<zyga> the pic is very representative of IS work
<zyga> not
<mborzecki> Chipaca: did you get my review of https://github.com/snapcore/snapd/pull/6026 ? when i go to the PR there's like 3 reviews pending (?)
<Chipaca> well, it's the reg
<mup> PR #6026: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<Chipaca> mborzecki: i got yours
<Chipaca> mborzecki: nobody else's yet
<mup> PR snapcraft#2378 closed: Release chagelog for 3.0 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2378>
<mborzecki> Chipaca: well i got a unicorn in return :P
<Chipaca> mborzecki: but as above, github's hard drive is full
<zyga> unicorns
<zyga> unicorns everywhere
<Chipaca> zyga: https://www.youtube.com/watch?v=DX1iplQQJTo&feature=youtu.be&t=90
<zyga> https://imgflip.com/i/2knjpg
<zyga> I guess the windows upgrade went well at GitHub today
<zyga> GH reviews are still in read only mode
<mborzecki> zyga: at least one got through :P
<zyga> oh? I keep try to send a trivial comment to see what happens
<mborzecki> haha got zyga's review email, but the reviews are not visible https://github.com/snapcore/snapd/pull/6026
<mup> PR #6026: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<Chipaca> well I got mborzecki 's review twice
<Chipaca> so there
<mborzecki> hahah
<Chipaca> zyga: and i just got a review from you as well
<mborzecki> oh and in zyga's review the comment was doubled
<Chipaca> yes
<Chipaca> zyga: so, depends how you look at it :-) that was the thing that triggered the panic, so that's the immediate cause
<Chipaca> zyga: but before that, cmdTry was different from other snap ops in that it didn't pass the error to errorToCmdMessage
<mborzecki> https://blog.github.com/2018-10-21-october21-incident-report/
<Chipaca> zyga: so that's the deeper cause
<Chipaca> zyga: because there _is_ an opts for this error, it's just not in main
<Chipaca> zyga: which one of those causes is the crux, i guess it depends on how you look at it?
<zyga> mmm, I see
<zyga> I made exceptionally hot coffee
<zyga> my hands are freezing here
 * Chipaca hands zyga a "crux of the matter" trophy
<Chipaca> (just got another few emails)
<zyga> hahah
<zyga> it's still being published?
<zyga> I see them now
<mborzecki> zyga: github liked you comment so much it keep on sending it ;)
<zyga> haha
<zyga> eventually it will stop ;-)
<mborzecki> haha
<mborzecki> is it just me or are none of the 2 reviews posted in https://github.com/snapcore/snapd/pull/6026 visible?
<mup> PR #6026: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<sil2100> zyga: hey! Did you have a moment to check the dragonboard image?
<zyga> yes!
<zyga> let's do it :)
<zyga> is the one from last week good?
<zyga> or shall I pick lastest
<sil2100> http://cdimage.ubuntu.com/ubuntu-core/18/pending/ubuntu-core-18-arm64+snapdragon.img.xz <- latest is always the best ;)
<sil2100> Oh, no mvo today?
<zyga> sil2100: no, sprinting
<zyga> sil2100: flashing
<sil2100> zyga: do you maybe know when's the ETA for a stable-channel release of snapd?
<zyga> no idea
<zyga> maybe mid sprint?
<zyga> but really no idea
<Chipaca> sil2100: are you talking about 2.36?
<sil2100> Chipaca: I'm talking about the snapd snap
<sil2100> Chipaca: we don't have any version of it in stable from what I can see at least
<Chipaca> ah
<Chipaca> ok :-)
<Chipaca> no idea
<mborzecki> Chipaca: shall we try posting the reviews again?
<Chipaca> mborzecki: zyga: please
 * Chipaca afk for a bit
<zyga> yep
<Chipaca> bah
<Chipaca> 10:47 British Summer TimeWe continue to monitor restores which are taking longer than anticipated. We estimate they will be caught up in an hour and a half.
<Chipaca> so maybe let's check after lunch
<Chipaca> zyga: mborzecki ^
<Chipaca> (that was 15 minutes ago)
<mborzecki> too late, already clicked :P
<mborzecki> aand unicorn!
<zyga> unicorn days
<zyga> I tried to fork a repo just now
<zyga> 404 and errors
<zyga> sil2100: it works
<zyga> https://www.irccloud.com/pastebin/bPMblg1d/
<zyga> dragon board is operational :)
<zyga> 11:47 CESTWe continue to monitor restores which are taking longer than anticipated. We estimate they will be caught up in an hour and a half.
<zyga> from status.github.com
<mup> Issue # closed: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15
<mup> PR # closed: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30
<sil2100> Let's SHIP IT
<mup> PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#22 closed: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<mup> PR core-build#26 closed: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
<mup> Issue # opened: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15
<mup> PR # opened: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30
<mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#22 opened: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<mup> PR core-build#26 opened: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
<zyga> everything is broken :)
<zyga> apparently ceph fails universally ;)
<pstolowski> Chipaca finally figured Friday's issue greyback hit
<mup> PR # closed: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#1905, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2289, snapcraft#2354, snapcraft#2359, snapcraft#2369
<greyback> pstolowski: oh nice!
<mborzecki> pstolowski: what was it?
<pstolowski> mborzecki: a commit i introduced on sep 7, to conflict & retry on discard-snap. I missed the fact that discard-snap is created sometimes by install as well to remove inactive revision. so, auto-refresh conflicts with itself
<pstolowski> mborzecki: in this case it tries to refresh lxd and also schedules removal of old inactive revision of lxd
<mborzecki> pstolowski: nice
<mup> PR # opened: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#1905, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2289, snapcraft#2354, snapcraft#2359, snapcraft#2369
<mborzecki> pstolowski: sounds like a scenario we'd like to have a test for
<pstolowski> mborzecki: yes, definately. i added a test for conflict, but no we have a case where we shouldn't conflict
<pstolowski> *now we have
<mborzecki> great
<zyga> sil2100: there are some wifi errors on screen after a while
<zyga> Oct 22 10:40:55 localhost kernel: wcn36xx: ERROR hal_remove_bsskey response failed err=6
<sil2100> zyga: I think we need to poke the kernel team about those
<zyga> where shall I report those?
<mborzecki> any idea if it's possible to do spread -repeat=<n> but directly in task.yaml?
<mborzecki> heh after/before test is fiddly
<zyga> mborzecki: no idea
<zyga> count: 10?
<mborzecki> zyga: doesn't appear to be anything like that
<zyga> :/
<Chipaca> pstolowski: sounds like another critical 2.36 pr
<Chipaca> how's our favourite unicorn factory?
<pstolowski> Chipaca: sure, i'm in touch with mvo on that
<pstolowski> and fix is in progress
<Chipaca> pstolowski: ð
<Chipaca> or maybe ð
<Chipaca> Â¯\_(ã)_/Â¯
<mborzecki> can i get 2nd reviews on https://github.com/snapcore/snapd/pull/6023 ?
<mup> PR #6023: overlord/snapstate, snap, wrappers: start services in the right order during install <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6023>
<mborzecki> off to pick up the kids
<zyga> FYI, latest GitHub status
<zyga> The majority of restore processes have completed. We anticipate all data stores will be fully consistent within the next hour.
<zyga> I just pushed a patch without erorrs
<zyga> I take that back
<zyga> comments I added just disappeared
<zyga> comment showed up and disappeared again
<zyga> fun
<Chipaca> zyga: were any of your reviews of 6026 a +1?
<zyga> Chipaca: let me look
<Chipaca> zyga: all I see are a bunch of "crux of the issue" comments :-)
<Chipaca> was wondering if I should merge it
<zyga> let me try to give it a +1
<zyga> my changes elsewhere on GH just go away after I reload
<sborovkov> Hi, is there some interface that allows me to change the scaling_governor on the core?
<zyga> sborovkov: let me look
<zyga> Chipaca: green, merge it
<Chipaca> zyga: ooh i see your +1
<zyga> sborovkov: no, I'm afraid not
<Chipaca> would that be cpu_control, or do we need power_control?
<sborovkov> zyga, is it something that's possible to add? basically we are running on rpis. we want to change the scaling governor to performance. Otherwise while it winds up video performance goes down
<ogra> cpu-control sounds about right
<sborovkov> and it goes down by a lot
<zyga> yeah, I agree with ogra
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<zyga> feels like a reasonable tweak
<ogra> sborovkov, thats weird, the ondemand governor sshould surely cope
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<sborovkov> ogra, it does work properly after some time. But when we have a fresh run - the times it takes us to render a frame goes upo from 32 to 64 ms for first 20 seconds and so
<Chipaca> ogra: it takes about a second to ramp things up though, doesn't it?
<ogra> (while we should add thiss to the interface, you should definitely not see much differenec in system behaviour when switching governors ... just that it doesnt clock down after it is done with processing)
<sborovkov> that looks so bad on the customer screens
<Chipaca> oh wow that's more than i'd expect
<sborovkov> basically the timings were 2 times worse
<sborovkov> once we enabled performance governor we never saw anything like that
<zyga> sborovkov: can you add this to your snap
<ogra> wow, is that with accelerated graphics or plain framebuffer?
<zyga> and show me the --devmode denial
<zyga> I can make a modification to the interface
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<ogra> i definitely dont see that with the kms driver
<Chipaca> aaaaah now my pr is half-merged
<ogra> non-kms indeed means you fully utilize the CPU and completely leave the GPU alone
<zyga> Chipaca: what?
<ogra> zyga, github fun today :)
<zyga> wow,
<zyga> yeah
<zyga> I think today is not a good GH day
<ogra> i actually learned their 404 pick is interactive !
<ogra> *pic
<ogra> i never stayed long enough on it to even notice
<ogra> but if you wiggle the mouse it makes nice layer shifting effects
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<sborovkov> alright I will need to build a devmode snap though or try it from some other one guys, I will write back when I do that. ogra  what do you mean accelerated graphics or plain framebuffer? we do use h/w decoder. and yeah showing stuff with qt's qml, so it's using framebuffer
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<ogra> sborovkov, i mean the kms drm driver when you set "dtoverlay=vc4-kms-v3d" in config.txt (this turns on accelerated GLES )
<sborovkov> that's not enabled at the moment
<sborovkov> it was breaking our qt app previously on the core
<sborovkov> I should try to see if it works now actually
<ogra> well, probably not without a compositor ... not sure
 * ogra curses about this silly x11 restriction that forces you to add a .desktop file for a kiok app 
<ogra> *kiosk
<zyga> re
 * zyga turned on the heater 
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
 * Chipaca hugs mup
<zyga> Pushing stuff to GH feels pointless now
<zyga> the patches show up
<zyga> the diff stays stale
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<Chipaca> zyga: let's move back to launchpad
<zyga> mborzecki: anyway, I pushed trivial fixes to https://github.com/snapcore/snapd/pull/6010
<mup> PR #6010: cmd/snap-discard-ns: add support for per-user mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/6010>
<Chipaca> zyga: â¦ or did you?
<mborzecki> heh gh is the new single point of failure of modern software dev
<mborzecki> pretty much that what we try to avoid when  designing stuff ;)
<zyga> mborzecki: wait until Microsoft moves GitHub to azure ;-)
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mborzecki> 13h+ of outage
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mborzecki> so does it make any sense to push stuff now or not?
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<Chipaca> mborzecki: probably not
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mborzecki> ehh
<mborzecki> damn
<mborzecki> hmm 2018-10-22 14:50:23 Cannot allocate google:ubuntu-18.10-64: cannot find any Google image matching "ubuntu-os-cloud-devel/daily-ubuntu-1810-cosmic-v20181002" on project "ubuntu-os-cloud-devel"
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<Chipaca> mborzecki: get master
<Chipaca> mborzecki: that was fixed by the cachio late friday
<mborzecki> ah ok
<Chipaca> #6024
<mup> PR #6024: tests: new cosmic image for spread tests on gce <Created by sergiocazzolato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6024>
<Chipaca> you'd call that "saturday"
<Chipaca> :-)
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<zyga> yeah, mup, thanks for reminding us
<mborzecki> probably integration hooks firing as they restore the data
<zyga> feels like starting an old card with water instead of gas
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<zyga> *cough* *cough* maybe this time it will wrok
<zyga> lol
<mup> PR snapd#6027 closed: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <Complex> <Squash-merge> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6027>
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<zyga> Chipaca: standup?
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6027 closed: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <Complex> <Squash-merge> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6027>
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<zyga> holly smokes GH, calm down
<mup> PR snapd#6027 closed: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <Complex> <Squash-merge> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6027>
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6027 opened: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <Complex> <Squash-merge> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6027>
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<zyga> https://media.ccc.de/v/ASG2018-173-libcapsule
<zyga> I think mborzecki will find it interesting
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mborzecki> zyga: thanks, will watch it
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6027 opened: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <Complex> <Squash-merge> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6027>
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<ogra> looks like they are wiggling the cable at GH
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6027 opened: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <Complex> <Squash-merge> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6027>
<mup> PR snapd#6027 closed: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <Complex> <Squash-merge> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6027>
<mup> PR snapd#6027 opened: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <Complex> <Squash-merge> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6027>
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mborzecki> mup really likes that PR
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6027 opened: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <Complex> <Squash-merge> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6027>
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<niemeyer> Yeah, something is not quite right there
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<niemeyer> Hello all
<zyga> hey
<zyga> GH is broken for the last ~14 hours
<niemeyer> Wow.. that's a long trail at status.github
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<zyga> trail of fire
 * Chipaca pushes his luck
<zyga> I get 404 on pull request pages now
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<Chipaca> I just created #6028
<ogra> at least you can play with your mouse with the 404 pic
<Chipaca> â¦ i'm feeling lucky
<zyga> 404
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<Chipaca> I've got an idea
 * Chipaca considers taking the afternoon off
<zyga> hah
<zyga> I was thinking the same thing
<zyga> I can go on a bike
<zyga> it's bright still
<zyga> and not like gh is now back and working
<zyga> btw, all systems go has plenty of other interesting videos\
<zyga> I strongly recommend them
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<Chipaca> it's lovely out
<Chipaca> I'll take the dog for a walk, then take the boys for a run, then go have tapas
<zyga> enojy
<Chipaca> I see *ZERO* problems with this plan
<zyga> refresh
<Chipaca> :-)
<mup> PR snapd#6027 closed: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <Squash-merge> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6027>
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6026>
 * Chipaca refreshes
<zyga> self :)
<Chipaca> zyga: still 404
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<ogra> i think mup would appreciate if the snap command wouldnt panic on "snap try" ...
<ogra> (just a guess though)
<seb128> Chipaca, bug 1773174 ... did the fix got merged? there has been a recent comment which seems to suggest it's still an issue (but that has no details on version used, distro serie, etc)
<mup> Bug #1773174: Dutch lowercase translation warnings <amd64> <apport-bug> <bionic> <snapd (Ubuntu):In Progress> <https://launchpad.net/bugs/1773174>
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6027 closed: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <Squash-merge> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6027>
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<Chipaca> seb128: the bug is in the translations in 18.10
<Chipaca> seb128: when the bug was reported we filed suggestions in the translations thing
<sborovkov> ogra, it's not possible to set force_turbo to 1 right now on the rpi, right?
<Chipaca> seb128: last time i checked, two had not been reviewed yet
<Chipaca> i thought i'd answered that person though
 * Chipaca writes it out again
<seb128> Chipaca, so you rely on ubuntu langpacks or how does it work?
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<Chipaca> ogra: can you mute mup for a bit?
<Chipaca> i keep on getting pinged :-)
<Chipaca> i could ignore him
<Chipaca> hm
<Chipaca> seb128: translations in ubuntu come from langpacks yes
<Chipaca> at least that's my understanding
<seb128> but snapd is not Ubuntu specific
<seb128> you can't rely on the Ubuntu langpacks to be providing your .mo
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<Chipaca> seb128: but the bug is about ubuntu
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6028 opened: testutil, cmd/snap: introduce and use testutil.EqualsWrapped and fly <Created by chipaca> <https://github.com/snapcore/snapd/pull/6028>
<sborovkov> ogra, would you accept PR that adds force_turbo to the list of rpi-config options. Looks like it's super critical for us to set it (most likely for others). Our rendering time when it's set goes from 32 to 16 ms per frame on the videos.
<seb128> Chipaca, right, but I guess snapd source includes those translations, do you fix them directly there?
<mup> PR snapd#6028 closed: testutil, cmd/snap: introduce and use testutil.EqualsWrapped and fly <Created by chipaca> <https://github.com/snapcore/snapd/pull/6028>
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<Chipaca> seb128: we sync them from launchpad, and the last pull we noticed we weren't getting the fixes so we also fixed them there, yes
<seb128> k, good, thx
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<Chipaca> seb128: a little bit more info and my thoughts on this just added to the bug
<Chipaca> (i thought i'd done it over the weekend, but must've gotten side-tracked before hitting submit)
<mup> PR snapd#6027 closed: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <Squash-merge> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6027>
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6026>
 * Chipaca adds mup to the ignore list
 * Chipaca breathes in relief
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<seb128> Chipaca, thx
<mup> PR snapd#6026 opened: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mup> PR snapd#6026 closed: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<ogra> Chipaca, done (sorry, was in a call) ... a reminder later to unquieten it again would be nice (i might forget)
<ogra> sborovkov, doesnt that void the warranty of the board ? (not sure, but i think i remember something like that)
<sborovkov> nope
<sborovkov> https://elinux.org/RPiconfig#force_turbo_mode
<sborovkov> we can increase voltage and set this flag without voiding the warranty
<ogra> sborovkov, well ... https://www.raspberrypi.org/forums/viewtopic.php?p=176865#p176865
<ogra> looks like manually setting the single values doent void it but using the force_turbo option doe
<ogra> *doesnt/does
 * cachio afk
<sborovkov> I am confused about how you word it :)
<sborovkov> https://www.raspberrypi.org/documentation/configuration/config-txt/overclocking.md
<sborovkov> this also states that setting only force_turbo is fine
<sborovkov> and we don't really want to set anything else/overclock
<ogra> force_turbo -> "Forces turbo mode frequencies even when the ARM cores are not busy. Enabling this may set the warranty bit if over_voltage_* is also set."
<ogra> so you cant combine it with over_voltage_* stuff
<sborovkov> right, but we are not going to do that
<ogra> not sure if we offer any over_voltage settings in the core config ... if not, just adding force_turbo hould be fine
<sborovkov> https://github.com/snapcore/core/blob/master/hooks/configure#L131
<sborovkov> no over voltage
<ogra> well, its not a question about what you do but about us offering a setting where you can void the warranty without any warning :)
<sborovkov> sure, but is not it the user responsibility https://github.com/snapcore/core/pull/98
<ogra> after all you could always add a hack that modifies the config.txt from the gadget ... since you own the gadget ... so we need to be sure what we offer for the general users is safe
<sborovkov> ogra, no, core overwrites the config options
<sborovkov> and can't users actually void warranty if they want :) it's their own device
<ogra> sborovkov, i'd upvote the PR if GH weould not sshow me a 404 :)
<ogra> they can ... but we dont really have a way to warn them if they just blindly call snap set
<sborovkov> yeah I can't load it anymore
<ogra> once GH is back to live i'll vote for it
<sborovkov> hm, since this value is not in the list of supported options
<sborovkov> if I set it in config.txt
<sborovkov> core won't overwrite it, right?
<ogra> yeah
<ogra> it only touches stuff it knows
<ogra> for everything else the gadget owner is the master
 * zyga EODs and goes to take some time off from screens
<sborovkov> ogra, the problem though is that if it's not in snapd we can't push out the change to the old users. even with gadget snap update
<ogra> yep
<ogra> i know :) ... so let get that change in
<ogra> *letss
<ogra> geez ! ... i hate my "S" key
<ogra> (50% of the time it doesnt work, when it works it duplicates the char)
 * Chipaca EODs as well
 * Chipaca puts 20 "S" keys in the mail for ogra 
<ogra> haha
<ogra> i really dont get how i manage to kill every keyboard within a year ... i had a model-M for 10 year that never had issues ...
<ogra> *yearss
<ogra> (GRRR)
<Chipaca> ogra: remap the s to the z and viceversa
<Chipaca> ogra: zuddenly you'll be zuper zmart
 * Chipaca runs away
<sborovkov> ogra, at least you have one keyboard. on my laptop I had US keyboard. When I went for the battety replacement (on warranty_ they replaced it with a Russian keyboard where enter key is completely diffrent.
<ogra> i have like 20 keyboards ... each with a different broken key though :)
<sborovkov> and they told me that it's my problem that I don't like it... Nevermind that they sold me laptop with the US layout.
<ogra> i just need to combine them into a single one one day
<ogra> luckily my laptop kbd still fully works
<ogra> but i prefer a proper mechanical keyboard with clicky switches and all
<pstolowski> zyga: 6017 needs you re-review
<zyga> Ack
<zyga> pstolowski: can you reply to https://github.com/snapcore/snapd/pull/6017/files#r226451342
<pstolowski> zyga: ah, thanks, got confused. applied.
<zyga> pstolowski: approved now
<pstolowski> thanks
<pstolowski> cachio: ping
<kyrofa> Hey there pstolowski, do you know if we have any docs about `assumes`?
<pstolowski> kyrofa: no, degville may know?
<pstolowski> kyrofa: and hi btw :)
<degville> kyrofa / pstolowski: I've not seen any, actually.
<kyrofa> Alright, thanks guys-- I'll experiment!
<pstolowski> kyrofa: please document your findings ;)
<kyrofa> pstolowski, overlord/snapstate/check_snap.go
<kyrofa> It seems one can rely on both snapd versions as well as specific features, but that set of features has long languished
<pstolowski> yeah i remember hearing about that, never used it nor seen in action
<kyrofa> There also at first glance seems to be no way to list the features supported by your version of snapd
<pstolowski> kyrofa: might be a good forum topic
<kyrofa> I've never used it/seen it used either, but we're about to start using command-chain in snapcraft so we've started thinking about adding an assumes to essentially every snap. I'm getting increasingly nervous using a feature that no one uses though :P
<kyrofa> pstolowski, mvo is it too late to get a PR adding a feature to the featureset into 2.36?
<pstolowski> kyrofa: he is at the sprint in us this week
<kyrofa> Ah yes, because zyga can't I suppose
<pstolowski> indeed
<kyrofa> pstolowski, what do YOU think about that? Not sure what your release process is
<pstolowski> kyrofa: depends on the complexity/risk i suppose, at this moment we're trying to land fixes for last-minute critical release blockers found in last couple of days
<cachio> pstolowski, hey
<kyrofa> Well, I'll propose it anyway, would be nice to get it into the actual release that contains the feature, but will still be useful if not
<pstolowski> cachio: hey, sent you an email
<cachio> pstolowski, ok, I'll play with the nested vm to see if I can make the serial usb adapter visible
<cachio> pstolowski, I'll ping you once I have some news
<pstolowski> cachio: ok, please reply to the email if you have something, i'm about eod
<cachio> pstolowski, sure
<pstolowski> kyrofa: sure, do that
<kyrofa> If github will actually work...
<kyrofa> pstolowski|afk, https://github.com/snapcore/snapd/pull/6029, easiest review of your life
<pstolowski|afk> kyrofa: ah, that looks simple and very safe indeed!
<kyrofa> degville, by the way, how would you suggest handling documentation changes for an upcoming release? Wait until it's released and then update everything?
<degville> kyrofa: I'd right the documentation anyway, if feasible, with a caveat or 'engineering' blockquote as a caveat.
<degville> kyrofa: we could then remove the caveat on release, and add any new documentation to the outline (I wouldn't add them to the outline before features are available in stable).
<degville> s/right/write <- terrible!
<kyrofa> degville, what if it was an update to existing docs?
<kyrofa> (something already in the outline)
<degville> kyrofa: the current plan is to have both side-by-side, with a clear note saying "This is for version/upcoming version."
<kyrofa> Alrighty, thanks!
<degville> kyrofa: np. but really, whatever's easier to work with. If you wanted to create a separate post, that would work too. I could then work it into the docs when it's ready to go.
<mvo> 6022 needs a second review - should be trivial :)
<mvo> and good morning
<kyrofa> Nooo, webhooks are down again
<cjwatson> sergiusens: Uh, so do we have to finish the launchpad-buildd rollout as an emergency?  (bug 1791201)
<kyrofa> cjwatson, I'm not sure what you've discussed in the past, but note that's only for bases
<cjwatson> kyrofa: Doesn't the new version of snapcraft significantly change behaviour if SNAPCRAFT_BUILD_ENVIRONMENT=host isn't passed, then?
<kyrofa> cjwatson, yes, but only if using bases
<cjwatson> kyrofa: You're sure nobody's using base: 16?
<cjwatson> sergiusens: Also, please don't mark launchpad-buildd bugs Fix Released.  That fix isn't rolled out yet
<cjwatson> (base: core16, I mean)
<kyrofa> cjwatson, such snaps fail to build as far as I'm aware, and don't install either. There are some using core18, but if I remember correctly they aren't using LP to build. sergiusens will of course know more
<Gargoyle> Hey there.
<kyrofa> Hey there Gargoyle, welcome
<Gargoyle> This is currently the file dialogue for atom (and slack, so probably all electron apps). Is this something in my snapd setup that needs fixing or do the individual snaps need updating? https://www.dropbox.com/s/pblpsnbyvuvez1z/atom.png?dl=0 ( snap versions = https://paste.ubuntu.com/p/JG6FkgDZCK/)
<cjwatson> kyrofa: Yeah, I know core18 won't work yet.  OK, maybe not an emergency then
<kyrofa> Gargoyle, what does it look like normally?
<kyrofa> Gargoyle, popey might be able to help here, he's much more familiar with those snaps
<Gargoyle> kyrofa: It's missing any kind of colour, padding or icons compared to say LibreOffice dialogue.
<Gargoyle> OK. Thanks. I'll wait and see if he chimes in.
<kyrofa> Gargoyle, for what it's worth, the vscode dialog looks unremarkable to me: native. What OS are you on?
<Gargoyle> Ubuntu 18.10.
<Gargoyle> I'll throw a screen grab of LibreOffice for comparison.
<Gargoyle> https://www.dropbox.com/s/hacpaoxi58djukq/lo.png?dl=0
<kyrofa> Perhaps theming is having some issues on 18.10
<kyrofa> (I'm on 18.04)
<Gargoyle> Does anything theme wise in snapd rely on the system as it was when snapd or snaps were installed (I recently reverted back to ubuntu-session and removed gnome-session.)
<indio> Hi. I'm on trisquel linux 8 which is package compatible with ubuntu xenial 16.04 and would like to install snapd. Since there's no snapd in trisquel repo I needed a snapd package from a PPA and the only one I could find is ppa:snappy-dev/edge. I just wanted to know if there is a stable PPA ? Thanks.
<Saviq> cachio: hey, I saw you have a dedicated -nested-vm image for spread, is that something available in general for GCE or are you building this image yourself for this purpose?
<sergiusens> cjwatson: sorry about that, was a glitch in my brain, I have the impression I quickly switched it back though, sorry if that was not the case
<sergiusens> cjwatson: about `base: core16` or bases in general, I did have a conversation with wgrant here on how to move that forward, we need to iron it out a bit, but there is nothing to worry about today at all
<cachio> Saviq, hey, I am building this vm
<cachio> Saviq, kyrofa requested that for snapcraft
<cachio> why?
<kyrofa> Saviq, we're using it for build VM tests, using multipass. It's all mine though, you can't have it
<Saviq> cachio: we'd use it for multipass with spread for sure, but we've had someone try multipass on GCE and I was wondering if nested vm is even supported by default
<Saviq> cachio: what's special about it?
<Saviq> kyrofa: I'll remember that! ;P
<kyrofa> Saviq, :P
<kyrofa> You have to enable it, cachio worked his magic: https://cloud.google.com/compute/docs/instances/enable-nested-virtualization-vm-instances
<cachio> Saviq, nested vms are supported but if you want to use kvm you need to build an image for taht
<Saviq> aha, interesting
<cachio> Saviq, otherwise you are able to create a nested vm using qemu by default
<Saviq> cachio: qemu without kvm, that is? so not really virtualization :)
<cachio> Saviq, yes, kind of virtualization
<Saviq> == emulation
<Saviq> cachio: if I wanted to run spread tasks on GCE do I need to get added to the project or something?
<cachio> Saviq, you want to use those images to run the spread tasks?
<Saviq> cachio: yup
<cachio> Saviq, so, you need just to use
<cachio> image: ubuntu-1604-64-nested-vm
<cachio> image: ubuntu-1804-64-nested-vm
<cachio> for xenial and bionic
<cachio> I'll create tasks to keep them updated next week
<cachio> then you can use them normally
<kyrofa> Saviq, for reference: https://github.com/snapcore/snapcraft/blob/master/spread.yaml#L37
<Saviq> cachio: yeah, but to run that from my laptop?
<Saviq> like I go to https://console.cloud.google.com/compute and I have no projects there, should I?
<cachio> Saviq, you should have computeengine
<cachio> Saviq, this is ou rproject
<Saviq> ah maybe I should switch to the right account...
<cachio> to the canonical one :)
<Saviq> still, I can only create a new project, can't see any existing one
<cachio> Saviq, did you see computeengine before?
<Saviq> no
<cachio> or it is the first time you try that
<cachio> Saviq, in that case you need gustavo
<Saviq> ack
<Saviq> tx
<cachio> Saviq, he manages the permissions, roles, etc
 * cachio afk
<niemeyer> Saviq: You were already in the account
<niemeyer> Saviq: You should be able to login and use our project
<Saviq> niemeyer: not sure what I'm doing wrong, then, I can only create a new project :/
<niemeyer> Saviq: Well, you can do lots of things I'm sure :)
<niemeyer> Saviq: The question would be why the one thing you can do, which is logging in with your Canonical credentials so you get proper spread access, not working?
<niemeyer> Saviq: I'm out of context, though..
<niemeyer> Saviq: What's failing?  Which error are you getting?
<Saviq> niemeyer: I go to https://console.cloud.google.com/projectselector/compute/ and I can't see any projects
<Saviq> (and if I create a project it wants my credit card :P)
<niemeyer> Saviq: Yep, sounds expected
<Saviq> oh ok I thought I should be able to see it there
<niemeyer> Saviq: No, the role provides only enough permissions for Spread to work
<Saviq> ack, trying that then
<ackk> hi, is there a way to inject ssh config/keys into the vm used by snapcraft when building?
<ijohnson> ackk: I don't know about the actual build VM work going into snapcraft 3.0, but I don't think there's a supported way for the lxd container that `snapcraft cleanbuild` creates, however if this is a git project you could store the credentials in a file that is ignored by git and have a part in the snapcraft.yaml that reads that file and uses it
<ijohnson> ackk: there may be a way to configure the default lxd profile to contain what you need, I'm not sure though
<ackk> ijohnson, but lxd is not the official way to build with 3.0 right?
<ijohnson> yeah with 3.0 I think currently only multipass is supported, but I'm not familiar with how 3.0 works with the VM yet so I can't speak to that
<ackk> ok, thanks
<ijohnson> kyrofa may know
<kyrofa> ackk, ijohnson indeed, I believe that's a problem today. I'm not sure what the ideal solution would be. sergiusens, any thoughts there?
<kyrofa> It's not a problem we ever solved for cleanbuild, either
<ijohnson> kyrofa: is there any obvious way that someone could accidentally leak credentials by storing such files in the source tree and using it in a part in snapcraft.yaml? I don't think that the sentry error reports include file contents, but I'm not sure
<ijohnson> I don't think the manifest.yaml file would leak anything if they turned that on
<ackk> ijohnson, in my case it's not credentials, I need to checkout a private branch using ssh keys
<ackk> so the config is actually in .ssh/config
<kyrofa> ijohnson, yeah I'm not sure what you mean, I'm just thinking of SSH keys as well
<ackk> kyrofa, precisely
<kyrofa> A short-term solution might be snapcraft bind-mounting that into place in the VM
<kyrofa> But I figure there's a good reason we didn't do that for cleanbuild
<kyrofa> Just not sure what it is :)
<ackk> kyrofa, sigh. and cleanbuild is the only way to properly build a core18 snap right?
<kyrofa> Build VMs, but yeah same concept
<ijohnson> I guess I was just referring generally to the files like private ssh keys, etc. You could always have a part that copies the private key from your snapcraft tree into the containers ~/.ssh/
<kyrofa> Yeah that might work around it for now. Would make me pretty nervous, make sure you filter it out
<ijohnson> right my concern was rather that even if you filter it out and be careful that snapcraft doesn't automatically include the file contents in an oops report or something, subverting all your efforts to keep it safe
<ackk> also not very generic, not everyone has the config and keys in the same place
<kyrofa> Nah, those reports are pretty spartan, and aren't automatic unless you make it so
<kyrofa> ackk, you can also use --destructive-mode which will run on the host like it does without bases, but then you exit supported territory
<ijohnson> kyrofa: ack, good to know
<kyrofa> ackk, I'm assuming you're using edge?
<ackk> kyrofa, well I was trying edge yes. I'm currently using stable for builds
<kyrofa> ackk, alright, yeah, on edge you can run `snapcraft --destructive-mode` and it won't spin up a VM, it'll run the build on the host. So you take responsibility for ensuring you're on the right host for the base, and make sure your environment isn't dirty, etc.
<kyrofa> But then you have access to things on the host, like SSH keys
<ackk> kyrofa, so that's the equivalent of the old plain "snapcraft" ?
<kyrofa> Yeah, like running `snapcraft` without bases
<ackk> I see
<ackk> kyrofa, is there an ETA on when snapcraft 3.0 will be published to stable?
<kyrofa> If you think you hit a bug in destructive mode, though, reproduce it in a build VM before reporting
<kyrofa> ackk, not of which I'm aware beyond "soon", but it should be in candidate any time
<ackk> kyrofa, cool, thanks
<Saviq> cachio: any pointers on how to set up auth for spread on google? when I run spread it bails out pointing at https://developers.google.com/accounts/docs/application-default-credentials - that then redirects to https://cloud.google.com/docs/authentication/production... all of that seem to require me to be able to see the project, and being able to create a service account on it...
<Saviq> ... but $ gcloud projects list
<Saviq> Listed 0 items.
<cjwatson> sergiusens: panic over then, thanks :-)  I will try to get that deployed this week though
#snappy 2018-10-23
<mborzecki> morning
<zyga> Hey
<zyga> mborzecki: mvo asked for release reviews today
<mborzecki> zyga: hey, ok
<mborzecki> zyga: do you know what's the status of https://github.com/snapcore/snapd/pull/5845 ? iirc it was waiting for a review from jdstrand mostly
<zyga> It also needs a new name from Gustavo
<zyga> I need to take Bit to the vet for surgery today but that should take a moment
<zyga> Iâll be in the office shortly
<mborzecki> zyga: https://paste.ubuntu.com/p/3ZwGpF6ZyT/ something i found on the laptop
<mborzecki> zyga: lrwxrwxrwx 1 root root 13 10-23 08:15 /var/lib/lxd -> /mnt/data/lxd
<mborzecki> since we test for access() removing the symlink makes it work
<zyga> Hmmm
<zyga> Yeah, the error message need improvements
<pstolowski> mornings
<mborzecki> zyga: can you take another look at https://github.com/snapcore/snapd/pull/6023 ?
<mborzecki> pstolowski: pedronis left a suggestion in https://github.com/snapcore/snapd/pull/6027
<pstolowski> yep, looking
<zyga> Ok
<zyga> Dog at vet
<zyga> Two hours after surgery for pickup
<zyga> Fingers crossed it goes well
<zyga> mborzecki: two, in 2 minutes, just going home
<jdrab> pani, VCERA SME PREMESKALI MEDZINARODNY DEN CAPS LOCKU!
<zyga> re
<zyga> uh?
<zyga> mborzecki: looking now
<mborzecki> yday was the national day of cap lock?
<jdrab> oh sry, wrong channel :D
<zyga> mborzecki: thank you for the link about Khan's Algorithm
<zyga> I wasn't aware of it, cool
<zyga> jdrab: nie szkodzi
<zyga> :)
<jdrab> ahaha :)
<mborzecki> zyga: yeah, and it's surprisingly simple once you understand it
<seb128> hey there
<seb128> $ snap changes
<seb128> ID    Status  Spawn                      Ready  Summary
<seb128> 1462  Doing   4 days ago, at 09:21 CEST  -      Auto-refresh snaps "core", "core18", "gnome-logs"
<seb128> is that "4 days ago" normal?
<seb128> or is snapd stucked in some way?
<mborzecki> pstolowski: ^^
<pstolowski> seb128: snap version?
<seb128> $ snap version
<seb128> snap    2.36~pre2+git965.966c1d4~ubuntu16.04.1
<seb128> snapd   2.36~pre2+git965.966c1d4~ubuntu16.04.1
<seb128> series  16
<seb128> pstolowski, ^
<mborzecki> pstolowski: you think that could be auto-connect?
<pstolowski> seb128: ok, and snap change 1462?
<seb128> that takes a bit...
<seb128> pstolowski, http://people.canonical.com/~seb128/log
<zyga> about that
<zyga> I think we could use RW locks on state
<zyga> so snap changes is fast
<zyga> unless I misunderstand and the delay is because of the volume of data
<mborzecki> crazy thought, but should we try to detect that stuff is getting retried indefinitely and perhaps log && abort?
<zyga> I think we do that in a way
<pstolowski> seb128: thanks. so yes, it's a known bug we've right now in master/edge, fix is being reviewed
<zyga> very old tasks get aborted
<zyga> or perhaps we meant to
<zyga> I'm not super familiar with that code
<pstolowski> seb128: as a workaround you can snap abort the change, and then remove all unused revisons of gnome-logs (snap remove --revision=....) to only leave one. alternatively, switching core to stable (after aborting the change) might help
<zyga> mborzecki: I will follow up with a validator for topological sorting in the mount backend
<zyga> at least we must detect cycles
<mborzecki> zyga: ping me for review
<zyga> with pleasure :)
<seb128> pstolowski, ok, thanks, I didn't even remember that I changed the core to a non stable channel on that box :)
<ackk> kyrofa, WRT --destructive-mode, it seems it currently only works if you don't pass a comand to snapcraft? if I try to "snapcraft prime --destructive-mode" it tries to use multipass
<ackk> is that expected?
<mborzecki> zyga: pstolowski: if i'm reading that right, the task would be auto aborted after 7 days
<zyga> that's about right
<zyga> it's a lot of time but it was meant to be conservative
<pstolowski> seb128: which is good, thanks to one other report about this we avoided releasing it (it happens under specific circumstances)
<pstolowski> mborzecki: zyga, right, we will not eat cpu indifinately or anything... but the problematic change will keep re-appearing and will never succeed (auto-refresh in this case)
<zyga> yeah
<zyga> we may have a fallback mode
<mborzecki> eat cpu and fill up the state
<zyga> if we fail to refresh and abort after 7 days
<zyga> we could do something special, like just refresh core - if installed, or snapd - if installed
<zyga> and nothing else
<mborzecki> iff we do healtchecks, this could be part of it
<pstolowski> seb128: so, thanks for using of edge, please switch back to it if possible after the fix lands, you guys have more interesting use cases than anyone else, so better chances of finding potential problems
<mborzecki> if nobody minds i can push the fixes to https://github.com/snapcore/snapd/pull/5727 that jdstrand requested
<zyga> mborzecki: +1
<seb128> pstolowski, np, thx for replying/getting me unstuck, your step worked
<pstolowski> zyga: yes, this sounds like a good idea
<zyga> mborzecki: can we land ? https://github.com/snapcore/snapd/pull/5346
<mborzecki> zyga: let me finish with the changes for breakpad and i'll take another look at it
<zyga> it's +2 and green
<zyga> breakpad?
<zyga> ah
<zyga> mozilla
<zyga> sure
<mborzecki> damn, hate running tests in snap-seccomp
<ogra> (assuming that GH behaves again i un-quietened mup again)
<zyga> mborzecki: on your laptop?
<mborzecki> zyga: anywhere, it's making the modules for all those crazy AF_* loaded
<zyga> ah right
<mborzecki> zyga: looking at the snap:// pr
<zyga> I wonder if it's ok to just merge
<zyga> morning Chipaca
<Chipaca> morning zyga
<mup> PR snapd#5985 closed: overlord/many: cleanup use of snapName vs. instanceName <Parallel installs â> <Simple ð> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5985>
<zyga> need to go to get the dog from the vet
<zyga> surgery over
<zyga> brb
<pstolowski> zyga: hmm, interesting issue from popey on the forum, 'snap interfaces' and conns state has the connection, but gnome snaps complain about lack of it; i've vague memory of something similiar before, do you remember?
<pstolowski> zyga: and it's 2.35.4
<pstolowski> zyga: was there something about profile generation you were investigating some time ago?
<pstolowski> it's https://forum.snapcraft.io/t/cant-connect-interfaces-so-cant-run-snaps/8123
<mup> PR snapd#5346 closed: cmd/snap: gnome-software install via snap:// handler <Created by jhenstridge> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5346>
<Chipaca> update sequencing makes my head hurt, still
<Chipaca> mborzecki: the snapcraft static suite doesn't like spread-shellcheck :-(
<Chipaca> mborzecki: I reformatted it with black, which passed the first hurdle, but now its flake8 is saying it's all too complicated
<Chipaca> zyga: at what  point are cmd/snap-confine/spread-tests/ run?
<zyga> Never, those are the old ones from split repo
<zyga> Probably more stale than ever
<zyga> pstolowski: still afk at vet, will be home in 10 min
<mborzecki> Chipaca: heh, we can feed spread-shellcheck to snapcraft, have them fix it to be nice python, and merge it back
<Chipaca> mborzecki: *cough* snapcraft#2381 *cough*
<mup> PR snapcraft#2381: tools: copy in spread-shellcheck from snapd <Created by chipaca> <https://github.com/snapcore/snapcraft/pull/2381>
<zyga> pstolowski: can you please ask for mount profiles
<zyga> Current and desired
<mborzecki> btw. are we having any talks about ubuntu core & snaps at ELC?
<mborzecki> Chipaca: heh, checkfile is too complex, it's the cyclic complexity check right?
<Chipaca> mborzecki: "aaah this is too complicated i give up"
<Chipaca> mborzecki: I imagined flake8 slamming the program printing down and going off in a huff
<mborzecki> Chipaca: i have some expierience working around gocyclo :P
<mborzecki> wonder if that applies to python too
<mborzecki> Chipaca: probably dropping some ifs would help
<Chipaca> mborzecki: I was going to just leave it there and see if snapcrafters would push a fix :-)
<mborzecki> Chipaca: hm ther's if > for > for > if sequence
<Chipaca> i'm going to have to figure out why flake8 locally complains about everything, making it pointless, aren't i
<Chipaca> sigh
 * Chipaca remembers the snapcraft venv, and tries that
<Chipaca> mborzecki: got it
<Chipaca> mborzecki: i'll fix
<mborzecki> Chipaca: heh, it's fun when you apply an artificial metric and thresholds and then workaround to meet the them :)
<pstolowski> popey: allright, i'll ask you to collect a bunch of other info in a moment
<popey> pstolowski: ok
<zyga> re
<zyga> dog safely home, still numb. but alive :)
<pstolowski> zyga: are the *fstab files from the host os useful, or only those from the mount namespace?
<zyga> pstolowski: we want a pair of files: /var/lib/snapd/snap.$SNAP_NAME.fstab and /run/snapd/ns/snap.$SNAP_NAME.fstab
<Chipaca> mborzecki: http://paste.ubuntu.com/p/6hmN9bKR6j/
<pstolowski> zyga: k, thanks
<zyga> thank you, let me know if you get more data
<mborzecki> Chipaca: does that bring the complexity count down?
<Chipaca> mborzecki: it brings it down to 9, apparently
<Chipaca> no, 10
<mborzecki> Chipaca: lgtm
<Chipaca> mborzecki: from 12 or 14 that it was
<Chipaca> 12
<Chipaca> mborzecki: ok, i'll push it
<Chipaca> of course now black doesn't like it
<Chipaca> :-)
<zyga> pstolowski: the .fstab files are available in all namespaces
<zyga> you don't need to be in a specific spot to read them
<pstolowski> zyga: yep, i figured by md5'suming them just to be sure ;)
<pstolowski> popey: ty! zyga, all the info there
<thresh> is there a way to make firefox in a snap to use the same mouse pointer as system-wide?
<zyga> popey, pstolowski: responded
<zyga> thresh: kenvandine would know I suspect
<ogra> you can surely fake it if you ship the cursor theme and force theme defaults for your app
<pstolowski> zyga: thanks, interesting (whether the script does the right thing)
<ogra> but thats indeed only making it a look-alike and only works as long as the default of the system has not been changed
<popey> pstolowski: fyi. I just did ctrld to exit that thing you had me enter. The second I did that something segfaulted and I lost  my entire desktop
<zyga> popey: !!
<pstolowski> woot
<zyga> can you please collect some logs
<zyga> I saw something similar on my machine once
<zyga> I was inside a mount namespace entered via nsenter
<thresh> well, me being on KDE and using breeze/dark will only make it more complex with firefox being a gtk app
<zyga> I hit exit and my desktop blinked
<zyga> I was surprised because as far as we're concerned that's just bash quitting
<thresh> but at least having the mouse pointer scaled 2x would already help
<pstolowski> popey: sorry! unintended and unexpected
<zyga> popey: are you on Wayland?
<ogra> thresh, well, my suggestion above would also not scale it ... just set a shipped default so you dont end up with the x11 pointer
<popey> No. X11
<zyga> hmmm
<zyga> collect logs please, let's try to understand what crashed
<popey> ogra: thresh mouse cursors are on kenvandine radar
<ogra> (though you could probably write a complex wrapper, read the dpi, force the theme up in scale etc etc ... but thats super hackish and pretty overkill)
<ogra> (pretty much what ken will eventually do in a clean way as popey says :) )
<thresh> gotcha
<thresh> thanks!
<popey> We shouldn't work around this but fix it
<ogra> popey, we should ... since 2 years :P
<ogra> if only the day had more hours
<popey> http://paste.ubuntu.com/p/sQtP7vmXPY/
<ogra> :D
<popey> Dmesg from my exploded session
<zyga> some things crashed on X
<zyga> but I suspect X disconnected
<zyga> and those things died as a consequence
<zyga> popey: can you look for logs of X
<zyga> not sure how yet
<popey> Yeah
<cachio> pstolowski, hey,
<zyga> TBH I'm not sure how X is started or managed nowadays
<pstolowski> hey cachio !
<cachio> pstolowski, did it work the change
<cachio> could you try it?
<pstolowski> cachio: I think it didn't, i'm just giving it another try
<zyga> for instance it _seems_ that gdb runs everything
<zyga> gdm then has gdm-session-worker as a child
<cachio> pstolowski, do you have the command line you used to start the vm?
<zyga> then gdm-x-session
<zyga> perhaps X is hidden there
<pstolowski> cachio: yes i've. let's talk in a private channel
<zyga> but no idea really
<zyga> popey: can you work with someone from the desktop team to help us understand this, if you can reproduce this the better
<zyga> popey: do you have Nvidia drivers?
<popey> I do
<popey> http://paste.ubuntu.com/p/VxM3bjHq3K/
<popey> Syslog
<zyga> popey: I see
<popey> Need to reboot to actually do some work
<zyga> Oct 23 11:30:43 hal /usr/lib/gdm3/gdm-x-session[2062]: (**) Option "fd" "84"
<zyga> Oct 23 11:30:43 hal /usr/lib/gdm3/gdm-x-session[2062]: (II) event3  - Power Button: device removed
<zyga> I think this is udev input triggering
<zyga> but no idea why it would happen
<ogra> do interfaces still call udevadm tigger ?
<ogra> iirc we had some doing that
<zyga> Oct 23 11:30:39 hal org.gnome.Shell.desktop[2197]: Window manager warning: last_focus_time (773055215) is greater than comparison timestamp (773055214).  This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW.  Trying to work around...
<zyga> then all hell breaks loose it seems
<zyga> ogra: regardless of what happens in udev - in this case we were not using interfaces
<zyga> popey just closed bash
<ogra> ouch, ok
<popey> well, i closed the command I had opened in bash
<zyga> popey: right
<zyga> it should not have happened
<zyga> btw, I have the same mouse :)
<popey> :)
<zyga> Oct 23 11:30:46 hal /usr/lib/gdm3/gdm-x-session[2062]: (EE) NVIDIA(GPU-0): Failed to acquire modesetting permission.
<zyga> this is interesting
<zyga> but TBH I think the X + Nvidia combo is something someone needs to look into
 * zyga has no nvidia
<zyga> popey: do you think it would help if I had a GPU at home?
<zyga> I could stick it into my test desktop for cases like that :/
<popey> ð¤·ââï¸
<mborzecki> what what nvidia?
<zyga> popey: Oct 23 11:30:46 hal /usr/lib/gdm3/gdm-x-session[2062]: (EE) Please also check the log file at "/var/log/Xorg.1.log" for additional information.
<zyga> do you still have that log files?
<zyga> perhaps X log has more fun stuff
<zyga> Oct 23 11:30:46 hal /usr/lib/gdm3/gdm-x-session[2062]: (WW) NVIDIA(0):  - Setting a mode on head 0 failed: Insufficient permissions
<zyga> Oct 23 11:30:47 hal nautilus[13429]: nautilus: Fatal IO error 11 (Resource temporarily unavailable) on X server :1.
<zyga> so my theory is as follows:
<zyga> something is broken in the desktop session and your ctlr+d went to X
<zyga> X got nuts and went belly up
<zyga> apps died making lots of noise when X disconnected
<zyga> I think a  test case is to:
<zyga> open bash just like you had befor
<zyga> (nsenter and such)
<zyga> and ctrl+d
<zyga> perhaps open the same apps
<zyga> not sure if there's a catalyst that makes this happen
<zyga> remember when ctrl-c was killing gdm?
<zyga> because overzealous input somewhere
<mborzecki> popey: what did you do?
<popey> good question
<mup> PR snapd#6030 opened: cmd/snap: tweak `snap services` output when there is no services <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6030>
<mborzecki> popey: i mean, what command did you run? i don't see it in the log
<popey> sudo nsenter -m/run/snapd/ns/gnome-calculator.mnt
<zyga> so you were root
<popey> and now I have rebooted, the snaps that didn't work, now work
<ogra> zyga, popey https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1710637
<zyga> (not that it would explode because you were root and wrote ctrl+d)
<popey> i cant see that ogra
 * zyga can
<zyga> but that was fixed in 2017
<ogra> that was the "ctrl+c (or +d) kills gdm" bug
<zyga> that's the bug where Ctrl-c goes to the wrong place
<zyga> but
<zyga> popey: I'll add you there
<zyga> can you read the last few comments
<zyga> done
<zyga> there's a command
<zyga> wait
<zyga> 503
<zyga> :/
<zyga> still 503
<mborzecki> heh, pefect timing
<mborzecki> zyga: btw. that PR ^^ hopefuly Chipaca and degville can help come up with a message that makes sense :)
<zyga> popey: ok, as a quick reproduce test
<popey> Note, I haven't restarted my system for 15 days before this happened
<popey> I seem to see all these odd issues because I have "long" uptimes
<popey> stuff seems to get itself well wedged as a result
<zyga> popey: run as root: udevdm trigger; udevadm settle --timeout=10
<zyga> this _may_ trigger bad stuff
<zyga> so mind the abyss
<zyga> then try the nsenter thing again
<zyga> I have a feeling we should stop using udev rules for tagging
<zyga> and use croups
<zyga> cgroups
<ogra> croups ?
<zyga> moronic spellchecker
<ogra> croutons ?
<ogra> :)
<zyga> cre^p du kernel ;)
<ogra> :D
<popey> Yes
<popey> That did bad things
<popey> Desktop exploded
<zyga> perfect
<zyga> package this in a bug report
<popey> Thanks
<zyga> along with system version, the driver you had (version) and perhaps the make of the card
<zyga> we will take it from there
<popey> Against gdm3?
<zyga> and I'm very sorry for the inconvenience this is causing
<popey> Or snapd
<zyga> against snapd first
<popey> Kk
<zyga> so that we can alter the status
<zyga> we can affect others as we discover
<popey> Will do
<zyga> woot!
<popey> Nice one
 * zyga inserts mental model of a plane falling on fire with two engineers watching from the ground, congratulating each other, one saying "woot, you were right, it was the fuel injection pump" 
<popey> This is separate from the original issue though, right :)
<zyga> "reproduced"
<zyga> I think so
<zyga> popey: I don't have recent enough hardware but I will see if this happens without nvidia
<zyga> and then buy a card for testing
<zyga> and upcoming chunk of Nvidia work anwy
<zyga> wooot
<zyga> reproduced like hell
<zyga> popey: no nvidia neede
<zyga> we need to get off of udev
<zyga> touching udev is bad
<zyga> here's my login screen
<zyga> I think willcooke is on a sprint now, right?
<popey> https://bugs.launchpad.net/snapd/+bug/1799433
<mup> Bug #1799433: GNOME desktop on nvidia crashes when exiting nsenter <snapd:New> <https://launchpad.net/bugs/1799433>
<zyga> popey: funny, in my case something crashed, desktop blinked but my programs were intact
<zyga> I logged in and it was back
<popey> hah
<zyga> but it's clearly broken
<popey> I am happy for you :)
<diddledan> OT https://github.com/features/actions
<pstolowski> zyga: see my comment re that problem
<zyga> pstolowski: replied
<pstolowski> zyga: ah, sorry, let me remove this not to bring confusion
<mborzecki> zyga: it does not reproduce here, i mean udevadm trigger && settle and nsenter
<mborzecki> zyga: popey: nope, maybe i'm doing something wrong
<zyga> mborzecki: we're talking in the #ubuntu-desktop channel as well
<zyga> same, I cannot reproduce it again
<zyga> maybe I was just very lucky
<zyga> (that one time)
<mborzecki> zyga: popey: i'm looking through my irc logs, but i recall we discussed a similar case when udevadm trigger with nvidia would bring down the whole session
<popey> yeah
<zyga> mborzecki: note, I was not on nvidia
<popey> this is familiar
<mborzecki> popey: do you remember what that was?
<popey> not without grepping logs
<popey> https://forum.snapcraft.io/t/weird-udev-enumerate-error/2360/9
<mborzecki> popey: heh, grepping is what i do, i really wish i had that indexed by xapian or sth
 * zyga lunches
<mborzecki> popey: zyga: i think last time we discussed this: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/1760104
<mup> Bug #1760104: Xorg crashed with SIGSEGV in InputReady() from ospoll_wait() from InputThreadDoWork() <amd64> <apport-crash> <bionic> <compiz-0.9> <single-occurrence>
<mup> <ubuntu> <snapd:Invalid> <nvidia-graphics-drivers (Ubuntu):Confirmed> <xorg-server (Ubuntu):Confirmed> <https://launchpad.net/bugs/1760104>
<mborzecki> off to pick up the kids
<zyga> indeed
<zyga> interesting
 * pstolowski lunch
<dot-tobias> Hi greyback, may I ask if you found the time to identify the cause for the rotation issue in chromium-mir-kiosk (https://discourse.ubuntu.com/t/snaps-to-develop-a-web-kiosk-on-ubuntu-core-using-wayland/6424/87) when rotating mir-kiosk to portrait mode (https://community.ubuntu.com/t/display-configuration-for-mir-kiosk/7815/3)? I'm currently building the snap with an altered i3 config which sets default_orientation = vertical. Does not seem to help,
<dot-tobias>  except I get a short i3 nagbar âyou have an error in your configuration fileâ, but I cannot figure out what the error is.
<ogra> dot-tobias, did you try shipping xrandr and use its rotation feature ?
<greyback> dot-tobias: hey, my apologies but I've been focused elsewhere.
<ogra> alternatively i think you would actually need a mir config to force the rotation
<ogra> https://community.ubuntu.com/t/configuring-mir-kiosk-a-masterclass/8150
<greyback> ogra's idea is worth a try, but I suspect it is i3 itself that isn't dealing with the X display rotation
<greyback> alan_g looked into it and it did appear that Xwayland was being correctly told by mir that the display had rotated
<dot-tobias> ogra: Not yet, was hoping I could achieve this through config files. Adding a layout for mir-kiosk rotates just fine, but chromium-mir-kiosk (which uses i3) does not pick up on it.
<ogra> ouch
<greyback> dot-tobias: as (lousy) workaround, could you make i3 size the chromium window in pixels at the size you desire?
<ogra> i'll hit that myself soon, working on https://snapcraft.io/magicmirror to build a pre-configured appliance image :)
<dot-tobias> greyback: Yeah, that workaround is building right now on my Pi ð But good to hear that would actually work.
<ogra> uh, you build on your pi ?
<ogra> use build.snapcraft.io ;)
<ogra> (it might fail to release, but you can still directly download the bult snap from there)
<ogra> *built
<dot-tobias> I use launchpad in parallel, but we're hosting everything on Gitlab.com which is currently not supported by build.snapcraft?
<greyback> dot-tobias: it shoud work, afaics i3 just isn't sizing the chromium surface by flipping the width/height
<ogra> ah, right
<ogra> launchpad offers git imports into local LP trees ... you might be able to use that with gitlab, not sure
<dot-tobias> ogra: That's actually exactly what I used, but good to hear I went in the right direction ð
<ogra> heh
<mup> PR snapd#6031 opened: snap/pack, cmd/snap: allow specifying the filename of 'snap pack' <Created by chipaca> <https://github.com/snapcore/snapd/pull/6031>
<mup> PR # closed: snapd#5170, snapd#5644, snapd#5696, snapd#5712, snapd#5714, snapd#5727, snapd#5789, snapd#5792, snapd#5822, snapd#5845, snapd#5885, snapd#5887, snapd#5897, snapd#5915, snapd#5916, snapd#5946, snapd#5954, snapd#5955, snapd#5958, snapd#5962, snapd#5963, snapd#5972, snapd#5981,
<mup> snapd#5982, snapd#5987, snapd#5996, snapd#6000, snapd#6008, snapd#6010, snapd#6016, snapd#6019, snapd#6023, snapd#6025, snapd#6027, snapd#6028, snapd#6030, snapd#6031
<mup> PR # opened: snapd#5170, snapd#5644, snapd#5696, snapd#5712, snapd#5714, snapd#5727, snapd#5789, snapd#5792, snapd#5822, snapd#5845, snapd#5885, snapd#5887, snapd#5897, snapd#5915, snapd#5916, snapd#5946, snapd#5954, snapd#5955, snapd#5958, snapd#5962, snapd#5963, snapd#5972, snapd#5981,
<mup> snapd#5982, snapd#5987, snapd#5996, snapd#6000, snapd#6008, snapd#6010, snapd#6016, snapd#6019, snapd#6023, snapd#6025, snapd#6027, snapd#6028, snapd#6030, snapd#6031
 * Chipaca hugs mup
<mup> Issue core18#86 opened: Ubuntu 18.10 <Created by kravietz> <https://github.com/snapcore/core18/issue/86>
<diddledan> did mup just vomit?
<diddledan> lots of "PR # closed"
<ogra> it rather "released a constipation"
<diddledan> aha. stinky mup!
<dot-tobias> ogra: (late reply re: rotation & mirror applkiance after AFK) BTW using display_rotate and dtoverlay=vc4-fkms-v3d (https://github.com/michmich/magicmirror/wiki/configuring-the-raspberry-pi#enable-the-open-gl-driver-to-decrease-electrons-cpu-usage) works most of the time with mir-kiosk, but it produced some funny rendering issues and the Pi heats up considerably. Had two temp-induced reboots,
<mup> PR snapd#5981 closed: interfaces/many: updates to support k8s worker nodes <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5981>
<Chipaca> hmmm
<Chipaca> i should probably have lunch
<ogra> isnt that linner already ?
<ogra> dot-tobias, fkms is 100% SW rendering, it completely turns off the GPU
<ogra> your board will overheat if you run it for a while
<dot-tobias> ogra: that's what I thought, and observed â¦ I'll test the i3 resizing and/or xrandr route once I'm back at the office.
<ogra> either use the kms driver and gallium or somehow get the closed source driver to work ... but i doubt thats possible without also patching the kernel
<ogra> sadly using kms means no rotation before mir comes up (i.e. splash screen)
<zyga> mborzecki: could you please review https://github.com/snapcore/snapd/pull/6010
<mup> PR #6010: cmd/snap-discard-ns: add support for per-user mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/6010>
<zyga> you did in the past but not fully (vote vote vote)
<zyga> mborzecki: I'll review your ordering PR next, I stopped on Khan before and then it got lost in a tab swarm
<dot-tobias> ogra: is that what you mentioned about the missing /dev/fb0 in your PR @ https://github.com/snapcore/pi3-gadget/pull/13 ? Or unrelated? I could live with an always-portrait splash for now ð
<mup> PR pi3-gadget#13: add splash support <Created by ogra1> <https://github.com/snapcore/pi3-gadget/pull/13>
<ogra> dot-tobias, the missing framebuffer is caused by the vc4 module not being in the initrd ...
<ogra> dot-tobias, i have a workaround in my pi-kiosk gadget
<ogra> https://github.com/ogra1/pi-kiosk-gadget
<ogra> and the next kernel should actually even add the modules to the initrd by default so only the modprobe call might be needed (if at all) ... i'm not sure where we stand with that though ... ppisati is your man
<tomwardill> hello! another question about pre-refresh hooks, which version of the hook do they execute? The installed version or the about-to-be-installed one?
<tomwardill> the docs here https://docs.snapcraft.io/supported-snap-hooks/3795 aren't entirely clear
<ogra> if you'd do the installed one, your fix to that hook would only apply in the next update ...
<ogra> so i guess you can assume it is the about-to-be-installed one
<dot-tobias> ogra: I have your pi-kiosk gadget on my todo/inspiration list for exactly that usecase ð Thank you for your work btw!
<ogra> np :)
<tomwardill> ogra: thanks :)
<Gargoyle> Is there any way to accelerate the launch of snap apps?
<ogra> buy a faster disk ? :)
<zyga> Gargoyle: snaps launch very very quickly - what is slow are parts of the desktop stack, such as fontconfig, that is unique to each snap
<zyga> Gargoyle: work on fontconfig should improve that situation to the point where perhaps a shared cache can be used?
<ogra> specifically at the foirst start of a desktop snap you have a lot of stuff being copied around
<zyga> Gargoyle: to see how fast snaps run install snapd-hacker-toolbelt and time it
<ogra> (and generated etc)
<Gargoyle> ahh so the 15 seconds it takes atom to launch it doing things like updating the fontconfig cache each time?
<zyga> I don't think it is each time
<diddledan> don't you love when builds are long: https://usercontent.irccloud-cdn.com/file/u3SMBRXX/image.png
<mup> PR snapcraft#2382 opened: unit tests: missing full adapter in extension test <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2382>
<zyga> but it should be per ... something
<zyga> (per revision perhaps?)
<zyga> but I really don't know
<zyga> it needs per-snap analysis
<zyga> though I believe the overhead from desktop helpers is commonly known
<Gargoyle> OK. I think something might be screwy on my laptop then. It;s taking 15s every time. But it's also giving me the "first run" screen every time too
<zyga> Gargoyle: perhaps something to debug with kenvandine
 * zyga returns to reviews
 * Chipaca drags himself off to have something to eat before he keels over
<mup> PR snapd#6030 closed: cmd/snap: tweak `snap services` output when there is no services <Simple ð> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6030>
<Chipaca> zyga: notes := []string{"", ""}[:0]
<zyga> haha
<zyga> yeah
<zyga> I don't know if golang does any static arrays but perhaps :)
<Chipaca> zyga: OTOH i don't know why you care :-)
<zyga> we seem to care about some trivial optimisations like that
<zyga> like pre-computing array size
<zyga> I heard that map resizing is slow
<zyga> but nothing tangible I can recall
<Chipaca> zyga: it's a little bit bad if it leaves the function, and can be big
<Chipaca> zyga: and is in something long-lived
<Chipaca> otherwise, eh
<kyrofa> zyga, Chipaca is core edge not on snapd master at the moment?
<kyrofa> Perhaps I should have phrased that the other way around
<kyrofa> And in reality, perhaps that's a question for cachio
<Chipaca> kyrofa: edge is 11 hours old
<Chipaca> and  built from master
<mup> PR snapd#6027 closed: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <Squash-merge> <â  Critical> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6027>
<Chipaca> afaik :-)
<kyrofa> Chipaca, I can't find that commit hash though
<Chipaca> I'd love to know why you even care,  but ok
<kyrofa> Haha, Chipaca because it doesn't seem to contain what I WANT it to contain, so I'm trying to figure out what it DOES contain
<Chipaca> kyrofa: what do you want it to contain?
<kyrofa> Chipaca, https://github.com/snapcore/snapd/pull/6029
<mup> PR #6029: snapstate: add command-chain to supported featureset <Created by kyrofa> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6029>
<Chipaca> kyrofa: hmm
<Chipaca> I wonder if we're mangling the tree before building the snap
<kyrofa> Making some sort of temporary commit?
<Chipaca> kyrofa: https://launchpadlibrarian.net/394484955/buildlog_snap_ubuntu_xenial_amd64_core_BUILDING.txt.gz
<kyrofa> Chipaca, hmm. That doesn't tell me much. Edge doesn't seem to contain the functionality I added there, so I'm trying to figure out if it's broken or just not there. Are you pretty sure it's the former?
<Chipaca> kyrofa: what time was that build started?
<kyrofa> Chipaca, ah, looks like yesterday in my early morning
<Chipaca> kyrofa: i thought it was today
<Chipaca> but dunno where you are in the world
<kyrofa> Chipaca, Mon Sep 24 13:14:43 UTC
<Chipaca> .... wat
<Chipaca> that's a month ago
<kyrofa> Oh
<kyrofa> Uh
<Chipaca> where are you looking?
<kyrofa> Whoops, ignore me
<Chipaca> way ahead of you
<Chipaca> :-Ã¾
<kyrofa> Chipaca, you're right, looks like it was today
<Chipaca> 4am utc is pretty much exactly 12 hours ago
 * zyga grabs dinner 
<Chipaca> kyrofa: so now the question is did the git tree in launchpad get the commit you wanted in time
<Chipaca> it's cutting it close :-)
<kyrofa> Yeah it is. It doesn't look like it, but there's no way to be sure unless snapd happens to shove a changelog in there
<kyrofa> It does!
<kyrofa> Not sure how this works though. If this is to be believed it's just 2.36~pre2
<Chipaca> kyrofa: i think the changelog has a manual step
 * Chipaca grabs cachio before he runs off again
<Chipaca> cachio: hi
<Chipaca> cachio: how can kyrofa figure out what commits of snapd are on core edge?
<zyga> re
<zyga> back to reviews
<cachio> Chipaca, kyrofa there is a launchpad repo
<cachio> on sed
<cachio> sec
<cachio> kyrofa, this is the repo https://launchpad.net/snapd-vendor
<cachio> it takes a time to create the snap
<cachio> kyrofa, what do you need to do with it?
<kyrofa> cachio, I was hoping folks could utilize a PR that landed yesterday
<kyrofa> Chipaca, ah, the commit hash comes from that ^
<kyrofa> cachio, so what, you just dump snapd master into that every few days?
<cachio> kyrofa, we dump it always when master is in green
<cachio> so, we run tests on master branch after each merge
<cachio> if the tests pass, then we run a script to dump the master to this lp repo
<cachio> then, based on that, we build the core snap on edge
<cachio> it takes some time
<kyrofa> Okay so based on this, the edge snap is based on snapd master as of Friday?
<kyrofa> Am I deducing this all correctly?
<Chipaca> kyrofa: BTW, you know assumes: is a last-ditch kind of thing, currently? it's not user friendly at all
<cachio> kyrofa, let me check when was the last one
<Chipaca> kyrofa: it's fine for exploratory work or for super-early-adopters kind of thing, but not for end users
<Chipaca> kyrofa: it'll download the snap before even knowing about assumes
<Chipaca> and throw a hissy fit at you
<kyrofa> Chipaca, yeah. It's either that or magically not work
<cachio> kyrofa, edge snap is based on snapd master
<cachio> it si right
<cachio> based on last master which has passed the tests
<cachio> kyrofa, last one is from today
<kyrofa> cachio, I'm confused. The edge snap has this version: "16-2.36~pre2+git967.54466bd"
<mup> PR snapcraft#2383 opened: ci: use more travis primitives for osx tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2383>
<kyrofa> cachio, that commit hash points to a commit you made on Friday: https://git.launchpad.net/snapd-vendor/commit/?id=54466bdcf1432fb7c2869a3abbf92751186aaa42
<kyrofa> Although when I click on it it changes to Saturday... but I'll ignore that :P
<kyrofa> Timezones I guess
<kyrofa> And if I look at the file I'm interested in, it's definitely not from today-ish since it doesn't contain the commit that landed yesterday: https://git.launchpad.net/snapd-vendor/tree/overlord/snapstate/check_snap.go?id=54466bdcf1432fb7c2869a3abbf92751186aaa42
<koala_man> mborzecki, Chipaca: I'm glad you're finding shellcheck useful! unfortunately the shellcheck snap build has been broken for a while due to https://bugs.launchpad.net/snapcraft/+bug/1797809 . Any suggestions?
<mup> Bug #1797809: Build fails on snapcraft.io, works locally (during `cabal update`) <Snapcraft:New> <https://launchpad.net/bugs/1797809>
<Chipaca> koala_man: I didn't know, no! and yes, we're using it all over the place including in static checks of snapd itself
<Chipaca> koala_man: I've got to run now, but I'll take a look later
<koala_man> I'd appreciate it ^^
<Chipaca> kyrofa: sergiusens: if you have a bit of time, ^^^
<kyrofa> koala_man, one of the better tools I've used
<kyrofa> We're using it in snapcraft as well
<kyrofa> koala_man, do you know if cabal obeys http_proxy?
<koala_man> kyrofa: yes, it does
<koala_man> If I run http_proxy='http://localhost:12345' cabal update  it fails with "cabal: Couldn't establish HTTP connection. Possible cause: HTTP proxy server is down."
<kyrofa> cjwatson, are you around? Curious to get your thoughts on https://bugs.launchpad.net/snapcraft/+bug/1797809
<mup> Bug #1797809: Build fails on snapcraft.io, works locally (during `cabal update`) <Snapcraft:New> <https://launchpad.net/bugs/1797809>
 * zyga goes for last streak today
<cachio> kyrofa, the commit summary has the commit in githb
<cachio> kyrofa, the last commit on lp has a commit message which points to c712d09ac22ee65c48b520f462f8ddbaf1ee5efa commit on github
<cachio> this it the traceability
<kyrofa> cachio, right, but that one's not in edge
<kyrofa> How often is it built?
<mup> PR snapcraft#2384 opened: project: do not install base is already installed <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2384>
<cachio> kyrofa, once a day aprox
<cachio> during the night
<cachio> kyrofa, 4 am was built the last one
<kyrofa> cachio, then why is the version referring to 54466bd?
<cachio> we have a sync job which takes the changes in snapd master and push it to launchpad
<cachio> the 54466bd... is the commit on launchpad which has the same content than whe commit id added in the summary
<cachio> Content updated (b5e852ba093baad2624a8ecc32e9715c72631752)
<cachio> so yoy know the commit in lp 	54466bdcf1432fb7c2869a3abbf92751186aaa42 is the same then the commit in github b5e852ba093baad2624a8ecc32e9715c72631752
<cachio> then every night another job is executed which creates and publishes the core on edge
<cachio> it takes the last change in the lp repo and use that to create the core snap
<cachio> it is a bit complicated :)
<kyrofa> Ah, I'm just looking at the commit timestamps and thinking "13 hours ago was yesterday!" but I suppose not everywhere
<kyrofa> Okay so the one that builds tomorrow will be what I want
<kyrofa> Thanks cachio, that traceability is handy
<cjwatson> kyrofa: should be reassigned over to launchpad-buildd - I guess either cabal ignores the proxy or they manage to confuse each other somehow
<kyrofa> cjwatson, will do, thanks :)
<cachio> kyrofa, yes, I think tomorrow will be includede
<cjwatson> kyrofa: I think I saw another question about the same thing recently but it doesn't seem to have ended up as a launchpad-buildd bug, so ...
<cachio> otherwise ping me
<kyrofa> koala_man, cjwatson knows everything about build.snapcraft.io, he'll help get that working
<koala_man> awesome! I'm happy to help in any way I can
<koala_man> cjwatson: is there any way I can run the build locally with the same proxy?
<cjwatson> koala_man: It's possible but complicated.  Requires setting up a xenial VM, installing launchpad-buildd in it from ppa:launchpad/ubuntu/ppa, and then sending some err not-very-well-documented XML-RPC commands to it to get it to do something ...
<cjwatson> Oh and of course you need a proxy for it to talk to
<cjwatson> I suspect the problem here is the localhost-only proxy that launchpad-buildd runs to avoid builds needing to be able to cope with authenticated proxies
<koala_man> cabal apparently has a --http-transport=curl flag that can be switched to wget or plain-http. is there a nice way to test this that doesn't involve me pushing upstream test commits?
<koala_man> by the way, this used to work, and I can probably find the date it started breaking if that's helpful
<cjwatson> Testing it locally can be done by just dispatching a snap build, but I won't be able to get to it until later this week
<cjwatson> It's quite likely that it started breaking in mid-June when we deployed the fix for bug 1690834 / bug 1753340
<mup> Bug #1690834: snap builds in cleanbuild but fails on buildd <launchpad-buildd:Fix Released by cjwatson> <https://launchpad.net/bugs/1690834>
<mup> Bug #1753340: build failing on download by ant build  <ant> <python> <snapcraft> <launchpad-buildd:Fix Released by cjwatson> <https://launchpad.net/bugs/1753340>
<koala_man> I just looked it up and you're right
<cjwatson> launchpad-buildd 162
<cjwatson> I'd rather we not work around it in shellcheck TBH since you're probably not the only affected project
<cjwatson> I'm slightly surprised I've only heard about this in relation to cabal
<cjwatson> But there may be some subtle property of the HTTP connection that's confusing it
<koala_man> of course, but it would be nice way to narrow down the problem
<cjwatson> It would be possible to push test commits to a branch and create a test snap on LP that builds it
<cjwatson> build.snapcraft.io can't do that, but it can be done directly using the API
<cjwatson> https://launchpad.net/+apidoc/devel.html#snaps-new
<cjwatson> Though TBH I suspect actually fixing the bug is going to require more direct debugging methods anyway - strace/tcpdump, that sort of thing
<cjwatson> or a load of debugging prints sprinkled through the localhost-only proxy
<mup> PR snapcraft#2383 closed: ci: use more travis primitives for osx tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2383>
<zyga> jdstrand: hey, I know you are sprinting but if you have a moment please consider looking at https://github.com/snapcore/snapd/pull/5727
<mup> PR #5727: interfaces/browser-support, cmd/snap-seccomp: Allow read-only ptrace, for the Breakpad crash reporter <Created by jld> <https://github.com/snapcore/snapd/pull/5727>
<mup> PR snapd#6000 closed: snap,client: use a different exit code for retryable errors <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6000>
 * cachio afk
<koala_man> cjwatson: I would be willing to look into that if I had a simple way to reproduce it
<mup> PR snapcraft#2382 closed: unit tests: missing full adapter in extension test <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2382>
<AuroraAvenue> Hi N00b question. Is it possible to Snap the google Api ?
<AuroraAvenue> https://developers.google.com/+/web/api/rest/
<ijohnson> AuroraAvenue: if all you want to do is call the API via HTTP calls then yes you could have a snap which interfaces with the Google+ REST API
<AuroraAvenue> cheers - I shall add it to the list.
<mup> PR snapd#5727 closed: interfaces/browser-support, cmd/snap-seccomp: Allow read-only ptrace, for the Breakpad crash reporter <Created by jld> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5727>
<mup> PR snapd#6023 closed: overlord/snapstate, snap, wrappers: start services in the right order during install <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6023>
<mup> PR snapd#6032 opened: overlord/snapstate, snap, wrappers: start services in the right order during install <Created by mvo5> <https://github.com/snapcore/snapd/pull/6032>
#snappy 2018-10-24
<mup> PR snapd#6033 opened: tests: update parallel-install-store test <Created by mvo5> <https://github.com/snapcore/snapd/pull/6033>
<mup> PR snapd#6034 opened: many: save media info when installing, show it when listing <Created by chipaca> <https://github.com/snapcore/snapd/pull/6034>
<mborzecki> morning
<mup> PR snapd#6035 opened: tests/main/parallel-install-store: the store has caught up, do not expect failures <Parallel installs â> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6035>
<mborzecki> super simple ^^
<mborzecki> and it unblock spread runs on master
<zyga> Re
<zyga> mborzecki: we might need a backport
<mborzecki> zyga: don't know if we can push a single cherry-pick, i'm opening a PR to 2.36
<mup> PR snapd#6036 opened: tests/main/parallel-install-store: the store has caught up (2.36) <Parallel installs â> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6036>
<dot-tobias> *waves good morning*
<zyga> hey dot-tobias
<pstolowski> mornings
<zyga> o/
<mup> PR snapd#6035 closed: tests/main/parallel-install-store: the store has caught up, do not expect failures <Parallel installs â> <Simple ð> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6035>
<mborzecki> pstolowski: hey
<mup> PR snapd#6033 closed: tests: update parallel-install-store test <Created by mvo5> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6033>
<zyga> can I get formal reviews on 5987 please
<zyga> as well as on 6010 if you can
<mborzecki> hm down to 34 PRs, nice
<zyga> could be 32 if someone merges my PRs ;-)
<zyga> (*shameless*)
<mborzecki> thought i left +1 on 5987 already
<pstolowski> zyga: looking
<zyga> thank you for reviews in any case :)
<pstolowski> zyga: not sure about snap-confine-debug change in makefile.am (i'm not clear about background of this); it looks like noinst_PROGRAMS += snap-confine/snap-confine-debug is left intact there, intended?
<zyga> yes, that's so that 'make all' builds it
<pstolowski> ok
<zyga> make hack just now installs that debug copy with extra stuff for local work
<zyga> we still have the non-debug version as before
<pstolowski> +1
 * pstolowski runs an errand
<zyga> more rain today
<mup> PR snapd#5987 closed: cmd: refactor IPC and lifecycle of the helper process <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5987>
<mborzecki> multipass is a classic snap?
<zyga> I think it needs kvm
<zyga> So ... likely?
<mborzecki> aand power outage :/
<zyga> Uh, does that happen often?
<mborzecki> zyga: quite often during thunderstorms and super windy weather, i was actually surprised that it happened only now given that's been very windy for 3 days now
<mborzecki> electricity company will happily take your money but they're not equally keen to replce airlines with underground power cables or fix their distribution transformers
<ackk> mborzecki, yes it's --classic
<mborzecki> multipassd not starting https://paste.ubuntu.com/p/3Zd3zcTrgK/
<mborzecki> ackk: should i use beta rather than edge?
<ackk> mborzecki, I've been using edge and it used to work (at least, it did yesterday)
<ogra> zyga, qemu-virgil is using kvm too and doesnt need to be classic ... i think that not caused by kvm
<ogra> *that's
<mborzecki> ackk: just for the record, is should work on non-ubuntu systems too, right?
<ackk> mborzecki, AFAIK classic only works on ubuntu
<ackk> ogra, ^ ?
<mborzecki> ackk: i mean multipass (whcih is a classic snap)
<Chipaca> zyga: morning
<ackk> mborzecki, right, I mean I don't think it will because classic snaps only work on ubuntu (AFAIK)
<ogra> ackk, afaik you only need to create the /var/lib/snapd/snap to /snap link to make them work on non-ubuntu
<ackk> ogra, but don't classic snaps assume the ubuntu distro layout underneath?
<ackk> I mean, they probably work on some non-ubuntu distros but ISTR they don't on some
<ogra> depends how they are built :)
<ackk> mborzecki, which distro are you using?
<ogra> this is totally up to the creator ... you can point all library paths to inside the snap
<mborzecki> ackk: afaiu they should not, oherwise it defats the purpose of having them as snaps
<ogra> then a classic snap isnt different to i.e. an upstream binary tarball you extract to /opt
<Chipaca> (morning all)
<ackk> ogra, sure, I mean they might rely on certain binaries to be available on the system. for instance I had a snap published as classic because the app calls "sudo" and that doesn't work in non-classic
<ogra> well, you could also just fix the app to not do that ;) or design your snap differently (a daemon process managing the elevated bits that a frontend wrapper talks to)
<ogra> that would even allow you strict confinement ;)
<ackk> ogra, yeah I'm talking about snapping existing apps
<ogra> right, internal sudo calls are a special case where classic is valid
<ackk> ogra, I wonder if there would be a way for core to provide a fake sudo that just forwards the command, so if your app has the right slots it can still do stuff, without using classic
<ogra> there could perhaps be an interface, yes ... but i bet thats pretty non-trivial to get right in a safe manner, you need to access the passwd db, suoders etc
<Chipaca> where were the environment variables that snapcraft exposes during a build documented?
<Chipaca> I remember somebody asking about this and having to go to github to find it
<Chipaca> (a docs github)
<Chipaca> degville: you maybe? ^
<zyga> o/
<zyga> Took small break for making breakfast for my daughter
<ackk> Chipaca, btw, it seems many links in the table on https://docs.snapcraft.io/snapcraft-yaml-reference are broken (they don't do anything)
<Chipaca> ackk: yep, reported that one
<ackk> cool, thanks
<Chipaca> I mean, somebody did
<Chipaca> not me
<degville> Chipaca: is this the one: https://github.com/canonical-docs/snappy-docs/blob/master/reference/env.md
<Chipaca> degville: similar but the SNAPCRAFT_ ones
<degville> ah, ok. I'll look.
<degville> Chipaca: https://forum.snapcraft.io/t/environment-variables-that-snapcraft-exposes/7569 ?
<chesty> hi, on my laptop my default route goes over a vpn and I have a net namespace if I want an application to not use the vpn, ie `sudo ip netns exec novpn gosu me firefox ` or whatever. this doesn't work for snap, how do I make a snap use an alternate routing table?
<zyga> chesty: when you say it doesn't work, what are the symptoms?
<chesty> sudo ip netns exec novpn sudo -u michaelc skypeexecv failed: Permission denied
<zyga> do you see any apparmor denials? dmesg | grep DENIED
<chesty> yes, [336140.107862] audit: type=1400 audit(1540372346.301:4293): apparmor="DENIED" operation="exec" profile="/snap/core/5789/usr/lib/snapd/snap-confine" name="/snap/core/5789/usr/lib/snapd/snap-exec" pid=27632 comm="snap-confine" requested_mask="x" denied_mask="x" fsuid=1098200003 ouid=0
<chesty> oh, I might need the classic flag?
<chesty> nope, the classic flag didn't help, I did need it to install skype
<zyga> no, this is against snap-confine, not a particular snap
<zyga> hmmm
<zyga> this is unexpected
<zyga> can you please pastebin /etc/apparmor.d/snap.core.5789.usr.lib.snapd.snap-confine
<chesty> the only snap related file in /etc/apparmor.d is /etc/apparmor.d/usr.lib.snapd.snap-confine.real
<zyga> chesty: what does snap version say?
<chesty> 2.36~pre2+git971.73ec9b5~ubuntu16.04.1
<zyga> can you please go to /var/lib/snapd/apparmor/ and look for snap-confine.core.NNN
<chesty> I believe I install an edge a few weeks ago to fix a bug
<zyga> and pastebin the profile for the revision 5789 please
<ackk> ogra, I meant, sudo could just let the app make the call and let normal confinement enforce permissions, can't it?
<ogra> no, if you exec inside the snap environment also sudo is confined and wont see the host system unless there is an interface
<ackk> ogra, yeah but I meant replace sudo with a fake sudo
<ackk> ogra, so that "sudo foo" would just run "foo"
<ogra> well, you still want to elevate your privs somehow
<ogra> or the app wants rather
<chesty> https://pastebin.com/VJRpkgd6
<mborzecki> yay, building a snap via snapcraft in a vm launched by multipass, all on arch
<mborzecki> docs.snapcraft.io doesn't really mention snapcraft + multipass
<pstolowski> nice!
<mborzecki> and it built successfuly!
<pstolowski> even nicer!
<Chipaca> degville: that was it, thanks!
<degville> np. We should make it easier to find.
<Chipaca> yar
<dot-tobias> should I be able to scp something to an ubuntu-core-vm (qemu), or is this not possible? SCP works fine with ârealâ Core installations, but somehow neither SSH key nor the manually set password for my account on the core vm is accepted. Auth.log in the vm just shows connection attempts. Am I completely off here, or missing something?
<Chipaca> dot-tobias: how do you run the vm?
<zyga> it works but perhaps the way you run the VM is tricky and your network is not properly set up\
<Chipaca> dot-tobias: I use: kvm -m 4G -redir :8022::22 -snapshot -serial stdio ~/Downloads/core18-amd64-18-beta20180823.img
<Chipaca> dot-tobias: I have a "kvm.sanppy" entry in my ~/.ssh/config
<Chipaca> dot-tobias: and i just "ssh kvm.snappy" and it works
<Chipaca> dot-tobias: (that particular invocation is an example only, happened to be the first  one in my history :) )
<dot-tobias> Chipaca: Using the ubuntu-core-vm as described here: https://developer.ubuntu.com/core/examples/snaps-on-mir
<Chipaca> dot-tobias: ah, never tried that, let me give it a whirl
<dot-tobias> (my previous message was missing a âsnapâ after âubuntu-core-vm ð )
<dot-tobias> Chipaca: Thanks
<Chipaca> I need to complain at gerboland (assuming these docs are from them) about using --devmode like this :-(
<ogra> dot-tobias, alternatively you can use qemu-virgil ... (launch instructions are in snap info) ...
<popey> ogra: why does core not have curl or wget?
<ogra> popey, dunno ... just snap install mget ?
<popey> ugh
<ackk> Chipaca, that's also how maas uses it I guess :)
<popey> I dont wanna install stuff on a clean system
<popey> just wanna use curl to find out the public IP
<tomwardill> I've bounced off that before too
<mup> PR snapd#6037 opened: tests/unit/gccgo: drop gccgo unit tests (2.36) <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6037>
<ogra> well, i dont remember anymore why we didnt ship wget ... security reasons most likely
<mborzecki> super simple ^^
<popey> hah, we ship netcat
<Chipaca> popey: python3 -c 'from requests import get;print(get("https://api.ipify.org").text)'
<popey> that'll do, thanks :)
<zyga> mborzecki: is there a way to install python3 on amazon linux?
<Chipaca> dot-tobias: so, using ubuntu-core-vm, you get the initial configure screen, yes?
<mborzecki> zyga: maybe epel
<Chipaca> zyga: snap install pypy
<mborzecki> zyga: although iirc epel-7 should be already added to the repos
<Chipaca> zyga: i mean pypy3
<zyga> Chipaca: it would need to be classic
<Chipaca> zyga: pypy3 is classic
<zyga> I may find a way out of this
<mborzecki> zyga: same problem will be on centos
<dot-tobias> Chipaca: qemu just shows a black screen, but knowing the setup by heart i just pressed enter until it was configured ð Installing mir-kiosk works.
<Chipaca> grr
<Chipaca> dot-tobias: do you have an nvidia card?
<dot-tobias> Chipaca: Yes
<Chipaca> grrÂ³
<mborzecki> nvidia..
<Chipaca> i have an nvidia card too, today
<Chipaca> and also get a black screen
<zyga> today"
<zyga> heisencard
<zyga> sometimes nvidia
<zyga> sometimes amd
<zyga> ;-)
<zyga> I need to bring the heater in here, I' m freezing
<mborzecki> nvidia on even days, today's 24th :)
<Chipaca> I edited the script to change sdl,gl=on to sdl,gl=off, and now it works (but is slow, because sdl seems slow)
<dot-tobias> Gotta head off for a while, colleagues complaining that we're missing lunch ð â re later
<Chipaca> mborzecki: zyga: it's a 'prime' laptop, so today it's in have-nvidia-i'm-plugged-in mode
<mborzecki> Chipaca: heh, i understand what you're going through :)
<Chipaca> mborzecki: it's not a mid-life crisis until _I_ say it is!
<chesty> hey zyga, did you see my pastebin above by chance?
<Chipaca> mborzecki: wait what were we talking about
<ogra> Chipaca, qemu-virgil ... justsayin ;)
<ogra> (tested regular with nvidia)
<Chipaca> ogra: i was trying to help dot-tobias, which took me to https://developer.ubuntu.com/core/examples/snaps-on-mir which tells people to do things in a way I tell people telling people to do things not to do
<ogra> heh
<zyga> chesty: yes, I saw it, I was investigating and then got interrupted, sorry
 * Chipaca hopes ogra's parser can un-nest that, but has hopes because German
<ogra> totally !
<chesty> zyga, no no, i appreciate your help. I just didn't ping you so thought you might not have seen it
<zyga> chesty: so... there are no permissions to run snap-exec directly in that profile but that's exactly as the profile was all the time
<zyga> chesty: I don't understand why that detail happens yet
<zyga> can you report a bug about it so that it doesn't get lost please
<Chipaca> ogra: dunno about this virgil thing, I don't want to end up with qemu tied to a boat with wax up its â¦ ears
<Chipaca> ogra: also that developer is super sketchy
<ogra> yeah, only does hacks all the time
<ogra> (i heard)
<chesty> zyga, absolutely, is that on github?
<zyga> chesty: on launchpad.net/snapd please
<Chipaca> chesty: https://bugs.launchpad.net/snapd/+filebug
<Chipaca> zyga: ^ :-)
<zyga> thanks Chipaca :)
<Chipaca> zyga: https://bugs.launchpad.net/snapd/+filebug?field.title=all+ur+base
<ogra> we used to have that in the channel topic :)
<zyga> rbelongtostore
<Chipaca> xceptfedorabase
<zyga> no no, it's in the store too
<zyga> mkosi will soon support building base snaps
<Chipaca> datbelongtosongoku
<chesty> zyga https://bugs.launchpad.net/snapd/+bug/1799677
<zyga> thank you chesty
<mup> Bug #1799677: apparmor issue when running snap with ip netns exec <snapd:New> <https://launchpad.net/bugs/1799677>
<zyga> chesty: I'll return to the bug after some feature work I need to finish soon
<mborzecki> heh, travis jobs on release/2.36 branch are not so much fun
<chesty> zyga and thank you for you help. there's no rush. cheers
<mborzecki> iirc someone was complaining about https://bugs.launchpad.net/snapd/+bug/1799677 in the comments under one of the reddit topics about flatpak
<mup> Bug #1799677: apparmor issue when running snap with ip netns exec <snapd:Triaged by zyga> <https://launchpad.net/bugs/1799677>
<mup> PR snapd#6037 closed: tests/unit/gccgo: drop gccgo unit tests (2.36) <Simple ð> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/6037>
<mborzecki> any ideas about https://github.com/snapcore/snapd/pull/6025 ?
<mup> PR #6025: Add go.mod files <Created by ryanjyoder> <https://github.com/snapcore/snapd/pull/6025>
<Chipaca> ogra: qemu-virgil has the same gl issues
<Chipaca> ogra: mind you i might need to restart to get gl working (or it might be broken) (quantum gl)
<zyga> mborzecki: can you have a look at https://github.com/snapcore/snapd/pull/6010 again please
<mup> PR #6010: cmd/snap-discard-ns: add support for per-user mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/6010>
<zyga> mborzecki: there are two topics in that go.mod pr: just the go.mod feature (which I'm not familiar with) and the bigger topic of what is our public API
 * pstolowski lunch
<Chipaca> mborzecki: zyga: https://github.com/snapcore/snapd/pull/6025#issuecomment-432616398
<mup> PR #6025: Add go.mod files <Created by ryanjyoder> <https://github.com/snapcore/snapd/pull/6025>
<mborzecki> Chipaca: thanks for leaving a note there
<Chipaca> i don't want op to think we're ignoring them :)
<mborzecki> Chipaca: otoh, the code is on github, nothing stopping them from using it as a public lib no matter what we say
<Chipaca> mborzecki: oh, i don't mind that :-)
<mborzecki> as long as we don't promise anything :)
<Chipaca> mborzecki: it's the complaining when we break it, or more precisely the having to run around like a headless chicken three hours after eod because we released something that broke them and it's suddenly our problem somehow
<mborzecki> zyga: left a comment, i think you missed some python[23] in mount.sh
<zyga> ohh
<zyga> drat
<zyga> I tested manually
<zyga> thanks!
<zyga> pushed
<mborzecki> 2018-10-24 10:54:23 Cannot allocate google:ubuntu-18.10-64: cannot find any Google image matching "ubuntu-os-cloud-devel/daily-ubuntu-1810-cosmic-v20181002" on project "ubuntu-os-cloud-devel"
<mborzecki> eh, need one more patch for 2.36
<dot-tobias> Chipaca: (re Ubuntu Core in KVM) FWIW, using the latest 18 Core image from today and your kvm invocation, console-conf shows just fine on the same nvidia card as before. I suspect the ubuntu-core-vm snap --beta does not have the latest ð
<Chipaca> dot-tobias: does any gl snap work for you right now?
<dot-tobias> Chipaca: Sec, testing mir-kiosk â¦
<Chipaca> dot-tobias: is mir-kiosk a gl-using snap?
<ogra> yes
<ogra> ist a hard requirement
<ogra> *it's
<dot-tobias> Chipaca: That question is beyond my knowledge, but I assume it does â¦ (but ogra confirms)
<dot-tobias> As for the test, mir-kiosk does not work. journalctl entry: Exception while creating graphics platform // st::exceptioin::what: Failed to find platform for current system
<Chipaca> yep, and i confirmed by downloading the snap and looking :-)
<Chipaca> dot-tobias: ohmygiraffe is the canonical opengl test, i hear
<Chipaca> â¦ and that one works, here
<Chipaca> ogra: so boo, your snap is broken :-D
 * Chipaca really has no idea about this side of the stack
<Chipaca> also i suck at ohmygiraffe
<Chipaca> i'm lion fodder
<ogra> Chipaca, which snap ?
<Chipaca> ogra: qemu-illiad
<Chipaca> or was it qemu-virgil
<ogra> works fine here
<ogra> on nvidia and intel
<ogra> (as long as you follow the steps in snap info)
<ogra> and it was -virgil :)
<Chipaca> actually, now it's started working
<Chipaca> WAT
<Chipaca> ah no, -vga std
<Chipaca> heh
<ogra> yeah, you dont want std
<Chipaca> oh it works with virtglwotsit as well
<Chipaca> ohmygiraffe fixed my gl, or â¦ dunno
<Chipaca> maybe i just needd lunch
<Chipaca> needed*
<Chipaca> Â¯\_(ã)_/Â¯
<ogra> to just test if GL works and if it starts you can simply start it without any options
<ogra> should get you the accelerated gtk UI ... with a menu bar at the top
<Chipaca> too late, now i'm running budgie on it
<ogra> heh
 * dot-tobias *tries to follow this conversation and installs qemu-virgil snap*
<ogra> dot-tobias, afterwards do a "snap info qemu-virgil"
<ogra> it has the quickstart instructions
<Chipaca> ogra: you should look into getting that autoconnected
<dot-tobias> ogra: Done that, getting permission denied with âcould not access KVM kernel moduleâ. Did connect the interface with sudo (if that makes any difference)
<Chipaca> dot-tobias: are you in the kvm group?
<ogra> Chipaca, yeah never got to doing the paperwork for autoconnect yet
<ogra> dot-tobias, if you arent in the kvm group but know the kvm module is loaded you can also just use qemu-virgil with sudo
<dot-tobias> Chipaca: No I was not (did I mention that my knowledge of all this is virtually non-existent?), but after adding it with usermod it still does not work.
<Chipaca> dot-tobias: for the usermod to take you need to re-login (or use sg)
<Chipaca> a blood sacrifice is also needed
<Chipaca> but it doesn't need to be yours
<ogra> well ... or sudo
<dot-tobias> Chipaca: Learning new things every day â¦ thought usermod is instant, that did the trick. Thanks!
<dot-tobias> using sudo for qemu-virgil gave me a perm denied on the image file in my user's home directory Â¯\_(ã)_/Â¯
<Chipaca> yep :-)
<ogra> lol
<ogra> ok
<Chipaca> ogra: you should be able to detect some of this and warn
<Chipaca> ogra: otherwise maybe including it in descr
<dot-tobias> qemu-virgil starting now, but the qemu window states "no bootable device" when using the exact command from qemu-virgil snap info
<ogra> can you paste the line here ?
<ogra> (the one you used in your terminal)
<ogra> note there is a line wrap in the info output
<ogra> Chipaca, good point
<Chipaca> dot-tobias: 'exact command' including the 'some.img' at the end?
<dot-tobias> ogra: nevermind, I had renamed the image file in the meantime â¦ :facepalm:
<Chipaca> heheh
<Chipaca> :-)
<ogra> heh
<dot-tobias> Chipaca: nope, I was smart enough to supplement some.img with the actual name, but forgot that I changed it between the first and last attempt to start qemu-virgil (because I downloaded another daily build)
<ogra> wow, this is gross ...
<mup> PR snapd#5954 closed: [wayland] explicitly permit file locking for wayland lock <Created by gerboland> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5954>
<ogra> i'm creating a hardcoded link in $SNAPCRAFT_PART_INSTALL to point to /var/snap/<snapname>/current/foo in ony of my snaps ...
<ogra> if i have that snap installed, snapcraft actually reads the content from that dir on disk instead of respecint that it is a symlink inside my build
<ogra> s/ony/one
<ogra> so it doesnt just put the link into the snap but copies the dir from /var
<ogra> removing the snap before building gets me a properly dangling symlink
<ogra> (as intended)
<Chipaca> ogra: sounds buggeh
<dot-tobias> ogra, Chipaca: Welp, scp'ing to the qemu-virgil-hosted Core image (20181023) does not work either (which was the initial problem with just running ubuntu-core-vm from its snap) ð and the manual kvm invocation by Chipaca seems to have issues with gl apps, which prevents me from actually testing my kiosk app ð
 * dot-tobias stuck between a rock and a hard place
<ogra> how do you scp ?
<Chipaca> dot-tobias: which was the image you were getting?
<Chipaca> dot-tobias: link plz, so i can try to repro
<dot-tobias> http://cdimage.ubuntu.com/ubuntu-core/18/20181023/ubuntu-core-18-amd64.img.xz
<dot-tobias> Chipaca ^
<Chipaca> getting
<Chipaca> ah, the core-18 snap, ok
<Chipaca> getting
<ogra> scp -P 10022 file-to-copy user@localhost:~/
<ogra> thats how you should do it
<dot-tobias> ogra: Yes, the connection itself is fine, and I can SSH in without problems â but using scp it does not accept my SSH key, then asks for the password instead. I even tried to set the password inside the vm with passwd <user> but giving the super-slowly-typed password to scp still aborts after 3 tries.
<Chipaca> or âscp file-to-copy kvm.snappy:â if you have the right .ssh/config entry =)
<Chipaca> core got, booting
<zyga> error: failed to commit transaction (conflicting files)
<dot-tobias> ogra, Chipaca: scp -p 10022 my.snap $SSO_USER@localhost:~/ â prompts for $SSO_USER's password, debugging with -vvv shows that my SSH key just gets ignored. Forcing it with -i ~/.ssh/my_key has no effect
<Chipaca> dot-tobias: -p, or -P?
<dot-tobias> Chipaca: -p
<ogra> large p please
<ogra> small p preserves modification times of the file you copy
<Chipaca> you're trying to ssh into yourself =)
<ogra> large P means port
<dot-tobias> I'm gonna go sit in the dumb corner for a while now â¦ Assumed that -p would be the same as for ssh.
<ogra> yeah, it is super confusing and annoying that they differ
<Chipaca> dot-tobias: https://pastebin.ubuntu.com/p/SfwM3ngYx7/
<Chipaca> dot-tobias: adjust as necessary, and append to ~/.ssh/config, and then forget all the sillyness of -p/-P etc
<dot-tobias> Chipaca: Thanks ð
<Chipaca> I suspect I could prune the "phablet" entry from my .ssh/config
<Chipaca> also bazaar.ubunet
<dot-tobias> Well, I guess I should not try again with the ubuntu-core-vm route because I might very well discover that I wasted > 15min on this when I could have just re-read the scp manpages. Huge thank you to ogra and Chipaca
<mborzecki> Chipaca: can I get a second +1 on https://github.com/snapcore/snapd/pull/6036 ?
<mup> PR #6036: tests: the store has caught up, drop gccgo test, update cosmic image (2.36) <Parallel installs â> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6036>
<ogra> Chipaca, btw, i dont get why ubuntu-core-vm actually needs devmode at all ... it is essentially similar to qemu-virgl (just uses an older qemu and has a lot of wrapper scripts around the qemu call)
<Chipaca> ogra: I'm in communication with the author about this
<Chipaca> mborzecki: you can try
 * mborzecki tries
<Chipaca> mborzecki: go go go
<mborzecki> Chipaca: thx
<mup> PR snapd#6036 closed: tests: the store has caught up, drop gccgo test, update cosmic image (2.36) <Parallel installs â> <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6036>
<zyga> I need a 2nd review on https://github.com/snapcore/snapd/pull/6010 to move forward
<mup> PR #6010: cmd/snap-discard-ns: add support for per-user mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/6010>
<pstolowski> cachio__: for a 2nd serial port with nested vm test it's important that it also has a different serial number, i hope qemu does that
<zyga> Chipaca: reviewed https://github.com/snapcore/snapd/pull/5955/reviews
<mup> PR #5955: cmd/snap, tests: snapshots for all <Snapshots ð¸ó > <Created by chipaca> <https://github.com/snapcore/snapd/pull/5955>
<zyga> I would love a review of https://github.com/snapcore/snapd/pull/6010 in return
<mup> PR #6010: cmd/snap-discard-ns: add support for per-user mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/6010>
<zyga> k, I need to go to the vet again
<Chipaca> zyga: thank you for the review!
<Chipaca> i'll get on those suggestions in a bit
<mborzecki> Chipaca: don't remember, if you do `snap restore` without --users then data for all users is restore or none?
<Chipaca> mborzecki: all
<Chipaca> that's one of the rough edges imo
<mborzecki> Chipaca: and if i want no users?
<Chipaca> mborzecki: er... shoot 'em?
<mborzecki> Chipaca: that's what i meant in https://github.com/snapcore/snapd/pull/5955/files#r224709843 i think it'd be nice to add something to long help of restore (and maybe save too)
<Chipaca> mborzecki: there's also no way to toggle restoring config
<mup> PR #5955: cmd/snap, tests: snapshots for all <Snapshots ð¸ó > <Created by chipaca> <https://github.com/snapcore/snapd/pull/5955>
<Chipaca> mborzecki: I'd rather not document it, and instead find a way of doing it :-)
<mborzecki> Chipaca: soemthing like 'When no users are provided, restoring a snapshot restores data for all users (whose data is in snapshot?)'
<Chipaca> we could have --no-system, --no-users, and --no-config
<Chipaca> --no-nothing
<mborzecki> hm many switches
<mborzecki> --users '' ?
<wgrant> mborzecki: Morning. Not sure if you saw on the forum, but we have parallel installs available on the prod store now.
<mborzecki> wgrant: yup, saw that, thanks for the notice, from the little testing I did it seems to be working fine
<wgrant> mborzecki: Excellent. Do let me know if you see anything odd.
<mborzecki> wgrant: ok
<mborzecki> Chipaca: silly thought, does `snap saved` show whose user data is in the snapshot?
<Chipaca> mborzecki: I'll update the help with that fwiw
<Chipaca> mborzecki: it does not. I'd wondered about including that (maybe in a --verbose or --long).
<Chipaca> but didn't acquire consensus, and it's been hard enough getting reviews for the bits that _did_ have consensus...
<mborzecki> Chipaca: i think we have --verbose elsewhere too (snap info?), but that's soemthing for a follow up presumably
<Chipaca> mborzecki: all of these flaggy things are :-)
<Chipaca> mborzecki: there's --verbose but for something that's already vertical; showing users would force a switch to vertical here
<Chipaca> so maybe --long is better
<Chipaca> dunno
<mborzecki> another PR anyway :)
<mborzecki> we want this one to land after all
<zyga> re
<mup> PR snapd#6032 closed: overlord/snapstate, snap, wrappers: start services in the right order during install <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6032>
 * cachio lunch
<cjwatson> koala_man: I don't suppose you have the skillset to track down https://github.com/haskell/HTTP/issues/68 ?
<cjwatson> koala_man: That seems to be the root cause of this weird proxy bug with shellcheck
<koala_man> cjwatson: I might, but it would probably require source changes to HTTP, cabal or both. How would those fixes make it back into the xenial build image?
<cjwatson> koala_man: It's possible we'll have to work around it; I'm not sure yet
<cjwatson> koala_man: But it appears to be violating RFC MUSTs, so ...
<koala_man> cjwatson: xenial uses cabal-install version 1.22.6.0-2 while this bug appears to be a non-issue in >1.23.0.0 (after https://github.com/haskell/cabal/commit/b780cc77dd) due to not using the HTTP library anymore
<cjwatson> Oh, interesting
<koala_man> and that was over three years ago
<cjwatson> (I'm less interested in workarounds now I've captured straces that show xenial's cabal-install version blatantly Doing HTTP Wrong)
<cjwatson> Same symptoms as in that bug, basically: gets 301 with Connection: close, tries to write the redirected request to the same FD, gets EPIPE, gets very sad
<Chipaca> backport of the 1.24 from bionic in a ppa? or has the haskell stack changed too much?
<cjwatson> Backporting Haskell stacks tends to be LOL
 * Chipaca chooses to read that as a labour of love
<cjwatson> When I used to do this from time to time in Ubuntu it took literally days just to do all the rebuilds
<cjwatson> Can't imagine doing it as an SRU
<cjwatson> cabal-install *might* be standalone enough ...
<koala_man> haha, yes, the ecosystem certainly has its challenges
<Chipaca> cjwatson: I can't even get the build deps for the one in xenial
<Chipaca>  builddeps:haskell-cabal-install : Depends: libghc-zlib-dev (< 0.6) but 0.6.1.1-1 is to be installed
<cjwatson> Yeah, that was bumped to < 0.7 in bionic; I guess haskell-cabal-install wasn't rebuilt in the last round because it's a standalone application so nobody noticed
<cjwatson> bionic's version needs libghc-hackage-security-dev and libghc-tar-dev (>= 0.5.0.3) though, neither of which are in xenial
<cjwatson> Conceivably easier to backport that one commit
<Chipaca> maybe there's a haskellers ppa out there
<cjwatson> Well, plus zlib dep fix
<cjwatson> We really need the version in xenial to be able to actually do HTTP properly
<cjwatson> I don't really want to punt everyone to a PPA
<Chipaca> .... maybe there's a snap of it
<Chipaca> :-D
 * Chipaca runs away and hides
<koala_man> :D
<koala_man> shellcheck can also be built with haskell-stack. I can see if the xenial version is recent enough, and whether it does HTTP better
<cjwatson> I'm just grabbing github:haskell/cabal to see if I can work out what to backport and if it's possible without getting into too many complication
<cjwatson> s
<cjwatson> I smell dinner though
<mup> PR snapd#5972 closed: tests: initial setup for testing current branch on nested vm and hotplug management <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5972>
<ogra> hmm
<ogra> so i just uninstalled htop, reinstalled it with --classic ... noticed that it can see al processes without any interfaces connected ... then uninstalled it again, reinstalled it without --classic and it can *still* manage all processes despite no interfaces being shown connected
<ogra> does using --classic for a snap premanently trash confinement now ?
<ijohnson> ogra: try using `/usr/lib/snapd/snap-discard-ns htop` and running htop again, it may be reusing the classic namespace setup for the snap, but I'm not sure as I don't know what exactly is setup for a classic snap (if anything)
<ogra> well, i'd expect "unconfined"
<ogra> well, nothing changed
<ogra> i have a confined htop that can see (and kill !!) all processes
<ijohnson> right but I don't know if there's a mount namespace setup for classic snaps, as if there is it could be re-used when you run it again. I've run into similar issues with namespaces not getting discarded after a snap was removed
<ogra> well, i discarded it with the above commend
<ogra> no change
<ijohnson> yeah no other ideas from me then
<ogra> this smells very very broken :/
<ijohnson> yeah I didn't actually realize that you could install a strict snap with classic confinement, I thought that was disallowed
<ogra> i even get multiple pages of DENIED messages in dmesg -w
<ogra> when starting htop
<ogra> yet it can see the whole processlist and kill all processes owned by me
<ogra> operates completely unconfined
<ijohnson> should probably report as a bug on LP (perhaps as a security bug?)
<ogra> Chipaca, if i used --classic with a confined snap, do i have to do some magical secret handshake to get it back to being confined ?
<ogra> (even uninstalling/reinstalling, discarding the namespace and whatnot doesnt seem to get me confinement back)
<Chipaca> ogra: remove and reinstall should do the trick
<ogra> well, probably i'm dong something wrong
<Chipaca> ogra: if it doesn't, you've found a bug
<ogra> then i did
<ogra> sigh
<Chipaca> ogra: stop breaking snapd :-p
<ogra> now maxiberta can read my disk !!!
<Chipaca> ogra: I hear he's bribe-able
<ogra> yeah, but the next sprint we cross paths is far ... so beer bribe doesnt work
<Chipaca> ogra: you'd be shocked to know how cheap it would be to get it delivered
<ogra> delivered, yeah ... but then ... customs ...
<Chipaca> ogra: i meant something like https://www.pedidosya.com.ar/restaurantes/buenos-aires/don-cervecero-menu
<Chipaca> ogra: (those are argentine pesos)
<Chipaca> ~10eur for 10 473cc cans delivered
<Chipaca> maybe :-)
<Chipaca> anyhoo, what was i doing
<Chipaca> oh yeah swearing at spread
<ogra> https://bugs.launchpad.net/snapd/+bug/1799760
<mup> Bug #1799760: using --classic for a confined snap doesnt get me confinement back even after reinstalling the snap <snapd:New> <https://launchpad.net/bugs/1799760>
<mup> PR snapd#6038 opened: release: 2.36 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6038>
<Chipaca> zyga: ^^ bug from ogra you might like
<ogra> i wont reboot that system ... so whatever else needs to be captured, the machine will stay in that state
 * zyga looks
 * cachio afk
<mup> PR snapcraft#2379 closed: meta: add assumes if using "full" app adapter <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2379>
<mup> PR snapcraft#2385 opened: cli: consolidate re-execution <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2385>
<mup> PR snapd#6039 opened: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
<cjwatson> koala_man: I managed to set up a simpler reproduction environment: for me, configuring squid with "client_persistent_connections off", and then running "http_proxy=... strace -f -o cabal.trace -s 4096 cabal fetch pandoc" in a clean sandbox with an empty cabal download cache provokes it often enough to be somewhat debuggable
<cjwatson> (the strace is needed to slow it down slightly - I think this is a race between when it tries to write the redirected request to the connection and when it's closed by the other end
<cjwatson> )
<cjwatson> koala_man: with that I've found that while bionic's cabal-install breaks in the same way (without curl), Debian unstable's (also without curl) seems to work - and it's not just winning the race, because I can see it getting EPIPE/SIGPIPE from write() and then recovering where the earlier version didn't
<cjwatson> so that might be something I can bisect
<mup> PR snapd#6040 opened: data/apt: close stderr when calling snap in the apt install hook <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6040>
<koala_man> cjwatson: this is to patch into HTTP and then rebuild cabal-install against it, thereby minimizing potential side effects?
<mup> PR snapcraft#2384 closed: project: do not install base if already installed <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2384>
#snappy 2018-10-25
<mup> PR snapcraft#2369 closed: Hide progress bar for dumb terminals <Created by eberkund> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2369>
<koala_man> cjwatson: I've looked into alternative routes. The stack build fails because it's linked against an old version of Cabal, and the docker build fails because multistage builds weren't introduced before 17.05 (xenial has 17.03)
<mup> PR snapd#6038 closed: release: 2.36 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6038>
<mborzecki> morning
<mborzecki> how can i put an apparmor profile of a snap into complain mode?
<dot-tobias> good morning everyone
<mborzecki> dot-tobias: morning
<zyga> Good morning
<zyga> mborzecki: you can use apparmor tools
<zyga> But I never remember which
<zyga> Just edit the profile
<mborzecki> zyga: something i wanted to avoid :)
<zyga> Change the part that reads (attach_disconnected,....)
<zyga> And insert âcomplainâ there AFAIR
<zyga> Then parse and load into the kernel
<mborzecki> zyga: tried aa-complain, but expects a path to the binary, which is sligtly funny as you can have a profile just with a label like we do for snaps
<pstolowski> heyas
<zyga> Hey
<mborzecki> looks like this test is slightly incorrect: https://github.com/snapcore/snapd/blob/master/cmd/snapd/main_test.go#L57-L94 the daemon is started, but we never wait for it to finish
<mborzecki> added some synchronization and now it's clear that Run() does not exit with nil, but raises value *errors.errorString = &errors.errorString{s:"cannot gracefully finish, still active connections on /tmp/check-8792093359864697921/0/run/snapd.socket after 5s"} ("cannot gracefully finish, still active connections on /tmp/check-8792093359864697921/0/run/snapd.socket after 5s")
<mborzecki> that's probably because http connections from the client are kept alive
<mborzecki> there are 2 intersting failures in unit tests i've seen today, first one https://paste.ubuntu.com/p/kTHywvD39V/ i can reproduce it locally if i change the sleep to something really small, hence i started adding extra synchronization around snapd.Run()
<mborzecki> and the 2nd one: https://paste.ubuntu.com/p/SwXy77XJ6H/ where userd got SIGQUIT ?
<mborzecki> this one is appearing quite often in 2.36 branch
<sil2100> eh, I fucked up
<sil2100> Can anyone check if the right pc i386 and amd64 gadget snaps are in stable and candidate now?
<sil2100> I never use the snapcraft dashboard UI for promoting snaps ever again...
<zyga> mborzecki: thank you
<zyga> sil2100: define correct
<sil2100> The last one that was supposed to be there, but I found it in the stable images
<sil2100> Damn I'm pissed off
<zyga> I'm still sleepy, not sure how to check
<zyga> I can tell you the revisions I see
<zyga> but not sure if that helps
<sil2100> Wanted to promote 18 gadget snaps, thought the dashboard UI is smart and will promote to the right 18/stable etc.
<zyga> sil2100: 18/stable is empty
<zyga> so perhaps not correct
<zyga> there are some revisions in 18/beta and edve
<sil2100> zyga: I was talking about 16
<sil2100> I now just promoted the 18 ones
<zyga>   stable:       16.04-0.8 (9)  856kB -
<zyga>   candidate:    16.04-0.8 (9)  856kB -
<zyga>   beta:         16.04-0.9 (24) 872kB -
<zyga>   edge:         16.04-0.9 (24) 872kB -
<sil2100> zyga: want to make sure the 16 ones are as correct as they were
<zyga> it looks rather unchanged
<sil2100> phew
<zyga> but I don't know what they were before
<zyga> so hard to say
<mborzecki> heh, looking into problem 1, we're doing a graceful shutdown and daemon is stuck calling net.Conn.Close()
<zyga> pstolowski: could you please look at 6010, landing this would unblock me
<pstolowski> zyga: sure
<mborzecki> this doesn't make any sense, it's like close(fd) which should not block
<zyga> mmm
<zyga> mborzecki: is it really just that?
<mborzecki> zyga: https://golang.org/src/net/net.go#L197
<zyga> mborzecki: sorry, I don't feel very well today and I'm slow at thinking, can you walk me through the problem statement
<mborzecki> zyga: take a look here: https://github.com/snapcore/snapd/blob/master/cmd/snapd/main_test.go#L57-L94, there's a gorouting which runs `err := snapd.Run()`
<mborzecki> zyga: but in the test we do not wait for the goroutine to finish
<mborzecki> zyga: now if we wait, it's either stuck or exits with error `cannot gracefully finish, still active connections on /tmp/check-8792093359864697921/0/run/snapd.socket after 5s`
<zyga> aha
<zyga> and where is the graceful shutdown code?
<mborzecki> zyga: that's because the test is poking the API via http, but net/http does not close the connection right away after the request is finished, so it's still 'seen' at the server side and we try to go through graceful shutdown calling Close() nicely on each connection
<mborzecki> zyga: it's here https://github.com/snapcore/snapd/blob/master/daemon/daemon.go#L462-L490
<mborzecki> zyga: specifically i see it stuck on https://github.com/snapcore/snapd/blob/master/daemon/daemon.go#L471 now
<zyga> mborzecki: and the net.Conn that we re interacting with
<zyga> what is it in reality?
<zyga> that is, what Close are we really calling
<mborzecki> zyga: this one https://golang.org/src/net/net.go#L197
<zyga> and netFD?
<mborzecki> heh added DisableKeepAlives to the transport config and now it's closing right away
<mborzecki> zyga: https://golang.org/src/net/fd_unix.go#L182 and then it goes into some internal/poll https://golang.org/src/internal/poll/fd_unix.go#L86 there's a comment that Close() may block
<dot-tobias> greyback: Regarding i3 WM in chromium-mir-kiosk not picking up rotation: I dug into the configuration and it seems that i3 does indeed not pick up the mir-kiosk vertical rotation. However, when I enable kiosk mode in the snap, chromium is forced to fullscreen, and resizing commands are discarded by i3. Do you have a hint on where I can disable the fullscreen? Maybe in xwayland-kiosk-helper?
<greyback> dot-tobias: the helper auto-generates a config file to make a surface fullscreen, see https://github.com/MirServer/xwayland-kiosk-helper/blob/master/xwayland-preload/xwayland-kiosk-launch#L121
<greyback> dot-tobias: however chromium-mir-kiosk provides it's own i3 config file
<greyback> I don't think enabling/disabling kiosk mode impacts the use of that config file at all
<zyga> mborzecki: a bit of internals for the morning
<zyga> are we holding it wrong?
<dot-tobias> greyback: Yeah, just found that variable ð I'm uncertain how the two i3 configs interact, but what I can observe is that commands in the chromium-mir-kiosk i3 config are ignored when kiosk mode is enabled for chromium-mir-kiosk. which âjustâ loads the kiosk Chrome app AFAIR
<mborzecki> zyga: i think it's outside of our control, let me check the unixDialer we use
<greyback> dot-tobias: that's not what I intended anyway. The goal was: if snap provides its own i3 config, use that. If not, fallback to an auto-generated one
<zyga> mborzecki: given that we don't do real http we could disable keepalive
<zyga> mborzecki: and perhaps leave a clear note that dragons lurk beyond
<zyga> pstolowski: one for you https://forum.snapcraft.io/t/hook-run-script-when-an-interface-is-connected/8155
<pstolowski> zyga: thanks, i'll answer
<pstolowski> zyga: i've just hit the issue popey reported recently, with gnome-calculator. i installed its snap yesterday, it's connected to gnome platform snap yet it doesn't see it. i'm on 2.36
<pstolowski> zyga: my laptop has been running for only a few days (since monday)
<zyga> can you nester
<zyga> nsenter
<zyga> and then see if that place $SNAP/gnome-platform looks sane please
<popey> yay!
<pstolowski> zyga: will do
<zyga> pstolowski: any files inside?
<zyga> and any changes recently?
<pstolowski> zyga: sorry, tryng to finish the review of your PR, will check that issue next. the only changes are
<pstolowski> 195  Done    yesterday at 17:39 CEST  yesterday at 17:39 CEST  Auto-refresh snap "lxd"
<pstolowski> 196  Done    today at 09:04 CEST      today at 09:05 CEST      Auto-refresh snaps "core", "lxd"
<zyga> thanks
<pstolowski> so, unrelated
<zyga> aha, core refreshed
<zyga> core change is related (perhaps)
 * zyga tries locally
<pstolowski> hmm
<zyga> h
<zyga> HA
<zyga> reproduced :)
<zyga> popey: I got this now
<zyga> I switched core from edge to beta
 * zyga investigates
<popey> \o/
<zyga> and I got the sudo nsenter + ctrl-d bug :/
<popey> also yay :)
<mup> PR snapd#6041 opened: client, cmd/daemon: allow disabling keepalive, improve degraded mode unit tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6041>
<pstolowski> zyga: a few comments
<pstolowski> zyga: wow, you reproduced, yay x2
<pstolowski> nonetheless, looking into my namespace
<zyga> pstolowski: you can discard the namespace, I will fix that issue
<zyga> thank you for the review, looking at the response
<mborzecki> can someone take a look at this: https://github.com/snapcore/snapd/blob/master/overlord/standby/standby.go#L80-L105 if i'm reading this right, when Stop() is called at the bad moment and m.stopCh is nil, the goroutine will go into sleep waiting for timeout even though it's supposed to exit
<pstolowski> zyga: great you found the problem! thanks
<pstolowski> degville: hey, https://forum.snapcraft.io/t/hook-run-script-when-an-interface-is-connected/8155/3 reminded me of the missing doc for interface hooks
<pstolowski> degville: shall i describe all that in an email and send to you?
<mup> PR snapd#6042 opened: overlord/standby: fix a race between standby goroutine and stop <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6042>
<degville> pstolowski: hello - yes, that would be great - thanks!
<pstolowski> degville: ok, will do
 * zyga breaks
<zyga> sorry guys, I feel sick
<Chipaca> why am i getting shellcheck errors for something that's already on master :-(
<Chipaca> and why is shellcheck now saying "unable to decommit memory"
<mborzecki> Chipaca: whcih file?
<mborzecki> Chipaca: btw. 6042 might be interesting for you
<zyga> Chipaca: uname?
<Chipaca> oh. new shellcheck.
<Chipaca> mborzecki: https://pastebin.ubuntu.com/p/KSJXRVXFVz/
<Chipaca> zyga: GO AWAY YOU'RE SICK FFS
<Chipaca> zyga: we'll get IRC cooties
<Chipaca> mborzecki: fixing
<mborzecki> Chipaca: which PR is that? shellcheck version should be printed in the log
<Chipaca> mborzecki: this is the spread-run shellcheck, so it's the snap
<Chipaca> mborzecki: the snap was created 2018-10-25T05:05:12.188830+00:00
<Chipaca> I think that means koala_man found out that haskell-stack does not have the "cabal does not do good http" bug
<mborzecki> heh
<Chipaca> mborzecki: anyway, to answer your question, https://api.travis-ci.org/v3/job/445913480/log.txt
<Chipaca> mborzecki: and AFAIK the spread run does not print the shellcheck version
<zyga> Chipaca: https://ghc.haskell.org/trac/ghc/ticket/12865
<mup> PR snapd#6028 closed: testutil, cmd/snap: introduce and use testutil.EqualsWrapped and fly <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6028>
<Chipaca> âThis is a stylistic issue that does not affect correctness. If you prefer the original expression, you can't not Ignore it with a directive or flag.â
<Chipaca> ^ shellcheck being snarky about the double-negative implied by ! -z / ! -n
<mup> PR snapd#6043 opened: tests/main: fixes for the new shellcheck <Created by chipaca> <https://github.com/snapcore/snapd/pull/6043>
<Chipaca> mborzecki: ^
<mborzecki> Chipaca: yeah, looks good
<mborzecki> nice that it's picky about such small things too
<Chipaca> mborzecki: also nice that it catches [ ! -z ] and ! [ -z ] the same
<mborzecki> yeah, one of these days it'd be nice to look at the implementation, my money is on having those actually encoded as pattern matching directly in the code
<Chipaca> haskell doing pattern matching? sounds about right :-)
<zyga> pstolowski: updated https://github.com/snapcore/snapd/pull/6010
<mup> PR #6010: cmd/snap-discard-ns: add support for per-user mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/6010>
<pstolowski> ok
<pstolowski> zyga: +1
<mborzecki> any ideas about https://paste.ubuntu.com/p/SwXy77XJ6H/ ? i've looked in go and check, does not look like any of those would send SIGQUIT
<mborzecki> the test sends SIGUSR1 to itself, but that's handed properly already
<zyga> mborzecki: nope, nothing remotely SIGQUITS this
<zyga> maybe it is spread itself?
<zyga> but I don't know
<mborzecki> zyga: grepped through spread, came up empty
<zyga> actually, I grepped in spread as well
<zyga> :/
<mborzecki> pushing an update to arch pacakge in a bit
<cjwatson> Chipaca: They installed an even more terrifying hack than that
<Chipaca> cjwatson: â¦ emacs?
<cjwatson> https://bugs.launchpad.net/launchpad-buildd/+bug/1797809/comments/3
<mup> Bug #1797809: Build fails on snapcraft.io, works locally (during `cabal update`) <launchpad-buildd:Triaged> <https://launchpad.net/bugs/1797809>
<Chipaca> hah
<Chipaca> proxies all the way down
<cjwatson> I also discovered that the reason newer cabal "works" even without curl is that it now supports multiple mirrors and just falls back to the next one in the list when its connection gets terminally confused by the first one
<cjwatson> So I'm trying to hack persistent connection support into launchpad-buildd's internal proxy
<mup> PR snapd#6043 closed: tests/main: fixes for the new shellcheck <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6043>
<dot-tobias> greyback: re: fullscreen chromium-mir-Kiosk in rotate => https://git.launchpad.net/~gerboland/+git/chromium-kiosk-app-snap/tree/manifest.json#n35
<zyga> mborzecki, Chipaca, pstolowski: would you mind stating your opinions on https://github.com/snapcore/snapd/pull/6010/commits/0ecf1448668b726021ff94408981599d335576d0
<mup> PR #6010: cmd/snap-discard-ns: add support for per-user mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/6010>
<dot-tobias> greyback: I suspect this launches chromium in fullscreen, and i3 does not seem to pick up the rotation coming from mir-kiosk / xwayland. Resizing commands in i3 do not work for fullscreen windows (which is logical, but impractical for my use-case)
<dot-tobias> greyback: Iâll add this to the forum topic (http://discourse.ubuntu.com/t/snaps-to-develop-a-web-kiosk-on-ubuntu-core-using-wayland/6424?page=5) once Iâm back at work. Would be very glad if you have suggestions how I can force i3 to respect the rotated layout. Thank you for your work on all the kiosk snaps ð
<greyback> dot-tobias: hmm interesting, I forgot about that policy setting
<greyback> dot-tobias: yes please do update the forum. I'll try to find time to look into the problem
<dot-tobias> greyback: Iâll do that and ping you here once done. Thank you for your time in advance ðIâll try to find a way to hide chromium UI when not in fullscreen mode.
<cachio> zyga, hey, I need to take my son to make an audition study
<cachio> zyga, I'll try to be back for the stand up but not sure
<zyga> cachio: noted
<zyga> thanks, good luck :)
<cachio> zyga, tx
<pstolowski> zyga: will do in a moment
<mborzecki> snapd updated in AUR, i've also updated the wiki with some extra info
<mborzecki> funny cause someone else edited the wiki while i was editing it and added a note about apparmor, which was like 10-15 minutes after i pushed the change to aur
<ijohnson> mborzecki: so is snapd on Arch now fully confined?
<mborzecki> ijohnson: not everything is supported yet, jdstrand left some details here: https://forum.snapcraft.io/t/arch-linux-and-apparmor/7036
<Chipaca> zyga: I have close to 0 opinions on C formatting style
<zyga> Chipaca: mainly if you are -1 on moving to clang-format
<Chipaca> zyga: I am not
<Chipaca> zyga: the only C formatting style I think is bad is the one that pushes the {}s and the ;s to column 80
<Chipaca> degville: you around?
<degville> Chipaca: yep
<Chipaca> degville: could you give the long help strings in https://github.com/snapcore/snapd/blob/dfef243c027b84ae8331a36dddbf61b6bf847813/cmd/snap/cmd_snapshot.go a once over?
<Chipaca> degville: (search for "var long")
<pstolowski> zyga: the clang-format lgtm, nothing out of ordinary,+1
<degville> Chipaca: will do - looking now.
<zyga> thanks!
<Chipaca> sborovkov: hi
<sborovkov> Chipaca, hello
<Chipaca> sborovkov: remind me, if I'm not being rude, what was it you worked on?
<sborovkov> screenly, digital signage :)
<Chipaca> sborovkov: are you, or is your team, sensitive to snapd api changes?
<Chipaca> I think it wasn't you, fwiw
<sborovkov> hmm, not to a big extent, We currently only use it to set config.txt options
<Chipaca> a shame, I'm going to have to talk to field engineering to get them to talk with the team in question, more roundabout than i would've preferred
<sborovkov> so you might be thinking about someone else
<Chipaca> sborovkov: yep yep :-)
<Chipaca> sborovkov: this is about a screenshots -> media transition
<Chipaca> happening in the 2.36 â¦ 2.39 timeline
<sborovkov> definitely not us then :)
<Chipaca> sborovkov: thank you for confirming :-) I'll go pester field eng
<zyga> mborzecki: do you know why the set of panics we see in unit tests surfaced now?
<zyga> mborzecki: is it something that changed on our side recently?
<Chipaca> mborzecki: which panics?
<Chipaca> um
<Chipaca> zyga: ^
<zyga> Chipaca: unit tests time out and panic
<zyga> just look at recent test failure
<Chipaca> zyga: in cmd/snap?
<zyga> yes
<Chipaca> hmm
<Chipaca> yes I did see that, thought it was a one-off
<Chipaca> machine taking a sleep or sth
<Chipaca> i'll dig
<mborzecki> Chipaca: w8, whci one? there's a PR addressing one of the issues i saw
<Chipaca> mborzecki: ah! which pr is that?
<mborzecki> Chipaca: there's one here https://github.com/snapcore/snapd/pull/6041
<mup> PR #6041: client, cmd/daemon: allow disabling keepalive, improve degraded mode unit tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6041>
<mborzecki> Chipaca: another one https://github.com/snapcore/snapd/pull/6042 this was not caught by unit tests but race detector suggested and issue and IMO there is one
<mup> PR #6042: overlord/standby: fix a race between standby goroutine and stop <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6042>
<Chipaca> mborzecki: the one I saw (and I thought zyga was asking about) was one where you get the test killed by go because it times out
<mborzecki> intersting, what PR is that?
<zyga> mborzecki: I mean your PRs are good but I wonder what happened that this started to happen
<Chipaca> zyga: do you have one of these failures handy?
<zyga> guys, I feel sick and could need to... break, at any time
<zyga> can one of you run the standup please
<zyga> my update: working on user mounts but interrupted by reproducing the issue popey discovered
<zyga> fixing it with top priority
<zyga> Chipaca: let me look
<zyga> Chipaca: here is one https://api.travis-ci.org/v3/job/445642309/log.txt
<Chipaca> whoops standup
<mborzecki> cachio: standup
<zyga> mborzecki: he said he would probably not make it
<mborzecki> ah ok
<zyga> sorry, I should have mentioned that above
<Chipaca> zyga: you coming?
<zyga> no, sorry
<Chipaca> ah ok
<Chipaca> the cmd/snap unit tests really need the new WrappedEquals checkers -- otherwise you can't run them from the 'go test -c' binary unless your terminal is 80 columns (or you redirect stdin)
<Chipaca> mborzecki: do you see what i mean about StandbyOpinions not being goroutine-safe?
<Chipaca> mborzecki: OTOH, why is timerCh an attribute, instead of a variable?
<mborzecki> Chipaca: heh, probably went through a couple of review changes
<mborzecki> Chipaca: using tomb we'd drop stopCh, then timerCh could be variable and we're left with AddOpinion() which could use some locking but not necessarily, slapping a comment that it needs to be called before Start() should be sufficient
<Chipaca> mborzecki: also setting closeCh to nil doesn't make sense; you want it closed, not nil, so the receive works (as opposed to blocking on nil)
<mborzecki> Chipaca: oh and daemon should probably wait for standby to finish
<mborzecki> Chipaca: right now it does not
<Chipaca> mborzecki: are either of your PRs fixing the ... value *errors.errorString = &errors.errorString{s:"dbus: connection closed by user"} ("dbus: connection closed by user") failure?
<mborzecki> Chipaca: nope, where did you get that one?
<Chipaca> mborzecki: /snap/bin/go test -count=100 -failfast ./cmd/snap
<Chipaca> mborzecki: fails with that rather quickly
<Chipaca> mborzecki: /snap/bin/go becaue 1.10 has -failfast
<mborzecki> Chipaca: hmm is godbus reusing the connection?
<Chipaca> mborzecki: dunno :-) i'm skipping the test to go on and find the hanging one
<tomwardill> more pre-refresh hook questions! Is it possible to manually run a hook? Otherwise testing this is a bit tricky.
<ogra> perhaps via "snap run --shell <snap app>"
<ogra> that gives you a shell inside the snap env ...
<tomwardill> ooh, that might do it, thanks ogra
<mborzecki> Chipaca: it is reusing the connection
<mup> PR snapd#6040 closed: data/apt: close stderr when calling snap in the apt install hook <Simple ð> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6040>
<Chipaca> zyga: ping
<zyga> yes?
<Chipaca> zyga: problem with the ptrace thing in other arches
<Chipaca> zyga: PTRACE_GETFPREGS i mean
<Chipaca> zyga: syscall.PTRACE_GETFPREGS is not always there
<Chipaca> i'm adding a test for this, hopefully
<Chipaca> xnox: are you around? question about gcc-arm-linux-gnueabihf vs gcc-multilib
<zyga> yes
<zyga> I think that's an arch specific thing but let me look
<Chipaca> zyga: do you know about gcc-arm-linux-gnueabihf vs gcc-multilib?
<zyga> probably not
<Chipaca> ok
<zyga> http://man7.org/linux/man-pages/man2/ptrace.2.html
<zyga> Chipaca: floating point regs, not on all arches
<xnox> Chipaca, sup? two are different; and also different depending on the host's arch.
<xnox> Chipaca, so which host arch are you on, what are you using, and why / what do you want to achieve?
<Chipaca> xnox: I was once again trying to cross-build go to armhf, and your blog post is my only reliable reference :-) but every time I come to it I have to install one and remove the other, and then time passes and I have to reverse it, and it seems broken
<Chipaca> xnox: so I was wondering if that was The Way, or if it was outdated and I was missing a trick
<xnox> ha
<xnox> Chipaca, which blog is that?
<Chipaca> http://blog.surgut.co.uk/2014/06/cross-compile-go-code-including-cgo.html
<Chipaca> I use this vintage tech called a "bookmark"
<xnox> Chipaca, no idea what that is? is like a star?
<Chipaca> :)
<xnox> Chipaca, also well, click chroots, don't exist anymore.... so do you use $ mk-sbuild --arch armhf bionic ; schroot -u root -c bionic-armhf ?
<ogra> xnox, nah, starts are for favourites ...
<Chipaca> xnox: CGO_ENABLED=1 GOOS=linux GOARCH=arm CC=arm-linux-gnueabihf-gcc  GOPATH=~/canonical/snappy/ go build -v -o /dev/null ./cmd/snap-seccomp/
<Chipaca> (the GOOS is spurious and you can ignore it)
<xnox> Chipaca, gcc-multilib is usually to allow building "co-pairs" of things - e.g. armel/armhf/arm64 on arm platforms; i386/amd64 on x86 platforms and so on.
<xnox> gcc-arm-linux-gnueabihf is a generic cross-compiler which should be available on all arches; and as a bonus point it is the native compiler on armhf.
<xnox> this way wherever one is, one should always be able to install and use gcc-arm-linux-gnueabihf
<xnox> Chipaca, i'm not sure how/why/where that would conflict with gcc-multilib
<xnox> cause it shouldn't.....
<xnox> and if you are doing all that, you shouldn't need to ever install gcc-multilib, on any host.
<Chipaca> xnox: ah, ok. Then don't look because you'll get lost down the warren.
<xnox> Chipaca, i see that gcc-multilib declares conflicts on everything.... so like stop using gcc-multilib i guess?
<Chipaca> xnox: ok, I'll stay like this, and the next time I need to revert it I'll flag you down again
<Chipaca> maybe the other flow is broken :-)
<Chipaca> xnox: thank you
<xnox> Chipaca, on the surface, i see that gcc-multilib potentially overdeclares conflicts.....
<oSoMoN> jdstrand, IÂ could use your help with bug #1738164 (see my last two comments). I now have a yubikey 4 so I can easily test things
<mup> Bug #1738164: [snap] U2F doesn't work with yubikey <snap> <chromium-browser (Ubuntu):Confirmed for osomon> <https://launchpad.net/bugs/1738164>
<mborzecki> Chipaca: so -count=n with dbus test does not work because the connection is shared, there is one reference in used and another one in dbustest, i'm working on some changes to use private connection instead
<Chipaca> mborzecki: ok
<Chipaca> mborzecki: I've forked to writing a mutliarch spread test
<ppisati> ogra: can you still reproduce those rpi wifi issues you were mentioning me some time ago?
<zyga> is master fixed now?
<ogra> ppisati, it seems to have been gotten a bit more stable lately but i still see it reboot at times (i have a acrit that pings the GW and force-reboots the board if it cant reach it) see https://paste.ubuntu.com/p/B7kDjxjKbt/
<ogra> *a script
<zyga> popey: I know what the bug is
<zyga> it's very simple to fix
<zyga> man
<zyga> THANK YOU
<zyga> it's super important!!!
<popey> zyga: oh!?
<zyga> I will land a quick one liner
<zyga> but then proceed with better fix
<popey> I love a one-liner
<zyga> I also added a logging subsystem to show what is going on
<ppisati> ogra: are you using a raspberrypi official power supply?
<ogra> ppisati, nope, a 2A phone charger
<zyga> Chipaca: hey
<zyga> do you have a sec?
<ppisati> ogra: ok, if you could get one and try that, it will surely help - with my rpi3b+ i encountered a lot of instabilities, in particular duing the boot phase, and they all went away when i switched to an official raspberry power supply
<ppisati> ogra: other than that, a tentative fix landed in the rpi tree so i might have a kernel to test, if you could give it a spin
<mup> PR snapd#6044 opened: cmd/snap-confine: remove stale mount profile along stale namespace <Created by zyga> <https://github.com/snapcore/snapd/pull/6044>
<ogra> ppisati, well, i can surely try but thats a normal pi3 ... i doubt it is underpowered ... there is a USB wbcam attached that permanently streams though ... my guess would rather go towards USB saturation than to missing power
<ogra> sure, i'll happily test
<Chipaca> zyga: more or less, why?
<zyga> Chipaca: can you please look at https://github.com/snapcore/snapd/pull/6044
<mup> PR #6044: cmd/snap-confine: remove stale mount profile along stale namespace <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6044>
<zyga> it's pretty critical
<zyga> I wanted to do a staged patch, a quick fix that is provided here
<ogra> (needs a bit though, this image is not running a sideloaded kernel, i'll need to build a new one)
<zyga> a more lengthy fix that uses snap-discard-ns instead of reimplementing it locally
<Chipaca> zyga: is this the one for --classic not going away?
<zyga> and perhaps a spread test if I can come up with a way to write one
<zyga> no, for mount profiles going away on base refreshes
<zyga> or breaking all desktop apps
<zyga> :/
<zyga> popey: ^
<zyga> that's the fix
<zyga> it won't fix any affected systems but for those snap-discard-ns can be ued
<zyga> subsequently it will be OK
<Chipaca> ah
<ppisati> ogra: bionic or xenial kernel?
<ogra> ppisati, core 16 stable
<ogra> so xenial
<popey> I don't fully understand, but don't worry :)
<pstolowski> zyga: \o/
<zyga> popey: it will get fixed, I will work with mvo on making this patch released
<zyga> and on tests so that it doesn't regress
<popey> ok, thanks
<zyga> thank *you*
<Chipaca> zyga: did you look further into the syscall.PTRACE_SHENANIGAN thing?
<zyga> not more that it is only available on some arches
<zyga> what is the problem?
<zyga> we should just have this logic in the interface
<zyga> we can start with easy
<zyga> if on i386 or amd64 == add that part
<zyga> otherwise not
<zyga> and that should be enough
<Chipaca> zyga: master is currently broken on arm64 armhf powerpc ppc64el s390x
<zyga> because of that?
<Chipaca> zyga: apparently?
<Chipaca> zyga: report comes from mvo
<zyga> well, master is broken in general, unit tests keep exploding
<zyga> aha
<zyga> let's do this
<zyga> let's maker that conditional
<zyga> but I need to get some stuff for my stomach first
<zyga> so ~~ one hour
<zyga> the patch should be mininal
<Chipaca> i'm working on a spread test that cross-compiles everything just in case
<zyga> iff it can land
<zyga> nice, thank you!
<Chipaca> so we don't break like this again
<Chipaca> but it's taking me a bit :-)
<zyga> Chipaca: it would be great to unbreak master
<Chipaca> zyga: can you? i'll review :-D
<zyga> I mean
<zyga> the current one that explodes on travis
<Chipaca> ah
<Chipaca> zyga: with this timeout thing?
<zyga> I can fix the trace issue
<Chipaca> zyga: but it's not every time is it?
<zyga> yeah
<Chipaca> i was looking at that but then this cross-thing came up
<Chipaca> which seemed more important :-)
<zyga> ok, I'll break now
<zyga> ttyl
<zyga> (in one hour)
<Chipaca> xnox: what's the way to get i686-linux-gnu-gcc (or i386 or w/e) on amd64?
<zyga> Chipaca: you can just use -mtune 32 or something
<zyga> I used to do that often
<zyga> hold on
<Chipaca> zyga: yes, but
<xnox> Chipaca, that's multilib, he doesn't want that.
<Chipaca> was wondering if amd64/i386 were the same
<Chipaca> as all the others :-)
<Chipaca> if not it's fine
<zyga> xnox: is there a difference in the resulting binary?
<Chipaca> zyga: are you back, looking at the ptrace thing?
<xnox> Chipaca, you want gcc-i686-linux-gnu i believe
<zyga> (or: is it worth testing with gcc on i386 vm)
<xnox> zyga, no, but there is a difference in # of compilers you can co-install.
<zyga> aha
<zyga> I see, thanks
<zyga> so some compilers conflict with each other?
<Chipaca> zyga: oh yes
<Chipaca> zyga: I started taking a stab at the ptrace thing, and it's strange
<Chipaca> zyga: i'm getting errors in more places than i'd expect
<xnox> Chipaca, zyga - and i strongly recommend you to use a chroot, such that you can safely install libfoo-dev:i386 libfoo-dev:amd64 etc if your native code requires C libraries/headers for a given cross-arch.
<xnox> e.g. mk-sbuild --arch armhf|arm64|i386 bionic, and schroot into that.
<xnox> it will have all the right compilers pre-installed, accessible by the right name gcc-${arch}
<Chipaca> xnox: I'll give that a try if my current approach fails even a teeny bit more
<Chipaca> xnox: (I don't see too much value in the chroot approach as these are for running in throwaway vms already)
<zyga> xnox: curious about armhf, would that work on amd64 as well? I mean, is that a chroot with a native cross compiler or a chroot with a non-native native compiler
<Chipaca> zyga: is it right that there's no PTRACE_GETFPREGS on 386?
<xnox> Chipaca, yeah, if you are already isolated from your host, it's fine to run as is.
<xnox> zyga, re-read again what you are saying =)
<zyga> xnox: well, I know what I said :)
<zyga> is that a chroot for native execution on the host
<zyga> or would it require qemu static
<xnox> of course not
<xnox> =)
<xnox> mk-sbuild can setup native chroots, and chroots for cross-compiling
<xnox> see manpage.
<xnox> but the neat thing is that our cross-compilers for $foo, on all arches, and the native compiler for $foo on $foo have the same binary name.
<zyga> Chipaca: looking at the kernel
<popey> jdstrand: you about for an apparmor problem?
<Chipaca> zyga: ignore that bit about PTRACE_GETFPREGS on 386, i'm dumb
<Chipaca> zyga: ignore ignore
<zyga> xnox: that _is_ neat :)
<xnox> thus one can always use the same CC= name
<zyga> haha, ok Chipaca :)
<zyga> xnox: yeah, I'm a bit of a fan of running my pet projects on weird stuff
<zyga> and I use the assorted set of cross compilers we provide
<zyga> I value that a lot
<zyga> I often mix those with qemu static
<zyga> and for some I have the hardware
<zyga> (still waiting for that low-cost power board that is low cost)
<mup> PR snapd#6044 closed: cmd/snap-confine: remove stale mount profile along stale namespace <â  Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6044>
<Chipaca> zyga: it's surprising to me that neither amd64 nor s390x have PTRACE_GETFPREGS
<Chipaca> zyga: running tests on a branch to fix this whole thing
<Chipaca> includes the cross-build spread test for arches supported by go itself
<Chipaca> bah for the intersection
<Chipaca> { arches supported by snapd } â© { arches supported by go } - { arches already covered by regular tests }
<Chipaca> { arm64 arm s390x }
<Chipaca> an alarmingly short list :-)
<Chipaca> still, should be enough to catch some bugs
<Chipaca> ooh ooh ppc64le also
 * Chipaca tries to add that
<kyrofa> zyga, you asked me to remind you about https://bugs.launchpad.net/snapd/+bug/1800004
<mup> Bug #1800004: snap try doesn't work: "cannot find installed snap" <snapd:New> <https://launchpad.net/bugs/1800004>
<zyga> thanks!
<kyrofa> It's kinda killing me if you can find some cycles
<zyga> kyrofa: I'll look today
<zyga> just updating a PR from mvo
<Chipaca> is ports.ubuntu.com the right place for -security on armhf?
<kyrofa> zyga, thank you. Please let me know if you need data from me
<Chipaca> zyga: https://github.com/snapcore/snapd/pull/6045
<mup> PR #6045: cmd/snap-seccomp: only look for PTRACE_GETFPX?REGS where available <Created by chipaca> <https://github.com/snapcore/snapd/pull/6045>
<mup> PR snapd#6045 opened: cmd/snap-seccomp: only look for PTRACE_GETFPX?REGS where available <Created by chipaca> <https://github.com/snapcore/snapd/pull/6045>
<mup> PR snapd#6010 closed: cmd/snap-discard-ns: add support for per-user mount namespaces <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6010>
<zyga> Chipaca: can we land https://github.com/snapcore/snapd/pull/6042#pullrequestreview-168525464
<mup> PR #6042: overlord/standby: fix a race between standby goroutine and stop <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6042>
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/6046 if you want to +1 something simple
<mup> PR #6046: cmd/snap-confine: remove SC_NS_FAIL_GRACEFULLY <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6046>
<mup> PR snapd#6046 opened: cmd/snap-confine: remove SC_NS_FAIL_GRACEFULLY <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6046>
<zyga> kyrofa: ok looking now
<mup> PR snapd#6047 opened: cmd: remove remnants of sc_should_populate_mount_ns <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6047>
<kyrofa> zyga, wonderful!
<zyga> kyrofa: I cannot reproduce it, tried on ...
<zyga> https://www.irccloud.com/pastebin/HtAv4AnW/
<zyga> can you share a snap you have that triggers this
<zyga> I tried ...
<zyga> go/src/github.com/snapcore/snapd/tests/lib/snaps/test-snapd-sh$ sudo snap try
<zyga> and subsequently ran some commands, all worked
<zyga> ahhh
<zyga> the snap is in /tmp/?
<zyga> perhaps that's why :)
 * zyga checks
<zyga> kyrofa: reproduced!
<kyrofa> zyga, ah, indeed, if I put it in my homedir it works
<kyrofa> Why would that be?
<kyrofa> I thought the private tmp didn't come into play until we were talking about the snap's namespace
<zyga> I'll reply in the bug
<kyrofa> Very good
<zyga> it's silly
<zyga> (very silly)
<zyga> replied, looking if I can fix it
<zyga> kyrofa: ok, I see why this happens
<zyga> it's silly, api reused around and perhaps in a bad way
<zyga> kyrofa: the tl;dr; answer is because the code for running a snap wants to know how big the snap is
<zyga> which is silly
<zyga> because that is a hot path
<zyga> and should not reuse random parts of snapd
<zyga> and hence it is a dangling symlink from the namespace POV
<zyga> it doesn't work
<zyga> which is double plus silly for symlinks
<zyga> it would be useless anyway, no size
 * cachio afk
<kyrofa> zyga, ah, interesting
<zyga> fixed locally
<zyga> just crafting a quick test
<kyrofa> Awesome!
<zyga> just running spread
<zyga> and I should EOD, it's almost 10pm
<zyga> kyrofa: https://github.com/snapcore/snapd/pull/6048
<mup> PR #6048: cmd/snap-exec: don't fail on some try mode snaps <Created by zyga> <https://github.com/snapcore/snapd/pull/6048>
<zyga> enjoy :)
<kyrofa> Thanks zyga!
<mup> PR snapd#6048 opened: cmd/snap-exec: don't fail on some try mode snaps <Created by zyga> <https://github.com/snapcore/snapd/pull/6048>
<Chipaca> zyga: wrt 6042, no :-)
<Chipaca> zyga: wrt 6046, looking
<Chipaca> I'm this >< close to losing packets today
 * Chipaca goes for tea
 * Chipaca wishes there were biscuits
<Chipaca> brb, reboot
<mup> PR snapd#6031 closed: snap/pack, cmd/snap: allow specifying the filename of 'snap pack' <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6031>
#snappy 2018-10-26
<mborzecki> morning
<mborzecki> starting later today, had to drive kids to school
<zyga> Hey mborzecki
<zyga> Friday comes so quickly lately
<mborzecki> zyga: hey
<pstolowski> morning
<mborzecki> pstolowski: hey hey
<mborzecki> btw. godbus and our unit tests are a bit messy
<mup> PR snapd#6046 closed: cmd/snap-confine: remove SC_NS_FAIL_GRACEFULLY <Simple ð> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6046>
<zyga> Thank
<mup> PR snapd#6045 closed: cmd/snap-seccomp: only look for PTRACE_GETFPX?REGS where available <Created by chipaca> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6045>
<mborzecki> need coffee
<mborzecki> Chipaca: what do you think about https://github.com/snapcore/snapd/pull/6042#discussion_r228421624 ?
<mup> PR #6042: overlord/standby: fix a race between standby goroutine and stop <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6042>
<Chipaca> mborzecki: not a lot
<Chipaca> mborzecki: coffee hasn't kicked in
<mborzecki> Chipaca: heh same here :)
<Chipaca> mborzecki: so
<Chipaca> mborzecki: that channel in the test still has the same race
<Chipaca> mborzecki: unless i'm missing something :-)
<Chipaca> let me apply it locally to test
<mborzecki> Chipaca: ok
<Chipaca> mborzecki: hm, the patch won't
<Chipaca> won't patch i mean
<mborzecki> Chipaca: doesn't apply?
<Chipaca> right
<mborzecki> sec, i'll give you a link then
<mborzecki> Chipaca: https://github.com/bboozzoo/snapd/commit/ed331c0c44b8fd776cca49ed1e8a34060eb682e9
<Chipaca> mborzecki: did you know you can add ".diff" to the end of that?
<mborzecki> omg, really? :)
<zyga> yep :)
<mborzecki> damn, it works
<zyga> anyone for a trivial remove PR https://github.com/snapcore/snapd/pull/6047 ?
<mup> PR #6047: cmd: remove remnants of sc_should_populate_mount_ns <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6047>
<zyga> sorry for starting late
<zyga> I feel so sleepy
<zyga> yesterday was good though, some useful things got done
<zyga> https://github.com/snapcore/snapd/pull/6019 needs a 2nd review
<mup> PR #6019: ifacestate: optimize disconnect hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6019>
<zyga> Chipaca: you commented on https://github.com/snapcore/snapd/pull/6016 before, a formal +1 or -1 would help to decide
<mup> PR #6016: [RFC] move various name validation helpers to snap/name package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6016>
<Chipaca> zyga: there was a chunk of discussion of the pr, i need to re-read it a bit
<zyga> thanks, sure
<zyga> disclaimer: I'm not trying to be pushy, just looking at PRs top to bottom
<mborzecki> so i'm reading dbus spec and find this: It could be ASCII or UTF-8, but could also be ISO Latin-1 or any other encoding.
<mborzecki> aka. surpsise string
<mup> PR snapd#5958 closed: NOT-REVIEW: tests: Add debug info main suite <Created by sergiocazzolato> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5958>
<mup> PR snapd#6008 closed: client, daemon, cmd/snap: indicate that services are socket/timer activated <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6008>
<zyga> mborzecki: aka what were they thinking?
<Chipaca> mborzecki: what could be?
<mborzecki> Chipaca: linux security label
<Chipaca> ah
<zyga> pstolowski: is https://github.com/snapcore/snapd/pull/5962/files read y for review?
<mup> PR #5962: ifacestate/hotplug: hotplug handlers <Complex> <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5962>
<Chipaca> mborzecki: about standby, I wonder about the need of the nested goroutine
<pstolowski> zyga: yes
<mborzecki> Chipaca: hm maybe, i wrote that before morning coffee
<Chipaca> mborzecki: it seems to me (but i could be wrong) that the second (outer) goroutine and the stopDone channel are spurious
<Chipaca> mborzecki: want to merge your changes, and i push more onto it? i've got a couple of tweaks (one of them, dropping that outer goroutine) but otherwise lgtm
<zyga> ogra_: can you please check https://github.com/snapcore/snapd/pull/5915
<mup> PR #5915: interfaces/network-setup-control: allow calling netplan generate/apply <Created by ogra1> <https://github.com/snapcore/snapd/pull/5915>
<Chipaca> i'm not convinced the channel dance is better than the wait, in that i'm not sure it's racy in the same way (just less likely because it's using the 200ms wait from the standby instead of an external 50ms wait) but if you are, i'm happy
<mborzecki> Chipaca: you want to merge the whole PR or should i just push that patch to the branch?
<Chipaca> mborzecki: to the -proposal branch?
<mborzecki> ok
<Chipaca> mborzecki: I don't mind
<Chipaca> mborzecki: I already pushed to yours:-)
<Chipaca> mborzecki: i do that, and then you merge once we agree?
<mborzecki> Chipaca: sgtm
<zyga> mborzecki: could you please check https://github.com/snapcore/snapd/pull/5789
<mup> PR #5789: snap: only show "next" refresh time if its after the hold time <Created by mvo5> <https://github.com/snapcore/snapd/pull/5789>
<zyga> Chipaca: can you look at https://github.com/snapcore/snapd/pull/5712 - it is green and has two reviews, I wonder if we should just merge it
<zyga> (perhaps re-triggering tests to see if it really passes now)
<mup> PR #5712: overlord: make InstallMany work like UpdateMany, issuing a single request to get candidates <Reviewed> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5712>
<Chipaca> zyga: no plz
<Chipaca> zyga: samuele hasn't merged it because it needs more tests
<zyga> k
<zyga> I'll add blocked
<Chipaca> zyga: add a comment about why, then :-)
<Chipaca> zyga: 1 sec let me give you a link
<zyga> done
<zyga> oh?
<zyga> just comment on the PR :)
<Chipaca> zyga: https://irclogs.ubuntu.com/2018/10/04/%23snappy.html#t19:52
<zyga> ta
<Chipaca> commented also
<mup> PR snapd#5885 closed: Adding DPDK interface for DPDK Snap <Decaying â¢> <Created by wililupy> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5885>
<zyga> with a few simple reviews we will be on one page
<mup> PR snapd#6047 closed: cmd: remove remnants of sc_should_populate_mount_ns <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6047>
<zyga> Chipaca: can we merge https://github.com/snapcore/snapd/pull/6025 or would you rather wait until Gustavo sees it?
<mup> PR #6025: Add go.mod files <Created by ryanjyoder> <https://github.com/snapcore/snapd/pull/6025>
 * zyga goes to review https://github.com/snapcore/snapd/pull/6034
<Chipaca> zyga: it feels like he should be at least aware of it, n'eh?
<mup> PR #6034: many: save media info when installing, show it when listing <Created by chipaca> <https://github.com/snapcore/snapd/pull/6034>
<zyga> yep, I'll add blocked
<Chipaca> zyga: and tag him please
<Chipaca> zyga: 6034, tag it for pedronis please
<Chipaca> zyga: thank you :-)
<zyga> k
<Chipaca> mborzecki: tell me what you think of that (re 6042)
<Chipaca> degville: morning sir
<degville> Chipaca: morning!
<Chipaca> degville: was just wanting to check if you'd had time to look at the changes to https://github.com/snapcore/snapd/pull/5955/files
<mup> PR #5955: cmd/snap, tests: snapshots for all <Snapshots ð¸ó > <Created by chipaca> <https://github.com/snapcore/snapd/pull/5955>
<degville> Chipaca: yes, sorry - looking now.
<Chipaca> degville: ok no problem
<Chipaca> degville: thank you
<mup> PR snapd#6049 opened: cmd/snap, userd, testutil: tweak DBus tests to use private session bus connection <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6049>
<mborzecki> Chipaca: zyga: hope this may fix userd/dbus issues we're seeing in tests
<mborzecki> ^^
<Chipaca> looking
<zyga> mmm
<zyga> mborzecki: I'm not familiar with private connections, can you explain that a little more?
<zyga> the code looks fine
<zyga> just not sure I understand the problem enough to give meaningful vote
<mborzecki> zyga: that's just a separate connection, i.e. with the changes the DBus test suite and userd use separate connections
<zyga> for test suite I sort of understand
<zyga> but for userd I don't
<zyga> separate from what/
<mborzecki> from nothing else atm
<zyga> aha
<Chipaca> mborzecki: the problem is that the dbus module shares the connection?
<mborzecki> Chipaca: yes
<Chipaca> ie two things doing dbus.SessionBus() get the same thing
<mborzecki> yup
<zyga> ahh
<Chipaca> and then one of them closes it and the other one says 'wuuut'
<zyga> that's wonky
<zyga> +1 then
<mborzecki> and if you do say go test -count=n it breaks too
<Chipaca> yeh :-)
<mborzecki> now i need to remind myself of what i was doing before i started fixing those tests :)
<zyga> can you review https://github.com/snapcore/snapd/pull/6048 before doing that :D
<mup> PR #6048: cmd/snap-exec: don't fail on some try mode snaps <Created by zyga> <https://github.com/snapcore/snapd/pull/6048>
<mborzecki> Chipaca: now that i see it, `opineReady <- struct{}{}` could be just `close(opineReady)`, but otherwise +1
<mborzecki> actually I'll push that
<mborzecki> Chipaca: pushed
<Chipaca> mborzecki: :-D
<mborzecki> so now zyga and pstolowski must approve :P
<zyga> which one?
<mborzecki> zyga: #6042
<mup> PR #6042: overlord/standby: fix a race between standby goroutine and stop <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6042>
<zyga> mborzecki: after the media PR from John
<zyga> brb, coffee
<mborzecki> Chipaca: don't remember, did we already have a pr for blocking installing confined snaps with --classic?
<mborzecki> or was it you working on this?
<Chipaca> mborzecki: #6039
<mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
<Chipaca> not super happy with that pr
<Chipaca> but i can only so much
<Chipaca> but, no error kind, meaning no user-facing error message
<mborzecki> heh, surising that someone actually tries to install snaps like this
<Chipaca> mborzecki: it's the same person that 'rm -rf /' on a core system to see if they could break it
<Chipaca> :-D
<Chipaca> (hint: they could)
<mborzecki> i think rm -rf / doesn't work anymore
<mborzecki> not without some extra --foo switch
<Chipaca> well, they had to add the --extra-foo
<popey> --no-preserve-root
<Chipaca> popey: hush you'll blow your cover
<popey> --i-know-what-im-doing --honest
<Chipaca> mborzecki: the fix to that was making things immutable, but testing it is a pain
<mborzecki> well, there should be a switch for dd to :P
<Chipaca> mborzecki: so we've got a chattr implementation to do it, but didn't get to _actuallly_ do it :-/
<Chipaca> mborzecki: linux is going soft in its old age
<Chipaca> these days you can't even mkfs /dev/sda without it saying "are you sure dude?"
<mborzecki> haha
<mborzecki> #6039 unit tests are passing locally, but not on travis
<mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
<mborzecki> hm maybe something new in master
<tomwardill> another question... If I install a snap from the store, then install a development version of it (using --dangerous), would the pre-refresh hook run?
<mborzecki> pstolowski: ^^
<pstolowski> tomwardill: yes
<tomwardill> pstolowski: lovely, thankyou
<zyga> Chipaca: I reviewed the media PR
<zyga> looking at https://github.com/snapcore/snapd/pull/6042/
<mup> PR #6042: overlord/standby: fix a race between standby goroutine and stop <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6042>
<pstolowski> looking at it as well
<Chipaca> zyga: https://play.golang.org/p/lRvxLmTlypq
<zyga> right, I get that but I think the wording is unintuitive
<Chipaca> ah ok
 * Chipaca goes to the gym
 * Chipaca really goes
<pstolowski> #6019 needs 2nd review
<pstolowski> and is green
<mup> PR #6019: ifacestate: optimize disconnect hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6019>
<mborzecki> shall we land #6042? or does anyone want another look?
<mup> PR #6042: overlord/standby: fix a race between standby goroutine and stop <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6042>
<mup> PR snapd#6049 closed: cmd/snap, userd, testutil: tweak DBus tests to use private session bus connection <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6049>
 * pstolowski lunch
<mborzecki> Chipaca: do you have any tests skipped in overlord/snapstate?
<cachio> mborzecki, hey, about the error on + systemctl restart snapd.socket
<cachio> Job for snapd.socket failed.
<mborzecki> cachio: hi, any progress there?
<cachio> mborzecki, well, it is fixed if I restart snapd.service too
<cachio> It is like a race with the dependencies
<cachio> I see in the logs that snapd.seeded.service fails to restart
<cachio> and then snapd.socket fails too
<cachio> it is happening mostly on debian
<cachio> is it a good solution to restart the snapd.service as well?
<mborzecki> hm i think snapd.seeded fails because the socket failed
<mborzecki> cachio: if you restart snapd.service then it won't be socket activated in the tests anymore
<cachio> I am restarting both  in fact
<mborzecki> snapd and snapd.socket?
<cachio> mborzecki, does it make sense?
<cachio> yes
<mborzecki> cachio: show abou systemctl stop snapd && systemctl restart snapd.socket ?
<mborzecki> maybe it's snapd proper and systemd racing to creat the socket?
<cachio> yes, systemctl restart snapd.{service,socket}
<mup> PR snapd#6050 opened: overlord/snapstate: run tests for classic snaps even on systems that don't support classic <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6050>
<cachio> mborzecki, this is the error https://paste.ubuntu.com/p/6mNsDRNRYy/
<cachio> that's why I restarted first the snapd service
<popey> Chipaca: joining us for snapd catchup?
 * popey assumes not
<Chipaca> popey: sorry :-(
<Chipaca> popey: was mvo there?
<Chipaca> mborzecki: tests skipped where?
<Chipaca> mborzecki: $ grep -r '\.Skip(' overlord/snapstate/  | sort | uniq -c
<Chipaca>      12 overlord/snapstate/snapstate_test.go:		c.Skip("no support for classic")
<mborzecki> Chipaca: right, but if you run go test overlord/snapstate then there are no tests skipepd on your system, right?
<Chipaca> mborzecki: a ver...?
<Chipaca> mborzecki: OK: 461 passed
<Chipaca> mborzecki: compare with go test -v -short cmd/snap: OK: 330 passed, 13 skipped
<Chipaca> ./cmd/snap i mean
<Chipaca> mborzecki: why?
<mborzecki> Chipaca: #6050 makes all of overlord/snapstate run on my system
<mup> PR #6050: overlord/snapstate: run tests for classic snaps even on systems that don't support classic <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6050>
<Chipaca> why wouldn't it?
<Chipaca> does your system not support classic?
<mborzecki> Chipaca: no, arch does not
<Chipaca> aw
<mborzecki> i can add symlink, but the tests shouldn't rely on that
<Chipaca> right
<Chipaca> given they should be setting global root to some tmpdir, they could create the symlink in there
<Chipaca> dang i need to make lunch for the troop
<Chipaca> brb
<mup> PR snapd#6048 closed: cmd/snap-exec: don't fail on some try mode snaps <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6048>
<popey> Chipaca: np, sadly not
<mborzecki> off to pick up the kids
<ogra> zyga, that netplan PR requires some extra time for re-doing my snap with changed profile etc ... that will still take a bit ... though jdstrand pointed to a thread where it all has been tested, we should probably just use that as input
<zyga> ogra: thanks, anytime you can do it is fine
<ogra> greyback, yo ! ... i'm trying to get a simple SDL2 pictureviewer to work natively on mir-kiosk, i belive everything is correct but i still end up with "SDL Failed to create window: failed to create a window surface" when trying to start the app
<ogra> greyback, the tutorials are rather sparse in that regsrd
<ogra> *regard
<greyback> ogra: for a reason :) Every toolkit can/wil be different
<greyback> ogra: if you test on your desktop, does it work? So run miral-kiosk, then set the wayland socket env var, and run that sdl app
<ogra> greyback, well, i dont want to use xwayland (which i surely could as fallback) ...
<ogra> greyback, hmm whats that var ? do i need to explicitly set it in a kiosk launcher ? (i see the wayland-0 socket)
<greyback> ogra: ofc. Pure SDL2 should work on top of Mir. I've not tried it in a while. What app?
<ogra> imv ... but with a wrapper etc
<greyback> ogra: that mir kiosk launcher script will take care of the env var for oyu
<ogra> which one ? i wrote my own :)
<greyback> ogra: "miral-app"
<ogra> well, how do i get that into my snap ?
<ogra> mir-kiosk surely doesnt ship it
<greyback> ogra: nope it doesn't. I'm not worrying about snaps just yet, I want to check that sdl app runs on top of Mir at all
<ogra> well, where is the source for miral-app so i can pull it into my snap ?
<popey> greyback: what sdl2 apps have you tried?
<ogra> https://tutorials.ubuntu.com/tutorial/wayland-kiosk#3 is really sparse ...
<ogra> err https://tutorials.ubuntu.com/tutorial/wayland-kiosk#0
<greyback> ogra: https://github.com/MirServer/mir/blob/master/examples/miral-shell/miral-run.sh
<greyback> ogra: yes you're right, it is sparse
<popey> Chipaca: i was going to raise this at the meeting btw. https://forum.snapcraft.io/t/ubuntu-core-doesnt-batch-reboots/8174/1
<popey> ogra: ^ I mentioned before that core reboots multiple times, this shows it
<greyback> popey: tbh I didn't. I snapped gtk2/3 and qt4/5. I know sdl2 works on mir, I never tried snapping one
<popey> be nice to have some hello world level tutorials of those
<popey> which aren't massively wordy tomes
<pstolowski> Chipaca, mborzecki, zyga, cachio I'll probably miss the standup, need to pick up my daughter returning from school trip
<popey> just "here's the yaml, here's the snap, done"
<zyga> pstolowski: ack
<greyback> popey: agreed
<zyga> popey: here's the jam, here's the snack, done
<zyga> ;-)
<popey> cprov: is there any more comprehensive docs on using surl than the readme?
<zyga> surl?
<diddledan> curl?
 * diddledan hurls the surl with a curl making it whirl.
<popey> https://github.com/cprov/surl / https://snapcraft.io/surl
<diddledan> yeah, that readme needs moar details
<ogra> popey, yeah, saw the post
<diddledan> e.g. what is the `-a` parameter for? does it accept anything other than `stg-reg`? what does `stg-reg` even mean?
<ogra> greyback, ok, now after setting MIR_SOCKET and WAYLAND_DISPLAY (i made sure i can see and access the files they point to), i get "SDL Failed to Init: wayland not available"
<popey> diddledan: oi! I was first in the queue! :D
<diddledan> popey: 2x2?
<popey> :)
 * diddledan holds popey's hand and stands along side to go in together like good little boys
<zyga> oh, surl is nice :)
<zyga> Chipaca: did you see that a?
<mborzecki> re
<mborzecki> surl? small curl?
<Chipaca> zyga: which a?
<ogra> the one before b ?
<zyga> sorry, not a ;) surl
<Chipaca> zyga: i have not. Have you seen icdiff?
<zyga> no I have not
<Chipaca> now we're even
 * Chipaca heads to the standup
<Chipaca> or is that stands for the standup
<dot-tobias> greyback, ogra: Re: chromium-mir-kiosk rotation issue â here are my findings https://forum.snapcraft.io/t/cross-post-chromium-mir-kiosk-in-portrait-mode-rotated-mir-kiosk-layout/8175
<ogra> dot-tobias, did you consider simply not using i3 ?
<greyback> dot-tobias: thanks for that excellent post.
<dot-tobias> ogra: I do, but I am completely out of my depth here when it comes to display servers and the likes. And I need to get a portrait mode-kiosk running ASAP because the beta testers are already waiting ð
<greyback> dot-tobias: I'll see what I can figure out now then
<greyback> dot-tobias: you're making a product with it?
<ogra> dot-tobias, well, i have the mirkiosk snap in the store that i'm planning to do an appliance with soon ... but i wot start on the integration work before next week ... then i'll hit (and hopefully solve) the same issues
<ogra> currently i'm sadly struggling with unexpected SDL2 issues for a native wayland slideshow appliance (picture-frame appliance)
<ogra> err
<ogra> s/mirkiosk/magicmirror/
<ogra> silly typo ... too much mir in my head now
<dot-tobias> ogra: ð Excited to see how you'll tackle these issues (with way more proficiency in this stack)
<ogra> i'll probably simply hack around the issues i hit ... like using matchbox or openbox if they can behave more dynamic than i3 ... or hacking xrandr calls into the launcher or some such :)
<tomwardill> ogra: I am excited to see magicmirror as a snap, I've got a Pi display on it's way to me atm
<ogra> i also still have to solve some issues with magicmirror itself ... getting the modules in a writable area while keeping the runtime code readonly seems extremely hard without patching upstream
<ogra> i initially tried to simply ship all available modules by default ... but somehow a 6.2GB source tree resulted from that (and a 700MB snap) ... that feels a bit like overkill :)
<Chipaca> degville: writing is hard. Maybe I'll just replace the help text with emoji.
<Chipaca> degville: ð¸ð
<degville> Chipaca: yeah.
<degville> +1
<tomwardill> ogra: I'd probably try and get a config variable or something upstreamed at that point
<tomwardill> but I've no idea how feasible that is
<ogra> yeah
<ogra> i havent talked to upstream yet ... the prob is that the code uses relative paths inside ... like ... everywhere
<ogra> foo=../../bar ... and such
<ogra> as soon as you operate with a symlink into $SNAP_DATA these relative paths break
<Chipaca> ogra: keeping in mind i have no context, layouts might help
<ogra> sigh ... so mir and SDL2 seems like a no-go ... and i dont really want the 120MB overhead adding the desktop launcher and xwayland stuff :((((
<ogra> Chipaca, they do, but are they not holding my snap upload anymore at the review steap ?
<ogra> *step
<dot-tobias> ogra: My use-case is a smart mirror as well ð And layouts (plus massive help from zyga) helped tremendously to cope with Rails and its assumption that everything lives inside its root directory.
<ogra> Chipaca, developing on core requires a painful amount of patience since all features i need to use make my packages go stuck until jdstrand finds the time to review ...
<ogra> so i always try to find a way around experimental features if possible
<ogra> it typically means my turnaround time for finishing a demo extends by about a week
<mup> PR snapd#6051 opened: cmd/snap-update-ns: parse the -u <uid> command line option <Created by zyga> <https://github.com/snapcore/snapd/pull/6051>
<ogra> greyback, are we sure the xenial SDL2 can actually work with mir-kiosk ?
<zyga> Chipaca: can we land https://github.com/snapcore/snapd/pull/6042
<mup> PR #6042: overlord/standby: fix a race between standby goroutine and stop <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6042>
<ogra> (has anyone tested that ?)
<zyga> https://github.com/snapcore/snapd/pull/6019 needs a 2nd review
<mup> PR #6019: ifacestate: optimize disconnect hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6019>
<mup> PR snapd#6042 closed: overlord/standby: fix a race between standby goroutine and stop <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6042>
<zyga> koza_: ping
<zyga> koza_: can you please fix https://github.com/snapcore/snapd/pull/5897#issuecomment-433412089 - merge master as well if you can please
<ogra> zyga, i think he is travelling
<mup> PR #5897: interfaces/builtin: add device-buttons interface for accessing events <Created by bergotorino> <https://github.com/snapcore/snapd/pull/5897>
<dot-tobias> zyga: Is there a timeline when layouts will no longer prevent automated reviews, as they're now out of beta AFAIR?
<zyga> cachio: there's one question from chipaca on https://github.com/snapcore/snapd/pull/5714#issuecomment-430589737
<mup> PR #5714: tests: new test for cifs-mount interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5714>
<zyga> dot-tobias: I think that is a good question
<zyga> dot-tobias: given that some people are sprinting today I think we will know next week (Tuesday is a good day to ask)
<zyga> dot-tobias: I think they will be out of review mode once 2.36 ships
<zyga> or was that 2.35 (/me never knows)
<dot-tobias> zyga: Ok, great! Thanks for the info
<zyga> jdstrand: ^ will layouts be blocked by store review after 2.36 ships?
<zyga> Chipaca, degville: is https://github.com/snapcore/snapd/pull/5955 good for landing?
<mup> PR #5955: cmd/snap, tests: snapshots for all <Snapshots ð¸ó > <Created by chipaca> <https://github.com/snapcore/snapd/pull/5955>
<Chipaca> zyga: we're still hashing out the last tweaks to docs
<zyga> +1
<zyga> merge when ready
<Chipaca> there's one paragraph that's stumped us a bit
<zyga> it looks very nice
 * zyga reads the new things
<Chipaca> i've got a bunch of changes
<Chipaca> and waiting to see if we can figure out the last one
<Chipaca> otherwise i'll just push what i've got and land when green
<zyga> https://github.com/snapcore/snapd/pull/5955#discussion_r228533627 for one crazy idea
<mup> PR #5955: cmd/snap, tests: snapshots for all <Snapshots ð¸ó > <Created by chipaca> <https://github.com/snapcore/snapd/pull/5955>
<zyga> mborzecki: can you do a quick pass over https://github.com/snapcore/snapd/pull/6051
<mup> PR #6051: cmd/snap-update-ns: parse the -u <uid> command line option <Created by zyga> <https://github.com/snapcore/snapd/pull/6051>
<cachio> zyga, ahh, let me see that, I already tested mount.cifs and it was failing but I don't remember the error
<zyga> cachio: thanks! :)
<zyga> mborzecki: and you could do a 2nd re-review of https://github.com/snapcore/snapd/pull/5789
<mup> PR #5789: snap: only show "next" refresh time if its after the hold time <Created by mvo5> <https://github.com/snapcore/snapd/pull/5789>
<zyga> with a few more reviews we could be at < 25 in a few minutes
<zyga> mborzecki: and perhaps something actionable on https://github.com/snapcore/snapd/pull/5792 - not sure
<mup> PR #5792: [RFC] {config,snap}state: add new refresh.metered=force option and flip default <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5792>
 * zyga stops harassing people for reviews
<mborzecki> on #6039, refreshing from --classic to strict (as in the next revision is strict) should not be blocked i presume
<mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
<mborzecki> (i'm down to one failing unit test which does exactly this scenario)
<zyga> mborzecki: yes, I agree
<zyga> yeah :)
<zyga> I had a stab at it last night and gave up
 * zyga -> dog 
<cprov> popey: no, we started mentioning it in store docs (https://dashboard.snapcraft.io/docs/v2/en/api-store-info.html), but it needs more love
<diddledan> I know the feeling. I need more love, too ;-p
 * cachio afk
<mborzecki> yup all unit tests passing now
<mborzecki> Chipaca: pstolowski: could you do a 2nd review of this change https://github.com/snapcore/snapd/pull/6050 ?
<mup> PR #6050: overlord/snapstate: run tests for classic snaps even on systems that don't support classic <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6050>
<Chipaca> mborzecki: i'm -0 on it as proposed so i'd rather not :-)
<mborzecki> Chipaca: you'd rather see this done in test setup?
<Chipaca> wait
<Chipaca> mborzecki: sorry wrong pr
<Chipaca> ETOOMANYBALLSINJUGGLE
<Chipaca> let me wade out of these failing tests and i can review if pstolowski didn't beat me to it
<mborzecki> https://www.youtube.com/watch?v=1D5Sa2Yq-2g
<pstolowski> mborzecki: looking
<Chipaca> mborzecki: more like https://youtu.be/3vyGMrQ0MBo?t=34
<mborzecki> Chipaca: hmm pstolowski just +1 ed it, want to me hold off merging it?
<Chipaca> mborzecki: no no
<Chipaca> mborzecki: the one i'm not too happy about is the --classic error one
<Chipaca> but -0, ie non-blocking
<mup> PR snapd#6050 closed: overlord/snapstate: run tests for classic snaps even on systems that don't support classic <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6050>
<greyback> ogra: yeah this doesn't work at all. Xenial sdl2 uses glx directly, even when wayland backend selected. Works ok on bionic. This needs fixing
<ogra> aha
<ogra> ... another estimated 10min job that turned into a day of hackery :(
<ogra> i'm trying to resort to xwayland but that doesnt work either now :(
<ogra> greyback, "You need to connect this snap to one which implements the wayland-socket-dir plug." ... wasnt that dropped long ago ?
<greyback> ogra: it was, where you find that?
<ogra> in my snap :P
<ogra> i just added after: [ xwayland-kiosk-helper, desktop-gtk2 ] ... the respective env vards and launchers ...
<greyback> ogra: clean and refetch?
<greyback> xwayland-kiosk-helper anyway
<ogra> i clean and rebuild all the time
<zyga> small planned power outage
<zyga> I'll be back online in ~30 minutes
<greyback> ogra: I've no idea how you get that then. This is the xwayland-kiosk-helper script: https://github.com/MirServer/xwayland-kiosk-helper/blob/master/xwayland-preload/xwayland-kiosk-launch
<ogra> greyback, definitely not what lands in the prime dir here
<ogra> greyback, http://paste.ubuntu.com/p/Yy4hdrrwGg/
<greyback> right, that's old
<ogra> yeah
<zyga> and now on battery power while the power line is adjusted around here
<ogra> and i'm 100% sure i have the new one in the other builds i did two weeks ago ... on the same host
<ogra> greyback, are you sure the parts entry on the wiki points to master ?
<greyback> ogra: as if the old remote part url was cached
<greyback> ogra: yep, just double-checked
<ogra> weird
<ogra> let me run snapcraft update
<ogra> the thing is that i built other snaps before that had the right part
<ogra> on the very same machine
<greyback> bizarre
<mborzecki> Chipaca: pushed to mvo's PR, probably even more reason for -1 now :)
<ogra> icviewer[4019]: #################################################################################
<ogra> icviewer[4019]: NOTICE: the 'wayland-socket-dir' interface has been removed!
<ogra> icviewer[4019]: Remove reference to it and WAYLAND_SOCKET_DIR from your snapcraft.yaml.
<ogra> icviewer[4019]: Consult the instructions in
<ogra> icviewer[4019]: https://github.com/MirServer/xwayland-kiosk-helper/blob/master/snapcraft.yaml
<ogra> icviewer[4019]: #################################################################################
<ogra> nope ...
<ogra> didnt help
<ogra> oh
<ogra> it did :P
<diddledan> /kick ogra FLOOOOOOOOD :-p
<ogra> but it doesnt start anyway :/
<ogra> what a mess ...
<ogra> greyback, huh ?!? ... why the heck do you exit 5 after this message instead of just unsetting WAYLAND_SOCKET_DIR quietly
<greyback> ogra: to force people to migrate. I didn't think it would impact many people
<greyback> sorry, you're in the awkward transition period
<ogra> yeah, there are probably only 5 people like me in the world atm :P
 * ogra re-builds the snap from scratch again
<ogra> ok, it starts now ...
 * ogra finally starts his actual work 
<zyga> ...and we have one page of reviews now :)
<mup> PR snapd#5789 closed: snap: only show "next" refresh time if its after the hold time <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5789>
<zyga> https://github.com/snapcore/snapd/pull/6019 is simple and needs a 2nd review
<mup> PR #6019: ifacestate: optimize disconnect hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6019>
<zyga> cachio: there's a conflict on v
<zyga> https://github.com/snapcore/snapd/pull/5887
<mup> PR #5887: tests: moving core-snap-refresh-on-core test from main to nested suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5887>
<zyga> cachio: and please let me know once you have details about 2.36 regression
<zyga> cachio: small tweak required to fix test in https://github.com/snapcore/snapd/pull/5714
 * zyga is eager to end the week with ~20 PRs
<mup> PR #5714: tests: new test for cifs-mount interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5714>
<zyga> Chipaca, mborzecki, pstolowski: can we try to get as many reviews as we can
<zyga> the week is almost over
 * Chipaca hugs zyga 
<pstolowski> yep! 6019 needs just 1 more review ;) and is easy
<zyga> reviews help move everyone
<Chipaca> zyga: i'm afraid the epoch thing takes priority today, but i should be out of the woods in an hour or so
<zyga> Chipaca: I was about to say that I was planning to be out here and in the woods in an hour but it's dark and cold so ...
<mup> PR snapcraft#2386 opened: project_loader: raise error if part in after is undefined <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2386>
<Chipaca> yea i was going to go for a run but here i am
<zyga> pstolowski: thank you for the review
<pstolowski> yw
<cachio> zyga, sure, working on it #5714
<mup> PR #5714: tests: new test for cifs-mount interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5714>
<zyga> thank you :)
<zyga> pstolowski: updated now
<pstolowski> looking
<zyga> mborzecki: errors on https://github.com/snapcore/snapd/pull/6039
<mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
<mborzecki> zyga: heh, right the snap was already installed earlier in the test
 * Chipaca went for tea and accidentally muffins /o\
<Chipaca> in my defence, the tests are taking a long time :-D
<Chipaca> zyga: any reviews of note?
<zyga> Chipaca: go for low hanging fruit :)
<zyga> or for stuff that needs the last prod to move
<zyga> we are on one page now :)
 * Chipaca goes for watermelons
<zyga> mborzecki: iterating on unsigned uid
<Chipaca> zyga: unsigned uid?
<zyga> parsing :)
<Chipaca> as opposed to "lol i don't care that uids are unsigned" go?
<zyga> Chipaca: I should have called it
<zyga> int cookie
<zyga> then nobody would object ;)
<Chipaca> but then you'd want cookies
<zyga> void *data
 * zyga runs
<mborzecki> fwiw go uses int for uids so there's that
<zyga> Chipaca: I think https://github.com/snapcore/snapd/pull/6041 is your kind of review
<mup> PR #6041: client, cmd/daemon: allow disabling keepalive, improve degraded mode unit tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6041>
<zyga> mborzecki: you saw https://github.com/snapcore/snapd/pull/6039 - right?
<mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
<zyga> https://github.com/snapcore/snapd/pull/6019 is low hanging landing
<mup> PR #6019: ifacestate: optimize disconnect hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6019>
<mborzecki> zyga: yes, i'm waiting for spread run to finish
<zyga> https://github.com/snapcore/snapd/pull/6016 could land if someone says yes
<mup> PR #6016: [RFC] move various name validation helpers to snap/name package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6016>
<zyga> as could https://github.com/snapcore/snapd/pull/5982
<mup> PR #5982: interfaces/many: conditionally use 'unsafe' with docker-support change_profile rules <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5982>
<mborzecki> zyga: 6016 needs more discussion probably
<zyga> mborzecki: yeah but it could also land ;)
<Chipaca> and if instead of reviewing â¦ i push a new one?
<zyga> Chipaca: gaah,
<zyga> we would have pagination
<zyga> please don't break GitHub ;)
<Chipaca> oops
<zyga> https://github.com/snapcore/snapd/pull/5887 has 0 reviews
<mup> PR #5887: tests: moving core-snap-refresh-on-core test from main to nested suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5887>
<mup> PR snapd#6052 opened: snap, store, overlod/snapstate: always send epochs <Created by chipaca> <https://github.com/snapcore/snapd/pull/6052>
<zyga> but it also has a conflict so
<zyga> Chipaca: maan, now I have to review it :)
<Chipaca> zyga: yes, yes you do
<mup> PR snapd#6041 closed: client, cmd/daemon: allow disabling keepalive, improve degraded mode unit tests <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6041>
<Chipaca> we should add a "notice me sempai" tag for gustavo
<Chipaca> senpai*
<Chipaca> travis has this "can fail" thing
<Chipaca> where you can have tests that can fail and it doesn't block a merge
<Chipaca> i'm not saying we should use it for distros that can't keep their mirrored ducks in a line, but *cough* opensuse *cough*
<zyga> Chipaca: done
<zyga> back to C
<zyga> mborzecki: ^ if you want to do more last minute before EOW PRs then the one from Chipaca about epochs would be great
<zyga> mborzecki: updated the parser based on your feedback
<mborzecki> zyga: i think the code still allows 0x123 and 0123, if we want to support it then i guess it's ok
<mborzecki> pushed a last patch to #6039, calling it eow, need to help kids with homework
<zyga> it doesn't - I will push one more test
<mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
<zyga> mborzecki: thank you! enjoy the weekend and see you next week
<mborzecki> zyga: thanks, you too
<zyga> Chipaca: ok, anything I can review?
<Chipaca> zyga: stacked on the snapshots one, so nah
<zyga> mmm
<zyga> I shall EOD then
<Chipaca> zyga: for next week, i'd like to figure out how to print e.g. "El Capitan" in the "darwin" line of 'snap version'
<Chipaca> and then â¦ then I'd make it print "El CapitÃ¡n"
<Chipaca> otoh it seems kernel version and codename go in lockstep
<Chipaca> dunno
<Chipaca> popey: could you add a "type" to that list?
<Chipaca> er
 * Chipaca checks the date
<Chipaca> yeah, friday
<popey> que?
<zyga> Chipaca: hmm,
<zyga> I can help with that :)
<zyga> Chipaca: you basically query the api and get a version number
<zyga> and map that to strings
<mup> PR snapcraft#2386 closed: project_loader: raise error if part in after is undefined <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2386>
<zyga> https://www.irccloud.com/pastebin/EmmPBcjL/
<zyga> Chipaca: ^
<Chipaca> ok, listen
<Chipaca> https://www.youtube.com/watch?v=hdWyYn0E4Ys
<mup> PR snapd#5955 closed: cmd/snap, tests: snapshots for all <Snapshots ð¸ó > <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5955>
 * zyga hugs Chipaca 
<zyga> really nice work :)
<zyga> Chipaca: I think this is the music that goes well with pull requests
<zyga> https://www.youtube.com/watch?v=Pmd3UiNfNkA
<zyga> cachio: the cifs test is not passing
<zyga> https://github.com/snapcore/snapd/pull/5714#issuecomment-433524035
<mup> PR #5714: tests: new test for cifs-mount interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5714>
<cachio> I am waiting for the new cifs snap to be approved
<zyga> aha
<zyga> can you add a comment to the PR please
<zyga> perhaps jdstrand can approve the snap
<zyga> jdstrand: ^
<cachio> zyga, the snaps are being uploaded
<cachio> to the store
<cachio> I'll run the tests again in few minutes
<zyga> super, thank you!
<cachio>   
<mup> PR snapd#6051 closed: cmd/snap-update-ns: parse the -u <uid> command line option <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6051>
<mup> PR snapd#6019 closed: ifacestate: optimize disconnect hooks <Created by stolowski> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6019>
 * cachio afk
<mup> PR snapd#6053 opened: cmd/snap, daemon, strutil: use CommaSeparatedList to split a CSL <Created by chipaca> <https://github.com/snapcore/snapd/pull/6053>
<zyga> Chipaca: +1
<zyga> error: invalid argument for flag `--id' (expected main.snapshotID): strconv.ParseUint: parsing "": invalid syntax
<zyga> Chipaca: is that a real bug or is merge with master needed?
<zyga> https://api.travis-ci.org/v3/job/442553822/log.txt
<zyga> https://www.irccloud.com/pastebin/6dCobmCw/
<Chipaca> zyga: where's that?
<zyga> https://github.com/snapcore/snapd/pull/5916
<Chipaca> - Save data of snap "test-snapd-tools" in snapshot set #1 (user: unknown userid 4294967294)
<mup> PR #5916: data: run snapd.autoimport.service only after seeding <Created by mvo5> <https://github.com/snapcore/snapd/pull/5916>
<zyga> yeah, I noticed
<zyga> this is amazon linux 2
<Chipaca> Â¯\_(ã)_/Â¯
<zyga> my thoughts exactly
<zyga> what is the user there normally?
<Chipaca> I'm not going to dig, tonight
<zyga> is it "test"
<Chipaca> 12345
<zyga> mmm
<zyga> ok
<zyga> yeah, sure it's super late
<zyga> just weird
<zyga> I'll restart the whole suite, that merges master locally
<Chipaca> wait
<Chipaca> no
<zyga> ok
<zyga> I'll wait
<Chipaca> 4294967294
<Chipaca> is "no change"
<Chipaca> it's 0xfffffffe
<zyga> waat!
<zyga> -1
<Chipaca> hmmm
<Chipaca> is it -1, or is it -2
<zyga> >>> ctypes.c_uint(-2)
<zyga> c_uint(4294967294L)
<zyga> -2
<Chipaca> 1. I can't even
<Chipaca> 2. not tonight
<zyga> haha
<zyga> yes, that's a good plan
<zyga> let's fight this next week :)
<zyga> I'll keep the log in case someone restarts
#snappy 2018-10-27
<tristan__> hi. I got stated with snapcraft from apt and just saw that snapcraft 3.0 was out on snap and could build with an 18.04 base. but did the commands change? it no longer has cleanbuild and doesn't accept lxd for SNAPCRAFT_BUILD_ENVIRONMENT
<tristan__> maybe managed-host is supposed to be the new cleanbuild?
<tristan__> I try running that and it crsahes, the stacktrace say it can't find ~/project...
<tristan__> oh, multipass seems to do what I want. it is launching a VM
#snappy 2018-10-28
<chesty> I've got another weird one I can't work out with snapping x2goclient, x2goclient uses libssh and I get the popup box saying the server is unknown and do I trust it, I click yes, it tries to add it to .ssh/known_hosts but it's not using $HOME, it's trying to open /var/lib/gdm3/.ssh/known_hosts I can't workout where it's getting /var/lib/gdm3 from
<chesty> I had a look at x2goclient source, and it's using QDir::homePath() which says "Under non-Windows operating systems the HOME environment variable is used if it exists, otherwise the path returned by the rootPath()."
<chesty> HOME=/home/michaelc/snap/x2goclient/x4
<mup> PR snapcraft#2385 closed: cli: consolidate re-execution <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2385>
<chesty> I worked it out, haven't fixed it yet. My  user isn't in /etc/passwd it's in ldap and atm `id myuser` isn't found so I guess I need some ldap nss packages
<Chipaca> chesty: I wasn't here for the first part of that, what's going on?
<chesty> I'm creating a snap with x2goclient, it uses libssh, it's trying to open known_hosts in /var/lib/gdm3/.ssh and I think it's because x2goclient can't find my user hence my users $HOME
<chesty> my user is in freeipa not /etc/passwd
<Chipaca> chesty: o...k
<Chipaca> chesty: that's going to be interesting to get working
<chesty> I'm starting x2goclient with a wrapper which logs `id myuser`, it's saying not found atm.
<chesty> bummer. snaps only work with users in /etc/passwd?
<Chipaca> depends on the snap, some things need to look in /etc/group
<Chipaca> let me check for etc/passwd
<chesty> i mean can snaps work with users and groups in freeipa?
<Chipaca> chesty: for things that need to look up users and groups, no
<Chipaca> chesty: but not everything does. In particular that "var/lib/gdm3" thing is your app's doing :-)
<chesty> I checked out x2goclient's code, it's calling QDir::homePath() to find the users home dir, it works outside of the snap environment
<Chipaca> chesty: the documentation of that function says it uses $HOME
<Chipaca> I don't know if that's true :-) but that's what it says
<Chipaca> if that's true, then you can see what it should be returning
<chesty> I did see that, but HOME is set to the expected value
<chesty>  /var/lib/gdm3 is the home dir of the user gdm3
<chesty> no idea how it's getting that
<Chipaca> and the QDir::homePath implementation I see does the right thing
<Chipaca> https://code.woboq.org/qt5/qtbase/src/corelib/io/qfilesystemengine_unix.cpp.html#_ZN17QFileSystemEngine8homePathEv
<Chipaca> hmmm
<Chipaca> chesty: is gdm3 the last user in /etc/passwd?
<Chipaca> if so, do we have a bug
<Chipaca> i don't know where though :-)
<chesty> it is the last user
<Chipaca> but, that's one thought, that something is just using the last entry
<Chipaca> chesty: probably best to ask tomorrow when more of the team is around though
<chesty> sweet. thanks Chipaca, roungly how many hours away is tomorrow for the team?
<chesty> I'm in +10, it's already tomorrow
<Chipaca> chesty: 13 hours away
<chesty> cheers.
<Chipaca> chesty: at least for those that might have some insight into this
<Chipaca> chesty: FWIW if it only works via NSS, it's not going to work
<Chipaca> fully I mean
<Chipaca> NSS is binary-only, and binary-incompatible between currently-supported releases of libc
<Chipaca> but something picking up the last entry is clearly a bug :)
<chesty> OK, I'll check out strace and see what I see.
<Chipaca> (but otoh some things don't take kindly to errors so maybe there's no better way, i don't really know)
<Chipaca> chesty: what distro is this on btw?
<chesty> 18.04. there's a bug in x2goclient which I've reported so I thought it might be a nice project to learn about snaps and work around the bug
<Chipaca> having said that about nss, i wonder if sssd offers a way out
<Chipaca> anyway, i need to run
<Chipaca> ttfn
<chesty> cheers
#snappy 2019-10-21
<mborzecki> morning
<mvo> hey mborzecki
<mup> PR snapd#7443 closed: timeutil: fix schedules with ambiguous nth weekday spans <Bug> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>
<zyga> hey
<zyga> mvo: this is the bug fix from Friday https://github.com/snapcore/snapd/pull/7632
<mup> PR #7632: interfaces/apparmor: avoid excessive repetition of snap-update-ns mount rules <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>
<zyga> mvo: at least the first patch can be reviewed and landed in separation
<zyga> mvo: namely https://github.com/snapcore/snapd/pull/7632/commits/02ba1f863776d4d4c27bcfc3edccfebe30a11ef2
<zyga> I'll iterate on https://github.com/snapcore/snapd/pull/7547
<mvo> zyga: cool, thank you. I have a look
<mvo> zyga: just making a cup of tea :)
<mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
<zyga> uh
<zyga> my dog needs help
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/7613#discussion_r336850453 does sfdisk poke kernel to rescan the partition table too?
<mup> PR #7613: snap-recovery: add minimal binary so that we can use spread on it <Created by mvo5> <https://github.com/snapcore/snapd/pull/7613>
<mborzecki> hm actually wonder what blockdev does, whether it creates the nodes itself or what
<mborzecki> mvo:  looked a bit at blockdev, looks like it's a single ioctl actually, even if sfdisk doesn't call it, and we don't want a dependency on blockdev, we can issue it ourselves from snap-recovery
<mvo> mborzecki: sfdisk does, I think the code comment referes to the line in the code even
<mborzecki> mvo: ah, good then
<mvo> mborzecki: yeah, its a single ioctl, let me quickly check
<mvo> mborzecki: disk-utils/sfdisk.c:write_changes()
<mborzecki> mvo: thanks, see that now
<mborzecki> mvo: we should be good then
<mvo> mborzecki: great, that runs fdisk_reread_partition_table which runs                 i = ioctl(cxt->dev_fd, BLKRRPART);
<mvo>  which is AIUI all that is needed
<mvo> mborzecki: its also smart enough to not call it on a non-blockdev (unlike blockdev :)
<mvo> mborzecki: fwiw,  Iremoved the blockdev call because it apparently raced with udev, I got an error that BLKRRPART failed because the deivce was already in use which seems to indicate that blockdev and udev tried to to the same thing (this happend in the spread test)
<mborzecki> mvo: duh, /o\
<mvo> mborzecki: no, its fine, it only happens with blockdev which we don't really need, was just a bit annoying to find it but spread tests ftw!
<zyga> re
<zyga> dog back home, got steroids, need to observe
<zyga> sorry, need to focus on coding again
<pstolowski> morning
<mborzecki> pstolowski: hey
<mup> PR snapd#7509 closed: gadget, snap/pack: perform extended validation of gadget metadata and contents <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7509>
<mvo> zyga: 7613 is rady for a second review, should address all the points you raied in the other review
<zyga> mvo: ack
<zyga> mvo: note: it has conflicts
<mvo> zyga: aha, I did not notice, fixing now
<zyga> Lost power
<zyga> Checking
<zyga> External fault
<zyga> Checking outdoors
<zyga> on phone thether
<zyga> well, that thing
<zyga> anyway
<zyga> last thing I heard before silence was neighbors drilling
<zyga> pro tip: one way to check if you lost power or if street lost power: check how many APs are around
<zyga> if there are none it's not just you
<pstolowski> zyga: smart
<zyga> it's not that I have a noisy environment
<zyga> but when power goes out
<zyga> everything is so silent it is almost uncomfortable
<mborzecki> zyga: zombie apocalypse?
<zyga> mborzecki: that's when hordes of mindless users look for open wifi?
<mborzecki> zyga: yeah, zombie walk with your phone looking for wifi :P
<pstolowski> pedronis: hey, will you have a moment to talk about system-key today?
<zyga> mborzecki: still no power
<pedronis> pstolowski: I have a meeting now, seems more likely that we should chat tomorrow morning
<pstolowski> zyga: btw, if you are with ENEA, then on https://www.wylaczenia-eneaoperator.pl you can subscribe to be notified about outages in your region
<pstolowski> pedronis: okay, sure (btw i'm off this afternoon)
<pedronis> pstolowski: yes, saw that, that's why I said tomorrow
<pstolowski> pedronis: good, ty
<mborzecki> mvo: can you take a look at #7630?
<mup> PR #7630: overlord/devicestate: check snap handler for gadget remodel compatibility <Remodel :train:> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7630>
<mvo> mborzecki: aha, yes, sorry, I have one more meeting and then we are good
<mvo> mborzecki: now!
<mborzecki> hah
<zyga> mvo: btw a question came up in a pull request, 14.04 support
<pstolowski> zyga: a few comments to  #7632
<zyga> mvo: is 14.04 maintained?
<mup> PR #7632: interfaces/apparmor: avoid excessive repetition of snap-update-ns mount rules <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>
<jamesh> Chipaca: in your comment on https://github.com/snapcore/snapd/pull/7589, was there any particular reason you thought individual subcommands should also be hidden?
<mup> PR #7589: cmd/snap: add ability to register "snap internal" commands <â Blocked> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7589>
<Chipaca> jamesh: because otherwise they're not actually hidden?
<jamesh> Chipaca: they won't show up in the "snap --help" output.
<jamesh> what is the benefit of hiding commands in "snap debug --help" or "snap internal --help" output?
<Chipaca> jamesh: we hide commands that aren't meant for human consumption
<Chipaca> jamesh: and all 'internal' commands are like this, aren't they?
<Chipaca> jamesh: all internal commands right now are hidden, in particular
<Chipaca> jamesh: why would you make 'internal' commands _not_ hidden?
<zyga> pstolowski: thank you, replied to each one
<jamesh> Chipaca: I understand preventing them from being discovered from "snap --help".  But if you're specifically asking for information about debug or internal commands, why wouldn't you show them?
<zyga> pstolowski: please let me know how you feel about Index
<zyga> er
<zyga> about Items
<zyga> I'll gladly make the change
<zyga> folks, I have 11% of battery left, there's something wonky in the wiring outside my house, I can flip on a switch and I get power for a second but then fuses back home pop
<zyga> I tried fiddling with it for a while but something new must be shorting the circuit
<zyga> I need to either debug it or go and find another place to work and debug it later
<zyga> if I don't respond it's likely that my laptop has discharged or that I'm in the fuse box in the basement
<zyga> please telegram me for thing that need my attention
<zyga> macos builds are failing on timeouts?
<mborzecki> zyga: yup, since friday i think
<mborzecki> it's random though
<Chipaca> mborzecki, zyga, do you have logs?
<zyga> yes
<zyga> one sec
<zyga> https://travis-ci.org/snapcore/snapd/builds/600667289
<mborzecki> Chipaca: https://travis-ci.org/snapcore/snapd/jobs/600643173 ;)
<mborzecki> would't call them logs tbf
<Chipaca> ah, not us
<Chipaca> jamesh: I don't have a good answer, I'd raise it with the team later
<mborzecki> brb quick errand
<mvo> zyga: re 14.04> we keep it alive
<mborzecki> re, heh, quicker than i thought
<mup> PR snapd#7613 closed: snap-recovery: add minimal binary so that we can use spread on it <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7613>
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/7632 updated and responded
<mup> PR #7632: interfaces/apparmor: avoid excessive repetition of snap-update-ns mount rules <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>
<zyga> power is back :)
<zyga> amurray: hey
<zyga> amurray: are you able to do some reviews for us this week?
<zyga> amurray: ideally before Jamie is back later this week
<pstolowski> zyga: ty
<zyga> mvo: small remark about snap-recovery here v
<zyga> https://github.com/snapcore/snapd/pull/7629#pullrequestreview-304503890
<mup> PR #7629: snap-recovery: create filesystems as defined in the gadget <Created by mvo5> <https://github.com/snapcore/snapd/pull/7629>
<zyga> mvo: about this part, https://github.com/snapcore/snapd/pull/7629#discussion_r336617913 -- do you know what I meant about that comment - I'm fine if you just don't want to do it but I wanted to make sure we understand each other
<mup> PR #7629: snap-recovery: create filesystems as defined in the gadget <Created by mvo5> <https://github.com/snapcore/snapd/pull/7629>
<pedronis> mvo: this line seems wrong:  https://github.com/snapcore/snapd/blob/master/overlord/managers_test.go#L3625 shouldn't that brand-kernel
<pedronis> *that be
<ijohnson> morning y'all
<zyga> hello ijohnson :)
<ogra> zyga, the correct answer to "y'all" is "howdy" ;)
<ogra> ijohnson, howdy
<ijohnson> ogra is well versed in american responses
<mvo> thanks zyga and mborzecki for 7629 review
<ogra> haha
<zyga> ijohnson, cachio, mvo: another spread PR https://github.com/snapcore/spread/pull/90
<mup> PR spread#90: runner: remove filterDir, default include to "." <Created by zyga> <https://github.com/snapcore/spread/pull/90>
<ijohnson> zyga ack will look today
<zyga> thank you :)
<zyga> Eighth_Doctor: ack, I'll look
<mvo> mborzecki: how much work will it to get golang.org/x/xerrors from 31 to f30? we may need it for 7622   (looks like we go with xerrors eventually)
<mborzecki> mvo: looked rather easy last time i checked
<zyga> Eighth_Doctor: hmm, that's valgrind
<zyga> Eighth_Doctor: perhaps we should just not use valgrind on ppc64el
<zyga> that single arch that nobody ever needed
<zyga> Eighth_Doctor: if it persists we should file a bug on valgrind and remove the check on ppc64el
<zyga> Eighth_Doctor: let me know if that works for you
<zyga> should I break out OrderedSet out of https://github.com/snapcore/snapd/pull/7632
<mup> PR #7632: interfaces/apparmor: avoid excessive repetition of snap-update-ns mount rules <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>
<zyga> it's totally standalone and could land separately
<Chipaca> zyga: yes :)
<zyga> Chipaca: sure, one moment
<Chipaca> zyga: then i can ask silly questions about it without feeling like i'm stalling _important_ work
<zyga> haha
<Chipaca> zyga: :-p
<zyga> as long as you review it :)
<mup> PR snapd#7633 opened: strutil: add OrderedSet <Created by zyga> <https://github.com/snapcore/snapd/pull/7633>
<zyga> Chipaca: please ask away :)
<mvo> zyga: I updated 7629 based on your suggestions (and maciej)
<zyga> mvo: looking
<zyga> mvo: reviewed
<ijohnson> zyga: Chipaca beat me to submitting a review but I think I won because I found a bug
<Chipaca> ijohnson: totes
<ijohnson> isn't that how this works? whenever you find a bug you win?
<Chipaca> ijohnson: yes
 * ijohnson waits for my trophy
<Chipaca> ijohnson: you can now take the day off, find a fair, and ride a rollercoaster
<ijohnson> weeeeeee
<Chipaca> ijohnson: also, you can expense up to 3 candy apples
<Chipaca> to zyga
<Chipaca> he wrote the bug, he pays the candy apples
<Eighth_Doctor> it's just weird, since this has worked for literally years on ppc64le...
<zyga> thank you for the review guys
<zyga> ijohnson: you win
<ijohnson> you're welcome zyga
 * ijohnson goes back to foruming up a forum post
<Chipaca> zyga: silly question: do you actually delete things, in your use of this?
<zyga> nope
<Chipaca> zyga: then don't offer a Del() at all
<Chipaca> easy enough to add (maybe leave a comment so we don't write the bug again)
<zyga> yeah
<Chipaca> less code -> less bugs
 * Chipaca deletes all of overlord/
<Chipaca> \o/
<ijohnson> I found a bug and Chipaca deleted the overlord, and the rise of skywalker tickets go on sale tonight! feels like the start to a great day already :-)
<Chipaca> as long as you aren't runing ppc64le, apparently
<zyga> ijohnson, Chipaca: updated https://github.com/snapcore/snapd/pull/7633
<mup> PR #7633: strutil: add OrderedSet <Created by zyga> <https://github.com/snapcore/snapd/pull/7633>
<mup> PR snapd#6666 closed: Change file names that are breaking go modules <Created by slimjim777> <Closed by slimjim777> <https://github.com/snapcore/snapd/pull/6666>
<mup> PR pc-amd64-gadget#21 opened: Xnox closing uc20 branch <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/21>
<zyga> thank you guys
<zyga> I'll brak for lunch now
<zyga> and be back after that
<Chipaca> don't brak too hard tho
<mup> PR snapd#7634 opened: Add empty go.mod file to ignore directories <Created by slimjim777> <https://github.com/snapcore/snapd/pull/7634>
<Chipaca> awww, #6666 was an awesome PR number
<mup> PR #6666: Change file names that are breaking go modules <Created by slimjim777> <Closed by slimjim777> <https://github.com/snapcore/snapd/pull/6666>
<ijohnson> zyga: reviewed #7632, I'm a bit concerned about the de-duplication by just splitting by newlines since apparmor does support some multi-line rules AFAICT
<mup> PR #7632: interfaces/apparmor: avoid excessive repetition of snap-update-ns mount rules <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>
<zyga> ijohnson: yes but there are no rules that are multi-line there
<zyga> ijohnson: in any case, I can remove the split entirely, along with the buffer
<zyga> ijohnson: it's just verbose
<zyga> ijohnson: as the patch will affect more code
<ijohnson> zyga: but what I'm concerned about is if we are de-duping based on newlines, then we need to be sure this de-dup code doesn't ever get run on anything other than s-u-n completely auto-generated code
<zyga> ijohnson: I replied in the PR,
<ijohnson> looking
<zyga> ijohnson: your concern is based in truth but it's not immediately affecting this branch; we can remove the buffer and the split but it will make the diff somewhat larger as it's spanning more areas
<zyga> ijohnson: but we can totally do that
<zyga> ijohnson: it's just a cheap-way out of the bug for now, so that tests can be understood
<zyga> ijohnson: I can look at that as the ordered set lands and we can again focus on the essence of the bug
<ijohnson> zyga: do we get the same performance gains if we don't split and de-dup based on the strings passed in directly?
<zyga> ijohnson: no, because we really add huge chunks that contain unique comments
<zyga> ijohnson: just look at what the buffer contains
<zyga> ijohnson: it used to be one add before
<zyga> ijohnson: I was thinking about changing this some more, as follows
<zyga> ijohnson: keep an ordered set of rules like now
<zyga> ijohnson: and separately, a set of comments that go along with each rule
<zyga> ijohnson: the comments will refer to where this is used
<zyga> ijohnson: we de-duplicate the rules but collect the comments
<zyga> ijohnson: and when we emit the profiles we see short code and longer usage explanation
<ijohnson> hmm that could work
<ijohnson> another option is that when we go to de-dup the rules, we just replace a rule with a comment that says "// duplicated" - this would keep it simple to understand and still de-dup real rules, just keep the profile at 17k lines or whatever
 * ijohnson quick coffee break
<zyga> ijohnson: I proposed that but it was NACKed by jdstrand
<zyga> I'll ponder some on ordered set while having tea
<kjackal_v2> hi jdstrand would it be possible to get a review on https://dashboard.snapcraft.io/snaps/microk8s/revisions/988/ and https://dashboard.snapcraft.io/snaps/microk8s/revisions/992/ to get the work I have on microk8s strict confinemnt so far into a branch?
<kjackal_v2> thanks
<zyga> kjackal_v2: jdstrand is off until Wed
<kjackal_v2> zyga: any chance someone else can give a +1 in the review queue
<zyga> I donât know
<kjackal_v2> zyga: who is normally reviewing snaps that need manual reviews?
<kjackal_v2> There must be a process somewhere documented
<ijohnson> roadmr: do you still do revision review, etc.? see kjackal_v2's request: ^
<mup> PR snapcraft#2757 opened: Drop build_base check from make plugin. It is universal <Created by xnox> <https://github.com/snapcore/snapcraft/pull/2757>
<roadmr> jacekn: let's see
<roadmr> sorry ijohnson I mean you
<ijohnson> thanks roadmr
<roadmr> ijohnson, kjackal_v2 : do you need manual approval of these two revs only, or would you need allowance of personal-files use?
<kjackal_v2> roadmr: with "personal-files use" you mean autoconnecting the home interface? For now I am interested in just getting the snap on the latest/edge/strict channel branch, nothing more
<kjackal_v2> I am ok with manualy connecting the interfaces
<roadmr> kjackal_v2: right, I can just approve these two revisions so you can publish them; subsequent ones would still need manual approval and manual connection
<kjackal_v2> That is fine roadmr, we will need a few iterations before we consider this ready for releasing to the users
<roadmr> ok
<kjackal_v2> thank you
<roadmr> kjackal_v2: 988 is approved, 992 is waiting for auto-review, I'll approve as well if done
<roadmr> kjackal_v2: I need to afk for a bit, will look at any stuck revisions when I'm back
 * cachio lunch
<Chipaca> degville, pedronis: do we still not have seed.yaml (or seeding as a process) documentation?
<pedronis> Chipaca: we don't, seed.yaml is still an internal details btw (abuses and uses not with standing), also it will not exist in core20
<ijohnson> pedronis, Chipaca: do we support seeding with a developer's credentials i.e. from `snapcraft export-login`? I've never seed a core image with credentials like that
<pedronis> ijohnson: you mean building an image? or actual seeding?
<ijohnson> pedronis: yes building an image, can you put the credentials in the image/seed such that it will automatically login and refresh private snaps when booted up and running
<ijohnson> or maybe this already happens, I haven't ever tried this
<pedronis> ijohnson: that is officially not supported
<pedronis> it's an anti-pattern
<ijohnson> pedronis: ack, that makes sense
<ijohnson> just curious as it seems like that's what this user is requesting if Chipaca is referring to https://forum.snapcraft.io/t/snap-login-without-password-prompt/13762/6
<pedronis> private snaps exists mainly to support private early development of snaps
<pedronis> Chipaca: to be clear we do need life cycle docs, just not sure how much seed.yaml details are important
<roadmr> kjackal_v2: hey, all available microk8s revisions are now approved, let me know if anything else is needed
<kjackal_v2> awesome roadmr, thank you
<zyga> mvo: thank you for review on the ordered set
<zyga> mvo: I pushed the extra test changes and simplified some of the code as pointed out :)
<zyga> mvo: I'll merge when green but if there is something more to change I'm happy to do so in a follow up
<zyga> cachio: are spread tests for spread expected to pass? I got a failure in the ad-hoc test
<zyga> cachio: specifically on https://github.com/snapcore/spread/pull/90 (restarted since)
<zyga> ijohnson: ^ replied there, thank you for the review\
<mup> PR spread#90: runner: remove filterDir, default include to "." <Created by zyga> <https://github.com/snapcore/spread/pull/90>
<cachio> zyga, let me take a lok
<cachio> look
<zyga> cachio: no, sorry, no more logs
<cachio> zyga, this one started failing a time ago
<zyga> cachio: just wanted to ask you if you know some tests are known broken
<zyga> cachio: can we fix or disable it
<cachio> zyga, I'yes
<cachio> i'll fix it
<cachio> it is in my todo
<zyga> cachio: sÃºper, thank you
<cachio> zyga, the problem is this + ADHOC_ADDRESS='10.214.87.197
<cachio> localhost:59387'
<ijohnson> zyga: cool, thanks for clarifying
<roadmr> hey folks, is core considered a "base" snap technically?
<mup> PR snapcraft#2758 opened: Appstream desktop suffix <Created by galgalesh> <https://github.com/snapcore/snapcraft/pull/2758>
<zyga> roadmr: no, not yet
<zyga> roadmr: core is special
<zyga> roadmr: it's a base but it's not of type base
<roadmr> interesting :) ok zyga thanks
<roadmr> which are the most common/used bases at this point?
<cachio> zyga, adhoc test fixed
<cachio> PR 91
<zyga> cachio: cool, looking
<mup> PR #91: [15.04] Default to SocketMode=0660 if no socket mode option is given <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/91>
<zyga> cachio: how can we land it?
<cachio> zyga, you cant
<cachio> zyga, niemeyer is the only one
<zyga> I know, I mean what can we do to get it merged?
<cachio> just ping him
<niemeyer> Yeah, that should work
<zyga> hey :)
<zyga> niemeyer: you are sometimes hard to find :)
<niemeyer> Even more if that's done during working hours instead of at sleep time ;D
<zyga> cachio fixed a bug in a test, do you think you could have a look?
<niemeyer> zyga: Yeah, sorry.. I haven't managed to not sleep yet
<zyga> doesn't have to be now :)
<zyga> tomorrow is a good day to do more work
<niemeyer> Yes, I'm just non-ironically saying that I don't think you've been pinging me during working hours
<niemeyer> So "hard to find" is.. hmm.. strange? for a remote team
<niemeyer> I'm here if you need.. just ping
<zyga> niemeyer: I meant that usually you are extremely busy so we plan our sync bursts with you carefully
<niemeyer> Have you actually been trying to talk to me?
<zyga> niemeyer: not today, no
<zyga> niemeyer: if you have some time tomorrow I have a PR for spread as well but I think it would be best to discuss that during your working hours
<niemeyer> Not today, not recently.. I got one ping from you recently I think, and that was very late at night
<niemeyer> I'm just saying, don't use my busyness (?) as an excuse to not talk to me :)
<zyga> niemeyer: noted :)
<niemeyer> Thanks for your interest.. I can only help if I'm in the loop
<mup> PR snapd#7633 closed: strutil: add OrderedSet <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7633>
<mup> PR snapcraft#2759 opened: remote-build: rebase on master and include https token support <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2759>
<amurray> zyga: sure (re reviews) - I have had a couple on my list to do already but have been sidetracked with other things - since Jamie is out I am also taking the load of store reviews etc too - but please tag me (@alexmurray) and I will do my best
#snappy 2019-10-22
<guiverc> Howdy.  A question in #ubuntu then #ubuntu-mate had me try & run software-boutique but I get same error as OP in rooms; since it's a snap - where does request for help (bug report?) get filed please? or where can I learn more about  (not sure what to ask sorry)
<guiverc> (on 19.10 ^)
<guiverc> actually I may have it; I think it's installed by ubuntu-mate-welcome; thus I have a .deb and can use launchpad...
<mup> Bug #1575560 changed: snap refresh in status hold; not clear how to continue <Snappy:Expired> <https://launchpad.net/bugs/1575560>
<mup> Bug #1595649 changed: Audio playback fails for KDE apps with Phonon <Snappy:Expired> <https://launchpad.net/bugs/1595649>
<mup> Bug #1620815 changed: Test failures in github.com/snapcore/snapd/cmd/snap at 0187d66 <Snappy:Expired> <https://launchpad.net/bugs/1620815>
<mborzecki> morning
<mborzecki> mvo:  hey
<mborzecki> mvo: i'll be looking into the failures with go.mod
<mborzecki> mvo: perhaps the tests need a tweak
<mvo> mborzecki: thank you! any news from xerrors for f30 yet?
<zyga> Hey guys
<zyga> Good
<zyga> Morning :-)
<mborzecki> mvo: nope, tried to catch the maintainer on irc yesterday, prepared a spec and a scratch build for f30, but have not heard back, i'll open a ticket in bz and ping him via email
<mvo> mborzecki: thank you!
<zyga> amurray: thank you!
<mup> PR snapd#6174 closed: many: add snap debug refresh-catalogs <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6174>
<zyga> re
<zyga> huh
<zyga> https://travis-ci.org/snapcore/snapd/jobs/600949213
<zyga> what happened here?
<pstolowski> morning
<zyga> good morning Pawel
<zyga> pstolowski: winter is coming
<pstolowski> zyga: up to 19 deg celsius still estimated for today here, pretty crazy
<zyga> pstolowski: -7 forecast by next week
<pstolowski> zyga: ah, time to change for winter tires indeed
<mborzecki> pstolowski: yeah, it's probably high time to swap the tires
<mborzecki> pstolowski: though i'm seriously considering getting an all-year set
<pstolowski> mborzecki: yeah i've been thinking of it too, although, when it really gets bad (and it sometimes does) or when i go south to the mountains (which i do almost every year) i appreciate having winter tires ;)
<zyga> brb
<zyga> back from breakfast and into testing
<mup> PR snapd#7635 opened: tests/lib/gendevmodel: helper tool for generating developer model assertions <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7635>
<mborzecki> pedronis: ^^
<causasui> archlinux. `sudo snap install thing` gives 'error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:' followed by mount failed on a tmpdir beginning with 'sanity-mountpoint'. known issue? squashfs-tools and squashfuse are both installed
<zyga> causasui: can you cat /proc/filesystems - is squashfs there?
<zyga> causasui: it's not a known issue
<zyga> cc mborzecki ^
<mborzecki> causasui: can you post the otput of `uname -r` and `pacman -Q linux` ?
<causasui> mborzecki: uname -r -> 5.3.7-arch1-1-ARCH ; pacman -Q linux -> linux 5.3.7.arch1-1
<causasui> zyga: grep -i squash /proc/filesystems -> null :thinking-face:
<zyga> no squashfs
<zyga> that's why it fails
<zyga> now why there's no squashfs? :)
<causasui> ^
<mborzecki> idk, seems to work here on the same kernel version
<mborzecki> causasui: anything in dmesg?
<zyga> mborzecki: do you think a good old "modprobe" will fix it?
<causasui> mborzecki: you probably have squashfs module loaded I'm guessing
<mborzecki> zyga: it's supposed to be automatic
<zyga> yeah but worth a shot
<causasui> probably cant hurt, modprobe just 'squashfs' right?
<zyga> indeed
<causasui> alright, now squashfs is in /proc/filesystems but I get the same operation not permitted error
<causasui> down the rabbit hole we go
<mborzecki> causasui: anytyhing in dmesg?
<Chipaca> causasui: what gives you operation-not-permitted?
<causasui> Chipaca: you got here a minute late, just 'sudo snap install thing' throws an error about operation not permitted mounting to /tmp/sanity-mountpoint-stuff with squashfs
<causasui> mborzecki: tail dmesg shows a bunch of audit messages about snapd that end with 'res=success' which I guess is good?
<causasui> msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
<Chipaca> causasui: did you restart snapd after loading squashfs?
<causasui> no
<Chipaca> the sanity check is performed at start and if it fails snapd enters "abandon all hope" mode
<causasui> here goes
<causasui> ok did `sudo systemctl restart snapd && sudo snap install <thing>` and no change
<causasui> I'm checking for random degraded services
<Chipaca> ð
<causasui> systemctl --failed is 0
<mborzecki> causasui: journalctl -u snapd then?
<Chipaca> mvo says he'll be here in 20, fwiw
<causasui> mborzecki: hm picking out some interesting things, ' helpers.go:104: error trying to compare the snap system key: system-key missing on disk'
<causasui> messages about apparmor not being enabled but that wouldn't cause this I think?
<pstolowski> zyga: do we have any known issues with having /home on nfs?
<causasui> it's way past my bed time sadly, hopefully there will be activity when I'm up. thanks for the help so far
<Chipaca> causasui: maybe ijohnson and you overlap a little
<Chipaca> causasui: g'night
<zyga> pstolowski: hey
<zyga> pstolowski: auto-mount is not working there
<zyga> pstolowski: or to be precise, if you have autofs then it doesn't work
<zyga> explicit nfs is tested in spread and should work
<pstolowski> zyga: ok, good
<zyga> pstolowski: I updated https://github.com/snapcore/snapd/pull/7632
<zyga> no more buffering
<zyga> no more splitting
<mup> PR #7632: interfaces/apparmor: avoid excessive repetition of snap-update-ns mount rules <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>
<pstolowski> zyga: nice, ty, will re-review
<zyga> if you want I could split the automatic changes
<zyga> that is, change how we write
<zyga> before adding de-dupe
<zyga> the the branch can simply enable de-duplication and observe a cascade of changes
<zyga> let me know if this helps in review
<zyga> I added this as a comment in the review now
<pedronis> pstolowski: #7597 and #7431 (in that order) are Ian's PRs that need reviews
<mup> PR #7597: overlord/snapstate: add LastActiveDisabledServices, missingDisabledServices <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7597>
<mup> PR #7431: overlord/snapstate: don't re-enable and start disabled services on refresh, etc <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7431>
<pstolowski> pedronis: ack
<zyga> mvo: hey
<zyga> mvo: I updated https://github.com/snapcore/snapd/pull/7632 -- I asked a question at the bottom of the PR
<mup> PR #7632: interfaces/apparmor: avoid excessive repetition of snap-update-ns mount rules <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>
<zyga> mvo: splitting that branch could land the bigger automatic chunk easily
<mvo> zyga: thanks, I have a look
<zyga> I'll grab coffee and add the remaining missing part
<dot-tobias> jdstrand: Are there any known issues with the network-manager interface on Core when I use it in the post-refresh hook? I added the plug to this hook and it works fine when testing on Ubuntu Desktop, but on Core I always get AppArmor denials.
<zyga> a test that compiles some profiles and ensures we are under 500M of memory
<zyga> and run it before and after just to be sure
<zyga> dot-tobias: jdstand is off today
<zyga> dot-tobias: if you share the denials I can look
<zyga> brb for coffee
<dot-tobias> zyga: Ok, thanks. The denial is here: https://paste.ubuntu.com/p/CfyfPYsYR7/
<dot-tobias> zyga: I looked at the policies file in /var/lib/snapd/apparmor/profiles/snap.mirros-one.hook.post-refresh *before* the refresh, and it contains the default lines which should already grant access to the Introspectable interface. snapcraft.yaml contains the 'network-manager' plug for the post-refresh hook, see https://gitlab.com/glancr/mirros-one-snap/blob/tmp-core16/snap/snapcraft.yaml#L21
<kjackal> Hey snappy people, I am missing something. We released microk8s to edge/strict yesterday. I can snap install it now, but cannot connect interfaces. Is this expected? Any idea why?
<ogra> "cannot connect interfaces" ...
<ogra> can you be a bit more detailed ?
<ogra> (what command do you call, whats the error, did you check the journal for errors etc)
<kjackal> "snap connections microk8s" showes all connections.  I am expecting "sudo snap connectio microk8s:home :home" to change the "Notes" column saying something like "manual"
<zyga> dot-tobias: can you look for the DENIED line, it has some more information that is absent here
<ogra> not sure it does this if the interface is already connected
<ogra> (and home auto-connects on desktop)
<zyga> dot-tobias: looking
<kjackal> let me see then
<ogra> s/desktop/classic installs/
<zyga> dot-tobias: network-manager interface does not grant that method
<kjackal> awesome orga, you are right, everything was already connected
<zyga> dot-tobias: one could argue it should, could you please report a bug, I can look into it
<ogra> yay
<dot-tobias> zyga: But why does it work when I test the (confined) snap on Ubuntu Desktop, or run the same command (Ruby wrapper for D-Bus calls) from the installed snap? This denial only occurs on Core during post-refresh.
<ogra> and you are sure the interface is connected at that time ?
<dot-tobias> zyga: Re dmesg line â https://paste.ubuntu.com/p/rg6SXb2vMf/
<zyga> dot-tobias: how are you testing it on the desktop?
<zyga> dot-tobias: introspection is usually not required
<zyga> dot-tobias: perhaps it's something specific to core that triggers it
<zyga> dot-tobias: note this:
<zyga> const networkManagerConnectedPlugAppArmor = `
<zyga> # Description: Allow using NetworkManager service. This gives privileged access
<zyga> # to the NetworkManager service.
<zyga> #include <abstractions/dbus-strict>
<zyga> # Allow all access to NetworkManager service
<zyga> dbus (receive, send)
<zyga>     bus=system
<ogra> (also ... on core you are likely using the NM snap while the deb runs on desktop, the interface migth act differetly in that case)
<zyga>     path=/org/freedesktop/NetworkManager{,/**}
<zyga>     peer=(label=###SLOT_SECURITY_TAGS###),
<zyga> # NM implements org.freedesktop.DBus.ObjectManager too
<zyga> dbus (receive, send)
<zyga>     bus=system
<zyga>     path=/org/freedesktop
<zyga>     interface=org.freedesktop.DBus.ObjectManager
<zyga>     peer=(label=###SLOT_SECURITY_TAGS###),
<zyga> `
<zyga> oh god, sorry
<ogra> yay
<zyga> dot-tobias: apparmor spec for connected network-manager plug  https://www.irccloud.com/pastebin/faBWA4Jd/
<zyga> the only thing that differs between core and classic is the peer label, either "unconfined" on the desktop or some snap label on core
<zyga> note that the interospectable interface is not there in either case
<zyga> since the program was ruby
<zyga> I can infer that it builds a method map for each object it talks to
<zyga> by using introspection
<dot-tobias> zyga, ogra: On Desktop, I have my snap from stable installed, then attempt to refresh from edge which contains the new D-Bus calls. Works. Same on Core errors as above.
<zyga> but this is ruby, perhaps on the desktop it reads some files to get that without asking
<zyga> I honestly don't know
<zyga> but I can explain why there's a denial on core for sure: because it is not permitted
<dot-tobias> zyga: Will test further on core, thanks in the meantime. The Ruby wrapper is a third-party lib, and yes it uses Introspect to map Properties/Interfaces.
<zyga> dot-tobias: you can expand the interface to add the introspection locally
<zyga> it might help you move further along
<zyga> to see if there's something else blocking
<zyga> let me know if you need any help with that
<dot-tobias> zyga: You mean adding an entry to /var/lib/snapd/apparmor/profiles/snap.mirros-one.hook.post-refresh ?
<ogra> dot-tobias, what i meant is that the slot side might act different in the NM snap compared to the (completely unconfined) deb ...
<dot-tobias> ogra: Yeah, sorry forgot to answer you. I guess that's the case, at least explains why Desktop/Core act differently when the only policy difference is the label (as zyga mentioned above)
<ogra> right
<dot-tobias> ogra/zyga: Ah, the dmesg output (to me) hints in this direction: https://paste.ubuntu.com/p/rg6SXb2vMf/ â if I read this correctly, the second line denies the call for the network-manager snap itself
<ogra> thats what i meant :)
<zyga> yep
<ogra> (or guessed rather :) )
<zyga> dot-tobias: in any case, if you report a bug I can get it fixed today
<zyga> I just need to write a regression test for somethnig else
<dot-tobias> zyga: On it, should I file against snapd?
<zyga> yes, please
<dot-tobias> zyga: https://bugs.launchpad.net/snapd/+bug/1849291 â let me know if you need more info. And thank you very much in advance! Just to have a timeframe: If this is fixed, when could I expect the next core release? So that I don't deploy my own snap before that. Wouldn't want user's devices to retry refreshes just to error out ð
<mup> Bug #1849291: Interface network-manager should grant access to org.freedesktop.DBus.Introspectable <snapd:New> <https://launchpad.net/bugs/1849291>
<zyga> dot-tobias: not sure, I'll add this to the bug when I konw
<zyga> *know
<zyga> wow, what a dramatic difference this fix makes!!!
<Chipaca> zyga: which?
<zyga> before
<zyga> wall: 0:03.17, mem: 1552532 Kb
<zyga> after
<zyga> wall: 0:00.22, mem: 37728 Kb
<zyga> that's a winner
<zyga> :D
<zyga> Chipaca: this is the mount de-duplicating
<zyga> *deduplication
<mup> PR pc-amd64-gadget#21 closed: Xnox closing uc20 branch <Created by xnox> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/21>
<mup> PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <Closed by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR snapd#7636 opened: gadget, overlord/devicestate: dd support for customized update policy, add remodel policy <Remodel :train:> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7636>
<mborzecki> mvo: pedronis: ^^
<mborzecki> should be a simple one
<mborzecki> zyga: you said somethng about exponential growth the other day, didn't you? :)
<zyga> yeah
<zyga> wrapping up the test soon :)
<zyga> but happy to fix this
<zyga> this will save a lot of energy planet-wide
<mborzecki> zyga: there a line for your CV ;)
<zyga> wrote inefficient code, fixed it after shipping to everyone
<mborzecki> sounds too familiar when you put it this way
<ogra> isnt that the standard anyway ?
<mup> PR snapd#7637 opened: tests/main/interfaces-contacts-service: disable on openSUSE Tumbleweed <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7637>
<mborzecki> ^^ should unblock master
<mborzecki> and PRs too
<mup> PR pc-amd64-gadget#22 opened: Store changes <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/22>
<Chipaca> zyga: mborzecki: "croud-sourced performance measurements"
<zyga> Chipaca: practical experience in reducing climate change
<zyga> ok, test executing now
<pedronis> mborzecki: thanks, trying to get to a pause point with something else, and then I will switch to do a bit of PR reviewing
<mborzecki> pedronis: thanks!
<mvo> mborzecki: thanks for this one (I changed dd -> add in the title, hope that was ok)
<mborzecki> mvo: haha thanks!
<pedronis> heh, for a second I wondered if the 'dd' command was involved
<pstolowski> ijohnson: hey, sorry about all the nitpicks re missing dots in comments (added inline suggestions where i spotted those); i found such comments (especially longer doc strings) slightly hard to read / grasp quickly with no fullstops
<mup> PR snapd#7637 closed: tests/main/interfaces-contacts-service: disable on openSUSE Tumbleweed <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7637>
<mborzecki> yay
<zyga> thanks mvo
<mvo> zyga: thanks to mborzecki
<zyga> pstolowski: do you have time to work with me on the apparmor fix, I was thinking about reducing the branch by moving the automatic changes elsewhere and landing
<zyga> pstolowski: so that the actual fix is just a small change + test changes + regression test
<pstolowski> zyga: only if i park something else; is it possible though to split it? all the profile changes need to land with the fix no?
<zyga> pstolowski: it's very easy to split, vast majority of change is the "getting ready" code
<zyga> pstolowski: that can land without any effect to tests or actual performance today
<zyga> pstolowski: I'm mainly looking for someone who would follow along and review it
<zyga> pstolowski: but no rush, I'm working on the spread test still, I need to check the numbers as I see some discrepancy
<pstolowski> zyga: okay, perhaps after standup
<zyga> booo
<zyga> there's no "time" command on core
<zyga> pstolowski: thanks!
<pedronis> mvo: Chipaca: does https://github.com/snapcore/snapd/pull/7615 needs my input? or should be ok for you two to work to land it?
<mup> PR #7615: policy: implement CanRemove policy for the snapd type <Created by mvo5> <https://github.com/snapcore/snapd/pull/7615>
<pstolowski> core has no time
<mborzecki> core is super busy
<Chipaca> pedronis: i think it's ok without your input
<pedronis> ok
<Chipaca> pedronis: ah, one question there, was that I recommended using model.Classic() instead of release.OnClassic, wdyt?
<pedronis> that sounds fine
<zyga> mborzecki: is there a "time" command on arch?
<Chipaca> pedronis: ok
<mborzecki> zyga: there's 2 time commands, some shells have a builtin, and there's gnu time at /usr/bin/time
<zyga> I need GNU time
<mborzecki> zyga: yup, that one is avialble, you may need to install it separately
<pedronis> Chipaca: we should just be consistent across policy about that
<zyga> mborzecki: thanks
<Chipaca> pedronis: agreed
<Chipaca> mborzecki: zyga: why wouldn't gnu time be installed?
<zyga> Chipaca: it's not on core
<mborzecki> Chipaca: tbh i think it rarely is
<zyga> and not on arch or sid
<Chipaca> huh
<mborzecki> iirc fedora doesn't have it by default either
<ogra> zyga, core ships at least the shell builtin
<zyga> ogra: it's not what I need
<zyga> I need the other one
<mborzecki> zyga: you probably need time -v right?
<zyga> no
<zyga> time -f %M
<ogra> snap it then ;)
<mborzecki> heh ;)
<zyga> ogra: cannot run snaps with snaps
<ogra> pfft, minor detail ...
 * zyga breaks for lunch
<zyga> see you at the standup
 * zyga watches https://www.youtube.com/watch?v=L-7W5pc7OjU while eating veggies
<Chipaca> zyga: is #7615 GTG IYHO?
<zyga> one sec
<mup> PR #7615: policy: implement CanRemove policy for the snapd type <Created by mvo5> <https://github.com/snapcore/snapd/pull/7615>
<zyga> ah
<zyga> I'll do a pass, I think so
<zyga> it looked ok before
<zyga> just had that one question then
<mup> PR snapd#7638 opened: Add OnlyKey to List <Created by onlykey> <https://github.com/snapcore/snapd/pull/7638>
<pedronis> mborzecki: I reviewed #7630, the main thing might require a prereq PR, it seems it might be time to split some .go files. they mix too much and they are getting big
<mup> PR #7630: overlord/devicestate: check snap handler for gadget remodel compatibility <Remodel :train:> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7630>
<mborzecki> pedronis: thanks, will take a look after than standup
<mborzecki> s/than/the/ ofc
<Chipaca> eep, the standup
 * Chipaca runs
<kjackal> hey snappy people, to use the "system-usernames:" I need snapd to be patched to be aware of the username?
<Chipaca> kjackal: no, only one username is supported for now
<Chipaca> kjackal: 1 sec, there's an explanation
<zyga> ondra: nice work on https://github.com/snapcore/snapd/pull/7596
<mup> PR #7596: overlord/snapstate: skip catalog refresh if unseeded <Simple ð> <Created by kubiko> <https://github.com/snapcore/snapd/pull/7596>
<Chipaca> kjackal: we're in phase 1, https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461
<Chipaca> kjackal: sorry, this: https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461/3?u=chipaca
<Chipaca> phase 1 is described at the end of that comment
<Chipaca> kjackal: i assume you've seen https://forum.snapcraft.io/t/system-usernames/13386 already
<Chipaca> kjackal: which is also describing current, ie phase 1
<kjackal> Chipaca: so there is only one user/group I can use, the "snap_daemon", right?
<Chipaca> kjackal: at this stage, yes
<kjackal> sounds good, let me try that
<mup> PR snapd#7596 closed: overlord/snapstate: skip catalog refresh if unseeded <Simple ð> <Created by kubiko> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7596>
<zyga> and now I have an 1080p IPS display
<zyga> :D
<zyga> the difference is insane :D
<diddledan> mine's bigger :-p
 * zyga is very happy with what he has :)
<Chipaca> diddledan: it's not how big it is, it's how much you giggle while using it
<diddledan> haha. and that did make me giggle
 * Chipaca rests his case
<diddledan> giggle when you wiggle it :-)
<diddledan> github actions really need better (more) examples
<diddledan> I wish CI services had local working environments to test that you've configured correctly before you upload to your shared project repository
<diddledan> otherwise you end up with "Add Travis CI" in one commit followed by 15 further "Fix Travis CI" and "Really Fix Travis CI" and "FFS, Travis CI Again"
<zyga> diddledan: I very much share this opinion
<zyga> it's very annoying
<zyga> I think travis used to have something like that
<zyga> via their ruby command line tool
<zyga> it'd let you run a job against your working directory
<diddledan> it's not just travis though, none of them have anything like it
<zyga> diddledan: did you see https://github.com/travis-ci/travis.rb
<mup> PR snapcraft#2760 opened: remote-build: rebase onto master <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2760>
<diddledan> interesting
<ChrisTownsend> Hey all, I have a snap that no longer has plug defined, so I want to remove it.  But when I try to disconnect it, it says the snap has no plug or slot with that name.  Is there some way to force the disconnect?
<zyga> Chipaca: there's a bug about that
<zyga> er
<zyga> ChrisTownsend: ^
<zyga> ChrisTownsend: sorry, tab completed incorrectly
<zyga> ChrisTownsend: we need to look into it
<ChrisTownsend> zyga: Ah, ok...no worries about tab completion:)
<ChrisTownsend> zyga: Do you have the bug number handy?
<zyga> https://bugs.launchpad.net/snapd/+bug/1848516
<mup> Bug #1848516: snap connections/interfaces shows dropped interfaces as connected after refresh <snapd:New> <https://launchpad.net/bugs/1848516>
<ChrisTownsend> zyga: Also, if there is an active connection listed and I did remove the plug/slot, can I be guaranteed that the new snap will indeed not use that connection?
<ChrisTownsend> zyga: Thanks for the link
<zyga> ChrisTownsend: that part works okay but we need to fix the UX to match AFAIK
<ChrisTownsend> zyga: Ok, great, thanks!
<zyga> pstolowski: so do you have a moment
<pstolowski> zyga: yes, but need a (late) lunch first
<zyga> pstolowski: ok, please ping me later
<pstolowski> zyga: sure
 * zyga goes to play with the thinkpad for a moment
<zyga> hmmm
<zyga> https://www.irccloud.com/pastebin/E6MEZkwC/
<zyga> is "command foo" equivalent to running /usr/bin/foo over alias/builtin?
<zyga> mborzecki: around?
<zyga> mborzecki, pstolowski: this is the emit PR: https://github.com/snapcore/snapd/pull/7639
<mup> PR #7639: interfaces: emit update-ns snippets to function <Created by zyga> <https://github.com/snapcore/snapd/pull/7639>
<zyga> it puts enough indirection for the de-duplication PR to shrink
<mup> PR snapd#7639 opened: interfaces: emit update-ns snippets to function <Created by zyga> <https://github.com/snapcore/snapd/pull/7639>
<pstolowski> zyga: ok, looking. how can i help with the remainder?
<mup> PR snapd#7640 opened: snap-recovery: deploy gadget content when creating partitions <Created by mvo5> <https://github.com/snapcore/snapd/pull/7640>
<mup> PR snapd#7615 closed: policy: implement CanRemove policy for the snapd type <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7615>
<zyga> pstolowski: re
<zyga> so
<zyga> pstolowski: please review https://github.com/snapcore/snapd/pull/7639
<mup> PR #7639: interfaces: emit update-ns snippets to function <Created by zyga> <https://github.com/snapcore/snapd/pull/7639>
<zyga> this is the no-op part of the real fi
<zyga> fix
<zyga> so if it lands I can shrink the other PR to the real essence
<zyga> pstolowski: for context on emit
<zyga> pstolowski: it is used in the "big" PR where it is a thin wrapper around simply adding a de-duplicated snipper
<zyga> snippet*
<pstolowski> zyga: yes, looks like a good plan
<Chipaca> zyga: did you check onlykey for CLA signature before +1'ing?
<Chipaca> zyga: I don't think CLA is needed for the code so far, but fixing the test as well might push it over? dunno
<pedronis> ijohnson: https://forum.snapcraft.io/t/systemctl-service-management-unification/13808/3
<pstolowski> zyga: a bit of a general question there
 * cachio lunch
<zyga> Chipaca: no, because there's a CI part for it
<zyga> pstolowski: looking
<zyga> pstolowski: replied
<zyga> pstolowski: replied again
<pstolowski> zyga: where are these helpers tested? i grepped the code / looked for references, found nothing
<Chipaca> zyga: that, when I added, I said should be checked for false-negatives of newcomers
<Chipaca> or is that false-positives? either way, this is one of those cases
<zyga> pstolowski: huh, you are right! they are no tested directly
<zyga> they can be dropped
<pstolowski> uff ;)
<zyga> they are tested indirectly obviously but I thought we had a bunch of explicit tests as well
<zyga> Chipaca: aha, I didn't know that
<zyga> pstolowski: dropped now
<zyga> thanks, that's a nice catch :)
<zyga> Chipaca: I think it's false-sense-of-security then :)
<zyga> pstolowski: do you plan to do any more reviews todayt/
<zyga> pstolowski: if not I will EOD
<zyga> pstolowski: and return here tomorrow
<pstolowski> zyga: just added last comment
<zyga> pstolowski: I tried to reply, perhaps we can HO quickly if you want to
<zyga> though I won't mind to wait for tomorrow if you want to EOD
<pstolowski> zyga: yep tomorrow, i need to leave soon, taking my daughter to horse club
<zyga> pstolowski: cool! I'm sure she will love it
<zyga> mvo: hey :) welcome back?
<zyga> pstolowski: thank you, lets continue tomorrow morning
 * zyga EODs
<mvo> zyga: yeah, was back before but then network decided to stop working
<pstolowski> zyga: it's weekly routine for a while already ;)
 * zyga looks at shiny new thinkpad screen :)
<zyga> pstolowski: my daughter is way more lazy
<zyga> she only did it three times
<zyga> mvo: the screen is gorgeous :)
<pstolowski> zyga: horses 1x a week, football 2-3x a week :O
<mvo> zyga: 1900x1200 ?
<zyga> mvo: I won't bother you tonight, I have some PRs for review but I think it's time to stop
<zyga> mvo: 1080p only
<zyga> mvo: it's a panel that fits into the device but it's not sold with it originally
<om26er> Can I use python 3.8 in my snap, is there a how-to for that ?
<zyga> om26er: yes, if you build python3.8 it can be used there
<zyga> I don't know if there's a tutorial for it
<zyga> om26er: snapcraft may or may not help you with it a lot
<zyga> om26er: but technically you can ship that snap to 14.04 tomorrow and it will work
<om26er> I want 3.8 because apparently we can set custom location for pycache tree, skipping the build time bytecompile of files and doing that using a post-install hook, ultimately causing a reduction is snap size
<om26er> https://bugs.python.org/issue33499
<zyga> om26er: if you start with a part that builds 3.8 from scratch
<zyga> om26er: add your app in a way that doesn't cause snapcraft to pull in all of python 3.7 for you again
<zyga> om26er: in other words, yes, for sure, just more manually than otherwise snapcraft allows for
<om26er> in our case our snap of 33mb becomes 49mbs with bytecompiled code. (doing that is important because startup on raspberry pi changes from 30 seconds to 10)
<om26er> zyga hmm, I will dig into this
<zyga> om26er: good luck!
<zyga> om26er: as you get that done you also gain independence and flexibility
<zyga> om26er: you can optimize python
<zyga> om26er: build some parts disabled
<zyga> om26er: and go to 3.9 the day it is out
<zyga> om26er: or you can follow fixes that you need
<om26er> heh, I think 3.8 is what I need, no other requirements for now ;-)
<om26er> OTOH: Can we use python 3.6 from core18 -- so we don't bundle our own copy of python ?
<zyga> om26er: yes
<zyga> om26er: again, I don't know if snapcraft makes that easy
 * om26er adds that to "to dig" list :-)
<om26er> Wimpress ping! you talked about trimming a Python based snap at Ubucon, can you share a snapcraft yaml that does that ?
<ijohnson> pedronis: ack thanks for looking at that, so do I have general consensus on the proposal outlined there? or do you anticipate having more comments?
<ijohnson> (I know Chipaca will review it as well, but just wondering if I should consider your comment as a +1)
<Saviq> jdstrand: hey, I'm running snap-review in our CI, and we're switching to strict with the `multipass-support` plug - any way we can make snap-review pass? https://travis-ci.org/CanonicalLtd/multipass/jobs/601308279#L4750
<zyga> Saviq: jdstrand is back tomorrow
<Saviq> ack :)
<pedronis> ijohnson: it's +1 assuming my expansion of your point seems to match what you had in mind
<ijohnson> yes it matches
<ijohnson> thanks pedronis
<pedronis> ijohnson: you'll have to chat a bit with pstolowski|afk though because I fear that your change and what he will need to do for the bug he mentioned today will interfere a bit
<pedronis> ijohnson: because it sound he needs start-snap-services to become a start --enable
<ogra> om26er, while you can indeed use the python binary itself from core/core18 you still need your python modules ... the python binar itself is 4-5MB uncompressed, compressed inside your snap that will just save you 1MB or so in the end ...
<ogra> 7me isnt sure thats actually worth the effort
<ijohnson> pedronis: ack yes I will chat with him tomorrow
<causasui> archlinux. `sudo snap install thing` gives 'error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:' followed by mount failed on a tmpdir beginning with 'sanity-mountpoint'. squashfs-tools and squashfuse are both installed & squashfs is in /proc/filesystems
<causasui> have rebooted since install & last kernel update is loaded etc
<mup> PR snapcraft#2760 closed: remote-build: rebase onto master <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2760>
<ijohnson> hey causasui sorry we missed you earlier, do you see anything in dmesg when this happens?
<causasui> ijohnson: messages about apparmor not being enabled but that wouldn't cause this I think? http://ix.io/1ZwJ there's a sample
<ijohnson> causasui: what does `snap changes` show for you?
<causasui> 1    Done    yesterday at 23:52 PDT  yesterday at 23:52 PDT  Initialize system state
<mup> PR snapd#7641 opened: tests: moving ubuntu-19.10-64 from google-unstable to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7641>
<causasui> ijohnson: has this risen to the level of a forum / stackexchange post?
<ijohnson> causasui: thanks for that, what is `snap version` for you?
<causasui> ijohnson: 2.42-2 http://ix.io/1ZwR
<ijohnson> causasui: can you run `snap download hello-world && mkdir test && sudo mount -o squashfs hello-world*.snap test` and see what happens?
<ogra> causasui, grep squash /proc/filesystems
<ijohnson> snap download doesn't currently go through snapd so that should work fine
<ijohnson> ogra: he already has squash in /proc/filesystems
<ogra> (see if your kernel doesnt accidentially miss squashfs)
<ijohnson> s/he/they/ (sorry)
<ogra> oh, ok
<ogra> (right, i havent seen the first line above)
<ijohnson> my best guess is this is some kine of kernel mount problem
<ijohnson> s/kine/kind/
<ogra> there was a bug in 5.2
<ijohnson> can't type today for some reason
<ijohnson> yeah they have 5.3.7
<ogra> right
<ogra> https://forum.snapcraft.io/t/mounts-broken-with-kernel-5-2/12272
<ogra> probably the fix got lost with the newer update ?
<ijohnson> yeah could be
<causasui> ogra: it's there
<causasui> ogra: squashfs in /proc/filesystems that is
<causasui> ijohnson: 'he' is fine, thanks
<causasui> :)
<ijohnson> :-) don't want to assume
<ijohnson> were you able to run that snippet above?
<causasui> ijohnson: which?
<ijohnson> causasui: can you run `snap download hello-world && mkdir test && sudo mount -o squashfs hello-world*.snap test` and see what happens?
<causasui> mount: hello-world*.snaptest: can't find in /etc/fstab.
<causasui> lul
<causasui> what?
<causasui> oh you forgot the mountpoint
<mup> PR snapcraft#2761 opened: Core20 base <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2761>
<ijohnson> hmm copy paste error?
<causasui> ah it wrapped
<causasui> mount: /tmp/test: special device hello-world*.snaptest does not exist.
<ogra> missing space
<ogra>  sudo mount -o squashfs hello-world*.snap tes
<ogra> bah
<causasui> ah
<ogra>  sudo mount -o squashfs hello-world*.snap test
<causasui> mount: test/: mount failed: Operation not permitted.
<causasui> odd
<ijohnson> are you root?
<ijohnson> or using sudo?
<causasui> sudo
<causasui> I'll try becoming root, why not
<causasui> yeah same error as root
<ijohnson> hmm, try `sudo strace -emount mount -o squashfs hello-world*.snap test` ?
<zyga> causasui: if you are getting permission denied as root then there must be a LSM around you
<zyga> causasui: or something is intercepting system calls for you
<ogra> selinux ?
<ogra> that would produce dmesg messages, no ?
<ijohnson> does arch use selinux? I didn't think so
<ogra> (or kern.log or whatever arch uses)
<causasui> selinux is available but it takes some work to set up, based on the wiki. I for sure did not install it knowingly
<ogra> yeah, unlikrly thats it then
<ogra> *unlikely
<ijohnson> causasui: is this perhaps some kind of container?
<causasui> ijohnson: what is "this"? I thought snaps were containers
<ogra> your archlinux ..
<causasui> ogra: that's not obvious from the question, sorry. no, it's not
<ijohnson> err sorry is your arch installation is it a container or a VM or something?
<ogra> is it running indside a container
<causasui> negative
<ijohnson> hmm
<ogra> anything in dmesg from your mount attempts ?
<causasui> no new messages in dmesg
<ogra> journald ?
<zyga> dmesg may not contain anything related to LSMs if there's nothing collecting those from the kernel and turning them into log messages
<zyga> e.g. auditd
<ogra> sure, but always worth taking a look anyway
<causasui> ogra: I don't see anything relevant in journalctl exept sudo logging the mount attempts themselves
<ijohnson> at this point I think a forum post is warranted, I have no idea what this is, and it very well could be an upstream kernel issue with mounts
<ogra> do you have any opportunity to use an older kernel for a uick test ?
<ijohnson> if you're getting permission denied from trying to mount a squashfs but squashfs is in /proc/filesystems and you don't have selinux on, then smells like a kernel thing to me
<ogra> smells really similar to the forum post above about archs 5.2 kernel
<ijohnson> yeah indeed
<ogra> but there you had at least a few chatty error messages
<ogra> silence in all logs is really weird
<mup> PR snapcraft#2762 opened: appstream: extract title and version <Created by galgalesh> <https://github.com/snapcore/snapcraft/pull/2762>
<ijohnson> cachio: any chance you could review #7581 this afternoon?
<mup> PR #7581: tests: add netplan test on ubuntu core <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7581>
<causasui> ijohnson: ogra: I assume the best venue is the one linked in the topic :) I'll type something up in there, thanks
<ijohnson> sounds good to me
<causasui> this is snapd not snapcraft right?
<ijohnson> it's a snapd bug yes, but the official forum is forum.snapcraft.iot
<ijohnson> err forum.snapcraft.io
<cwayne> Aww man it should be .iot
<ijohnson> that would be a cool TLD
<causasui> ijohnson: yes but there are different tags in that forum
<causasui> https://forum.snapcraft.io/t/cannot-mount-squashfs-image-using-squashfs-operation-not-permitted/13829
<ijohnson> causasui: right snapd tag is correct
<ijohnson> thanks, we'll make sure that our resident arch expert mborzecki takes a look tomorrow
<cyphermox> cool
<cyphermox> ijohnson: are there tests we can add to netplan too to check that things are sane?
<ijohnson> cyphermox: what things need to be tested?
<cyphermox> ijohnson: I don't know, but if you're adding tests for netplan in snapd, I'm questioning if there's some test I can add in netplan to facilitate
<cachio> ijohnson, sure
<ijohnson> cyphermox: ah right that test, well I think you already have tests for that on your side, all I added was tests for accessing the info d-bus method to network-setup-{observe,control}
<cyphermox> ok :)
#snappy 2019-10-23
<ijohnson> morning mvo, there's some weirdness going on with some of the spread tests where it just dies immediately before running spread
<ijohnson> The SU doc for me has an example build to look at, I couldn't figure it out, almost seems like spread itself is dying
<ijohnson> Anyways time for me to log off, good luck
<mvo> ijohnson: thank you, I noticed this right before going to bed too, I had hoped it was a fluke
<mvo> ijohnson: thanks, get some rest!
<mvo> ijohnson: I have a look
<mup> PR snapd#7642 opened: travis.yml: add 'sh -x' to run-checks <Created by mvo5> <https://github.com/snapcore/snapd/pull/7642>
<zyga> good morning
<zyga> hey mvo
<mborzecki> morning
<mvo> hey zyga and mborzecki
<zyga> hey mborzecki
<mvo> looks like travis has some problems sometimes
<mborzecki> mvo: zyga: hey
<zyga> fog, fog as far as I can see :)
<mvo> and of course my debug PR works just fine :(
<mborzecki> hahaha
<zyga> mvo: merge everything into it and land ;)
<zyga> some store woes yesterday
<zyga> error: cannot search: got unexpected HTTP status code 403 via GET to
<zyga>        
<zyga> "https://api.snapcraft.io/api/v1/snaps/search?confinement=strict%2Cclassic&fields=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha3_384%2Csummary%2Cdescription%2Cbinary_filesize%2Cdownload_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Csnap_id%2Clicense%2Cbase%2Cmedia%2Csupport_url%2Ccontact%2Ctitle%2Ccontent%2Cversion%2Corigin%2Cdeveloper_id%2Cdeveloper_name%2Cdeveloper_vali
<zyga> dation%2Cprivate%2Cconfinement%2Ccommon_ids&q=pc&scope=wide"
<zyga> some 503 as well
<zyga> hello niemeyer
<zyga> niemeyer: when you are around today could you please look at sergio's fix for spread spread tests: https://github.com/snapcore/spread/pull/91
<mup> PR spread#91: tests: Fix adhoc test <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/91>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7614 could use a review
<mup> PR #7614: cmd/snap-confine: implement snap-device-helper internally <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>
<zyga> and it's green (shocking)
<zyga> mvo: do you think you could look at https://github.com/snapcore/snapd/pull/7547
<mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
<zyga> at least conceptually
<zyga> it is already being looked at by ian and jamie but I wanted to make sure you understand what is going on there as well
<mvo> zyga: sure, was wondering if samuele needs to look but I'm happy to do it
<zyga> mvo: I think we all should look because it's such a fundamental part
<mvo> zyga: sounds good
<mup> PR snapd#7634 closed: tests: ignore directories for go modules <Created by slimjim777> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7634>
 * zyga needs to garden his PRs
<mborzecki> zyga: left some comments under your PRs
<mborzecki> zyga: btw. what's the problem with ijohnson's named hierarchy use?
<zyga> none?
<zyga> can you clarify please
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/7547#pullrequestreview-305622718 but i see it was nothing weird ;P
<mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
<zyga> mborzecki: did you see my reply on https://github.com/snapcore/snapd/pull/7547#issuecomment-545280953
<mup> PR snapd#7629 closed: snap-recovery: create filesystems as defined in the gadget <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7629>
<zyga> mvo: https://github.com/snapcore/snapd/pull/7642 is green
<mup> PR #7642: travis.yml: add 'sh -x' to run-checks <Created by mvo5> <https://github.com/snapcore/snapd/pull/7642>
<mvo> zyga: yeah, its strange
<mvo> zyga: another of my PRs also went green
<zyga> let's merge it and see
<mvo> zyga: maybe it was a fluke
<zyga> question is what was it, your PR might answer that
<mvo> zyga: yeah, we can always revert
<pstolowski> morning
<zyga> hey pawel
<zyga> pstolowski: sorry to jump into this straight away but I'm hunting for reviews for the emit() branch again :)
<zyga> mborzecki: I debugged why I saw different numbers in spread and on my system, without the memory fix patch
<zyga> mborzecki: turns out my desktop had more rules because of the document portal
<mborzecki> hah
<zyga> mborzecki: so the test is reliable
<zyga> mborzecki: it just measures a smaller set of rules
<zyga> mborzecki: but it's still clear as day and night that it is using small amount of memory vs huge before
<pstolowski> zyga: will get to it in a moment
<zyga> pstolowski: I rebased the original PR on the emit branch now
<zyga> pstolowski: and it shows exactly how little has to change, on top of emit(), to fix the memory issue
<zyga> pstolowski: this is the only remaining patch there: https://github.com/snapcore/snapd/pull/7632/commits/03ef1bd9b36c368c64c717879098f7fbe533c389
<mup> PR #7632: interfaces: de-duplicate emitted update-ns profiles <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>
<zyga> brb
<zyga> so cold and foggy today
<zyga> hot tea anyone?
<zyga> re
<zyga> pstolowski: thank you, replied to both
<zyga> kyrofa: hey, replied to https://github.com/nextcloud/nextcloud-snap/issues/913
<niemeyer> zyga: Did you review the PR?
<niemeyer> zyga: Good morning
<zyga> niemeyer: good morning
<zyga> niemeyer: I had a look at it, is there something wrong?
<niemeyer> Feels flimsy
<niemeyer> It broke because we're using awk to parse yaml
<zyga> I'm happy to rework it, let me look again
<niemeyer> The PR puts more shell to make more guesses about what the document happens to be
<niemeyer> Trivial to break it again
<zyga> sure, I'll make it less reliant on shell
<niemeyer> zyga: The proper fix is to not use awk or head to parse yaml
 * zyga had to help with the baby, back now
<zyga> niemeyer: yeah, I have an idea how to do that now
<niemeyer> Python would do
<niemeyer> Single command line.. python3 -c "import yaml"
<mborzecki> hmmm when a test suite is embedded in another test suite, and the first one has Test* funcs, shared tests are doubled when both suites are run
<pedronis> mborzecki: yes
<mborzecki> kind of expected when one things about it, but still a bit meh when doing a larger split
<pedronis> you really need to create a Base
<pedronis> of some kind
<pedronis> without tests
<mborzecki> s/things/thinks/
<pedronis> for the share fixture stuff
<pedronis> there are some examples
<pedronis> in the code base
<mborzecki> yeah, my concern is actually untangling devicemgr test suite
<mborzecki> tried to be 'smart' about it :/
<pedronis> mborzecki: if it's too onoreous you can always do it in two steps
<pedronis> just split tests across files but keep one suite
<pedronis> and do the suite splitting when it's less blocking
<mborzecki> pedronis: mhm, that's what i have now
<mborzecki> i suppose is good enough for now, at least the test file is no longer 4k+ lines
<pedronis> yes, we have some packages in that state
<pedronis> still better than too big test files
<pedronis> and can be improved
<Chipaca> 4k lines? them's rookie numbers!
<mborzecki> 8 files changed, 4699 insertions(+), 4516 deletions(-)
<mborzecki> heh
 * Chipaca looks at snapstate_test
<mup> PR snapd#7643 opened: overlord/devicestate: refactor and split into per-functionality files, drop dead code <Remodel :train:> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7643>
<Chipaca> hmmm
<zyga> niemeyer: yep, fixed locally, just running a quick check before pushing
<mborzecki> haha github decided it's not going to show diffs ;P
<zyga> are you seeing that too?
<zyga> for the past few days I had issues with diff pane
<zyga> it was just empty, apart from the typical github UI
<mborzecki> zyga: nah, the diffs are just too large in this PR
<Chipaca> #7643
<mup> PR #7643: overlord/devicestate: refactor and split into per-functionality files, drop dead code <Remodel ð> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7643>
<Chipaca> \o/
<mvo> mborzecki: 7640 is ready for a review
<zyga> niemeyer: updated now
<zyga> oops
<zyga> no permission to push
<zyga> niemeyer: opened https://github.com/snapcore/spread/pull/92
<mup> PR spread#92: tests: fix ad-hoc test <Created by zyga> <https://github.com/snapcore/spread/pull/92>
<mborzecki> pushed a really shallow suite split with common suite
<zyga> mborzecki: 8K diff
<zyga> mborzecki: very appropriate, 5K is passe
<niemeyer> zyga: Thanks! Let's see if it passes
<mborzecki> heh, go.mod broke gorename?
<zyga> niemeyer: it's green :)
<niemeyer> ... and it's in
<zyga> super! thank you
<zyga> niemeyer: this was a prelude to a change that does more than just fixes tests: https://github.com/snapcore/spread/pull/90
<mup> PR spread#90: runner: remove filterDir, default include to "." <Created by zyga> <https://github.com/snapcore/spread/pull/90>
<niemeyer> Reviewed
<zyga> niemeyer: the motivation behind this change is to eventually have "tar" invoked with project path and not the individual files and directories
<zyga> niemeyer: because that in turns allows us to say tar --exclude-vcs-ignore, which will automatically handle .gitignore
<zyga> niemeyer: there's an older branch that builds towards handling .gitignore: https://github.com/snapcore/spread/pull/89
<mup> PR spread#89: runner: pass --exclude-vcs-ignores to tar <Created by zyga> <https://github.com/snapcore/spread/pull/89>
<niemeyer> zyga: There are two different issues here:
<niemeyer> The first one is that spread is meant to send whatever files the project needs it to send, and also exclude whatever files it wants to to drop
<niemeyer> We cannot make assumptions about what the person using spread is actually trying to do with it
<niemeyer> But you as the spread user should be able to tune that list to your desires
<zyga> I agree, and therefore the idea is to allow users to configure spread to respect .gitignore-like files if they are present
<niemeyer> The second thing is that filterDir has a specific purpose. The PR dropped that purpose silently, and said nothing about it. That's usually a bad sign.
<niemeyer> zyga: The fact you want files to be ignored by git is not an indication that you want spread not to ship them
<zyga> niemeyer: did I miss the prupose? it is duplicated by how tar is invoked
<niemeyer> zyga: What is being done by filterDIr?
<zyga> niemeyer: we filter out spread-reuse files
<niemeyer> zyga: Maybe I'm the one missing it
<zyga> niemeyer: but this is redundant because the way spread invokes tar does that already
<zyga> niemeyer: it's not in the diff here because that part did not have to change
<niemeyer> zyga: I see now, sorry and thanks
<niemeyer> zyga: Let me play with it to see how it diverges if it all
<niemeyer> if at all
<zyga> niemeyer: thanks!
<zyga> niemeyer: I think this part is safe, it really is about working around a bug in tar
<zyga> niemeyer: tar needs to be shown the root of the project for it to consider .gitignore there (along with the required option to read it)
<zyga> niemeyer: separarely https://github.com/snapcore/spread/pull/91 can be closed now because it was a part of the branch you just merged
<mup> PR spread#91: tests: Fix adhoc test <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/91>
<niemeyer> zyga: So, the outcome is different indeed:
<zyga> oh?
<niemeyer> https://www.irccloud.com/pastebin/kb82VgAp/
<niemeyer> Weird..
<niemeyer> The pastebin corrupted line breaks
<zyga> is that different on the receiving end?
<niemeyer> Yeah, I suspect these paths are actually stored into the file
<niemeyer> Double checking
<niemeyer> https://www.irccloud.com/pastebin/bXQa7OJX/
<mup> PR snapd#7644 opened: gadget: rename existing and add new helpers for checking filesystem/partition presence <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7644>
<zyga> mborzecki: https://github.com/snapcore/spread/pull/85 needs master merge
<mup> PR spread#85: spread/client: workaround bash 4.3 subshell errexit issues <Created by bboozzoo> <https://github.com/snapcore/spread/pull/85>
<zyga> brbr, need tea
<zyga> we have a confusing spread system naming pattern
<zyga> imagine in 2064
<zyga> spread -debug -v google:ubuntu-core-64-64:
<pedronis> :)
<pedronis> it's non-problem until 2028, I mean we might want to clean it up, but I don't think we should do that now particularly
<Chipaca> ubuntu-core-64-128 \o/
<pedronis> I mean ubuntu-core-30-32  start to get confusing, otoh there might not be a 32 anymore at that point
<zyga> ;D
<zyga> I was totally joking btw
<zyga> Iza is back, made her some tea as well
<zyga> hmm
<zyga> mvo: did we do any changes to core/core16 recently?
<zyga> mvo: I'm seeing /system-data/etc/systemd/user added to host mount table
<zyga> or is the test flawed
 * zyga runs a small experiment
<mup> PR snapd#7636 closed: gadget, overlord/devicestate: add support for customized update policy, add remodel policy <Remodel ð> <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7636>
<zyga> listening to Parliament today, we should change our job titles to "due of snapd"
<zyga> "duke*"
<zyga> ah, I think I know why
<zyga> but it needs changes anyway
 * zyga small break
<mup> PR snapd#7645 opened: client: add xerrors and wrap errors coming from "client" <Created by mvo5> <https://github.com/snapcore/snapd/pull/7645>
<mvo> zyga: this got added iirc because of the user session service that was added recently
<zyga> mvo: that's excellent, thank you for confirming this
<zyga> mvo: reviewed https://github.com/snapcore/snapd/pull/7645#pullrequestreview-305827995
<mup> PR #7645: client: add xerrors and wrap errors coming from "client" <Created by mvo5> <https://github.com/snapcore/snapd/pull/7645>
<zyga> mborzecki: conflicts on https://github.com/snapcore/snapd/pull/7643
<mup> PR #7643: overlord/devicestate: refactor and split into per-functionality files, drop dead code <Remodel ð> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7643>
<mborzecki> ah damn, i expected the other PR to be in conflict
<zyga> ijohnson, mborzecki: can you please finish your review on https://github.com/snapcore/snapd/pull/7639
<mup> PR #7639: interfaces: emit update-ns snippets to function <Created by zyga> <https://github.com/snapcore/snapd/pull/7639>
<zyga> it will help to review the bugfix PR in the evening
<ogra> Chipaca, are you able to add categories in the forum ? i tend to think we should have a "multipass" one
<zyga> what the .... ?!?!
 * zyga looks closer
<ijohnson> zyga sure thing, I'll get on that right after breakfast and then SU
<zyga> thanks!
<zyga> WHAT THE ?!
<zyga> mvo: something changed drastically in core16
<zyga> mvo: do you have a sec?
 * Chipaca takes a break
<zyga> mborzecki: you won't believe what's in this commit message
<mup> PR snapd#7646 opened: tests: update mount-ns after addition of /etc/systemd/user <Created by zyga> <https://github.com/snapcore/snapd/pull/7646>
<zyga> mborzecki: please have a look, I think we need to understand what is going on
<zyga> note that core18 is okay
<zyga> it was not affected by whatever caused this
<mborzecki> zyga: one in 7646?
<zyga> I'm looking at anything merged to snap-confine
<zyga> yes
<zyga> mborzecki: for the purpose of staying honest I can split this into two patches
<zyga> but please read it first
<zyga> mborzecki: I strongly suspect it is a fallout from 4b4cf41fd17951157221f406e6f7a5bb5f2f6fff
<zyga> it probably was me not noticing the test didn't run
<zyga> I'll double check in a moment
<zyga> but I don't understand how this affects everything outside of /snap yet
<zyga> hmm, but I did change the data set there
<zyga> it cannot be that
<zyga> I cannot find anything that would explain this in changes since the 6th of September
<zyga> hmmmm
<zyga> maybe a false alarm
<zyga> I think I confused multiple runs together, I cannot reproduce this now, it must have been a run from the branch that enables sharing
<zyga> mborzecki: I think crisis averted
<mup> PR snapd#7644 closed: gadget: rename existing and add new helpers for checking filesystem/partition presence <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7644>
<mborzecki> do we intend to land #7642?
<mup> PR #7642: travis.yml: add 'sh -x' to run-checks <Created by mvo5> <https://github.com/snapcore/snapd/pull/7642>
<zyga> mborzecki: please look at the last comment on https://github.com/snapcore/snapd/pull/7643
<mup> PR #7643: overlord/devicestate: refactor and split into per-functionality files, drop dead code <Remodel ð> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7643>
<ahasenack> hi guys, all my snaps stopped working this morning, I get this message:
<ahasenack> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
<zyga> ahasenack: hello
<zyga> ahasenack: can you please provide the output of "snap version"
<ahasenack> zyga: hi, https://pastebin.ubuntu.com/p/fNNY5Fbk6t/
<zyga> ahasenack: can you please share the output of systemctl status apparmor.service
<ahasenack> zyga: https://pastebin.ubuntu.com/p/dcWgC4K2CV/
<ahasenack> sounds like I have an ordering problem in systemd services
<ahasenack> let me delete the zfskey one
<zyga> something is off
<zyga> can you paste the output of journalctl -u apparmor.service
<ahasenack> it's the same, but I now started it explicitly, and it worked
<ahasenack> zfskey-nsnx@nsnx.service/start is a systemd service I added recently, I'm guessing it has impossible targets/ordering
<ahasenack> snaps are working after I started apparmor
<zyga> thanks!
<zyga> good luck :)
<mvo> zyga: sorry, was at lunch
<zyga> mvo: no more crisis :)
<jdstrand> Saviq: fix, but...
<jdstrand> sergiusens (cc Saviq): hey, is snapcraft running the review-tools in travis/LP now?
<Saviq> o/ jdstrand
<mup> PR snapd#7641 closed: tests: moving ubuntu-19.10-64 from google-unstable to google backend <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7641>
<sergiusens> jdstrand: not yet, that is my next work item after I get some core20 stuff out of the way
<jdstrand> sergiusens: Saviq mentioned https://travis-ci.org/CanonicalLtd/multipass/jobs/601308279#L4750, which I was surprised to see
<sergiusens> jdstrand: line 55 and 59 from https://travis-ci.org/CanonicalLtd/multipass/jobs/601308279/config
<jdstrand> sergiusens: since there are probably some things we want to auto-block on, but others we do not (eg, it would be ok to let the store handle personal-files, for example)
<mup> PR snapd#7647 opened: gadget: skip structures with no partition table entry during remodel <Remodel ð> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7647>
<jdstrand> sergiusens: ah, ok. note ^ before enabling everywhere :)
<sergiusens> jdstrand: this was the contentious topic we did not reach an agreement on, we have no way to know what was whitelisted store side
<zyga> jdstrand: hello! :)
<jdstrand> sergiusens: right. so, you can give snap-review '--json' then read that and decide what to and what not to block on
<jdstrand> sergiusens: eg, you could choose to entirely skip declaration-snap-v2
<jdstrand> s/skip/ignore/
<jdstrand> zyga: hi :)
<zyga> jdstrand: I will have some things for you after the standup
<sergiusens> jdstrand: should we also --allow-classic if the snap is classic? Do the review-tools issue some output when that flag is used?
<Saviq> jdstrand: we're running it ourselves explicitly
<Saviq> but it's likely we're using it wrong :)
<jdstrand> Saviq: yeah, see that and now, you are fine, though you may want to set SNAP_ENFORCE_RESQUASHFS=0 for faster reviews
<jdstrand> sergiusens: you will probably want that ^ too, or at the very least a way to opt in/out of it
<Saviq> jdstrand: I just wonder if there's something we can do to make it pass with the new plugs? Does that talk to the store for assertions or?
<jdstrand> zyga: fyi, I will be looking at https://github.com/snapcore/snapd/pulls/review-requested/jdstrand this week
<jdstrand> Saviq: I issued the snap decl already. I said 'fix', I meant, 'I fixed it'
<Saviq> Ah! :)
<Saviq> ChrisTownsend: ^^
<jdstrand> Saviq: actually, I only fixed part of it
<zyga> jdstrand: thank you :)
<jdstrand> Saviq, ChrisTownsend: when it is uploaded to the store, it will now pass
<jdstrand> Saviq, ChrisTownsend: but not on your invocation of snap-review. gimme a sec for an updated invocation
 * ChrisTownsend reads backlog
<zyga> jdstrand: I prepared the apparmor memory fix in a way I believe can land after your reviews and some follow-ups for things like function names and typical iteration elements
<dot-tobias> zyga / jdstrand: Re the NetworkManager D-Bus Introspectable issue from yesterday (https://bugs.launchpad.net/snapd/+bug/1849291) â sorry for being impatient, but I need a rough timeframe when this will be available in core to decide if I should postpone the refactor in my snap until Introspectable is allowed in the network-manager interface. Let me know if I can be of any help!
<mup> Bug #1849291: Interface network-manager should grant access to org.freedesktop.DBus.Introspectable <papercut> <snapd:Confirmed> <https://launchpad.net/bugs/1849291>
<zyga> jdstrand: I included a memory usage test as well
<zyga> dot-tobias: I didn't manage to do it yesterday but I can propose a fix today
<zyga> dot-tobias: please ask mvo about release schedule for core / snapd
<dot-tobias> zyga: That would be marvelous, thank you! Will do
<mvo> dot-tobias: is there a PR for this issue yet?
<mvo> dot-tobias: (in a meeting so I may a bit slow replying)
<zyga> mvo: no, not yet, it's a small change to allow dbus introspection method on network manager that was missing before
<jdstrand> ChrisTownsend (cc Saviq): https://paste.ubuntu.com/p/RChQs4dkTQ/
<Saviq> jdstrand: ack, thanks!
<ChrisTownsend> jdstrand: cool, thanks!
<Saviq> jdstrand: in theory we could also download the snap declaration from the store, right? So that we can flag any changes necessary early?
<zyga> ijohnson: https://github.com/snapcore/snapd/pull/7547#issuecomment-545280953
<ijohnson> zyga: after reading your response that all makes sense
<mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
<zyga> cool, excellent :)
<pedronis> pstolowski: about that kind of code (loadSeed), you don't need to create the db either, you can pass nils to LoadAssertions, it's created there because the test wants to look at it
<ijohnson> zyga: re-approved
<zyga> ijohnson: woot, thanks!
<pstolowski> pedronis: ah, good, this just answered another dillema that i'd have, good
<pedronis> pstolowski: go doc Seed in seed should be helpful (it says this e.g.) hopefully
<pedronis> mvo: pstolowski: I'm touching that area again, how strongly would you like me to change the places we use cstr(s) for constraint(s) expanding them to the full word, I vaguely remember you commented on this at some point
<zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/7646
<mup> PR #7646: tests: update mount-ns after addition of /etc/systemd/user <Created by zyga> <https://github.com/snapcore/snapd/pull/7646>
<cachio> degville, hey
<cachio> degville, I am free, just ping me when you have time
<degville> cachio: hello!
<cachio> ah, you already sent the app
<cachio> perfect
<mup> PR snapd#7579 closed: interfaces/net-setup-{observe,control}: add Info D-Bus method accesses <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7579>
<degville> cachio: ok, cool! I was just going to say maybe 5 mins because I'm eating a bowl of sauerkraut :)
<sergiusens> pedronis, mvo: would be nice to see some UX improvements on mandatory interfaces so every snap does not have to reimplement the wheel (which would bring wrappers into play again) https://forum.snapcraft.io/t/missing-shared-library-for-digikam/13674
<cachio> degville, hehe
<zyga> jdstrand: can you read the topic of the bug on https://bugs.launchpad.net/snapd/+bug/1849291 and comment if that's something that should be fixed
<mup> Bug #1849291: Interface network-manager should grant access to org.freedesktop.DBus.Introspectable <papercut> <snapd:Confirmed> <https://launchpad.net/bugs/1849291>
<zyga> jdstrand: the fix is simple and I can handle that today
<ijohnson> zyga: also approved #7639
<mup> PR #7639: interfaces: emit update-ns snippets to function <Created by zyga> <https://github.com/snapcore/snapd/pull/7639>
<zyga> ijohnson: excellent, thank you
<zyga> I will review comments and open follow-ups
<pstolowski> pedronis: not super critical imho.. and there is a lot of those. i think it's better if your changes re greedy plugs are only about the new functionality, not renaming
<pedronis> pstolowski: ok, I would have done them separately, not mixed
<mup> PR snapd#7639 closed: interfaces: emit update-ns snippets to function <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7639>
<pedronis> just gauging how annoying people find the current status
<pedronis> I might just change things in policy because it might make the new code clearer
<pedronis> and leave asserts alone for now
<mborzecki> zyga: heh so we actually had user.conf.d for overriding the user session manager but didn't have /etc/systemd/user/ ?
<jdstrand> Saviq: re download> you could, but it is in a modified yaml format so you would have to parse/translate it to json
<zyga> mborzecki: yes
<zyga> ;D
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/7632 is ready from my POV
<mup> PR #7632: interfaces: de-duplicate emitted update-ns profiles <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>
<mborzecki> well, at least it's accounted for now
<oSoMoN> jdstrand, not sure whether this has been reported in the past: bug #1848919 , the home interface prevents access to ~/.Private, is there anything that can be done about it without compromising security?
<mup> Bug #1848919: [snap] Permission denied on Private encrypted folder <chromium-browser (Ubuntu):Confirmed> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1848919>
<zyga> ijohnson: https://github.com/snapcore/snapd/pull/7632 needs a re-review from you, I believe the concern you had was addressed
<mup> PR #7632: interfaces: de-duplicate emitted update-ns profiles <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>
<ijohnson> yes I'm re-reviewing it as we speak :-)
<zyga> super, thank you! :)
<mup> PR snapd#7648 opened: interfaces/policy: expand cstrs/cstrs1 to altConstraints/constraints <Simple ð> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7648>
<pedronis> pstolowski: ^
<pstolowski> pedronis: that's not too bad, i thought there were more. thanks
<pedronis> pstolowski: not in policy
<pedronis> there's a ton in asserts/ifacedecls*.go
<pedronis> that's a bit more work, will leave it alone for now
<pstolowski> pedronis: +1
<jdstrand> zyga: commented
<jdstrand> oSoMoN: I responded in the bug
<Saviq> jdstrand: while we have a direct line with you ;), would you please allow auto-connection for kvm, network-control and firewall-control?
<oSoMoN> jdstrand, thanks, I'll reproduce in a VM and will post the denial
<Saviq> jdstrand: if you'd rather us go through the forum, just say so
<jdstrand> Saviq: normally, yes, but this has been discussed previously, so I'll just make sure the reviewers are aware I did it
<jdstrand> Saviq: cone
<jdstrand> done*
<Saviq> jdstrand: thanks!
<zyga> jdstrand: thanj you
<mup> PR snapcraft#2763 opened: "snap debug validate-seed" fails if the slot is specified in the default-provider <Created by kenvandine> <https://github.com/snapcore/snapcraft/pull/2763>
<zyga> Saviq: as for the multipass category, if this is more popular as a theme, perhaps we should have a snap:multipass category instead, to indicate that this is a topic for a particular snap
<Saviq> it's really more about snapcraft's use of Multipass there, so maybe a tag is more appropriate
<oSoMoN> jdstrand, I commented on the bug with the denial I'm seeing
 * zyga goes for lunch
<zyga> Saviq: ah, I see
<mvo> pedronis: I think 7626 is ready for another review, I think I addressed the points you raised
<joedborg> morning all!  if anyone could cast their eyes on https://forum.snapcraft.io/t/fatal-python-error-py-initialize-unable-to-get-the-locale-encoding/13844 (TLDR, getting a python error with snapcraft), it'd be great
<mvo> pedronis: also it looks like the following change broke the seeding of gnome-calculator https://paste.ubuntu.com/p/BJBBRkdcRQ/ - their snap is now adding something like  default-provider: gnome-3-28-1804:gnome-3-28-1804 and our validate-seed seems to break on this :/
<pedronis> mvo: ?
<pedronis> it's our change, no?
<pedronis> default-provider is not a slot or  a plug
<pedronis> what are they trying to do?
<mvo> dot-tobias: uh, I think I did not get back to you about this bug we talked earlier. sorry for that. if its a trivial fix we could pull it in
<mvo> pedronis: I don't know, its apparently snapcraft adding this
<pedronis> mvo: the gnome extension thingy?
<mvo> pedronis: in the kde and gnome plugsin
<mvo> pedronis: yeah
<pedronis> well, is not a snapd bug
<mvo> pedronis: I need to look at the code, I think we allowed ":" there for histric reasons
<pedronis> ?
<mvo> pedronis: sorry, I will dig into this myself, the information I have is that building an image is currently failing withhttps://launchpadlibrarian.net/447954589/buildlog_ubuntu_focal_amd64_ubuntu_BUILDING.txt.gz
<mvo> pedronis: https://launchpadlibrarian.net/447954589/buildlog_ubuntu_focal_amd64_ubuntu_BUILDING.txt.gz
<mvo> pedronis: and I had a quick look and noticed the default provider changed in the snap
<mvo> pedronis: now I need to remember things about this :/
<pedronis> mvo: ok, yes
<pedronis> we have two form of code
<pedronis> we have a bit too many pieces of code extracting default providers
<pedronis> mvo: we have this:  https://github.com/snapcore/snapd/blob/master/overlord/snapstate/snapstate.go#L490
<mup> PR snapd#7649 opened: overlord: fix TestRemodelSwitchToDifferentKernel for bootvars <Created by mvo5> <https://github.com/snapcore/snapd/pull/7649>
<pedronis> and this: https://github.com/snapcore/snapd/blob/master/snap/validate.go#L957
<pedronis> they don't do the same thing
<pedronis> mvo: we have a 3rd as well
<mvo> pedronis: hrm, hrm, sounds like a good target for unification - oh well
<mvo> pedronis: I try to have a look today
<kenvandine> mvo: does this mean the kde snaps aren't working the way they think they are?
<kenvandine> if the slot is being stripped...
<pedronis> mvo: https://github.com/snapcore/snapd/blob/master/overlord/ifacestate/handlers.go#L698
<pedronis> it's not a slot
<pedronis> / The default-provider is a name. However old
<pedronis> 				// documentation said it is "snapname:ifname",
<pedronis> 				// we deal with this gracefully by just
<pedronis> 				// stripping of the part after the ":"
<pedronis> of course only one place in our code does that, so there might be wobblyness anyway
<kenvandine> yeah, but the kde snaps are trying to connect a plug with a different name than the slot
<kenvandine> in the default-provider
<pedronis> that's not a thing
<kenvandine> what they are doing might not really work...
<pedronis> usually what happens is that the default-provider kicks in
<pedronis> and then auto-connection does its job
<pedronis> that's kind of the only way it works
<pedronis> s/kicks in/gets installed/
<pedronis> mvo: our docs still says this:  default-provider (plug): name and slot of preferred providing snap (<SNAP>:<SLOT>)
<pedronis> but we never implemented that
<pedronis> funny
<kenvandine> i'm saying the kde snaps are including the slot in the default-provider, and that slot name isn't the same as the plug name
<pedronis> kenvandine: apparently it's documented
<pedronis> but even I was not aware of that
<kenvandine> plug=kde-frameworks-5-plug has default-provider = kde-frameworks-5-core18:kde-frameworks-5-core18-slot
<pedronis> and as far as I know, it never was implemented like that
<pedronis> you need mvo and zyga to tell you more
<kenvandine> ok
<pedronis> kenvandine: see this post by Gustavo: https://forum.snapcraft.io/t/the-snapd-roadmap/1973/9
<pedronis> which doesn't match the doc
<kenvandine> the seed validation are failing for something that's documented :)
<pedronis> and doesn't work as documented
<pedronis> and wasn't implemented as documented
<kenvandine> indeed
<pedronis> it's kind of a pain to implement it as documented actually
<pedronis> so I don't see it get it fixed quickly
<pedronis> to work as originally documented
<pedronis> we can fix it quickly to ignore in more places
<pedronis> kenvandine: I would like to understand if the feature is really needed
<pedronis> it's not been there in that form
<pedronis> ever
<kenvandine> pedronis: i not really concerned to much about the feature
<om26er> is there a way to expose an environment variable from one snap to another ? think snap A exposing what port snap B should connect to it on
<kenvandine> the issue is the extension includes the slot in the default-provider and it is now breaking iso builds
<pedronis> kenvandine: I understand
 * zyga breaks for an hour
<zyga> or two
<pedronis> kenvandine: we can fix snapd to ignore it, but I think the extension should stop to add the slot
<pedronis> at some point soon
<zyga> need to go while there's some sunlight still
<pedronis> and we need to do something about the doc
<pedronis> om26er: not unless an interface is involved, all snaps to snaps relations should be via interfaces
<zyga> om26er: this can be done via interface hooks, as a part of the post-connection "those are the attributes" phase for example
<zyga> om26er: but as pedronis said it must be modeled as an interface
 * zyga really AFK
<ijohnson> hmm I can't seem to restart travis jobs anymore
<ijohnson> can someone restart https://travis-ci.org/snapcore/snapd/jobs/601379249 for me? it failed due to store problems
 * cachio lunch
<pedronis> ijohnson: done
<ijohnson> thanks pedronis
<mup> PR snapcraft#2764 opened: Snapd doesn't actually honor the slot specified in the default-provider <Created by kenvandine> <https://github.com/snapcore/snapcraft/pull/2764>
<mvo> team: 7595 needs a second review, would unblock some uc20 work (maybe ijohnson?)
<ijohnson> mvo: ok I can take a look in my afternoon
<mvo> ijohnson: great, thank you!
<ogra> mvo, oh, 1849515 is an interesting one ... on zfs installs seemingly /var(snap becomes a mounted zpool so rm'ing it from the postinst seems to fall over
<ogra> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1849515
<mup> Bug #1849515: package snapd (not installed) failed to install/upgrade: Â»installiertes snapd-Skript des Paketes post-removalÂ«-Unterprozess gab den Fehlerwert 1 zurÃ¼ck <amd64> <apport-package> <focal> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1849515>
<sil2100> mvo: hey! Could you sign-off formally on the UC20 u-i image spec if you have a moment? ;)
<jdstrand> oSoMoN: one more question in the bug
<Saviq> harr harr harr https://imgur.com/a/bRb6M1T
<oSoMoN> jdstrand, replied
<mup> PR snapd#7638 closed: interfaces/u2f-devices: add OnlyKey to devices list <Created by onlykey> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7638>
<kenvandine> jdstrand: gnome-nibbles was getting rejected due to symlink issues.  I've fixed them and now it's rejected for the dbus slot... which isn't new
<mup> PR snapd#7631 closed: interfaces/pulseaudio: adjust to manually connect by default <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/7631>
<kenvandine> jdstrand: oh... maybe it's because the case changed :)
<mup> PR snapcraft#2765 opened: remote-build: initial Windows support <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2765>
<mup> PR snapcraft#2759 closed: remote-build: https token support <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2759>
<mup> PR snapcraft#2762 closed: appstream: extract title and version <Created by galgalesh> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2762>
<mvo> ogra: thank you! we have a look, we just discussed this in our standup and we will add a 19.10 zfs machine to spread
<jdstrand> kenvandine: it is the case change. I adjusted and it is passing now
<kenvandine> thanks, i forgot when i bumped the version a few weeks ago i had to change the case
<mup> PR snapcraft#2752 closed: errors: migrate handful of errors to SnapcraftException <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2752>
<mup> PR snapcraft#2758 closed:  appstream: support legacy ids without desktop suffix  <Created by galgalesh> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2758>
<mup> PR snapcraft#2747 closed: nodejs plugin: fix errors when building in confinement <Created by NickZ> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2747>
<mup> PR snapcraft#2672 closed: docker: use apt-get to avoid warnings <Created by abitrolly> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2672>
<mup> PR snapcraft#2757 closed: Drop build_base check from make plugin. It is universal <Created by xnox> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2757>
<mup> PR snapcraft#2699 closed: python plugin: add option to process-pipfile-lock for pipenv users <Created by cjp256> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2699>
<zyga> re
<zyga> I'm doing homework with kids but I'll do an evening pass and fix one more bug
<zyga> jdstrand: is there anything I should look at from your point of view?
<jdstrand> zyga: atm I am focusing on store reviews. it may be tomorrow when I look at it, so enjoy your eod :)
 * cachio afk
<zyga> jdstrand: understood, enjoy your evening as well :)
<zyga> jdstrand: :-)
<xnox> sergiusens:  why was https://github.com/snapcore/snapcraft/pull/2757 closed, but not merged? did i do something wrong?
<mup> PR snapcraft#2757: Drop build_base check from make plugin. It is universal <Created by xnox> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2757>
<sergiusens> xnox: my comment mentions I implemented it in that other PR... the plugin is not really universal, it depends on an apt based system so having the explicit check is fine
<xnox> sergiusens:  make package is called make in rpm distros too
<xnox> sergiusens:  so which PR should I look at?
<xnox> sergiusens:  or which commits on master?
<sergiusens> xnox: does "apt install make" work on RPM distros?
<xnox> sergiusens:  obviously not =) but "yum install make" does. Reading the plugin, I got fooled that "pkg install make" works on things other than apt too =)
<xnox> sergiusens:  i see core20 in https://github.com/snapcore/snapcraft/pull/2761/files#diff-c6b5575f0de40006219f3af3804ec78eR92 now, so yeah, that's fine
<mup> PR snapcraft#2761: Core20 base <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2761>
<xnox> it's just it's not merged. Can you build that PR and publish it to a channel like edge/pr2761 ?
 * xnox ponders if all PRs should be autobuilt and autopublished to edge/pr*
<sergiusens> xnox: that would be ideal, but we cannot get attenuated macaroons yet for a channel glob like edge/pr-* so the builder would have too much access
<xnox> ture
<xnox> true
<mup> PR snapcraft#2766 opened: project: truncate project directory hash <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2766>
#snappy 2019-10-24
<mborzecki> morning
<mborzecki> google:ubuntu-18.04-64:tests/main/uc20-snap-recovery seems to fail randomly
<mup> PR snapd#7650 opened: o/ifacestate: unify code into autoConnectChecker.addAutoConnections <Created by pedronis> <https://github.com/snapcore/snapd/pull/7650>
<mup> PR snapd#7651 opened: asserts: support and parsing for slots-per-plug/plugs-per-slot <Created by pedronis> <https://github.com/snapcore/snapd/pull/7651>
<pedronis> mborzecki: hi, should we disable temporarely google:ubuntu-18.04-64:tests/main/uc20-snap-recovery it seems indeed flaky
<mborzecki> pedronis: i'll try to find out what's going on there
<pedronis> ok
<mborzecki> pedronis: can you take a look at https://github.com/snapcore/snapd/pull/7643 ? should be easy to land, it's just moving the code around into separate files
<mup> PR #7643: overlord/devicestate: refactor and split into per-functionality files, drop dead code <Remodel ð> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7643>
<pedronis> mborzecki: yes, finishing something else and then I will look
<mborzecki> pedronis: cool, thank you
<pstolowski> morning
<zyga> Hey
<zyga> Overslept
<zyga> Including kids
<zyga> Sorting out stuff
<mborzecki> hey guys
<mvo> hey mborzecki
<mborzecki> mvo: quick question about uc20-snap-recovery test, lsblk is wrapped by retry-tool, the comment says it's a race with udev, i've also seen it fail randomly in the travis runs
<mborzecki> mvo: the race is in udev noticind the new partitions and creating device nodes, while lsblk picks them up, right?
<mup> PR snapd#7652 opened: o/ifacestate,interfaces,interfaces/policy: slots-for-plug: * <Created by pedronis> <https://github.com/snapcore/snapd/pull/7652>
<mvo> mvo: yeah, I think so, we could call udevadm I guess
<mvo> mborzecki:
<mvo> mborzecki: I'm doing a spread run right now to validate this
<pedronis> mvo: all greedy plugs PRs are up now
<mvo> pedronis: \o/
<pedronis> pstolowski: hi, I asked you a review in #7650, that's definitely an area you worked on/touched
<mup> PR #7650: o/ifacestate: unify code into autoConnectChecker.addAutoConnections <Created by pedronis> <https://github.com/snapcore/snapd/pull/7650>
<pstolowski> pedronis: sure, will do
<pedronis> thx
<mborzecki> mvo: heh, obviously spread -repeat=20 did not catch this
<mborzecki> mvo: repeated that a couple of times, same thing
<mborzecki> mvo: wonder if maybe there's some cross test interaction after all
<mvo> mborzecki: could be, I can also just mount the partitions directly in the test and not rely on lsblk
<mborzecki> mvo: hm, otoh, the nodes under /dev are created by the kernel now
<mborzecki> mvo: not all though, but /dev/loop*p* probably is
<pedronis> it failed again fwiw also in 7650
<mvo> meh, I change from lsblk to mount for now
 * mvo does that right away
<mvo> sorry guys
<mborzecki> pedronis: restarted the job in 7650, there's nothing new in the log, tests that ran earlier don't seem to be related
<mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/7647 ?
<mup> PR #7647: gadget: skip structures with MBR role during remodel <Remodel ð> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7647>
<pedronis> mborzecki: reviewed #7643
<mup> PR #7643: overlord/devicestate: refactor and split into per-functionality files, drop dead code <Remodel ð> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7643>
<mborzecki> pedronis: thanks! i think we could return to making the split nicer once gadget remodel (and maybe base remodel) land
<pedronis> yea, I would also like to clean up some stuff in managers_test.go but yes, after more remodel stuff lands seems the right call
<pstolowski> mborzecki: sure
<mborzecki> zyga: tiny suggestion under https://github.com/snapcore/snapd/pull/7623 also the test caught something
<mup> PR #7623: tests: check world-writable and test-owned files <Created by zyga> <https://github.com/snapcore/snapd/pull/7623>
<mborzecki> zyga: probably needs a master merge too
<zyga> mborzecki: tests caught real bug, it is discussed in the PR
<mup> PR snapd#7653 opened: tests: do not use lsblk in uc20-snap-recovery test <Created by mvo5> <https://github.com/snapcore/snapd/pull/7653>
<mborzecki> mvo: left a little comment https://github.com/snapcore/snapd/pull/7653#discussion_r338436144
<mup> PR #7653: tests: do not use lsblk in uc20-snap-recovery test <Created by mvo5> <https://github.com/snapcore/snapd/pull/7653>
<mvo> mborzecki: oh, nice! we probably want both, i.e. know we can mount it but also get all this nice information that file provides
<mborzecki> mvo: surprisingly there's not that many methods for probing the fs type of a block device :/
<mvo> mborzecki: yeah, I'm also puzzled why lsblk is not reliable, I try to look at the code of lsblk
<mborzecki> Chipaca: updated my old store-url branch
<mborzecki> Chipaca: will be pushing that out soonish
 * zyga -> tea
<Chipaca> mborzecki: neat
<mborzecki> Chipaca: hm haven't added it to aux info though, we have a website and media list there
<dot-tobias> jdstrand: Ping re https://bugs.launchpad.net/snapd/+bug/1849291/comments/2 â can I be of any help to get this into snapd soon(ish)? Sorry for nagging, but our snap pipeline is currently blocked for pressing updates, I'd need to revert a slew of NM-related changes or cherry-pick to another build branch until core allows Introspectable access for NM.
<mup> Bug #1849291: Interface network-manager should grant access to org.freedesktop.DBus.Introspectable <papercut> <snapd:Confirmed> <https://launchpad.net/bugs/1849291>
<dot-tobias> (Note to self: Don't assume NM access works on Core when working fine on Classic desktop ð)
<mup> PR snapd#7654 opened: cmd/snap, store: include snapcraft.io page URL in snap info output <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7654>
<mborzecki> Chipaca: ^^
<Chipaca> mborzecki: yeah that'd be better,but could be a follow-up
<ijohnson> pedronis, mvo sorry for not getting to #7595 yesterday, but I'm looking at it now, is there a design doc for the things there I should be looking at it? is the model assertion doc the only thing?
<mup> PR #7595: seed/seedwriter: support writing Core 20 seeds (aka recovery systems) <Created by pedronis> <https://github.com/snapcore/snapd/pull/7595>
<pedronis> ijohnson: there's that and there's a picture from a sprint, let me turn it into a doc quickly
<ijohnson> ok thanks
<ijohnson> also could someone restart https://travis-ci.org/snapcore/snapd/jobs/601379249 again for me? it failed on store 403s again :-/
<Chipaca> ijohnson: done
<ijohnson> \o/
<Chipaca> ijohnson: you don't have travis permission to restart?
<ijohnson> I used to but it went away yesterday, I am still a GitHub member of snapcore but Travis doesn't think so anymore
<Chipaca> ijohnson: maybe you need to log back in?
<ijohnson> hmm I could try clearing the cache too I suppose
<Chipaca> heh
<ijohnson> signing out and back in doesn't do anything unfortunately
<Chipaca> i recently got told to clear all my cookies to debug some website
<Chipaca> "hahaha no"
<ijohnson> "ALL your cookies are belong to us now"
<Chipaca> there's so much state in dem biscuits
<ijohnson> huh well now it works when I go sign in fresh to another browser
<mborzecki> quick errand, back in 30
<ijohnson> also Chipaca does the meeting time I sent out today work for you?
<Chipaca> ijohnson: both of 'em work :-) but yes
<Chipaca> ijohnson: i didn't check, is pedronis also there?
<ijohnson> Chipaca yes and pedronis accepted the most recently sent invitation
<Chipaca> ijohnson: are you saying i should actually click accept on the invite
<Chipaca> psh
<Chipaca> RSVPs is for frenchies
<ijohnson> next time I'll mail you a physical invite so you can't decline it
<Chipaca> you underestimate my power
<Chipaca> can I enjoy some schadenfreude over the "FIREFOX UPDATED WITHOUT MY KNOWLEDGE AND STOPPED RESPONDING THIS IS TERRIBLE WILL YOU PLEASE FIX IT oh wait it was the apt version never mind" thing
<mborzecki> re
<mup> PR snapd#7655 opened: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7655>
<zyga> dot-tobias: ^
<mup> PR snapd#7646 closed: tests: update mount-ns after addition of /etc/systemd/user <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7646>
<mup> PR snapd#7643 closed: overlord/devicestate: refactor and split into per-functionality files, drop dead code <Remodel ð> <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7643>
<mup> PR snapd#7656 opened: tests: verify host is not affected by mount-ns tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7656>
<Chipaca> zyga: pstolowski: is either of you aware of / working on #1848516 and #1849564 ?
<mup> Bug #1848516: snap connections/interfaces shows dropped interfaces as connected after refresh <snapd:New> <https://launchpad.net/bugs/1848516>
<mup> Bug #1849564: snap connections doesn't work as expected when interface attributes change <snapd:New> <https://launchpad.net/bugs/1849564>
<zyga> Chipaca: I'm aware of the first one, working on neither
<zyga> checking the second one
<Chipaca> mvo: with the pulsaudio transition in progress, these bugs are going to bite
<Chipaca> zyga: variation thereof
<mvo> Chipaca: uh, thanks for raising this
<Chipaca> zyga: you commented on this, so I ask you: what other projects have bugs for us? I'm adding them all to the triage doc
<zyga> Chipaca: that's a great question, let me think
<ijohnson> yassss finally silly spread tests passed
<mup> PR snapd#7597 closed: overlord/snapstate: add LastActiveDisabledServices, missingDisabledServices <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7597>
<Chipaca> zyga: I'm stepping outside for a while, feel free to edit the doc :-) hopefully it makes sense wrt where to add
<zyga> Chipaca: I will
<zyga> enojy
<zyga> enjoy*
<zyga> pstolowski: we should look at those connections bugs
<zyga> pstolowski: let me wrap something up first though
<zyga> I see some searching and apt-hooks failures
<pstolowski> zyga: interesting, I will investigate later today
<zyga> 403 store side
<mvo> I see a bunch of (random?) systemctl restart systemd-journald.service failures. anyone  else is seeing this in the tests?
<ijohnson> mvo: yes I see this constantly
<ijohnson> cachio has a PR which should fix this
<zyga> snap recovery failures
<zyga> mvo: all the time
<mvo> zyga: I'm trying to fix those
<zyga> mvo: as in every day for as long as I can remember
<zyga> mvo: thank you so much
<mvo> zyga: but now I see failures in the other ones
<mvo> zyga: so I can't land my fix :/
<ijohnson> mvo: https://github.com/snapcore/snapd/pull/7605 is what cachio had to fix that I think
<zyga> reliability of the test suite is such an important part of snapd
<mup> PR #7605: tests: configure the journald service for core systems <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7605>
<mvo> zyga: 7653 fwiw
<ijohnson> mvo: you always see it in ubuntu-core right?
<ijohnson> or elsewhere?
<ijohnson> I always only see it on ubuntu core
<mvo> ijohnson: correct
<mvo> ijohnson: lookng now
<mvo> ijohnson: the PR from sergio needs a core update to writable path or some other mean to set this :/
<ijohnson> ah darn, is there anyway we could hack around that?
<pstolowski> zyga: i suspect a problem around reloadConnections, afair it is not robust enough. Iâll check later, need to wrap up first pare-Bakun PR
<zyga> mvo: assuming https://bugs.launchpad.net/snapd/+bug/1849291 is fixed now, should it be targeting 2.43?
<mup> Bug #1849291: Interface network-manager should grant access to org.freedesktop.DBus.Introspectable <papercut> <snapd:In Progress by zyga> <https://launchpad.net/bugs/1849291>
<pstolowski> *pre-bake
<zyga> some old milestones on launchpad ought to be closed
<zyga> I'll do that
<zyga> yay
<zyga> two milestones left
<zyga> mvo: and if so, what is the estimated release for 2.42 and 2.43?
<zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/7614
<mup> PR #7614: cmd/snap-confine: implement snap-device-helper internally <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>
<mup> PR snapd#7585 closed: spread.yaml: drop exclude list, use .gitignore <â Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7585>
<zyga> It'd like to start moving this forward a little
<mup> PR snapd#7657 opened: snap: fix default-provider in seed validation <Created by mvo5> <https://github.com/snapcore/snapd/pull/7657>
<mvo> ijohnson: is the restart issue only happening on core18?
<mvo> ijohnson: or did you see it on core16 as well?
<zyga> mborzecki: also https://github.com/snapcore/snapd/pull/7656 is very simple and could land soon
<mup> PR #7656: tests: verify host is not affected by mount-ns tests <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7656>
<zyga> mvo: I saw this issue (journal service restart) on pretty much all systems, but this is an unscientific assertion]
<ijohnson> mvo: pretty sure I've seen it on core16 as well
<mvo> ijohnson: yeah, I'm just going over the last couple of failures and there it is
<pedronis> I remember I have a note about the fact that we should simply drop some connections
<pedronis> on refresh
<mvo> ijohnson: let me see if I can fix sergios pr
<zyga> core 20 recovery fails
<zyga> is that fixed or shall we disable it
<zyga> pedronis: yes, we never implemented transitions in any way, where a snap can rename a plug or slot or actual dropping of a plug or slot where that is removed from the state
<zyga> I need some coffee, it's such a sleepy day
<zyga> sorry, brb
<dot-tobias> zyga, jdstand, mvo: Hearty thank you for the fast help + fix re: NM Introspectable! One more thing to look forward to in the 2.43 release ð
<dot-tobias> *jdstrand ^
<mvo> ijohnson: I pushed a PR to core
<mup> PR core#109 opened: extra-file: make /etc/systemd/journald.conf.d writable <Created by mvo5> <https://github.com/snapcore/core/pull/109>
<ijohnson> ack mvo will take a look today then
<zyga> dot-tobias: a pleasure :)
<zyga> mvo: once that lands I need to adjust mount-ns test to compensate
<mup> PR snapd#7658 opened: cmd/snap-start-pressing: add snap-start-preseed executable (1/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/7658>
<mborzecki> pedronis: i've updated https://github.com/snapcore/snapd/pull/7630
<mup> PR #7630: overlord/devicestate: check snap handler for gadget remodel compatibility <Remodel ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7630>
<pstolowski> ijohnson: hey, 7431 has conflicts
<pedronis> mborzecki: addd to my queue
<mborzecki> thx!
<ijohnson> pstolowski: yes I finally just merged the dependent one, will resolve asap after my meetings this morning
<mborzecki> Chipaca: pushed changes to aux data too
<Chipaca> mborzecki: reviewed changes to aux data too
<mborzecki> Chipaca: cool, thanks!
<mborzecki> Chipaca: something i haven't checked, when is the aux info refreshed? bc if the store were to change the urls for any reason, would this end up being out of date?
<Chipaca> mborzecki: currently it's bumped on refresh, although my plan is to do it on checking for refreshes also
<mborzecki> Chipaca: so it should be fine then
<Chipaca> mborzecki: that is: the refresh action fetches a bunch of data that we currently completely ignore for snaps that aren't actually refreshed, but that can and should change
<Chipaca> mborzecki: we need to run the numbers but it's quite possible it'll be less expensive to get minimal data on refresh, and do separate info calls for what actually changed
<Chipaca> but that's something to do when we have free time
 * Chipaca looks at work mapped out to 2040
<Chipaca> â¦ yeah, someday
<ogra> is there a forum thread so we can put our wishlist items on your 2040 schedule ?
<pedronis> ogra: ?
<ogra> pedronis, i was reacting to Chipaca's snarky joke :)
<pedronis> ah
<ogra> didnt mean to scare you :)
<Chipaca> snarky? me?!?
 * zyga goes for lunch
<mup> PR snapd#7653 closed: tests: do not use lsblk in uc20-snap-recovery test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7653>
<mvo> mborzecki: 7640 is ready for a second review
<ogra> jdstrand, the new daemon user is hardcoded to "snap_daemon" ? (i.e. i can not set a random username here ?)
<ijohnson> ogra: yes
<joedborg> morning all! I've been seeing some odd snapcraft errors since late last week.  They seem to point at missing libraries, but I get different results part to part and for different libraries.  Could anyone lend their eyes please?  It's blocking some work.
<jdstrand> ogra: you may only use snap_daemon at this time
<Chipaca> joedborg: maybe #snapcraft ?
<Chipaca> joedborg: or are they snapd-related?
<joedborg> thanks, i'll try there. i guess it's snappy as it's happening at build time
<mborzecki> off to pick up the kids
<jdstrand> dot-tobias: it might make sense to verify the changes in that PR are enough to solve your issue. the way to do that would be a) install the two snaps b) in /var/lib/snapd/apparmor/profiles/snap.network-manager.networkmanager add the receive rule from the PR, substituting the plug's name (eg, snap.mirros-one.hook.post-refresh)
<jdstrand> dot-tobias: c) in /var/lib/snapd/apparmor/profiles/snap.mirros-one.hook.post-refresh add the send rule from the PR, substituting the slot's name (eg, snap.network-manager.networkmanager)
<jdstrand> dot-tobias: d) load the profiles into the kernel with: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.network-manager* /var/lib/snapd/apparmor/profiles/snap.mirros-one*
<zyga> re
<zyga> hello jamie :)
<zyga> I'll push forward with bugfixes tonight
<zyga> (spread permitting, sigh)
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/7655 updates as requested
<mup> PR #7655: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7655>
<doko> sergiusens: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/u/ubuntu-image/20191022_062343_f039f@/log.gz
<doko> this needs updating for 20.04?
<doko> mvo: ^^^ ?
<mvo> doko: looks like it, yes - sergiusens will have a look, he is in a meeting right now
<sergiusens> doko: I worked that out on #ubuntu-release already, or is this a trigger after that?
<doko> sergiusens: is it already fixed?
<mup> PR core#109 closed: extra-file: make /etc/systemd/journald.conf.d writable <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/109>
<sergiusens> doko: a retrigger should fix it if sil2100 or infinity haven't done so yet
<sergiusens> doko: I reported my side of the fix one hour and 20 minutes ago on #ubuntu-release ... I cannot retrigger tests for ubuntu-image
<mvo> zyga, cachio new core with fix for journal.d is building
<cachio> mvo, perfect
<jdstrand> zyga: hi and thanks!
<zyga> mvo: thank you, I will prepare the fix for mount-ns test
<pedronis> pstolowski: I skimmed the preseed PR,  it looks good overall, my main comment will probably be naming related
<pstolowski> pedronis: ty!
<sil2100> mvo: hello! Once you find a few cycles today, could you formally sign-off on the uc20 u-i spec in the doc? ;)
<sil2100> Since I'm getting poked about that constantly, especially now that I want to land the changes
<mvo> sil2100: yes, today is meeting crazy, I try
<sil2100> mvo: thank you!
<pedronis> mvo: I made a suggestion comment in #7649
<pedronis> related to what we discussed
<mvo> pedronis: thank you!
<mup> PR #7649: overlord: fix TestRemodelSwitchToDifferentKernel for bootvars <Created by mvo5> <https://github.com/snapcore/snapd/pull/7649>
<pedronis> sil2100: mvo: I could probably look at it an sign it off instead of mvo if that helps
<mvo> pedronis: that would be great
<mvo> pedronis: *if* you have some minutes, but hopefully straightforward
<mvo> mborzecki: any news on the f30 xerrors backport?
<mborzecki> mvo: nope, filed a ticket, pinged the guy irc, but haven't heard back
<sil2100> pedronis: I'd be +1 on that too ;)
<ijohnson> pedronis: left an initial review on #7595, need to finish reviewing the tests in a followup review I will submit later this morning
<mup> PR #7595: seed/seedwriter: support writing Core 20 seeds (aka recovery systems) <Created by pedronis> <https://github.com/snapcore/snapd/pull/7595>
<pedronis> sil2100: I made two additions, as suggestions, do they match our last understanding
<pedronis> ?
<sil2100> pedronis: yes, approved those o/
<sil2100> Thanks for adding them
<pedronis> ijohnson: thanks, I'll answer some of your questions in my morning
<ijohnson> sounds good, have a nice evening (also I scheduled a meeting with you tomorrow morning re: performance things)
<pedronis> sil2100: I filled in the table at the top with my +1, let me know if I should put in something else, not sure how you do this
<sil2100> pedronis: that's perfect, thanks a lot o/ I'll inform my manager and land the u-i bits tomorrow - we can always follow up with fixes later when we're able to test it properly
 * zyga is sleepy and goes to bed
<pedronis> ijohnson: I did a pass of answering already
<ijohnson> pedronis: ack will take a look
<mup> PR snapcraft#2767 opened: rust plugin: add rustup profile <Created by dalance> <https://github.com/snapcore/snapcraft/pull/2767>
 * cachio lunch
<ogra> ppisati, so i just tried to roll a kernel snap from the raspi2 tree of eoan ... using the rsapi2 defconfig (to use it on my pi4 core images) ... and i notice that i end up with an ~800MB snap !! lookinng inside (unsquashed it is even 2GB) i see 976M in modules !
<ogra> do we really need all this on a pi ?
<ogra> (and how did it grow so much since bionic ?)
<ogra> $ snap info rpi-iptv-player
<ogra> Killed
<ogra> bah !
<om26er> @saviq is there a way to tell multipass to use all available instead of using a single core ?
<Saviq> om26er: --cpu `nproc` when launching
<ogra> jdstrand, do we suddenly have auto-rebuilds enabled for outdated snaps ?
<Saviq> om26er: snapcraft has a hidden env var for it, too
<om26er> Saviq, cool that was going to be my second question :-)
<Saviq> https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/build_providers/_multipass/_multipass.py#L99
<Saviq> om26er: vote on https://github.com/CanonicalLtd/multipass/issues/756 to have a setting for the defaults ;)
<om26er> hmm, it seems to default to 2 apparently
<ogra> jdstrand, i just looked at one of my pi's and had an update this morning of one of my packages that i definitely havent touched in more than a month ... and snap info also shows "edge:      0.2 2019-10-24 (56) 42MB -"
<Saviq> om26er: that's threads, not necessarily cores
<Saviq> (i.e. with HT that might end up just one core)
<om26er> Saviq thanks for info, I'll subscribe to that issue
<ppisati> ogra: i don't work on ARM kernels anymore -- juergh and hwang4 are taking care of rpi kernels now
<ogra> ppisati, ah ..
<ogra> well, let me just express that i'm slightly shocked then ... seeing my kernel snaps triple up in size :)
<ppisati> ogra: while shrirang and jesse work on snapdragon
<ppisati> ogra: eh, i see what you mean
<ppisati> ogra: we can probably reduce the size / number of kmods
<ogra> yeah i guess so
<ppisati> ogra: thow a bug in LP about that, and we can take a look
<ogra> will do ... not urgent indeed, i believe official pi4 core support is only on schedule for core20 anyway
<mvo> zyga: do you think you could give a second review to 7640 ?
<ogra> $ snap stop lxd
<ogra> error: cannot communicate with server: Post http://localhost/v2/apps: dial unix /run/snapd.socket: connect: connection refused
<ogra> GRRRR !!!
<ijohnson> zyga: when you get back I have some bad news for you :-( https://github.com/snapcore/snapd/pull/7547#issuecomment-546001237
<mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
<ijohnson> I'm looking into it and I'm hoping there's an easy way out for this
 * Chipaca takes a break
<pedronis> mvo: I reviewed some of your PRs
<jdstrand> roadmr: hey, can you pull 20191024-1700UTC?
<roadmr> jdstrand: sure!
<jdstrand> roadmr: thanks :)
<roadmr> 1700 how precise ;)
<jdstrand> roadmr: just overrides and a change to the README. I used the new debian/changelog methodology as discussed before
<jdstrand> roadmr: yeah :)
<roadmr> thanks! jdstrand fwiw the guys who had complained about that said having the changelog from source was fine, so yay
<jdstrand> roadmr: cool :)
<jdstrand> ogra: if something is rebuilding that, it isn't something I am aware of
<ogra> jdstrand, yeah, i just learned that build.s.io adds automatic watches for *any* "source:" line in snapcraft.yaml ... not just for the repo that carries the snapcraft.yaml
<ogra> so myth solved .. the package uses two external GH trees ... i had the impression only changing the tree itself triggers rebuilds
<ogra> (i wonder how many of my snaps are actually broken because the initial build used some source: entry to a foreitgn trunk tree that was stable at the time i created the initial snap)
<ogra> thats probably a "feature" we should make people more aware of ... i certainly didnt knwo this
<ogra> *know
<cjwatson> Not any source: line, just ones that refer to repos on github
<ogra> indeed
<ogra> still though, i'm not even sure how many of my snaps use trunk links that might have completely fallen over after i created the snap
<ogra> (simply bcause ... well .. development trees instead of stable ...)
<ogra> +e
<zyga> mvo: sure
<zyga> ijohnson|lunch: uh
<zyga> ijohnson|lunch: there was a similar case before
<ijohnson|lunch> zyga: yeah I think I remember, but this is different because what I'm thinking right now is that we put dockerd inside a cgroup and it tries to mount things underneath that group and that doesn't work because those subsystems, i.e. devices are not mounted there they are mounted in the normal system one
<ijohnson|lunch> this should only affect things that need to create containers and manage cgroups
<ijohnson|lunch> anyways I will keep looking after lunch and let you know via the PR what I find
<jdstrand> ogra: oh, interesting
<zyga> jdstrand: do you want to review https://github.com/snapcore/snapd/pull/7632 -- it's the fix for the memory bug
<mup> PR #7632: interfaces: de-duplicate emitted update-ns profiles <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>
<zyga> jdstrand: it has +2 but I can wait if you want to go through it carefulyl
<zyga> *carefully
<mup> PR snapcraft#2766 closed: project: truncate project directory hash <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2766>
<cachio> niemeyer, hey, I am makes a POC related to github actions
<cachio> and I need a sa to store in the secrets to run the tests
<cachio> niemeyer, could you please create one similar to the one we use for travis
<cachio> with expiration: 1 week
<cachio> so I can test it?
<om26er> If that is of interest for anyone, I wrote a snap example that uses python3.8 and instead of bundling pycache files as part of the snap package, it generates them post-install. Reducing the size of the snap substantially (and in rare cases improves startup time as well) https://github.com/om26er/post-refresh-bytecompile-snap
<jdstrand> zyga: I do. as you can see from forum traffic, I'm a bit swamped
<jdstrand> zyga: I will review it before any other PRs
<zyga> jdstrand: no worries, thank you
 * cachio afk
<mup> PR snapcraft#2763 closed: "snap debug validate-seed" fails if the slot is specified in the default-provider <Created by kenvandine> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2763>
<zyga> jdstrand: hey
<zyga> jdstrand: I just ran into a curious bug
<zyga> jdstrand: https://forum.snapcraft.io/t/classic-confinement-breaks-high-dpi-support/13868
<zyga> jdstrand: XDG_RUNTIME_DIR breaks wayland
<zyga> cc kenvandine
<zyga> but when snap uses classic confinement, we should not set it at all IMO
<jdstrand> zyga: I just approved 7632, but please see my comments for a follwoup
<zyga> jdstrand: I will, thank you
<mup> PR snapd#7659 opened: snap/snapenv: preserve XDG_RUNTIME_DIR for classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/7659>
<mup> PR snapcraft#2765 closed: remote-build: initial Windows support <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2765>
 * kenvandine looks
<zyga> jdstrand: note, command time, is running /usr/bin/time, it's just that it's rarely installed
<zyga> jdstrand: I'll fix that in a follow up
<zyga> jdstrand: command foo performs PATH lookup and skips shell built-ins
<zyga> jdstrand: but GNU time is not installed anywhere outside of ubuntu
<jdstrand> zyga: I understand that about the lookup except bash behaves different. try it :)
<zyga> jdstrand: bash vs dash?
 * zyga tries
<jdstrand> zyga: yes, as my comment mentioned with hello-world.sh
<zyga> jdstrand: what I am doing wrong? https://www.irccloud.com/pastebin/uG75D2rs/
<jdstrand> zyga: anyway, how you fix it doesn't matter, just having it everywhere makes sense
<zyga> jdstrand: I think it only depends on /usr/bin/time being present or not, it's not in core
<zyga> (core 16 or 18, one of those has it AFAIR)
<jdstrand> zyga: you aren't in hello-world.sh?
<zyga> right, it's not in core so it's not there
<zyga> not on path
<jdstrand> bash-4.3$ command -v time
<jdstrand> time
<jdstrand> bash-4.3$ /bin/sh
<jdstrand> $ command -v time
<jdstrand> $
<zyga> no, I was on a 19.10
<zyga> oh
<zyga> that's weird
<zyga> it says that there's no time at all
<zyga> not even built-in
<jdstrand> zyga: it isn't in path in hello-world.sh bash either:
<zyga> I see now
<jdstrand> bash-4.3$ which time
<zyga> I understand the mistake now
<jdstrand> bash-4.3$
<zyga> thanks!
<jdstrand> np
<zyga> jdstrand: as for xdg runtime dir
<zyga> I think we need to fix wayland for strict
<zyga> but for classic I would argue that we did something wrong and need to back out
<zyga> even if there is some frictoin
<zyga> yes, each snap can fix it by itself
<zyga> but I would argue it's our bug
<zyga> *friction
<jdstrand> we can discuss that in the topic
<zyga> sure, sorry for splitting the conversation
<jdstrand> as for strict, that is a longer discussion. the symlinks were never supposed to be a longterm solution
<jdstrand> but resources what they are...
<zyga> I think nobody noticed this because it really manifests itself when you have fractional scaling
<zyga> and suddenly you go via xwayland
<zyga> and that just scales a bitmap
<jdstrand> as someone who uses hidpi, that would be annoying
<jdstrand> ok, I gotta run. I'm getting the side eye, but wanted that PR review out the door
<jdstrand> zyga: talk to you later
<zyga> jdstrand: sure, o/
<zyga> jdstrand: thank you for the review!
<zyga> I know you are super busy now
<jdstrand> zyga: np, sorry for the delay. I think I am through all the reviews/forum backlog (finally-- 2 days!! :\ )
<zyga> :)
<jdstrand> so, more PR reviews tomorrow
<jdstrand> ok, bye! :)
<mup> PR core-build#55 closed: Drop abootimg support, not used anymore <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core-build/pull/55>
#snappy 2019-10-25
<mup> PR snapcraft#2764 closed: Snapd doesn't actually honor the slot specified in the default-provider <Created by kenvandine> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2764>
<mvo> hey mbo
<mborzecki> morning
<mvo> hey mborzecki
<mborzecki> mvo: PRs still red?
<mvo> mborzecki: looks better today
<mvo> mborzecki: at least the one from zyga 7h ago is green
<mborzecki> wth https://github.com/snapcore/snapd/pull/7647 has pending build status, but when you go to the details page it's actually green
<mup> PR #7647: gadget: skip structures with MBR role during remodel <Remodel ð> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7647>
<mvo> mborzecki: oh no
<mborzecki> mvo: i've restated the cla check job, maybe it's enough to switch the status :/
<mvo> mborzecki: the cla job is not finished
<mvo> mborzecki: which is slightly strange
<mvo> mborzecki: I can cancel and restart?
<mborzecki> mvo: restarted it just now intentionally
<mvo> mborzecki: aha, ok
<mborzecki> mvo: all the other jobs were green, and cla runs are shortest, hope that when it completes travis will report the status back to gh
<mvo> mborzecki: right, makes sense. if not, I will just merge and override the missing check
<mup> PR snapd#7647 closed: gadget: skip structures with MBR role during remodel <Remodel ð> <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7647>
<mup> PR snapd#7657 closed: snap: fix default-provider in seed validation <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7657>
<zyga> hey
<zyga> mborzecki: the secret for green spread PRs is to open them at 1AM
<zyga> spread has logic for that
<zyga> really ;)
<zyga> juts look at 1AM and you will see it
<mborzecki> zyga: i.e. switch timezones then
<mborzecki> zyga: and hey :)
 * zyga had a horrible horrible night
<zyga> Janek decided to sleep in our bed and we couldn't convince him otherwise
<zyga> and that's just not enough space
<zyga> my whole body hurts
<zyga> mvo: I found a curious bug
<zyga> I discussed it with jamie a little
<zyga> but I couldn't convince him at the time
<zyga> mvo: I opened a thread about it to discuss it https://forum.snapcraft.io/t/classic-confinement-breaks-high-dpi-support/13868
<zyga> mvo: I think the bug is more serious for non-x-wayland sockets because it is likely that classic software is broken and unable to open files it expects
<jamesh> Ideally we wouldn't change XDG_RUNTIME_DIR for confined snaps either...
<zyga> by applying the attached fix all my snap apps are non-blurry now
<zyga> jamesh: I tend to agree, after all we have apparmor for confinement
<zyga> jamesh: I think jamie wanted to do this (set it to a custom value) to support things like instances
<zyga> but I don't know if that is sensible, how are apps expected to talk to each other?
<zyga> hey jamesh :-)
<jamesh> zyga: by that I mean mounting something over /run/user/$UID for strict confinement, with bind mounts of wayland, dbus, pulse sockets
<zyga> jamesh: mhm
<zyga> jamesh: for strict apps that's sensible IMO
<zyga> jamesh: especially that we can "recover" those socktes via hostfs
<mvo> zyga: is this 7659 ?
<zyga> jamesh: so even regular mount backend code would make it work
<zyga> mvo: yes
<mvo> zyga: aha, I see
<zyga> actually using wayland, snaps on the desktop
<zyga> brave new world
<zyga> I need to figure out the horrid suspend issue where x input breaks
<zyga> (but works in console)
<mvo> zyga: this looks fine to me but I don't know enough
<zyga> I only can reboot to recover from that
<zyga> need to learn how xinput works
<mvo> zyga: do you think could have a look at 7640? this would allow us to ship this in the initramfs
<zyga> yes, I think you pinged me about that yesterday
<zyga> let me do so now
<zyga> mvo: question about the path, we have /run/snapd/* already, could that path be /run/snapd/recovery or something like that?
<mvo> zyga: sure, I can change that
<mvo> zyga: this is in initramfs
<mvo> zyga: so we don't have /run/snapd yet but its fine to add it
<zyga> yeah, just for consistency,
<zyga> it's not a blocker in any way
<zyga> mvo: total lack of docstrings makes this harder to review
<zyga> mvo: I'm not following core20 work as closely
<zyga> mvo: what kind of filesystems are going to be mounted?
<mvo> zyga: vfat and ext4 currently
<zyga> mvo: by deployFilesystemContent
<zyga> ok
<mborzecki> zyga: i'm looking for the place where we creat that per snap XDG_RUNTIME_DIR but i don't see it
<mborzecki> zyga: there's some dead code in s-c
<mborzecki> zyga: and nothing in snap run?
<zyga> mborzecki: snap run
<zyga> mborzecki: cmd/snap/cmd_run.go:495
<mborzecki> zyga: btw. wonder if that also breaks the thing with xdg-open & classic snaps that cause new browser window to pop up
<zyga> mborzecki: probably
<zyga> yeah, it's just silly we set it
<zyga> for classic I mean
<mup> PR snapd#7660 opened: snap-recovery: rename to "snap-bootstrap" <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7660>
<mborzecki> zyga: hmm that code in snap run doesn't create /run/user/<uid>/snap.*
<jamesh> there's code in snapcraft-desktop-helpers that creates it, with a comment referencing https://bugs.launchpad.net/snappy/+bug/1656340
<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>
<zyga> mvo: https://github.com/snapcore/snapd/pull/7640#pullrequestreview-307007679
<mup> PR #7640: snap-recovery: deploy gadget content when creating partitions <Created by mvo5> <https://github.com/snapcore/snapd/pull/7640>
<mvo> zyga: thank you! about the ShiftStructureTo - thats something for mborzecki
<mvo> zyga: I will follow the second suggestion in a followup, I need to make it transactional and then its good for now
<mup> PR snapd#7640 closed: snap-recovery: deploy gadget content when creating partitions <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7640>
<zyga> +1
<mvo> thanks zyga !
<zyga> mvo: is https://github.com/snapcore/snapd/pulls/zyga something for 2.42.1 or 2.43?
<zyga> I'll get breakfast and then work on follow ups
<pstolowski> morning
<zyga> hey palasso
<zyga> pawel :)
<palasso> hello zyga
<mup> PR snapd#7630 closed: overlord/devicestate: check snap handler for gadget remodel compatibility <Remodel ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7630>
<mvo> hey pstolowski ! good morning
<mborzecki> zyga: reading the comments from ian about docker snap, wtf is docker doing there?
<mborzecki> btw. wonder if we could snap podman and use the same docker interface
<zyga> i have ideas
<zyga> breakfasting
<mborzecki> zyga: #7632 is green
<mup> PR #7632: interfaces: de-duplicate emitted update-ns profiles <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>
<zyga> yep
<zyga> re
<zyga> okay
<zyga> mborzecki: we had an issue with docker in the past
<zyga> mborzecki: it was trying to use /sys from ... /var/lib/snapd/hostfs/sys
<zyga> mborzecki: I think it's a bit "too" smart
<zyga> mborzecki: I'll start by hiding the cgroup from snap view
<zyga> mborzecki: let's see if that is enough to fix it
<mborzecki> zyga: so smart that the smartness overflowed
<mborzecki> zyga: won't the cgroup always appear via /proc/$$/cgroup?
<zyga> mborzecki: nuclear gandhi
<zyga> mborzecki: yes but if it doesn't show up mounted maybe it will ignore it
<zyga> mborzecki: we need to check docker logic
<zyga> afk again
<mborzecki> zyga: iirc when i looked at libcontainer it tried to parse /proc/self/cgroup and /proc/mountinfo
<zyga> mborzecki: we can remove it from mountinfo
<zyga> if it parses cgroup then we're SOL
<zyga> but then again, it's silly to do :P
<mup> PR snapd#7661 opened: packaging: tweak handling of usr.lib.snapd.snap-confine <Created by mvo5> <https://github.com/snapcore/snapd/pull/7661>
<zyga> mvo: thanks
<zyga> mvo: is it working?
<zyga> is that tested?
<zyga> we did that before and it was a hit-and-miss
<zyga> mborzecki: I wrote a small patch - checking if that makes docker work
<mvo> zyga: we test it in one spread test but I could not reproduce
<zyga> aha
<zyga> well
<zyga> I wrote that patch for moving that out of /etc
<zyga> but it's not finished (tests need adjusting)
<zyga> I think it's fine
 * mvo nods
<zyga> mborzecki: it works
<zyga> mborzecki, ijohnson: this fixes docker
<zyga> https://github.com/snapcore/snapd/pull/7547/commits/1c60b84df1faf7ca2e80bf30d50850e6322da87b
<mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
<zyga> so yay
<pedronis> mvo: should #7642 be merged?  #7626 and #7645 need a master merge I think
<mup> PR #7642: travis.yml: add 'sh -x' to run-checks <Created by mvo5> <https://github.com/snapcore/snapd/pull/7642>
<mup> PR #7626: managers: add remodel undo test for new required snaps case <Created by mvo5> <https://github.com/snapcore/snapd/pull/7626>
<mup> PR #7645: client: add xerrors and wrap errors coming from "client" <Created by mvo5> <https://github.com/snapcore/snapd/pull/7645>
<pedronis> mborzecki: hi, maybe you can do a 2nd review of 7626
<mup> PR snapd#7632 closed: interfaces: de-duplicate emitted update-ns profiles <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7632>
<pedronis> lots of repeated red :/
 * dot-tobias says hi
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/7662
<zyga> hey dot-tobias
<mup> PR snapd#7662 opened: interfaces: simplify AddUpdateNS and emit <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7662>
<mup> PR #7662: interfaces: simplify AddUpdateNS and emit <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7662>
<pstolowski> zyga: ty
<pedronis> mvo: did you see my ping here about some of your PRs ?
<mvo> pedronis: re 7642> if we don't see the mysterious error 6 anymore I think we can omit it
<mvo> pedronis: I suspect something with travis was wrong that triggered these errors
<pedronis> ok
<mvo> pedronis: feel free to close, we can always reopen if these mysterious errors  come ack
<mup> PR snapd#7663 opened: tests: add 14.04 canonical-livepatch test <Created by mvo5> <https://github.com/snapcore/snapd/pull/7663>
<mup> PR snapd#7664 opened: cmd/cmdutil: version helper <Prebaking> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7664>
<mup> PR snapd#7642 closed: travis.yml: add 'sh -x' to run-checks <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7642>
<mup> PR snapd#7665 opened:  devicestate: add support for gadget->gadget remodel  <Remodel ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7665>
<mborzecki> mvo: pedronis: ^^ decided against splitting it further for now
<mborzecki> still 12 files changed, 820 insertions(+), 97 deletions(-) :/ meh
<ijohnson> zyga nice
<zyga> hey :)
<zyga> yeah
<ijohnson> Much better than trying to patch docker :-)
<pedronis> mborzecki: sounds ok size wise, I imagine a bunch is the managers_test.go test ?
<mborzecki> pedronis: yup, managers_test, devicestate tests, spread test ;)
<pedronis> yea, sounds alright :)
<mvo> thanks mborzecki
<mborzecki> mvo: got some reviews for zyga and then i'll look into the copr repo with xerrrors to unblock you
<mvo> mborzecki: \o/
 * Chipaca gets confuzzled and takes a break
 * pstolowski lunch
<Wimpress> mvo Chipaca We (popey and I) have things to discuss with you for todays catch up :-)
<mup> PR snapd#7648 closed: interfaces/policy: expand cstrs/cstrs1 to altConstraints/constraints <Simple ð> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7648>
<zyga> Wimpress: sounds interesting
<mup> PR snapd#7655 closed: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7655>
<mvo> Wimpress: I can make it if we keep it short
 * zyga afk
<mup> PR snapcraft#2707 closed: manifest: sort package and snap lists for consistency <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2707>
<mup> PR snapcraft#2755 closed: extensions: kde-neon: add icon and sound themes <Created by galgalesh> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2755>
<ijohnson> morning
<pedronis> pstolowski: I did a pass on #7658
<mup> PR #7658: cmd/snap-start-preseed: add snap-start-preseed executable (1/N) <Prebaking> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7658>
<pstolowski> pedronis: yes just saw it, thank you
<ijohnson> pstolowski: thanks for the review, will address your suggestions today
<mvo> mborzecki: about this copr repo - do I need to add something to the xerrors pr under review?
<mborzecki> mvo: i'll open a PR adding that to the early setup we do on fedora
<mvo> mborzecki: \o/
<mup> PR snapd#7662 closed: interfaces: simplify AddUpdateNS and emit <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7662>
<zyga> jdstrand: can you re-review https://github.com/snapcore/snapd/pull/7547
<mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
<zyga> jdstrand: mainly to check the comments about v1 vs v2 mode
<zyga> huh
<zyga> https://www.irccloud.com/pastebin/eonsNHRx/
<zyga> mborzecki: did you see this when changing delta code in spread recently?
<zyga> not sure why this didn't flag before
<zyga> perhaps just 19.10 -> amazon is the problem
<mborzecki> zyga: nope? this an opensuse host?
<zyga> no, ubuntu 19.10
<mborzecki> ah 19.10 hm, maybe some defaults changed?
<zyga> mhm
<sergiusens> how good is "snap set core experimental.refresh-app-awareness=true"?
<zyga> sergiusens: it's partially useful, it's not handling classic confinement which will be fixed shortly (code ready, waiting on reviews)
<zyga> sergiusens: there's no UX but that's under development
<mup> PR snapd#7666 opened: tests: don't depend on GNU time <Created by zyga> <https://github.com/snapcore/snapd/pull/7666>
<zyga> sergiusens: there will be some in the next two weeks
<sergiusens> zyga: I just want to prevent updates for when running confined snaps like the browser, which updates frequently and too many weird things start to happen :-)
 * sergiusens sets the flag
<zyga> sergiusens: yes, please set it
<zyga> sergiusens: and report all weird stuff
<zyga> sergiusens: I'm working on making it much better
<zyga> mborzecki: small python helper if you want to look
<zyga> https://github.com/snapcore/snapd/pull/7666/files
<mup> PR #7666: tests: don't depend on GNU time <Created by zyga> <https://github.com/snapcore/snapd/pull/7666>
<ijohnson> pedronis: I will look at your seedwriter PR now
<zyga> Installing updates....
<pedronis> ijohnson: thx
<mup> PR snapd#7667 opened: spread: enable bboozzoo/snapd-devel-deps COPR repo for getting golang-x-xerrors <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7667>
<mborzecki> mvo: ^^
<ijohnson> pedronis: reviewed one question about the tests
 * ijohnson goes to get coffee before meeting
<jdstrand> zyga: it is on the list, yes. pedronis, I commented (only) on pr 7659. I am not explicitly blocking the PR, but wanted to make sure my concerns were considered
<mup> PR #7659: snap/snapenv: preserve XDG_RUNTIME_DIR for classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/7659>
<zyga> jdstrand: ack
<jdstrand> well, I did vote -1 for 2.42.x
<jdstrand> but anyhoo, it is all in the PR
<jdstrand> zyga: also, I don't think I'm needed for 7666, but I glanced at it and the approach looks good. thanks for the followup :)
<zyga> jdstrand: thanks! :)
<abeato> jdstrand, hey, is https://github.com/snapcore/snapd/pull/7603 on your radar? the MP contains a couple of new interfaces for dpdk
<mup> PR #7603: interfaces: add dpdk and hugepages interfaces <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/7603>
<jdstrand> abeato: it is. I need to dig in a bit on that one
<abeato> great
<hellsworth> i see two content snaps listed when i do snap connections on my snap so can someone point me to where connections grabs its info from?
<hellsworth> i'm building my snap in a normal way, only pointing to one extension. that extension only points to one platform snap.
<hellsworth> does the core18 base know about extensions?
<ijohnson> hellsworth: look at `sudo cat /var/lib/snapd/state.json | jq .data.conns`.
<ijohnson> hellsworth: probs you are suffering from the bug where your snap you are working on was previously installed and had that connection to the other content interface and so now `snap connections` shows that
<hellsworth> how can i clear that history though
<hellsworth> yes i did previously have this snap installed with the old extension
<hellsworth> which connected to the old content snap
<ogra> Oct 25 16:19:28 ... systemd[1]: [/etc/systemd/system/snap-pi2\x2dkernel-102.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'
<ogra> Oct 25 16:19:28 ... systemd[1]: [/etc/systemd/system/snap-core18-1226.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'
<ogra> hmm, thats a new one
<ogra> (my log is full of these)
 * zyga goes for lunch
<oSoMoN> jdstrand, have you seen my last message on https://forum.snapcraft.io/t/auto-connecting-the-personal-files-interface-for-the-chromium-snap-part-ii/13705/8 ?
<oSoMoN> auto-connection of personal-files for chromium is refused, I thought you had allowed it?
<jdstrand> oSoMoN: I hadn't, but I'll look at it
<jdstrand> zyga: ok, reviewed pr 7547, please see both the review comments and the additional comment I added after
<mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
<oSoMoN> jdstrand, you wrote "Granting use of the updated path. This is now live.", I assumed this was good to go
<jdstrand> oSoMoN: it should be. that is why I need to look at it :)
<oSoMoN> ok, thanks :)
 * cachio lunch
<zyga> jdstrand: ack
<jdstrand> oSoMoN: btw, the memory usage PR as merged. it should be in edge whenever the core snap is rebuilt
<jdstrand> zyga: it probably wouldn't be terrible to get that ^ in 2.42
<jdstrand> I'll let others decide
<zyga> jdstrand: the apparmor memory fix? I think that's up to mvo to cherry pick but I agree it's not likely to be hard to do or breaking stuff
<zyga> so yeah =1
<zyga> +1
<jdstrand> zyga: yeah
<mvo> zyga: if you and jdstrand are good I can cherry pick the appamror de-dup fix to 2.42.1  (unless pedronis  objects of course)
<oSoMoN> jdstrand, I subscribed to the PR so I got a notification when it was merged, that's very nice, thanks!
<oSoMoN> my opinion doesn't count, but I'm totally +1 for cherry-picking :)
<jdstrand> mvo: +1
<zyga> mvo: yes, just remember it was split into three PRs
<zyga> mvo: 1) OrderedSet, 2) emit 3) the actual fix with spread test
<oSoMoN> btw, thanks zyga for working on this
<jdstrand> mvo: regression potential should be shallow. if snap-update-ns isn't working right, it should be broken in many places. asking QA for explicitly testing the preinstalled gnome snaps is likely not a bad idea to build confidence
<mvo> zyga, jdstrand lets quickly catchup with pedronis  (he is in a meeting right now) and if he is +1 I will cherry-pick
<jdstrand> oSoMoN: typo in snap decl. I thought it was chromium-browser-init. it is chromium-browser.init
<jdstrand> oSoMoN: shall I fix the snap decl or you fix the snap?
<jdstrand> oSoMoN: it is easy to fix the snap decl
<jdstrand> oSoMoN: I see the original request was for chromium-browser.init, so I'll fix the snap decl
<jdstrand> oSoMoN: fixed: https://forum.snapcraft.io/t/auto-connecting-the-personal-files-interface-for-the-chromium-snap-part-ii/13705/8
<jdstrand> oSoMoN: be sure to 'snap refresh' before install if using the same system
 * zyga made coffee
<ogra> zyga, did you see my error above ? seems all my machines are spamming their logs with that
<zyga> ogra: no, I did not
<ogra> Okt 24 20:52:26 anubis systemd[1]: [/etc/systemd/system/snap-core-7917.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'
<zyga> I see that now
<ogra> ogra@anubis:~$ journalctl |grep -c lvalue
<ogra> 1483
<jdstrand> ogra: oh, I've seen that. I kept meaning to mention it somewhere
<zyga> older versions of systemd don't understand lazy unmount
<zyga> ogra: which version is that?
<zyga> of the distribution
<jdstrand> zyga: for me it was uc16
<ogra> i just noticed it on a pi here ... and checked the other machines ... seems all of them show it
<zyga> I see
<ogra> thats 16.04 and a Core 16 Pi
<zyga> it's a part of a fix
<zyga> that doesn't work on old systems
<ogra> so both, core and desktop
<pedronis> mvo: what's the question?
<ogra> yeah, i was guessing you use some new systemd feature there :)
<jdstrand> zyga: perhaps use of the conditional needs to be conditional on new enough systemd? not sure if that is system-key material...
<jdstrand> meh
<zyga> it is https://github.com/snapcore/snapd/commit/5f16e6b0738410d07995b85bc516d9bbb50263c8
<jdstrand> use of the feature*
<mvo> pedronis: if we can backport the de-duplication for apparmor lines into 2.42.1
<zyga> jdstrand: we don't re-generate mount units today, system key won't help
<zyga> jdstrand: I agree it would be nicer to know if it is supported
<zyga> I need a moment to finish the coffee
<zyga> then jumping into a customer bug
<jdstrand> ogra: I'm thinking there should be a bug. I suspect we'll get customers wondering about it
<jdstrand> ogra: and that will help the snapd team to prioritize
<pedronis> mvo: it seems ok, if jdstrand is also +1
<mvo> zyga: has the 3rd part landed already?
<zyga> mvo: yes, all parts are inn
<zyga> *in
<jdstrand> pedronis (cc mvo): I am, though asking for some light additional QA for say running gnome snaps and verifying no new denials would not be unreasonable. I know there are nice tests for that in the PRs, so, all of your call
<ogra> zyga, jdstrand https://bugs.launchpad.net/snapd/+bug/1849861
<mup> Bug #1849861: Unknown lvalue 'LazyUnmount' message in logs with latest snapd on 16.04 based systems <snapd:New> <https://launchpad.net/bugs/1849861>
<jdstrand> ogra: thanks!
<pedronis> mvo: as jdstrand says a bit of extra QA would be good? what was your plan, do 2.42.1 straight? do a pre?
<mvo> pedronis: probably no pre, should be very controlled but we can keep it longer in candidate for example
<pedronis> ok
<mvo> zyga: what was the pr number for the 3rd part
<zyga> mvo: just install a snap before and after and check sha1 of the kernel image of the profile
<zyga> mvo: one moment
<zyga> mvo: 7632 7633 7639
<zyga> mvo: please make sure to cherry pick the test as well, so that you can see it pass
<mvo> zyga: thank you! 7632
<mvo> zyga: 7632 tripped me over
<zyga> mvo: do you need help?
<mvo> zyga: in a meeting right now, I will probably do this on monday, but you are welcome to prepare a PR against 2.42 - but no worries, I will get to it eventually
<zyga> mvo: not today, I'll just inspect that bug and EOD
<zyga> mvo: I -1 one of your branches, sorry, just a  question but need to make sure it does not land unanswered
<mvo> zyga: thats fine, its a valid question, we do it in other tests too but I will have a look later
 * zyga is under invasion from a particularly lovely toddler :D
<mvo> zyga: eod> totally fine!
 * zyga breaks to run an errand
<ijohnson> hellsworth: sorry I missed your response, probably what you can do is first remove the snap, then make a backup of your state.json, stop snapd with `systemctl stop snapd.socket && systemctl stop snapd` and then delete the conns for the snap in question in state.json and then re-enable snapd with `systemctl start snapd.socket && systemctl start snapd`and finally try installing your snap again
<ijohnson> note that afaik the bug is just about the connections showing up in `snap connections`, I don't think the security policy still actually has the stuff that those connections implies
<hellsworth> ok thanks. should snap-discard-ns also cleare this cached history too?
<ijohnson> hellsworth: snap-discard-ns will clean up the security policy stuff (well specifically the mount ns), but it won't clean up the connections themselves
<hellsworth> ok thanks for clearing that up ijohnson
<ijohnson> np, sorry you are encountering that bug
<hellsworth> bugs happen :)
<ijohnson> hellsworth: that bug fwiw is https://bugs.launchpad.net/snapd/+bug/1848516
<mup> Bug #1848516: snap connections/interfaces shows dropped interfaces as connected after refresh <snapd:Confirmed for stolowski> <https://launchpad.net/bugs/1848516>
<hellsworth> ah thanks
<jdstrand> zyga: oh, I meant to ask, what was up with all the .keep files in PR 7632?
<mup> PR #7632: interfaces: de-duplicate emitted update-ns profiles <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7632>
<zyga> jdstrand: those are so that we have a
<zyga> Directory structure
<zyga> It is like gnome system monitor snap
<zyga> Just frozen in time
<zyga> And empty
<jdstrand> zyga: oh right, git
<zyga> Yeah :-)
<jdstrand> zyga: it was weird cause github said 'No changes' in the PR
<jdstrand> so it threw me
<zyga> Yeah, all empty
<jdstrand> ok, thanks :)
<zyga> :-)
<mup> PR snapcraft#2768 opened: remote-build: autorecovery and improved resiliency <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2768>
 * cachio afk
<kenvandine> sergiusens: https://paste.ubuntu.com/p/HTgWjC9tJV/
<kenvandine> that is me building with the WIP gnome-3-34 extension which uses gnome-3-34-1804-sdk build snap
<kenvandine> libffi.so.7 is in the same directory as libgobject-2.0.so
<mup> PR snapcraft#2761 closed: Core20 base <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2761>
<kenvandine> sergiusens: any suggestions appreciated
<mup> PR snapd#7667 closed: spread: enable bboozzoo/snapd-devel-deps COPR repo for getting golang-x-xerrors <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7667>
<mup> PR snapd#7664 closed: cmd/cmdutil: version helper <Prebaking> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7664>
<mup> PR snapd#7654 closed: cmd/snap, store: include snapcraft.io page URL in snap info output <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7654>
<mup> PR snapd#7605 closed: tests: configure the journald service for core systems <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7605>
<mup> PR snapd#7656 closed: tests: verify host is not affected by mount-ns tests <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7656>
#snappy 2019-10-26
<mup> PR snapd#7668 opened: tests: tweak wording in mount-ns test <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7668>
<mup> PR snapd#7645 closed: client: add xerrors and wrap errors coming from "client" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7645>
<mup> PR snapd#7626 closed: managers: add remodel undo test for new required snaps case <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7626>
<mup> PR snapd#7660 closed: snap-recovery: rename to "snap-bootstrap" <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7660>
<mup> PR snapcraft#2769 opened: [WIP] extensions: skip icon cache creation when icon theme specifies so <Created by galgalesh> <https://github.com/snapcore/snapcraft/pull/2769>
<mup> PR snapd#7367 closed: snap, cmd/snap: support (but warn) using deprecated multi-slash channel <â Blocked> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/7367>
<mup> PR snapcraft#2770 opened: extensions: speed up desktop-launch by not calling mkdir -p <Created by galgalesh> <https://github.com/snapcore/snapcraft/pull/2770>
#snappy 2019-10-27
<mup> PR snapd#7669 opened: Channels with extra slashes v2 <Created by chipaca> <https://github.com/snapcore/snapd/pull/7669>
<mup> PR snapd#7670 opened: cmd/snap: support (but warn) using deprecated multi-slash channel <Created by chipaca> <https://github.com/snapcore/snapd/pull/7670>
<mup> PR snapd#7671 opened: overlord/patch: normalize tracking channel in state <Created by chipaca> <https://github.com/snapcore/snapd/pull/7671>
<mup> PR snapd#7595 closed: seed/seedwriter: support writing Core 20 seeds (aka recovery systems) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7595>
<mup> PR snapd#7672 opened: seed: share auxInfo20 and makeSystemSnap via internal <Created by pedronis> <https://github.com/snapcore/snapd/pull/7672>
<mup> PR snapd#7673 opened: interfaces/desktop: allow access to system prompter interface <Created by alexmurray> <https://github.com/snapcore/snapd/pull/7673>
