text: #snappy 2015-10-12
  <dholbach> good morning
  <clobrano> good morning
  <Chipaca> goood morning people!
  <mvo> hey Chipaca, good morning!
  <Chipaca> mvo: how's things?
  <mvo> Chipaca: busy, but good otherwise, how are you?
  <Chipaca> mvo: considering breakfast
  <Chipaca> :)
  <mvo> Chipaca: do it!
  <Chipaca> mvo: i need to fix the way we're using husks, i learned
  <Chipaca> um
  <Chipaca> not husks
  <Chipaca> the other thing
  <Chipaca> tombs
  <mvo> Chipaca: oh? how so?
  <mvo> Chipaca: the way you used them looked super nice
  <Chipaca> mvo: the function you give to tomb.Go is supposed to check whether the tomb.Kill has been called
  <Chipaca> mvo: http.Serve does not do that :)
  <Chipaca> i learned this in trying to make the server auto-go away after a bit ;)
  <mvo> Chipaca: heh, ok
  <Chipaca> so there'll be a branch about that sometime today, maybe :)
  <mvo> Chipaca: cool
  <Chipaca> we're also not doing that in tasks' tomb, but that's ok because there aren't cancelable tasks just yet
  <JamesTait> Good morning all; happy Monday, and happy World Arthritis Day! ð
  <ogra_> ouch
  <Chipaca> wah, http.Server's Serve() calls out to private methods; i can't reimplement it tomb-friendly without reimplementing the guts of http :-(
  <Chipaca> pitti: o/
  <Chipaca> pitti: how much do you know about systemd's socket activation? :)
  <Chipaca> pitti: looking for a way to tell systemd to shut it down after inactivity
  <Chipaca> pitti: or lacking that, looking for a way to tell systemd it's shutting down due to inactivity
  <Chipaca> pitti: i've tried doing sd_notify(0, "STOPPING=1") but that still seems to get clients connecting after
  <pitti> Chipaca: not much, I'm afraid; sd_notify(3) looks like STOPPING=1, but do you actually shut down the service afterwards?
  <Chipaca> yep
  <pitti> Chipaca: you can't tell if a service is inactive from teh outside, the process itself needs to do that
  <Chipaca> sd_notify doesn't seem to make any difference
  <pitti> Chipaca: maybe it gets restarted immediately due to new clietns connecting?
  <Chipaca> yes
  <pitti> Chipaca: i. e. you might have stopped the .service, but not the corresponding .socket
  <Chipaca> and then it starts starting
  <Chipaca> pitti: i'm testing exactly that
  <Chipaca> that is: i'm trying to make sure that if the server decides to go away *just* as a new client connects, things still work
  <gberginc> can anyone help me get my demo snappy app that depends on a small shared library run?
  <gberginc> shared lib only has one function and my main app only calls that function
  <gberginc> all is packed into a snap
  <gberginc> the contents of the package can be seen at http://pastebin.com/4MA60S6r
  <gberginc> (well, the structure, that is)
  <biezpal> gberginc, you should define "LD_LIBRARY_PATH" variable to make library "shared" :)
  <gberginc> sorry, biezpal, I am completely new to Snappy - where should I add this? on my host I have specified LD_LIBRARY_PATH before building the app
  <biezpal> I mean, run "export LD_LIBRARY_PATH=/apps/heyho/current/lib/x86_64-linux-gnu" in Snappy with your app installed on
  <biezpal> and try to run your app after this, this should help
  <ogra_> you shouldnt need that
  <ogra_> the wrapper that executes the snap binary will set it automatically
  <ogra_> you just need to put your lib in the right place in your snap
  <biezpal> ogra_, is it already implemented?
  <ogra_> lib/x86_64-linux-gnu/ for amd64 and lib/arm-linux-gnueabihf/ for arm
  <ogra_> biezpal, since forever :)
  <biezpal> ogra_, few month ago we requested this feature)
  <biezpal> btw, where can we get changelogs?
  <gberginc> I have the lib in that folder but it doesn't seem to work
  <gberginc> I may have some other problems though :)
  <gberginc> because even after setting LD_LIBRARY_PATH it doesn't work; I'll look into
  <Chipaca> ogra_: um... you sure the LD_LIBRARY_PATH thing is done?
  <Chipaca> ogra_: it's not done by ubuntu-core-launcher, and it's not done by snappy
  <Chipaca> ogra_: i think it used to be done by the precursor of snapcraft, but i'm not sure
  <biezpal> :D
  <Chipaca> so AFAIK you still have to do it yourself
  <Chipaca> gberginc: if you share the snap itself, i can help, probably
  <gberginc> after setting LD_LIBRARY_PATH I see this in ldd
  <gberginc> (amd64)ubuntu@localhost:/apps/heyho.sideload/current$ ldd bin/main
  <gberginc>         linux-vdso.so.1 =>  (0x00007ffdf3fda000)
  <gberginc>         libmylib.so => /apps/heyho.sideload/current/lib/x86_64-linux-gnu/libmylib.so (0x00007fa3a3019000)
  <gberginc>         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa3a2c4f000)
  <gberginc>         /lib64/ld-linux-x86-64.so.2 (0x00007fa3a321b000)
  <gberginc> but it still fails to start
  <gberginc> let me create a repo with the app
  <gberginc> ^ Chipaca
  <Chipaca> gberginc: how are you starting it, and what error do you get
  <ogra_> Chipaca, hmm ? ubuntu-core-launcher should do it since quite a while
  <Chipaca> ogra_: set LD_LIBRARY_PATH? nope
  <ogra_> yes
  <Chipaca> john@fogey:~/canonical/ubuntu-core-launcher$ grep -r LD_LIBRAR
  <Chipaca> john@fogey:~/canonical/ubuntu-core-launcher$
  <ogra_> now thats weird, i definitely remember apparmor chnges after this landed
  <ogra_> well, but then yes, you need a wrapper
  <Chipaca> gberginc: fwiw just the .snap would probably be enough to point you in the right direction, don't need to see the source itself
  <gberginc> Chipaca: ok, I'll share the snap
  <gberginc> Chipaca: http://k00.fr/2w2gp
  <biezpal> (amd64)ubuntu@management:~$ /apps/heyho.sideload/current/bin/main
  <biezpal> Hello from librarycos(0) = 1.000000
  <biezpal> (amd64)ubuntu@management:~$ /apps/heyho.sideload/current/bin/hoho
  <biezpal> Heyhohoho!
  <Chipaca> $ heyho.main
  <Chipaca> Hello from librarycos(0) = 1.000000
  <Chipaca> biezpal: don't call it directly, that's not contained!
  <Chipaca> biezpal: use the /apps/bin/* wrappers
  <Chipaca> gberginc: so
  <Chipaca> gberginc: move main to main.real
  <Chipaca> gberginc: and make "main" a script that does: #!/bin/sh
  <Chipaca> LD_LIBRARY_PATH=$SNAP_APP_PATH/lib/x86_64-linux-gnu $SNAP_APP_PATH/bin/main.real
  <Chipaca> (if you're packaging more than one architecture, $SNAPP_ARCH can help)
   * Chipaca wonders, not for the first time, why there isn't a SNAP_ variable for the multiarch string thing
  <gberginc> great, thanks Chipaca!
  <gberginc> Chipaca: it works!
  <Chipaca> *shocking*
  <gberginc> for me, yes :D
  <gberginc> I'll now try openfoam to see how easy it would be to make a framework/app out of it
  <olli> gm
  <jdstrand> ogra_: hey, I'm not working right now, but I was wondering how to force a module load with snappy config. I know about the 'modprobe' option, but that edits a file in /etc/modprobe.d. I think I need a file in /etc/modules-load.d to be edited, unless there is something I can put in modprobe.d
  <jdstrand> but I can't seem to find it
  <jdstrand> what I specifically need it iptable_filter and ip6table_filter to be loaded, since they don't autload from within a snap
  <ogra_> heh, i didnt even know abouot /etc/modules-load.d ... is that the same as /etc/modules ?
  <ogra_> (just broken down into single files)
  <jdstrand> yes
  <ogra_> Chipaca, ^^^ can we add that to snappy config for ubuntu-core ?
  <jdstrand> otherwise firewall snaps aren't going to work :)
  <ogra_> jdstrand, same game as always ... needs adding to writable paths in ubuntu-core-config and a function in snappy for snappy config
  <Chipaca> what's the difference between modprobe.d and modules-load.d?
  <jdstrand> both have man pages
  <ogra_> modprobe.d definest module parameters
  <jdstrand> the first adjusts options when loading
  <jdstrand> the second forces load on boot
  <Chipaca> oooh, haven't been told to rtfm in ages
   * Chipaca rtfm's
  <jdstrand> this is trying to deal with this bug: https://bugs.launchpad.net/snappy/+bug/1496419
  <ubottu> Launchpad bug 1496419 in Snappy "iptable_filter and ip6table_filter do not auto load" [Undecided,New]
   * ogra_ adds an ubuntu-core-config task
  <jdstrand> cool, thanks
  <jdstrand> one of these days, I'll have a ufw snap in the store
  <ogra_> yay
  <ogra_> then i could actually snappify my firewall !
   * ogra_ already has a ufw firewall in use here ... but deb based 
  <jdstrand> yeah, me too
   * davmor2 pictures ogra_'s home slowly turning into rasp pi2's 
  <jdstrand> I really want to create a little 'router snap' for my soekris
  <Chipaca> ogra_: where does ubuntu-core-config come into the picture, btw?
  <ogra_> Chipaca, it defines the writable paths on the image
  <Chipaca> ah
  <ogra_> davmor2, nah, for real stuff i dont use RPis :)
  <davmor2> ogra_: oh sorry Beagle Board blacks is it ;)
  <ogra_> http://www.amazon.de/gp/product/B00JR6X0ZK
  <ogra_> plain x86
  <davmor2> ogra_: nice
  <jdstrand> ogra_, Chipaca: so we need that writable path but also a 'modules-load' option in snappy config ubuntu-core. guessing that would just be a list that create a file in /etc/modules-load.d/ubuntu-core.conf that has one module per line
  <ogra_> jdstrand, yeah, that sounds correct
  <ogra_> by default just an empty file
   * jdstrand nods
  <Chipaca> how many modules would it be, worst case?
  <Chipaca> because making it a bunch of files would be easier :)
  <jdstrand> in my case, 2
  <jdstrand> :)
  <jdstrand> or any firewall snap
  <Chipaca> i mean, /etc/modules-load.d/ubuntu-core-$module for every module you want
  <jdstrand> I don't know what other modules don't autoload when under confinement
  <ogra_> well
  <ogra_> might not only be an autoload thing but simply some adjustment to the default image
  <jdstrand> that seems weird when comparing it to modprobe
  <jdstrand> Chipaca: ^
  <jdstrand> modprobe creates one file
  <ogra_> i can imagine that you might want to force load modules that wouldnt autoload when doing a certain oem project
  <jdstrand> ogra_: I had that feeling too, but I couldn't come up with an example
  <davmor2> jdstrand, ogra_: actually I'm surprised that ufw isn't in the base image it is way more pleasant to use that iptable :)
  <ogra_> davmor2, bot not everyone needs a firewall builtin into his drone :)
  <jdstrand> it wasn't considered minimal enough
  <davmor2> ogra_: but iptables is which is the actual firewall, ufw just makes your eyes bleed less using it :P
  <ogra_> well, a snappy install should essentially only be systemd, the snappy binary, a shell and the glue to make these three boot a system
  <ogra_> as minimal as possible
  <ogra_> sadly we're kind of moving away from that a little recently
  <Chipaca> we are?
  <ogra_> yeah, definitely
  <Chipaca> aww
  <ogra_> so many seed additions recently :/
  <davmor2> ogra_: but iptable is part of the kernel right so if you have the kernel installed it's there isn't it?
  <Chipaca> i'm still wanting to nuke python out of there
  <ogra_> davmor2, not the userspace
  <Chipaca> iptables the userspace things are quite large, even
  <davmor2> ogra_: grrrr ogra2 keeps getting priority over ogra_   fair enough wasn't sure if it was a separate thing or not nice to know though :)
  <Chipaca> ogra2 isn't an async ogra_ ?
  <ogra_> Chipaca, nah, its my snappy test setup for the bip snap in longterm testing :)
   * Chipaca reads "yes, yes it is"
  <ogra_> haha
  <longsleep> Chipaca: nuke python2 or python3 - but please keep a python there so snaps do not have to ship python for simple scripts and stuff
  <Chipaca> longsleep: https://github.com/micropython/micropython :D
  <longsleep> mhm - i am not sure i like that
   * longsleep prefers to have /usr/bin/python 
  <ogra_> we will definitely get rid of python at some point
  <ogra_> thats like saying "we need nodejs in the image so snaps dont need to ship it"
  <longsleep> well, python has been standard on linuxes for centuries - i am not sure if node qualifies as comparison
  <Chipaca> ogra_: not node! v8, clearly
  <davmor2> Chipaca: isn't the system-image-cli stuff written in py3?
  <Chipaca> longsleep: so has X
  <Chipaca> davmor2: yes. But that's already on the chopping block.
  <longsleep> but whatever, in my case i would need a python framework to avoid having 30 snaps each shipping python for scripting
  <Chipaca> davmor2: apparmor-click is also py3
  <longsleep> to me, removing python is the same as removing /bin/sh
  <longsleep> or /bin/bash for that matter
  <Chipaca> oh, i agree. bash should also go >:D
  <jdstrand> I'm not saying python shouldn't go, but fyi, it adds something in the neighborhood of 40M to a snap
  <jdstrand> (if using it with snapcraft, for example)
  <Chipaca> here's the thing
  <Chipaca> right now, it's in a weird state
  <longsleep> yes - i mean that would be fine if there is a framework
  <Chipaca> where we don't *promise* it'll be there
  <Chipaca> but people still depend on it
  <longsleep> true, but this is the same as with sed, awk, sh, grep
  <Chipaca> so, i think we should do two things, in order, if/when we have infinite engineering resources
  <davmor2> Chipaca: Python Roulette
  <Chipaca> or what you say
  <ogra_> bash needs to die on the snappy image :)
  <Chipaca> basically, handwavy make it possible to use a "python framework" (which isn't possible right now)
  <Chipaca> and then remove everything not *strictly* essential from the core
  <longsleep> that sounds good to me
  <jdstrand> I don't think python should be a framework
  <Chipaca> framework is wrong, hence the handwavy bit
  <jdstrand> that isn't what frameworks are for. that are explicitly not for a substitute for libraries
  <Chipaca> frameworks can't depend on things, and are for controlling access to shared resources, nothing else
  <longsleep> isnt a framework something snaps can share or rely on?
  <Chipaca> longsleep: no
  <longsleep> ah
  <jdstrand> with this sorta is, cause the interpreter is versioned
  <Chipaca> longsleep: also, frameworks can't depend on things
   * jdstrand nods to handwavy bit
  <Chipaca> longsleep: so you couldn't make a framework that depended on the "pthon" "framework" ""
   * Chipaca adds more ""s in there
  <beuno> also, you don't need all of python
   * Chipaca also adds an y
  <beuno> so surely snapcraft can improve
  <longsleep> Chipaca: i see, so how to solve that?
  <beuno> and only bring in the bits you need
  <Chipaca> longsleep: today, carry on as you were
  <Chipaca> later, we'll see
  <Chipaca> longsleep: this is long-term after-lunch-break-chat stuff
  <Chipaca> beuno: hola :)
  <beuno> o/ Chipaca
  <longsleep> Chipaca: i see :) but is later also to remove one of the pythons? Right now there is 2 and 3 isn't it?
  <Chipaca> longsleep: no, only 3
  <Chipaca> wait
  <longsleep> Chipaca: oh 2 went away then already?
  <Chipaca> 2 is also on there!
  <Chipaca> what?
  <Chipaca> i thought we'd got rid of 2
  <longsleep> thats what i mean :)
  <Chipaca> :-(((
  <longsleep> well i did not check for a while
  <longsleep> maybe it is gone now
  <beuno> Chipaca, it used to be there because of cloud-init
  <Chipaca> ahhhh
  <Chipaca> 15.04 still has it
  <Chipaca> wily does not
  <Chipaca> phewww
  <beuno> right
  <longsleep> ah ok
  <Chipaca> longsleep: rolling --> awesomeness
  <longsleep> but 15.04 is what anyone should use now right?
  <Chipaca> also, much breakage, all the time
  <Chipaca> longsleep: only if you like things that don't break all the time
   * longsleep did not check on rolling since June or something
  <beuno> longsleep, rolling is slowly becoming 16.04
  <beuno> sometimes, not slowly and not backwards compatible
  <longsleep> Chipaca: so you would agree saying that python3 will be in 16.04 - or is 16.04 after lunch break stuff?
  <beuno> if you want to stay close to the LTS and can tolerate some breakage, I'd follow rolling
  <beuno> longsleep, we don't know
  <beuno> if we can, I think we'll try and release 16.04 without Python
  <Chipaca> 16.04 is 3Ã too far into the future for humble little me to guess at
  <beuno> everyone benefits from a smaller image
  <longsleep> beuno: Ok fair enough, but i suggest you think about sharing python with multiple snaps before removing it
  <beuno> longsleep, absolutely
  <Chipaca> longsleep: yeh, in what i said above there was an ordering
  <beuno> we need the same for node, java, etc
  <Chipaca> qt
  <beuno> so it's a general problem to solve
  <Chipaca> /o\ qt
  <longsleep> Ok sounds good to me, as long as i can avoid adding python to all of my snaps
  <Chipaca> hah!
  <Chipaca> we've got python3.4 and 3.5 in wily
  <Chipaca> instead
  <longsleep> hehe
  <beuno> what's 40mb among friends?
  <Chipaca> probably a bug tho, i guess in the transition to 3.5 we forgot to update something
  <Chipaca> ogra_: ^?
   * Chipaca puts it on the floor and runs
  <longsleep> but can you agree in saying "python2 is dead" - use python3 or is there still some movement to resurrect python 2?
  <ogra_> i'm pretty sure we only seed one
  <ogra_> must be some dep that pulls in the other
  <beuno> longsleep, no chance py2 is coming back
  <longsleep> beuno: ok good thats what i wanted to hear :)
  <Chipaca> longsleep: python2 is dead. Long live python3.
  <longsleep> btw, python3 does still not support ipv6 listeners in the standard library .. totally sucks
  <ogra_> heh
  <ogra_> we dont seed any python
  <beuno> ogra_, python seeds us?
  <ogra_> some package deps seem to pul both of them in
  <ogra_> ah, wait
  <ogra_> we do seed python3-pycurl
  <ogra_> booo
  <Chipaca> longsleep: python3 does support ipv6 in the standard library, afaik, fwiw, etc
  <longsleep> Chipaca: yes but only for clients, the socketserver implementations do not
  <Chipaca> longsleep: http://pastebin.ubuntu.com/12763435/
  <Chipaca> longsleep: lies
  <Chipaca> you just need to set address_family to ipv6
  <longsleep> then ipv4 does not work
  <Chipaca> ah, yes it sucks you can't easily do both
  <Chipaca> more subclassing is needed
  <longsleep> yes that is what i mean sorry
  <longsleep> my rant was not precise enough :)
  <Chipaca> longsleep: but, http://code.activestate.com/recipes/578504-server-supporting-ipv4-and-ipv6/
  <Chipaca> that is a lot longer than it needs to be, also :)
  <longsleep> sure custom class is always possible
  <longsleep> i nowadays just use a simple go server instead
  <Chipaca> yes... yes... embrace that feeling of compiled speed
  <longsleep> Chipaca: i noticed that when implementing a workaround for bug #1480404
  <ubottu> bug 1480404 in webdm "Webdm open/manage links cannot handle https" [Critical,Confirmed] https://launchpad.net/bugs/1480404
  <longsleep> the snap now runs a redirecting web server to https, just a simple python script but that cannot do dual stack
   * ogra_ always uses a 50 line shell script for webservers :P
  <ogra_> just some bi-directional nc wrapping is enough for everyone !
  <longsleep> mhm that includes argument parsing with GET and HEAD support?
  <ogra_> sure
  <longsleep> i mean the python script i have currently has 74 lines
  <ogra_> http://paste.ubuntu.com/12763576/
  <longsleep> ogra_: ok nice, here is what i use http://paste.ubuntu.com/12763590/
  <ogra_> misses curly brackets evereywhere :P
  <longsleep> yeah
   * ogra_ grins evil
  <longsleep> we could do it with node - plenty curly there
  <ogra_> haha, yeah
  <Chipaca> ogra_: what're the []'s around \r\n for?
  <Chipaca> ogra_: in tr -d '[\r\n]'
  <ogra_> it removes linefeeds and returns
  <Chipaca> yes
  <Chipaca> but what are the []s for
  <Chipaca> works without 'em
  <Chipaca> afaict
  <ogra_> i think thats how it arrives in encoded stings
  <ogra_> (that code is like 2 years old ... i dont remember anymore)
  <jdstrand> ogra_: hey, fyi, lp:~jdstrand/+junk/ufw-snap. see the readme.md file. to create a snap: make clean ; make snap. you'll need to adjust /etc/modules-load.d/something.conf to include iptable_filter and ip6table_filter until the feature is implemented in snappy config
  <jdstrand> ogra_: it is only very lightly tested and I'm heading out for the rest of the day (US holiday), but it is there if you want to play with it
  <ogra_> jdstrand, no snapcraft ?
  <jdstrand> no, snapcraft doesn't handle --root with setup.py right yet
  <jdstrand> serguisens knows about it
  <ogra_> ah, python
  <jdstrand> it is nice having ufw on my snappy system though :)
   * jdstrand heads out
  <jdstrand> ogra_: oh, if you are interested in trying it out and find a bug and feel like filing it, feel free to file it at lp:ufw
  #snappy 2015-10-13
  <biezpal> good morning all
  <biezpal> Seems like we have faced another "random-version-string" problem, similar to https://bugs.launchpad.net/bugs/1498396
  <ubottu> Launchpad bug 1498396 in Snappy "Random string in data path breaks application" [Undecided,Fix committed]
  <biezpal> We have service in snap package with apparmor profile defined like:
  <biezpal> profile "app_ovs-init-db_0.0.1" {
  <biezpal>   capability,
  <biezpal>   ...
  <biezpal> In systemd this service exist with name "app_ovs-init-db_IDDSYPEfafNM.service" and seems like apparmor cannot change profile properly because of different names. When we trying to start service through ubuntu-core-launcher we see error:
  <biezpal> aa_change_onexec failed with -1
  <biezpal> . errmsg: No such file or directory
  <biezpal> If we change service name in apparmor profile and start service again - everything works fine.
  <biezpal> How can we configure apparmor profile to work with random named services?
  <jjohansen> biezpal: ?
  <jjohansen> biezpal: within a profile you can specify the name to transition to
  <jjohansen>   /foo px -> bar,
  <jjohansen> or you could use the the change_profile api
  <jjohansen> from a shell you can do
  <jjohansen>   aa-exec -p profile_name -- your shell command
  <jjohansen> and that will run your shell command with the specified profile_name
  <jjohansen> aa-exec is just a wrapper around the change_profile api
  <biezpal> jjohansen, but we need valid apparmor profile before snap package installed
  <biezpal> we have a list of service that should run automatically after package installed and we cannot change all profiles manually from shell
  <jjohansen> biezpal: so what kind of changes do you need to the profile?  Just changing the name, or do you need to change the profile contents?
  <jjohansen> sorry, I am reading the bug now
  <biezpal> apparmor profile that we have in snap package becomes invalid after install because of randow version in service name
  <jjohansen> biezpal: do you need the random version in the profile name?
  <biezpal> for example, profile defined for service_0.0.1 but system looking for service_IDDSYPEfafNM
  <biezpal> jjohansen, we don't need random version in profile :)
  <biezpal> cause we cannot define them in advance, before installation
  <jjohansen> right
  <biezpal> and because of it our services cannot start
  <jjohansen> so, I  am not sure what the best way to proceed from here, jdstrand will know the snap integration part much better
  <jjohansen> biezpal: unfortunately jdstrand won't come online for about 8 hours
  <biezpal> jjohansen, yes, we know :)
  <biezpal> thanks anyway
  <jjohansen> biezpal: my initial reaction is don't do that :)
  <jjohansen> it is possible to make the change_profile rule match multiple versions
  <jjohansen> and I am guessing that will be the route to go, but I'd run it past jdstrand first
  <biezpal> ok, waiting for jdstrand
  <dholbach> good morning
  <mvo> hey dholbach, good morning
  <dholbach> hi mvo
  <mvo> ogra_: hi, fwiw, I triggered a new build for vivid from proposed that contains some rest api fixes (just in case you wonder why a new build is happening right now)
  <fgimenez> good morning
  <Chipaca> mo'in
  <Chipaca> something weird is up with wily
  <Chipaca> getting stuck in emerg mode
  <Chipaca> mvo: o/
  <mvo> hey Chipaca
  <Chipaca> mvo: how's things?
  <Chipaca> mvo: did you know wily edge 199 -> 201 lands you in emergency mode right now?
  <Chipaca> mvo: (just in case you thought things were ok :-p)
  <mvo> Chipaca: uff
  <mvo> Chipaca: ok, thats alarming as it most likely affects stable in some way too
  <longsleep> good morning snappy
  <Chipaca> indeed, I am moderately alarmed by this
  <Chipaca> Chipaca code Mauve
   * Chipaca steals python *and* perl from under longsleep's feet
  <Chipaca> longsleep: morning :)
  <longsleep> hehe i switched from Perl to Python in 2001
  <longsleep> so have fun with the Perl but let me keep Python :P
  <longsleep> but aside from scripting languages, what is the best practice to create an snappy image with many snaps pre installed where some of the snaps are not in the store? I have to start with some build system for this soon - any suggestions?
  <fgimenez> hi mvo
  <mvo> hey fgimenez
  <fgimenez> i'm trying 15.04/edge r212 on kvm and it doesn't have eth0 up when started
  <fgimenez> mvo, is that a known issue? ^
  <mvo> fgimenez: not a know issue :(
  <fgimenez> mvo, i'll try to check again and ping you back, even more after sudo ifconfig eth0 up it only has a ipv6 address
  <Chipaca> fgimenez: not any eth0, or not ipv4?
  <Chipaca> ah
  <fgimenez> Chipaca, only lo
  <Chipaca> fgimenez: "ifconfig eth0 up", or ifup eth0?
  <Chipaca> fgimenez: what do you have in /etc/network/interfaces.d?
  <fgimenez> Chipaca, eth0 with: "allow-hotpug eth0\niface eth0 inet dhcp"
  <Chipaca> fgimenez: and "sudo journalctl -x"?
  <Chipaca> fgimenez: anything red in that? :)
  <mvo> fgimenez: so it might be the new kernel http://people.canonical.com/~ogra/core-image-stats/vivid/20151013.1.changes
  <fgimenez> Chipaca, :) a few about ACPI, EXT4-fs and pkcsslotd, I also get http://paste.ubuntu.com/12771951/
  <mvo> Chipaca: hm, I just upgraded rolling and no panic, let me try to reproduce again with the exact versions
  <ogra_> fgimenez, there is actually a \n in the eth0 file ?
  <fgimenez> ogra_, no, just for displaying it here :)
  <ogra_> ah, k
  <Chipaca> ogra_: excellent question :)
  <ogra_> hah, look ... my test server just started spilling autopilot reboot messages to the console ... it is on 211 ... lets see if it comes up
  <fgimenez> ogra_, latest stable was 185 on edge, right?
  <ogra_> fgimenez, yup
  <Chipaca> gah! map is not a function, it's a keyword :-(
  <fgimenez> ogra_, ok thx, i'll try upgrade and rollback from there
   * ogra_ waits for ogra2 to return ...
  <ogra_> there he is
  <ogra_> so looks like my installed/auto-upgraded server comes up fine with 212
  <ogra_> yep, all up
  <JamesTait> Good morning all; happy Tuesday, and happy Ada Lovelace Day! ð
  <mvo> Chipaca: so r199->201 is a 40mb delta update and I strongly suspect it contains a new kernel *but* for me it did not panic :(
  <mvo> Chipaca: no new kernel, sorry
  <mvo> Chipaca: do you have some more details about the recovery mode you ended up in?
  <Chipaca> mvo: it looks recoverish?
  <Chipaca> mvo: dunno what details there are to be had :)
  <Chipaca> it's a kvm in snapshot mode, so i can drop back to the old thing and redo the update any time
  <Chipaca> (and have, multiple times, and it ends up in emerg mode every time)
  <Chipaca> ah, this might be relevant
  <Chipaca> failed to exec /bin/plymouth
  <mvo> Chipaca: I thnk the pylmouth is a red-herring
  <Chipaca> ok :)
  <mvo> Chipaca: does it tell you why its in recovery mode? or is it because of plymouth and its not a red-herring at all :) ?
  <Chipaca> ah, charset not found
  <mvo> Chipaca: ha!
  <Chipaca> failed to mount /boot/efi
  <mvo> Chipaca: so that indicates that the kernel has changed but no modules
  <Chipaca> because charset not found
  <mvo> Chipaca: so a new kernel but no modules, or rather, the filesystem has a new kernel abi and the old kernel is booted which then can not load the nls8859-1 module
  <ogra_> someone dropped vfat stuff ?
  <ogra_> it shouldnt be a module anymore
   * ogra_ asked for that ages ago 
  <mvo> Chipaca: can you inspect the filesystem?
  <Chipaca> mvo: sure, what do i look for?
  <mvo> Chipaca: i.e. md5sums of /boot/grub/{a,b}/*
  <Chipaca> let me see if i can bring up ssh
  <mvo> Chipaca: and "ls /lib/modules/ /writable/cache/system/"
  <mvo> Chipaca: I actually suspect just 199->201 is not enough, something like ?->199->201, i.e. old-kernel->new->new maybe?
  <ogra_> (amd64)ogra@aleph2:~$ lsmod |grep vfat
  <ogra_> (amd64)ogra@aleph2:~$ cat /proc/filesystems |grep fat
  <ogra_> 	vfat
  <Chipaca> trying to bring up ssh froze stuff (?)
  <Chipaca> ogra_: what about nls
  <Chipaca> ogra_: problem isn't vfat
  <ogra_> nls8859-1 really needs to be compiled in, givcen that vaft is too
  <mvo> yeah, its nls8859
  <ogra_> i'm not doubting that :)
  <mvo> :)
  <ogra_> but vfat is useless without nls8859, so it needs to be compiled in too
  <mvo> all good, well, there is a bug in our code somewhere I think
   * mvo nods
  <Chipaca> where was the kernel config stored?
  <ogra_> (though it helps finding module issues :P )
  <ogra_> Chipaca, in boot (if you are lucky and the kernel is the same as in the device tarball(
  <Chipaca> mvo: before the reboot: http://pastebin.ubuntu.com/12772258/
  <Chipaca> ogra_: where in boot?
  <mvo> Chipaca: what does the module dirs look like?
  <ogra_> Chipaca, in /boot
  <Chipaca> $ ls /lib/modules/
  <Chipaca> 4.2.0-16-generic
  <Chipaca> $ ls /boot/
  <ogra_> oh !
  <Chipaca> efi  grub
  <ogra_> (amd64)ogra@aleph2:~$ ls /boot/
  <ogra_> System.map-3.19.0-31-generic  efi   initrd.img-3.19.0-31-generic  vmlinuz-3.19.0-31-generic.efi.signed
  <ogra_> abi-3.19.0-31-generic         grub  vmlinuz-3.19.0-31-generic
  <mvo> Chipaca: and the other one? /writable/cache ?
  <ogra_> no config anymore ?
  <mvo> Chipaca: and the other one? /writable/cache/system/lib/modules ?
  <Chipaca> $ ls /writable/cache/system/lib/modules/
  <Chipaca> 4.2.0-14-generic
  <mvo> Chipaca: so that is before the reboot?
  <Chipaca> yes
  <mvo> Chipaca: what is the content  /writable/cache/system/etc/system-image/channel.ini?
  <mvo> Chipaca: and /etc/system-image/channel.ini ?
  <mvo> Chipaca: so I'm super confused, /lib/modules is different on a/b but the kernel is the same but also the "other" parition has a lower version for the kernel modules than your current partition
  <Chipaca> mvo: http://pastebin.ubuntu.com/12772276/
  <mvo> Chipaca: thats puzzling
  <mvo> Chipaca: thanks, so other looks correct and yet it has the modules for 4.2.0-14-generic ?
  <mvo> Chipaca: it explains the failure, but how the systemd ended up in that state is the interessting part now :)
  <mvo> Chipaca: does it make sense so far? what I'm saying?
  <Chipaca> mvo: new system has .16 kernel and .14 modules --> how can it i don't even
  <Chipaca> mvo: makes sense to me
  <mvo> Chipaca: yeah, it does not make any sense, do you still have content in /writable/cache ? i.e. the delta update?
  <mvo> Chipaca: the delta update files?
  <mvo> Chipaca: so one theory might be that the delta update used the wrong base, e.g. "other" was "185" but the delta update used soemthing later that did no include the kernel change in the filesystem which is still a weak theory because the kernel itself was part of the delta
  <Chipaca> mvo: where in /writable/cache should i have content?
  <Chipaca> i mean, there's /writable/cache/system :)
  <Chipaca> let me start over, and see what system-image-cli has to say for itself
  <Chipaca> $ sudo system-image-cli -n
  <Chipaca> Upgrade path is 200:201
  <mvo> Chipaca: yeah, thanks. if you still have the state of before the upgrade, thats awsome, what revno was "other" before?
  <Chipaca> yes, i do still have the before-upgrade; always do kvm -snapshot here
  <mvo> Chipaca: we dtive system-image by pointing it to the "other" parition so that we get the delta download relative to this "other"
  <Chipaca> because i can commit a snapshot, but can't uncommit a non-snapshot :)
  <mvo> :)
  <Chipaca> version_detail: ubuntu=20151008,raw-device=20151008,version=197
  <Chipaca> that's /writable/cache/system/etc/system-image/channel.ini before the upgrade
  <Chipaca> (i mean, it has all the other stuff, but that's got the info you want)
  <mvo> Chipaca: could you run system-image-cli -C /writable/cache/system/etc/system-image -n
  <mvo> Chipaca: thats what snappy will do?
  <mvo> Chipaca: well, it will not use "-n"
  <Chipaca> I can, but you might not like it
  <mvo> Chipaca: this smells like a but in s-i or a bug in the way we drive it
  <Chipaca> $ sudo system-image-cli -C /writable/cache/system/etc/system-image -n
  <Chipaca> Already up-to-date
  <mvo> Chipaca: oh? well, that would explain the issue, but â¦ but?
  <mvo> why does it think its up-to-date?
  <Chipaca> mvo: wait, we get to blame barry for this?
  <Chipaca> that's always a win!
  <mvo> Chipaca: do you have --debug or something in s-i?
  <mvo> Chipaca: well, we better have hard data to backup this claim ;)
  <Chipaca> http://pastebin.ubuntu.com/12772321/
  <mvo> Chipaca: hm, I hope this getprop failure is not the issue :(
  <mvo> Chipaca: what does "sudo system-image-cli -n -v" yield?
  <Chipaca> i'm assuming that's part of the "check you're on an ubuntu phone" code :)
  <mvo> Chipaca: ups, coud you set the -C dir to "/writable/cache/system/etc/system-image/config.d" instead?
  <mvo> Chipaca: sorry, I think I pasted you the wrong dir
  <Chipaca> http://pastebin.ubuntu.com/12772343/
  <mvo> ta
  <Chipaca> http://pastebin.ubuntu.com/12772348/
  <Chipaca> âUpgrade path is 201â
  <mvo> Chipaca: I wonder what that means, if it means a full download, we are good, if it means just the 200:201 delta not so much
  <Chipaca> i think a delta is written m:n
  <mvo> Chipaca: if you run it with "--no-apply" instead of "-n", what does it download?
  <Chipaca> as in the 200:201 you get without -C
  <mvo> the download will end up in /writable/cache
  <Chipaca> 	http://system-image.ubuntu.com/ubuntu-core/rolling/edge/generic_amd64/version-201.tar.xz.asc -> /writable/cache/version-201.tar.xz.asc
  <mvo> i.e. sudo system-image-cli -C /writable/cache/system/etc/system-image/config.d/ -g -v
  <Chipaca> tadaa
  <Chipaca> http://pastebin.ubuntu.com/12772377/
  <Chipaca> includes: device-2bc2ee8db5cd33e143438171da503c2ce56eeb49adc0617872b9a099d18c2288.tar.xz
  <Chipaca> and that file has lib/modules/4.2.0-16-generic
  <Chipaca> and vmlinuz 4.2.0.16
  <Chipaca> wait, that shouldn't be a problem :)
  <mvo> Chipaca: ok, so the next suspect is the upgrader then that applies the upgrade
  <Chipaca> mvo: is that also system-image?
  <mvo> Chipaca: "sudo ubuntu-core-upgrade --dry-run --leave-files" maybe?
  <mvo> Chipaca: "sudo ubuntu-core-upgrade --dry-run --leave-files --debug" maybe?
  <Chipaca> Failed to read command file: None
  <mvo> Chipaca: is there a ubuntu_command file in /writable/cache ?
  <Chipaca> mvo: i could send you the kvm image, fwiw :)
  <mvo> Chipaca: that might be easier indeed
  <Chipaca> http://pastebin.ubuntu.com/12772390/
  <mvo> Chipaca: less learning expereince for you :P
  <Chipaca> indeed
  <Chipaca> which is why i'm not stopping you :)
  <mvo> Chipaca: I'm kidding, I will be so happy when this part gets replaced
  <longsleep> Does it make sense to test for future breakage anything other than 15.04/edge (which works fine). Should i test rolling/edge from time to time?
  <mvo> Chipaca: but maybe you will appreciate it more this way when we replace it
  <mvo> Chipaca: "sudo ubuntu-core-upgrade --dry-run --leave-files --debug /writable/cache/ubuntu_command"
  <mvo> Chipaca: sorry for my mistaken cmdline earlier
  <mvo> Chipaca: and feel free to upload your image to people.c.c or something and I can poke it harder
  <mvo> Chipaca: this command should give us some hints
  <Chipaca> ubuntu-core-upgrade: error: argument --debug: invalid int value: '/writable/cache/ubuntu_command'
  <Chipaca> :)
   * Chipaca goes with 9
  <Chipaca> whoa, that was verbose. doing over.
  <mvo> Chipaca: I get some lunch but will read scrollback
  <Chipaca> mvo: stderr: http://pastebin.ubuntu.com/12772425/
  <Chipaca> mvo: stdout looks like a tar listing, can upload if needed
  <mvo> Chipaca: hm, if you run that without --dry-run, does it unpack the right lib/modules? I suspect it will and this means something is missing here :(
  <mvo> Chipaca: i.e. somewhere what we did is not what snappy did
   * mvo really lunches first
  <olli> gm
  <Chipaca> mvo: indeed, that worked perfectly
  <Chipaca> doing over with strace
  <mvo> Chipaca: yeah, lets figure out what it execve()s :/
  <sergiusens> morning
  <Chipaca> olli: sergiusens: mo'in
   * sergiusens has a nasty cold since yesterday
  <Chipaca> so does the uk
  <Chipaca> they're calling it "autumn"
  <sergiusens> Chipaca, it snowed in the Altas Cumbres yesterday!
  <sergiusens> we are enjoying spring ;-)
  <Chipaca> wow, slightly late this year
  <Chipaca> usually it's september it snows :)
  <Chipaca> whaaaa
  <Chipaca> ok, lots of trace files :)
  <Chipaca> hah, well, that's something that went wrong
  <Chipaca> /tmp/trace.1080:execve("/usr/bin/system-image-cli", ["system-image-cli", "--progress", "json", "-C", "/etc/system-image/config.d"], [/* 23 vars */]) = 0
  <Chipaca> and that happens if it can't read the one in /writable/cache
  <Chipaca> $ ls -l /writable/cache/system/etc/system-image/config.d/00_default.ini
  <Chipaca> lrwxrwxrwx 1 root root 13 Oct 13 11:04 /writable/cache/system/etc/system-image/config.d/00_default.ini -> ../client.ini
  <Chipaca> puzzled, now
  <ogra_> why ?
  <ogra_> the old s-i-cli used /etc/system-image/client.ini by default, the new one uses the files under /etc/system-image/config.d/
  <Chipaca> i think this is related to a bug barry already fixed
  <Chipaca> with system-image not really requiring config to work
  <Chipaca> but we still treat it like it does
  <Chipaca> and system-image used to crash with a symlink, but he fixed taht
  <Chipaca> ogra_: in any case, it's doing the wrong update and getting into trouble
   * olli waves at Chipaca
  <Chipaca> i'm not sure when using the wrong config for system image is the right thing, but this isn't one of those times :)
  <ogra_> well, whats inside that client.ini  ?
  <ogra_> it should point to the new image
  <Chipaca> it's not there ^
  <Chipaca> broken symlink
  <ogra_> ah !
  <ogra_> it should be there
  <Chipaca> it refuses to bow to your imperialist views on existentialism
  <ogra_> http://paste.ubuntu.com/12772505/
  <Chipaca> i don't believe it's necessary any more
  <ogra_> (note that archive_master lives elsewhere in rolling, the above is stable)
  <Chipaca> k
  <ogra_> i thik it is still necessary
   * Chipaca buys ogra_ a box of chocolates of the wrong ABI
  <ogra_> haha
  <mvo> Chipaca: ha! so 00_default.ini is a dangling symlink on wily. nice catch. its not on 15.04 fortunately there is a client.ini there but  I think its there because I put it back
  <mvo> Chipaca: so the fix is to test for 01_channel.ini I guess (?) or 20_snappy.ini which is safer
  <mvo> Chipaca: nice work tracking this one down \o/
  <Chipaca> what are we actually testing for?
  <mvo> Chipaca: that the other partition is "valid" (no-empty)
  <mvo> Chipaca: see systemimage.go:222
   * mvo needs to vanish again for some seconds
  <Chipaca> mvo: if the question is "can system-image build an upgrade path from this", then maybe we should check with barry and update the check
  <Chipaca> mvo: there's an XXX just below where you ponted me at in systemimage.go that points at potential trouble; it doesn't say *why* it does two different checks :-/
  <mvo> Chipaca: it otherIsEmpty() contains some info, no?
  <mvo> Chipaca: i.e. we need(ed) in the old days both client and channnel config, nowdays we don't need a client config but we still need a snappy specific config
  <Chipaca> ah, so it does, so it does
  <mvo> so checking for 20_snappy.ini seems prudent (unless I miss something)
  <longsleep> When testing snappy on bare metal, how many sdcards have you folks worn out already? These things drive me crazy eventually :/
  <Chipaca> longsleep: hard drives are a consumable; sd cards more so
  <mvo> fgimenez: how big is /boot now with the alpha images and the signed kernels?
  <fgimenez> mvo, let me check
  <longsleep> Chipaca: yeah, i am just wondering if this happens to other people as well
  <longsleep> i mean, flash 100x, the odds that the card is borked seem to be big
  <Chipaca> longsleep: yes. Fortunately update is usually good enough you only rarely need a full reflash, and that helps
  <mvo> longsleep: how many cards did you loose already? and how often does it happen?
  <longsleep> mvo: this is now the third card out of 5 which stopped working since i started working with snappy in march
  <Chipaca> longsleep: how often do you reflash?
  <mvo> longsleep: all the same batch of cards? just curious if there are differences between manufactors etc
  <mvo> longsleep: seems like a lot indeed
  <longsleep> Chipaca: sure they will last longer for normal use case - though the general quality of the sdcards seem like shit, i mean these are all sandisk cards - the normal ones though. The exreme ones seem to be more durable.
  <longsleep> mvo: yes those who give i/o errors are from the same batch
  <Chipaca> longsleep: like these? http://martybugs.net/articles/images/sandisk_box_large.jpg
  <Chipaca> ah, those are cf
  <longsleep> Chipaca: around 100 times
  <Chipaca> http://ecx.images-amazon.com/images/I/61ezDfz50AL.jpg
  <longsleep> Chipaca: yes those
  <Chipaca> longsleep: check they aren't fake sandisks
  <longsleep> and i got a broken one from transcend as well
  <beuno> longsleep, FWIW, I trashed an SD card in a single night when I wrote a small app that took pictures when it detected movement, and it rained that night  :)   (it was pointing out the window)
  <longsleep> beuno: yeah - thats why i ask here, if this is a common thing others must have dead sdcards as well
  <longsleep> or do you all get the expensive ones?
  <fgimenez> mvo, 76M in bbb, 131M in amd64
  <longsleep> Chipaca: hard to tell if its a fake
  <Chipaca> longsleep: yep, seems to vary a lot
  <longsleep> Chipaca: could be, but they worked fine half a year full capacity and all. So i find it unlikely
  <Chipaca> longsleep: ah, ok :)
  <Chipaca> longsleep: these days i mostly just get the expensive ones
  <Chipaca> longsleep: but if i were working with them in bulk i'd probably be ok wiht the cheaper ones
  <longsleep> Chipaca: right, thats why i am testing the cheap ones
  <longsleep> but the Transcend one which broke today is an expensive one, only 8GB though
  <longsleep> they give 30 years limited guarantee on that one
  <longsleep> haha they do not give that guarantee for write intensive applications
  <Chipaca> i'd be tempted to get it rma'd :)
  <longsleep> they explicitly list "servers" as write intensive or continuous use case in their warranty agreement
  <longsleep> so basically they know that the card can just fail when used in a server
  <longsleep> and that is for a card which is called "Premium"
  <mvo> Chipaca: do we have a bug for the upgrade issue or should we have one? I want to ensure its tracked because I will likely forget about it because of release and all this other stuff that is going on
  <Chipaca> mvo: filing i tnow
  <Chipaca> mvo: do you know why it failed for me and not for you?
  <beuno> spite?
  <mvo> Chipaca: \o/ please add the relevant bits from irc so that we know how to fix it too :)
  <mvo> Chipaca: no idea yet, in a meeting right now so I can't check, will check tonight
  <Chipaca> beuno: +1
  <Chipaca> mvo: bug 1505682
  <ubottu> bug 1505682 in Snappy "upgrade wily/edge 199->201 failed" [Undecided,New] https://launchpad.net/bugs/1505682
  <Chipaca> mvo: let me know if i should expand it any
  <mvo> Chipaca: looks good
  <Chipaca> and wily.img.xz made it up
  <sergiusens> elopio, can you look at https://code.launchpad.net/~sergiusens/snapcraft/1500902/+merge/273444 again? or are we good already?
  <elopio> sergiusens: we are good.
  <sergiusens> elopio, \o/
  <elopio> I saw Chipaca's +1 but forgot to push mine.
  <barry> mvo: hi.  what's up?
  <mvo> hey barry, we tracked down  a issue in snappy to a broken /etc/system-image/config.d/00_default.ini symlink. this may be snappy specific I need to look further into it
  <barry> mvo: cool.  si 3.0.2 in wily at least no longer crashes on dangling symlinks, but i don't think we ever tracked down why the symlink is dangling
  <barry> (don't think it is on touch)
  <mvo> barry: ok, thanks! thats good to know
   * mvo adds it to the bug
  <barry> mvo: i'm around all day so ping me if needed
  <mvo> barry: thanks, busy with $stuff today :( but much appreciated that offer
  <barry> mvo: i hear ya :)
  <plars> ogra_:  is pi2_0.15_all.snap still available somewhere?
  <ogra_> sure
  <ogra_> there is an achive folder in the download dir
  <plars> ogra_: got it, thanks!
  <elopio> Chipaca: are you getting a vet error on trunk?
  <Chipaca> elopio: negatory
  <Chipaca> well, i could get *actual* trunk
  <Chipaca> and see
  <Chipaca> give me a mo'
  <sergiusens> Chipaca, a month?
  <ogra_> no, he typoed mvo
  <Chipaca> yes, tests are slow
  <elopio> Chipaca: http://pastebin.ubuntu.com/12773266/
  <Chipaca> definitely not getting that
  <Chipaca> and would be disappointed with everything if i did
  <mvo> ogra_: heh
  <elopio> tarmac is not getting that either, so might be a wily thing.
  <Chipaca> i'm on wily
  <Chipaca> but haven't updated
  <Chipaca> on it now
  <Chipaca> elopio: i guess i can rewrite that test to use reflect instead of the lazier printf
  <elopio> Chipaca: that might be clearer, because I'm not sure what you are testing there.
  <Chipaca> elopio: pointer equality
  <Chipaca> elopio: i want to know they're the same *actual object*
  <Chipaca> elopio: but go won't let you compare functions, it protects you from thinking two functions that compare different give different values for the same inputs
  <Chipaca> or somehting, i don't know why it doesn't let you
  <elopio> Chipaca: got it. It might be nicer to actually excercise that d.router.NotFoundHandler instead of just checking the references.
  <elopio> but I'm not sure how hard it would be to write that test.
  <elopio> and I don't understand the vet error anyway. I'm upgrading here too.
  <Chipaca> elopio: updated, still not getting that
  <Chipaca> elopio: your vet probably comes from source
  <Guest42341> omg what am i doing here???
  <Chipaca> ogra_: https://pastebin.canonical.com/141658/ <- know issue of rpi2 on rolling?
   * ogra_ grumbles about 2fa
  <Chipaca> ogra_: sorry, comes from somebody working on server side, always 2fa'd in :)
  <ogra_> definitely not known, no
  <Chipaca> ogra_: anything verterok could try?
  <mvo> Chipaca: "failed to find user uid/gid"  hu? no clickpkg or snappypkg user on this system?
  <ogra_> works flawless here
  <Chipaca> um
  <verterok> Chipaca: o/
  <Chipaca> verterok: you did install the tools ppa, didn't you?
  <ogra_> (copy pasted the command)
  <Chipaca> mvo: i'd guess an old u-d-f
  <Chipaca> pre the switch
  <ogra_> 0.31-0ubuntu1
  <ogra_> is what i use atm
  <Chipaca> verterok: ppa:snappy-dev/tools is what i mean
  <verterok> Chipaca: I have the ppa, checking the installed version
  <Chipaca> ah, ok
  <ogra_> newer should work too
  <verterok> Chipaca: I have http://ppa.launchpad.net/snappy-dev/beta/ubuntu
   * Chipaca also builds just in case
  <Chipaca> verterok: ah! no, not that one
  <Chipaca> i thought we'd deleted that one already
  <verterok> Chipaca: ok, removing and adding the new one
  <Chipaca> that has 0.23
  <verterok> yup
  <ogra_> http://paste.ubuntu.com/12773485/
  <Chipaca> tools has 0.31
  <ogra_> just for reference
  <ogra_> sergiusens, can we tunr off that azure warning for RPi builds ?
  <Chipaca> ogra_: http://pastebin.ubuntu.com/12773489/
  <ogra_> wut ?!?
  <Chipaca> ogra_: $ sudo tail -n1 /etc/sudoers
  <Chipaca> Defaults	insults
  <Chipaca> ogra_: just in case you thought sudo was all serious and only about security
  <ogra_> hah
  <qengho> I'm accustomed to, and like, having only a debian/ directory in source control and giving that to some kind of System that creates deb packages in architectures I don't own. Am I right in thinking that, in snappy, there are about five things missing from that kind of workflow?
  <Chipaca> qengho: not sure what you mean, but I'd start with "no, you are not right"
  <Chipaca> qengho: for example, lp:~snappy-dev/snappy-hub/snappy-examples has a bunch of sources of snaps in source control
  <qengho> Thanks, Chipaca. I'll look.
  <qengho> Okay, so cross-compiling is normal and expected, in this new world. And fabricating the programs for a package involves knowing something of the package, in this world too; there is no debian/rules kind of standard interface. I wish those facts were in the docs on the web site.
  <sergiusens> qengho, you want a snapcraft.yaml which defines everything, launchpad will build snaps from that
  <sergiusens> qengho, it is not open to public building just yet though
  <qengho> Huh.
  <sergiusens> qengho, more context maybe?
  <sergiusens> or huh to your huh ;-)
  <ogra_> huh huh
  <qengho> Okay, I've read most of the web site, and haven't heard of snapcraft yet.
  <sergiusens> qengho, https://developer.ubuntu.com/en/snappy/snapcraft/
  <qengho> sergiusens: I think that deserves to be merged into guides, pretty early.
  <Facu> Hi all! Question... we're installing the standard image in a raspberry pi 2... all works ok, and we can see the raspi in 'webdm.local'
  <Facu> it's nice, it works
  <sergiusens> qengho, right, Thibaut is working on that with dholbach
  <Facu> however, we want to start a *second* one, how we can change that name so we don't get BOTH trying to use webdm.local?
  <Facu> thanks!!
  <sergiusens> Facu, with snappy config and changing the hostname I think/hope
  <verterok> Chipaca: FYI, now its working  (building rolling)
  <qengho> Facu: this isn't a snappy answer, but: mdns should append numbers to avoid name collisions.   webdm.local, webdm1.local, webdm2.local
  <Facu> sergiusens, that is using u-d-f, or after it?
  <Facu> qengho, and there you don't know which one is which one :) (it will depend on boot order, right?)
  <sergiusens> Facu, after, on a running image
  <sergiusens> qengho, right there is a plan
  <sergiusens> to be fair, webdm needs lots of catching up to do
  <Facu> sergiusens, but to do that, I'd need to ssh into the raspi, and for that I'd need the IP ;)
  <qengho> Facu: Something like that. Also, there's probably a hyphen before the number, now that I think about it.
  <sergiusens> Facu, it might just be easier to connect your rpi2 to your network socket in your laptop and setup nm to share the connection
  <ogra_> sergiusens, i dont think webdm picks up the hostname
  <ogra_> it still uses webdm.local in any case
  <ogra_> (unless something changed recently)
  <Chipaca> ogra_: it only uses webdm if hostname is localhost
  <Chipaca> you need to restart the service though
  <Chipaca> so
  <ogra_> oh, i didnt know that !
  <Chipaca> echo "config: {ubuntu-core: {hostname: potato}}" | sudo snappy config ubuntu-core - | grep hostname
  <Chipaca> sudo snappy service restart
  <Chipaca> Facu: ^ those two should get you sorted
  <ogra_> creeezie ... it works !
  <sergiusens> ogra_, imagine that ;-)
  <sergiusens> ogra_, it was done for MWC fwiw
  <ogra_> ah
  <Facu> Chipaca, do you know if I can choose a different hostname at the u-d-f step?
  <ogra_> not at the u-d-f step
  <Chipaca> Facu: not unless you want to write your own oem snap
  <ogra_> you can pre-define settings inside the oem snap (but that would mean you need to use your own and are bound to always use --developer-mode )
  <Chipaca> ogra_: jinx, i guess
  <Facu> we're using developer mode already
  <Facu> ok
  <ogra_> :)
  <Facu> Chipaca, ogra_, sergiusens, qengho, thanks!!
  <elopio> fgimenez: so, what are we testing? 15.04 alpha?
  <fgimenez> elopio, yep, 14 for amd64 and 13 for armhf are the candidates
  <elopio> fgimenez: ok. And we are only missing some exploratory to see if we catch the ip issue again?
  <fgimenez> elopio, yes, the suite is passing on both (with eventual failures of the rollback test, but that's a test problem), i've tried -rollback and -update on amd64 too
  <fgimenez> elopio, also 13->14->13->14... oon amd64, i'm currently doing the same for bbb
  <elopio> fgimenez: awesome.
  <fgimenez> elopio, there's also this branch https://code.launchpad.net/~fgimenez/snappy/fix-activate-test, activate is not present in the rc images
  <fgimenez> elopio, and setupsuite does funny things on reboot :)
  <elopio> fgimenez: yeah, the setup has become scary
  <verterok> Chipaca, ogra_: hey, it's working now, old tools was the reason of my error.
  <verterok> Chipaca, ogra_: We are now seeing that the dhcp client is not starting on boot (no IP assigned to the device)...in case it's relevant let me know if you need more info about it
  <ogra_> verterok, weird, works here
  <Chipaca> verterok: more info plz :)
  <ogra_> do you use snapy config to modify the eth0 settings somehow ?
  <verterok> ogra_: no, we are sideloading a test snap. no other changes besides that
  <verterok> Chipaca, ogra_: looking at syslog
  <ogra_> oh, wait, you are using rolling
  <ogra_> that can indeed have unexpected breakage
  <elopio> fgimenez: oh, sorry, we were in the middle of something in the meeting.
  <verterok> ogra_: yes, we are on rolling
  <ogra_> (at any time)
  <elopio> fgimenez: ah, ovmf, this is the card: https://trello.com/c/I1BSZ6iV/130-run-tests-for-snappy-personal-and-uefi-boot
  <fgimenez> elopio, my connection was ugly, we can join again
  <verterok> yup, we know :)
  <elopio> fgimenez: no, don't worry. That was the last thing I wanted to mention.
  <elopio> we need to give it a try.
  <elopio> sergiusens: did you uplad the example snap?
  <elopio> *upload
  <fgimenez> elopio, ok thanks, there's the link you mentioned
  <sergiusens> elopio, oh sorry, no; which one was it?
  <elopio> sergiusens: bash config.
  <sergiusens> elopio, hah, you didn't update the version ;-
  <sergiusens> ;-)
  <elopio> sergiusens: I haven't made any changes to it.
  <sergiusens> elopio, ah, so it is a new package?
  <elopio> sergiusens: yes, it's not in the store.
  <sergiusens> elopio, uploaded
  <fgimenez> nice evening everyone o/
  <elopio> sergiusens: thanks!
  <tasdomas> hi
  <tasdomas> a quick question regarding hw-assign
  <tasdomas> let's say my snap specifies a service that requires access to a device (a pi-glow in this instance)
  <tasdomas> when I install it, the service does not have access
  <tasdomas> but even after performing hw-assign, it seems I need to restart the service for the settings to take effect
  <tasdomas> is there a nicer way of doing this?
  <ogra_> tasdomas, sadly not, there is a bug open that services should be auto-restarted though
  <jdstrand> beuno: hey, this isn't urgent-- at the next store rollout can you pull in the latest review tools?
  #snappy 2015-10-14
  <dholbach> good morning
  <tasdomas> morning
  <tasdomas> if a service requires access to a device, does it need to be restarted after hw-assign?
  <tasdomas> or is there a more elegant solution?
  <tasdomas> I noticed that the webcam-demo basically runs an executable periodically to retrieve an image, so I guess it does not have that problem
  <fgimenez> good morning
  <mvo> Chipaca: hi, a quick question about the rest api, i remember in some versions the ubuntu-core snap was not displayed, there was a question about this and I wonder if I misremember and if not if its fixed ?
  <tasdomas> does a service need to be restarted after running hw-assign for its package?
  <mvo> tasdomas: yes, this needs to be done manually at this point iirc
  <tasdomas> mvo, I see - thanks
  <tasdomas> mvo, took me a while to figure out why the webcam-demo does not need this
  <mvo> tasdomas: sorry, bug #1484645 (https://bugs.launchpad.net/snappy/+bug/1484645)
  <ubottu> Launchpad bug 1484645 in Snappy "Snappy hw-assign doesn't restart affected services" [Medium,Triaged]
  <mvo> maybe we need to raise the priority of this one
  <mvo> or at least print some warning as a stop-gap
  <JamesTait> Good morning all; happy Wednesday, and happy World Maths Day! ð
  <Chipaca> mvo: core is always displayed in the rest api, afaik
  <Chipaca> mvo: i believe the question was about when it would be displayed in the CPI
  <mvo> Chipaca: ok, in this case the question needs more context
  <mvo> Chipaca: aha, sorry, then I misread it, you should be in the CC so feel free to correct that :)
  <Guest42341> omg how do i end up on this channel???
  <tasdomas> is the source for the snappy mqtt package available anywhere?
  <Chipaca> what do you call a thing that looks like a mutex, but whose lock/unlock methods take a string and it only locks things with the same string?
  <Chipaca> i'd call it a mutex tree, except it's not a tree, it's more like a bush :)
  <mvo> Chipaca: sounds like a MutexManager to me
  <mvo> Chipaca: if I don't know what its good for I call it a manager :P
  <Chipaca> noted :)
  <mvo> Chipaca: you could of course make it something like a factory, i.e. GiveMeMutex(string) and it either gives you a ref for a new one or a existing one
  <Chipaca> mvo: yes, but there's a two-level thing going on that i'd lose
  <Chipaca> um, maybe
  <Chipaca> hm
  <Chipaca> mvo: some operations mutate the state of everything, so they need to lock a "root" mutex, whereas most things just read or mutate things on a leaf, so they *rlock* the root mutex and lock/rlock the leaf mutex
  <Chipaca> mvo: i'll push it as is, you tell me if a name pops out at you :)
  <Chipaca> mvo: http://bazaar.launchpad.net/~chipaca/snappy/lock-ness/revision/771#daemon/mutex/mutex.go
  <beuno> jdstrand, ack
  <popey> dholbach: heya, do we have a simple snapcraft example which caters for the "I have a simple C / C++ program I want to build and package as a snap?
  <dholbach> popey, https://bazaar.launchpad.net/~snappy-dev/snapcraft/core/files/head:/examples/libpipeline/
  <popey> ta!
  <dholbach> sergiusens, tedg: about the Snappy Clinic?
  <dholbach> what do you think?
  <dholbach> I mean on Friday
  <sergiusens> dholbach, didn't I reply for Monday? :-)
  <dholbach> oh?
  <dholbach> sergiusens, ok... shall we have a chat on Friday then to talk about a propoer script?
  <dholbach> tedg, ^
  <sergiusens> dholbach, that sounds like a good plan
  <dholbach> awesome... which time? 14 UTC?
  <sergiusens> dholbach, 14 sounds good
  <dholbach> rock and roll - I'll pencil something into the calendar
  <sergiusens> dholbach, I might have a baby in arms potentially crying at that time, but for something private should be fine ;-)
  <dholbach> :-)
   * dholbach hugs sergiusens
  <ogra_> must be the mate overdose if it cries :)
   * sergiusens feels the hug and hugs back
  <sergiusens> ogra_, probably, but from the mother ;)
  <ogra_> haha
  <rickspencer3> mvo, did I see "hw-assign" fixes in your snappy stable release announcement? ;)
  <mvo> rickspencer3: yes, the override bug should be fixed in r7
  <rickspencer3> mvo, is that the one that made me have to edit the apparmor profile?
  <mvo> rickspencer3: yes, I believe that this one is fixed
  <rickspencer3> \o/
   * Chipaca -> lunch
  <dholbach> mvo, ogra: got much to discuss for the call today - if not, I guess we can skip it?
  <ogra_> dholbach, nothing from me atm
  <dholbach> all right, let's skip it then
  <dholbach> from what I gathered mvo is going to be busy as well :)
  <ogra_> nah, he just pretends to :P
   * ogra_ upgrades to snapcraft 0.3 ... lets see if my snaps still build 
  <ogra_> ogra@styx:~/Devel/branches/ircproxy$ snapcraft
  <ogra_> DEPRECATED: Use "plugin" instead of "type"
  <ogra_> Pulling ircproxy
  <ogra_> ...
  <ogra_> Staging ircproxy
  <ogra_> Snapping ircproxy
  <ogra_> Generated 'ircproxy_0.1_amd64.snap' snap
  <ogra_> ogra@styx:~/Devel/branches/ircproxy$
  <ogra_> \o/
   * ogra_ changes "type" to "plugin" 
  <mvo> dholbach: skip
  <ogra_> sergiusens, well done !!
  <sergiusens> ogra_, lol, at least that works :-P
   * sergiusens wonders where zyga is
  <sergiusens> it is the perfect moment to switch to git
  <ogra_> oh, is that better to do if zyga isnt around ?
   * ogra_ didnt know 
  <sergiusens> lol
  <sergiusens> ogra_, he said he'd help with all the automation :-)
  <ogra_> ah
  <tedg> dholbach: sergiusens: sounds good
  <dholbach> cool cool
  <dholbach> sergiusens, tedg: at which time on Monday do you think we should do the Clinic?
  <dholbach> shall we maybe announce it a bit in advance?
  <tedg> If we go too early, people have an opportunity to think up hard questions.
  <tedg> Need to keep them on the edge.
  <dholbach> I'm not sure if that should be a real concern. :-)
  <tedg> Heh
  <dholbach> we're going to get those hard questions soon enough anyway :)
  <tedg> So I'm not particular on time. I guess it'd depend on who we expect the audience to be.
  <tedg> 1400UTC is a bit early for the West Coast US.
  <dholbach> ok
  <tedg> But, not sure if we're looking to include those folks or not.
  <dholbach> the latest I could offer (if you want me in there as well) is 16 UTC
  <dholbach> that's EOD (or near-EOD) for most Europeans, but I guess we could do that
  <tedg> dholbach: I think you'd have a better feel for what works than me or sergiusens
  <tedg> You choose, we'll follow :-)
  <sergiusens> dholbach, 16 utc seems like a good compromise catch all
  <dholbach> ok, let's try it - if it doesn't work, we'll do something different
  <dholbach> I'll send out the announce Thu or Fri - that should be good enough
  <sergiusens> dholbach, we should bounce the times so eventually everyone can join
  <dholbach> nice one! let's talk about that on Friday too then
   * ogra_ has lannding meeting on mondays at 16:00 UTC
  <sergiusens> ogra_, you still go to those?
  <ogra_> yes
  <sergiusens> ogra_, wow, why? :-P
  <ogra_> to help out with image build issues etc
  <ogra_> (and answer questions about plumbing which nobody else can answer anymore)
  <sergiusens> dholbach, btw, did you do your snapcraft dput magic?
  <dholbach> oh ok, no - will do
  <tedg> Did we ever add a logs command to snappy?
  <dholbach> sergiusens, https://launchpad.net/ubuntu/wily/+queue?queue_state=1&queue_text=snapcraft
  <dholbach> sitting in the queue for the release admins
  <ogra_> hmm, what is "snappy man" and why does it spill formatting chars to my console ?
  <dholbach> fgimenez, elopio: do we know why http://autopkgtest.ubuntu.com/packages/s/snapcraft/ is failing?
  <dholbach> will 0.3 fix it? :)
  <sergiusens> ogra_, that is what olli wanted, the man page (troff)
  <olli> sergiusens, I never said man or troff
  <ogra_> well, it would be nice if it was actually readable :)
  <olli> I want documentation to go to a website
  <olli> automatically
  <fgimenez> dholbach, according to this https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/s/snapcraft/20151005_190657@/log.gz there's a problem with the unit tests, let me check
  <ogra_> the funniest is that i have "snappy man" but not "snappy help" :)
  <sergiusens> fgimenez, did we disable unit test running from debian/rules?
  <fgimenez> sergiusens, no idea, currently in trunk there's no override there for the tests
  <Chipaca> ogra_: it's because you didn't want to ship troff in core. See what you've done?
  <ogra_> owww ... i didnt realize its my fault ... really sorry then
   * ogra_ seeds man :P
  <Chipaca> :-p
  <fgimenez> sergiusens, the failures are for 0.2.1 http://autopkgtest.ubuntu.com/packages/s/snapcraft/wily/amd64/ no override there either
  <ogra_> we just need to tell people to then run: snappy man|man
  <Chipaca> |man -l -
  <ogra_> yeah
  <sergiusens> fgimenez, you are talking about autopackage tests, I'm talking about the regular debuild
  <fgimenez> sergiusens, yes, in debian/rules there's only an override for dh_compress http://bazaar.launchpad.net/~snappy-dev/snapcraft/0.2/view/head:/debian/rules, the tests are not disabled there, but you are right, the errors in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/s/snapcraft/20151005_190657@/log.gz come from adt-run while executing runtests
  <sergiusens> fgimenez, dholbach so unit tests aren't running from package build, I fixed it and reproduced the error
  <sergiusens> fails during package build, works fine outside of it
  <plars> ogra_: I'm bulding rolling/edge images for rpi2 with something like: "core rolling --oem pi2.canonical --device raspi2_armhf --enable-ssh --developer-mode --channel edge" and they seem to stop working at ubuntu-core rev 9, but 8 worked. Any idea what changed between those two that might have broken things?
  <fgimenez> sergiusens, great, thx :)
  <plars> ogra_: similarly, on generic_armhf, 186 works but 187 does not
  <ogra_> plars, rpi started using the new uboot setup between 8 and 9
  <plars> ogra_: what's different about it?
  <ogra_> http://system-image.ubuntu.com/ubuntu-core/rolling/edge/raspi2_armhf/version-8.json (device=0.16 ...) http://system-image.ubuntu.com/ubuntu-core/rolling/edge/raspi2_armhf/version-9.json (device=0.16-1 ...)
  <ogra_> i have to look that up
  <ogra_> oh, that was just the addition of linux-fiirmware i think
  <ogra_> shouldnt affect booting
  <ogra_> and it wouldnt affect amd64 indeed
  <plars> ogra_: it will very likely affect things for me - remember how I have to boot the test images from usb?
  <plars> ogra_: so I'll likely need to make similar changes to uboot that boots from the mmc on our rpi2
  <ogra_> well. i was wrong the uboot change was in 0.15 already
  <ogra_> when we dropped all txt files
  <plars> ogra_: right, this problem is just affecting rpi2, nothing else
  <ogra_> so between 8 and 9 there were only minor kernel adjustments
  <plars> I'm gussing 187 for generic_armhf got the same kernel adjustments?
  <plars> *guessing
  <ogra_> no idea, i dont touch amd64 usually
  <plars> ogra_: I'm not saying amd64
  <ogra_> oh, generic_armhf, sorry, i misread
  <ogra_> might be, i didnt look at BBB for a long time either
  <plars> :)
  <plars> something in those changes broke rpi2 for us
  <ogra_> (last time for the uboot changes but they were far before that)
  <plars> ogra_: bbb works fine
  <plars> rpi2 is completely busted for the way we have to automate it though
  <ogra_> well, both are identical on the uboot level
  <ogra_> both dont use txt files anymore and require editing of uboot.env
  <plars> so either we need some other options for automating (unlikely unless they release a rev of the board with better hardware) or we need to figure out what changed and roll it back
  <ogra_> and both use the same kernel ... with RPi having a set of extra HW patches on top
  <plars> ogra_: I don't expect bbb to break here, we don't have to do this trick to make bbb boot
  <plars> ogra_: bbb boots off the sd card, just as if you had flashed it, because we can boot a stable image off of emmc
  <ogra_> http://people.canonical.com/~ogra/core-image-stats/20151002.changes thats the rootfs changes of 187
  <plars> ogra_: rpi only has one place to boot from, so we have to resort to pushing the new image to usb - did anything with usb perhaps?
  <ogra_> plars, yes, i know, i'm working on a netboot setup for the Pi as discussed with the CI team last week
  <ogra_> hopefully ready on friday
  <plars> ogra_: oh? I didn't hear about this
  <plars> ogra_: they don't tell me anything anymore :)
  <ogra_> you will still need the boot partition intact ... but it then should completely operate from ram and be able to dd a remote image from network
  <ogra_> plars, blame ursual and celso :P
  <ogra_> *ursula
  <Ursinha> me
  <ogra_> plars, anyway, the 187 changes show a new systemd and udev
  <ogra_> perhaps your issue is related to that
  <Ursinha> plars: we can't advertise features other people are working on :P
  <plars> ogra_: hah, I thought that changelog looked familiar
  <ogra_> plars, so the idea is to have a script that itercepts the uboot boot via the serial port, then dumps a netboot config in place, pulls a remote kernel and initrd ... that initrd has dd and wget inside and writes that image to SD
  <plars> ogra_: it's the same point that bbb stopped getting ipv4 addresses on boot
  <plars> ogra_: I'm not sure that this is the same bug on rpi2 though, iirc when we looked at it with serial, it's just not getting past loading the kernel
  <ogra_> yes, probably a systemd regression
  <ogra_> i think pitti actually made some changes to networking that we perhaps need to adapt to
   * ogra_ remembers seeing a mail
  <plars> ogra_: where does it boot from though? the sd that it's about to dd over the top of? what happens if something goes wrong or if the new image that you dd is bad?
  <plars> ogra_: also, we've been down the path of trying to drive uboot automatically over serial before... it's bad
  <ogra_> you are screwed if the boot partition is broken indeed
  <plars> ogra_: isn't that exactly what we're trying to avoid?
  <ogra_> you cant avoid that
  <plars> :(
  <ogra_> as you know already :)
  <ogra_> i'm doing the best we can under the restrictions we have ... nothing more ... i cant magically swing my want and make an eMMC appear on the devic
  <ogra_> e
  <ogra_> *wand
  <plars> ogra_: yeah, I know... I think the way I already use is still better when it works though
  <ogra_> plars, do cprov and Ursinha know your way ?
  <plars> ogra_: yes
   * ogra_ wonders if it makes sense that he works on this then
  <jdstrand> mvo: is there something like this http://people.canonical.com/~lzemczak/landing-team/ubuntu-touch/rc-proposed/ for snappy?
  <jdstrand> mvo: and hello :)
  <ogra_> plars, the requirement was to dd a full image to the SD
  <plars> ogra_: I think they have different needs, and can more easily tolerate needing to reflash the sd if things go bad though
  <ogra_> i assume thats will be a very rare case anyway
  <Ursinha> plars: for us it'd be to reset the device to run new tests
  <plars> Ursinha: when ev talked to me about it, it sounds like you can handle needing to reflash a few by hand every day
  <plars> Ursinha: that's harder for me
  <plars> I need to be able to automatically reset it to a stable condition
  <ogra_> you will only need to manually re-flash if the dd actually failed to write the first megabytes of the img... as long as the first partition ends up on the SD you should be fine
  <Ursinha> plars: that's sort what we need, but we need a specific stable condition :)
  <ogra_> i wouldnt expect that to be "a few per day" ... rather a few per month if at all
  <plars> ogra_: I'd be willing to give it a try
  <ogra_> i'll hand it to you once i'm done :)
  <ogra_> jdstrand, indeed there is ;) the original of that stuff ... http://people.canonical.com/~ogra/core-image-stats/
  <jdstrand> I was thinking you might've had it. thanks!
  <ogra_> jdstrand, iirc lukasz uses my logs as input, i guess he can do the same for snappy too
  <ogra_> in case you need more details
  <jdstrand> I don't, no
  <mvo> jdstrand: what ogra_ said, plus there is a script https://code.launchpad.net/~mvo/+junk/compare-channels that can be used to compare channels, e.g. "compare-channels.py ubuntu-core edge alpha". its slow though needs to download images
  <mvo> jdstrand: and hello to you as well :)
  <jdstrand> interesting, thanks :)
  <ogra_> mvo, why do you need images to compare channels ? manifests should be enough
  <mvo> ogra_: patches welcome :P
  <ogra_> well, just curious
  <ogra_> do yoou actually unpack them and compare contents ?
  <mvo> I don't know, I did that a long while ago, maybe I could not find the right manifests? sorry, I really don't remember
  <ogra_> fair enough
  <sergiusens> ogra_, mvo I bet it is because the channels don't have manifests, only cdimage has manifests
  <ogra_> sergiusens, well, index.json has all info about which manifest to look for
  <ogra_> which is what my script does
   * ogra_ makes a note to actiually store the manifests under http://people.canonical.com/~ogra/core-image-stats/ so we have the history for them
  <sergiusens> ogra_, ah, doesn't cdimage roll over though, faster than system image at least?
  <ogra_> yeah
  <elopio> sergiusens: could you please upload teh licensed snap example to the store?
  <ogra_> which is fine if you generate the changelog immediately after build
  <ogra_> but doesnt work when trying to go backwards
  <sergiusens> ogra_, that is the reason ;-) when mvo did this it was reactive to figure out something that couldn't use the sources you use ;-)
  <ogra_> i'll add some backup code to my script
  <ogra_> so we have the manifests for older images too
  <dholbach> sergiusens, snapcraft 0.3 is in wily :)
  <dholbach> https://launchpad.net/ubuntu/+source/snapcraft/
  <sergiusens> dholbach, great, I already fixed that test thing, we can dilute it to 0.4 now I hope
  <dholbach> nice!
  <sergiusens> dholbach, thanks a bunch
  <dholbach> let's open 0.4 then ;-)
  <jdstrand> mvo: fyi, I reviewed snappy-debug. please see my response to the email thread
  <sergiusens> elopio, fgimenez Chipaca I need one QA and one Chipaca to look at this :-) https://code.launchpad.net/~sergiusens/snapcraft/1506096/+merge/274418
  <Chipaca> chipaca levels are running rather low today
  <Chipaca> we'll see if we can scrounge one up for you
  <Chipaca> mvo: what's the state of https://code.launchpad.net/~mvo/snappy/snappy-snapfs-mount/+merge/273883 ?
  <mvo> Chipaca: no change yet, sorry. I need to address the comments and thing some more about your other alternative
  <Chipaca> no worries
  <mvo> Chipaca: I kind of like the property of rm -rf /apps/$name/$ver
  <mvo> Chipaca: I would like to preserve this, but maybe thats all mood with all-snap anyway because once something is mounted there the rm -rf will not work anymore anyway
  <sergiusens> mvo, btw, are we keeping SNAP_APP_DATA_PATH and others or are we going to be bind mounting that into /apps/$name/$ver/data ?
  <sergiusens> we can keep the var too ;-)
  <Chipaca> mvo: it's not strictly true anyway; there's a bunch of odds and ends in the system as well
  <Chipaca> mvo: like apparmor, seccomp, and systemd chunks
  <mvo> Chipaca: yeah
  <mvo> sergiusens: hm, once we mount the snap we could bind mount too indeed. I have no immediate plans for this though
  <sergiusens> fgimenez, can you try real quick changing the port to 9999?
  <fgimenez> sergiusens, sure, give me a second
  <sergiusens> fgimenez, I don't know why it is going to a proxy since I added 'NO_PROXY' for 127.0.0.1 :-(
  <fgimenez> sergiusens, it seems to work with lower case os.environ['no_proxy'] = '127.0.0.1' :)
  <mhall119> asac: ping
  <sergiusens> olli, ^
  <olli> mhall119, wazzup
  <mhall119> olli: Hi, earlier this year we printed some appdev flyers to give away at conferences, they highlight the developer portal and the scopes, apps and web sections, We have a space available to add something about Snappy and a link to it's section on the devportal, I just need someone to tell me what words to use
  <mhall119> olli: see https://docs.google.com/document/d/1EQ3Dm-lMMxEY584_vX10ESBlxVxin8RgIHHpPCpgtns/edit towards the bottom I have a comment for this
  <mhall119> I'd like to get snappy stuff added before asking for another batch to be printed
  <olli> mhall119, what's your timeline?
  <olli> I don't think I will get to this this week
  <mhall119> olli: if we can get it early next week, I'm going ot try and have them printed in time for FOSSETCON next month
  <olli> mhall119, I added a reminder for Mo
  <mhall119> thanks
  <manik> hey guys
  <manik> anyone around?
  <manik> how do i generate a device tarball for a particular platform?
  <tedg> I'm around, but I don't know how to do that :-)
  <manik> tedg: is there any way to tell where a device tarball came from in a given image?
  <manik> or what version it is?
  <manik> or really get any information about it?
  <manik> also, is there a way to access the contents of a .snap?
  <sergiusens> manik, your questions are rather broad
  <sergiusens> manik, there is no supported way to create a tarball
  <manik> sergiusens: thanks
  <manik> is there a way to see the snap contents?
  <sergiusens> manik, instructions on how to get started with one are here though https://developer.ubuntu.com/en/snappy/guides/porting/
  <sergiusens> manik, but to have it supported is another story
  <sergiusens> manik, to list contents of a .snap that has not been installed just dpkg -c [file.snap]
  <sergiusens> subject to change with all snaps
  <manik> ok
  #snappy 2015-10-15
  <tedg> sergiusens: So feeling a bit weird, I have to put the getting source options in setup_stage_packages() now
  <tedg> sergiusens: Because I need the source to know which packages we need.
  <tedg> sergiusens: It seems to be working, but seems kinda broken.
  <sergiusens> tedg, ok, but what are you talking about, I am missing some context
  <tedg> sergiusens: Porting catkin to snapcraft 0.3
  <tedg> sergiusens: So I need to get the source if it's on git or something to get the packages.xml
  <sergiusens> tedg, right, but this problem was alway there, right?
  <sergiusens> too many right don't make a wrong ?
  <sergiusens> rights
  <sergiusens> tedg, http://bazaar.launchpad.net/~ted/snapcraft/ros-catkin-plugin/view/head:/snapcraft/plugins/catkin.py#L121
  <tedg> sergiusens: Hmm, it worked before....
  <tedg> sergiusens: And I just changed my pull to override setup_stage_packages()
  <sergiusens> tedg, in your MP you inverted the setup_stage_packages and pull calls
  <sergiusens> tedg, I think that's why
  <tedg> sergiusens: What changed is the ordering in pull()
  <tedg> Oh, I must have unmerged that change.
  <tedg> So do you like reordering that or overrideing setup_stage_packages() better?
  <sergiusens> tedg, I'll answer with another question; are we ever going to need something from stage pacckage to satisfy a pull
  <sergiusens> tedg, ftr https://code.launchpad.net/~ted/snapcraft/ros-catkin-plugin/+merge/273048#diff-line-508
  <sergiusens> that's the inversion
  <sergiusens> tedg, I haven't checked if this change would break pip and friends
  <tedg> I'm curious if we just have bad naming.
  <tedg> If we shouldn't just call it "pre-stage-packages" and "post-stage-packages"
  <tedg> It's not that we don't need both, but we need to be clear about how they go.
  <tedg> Or, perhaps, put setup_stage_packages in the pull() for the super class.
  <tedg> Then the subclass could move it where it needs it.
  <sergiusens> tedg, I was wanting to implement pull in the base class today but I am waiting for your plugins to not cause one more update you need to do ;-)
  <tedg> Ha
  <tedg> This has touched more files than I expected
  <tedg> Everything is at least building now.
  <JamesTait> Good morning all; happy Thursday, and happy Conflict Resolution Day! ð
  <biezpal> Hi all! We have a problem with random string in package version and apparmor profiles
  <biezpal> Apparmor profile:
  <biezpal> profile "ovs_init-db_0.0.1" {
  <biezpal> But system is waiting for:
  <biezpal> ovs_init-db_IDKQMVPQVIGN
  <biezpal> We cannot specify random version while preparing snap package. How should we handle it?
  <jjohansen> biezpal: did you have a chance to talk to jdstrand
  <biezpal> jjohansen, nope :(
  <biezpal> seems like we have a 12-hours difference in time :)
  <jjohansen> sadly I am going to give the same recommendation, he is the guy you should talk to
  <jjohansen> biezpal: yeah, that is a problem, I can ping him about it tomorrow for you but I don't know how much time he will have, so he may not get back right away
  <biezpal> jjohansen, thanks
  <Chipaca> Ooops, I did it again.
  <Chipaca> https://code.launchpad.net/~chipaca/snappy/lock-ness/+merge/274547
  <Chipaca> 1k lines
  <Chipaca> how did that happen
  <davmor2> Chipaca: they let you write the code, that's normally how it happens
  <Chipaca> and i'm lovin' it
  <Chipaca> mvo_: ogra2: fwiw, the lock adds 5ms, or 10%, to the quickest rest query on bbb
  <ogra_> Chipaca, stop taling to that test guy :P
  <ogra_> *talking
  <Chipaca> ogra_: why? beuno hardly ever has time for epic dissing contests these days, so i'll take it piecemeal from davmor2
  <ogra_> haha
  <davmor2> ogra_: someone has to deflate his head otherwise he can't get through doorways and it's expensive to get building modifications done in the UK
  <ogra_> oh, and i always thought that was a beard !
  <jdstrand> biezpal: fyi, your profile name is due to the fact that you are sideloading. there was a change in snappy not too long ago that does that. it changes not only the profile name but install dir, etc, etc
  <jdstrand> jjohansen: (fyi ^)
  <Chipaca> oh, missed that
  <Chipaca> biezpal: jjohansen: holler if you need more help with that
  <Chipaca> jdstrand: good catch :)
  <jdstrand> biezpal: if this isn't working right for you, I suggest talking to Chipaca or someone else here
   * Chipaca wonders what the problem is
  <biezpal> jdstrand, we know about random string version for sideloaded apps. The problem is that we cannot specify apparmor profile because of random string version
  <biezpal> before, we could specify number version in apparmor profile, but now it doesn't work
  <Chipaca> where/why do you have to specify the version?
  <biezpal> profile name contain version which is now random
  <biezpal> apparmor profile config, first line
  <biezpal> profile "ovs_init-db_0.0.1" {
  <jdstrand> biezpal: are you using 'security-policy' in your yaml?
  <biezpal> jdstrand, yes
  <jdstrand> biezpal: see this: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/view/head:/framework-template/meta/svc.apparmor.boilerplate
  <jdstrand> biezpal: basically, have ###VAR### in there, and use ###PROFILEATTACH###, then it all gets filled in for you
  <biezpal> jdstrand, so, we can use {APP_VERSION} in our profiles, right?
  <jdstrand> yes
  <jdstrand> ###VAR### gets expanded to all those vars
  <mvo_> Chipaca: nice
  <biezpal> jdstrand, ok, thanks, we'll try it now
  <biezpal> jdstrand,  seems like I didn't get you right.. How should we define @{APP_VERSION} for our app before installation?
  <Chipaca> biezpal: so
  <biezpal> ah, I see now..
  <jdstrand> biezpal: you don't have to. it gets filled in for you on install
  <Chipaca> biezpal: do you have click-review?
  <Chipaca> biezpal: click-review would've told you about ###vars### and ###profileattach###
  <biezpal> jdstrand, Chipaca yes, I see how it works now, thanks
  <Chipaca> biezpal: holler if you get stuck again please
  <biezpal> Chipaca, sure, I will :)
  <biezpal> thanks
  <tbr> aj
  <tbr> EWINDOW
  <Chipaca> tbr: ENOCOOKIE
   * davmor2 gives Chipaca a Cookie now will you stop complaining?
  <Chipaca> davmor2: http://i.imgur.com/05bXjHW.jpg
  <davmor2> Chipaca: say Cookie one more time......I dare you!
  <kenvandine> Cookie
   * Chipaca gets behind the bulletproof glass
  <kenvandine> :)
  <longsleep> Hey folks, what does "support for secure boot" mean with the latest stable release mean?
  <longsleep> -mean
  <mvo_> longsleep: that you can enable uefi and secure boot and the system will boot signed kernels
  <mvo_> longsleep: useful for systems who need a higher level of trust etc
  <ogra_> longsleep, after you switched yu rodroid to UEFI you can use signed kernels ;)
  <ogra_> *your
  <longsleep> mvo_: signed kernel wit UEFI and microsoft keys you mean?
  <mvo_> longsleep: yes
  <longsleep> mvo_: ah ok - thanks - so not relevant for arm
  <mvo_> well, the shim is signed with the microsoft key and that uses our key for the subsequent steps
  <mvo_> longsleep: yeah
  <longsleep> yes true, is it the same shim as with normal ubuntu?
  <mvo_> yes
  <tbr> well AArgh64 servers with UEFI...
  <tbr> if they ever ship
  <ogra_> longsleep, the last two releases were rather irrelevant to arm overall
  <mvo_> I guess the mail should have clarified that its about uefi secure boot
  <longsleep> ogra_: yeah i figured that, my odroids updated flawlessly from 5 to 6 and 7 though
  <ogra_> and the next one likely as well
  <longsleep> ogra_: did you look into possibilies for secure boot on armhf?
  <ogra_> not really ... would that be possible with uboot at all ?
  <longsleep> tbr: somewhere i read that 2016 will be the year of arm64 servers
  <ogra_> wasnt that arm64 laptops ?
  <longsleep> ogra_: mhm could have been laptos - i remember it not very good
  <longsleep> ogra_: i saw some code in u-boot with which was labled secure boot using some keys fused into the soc
  <longsleep> ogra_: did not look closes yet though
  <ogra_> "fused into the soc" heh
  <ogra_> might be hard to do if you are not a manufacturer
  <longsleep> true, but getting the uboot signed might be possible somehow
  <tbr> HS silicon often uses keys from a PROM inside the soc
  <longsleep> yeah - without knowing anything .. how are the phones which use u-boot protect their bootloader?
  <ogra_> usualyl from the preloader as i understand
  <longsleep> right, and how is the preloader protected from beeing overwritten with a preloader which does not validate anything?
  <tbr> longsleep: e.g. QC usually only loads a signed loader and will not boot if it's not signed
  <ogra_> yeah
  <tbr> and most phones don't use u-boot but a-boot or that other thing
  <ogra_> and you cant easily overwrite it either
  <longsleep> right
  <ogra_> some use uboot, but only chainloaded
  <longsleep> tbr: so i asume it is pretty hard to get secure boot on arm when the soc would boot any loader
  <tbr> longsleep: just as on x86, it's not an arch dependent problem
  <longsleep> tbr: right, i see - thanks!
  <longsleep> ogra_: are there any device which do not chain load uboot with some binary boot loader blob?
  <tbr> intel will also want your firstborn if you want the secure version of their CPUs
  <longsleep> hehe
  <ogra_> longsleep, yeah, most of them ...
  <ogra_> uboot on phones is rather a rare case ... it exists though
  <tbr> TI SoCs can usually be booted with u-boot directly
  <tbr> e.g. the BB with its AM335x
  <tbr> MLO is just a minimal u-boot
  <longsleep> oh, thats cool, so no proprietary part required to boot them up?
  <tbr> correct
  <tbr> not like RPi that requires that ginormous blob to boot the GPU before it even thinks about ARM cores
  <tbr> also u-boot on x86 works well
  <tbr> and I don't mean chain loaded
  <longsleep> is that in use on x86 in some machines one can buy?
  <tbr> yes, the minnowboard max for example
  <tbr> I'm not sure if it still requires the FSP blob or if someone figured that out yet
  <ogra_> i think you can re-flash the bnootloader on ALIX boards easily
  <ogra_> they come with coreboot preinstalled though
  <longsleep> coreboot is nice, though i read that most coreboot devices still load some blob to make hardware components work
  <ogra_> might be, i have two alix boards but never examined that level
  <tbr> that's the FSP and SM
  <tbr> you can get around those in some cases
  <tbr> you will still very much need the microcode updates though
  <longsleep> yeah - i would like to know what this stuff is doing though
  <tbr> the microcode in the soc is most often barely functional
  <tbr> fsp mostly sets up RAM timings and such IIRC
  <tbr> I've heard of a coreboot fork called libreboot (how inventive!) that manages on a few devices without those
  <longsleep> oh let me google that
  <longsleep> Ministry of Freedom (UK) lol
  <longsleep> they support the t400 - not so bad
  <ogra_> t400 ... pfft ...
   * ogra_ wants a t1000 to mow his lawn
  <longsleep> eheh
  <ogra_> but thats still 600 revisions away
  <longsleep> the t400 is a little old
  <longsleep> libreboot can be flashed on the bbb
  <longsleep> that would be awesome if it then could boot snappy
   * tbr fails to see the appeal on BBB, it already has a fully open source boot process
  <longsleep> oh it has? sorry then i was just ignorant
  <tbr> 14:25:22< tbr> TI SoCs can usually be booted with u-boot directly
  <tbr> 14:25:42< tbr> e.g. the BB with its AM335x
  <tbr> 14:25:50< tbr> MLO is just a minimal u-boot
  <longsleep> so the sources for MLO are public - i did not know that
  <longsleep> i do not have a BBB either though
  <ogra_> longsleep, MLO is uboot on a diet :)
  <tbr> which is necessary due to the internal SoC ram being only 32k or such. so all it does is try to set up the RAM and find the proper U-Boot binary
  <elopio> sergiusens: I'll review your code iff you upload the licensed snap.
  <elopio> that's my price :)
  <sergiusens> elopio, deal
  <Chipaca> elopio: "licensed snap"?
  <elopio> sergiusens: do you like or dislike docstrings?
  <sergiusens> elopio, wait, can we upload now?
  <sergiusens> elopio, I like!
   * ogra_ buys a license from elopio 
  <elopio> Chipaca: yes, the one that has a funny paragraph that you have to agree with.
  <Chipaca> elopio: dude
  <sergiusens> elopio, I've just never done them properly, but I want to document the base plugin with docstrings
  <Chipaca> elopio: snappy-examples/licensed
  <elopio> I suspect you wrote that one.
  <sergiusens> Chipaca, he wants me to upload that ;-)
  <sergiusens> Chipaca, to the store
  <Chipaca> to the stoar
  <Chipaca> ok :)
   * Chipaca gets it now
  <sergiusens> elopio, I'll check on the 'all reviews must be manual' thing first
  <elopio> ogra_: the first one is free.
  <ogra_> yay
   * ogra_ feels the greed for more coming up 
  <elopio> sergiusens: I was just thinking that it's so hard for me to understand the snapcraft code because it doesn't have comments. Like this compose method.
  <elopio> I think I'd even like an example in the docstring.
  <sergiusens> elopio, ah, give me an example on how to write a 'proper' docstring and I'll do it :-)
  <sergiusens> elopio, it is not as easy as it was to do in go ;-)
  <elopio> sergiusens: https://www.python.org/dev/peps/pep-0257/
  <sergiusens> elopio, in go I jst started writing them and all was fine, the world was happy; in python there are many iplicit semantic rules :-P
  <elopio> sergiusens: I'll start documenting some things I understand.
  <elopio> then you can copy the format.
  <sergiusens> elopio, does that work for you http://paste.ubuntu.com/12791820/
  <sergiusens> elopio, ignore the runtests.sh part (that will be a separate MP)
  <sergiusens> elopio, wht is the correct way to add an example?
  <elopio> sergiusens: looks good, but not perfect.
  <elopio> sergiusens: instead of Returns, it should be Return.
  <elopio> and the first sentence should be a single line.
  <elopio> there are some tools that take the first line of the docstring as a summary.
  <sergiusens> elopio, so I have around 50 chars to express it?
  <elopio> sergiusens: yes, the short summary. Then you write as many lines you want in the following paragraphs.
  <sergiusens> elopio, it seems there are many ways to write docscrings
  <sergiusens> which I dislike
  <sergiusens> elopio, http://paste.ubuntu.com/12791994/
  <elopio> sergiusens: yes. The form we tried to follow in the tests was to stick to pep 257 as much as possible, using the sphinx tags.
  <sergiusens> elopio, I found that and then a ::param ...:: format
  <sergiusens> elopio, I saw ``keyword`` as well
  <sergiusens> elopio, just show me one docsrting from a test I can follow and I will write awesome docstrings
  <sergiusens> I dislike the fact that there is choice on how to do this ;-)
  <ogra_> but linux ius abouot choice !
  <elopio> sergiusens: https://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/tests/autopilot/ubuntuuitoolkit/_custom_proxy_objects/_common.py#L121
  <elopio> sergiusens: there's free will, but we crush it on code reviews.
  <sergiusens> elopio, does help(something) pretty format all those ::param:: declaratons btw?
  <sergiusens> elopio, should I use ''' or """ ?
  <elopio> sergiusens: I don't know about help. But the idea is to generate an sphinx html out of this.
  <elopio> sergiusens: """
  <sergiusens> elopio, is multiline allowed after ::param keyword:: ?
  <elopio> sergiusens: yes.
  <sergiusens> elopio, ah, I see it now
  <sergiusens> elopio, how do I ref a :param keyword: in return?
  <sergiusens> elopio, see, this is why I did not start doing this :-)
  <sergiusens> vmayoral, hey, since you joined, I'm interested in knowing if you have tried experimenting with faster sdcards
  <vmayoral> hey @sergiusens,
  <sergiusens> vmayoral, I talked about some of the i/o slowness with ogra_ and mvo_ and there are some ideas floating around aside from just slow sdcard that might affect you; primarily the shared usb bus
  <elopio> sergiusens: uhm, I don't know. Just name it.
  <vmayoral> sergiusens: we've ordered them, should be able to test it soon
  <elopio> http://sphinx-doc.org/domains.html#cross-referencing-python-objects
  <elopio> sergiusens: it seems you can reference attr, but not parameters.
  <elopio> sergiusens: this is the examples I mostly follow: http://sphinx-doc.org/domains.html#info-field-lists
  <sergiusens> elopio, how about this http://paste.ubuntu.com/12792139/?
  <elopio> sergiusens: perfect.
  <elopio> I tend to be more verbose on the second paragraph instead of the return keyword.
  <elopio> but as you prefer.
  <sergiusens> elopio, I wasn't sure, I just saw duplication and then saw the doc you sent me and the example from ui-toolkit :-P
  <elopio> sergiusens: just choose whatever makes you happy, and we'll copy that style. The things that are important for me are the param and return tags, and the one line summary.
  <sergiusens> elopio, great, I'll stick to this, I don't like free form :-)
  <sergiusens> elopio, the paragraph could be used to go into detail with examples
  <sergiusens> elopio, which I haven't seen how to do yet
  <elopio> sergiusens: ah, right.
  <elopio> there are two options for the examples. You can write doctest  https://docs.python.org/3/library/doctest.html
  <elopio> or you can make it free form with the sphinx syntax. Let me see if I can find a nice one.
  <sergiusens> elopio, I don't mind doctest as long as they can access the network or if that won't be a problem we will be facing on and on in the future
  <elopio> sergiusens: we don't necessarily run the doctests. We need to add a command that runs them, and we can choose not to run them while the package is being build, for example.
  <sergiusens> elopio, I'll table the doctest/examples with sphinx for now then and think about it
  <sergiusens> elopio, I've already pushed the docstring while you weren't looking
  <sergiusens> :-)
  <elopio> sergiusens: https://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/matchers/__init__.py#L49
  <sergiusens> vmayoral, great, we are looking forward to isolating the issue
   * sergiusens will brb
  <sergiusens> elopio, I uploaded licensed.canonical
  <sergiusens> tedg, is the catkin plugin ready for review? I saw some code changes but not sure if I should start code review yet
  <zyga> sergiusens: hey!
  <zyga> sergiusens: how are you
  <sergiusens> zyga, doing good, what's up?
  <zyga> sergiusens: holidays, a bit ill, enjoying rain and wind in Poland :)
  <elopio> sergiusens: thanks. I'm still confused by your branch.
  <elopio> I'm slow today.
  <sergiusens> elopio, the tests don't make it clear either?
  <elopio> sergiusens: it's like you are filling the missing properties with the values from the wiki, right?
  <sergiusens> elopio, exactly; and you might ask why I don't use .update() I guess
  <sergiusens> elopio, 1 I've had issues with it, 2 there is more to come (properties from the wiki will also do var expansion for the values)
  <elopio> sergiusens: no, I would just phrase the comments differently.
  <sergiusens> elopio, this is why we have reviews :-)
  <sergiusens> zyga, well go and relax if you are on holidays AND ill ;-)
  <elopio> sergiusens: yeah, but I don't know how to make it better. I'm trying...
  <sergiusens> elopio, exactly, I tried to explain using only a few words, maybe compose is what causes confusion and that word needs to be changed
  <elopio> sergiusens: :return: a dictionary that fills the missing values from the properties passed as an argument with values from the part in the wiki.
  <elopio> sergiusens: just a suggestion. Not sure if yours is better.
  <elopio> sergiusens: also I don't understand why would you return something if there is no wiki part. Shouldn't it raise an exception?
  <sergiusens> elopio, ah, I was trying to not use the word dictionary as that was implied in the type, but if that is fine, I don't mind using that
  <sergiusens> elopio, I can raise an exception too, that is debatable; I don't mind
  <elopio> sergiusens: I think it's clearer to raise an exception than to return a null value that later has to be interpreted.
  <sergiusens> elopio, I will raise an exception
  <sergiusens> elopio, right, as it is now, it is not a nul value, it is a nop
  <elopio> sergiusens: also, the docs are to be read by people, so make them as readable as possible. Don't worry that much about the metadata or duplication.
  <elopio> sergiusens: ah, I see. You return the same thing you get.
  <elopio> I'm inclined for the exception. The caller can take care of catching it to make it no-op.
  <sergiusens> elopio, ok, let me change that
  <elopio> sergiusens: and about the tests, I think that the name is the most important thing to make them readable.
  <elopio> instead of test_compose, I see three tests. something like
  <elopio> test_compose_must_update_missing_value_from_wiki -> you pass no source as argument
  <elopio> test_compose_must_keep_value_from_properties -> you pass source as an argument
  <elopio> test_compose_unexisting_wiki_part_must_raise_exception
  <elopio> sergiusens: and starting to nitpick, s/part1/part-from-wiki.
  <sergiusens> elopio, the nitpick I refuse as the part lives in both places :-)
  <sergiusens> elopio, but if it makes it clearer, then yeah, for the test it is fine
  <elopio> sergiusens: well, it wouln't hurt to make it more verbose like: part-that-exists-in-wiki
  <elopio> not a big deal if the name of the test is clear. And you can always throw comments instead.
  <elopio> sergiusens: anyway, now that I get what your branch does, +1. It looks correct to me.
  <elopio> I'll top approve after lunch.
  <sergiusens> elopio, I'll be fixing in the meantime :-)
  <elopio> sergiusens: and I would throw in an integration or example test.
  <elopio> but maybe not yet. We only have the curl part in the wiki, and there's no much sense in overwriting its properties. Maybe an example when we have more parts that make sense to extend
  <mvo_> Chipaca: *if* you are still around, I followed up on the snappy-snapfs-mount MP would love to hear your thoughts, but no rush, I call it a day now
  <sergiusens> tedg, maybe envvars can all be driven by the plugin and no need to have it in the parts?
  <tedg> sergiusens: Eh, I'm not sure that many people will use plugins though. I'd like to have less of them.
  <tedg> sergiusens: For instance if ROS didn't have so many relocation issues, it'd be nice if that didn't have to be a plugin. Just a repo and some stage-packages in the wiki.
  <tedg> I'm just not sure we're ever gonna live in a world where the libraries end up where we want.
  <tedg> And I hate pushing people to write shell scripts all the time.
  <sergiusens> tedg, well the thing is, for a part, we can't
  <sergiusens> tedg, as in, hey look for stuff here too
  <tedg> sergiusens: I guess I was thinking that the part would provide environment variables for things it builds. For instance "I put my data here"
  <sergiusens> tedg, right, I have that email in draft :-)
  <sergiusens> tedg, The wrapper thing is all fine and dandy to some extent for running, but building is so disparate
  <tedg> I feel like we're walking a dangerous path with encouraging so many wrappers.
  <sergiusens> tedg, so I replied and not sure if it will be for the worse :-)
  <sergiusens> tedg, wrt actual things in the pipeline, just leave a coment in the catkin branch when it is ready for another look
  <tedg> sergiusens: I think that it is, I'm building a test snap to see if it still all works.
  #snappy 2015-10-16
  <dholbach> good morning
  <fgimenez> good morning
  <dholbach> ogra_, ogra2: do you know who could help figuring out https://bugs.launchpad.net/snappy/+bug/1506480 (link to "Kernel requirements for Snappy" is broken and I'm not sure what else to link to)?
  <ubottu> Launchpad bug 1506480 in Snappy "Broken link in https://developer.ubuntu.com/en/snappy/guides/porting/" [Undecided,New]
  <Chipaca> asac: beuno: http://jimbenton.tumblr.com/image/131162934224
  <tasdomas> morning
  <Chipaca> mo'in!
  <tasdomas> the wiki specification for snappy confinement mentions an assign.yaml file that can be used instead of running the hw-assign command
  <tasdomas> however, I couldn't find any more information about it (format, etc.)
  <tasdomas> is it supported?
  <Chipaca> tasdomas: where does it mention that?
  <tasdomas> Chipaca, https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement
  <Chipaca> tasdomas: there's no assign.yaml in that doc
  <Chipaca> tasdomas: it says "assign yaml"
  <Chipaca> tasdomas: no dot
  <Chipaca> tasdomas: it's not a file; it's part of the oem config
  <tasdomas> Chipaca, ah, sorry - misread that
  <Chipaca> tasdomas: so, yes it's supported, for oem snaps
  <tasdomas> Chipaca, so for my own snap the only thing to do is use hw-assign, right?
  <Chipaca> tasdomas: right
  <Chipaca> tasdomas: what're you wanting to do?
  <tasdomas> Chipaca, I was writing a simple snappy app to control the piglow device on my orange matchbox
  <tasdomas> Chipaca, http://domas.monkus.lt/posts/2015-10-15-writing-a-snappy-application/
  <tasdomas> Chipaca, my main problem was that I need to restart the service after assigning the i2c device to it
  <Chipaca> really?
  <Chipaca> that's surprising to me -- but then i know little about i2c and the rpi2
  <Chipaca> tasdomas: are you sure it's not that you need to restart the service that uses it?
  <Chipaca> (that'd be bug 1484645 fwiw)
  <ubottu> bug 1484645 in Snappy "Snappy hw-assign doesn't restart affected services" [High,Triaged] https://launchpad.net/bugs/1484645
  <tasdomas> Chipaca, sorry - maybe I wasn't clear - my problem was that I needed to restart the service (exposed by my snappy app) that uses the i2c device
  <Chipaca> wow, it's going to be a long day
  <Chipaca> because you said exactly that
  <Chipaca> sorry :-(
  <Chipaca> tasdomas: that's a bug, we know about it, should get fixed (on rolling/edge) soonish
  <tasdomas> Chipaca, ah, cool!
  <tasdomas> Chipaca, can I bother you with one more question?
  <Chipaca> tasdomas: i dount you can bother me with a question, but you're welcome to try
  <Chipaca> doubt*
  <tasdomas> there's an mqtt snappy app available in the store - but I can't find the source for it
  <tasdomas> I want to modify it to make it mdns discoverable
  <Chipaca> tasdomas: have you tried asking the snap publisher?
  <Chipaca> or gone to the snap support url?
  <Chipaca> tasdomas: this one, i presume https://search.apps.ubuntu.com/api/v1/package/mosquitto.kartben
  <tasdomas> Chipaca, ah, will do
  <dpm> davidcalle, dholbach, looking at askubuntu, there seems to be quite a lot of questions around snappy already
  <dpm> might be worth for us looking at them in the upcoming weeks
  <dholbach> maybe we can talk about it in our next docs hour call?
  <dholbach> dpm, ^
  <dpm> it could be a good topic, yes
  <dholbach> cool
  <davidcalle> dholbach, dpm, +1
  <tasdomas> by the way, is it possible to use snapcraft to build a snappy package for a different architecture? e.g. build a RPi2 compatible package on my amd64 laptop?
  <dpm> davidcalle, dholbach, it might be worth creating a snapcraft tag as well. Right now we've got 'snappy' already, which redirects to 'ubuntu-core'
  <dholbach> yep, that makes sense
  <dholbach> ciao ppisati, do you know how we could fix https://bugs.launchpad.net/bugs/1506480? (which information should we link to in the article there?)
  <ubottu> Launchpad bug 1506480 in Snappy "Broken link in https://developer.ubuntu.com/en/snappy/guides/porting/" [Undecided,New]
  <JamesTait> Good morning all; happy Friday, and happy World Food Day! ð
  <ogra_> dholbach, ppisati should be able to help with the link
  <dholbach> cool
  <dpm> dholbach, davidcalle, do we have any document that specifies the format of the snapcraft.yaml file?
  <dholbach> dpm, no spec-like doc in our docs yet, but there's 1) https://developer.ubuntu.com/en/snappy/snapcraft/your-first-snap/ and 2) ./examples in lp:snapcraft and 3) https://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/docs/snapcraft-advanced-features.md which will land as soon as the md importer is working
  <davidcalle> dpm, closest thing we have to a spec for it in the the App dev manual
  <dholbach> ah yes, and that
  <davidcalle> It's actually quite detailed
  <dpm> davidcalle, yeah, I've gone through 1) and 2), but I've been missing a doc that is specific to snapcraft.yaml
  <davidcalle> dpm, https://docs.google.com/document/d/1Rj9nVBttx62BvGlbnkmKOzAlAIEWuLNr1QaSGe3gQDA/edit#heading=h.8o7w1g30gucy
  <dpm> ahaha
  <dpm> I had actually seen this, but couldn't figure out where, glad I wasn't going mad
  <davidcalle> dpm, not sure the link is world-readable though, hopefully next week in some form on duc...
  <dpm> yeah
  <dpm> davidcalle, dholbach, http://askubuntu.com/questions/686167/what-is-snapcraft, this might help with AskUbuntu/Stackoverflow searches to give a 5 min intro and direct folks to the site
  <Chipaca> mvo: ping
  <davidcalle> dpm, this is excellent
  <davidcalle> dpm, love it :)
  <mvo> Chipaca: pong
  <dpm> glad it if it's useful :)
  <Chipaca> mvo: this race condition with the automount unit
  <Chipaca> mvo: tell me about it
  <mvo> Chipaca: its not that much that I know - so the code will activate and start the automount unit, right after that it runs the click stuff
  <dholbach> dpm, nice one!
  <dholbach> dpm, now we can't change the URLs anymore! :-)
  <mvo> Chipaca: when I do not unpack the meta,.click dirs it will fail to generate the apparmor profiles
  <mvo> Chipaca: however ls a bit later is fine
  <dpm> dholbach, oh, I can update the link after we've done the IA rearrangement. Or just make it point to https://developer.ubuntu.com/snappy
  <mvo> Chipaca: hm, maybe its something else, need to look deeper
  <dholbach> dpm, or we add redirects - in any case, no problem :)
  <Chipaca> mvo: aiui, systemctl should not return until automount has actually started
  <Chipaca> mvo: maybe we're creating the units but not starting the .automount until later?
   * Chipaca looks
  <mvo> Chipaca: adding a sleep did not solve it, so its something else
  <mvo> Chipaca: here we go, its a missing .click/manifest in the snap :/
  <mvo> Chipaca: sorry
  <mvo> Chipaca: let me fix that
  <Chipaca> hue hue hue, to quote a brazilian
  <mvo> Chipaca: we also may want to keep the .meta for now because of "snappy list -v"
  <mvo> unless we go husks
  <Chipaca> mvo: that one i don't follow
  <Chipaca> mvo: once automount is started, any access under it will trigger the mount
  <Chipaca> mvo: even if you're accessing things that are there
  <mvo> Chipaca: so only the active snap has a automount unit
  <Chipaca> ohhhh
  <mvo> Chipaca: so snappy list -v (old snap) will not have a meta/packages.yaml
  <Chipaca> yep yep
  <Chipaca> so, yeah, leave it for now, flag it for removal when we switch to lightweights
  <Chipaca> ok
  <mvo> yeah, will do
  <Chipaca> mvo: have you checked it for speed?
  <mvo> Chipaca: not yet, no
  <Chipaca> k
  <Chipaca> mvo: the lightweight thing of looking at remote manifests does not work for sideloaded stuff though
  <mvo> Chipaca: one more complication - the hooks expect .click/$name.$origin.manifest - and the $origin is not known at build time. so we can not ship that in the snap and need to generate it
  <mvo> Chipaca: once hooks are gone this is no longer a issue of course
  <Chipaca> hooks were going to be gone "soon" since i joined
  <Chipaca> not lookin' good
  <mvo> yeah
  <mvo> there is only one left
  <mvo> but that one is pretty sticky :P
  <mvo> Chipaca: do you want me to split the branch for the snapfs-mount up more?
  <Chipaca> mvo: how would you split it?
  <Chipaca> unless you moved all the systemd stuff to .. ahem .. systemd :-p
  <Chipaca> mvo: anyway, you don't have to, but my review is slower :)
  <mvo> Chipaca: I can do that I think if it helps (I will do that in any case in this MP, your suggestion makes sense)
  <mvo> but lunch first
  <Chipaca> mvo: i'm not sure the total time would be less, so i'd say nah
  <beuno> Chipaca, lol
  <longsleep> yaml question, how can i have a binary with a _ in the name?
  <tedg> sergiusens: So I think I may need to copy the options locally to stay under the 79 character limit :-)
  <sergiusens> tedg, harr harr :-)
   * sergiusens notices that today is not talk like a pirate day
  <tedg> sergiusens: It can be here!
  <tedg> matey
  <sergiusens> tedg, I couldn't sleep last night thingking about the override of setup_stage_packages; maybe it is best to use repo.Ubuntu directly instead
  <tedg> Since we can't have casual Friday's working from home, we should have talk like a pirate Fridays.
  <sergiusens> tedg, right on
  <tedg> sergiusens: Heh, I never meant for you to lose sleep over it :-)
  <sergiusens> although my vocabulary is rather scarce
  <sergiusens> tedg, it is one of those things
  <sergiusens> I also stayed up late as I went to a docker meetup to see a bunch of old friends
  <sergiusens> learned a lot about docker and why developer like it so much
  <tedg> I'm feeling like we might need to detach the plugin lifecycle from the overall one. Like have more phases for plugins.
  <tedg> I think it is nice. I just haven't see the overlays actually work well. Seems like they always get confused for me.
  <ogra_> because you talk like a pirate to them ?
  <tedg> Stupid overlays are no fun, they never talk like pirates.
  <dholbach> sergiusens, tedg: snappy clinic planning?
  <jdstrand> mvo: hey, curious if you had a chance to review my email re snappy-debug. I know we were both pretty busy yesterday
  <mvo> jdstrand: I saw it but have not acted on it yet, sorry
  <jdstrand> mvo: ack
  <dholbach> sergiusens, I found an interesting one: http://pastebin.ubuntu.com/12799579/
  <dholbach> not sure if we support this
  <dholbach> tedg, ^
  <dholbach> I just used: apt-get source bamtools
  <sergiusens> dholbach, thanks, perfect example for custom plugin
  <dholbach> I'll leave that one for you then :)
  <dholbach> tedg, sergiusens: I added two more examples to the pad
  <Chipaca> sergiusens: i should probably have pointed you at that talk earlier
  <Chipaca> sergiusens: 's good stuff
  <elopio> mvo: Chipaca: yes! with this last test I saw the moment when the last cloud init message appeared and the moment when the mode switched to regular. It's just twice as slow as the last time I tried.
  <elopio> fgimenez: ^
  <elopio> Chipaca: tell me more about waiting for a systemd service.
  <Chipaca> elopio: it's just a for loop with a sleep and a check
  <Chipaca> elopio: give me a sec
  <elopio> Chipaca: ah, we have that.
  <Chipaca> elopio: ah! show me the code :)
  <elopio> I thought you were talking about subscribing a listener to the service or something like that.
  <Chipaca> elopio: well, you could, but why bother
  <elopio> Chipaca: https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/_integration-tests/testutils/wait/wait.go
  <elopio> to work around the workaround I will just have to increase the maxWaitRetries.
  <Chipaca> elopio: and you're waiting for bootok?
  <elopio> Chipaca: I'm waiting for snappy_mode=regular
  <Chipaca> elopio: and is that better, or worse than waiting for boot ok?
   * sergiusens wonders if it is beer o clock already
  <Chipaca> sergiusens: it is!
  <elopio> Chipaca: better, I think. Instead of checking the service, we check it's effect.
  <Chipaca> sergiusens: you should come visit. can't have beer on my own (and ellie doesn't do beers)
  <elopio> *its
  <elopio> it's beer-on-hangout o'clock.
  <Chipaca> elopio: so, yeah, looks like you're already doing the right thing and all :)
  <Chipaca> elopio: wrt increasing maxWaitRetries, maybe instead have an arch-dependent base?
  <Chipaca> elopio: ie scale checkInterval by some bogomips factor
  <elopio> Chipaca: that would be nice.
  <Chipaca> var bogomips = map[string]int{"arm": 100, "amd64": 1, etc}
  <Chipaca> and index it on GOARCH
  <elopio> I'll make a card to be able to configure the wait, with a delay factor.
  <elopio> but anyway, this is a bug :) Instead of working it around, somebody should fix it.
   * elopio looks at somebody.
  <Chipaca> elopio: which is the bug, exactly?
  <Chipaca> elopio: that you can ssh in before you can log in?
  <elopio> Chipaca: you can sign in before boot-ok. both ssh and normal log in through serial. And if you are fast with a rollback, that makes the boot crazy.
  <elopio> https://bugs.launchpad.net/snappy/+bug/1498293
  <ubottu> Launchpad bug 1498293 in Snappy "after a successful update and reboot, the bootloader snappy_mode is set to 'try'" [Critical,Triaged]
  <elopio> on bbb you don't have to be super fast. I actually can reproduce this manually.
  <Chipaca> elopio: so that's the bug
  <Chipaca> elopio: not that "try" thing :)
  <Chipaca> so, we want the boot-ok to be done *before* ssh and getty lets people in
  <Chipaca> pitti: do you remember offhand whether there's a target that would let us do that easily?
  <elopio> Chipaca: I think so. You could fix the rollback so it waits for boot-ok, but then it might affect something else.
  <elopio> Chipaca: and if you just move the log in after boot-ok, the reboot will take twice the time to let you access the board.
  <Chipaca> elopio: well, but it's letting you in before things are ready
  <sergiusens> Chipaca, I don't mind visiting; when are we having a sprint in London?
  <Chipaca> sergiusens: i have space for two for half a week every week
  <Chipaca> as long as they're not super tall :)
  <elopio> Chipaca: well, before cloud-init has finished. Most of the things are ready.
  <dholbach> tedg, sergiusens: is the announce text roughly what you expected?
  <sergiusens> dholbach, where is it?
  <dholbach> sergiusens, ah sorry - on the pad :)
  <sergiusens> dholbach, looks good, just added on clarification just in case
  <dholbach> thanks sergiusens
  <sergiusens> dholbach, btw, how hard would it be to patch clog?
  <dholbach> rock and roll
  <dholbach> let me check
  <sergiusens> dholbach, so ideally, patch CMakeLists.txt to take an arg to provide an alternate ~/.clogrc path
  <tedg> If sergiusens is happy I'm good.
   * tedg didn't keep a link to the pad :-)
  <dholbach> tedg,
  <dholbach> http://snappy.asac.ws:9001/p/snapcraft-clinics
  <sergiusens> -DLOGRC_PATH=$SNAP_APP_DATA_PATH or something like that, and then the code would need to expand the var
  <tedg> dholbach: +1
  <dholbach> sergiusens, I guess it's not too hard to do - maybe something to look into some other time?
  <dholbach> tedg, sergiusens: thibautr suggested next time we ask for proposals on what people would like to see snappified :)
  <fgimenez> have a nice weekend o/
  <sergiusens> dholbach, sounds like a good idea
  <sergiusens> dholbach, maybe at the end of the clinic we ask that question too
  <dholbach> for next time we can maybe leave it a bit more time in advance, so we can collect suggestions beforehand
  <sergiusens> elopio, very simple MP https://code.launchpad.net/~sergiusens/snapcraft/tested_or_not/+merge/274741
  <elopio>  sergiusens: why is that needed? I find it good to see if all your test code is being run.
  <elopio> if it isn't, you can probably remove it. Or you have a condition that has to be faked.
  <sergiusens> Chipaca, can we get the release from the rest api already or not?
  <Chipaca> sergiusens: i don't think that's in stable yet
  <Chipaca> sergiusens: why?
  <sergiusens> Chipaca, to be able to ask it to be able to ask the store if you know what I mean.
  <Chipaca> sergiusens: updating to latest edge to see if it's there yet
  <sergiusens> elopio, ok, it just bothers me to be honest :-)
  <Chipaca> sergiusens: wait, the release?
  <Chipaca> sergiusens: you could always get the release!
  <sergiusens> Chipaca, as in 15.04-core .. btw, I'm not saying you can't, I'm asking if you can! :-D
  <Chipaca> sergiusens: the store id is what was missing, and is there now
  <Chipaca> sergiusens: http://pastebin.ubuntu.com/12801235/
  <Chipaca> sergiusens: ^ that's the output in rolling/edge :)
  <sergiusens> Chipaca, yup, nice
  <Chipaca> sergiusens: http://pastebin.ubuntu.com/12801274/
  <Chipaca> sergiusens: that's 15.04, now
  <Chipaca> sergiusens: note the socket name has changed
  <sergiusens> Chipaca, life is good!
  <sergiusens> Chipaca, mind looking at this https://code.launchpad.net/~sergiusens/snapcraft/build-deps-request-something-missing/+merge/274749 among other complicated things in your life?
  <Chipaca> sergiusens: i don't *mind*, but it's friday afternoon and the malbec has already confessed its crimes
  <sergiusens> Chipaca, look at it and then decide ;-)
   * Chipaca obeys
  <Chipaca> sergiusens: no, that's too many lines of code for this hour
  <Chipaca> sergiusens: also, the complexity is astounding
  <Chipaca> sergiusens: flabbergasting
  <Chipaca> sergiusens: maybe split it in two or three and have a team work on it on monday
  <sergiusens> Chipaca, btw https://github.com/docopt/docopt.go
  <Chipaca> !
  <Chipaca> sergiusens: also, in that branch, i think you're using the Schwarzschild metric wrong; you need to use KruskalâSzekeres coordinates to express it like that
  <pitti> Chipaca: Before=systemd-user-sessions.service? That's "before people can log in" (I didn't read the full backscroll)
  <Chipaca> pitti: that includes ssh and getty (both tty and serial)?
  <pitti> yes
  <Chipaca> elopio: could you try that?
  <Chipaca> pitti: thanks!
  <Chipaca> pitti: can something be after: multi-user.service *and* before: systemd-user-sessions.service?
  <Chipaca> that seems to be a no-no
  <pitti> no
   * Chipaca could test, but me has already checked out
  <pitti> as multi-user is after user-sessions
  <Chipaca> suspected as much
  <Chipaca> we need to check on monday, then, whether sessions is enough
  <pitti> it has multi-user in it, after all :)
  <pitti> right; I'm just on a drive-by, need to leave again
  <sergiusens> Chipaca, let me fix!
  <sergiusens> :-)
  <sergiusens> Chipaca, I like the docopts thing, but I can't easily add help to commands
  <sergiusens> tedg, final comment wrt setup_stage_packages
  <sergiusens> and there's a merge conflict (very minor)
  <tedg> Heh
   * tedg isn't sure if he wants to look
  <tedg> sergiusens: I don't think we can use pull with the current configuration of the command. Because the superclass is just empty.
  <sergiusens> tedg, right, I mean, pull() -> handle_source_options;
  <sergiusens> tedg, then have your private implementation of setup_stage_packages keeping self.stage_packages empty (or reuse if you want)
  <tedg> Oh, I see.
  <tedg> That seems a little scarier to me...
  <sergiusens> tedg, in other words, setup_stage_packages should have always been _setup_stage_packages
  <tedg> Because then we have two overrides
  <sergiusens> tedg, 2?
  <tedg> sergiusens: We'd have to override setup_stage_packages to be null, then have pull get sources, setup deps, and then call it.
  <sergiusens> tedg, let me try and propose something
  <sergiusens> tedg, meh, I'll do this in another proposal (I'll fix the priv/pub thing first)
  <tedg> sergiusens: I think restructuring pull() also would help.
  <sergiusens> tedg, indeed, that's why :-)
  <sergiusens> well another reason why
  <tedg> I think there may need to be a "get_deps_from_source()"
  <tedg> Or something for plugins.
  <tedg> sergiusens: I'm getting an odd error with trying to copy system libs. Basically the -dev packages are bringing in symlinks and that seems to be confusing snapcraft.
  <tedg> sergiusens: Does that sound like something you've seen?
  <tedg> http://paste.ubuntu.com/12804340/
  <tedg> http://pastebin.ubuntu.com/12804368/
  <tedg> The first results in the second :-)
  <sergiusens> tedg, that is weird, the path exists but can't be copied to
  <sergiusens> tedg, does /home/ubuntu/readlinetest/parts/ginac/install/lib/x86_64-linux-gnu/ exist?
  <tedg> sergiusens: No
  <sergiusens> tedg, that is the darn problem then :-/
  <tedg> sergiusens: I'll get an MR here in a sec.
  <sergiusens> tedg, its just a mnissing os.makedirs(os.path.basename(real_path, exist_ok=True)
  <sergiusens> before the copy
  <sergiusens> tedg, what I don't get is that that lib should of been relinked to the internal one
  <tedg> sergiusens: There is no internal one because it's on the list of blocked packages.
  <tedg> sergiusens: I'm not sure that readline should be on that list though.
  <sergiusens> tedg, ah, then the makedirs missing is the correct thing to do or if it is one of those that is always on the system, add it to the skip list
  <sergiusens> tedg, right, maybe not; the only real problematic one is libc
  <sergiusens> tedg, all others come inherited from deb2snap
  <tedg> sergiusens: So, I think it found a bug, but perhaps it isn't a bad bug once we get everything more refined.
  <sergiusens> tedg, what bug?
  <tedg> sergiusens: Not making the directory
  <sergiusens> tedg, right, that is indeed a bug
  #snappy 2015-10-17
  <sergiusens> elopio, Chipaca if you get bored https://code.launchpad.net/~sergiusens/snapcraft/cleanup/+merge/274801
  <sergiusens> :-)
  #snappy 2015-10-18
  <tmk> hi
  <tmk> any1 online?
  #snappy 2016-10-17
  <lpotter> I would guess it depends on the license it is released under
  <dr1337_> ogra_: how does snappy know where to mount the /writeable partition and what to do with it?
  <ogra_> dr1337, from the initrd (and the filesystem label)
  <dr1337> ogra_ nah I mean the snap command
  <dr1337> on snapcraft.io it's /snap
  <ogra_> well, that doesnt mount the writable partition
  <ogra_> snaps are just squashfses and the /snap path is hardcoded
  <ogra_> for more details, i guess zyga might be able to point you to the right code snippets
  <dr1337> and what's the gadget snap for?
  <ogra_> it describes the image (defining what kernel, bootloader and partitioning is used)
  <xnox> is it normal that my confined snap does not have access to /tmp?
  <ogra_> xnox, no ... it should spin up its own /tmp dir
  <xnox> e.g. i would have expected for mkdtemp() calls to work, as they do with e.g. PrivateTmp= in
  <ogra_> it doesnt have access to the systems /tmp though
  <xnox> my code calls mkdtemp()
  <xnox> and i hoped that it would just work(tm)
  <xnox> ogra_, as in the execution envrionment should set-up per exec $tmpdir and set envrionemnt variables that would make mkdtemp() to work.
  <ogra_> well, that should work ... on a per-snap base though
  <ogra_> apps within the same snap should use the same /tmp ... if thats not the case, it is a bug
  <autonomouse> D$HmMo100709_ubu
  <tbr_> someone needs to change their p4ssw0rd
  <xnox> ogra_, right. I will experiment more and probably will open a bug report
  <popey> jdstrand: is there a plan to update click-reviewers-tools in xenial? I am getting different results in snap-review on my laptop than the store gives. e.g. results on this app gives me bug 1618123 locally, https://myapps.developer.ubuntu.com/dev/click-apps/6141/rev/1/
  <mup> Bug #1618123: Add a build grade attribute to snaps <Canonical Click Reviewers tools:Fix Committed by cprov> <Snapcraft:Fix Released by caio1982> <https://launchpad.net/bugs/1618123>
  <Elleo> I'm trying to implement an interface for download manager, and I'm wondering what the snappy equivalent of APP_PKGNAME and APP_ID_DBUS are for app armor rules; I managed to bodge something with SNAP_NAME, but that doesn't seem like a reliable approach
  <jdstrand> popey: eventually, yes. I'm working on a big update for snap declarations and figured I'd update it after
  <popey> jdstrand: ok, thanks.
  <mup> PR snapd#2155 opened: HACKING.md: fix spread command for reusing servers <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2155>
  <mwhudson> morphis, ogra_: do we care about any wlan drivers that do *not* support nl80211?
  <ogra_> uuh, thats probably a kernel team question
  <ogra_> (but i'd guess wwe should care about all possible drivers)
  <mwhudson> i have a half-assed version of 'ip monitor' now
  <mwhudson> now to hack up something like what 'iw monitor' would be if that existed
  <mup> PR snapd#2156 opened: many: move from flags as ints to flags as structs-of-bools <Created by chipaca> <https://github.com/snapcore/snapd/pull/2156>
  <mup> Bug #1634088 opened: Cannot activate Chinese input method for Qt app <Snappy:New> <https://launchpad.net/bugs/1634088>
  <mup> Bug #1634089 opened: Cannot activate Chinese input method for Qt app <Snappy:New> <https://launchpad.net/bugs/1634089>
  <mup> PR snapd#2157 opened: read/write boot variables in a single operation <Created by mvo5> <https://github.com/snapcore/snapd/pull/2157>
  <dr1337> hey does anyone know of a commercial product that's currently on sale that uses snappy core?
  <mato_> Hi, I've created snapcraft.yaml for application which uses tesseract. Snap package is done, but application crashes because cannot access the files in /usr/share/tesseract-ocr/tessdata. Did I miss something in sanpcraft.yaml? (permissions)
  <mup> PR snapd#2158 opened: many: remove unnecessary snap name parameter from buying endpoint <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2158>
  <mup> PR snapd#2159 opened: spread.yaml: dump apparmor denials on spread failure <Created by zyga> <https://github.com/snapcore/snapd/pull/2159>
  <mup> PR snapd#2160 opened: image: tweak the cloud-init configuration <Created by mvo5> <https://github.com/snapcore/snapd/pull/2160>
  <mup> PR snapd#2161 opened: interfaces/builtin: add dcdbas_control interface <Created by tonyespy> <https://github.com/snapcore/snapd/pull/2161>
  <mup> PR snapd#2091 closed: interfaces: tweak wording and comment <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2091>
  <mup> PR snapd#2159 closed: spread.yaml: dump apparmor denials on spread failure <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2159>
  <mariogrip> I edited the origin on https://wiki.ubuntu.com/snapcraft/parts but https://parts.snapcraft.io/v1/parts.yaml wont edit
  <mariogrip> oh! nevermind, that's the git for the source right! sorry about that
  <mariogrip> how can i access .ssh with plugs?
  <mup> PR snapd#2162 opened: interfaces: add system-power-control interface <Created by morphis> <https://github.com/snapcore/snapd/pull/2162>
  <mup> PR snapd#2155 closed: HACKING.md: fix spread command for reusing servers <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2155>
  <mup> PR snapd#2163 opened: update dependency of ubuntu-core-launcher to snap-confine <Created by mvo5> <https://github.com/snapcore/snapd/pull/2163>
  <mup> PR snapd#2164 opened: many: add supports for keeping and finding assertions with different format iterations <Created by pedronis> <https://github.com/snapcore/snapd/pull/2164>
  <mup> PR snapd#2165 opened: snap: stop using ubuntu-core-launcher, use snap-confine <Created by mvo5> <https://github.com/snapcore/snapd/pull/2165>
  <blackboxsw> qengho, any idea what might cause a system to attempt looking for /var/lib/snapd/snaps/<my_snap>_x1.snap instead of the installed proper version "12" from the snap store.
  <blackboxsw> qengho, x1 seems to be a placeholder/indicator for locally installed snaps, which mine wasn't
  <blackboxsw> could it have something to do with intermittent network connectivity somehow? like validating w/ an unavilable snap store?
  <blackboxsw> I'm getting occasional errors from ureadahead as the system is starting up trying to access *_x1 files that don't exist
  <mup> PR snapd#2148 closed: many: introduce an assertion format iteration concept, refuse to add unsupported assertion <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2148>
  #snappy 2016-10-18
  <blackboxsw> hi folks, I've just started seeing failures based on the systemd triggered auto-update of installed snaps
  <blackboxsw>  cannot refresh snap-declaration for "<mysnap>": Get https://assertions.ubuntu.com/v1/assertions/snap-declaration/16/<myid>: dial tcp: lookup assertions.ubuntu.com on 127.0.1.1:53: server misbehaving
  <blackboxsw> have we changed something with the snap store recently that could cause some of the snap auto-refresh services to fall over?
  <mup> PR snapd#2166 opened: snap: stop using ubuntu-core-launcher, use snap-confine <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2166>
  <mup> PR snapd#2163 closed: debian: update dependency of ubuntu-core-launcher to snap-confine <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2163>
  <dr1337> hey guys, anyone know where the snappy builder repos are being pulled from?
  <dr1337> like this one ? https://github.com/alexgg/ccimx6sbc-snappy
  <qengho> blackboxsw: No idea, without looking in source code.
  <blackboxsw> qengho, no worries, it seems intermittent
  <blackboxsw> I've seen many clients already update our snap via the auto-refresh mechanism.
  <blackboxsw> so I don't know if it was a temporary 404 of some content during a rollout
  <dr1337> Does anybody know what SNAP_CONTEXT environmental variable is for?
  <qengho> https://github.com/snapcore/snapd/search?utf8=%E2%9C%93&q=SNAP_CONTEXT
  <mup> PR snapd#2165 closed: snap: stop using ubuntu-core-launcher, use snap-confine <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2165>
  <mup> PR snapd#2166 closed: snap: stop using ubuntu-core-launcher, use snap-confine <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2166>
  <zyga> jdstrand: https://github.com/snapcore/snap-confine/pull/172/files
  <mup> PR snap-confine#172: Improve decoding of mount flags <Created by zyga> <https://github.com/snapcore/snap-confine/pull/172>
  <zyga> jdstrand: https://github.com/snapcore/snap-confine/pull/172/files
  <zyga> oh, sorry
  <jdstrand> zyga: heh, nice :)
  <jdstrand> I'm not going to review it right this second as I want to be more awake for the review, but added to my list
  <dr1337> qengho: thanks
  <mup> Bug #1621525 changed: classic environment variables for daemon snaps <Snappy:Fix Released> <https://launchpad.net/bugs/1621525>
  <ogra_> cjwatson, did some LP branch land last night or did the store change .... ?
  <ogra_> Launchpad uploaded this snap package to the store, but the store failed to
  <ogra_> scan it:
  <ogra_>   __all__: The upload does not appear to be a valid package.
  <ogra_> https://launchpad.net/~snappy-dev/+snap/core/+build/7240
  <ogra_> gotthat for all core and ubuntu-core builds tonight ...
  <cjwatson> ogra_: src/devportal/clickapp_forms.py:            msg = _("The upload does not appear to be a valid package.")
  <cjwatson> ogra_: so this is an SCA problem I'll bet
  <cjwatson> last SCA rollout was Friday though
  <cjwatson> and this succeeded yesterday
  <ogra_> cjwatson, yeah, weird ... i spoke to cprov when smoking about it
  <ogra_> he is taking a look now
  <cjwatson> ogra_: could yet be that we're sending the wrong data in the form, but the "__all__" smells of a bug on the SCA side to me
  <ogra_> yeah, smells like it mis-takes the architecture for the name or some such
  <cjwatson> ogra_: I don't think that's architecture, I think that's more like the __all__ special name in Python
  <cjwatson> given the double underscores
  <ogra_> hmm, yeah, or that :)
  <cjwatson> but there is no good reason for that to leak into error messages absent a bug :)
  <mup> PR snapd#2167 opened: Do not remove seed <Created by chipaca> <https://github.com/snapcore/snapd/pull/2167>
  <kyrofa> enoch85, you trying to reach me?
  <mup> PR snapd#2168 opened: snap/squashfs: try to hard link instead of copying. Also, switch to osutil.CopyFile for cp invocation <Created by chipaca> <https://github.com/snapcore/snapd/pull/2168>
  <zyga> jdstrand: hey, can you please ack and land https://github.com/snapcore/snap-confine/pull/172
  <mup> PR snap-confine#172: Improve decoding of mount flags <Created by zyga> <https://github.com/snapcore/snap-confine/pull/172>
  <zyga> Pharaoh_Atem: hey
  <zyga> Pharaoh_Atem: can you perhaps get into the xdistro room if you are not in a session now
  <dr1337> ogra_ is the system-a and system-b partition structure with writable still apply to the /snap partition structure?
  <dr1337> what about /var/snap ?
  <ogra_> dr1337, thats dead since 15.04
  <dr1337> :/
  <dr1337> ogra_ where's the new documentation?
  <mup> PR snapcraft#777 closed: go plugin: don't put debugging symbols in generated binaries <Created by teknoraver> <Closed by teknoraver> <https://github.com/snapcore/snapcraft/pull/777>
  <cprov> ogra_: other LP built snaps are working fine, including store release. Come by, when you have time, so we can take a closer look on what's going on and how to improve the error message.
  <cjwatson> ogra_,cprov: c-r-t passes on that snap, at least; I wonder if the scan data is nonsense
  <cprov> cjwatson: what's the LP snap url ?
  <cjwatson> cprov: https://launchpad.net/~snappy-dev/+snap/core/+build/7241
  <cjwatson> cprov: well, ogra_ reported https://launchpad.net/~snappy-dev/+snap/core/+build/7240, but either way
  <cprov> cjwatson: yeah, same error
  <ogra_> yeah, i got a whole set of ten snaps that exposed it
  <cprov> cjwatson: the error is indeed coming from the store, src/devportal/clickapp_forms.py :-/
  <cjwatson> cprov: William pointed out that the __all__ bit probably means it's a django form-global error
  <cjwatson> was anything deployed yesterday?  CUD say?
  <cprov> cjwatson: which seems to be accurate.
  <Son_Goku> zyga: it begins... https://github.com/Conan-Kudo/snapcraft/commit/c960914b97440e2dca7a66c22c07438d809590fc
  <cjwatson> ogra_: the failure is because /var/lib/snapd/void changed from mode 0700 to mode 0000
  <cjwatson> ogra_: this appears to crash the review tools
  <ogra_> woah
  <ogra_> thats mvo'S fault then i guess. he changed something regarding the writable paths yesterday that could cause this
  <ogra_> hmm, he says it must be the review tools
  <cjwatson> the same version of the review tools seem to work for me
  <ogra_> with 0700 you mean ?
  <cjwatson> with 0000
  <ogra_> hmm, so why dont they work in the store then
  <cjwatson> but I don't know SCA well enough, maybe there's some confinement going on or something
  <ogra_> yeah, sounds like an environmental problem then
  <cjwatson> cprov: do you know if this error was directly from click-review, or if it was from the SCA task?
  <enoch85> kyrofa: I was, but I solved it with oparoz
  <qengho> Who approves new app names for Ubutu snap store? I thought it was automatic if not in a blacklist.
  <qengho> The FJKong tried to register something. It awaits some review or something.
  <ogra_> a  name that was already taken ?
  <ogra_> (usually it does not block)
  <qengho> I can not imagine it was taken.
  <ogra_> then it should just work i think ... (definitely did for me the last times i registered one, though admittedly that was a while ago)
  <qengho> Me too.
  <FJKong> ogra_: thanks I got the problem solved
  <FJKong> I got answer from cprov
  <qengho> Should all names be suffixed with a hyphen and a username? FJ wanted to register 'qrq'. There is no chance that there will be a conflict in names.
  <cprov> qengho: only in the case the requester is not the upstream or doesn't have a clear relation with it.
  <mup> PR snapd#2169 opened: interfaces/builtin: finish decl based checks <Blocked> <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2169>
  <FJKong> cprov: I think this package is no longer maintained any more by upstream
  <qengho> FJKong: I guess you need to become upstream!
  <FJKong> ye, glad to do that
  <qengho> Okay, not a snappy problem then.
  <cjwatson> ogra_: narrowed down.  can you please file a bug against software-center-agent for this?
  <cjwatson> ogra_: working on a fix
  <ogra_> doing ...
  <ogra_> cjwatson, bug 1634443 (feel free to adjust summary/description to be  more accurate)
  <mup> Bug #1634443: changing directories like /var/lib/snapd  to 0000 mode causes review-tools to misbehave <Software Center Agent:New> <https://launchpad.net/bugs/1634443>
  <kyrofa> enoch85, good deal
  <ogra_> lool, https://bugs.launchpad.net/bugs/1621380
  <mup> Bug #1621380: console-conf should allow to configure a hostname <Snappy:New> <subiquity (Ubuntu):In Progress> <https://launchpad.net/bugs/1621380>
  <lool> ogra_: added to notes, thakns
  <bencc> do I need to install something to run snap packages on ubuntu 16.04 server?
  <Chipaca> bencc, "apt install snapd" should be enough
  <bencc> Chipaca: thanks
  <bencc> I'm considering packaging minio
  <bencc> https://github.com/minio/minio
  <Chipaca> bencc, nice!
  <mup> PR snapd#2170 opened: tests: use the snapd-control-consumer snap from the store <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2170>
  <mup> PR snapd#2164 closed: many: add supports for keeping and finding assertions with different format iterations <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2164>
  <pstolowski> matiasb, ping
  <matiasb> pstolowski, o/
  <pstolowski> matiasb, hey, are you going to join store filtering session?
  <matiasb> pstolowski, I guess I can be there if it helps
  <pstolowski> matiasb, i think there is some confusion about what this session is about.. looks like client-side filtering and we may need to know what store is capable of et
  <pstolowski> etc
  <pstolowski> matiasb, it's in rembrandt
  <matiasb> pstolowski, ack
  <pstolowski> in 4 minutes
  <mup> PR snapd#2171 opened: tests: reenable ubuntu-core tests on qemu <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2171>
  <fgimenez> hey om26er, i'm in potter, well now i'm heading to the coffee machine :)
  <om26er> fgimenez: was just going to ask if you have the TTL cable, now borrowed HDMI from IS.
  <desrt> Chipaca: hihi
  <Chipaca> desrt, o/
  <desrt> Chipaca: got a chance to chat about XDG_RUNTIME_DIR inside of snaps?
  <desrt> am happy to meet in a hallway somewhere if you have some minutes
  <Chipaca> desrt, in half an hour?
  <desrt> sure
  <desrt> i'm in the desktop room if you want to come get me
  <om26er> fgimenez: Hey! if you have a wifi dongle, please bring that as well
  <fgimenez> om26er: ok, are you on the unity8 room?
  <om26er> yes
  <om26er> fgimenez: yes
  <mup> PR snapd#2156 closed: many: move from flags as ints to flags as structs-of-bools <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2156>
  <desrt> Chipaca: around?
  <mup> PR snapcraft#870 opened: sources: Add RPM source <Created by Conan-Kudo> <https://github.com/snapcore/snapcraft/pull/870>
  <mup> PR snapd#2151 closed: asserts,interfaces/policy: allow OR-ing of subrule constraints in plug/slot rules <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2151>
  <Chipaca> desrt, was around for a bit, missed your message here when i was out
  <Chipaca> desrt, want to come by Potter?
  <desrt> sure
  <lazyPower> lool you're my new best friend :)  *much fanfare*
  <lool> lazyPower: Hmmm?
  <lazyPower> that mail to the snap list about the docker snap being available for testing
  <lool> :-)
  <lazyPower> lool - its suspiciously well timed as well - http://imgur.com/a/7nKwM
  <lool> wow!
  <lazyPower> armhf lab, 6 ssd backed rpi2/3's
  <lazyPower> its not as fast as a proper ssd, but at least the storage is reliable ;)
  <lool> lazyPower: BTW do you know you can network boot rpi3?
  <lazyPower> i do but its a one way change, adn i wasn't ready to commit
  <lool> yeah, same here  :-)
  <lazyPower> i have been following the discussion on those addon wifi cards
  <lazyPower> sounds interesting enough
  <lazyPower> when we can maas enlist these boards, i'll be in nirvana
  <lool> lazyPower: is there a maas driver for devices without bmc?
  <lazyPower> i dont think so, but i'm not positive. I'd have to poke the #maas group
  <lool> lazyPower: how do you intend to drive power from maas for the rpis?
  <lazyPower> lool - well, the idea is that any time the board boots, it should read and attempt a pxe boot. maas will not re-pxe boot a provisioned machine so it should hten default to booting off the curtained disk
  <lazyPower> so i could in theory build a usb power brick with some additional love from a pi that can change power states on the ports
  <lazyPower> but thats WIP that has yet to be done, and that would be my first hardware hack in a heck of a long time
  <lazyPower> but i'm game to spend some weekends cycling on it
  <niemeyer> rharper: ping
  <rharper> niemeyer: here
  <niemeyer> rharper: Heya
  <rharper> hey
  <niemeyer> rharper: Looking into that cloud-init detail from PR snapd#2160
  <mup> PR snapd#2160: image: tweak the cloud-init configuration <Created by mvo5> <https://github.com/snapcore/snapd/pull/2160>
  <mup> Bug #1620442 changed: snap fails because XDG_RUNTIME_DIR is set to /run/user/1000 <snapd-interface> <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1620442>
  <lazyPower> lool - i was actually looking for a programmable usb hub/power-brick, and the only one i found was intended for telescope equipment, and its to the tune of 250 USD which is quite expensive for what its doing.
  <mup> PR snapd#2172 opened: asserts,interfaces/policy: implement on-classic plug/slot constraints <Created by pedronis> <https://github.com/snapcore/snapd/pull/2172>
  <lazyPower> lool - so seems like we're also hitting an edge of a product market that doesn't exist yet
  <niemeyer> rharper: How does the logic take place when there is both a default cloud.cfg and something else on .d?
  <rharper> niemeyer: cloud-init does a dictionary based merging of all of the yaml cfg files present
  <rharper> so loading /etc/cloud/cloud.cfg and any *.cfg that's yaml in /etc/cloud/cloud.cfg.d
  <niemeyer> rharper: How do we take an option off if they're mergeD?
  <rharper> I believe setting the value to None, or empty should suffice
  <niemeyer> rharper: Ok, so in theory if we use the full cloud.conf, will it work the same way?
  <niemeyer> rharper: Well, in practice actually? :)
  <iliv_> is there a way to specify a target for make in the snapcraft.yaml file?
  <rharper> niemeyer: I can test that quickly by duplicating /etc/cloud/cloud.cfg and putting that in /etc/cloud/cloud.cfg.d/cloud.cfg
  <rharper> niemeyer: I expect it to work the same; yes
  <niemeyer> rharper: Thanks, it'd be nice to have some certainty about how this work as we'll be baking it into snapd proper.. if it's just a sum, then that's nicer indeed
  <lool> lazyPower: one of the old ones we used was http://www.digital-loggers.com/lpc.html
  <lool> lazyPower: but it's still fairly expensive and in my case the US power sockets are annoying
  <lazyPower> ah yeah i was hoping to avoid the AC power plug all together and get power-controlled USB ports instead
  <lazyPower> but this is a good lead, i should look into getting a managed power-switch
  <rharper> niemeyer: in general though, we'd like to avoid duplicating the default cloud.cfg in the gadget;
  <niemeyer> rharper: I'm still not entirely sure that's a good idea, but as long as the results of including a full cloud.cfg are the same, that should be okay
  <rharper> niemeyer: to be fair, the current cloud.conf file was never the full config; for example, it left off the 05_logging.cfg which is in /etc/cloud/cloud.cfg.d/ ... so current users of that miss configuring that and cloud-init.log remains empty
  <rharper> niemeyer: I'm interested in any scenario you think might not work ...  ;
  <lazyPower> lool but to be fair, i think i'll wait for that maas work first :) then i'll invest in a managed power switch
  <lazyPower> until then, the plugin will be "manual" - as in, i get off my bum and to plug/unplug the board.
  <lazyPower> s/to/go/
  <niemeyer> rharper: The problem is cloud.cfg changing behind the gadget's back, which is exactly the motivation for doing this
  <niemeyer> rharper: Somebody cooking an image for a particular environment will not expect these settings to magically change after an update
  <rharper> niemeyer: right, if the core snap (or cloud-init snap) updated;
  <niemeyer> rharper: Which it does all the time, right? :)
  <rharper> the cloud.cfg is pretty static actually
  <rharper> but the concern you raise is real
  <niemeyer> rharper: Right, but if the point is that it's okay because it doesn't change, then why are we doing this? :)
  <rharper> because almost zero folks copying in the correct cloud.cfg and it clobbered the default configureation
  <rharper> this meant that cloud-init ran but didn't do anything as the list of datasources and config modules to run was empty
  <niemeyer> rharper: Can you rephrase this?  I didn
  <niemeyer> 't get the real point behind the comment
  <rharper> sure:  previous behavior was:  gadget needs 'cloud.conf' or cloud-init is disabled;  if cloud.conf exists, copy cloud.conf to /etc/cloud/cloud.cfg;  the overlay of cloud.cfg requires extracting the default cloud.cfg and the contents of /etc/cloud/cloud.cfg.d/*.cfg to bundle the correct default configuration
  <rharper> ideally we'd not punish cloud-init users by requiring that assembly of configuration into a single file
  <niemeyer> rharper: In the previous phrasing you mentioned a bug (didn't do anything because ...).. what was the cause/consequence?
  <rharper> niemeyer: the bug was that the conf clobbers the default cloud-init config;
  <niemeyer> rharper: Okay.. I thought they were actually trying to clobber it
  <rharper> niemeyer: hrm; ok
  <rharper> niemeyer: I do think that puts almost too much burden on gadget creator to understand all of cloud-init's defaults (or at least to learn how to extract it all from cloud-init deb)
  <rharper> niemeyer: I agree that if a gadget wanted to disable the default config then overwriting the cloud.cfg in the core snap is the right way to do that;
  <rharper> niemeyer: I don't think folks would realize that they might also need the 05_logging.cfg and other defaults to get the same behavior one would get on a cloud-image
  <niemeyer> rharper: There's a grub.conf right next to it, and a gadget.yaml with a detailed specification of partitions..
  <niemeyer> rharper: I'm more concerned about behavior changing behind people's back than about them having to cargo cult a nice example
  <rharper> niemeyer: isn't that a general concern w.r.t conf files versus code in the core snap  ?
  <niemeyer> rharper: Hmm.. in which sense?
  <rharper> we could include a configuration file for  some other package in the core snap and an update could change behavior despite the config in the gadget
  <iliv_> is there a way to make snapcraft cd into a specific directory before calling the make plugin? in this case, a Makefile includes another Makefile and the path to the second file is relative.. so it never gets included as apparently snapcrafts cwd is not where the first Makefile resides.
   * iliv_ wondering if ogra_ might be able to help. He usually does :P
  <nacc> iliv_: i believe you might need to write a custom plugin then (pretty easy to do)
  <nacc> iliv_: it can probably inherit almost everything from the make plugin, except for the actual building step which knows about the details of your setup
  <iliv_> hmm
  <iliv_> alright
  <iliv_> thanks nacc
  <iliv_> where do I find make plugin's source code btw?
  <nacc> iliv_: that's what i've done in the past, at least
  <nacc> iliv_: it should all be in github (snapcraft iirc)
  <zyga> jdstrand: hey
  <zyga> jdstrand: I got notified about this bug earlier https://bugs.launchpad.net/snap-confine/+bug/1620442
  <mup> Bug #1620442: snap fails because XDG_RUNTIME_DIR is set to /run/user/1000 <snapd-interface> <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1620442>
  <zyga> jdstrand: it looks easy technically but I wanted to ask you about your opinion first
  <mup> PR snapd#2171 closed: tests: reenable ubuntu-core tests on qemu <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2171>
  <mup> PR snapd#2173 opened: overlord/snapstate: move trash cleanup to a cleanup handler <Created by chipaca> <https://github.com/snapcore/snapd/pull/2173>
  <mup> PR snapd#2174 opened: store: send supported max-format when retrieving assertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/2174>
  <Chipaca> jdstrand, whereabouts are you?
  <mup> PR snapd#2132 closed: interfaces/builtin: enable out of process providers for locationd <Created by vosst> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2132>
  <Chipaca> jdstrand, dude we can tell you're not at the museum :-p
  <mup> PR snapd#2157 closed: boot,image,overlord,partition: read/write boot variables in single operation <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2157>
  <mup> PR snapd#2167 closed: snapstate, devicestate: do not remove seed <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2167>
  <mup> PR snapd#2174 closed: store: send supported max-format when retrieving assertions <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2174>
  <mup> PR snapd#2160 closed: image: tweak the cloud-init configuration <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2160>
  <mup> PR snapd#2168 closed: snap/squashfs: try to hard link instead of copying. Also, switch to osutil.CopyFile for cp invocation <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2168>
  <mup> PR snapd#2154 closed: cmd/snap: make snap run not talk to snapd for finding the revision <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2154>
  <mup> PR snapd#2170 closed: tests: use the snapd-control-consumer snap from the store <Created by fgimenez> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2170>
  <jdstrand> Chipaca: yeah, not there
  <jdstrand> Chipaca: in my hotel room
  <Chipaca> jdstrand, we're in Potter, if you're feeling lonely
  <jdstrand> I'm feeling quite sleepy after last night tbh :)
  <Chipaca> jdstrand, but only if you have pants on
  <jdstrand> ya, you caught me there.  ;) I think I am going to call it a night in a few
  <jdstrand> zyga: I saw bug #1620442. on touch we set that to somewhere in /run and in snapd we currently allow: /{dev,run}/shm/snap.@{SNAP_NAME}.**
  <mup> Bug #1620442: snap fails because XDG_RUNTIME_DIR is set to /run/user/1000 <snapd-interface> <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1620442>
  <jdstrand> zyga: actually that rule is irrelevant
  <jdstrand> zyga: but I don't think the bind mount is particularly necessary, we could just add an apparmor rule for /run/user/*/snap.$SNAP/**, set XDG_RUNTIME_DIR to point to that and mkdir
  <jdstrand> zyga: can you think of why it should be a bind mount? I mean, it is already honoring the envvar
  <jdstrand> zyga: (and this is something ubuntu-app-launch on Touch would set)
  <mup> PR snapd#2143 closed: overlord: check that the first installed gadget matches the model assertion <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2143>
  <mup> PR snapd#2172 closed: asserts,interfaces/policy: implement on-classic plug/slot constraints <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2172>
  <mup> PR snapd#2175 opened: overlord: checks for kernel installation/refresh based on model assertion and previous kernel <Created by pedronis> <https://github.com/snapcore/snapd/pull/2175>
  <mup> PR snapd#2123 closed: daemon: ensure `snap create-user --known` errors on classic (unless --force-managed is added) <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2123>
  <mup> PR snapd#2173 closed: overlord/snapstate: move trash cleanup to a cleanup handler <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2173>
  <k_> Hi, is there a way to test snap on centos 7?
  <mup> PR snapd#2122 closed: snappy: disable auto-import of assertions on classic <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2122>
  <mup> PR snapd#2176 opened: store,daemon,overlord: download things to a partials dir <Created by chipaca> <https://github.com/snapcore/snapd/pull/2176>
  <ypwong> slangasek, you may want to look at https://bugs.launchpad.net/ubuntu-image/+bug/1634557
  <mup> Bug #1634557: The writable partition is corrupted using the latest ubuntu-image(0.8 ) <Ubuntu Image:New> <https://launchpad.net/bugs/1634557>
  <mup> PR snapd#2177 opened: many: use the new systemd backend for configuring GPIOs <Created by zyga> <https://github.com/snapcore/snapd/pull/2177>
  <mup> PR snapd#2178 opened: snap: spool assertion candidates if snapd is not up yet <Created by mvo5> <Conflict> <https://github.com/snapcore/snapd/pull/2178>
  <slangasek> ypwong: hi - I had seen the bug and was going to raise this with barry today.  This is listed as a regression vs. 0.7?  where does this version of the package (0.8+17.04ubuntu1) come from?  that's not a version that's in the archive
  <mup> PR snapd#2179 opened: remove silly stuff <Created by mvo5> <Conflict> <https://github.com/snapcore/snapd/pull/2179>
  <slangasek> ypwong: ok, reproduced and it seems to not be a regression - we were just being spared this being an issue on the pi3 because of the firstboot autoresizing from the initramfs fixes it before we ever mount the rootfs
  <adam__> hello, I am looking at using ubuntu core snappy as the OS of choice for a raspberry pi solution to communicate with a webserver and some connected hardware via a serial port. I already have a node app that I want to repackage as a snap, but I am struggling to find the information that I need online: 1) Can I publish snaps privately, e.g. with proprietary closed source code and still make use of the auto-update functionality? 2) Can I 
  <rhollan> Is there a snappy package that has networking utils, specifically bridge-utils? I want to bridge two docker containers to the hosts interface and have them get internal IP addresses and gateways and dns servers therefrom
  <rhollan> I don't have any bridge utils on the host side in snappy
  <mup> PR snapd#2180 opened: overlord/snapstate: two bugs for one <Created by chipaca> <https://github.com/snapcore/snapd/pull/2180>
  <Chipaca> ^ fix for #1628914 :-D
  <mup> Bug #1628914: ubuntu-core edge image switched to stable channel unpredictably and became unusable <Snappy:In Progress by chipaca> <https://launchpad.net/bugs/1628914>
   * Chipaca ~> bed
  <mup> PR snapd#2179 closed: remove silly stuff <Created by mvo5> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2179>
  #snappy 2016-10-19
  <mup> Bug #1634730 opened: 500 error when installing snap package <Snappy:New> <https://launchpad.net/bugs/1634730>
  <jdstrand> jjohansen: here is your bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1634753
  <mup> Bug #1634753: srcname from mount rule corrupted under load <aa-kernel> <AppArmor:In Progress by jjohansen> <linux (Ubuntu):Triaged> <linux (Ubuntu Xenial):Triaged> <linux (Ubuntu Yakkety):Triaged> <https://launchpad.net/bugs/1634753>
  <jjohansen> zyga: debs for the fixed kernel are in http://people.canonical.com/~jj/snap/
  <ogra_> pitti, should /etc/netplan/00-snapd-config.yaml be world readable ? (i see my WEP password in there)
  <pitti> ogra_: I guess you just answered that yourself :)
  <ogra_> well, want a bug ?
  <ogra_> :)
  <pitti> ogra_: sure, sounds like a good idea (although it's not "my" bug)
  <pitti> what creates that, console-conf?
  <ogra_> oh, i thought netplan itself ...
  <ogra_> but yeah, might be console-conf
   * ogra_ files bug 1634775 ... for mwhudson 
  <mup> Bug #1634775: /etc/netplan/00-snapd-config.yaml should not be world readable <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1634775>
  <mup> Bug #1634775 opened: /etc/netplan/00-snapd-config.yaml should not be world readable <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1634775>
  <mup> PR snapd#2181 opened: client: add a few explicit error types (around the request cycle) <Created by chipaca> <https://github.com/snapcore/snapd/pull/2181>
  <Son_Goku> zyga: https://github.com/zyga/snapcore-fedora/pull/7
  <mup> PR zyga/snapcore-fedora#7: Add SELinux policy module subpackage <Created by Conan-Kudo> <https://github.com/zyga/snapcore-fedora/pull/7>
  <cjwatson> ogra_: the store should be properly fixed now to handle mode 0 directories in snaps
  <ogra_> yay !
  <iliv__> hey ogra_. did you see by chance my question from yesterday about a Makefile included in a Makefile via relative path?
  <zyga> Son_Goku: thank you :)
  <mup> PR snapd#2180 closed: overlord/snapstate: two bugs for one <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2180>
  <ogra_> iliv__, yes, but i'mm at a sprint this week ... how does your "source:" entry look like ?
  <kyrofa> zyga, ping
  <mup> PR snapd#2182 opened: tests/lib/fakestore/cmd/fakestore: trivial typo fix <Created by chipaca> <https://github.com/snapcore/snapd/pull/2182>
  <chihchun> barry: hi, is there a xenial ppa for ubuntu-image?
  <ogra_> chihchun, you should really use the snap
  <chihchun> ogra_: if there is snap on macos and windows, yes, I will :-)
  <kyrofa> ogra_, I'd love to see a lightning talk on ubuntu-image
  <ogra_> fgimenez, http://paste.ubuntu.com/23347670/
  <ogra_> kyrofa, hmm
  <kyrofa> ogra_, not saying that should be you... but barry isn't here, so... ;)
  <ogra_> kyrofa, yeah ... i get it ... the issue is that the key setup, creating an assertion etc
  <ogra_> .... are rather complex ...
  <kyrofa> ogra_, time-intensive?
  <kyrofa> ogra_, are you going to the hacking session tonight?
  <kyrofa> ogra_, if so, how would you feel about just getting together and give me a tutorial?
  <ogra_> kyrofa, https://docs.google.com/document/d/1cJvRnpoQyLvY6pOLFPgUxMHrFVBCDNwAlrORARBiZlU/edit
  <ogra_> i could probably run a talk along that ...  but i'm not sure if it is fully up to date ( sergio is so fast improving things sometimes ;) )
  <mup> PR snapd#2182 closed: tests/lib/fakestore/cmd/fakestore: trivial typo fix <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2182>
  <dr1337> ogra_ is that a tutorial on building core snap?
  <ogra_> dr1337, no, building an image
  <fgimenez> ogra_: thx!
  <dr1337> ogra_ Nice - I'd love access to that please
  <ogra_> you dont have access ?
   * ogra_ though it is a public doc ... i dont own it
  <dr1337> ogra_ not to that google docs
  <dr1337> ogra_ Have you thought of building an image for QEMU arm?
  <mup> PR snapd#2183 opened: tests/lib/fakestore/cmd/fakestore: make it log, and fix a typo <Created by chipaca> <https://github.com/snapcore/snapd/pull/2183>
  <kyrofa> ogra_, ah, handy document, thank you!
  <ogra_> dr1337, i just noticed it is now in the snapcraft.io tree https://github.com/CanonicalLtd/snappy-docs/blob/master/core/images.md so you can read it from there
  <dr1337> ogra_ thanks!
  <mup> Bug #1634822 opened: Console-conf needs a cancel button <Snappy:New> <https://launchpad.net/bugs/1634822>
  <mup> PR snapd#2184 opened: tests/lib/fakestore: fix logic to distinguish assertion not found errors <Created by pedronis> <https://github.com/snapcore/snapd/pull/2184>
  <Chipaca> davmor2, wrt bug 1634822, I'm sorry your system is sore
  <mup> Bug #1634822: Console-conf needs a cancel button <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1634822>
  <mup> PR snapd#2183 closed: tests/lib/fakestore/cmd/fakestore: make it log, and fix a typo <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2183>
  <mup> PR snapd#2181 closed: client: add a few explicit error types (around the request cycle) <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2181>
  <mup> PR snapd#2184 closed: tests/lib/fakestore: fix logic to distinguish assertion not found errors <Created by pedronis> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2184>
  <mup> PR snapd#2175 closed: overlord: checks for kernel installation/refresh based on model assertion and previous kernel <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2175>
  <ogra_> ToyKeeper, http://www.transcend-info.com/Products/No-401 and something like https://www.amazon.com/SD-to-Micro-Adapter/dp/B0143QFXYO
  <ogra_> ToyKeeper, http://www.transcend-info.com/Products/No-401 and something like https://www.amazon.com/SD-to-Micro-Adapter/dp/B0143QFXYO
  <mup> PR snapd#2185 opened: interfaces/builtin: home base declaration rule using on-classic for its policy <Created by pedronis> <https://github.com/snapcore/snapd/pull/2185>
  <iliv__> ogra_, the source: entry looks like this. source: parts/app/src/modules/
  <mup> Bug #1634880 opened: Interface for accessing lxd <snapd-interface> <Snappy:New for kalikiana> <https://launchpad.net/bugs/1634880>
  <mup> Bug #1634885 opened: Removing /writable/ kills the system <Snappy:New> <https://launchpad.net/bugs/1634885>
  <mup> Bug #1634890 opened: File system not resized in Raspberry Pi 3 <Snappy:New> <https://launchpad.net/bugs/1634890>
  <barry> chihchun_afk, kyrofa good morning (here :).  we're using this ppa but i wouldn't necessarily count on it.  it's mostly for testing: https://launchpad.net/~canonical-foundations/+archive/ubuntu/ubuntu-image/+packages
  <kyrofa> barry, feels like morning here, too
  <barry> chihchun_afk, kyrofa but for xenial, i would also recommend just using the snap
  <barry> kyrofa: it's always morning somewhere!
  <mup> PR snapd#2186 opened: asserts: bump snap-declaration to allow signing with new-style plugs and slots <Created by emgee> <https://github.com/snapcore/snapd/pull/2186>
  <perrito666> hello people, I have a few doubts here, I am trying to build a snap for vim8 with a particular set of compile flags, how do I specify which packages this requires to run afterwards?
  <ogra_> perrito666, "stage-packages" if you mean the binaries you want installed alongside
  <perrito666> ogra_: yep, I had a feeling it was that but the wording in the docs is either not clear or beyond my english-fu
  <perrito666> ogra_: tx a lot
  <mup> Bug #1634909 opened: Disabling pc||pc-kernel||core should give a warning message <Snappy:New> <https://launchpad.net/bugs/1634909>
  <perrito666> and since I am here, lets say I specify a git repo as the "source" for the make plugin, is there a way to indicate the tag/checkout?
  <ogra_> ppisati, hmm, the kernel in -proposed looks good so far, but i did not get a wlan0 device in /proc/net/dev on first boot (second boot is fine)
  <ogra_> trying to repro that now
  <ppisati> ogra_: raspi?
  <ogra_> yep
  <ogra_> the uart error is gone at least
  <ogra_> and there was no wlan oops either
  <ogra_> probably it was just a glitch, lets see, trying the second time now
  <ppisati> ogra_: i remember there was a wlan in... console-conf
  <ogra_> yeah, i used wired though ... and there was no wlan0 in /proc/net/dev after i logged in via ssh
  <ppisati> ogra_: though i couldn't configure that (it kept timing out when trying to configure)
  <ppisati> ogra_: uhm k
  <ogra_> i have test images at http://people.canonical.com/~ogra/snappy/all-snaps/
  <ppisati> ogra_: did you run your script or did you rebuild the kernel.snap manually?
  <ogra_> ppisati, https://code.launchpad.net/~ogra/+snap/pi2-kernel/+build/7441 i got a hacked up version of the script running in a +junk tree now
  <ogra_> that forcefully pulls from -proposed
  <ppisati> ogra_: k
  <ogra_> GRR
  <ogra_> Network configuration timed out; please verify your settings.
  <ogra_> damned
  <ogra_> i wonder whyt consoole-conf does ...
  <ppisati> ogra_: yes, it's always like that
  <ogra_> before we had it and when i just used /etc/network/interfaces the wlan always worked
  <ppisati> ogra_: the funny thing is that on secondo boot, all the wifi details are there and it connects fine
  <ogra_> well, i blame either netplan or console-conf ...
  <ogra_> yeah
  <ogra_> as if there was some race
   * ogra_ tries a reset
  <mup> PR snapd#2187 opened: boot:no next boot to the same thing <Created by mvo5> <https://github.com/snapcore/snapd/pull/2187>
  <ppisati> ogra_: so you got the wlan interface this time
  <ogra_> it shows up but doesnt connect
  <ogra_> it did show up in the last try too in the UI but could not be found in /proc/net/dev after finishing the config
  <ppisati> ogra_: yes, that has always been my experience since console-conf entered the image
  <ogra_> right
  <ppisati> btw, how do you ssh if there's no user configure in that image?
  <ppisati> *ssh in
  <ogra_> lets see if it behaves after a reset
  <ogra_> you cant ...
  <ogra_> (which makes debugging console-conf a pain)
  <ogra_> LOL
  <ppisati> ogra_: right, but you said that you sshed in and checked /proc/dev/net/...
  <ogra_> heh
  <ogra_> so after reset the wlan0 interface comes up telling me it is connected in console-conf
  <ppisati> ogra_: yes, that's me experience too
  <ogra_> yes, i configured wired
  <ppisati> oh k
  <ogra_> well, seems to still time out
  <ogra_> sigh
  <ogra_> so i guess no wlan on pi3 for the RC image then
  <ppisati> ogra_: can you ssh in and check if the wlan is there?
  <ogra_> well, i can probably set up wired, lets see ... though usually if console-conf had one error you can forget about the whole thing
  <ppisati> ogra_: right, it usually loses its mind after a failed network config
  <ogra_> yep
  <ogra_> well, we still have two weeks :P
  <ogra_> ppisati, in general the kernel seems to be a lot better though ... something at least ... all oopses gone
  <ogra_> oh my
  <ogra_> now cosole-conf just crashed ... drops me back to "please press enter" and if i do that it prints python tracebacks
  <ppisati> ogra_: so, for the BBB panic bug, i tried to install console-conf on classic, reproduce the 'first boot' snappy boot environment and work from there
  <ppisati> ogra_: might be a strategy to debug this
  <ogra_> i did set BBB to verification-done for the sru kernel yesterday already
  <ogra_> ppisati, was the kernel from bug 1627643 the one in proposed ?
  <mup> Bug #1627643: oops on pi3 (seemingly wlan related) <Snappy:New> <linux-raspi2 (Ubuntu):New for p-pisati> <https://launchpad.net/bugs/1627643>
  <ppisati> ogra_: or we punch a hole in the dev image so we can login via the serial console and check what's really going on
  <ppisati> ogra_: yes
  <ogra_> well, i wanted to play with systemd console but didnt have time for that yet
  <ogra_> \o/
  <ogra_> something at least ... that kernel looks fine
  <ppisati> ogra_: good to know
  <ogra_> do you have an SRU bug that i can tag verification-done ?
  <ogra_> (though i need to test pi2 still)
  <ppisati> ogra_: let me find it
  <ogra_> ogra@localhost:~$ cat /proc/net/dev
  <ogra_> Inter-|   Receive                                                |  Transmit
  <ogra_>  face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
  <ogra_>   sit0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
  <ogra_>     lo:  166400    2080    0    0    0     0          0         0   166400    2080    0    0    0     0       0          0
  <ogra_>   eth0:   83971    1140    0    6    0     0          0         0    13042      83    0    0    0     0       0          0
  <ogra_> ogra@localhost:~$
  <ogra_> hmm
  <ppisati> ogra_: does dmesg say anything wrt wlan?
  <ppisati> ogra_: does it require a fw the wlan on rpi3? i think it does
  <ogra_> http://paste.ubuntu.com/23348754/
  <ogra_> yeah, we have that in the image PPA ... the kernel snap contains it
  <ogra_> (i pulled it from your embedded PPA ages ago)
  <ppisati> ogra_: i need to grab my rpi3, it's in my room
  <ogra_> well, link to the image is above
   * ogra_ needs to test pi2 now ... and if yu give me the SRU bug# i'll set it to verification-done
  <ogra_> (if it works :P)
  <ppisati> ogra_: lsmod?
  <ogra_> sorry, already on the pi2 now
  <ogra_> ah, but i have an lsmod output in my shell history
  <ogra_> one sec
  <ogra_> http://paste.ubuntu.com/23348784/
  <ogra_> ogra@localhost:~$ uname -a
  <ogra_> Linux localhost.localdomain 4.4.0-1028-raspi2 #34-Ubuntu SMP Mon Oct 17 09:44:39 UTC 2016 armv7l armv7l armv7l GNU/Linux
  <ogra_> ogra@localhost:~$
  <ogra_> :)
  <ogra_> pi2 looks GOOD !
  <ppisati> ogra_: ok, i don't have any way to login, nice
  <ogra_> well, wired works
  <ogra_> (we have a switch in the QA room that i use here)
  <ppisati> ogra_: k, i'm in the plenary room now
  <ogra_> yeah, i'll come too
  <mup> PR snapd#2188 opened: tests: wait for file written instead of log entries in the writable-areas test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2188>
  <Chipaca> davmor2, mksquashfs squashfs-root foo_$i.snap -noappend -comp xz -all-root -no-xattrs
  <mup> PR snapd#2189 opened: asserts,daemon: implement system-user-authority header/concept <Created by pedronis> <https://github.com/snapcore/snapd/pull/2189>
  <ogra_> Chipaca, unless it is a core snap ;) (then without -all-root)
  <Chipaca> ogra_, yeap
  <mup> PR snapd#2186 closed: asserts: bump snap-declaration to allow signing with new-style plugs and slots <Created by emgee> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2186>
  <mup> PR snapd#2169 closed: interfaces/builtin: finish decl based checks <Blocked> <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2169>
  <mup> PR snapd#2185 closed: interfaces/builtin: home base declaration rule using on-classic for its policy <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2185>
  <mup> PR snapd#2190 opened: overlord/ifacestate: setup security for slots before plugs <Created by zyga> <https://github.com/snapcore/snapd/pull/2190>
  <mup> PR snapd#2187 closed: boot:no next boot to the same thing <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2187>
  <mup> PR snapd#2191 opened: boot: do not set boot to try mode if the revision is unchanged <Created by mvo5> <https://github.com/snapcore/snapd/pull/2191>
  <mup> PR snapd#2149 closed: Finalize declaration based checks <Blocked> <Critical> <Created by jdstrand> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/2149>
  <lotuspsychje> anyone knows howto list latest snap packages from terminal or ubuntu software on 16.04?
  <lotuspsychje> would be nice to know whats newly added
  <mup> PR snapd#2189 closed: asserts,daemon: implement system-user-authority header/concept <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2189>
  <mup> PR snapd#2176 closed: store,daemon,overlord: download things to a partials dir <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2176>
  <mup> PR snapd#2178 closed: snap: spool assertion candidates if snapd is not up yet <Critical> <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2178>
  <mup> PR snapd#2188 closed: tests: wait for file written instead of log entries in the writable-areas test <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2188>
  <mup> Bug #1635011 opened: /v2/changes/ is not documented in rest.md <Snappy:New> <https://launchpad.net/bugs/1635011>
  <mup> Bug #1635016 opened: Missing dependency on ca-certificates <Snappy:New> <https://launchpad.net/bugs/1635016>
  <mup> PR snapd#2190 closed: overlord/ifacestate: setup security for slots before plugs <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2190>
  <perrito666> interesting, I made a snapcraft.yaml  (http://pastebin.ubuntu.com/23350368/) and it seems to build correctly but when I isntall it 1) my binaries are prefixed with vim-hduran. and 2) they complain of the lack of a .so.0 file which is included in one of the packages I explicitly added to stage-packages any ideas?
  <slangasek> morphis: hi, I see you've marked bug #1634540 as 'critical'; is there a deadline for this work?
  <mup> Bug #1634540: Configuring a static IP address generates a netplan file without a gateway <nplan (Ubuntu):New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1634540>
  <mup> PR snapd#2177 closed: many: use the new systemd backend for configuring GPIOs <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2177>
  <jjohansen> zyga: ppa for mvo or ogra_ to snap a kernel from https://launchpad.net/~apparmor-dev/+archive/ubuntu/apparmor-devel/+packages
  <rharper> ogra_: are you aware of any changes to live-build that now purge cloud-init ?  I've been rebuilding the core snap to include newer cloud-init to test out the system-user assertions; this worked last week, today however, in the build log, I see a purge  of cloud-init: The following packages will be REMOVED:
  <rharper>   cloud-init* locales* ubuntu-core*
  <rharper> looking for help in figuring out how to do builds of core snap that include cloud-init so we can get images that work in clouds
  <jgrimm> slangasek, ^^
  <slangasek> rharper, jgrimm: hrm
  <slangasek> I had not heard anything about this; certainly seems like a change we need to revert
  <rharper> slangasek: ok, last good build for me was on 10-13;  10-14 till now, the .manifest doesn't include cloud-init; https://code.launchpad.net/~raharper/+snap/core
  <slangasek> rharper: maybe worth a look at the history of the livecd-rootfs package in the snappy-dev ppa?
  <rharper> yeah, lemme look there
  <rharper> 2 http://ppa.launchpad.net/snappy-dev/image/ubuntu xenial/main amd64 livecd-rootfs amd64 2.420+ppa46 [47.0 kB]
  <rharper> that's the latest, published 10-10
  <rharper> used in both good builds and the current builds that purge
  <rharper> so something else is triggering it
  <eltigre> Hey, what's the state of "snappy ubuntu core" on raspberry pi devices? The documentation is outdated, the last available image is a year old, and does it support Raspberry pi 2?
  <eltigre> raspberry pi 3 , I mean
  <eltigre> I like the concept of snappy, but I'm a bit unsure about future device support etc
  <mwhudson> eltigre: pretty sure rpi 2 and 3 are target platforms
  <eltigre> I know rpi 2 is
  <mwhudson> eltigre: there has been some renaming of things recently though, where do you see things being a year old?
  <eltigre> first problem, when I go to https://developer.ubuntu.com/en/snappy/start/ and click the "Get started on the Raspberry Pi 2 âº"  the guide tells me to download a normal server image for arm
  <eltigre> I just found newer ubuntu-core images...
  <eltigre> ok, so the 16.04 snappy-core image boots, has an open ssh service, but it doesn't take ubuntu:ubuntu or root:ubuntu or ubuntu:snappy
  <mwhudson> eltigre: you need to configure a user on a vt or serial
  <eltigre> uhm...
  <eltigre> so vt means I need to attach hdmi+keyboard, not even sure how to do "serial"
  <eltigre> and I must really have the wrong documentation if this is the only way
  <mwhudson> eltigre: well having every device running ubuntu core having ubuntu:ubuntu be a sudoer is not ideal either!
  <eltigre> The server image has ubuntu:ubuntu and forces you to change the password at first login. For Raspberry Pi I think this security is enough, because you'd have an attacker in your home network scanning your network every minute for newly flashed rpis and then you'd still know because the password changed
  <eltigre> But that's just me. I can understand that. Would be nice to have documentation on this though.
  <mwhudson> yeah, documentation is definitely lacking
  <mwhudson> uh, why am i still waiting for a cloud-init timeout in a pc image?
  <mwhudson> i guess all the people who might know that are asleep
  <mwhudson> rharper: around?
  <mwhudson> this is infuriating
  <mwhudson> i guess i could try to understand what's going on
  #snappy 2016-10-20
  <dr1337> Hi guys is it possible to build an ubuntu image using local snaps defined in the model assertion instead of having to go through the snap store?
  <mup> Bug #1635101 opened: /snap/bin is not added to path for "sudo su" <Snappy:New> <https://launchpad.net/bugs/1635101>
  <dr1337_> mwhudson: most of the devs are in Europe so they would be asleep
  <dr1337_> mwhudson: and I agree the documentation is very patchy with lots of different components being constantly rewritten with out of date instructions. I'm almost at the point of giving up on Snappy and going with something easier like ResinOS.
  <ogra_> rharper, we do not purge, but snap prepare-image has a function that disables it if there is no cloud-init config in the gadget snap
  <ogra_> jdstrand, hmm, didnt you recently say you addded linux-generic-bbb to the kernel exceptions so it auto-lands ? https://myapps.developer.ubuntu.com/dev/click-apps/5912/review/rev/5/ is in manual review now
  <jdstrand> ogra_: I did but the store doesn't have it yet
  <ogra_> ah
  <jdstrand> ogra_: approved but not published
  <ogra_> yep, got the mail, thanks :)
  <jdstrand> np
  <ogra_> and published too ... :)
  <mup> PR snapd#2192 opened: snap: fix FTBFS because the buildds do not allow writing to syslog <Created by mvo5> <https://github.com/snapcore/snapd/pull/2192>
  <mup> PR snapd#2192 closed: snap: fix FTBFS because the buildds do not allow writing to syslog <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2192>
  <mwhudson> ogra_: ah maybe i need to update my snapd then
  <mwhudson> pitti: yo
  <pitti> hey mwhudson, how are you?
  <mwhudson> pitti: i'm ok
  <mwhudson> pitti: netplan and nameservers, how much work does that sound?
  <pitti> mwhudson: ok, jumping back :)
  <pitti> mwhudson: not that much, I just moved it to the top of my list as it seems to become a blocker RSN?
  <mwhudson> pitti: seems so if https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1634540 is critical
  <mup> Bug #1634540: Configuring a static IP address generates a netplan file without a gateway <nplan (Ubuntu):Invalid by pitti> <subiquity (Ubuntu):Fix Committed> <https://launchpad.net/bugs/1634540>
  <mwhudson> because if you configure static addresses and no nameserver you're going to have a hard time talking to the store..
  <mwhudson> i guess we *could* put login.ubuntu.com's ip address in /etc/hosts :-)
  <pitti> mwhudson: well, if you don't configure a nameserver, resolved defaults to 8.8.8.8, so it shoudln't completely fail
  <mwhudson> pitti: oh huh
  <pitti> mwhudson: but it's better to be able to configure it of course
  <mwhudson> pitti: it definitely failed for me in qemu
  <mwhudson> pitti: is that user mode networking being odd?
  <pitti> mwhudson: it would only work if you ... oh crap, this is xenial, so no resolved
  <pitti> nevermind :)
  <mwhudson> ha
   * pitti just doesn't live in stable releases
  <mwhudson> well we already backported netplan itself for this...
  <mwhudson> backporting resolvd does feel a bit large-hammer
  <pitti> nah
  <pitti> we really don't want to do that
  <pitti> mwhudson: both networkd and NM support manual nameservers, so it's just a matter of adding the glue to pass it on, and writing tests
  <pitti> mwhudson: I'll start on that now
  <mwhudson> yeah, networkd looked pretty straightforward at least
  <pitti> mwhudson: getting that into xenial-updates will take a bit longer, but you can park it in your PPA in the meantime
  <mwhudson> (i know nothing about NM really)
  <mwhudson> yeah ppas r us
  <pitti> mwhudson: is yakkety a thing for snappy at all? or just x (and zesty/devel of course)?
   * pitti hopes not -- please no non-LTS releases any more, EVAR
  <mwhudson> just xenial + ppas i think really
  <mwhudson> and of course xenial implies devel release first, not that that rule is being stuck too 100%
  <pitti> I just don't want to repeat the vivid pain :)
  <mwhudson> xnox is in the hague, he can attack anyone who suggests anything like that
  <xnox> pitti, sure.... would you like to maintain yakkety, or whould you like to SRU everything from yakkety to xenial?
  <ogra_> mwhudson, i was just wondering, is VPN support in console-conf on the roadmap ?
  <xnox> people are talking about SRUing all of systemd user session work, and all of perfonal/unity8 as SRUs into xenial for ever.
  <pitti> xnox: I want to forget that yakkety exists :) I want to backport necessary stuff from devel (i. e. z now) to x
  <mwhudson> i'd better get on with the ui for nameservers...
  <pitti> xnox: uh, ambitious :)
  <mwhudson> ogra_: noone has mentioned it to me
  <ogra_> xnox, we should really just SRU zesty altogether :P
  <pitti> it works great!
  <pitti> ship it
  <ogra_> mwhudson, yeah, just came to my mind that IoT setups might want to use it
  <mwhudson> ogra_: is openvpn-client even in core
  <mwhudson> ?
  <pitti> urgh, happy typing of X.509 certificates into your serial console :)
  <ogra_> mwhudson, nops, apparently not
  <mwhudson> sounds like using telnet to debug http/2
  <ahayzen> Hey, has anyone experienced a situation where building a snap in a yakkety container is different to a snap built from in a VM ?  As the snap i've built from the container doesn't work on the host, whereas the one from the VM does and they both have the same size but a different md5sum
  <mwhudson> ogra_: i guess the gadget snap can provide it somehow?
  <ogra_> yeah, well, i will try to discuss it with the team here
  <mwhudson> ogra_: anyway, sounds like a medium term thing ...
  <ogra_> right, not super urgent ... definitely not for the release ... for that getting wifi to work on the pi3 would be a bit more important ;)
  <mwhudson> ogra_: do you have any idea what's actually going wrong there?
  <ogra_> mwhudson, not the slightest .... wlan doesnt work at all ... when you try to configure it it times out ... when you *then* try to do anything else network related ... i.e. try to set up wired, that doesnt work either anymore ....
  <mwhudson> ogra_: but if you run through console-conf on wired, then wlan works?
  <ogra_> btw, i just talked to mvo, we'll seed openvpn stuff so you have something you can later attach to
  <ogra_> iirc (have to test that again) if you configure both, iit doesnt work
  <ogra_> it only works if i use wired only
  <ogra_> it also works if i manually bring up wlan after booting
  <ogra_> fgimenez might be able to give more details, he tests that stuff all day atm
  <mwhudson> pitti: http://paste.ubuntu.com/23352576/ <- does that match planned syntax
  <pitti> mwhudson: looks good; I'm writing test cases like this:
  <pitti>     enblue:
  <pitti>       addresses: ["192.168.1.3/24"]
  <pitti>       nameservers:
  <pitti>         search: [lab, kitchen]
  <pitti>         addresses: [8.8.8.8]''')
  <pitti> mwhudson: which is the same thing, just different YAML syntax
  <mwhudson> ogra_: can you do something like create /var/log/journal so the journal persists and then see what ends up in there
  <mwhudson> pitti: wait, it's per interface?
  <pitti> mwhudson: NM seems to have trouble with multiple search domains, argh
  <pitti> mwhudson: yes, it is; nameservers usually are
  <mwhudson> pitti: ok fine, but that's not what https://git.launchpad.net/netplan/tree/doc/netplan.md has :)
  <pitti> mwhudson: right, I'll fix that
  <pitti> that was obviously an error
  <pitti> thanks for pointing out
   * mwhudson rebases :)
  <pitti> mwhudson: http://paste.ubuntu.com/23352599/
  <mwhudson> pitti: looks plausible at least
  <pitti> mwhudson: as I said, NM does not actaully seem to properly configure multiple search domains (I just see "search lab" in /etc/resolv.conf), but I hope that won't block you
  <mwhudson> pitti: i don't think that's important here no
  <mwhudson> maybe morphis could say more
  <mwhudson> pitti: you're probably not the ideal person to ask this but do you think it makes sense to allow configuring nameservers when using DHCP for an interface?
  <pitti> mwhudson: it's technically possible to configure this; my gut feeling is that it doesn't make much sense to expose this corner case in the UI, though
  <mwhudson> pitti: ok
  <ogra_> pitti, mwhudson, seeding the openvpn package is enough for you guys to have everything you need to later implement something in netplan and console-conf ?
  <mwhudson> ogra_: i don't think that's something i can answer off the top of my head
  <pitti> ogra_: probably; but doesn't make much sense to seed it until we actually can use it
  <ogra_> well, we release in two weeks, i just want to have all the requirements there so you can get to it later
  <pitti> we can seed it if/once we support it; until then, it's just dead weight
  <pitti> also, I don't think we want to abstract this in any form
  <pitti> if you want to configure openvpn, then add an openvpn config file
  <pitti> this isn't related to different backends like networkd vs. ifupdown vs. NetworkManager
  <ogra_> ok
  <pitti> I mean, maybe we want to put it into the yaml some day, but that shouldn't be a blocker
  <mup> Bug #1631791 changed: ubuntu-core/core unconditionally switches to the stable channel on all-snap images <Snappy:Confirmed> <https://launchpad.net/bugs/1631791>
  <mwhudson> pitti: http://paste.ubuntu.com/23352666/ <- better?
  <ogra_> ppisati, hmm, the uart oops on pi3 is supposed to be fixed with todays -security/-update kernels, right ?
  <ogra_> ppisati, the QA team just showed me an oops that looks suspiciously like it
  <ogra_> ppisati, https://rocket.ubuntu.com/file-upload/E5QyRTm7Xq6nojq3E/photo_2016-10-20_10-39-04.jpg
  <mup> PR snapd#2162 closed: interfaces: add shutdown interface <Critical> <Created by morphis> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2162>
  <zyga> Son_Goku: hey
  <zyga> Son_Goku: I pushed some small change
  <zyga> Son_Goku: let's try to run that for real
  <Son_Goku> I just pulled and it built
  <Son_Goku> don't know if it works, though
  <Son_Goku> ah, I'm missing that patch
   * Son_Goku pulls again
  <zyga> Son_Goku: I'm just rebuilding both to install now
  <ppisati> ogra_: cannot open that image
  <ppisati> ogra_: anyhow, >= 4.4.0-1028.34 should be fine
  <ogra_> 4.4.0-1029 is what we (should) have in the store
  <ogra_> hmm, https://launchpadlibrarian.net/290063684/buildlog_snap_ubuntu_xenial_armhf_pi2-kernel_BUILDING.txt.gz
  <ogra_> -1028 actually :)
  <mwhudson> cyphermox: https://github.com/CanonicalLtd/subiquity/pull/175
  <mup> PR CanonicalLtd/subiquity#175: add UI for entering nameservers <Created by mwhudson> <https://github.com/CanonicalLtd/subiquity/pull/175>
  <ogra_> ah, wrong log
  <ogra_> https://launchpadlibrarian.net/290161189/buildlog_snap_ubuntu_xenial_armhf_pi2-kernel_BUILDING.txt.gz
  <ogra_> that has actually -1029
  <ogra_> ppisati, hmm, but only:
  <ogra_> Get:5 http://ftpmaster.internal/ubuntu xenial-security/universe armhf linux-image-raspi2 armhf 4.4.0.1029.29 [2324 B]
  <ogra_> ppisati, where is .34 ?
  <ogra_> (also it would amke sense if you could come over to the snappy room, we are discussion uboot watchdog)
  <ogra_> *discussing
  <ppisati> ogra_: i'm here actually
  <zyga> Son_Goku: hmm, I dont see the snapd-selinux package
  <zyga> Son_Goku: ah, I'm a dork, noatch
  <zyga> noarch*
  <mup> PR snapd#2193 opened: add raw-usb iterface <Created by teknoraver> <https://github.com/snapcore/snapd/pull/2193>
  <zyga> Son_Goku: I need to redo the systemd units a little
  <zyga> Son_Goku: fingers crossed
  <Son_Goku> okay
  <mup> PR snapd#2194 opened: store: retry readyToBuy request <Created by stolowski> <https://github.com/snapcore/snapd/pull/2194>
  <zyga> Son_Goku: trying more
  <zyga> Son_Goku: so I see stuff that seems to imply the selinux policy is not loaded
  <zyga> Son_Goku: how do I reload it?
  <zyga> Son_Goku: I need a few more binaries, iterating
  <mup> PR snapd#2195 opened:  interfaces/builtin: add dcdbas-control interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/2195>
  <alevipri> hello, I've installed libreoffice 5.2 via snap in xenial, then removed libreoffice 5.1 with synaptic
  <alevipri> however now the dash does not show LO icons
  <alevipri> how to fix this?
  <alevipri> I was thinking that the LO snap provides icons too
  <Simooon> Can anyone tell me how I'm supposed to verify that a snap package, made availible by some random developer I don't know, is the real deal, and not some sneaky way of installing a modified version of the program that sends all my data to haxx.ru?
  <Simooon> alevipri, well it is distributed by chanonical, so you would thing they have included everything. Have you tried restarting, to see if it is something that just needs to be reinitialized?
  <alevipri> Simooon already restarted
  <Simooon> alevipri, okay, I just started using snap yesterday, so I'm probably not the right person to help :-P
  <alevipri> before to remove LO 5.1 with synaptic, I notices icone were available for both deb and snap installed applications
  <alevipri> noticed* icons*
  <alevipri> so I can imagine I removed something with synaptic
  <Simooon> alevipri, I don't think synaptic is supposed to be able to touch the snaps
  <alevipri> however I was expected to install a snap containing all dependencies, icons too
  <Simooon> that seems to be the general idea
  <alevipri> Simoon yeah I think it too, however now LO launchers don't show icons
  <Simooon> if synaptics touched the snap by some weird bug or other interaction I don't understand, you can probably restore it to it's original form with the "snap refresh" command, however I think it is unlikely that synaptics have been able to touch it.
  <Simooon> worth a try though
  <mup> Bug #1635251 opened: /boot/efi/EFI/boot/ is writable as sudo <Snappy:New> <https://launchpad.net/bugs/1635251>
  <alevipri> Simooon tried but nothing changed
  <Simooon> alevipri, Well that is what I expected :-/
  <Simooon> alevipri,  Have you tried other applications where it worked?
  <mup> PR snapd#2195 closed:  interfaces/builtin: add dcdbas-control interface <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2195>
  <morphis_> pitti: ping
  <pitti> morphis_: pong
  <morphis_> pitti: while you're working on the DNS fix for netplan can you include https://launchpadlibrarian.net/290162595/nplan_0.12~16.04+ppa1_0.12~16.04+ppa2.diff.gz in your next upload as well (if you agree with that change)?
  <pitti> morphis_: no problem -- it's just a small change within that hack, so that doesn't make it any worse
  <morphis_> pitti: I can submit a proper MP as well if you want
  <morphis_> pitti: :-)
  <pitti> morphis_: we don't have the xenial version in VCS
  <morphis_> ah ok
  <morphis_> then nevermind :-)
  <pitti> morphis_: how far are we with dropping that hack?
  <morphis_> pitti: not much further, we're trying to hit deadlines for the final product right now
  <morphis_> but I wanted to check with mvo while being on the sprint in the hague what we can do about this
  <mup> Bug #1635258 opened: File system should 5% Ubuntu-image <Snappy:New> <https://launchpad.net/bugs/1635258>
  <alevipri> Simooon for example krita (snap) works with the correct icon
  <Simooon> alevipri, just installed the telegram app myself, and the icon shows up in the launcher, however the systray (or whatever that thing in the upper right conor is called) does not show the correct icon, but an error message icon instead. Perhaps there are just some general issues with icons still?
  <Simooon> alevipri, anyway I will reboot my system to see if that changes this minor issue
  <alevipri> Simooon the telegram-sergiuseng missing icon on the systray is a old bug
  <alevipri> s*
  <Simooon> alevipri, okay, will not reboot then :-P
  <alevipri> Simooon the point is, why before to remove LO 5.1 (deb) the icons os LO 5.2 (snap) were available?
  <alevipri> I suspect something is missing from the LO snap package
  <mup> PR snapd#2191 closed: boot: do not set boot to try mode if the revision is unchanged <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2191>
  <Simooon> alevipri, and it launched 5.2 before you removed 5.1?
  <Paz_> Hi. This is my first outing with Snappy and I'm trying to include a couple of libraries (.so files) to my snap package using the dump plugin, but having no joy.
  <qengho> Paz_: Where did the library files come from?
  <Paz_> Currently, they are pre-built. The final aim is to build them via snappy
  <qengho> Paz_: This is my long way of asking, why use the "dump" plugin? Are you sure that's what you need?
  <qengho> Hmm.
  <Paz_> No I'm not sure. Was using 'copy' plugin, but this is deprecated
  <qengho> Paz_: Okay, let's start at the beginning. What is the error message?
  <Paz_> During the Priming of the library I get the following message...
  <Paz_> No such file or directory: '/home/celldev/Development/snap-telegram-app/stage/moc_sessionmanager.cpp
  <john-mcaleely> awe_, https://docs.google.com/document/d/1a8eydCb_55M6FQdrdZDXZ1Figkh6rLrERMbWO2v2KzI/edit
  <alevipri> Simooon there were 2 .desktop launchers per app, i.e. 1 for calc-deb and 1 for calc-snap
  <qengho> Paz_: Pastebin the entire output, starting after "snap clean".
  <mup> Bug #1635264 opened: ufw rules created even though there is no ufw on the system <Snappy:New> <https://launchpad.net/bugs/1635264>
  <Paz_> ok, give me a sec...
  <alevipri> Simooon both worked launching both LO versions and both showed LO icons correctly
  <alevipri> Simooon re-installed libreoffice-gtk with its dependencies
  <alevipri> now icons are shown again
  <alevipri> Simooon my conclusion is that something is missing from the LO snap package
  <Chipaca> pitti, are you around?
  <pitti> Chipaca: yes
  <Paz_> qengho: http://pastebin.com/Cpj3xpeq
  <Chipaca> pitti, hiya. Do you know anything about https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/ (and in particular about requirements around the shutdown executable)
  <Chipaca> pitti, i mean, do we disable it or anything?
  <Paz_> qengho: This is my YAML file http://pastebin.com/T3ukAnyD
  <pitti> Chipaca: we don't use systemd in the initrd; you can by using dracut instead of initramfs-tools, but I don't have much experience with it
  <Chipaca> pitti, this isn't to use systemd in the initrd; it's a way for systemd to hand control back to initrd on shutdown
  <qengho> Paz_: Does this print two entries?  $ ls -ld snapcraft.yaml telegram/app/deps/libqtelegram-ae/build_desktop
  <ogra_> Chipaca, hmm, i think we throw away the initrd after boot
  <ogra_> so if you expect to do anything with the initrd itself that will likely not work
  <Chipaca> ogra_, one problem at a time :-D
  <ogra_> heh, k
  <pitti> Chipaca: I don't think it actually uses that in Ubuntu; AFAIK pid 1 just exec()s systemd-shutdown (to make sure that all open  fds to the root fd are closed), which then unmounts everything (or rather, remounts r/o)
  <ogra_> and then falls over :P
  <ogra_> pitti, the prob we have here is that we have a mount inception ... the readonly bit of the fs sits inside the rw bit ... both are mounted on shutdown so the writable bit can not be unmounted because the ro bit inside keeps the fd open
  <Paz_> qengho: Yes it does, one for the .yaml file and the other is the directory
  <qengho> Cool.
  <qengho> Paz_: Comment-out your line31, "stage: [...]"
  <Paz_> qengho: OK, then run clean and snapcraft again?
  <qengho> Yes please.
  <qengho> Paz_: I don't understand that "stage: " list any more. I can't explain what it's supposed to be doing there.
  <Paz_> qengho: I was playing around, so understand if some stuff is nonsensical. Basically, I have 2 pre-built .so files which are needed to build the 'telegram' part. How do I make this visible to that part?
  <Paz_> qengho: I was manually moving these .so files into /lib before to make them visible, but now need this to be done via the YAML file
  <mup> PR snapd#2195 opened:  interfaces/builtin: add dcdbas-control interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/2195>
  <rharper> ogra_: right; I'm not yet building an image; I'm building a new core snap pointed to my PPA so I can get an updated cloud-init into the core snap;  last week the core snap build ended up with my cloud-init in the .manifest;  the last two days the build no longer has it; trying to understand why.
  <ogra_> can you show me your ppa ?
  <rharper> yeah
  <rharper> https://code.launchpad.net/~raharper/+snap/core
  <rharper> those are the snaps; the PPA I point to is here: https://launchpad.net/~raharper/+archive/ubuntu/snapbuilds/+packages
  <Chipaca> pitti, ogra_, so the good news is, it works
  <ogra_> and the bad news ?
  <Chipaca> pitti, ogra_, /run needs to lose the noexec flag, and now i need to figure out if i can write shutdown as a shell script or not :-D
  <Chipaca> ogra_, I'll write it in python just to keep you happy
   * pitti watches ogra explode in anger
  <ogra_> Chipaca, it doesnt need to "lose the noexec" completely though, have a shutdown unit that remounts it "exec" right before shutdown
  <Chipaca> true dat
  <Chipaca> ogra_, BTW we have /lib/modules and /lib/firmware mounted twice
  <ogra_> which shutdown did you use ? busybox ?
  <ogra_> yeah, thats a bug i guess
  <Chipaca> ogra_, mksh-static
  <ogra_> ah
  <hurricanehrndz> anyone here use the libreoffice snap?
  <Chipaca> ogra_, because the binary needs to be called "shutdown"; imagine what happens if I put busybox there
  <Chipaca> ogra_, (spoiler: nothing; the busybox i tried didn't have that applet)
  <ogra_> well, if you put busybox there and create a link called shutdown, it should DTRT
  <ogra_> ah
  <ogra_> right, i was assuming we have the applet enabled
  <Paz_> qengho: Here is the latest snapcraft output with the 'stage' key commented out. http://pastebin.com/4MaLq7qK
  <Chipaca> ogra_, busybox will try to run as the applet even when symlinked
  <ogra_> hurricanehrndz, perhaps you get better results asking in #ubuntu-desktop (where the libreoffice maintainer tends to hang around)
  <ogra_> Chipaca, indeed ... i was assuming the applet is enabled
  <Paz_> qengho: As you can see, it is unable to find the 2 libs, qtelegram-ae and telegramqml
  <Paz_> qengho: I can see the .so files in my parts/.../src directory, however
  <hurricanehrndz> anyhow, has anyone else noticed spell checking does not work in libreoffice snap
  <rharper> ogra_: the build on 10-13 has cloud-init from my PPA in the .manifest, but 10-14 and newer don't;
  <rharper> comparing the build logs, when it's not included, there is an explicit purge of cloud-init* locales* ubuntu-core*;  I we see a 'Removing cloud-init; Purging configuration, and finally Del cloud-init'
  <ogra_> rharper, hmm, your livecd-rootfs is the wrong one
  <rharper> in the working case; there's only the 'Del cloud-init' line; but the files remain present in the core snap (and cloud-init is listed in the manifest)
  <ogra_> rharper, just throw it out
  <rharper> ogra_: I have an older version in my PPA but the logs show I'm picking up the one from the snappy-dev PPA
  <rharper> ogra_: which version of livecd-roofs should I be using?
  <rharper> Get:2 http://ppa.launchpad.net/snappy-dev/image/ubuntu xenial/main amd64 livecd-rootfs amd64 2.420+ppa46
  <rharper> is that not the right one ?
  <ogra_> yeah
  <ogra_> do you also see it getting the ubuntu-core meta package from our PPA ?
  <rharper> let's see
  <rharper> Get:65 http://ppa.launchpad.net/snappy-dev/image/ubuntu xenial/main amd64 ubuntu-core amd64 1.7.2 [2274 B]
  <ogra_> that looks good
  <ogra_> that has a hard dependency on cloud-init
  <rharper> huh
  <rharper> and indeed it pulls it in; I see it get installed
  <rharper> it's the purge part that's new
  <ogra_> well, grab the livecd-rootfs package and take a look at the changelog ... but we ship cloud-init by default in the normal core image ... so i wouldnt see why in your builds it gets removed
  <Simooon> alevipri, You are probably right.
  <ogra_> rharper, do you add/change any dependencies vs the archive cloud-init in your package ?
  <ogra_> that removal looks like you have a dependency on something added
  <ogra_> (and your package gets removed along with this)
  <rharper> ogra_: interesting
  <rharper> we've been updating it to be more explicit about dependencies (for example the ssh-import-id package)
  <rharper> I wonder which dep triggered it ?
  <rharper> the removal ?
  <ogra_> note that new dependencies require really thoourough discussion ... we are at the edge of our size restrictions of the image (actually there is quite a bugnch that will soon be dropped)
  <ogra_> ssh-import-id ids definitely nothing we want in the image
  <rharper> oh, right
  <ogra_> like lsb-release (which recently got in by accident but will soon be removed again)
  <ogra_> i just didnt get to do another cleanup yet
  <rharper> ogra_: this was quite helpful;  thank you for pointing me in the right direction
  <rharper> ogra_: is there a list of packages in the livecd-rootfs build that it explicitly purges?
  <ogra_> well, we make sure that we initially dont seed that stuff usually ... livecd-rootfs calls apt autoremove at some point ... the packages we explicitly remove are only apt, dpkg and locales
  <ogra_> there are scripts for these three in livecd-rootfs in the live-build/hooks/ubuntu-core dir
  <rharper> ogra_: great; I'll look at that
  <rharper> thanks again
  <ogra_> np
  <hurricanehrndz> anyhow, has anyone else noticed spell checking does not work in libreoffice snap
  <hurricanehrndz> Opps sorry for the spam
  <morphis_> pitti: you already finished the work?
  <pitti> morphis_: yes; I built a xenial package, lcoal autopkgtests just succeeded, so I'll upload to the SRU queue and update the bug
  <pitti> morphis_: I included your path change
  <morphis_> pitti: awesome, does it include the mkwifi driver bind fix as well? if yes I can ask mvo to push that package directly to our ppa
  <pitti>    * Blacklist mwifiex_pcie from rebinds (work around LP: #1630285)
  <mup> Bug #1630285: mwifiex_pcie crashes after several bind/unbind <kernel-da-key> <originate-from-1623583> <plano> <HWE Next:New> <linux (Ubuntu):Triaged> <https://launchpad.net/bugs/1630285>
  <pitti> morphis_: I suppose you meak that one
  <pitti> morphis_: yes, that landed upstream too (in 0.13/zesty), so it's included in the  backport
  <pitti> morphis_: https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=nplan
  <mup> PR snapd#2161 closed: interfaces/builtin: add dcdbas-control interface <Critical> <Created by tonyespy> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2161>
  <mup> PR snapd#2195 closed:  interfaces/builtin: add dcdbas-control interface <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2195>
  <pitti> morphis_: I think the "edge" (or whatever) snappy images are built including -proposed, so if that gets reviewed/accepted soon, you might not even need a PPA upload
  <pitti> apw: ^ if you have a minute, maybe you can review the nplan xenial SRU
  <apw> pitti, sure
  <morphis_> pitti: I've justed checked with niemeyer and mvo and we decided to leave it out of RC
  <morphis_> pitti: so no hurry
  <pitti> morphis_: apw just accepted it, anyway
  <morphis_> pitti: so it will be in xenial-updates in a bit?
  <pitti> morphis_: in a week (assuming it gets verified in time, so please report back to the bug); but as I said, I believe snappy images are built with -proposed, so the next image should pick it up
  <morphis_> aye
  <slangasek> morphis_: leave it out of RC> but is this a requirement for GA?
  <morphis_> slangasek: yes
  <slangasek> ok
  <morphis_> otherwise static IP configuration does not make sense inside console-conf
  <morphis_> as you can never reach the SSO service
  <mup> PR snapd#2196 opened: debian: run our udev rule before the snap udev rules <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/2196>
  <mup> Bug #1635335 opened: main.go warning to stderr about syslog <Snappy:New> <https://launchpad.net/bugs/1635335>
  <mup> PR snapd#2196 closed: debian: run our udev rule before the snap udev rules <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2196>
  <mup> PR snapd#2197 opened: debian: ensure missing dirs for auto-import and partial <Created by mvo5> <https://github.com/snapcore/snapd/pull/2197>
  <mup> PR snapd#2198 opened: tests: only check pc model for the ubuntu-core-16-64 system <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2198>
  <mup> PR snapd#2197 closed: debian: ensure missing dirs for auto-import and partial <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2197>
  <mwhudson> ok so we
  <mwhudson> ok so we're not panicing to get the console-conf changes in right now now now?
  <mup> PR snapd#2199 opened: osutil: add chattr funcs <Created by chipaca> <https://github.com/snapcore/snapd/pull/2199>
  <mwhudson> pitti: hm
  <mwhudson> i got a netplan failure in testing with
  <mwhudson> 2016-10-20 19:36:29,021 subiquitycore.utils:130 run_command returning: {'status': 1, 'err': "Error in network definition //etc/netplan/00-snapd-config.yaml line 7 column 17: address '8.8.8.8' is missing /prefixlength\n", 'output': ''}
  <mwhudson> surely you don't have to write the nameserver address as 8.8.8.8/32
  <mwhudson> i wonder what went wrong
  <slangasek> mwhudson: maybe cyphermox is currently fixing this?  there was a mismatch between console-conf and nplan about which level the dns server should be declared at
  <mwhudson> ah ok
  <cyphermox> err, what?
  <cyphermox> oh
  <mwhudson> oh yes
  <pitti> mwhudson: maybe you missed an identation?
  <mwhudson> yeah
  <cyphermox> mwhudson: that's because the nameservers are written in the wrong section
  <pitti> mwhudson: the per-interface addresses: needs prefix lenghts; the nameservers: addresses doesn't
  <mwhudson> yes i see it now
  <cyphermox> mwhudson: fixed in already in my local brandh
  <pitti> ok,
  <mwhudson> cyphermox: +1
   * mwhudson goes back to grinding email
  <cyphermox> mwhudson: I'll be pushing this in a minute, and preparing to build it in our PPA, along with a new image -- let me know if you have other fixes to land along with it
  <mwhudson> cyphermox: oh one thing
  <mwhudson> cyphermox: remove_ipv4_networks needs to clear gateway4 on Networkdev
  <cyphermox> ok
  <mwhudson> cyphermox: and, uh something needs to clear out the nameservers config when you enable dhcp too i guess
  <mwhudson> nameservers/searchdomains
  <cyphermox> mwhudson: here, pushed; please feel free to add your fixes now while I update the setup to use our PPA
  <mwhudson> cyphermox: pushing my fixes
  <mwhudson> cyphermox: i haven't tested in a kvm yet, just dry run
  <cyphermox> ok
  <mwhudson> oh yeah, when i make an image locally i have to wait for cloud-init to time out
  <mwhudson> which is very confusing
  <mwhudson> cyphermox: tested in kvm now, seems to work \o/
  <cyphermox> ok, pushed your changes?
  <cyphermox> I see you did
  <cyphermox> ok, spinning a new release for the PPA
  <mwhudson> cyphermox: yay
  <rharper> mwhudson: you should be able to provide a seed so it won;t timeout looking for one (or disable cloud-init via cmdline or file in the image)
  <mwhudson> rharper: ok
  <mwhudson> i guess we do actually want it to run by default for the cloudy cases
  <mup> Bug #1635413 opened: newgrp doesn't work on classic <Snappy:New> <https://launchpad.net/bugs/1635413>
  <rharper> mwhudson: yeah; currently one has to create a new gadget which includes a 'cloud.conf' file in the gadget to prevent cloud-init from being disabled by default; so your "hang" seems strange to me
  <rharper> assuming your testing UC 16 recent images (from ~ogra 's people page)
  <mwhudson> rharper: i am making images myself
  <rharper> via ubuntu-build ?
  <mwhudson> ubuntu-image
  <rharper> err, yeah
  <rharper> snap prepare image should be disabling it
  <rharper> unless your gadget has cloud.conf in it
  <mwhudson> snap versoin 2.16ubuntu3
  <rharper> which the pc gadget doesn't
  <mwhudson> i'm just using the standard 'pc' gadget
  <rharper> very strange
  <rharper> from edge? or stable
  <hurricanehrndz> ogra_: Thanks for the heads up
  <mwhudson> rharper: edge
  <mwhudson> rharper: i'm using my own model assertoin but i don't see how that matters
  <rharper> mwhudson: very strange
  <rharper> you can inspect your image  (sudo kpartx -va <image>;  sudo mount /dev/mapper/loopNp3 /mnt;  find /mnt ) ; you should see /mnt/system-data/etc/cloud/cloud-init.disabled
  <rharper> which prevents cloud-init from running altogether;  if you see /etc/cloud/cloud.cfg; then the pc gadget you're using must have a 'cloud.conf' file in it
  <rharper> that's my experience building images with my own models for testing system-user assertions with newer cloud-init to inject those via user-data testing
  <mwhudson> mount: mount /dev/mapper/loop16p3 on /mnt failed: Structure needs cleaning
  <mwhudson> what
  <mwhudson> rharper: i don't really have anything in /mnt/system-data/ ?
  <mwhudson> rharper: or do you mean after i've booted the image?
  <mwhudson> i wonder if i should try ubuntu-image from the archive rather than snap
  <rharper> mwhudson: I'm using ubuntu-image from the beta channel
  <mwhudson> ubuntu-image          0.5+mvo8  15   canonical   devmode
  <rharper> it writes out .img file, which has 3 partitions , the 3 is the system-data/writable one; that includes the kernel, and core snaps
  <rharper> that's old
  <mwhudson> $ snap refresh --channel beta ubuntu-image
  <mwhudson> error: cannot refresh "ubuntu-image": snap "ubuntu-image" has no updates available
  <mwhudson> oh --devmode
  <rharper> ubuntu-image  0.5+mvo13  20   canonical  devmode
  <mwhudson> yeah ok
  <mwhudson> getting 22 from edge now
  <rharper> and I'm running snapd from xenial-proposed
  <rharper> 2.16, something, but I think you're there too
  <rharper> the new ubuntu-image + snapd prepare-image should get you going with a nocloud-net seed by default (and it's disabled by default)
  <mwhudson> rharper: looks happier indeed
  <rharper> cool
  #snappy 2016-10-21
  <hamptus> Hi everyone. I'm building an application using Kivy (https://kivy.org/) and it works on my laptop outside of a snap, but once I build it within a snap everything works except for the text input. Specifically, when I type into the application, it sees the keyboard events, but nothing shows up in the TextInput widget.
  <hamptus> I asked on the Kivy channel, but no one could help.
  <hamptus> This is the code for my snap: https://github.com/hamptus/kivy-snap
  <hamptus> If you run it, you can see that the key presses do print out to the console, but don't appear on my application. Can anyone think of a reason why?
  <mup> PR snapd#2200 opened: provide a human readable error message when download fails due to non purchase <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2200>
  <ogra_> sil2100, https://github.com/CanonicalLtd/snappy-docs/blob/master/core/images.md
  <sil2100> ogra_: thanks!
  <sil2100> This is what I needed
  <ogra_> fgimenez, https://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ has new pi images with the new kernel the kernel team built tonight ...
  <ogra_> davmor2, ^^
  <ogra_> (i'll test them myself the next session, but any extra data point helps)
  <davmor2> ogra_: thanks I'll let rvr know
  <Paz_> Hi. Does anyone know how to pull down a particular version of a source pointing to git. I have the commit hash
  <Paz_> I should add, I want to do this in my YAML file
  <mup> Bug #1635582 opened: inhibit snap refresh while console-conf is running <Snappy:New> <https://launchpad.net/bugs/1635582>
  <mup> Bug #1635584 opened: "snap interfaces" output hides some magical, essential package name <Snappy:New> <https://launchpad.net/bugs/1635584>
  <kyrofa> Paz_, for git, snapcraft supports source-branch and source-tag
  <kyrofa> Paz_, I don't think specific commit hashes are supported
  <Paz_> kyrofa: Thanks.
  <fasda> Can Snappy Ubuntu be installed on VirtualBox? I am running Windows host
  <Paz_> Anyone know how to include libraries (.so files) that I have staged into the build process for building my final part? They don't seem visible
  <mup> PR snapd#2201 opened: spread.yaml: Ensure ubuntu user has passwordless sudo for autopkgtests <Created by plars> <https://github.com/snapcore/snapd/pull/2201>
  <mup> PR snapd#2202 opened: image: work for a user <Created by chipaca> <https://github.com/snapcore/snapd/pull/2202>
  <Son_Goku> zyga: ping
  #snappy 2016-10-22
  <mup> PR snapcraft#865 closed: Add `init-plugin`  <Created by jaymell> <Closed by jaymell> <https://github.com/snapcore/snapcraft/pull/865>
  <hamptus> Hi. I'm building a Python desktop application that listens for SDL2 events. On my dev machine (Ubuntu 16.04) the SDL_TextInputEvent is fired (Along with the SDL_KEYDOWN event). But, when I build the app to use as a snap, the SDL_TextInputEvent is not fired (the other events are). Any ideas?
  <mup> Bug #1577472 changed: The remapped $HOME directory shows as read-only to applications running in a snap <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1577472>
  <manuki> Hello, I have a question that might look stupid but I couln't find the answer. How to I mount automatically a hard drive after startup ?
  <manuki> snappy is installed on an SDD nvme0n1 p1, p2, p3, p4, p5, and I would like to mount automatically /dev/sda1 to /writable/HDD
  <manuki> I can't touch /etc/fstab as there is a warning in the file: "# DO NOT EDIT THIS FILE BY HAND, YOUR CHANGES WILL BE OVERWRITTEN"
  <manuki> writable-path(5) doesn't help either as (source: http://manpages.ubuntu.com/manpages/wily/man5/writable-paths.5.html) the mount point must be a "A  pre-existing  directory on the read-only root partition"
  <lightuniverse> hi
  <lightuniverse> is anyone online?
  #snappy 2016-10-23
  <nhandler> I've been having an interesting time playing around with snapcraft. Managed to get Packer snapped up (https://uappexplorer.com/app/packer.nhandler). I have another snap just about ready to publish as well. I'm hoping to have some time tomorrow to write up a blog post about this experience.
  <mup> Bug #1635925 opened: Snappy Error - QOwnNotes Error with NTFS <ntfs> <qownnotes> <Snappy:New> <https://launchpad.net/bugs/1635925>
  <Simooon> How do you guys evaluate whether a snap package is trust worthy? For now I've been looking them up on uappexplorer.com and checking out the domain that issued their email, to get some sense of theor motivation, but that seems like a flawed mothod.
  <Elleo> has anyone hit this when creating opengl based snaps? "MESA-LOADER: failed to retrieve device information" followed by attempts and failures to load the wrong driver (i915_bpo_dri.so which doesn't exist), runs fine in devmode and other opengl snaps are fine
  <ahoneybun> well then: http://pastebin.ubuntu.com/23369719/
  <ahoneybun> rocketchat-server snap does this
  <Elleo> ahoneybun: are you using a non-ubuntu kernel?
  <mup> PR snapcraft#871 opened: Remove XXX comment from stage-packages <Created by nhandler> <https://github.com/snapcore/snapcraft/pull/871>
  <ahoneybun> Elleo: I think Linode compile their own
  <ahoneybun> since my 16.04 server is on 4.7
  <ahoneybun> they might have based it on a upstream one without the Ubuntu stuff in it
  <Elleo> ahoneybun: yeah, that'd be my guess; apparmor currently still requires some custom patches (I think someone's working hard on getting them into the mainline kernel at the moment though)
  <Elleo> ahoneybun: it looks like you could rebuild snap-confine with "--disable-apparmor" to make it work on such a system (albeit without any app confinement)
  <Elleo> ahoneybun: might also be able to install with --devmode without recompiling anything, not sure if that does enough to skip the whole apparmor processing or not
  <Elleo> ahoneybun: (again that'd result in no confinement)
  <mup> Bug #1636023 opened: Name registration fails with no helpful message <Snappy:New> <https://launchpad.net/bugs/1636023>
  <mup> PR snapcraft#872 opened: Add some further bash-completion <Created by cwayne18> <https://github.com/snapcore/snapcraft/pull/872>
  <not_MartinWimpre> hello, quick questions for anyone: is snapd working on Mint? is there a way to only get the "release" versions snaps like vlc versus the bleeding-edge git "daily" version?
  #snappy 2017-10-16
  <Son_Goku> sabdfl: so you're on this side of the pond now?
  <zyga-ubuntu> good morning
   * zyga-ubuntu does PR pass
  <zyga-ubuntu> mvo: o/
  <zyga-ubuntu> mvo: hey
  <zyga-ubuntu> mvo: I'm willing to do a deep dive on https://github.com/snapcore/snapd/pull/4030
  <mup> PR #4030: many: add internal squashfuse copy as "snapfuse" <Created by mvo5> <https://github.com/snapcore/snapd/pull/4030>
  <zyga-ubuntu> mvo: unless you are already doing that
  <Son_Goku> zyga-ubuntu
  <Son_Goku> that seems like a super-bad idea
  <zyga-ubuntu> Son_Goku: hey
  <zyga-ubuntu> Son_Goku: I know
  <zyga-ubuntu> Son_Goku: but if it's sufficient let's do it the best we can:
  <zyga-ubuntu> Son_Goku: I'd discard the generated files, discard uneeded code, integrate it into our build system, ete
  <zyga-ubuntu> Son_Goku: I haven't looked yet, maybe it is huge, maybe it will end up being a handful of files that we can just maintian
  <zyga-ubuntu> *maintain
  <zyga-ubuntu> Son_Goku: and good morning :)
  <zyga-ubuntu> Son_Goku: you're up early, it's barely sunrise here
  <Son_Goku> I'm about to pass out
  <zyga-ubuntu> my son is in a new school today
  <zyga-ubuntu> so I'm working from a coffee shop nearby
  <Son_Goku> zyga-ubuntu: I think it's a really bad idea to do this at all
  <zyga-ubuntu> Son_Goku: sure but what is the alternative?
  <zyga-ubuntu> Son_Goku: if we have to do it, we have to do it
  <zyga-ubuntu> Son_Goku: we canont just change apt defaults overnight (even though I agree they are bad)
  <zyga-ubuntu> Son_Goku: those should have been changed years ago
  <zyga-ubuntu> Son_Goku: but I think that now it is too late for that
  <Son_Goku> well, if people are updating graphically or using `apt upgrade`, they'd get it
  <Son_Goku> just fix apt-get upgrade's behavior
  <zyga-ubuntu> Son_Goku: yes but there is always a set that doesn't
  <zyga-ubuntu> Son_Goku: I think we've seen that already with snapd before (and we reverted a change that triggered that)
  <zyga-ubuntu> Son_Goku: it will also be a (I suspect) endless discussion in debian
  <zyga-ubuntu> Son_Goku: I think it's risky business to go and change that for snapd's sake
  <zyga-ubuntu> Son_Goku: (I'd still change it but on separate schedules)
  <zyga-ubuntu> Son_Goku: and once snapd can reliably depend on things, let's yank this
  <Son_Goku> then don't integrate it into the source tree
  <Son_Goku> just carry it as a separate tarball bundle
  <zyga-ubuntu> mmm
  <Son_Goku> that way it's harder to be lazy about it
  <zyga-ubuntu> that's interesting, perhaps that's a better idea indeed
  <zyga-ubuntu> Son_Goku: i'd require some tweaks to CI but yes, it's nicer this way
  <Son_Goku> zyga-ubuntu: I wish you'd do this with a vendor overlay tarball too
  <Son_Goku> basically, a tarball that only contains snapd-<version>/vendor/
  <zyga-ubuntu> Son_Goku: yes, I think that's a natural place to do this for releases
  <zyga-ubuntu> Son_Goku: I'll talk to mvo
  <Son_Goku> this would allow me to ship the snapd-<version>.tar.gz (or in debian parlance, snapd-<version>.orig.tar.gz) and snapd-<version>.vendor.tar.gz in distgit as sources while not using the vendor tarball on Fedora
  <Son_Goku> which would open the door to adding an EPEL build
  <Son_Goku> (aka CentOS)
  <mvo> zyga-ubuntu: a vendor tarball? we can do this easily
  <Son_Goku> I asked for this a year ago too, btw
  <mvo> :(
  <mvo> sorry
  <mvo> must have forgoten
  <Son_Goku> the experimental CentOS builds are super-brittle :(
  <Son_Goku> zyga-ubuntu: incidentally, for your amusement, with literally no expectation of anything working: https://copr.fedorainfracloud.org/coprs/ngompa/snapcore-el7/
  <mvo> Son_Goku: so snapd_2.28.5.{pristine,vendor}.tar.xz? a
  <Son_Goku> mvo: yep
  <Son_Goku> sounds fine with me :D
  <mvo> ok
   * mvo will update his release script
  <Son_Goku> mvo: basically, I need the base tarball to be closest to what git repo looks like, otherwise patches don't apply
  <Son_Goku> mvo: though you don't have to do weird underscores and whatnot :)
  <Son_Goku> unlike debian, I don't have such restrictions :)
  <mvo> Son_Goku: heh, ok
  <zyga-ubuntu> o/
  <Son_Goku> it can just be snapd-2.28.5.tar.xz and snapd-2.28.5.vendor.tar.xz
  <mvo> Son_Goku: ok, I may need to keep the current convention for people using our GH release page, so it might be snapd.vendor-only.tar.xz or I will just annouce the new format and assume that not a lot of people need to adjust their scripts
  <Son_Goku> sure
  <Son_Goku> that's fine
  <Son_Goku> I don't particularly care if you only just upload a vendor-only tarball
  <Son_Goku> as I can just get the regular one from the GitHub link as I do now
  <zyga-ubuntu> mvo: I think it's just a handful of people, we'll be fine
  <Son_Goku> I just need the vendor code in a separate tarball that I can extract
  <mup> PR snapd#4047 opened: snap-confine: init all arrays with `= {0,}` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4047>
  <zyga-ubuntu> mvo: .5 looks good so far
   * zyga-ubuntu tweaks details on 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>
  <Son_Goku> zyga-ubuntu: test and give karma for Fedora snapd updates
  <Son_Goku> they're on 2.28.5 now
  <mvo> zyga-ubuntu: could you or pawel try to reproduce the error on the pi3 that sergio got? I'm still nervous about it. otoh I have no report other than from sergio about it and would love to get that confirmed
  <zyga-ubuntu> mvo: I cannot do that today, sorry, I won't be home until after 18
  <zyga-ubuntu> mvo: it seems the error cachio got was repeated on >1 SD card he had
  <zyga-ubuntu> maybe it's just bad luck but it does seem to indicate more than random issue
  <zyga-ubuntu> Son_Goku: only after I'm home, sorry :/
  <zyga-ubuntu> mvo: though my pi3 is still up
  <zyga-ubuntu> mvo: I could try to test something remotely
  <zyga-ubuntu> pstolowski: hey
  <zyga-ubuntu> pstolowski: is your pi3 operational?
  <zyga-ubuntu> mvo: my pi3-1 is operational, though I cannot reflash it remotely
  <pstolowski> zyga-ubuntu, morning! yes, it is
  <zyga-ubuntu> pstolowski: I think mvo needs a little bit of help and I'm not at my office today
  <zyga-ubuntu> 09:12 < mvo> zyga-ubuntu: could you or pawel try to reproduce the error on the pi3 that sergio got? I'm still nervous about it. otoh I have no report other
  <zyga-ubuntu>              than from sergio about it and would love to get that confirmed
  <zyga-ubuntu> pstolowski: I can only run spread tests on pre-installed remotely
  <zyga-ubuntu> pstolowski: last week cachio ran into a bug where smoehing got corrupted in the boot process
  <zyga-ubuntu> pstolowski: it might be related to the SD card he was using (he tried two)
  <zyga-ubuntu> pstolowski: we need hands on testing to see if we can reproduce it
  <pstolowski> zyga-ubuntu, sure, happy to help. i need to reflash with latest edge image correct?
  <zyga-ubuntu> pstolowski: I think so, ideally build the image as cachio did
   * zyga-ubuntu looks 
  <zyga-ubuntu> pstolowski: look at this thread please: https://forum.snapcraft.io/t/snap-mode-try-on-raspberry-pi/2454
  <pstolowski> zyga-ubuntu, k
  <Guest92109> hello got stuck in network configuration can any one please help
  <zyga-ubuntu> Guest92109: hey, can you please ask a more precise question?
  <Guest92109> zyga-ubuntu: Sure
  <zyga-ubuntu> pstolowski: I commented on the thread with details of what I know
  <pstolowski> zyga-ubuntu, thanks
  <Guest92109> I got a machine with ubuntu core15.10
  <Guest92109> I need to configure eth0
  <Guest92109> I teied to edit /etc/network/interfaces file but it gives system is read-only message please help
  <zyga-ubuntu> Guest92109: 15.10 you say
  <zyga-ubuntu> hmmm
  <zyga-ubuntu> Guest92109: may I ask if you really want to use 15.10 or can you consider updating to ubuntu core 16?
  <pstolowski> zyga-ubuntu, what are the steps to build an image?
  <zyga-ubuntu> Guest92109: I don't think we support 15.10 anymore (apart from commercial contracts) as it was an early version and ubuntu core 16 has received immense fixes, features and improvements since
  <zyga-ubuntu> pstolowski: I think you need ubuntu-image and the pi3 model, one sec
  <zyga-ubuntu> pstolowski: $ sudo ubuntu-image -c beta -O pi3-beta.img pi3.model
  <Guest92109> <zyga-ubuntu> - I am using dell edge gateway 5000 series which comes with preinstalled snappy core 15.10 and need to configure same
  <zyga-ubuntu> Guest92109: it used to ship with 15.10 with the desire to update to 16-series, new releases are only using 16; in any case let me try to find someone who can help you
  <zyga-ubuntu> pstolowski: you need the pi3.model assertion
  <zyga-ubuntu> pstolowski: cachio sent a link somewhere to a repo with test scripts but I cannot find it
  <zyga-ubuntu> mvo: do you happen to remember how to fetch the pi3 model file
  <zyga-ubuntu> Guest92109: I've asked around but I don't know how soon I'll get an answer
  <zyga-ubuntu> Guest92109: may I suggest that you go to forum.snapcraft.io and ask your question there
  <Guest92109> zyga-ubuntu: thanks in advance would be a great help i am not getting any help onlien
  <zyga-ubuntu> Guest92109: please double check that you cannot upgrade your device to 16 series, then we can all help you easily
  <zyga-ubuntu> Guest92109: I think 15.10 is not supported anymore (apart from contractual obligations) and everyone is strongly encouraged to go to 16
  <Guest92109> zyga-ubuntu: Sure thanks but can u just answer is the read-only file system also persist in 16 series
  <Guest92109> While configuring /etc/network/interfaces file
  <zyga-ubuntu> Guest92109: yes although network configuration in 16 series is different and much much easier
  <zyga-ubuntu> Guest92109: apart from a menu-driven wizard we also use declarative YAML based nplan (netplan) configuration
  <zyga-ubuntu> Guest92109: while the system as a whole is read only the set of writable files is different
  <zyga-ubuntu> Guest92109: (between 16-series and 15.10)
  <zyga-ubuntu> kissiel: ^
  <zyga-ubuntu> kissiel: I think you are experienced with the dell gateways more than I am
  <Guest92109> zyga-ubuntu: Thanks can i get the steps of 16 series, i will get the idea regarding the configuration
  <zyga-ubuntu> Guest92109: it's a simple process you follow using the on-screen menu (also availale via serial port)
  <zyga-ubuntu> Guest92109: you can run "console-conf" after initial setup if you wish to change the configuration
  <kissiel> Guest92109: I'd poke around network-manager snap
  <zyga-ubuntu> kissiel: note, Guest92109 is using 15.10, I'm not sure we still ship that snap for 15.10
  <mvo> zyga-ubuntu, pstolowski sorry, was distracted, do you still need the pi3 model assertion ? i
  <mvo> pstolowski: "snap known --remote model series=16 brand-id=canonical model=pi3"
  <kissiel> zyga-ubuntu: ah, right. maybe joc will know more, I'll ping him when he gets online
  <zyga-ubuntu> mvo: thank you, I had a copy but I forgot how I got it
  <zyga-ubuntu> Guest92109: joc is in the UK timezone, he should be around soon
  <Guest92109> zyga-ubuntu: Thanks a lot for ur support one last thing how would i know if he comes online
  <pstolowski> mvo, zyga-ubuntu thanks! so, I'm going to rebuild the pi3 image, flash it, configure pi3, then add the assertion on it, then run ubuntu-core-upgrade spread test on it in a loop; did i miss anything?
  <zyga-ubuntu> pstolowski: the assertion is needed to build the image
  <pstolowski> ah!
  <zyga-ubuntu> pstolowski: you need to set up the pi for external backend
  <pstolowski> ok
  <zyga-ubuntu> pstolowski: this is described in tests/external-backend.md
  <zyga-ubuntu> pstolowski: have a look, you just flash & first-boot as usual
  <zyga-ubuntu> pstolowski: then run a few scripts
  <zyga-ubuntu> pstolowski: (from the tree)
  <zyga-ubuntu> pstolowski: and then you are ready for testing
  <zyga-ubuntu> pstolowski: ask if you need help, I did this on Friday
  <pstolowski> zyga-ubuntu, oh yeah, i know that, just unclear on building the image + assertion part
  <mvo> pstolowski: yes, what zyga-ubuntu said and good luck
  <__chip__> morning peeps
  <zyga-ubuntu> __chip__: hello, good morning
  <__chip__> i'm on the road today -- doing admin stuff wrt the boys' schooling
  <__chip__> got my tablet with me (thus the nick)
  <zyga-ubuntu> __chip__: I'm on the road too, and my son changed school (well, maybe, trial week)
  <zyga-ubuntu> __chip__: fingers crossed for both of us :
  <zyga-ubuntu> :)
  <__chip__> zyga-ubuntu: hah. this is about changing schools also (looking into a different school)
  <__chip__> so, yeah, good luck to us
  <pstolowski> mvo, zyga-ubuntu ok, all clear, i see where the assertion is needed now, thanks
  <zyga-ubuntu> mvo: if you want I can keep running that test on my pi3 but I think it depends on SD card model
  <zyga-ubuntu> mvo: and some models corrput something
  <zyga-ubuntu> mvo: otherwise why would it never fail vs always fail?
  <pstolowski> ok, got the image built, falshing
  <mvo> zyga-ubuntu: did you build the image yourself when you did the test? or download a pre-made one? maybe its a specific combination of the ubuntu-image cmdline/kernel/gadget or something
  <zyga-ubuntu> mvo: no, I ran the pre-made one
  <zyga-ubuntu> mvo: ah, indeed
  <zyga-ubuntu> mvo: could be!
  <__chip__> pedronis: are you working today?
  <zyga-ubuntu> morphis: Guest92109 here has a dell gateway with ubuntu 15.10 and need help, can you please try to render assistance?
   * zyga-ubuntu is on the move again, I'll be online in ~~ hour
  <zyga-ubuntu> ttyl
  <mup> Bug #1723881 opened: [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>
  <joc> Guest92109: hi, i see you had some questions about the 5000 series gateways
  <pstolowski> mvo, it failed for me, but with slightly different output http://pastebin.ubuntu.com/25751741/
  <pstolowski> Error: "snap_mode" not defined ?
  <pstolowski> mvo, it seems that re-running the test again after the above failure gives another unexpected failure, i assume the box is now in a bad shape and needs re-flashing before attempting tests again?
  <mvo> pstolowski: looking
  <mvo> pstolowski: could you please paste the other failure too?
  <mvo> pstolowski: this is very different from what cachio got, it went much further
  <pstolowski> mvo, the other failure after I re-run the tests: http://pastebin.ubuntu.com/25751799/
  <mvo> pstolowski: and a different error, I would love to compare the revisions of core/gadget/kernel you have and the revision of ubuntu-image to see where things are different
  <pstolowski> mvo, external:ubuntu-core-16-arm-32 .../tests/main/ubuntu-core-upgrade# snap list
  <pstolowski> Name        Version        Rev   Developer  Notes
  <pstolowski> core        16-2.28.5      3214  canonical  core
  <pstolowski> pi2-kernel  4.4.0.1075.75  43    canonical  kernel
  <pstolowski> pi3         16.04-0.5      6     canonical  gadget
  <mvo> pstolowski: maybe we can put it into sergios forum post? this way we can compare notes more easily
  <pstolowski> sure
  <mvo> pstolowski: the followup looks indeed just like a test issue with a strange state, might be enough to just "rm curChg" in the debug shell and run again
  <mvo> pstolowski: thank you, this looks promising, it does not fail in the omg-cant-explain-what-is-going on way at least (which is the case for sergios error, I can't make any sense of it)
  <pstolowski> mvo, I hope I didn't miss anything in the setup. will re-try from scratch in a while
  <mvo> pstolowski: if you could rm curChg and run again, that would be nice
  <mvo> pstolowski: miss something> well, if its really hard to reproduce it means its not wide-spread at least. i.e. we can't reproduce it with the pre-build images, we can't reproduce the same error with ubuntu-image, so it must be sometihng special
  <mvo> pstolowski: well, hopefully
  <kissiel> Guest92109: joc is online, you could consult him
  <jamespage> anyone else hitting https://bugs.launchpad.net/snapcraft/+bug/1723898 ?
  <mup> Bug #1723898: Unable to build snaps using python plugin - pypi.debian.net no longer accessible <Snapcraft:New> <https://launchpad.net/bugs/1723898>
  <jamespage> for the life of me I can't actually figure out where snapcraft is configured to use that
  <mvo> hrm, hrm, interfaces-cups-control test is busted
  <mvo> (in debian-unstable)
  <zyga-ubuntu> re
  <zyga-ubuntu> (and right on time)
  <mvo> zyga-ubuntu: heh :) debian-unstable cups control test is busted, that rings a bell, iirc we had artful broken as well recently. anyways, I'm debugging
  <Guest92109> kissiel: Thanks
  <Guest92109> joc: Hello I have a dell edge geteway with ubuntu 15.10 snappy core
  <Guest92109> I am having difficulty in configuring the network using the traditional ubuntu method in the interfaces file
  <Guest92109> as the system is read-only
  <joc> Guest92109: if i could first make a recommendation: if you are just beginning a project then zyga & kissiel were correct in urging you to update to Series 16 Ubuntu Core, we have been working with Dell to transition customers for serveral months to Series 16
  <joc> Guest92109: in addition I believe Dell announced that your version of Ubuntu Core would go End Of Life on September 30th so you will not receive further security updates
  <zyga-ubuntu> mvo: ack
  <zyga-ubuntu> mvo: let me know if I can help in some way
  <zyga-ubuntu> mvo: I'm updating my branches
  <joc> Guest92109: in the meantime the supported method for configuring the network is to use network-manager which should come preinstalled on your system
  <mvo> zyga-ubuntu: yeah, I keep you updated, waiting for a debug shell right now. a cheap way would be to simply disable the test
  <mvo> zyga-ubuntu: on debian
  <zyga-ubuntu> mvo: is there a thread?
  <mvo> zyga-ubuntu: otoh, it will probably come back to use for artful+1
  <mvo> zyga-ubuntu: not yet, I just noticed with my most recent PR that it fails
   * zyga-ubuntu was reading something while stuck in transit and is a bit freaked out about this: 
  <zyga-ubuntu> ok
  <zyga-ubuntu> http://papers.mathyvanhoef.com/ccs2017.pdf
  <zyga-ubuntu> mvo: note, our spread image differs for linode and qemu
  <zyga-ubuntu> mvo: qemu uses, I believe, real sid, while linode is using stretch
  <zyga-ubuntu> mvo: I wanted to fix this a while ago but I wans't sure how
  <mvo> zyga-ubuntu: yeah, I'm running against linode just to be sure
  <mvo> zyga-ubuntu: however there was a new upstream release of cups to unstable yesterday so most likely fallout from that
  <Guest92109> joc: thanks for your valuable information
  <Guest92109> Will contact them and do the same
  <Guest92109> Can i get a doc where complete step is mentioned how to open network manager and configure
  <zyga-ubuntu> mvo: aha
  <zyga-ubuntu> mvo: that paper I linked to looks like a massive security issue that affects everything using wifi, expect surge of updates everywhere :/
  <Guest92109> I am new to core and tried various commands using snappy but could not get the setting . Thanks in advance
  <zyga-ubuntu> morphis: I think you need to update hostapd
  <joc> Guest92109: configuration should be via the "nmcli" command
  <zyga-ubuntu> pstolowski: can you try the test a few more times?
  <Guest92109> joc: sure will check and let u know :)
  <joc> Guest92109: there should be plenty of documentation for that in mangpages and on the internet, I would have to check with our Dell liasons whether there is some official docs for customers
  <Guest92109> joc: Thanks a lot would be a great help
  <mup> PR snapd#4048 opened: tests: fix interfaces-cups-control test for cups-2.2.5 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4048>
  <zyga-ubuntu> mvo: +1 :)
  <mvo> zyga-ubuntu: ta
  <mvo> zyga-ubuntu: silly idea - could we simply govendor the squashfuse binary :) ?
  <mvo> zyga-ubuntu: it looks like govendor does not care if the git repo is go
  <zyga-ubuntu> mvo: mmm, dunno, how do you envision that? a go binary linking to something that is squashfuse itself or just a "govendor sync" repo that keeps all of squashfuse code but is unrelated to go
  <mvo> zyga-ubuntu: the later, just to have the git checkout and we do the building ourselfs
  <zyga-ubuntu> I like that much more than the PR
   * kalikiana coffee
  <mvo> zyga-ubuntu: its slightly crazy but maybe a nicer option than the massive embedding
  <zyga-ubuntu> mvo: yes, certainly nicer
  <zyga-ubuntu> *certainly
  <ogra_> mvo, urgh ... i think i found your reason for the upgrade test issues ...
  <ogra_> mvo, https://dashboard.snapcraft.io/dev/snaps/5596/configurations/
  <ogra_> candidate and beta use the stable gadget (ancient firmware and uboot)
  <ogra_> if you dont start from edge this wil most likely always fail with newer kernels
  <ogra_> pstolowski's last comment on the thread helped a great deal ...
  <ogra_> mvo, if you dont mind, i'll switch beta and candidate to the latest edge gadget
  <pstolowski> ogra_, oh, the versions?
  <ogra_> pstolowski, yeah, your pi3 is the stable one
  <ogra_> (pi3 snap)
  <mvo> ogra_: lets not change it just yet, lets see if cachio can refresh to edge gadget to make the issue go away
  <mvo> ogra_: but it sounds great
  <mvo> ogra_: I mean, great in the sense that it sounds like a plausible theory
  <mvo> ogra_: and also would explain all the oddness around the issue
  <ogra_> mvo, well, he'Ãd have to build an edge image and then downgrade kerne/coe to the espective target channels he wants to test
  <ogra_> mvo, what doesnt go well with that theory is that it only started recently
  <mvo> ogra_: yeah, he says it started recently, hm, hm
  <ogra_> there must be another aspect to it since the gadget channel setup has never changed after the first stable one
  <ogra_> but it is defintely one of the issues
  <pstolowski> ogra_, hmm, ok all the rpi3 stuff is new to me, so please bear with me... I didn't miss any setup test, did I?
  <ogra_> pstolowski, well, if i wanted to test beta i'*d also just builld a beta image, the issue is on ou side, not on yours
  <ogra_> *our
  <pstolowski> ok
  <pstolowski> ogra_, interestingly, i re-flashed and testing again, it a 3rd run of the test and so far so good
  <pstolowski> *it's a 3rd
  <mvo> pstolowski: ha!
  <ogra_> and pi3 is still at rev 6 ?
  <mvo> pstolowski: so you and cachio need to compare notes what is different
  <pstolowski> ogra_, yes, rev 6 still
  <ogra_> ++ fw_printenv snap_mode
  <ogra_> ## Error: "snap_mode" not defined
  <mvo> ogra_: lets try to find what this other factor is, then we need to fix the gadget to match the beta kernel. but lets try to get to the bottom of this first
  <ogra_> thats the thing that made me curious ...
  <ogra_> the stable gadget has still all the old variablle names
  <ogra_> the test should fail exactly there ...
  <ogra_> (from http://pastebin.ubuntu.com/25751741/)
  <zyga-ubuntu> github feature idea: mark a PR as "unbreaks master" and stop testing and landing all other PRs
  <zyga-ubuntu> could help us with cases like the one today
  <zyga-ubuntu> do we have any friends there?
  <mvo> ogra_: hm, things should be ok if snap_mode is not definied at all (unless I miss something). when it needs to get set, snapd will set it. in what line in http://pastebin.ubuntu.com/25751741/ should it fail you mean?
  <ogra_> mvo, sure, the point is that snap__mode doesnt even exist ... which is true for the ancient gadget but not true for all newer ones
  <ogra_> mvo, in the old gadget only "snappy_mode" is set
  <zyga-ubuntu> the price of renaming
  <ogra_> mvo, indeed just the missing variable isnt an issue but an indicator that yoou run old and incompatible binary bllobs and uboot
  <zyga-ubuntu> is eternal backwards compatibilty support code
  <mvo> ogra_: aha, yes
  <zyga-ubuntu> (said with the voice of malcom mcdowell)
  <zyga-ubuntu> *malcolm*
  <pstolowski> mvo, ogra_ ah, no, it eventually failed again http://pastebin.ubuntu.com/25752176
  <mup> PR snapd#4030 closed: many: add internal squashfuse copy as "snapfuse" <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4030>
  <zyga-ubuntu> Read error on /boot/uboot/uboot.env: Success
  <zyga-ubuntu> something is not setting errno
  <mvo> pstolowski: if you hexdump -C /boot/uboot/uboot.env - what happens?
  <ogra_> mvo, note that this can actuallly be a eal corruption issue due to the ancient uboot vfat version in stable (vs very new kernel in beta and candidate)
  <pstolowski> mvo, I exited the spread test shell, is it still useful if I do that after spread restored the stuff?
  <ogra_> pstolowski, just call fw_printenv alone
  <zyga-ubuntu> pstolowski: I think so
  <zyga-ubuntu> just ssh into it
  <mvo> pstolowski: I think so too
  <ogra_> the test proobably swallows output
  <mvo> ogra_: yeah, corruption of the vfat would make a lot of sense. what version of uboot do we have there and in edge? might be worthwhile to do a quick scan of the uboot git log to see if anything related to vfat is there
  <pstolowski> ogra_, mvo, zyga-ubuntu fw_printenv output: http://pastebin.ubuntu.com/25752195/
  <ogra_> mvo, some 2015 version iirc, we neve properlly documented it and it isnt built fom source
  <ogra_> that onlly changed in edge when we switched to actual uboot source builds
  <ogra_> pstolowski, well, that doesnt look corrupt at all
  <mvo> pstolowski: the first call looks very short
  <ogra_> mvo, seeing that i take back my vfat theory :P
  <pstolowski> mvo, yeah, ignore it, probably I made a mistake copying
  <ogra_> there must be some issue how the test uses fw_printenv instead
  <mvo> ogra_: well: "+ fw_printenv
  <mvo> Read error on /boot/uboot/uboot.env: Success" is the error from the test
  <mvo> pstolowski: anything in dmesg?
  <mvo> pstolowski: related to read error or so?
  <pstolowski> mvo, snappy_mode in there?
  <ogra_> mvo, yes ... but nmanualy it woks
  <ogra_> pstolowski, yeah, eftover
  <ogra_> *left
  <mvo> ogra_: yeah, still odd, how could the test use it incorrectly? also no errno set :/
  <ogra_> pstolowski, there should also be a snap_mode *if* you ae in any of try/trying ... it gets unset afterwards
  <mup> PR snapd#4048 closed: tests: fix interfaces-cups-control test for cups-2.2.5 <Critical> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4048>
  <ogra_> mvo, well, i dont know, but manually running it obviously works ... perhaps missing env ? or does the test unmont snappy-boot at some point ?
  <mvo> ogra_: I don't think it does
  <pstolowski> mvo, nothing stands out in dmesg.. except for [    6.989717] EXT4-fs (mmcblk0p2): couldn't mount as ext3 due to feature incompatibilities
  <pstolowski> [    7.004959] EXT4-fs (mmcblk0p2): couldn't mount as ext2 due to feature incompatibilities
  <mvo> pstolowski: what ogra said, snappy_mode= can be ignored
  <ogra_> pstolowski, thats /writable ;) and normal noise from the ext4 driver looping over fs capabilities
  <zyga-ubuntu> mvo: could it be (in any way) related to the fact that more recent ubuntu versions use incompatible feature set for ext4
  <ogra_> (i whish we could just quieten that)
  <zyga-ubuntu> csum_metadata
  <zyga-ubuntu> chsum_metadata*
  <ogra_> zyga-ubuntu, wrong path :P we talk about a vfat ;)
  <zyga-ubuntu> ogra_: p2 is vfat?
  <zyga-ubuntu> ogra_: I thought p1 is
  <ogra_> zyga-ubuntu, system-boot is
  <ogra_> everywhere
  <ogra_> mvo, the original test ooutput has "mesg: ttyname failed: Inappropriate ioctl for device" https://paste.ubuntu.com/25728858/
  <ogra_> mvo, i wonder if that could inflluence fw_printenv functionality somehow
  <mvo> ogra_: I think thats something from spread actually, but it might be, I am looking at fw_printenv from the uboot git now
  <ogra_> mvo, better look at the one fgrom the deb source
  <ogra_> thats what we use
  <ogra_> (and it might be far behind git)
  <mvo> ogra_: the xenial one?
  <ogra_> yep
  <ogra_> 2016.01+dfsg1-2ubuntu3 ... nearly 2y old
  <zyga-ubuntu> how can 2016 be nearly two years old?
  <zyga-ubuntu> well,
  <zyga-ubuntu> nearly ok
  <ogra_> january 2016 ...
  <ogra_> (i could have said 22 months if you'd prefer that :P )
  <pstolowski> my tests also had a couple of 'mesg: ttyname failed: Inappropriate ioctl for device' errors
  <ogra_> yeah
  <ogra_> must not be the issue but it might indicate that you tty is somewhat different to the one you have when running fw_printenv manually
  <ogra_> something is surelly with the env
  <mvo> pstolowski, ogra_ http://git.denx.de/?p=u-boot.git;a=blob;f=tools/env/fw_env.c;h=ab06415898c2f718e8a926879379b1f8d74ca55d;hb=HEAD#l760 is the only place where this error is produced (looks the same in the 2016 version)
  <zyga-ubuntu> too bad it doesn't display rc
  <mvo> pstolowski: I would argue the code in there is incorrect
  <zyga-ubuntu> it may be just a partial read
  <mvo> zyga-ubuntu: yeah, exactly
  <zyga-ubuntu> (truncated environment?)
  <mvo> zyga-ubuntu: you mean something else truncated the uboot.env?
  <zyga-ubuntu> mvo: last week we learned how error messages suck
  <zyga-ubuntu> mvo: well, not sure if really truncated
  <zyga-ubuntu> mvo: I didn't read the rest of the code
  <zyga-ubuntu> mvo: I meant that if you have a fixed buffer
  <zyga-ubuntu> mvo: and then read until EOF
  <ogra_> well, uboot.env isnt truncated if you manually run fw_printenv
  <zyga-ubuntu> mvo: then eventually you will get a partially complete buffer
  <mvo> zyga-ubuntu: there might be a signal
  <zyga-ubuntu> mvo: unless there's some assumption about the alignment of the file
  <zyga-ubuntu> mvo: "alignment" in blocks
  <mvo> zyga-ubuntu: but yeah, I think the code in there is slightly naive
  <zyga-ubuntu> mvo: might be but we don't know
  <mvo> zyga-ubuntu: yeah, sadly it does not print rc which is the crucial bit
  <mvo> s/is/would be/ :/
  <zyga-ubuntu> mvo: maybe we just need to patch snapd to always write the environment in multiples of some block size
  <ogra_> mvo, zyga-ubuntu, but why does it work manually then ?
  <zyga-ubuntu> mvo: and fill the rest with zeros
  <zyga-ubuntu> ogra_: I don't suppose it is corrected by that process somewhere
  <zyga-ubuntu> ogra_: maybe it fails, then gets fixed, and then is correct
  <zyga-ubuntu> ogra_: we don't have snapshots of the file during the process to say
  <ogra_> well, you could stop the test before it calls fw_pintenv the first time i suppose
  <ogra_> and then manually run the command to see
  <mvo> pstolowski: could you please rerun the test just to see if it fails in a similar way again? plus please update the forum post so that all the "evidence" is in a single place
  <zyga-ubuntu> ogra_: it doesn't fail for me, I cannot reflash beta sadly (AFK)
  <mvo> zyga-ubuntu: I still suspect a signal that might cause the short read, but what signal could it be? usually it would be something like SIGWINCH but that is probably not it on a spread run and no other signal springs to my mind
  <zyga-ubuntu> phone
   * mvo lunch
  <zyga-ubuntu> re
  <zyga-ubuntu> mvo: so I was thinking that it could be a signal _but_ I'm somewhat skeptical; let me check something
  <zyga-ubuntu>        SIGWINCH    28,28,20    Ign     Window resize signal (4.3BSD, Sun)
  <zyga-ubuntu> SIGWINCH is ignored by default
  <ogra_> i guess we dont call out to fw_setenv when writing thhe file but use our own write finction ?
  <ogra_> *function
  <ogra_> (from snapd that is)
  <zyga-ubuntu>    Interruption of system calls and library functions by signal handlers
  <zyga-ubuntu>        If a signal handler is invoked while a system call or library
  <zyga-ubuntu>        function call is blocked, then either:
  <zyga-ubuntu>        * the call is automatically restarted after the signal handler
  <zyga-ubuntu>          returns; or
  <zyga-ubuntu>        * the call fails with the error EINTR.
  <zyga-ubuntu> ogra_: I think so
  <zyga-ubuntu>        If a blocked call to one of the following interfaces is interrupted
  <zyga-ubuntu>        by a signal handler, then the call will be automatically restarted
  <zyga-ubuntu>        after the signal handler returns if the SA_RESTART flag was used;
  <zyga-ubuntu>        otherwise the call will fail with the error EINTR:
  <zyga-ubuntu>        * read(2), readv(2), write(2), writev(2), and ioctl(2) calls on
  <zyga-ubuntu>          "slow" devices.  A "slow" device is one where the I/O call may
  <zyga-ubuntu>          block for an indefinite time, for example, a terminal, pipe, or
  <zyga-ubuntu>          socket.  If an I/O call on a slow device has already transferred
  <zyga-ubuntu>          some data by the time it is interrupted by a signal handler, then
  <zyga-ubuntu>          the call will return a success status (normally, the number of
  <zyga-ubuntu>          bytes transferred).  Note that a (local) disk is not a slow device
  <zyga-ubuntu>          according to this definition; I/O operations on disk devices are
  <zyga-ubuntu>          not interrupted by signals.
  <zyga-ubuntu> so I think the C code for uboot env handling may not be setting SA_RESTART in any place
   * zyga-ubuntu looks
  <pstolowski> mvo, will do
  <zyga-ubuntu> mvo: still no idea which signal it might be :/
  <zyga-ubuntu> ideally we'd rebuild that old uboot
  <zyga-ubuntu> and set a breakpoint and see
  <zyga-ubuntu> but ...
  <zyga-ubuntu> well
  <zyga-ubuntu> maybe we can?
  <zyga-ubuntu> pstolowski: can you reproduce this?
  <zyga-ubuntu> pstolowski: or does it happen only once?
  <zyga-ubuntu> pstolowski: ideally we'd have a copy of the binary that has this problem and the file that causes it
  <zyga-ubuntu> pstolowski: and then see what gdb tells us
  <ogra_> it prints the build date as very first line duing boot on serial
  <zyga-ubuntu> ogra_: any chance we can grab debug symbols for that build somewhere/
  <ogra_> nly via re-building ... i thinbk it gets stripped by default (it is a bootloade optimized for size after all)
  <zyga-ubuntu> ogra_: any -dbg package equivalent?
  <ogra_> noot reallly
  <ogra_> with the new setup it would be easy since we now build from upsteam tags ... stable was random local builds originally ... we need the string it prints, with lluck that had the commit in the version
  <ogra_> *has
  <zyga-ubuntu> aha
  <zyga-ubuntu> well, that depends on if pstolowski can reproduce this :)
  <zyga-ubuntu> ogra_: could you provide a build for pawel to try
  <zyga-ubuntu> ogra_: just that command with debug symbols with ~~ similar version (as close as you can get it)
  <ogra_> https://www.denx.de/wiki/DULG/DebuggingUBoot
  <ogra_> seems it is actually not stripped (nothing theer says you need a debug build)
  <zyga-ubuntu> pstolowski: can you run gdb and see if that build has symbols?
  <ogra_> https://www.denx.de/wiki/view/DULG/Debugging is a bit more informative and llinks to tips and tricks
   * zyga-ubuntu breaks, I'll probably miss standup but I may show up if lucky
  <pstolowski> just re-flashed to retest
  <zyga-ubuntu> re
  <zyga-ubuntu> Pharaoh_Atem: hey, can you remind me that repo sync issue in fedora/linode
  <zyga-ubuntu> Pharaoh_Atem: linode operators are in #linode but on OFTC, not freenode
  <zyga-ubuntu> Pharaoh_Atem: if you can give me those details again I'll collect everything and open a ticket
  <mvo> zyga-ubuntu, pstolowski just finished reading backlog. lets see if it is reproducible and then we attack it
  <pstolowski> mvo, ... and i'm having issues now on 1st boot after flashing. it's taking forever on 'random: nonblocking pool is initialized'
  <pstolowski> not sure if this is entropy issue or what. console-conf doesn't show up
  <ogra_> no, thats a red herring
  <ogra_> it is simply the last thing the kernel prints before switching consoles
  <mvo> pstolowski: hm, is the network cable attached?
  <pstolowski> mvo, no
  <ogra_> that might then take 2min for the timeout
  <pstolowski> ogra_, i've been waiting much much longer already
  <ogra_> hmm
  <ogra_> mvo, i was actually wobndering if we should rip out the hardcoded DHCP default for eth0 that we add during build
  <ogra_> at least for physical images (probably cloud still needs it)
  <zyga-ubuntu> mvo: I'll be away from home for at least three hours, after that I can spend any time debugging and exploring this with hands on
  <zyga-ubuntu> mvo: I'll try to focus on coding but I can help pstolowski with gdb
  <mvo> zyga-ubuntu: thanks, I think we are good for now, if pstolowski can reproduce that is good enough for now
  <pstolowski> ok, i reflashed and this time it didn't hang on boot. weird.
  <zyga-ubuntu> pstolowski: does the uboot env CLI tool fail the same way?
   * zyga-ubuntu logs into ubuntu session, brb
  <pstolowski> zyga-ubuntu, not yet, the test is running
  <zyga-ubuntu> aha
   * zyga-ubuntu joins the standup
  <mup> PR snapcraft#1615 closed: schema: improve invalid app, hook, and part errors <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1615>
  <jamespage> sergiusens: hi - raised https://bugs.launchpad.net/snapcraft/+bug/1723945 based on the conversation we had last week
  <mup> Bug #1723945: provide support for use of DEB_HOST_MULTIARCH in environment variables <Snapcraft:New> <https://launchpad.net/bugs/1723945>
  <jamespage> does that sounds about right?
  <mup> Issue snapcraft#1445 closed: ROS user oriented story <docs> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1445>
  <mup> Issue snapcraft#1446 closed: MOOS user oriented story <docs> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1446>
  <mup> PR snapcraft#1577 closed: lxd: don't inject local snaps on a different arch <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1577>
  <mup> PR snapcraft#1610 closed: tests: reenable the cleanbuild integration test <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1610>
  <mup> PR snapcraft#1609 closed: tests: remove the duplicate nodejs integration tests <bug> <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1609>
  <sergiusens> jamespage yeah, that should cover it
  <jamespage> sergiusens: also what would you think of https://bugs.launchpad.net/snapcraft/+bug/1723957
  <mup> Bug #1723957: cleanbuild: add PPA sources <Snapcraft:New> <https://launchpad.net/bugs/1723957>
  <jamespage> I'm using cleanbuild to produce test binaries; currently hacking in my ppa sources using cloud-init in lxd user.user-data config
  <diddledan> I don't understand this behaviour at all: https://forum.snapcraft.io/t/cleanbuild-remote-on-pi-grabs-wrong-arch-lxc-image/691/17
  <diddledan> cleanbuild should not be forcing the version of snapd to anything EXCEPT "the latest" stable, unless the user specifically tells snapcraft otherwise
  <diddledan> and doing the forcing by injecting host-side snaps is just plain wrong
  <diddledan> IMO
  <diddledan> and no, that opinion is not humble in any way :-p
  <mvo> pstolowski: how is that test going? the second run of the core-refresh testing?
  <kalikiana> diddledan: snapd? do you mean the core snap? snapcraft attempts to install the same version in the container that's being used on the host
  <pstolowski> mvo, well..
  <diddledan> yeah, core
  <pstolowski> mvo, http://pastebin.ubuntu.com/25753195/
  <kalikiana> diddledan: so if eg. you're using beta on the host to test something, the container will be using that, same goes for snapcraft itself
  <pstolowski> mvo, last failure unrelated, probably wifi dropped or something
  <diddledan> I think it's wrong to be injecting at all, foreign arch or not. Core should be updated using snap processes not by injecting random snaps. We should not be designing weird behaviour for the edge case of "I want to test something" by default
  <diddledan> an "I want to test something" should be an opt-in not a default
  <mvo> pstolowski: do you have a monitor attached, i.e. can you actually see what is on screen when its in this "2017-10-16 15:41:20 Error debugging external:ubuntu-core-16-arm-32:tests/main/ubuntu-core-upgrade : EOF" state?
  <diddledan> the whole point of cleanbuild is that the build is in a clean environment. The moment you start injecting stuff to match the host it is no-longer "clean"
  <kalikiana> diddledan: I wouldn't agree it's "random". If you're using snapcraft natively without a container, it uses whatever core you are running. The experience should as much as possible be the same
  <kalikiana> You should of course be testing that your snap works with stable before you release it, in both cases
  <pstolowski> mvo, no, no monitor (but i've usb-serial). but hmm.. i cannot access this pi3 via wifi anymore
  <diddledan> maybe if you think we should be doing this, the name "cleanbuild" is wrong. So let's rename it to "meh, frankenstein, YMMV"
  <pstolowski> mvo, if serial console doesn't lie, then the last thing that happened was systemd[1]: Started Journal Service
  <mvo> pstolowski: hm, that looks harmless
  <mvo> pstolowski: I wonder why it stops responding
  <mvo> pstolowski: fwiw, cachio saw some of these errors too (EOF) but we never got to the bottom of it, might actually be multiple causes just showing the same error
  <pstolowski> mvo, wifi seems dead, no led blinking
  <diddledan> and let's change the documentation to say "this is not a clean environment. any attempt to get a system as close to build service is never going to work. We made it this way on purpose because we hate consistency"
  <kalikiana> diddledan: Can we take a step back and you tell me what your expectation of cleanbuild is? If this is your impression that's certainly not what anyone wants :-)
  <pstolowski> mvo, I just powered it again; on normal boot that Systemd Journal Service message is followed by brcmf initialization, which apparently didn't happen
  <diddledan> my expectation is that cleanbuild builds in a clean environment. Is it wrong to assume that when the documentation says "cleanbuild       Create a snap using a clean environment..." that it will build using a clean environment?
  <mvo> pstolowski: hm, do you think you could put it on a cable connection? to make tests more reliable?
  <pstolowski> mvo, yeah, that might be a good idea
  <diddledan> also, when the documentation says "Create a snap using a pristine environment managed by lxd" I expect the environment to be unaltered
  <diddledan> I certainly do NOT expect for implementation in my host to "leak" through into the LXD container
  <kalikiana> diddledan: So even if you're doing, say, `snap install core --edge`, you wouldn't want the container to use the same channel?
  <diddledan> no
  <kalikiana> diddledan: Would you apply the same reasoning to persistent containers?
  <diddledan> if I did that then I would want a switch to tell snapcraft to change to using a different channel
  <diddledan> yes, I would
  <kalikiana> diddledan: One thing we could look into is a prompt like `You're using the "core" snap from the "edge" channel. Do you want to use  the same in the container?`
  <diddledan> most people building snaps are NOT going to want to change the core snap to test things because they're not developing the core snap nor snapd nor snapcraft
  <diddledan> if they really need to test their snap builds against a different core then they will know that they want a specific core and should then be tasked with telling snapcraft that specifically
  <kalikiana> diddledan: Right. We have slightly different perspectives here. To my mind, the same core snap increases predictability. But I see the point you're making
  <kalikiana> diddledan: Would you mind opening a new forum topic for it?
  <diddledan> the problem that you wrote the PR in the link above with core being injected to foreign arch snaps is a symptom, not the cause. the cause is that we're assuming the user wants to match their host with their build. Now your PR says "match the host EXCEPT on remote builds." where are these exceptions going to end? why not just allow the user to specify the core they want to use rather than guessing
  <kalikiana> diddledan: The PR applies to both the core and snapcraft. We have to do this anyway to be able to get the correct snapcraft version.
  <kalikiana> If we decide to not push the core snap out of the box, that's a separate decision
  <kalikiana> Or maybe add a way to choose the channel explicitly etc.
  <kalikiana> diddledan: To be clear, we have to push snapcraft because it's calling itself.
  <diddledan> kalikiana: https://forum.snapcraft.io/t/dont-match-the-core-snap-to-the-host-in-cleanbuild-environments/2486
  <kalikiana> diddledan: Thanks!
  <kalikiana> Will reply in a bit
  <diddledan> np
  <sergiusens> kalikiana just ensure it always comes from the stable channel
  <kalikiana> sergiusens: Yeah, that we can do. To be clear, though, we still want snapcraft itself to be injected from the host or same channel, right?
  <mup> Bug #1723974 opened: snap client doesn't work with Croatian language/characters <Snappy:New> <https://launchpad.net/bugs/1723974>
  <diddledan> kalikiana: I must apologise if I may have seemed aggressive above, I was just frustrated at my inability to articulate why I felt cleanbuild was behaving wonky
  <diddledan> group hug!
  <diddledan> :-p
   * kalikiana hugs diddledan 
  <diddledan> yey
  <diddledan> for anyone who doesn't like hugs, as punishment I shall not hug you! :-D
  <sergiusens> kalikiana for persistent containers, most likely yes, for cleanbuild, only if it is in stable
  <kalikiana> Good point. Will think about how we can do that
  <pstolowski> mvo, 5 runs of pi3 ubuntu-core-upgrade test passed when on ethernet
  <ogra_> heh
  <ogra_> yay ?
  <mvo> pstolowski: interessting. so lets compare notes with cachio when he is back tomorrow and see what the differences are
  <mvo> pstolowski: thanks a lot for your test!
  <ogra_> this is starting to get curious ...
  <mvo> pstolowski: that gives me some peace of mind. this was an image produced with all bits from beta, right?
  <mvo> ogra_: to me it already was last week :) but yeah, it is very inconclusive
  <ogra_> did you bump the gadget in beta ?
  <ogra_> we should really do that
  <pstolowski> mvo, sudo ubuntu-image -c beta -O pi3-beta.img pi3.model, that's how I created it
  <mvo> pstolowski: great
  <mvo> pstolowski: lets see what sergio did - maybe it makes a difference if it was created without sudo or something else, also the revision of ubuntu-image. I'm sure we can now track it down better
  <pstolowski> ogra_, ethernet may have nothing to do here, it was just a re-test for yet another failure I pasted above where on the last run I lost access to my pi3 over wifi
  <mvo> ogra_: I did not touch the gadget
  <mvo> ogra_: I would like to wait until we solved this mystery, lets cange as little as possible
  <ogra_> mvo, well, then it is interesting that this kernel boots at all, since the dtb will be incomplete
  <ogra_> (i assume half the devices you have with the edge gadget wont simply be there or only half working)
  <mvo> ogra_: yeah, I think that is an interessting datapoint as well, the old dtb seems to be fine with most new kernels
  <ogra_> well
  <ogra_> the unstable wifi behavoiur might already be an indicator here
  <ogra_> (we only added the fully fixed wifi stuff after stable got released)
  <ogra_> it is like a lottery :)
  <mvo> ogra_: yeah, not saying its great, but interessting how uch apparently worked
  <ogra_> yeah
  <mvo> ogra_: yeah, maybe that is the answer, sergio just draw the short straw
  <ogra_> yep
  <mup> PR snapd#4049 opened: debian,vendor: import github.com/snapcore/squashfs and use <Created by mvo5> <https://github.com/snapcore/snapd/pull/4049>
  <kyrofa> sergiusens, kalikiana, elopio: someone _banned_ me. Who hates me today?
  <kyrofa> I can't rejoin :P
  <ogra_> have you been rude ?
  <ogra_> :)
  <elopio> kyrofa: sorry
  <kyrofa> ogra_, sometimes it slips
  <ogra_> haha
  <kyrofa> elopio, hahaha, was it you? Fess up
  <Chipaca> nice, we have a bug in the croatian translation that causes snap to panic
  <Chipaca> that's #1723974
  <mup> Bug #1723974: snap client doesn't work with Croatian language/characters <Snappy:Confirmed> <https://launchpad.net/bugs/1723974>
  <Chipaca> also: âPokuÅ¡ajte "snap install hello-world".â
  <ogra_> i guess re-exec should better use C.UTF-8 ;)
  <zyga-ubuntu> re
  <Chipaca> mvo: do you know who I need to pester to fix a buggy translation?
  <sergiusens> elopio can we make that timing thing the default on tests or is that something you did manually?
  <kalikiana> this was a looong meeting :-D I need food now to re-ful
  <elopio> sergiusens: I added a timer in setup and teardown. It makes things verbose, and only the outliers are useful. As a second step after fixing the outliers, I was thinking to add a max time, and fail the tests that cross that line.
  <elopio> but if you want, I can get it printed in travis.
  <elopio> kyrofa: the ros unit tests should not connect to the server, right? https://launchpadlibrarian.net/341066726/buildlog_ubuntu-artful-amd64.snapcraft_2.34-201710161334-d0be68b~ubuntu17.10.1_BUILDING.txt.gz
  <kyrofa> elopio, huh, looks like it is
   * kyrofa looks
  <kyrofa> elopio, indeed, it seems that it is
  <kyrofa> But it shouldn't be...
  <kyrofa> Oh oh, wrong test
  <kyrofa> elopio, fixing now
  <mup> PR snapd#4050 opened: cmd/snap: tell translators about arg names and descs req's <Created by chipaca> <https://github.com/snapcore/snapd/pull/4050>
  <mark__> Hey guys, could you help me out making a snap? https://askubuntu.com/questions/965455/how-do-i-create-an-opengles2-and-glfw3-snap
  <mup> PR snapcraft#1614 closed: apt repo: allow insecure repos <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1614>
  <Chipaca> mark__: hello
  <mark__> hi
  <Chipaca> mark__: I think the most effective way forward for you will be to ask in the forum
  <mark__> I did
  <Chipaca> mark__: ah! ok then you're set :-)
  <mark__> Thanks.
  <kyrofa> elopio, fixed
  <elopio> thank you!
  <Chipaca> mark__: about your other issue though
  <Chipaca> mark__: what distro are you on?
  <mark__> lubuntu
  <sergiusens> elopio I am not so confident about killing tests that take too long. It is an extra burden and in practice doesn't work really well (considering that we already get our runners killed for long running test executions anyways)
  <Chipaca> mark__: what's the output of `which stopwatch`?
  <Chipaca> mark__: which -a stopwatch, even
  <mark__> of both commands
  <mark__> the output is "/snap/bin/stopwatch"
  <Chipaca> mark__: and if you run stopwatch, it complains about /usr/local/bin/stopwatch?
  <mark__> Actually it's fixed now. I don't know, maybe because after the question I make a new snap and installed/removed it multiple times.
  <Chipaca> mark__: did you used to have it in /usr/local ?
  <mark__> So now" snap run stopwatch" and "stopwatch" produce the same results
   * Chipaca mangles the english language for fun & profit
  <Chipaca> mark__: that error looks like at some point you had a /usr/local/bin/stopwatch, and bash cached it
  <mark__> yeah, I had it installed manually before
  <mark__> using custom install.sh and uninstall.sh scripts
  <Chipaca> mark__: for what it's worth, when that happens, bash has a builtini "hash" that lets you tweak that cache
  <Chipaca> hash -r, if memory serves, updated the entries in it
  <Chipaca> or maybe it reset it
  <Chipaca> one of those :-)
  <mark__> oh, so that's solved then...
  <mark__> thanks
  <Chipaca> no problem
  <Chipaca> glad it was that :-)
  <mark__> I still can't load the graphics drivers though :(
  <Chipaca> mark__: yep, that's something else (and you'll need a snapcrafter for it i reckon)
  <elopio> kyrofa: wait, that test hasn't landed in master?
  <Chipaca> mark__: have you looked at one of the sample snaps that use opengl?
  <Chipaca> mark__: (no idea, just trying to help)
  <kyrofa> elopio, ah, yes indeed it has
  <kyrofa> elopio, I can propose a quick PR to fix it rather than putting it in the ament PR if you like
  <kyrofa> It's two lines
  <kyrofa> I suppose autopkgtest is barfing on it huh
  <elopio> kyrofa: is the PPA recipe. I'd appreciate if you make the PR, so I can move on with the PPA.
  <kyrofa> elopio, easy peasy. Two seconds
  <mup> PR snapcraft#1619 opened: tests: don't hit internet in ros2 units <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1619>
  <kyrofa> elopio, there you are ^^
   * sergiusens commutes to a location with something to eat lunch
   * zyga-ubuntu rests after a long day
  <mup> PR snapcraft#1620 opened: plugins: build-attributes is already in the state <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1620>
  <diddledan> popey: can you review https://github.com/snapcrafters/corebird/pull/13 for me please? :-)
  <mup> PR snapcrafters/corebird#13: add wayland support for artful (17.10) <Created by diddledan> <https://github.com/snapcrafters/corebird/pull/13>
  <mup> PR snapcraft#1621 opened: integration tests: skip catkin test on non-xenial <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1621>
  <kyrofa> elopio, take a look at that ^^ one when you get a sec as well
  <kyrofa> Hey elopio, I have another thought for our tests. What if we had a Docker container pre-configured with all our dependencies. That would save a lot of setup time, wouldn't it?
  <kyrofa> I mean, the static tests that take a few seconds on my machine take over 5 minutes in travis
  <gouchi> hi
  <gouchi> I was wondering why we have to connect manually some interfaces with snap connect xxxx:home for example ?
  <gouchi> why it is not done automatically ?
  <kalikiana> gouchi: some interfaces don't autoconnect for security reasons. Have a look at this wiki https://github.com/snapcore/snapd/wiki/Interfaces
  <gouchi> kalikiana: thank you
  <mup> PR snapcraft#1620 closed: plugins: build-attributes is already in the state <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1620>
  <Arthur_D> hi, noob question: how does Snapcraft interact with Github - if I give it access to my Github account, will it edit anything regarding the repo or Github presentation? For example create some sort of link to the Snap on the Snapcraft website
  <sergiusens> Arthur_D it shouldn't, the scope is a bit broad, but it is I think the no brainer one that allows webhooks
  <sergiusens> instructions on manually hooking it all up are being worked on to avoid this scenario, it would however require more manual interaction and setup
  <Arthur_D> the reason I ask is because I contribute a bit to a project but don't want to create some sort of official or official looking snap, mainly wanted to test
  <mup> PR snapcraft#1619 closed: tests: don't hit internet in ros2 units <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1619>
  <mup> PR snapcraft#1621 closed: integration tests: skip catkin test on non-xenial <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1621>
  <mup> PR snapcraft#1622 opened: schema: sync patterns with snapd <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1622>
  #snappy 2017-10-17
  <mup> PR snapcraft#1568 closed: lxd: don't re-inject the same snaps <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1568>
  <mup> PR snapcraft#1618 closed: states: add scriptlets to build state <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1618>
  <zyga-ubuntu> o/
  <zyga-ubuntu> mvo: hey
  <zyga-ubuntu> just the man I wanted to see
  <zyga-ubuntu> mvo: https://github.com/snapcore/squashfuse/pull/1
  <mup> PR squashfuse#1: Tweak implementation of dummy go module <Created by zyga> <https://github.com/snapcore/squashfuse/pull/1>
  <mvo> hey zyga-ubuntu
  <mvo> zyga-ubuntu: hyes, thanks for this PR! did you test it, does that work? I also tried a subdir approach and go get would only checkout the actual dir, not any other dirs. if it works, that would indeed be very nice
  <mvo> zyga-ubuntu: (i was doing it the other way around, the C source in a subdir)
  <zyga-ubuntu> mvo: it go builds but I didn't test the full govendor sync with it (I'd have to change paths)
  <zyga-ubuntu> mvo: right but that failed for me
  <zyga-ubuntu> mvo: the linker part was not working
  <zyga-ubuntu> mvo: and govendor complained if nothing referenced that
  <zyga-ubuntu> mvo: now it's working locally, if you commit I will be able to sync
  <mvo> zyga-ubuntu: let me try quickly based on your branch, if it works, +100, very nice
  <zyga-ubuntu> if it doesn't work we can remove that patch from history
  <zyga-ubuntu> mvo: one sec
  <zyga-ubuntu> http://paste.ubuntu.com/25757470/
  <zyga-ubuntu> you want this in your snapd tree
  <mvo> zyga-ubuntu: oh, nice, yeah, this way around it works
  <mvo> zyga-ubuntu: \o/
  <zyga-ubuntu> I can push this into your branch
  <mvo> zyga-ubuntu: please do, I will take care of the rest, that will simply some things
  <zyga-ubuntu> just say the word
  <zyga-ubuntu> done
  <mvo> zyga-ubuntu: thanks
  <mvo> zyga-ubuntu: (I guess that was the word your were looking for ;)
   * mvo hugs zyga-ubuntu 
  <zyga-ubuntu> woot, I hope we can quickly solve this
  <zyga-ubuntu> do you want to make .6 with this feature?
  <mvo> zyga-ubuntu: no more 2.28 :) it will be part of 2.29
  <mvo> zyga-ubuntu: unless regression of course, then there will be a .6
  <zyga-ubuntu> hmmmm
  <zyga-ubuntu> Obtaining dependencies
  <zyga-ubuntu> Found unused ./vendor packages:
  <zyga-ubuntu>  vu github.com/snapcore/squashfuse
  <zyga-ubuntu> Please fix via 'govendor remove +unused'
  <zyga-ubuntu> darn, govendor is too picky
  <zyga-ubuntu> why doesn't it see the test reference?
  <zyga-ubuntu> is govendor really syncing sudirectories or nothing?
  <mvo> zyga-ubuntu: hm, it is not complaining here, strange
  <zyga-ubuntu> let me reset my tree
  <zyga-ubuntu> it didn't complain when I had the tree in $GOPATH
  <zyga-ubuntu> but now it does
  <mvo> now I just need to make autogen.sh work in squashfuse
  <zyga-ubuntu> darn govendor
  <zyga-ubuntu> maybe we can just make get-deps.sh not fail on that?
  <mvo> zyga-ubuntu: I removed everyting squashfuse from my GOPATH and ran tests again, no error
   * zyga-ubuntu thinks
  <zyga-ubuntu> well
  <zyga-ubuntu> if it works in the build I'll be happy
  <zyga-ubuntu> mvo: and you want to twaek autogen for local development?
  <zyga-ubuntu> mvo: I'm building the package now
  <mvo> zyga-ubuntu: it complains for me about SQ_WANT_HIGHLEVEL missing
  <mvo> eh, "does not appear in AM_CONDITIONAL"
  <mvo> (not missing)
  <zyga-ubuntu> mvo: the beauty of autohell
  <mvo> zyga-ubuntu: did this work for you?
  <zyga-ubuntu> yes
  <zyga-ubuntu> but something odd is going on
  <mvo> zyga-ubuntu: I'm on artful, maybe because of that?
  <zyga-ubuntu> mvo: I just saw your dummy-{gcc,ld} output
  <zyga-ubuntu> something must be cached somewhere
  <zyga-ubuntu> ah
  <zyga-ubuntu> man, we didn't change the hash in vendor.json
  <mvo> zyga-ubuntu: git pull
  <zyga-ubuntu> I'm on artful too
  <zyga-ubuntu> k
  <mvo> zyga-ubuntu: that will update the vendor.json
  <zyga-ubuntu> got that now
  <zyga-ubuntu> fatal: Could not parse object 'f066269fbbcd0ec6232cdffbc0fe48c7e2f7ad97'.
  <mvo> woah
  <zyga-ubuntu> # cd /home/zyga/go/.cache/govendor/github.com/snapcore/squashfuse; git reset --hard f066269fbbcd0ec6232cdffbc0fe48c7e2f7ad97
  <mvo> thats strange I just did "govendor fetch github.com/snapcore/squashfuse"
  <zyga-ubuntu> I'll kill that cache
  <zyga-ubuntu> now it worked
  <zyga-ubuntu> weird
  <zyga-ubuntu> maybe the cache was confused by my operations on the local tree earlier (I squashed/amended)
  <zyga-ubuntu> building in progress
  <mvo> zyga-ubuntu: yeah, just double checked, the hash i nthe vendor.json matches the git repo
  <zyga-ubuntu> it failed on three automake things now
  <zyga-ubuntu> Makefile.am:6: error: MAKE_EXPORT does not appear in AM_CONDITIONAL
  <zyga-ubuntu> Makefile.am:36: error: SQ_WANT_HIGHLEVEL does not appear in AM_CONDITIONAL
  <zyga-ubuntu> Makefile.am:48: error: SQ_WANT_LOWLEVEL does not appear in AM_CONDITIONAL
  <zyga-ubuntu> I think we are now in sync
  <mvo> yes
  <mvo> same that i get
  <zyga-ubuntu> brb, daughther goes to school
  <zyga-ubuntu> re
  <zyga-ubuntu> sorry, kids as usual :)
  <zyga-ubuntu> mvo: are you patching those?
  <zyga-ubuntu> I just started
  <mvo> zyga-ubuntu: hi, looks like issue #12 for squashfuse discusses the issue we are seeing
  <mup> PR #12: Bugfix/lp1480248 test reenable <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/12>
  <zyga-ubuntu> mvo: looking
  <mvo> zyga-ubuntu: I patched them but got stuck right after that :/
  <zyga-ubuntu> hehe, look who reported it
  <zyga-ubuntu> mvo: how does it build in the archive? maybe there's a patch
  <mvo> zyga-ubuntu: aha, good idea
  <mvo> zyga-ubuntu: fwiw, feel free to attach your patch :)
  <zyga-ubuntu> mvo: I don't have anything yet, just reading the configure script now
  <mvo> zyga-ubuntu: mehhhh
  <zyga-ubuntu> mvo: I find it sad/silly that a half a dozen C file project is so hard to build
  <zyga-ubuntu> wat?
  <mvo> zyga-ubuntu: the m4 subdir is missing I think
  <zyga-ubuntu> I see it here
  <zyga-ubuntu> missing as in not copied somewhere?
  <mvo> zyga-ubuntu: thats govendor again, its really annyoing about subdirs
  <zyga-ubuntu> ah
  <mvo> zyga-ubuntu: rm -rf the squashfs and get it again
  <zyga-ubuntu> mv dummy m4/
  <mvo> zyga-ubuntu: and then check the dir
  <zyga-ubuntu> ah, right, I was looking at the full git tree
  <zyga-ubuntu> did you get
  <zyga-ubuntu> extract.c:51:17: warning: implicit declaration of function âsqfs_makedevâ; did you mean âsqfs_modeâ? [-Wimplicit-function-declaration]
  <mvo> zyga-ubuntu: I wonder how to overcome the m4 subdir problem
  <zyga-ubuntu> mvo: mv dummy m4/dummy
  <zyga-ubuntu> done
  <zyga-ubuntu> we'll get the full set
  <zyga-ubuntu> (silly but, well it should work)
  <mvo> zyga-ubuntu: heh, smart
  <zyga-ubuntu> mvo: I'd say sad but I think we are in agreement :)
   * mvo hugs zyga-ubuntu again
  <zyga-ubuntu> mvo: I'll try something entirely different to see how crazy that would be
  <mvo> zyga-ubuntu: I update the trees for your approach in the meantime
  <zyga-ubuntu> ok
  <zyga-ubuntu> mvo: note that squashfuse uses a library now
  <zyga-ubuntu> mvo: where will we keep it?
  <zyga-ubuntu> mvo: it seems we need to link that statically
  <mvo> zyga-ubuntu: yes, we need to link statically
  <zyga-ubuntu> mvo: note, just the library, the rest can be dynamic
  <zyga-ubuntu> (to avoid hair-pulling in other distros0
  <mvo> zyga-ubuntu: hm, adding github.com/snapcore/squashfuse/ does no longer work for me without go files in it, it is just silently ignored
  <zyga-ubuntu> mvo: take a break from this problem for two hours please
  <zyga-ubuntu> mvo: if my approach fails we can go back to adding more hackery
  <mvo> zyga-ubuntu: ok
  <zyga-ubuntu> mvo: how are we calling the binary? snapfuse?
  <mvo> zyga-ubuntu: yes
  <mvo> zyga-ubuntu: https://github.com/snapcore/snapd/pull/4049/commits/bff17ef731ea8e2bc88a1ab2066b33a2bc8c0e31#diff-42c07ec7ffa970857b4e0db2614e482bR428
  <mup> PR #4049: debian,vendor: import github.com/snapcore/squashfs and use <Created by mvo5> <https://github.com/snapcore/snapd/pull/4049>
  <zyga-ubuntu> thank you!
  <knurd> Lo. Is it still possible somehow to set up your own snap store and configure snap to use it? Looks like https://github.com/noise/snapstore/ stopped working a while ago and was abandoned recently.
  <knurd> I already asked on https://plus.google.com/+ThorstenLeemhuis/posts/HyHfxaFQWz2 but got no reply
  <zyga-ubuntu> knurd: please look at forum.snapcraft.io, this has been extensively discussed there under the topic "extenral repositories"
  <knurd> zyga-ubuntu: thx for the pointer!
  <zyga-ubuntu> wa
  <zyga-ubuntu> mvo: almost there, I think
  <mwhudson> zyga-ubuntu: btw i poked at 2.28.5 in debian, i didn't do the dependency updates though
  <mwhudson> i should push what i have to alioth i guess
  <mwhudson> vendor.json diffs are hard to read :(
  <mvo> fwiw 4047 needs a second review
  <zyga-ubuntu> mwhudson: ack
  <zyga-ubuntu> mwhudson: I'll have a look, I cannot promise anything soon though (I need to trim my PR list)
  <mwhudson> yeah. o
  <mwhudson> bah
  <mwhudson> yeah, i'll try to poke at it over the next couple of days too
  <zyga-ubuntu> mvo: http://pastebin.ubuntu.com/25757771/
  <zyga-ubuntu> mvo: integrated into our build system
  <mvo> zyga-ubuntu: nice, I wonder if libfuse is installed by default
  <mvo> and 4028 (easy) needs a second review
  <mvo> zyga-ubuntu: curious what you did and how you overcame the m4 subdir issue
  <zyga-ubuntu> mvo: I can link that statically
  <mvo> zyga-ubuntu: I think we just need to check in the lxd base image
  <zyga-ubuntu> mvo: I just integrated that into our build, the whole set of m4 macros is needed for things we don't need
  <zyga-ubuntu> we can also drop code like non xz compression and windows support files
  <mvo> zyga-ubuntu: *nod*
  <zyga-ubuntu> mvo: shall I review 4028? :D
  <mvo> zyga-ubuntu: ;) I was hoping pstolowski or chipaca might have a look
  <zyga-ubuntu> mvo: I tweaked the build system to simplify what we need, I'll run a spread test if that works
  <zyga-ubuntu> mvo: I'll push this for reference but I want to re-do it so that we can import git history
  <zyga-ubuntu> mvo: we might be able to pull in fixes from squashfuse upstream this way
  <zyga-ubuntu> mvo: so far so good though
  <pstolowski> approved
  <zyga-ubuntu> mvo: we can also go through the code and simplify windows bits out
  <zyga-ubuntu> mvo: builds are ok, testing in spread
  <zyga-ubuntu> mvo: once this works I'll ask you to review and then let's see what to do about history, ok?
  <mvo> ok
  <zyga-ubuntu> mvo: https://github.com/zyga/snapd/tree/rfc/integrated-squashfuse
  <zyga-ubuntu> this is the code
  <zyga-ubuntu> mvo: and this is the new part essentially: https://github.com/zyga/snapd/commit/3545b115cb90e702779c43703f70db9e01b10cff
  <zyga-ubuntu> mvo: lxd test now running
  <zyga-ubuntu> fingers crossed
  <zyga-ubuntu> doh :)
  <zyga-ubuntu> silly mistake
  <zyga-ubuntu> fixed now, re-running tests
  <zyga-ubuntu> I didn't enable XZ
  <Chipaca> moin
  <zyga-ubuntu> Chipaca: hey
  <zyga-ubuntu> mvo: it works now, I think I need to expand this to cover more packaging
  <mvo> zyga-ubuntu: just cherry pick my bits from https://github.com/snapcore/snapd/pull/4030
  <mup> PR #4030: many: add internal squashfuse copy as "snapfuse" <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4030>
  <zyga-ubuntu> mvo: aha, thank you
  <mvo> zyga-ubuntu: I will revert 4049 back to the original state, lets see what niemeyer thinks about the two approaches as they have boths pros/cons
  <Tazmania> Hello, I have a Dell atom based mini PC came pre-installed with Ubuntu Core 16.  I would like to know if it is possible to install cmake and domoticz packages on it?  I am a newbie to Snappy, please pardon me.
  <mvo> zyga-ubuntu: but maybe/probably the govendor approach is doomed as it cannot statically link selectively via configure
  <zyga-ubuntu> mvo: fingers croessed
  <zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/4051
  <mup> PR #4051: many: add integrated snapfuse <Created by zyga> <https://github.com/snapcore/snapd/pull/4051>
  <mup> PR snapd#4051 opened: many: add integrated snapfuse <Created by zyga> <https://github.com/snapcore/snapd/pull/4051>
  <zyga-ubuntu> mvo: I'll break for shower/coffee as I'm still in my pijamas today
  <mvo> Tazmania: if you want to develop its probably easiest if you "snap install classic; classic"
  <mvo> Tazmania: eh, "sudo snap install --devmode --beta classic" that is
  <mvo> zyga-ubuntu: heh, thank you!
  <zyga-ubuntu> Tazmania: and please look at forum.snapcraft.io, lots of friendly people there and lots of questions answered already
  <Tazmania> What's the difference between classic and the pre-installed?
  <Tazmania> zyga-ubuntu: thanks. I will check the forum
  <mvo> zyga-ubuntu: did you add a patch to fix the sqfs_makedev() error ?
  <zyga-ubuntu> mvo: compare diffstat in 4030 and 4051
  <zyga-ubuntu> automake is crazy
  <zyga-ubuntu> mvo: hmmmmm, I don't think I did
  <mvo> Tazmania: classic is a environment that makes it easy to develop using the classic tools
  <Tazmania> mvo: thanks
  <zyga-ubuntu> mvo: have a look at my branch please, let's see what we can cut from snapfuse/*.[ch]
  <mvo> zyga-ubuntu: interessting, I get a warning that is turned into an error here
  <zyga-ubuntu> mvo: hmm, spread passed for me, hmmm
  <mvo> zyga-ubuntu: cool
  <zyga-ubuntu> maybe I did but I didn't notice :)
  <zyga-ubuntu> anyway, afk for a moment
  <mvo> zyga-ubuntu: lets see what gustavo thinks, I personally would like to make snapfuse as much "imported" as possible and ideally not modify it but I see the advantages so lets see how gustavo feels about what approach should be taken
  <mvo> zyga-ubuntu: see you
  <zyga-ubuntu> mvo: shall we prepare an alt version that has working imported approach?
  <zyga-ubuntu> mvo: I mean, it might be even this code, we could just depend on a script that gets the debian .orig tarball
  <zyga-ubuntu> mvo: (via get-deps)
  <popey> diddledan: sorry for the delay, testing your corebird snap
  <mvo> zyga-ubuntu: lets talk after you had your shower, I'm not sure myself.
  <zyga-ubuntu> I'm back already
  <zyga-ubuntu> mvo: ok, I'll look at failing tests in one of my PRs and let's wait to see if 4051 is green
  <mvo> zyga-ubuntu: for when you are back - do you happen to know why none of our tests caught the typo https://github.com/snapcore/snapd/pull/3617/files#diff-ec8cacef522dbb27eeb9ceed25f03b22R249 ? I mean, we have a integration test for network-control, why does that not fail on invalid content? can we add that?
  <mup> PR #3617: interfaces/builtin: use udev tagging more broadly <Created by adglkh> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3617>
  <zyga-ubuntu> mvo: looking
  <zyga-ubuntu> aha, that typo
  <zyga-ubuntu> let me think
  <mvo> zyga-ubuntu: I'm breaking it on purpose now and run the spread test to see if our checks are insufficient
  <mvo> zyga-ubuntu: does udev not error when we write incorrect files?
  <zyga-ubuntu> mvo: are those tests checking tun devices?
  <zyga-ubuntu> mvo: I think the file was parsing OK, just not doing what we wanted
  <mvo> zyga-ubuntu: no, no checks for tun devices. hm, ok, if its valid syntax just the wrong one that is hard to test
  <zyga-ubuntu> mvo: maybe if the rules looks like `KERNEL=="foo", TAG+="...",\nKERNEL=="bar", TAG+="..."` the rule is just a no-op
  <zyga-ubuntu> mvo: as in, it will never match both "foo" and "bar"
  <mvo> zyga-ubuntu: there was an extra "," at the end of the line
  <zyga-ubuntu> I can test that theory but I need to get to the bottom of something failing in my branch first
  <mvo> (in this particular case)
  <zyga-ubuntu> mvo: right but , is a separator for udev expressions
  <mvo> zyga-ubuntu: sure, I can chase this
  <mvo> zyga-ubuntu: aha, ok
  <zyga-ubuntu> mvo: we could build a simple safeguard
  <zyga-ubuntu> mvo: add a new api to udev.Specification
  <zyga-ubuntu> mvo: that has less flexibility in it
  <zyga-ubuntu> mvo: we could then rewrite vast majority of udev rules to use that
  <zyga-ubuntu> mvo: and maybe keep {modem,network}-manager as the only uses of the more powerful, type-unchecked api
  <zyga-ubuntu> mvo: essentially there's no type checking anywhere there
  <zyga-ubuntu> mvo: we could also have a test that parses all the snippets
  <zyga-ubuntu> mvo: and ensures that some simple impossible conditions are not present
  <zyga-ubuntu> mvo: like tests that attr == "a" and attr == "b" at the same time
  <zyga-ubuntu> mvo: I did something similar-ish for apparmor rules earlier (I was fully parsing them, there's still a branch somewhere I can find)
  <mvo> zyga-ubuntu: ok, thank you. sounds all like some work
  <zyga-ubuntu> mvo: sorry, it's not apparmor, it was seccomp,
  <zyga-ubuntu> mvo: the branch starts at 87826dc09a7a43357500329032185544b53c5c91
  <zyga-ubuntu> mvo: feature/typed-syscalls in my remote
  <zyga-ubuntu> mvo: that ensures that seccomp rules are well typed
  <zyga-ubuntu> mvo: udev rules are not too sopisticated, we could do something like that too
  <zyga-ubuntu> mvo: even if it's just for testing
   * Chipaca realises the time and runs to make it to physio
  <zyga-ubuntu> Chipaca: o/
  <zyga-ubuntu> run slowly and safely man
   * zyga-ubuntu fixed his other brnach
  <mvo> pstolowski, zyga-ubuntu: related, the lxd-demo-server stopped because we had lxd as reserved for the OS, when that started to fail we changed something else, right? more strict checking in the interfaces code, does anyone remember details?
  <mvo> hey Chipaca
  <mvo> (sorry for the many questions, writing the retrospect right now)
  <zyga-ubuntu> mvo: I don't remember, let me look
  <pstolowski> mvo, there was a change recently (the week after the sprint) to that interface
  <skjensen> Hi Guys, I'm trying to build Ubuntu Core for Nvidia TX1 it's a arm64 bit system. I'm following this guide: https://wiki.ubuntu.com/ARM64/FoundationModel  but the link to download ubuntu-core-13.10-core-arm64.tar.gz is broken. I have tried to find a more recent version of the core for arm64 but without luck..
  <zyga-ubuntu> mvo: I only found 042f9d0085bf6fe0ff82345cc58804d9e21eb318
  <skjensen> Does anyone know where I can find it, if it exist?
  <zyga-ubuntu> skjensen: ubuntu-core-13.10?
  <zyga-ubuntu> ogra_: ^
  <skjensen> I would like ubuntu-core-16.04
  <zyga-ubuntu> I think that's something for you
  <mvo> pstolowski: yes, we fixed the issue in that PR a week after the sprint. I wonder what commit/PR broke it though, it was reserved for the OS since forever afaik.
  <pstolowski> zyga-ubuntu, mvo yes, that's the change I meant
  <zyga-ubuntu> mvo: I think we just never tested that combination mvo
  <zyga-ubuntu> mvo: you added a test for this later
  <zyga-ubuntu> mvo: after the brekage occurred
  <mvo> zyga-ubuntu: stgraber reported lxd-demo-server used to work and started breaking with 2.28
  <mvo> zyga-ubuntu, pstolowski ok, I chase that, thanks for your input!
  <zyga-ubuntu> skjensen: ogra is the person for that question, I think there is (or might be) a model/gadget/kernel for TX1 but I'll let him answer with authority
  <zyga-ubuntu> wow, incredible, I can actually write a new feature now
  <zyga-ubuntu> and it's 11:56
  <ogra_> skjensen, the old ubuntu-core has been enamed to "ubuntu-base", tarballs can be found at http://cdimage.ubuntu.com/ubuntu-base/
  <ogra_> *renamed
  <skjensen> Great thanks.. :) Is there one for the TX1?
  <zyga-ubuntu> mvo: I spoke too soon, the fuse stuff, no fuse on 14.04
  <zyga-ubuntu> mvo: so packaging diverges
  <zyga-ubuntu> mvo: and this is now optional
  <zyga-ubuntu> mvo: meeh
  <zyga-ubuntu> skjensen: do you want classic ubuntu headless or the new snap-based ubuntu (aka ubuntu-core nowadays)
  <ogra_> skjensen, if you want an actual snap based UbuntuCore install then you need to create a gadget snap and use ubuntu-image to build an image for it ... the jetson tk1 is supported in the llinux-generic-bbb kernel (by selecting the tegra124-jetson-tk1.dtb devicetree froom the gadget snap)
  <skjensen> I want the new snap-based ubuntu due to the new features. It's for a IoT deployment
  <ogra_> skjensen, the -base tarballs are just root filesystems just pick the arm64 one
  <zyga-ubuntu> skjensen: I'd suggest you open a forum thread about TX1 core image
  <ogra_> skjensen, aha ... https://ograblog.wordpress.com/2017/05/30/building-u-boot-gadget-snap-packages-from-source/ and https://ograblog.wordpress.com/2017/06/13/patching-u-boot-for-use-in-an-ubuntu-core-gadget-snap/ ae what you want then
  <kalikiana> clobrano: hey
  <zyga-ubuntu> skjensen: you should familiarize yourself with some snappy concepts (models, gadget snaps, kernel snaps) to make a proper set of files needed to support this
  <c-lobrano> kalikiana: hi
  <kalikiana> c-lobrano: You wanted to work on bug 1722650?
  <mup> Bug #1722650: snapcraft requires optional VERSION_ID in os-release <bitesize> <Snapcraft:Confirmed> <https://launchpad.net/bugs/1722650>
  <zyga-ubuntu> skjensen: doing that on the forum is easier and many people can participate (across timezones)
  <ogra_> skjensen, create that gadget, make it use tegra124-jetson-tk1.dtb and once you have that ping me again and we'll talk abut how you get yur own kernel build fom the linux-generic-bbb snap
  <zyga-ubuntu> ogra_: btw, do you have the TX1 or the TX2?
  <zyga-ubuntu> ogra_: are they decent machines? I was thinking about getting one simply because it has oodles of ram (for an arm board)
  <ogra_> zyga-ubuntu, nope ... i stopped after tegra2 ...
  <c-lobrano> kalikiana: yes, but before pushing a change according to what you suggested, I'd like to see what kind of file snapcraft is looking for
  <zyga-ubuntu> ogra_: aha, thank you
  <ogra_> they shoudl be in the relam of a dragonbard
  <skjensen> I got the TX1 and actually got a TK1 as well.. But we decided we needed the TX1 to run out software since it uses TensorFlow and that's not supported anymore on the TK1
  <kalikiana> c-lobrano: Do you have a local checkout of snapcraft?
  <zyga-ubuntu> mvo: shall I change the snapfuse PR now or would you rather wait for gustavo's opinion first?
  <kalikiana> c-lobrano: You can have a look at the "libraries" folder
  <c-lobrano> kalikiana: yes, I've already branched the project for a previous PR
  <c-lobrano> *forked
  <skjensen> It's a work project, so I got the next 2 months to dive into the snap universe and get a proper version up and running on the TX1. Thanks for all the help to get started on this. I will let you know how I get on.. :)
  <mvo> zyga-ubuntu: either way is fine with me
  <zyga-ubuntu> skjensen: welcome aboard, the forum has a "docs" category with useful documentation
  <skjensen> Great :)
  <zyga-ubuntu> skjensen: there's also the "device" category for topics related to making and supporting new devices
  <zyga-ubuntu> https://forum.snapcraft.io/c/device
  <zyga-ubuntu> https://forum.snapcraft.io/c/doc
  <zyga-ubuntu> https://forum.snapcraft.io/t/the-gadget-snap/696
  <ogra_> skjensen, well, start with the gadget and for easiness i'd take the tk1 first ... the gadget between the two will only differ minimally so you can re-use it for tx1 with some minimal changes ... the difference between the tw is that you will need your own kernel for the tx1 so fr a start the tk1 will be easier ...
  <zyga-ubuntu> https://forum.snapcraft.io/t/the-kernel-snap/697
  <ogra_> skjensen, just folllow the blogposts i gave yu abve, they have a step by step guide and all links to alll docs yu need
  <skjensen> ogra_ thanks, I will get started on the TK1 to get some experience.. and then move onto the TX1
  <ogra_> iirc there was also some jetson work done initially by parrot ... not sure if they put that in github though
  <kalikiana> c-lobrano: Perfect. So if you see the "libraries" folder, there's a file "16.04" in there, which if you open it contains a lot of filenames.
  <kalikiana> That's the ones that get stripped from the snap
  <c-lobrano> kalikiana: oh, I see
  <skjensen> ogra_ super, and I can guarantee you my work will go up on github for everyone to use..
  <ogra_> \o/
  <c-lobrano> kalikiana: so, if no VERSION_ID exists, there is no way to find "another equivalent" file, right?
  <kalikiana> c-lobrano: The code basically wants to know that it runs on Ubuntu 16.04 and do its thing. If VERSION_ID isn't there... it should probably be equivalent to a different version, like say 17.10, in which case there's no file
  <c-lobrano> kalikiana: perfect, so I can propose my PR
  <kalikiana> c-lobrano: Yeah. I think kyrofa made a good point there with regard to abstracting it, tho not sure it should be done in the same PR... unless you'd like to look into that as well?
  <ogra_> mvo, you might want to mention https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1724088 in the changelog for the release
  <mup> Bug #1724088: All snap packages fail to start with 'udev_enumerate_scan failed' <snapd (Ubuntu):Fix Committed> <https://launchpad.net/bugs/1724088>
  <c-lobrano> kalikiana: oh, I wasn't subscribed to the bug yet, and I missed kryofa's comment. What about doing two PR, one for the bug and one for the "new feature"?
  <mup> PR snapd#4052 opened: tests: check for invalid udev files during all tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/4052>
  <kalikiana> c-lobrano: Yeah, that's what I was thinking as well. The fix itself is straight-forward
  <c-lobrano> kalikiana: alright. I'm in the middle of ./runtest.sh unit, then I can push the PR
  <kalikiana> c-lobrano: Awesome. Thanks for working on it!
  <c-lobrano> kalikiana: yw :)
  <zyga-ubuntu> mvo: there's a typo in tihs:
  <zyga-ubuntu> 2017-10-12 Bureport from 16.04 users about udev_enumerate_scan failure not fixed until the machine is reported. This is unacceptable so we added cleanup code into snap-confine to cleanup the state that caused libudev to be erroring (releated to the udev device tagging that was incorrectly applied to nvidia devices) - PR#4042.
  <zyga-ubuntu> s/machine/machine is rebooted/
  <zyga-ubuntu> mvo: otherwise great writeup, thank you!
   * zyga-ubuntu goes to pick up his son from new school. will probably miss the standup in traffice, be back in two+ hours
  <mup> PR snapcraft#1623 opened: Removed dependency on VERSION_ID in os-release <Created by clobrano> <https://github.com/snapcore/snapcraft/pull/1623>
  <kalikiana> c-lobrano: Could you add a unit test for your fix? Probably in snapcraft/tests/test_libraries.py
  <c-lobrano> kalikiana: sure
  <zyga-ubuntu> re, waiting for son in school
  <c-lobrano> kalikiana: just let me see how to do it :)
  <niemeyer> o
  <niemeyer> o/
  <Chipaca> \o
  <sergiusens> o/
  <Chipaca> /o/
  <Chipaca> \o\
  <niemeyer> \_o_/
  <niemeyer> mvo: What's up with snapfuse? (Wondering about zyga's comment above)
  <niemeyer> (and about the new PR)
  <ogra_> first rule of the snappy yoga club ... don't talkk about the snappy yoga club
  <niemeyer> ogra_: You just broke it
  <ogra_> yeah, the evil in me ... :)
  <mvo> niemeyer: its mostly about details in how we should do it. I was trying to use "govendor fetch" to get it. however its really fighting govendor more than anything else. the alternative is to embedd it, zygas approach is to integrate it pretty close (including putting it into our make files instead of using the upstream makefiles). I was mostly curious about your suggested approach
  <mvo> ogra_: thanks for the pointer to the bug about udev_enum_failed
  <ogra_> np
  <ackk> hi, could anyone kick a CI run on https://github.com/snapcore/snapd/pull/3916? I suspect there were some infrastructure issues on the previous run
  <mup> PR #3916: snap,wrappers: add support for socket activation <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916>
  <niemeyer> mvo: What happened with govendor?  I was hopeful as well
  <mvo> niemeyer: its still there in #4049, but open issues and I had to be quite creative to make it go getable (https://github.com/snapcore/squashfuse/commit/ed6f37bbee6537e0598aa7f4f5dafa379be0c73a)
  <mup> PR #4049: debian,vendor: import github.com/snapcore/squashfs and use <Created by mvo5> <https://github.com/snapcore/snapd/pull/4049>
  <kalikiana> c-lobrano: Feel free to pester me with questions as needed :-D
  <niemeyer> mvo: Oh, I see.. so govendor will still use go get
  <mvo> niemeyer: we can further explore this, we need to link some (or all) libs for snapfuse statically to ensure we don't add other hidden dependencies
  <c-lobrano> kalikiana: :D I'll do
  <mvo> niemeyer: yes, I could not make it just fetch my git tree, it was slightly confusing as you can add things and it will not err/warn but just silently ignore it if it does not look like a go repo
  <niemeyer> Hmmm
  <mvo> niemeyer: we can talk more in the standup, zygas PR is much much closer (and conceptually easier). the downside is that we need to track upstream
  <mvo> (closer)
  <niemeyer> mvo: If all we want is to get the tree and not compile, we might just drop a Go file somewhere
   * kalikiana time for a break
  <mvo> niemeyer: that is what I did, unfortuantely once there are C files in the tree it will try to compile them (it being go)
  <niemeyer> mvo: It won't try to compile any place that you don't explicitly get
  <mvo> niemeyer: so yeah, we can make it work its just a bit more hacky and we need to solve how to  statically linki in that PR
  <niemeyer> mvo: e.g. if you create a directory and drop a println("hi") on a .go file on it, and get _that_ package path, it won't care about the rest
  <mvo> niemeyer: correct, but it will also only get that directory and leave parent dirs empty
  <niemeyer> mvo: No.. it fetches the whole repository
  <niemeyer> mvo: There's no way to tell git to fetch a subtree
  <mvo> niemeyer: you are right, this is what I see with go get too, I wonder why I had a different experience with govendor, I can try this again and understand the details
  <skjensen> ogra_ I'm trying to follow your beaglebone guide to build for the TK1, but I'm a bit unsure about the uboot.env.in file? Where did you get that from?
  <ogra_> skjensen, you start with "printenv" in the uboot shell to get the default env ... then you need the load* scripts to load the right files and all the snappy_* and snap_* vars (and scripts)
   * zyga-ubuntu is online but in super-noisy place
  <ogra_> and examples are at https://github.com/ogra1/beaglebone-gadget/blob/master/uboot.env.in ... or https://github.com/ogra1/pi3-gadget/blob/master/uboot.env.in
  <skjensen> okay, thanks..
  <ogra_> the essential bits are "loadfiles" and "snappy_boot"
  <skjensen> okay.. :)
  <c-lobrano> kalikiana: I'm using TestSystemLibsOnNewRelease as template, mocking get_os_release_info in order to return a dict without VERSION_ID, but somehow I still get the 16.04 list of .so, maybe you can spot my mistake http://paste.ubuntu.com/25759264/
  <kalikiana> c-lobrano: _get_system_libs uses a global variable. Can you try unsetting it in the setup method?
  <kalikiana> ie. `_libraries = None`
  <kalikiana> it's set and checked at the top of the _get_system_libs function
  <c-lobrano> I see, but it doesn't seem to work
  <kalikiana> you tried it like that?
  <c-lobrano> yes, with global _libraries first
  <kalikiana> c-lobrano: Hmmm maybe you can mock.pantch _libraries?
  <kalikiana> And give it .return_value = None
  <c-lobrano> kalikiana: good idea, let me try
   * c-lobrano haven't used unittest.mock much so far
  <c-lobrano> kalikiana: it was easier than expected "libraries._libraries = None"
  <kalikiana> Oh, nice
  <c-lobrano> saint StackOverflow ;D
  <c-lobrano> kalikiana: weird, can't see the PR updated
  <kalikiana> c-lobrano: I don't see it either. Did you `git push origin bug-lp1722650` the branch?
  <c-lobrano> kalikiana: I did `git push -f` actually, but I can see it on my repo
  <c-lobrano> https://github.com/snapcore/snapcraft/compare/master...clobrano:bug-lp1722650
  <kalikiana> Hmm. Even if you amended the commit it should have updated automatically
  <kalikiana> Or did you completely re-do the branch under the same name?
  <cachio_> pstolowski, mvo I have the same issue with the pi3 using 2.28.5
  <cachio_> I try to creata the image by using the deb ubuntu-image
  <pstolowski> cachio_, i've just finished preparations, about to run the test
  <mvo> cachio_: did you and pstolowski figure out in what way the test differed between you?
  <kalikiana> btw sergiusens did you want to have a one on one today? You mentioned it the other day, but I have none anymore in my calendar since you removed it last time
  <cachio_> mvo, a diff is the tool we used to create the image
  <pstolowski> mvo, i used ubuntu-image from the distro (not snap), however the version number is the same, so perhaps that's irrelevant
  <c-lobrano> kalikiana: just amended
  <kalikiana> c-lobrano: Hmm weird. It should just show up then
  <mvo> cachio_, pstolowski aha, thats very interessting
  <pstolowski> mvo, it's hard to compare the versions of other stuff, Sergio flashed his card already. this time we will generate beta images at the same time
  <mvo> pstolowski: \o/
  <Chipaca> kalikiana, sergiusens, kyrofa, who's fielding questions along the lines of "why does a snap built with this snapcraft.yaml throw these library errors"?
   * kyrofa runs
  <kyrofa> Chipaca, hit me :)
  <kalikiana> haha
   * Chipaca picks up a 15kg wrench
  <zyga-ubuntu> Chipaca: are you going to mend the computer?
  <Chipaca> kyrofa: actually i'm asking on behalf of https://forum.snapcraft.io/t/how-do-i-create-an-opengles2-and-glfw3-snap/2488
   * zyga-ubuntu is in a bus, working like it's his office
  <Chipaca> zyga-ubuntu: put pants on, man!
  <kyrofa> Chipaca, alright I'll take a look, thanks for the ping :)
  <zyga-ubuntu> Chipaca: oh my!
  <zyga-ubuntu> and I thought I just looked good
  <zyga-ubuntu> all the people staring
  <sergiusens> Chipaca the title doesn't make me feel it would be easy as the text below it makes it
  <c-lobrano> kalikiana: alright, changed commit message a bit, now github recognized the update :D
  <Chipaca> sergiusens: users gonna use
  <sergiusens> Chipaca isn't all the gl stuff supposed to be mirrored into the snap through the snapd mounts?
  <sergiusens> zyga-ubuntu ^ ?
  <Chipaca> was about to say, i think some magic is done, but ask zyga-ubuntu :-)
  <Chipaca> this might just be a "add the opengl interface" or something
   * Chipaca no sabe
  <kalikiana> c-lobrano: One note on the test data. How about using something other than Xenial where it's normal to have no VERSION_ID field?
  <kalikiana> Otherwise it's potentially confusing to someone reading the test
  <Chipaca> kalikiana: c-lobrano: you know about os-release-zoo?
  <kalikiana> Chipaca: What's that?
  <Chipaca> kalikiana: like an animal zoo, but of os-release files
  <Chipaca> kalikiana: https://github.com/zyga/os-release-zoo
  <kalikiana> Oh, neat
  <kalikiana> MAybe this one https://github.com/zyga/os-release-zoo/blob/master/elementary/elementary-0.4.txt works for this test
  <Chipaca> kalikiana: note that one is wrong
  <Chipaca> as in, it's what they shipped, but it's invalid
  <Chipaca> they have since fixed it (i think0
  <Chipaca> )
  <kalikiana> Ah, it has the invalid ID. There was even a snapcraft bug about it
  <Chipaca> :-)
   * ikey sometimes thinks os-release needs an UPDATE_MECHANISM field to properly describe the core architecture
  <Chipaca> ikey: also a SUCKS_LIKE field
  <Chipaca> IS_AT_LEAST_AS_BAD_AS=...
  <ikey> lol
  <c-lobrano> kalikiana: I think you're right. I'm not familiar with os-release-zoo
  <zyga-ubuntu> c-lobrano: hey
  <zyga-ubuntu> c-lobrano: github.com/zyga/os-release-zoo
  <pstolowski> cachio_, it failed for me with snap_mode not defined again, http://pastebin.ubuntu.com/25759787/
  <pstolowski> mvo, ^
  <c-lobrano> hey zyga-ubuntu, thank you, I'll look into it
  <pstolowski> cachio_, my versions: http://pastebin.ubuntu.com/25759794/
  <pstolowski> cachio_, how about yours?
  <cachio_> pstolowski, one min please
  <cachio_> flasing the new one
  <cachio_> pstolowski, did you use the ubuntu-image snap?
  <pstolowski> cachio_, yes
  <cachio_> pstolowski, https://paste.ubuntu.com/25759837/
  <cachio_> this is mine
  <cachio_> flashed with deb ubuntu image
  <cachio_> the only diff is the rev for the core
  <cachio_> pstolowski, I am gonna run the test now
  <elopio> sorry for not replying kyrofa, I spent too much time fixing my wifi yesterday
  <pstolowski> cachio_, why is it different?
  <ogra_> cachio_, please check if there is actually any corruption by running fw_printenv manuallly after the test, we found yesterday that this actually works and there might be just an issue how fw_printenv is used in the test or a bug in fw_printenv itself but no actual corruption of uboot.env or the vfat ...
  <kyrofa> elopio, quite alright. Things working better today?
  <elopio> kyrofa: docker will speed things, we can go back to it. However, the problem we had was that nobody is developing in docker, so it was hard to reproduce the errors.
  <elopio> also, we can't install snaps.
  <ogra_> cachio_, all manual runs of fw_printenv returned proper results yesterday even if the test failed
  <cachio_> ogra_, ok
  <kyrofa> elopio, yeah I was mostly meaning for normal units/integrations
  <kyrofa> But if there are weird failures there, yeah that would explain it
  <elopio> kyrofa: if we publish a snap before running the integration tests, there will be no deps to install.
  <kyrofa> Very true
  <kyrofa> elopio, but again: talking about unit tests and stuff
  <elopio> kyrofa: I'm not worried about unit, but I have no problem moving those to docker.
  <kyrofa> elopio, yeah I really just mean as an overall speedup step
  <pstolowski> cachio_, please paste your error if it hppens again
  <elopio> kyrofa: we still have the docker scripts around, because I didn't get a chance to move the CLA to lxc. My plan was to have everything consistent in lxc, but we can go the other way, no big arguments from me.
  <cachio_> pstolowski, it works when I flash with the deb }ubuntu-image
  <kyrofa> elopio, I have no strong feelings. We all know lxd better. I was just thinking from a speed perspective
  <cachio_> did you run the test with the image flashed with the snap ubuntu-image?
  <kyrofa> Not sure it's worth it
  <cachio_> mvo, when I use an image flashing with the deb ubuntu-image the tst pass, when I use the snap ubuntu-image the test fails
  <cachio_> mvo, interesting
  <cachio_> ogra_, also for you
  <elopio> kyrofa: would it make sense to explore having a persistent lxc container and caching it?
  <kyrofa> elopio, caching it... in lxc?
  <kyrofa> Ugh, in s3 I mean, sorry
  <kyrofa> Not awake yet
  <elopio> caching it in travis
  <kyrofa> How would that work?
  <ogra_> cachio_, hmm, has the deb even been updated sinc ethe snap exists ?
  <ogra_> also ... the deb requires you to use the foundations PPA for it to get the ext4libs version that make you not require sudo
  <ogra_> though neither should have any influence here
  <cachio_> I ran with sudo
  <kalikiana> elopio: Where would the container be created/ destroyed in that case?
  <cachio_> ogra_, is it a problem?
  <ogra_> well, it is a difference ... :)
  <mvo> cachio_: yay
  <ogra_> the version differemce might/could be a prob though
  <mvo> cachio_: that is awesome news, we have a smoking gun now
  <pstolowski> mvo, cachio_ well, it doesn't match my results
  <mvo> cachio_: I bet its the embedded mtools (or whatever vfat tools) inside the snap then
  <mvo> pstolowski: what do you get?
  <pstolowski> mvo, http://pastebin.ubuntu.com/25759787/
  <pstolowski> mvo, it's from a few moments ago, i flashed with ubuntu-image from the snap (yesterday I was using ubuntu-image from the deb)
  <ogra_> pstolowski, ubuntu-image deb or snap ? (and did you use sudo or not)
  <ogra_> aha
  <ogra_> so a smoking red herring then :P not a gun ...
  <cachio_> ogra_, I always used sudo
  <pstolowski> ogra_, yes I used sudo
  <ogra_> wwith the snap you shouldnt need to ...
  <ogra_> and with the deb, only if you dont use the PPA
  <pstolowski> ogra_, but no harm either way?
  <ogra_> theoretically not
  <ogra_> practically ... i dont know :)
  <mvo> pstolowski: well, its the EOF again, thats slightly different than the error from cachio_
  <mvo> pstolowski: still interessting and something I would love to figure out why the connection is broken
   * kalikiana going to step out for a bit, to find some food
  <pstolowski> mvo, but first and foremost, it's snap_try_core and snap_mode not defined again, right?
  <mvo> pstolowski: it will get cleared after a successful boot, so its ok if you don't see it
  <mvo> pstolowski, cachio_ I need to interrupt your testing with 2.28.5 and push 2.28.1 with a wpa fix to beta now
  <cachio_> mvo, np
  <cachio_> should I validate it now?
  <kyrofa> Yikes... using github to update branches is not working
  <kyrofa> Something is broken here
  <mvo> cachio_: yes please, once its ready, I'm uploading right now
  <kyrofa> It actually does the merge, but doesn't update the PR or tests
  <cachio_> mvo, I'll have lunch now in that case
  <mvo> cachio_: sure
  <mvo> cachio_: enjoy!
  <cachio_> mvo, and I'll create the images with the deb ubuntu-image then :)
  <mvo> cachio_: \o/
  <kyrofa> Meh. "We continue to investigate a queue backlog. You may experience that commits take longer than usual to appear in pull requests."
  <mup> PR snapcraft#1624 opened: kernel plugin: use latest stable core snap <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapcraft/pull/1624>
  <elopio> kyrofa, kalikiana: I don't know, just an idea that I would have to try. Maybe putting /var/snap/lxd in the cache, or something like that.
  <kyrofa> elopio, wait... I thought the cache required s3?
  <kyrofa> Maybe I'm mixing wires with other conversations we've had
  <elopio> kyrofa: you are talking about sharing files between stages. For that, they recommend not to use the cache, and use something external.
  <kyrofa> elopio, oh interesting. Wouldn't that be what we're doing if we cache lxd, though?
  <elopio> we want to share the snap between stages, it might be worth asking why they are recommending that.
  <elopio> yes. They also recommend not to cache images :)
  <elopio> but if there is no good reason, we can just ignore the recommendation.
  <kyrofa> Huh
  <ogra_> ppisati, sergiusens ... what is this ? https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/kernel.py#L456 ... why was the kernel plugin not switched to download core ?
  <ogra_> (ubuntu-core has not been built since severeal months, all initrd scripts in there are definitely massively outdated)
  <mvo> cachio_: new beta core ready for testing, this is a cve fix, so feel free to bump to candidate as soon as we get ok from CE and we should also push to stable as QA allows
  <abeato> ppisati, sergiusens FTR: https://github.com/snapcore/snapcraft/pull/1624
  <mup> PR snapcraft#1624: kernel plugin: use latest stable core snap <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapcraft/pull/1624>
  <cwayne> mvo: cert tests are under way, we'll keep an eye out and let you know as soon as they're ready
  <mvo> cwayne: \o/
  <mvo> cwayne: thank you, this is very important so I appreciate it
  <ppisati> ogra_: i don't know, maybe when the rename 's/ubuntu-core/core/' was done they forget to check every plugin?
  <ogra_> heh, well, kernel is the only plugin that downloads core ...
  <ogra_> i dont get how we didnt notice this though
  <ogra_> doesnt it print "downloading ubuntu-core" somewhere when it does that ?
  <ppisati> uhm
  <ogra_> it snt *that* bad given that all official kernel snaps re-pack the deb anyway ... but people building their own kernels miss the last fixes in the initrd scripts
  <kalikiana> elopio: Do you know if I can mock.patch for an entire module? I'm trying to patch check_open which is used in different files - and I don't want to have several mocks for all of them
  <elopio> kalikiana: yes, just use the path to the module they are all importing
  <kalikiana> elopio: That's what I tried... it's telling me the functions don't exist
  <kalikiana> elopio: This is how I'm specifying it `snapcraft.internal.lxd.sleep`
  <kalikiana> lxd is the folder containing __init__.py
  <elopio> kalikiana: are you importing snapcraft.internal.lxd in the test file?
  <kalikiana> elopio: No
  <kalikiana> elopio: even with that, I'm getting `AttributeError: <module 'snapcraft.internal.lxd' from '~/bau/snapcraft/snapcraft/internal/lxd/__init__.py'> does not have the attribute 'check_call'`
  <kalikiana> It seems to be looking in __init__.py, not inside the module where it's being used
  <kalikiana> elopio: I'm guessing I'd have to import those functions in __init__.py then, rather than the individual files
  <cachio_> cwayne, are you already testing 2.28.5 with the wpa fix?
  <kalikiana> elopio: Well, doesn't seem like I can. I can't use functions  from __init__.py in the other files
  <cwayne> cachio_: if that's the core in beta currently, yes
  <cachio_> cwayne, perfect
  <cachio_> please tell me once it is ready
  <cwayne> cachio_: thats rev 3242 right?
  <cachio_> cwayne, 3247
  <elopio> kalikiana: I'm confused, because you are talking about sleep, check_call and check_open. Not sure which one you are trying to mock. If it's sleep, just import time and mock.patch('time.sleep')
  <kalikiana> elopio: Yes. And right now all of these are imported individually
  <cwayne> cachio_: ah, were there two pushes to beta today?
  <cachio_> cwayne, yes
  <cwayne> ok, it's ongoing
  <cachio_> cwayne, the last is the valid one
  <cwayne> cachio_: ack, some systems were still running on 3241, we'll cancel and start up 3247 on those now
  <kyrofa> snappy-m-o, autopkgtest 1603 artful:amd64 xenial:arm64 xenial:armhf zesty:arm64
  <snappy-m-o> kyrofa: I've just triggered your test.
  <kyrofa> You're the best
  <cachio_> cwayne, great, thanks
  <mup> PR snapcraft#1625 opened: tests: use the snapcraft snap for integration tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1625>
  <ackk> uhm, https://travis-ci.org/snapcore/snapcraft/jobs/289097568 has a weird error
  <kalikiana> elopio: Alright, will see how far I get by not importing these by name. Already hit `open` not working. So that one I have to mock for the individual file, otherwise it silently fails
  <ackk> kyrofa, ^ beside that one, other tests on my PR are green
  <kyrofa> ackk, unfortunately, the other tests didn't even run due to that failure :P . I've poked it
  <ackk> kyrofa, thanks
  <kenvandine> nessita, i'm getting a 401 error trying to download a snap from the edge channel
  <kenvandine> - Download snap "gnome-taquin" (8) from channel "edge" (received an unexpected http response code (401) when trying to download https://api.snapcraft.io/api/v1/snaps/download/pyEMtK4uVBGIvCV2B1NHC1sb3c2bL7x6_8.snap)
  <kenvandine> nessita, is that something you can help with?
  <kenvandine> we saw this before with the same package, i released it to stable and it worked
  <kenvandine> but now there's a new revision in edge and seeing the same thing again
  <kenvandine> popey, ^^ it happened again, same package
   * sergiusens is always annoyed by our unittests requiring hg, svn and bzr
  <mup> PR snapcraft#1626 opened: lifecycle: split into its own package <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1626>
  <nessita> kenvandine, checking
  <nessita> kenvandine, what arch?
  <kenvandine> amd64
  <nessita> kenvandine, are you logged in? (is not a requirement but if you are is a different debug path)
  <kenvandine> nessita, yes and no :)
  <nessita> in other words, what command were you executing?
  <kenvandine> i've tried it both ways
  <kenvandine> sudo snap install --edge gnome-taquin
  <kenvandine> a wget of the url fails too
  <kenvandine> popey had tried that last time it happened
  <nessita> kenvandine, let me involve more relevant people then
  <kenvandine> cool
   * kenvandine wasn't sure who to bug
  <nessita> cprov, hi hi
  <nessita> cprov, so "sudo snap install --edge gnome-taquin" is failing with - Download snap "gnome-taquin" (8) from channel "edge" (received an unexpected http response code (401) when trying to download https://api.snapcraft.io/api/v1/snaps/download/pyEMtK4uVBGIvCV2B1NHC1sb3c2bL7x6_8.snap)
  <kenvandine> last time i released it to another channel and it was fine in the other channel
  <nessita> cprov, I've checked and the snap is public and released to edge for revision 8
  <kenvandine> now that i rebuilt the snap in edge it happens again
  <popey> works for me
  <popey> i am logged into the store tho
  <nessita> popey, what snapd are you running?
  <kenvandine> oh right... you are special though :)
  <kenvandine> that's right
  <popey> 2.28.5
  <popey> oh, also, I am special
  <kenvandine> doesn't work for my login and not logged in
  <kenvandine> popey, remember we debugged this before ;)
  <nessita> popey, so you are on beta for snapd?
  <kenvandine> nessita, we ruled out snapd versions last time
  <kenvandine> it was his login
  <kenvandine> if popey logs out it fails for him too
  <nessita> popey, you are a reviewer, so that may be giving you special access
  <kenvandine> right
  <popey> i am tracking beta for core, yes
  <popey> because reasons
  <popey> confirmed I get 401 from another (not logged in, snap 2.28.1) machine
  <mup> PR snapd#3954 closed: snap: introduce structured epochs <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3954>
  <cprov> nessita: yup, 401 comes from SCA, I will look in a bit
  <kenvandine> cprov, thx
  <nessita> cprov, if I login it works, and I'm guessing that's because I'm a reviewer, but I thought we killed all privileges for reviewers when downloading outside dashboard
  <cprov> nessita: right, works when I am logged in
  <kenvandine> i can download the snap via the browser
  <nessita> kenvandine, what do you mean?
  <nessita> kenvandine, from the dashboard site while logged in as you?
  <mup> PR snapcraft#1627 opened: lxd: split container classes into different files <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1627>
  <nessita> what's the link you used in the browser?
  <kenvandine> dashboard logged in
  <nessita> cprov, so the above indicates that only publishers and reviewers are being able to download, not other users
  <kenvandine> oh, actually i can install it when logged in
  <kenvandine> but i can't when not logged in
  <kyrofa> nessita, isn't that by design?
  <kenvandine> i can install from the stable channel when not logged in
  <kenvandine> but only for this snap
  <kenvandine> weird... scratch that... i can't install from stable either when not logged in
   * kenvandine could have sworn i could 
  <nessita> kenvandine, but the issue was with edge, no?
  <kenvandine> was... but it exists with stable too it seems
  <kenvandine> when not logged in
  <kenvandine> nessita, i noticed there is a distribution blacklist
  <kenvandine> that lists like all the countries
   * kenvandine hasn't seen that before
  <nessita> gah did I miss checking for country restrictins?
  <kalikiana> elopio: I was successful with not importing by name in the end :-D  You'll see the result in my new PR
  <kenvandine> nah, it says no restrictions
  <kalikiana> Now time to wrap up for today
  <kenvandine> nessita, if i edit that it gives me a huge list of course
  <kenvandine> to select form
  <kenvandine> from
  <nessita> kenvandine, I don't see any restrictions set
  <nessita> kenvandine, as in the whitelist and blacklist are not defined, so that means all countries can access
  <kenvandine> package is public too
  <kenvandine> yeah
  <cprov> nessita: snapident & revs data match what I see in dashboard (public, not country_black/white lists and released at least once)
  <nessita> cprov, so revision 8 is shown as published in the channel map?
  <cprov> nessita: yes, released | 2017-10-17 17:28:31.979241
  <mup> Issue snapcraft#1628 opened: record lxc image used <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1628>
  <kyrofa> What the heck is wrong with Travis. We're getting all sorts of errors that we didn't get before
  <kyrofa> BlockingIOErrors, address space conflicts
  <kyrofa> kalikiana, elopio we're getting container-related autopkgtest failures: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-snappy-dev-snapcraft-daily/artful/amd64/s/snapcraft/20171017_173440_d185c@/log.gz
  <kyrofa> It looks valid, the raw.idmap assertion looks wrong
  <kyrofa> At least, it's obviously different than what we expect
  <elopio> both 1000 0/both 1234 0 Hum, this seems related to the change kalikiana did for running with sudo
  <mup> PR snapcraft#1622 closed: schema: sync patterns with snapd <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1622>
  <sergiusens> elopio how about retriggering adt for snapcraft#1602 ?
  <mup> PR snapcraft#1602: tests: add the slow tag for ros snapd integration test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1602>
  <sergiusens> elopio and what I mean about error prone is that in setUp I change the value we can easily confuse the whole thing. The text should say something like "add it as a class attribute"
  <kyrofa> sergiusens, that's the one I'm whining about now. Doesn't look like a retrigger will succeed
  <kyrofa> Actually I'm whining about its prereq
  <sergiusens> kyrofa which one is the prereq?
  <kyrofa> elopio, note that xenial amd64 passed, and is the only amd64 I ran
  <kyrofa> sergiusens, snapcraft#1603
  <mup> PR snapcraft#1603: tests: add /snap/bin to PATH in autopkgtests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1603>
  <sergiusens> kyrofa the github side of it worked fine
  <sergiusens> kyrofa the adts of it all failed though
  <elopio> sergiusens: I updated the wording. Please let me know if it's better now.
  <kyrofa> sergiusens, indeed
  <kyrofa> elopio, oh wait... what. Maybe I lied. github is still weird right now, the amd64 run disappeared
  <kyrofa> Oh, no, it failed as well
  <kyrofa> I think that was an artifact from the previous run. This is really bad today
  <elopio> well, it's clear there's an issue in that test. It mocks getuid, and returns the wrong value.
  <kyrofa> elopio, and it looks like it fails everywhere
  <kyrofa> Obvious fix? Or would you like me to investigate?
  <kyrofa> I think we should focus on getting autopkgtests to pass until they do :P
  <elopio> kyrofa: obvious fix is to also patch SUDO_UID
  <kyrofa> elopio, wait... these are unit failures. Why aren't they failing on travis?
  <kyrofa> (or locally)
  <kyrofa> Because they run as root in autopkgtest?
  <elopio> because we don't run with SUDO maybe?
  <elopio> I don't like this test :/
  <kyrofa> Ah, indeed, SUDO_UID I see what you're saying now
  <cwayne> cachio_: looks good so far, waiting on a few more devices
  <cachio_> cwayne, great, here also looks promising
  <cachio_> just known issues
  <kyrofa> sergiusens, pre/post stanzas: are you thinking we'll have those around stage/prime as well?
  <mup> PR snapcraft#1629 opened: lxd: fix the unit test for the ser id map <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1629>
  <elopio> what do you kyrofa? snapcraft#1629
  <mup> PR snapcraft#1629: lxd: fix the unit test for the ser id map <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1629>
  <kyrofa> elopio, I'd prefer to see it testing that SUDO_UID actually takes precedence
  <kyrofa> elopio, i.e. make them different values
  <kyrofa> And have an "expected" in the scenario
  <kyrofa> Thoughts?
  <kyrofa> sergiusens, also, do you intend them to include a third stanza that replaces the plugin's? e.g. pre-pull, pull, and post-pull?
  <elopio> kyrofa: please refresh the diff and see if you like it better.
  <kyrofa> elopio, much better, but I'd also like to see a third case where they're both set and SUDO_UID is used instead of getuid
  <kyrofa> Thoughts?
  <kyrofa> I feel like that precedence is probably important behavior to preserve
  <elopio> you are right.
  <elopio> I don't like this test, so I was trying to not touch it a lot. But well, that's a small change.
  <kyrofa> Hahaha
  <kyrofa> Go wash your hands after
  <elopio> hum, no kyrofa, this third test would be a duplicate. On the first one, the env var is set, and os.getuid is not called.
  <kyrofa> elopio, are we testing for that? Or could the test also pass if it tried to call os.getuid first, got None, and fell back to SUDO_UID?
  <elopio> on the second one, the env var is not set, and os.getuid is called. This third test is the same as the first one. I just set the os.getuid return value as None, to make it clearer. But apparently, it's not :p
  <kyrofa> I suppose getting None from getuid would be odd
  <kyrofa> elopio, works for me
  <elopio> well, I can replace getuid None for a value.
  <kyrofa> elopio, doesn't matter too much. I agree with you
  <elopio> snappy-m-o autopkgtest 1629 xenial:amd64
  <snappy-m-o> elopio: I've just triggered your test.
  <cwayne> cachio_: so the only change in this core is the krack fix right?
  <cachio_> cwayne, there are few changes compared with 28.4
  <cachio_> but the diff with the previous 28.5 is just the fix
  <cwayne> cachio_: shouldn't we have done just 2.28.1+krack fix since that's what's in stable today?
  <cachio_> cwayne, that was the original idea, but it was also needed to add some other important fixes that are included in the 2.28.5 such as the fix for machines with nvidia drivers
  <cachio_> cwayne, so it was decided to go with the 2.28.5
  <cachio_> cwayne, so far everything working properly on my side
  <cachio_> cwayne, how is it going in your side?
  <cwayne> cachio_: either way, it looks like we're having some issues with the last device (unrelated to core), so I think in interest of speediness, we can push 3247 to candidate
  <cwayne> everything looks pretty normal here, just waiting on that last device (been having problems with the hw lately)
  <cachio_> cwayne, ok, which device is it?
  <elopio> snappy-m-o autopkgtest 1629 xenial:amd64
  <snappy-m-o> elopio: I've just triggered your test.
  <mwhudson> how do you guys test that snap updates work correctly?
  <mwhudson> i have a bug where the snap being updated breaks things :/
  <mwhudson> oh revert i guess
  <kyrofa> mwhudson, it depends on the snap. I use capistrano for Nextcloud
  <kyrofa> *sigh* I mean capybara. Man what is the deal today
  <kyrofa> mwhudson, and manual testing-- install the stable version, then test refreshing to candidate
  <mwhudson> whoa snap revert blew up in an exciting way
  <mwhudson> i think that's probably the overlayfs fun and games
  <kyrofa> mwhudson, overlayfs? Do I wanna know?
  <mwhudson> kyrofa: the snap i'm working on is subiquity, the server installer
  <mwhudson> it runs out of a livecd environment so everything is strange :)
  #snappy 2017-10-18
  <kyrofa> mwhudson, oh yes that sounds fun
  <sergiusens> kyrofa about pre and post, there's a very long forum post about that!
  <sergiusens> kyrofa so what is the veredict on https://github.com/snapcore/snapcraft/pull/1626 ? Or maybe elopio...
  <mup> PR snapcraft#1626: lifecycle: split into its own package <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1626>
  <zyga-suse> good morning
  <zyga-suse> Pharaoh_Atem: I'll start testing 2.28.5 update after breakfast
  <elopio> snappy-m-o autopkgtest 1630 xenial:amd64:integration
  <snappy-m-o> elopio: I've just triggered your test.
  <mup> PR snapcraft#1630 opened: tests: allow to select a suite when running autopkgtests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1630>
  <mup> PR snapd#4028 closed: interfaces/mount: don't generate legacy per-hook/per-app mount profiles <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4028>
  <zyga-suse> hey, good morning mvo
  <zyga-suse> mvo: heads up, I need to pick up my son from school again at .. 15:00 exactly,
  <mup> PR snapd#4009 closed: tests: adding test for network-manager interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4009>
  <mvo> zyga-suse: good morning
  <zyga-suse> :-)
  <mvo> zyga-suse: do you mind if I merge 3999?
  <zyga-suse> looking
  <mvo> zyga-suse: there is one followup {0,}->{0} for the array init, but otherwise it should be fine, I can do this followup in my 4000 pr
  <zyga-suse> mvo: I think we need to wait for jamie's review
  <zyga-suse> as for {0.} vs {0} - I don't mind. whatever indent does is fine
  <mvo> yeah
  <zyga-suse> mvo, jdstrand should be back tomorrow AFAIR
  <mvo> zyga-suse: ok
  <zyga-suse> mvo: question about .5 promotion
  <zyga-suse> mvo: when do you envision that will happen
  <kalikiana> o/
  <mvo> zyga-suse: hey, not entirely sure, we should discuss in the standup. usually on mondays but given the cirumstance maybe earlier is better
  <zyga-suse> I think that earlier is better too, given that many people are affected by nvidia
  <mvo> zyga-suse: yeah, that too
  <zyga-suse> NB: I won't be at the standup
  <mvo> zyga-suse: also now that the pi3 mystery is traced to ubuntu-image
  <zyga-suse> mvo: aha? different versions of embedded tools?
  <mvo> zyga-suse: yeah, i suspect that
  <mup> PR snapd#4047 closed: snap-confine: init all arrays with `= {0,}` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4047>
  <mup> PR snapd#3872 closed: preserve TMPDIR and HOSTALIASES across snap-confine invocation (LP: #1682308) <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3872>
  <c-lobrano> hey kalikiana, sorry for disappearing yesterday. I updated the PR on LP 1722650 using Gentoo's os-release-info, which does not have VERSION_ID (thanks zyga-suse as well)
  <c-lobrano> ^bug #1722650
  <mup> Bug #1722650: snapcraft requires optional VERSION_ID in os-release <bitesize> <Snapcraft:In Progress by c-lobrano> <https://launchpad.net/bugs/1722650>
  <Chipaca> mvo: ping
  <mvo> Chipaca: pong
  <Chipaca> mvo: i'm lookinig into the translations thing
  <Chipaca> mvo: the translations are on the ubuntu package, not the snapd project
  <Chipaca> mvo: so i can't set up the branch to pull them back in
  <Chipaca> mvo: who knows this stuff?
  <mvo> Chipaca: I do
  <Chipaca> mvo: oh no :-)
  <mvo> Chipaca: its mostly sorted, expect a pr in a little bit
  <Chipaca> mvo: ah ok
  <mvo> Chipaca: I enabled translation on the project now
  <mvo> Chipaca: it was selected on the 15.04 branch
  <zyga-suse> Parlez-vous francais?
  <zyga-suse> will snapd now happily speak esperanto?
  <mvo> zyga-suse: yes
  <mvo> Chipaca: I was mostly adding the test we talked about
  <zyga-suse> mon dieu!
  <zyga-suse> mvo: will we now get perioidic imports of translations into github?
  <mvo> zyga-suse: yes, hopefully we can just pull from a LP git branch
  <mvo> zyga-suse: but that is not done yet
  <ogra_> pfft esperanto ...
  <ogra_> ... klingon is what we want !!!
  <mup> PR snapd#4053 opened: tests,po: sync translations from LP and add regression test for LP:1723974 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4053>
  <mvo> Chipaca: -^
  <mvo> Chipaca: fwiw, this panics for other translations as well
  <mvo> Chipaca: feel free to merge into your branch
  <kalikiana> c-lobrano: Cool! No worries. I'm testing it now
  <Chipaca> mvo: you know what would be cool? if i18n could be compiled to look in a non-system dir, for unit-ish testing
  <mvo> Chipaca: that can be done
  <Chipaca> mvo: SMOP and all that
  <mvo> Chipaca: actally vSMOP
  <mvo> actually
  <mvo> Chipaca: I can make this happen, sounds like the right task before lunch
  <Chipaca> mvo: i've merged your branch and am building the package to test it, fwiw
  <mvo> Chipaca: what do you envision? a unit test for cmd.go?
  <mvo> Chipaca: in addition to the integration test? or should this supersede it?
  <mvo> Chipaca: the i18n might be easy, iirc the cmd.go go-flags stuff is harder to re-init, iirc it has some global state that is hard to get rid of :/
  <Chipaca> mvo: the integration test doesn't seem to do anything that of necessity needs to be integration-y
  <Chipaca> ah
  <Chipaca> bah
  <Chipaca> mvo: maybe it's for another time then
  <mvo> Chipaca: yeah, the i18n part is "simple", but let me quickly poke at it, maybe I misremember, but I think there is a bunch func init() in go-flags
  <Chipaca> mvo: it's sort-of-kinda a static check that run-checks could do if it knew how
  <Chipaca> but might as well leave it in spread Â¯\_(ã)_/Â¯
  <Chipaca> who do we know that speaks nb_NO?
  <Chipaca> fnordahl: ohi
  <fnordahl> Chipaca: jeg snakker norsk, hva trenger du?
  <fnordahl> Chipaca: What can I do for you today?
  <Chipaca> fnordahl: hello. I was just checking if there was a reason (beyond a typo) for â<assertion file>â to have been translated to âforutsetningsfil>â, i.e. for the missing opening <
  <zyga-suse> Chipaca: I was wondering why you didn't choose to add < > in go
  <zyga-suse> Chipaca: and just ask the translators to translate the markupless text
  <Chipaca> ...........................
   * zyga-suse implemented overlayfs hole-poking logic now, now the testing 
  <zyga-suse> *lots* of tests to write
  <Chipaca> zyga-suse: that's my forehead hitting the keyboard
  <Chipaca> zyga-suse: I don't know either. Inertia?
  <Chipaca> OTOH, let's not fix it in that direction _right_ now (and lose the translations)
  <Chipaca> mvo: when we SRU, does that mean the language pack might also get updated? or is that separate?
  <fnordahl> Chipaca: the missing character does indeed look like a typo. To say anything about the actual wording used in the translation I need some context. In which files does the referenced sentences reside?
  <Chipaca> fnordahl: hmm, not sure if this answers your question: https://translations.launchpad.net/ubuntu/artful/+source/snapd/+pots/snappy/nb/+translate?batch=10&show=all&search=forutsetningsfil ?
  <mvo> Chipaca: its separate, the language-packs follow their own schedule
  <Chipaca> fnordahl: otherwise this https://github.com/snapcore/snapd/blob/master/cmd/snap/cmd_ack.go is the source file for that string
  <Chipaca> (but that might not help much either)
  <fnordahl> sure that was helpful, i'll have a look and leave any suggestion I might have on the referenced page and comment here.
  <ackk> mvo, a couple of autopkgtests still failed on  https://github.com/snapcore/snapd/pull/3916, but I'm not sure it's related to the changes
  <mup> PR #3916: snap,wrappers: add support for socket activation <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916>
  <mvo> ackk: you can ignore those, I will double check but those are unstable today
  <ackk> mvo, thanks
  <Son_Goku> zyga-suse: Yo
  <zyga-suse> Son_Goku: hey ho
   * Son_Goku sighs
  <Son_Goku> I'm disappoint
  <Son_Goku> I wanted 2.28.5 to be part of the Fedora 27 final freeze
  <Son_Goku> but no one bothered to give any karma for it
  <Son_Goku> I *hate* this
  <zyga-suse> :-/
  <Son_Goku> no one tests it, and I basically have to wait
  <Son_Goku> and twice I've been ruined by Ubuntu breakages and having to reset the counter
  <Son_Goku> because I *have* to move in lockstep or otherwise things break badly
  <Son_Goku> this is the really *not* fun part of snapd
  <zyga-suse> I don't disagree with other things but the whole 2.28.x release is not really broken just on ubuntu
  <Son_Goku> it's not really broken on Fedora
  <Son_Goku> all the problematic features are disabled
  <zyga-suse> I'm worried that nobody apart from sometimes me looks at fedora testing
  <zyga-suse> Son_Goku: udev is equally broken
  <zyga-suse> Son_Goku: most of the fixes were related to udev in one way or another
  <Son_Goku> you think you're worried? aside from myself, I don't think anyone actually looks at it or cares
  <Son_Goku> I have no numbers to prove any usage, since we don't have an equivalent to popcon in Fedora
  <Son_Goku> I do know that basically no one ever clicks the links on the snapcraft forum
  <zyga-suse> links for testing?
  <Son_Goku> yes
  <Son_Goku> I went through a ton of trouble to diagnose and fix static builds for snap-exec and snap-update-ns
  <Son_Goku> for base snaps
  <leocadio> Hello. Does anyone know if it's possible to make changes on the ath9k driver and compile it as a snap to be executed within a Ubuntu Core installation?
  <zyga-suse> re
  <Chipaca> leocadio: sounds like something for the forum
  <Chipaca> leocadio: AFAIK it's currently not possible -- i think currently you need to ship it in the kernel snap
  <zyga-suse> mvo, Chipaca: I'm going to pick up my son again, will miss standup.
  <zyga-suse> my update is simple, overlays work but I need to spend time on polishing fine details, fixing and writing tests
  <Chipaca> zyga-suse: i'm so excited about overlays :-)
  <zyga-suse> Chipaca: me too, it's a game changer in many ways
  <zyga-suse> I'm pushing a WIP branch but it's too early to even spread test (especially after what I just pushed)
  <zyga-suse> feel free to peek though :)
  <zyga-suse> with that note I'm off
  <mvo> zyga-suse: see you
  <Chipaca> mvo: wrt the translations thing, should i patch the nb_NO translation so the tests pass and we can land it?
  <Chipaca> mvo: or should we wait for launchpad to reflect the fixed translation?
  <mvo> Chipaca: do you have a link to nb_NO translation?
  <mvo> Chipaca: maybe I can fix myself or did you suggest a translation already?
  <Chipaca> mvo: i have suggested it
  <mvo> Chipaca: I think we should fix in git and land and not wait for LP. do you think you could contact the nb translation team? there must be a way to get in touch so that they can approve it?
  <Chipaca> mvo: once f.nordahl confirmed it was a sane suggestion :-)
  <mvo> Chipaca: heh, thanks to fnordahl then :)
   * Chipaca should've split that as fnord.ahl
  <Chipaca> yes indeed
  <Chipaca> but, launchpad hasn't accepted it yet
  <Chipaca> hence my question (as opposed to me pestering you to pull them again)
  <mvo> Chipaca: yeah, lets pester the nb team but also we should not block on it, we have a test so if this gets pullled in again we will know :)
  <Chipaca> mvo: so I hand edit the nb_NO.po?
  <Chipaca> nb.po actually
  <Chipaca> msgid "-r can only be used with --hook"
  <Chipaca> msgstr "Â«-rÂ» kan bare brukes sammen med Â«--hookÂ»"
  <Chipaca> oooohhhh
  <Chipaca> we need to fix quoting everywhere, and it always turns out to be huge. I'll probably do it on a plane six months from now :-)
  <Chipaca> (there's a bug along the lines of âuse double quotes for X, single quotes for Yâ)
  <Chipaca> mvo: anyway, unless you say no, i'm pushing a fix to nb.po so my branch looks green again
  <mvo> Chipaca: +1
  <Chipaca> ok, i'm going off for a while
  <mup> PR snapd#4051 closed: many: add integrated snapfuse <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/4051>
  <mup> PR snapcraft#1623 closed: Removed dependency on VERSION_ID in os-release <Created by clobrano> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1623>
  <mup> PR snapcraft#1626 closed: lifecycle: split into its own package <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1626>
  <sergiusens> o/
  <sergiusens> In the end I decided to cancel my day off for today. There is just so much I want to get done
  <sergiusens> kalikiana mind looking at snapcraft#1480 ? The adt container test errors
  <mup> PR snapcraft#1480: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1480>
  <kalikiana> sergiusens: There's already a PR snapcraft#1629 for part of the failures - I'm actually looking into the one it doesn't fix that fails with "no such file or directory"
  <mup> PR snapcraft#1629: lxd: fix the unit test for the user id map <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1629>
  <zyga-suse> me is home
  <zyga-suse> time for a small break, then to attack overlayfs with tests
  <zyga-suse> :-)
  <mup> PR snapcraft#1624 closed: kernel plugin: use latest stable core snap <bug> <Created by alfonsosanchezbeato> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1624>
  <kyrofa> pstolowski, curious to get your thoughts on https://forum.snapcraft.io/t/restarting-services-from-configure-hook-race-condition
  <pstolowski> kyrofa, are you watching me?
  <kyrofa> pstolowski, ha!
  <kyrofa> Yes
  <ogra_> kyrofa, is that the webcam link you forwarded to me in PM (havent clicked it yet) ?
  <kyrofa> ogra_, who ELSE would it be?
  <ogra_> indeed
  <pstolowski> kyrofa, I was reading it for the 2nd time a moment ago. still thinking - the response you got already was kinda what I thought about too (creating a config file solves the "problem" of transactional nature of the hook; but on the other hand it's against the idea of using snapctl when possible
  <kyrofa> pstolowski, my thoughts exactly
  <pstolowski> kyrofa, so, I need to think some more. clearly the introduction of snapctl outside of hooks introduced this kind of issue
  <kyrofa> pstolowski, well, it exposed it anyway. I would never say that feature wasn't required-- it's one of my favorites actually. Saving a config file felt super hacky
  <kyrofa> But yeah, making use of it is difficult
  <pstolowski> kyrofa, right, exposed; bad choice of words on my side
  <kyrofa> pstolowski, at the same time, what we have is conceptually correct. I like the transactional manner of this
  <kyrofa> My lockfile is admittedly probably just as hacky as saving config files, haha
  <pstolowski> kyrofa, would it make sense to be able to commit changes to config explicitely? `snapctl commit`? but it feels suspicious, we loose all the benefit of reverting config changes on failure
  <pstolowski> feels like a hack too
  <pstolowski> nah
  <kyrofa> pstolowski, yeah I considered that as well. I agree that it defeats some of the niceties and adds complexity...
  <kyrofa> But it feels more intuitive than trying to design a way to queue service restarts
  <kyrofa> I don't even know what that would look like
  <kyrofa> It also makes documentation hard. If configuring the port for apache succeeded but configuring the memory limit for PHP failed, the hook fails. I think the user should be able to assume everything they just set failed
  <kyrofa> pstolowski, here's a question
  <kyrofa> pstolowski, this problem exists because I can't actually restart the service. I have to kill it, then systemd brings it up in its own env
  <kyrofa> pstolowski, once snapctl supports restarting services, and I use it inside the hook, won't it get the hook's snapctl transaction?
  <kyrofa> i.e. its configuration
  <kyrofa> The context/cookie should be the same
  <pstolowski> kyrofa, indeed, but it's just going to send a request to snapd to restart the service (which in turn just restarts it via systemd)
  <kyrofa> Ah, darn
  <kyrofa> pstolowski, okay, what if snapctl grew the ability to queue generic shell commands that ran after the hook completed successfully
  <kyrofa> Then one could use `snapctl queue -- snapctl restart apache`
  <kyrofa> (in the hook)
  <pstolowski> kyrofa, hmm, maybe.. what about a "post-configure" hook?
  <kyrofa> That ran when `configure` succeeded? That could work, but requires one to save old values to compare new vs. old and determine what needs to be restarted
  <kyrofa> i.e. the restart conditions need to be determined out of context
  <kyrofa> Which is a bit of a buden
  <kyrofa> burden*
  <pstolowski> right, good point
  <Chipaca> linode is being funny again?
   * Chipaca hits the AGAIN button
  <mup> PR snapcraft#1603 closed: tests: add /snap/bin to PATH in autopkgtests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1603>
  <kyrofa> pstolowski, with the generic commands, we can build up a queue and then only run unique commands, so multiple service restart queues only end up restarting once, etc.
  <kyrofa> Well... maybe you don't want that as a generic feature. Hmm
  <pstolowski> kyrofa, atm I'm wondering if there is any way to expose cookie/context to the restarted service, so that it sees same transaction, and sapctl get from the service see yet-uncommited values. not sure that's easily doable though
  <kyrofa> pstolowski, that seems the simplest from the users point of view, certainly
  <mup> PR snapcraft#1631 opened: lxd: use FakeFilesystem in test_snap_containerized_remote <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1631>
  <kyrofa> pstolowski, although that still breaks the transactional nature of setting a configuration. That means it's possible for a service to be running with a configuration that failed to apply in the end
  <pstolowski> indeed
  <kalikiana> sergiusens: snapcraft#1631 is the missing piece to get the autopkg tests green again
  <mup> PR snapcraft#1631: lxd: use FakeFilesystem in test_snap_containerized_remote <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1631>
  <kalikiana> together with elopio's PR
  <elopio> together with two other PRs. We'll get there :)
  <kalikiana> Haha, true. I just meant the lxd ones, but yeah
  <kalikiana> elopio: your branch has conflicts btw
  <sergiusens> kalikiana can you just update elopio's branch with that PR as he moved the container tests into a new class
  <sergiusens> ?
  <kalikiana> sergiusens: That one doesn't test user id's so it wouldn't really benefit from the scenarios...
  <kalikiana> I can add it to his branch anyway
  <kalikiana> But not in the new class
  <elopio> conflict solved.
  <pstolowski> niemeyer, hey, any thoughts on the above discussion - I summarized it here: https://forum.snapcraft.io/t/restarting-services-from-configure-hook-race-condition/2513/5 ?
  <niemeyer> Looking
  <sergiusens> nhandler hey, do you know how long the talks are for ATO?
  <kyrofa> sergiusens, four hours. You didn't know that?
  <pstolowski> niemeyer, hold one for a sec, forgot to document one more case
  <kyrofa> sergiusens, they anticipate between 300-500 slides
  <sergiusens> kalikiana the thing is, one will have conflicts as soon as the other lands, won't they? They both touch test_snap
  <sergiusens> kyrofa lol, given that there are 8 talks in parallel I think the combined value would add up to that number
  <kyrofa> Haha
  <sergiusens> kyrofa I will just use slides with single words ;-)
  <kyrofa> sergiusens, those are called CEO talks
  <sergiusens> heh
   * sergiusens leaves the computer for a bit to practise some aikido and get lunch
  <pstolowski> niemeyer, ok, now, updated with item #4
  <niemeyer> pstolowski: Thinking
  <kyrofa> pstolowski, good summary, thank you
  <niemeyer> pstolowski, kyrofa: Responded
  <kalikiana> elopio: sergiusens pushed my fix to the existing branch now
  <mup> PR snapcraft#1631 closed: lxd: use FakeFilesystem in test_snap_containerized_remote <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1631>
  <elopio> snappy-m-o autopkgtest 1629 xenial:amd64
  <snappy-m-o> elopio: I've just triggered your test.
  <pstolowski> niemeyer, thanks
  <niemeyer> pstolowski: #3972 reviewed again
  <mup> PR #3972: interfaces: sanitize plugs and slots early in ReadInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/3972>
  <niemeyer> pstolowski: LGTM with those details sorted
  <pstolowski> niemeyer, cool, thank you
  <facubatista> sergiusens, elopio, how can I see stdout in snapcraft tests after I put a print() in the tests?
  <elopio> facubatista: in unit tests, there's a self.fake_terminal that swallows all stdout and stderr.
  <facubatista> elopio, is there an easy way to disable it?
  <elopio> I wouldn't use print to debug. I would put a self.assertThat to confirm my assumptions. But, you can self.fake_terminal.getvalue()
  <facubatista> elopio, I can not open a pdb either
  <facubatista> elopio, I need to start checking the subversion machinery to see why a test fails in my computer
  <elopio> facubatista: comment it out in the setUp.
  <facubatista> elopio, is this a standard procedure? how do you debug when run tests?
  <elopio> I put assertions.
  <facubatista> elopio, but an assertions is a way to check a variable to a value... how do you just *see* different values when making the machinery move?
  <elopio> But it's not a happy thing. We need to split our logic from our presentation. One day...
  <elopio> When I don't understand a test, I put multiple assertions to check if my assumptions are correct until I understand it.
  <elopio> Not saying that's what you should do. You can disable the setup things that break pdb, and debug
  <facubatista> elopio, ack, thanks
  <mup> PR snapd#4017 closed: store: add download caching <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4017>
  <elopio> Probably sergiusens, kaliakiana and kyrofa have other methods.
  <facubatista> elopio, oh, subversion tests depends on machine's locale :/
  <kyrofa> elopio, facubatista yes I use a magical line: raise RuntimeError(<thing i want to see>)
  <kyrofa> The whole swallowing stdout/stderr for everything is awful
  <facubatista> kyrofa, that, like elopio's assert, makes possible to see ONE thing, not several
  <kyrofa> facubatista, you will hear no disagreement from me
  <elopio> Oh damn. That's a good finding, thanks facubatista
  <elopio> Please report a bug.
  <kyrofa> facubatista, sometimes that line becomes more magical: raise RuntimeError('{} {}'.format(<first thing>, <second thing>)) :P
  <facubatista> kyrofa, too much work error :p
  <kyrofa> Hahaha
  <facubatista> kyrofa, elopio, thanks!!
  <kalikiana> facubatista: You can also use the logger to read the output. Although it's slightly different depending on the test setup.
  <kalikiana> elopio: let me know if anything else comes up wrt autopkg tests, Travis is sadly slow to confirm... I'm headed to a pub now, but will check IRC later
  <elopio> Tx kalikiana
  <sergiusens> elopio you should alias autopkgtest to adt, some contracted and some expanded nouns gets me all the time ;-)
  <sergiusens> facubatista I use vs code and set breakpoints as a normal person :-P
  <elopio> Pitti renamed everything to autopktest. Adt is no more
  <sergiusens> elopio I really wish the unittest for subversion, hg and bzr tests were just removed or have fakes in place for those
  <sergiusens> facubatista you can blame kyrofa fo all the hidding, he always complained about leaked stdouts in the tests ;-)
  <sergiusens> kyrofa now that we are using click we could probably just mock the calls to click instead, just a hint for a rainy day :-)
  <elopio> Fakes + integration tests sounds good to me. Just integration doesn't sound so bad either
  <mwhudson> hooray for merging #3872  ;)
  <mup> PR #3872: preserve TMPDIR and HOSTALIASES across snap-confine invocation (LP: #1682308) <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3872>
  <kyrofa> sergiusens, yes indeed
  <mup> PR snapcraft#1602 closed: tests: add the slow tag for ros snapd integration test <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1602>
  <sergiusens> kyrofa does my comment on snapcraft#1613 make sense?
  <mup> PR snapcraft#1613: cross compilation: enable cross compilation of i386 kernel on x86-64 â¦ <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1613>
  <kyrofa> sergiusens, yeah probably
   * zyga-ubuntu fell asleep
  <zyga-ubuntu> man, I need to sleep more regularly
  <zyga-ubuntu> just woke up
  <sergiusens> kyrofa do you have time to test a branch for me on your trustworthy trusty sytem?
  <sergiusens> *system
  <kyrofa> sergiusens, haha, I ran out of HD space and blew it away
  <sergiusens> kyrofa oh, well, I thought you might like this https://github.com/snapcore/snapcraft/compare/master...sergiusens:libc6-and-friends?expand=1
  <kyrofa> sergiusens, ooo, fancy! Let me shuffle a few files around and get back to you
  <sergiusens> kyrofa that is, libraries from the past; next the more complicated elf patching, but I am still pondering on that
  <facubatista> sergiusens, import pdb; pdb.set_trace(), if not commenting out the fake_terminal thing, crashes with TypeError: bad argument type for built-in operation
  <facubatista> elopio, https://bugs.launchpad.net/snapcraft/+bug/1724674
  <mup> Bug #1724674: Subversion test fails in a non-english locale <Snapcraft:New> <https://launchpad.net/bugs/1724674>
  <sergiusens> facubatista yeah, FakeTerminal might need what I mentioned above
  <sergiusens> kyrofa how is that going? I have a small refactor coming after that ;-)
   * sergiusens begins the relocation process
  <mup> PR snapcraft#1632 opened: libraries: exclude the full set of libc6 <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1632>
  <kyrofa> sergiusens, haven't tested yet, clearing space now. Would be nice to be able to test the PR's snap... ;)
  <kyrofa> elopio, in gitlab ci I can specify artifacts and it displays them on the PR. Do you know if Travis supports somethin similar?
  <elopio> kyrofa: it does not.
  <kyrofa> Darn. Well, I discovered something neat today that might prove useful: transfer.sh
  <kyrofa> elopio, sergiusens we could upload every PR's snapcraft there
  <elopio> when I asked about sharing files between stages, they said that's the solution. But everything is slow here. After my first project in gitlab, I'm happy to move all our stuff there :D
  <kyrofa> There's even a snap for it made by someone awesome: snap install transfer
  <elopio> kyrofa: how much space do we get there for free?
  <kyrofa> elopio, 10 gigs for each transfer. It stays there for 14 days
  <elopio> $26 of $2,000 per month
  <elopio> When I reach $ 2000 a month, we can keep running Transfer.sh.
  <elopio> it sounds they need more support to be sustainable. I'm happy to change my PR to use that instead of the cache. We can always fall back to the cache if they have to suspend the service.
  <elopio> actually, we still need the cache to share the file id between stages. But the benefit is that we can manually install and test it. Not bad.
  <kyrofa> Inded
  <kyrofa> With another e in there somewhere
  <stgraber> zyga-suse, jdstrand: we recently noticed this: https://bugs.launchpad.net/snapd/+bug/1724697
  <mup> Bug #1724697: snap-confine shouldn't setup a seccomp policy if policy is @unrestricted <snapd:New> <https://launchpad.net/bugs/1724697>
  <stgraber> can you comment on the approach? I may be able to spare a bit of time from one of the LXD devs to change snap-confine.
  <sergiusens> kyrofa elopio while we can switch CI systems we cannot move away from github without contention
  <sergiusens> I would push for proper hook design to get PRs into build.snapcraft.io
  <kyrofa> sergiusens, nah, not making a play for github-ci, just thinking about how to get snaps available from PRs
  <kyrofa> sergiusens, oh definitely the preferred option. Plan B is just uploading the snap from travis. Moving to gitlab-ci is not on our radar AFAIK as much as I whine
  <sergiusens> JamieBennet btw, we talked about that during the Sprint but it did not reach any roadmap ^
  <kyrofa> JamieBennett, please please pretty please
  <sergiusens> kyrofa we certainly should have proper guidelines for folks on gitlab though
  <kyrofa> sergiusens, yeah, would be handy to see a build.snapcraft.io integration there, but an `enable-ci gitlab` option would be pretty easy as well
  <sergiusens> We should work on the latter
  <zyga-suse> stgraber: ack, checking
  <zyga-suse> stgraber: the change to what @unrestricted means was done a while ago, along with the introduction to snap-seccomp
  <zyga-suse> stgraber: before the seccomp profile was parsed each time
  <zyga-suse> stgraber: now the profile is parsed and compiled only when the policy is prepared
  <zyga-suse> stgraber: because the compiled policy is a BPF program we didn't have a way to say "don't load anything" without introducing some form of header or other special semantics in interpreting the file content
  <zyga-suse> stgraber: mvo implemented a permissive policy as a workaround
  <zyga-suse> stgraber: if this breaks LXD we can definitely change this
  <zyga-suse> stgraber: e.g. by encoding a little header or by interpreting tuncated file as unconifned
  <zyga-suse> stgraber: (or perhaps a file containing just the string @unconfined, not to be confused with a truncated file due to another bug)
  <zyga-suse> stgraber: I commented as such on the bug report now
  <zyga-suse> stgraber: I'll catch up with mvo tomorrow morning about this
  <zyga-suse> stgraber: please try to indicate urgency or importance, is this a 2.28.6 material?
   * zyga-suse -> EOD
  #snappy 2017-10-19
  <sergiusens> kyrofa and?
  <kyrofa> sergiusens, seems to work, but my test case is broken anyway (opencv) so I still want to poke at it some more tomorrow. Left some comments on the PR
  <stgraber> zyga-suse: not crazy urgent, not warranting a point release on its own, but it is something we need sorted to have LXD actually be at feature parity with the deb package. Custom seccomp policies is a feature we've had quite a bit of interest for lately and it's pretty unfortunate that it's not working with the snap.
  <sergiusens> kyrofa it would be nice to know how it is broken and what is the test case, I'll most likely be off tomorrow but all the info you can get would be good
  <kyrofa> sergiusens, it's the bug I logged about snapcraft on trusty
  <kyrofa> Details are there
  <zyga-suse> stgraber: I understand, I'll talk to mvo
  <morphis> stgraber: zyga-suse: not sure what I see here: https://paste.ubuntu.com/25770362/
  <stgraber> that's a snapd bug
  <stgraber> that got fixed in a 2.28 point release
  <morphis> ah good to know
  <morphis> which isn't yet in stable as it seems
  <morphis> stgraber: yeah, with latest candidate of core it seems to be fixed
  <zyga-suse> morphis: indeed, this is fixed in one of the point releases after 2.28, try .5 to be sure
  <elopio> snappy-m-o autopkgtest 1630 xenial:amd64:integration
  <snappy-m-o> elopio: I've just triggered your test.
  <sborovkov> ogra_: hi. Looks like psplash is not present in cm3? Is it like forgotten there?
  <zyga-suse> mvo: good morning
  <mvo> hey zyga-suse
  <mvo> zyga-suse: how ar ethings?
  <zyga-suse> mvo: sorry to start like that straight when you join
  <zyga-suse> https://bugs.launchpad.net/snapd/+bug/1724697
  <mup> Bug #1724697: snap-confine shouldn't setup a seccomp policy if policy is @unrestricted <snapd:Triaged> <https://launchpad.net/bugs/1724697>
  <zyga-suse> we need to solve this quickly
  <zyga-suse> mvo, stgraber said it's not a 2.28.6 thing but important for him
  <zyga-suse> mvo: I think the idea to keep the file and put a unique string into it is simple and should be enough
  <mvo> zyga-suse: ok, sounds reasonable
  <mvo> zyga-suse: I'm just reading the bugreport
  <mvo> zyga-suse: I can work on a fix this morning, just doing some pi2 related research but I'm almost done
  <zyga-suse> mvo: I can help too
  <zyga-suse> mvo: I'm working on loads of tests for the new overlayfs mount feature
  <mvo> zyga-suse: overlays are priority
  <zyga-suse> ok
  <mvo> zyga-suse: at least that is my understanding :)
  <mvo> zyga-suse: hey, if we could get that for 2.29 ...
  <mvo> zyga-suse: maybe as a experimental thing or so?
  <zyga-suse> I think it's too soon as neither gustavo nor jamie saw it yet
  <zyga-suse> but we'll see :)
  <zyga-suse> I need to land a prereq branch
  <zyga-suse> I may yet tweak it to move files around and shrink diff for future PRs but not my priority yet
  <kalikiana> o/
  <c-lobrano> morning :)
  <c-lobrano> kalikiana: thinking about hardening `get_os_release_info`, as suggested by kryofa. What about a little bit more robust `get_os_release_info` and some `get_os_release_fieldname` that wrap the first and provide fallback? Like `get_os_release_version_id()`. This way, the user does not need to know the actual dictionary key name
  <kalikiana> c-lobrano: Hmm maybe one step further and make it a little class?
  <c-lobrano> kalikiana: yes, that would be good
  <mup> PR snapcraft#1633 opened:  recording: record information from the image in container builds  <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1633>
  <kalikiana> elopio: since you're awake: we hit the timeout again in snapcraft#1632 :-(
  <mup> PR snapcraft#1632: libraries: exclude the full set of libc6 <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1632>
  <elopio> I'm working on the split.
   * zyga-suse -> coffee
  <kalikiana> awesome
  <Chipaca> pedronis: how're things?
  <Chipaca> mvo: has #4050 earned your +1?
  <mup> PR #4050: cmd/snap: tell translators about arg names and descs req's <Created by chipaca> <https://github.com/snapcore/snapd/pull/4050>
  <mvo> Chipaca: I look in a tiny bit
  <Chipaca> mvo: how's things?
  <mvo> Chipaca: I can foresee nitpicking about tidyNoticef, as the name gives no hint that it transforms into a panic under certain conditions. but I have not made up my mind much
  <mvo> Chipaca: otherwise things are good mostly, looking at pi firware stuff right now
  <Chipaca> mvo: do we have a reproducer for the insane flip-flops?
  <mvo> Chipaca: what flip-flops, do you have a reference to a forum post or a bugreport?
  <mup> PR snapd#4054 opened: snap-{confine,seccomp}: make @unrestricted fully unrestricted <Created by mvo5> <https://github.com/snapcore/snapd/pull/4054>
  <mvo> zyga-suse: and you may say "told you so" now :) I remeber we talked about fully unrestricted seccomp and iirc you suggested we should do it in the above way
  <jacekn> aaaaaaaaaaaaaaaaaaaaaaaaaaaaa3aaaaaaad
  <jacekn> sorry
  <Chipaca> mvo: sorry, i meant the thing where sergio's pi3 would boot into one thing but think it's booting into another? something like that
  <mvo> Chipaca: we know it is caused by the ubuntu-image snap, once sergio uses the deb things are ok. my plan was to look into it more once I have a pi3 (should arrive today)
  <Chipaca> ah ok
  <mvo> Chipaca: which is a huge relief that its not a snapd issue
  <Chipaca> mvo: we can shake our fists at barry and move on :D
  <mvo> Chipaca: :-D
  <zyga-suse> mvo: impossible, I don't recall saying that ;-)
   * zyga-suse is progressing thrgough testing, with some nice simplifications and improvements to code in result of finding tiny details off
  <Son_Goku> mvo, zyga-suse: https://github.com/canonical-docs/snappy-docs/pull/138
  <mup> PR canonical-docs/snappy-docs#138: Update Fedora snapd to 2.28.5 <Created by Conan-Kudo> <https://github.com/canonical-docs/snappy-docs/pull/138>
  <Son_Goku> davidcalle ^
  <Son_Goku> zyga-suse: this will likely be the end of the line for Fedora 25
  <Son_Goku> as by the time 2.29 becomes available, Fedora 25 will EOL
  <Son_Goku> zyga-suse, you should reach out to pitti at some point to talk about downstream Fedora CI
  <Son_Goku> he's been working on a project to introduce the equivalent of autopkgtests in Fedora for a while now
  <mvo> zyga-suse: does "cannot open current mount profile: /run/snapd/ns/snap.*<snap_name>*.fstab:permission denied" ring any bell? we got a bugreport about this, I can forward
   * kalikiana break
  <mup> PR snapd#4055 opened: daemon: generate a forbidden response message if polkit dialog is dismissed <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4055>
  <mup> PR snapd#4056 opened: tests: improve revert related testing <Created by mvo5> <https://github.com/snapcore/snapd/pull/4056>
  <zyga-suse> mvo: hmmm, no, not immediately, looks like apparmor
  <zyga-suse> mvo: please forward
  <mvo> zyga-suse: I did
  <mvo> zyga-suse: its the mail from pierre, I don't have many details yet
  <zyga-suse> mvo: ePierre?
  <mvo> zyga-suse: yeah, I think so
  <mvo> zyga-suse: does http://paste.ubuntu.com/25771634/ ring a bell?
  <zyga-suse> mvo: that looks like a custom base snap with no /dev
  <mvo> zyga-suse: that is from core stable -> edge auto refresh test http://paste.ubuntu.com/25771638 has the debug
  <mvo> zyga-suse: anyway, I have a look
  <mvo> zyga-suse: but it looks like pierre foudn a bug
  <zyga-suse> mvo: this code didn't change
  <zyga-suse> mvo: I bet it's /dev missing
  <zyga-suse> mvo: FYI, I'm chatting with ePierre on #chekbox
  <zyga-suse> #checkbox
  <mvo> zyga-suse: aha, ok
  <zyga-suse> I want to collect some quick info since pierre is likely to EOD any time now
  <zyga-suse> mvo: can you forward the rport please?
  <mvo> zyga-suse: I did that already, you are in the CC
  <mvo> zyga-suse: message-id: 20171019102101.h7wlysxnpqjfufqk@bod
  <zyga-suse> I get 0 matches
  <zyga-suse> maybe gmail doesn't filter on those
  <zyga-suse> mvo: ok, I understand the issue now
  <zyga-suse> mvo: not sure why it happens but here's what happens:
  <zyga-suse> mvo: when we introduced snap-update-ns as the namespace initializer
  <zyga-suse> mvo: we removed the ability to read / process .fstab files from snap-confine
  <zyga-suse> mvo: after reverting we are running on the profile from the +next version
  <zyga-suse> mvo: I think it looks like a bug in the code that re-builds snap-confine's apparmor profile
  <zyga-suse> mvo: does that make sense?
  <zyga-suse> mvo: after revert we should immediately rebuild the profile
  <zyga-suse> mvo: what is curious here is that since the profile is *path based* it should not be a problem
  <zyga-suse> the old profile is around
  <zyga-suse> mvo: (around as in loaded in memory)
  <mvo> zyga-suse: well, we reboot in between in tests on core
  <mvo> zyga-suse: but yeah, it makes sense
  <zyga-suse> hmmm
  <mvo> zyga-suse: I mean, if its loaded in memory it will get lost accross the reboot
  <zyga-suse> this should not be an issue on core
  <zyga-suse> yes
  <zyga-suse> well
  <zyga-suse> no
  <mvo> zyga-suse: the report is about core afaict
  <zyga-suse> across reboot we'll keep the file in /etc/apparmor.d
  <zyga-suse> so it will get re-loaded
  <zyga-suse> was this on core on classic?
  <mvo> zyga-suse: from what I read its a regular core device (caracalla/stlouis9
  <mvo> )
  <zyga-suse> right
   * zyga-suse thinks
  <zyga-suse> it doesn't seem device specific
  <zyga-suse> so we should be able to reproduce it
  <mvo> yeah
  <zyga-suse> that was edge->stable?
  <mvo> I did a PR that tests some more things with reverts
  <mvo> yeah
  <zyga-suse> thank you
  <zyga-suse> do you want me to explore or shall I keep at layouts?
  <mvo> see the linked PR
  <zyga-suse> ack
  <mvo> I can work a bit on this and get a reliable test, then we can brainstorm again
  <mvo> zyga-suse: just wanted to double check that its not something obvious
  <mvo> (or known)
  <zyga-suse> no, nothing obviously smoking-gun-wrong
  <mvo> ta
  <zyga-suse> mvo: when we run reexecing snap-confine do we follow the current symlink?
  <zyga-suse> meh
  <zyga-suse> mvo: I'm dumb
  <zyga-suse> mvo: I understand now
  <zyga-suse> mvo: on core / is the core snap
  <zyga-suse> mvo: so when we get new core via update
  <zyga-suse> mvo: (and we don't reload the profile there)
  <zyga-suse> mvo: so when we get the new core, we must not follow any current symlinks and must use the old profile
  <zyga-suse> mvo: right?
  <zyga-suse> mvo: so we literally run /usr/lib/snapd/snap-confine
  <mvo> zyga-suse: correct
  <zyga-suse> mvo: so dump my other theories, the cause still is likely (we removed the right to touch .fstab profiles) but why it gets applied here is unclear
  <zyga-suse> mvo: (assuming before reboot)
  <zyga-suse> I'm getting hungry, let's break for some lunch
  <mvo> zyga-suse: good idea
  <kalikiana> mwhudson: Hey! I was wondering if we should discuss snapcraft#1557 a bit
  <mup> PR snapcraft#1557: cleanbuild: add a --image option to build in a different image <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1557>
  <zyga-suse> re
  <Chipaca> kalikiana: you know it's 1am for mwhudson, yes?
  <kalikiana> Chipaca: Oh, I didn't realize. What timezone is he in?
  <zyga-suse> kalikiana: NZ
  <zyga-suse> "the far side of the moon^Hearth"
  <kalikiana> Heh
  <kalikiana> Thanks
  <kalikiana> I'll try to ping him at a better time then
  <Chipaca> kalikiana: that's not to say he isn't sometimes around at this time, but it's usually bad news :-)
   * zyga-suse works on 4008
  <zyga-suse> I can put some future code there to make eventual diff smaller
  <zyga-suse> hmm
  <zyga-suse> on go 1.9.1 I cannot "go test" stuff anoymre
  <zyga-suse> *anymore
  <zyga-suse> zyga@faroe:~/snapd/cmd/snap-update-ns> go test .
  <zyga-suse> # github.com/snapcore/snapd/vendor/gopkg.in/tomb.v2
  <zyga-suse> flag provided but not defined: -goversion
  <zyga-suse> niemeyer: ^ does this ring any bells?
   * zyga-suse reboots
  <zyga-suse> ok, all good now
  <zyga-suse> probably stale env after update
  <jdstrand> zyga-suse: overlayfs? I thought this was being done with bind mounts...
  <zyga-suse> jdstrand: with both
  <niemeyer> zyga-suse: No, I've never seen that flag either I think
  <zyga-suse> niemeyer: it's all good now
  <niemeyer> zyga-suse: Perhaps go tool was out of date with underlying tooling
  <zyga-suse> yes, I just updated; it's okay now, probably some stale stuff while I was logged in
  <cachio> mvo, I am creating a test for gsettings interface, an I am getting "gsettings: not found" when I execute a command
  <mvo> cachio: curious what this is about
  <mvo> cachio: it is installed and in /usr/bin/gsettings I pressume?
  <cachio> yes
  <cachio> mvo, it is just a wrapper for gsettings command
  <cachio> the snap makes gsettings "$@"
  <zyga-suse> mvo: just saw this from go vet
  <zyga-suse> cmd/snap-repair/runner.go:254: arg r.RepairID() for printf verb %d of wrong type: string
  <zyga-suse> cmd/snap-repair/runner.go:415: arg repair.RepairID() for printf verb %d of wrong type: string
  <zyga-suse> mvo: shall I fix?
  <zyga-suse> odd, I don't see the issue
  <zyga-suse> %d is printing int's
  <cachio> pedronis, hey, tests/lib/assertions/auto-import.assert  is expired, do you know how to generate a new one?
  <jdstrand> zyga-suse: I was unaware that layouts required overlayfs. when was the greenlight given on overlayfs? we can't guarantee it is going DTRT with apparmor in modern kernels or in backported apparmor to older kernels. overlayfs is unbackportable to older kernels. all the same arguments as always...
  <Chipaca> zyga-suse: in 451, it's doing ("... %s/%d != %s/%d", repair.BrandID(), repair.RepairID(), brandID, repairID)
  <zyga-suse> jdstrand: this is a new development (relatively), we plan to use overlayfs to poke writable holes over squashfs; I made a RFC branch that does this
  <zyga-suse> Chipaca: I know, I think go vet is wrong here
  <ogra_> sborovkov, i changed teams and all, i simply didnt get to cm3 yet, but should be ready before end of this week (i'm currently working on the remaining bits for cm3 and dragonbard splash support)
  <zyga-suse> Chipaca: especially after fixing it tests are failing
  <Chipaca> zyga-suse: RepairID() returns a string
  <zyga-suse> aha
  <jdstrand> zyga-suse: obviously it's a new development :) my question is where was it discussed? it seems to be ignoring the previous discussions
  <zyga-suse> jdstrand: I don't remember if it was a hangout recently or IRC recently
  <zyga-suse> jdstrand: I recall the earlier discussion but this is an experiment to see if we can use overlay for this purpose
  <jdstrand> zyga-suse: I thought things like this were supposed to be captured in the forum? this is a major technical decision
  <zyga-suse> jdstrand: as it presents simpler semantics and has easier undo story
  <zyga-suse> jdstrand: indeed, I wanted to talk to you about this because it's a big change but all the sprints/holidays were in the way
  <zyga-suse> jdstrand: the short summary is that we'd like to use overlayfs over squashfs
  <zyga-suse> jdstrand: as a hole-poking tool
  <zyga-suse> Chipaca: no, it's an int:
  <zyga-suse> ... error string = "cannot fetch repair, repair id mismatch canonical/%!s(int=2) != canonical/4"
  <zyga-suse> ... regex string = "cannot fetch repair, repair id mismatch canonical/2 != canonical/4"
  <zyga-suse> jdstrand: anyway, let's put that on hold now
  <zyga-suse> jdstrand: (the discussion)
  <Chipaca> zyga-suse: i was wrong Â¯\_(ã)_/Â¯
   * Chipaca tries to find out why he was wrong
  <zyga-suse> jdstrand: I'll have a thread and PR to review (very short) soon after https://github.com/snapcore/snapd/pull/4008 lands
  <mup> PR #4008: cmd/snap-update-ns: create missing mount points automatically <Created by zyga> <https://github.com/snapcore/snapd/pull/4008>
  <zyga-suse> (that's what I'd like to focus on now)
  <jdstrand> I understand that. I have little confidence it is going to work reliably with apparmor  considering people are backporting apparmor to older kernels (or even an unpatched kernel). I mean, it might work with a recent Ubuntu kernel. note that overlayfs wasn't even an official thing in the upstream kernrel til relatively recently. this makes snaps that utilize the feature impossible to use on older kernels where you can't backport overlayfs
   * Chipaca disappears again
   * zyga-suse nods
  <jdstrand> tyhicks: warning ^. the plan is to try overlayfs to poke holes in squashfs in an exploratory PR
  <jdstrand> tyhicks: (in support of layouts)
  <zyga-suse> jdstrand: I have the undo logic to tweak but it looks promising (so far)
  <zyga-suse> jdstrand: the diff is very small so far, which is also very very promising
  <zyga-suse> ohg
  <zyga-suse> standup
  <jdstrand> well, except the technologies you are utilizing have to actually work right
  <jdstrand> not to mention my point that overlayfs is new so its use means those snaps can't work on older kernels
  <mup> PR snapd#3972 closed: interfaces: sanitize plugs and slots early in ReadInfo <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3972>
  <jdstrand> zyga-suse: I should also stress that overlafs didn't land in its current form. it landed early and had lots of trouble with LSMs. It still has trouble with LSMs. this means that there is a huge test matrix to make sure  the feature even works for kernels that claim to support the feature
   * jdstrand still wonders why he or tyhicks weren't pulled into the conversation
  <jdstrand> or jj
  <ogra_> pobably zyga will simply fix all missing LSM bits with overlayfs on the go then ;)
  <ogra_> ... will just delay the ETA for the feature by a few years :)
  <skjensen> Hi guys, I'm trying to build an image for my Nvidia TK1. I made an attempt on a snap gadget for the device and have created the model.json. But to make it into a image I need the gadget snap to be available. I'm on Ubuntu 16.04 (amd64) but the device I'm building for is armhf.  So I can't use the snap install --dangerous to install the gadget snap I need. How do I build the image on my arm64 workstation?
  <ogra_> skjensen, you need to use the ubuntu-image tool (theer is a snap with it) and use the --extra-snaps optin to point to your local gadget
  <ogra_> skjensen, https://docs.ubuntu.com/core/en/guides/build-device/image-building
  <skjensen> I did try that but with little luck..
  <ogra_> see part 3
  <ogra_> sudo ubuntu-image -c edge --extra-snaps /path/to/your/gadget.snap /path/to/your/model.assertion
  <skjensen> Still can't find it..
  <ogra_> whats the exact error ?
  <skjensen> skj@laptop:~/Documents/snap/TK1$ sudo ubuntu-image -c edge  --extra-snaps /home/skj/Documents/snap/TK1/tk1_16-0.1_armhf.snap /home/skj/Documents/snap/TK1/tk1.model
  <skjensen> error: cannot find snap "tk1_16-0.1_armhf": snap not found
  <skjensen> COMMAND FAILED: snap prepare-image --channel=edge --extra-snaps=/home/skj/Documents/snap/TK1/tk1_16-0.1_armhf.snap /home/skj/Documents/snap/TK1/tk1.model /tmp/tmp904xzqti/unpack
  <skjensen> and I have defined the gadget like this in the model.json file "gadget": "tk1_16-0.1_armhf",
  <ogra_> ah
  <ogra_> you just want the name in there
  <ogra_> "tk1"
  <ogra_> change that and re-create the assertion
  <skjensen> Yes, that's working.. :)
  <ogra_> ;)
  <skjensen> I had it with only the name to start with, but because it couldn't find it I changed to the complete name of the file..
  <skjensen> Okay, so far so good.. Now I need the kernel snap.. ogra, did you say I can use the bbb kernel?
  <ogra_> yeah "linux-generic-bbb" is the name ...
  <ogra_> though ubuntu-image might complain that this isnt a "canonical" package ... in that case use snap download oor grab it from https://code.launchpad.net/~snappy-dev/+snap/linux-generic-bbb/+build/76303 and use the --extra-snaps arg for it as well
  <skjensen> It found it correctly..
  <ogra_> cool
  <ogra_> i knoow there is some builtin policy that the owner of the gadget must match the owner of the kernel snap ... unless the kernel is owned by canonical ... seems we dropped it
  <skjensen> Nope.. you are right.. Just a delayed error message..
  <skjensen> error: cannot use kernel "linux-generic-bbb" published by "QfOqF7d2M1Pk2O0SbEKqTdB9Ry2aI0BP" for model by "bdSXYoRKHbnUgDeg0MU6rJIID8IODntX"
  <ogra_> so just pull it from the LP build page and use --extra-snaps
  <ogra_> that should ignore the requirement
  <skjensen> It's downloading.. :)
  <ogra_> (i hope)
  <skjensen> Me too.. Unfortunately I got to go pick up my son.. so will have to wait before I can test the image.. I'm right in saying I can flash this image to a SD card and boot from that?
  <ogra_> yes
  <ogra_> (if your booard generally can boot from SD indeed)
  <skjensen> It's one of it's best features, if there is a bootable SD card it will boot from that by default..
  <skjensen> Okay, I'm gone.. Thanks a lot for the help again.. :)
  <ogra_> then it shoould just woork (if your gadget is correct :) )
  <zyga-suse> ok, stuff is reabsed
  <zyga-suse> now to tie overlay mount entries to things that use them
  <zyga-suse> so that undo works :)
  <zyga-suse> come to think of it, I think it's actually easier than I thought
  <zyga-suse> perhaps we don't need to annotate overlays
  <zyga-suse> we can just keep them IFF there's anything mounted underneath
  <zyga-suse> so yeah, less patches needed :)
   * kalikiana  lunch time
  <Son_Goku> zyga-suse: overlays?
  <Son_Goku> are we using overlayfs now?
  <zyga-suse> well, I'm trying to
  <sergiusens> zyga-suse if you have a discussion on irc or a hangout the "minutes" for it at least should really make their way to the forum
  <sergiusens> kalikiana kyrofa elopio et. al. reminder I am out today
  <zyga-suse> sergiusens: are you referring to overlays or something else?
  <sergiusens> zyga-suse yes, but anything really needs to go there if it "matters"
  <sergiusens> kyrofa mind looking at snapcraft#1607 and snapcraft#1583 ? Those are yours and getting those failures out of the way would be great! ;-)
  <mup> PR snapcraft#1607: python plugin: use extracted pip <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1607>
  <mup> PR snapcraft#1583: ament plugin: new plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1583>
  <zyga-suse> yes, you are right; I wanted to describe this on the forum but I had a few crazy days and I spent most of the time on just coding this
  <zyga-suse> I'll write something now
  <Son_Goku> so for once, a feature that actually already has SELinux support :)
  <zyga-suse> Son_Goku: https://github.com/zyga/snapd/commit/f34aca5625013b3d02ee6dba384e9918770f94ef#diff-4480ffd44957efa3395867c929f88014R145
  <cachio> mvo, same error using devmode
  <cachio> to use gsettings
  <zyga-suse> cachio: any denials?
  <cachio> mvo, no
  <cachio> zyga-suse, I am using snap try
  <cachio> zyga-suse, could that affect?
  <Son_Goku> hmm
  <zyga-suse> yes, perhaps
  <kalikiana> kyrofa: mind taking another look at  snapcraft#1412 today? I hope I made it clearer now what's addressed there vs. the other PR
  <mup> PR snapcraft#1412: lxd: snapcraft refresh in containers <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1412>
  <kalikiana> kyrofa, elopio: also snapcraft#1627 should be fairly straight-forward. I'm splitting lxd.py into different classes/ files to make the code more maintainable. It's getting a bit unwieldy :-D so might even be better to get this in first, since it probably makes other PRs easier to review
  <mup> PR snapcraft#1627: lxd: split container classes into different files <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1627>
  <kyrofa> kalikiana, will do. Just want to fix my branches now that slow tests have landed etc.
  <zyga-suse> niemeyer: gentle ping about https://github.com/snapcore/snapd/pull/3958
  <mup> PR #3958: many: add support for /home on NFS <Created by zyga> <https://github.com/snapcore/snapd/pull/3958>
  <kalikiana> kyrofa: Aye, no rush. Let me know if you need another review from me there.
  <mvo> cachio: if you post your work-in-progress branch I can have a look
  <cachio> mvo, sure
  <cachio> mvo, this is the branch https://github.com/sergiocazzolato/snapd/tree/tests-interface-gsettings
  <kyrofa> Agh, test_list_plugins will be the death of me
  <cachio> niemeyer, I think the problem about the refresh core is that after I start the stable version I see https://paste.ubuntu.com/25773077/
  <niemeyer> zyga-suse: Ack
  <niemeyer> cachio: Looking
  <cachio> niemeyer, I am using the stable version from long time ago
  <niemeyer> cachio: Yeah, so exactly what we discussed
  <cachio> so it triggers a refresh to the current stable
  <cachio> reboots the device and then I start the tests
  <cachio> running against stable instead of using beta
  <niemeyer> cachio: Yeah.. it's a simple race with auto-refresh
  <niemeyer> cachio: As mvo predicted
  <cachio> niemeyer, I should wait until the autorefresh is done to trigger the refresh to beta
  <niemeyer> cachio: Yeah, that should work
  <cachio> niemeyer, nice, thanks for the support
  <niemeyer> cachio: np!
  <kyrofa> elopio, kalikiana I'm getting this a lot on the pip PR: https://travis-ci.org/snapcore/snapcraft/jobs/289625934
  <kyrofa> elopio, kalikiana have you guys seen that elsewhere?
  <kyrofa> It's definitely not my error, but it only surfaces when running pip stuff, which makes me think I'm doing something to surface it
  <kalikiana> kyrofa: Yeah, I've seen and mentioned that before... the answer I got in the past was "Re-run"...
  <kyrofa> kalikiana, oh really? Okay so maybe not this PR then
  <kyrofa> kalikiana, I wasn't seeing it elsewhere, so was starting to question myself
  <kalikiana> kyrofa: I try to add a comment these days quoting the last lines of such errors, so we can check other PRs for the same false negatives
  <kalikiana> Otherwise it really is difficult to keep track of
  <mvo> zyga-suse: fwiw, I can reproduce the issue the ePiere was describing, I think I have a test, my local spread is just unhappy, steps are pretty simple, will send via mail
  <mvo> zyga-suse: i.e. the error is: "cannot open current mount profile: ....fstab: permission denied"
  <mvo> zyga-suse: and I get an apparmor denied from /usr/lib/snapd/snap-confine
  <zyga-suse> mvo: aha
  <zyga-suse> mvo: right
  <zyga-suse> mvo: I'll check it out, let me look at the mail
  <mvo> zyga-suse: I have not written the mail yet
  <zyga-suse> mvo: if you have access to the shell there
  <zyga-suse> mvo: look at the profile in /etc/apparmor.d
  <zyga-suse> mvo: you can also collect the data about the loaded profile in sysfs
  <zyga-suse> mvo: can you paste the denial really quick please?
  <mup> PR snapd#4057 opened: interfaces: remove duplicated MockPlug/MockSlot helpers from interface tests <Created by stolowski> <https://github.com/snapcore/snapd/pull/4057>
  <pstolowski> zyga-suse, can you look at this trivial if you have a moment? ^
  <mvo> zyga-suse: http://paste.ubuntu.com/25773282/
  <zyga-suse> mvo: you can also poke at /sys/kernel/security/apparmor
  <zyga-suse> pstolowski: yes
  <mvo> zyga-suse: http://paste.ubuntu.com/25773287/ is the denial
  <zyga-suse> mvo: and the denial?
  <zyga-suse> ah
  <zyga-suse> oh
  <zyga-suse> mknod?
  <zyga-suse> that's odd
  <zyga-suse> that's totally unexpected
  <zyga-suse> can you run with SNAP_CONFINE_DEBUG=yes
  <mvo> zyga-suse: this is the strace (the last few lines) http://paste.ubuntu.com/25773303/
  <zyga-suse> open("/run/snapd/ns/snap.test-snapd-tools.fstab", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = -1 EACCES (Permission denied)
  <zyga-suse> mvo: that looks like a bug in apparmor
  <zyga-suse> mvo: we get open and mknod
  <zyga-suse> mvo: that doesn't make sense
  <mvo> zyga-suse: and http://paste.ubuntu.com/25773306/
  <zyga-suse> jdstrand: ^
  <zyga-suse> pstolowski: why do you want that change?
  <zyga-suse> pstolowski: I wanted it the other way around but I didn't find a way to do it
  <zyga-suse> pstolowski: now we're keeping more test-only code in the real package
  <zyga-suse> mvo: thinking
  <jdstrand> is there actually an *apparmor* denial?
  <zyga-suse> mvo: `    /run/snapd/ns/*.fstab rw,` is the rule that should allow the open
  <pstolowski> zyga-suse, cause I need two other Mock* helpers like that in my other branch, so I thought I'd go ahead and change existing ones to avoid duplication
  <jdstrand> http://paste.ubuntu.com/25773282/ doesn't show there is anything in syslog/journalctl
  <zyga-suse> [  290.377428] audit: type=1400 audit(1508427272.862:36): apparmor="DENIED" operation="mknod" profile="/usr/lib/snapd/snap-confine" name="/run/snapd/ns/snap.test-snapd-tools.fstab" pid=4066 comm="snap-confine" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
  <zyga-suse> jdstrand: it's a separate pastebin
  <jdstrand> ok, yes, I see that
  <zyga-suse> pstolowski: can you make it so that we call one of the mock from the other and still use the test package rather than the main package?
  <zyga-suse> mvo: I don't have any theory yet
  <pstolowski> zyga-suse, i'm not totally clear on what do you mean? you don't want builtin.Mock*?
  <zyga-suse> pstolowski: no, I don't want builtin.Mock
  <zyga-suse> pstolowski: we can keep the mock in test-only code
  <zyga-suse> pstolowski: but becase we cannot do that yet there are two copies of the code
  <jdstrand> mvo: are you sure that the .real is what is being used and not snap.core....
  <zyga-suse> pstolowski: I was thinking one could call the other
  <zyga-suse> mvo: are there .real and plain profiles?
  <pstolowski> zyga-suse, ah, that. let me see
  <zyga-suse> pstolowski: and in general we should perfer test package to the main package
  <zyga-suse> pstolowski: thank you!
  <jdstrand> mvo: you pasted 'cat /etc/apparmor.d/usr.lib.snapd.snap-confine.real'
  <mvo> jdstrand, zyga-suse http://paste.ubuntu.com/25773336/
  <zyga-suse> mvo: (I mean are there both)
  <zyga-suse> mvo: good
  <mvo> zyga-suse, jdstrand so that is the only apparmor profile for snap-confine (this is on a core system)
  <jdstrand> mvo: what kernel are you using?
  <zyga-suse> yeah, my question exactly
  <jdstrand> cat /proc/version_signature
  <mvo> jdstrand: http://paste.ubuntu.com/25773342/
  <zyga-suse> mvo: that product may have a different kernel snap
  <zyga-suse> mvo: but I assume you have done this on generic
  <zyga-suse> aha
  <mvo> jdstrand: http://paste.ubuntu.com/25773346/
  <mvo> yeah, this is a stock (spread) core VM
  <zyga-suse> mvo: at this time I'd collect verbose apparmor debug data
  <zyga-suse> mvo: can you look at /sys/kernel/apparmor
  <mvo> zyga-suse: sure, what do I need to do ?
  <zyga-suse> mvo: and collect (cat + redirect) the profile for snap-confine
  <zyga-suse> just a moment
  <zyga-suse> cd /sys/kernel/security/apparmor
  <zyga-suse> cd policy/profiles
  <jdstrand> mvo: what if you downgrade the kernel to stable
  <zyga-suse> cd usr.lib.snapd.snap-confine.*
  <zyga-suse> mvo: collect everything there
  <zyga-suse> mvo: note that tar is silly and gets empty files
  <zyga-suse> you need a dumb cp -R copy
  <zyga-suse> then tarball
  <zyga-suse> then please send/attach that
  <zyga-suse> I'll have a look
  <zyga-suse> if you could, save the snap_confine profile text as well
  <zyga-suse> verbatim as it appears for you
  <zyga-suse> I know you pastebinned it but if it's in the same tarball it's more convenient
  <zyga-suse> mvo: after that you can experiment in any way, change the kernel as jdstrand suggeste
  <zyga-suse> *suggested, perhaps
  <mup> PR snapd#4057 closed: interfaces: remove duplicated MockPlug/MockSlot helpers from interface tests <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/4057>
  <mvo> zyga-suse: on the way via mail
  <mvo> zyga-suse: jdstrand going to the stable kernel now and trying it again
  <zyga-suse> thank you
  <jdstrand> mvo: you said this is part of spread. what test?
  <pstolowski> zyga-suse, I can make the Mock* method from tests call the one from builtin, so we get rid of duplicated body, a little win..
  <mvo> jdstrand: its a new spread test I'm currently working on. we got a report from CE QA about this issue
  <jdstrand> I see a test for that file in  tests/main/snap-discard-ns, but that wouldn't be confined since calling snap-discard-ns directly...
  <pstolowski> but not the other way around
  <zyga-suse> pstolowski: yeah, that's good
  <zyga-suse> pstolowski: little by little :)
  <mvo> jdstrand: and we have no test yet that checks snap refresh stable->edge and revert back
  <pstolowski> ok..
  <mvo> jdstrand: fwiw, stable kernel shows the same message
  <jdstrand> mvo: how can I reproduce?
  <jdstrand> mvo: do you have a branch somewhere?
  <jdstrand> mvo: what is it that you are reverting btw?
  <mvo> jdstrand: I reverted core
   * jdstrand wonders if it is a timing issue
  <mvo> jdstrand: one sec, I'm writing a mail and will CC you
  <jdstrand> eg, if the policy gets updated but the snap-confine binary does not...
  <jdstrand> (eg, as part of the revert)
  <mup> PR snapd#4058 opened: interfaces: reduce duplicated code in interface tests mocks <Created by stolowski> <https://github.com/snapcore/snapd/pull/4058>
  <jdstrand> fwiw, I would be surprised if there is a bug in apparmor for file mediation. I am not saying it isn't possible, but I would expect we would see a ton more issues if there was
  <pstolowski> zyga-suse, ^
  <zyga-suse> jdstrand: yes, it's a bit mysterious why this happens
  <zyga-suse> jdstrand: remember when we once saw a case of apparmor profile staying stale after being loaded?
  <zyga-suse> mvo: is this reproducible or did you just get it once and didn't try again?
  <jdstrand> if it happens as a result of reverting core, I suspect we are loading the policy from the reverted core but using the snap-confine binary from the unreverted core, or something similar
  <zyga-suse> pstolowski: +1
  <zyga-suse> jdstrand: but note that on core we reboot and we don't have any core-derived profiles
  <pstolowski> tx
  <zyga-suse> mvo: maybe one more sanity check
  <jdstrand> I bet it is the cache file then
  <mvo> zyga-suse: I rebooted at least twice, manually loaded the profile to double check, definitely reproducible for me. but I have not done a full scenario yet
  <zyga-suse> mvo: reload that profile from disk
  <zyga-suse> mvo: and see if the data in sysfs changes
  <zyga-suse> mvo: and if the error goes away
  <zyga-suse> jdstrand: yes, that's a good idea
  <zyga-suse> mvo: hold on, you reloaded the profile manually and it still failed?
  <jdstrand> eg, boot into current core, generate the cache. reboot into an older core, the mtime check is older than the previous cache file
  <mvo> zyga-suse: apparmor_parse -r /etc... ? I did that, same failure
  <zyga-suse> mvo: yes
  <zyga-suse> holly molly
  <jdstrand> I need a reproducer
  <jdstrand> I strongly suspect there is something along these lines
  <mvo> jdstrand: what file is the cache? I think your theory is correct
  <zyga-suse> mvo: /var/cache/apparmor I think
  <mvo> jdstrand: I can touch the file and see
  <zyga-suse> mvo: for that file
  <jdstrand> /etc/apparmor.d/cache
  <mvo> zyga-suse: cool, let me try that
  <zyga-suse> jdstrand: oh, sorry
  <jdstrand> /var/cache/apparmor is for snaps. /etc/apparmor.d/cache is for system
  <mup> PR snapcraft#1591 closed: snapd integration tests: print stdout/stderr <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1591>
  <mvo> jdstrand: http://paste.ubuntu.com/25773431/ <- looks suspcious
  <jdstrand> mvo: a better test might be to rm -f /etc/apparmor.d/cache/usr.lib.snapd.snap-confine* before the reboot
  <zyga-suse> september 27th?
  <zyga-suse> wat?
  <jdstrand> mvo: exacctly
  <mvo> jdstrand: if I remove the cache file and reload the profile things are ok.
  <zyga-suse> the cache looks good though
  <jdstrand> ok
  <jdstrand> so, I think the revert needs to remove the cache file unconditionally
  <zyga-suse> mvo: is that september 27th the moment when the profile was loaded?
  <zyga-suse> er
  <zyga-suse> when the image was built
  <mvo> zyga-suse: yes
  <jdstrand> it'll be regenerated on reboot
  <zyga-suse> jdstrand: when is the cache not used?
  <jdstrand> it's always used as part of boot
  <zyga-suse> always even if stale?
  <zyga-suse> is there any staleness check?
  <jdstrand> no
  <jdstrand> yes
  <jdstrand> it doesn't use a stale cache. it has a check. it will regenerate it if stale
  <zyga-suse> what is the condition?
  <jdstrand> the problem is it doesn't look stale
  <jdstrand> mtime
  <mvo> could we rework the cache? I remember we had issues with this before, I vaguely remember some discussion to move to md5sum/sha1 or similar for cache comparing
  <zyga-suse> aha
  <zyga-suse> I see
  <jdstrand> the cache file is always going to be newer than the reverted core's profile
  <zyga-suse> jdstrand: I think this will explain what I saw earlier as well
  <zyga-suse> jdstrand: the issue that federico ran into right in front of my eyes
  <jdstrand> mvo: just remove the cache files on revert
  <zyga-suse> jdstrand: all of them? /var/cache/apparmor /etc/apparmor/cache ?
  <jdstrand> that is the fast and correct fix for today. if want to use checksums, that could come later
  <jdstrand> no
  <jdstrand> we are talking about snap-confine. just remove the /etc/apparmor.d/cache/*snap-confine* profiles on core revert
  <mvo> jdstrand: I just found something, it makes me weep a bit
   * zyga-suse hugs mvo and is curious to know
  <mvo> jdstrand: https://bugs.launchpad.net/snappy/+bug/1460152
  <mup> Bug #1460152: apparmor cache not updated when apparmor.d rules change (breaks 15.04/stable -> 15.04/edge updates) <patch> <Snappy:Fix Released by mvo> <Snappy 15.04:Fix Released by mvo> <apparmor (Ubuntu):Fix Released> <https://launchpad.net/bugs/1460152>
  <zyga-suse> oh my https://code.launchpad.net/~mvo/ubuntu/vivid/ubuntu-core-config/lp1460152-workaround/+merge/261179
  <zyga-suse> mvo: we barely notice this bug because the profile for snap-confine rarely changes in ways that newer revision can do *less* than the older revision
  <zyga-suse> mvo: where shall we change this?
  <zyga-suse> mvo: in request snapd restart?
  <zyga-suse> mvo: or in the apparmor backend?
  <zyga-suse> mvo: we could purge the cache whenever core is installed
  <zyga-suse> mvo: just in case
  <zyga-suse> jdstrand: is the apparmor cache location the same in various distros?
  <jdstrand> in thinking about this, on core, should rm -rf /etc/apparmor.d/cache/*
  <jdstrand> on refresh/revert of the core snap
  <zyga-suse> jdstrand: yeah, because new policy can be inside and we won't know
  <jdstrand> zyga-suse: we are talking about Ubuntu Core here. on classic, re-exec solves all this ith per-revision profiles
  <jdstrand> so on Ubuntu Core, we can depend on /etc/apparmor.d/cache
  <zyga-suse> jdstrand: yes, but what about !snap-confine profiles?
  <zyga-suse> jdstrand: well, we ge-gen those on startup now
  <jdstrand> what about them?
  <zyga-suse> jdstrand: I think you are right, those are fine
   * jdstrand is confused. I thought we were talking about snap-confine
  <zyga-suse> jdstrand: yes but I was thinking that the cache issue may affect other profiles too
  <zyga-suse> jdstrand: but I agree with you that it is just for this single profile
  <jdstrand> snap profiles?
  <mvo> jdstrand: what was the downside of https://bugs.launchpad.net/snappy/+bug/1460152/+attachment/4409034/+files/lp1460152-apparmor.diff  ? this syncs mtime of profile and cache, if there is a difference we re-generate. cheap and (at first glance) reliable, no?
  <mup> Bug #1460152: apparmor cache not updated when apparmor.d rules change (breaks 15.04/stable -> 15.04/edge updates) <patch> <Snappy:Fix Released by mvo> <Snappy 15.04:Fix Released by mvo> <apparmor (Ubuntu):Fix Released> <https://launchpad.net/bugs/1460152>
  <jdstrand> no-- cause of the overlord or whatever making sure if they are different they are regenerated
  <elopio> kyrofa: sorry, I didn't see the error and now that link is an execution in progress.
  <mvo> jdstrand: I can prepare something that "rm -rf /etc/apparmor.d/cache/* on core devices when the core snap changes. but I still would to discuss how to make apprmor itself more reliable here"
  <elopio> kyrofa: when I get repeated errors, I report them in a bug even if it's not clear if they are snapcraft's fault.
  <kyrofa> elopio, good idea. I'll do that again if I see it
  <mvo> jdstrand: if you think the syncing is ugly, just embedding the timestamp of the source file in the cache is also super cheap or putting an .aux file next to it with the timestamp
  <jdstrand> mvo: the downside is that apparmor would need an SRU everywhere. that will be too slow for you
  <mvo> jdstrand: *cough* dput ppa:snappy-dev/image apparmor_13371+ppa1_source.changes. problem solved until the SRU is in
  <mvo> jdstrand: it seems more correct to me and I'm happy to give it a shot
  <jdstrand> mvo: I'll defer to jjohansen on the best approach. It looks like he started to pick up that work
  <jdstrand> mvo: you know I very much hate that :P
  <jdstrand> mvo: I would very much prefer to not be ahead of upstream apparmor on this point
  <kyrofa> elopio, is snapcraft#1629 good to go?
  <mup> PR snapcraft#1629: lxd: fix the unit test for the user id map <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1629>
  <elopio> yes, it even got a green autopkgtest execution
  <zyga-suse> mvo: so we need a .6?
  <mvo> jdstrand: thats ok, I can do both: add code to snapd and poke at apparmor (or poke you guys to do that)
  <zyga-suse> mvo: I think we need a .6 :/
  <mvo> zyga-suse: no, not a regression
  <zyga-suse> mvo: it breaks revert
  <zyga-suse> mvo: CE won't like that
  <kyrofa> elopio, excellent, I'm merging it. So tired of bad autopkgtests
  <mvo> zyga-suse: but its stable->edge so far, no?
  <zyga-suse> no, this is ever since we have snap-update-ns
  <elopio> thanks kyrofa.
  <mvo> zyga-suse: if its old-stable->stable thats different
  <zyga-suse> mvo: hmmmm
  <jdstrand> mvo: note that we are probably going to do an apparmor SRU for the af_unix issue, so maintaining an extra apparmor in a ppa makes that more complicated
  <zyga-suse> not sure
   * zyga-suse looks
  <jdstrand> mvo: yes, rm -rf in PR +1. working with upstream on better parser +1
  <mvo> jdstrand: my suggestion about the ppa is only to quicken the sru process, i.e. we would not maintain something, we would just upload something that you guys have already in the upstream git
  <mvo> jdstrand: let me know if I can help, happy to poke at this again, the fact that I worked on this 2y ago and it came back indicates to me that I don't want to do this again in 2y :/
  <jdstrand> mvo: right, but then we'd need to remember to include that in the SRU so it isn't dropped
  <mvo> jdstrand: agreed
  <jdstrand> I'm not saying it isn't impossible or anything, just, we need to think through coordination, etc
  <mvo> jdstrand: as long as we have a regression test in our tree things should be ok.
  <mup> PR snapcraft#1629 closed: lxd: fix the unit test for the user id map <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1629>
  <zyga-suse> mvo: dccfcb26c5fe59fb259a800a22208f355e79d6bd is the patch that changes the policy
  <jdstrand> mvo: looking at trunk, it seems like there were commits related to this
  <zyga-suse> mvo: I don't see it in 2.28 release branch
  <zyga-suse> mvo: so I think it's looking like a quiet weekend
  <mvo> zyga-suse: :)
  <mvo> zyga-suse: yay, big hugs to the CE QA team then
  <jdstrand> mvo: with a regression fix: https://bugs.launchpad.net/apparmor/+bug/1484178
  <mup> Bug #1484178: Policy cache file mtimes are not being set correctly <AppArmor:Fix Released by tyhicks> <apparmor (Ubuntu):Fix Released by jdstrand> <https://launchpad.net/bugs/1484178>
  <jdstrand> mvo: so it looks like a version of your patch made it in, but "Starting in AppArmor 2.10, the policy cache file's mtime was meant to be updated to be equal to the newest mtime detected on the profile and abstraction files used to generate the policy cache file"
  <jdstrand> mvo: this was something I was trying to think through. the include files are going to be a problem on revert
  <jdstrand> I think
  <jdstrand> so the parser is supposed to use the newest value of mtime between the profile and include files
  <tyhicks> that's correct
  <jdstrand> so if /etc/apparmor.d/tunables/global is newer than /etc/apparmor.d/*snap-confine*, the mtime of global will be used for the cache
  <jdstrand> if we revert but global did not change, then the mtime will be the same and the cache won't be stale
  <kyrofa> kalikiana, snapcraft#1412 has conflicts
  <mup> PR snapcraft#1412: lxd: snapcraft refresh in containers <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1412>
  <tyhicks> jdstrand: sounds like the cache read should be skipped in such a situation
  <tyhicks> the '--skip-read-cache' option of apparmor_parser
  <jdstrand> tyhicks: which part are you talking about?
  <jdstrand> tyhicks: in snapd on refresh/revert?
  <tyhicks> jdstrand: yes
  <jdstrand> for core
  <tyhicks> yes
  <jdstrand> that would work too, but having the stale cache files around seems wrong too
  <jdstrand> so long as we use --write-cache, that would be ok
  <tyhicks> jdstrand: you're talking about stale cache files for app snaps?
  <zyga-suse> the parser could unlink them
  <jdstrand> tyhicks: no, snap-confine
  <jdstrand> zyga-suse: I don't think the parser is the place to do this. it is doing what everyone asked
  <jdstrand> it still has a concept of 'newer'
  <jdstrand> in terms of what it is including. if there is a concept of 'newer' then reverts are problematic to handle in the parser itself
   * zyga-suse feels that cache in apparmor is not as transparent as it should and needs hand-holiding
   * mvo dinner
  <jdstrand> tyhicks: the problem is on core revert, the newer cache file is still used but with an older snap-confine. that broke things
  <mvo> yeah, I think hashes or list of mtimes of the inputs would be more reliable
   * mvo vanishes
   * zyga-suse too
  <jdstrand> mvo: if you recall from the bug, hashes will slow things down
  <tyhicks> jdstrand: how about simply updating the mtime of the profile on revert?
  <jdstrand> tyhicks: that could work too
  <jdstrand> tyhicks: well, no. it is in rofs
  <tyhicks> imo, that's what needs to happen
  <tyhicks> oh
  <jdstrand> /etc/apparmor.d is read-only. /etc/apparmor.d/cache is rw
  <jdstrand> mvo: the cache is meant to be pretty much as fast as you can read them off the disk. if we add hashes, consider hundreds or more profiles
  <mvo> jdstrand: if hashes are slow we could store the [(input1,mtime1),...(inputN,mtimeN)] and compare those, that should be quick
  <zyga-suse> jdstrand: out of my PRs I'd like your review on https://github.com/snapcore/snapd/pull/4008 -- it's long but most of that is tests
  <mup> PR #4008: cmd/snap-update-ns: create missing mount points automatically <Created by zyga> <https://github.com/snapcore/snapd/pull/4008>
  <zyga-suse> jdstrand: it contains go's version of mkpath
  <jdstrand> zyga-suse: it is already on my list. I'll put it towards the top. I've seen commits as recent as today-- is it ready for another review?
  <zyga-suse> jdstrand: freeze/thaw logic that's new
  <mup> PR snapd#4059 opened: tests: add test that checks core reverts on core devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/4059>
  <mvo> jdstrand: please don't get me wrong, I don't want to be pushy or anything, happy to help wit hthis stuff. but dinner now really :)
  <jdstrand> mvo: that would require changes to the format on disk and thus require jjohansen's input
  <zyga-suse> jdstrand: and small glue that uses mkdir when we want to mount something but target is gone
  <kyrofa> elopio, will python3 -m unittest discover -b -v -s integration_tests" not run _all_ the integration tests, including the packages below?
  <zyga-suse> jdstrand: there's loads of unit tests and one comprehensive integration test
  <elopio> Not until tomorrow
  <kyrofa> elopio, isn't that how discover works?
  <jdstrand> mvo: checking and comparing the mtimes of everything is likely performant enough. I'm not sure of other ramifications. maybe it makes sense to bring up on the apparmor ML?
   * jjohansen reads backscroll to pickup context
  <tyhicks> jjohansen: don't spend time reading all of backscroll
  <tyhicks> jjohansen: I'll summarize
  <elopio> kyrofa: I'm moving some integration tests to a general suite, so we can properly filter.
  <zyga-suse> jjohansen: hey, long time no see :)
  <jdstrand> zyga-suse: I think I heard "yes, it is ready for you to review"?
  <jjohansen> hi zyga-suse
  <zyga-suse> jdstrand: hmm?
  <zyga-suse> jdstrand: I think it's ready now
  <zyga-suse> jdstrand: NB, this is the code without any overlayfs
  <jdstrand> 11:42 < jdstrand> zyga-suse: it is already on my list. I'll put it towards the op. I've seen commits as recent as today-- is it ready for another review?
  <zyga-suse> jdstrand: so should be non-controversial
  <zyga-suse> jdstrand: ah, I didn't notice
  <kyrofa> elopio, ah, integration_tests/snapd, integration_tests/store etc. aren't packages, I see
  <elopio> kyrofa: at some point, somebody, probably not me but maybe... removed the init.py from some subdirs, so they are not discovered.
  <zyga-suse> jdstrand: it's ready, the code today was more tests and shrinking the diff for next PRs
  <kyrofa> elopio, gotcha
  <tyhicks> jjohansen: on snap revert, snapd is rolling back profiles to old versions but there could be an include file that is newer so the mtime of the policy cache file isn't updated and the old cache file is loaded
  <jdstrand> zyga-suse: ok
  <niemeyer> zyga-suse: You've got a review
  <zyga-suse> niemeyer: thank you
  <niemeyer> zyga-suse: Thanks for the PR!
  <elopio> kyrofa: I'm moving everything around to make the split for Travis a little less painful.
  <niemeyer> zyga-suse: Ah, one more note, can we please drop the "generated-" prefix and use something more contextual?
  <niemeyer> zyga-suse: Every profile we have is generated
  <tyhicks> jjohansen: apparmor's policy cache implementation assumes that mtimes should only ever go forward but that's not the case when reverting back to older, read-only versions of a profile
  <jdstrand> tyhicks: that summarizes things ok, but more precisely, it is core snap revert, which includes system profiles in /etc/apparmor.d. non-core snap profiles are not affected because of how snapd manages them. there is an interplay with the /etc/apparmor.d profiles and the init script that is causing trouble
  <zyga-suse> niemeyer: whatever we want, we just need to have a prefix
  <tyhicks> jdstrand: sure but jj doesn't need that info
  <niemeyer> zyga-suse: What's common across all of the files?
  <tyhicks> at least, I didn't think he did :)
  <zyga-suse> niemeyer: so far we only have one file
  <jdstrand> tyhicks: I thought the system profile point was important, but ok
  <zyga-suse> niemeyer: but the theme is "local tweaks to work around something"
  <niemeyer> zyga-suse: How about nfs then?
  <niemeyer> zyga-suse: Or perhaps...
  <jjohansen> tyhicks: ? ah, so what you want is the hashing consistency check
  <zyga-suse> niemeyer: we need a glob to match the set we manage, we can juse use `*`
  <zyga-suse> niemeyer: then we can drop generated-
  <niemeyer> zyga-suse: If it's just one file, it'd be better to use that one file instead
  <jjohansen> which we started on ages ago, and never finished because its priority was dropped
  <jdstrand> jjohansen: I think what mvo wants is that if the profile or any included files are different, then regenerate the cache. how that is done I don't think he cares
  <tyhicks> jjohansen: I'm not asking for that but the snapd folks want something along those lines or for a list of profile and include file mtimes to be stored alongside the policy cache file
  <niemeyer> zyga-suse: nfs-support is a good name for the file
  <zyga-suse> ok
  <zyga-suse> I'll review the review comments and tweak this, I think it should land tomorrow
  <niemeyer> zyga-suse: The file is included/imported by name, right, not by glob?
  <zyga-suse> niemeyer: no
  <zyga-suse> niemeyer: everything in the directory is imported
  <zyga-suse> niemeyer: apaprmor includes are recursive
  <niemeyer> zyga-suse: Oh?
  <jdstrand> jjohansen: I speculated in the old bug that prompted the setting of mtime of the cache to that of the newest file patch that a hash of everything would be slow, so people thought about storiing of the list of all the mtimes and comparing those
  <niemeyer> zyga-suse: Okay, so the glob needs to be * indeed
  <jjohansen> jdstrand: well, its either store everything and compare. Or a hash and compare
  <niemeyer> Otherwise we may be including things we have no idea about
  <jdstrand> jjohansen: right
  <tyhicks> jjohansen: I'm currently of the opinion that snapd is subverting the policy cache, out from under apparmor_parser, and should be smart enough to use --skip-read-cache when appropriate
  <tyhicks> jdstrand: we could hash all the mtimes instead of hashing the profiles and include files themselves
  <jdstrand> it is true that snapd is moving forward and backward in time in arbitrary ways with the concept of revert
  <jdstrand> tyhicks: that's interesting
  <jjohansen> jdstrand: the hashing isn't that slow when you realize we read in those files already anyways, because we the time comparison is in the parse
  <tyhicks> and it doesn't have to be an cryptographic hash
  <jjohansen> right
  <kyrofa> snappy-m-o, autopkgtest 1627 xenial:amd64
  <snappy-m-o> kyrofa: I've just triggered your test.
  <jjohansen> I believe I was using murmer hash3, which is faster than a crypto hash but still fairly good
  <jdstrand> jjohansen: did you profile its performance?
  <tyhicks> jjohansen: I used djb2 for my old multiple policy cache implementation
  <jjohansen> jdstrand: it was never completed to the point where performance could be checked, but it should be at least a couple order of magnitudes faster than the disk read
  <jdstrand> cause while this is prompted by the system cache and the system profile in ro media, if we introduce a hash check I would expect it to be used for all profile loads (where we are considering the use of the cache), which could easily be hundreds of profiles
  <jjohansen> so I expect you won't even notice it
  <jjohansen> jdstrand: right, which brings us to another optimization that has never been finished. Calling the parser once with all the profiles to load and caching each file once (which means hashing them once)
  <jdstrand> just so it is understood why a crypto hash is not required, the idea is that if you can modify the files in /etc/apparmor.d{,/cache} to create a collision, you may as well just change them
  <tyhicks> jdstrand: speed is the #1 reason followed by what you just said
  <jdstrand> jjohansen: that would be quite nice since we are using templates, etc (we could actually optimize what snapd does to leverage that even more when the feature was there). I'm guessing that is quite far out though
  <jjohansen> jdstrand: we are hardening against an attack, this is just an optimization, and detecting files changes. A good hash makes that almost guarenteed
   * zyga-suse cannot find any bug reports about NFS and apparmor 
  <jjohansen> a crypto hash would make the odds against an accidental collision even better, but for this, not worth the cost
  <tyhicks> if we do hashing, I'd think that we would want to use something very fast (djb2/murmur) and also continue to check the most recent mtime (like what we're doing today) to slightly reduce the chance of a collision under normal usage (doesn't help with snapd's revert situation)
  <jdstrand> right, I understand the reasoning, I just wanted it explicitly stated for posterity :)
  <jjohansen> zyga-suse: oh they have happened in the past, but you may need to file a new one. I am not sure there are any in launchpad, perhaps suse bugzilla
  <jdstrand> zyga-suse: let me check. I thought there was one
  <zyga-suse> jjohansen: aha, I'll look at suse then
  <zyga-suse> thank you!
  <jjohansen> tyhicks: yep that was the plan
  <zyga-suse> I looked at apparmor on LP and general google
  <tyhicks> jjohansen: do you agree that we just hash the mtimes rather than the file contents?
  <jjohansen> zyga-suse: I remember something around 2004-2006, can't remember the details, tony dealt with it
  <jjohansen> tyhicks: uh no
  <jdstrand> zyga-suse: I think I was only thinking of https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662552, which you are familiar with
  <mup> Bug #1662552: snaps don't work with NFS home <snapd:In Progress by zyga> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1662552>
  <jjohansen> tyhicks: we can consider it, but its not something I have spent enough time with to agree
  <zyga-suse> hmm, it feels I should file a new bug on apparmor specifically
  <jjohansen> zyga-suse: please do
  <jdstrand> tyhicks, jjohansen: to be clear, this conversation is about a proper solution. mvo and the snapd team will implement something to work with what is currently there (maybe --skip-read-cache, maybe rm -f of the cache files, etc)
  <tyhicks> jdstrand, jjohansen: I think that this was a useful technical deep dive but we don't currently have plans to work on this for 18.04
  <jdstrand> mvo: ^
  <zyga-suse> jjohansen: https://bugs.launchpad.net/apparmor/+bug/1724903
  <mup> Bug #1724903: NFS access is not transparent to processes with apparmor profile containing network rules <AppArmor:New> <https://launchpad.net/bugs/1724903>
  <zyga-suse> jjohansen: if you have insight into how this works and why the workaround is needed could you pleaseadd it there
  <zyga-suse> I'm only aware of the surface of the issue
  <jjohansen> zyga-suse: hrmmm, my guess is because nfs is using the task asking the files cred instead of a kernel cred via the act as cb when doing the network stuff. But I will have to actually dig into it to be sure
  <jjohansen> zyga-suse: how about I distract you with the fedora kernel I gave stgraber instead ;)
  <zyga-suse> jdstrand: :D
  <zyga-suse> fedora kernel?
  <stgraber> :)
  <zyga-suse> jjohansen: note that that was just a gentle idea, I don't want you to drop what you are doing and work on that bug :)
  <jjohansen> hence the distraction to keep you occupied, so you don't realize I haven't worked on the bug :)
  <zyga-suse> I think I need to EOD now, kids are running unchecked here and I bet they have homework :)
  <mvo> jdstrand, tyhicks would you accept patches if there is agreement about the approach?
  <tyhicks> mvo (cc jjohansen): definitely :)
  <mvo> tyhicks: cool! and agreement is fast-hash+mtime? (cc jjohansen)?
  <jjohansen> zyga-suse: yes fedora kernel, its stack apparmor and selinux
  <jjohansen> mvo: give me a minute
  <mvo> jjohansen: sure :)
  <zyga-suse> jjohansen: oh, shiny!
  <zyga-suse> jjohansen: do you have RPM?
  <jjohansen> zyga-suse: for the kernel only atm
  <jjohansen> zyga-suse: http://people.canonical.com/~jj/fedora/
  <stgraber> jjohansen: one thing that was mentioned last week is that we could probably call the apparmor tools from within the core snap
  <zyga-suse> jjohansen: 1.1G?
  <jjohansen> give me a minute and I can send you an email with some instructions
  <stgraber> jjohansen: at which point we'd only really need apparmor support in the kernel, everything else would be coming from the core snap
  <jjohansen> zyga-suse: its all the rpms from the kernel build
  <jjohansen> stgraber: yep that is a possibility, just wanted to make sure zyga-suse understood there is no apparmor userspace rpm atm
  <zyga-suse> jjohansen: ack, I understand
  <cachio> niemeyer, is it any way to stop the auto-refresh?
  <kyrofa> cjwatson, any chance you're still around?
  <cjwatson> kyrofa: about to finish.  what is it?
  <kyrofa> cjwatson, quick question
  <Pharaoh_Atem> jjohansen: what is this?
  <kyrofa> cjwatson, back when we were discussing the `architectures` key at the sprint, we settled on using the grammar we already have
  <kyrofa> cjwatson, but this is something LP will need to parse
  <kyrofa> cjwatson, we discussed your using the grammar processing we already wrote, and I'd like to quickly discuss how you'd like to consume that
  <cjwatson> kyrofa: and I think what Sergio (or you?) said was that the relevant bit of the parser would be made available on PyPI as a thing we could use
  <Pharaoh_Atem> jjohansen: it's 1.1GB!
  <jjohansen> Pharaoh_Atem: development work towards LSM stacking, which will allow for multiple LSMs on a system at once. So if enabled, apparmor based snaps would work (in enforcing, not dev mode) on an selinux fedora
  <jjohansen> or you could use and Ubuntu container with apparmor on an selinux fedora
  <jjohansen> etc
  <kyrofa> cjwatson, that was my question: is that best for you? Or do you simply want it as part of the public API in snapcraft so you can import it, etc.
  <jjohansen> Pharaoh_Atem: its all the kernel rpms from a kernel build, you don't need all of them, just like an ubuntu kernel build you get lots of different debs out, but only need 1 or 2 for most things
  <cjwatson> kyrofa: PyPI would be much better for us; recall that LP is running in fairly tightly-controlled environments.
  <kyrofa> cjwatson, yep, good deal, that's all I needed! Just planning out tasks
  <kyrofa> cjwatson, thank you :)
  <cjwatson> kyrofa: And while we do still consume a few Python packages from the system, we want to move away from doing that.
  <Pharaoh_Atem> jjohansen: does someone want to start talking to the Fedora kernel team about this?
  <Pharaoh_Atem> because this is not something to enable lightly
  <Pharaoh_Atem> jjohansen: where's the src.rpm?
  <kyrofa> cjwatson, makes sense
  <jjohansen> Pharaoh_Atem: no, none of its upstream, its a work in progress. The selinux people are aware of it, we have been discussing LSM stacking for 5 years, slowly working towards it
  <jjohansen> Pharaoh_Atem: hrmm, if its not in the tarball then the build must have dropped it in a different location
  <Pharaoh_Atem> it's in SRPMS in the rpmbuild/ tree
  <jjohansen> I tared up the build dir
  <Pharaoh_Atem> looks like you archived rpmbuild/RPMS/*
  <Pharaoh_Atem> but not rpmbuild/SRPMS/*
  <jjohansen> Pharaoh_Atem: ack, so a different location, I didn't check, and its been a long time since I have dealt with rpm packaging
  <Pharaoh_Atem> jjohansen: you should get out more ;)
  <jjohansen> this was a quick one off for a demo, it wasn't meant for public consumption
  <jjohansen> well general public, people are welcome to play but I haven't even put together a good list of instructions
  <Pharaoh_Atem> jjohansen: feel free to set up something on https://copr.fedorainfracloud.org/
  <Pharaoh_Atem> it's not particularly hard ;)
  <jjohansen> the plan was to fix some bugs, and make the git tree public, along with some instructions
  <zyga-ubuntu> jjohansen: I can help
  <Pharaoh_Atem> the only thing I'm not particularly happy about is that the LSM stacking doesn't help anything for RHEL/CentOS users
  <jjohansen> zyga-ubuntu: thanks for the offer, I will take you up on it, but it will be a few days before I can get back to playing with this
  <Pharaoh_Atem> as in, even if we got AppArmor enabled in Fedora, and had the userspace utilities packaged (not particularly difficult), it won't help for RHEL/CentOS users who use the RHEL kernel
  <zyga-ubuntu> Pharaoh_Atem: we won't necessairly have to package them
  <Pharaoh_Atem> zyga-ubuntu: trust me, that *will* be a requirement of the kernel team
  <jjohansen> Pharaoh_Atem: hrmm, maybe apparmor was enabled in at one of those at one point. not default, and not supported but enabled
  <jjohansen> s/enabled/compiled in/ so some one could set it on the grub kernel line
  <Pharaoh_Atem> jjohansen: it's not currently enabled in the Fedora kernel or the RHEL7 kernel
  <Pharaoh_Atem> as in, not compiled in at all
  <Pharaoh_Atem> zyga-ubuntu: it's not an unreasonable requirement to package and maintain the userspace for AppArmor
  <jjohansen> Pharaoh_Atem: yep, that may change. stgraber did a demo of an ubuntu container running on fedora with selinux enforcing the host and apparmor the guest
  <jjohansen> being able to fully support other OS containers is a compelling use case
  <Pharaoh_Atem> well, LXD will be fine with SELinux across the board
  <Pharaoh_Atem> I fixed the SELinux policy to add the LXD binaries, so now LXD just has to use it
  <Pharaoh_Atem> jjohansen: most people are fine with security systems being disabled
  <Pharaoh_Atem> and historically, it's been a huge burden to be an AppArmor user
  <Pharaoh_Atem> though hopefully that is changing with the more upstream-y policy of AppArmor team
  <skjensen> Any where I can find the source for building this kernel? https://code.launchpad.net/~snappy-dev/+snap/linux-generic-bbb/+build/76303  Downloading it and using it as an extra snap still give me the with different signatures on the kernel and gadget.. :(
  <Pharaoh_Atem> so at some point soon, kyrofa and zyga-ubuntu will work with the lxd copr packager to bring those into Fedora mainline
  <cjwatson> kyrofa: (BTW I don't particularly object if this is a matter of dumping snapcraft onto PyPI, but I also don't know whether that would be a pain due to non-standard packaging or whatever)
  <kyrofa> cjwatson, haha, me neither
  <cjwatson> kyrofa: though I guess adding all of snapcraft to our dependencies would bloat our virtualenv a *lot*, so it might be better if there were a more focused dependency split off from it, if that isn't too much hassle
  <cjwatson> kyrofa: oh, err - also, LP is currently Python 2
  <kyrofa> cjwatson, oh nooooooo
  <kyrofa> Hahaha
  <cjwatson> kyrofa: making just the parser bilingual might be easier than making the whole thing bilingual
  <cjwatson> which I'm fairly sure you have no interest in
  <kyrofa> cjwatson, indeed, that's definitely a point in favor of refactoring into its own thing (which is what I was planning for anyway)
  <kyrofa> cjwatson, glad we talked, that changes my time estimate a little
  <cjwatson> I obviously want to get LP onto Python 3 eventually, but it's lots of code and lots of dependencies
  <Pharaoh_Atem> will LP become Python 3?
  <cjwatson> glad I thought of that, that obviously changes things
  <cjwatson> Pharaoh_Atem: ... as I just wrote :)
  <kyrofa> cjwatson, but not unreasonably so
  <Pharaoh_Atem> well, you want it to, doesn't mean that's actually planned :P
  <kyrofa> cjwatson, sure, no problem at all
  <Pharaoh_Atem> last time I talked to anyone about LP, they said the project is effectively dead :/
  <kyrofa> But I appreciate the heads up
  <cjwatson> Pharaoh_Atem: they were lying
  <cjwatson> or misinformed
  <kyrofa> Pharaoh_Atem, it's a huge part of our infra
  <cjwatson> that sort of thing makes me quite cross because it erases e.g. my work
  <Pharaoh_Atem> kyrofa: plenty of people run on dead projects :)
  <Pharaoh_Atem> cjwatson: it gets said *a lot*
  <cjwatson> Pharaoh_Atem: turns out that porting three-quarters of a million lines of Python with 200 dependencies to Python 3 is a ton of work, and when it has to be fitted around the edges of feature work, that's tough
  <Pharaoh_Atem> X_X
  <Pharaoh_Atem> it'll be impressive at the end :)
  <kyrofa> cjwatson, 200? That's all?
  <cjwatson> Pharaoh_Atem: it's significantly less funded than it used to be, certainly, but it is not dead and if you're hearing that I'd appreciate correcting the misapprehensions
  <Pharaoh_Atem> kyrofa: dude, GitLab has almost 600 dependencies
  <Pharaoh_Atem> you should be glad LP only has 200
  <kyrofa> Pharaoh_Atem, I know, I wasn't being sarcastic, I'm genuinely surprised
  <cjwatson> kyrofa: last exact count was 208 I think
  <cjwatson> though that's not counting .deb-packaged deps
  <Pharaoh_Atem> cjwatson: the last couple of times I've reported LP bugs, people have messaged me to say to not bother
  <cjwatson> bah
  <Pharaoh_Atem> so *shrugs*
  <Pharaoh_Atem> sorry
  <cjwatson> next time please tell me who they are so I can correct them
  <Pharaoh_Atem> will do
  <cjwatson> possibly just by fixing the bug in question :P
  <kyrofa> Hahaha
  <cjwatson> if they're Canonical people, then I think it's actually really unprofessional
  <Pharaoh_Atem> yeah, it was definitely Canonicalers
  <Pharaoh_Atem> last year or so
  <Pharaoh_Atem> and again after I filed this: https://bugs.launchpad.net/launchpad/+bug/1678486
  <mup> Bug #1678486: Enable watching Red Hat Bugzilla bugs <Launchpad itself:New> <https://launchpad.net/bugs/1678486>
  <cjwatson> I didn't notice that, but will look into the history
  <Pharaoh_Atem> the other time recently was when I asked about some of the incorrect project associations in LP
  <Pharaoh_Atem> I was told that no one maintains those and there's nothing anyone can do about it
  <cjwatson> That's not really about the LP codebase; those were always designed (rightly or wrongly) to be gardened by the community
  <Pharaoh_Atem> for example, the rpm5 guys hijacked the rpm registration on LP: https://launchpad.net/rpm
  <cjwatson> Pretty much anyone can change them, but the flip side is that pretty much anyone can change them back
  <Pharaoh_Atem> which means it's impossible to glue upstream rpm bugs to downstream issues
  <cjwatson> Oh, you don't mean the project/package associations, you mean metadata on projects?
  <Pharaoh_Atem> yeah
  <Pharaoh_Atem> as an example, this: https://bugs.launchpad.net/rpm/+bug/1475755
  <mup> Bug #1475755: rpmbuild auto provides not listing shared libraries <RPM:Invalid> <https://launchpad.net/bugs/1475755>
  <cjwatson> Somebody must've specifically asked for that
  <cjwatson> Honestly I think it might be best to register a new project name for upstream rpm
  <cjwatson> Or we could fight it out with ~rpm5 to get the project renamed to rpm5
  <Pharaoh_Atem> that's hard, since the "rpm" name is tied to the rpm package and all the tooling
  <cjwatson> The project name in Launchpad can't possibly be
  <cjwatson> I wasn't suggesting renaming rpm upstream ...
  <cjwatson> Just LP's view of it
  <Pharaoh_Atem> ah
  <Pharaoh_Atem> well, if the current "RPM" is renamed to RPM5 and kicked out of the associations, that'd fix it
  <cjwatson> Anyway, doesn't sound like you asked anyone who actually knew how this stuff is handled
   * Pharaoh_Atem shrugs
  <Pharaoh_Atem> I don't know anything
  <Pharaoh_Atem> all I know is what people tell me
  <Pharaoh_Atem> which apparently is 120% wrong :)
  <cjwatson> Can you (get somebody with suitable authority to) file a ticket on https://answers.launchpad.net/launchpad/+addquestion about the rpm issues with as much detail as possible?
  <cjwatson> It may take some archaeology to sort out what's been happening
  <Pharaoh_Atem> I can try
  <cjwatson> thanks
  <Pharaoh_Atem> no promises, as most of the rpm guys just want to stay the fuck away from rpm5 maintainer
  <Pharaoh_Atem> he's kind of a toxic asshole
  <cjwatson> well, LP by policy wants to stay away from that sort of thing, it's not our business; we just want to have a semi-reasonable modelling of what things are called
  <Pharaoh_Atem> yeah
  <cjwatson> Pharaoh_Atem: oh, re "you want it to, doesn't mean that's actually planned" - I landed a bunch of branches just today making concrete progress towards it, even if it does feel a bit drop-in-the-ocean sometimes :)
  <cjwatson> (lots of "from __future__ import absolute_import, print_function, unicode_literals" and associated fixups)
  <sergiusens> cjwatson and kyrofa snapcraft is already on pypi and yes we will split the package out as a stretch goal
  <kyrofa> sergiusens, you missed it: needs to be python2
  <kyrofa> Can't be a stretch goal :)
  <sergiusens> It can still be stretch.
  <niemeyer> cachio: Stop one in progress? snap abort
  <niemeyer> cachio: Prevent it from even getting started?  schedule the refresh
  <cachio> niemeyer, yes, testing that, because wait of the auto refresh is taking so long
  <niemeyer> cachio: The --last parameter of abort may come in handy
  <cachio> niemeyer, well the --last is not present inthe stable version so it makes the script fail
  <niemeyer> cachio: I'm pretty sure it is
  <niemeyer> cachio: It's been added a long while ago
  <cachio> niemeyer, https://paste.ubuntu.com/25774590/
  <cachio> this stable release is from mack I guess
  <cachio> march
  <niemeyer> cachio: lol
  <niemeyer> cachio: I'm sure *some day* stable didn't have it :)
  <cachio> niemeyer, :) sadly, np, I'll continue working with the change id instead
  <facubatista> sergiusens, push metadata to the store: https://github.com/snapcore/snapcraft/pull/1634
  <mup> PR snapcraft#1634: Push metadata to the Store <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1634>
  <mup> PR snapcraft#1634 opened: Push metadata to the Store <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1634>
  #snappy 2017-10-20
  <elopio1> snappy-m-o autopkgtest 1630 ubuntu:xenial:integration
  <snappy-m-o> Computer says nooo. See logs for details:
  <snappy-m-o>  Command '['/tmp/tmp5u8uatg8/retry_autopkgtest.sh', '1630', 'ubuntu:xenial:integration']' returned non-zero exit status 1
  <elopio1> snappy-m-o autopkgtest 1630 xenial:amd64:integration
  <snappy-m-o> elopio1: I've just triggered your test.
  <zyga-ubuntu> good morning
  <mup> PR snapd#4060 opened: interfaces: clean system apparmor cache on core device <Created by mvo5> <https://github.com/snapcore/snapd/pull/4060>
  <mvo> Chipaca: hey, good morning. how are you? a quick question, currently if you ddo "snap install foo; snap refresh --edge foo; snap revert foo" afterwards you have foo from stable but you still track edge. I was wondering if that is something that users expect, i.e. if we violate the principle of least surprise here
  <Chipaca> mvo: I don't know. Maybe?
  <Chipaca> mvo: but mostly, no
  <Chipaca> mvo: "snap refresh --channel foo bar" is two operations: "snap switch --channel foo bar && snap refresh bar"
  <Chipaca> mvo: snap revert just blacklists current and goes back to the previous revision, it does nothing around switch
  <Chipaca> mvo: if you're on stable and "snap refresh --beta bar" and beta has the same revision as stable, you're saying a user would expect snap revert to .... what?
  <Chipaca> mvo: mostly, if their mental model is wrong, we need to see why and address that; i think revert's behaviour is relatively well defined
  <Chipaca> (relatively being about flags that should be per revision but aren't)
  <mvo> Chipaca: thanks, thats fine, was mostly wondering
  <Chipaca> wrt how to fix that, we could make revert comment
  <Chipaca> not sure we currently have enough info to do so, but we could
  <Chipaca> something like âreverted âfooâ to rev 232 (in channel stable), but still tracking betaâ
  <Chipaca> not sure that wording in particular helps, but something like that?
  <mvo> Chipaca: aha, nice, I think that that would be a nice improvement
  <Chipaca> I suddenly have polkit-enabled snapd and it's magic
   * Chipaca hugs jamesh 
  <jamesh> Chipaca: there's still more work to do, but the parts landed in 2.28 are probably most noticeable
  <Chipaca> mvo: we _do_ have the info to output that message
  <Chipaca> jamesh: is there / should there be a way for it to cache my password though?
  <Chipaca> ah, it is
  <Chipaca> just per op
  <Chipaca> ok
  <mvo> Chipaca: we show we reverted to what version but we don't show any channel info afaict
  <Chipaca> ah no it isn't
  <Chipaca> hm
  <Chipaca> the flow for login is weird
  <Chipaca> it asks for the passwords in the reverse order than before
  <Chipaca> mvo: correct
  <Chipaca> mvo: but we do store the channel from which we got each revision
  <jamesh> Chipaca: the policy is controlled by /usr/share/polkit-1/actions/io.snapcraft.snapd.policy plus and pkla files that modify the policy
  <jamesh> Chipaca: the policy should be auth_admin_keep for active users, so I'm not sure why that isn't happening
  <Chipaca> jamesh: âOperator of unix-session:c4 successfully authenticated as unix-user:john to gain TEMPORARY authorization for action io.snapcraft.snapd.login for unix-process:31007:75416645 [snap login jlenton@gmail.com] (owned by unix-user:john)â says the log
  <jamesh> Chipaca: the intent of the policy is to let an active user (i.e. logged in locally and without the screen locked) retain authorization, and require others to enter password every time
  <jamesh> I'm not sure why that isn't working
  <Chipaca> jamesh: is that just not working for me, or do you also see it?
  <jamesh> Chipaca: it seems to ask every time for me too.
  <jamesh> something to investigate, sure.
  <Chipaca> ok
  <mup> PR snapd#4061 opened: daemon, store: forward SSO invalid credentials errors as 401 Unauthorized responses <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4061>
   * kalikiana coffee break
  <cjwatson> sergiusens: can you elaborate on your comment that it can still be a stretch goal?  I don't see how we can do this without 2/3 bilingual parser code, and making all of snapcraft 2/3 bilingual sounds like considerably more work than splitting out the parser bits ...
  <cjwatson> (I don't want to dictate exactly how you do it, just making our reqs clear)
  <mup> Bug #1725208 opened: missing interface to exec cc <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1725208>
  <mup> PR snapd#4062 opened: cmd/snap: warn when a snap is not from the tracking channel <Created by chipaca> <https://github.com/snapcore/snapd/pull/4062>
  <Chipaca> mvo: ^
  <jjohansen> mvo: sorry, for the delay I was looking for the patch I had started years ago to do the profile hashing for cache consistency, it wasn't were I thought it was so it took me a while to find it
  <jjohansen> It looks like its 80-90% done but doesn't apply cleanly against the current tree
  <mvo> Chipaca: nice!
  <mvo> jjohansen: can I help in some way?
   * zyga-ubuntu -> afk, need a coffee
  <mvo> jjohansen: thanks for getting back to me :)
  <jjohansen> I'll refresh it, and poke at it a little more, at a minimum I'll kick it over to you, but I might play with it this weekend
  <mvo> zyga-ubuntu: for when you are back, is it just me or are the gnome-shell extension not really working? I tried to add a clock with times from different timezones and nothing works and its all dubious :/
  <mvo> jjohansen: great, thanks!
  <jjohansen> mvo: so basically, yeah fast hashes are good enough, just hashing the timestamp would be a little faster, and might be sufficient
  <mvo> jjohansen: great! there is no real rush, so I'm happy to wait until after the weekend. but I would really like to get this upstream fixed to avoid that we run into this again in 1-2y when we change something structual again :)
  <mvo> jjohansen: and I'm happy to help, just to be clear.
  <jjohansen> I like help :)
  <zyga-ubuntu> mvo: could be just lost in transition, I switched to my phone for stuff like that
  <mvo> zyga-ubuntu: aha, ok. yeah, the whole extensions story feels very weak, none of the ones I tried worked
  <zyga-ubuntu> mvo: I tried one that did work just now but it was ugly
  <mvo> zyga-ubuntu: and its super obscure how to add/manage them, apparently via the browser and a local service
  <mvo> zyga-ubuntu: which one was it?
  <zyga-ubuntu> https://extensions.gnome.org/extension/605/multiclock/ this one
  <zyga-ubuntu> but now that I try again I get an error
  <mvo> zyga-ubuntu: aha, this works indeed
  <mvo> zyga-ubuntu: anyway, not important
  <mvo> zyga-ubuntu: just annoying, I really liked my unity clock that told me what time .br .us etc have
  <zyga-ubuntu> mvo: yeah, I was using it too
  <zyga-ubuntu> mvo: as I said I switched to my phone for that, more consistency in features and more longevity
   * mvo nods
   * mvo nods sadly
  <Chipaca> "oh boo hoo i cut myself on the bleeding edge with the big warning and the flashing lights"
   * Chipaca grins evily
  <zyga-ubuntu> Chipaca: and the sign said "fewer features, come right in"
  <Chipaca> zyga-ubuntu: did the spinning blades around the entrance not give you a hint?
  <zyga-ubuntu> Chipaca: the conveyor belt was fused in the "fast forward" mode so like everyone else, I flew right in
  <ogra_> zyga-ubuntu, you get that wrong, the "fewer features" thing is a new feature ;)
  <Chipaca> ubunteros have been complaining about losing features since 6.06 at least
   * Chipaca included
  <zyga-ubuntu> http://images.uncyc.org/commons/4/4f/Gnomehint.png
   * zyga-ubuntu is sorry about this and gets back to work
  <Chipaca> zyga-ubuntu: sounds about right
  <zyga-ubuntu> mvo: niemeyer suggested I work with sergio on centralied package installation, do you know where that lives?
  <mvo> zyga-ubuntu: I get lunch now, but we can talk about this afterwards. its in prepare.sh I would assume
  <zyga-ubuntu> mvo: thank you, enjoy your lunch :)
  <zyga-ubuntu> cachio: hey :)
  <zyga-ubuntu> cachio: I just asked about something :)
  <zyga-ubuntu> 13:29 < zyga-ubuntu> mvo: niemeyer suggested I work with sergio on centralied package installation, do you know where that lives?
  <cachio> zyga-ubuntu, hey
  <cachio> zyga-ubuntu, yes, on minute
   * ogra_ notes that #3958 starts to have more traffic than most mailing lists he is subscribed to :P
  <mup> PR #3958: many: add support for /home on NFS <Created by zyga> <https://github.com/snapcore/snapd/pull/3958>
  <cachio> zyga-ubuntu, https://github.com/snapcore/spread-images/pull/9
  <mup> PR spread-images#9: Install dependencies on the images <Created by sergiocazzolato> <https://github.com/snapcore/spread-images/pull/9>
  <zyga-ubuntu> cachio: so this will take over the regular installation logic?
  <Chipaca> do we have the 'debug build' feature enabled in our travis?
  <zyga-ubuntu> cachio: can you please add nfs-kernel-server there
  <zyga-ubuntu> Chipaca: what does that feature do, out of curiosity?
  <Chipaca> zyga-ubuntu: lets us ssh into it
  <Chipaca> https://docs.travis-ci.com/user/running-build-in-debug-mode/
  <cachio> zyga-ubuntu, sure
  <zyga-ubuntu> cachio: thank you :-)
  <zyga-ubuntu> ohhh
  <zyga-ubuntu> shiny
  <cachio> zyga-ubuntu, we are not currently installing nfs-kernel-server
  <cachio> should I install it just in ubuntu?
  <zyga-ubuntu> cachio: yes, that will be fine, thank you
  <zyga-ubuntu> ogra_: indeed, that PR has exactly 100 comments now :)
  <ogra_> so crazy
  <zyga-ubuntu> ogra_: review it, you will get 101th comment
  <cachio> zyga-ubuntu, the test on linode failed, I am rexecuting
  <cachio> once it passes I'll push the change
  <zyga-ubuntu> cachio: thank you
  <cachio> zyga-ubuntu, change added
   * kalikiana break
  <sergiusens> good morning!
  <sergiusens> cjwatson let me rephrase privately
  <zyga-ubuntu> hey sergiusens
  <sergiusens> zyga-ubuntu how is it going?
   * sergiusens is procrastinating on presentations he needs to get done
  <zyga-ubuntu> sergiusens: working on layous and new mount features
  <zyga-ubuntu> sergiusens: sleepy morning, dind't sleep well but now it's good (feels like 10AM now :)
  <sergiusens> zyga-ubuntu and yet you are almost EOD :-P
  <zyga-ubuntu> no no, I'll stay now
  <zyga-ubuntu> pstolowski: I ran into a issue sometimes, can you have a look at this and tell me if it rings any bells
  <zyga-ubuntu> http://pastebin.ubuntu.com/25779014/
  <zyga-ubuntu> I'll debug, just want to see if you've seen it
  <pstolowski> zyga-ubuntu, wow, i've never seen this kind of issue
  <zyga-ubuntu> pstolowski: thanks, maybe it's an impact of my work :/
  <zyga-ubuntu> hah
  <zyga-ubuntu> qemu:ubuntu-16.04-64 .../tests/main/interfaces-hooks# cat /var/lib/snapd/mount/snap.basic-iface-hooks-consumer.fstab
  <zyga-ubuntu> /snap/basic-iface-hooks-producer/x1/etc /snap/basic-iface-hooks-consumer/x1/initialtarget none bind,ro 0 0
  <mup> Issue snapcraft#1437 closed: cross-compile i386 kernel <designed> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1437>
  <mup> PR snapcraft#1613 closed: cross compilation: enable cross compilation of i386 kernel on x86-64 â¦ <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1613>
  <zyga-ubuntu> qemu:ubuntu-16.04-64 .../tests/main/interfaces-hooks# ls -ld /snap/basic-iface-hooks-producer/x1/etc
  <zyga-ubuntu> ls: cannot access '/snap/basic-iface-hooks-producer/x1/etc': No such file or directory
  <zyga-ubuntu> qemu:ubuntu-16.04-64 .../tests/main/interfaces-hooks# ls -ld /snap/basic-iface-hooks-consumer/x1/initialtarget
  <zyga-ubuntu> ls: cannot access '/snap/basic-iface-hooks-consumer/x1/initialtarget': No such file or directory
  <zyga-ubuntu> pstolowski: so now those get created
  <zyga-ubuntu> pstolowski: did you mean for basic-iface-hooks-producer/ to have an $SNAP/etc directory?
  <pstolowski> zyga-ubuntu, let me check, i need to refresh my memory
  <zyga-ubuntu> pstolowski: it's specified in snap.yaml but not in the tree
  <zyga-ubuntu> pstolowski: maybe it needed a fake file to keep the directory around?
  <pstolowski> zyga-ubuntu, ok. the test doesn't are about what's in the filesystem. it just cares about reading the attributes of interface
  <zyga-ubuntu> pstolowski: ok, I'll probably tweak the test to contain more realistic content interface use
  <pstolowski> zyga-ubuntu, can be any other interface if you can find one that has attributes and can be used instead in the test, although afair i had some issues with that and found out that content interface could be "abused" for this test
  <zyga-ubuntu> pstolowski: well, you could use the network interface
  <zyga-ubuntu> pstolowski: and then add any set of attributes inside
  <zyga-ubuntu> (or any other simple interface)
  <zyga-ubuntu> ah wait, you need the pair
  <zyga-ubuntu> hmm
  <elopio1> sergiusens: kyrofa kalikiana here is my task breakdown: http://pad.ubuntu.com/snapcraft-18-04-elopio
   * zyga-ubuntu -> lunch
  <mup> PR snapd#4063 opened: tests: add new kernel refresh/revert test for spread-cron <Created by mvo5> <https://github.com/snapcore/snapd/pull/4063>
  <mup> PR snapd#4058 closed: interfaces: reduce duplicated code in interface tests mocks <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4058>
  <zyga-ubuntu> mvo: hey, can you look at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/amd64/s/snapd/20171020_131659_7c6aa@/log.gz
  <zyga-ubuntu> mvo: one test failed there
  <mvo> zyga-ubuntu: sanity timeout expired: Interrupted system call
  <zyga-ubuntu> mvo: this says that snap-confine held a lock for more than 3 seconds
  <zyga-ubuntu> mvo: (we have a sigalrm being sent to us)
  <mvo> zyga-ubuntu: is it just a very slow vm? can we try 12s?
  <zyga-ubuntu> mvo: I'd rather not change that amount yet, I just want to raise this in case there's something funny going on and we break in some D state in the kernel
  <zyga-ubuntu> mvo: I'll monitor tests for this
  <mvo> zyga-ubuntu: fair enough
  <zyga-ubuntu> mvo: it could be a slow VM but we usually grab this lock for tiny fractions of a second
  <mvo> zyga-ubuntu: is it in all tests? i have seen it before I think but not consistently
  <zyga-ubuntu> mvo: no, I just saw it now for the first time
   * zyga-ubuntu -> fetch water
  <zyga-ubuntu> man
  <zyga-ubuntu> I go to fetch some water into canisters
  <zyga-ubuntu> just to find they finished repairs and it's back on :)
   * zyga-ubuntu breaks, I'll ran into one problem and I need to think about it
  <mup> PR snapd#4064 opened: tests: new test for hardware-random-control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4064>
  <niemeyer> mvo: The container based travis is flowing
  <niemeyer> mvo: For awareness, there were two different issues.. using the C language meant the checkout from git was done differently and paths didn't match anymore ($GOPATH semantics was gone).. then, the removal of the install section meant Travis cooked up a default install section for us while trying to help, but that broke things out as well
  <niemeyer> mvo: I'll write those notes in the forum so we don't lose it
  <niemeyer> Will just wait for tests to pass
  <mup> PR snapd#3960 closed: travis: switch to container based test runs <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3960>
  <niemeyer> mvo: https://forum.snapcraft.io/t/ci-on-travis-now-using-containers/2547
  <mvo> niemeyer: nice, thanks for handling this
  <niemeyer> mvo: My pleasure, let's see if that kills the delays we've been observing
  <bashfulrobot> Are questions better in here, or in rocketchat?
  <kyrofa> bashfulrobot, here nowadays
  <bashfulrobot> ok, great.
  <kyrofa> Man, I do not know The Twitter. I never remember to make sure NOT to start a non-reply with a @
  <bashfulrobot> soooo.... for 18.04 I would really like tio use snaps for applets in Ubuntu Budgie. Now with V11 in dev, but no ETA, we are staying open at this point if it will be V10 vs V11. But with V10, applets have to reside in a certain folder location. Do snaps at this point have a mechanism to accomplish this? I know with confimenemtn, etc, this goes COMPLETELY against what snaps are...
  <popey> ogra_: have you attempted to get your nwjs snap working strictly? https://github.com/ogra1/nwjs
  <kyrofa> bashfulrobot, well, what ARE applets for budgie?
  <bashfulrobot> Essentially plugins and added features for teh Budgie Desktop.
  <kyrofa> bashfulrobot, so, like, .so ?
  <bashfulrobot> usually added to the panels, etc.
  <bashfulrobot> They can be written (currently) in vala, pythin and c++
  <nacc> are they themselves applications?
  <nacc> (things that run)
  <bashfulrobot> They do not
  <bashfulrobot> run on their own.
  <kyrofa> bashfulrobot, i.e. you wouldn't declare any `apps` for them?
  <bashfulrobot> kyrofa - they have to be run and written in a certain way to be consumed by the desktop
  <kyrofa> In that case, they aren't technically confined at all
  <nacc> kyrofa is probably a better expert here, then, but why is a snap a good idea for that?
  <bashfulrobot> nacc The idea is to make it easier for 3rd party people to package. Auto update. Solus in theory could take advantage of them too. We also try to push our core applets into Debian, so that requirement is moot in snaps.
  <nacc> bashfulrobot: i understand all that, but it does't sound like what you are packaging is actually a snap :)
  <nacc> (or at leasta  confined application in a snap)
  <bashfulrobot> Now you could be compeltely correct and maybe a snap is not the proper mechanism for this. But for the above reasons it "seemed" like it could be a good option (unless there is a reason technically to not do this).
  <bashfulrobot> nacc - this is true
  <bashfulrobot> It is kind of an odd edge case
  <bashfulrobot> I guess more so trying to use it as a delivery mechanism.
  <nacc> bashfulrobot: i'm curious what kyrofa things -- i have wondered how 'glue' fits into snaps myself. Things that are consumed by other applications. Perhaps what you want is to be a part?
  <kyrofa> Heh
  <bashfulrobot> exactly
  <kyrofa> Confinement is really only one aspect of snaps. There are a lot more, too
  <bashfulrobot> And as mentioned - I very well may be barking up the wrong tree where.
  <kyrofa> Bundling, updates, kind of the generic delivery method
  <bashfulrobot> But wanted to validate and see what the snap ecosystem thought of this.
  <kyrofa> bashfulrobot, nah, I hear where you're coming from, but I'll admit it's a bit unconventional
  <kyrofa> bashfulrobot, let's think this through
  <bashfulrobot> kryofa for sure. Has this type of thing come up before in discussion/
  <bashfulrobot> ?
  <kyrofa> Not in my experience, but I'm hardly the only snap dev
  <bashfulrobot> ah ha for sure
  <kyrofa> So: you have a specific directory where "things" need to be. What are those things? How are they called into?
  <kyrofa> e.g. does each applet have a single entry point?
  <bashfulrobot> disclosure... I am more of the packager, and not so much a developer of these applets. so I have to be cautious of what I say here so as to not stick my foot up my arse.
  <kyrofa> bashfulrobot, haha, everyone is an expert relative to their colleagues. In this room, I suspect you're the expert ;)
  <bashfulrobot> well a foot up the arse is uncomfortable either way. :-p
  <kyrofa> Yeah that sorta sucks
  <kyrofa> bashfulrobot, we can start on the other end of the discussion, and I can list possibilities
  <bashfulrobot> awesome. I'm just reviewing a few applets here to be clear on myanswer for your question.
  <kyrofa> So: snaps are a single squashfs image, as you know. They get mounted into e.g. /snap/snapname/version
  <bashfulrobot> yup.
  <kyrofa> A snap containing an applet would contain the applet itself as well as any of its dependencies
  <kyrofa> First question: would budgie itself be one of those dependencies?
  <kyrofa> Ignoring that question, I'll continue
  <kyrofa> Having applets in /snap isn't useful. You need some way to get the applets into the "applet dir" what is that, in /var somewhere?
  <bashfulrobot> Well budgie itself is needed, but is not a snap.
  <kyrofa> What if you made a symlink back to the applet in the snap?
  <bashfulrobot> That was a thought I had. But was concerned that it was a bit of tom folery and hacky.
  <bashfulrobot> fooler*
  <bashfulrobot> foolery*
  <kyrofa> Since you'd be using the snap solely as a delivery method, it's really just a lump of libs and assets
  <bashfulrobot> yeah
  <bashfulrobot> exactly that
  <kyrofa> You'd need to set up the LD_LIBRARY_PATH such that those things are found
  <kyrofa> It could also use the budgie on the system if you strip it out of the applet snaps
  <bashfulrobot> that is hte way it would need ot be today.
  <kyrofa> Yeah, I think you could make this happen. It does sound a bit hacky
  <bashfulrobot> kyrofa - also to loop back to an earlier question...
  <bashfulrobot> That you had
  <bashfulrobot> Each applet is a typical libpeas based applet - i.e. a .plugin file and and a module file. Both live in /usr/lib/budgie-desktop/plugins/applet-name/applet.plugin & applet_module
  <bashfulrobot> Each applet can have multiple instances - UUID for each applet.
  <kyrofa> So you'd need to symlink both of those out of the snap?
  <xan_IT> hi, can i ask noob question about snap packages inside ubuntu here?
  <kyrofa> xan_IT, always :)
  <bashfulrobot> kyrofa - yeah that is my concern (hacky). I don't want to do this "just to do it", but rather if it makes sense. And if it was a situation that the team had either looked at, or considered (glue code of sorts).
  <kyrofa> bashfulrobot, are they found recursively? e.g. could you symlink a dir?
  <kyrofa> bashfulrobot, I think it's interesting, snaps solve some of the problems you'd need to solve yourself otherwise
  <kyrofa> bashfulrobot, it's probably going to come down to weighting the pros and cons there
  <xan_IT> 1) snap packages are in sandbox area, true? so if i install same packages throught deb and snap, second will not overwrite first. true?
  <kyrofa> bashfulrobot, might be worth a prototype
  <bashfulrobot> yeah for sure.
  <bashfulrobot> I could work towards one.
  <xan_IT> 2) there is like https://packages.ubuntu.com/ for snap??
  <kyrofa> xan_IT, you're mixing terminology a bit, but yeah: when you install a snap, it typically doesn't mess with any debs
  <xan_IT> kyrofa what i mixing ? i want hunderstands :D
  <kyrofa> bashfulrobot, you know where to find us if you run into interesting issues there
  <bashfulrobot> xan_IT sandboxed yes, but if you use classic confinement, way more access (almost no confinement if I understand correctly)
  <roadmr> xan_IT: https://uappexplorer.com/snaps has a list of available snaps
  <bashfulrobot> xan_IT deb will not overwrite snap. snap is in a differnt location and a squashfs
  <kyrofa> xan_IT, when you say "sandbox" you're mostly talking about confinement, but what you seem to be asking is: "will installing a snap interfere with a deb of the same thing"
  <xan_IT> thz, so snap packages can access to all file system ?
  <nacc> xan_IT: it depends on the confinement of the snap
  <bashfulrobot> kyrofa - I just remembered. We did do sonme testing with symlinks....
  <bashfulrobot>  I know if you symlink /usr/lib/budgie-desktop/plugins/applet-name to somewhere else, then yes budgie-desktop is happy
  <bashfulrobot> BUT
  <xan_IT> nacc ?
  <bashfulrobot> updates broke because the link is tied to the version number
  <kyrofa> bashfulrobot, did you try symlinking through /snap/snapname/current ?
  <bashfulrobot> so I guess the snap YAML would need logic to recreate on each update
  <nacc> xan_IT: https://docs.snapcraft.io/reference/confinement
  <kyrofa> bashfulrobot, another symlink
  <kyrofa> snapd maintains that one
  <bashfulrobot> ahh - did not
  <bashfulrobot> Will ahve to try that
  <kyrofa> bashfulrobot, that could work really nicely actually. Snaps can be disabled as well, which removes that symlink (but leaves the snaps in place)
  <kyrofa> bashfulrobot, which would break the symlinks, thus ensuring those applets aren't loaded
  <nacc> (another use-case for current is that, e.g., you can find the core snap always at /snap/core/current)
  <nacc> that has some use for me, at least
  <xan_IT> so there is only 1 repository for snaps for all distributions?
  <kyrofa> xan_IT, indeed. Since snaps are designed to work on multiple distributions, there's not really a need for a store for each
  <bashfulrobot> kyrofa well you have given me something to think about. And that the path I was looking at is the way to do it today. I would be interested if more of this type of discussion pops up and what the overall community thinks of this methind and delivering something like a plugin via snap.
  <kyrofa> bashfulrobot, well, there are multiple facets to that
  <bashfulrobot> xan_IT just the store. Global to all distros that use snaps
  <kyrofa> bashfulrobot, I think we definitely want to support shipping plugins as snaps, the question is how they're consumed
  <kyrofa> bashfulrobot, we have a bug for a new interface for this
  <xan_IT> last question: who update snap packages?
  <kyrofa> bashfulrobot, but that requires the consumer to be a snap
  <nacc> yeah, it's itneresting. a pluginn is like between a part and app
  <nacc> xan_IT: the snap owner
  <kyrofa> bashfulrobot, having the consumer be not snapped is a different ballgame
  <kyrofa> Because interfaces don't help us
  <xan_IT> kyrofa, author of app, or a official mantainer for all packages?
  <bashfulrobot> right meaning the deps (like budgie desktop in this case)?
  <kyrofa> bashfulrobot, yep
  <bashfulrobot> right - yeah - somethign to consider for sure.
  <kyrofa> bashfulrobot, so yeah. Go snap that. You'll be done tomorrow, I expect
  <xan_IT> kyrofa, simply like debian repository or like play store/appstore ??
  <kyrofa> bashfulrobot, (kidding)
  <bashfulrobot> kyrofa - it's already done!
  <kyrofa> kyrofa, more like the play store
  <bashfulrobot> HA HA
  <kyrofa> Wow, sorry, that was for you xan_IT
  <kyrofa> Ha!
  <xan_IT> :)
  <kyrofa> xan_IT, there is no central packaging authority in the snap world
  <kyrofa> xan_IT, which means it's very easy to get YOUR app to YOUR users. Just release your update
  <kyrofa> xan_IT, in a more traditional packaging world this can be dangerous because you can break dependents, or your dependencies can break you
  <kyrofa> xan_IT, but since snaps bundle dependencies, we can skirt a lot of those issues
  <kyrofa> xan_IT, I don't mean to say that's a silver bullet, there are obviously tradeoffs there
  <bashfulrobot> xan_IT another perk, can hook up your github repo to build on push, etc too. See https://build.snapcraft.io/ and  https://docs.snapcraft.io/build-snaps/ci-integration
  <bashfulrobot> kyrofa - thanks a ton for all of your help and time! Excellent info as always!
  <kyrofa> bashfulrobot, yeah man, any time
  <bashfulrobot> I'll work on this and post back if I have success!
  <xan_IT> thz to all, so is like a store inside linux
  <xan_IT> or like npm
  <kyrofa> bashfulrobot, would also like to hear about utter and compete failure
  <bashfulrobot> ok, donlt you worry, my sorry arse will likely be back with questions!
  <bashfulrobot> hahah
  <kyrofa> xan_IT, yeah, kinda. Although what happens if you're distributing an npm package that has a system dependency?
  <bashfulrobot> kyrofa ^^
  <kyrofa> bashfulrobot, good
  <xan_IT> kyrofa i think npm not manage system dependency
  <kyrofa> xan_IT, right. So even with npm, you have to tell your users "install these dependencies... now install npm... now install my package"
  <kyrofa> xan_IT, with a snap, it's `snap install my-package` which contains npm, those dependencies, and your package
  <xan_IT> kyrofa i understands, is like npm++ :)
  <kyrofa> Hahaha, sure
  <xan_IT> :)
  <xan_IT> i need to go out, thz to all, i love all of you  :)
  <kyrofa> xan_IT, thanks for stopping by!
  <kyrofa> snappy-m-o, autopkgtest 1583 xenial:amd64
  <snappy-m-o> kyrofa: I've just triggered your test.
  <kyrofa> elopio1, I need your python and testing expertise
  <kyrofa> elopio1, help me brainstorm bug #1717921
  <mup> Bug #1717921: CI: BlockingIOError about 50% of the time <Snapcraft:New> <https://launchpad.net/bugs/1717921>
  <kyrofa> It's killing me
   * Pharaoh_Atem sighs
  <cyphermox> ogra_: can you help verifying 1712224 ?
  <cyphermox> bug 1712224
  <mup> Bug #1712224: netplan should not try to unbind brcmfmac (like brcmfmac-sdio) <patch> <verification-needed> <verification-needed-xenial> <verification-needed-zesty> <nplan
  <mup> (Ubuntu):Fix Released by cyphermox> <nplan (Ubuntu Xenial):Fix Committed by cyphermox> <nplan (Ubuntu Zesty):Fix Committed> <https://launchpad.net/bugs/1712224>
  <kyrofa> elopio1, unrelated question spawned by niemeyer's forum post: are we not using docker pretty much exclusively for our tests, now? Does that make getting off the VM system a possibility for us as well?
  <kyrofa> Or wait... maybe we only use docker to build the snap
  <bashfulrobot> refresh my memory $SNAPCRAFT_PART_INSTALL is reltive to what? teh snap dir?
  <kyrofa> bashfulrobot, I believe it's absolute
  <kyrofa> bashfulrobot, it's only used when building in snapcraft, and it points to that specific part's installdir
  <kyrofa> bashfulrobot, put files in there, and they'll be migrated into stage, prime, and finally the snap
  <kyrofa> bashfulrobot, that variable is not defined at runtime
  <bashfulrobot> kyrofa - thanks again!
   * bashfulrobot starting to refresh to finially finish mumble snap 
  <sergiusens> bashfulrobot \o/
  <sergiusens> kyrofa moving to docker won't help us as we need snapd; well we could move to docker with some hacks to have something running (snapd), but I don't really want to rely on that
  <sergiusens> the path to success elopio1 has layed out sounds better (dispatching though webhooks), but then we are at ground zero again with supporting our own infra
   * sergiusens heads to the train station
  <kyrofa> sergiusens, bin/snapcraft-classic still sets LD_LIBRARY_PATH
  <kyrofa> sergiusens, which I believe leaks into its calling environment, making cmake look there for libs as well
  <kyrofa> sergiusens, which on trusty results in cmake: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /snap/snapcraft/x1/usr/lib/x86_64-linux-gnu/libicuuc.so.55)
  <kyrofa> Does that sound accurate?
  <kyrofa> I didn't think LD_LIBRARY_PATH was needed
  <kyrofa> I'll try blowing it away and see what happens
  <kyrofa> sergiusens, yes, that fixes things. Are you sure that LD_LIBRARY_PATH is still needed? I'm not seeing problems removing it in my limited tests
  <kyrofa> sergiusens, now I'm running into the issue that I think your PR fixes
  <kyrofa> Things are looking up in the world
  <kyrofa> sergiusens, yep, your PR officially works great
  <kyrofa> sergiusens, just built the ROS indigo snap, works great
  <kyrofa> I'm gonna propose removing the LD_LIBRARY_PATH
  <mup> PR snapcraft#1635 opened: snap: remove leaking LD_LIBRARY_PATH <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1635>
  <bashfulrobot> sergiusens 0/
  <kyrofa> snappy-m-o, autopkgtest 1583 xenial:amd64 zesty:amd64 xenial:armhf
  <snappy-m-o> kyrofa: I've just triggered your test.
   * nacc wonders why steam isn't a snap yet
  <nacc> seems like the perfect target
  <nacc> and given that there is both an ubuntu and a valve repository, would allow some consolidation, and hopefully avoid all the breakage that ensues from people using the wrong .deb on the wrong system
  <mup> PR snapcraft#1636 opened: internal: more gracefully determine host OS <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1636>
  <kyrofa> snappy-m-o, autopkgtest 1635 xenial:amd64
  <snappy-m-o> kyrofa: I've just triggered your test.
  <mup> PR snapcraft#1637 opened: repo: add elementaryOS (no spaces) to deb distros <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1637>
  #snappy 2017-10-21
  <xan_IT> hi, i receive segmentation fault from snap ubuntu make
  <xan_IT> i found this, https://forum.snapcraft.io/t/segmentation-fault-in-python-snap/2218/4
  <mup> PR snapcraft#1635 closed: snap: remove leaking LD_LIBRARY_PATH <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1635>
  <kyrofa> snappy-m-o, autopkgtest 1583 xenial:amd64 xenial:armhf zesty:amd64
  <snappy-m-o> kyrofa: I've just triggered your test.
  <Son_Goku> TRIGGERED!
  <skjensen> Hi Guys, I have made a build from ogra's repository on launchpad.  The build status is successful, but where do I download the snap?
  #snappy 2018-10-15
  <mborzecki> morning
  <mborzecki> mvo: hey
  <mvo> hey mborzecki - good morning
  <mborzecki> mvo: when's the release?
  <mvo> mborzecki: 2.36~pre2 happend last friday but it looks like we need a 2.35.5 :/
  <mvo> mborzecki: why? anything important pending?
  <mborzecki> mvo: no, just checking if we could squeeze in https://github.com/snapcore/snapd/pull/5979
  <mup> PR #5979: install: don't start disabled services <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5979>
  <mvo> mborzecki: mark it for 2.36 please
  <mvo> mborzecki: and alsp please mark for squash merge to merge the cherry-pick/pr easier
  <mborzecki> mvo: marked
  <mup> PR snapd#5983 opened: interfaces/home: don't allow snaps to write to $HOME/bin (2.35) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5983>
  <mvo> mborzecki: ta
  <mvo> zyga: 5974 has some comment improvement suggestions, could you do a followup with those? I will merge and pull into 2.35 so that things move here
  <mup> PR snapd#5974 closed: osutil: workaround overlayfs on ubuntu 18.10 <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5974>
  <mvo> zyga: in case you didn't already, not sure if all points where addressed
  <mvo> mborzecki: jdstrand pushed a bunch of PRs that look important but he did not attach a milestone - do you happen to know what he needs? I tagged them as 2.36
  <mvo> mborzecki: but I'm not sure if we might even pull things into 2.35 (cc zyga)
  <mborzecki> mvo: i recall the one about scrubbing env on profile change, i see it's tagged for 2.36
  <zyga> re
  <zyga> good morning
  <zyga> sorry for starting late, very very rough night
  <zyga> mvo: looking at 5974
  <zyga> ah that, I need to digest those as, as we were discussing in on IRC, we were also talking in the pull request
  <zyga> mvo: I believe all the code there is correct, we can tweak the comment
  <zyga> mvo: I will look at Jamie's pr's now
  <zyga> jdrab: https://github.com/snapcore/snapd/pull/5982 this one is very important
  <mup> PR #5982: interfaces/many: conditionally use 'unsafe' with docker-support change_profile rules <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5982>
  <mup> PR snapd#5983 closed: interfaces/home: don't allow snaps to write to $HOME/bin (2.35) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5983>
  <zyga> the k8s pull requests are something I was not tracking so I cannot asses those
  <pstolowski> mornings
  <mvo> zyga: thanks
  <mborzecki> zyga: pstolowski: hey
  <zyga> the unsafe PR is holly smokes long :)
  <zyga> mvo: I left some comments on https://github.com/snapcore/snapd/pull/5980#pullrequestreview-164581442 - I suspect we should rename the fields/methods to match go naming scheme but otherwise this is a very welcome improvement
  <mup> PR #5980: interfaces/apparmor: conditionally add explicit deny rules for ptrace <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5980>
  <zyga> mvo: please let me know if you want to see those extra changes as additional patches in this PR directly or as a separate PR
  <mvo> zyga: ta, I have a look in a wee bit
  <zyga> British English wee bit :)
  <mvo> zyga: I don't know :) the wee as in little
  <zyga> exactly
  <zyga> that's what I meant :)
  <mvo> are there more meanings than this one?
  <zyga> not that I know of, I meant that it is specific to British English as a way to say little
  <sparkiegeek> https://en.wiktionary.org/wiki/wee#Adjective https://en.wiktionary.org/wiki/wee#Noun
  <sparkiegeek> oh, I meant to link to Etymology 2
  <zyga> lol
  <zyga> that's new :)
  <zyga> TIL wee things matter
  <zyga> pstolowski: is 5975 something we can land for 2.36?
  <zyga> it's +2 green right now
  <pstolowski> zyga: we could yes, but mvo wanted to have a look i think
   * zyga looks at k8s pull request
  <zyga> mvo: I would vote +1 on that since it makes everyday "snap tasks" much more understandable and accurate
  <zyga> mvo: but please do see it before merging
  <pstolowski> (let's squash merge then if we do)
  <zyga> sure, please set a tag there
  <mvo> zyga: yeah, I think its good, looking now (sorry, just had to finish the classic dimension forum post before it escapes my mind again :)
  <zyga> cool, thank you for doing that - I will gladly read it soon
  <Chipaca> good morning
  <zyga> good morning sir
  <Chipaca> zyga: are we there yet?
  <zyga> no, not quite
  <Chipaca> aww
  <mvo> pstolowski: 5975 looks great, please go ahead and squash merge it so that we can backport to 2.36
  <pstolowski> mvo: great, ty!
  <mvo> zyga: anything else we might need for 2.35.5 ? if not I will go ahead with this soon
  <zyga> mvo: I don't know of anything else but let me look at the full list of PRs
  <mup> PR snapd#5975 closed: ifacestate/hooks: only create interface hook tasks if hooks exist <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5975>
  <pstolowski> mvo: merged, shall i prepare PR for 2.36?
  <mvo> pstolowski: please do
  <pstolowski> sure
  <mvo> pstolowski: thank you
  <zyga> mvo: perhaps a subset of https://github.com/snapcore/snapd/pull/5696/files
  <mup> PR #5696: interfaces/opengl: add additional accesses for cuda <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5696>
  <zyga> where we have the extra directory but not the part that jdstrand pointed out (the mknod perm)
  <zyga> mvo: otherwise nothing else I see for 3.35.x
  <mup> PR snapd#5984 opened: ifacestate/hooks: only create interface hook tasks if hooks exist (2.36) <Created by stolowski> <https://github.com/snapcore/snapd/pull/5984>
  <mvo> zyga: thanks for double checking. I looked at 5980, it looks good, I agree with your comments about naming conventions though
  <zyga> I can push a patch to change it there and in the other PRs that are built on it
  <pstolowski> mvo, zyga ^ pr for 2.36 is up
  <mborzecki> pstolowski: did a pass on #5962
  <mup> PR #5962: ifacestate/hotplug: hotplug handlers <Complex> <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5962>
  <mvo> pstolowski: cool, thanks
  <mborzecki> heh github, if you search with query https://github.com/snapcore/snapd/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+%F0%9F%94%8C (using the hotplug emoji) it finds no PRs
  <pstolowski> mborzecki: thanks!
  <pstolowski> mborzecki: +1 for #5966, with one remaks (perhaps degville can help again)
  <mup> PR #5966: snap: overhaul validation error messages <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5966>
  <niemeyer> Yeah, the emojis are funny, but we should probably drop them
  <niemeyer> Morning all
  <mvo> good morning niemeyer
  <niemeyer> mvo: Yo
  <Chipaca> mborzecki: does searching by the contents of a tag find things? (doesn't work with 'complex' either)
  <mborzecki> Chipaca: probably not, seems like freetext search ignores labels
  <mvo> Chipaca: a while ago you looked into uc16 to ensure things cleanly unmount on stop/reboot, do you think you could you do the same for uc18 again?
  <Chipaca> mvo: I think I probably could :-) do you know it doesn't?
  <mvo> ppisati: did you had any luck getting to the bottom of the 4.15 pi3 b+ ethernet connection issues?
  <mvo> Chipaca: I suspect it might be :/
  <Chipaca> mvo: ok. Is there a working intel core18 i could look at?
  <mvo> Chipaca: http://people.canonical.com/~mvo/core18/
  <mvo> Chipaca: so http://people.canonical.com/~mvo/core18/core18-amd64-18-beta20180823.img.xz
  <Chipaca> thanks
  <mvo> Chipaca: should work, please do let me know if you notice anything
  <mvo> Chipaca: thank *you*
  <pstolowski> mvo: i think #5969 needs master merged, the base PR already landed
  <mup> PR #5969:  apparmor: add unit test for probeAppArmorParser and simplify code  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5969>
  <mvo> pstolowski: thanks, done
  <pstolowski> thx
  <ppisati> mvo: the fix is already queued in bionic
  <mvo> ppisati: \o/
  <mvo> ppisati: great to hear, do you have a rough eta for the snap? I guess its too much work to just do an edge build of the pi-kernel (?)
  <ppisati> mvo: as soon as the new SRU kernel is released - IIRC they cut a new kernel tomorrow, then it's 2 weeks after that
  <ppisati> mvo: but there was a respin of kernels last week, so the window might have slide a bit
  <ppisati> *slid
  <mvo> ppisati: ok. I wish we had git snapshots in the edge channel :) but I guess that is a wishlist item for another day. might actually be nice for you guys as well to get people testing/validating fixes
  <mvo> ppisati: thanks for this update!
  <mborzecki> Chipaca: i'm looking at snapshot file names, the code does not reverse the file name anywhere, so we sould be safe there wrt. parallel instances and extra _
  <Chipaca> mborzecki: yep, the filename is for the sysadmin, snapshots doesn't infer info from it
  <mborzecki> Chipaca: mhm, cool
  <Chipaca> mborzecki: only thing where it might be a problem is creating duplicate filenames, which we might not check for
  <Chipaca> mborzecki: but we use InstanceName so should be fine, afaik
  <mborzecki> Chipaca: yes, instance names are unique
  <Chipaca> i mean afaik we use instance name :)
  <Chipaca> mvo: how long does the 'resize partition' step take, usually? boot's been stuck there for a while now
  <mvo> Chipaca: probably entropy :(
  <mvo> Chipaca: just hammer at some keys
  <Chipaca> heh, that was it
   * mvo weeps a bit in the corner about this problem
  <mborzecki> heh, wonder what one will do when there's no keyboard attached
  <mborzecki> wiggle some gpios
   * Chipaca suddenly wishes for "base: core | core18
  <Chipaca> huh
  <Chipaca> mvo: a 'snap install' got aborted by a refresh of core18; is that expected?
  <zyga> aborted?
  <zyga> can we even do that?
  <Chipaca> might've been just coincidence
  <Chipaca> 'snap tasks' say 'server misbehaving'
  <zyga> mvo: actually
  <zyga> mvo: perhaps https://github.com/snapcore/snapd/pull/5982#pullrequestreview-164628872 is a candidate for .5
  <zyga> mvo: but it is stacked on top of a pile of other things
  <zyga> so unsure
  <mup> PR #5982: interfaces/many: conditionally use 'unsafe' with docker-support change_profile rules <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5982>
  <zyga> you marked that PR as targeting 2.36 so perhaps you know better
  <Chipaca> mvo: bad news: we're hitting a variant of https://github.com/systemd/systemd/issues/8155
  <mvo> zyga: I can wait for jamie to clarify
  <mvo> Chipaca: uhhh
  <Chipaca> mvo: maybe :)
   * Chipaca is still digging
  <Chipaca> but, yeah, we just see the nasty [  364.293811] systemd-shutdown[1]: Failed to wait for process: Protocol error
  <Chipaca> which seems to mean that systemd < 238
  <mvo> Chipaca: hrm, hrm, or would need to sru
  <Chipaca> yeah, systemd --version says 237
  <Chipaca> we could also backport https://github.com/systemd/systemd/pull/8429/files
  <mup> PR systemd/systemd#8429: sd-shutdown improvements <ci-fails/needs-rework ð¥> <merged-but-needs-fixing> <pid1> <Created by medhefgo> <Merged by keszybz> <https://github.com/systemd/systemd/pull/8429>
  <zyga> uh fun
  <zyga> (not)
  <Chipaca> mvo: but all that _really_ does is turn up the logging
  <Chipaca> bah, maybe :)
  <Chipaca> for our case it might be the only difference
  <Chipaca> i wonder if i can't turn up the logging without that
  <mvo> Chipaca: ok
  <Chipaca> mvo: so. we might not need that patch
  <Chipaca> mvo: it's just that our systemd-shutdown helper unit isn't getting triggered
  <Chipaca> digging continues
  <Chipaca> that is: if I set it up by hand, I get
  <mvo> Chipaca: oh, nice
  <Chipaca> Successfully changed into root pivot.
  <Chipaca> Returning to initrd...
  <Chipaca> snapd system-shutdown helper: started.
  <Chipaca> snapd system-shutdown helper: no reboot parameter
  <Chipaca> snapd system-shutdown helper: * unable to disassociate loop device /dev/loop0s: No such device or address
  <Chipaca> snapd system-shutdown helper: - was able to unmount writable cleanly
  <Chipaca> snapd system-shutdown helper: - halting.
  <mvo> Chipaca: so maybe just a missing symlink to activate it?
  <Chipaca> pr'aps
  <Chipaca> rebooting to see :-)
  <zyga> Chipaca: really /dev/loop0s?
  <mvo> Chipaca: I can look for this is that helps you :)
  <zyga> what even is that
  <Chipaca> $ systemctl is-enabled snapd.system-shutdown.service
  <Chipaca> enabled
  <Chipaca> mvo: so it's not that :-|
  <Chipaca> zyga: Â¯\_(ã)_/Â¯
  <Chipaca> zyga: /dev/loop0; the s is probably a typo
  <Chipaca> zyga: 			kmsg("* unable to disassociate loop device %ss: %s",
  <zyga> ah
  <Chipaca> :)
  <zyga> good
  <zyga> at least
  <zyga> loop0 is probably the boot snap
  <Chipaca> it's probably fine;  disassociation is automatic after dunno-what-utils-linux-version
  <Chipaca> mvo: so,  the unit is enabled; it's not getting activated afaict
  <Chipaca> probably changes to systemd-shutdown
  <mvo> Chipaca: :/ hrm, hrm
  <Chipaca> ah
  <Chipaca> i think i might know why
  <Chipaca> mvo: the snapd snap does not ship sh
  <zyga> huh? why would we need to ship sh?
  <Chipaca> well, we don't, but we then create snapd.system-shutdown.service as if we did
  <zyga> is the service using shell?
  <Chipaca> sudo sed -i -e 's|/snap/snapd/659/bin/sh|/snap/core18/304/bin/dash|' /etc/systemd/system/snapd.system-shutdown.service && sudo systemctl daemon-reload -> works
  <Chipaca> zyga: ExecStart=/snap/core18/304/bin/dash -euc 'mount /run -o remount,exec; mkdir -p /run/initramfs; cp /usr/lib/snapd/system-shutdown /run/initramfs/shutdown'
  <zyga> ohohh
  <zyga> I see
  <mvo> Chipaca: oh woah - nice catch!
  <Chipaca> I don't remember why it does that instead of having multiple ExecStart= lines
  <Chipaca> let me try that instea
  <Chipaca> probably more portable
   * Chipaca tries
  <Chipaca> of course if I had 'vi' this would be slightly easier :-D
  <mvo> Chipaca: I thought we added this
  <mvo> Chipaca: maybe you need a newer core18?
  <Chipaca> mvo: I'll let it refresh
  <mvo> ok
  <Chipaca> mvo: which 'this' is this, btw?
  <mvo> Chipaca: I thought we added "vi" to core18
  <mvo> (vim.tiny to be exact)
  <Chipaca> mvo: ah, possibly, it seems the core image was ~200 revisions behind
  <zyga> brb, dog
  <Chipaca> ok
  <Chipaca> so
  <Chipaca> easy fix
  <mup> PR snapd#5985 opened: overlord/many: cleanup use of snapName vs. instanceName <Parallel installs â> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5985>
  <mvo> Chipaca: I like the ring of "easy fix" \o/
  <Chipaca> mvo: what creates snapd.system-shutdown.service?
  <Chipaca> mvo: found it
  <Chipaca> hmm
  <Chipaca> mvo: what changes /bin/sh to /snap/snapd/<revno>/bin/sh ?
  <Chipaca> mvo: found it
  <sil2100> mvo: I have uploaded the probert with the fix for db that mwhudson prepared to our PPA, once it's built I'll be triggering a new core18
  <sil2100> Once that's in would be nice to confirm that the probert crash is gone
  <sil2100> zyga: ^
  <mvo> sil2100: nice
  <mvo> sil2100: I will test with my pi-64bit
  <zyga> As will once back
  <mvo> sil2100: nice fix
  <mvo> sil2100: great that this is under control
  <mvo> Chipaca: fwiw, this fix sounds a lot like we want it in 2.35.5 just to be one the safe side (if its someting that needs to go into snapd)
  <Chipaca> k
  <mvo> Chipaca: ta
  <mvo> Chipaca: but don't worry about this, I can do the backporting etc
  <Chipaca> mvo: there is no worry; there is only do
  <mvo> :)
  <mvo> DO!
   * mvo hugs Chipaca 
  <zyga> sil2100: is that the image from Friday good for testing?
  <zyga> mvo: release day is like xmas
  <zyga> everyone has a present
  <sil2100> No, not yet
  <sil2100> I mean, not anymore ;)
  <sil2100> I'll have a new one soonish
  <zyga> ok
  <sil2100> The packages  need to publish though
  <zyga> I'll grab lunch quickly then
  <mup> PR snapd#5986 opened: data/systemd, wrappers: tweak system-shutdown helper for core18 <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5986>
  <Chipaca> mvo, zyga: ^
  <Chipaca> ooh, lunch, a capital idea
  <pstolowski> mborzecki: +1 on  #5985, would be good to land it fast
  <mup> PR #5985: overlord/many: cleanup use of snapName vs. instanceName <Parallel installs â> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5985>
  <mvo> Chipaca: thank you
  <zyga> Chipaca: reviewed
  <sil2100> mvo: ummm, could you re-build core18 snap? Since currently I guess the main snap recipe is owned by you for now
  <sil2100> probert is good
  <mborzecki> off to pick up the kids
  <jdstrand> mvo: hi!
  <jdstrand> mvo: I didn't tag those as 2.36 because I wasn't sure how suitable they were for it at this point in time and was going to let you decide (they are bigger than whatI (and probably you) were expecting last week
  <jdstrand> needless to say, they took more than 'a few hours'
  <jdstrand> mvo: I mean, I'm happy if they go into 2.36, but having them just in trunk is ok too
  <jdstrand> mvo: but I wanted to talk to you about this: audit: type=1400 audit(1539604887.557:452): apparmor="DENIED" operation="exec" profile="snap.hello-world.env" name="/sbin/apparmor_parser" pid=30864 comm="snap-exec" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
  <jdstrand> mvo: it seems every snap run invocation is causing this. let me know when you have a moment
  <zyga> woah?
  <zyga> so snap-exec runs apparmor_parser
  <zyga> probably in the quest to compute system key
  <zyga> or something similar?
  <jdstrand> that is what I was thinking
  <zyga> what is worse
  <zyga> if apaprmor is updated
  <zyga> and we have a new apparmor parser
  <zyga> the system key will not match
  <zyga> but snapd doesn't care about the upgrade in the system
  <zyga> so it will always be wrong
  <jdstrand> so, release/apparmor.go init(), there is:
  <jdstrand> appArmorLevel, appArmorSummary = probeAppArmor()
  <zyga> until you reboot and snapd considers this
  <jdstrand> appArmorParserFeatures = probeAppArmorParser()
  <jdstrand> what is weird though, is if this is the issue, then why don't I see denials from probeAppArmor?
  <jdstrand> I only see denials for probeAppArmorParser
  <zyga> I think we allowed the former
  <jdstrand> I looked in the template. let me look again
  <zyga> oh, in that case I don't know
  <jdstrand> also, I was really surprised that snap run is doing all these checks
  <jdstrand> it isn't like it can do anything with the result
  <zyga> I think we d
  <zyga> we spin and wait
  <zyga> that's the purpose of system key there
  <jdstrand> and we are adding a bunch of stat()s and an exec() to the snap run
  <jdstrand> hmm
  <jdstrand> I definitely didn't mean for apparmor_parser to be called every time that an app was run
  <zyga> right
  <jdstrand> quite the opposite. I didn't even want it run every time a profile was compile
  <zyga> I think this falls under the idea I had a while ago with "facts" in /var/lib/snapd/facts - that would be written by snapd and interrogated by other parts of the stsack
  <jdstrand> I wanted it precisely once when snapd started :)
  <jdstrand> and I thought that was what happened with system-key
  <zyga> mmm, not quite
  <zyga> you need to be able to compute the system key
  <jdstrand> well, clearly
  <zyga> in snap-run
  <zyga> and quickly too as you now learned
  <jdstrand> we need to short circuit this or move it
  <jdstrand> I mean we could add a rule, but blech, I don't want this-- it is only useful for profile generation
  <zyga> I agree
  <zyga> hmmm hmm
  <jdstrand> snap run can literally do nothing with the information
   * pstolowski lunches
  <zyga> jdstrand: if you need me for this just ask, otherwise I'll be going through per user mount namespaces
  <jdstrand> yeah, I don't see /sys/kernel/security/apparmor/features in the template
  <jdstrand> zyga: thanks, I'll discuss with mvo and we can decide from there
  <jdstrand> it is definitely denied: $ ls /sys/kernel/security/apparmor/features/
  <jdstrand> ls: cannot open directory '/sys/kernel/security/apparmor/features/': Permission denied
  <jdstrand> so, probeAppArmor() is not getting called, but probeAppArmorParser() is...
  <jdstrand> which makes no sense cause they are both only called via init()...
   * jdstrand is confused
  <zyga> perhaps probe apparmor is really lazy?
  <jdstrand> huh
  <jdstrand> ./interfaces/system_key.go:sk.AppArmorParserFeatures = release.AppArmorParserFeatures()
  <jdstrand> ./interfaces/apparmor/backend.go:parserFeatures        = release.AppArmorParserFeatures
  <jdstrand> so in system_key, we assign '()' but in backend.go we do not
  <jdstrand> that is the same with AppAmorFeatures though...
  <zyga> !
  <mborzecki> re
  <jdstrand> maybeWaitForSecurityProfileRegeneration() does call interfaces.SystemKeyMismatch()
  <jdstrand> I'm really puzzled that I'm not seeing denials from release.AppArmorFeatures() but I am for release.AppArmorParserFeatures()
  <mvo> sil2100: sure
  <mvo> jdstrand: hi, reading backlog (looks like there is a lot of it :)
  <jdstrand> mvo: yes, halp :)
  <zyga> (insert 5th element quote0
  <jdstrand> I wonder what ioutil.ReadDir() is doing
  <jdstrand> maybe it doesn't trigger the apparmor denial
  <jdstrand> but then that would be a bug in system-key detection
  <jdstrand> hmm, it is just an os.Open
  <Chipaca> jdstrand: ls /sys/kernel/security/apparmor/features/ triggers the denial, but does stat on its own?
  <jdstrand> Chipaca: it would not, no
  <zyga> stat is not mediated anywhere AFAIK
  <Chipaca> jdstrand: maybe whatever's triggering the denial is not one of the required features that we stat in probeAppArmor
  <jdstrand> yes, that is what it is Chipaca
  <Chipaca> ah
  <jdstrand> probeAppArmor only does an isDirectory() which is just a stat
  <Chipaca> yup
  <Chipaca> and a rather dumb stat at that :)
  <zyga> aaah
  <jdstrand> ok, so mystery solved on the why probeAppArmor() doesn't trigger denials
  <zyga> man, that's magic
  <jdstrand> mvo: ^
  <mvo> jdstrand: I just finished reading backlog - indeed, we compute the system-key in snap run, sorry that I did not realize during the review about the implication of the apparmor parser test
  <jdstrand> so, the question is how to fix probeAppArmorParser
  <mup> PR snapd#5987 opened: cmd: refactor IPC and lifecycle of the helper process <Created by zyga> <https://github.com/snapcore/snapd/pull/5987>
  <mvo> jdstrand: let me quickly look at this (its 5min until our standup)
  <zyga> standup time but I'll be 3 min late
  <zyga> brb
  <jdstrand> mvo: so, on the one hand, it does make sense that we might wait for profile regeneration for the unsafe, but on the other, I'd *way* much prefer we *not* exec apparmor_parser in every snap run
  <mvo> jdstrand: from the top of my head: probe once and then save the result in e.g. /run/snapd
  <jdstrand> mvo: that's what I was trying to do :)
  <jdstrand> mvo: you mean, just touch a file?
  <mvo> jdstrand: yeah
  <jdstrand> mvo: ok, let me work through that
  <mvo> jdstrand: thanks, the other option would be to simply not make it part of system-key and hope that something else triggers a re-run
  <jdstrand> mvo: which do you prefer?
  <mvo> jdstrand: let me quickly look at what goes into system-key already
  <mvo> jdstrand: it partly depenends on your preferences as well, if we remove it from the system-key worst case is that the profile is only re-generated with the next snapd refresh
  <jdstrand> it would be fast to add a touch at the end of probeAppArmorParser and then stat for it at the top
  <jdstrand> mvo: I think that is least correct
  <mvo> jdstrand: yeah, and cheapest :)
  <jdstrand> mvo: no, I meant removing and hoping is least correct
  <jdstrand> mvo: but is is also not correct to touch the file. cause, well, in theory the parser could've been updated in the mean time (that was always true with the intent of the original PR
  <jdstrand> )
  <mvo> jdstrand: we could use the mtime of apparmor_parser as input
  <mvo> of system-key
  <jdstrand> mvo: so, mtime and touch?
  <mvo> jdstrand: mtime of /usr/bin/apparmor_parser and if that changes the system-key changes and we re-generation apparmor. and when doing that we check apparmor features
   * jdstrand doesn't see how mtime is enough
  <jdstrand> that would require redoing system key generation a bit, no?
  <jdstrand> well wait
  <jdstrand> ok, I add mtime to the systemKey struct. then I always just check for that
  <jdstrand> so, that is a stat, and we only call probeAppArmorPaarser if they are different
  <jdstrand> ok, let me look at that
  <mvo> jdstrand: thank you! in the standup right now so I may be a bit slow replying
  <Chipaca> jdstrand: dunno if it helps, but i've got this in my bash history: grep -rl --include \*.go --exclude \*_test.go '^func init()' | xargs perl -pi -we 's/(^func init\(.*)/\1\nprintln("$ARGV")/'
  <Chipaca> jdstrand: adds a print to any and all init, so you can easily spot unexpected inits
  <zyga> jdstrand: offtopic, I think you should enqueue https://github.com/snapcore/snapd/pull/5885
  <mup> PR #5885: Adding DPDK interface for DPDK Snap <Created by wililupy> <https://github.com/snapcore/snapd/pull/5885>
   * Chipaca hugs mborzecki 
   * mvo hugs mborzecki as well well
  <mborzecki> why the hugs?
  <mvo> jdstrand: standup over, anything I can help with?
  <Chipaca> niemeyer: dunno if you saw but at least mborzecki isn't here in 1h
  <Chipaca> mborzecki: no, that you said the above just as we wrapped (and I feel guilty because I said "yes", for myself, but know how that can be taken as a for all so I should've waited)
  <mvo> mborzecki: because Chipaca started it :) *grouphug*
  <Chipaca> :)
  <mvo> Chipaca: I think its fine, we just skip the bits from mborzecki  and talk about them tomorrow, no?
  <niemeyer> Chipaca: Ah, I didn't realize.. well, we can get together either way and just finish that list.. tomorrow we can review the whole thing again
   * Son_Goku hugs mborzecki 
  <mborzecki> works for me
  <Son_Goku> I'm just happy someone besides me actually bothers to investigate SELinux stuff, so you deserve hugs from me anyway :D
  <jdstrand> mvo: not yet
  <mvo> ok
  <Son_Goku> mborzecki, when 2.36 becomes available, I'm going to push out for epel7 at the same time as fedora
  <zyga> mborzecki: hey, I pushed a few tweaks to snap-confine, would you be willing to look
  <zyga> it's nothing major really, and not that long
  <zyga> mostly a switch to pipe
  <jdstrand> Chipaca: that's interesting. thank you
  <mborzecki> Son_Goku: nice, thank you!
  <mup> PR snapd#5988 opened: cmd: rename ns_group to mount_ns <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/5988>
  <zyga> mvo: if you can, please land that, that's just a rename
  <zyga> ^
  <mvo> zyga: sure, I have a look
  <zyga> thank you!
  <niemeyer> zyga: You coming?
  <zyga> ah, sure
  <zyga> niemeyer: same URL?
  <degville> zyga: yep
  <mup> PR snapcraft#2353 opened: tests: remove dependency on snapcraft for integration tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2353>
  <ackk> hi, can classic snaps run deamons as specific system users?
  <smoser> zyga: is there expected to be a new snapd upload before release  of 18.10 ?
  <zyga> smoser: I defer to our release manager, mvo
  <zyga> I don't know
  <zyga> ackk: not at present
  <zyga> unless said daemons do that themselves
  <ackk> zyga, meaning, you can "su" as a different user from classic, right? IOW a daemon could run as "nobody" in that case?
  <kyr0> Hi, I have a snap package that when I launch it from the terminal, nothing happens. Where should I start to troubleshoot?
  <zyga> re
  <zyga> ackk: correct
  <zyga> kyr0: hello
  <zyga> kyr0: it depends on the software but you may have some good idea what is happening in general by using:
  <zyga> kyr0: SNAPD_DEBUG=1 snap run ...
  <zyga> (or just the program name)
  <kyr0> zyga: Thank you, ill start my investigation.
  <zyga> kyr0: you can also run "snap run --shell" to enter a shell with the same confinement
  <zyga> kyr0: but note, not the same environment
  <zyga> some of the environment is set by wrapper scripts in $SNAP
  <zyga> cd $SNAP to look around
  <zyga> you can run those scripts directly to execute the same command
  <zyga> hmm
  <zyga> Chipaca: still hear?
  <zyga> here*
  <kyr0> zyga: Thanks, i'll start looking into it
  <Chipaca> zyga: yes
  <zyga> oh god why :)
  <zyga> ok
  <zyga> I was thinking about taking the accounts service test manual for a moment
  <Chipaca> zyga: finished dinner, came to eod
  <zyga> it's failing all the time
  <zyga> wanted to discuss ideas
  <zyga> but can wait
  <zyga> not urgent :)
  <Chipaca> zyga: i've left it looping here to see if i can catch the failure
  <zyga> I caught it once
  <Chipaca> on iteration 20 with no failures
  <zyga> forgot about it
  <zyga> closed terminal
  <zyga> yes ;)
  <zyga> I would suggest adding ps aux to debug
  <zyga> I bet there's something very odd running then
  <zyga> (not accounts service)
  <Chipaca> yeap
  <Chipaca> zyga: instead of 'gdbus monitor --session --dest yadda', i'd do 'dbus-monitor --session' which is a lot more chatty
  <Chipaca> but, that assumes I can reproduce the issue :-D
  <zyga> Chipaca: is your unmount fix ready?
  <Chipaca> zyga: well, its spread is red, if that's what you're asking
  <Chipaca> or was when i looked last
  <Chipaca> zyga: https://api.travis-ci.org/v3/job/441628807/log.txt
  <Chipaca> zyga: the last run, degraded and snap-repair failed, which â¦ not sure what those are about
  <zyga> I see
  <Chipaca> suspect something is actually broken
  <zyga> ah
  <zyga> I was just chatting with mvo about a possible release tonight
  <Chipaca> that'd be nice but integration tests aren't cooperating
  <Chipaca> and i don't know enough about those two tests to know if they're real or not
  <Chipaca> they're failing on core 18
  <Chipaca> are you seeing them fail there as well?
  <zyga> I see the error log now
  <zyga> hmmm
  <zyga> Chipaca: is ExecStart= ... ordered?
  <zyga> seems so according to manual pages
  <mup> PR snapd#5989 opened: interfaces/system-key: add parser mtime and only discover features on write <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5989>
  <Chipaca> zyga: yes, it's ordered
  <Chipaca> zyga: and yes it stops as soon as one fails, unless it starts with -
  <kyrofa> How is the possibility for a 2.36 release looking this week?
  <Chipaca> kyrofa: 0.47
  <Chipaca> kyrofa: but i'm probably overly pessimistic, so maybe it's .87
  <kyrofa> Chipaca, I'll take your earlier assessment :P
  <Chipaca> kyrofa: I hope I'm wrong, because I'm itching to update the brew formula so it no longer neads --HEAD
  <mup> PR snapcraft#2349 closed: extensions: use extension docstring <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2349>
  <popey> Chipaca: fyi, that person you conversed with was a spammer, i removed them
  <popey> (on the forum)
  <Chipaca> popey: they were? their question seemed relevant
  <Chipaca> booo
  <popey> it was a copy/pasta from a reddit thread a year ago
  <Chipaca> oh
  <popey> they do that to get credit on the forum, then slip a url edit in a few days later
  <Chipaca> right
  <popey> i didnt spot it until the edit
  <Chipaca> how isn't there an emoji for spam
  <popey> trademarks i guess
  <Chipaca> ð¥« came so close
  <Chipaca> anyhoo, it's a relief as the "why do i need to log in" thing should be well dead
  <popey> Yeah, i recently requested an edit to the appimage wiki because it claimed we still needed to login
  <popey> xkcd 386
  <mup> PR snapcraft#2354 opened: Preflight missing multipass <Created by evandandrea> <https://github.com/snapcore/snapcraft/pull/2354>
  <mup> PR snapcraft#2350 closed: extensions: parse all declared extensions before applying <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2350>
  <mup> PR snapcraft#2355 opened: extensions: cleanup and generic tests <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2355>
  <mup> PR snapcraft#2246 closed: packaging: cleanup extension usage in setup.py <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2246>
  #snappy 2018-10-16
  <mup> PR snapcraft#2353 closed: tests: remove dependency on snapcraft for integration tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2353>
  <mborzecki> morning
  <mborzecki> ugh, travis jobs unhappy again
  <zyga> good morning
  <zyga> mborzecki: the dreaded accounts service test
  <mborzecki> zyga: hey
  <mborzecki> yeah, not repeating in isolation :/
  <zyga> I reproduced it but didn't noice and closed the session
  <mborzecki> ayy
  <mup> PR snapd#5990 opened: tests: do not run degraded test in autopkgtest env <Created by mvo5> <https://github.com/snapcore/snapd/pull/5990>
  <mvo> hey zyga
  <mvo> and hey mborzecki
  <mborzecki> mvo: hey
  <zyga> hey mvo
  <zyga> good morning
  <zyga> I haven't seen infinity yet
  <mvo> zyga: I just asked him in #ubuntu-release
  <zyga> I kicked off main again, I will try to hunt the accounts service failure
  <zyga> thanks!
  <mborzecki> hm maybe it's something about gce being slow or sth, that online accounts service is dbus activated, isn't it?
  <mvo> zyga: thank you - all autopkgtest are good except for the degraded one
  <mvo> zyga: I do the proper release now (without the umount fix sadly)
  <zyga> mborzecki: unlikely, bus activated services get the socket from systemd, right?
  <zyga> mborzecki: so you'd race with systemd
  <zyga> well - we shall see really
  <mup> PR snapd#5966 closed: snap: overhaul validation error messages <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5966>
  <mup> PR snapd#5991 opened: release: 2.35.5 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5991>
  <mup> PR snapd#5992 opened: release: merge 2.35.5 changes into the 2.36 branch <Created by mvo5> <https://github.com/snapcore/snapd/pull/5992>
  <zyga> https://blogs.gnome.org/tbernard/2018/10/15/restyling-apps-at-scale/ <- interesting for theming
  <mborzecki> heh pushed a commit with some additional debug to the PR that failed consistntly due to interfaces-accounts-service, and it's failing no more
  <mborzecki> why am i even suprised
  <zyga> brb
  <zyga> mborzecki: it's just an ordering issue
  <mborzecki> zyga: i'm not so sure, the testt that executed before this one do not seem reelvant
  <zyga> mborzecki: I sent a trivial PR, we'll see
  <mborzecki> zyga: are debug sections meged together?
  <mup> PR snapd#5993 opened: tests: show list of processes when ifaces-accounts-service fails <Created by zyga> <https://github.com/snapcore/snapd/pull/5993>
  <pstolowski> mornings
  <mborzecki> pstolowski: hey
  <zyga> Oh! No
  <mborzecki> pulled logs from 6 failed runs, dropped into python to check if there's a test common to all failed jobs that ran before, seems there's no connection there
  <mborzecki> maybe we shuld just switch this test to manual to unblock prs
  <mborzecki> zyga: this is what i'm trying with here https://paste.ubuntu.com/p/Ktcj47ZDqh/
  <mup> PR snapd#5991 closed: release: 2.35.5 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5991>
  <mup> PR snapd#5990 closed: tests: do not run degraded test in autopkgtest env <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5990>
  <pedronis> mborzecki: the failure mode of that test look like the are different services that provide similar but different apis for something, it's quite weird
  <mup> PR snapd#5994 opened: tests/main/interfaces-accounts-service: more debugging <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5994>
  <mborzecki> https://www.reddit.com/r/linux/comments/9oddtb/flatpaks_sandboxes_and_security/ another *pak & sandbox thread
  <mup> PR snapd#5984 closed: ifacestate/hooks: only create interface hook tasks if hooks exist (2.36) <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5984>
  <zyga> woot, that's great
  <zyga> thank you again pstolowski
  <zyga> I will try to optimise apparmor use next week
  <pstolowski> zyga: sounds awesome!
  <zyga> man, reading reddit is a waste of time
  <mborzecki> zyga: heh, usual bs in the comments
  <zyga> BS is one thing, I really cannot stand people that claim to know something but are clearly clueless about it
  <mborzecki> btw. on the topic of desktop themes, anyone running kde? do gtk apps from snaps have breeze properly applied to them?
  <zyga> mborzecki: sorry, I'm on gnome usually
  <zyga> but on the bright side, we will always have Adwaita
  <zyga> eh
  <zyga> not a great morning
  <mvo> sil2100: bad news, probert seems to be still crashing, I have a theory (only tested on my pi3-64)
  <zyga> question, what is probers?
  <zyga> probert
  <Chipaca> we need a "this topic provides no added value" thing for the forum :-|
   * zyga hugs Chipaca 
  <zyga> what topic is that?
  <Chipaca> zyga: today, it's https://forum.snapcraft.io/t/gnome-calendar-is-not-in-spanish/7866/11
  <Chipaca> if it were a support ticket, i wouldn't mind
  <Chipaca> also, ps, spanish is not a regional language :)
  <sil2100> mvo: oh no
  <sil2100> Let me check if the right version has been pulled in
  <sil2100> Yeah, it looks like it
  <sil2100> mvo: so it's still crashing at the same place in console-conf? On startup?
  <Chipaca> zyga: has anything reached master since yesterday?
  <zyga> not that I know of :/
  <zyga> let me look
  <zyga> Chipaca: actually, I'm mistaken
  <zyga> 063f83e687d1fa2d339bc123ff5c37a2030afb50 landed
  <Chipaca> zyga: hello mistaken, i'm Chipaca
  <zyga> I'm Zygmunt if I'm not mistaken
  <zyga> ;-)
  <zyga> (or both, knowing me)
  <Chipaca> mborzecki: does 'gdbus monitor' work withouot --dest?
  <Chipaca> $ gdbus monitor --session
  <Chipaca> Error: Destination is not specified
  <sil2100> zyga: did you try a new image on your dragonboard?
  <Chipaca> mborzecki: go with dbus-monitor --session
  <zyga> sil2100: I only have the image from Friday
  <zyga> shall I re-download http://people.canonical.com/~lzemczak/dragonboard.img.xz ?
  <mup> PR snapd#5995 opened: tests/main/interfaces-accounts-service: switch to manual while we debug the test <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5995>
  <mborzecki> Chipaca: see #5994
  <mup> PR #5994: tests/main/interfaces-accounts-service: more debugging <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5994>
  <Chipaca> mborzecki: better :)
  <Chipaca> mborzecki: or was it always like that, and I'm in need of more coffee?
  <zyga> meh, now travis is not doing much
  <zyga> ohhh coffee
  <mborzecki> Chipaca: no, i mistyped it, had it `dbus monitor` before
  <zyga> I could use that
  <Chipaca> hah, even more fun
  <mborzecki> did eavesdrop need to be expliclitly enabled for session bus?
  <zyga> not that I recall
  <Chipaca> mborzecki: what about checking the package version of accountsservice?
  <mborzecki> Chipaca: that should be the same as if you spin up the test image
  <Chipaca> hm, tru
  <Chipaca> e
  <mborzecki> Chipaca: gnome-online-accounts                 3.18.3-1ubuntu2
  <mborzecki> btw. pushed a repo with a minimal spread setup i use to spin up images, faster and smaller than doing the same from snapd tree https://github.com/bboozzoo/spread-mini
  <Chipaca> mborzecki: also: gdbus introspect --session --dest=org.gnome.OnlineAccounts --object-path=/org/gnome/OnlineAccounts/Manager
  <Chipaca> WTF, travis
  <Chipaca> mborzecki: zyga: as travis is kinda stuck, would you mind merging #5994 and #5993 into a single one?
  <mup> PR #5994: tests/main/interfaces-accounts-service: more debugging <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5994>
  <mup> PR #5993: tests: show list of processes when ifaces-accounts-service fails <Created by zyga> <https://github.com/snapcore/snapd/pull/5993>
  <mborzecki> hahah
  <Chipaca> oh wait one of them is already running
  <Chipaca> Â¯\_(ã)_/Â¯
  <mborzecki> ok, hm last time we were debugging this test the observation was that the signature returned as 'expected' is correct and matches that of AddAccount
  <sil2100> zyga: I'll rebuild it in a moment
  <sil2100> (the image)
  <zyga> sil2100: ok
  <mborzecki> looking at my notes i was digging into gdbus to see if there's some parsing error
  <sil2100> I'm on the release sprint right now and we need to fix ubiquity first
  <zyga> sure
  <mvo> sil2100: sorry for the delay, had a call - my mistake, console-conf is working!
  <Chipaca> mborzecki: ISTR gdbus was funny about how it interpreted arguments
  <mborzecki> Chipaca: i switched to busctl now, will push a commit in a minute
  <Chipaca> mborzecki: but you can specify the type
  <mborzecki> at least this one is explicit about the types
  <Chipaca> mborzecki: ah, good
  <zyga> mborzecki: what is the chance that with more debugging it will no longer fail ;-) ?
  <mborzecki> zyga: high :)
  <zyga> still, I'd love to merge it
  <zyga> to see what is wrong
  <zyga> I'm wary of merging your branch with extra kills and what not just because we don't know the problem yet
  <mborzecki> the upside is we'll know more the next time it appears
  <zyga> yes, exactly
  <mborzecki> zyga: i'll drop pkills
  <sil2100> mvo: \o/
  <sil2100> mvo: sweet!
  <sil2100> I'll prep a quick image for zyga in a moment for the db and upload it somewhere, since I'm at the office it should be a fast upload
  <zyga> cool
  <mborzecki> zyga: while pipe2 instead of socketpair in your pr?
  <zyga> no preference really
  <zyga> also no need to use sockets :-)
  <mborzecki> zyga: Chipaca: please take a look at #5994
  <mup> PR #5994: tests/main/interfaces-accounts-service: more debugging <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5994>
  <zyga> what is in dbus.env?
  <mborzecki> zyga: when you dbus-launch it spits some stuff you can eval in the shell to set the environment variables, now it's dumped to a file in case i need to use it in debug section
  <zyga> right
  <zyga> I know that,
  <zyga> what is there in practice :)
  <zyga> is it just a variable definition?
  <Chipaca> DBUS_SESSION_BUS_ADDRESS='unix:abstract=/tmp/dbus-QvYL1sZnrl,guid=78c09efa6f3ce976cbffb0a35bc5bc72';
  <Chipaca> export DBUS_SESSION_BUS_ADDRESS;
  <Chipaca> DBUS_SESSION_BUS_PID=25966;
  <Chipaca> DBUS_SESSION_BUS_WINDOWID=119537665;
  <mborzecki> zyga: https://paste.ubuntu.com/p/TTh392C3Bb/
  <zyga> aha, I see
  <zyga> thanks!
  <mborzecki> oh, windowid?
  <mborzecki> wonder why i don't have it
  <Chipaca> mborzecki: probably because I did it from within X and you didn't
  <zyga> mborzecki: my PR passed
  <zyga> let's merge it
  <zyga> man, I knew this would happen
  <mborzecki> Chipaca: hm did it in tmux, which was in turn started by systemd user session, maybe that's why
  <zyga> sil2100: flashing now
  <Chipaca> an extra downside of this accounts service silliness is that it took me a day to see a trivial bug in my shutdown pr
  <zyga> now let's reproduce the f*r
  <mup> PR snapd#5993 closed: tests: show list of processes when ifaces-accounts-service fails <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5993>
  <sil2100> zyga: thanks! Fingers crossed it's all resolved here as well
  <zyga> we will know soon
  <mup> PR snapd#5996 opened: [RFC] daemon: support `snap logs snapd` to get snapd logs <Created by mvo5> <https://github.com/snapcore/snapd/pull/5996>
  <mvo> cachio: good morning! new snapd 2.35.5 in beta - sorry for yet another dot release :/
  <mvo> cachio: but .4 is fine, this is just yet another fix on top
  <mup> PR snapd#5997 opened: ifacestate: simplify task chaining in ifacestate.Connect <Created by stolowski> <https://github.com/snapcore/snapd/pull/5997>
  <pstolowski> mborzecki: ^ the simplification you suggested in previous PRs
  <pstolowski> *PR
  <zyga> nice pstolowski :)
  <mborzecki> pstolowski: nice
  <zyga> sil2100, mvo: booting ...
  <zyga> fingers crossed
  <zyga> sil2100, mvo: no more crashes!
  <zyga> woot
  <mvo> zyga: yay
  <zyga> sil2100: what was the issue?
  <zyga> sil2100, mvo: although it does not crash I cannot actually connect to wifi
  <zyga> it times out all the time
  <zyga> (wifi dit not change)
  <mvo> zyga: same for me on my pi3-64
  <mvo> sil2100: -^
  <zyga> bor0en
  <zyga> or just broken
  <Chipaca> mvo: want me to give the appInfosFor a stab? I'm blocked waiting for spread otherwise :-)
  <Chipaca> bah, i've got other things i could do
  <Chipaca> like lunhc
  <Chipaca> lunch
  <Chipaca> but that's boring
  <zyga> sil2100: do you need that reported?
  <mup> PR snapd#5998 opened: osutil: tweak handling of error adduser errors <Created by mvo5> <https://github.com/snapcore/snapd/pull/5998>
  <mvo> Chipaca: app infos for as in 5996?
  <Chipaca> mvo: ah, yes :-)
  <mvo> Chipaca: I would not mind - but note its still an RFC PR that needs approval from gustavo
  <Chipaca> mvo: actually we could expose a pseudo-snap 'snapd' in /v2/snaps
  <mvo> Chipaca: that works for me
  <mvo> Chipaca: no strong opinion either way
  <Chipaca> mvo: snapInfosFor calls allLocalSnapInfos, if we make that one pseudo-snapd-aware, we get a consistent pseudo-snapd in the api (except you can't remove/refresh/etc it sometimes)
  <Chipaca> (the latter makes it awkward, i guess)
  <Chipaca> bah :)
  <Chipaca> it depends on what we want
  <Chipaca> i'll comment on the rfc
   * mvo nods
  <mvo> thank you!
  <pedronis> Chipaca: we have system and snapd (as pseudo but not quite things),  should snap logs system do the same,  do something?
  <pedronis> all of this is cute but without a plan it will get messy
  <zyga> snap logs system giving just snapd logs feels weird though
  <pedronis> yea, agreed
  <pedronis> also snapd will be a snap
  <zyga> but without services
  <zyga> so all kinds of weirdness
  <sil2100> zyga: yeah, not sure what's the reason for that not working, I think I also had wifi issues on my regular armhf rpi3 core18 last time
  <Chipaca> pedronis: zyga: FC on the RFC
  <sil2100> Not sure if that got reported somewhere
  <sil2100> I guess Paolo was looking at something like that?
  <pedronis> Chipaca: my C  is mostly that it probably needs a forum topic
  <Chipaca> sergiusens: what was the env var that dropped snap/snapcraft.yaml and manifest.yaml into the snap?
  <pedronis> Chipaca: I think  SNAPCRAFT_BUILD_INFO=1  from here:  https://forum.snapcraft.io/t/notifications-for-out-of-date-stage-packages/5161
  <Chipaca> thanks
  <sergiusens> Chipaca: I see you found it
  <Chipaca> sergiusens: yes, thanks
  <pstolowski> we're at the brink of opening 3rd page of PRs... would be good to land some
  <Chipaca> grep took me to the tests, and then samuele confirmed it :)
  <Chipaca> pstolowski: har har
  <sergiusens> Chipaca: hah, I thought you would have done a forum search first ð
  <Chipaca> pstolowski: dunno if you noticed but we've been fighting the spread tests since at least yesterday
  <mborzecki> pstolowski: well, stuff is blocked by travis atm
  <pstolowski> Chipaca: yes i'm aware
  <Chipaca> pstolowski: almost everything in the first page is red
  <mborzecki> hopefully we can land #5994 soon
  <Chipaca> so, i mean, sure it'd be nice to land stuff
  <mup> PR #5994: tests/main/interfaces-accounts-service: more debugging <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5994>
  <zyga> mborzecki: it failed in my PR
  <mborzecki> zyga: hm, which one?
  <zyga> https://www.irccloud.com/pastebin/OuTgkBZz/
  <zyga> https://github.com/snapcore/snapd/pull/5988
  <mup> PR #5988: cmd: rename ns_group to mount_ns <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/5988>
  <mborzecki> zyga: is that goa using 100MB of mem/
  <zyga> apparently
  <mborzecki> anyone willing to look at #5959 while we wait for PRs to be green again?
  <mup> PR #5959: systemd: extend Status() to work for socket and timer units <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5959>
  <zyga> mborzecki: done
  <mborzecki> zyga: thanks!
  <cachio> mvo, hi
  <cachio> sure
  <cachio> mvo, I'll make a run
  <zyga> mborzecki: I pushed https://github.com/snapcore/snapd/pull/5999
  <mup> PR #5999: tests: ensure that goa-daemon is off <Created by zyga> <https://github.com/snapcore/snapd/pull/5999>
  <zyga> not sure if this is a red herring or real
  <cachio> mvo, should we promote 35.4 to stable?
  <mup> PR snapd#5999 opened: tests: ensure that goa-daemon is off <Created by zyga> <https://github.com/snapcore/snapd/pull/5999>
  <pstolowski> Chipaca: #5961 gtg
  <mup> PR #5961: snap/pack, snap/squashfs: use type to determine mksquashfs args <Created by chipaca> <https://github.com/snapcore/snapd/pull/5961>
  <mborzecki> zyga: i'm not sure it's a problem though, the original error is Error: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Type of message, '(ssssa{ss})', does not match expected type '(sssa{sv}a{ss})', so the expected type is correct and matches what busctl introspect shows
  <mborzecki> zyga: the mystery is why gdbus came up with (ssssa{ss})
  <mborzecki> zyga: it's like it's treating '{}' as s instead ov a{..}
  <mborzecki> and only occasionally
  <mborzecki> off to pick up the kids
  <dot-tobias> Hi everyone
  <zyga> hey
  <sil2100> mvo, zyga: another good news - we seem to have everything for enabling core18 dailies, so I'll do that once we spin out latest RC images for cosmic
  <sil2100> As I don't want to eat up precious resources before we're done with those
  <zyga> sil2100: ok let me know if you need any more testing
  <mup> PR snapcraft#2355 closed: extensions: cleanup and generic tests <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2355>
  <mup> PR snapd#6000 opened: snap,client: use a different exit code for retryable errors <Created by mvo5> <https://github.com/snapcore/snapd/pull/6000>
  <mvo> cachio: yeah, 2.35.4 can go to stable
  <Chipaca> mvo: do you need #5986 squashed?
  <mup> PR #5986: data/systemd, wrappers: tweak system-shutdown helper for core18 <Simple ð> <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5986>
  <mvo> sil2100: nice, thanks!
  <mvo> sil2100: did our 2.35.5 snapd upload from cosmisc-proposed made it?
  <Chipaca> also dunno what makes gdbus go ssssa{ss} instead of sssa{sv}a{ss} but it looks like it's over it for a bit
  <Chipaca> :-(
  <mvo> Chipaca: yes, please squash 5986 it will be needed for 2.36
  <mvo> Chipaca: and thanks for this PR, nice job!
  <Chipaca> mvo: should i retarget it? (it's currently targetted to 2.35)
  <Chipaca> targeted*
  <mvo> Chipaca: yeah, I really really job we are done with 2.35
  <Chipaca> :)
  <mvo> pedronis: I pushed a PR for the retryable errors, iirc field was askign for this in the context of auto-connect (just fyi)
  <dot-tobias> ogra: I'm trying to rotate the HDMI display connected to my Pi 3B running Core edge (edge because I need the mir-kiosk snap). setting pi-config.display-rotate=1 and then rebooting seems to bog the system, it does not boot up at all anymore. Removing the option from config.txt (SD inserted into the reader on my main machine) allows proper boot again. This does not occur on Core stable. Is this known or should I open a forum thread? Couldn't find
  <dot-tobias>  anything there.
  <mup> PR snapd#5986 closed: data/systemd, wrappers: tweak system-shutdown helper for core18 <Simple ð> <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5986>
  <mup> PR snapcraft#2356 opened: nodejs plugin: add support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2356>
  <Chipaca> pstolowski: thanks for the review! I'll add a comment to Alike in a followup (but note it's only there for tests)
  <pstolowski> Chipaca: k, yes, i know it's for test
  <pedronis> mvo: ah, I see, was confused for a second (too many problems with similar terms)
  <mup> PR snapd#5961 closed: snap/pack, snap/squashfs: use type to determine mksquashfs args <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5961>
  <jdstrand> mvo: hey, do you want a 2.36 branch for PR 5989?
  <zyga> error: cannot communicate with server: Post http://localhost/v2/snaps: write unix @->/run/snapd.socket: write: broken pipe
  <mup> PR #5989: interfaces/system-key: add parser mtime and only discover features on write <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5989>
  <zyga> man, my trivial PR is red for 40 hours over random stuff
  <jdstrand> zyga: hey, I know the feeling
  <zyga> yeah :|
  <jdstrand> "do I really want to fix that typo?" ;)
  <zyga> mvo: the graceful restart thing, is that a thing?
  <zyga> graceful restart breaking snap install (perhaps) https://www.irccloud.com/pastebin/6cblPVl4/
  <zyga> jdstrand: "let's start with this simple PR"
  <jdstrand> zyga: "I'll just merge from trunk"
  <zyga> jdstrand: I actually tried to debug various failures
  <jdstrand> zyga: I see you are looking at the accounts-service ones. thanks!
  <zyga> but this is not the very best of Tuesdays
  <jdstrand> been seeing those a lot
  <mvo> jdstrand: yes please - 2.36 for 5989
  <mvo> zyga: hm, the graceful stop breaks? or start? the log you pasted looks harmless?
  <mborzecki> re
  <zyga> snap install died on unix socket hangup
  <zyga> error: cannot communicate with server: Post http://localhost/v2/snaps: write unix @->/run/snapd.socket: write: broken pipe
  <mvo> zyga: oh? do you have more details?
  <mborzecki> zyga: got journactl of snapd?
  <zyga> doesn't look transparent
  <zyga> https://api.travis-ci.org/v3/job/441691823/log.txt
  <mvo> zyga: thanks, let me look
  <zyga> look for "error executing" please
  <zyga> save the log guys, I really want to land and iterate :/
  <zyga> so I want to restart that job
  <zyga> just tell me when please
  <mvo> zyga: right, I see the error
  <zyga> mborzecki: ready?
  <mborzecki> zyga: yeah
  <zyga> restarting job
  <mborzecki> mvo: isn't that just snap (the client) polling and hitting /run/snapd.sock with some unfortunate timing?
  <mvo> mborzecki: the log looks odd, it looks like core got installed
  <mvo> mborzecki: and with a snap snapd should not go into stop mode
  <mvo> mborzecki: aha, no - just the core configureation, hm
  <mvo> mborzecki: maybe it is just unfortunate timing
  <mvo> mborzecki: which still sucks :/
  <zyga> mvo: I'm more and more convinced we should do something with systemd to ensure we can shut down gracefully
  <zyga> (that is, pass the fd back and exit)
  <zyga> and then let systemd handle the grace period where we are going down
  <mvo> zyga: right, I'm not sure how to do that race-free yet, I am looking into a test to reproduce the current issue now
  <mborzecki> zyga: afaiu this is a remote end doing shutdown on a connection
  <pedronis> niemeyer: mvo: hi, reminder that I have a conflict with the standup
  <zyga> mvo: did you look at sd_pid_notify_with_fds ?
  <niemeyer> pedronis: Ack, thanks
  <mvo> zyga: I did not
  <mvo> zyga: thank you, I have a look now
  <mvo> zyga: aha, neat, that looks interessting
  <mborzecki> https://github.com/snapcore/snapd/pull/5994 is green, land it?
  <mup> PR #5994: tests/main/interfaces-accounts-service: more debugging <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5994>
  <mup> PR snapcraft#2357 opened: scons plugin: add support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2357>
  <mup> PR snapd#6001 opened: interfaces: typo 'allows' for consistency with other ifaces <Created by zyga> <https://github.com/snapcore/snapd/pull/6001>
  <mup> PR snapd#5994 closed: tests/main/interfaces-accounts-service: more debugging <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5994>
  <mup> PR snapd#5988 closed: cmd: rename ns_group to mount_ns <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5988>
  <mborzecki> https://paste.ubuntu.com/p/3D95h34pXs/
  <mborzecki> heh, so i broke dbus/gdbus/goa https://paste.ubuntu.com/p/4bF95krMWf/
  <mup> PR snapd#5995 closed: tests/main/interfaces-accounts-service: switch to manual while we debug the test <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/5995>
  <mup> PR snapd#6002 opened: interfaces/system-key: add parser mtime and only discover features on write - 2.36 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6002>
  <Chipaca> mborzecki: the dbus snakes are attacking
  <pstolowski> zyga: might be worth re-running the tests on 5170, they were last run 19 days ago
  <zyga> pstolowski: great point
  <zyga> pstolowski: they will fail on accounts service ;-)
  <pstolowski> :)
  <mup> PR snapd#5998 closed: osutil: tweak handling of error adduser errors <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5998>
  <jdstrand> mvo: fyi, https://github.com/snapcore/snapd/pull/6002/
  <mvo> jdstrand: thank you!
  <mup> PR #6002: interfaces/system-key: add parser mtime and only discover features on write - 2.36 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6002>
  <jdstrand> mvo: fyi, I'll let you decide on PR 5980, PR 5981 and PR 5982 for 2.36 (I'm not pushing for it-- might be nice to have more testing), but it would be nice if they were in trunk by SLC
  <mup> PR #5980: interfaces/apparmor: conditionally add explicit deny rules for ptrace <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5980>
  <mup> PR #5981: interfaces/many: updates to support k8s worker nodes <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5981>
  <mup> PR #5982: interfaces/many: conditionally use 'unsafe' with docker-support change_profile rules <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5982>
  <jdstrand> mvo: that's just an fyi for what I'm thinking about. I know you're busy, so whatever you decide
  <sergiusens> mvo: cachio are are your travis pull requests just stalled? A quick check on your PR run tells me so, our are too ð¢
  <cachio> sergiusens, we have several on the queue
  <sergiusens> but none are running right? just waiting?
  <cachio> 2 running
  <cachio> the rest waiting
  <cachio> 3 running
  <sergiusens> ah, I see, closer to the bottom https://travis-ci.org/snapcore/snapd/pull_requests
  <cachio> :)
  <sergiusens> mvo: what is the ETA for core16 coming to stable? Not rushing, just getting my ducks aligned ð
  <zyga> Chipaca, mvo: shall we land the .po update?
  <Chipaca> zyga: I'm not sure I can +1 it at this point :)
  <mvo> sergiusens: thats a sil2100 question now :)
  <mvo> sergiusens: foundations works on this
  <mvo> zyga: yes
  <mvo> Chipaca: no? why not?
  <Chipaca> zyga: mvo: but I +1 the ones mvo committed
  <Chipaca> mvo: 5 commits,  4 by me
  <mvo> Chipaca: haha
  <mvo> Chipaca: ok
  <Chipaca> there, I +1'ed it :)
  <mup> PR snapd#5935 closed: po: sync translations from launchpad <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5935>
  <mvo> thanks zyga
  <mborzecki> hm i can reproduce the problem with dbus when goa-daemon is in the process of dying and a call is made, at least in that situation busctl delivers more meaningful error message
  <mborzecki> still, we do not kill goa-daemon in the test
  <mvo> mborzecki: nice
  <zyga> mborzecki: my PR has kills it
  <Chipaca> zyga: mvo: #5980 has two +1's (from you two), is green, but jdstrand said it was ready for re-review. Seems to me to be a quick one :)
  <mup> PR #5980: interfaces/apparmor: conditionally add explicit deny rules for ptrace <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5980>
  <sil2100> mvo, sergiusens: aaaaa, for core16 it's well, not foundations as far as I know
  <sil2100> mvo, sergiusens: since I don't have upload access for core16 in the store or even snap recipe access (AFAIK)
  <mvo> sil2100: for core16 it is - for "core" (without the 16) we are still in charge
  <sergiusens> mvo feels like it might still be your problem if only to transition correctly ð
  <mvo> sil2100: sounds like we need to fix the access :)
  <Chipaca> I could use reviews on #5957 (it unblocks #5955)
  <mup> PR #5957: overlord/snapshotstate/backend: fall back on sudo when no runuser <Snapshots ð¸ó > <Created by chipaca> <https://github.com/snapcore/snapd/pull/5957>
  <mup> PR #5955:  cmd/snap, tests: snapshots for all <Snapshots ð¸ó > <â Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5955>
  <mvo> sil2100: snap recipe is here https://github.com/snapcore/core16
  <mvo> sil2100: and you should have store access now :)
  <sil2100> mvo: thank you!
  <mvo> sil2100: let me know if I can help, sorry if my earlier reply to sergiusens  sounded strange, I think for core16 we need the same mechanisms as for core18, i.e. a watcher that scans for package changes and that then triggers a core16 build plus some (auto) testing
  <sil2100> mvo: sure! The script for core18 is ready btw., just waiting for some time to poke Steve about a nice comfy place for it to be on
  <sil2100> Hopefully I won't have to create a new instance for it, my mojo mojo is weak
  <mvo> sil2100: cool
  <mvo> sil2100: yeah, I had the same problem with my cnf-extractor-charm - fortunately I was rescued by IS
  <mvo> sil2100: speaking of this, thats something I need to talk to steve about as well :)
  <mvo> sil2100: anyway, none of your concerns (most likely)
  <tomwardill> hello! A question, what happens if a snap pre-refresh hook fails? Can it abort the refresh and continue with the existing installed version?
  <Chipaca> tomwardill: yes
  <pstolowski> tomwardill: it should work that way yes, are you experiencing something else?
  <tomwardill> Chipaca, pstolowski: We've not tried yet, was just checking if it worked that way
  <tomwardill> is it just a case of exit(1) from the hook?
  <Chipaca> tomwardill: yep
  <tomwardill> excellent, thanks.
  <Chipaca> at least that's what the integration test uses :-)
  <sil2100> sergiusens: anyway, we weren't looking at core16 recently yet
  <sil2100> sergiusens: so I guess it
  <sil2100> argh, I guess it
  <sil2100> (keyboard errors)
  <sil2100> I guess it'll still take a bit
  <sil2100> Since you mentioned it now, I'm doing an image test build to see what's the current state
  <mup> PR snapd#6003 opened: cmd/snap: block 'snap help <cmd> --all' <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6003>
  <Chipaca> hmm, hmm, snap refresh --offline
  <pedronis> Chipaca: what would that do ?
  <Chipaca> pedronis: remember apt-zip?
  <pedronis> no
  <Chipaca> https://wiki.debian.org/AptZip
  <pedronis> I see
  <Chipaca> pedronis: context is a person in the forum in 'the heart of africa' (says their profile), 3rd world with intermittent energy and connectivity, wanting to only talk to the store once and get everything for multiple devices
  <Chipaca> pedronis: I tagged you in one of the topics on this, there's a second (linked to that one)
  <Chipaca> anyway, i'm off for a bit
  <mup> PR snapd#6004 opened: cmd/snap-confine: reduce verbosity of debug and error messages <Created by zyga> <https://github.com/snapcore/snapd/pull/6004>
  <jdstrand> mvo: I think this is what sergiusens may have been reporting. it looks like my 5981, 5989 and 6002 PRs are 'stuck'. 'Details' show all green for 5981, shows spread at 6 minutes for 5989 (did that restart?) and show nothing started for 6002
  <jdstrand> mvo: let me know if I should do something
  <zyga> dpkg-deb: error: <compress> from tar -cf subprocess was killed by signal (Illegal instruction), core dumped
  <zyga> that's a new error
  <mup> PR snapd#5992 closed: release: merge 2.35.5 changes into the 2.36 branch <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5992>
  <mvo> jdstrand: sorry for the slow reply - "stuck> not sure what we can do, I poke around a bit
  <zyga> hey mvo
  <zyga> back from sports?
  <mvo> zyga: yes
  <zyga> mvo: I wonder if I can and 6001 today
  <zyga> mvo: there's a deadlock in one of the tests: https://api.travis-ci.org/v3/job/442145572/log.txt
  <mvo> zyga: urgh
  <zyga> look for PC=0x5626a1bf1aa1
  <mvo> zyga: hrm, hrm, its not even clear where it hangs
  <jdstrand> mvo: no worries. let me know if I need to mash any buttons or anything
  <zyga> mvo: if still here can I land 5999
  <zyga> jdstrand: I know there are other priority things on your plate but gentle ping about the oldest open PR: https://github.com/snapcore/snapd/pull/5170
  <mup> PR #5170: interfaces/builtin: add adb interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5170>
  <mup> PR snapcraft#2357 closed: scons plugin: add support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2357>
  <jdstrand> yes. it seems like it, but it isn't forgotten
  <zyga> that's great, I'll try to review your PRs tomorrow
  <zyga> jdstrand: I sent a rewording PR for snap-confine but it's just about making the debug and error messages more consistent so I didn't request your review on anything
  <zyga> there's a 2nd PR about IPC tweak (upgrading eventfd to a full pipe) so that the helper can do more
  <zyga> I don't think this is security critical either but if you want I can request your review
  <zyga> though I'd rather not really since it's just the start and I have more after that and it would probably not land this week
  <jdstrand> zyga: are they all static messages or is there string handling in the debug/error messages that changed?
  <jdstrand> s/is there/are there/
  <zyga> nothing new
  <zyga> just changing existing strings
  <zyga> no more string manipulation
  <zyga> (actually less, I remove some of the repeating arguments we keep saying over and over, like snap name)
  <zyga> In general I tried to make it more terse and more useful
  <mup> PR snapd#5980 closed: interfaces/apparmor: conditionally add explicit deny rules for ptrace <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5980>
  <zyga> jdstrand: can you please merge master into 5982
  <zyga> mvo: FYI: another PR had a deadlock in cmd/snap, something to be wary of
  <zyga> jdstrand: and 5981 please
  <zyga> ok, I gotta go
  <zyga> promised to watch Han Solo with my son :)
  <zyga> ttyl
  <jdstrand> zyga: nice, thanks! :)
  <jdstrand> zyga: enjoy :)
   * jdstrand wonders why 5981 is showing changes to master that were merged in 5980
  <jdstrand> after merging master
  <jdstrand> oh, it idn't have it yet
  <jdstrand> weird
  <mup> PR snapcraft#2358 opened: dotnet plugin: add support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2358>
  <mvo> zyga: same package the deadlock?
  <mvo> zyga: might be worth running it with go test -count 1000
  <Chipaca> zyga: deadlock?
  <Chipaca> ah
  <Chipaca> han solo wins
  <slvn_> Hey, my 10 snaps games are published for a while. Only two of them appear in the listing of snapcraft.io
  <mup> PR snapd#6005 opened: snap/pack, snap/squashfs: remove extra copy before mksquashfs <Created by chipaca> <https://github.com/snapcore/snapd/pull/6005>
  <mup> PR snapd#6006 opened: tests: move spread-shellcheck to run-checks --static <Created by chipaca> <https://github.com/snapcore/snapd/pull/6006>
  <mup> PR snapcraft#2359 opened: [WIP] extensions: add glib <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2359>
  #snappy 2018-10-17
  <mup> PR snapd#5969 closed: apparmor: add unit test for probeAppArmorParser and simplify code  <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5969>
  <mup> PR snapcraft#2356 closed: nodejs plugin: add support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2356>
  <mborzecki> morning
  <zyga>  Good morning
  <mborzecki> zyga: hey
  <zyga> Cold morning
  <mvo> hey zyga
  <zyga> Hey, how are you?
  <mvo> zyga: good, thank you - how are you?
  <mborzecki> mvo: morning
  <zyga> Good, last evening was fun :-) we loved the movie
  <mvo> hey mborzecki
  <mvo> lots of green tests today?
  <mborzecki> finally :)
  <mup> PR snapd#5948 closed: asserts, image: ensure kernel, gadget, base and required-snaps use valid snap names <Parallel installs â> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5948>
  <mup> PR snapd#6003 closed: cmd/snap: block 'snap help <cmd> --all' <Simple ð> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6003>
  <mup> PR snapd#6005 closed: snap/pack, snap/squashfs: remove extra copy before mksquashfs <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6005>
  <mup> PR snapd#5999 closed: tests: ensure that goa-daemon is off <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5999>
  <slvn_> Hey, my 10 snaps games are published for a while. Only two of them appear in the listing of snapcraft.io when searching in "Games", but appears in "All snaps". It seems Categories Game is not correctly detected. It happens also for many other Snaps.
  <zyga> Hey, slvn_ - I would recommend to ask in the four of you donât get a reply here. It is still early and store people are in other time zones as well
  <mborzecki> slvn_: s/four/forum/
  <zyga> But do come back if you donât get a reply! Thank you for making snaps :-)
   * zyga responds from a phone
  <pstolowski> mornings
  <zyga> DzieÅ dobry
  <mup> PR snapd#5997 closed: ifacestate: simplify task chaining in ifacestate.Connect <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5997>
  <slvn_> thanks, ok! I'll repost in a few hours
  <mborzecki> pstolowski: czeÅÄ :)
  <zyga> guten tag mvo :)
  <zyga> (not to force one minority language upon others)
  <mborzecki> https://www.reddit.com/r/linux/comments/9ool14/xdgportal_support_landed_on_firefox_nightly/
  <zyga> that's cool
  <mborzecki> Download (curl) error for 'http://download.opensuse.org/update/leap/42.3/oss/x86_64/libgcrypt20-32bit-1.6.1-45.1.x86_64.rpm':
  <mborzecki> heh
  <slvn_> zyga, btw, who should be contacted for http://snapcraft.io issue ?
  <sparkiegeek> slvn_: if you look in the footer, you'll see links to where to file bugs
  <mup> PR snapd#5979 closed: install: don't start disabled services <Squash-merge> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5979>
  <zyga> mvo: could you please review https://github.com/snapcore/snapd/pull/5727 - this is affecting Firefox in the wild and it would be good to have in 2.36
  <mup> PR #5727: interfaces/builtin, cmd/snap-seccomp: Allow read-only ptrace, for the Breakpad crash reporter <Created by jld> <https://github.com/snapcore/snapd/pull/5727>
  <mvo> zyga: this is waiting for a security review, no? happy to do a review but it seems we need jamie, no?
  <zyga> yeah, I suppose you are right
  <zyga> https://github.com/snapcore/snapd/pull/6004 is green and I'd love to land it - it is just tweaking debug messages
  <mup> PR #6004: cmd/snap-confine: reduce verbosity of debug and error messages <Created by zyga> <https://github.com/snapcore/snapd/pull/6004>
   * zyga goes to bring a heater into the office
  <zyga> I miss the days of Pentium 4 heaters
  <sil2100> mvo, zyga: hey, could you fill in a bug for the non-working wifi here if you have a moment? https://bugs.launchpad.net/snap-core18
  <zyga> sure
  <zyga> wow
  <zyga> no bugs
  <zyga> must be some decent software!
  <mborzecki> Chipaca: what if we move static checks to a separate job?
  <sil2100> (/me deletes all bugs after they pop up)
  <mvo> sil2100: added a bug (cc zyga)
  <mborzecki> Chipaca: unit tests already take ~8 minutes, so the stage is 8+ minutes anyway
  <zyga> oh
  <zyga> do you want both? :)
  <zyga> I just wrote mine but haven't sent it
  <zyga> well, you have two now
  <mvo> :)
  <mvo> sorry!
  <Chipaca> mborzecki: 1/8th is still a serious chunk in the wrong direction
  <Chipaca> mborzecki: static checks in a separate job would work, but I worry about using too many jobs
  <mborzecki> Chipaca: if you take the 1-2m off unit tests & static checks, and put it in a separate job, the total of the 1st stage should not be significantly affected
  <mborzecki> Chipaca: probably only way to know is to arrange it that way :)
  <Chipaca> mborzecki: I'll do it, and then we see :-)
  <mborzecki> Chipaca: ok
  <Chipaca> static checks shouldn't need the build-dep
  <mborzecki> hm we do run some go tools as static checks though
  <mborzecki> misspel, vet?
  <Chipaca> a lot
  <Chipaca> but go is there already
  <Chipaca> we need the build deps for the c libs
  <mborzecki> oh, btw. i had that branch with gometalinter a while ago
  <Chipaca> also we could move the travis-sie unit tests to 1.10 and it might be a little bit faster
  <Chipaca> travis-side*
  <Chipaca> and, yes i can install shellcheck from snap, will need to tweak the python to look there first
  <Chipaca> or fiddle with PATH
  <Chipaca> hm
  <mborzecki> you can set SHELLCHECK=/some/path for spread-shellcheck
  <mborzecki> uh, or not
  <Chipaca> :-)
  <mborzecki> ok, that should be a trivial change :P
  <mvo> sil2100: added one more for you in snap-core18 bugs :)
  <mborzecki> there's SHELLCHECK_SHELL which is kind of useless because spread does bash anywya
  <sil2100> mvo: thanks! ;)
  <sil2100> The more bugs the merrier, right?!
  <Chipaca> mborzecki: doesn't spread run with -u on also?
  <mup> PR snapd#6001 closed: interfaces: typo 'allows' for consistency with other ifaces <Simple ð> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6001>
  <sil2100> mvo, zyga: btw... core18 dailies! http://cdimage.ubuntu.com/ubuntu-core/18/pending/
  <zyga> thanks pawel!
  <sil2100> (didn't check if they actually work yet, since still sprinting)
  <zyga> I can check later today
  <mvo> sil2100: nice! build from what channel?
  <mvo> sil2100: good stuff in any case
  <sil2100> mvo: edge by default as for 16
  <mborzecki> Chipaca: yup, looks like -u is set
  <mvo> sil2100: interessting, thats a pretty high risk level. I wonder if we should reconsider this as the default (more so if that the default for uc16)
  <mvo> sil2100: but not now :)
  <sil2100> It's a daily, it's like how we usually build regular images with PROPOSED enabled
  <sil2100> But yeah, we can have a discussion about that, right now an edge-build is just what we need for testing purposes!
  <mvo> sil2100: ok, if it matches then thats ok I guess. edge is very edgy, probably more so than proposed. but not supper important right now
  <mvo> sil2100: +1 :)
  <sil2100> Like the edge is edgy idea ;)
  <mvo> sil2100: in the (very) old days the term was "crack of the day" :P but of course for our stuff the CI is a huge and effective filter so that term does no longer make sense (still amusing though)
  <mvo> sil2100: anyway, great progress, thank you!
  <mvo> sil2100: does it also include detection of changes in the core18 packageset? or is that something that will come later?
  <alocer> i m having font problems. no fonts are availble when using colibri or flock-chat in snap. i m on fedora 28 selinux disabled.
  <alocer> tryed to mount the font directories as specified in mount-snap.fstab but not succeeded.
  <alocer> any idea
  <Chipaca> mborzecki: hehe, if I run the checks using apt-provided shellcheck on 16.04, that shellcheck has no -x option, so the lack of a stdout lock makes it look like it's had too many mushrooms
  <Chipaca> mborzecki: e.g.,
  <Chipaca> el l =SHELL-NAeM CEO  D E1 , C O D E2Sp..e c ify-- edxicalluedce=tC (ODbEa1s,hC,OsDh,Ek2.s.h )
  <mvo> Chipaca: lol
  <zyga> mborzecki: thanks for the review, updated
  <mborzecki> Chipaca: haha
  <zyga> https://github.com/features/actions <- missing a "push to snap store"
  <niemeyer> Yo
  <Chipaca> Wa
  <niemeyer> zyga: Yeah, I thought the same thing when I saw it.. this opens up some nice possibilities
  <zyga> I don't know if this is powered by or simply integrated with hashicorp tech though
  <zyga> but something to look at for sure
  <zyga> Chipaca: did you see https://bugs.launchpad.net/snapd/+bug/1796125
  <mup> Bug #1796125: services in a snap with dependencies aren't started in correct order on install <snapd:New> <https://launchpad.net/bugs/1796125>
  <mborzecki> anyone up for a review of #5959?
  <mup> PR #5959: systemd: extend Status() to work for socket and timer units <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5959>
  <zyga> looking
  <zyga> ah
  <zyga> I did :<
  <zyga> sorry
  <zyga> mborzecki: it has a conflict
  <Chipaca> I could really use reviews on #5957
  <mup> PR #5957: overlord/snapshotstate/backend: fall back on sudo when no runuser <Snapshots ð¸ó > <Created by chipaca> <https://github.com/snapcore/snapd/pull/5957>
  <mborzecki> zyga: didn't notice, thanks
  <mborzecki> and pushed
  <pstolowski> zyga: commented on ipc/helper pr
  <zyga> thanks
  <zyga> pstolowski: replied, thank you
  <niemeyer> zyga: I think it's completely unrelated to HashiCorp.. they just reused the HCL, which is a JSON-like format that is nicer to type by hand
  <zyga> ah, I didn't know that
  <mborzecki> zyga: Chipaca: left a note in #1796125, looks like this is a problem in systemd but i has gone unnoticed for years now, doesn't change the fact we should do something about that
  <niemeyer> It's a nice format..
  <mup> Bug #1796125: services in a snap with dependencies aren't started in correct order on install <snapd:New> <https://launchpad.net/bugs/1796125>
  <alocer> just trying to figure out what fonts does and snap app use ?
  <mborzecki> zyga: Chipaca: btw. https://github.com/systemd/systemd/pull/7947 is fun to read
  <mup> PR systemd/systemd#7947: man: systemctl doesn't operate multiple units in a single transaction <documentation> <Created by johnlinp> <https://github.com/systemd/systemd/pull/7947>
  <mborzecki> fwiw https://lists.freedesktop.org/archives/systemd-devel/2018-January/040122.html is fun too
  <Chipaca> alocer: sorry, what's that again?
  <Chipaca> mborzecki: sounds like we need to work around the systemd bug by ordering things ourselves as well
  <Chipaca> mborzecki: zyga: either of you have a fedora 28 so you could look into reproducing alocer's issue?
  <mborzecki> Chipaca: either that or adding Requires/RequiredBy
  <Chipaca> mborzecki: requires/requiredby means you can't stop one without t'other
  <zyga> Chipaca: hmm? which issue is taht
  <mborzecki> Chipaca: yeah
  <Chipaca> alocer: what's the output of 'snap version'?
  <Chipaca> zyga: no fonts in colibri
  <mborzecki> zyga: fonts ^^ ~10:53
  <zyga> mborzecki: wow, I don't see that message, can you paste it again
  <zyga> IRC WTH?
  <Chipaca> zyga: search for alocer?
  <zyga> Chipaca: I looked
  <Chipaca> zyga: IRC is fine, your async client is wacko
  <mborzecki> 10:55:20      alocer | any idea
  <Chipaca> <alocer> i m having font problems. no fonts are availble when using colibri or flock-chat in snap. i m on fedora 28 selinux disabled.
  <Chipaca> <alocer> tryed to mount the font directories as specified in mount-snap.fstab but not succeeded.
  <Chipaca> zyga: ^
  <zyga> thanks
   * zyga looks
  <zyga> alocer: hold on please
  <zyga> alocer: so just install colibri and run it?
  <Chipaca> zyga: seriously it's not the first time i see irccloud mess up basic message delivery on you
  <zyga> alocer quit on ping timeout here
  <zyga> :/
  <Chipaca> zyga: here as well
  <zyga> hmm https://www.irccloud.com/pastebin/uC4kEeDp/
  <zyga> I see a gazillion fonts in /usr/share/fonts
  <zyga> when I do snap run --shell colibri I cannot get the app to start
  <zyga> desktophelpers quit
  <zyga> as I cannot reproduce the issue and I suspect the desktop-launch is at fault I would recommend someone that maintains it to look deeper
  <zyga> I can launch colibri by running the real command though
   * zyga sighs that pastebinit is broken out of the box for several releases on fedora :/
  <zyga> willcooke: hey, do you know who maintains desktop-launch?
  <zyga> https://paste.ubuntu.com/p/bCfTD2k65M/ <- shellcheck on the desktop helpers
  <zyga> I didn't investigate what failed
  <willcooke> zyga, kenvandine
  <zyga> thanks!
  <willcooke> zyga, well, desktop team, but Ken is the main man
  <zyga> kenvandine: hey, could you give me a hand debugging app startup issue on fedora
  <zyga> I can run the app just fine manually in snap run --shell
  <zyga> but when invoked through desktop-launch it doesn't start at all
  <zyga> willcooke: super, I'll work with ken on this
  <willcooke> oSoMoN, are you able to offer any advice there too? ^
  <oSoMoN> zyga, maybe I can help, how does it fail?
  <zyga> oSoMoN: prints nothing at all
  <zyga> let me see if I can massage it to run with set -x
  <zyga> oSoMoN: https://paste.ubuntu.com/p/cjHb2cGhMg/
  <zyga> this is from snap run --shell
  <zyga> oSoMoN: if I just run ./colibri it does start
  <zyga> but fonts look wrong
  <zyga> and it shows this text:
  <zyga> colibri invoked without desktop helpers on fedora 28 https://www.irccloud.com/pastebin/XP18dwTR/
  <oSoMoN> zyga, so it looks like it's going through the entire desktop-launch script fine, and then fails on the exec?
  <zyga> dunno
  <mborzecki> zyga: the fonts look a bit odd here too, a bit fuzzy i'd say
  <zyga> I see huge fonts
  <zyga> btw I have a hi-dpi setup
  <mborzecki> and the size is off too
  <oSoMoN> zyga, can you comment out all of the contents of desktop-launch but the last line (exec), and see if that works?
  <zyga> pstolowski: can you look at https://github.com/snapcore/snapd/pull/6004#discussion_r225866841 please
  <mup> PR #6004: cmd/snap-confine: reduce verbosity of debug and error messages <Created by zyga> <https://github.com/snapcore/snapd/pull/6004>
  <zyga> oSoMoN: sure
  <zyga> oSoMoN: done, what did you expect to happen?
  <zyga> I got https://paste.ubuntu.com/p/BbTqzyXmCt/
  <pstolowski> zyga: replied
  <zyga> ++ cat /home/zyga/snap/colibri/8/.config/user-dirs.dirs.md5sum
  <zyga> + [[ 7b7b9530d5860d479bc2941ec3351c69  - != \7\b\7\b\9\5\3\0\d\5\8\6\0\d\4\7\9\b\c\2\9\4\1\e\c\3\3\5\1\c\6\9\ \ \- ]]
  <zyga>  
  <zyga> this looks ... od?
  <zyga> odd
  <pstolowski> sorry for confusion ;)
  <zyga> thanks, will do :)
  <zyga> oSoMoN: I'n not an expert on the desktop stack but since this is a shell script and I am terrible with shell I started by running shellcheck on it, perhaps it would be good to look at the list and see if anything could be a factor
  <oSoMoN> zyga, I'm not a shell script expert either
  <oSoMoN> zyga, I meant to comment out everything except for the last line, looks like you did the opposite
  <zyga> wait, what?
  <zyga> so just exec?
  <zyga> if so then I tried that and then the application does start
  <zyga> so something set along the way makes it not start
  <mvo> niemeyer: could you please add github.com/snapcore/classic-snap to the list of things that mup watches?
  <niemeyer> mvo: Of course
  <mvo> thank you
  <mvo> https://github.com/snapcore/classic-snap/pull/20 is the PR that made me ask about it. reviews welcome :)
  <mup> PR classic-snap#20: port classic to UC18 <Created by mvo5> <https://github.com/snapcore/classic-snap/pull/20>
  <niemeyer> mvo: That's done
  <mvo> ta
  <niemeyer> Woah...
  <niemeyer> https://usercontent.irccloud-cdn.com/file/WHV6Qd8P/image.png
  <niemeyer> That makes the day...
  <mvo> niemeyer: yeah! Chipaca already used it to fix typos :)
  <niemeyer> Super cool
  <Chipaca> :-)
   * Chipaca wonders if "you will be attributed in the commit" is satisfied by a commit log of "$you is a fool"
  <zyga> mvo: reviewed
  <zyga> niemeyer: yeah, I saw that too, it's awesome to have that :)
  <zyga> perfect for typo and other things
  <Chipaca> mborzecki: snaps work on travis, but snapd isn't there by default. shellcheck on travis is 0.46, which is sufficiently new i think?
  <Chipaca> mborzecki: it's not 0.50, but 0.50 isn't even out yet :)
  <oSoMoN> zyga, can I easily reproduce in a fedora VM, or does this require some preliminary set-up?
  <zyga> oSoMoN: just install and run
  <oSoMoN> ok, I'll try that
  <zyga> thanks! let me know if I can help
  <oSoMoN> I'm downloading a fedora ISO, I'll let you know when I reproduce the issue and start investigating it
  <zyga> ok
  <mborzecki> Chipaca: any chance of getting a more recent version? iirc 0.5 i had here was more picky about out code than the version in 18.04 which is 0.4.6
  <Chipaca> mborzecki: grmbl. ok.
  <Chipaca> indeed 0.4.6 not 0.46
  <mborzecki> hm to do start the after/before services correctly then, we'd need to do the topo sort again
  <mborzecki> s/to do/to/
  <mborzecki> wonder if we could make that sort generic, iirc zyga will need something like this for mounts
  <zyga> yes please
  <zyga> we shoud
  <zyga> lattice or whatever
  <Chipaca> mborzecki: remind me, do we validate before/afters?
  <Chipaca> for cycles, i mean
  <mborzecki> Chipaca: yes, we do the 'sorting' but we're more interested in finding cycles
  <Chipaca> ah ok
  <mborzecki> Chipaca: but the algo is there
  <mborzecki> iirc we're using kahn
  <Chipaca> hah, validateAppOrderCycles
  <Chipaca> "mÃ¡s claro, echale agua"
  <mborzecki> i added it so i should probably be the one to fix it now :)
  <Chipaca> mborzecki: it's a lovely little algo tho
  <Chipaca> _please_ can i have reviews of #5957
  <mup> PR #5957: overlord/snapshotstate/backend: fall back on sudo when no runuser <Snapshots ð¸ó > <Created by chipaca> <https://github.com/snapcore/snapd/pull/5957>
  <Chipaca> pedronis: what's #5712 waiting for?
  <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>
  <pedronis> Chipaca: more tests and a refactoring
  <pedronis> Chipaca: related to the Validate*Flags helpers, if you remember I used them more uniformly now
  <Chipaca> pedronis: ah. Should it get marked Blocked?
  <Chipaca> otherwise a trigger-happy me might merge it :)
  <pedronis> Chipaca: well, it wouldn't hurt anything
  <pedronis> it would just need a follow up
  <Chipaca> hmm
  <pedronis> sorry, I always hope to have that 30mins
  <Chipaca> :-D
  <pedronis> to do the thing
  <pedronis> but hasn't happened yet
  <pedronis> if it's annoying I can also temporarely close it
  <zyga> Chipaca: done
  <Chipaca> pedronis: no planning to have 30 minutes around ubuntu release time
  <zyga> brb, coffee time
  <mup> PR classic-snap#21 opened: create: improve user information <Created by mvo5> <https://github.com/snapcore/classic-snap/pull/21>
  <mvo> yay, thanks mup!
  <zyga> mvo: done
  <mvo> ta
   * mvo hugs zyga
  <zyga> I didn't get the coffee
  <zyga> ok, really coffee
  <Chipaca> jdstrand: #5727 could use a once-over from you i think
  <mup> PR #5727: interfaces/builtin, cmd/snap-seccomp: Allow read-only ptrace, for the Breakpad crash reporter <Created by jld> <https://github.com/snapcore/snapd/pull/5727>
  <mborzecki> off to pick up the kids
  <zyga> re
  <zyga> coffee expanded into lunch
  <Chipaca> lunch? so early?
  <Chipaca> â¦ oh wait
  <Chipaca> drat
  <Chipaca> i had a morning, once
  <Chipaca> zyga: should I do the rename I mention in #5957?
  <zyga> Chipaca: looking
  <mup> PR #5957: overlord/snapshotstate/backend: fall back on sudo when no runuser <Snapshots ð¸ó > <Created by chipaca> <https://github.com/snapcore/snapd/pull/5957>
  <Chipaca> zyga: the 'unify' comment
  <zyga> thinking
  <zyga> I added an idea but really this is bike shed hue now :)
  <zyga> Chipaca: is 2PM early for lunch?
  <pstolowski> it's not
   * pstolowski lunches
  <axino> hi
  <axino> is there a "snap" command knob to tell me if an installed snap has "strict" or "classic" confinement ?
  <ijohnson> axino: `snap info snap-name --verbose` and under "notes"
  <axino> ijohnson: nice, thanks !
  <niemeyer> Hey folks, we've got a conflict today in our standup, but would be nice to run that exercise for defining the features for the upcoming cycle.. should we/can we postpone the meeting today for an hour?
  <Chipaca> axino: if it's installed,  'snap list snap-name', if it's classic it says 'classic' in the Notes column
  <axino> Chipaca: ack, thanks
  <pstolowski> niemeyer: fine by me
  <mvo> niemeyer: works for me
  <niemeyer> Thanks, I've moved the calendar event
  <jdstrand> Chipaca: ack, yes
  <zyga> uh
  <zyga> did standup move?
  <zyga> ah, I see
   * zyga gets back to coding
  <Chipaca> jdstrand: thanks! :-)
  <mup> PR snapd#5959 closed: systemd: extend Status() to work for socket and timer units <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5959>
  <sergiusens> zyga: oSoMoN I wouldn't put too much effort in the shellcheck stuff, you might as well copy over from the extensions work (which has been shellchecked) https://github.com/snapcore/snapcraft/pull/2359/files
  <mup> PR snapcraft#2359: [WIP] extensions: add glib <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2359>
  <zyga> sergiusens: nice, thank you for the tip!
  <mup> PR snapd#6007 opened: tests/lib: add an @mozilla.com exception to the CLA checker <Simple ð> <â Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6007>
  <mup> PR snapd#6008 opened: client, daemon, cmd/snap: indicate that services are socket/timer activated <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6008>
  <mborzecki> Chipaca: something you may want to look at ^^
  <Chipaca> will do
  <mborzecki> it's passing the status of activators to the client, so now we can play with the ui all we want
  <mup> PR snapd#6009 opened: cmd: use relative file names in locking APIs <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6009>
  <mborzecki> i suppose `snap stop` `snap start` should also DTRT wrt after/before
  <Chipaca> mborzecki: as suppositions go, that's a solid one
  <mup> PR snapd#6010 opened: cmd/snap-discard-ns: add support for per-user mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/6010>
  <mborzecki> having 2 separate paths to call sysstemctl is so much fun :)
  <oSoMoN> sergiusens, I'm not planning on applying shellcheck fixes to the desktop helpers, but I want to understand why this doesn't work under fedora
  <sergiusens> oSoMoN: I will not get in your way there ð
  <Chipaca> mborzecki: let's fix that
  <Chipaca> mborzecki: i forget why we have two :-)
  <zyga> new standup time :)
  <Chipaca> mborzecki: once upon a time, everything systemd went via systemd-the-package
  <Chipaca> meaning reimplementing things for runit or whatever was just writing a systemd-the-package-alike
  <zyga> mborzecki: can you please give a final vote on https://github.com/snapcore/snapd/pull/6004
  <Chipaca> today it's probably less true :-D
  <mup> PR #6004: cmd/snap-confine: reduce verbosity of debug and error messages <Created by zyga> <https://github.com/snapcore/snapd/pull/6004>
  <mup> PR classic-snap#22 opened: make snapcraft.yaml architecture specific <Created by mvo5> <https://github.com/snapcore/classic-snap/pull/22>
  <niemeyer> pedronis: Yeah, that's the code we were just discussing.. some more digging and testing is needed
  <niemeyer> pedronis: Have a good one
  <niemeyer> Chipaca: So, back to media, sorry for the detail
  <niemeyer> derail
  <mup> PR snapcraft#2361 opened: schema: remove deprecated plugin pull and build-properties <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2361>
  <pstolowski> i'll dig in in the morning and see if we're missing normalization somewhere
  <Chipaca> niemeyer: â¦ ?
  <niemeyer> Chipaca: Sorry... I suggest going forward with the plan and preserving the current shape of our API, having "icons" as an independent entry
  <zyga> re
  <zyga> somewhat related https://github.com/snapcore/snapd/pull/6012
  <mup> PR #6012: interfaces: fix NormalizeInterfaceAttributes, add tests <Created by zyga> <https://github.com/snapcore/snapd/pull/6012>
  <zyga> Chipaca: ^
  <mup> PR snapd#6012 opened: interfaces: fix NormalizeInterfaceAttributes, add tests <Created by zyga> <https://github.com/snapcore/snapd/pull/6012>
  <cachio> mvo, 2.35.4 is stable now
  <cachio> mvo, smoke test in progress
  <Chipaca> niemeyer: wait, what for?
  <niemeyer> Chipaca: We can also add banners when we have a clear idea of how they look like, but we should clarify the discrepancies that exist between the spec and the dev API spec
  <Chipaca> niemeyer: there's never more than one icon AFAIK
  <Chipaca> niemeyer: is there going to be?
  <niemeyer> Chipaca: Oh my.. I thought we were missing it.. so that's *also* duplciate
  <niemeyer> duplicated
  <niemeyer> Chipaca: We just the banner then.. I wonder if we need more htan one
  <niemeyer> Chipaca: Either way, we should clarify if it's the dev API doc or the spec that is right
  <niemeyer> Chipaca: The dev API doc mentions "key", and "filename"
  <Chipaca> niemeyer: isn't the dev api the one snapcraft talks?
  <niemeyer> Chipaca: The comment is likely just bogus.. it mentions a filename, and provides an example without a URL
  <niemeyer> Chipaca: Well, or maybe not.. it's indeed storing the content, in which case it's the "url" parameter in the API that is unnecessary
  <mup> PR snapd#6013 opened: Revert "snap, client, daemon, store: use and expose "media" more (#5906)" <Created by chipaca> <https://github.com/snapcore/snapd/pull/6013>
  <Chipaca> niemeyer: I'm sure your statements make sense in the context of whatever it is you're looking at, but without that context I'm lost
  <zyga> mvo: if still around please look at 6012
  <niemeyer> Chipaca: https://dashboard.snapcraft.io/docs/api/snap.html#get--dev-api-snaps-(snap_id)-binary-metadata
  <zyga> I had a look at how Normalize is used as well
  <Chipaca> niemeyer: that's not an api we talk to, is it?
  <niemeyer> Chipaca: Yeah, it's somewhat irrelevant, other than for understanding how we get what we get. On our end the problem is simpler.. we just need to support banners, and banner icon... the one question we need answered still is what's the use for those values.. can we have multiple banners, and why
  <niemeyer> Chipaca: Same thing for banner icon
  <Chipaca> a confirmation over icon being single would be nice
  <Chipaca> as well
  <Chipaca> niemeyer: in any case, #6013 reverts #5906
  <mup> PR #6013: Revert "snap, client, daemon, store: use and expose "media" more (#5906)" <Created by chipaca> <https://github.com/snapcore/snapd/pull/6013>
  <mup> PR #5906: snap, client, daemon, store: use and expose "media" more <Squash-merge> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5906>
  <niemeyer> Chipaca: The obvious reasons for having multiple icons is format and size
  <Chipaca> niemeyer: pending confirmation of these things, a related question: should I make client standalone, and could I make snap use client instead of viceversa
  <Chipaca> and if yes, should I do that after the 1.10 move so we can use aliases
  <niemeyer> Chipaca: I think we had that agreement at some point, to avoid duplication by having the rest of the code importing client, which is okay. I can't remember if we ever discussed reasons for breaking that assumption with the "snap" package..
  <Chipaca> niemeyer: I think we just never got to it. It's a fair amount of work.
  <niemeyer> Chipaca: There are only two imports of "snap" inside the client, but that doesn't change what you just said
  <Chipaca> heh
  <Chipaca> i mean,  it's changing snap.Revision to client.Revision everywhere
  <Chipaca> that sort of thing
  <niemeyer> Chipaca: The alternative would be defining "snap" to be part of the client too
  <niemeyer> Chipaca: Which is reasonable to a degree..
  <Chipaca> client/snap/...
  <niemeyer> Chipaca: I mean just semantically, not necessarily the location itself
  <Chipaca> niemeyer: i got that, but we can have both
  <Chipaca> bah, i dunno
  <tomwardill> Hi, just to let you know the store is responding slowly / erroring, on both api and dashboard. We're working on it :)
  <Chipaca> and it's too late in the day to go poke
  <niemeyer> Chipaca: We have a bunch of *util packages in a similar category.. wouldn't be nice to have client/<everything>
  <niemeyer> tomwardill: Thanks for the note
  <niemeyer> Chipaca: And agreed, a bit late
  <zyga> tomwardill: thank you for the notice!
  <Chipaca> niemeyer: but there are things in snap that aren't client, so splitting it might be a good exercise
  <mvo> zyga: \o/ you rock
  <zyga> mvo: I don't know if that is the problem though
  <zyga> I did not reproduce it
  <zyga> Chipaca: back now, sorry, the young one wanted food
  <mvo> zyga: it probably is not but still nice
  <zyga> Chipaca: reviewed https://github.com/snapcore/snapd/pull/5957#pullrequestreview-165744410
  <mup> PR #5957: overlord/snapshotstate/backend: fall back on sudo when no runuser <Snapshots ð¸ó > <Created by chipaca> <https://github.com/snapcore/snapd/pull/5957>
  <jdstrand> roadmr: hi! can you pull r1141 of the review-tools?
  <zyga> hey jdstrand
  <roadmr> jdstrand: sure, will do!
  <zyga> sorry for not doing more reviews
  <jdstrand> roadmr: it would be nice if it was in before SLC, but not mandatory
  <zyga> I'll try to tomorrow, I'm just about to wrap it
  <jdstrand> zyga: hey :) no worries. belive, I know how that can happen
  <zyga> jdstrand: I sent one interesting PR but not security critical
  <jdstrand> believe me*
  <zyga> still I wrote it as tightly as I could
  <zyga> jdstrand: do you remember MNT_DETACH and unmount
  <zyga> jdstrand: and the case that if a dentry is mounted in one mount namespace it is EBUSY to remove it in another
  <zyga> jdstrand: that got fixed in the kernel since
  <zyga> jdstrand: it's not fixed on CentOS or RHEL ... :-(
  <zyga> jdstrand: we very much rely on that so bummer
  <jdstrand> well, still progress
  <roadmr> jdstrand: I'll do my best :)
  <Chipaca> niemeyer: client uses store uses overlord/auth btw
   * zyga EODs
  <niemeyer> Chipaca: /o\
  <niemeyer> zyga: Have a good night
  <jdstrand> roadmr: thanks :)
  <Chipaca> niemeyer: http://r.chipaca.com/snap.png
  <Chipaca> niemeyer: http://r.chipaca.com/client.png
  <Chipaca> niemeyer: osutil is orange just because it's cgo
  <mup> PR snapd#6014 opened: ifstate: fix decoding of json numbers <Created by mvo5> <https://github.com/snapcore/snapd/pull/6014>
  <Chipaca> updated those pngs with splines
   * zyga sends gentle reminder for someone to look at https://bugs.launchpad.net/snapd/+bug/1796125
  <cachio> mvo, https://paste.ubuntu.com/p/Sh4Zf7TyVc/
  <zyga> and really goes to play
  <mup> Bug #1796125: services in a snap with dependencies aren't started in correct order on install <snapd:New> <https://launchpad.net/bugs/1796125>
  <cachio> mvo, this is the issue what we see snapd.socket failing
  <cachio> mvo, sorry, this error is caused by systemd
  <zyga> mvo: reviewed your pr
  <zyga> and I'm gone for real
  <mvo> zyga: thank you! and totally agree, we may need to think about this in a deeper level :) enjoy your evening!
  <cachio> mvo, this is the error
  <cachio> https://paste.ubuntu.com/p/KQjX3SYNXz/
  <cachio> at least one error easy to reproduce
  <cachio> seem to be a race
   * cachio afk
  <zyga> kenvandine: hey
  <zyga> kenvandine: just FYI there's an issue with desktop-launcher on Fedora
  <kenvandine> zyga: what kind of issue?
  <kenvandine> i tested the GNOME snaps recently on fedora
  <zyga> kenvandine: calibri doesn't start with it
  <zyga> I spent some time debugging
  <zyga> if the launcher runs and sets up stuff the app doesn't start, just quits (I didn't strace it)
  <zyga> if I run the app directly it runs but some stuff is wonky (fonts)
  <zyga> kenvandine: oSoMoN also looked at it I believe
  <zyga> kenvandine: the script is full of shellcheck warnings, not sure if related
  <kenvandine> zyga: do other snaps work?
  <kenvandine> like gnome-calculator?
  <zyga> kenvandine: I haven't tried many snaps, let me look
  <kenvandine> zyga: those are just places where we could quote variables
  <kenvandine> but shouldn't effect this
  <zyga> kenvandine: perhaps but maybe there are real bugs in the noise
  <kenvandine> perhaps
  <zyga> installing now
  <zyga> kenvandine: it runs
  <kenvandine> ok, interesting
  <zyga> kenvandine: I'll leave the rest to you though, it's far too late for work now :)
  <kenvandine> i can't debug right now, working on release stuff
  <zyga> ack :)
  <kenvandine> zyga: i'll look at it soon though
  <zyga> snapd gets killed on fedora ...
  <zyga> snapd gets killed on fedora by systemd https://www.irccloud.com/pastebin/3VlZmBvX/
  <oSoMoN> kenvandine : I managed to observe the issue described by zyga in a fedora VM, but I'm afraid  I didn't go much furtherâ¦ chromium runs, and I've compared the desktop-launch scripts for chromium and colibri, the one for colibri appears to be a much older version, IÂ wonder if rebuilding with a recent version would make things better?
  <kenvandine> maybe
  <mup> PR snapcraft#2362 opened: python plugin: add support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2362>
  <oSoMoN> hrmmm, snapcraft is not available in fedora, and installing classic snaps doesn't appear to be supported :/
  <kenvandine> oSoMoN: nope
  <oSoMoN> kenvandine, I'm rebuilding the snap with a more recent desktop-launch script and will test in my fedora VM, will let you know how that goes
  <oSoMoN> kenvandine, zyga: a more recent desktop-launch script didn't change anything, the snap still won't run
  <oSoMoN> I wonder what's so special about that snap
  <koala_man> are there any snaps written in Haskell that I can look at? I can make my build work locally with 'snapcraft cleanbuild' but not on snapcraft.io
  <oSoMoN> kenvandine, zyga: I'm going offline and won't be around until Monday, if there hasn't been progress on that issue by then I can pick it up and continue investigatingq
  <mup> PR snapcraft#2361 closed: schema: remove deprecated plugin pull and build-properties <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2361>
  <mup> PR snapcraft#2363 opened: {make,cmake,autotools} plugin: add support for bases <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2363>
  #snappy 2018-10-18
  <mup> PR snapcraft#2360 closed: plainbox-provider plugin: add support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2360>
  <mup> PR snapd#5957 closed: overlord/snapshotstate/backend: fall back on sudo when no runuser <Snapshots ð¸ó > <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5957>
  <mwhudson> what's the story with libseccomp and trusty and arm64 and ppc64el?
  <mwhudson> snapd is stuck in trusty-proposed because of this
  <mwhudson> oh wait no that's not why
  <mborzecki> morning
  <zyga> Hey
  <zyga> Did
  <zyga> Haha
  <zyga> My phone just fell and wrote this
  <mborzecki> zyga: hey
  <mborzecki> must be ai
  <zyga>  Hey mvo
  <mborzecki> mvo: hey
  <mvo> hey zyga and mborzecki
  <mvo> how is life today?
  <mborzecki> mvo: all red
  <mvo> urgh
  <mvo> do we know why?
   * mvo looks
  <zyga> It is all red because summer is over
  <mborzecki> mvo: random stuff afaict, there was some store hiccup yday too, maybe somewhat related
  <zyga> Well, that is one theory
  <zyga> Store was broken
  <zyga> So perhaps that is why
   * mvo nods
  <mborzecki> didn't we disable gccgo?
  <mvo> we can now, we got agreement we no longer need to support it
  <mborzecki> https://api.travis-ci.org/v3/job/442894803/log.txt the gccgo unit tests died in most mysterious way here
  <mborzecki> this PR https://github.com/snapcore/snapd/pull/5989
  <mup> PR #5989: interfaces/system-key: add parser mtime and only discover features on write <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5989>
  <mborzecki> uhh, restarted the job, the log is gone :/
  <mwhudson> mvo: golang-1.10 is in proposed everywhere now \o/
  <mvo> mwhudson: awesome, thank you so much!
  <pstolowski> mornings
  <pstolowski> mvo: thank you for getting to the bottom of decoding issue! i've left a comment
  <pedronis> pstolowski: is normalize enough though, any number ends up out of state as float, no?
  <mvo> pstolowski: thank you! also to pedronis for his comments. I figured this would need more discussion :)
  <mvo> pstolowski: if you know what to do, feel free to just take my PR (or just cherry pick the commit if its useful) and go wild
  <pstolowski> pedronis: hmm but not with json.DecodeWithNumbers as mvo proposed?
  <pedronis> pstolowski: indeed, but we still need to massage that
  <pedronis> I mean there is still a missing link
  <pedronis> one approach would be to teach normalize about json.Number I suppose
  <pstolowski> mvo: sure, i'll dig into it
  <zyga> pedronis: yeah, I think we should do exactly that
  <pedronis> we probably want to call normalize before NewConnection though
  <pstolowski> it's annoying this is a second instance of such issue (first was around configuration afair)
  <mup> PR classic-snap#22 closed: make snapcraft.yaml architecture specific <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/classic-snap/pull/22>
  <pedronis> carrying around Numbers
  <pedronis> is a bit strange
  <mvo> pedronis: yeah, I was thinking that (normalize learns about json.Number), I have something local but its so trivial that I'm not sure its worth pushing
  <mvo> (on top of the UseNumbers PR)
  <zyga> mvo: shall I merge https://github.com/snapcore/snapd/pull/6012 ?
  <mup> PR #6012: interfaces: fix NormalizeInterfaceAttributes, add tests <Created by zyga> <https://github.com/snapcore/snapd/pull/6012>
  <zyga> do you want it squashed?
  <mborzecki> damn, was checking out a problem with apparmor profiles not being loaded on arch, turns out i forgot to enable snapd.apparmor.service
  <mvo> zyga: I get the feeling we will need it squashfs yes
  <mvo> zyga: please do
  <mup> PR snapd#6012 closed: interfaces: fix NormalizeInterfaceAttributes, add tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6012>
  <mvo> zyga: thanks, I will cherry-pick into 2.36
  <zyga> thank you!
  <mvo> thank *you*
  <mvo> pstolowski: keep me updated please, I will go back to core18 (unless you want me to help of course)
  <mup> PR snapd#6009 closed: cmd: use relative file names in locking APIs <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6009>
  <pstolowski> mvo: will do, thanks
  <pstolowski> mvo, pedronis we could maybe make getAttribute reflect check smarter, if you convert to int if that's what caller requested, wdyt?
  <pstolowski> sorry, mistyped
  <pstolowski>  we could maybe make getAttribute reflect check smarter and convert to int if that's what caller requested
  <pedronis> pstolowski: it's a bit too different from what we do everywhere else
  <pedronis> pstolowski: I think the result of getConns
  <pedronis> needs to be sane
  <pstolowski> i see, fair point
  <pedronis> pstolowski: btw, do we have a similar problem with dynamic attributes?
  <pedronis> I know we normalize but is a bit unclear if that's enough
  <pedronis> pstolowski: we can reboot in the middle of an op and then dynamic attributes would also come from state on disk
  <pstolowski> pedronis: i'm not sure anymore tbh, possibly yes, i trusted normalization but missed that json decoding/encoding problem
  <pedronis> pstolowski: we might want to write some kind of test about that
  <pstolowski> pedronis: yes, this what i'm aiming at first
  <pedronis> needs to serialize and unserialize state with dynamic attrs
  <pedronis> in it
  <mup> PR classic-snap#20 closed: port classic to UC18 and put into "18" branch <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/classic-snap/pull/20>
  <mup> PR snapd#6015 opened: tests/unit/gccgo: drop gccgo unit tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6015>
  <mvo> hey sil2100 - happy release day
  <sil2100> mvo: hey! Happy release day o/
  <zyga> is today 18.10 day?
  <mup> PR snapd#6016 opened: [RFC] move various name validation helpers to snap/name package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6016>
  <mborzecki> pedronis: hi, the snap name split proposal ^^
  <zyga> mborzecki: did you see https://forum.snapcraft.io/t/snapd-2-35-2-error-run-hook-configure-cannot-set-core-schedule-unsupported-system-option/8051
  <mborzecki> zyga: core.schedule?
  <zyga> mborzecki: didn't look at this more than "looks like something you might know"
  <mup> PR classic-snap#23 opened: create,classic: make the classic snap work on classic distributions (for 18) <Created by mvo5> <https://github.com/snapcore/classic-snap/pull/23>
  <mborzecki> opensuse mirrors at it again :(
  <mvo> zyga: I updated classic snap PR (21) you commented about. I will do shellcheck next and tests after that (need to think a bit about the tests)
  <zyga> mvo: can we use classic to run a script?
  <mvo> zyga: now we can
  <zyga> so that we could test "running scripts inside classic" via spread?
  <mvo> zyga: it was broken before
  <zyga> apt-get install && run something would be useful :)
  <zyga> perhaps a cli and a service?
  <mvo> zyga: sounds good, services are not supported (deliberately) but that needs a test too
  <zyga> ah I see
  <Chipaca> mvo: not supported as in won't install, or won't start?
  <Chipaca> did we come to an agreement about having 'install' not error if a service didn't start?
  <Chipaca> actually, before i get carried away: i need to go get a new phone :-(
  <zyga> oh
  <zyga> what happened?
  <mvo> Chipaca: correct, not starting
  <Chipaca> screen cracked, including the touchscreen, so no unlocking, so no 2fa
  <mvo> Chipaca: it will install fine (the service) but there will be a message that it won't run
  <Chipaca> mvo: nice
  <niemeyer> Chipaca: There's a Go app that generates the 2fa if you can still login.. it's quite convenient
  <niemeyer> Moins
  <mvo> good morning niemeyer
  <niemeyer> I'm a bit under the weather today, but feeling better compared to the night.. my voice just sounds like someone that shouldn't try to sing did some really hard singing
  <mup> PR classic-snap#24 opened: add shellcheck and fix warnings <Created by mvo5> <https://github.com/snapcore/classic-snap/pull/24>
  <zyga> mborzecki: hey, do you have a second
  <mborzecki> zyga: hm?
  <zyga> I'm looking at a bit of shell and not sure why it is structured like that
  <zyga> mborzecki: please look at snap-mgmt.sh.in, line 122
  <zyga> mborzecki: why do we do first a find
  <zyga> and then a for loop over a what looks like identical glbo
  <zyga> *glob
  <zyga> why not just iterate over find results?
  <zyga> is this fixing something?
  <mborzecki> zyga: don't know, i see it's the same in postrm in debian packaging, probable made its way from there
  <pedronis> zyga: probably the find and the glob fail differently
  <pedronis> zyga: it has a note in the postrm that some bits of that might not be mounted
  <pedronis> zyga: try  for a in /nonexisting/* ; do echo $a ; done  for example
  <zyga> right but the find would behave correctly?
  <zyga> could we not just iterate over results from find?
  <pedronis> zyga: the find fails too
  <pedronis> but the wc -l
  <pedronis> makes it work
  <zyga> ah, I see
  <zyga> right
  <zyga> because set -e is not active for pipe chains
  <zyga> makes sense, thank you pedronis
  <pedronis> but yes, maybe those needs for comment
  <pedronis> is usual shell fun
  <zyga> yes :)
  <pedronis> s/for/more/
  <mborzecki> the whole block should use find, `for mnt in $(find /run/snapd/ns -maxdepth 1 -name '*.mnt'); do ... done` or just find with -exec
  <mborzecki> heh, actually find is used properly in the file in some places, just not everywhere
  <mvo> mborzecki: yeah, I think it was just a suboptimal fix, looking at git history
  <mvo> mborzecki: go ahead and make it great :)
  <pedronis> mborzecki: ?
  <pedronis> mborzecki: that doesn't work if /run/snapd/ns doesn't exist
  <zyga> pedronis: I tested it just now
  <pedronis> zyga: ?
  <pedronis> do you have /run/snapd/ns ?
  <zyga> for i in $(find /nonexistent); do echo $i; done.
  <zyga> it says that the directory doesn't exist but exits successfully because of the sub-shell
  <pedronis> yea, that error is not nice though
  <zyga> yeah, I think we can make it better still, let me experiment
  <pedronis> anyway not sure it's the best time spent
  <pedronis> at this moment
  <pedronis> the current code is weird but not wrong or insane
  <zyga> I'm looking because I got a odd failure in that area
  <mborzecki> test -d .. && for .. ?
  <zyga> but perhaps 14.04 specific
  <zyga> it seems a symlink confused the inner parts of the loop
  <Chipaca> niemeyer: wrt #5906, what about: we keep the old behaviour, but also add a zeroth implementation of fields=,  just to cover media?
  <mup> PR #5906: snap, client, daemon, store: use and expose "media" more <Squash-merge> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5906>
  <Chipaca> niemeyer: e.g. fields=+media
  <Chipaca> niemeyer: this assumes media is the end game tbh, which i'm not sure is what you meant
  <Chipaca> niemeyer: but I got conflicting messages yesterday as to whether it was the shape, or the duplication that you objected to
  <Chipaca> maybe it's both Â¯\_(ã)_/Â¯
  <niemeyer> Chipaca: It's both the shape and the duplication.. my concern is that we can't change our minds regularly once we have an API in the wild.. the best scenario is that the API is self-consistent, so we have a line of design that we can be truthful towards..
  <niemeyer> Chipaca: I wish we had media on day one, but we don't.. even if we agree this is the way to go, adding the field means being neither here nor there. If we keep this kind of design mindset, soon this will be a huge mess.
  <Chipaca> niemeyer: which is the design mindset you object to?
  <niemeyer> Chipaca: The mindset that it's okay to make the API inconsistent with itself everytime an idea that looks better than the prior one shows up
  <Chipaca> niemeyer: ok
  <greyback> quick qn: I have qemu-kvm installed but spread still fails for me with: https://pastebin.ubuntu.com/p/WxVpFGrJwD/ (selected qemu image exists and was created using adt-buildvm-ubuntu-cloud). Any idea what I'm doing wrong?
  <Chipaca> niemeyer: how do we evolve the api, then? is the only way to have big versioned jumps?
  <Chipaca> greyback: is 'kvm' actually in PATH?
  <greyback> Chipaca: yes
  <pedronis> Chipaca: we need to design how to evolve the api
  <niemeyer> Chipaca: Yeah, that's generally what I try to do in other cases that resembled that kind of evolution. Learn, write down potential ideas, and once there is a great reason to break up, introducing a whole new API, and then reset the idea of what the current design is
  <Chipaca> greyback: all spread does is exec.Command("kvm",  ...), which looks for "kvm" in $PATH
  <pedronis> Chipaca: I don't think keeping its shape as it is is tenable for much longer either
  <greyback> Chipaca: the $PATH specified in the spread.yaml?
  <niemeyer> pedronis: What's the potential deal breaker
  <niemeyer> ?
  <niemeyer> I haven't observed many complaints about the API yet
  <niemeyer> (which doesn't mean they don't exist)
  <pedronis> niemeyer: we already had to introduce duplication
  <pedronis> niemeyer: the flat top-level that mixes namespaces we don't fully control or have to control for not the best is not great either
  <niemeyer> pedronis: If the duplication you mention is developer/publisher, these are not actually duplicated, in the sense they were supposed to potentially represent different people.. we do have a problem which is not using the same structure for both, so indeed an inconsistency
  <niemeyer> pedronis: What's the flat top-level about?
  <pedronis> niemeyer: I understand that you think we can keep under control but an api that has at top level ,  left-corner-hero-icons is not great
  <niemeyer> pedronis: Sorry, I'm still missing what you really mean. If we can't keep the API under control, we're in the wrong business. :)  What's left-corner-hero-icons?
  <Chipaca> greyback: I don't think so, that's the one 'inside'; it uses the outside path to find that
  <Chipaca> greyback: e.g. i have  ~/bin/kvm because I like to monkey with the args (adding -smp 4 for ex)
  <Chipaca> greyback: and that just works
  <Chipaca> niemeyer: adding a toplevel entry per media type
  <greyback> Chipaca: ack. I'm reading spread code now, I see what you mean. I think my issue is permissions and kvm, trying to sort that out
  <Chipaca> niemeyer: will end up with e.g. left-corner-hero-icons at the top level
  <pedronis> or not
  <niemeyer> Chipaca: Only if that's how we design it
  <Chipaca> well, but that's what we're proposing now isn't it?
  <niemeyer> Chipaca: That sounds like a pretty terrible design
  <pedronis> we should not be designing that
  <pedronis> we have lots of thinks to design
  <Chipaca> we're saying:  don't do media, let's just have a toplevel per media type
  <niemeyer> Chipaca: That's why I one of the first things I asked is what are the media types we have
  <pedronis> niemeyer: btw there are a meeting about exactly desiging those types, and nobody of us has been invited
  <Chipaca> niemeyer: there's a meeting next week to decide that
  <niemeyer> Chipaca: If we have several icons, we can have an "icons" field
  <pedronis> niemeyer: I let you meditate on that, I have zero energy for this
  <pedronis> (which is sort of the point)
  <Chipaca> i just don't get why we care. the consumers of our api need something, the providers of the data we consume offer that something, why would we not funnel it across untouched
  <Chipaca> i mean, i get that we don't want duplication
  <Chipaca> and we don't want it to be ugly
  <niemeyer> Chipaca: Alternatively, we can have a plan to obsolete the other fields.. we'll need to figure who uses them and what events we need to wait for in order to kill them
  <pedronis> which was my point
  <pedronis> we need to think how to evolve
  <pedronis> the api
  <Chipaca> but that just means we have a chat to make sure we're on the same page (i thought we were) and just pass it through
  <pedronis> non-evolving it
  <pedronis> is not a path either
  <niemeyer> Chipaca: My main complaint here is the lose way to evolve the API
  <niemeyer> loose
  <Chipaca> i thought your main complaint was the shape and the duplication
  <pedronis> I'm happy to have a conversation how not-loosely evolve the api, I'm less api to be forced to be in all conversation because our api is too set in its way
  <Chipaca> sigh
  <Chipaca> niemeyer: i thought fields= gave us a way to evolve the api
  <pedronis> Chipaca: on that I agree with niemeyer, is too flaky
  <pedronis> annoying
  <pedronis> I mean it can be part of the picture
  <pedronis> but cannot be the whole solutions
  <pedronis> also because we have zero control on when we can drop stuff
  <pedronis> that way
  <Chipaca> i haven't heard a proposal that gives us any amount of control on when we can drop stuff
  <niemeyer> Chipaca: That is my main complaint... the shape and the duplication are symptoms of a loose API
  <niemeyer> "Chipaca: Yeah, that's generally what I try to do in other cases that resembled that kind of evolution. Learn, write down potential ideas, and once there is a great reason to break up, introducing a whole new API, and then reset the idea of what the current design is"
  <pedronis> Chipaca: we can discuss some
  <pedronis> maybe
  <Chipaca> niemeyer: introducing a whole new api is not what i thought of as evolving the api
  <niemeyer> and
  <niemeyer> "Chipaca: Alternatively, we can have a plan to obsolete the other fields.. we'll need to figure who uses them and what events we need to wait for in order to kill them"
  <pedronis> niemeyer: that works only if you control all the pieces around the api
  <niemeyer> Chipaca: Both of these are proposals for how to keep an API tight while allowing for changes over time
  <niemeyer> Chipaca: Incompatible changes, that is.. changing is easy
  <Chipaca> and saying we can have a plan is not a plan :-)
  <pedronis> Chipaca: one idea is to have versions for different consistent views of/on a snap
  <pedronis> (views = set of fields if you want)
  <niemeyer> Chipaca: Heh.. I'm not sure how to satisfy that kind of snarky request for plans.
  <Chipaca> apologies if I'm coming across as grumpy or overly confrontational
  <niemeyer> Chipaca: I've been trying to explain what the main issue in my view is, and what potential ideas for solving it could be
  <pedronis> anyway at the moment we have two solutions that are problematic, don't care duplications, and forcing something that is loose into the top-level
  <Chipaca> niemeyer: it's ok to admit we don't have a plan and that we need one
  <pedronis> both *are* problematic
  <pedronis> and one will also create potentially tensions
  <pedronis> for which is unclear we have time to spend
  <niemeyer> Chipaca: I don't know what you want, honestly. I'm offering two alternatives, both of them are real ways to work together and evolve the API. Just repeating that you want a plan or want people to admit to not have a plan is completely irrelevant.
  <pedronis> I want a plan to be able to obsolete fields
  <niemeyer> pedronis: The only way to do that is to evaluate the impact... once we stop providing a field, we break people that depend on that field being there.
  <mup> PR classic-snap#25 opened: Add simple spread tests <Created by mvo5> <https://github.com/snapcore/classic-snap/pull/25>
  <pedronis> so this is much easier on servers, but we there should be a way for us to track field
  <pedronis> usage without being nosy
  <niemeyer> pedronis: The alternative of reving up the API allows us to have a consistent new API without breaking the old one. It won't remove the old one, but it does obsolete the field as a side effect.
  <niemeyer> pedronis: Right
  <pedronis> yes, of which a variant is to rev the response format only
  <pedronis> if that's is enough
  <niemeyer> pedronis: Right.. that's the /v3/
  <pedronis> or using Accept
  <pedronis> or something
  <pedronis> we do have options
  <pedronis> not sure we can find a solution today and tomorrow
  <pedronis> but we do have options
  <niemeyer> pedronis: Yeah.. as mentioned earlier, in those situations I try to pack up a few high-profile changes that are clear reasons for the effort of breaking the API apart between vN and vN+1
  <Chipaca> so, I want two things: I want to not block gnome software from getting the media they need today, and I want to be able to ditch the current response format entirely soon after we move to v2 search
  <Chipaca> a clear reason for breaking the api is that we're moving to not conflating per-revision and per-snap information
  <Chipaca> and our current structure does not allow for it
  <niemeyer> Chipaca: Is there a place I can read more about the second issue?
  <Chipaca> niemeyer: not sure if there's info on the issue; there's info on the solution
   * Chipaca looks
  <zyga> mvo: reviewed
   * pedronis needs to have lunch + errand
  <niemeyer> Chipaca: That's a big document.. is there a particular issue or header I should be looking at?
  <Chipaca> niemeyer: yeah, and as I say it doesn't describe the issue, just the solution, under the "Response" header
  <Chipaca> niemeyer: there's a "snap" object with per-snap members, and at the same level a "channel-map" list with per-revision objects
  <niemeyer> Chipaca: If we don't have a clear problem being solved, in general I'd be tempted to not introducing the breaking API change
  <niemeyer> Chipaca: and instead pack it next to other ideas for the time it's rev'd up
  <Chipaca> niemeyer: the problem is that we conflate per-snap and per-revision, so for example 'snap info' lies (to the best of its ability)
  <Chipaca> of course one could argue that lying in this way is the only sane approach
  <niemeyer> Chipaca: Yeah, I remember these discussions when we redesigned the original API.. but I have memories of the issue going beyond the representation of the result, and into actual usability, in the sense it's convenient for the user to have "snap info foo" doing the right thing
  <niemeyer> Chipaca: Right, what you just said
  <Chipaca> :)
  <Chipaca> niemeyer: I've got to move on to other things now
  <zyga> mborzecki: I added debug, doesn't reproduce :)
  <zyga> same seed
  <zyga> same tree
  <zyga> two runs in parallel
  <zyga> I hope I can get to the bottom of this
  <mvo> zyga: thanks for the review
  <niemeyer> Chipaca: Me too.. tasty things
   * zyga -> walk
   * pstolowski lunch
  <zyga> mborzecki: ha
  <zyga> reproduced that same behavior
  <zyga> mborzecki: I think I know what's going on
  <zyga> and it does look exactly like the centos case
  <zyga> let me spawn a more regular VM and try
  <mborzecki> mhm
  <mborzecki> centos was failing in the same place when calling snap-mgmt purge
  <zyga> EBUSY https://www.irccloud.com/pastebin/1eVl6UTk/
  <zyga> mborzecki: look at that please
  <zyga> waoh wait
  <zyga> it's ever more mysterious!!!
  <zyga> that makes totally no sense!
  <zyga> feels more and more like a kernel bug?
  <zyga> + umount -l /run/snapd/ns/test-snapd-tools.mnt
  <zyga> umount: /run/snapd/ns/test-snapd-tools.1000.mnt: not found
  <zyga> I'll add more debug, I wonder if there are some interesting processes running in parallel with postrm
  <zyga> and what's the full content of that directory before we loop over it
  <Chipaca> why would 'common' not get created, on opensuse and fedora?
  <mborzecki> Chipaca: just common? which test?
  <Chipaca> actually opensuse might be a different issue
  <Chipaca> mborzecki: https://api.travis-ci.org/v3/job/442964462/log.txt
  <Chipaca> mborzecki: second failure there
  <Chipaca> mborzecki: sorry,  third
  <Chipaca> first is shellcheck, second opensuse, third fedora
  <Chipaca> snapshot fails if common is missing
  <Chipaca> and, common is missing, wtf
  <greyback> Chipaca: I had permission errors with kvm, which caused the issue. Binary was there, just failing. Working now. Thanks for the help
  <Chipaca> greyback: np
  <Chipaca> greyback: was the error misleading, or was that what the os was reporting?
  <mborzecki> Chipaca: selinux?
  <mborzecki> Chipaca: there were some changes in creating snap dirs, but we have tests that verify that those are present iirc
  <Chipaca> mborzecki: it's not consistently reproducible
  <greyback> Chipaca: misleading error. strace showed me the kvm binary was being run, but printing an error
  <zyga> Small break
  <Chipaca> greyback: what was the error?
  <greyback> Chipaca: "need to run as root or suid"
  <Chipaca> greyback: ah, not an error from exec?
  <greyback> Chipaca: right
  <greyback> I'll log a bug
  <Chipaca> greyback: looks like a bug in go
  <Chipaca> greyback: is that because you weren't in the kvm group or something?
  <greyback> Chipaca: essentially yeah (modulo some other group error I'd made)
  <Chipaca> greyback: do you happen to have the strace?
  <greyback> Chipaca: unfortunately not, sorry. I'll see if I can repro, once my spread run finishes
  <Chipaca> greyback: thank you. I tried to repro locally and couldn't.
  <Chipaca> greyback: (running spread as "nobody" just hangs, which is weird but different)
  <Chipaca> #6007 could use reviews
  <mup> PR #6007: tests/lib: add an @mozilla.com exception to the CLA checker <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6007>
  <mborzecki> off to pick up the kids
  <mup> PR snapcraft#2363 closed: {make,cmake,autotools} plugin: add support for bases <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2363>
  <jdstrand> mvo: ok, after *many* retries I finally got PR 6002 to pass spread. continuing to mash restart restart for PR 5989
  <mup> PR #6002: interfaces/system-key: add parser mtime and only discover features on write - 2.36 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6002>
  <mup> PR #5989: interfaces/system-key: add parser mtime and only discover features on write <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5989>
  <mvo> jdstrand: thank you
  <jdstrand> I'm not sure what is going on. the failures are timeouts in some dbus code (totally unrelated to my PR)
  <jdstrand> anyway, will continue to keep mashing
  <jdstrand> mvo: if there was time, it would be great to get 5981 and 5982 reviewed and in trunk (cc zyga). if not, I understand
  <mvo> jdstrand: let me have a look
   * zyga is a bit indisposed now, sorry :|
  <zyga> mvo: is 2.36 today?
  <zyga> I will review it but I need to break for some time, food poisoning :(
  <zyga> mvo: my update for today: I updated adb interface again, worked on snap-update-ns per-user support, which is looking good, expect PRs today, digging into the weird issue with unmount I talked to mborzecki about
  <zyga> jdstrand: https://www.irccloud.com/pastebin/1eVl6UTk/ FYI
  <zyga> jdstrand: carefully read lines 26 and 27
  <mup> PR classic-snap#23 closed: create,classic: make the classic snap work on classic distributions (for 18) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/classic-snap/pull/23>
  <zyga> this is on a 4.5 kernel
   * zyga goes away again
  <Chipaca> mvo: see my note on #6013 being a blocker for 2.36
  <mup> PR #6013: Revert "snap, client, daemon, store: use and expose "media" more (#5906)" <â Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6013>
  <mvo> Chipaca: 'k
  <mvo> Chipaca: we have at least one more blocker
  <jdstrand> mvo: speaking of blockers. I know we discussed the bug, and I think it was implied, but PR 6002 should be a blocker too
  <mup> PR #6002: interfaces/system-key: add parser mtime and only discover features on write - 2.36 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6002>
  <mvo> jdstrand: +1
  <ackk> hi, I'm having an issue with a snap that stages jq from the deb. it seems snapcraft stopped pulling in libjq1.so, so jq doesn't work anymore
  <ackk> (I'm using snapcrafat edge)
  <ackk> *snapcraft
  <ackk> https://github.com/CanonicalLtd/candid/blob/master/snap/snapcraft.yaml is the snapcraft config
  <ackk> ah, n/m I figured it out
  <Chipaca> mborzecki: polish is hard, let's do roadmap planning
  <mborzecki> heh :)
  <zyga> mborzecki: I know what is was!
  <mborzecki> zyga: umounts?
  <zyga> yes
  <zyga> I'll share after meeting
  <mborzecki> ok
  <Chipaca> #5955 is green; plz review
  <mup> PR #5955:  cmd/snap, tests: snapshots for all <Snapshots ð¸ó > <Created by chipaca> <https://github.com/snapcore/snapd/pull/5955>
  <zyga> brb
  <zyga> mborzecki: I have a fix
  <mborzecki> zyga: diff?
  <ppisati> ogra: FYI - https://lists.ubuntu.com/archives/kernel-team/2018-October/096147.html
   * cachio lunch
  <mvo> zyga, cachio thanks for your classic snap review(s) - I updated 25
  <zyga> mborzecki: I just tested it manually, the fix is to avoid lib mount in a test I changed
  <zyga> mborzecki: I'll ping you for review :)
  <pstolowski> mvo: i've pushed my additions to json issue fix to https://github.com/stolowski/snapd/pull/new/fix-conn-attributes-numbers ; i've added normalization, one more test and updated hooks spread test. would you like to merge this into your PR or shall I re-propose a new one?
  <mvo> pstolowski: either way is fine
  <greyback> Chipaca: aaand naturally I cannot reproduce the bug now
  <pstolowski> mvo: ok i'll propose a new PR
  <mvo> pstolowski: ok
  <mup> PR snapd#6017 opened: interfaces: fix decoding of json numbers for static/dynamic attributes <Created by stolowski> <https://github.com/snapcore/snapd/pull/6017>
  <zyga> pstolowski: sent a quick comment there
  <pstolowski> zyga: yep, ty
  <mup> PR core18#85 opened: Add wpa-supplicant to the list of installed packages <Created by sil2100> <https://github.com/snapcore/core18/pull/85>
  <mup> PR core18#85 closed: Add wpa-supplicant to the list of installed packages <Created by sil2100> <Merged by sil2100> <https://github.com/snapcore/core18/pull/85>
  <zyga> jdstrand, niemeyer: cool interaction observation: on macOS doing find $HOME triggers an interactive question from the system "terminal wants to access your contacts" - rejecting that I get a denial to enter a particular folder on disk; that would be an interesting way to manage system connections
  <niemeyer> zyga: If only the kernel offered us a way to make these decisions...
  <zyga> yes, that's true
  <zyga> I was just surprised to see this
  <Chipaca> zyga: niemeyer: we did have a plan to almost get there
  <Chipaca> but it was a lot of work, and not prioritised
  <zyga> I could use a coffee
  <zyga> but let me wrap one thing up first...
  <jdstrand> zyga, niemeyer: fyi, the apparmor prompting work is still being worked on. jjohansen made a good bit of progress
  <zyga> mborzecki: I fired another round of tests now, with the fix in place
  <slvn_> slvn
  <slvn_> hi, I have an issue with snapcraft.io
  <slvn_> the website does not seem to take care of categories
  <slvn_> hence the search engine is not working correctly
  <slvn_> I have 10 snaps games that are published for a while. Only two of them appear in the listing of snapcraft.io when searching in "Games", but appears in "All snaps".
  <noise][> slvn_: we have some upcoming feature work to allow for publishers to self-select categories, but in the meantime if you can provide a list of your game snaps that need to be categorized in a forum post I can get someone from our advocacy team to review and get them associated to the category
  <slvn_> ok great !
  <mup> PR classic-snap#25 closed: Add simple spread tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/classic-snap/pull/25>
  <niemeyer> mvo: classic-snap#20 already went in, but fwiw thanks for the explanation. Sounds reasonabe
  <mup> PR classic-snap#20: port classic to UC18 and put into "18" branch <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/classic-snap/pull/20>
  <cyphermox> mvo: ping
  <cyphermox> mvo: I have just tested rev 445 of core18; adding wpasupplicant fixes the wifi connection issues (I can connect fine now)
  <cyphermox> (this is armhf+raspi3)
  <zyga> cyphermox: if you have an image I can test the dragon board
  <cyphermox> zyga: it was pre-testing, sil2100 will kick off a real build to get you a dragon image.
  <zyga> cool, sil2100 just let me know
  <sil2100> Will be kicking off a new image soonish
  <zyga> great, just let me know (with the URL, I never remember those)
  <sil2100> zyga: sure!
  <mvo> cyphermox: yay, thank you
  <sil2100> mvo: strange, I was sure we had that installed, but then I checked and we only *discussed* it being installed on the forums
  <zyga> mborzecki: back
  <zyga> mborzecki: the fix is https://github.com/snapcore/snapd/pull/6010/commits/b803e1c62350e76e7f62fd937ea443191cc496f7
  <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> and man, 14.04 :)
  <cachio> kyrofa, hey
  <cachio> kyleN, could you take a look to the nested suite?
  <kyrofa> Hey there cachio! I looked at the PR you linked. Am I correct in thinking that in order to get spread using an image with nested virt enabled you need to set those environment variables?
  <cachio> no env variables needed
  <cachio> kyrofa, those env variables are to configure our test suite
  <cachio> which kind of vm do you want to start?
  <cachio> I didnt try with kvm acceleration
  <kyrofa> cachio, multipass, actually
  <kyrofa> Have you tried that?
  <cachio> no
  <cachio> which on did you try?
  <kyrofa> cachio, I haven't tried at all after seeing that GCE link I shared saying that it needed to be enabled
  <kyrofa> cachio, so to be clear, are you saying you've already done that, or are you saying that you've got nested virt working without kvm?
  <cachio> yes
  <kyrofa> Hahaha, which one?
  <cachio> we run everyday that
  <cachio> ubuntu core, ubuntu 16, ubuntu 18
  <cachio> using qemu
  <cachio> 2gb of memory
  <kyrofa> cachio, but you didn't do https://cloud.google.com/compute/docs/instances/enable-nested-virtualization-vm-instances ? Wonder if you're getting a software version, then (this is not my area of expertise)
  <cachio> kyrofa, I see, this is if you want to use the gce tooling
  <cachio> kyrofa, in fact they are describing a process really similar to what we do
  <kyrofa> cachio, interesting, so this may already work. I'm testing now
  <cachio> but they show how to create your image and use a gce image for the nested vm
  <cachio> and we create the image as part of the test
  <kyrofa> cachio, yeah it was more the "Enabling nested virtualization on an instance" section that I was referring to
  <kyrofa> Makes it sound like by default this won't work unless you take that action to add that licenses thing
  <kyrofa> cachio, yeah, looks like multipass needs KVM:
  <kyrofa> # multipass launch xenial
  <kyrofa> failed to launch: CPU does not support KVM extensions.
  <kyrofa> # grep -cw vmx /proc/cpuinfo
  <kyrofa> 0
  <kyrofa> cachio, looks like we indeed need "the special license key required for virtualization."
  <cachio> in that case we need to create an image with kvm enabled
  <cachio> kyrofa, let me check a bit more about enabling kvm on gce
  <kyrofa> cachio, would there be a downside to just enabling that in all the images we're using?
  <kyrofa> cachio, excellent, thank you
  <cachio> kyrofa, dont have enough permissions for that
  <cachio> I'll request them and I'll try again
  <kyrofa> Alright cachio, thank you!
  <cachio> kyrofa, np
   * cachio afk
  <mup> PR snapcraft#2364 opened: maven plugin: add support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2364>
   * zyga EODs
  <mup> PR snapcraft#2365 opened: multipass: change default CPU value <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2365>
  <mup> PR snapcraft#2366 opened: qmake plugin: add support for bases <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2366>
   * cachio afk
  <mup> PR snapcraft#2264 closed: Fix issue where Rust cross compile target is ignored <Created by eberkund> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2264>
  <mup> PR snapcraft#2365 closed: multipass: change default CPU value <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2365>
  <mup> PR snapcraft#2367 opened: tests: add spread test exercising multipass build VMs <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2367>
  <mup> PR snapcraft#2368 opened: {kbuild,kernel} plugin: add support for bases <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2368>
  <mup> PR snapcraft#2366 closed: qmake plugin: add support for bases <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2366>
  #snappy 2018-10-19
  <mup> PR snapcraft#2368 closed: {kbuild,kernel} plugin: add support for bases <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2368>
  <erio> anything obviously wrong with this snapcraft.yaml ? https://pastebin.com/GSWxvuAQ
  <erio> maaaan.. cleanbuild takes ages
  <mup> PR snapcraft#2369 opened: Hide progress bar for dumb terminals <Created by eberkund> <https://github.com/snapcore/snapcraft/pull/2369>
  <mborzecki> morning
  <mborzecki> got to run an errand, back in ~30
  <zyga> Hey
  <zyga> Hey mvo
  <mvo> hey zyga
  <zyga> Prepping for SLC?
  <zyga> I forgot to mention that I will be working with Zbyszek from red hat today
  <zyga> I plan to discuss some Fedora issues as well as some cgroup topics
  <zyga> I will be around as usual, sort from the extra commute
  <mvo> zyga: yeah, preparing
  <mvo> zyga: cool, good luck
  <zyga> mvo: can you think of any systemd topics to ask about?
  <zyga> mborzecki: ^
  <mvo> zyga: heh - the mount race
  <mvo> zyga: but maybe not
  <zyga> Oh, for sure
  <zyga> No?
  <mvo> zyga: I mean, if its really util-linux then its none of his concern
  <mvo> zyga: but *maybe* it is not, might be nice to hear his opinion
  <zyga> I think it is worth trying at least
  <mvo> yeah
  <pstolowski> morning
  <mborzecki> zyga: yes, systemctl start <many-services> as single transaction
  <mborzecki> need to go to kids school
  <mborzecki> zyga: https://bugs.launchpad.net/snapd/+bug/1796125
  <mup> Bug #1796125: services in a snap with dependencies aren't started in correct order on install <snapd:New for maciek-borzecki> <https://launchpad.net/bugs/1796125>
  <mborzecki> zyga: there are links to systemd github issues in the comments
  <mborzecki> zyga: would be great if he had a suggestion for a reasoanble workaround, or eta if they plan to do it
  <mborzecki> bbiab
  <mup> PR snapd#6014 closed: ifstate: fix decoding of json numbers <Created by mvo5> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/6014>
  <zyga> mborzecki: the one with services?
  <zyga> mborzecki: he replied on it already
  <zyga> But I will ask just in case :-)
  <zyga> Hey Chipaca
  <Chipaca> hey yourself
  <zyga> Chipaca: do you have any questions or issues to raise about systemd?
  <Chipaca> zyga: ?
  <Chipaca> zyga: I don't, offhand, why?
  <zyga> Iâll work with Zbyszek today
  <zyga> He is a systemd upstream
  <Chipaca> ah
  <Chipaca> zyga: is there a way to cause all the starts/stops to be in a single transaction
  <Chipaca> zyga: or do we need to do the topological sort ourselves
  <Chipaca> (we already are, almost Â¯\_(ã)_/Â¯ )
  <Chipaca> zyga: dunno if you remember from yesterday, this is that we have before/afters in units in a snap, and those are respected at system boot, but when we systemctl start them all at snap install time, they're started without ordering
  <mvo> Chipaca: oh, yes, that is a good one
  <zyga> Iâll ask
  <Chipaca> also try to convince them to absorb something else, people can only hate on one thing at a time
  <Chipaca> :-p
  <zyga> Is this the same issue that war reported by ian?
  <zyga> Or better yet: do you have a link
  <zyga> Iâm on the tube now but I will collect them later
  <Chipaca> zyga: i think we talked about it in the standup
  <Chipaca> i don't have issues/links/etc to go with it
  <Chipaca> mborzecki: you around? let's chat about the snapname pr
  <zyga> mborzecki: ^ is this the same issue you mentioned?
  <Chipaca> relatedly, somebody is calling github.com/snapcore/snapd/client a "library" and i'm worried
  <pedronis> yes, if we need to treat it as one we need to know
  <pedronis> atm only asserts is officially used as a library, but from things we control tough
  <Chipaca> pedronis: https://github.com/snapcore/snapd/pull/6011#issuecomment-431214304
  <mup> PR #6011: Fix import as module by adding go.mod files <Created by ryanjyoder> <https://github.com/snapcore/snapd/pull/6011>
  <Chipaca> pedronis: and http://r.chipaca.com/client.png if you need to make a point about things
  <pedronis> Chipaca: it's mostly auth from store provoking the mess IÂ suppose
  <pedronis> we would need store/auth
  <pedronis> and to do reasosnable things with overlord/auth
  <pedronis> which is also misnamed atm
  <pedronis> and mixing a couple different concerns
  <Chipaca> pedronis: buy is the thing pulling in store
  <pedronis> not auth stuff?
  <pedronis> maybe that was long ago
  <Chipaca> no auth stuff
  <pedronis> yea, I see
  <pedronis> so it's Buy stuff
  <pedronis> :(
  <Chipaca> and it looks like it's just for a struct
  <Chipaca> or two
  <Chipaca> we could easily turn that one around
  <Chipaca> or we could go on and kill buy :-)
  <pedronis> after store, there's snap and overlord/auth
  <Chipaca> snap is http://r.chipaca.com/snap.png
  <pedronis> Chipaca: mmh, it doesn't import overlord/auth directly, or does it?
  <pedronis> anyway IÂ seem confused
  <pedronis> either way it's a bit of work to make it a "library"
  <Chipaca> pedronis: if I copy the structs for Buy in, all client depends on is snap and asserts
  <pedronis> asserts is fine
  <pedronis> IÂ suppose
  <Chipaca> pedronis: http://r.chipaca.com/client_pruned.png
  <Chipaca> so maybe we should do that
  <pedronis> Chipaca: the annoying bits  of snap,  are really that it pulls in squashfs,  dirs,  and maybe arch (IÂ don't remember how naive or not that is these days)
  <pedronis> also snapdir
  <Chipaca> pedronis: why is the squashfs import annoying?
  <Chipaca> dirs is fine, it's just config
  <Chipaca> arch is a funny one, mostly because i'm not sure it needs to be its own package
  <pedronis> Chipaca: because is conceptually wrong, and because one day it might brings in a big library instead of shelling out
  <Chipaca> pedronis: can you explain the misconception to me?
  <pedronis> Chipaca: dealing with snaps abstractly/remotely vs concrentely are very different things
  <Chipaca> ah
  <Chipaca> pedronis: well, it would be easy to split
  <pedronis> it's just a taste thing
  <pedronis> but the bring in a library bit is a bit more serious
  <Chipaca> pedronis: snap/container.go -> snap/container/container.go (or some better name)
  <pedronis> potentially
  <pedronis> Chipaca: osutil/sys is also interesting
  <Chipaca> then snap can be the abstract, and snap/container be the "open this thing" and the "build this thing" aspects of it
  <Chipaca> osutil and osutil/sys are in the middle of finding themselves
  <Chipaca> :-p
  <Chipaca> the idea is that osutil/sys is like syscall, and has friendly wrappers in osutil
  <Chipaca> but there's work to do to finish that division, and so things are a bit messy still
  <Chipaca> (including a bit of duplication)
  <Chipaca> i'm not sure if that makes it better or not :-)
  <pedronis> Chipaca: just wondering why snap imports it
  <pedronis> directly
  <mup> PR classic-snap#21 closed: create: improve user information <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/classic-snap/pull/21>
  <Chipaca> pedronis: without looking, probably sys.UserID and sys.GroupID
  <Chipaca> now looking
  <Chipaca> 	UserXdgRuntimeDir(userID sys.UserID) string
  <pedronis> I see
  <pedronis> mmmh
  <pedronis> lots of conceptual decisions to make
  <pedronis> Chipaca: in theory the easiest is to invert and have anything in snap that client needs live in client, import client from snap
  <pedronis> but I'm not 100% happy with that
  <pedronis> either
  <Chipaca> pedronis: why not?
  <Chipaca> (sorry if this explain-your-thinking interrogation gets boring)
  <mup> PR classic-snap#26 opened:  Add simple spread tests <Created by mvo5> <https://github.com/snapcore/classic-snap/pull/26>
  <pedronis> Chipaca: it reads strange to me
  <pedronis> client.Revision
  <pedronis> is odd
  <pedronis> maybe is just me
  <Chipaca> ah, yes
  <Chipaca> no not just you
  <Chipaca> when i was saying we could do that i found the same thing
  <Chipaca> OTOH we could have client/snap and internal/snap?
  <Chipaca> dunno
   * pedronis errands
  <Chipaca> pedronis: ttfn
  <zyga> re
  <mup> PR snapd#6015 closed: tests/unit/gccgo: drop gccgo unit tests <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6015>
  <mup> PR snapd#6018 opened: nuke tests/unit/go-darwin <Created by chipaca> <https://github.com/snapcore/snapd/pull/6018>
  <Chipaca> I'd love to get reviews of #5955
  <mup> PR #5955: cmd/snap, tests: snapshots for all <Snapshots ð¸ó > <Created by chipaca> <https://github.com/snapcore/snapd/pull/5955>
  <Chipaca> it's green! and the only thing between us and snapshots
  <mup> PR classic-snap#27 opened: add shellcheck and fix warnings (16) <Created by mvo5> <https://github.com/snapcore/classic-snap/pull/27>
  <mborzecki> re, finally
  <mup> PR snapcraft#2362 closed: python plugin: add support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2362>
  <mup> PR snapcraft#2364 closed: maven plugin: add support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2364>
  <mborzecki> Chipaca: thanks for the reviews
  <mborzecki> Chipaca: any suggestions about snap/name?
  <Chipaca> mborzecki: I didn't understand your response to my comment :-)
  <Chipaca> sorry, stray middle click
  <Chipaca> mborzecki: what do you mean by "you'd still need to have access to snap.Info"?
  <Chipaca> mborzecki: how is that different between snap/validate and snap/name?
  <mborzecki> Chipaca: hmm maybe i misunderstood yours
  <Chipaca> mborzecki: ah
  <mborzecki> Chipaca: i thought you'd want to have all the validation code (now in snap/validate.go) in a seaprate snap/validate package?
  <Chipaca> mborzecki: mine was just: everything in name is called ValidateX
  <Chipaca> mborzecki: so why not call it validate :)
  <Chipaca> mborzecki: then using snap/validate primarily in snap/validate.go is a nice pattern as well
  <Chipaca> we do that in a few places even
  <mborzecki> Chipaca: right, but then we'd end up with some validate*() in snap/validate.go and some in snap/validate, felt a bit uneasy about that
  <mborzecki> Chipaca: but you have a point, it's snap/name now but all of it actually validation :/
  <Chipaca> mborzecki: looking at snap/validate.go in your pr, 1 sec
  <Chipaca> mborzecki: snap.ValidateVersion could move into the new package
  <Chipaca> dito snap.ValidateLicense
  <mborzecki> Chipaca: license calls out to spdx package?
  <Chipaca> yes
  <mborzecki> Chipaca: i think i'd rather keep it ValidateLicense in snap then
  <Chipaca> hm
  <Chipaca> mborzecki: so
  <Chipaca> mborzecki: how about keeping just snap.Validate as the public interface, and making everything else be either in snap/validate or private in snap?
  <mborzecki> Chipaca: the motivation was to not have another copy of ValidateName() in asserrts, but rather have a package slimmer than snap and have it importable in asserts
  <Chipaca> ha, now i understand the no-spdx thing more :-)
  <Chipaca> mborzecki: this strengthens my last suggestion above
  <Chipaca> i think
  <mborzecki> Chipaca: hm, let me check again, iirc snap.ValidateLayout may still need to be public, but the rest could be make private
  <Chipaca> grep says nothing uses it outside of snap.Validate
  <mborzecki> Chipaca: ValidateContainer is probably the only func other than Validate() that would need to be public
  <mborzecki> i see some calls to ValidateSlotName() but that would be validate.SlotName() (or validate.Slot()) now
  <mborzecki> Chipaca: yeah, snap/validate seems ok, a question about naming, since the validation code is mostly validating names right now, validate.SnapName() feels more fitting than validate.Snap(name string)
  <mup> PR snapd#6019 opened: ifacestate: optimize disconnect hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6019>
  <pedronis> Chipaca: the problem of making it validate that it will be very tempting to move Validate itself or other things into it at some point
  <pedronis> Chipaca: also there are some name related regexpes that asserts could reuse
  <pedronis> Chipaca: making it about names (which are strings in the end), makes it easier to keep under control imo
  <mborzecki> snap/validate/name :)
  <pedronis> that is not funny
  <pedronis> Chipaca: mborzecki: anyway my 2cts
  <mborzecki> pedronis: which regexp you'd like to see public?
  <pedronis> mborzecki: asserts has at least a validAppName and validAlias atm
  <pedronis> degville: hi,  somebody liked this just now which Â I wrote long ago,  https://forum.snapcraft.io/t/the-meaning-of-classic/861 is not under doc because niemeyer said he wanted to tweak it a bit but didn't get to it, maybe you can do something with it when you have time
  <pedronis> mborzecki: Chipaca: another approach would be to find something a bit more encompassing than "name" and also put Channel and some helpers for the various kind of IDs we have there
  <mborzecki> Chipaca: do you have /usr/bin/tar?
  <mup> PR snapd#6020 opened: overlord/snapshotstate/backend: detect path to tar in unit tests <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6020>
  <mborzecki> Chipaca: ^^
  <niemeyer> zyga: I've responded on the adb interface.. sorry that it's not just a LGTM, but the current proposal there looks quite cumbersome, and a bad precedent.. we should probably talk about it in a call if you have a moment
  <zyga> niemeyer: thank you, I'll check that out
  <zyga> niemeyer: perhaps next week, it's not urgent IMO
  <niemeyer> zyga: Today is better if you have a moment.. next week I'm in SLC
  <niemeyer> zyga: It's not urgent.. it's just been sitting there for very long
  <zyga> niemeyer: I'm not at home today but I'll try to find a moment
   * pstolowski lunch
  <zyga> niemeyer: I read the response, I think you are right and this feels like a new thing - with foo-support like approach we could have the adb  server part solved, I think we should still have the adb client part
  <niemeyer> zyga: We can have that to actually make the inter-snap logic work, but I wouldn't try to bake that in together
  <niemeyer> zyga: As that's not required for the person that submitted that request, as I understand it, and it would take longer to agree on the details
  <zyga> yes, that's true
  <zyga> the user would just run adb internally
  <niemeyer> zyga: Yeah, that sounds a lot like browser-support
  <niemeyer> zyga: And it becomes pretty sensible from the outside
  <zyga> I can make those changes if that's what we agree on
  <niemeyer> zyga: once we need a snap using adb from another snap, we can then have an "adb" plug+slot interface, that do just that
  <zyga> +1
  <niemeyer> zyga: If we can make that work, we can even get that merged today
  <zyga> sure, that would be nice :)
  <niemeyer> zyga: Since the details of what's allowed was already approved
  <niemeyer> zyga: (by jdstrnad)
  <niemeyer> zyga: Same as in the current incarnation, we shouldn't allow access to the devices unless adb-support is connected
  <niemeyer> zyga: There's another part which feels a bit awkward in that interface which is the network bits
  <niemeyer> zyga: Does it grant open access into the network?
  <zyga> ish
  <zyga> it needs localhost sockets
  <zyga> it's like network
  <zyga> this is how adb operates
  <zyga> (well network-bind and network()
  <niemeyer> zyga: Sure, but the comments there make it sound like we're granting open ended access into the network via that interface
  <niemeyer> zyga: That sounds undue
  <zyga> that's because we have no richer language
  <zyga> yes , that is true
  <niemeyer> zyga: If it's open ended and not localhost, and unless there's more missing that would prevent the access from being actually used for general network access, I think we can drop those permissions and mention that they'll need "network-bind" as well
  <niemeyer> zyga: Sure, and in some cases that's alright, but here it feels like we have a very purpose-specific interface that is then offering something unexpected, and unnecessarily so since we have another interface that grants exactly those permissions
  <niemeyer> zyga: Once we get the ability to define network context, we can include in the interface, and nobody breaks
  <niemeyer> The opposite isn't true
  <zyga> in a way but it is also internal part of the interface, it will always be broken without network-bind
  <niemeyer> zyga: That's not an internal part of the interface unless we define that it is
  <niemeyer> zyga: If it's open ended network access, I'd generally recommend letting people explicitly ask for it
  <niemeyer> jdstrand: ^
  <zyga> I mean without network-bind, adb will crash
  <niemeyer> zyga: Doesn't hurt, comes for free with auto-connection, and is truthful to what the snap is being able to do
  <zyga> sure, I don't mind that
  <zyga> I can make the modifications today
  <niemeyer> zyga: I understand.. that's why they'll use the plug..
  <niemeyer> zyga: Once we're able to further restrict so that it's not open ended access, we can be more precise in what we offer
  <niemeyer> zyga: and the interface might become self-sufficient
  <zyga> yeah, that's a good point
  <mup> PR snapcraft#2367 closed: tests: add spread test exercising multipass build VMs <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2367>
  <niemeyer> zyga: Pasted this conversation into the ticket for reference
  <niemeyer> zyga: Sorry for the terrible copy & paste... my client has c&p broken right now
  <Chipaca> pedronis: mborzecki: i'm ok with it not being validate if that'll keep it about simple strings as opposed to more complex stuff, if we don't want it to have more complex stuff (and i guess using it from asserts means we don't)
  <zyga> niemeyer: thank you :-)
  <niemeyer> I'm going to have lunch
  <zyga> enjoy :)
  <niemeyer> Thanks
  <Chipaca> pedronis: mborzecki: otoh i maintain that 'name' is a bad name :-) note how everywhere you use it you have to re-name (groan) it
  <Chipaca> pedronis: mborzecki: combine that with pedronis's observation about having other things we could move out if it weren't called 'name', and i really want it called something else :-)
  <Chipaca> pedronis: mborzecki: call it "english-racing-green"
  <mborzecki> Chipaca: moss?
  <mborzecki> a package full of surprises
  <Chipaca> i thought that was lichen
  <Chipaca> mborzecki: 'twas a bikeshed joke, just in case it was too unobvious
  <mborzecki> Chipaca: it was
  <Chipaca> sary
  <mborzecki> uh, it wans't :)
  <Chipaca> saryn't
  <Chipaca> things we want that package to do: validate instance names, validate snap names, validate channels, validate other ids
  <Chipaca> things we can't call it because conflicting things with too similar names; snapids, snapidents
  <Chipaca> name that probably only serves to make me giggle: snapvalids (groan)
  <noise][> you should feel bad about yourself Chipaca :)
  <Chipaca> every day, noise][. Every day.
  <pedronis> Chipaca: handle (the name, not the verb), moniker, refer, designate, nominate
  <Chipaca> nomnomnom
  <Chipaca> hmm, lunch
  <rbasak> Are the various SNAP_ environment variables documented anywhere? I'm looking at docs.snapcraft.io and don't see it anywhere obvious, and I'm a bit lost after the refactor.
  <rbasak> The environment variables were previously the reference section IIRC, but that doesn't seem to be there any more.
  <popey> google got me to https://snapdocs.labix.org/look-at-this/5368
  <popey> which is a mad url
  <Chipaca> popey: https://docs.snapcraft.io/moved-environmental-variables-that-snapcraft-exposes/5368
  <Chipaca> popey: dunno where it was moved to, offhand
  <Chipaca> popey: but until they get hidden, you can use the ids to find stuff :-)
  <rbasak> I want SNAP_* rather than SNAPCRAFT_*
  <rbasak> And also what they mean rather than what they're set to
  <mborzecki> rbasak: try this https://forum.snapcraft.io/t/security-policy-and-sandboxing/554
  <Chipaca> rbasak: https://docs.snapcraft.io/environmental-variables/7983
  <rbasak> Thanks!
  <rbasak> Though that doesn't explain SNAP_INSTANCE_DATA?
  <Chipaca> that'll be in https://docs.snapcraft.io/parallel-installs/7679
  <Chipaca> but i agree it should get added to the other one
  <Chipaca> mborzecki: ^ :-)
  <Chipaca> augh, i need to go have lunch
   * Chipaca goes
  <mborzecki> w8, why doesn't https://docs.snapcraft.io/environmental-variables/7983 have SNAP_INSTANCE_NAME?
  <rbasak> Thanks! That page also doesn't explain SNAP_INSTANCE_DATA, but I think from the context it's clear I can ignore SNAP_INSTANCE_*
  <mborzecki> rbasak: which version of snapd do you have? SNAP_INSTANCE_DATA is no more
  <rbasak> 2.34.2 on Xenial on this particular system
  <mborzecki> rbasak: ah ok, makes sense now
  <mborzecki> degville: added a note about SNAP_INSTANCE_NAME and SNAP_INSTANCE_KEY to https://forum.snapcraft.io/t/environmental-variables/7983
  <degville> mborzecki: thank you!
   * Chipaca sneaks SNAP_TROLL_NAME in to keep people on their toes
   * Chipaca is making lunch, so technically on lunch break
  <popey> can we s/environmental/environment/ too :)
  <popey> always makes my teeth clench when i see 'environmental'
  <mborzecki> degville: ^^
  <mborzecki> hm discourse should be smart enough to figure it out when the topic is changed
  <Chipaca> popey: to be fair, the environ is mental
  <popey> wakka wakka wakka
  <niemeyer> mborzecki: It pops it up in the list, but it doesn't resend notifications
  <degville> popey/mborzecki: changed.
  <popey> <3
  <degville> aww, shucks.
  <mborzecki> interesting observation, not a problem though, i was automatically redirected to https://forum.snapcraft.io/t/environment-variables/7983 by discourse, but the same did not happen on docs.snapcraft.io
  <Chipaca> mborzecki: 'snap fork a-snap a-snap_foo'
  <zyga> Chipaca: snap wait ...
  <zyga> oh wait!
  <Chipaca> or maybe 'snap switch --rename=a-snap_foo a-snap'
  <Chipaca> hmm
  <zyga> Chipaca: snap rename
  <Chipaca> snap rename core core18
  <Chipaca> mbuahaha
  <Chipaca> switch is wrong, because it isn't instant
  <Chipaca> it'd have to be 'snap refresh' and then not having the equivalent switch would be strange
  <Chipaca> so maybe 'snap rename' is the potato
  <mup> PR classic-snap#28 opened: enable spread tests for core as well <Created by mvo5> <https://github.com/snapcore/classic-snap/pull/28>
  <Chipaca> snap instantiate
  <Chipaca> snap summon
  <mup> PR snapd#6021 opened: data/systemd, wrappers: tweak system-shutdown helper for core18 (2.36) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6021>
  <mborzecki> Chipaca: conjure
  <Chipaca> snap dwim
  <Chipaca> snap frogger
   * Chipaca checks his drink
  <Chipaca> looks like it's free-association-friday
  <zyga> I'll skip standup to grab some food, plus no way to have a call now
  <rbasak> I'm improving the git-ubuntu importer service, which lives inside the snap and is currently just a command. I want to make it into a systemd service which a sysadmin can enable, and once enabled, it will run as a specific user (not root). It seems to make sense to me to put its persistent data in $SNAP_DATA. But: 1) how should I ship a snap such that the service isn't enabled by default, but it can be
  <rbasak> enabled; 2) $SNAP_DATA is owned by root. Can I change that? What should the mechanism be to do that?
  <rbasak> Most git-ubuntu users will never use the service. However we maintain it in the same code base, and the snap is a convenient way of deploying it. I could split it into a different snap but would like to avoid having to maintain two.
  <rbasak> (and splitting it doesn't help me with ownership of $SNAP_DATA I don't think)
  <mup> PR snapd#6020 closed: overlord/snapshotstate/backend: detect path to tar in unit tests <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6020>
  <Chipaca> rbasak: so, first off, we don't currently support running services as non-root
  <Chipaca> rbasak: nor do we support setuid and fly
  <Chipaca> rbasak: but, to ship a service that's default disabled you can have a hook
  <Chipaca> rbasak: e.g. have a config hook that creates a file, and the service starts and quits if the file isn't there
  <mborzecki> Chipaca: in current master you can disable it from install hook
  <Chipaca> yes :-) but that's a week or so away at least
  <Chipaca> probably more
  <Chipaca> mborzecki: is it 2.36?
  <mborzecki> or --edge :)
  <rbasak> Chipaca: thanks
  <mborzecki> Chipaca: yes
  <rbasak> Given that the service is only expected to be used by (essentially just) me, perhaps I'll keep the service out of the snap for now then, together with its persistent directory.
  <rbasak> The classic snap gives me a command, and maybe I can run that command using a manually (non-snap) defined systemd service.
  <rbasak> Then I can run it as a user as well.
  <Chipaca> rbasak: OTOH james h has been working on user session services, but I have no idea how usable that is yet
  <Chipaca> rbasak: solutions are in the pipeline --- but it's a long, thin pipe
  <Chipaca> and it's like molasses in there :-p
  <mup> PR snapd#6007 closed: tests/lib: add an @mozilla.com exception to the CLA checker <Simple ð> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6007>
  <Chipaca> mvo: thanks!
  <mvo> Chipaca: thank you!
  <mup> PR snapd#6013 closed: Revert "snap, client, daemon, store: use and expose "media" more (#5906)" <â Blocked> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6013>
  <mup> PR classic-snap#29 opened: create: only copy config that exists <Created by mvo5> <https://github.com/snapcore/classic-snap/pull/29>
  <Chipaca> mvo: one last 2.36 pr cooking here
  <Chipaca> do we support running on ecryptfs?
  <cachio> mvo, https://paste.ubuntu.com/p/M5ZP7S4Jgn/
  <cachio> this is the debug info for the snapd.socket issue
  <cachio> mvo, perhaps that could help to understand the root cause of the issue
  <mup> PR snapd#6022 opened: daemon, snap: mark screenshots as deprecated <Created by chipaca> <https://github.com/snapcore/snapd/pull/6022>
   * cachio lunch
  <mup> PR snapd#6023 opened: overlord/snapstate, snap, wrappers: start services in the right order during install <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6023>
  <mborzecki> Chipaca: mvo: ^^
  <mborzecki> I've tagged it 2.36 but I guess 2.36.1 will be fine too
  <greyback> hey, I'm hacking on snapd to test a new interface, but getting stuck on "error: snap "core" has "auto-refresh" change in progress"
  <greyback> but I can't see any evidence of a refresh happening, and it's not changing out of this state either with time
  <Chipaca> greyback: are you running snapd from the terminal?
  <mvo> mborzecki: thank you
  <greyback> Chipaca: yes. I'm doing: https://pastebin.ubuntu.com/p/S2GvCRWFjV/
  <mvo> cachio: thanks, checking
  <mvo> Chipaca: I think we do, iirc one of my systems if using it
  <greyback> Chipaca: if there's a better way to launch custom snapd, I'd happily use it
  <Chipaca> greyback: I use https://github.com/chipaca/bin/blob/master/run-snapd-srv but that might be just me
  <Chipaca> greyback: with your approach, don't you end up with a bunch of weirded bind mounts?
  <mborzecki> i just switch the binaries and let systemd restart the service
  <Chipaca> greyback: in any case, i'd be interested in the debug logs from snapd
  <greyback> Chipaca: I've only started using it today (found it in the forum), zyga's devscripts not working for me any more
  <mup> PR classic-snap#26 closed:  Add simple spread tests (16) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/classic-snap/pull/26>
  <Chipaca> my script uses the fact that you can just run the snapd binary and it'll figure stuff out, mostly
  <Chipaca> but, anyway, the how is immaterial as long as i can see those logs ;-)
  <mborzecki> Chipaca: right, just snapd works fine, when you do changes in snap-{confine,update-ns,exec} things get hairy :)
  <greyback> Chipaca: http://paste.ubuntu.com/p/NmsMKVRyRw/
  <Chipaca> greyback: dude, turn on debug :-)
  <mborzecki> greyback: SNAPD_DEBUG=1
  <greyback> Chipaca: apologies! I only dabble in snapd
  <Chipaca> runs-snapd-srv sets all those for you :-)
  <greyback> Chipaca: aha line 4040 of https://paste.ubuntu.com/p/F32PzrKq8M/ shows something not happy with lxd
  <greyback> auto-connect of snap "lxd" will be retried because of "lxd" - "core" conflict
  <Chipaca> that's strange
  <Chipaca> that should either resolve or blow up, unless I misunderstood things
  <Chipaca> greyback: what's "snap tasks --last=auto-refresh" say?
  <Chipaca> assuming that's an auto-refresh and not an install. Maybe should've started with "snap changes" to figure that one out
  <greyback> Chipaca: https://pastebin.ubuntu.com/p/tr6t5T5Nz5/ for snap tasks
  <greyback> https://pastebin.ubuntu.com/p/xt64zHTM3N/ for changes
  <Chipaca> greyback: what happens if you "snap abort 171"?
  <Chipaca> it's been stuck there since yesterday :-(
  <Chipaca> this should not happen
  <Chipaca> greyback: the interfaces you're playing with have nothing to do with lxd, i presume
  <greyback> Chipaca: yes, I'm not touching lxd
  <greyback> Chipaca: ok that unblocked things
  <pstolowski> that looks like an incarnation of an old bug i hoped i fixed
  <Chipaca> greyback: the pastebins, did you set an expire on them?
  <pstolowski> greyback: can you send me your state.json?
  <pstolowski> cachio: hey, can you ping me when back from lunch?
  <Chipaca> pstolowski: that's snapd/2.36~pre2+git964.f71d856~ubuntu16.04.1 fwiw
  <Chipaca> pstolowski: so, quite fresh :-)
  <greyback> Chipaca: expiry on just 1: https://pastebin.ubuntu.com/p/tr6t5T5Nz5/. I'll repaste
  <Chipaca> greyback: please
  <pstolowski> Chipaca: yes, that's why i say incarnation of old bug ;)
  <greyback> Chipaca: https://pastebin.ubuntu.com/p/KFtytY5scV/
  <Chipaca> pstolowski: :-(
  <Chipaca> greyback: thanks
  <pstolowski> greyback: send my your state.json if you can but not pastebin, it has private bits
  <Chipaca> also it can be big :-)
  <greyback> pstolowski: https://paste.ubuntu.com/p/X96gdkt3rG/
  <greyback> oops
  <greyback> oh well
  <pstolowski> here you go...
  <Chipaca> heh
  <Chipaca> greyback: easy fix: snap logout
  <greyback> Chipaca: ta :)
  <pstolowski> yeah you need new macaroon now
  <Chipaca> raspberry macaroon for me plz
  <pstolowski> pastebin.c.c is wonderfull... shows me entire content, but asks for auth only if i want to download as text
  <Chipaca> pstolowski: that's because of abuse
  <Chipaca> Â¯\_(ã)_/Â¯
  <Chipaca> people using it to host stuff
  <pstolowski> ah, hmm... interesting
  <Chipaca> and, stuff from a canonical.com domain no less. What could go wrong.
  <Chipaca> ubuntu.com*
  <Chipaca> bah, either, same diff
  <Chipaca> (so if you convince a browser to load it as .js, it has access to your cookies)
  <Chipaca> anyway
  <Chipaca> i need to run
  <Chipaca> and by that i mean leave, not actually run
  <Chipaca> running happens tomorrow
  <Chipaca> ttfn! ttyl
  <greyback> Chipaca: thanks for the help o/
  <pstolowski> have a good weekend Chipaca!
  <pstolowski> greyback: thanks for the state
  <greyback> np
  <greyback> oh, the lxd conflict thing is appearing in my logs again
  <pstolowski> oh, that's not good :(
  <pstolowski> greyback: was the core refreshed? or is it refreshing both core and lxd again?
  <greyback> pstolowski: just lxd I think: https://pastebin.ubuntu.com/p/qGx999YXy7/
  <pstolowski> greyback: can you send me your current state again? do not abort anything
  <greyback> pstolowski: https://pastebin.canonical.com/p/fQFwFwpbdD/
  <greyback> if I can reformat it to help you, let me know
  <pstolowski> greyback: dont worry, i json_pp it
  <greyback> ok
  <pstolowski> and analyze in emacs
  <mup> PR classic-snap#29 closed: create: only copy config that exists <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/classic-snap/pull/29>
  <mup> PR snapd#5989 closed: interfaces/system-key: add parser mtime and only discover features on write <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5989>
  <mup> PR snapd#6018 closed: nuke tests/unit/go-darwin <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6018>
  <mup> PR snapd#6002 closed: interfaces/system-key: add parser mtime and only discover features on write - 2.36 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6002>
  <mup> PR snapd#6021 closed: data/systemd, wrappers: tweak system-shutdown helper for core18 (2.36) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6021>
  <mvo> 6017 needs a second review
  <mvo> its a release blocker too
  <mvo> *please* :)
  <mvo> mborzecki: thanks for 6023, looks very good
  <mborzecki> mvo: thanks for the review
  <pstolowski> mvo: i'm worried about the issue greyback just hit
  <mvo> mborzecki: I will go over it once more but first pass looks great
  <mvo> pstolowski: edge? beta? stable?
  <mvo> pstolowski: sorry, miss context, should I just read scrollback?
  <pstolowski> mvo: 2.36~pre2+git964.f71d856~ubuntu16.04.1
  <mvo> pstolowski: btw 6017 looks also really nice
  <mvo> pstolowski: aha, I read a bit of backlog now - can you reproduce this?
  <mvo> pstolowski: it looks like a blocker :/
  <pstolowski> mvo: i'm just trying to reproduce. i also have the problematic state, but it's very time consuming to understand these things from state
  <pstolowski> mvo: i wish we had a detailed log message (what's conflicting)
  <mborzecki> pstolowski: we could push a PR adding a message
  <pstolowski> mvo: of course i cannot reproduce, it needs auto-refresh of lxd
  <mborzecki> before 2.36 is released that is
  <pstolowski> might be a good idea
  <pstolowski> hmm actually we have something on debug level, not super precise but may give a clue
  <pstolowski> greyback: assuming you still see the lxd stuck on auto-connect, can you run your snapd with SNAPD_DEBUG=1 env set?
  <pstolowski> greyback: i see you did that already. would be interesing to see it again
  <mup> PR snapcraft#2370 opened: ant plugin: add support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2370>
  <mvo> pstolowski: thanks, keep me updated, I will read backlog and keep this issue in mind
  <pstolowski> mvo: will do. i suppose you're departing soon for the sprint?
  <mvo> pstolowski: sunday morning so plenty of time. it sounds like I will do a 2.36~rc1 or even final early next week. hopefully I find time dduring the sprint for it
  <pstolowski> mvo: okay, safe travels then, talk to you on monday!
  <mvo> thanks
  <xnox> mvo, hey does snapd.seeded.service need internet / access to snapstore to complete?
  <xnox> or can it complete offline on boot?
  <cachio> pstolowski, I just saw yuor message
  <mup> PR snapcraft#2371 opened: plugins: remove jhbuild <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2371>
  <mvo> xnox: it should work completely offline (all assertions should be in the local disk). why? do you see different behavior?
  <xnox> mvo, awesome! no, it's just cloud-init for some reason forces it to be after networking is started, which is not good in this one cloud.
  <xnox> we'd rather have seeded snaps before/in-parallel-to network up
  <mvo> xnox: ok
  <pedronis> xnox: there is some requirement tough for some part of cloud-init identifying the cloud to be done before snapd starts, otherwise cloud decition/cloud CDN stuff will not work
  <pedronis> *detection
  <mup> PR snapcraft#2372 opened: gradle plugin: add support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2372>
  <stokachu> whats the url that is used during snapcraft push?
  <stokachu> i need to get a firewall update for it
  <stokachu> i thought it was dashboard.snapcraft.io?
  <stokachu> sergiusens: do you know? ^
   * cachio afk
  <stokachu> or noise][ ?
  <xnox> pedronis, i know that bit. but thanks for pointing out.
  <Dmitrii-Sh> https://bugs.launchpad.net/snapd/+bug/1791587/comments/4 <- found out that the proxy settings are not applied if the core snap is not installed
  <mup> Bug #1791587: [2.34.2] snapd ignores proxy settings set via core snap <cpe-onsite> <snapd:New> <https://launchpad.net/bugs/1791587>
  <cjwatson> I answered stokachu on #is
  <sergiusens> stokachu: one sec
  <stokachu> sergiusens: i got it already lol
  <stokachu> thanks though
  <sergiusens> stokachu: ah, sorry, was deep in the waters
  <stokachu> all good man
  <mup> PR classic-snap#30 opened: enable spread tests for core as well (16) <Created by mvo5> <https://github.com/snapcore/classic-snap/pull/30>
  <Chipaca> cachio: you around?
  <Chipaca> cachio: 2018-10-19 16:05:00 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"
  <Chipaca> Dmitrii-Sh: hi
  <Chipaca> Dmitrii-Sh: i thought we'd fixed that in 2.35 though
  <Dmitrii-Sh> Chipaca: hi
  <Dmitrii-Sh> Chipaca: I tried that when core was installed but apparently without the core snap it doesn't work
  <Dmitrii-Sh> Chipaca: also noted by the k8s team https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/676#issuecomment-431449672
  <Chipaca> Dmitrii-Sh: you're on 2.34
  <Dmitrii-Sh> Chipaca: hmm
  <Dmitrii-Sh> ok
  <Chipaca>   Installed: 2.34.2
  <Chipaca> Dmitrii-Sh: when you get the core snap, you run snapd from the core snap, which is 2.35
  <Chipaca> Dmitrii-Sh: that might be the difference :-)
  <Dmitrii-Sh> Chipaca: so, snapd comes from the core snap?
  <Chipaca> Dmitrii-Sh: can you update your snapd package to 2.35?
  <Chipaca> Dmitrii-Sh: on ubuntu, if the core snap is installed, yes
  <Dmitrii-Sh> Chipaca: wow, that's new to me
  <Dmitrii-Sh> Chipaca: is it present in apt repos already (updates?)
  <Dmitrii-Sh> Chipaca: 2.34.2+18.04 looks to be the newest one
  <Chipaca> Dmitrii-Sh: cosmic has 2.35.5
  <Dmitrii-Sh> the problem is that every environment that we deploy for customers uses LTS versions
  <Chipaca> right, the SRUs are chugging along
  <Dmitrii-Sh> Chipaca: I see http://people.canonical.com/~ubuntu-archive/pending-sru.html
  <Chipaca> I don't know if there's a 2.35.5 in the pipeline
  <Chipaca> 'snap info core' shows there's a 2.35.5 core, but not all updates to core need to be updates to the snapd package
  <Chipaca> mvo would know :-)
  <Chipaca> anyhow
  <Chipaca> Dmitrii-Sh: if you could install snapd from proposed, that'll tell us if this is actually fixed :-)
  <Dmitrii-Sh> Chipaca: https://launchpad.net/ubuntu/+source/snapd/2.35.4~14.04/+build/15523520
  <Dmitrii-Sh> seems like the SRU is waiting on arch-specific deps
  <Dmitrii-Sh> snapd
  <Dmitrii-Sh> ppc64el: Dependency wait
  <Dmitrii-Sh> arm64: Dependency wait
  <Dmitrii-Sh> powerpc: Dependency wait
  <Dmitrii-Sh> Chipaca: ah, that's for 14.04 only
  <Chipaca> Dmitrii-Sh: https://launchpad.net/ubuntu/+source/snapd/2.35.4+18.04 ?
  <Dmitrii-Sh> Chipaca: getting a container to test now
  <Chipaca> neat, thank you
  <Chipaca> I'll get a container for some ice-cream, meanwhile
  <Dmitrii-Sh> Chipaca: right ð
  <mup> PR snapcraft#2371 closed: plugins: remove jhbuild <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2371>
  <mup> PR snapcraft#2372 closed: gradle plugin: add support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2372>
  <cachio> Chipaca, updating it
  <Dmitrii-Sh> Chipaca: https://paste.ubuntu.com/p/qtsbwhc2cY/
  <Dmitrii-Sh> hmm
  <Dmitrii-Sh> tried restarting too
  <Dmitrii-Sh> root@snaptest:~# strace -e connect -f -p `pgrep -f snapd` &
  <Dmitrii-Sh> root@snaptest:~# snap install fcbtesting
  <Dmitrii-Sh> [pid  1313] connect(4, {sa_family=AF_INET, sin_port=htons(9), sin_addr=inet_addr("91.189.92.19")}, 16) = -1 ENETUNREACH (Network is unreachable)
  <Dmitrii-Sh> [pid  1313] connect(4, {sa_family=AF_INET, sin_port=htons(9), sin_addr=inet_addr("91.189.92.41")}, 16) = -1 ENETUNREACH (Network is unreachable)
  <cachio> Chipaca, #6024
  <mup> PR #6024: tests: new cosmic image for spread tests on gce <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6024>
  <mup> PR snapd#6024 opened: tests: new cosmic image for spread tests on gce <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6024>
  <cachio> if you have a minute to take a look
  <mup> PR snapcraft#2373 opened: rust plugin: add support for bases <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2373>
  <cachio> Chipaca, I'll merge it if the tests pass
  <Chipaca> cachio: thanks
  <Chipaca> Dmitrii-Sh: hmm
  <Chipaca> gah
  <Chipaca> Dmitrii-Sh: sorry, my bad
  <Chipaca> Dmitrii-Sh: the fix in 2.35 is about the proxy store, not the http proxy
  <Chipaca> Dmitrii-Sh: question, why aren't you setting the proxy via /etc/environment?
  <Dmitrii-Sh> Chipaca: Juju sets it via core snap proxy settings
  <Dmitrii-Sh> and that's how we set it on the whole env
  <Dmitrii-Sh> nowadays /etc/environment is untouched by juju
  <Dmitrii-Sh> so it's very targeted proxy config to avoid workloads from getting any proxy settings
  <Chipaca> hm
  <Dmitrii-Sh> in other words: if we deploy an HTTP service and a client, the client should not be affected by global environment settings because they speak within the same deployment behind a firewall/proxy
  <Chipaca> Dmitrii-Sh: is this on 18.04?
  <Dmitrii-Sh> and if a charm requires proxy usage it must explicitly use JUJU_CHARM_HTTP(S)_PROXY proxy settings (e.g. charms that do curl or wget)
  <Dmitrii-Sh> Chipaca: yes
  <Dmitrii-Sh> Chipaca: what we use as a workaround is cloudinit userdata + setting environment variables to the systemd unit of snapd. This makes it more rigid as changing juju snap-related model-configs does not change the proxy setup. Besides, Juju documents usage of these model-configs and while they set core proxy settings, it doesn't result in working deployments
  <Chipaca> right
  <Chipaca> we need to talk about these things i suspect
  <Chipaca> this is, to me at least, an unexpected use case
  <Chipaca> with the http proxy we'd always assumed that if you were in classic, environ was fine; if you were in core, you had core so 'snap set' would work
  <Chipaca> what you're saying is that you want 'snap set' to always work even if core isn't there, and that that needs to win over the environ
  <Dmitrii-Sh> Chipaca: well, essentially, we don't want /etc/environment to be modified by snapd because it affects services we start. Not all traffic goes to the internet and most of it stays within an internal network(s) so we only apply proxy settings for applications that really need them (like apt, snapd and other package managers).
  <Dmitrii-Sh> for example, that was a problem with Juju hooks because HTTP_PROXY in the environment resulted in charm failures when traffic was local (and it was it most cases)
  <Chipaca> Dmitrii-Sh: wait, if you don't want /etc/environment modified by snapd, why are you calling 'snap set core proxy.yadda'?
  <Dmitrii-Sh> Chipaca: to set proxy settings for snapd itself but only when it retrieves snaps from the store or from enterprise proxy (e.g. a store is behind an internal firewall)
  <Chipaca> i'm lost now
  <Chipaca> when you say 'enterprise proxy', you mean the proxy store?
  <Chipaca> because that's a different setting, that's the one we fixed
  <Dmitrii-Sh> yes-yes, let me break it down :^)
  <Chipaca> and that one wasn't touching /etc/environment afaik
  <Dmitrii-Sh> 1) proxy settings -> http transport object setting to use a proxy
  <Chipaca> break it down into small pieces because it's been a long week and it's nearly midnight
  <Dmitrii-Sh> 2) enterprise proxy settings -> retrieve snaps from here
  <Dmitrii-Sh> proxy settings + enterprise proxy settings -> retrieve snaps from here via an http proxy
  <Dmitrii-Sh> app proxy settings -> /etc/environment (global) or snap-specific options coded by snap authors to modify http transport settings of apps
  <Dmitrii-Sh> what we (ideally) want to achieve: settings are set via Juju model-configs snap-http-proxy, snap-https-proxy which translates into core snap proxy settings
  <Dmitrii-Sh> this covers case (1) above
  <Dmitrii-Sh> and app proxy settings are unaffected by this
  <Dmitrii-Sh> juju can also set snap-store-proxy	and snap-store-assertions	settings -> this will handle case (2) and modify the target URL of a snap store on snapd
  <Chipaca> Dmitrii-Sh: but you also want core snap proxy settings to not affect /etc/environment
  <Chipaca> in (1) i mean
  <Dmitrii-Sh> Chipaca: yes, because on a classic system this will potentially affect all workloads we deployed
  <Dmitrii-Sh> including the non-snap ones
  <Dmitrii-Sh> instead, we expect snaps themselves to expose proxy settings if they need to direct some application traffic via a proxy
  <Chipaca> Dmitrii-Sh: this is a rather big change of behaviour
  <Dmitrii-Sh> I am open to saying that per-snap global settings should be allowed because some snaps may be primitive in that regard
  <Chipaca> Dmitrii-Sh: are you in SCL next week?
  <Dmitrii-Sh> Chipaca: yes
  <Chipaca> Dmitrii-Sh: ok, talk it over with gustavo and/or mvo
  <Dmitrii-Sh> Chipaca: ok
  <Dmitrii-Sh> Chipaca: I'll just give you an example
  <Dmitrii-Sh> kubectl talks to kubeapi
  <Dmitrii-Sh> if we install it from a snap store via a proxy
  <Dmitrii-Sh> it doesn't mean kubectl should use proxy settings to talk to kubeapi
  <Chipaca> I do understand the use case, I think :)
  <Chipaca> what's there now is very simplistic, and only works on core and not classic
  <Dmitrii-Sh> right :^) in other words it's making only north-south traffic go through a proxy if needed, but leave east-west traffic within the data center unaffected
  <Dmitrii-Sh> north-south - download packages from the internet
  <Dmitrii-Sh> east-west - talk within a DC
  <Chipaca> so, one way to cover that is to expose that config, but skip the 'write /etc/environment' bit
  <Chipaca> on classic i mean
  <Chipaca> if we need the same thing on core then i dunno
  <Chipaca> it also means we need some internal thing with this, which i think we don't currently have
  <Chipaca> that is, i think we rely on the environment for this; we do store the config
  <Chipaca> hm
  <Chipaca> anyway, talk it over with snapd people in SCL
  <Chipaca> it's very doable, once we have a design
  <Chipaca> try to do it early in the week so I  can code it in the second half (i won't be there)
  <Chipaca> :-)
  <Dmitrii-Sh> Chipaca: ok, I'll do my best - a lot of people stumbled upon it in field engineering already
  <mup> PR snapcraft#2374 opened: build providers: destroy on create failures <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2374>
  <mup> PR snapd#6024 closed: tests: new cosmic image for spread tests on gce <Created by sergiocazzolato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6024>
  <mup> PR snapcraft#2370 closed: ant plugin: add support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2370>
  <mup> PR snapcraft#2375 opened: sanity checks: verify that command-chain is not used with legacy adapter <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2375>
  <mup> PR snapcraft#2373 closed: rust plugin: add support for bases <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2373>
  #snappy 2018-10-20
  <mup> PR snapcraft#2376 opened: jdk plugin: remove jdk <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2376>
  <mup> PR snapcraft#2377 opened: cli: remove disable-parallel-build and geoip toggles <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2377>
  <mup> PR snapcraft#2374 closed: build providers: destroy on create failures <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2374>
  <mup> PR snapcraft#2376 closed: jdk plugin: remove jdk <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2376>
  <mup> PR snapcraft#2375 closed: sanity checks: verify that command-chain is not used with legacy adapter <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2375>
  <mup> PR snapd#6006 closed: tests: move spread-shellcheck to run-checks --static <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6006>
  <mup> PR snapcraft#2377 closed: cli: remove disable-parallel-build and geoip toggles <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2377>
  <mup> PR snapcraft#2378 opened: Release chagelog for 3.0 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2378>
  <ping> Hi, I've a question about using snaps
  <ping> I have two GNU+Linux distros
  <ping> and is there a way to share the snaps between them?
  <ping> for example, storing them in a third SSD which I use to store stuff shared between both
  <ping> I want to do this because I've a very bad internet connection and re-download again the same set of snaps for all my distros is a little problematic
  <mup> PR snapd#6011 closed: Fix import as module by adding go.mod files <Created by ryanjyoder> <Closed by ryanjyoder> <https://github.com/snapcore/snapd/pull/6011>
  <mup> PR snapd#6025 opened: Add go.mod files <Created by ryanjyoder> <https://github.com/snapcore/snapd/pull/6025>
  <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>
  #snappy 2018-10-21
  <sborovkov> hi, is there an interface that gives permissions to set thread priority / cpu affinity?
  <mup> PR snapcraft#2378 closed: Release chagelog for 3.0 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2378>
  #snappy 2019-10-14
  <mborzecki> morning
  <zyga> mborzecki: good morning
  <mborzecki> zyga: hey
  <zyga> mborzecki: election results, uuuuh
  <mborzecki> zyga: not a surprise really
  <mvo> hey mborzecki and zyga
  <mborzecki> zyga: i'm happy sejm is more diversified, but wan's really expecting a significant power shift
  <zyga> hey mvo
  <zyga> mborzecki: did you see the new results this morning
  <zyga> mborzecki: pis has almost 50 now
  <mborzecki> mvo: hey
  <mborzecki> zyga: those aren't final yet
  <zyga> mborzecki: exactly :(
  <mup> PR core-build#57 opened: many: drop static files for "core" snap from the package <Created by mvo5> <https://github.com/snapcore/core-build/pull/57>
  <mvo> mborzecki, zyga: can I get a review for this please? and for https://github.com/snapcore/core/pull/83
  <mup> PR core#83: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
  <mborzecki> mvo: can you take a quick look at https://github.com/snapcore/snapd/pull/7587 ?
  <mvo> without one review from a team member I cannot merge
  <mup> PR #7587: spread: generate delta when using google backend <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7587>
  <mvo> mborzecki: sure
  <zyga> I'll be around in 15
  <mup> PR core-build#48 closed: config: remove static files in etc,lib,usr,var <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core-build/pull/48>
  <zyga> mborzecki: is school cancelled for your kids as well?
  <mup> PR snapd#7587 closed: spread: generate delta when using google backend <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7587>
  <mborzecki> mvo: left some comments under https://github.com/snapcore/core/pull/83
  <mup> PR core#83: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
  <mborzecki> mvo: i suppose it was like this before too
  <mvo> mborzecki: yeah, these files just move in this PR - happy to do a followup with fixes
  <mborzecki> mvo: +1
  <mvo> mborzecki: \o/
  <mborzecki> mvo: hm the travis job is red anyway
  <mvo> mborzecki: yeah, I need to tweak the ppa:snappy-dev/image archive as right now the builds are fighting over which content is correct
  <mvo> mborzecki: the coresponding one in core-build (57) is what is needed in the ppa to properly build
  <mvo> mborzecki: if you could also please look at https://github.com/snapcore/core-build/pull/57
  <mup> PR core-build#57: many: drop static files for "core" snap from the package <Created by mvo5> <https://github.com/snapcore/core-build/pull/57>
  <mvo> mborzecki: its the coresponding one for the one you reveiwed before
  <mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/83>
  <zyga> eoan woes :/
  <zyga> moving back to vm
  <pstolowski> mornings
  <mvo> hey pstolowski
  <zyga> hey pawel
  <mup> PR core-build#57 closed: many: drop static files for "core" snap from the package <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/57>
  <mup> PR core#107 opened: extra-file: drop restorecon from sshd-host-keygen <Created by mvo5> <https://github.com/snapcore/core/pull/107>
  <mborzecki> pstolowski: hey
  <mup> PR core#108 opened: extra-files: add /var/home to make snaps work on some distros <Created by mvo5> <https://github.com/snapcore/core/pull/108>
  <zyga> thanks for that
  <mborzecki> got to run an errand, back in a bit
  <mvo> zyga: my pleasure
  <mup> PR core18#141 opened: static: add /var/home to make snaps work on some distros <Created by mvo5> <https://github.com/snapcore/core18/pull/141>
  <mup> PR snapd#7594 opened: tests: replace "test-snapd-base-bare" with real "bare" base snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/7594>
  <mvo> zyga: also https://github.com/snapcore/bare-base/pull/1 (which I think mup is not monitoring yet)
  <mup> PR bare-base#1: Makefile: add /var/home to make snaps work on some distros #141 <Created by mvo5> <https://github.com/snapcore/bare-base/pull/1>
  <mborzecki> re
  <zyga> one sec
  <zyga> hmm
  <pstolowski> :
  <mborzecki> mvo: can you take another look at https://github.com/snapcore/snapd/pull/7536 ? it's unclear to me whether we're still missing something there or not
  <mup> PR #7536: gadget: accept system-seed role and ubuntu-data label <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7536>
  <mvo> mborzecki: in a meeting, but happy to do so later
  <mborzecki> mvo:  cool, thanks!
  <Chipaca> zyga: http://whatthecommit.com/index.txt
  <zyga> Chipaca: looking
  <zyga> hello btw :)
  <zyga> Chipaca: will you tell if I uses that :D ?
  <zyga> brb
  <zyga> let me get coffee
  <Chipaca> coffee sounds like a good idea
  <zyga> heh
  <zyga> my woes with eoan on suspend
  <zyga> translate to same woes in vmware on suspend
  <zyga> (vmware suspends VMs to save power if asked to by asking the os to suspend)
  <mup> PR snapd#7595 opened: seed/seedwriter: support writing Core 20 seeds (aka recovery systems) <Created by pedronis> <https://github.com/snapcore/snapd/pull/7595>
   * zyga runs spread _and_ gets that coffee he wanted
  <mborzecki> do you guys think it's legit to poke snapd api when a snap service is being stoped?
  <ondra> Chipaca I think I found another 20 seconds in first boot :0
  <ondra> Chipaca or more :)
  <pstolowski> ondra: hey, i'm working on pre-baking of firstboot stuff, with the plan to shave off those most expensive ops
  <pstolowski> pedronis: btw i saw your comment to Friday's standup notes, do you have a moment today to discuss?
  <Chipaca> ondra: tell me more :-)
  <ondra> pstolowski sure
  <Chipaca> pstolowski: ondra is finding things we can do that'll help current core16/18 though so as long as it's not disruptive it's good imho
  <ondra> Chipaca reading logs, we are trying to refresh catalogue from store, at very early stage. I'd think this is operation do not need to do pre-seeding
  <ondra> Chipaca it's so early in the boot, we have no network, so it keeps timing out.
  <Chipaca> ondra: you're saying skipping that saves us 20+ seconds?
  <ogra> yeah, snapd really shouldnt assume network ... we have many wlan equipped boards that first need wifi setup
  <ondra> Chipaca in our case there will be never network a this stage ( wireless only net interface, image has no baked in AP credentials)
  <ondra> Chipaca yep
  <pstolowski> ondra: funny you mention this as it's currently erroring/making noise in my pre-baking code (precisely because of no network in the chroot env) and i was about to look at what to do about it
  <Chipaca> ondra: you can trick it to skipping that step fwiw
  <ondra> Chipaca https://paste.ubuntu.com/p/73vXpjW3jf/
  <ondra> pstolowski Chipaca I'd argue that we have not even parsed seed.yaml, what do we actually need to refresh, or what do we expect to gain from it?
  <ondra> Chipaca pstolowski https://paste.ubuntu.com/p/3f2ZPHrtmt/
  <ondra> this shaved me 20 seconds and no noise
  <Chipaca> ondra: if you drop in a snapd.service.d file with [Service] ExecStartPre=touch /var/cache/snapd/names, that should have it skip that catalog refresh
  <ondra> pstolowski Chipaca does it sounds like something we can assume?
  <Chipaca> ondra: or that :-)
  <Chipaca> ondra: but, if you do that, can you make seeded trigger a catalog refresh?
  <ondra> Chipaca I was thinking to simply check if we are seeded, and if not, assume this is first boot
  <ondra> Chipaca you mean to trigger refresh after it's seeded?
  <Chipaca> ondra: that would mean no catalogues for the first day of the device
  <Chipaca> ondra: yes, please
  <Chipaca> ondra: it's called "refresh" but they don't exist before the first refresh succeeds
  <ondra> Chipaca this is first shot, I'm sure this can be done better way
  <Chipaca> ondra: fair enough
  <ondra> Chipaca but are you sure it works this way? because this refresh cannot succeed for many reasons
  <Chipaca> ondra: right, it failing means it tries again sooner
  <ondra> Chipaca there are no snaps installed, so what is it actually refreshing? if this is brand store it should have no way to access store anyway
  <ondra> Chipaca we only get serial assertion once seeded
  <Chipaca> ondra: right but you're changing code that affects everybody :)
  <ogra> pfft
  <ogra> who cares about the others
  <ondra> Chipaca then let's make it way it works way we want :)
  <ondra> Chipaca this was my first shot to see if I can use seeded as detection of first boot
  <ondra> Chipaca now we need to decide what to do next, ideally I was thinking to schedule refresh in say 10 minutes or something
  <ondra> Chipaca but I think you guys know first boot sequence way better than me, so you might have better idea
  <ogra> does refresh uses deltas ? could we pre-seed it with data at build time so it only needs to do a delta update ?
  <ondra> I do not know if we even know at that point number of snaps we are about to seed, so we can guess delay
  <ondra> ogra what refresh? this pings server before we have any snap installed
  <ondra> at that point, there zero snaps to check for refresh
  <ogra> i thought it queies the store and fills a local db
  <ogra> *queries
  <Chipaca> ogra: catalog refresh is not refresh
  <Chipaca> oh dear looks like i'm lagged
  <ogra> ah, ok
  <ogra> (just thinking about cutting down the amount of data to request and transfer to cut down time)
  <ondra> ogra you want to refresh before you have even first version, ever heard "trying to run before you can walk"
  <ondra> :P
  <Chipaca> ondra: so, what we want at some point is to move catalog-refresh to a task, and then trigger that task from the right places/times
  <zyga> mvo: some packaging changes may be needed https://forum.snapcraft.io/t/stop-commands-and-snapd-package-cleanup/13688
  <ondra> Chipaca that sounds good
  <Chipaca> ondra: easy peasy :-p
  <ogra> ondra, no, i want to pre-fill a db and only apply a delta so you dont need the full db data
  <ondra> Chipaca I'd do test boot to see refresh time, because we might trigger refresh when we get serial assertion
  <ondra> ogra I think we do not get db delta, as we are only pulling assertions we care about and relevant to the system
  <Chipaca> ondra: meanwhile your approach is a good step in the right direction. I'd suggest moving the check earlier, even, to where the CanAutoRefresh check is
  <ondra> ogra but I might be wrong
  <ogra> i'm probably tricked by the name "catalog-refresh" then :)
  <ondra> Chipaca I was not brave to put it that early, you say it's safe, then indeed better place
  <Chipaca> ondra: putting it super early means it gets to try again every ~5 minutes or so
  <Chipaca> ondra: that's what we want :-)
  <ondra> Chipaca ah yeah indeed that's good one
  <Chipaca> then once seeded it'll do the catalog refresh, and set the next catalog refresh time and back off
  <ondra> Chipaca yep, it seems it triggered refresh once it got serial assertion, even with current change
  <mvo> zyga: packaging change where exactly? in lxd? or snapd?
  <ondra> Chipaca I just did fresh boot with change I had, so we have good trigger post seeding as well
  <ondra> Chipaca OK I will update change based on your suggestion and prepare PR
  <ondra> Chipaca we can then iterate there
  <ondra> Chipaca thanks for help :)
  <Chipaca> ondra: thank you!
  <zyga> mvo: in snapd
  <mborzecki> zyga: mvo: yeah, the situation is puzzling
  <mborzecki> maybe let's talk after/during standup?
  <mborzecki> i guess there's a reason why it's done in postrm and not prerm like other distros
  <mvo> mborzecki: after sounds ok
  <mup> PR core18#141 closed: static: add /var/home to make snaps work on some distros <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/141>
  <ogra> wow, there are distros using /var/home as default ? crazy !
  <Chipaca> ogra: silverblue i think
  <ogra> (i used to do that on servers with /var being the data partition ... but would never have imagined a distro doing this by default)
   * pstolowski lunch
  <mup> PR snapd#7596 opened: Skip catalog refresh on unseeded system <Created by kubiko> <https://github.com/snapcore/snapd/pull/7596>
  <ondra> Chipaca pstolowski https://github.com/snapcore/snapd/pull/7596
  <mup> PR #7596: Skip catalog refresh on unseeded system <Created by kubiko> <https://github.com/snapcore/snapd/pull/7596>
  <ondra> pstolowski I also created this PR, to run assertion check in parallel https://github.com/snapcore/snapd/pull/7590
  <mup> PR #7590: seed: seed16: run adding snaps in parallel <Needs Samuele review> <Created by kubiko> <https://github.com/snapcore/snapd/pull/7590>
  <zyga> brb
  <zyga> 1
   * zyga needs to leave the house and think
  <zyga> or work anywhere but here
  <zyga> I cannot stand the smell anymore (kitchen nearby)
  <mup> Bug #1650738 changed: Scan network failure error after first reboot <Snappy:Fix Released> <https://launchpad.net/bugs/1650738>
  <mup> Bug #1649840 changed: unknown keys in model assertion are silently ignored <Snappy:Won't Fix> <Ubuntu Image:Invalid by sil2100> <https://launchpad.net/bugs/1649840>
  <mup> Bug #1651722 changed: Latest candidate snap breaks running snapcraft in classic snap <Snappy:Fix Released> <https://launchpad.net/bugs/1651722>
  <abeato> sil2100, hey, did you see my update to https://github.com/CanonicalLtd/ubuntu-image/pull/175 ?
  <mup> PR CanonicalLtd/ubuntu-image#175: Little kernel bootloader support <Created by alfonsosanchezbeato> <https://github.com/CanonicalLtd/ubuntu-image/pull/175>
   * Chipaca goes for a short walk
  <sil2100> abeato: hey! Yes, let me look at that and action in a bit, I'm on the release sprint right now
  <zyga> mvo: I'm on a slow network, I cannot join the standup with video today
  <zyga> not sure if audio will work, I'll do my best
  <mvo> zyga: no worries
  <abeato> sil2100, cool, take you time, thanks
  <zyga> I cannot connect
  <zyga> Eoan and modem manager :-/
  <mup> Bug #1749538 changed: refresh time docs lacks the correct command <docs> <Snappy:Fix Released by morrisong> <https://launchpad.net/bugs/1749538>
  <Chipaca> pedronis: wrt #1659153, I don't think there's a bug beyond the impedance mismatch (which could be alleviated by blocking private+name)
  <mup> Bug #1659153: /v2/find with select=private has different behaviour for queries and name searches <Snappy:Confirmed> <https://launchpad.net/bugs/1659153>
  <Chipaca> pedronis: OTOH I'm not sure what store bug you mean :-)
  <Chipaca> pedronis: snap find --name hits the store's 'info' endpoint
  <Chipaca> not the search one
  <mborzecki> mvo: pedronis: ok, added a note in the forum about the prerm thung we agreed on
  <mborzecki> pedronis: can you take another look at claudio's PR https://github.com/snapcore/snapd/pull/7536 ? i'm not sure there's more to do there, and if we land it then i could start looking into https://github.com/snapcore/snapd/pull/7593
  <mup> PR #7536: gadget: accept system-seed role and ubuntu-data label <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7536>
  <mup> PR #7593: recovery-tool: add sfdisk wrapper <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7593>
  <pedronis> mborzecki: I'll try to look today or tomorrow morning at that PR
  <mborzecki> pedronis: great, thanks!
  <zyga> I managed to somehow connect
  <zyga> at this rate I will run windows with WSL to get a machine that works :|
   * Chipaca sends zyga a raspberry pi
  <mborzecki> zyga: what's wrong with eoan?
  <zyga> mborzecki: suspend resume kills my input
  <zyga> mborzecki: then does something really odd to my modem
  <zyga> ended up powering off
  <zyga> and then powering on
  <zyga> then I can connect
  <zyga> reboot is not good enough
  <zyga> gnome-shell connection menu gets very confused when this happens, so I really reboot out of a habit now
  <mborzecki> zyga: btw. i think i asked abut it already, is the input and modem connected via usb?
  <zyga> mborzecki: I don't know
  <zyga> mvo: packaging question: should /usr/bin/snap be a symbolic link to /usr/lib/snapd/snap?
  <zyga> mvo: in our debian/ubuntu packages
  <rbasak> ANy help with hacking on snapcraft please?
  <zyga> mborzecki: I don't think the touchpad / trackpoint is using usb
  <rbasak> I'm trying to look at https://bugs.launchpad.net/snapcraft/+bug/1841861 but a day later I still haven't managed to figure out how to run snapcraft from the source tree :-/
  <mup> Bug #1841861: Python plugins fails to build a snap when some parts depends on unpublished modules <Snapcraft:New> <https://launchpad.net/bugs/1841861>
  <zyga> mborzecki: my knowledge ends at xinput that says:
  <zyga> SynPS/2 Synaptics TouchPad
  <rbasak> snapcraft seems to have its own plugin discovery and it's a plugin I'm trying to modify
  <zyga> TPPS/2 IBM TrackPoint
  <rbasak> But it's not using PYTHONPATH, and looking in the pip-installed area first.
  <rbasak> (having followed HACKING.md)
  <zyga> kenvandine: ^ actually, do you know how to debug xinput things going away on suspend
  <zyga> kenvandine: on my laptop suspend kills the trackpoint/touchpad until reboot
  <rbasak> And I'm about five levels deep in indirection trying to figure out how to get snapcraft to look in the source tree :-/
  <mvo> zyga: maybe, whats the advantage of doing it?
  <zyga> mvo: /usr/lib/snapd is enough to get all the new binaries
  <zyga> mvo: IIRC we do something like that on core18
  <mborzecki> zyga: hmm same on x250, not listed in lsusb
  <zyga> anyway
  <zyga> back to work
  <ijohnson> rbasak: I think the actual snapcraft devs such as cjp256 and sergiusens are off today, but also note that there is an additional channel for snapcraft specifically #snapcraft
  <rbasak> Joined, thanks!
  <sil2100> abeato: can we get https://snapcraft.io/docs/gadget-snap updated with the new names too?
  <abeato> sil2100, sure, let me edit
  <abeato> sil2100, ah, I thought that was the forum
  <abeato> sil2100, I don't know who needs to change that one
  <sil2100> Ah, the forum one too! I never know which one is the official one in the end
  <mvo> pedronis: do you want to review 7593 or do you think a review from maciej and me will be enough?
  <pedronis> mvo: I probably will not do a deep review, but I should look at it
  <abeato> sil2100, anyway, I've edited the forum one: https://forum.snapcraft.io/t/the-gadget-snap/696
  <pedronis> mvo: also is recovery-tool called recovery-tool? shouldn't it be snap-recovery ?
  <pedronis> where will it get installed?
  <pedronis> I asked in the PR itself
  <abeato> ijohnson, hi! do you know where is the latest version of the dpdk/hugepages interfaces?
  <ijohnson> abeato: you mean the one that luke worked/is working on?
  <abeato> yes
  <ijohnson> one minute let me look
  <pedronis> Chipaca: I made a meta-comment in #7589, would like your input
  <abeato> pedronis, fyi I have edited https://forum.snapcraft.io/t/the-gadget-snap/696 , updating the role names for lk partitions as was decided
  <mup> PR #7589: cmd/snap: add ability to register "snap internal" commands <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7589>
  <abeato> ijohnson, k
  <mvo> pedronis: I think snap-recovery is more approprate, yes
  <pedronis> abeato: thank you
  <ijohnson> abeato: last I heard from Luke, https://github.com/snapcore/snapd/pull/5885 was up-to-date, I helped him a bit with the dpdk snap here: https://github.com/anonymouse64/dpdk-snap/tree/wip
  <mup> PR #5885: Adding DPDK interface for DPDK Snap <Decaying â¢> <Created by wililupy> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5885>
  <ijohnson> err up-to-date insofar as that's all the work Luke had on it, not necessarily that it was complete
  <abeato> ijohnson, ok, thanks for the pointers
  <zyga> Wrapping up for now. Time to eat something
  <sil2100> abeato: merged your PR, thanks again! We should have it in edge soonish
  <sil2100> There's still one thing we want to add before we promote this further
  <sil2100> Hopefully having it in edge will be enough for now?
  <abeato> sil2100, awesome, thank you!
  <abeato> sil2100, sure, no hurry for me
  <kenvandine> zyga: sorry, I was out today for a holiday.  I'll catch up with you in the morning
  <jdstrand> joedborg: hey, I just saw this: 16:03 < joedborg> `[285928.025967] audit: type=1400 audit(1570741250.597:1384598): apparmor="DENIED" operation="signal" profile="docker-default" pid=703 comm="kubelet" requested_mask="receive" denied_mask="receive" signal=kill peer="snap.kubernetes-worker.kubelet"`
  <jdstrand> joedborg: kubelet shouldn't be talking to a 'docker-default' profile, it should be talking to the one that containerd sets up
  <jdstrand> joedborg: oh, I read that backward. why is a docker container sending signals to kubelet?
  <ijohnson> jdstrand: joedborg: I don't remember the specifics, but IIRC the child profile (i.e. the container) needs to signal to the parent that it is done, I think that's something runC does
  <ijohnson> also welcome back jdstrand :-)
  <jdstrand> ijohnson: thanks, right, but the kubernetes-worker snap has a containerd with a different profile name than 'docker-default', so I'm confused why a profile named 'docker-default' is in play at all
  <jdstrand> joedborg: eff, I am a little slow today. that denial says that a process running under a 'docker-default' profile name was sent 'kill' by snap.kubernetes-worker.kubelet, and that was blocked because the docker-default profile doesn't allow receiving signals from snap.kubernetes-worker.kubelet
  <jdstrand> erf*
  <jdstrand> joedborg: so, why is kubelet talking to a container running under the 'docker-default' profile? the snap should be configured for it to talk to a containerd profile
  <ijohnson> jdstrand, well regardless of why it's named docker-default, the container is only allowed to transition to a docker-default profile from `docker-support` interface or to the `systemd-run` one from `k8s-support` interface if I'm reading those correctly
  <ijohnson> jdstrand: so if it started running under containerd-default we would have to change the apparmor transition rules wouldn't we?
  <jdstrand> ijohnson: the interfaces were adjusted for this before I left and there were no denials and no docker-default profiles on the system. I'm wondering what has changed. like, did something get dropped from the snap packaging? is the packaging moving to docker instead of containerd? something else?
  <jdstrand> ijohnson: ie:
  <jdstrand> # defaults for containerd
  <jdstrand> change_profile unsafe /** -> cri-containerd.apparmor.d,
  <jdstrand> signal (send) peer=cri-containerd.apparmor.d,
  <jdstrand> ptrace (read, trace) peer=cri-containerd.apparmor.d,
  <jdstrand> ijohnson: it all worked fine. this is for kubelet to *send* signals. the denial is about the container to *receive* them though
  <jdstrand> ijohnson: and there were patches to cri-containerd.apparmor.d in the kubernetes-worker package to allow this
  <jdstrand> (and for said profile to be named 'cri-containerd.apparmor.d', not 'docker-default'
  <jdstrand> )
  <jdstrand> so I'm confused why 'docker-default' is the profile name
  <jdstrand> the snap wasn't changed in 17 days according to github. I need more context from joedborg
   * jdstrand wonders if the control plane has a mix of docker and containerd. that would be weird...
  <joedborg> Hey jdstrand can we pick it up tomorrow please? Iâve got today off.  The eks-support branch in GitHub is up to date but I donât think itâs very relevant
  <jdstrand> joedborg: yes, of course :)
  <jdstrand> joedborg: enjoy the rest of the day :)
  <joedborg> jdstrand: thanks :) I think itâs an issue of stuff in containerd still being constructed by apparmor
  <joedborg> That docker signal may be a red herring
  <joedborg> Constricted *
  <jdstrand> joedborg: well, kubelet shouldn't be sending a signal to anything with a 'docker-default' profile name when containerd is spinning up containers under the cri-containerd.apparmor.d profile
  <jdstrand> joedborg: unless there is an external docker that is spinning up stuff and the CP is telling kubelet to work with that container.
  <jdstrand> there are other things that could be wrong. we can look tomorrow
  <joedborg> jdstrand: yeah you might well be right as itâs a brown field deployment.  Iâll take a look in the AM and circle back.  Hope you had a good vacation btw
  <ijohnson> jdstrand: hmm I guess I never noticed that new containerd transition in docker-support, I only looked at kubernetes-support interface, it's still a bit confusing to me why certain things are in docker-support and not kubernetes-support when the docker snap doesn't use those things
  <ijohnson> jdstrand: anyways, for the docker snap specifically, the docker-default profile isn't persistent, it's just created in /tmp somewhere, loaded into the kernel and then the file is deleted, so it wouldn't show up anywhere in the normal apparmor packaging dirs
  <ijohnson> jdstrand: but anyways anyways I'll let you take care of this, as I haven't actually built this kubernetes snap and am just theorizing about everything
  <jdstrand> joedborg: thanks, it was great
  <jdstrand> ijohnson: yeah, I'm familiar with the way docker does things these days, but 'aa-status' would show it since the profile need to be loaded into the kernel for a process to be running under that profile. thanks
  <ijohnson> yes aa-status would still show it that's correct, I assumed you meant no docker-default profiles on the filesystem, sorry
  <jdstrand> no worries at all :)
  <mup> PR snapd#7597 opened: overlord/snapstate: add LastActiveDisabledServices, ComputeMissingDisabledServices <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7597>
  <mup> PR snapd#7598 opened: test/lib/names.sh: make backslash escaping explicit <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7598>
  #snappy 2019-10-15
  <mup> PR snapd#7598 closed: test/lib/names.sh: make backslash escaping explicit <Simple ð> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7598>
  <mborzecki> morning
  <mvo> mborzecki: good morning
  <mborzecki> yay 7536 landed :P
  <mup> PR snapd#7536 closed: gadget: accept system-seed role and ubuntu-data label <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7536>
  <mborzecki> mvo: thanks!
  <mvo> mborzecki: yes, finally :)
  <mborzecki> i've updated #7593
  <mup> PR #7593: recovery-tool: add sfdisk wrapper <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7593>
  <mborzecki> and there are some comments from zyga too
  <mborzecki> hmm, new kernel, i better reboot
  <mborzecki> brb
  <mborzecki> and back on 5.3.6 kernel
  <mup> PR snapd#7599 opened: gadget: refactor ensureVolumeConsistency <Created by mvo5> <https://github.com/snapcore/snapd/pull/7599>
  <pstolowski> morning
  <mvo> pstolowski: hey, good morning!
  <mborzecki> pstolowski: hey
  <zyga> hello?
  <zyga> is this thing on?
  <zyga> I think I connected now
  <zyga> sorry for starting late, lucy was sleeping hugging me all the time and got grumpy the second I tried to put her to bed
  <mborzecki> zyga: hey
  <zyga> mborzecki: hey, question on how to proceed for you
  <zyga> mborzecki: I removed the guts of snap-update-ns so that I can create other tools with the same logic
  <zyga> mborzecki: I moved it to system/mount for lack of a better name
  <zyga> mborzecki: some bits can go to sandbox/cgroup
  <zyga> mborzecki: but most has no good place to go
  <zyga> mborzecki: ideas?
  <zyga> mborzecki: I'm mainly after plan-writable-mimic and execute-writable-mimic
  <zyga> mborzecki: this pulls in change, assumptions, restrictions and tresspassing
  <zyga> mborzecki: along with loads of tests
  <mborzecki> mvo: i'm looking at 7593, perhaps our consistency checks are too strict, in particular the len(volumes) != 0 only counts when constraints are used, but once there's a system-seed structure defines and SsytemSeed is not true, then we bail out, why not allow this case?
  <mborzecki> zyga: that's part of mount related logic though?
  <mborzecki> zyga: or hmm we call it namespace (or whatnot) often
  <zyga> mborzecki: mainly yes
  <mborzecki> zyga: system/mount/namespace?
  <zyga> mborzecki: I'd go for system/mount really, it would help abbreviate the API names and would look nice
  <zyga> mount.Change
  <zyga> mount.Assumptions
  <zyga> mount.Restrictions
  <zyga> etc
  <mborzecki> system/mounts stgm too
  <zyga> though
  <zyga> my main question is: can we use main :)
  <zyga> er
  <zyga> system/
  <zyga> or is that too vague
  <zyga> I want to have this because otherwise debugging some issues is very hard
  <zyga> and having an interactive tool where you can do stuff is very useful to understand things misbehaving
  <zyga> and sadly it's forbidden to import from "main" packages
  <mborzecki> zyga: hm we have osutil which kind of is system like already, and there's some mount related stuff in there too
  <zyga> mborzecki: yeah but any existing package may trigger import loops
  <mborzecki> zyga: osutil/mount ?
  <zyga> I can tryt
  <zyga> *try
  <zyga> let's see if that works
  <zyga> mborzecki: do you know if go has some rules on what is in a binary
  <zyga> if there's a package foo/bar
  <zyga> and I use only bar.Symbol
  <zyga> does it include all of foo?
  <mborzecki> zyga: no, bar is bar, foor is foo
  <zyga> mborzecki: so foo does _not_ bloat a binary using bar?
  <zyga> mborzecki: and the reverse case?
  <zyga> mborzecki: is presence of foo/bar affecting a binary that only uses symbols from foo?
  <mborzecki> zyga: same, no effect unless you import it, or it's imported internally
  <mborzecki> zyga: or you created an import loop :P
  <zyga> ok, let's give it a try
  <mborzecki> mvo: simply put, if i have a gadget yaml with system-seed and system-data, and use an empty ModelConstraints (just want to have consistency checked), this will error out
  <mvo> mborzecki: I need to look, could you please add a note in the PR? maybe we are too strict .) it seems like the refactor helped to reason about this easier
  <mvo> mborzecki: I'm in the middle of 7593 right now
  <mborzecki> mvo: ah ok, started to play with thhis code too, i'll leave a comment in the PR then
  <mvo> mborzecki: or feel free to propose a pr on top if you feel this should be ok, either way is fine with me :)
  <mvo> ackk: hey, in snapd 2.42 we improved the fuse performance in lxd, I heard maas is using this a lot, did you see improvements?
  <Chipaca> ð
  <zyga> hello Chipaca
  <zyga> mborzecki: the easy branch https://github.com/snapcore/snapd/pull/7600
  <mup> PR #7600: sandbox/cgroup: move freeze/thaw code <Created by zyga> <https://github.com/snapcore/snapd/pull/7600>
  <mup> PR snapd#7600 opened: sandbox/cgroup: move freeze/thaw code <Created by zyga> <https://github.com/snapcore/snapd/pull/7600>
  <Chipaca> pedronis: ð
  <Chipaca> pedronis: did you see my question about the quotes in the repair script?
  <pedronis> yes, but I didn't understand it
  <pedronis> maybe mvo does
  <Chipaca> pedronis: you didn't understand the question, or the origin of the quotes? :)
  <mvo> Chipaca: good morning! I did not see the quotes at all
  <mvo> Chipaca: oh, fun!
  <Chipaca> mvo: snap known --remote repair brand-id=canonical repair-id=1
  <Chipaca> mvo: the script has typographic quotes
  <pedronis> Chipaca: I think it's copying from a gdoc
  <mvo> Chipaca: haha - I see it now
  <Chipaca> mvo: that might be intentional, but I doubt it
  <pedronis> that did that
  <mvo> Chipaca: yeah, it was not
  <Chipaca> yeah, that would do it
  <mvo> Chipaca: we need to improve the way we sign assertions
  <mvo> Chipaca: or let assertion sign :)
  <mvo> Chipaca: THANKS for spotting this
  <Chipaca> it's silly that I worry about this, but I worry because although "echo" doesn't care, there's not a lot more that is as amicable
  <mvo> Chipaca: oh, totally
  <mvo> Chipaca: we need to improve our process here
  <Chipaca> that's all i needed to hear to stop worrying about it :-)
  <mvo> Chipaca: I'm editing a gdoc now so that we don't use gdocs for this :)
  <mborzecki> mvo: added a bunch of comments in #7593, i think some relate to how the seed/recovery is supposed to work, can you take a look and maybe we could discuss that with whoever is interested before/after the standup?
  <mup> PR #7593: recovery-tool: add sfdisk wrapper <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7593>
  <zyga> mborzecki: I'm stuck
  <zyga> mborzecki: the challenge is as follows:
  <zyga> mborzecki: there's lots of tailored mocking going on
  <zyga> mborzecki: in osutil/ snap-update-ns and now in osutil/mount
  <zyga> mborzecki: then there's the general mocking all syscalls that are used in snap-update-ns
  <zyga> mborzecki: if you try to reconcile all of that it's a big mess
  <zyga> mborzecki: thinking about it, I see the following way forward and perhaps out of the problem as well
  <zyga> mborzecki: we can make a new package syscalls/ that has just the system calls and a means to mock them
  <zyga> mborzecki: as things move out of snap-update-ns, they get updated to use this package over the private mocking code used locally
  <zyga> mborzecki: then some parts of snap-update-ns, for example all the mk{dir,file,symlink} and openpath code move to osutil/
  <zyga> (or osutil/mk... if that helps to scope it)
  <zyga> mborzecki: while the real essence of mount, like secure bind mount, mimic logic, can move to osutil/mount
  <zyga> or even osutil/mimic
  <zyga> mborzecki: moving everything in bulk might help in the short term
  <zyga> mborzecki: but won't change how those things are messy internally when considered along with the rest of osutil
  <mborzecki> heh, if you move some of the calls to osutil there's probably going to be some funky import dependencies
  <zyga> mborzecki: there already are, much of the code uses osutil already
  <zyga> mborzecki: how would you feel about the syscalls package?
  <zyga> mborzecki: the public API would be various system calls
  <zyga> mborzecki: and a means to mock them all (e.g. with the recorder already present in another package)
  <mborzecki> zyga: there's stdlib syscalls already, could those wrappers just live in osutil instead?
  <zyga> mborzecki: yes but I'd like them not to
  <zyga> osutils is already kind of large
  <zyga> but most importantly it already has a number of them and some mocking
  <zyga> mborzecki: (mock-this, mock-that, not in general)
  <zyga> mborzecki: the idea is that eventually, over time, code could move to use the new pakcage
  <zyga> and drop its own mocking
  <zyga> mborzecki: this is why I think a new package would help
  <zyga> mborzecki: if we move them over to osutil right now you will see a number of separate mocking systems that need to be reconciled
  <mborzecki> zyga: osutils/syscalls? with a godoc that 'here lie the syscalls we can mock' ? :)
  <zyga> :D
  <zyga> mborzecki: that works for me
  <zyga> mborzecki: importantly, mock in bulk
  <zyga> not one by one
  <Chipaca> mborzecki: osutil/sys
  <Chipaca> ?
  <mborzecki> right, avoids a name clash with stdlib's syscalls
  <ogra> would gadgets on top of debian work or is there any special-casing-code that only allows them on ubuntu classic ?
  <zyga> Chipaca: would you prefer if this was in osutil/sys?
  <zyga> brb
  <Chipaca> zyga: i'm not sure quite what you're asking, but, probably? the difference between osutil/syscall[s] and the existing osutil/sys escapes me
  <pedronis> zyga: what are the changes to snap-update-ns about ?
  <zyga> pedronis: being able to expose the internals for interactive debugging
  <pedronis> zyga: what's the context? are you chasing a bug?
  <zyga> Yes, correct.
  <pedronis> which one?
  <zyga> I did that yesterday and thought that some of those could land
  <zyga> Not all changes are easy though
  <pedronis> zyga: I fear I still don't have enough context, maybe you need to propose the mess as is, and I can look what to do with it
  <pedronis> when I have a bit of time
  <zyga> I think some bits are easier than others but the main value already exists. In a branch I can build mimic-tool to experiment and see where the kernel behavior is coming from
  <pedronis> zyga: still no context
  <zyga> Finishing breakfast, Iâll be back soon
  <mvo> mborzecki: I addressed a bunch of your comments in 7593, I am looking into using "-apend" now
  <mborzecki> mvo:  thanks! btw. that's an interesting find about blockdev
  <mvo> mborzecki: thank you for pointing this out!
  <mvo> mborzecki: blockdev seems to be part of busybox fwiw
  <mborzecki> mvo: ah, that makes sens
  <mvo> mborzecki: also thanks for the comment about -apend, I was wondering about this myself but wasn't aware of -append :)
  <mup> PR snapd#7601 opened: overlord/ifacestate: use SetupMany in setupSecurityByBackend <Created by stolowski> <https://github.com/snapcore/snapd/pull/7601>
  <pedronis> mborzecki: what's the status of #7079, is it being absorbed by the snap-recovery work?
  <mup> PR #7079: [RFC] cmd/snap-image: tool for building UC images <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7079>
  <mborzecki> pedronis: not really, parts of it probably affected snap recovery work, but iirc claudio did not pull in any patches directly
  <pedronis> mvo: are we going to do a 2.42.1 ?  mvo, pstolowski: when should we try to land #7092, it's unblocked now?
  <mup> PR #7092: packaging: use snapd type and snapcraft 3.x <Created by stolowski> <https://github.com/snapcore/snapd/pull/7092>
  <mborzecki> pedronis: though, the sfdisk parts should be consolidated into the gadget package since we alredy have some code there
  <pedronis> mborzecki: it sounds like we would redo it on top of the recovery work at this point, no?
  <pedronis> should it be closed?
  <mborzecki> pedronis: other than that, the tools are run in different environment and differnt part of the cycle
  <mborzecki> pedronis: i can close it for now and we can discuss what to do witht he tool separately
  <pedronis> ok, sounds good
  <pedronis> mborzecki: to be clear, the medium term plan is still for ubuntu-image to be a thin wrapper around snapd code, but I don't we want to land two codebases doing partions into snapd, we probably want to get to one codebase surface maybe in two slightly diffferent ways
  <mup> PR snapd#7079 closed: [RFC] cmd/snap-image: tool for building UC images <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7079>
  <pstolowski> pedronis: yes i think we should land 7092. going to deconflict it
   * Chipaca brb
  <mvo> mborzecki: I think 7593 is good for now, I want to do a followup with some real sfdisk tests but that will probably become quite a bit bigger
  <mborzecki> mvo: do you think it'd make sense to move the code that creates a LaidOutVolume out of sfdisk dump into gadget/partition.go ?
  <mup> PR snapd#7222 closed: tests: show just the last log as part of the debug output when check journal logs <Simple ð> <Created by sergiocazzolato> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7222>
  <pedronis> mvo: mborzecki: volmgr is a strange name, it makes one think LVM
  <ogra> makes me think of androids vold ... :)
  <zyga> Voldmgrd
  <zyga> ;-)
  <ogra> pedronis, do you knwo off the top of your head if it is seamlessly possible to use gadget snaps on debian systems (i.e. to attach to a brand store or add certain interfaces)  or does snapd currently restrict this to ubuntu systems ?
  <mvo> pedronis: we could move it to osutil/fdisk ?
  <mup> PR snapd#7600 closed: sandbox/cgroup: move freeze/thaw code <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7600>
  <pedronis> mvo: probably not osutil given it uses types from gadget
  <pedronis> it could be under gadget
  <mvo> pedronis: good point
  <mvo> pedronis: or just cmd/snap-recovery/fdisk ?
  <pedronis> that's fine too
  <pedronis> mostly against the volume manager terminology
  <mvo> pedronis: cool, I will rename to fdisk for now, I think it will later grow luks and stuff but even that seems to be ok to put under fdisk
  <pedronis> mvo: gadget/partition ?
  <pedronis> (I'm fine with fdisk as well)
  <mvo> pedronis: yeah, partition works for me, shall I keep it under cmd/snap-repair for now or do you prefer gagdet?
  <pedronis> mvo: as your prefer, discuss with mborzecki
  <mvo> pedronis: thanks, will do
  <pstolowski> got ubuntu-core-18-64:tests/core18/snapd-failover failure in one of my PRs: 2019-10-15T10:05:40Z INFO Waiting for restart...
  <pstolowski> error: cannot perform the following tasks:
  <pstolowski> - Mount snap "snapd" (unset) (remove /etc/systemd/system/snap-snapd-x2.mount: no such file or directory)
  <pstolowski> - Automatically connect eligible plugs and slots of snap "snapd" (there was a snapd rollback across the restart)
  <mup> Bug #1835024 changed: Links triggered within most snap apps open in a separate browser session <snapd:Incomplete> <xdg-utils (Ubuntu):New> <https://launchpad.net/bugs/1835024>
  <mup> Bug #1801201 changed: Installed snap icons missing if using pixmap <Snapcraft:New> <snapd:New> <https://launchpad.net/bugs/1801201>
  <mup> Bug #1809729 changed: Removing a snap triggers 'Starting scheduled backup' notification <amd64> <apport-bug> <cosmic> <third-party-packages> <udev> <wayland-session> <snapd:Triaged> <deja-dup (Ubuntu):New> <https://launchpad.net/bugs/1809729>
  <mup> Bug #1773416 changed: Interface from Thunderbird/Firefox to LibreOffice/VLC <snapd-interface> <snapd:Confirmed> <https://launchpad.net/bugs/1773416>
  <mup> Bug #1797745 changed: "ln: failed to create symbolic link" in deepin 15.7 <Snappy:Invalid> <https://launchpad.net/bugs/1797745>
  <zyga> it is frustrating when lxd and snapd use different bug trackers
  <zyga> and that launchpad does not automatically ping-back the other bug when an URL is mentioned.
  <zyga> stgraber: hello, could you kindly look at https://bugs.launchpad.net/snappy/+bug/1773044 and if appropriate, convert it to an LXD bug on github please.
  <mup> Bug #1773044: Can't get snap gui apps (notepadqq and firefox) to run in LXD/LXC container <Snappy:Invalid> <https://launchpad.net/bugs/1773044>
  <mup> Bug #1773044 changed: Can't get snap gui apps (notepadqq and firefox) to run in LXD/LXC container <Snappy:Invalid> <https://launchpad.net/bugs/1773044>
  <stgraber> zyga: doesn't look like a bug, just misconfiguration by the user. I suspect they've bind-mounted the X11 socket which works fine for everything but snaps as snaps need the abstract Unix socket instead
  <mup> Bug #1763071 changed: Error message installing a paid snap as unauthenticated user <snapd:Triaged> <https://launchpad.net/bugs/1763071>
  <mup> Bug #1765979 changed: snap applications icons missing in launcher wayland <wayland> <snapd:Triaged> <https://launchpad.net/bugs/1765979>
  <mup> Bug #1766079 changed: ripgrep installed via snap fail to work in /lib/systemd/system folder <Snappy:Invalid> <https://launchpad.net/bugs/1766079>
  <Eighth_Doctor> zyga: I kind of wish that snapd didn't use launchpad as the bug tracker
  <Chipaca> diddledan: Dear Tea., â¦ ?
  <Eighth_Doctor> it's surprisingly difficult to locate bugs in launchpad
  <zyga> Eighth_Doctor: that makes 1002 of us
  <zyga> Eighth_Doctor: at least we're looking now :)
  <zyga> Eighth_Doctor: progress!
  <Eighth_Doctor> yeah
  <Eighth_Doctor> the only really useful feature of launchpad is multi-tracker aggregation
  <Eighth_Doctor> that's actually a powerful feature if it worked more...
  <mup> Bug #1758465 changed: snapd doesn't upgrade on bionic when a local installed snap mount is failing <snapd:Triaged> <https://launchpad.net/bugs/1758465>
  <diddledan> hmm?
  <Chipaca> diddledan: https://forum.snapcraft.io/t/need-to-add-our-product/13694?u=chipaca
  <diddledan> aha
  <diddledan> yeah, I think they missed an M
  <Eighth_Doctor> zyga: but does this mean I need to clone rhbz bugs to LP to get them fixed? â¹ï¸
  <zyga> Eighth_Doctor: why would you do that?
  <zyga> ah
  <zyga> I see
  <zyga> are you saying that we should look at RHBZ bugs as well?
  <Eighth_Doctor> yes
  <mup> Bug #1750856 changed: snapd on s390x tried to run locationd tests, which does not exist on s390x <britney:Fix Released> <Snappy:Fix Released> <snapd (Ubuntu):In Progress> <snapd (Ubuntu Bionic):In Progress> <https://launchpad.net/bugs/1750856>
  <mup> Bug #1752916 changed: Desktop interface should allow accessing to recent files and xdg dirs <snapd-interface> <snapd:Triaged> <https://launchpad.net/bugs/1752916>
  <Eighth_Doctor> I've been doing some of the triage for a while now, but if there's an actual code problem, it's a bit difficult to escalate because I don't know how to get people's attention on it
  <Chipaca> zyga: we do look at ubuntu/+source/snapd bugs, so why not rhbz bugs?
  <zyga> mvo: could you kindly check if the bionic task of this bug is still valid https://bugs.launchpad.net/snappy/+bug/1750856
  <mup> Bug #1750856: snapd on s390x tried to run locationd tests, which does not exist on s390x <britney:Fix Released> <Snappy:Fix Released> <snapd (Ubuntu):In Progress> <snapd (Ubuntu Bionic):In Progress> <https://launchpad.net/bugs/1750856>
  <zyga> Chipaca: I agree, it's just a matter of manpower and gardening the mess first
  <zyga> Eighth_Doctor: we have a recurring triage work, at some point we'll run out of overflowing NEW bugs and can look at existing bugs
  <zyga> Eighth_Doctor: can you point me to the list of snapd bugs in RH bugzilla please
  <zyga> Eighth_Doctor: I'll add that to our laundry list
  <Eighth_Doctor> http://bugz.fedoraproject.org/snapd
  <Eighth_Doctor> I need to write a script to mass-close all these SELinux bugs
  <diddledan> WONTFIX :-p
  <Eighth_Doctor> I'm pretty sure a large chunk of those are from before the policy rewrite that mborzecki did in May
  <Chipaca> how do we feel about snaps that tell users to do things that could easily trick them to run things unconfined?
  <mup> Bug #1748510 changed: shell's test gives false positive on readability of files <Snappy:Won't Fix> <https://launchpad.net/bugs/1748510>
  <zyga> Chipaca: RUN THIS SNAP WITHOUT PESKY ERRORS WITH THIS ONE TRICK
  <diddledan> Chipaca: that sounds dirty
  <diddledan> zyga: you'll never believe what happens next
  <zyga> diddledan: I know, I know
  <Eighth_Doctor> zyga: protip, all Fedora packages actually have a BugURL property set on them ;)
  <zyga> sudo wget | sh
  <Chipaca> 'loopchain' (brought to my attention by requesting a track) is like this
  <zyga> it's always like tat
  <zyga> *that
  <diddledan> love those instructions appearing everywhere because macOS
  <Eighth_Doctor> `rpm --query --queryformat "%{BUGURL}" snapd`
  <Chipaca> it doesn't seem to be immediately bad, but it makes me feel a little uncomfortable
  <Chipaca> "to install, first snap install this, then apt install rabbitmq, then run thesnap.init, then run the scripts it wrote in $SNAP_COMMON
  <Chipaca> "
  <Eighth_Doctor> zyga: thankfully all these Fedora 29 bugs go away when F29 EOLs next month
   * Chipaca would NOPE out of that really fast, but some users are perseverant... 
  <diddledan> or "run `$(thesnap.init)`
  <mup> Bug #1747200 changed: console conf crashes on dragonboard <subiquity:New> <https://launchpad.net/bugs/1747200>
  <Chipaca> diddledan: sudo $(thesnap.ok)
  <Eighth_Doctor> Chipaca: you didn't think snaps would actually stop people from doing dumb things, did you? ð¶
  <zyga> Eighth_Doctor: that's a bit annoying on the user side but that's very convenient for the developer side :)
  <zyga> diddledan: they will all need to change to curl | zsh
  <Eighth_Doctor> well, it's the only way I maintained my sanity with snapd bugs
  <zyga> and sudo won't help since macos is locked down more than ever now
  <Eighth_Doctor> macOS has become an annoying platform to be a developer on
  <Chipaca> Eighth_Doctor: https://www.youtube.com/watch?v=TL0dfzK3Aqs
  <diddledan> love that song
  <Eighth_Doctor> it's a good song
  <Eighth_Doctor> and very appropriate here
  <Chipaca> BUT THE SUDO COMES AT NIGHT
  <mborzecki> Eighth_Doctor: i'm quite sure there's still a bunch of things popping up when installing snaps :/
  <zyga> is lxd security.nesting enabling nested apparmor?
  <mup> Bug #1744584 changed: Exclude Snap .cache from Dejadup backups <DÃ©jÃ  Dup:Fix Released> <Snappy:Invalid> <deja-dup (Ubuntu):Fix Released> <https://launchpad.net/bugs/1744584>
  <Eighth_Doctor> yeah
  <Eighth_Doctor> it's a lot less nowadays, thankfully
  <Eighth_Doctor> and some of the warnings I don't want to fix
  <mborzecki> Eighth_Doctor: i should try installing some snaps on my wife's lapotp to catch them all :P
  <Eighth_Doctor> there are cases where it's actually bad behavior it's blocking, and I'm okay with the denial status
  <mvo> zyga: sure, done
  <Eighth_Doctor> mborzecki: the issue right now is that Silverblue users are upset that snaps using the "home" perm fail to start because of `/var/home`
  <Eighth_Doctor> there's a symlink for `/home` to `/var/home`, but that isn't enough for snapd, I guess
  <zyga> mvo: thank you
  <zyga> Eighth_Doctor: there's been some patches to make /var/home work already
  <zyga> Eighth_Doctor: though we obviously lack the full test
  <Eighth_Doctor> zyga: oh cool, can I cherry-pick that into 2.42 release for Fedora?
  <zyga> Eighth_Doctor: it's not the full fix yet, just initial patches
  <Eighth_Doctor> I haven't pushed it yet because this bug just came up as I started working on it
  <zyga> Eighth_Doctor: base snaps will have /var/home so we can start binding onto it
  <Eighth_Doctor> ah, I see
  <Eighth_Doctor> we'll need to keep that in mind for fedora base as well
  <mup> Bug #1732494 changed: Impossible to manage package after Trusty --> Xenial upgrade <apport-bug> <i386> <third-party-packages> <xenial> <snapd:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1732494>
  <zyga> mvo: do you have access to launchpad.net/snapd project description?
  <zyga> mvo: it would be good to change the first line
  <zyga> mvo: now it reads "code hosted at URL"
  <zyga> mvo: but if you re-assign bugs between projects all you get is "code hosted at" period
  <zyga> mvo: we could change it to say something nice, like "snapd is the best way to manage snap packages" :)
  <mvo> zyga: updted
  <zyga> mvo: super, thank you
  <zyga> can you edit again to replace the word "snap ..." with snaps
  <zyga> the message gets cut off at "snap"
  <mup> Bug #1647333 changed: adduser misses extrausers support for group management <patch> <snapd:New> <adduser (Ubuntu):Confirmed> <shadow (Ubuntu):In Progress by ogra> <https://launchpad.net/bugs/1647333>
  <zyga> sorry :)
  <mvo> zyga: done
  <zyga> haha, now it says: the best way to manage snaps. Code\n
  <zyga> and that's all :D
  <zyga> oh well, it's good enough
  <ogra> "a good enough way to manage snaps" ?
  <mup> Bug #1662452 changed: snap install squid-gary failed on Ubuntu Core <snapd:Invalid> <https://launchpad.net/bugs/1662452>
   * Chipaca breaks all the tests again
  <zyga> where are ubuntu-image bugs reported?
  <zyga> ogra: "a good enough way to"
  <zyga> mborzecki: do you know? ^
  <mborzecki> zyga: lp? or github project maybe
  <Chipaca> zyga: snaps@canonical.com ?
  <mborzecki> zyga: https://github.com/CanonicalLtd/ubuntu-image/ ?
  <zyga> thanks
  <Chipaca> popey: does email to that address reach you?
  <Chipaca> or who?
  <mborzecki> zyga: https://launchpad.net/ubuntu-image apaprently
  <zyga> wait
  <zyga> no issues there
  <popey> Chipaca: no, mvo
  <zyga> oh the horror
  <zyga> thanks
  <mborzecki> zyga: yeah, there's this message that points to LP
  <Chipaca> zyga: it has no bugs! \o/
  <zyga> Chipaca: I wish it was easier to find :)
  <mborzecki> Chipaca: no reported bugs :P
  <zyga> Chipaca: ship it!
   * Chipaca ships everyone with everyone
  <popey> Chipaca: i lamented this back in malta
  <zyga> Chipaca: do you remember when I first wanted to join the team
  <zyga> Chipaca: I was supposed to create ubuntu-image
  <zyga> Chipaca: and maybe help with "resources" aka "capabilities" aka "skills"
  <Chipaca> zyga: my memory is a two-week round-robin database
  <zyga> Chipaca: what?
  <zyga> ;-)
  <mborzecki> Chipaca: journalctl --vacuum-time=2w ? :P
  <zyga> <gif of hampster on a treadmill>
  <mup> Bug #1649839 changed: unknown snap and snapd version when image created via ubuntu-image <Ubuntu Image:New> <https://launchpad.net/bugs/1649839>
  <mup> Bug #1655060 changed: snapcraft doesn't support the dbus daemon type <Snapcraft:New> <snapd:New> <https://launchpad.net/bugs/1655060>
  <Chipaca> actually it's more like rrdtool but close enough
  <Chipaca> popey: was your lament about the fact that the email is there, or that it only goes to the m of the v.o.?
  <popey> both
  <popey> it should go to a project github page, or home page
  <popey> see lxd for the pinnacle of snapcraft store pages
  <mup> Bug #1655593 changed: chattr code (tests/main/chattr/task.yaml) fails on ppc64el <snapd:Triaged> <https://launchpad.net/bugs/1655593>
  <mup> Bug #1659523 changed: console-conf doesn't work well if using screen on Mac <subiquity:New for wangliming> <https://launchpad.net/bugs/1659523>
  <zyga> mvo: can we put the snapcraft logo on snapd?
  <Chipaca> mvo: WDYT about having snaps@c.c also go to advocacy?
  <diddledan> zyga: that's far too sensible
  <Chipaca> mvo: and, WDYT about pointing ubuntu-image's contact to something better than an email address?
  <Chipaca> zyga: the snapcraft logo but in asciiart
  <zyga> Chipaca: in black and white
  <zyga> maybe that's too sad though
  <Chipaca> we have one of those
  <Chipaca> nah, sad is grey on grey
  <Chipaca> or is that depression
  <cachio> mborzecki, hey
  <mup> Bug #1679739 changed: System-User Assertions and the system time <snapd:New> <https://launchpad.net/bugs/1679739>
  <mup> Bug #1683823 changed: snapstore returns multiple instances of the same publication (was snapcraft list-revisions showing multiple publications in the same channel) <apw-snappy> <Snapcraft:New> <https://launchpad.net/bugs/1683823>
  <cachio> mborzecki, I m with the #7551
  <mup> PR #7551: tests: fix the how the systemd-journald.service is restarted during the prepare <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7551>
  <ogra> Chipaca, isnt u-image foundations child now ?
  <Chipaca> ogra: je ne sais pas, je ne sais plus, je suis perdu, etc
  <zyga> pedronis: something for your awareness: https://bugs.launchpad.net/snapd/+bug/1679739 -- perhaps assertions should be loaded and only re-validated (and actually take effect) once we have system time synchronized
  <mup> Bug #1679739: System-User Assertions and the system time <snapd:Triaged> <https://launchpad.net/bugs/1679739>
  <mborzecki> cachio: do you have more details about those journal failures?
  <cachio> mborzecki, yes
  <mborzecki> cachio: i have a hunch that it's the stop that fails
  <cachio> mborzecki, basically what happens with restart
  <cachio> is that it stops
  <cachio> but sometimes it makes a flush
  <cachio> during stop
  <cachio> and while it is flushing
  <mup> Bug #1679210 changed: snap install --revision tracks stable by default <snapd:New> <https://launchpad.net/bugs/1679210>
  <cachio> it tries to start
  <cachio> and it can't
  <mborzecki> yeah, probably when there's a lot of data bc snapd is chatty with debugs enabled
  <cachio> so retries many times until it reaches the starts limit
  <mborzecki> cachio: w8, so it didn't stop, is still flushing and nother journald instance starts up?
  <cachio> and fails
  <cachio> mborzecki, it doesn't finish the stop and it is trying to start
  <mborzecki> wow
  <cachio> mborzecki, if you see the log there, the error is Active: failed (Result: start-limit-hit) since Thu 2019-10-03
  <cachio> mborzecki, it is just happening on core18 and sometimes on core16
  <cachio> I could not reproduce is on classic
  <cachio> mborzecki, I am creating a debug session now
  <zyga> what on earth is "ubuntu-snappy" source package
  <cjwatson> Old name for the snapd source package
  <zyga> ah
  <mup> Bug #1657552 changed: [spread] install-sideload:reexec0 failure <Snappy:Won't Fix> <https://launchpad.net/bugs/1657552>
  <mup> Bug #1662772 changed: systemd[1]: Failed to start Set the hostname to the value stored on the writable partition <snappy-set-hostname.service> <Snappy:Won't Fix> <https://launchpad.net/bugs/1662772>
  <ogra> zyga, dont kill it in case you want to go back to a python based snapd :P
  <zyga> ogra: maybe one day we can snap install snapd0 ;)
  <ogra> haha
  <mup> Bug #1684343 changed: For candicate release is appearing on dragonboard the message "ERROR hal_remove_bsskey response failed err" <subiquity:New> <https://launchpad.net/bugs/1684343>
  <mup> Bug #1671778 changed: failover:emptysystemd test fails <Snappy:Won't Fix> <https://launchpad.net/bugs/1671778>
  <mup> Bug #1679432 changed: Bluetooth SCO connections don't work on Dragonboard 410c <Snappy:Invalid> <https://launchpad.net/bugs/1679432>
  <mup> Bug #1679747 changed: Cannot send bluetooth SCO packets with Raspberry Pi 3 internal bluetooth module. <Snappy:Invalid> <https://launchpad.net/bugs/1679747>
   * pstolowski lunch
  <mup> Bug #1666690 changed: Dependency issues when sharing a library through content interface <personal> <Canonical System Image:New> <snapd:New> <https://launchpad.net/bugs/1666690>
  <mup> Bug #1705985 changed: snaps fail to install on juju1 deployed lxc container <canonical-bootstack> <snapd:Incomplete> <https://launchpad.net/bugs/1705985>
  <zyga> kenvandine: hello, could you please enqueue this bug report https://bugs.launchpad.net/snapd/+bug/1661626 -- there's some things related to gsettings and dbus signal for notification on changes. I could use some help in understanding how the desktop stack works in this area.
  <mup> Bug #1661626: GSettings/dconf reports incorrect values on setting change under confinement <desktop> <snapd:Triaged> <https://launchpad.net/bugs/1661626>
  <mup> Bug #1661626 changed: GSettings/dconf reports incorrect values on setting change under confinement <desktop> <snapd:Triaged> <https://launchpad.net/bugs/1661626>
  <mup> Bug #1662962 changed: 'snap find' does not allow channel specification <snapd:Triaged> <https://launchpad.net/bugs/1662962>
  <mup> Bug #1665683 changed: Strictly confined snapped desktop applications can't toggle Launch at Login <isv> <snapd:Fix Released> <https://launchpad.net/bugs/1665683>
  <mup> Bug #1689302 changed: Can't set program_usb_boot_mode pi-config option <ce> <snapd:Confirmed> <https://launchpad.net/bugs/1689302>
  <zyga> sil2100: could you please enqueue this bug to your list https://bugs.launchpad.net/snappy/+bug/1740655 -- I'm not sure what to do about it
  <mup> Bug #1740655: Using dtoverlay=pi3-disable-bt to disable Bluetooth results in unbootable system <Snappy:Triaged> <https://launchpad.net/bugs/1740655>
   * Chipaca stands up
  <ijohnson> morning folks, I think that https://github.com/snapcore/snapd/pull/7431 is basically ready, if folks want to take a really quick look and see if there's anything obvious that I could split out into different smaller PRs that would be great
  <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>
  <mup> PR snapd#7602 opened: overlord/many: extend check snap callback to take snap container <Remodel :train:> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7602>
  <kenvandine> hey zyga
  <zyga> hey
  <zyga> how are you? :)
  <kenvandine> i'll look at it
  <mborzecki> weird failure with current master https://paste.ubuntu.com/p/8P6hYK5PcJ/
  <kenvandine> good, recovering from a long weekend :)
  <zyga> kenvandine: thank you, it's not urgent, just something that came out of our bug gardening
  <zyga> mborzecki: two comments
  <zyga> mborzecki: how big is that deb?!?!
  <zyga> mborzecki: and maybe systemd became a virtual package somehow?
  <mborzecki> zyga: idk
  <zyga> cachio: can you please look at https://bugs.launchpad.net/snapd/+bug/1847665 -- it seems one snap that we get from the store is not published for i386 - perhaps we need to nuke the test or perhaps we need to publish the test snap but it looks like it should work (the test snap name is multi-arch)
  <mup> Bug #1847665: snapd autopkgtest fails on i386 <snapd:Triaged> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1847665>
  <zyga> cc mvo ^ not sure who has access to those
  <kenvandine> marcustomlinson: can you look at bug 1661626 ?
  <mup> Bug #1661626: GSettings/dconf reports incorrect values on setting change under confinement <desktop> <snapd:Triaged> <https://launchpad.net/bugs/1661626>
  <zyga> mvo: can you please look at https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1844498 -- you were participating in the discussion there and I'm not sure if the snapd package task is something that is still accurate - should it change to triaged or invalid?
  <mup> Bug #1844498: 18.10+ cloud images have the LXD group as gid 1000 <id-5d84bb1ca26b0679a708dc40> <cloud-images:New> <cloud-init (Ubuntu):Invalid> <livecd-rootfs (Ubuntu):Fix Released by mwhudson> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1844498>
  <marcustomlinson> kenvandine: ok
  <kenvandine> marcustomlinson: thanks
  <sil2100> zyga: yes, something related to it is actually in the works
  <jdstrand> pedronis: hey, would you mind giving me an updated list of pulseaudio.snap-ids? if you don't have time, perhaps describe the query to roadmr (or me and I can find someone if he can't do it)?
  <zyga> sil2100: excellent, thank you
  <sil2100> zyga: so how it's most probably going to be resolved is for us shipping two different image flavors - one with bluetooth enabled, one with disabled
  <sil2100> Since from what I've been told on most pi's you can't actually have both serial and bluetooth enabled at the same time
  <zyga> sil2100: you can, it's just shifting the serial around to other pins
  <jdstrand> pedronis: I don't need it *immediately* since I can look in the snap usns dump and continue working, but I want to make sure I didn't miss any new ones
  <zyga> sil2100: AFAIK
  <zyga> jdstrand: hey :)
  <zyga> jdstrand: welcome back
  <sil2100> zyga: I'm not a pi expert so I can't really say, waveform would have more info about that
  <sil2100> ;)
  <jdstrand> pedronis: plan is, get through all current ones, propose a pr to manually connect, then right before 2.43 lands, do one more query and fill in any more
  <zyga> cool, I'm sure he knows more than I do
  <jdstrand> hey zyga, thanks! :)
  <zyga> just happy to see progress
  <pedronis> jdstrand: I can try to look tomorrow morning
  <cachio> zyga, I'll take a look
  <jdstrand> pedronis: thanks
  <zyga> cachio: thanks!
  <zyga> Chipaca: something that feels like a papercut and I agree with the reporter
  <zyga> https://bugs.launchpad.net/snapd/+bug/1830183
  <zyga> Chipaca: related to how we log
  <mup> Bug #1830183: Absence of updates is labelled a critical error in syslog <snapd:Triaged> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1830183>
  <Chipaca> zyga: papercut, indeed
  <zyga> Chipaca: though not sure how to technically solve it
  <Chipaca> easily :-)
  <zyga> Chipaca: maybe we should talk to journald natively so that we can send those nice log properties
  <Chipaca> whoa
  <Chipaca> zyga: maybe, possibly, if there's a reasonable library for it, but that's not this bug
  <mup> PR snapd#7603 opened: dpdk and hugepages interfaces <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/7603>
  <Chipaca> this bug is just "don't log no-refreshes-available with INFO" probably :)
  <Chipaca> zyga: that's what makes it papercut
  <zyga> Chipaca: IIRC the format is simple so it's just about formatting the error "text" correctly, I think we'd prefer to carry that code instead of depending on it
  <zyga> Chipaca: yeah :)
  <zyga> Chipaca: (and talking over the right FD)
  <Chipaca> yeah, and keeping up with changes, and and and
  <roadmr> mvo: are you around?
  <mvo> roadmr: yes
  <zyga> Chipaca: no, it's not like that actually
  <zyga> Chipaca: http://0pointer.de/blog/projects/journal-submit.html
  <Chipaca> zyga: are you really advocating for NIH'ing a systemd library
  <zyga> Chipaca: not a systemd library, a public protocol
  <pstolowski> i got lxd spread test failure again on 18.04, fails with "snapd : Depends: systemd but it is not going to be installed", has anyone seen this? 18.04 image needs updating?
  <zyga> pstolowski: maciek did IIRC
  <zyga> maybe apt database is empty?
  <zyga> pstolowski: this is interesting
  <zyga> https://errors.ubuntu.com/problem/5e58e04cdc647a1fd50f71f02724dd0b5b8c1f4b
  <zyga> pstolowski: udev netlink hotplug panic
  <zyga> the bug behind it is https://bugs.launchpad.net/snapd/+bug/1824162
  <mup> Bug #1824162: /usr/lib/snapd/snapd:11:runtime:runtime:runtime:runtime:runtime <artful> <bionic> <cosmic> <xenial> <zesty> <snapd:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1824162>
  <zyga> can you please enqueue looking at it
  <zyga> mvo: can I close https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1824237 now?
  <mup> Bug #1824237: snap 'core' broken/missing and causing autopkgtest failures <snapd:In Progress by zyga> <snapd (Ubuntu):New> <snapd (Ubuntu Cosmic):New> <https://launchpad.net/bugs/1824237>
  <mvo> zyga: yes, all autopkgtest related bugs can be closed
  <zyga> mvo: _all_? I found one that looks like a real bug
   * zyga is done with triage for the day
   * zyga -> break / food
  <cachio> zyga, I dont have test-snapd-hello-multi-arch under my control
  <zyga> cachio: it probably belongs to mvo
  <cachio> zyga, not sure who created this one
  <zyga> someone from the store can probably help you move it?
  <pstolowski> zyga: hmm, i think i see where the problem is on the very high level.. go routine running in the background. will check, thanks for pointing out
  <zyga> roadmr: ^ test-snapd-hello-multi-arch, do you know who is in the collaborators?
  <roadmr> I can check
  <zyga> pstolowski, roadmr: cool, thank you for looking
  <zyga> (one messgage, two topics, take that tracking AI overloards)
  <roadmr> zyga: nobody ð¦
  <zyga> oh crab :D
  <zyga> roadmr: can you please give it to cachio and mvo perhaps, following all protocol
  <roadmr> zyga: the current owner (the "canonical" account, not sure if this is mvo?) has to add collaborators. I can't do it administratively :(
  <zyga> I see
  <zyga> is there an email address?
  <zyga> mvo: are _you_ secretly all of canonical? :D
  <ijohnson> does anybody have an example of scanning journald in spread tests for something specific in the logs? is there a helper for "discard everything in the log from x point later on" to just check something in the logs happened after a certain point?
  <zyga> ijohnson: plenty
  <zyga> we nuke the journal between tests
  <zyga> so anything that uses 'journal' helper functions is likely a candidate
  <ijohnson> right but which journal helper there are several
  <zyga> I can find a specific example but the main principle applies
  <zyga> yeah
  <zyga> but they all do the same thing
  <zyga> with various quirks on how
  <zyga> I agree that multitude of functions is confusing
  <ijohnson> all I need to do is check for a certain message in the log happening after a certain line in the test
  <ijohnson> thanks btw!
  <zyga> I think this is a buggy area
  <zyga> and the helper that we use most often has some loops inside
  <zyga> some journal versions have a marker concept
  <zyga> so you can cat the whole log since a marker was emitted
  <zyga> then grep that
   * zyga needs to break for some back pain relief
  <ijohnson> that feels like the right thing, do you have an example I can look at zyga?
  <ijohnson> or maybe cachio knows
  <zyga> ijohnson: sorry, leaving now
  <zyga> I can later
  <zyga> if you don't get it before
  <ijohnson> zyga: np get better I can figure it out
  <cachio> ijohnson, what we do in some scenarios
  <cachio> is to count the number of ocurrencies before and after
  <cachio> and compare the number is iscreased
  <zyga> ijohnson: just ward of caution, it's all good except on 14.04 :D
  <zyga> *word
  <cachio> ijohnson, take a look to test catalog-update
  <ijohnson> trusty seems not so trustworthy anymore with respect to features :-/
  <cachio> perhaps it could help
  <ijohnson> cachio, thanks looking
  <ijohnson> cachio: that looks like the easiest way to check this, thanks
  <cachio> ijohnson, yaw
   * Chipaca takes a break
  <mvo> I saw some failures in current PRs related to the lxd test, looks like systemd was not installable in there, anyone know more ?
  <pedronis> mvo: what's the public interface of 7593 ? most things seem unexported
  <pedronis> you create a SFDisk manually?
  <pedronis> mvo: I put some questions there
   * cachio lunch
  <mvo> pedronis: public interface is just partition.NewSFdisk() and you go from there, two exported methods on it, DeviceInfo and CreatePartitions
  <mvo> pedronis: I will check in the PR
  <pedronis> mvo: that new is private atm
  <pedronis> anyway see comments
  <mvo> pedronis: yeah, everything is spot on - I think we don't really need the interface, *might* be handy for tests later, I check the full branch from claudio - but we can always add it back once we need it so I'm +1 to remove it
  <pedronis> ok
  <thresh> what does "grandfathering" mean in context of https://forum.snapcraft.io/t/upcoming-pulseaudio-interface-deprecation/13418 ?
  <mup> PR snapd#7604 opened: many:  address issues related to explicit/implicit channels for image building <Created by pedronis> <https://github.com/snapcore/snapd/pull/7604>
  <pedronis> Chipaca: mvo: ^
  <pedronis> thresh: that a declaration will be setup in the store to keep them working (for now at least) with pulseaudio as they did so far
  <thresh> pedronis, good, thank you!
  <thresh> (i suck at idioms)
  <mvo> thanks pedronis
  <pstolowski> zyga: i think i found the bug in the upstream go-udev code that causes the crash
  <pstolowski> commented on the bug
  <mup> PR snapd#7605 opened: tests: configure the journald service for core systems <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7605>
  <mup> PR snapd#7551 closed: tests: fix the how the systemd-journald.service is restarted during the prepare <Simple ð> <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7551>
  <zyga> pstolowski|afk: woot, great
  <zyga> makes bug gardening worthwhile :)
  <pstolowski|afk> yes :)
  <pstolowski|afk> slightly terrible we had this bug for a while
  <mvo> cachio: can you please have an eye on master in travis? I just noticed some failures in recent PRs related to lxd. would be great if we can get master green again (if its something real and not just transient)
  <mvo> pedronis: I updated the sfdisk PR now and addressed your points
   * ogra notes pstolowski|afk must have looong arms
  <jdstrand> Chipaca: hey, you gave me a cool command for downloading the snap.yaml (with caveats) of a snap in the public store. do you happen to know a command otoh to get the snap decl for a given snap name?
  <jdstrand> Chipaca: snap download would do it, but I don't want the snap, just the decl (I'll be doing hundreds of downloads)
   * jdstrand looks at 'snap download'
  <pstolowski|afk> ogra: now you know ;)
  <pedronis> jdstrand: which revisions do you need ?
  <jdstrand> pedronis: the latest
  <jdstrand> pedronis: well, I just need the snap decl, which is shared across revisions
  <pedronis> jdstrand: ? do you nee the snap.yaml or the snap decl?
  <pedronis> not the same thing
  <jdstrand> pedronis: the snap decl
  <pedronis> jdstrand: do you have the snap name or the snap id ?
  <jdstrand> pedronis: both
  <pedronis> jdstrand: something like: snap known --remote snap-declaration series=16 snap-id=KTe2wdAu5JKdRDUgYBuXXGjDXyzobvFI
  <jdstrand> pedronis: that is perfect, thanks! (cc Chipaca)
  <mup> PR snapd#7606 opened: tests: run apt update in lxd containers <Created by mvo5> <https://github.com/snapcore/snapd/pull/7606>
  <ijohnson> cachio: have you been able to figure out the issue with the lxd tests? I see it keeps failing consistently, and mvo's patch apt update still failed
  <ijohnson> err, mvo's patch to call apt update before doing the install of snapd in the container still fails (see #7606)
  <mup> PR #7606: tests: run apt update in lxd containers <Created by mvo5> <https://github.com/snapcore/snapd/pull/7606>
  <cachio>  ijohnson working on that
  <ijohnson> ack ok
  <cachio> ijohnson, I just finished a task and started with that one
  <cachio> ijohnson, currently debugging
  <ijohnson> cachio: I looked into it a little bit but didn't find anything if you weren't looking into it I was going to, but if you're on top of I'll work on other things
  <cachio> ijohnson, I'll try to fix it
  <cachio> otherwise I'll ping you in case I need help
  <joedborg> jdstrand: will you have some free time this PM?
  <ijohnson> cachio: ack sounds good
  <jdstrand> joedborg: if by 'this PM' you mean now, sure :)
  <jdstrand> zyga: hey, it looks like solus is still at 2.39.3 and parrot os at 2.37. curious when you think they'll get updated to 2.41+
  <jdstrand> popey, Wimpress: hey, can one of you talk to electron about https://github.com/electron-userland/electron-builder/issues/4234?
  <joedborg> jdstrand: excellent.  Very basically, I'm still seeing times where containers are getting filesystem permission denied
  <jdstrand> joedborg: what are the denials? shall I login somewhere?
  <joedborg> jdstrand: let me copy your ssh keys
  <joedborg> jdstrand: ubuntu@34.201.205.205
  <jdstrand> I'm in
  <joedborg> jdstrand: we can move this to 1:1 if we're worried about spamming.  Basically, this is an EKS node where I've ripped out the EKS provisioned kubelet and stopped docker, replacing it with our snap
  <jdstrand> ok. yes, let's privmsg since this isn't interesting to others
  <joedborg> jdstrand: the only pod that's having a problem is the aws-node pod, which tried to create `/host` in its namespace
  <mup> PR snapd#7607 opened: tests: taunch the lxd images folowing the pattern ubuntu:${VERSION_ID} <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7607>
  <cachio> ijohnson, if you want to take a look, there is a PR to fix the lxd issue
  <cachio> #pull
  <cachio> #7607
  <mup> PR #7607: tests: taunch the lxd images folowing the pattern ubuntu:${VERSION_ID} <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7607>
  <jdstrand> joedborg: I privmsg'd you
  <jdstrand> ijohnson: hi!
  <ijohnson> jdstrand: hey
  <jdstrand> ijohnson: joedborg and I are looking at a denial when running kubernetes-worker under strict mode on EKS
  <ijohnson> ok
  <jdstrand> Oct 15 20:31:57 ip-192-168-91-85 audit[21757]: AVC apparmor="DENIED" operation="exec" profile="snap.kubernetes-worker.containerd" name="/app/install-aws.sh" pid=21757 comm="sh" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
  <jdstrand> ijohnson: containerd is triying to run /app/install-aws.sh which corresponds to https://github.com/aws/amazon-vpc-cni-k8s/blob/master/scripts/install-aws.sh
  <jdstrand> ijohnson: the fact that it is at /app (and later /host) means we can't use a layout
  <ijohnson> right
  <jdstrand> ijohnson: and I thought I remembered you facing similar issues with greengrass
  <ijohnson> yeah so first I'll say what we did for the docker snap is that we patched dockerd (in your case probably containerd) to not run pivot_root and instead just do a chroot
  <joedborg> ijohnson: this is what we were talking about with perhaps needing to patch containerd's app armor template
  <joedborg> :)
  <ijohnson> joedborg: jdstrand: is there a reason why you need to do pivot_root?
   * ijohnson goes and finds the dockerd patches
  <jdstrand> ijohnson: I don't know what is doing a pivot_root
  <jdstrand> joedborg: ^
  <ijohnson> jdstrand: when the container is launched, it's rootfs is actually somewhere writable like `/var/snap/.../storage-drivers/....`
  <jdstrand> joedborg: is this a pivot_root or does EKS actually ship /app and /host?
  <ijohnson> jdstrand: and to start the container containerd/dockerd will do a pivot_root into that storage-driver dir
  <joedborg> jdstrand: that's what containerd does when the kubelet asks it to run a workload
  <ijohnson> this is all behind the scense
  <jdstrand> ijohnson: I should also reiterate this is classic, not core
  <ijohnson> *scenes
  <ijohnson> jdstrand: same problem on core as classic though
  <jdstrand> ah ok
  <jdstrand> so, in theory, container do could mv /var/snap/.../storage-drivers/..../app, then symlink from /var/snap/.../storage-drivers/..../app to /var/snap/.../storage-drivers/..../somewhere/deeper/app
  <ijohnson> anyways the issue that happened with the docker snap is that if dockerd ran pivot_root then all of the container fs accesses that the container thought were at `/app/...` were really actually at `/var/snap/.../storage-driver/some-big-uuid/app`
  <ijohnson> but how we solved that was do instead just not do a pivot_root and instead just do a chroot
  <jdstrand> ijohnson: right, makes sense
  <ijohnson> then apparmor doesn't see the container processes as accessing /app it sees /var/snap/.../app
  <jdstrand> ijohnson: is the chroot a configurable thing?
  <ijohnson> no :-(
  <jdstrand> ijohnson: yep
  <ijohnson> hence why we had to patch it
  <ijohnson> here's the patch we did: https://git.launchpad.net/~docker/+git/snap/tree/dockerd-patches/snappy-real-chroot.patch
  <jdstrand> ijohnson: ah, so you patched docker to do that
  <ijohnson> I'm trying to find where in containerd you would do the same patch
  <jdstrand> ijohnson: cool, thanks!
  <ijohnson> it might be in runc actually, it's been a while since I've looked at thsi stuff
  <joedborg> ijohnson: jdstrand: just as a (probably stupid) question, is there no way for apparmor to know that a process is being containerised and to  apply different rules?
  <joedborg> ijohnson: yeah it'll almost certainly be runc
  <ijohnson> well for dockerd it is in fact in github.com/moby/moby aka "real dockerd"
  <ijohnson> but there has to be an equivalent thing in runc/containerd
  <jdstrand> joedborg: re apparmor: apparmor absolutely knows stuff, but containerd/runc is doing things to complicate things
  <jdstrand> joedborg: ie, it is containerdc/runc that is putting the container into the cri-containerd.apparmor.d
  <ijohnson> joedborg: do you know offhand if containerd just runs the `runc` binary directly? or does it use the opencontainers go library ?
  <joedborg> jdstrand: ah i mean can't apparmor be told "this proc is being called by containerd so should be allowed free range of the FS"?
  <jdstrand> joedborg: and that profile is what your snap is loading
  <joedborg> ijohnson: almost certain that it calls the binary
  <ijohnson> jdstrand: but for that specific denial you showed me with /app that's for a snap ?
  <ijohnson> joedborg: ack thanks
  <joedborg> because the runtime binaries are dropped in via config
  <jdstrand> joedborg: so you can put whatever is needed for the container. *but* this denial is not for the container, but for containerd, and its doing something post pivot_root(). depending on your pov, apparmor doesn't handle pivot_root well
  <joedborg> jdstrand: yeah, i guess that was me question; can't it handle pivot root like it does chroot
  <ijohnson> yeah I can see apparmor's pivot_root handling being a bug right now but being a savior in other cirumstances so yeah ... I dunno
  <jdstrand> joedborg: it cannot
  <jdstrand> ijohnson: we have an upstream bug on it
   * jdstrand is trying to find it
  <ijohnson> I think I've seen the bug before
  <jdstrand> ijohnson: iirc, I think we want full mediation of the whole path with something like an alias mechanism to make it convenient and flexible
  <ijohnson> yeah that sounds right
  <ijohnson> I haven't been able to find the bit in containerd you need to patch, but I have to EOD now, I will resume looking tomorrow, if you can't wait, I found that there's already an option to specify disabling pivot_root when creating a container, referenced in the oci options
  <ijohnson> i.e. https://github.com/containerd/containerd/blob/master/runtime/v2/runc/options/oci.pb.go#L27-L28
  <ijohnson> I'm not sure how to use that, but that might avoid needing to patch things
  <jdstrand> this is the bug: https://bugs.launchpad.net/apparmor/+bug/1791711
  <ijohnson> anyways good luck, I will resume looking tomorrow to try and find the stuff y'all need
  <mup> Bug #1791711: path-based AppArmor controls for snap-confine are ineffective due to pivot_root <AppArmor:Confirmed> <https://launchpad.net/bugs/1791711>
  <jdstrand> I thought there was another one
  <jdstrand> but that is what we reference in the snapd sources too
  <joedborg> thakns ijohnson, i'll ask on their slack
  <joedborg> have a good evenign
  <ijohnson> thanks you too
  <jdstrand> ijohnson: big thanks!
  <jdstrand> joedborg: ok, so with the plugs changes we discussed and this, I think we are set for the moment
  <joedborg> jdstrand: yeah, thanks for pointing out the k8s-support needing to be with containerd too, i'll test that tongiht
  <Chipaca> yusss
  <Chipaca> got a PR this PM as promised \o/
  <mup> PR snapd#7608 opened: o/snapstate, etc: SnapState.Channel -> TrackingChannel, and a setter <Created by chipaca> <https://github.com/snapcore/snapd/pull/7608>
   * Chipaca had *more than half an hour* to spare before it was no longer technically PM
   * Chipaca now goes to wash the dishes
  #snappy 2019-10-16
  <mup> PR snapd#7607 closed: tests: launch the lxd images folowing the pattern ubuntu:${VERSION_ID} <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7607>
  <mborzecki> morning
  <mvo> hey mborzecki
  <mborzecki> mvo: how are the tests today? i'm seeing quite a lot of red
  <mborzecki> uhh lxd-nofuse/lxd-snapfuse
  <mvo> mborzecki: yeah, cachio debugged/fixed this one
  <mvo> mborzecki: mergering master should help :)
  <mborzecki> ah, great
  <zyga> o/
  <zyga> good morning
  <zyga> I'll grab some breakfast
  <mvo> zyga: good morning
  <mborzecki> zyga:  hey
  <zyga> o/
  <mborzecki> mvo:  can tou take a look at https://github.com/snapcore/snapd/pull/7605 ? i think i'm missing something, /etc/systemd as a whole is listed in writable, shouldn't mkdir /etc/systemd/journal.conf.d succeed then?
  <mup> PR #7605: tests: configure the journald service for core systems <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7605>
  <zyga> mborzecki: are you sure /etc/systemd is writable? can you provide a reference?
  <mborzecki> zyga: ahh damn, looking at the wrong tab
  <mborzecki> zyga: it's writable on core18, on core there's individual directories under /etc/systemd
  <zyga> that's how I remember it
  <zyga> yeah, it's complex :/
  <mvo> mborzecki: sure, looking
  <mborzecki> mvo: nvm, mystery solved :P
  <mvo> mborzecki: but iirc on core16 not all of it is writable just selected parts
  <mborzecki> mvo: right, i have writable-paths from both open and was looking at the other tab :P
  <zyga> mborzecki: I wonder if xnox experiment to use systemd in initrd works out
   * mvo nods
  <zyga> I'll get to https://github.com/snapcore/snapd/pull/7547 now
  <mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
  <mborzecki> zyga: can you take a look at https://github.com/snapcore/snapd/pull/7602 ?
  <mup> PR #7602: overlord/many: extend check snap callback to take snap container <Remodel :train:> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7602>
  <mvo> zyga: 1825298 is interessting
  <mvo> dear launchpad, please stop timing out on me when I try to do bugtriage, love michael
   * mvo stops bug triage
  <zyga> mvo: looking now
  <zyga> mvo: oh boy
  <zyga> mvo: how do we leave this misery
  <mvo> zyga: thats a tricky one :(
  <mvo> zyga: also super annoying :(
  <zyga> mvo: one way out would be to stop using /etc for apparmor profiles we use
  <zyga> this would involve shipping empty replacements that do NOP
  <zyga> and shipping files in /var forever
  <mvo> zyga: does apparmor support /var ?
  <zyga> mvo: ubuntu's apparmor does, that's how our profiles work
  <zyga> mvo: other distributions don't until apparmor 3.0 eventually ships
  <zyga> mvo: we wrote snapd.apparmor.service to support that and use it on some systems
  <zyga> mvo: solus has a custom solution for loading profiles but it supports /var/lib/snapd/apparmor already
  <zyga> mvo: we can do it
  <mvo> zyga: interessting, might be a good option, I feel I lack some details though, need to look closer after I did this bug triage
  <zyga> mvo: sure, we can talk about it later today
  <zyga> mvo: I mainly worry about how to fit this into our framework of rollbacks
  <amurray> mvo zyga: you could change the profile in /etc to '#include if exists </var/...>' so that it can hang around and still work even if the one in /var goes away
  <zyga> amurray: hey :)
  <amurray> mvo zyga: ah sorry - this was added in AppArmor 2.13 iirc so won't work for older releases
  <zyga> amurray: last time we looked it was not supported
  <zyga> :D
  <zyga> exactly
  <amurray> hey zyga
  <zyga> so it's great, but we cannot have it
  <amurray> bah ignore me then... oh well
  <zyga> amurray: shipping software on linux is easy they said ;)
  <zyga> amurray: while we have you
  <zyga> amurray: do you have a moment to look at an idea we had
  <zyga> amurray: it's described here 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>
  <amurray> zyga: sure it's easy shipping software when you have snapd - shipping snapd however... that is harder :)
  <amurray> zyga: give me a sec
  <zyga> amurray: but the basic idea is that we mount a cgroup v1 hierarchy at /run/snapd/cgroup
  <zyga> amurray: no controllers just name=snapd
  <zyga> amurray: and we use it in v1 and v2 worlds so that we can always track processes
  <zyga> amurray: we want holes to be poked in the idea
  <amurray> zyga: my cgroups knowledge is a bit rusty but I will try and brush up and then review it in the next day or so if that's ok?
  <zyga> amurray: perfect
  <zyga> thank you so much
   * zyga takes bit out for a walk
  <amurray> zyga: no worries
  <mvo> amurray: hey, do you happen to know if there is a "if file.exists()" primitive in apparmor profiles? or an include_if_availalbe? context is bug 1825298
  <mup> Bug #1825298: apparmor.service fails to start when apt install/remove snapd due to snapd profile error <snapd:Confirmed> <snapd (Ubuntu):Triaged> <snapd (Ubuntu Cosmic):Won't Fix> <https://launchpad.net/bugs/1825298>
  <pstolowski> morning
  <pstolowski> mborzecki: hey, have you looked at https://paste.ubuntu.com/p/S48Gyv5mpp/ recently? snapd deb failing to install inside container
  <mborzecki> pstolowski: he, it's fixed in master by cachio
  <pstolowski> mborzecki: ah, great
  <mvo> hey pstolowski !
  <pstolowski> o/
  <pstolowski> mvo: do you think https://bugs.launchpad.net/snapd/+bug/1824162 is medium prio? i was contemplating setting it critical for a while :/
  <mup> Bug #1824162: /usr/lib/snapd/snapd:11:runtime:runtime:runtime:runtime:runtime <artful> <bionic> <cosmic> <xenial> <zesty> <snapd:Triaged by stolowski> <snapd (Ubuntu):In Progress> <https://launchpad.net/bugs/1824162>
  <pstolowski> mvo: it may occur regardless of experimental hotplug flag, and may prevent clean shutdown of snapd; of course only if there is udev netlink activity
  <mvo> pstolowski: I saw the report
  <mvo> pstolowski: it should probably be high or criticial, yes
  <mvo> pstolowski: do we have a fix yet or is it complicated?
  <pstolowski> mvo: no fix but should be simple, i needed to think a bit about it. should have a PR today
  <mup> PR snapd#7593 closed: recovery-tool: add sfdisk wrapper <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7593>
  <mup> PR snapd#7609 opened: snap-recovery: remove "usedPartitions" from sfdisk.Create() <Created by mvo5> <https://github.com/snapcore/snapd/pull/7609>
  <stealthybox> davdunc, could we update the aws-cli snap?   It's getting a bit too old to use with EKS.  Anything Weaveworks can do to help get this bumped regularly?  Cheers
  <zyga> mborzecki: updated 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> mborzecki: I think I applied everything that we agreed upon
  <zyga> mborzecki: I didn't apply the changes that would impact people with the feature disabled for now
  <zyga> mborzecki: I'll do a small patch on top that enables this unconditionally to see if things fall apart
  <zyga> mborzecki: and then move this to happen for all snap confinement types
  <oSoMoN> pedronis, hello! would you mind voting on https://forum.snapcraft.io/t/auto-connecting-the-personal-files-interface-for-the-chromium-snap-part-ii/13705 ?
  <mup> PR snapd#7602 closed: overlord/many: extend check snap callback to take snap container <Remodel :train:> <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7602>
  <pedronis> mborzecki: please do a follow up to #7602 where you swap *snap.Info and snap.Container
  <mup> PR #7602: overlord/many: extend check snap callback to take snap container <Remodel :train:> <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7602>
  <mborzecki> pedronis: sure
  <pedronis> thanks
  <pedronis> mborzecki: to be clear, it means that now args are  snap, snapf, curSnap
  <mborzecki> pedronis: yup, got it :P
  <pedronis> mborzecki: I suppose snap, curSnap, snapf   if it's a bit simpler
  <pedronis> but snapf first is strange because of most of these will not use it
  <pedronis> it's ancillary to the infos
  <zyga> mborzecki: trivial https://github.com/snapcore/snapd/pull/7610
  <mup> PR #7610: cmd/snap-confine: remove leftover condition from capability world <Created by zyga> <https://github.com/snapcore/snapd/pull/7610>
  <mup> PR snapd#7610 opened: cmd/snap-confine: remove leftover condition from capability world <Created by zyga> <https://github.com/snapcore/snapd/pull/7610>
  <pstolowski> mvo: hmm i take my words back, a simple fix doesn't cut it for go-udev, it may get more complicated to fix
  <zyga> mborzecki: we need to talk
  <zyga> mborzecki: about classic mount ns
  <zyga> mborzecki: I have an idea that will resolve a problem that was raised during one of the review cycles
  <zyga> mborzecki: essentially, we can keep using the mount namespace we inherit when starting
  <zyga> mborzecki: and not re-associate back to pid-1 ns
  <zyga> mborzecki: I need to go for a haircut now, let's chat later, ok?
  <mborzecki> zyga: sgtm, deep in some bits of gadget/devicestate now
  <zyga> mborzecki: but the main idea is: since there is no persistence we don't need to re-associate with pid-1 ns
  <zyga> mborzecki: and anything we need to do (like tracking) can be forked to a helper that re-associates and quits
  <zyga> mborzecki: so that main process is where it was originally
  <zyga> mborzecki: this means that there is perfect compatibility and no impact to any odd setups that work today
   * zyga runs for an errand, ttyl
  <mvo> pstolowski: uh, thats slightly sad
  <mup> PR snapd#7577 closed: overlord: set fake serial in TestRemodelSwitchToDifferentKernel <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7577>
  <kjackal> hi jdstrand. I am settign up microk8s with strict confinement. Partially works. I have a problem with a pod getting a denial.
  <kjackal> apparmor="DENIED" operation="ptrace" profile="snap.microk8s.daemon-kubelet//systemd_run" pid=3034 comm="mount" requested_mask="trace" denied_mask="trace" peer="snap.microk8s.daemon-kubelet"
  <kjackal> Have you seen this before?
  <Chipaca> kjackal: it's a bit early
  <kjackal> yeap I know, no worries. I will ping him later as well
  <pedronis> Chipaca: hi, I did a pass on #7608
  <mup> PR #7608: o/snapstate, etc: SnapState.Channel -> TrackingChannel, and a setter <Created by chipaca> <https://github.com/snapcore/snapd/pull/7608>
  <Chipaca> just reading it
  <Chipaca> pedronis: the "Invalid channel" was because that way it looked just like the error we would get from the store :-)
  <Chipaca> perhaps too cute a reason tho
  <Chipaca> pedronis: pushed fixes for those and the spread tests
  <Chipaca> now going for a walk, bbiab
  <pedronis> Chipaca: made a naming remark
  <mup> PR snapd#7611 opened: overlord/many: switch order of check snap parameters <Remodel :train:> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7611>
  <mborzecki> pedronis: ^^
  <pedronis> mborzecki: thanks, the fact that nil now are packed together seems to mean it's the right thing
  <mborzecki> pedronis: wodnering about moving it further to the right, after flags though
  <pedronis> we tend to put flags as right as we can
  <pedronis> you would have:   nil, snapstate.Flags{}, nil
  <pedronis> doesn't look better to me,  any particular reason?
  <pedronis> if we want to shuffle again
  <pedronis> having after the first snap would still be best (except it needs more signature churn)
  <mborzecki> pedronis: otoh, it's probably good as it is in the PR, infos come first, then the container, then the rest
  <pedronis> mborzecki: as I said I'm fine with the PR state
  <mborzecki> ack
  <pstolowski> mborzecki: do you have a moment for https://github.com/snapcore/snapd/pull/7518 ?
  <mup> PR #7518: cmd/snap: sort tasks in snap debug timings output <Created by stolowski> <https://github.com/snapcore/snapd/pull/7518>
  <mborzecki> pstolowski: sure
  <pstolowski> thanks!
  <mup> PR snapd#7612 opened: gadget: add a public helper for parsing gadget metadata <Remodel :train:> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7612>
  <mborzecki> another simple one ^^
  <mup> PR snapd#7355 closed: interfaces/apparmor: load multiple profiles in a single batch <Complex> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7355>
  <pstolowski> pedronis: what's the problem with the transition in the store wrt #7092?
  <mup> PR #7092: packaging: use snapd type and snapcraft 3.x <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7092>
  <mup> PR snapd#7613 opened: snap-recovery: add minimal binary so that we can use spread on it <Created by mvo5> <https://github.com/snapcore/snapd/pull/7613>
  <amurray> mvo: there is 'include if exists' - see say https://gitlab.com/apparmor/apparmor/blob/master/profiles/apparmor.d/abstractions/dri-enumerate#L11 for an example - but this is only supported by apparmor 2.13
  <amurray> and as zyga mentioned, this 2.13 is not available everywhere so include if exists is probably not a realistic option
  <pedronis> pstolowski: the store checks that the type of snap upload is like the one of the last approved one
  <pedronis> so for snapd is app
  <pedronis> atm
  <pedronis> we are discussing with the store to have an override
  <pedronis> it's a good check in general, but a couple of cases show we need an override
  <pstolowski> pedronis: i see, thanks
  <mvo> amurray: thank you!
  <mup> PR snapcraft#2751 closed: tests: move cli store push/upload tests to FakeStoreCommands <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2751>
  <mup> PR snapcraft#2745 closed: tests: update spread tests to account for content snaps <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2745>
   * pstolowski lunch
  <Chipaca> zyga: question about #7610, about something i only noticed thanks to pstolowski
  <mup> PR #7610: cmd/snap-confine: remove leftover condition from capability world <Created by zyga> <https://github.com/snapcore/snapd/pull/7610>
  <zyga> sure
  <zyga> looking at the PR
  <Chipaca> zyga: why do you call geteuid etc when you've already loaded their answers via getresuid?
  <zyga> Chipaca: there's no good reason, it's just a bunch of old code few people touch
  <zyga> Chipaca: some reasons as that it is easier to ... reason about the code in front of you
  <zyga> vs some state
  <zyga> Chipaca: but I think that it can be simplified
  <zyga> pstolowski, Chipaca: would you mind if I open the simplification as another PR if this goes green?
  <zyga> I have some more in this area anyway
  <pstolowski> zyga: absolutely
  <Chipaca> zyga: what's currently 'if geteuid() != 0 { bail } ' could go right after the call to getresuid and make it easier to follow without needing the extra syscall
  <zyga> yeah
  <Chipaca> etc etc
  <zyga> I missed that, I looked at other parts and got confused
  <Chipaca> zyga: also these are all nits :-)
  <zyga> sure, but it's good to ask such questions
  <zyga> thank you for that!
  <zyga> :)
  <Chipaca> :)
  <Chipaca> speaking of questions, lunchp?
   * Chipaca goes
  <zyga> Chipaca: lunchp? is redundant, no?
  <zyga> it's either lunch? or lunchp
  <zyga> ;-)
  <Chipaca> I was questioning the very question, probably
  <zyga> Chipaca: (lunch?)? ;-)
  <mup> PR snapd#7610 closed: cmd/snap-confine: remove leftover condition from capability world <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7610>
  <zyga> it's in :)
  <mup> PR snapd#7611 closed: overlord/many: switch order of check snap parameters <Remodel :train:> <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7611>
  <zyga> mborzecki: I opened a draft of device cgroup changes I had stashed, there's more piled on top to support v2 but I think this is a good thing to discuss before
  <zyga> mborzecki: if you have some time now we can discuss before the standup
  <mup> PR snapd#7614 opened: cmd/snap-confine: implement snap-device-helper internally <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>
  <zyga> mborzecki: it's not complex, I think it's actually more readable than before
  <mborzecki> zyga: ok, let me grab a coffee
  <jdstrand> pstolowski: re 7355> woohoo, merged! :)
  <zyga> jdstrand: hey :)
  <zyga> jdstrand: there's something that you could look at to help us move forward with a feature
  <zyga> jdstrand: we also asked alex and he said he would look tomorrow
  <zyga> jdstrand: but it would be good for you be aware of it in general
  <zyga> jdstrand: 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: the main idea is that we mount a new cgroup at /run/snapd/cgroup, just for tracking processes
  <zyga> jdstrand: no controllers are involved
  <jdstrand> kjackal: yes, I have seen that and it should be addressed in snapd 2.42. what does 'snap version' give you?
  <zyga> jdstrand: and we use this method in v1 and v2 worlds where it surprisingly works for as long as v1 is in the kernel
  <zyga> jdstrand: we have some more plans for this, there's a follow up branch that adds and configures a release agent for the cgroup
  <zyga> jdstrand: and this lets us solve some long-standing bugs with resouce leaks as well as get the new desired features for app termination notification in snapd
  <kjackal> jdstrand: 2.42+git1515.143caf4~ubuntu16.04.1
  <jdstrand> zyga: thanks for making me aware. the idea seems ok otoh
  <kjackal> jdstrand: I am now in the middle of another addon that is failing. This time with:
  <kjackal> apparmor="DENIED" operation="exec" info="no new privs" error=-1 profile="snap.microk8s.daemon-containerd" name="/usr/local/bin/proxy-init" pid=16941 comm="runc:[2:INIT]" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 target="cri-containerd.apparmor.d"
  <jdstrand> kjackal: can you paste /var/lib/snapd/apparmor/profiles/snap.microk8s.daemon-kubelet ?
  <kjackal> jdstrand: Here it is http://paste.ubuntu.com/p/fqpxsZscF9/
  <jdstrand> kjackal: re the paste> you don't have the rule in there. can you paste /snap/microk8s/current/meta/snap.yaml ?
  <kjackal> jdstrand: http://paste.ubuntu.com/p/4qMqPQjmKn/
  <jdstrand> hmm, I thought that was in 2.42
   * jdstrand double checks
  <jdstrand> kjackal: ok, I misread the trace denial. I saw it the other way around (kubelet tracing itself) but not kubelet's systemd-run needing to trace kubelet
  <jdstrand> kjackal: do you know what operation is causing that?
  <kjackal> jdstrand: I shared this via email https://docs.google.com/document/d/1mGHEfgiTDB6Nd11vgkPgCY2OrzrDGk7vmEgjrJGTKmA/edit?usp=sharing
  <jdstrand> kjackal: also, what kernel is this on?
  <kjackal> jdstrand: its on Linux ip-172-31-20-243 4.15.0-1051-aws #53-Ubuntu SMP Wed Sep 18 13:35:53 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
  <mup> PR #53: Negate the integration build tag <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapd/pull/53>
  <jdstrand> kjackal: ok, I understand the denial and will create a PR
  <jdstrand> kjackal: do you have more information on the proxy-init denial?
  <kjackal> I am looking into this now
  <kjackal> What other info would you like me to gather?
  <jdstrand> kjackal: like with the subpath, the context of the denial. also, this looks to be in aws, can you give me ssh access?
  <kjackal> of course, looking for you in LP
  <kjackal> jdstrand: try ubuntu@ec2-54-161-115-99.compute-1.amazonaws.com
  <jdstrand> kjackal: ok, I'm in
  <kjackal> there is a tmux session I am using, in case you want to show me anything
  <jdstrand> kjackal: what are you doing to trigger the proxy-init denial?
  <kjackal> jdstrand: it is part of the "microk8s.enable linkerd"
  <kjackal> all containers are failing. I suspect the reason is "securityContext:
  <kjackal>           runAsUser: 2103"
  <kjackal> jdstrand: see "sudo microk8s.kubectl edit -n linkerd       deployment.apps/linkerd-controller"
  <jdstrand> that is entirely possible
  <jdstrand> kjackal: that user doesn't exist on the main system, but more importantly, I think nnp (no new privs) may get in the way if you try to use a different user than what it is running as. try making that root
  <kjackal> jdstrand: the problem is that the manifests I apply are not mine
  <kjackal> jdstrand: I am deploying the linkerd manifests. If they fail out of the box they will fail from anyone
  <jdstrand> joedborg: are you using linkerd? have you seen/fixed kjackal's denial in kubernetes-worker?
  <roadmr> linkerd sounds like a startup's name (linkerd.io! we link all your links!)
  <joedborg> jdstrand: i'm not using linkered.  kjackal sent me some last week which one in particular?
  <jdstrand> joedborg: the one from 30 minutes ago
  <jdstrand> (in this channel)
   * joedborg found it
  <jdstrand> kjackal: nnp presents a number of challenges
  <kjackal> joedborg: these are the instructions for deploying linkerd https://linkerd.io/2/getting-started/
  <roadmr> I was just joking about linkerd.io :(
  <jdstrand> roadmr: clearly not ;)
  <roadmr> well it's like "I was just joking about Donald Trump being president" :(
  <joedborg> jdstrand: kjackal: Ah, no i haven't, but this may be where k8s-worker and microk0s diverge; microk8s runs a lot of infra outside of k8s, where as k8s-worker runs it inside, so there will be differences like this (where the paths are different, for example)
  <joedborg> thanks kjackal, I'll test it on my local cluster
  <jdstrand> joedborg: that's fine, thanks
  <kjackal> joedborg: jdstrand, do you think we could say that "certain workloads will not run on strictly confined setup" ?
  <jdstrand> kjackal: have you tried to use a layout for /usr/local/bin?
  <jdstrand> kjackal: it isn't in the current snap.yaml
  <jdstrand> kjackal: ala https://github.com/charmed-kubernetes/snap-kubernetes-worker/blob/master/snap/snapcraft.yaml
  <kjackal> jdstrand:  I can add it now
  <jdstrand> kjackal: I would like to better understand what is happening before saying that (re certain workloads)
  <joedborg> jdstrand kjackal I think it's possible to run all workloads under strict confinement, but that it hignes on getting runc to use chroot, rather than pivot (as we discussed yesterday)
  <jdstrand> kjackal: can you not install/refresh microk8s on the aws node I'm on for a bit (I'll let you know)?
  <jdstrand> kjackal: also, what is a command I can run to trigger the subpath denial?
  <joedborg> jdstrand: kjackal: ah, so I do get that same issue when running linkerd `[86131.195871] audit: type=1400 audit(1571232667.748:226767): apparmor="DENIED" operation="exec" info="no new privs" error=-1 profile="snap.kubernetes-worker.containerd" name="/usr/local/bin/proxy-init" pid=10902 comm="runc:[2:INIT]" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 target="cri-containerd.apparmor.d"`
  <kjackal> jdstrand: try this: sudo microk8s.kubectl apply -f  /var/snap/microk8s/current/testcfgmount.yaml
  <jdstrand> joedborg: is it possible to intercept that 'runAsUser: 2103' bit and remove it/make it '0'?
  <joedborg> jdstrand: it might be possible, but would probably mean no cross compatibility with running clusters
  <Chipaca> zyga: I had my hand on "close window" before mvo finished saying "weird users of qemu"
   * Chipaca stays well away
  <joedborg> jdstrand: just FYI, that's user 2103 from within containerd
  <pedronis> Chipaca: any reason not to change .Full already ? just more spread tests breaking? or something else
  <joedborg> jdstrand: like with the pivot root stuff
  <Chipaca> pedronis: no reason
  <Chipaca> pedronis: oh wait, you mean the implementation?
  <pedronis> Chipaca: yes
  <jdstrand> kjackal, joedborg: I need to study the linkerd issue. nnp is, shall we say, problematic atm for all the LSMs (including apparmor)
  <pedronis> it's used only in errors afaict
  <Chipaca> pedronis: I think it'll break some things without the patch
  <Chipaca> let me check though
  <joedborg> jdstrand: i imagine there's something been done to the docker snap to allow that
  <pedronis> Chipaca: afai see all usages are in cmd/snap/error.go
  <pedronis> Chipaca: this is Full, not Clean
  <Chipaca> pedronis: that's usage of .Full, usage of canon(ical)ize are in snapstate
  <pedronis> I don't see Full in snapstate
  <pedronis> (I might have removed it myself at some point, don't know, I don't see it anymore)
  <Chipaca> pedronis: my question is what happens if you do --channel=//foo//, shut down snapd ,restart with the new one that calls Canonize
  <pedronis> Chipaca: what it has to do with Full() tough?
  <pedronis> that's a different issue
  <Chipaca> ?
  <pedronis> Chipaca: yes, we want the patch very soon
  <Chipaca> pedronis: then we're talking cross-porpoises
  <Chipaca> pedronis: what're you talking about :-)
  <pedronis> Chipaca: change Channel.Full to be Canonize
  <pedronis> what code would explode ?
  <roadmr> ð¬
  <Chipaca> pedronis: i thought we were talking about making channel.Canonize call Channel.Full
  <Chipaca> pedronis: you were talking about renaming Channel.Full to be Channel.Canonize?
  <pedronis> no?
  <pedronis> no
  <pedronis> no
  <pedronis> no
   * Chipaca giggles
  <pedronis> Chipaca: use the code in Canonize as implementation for Full
  <Chipaca> ahhhhhhh
  <pedronis> then make channel.Full use Channel.Full
  <pedronis> still a bit unclear what this would make explode
  <pedronis> more than the current state of the PR
  <Chipaca> nothing, probably -- it's more lenient
  <Chipaca> might break some tests that could be checking the lack of leniency
  <pedronis> ok
  <Chipaca> other than that it should be about the same
  <pedronis> as I said, Channel.Full afaict is only used in cmd/snap/error.go
  <pedronis> Chipaca: I know we need to fix Clean at some point
  <pedronis> because in the new world is weird
  <pedronis> but that came come later
  <Chipaca> ok
  <pedronis> when we do the actual default track work
  <Chipaca> I'll write the code but not push it unless there's another reason to iterate this PR
  <Chipaca> I'll push it as separate otherwise
  <pedronis> as you prefer
  <pedronis> but let's try to use Full in full (as name)
  <jdstrand> ijohnson: hey did you do anything to docker to avoid denials like this:
  <jdstrand> [86131.195871] audit: type=1400 audit(1571232667.748:226767): apparmor="DENIED" operation="exec" info="no new privs" error=-1 profile="snap.kubernetes-worker.containerd" name="/usr/local/bin/proxy-init" pid=10902 comm="runc:[2:INIT]" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 target="cri-containerd.apparmor.d"
  <jdstrand> ijohnson: the theory is it has to do with runAsUser
  <jdstrand> kjackal, joedborg (cc joeubuntu, amurray): so that denial ^ is going to require not insignificant investigation, possibly from other members of the security team. nnp is quite problematic with LSMs with current kernels
  <joedborg> jdstrand: nnp?
  <jdstrand> kjackal, joedborg (cc joeubuntu, amurray): this is unplanned work and beyond the strict mode k8s minimum viable product
  <jdstrand> joedborg: 'no new privs'
   * joedborg reads kernel.org
  <joedborg> jdstrand: ah okay, cool
  <kjackal> jdstrand: This denial came up with the DNS addon and had to patch it https://github.com/ubuntu/microk8s/blob/feature/strict-v3/microk8s-resources/actions/coredns.yaml#L105
  <jdstrand> kjackal (cc joedborg, joeubuntu, amurray): without investigating, my concern is this may require kernel changes for things to run unpatched
  <kjackal> meaning, it is rather common
  <jdstrand> kjackal: indeed. this isn't 'just a snapd' thing
  <jdstrand> kjackal (cc joeubuntu, amurray and joedborg): I suggest trying to work around it for now. if you need me/the security team to investigate it, we likely need to discuss prioritizing/resourcing with Tim and Joe
  <kjackal> yeap
  <ijohnson> jdstrand: hmm I don't think I've seen that one before
  <jdstrand> it's possible kernel changes are not invloved. eg, there are code changes in snap-confine that I did to work around it. something similar might be possible in linkerd or containerd (beyond the oci change, etc)
  <jdstrand> ijohnson: ack, thanks
  <jdstrand> but it depends on what the investigation reveals
  <ijohnson> did y'all find anything more about pivot_root last night? I didn't see anything more on IRC after I left
  <jdstrand> kjackal: unless you escalate to Tim and joeubuntu, I'm not planning to look into it atm
  <jdstrand> kjackal: ok, swinging back to the trace denial
  <jdstrand> kjackal: I'm tinkering with the instance now
  <kjackal> thanks
  <mup> PR snapd#7606 closed: tests: run apt update in lxd containers <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7606>
  <kjackal> I will report back to Tim and we will see what we have to do about it. Thank you jdstrand
  <zyga> jdstrand: anything I can help with?
   * zyga has highlight on snap-confine
  <jdstrand> zyga: no, snap-confine is fine. I was just talking about some hoops I had to jump through wrt nnp for context on the linkerd denial
  <zyga> ack
  <jdstrand> kjackal: ok, I'm done. with this: https://paste.ubuntu.com/p/HFpmhxVph5/ I'm able to run that test command
  <jdstrand> kjackal: those may not be the rules I use in the PR, but if you want to manually add them for testing, etc, there they are
  <jdstrand> kjackal: logging out of the instance. I'll ping you with the PR
  <kjackal> thank you jdstrand
  <kjackal> jdstrand: I tried to setup a branch on the latest channel for build of the strict microk8s. It seems things are blocked into maual review. Is there a way to automate the pushes?
  <jdstrand> kjackal: yes. I have to step away but will do that when I get back
  <kjackal> cool
  <oSoMoN> jdstrand, could you please vote/comment on https://forum.snapcraft.io/t/auto-connecting-the-personal-files-interface-for-the-chromium-snap-part-ii/13705 ?
  <oSoMoN> (thanks in advance!)
   * zyga goes for a nap
  <zyga> ttyl
  <mup> PR snapcraft#2752 opened: errors: migrate handful of errors to SnapcraftException <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2752>
  <kjackal_v2> jdstrand: joedborg: the prometheus operator is also failing with the same error:
  <kjackal_v2> apparmor="DENIED" operation="exec" info="no new privs" error=-1 profile="snap.microk8s.daemon-containerd" name="/bin/operator"
   * cachio lunch
  <joedborg> kjackal_v2: +1
  <mup> PR snapd#7615 opened: policy: implement CanRemove policy for the snapd type <Created by mvo5> <https://github.com/snapcore/snapd/pull/7615>
  <zyga> mvo: I'm fixing the bug with snapd removal
  <Chipaca> ttfn!
  <ogra> zyga, by makiing it unremovable ? :)
  <zyga> ogra: not today :)
  <ogra> hehe
   * ijohnson goes to lunch before mborzecki's schedule PR makes my brain hurt more
  <zyga> ijohnson|lunch: just schedule lunch, it will solve itself
  <ogra> snap feed --time=
  <ogra> ??
   * zyga needs to finish this tomorrow
  <zyga> time to rest
  <mup> PR snapd#7616 opened: interfaces/many: allow systemd-run to mount volume subPaths plus cleanups <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7616>
  <jdstrand> kjackal: fyi: https://github.com/snapcore/snapd/pull/7616
  <mup> PR #7616: interfaces/many: allow k8s/systemd-run to mount volume subPaths plus cleanups <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7616>
  <kjackal> awesome, thank you jdstrand
  <jdstrand> kjackal: is that instance still up for me to verify ^ for the subPath fix?
  <kjackal> yes it is up
  <jdstrand> kjackal: do you mind if I check now real quick?
  <kjackal> jdstrand: no go ahead
  <kjackal> jdstrand: any suggestion for this:
  <kjackal> [ 4041.214192] audit: type=1400 audit(1571247745.450:4392): apparmor="DENIED" operation="open" profile="snap.microk8s.daemon-kubelet" name="/var/lib/snapd/hostfs/usr/lib/x86_64-linux-gnu/libnvidia-ml.so.390.116" pid=4464 comm="kubelet" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
  <kjackal> [ 4041.214196] audit: type=1400 audit(1571247745.450:4393): apparmor="DENIED" operation="open" profile="snap.microk8s.daemon-kubelet" name="/var/lib/snapd/hostfs/usr/lib/i386-linux-gnu/libnvidia-ml.so.390.116" pid=4464 comm="kubelet" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
  <kjackal> [ 4041.361220] audit: type=1400 audit(1571247745.598:4394): apparmor="DENIED" operation="open" profile="snap.microk8s.daemon-containerd" name="/etc/nvidia-container-runtime/config.toml" pid=15115 comm="nvidia-containe" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
  <kjackal> trying to see if gpu support is broken or not
  <jdstrand> kjackal: I'm going to defer to zyga for that. it is curious you are seeing this in hostfs. I would expect the libs to be in /var/lib/snapd/lib/gl
  <jdstrand> kjackal: perhaps you could use a layout for /etc/nvidia-container-runtime and have it look in the right place?
  <jdstrand> kjackal: but usr/lib/i386-linux-gnu/libnvidia-ml.so.390.116 is not what I expected
  <jdstrand> kjackal: that said, zyga has looked at gpu support a lot. he may be eod atm
  <kjackal> ok, I will see what I can do
  <kjackal> thanks
  <zyga> jdstrand: there are cases where we take it from hostfs
  <jdstrand> kjackal: I'll ping you in a minute when I'm done with the test
  <jdstrand> (subPath)
  <zyga> kjackal: I'm EOD, please drop me a note with the details
  <kjackal> cool zyga, let me try some things first
  <jdstrand> kjackal: ok, this would be the result of when that PR is applied: https://paste.ubuntu.com/p/fFXYP5kNvk/, and with that 'sudo microk8s.kubectl apply -f /var/snap/microk8s/current/testcfgmount.yaml' doesn't have the ptrace trace denial
  <jdstrand> kjackal: so, cool :)
  <jdstrand> kjackal: logging out now
  <kjackal> many thanks jdstrand
  <jdstrand> kjackal: np. when you see that merged, the next day's core from edge will have it
  <kjackal> great
  <jdstrand> kjackal: this should be in 2.43
  <jdstrand> kjackal: are you using the same snap name for strict mode microk8s? I ask cause I don't see any failed reviews for microk8s
  <kjackal> let me fire the lp builder
  <jdstrand> kjackal: I'll look at the snap.yaml in the instance and create a snap decl
  <kjackal> just queued a build
  <kjackal> ETA in 13 minutes (estimated)
  <jdstrand> kjackal: it will fail due to the review-tools needing an update for your use of personal-files. I've made that change but it will need to be manually approved for now
  <jdstrand> kjackal: but you can ping my to manually approve in the meantime
  <kjackal> is this a one off approval or do I need to ping you on every new revision I want to push to the channel branch?
  <kjackal> jdstrand: ^
  <jdstrand> kjackal: until the review-tools are in prod, every one. after that, it will remember
  <kjackal> jdstrand: cool, for now I can wait. We may want to push one in a couple of weeks
  <jdstrand> roadmr: can you pull 20191016-1840UTC? just doc changes and 2 override additions
  <jdstrand> kjackal: ^ that has the change I mentioned
  <jdstrand> kjackal: ok, it should all be in place then
  <jdstrand> roadmr: and hi! :)
  <kjackal> awesome
  <roadmr> jdstrand: hey! sure thing
  <roadmr> jdstrand: when can we chat re: stateful review-tools?
   * cachio afk
  <jdstrand> roadmr: tomorrow?
  <jdstrand> roadmr: and thanks! :)
  <roadmr> jdstrand: sure, can I go by your google calendar?
  <roadmr> jdstrand: looks like there's no such tag in the repo :/
  <jdstrand> roadmr: yes, please look at the calendar
   * jdstrand looks at tag
  <roadmr> thanks!
  <jdstrand> roadmr: 20191016-1840UTC ? I see it in https://git.launchpad.net/review-tools?h=master
  <jdstrand> https://git.launchpad.net/review-tools/tag/?id=20191016-1840UTC
  <roadmr> jdstrand: ah! it's there now
  <jdstrand> roadmr: oh hah, I pushed the tag, not the commit :)
  <roadmr> jdstrand: some refreshing shenanigans, it seems
  <roadmr> ð
  <ijohnson> jdstrand: re #7616 am I correct in thinking that mount rules for `/var/snap/@{SNAP_INSTANCE_NAME}/*/**` would allow a snap revision to mount stuff over another revision?
  <mup> PR #7616: interfaces/many: allow k8s/systemd-run to mount volume subPaths plus cleanups <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7616>
  <jdstrand> ijohnson: yep
  <jdstrand> ijohnson: hence my comment about refresh
  <ijohnson> is that intentional ?
  <jdstrand> ijohnson: did you see the commit message? I avoided SNAP_REVISION after all thinking that refresh would be potentially problematic
  <ijohnson> jdstrand: I did I just don't quite understand the reasoning
  <ijohnson> if they needs mounts to persist across refreshes then they should definitely use common
  <ijohnson> my original point was just that maybe someday they don't need to care about mounts persisting across  revisions and instead have incompatible data between revisions that they explicitly don't want to be shared across revisions
  <ijohnson> if that was the case they could then transition to mounting things on top of $SNAP_DATA, which would be per revision
  <jdstrand> ijohnson: I suspect that, like lxd, k8s will use the mechanism to not restart itself so pods aren't blown away
  <ijohnson> yes that is probably true
  <ijohnson> does lxd have rules to do mounts across revisions in $SNAP_DATA though?
  <jdstrand> ijohnson: lxd's profile allows transitioning to unconfined so there are no rules
  <jdstrand> ijohnson: (beyond allowing it to get to that point)
  <ijohnson> ah right yeah
  <ijohnson> lxd is special
  <jdstrand> ijohnson: iirc, this was why common/ was enforced in kubernetes-support
  <jdstrand> (ie, the refresh point, not lxd :)
  <jdstrand> it's been a while since I wrote those rules, but iirc I was enforcing best practice
  <ijohnson> jdstrand: perhaps given this we should just stick with common
  <jdstrand> ijohnson: ok. easy enough. we can rediscuss if there is a use case for SNAP_DATA
  <ijohnson> sure sounds good
  <ijohnson> feel free to force push if you want to remove that most recent commit
  <jdstrand> ijohnson: I am tempted to do that since I noticed typos in some commit messages ;) however, I did a revert commit so the discussion is captured for posterity
  <ijohnson> jdstrand: ack
  <mup> PR snapd#7617 opened: snap-confine.apparmor.in: harden pivot_root until we have full mediation <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7617>
  <jdstrand> roadmr: fyi, https://dashboard.snapcraft.io/snaps/microk8s/feedback/ has been giving a 504 for... 30 minutes?
  <jdstrand> roadmr: ish
  <roadmr> thanks jdstrand, fighting some minor fires store-side
  <jdstrand> roadmr: ok, just fyi. I'm not blocked
  <roadmr> right - seems to be widespread, get the same for e.g. core
  <jdstrand> roadmr: fyi, it is not *all* snaps. eg https://dashboard.snapcraft.io/snaps/telegraf/feedback/ is fine
  <roadmr> ah, interesting
  <roadmr> jdstrand: nessita found it's an n+1 queries problem which will hit snaps with many uploads
  <jdstrand> interesting
  <jdstrand> roadmr: I did see this with https://dashboard.snapcraft.io/snaps/app-outlet/ (notice no feedback/ in url) and it sometimes displayed
  <nessita> jdstrand, if you browse by revision, it should work
  <nessita> jdstrand, like https://dashboard.snapcraft.io/snaps/core/revisions/<revision>/
  <jdstrand> roadmr, nessita: well, I would need to know the revision. I guess I could snap info it.... also, I don't know if this makes a difference, but as a data point, I added scores of snap decls for snaps for pulseaudio, each with a feedback comment
  <jdstrand> (yesterday)
  <jdstrand> continuing that today
  <jdstrand> nessita: fyi, 504 with https://dashboard.snapcraft.io/snaps/app-outlet/revisions/1/
  <nessita> jdstrand, odd, it opened quite fast for me. Reloading...
  <nessita> hum 504 now
  <nessita> roadmr, maybe we have some sca fe with troubles?
  <jdstrand> nessita: that one didn't have many revisions iirc
  <roadmr> nessita: could be, or maybe the app units, one could have landed on an evil host
  <jdstrand> nessita: I just saw one with 73 revisions that was fine
  <nessita> jdstrand, yeah, we may have more than one issue. I mean, the linear queries is a problem and I've writen a test for it (that fails right now)
  <nessita> jdstrand, if you reload a few times https://dashboard.snapcraft.io/snaps/app-outlet/revisions/1/, do you get the right page from time to time?
  <jdstrand> nessita: I see it now
  <jdstrand> (30 revisions)
  <nessita> jdstrand, we may issues with one of the fe units or app units, let us look
  <roadmr> nessita: I would think app/backend units, the fe is just haproxy, shouldn't have any problems plus hasn't changed in a while
  <nessita> roadmr, jdstrand moving this to our private channel
  <roadmr> +1
  <nessita> roadmr, jdstrand #snastore please
  <nessita> roadmr, jdstrand #snapstore please
  <mup> PR snapcraft#2753 opened: cli: use click utilities for registering on push <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2753>
  <mup> PR snapd#7604 closed: many: address issues related to explicit/implicit channels for image building <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7604>
  #snappy 2019-10-17
  <mup> PR snapcraft#2753 closed: cli: use click utilities for registering on push <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2753>
  <mborzecki> morning
  <zyga> Hey
  <zyga> Taking Bit for a walk
  <mborzecki> zyga: hey
  <zyga> back in the office
  <zyga> man it's so wet today
  <zyga> it's not so cold but there's so much humidity everything is sticky wet
  <zyga> mborzecki: I'll work on the fix for apparmor now but later on I'd like to push some code through your review eyes ;)
  <mborzecki> hahah
  <mborzecki> zyga: i'm on a bug triage duty today, but want to finish some gadget stuff first
  <zyga> mborzecki: cool, enjoy it :)
  <zyga> mborzecki: perhaps you could triage fedora/rhel bugs
  <mborzecki> zyga: hm let me check whether i have the right permissions, last time i tried i couldn't switch them to resolved and assign to myself
  <mborzecki> zyga: should probably nag you and Eighth_Doctor to maybe add me to the snapd package
  <zyga> you have the required accounts and there's probably lots of stuff that is fixed
  <zyga> yeah, that's a good idea
  <zyga> add me as well if that's not already the case please
  <mup> PR snapd#7612 closed: gadget: add a public helper for parsing gadget metadata <Remodel :train:> <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7612>
  <pstolowski> morning
  <mborzecki> pstolowski: hey
  <mvo> hey pstolowski and mborzecki
  <mborzecki> mvo: hey
  <mvo> looks like we have lots of red, has anyone looked?
  <mvo> and happy release day
  <mborzecki> mvo: release day meaning we're going to see PRs failing on the store api? :)
  <mvo> mborzecki: most likely :/
  <mborzecki> mvo:  only 2 of recent PRs were red, pushed a little spelling fix to one with apparmor and pivot_root, the k8s one failed on store api returning 403
  <mup> PR snapd#7599 closed: gadget: refactor ensureVolumeConsistency <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7599>
  <mup> PR snapd#7618 opened: snap-install: add ext4,vfat creation support <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7618>
  <mup> PR snapd#7618 closed: snap-install: add ext4,vfat creation support <Simple ð> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7618>
  <mup> PR snapd#7619 opened: image,seed: hide Seed16/Snap16, use seed.Open in image_test.go <Created by pedronis> <https://github.com/snapcore/snapd/pull/7619>
  <mborzecki> mvo: 7618 was quick, should i review it still?
  <mvo> mborzecki: no
  <mvo> mborzecki: I just noticed it duplicates code from the gadget
  <mvo> mborzecki: better code
  <mvo> mborzecki: so I will update and repush, sorry, I'm extracting mergable bits from the draft PR of claudio and didn't notice the duplication
   * zyga has some back pain today
  <zyga> I'll focus on reviews
  <pedronis> pushed some seed/image cleanups,  so now #7619 should be reviewed before #7595
  <mup> PR #7619: image,seed: hide Seed16/Snap16, use seed.Open in image_test.go <Created by pedronis> <https://github.com/snapcore/snapd/pull/7619>
  <mup> PR #7595: seed/seedwriter: support writing Core 20 seeds (aka recovery systems) <Created by pedronis> <https://github.com/snapcore/snapd/pull/7595>
  <mvo> mborzecki: and its back again, had to tweak it a little to support contentless mkfs from gadget but still very easy I hope
  <mup> PR snapd#7620 opened: snap-install: add ext4,vfat creation support <Created by mvo5> <https://github.com/snapcore/snapd/pull/7620>
  <mvo> mborzecki: layering of the mocking is a bit debatable, happy to fix it
  <Chipaca> mborzecki: #1840751 is fix-released, if you have the bandwidth
  <mup> Bug #1840751: Please include store-url when it exists <Snap Store:Fix Released> <https://launchpad.net/bugs/1840751>
  <Chipaca> otherwise I'll leave it in my to-do
  <pedronis> Chipaca: hi, could you quickly backfill your standup notes for yesterday (maybe mvo should tell this, but I fear it might go all a bit downhill if we starts having gaps that are not because of time off)
  <Chipaca> drat, i forgot, yes
  <Chipaca> pedronis: thankyou for reminding me
  <pedronis> np
  <mborzecki> Chipaca: added a note in the topic and tagged it as upcoming for both of us :P
  <Chipaca> mborzecki: all I heard was "it's a race"
  <mborzecki> degville: i've gone through instructions in https://forum.snapcraft.io/t/building-a-snap-rpm-for-red-hat-enterprise-linux-rhel-8/13728 and updated them a bit, can you take a look whether i haven't butchered the language in the process?
  <degville> mborzecki: yes of course, thanks so much for looking through them and updating them!
  <degville> mborzecki: looks good - it's great to have the definitive article :) Thanks!
  <mborzecki> degville: it's using the release packages from github, at the cost of uglier download url :/ but i figured this would be better if the spec in master gains support for some new bianries that aren't in the latest release
  <Chipaca> mborzecki: degville: shouldn't the link point to the same place the example downloads?
  <Chipaca> or is it a different file
  <mborzecki> Chipaca: which example downloads?
  <mborzecki> the relase tarbal?
  <Chipaca> mborzecki: the spec file, but now i don't know what puts it there
  <Chipaca> so i'm confused and probably wrong
  <Chipaca> mborzecki: wha creates ~/rpmbuild/SOURCES/snapd.spec ?
  <Chipaca> in those instructions i mean
  <mborzecki> Chipaca: the tar incantation
  <mborzecki> Chipaca: tar -xvJ -C ~/rpmbuild/SPECS --strip-components=3 -f snapd_2.42.no-vendor.tar.xz snapd-2.42/packaging/fedora/
  <Chipaca> ahhh
  <Chipaca> mborzecki: i might have missed the strip-components option there :)
  <Chipaca> mborzecki: ok, so, question stands! shouldn't the link in "contains the recipe" point to the release recipe, not master?
  <mborzecki> ah right
  <degville> Chipaca / mborzecki: right, that's my fault. I put that original link in, you're right Chipaca.
  <Chipaca> https://github.com/snapcore/snapd/blob/release/2.42/packaging/fedora/snapd.spec is the 2.42 release blob
  <Chipaca> fwiw
  <mborzecki> Chipaca: degville: updated
  <degville> mborzecki: thank you!
  <Chipaca> mborzecki: is /blob/2.42/ the same as /blob/release/2.42?
  <Chipaca> anyway, i'll stop pestering now
  <zyga> pedronis: is this syntax new in go? https://github.com/snapcore/snapd/pull/7619/files#diff-4a51d32715a8521893a1f9ecf9236fb9R26
  <mup> PR #7619: image,seed: hide Seed16/Snap16, use seed.Open in image_test.go <Created by pedronis> <https://github.com/snapcore/snapd/pull/7619>
  <zyga> looks like type aliases
  <zyga> are those supported across all our go versions now?
   * zyga afk for a second
  <zyga> need to find some painkillers for the back
  <zyga> gosh, I love autumn and all the windy weather it brings
  <pedronis> zyga: yes, they are type aliases, we have already some (for tests) in the code base
  <pedronis> zyga: they were added in 1.9
  <pedronis> I think
  <Chipaca> yep, 1.9
  <mup> PR snapd#7573 closed: [RFC] client: add support for the new "/v2/assertions/%s?remote=true" <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7573>
  <mborzecki> ijohnson: silly me, pushed a fix for https://github.com/snapcore/snapd/pull/7443/files#r335908588 should have simplified this earlier since i was using the funky mon1-mon schedule in testing while working on the code, that's how the other part of the || came to be
  <mup> PR #7443: timeutil: fix schedules with ambiguous nth weekday spans <Bug> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>
  <ijohnson> mborzecki: great, I'll take a look in a bit thanks for explaining that
  <mborzecki> ok, onto the bug triage
  <mup> PR snapd#7621 opened: Add EPL-2.0 to licenses <Created by ralight> <https://github.com/snapcore/snapd/pull/7621>
  <mvo> mborzecki, zyga can someone on a fedora system check if "golang.org/x/xerrors" is available as a package?
  <zyga> mvo: hold on
  <zyga> mvo: a quick google ftp://rpmfind.net/linux/RPM/fedora/devel/rawhide/x86_64/g/golang-x-xerrors-devel-0-0.1.20190916gita985d34.fc32.noarch.html
  <zyga> mvo: so I suspect so
  <mborzecki> mvo:  i see it was released to 31 only
  <mvo> mborzecki: is it possible/easy to also releae for f30?
  <zyga> mvo: if needed it can be brouht to older releases
  <mborzecki> mvo: could probably ask the guy who maintains it to push a build for 30, although it's unsing a new packaging, so will require some tweaks
  <zyga> mvo: especially new devel packaes
  <mvo> will centos be a problem?
  <mborzecki> mvo: centos uses vendored pacakges
  <mvo> cool
  <mvo> well, it would make the PR I have here a lot nicer so would be nice to have it
  <mvo> and debian-sid has the package so its really just fedora
  <mborzecki> mvo: ah, it's the 1.13 error handling for older go releases
  <mvo> mborzecki: yeah
  <pstolowski> hmmmmm is there anything special about mount unit for core? on my WIP pre-baked image the unit is there in the fs (along one other snap), yet on boot it's not mounted and there is no trace of it in journal (the mount unit of other snap does appear there and gets mounted)
  <mvo> mborzecki: I think we will benefit in other areas too
  <zyga> pstolowski: which mount unit?
  <mvo> pstolowski: maybe not enabled in /{etc,lib}/systemd/system/mount.wants or something?
  <pstolowski> zyga: mount unit for core snap
  <mborzecki> btw. do you have an ubuntu system with nvidia?
  <zyga> mborzecki: me?
  <mborzecki> zyga: yes :P
  <zyga> mborzecki: not with ubuntu, last time I tried it wasn't working with this GPU
  <zyga> mborzecki: I think 19.10 will now work
  <zyga> mborzecki: but I don't have one installed
  <pstolowski> mvo: hmm interesting, will check, although mount unit is fine for lxd snap
  <mborzecki> zyga: ok, https://bugs.launchpad.net/snapd/+bug/1824168 needs checking on nvidia, perhaps they updated the snap since that time
  <mup> Bug #1824168: classic opengl application on 19.04 fail to find gl drivers <amd64> <apport-bug> <disco> <snapd:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1824168>
  <zyga> Ok
  <mup> PR snapd#7622 opened: snap: make `snap known --remote` use snapd if available <Created by mvo5> <https://github.com/snapcore/snapd/pull/7622>
  <ogra> ogra@pocketbeagle:~$ grep BUG /etc/os-release
  <ogra> BUG_REPORT_URL="http://bugs.launchpad.net/snappy/"
  <ogra> given you guys did so much bug cleanup the last days ...
  <ogra> is that url in UbuntuCore still accurate ?
  <ogra> (thats core18)
  <pstolowski> mvo: aha! that is the case, thank you
  <Saviq> zyga: hey, is there somewhere we could read about / provide feedback on the hardware-support snaps (GL)?
  <ogra> there used to be a forum thread about this ...
  <zyga> Saviq: they are not on the roadmap anymore. What is present is on the forum
  <zyga> You can respond to existing topics there
  <zyga> I made one for OpenGL and one for CUDA
  <ogra> well, the Mir team made one for opengl too ... before yours i think
  <ogra> https://forum.snapcraft.io/t/libgl-and-snaps/6270
  <Saviq> and I suppose what you mean is https://forum.snapcraft.io/t/gpu-support-proposal/11247 and https://forum.snapcraft.io/t/hello-world-cuda-analysis/11250
  <ijohnson> mborzecki: I checked with my nvidia gpu + 19.04 and I can reproduce
  <mborzecki> hm someone reported a but about snapd 2.34.2ubuntu0.1 to 2.37.4ubuntu0.1 upgrade, but there's no 2.34 in the archive :?
  <mborzecki> ijohnson: thanks!
  <zyga> Saviq: yes
  <Chipaca> mborzecki: https://launchpad.net/ubuntu/+source/snapd/2.34.2ubuntu0.1
  <Chipaca> mborzecki: perhaps look in security you did not
   * Chipaca yodas
  <mborzecki> Chipaca: heh, thanks!
  <Chipaca> mborzecki: fwiw i got there via googling 'snapd <version>'
  <mborzecki> Chipaca: hmmm, still no deb there either, thought the old versions are just kept behind
  <mborzecki> unless, it was pulled maybe?
  <ogra> or the user has -proposed permanently enabled
  <Chipaca> mborzecki: ? the link is right there
  <Chipaca> mborzecki: on the right, "builds"
  <Chipaca> mborzecki: amd64
  <Chipaca> mborzecki: https://launchpad.net/~ubuntu-security/+archive/ubuntu/ppa/+build/16332834/+files/snapd_2.34.2ubuntu0.1_amd64.deb
  <Chipaca> (and all the other debs we build)
  <mborzecki> Chipaca: right, there's where i downlaoded it from, but i'm not sure why it's not in archive.u.c or security.u.c pacakge pools
  <Chipaca> ahhh
  <Chipaca> mborzecki: because it got superseded, i assume
  <Chipaca> archive doesn't keep all old versions
  <Chipaca> huh, we don't restart snapd on removing the snapd snap
  <ogra> well, if you remove the snapd snap as a general user, you probably expect the deb to be gone too ?
  <Chipaca> well you'd be expecting wrong, then
  <mborzecki> Chipaca: --purge?
  <Chipaca> mborzecki: ?
  <mborzecki> Chipaca: duh, misread, it's the snapd snap
  <sergiusens> how do I deal with "error: cannot install snap file: snap "snapcraft" assumes unsupported features: snapd2.39 (try to update snapd and refresh the core snap)" but installing the snapd snap instead? I get "error: cannot install "snapd": cannot install snapd snap on a model without a base snap yet"
  <sergiusens> this is 16.04
  <sergiusens> and hello everyone
  <ogra> create a gadget for your install :P
  <ogra> (one thats base: core18 ... )
  <sergiusens> for my lxd container running a classic system?
  <ogra> (i wasnt serious)
  <zyga> sergiusens: install core
  <Chipaca> sergiusens: 1 sec
  <ogra> note that our classic installs all default us use core, not core18
  <sergiusens> good, I want to avoid installing core, snapcraft is on core18 and doesn't want to be installed
  <ogra> s/us/to/
  <sergiusens> zyga: so to install snapcraft I need to install core and core18?
   * ogra glares at his fingers
  <zyga> Yes
  <sergiusens> I went down this path as I was told the snapd snap fixed that
  <zyga> Until we ship snapd snap ootb
  <Chipaca> hold on
  <Chipaca> 1 sec
  <zyga> AFAIK it is not ready
  <Chipaca> sergiusens: can't you update your snapd package?
  <ogra> wouldnt that be snapd and core16 then, not core ?
  <Chipaca> sergiusens: otherwise, try this
  <sergiusens> Chipaca: I could add it to the work flow
  <Chipaca> sergiusens:  snap set system experimental.snapd-snap=true
  <zyga> ogra: it is not ready yet
  <Chipaca> sergiusens: then snap install snapd
  <ogra> zyga, yes, i got that ... but you'd not be using core in that scenario, right =
  <ogra> ?
  <Chipaca> zyga: snapd + core18 on classic works fine
  <sergiusens> Chipaca: ok, useful for play, but not to get out of this pickle :-)
  <Chipaca> sergiusens: what is your pickle?
  <Chipaca> sergiusens: as an aside: why are you running things on a 16.04 that is not up to date? :)
  <sergiusens> Chipaca: I build snapcraft with assumes command-chain, and 16.04 holding an older snapd
  <sergiusens> Chipaca: it is the latest minimal image
  <ogra> how could it "hold an older snapd" ? it re-execs into core
  <Chipaca> sergiusens: snapd 2.40 is in xenial-updates for quite a while now, but ok
  <ogra> (which should be auto-installed with your first snap)
  <sergiusens> Chipaca: yeah, the apt update proved that
  <Chipaca> sergiusens: and why does the 'snap set system' call not get you out of there?
  <sergiusens> Chipaca: oh, I read "experimental" and sort of hid from it
  <Chipaca> well, it's no longer experimental in a new enough snapd :)
  <zyga> Chipaca: there are still some issues in that setup
  <sergiusens> great then
  <Chipaca> zyga: what issues?
  <zyga> Chipaca: snapd tools directory injection into snap mount namespaces leads to stale tools over time
  <zyga> There is a topic forum describing this
  <zyga> Along with three proposals for solving it
  <zyga> Chipaca: I can find the link if you want to know more
  <Chipaca> zyga: you're mentioned in this thread, but dunno if you were aware (nor if you know what they're talking about): do you know what a 'readonly snapshot' means in this context? https://discourse.ubuntu.com/t/intent-to-provide-chromium-as-a-snap-only/5987/2?u=chipaca
  <Chipaca> and more importantly why would it trip up snapd
  <Chipaca> zyga: ah, link to the forum, d'oh
   * pstolowski lunch
  <ondra> sergiusens ping
  <ondra> sergiusens you might have regression in snapcraft which is in beta
  <ondra> sergiusens run snapcraft init and then add in snapcraft.yaml plug definition from here https://forum.snapcraft.io/t/the-content-interface/1074
  <diddledan> ondra: I suspect you'll need to state which of those plug definitions you're using - there's several on that page
  <ogra> details ...
  <mup> PR snapd#7617 closed: snap-confine.apparmor.in: harden pivot_root until we have full mediation <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/7617>
  <diddledan> ogra: details are the bane of our existence. down with details!
  <ondra> diddledan the very basic one https://paste.ubuntu.com/p/PpBrFGnMcf/
  <ondra> diddledan I get "Sorry, an error occurred in Snapcraft: argument of type 'NoneType' is not iterable"
  <diddledan> ooh, interesting
  <ondra> diddledan seems like missing tests
  <ondra> diddledan this should be caught during testing
  <diddledan> yes, it should :-)
  <ondra> diddledan essentially it breaks now every snap using content interface plug
  <ondra> diddledan true I'm on beta :)
  <zyga> mborzecki: small test https://github.com/snapcore/snapd/pull/7623
  <zyga> jdstrand: ^
  <mup> PR #7623: tests: check world-writable and test-owned files <Created by zyga> <https://github.com/snapcore/snapd/pull/7623>
  <mup> PR snapd#7623 opened: tests: check world-writable and test-owned files <Created by zyga> <https://github.com/snapcore/snapd/pull/7623>
  <zyga> AFAIK we discussed this a while ago
  <jdstrand> I'll take a look
  <zyga> thank you
  <sergiusens> ondra: thanks, we will look into it, adding the Sharing a C-level library ? I guess we are naively expecting a default to be defined.
  <ondra> sergiusens I used that example straight from our docs
  <ondra> sergiusens in snap it broke I was just sharing socket
  <ogra> because our docs are always correct indeed :)
  <ondra> sergiusens but I wanted to demonstrate it on official example
  <ondra> ogra :P
  <sergiusens> Chipaca: I know why there are no updates, policy today is that build images are based on -release with no -updates
  <sergiusens> ondra: that's fine, no worries, we made changes there so there most likley is a regression
  <sergiusens> Chipaca: so is the outcome to use the snapd snap or just install core?
  <ondra> sergiusens cool, thanks
  <jdstrand> zyga: ok, fixed your hook comment (good catch!). See https://github.com/snapcore/snapd/pull/7616#pullrequestreview-303088818 for discussion
  <mup> PR #7616: interfaces/many: allow k8s/systemd-run to mount volume subPaths plus cleanups <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7616>
  <zyga> jdstrand: thank you, I'll look soon
  <jdstrand> zyga: thanks, not urgent (just needs to be in 2.43 :)
  <jdstrand> huh
  <jdstrand> so, yesterday I dropped pulseaudio from chocolate-doom-jdstrand and used audio-playback instead (fine)
  <jdstrand> I pushed that to git, which built the snap, which pushed it to edge which updated on my laptop
  <jdstrand> $ snap connections chocolate-doom-jdstrand|grep pulseaudio
  <jdstrand> pulseaudio              chocolate-doom-jdstrand:pulseaudio              :pulseaudio              -
  <jdstrand> $ grep pulseaudio /snap/chocolate-doom-jdstrand/current/meta/snap.yaml
  <jdstrand> [1]
  <sergiusens> ondra: https://github.com/snapcore/snapcraft/pull/2754
  <jdstrand> so... pulseaudio is connected after the refresh even though the current revision does not plugs it
  <mup> PR snapcraft#2754: meta: support the case of a plug without a default provider <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2754>
  <jdstrand> zyga: this seems like a bug ^
  <mup> PR snapcraft#2754 opened: meta: support the case of a plug without a default provider <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2754>
  <zyga> jdstrand: aha
  <zyga> in standup now
  <zyga> jdstrand: can you clarify, even though the revision does not plug it?
  <zyga> jdstrand: are you referring to "snap connections" claiming there is a connection even though a plug or slot has been removed?
  <jdstrand> zyga: the 'current' revision (ie, 81) does not 'plugs: pulseaudio'. the previous revision did. when snapd refreshed the snap from the previous to the current, pulseaudio remains connected
  <zyga> I see
  <jdstrand> zyga: unsurprisingly, that is also true of 'snap interfaces'
  <jdstrand> zyga: the profile on disk correctly only has audio-playback in the snippets
  <jdstrand> zyga: I'm going to file a bug. someone can mark it Invalid if it is operating as designed
  <kjackal_v2> jdstrand: any hints on this:
  <kjackal_v2> apparmor="DENIED" operation="open" profile="snap.microk8s.daemon-cluster-agent" name="/proc/18749/mounts" pid=18749 comm="python3" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
  <kjackal_v2> it comes from a command executing a python script
  <kjackal_v2> am I missing an interface?
  <jdstrand> or maybe not... what's going on LP?
  <zyga> jdstrand: thank you for the bug
  <zyga> jdstrand: lp is a bit wonky recently
  <ogra> release day ...
  <zyga> jdstrand: are you seeing timeout errors?
  <ogra> it is busy at some release party i guess
  <ogra> (getting drunk and such)
  <zyga> kjackal_v2: you can use mount-observe to avoid it
  <kjackal_v2> cool, trying that now, thanks zyga
  <jdstrand> kjackal_v2: plugs mount-observe
  <jdstrand> zyga: I see nothing. all white
  <zyga> jdstrand: oh that's even more buggy :)
  <jdstrand> there we go
  <kjackal_v2> there must be a tool suggesting the interfaces based on denials. thank you
   * jdstrand writes his bug report in an editor to then paste in
  <jdstrand> kjackal_v2: snappy-debug
  <zyga> kjackal_v2: there's snappy-debug
  <ogra> kjackal_v2, it is called snappy-debug
  <ogra> bah, snap
  <zyga> but I think we could instead have a tree-like output of files and patterns and associated interfaces that grant access
  <kjackal_v2> woohoo, thank you
  <jdstrand> kjackal_v2: I don't know if you saw, but it is called snappy-debug ;)
  <kjackal_v2> snappy-what ???
  <jdstrand> :)
  <zyga> jdstrand: I think snapd could even make that output
  <zyga> jdstrand: even based on dynamically created interfaces
  <zyga> jdstrand: that would be pretty neat actualy
  <zyga> *actually
  <jdstrand> zyga: the problem is globs and weird things like dbus rules and things with peers, etc
  <jdstrand> zyga: for best results (that snappy-debug is not currently doing) we need to use logprof to aid in suggestions
  <zyga> Yeah but those are all doable
  <jdstrand> and logprof is py3
  <jdstrand> snappy-debug receives nearly no love and I would still consider it poc code
  <jdstrand> I mean, it works, but isn't perfect
  <zyga> brb
  <mup> PR snapd#7518 closed: cmd/snap: sort tasks in snap debug timings output <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7518>
  <jdstrand> zyga: what would be quite cool is for snappy-debug to be able to query snapd on the fly (perhaps using your output) to obtain the policy to base suggestions on
  <jdstrand> right now I have to dump the policy snippets to disk in a rather convoluted manner and ship those snippets in snappy-debug
  <jdstrand> which, again, 'works', but it gets out of date and there are some problems wrt implicitCore and implicitClassic
  <jdstrand> anyway, we could discuss this over lunch sometime. it isn't like any of this is resourced :)
  <roadmr> jdstrand: hey there - hope it's not too short-notice, I scheduled the kickoff for the review-tools stateful thing in 50 min
  <jdstrand> roadmr: that's fine. do note that I'm booked til the roadmaap sprint and won't personally be able to do much wrt this until likely after. possibly just before
  <pedronis> pstolowski: which should probably discuss this issue with enable because I still think there is either a small bug in snapd or in some snaps, probably next week at this point though
  <jdstrand> possibly...
  <jdstrand> roadmr: my understanding was this was a 'next cycle' thing (in fact, the base snap stuff I've communicated in the forum as early next cycle)
  <pedronis> pstolowski: I made a note
  <jdstrand> roadmr: that doesn't mean I can't attend the meeting, just trying to set expectations
  <roadmr> jdstrand: right, we can clarify that in a bit. Our plan is to feature-flag this so it's ready to go once the tools support it, so there's no pressure on you ideally
  <jdstrand> roadmr: ack
  <pstolowski> pedronis: ok
  <jdstrand> pstolowski: fyi, in 2.42 snap install is fast since we only do the apparmor_parser at the end, but snap remove runs the parser on each disconnect
  <jdstrand> pstolowski: I don't recall if that was intentional (ie, it is still a known todo)
  <jdstrand> pstolowski: but if it was unknown, now it is known
  <jdstrand> :)
  <jdstrand> pstolowski: hey btw :)
  <pstolowski> jdstrand: hi! yes and no, we know we have a few variants of ops that need their own treatment... btw i've next PR up - https://github.com/snapcore/snapd/pull/7601 ; but yes i haven't considered remove yet
  <mup> PR #7601: overlord/ifacestate: use SetupMany in setupSecurityByBackend <Created by stolowski> <https://github.com/snapcore/snapd/pull/7601>
  <pstolowski> jdstrand: so, thanks for pointing out
  <jdstrand> ack on that PR (had it in my todo)
  <jdstrand> 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>
  <jdstrand> zyga: the end of that report is bizarre
  <Chipaca> found the issue with brave
  <Chipaca> https://forum.snapcraft.io/t/small-problem-with-brave-browser/13743/6?u=chipaca
  <Chipaca> anybody know the brave devs? popey?
  <ogra> they used to be active on the forum when packaging it first
  <ogra> @posix4e on the forum it seems
  <Chipaca> ogra: thanks
  <ogra> :)
  <Chipaca> hm, last seen jan 27
  <Chipaca> hmm
  <ogra> yeah ... at least this year though :)
  <zyga> jdstrand: returning from lunch and looking
  <Saviq> Can't find this documented anywhere, does the store expire old revisions of software? What are the rules for that?
  <ogra> afaik the store never deletes anything ... and revisions are only wiped when new stuff comes in
  <ogra> (unless you manually unrelease/close channels etc)
  <Chipaca> Saviq: if you're the publisher you can still install the old revisions
  <Chipaca> e.g. i can snap install --revision=1 http
  <ogra> show off ...
  <Chipaca> wait, i lied, i can onlu install 14 and on
  <Chipaca> huh
  <Chipaca> Saviq: so maybe there's more to it than that and we should ask the store :-D
  <ogra> probably only revisions that have been published once ?
  <Saviq> well, multipass's revisions start with no. 700+ (at least as far as `snapcraft revisions` is concerned)
  <Saviq> why I'm asking is I'm considering edge/pr-123 branches for pull requests, but would not like those to live ad infinitum
  <Saviq> so if there are *some* rules for expiration, I'd be much happier :)
   * cachio lunch
  <popey> Chipaca: they haven't been active for ages
  <popey> We may have to re-home it
  <zyga> jdstrand: question about https://github.com/snapcore/snapd/pull/7623 -- it shows we actually do use wrong permissions
  <mup> PR #7623: tests: check world-writable and test-owned files <Created by zyga> <https://github.com/snapcore/snapd/pull/7623>
  <zyga> jdstrand: I made some changes to snap-confine where this test passes, do you think I should open that as a PR?
  <jdstrand> zyga: I have to step away but will circle back
  <zyga> ok
  <zyga> I'll commit and push it and give you a link
  <mup> PR snapd#7624 opened: snap: make `snap download` download via snapd if availalbe <Created by mvo5> <https://github.com/snapcore/snapd/pull/7624>
  <mup> PR snapd#7619 closed: image,seed: hide Seed16/Snap16, use seed.Open in image_test.go <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7619>
  <mvo> pedronis: yay
  <mvo> pedronis: ping me once this is merged into your other PR
  <pedronis> mvo: it is now
  <pedronis> #7595 is ready for review
  <mup> PR #7595: seed/seedwriter: support writing Core 20 seeds (aka recovery systems) <Created by pedronis> <https://github.com/snapcore/snapd/pull/7595>
  <mup> PR snapd#7625 opened: cmd/snap-confine: stop being setgid root <Created by zyga> <https://github.com/snapcore/snapd/pull/7625>
  <mup> PR snapd#7233 closed: interfaces/firewall-control: add nf_nat_* to kmod plug <Created by alfonsosanchezbeato> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7233>
  <mup> PR snapd#7626 opened: [RFC] managers: add remodel undo test for new required snaps case <Created by mvo5> <https://github.com/snapcore/snapd/pull/7626>
  <joedborg> hey ijohnson, do you happen to have the snapcraft.yaml for the docker snap you wrote?
  <ijohnson> joedborg: it's being maintained by tianon now on LP
  <joedborg> ijohnson: thanks!
  <ijohnson> joedborg: but anyways it's here : https://git.launchpad.net/~docker/+git/snap/tree/
  <joedborg> ijohnson: ah, nice, thanks.  just needed to "borrow" some bits :)
  <ijohnson> +1
  <mup> PR snapcraft#2741 closed: extensions: support using gjs from gnome runtime <Created by galgalesh> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2741>
  <jdstrand> zyga: can you take a look at this and bring it up in your standup: https://bugs.launchpad.net/snapd/+bug/1848567
  <mup> Bug #1848567: autogenerated per-snap snap-update-ns apparmor profile may contain many duplicate rules causing excessive parser memory usage <aa-parser> <AppArmor:New> <snapd:New> <https://launchpad.net/bugs/1848567>
  <jdstrand> cc pedronis ^
  <jdstrand> zyga (cc pedronis): that could be an easy performance win
  <jdstrand> I say 'easy' because it is no risk for production, but I realize there could be a lot of testsuite changes
  <mup> PR snapd#7627 opened: overlord: add checks for bootvars in TestRemodelSwitchToDifferentKernel <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7627>
  <ijohnson> jdstrand: I'll make sure it's discussed, that's could be a huge performance win it seems
  <jdstrand> ijohnson: yes, huge! and not just UC. eg, Ubuntu with preinstalled snaps on first boot could swap (or even OOM) due to this
  <ijohnson> yeah totally
  <jdstrand> ijohnson: the biggest number of dupes seems to be mostly around the content interface
  <jdstrand> layouts aren't too bad
  <jdstrand> at least anecdotally
  <ijohnson> yes it's quite odd because I have 3 graphical snaps on my system and they all have 17k line long snap-update-ns profiles and all the rest of my profiles are only about 100-200 lines
  <jdstrand> ijohnson: jjohansen mentioned to me that the issue is because mount rules don't have a quick and dirt second pass to pull out dupes
  <jdstrand> dirty*
  <ijohnson> but also all the graphical snaps use the content interface too
  <jdstrand> ijohnson: yes, exactly
  <jdstrand> ijohnson: I see that chromium ,discord, gedit, gimp, gnome-calculator, gnome-characters, gnome-logs, gnome-system-monitor, indicator-sensors, libreoffice, remmina, ...
  <jdstrand> ijohnson: you know, all the stuff no one uses :P
  <ijohnson> haha yeah :-O
  <oSoMoN> jdstrand, hey, until the voting period is over for https://forum.snapcraft.io/t/auto-connecting-the-personal-files-interface-for-the-chromium-snap-part-ii/13705, the chromium snap in the candidate channel is not installable. If IÂ wanted to publish unrelated bug fixes in the chromium snap, should IÂ simply revert the change to the personal-files plug temporarily, then add it back when auto-connection is granted?
  <jdstrand> oSoMoN: yes, that would be the best course. let me look at that request real quick
  <jdstrand> oSoMoN: let me look at the snapcraft.yaml. recall there is a review-tools change that is also needed
  <jdstrand> oSoMoN: I'd like to proactively add that ahead of the voting period expiration
  <oSoMoN> cool
  <jdstrand> oSoMoN: so your plan is to update the existing 'chromium-config' plug?
  <oSoMoN> jdstrand, yes, unless you advise otherwise
  <oSoMoN> the change is here:Â https://git.launchpad.net/~chromium-team/chromium-browser/+git/snap-from-source/commit/?id=ffd7ad54bca62c325f906014cd3b96bd2bcd2ee7
  <jdstrand> oSoMoN: in this case, I think that is fine. it also means I don't need to add anything to the review-tools
  <oSoMoN> even better
  <mup> PR snapcraft#2755 opened: extensions: kde-neon: add icon and sound themes <Created by galgalesh> <https://github.com/snapcore/snapcraft/pull/2755>
  #snappy 2019-10-18
  <mborzecki> morning
  <mup> PR snapd#7621 closed: spdx: add EPL-2.0 to licenses <Created by ralight> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7621>
  <mborzecki> mvo: hey
  <mvo> hey mborzecki
  <mup> PR snapd#7609 closed: snap-recovery: remove "usedPartitions" from sfdisk.Create() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7609>
  <mup> PR snapd#7620 closed: snap-install: add ext4,vfat creation support <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7620>
  <mvo> 7613 is ready for review now, pretty small and hopefully simple :)
  <mborzecki> mvo: so are we going with snap-recovery instead of recovery-tool, or will the former just stay an internal/testing thing for now?
  <mvo> mborzecki: hope I understand the question but snap-recovery is the new name of recovery-tool, recovery-tool is a bit too generic (iirc that was what was the outcome of the code review earlier)
  <mborzecki> mvo: ah ok, missed that
  <mvo> mborzecki: there should be no recovery-tool anymore unless I overlooked something :)
  <mup> PR snapd#7627 closed: overlord: add checks for bootvars in TestRemodelSwitchToDifferentKernel <Simple ð> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7627>
  <pstolowski> morning
  <mvo> hey pstolowski
  <zyga> re
  <zyga> hey guys
  <zyga> feeling somewhat better, working from office now
  <zyga> resuming work on /etc -> /var move
  <mup> PR snapd#7628 opened: gadget: helper for volume compatibility checks <Remodel :train:> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7628>
  <mborzecki> mvo: ^^
  <mborzecki> pstolowski: zyga: hey
  <mvo> mborzecki: nice one
  <mvo> zyga: hey ! glad to hear that you feel better
  <zyga> mvo: thanks
  <pedronis> mborzecki: hi, btw now that claudio changes have landed #7509 should be unblocked ?
  <mup> PR #7509: gadget, snap/pack: perform extended validation of gadget metadata and contents <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7509>
  <mborzecki> pedronis: yes
  <zyga> mvo: check this out
  <zyga> https://www.irccloud.com/pastebin/Kpa4yYyI/
  <mborzecki> zyga: hm maybe snapd.failure.service ran and exited between the is-active calls?
  <zyga> that's a good hunch
  <zyga> perhaps it should stay-after-exit?
  <zyga> or leave a trace that the test can reliably check for
  <mup> PR snapd#7629 opened: snap-recovery: create filesystems as defined in the gadget <Created by mvo5> <https://github.com/snapcore/snapd/pull/7629>
  <mborzecki> osx jobs fail on travis?
  <zyga> mborzecki: I didn't see any failures, what did you get?
  <mborzecki> zyga: jobn fails, 10 minutes with no output, as if nothing got really executed
  <zyga> hum
  <zyga> I've submitted some changes so I will likely see that soon
  <zyga> but no output is a big hard to debug
  <zyga> macos has abandoned bash and switched to zsh
  <zyga> maybe that's a factor?
  <mborzecki> really?
  <mborzecki> wonder why
  <zyga> gpl
  <zyga> they never upgraded past gpl 2.0 licensed version
  <zyga> there's nothing gpl 3.0 on macos
  <mborzecki> duh
  <mborzecki> at least they didn't go with tcsh :P
  <zyga> mash :)
  <pedronis> mvo: so I'm ready to submit seed/seed20 code and the basics of using it for firstboot, but I need reviews otherwise it will just be huge diffs
  <zyga> mvo: question on your policy branch https://github.com/snapcore/snapd/pull/7615/files#r336367270
  <mup> PR #7615: policy: implement CanRemove policy for the snapd type <Created by mvo5> <https://github.com/snapcore/snapd/pull/7615>
  <pedronis> I'll have a break and then switch to doing reviews
  <mvo> zyga: sure, I have a look
  <mvo> pedronis: will review your PR in a little bit
  <Chipaca> ð
  <Chipaca> just to note I'm not working today :-)
  <Chipaca> did I say note? I meant 'gloat'
  <zyga> Chipaca: are you okay?
  <pedronis> zyga: what's the status of #7547 ? does it need Jamie's review?
  <mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
  <zyga> pedronis: I asked for someone from security (jamie or alex) to review it
  <zyga> jamie had a look and mentioned the idea is sound (on IRC)
  <zyga> but there's no full review from him yet
  <zyga> I think it would be good to have one though it's all entirely behind a feature flag so we might land it without a review assuming we get one later
  <zyga> I have more code depending on this landing so moving it would unblock me
  <zyga> mborzecki: reviewed https://github.com/snapcore/snapd/pull/7628#pullrequestreview-303746745
  <mup> PR #7628: gadget: helper for volume compatibility checks <Remodel :train:> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7628>
  <mborzecki> thx
  <mvo> thanks zyga !
  <zyga> mvo: small review for you https://github.com/snapcore/snapd/pull/7626#pullrequestreview-303758751
  <mup> PR #7626: [RFC] managers: add remodel undo test for new required snaps case <Created by mvo5> <https://github.com/snapcore/snapd/pull/7626>
  <mvo> zyga: happy to discuss this in a bit, fwiw we use similar style in snapstate and wrappers, it seems to be ok if "f() (err error)" style is used - or am I misreading/misunderstanding?
  <zyga> mvo: it's still easy to define another err
  <zyga> mvo: I know we are using this style
  <zyga> but if we are going to rely on it I think it's a bit too fragile
  <pedronis> zyga: it's a bit more subtle
  <mvo> zyga: you mean if someone defines does "return err2" ?
  <pedronis> the return do an assignment afaiu
  <mvo> yeah, that is my understanding as well, so I wonder if I miss something
  <pedronis> zyga: see, this code  https://play.golang.org/p/gzUa03a0ET7
  <zyga> mvo: I could be wrong but last time I was doing it I had unexpected results from foo, err := ... style code even if err was defined
  <mvo> zyga: this case will work, I can add some test for this later
  <mvo> zyga: but in the middle of a review right now so I don't want to switch too much context :)
  <mvo> zyga: aha, pedronis was kind enough to add the pastebin
  <mvo> eh, play
  <pedronis> zyga: is the this bit of the spec: A "return" statement that specifies results sets the result parameters before any deferred functions are executed.
  <pedronis> https://golang.org/ref/spec#Return_statements
  <zyga> pedronis: that's interesting, I didn't know that
  <zyga> I was trying to craft something nefarious in the playground but could not
  <mvo> zyga: we could add a comment to this kind of code to ensure ppl are not nervous about it
  <pedronis> there are still some ways to get this idiom wrong:
  <pedronis> not defining err in the return type, but have some early err := but using the idiom anyway somehow
  <pedronis> some path that errors but returns nil to the caller (but still hope to get the undoing working)
  <pedronis> mvo: thanks for the review, I asked a question about one of your questions :)
  <zyga> I'll be back soon,
  <zyga> it's so cold in the office nowadays
  <zyga> I should turn more computers on
  <zyga> (heating is on but the office has weaker heat insulation compared to the rest of the house)
  <mvo> pedronis: thanks, I replied
  <pstolowski> yay, got the cloud image firstboot working end-to-end with pre-baked image \o/
  <pstolowski> now onto open points.. system key, gadget configure hook..
  <zyga> pstolowski: nice milestone :)
  <pedronis> mvo: couple of comments in 7626
  <mvo> pedronis: thank you
  <pedronis> pstolowski: great
  <mup> PR snapd#7548 closed: tests: update snap logs to match for multiple lines for  "running" <Created by sergiocazzolato> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7548>
  <mvo> pedronis: thanks for your suggestions, I will update the undo PR accordingly, much simpler this way :)
  <mup> PR snapd#7630 opened: overlord/devicestate: check snap handler for gadget remodel compatibility <Remodel :train:> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7630>
  <mborzecki> mvo: pedronis: ^^
  <mup> PR snapcraft#2754 closed: meta: support the case of a plug without a default provider <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2754>
  <mvo> mborzecki: thanks, looking
  <zyga> mborzecki: https://github.com/snapcore/snapd/pull/7630#pullrequestreview-303818422
  <mup> PR #7630: overlord/devicestate: check snap handler for gadget remodel compatibility <Remodel :train:> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7630>
  <zyga> mvo: is https://github.com/snapcore/snapd/pull/7613 already minimal or would merging master shrink it?
  <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>
  <zyga> mborzecki: can you do a pass over https://github.com/snapcore/snapd/pull/7614 as well
  <mup> PR #7614: cmd/snap-confine: implement snap-device-helper internally <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>
  <mvo> zyga: its already minimal, I merged master this morning
  <zyga> mvo: thanks, I'll review it then
  <zyga> mvo: I only asked because it said it is based on something and I wasn't sure
  <mvo> zyga: ta
   * pstolowski lunch
   * zyga break as well
  <zyga> mvo: I'll finish the review soon
  <mvo> zyga: no worries, I have lunch now
  <zyga> mvo: https://github.com/snapcore/snapd/pull/7629#pullrequestreview-303823599 :)
  <mup> PR #7629: snap-recovery: create filesystems as defined in the gadget <Created by mvo5> <https://github.com/snapcore/snapd/pull/7629>
  <mup> PR snapd#7628 closed: gadget: helper for volume compatibility checks <Remodel :train:> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7628>
  <zyga> LXD test is failing a few times today
  <mborzecki> pedronis: updated #7509
  <mup> PR #7509: gadget, snap/pack: perform extended validation of gadget metadata and contents <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7509>
  <pedronis> jdstrand: hi, I made a meta comment in the system-backup PR, you probably know but you have quite few snapd PRs asking your review
  <jdstrand> pedronis: thanks, yes, going to get through as many as I can today
  <mborzecki> off to pick up the kids, or i'm gonna be late for standup
  <jdstrand> mvo: hey, others said they would bring this up in your standup, but fyi bug #1848567
  <mup> Bug #1848567: autogenerated per-snap snap-update-ns apparmor profile may contain many duplicate mount rules causing excessive parser memory usage <aa-parser> <AppArmor:New> <snapd:New> <https://launchpad.net/bugs/1848567>
  <zyga> oh
  <jdstrand> zyga: oh, did you not see backscroll from after you eod'd?
   * jdstrand gathers
  <zyga> nope
  <zyga> I didn't read any
  <jdstrand> zyga: https://paste.ubuntu.com/p/NKFGsZtBZN/
  <zyga> jdstrand: thanks
  <zyga> jdstrand: I think there is an "easy" way to solve this
  <zyga> jdstrand: I can give it a try
  <zyga> jdstrand: we can de-duple in the apparmor spec
  <zyga> *de-dupe
  <zyga> jdstrand: and simply change how we emit lines for the offending rules
  <jdstrand> zyga: please only dedupe in snap-update-ns profiles though
  <zyga> jdstrand: I'll try
  <zyga> jdstrand: though
  <zyga> jdstrand: I think it'd be good to do globally
  <jdstrand> zyga: I do not
  <zyga> jdstrand: we can have some code that emits # line if line was already added
  <zyga> jdstrand: why?
  <zyga> jdstrand: doing it in a specific profile would create a special case
  <zyga> jdstrand: so more complexity to test
  <jdstrand> zyga: snap-update-ns is auto-generated so we need to make sure it is clean. the handcrafted snippets will have few duplicates and removing them will have essentially no performance gain but cause confusion in debugging and auditing
  <zyga> jdstrand: it depends on how it is done, we can keep the duplicated lines, just comment them out
  <pedronis> I agree with jdstrand that it will get confusing for debugging
  <Saviq> is there documentation somewhere about the acls I can give to `snapcraft export-login`?
  <zyga> pedronis: it's hard to say if it is confusing before we see it
  <pedronis> zyga: heh
  <pedronis> you are copying something into something else
  <pedronis> except removing some bits
  <jdstrand> zyga: please note the problem is that the parser doesn't (currently) have a cheap dedupe for mount rules. all others are dedupes fast. we just need to make sure the auto-generated profiles doesn't balloon
  <pedronis> depending on mixing of things
  <pedronis> that sounds confusing
  <pedronis> a priori
  <zyga> pedronis: I think you are confused by what I'm trying to do
  <zyga> jdstrand: sure, I understand the problem
  <pedronis> zyga: I expect every line from a template to end up in the final profile atm
  <pedronis> it sounds you want to change that
  <jdstrand> zyga: the commented out idea is better than removing, but we don't want that. why have 17000 commented out lines?
  <zyga> jdstrand: for the audit you wanted?
  <zyga> pedronis: I don't want to change anything related to the template
  <zyga> pedronis: or parse anything for that matter
  <pedronis> zyga: you are changing the relation between template content and output
  <jdstrand> zyga: I am talking about *auto-generated* rules. for templated policy with snippets, we  should have everything
  <zyga> pedronis: yes, but that is unavoidable, we must change something to get less output
  <pedronis> zyga: yes, but only for autogenerated stuff
  <zyga> jdstrand: sure, but I never intended to change the template here
  <zyga> pedronis: yes, that's what I was proposing
  <zyga> anyway, I think code speaks clearer than english
  <pedronis> zyga: so I'm not confused, but both me and jdstrand are saying no to that
  <zyga> I will have a look
  <zyga> and we can discuss it then
  <jdstrand> zyga: but you did say that you would dedupe snap.* profiles, not just snap-update-ns.*. snap.* aren't autogenerated
  <pedronis> zyga: please discuss with mvo how to prioritize this
  <zyga> jdstrand: my idea is to dedupe snippets
  <zyga> jdstrand: nothing more
  <zyga> jdstrand: this idea is super simple, it only depends on how we send mount rules as snippets
  <zyga> jdstrand: instead of sending one big block of unique text
  <jdstrand> zyga: snippets are also not autogenerated rules
  <zyga> jdstrand: we can send each mount rule
  <zyga> jdstrand: snippets are just that, the contets is auto generated or not
  <jdstrand> zyga: or rather, the ones in interfaces/builtins are not autogenerated
  <zyga> jdstrand: if we change the content permissions to generate each mount rule as a snippet
  <zyga> (actually we may already have deduplication in the snippets)
  <jdstrand> zyga: there is a difference between snapd calculating individual rules and adding them and snapd splatting out templated snippets
  <zyga> jdstrand: so instead of sending one, say, ten line snippet
  <zyga> jdstrand: we can send ten snippets
  <zyga> jdstrand: and if the next directory rule sends the 9 snippets that are the same
  <zyga> jdstrand: and one that is different
  <zyga> jdstrand: we end up with just 11 snippets now
  <zyga> jdstrand: as I said above, I don't intend to parse or split snippets that are provided to the spec
  <zyga> jdstrand: just be smarter about the snippets that we add to the spec in this case
  <jdstrand> zyga: there are implementation ideas that can be done to dedupe. that is fine. I'm saying that at the end of it all, we should have deduped snap-update-ns policy, but snap.* policy is character by character identical
  <jdstrand> to what we have now
  <zyga> jdstrand: I think I see your point but I don't think we should be this strict about this, this kind of approach introduces special cases that are error prone. I don't think we have any duplication in snap profiles today. Having said that I would not like to if-then-else this special case
  <jdstrand> zyga: it doesn't feel that hard. add a flag if and set it to true if generating snap-update-ns
  <zyga> jdstrand: btw, how did you run into this?
  <zyga> jdstrand: is there a simple test where we can measure the memory used by apparmor parser?
  <pedronis> jdstrand: agreed
  <jdstrand> zyga: people (including myself) were seeing OOMs in Ubuntu vms
  <jdstrand> zyga: did you read the bug? :)
  <zyga> jdstrand: I didn't notice the -f mem thing there, I read the summary only
  <zyga> jdstrand: I will look at adding a test that checks if the memory used by apparmor parser on a specific profile is not unreasonable
  <zyga> (though as with all "benchmark" style tests, it's not a clear-cut what is reasonable)
  <jdstrand> zyga: btw, there is duplication in the snap.* profiles today, but it is small and unimportant for performance and memory
  <jdstrand> zyga: that will be difficult and dependent on how many cpus you have
  <zyga> jdstrand: I would imagine a test that loads one specific profile should not depend on that
  <zyga> jdstrand: (load profile one by one, check that memory used by apparmor parser is << than some sane value)
  <zyga> (with the right arguments to force skipping cache to see the actual cost)
  <jdstrand> zyga: one profile no, but that is artificial with pstolowski's patches to load all of the snaps profiles with one parser invocation. it might be ok, but I don't know what a good number is. it is definitely less than 1.5G :)
  <zyga> jdstrand: btw, why is apparmor parser not de-duplicating mount rules?
  <jdstrand> zyga: that is in the bug :)
  <zyga> jdstrand: yeah, for sure, I need to see
  <jdstrand> zyga: it is a bug in apparmor_parser. it should be
  <zyga> I see
  <zyga> ok
  <zyga> mvo: can you triage https://bugs.launchpad.net/snapd/+bug/1848567 :)
  <mup> Bug #1848567: autogenerated per-snap snap-update-ns apparmor profile may contain many duplicate mount rules causing excessive parser memory usage <aa-parser> <AppArmor:New> <snapd:New> <https://launchpad.net/bugs/1848567>
  <jdstrand> zyga: but even if that was fixed, 17000 auto-generated rules need to be fixed
  <zyga> jdstrand: it looked good when we were writing it ;)
  <zyga> jdstrand: precise and all that
  <zyga> but yeah
  <jdstrand> that is impossible to read, audit and too much disk
  <pedronis> mborzecki: I don't understand why we need volumes for classic gadgets now in #7509
  <mup> PR #7509: gadget, snap/pack: perform extended validation of gadget metadata and contents <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7509>
  <zyga> jdstrand: perhaps we should not be this precise
  <jdstrand> zyga: well, I think things are pretty 'ok' with a single content interface. but the pattern in the filed is multiple content interfaces like with gnome-calculator
  <pedronis> mborzecki: commented there
  <jdstrand> zyga: we are precise for a reason. just dedupe: we are then precise and small
  <jdstrand> the file ends up being <700 lines (with comments) after deduped. that is totally fine
  <jdstrand> (for gnome-calculator that is)
  <jdstrand> memory is inline with all our othe profiles
  <jdstrand> time to compile too
  <jdstrand> it's a cheap win with no production risk since the rules loaded into the kernel are exactly the same as the 17000 line profile
  <zyga> jdstrand: because of apparmor parser DFA miminalization?
  <jdstrand> zyga: yeah
  <ijohnson> jdstrand: well looks like you got your bug discussed before I even had a chance to mention it :-)
  <jdstrand> zyga: there is an expensive dedupe stage and a cheap one. the cheap one is missing for mount in the parser.
  <zyga> yeah, I think I understand how the parser is ending up working this way
  <jdstrand> zyga: the idea is, do the cheap one then the expensive.
  <zyga> state machine transformations are expensive, especially the minimalization that results in exponential states
  <jdstrand> ijohnson: heh, it was good. now people know where everyone stands and the discussion in the standup can perhaps be more productive, shorter and about resourcing
  <ijohnson> +1
  <ijohnson> oh btw I still have a todo to look into stopping pivot_root for containerd, is that still necessary/relevant (cc joedborg)
  <mborzecki> pedronis: heh, right, leftover from the initial version of the pr
  <ijohnson> jdstrand: ^
  <pedronis> ijohnson: hi, I did a pass on the disabled services PRs
  <joedborg> ijohnson: Iâve tried with setting `no_pivot` to true but am still getting the app armor violations on the file system
  <jdstrand> ijohnson: kjackal is who wanted it (but I'm sure joedborg is interested too), but yes, kjackal saw prometheus had a similaar issue. I'll let him comment further
  <jdstrand> ijohnson: if you don't mind that is
   * kjackal reading
  <jdstrand> zyga: fyi, sha256sum for big vs deduped cache files: https://paste.ubuntu.com/p/YFCkGZysk2/
  <zyga> jdstrand: how did you dedupe?
  <ijohnson> pedronis: I saw that thanks
  <jdstrand> zyga: it is in the bug ;) I sort -u then put the preamble lines and the } in the right spot
  <zyga> jdstrand: +1
  <zyga> thanks
  <zyga> yeah, this is expected
   * jdstrand nods
  <kjackal> ijohnson: joedborg is probably the best to comment on this. The only thing I can say for sure is that we see issues with a number of workloads some of which are probably due to patches mising from containerd.
  <jdstrand> just wanted to prove that the kernel blob is the same. no reason to change our rules
  <ijohnson> jdstrand, kjackal, joedborg: ack I'll still take a look at it then. btw which snap is this for, the kubernetes-worker snap? I can't seem to find it on github anymore, I thought it was somewhere in https://github.com/charmed-kubernetes/bundle
  <jdstrand> ijohnson: https://github.com/charmed-kubernetes/snap-kubernetes-worker is kubernetes-worker
  <ijohnson> thanks jdstrand
  <jdstrand> ijohnson: https://github.com/ubuntu/microk8s/ is microk8s
  <joedborg> ah thanks jdstrand
  <jdstrand> ijohnson: (though I don't know where kjackal's strict mode branch is currently living)
  <jdstrand> otoh
  <kjackal> It is here https://github.com/ubuntu/microk8s/tree/feature/strict-v3
  <ijohnson> thanks everybody, will try to look into this soon
  <jdstrand> zyga: so, for the benchmark, /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -QTK -o benchmark.cache profile
  <jdstrand> zyga: actually, just to be 100% consistent: /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -j1 -QTK -o benchmark.cache profile
  <mup> PR snapd#7562 closed: tests: check the apparmor_parser when the file exists on snap-confine test <Simple ð> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7562>
  <jdstrand> zyga: where profile is something akin to what gnome-calculator has (eg, multiple content plugs). maybe put memory at under 50000 and time at under 1 second?
  <zyga> jdstrand: thank you, I'll make sure this is tested
  <jdstrand> zyga: you might have to play with those thresholds. the deduped profile was ~32M here and < .5 seconds
  <jdstrand> here
  <zyga> jdstrand: I think I will put the threshold at 512M
  <zyga> if we needed more mem we will fail on some supported systems
  <jdstrand> zyga: maybe make sure it is < 1000? line? (it was 662 here)
  <zyga> but I need to sit down and code it first
  <zyga> most likely next week as we won't release over weekend anyway
  <jdstrand> zyga: soryy, 50000 was in k. that is 50M
  <jdstrand> zyga: 'time' uses 'k' but then I used 'm' in later comments. 50M as the upper limit initially sounds good
   * jdstrand tests on arm64 and armhf real quick
  <zyga> jdstrand: I'm only grumpy that nobody raised this during 19.10 beta
  <zyga> jdstrand: we could have fixed it for that release
  <zyga> jdstrand: but that's why I want to do a test
  <jdstrand> zyga: it isn't a 19.10 thing
  <zyga> jdstrand: so that next time we won't be burned by accident
  <zyga> jdstrand: oh I know
  <zyga> but it JUST SHIPPED and nobody noticed before :)
  <jdstrand> zyga: oh I see what you mean
  <jdstrand> zyga: yes, well, at least it was found by us rather than the field blowing up
  <zyga> jdstrand: well, the field may still blow up :)
  <jdstrand> zyga: but, for sure classic distro is feeling this and don't know it
  <jdstrand> zyga: most desktop system probably have 1.5G ram and swap these days, and it is desktop system that hit the pathological multiple content interface case
  <zyga> jdstrand: yeah
  <jdstrand> zyga: so OOM won't usually be hit unless other things are going on
  <zyga> jdstrand: if you want to review it today I may look at a quick PR after standup
  <zyga> jdstrand: if you are fine waiting it will be done next week
  <jdstrand> but, they could crawl with swap and be a bit slow
  <jdstrand> zyga: yes. I am off Mon and Tue. 2.43 material is fine
  <zyga> jdstrand: oh
  <zyga> hmmm
  <jdstrand> zyga: I'm going to try to get through all the PR reviews today
  <zyga> perhaps a quick iteration today is better
  <zyga> well, I'll leave that to you
  <zyga> otherwise I will resume reviews
  <zyga> and try to finish a bugfix for apparmor in another area
  <zyga> (the one with the include file)
  <jdstrand> zyga: 2.43 wasn't even branched yet as of... yesterday? wed?
  <zyga> I don't know the status of the release
  <zyga> sorry
  <jdstrand> that's fine. next week is fine. please discuss priority in standup (and feel free to relay I'm reviewing today and off Mon and Tue if that is useful)
  <jdstrand> zyga: ^
  <zyga> ok
  <jdstrand> zyga: a not nearly as important bug that I can't recall if I forwarded to you: 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>
  <jdstrand> zyga: oh, I did. I was really surprised remove/install still showed it as connected :)
  <jdstrand> erf, 'time' isn't in UC
  <ogra> jdstrand, lies ... my UC16 has it :P
  <jdstrand> ogra: /usr/bin/time?
  <ogra> ah, no, the shell builtin
  <jdstrand> (it is also a shell builtin, but that isn't what I want)
   * jdstrand nods
  <jdstrand> using classic snap
  <jdstrand> ogra: I totally forgot how handy /usr/bin/time is
  <ogra> haha, yeah
  <jdstrand> the builtin is all I think I've used for years :)
  <ogra> oh, it actually even comes from its own deb
  <ogra> i thought it is part of coreutils
  <jdstrand> huh, me too
  <jdstrand> zyga: oh, /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -QTK -Ono-expr-simplify -j1 -o cache profile
  <jdstrand> zyga: (forgot -Ono-expr-simplify)
  <jdstrand> zyga: armhf: wall: 0:00.24, mem: 3472 Kb
  <jdstrand> zyga: arm64: wall: 0:00.45, mem: 5392 Kb
   * jdstrand moves along
  <ogra> heh, thats the same binary you call on armhf and arm64 i guess ?
  <ogra> (surprising it isnt 2x the memory size but only 1.5 or so ... )
  <ijohnson> hey Chipaca got a question yesterday about store connections from snapd... is there a single global timeout we set for all connections to the store? and if there is, can a user adjust that timeout?
  <mup> PR snapd#7574 closed: client: add KnownOptions to Know() and support remote assertions <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7574>
  <pedronis> ijohnson: John is off today,  we have a couple of timeouts and retry strategies, they are not user configurable atm
  <ijohnson> ah okay, thanks pedronis
  <mvo> 7622 is now also ready for a review
  <mvo> zyga: hm, it looks like I did not look closely enough, 7613 was the smallest snap-recovery PR in flight right now, I will apply your feedback to the other to this one. sorry that I overlooked this earlier
  <zyga> mvo: no worries :)
  <pedronis> mborzecki: re-reviewed 7509
  <mborzecki> pedronis: thanks
  <jdstrand> pedronis: hey, those snap-ids, they were for all stores, correct?
  <pedronis> jdstrand: yes
  <jdstrand> thanks
  <zyga> jdstrand: I think it works
  <zyga> jdstrand: have a look https://usercontent.irccloud-cdn.com/file/FB0h24Ik/deduped-update-ns-profile
  <zyga> I need to adjust tests but it's simple enough
  <zyga> but firstd
  <zyga> foood :D
   * zyga had only breakfast and it's almost 5PM
  <jdstrand> zyga: yikes. that happened to me yesterday :\
  <zyga> as a super-cheap approach for now until tests pass
  <zyga> jdstrand: diff that makes it go  https://www.irccloud.com/pastebin/TCWMioYP/
  <zyga> it relies on spec.AddUpdateNS() de-duplicating already
  <zyga> ok, time for that food
  <joeubuntu> hey all - looking for a pointer. I've heard tales of a scenario where snaps can be built by pulling source down from github. Is there a link you can share so I can read up on it? I have not been able to find it with the googles.
  <joeubuntu> i.e. I'd somehow modify my snapcraft.yaml to git clone my repo? Is that a thing or do I misunderstand the feature?
  <ijohnson> joeubuntu: do you mean you have a snapcraft.yaml source on github you want to be built into a snap? or you just want to include some github repo in your snap?
  <ijohnson> joeubuntu: we have build.snapcraft.io which will automatically re-build your snap when you push to the github repository and publish the built snap into the edge channel
  <joeubuntu> ijohnson that is the goal!  right now I just copy my files in to ~/snap/snapName/snap/files
  <ijohnson> hmm I guess I didn't quite follow which thing is the goal :-)
  <joeubuntu> I want to use build.snapcraft.io , so thanks !
  <ijohnson> joeubuntu: ah okay cool, feel free to let us know if you can't get it setup
  <ogra> oh, so interesting (and i have never noticed that before ...)
  <ogra> $ du -hcs /usr/lib/chromium-browser
  <ogra> 230M	/usr/lib/chromium-browser
  <ogra> $ ls -lh /var/lib/snapd/snaps/chromium_881.snap
  <ogra> -rw------- 1 root root 156M Okt 11 03:00 /var/lib/snapd/snaps/chromium_881.snap
  <ogra> oSoMoN, why the heck dont we blog left and right about this ^^^ :)
  <ogra> (i just had another "snaps are too big" discussion with someone ... and actually checked the sizes for the first time ... what a surprise :)
  <ijohnson> ogra: maybe popey should update that blog post?
  <ogra> well, its a bit unfair given you have 3 copies with the snap ... so you lose the advatage in the end again ... but the fact alone that the snap itself is 80M smaller is definitely not well known among the haters (and their parrots)
  <joeubuntu> Sorry for all the question... now that I am using build.snapcraft.io what does my snapcraft.yaml have to look like ? prior to using b.s.io I manually copied my files in to files/bin/* ?  In the repo they are just in the root.  I imagine I need to just update wrapper: source: to / and change the command from bin/foo to /foo ?
  <ijohnson> joeubuntu: so you have some files that are just on your mahcine's filesystem that need to be in the snap? if it doesn't make sense to put those files into your git repository, then you usually would either build those files inside a part in your snapcraft.yaml or upload those files somewhere and use the dump plugin in snapcraft with a source pointing to wherever you uploaded those files
  <ijohnson> does that make sense?
  <zyga> re
  <joeubuntu> ijohnson thanks,  I'll poke around. Thanks for the tips!
  <popey> ijohnson: I'm on vacation. Please email if there is something that needs my attention. Ta
   * ogra hugs popey ... no action needed enjoy holiday beers !
  <ijohnson> popey: enjoy the vacation! do something fun and stop checking notifications :-)
   * cachio lunch
  <oSoMoN> ogra, yeah, IÂ wrote about it at some point to answer one of those "snaps are big" claim
  <oSoMoN> to be fair, that's quite the exception, snaps do tend to be bigger than their deb counterparts
  <oSoMoN> which is totally normal, given that they embed their dependencies
  <mvo> zyga: I addressed some of the feedback in 7629 in 7613, probably best to focus on 7613 for now and once that landed I will work on the remaining bits in the other one
  <zyga> mvo: cool, I'll finish the de-dupper for jdstrand and look
  <mvo> zyga: I still need to look at how not-to-install snpa-recover on rpms :/ but I'm running out of time for today
  <zyga> mvo: rm -f works :)
  <zyga> mvo: porting it to use snapd.mk also works
  <zyga> mvo: in snapd.mk there's a section for things that are removed if we are packaging for a classic distribution
  <zyga> mvo: thank you for looking into this :)
  <ogra> oSoMoN, indeed
  <mvo> zyga: ok, feel free to just do it and push while I'm away but I will try to get to it later tonight
   * mvo waves
  <zyga> mvo: I won't have time, I will finish this bug and work on a test
  <mup> PR snapd#7631 opened: interfaces/pulseaudio: adjust to manually connect by default <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7631>
  <pedronis> jdstrand: what's the status of #7228 ?
  <mup> PR #7228: interfaces: add audio-playback/record and pulseaudio spread tests <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7228>
  <jdstrand> pedronis: that is next up after I do PR reviews and store reviews, so, for next week
  <jdstrand> pedronis: but for 2.43 for sure. disco has the changes needed to actually write those tests now, so I can move forward
  <pedronis> jdstrand: ok, thanks for the update
  <jdstrand> pedronis: fyi, I talked with kenvandine and he said that the desktop team will hopefully have the sru done for bionic and xenial (see https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1781428)
  <mup> Bug #1781428: please enable snap mediation support <patch> <pulseaudio (Ubuntu):Fix Released by jamesh> <pulseaudio (Ubuntu Xenial):Triaged by jamesh> <pulseaudio (Ubuntu Bionic):Triaged by jamesh> <https://launchpad.net/bugs/1781428>
  <jdstrand> pedronis: all the necessary dependencies are SRU'd, so just need the pulseaudio patch (though there may be a snapd-glib bug that needs fixing on xenial)
  <kenvandine> jdstrand: that reminds me to check on that :)
  <jdstrand> pedronis: I mention that because if it is SRUd before 2.43, I can adjust the aforementioned spread test to also include xenial and bionic rather than just disco (and now that I think of it, eoan)
  <jdstrand> kenvandine: thanks :)
  <jdstrand> popey, Wimpress: is there anything besides snapcraft-desktop-helpers and electron-builder that might templatize snapcraft.yaml/snap.yaml to include pulseaudio?
  <zyga> jdstrand: ok, I have a fix
  <zyga> jdstrand: I'll work on a perf test now
  <mup> PR snapd#7632 opened: interfaces/apparmor: avoid excessive repetition of snap-update-ns mount rules <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>
  <popey> jdstrand: we are both on holiday, please email or forum thread
  <zyga> jdstrand: https://github.com/snapcore/snapd/pull/7632
  <mup> PR #7632: interfaces/apparmor: avoid excessive repetition of snap-update-ns mount rules <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>
  <zyga> jdstrand: if you don't mind I'll EOD now but watch for your feedback
  <zyga> jdstrand: I can implement the spread test that checks for memory usage next week
  <zyga> jdstrand: I wanted to ack the main part with you
  <zyga> jdstrand: namely changes to apparmor.Specification.AddUpdateNS
   * zyga EODs and waits for jdstrand's input passively 
  <jdstrand> zyga: thanks! I've got a bunch of PRs enqueued ahead of that so may not get to it today
  <zyga> jdstrand: boo ;-)
  <zyga> jdstrand: can you just ack 3 line diff then
  <zyga> jdstrand: (or not ack)
  <zyga> that's the essence
  <zyga> https://github.com/snapcore/snapd/pull/7632/files#diff-8d0225478e724e1ef6689c6f12feac06L184
  <zyga> this one
  <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> I just realized this is just the layout part, not the content part
  <zyga> shoo
  <zyga> anyway, that's that
  <jdstrand> zyga: I'm going to want to really examine it and not rush it to make sure we end up with identical cache files
  <zyga> jdstrand: note, you don't have to approve it
  <zyga> jdstrand: just disapprove if the approach is too simple
  <zyga> jdstrand: but it's your call
  <zyga> jdstrand: I'll add the perf test and handle content interface next
  <jdstrand> zyga: it's apparmor policy generation. I requested myself for review
  <jdstrand> popey: sorry, thanks, done
  <mup> PR snapd#7616 closed: interfaces/many: allow k8s/systemd-run to mount volume subPaths plus cleanups <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/7616>
  <jdstrand> kjackal: fyi ^. that should be in monday's core in edge
  <kjackal> woohoo awesome jdstrand
  <zyga> jdstrand: FYI https://github.com/snapcore/snapd/pull/7632 is updated to handle all the interfaces that used update-ns snippets
  <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> jdstrand: I _really_ EOD now :)
  <ijohnson> jdstrand: feel free to push #7579 to the back of your queue FWIW, the other PR's open in snapd are more important and we don't have anybody asking for that right now, just something I noticed
  <mup> PR #7579: interfaces/network-setup-observe: add Info D-Bus method accesses <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7579>
   * zyga waves and wishes everyone a good weekend
  <ijohnson> have a good weekend zyga
  <jdstrand> ijohnson: it is on the list, thanks
  <jdstrand> zyga: thanks!
  #snappy 2019-10-19
  <Eighth_Doctor> zyga, mborzecki: failure when trying to build snapd for el7 ppc64le: https://kojipkgs.fedoraproject.org//work/tasks/3761/38393761/build.log
  <Eighth_Doctor> err not el7, fc32 (rawhide)
  <Eighth_Doctor> https://koji.fedoraproject.org/koji/taskinfo?taskID=38393761
  #snappy 2019-10-20
  <mup> PR snapcraft#2756 opened: extractors: match setuptools metadata keys <Created by galgalesh> <https://github.com/snapcore/snapcraft/pull/2756>
  <grubbleapple> where's the best place to get news on the snapd project and any integration with epel-release/centos8 ?
  <mup> PR snapcraft#2756 closed: WIP: extractors: match setuptools metadata keys <Created by galgalesh> <Closed by galgalesh> <https://github.com/snapcore/snapcraft/pull/2756>
  <Eighth_Doctor> grubbleapple: well, I'm working on it...
  <Eighth_Doctor> if I have news to share, I'll share it on the snapcraft forums
  <mup> PR snapcraft#2518 closed: snapcraft/extractors/setuppy.py: match setuptools metadata keys <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapcraft/pull/2518>
  