#snappy 2015-07-20
<fgimenez> good morning
<longsleep> hey folls is there any docs other than the trello about the upcoming u-boot changes. I want to try as early as possible for the ODROID-C1.
<ogra_> mvo, oh, does your uboot-env command need fw_env ?
<ogra_> longsleep, i'll write it up once we're done
 * ogra_ just noticed the livecd-rootfs upload ... i thought we dont need that with the go tool
<longsleep> ogra_: ok - is that happening soon? I need to check about the fw_* commands right?
<mvo> ogra_: my uboot-go work does not, the current branch is based on fw_setenv/fw_printend
<ogra_> mvo, i think we should switch over
<mvo> ogra_: I can move forward to the native go version, iirc the missing bit was that I need to implement a gettenv for a single var, thats easy to add
<mvo> ogra_: sure, I work on this now
<ogra_> mvo, is the snappy-hub branch the actual branch we buiold the beaglebone snap from ?
<longsleep> fw_setenv is a different command from setenv, fw_printenv different from printenv right?
<ogra_> the fw_ ones are userspace commends you run from a running system
<longsleep> oh
<longsleep> thats good information thanks :)
<ogra_> but they are rather buggy ... thois is why https://github.com/mvo5/uboot-go exists ... and i think we'll use that instead
<longsleep> i see - and where is the stuff stored? Question is what does my u-boot need to load such a file?
<ogra_> longsleep, here are my notes http://paste.ubuntu.com/11893737/
<ogra_> the uboot.env file just sits on the vfat partition next to the empty uEnv.txt file
<longsleep> ogra_: i see thanks. But the uboot.env needs to be loaded somehow. Do you know what feature that is in u-boot config?
<ogra_> we merge all env settings into a sinlge file and get rid of the scattered config that spans across multiple ones
<ogra_> longsleep, see line 9
<longsleep> ogra_: super - thanks i think i got it
<ogra_> getting the exact initial env was a bit tricky ... some env vars get set from dtb values or atags, you need to make sure they are not pre-set in your .env file
<longsleep> ogra_: my u-boot loads a file called boot.ini - so i guess i could just load the uboot.env from there.
<longsleep> ogra_: see here: https://github.com/longsleep/snappy-odroidc/blob/master/oem/boot-assets/boot.ini the current script
<ogra_> what i did was: booting with an empty .env file ... that gets you the dtb or atag values ... then boot with a broken .env file and run printenv in the uboot shell ...
<ogra_> that printenv with the vars from the first step removed was my base
<ogra_> and to that i added the vars from snappy-system.txt and uEnv.txt
<ogra_> (plus "snappy_trial_boot")
<longsleep> that sounds complicated - these values come from u-boot tree for the particular hardware right?
<ogra_> yes and i'm not sure they get overwritten if they are inside the enc
<ogra_> *env
<ogra_> which is why you should exclude them
<ogra_> witzh the uboot patch your ini file can be empty
<longsleep> right
<longsleep> that is worth a try
<ogra_> all environment will be read from uboot.env
<longsleep> assuming my u-boot tree supports CONFIG_ENV_* / checking now
<ogra_> thats a pretty generic function
<ogra_> (usually used to write the env to a raw space on the SD or NAND though)
<longsleep> yeah lots of grep matches
<longsleep> so that looks good
<ogra_> great
<longsleep> so for testing i could just create a uboot.env manually and see if i can boot with only that?
<ogra_> yeah
<longsleep> great - let me try that
<longsleep> ogra_: when looking at your .evn file. Lots of values seem to be not required. Did you check already what can be cleaned up?
<ogra_> longsleep, no, i actually use the complete default env from uboot up to now ... not sure if we want to clean it up (to not lose any features)
<longsleep> ogra_: makes sense - at least if loading the .env file undefines already defined stuff
<ogra_> right
<ogra_> it is loaded before anyting else so if you wanted you could still put overrides in boot.ini or uEnv.txt (whatever you use)
<longsleep> depends when the boot.ini is loaded - it is a custom patch from aml doing all kind of stuff ..
<ogra_> as i said, uboot.env is loaded immediately on startup ... before anything else
<longsleep> ok
<longsleep> well - my u-boot tree does not have CONFIG_ENV_IS_IN_FAT :-/
<ogra_> bah
<longsleep> just checking when this was added
<ogra_> it muste be really old
<ogra_> i remember using it years ago on pandabaords
<longsleep> the tree i have to use is from early 2013
<ogra_> (pandaboard went out of production in 2012)
<longsleep> mhm :)
<longsleep> you are right - added 2012-03-30
<longsleep> so i shoud have it ..
<longsleep> but the whole file is not there in my tree .. damn!
<longsleep> this is the commit - just for the record: http://git.denx.de/?p=u-boot.git;a=commit;h=57210c7cc363cf2a2a28010658c7ea67388f8d21
<ogra_> well, at least it should be easy to apply
<longsleep> yes looks easy
<JamesTait> Good morning all; happy Monday, and happy Space Exploration Day! ð
<mvo> ogra_: http://people.canonical.com/~mvo/tmp/snappy_armhf <- thats a updated version that uses the new native go uboot env handling code, if you have a moment, would be great if you could give it a go (I only tested via unittests so far
<mvo> ogra_: next I will do a bit of code cleanup and write code to import files like the existing snappy-system.txt
<ogra_> you mean on updates ?
<ogra_> mvo, the file is still sourced by uboot, so with the first "saveenv" the content should show up in the uboot.env ... what we need to make sure is to check it matches the uboot.env content and then empty it (so it doesnt get sourced again)
<longsleep> well seems like my u-boot created a uboot.env file after saveenv and next boot seems to have loaded it without error
<ogra_> awesome !
<ogra_> you should be able to use tools/mkenvimage though ... to pre-create it from a txt file
<longsleep> yeah
<ogra_> (line 16 in http://paste.ubuntu.com/11893737/)
<longsleep> checking the u-boot side first - patching was messy
<ogra_> :(
<longsleep> i could not cherry pick cleanly
<longsleep> ogra_: so the source for your uboot.env is the new-Env.txt file ?
<ogra_> yeah
<ogra_> but that indeed includes the BBB default env ... i assume you want to create your oown from scratch
<longsleep> ok let me see where i get this tool - or do you recommend to use https://github.com/mvo5/uboot-go instead?
<longsleep> mkenvimage was added to u-boot in http://git.denx.de/?p=u-boot.git;a=commit;h=a6337e6ffdea211e70dd8d6c638f6a5ec2295400 - i guess i can cherry pick that one or use the other tool
 * longsleep tries the go tool first
<longsleep> well uboot-go says bad CRC when trying to print the file created by saveenv
<longsleep> at least it is consistent - u-boot says bad CRC when loading a uboot.env created by the uboot-go :)
<ogra_> yeah, not good
<longsleep> ogra_: did you try that too and have the same issue?
<ogra_> no, works fine for me ... but mvo develops on the BBB (and i try on the BBB) so that proves nothing
<longsleep> mhm - i might have an older format of the file. Let me upload it for you somewhere.
<ogra_> note that i'm using the armhf version *on* the BBB
<longsleep> armhf version of what?
<longsleep> uboot-go ?
<ogra_> of the go tool
<longsleep> mhm there should not be any difference in go no matter what arch
<ogra_> http://people.canonical.com/~mvo/tmp/
<longsleep> ok let me try that build
<mvo> longsleep: the uboot env format is "funny". its either 4 byte  (crc) or 5 byte (crc+flags)
<longsleep> mvo: any idea where i could quickly upload the env file?
<mvo> longsleep: it seems like the flag is for "redundant" envs, but thats just a theory from reading the u-boot code, maybe your thing expects a different header
<mvo> longsleep: hexdump -C uboot.env|head is probably enough for me for now, just pastebin that :)
<longsleep> mvo: well i cherry picked and hacked around the env fat code so it might well be a u-boot issue as well
<longsleep> mvo: ok hold on
<longsleep> mvo: http://paste.ubuntu.com/11908556
<mvo> longsleep: for the 5 bytes image you need to pass mkenvimage -r iirc (redundant). plus the size must exactly match the size that is compiled into the uboot binary (but I guess thats all no news for you :)
<mvo> longsleep: joy, looks like you have a 4 byte header
<longsleep> mvo: that is news - i had no idea about .env format before today
<longsleep> i do not even have mkenvinmage yet as this is newer than my uboot :)
<longsleep> but the size triggers a bell
<mvo> longsleep: heh :) ok, I can tell you all I know, its going to be quick ;)
<mvo> longsleep: so header is important (either 4 or 5 byte). size must match exactly the one thats compiled in, then it should work (tm)
<longsleep> i have CONFIG_ENV_SIZE (32 * 1024)
<longsleep> is that the size you mean?
<mvo> yes
<longsleep> and CONFIG_ENV_OFFSET (512 * 1024)
<longsleep> that might be a problem?
<mvo> I'm not sure, I *think* (but could be totally off) that this is ignored when writing to fat files
 * longsleep checks the code
<longsleep> seems so as its not used in the FAT code. CONFIG_ENV_SIZE is used
<mvo> great!
<mvo> longsleep: the uboot.env from the pastebin, was that created using saveenv from your uboot prompt?
<longsleep> yes
<mvo> hm, I wonder if there is a way to get a 5 byte header there as well. would be nice if it would be all the same on all ports
<mvo> but I can probably add auto-detect magic to my go-code, but its a bit ugly, something like "if isAscii(content[4])" which feels â¦wrong
<longsleep> assuming that my file is supposted to work then yes - but i thought you have a 4 byte header as well?
<mvo> we have a 5 byte header but I have not yet figured out why, I don't know if its maybe a config option in the uboot build, maybe ogra_ knows. its seems releated to "redundant"  env
<mvo> whatever that means
<longsleep> mvo: i do not know either, no redundant what so ever related to env in my build config for u-boot.
<longsleep> mvo: if you want to have the complete file: https://www.stdin.xyz/downloads/people/longsleep/tmp/uboot.env-odroidsaveenv
<mvo> longsleep, ogra_ do you have CONFIG_SYS_REDUNDANT_ENVIRONMENT in your build config?
<mvo> that seems to be the magic configuration
<ogra_> ogra@anubis:~/datengrab/rpi/uboot/bbb/u-boot-latest$ grep CONFIG_SYS_REDUNDANT_ENVIRONMENT configs/am335x_boneblack_defconfig
<ogra_> ogra@anubis:~/datengrab/rpi/uboot/bbb/u-boot-latest$
<ogra_> nope
<longsleep> mvo: grep shows nothing in u-boot that - so does not seems so
<mvo> ups, sorry, typo on my side :(
<mvo> CONFIG_SYS_REDUNDAND_ENVIRONMENT
<mvo> -^
<longsleep> that matches but i do not have it set
<ogra_> nope, not either
<mvo> ogra_: not set either
<mvo> hmmmmm
<longsleep> it also seems only be used in env_embedded
<longsleep> and in envcrc
<longsleep> hold on
<mvo> for me (current u-boot git) it defines the size o fenv_t
<mvo> i.e. typedef struct environment_s {} env_t
<mvo> but nevermind, I am pretty sure I can do the auto-detection magic, reading the code further, content[4] is either 0 or 1 when its a 5 byte header and its ascii if its a 4 byte header, so auto-detect should work
<mvo> on reading at least
<mvo> writing is a different matter, need to add flags or something
<mvo> ogra_: but why we do not set it really confuses me, i.e. how we end up with a long header
<ogra_> i have no idea
<mvo> ogra_: could you pastebin our config? maybe its somehow derrived
<longsleep> i just pushed my u-boot branch https://github.com/longsleep/u-boot-odroidc/tree/odroidc-configfat
<longsleep> thats the tree i have to use
<longsleep> mvo: what file is that with the size?
 * ogra_ grumbles about sergiusens sending messages i cant open
<longsleep> environment.h found it
 * mvo gets lunch
<mvo> longsleep: include/environment.h is it for me that defines the header size
<longsleep> mvo: yeah i see it - maybe that has changed in later uboots
 * mvo nods
<longsleep> mvo: see https://github.com/longsleep/u-boot-odroidc/blob/odroidc-configfat/include/environment.h - i will compare as well
 * longsleep gets lunch too
<mvo> looks similar at first glance
<mvo> oh - CONFIG_ENV_OFFSET_REDUND
<mvo> looks like it might be a derrived config value
<longsleep> that REDUND stuff looks like a big mess
<longsleep> but anyhow - i agree that you should only end up with a 5 byte header when REDUNDAND_ENVIRONMENT is set
<longsleep> mvo: just to confirm, when changing headerSize to 4 in your env.go the odroidc file parses just fine
<longsleep> ogra_: i think the reason why your u-boot has 5 bytes header and mine has 4 bytes needs to be found.
<ogra_> yeah, i need to check on the RPi too
<longsleep> ogra_: http://paste.ubuntu.com/11908839/ is the uboot.env default content - if you want to compare with yours
<zyga> hi
<zyga> I'd like to have a bit of web service
<zyga> and I'd like to register my service to avahi
<zyga> so
<zyga> should I bundle avahi (seems wrong)
<mvo> longsleep: great to hear that it works with that header size
<zyga> or should I start to work on a avahi.framework?
<zyga> mvo: hey :-)
<mvo> hey zyga
<ogra_> zyga, you should bundle avahi
<mvo> longsleep: and yeah, I need we need to figure out whats going on :)
<zyga> ogra_: but how can that work if there can be only one avahi server on a host
<zyga> ogra_: one to bind to the magic port
<zyga> ogra_: it's a system-level feature
<ogra_> zyga, there was some planning that user installed snaps can override that
<zyga> ogra_: two apps cannot both bundle avahi (server)
 * ogra_ remembers some discussion on the ML
<zyga> ogra_: can you explain how this would work ?
<ogra_> no
<ogra_> but i know that the expectation was that you bundle it
<ogra_> and that the preinstalled avahi goes oout of your wa<
<zyga> ogra_: mmm, so I don't get it, if I do my snap with avahi server I effectively prevent all other snaps from doing that
<ogra_> way
<zyga> ?
<zyga> is there a preinstalled avahi?
<ogra_> no idea
<ogra_> yes, webdm ships avahi
<zyga> hmm, does it?
<zyga> I don't see that here
<ogra_> yes
<mvo> longsleep, ogra_: lets try to get to the bottom of this, if all else fails I add the auto-magic, but I hope I don't have to do this
<ogra_> well, and that wouldnt help on "create"
<longsleep> mvo: well the question is how is the initial .env file created.
<zyga> ah, so snappyd has an avahi server inside?
<longsleep> +is
<zyga> hmmm, I still don't get how this can work with more than one app
<mvo> longsleep: indeed, you guys need some default values in there right? that come from the default_env of the uenv code?
<ogra_> longsleep, preferably indeed by your mkenv tool
<ogra_> from the tools dir
<ogra_> that should give you the right header for your uboot
<longsleep> yes all kinds of stuff might need to be set in addition to snappy boot logic
<mvo> longsleep: I have go code that can read a key=value\n file and create a uboot.env but I don't know about the initial defaults. I wonder if mkenvimage helps here
<ogra_> yes, it should be compiled with the righ defaults for your specific build
<longsleep> well the default could be provided in the oem package
<longsleep> the problem is how and where does the snappy boot logic get triggered
<ogra_> i assume some devices will adapt all that stuff to a possible NAND that we dont use
<longsleep> in ogra_ 's file he does it with uenvcmd
<longsleep> that only works because his defaults run this macro in bootcmd
<longsleep> in my file this will have to be totally different
<ogra_> all devices use snappy_boot
<ogra_> your bootcmd should already be adjusted for this
<longsleep> the bootcmd should directly load snappy_boot ?
<longsleep> yours loads uenvcmd
<ogra_> which the loads snappy_boot
<ogra_> *then
<longsleep> so you say that the defaults should somehow end up loading snappy_boot?
<longsleep> i am good with that
<ogra_> the final env needs to be a merger of all the former snappy- files uEnv.txt and the default env
<longsleep> right
<ogra_> like you used it before ... just now merged
<longsleep> i was not using uEnv.txt before - so it might be a bit different
<longsleep> i was using boot.ini to set stuff
<ogra_> well, but for rollback and stuff you used snappy-system-txt
<ogra_> *.txt
<longsleep> right
<ogra_> so your boot.ini somehow pulled in and called snappy_boot
<longsleep> correct
<ogra_> which has the logic
<ogra_> right, so now, just do the same :)
<longsleep> yes i can do it manually i get that
<ogra_> just not scattered across multiple files
<longsleep> the question is how to automate it
<longsleep> or make it generic
<ogra_> your initial txt file should have it
<longsleep> ok - so that is still shipped by the OEM snap or whatever there is in the future
<ogra_> yes
<ogra_> uboot.env will be shipped
<ogra_> in your snap
<longsleep> then the 4 or 5 byte problem should be none as well
<longsleep> the tool just needs to keep the header size as the same
<ogra_> right, if mvo can autodetect it and we can just rely on mkenvimage we should be all fine
<longsleep> mkenvimage - that tool is a problem - i would prefer the go version from mvo
<ogra_> i wouldnt like to generalize here since it might break the ability of a board to actually use the NAND
<ogra_> in case you want to switch to that we shouldnt break your defaults
<ogra_> mkenvimage guarantees that your env file will be readable for sure though
<ogra_> (for u-boot at least)
<longsleep> corret - but this would be created on OEM snap building right? So that tool is a build requiredment
<ogra_> yeah
<ogra_> well, its is a req for your port
<longsleep> ah - the .env file needs to be changed on update too - you want this to be done by the mkenvimage tool as well?
<ogra_> will ave to go into the porting documentation (once we have such a thing :P )
<mvo> ogra_: how would it break nand when we use the go version? just curious? mkenvfile can only create a file afaics
<ogra_> mvo, it could break NAND if we enforce a certain header in the u-boot build ... not in the go version
<mvo> ogra_: oh, sure, the go version will be able to deal with both headers, thats for sure, same way as mkenvfile with a flag
<longsleep> ah yes - thats true - but we do not neede to enforce the header. Just make the go tool support 4 and 5 bytes and keep the size on change
<ogra_> what mkenvfile creates could be written to nand
<mvo> but no worries, using mkenvfile is fine
<mvo> I just wanted to understand if there is anything I need to support for NAND
<ogra_> yeah, i think thats the safest option
<ogra_> no
<ogra_> and we dont plan to support it atm ... but i want us to not break the potential use of it either :(
<ogra_> err
<ogra_> :)
<longsleep> so you propose to ship mkenvfile as pat of a snappy system and use this tool to modify .env files?
<longsleep> s/pat/part
<ogra_> no
<ogra_> i propose to ask porters to use it to create their initial uboot.env file
<ogra_> when they do their u-boot.img build
<longsleep> ok thats fine
<longsleep> and for updates use the go tool?
<ogra_> for our purpoose the go binary should be fine
<longsleep> +1
<ogra_> jusr not for the initial creation (unless we have a header -zize option or some such and know exactly which board needs which header size)
<longsleep> well the developer should know, i am not so sure that the mkenvfile will know either as it needs to be compiled exactly with the same config.
<ogra_> right, which is what i simply assume when you build your u-boot tree
<longsleep> ogra_: ok - i guess this is a valid assumption
<ogra_> (especially since you need to patch it anyway for the uboot.env support i would expect you to recompile it)
<longsleep> ogra_: by patching you mean enabling the defines in the board configuration?
<ogra_> right
<longsleep> ogra_: i thought newer uboots have a config file for this instead of header files
<ogra_> oh,, do they ?
 * ogra_ hasnt heard of that 
<longsleep> i think so, i had some troubles backporting stuff because of this change
<longsleep> yes
<longsleep> see http://git.denx.de/?p=u-boot.git;a=tree;f=configs;h=ff6b998c4ffa4e9da3ab367141156391d5fcad3d;hb=HEAD
<ogra_> what about that ? that has always been the config dir
<longsleep> no - not in my tree
<longsleep> all the defconfig stuff is rather new
<ogra_> ah
 * ogra_ remembers using it for beagle XM installs years ago 
<longsleep> well arm u-boot is so messy, but the diff you use for BBB also does not seem to use it as your change is in a header file - or maybe i get it wrong
<longsleep> ogra_: well ok - it uses both, earlier it was only includes. Never mind.
<ogra_> yeah, it now includes the includes :)
<ogra_> they changed the structure a bit
<longsleep> i thought it was easier to change compile settings without patching in a bunch of defines
<longsleep> mvo: uboot-go seems to have another setting for headerSize as it seems to create 5 bytes headers even with headerSize set to 4
 * ogra_ tried a static kodi build on the weekend to use it in snap and click packages ... 
<mvo> longsleep: oh, let me check
<ogra_> seems building something static as soon as pytjhon is involved becomes a major pain :(
<longsleep> thats why you use Go :)
<ogra_> longsleep, doesnt help when wanting to build some nonn go thing like kodi (xbmc)
<ogra_> obviously i can only build it as static binary if i also have a static python i have to build myself
<ogra_> such a mess .(
<longsleep> having a kodi snap would be pretty awesome
<mvo> longsleep: I'm fixing this right now, give me some minutes, I will yell once I have a fix
<longsleep> mvo: awesome thanks
<ogra_> well, i was more after a click :) but yeah, rolling a snap at the same time shouldnt be hard
<longsleep> what is a "click" - i think i missed something
<ogra_> longsleep, the predecessor of snap
<longsleep> ogra_: oh - seems i have missed that
<ogra_> it is what we use on the phone
 * longsleep tries to compile mkenvimage
<ogra_> just "make all" ;)
<longsleep> nah - had to backport it into my u-boot :)
<longsleep> but seems like it compiled
<Chipaca> anybody here on 14.04, to try the mir snap in virt-manager?
<longsleep> ogra_, mvo - i think i just might have found why you have 5 bytes headers
<ogra_> because we are the cooler kids !
<ogra_> :P
<longsleep> in your example you have -r parameter to mkenvimage - i guess that means redundant
<longsleep> "the environment has multiple copies in flash"
<ogra_> right, and without -r we get CRC errors
<longsleep> ok :)
<ogra_> so the uboot binary expects the 5 bytes
<mvo> longsleep: if you git pull from my uboot-go repo it should hopeflly work, no auto-detection yet though, you still need to set the header size manually, I add that in the next commit
<longsleep> mvo: cool / i will try in 2 minutes
<mvo> no rush
<mvo> I'm here for at least 3h
<longsleep> ok with the old version i can read a 4 bytes file created with mkenvimage
<longsleep> lets update
<longsleep> still works with updated version
<longsleep> lets see if i can create
<longsleep> mvo: yes works - cool
<mvo> yay
<mvo> yay^2
<longsleep> lets try to set something :)
<longsleep> set works too now - now the boot test
<ogra_> yippies
<longsleep> mvo: works like a charm
<ogra_> \o/
<longsleep> ogra_: and you were right, uboot.env removes all previously loaded defaults
<longsleep> i now have essentially only foo=bar in the environment
<ogra_> yeah
<longsleep> but thats something - i think i could get the odroidc platform boot fine with this ne scheme
<longsleep> new
<ogra_> just think about the kids^WATAGs ...
<ogra_> (respective handed through dtb settings)
<mvo> longsleep: there is now also "import" to read from key=value files
<longsleep> mvo: oh let me try that
<longsleep> mvo: yeah works fine as well
<longsleep> (note that i have changed headerSize to 4)
<tedg> I don't see an updated Mir in my updates, is there a way to check the store to make sure it's not my local system being broken?
<Chipaca> tedg: what's up/down?
<ogra_> was a newer Mir uploaded to the store yet ?
<ogra_> you can use uappexplorer
<Chipaca> tedg: ah, you mean the snap?
<ogra_> (unless that now filters snaps)
<Chipaca> tedg: bzr branch lp:~mir-team/mir/snappy-packaging && cd snappy-packaging && make && echo YEAH
<tedg> It was in the store, just need a newer version. Which kgunn said he was uploading on Friday.
<tedg> I need to know whether it's my fault or not before I complain :-)
<Chipaca> s/echo/notify-send/
<tedg> Chipaca, Sure, just trying to get everything working "out-of-the-box"
<ogra_> https://uappexplorer.com/app/my-world.testsnappy ... doesnt filter it seems
<ogra_> so if a new snap is uploaded it should show up in https://uappexplorer.com/apps
<ogra_> (usually sorts newest first)
<tedg> I can't find the original in uappexplorer, because it's a framework?
<Chipaca> probably
<Chipaca> what version do you see?
<tedg> snap1
<ogra_> ah, right, a search for docker doesnt return anything
<ogra_> hmm, just because i searched wrongly
<ogra_> https://uappexplorer.com/app/com.ubuntu.snappy.docker
<ogra_> https://uappexplorer.com/apps?sort=relevance&type=snappy
<ogra_> that actually lists all snaps
<tedg> Still don't see Mir though.
<ogra_> only 59 :(((
<tedg> kgunn, Where you able to get Mir uploaded on Friday?
<kgunn> tedg: i did, altho, prolly just in store review queue...lemme check
<mvo> longsleep: silly question, how terrible would it be for you to enable this redundand option? or is that not availalbe at all for your version of uboot?
<kgunn> tedg: ah...says published, so snappy search should say snap1.1
<longsleep> mvo: good question - can give it a try
<longsleep> mvo: i guess i would be fine if it does not break anything
<kgunn> tedg: lemme know if you have issue with install
<tedg> Hmm, no. I don't see it. And neither does uappexplorer. https://uappexplorer.com/app/mir.mvp-demo
<tedg> (finally found it there)
 * longsleep compiling u-boot with CONFIG_SYS_REDUNDAND_ENVIRONMENT
<ogra_> tedg, yeah, weird that uappexplorer doesnt list it at all
<longsleep> mvo: seems to work just fine - now i get CRC error with 4 byte env file
<tedg> We may need to ping the store.
<longsleep> mvo: saveenv just worked fine and it seems to load the file it just created
<ogra_> 4 byte is so last build anyway :P
<longsleep> hehe
<mvo> yay
<ogra_> moar bytes !
<longsleep> now let me create a new 5 byte file
<tedg> Could someone check with a "snappy search mir" on their device and see if snap1.1 is available to them?
<ogra_> not here
<ogra_> no neither of my armhf devices
<ogra_> but i guess that is because kgunn is a lazy guy and only built for x86 :)
<tedg> Okay, thanks ogra_
<tedg> Oh, I want it for amd64, so I'm happy there :-)
<Chipaca> tedg: no mir for amd64 here either
<longsleep> mvo, ogra_ : Seems like i do not care if its 5 or 4 byte header - i can do both :)
<ogra_> cool !
<mvo> longsleep: then go with 5 ;)
<mvo> makes our life easier
<ogra_> 5 is the future !
<longsleep> mvo: all right - just make sure to add it to the docs that one needs to set CONFIG_SYS_REDUNDAND_ENVIRONMENT
<longsleep> and that typo will give problems for sure ;)
<mvo> heh
<tedg> kgunn, Can you check your store page again to make sure it's published? And then we'll look to see what happened.
<kgunn> tedg: so on myapps.developer.ubuntu.com/dev/click-apps/?format=snap i see mir snap1.1 and it says "published" with a little green bubble
<kgunn> tedg: or do you mean some other way of checking ?
<kgunn> tedg: ah...wait, there's another page
<ogra_> yeah, the public appstore
<kgunn> tedg: "current approved version" snap1
<ogra_> (it is a community project using the store api ... might be an api bug and beuno's fault that we dont see it)
<tedg> kgunn, Do you approve or do we need a store approver?
<tedg> Is that a popey thing?
<ogra_> thats likely a review thing
<popey> i can
<popey> if in stores
<kgunn> popey: yeah, i uploaded friday
<tedg> popey, You can trust kgunn for this, he's a manager, but it's okay. ;-)
<kgunn> lol
<popey> hah
 * kgunn grabs steel ball and rubber hammer to show them
<popey> kgunn: not confident approving this. I really only approve clicks right now. might need to wait for jdstrand ?
<ogra_> yeah, just estimate a few months for the review ... non click apps can take long :P
<ogra_> (just re-pack as click and popey will let it through ;) )
<kgunn> popey: np, jdstrand should be on soon
<kgunn> tedg: ^ ...so waiting now
<tedg> Yeah, glad we figured out what the issue is though. Now I can move to track down others :-)
<longsleep> ogra_, mvo: Seems that i can release the u-boot changes already as everything works as before as long as where is no uboot.env file
<mvo> yay!
<longsleep> if there is such a file, it completely takes over
<longsleep> and whatever new behaviour jumps in
<ogra_> yeah, the new behavior is the part we're still working on
<ogra_> (on the snappy side)
<ogra_> (and i need to prepare an MP for the snappy-hub tree for the default BBB env)
<longsleep> right - i just wanted to check possible u-boot issues on my end as early as possible. So for now i am good as everthing seems to work and i might eventually even be able to remove some of the FAT backports i had to do.
<ogra_> yeah
<ogra_> thats our evil masterplan :) getting rid of writing files to fat
<longsleep> very good plan
<longsleep> I merged it to master of my u-boot tree: If you are interested in the changes i had to backport https://github.com/longsleep/u-boot-odroidc/compare/odroidc-0.2...master
<jdstrand> benoitc: fyi, server error going to https://myapps.developer.ubuntu.com/dev/click-apps/reviewer/
<jdstrand> benoitc: nm
<jdstrand> beuno: fyi, server error going to https://myapps.developer.ubuntu.com/dev/click-apps/reviewer/
<jdstrand> (tab fail)
<jdstrand> beuno: OOPS-0393df0da7284ccf8501cfb761c0ce4d
<beuno> jdstrand, oh-oh
<beuno> nessita, ^
<nessita> beuno, ack, seems like we have some issues with the quarantined apps
<nessita> jdstrand, one sec, we're removing the troubling apps
<nessita> jdstrand, do you need to review a specific app?
 * ogra_ bets the one you just removed :)
<jdstrand> nessita: I was going to look at the mir one
<ogra_> mvo, if i only had any clue on go ... then i would approve https://code.launchpad.net/~mvo/snappy/snappy-snappy-bootsuccess-env2/+merge/265259
<mvo> heh
<mvo> ogra_: Chipaca will have a look I'm sure
<ogra_> yeah
<nessita> jdstrand, so until we fix the review you can workaround like this: search for the app in https://myapps.developer.ubuntu.com/dev/click-apps/search/
<longsleep> ogra_: In the new uboot.evn approach - do you have already any ideas wher ethe snappy_boot macro comes from? Am i supposed to add this there myself?
<nessita> jdstrand, then go to the package details of the desired app https://myapps.developer.ubuntu.com/dev/click-apps/2811/
<nessita> and  append /review/ to the url: https://myapps.developer.ubuntu.com/dev/click-apps/2811/review/
<ogra_> longsleep, yes
<ogra_> longsleep, your uboot.env needs to be a merge of boot.ini/uEnv.txt (whatever of the two your device uses), the default env and the snappy-system-txt content
<longsleep> ogra_: Great thats good, as i currently have to overwrite it.
<nessita> jdstrand, sorry for the trouble but we're working right now on fixing it
<longsleep> ogra_: Understood thanks
<ogra_> since snappy-system.txt is created by ubuntu-device-flash you need to pull the original content from a former install i fear
<ogra_> (and then apply my changes to snappy_boot)
<ogra_> (mainly getting rid of fatwrite and using a variable)
<longsleep> ogra_: well i think it just needs to be documented what env variables are changed on update and the boot scripting then needs to use them
<longsleep> ogra_: right now i think, on update just snappy_mode will be changed
<longsleep> ogra_: and whatever scripting happens needs to check that and toggle root to a or b
<ogra_> well, snappy_boot holds essentially the whole logic for updates/rollback/reboot
<longsleep> ogra_: yes - i guess that macro needs just to be documented. Though what is currently shipped does boot a initrd zimage
<jdstrand> nessita: no worries and thanks :)
<longsleep> ogra_: my u-boot can only boot uimages
<longsleep> ogra_: thus i had to overwrite the whole macro
<ogra_> right, so you need to adjust for that
<longsleep> ogra_: but if the macro goes into oem domain then this is fine
<ogra_> hmm
<ogra_> snappy_boot doesnt use initrd or uninitrd anywhere
<longsleep> at the end it calls bootz does it not?
<ogra_> ah, right
<ogra_> so yeah, you need to change it to bootm
<longsleep> yes
<ogra_> we should probably push that out of that line and define it elsewhere
<longsleep> well - if the whole thing gets owned by the image creator then it does not matter
<ogra_> snappy_default_bootcmd=bootz ${loadaddr} ${initrd_addr}:${initrd_size} ${fdtaddr} ...
<ogra_> then you can more easily re-define it to be bootm
<ogra_> without hacking the actual command
<longsleep> true - the more modular the better
<nessita> jdstrand, review UI fixed! :-)
<jdstrand> nessita: that was fast! :)
<nessita> jdstrand, faster than expected, yeah (we managed to fix a package in a inconsistent state instead of having to wait for a new deploy)
<p_lorenz> hi - is there already a snappy image for the raspberry pi 2 which does not have the random mac address assigning bug? ( @ogra_ ?)
<ogra_> p_lorenz, nope, the next 15.04 image will have that ... but the image itself got delayed due to another bug
<ogra_> (we had planned to release it last week, but that didnt happen yet and i can only build the actual RPi image once the image is out)
<tedg> jdstrand, Were you able to approve the mir snap?
<jdstrand> tedg: not yet but am working on it
<tedg> jdstrand, Cool, thank you!
<fgimenez> rsalveti, while at the writable paths test i've found what seems to be an error, the path for /etc/NetworkManager/system-connections is missing the leading slash http://paste.ubuntu.com/11909810/
<hallyn> hi - there's an open bug about updating a package's config file (/etc/lxc/lxc-usernet) from another package (phablet).  phablet wants to add an entry.  What would be the proper way to do that, given that lxc-usernet is ro?
<hallyn> (bug 1475751 fwiw)
<ubottu> bug 1475751 in lxc (Ubuntu) "need phablet support for mods to /etc/lxc/lxc-usernet (vivid+stable ppa overaly)" [High,New] https://launchpad.net/bugs/1475751
<fgimenez> rsalveti, it seems to be in the previous line, where should i report this?
<jdstrand> tedg: can someone request a manual review for mir?
<jdstrand> tedg: I've reviewed it, but I can't accept it until someone does that
<jdstrand> kgunn: ^
<kgunn> ack looking
<kgunn> jdstrand: hmmm, not apparent how i do that....i see the failure due to unconfined and framework
<kgunn> but i don't see how to ask for a manual review
<kgunn> i see i can make a comment on the failures...?
<kgunn> jdstrand: do i need to "unpublish" ?
<jdstrand> kgunn: no. maybe it was the link I went to. I got there via another means and can see that I can approve
<jdstrand> kgunn: since it is already up for review, I guess you can't request to manually review
<jdstrand> anyway, taking care of it
<jdstrand> kgunn: ok, approved, but please see my review feedback
<kgunn> jdstrand: ok, thanks... tedg ^
<longsleep> ogra_: I finished experimental uboot.env building in my build environment - it boots just fine. So i have this environment combining defaults, boot.ini and snappy-system.txt: https://github.com/longsleep/snappy-odroidc/blob/uboot-env-support/oem/boot-assets/uboot.env.txt
<ogra_> longsleep, perfect !
<longsleep> ogra_: so assuming a tool will change snappy_mode regular to try it should just work. Is that something you want in 15.04?
<ogra_> yes, it is what we hold back the release for
<longsleep> i see - by the way i found one problem
<ogra_> since the fatwrite way we used there is not reliable and always trashes the fat after some going back and forth
<longsleep> yeah - i could never reproduce this on the odroidc
<longsleep> never mind, the problem i found might be no problem after all
<longsleep> well - saveenv will add extra stuff to the stored env file. Like mac address and system serial.
<longsleep> not sure if that is a problem
<ogra_> i dont think it is, they are usually not changing
<tedg> Great, thanks jdstrand!
<ogra_> if we find a var that actually has probs with that we'll deal with it then
<longsleep> ogra_: right, but it might give a surprise when the media is moved to another device
<ogra_> true
<ogra_> sadly there is no selective-saveenv to just store single var changes
<longsleep> yeah - well we will see how this goes in the wild
<ogra_> yup
<ogra_> i dont imagine it will be problematic ... but we'll see
<longsleep> i will experiment a bit on this
<ogra_> cool, thanks !
<longsleep> ogra_: well i guess i could just compile u-boot without network support.
<ogra_> i think the ftd will still hand over a MAC even then
<tedg> jdstrand, I'm still getting a bad system call with the updated Mir package. Where do I find the seccomp policy to make sure it's the one with socketpair() ?
<tedg> Uhg, found it. That's not it.
<elopio_> good morning!
<elopio_> internet is bad in here, again. Seems better now, so I'll make it up for my tardiness working late today.
<elopio_> ev: what about https://code.launchpad.net/~tanuki/charms/trusty/tarmac/trunk ?
<elopio_> are you supporting that?
<ev> no, that's for internal use
<ev> elopio_: the kitsune squad is working with engineering teams to get what CI used to run for them transitioned over to self-service CI. This is done with Jenkins-as-a-service, a push button deployment of a Jenkins. Part of that will be using Tarmac for injecting MP events into Jenkins, but that's on a case by case basis, ultimately managed by the engineering
<ev> teams who will now own these Jenkins instances, and is done as just installing the tarmac package, not a charm.
<ev> This is unrelated to the work the CI product squad (tanuki) is doing to build what we discussed last week
<ev> think of kitsune as helping teams get a Jenkins, and get familiar with running their own jobs. Tanuki is about product-testing, wherein the CI service is just about telling you there are product test opportunities, helping direct these opportunities down to your lab and your devices to be run, and giving you a place to pass binary result states up
<ev> if you have deeper questions, feel free to kick this over to a PM
<elopio> ev: ok, from playing with that charm I found it easier to just install tarmac too.
<elopio> ev: no more questions for now. If your kitsune team wants alpha users, count me in.
<ev> they've got their hands full with community core apps and mir/unity at the moment, but I'll keep you posted
<ev> as it turns out, self-service CI is a desired thing :D
<jdstrand> tedg: /var/lib/snappy/seccomp/profiles
<jdstrand> tedg: note, seccomp policy is not regenerated on upgrade yet
<tedg> jdstrand, Yeah, I figured out my issue. Apparently qmlscene opens a socket for even local file access if you use the XMLHTTP() object.
<tedg> jdstrand, Had to add in network-client
<jdstrand> ah, yeah
<jdstrand> I remember that with touch policy
<jdstrand> now that you mention it
<tedg> kgunn, Are there plans to make a mir package for the RaspPi2?
<kgunn> tedg: kinda... it's not just adding arm,  we need to add sw rendering to mir
<tedg> kgunn, Oh, can't use the RaspPi drivers? I thought they were accelerated?
<tedg> kgunn, Also it seems keyboard isn't working for me. Is that expected? Or something I did wrong :-)
<kgunn> tedg: bregma and bschaefer have poked around on RPi, i think egl might have been missing ?
<bschaefer> kgunn, the entire /dev/dri/card* is missing
<kgunn> tedg: ...and i can't speak to keyboard issues
<bschaefer> right, i was getting no keyboard events in a kvm through mir (wasnt sure if it was the VM it self or an issue with snappy/mir)
<kyrofa> seb128, you still around?
<kyrofa> kgunn, quick update: the snappy scope is is the NEW queue for wily awaiting review
<kgunn> kyrofa: that's good news!
<kgunn> kyrofa: so are you able to install a snap ?
<kyrofa> kgunn, search/install/uninstall, yes
<kgunn> oh man...nice!
<kyrofa> kgunn, as soon as it hits the archives I'll make a MP to get it into the Personal seed
<kyrofa> kgunn, there's a caveat. It requires the webdm snap to work, which has not yet been released in the personal channel so it can't be preloaded
<kyrofa> I'll ping sergiusens in the morning to see if I can get that to happen soon
<kyrofa> kgunn, until then you'll have to sideload it
<kgunn> thanks
<mariogrip> ogra_: Im running snappy in lxc :D  https://usercontent.irccloud-cdn.com/file/e9wYtfMb/
<mariogrip> ogra_: Im running snappy in lxc :D
<mariogrip> using the snappy personal
<bregma> keyboard works fine on rasPi for me, but I'm using the serial console not USB
 * bregma does not have enough desks for a keyboard just for a pi
 * bregma is waiting like a vulture for his daughter to move out again
 * bregma has plans, of yes, he has plans.....
#snappy 2015-07-21
<kirkland> is there a public "view" of my app uploaded to the snappy store?
<kirkland> I can see https://myapps.developer.ubuntu.com/dev/click-apps/3123/ but that looks to be private to me
<mvo> ogra_: good morning! there is https://code.launchpad.net/~mvo/snappy-hub/bbb-env/+merge/264975 right now but thats incomplete, right? would be awsome if you could point me to the steps that are missing. is it just adding "snappy-system.txt" to mkenvimage?
<fgimenez> good morning
<ogra_> mvo, the input file shouldnt be called uEnv.txt, we want that file empty in the /boot dir ... (or alternatively fix snappy to not look for it but to check for uboot.env instead)
<ogra_> i'll prepare an MP with the file content
<dholbach> good morning
<JamesTait> Good morning all; happy Viking 1 Landing Day! ð
<longsleep> ogra_: I was thinking about the saveenv a bit more and was wondering why you guys do not see fat corruption that way. Any idea?
<ogra_> longsleep, different layer i guess
<ogra_> the assigned size of the file on the fs is fixed, only the content inside changes, i guess that makes it behave different
<ogra_> mvo, https://code.launchpad.net/~ogra/snappy-hub/bbb-new-binaries-and-env/+merge/265375
<mvo> ogra_: hm, thats long :) none of this is in the default env that uboot already generates? thats a bit disappointing of uboot :/
<ogra_> mvo, thjats in the default env that is hardcoded into the uboot binar
<ogra_> y
<ogra_> which gets emptied automatically if uboot.env gets loaded
<mvo> ogra_: aha, that was my question, if it merges or overrides
<ogra_> to keep it we need to carry over the whole of it
<mvo> yeah, makes sense
<mvo> would be great if we could document this for porters later how to ge tthe defaults that needs to be added
<ogra_> thats my plan once we are finished
<mvo> yay
<mvo> :)
<ogra_> i added the MP as item to the trello card
<longsleep> ogra_: ah yes that makes sense - the file size always stays the same
<ogra_> (and commented on https://code.launchpad.net/~mvo/snappy-hub/bbb-env/+merge/264975)
<mvo> so does that mean with that uboot.env a fresh system with your latest uboot will fully work with the uboot.env (and with my snappy branch)?
<mvo> ogra_: yeah, my branch is obsolete now
<ogra_> mvo, thats what i tested here
<mvo> ogra_: \o/
<ogra_> mvo, no, it isnt
<ogra_> i left out the bits your branch has
<ogra_> the README needs updating though :)
<mvo> ogra_: you tested and it all worked? thats fantastic news
<mvo> ogra_: haha, ok
<mvo> ogra_: I merge your stuff then :)
<ogra_> mvo, last friday, yes
<ogra_> with my own snap though (based off the beagleblack snap from the store) ... we'll still need an end to end test with a snap built fr4om the branch
<mvo> ok
<ogra_> (and with your chanes in place indeed)
<mvo> ogra_: did you managed to test if the fs corruption is fixed too?
<ogra_> (without me cp'ing the snappy binary in place ;))
<ogra_> i didnt have any corruption, but i would still like to see it in a real end to end test first
<ogra_> (i switched back and forth twice when i tested, the prob is indeed that i manually hack the env to trigger that)
<longsleep> thats what i also wanted to ask, how can i build an image which does change the stuff in uboot.env? Is there something in edge channel already?
<ogra_> well, technically we dont support rollback on non beagle boards currently
<ogra_> though i bet in 15.04 it might still work somehow
<longsleep> ogra_: rollback works fine for the odroidc with my image
<ogra_> hah, good  :)
<longsleep> and i would like to keep it that way with the upcoming changes :)
<ogra_> well, snappy will refuse to update at some point ...
<ogra_> in rolling ...
<longsleep> i can easily trigger it from uboot shell now, the only thing missing is the stuff modifying the uboot.evn after successfull boot
<longsleep> why would it refuse to update?
<ogra_> because only fully supported boards are supposed to get updates
<ogra_> (there were a few discussions on the ML about this ... in the RPi threads )
<longsleep> how is it detected? I have the auto updater currently enabled and it worked fine when version 3 was released
<ogra_> (that doesnt stop you from doing any uboot shell hackery, but the automatism wil likely refuse to work at some point)
<ogra_> yes, as i said, in 15.04 that still works
<longsleep> well - thats why i am here to fix things and make it working
<ogra_> i assume what is supported will be considered by the store ... technically only the bits from plain mainline are under active support currently ... which limits us to the BBB on arm
<Chipaca> rsalveti: ping about the difference between "snappy service status" and "snappy service list"
<longsleep> yes that is fine with me - i can even run my own system-image server if required. I want to provide a stable upgrade path to anyone trying my images.
<ogra_> well, system-image will go away
<ogra_> everything will become a snap
<longsleep> right - i might to want to run my own source for snaps then. I already have the odroid oem snap in the store. If that is the way thats fine too.
<chihchun> is rootfs of snappy ubuntu core built with this seed ? https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-core.wily ?
<chihchun> bafu: hi
<bafu> chihchun, hi
<ogra_> chihchun, from the system-imae file in there
<ogra_> *image
<chihchun> ogra_: thanks
<chihchun> ogra_: for the device tarball, I assume it's built by CI system. But I could not find the source code or build script ?
<ogra_> no, it is built by cdimage during the rootfs build
<ogra_> which is done by live-build ... the configs and scripts used by live-build live in the livecd-rootfs package
<chihchun> ogra_: got it, thanks
<chihchun> did not aware the config of live-build also included
<ogra_> well, we abuse the chroot from it after the rootfs has been produced to actually roll the device tarball
<ogra_> so you have all in one central place
<ogra_> mvo, hmm ...
<ogra_> mvo, i wonder how/where we can ship mkenvimage in the snappy-hub tree
<mvo> ogra_: hm, hm, its part of u-boot-tools, could we just depend on that?
<ogra_> the uboot-tools one might be older or use different defaults
<ogra_> since we require the uboot binary to be built by hand anyway we should use the mkenvimage from the same build imho
<ogra_> i have a proper binary here, i just dont know where to put it
<ogra_> mvo, http://people.canonical.com/~ogra/snappy/bootloader/ has a snap created from the tree now
<ogra_> (boots fine here )
<ogra_> "Firefox prevented the execution of Adobe Flash for github.com, do you want to keep it blocked" ....
<ogra_> WTF
<ogra_> where does github use flash !
<tbr> IIRC in the repository url widget and somewhere else
<ogra_> gross
<mvo> ogra_: nice, let try it too
<kyrofa> seb128, quick status update: the snappy scope is in the NEW queue awaiting review
<seb128> kyrofa, hey, great, let me have a look
<ogra_> kyrofa, was that a subtle way of asking seb128 to review it ?
<ogra_> :)
<longsleep> Flash is used in all kind of places as it is the only way to put something into clipboard with javascript.
<kyrofa> ogra_, maaaaaaaybe
<ogra_> :D
<ogra_> longsleep, well, github was one of the pages where i wouldnt have expected it
<tbr> ogra_: just as I remembered, it's some sort of clipboard bridge flash abomination, probably due to the native browser restrictions on pushing things to clipboard
<ogra_> yeah
<longsleep> ogra_: they have the copy to clipboard button for clone urls
<ogra_> because selecting an url and hitting ctrl-c is so hard :P
<ogra_> but yeah, understood :)
 * tbr uses a different paste buffer anyway, so selects the url manually in the field and then middle-click pastes
<ogra_> same here
<ogra_> but even here ctrl-c works :)
<ogra_> and i kind of would expect people that use git to know how to copy/paste something
<ogra_> (or is that knowledge limited to us bzr users ? (muhahaha))
<ogra_> mvo, did it work for you ?
<mvo> ogra_: haven't checked yet, the BBB is busy with some squashfs releated work
<ogra_> ah
<ogra_> well, i think we should soon start to produce an image to start testing
<longsleep> i would be interested in that as well :)
<mvo> ogra_: good point, I will try to hurry here (hurry and BBB is a bit of a contradiction though)
<ogra_> haha, yeah
<ogra_> we should have picked the parallella board as default :)
<kyrofa> ogra_, ahh, the parallella
<ogra_> shiny little fast thing :)
<ogra_> (the odroid is nearly as fast though)
<longsleep> you can test my snap :P https://www.stdin.xyz/downloads/people/longsleep/tmp/odroidc-bootloader/
<ogra_> i have a bit of an SD card shortage atm ... but will try it at one point
<longsleep> so - now that i have a snap the only thing i need now is a ubuntu-device-flash which builds an image using uboot.env :)
<kyrofa> ogra_, speaking of SD cards, how hard is it to get u-boot to boot to a USB HD instead of the SD?
<ogra_> kyrofa, that depends completely on the ROM
<ogra_> some boards can do that ... but it is realyl rare
<ogra_> (the pandaboard was capable of booting via USB if you gave it a uboot binary via netboot or usb cable iirc)
<longsleep> odroidc u-boot does not support booting from USB
<kyrofa> ogra_, that's too bad. My main personal web server is a mirabox (one of those plug computers), and that thing toasts through an SD card a year or so
<ogra_> well, if you have an MMC inside where you could put the /boot partition on to carry bootloader, kernel and initrd, booting off USB key is possible
<ogra_> but you need these bits in place on SD or MMC
<kyrofa> ogra_, hmm, interesting. And that stuff could be read-only, yeah? I may ask your advice on that later :)
<ogra_> well, if you use snappy it cant be read only because snappy needs to be able to modify the bootloader config
<ogra_> but if you stick to one image and dont upgrade you could keep it readonly indeed
<ogra_> the good thing is that we mount everything by label ... so you can just use a normal snappy img and dd it to your usb key and it will work
<ogra_> (you could do that only with the writable partition btw, since that is the only one that actually counts on snappy ... i.e. remove the label from the writable lartition on the SD, format the USB key and copy the former writable partition contents over ... then add a label to the usb key and it should work)
 * ogra_ is plannning to do that for a owncloud install here ... 
<kyrofa> ogra_, heh, that's currently one of the usages for my current server
<kyrofa> ogra_, good ideas, thank you :)
<mterry> sergiusens, could you install python3-fixtures to the snapcraft tarmac instance?
<rsalveti> fgimenez: replying back your question from yesterday, just report to snappy itself (about the writable-paths)
<kyrofa> sergiusens, we talked briefly last week about making webdm available in the Ubuntu Personal channel. Is that still something you plan on doing?
<fgimenez> rsalveti, ok thx, will do
<longsleep> btw, anyone has written a tool to enlarge the writeable partition to fill the whole storage device?
<longsleep> i mean i can easily use a script for my particular device but i would like to see a generic solution for this in snappy.
<ogra_> longsleep, we have scripts for the initrd to do that ... just not ported over to snappy
<longsleep> ogra_: is this planned? I know cloud-init can do it - do you mean these scripts?
<ogra_> no, initrd scripts that do it before the first mount
<longsleep> ok - that was what i have to do myself unless snappy gets it by default :)
<longsleep> i mean i have plenty of stuff to be done on first boot
<longsleep> like waiting for entropy, generate keys, dhparams etc ..
<ogra_> not from the initrd i hope :)
<longsleep> yeah - from the initrd it should only be the resize
<longsleep> though i do consider waiting for entropy in initrd as well
 * rsalveti finally get to read backlog
<rsalveti> Chipaca: better to ask mvo, he is the one that added the entries to the checklist
<Chipaca> fair :)
<rsalveti> longsleep: https://trello.com/c/EdWkd2UW/181-use-cloud-init-to-extend-resize-the-writable-partition-during-first-boot
<rsalveti> longsleep: that's in the list, patches are welcome if you want to give it a try
<longsleep> rsalveti: my problem is that i do not like cloud-init very much :)
<rsalveti> hard to find one that really likes it :-)
 * ogra_ is with longsleep :)
<longsleep> hehe
<longsleep> well - i have some gear to do it without cloud init for non snappy ubuntu
<rsalveti> we don't yet know if it's better to do in the initrd or cloud-init
<rsalveti> the good with thing with cloud-init is that we don't need to add extra logic in the initrd itself
<rsalveti> but that's the main difference
<ogra_> but get multi hour boot times :P
<ogra_> and python on the image
<rsalveti> well, cloud-init is already there
<longsleep> cloud init is so bloated - i would like it to go away :)
<rsalveti> the new cloud-init should probably be in go
<rsalveti> but further down the line
<longsleep> yeah - i can see that. Though cloud-init is the only thing which stopped me to implement something so far
<longsleep> and for me, that is just one problem. I need means to run (and optionally block) for other things on boot as well
<longsleep> first boot - i mean
<rsalveti> yeah, it's not ideal
<longsleep> in non snappy i just have a upstart service with run-parts a directory and writing a marker when complete. That way i can easily spawn multiple stuff, wait on it and make sure it is only done once.
<longsleep> for example on the ODROIDC generating 2048 bit dhparams takes over 10 minutes
<longsleep> and the question is what services are allowed to start until that is complete
<longsleep> assuming a default params file is shipped or something
<longsleep> another thing is the system time
<longsleep> when generating certificates on first boot, it is bad if the time is 1970 :)
<ogra_> longsleep, that means you have not enabled fixrtc on the cmdline then
<longsleep> i have - but i have no clue what it does
<longsleep> if it does not happen with snappy thats fine
<longsleep> just an example from other devices
<ogra_> well, seems it doesnt work then ... it forces the clock to the last mount time or the creation time of your partition
<ogra_> (whatever is newer)
<longsleep> that is reasonable
<ogra_> so while the clock will still be off, the diff wont be that massive
<longsleep> yeah that should be fine.
<mvo> Chipaca: what was the question again? sorry can't see it in the backlog
<Chipaca> mvo: there wasn't a question in the backlog; just a note to ask a quesiton
<mvo> heh, ok
<Chipaca> mvo: what's the difference between "snappy service list" and "snappy service status"?
<mvo> Chipaca: I was thinking that list would simply list the available ones and status gives details for a specific one, but that was shooting from the hip, so feel free to override/refine/improve :)
<Chipaca> mvo: ok, i'll implement status and then we see if we need list
<mvo> sounds good
<longsleep> rsalveti, ogra_ : Well i just tried the stuff cloud-init is doing - seems all the gear is there (growpart, resize2fs).
<ogra_> sure
<rsalveti> longsleep: yeah, might be a config change only
<longsleep> the config says something about sfdisk missing which is true but it does not seem to be required. I just ran growpart and then resize2fs. Growpart showed some warning about sfdisk but did the trick just fine. Did not even have to reboot.
<longsleep> so this could be a 3 liner script instead of cloud-init. Find disk device and partition number for writable label. Run gropwart on that partition, on success run resize2fs
<rsalveti> yup
<longsleep> rsalveti: In your trello extend/resize task there is a reference to "recovery" what is this "recovery" ?
<rsalveti> longsleep: we had an idea to investigate on having a recovery (similar to what we have for phones), but for snappy
<longsleep> rsalveti: oh all right - but that does not exist yet?
<rsalveti> the recovery could help restoring the image to factory, help sideloading apps and doing extra logic
<rsalveti> longsleep: nops, just an idea atm
<longsleep> ok
<dholbach> mvo, mterry: thanks a bunch!
<elopio> zyga: have you tried to measure the code covered by plainbox?
<zyga> elopio: hey
<zyga> elopio: code coverage of plainbox itself?
<zyga> elopio: yes
<zyga> elopio: cli parts are poorly covered, most of the core is covered well
<zyga> elopio: though a few of the new features may have lowered the scoer a little
<zyga> elopio: there's a script in trunk to run all tests with coverage
<tedg> mvo, So I think I might be caught up in the conflict between the copy plugin and trunk. Are you merging that?
<elopio> zyga: not plainbox itself. The code that the plainbox tests are covering.
<elopio> like in snapcraft, call plainbox from python3-coverage or something like that.
<mvo> tedg: I can fix merge conflicts, sure, one sec
<tedg> Great, thank you!
<zyga> elopio: ah
<zyga> elopio: no, that's hard to do in general
<zyga> elopio: though, if we specialize
<zyga> elopio: then it's quite possible
<zyga> elopio: I wrote a bit of an interesting proof of concept a while ago
<zyga> elopio: you can run a test with that, it will show you what was executed per test case
<zyga> elopio: it was specialized to python obviously
<zyga> elopio: (our code tends to be split between python, shell and C so we did not pursue that but for python-specific projects we could)
<zyga> elopio: if you have ideas how you'd like to make it better to run unit tests via plainbox I'm all ears
<elopio> zyga: we only need python here. Do you have a link?
<zyga> elopio: I'll be adding benchmark support next week
<zyga> elopio: it wasn't specific for plainbox but sure, let me find it
<zyga> elopio: though the benchmarks I'm after are like "this test compiles the linux 3.14 kernel"
<zyga> elopio: :-)
 * zyga looks at his +junk branches
<zyga> it's somewhere there :D
<elopio> zyga: for snapcraft seems to be a good fit. I'd like nicer regex matching, but we can add that.
<zyga> elopio: one thing that's possible (not sure if useful yet)
<zyga> elopio: is write a local job that looks at your python code to see what tests exist (just to discover them)
<zyga> elopio: and then let you run each single test directly via plainbox (each test would become a new job)
<zyga> elopio: local jobs are like test generators, they can run any code and can print additional test definitions)
 * zyga goes through his old code...
<kyrofa> tedg, the click scope launches click apps and scopes via UAL, right?
<tedg> kyrofa, Basically, it sends URLs to the dash when sends them to URL dispatcher which uses UAL.
<zyga> found it :)
<kyrofa> tedg, alright. Do you envision the same happening for snaps?
<zyga> whee
<tedg> kyrofa, Yeah, I do.
<tedg> kyrofa, Should just be appid:// URLs
<kyrofa> tedg, should something like that work currently?
<tedg> kyrofa, No, there's no way to define an application in a snap today.
<mvo> ogra_: http://paste.ubuntu.com/11914911/ <- this looks good, right?
<ogra_> mvo, "reading uboot.env"
<tedg> kyrofa, Only binaries and services, it needs to grow a bit of functionality before applications can exist.
<ogra_> mvo, so it does :)
<kyrofa> tedg, alright, interesting. What needs to grow beyond having a binary and some sort of .desktop (or yaml, whatever) file with install hooks?
<mvo> ogra_: yay!
<tedg> kyrofa, Well, it is more fundamental than that. There's no such thing as a way to provide install hooks or anything like that.
<tedg> kyrofa, So once a system is defined for that, it can be used to provide application information.
<tedg> kyrofa, Then we'll have appids.
<zyga> elopio: one sec, just adding boilderplate and fixing this to work on python3
<zyga> elopio: (it's pretty old)
<kyrofa> tedg, okay, I gotcha
<mvo> Chipaca: will you be able to do a bit of code review for the new uboot env snappy code today?
<kyrofa> tedg, do you have any idea of a timeline for those features?
<Chipaca> mvo: sure
<mvo> Chipaca: https://code.launchpad.net/~mvo/snappy/snappy-snappy-bootsuccess-env2/+merge/265259 and the new uboot-go env code (which is relatively small). happy to talk about deails
<tedg> kyrofa, I don't know of anyone working on it currently.
<tedg> kyrofa, I proposed a spec, but it hasn't passed through the system yet.
<tedg> kyrofa, It also needs more work if the basics do get approved there.
<kyrofa> tedg, alright. Just curious from an Ubuntu Personal perspective
<mvo> tedg: hm, I don't see a conflict in snapcraft between copy-plugin and trunk(?)
<kyrofa> tedg, in the same vein, will UAL handle legacy app launches?
<tedg> mvo, I've got the copy tests failing, could have been my merge, but I saw this comment from mterry: https://code.launchpad.net/~mvo/snapcraft/copy-plugin/+merge/264706/comments/665846
<tedg> kyrofa, I understand, not sure what you mean by "legacy" in this context.
<kyrofa> tedg, libertine
<tedg> kyrofa, libertine or /usr/share
<tedg> kyrofa, Yes, there's a branch for that, needs review.
<zyga> elopio: almost done
<elopio> zyga: no hurries.
<kyrofa> tedg, awesome! Okay, thanks for the update :)
<Chipaca> mvo: i think you need to update depedencies.tsv
<mterry> tedg, the tests in the copy-plugin branch failing you mean?
<zyga> elopio: python3 support for the example and I'm done
<tedg> mterry, Yeah
<mvo_> Chipaca: feedback on uboot-go would also be great, it has no review yet and api review etc
<Chipaca> sure
<mvo_> \o/
<kyrofa> tedg, the spec you proposed, is it the extension points document?
<tedg> kyrofa, Yes
<Chipaca> mvo_: how do i review the one in github?
 * Chipaca has a low github score
<tedg> kyrofa, Idea being that person could provide extension points for applications (devs don't need them as much) and then apps could connect into those points.
<mvo_> Chipaca: just clone and yell at me via mail or irc
<mvo_> Chipaca: or file issues, but I think thats more overhead
 * Chipaca engages yelling mode
<Chipaca> mvo_: so, silly things first
<Chipaca> mvo_: https://github.com/mvo5/uboot-go/blob/master/uenv/uboot.go~
 * mvo_ drops dead
<mvo_> thanks Chipaca
<Chipaca> mvo_: next, in https://github.com/mvo5/uboot-go/blob/master/uenv/env.go
<Chipaca> mvo_: you don't check the writes
<Chipaca> mvo_: what's the reasoning there?
<Chipaca> mvo_: not so worried about the writes to the bytes buffer, but the writes to the actual file probably need checking
<mvo_> Chipaca: absolutely
<Chipaca> mvo_: that's in Save fwiw
<ogra_> pfft, that sounds like we even test code ... "checking" hah
<Chipaca> mvo_: and you don't Sync the file
<mvo_> Chipaca: yes!
<ogra_> Chipaca, we mount with sync option
<ogra_> (while more elegant it shouldnt be needed to do any extra sync call)
<mvo_> I will still add the f.Sync()
<Chipaca> ogra_: great! that means the Sync will be instant
<Chipaca> :)
<ogra_> yeah
<mvo_> Chipaca: thats great great feedback, keep it coming
<Chipaca> mvo_: you also don't do the atomic rename dance
<ogra_> technically not needed ... for code sexiness it is though :)
<Chipaca> mvo_: not sure if that's important in this case
<Chipaca> ogra_: ideally we could stop using sync, and reap perf gainz :-p
<Chipaca> anyway
<ogra_> on /boot ?
<ogra_> :)
<Chipaca> mvo_: in Import, why don't you return scanner.Err() instead of only returning it if it's not nil, and returning nil otherwise?
<zyga> elopio: ok, done https://git.launchpad.net/testtrace/tree/demo.py
<Chipaca> ogra_: maybe in arm we don't copy kernels and initrds around between a/ and b/ ?
<Chipaca> ogra_: i thought we did
<Chipaca> ogra_: and sync makes that slow
<zyga> elopio: not much but I did clean it up a little
<ogra_> Chipaca, ah
<ogra_> i didnt think of that
<mvo_> Chipaca: yes!
<Chipaca> mvo_: and starting to get really nit-picky with this file: in âSet sets an environment name to the given valueâ
<Chipaca> mvo_: you could write âSet an environment name to the given valueâ
<Chipaca> mvo_: ditto âGet returns the value of the environment variableâ -> âGet the value of the environment variableâ
<mvo_> Chipaca: I guess its a good sign that we are at this level already
<mvo_> :P
<zyga> elopio: have a look and tell me if it's of any use to you
<Chipaca> either that, or my head works via BFS
<mvo_> heh
 * mvo_ starts fixing
<elopio> zyga: looking. Also looking at the python3-coverage approach, that doesn't require a TestCase.
<zyga> elopio: they are based on the same logic
<zyga> elopio: I mean, the same low-level feature
<zyga> elopio: this is tied to a test case so that one can easily get data that is per-test-case
<zyga> elopio: though this is just an old proof-of-concept, dusted and packaged
<elopio> zyga: it's useful, thanks.
<elopio> what's not clear for me is why python3-coverage needs to run a python file. Seems the same to me who starts the run. But I'll dig more, slowly through the week.
<zyga> elopio: because it sets up that low level trace call this way
<Chipaca> mvo_: that's all i have for now :)
<mvo_> Chipaca: I pushed a updated version, let me know if there is anything I overlooked or if my comment on e.g. write-rename make sense
<Chipaca> mvo_: there is one thing in run-checks, but we have the same issue
<Chipaca> mvo_: we should probably quote the lint output
<elopio> wow, this works.
<mvo_> Chipaca: indeed, let me fix that
<elopio> mterry: zyga: if we replace all the calls to snapcraft to something like "python3-coverage run --append --source snapcraft bin/snapcraft", we would be able to collect the coverage.
<elopio> easiest solution that comes to mind.
<mvo_> nice!
<Chipaca> mvo_: difference being http://pastebin.ubuntu.com/11915213/
<mvo_> Chipaca: fixed, I may cowboy it into lp:snappy
<Chipaca> mvo_: haven't looked at the gofmt output, but it might need the same kindness
<mvo_> Chipaca: indeed so, updated that too now
<mvo_> Chipaca: I can prepare a branch for snappy now too, unless you want to do that (don't want to steal your credits :)
<Chipaca> mvo_: s/rational/rationale/; s/FAt/FAT/; s/we not truncate/$english/; and \o/
 * ogra_ prefers FAT free ... 
<mvo_> Chipaca: pfff, whats wrong with "we not truncate" :P
<mvo_> Chipaca: fixing !
<Chipaca> mvo_: i no idea
<Chipaca> mvo_: but it wrong
<Chipaca> mvo_: as if something missing
<mvo_> Chipaca: :-D pushed another fix
 * mvo_ hugs Chipaca for his patience
<FergusL> anyone tried Snappy on OrangePi boards ?
<ogra_> FergusL, a few people i would think
<ogra_> (or is OrangePi different from OrangeBox) ?
<Chipaca> mvo_: wrt snappy branch, i don't mind either way :)
<mvo_> Chipaca: then you do it and I get dinner ;)
<Chipaca> ogra_: http://www.orangepi.org/
<ogra_> oh
<mvo_> Chipaca: and I will come back later and fix all the issues in the -env2 branch and prepare the backport after that - deal?
<ogra_> WOW !
<ogra_> sata and GigE
<ogra_> FergusL, then i was wrong ... :) i mixed it up
<longsleep> yeah, but crappy allwinner cpu
<ogra_> well, you cant have everything
<Chipaca> and it has an upgrade key!
<Chipaca> mvo_: deal
<fgimenez> nice evening everyone o/
<FergusL> I have OrangePi 2 with H3 (quad 1.6GHz A7)
<Chipaca> mvo_: only thing I see in -env2 is that we don't have a packaged golang-uboot-yadda
<mvo_> Chipaca: indeed, please add this as a review comment (if you haven't already). I will either package or just pull it into snappy, but it feels like its really a standalone thing
 * Chipaca nods
<Chipaca> mterry: any reason not to approve the copy plugin?
<Chipaca> ah, the last changes after your comments are fairly new
<longsleep> Anyone who is interested in a simple generic Snappy writable resize to max script - grab it here: https://github.com/longsleep/snappy-odroidc/blob/master/scripts/resize-snappy-writable.sh
<mterry> Chipaca, also all my previous review comments haven't been addressed yet
<mterry> Chipaca, that is one thing I don't like about inline comments.  They get "lost" when someone does any update at all
<tedg> mterry, Do I have the wrong version of something? manage.py: error: unrecognized arguments: -d /tmp/tmp.5BfenzNjeb
<mterry> tedg, README.md should have the right PPA to install to get the correct plainbox version
<mterry> tedg, also, not on wily?!  :)
<tedg> mterry, Ha, yeah. Can't wait for libertine container to work :-)
<mterry> tedg, libertine?
<tedg> mterry, The system that's being developed to run a "standard Ubuntu" on a read only filesystem.
<tedg> mterry, Runs as a container, but then exports the apps to the launcher, etc.
<mterry> ah interesting
<kyrofa> rsalveti, we're investigating i18n in the snappy scope. Do you know if webdm supports that at all?
<tedg> The nice part is that you can have real apps on multiple containers then. So it'll be easier to keep a wily version of things around.
<mterry> mvo_, can snap binary exec: lines be multi-word like service start/stop lines can be?  I'm guessing so
<mvo_> mterry: yes, that should work
<mterry> mvo_, cool
<kyrofa> Hey bregma, did you ever try running Ubuntu Personal on the rpi2?
<bregma> kyrofa, Ubuntu Personal no, because there is missing support for Mir (or Mir is missing support)
<bregma> or both
<kyrofa> bregma, heh, okay gotcha
<kyrofa> ogra_, were you ever able to get i2c + devicetree working on the rpi image?
<ogra_> kyrofa, not yet, thats in the works for the next (delayed) stable image
<ogra_> working on fixing the image itself before going back to the rpi
<kyrofa> ogra_, alright, sounds good
<ogra_> i'll send a mail announcement once the image is ready
<ogra_> we're just re-working a critical part for the default image that takes my attention atm
<tedg> mterry, So I think that focused assemble is confusing the copy plugin and breaking it's test.
<tedg> its'
<tedg> mterry, Do you have a second to take a look at that?
<tedg> mterry, I think that it shouldn't be in the build step anymore, no?
<mterry> tedg, yeah... the integrated test for copy should do 'snapcraft stage' instead of 'snapcraft snap' since it doesn't provide the metadata that 'snapcraft snap' now demands
<mterry> tedg, and should test ./stage/dst instead of ./snap/dst
<tedg> Ah, okay.
<tedg> mterry, Cool, works, thanks!
<mterry> tedg, sweet
<kyrofa> ogra_, without i2c, does that mean GPIO works OOTB?
<kyrofa> ogra_, on the rpi2
#snappy 2015-07-22
<mvo_> ogra_: hi, do you have any expectation on the order of the uboot environment vars? I use alphabetic order right now but was wondering if I should keep the order of the input file inside the uboot.env. I guess it does not matter but I wanted to double check
<fgimenez> good morning
<dholbach> good morning
<ogra_> mvo_, no, no expectations, uboot loads all at once before processing, so any order should be fine
<mvo_> Chipaca: hi, I think https://code.launchpad.net/~mvo/snappy/snappy-snappy-bootsuccess-env2/+merge/265259 is good now, I fixed the missing dependency and update tha ppa. I also createda backport for 15.04 but have not proposed it yet, wanted to do the full willy image test first
<mvo_> Chipaca: if you could check if its really good now, that would be great
<longsleep> mvo_: When this is merged and i build a new willy image, will that include the new behavior?
<ogra_> longsleep, yes
<ogra_> you will need the updated device snap
<longsleep> ogra_: Even if i have my own device snap?
<mvo_> yeah, we are just wating for the final code review, I guess I could top-approve, john said "good except the missing package dependency wich i added)
 * mvo_ wonders how impatient he is today :)
<ogra_> longsleep, you will need uboot.env support in the bootloader
<longsleep> yes i got that
<longsleep> btw - did you see my script for resizing from yesterday: https://github.com/longsleep/snappy-odroidc/blob/master/scripts/resize-snappy-writable.sh
<longsleep> i would suggest adding something like this to the boot process by default
<longsleep> will just grow the writable partition no matter what
<longsleep> (if it can be grown)
<ogra_> longsleep, we have a set of initramfs script already that are widely used (i.e. on the phones) ... we just havent decided to include them yet because there are potentially more and bigger changes to the partitioning setup ahead
<longsleep> ok - understoot. So for now see it as easy way for people to resize their snappy installation.
<longsleep> so just to be sure - once mvo_ merged the changes, 'ubuntu-device-flash core --channel edge .. 15.10 should' fuse them into an image right?
<mvo_> the snapy on the image will deal with both new uboot.env and old uEnv.txt, if uboot.env is there its used, otherwise it just keeps using the old system
<ogra_> ah, sweet
<longsleep> ok - so i could now even remove the empty uEnv.txt ?
<longsleep> and the snappy tool will still detect u-boot environment?
<ogra_> if there is no uboot.env file u-boot will fall back to the defaults
<ogra_> (and load uEnv.txt or boot.ini or whatever you have definaed by default)
<zyga> ogra_: hey, I found two bugs in snappy amd64 boot config
<ogra_> file them then
<zyga> ogra_: I'll report them later today after meetings but I wanted to share this
 * ogra_ has never touched the grub stuff ... luckily :)
<zyga> ogra_: first, we use the wrong identifier for the hard drive and snappy really boots by accident
<zyga> ogra_: it should be hd0 instead of hd1 everywhere
<zyga> ogra_: I suspect this is because after the image was generated the grub config generator never ran again
<zyga> ogra_: this makes it boot by accident really, it boots because --
<zyga> ogra_: the filesytem identifiers are used as a fallback and those actually work
<zyga> ogra_: which is the second bug: everyone that downloads the pre-made image will have the same unique identifier
<zyga> ogra_: and then mess happens, boot snappy, plug snappy on a usb drive, reboot -- you will boot into the random one depending on bios
<zyga> ogra_: we should re-generate them on first boot
<zyga> ogra_: like other things (ssh keys)
<zyga> ogra_: I'll file them today, thanks
<longsleep> ogra_: yeah if there is no uboot.env file, my uboot will now fail to boot as i have dropped the boot.ini. But i am also not loading uEnv.txt and in the past this file was used to detect u-boot environment - thus is shipped an empty one and still do.
<ogra_> well, why did you drop the boot.ini code ?
<ogra_> i assume thats just a fatload somewhere in the u-boot default config ?
<longsleep> because it is not needed anymore as everthing is in boot.env
<ogra_> yes, and that means you can keep the old env around
<ogra_> uboot.env will completely replace it if it is there ... if it is not there you fall back to the old methid automatically
<longsleep> Mhm - i thought to clean it up to avoid confusion
<ogra_> well, its a safety net :)
 * ogra_ doesnt want to admit that he is just to lazy to clean that up in his own images :P
<longsleep> mhm - i was thinking to bring back uboot.ini eventually so people can customize "some" variables without modifying the .env file
<longsleep> the .ini file is handy as it supports comments and empty lines
<longsleep> i think these two points are the reason they added it
<ogra_> well, with uboot-go around changing the env vars isnt actually a biggie
<ogra_> but yeah, we dont remove the loading code for uEnv.txt either
<ogra_> so you could use it to override thins
<ogra_> *things
<longsleep> well you have to do it from command line - i was thinking about people who insert the sdcard into some pc and use notepad to edit it
<ogra_> right
<longsleep> there are some things people might want to change, like hdmi resolution, mode, sdcard compatibility
<zyga> ogra_: btw, who's working / looking after the amd64 images?
<JamesTait> Good morning all; happy Hammock Day! ð
<longsleep> ogra_: and in my old boot.ini i was hacking and calling snappy_boot, so i really want to get rid of this
<ogra_> longsleep, just ship an empty one then
<longsleep> yeah i will do that with some examples for customization
<longsleep> this is not possible with uEnv.txt
<longsleep> no comments and no empty lines right?
<longsleep> i mean for the bbb uEnv.txt is just loaded with import -t -r
<ogra_> uEnv.txt is exactly the same
<longsleep> same was what?
<ogra_> comments and all
<ogra_> they are identical ... just differently named
<ogra_> (i never understood why odroid felt they need their own filename)
<longsleep> identical to what ? sorry i am not getting it :)
<longsleep> you mean the boot.ini ?
<longsleep> they are not the same
<longsleep> they are similar
<longsleep> but the boot.ini is parsed differently
<ogra_> boot.ini and uEnv.txt are absolutely identical, just that whoever implemented the odroid uboot bits decided he wants it called boot.ini
<longsleep> no thats not true
<longsleep> boot.ini supports empty lines and comments
<ogra_> i dont think there is any difference in parsing
<ogra_> uEnv.txt too
<longsleep> oh
<ogra_> our beagle and RPi images hsip a uEnv.txt with empty lines and comments ;)
<longsleep> well they have 100 lines parsing code added to u-boot
<longsleep> so let me check that code
<longsleep> i would be happy to use uEnv.txt
<ogra_> heh, seeing the wily-devel ML it looks like slangasek had "a-f day" :)
<ogra_> err ... wily-changes i mean indeed
<longsleep> ogra_: so the code is here: https://github.com/hardkernel/u-boot/blob/odroidc-v2011.03/board/hardkernel/odroidc/cfgload.c - they have logic to load it from muliple locations which we do not need, the rest is about ignoring comments and parsing all with hush. Is uEnv.txt also parsed with hush?
 * longsleep needs to learn about uEnv.txt
<ogra_> if hush is enabled, yeah
<longsleep> ok then - i do not know why they added this cfgload stuff either :)
<ogra_> it might be implemented a few mobnths before the uEnv.txt support landed or some such
<longsleep> mhm well that wile was added end of 2014 - so i guess uEnv.txt support is older
<ogra_> uEnv.txt comes from 2010 or 2011 IIRC ---
<ogra_> might have been 2012
<longsleep> they have some text comparison verifying that the file is for the correct target - maybe that is the reason (it has to start with ODROIDC-UBOOT-CONFIG to be used).
<longsleep> mhm - i still fail to see how "env import" can process stuff like "setenv foo bar" assuming uEnv.txt is the same as boot.ini
<Chipaca> mvo_: approved; sorry for the delay (first day of school holidays!)
<mvo_> Chipaca: no problem at all
<mvo_> Chipaca: I *so* look forward to the school holidays too
 * mvo_ will sleep until noon that day
<Chipaca> :)
<Chipaca> i instead got a supermarket delivery at 6:30am, just to celebrate
<Chipaca> but then went back to sleep \o/
<mvo_> lol
<ogra_> your kids dont show up at your bed at 7 ?
<Chipaca> 6:45
<Chipaca> but he's just started a longish book, so he was lost in it before 7
<Chipaca> i must admit the fact that he's reading "young adult" fiction does bother me a little bit :)
<ogra_> why is that ?
<Chipaca> because he's 10?
<ogra_> nothing to bother about then :)
<Chipaca> that's why the smile :)
<Chipaca> especially considering i was reading LOTR at his age
<ogra_> i had a hang for scifi short stories at that age ...
<Chipaca> (it's my grandpa's fault, as he gave me the best encouragement he could: he told me i was to young to read it)
<ogra_> (i think i was way older before i read LOTR)
<Chipaca> nice, the kvm hung overnight
<longsleep> ogra_: so - from my testing uEnv.txt gets loaded as key=value file - it supports comments, but one cannot use if, or setenv in it. Do you have an example for an uEnv.txt which does that?
<Chipaca> mvo_: anything you'd do different wrt http://pastebin.ubuntu.com/11919018/ ?
<ogra_> lohmm, no
<ogra_> longsleep, hmm, no
<ogra_> longsleep, why do you feel the need for setenv ?
<longsleep> well it all comes down how the uEnv.txt is loaded, in your bbb its just "env imported", the boot.ini is parse_string_outer line by line.
<ogra_> var=value is enough
<longsleep> setenv is not required true
<longsleep> but i need if/else
<ogra_> if/else work inside a var
<ogra_> look at the old snappy-system.txt
<ogra_> i.e. the snappy_boot cmd
<longsleep> well, ok - i need to do this: if test "${vpu}" = "0"; then fdt rm /mesonstream; fdt rm /vdec; fdt rm /ppmgr; fi
<longsleep> i need to run commands inside if/else
<longsleep> and the settings should be controllable by user
<ogra_> mytest=if test "${vpu}" = "0"; then fdt rm /mesonstream; fdt rm /vdec; fdt rm /ppmgr; fi
<ogra_> then you exec mytest from somewhere
<longsleep> ok i guess i could do that
<longsleep> let me try :)
<ogra_> run mytest
<ogra_> ...
<ogra_> snappy_boot=if test "${snappy_mode}" = "try"; then if test ${snappy_trial_boot} = 1; then if test "${snappy_ab}" = "a"; then setenv snappy_ab "b"; else setenv snappy_ab "a"; fi; else setenv snappy_trial_boot 1; saveenv; fi; fi; run loadfiles; setenv mmcroot /dev/disk/by-label/system-${snappy_ab} ${snappy_cmdline}; run mmcargs; bootz ${loadaddr} ${initrd_addr}:${initrd_size} ${fdtaddr}
<ogra_> uenvcmd=run snappy_boot
<ogra_> like that :)
<longsleep> yes, and those vars i could predefine in the .env file even
<longsleep> ok sounds like a plan - thanks
<ogra_> :)
<longsleep> i want to get rid of all hardkernel special stuff if possible, so make it easier to switch to upstream u-boot eventually.
<ogra_> +1
<ogra_> mvo_, do you need an extra approval on https://code.launchpad.net/~mvo/snappy/snappy-bootsuccess-env/+merge/264981 ? i assume we wont get one from sergio this week
<mvo_> ogra_: I self approved now, this branch is obsolete with the env2 one anyway
<ogra_> ah
<ogra_> so now i need to find out how to get the snap into the store
<ogra_> seems it was uploaded by a canonical account
<ogra_> (and i guess both people that could tell me about it are gone this week)
<mvo_> ogra_: so the snappy change is merged, I triggered a ppa build, once that is in the PPA we can do a new image
<mvo_> ogra_: re store,
<ogra_> mvwe need the snap in the store ...
<ogra_> mvo_, we need the snap in the store ...
<mvo_> ogra_: so the snappy change is merged, I triggered a ppa build, once that is in the PPA we can do a new image
<ogra_> and i have not the slightest clue how to get it there
<mvo_> ogra_: re store,  one sec
<mvo_> ogra_: you have a private message with details :)
<ogra_> ah, i need to go to the other machine then :)
 * ogra_ is having brunch :) 
<conyoo> is it possible to rollback more than 1 step? i kinda find it interesting to be able to rollback 12 versions back if i'm crazy. the a/b is nice but the whole alphabet is nicer :D
<ogra_> ii think currently only one step
<conyoo> :'(
<conyoo> oh currently :d
<conyoo> so there is hope!
<conyoo> OMG!
<ogra_> i'm not sure we plan to actually keep all versions of a snap on your disk forever ...
<ogra_> which would be needed for endless rollback
<conyoo> maybe for selected snaps? :D
<conyoo> i don't need all of them, but would be nice to work for selected snaps
<conyoo> i also don't care about disk space
<mvo_> we plan to move to a more flexible way than a/b in the future, but its not done yet
<ogra_> mvo_, thats about app snaps
<mvo_> ogra_: let me know if the msg made it, if not I can also handle the upload
<conyoo> thanks mvo_ and ogra_ :D sounds amazing to me! :D
<ogra_> i guess starting a discussion on the ML might be helpful
<ogra_> mvo_, well ~30min, then i'll be back in the office
<mvo_> oh, app snaps, yeah, we already keep 3 by default iirc, easy enough to keep more
<mvo_> ogra_: thats fine, I get lunch then I think
<ogra_> yeah
<Chipaca> yeah, we'll allow a/b and *also* ð¼/ð½ \o/
<ogra_> greek rollback ?
<ogra_> mvo_, ok, new bealeblack snap sits in review in the store, someone needs to manually approve it
<ogra_> *beagleblack
<longsleep> ogra_: so now that the change is merged - you think i can build a new image which should handle uboot.env ?
<ogra_> longsleep, not yet ... we dont have a new rootfs yet
<longsleep> ogra_: ah yes - that reminds me that i need to learn how to build a rootfs myself
<ogra_> yeah, thats next on my list ... making rootstock-ng work for home builds again
<longsleep> well does it actually matter how the preinstalled tarball is created? I mean building that should be easy. I am only worried about what comes after that - as i have no clue yet :)
<ogra_> after that it gets processed by system-image
<ogra_> which unpacks it and the last tarball, diffs the files and creates a delta tarball
<longsleep> yeah thats the scary part :)
 * longsleep still needs to build a system-image and deltas for odroidc
<ogra_> https://wiki.ubuntu.com/ImageBasedUpgrades/Server
<longsleep> yes i have been reading that a couple of times - until now i found something which was more fun to work on
<ogra_> i'm also not sure it is worth the effort ... eventually your device tarball will become a snap too ... then a system-image server would be rather pointless (as you would just serve the same rootfs we serve)
<mvo_> ogra_: only for rolling right now, correct?
<mvo_> ogra_: the 15.04 backport is not approved yet, but we should focus on that now I guess
<ogra_> mvo_, well i didnt change anything in the package setup on the page ... it had both ticked ... can you just release for one ?
<longsleep> ogra_: i am not so sure yet, i might require changes to the rootfs or some software inside it. Or for the paranoid, i might want to have self compiled versions of everything
<mvo_> ogra_: I think no, will it still install the old files? i.e. will a old snappy still work?
<ogra_> longsleep, that breaks snappy design though ... you should put your extra bits into snaps people can install at build time of the image
<mvo_> ogra_: eh, nevermind, of course not
<ogra_> mvo_, uEnv.txt is empty
<mvo_> ogra_: meh, ok
<mvo_> ogra_: I will ask Chipaca for another review then :)
<ogra_> yeah, then we can blame him if it breaks, good idea :)
<mvo_> ogra_: thats the idea, right? its always the reviewers fault
<ogra_> yup
<mvo_> ogra_: unless I did the review in which case its the original authors fault
<ogra_> *indeed* !
<mvo_> Chipaca: if you have a moment, could you plese check https://code.launchpad.net/~mvo/snappy/15.04-snappy-bootsuccess-env2/+merge/265510
<Chipaca> I shall consider it.
<longsleep> ogra_: yes, but what about images for certain hardware which come with pre installed stuff?
<mvo_> Chipaca: meh, I just noticed it may miss a upstream revision, let me quickly double check
<ogra_> longsleep, same thin
<ogra_> g
<ogra_> longsleep, your extras should be in snaps
<longsleep> ogra_: ok i see - can the snap modify base behavior? Like add or change systemd services ?
<ogra_> theoretically yes, not sure how that will practically work ... but confinement is something we enforcxe artificially so you can indeed work around it (as long as a store reviewer approves it)
<mvo_> Chipaca: ok, should be ready now
<longsleep> ogra_: what about third party devices with custom behavior, do these have their own store then?
<ogra_> i guess so
 * ogra_ doesnt know the exactly planned setup for that 
<longsleep> ogra_: ok, that is probalbly soemthing i need to investigate more then.
<ogra_> yep
<ogra_> beuno should be abck next week, he can elaborate
<ogra_> *back
<beuno> well, don't kick me out just yet!
<longsleep> :D
<ogra_> hey, didnt you mail that you are vacating ?
<beuno> tomorrow and thu!
<beuno> er, tomorrow and fri!
<ogra_> ah
<beuno> longsleep, we're still working out the details on how to support third-party devices that need to break out of confinement. We can point you to the commercial team to help you flesh that out if you'd like
<longsleep> beuno: Yeah - i just had a call with Marteen and he sent an email to connect me with lool
<beuno> ah, perfectd
<longsleep> but i also would prefer to have as less customizations as possible. So i am checking all the possibilies here. Not sure if it really needs to break out of confinement.
<lool> longsleep: hi!
<longsleep> I have control on uboot, kernel, snaps and device part. Device part will become a snap eventually. What i need in addition is a customization like some post image build scripts.
<lool> longsleep: just read through Maarten's email; reading the fwded one now
<longsleep> lool: hey - no hurries
<lool> longsleep: ok, done reading, and BTW well done on the ODROID-C OEM snap  :-)
<lool> longsleep: I didn't find details of the questions around SSL and ports; is this written up somewhere in email or bug?
<longsleep> lool: thanks - that was the easy part. Getting the thing doing the same as with normal ubuntu is the hard part.
<longsleep> lool: i sent some points to the mailling list in the past, and i have added some stuff to the tracker as well.
<dholbach> rsalveti, do we have much of an agenda for the snappy community call?
<ogra_> oh, i totally forgot about that one
<ogra_> no asac today too
<longsleep> lool: bot i think its best explained all together rather to get the idea
<dholbach> rsalveti, I had a few days off so not too much to report on my side
<longsleep> lool: right now it comes down to entropy, having a NGINX framework so many snaps can share port 443 and SSL setup
 * ogra_ was busy with technical stuff the last days ... 
<ogra_> not much from my side either
<lool> longsleep: I see
<lool> longsleep: I think it's a great thing to provide
<lool> longsleep: so in general, we have not been mandating how this or that should be designed but rather gave a set of primitives (like frameworks and apps) as to let various experiences bloom
<lool> longsleep: and then we see what picks up and makes the most sense
<lool> longsleep: I think it's a wonderful example
<lool> longsleep: in general, framework provide services typically in the sense of a shared resource; port 443 is one; entropy pool is another; great things to expose in a framework
<lool> longsleep: how would the API be? apps depend on your nginx-based framework and register a name over HTTP/REST to localhost to get traffic forwarded to them for /name/ or for name.xyz?
<longsleep> lool: yes something like that - not sure if it needs to be an api though. In non snappy we just have a conf.d folder where packages can put their configs.
<ogra_> well, you could have snappy config do it from your oem snap
<ogra_> snappy config can use script hooks to apply the config
<longsleep> lool: and the entropy one is tricky, on first boot keys need to be generated - it needs to be ensured that there is entropy available. Right now it creates key with essentially no entropy on first boot.
<longsleep> ogra_: ok, snappy config - thats something i need to investigate then. Is that only for oem snaps or also for software snaps?
<lool> longsleep: so apps (and frameworks) are sandboxed as to prevent apps to see files from other apps; there needs to be a provisioning mechanism; we dont want maintainer scripts, but you could have data bits
<ogra_> longsleep, thats for all snaps
<ogra_> but in context of oem it can indeed be more powerful
<lool> I dont think config hook will help to cross app barriers
<ogra_> no, but to alter system defaults without having to hack the rootfs snap
<lool> the idea of config hooks if to have a standard interface for one snap to load/dump its config in YAML
<ogra_> (or tarball)
<ogra_> what longsleep wants, as i understand is some firstboot config to be applied
<ogra_> for that the config hooks in the oem snap should be fine
<longsleep> only if applying that would block boot
<longsleep> or start of systemd services
<longsleep> i mean, the problem exists today. The SSH keys are generated on first boot with essentially no entropy.
<longsleep> Thats why i think the problem needs solving on snappy level.
<lool> we're discussing two different things
<ogra_> well, on a cloud-init level
<lool> one is the entropy, the other is providing nginx to other apps
<longsleep> yes true
<longsleep> lets talk nginx first
<longsleep> i was thinking to have something similar to the docker framework
<longsleep> it essentially the same
<longsleep> provide outside resouces to snaps
<longsleep> right?
<lool> yup, kind of
<longsleep> right now i would have to ship nginx inside my snap
<longsleep> instead i could create a nginx snap
<longsleep> and somehow depend on it
<longsleep> are frameworks snaps too?
<lool> so generally, we are not trying to use frameworks as a mean to distribtue dependencies
<lool> liek packages were
<lool> snaps are apps
<ogra_> yes, frajmeworks are snaps
<lool> fully contained
<lool> frameworks are to deliver a service or access to a shared resource
<longsleep> yes
<lool> for instance, a bluetooth service
<lool> but if the goal is to make it easy for an app to embed a HTTP server like nginx, then I think this is more of a snapcraft topic
<lool> which is the optional developer tool to create snaps
<longsleep> mhm not sure - that would mean there would be multiple nginx running
<lool> with snapcraft, you can say "embed a java runtime in my snap"
<lool> similarly, you might want to embed a HTTP server
<lool> yes, multiple HTTP servers running is fine
<lool> obviously not on the same port
<longsleep> not on the same port - and they all would need access to the same private key
<lool> not necessarily
<lool> that's if they serve the same site
<longsleep> true
<lool> so perhaps it would make sense to discuss the larger problem you're trying to solve
<longsleep> right now we have a bunch of micro services all providing HTTP web server. To the outside they get exposed with specific configuration by Nginx TLS on 443/tcp
<lool> is it to make it easy to server a bunch of websites from a snappy install?
<longsleep> well, if web sites mean differnt domains then no.
<longsleep> its about exposing web services on port 443/tcp with a secure TLS configuration.
<longsleep> lets take the example from spreed-webrtc
<longsleep> its a go service, wich listens on port 8080/tcp
<longsleep> it needs to be exposed to the world on port 443/tcp with tls
<longsleep> it could do that itself or the snap could include a web service which does it
<lool> longsleep: is there an architecture diagram of spreed somewhere?
<longsleep> sure
<longsleep> hold on
<longsleep> but spreed-webrtc is simple
<longsleep> in the default setup it has only one end point
<lool> longsleep: yes, but rather than discussing bottom up, I'd like us to have a top down discussion
<longsleep> let me upload it
<lool> longsleep: for instance, from my naive understanding, I understand that this is about delivering spreed easily; I instinctively think this shoud be implemented by delivering a single spreed snap that offers the whole thing with hardcoded configs for most things, then exposing more and more features
<longsleep> lool: yes - but that only works if no other snap uses port 443.
<lool> longsleep: basically, the closest thing that matches this for me is how I'd run Kodi on an Android device
<lool> I'd install the Kodi app
<lool> and then run it
<ogra_> and perhaps have snappy config options to en/disable single spreed bits
<lool> in the first version, this would not expose all the crazy advanced features like the web services for the remote control or the storage abstraction or etc.
 * ogra_ tried a kodi snap on the weekend but failed to build a static binary *sniff*
<longsleep> lool: can you go to https://spreed.me/struktur/longsleep and i share the diagram with you there
<lool> longsleep: so port conflicts are a real issue; we need to provide a definitive solution for this, but for now I'd say take port 443 by default, make the port configurable in the config hook and let anyone install the app; if the port is free, it's used, otherwise it's configurable
<lool> longsleep: I have a personal opinion on how we should solve the port issue, but I dont think it was discussed
<lool> longsleep: the current plan was around having an API to negociate/reserve ports
<longsleep> lool: ok - what about muliple ips - do you have ideas around that as well?
<lool> my personal opinion is that we should start apps in some kind of network namespace where they can do what they want and some core snappy config allows routing host ports to snappy apps
<mvo_> Chipaca: \o/
<Chipaca> :)
<ogra_> lool, sounds like ubuntu-fan for ports :)
<lool> longsleep: I'm there
<longsleep> lool: ok - i shared the file with you.
<rsalveti> longsleep: https://wiki.ubuntu.com/Snappy/CoreImageBuild as well
<rsalveti> dholbach: we can do a short call, just wanted to talk about snapcraft quickly
<dholbach> sure
<lool> longsleep: got it
<longsleep> so you see Nginx STUN and TURN
<longsleep> In the simple case we have only Nginx
<longsleep> that is on port 443
<longsleep> but what if we want to have a TURN server as well
<longsleep> that would be a different snap
<longsleep> also needs to listen on port 443
<longsleep> different IP
<longsleep> or if we would add other backend services
<lool> longsleep: ok, so what's the minimal first version we could target? coudl we do everything on top of User 2 in a single snap to start with?
<longsleep> yes that is no problem
<lool> longsleep: BTW, checkout snapcraft; it's alpha but it allows bundling binaries from .debs easily
<lool> I've used it to embed a java runtime and tomcat with a webapp
<longsleep> lool: Maarten told me about this today
<longsleep> will check it out for sure
<lool> longsleep: (NB: I have a call tunnel starting now and going 4 hours)
<lool> 4.5 actually
<longsleep> no problem
<lool> but I'm reading IRC
<longsleep> think about the entropy problem though
<longsleep> that is more critical :)
<longsleep> thanks for your time
<lool> longsleep: so are STUN and TURN typically provided / deployed with spreed?
<lool> are you saying the second IP is mandatory?
<longsleep> no they are optional
<longsleep> but you should have a STUN server somewhere
<longsleep> and a TURN server too for firewalled users
<lool> longsleep: ok; entropy... again super naive thought, but we do that in all our cloud images: they boot and get some entropy from linux to generate a SSH key (I guess /dev/random provides a limited amount thanks to entropy of network traffic?)
<longsleep> eg on our deployments they are all installed and that requires 3 IP's even. But the spreed server works fine with one.
<lool> longsleep: are the TURN/STUN bits typically provided with the spreed codebase?
<longsleep> lool: no it is a separate software
<lool> longsleep: are the TURN/STUN generally useful with non-spreed use cases?
<longsleep> lool: cloud images are a little different, they have most likely network connection on first boot and load entropy from your entropy service. While i find that scary too at least the keys are fine assuming the entropy service is providing good random.
<lool> (I know what kind of services these provide, just not sure if these are typically used outside of spreed in general)
<longsleep> lool: yes sure, many services require / can use a STUN/TURN service
<kyrofa> ogra_, since i2c isn't enabled on the rpi2, does that mean the GPIO works out of the box?
<lool> longsleep: I can't really judge on this question product-wise, but I see two ways this could be done: either bundle all the software in a spreed snap, with 3 sets of services; second and third set of services would be disabled by default but could be enabled from a tunable
<ogra_> kyrofa, no
<lool> longsleep: would also expose config to set IP address to use
<longsleep> lool: yes - that is possible. No problems here - though i wanted to avoid problems when people have other snaps also binding port 443 (current example is the ownlcoud snap).
<kyrofa> ogra_, can I get it to work, or is it in a similar situation to i2c?
<ogra_> you need to have the bootloaders load the overlay dtb files that are needed for this ... and it will onyl work with ppisati's new kernel which will only be in the next image
<kyrofa> ogra_, alright, thanks for the info :)
<ogra_> mvo_, E: Build-Depends dependency for ubuntu-snappy cannot be satisfied because the package golang-uboot-go-dev cannot be found ...
<ogra_> anything to worry about ?
<ogra_> https://launchpadlibrarian.net/212301215/buildlog.txt.gz
<mvo_> ogra_: yeah, I coped the depenency but looks like it was only copied but not published
<mvo_> ogra_: I'm sitting here very  impatiently
<mvo_> ogra_: fwiw, I started a wily image build now, that should have the real deal
<ogra_> ah, sweet
<mvo_> ogra_: and once the golang-uboot-go package is available on vivid we can test that too
<ogra_> yup
<mvo_> ogra_: yay, build! now once that is published we should have a 15.04 test image
<ogra_> cool .... i'll test after the call
<ogra_> (assuming it ever ends so dholbach can go back to comb his moustache )
<kyrofa> Has anyone tried doing something with apache or nginx on snappy?
 * longsleep has tried nginx
 * ogra_ has done a few nodejs snaps 
<kyrofa> longsleep, any luck? Did you make it a framework and make a website snap or something?
<ogra_> you should put it inside your snap
<longsleep> kyrofa: did not make a framework - had it in a snap
<kyrofa> ogra_, interesting. How would I install multiple website snaps that way? (i.e. a fight over ports 80 and 443)
 * dholbach slaps ogra_ :)
<longsleep> kyrofa: yeah we just had that discussion. Nginx framework might be handy
 * ogra_ hands dholbach https://vimeo.com/111123707
<ogra_> :)
<kyrofa> longsleep, interesting, I wonder how tough that would be. I'll look into it if you think that such a framework is possible
 * ogra_ doesnt think a webserver is actually suitable for frameworks ... but looks like lool disagrees above
<kyrofa> ogra_, how else to you get around the port fighting?
<longsleep> kyrofa: well we will see how it goes
<ogra_> kyrofa, see backlog that was discussed above ...
<ogra_> most likely by providing a port controlling service inside snappy
<kyrofa> ogra_, oh, you were _literally_ just discussing it! Okay :)
<ogra_> well lool told us his vision ... the discussion is still outstanding
<ogra_> mvo_, hmm, udf for 15.04 edge still gets me image 124 (the same i had yesterday)
<mvo_> ogra_: you are too quick, wily is still building and 15.04 is not even publised yet
<ogra_> oh, ok
<mvo_> ogra_: so once snappy is published I will trigger a build and let you know, ~30min at last
 * ogra_ gets fresh coffee and a cigrarette 
<ogra_> yeah
<mvo_> yay, tea
 * mvo_ jumps with joy
 * ogra_ jumps along
 * Chipaca starts getting "unusable private key" from gpg, and is sad
<mterry> elopio, even in your branch names, you like underscores  ;)  ~elopio/snapcraft/integration_coverage
<Chipaca> ooh! it's key day!
<Chipaca> mvo_: you got a bit?
<mvo_> Chipaca: sure
<elopio> good morning.
<elopio> mterry: we should pep8 also our branch urls :)
<mterry> :)
<elopio> zyga: is there a way to make less verbose the output of plainbox, in case all the tests pass?
<zyga> elopio: hey
<zyga> elopio: yes
<zyga> lool: https://bugs.launchpad.net/snappy/+bug/1477178 (the stuff I mentioned today)
<ubottu> Launchpad bug 1477178 in Snappy "Snappy prebuilt images have very non-unique filesystem identifiers" [Undecided,New]
<lool> zyga: yup
<zyga> elopio: you can provide a different UI, I can show you how to do that tomorrow after my chain of meetings
<zyga> elopio: I suspect we could also use a more silent UI as an option, this is all related to using plainbox as a simple unit-test runner
<zyga> elopio: can we work on that sometime tomorrow afternoon CET?
<mvo_> ogra_: both wily and 15.04 are build, we just wait for arm64, iirc the import will only start if all arches are build, but maybe (hopefully) I misremember that
 * ogra_ taps foot 
<ogra_> i shoudl grow a moustache too so i could comb it while waiting
<genii> Also good for straining your soup
<ogra_> yeah, and keep something for bad days
<longsleep> for some reason a bunch of parameters to the kernel get lost from uboot to dmesg - someone seen that before?
<elopio> zyga: tomorrow around this time would be ok. Thanks.
<elopio> mterry: can I move the snapcraft.dirs.setup_dirs() inside snapcraft.main.main() ?
<elopio> I think main should do everything.
<mterry> elopio, probably?  No one calls main() without doing that, I assume?
<kyrofa> seb128, just a heads up: I believe a newly built version of the snappy scope hit the NEW queue yesterday. The newest version of lintian caught some duplicate licenses in debian/changelog, so that's been fixed now
<seb128> kyrofa, k, great, I reviewed it yesterday and it looked good, let me NEW it
<longsleep> ah - it was uEnv.txt seems it cannot handle lines like var=value # comment
<ogra_> longsleep, what kind of parameters ?
<ogra_> ah
<ogra_> yeah, i think they cant be on the same line
<kyrofa> longsleep, how dare you comment your variables :P
<longsleep> yes comments at end of lines get included in the variable value and then magically scripts handle the # and stop afterwards :D
<ogra_> sounds like a bug though
 * longsleep will never comment variables again - not!
<kyrofa> longsleep, I bet that was tough to find
<longsleep> not really - i am used to u-boot problems by now :)
<elopio> fgimenez: I'll work on your comments for the rollback, so lets skip our meeting today.
<elopio> let me know here if you want me to do something this evening.
<longsleep> that explains why the kernel crashed before - i had variable values with hashes at the end
<ogra_> well, if you need the hash sign you should be able to use single quotes
<longsleep> right, but it was just the comment
<longsleep> moving the comments into extra lines works just fine
<longsleep> stil the 4k monitor i got here does not even now then i changed to dvi mode :(
<tedg> Uhg, three QML apps installed and ran out of space in my VM.
<zyga> elopio: nice
<fgimenez> elopio, fine, i'll continue with the integration tests job, hopefully i'll push something for you to try today
<elopio> fgimenez: now we can talk about putting all the tests in the tests package. That would be merging the current cmd and failover dirs.
<elopio> do you prefer to have them separated?
<fgimenez> elopio, now it doesn't make too much sense, having them unified would simplify the filtering and would consolidate the output dir
<elopio> fgimenez: ok, I'll get to that too.
<fgimenez> elopio, ok thx
<Chipaca> zyga: wrt uuids, have you tried rolling? we no longer use uuids in grub
<Chipaca> zyga: in fact i thought that was already in 15.04
<Chipaca> but i'm not the bestest at tracking what we backported and what not
<Chipaca> (that would be mvo)
<mvo_> we never use uuids, did we?
<mvo_> not in 15.04
<Chipaca> mvo_: before i cleaned up update-grub, we got uuid cruft in there
<Chipaca> mvo_: s/i/we/
<Chipaca> mvo_: this is wrt https://bugs.launchpad.net/snappy/+bug/1477178
<ubottu> Launchpad bug 1477178 in Snappy "Snappy prebuilt images have very non-unique filesystem identifiers" [Undecided,New]
<ogra_> Chipaca, does that even matter at all, since we fall back to the right thing anyway ?
<Chipaca> ogra_: zyga seems to think it does :)
<ogra_> as long as we end up booting the right thing ...
<zyga> Chipaca: I didn't but this should be fixed in stable as well
<zyga> Chipaca: I'd love if you could look at my inception snap if you have a moment
<zyga> Chipaca: and if you could tell me more about how /boot/grub/grub.cfg (as in 15.04 image) came to be
<zyga> Chipaca: as IMHO it's broken in other ways
<zyga> Chipaca: it looks like it was generated when /dev/sdb was snappy
<zyga> Chipaca: all the identifiers there refer to hd1
<zyga> Chipaca: but if you inerrupt grub and go to grub console
<Chipaca> zyga: http://pastebin.ubuntu.com/11920503/
<zyga> Chipaca: ls hd<tab><tab> will show you that snappy is actually on another disk
<Chipaca> zyga: i have no idea what grub.cfg you're looking at; i don't think we've ever explicitly refered to hdX
<zyga> Chipaca: is that rolling?
<zyga> Chipaca: look at the one on ubuntu.com snappy website :)
<zyga> Chipaca: I can pastebin that in a moment
<ogra_> smells a bit like something ran update-grub or some such
<zyga> ogra_: yes
<zyga> ogra_: likely
<ogra_> (which i think we ripped out completely by now)
<ogra_> (luckily)
<zyga> ogra_: we should kill non-snappy /etc/grub.d/ bits
<Chipaca> zyga: we no longer use update-grub at all
<zyga> ogra_: that sounds good, so without that, and with uuids fixed, it should be better
<zyga> Chipaca: btw, when you said you don't use uuids
<Chipaca> but, again, dunno about 15.04 stable; checking 15.04 edge right now
<zyga> Chipaca: does that mean they are changed on first boot
<zyga> Chipaca: because if not you will still get mess while booting
<Chipaca> zyga: not as far as i know
<Chipaca> zyga: why will we get a mess?
<zyga> Chipaca: e.g. you boot with labels and labels are terribly nonunqie
<zyga> Chipaca: boot snappy preinstalled with snappy usb
<zyga> Chipaca: you boot to ... usb
<ogra_> but non-unique is exactly what we want
<zyga> ogra_: why?
<zyga> Chipaca: btw, what is /prefix there
<ogra_> zyga, today i can boot from SD, plug in a USB key, make a partition and label it "wrtitable" ... move the content from the SD writable partition and delete it there .... and snap my writable space on the RPi is 1TB
<zyga> ogra_: yes, that's all fine
<ogra_> same goes for a and b
<zyga> ogra_: but it break if you have two snappy-like partitions around
<ogra_> yes, you shouldnt
<zyga> ogra_: that's unreliable, it should not break just beacuse I happen to have snappy dual boot
<zyga> ogra_: no, the system should keep working
<Chipaca> 15.04 edge is an update-grub--generated file, but no mention of hdX
<zyga> ogra_: and the right way to do that is to use unique partition IDs
<ogra_> zyga, well, the whole setup is still totally in flux
<ogra_> zyga, we might end up with only two partitions for everything
<zyga> ogra_: and the use case you want is a developer feature, I'm sure you can hack your boot conf to mount those by label
<zyga> ogra_: oh, nice
<ogra_>  /boot and writable
<zyga> ogra_: what's the intended layout?
<zyga> brb
<Chipaca> zyga: âGRUBâs normal start-up procedure involves setting the âprefixâ environment variable to a value set in the core image by grub-install, setting the ârootâ variable to match, loading the ânormalâ module from the prefix, and running the ânormalâ command (see normal). This command is responsible for reading /boot/grub/grub.cfg, running the menu, and doing all the useful things GRUB is supposed to do.â
<Chipaca> zyga: IOW, $prefix is set by grub on startup; it points to the grub directory (whatever holds grub.cfg)
<Chipaca> zyga: https://www.gnu.org/software/grub/manual/html_node/GRUB-only-offers-a-rescue-shell.html
<zyga> Chipaca: thanks
<zyga> Chipaca: I spent ~10 hours in grub this week :D
<zyga> Chipaca: found lots of goodies
<zyga> Chipaca: and learned a lot
<ogra_> zyga, moving the a and b readonly partitons to be squashfs images ion /boot instead of partitions
<zyga> ogra_: oh, great
<zyga> ogra_: that's even more interesting
<ogra_> :)
<zyga> ogra_: so they are mounted from squashfs
<Chipaca> zyga: i spent a little bit of time on it to pare grub.cfg down to what i pastebin'ed; i'm sure it's missing stuff (e.g., does it work on xen?), but it's at least a sane starting point
<ogra_> zyga, right
<zyga> ogra_: will that follow to .snaps?
<zyga> how can I get rolling?
<zyga> I'd like to try that
<ogra_> zyga, sergiusens and mvo are currently researching that setup
<Chipaca> o ubuntu-device-flash core rolling --oem=generic-amd64 --channel edge -o wily.img --developer-mode
<Chipaca> zyga: ^
<zyga> Chipaca: do I need to be on willy?
<zyga> wily
<Chipaca> zyga: s/^o/sudo/ :)
<zyga> (I always want to say willy)
<zyga> :D
<Chipaca> zyga: there's a ppa for legacy releases like utopic
<Chipaca> :)
<Chipaca> zyga: the "tools" ppa
<zyga> Chipaca: i'm on vivid
<zyga> and I have ...
<zyga> deb http://ppa.launchpad.net/snappy-dev/tools/ubuntu vivid main
<Chipaca> zyga: should work, then
<zyga> nice, I'll try that
<zyga> I have a dedicated snappy test box
<zyga> to try various cert magic on
<elopio> mterry: I don't fully understand the current behaviour of log. Your idea was to use print from plugins and snapcraft.common.log from snapcraft itself?
<Chipaca> zyga: on first boot you might not get ethernet; a reboot should fix it
<Chipaca> zyga: also note "rolling" is code for "we break it all the time"
<zyga> Chipaca: I though that was "rawhide" ;-)
<ogra_> dude !
<Chipaca> zyga: "rawhide" is code for "*they* break it all the time"
<ogra_> wrong distro
<zyga> ogra_: I know that
<ogra_> :)
<mvo_> mterry: given that we have no python3-fixtures on tarmac right now I wonder if we should just merge manually right now. sucks but sucks to be blocked by tarmac too
<zyga> Chipaca: I'm woring on a solution for automatic testing machines that don't do netbooting
<zyga> Chipaca: e.g. xps13 over wifi
<zyga> Chipaca: I _may_ have some suggestions for boot parts as I go
<zyga> Chipaca: where can I target that as patches?
<zyga> Chipaca: (though x86 only atm)
<Chipaca> zyga: um, depends on the patch i guess? asking here is a good place to start
<zyga> Chipaca: where does grub part live?
<Chipaca> ogra_: we should rename 'stable' to 'rawhide', to see if they're paying attention
<zyga> Chipaca: I'm only interested in that for now
<ogra_> lol
<Chipaca> zyga: split between u-d-f and the generic-amd64 part, afaik
<ogra_> "rawhide tumbleweed" then
<zyga> ogra_: no, no
<zyga> ogra_: rawhide tumbleweed 10 X
<zyga> then it'll work
<zyga> Chipaca: where do they live?
<Chipaca> zyga: lp:~snappy-dev/snappy-hub/snappy-systems
<Chipaca> zyga: or lp:goget-ubuntu-touch for u-d-f
<zyga> thanks
<zyga> I got the first one, getting the second
<zyga> (and my boot beagle patch is merged now ^_^)
<Chipaca> I'm not sure we don't have logic in livecd still; sergio would know but he's away doing critical feature work
<zyga> Chipaca: aka putting the big fire out ;) ?
<Chipaca> zyga: aka having a kid
<zyga> Chipaca: how does livecd fit into place?
<zyga> ah
<Chipaca> :)
<zyga> yeah, that takes a while
<zyga> like 30 years ...
<Chipaca> *sigh*
 * Chipaca is 10 into that
<zyga> :D
<zyga> Chipaca: I'm 8
<ogra_> and i always thought you looked older
<Chipaca> zyga: i'm not *sure*, but i think we use livecd-rootfs to create the rootfs
<zyga> mmm
<ogra_> we do
<Chipaca> ogra_: it's the beard
<ogra_> yeah :)
<Chipaca> but that's descending into handwavy "sergio and ogra get a room, and magic happens, and we get an image" territory
<zyga> :DD
<ogra_> mvo_, damn ... i just found out the image doesnt boot .... if you dont plug the SD into the slot ...
<Chipaca> ogra_: the image that is on the SD?
<ogra_> Chipaca, yeah
<Chipaca> ogra_: stop the line! that's a critical bug
<zyga> ogra_: ;-)
<Chipaca> :)
<zyga> ogra_: use the force
<zyga> ogra_: make it boot
<ogra_> looks fine if i pluig it in though :)
<mvo_> ogra_: I'm still waiting for the dd to finish, godd tells me 2m:50s
<mvo_> but I think its lying
<zyga> ogra_: do you remember that weird remote SD card from linaro?
<zyga> ogra_: I hear you can get some
<zyga> ogra_: if you ask the right person
<zyga> ogra_: if you are tired with waving that SD card around all the time
<kyrofa> Chipaca, sergio is having a kid?
<ogra_> mvo_, so whats the command to change the uboot vars now, how did you call the final binary ?
<kyrofa> Chipaca, that's awesome!
<zyga> ogra_:
<ogra_> kyrofa, he already had ... now he is having insomnia
<zyga> er...
<zyga> tab up mess
<kyrofa> ogra_, yeah, I know how that goes. I have a 1-year-old myself
<mvo_> ogra_: there is no command (but fw_printenv, fw_setenv will work). its all part of the library that is used from inside snappy
<ogra_> mvo_, hmm, i dont see the config in /etc
<ogra_> (note i'm on 15.04 edge)
<mvo_> meh, right, its only in edge. do you "just" need it for debugging?
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ ls /etc/fw*
<ogra_> ls: cannot access /etc/fw*: No such file or directory
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ sudo fw_printenv
<ogra_> Cannot parse config file: No such file or directory
<mvo_> I need to add it for 15.04 to livecd rootfs too if we need it
<ogra_> well, i need to set the boot to "try" no ?
<ogra_> i'll do it from the uboot prompt
<mvo_> ok
<ogra_> yawn ... cloud-init ...
<ogra_> mvo_, hmm, so booting with "try" still boots from a/
<ogra_> shouldnt it have switched to b ?
<mvo_> ogra_: did you also set snappy_ab=b ?
<ogra_> no, just try
<mvo_> ogra_: both need to be set
<ogra_> oops
 * ogra_ retries
<mvo_> ogra_: no worries, try is actually more logical
<ogra_> at least i havent managed to trash it yet
<mvo_> I mean, its more logical that you set it to try and it automatically toggles
<ogra_> in 5 boots
<mvo_> a good sign!
<ogra_> and i always find snappy_mode=regular when i reset the board
<ogra_> so snappy updates the var properly
<ogra_> hmpf
<ogra_> still boots from a/
<ogra_> even with both set
<ogra_> but still no corruption at least
<ogra_> ubuntu
<ogra_> bah !
<mvo_> ogra_: same here on wily, boots from "a"
<mvo_> ogra_: cloud-init is soooooo slow
<mvo_> but snappy_ab is set to b hmmmm
<ogra_> yeah, cloud-init is a pain
<ogra_> really wastes my time
<mvo_> hm, snappy_trial_boot may also needs to be set to 1
<ogra_> my snappy_ab is properly re-set to a
 * mvo_ tests
<longsleep> mvo_: do i can try a new image too now? 15.04 edge?
<mvo_> longsleep: yes
<ogra_> oh !
<longsleep> mvo_: ok great
<ogra_> shouldnt it set snappy_trial_boot ?
<mvo_> longsleep: or rolling for now, the fw_setenv/printenv is not working yet on 15.04
<ogra_> i dont see that here
<mvo_> ogra_: ups, silly me
<mvo_> of course
<ogra_> is that snappys fault or uboots
<ogra_> oh, i see ... snappys
<mvo_> oh?
<ogra_> well, snappy needs to set it to 1
<mvo_> set what to 1?
<ogra_> if test ${snappy_trial_boot} = 1; then
<longsleep> ogra_: what channel should i use for rolling?
<ogra_> that wraps around the ab logic
<mvo_> ogra_: the bootloader sets this, snappy just resets it
<mvo_> ogra_: thats how its done in grub at least
<ogra_> oh, ok
<mvo_> ogra_: and its doing this, no? in the else setenv part?
<ogra_> setenv snappy_trial_boot 1
<ogra_> bah
<ogra_> efocus
<ogra_> U-Boot# setenv snappy_trial_boot 1
<ogra_> U-Boot# setenv snappy_mode try
<ogra_> U-Boot# setenv snappy_ab b
<ogra_> U-Boot# saveenv
<ogra_> lets see
<ogra_> sigh  ... still a/
<longsleep> this logic is in uboot only / independent from the booted system isnt it?
<mvo_> hm, thats confing indeed "printenv snappy_ab
<mvo_> snappy_ab=b
<mvo_> "
<mvo_> but on boot it runs from a/
<ogra_> longsleep, no, snappy adjusts the values after boot
<longsleep> mhm i got an error when building the image - it failed to extract my oem snap.
<mvo_> ogra_: could it (uboot) read stuff from snappy-system.txt still? that has snappy_ab=a in there
<ogra_> mvo_, must be snappy that resets it ... snappy_trial_boot is actually completely gone from uboot.env after i booted ...
<longsleep> snap failed to install unpack failed with exit status 1
<mvo_> ogra_: yes, thats part of the firstboot job to unset it
<ogra_> while a saveenv on the uboot prompt (even witrhj a reset afterwards) has the var
<ogra_> mvo_, unset or set it to 0 ?
<mvo_> unset
<mvo_> remove
<ogra_> not good i think
<mvo_> I could change it so that it sets it to zero
<mvo_> why?
<ogra_> i think we need a boolean here
<mvo_> oh, ok
<ogra_> so we at least know the corruption is gone
<ogra_> i did like 20 boots now ... and each time uboot.env was modified
<mvo_> ogra_: easy to fix, but it does not explain why it boots a/ instead of b/ if you set it in the uboot prompt manually - or does it?
<ogra_> nope
<mvo_> ogra_: yay! corruption free booting
<ogra_> i wonder if its a quoting issue
<ogra_> U-Boot# setenv snappy_boot if test "${snappy_mode}" = "try"; then if test "${snappy_trial_boot}" = 1; then if test "${snappy_ab}" = "a"; then setenv snappy_ab "b"; else setenv snappy_ab "a"; fi; else setenv snappy_trial_boot 1; saveenv; fi; fi; run loadfiles; setenv mmcroot /dev/disk/by-label/system-${snappy_ab} ${snappy_cmdline}; run mmcargs; bootz ${loadaddr} ${initrd_addr}:${initrd_size} ${fdtaddr}
<ogra_> syntax error
<ogra_> wow
<longsleep> put single quotes around the value
<kyrofa> seb128, I'm making an MP to get unity-scope-snappy into the Personal seed (thanks for pushing that through!)
<seb128> kyrofa, yw!
<kyrofa> seb128, but as I mentioned previously, it does depend upon WebDM
<seb128> did it work out of the box? I didn't try yet
<kyrofa> seb128, which is only a snap
<longsleep> mvo_: so - when i try to build the image with rolling it gives me an error that my oem snap fails to install. Any idea?
<seb128> so if you snappy install webdm it should work?
<ogra_> not a quoting issue then ... still boots from a ... :/
<longsleep> mvo_: 15.04 creates image fine with the same oem snap
<kyrofa> seb128, normally yes, but webdm isn't in the Personal channel, so you have to sideload it. But then, yes :P
<mvo_> longsleep: are you on trusty ? latest tools from the ppa:snappy-dev/tools ?
<seb128> kyrofa, can you get it in the personal channel?
<longsleep> mvo_: i am on vivid - let me check if there are updates
<seb128> unsure how to do that
<mvo_> longsleep: oh, ok. maybe its a issue with rolling then, I'm not aware of one though
 * mvo_ needs to get some dinner, bbiab
<kyrofa> seb128, I pinged sergiusens about it last week, but apparently he just had a baby
<kyrofa> Maybe rsalveti can help us here
<seb128> oh, ok
<seb128> sergiusens, congrats ;-)
<mvo_> longsleep: aha, I think its a race or something, I had this too
<mvo_> longsleep: no, meh, I think its something else
<kyrofa> seb128, so let's pretend it's in the Personal channel. Can I modify something else in this branch to make sure it's included, or is it something special we're going to have to add to the u-d-f incantation every time we make an image?
<seb128> kyrofa, no idea, that's an udf/sergiusens question
<kyrofa> seb128, alright, so you're not preloading any snaps at the moment then?
<longsleep> mvo_: http://paste.ubuntu.com/11920858/ that shows both outputs
<mvo_> longsleep: yeah, I think its "failed to find user uid/gid" thats the culprit
<kyrofa> seb128, alright, I should probably hold off on adding this to the seed until it works out of the box, yes?
<longsleep> mvo_: ok - is that something i could change in my snap?
<mvo_> unfortunately not, let me build you a new 15.04 image for now until this issue is fixed
<longsleep> mvo_: that would be awesome
 * longsleep wonders how ogra_ did it 
<kyrofa> seb128, perhaps I'll make an MP, but make a note of the prerequisite?
<longsleep> mvo_: do you want me to add the issue to the tracker?
<mvo_> longsleep: yes, set it to critical please, I think its because we renamed the snap user from clickpkg to snappypkg in rolling
<longsleep> mvo_: ok
<ogra_> longsleep, i'm testing 15.04 rolling here
<mvo_> longsleep: but I need to double check, I have a vague memory of fixing it but maybe the fix was not promoted from ppa:snappy-dev/tools-proposed to tools, you might check if tools-proposed has a update for ubuntu-device-flash
<mvo_> but in any case, image build with /etc/fw_env.config triggered
<mvo_> and dinner!
 * ogra_ doesnt care much about wily atm ... 
<ogra_> i just want that stable image done
<longsleep> sure - so why did i test wily then? Set channel to rolling and release to 15.04 should give me all the new stuff?
<seb128> kyrofa, that image is experimental, we can document that webdm should be installed and how...
<kyrofa> seb128, perfect, making the MP
<seb128> kyrofa, no, we are not proloading any snap atm, I don't know how to do that/didn't look at it
<seb128> kyrofa, thanks
<ogra_> longsleep, yes ... we need to test wily too though +
<ogra_> but for now i want that stable image out first
<longsleep> rolling not found on server.
<ogra_> and i didnt really plan to do a late shift today, damned
<ogra_> sudo ubuntu-device-flash core --channel=edge --oem beagleblack_1.9_all.snap --developer-mode -o bbb.img 15.04
<ogra_> longsleep, ^^^ edge ... sorry
<longsleep> ah edge
<longsleep> :D
<ogra_> U-Boot# setenv snappy_ab b
<ogra_> U-Boot# run loadfiles
<ogra_> reading b/vmlinuz
<ogra_> GRRRR
<ogra_> why does that work
<ogra_> (and why doesnt it if snappy_boot calls the same)
<longsleep> mvo_: i just added bug 1477224 - but i do not seem to be able to set to critical
<ubottu> bug 1477224 in Snappy "OEM snap does not install when building image for rolling" [Undecided,New] https://launchpad.net/bugs/1477224
<longsleep> ogra_: ok i got an image edge version 125. That looks good?
<ogra_> yup
<ogra_> thats what i use here
<mterry> mvo_, sorry, was out for lunch.  About fixtures and tarmac...  That would involve not just a manual merge, but turning off tarmac altogether, as other merges would be blocked too, if trunk required fixtures
<ogra_> hmm, so manually setzting snappy_ab to b and snappy_trial_boot to 1 and then running run snappy_boot works fine
<ogra_> it properly boots from b
<ogra_> i dont get that
<longsleep> maybe its an order thing
<ogra_> why would it work on the uboot prompt then ?
<longsleep> mhm
<longsleep> no idea :)
<ogra_> (and why did it work before when we tested it)
<ogra_> U-Boot# setenv snappy_trial_boot 1
<ogra_> U-Boot# if test "${snappy_trial_boot}" = 1; then echo foo; fi
<ogra_> foo
<ogra_> works just fine too
<longsleep> what about env print snappy_trial_boot
<longsleep> does that show 1 ?
<ogra_> not by default
<ogra_> but yes, if i set it
<longsleep> so what is the problem?
<ogra_> U-Boot# printenv snappy_ab
<ogra_> snappy_ab=a
<longsleep> i just finished fusing - so lets see if i can reproduce
<ogra_> U-Boot# if test "${snappy_ab}" = "a"; then setenv snappy_ab "b"; fi
<ogra_> U-Boot# printenv snappy_ab
<ogra_> snappy_ab=b
<ogra_> grmbl
<ogra_> so that bit is ok as well
<ogra_> longsleep, the prob is that no matter what i set, it always boots from a
<longsleep> ok so mine booted just fine - what should i try?
<longsleep> ah
<longsleep> ok
<ogra_> unless i do it manually
<ogra_> by calling run snappy_boot after setting the vars
<longsleep> how do you set something not manually?
<longsleep> mine now is booted from a
<ogra_> i set it, call saveenv and call reset
<longsleep> ah ok
<longsleep> let me try that
<ogra_> or i set it and run snappy_boot
<ogra_> the latter works
<ogra_> the former doesnt
<longsleep> what should i set? snappy_mode to try?
<ogra_> snappy_mode try ... snappy_ab b .... and snappy_trial_boot 1
<longsleep> right - booted from a for me too
<ogra_> yeah
<ogra_> oh, wait
<ogra_> do we actually need to set snappy_ab at all ?
<longsleep> well depends what you want
 * ogra_ tries without it ... 
<longsleep> it changes to the other at some point
<ogra_> i dont think we touch that var normally
<longsleep> dependend on the other vars
<ogra_> exactly
<ogra_> only snappy_trial_boot and snappy_mode
 * ogra_ taps foot waiting for cloud init
<longsleep> it fast on the odroid
<longsleep> rather fast
<ogra_> \o/
<longsleep> i can confirm that the system did set snappy_mode to regular and it sems to have removed snappy_trial_boot
<ogra_> me has it booting from b with only the two vars touched
<longsleep> yes works here too
<longsleep> if i only change those two it boots from b
<ogra_> which is indeed logical :)
<ogra_> right
<ogra_> and if you change them again it shoudl switch back
<ogra_> and so it does !Â°
<ogra_> yay
<ogra_> and still no corruption
<slangasek> ogra_: g-* was meant to happen overnight, but apparently I didn't hit the right key before going to bed :P
<ogra_> i guess we can call that a success
<longsleep> yes - changing back works here too
<longsleep> great
 * ogra_ needs to wait for mvo to return to confirm snappy itself doesnt tinker with snappy_ab
<ogra_> but yay ... we have grub and uboot unified !!!
<longsleep> very nice indeed!
<ogra_> now we just need to convince both upstreams to also merge theior code :)
<ogra_> slangasek, lol
<ogra_> i actually had to look up what i had said to trigger your answer :)
<ogra_> rsalveti, so confirmed that there is no fat corruption anymore ... i just need one final confirmation from mvo and we are good
<longsleep> ogra_: https://github.com/longsleep/snappy-odroidc/tree/uboot-env-support branch has all the gear to build oem and device for ODRODIC using the new .env file - if you want to give it a try see how my uEnv.txt and .env.in look now.
<rsalveti> ogra_: that's great, can you promote latest edge to alpha so we can test the update/rollback a bit more in there?
<ogra_> rsalveti, one thing missing in the current rootfs, mvo has triggered a build with a fix
<rsalveti> want to give it a shot in a few
<ogra_> waiting for that
<rsalveti> ogra_: oh, great
<ogra_> (fw_setenv/printenv config was missing in 15.04 --- so you cant tinker with the config from the runnng system)
<longsleep> it is there in the image i just built
<ogra_> oh, so the rootfs is already there ?
<longsleep> ah the config
<longsleep> sorry
 * ogra_ tries
<longsleep> no - i thought you mean the commands
<ogra_> yeah /etc/fw_something
<longsleep> yes that still is missing
<longsleep> sorry
<ogra_> the commands dont work at all without that
<longsleep> yeah - thats one reason why the go tool would be nicer
<ogra_> (though i would have preferred to just includethe uboot-go tool instead ... the fw_ stuff is so fragile)
<longsleep> +1
<rsalveti> kyrofa: to include webdm by default I'd assume we need to change the oem itself
<rsalveti> since it's a snap package
<kyrofa> rsalveti, ah, good to know. But I think we need it in the Personal channel first, right?
<kyrofa> rsalveti, last I checked, it was only in Core
<rsalveti> do we have another channel dedicated just for personal?
<rsalveti> never used personal
<ogra_> a whole image
 * ogra_ forgot what he did to build personal
<ogra_> but you need the u-d-f that suports the "personal" keyword
<ogra_> ubuntu
<ogra_> grrr !!!!
 * ogra_ wants FFB (focus follow brain)
<mterry> rsalveti, is sergiusens away?
<ogra_> ubuntu
<ogra_> ubuntu+
<ogra_> GODDAMNED !
<mterry> ogra_, :)
<ogra_> mterry, he had a kid (and now he has insomnia)
<mterry> ogra_, oh right!  the child!
<ogra_> back next week (perhaps ...)
<rsalveti> mterry: yeah, back on monday
 * mterry has amnesia himself
<mterry> mvo_, maybe we better manually merge snapcraft indeed for a couple days
<mterry> mvo_, just involves me running tests instead of tarmac, not that different
<jobot> Hi, I have owncloud installed on snappy (beaglebone black). I would like to point the storage to a usb drive. I have manually mounted the drive. and did a chown ubuntu:ubuntu. But, when I mount usb to the folder (as root because I have too?), the ownership changes, and becomes unwritable. Ownloud gives this: Can't create or write into the data directory /home/ubuntu/owncloud. Any advice appreciated. Thanks
<ogra_> jobot, format the dirve ... create a label on it "writable" ... then copy the content from the writable partition on the SD to that ... and delete the writable partition of the SD (or just remove the label)
<rsalveti> if blocked by tarmac might just be easier to merge by hand
<rsalveti> until we have our own tarmac that elopio and federico are working on
<jobot> @ogra_ , thanks. Does that mean I need to recreate any symlinks to the usb or does that get detected automatically?
<nothal> jobot: No such command!
<elopio> rsalveti: I can put a tarmac in canonistack now, but I would have to create a new tarmac-snappy user as I don't have the credentials for the existing one.
<elopio> I'd prefer to wait and use the same one.
<rsalveti> yeah, no need to rush
<ogra_> jobot, the USB disk simply takes over the writable bits of the SD then yu dont need any symlinks or anything with that method
<ogra_> rsalveti, a and b contents are identical on the BBB image, right ?
<ogra_> if i didnt upgrade anything i mean
<jobot> ogra_, thank you. I will give it a go.
<rsalveti> ogra_: after flashing, yes
<ogra_> well, indeed
<ogra_> funny then
<ogra_> i reliably get "[   20.580754] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517" 8 times in the log when booting from b
<ogra_> it never shows when booting from a
<jobot> Second question: is it possible to have the usb encrypted and mountable easily?
<ogra_> not yet ...
<ogra_> (it is definitely planned to support all kinds of disk encryption, but not implemented yet)
<jobot> ok cool thanks
<ogra_> mvo_, livecd-rootfs seems to have promoted, i trigered a new 15.04 image build now
<ogra_> +g
<mterry> tedg, poke about the questions you had in focused-assemble, got a sec?
<rsalveti> jobot: just remember that after you migrate the writable content you'd need to keep the usb stick around
<rsalveti> we definitely need a better way to handle usb storage devices
<jobot> rsalveti: good point. thanks !
<ogra_> rsalveti, well, i think moving writable to USB stick is a valid workaround for the moment :)
<ogra_> (or even tio the 3TB external rotary USB disk)
<ogra_> thats the beauty of using labels :)
<rsalveti> sure
<ogra_> the new image weems to be up ... (at least udf downloads something)
<ogra_> *seems ...
 * ogra_ will need a break shortly 
<mvo_> ogra_: snappy itself does not tinker with snappy_ab - well, the code does but it has no affect, on bootsuccess snappy_ab=a it sets it to â¦ "a" :P which is silly as its already set to a (and values that are already set to the same value are not written)
<mvo_> ogra_, longsleep: I'm happy to add the uboot-go binary, its just so huge (~2mb or so) :/
<mvo_> mterry: yeah, maybe we do it manually, I have access to tarmac but can not install stuff on the tarmac instance. and sergio is using unattended-upgrades so I can't help myself with the root access either :/
<mterry> mvo_, I merged one thing automatically already, but hit a snag with one of yours -- commented on it
<mvo_> elopio: I have access to the tarmac instance, I can get the creds I think
<mvo_> ogra_: \o/
<mvo_> mterry: oh, I have a look, thanks
 * mvo_ has finished reading backlog
<mvo_> longsleep: does it mean the uboot.env stuff is working now ? what was the issue that ogra was seeing, do you know?
<ogra_> mvo_, all working :D
 * ogra_ is just playing with image 126 here 
<ogra_> http://paste.ubuntu.com/11921381/  properly switches back and forth between a and b
<ogra_> oh
<ogra_> crap
<ogra_> no, it doesnt anymore
<ogra_> damned
<ogra_> reading uboot.env
<ogra_> ERROR: Cannot import environment: errno = 22
<ogra_> mvo_, :(((
<ogra_> at ../common/env_common.c:221/env_import()
<ogra_> *** Warning - import failed, using default environment
<ogra_> mvo_, i had it working by manually adding the config to image 125 ... now it completely broke in 126 ... and i have not the slightest idea why
<rsalveti> ouch
<rsalveti> can you check the vfat partition?
<ogra_> fatls lists everything fine ...
<ogra_> it also looks different from the corruption errors
<ogra_> (and i really cant focus anymore ... i need to stop soon)
<ogra_> i suspect it has somethign to do with the way the config is created ... thats the only difference we have
<ogra_> (the fw_setenv config)
<elopio> mvo_: great, please send them to me. Also if you can copy the tarmac config, that would be handy.
<mvo_> ogra_: hm, errno 22 is invalid argument in linux at least, wonder if uboot is the same. not more infos?
<mvo_> ogra_: aha, nevermind, take a break :)
<mvo_> elopio: sure thing, or if you have a instance just add my ssh key and I scp everything over
<mvo_> elopio: and turn the other tarmac off
<elopio> mvo_: your keys are imported, 10.55.32.109.
<tedg> mterry, Just got back (long story) are you around now?
<mterry> tedg, heyo
<mterry> tedg, sorry, had a contractor come by to look at some winter damage
<mterry> tedg, so I replied to you in merge comments, but wanted to drop to IRC to fully understand the issues in #2 (how snappy handles paths)
<tedg> mterry, Hmm, I don't see the reply. Let me check LP.
<tedg> mterry, So I guess that the snappy build does do that, but I'm not sure how I'd reference something in the path then.
<mterry> tedg, I don't think you do, not at the snappy-command level
<tedg> mterry, The QML plugin is setting up the PATH to include qmlscene
<tedg> mterry, I don't want the project to care where qmlscene is installed
<mterry> tedg, your plugin can install a thin wrapper that is basically "#!/bin/sh; qmlscene $*" or hardcode the qml there too if you know it
<mterry> tedg, i.e. drop to shell in order to use PATH
<mterry> And then have the user put your wrapper at the exec line
<tedg> Sure, trying to avoid having everyone build a shell script
<mterry> tedg, i.e. bin/qmlplugin myqmlfile.qml
<mterry> tedg, well the user wouldn't do it
<tedg> ?
<mterry> tedg, or you could basically just have the plugin install a symlink
<mterry> tedg, I'm trying to think of ways for you to have users not care about where your plugin puts qmlscene
<mterry> tedg, so I'm saying your plugin can put a symlink (or thin wrapper) somewhere in a place that you "own" and would tell users to run
<tedg> mterry, They have to define the exec statement
<mterry> tedg, so maybe that's a toplevel "runqml" symlink
<mterry> tedg, or "bin/runqml" that users of your plugin put in the exec statement
<mterry> tedg, (or you could just tell users to put usr/bin/qmlscene there)
<tedg> I guess I don't understand why it has to be different than running it on my development system.
<tedg> qmlscene foo.qml
<mterry> tedg, snappy is a whole different thing man
<mterry> tedg, that's just not how exec lines work
<mterry> tedg, (unless you put a qmlscene symlink at the toplevel)
<mterry> but at that point, you're just faking it so it looks like it's a PATH references
<tedg> Snapcraft could fix that :-)
<mterry> tedg, I mean, we basically do for everything *AFTER* that entry point
<tedg> If you're pulling things in with teh Ubuntu plugin, you probably want them to be in the PATH (they are) so I think it makes sense to use them as such.
<mterry> tedg, but that entry point itself is a snappy thing, and is a relative path
<tedg> So I'm saying that the snapcraft wrapper should allow using the PATH that is already in that same wrapper.
<tedg> (which if you're using Ubuntu, it is)
<mterry> tedg, ... so you want in your case of 'qmlscene', you want snapcraft to make a 'qmlscene.wrapper' file at, I dunno, the toplevel, which which assumes that the exec line was not in fact a standard snappy exec line but actually a PATH reference. I'm leery of doing that as a matter of course.  And it feels silly to have an option for that
<mterry> tedg, maybe if we detect that the file doesn't exist
<mterry> tedg, and we could check all the PATH locations....
<mterry> tedg, find it, and stuff that into the exec line instead
<mterry> tedg, that's awfully magic
<mterry> tedg, just to avoid people learning a tiny bit about how snappy works  :)
<mterry> tedg, but it seems like a harmless feature to add
<mterry> tedg, but I'm comfortable making that a separate branch  :)
<tedg> mterry, Heh, okay.
<tedg> mterry, I'm not sure if we need to search the PATH, I think we can just assume the path if it doesn't exist.
<mterry> tedg, it is a decent way to avoid what may be a common problem for people unused to snappy, indeed.  I'll file a bug
<mterry> tedg, well, someone may have legitimately made a typo or not understood something.  We know what the PATH will be at that point, so it's harmless to check
<mterry> tedg, though maybe it will be hard to know what is in Core vs the snap, if the first command is a Core exec
<tedg> mterry, We'd have to run it through a shell, we're not actually evaluating the PATH.
<tedg> I think the point of Snappy is "assume nothing is core" right? ;-)
<mterry> tedg, we can parse all the env vars that are PATH= that the plugins give us into the snap
<mterry> tedg, yeah but what if the first exec fragment is "env"
<mterry> tedg, maybe that's just not allowed (it wouldn't be by base snappy I don't think)
<tedg> mterry, Heh, then right now you'll rewrite it as "$SNAP_APP_PATH/env" ;-)
<mterry> tedg, which is what snappy itself would do.  I don't think that's a bug in the current instance
<mterry> tedg, I was just seeing if we could be more magic there for the user.  But I don't think we want to in that case
<mterry> tedg, how about https://bugs.launchpad.net/snapcraft/+bug/1477286 ?
<ubottu> Launchpad bug 1477286 in Snapcraft "Support PATH-resolved commands in exec lines" [Undecided,New]
<mterry> tedg, and credited you in a comment  :)
<tedg> mterry, Heh, that works.
<mterry> tedg, I also have a bunch of source-option branches if you're feeling review-y
<tedg> mterry, Sure, source-options, more-source-options?
<mterry> tedg, and source-tarball
<elopio> mterry: did you need any other package installed in tarmac, in addition to python3-fixtures?
<mterry> elopio, I will also probably need git, bzr, and xz-utils (if they aren't already there)
<mterry> tedg, source-* options may change in further spec discussions too.  I just wanted something in place to not block people and other work.  All yaml is changeable  :)
<mterry> tedg, and I admit that git isn't my first language.  I just did something I found would work.  I miss bzr's easy to understand revnos
<tedg> mterry, Yeah, at least Linus admitting not having them was a mistake :-)
<tedg> Cool, let me get qml updated for trunk. (and see if it still works :-) )
<mterry> tedg, you're right...  I'll make a little unit test for isurl
<mvo_> ogra_: for tomorrow, one data point with r126 and the corruption is that I see is that there is a "=b" entry in printenv. I can get that by typing "setenv "" b; saveenv" in the u-boot prompt and I wonder if somehow something in our bootscript sets a empty var to b. something like "setenv $some_var_that_is_not_defined b; saveenv" or something. once there is a empty key in the uboot env it seems it can no longer load the file. but looking at uboot
<mvo_> .env.in I don't see anything like this
<mvo_> ogra_: so manybe/probably a wrong theory
<ogra_> mvo_, i noticed that i have an 8 byte header on the unreadable file
<mvo_> ogra_: could you pastebin the hexdump -C uboot.env |head output please?
<ogra_> mvo_, i'll check the quoting tomorrow, it isnt consistent in snappy_boot ...
<ogra_> mvo_, http://paste.ubuntu.com/11922519/
<mvo_> ogra_: the "=1" is a key=value, the key is just empty, should not happen of course and I wonder what is triggering it
<ogra_> mvo_, then i'm sure it is the quoting in snappy_boot ... i changed some bits in 125 when i tested it
<mvo_> ogra_: it could be, yeah, I managed to corrupt my file in a similar way with setenv "" x ; saveenv in the uboot prompt
<ogra_> (because i couldnt use fw_setenv initially)
<mvo_> ogra_: there is something funny with the fw_setenv in 15.04
<mvo_> ogra_: I have strange issues here too
<ogra_> well, it worked for at least 50 boots for me with 125
<ogra_> i didnt have any comments in my config ... thats the only difference on that layer
<mterry> tedg, thanks for the reviews!
<mvo_> ogra_: hm, hm, if it worked in 125 and no longer in 126 its probably something else
<ogra_> (i actually wonder if fw_*'s config handling is comment safe :=)
<mvo_> ogra_: haha
<ogra_> well, I#ll re-work tezh snappy_boot command tomorrow morning i know it can work for 50 boots without any issue
<mvo_> ta, lets check it out tomorrow and I let you kow if I notice anything
<ogra_> now it breaks reliably the third boot
<mvo_> ogra_: and I remove the comments
<ogra_> heh, i wasnt actually serious :)
<mvo_> I know
<mvo_> but I am ;)
<mvo_> every 3 boots you say?
<ogra_> i'm pretty sure its snappy_boot that breaks us
<ogra_> well, when switching back from b to a
<mvo_> snappy_boot in snappy-go ? or in the bootloader itself?
<ogra_> in uboot.env
<ogra_> its a var
<mvo_> aha
<ogra_> the thing that carries the a/b logic
<ogra_> i already noticed the quoting is pretty inconsistent, that needs fixing anyway
<mvo_> ogra_: ok, lets hope that its that and I will get some rest :)
<ogra_> http://paste.ubuntu.com/11922551/
<ogra_> oh man
<ogra_> i see whats wrong ... after the setenv snappy_ab "a" and snappy_ab "b" there needs to be a saveenv indeed
<mvo_> ogra_: nice, hope its that. here is what I see when its broken:
<mvo_> fw_printenv|cut -f1 -d=|sort|head
<mvo_> arch
<mvo_> meh, http://paste.ubuntu.com/11922579/ is better. a empty key in the first line
<ogra_> wow
<ogra_> perhaps we should really take uboot-go instead
<ogra_> even if it costs 2M
<mvo_> might be me corrupting it, I just don't know right now :/
<mvo_> ogra_: this is what I did: http://paste.ubuntu.com/11922587/
<ogra_> well, thats wrong
<ogra_> though it shouldnt break anything
<ogra_> you want to set snappy_trial_boot 1 ... not snappy_ab b
<ogra_> setting snappy_ab happens inside the bootloader later
<mvo_> ogra_: snappy_trial_boot is what the bootloader sets itself, snappy just cleans that
<mvo_> ogra_: at least thats how grub is doing it
<ogra_> well, see the snappy_boot command i pasted above
<ogra_> it checks for that being set
<mvo_> yeah, it uses that to detect that the boot failed, i.e. if its in "try" mode and it has not booted successfully (trial boot is set) it will revert back to the previous partition
<ogra_> hmpf, then i tested wrong
<mvo_> so when the bootloader sees try it will set trial_boot=1 and then booted OS is expected to clean that
<mvo_> its confusing :/
<ogra_> i did set snappy_trial_boot to 1 and snappy_mode to try
<mvo_> that should be ok, that simulates the fallback to the other patition
<ogra_> ok
<mvo_> with that it should simpliy toggle
<mvo_> or flip-flop :)
<mvo_> meh, I whish it would boot faster
<ogra_> cloud-init is a pain
<ogra_> and something still hangs with th NIC startup
<mvo_> ogra_: ok, the bug is on my turf, I just ran "snappy booted" manually and managed to trigger it without rebooting
<mvo_> ogra_: so its not uboot
<ogra_> P H E W  !
<mvo_> :)
<mvo_> oh, wait
<mvo_> :(
<ogra_> mvo_, i still dont get how it worked in 125 and stopped working in 126
<ogra_> did you do a snappy upload alongside the livecd-rootfs one ?
 * ogra_ thoguht adding the config was the only change 
<Chipaca> mvo_: ogra_: you guys are up way past your bedtime
<ogra_> Chipaca, you not ?
<Chipaca> I'm 1h behind you
<Chipaca> and my eod is always late :)
<ogra_> (definitely hours before my bedtime though ... but far past my EOD time :) )
<Chipaca> also feeling a little bit guilty that the biggest problem i'm wrangling is around naming, and you guys are fighting uboot
<Chipaca> but the feeling will pass i'm sure
<ogra_> hah, i like bootloader wrangling :)
<mvo_> ogra_: I can not find a way to trigger it reliable
<ogra_> hmpf
<mvo_> ogra_: I guess my best option for now is rest
<ogra_> yeah, same here ... we'll nail it tomorrow ...
 * mvo_ waves
<mvo_> indeed
#snappy 2015-07-23
<mvo> ogra_: I blame fw_setenv for the breakage and I think I can prove it: http://paste.ubuntu.com/11923858/
<mvo> ogra_: thats operating on the pristine uboot.env I got from you and that was generated with mkenvimage, no snappy involved at all and notice the corruption at the end of the file
<mvo> ogra_: I think I have a plan, lets see if it works
<fgimenez> good morning
<dholbach> good morning
<mvo> ogra_: I uploaded a fix to the ppa that should fix the corruption, its a bit ugly, I work on a nice version with proper tests etc now. its also very panic()y to ensure that any remaining issues are caught
<mvo> ogra_: once the updated uboot-go is in, we need to rebuild snappy and make a new image and then fingers crossed :)
<mvo> hey fgimenez and dholbach, good morning!
<fgimenez> hi mvo dholbach and all :)
<dholbach> hey hey :)
<ogra_> mvo, thanks !
<ogra_> mvo, i still dont get how it broke between 125 and 126 though ... only the config was different there
<ogra_> (and 125 was to 100% reliable)
<longsleep> reading through backlog you guys had some fun last night - anything i should test with 126?
<ogra_> longsleep, no, but the next build
<longsleep> ogra_: ok - did you make any changes to the saveenv logic?
<ogra_> not yet, i'm cleaning that up now, but since it worked for both of us before it should technically be fine, this is more cosmetic to rip out the inconsistent quoting
<longsleep> ogra_: i think i have alreayd put double quotes around everthing - are you doing that too?
<ogra_> yep
<ogra_> our current snappy_boot only has half of the vars and values quoted
<ogra_> (on the BBB that is)
<longsleep> well, i only put double quotes around stuff used for comparison, for the rest i never use double quotes
<longsleep> ok - i see what you mean i am inconsitent there too
 * longsleep is fixing
<ogra_> heh
<ogra_> as i said ... simply cosmetic
<longsleep> by the way - what is the reason to have snappy_cmdline as seperate var ?
<longsleep> i think its unclean to just add that value at the end of mmcroot and will probably remove the var
<ogra_> i'm also putting a saveenv behind every setenv here
<longsleep> really
<ogra_> well, for the snappy_boot line ... not for everything :)
<longsleep> i need to make it multi line to make sense of it
<longsleep> yeah i figured that much :)
<longsleep> ogra_: mine currently looks like this https://pad.struktur.de/p/snappy_boot
<longsleep> ogra_: where do you put extra setenv?
<longsleep> saveenv
<ogra_> http://paste.ubuntu.com/11924149/
<ogra_> i cant open your url ... insufficient privs
<longsleep> err
<longsleep> maybe its blocked from outside
<longsleep> let me check your diff
<ogra_> The requested URL /insufficient_privileges was not found on this server.
<ogra_> :D
<ogra_> thats like "the url "broken link" was not found"
<longsleep> hehe
<longsleep> i think the pad is not in outside DNS and you end up at some fallback server
 * ogra_ notes he ends up at a fedora server .... thats all it says
<longsleep> so you saveenv whenever the snappy_ab is changed - not sure why this is required - i was under the impression that this is only for the current boot
<ogra_> well, it means you keep the condition if you powered off the board before the boot finished
<longsleep> mhm, what is the difference between boot failure and powered off - shouldnt it roll back in that case?
<ogra_> yes
<longsleep> ok i see your point - i was under the impression only snappy_mode was set to try on upgrade. But that would make no sense.
<longsleep> well ok hold on
<longsleep> it would make sense if the system upgrade would set snappy_ab to the upgraded partition value as well
<ogra_> it will roll back in both cases ... weather or not the var is set ...
<longsleep> then you would not have to save that change from u-boot ?
<ogra_> either all the vars are stored and the next boot will switch back to the former partition .... or none of the vars is stored so they are reset and it boots normal ...
<mvo> ogra_: I can build you a custom snappy if you want to test/explore with the fixed code until the full image is ready
<ogra_> but in the latter case the bootloader will never know that an upgrade boot was attempted ... in the former it will ... the result is the same
<longsleep> the next boot will only switch to former partition if it failed to boot when the successfull boot does not reset snappy_mode and snapp_trial_boot
<ogra_> mvo, i can wait for the full image ... btw, did you make the snappy_trial_boot a boolean ?
<ogra_> longsleep, exactly
<longsleep> so why do you saveenv the snappy_ab change in u-boot then?
<mvo> ogra_: its still a unset, I can change that now (would like to change it in both grub and uboot then in wily) do you think its important? i.e. will uboot be unhappy if its not set at all?
 * longsleep does not get it - lets get some coffee
<ogra_> mvo, well, i'd like to exclude the possibility that it could get unhappy ... i have no proof, only gut feeling
<ogra_> longsleep, hmm, yeah, prehaps i have a brainfart here
<longsleep> ogra_: lets use this https://etherpad.mozilla.org/sglergmwrt - i hope you can open that :)
<longsleep> arg
<longsleep> it did format it
<ogra_> lol
<ogra_> in a weird way
<longsleep> that is just plain stupid
<longsleep> paste it in, gets formatted
<ogra_> what is "run setup" ?
<longsleep> thats setting up fdt based on variables
<ogra_> and how do you hand over the initrd, i dont see that in bootm
<longsleep> https://public.pad.fsfe.org/p/snappy_boot
<longsleep> copy paste fail - forgot the last line
<ogra_> ah !
<ogra_> :)
<longsleep> so
<longsleep> i fail to see why the setenv snappy_ab parts need to be saved
<ogra_> looks good ... and i thihnk based on the above i'll leave out the saveenv
<longsleep> and i would like to get rid of snappy_cmdline
<longsleep> feels strage to just add it to mmvroot
<ogra_> well, it is good to have it separate for better readability ...
<longsleep> just added the setup - so you get the whole picture
<ogra_> so that you can see the actual cmdline options in one go without having to pick them out of an already way to long snappy_boot line
<longsleep> ogra_: so the only question is what does happen when the system gets updated. Someone sets snappy_mode to try - i get that much, the question is if snappy_ab is also changed or not
<ogra_> it is
<ogra_> snappy cvhanges it from userspace
<ogra_> it sets "ab" to the "other" partition and sets trial_boot to 1
<longsleep> ogra_: good, then it would be bad to saveenv snappy_ab from u-boot
<longsleep> ogra_: i just changed snappy_cmdline to be added by mccargs to bootargs
<longsleep> i think that is cleaner
 * ogra_ needs to check how mmcargs looks on the BBB and RPi 
<ogra_> uh
<longsleep> i think it just sets the bootargs. It is called by snappy to pull in mmcroot as this contains the snappy_ab variable
<ogra_> never noticed that before ... BBB sets rootfstype there
<longsleep> yeah i saw that. I think that is redundant
<ogra_> no, thats dangerous
<longsleep> mhm ok :)
<ogra_> mmcrootfstype=ext4 rootwait
<ogra_> not so clever if we switch to some other fs :)
<longsleep> yeah
<longsleep> ogra_: so in the pad i now have my complete mmcargs with snappy_cmdline put there, instead of in the setenv in snappy_boot
<longsleep> feels cleaner
<ogra_> yes, i did the same here (anmd dropped mmcrootfstype)
<longsleep> ok great - so what is the problem with build 126 / why did you add the saveenv's in the first place?
<longsleep> ogra_: above you wrote the system sets ab to the other partition and trial_boot to 1. Is that really so? I think it should not touch trial_boot, but set snapp_mode to try instead?
<JamesTait> Good morning all; happy Gorgeous Grandma Day! ð
<ogra_> longsleep, 126 corrupts the uboot.env file by adding a value without a var name to it
<mvo> ogra_: I triggered a new armhf build for 15.04, fingers crossed
<ogra_> fw_setenv actually allows things like: "fw_setenv ' ' 1"
<ogra_> mvo, \o/
<longsleep> oh
<longsleep> any news about using uboot-go instead?
<ogra_> longsleep, it is go ...
<ogra_> (meaning it is a static binary of 2MB size)
<longsleep> ogra_: thats great then
<longsleep> ogra_: btw - i wanted to ask you how to handle upgrades from snappy-system.txt to uboot.env. When an new image is released and gets updated to uboot.env
<ogra_> i'm not sure we do that
<ogra_> (we do use the old files if they exist, so it only affects new installs)
<longsleep> mhm
<longsleep> ok
<longsleep> so version 4 will contain the new and old behavior then?
<mvo> ogra_: looks like the new armhf 15.04 is available
 * mvo downloads
<longsleep> mvo: version 128 sounds good?
 * ogra_ downloads too
<longsleep> mvo, ogra_ : all right i am booted into 128 - let me know if you want me to do any specific tests
<longsleep> Mhm - fw_printenv Read error on /boot/uboot/uboot.env: Success
<dholbach> davidcalle, I added an item to the trello card about generalising the markdown importer so we can import docs from lp:snapcraft too - I'll look into that now
<longsleep> mvo: well, fw_printenv cannot read or set anything in the .env file, while uboot-go works just fine
<mvo> longsleep: hm, hm, let me investigate
<longsleep> mvo: i see the scary config in /etc/fw_env.config
<longsleep> mvo: i also just updated uboot-go to latest git and it still works
<longsleep> (ODROIDC)root@odroid:~# fw_setenv foo bar
<longsleep> Read error on /boot/uboot/uboot.env: Success
<longsleep> Error: environment not initialized
<longsleep> (ODROIDC)root@odroid:~# fw_printenv
<longsleep> Read error on /boot/uboot/uboot.env: Success
<mvo> longsleep: so 113/rolling works with fw_setenv/fw_printenv, I create a 15.04 one now
<longsleep> mvo: did you fix the issue with the OEM snap in rolling? (bug #1477224)
<nothal> Bug #1477224: OEM snap does not install when building image for rolling <Snappy:New> <http://launchpad.net/bugs/1477224>
<ubottu> bug 1477224 in Snappy "OEM snap does not install when building image for rolling" [Undecided,New] https://launchpad.net/bugs/1477224
<mvo> longsleep: no, I think its a race actually, after ~5 tries it worked for me
<longsleep> ok let me try that
<ogra_> mvo, hmm ... settin snappy_ab to b and snappy_mode to try doesnt get me booted from b
<mvo> ogra_: does it show the correct values in the uboot prompt with printenv?
<ogra_> havent checked that yet
 * ogra_ isnt sure if our logic is actually correct 
<longsleep> did you see what i wrote above: ogra_: above you wrote the system sets ab to the other partition and trial_boot to 1. Is that really so? I think  it should not touch trial_boot, but set snapp_mode to try instead?
<ogra_> mvo, http://paste.ubuntu.com/11924535/
<ogra_> yeah, the trial_boot looks wrong
<ogra_> setting trial_boot to 1 and mode to try works
<longsleep> yes - but you should not set trial_boot, you should set mode to try and ab to the one which you want to try
<longsleep> whats how i see it at least
<ogra_> right, but thats not what the logic we have does
 * ogra_ takes a look at the old code
<longsleep> no? i think it does just that
<ogra_> http://paste.ubuntu.com/11924535/ is the currentl logic
<longsleep> yes
<longsleep> but that is in uboot
<ogra_> it onl switches if mode is try and at the same time trial_boot is 1
<ogra_> sigh
<longsleep> yes but it only has to switch if the boot failed
<ogra_> why cant cloud-init not write to /dev/null
<ogra_> so annoying
<longsleep> +1
<ogra_> well, at least i dont see corruption now
<longsleep> from my point of view, uboot is only switching in case of roll back
<longsleep> the try is done from the system side after update
<ogra_> it shoudl also switch in case of upgrade :)
<longsleep> set try and ab to other
<ogra_> and it doesnt with the current logic
<longsleep> so the system does only set try but not ab to other
<longsleep> thats the error then
<ogra_> no, the system sets try and ab to the other
<longsleep> then all is good
<ogra_> well, no
<ogra_> it doesnt boot from b if i set it to b
<longsleep> well it should, because mode is try, it boots from whatever ab is set to because trial boot is 0
<ogra_> http://paste.ubuntu.com/11924564/
<longsleep> so either ab is a or if its b then trail boot is 1
<longsleep> if ab is b and you want to boot it from b, then trial boot needs to be 0
<mvo> ogra_: hm, hm U-Boot# printenv snappy_ab
<mvo> snappy_ab=b
<longsleep> ok, then trial boot is 1
<ogra_> U-Boot# printenv snappy_ab
<ogra_> snappy_ab=b
<mvo> and snappy_mode is try as well I assume?
<mvo> i.e. the env is read correctly?
<ogra_> http://paste.ubuntu.com/11924581/
<ogra_> ah, wait, didnt check mode
<ogra_> ab is definitely b after reboot
<ogra_> as you can see in the paste it boots a though
<longsleep> well, for me it boots just fine from b when i set it to b, saveenv and reset
<mvo> just snappy_ab b ?without the try?
<mvo> without hte snappy_mode try?
<longsleep> if ab is set to b and mode is try, then trial is 1 if it boots from a
<longsleep> yes without the try
<longsleep> let me try with try
<longsleep> ok that boots from a
<longsleep> so ..
<longsleep> script does not work
<longsleep> let me check
<ogra_> http://paste.ubuntu.com/11924593/
<ogra_> mvo, ^^^
<ogra_> so ab is set to b and mode to try
 * ogra_ doesnt get that
<longsleep> ah i guess the problem is that snappy_trial_boot is not set and then always returns true
<longsleep> i remember test to behave that way
<ogra_> yeah, thats why i wanted a boolean
 * ogra_ sets it ... once cloud-init lets me
<mvo> if test ${snappy_trial_boot} = 1; then echo yes; fi
<mvo> yes
<mvo> echo ${snappy_trial_boot}
<ogra_> mvo, what sets it ?
<mvo> thatsâ¦unexcpected
<longsleep> if snappy_trial_boot is not set then it always sets to a
<mvo> u-boot, seriously?
<longsleep> if i set it to 0
<longsleep> it works just fine
<ogra_> mvo, well, thats the hush shell implementation ... cant blame uboot itself :)
<mvo> hm, quoting maybe?
<mvo> if test "${snappy_trial_boot}" = "1"; then echo yes; fi
<mvo> give no output
<longsleep> no, my script is quoted
<longsleep> i remember having this issue before
<ogra_> yeah, i have a local fix for the quoting, but its not that
<mvo> http://paste.ubuntu.com/11924602/
<mvo> looks like quoting to me unless I miss something
<ogra_> hmm
<longsleep> mvo: no it does not work with the quoting either
<mvo> http://paste.ubuntu.com/11924610/
<mvo> longsleep: how does yours look like?
<mvo> longsleep: could you pastebin it please?
<ogra_> so what are the actual reasons for using cloud-init ? this is really annoying the hell out of me (additionally to the extra 30sec boot time it spams the console all the time)
<ogra_> i know we have distro ways of generating ssh keys
<longsleep> mvo: http://paste.ubuntu.com/11924615/
<ogra_> and i guess it wouldnt be to hard to have user creation code adopted from d-i or some such
<ogra_> what else does cloud-init do for us ?
<longsleep> i have checked that a couple of weeks ago. It creates the default user too i think
<longsleep> and something with the hostname
<ogra_> right
<ogra_> see what i write
<ogra_> *wrote
<ogra_> we have tools for that in the distro that we use on the livecd for example
<ogra_> its a 10 line script or so
<ogra_> same goes for ssh ... its a few extra lines to have it create keys if they dont exist
<mvo> longsleep: hm, thats confusing. does your uboot shell also behave like what I see in http://paste.ubuntu.com/11924610/ ?
<ogra_> and setting the hostname from /proc/cpuinfo isnt to hard either
<longsleep> mvo: i just checked that
<longsleep> mvo: mine behaves differently
<longsleep> mvo: if test "${snappy_trial_boot}" = "1"; then echo yes; fi
<longsleep> yes
<ogra_> i just dont get why we have to go through all the pain with cloud-init for these tzhree bits ... and make it really hard and uncomfortable for developers
<longsleep> (with unset trial boot)
<ogra_> longsleep, mvo most likely a version thing
<longsleep> ogra_: yeah - i think you should ask the one who added it - i would really love to see it go away
<longsleep> ogra_: let me check Git
<ogra_> seems everyone would
<ogra_> so yeah setting trial_boot to 0 gets me properly booted from b as expected
<mvo> longsleep: woah, thats amazing, uboot is always good for a suprise
<longsleep> mvo: http://paste.ubuntu.com/11924645/
<longsleep> mvo: indeed
<ogra_> mvo, well, vendors are good for surprises in that case ;) ... since they fork off from ancient uboot versions and never merge back usually
<longsleep> ah yes
<longsleep> http://git.denx.de/?p=u-boot.git;a=commit;h=2453de99df576fb907fe06cac58c628e3590833f
<mvo> ogra_: yeah, looks like we need to make it bool and also change grub to be on the safe side, it looks on the bbb quoting will help, but if thats not universal its no good
<ogra_> yep
<mvo> amazing
<mvo> thanks longsleep
<longsleep> i did remember seeing that because i have another u-boot where i needed the -e for test and thus merged around in test command before
 * longsleep is going to have some lunch
<mvo> longsleep: do you also a yes for ' if "" = "1"; then echo yes; fi'
<longsleep> mvo: err sorry
<longsleep> mvo: what do you want me to run?
<longsleep> got it hold on
<longsleep> mvo: you missed a test in there right? else if gives unknown command
<longsleep> mvo: empty string works just fine
<mvo> longsleep: yes, sorry. I wonder if "if printenv snappy_trial_boot; then echo yes; fi works
<mvo> longsleep: interessting and crazy
<ogra_> WOAH !
<ogra_> mvo, why is /var/lib/dpkg/info not wiped ?
<mvo> ogra_: we only do that on wily
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ du -hcs /var/lib/dpkg/info/
<ogra_> 9.2M    /var/lib/dpkg/info/
<ogra_> ah, k
<ogra_> then i'm fine
<longsleep> mvo: that seems to work http://paste.ubuntu.com/11924669/
<ogra_> mvo, that meanbs we have 9.2M extra space there in which we could ass uboot-go ;)
<mvo> lol
<ogra_> *add
<mvo> yeah, I thnk we should add it
<mvo> http://people.canonical.com/~mvo/tmp/beagleblack_1.10_all.snap <- that has a snap with the quotes, building a new image+mp will be at least 2h that we can't test the rest :/
<Chipaca> pitti had suggested how we restart the network from inside the 'first boot' unit; does anybody remember how it was?
<mvo> longsleep: I wonder if that could/should be used so that we can continue iterating, the image building is so slow :/
<ogra_> mvo, does that have my MP merged ?
<mvo> ogra_: I used your 1.9 snap
<ogra_> cool
<mvo> as the base and just added the quotes
<mvo> its writing now
<ogra_> mvo, hmm, no
<longsleep> mvo: so for your u-boot it works with quotes?
<longsleep> mvo: i could merge the fix into my u-boot
<mvo> longsleep: it appears to be, I'm double checking
<ogra_> you probably also want snappy_trial_boot=0 in uboot.env.in
<longsleep> but i guess it will be trouble
<mvo> ogra_: thats in there already afaict
<longsleep> as that change is from early 2014
 * mvo double-checks
<ogra_> oh
<mvo> longsleep: yeah, I think the final version needs to set it to "0"
<ogra_> ah, yeah
<ogra_> heh ... i dont know my own code after two days anymore ...
<mvo> longsleep: I'm just sick of waiting for another image and want to give it a good beating (for testing)
<mvo> ogra_: I don't after 2h
 * ogra_ guesses he should check for some vacation :)
<longsleep> mvo: but for testing now i am fine with whatever workaround
<ogra_> mvo, but you have kids distracting you ... thats fine :P
<mvo> then I can prepare a branch after lunch, its trivial
<mvo> ogra_: you have cats, about the same, no ;) ?
<ogra_> nah, they lseep during the day :)
<ogra_> *sleep
 * longsleep now really goes for lunch
 * mvo is also hungry 
 * ogra_ considers breakfast :)
<Chipaca> Cogito ergo ipomoea batatal.
 * Chipaca takes a break
<mvo> ogra_: http://people.canonical.com/~mvo/tmp/beagleblack_1.11_all.snap <- latest that works for me, i.e. it now boots b when I set snappy_ab b and snappy_mode try
<mvo> next I will make it not unset the env
<mvo> Chipaca: if you have a moment, it would be great if you could check https://code.launchpad.net/~mvo/snappy/snappy-no-unset-trial-boot and https://code.launchpad.net/~mvo/snappy/15.04-snappy-uboot-no-unset-trial-boot
<mvo> ogra_: ^--- those branches set to "0" instead of unsetting
<Chipaca> mvo: are those the result of what you and ogra debugged this morning?
<mvo> Chipaca: yes, its the result of trying to be as compatible with u-boots quirks as possible
<Chipaca> mvo: +1'ed; code looks sane, and i've watched you debug it :)
<mvo> Chipaca: heh, thanks
<mvo> Chipaca: crazy I say this u-boot
<mvo> but it seems its under control
<longsleep> mvo: i did some more testing and found that all combinations seem to work as long as no variable is not defined.
<longsleep> mvo: See https://github.com/longsleep/snappy-odroidc/blob/uboot-env-support/oem/boot-assets/uboot.env.in for my latest env
<mvo> longsleep: great, the above MP fixes the undefined vars
 * mvo is still a bit disappointed by uboot, really
<longsleep> well u-boot is getting better and has improved a lot since 2014
<longsleep> unfortunately most vendors have based their u-boot on 2013 something ..
<mvo> yeah, sorry, I'm ranting a bit
<longsleep> at least it is open source - imagine you had to deal with closed source issues
<mvo> longsleep: heh :) good point
<longsleep> i am pretty sure uefi implementations are even worse than u-boot is
<ogra_> mvo, could be a lot worse ... we could have to deal with redboot or aboot :)
<ogra_> merge looks good indeed
<ogra_> hmm
 * ogra_ wonders why his phone screen doesnt turn on on notofocations
<ogra_> *notifications
<ogra_> WOW ...
<ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages
<ogra_> why does it say "no signer" for the last snappy build
<mvo> auto upload from the daily builds
<mvo> thats ok
<mvo> I triggered builds now and once they are in we can get the golden image
<mvo> hopefully :P
<ogra_> does it correct that later ?
<mvo> ogra_: the later? you mean the unset vs set = 0?
<ogra_> i mean the "no signer" i have never seen that before
<mvo> I thnk its there all the time, for every daily build
 * mvo could be wrong though
<ogra_> i wonder why i never noticed it before
<ogra_> i not only need new teeth and vacation apparently but also glasses :P
 * ogra_ is happy he still has some hair at least :P
<longsleep> mvo: so you think the fw_* commands will work with the next build?
<longsleep> mvo: i did not manage to get the rolling release to accept my oem snap :/
<ogra_> fw_* should work, yes
<ogra_> they already work here right now though
<longsleep> oh - so am an 128 and they do not work for me
<ogra_> oh ?
<mvo> longsleep: crc error? or something else?
<ogra_> 4 vs 5 byte again?
<longsleep> no i got 5 byte env
<longsleep> parses fine with uboot-go
<mvo> size also corret on disk and maches fw_env.config?
<mvo> fw_env.config needs the hex size
<mvo> if its nothing like this I run out of ideas :/
<longsleep> the config has the two lines with the comment for 5 bytes
<mvo> uboot-go is smarter and figures the size out by itself
<longsleep> mhm
<longsleep> http://paste.ubuntu.com/11925071/
<longsleep> 5 bytes until the b
<mvo> longsleep: what fize has the file?
<longsleep> mvo: 32768 bytes
<elopio> fgimenez: I was wondering if we could leave your job code only for provisioning.
<longsleep> (thats the value in u-boot compile time)
<elopio> fgimenez: like leave the --command flag out, and make the main return an ip.
<ogra_> longsleep, to small then
<longsleep> err
<ogra_> +uboot.env is created from uEnv.txt via:
<ogra_> +$ mkenvimage -r -s 131072  -o uboot.env uboot.env.in
<fgimenez> elopio, sure, the cloud package takes care of that
<ogra_> from our beaglebone README in the snap branch
<mvo> longsleep: hm, so we need to set 0x8000 in fw_env.config for you or you increase the env
<longsleep> ogra_: why too small?
<mvo> probably best if you increase it as we have no way right now to change fw_env.config
<longsleep> how large should it be
<ogra_> longsleep, 128k
<longsleep> oh ok
<ogra_> just use the same mkenvimage call
 * mvo will explore to put uboot-go into the image, thats all a bit insane IMNSO
<longsleep> i doo
<longsleep> see https://github.com/longsleep/snappy-odroidc/blob/uboot-env-support/oem.mk#L29
<ogra_> mvo, +1000
<mvo> I mean, it seems bad to force everyone to use our env size just because of a silly config
<ogra_> longsleep, no, you use -s 32768
<longsleep> yes
<longsleep> i was not aware that i have to use another size
<elopio> fgimenez: so I'm thinking, on snappy/_integration-tests/main.go we can do a kvm-ok. If it succeeds, run adt-run ... -- snappy. If it doesn't, call your project and get an ip from canonistack, and then adt-run ... -- ssh ip.
<ogra_> <ogra_> +$ mkenvimage -r -s 131072  -o uboot.env uboot.env.in
<longsleep> but no problem
<mvo> longsleep: yeah, you wouldn't have to, actually you don't have to except for testing
<ogra_> longsleep, well, preferably fw_* would autodetect it
<mvo> longsleep: snappy itself is not touch fw_setenv/printenv at all
<ogra_> but the command is originally for MTD devices
<longsleep> yeah
<mvo> it uses its own uboot env handling (thanks god for that)
<elopio> fgimenez: also, I'm getting this error: http://paste.ubuntu.com/11925094/
<ogra_> mvo, looks lilke the packages have built
<ogra_> (ppc failing on vivid)
 * longsleep rebuilds u-boot with 128k env size
<fgimenez> elopio, the error is because the credentials you are using, the key specified with -k is not present,
<mvo> ogra_: yeah, I triggered a rootfs build some minutes ago
<mvo> so once that new image is available I guess QA needs to test the hell out of it
<ogra_> wheee !!
<fgimenez> elopio, when we meet later we can talk about the shared user credentials
<longsleep> mvo, ogra_ ok confirmed fw_* works with 128k size - thanks!
<mvo> yay!
<ogra_> :)
<ogra_> silly hardcoding in the confi file
<ogra_> +g
<mvo> oh yes
<ogra_> but i guess we get what we ask for ... abusing an MTD tool for a random file :)
<elopio> fgimenez: ok, got it working now, thanks. I think the ssh security group is not needed, as the default is to allow the port 22.
<mvo> ohh, image build, now its just a matter of waiting for it to be imported
<ogra_> yeah .... already uploading
<elopio> utlemming: could you add the image # into the cloud image name?
<fgimenez> elopio, ok thx, i'll correct that and some errors because of the import paths, at least when running from an instance without gopath defined
 * ogra_ builds a new image
<ogra_> oh, i cant
<ogra_> !
<ogra_> mvo, where is your snap ? :)
<ogra_> (could you upload it somewhere)
<ogra_> oh man !
<ogra_> ogra@anubis:~/datengrab/rpi/uboot/bbb/snappy/snappy-systems$ snappy revert
<ogra_> Unknown command `revert'. Please specify one command of: booted, build, config, firstboot, hw-assign, hw-info, hw-unassign, info, install, internal-run-hooks, internal-unpack, list, login, purge, remove, rollback, search, set, update or versions
 * ogra_ makes snappy a hardlink to bzr on his machine :P
<mvo> ogra_: http://people.canonical.com/~mvo/tmp/beagleblack_1.11_all.snap
<ogra_> thx
<mvo> yw
 * rsalveti reads backlog
<mvo> yay, looks like the image is there
<ogra_> yep
<Chipaca> mvo: when you have a moment, and it's not urgent at all, i could use a review on https://code.launchpad.net/~chipaca/snappy/service/+merge/265658
<Chipaca> also on its pre-req
<mvo> Chipaca: sure
 * Chipaca ~> lunch
<mvo> rsalveti: executive summary: more fighting with uboot and its quirks, we *think* we have a final image
<ogra_> yeah
<mvo> rsalveti: that just finished building ~2min ago
<ogra_> we are pretty pretty sure we do :)
<mvo> rsalveti: if ${var_that_is_not_set} = "1"; then echo yes; fi returns yes in uboot, that took us a while to figure out (well, me at least)
<mvo> even with quotes its still not working on an older uboot
<ogra_> boolean ftw :)
<Chipaca> mvo: ogra_: in uboot, does if "11" = "1"; then echo yes; fi produce yes?
<Chipaca> ie, is = a prefix search?
<ogra_> no
<ogra_> but if "" = "1" can produce yes in older versions
<ogra_> Chipaca, http://git.denx.de/?p=u-boot.git;a=commit;h=2453de99df576fb907fe06cac58c628e3590833f
 * ogra_ twiddles thumbs waitin for dd
<mvo> ogra_: use godd, it tells me that I need to wait 8 more min utes
<mvo> this makes the thumb twiddle much more planable
<ogra_> mvo, but it doesnt speed up anything
<Chipaca> or killall -USR1 dd
 * mvo thinks about complex patterns 
<ogra_> i know how to get a progressbar ... i wrote usb-imagewrite 5 years ago using the USR hack
<mvo> ogra_: did you send a USR signal every N seconds? just curious?
<mvo> Chipaca: shhh, don't tell people that the 7 lines of go code for godd are not needed ;)
 * ogra_ would be more interested in a patch to dd so that it automatically determines the fastest blocksize for me and speeds up the write ;)
<Chipaca> ogra_: mvo: clearly, your computers need more ram! http://downloadmoreram.com/
<ogra_> mvo, yeah ... two processes
<ogra_> a shell wrapper to call the dd with a watch ... and a pygtk UI that reads from it to show a UI progressbar
<ogra_> (i never found the time to port it away from hal though ... and left it die)
<mvo> ogra_: neat!
<ogra_> heh, it is still promoted on https://help.ubuntu.com/community/Installation/FromImgFiles
<ogra_> "for systems up to 12.10" ... :P
 * ogra_ boots the new image 
 * ogra_ reboots and crosses fingers
<ogra_> yay ... boots from b
<mvo> same here
<ogra_> rebooting back to a
<ogra_> works too :)
<mvo> yay
<ogra_> ok, lets torture it a bit with reset button and reboot -f
<mvo> go go go
<mvo> and someone needs to test upgrades from older image sto the new and check that the old uEnv.txt is still fully supported and understood
<mvo> etc
<ogra_> we need the images for that ... on the server i mean
<ogra_> and the snap approved in the store
<ogra_> (not sure how else you could upgrade manually ... does sideloadign the oem snap work ?
<ogra_> mvo, btw, why do we need to give a and b ... wouldnt it be better to have something like "other" and snappy or the bootloader automatically pick the currently not used path ?
<mvo> ogra_: hm, upgrading the oem snap is actually a problem, we can't allow that before we can not also write a new uboot
<ogra_> so i think it tried all possible ways to kill it now ... removing power, reset button "reboot -fp" ... no corruption
<ogra_> (and it reacts as expected still)
<ogra_> that shoudl also finally fix vmayorals issues with the erle bots
<mvo> yeah, someone needs to send him a mail that its finally under control
<mvo> (if he is not on irc)
<ogra_> well, once we released it i'll write an announcement mail and also some documentation for porters
<ogra_> i just dont want to do that before we have a 100% final implementation
<mvo> ogra_: uh, looks like someone approved beagleblack 1.9 in the store
<ogra_> (seems we hit a roadblock every time we think we are done ... i got careful :) )
<ogra_> mvo, eeek !
<ogra_> so better push .11 over it
<mvo> ogra_: well, the remaining roadblock is what to do with existing users
<ogra_> right
<rsalveti> mvo: wow, that is annoying (the if check issue)
<rsalveti> and wow, you guys had a lot of fun :-)
<ogra_> LOL
<ogra_> FSVO fun :)
<rsalveti> so you guys had to path u-boot in the end?
<mvo> ogra_: puhh, all good, I *think* we are save, boot-assets are only handled by u-d-f so we are good for the upgrade
<ogra_> no, in the beginning :)
<rsalveti> *patch
<ogra_> rsalveti, we only ptach the enabling of uboot.env into the config, nothing more
<rsalveti> right, cool
<ogra_> *patch
<ogra_> :P
<rsalveti> mvo: ogra_: so did we approve the oem we didn't yet want to land?
<ogra_> (such a hard word to type :P )
<rsalveti> beagleblack 1.9
<ogra_> yes
<rsalveti> why?
<ogra_> but there is a 1.11 that we need anyway
<ogra_> no idea, i dont know who approved and why
<rsalveti> so would 1.9 break the current stable image?
<ogra_> yes
<rsalveti> crap
<longsleep> so is the new image ready - so i can give it another try?
<ogra_> half breeded
<ogra_> which is why we havent approved it
<ogra_> longsleep, yeah
<rsalveti> well, if 1.9 is already causing us pain, just push 1.11
<ogra_> mvo, ^^^
<rsalveti> and let's hope we can release today
 * longsleep is downloading
<rsalveti> at least we can test it easily
<ogra_> rsalveti, +1 ... that took way to long again :/
<rsalveti> ogra_: might be a good time to promote latest edge to alpha
<ogra_> does that make sense without the snap ?
<ogra_> i think we need 1.11 first ... then promote
<rsalveti> sure, I was assuming we can do both in parallel
<ogra_> or that, yeah
<longsleep> all right, booted into 129 - lets have some fun
<longsleep> ogra_, mvo : 129 works just fine (faking update by fw_setenv snappy_ab b; fw_setenv snappy_mode try; reboot)
<ogra_> yay
<longsleep> let me try rollback
<longsleep> ogra_, mvo : Rollback works as well - so all green from me :)
<rsalveti> ogra_: do we need to wait for mvo to upload a new oem?
<longsleep> from what i understand is that old oem should work with new image but new oem will not work with old image
<longsleep> that the state for my odroidc oem at least
<ogra_> longsleep, \o/
<ogra_> rsalveti, it is uploaded but someone needs to approve it
<mvo> rsalveti: already uploaded, just needs approval
<rsalveti> I guess I can approve it, but would need to find it first
<rsalveti> let me check
<ogra_> https://myapps.developer.ubuntu.com/dev/click-apps/2277/
<rsalveti> ogra_: mvo: done
<mvo> longsleep: thanks a bunch for all your help and testing and feedback
<mvo> rsalveti: \o/
<ogra_> so let me push edge to alpha then
<mvo> elopio, fgimenez do you guys have time to test the new 15.04 image in edge? we need to be sure that upgrades do not break, especially with beagleblack 1.8 from the last stable to the current alpha
<mvo> ogra_: cool
<fgimenez> mvo, sure, on it
<mvo> thanks!
<elopio> mvo: yes.
<ogra_> mvo, hmm, that doesnt look right http://system-image.ubuntu.com/ubuntu-core/15.04/edge/generic_amd64/
<elopio> fgimenez: mvo: current stable is the same as alpha#3, so we can start flashing that one.
<ogra_> mvo, last build is from yesterday
<elopio> fgimenez: want to meet, or do you prefer to spend the time testing?
<mvo> ogra_: oh, I did not triggered amd64, one sec
<ogra_> mvo, did you buiuld with ARCHES= set when you re-triggered a build ?
<mvo> ogra_: I did
<ogra_> ah
<mvo> ogra_: to speed it up
<ogra_> yeah
<ogra_> armhf is copied to alpha now
<mvo> I triggered a full build now too
<ogra_> waiting for amd64 now :)
<fgimenez> elopio, as you like, i have the ho open :)
<mvo> elopio: great, the important part is that beagleback is still 1.8 on the base image so that we are confident that existing users will not break with the new oem part. I'm 96% certain they won't but the remaining 4% worry me a bit
 * longsleep thinks i should implement that into the new oem as well
<longsleep> mvo: how did you handle this case, how do you know if you have to load snappy-system.txt ?
<mvo> longsleep: I check for /boot/uboot/uboot.env, if thats there I assume its the new system. this will only be put in place by u-d-f
<longsleep> mvo: ah - you are saying that updating the oem snap from the store does not change stuff below /boot/uboot ?
<longsleep> mvo: or where is this check?
<mvo> longsleep: yes, new boot-assets are not put into place
<longsleep> mvo: ok, that essentially means that there is no way to upgrade from old oem uboot to new one?
<ogra_> longsleep, works in rollinng afaik
<vmayoral> hi everyone, just realized https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ changed
<vmayoral> i noticed that system-a is now "2 GB"
<vmayoral> do the new BeagleBone Black images includes this change?
<longsleep> ogra_: you mean in rolling, the boot-assets are put in place on update?
<vmayoral> also, what happened to "system-boot"?
<vmayoral> mmm, the filesystem information conflicts with what's provided at https://developer.ubuntu.com/en/snappy/guides/transactional-updates/
<rsalveti> hm, it shouldn't be 2gb, wonder what happened in there
<ogra_> vmayoral, FYI we reworked the uboot bits the last days, i'll write an announcement and documentation soon, that should one and for all fix all your corruption issues
<vmayoral> ogra_: that's great, thanks a lot
<ogra_> you likely want to adjust your oem snaps for that then
<vmayoral> ogra_: the oem snap?
<ogra_> well, the ones you use for your bootloader
<ogra_> (i think i saw a few in the store)
<vmayoral> ogra_: i'd expect to modify something within the boot partition (e.g. the initrd.img). Currently our oem snap does not contain any dtb
<ogra_> oh, i didnt know, i thought you include uboot and a uboot confi for the dtb overrides
<vmayoral> ogra_: that'll happen soon i hope :)
<Chipaca> rsalveti: wrt bug 1466672, given that webdm isn't useful if there's no network, i think what we want to happen is it's only started when an external interface is brought up
<ubottu> bug 1466672 in Snappy trunk "webdm failed to start / Failed to listen 224.0.0.251:5353" [Undecided,New] https://launchpad.net/bugs/1466672
<ogra_> +1
<ogra_> its doesnt do that currently though
<ogra_> there is no auto-starting
<Chipaca> rsalveti: given that, i propose we modify the generated service startup scripts so that, if a service specifies an external port, we make it depend on having an external network
<ogra_> ok, seems the image is done
<elopio> mvo: so, I can't flash alpha like this: http://paste.ubuntu.com/11925656/ ?
 * ogra_ copies again to alpha
<Chipaca> rsalveti: keying off of having an external port means we can implement it with no changes to published meta description
<ogra_> elopio, oh, why ?
<elopio> ogra_: not sure, it's booting into debian.
<elopio> might be my sdcard, so I'll try with the new one.
<ogra_> did you hold down the S2 button ?
<elopio> ogra_: no.
<elopio> didn't we change it so the s2 button does nothing anymore?
<ogra_> well, try that :)
<ogra_> no, we cant change the RM
<ogra_> *ROM
<fgimenez> elopio, mvo ogra_ mmm it seems to fail to rollback from 6 to 3 here http://paste.ubuntu.com/11925667/
 * ogra_ would like to see the bootloader messages on serial console for that 
<fgimenez> how can i get the output from the serial console?
<ogra_> with your serial cable :)
<elopio> fgimenez: ctrl+a + H saves it to a log file
<fgimenez> ogra_, yep :) but the screen... ok thx elopio
<elopio> that's ctrl+a and then H
<mvo> elopio: might be that you get a beaglebone thats too new I wonder if the store can give you 1.8, let me see
<ogra_> or if you use screen use the -L option
<ogra_> it will create a screenlog.0 file and log everything in $(pwd)
<fgimenez> ogra_, ok thx, trying now
<longsleep> mvo: just trying update from 129 to 130 - getting "can not find file /writable/cache/assets/vmlinuz" http://paste.ubuntu.com/11925676/ - any idea?
<longsleep> update seems to work
<ogra_> despite the errors ?
<ogra_> *error
<longsleep> well, it wrote the other patition, trying boot now
<mvo> elopio: could you please try if http://people.canonical.com/~mvo/tmp/beagleblack_1.8_all.snap with u-d-f works? so download and then --oem ./beagleblack_1.8_all.snap ?
<elopio> mvo: sure.
<longsleep> ogra_: no - it seems it did not write the changes to the environment
<ogra_> hrm
<longsleep> (ODROIDC)root@odroid:~# snappy list -v
<longsleep> Name        Date       Version Developer
<longsleep> ubuntu-core 2015-07-23 129     ubuntu*
<longsleep> ubuntu-core 2015-07-23 130     ubuntu!
<longsleep> odroidc     2015-07-23 0.3     *
<longsleep> Reboot to use the new ubuntu-core.
<longsleep> when i reboot it boots into 129
<mvo> fgimenez: so you upgraded from 3->6 and then the rollback showed the behvior in the pastebin? could you pastebin ls -al /boot/uboot/ please
<mvo> longsleep: so you just get this warning? let me look at the source, no ideas right from the top of my head
<elopio> mvo: is there an option to allow-unauthenticated from udf? beagleblack_1.8_all.snap failed to install: Signature verification failed
<longsleep> mvo: yes that warning and nothing more
<mvo> longsleep: oh, so your changes got applied to the other partiton but it did not boot the other one?
<longsleep> mvo: correct
<ogra_> elopio, weird, that works locally
<fgimenez> mvo, of course, this is the serial console log http://paste.ubuntu.com/11925689/
<mvo> elopio: I thought it did that automatically with --developer-mode :/
<fgimenez> ogra_, ^
<longsleep> mvo: probably stopped because of the vmlinuz error before modify of the uboot.env
<ogra_> elopio, sudo ubuntu-device-flash core --channel=edge --oem beagleblack_1.8_all.snap --developer-mode -o bbb.img 15.04
<elopio> mvo: That's it. I wasn't using dev mode.
<mvo> longsleep: what does fw_printenv|grep ^snappy show? and ls -al /boot/uboot?
<mvo> longsleep: aha, that makes sense, yes
<mvo> elopio: cool
<longsleep> mvo: http://paste.ubuntu.com/11925696/
<fgimenez> mvo, http://paste.ubuntu.com/11925697/
<mvo> ogra_, fgimenez I wonder if the rollback failed because of spl_load_image_fat_os: error reading image args, err - -1 in the pastebin
<longsleep> mvo: but why does it want an vmlinuz file - my oem snap provides uImage
<vmayoral> guys, recently i've noticed that when creating some snaps, I get ".sideload" at the end. Can anyone explain why's that?
<ogra_> mvo, no
<mvo> fgimenez: it looks like it tried booting a, then failed and reverted to b?
<mvo> ogra_: no?
<ogra_> mvo, SPL doesnt need more than finding uboot.img
<longsleep> mvo: sorry meant device tarball - that provides uImage and not vmlinuz
<ogra_> you can ignore the messages
<mvo> longsleep: ohhh, I think we may have hardcoded vmlinuz :/
<longsleep> mvo: ah - well
<mvo> longsleep: we call it "normalized" instead of hardcoded but its the same :(
<longsleep> mvo: i guess i can write it to vmlinuz even if it is not a vmlinuz
<mvo> fgimenez: thanks, the uboot dir looks fine, you were not migrated to the new uboot.env which is what we expected
<ogra_> riht
<ogra_> the serial log looks ok too
<longsleep> mvo: you should probablu use the name provided in device/hardware.yaml - there i say kernel: assets/uImage
<ogra_> loads the old files, they seem to contain data too and it even writes snappy-stamp.txt
<mvo> ogra_: in the pastebin http://paste.ubuntu.com/11925689/ I see in line ~205 that it tries to load a/vmlinz, boots it, then 227 has the uboot prompt again and it boots b/ again, so I wonder if the kernel on a/ failed somehow
<mvo> longsleep: *cough* indeed
<ogra_> mvo, yeah, but why would it ? its the same kernel
<mvo> longsleep: thats a diferent bug, I need to look at this (or sergio when he is back)
<mvo> ogra_: I have no clue, there is also no message
<ogra_> right
<mvo> unless its the same corruption we are trying to fix with the new uboot.env
<mvo> but that feels a bit too much like magic-rabitt-to-explain-this-problem
<ogra_> yeah
<ogra_> and that usually also errors
<ogra_> there are no errors
 * mvo nods
<ogra_> fgimenez, can you paste uEnv.txt and snappy-system.txt
<mvo> fgimenez: could you md5sum the kernels in /boot/uboot/?/vmlinuz
<rsalveti> Chipaca: I think that's ok
<longsleep> mvo: i will add a ticket, and change my device tarball to use vmlinuz
<mvo> longsleep: thanks
<rsalveti> but yeah, we can start the service once we get the network I guess
<fgimenez> ogra_, http://paste.ubuntu.com/11925725/
<ogra_> fgimenez, thanks, looks all as expected
<fgimenez> mvo, http://paste.ubuntu.com/11925728/
<ogra_> interesting !
<ogra_> they should be the same binary
<ogra_> i wonder if mvo is actually right and we hit fs corruption on the old version
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ md5sum /boot/uboot/?/vmlinuz
<ogra_> 73d20f826ae7ec09671950057dee0db8  /boot/uboot/a/vmlinuz
<ogra_> 73d20f826ae7ec09671950057dee0db8  /boot/uboot/b/vmlinuz
<ogra_> that is how it shoudl look like
<ogra_> so i guess the a kernel got corrupted somehow
<mvo> elopio: you are writing a alpha rev3 image too right? what md5sum do you have for the kernel(s). does it match http://paste.ubuntu.com/11925728/?
<mvo> longsleep: thanks! this part the code in snappy needs some love iirc
<longsleep> mvo: yeah - added bug #1477657 - now chaning stuff to be named vmlinuz (btw, that worked when updating from 2 to 3 in stable). Do you check for initrd name as well (because that is named uInitrd for me)
<nothal> Bug #1477657: Snappy update fails because of hardcoded assets/vmlinuz <Snappy:New> <http://launchpad.net/bugs/1477657>
<ubottu> bug 1477657 in Snappy "Snappy update fails because of hardcoded assets/vmlinuz" [Undecided,New] https://launchpad.net/bugs/1477657
<mvo> ogra_: there were some more issues with non-store device part updates, right  ? longsleep is hitting some issue - or is the odroid oem in the store?
<ogra_> the latter
<ogra_> and no, updates in 15.04 should theoretically work, we never blocked them there
<ogra_> (practically it is a matter of the uboot setup )
<ogra_> if they used to work they shoudl still do
<longsleep> right - but my uboot setup is fine and stable updates with my released stuff from https://www.stdin.xyz/downloads/snappy/odroidc/ work
<longsleep> (that is the same snap as in the store)
<elopio> mvo: nop: http://paste.ubuntu.com/11925776/
<ogra_> lol
<ogra_> so now we have 3 different md5 sums for the same kernel
<ogra_> (... proposedly same kernel)
<fgimenez> elopio, that's before the update + rollback, right?
<elopio> fgimenez: yes, I've just flashed
<elopio> with http://paste.ubuntu.com/11925790/
 * mvo gets dinner
<fgimenez> elopio, mine was after, i flashed the image with the normal --oem beagleblack
<elopio> updating now...
<Chipaca> why, oh why, has go decided that setsockopt is private?
<Chipaca> :-(
<ogra_> fgimenez, yeah, i dont think that works, you cant use the current snap in the store with an image 3 rootfs
<ogra_> you would have to use the 1.8 version of it
<ogra_> http://people.canonical.com/~mvo/tmp/beagleblack_1.8_all.snap
<fgimenez> ogra_, ok thx, i'll try that
<fgimenez> ogra_, elopio btw i flashed the alpha #3 -image for the previous
<fgimenez> release, a week or so ago
<ogra_> fgimenez, yes, but using the new oem snap from the store
<longsleep> mvo: mhm even when i ship vmlinuz in my device tree it still fails with same error
<elopio> so, I do snappy rollback ubuntu-core 3
<elopio> and I also have to rollback the beaglebone package, right?
<elopio> or it will magically rollback?
<ogra_> no, you dont
<ogra_> it *should* be backwards compatible on upgrades
<ogra_> "should"
<ogra_> "should"....
<elopio> let's see...
<longsleep> (the folder also does contain a initrd.img and initrd.img-3.19.0.0-23-generic)
<fgimenez> ogra_, ok, the oem snap was already the new one by then, thanks
<ogra_> longsleep, yeah, thats something still to fix on sergiusens plate ... we need the versioned binary to make system-image recognize there is a new binary
<longsleep> ogra_: mhm i dont understand - the only thing which needs to happen is the change to the environment to try the update - isnt it?
<ogra_> longsleep, yeah, the versioned vmlinuz is unrelated to that
<fgimenez> leaving, nice evening o/
<longsleep> ogra_: ok - so now i am stuck, seems like the update does require a vmlinuz file in /writable/cache/assets which i have no way to provide
<elopio> nop, can't rollback.
<elopio> now I get the same md5sums that fginther
<ogra_> elopio, los ?
<ogra_> *logs
<elopio> sorry fginther. fgimenez left.
<elopio> ogra_: on their way.
<ogra_> (serial specifically)
<fginther> elopio, nw
<mvo> elopio: same output as well, i.e. it tries to boot a/ (or b/) and then you return to the uboot prompt?
<elopio> ogra_: mvo: http://people.ubuntu.com/~elopio/logs/bbb-rollback-alpha7-3.log.0
<elopio> mvo: yes.
<ogra_> sigh, why cant any browser open that inline
<longsleep> mvo: so seems i am unable to do an automatic update, because of it not finding vmlinuz - i updated #1477657 accordingly
<ogra_> elopio, if you cp the b kernel to the a partition, does it work then (make a backup of the file in a first)
<ogra_> mvo, elopio, hmmm, is that the cirrect uboot that is being used there ?
<ogra_> *correct
<ogra_> looks like the onboard one
<ogra_> (iirc ours had a git hash in the version instead of -dirty, i could be wrong though)
<elopio> ogra_: $ sudo cp /boot/uboot/b/VMLINUZ /boot/uboot/a/ ?
<elopio> it starts booting on a
<elopio> but it says LZMA data is corrupt
<ogra_> elopio, right, it starts and then resets itself and boots b
<ogra_> oh, you mena after the copy ?
<ogra_> *mean
<elopio> ogra_: yes, after copy. It doesn't reset.
<ogra_> ok, copy the initrd too
<elopio> it's stuck waiting for root device ... system-a
<ogra_> the lzma error likely talks about the initrd
<elopio> ogra_: emergency mode.
<ogra_> did it load the initrd before going there ?
<elopio> ogra_: yes: http://people.ubuntu.com/~elopio/logs/bbb-rollback-alpha7-3-copying_b_kernel.log.0
<ogra_> oh, why can my browser open this one inline but couldnt the former ... weird
<ogra_> elopio, ah, thats expected since you use a kernel that has no modules in that rootfs
<ogra_> so yeah, your a kernel *and* your a initrd were corrupt ... wow, thats really gross
<ogra_> rsalveti, ^^
<ogra_> rsalveti, after upgrading from alpha 3 the original alpha3 kernel in /boot/uboot/a/ and the initrd get broken
 * ogra_ scratches head
<longsleep> ogra_: after update, should i still have the old version on the "other" partition?
<ogra_> oh, meanwhile my 129 install upgraded in bg and asks me to reboot
 * ogra_ does so 
<longsleep> ogra_: nice - that is was failed for me because of bug #1477657 :(
<nothal> Bug #1477657: Snappy update fails because of its looking for non existing /writable/cache/assets/vmlinuz <Snappy:New> <http://launchpad.net/bugs/1477657>
<ubottu> bug 1477657 in Snappy "Snappy update fails because of its looking for non existing /writable/cache/assets/vmlinuz" [Undecided,New] https://launchpad.net/bugs/1477657
<ogra_> longsleep, yeah, a should still have the install kernel and b the one for the new image
<longsleep> ogra_: ok - so then i can confirm that update works fine when i set the uboot.env stuff manually
<longsleep> i now have booted 130 and 129 on the other
<longsleep> ogra_: so for you there is a vmlinuz in /writable/cache/assets/ ?
 * longsleep wonders where this comes from
<ogra_> Name        Date       Version Developer
<ogra_> ubuntu-core 2015-07-23 129     ubuntu*
<ogra_> ubuntu-core 2015-07-23 130     ubuntu!
 * ogra_ curses
<longsleep> mhm - maybe your update also didnt set the env variables then
<ogra_> so it clearly boots from the b partition ... i see it mounting system-b during boot as readonly partition ...
<ogra_> but snappy thinks i'm still on 129
<longsleep> mhm thats strange
<ogra_> yes
<ogra_> snappy bug most likely
<longsleep> mine says i am on 130
<longsleep> what does the exclamation mark mean?
<longsleep> i am pretty sure it means something as mine does not have it
<ogra_> /dev/mmcblk0p3 on / type ext4 (ro,relatime,data=ordered)
<ogra_> definitely the b partition
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ ls /writable/cache/assets/
<ogra_> initrd.img  initrd.img-3.19.0-23-generic
<ogra_> no vmlinuz here
<ogra_> but i guess simply because we didnt update it (system-image strips it then)
<longsleep> mhm - then maybe you have the same error but just didnt see it because you auto updated and i did it manually by calling snappy update ?
<ogra_> no
<ogra_> i called snappy update the second time
<ogra_> didnt change a thing
<longsleep> mhm
<ogra_> it boots by default from b now
<longsleep> ok
<ogra_> but snappy still thinks it is 129
<longsleep> what if you boot from a ?
<ogra_> hmpf
<ogra_> snappy rollback also only boots from b
 * longsleep tries that
<longsleep> ogra_: yes confirmed - snappy rollback does not work for me either - still booted 130 / 129 now marked with !
<mvo> ogra_: what values do you have in /etc/system-image/channel.ini ?
<mvo> ogra_: and /writable/cache/system//etc/system-image/channel.ini ?
<ogra_> http://paste.ubuntu.com/11926102/
<ogra_> http://paste.ubuntu.com/11926112/
<ogra_> writable has 130
<longsleep> added another bug #1477692 about the rollback issue
<nothal> Bug #1477692: snappy rollback ubuntu-core does not change uboot.env <Snappy:New> <http://launchpad.net/bugs/1477692>
<ubottu> bug 1477692 in Snappy "snappy rollback ubuntu-core does not change uboot.env" [Undecided,New] https://launchpad.net/bugs/1477692
<longsleep> is there a way to undo the rollback, unmark it somehow?
 * ogra_ doesnt know 
<ogra_> this starts getting depressing :(
<longsleep> do it like me, grab some cuba libre from the bar next door
<ogra_> no bars around me ...
<ogra_> (i live in an awkward place in an awful city :/ )
<longsleep> you should grab your laptop and go to a bar :P
<ogra_> well, the only bars kassel has are on the other side of the city
<ogra_> and are not exciting either ...
<Chipaca> ogra_: longsleep: a manual update should undo the manual rollback
<ogra_> Chipaca, well, whatever i do it boots from b
<ogra_> neither update nor rollback change that
<ogra_> (i guess i could enforce it by setting the uboot vars directly though, but not via any snappy command it seems)
<mvo> ogra_: that means the snappy output is correct its really in 129, what does fw_printenv |grep ^snappy show?
<ogra_> oh, wow, that works without sudo !
<ogra_> mvo, everything as expected http://paste.ubuntu.com/11926167/
<mvo> ogra_: hm, except that it should be snappy_ab=a, no?
<ogra_> for 129, yes
<ogra_> for the state i'm in b is correct ... since it booted that
<ogra_> (but indeed 129 isnt then)
<mvo> you are b with 129 but you actually want to be in a which is 130, do I understand that correctly?
<ogra_> no
<ogra_> b should be 130
<ogra_> i got an auto upgrade and got asked to reboot
<ogra_> that properly booted to b ... but still shows 129
<mvo> what was b before? and a?
<ogra_> a was my original install of 129
<mvo> and now a is 130?
<ogra_> no idea, i cant boot to a
<ogra_> unless i hack the vars directly
<ogra_> (i guess, didnt try yet)
<mvo> oh, hm, what does snappy set ubuntu-core active=130 give you?
<mvo> with sudo
<ogra_> i installed 129 and booted to a ... then i got an auto update and was asked to reboot ... on reboot i see it booting to b proper ... but snappy list still shows i'm running 129
<ogra_> nothing
<ogra_> =129 doesnt return anything either though ...
<mvo> ok, let me look deeper, thanks!
<ogra_> just dumps me back to the shell prompt
<longsleep> Chipaca: mhm snappy-update ubuntu-core does nothing
<mvo> I think there is another missing piece
<mvo> I'm on it
<ogra_> yeah
<ogra_> looks like
<ogra_> meanwhile i'll try to manually switch back to a to check potential corruption
<ogra_> yup, manually works fine
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ snappy list -v
<ogra_> Name        Date       Version Developer
<ogra_> ubuntu-core 2015-07-23 130     ubuntu*
<ogra_> ubuntu-core 2015-07-23 129     ubuntu
<ogra_> after manual switch to a
<longsleep> yes i did that too
<ogra_> so apparently a actually has 130 ... and b had 129 ...
<longsleep> worked for me
<ogra_> for whatever weird reason
<ogra_> ok, snapy rollback doesnt roll me back
<ogra_> still boots a
<longsleep> yes - me neither
<ogra_> but at least i dont have any coorruption here
<longsleep> i am now stuck in this
<longsleep> (ODROIDC)root@odroid:~# snappy list -v
<longsleep> Name        Date       Version Developer
<longsleep> ubuntu-core 2015-07-23 130     ubuntu*
<longsleep> ubuntu-core 2015-07-23 129     ubuntu!
<longsleep> odroidc     2015-07-23 0.3     *
<longsleep> Reboot to use ubuntu-core version 129.
<longsleep> cant seem to set it back to 130
<ogra_> now ... why do we get corruption when switching from image 3 to the latest
<longsleep> mhm - maybe the fat in 3 is already corrupted?
<ogra_> longsleep, yeah ... mvo is on it
<ogra_> longsleep, well, it isnt corrupted until you upgrade apparently
<mvo> longsleep: I will have something ready RSN
<mvo> Chipaca: will you be around for a review?
<ogra_> and the fat as a whole seems to be ok ... only the a directory contents are corrupted after upgrade
<davmor2> ogra_: not using a big enough hammer
<ogra_> davmor2, dude ... hammers all the way down here ... and from the sides too
<ogra_> no dice though
<ogra_> :)
<mvo> ogra_: hm, if we still have corruption :(
<ogra_> mvo, i dont
<ogra_> mvo, federico and elopio do when coming from image 3
<longsleep> So, if you guys are interested in why i am working on the ODROID stuff with snappy - check out https://www.kickstarter.com/projects/spreed/spreedbox-the-most-private-video-chat-and-file-exc
<longsleep> just launched
<ogra_> mvo, the old kernel and initrd are trashed if you upgrade from old to now
<ogra_> i.e. from the snappy-system-txt way ...
<mvo> ogra_: aha, only with the old uboot? thats ok
<ogra_> mvo, not really ok ... but yeah
<ogra_> there is no reason why the a subdir content should get corrupted
<ogra_> (b is fine)
<ogra_> it only breaks rollback though
<mvo> ogra_: could you please put http://people.canonical.com/~mvo/tmp/snappy_armhf onto your image as /usr/bin/snappy and see if that helps?
<ogra_> oh how i hate that we dont have wget on the image :P
<mvo> Chipaca: https://code.launchpad.net/~mvo/snappy/15.04-snappy-more-uboot-fiddling if you have a moment should unblock ogra and I will a version in trunk thats nicer
<ogra_> mvo, rollback seems to work, update doesnt ...
<ogra_> though i might have confused the system with my manual switching before upgrading in the beginning
<ogra_> (by using fw_setenv for corruption tests)
<ogra_> why does snappy update always re-download 130
 * ogra_ considers a fresh flash of 129, i think i cinfused the system to much
<rsalveti> elopio: ogra_: usually when the kernel name is VMLINUZ instead of vmlinuz that means the fs got corrupted somehow
<ogra_> rsalveti, well, only the a directory
<ogra_> rsalveti, he can fix it by copying the b content to the a dir
<ogra_> well, "fix" ... it then fails to find the modules indeed
<rsalveti> if you are coming from 3, that is expected, isn't it?
<rsalveti> because it will still run fatwrite
<ogra_> rsalveti, fatwrite writes to the toplevel dir
<rsalveti> still, that is the original behavior I had
<ogra_> rsalveti, the a dir shouldnt be touched at all
<rsalveti> fsck was later touching everything
<ogra_> there was no fsck ... at least i didnt see it in the logs
<rsalveti> the long file names were all renamed to match 8 chars
<rsalveti> should be
<rsalveti> during boot
<ogra_> well, erhaps i didnt see all logs
<ogra_> rsalveti, so not being able to roll back to 3 is acceptable ?
<rsalveti> let me start fresh with image 3
<ogra_> i wonder what happens for the next rollback then :/
<rsalveti> ogra_: right, we can't avoid that
<rsalveti> because we can't update the bootloader
<rsalveti> and the updater is not yet separated
<ogra_> well, people using fatwrite will go on doing so
<ogra_> while people installing freshly will get the new behavior
<rsalveti> right, what we said is that we'd ask people to manually update the bootloader
<rsalveti> at least for this release
<rsalveti> while we can fix the remaining issues, like splitting the updater and making it able to upgrade the bootloader
<ogra_> k
<mvo> Chipaca: and https://code.launchpad.net/~mvo/snappy/snappy-more-uboot-fiddling
<mvo> ogra_: keep me updated, need to bring the kids to bed
<ogra_> all i'm worried about now is what happens if you upgrade from 4 to 5 or some such
<mvo> ogra_: if the new snappy binary helps or not
<ogra_> mvo, will do ... i just created a new 129 image and wont touch the bootloader vars this time
<ogra_> mvo, rollback worked ... update didnt ... but i'm not sure thats not caused by my tinkering
<mvo> ogra_: cool, you can also just copy uboot.env from e.g. the beagleblack 1.11 snap, saves some time :)
<rsalveti> ogra_: did we publish 2 images for alpha?
<mvo> ogra_: keep me updated if it updates the env vars etc, I will check back in some minutes
<ogra_> rsalveti, yes, i didnt notice that there were no amd64 builds
<ogra_> my fault, sorry
<ogra_> (amd64 only had one promotion)
<rsalveti> oh, but only for amd64
<rsalveti> sorry, armhf
<ogra_> yes
<rsalveti> would like to align the numbers if possible
<ogra_> to make sure we have the same content
<ogra_> hmm
<rsalveti> otherwise this will create even more confusion
<rsalveti> but I also wanted us to release another image to alpha
<rsalveti> so we could test the upgrade from -1 to latest
<ogra_> yeah, but i'm not sure thats easily doable if we dont do an amd64 only build
<rsalveti> to make sure the new logic will handle the next update without corruption
<rsalveti> let's do one amd64 only build
<ogra_> (though i guess we can do that to get them in line again)
<rsalveti> and do a build for both
<ogra_> will do once we're ready
<ogra_> there are still issues
<rsalveti> ogra_: what are the current issues?
<ogra_> rsalveti, rollback not working
<rsalveti> rollback from what?
<ogra_> (snappy rollback is a no-op)
<rsalveti> 3->7->3?
<rsalveti> that might indeed be a problem
<ogra_> yes :)
<rsalveti> because since we're not creating the stamp anymore
<ogra_> mvo has a fix ... i'll test in a minute with a fresh 129 image
<rsalveti> great
<mvo> well still create the stamp if you start from 3, no? we do not change existing snappy-system.txt or uEnv.txt the new boot-assets are only applied on fresh u-d-f runs
<mvo> of course, once a user manually flahes he/she can not go back
<ogra_> yeah, afaik
<mvo> cool, so we are all aligned
<ogra_> ok, so i'm booted into 129 on partition a ... i did put snappy_armhf in place and am now updating
 * ogra_ twiddles thumbs
 * ogra_ wonders why he gets to awful download rates
<ogra_> mvo, hmm http://paste.ubuntu.com/11926470/
<ogra_> (see the pre-last line)
<rsalveti> isn't this the issue longsleep had?
<ogra_> bug #1477657
<nothal> Bug #1477657: Snappy update fails because of its looking for non existing /writable/cache/assets/vmlinuz <Snappy:New> <http://launchpad.net/bugs/1477657>
<ubottu> bug 1477657 in Snappy "Snappy update fails because of its looking for non existing /writable/cache/assets/vmlinuz" [Undecided,New] https://launchpad.net/bugs/1477657
<ogra_> yes
<ogra_> anything i should capture before reboot ?
 * ogra_ wnats to see if it at least boots to b now 
<longsleep> ogra_: ah - thats a relief you see that issue too
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ ls /writable/cache/assets/
<ogra_> initrd.img  initrd.img-3.19.0-23-generic
<ogra_> and it is correct :)
 * ogra_ reboots anyway 
<longsleep> will not boot to the one it just updated as the env file was not updated
<ogra_> yay
<ogra_> boots from b
<longsleep> oh
<longsleep> then something was fixed?
<ogra_> well, i'm testing mvo's new snappy binary from above
<longsleep> ah i see
<longsleep> that makes sense
<longsleep> so the error is no error and only a warning
<ogra_> well, it might be an error ... the bootloader config is updated before though ... see my paste
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ snappy list -v
<ogra_> Name        Date       Version Developer
<ogra_> ubuntu-core 2015-07-23 130     ubuntu*
<ogra_> ubuntu-core 2015-07-23 129     ubuntu
<ogra_> yay
<ogra_> now lets see rollback
 * longsleep cheers
<rsalveti> great
<ogra_> nope ...
<ogra_> still boots from b
<ogra_> oh !
<ogra_> wait :P
<rsalveti> did it work?
<ogra_> i replaces snappy with the new binary on a but not on b
<ogra_> rsalveti, no
<rsalveti> sigh
<ogra_> but the b partition has the wrong snappy binary
<ogra_> once cloud-init is done and i can log in i'll try again
<ogra_> *twiddle*
<ogra_> YAY
<ogra_> works
<ogra_> rollback gets me back to a now
 * ogra_ will try that a few times to be sure
<ogra_> sigh ... cloud-init ...
<ogra_> another minute of wasted worktime
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ snappy list -v
<ogra_> Name        Date       Version Developer
<ogra_> ubuntu-core 2015-07-23 129     ubuntu*
<ogra_> ubuntu-core 2015-07-23 130     ubuntu
 * ogra_ snappy updates again 
<ogra_> properly boots b
<hio_> hey, i don't understand snappy. does it replace the old ubuntu completely?
<hio_> will in the future all software on ubuntu be packaged as snappy?
<ogra_> no, it will be developed in parallel
<hio_> ok but in the future?
<ogra_> somce new variants will only be available as snappy though
<hio_> and i can have snappy installed on an old ubuntu?
<ogra_> snappy is a special installation variant ... a special package manager and essentially a lot more ... you cant just install it on a deb based ubuntu. no
<hio_> does snappy have a graphical desktop? can i use it as a desktop machine?
<ogra_> (snappy systems also dont have dpkg or apt )
<hio_> but i thought it was developed in parallel?
<ogra_> there will be snappy variants with graphical desktop, yes
<ogra_> mvo, all fine, get your MP in !
<hio_> so for example, if i use snappy on my server right now and i need a specific package for my code to compile, maybe there won't be a snappy version yet and it won't work?
 * ogra_ has done 5 update/rollback cycles now ... no more issues
<ogra_> hio_, for that there is a special tool in development that will bundle your deb packages for a project into a snap that you can install (or upload to the ubuntu store to provide it to others)
<ogra_> rsalveti, ^^ with mvo's MP all is fine here ... update/rollback between edge 129/1330 works fine for me
<ogra_> *130
<hio_> what relation does it have to docker? none?
<ogra_> you can use docker pretty easily with it
<ogra_> there is already a docker framework in the store you can use
<mvo> ogra_: \o/ thank you so much for the testing
<hio_> docker would be a mother layer on top of it ok, good
<hio_> another*
<ogra_> mvo, i still feel a bit uncomfortable that people going on to use the fatwrite stuff will get corruption
<mvo> now someone just needs to review :)
<ogra_> but i guess there is not much we can do
<rsalveti> ogra_: that's great
<hio_> ok how far long is the development? should i use it right now as my server ?
<rsalveti> yeah
<mvo> ogra_: we could auto-migrate them, but then there is really no rollback (automigrate via custom boot script)
<mvo> but thats very scary
<rsalveti> hio_: depends on what you want to run as your workload
<rsalveti> you can run docker containers or you can create services that could be provided by a snap
<hio_> a java webserver
<rsalveti> and push that in our store
<ogra_> mvo, well, and indeed super dangerous to dd to the disk ... if power fails that moment you are completely bricked
<hio_> i don't want to push things into the store, i might want my own store though
<hio_> can i create my own snappy repo?
<ogra_> no
<rsalveti> at least not yet
<ogra_> you can set up a push service that sideloads the snaps
<rsalveti> there is an idea of having private store
<ogra_> yeah
<ogra_> which is essentially just a sub-store of the official store then
<hio_> i don't want it to be online, its in my own LAN
<ogra_> right, then you can script something that pushes snaps via ssh
<rsalveti> then for now you could create the snap and just sideload it
<hio_> what exactly do you mean by "sideload"? i assume theres still just a simple cmdline so i can install my own snappy packages
<rsalveti> yeah, once you create it, you can install it locally or even remotely
<rsalveti> with snappy-remote
<hio_> ok good
<ogra_> there is either a commandline or a remote tool
<rsalveti> sideloaded means it's not coming from the store
<ogra_> right
<rsalveti> ogra_: will you take care of the reviews?
<ogra_> rsalveti, of go code ? ...
<rsalveti> ogra_: at least check if the logic is fine in there
<ogra_> i can do that but cant give any guarantees if what i say makes even sense
<rsalveti> let me take a look as well
<rsalveti> https://code.launchpad.net/~mvo/snappy/snappy-more-uboot-fiddling/+merge/265715
<rsalveti> right?
<ogra_> looks like
<ogra_> by the timestamp
<ogra_> bah, thats big
<ogra_> i'm not sure my judgement is helpful, it looks ok to me (and well, i just ran the binary and it worked :P )
<ogra_> approved
 * longsleep is leaving for the night - check out our kickstarter bringing a Spreed hardware device powered by Snappy: https://www.kickstarter.com/projects/spreed/spreedbox-the-most-private-video-chat-and-file-exc
<longsleep> (sorry for the spam) :)
<ogra_> longsleep, dude ... i have quite a bunch of G+ followers, you need to ppaste such a thing earlier !
<longsleep> well it just started - there are 29 days to go
<longsleep> any sharing would be very nice :)
<ogra_> yeah, no prob
<longsleep> cool thanks - see you tomorrow
<ogra_> director of bits and bytes ... heh
<ogra_> do you have that on your business card too ? :)
<longsleep> only the first part
<longsleep> no idea where that came from :P
<ogra_> heh
 * rsalveti waits mr to land before triggering a new image
<rsalveti> webdm failed to install: Get https://myapps.developer.ubuntu.com/site_media/appmedia/2015/04/ubuntu.png: EOF
<rsalveti> wat
<mvo> yay
 * mvo looks forward for the new image
<Chipaca> mvo: still needing that review?
<mvo> Chipaca: looks like rsalveti already did it, so all good :) tomorrow is enough
<mvo> and we almost have a new image
<rsalveti> yeah, image 131 is currently being imported
<rsalveti> then will migrate to alpha and test it a bit more
<mvo> yay
<rsalveti> and maybe, hopefully, we can release it tomorrow
<mvo> *fingerscrossed*
<rsalveti> image 131 seems to be out
 * ogra_ waits for 130 to tell him about the auto update :) 
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ snappy list -v|tail -1
<ogra_> Reboot to use the new ubuntu-core.
<ogra_> :D
<ogra_> auto updated ...
 * ogra_ reboots
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ snappy list -v
<ogra_> Name        Date       Version Developer
<ogra_> ubuntu-core 2015-07-23 131     ubuntu*
<ogra_> ubuntu-core 2015-07-23 130     ubuntu
<ogra_> :D
 * ogra_ tries a rollback
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ snappy list -v
<ogra_> Name        Date       Version Developer
<ogra_> ubuntu-core 2015-07-23 130     ubuntu*
<ogra_> ubuntu-core 2015-07-23 131     ubuntu
<ogra_> looks good
<ogra_> rsalveti, looks all good over here
<ogra_> rollback and update work, no corruption
<rsalveti> great, let me promote to alpha then
<ogra_> +1
<ogra_> rsalveti, oh, wait
<rsalveti> what now? :-)
<ogra_> didnt we want an amd64 only buuld first ?
<ogra_> *build
<rsalveti> already did that
<ogra_> oh, heh
<ogra_> well, then go for it ... the copy-image should still be in cdimages history
<rsalveti> alright, copied for armhf
<rsalveti> copying for amd64
<ogra_> yay
<rsalveti> done, image 8 is the latest edge
<rsalveti> now let me flash image 3 first :-)
<ogra_> dont try to roll back :P
<rsalveti> :-)
<ricmm> stop breaking everything guys
<ricmm> geez
<ogra_> ricmm, it was broken already
 * ogra_ blames microsoft ... for inventing vfat
<rsalveti> ogra_: crap, need to use 3 with the sideloaded oem snap
<ogra_> yeah
<rsalveti> do you have the link for that in hands?
<rsalveti> oh cloud-init
<ogra_> rsalveti, http://people.canonical.com/~mvo/tmp/beagleblack_1.8_all.snap
 * rsalveti kicks it
<rsalveti> thanks
<rsalveti> Signature verification failed
<rsalveti> ogra_: how to skip that?
<ogra_> --developer-mode
<rsalveti> haha, alright
<ogra_> :)
#snappy 2015-07-24
<tedg> jdstrand, By chance are you around? I'd like to get a snap approved in the store.
<tedg> (it's tiny)
<fgimenez> good morning
<davidcalle> Morning o/
<longsleep> good morning all
<longsleep> so - whats the state of images ? Can i fuse to 130 and then update to 131 and all should work?
<ogra_> yes
<olli> gm
<mvo> longsleep: see also my comment in #1477657, something fishy is going on with the delta generation right now
<ogra_> mvo, the same thing as always really ... and the reason why sergiusens switched to the versioned binary names
<ogra_> if the file didnt change system-image will simply not put it into the delta
<ogra_> also, the update seems to work fine despite the message
<mvo> ogra_: yeah, its not a regression, still anoying
<longsleep> ogra_: so the fix in the snappy tooling for rollback also fixed update?
 * longsleep tries that
<longsleep> 130 has the fixed tool right?
<ogra_> ah, no, you need to copy the snappy binary over to 130 i think
<ogra_> after upgrading to 131
<ogra_> at least if you want to do multiple back and forth rollback tests
<mvo> ogra_: fwiw, fake-upgrade worked for me, I got auto-upgraded and rollback also works, looks like we are good here
<longsleep> well the problem i had was that the update never touched uboot.env and thus automatic boot into the new system did not work
<ogra_> we definitely are
<mvo> and re-upgrade too (all using fake versions though)
<ogra_> ricardo already copied 131 to alpha
<longsleep> ah
<longsleep> let me try that - i am all busy with sharing the kickstarter campaign  ..
<ogra_> heh, looking good already
<longsleep> anyone who wants to help - please share https://www.kickstarter.com/projects/spreed/spreedbox-the-most-private-video-chat-and-file-exc to make a cool Snappy device
<ogra_> (but your goal is also easy to achieve ... would be surprising if you dont make it
<ogra_> )
<ogra_> did you send it to heise and golem.de ?
<longsleep> well i hope so because i want the device for myself :D
<longsleep> ogra_: i am not directly involved the the marketing
<longsleep> thankfully :)
<ogra_> and ?
<ogra_> :P
<longsleep> i leave that to others
<longsleep> just spamming you guys here
<ogra_> just report it as news via their reporting mail addresses :)
<longsleep> yeah i suppose i can do that thanks
<ogra_> if one of them picks it up you will have your goal in no time
<longsleep> true - i am pretty sure that my colleagues are on that already - but more helps more :P
<ogra_> yeah
<conyoo> longsleep, https://www.reddit.com/r/Ubuntu/comments/3efbx7/secure_and_private_video_conferencing_with_ubuntu/
<longsleep> conyoo: nice thanks !
<conyoo> np :P
 * longsleep just received a shipmempt of ODROID-XU4's (USB3 + Gigabit Ethernet, Oktacore Exynos ARM) yay!
<davidcalle> conyoo, this looks excellent!
<ogra_> davidcalle, spread it ... share it ;)
<mvo_> longsleep: you are not in this video or are you?
<ogra_> mvo_, he is at the bottom in the pics
<mvo_> olli: thanks for the bugreport (and sorry for the delay, got disconnected)
<Chipaca> mvo_: am looking at https://code.launchpad.net/~mvo/snappy/snappy-i18n-for-go-flags/+merge/264112
<Chipaca> mvo_: is there a reason for not iterating over options and setting each option description to i18n.G of the description after the parse?
<Chipaca> or even before, actually
<JamesTait> Good morning all; happy Friday, and happy Tequila Day! ð
<Chipaca> mvo_: ah, maybe the concern is that xgettext won't find the strings that way
<Chipaca> hmm
<mvo_> Chipaca: I'm not sure I understand the question, but yes, the string must be marked with something like i18n.G() so that it can be found
<mvo_> Chipaca: I think I understand the question now and yes, if the string is somehow marked this approach works fine
<Chipaca> mvo_: actually my main beef with this approach is that you're iterating over a list of things multiple times instead of doing a single pass
<Chipaca> mvo_: hmm :)
<mvo_> Chipaca: oh, I see, hmmmm
<Chipaca> ooooh! i see a bug :)
<mvo_> Chipaca: fwiw, I tried to get upstream to make this easier but he was of the opinion its fine with the iterations
<mvo_> Chipaca: meeeh, a BUG?
<Chipaca> a buggy bug
<Chipaca> btw, me thinks hw-(.*) should be hw $1
<Chipaca> but anyways
<mvo_> Chipaca: yes
 * mvo_ waits patiently for the buggy bug
<Chipaca> mvo_: line 422
<Chipaca> of the diff
<Chipaca> sorry, was reading the whole thing again to catch similar ones
<Chipaca> mvo_: can't find any other
<Chipaca> so, anyway
<mvo_> yay, nice catch on r422
<mvo_> l422
<Chipaca> mvo_: this way works; most things don't have that many options for it to be problematic
<Chipaca> mvo_: however, i was wondering
<Chipaca> mvo_: maybe we can arrange it so that each cmd either defines a per-cmd dict or adds to a global dict, and main.go does work?
<longsleep> mvo_: i am in the video
<longsleep> mvo_: at 1:40 or something
 * Chipaca gives it a poke
<mvo_> Chipaca: sounds like a good idea, I'm not super worried about the overhead of the iterations, but I like the elgance of it
 * mvo_ will ponder over lunch
<conyoo> longsleep, https://news.ycombinator.com/item?id=9940909
<Chipaca> mvo_: +1'ed your i18n flags branch; it needs a commit message though
<Chipaca> mvo_: ditto your atomic branch
<Chipaca> mvo_: and ditto your review tools branch
<Chipaca> elopio: can i note that i disagree with you needsfixing things over % vs format? the recommendation of format is not even strong enough for pep8, and many people disagree
<Chipaca> elopio: in particular, i think most of the time format only adds unreadableness for no benefit
<longsleep> conyoo|AW: great thanks again!
<Chipaca> elopio: also note i disagree in the -0 sense, not in the -1 sense
<Chipaca> i mean, i can wade through unreadable code, and have done so for a living, so i don't worry too much about it
<Chipaca> but Â¯\_(ã)_/Â¯
<Chipaca> mvo_: what cna i do to help clear up the review queue?
<Chipaca> it's massive
<mvo_> Chipaca: cleanup> is there more to do other than doing reviews :) ? iirc it was just that, iirc stuff was addressed its just a mater of approving or setting to needs-fixing etc
 * mvo_ sets commit message
<mvo_> s
<rsalveti> fgimenez: mvo_: ogra_: I'll do a bit more testing in a few, but alpha looks fine
<rsalveti> we need to make sure that we can do 6->7->6
<rsalveti> and that 3->7 can still work
<ogra_> rsalveti, how would 6-7-6 help if we only release 7 to the stable channel ?
<ogra_> or do you want to do two releases
<rsalveti> because with 6->7->6 we can confirm that the next stable image will update successfully
<ogra_> ah, k
<rsalveti> without fs corruption :-)
<fgimenez> rsalveti, ok i'll begin with 6->7->6, you mean amd64 right? this morning armhf tip was 8 iirc
<ogra_> since we dont migrate people we should actually encourage a re-flash
<rsalveti> hm, let me check
<ogra_> else they stay with the fatwrite forever
<rsalveti> fgimenez: ogra_: yeah, sorry, 7->8->7
<fgimenez> rsalveti, ok
<rsalveti> ogra_: right
<longsleep> from that i understood, when the oem snap is updated boot resources are not written right? Is there any propsed way to update u-boot and consorts without reflashing?
<ogra_> longsleep, yes, in rolling
<ogra_> (only proposed afaik, not implemented yet)
<fgimenez> Chipaca, thanks for the review! :)
<mvo_> yeah, Chipaca rocks
<zyga> hey, do you plan to support upgrades from dual partition to single partition layout?
<rsalveti> eventually, yes
<rsalveti> since that would be the layout used by the phone
<ogra_> first we have to have the single partition layout :P
<ogra_> we're not even at prototype stage with that :)
<mvo_> longsleep: thats correct, only u-d-f deals with the boot-assets for now
<mvo_> longsleep: we have no plan, no. some ideas, but its tricky as the potential for screwup is huge
<mvo_> longsleep: as ogra_ pointed out the other day, powerfailure during uboot flash and its a brick
<Chipaca> we can't just ship partitionmagic and let people sort it out?
<Chipaca> i probably have it on a 3.5" somewhere
 * ogra_ puts "floppy image" on his TODO
<zyga> Chipaca: and cyanide, once they give up ;)
<Chipaca> we could ship a script that just wrote 0s over everything, and call it partitionmagic
<Chipaca> when partitionmagic failed, we'd say "ah well, we tried; you'll have to reflash"
<Chipaca> \o/
 * Chipaca should get lunch before he does anything *actually* crazy
<longsleep> mvo_: yes - but that is the same as with all devices - i think it would be nice to have some means to flash only u-boot environment
<longsleep> i mean i do that all the time
<longsleep> (manually with dd)
<Chipaca> mvo_: I am suspicious of a branch that has two typos in the branch name alone
<Chipaca> mvo_: but other than that https://code.launchpad.net/~mvo/snappy/snapy-out-own-xgettext/+merge/263659 seems fine :)
<mvo_> longsleep: good point indeed, so something like "snappy reflash"? or similar (well, name sucks) but essentially a snappy command to reinstall the bootloader?
<mvo_> Chipaca: pff, typos
<Chipaca> mvo_: it's got a silly conflict, if you could fix that it's good to go i think
 * Chipaca still doing the *actual* review, but it looks good
<mvo_> Chipaca: my only concern with that branch is that its a big hammer for the `` but the alternatives seemd worse
<longsleep> mvo_: yes - with the oem snap as provided input
<mvo_> longsleep: I like that idea a lot
<Chipaca> it's a lovely bejewelled (glowing) (blessed) hammer of +2 i18nage
<mvo_> Chipaca: rotfl (and I don't use that term lightly!)
 * Chipaca helps mvo_ up
 * mvo_ fires up nethack to get a real hammer
<ogra_> you have been eaten by a grue
<longsleep> mvo_: a tool like that could even gain a brain over time and check what is actually on the disk to do more complex migrations.
<Chipaca> longsleep: i imagine that tool would come after the separation of the updater into its own thing
<tbr> and then /dev/zombie comes by and eats it
<Chipaca> longsleep: (so we can update the updater before updating the system)
<Chipaca> which makes me think snappy would come in a .snap
<Chipaca> which makes me think of the smalltalk type system
<longsleep> Chipaca: well - i would see this as two things. One is for offline updater - doing a update like a new flash but without loosing data
<longsleep> Chipaca: the other is on the system itself, making this possible without an extra PC
<mvo_> longsleep: yes, if you don't mind, file a bug and  I will add it to the trello board
<longsleep> mvo_: ok i can do that
<mvo_> longsleep: thanks!
<Chipaca> mvo_: https://code.launchpad.net/~mvo/snappy/snappy-atomic-write-once/+merge/264125 also needs deconflicting
<Chipaca> man, i let the review queue be too big for too long. sorry y'awl
<Chipaca> conflicts everywhere
<longsleep> mvo_: bug #1477950 added
<nothal> Bug #1477950: Add tool to write OEM snap boot-assets to existing media <Snappy:New> <http://launchpad.net/bugs/1477950>
<ubottu> bug 1477950 in Snappy "Add tool to write OEM snap boot-assets to existing media" [Undecided,New] https://launchpad.net/bugs/1477950
<fgimenez> rsalveti, i'm getting this when trying 7->8 http://paste.ubuntu.com/11929782/
<rsalveti> right, might be the issue we had that the kernel wasn't updated between such versions
<rsalveti> mvo_: ogra_: ^
<ogra_> thats harmless
<rsalveti> we need to fix that at the system-image side
<ogra_> yeah
<ogra_> but mainly cosmetic atm ... longsleep opened a bug for it yesterday
<longsleep> yes - the update should work. But i think the tool would show a messsage that one should reboot if that error would not happen.
<longsleep> similar to snappy list
<ogra_> right
<fgimenez> rsalveti, ogra_ longsleep yep http://paste.ubuntu.com/11929791/ rebooting now
<rsalveti> hm, why is the oem 1.8?
<longsleep> any chance that we can get a 132 edge 15.04 so i could test the upgrade path without replacing snappy tool in 130 ?
<rsalveti> you should only use oem 1.8 when testing from 3->8 (fallback might fail)
<rsalveti> and use latest oem when doing 7->8->7
<rsalveti> which is 1.11
<ogra_> yeah
<fgimenez> rsalveti, ah ok, first time i tried --oem beagleblack it booted into debian, i'll try again now
<rsalveti> fgimenez: oh, if you got debian installed you also need to remove your current bootloader
<rsalveti> fgimenez: or just unplug and plug power again with the boot switch pressed
<fgimenez> rsalveti, ok
<ogra_> nah
<ogra_> S2 should be enough ...
<ogra_> you need to make it boot once from the SD and it will keep usign that
<ogra_> (by holding the S2 button i mean)
<rsalveti> right
<rsalveti> or
<rsalveti> sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1024 count=1024
<ogra_> yeah, but then you have no fallback if you want to debug on the board
<rsalveti> well, we want to make sure people are always booting with our bootloader
<rsalveti> otherwise we might have all sorts of issues
 * ogra_ finds it pretty conveninet to be able to boot itno debian and mount the Sd partitions to check stuff
<ogra_> right, indeed thats more for debugging
<jdstrand> tedg: I'm here now
<Chipaca> mvo_: what should service status output when no service is found?
<tedg> jdstrand, Can you approve this app? It should be pretty straight forward, but I think you're the only one doing snaps today. https://myapps.developer.ubuntu.com/dev/click-apps/3195/
<longsleep> mvo_: can i somehow force snappy update to fetch a specific version? I am currently on 131 and would like to update the other partition to 131 as well
<mterry> elopio, why is format ({}) considered better than % in python strings?
<mvo_> Chipaca: a good question, maybe simply nothing if there are none and the user did not specificy a search?
<Chipaca> sounds fair
<Chipaca> mvo_: and if the search is via webdm?
<Chipaca> that is: is this a special case for the commandline only, or should i expose it to webdm too?
<mvo_> longsleep: you can do that in u-d-f, after its installed you can manually edit /etc/system-image/channel.ini and /etc/writable/cache/etc/system-image/channel.ini
<mvo_> Chipaca: I would say just return a empty list and no error?
<mvo_> Chipaca: unless there is a good reason for something else of course
<Chipaca> mvo_: nope, that sounds sane to me
<mvo_> cool
<jdstrand> tedg: ok, approved. You can of course fix the 'lint_description' warning easily enough. however I wonder why you are targetting amd64 if there are no binaries?
<tedg> jdstrand, Because it seems that docker can only have one architecture per symbolic name. So that'll have to pull the amd64 image, and then I'll have to have a different name for arm, arm64, etc.
<tedg> jdstrand, At some point I can probably script that, but I'm not there yet :-)
<longsleep> mvo_: in u-d-f .. but my system is already installed and running. I would just want to a 'force update other to latest no matter what i have booted'
<kickinz1> ted, you can look at owncloud package, it checks the arch, then pull the  corresponding image from registry.
<longsleep> ogra_: what was the name of the tool again which creates snaps from deb files?
<ogra_> there is deb2snap and there is snapcraft
 * longsleep remembers that he wanted to look at that
<longsleep> a snapcraft that was it
<longsleep> thanks
<longsleep> i guess http://www.snapcraft.net/ is not it :D
<elopio> good morning.
<longsleep> ok - ppa https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily is good to experiment with snapcraft?
<zyga> hey
<elopio> mterry: it has more features, some consider it cleaner (and I agree), and it's the new standard so all py3 should use it.
<elopio> I find it cleaner specially because the strings tend to grow. You start with one argument, and it's common to end up with a string that has four arguments.
<mterry> elopio, fair enough, just saw your link to the python2 docs about it
<mterry> elopio, and it is nicer when you reuse the same argument.  Can just do {0}, {0} twice
<elopio> also I find it nice to use things like !r to format the value. There are some things to format decimals and stuff, but I haven't used them yet.
<zyga> mterry: format is also better on tuples where % may misbehave if you don't do it carefully enough
<mterry> fair
<elopio> mterry: even "{nicely_named_arg1}, {nicely_named_arg1}".format(nicely_named_arg1='value')
<mterry> elopio, so verbose!  :)
<rsalveti> longsleep: check https://code.launchpad.net/~mvo/snapcraft/docs-1/+merge/265770 as well
<rsalveti> we're still working on getting it in a proper shape for release
<elopio> mterry: yes indeed. Oh I like python very much.
<elopio> I find it hard to switch from python to go, where everything uses short terms. On python I usually name a var index instead of i :)
<elopio> that's so much better for reading code with my bad english.
<mterry> elopio, beware carpal tunnel, man!
<elopio> mterry: I have a shiny kinesis keyboard. He takes care of me and I of him.
<longsleep> rsalveti: ok great - that looks promising thanks
<elopio> Chipaca: noted your disagreement.
<elopio> as it's -0, I prefer to go with the docs suggestion.
<elopio> fgimenez: hey, I didn't notice that we can now start throwing tarmac integration runs to an ip in canonistack.
<elopio> we just have to set it up with autoupdates and autoreboots.
<elopio> they will fail of course, but they will fail with real regressions.
<fgimenez> elopio, you mean having a running instance there always up, right?
<elopio> fgimenez: yup. While we are ready with our throwable instances.
<rsalveti> elopio: mterry: seems the amd64 build of snapcraft is failing https://launchpadlibrarian.net/212453342/buildlog_ubuntu-vivid-amd64.snapcraft_0-0~105~ubuntu15.04.1_BUILDING.txt.gz
<rsalveti> when running the tests
<mterry> humph
<mterry> will look
<fgimenez> elopio, yes, sounds good :)
<elopio> mterry: rsalveti: Please, set your name with the 'whoami' command.
<elopio> not sure how to solve that. I did it manually on tarmac.
<elopio> I guess we can have a setup command on the plainbox tests?
<mterry> elopio, whoami in what context?  irc?
<elopio> mterry: no, bzr whoami.
<mterry> elopio, that is set for me
<elopio> needed for the bzr commit that it's done in a couple of plainbox tests.
<elopio> mterry: well, yes, on your machine you have it set for sure. But on the builders it's not.
<mterry> elopio, I see what you're saying
<mterry> elopio, stupid bzr shouldn't error out for that
<elopio> or we could just put bzr whoami on the two tests, before bzr commit.
<mterry> but i understand why it does
<mterry> elopio, yeah easiest is just a quick dumb whoami in the tests
<mterry> that way we don't rely on environment being configured right
<elopio> mterry: sure. Will you do it or should I?
<mterry> elopio, i will
<elopio> tx
<longsleep> mvo_: does the tutorial for snapcraft exist in some stage more than the stub in https://code.launchpad.net/~mvo/snapcraft/docs-1/+merge/265770 :D
<mvo_> longsleep: mterry will correct me if I'm wrong, but I think thats abot it right now, we are busy working on it thouhg and hope to have something more RSN
<ogra_> not yet :)
<longsleep> ah just found the examples in the repository - i guess i will get it with those
<longsleep> (Spreed WebRTC is a go server after all)
<longsleep> mvo_: where does the software for the plugins come from?
<mvo_> longsleep: it can be various sources, launchpad, github, the archive, local
<longsleep> mvo_: for example http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/plugins/go1.4.yaml - where does go1.4 come from / how does it know where to find it?
<elopio> longsleep: are you working on spreedbox? that's nice!
<longsleep> elopio: yeah i am
<longsleep> mvo_: ok found it - it downloads it from https://storage.googleapis.com/golang/go1.4.2.linux-amd64.tar.gz
<longsleep> mvo_: i am not sure if i like that - means builds cannot be automated if the build environment has no internet
<longsleep> mvo_: i think snapcraft plugins should come from normal deb packages
<longsleep> mvo_: or rather the third party gear
<ogra_> longsleep, why ? you could use a pluin (or wrtite one) that only uses debs ... and provide a local mirror
<mvo_> longsleep: well, its one way of doing it, there are more, you could have a go1.4 plugin that takes it from you local system for example
<ogra_> *plugin
<longsleep> ah true - i can just provide my own plugins as python modules
<mvo_> longsleep: snapcraft mandates no policy here, its fine to write plugins that use debs of course
<longsleep> got it
<mvo_> longsleep: and even plan to make it really easy to share them via some repository, so that other people benefit from your work
<ogra_> well it mandates a policy ... somehow ... "Go Wild !!"
<mvo_> haha, ok, it does
 * longsleep likes 'wild' a lot
<longsleep> ok i will be making a spreed-webrtc snap with snappcraft next week then - will let you know how it goes and probably ask stupid questions
<elopio> fgimenez: well, only detail is that snappy rolling edge is still not booting on canonistack
<Chipaca> elopio: not booting, or not getting network?
<elopio> Chipaca: hard to tell as I have no way to know what's happening.
<elopio> it doesn't leave a log.
<Chipaca> elopio: i haven't used canonistack; can't you reset an instance? like, hard reboot it?
<Chipaca> elopio: or, better, can't you connect to a serial console of an instance?
<ogra_> or even mount the writable partition ?
<ogra_> from the outside
<elopio> Chipaca: I can hard reboot. That's in progress.
<longsleep> other questions folks: how can i install snaps which are not in the store / say i have them as a .snap file
<Chipaca> or that, although i can't imagine building an api for that :)
<elopio> I think the log is what comes from the serial console, maybe? don't really know.
<Chipaca> elopio: so, if you let it boot the first time (give it plenty of time), then hard reboot it, it should come up with network the second time
<Chipaca> elopio: if everything is alright :)
<elopio> ok, /me waits for it.
 * longsleep just discovered that snappy install somefile.snap seems to work
<Chipaca> there's an abundance of wishful thinking in that, but maybe :)
<Chipaca> longsleep: what do you mean?
<elopio> I think there's something else wrong, because the log of my other instances appear before the network is up. But lets see.
<longsleep> Chipaca: when i built a snap for some software, how do i install it without the store
<longsleep> Chipaca: just install from file ?
<Chipaca> longsleep: yes
<Chipaca> longsleep: it's called sideloading (your package will have origin: sideload)
<longsleep> Chipaca: ok thats simple enough then
<longsleep> Chipaca: all right - can i sideload during image creation in u-d-f as well?
<ogra_> yeap
<ogra_> use the --install option
<longsleep> ok - so just ignore it is in the "Deprecated" section?
<lool> elopio: funny that you bring this up, the integration tests fail if git config isn't set
<lool> longsleep: heya
<lool> longsleep: I'm sorry we didn't manage to finish our exchange
<elopio> lool: I didn't see that error, but I suppose it would be the same, yes.
<lool> longsleep: I see you've submitted a snap though  :-)  how did you end up approaching this?
<longsleep> lool: no worries i had plenty of distraction here thanks
<Chipaca> longsleep: where in "deprecated"? i see it under "development" here
<lool> elopio: it was failing to me due to EMAIL/GIT_COMMITER_NAME etc. not being set in the test of snapcraft pull
<longsleep> lool: the snap i submitted - you mean the ODROID oem snap? I just built it - that was quite simple. I published all the gear at https://github.com/longsleep/snappy-odroidc - might be helpful for other devices as well.
<lool> longsleep: oh I thought you had submitted a spreed snap
<longsleep> lool: no - not yet
<longsleep> lool: i did build one though - but that was just hacking around
<ogra_> lool, we're keeping him busy with re-designing the uboot process
<longsleep> yeah - but it turned out to be harder for you than it was for me i guess :)
<lool> longsleep: ah there's a dummy spreed snap up for review, lol; I think it's just an empty one though
<longsleep> lool: Who submitted that ?
<longsleep> not me
<lool> ogra_: eh, where's that happening?
<ogra_> lool, in 15.04
<lool> longsleep: no, mectors, I think it's something he threw together for iotworld, but I dont think he had time to touch it since
<longsleep> lool: yes thats too - he sent me the details
<ogra_> lool, we moved away from txt files and fatwrite to using a binary blob environment file and put everything into variables
<longsleep> lool: i will try snappcraft first and see how it goes and then submit one next week
<longsleep> either with snapcraft or manually crafted
<lool> mterry: heya
<longsleep> lool: do you have some time to discuss the entropy issue?
<lool> longsleep: snapcraft is comign really well; it's already able to deliver quite complex combinations
<lool> longsleep: yes, with pleasure
<mterry> elopio, rsalveti: sorry!  my cafe internet expired.  I'm back in my host's apt (I'm in NYC briefly) with wifi.  trunk's use of whoami is fixed
<mterry> lool, hi
<lool> longsleep: TBH, I'm sleep deprived so my brain is quite in slow motion, but that kind of forces me to focus on one thing at a time like IRC or email
<lool> mterry: would love to discuss some snapcraft bits when you have some time
<longsleep> lool: ok great thanks - summary first - whenever a snappy device boots up first time it creates some stuff which requires entropy. On embedded devices there is essentially no entropy from standard kernel
<mterry> lool, sure
<longsleep> lool: means any key created on first boot is weak as it was created without entropy.
<lool> longsleep: so what surprizes me is that this must be a common problem; how is this typically solved in other embedded systems?
<longsleep> lool: it is a common problem yes - with embedded systems and with cloud systems as well
<longsleep> lool: in embedded systems this is solved by having a HWRNG on chip which which feeds entropy into the kernel
<elopio> mterry: lool mentioned we need to configure git too. "EMAIL/GIT_COMMITER_NAME etc. not being set in the test of snapcraft pull"
<longsleep> lool: for this to work, ususally a system service is run (eg rngd or haveged)
<mterry> elopio, lool: that doesn't seem to break the tests.  is that just for correctness?
<lool> mterry: so on the top of my mind: wanted to confirm the 2 branches I had submitted are now ready for review; I brought up the jre vs jdk thing in a bug report (and using host vs target deps/java runtime during build); then there are a couple of paper cuts I've hit; lastly, I have some feedback on the new copy/tarball plugins
<longsleep> lool: for cloud stuff you folks at canonical implemented a rather scary entropy service providing random data over the network (managed by cloud-init)
<lool> mterry: it broke the tests for me yesterday
<lool> mterry: on a clean vm with no git config
<mterry> lool, I saw your branches go by.  I can start reviewing them, but did you want to talk about something outside the branches?
<lool> mterry: I had to set the usual env vars (or I could have set git-config) for the tests to pass
<lool> mterry: this broke snapcraft pull on top with the git commit -m 1, -m 2 etc. test
<lool> mterry: topics I've listed above
<lool> mterry: in no particular order
<mterry> lool, ok...  our buildd managed, but I guess it's a fragile thing
<longsleep> lool: so to handle the problem, two things need to happen. Services which need entropy need to first start until there is sufficient entropy. On embeddded devices this usually means that rngd has been started. Only after, any private keys can be created.
<longsleep> lool: or host keys for SSHD for that matter
<tedg> I'm trying to install from the store and I'm getting "snappy package not found"
<tedg> It shows up in "snappy list" thoughâ¦
<mterry> lool, right, but the topics you listed above seem like they are  a list of the branches you submitted.  I can look at them, but I haven't yet, so I may not have the context for the discussion that you want
<tedg> Sorry snappy search
<lool> longsleep: I'm scared by the entropy service in the cloud too; surprized there is no support from vm providers for this
<lool> longsleep: the hardware generators feels like the msot natural
<lool> longsleep: why does this need a daemon rather than the kernel just using it?
<longsleep> lool: because there can be many sources for random data, and having them all in kernel space would be complicated
<longsleep> lool: thus it is in user space
<lool> longsleep: I remember a long debate upstream about using the Intel hw rng from Intel CPUs (and how the NSA could potentially use this), so seems it's already the case on x86?
<longsleep> lool: see http://linux.die.net/man/8/rngd
<lool> longsleep: makes sense
<longsleep> lool: yes, the kernel uses some hardware rngs directly
<lool> longsleep: so this seems like a rather core thing that should be there on all linuxes; how come we dont include it?
<lool> mterry: the last topic was some feedback on tarball/copy plugins
<lool> mterry: and the jre/jdk one is one which might need discussion
<longsleep> lool: well - first of all most people do not care. Second, most PC's do not have a extra RNG hardware
<longsleep> lool: there are USB dongles and such for it though
<lool> mterry: otherwise, yes, the rest was just a heads up on branches I've pushed
<mterry> lool, (I was off yesterday and will be off half today, so I've not had much time to review)
<lool> longsleep: so on PCs, we use the CPU provided one, and on embedded systems there's often one and we just need rngd to use it
<mterry> lool, lay your tarball/copy feedback on me  :)
<lool> mterry: that's fine; it's just a FYI because I've pushed a number of times to the branches and I wanted to clarify I was done for now
<mterry> lool, cool, ACK
<longsleep> lool: essentially yes - though it might also not be wise to always use one as some of them are really bad quality as well
<lool> mterry: so the copy stuff is too minimal and I find it's clumsy to list the filenames directly as yaml keys
<longsleep> lool: it should be a decision of the OEM provider how random is best created for this particular hardware
<lool> mterry: I wanted to copy a dir over and couldn't, I wanted to do a shell glob and couldn't
<mterry> lool, you should be able to copy a dir over.... that's intended and (I thought) tested
<lool> didn't work for me, I think it's not a cp -r
<longsleep> lool: i mean it is easy to provide a rngd snap, but the problem is that whatever first start stuff is done in snaps needs to rely on it
<mterry> lool, ok...  we could add a shell glob easily enough...  you lose the ability to specify the destination easily.  Unless it's a directory I guess
<lool>             res &= self.run(["cp", "--preserve=all", src, dst], cwd=os.getcwd())
<lool> that wont cp -r
<mterry> lool, yup agreed.  It was intended to do a directory.  That got lost in the shuffle I guess
<lool> longsleep: is rngd covering 98% of the use cases?
<longsleep> lool: for example in the Spreedbox, we have 3 sources for entropy - SOC rng in the ARM chip, Linux Kernel interrupts and our own custom TRNG device. They all feed entropy in the kernel and only when there is say at least 300 bytes entropy any key can be created
<longsleep> lool: yes - but only after it is started
<longsleep> lool: trick is to not create anything before it is started
<lool> longsleep: are all rngd providers upstream, or would one also need to configure/add providers?
<lool> longsleep: is it just enabling a list or also configuring each differently
<lool> longsleep: sounds like a typical boot job
<longsleep> lool: one will want to add own ones - the device names are diffent, they could be connected by SPI, USB, on chip
<lool> mterry: the tarball plugin, I wish we'd have a way to unpack to a subdir
<lool> basically naming the toplevel now that we automatically strip it
<mterry> lool, first you want to strip, now you don't!  ;)
<lool> mterry: and then, I've got bitten again with the "post-processing" use case
<lool> mterry: eh
<lool> mterry: well, having apache-tomcat-8.4.0/* was bad, but having LICENSE, README etc. all spread around is also bad
<mterry> lool, I understand, I was just poking fun  :)
<lool> mterry: I guess ultimately we want some include/exclude between steps, but a dest dir is fine for now; it doesn't seem complex
<ogra_> mterry, stop implanting distrubing pics in my brain !
<lool> mterry: I kind of suspected you were  :-)
<longsleep> lool: on the odroidc the SOC device is called /dev/hwrng - the Ubuntu packge for rng-tools has some auto detection
<mterry> ogra_, poking fun?
<ogra_> mterry, lool stripping
<mterry> ogra_, haha
<lool> longsleep: so I think the proper course of action is to propose this by default on Ubuntu
<lool> perhaps only on some architectures
<longsleep> lool: see http://paste.ubuntu.com/11930609/ for some examples
<lool> it might have a consequence on boot time, and it needs a security review to go in main
<lool> longsleep: but generally, it sounds like a piece of boot we are missing and which is quite important on some platforms
<mterry> lool, yeah a prefix dir seems reasonable (it has been floated as a general thing for any given plugin, but such discussions are ongoing).  Doens't hurt to add it to a case like the tar_content plugin that needs it most
<lool> like setting the clock frmo hwclck
<Chipaca> mvo_: pushed fixes to service
<lool> mterry: post-processing: I mean that I wanted to fix files around (permissions, remove some, replace some, patch some) and couldn't because: a) there's no hook b) if you're a part Y after part X, it's not particularly easy to access part X c) when merging from multiple parts, file conflicts are explicitly prevented
<lool> mterry: I dont know if hooks are the right answer, I dont like code mixed with the mostly declarative nature of snapcraft, so perhaps solving b) or allowing for c) would help enough
<longsleep> lool: well - the Linux kernel is supposed to handle it. Newer linux kernels are supposed to set urandom blocking (similar to OpenBSD) until there is entropy. So the problem on some kernels is not so critical. Though, most ARM stuff from China runs on Kernel 3.10 which does no such thing.
<lool> also, the various tarball/copy options we've discussed would make things less painful
<mterry> lool, I'll make your nits into bugs so they don't get lost
<mterry> lool, post-processing is a whole thing though
<lool> longsleep: oh I didn't know urandom became blocking
<lool> I thought the main point over dev/random was to NOT be blocking  :-)
<lool> I see where this is going though
<lool> mterry: yup; sorry this is a bit unstructured, I wanted to share this while it's "fresh" in my mind if "fresh" can describe my current brain status
<mterry> lool, :)
<longsleep> lool: so for now i am looking for ways to include rngd in my image. Though i can do nothing about the weak SSH keys which get created on first boot
<lool> longsleep: so this feels like a mature and simple daemon; I think we should consider it for Ubuntu boot sequence short term with a design on how sshd etc. would wait for that before generating keys; the longer term fix might be a systemd implementation, with slighlty more magic (e.g plugging an USB hw rng automatically adds it to the pool and such)
<longsleep> lool: yeah sounds a good idea for all ARM based platforms if you ask me.
<lool> longsleep: so I can't think of a fancy hook that could use; I can think of relatively heavy hacks
<longsleep> hehe too bad
<longsleep> well i am going to build my own rootfs - so i can even add more heavy hacks
<lool> longsleep: what would seem the cleanest way would be to proof of concept this into the rootfs; either remounting yours rw, or building one from scratch; the heavy workaround would be to disable system services you dont want such as SSH and provide them yourself, but only after you've started your own copy of hw rng
<longsleep> lool: well what would i give if snappy was using upstart :D
<ogra_> +1
<lool> haha
<lool> I loved upstart
<longsleep> me too
<ogra_> we wont get rid of it :)
<longsleep> well we have all the gear for that random stuff for upstart
<lool> oh really
 * ogra_ herad there are no plans to move the unity8 sessions over to systemd 
<lool> ok, I need to break away
<longsleep> lool: yeah - a fistboot service which blocks
<lool> I'm dead anyway
<lool> longsleep: so I think next step is to engage in Ubuntu (and/or Debian!) discussions on enabling this on systemd systems and important services in the short term, and engaging with systemd upstream on a proper design
<longsleep> lool: yes - i am still in the process on understanding the systemd boot and how it gets built into snappy rootfs
<longsleep> lool: hacky but works just fine: http://paste.ubuntu.com/11930663/
<ogra_> how do you mean "how it gets built into snappy rootfs"
 * longsleep needs something similar for snappy
<ogra_> we install debs in a chroot and then tar that up
<longsleep> ogra_: yeah - and the device tree what happens with it?
<ogra_> separate
<longsleep> i mean i guess i could just use our current rootfs builder to build the rootfs - just need to make it to work with snappy
<lool> longsleep: so I find it weird that you read a load of entropy; if it's to make sure that it's coming from rngd, why not read it after it started?
<ogra_> for the supported arches we simply install the kernel deb into the chroot after the rootfs tarball was created ... and pick the bits out of the chroot into a device tarball
<longsleep> lool: well yeah - this is just to make sure to get rid of any possible bad entropy
<ogra_> but that has nothoing to do with systemd
<longsleep> bad means not so random
<lool> longsleep: right, so perhaps do that after starting the daemon
<longsleep> lool: yeah true - i guess it would be better that way
<lool> first, this has less chances of blocking, second, you wont have more bad entropy created between the time where you read it and the daemon being ready
<longsleep> lool: correct
<longsleep> lool: let me change that in the repo :)
<longsleep> lool: but i think i made my points clear, cloud-init and such would have to run after entropy is available.
<longsleep> lool: we wait for 200 bytes - which is quite a lot
<longsleep> check your devices: cat /proc/sys/kernel/random/entropy_avail
<lool> longsleep: I suspect this will have to be benchmarked by cloud folks working on the images for various cloud providers
<longsleep> probably fine right now (but check then on boot)
<lool> longsleep: (one other thing they care about is boot time)
<ogra_> lool, lol
<lool> sometimes, it's acceptable to have less security for not too valuable VMs or if the networking environment is closed
<ogra_> lool, so they developed cloud-init to make the boot time more interesting ?
<longsleep> lool: well yes - i think cloud-init is beyond repair and snappy should just drop it and implement the three four things instead
<ogra_> longsleep, +1
<longsleep> lool: also for cloud images, you have the entropy service - so it should be quick and rngd would make no sense
<lool> ogra_: I suspect that demos where one creates 2000 containers or vms will get impacted if we add something which might block for a random number of seconds/minutes
<lool> say, this cloud provider has a broken this or that rng implementation and it blocks his boot, we'll be in hot water
<ogra_> lool, seriously, clud-init reliably adds 30-50 seconds to our boot process
<ogra_> not sure where the speedup should be here
<lool> ogra_: I dont understand the argument you're making
<lool> it's ok to slow down the boot because they've slowed it down already?
<longsleep> lool: yeah - true though i think most cloud providers pre seed their images with a seed file. So the kernel has entropy instantly.
<lool> I'm not worried about a small impact on the boot, but more of a random boot delay in some configurations
<lool> longsleep: wow, you've had some strong words against cloud-init
<ogra_> lool, no, i'm sayin lets speed up the boot by getting rid of cloud-init ... i simpÃ¼ly found your argument funny that cloud people care about bootspeed while we are constantly suffering from cloud-init doing exactly the opposite for us
<ogra_> (not to mention that we have distro tolls for everything cloud-init does and could simply use them)
<ogra_> *tools
<longsleep> yeah it does a lot of things where only few will be used together - i guess it is valid for automatic deployments in clouds but i fail to see the need on embedded devices
<longsleep> especially now that cloud init is the reason to ship python2 and python3
<longsleep> (as far as i see)
<ogra_> yes, that too
<ogra_> my biggest concern is that it is a reinvention of existing distro tools that wokrs a lot slower and adds extra pain where we could use saner methods to achieve the same
<longsleep> i just say leave cloud init to clouds and do not use it in embedded devices :)
<ogra_> if the cloud peaople actually need images from us i would rather build an ubuntu-core-cloud rootfs then to have cloud-init everywhere
<ogra_> (and no, i dont belive that rewriting it in go is better than using distro ways for the bits we need)
<lool> longsleep, ogra_: FYI, there's a cloud-init rewrite underway but it's still young https://github.com/stackforge/cloud-init
<ogra_> lool, yes :/
<ogra_> not what i'm aiming for
 * ogra_ wants it gone 
<longsleep> if i really have to build own rootfs i guess it will not include cloud-init if i can make it work without it
<longsleep> ogra_: btw - i have other challenges on boot as well, i need to set certain sysctl stuff - some can be set late, but others need to be set during initrd - any idea how i could do that from the oem or device parts?
<ogra_> not really, except for hacking the initrd ... which i wouldnt do
<longsleep> ogra_: i am doing that already :D
<ogra_> (will be a pain to keep in sync)
<ogra_> and i want us to get to a generic initrd that nobody needs to change
<ogra_> (like we use on the phone)
<longsleep> ogra_: currently i am only removing lib/modules and lib/firmware from the initrd i extracted from the preinstalled tarball
<ogra_> (sergio was working on that before he went on paternity leave)
<longsleep> so i gess that is minimal
<ogra_> yeah, and the generic one would have that inside
<ogra_> *would not
<longsleep> that would be ok, but i still have to add some scripts to init-top and init-bottom phases - how do you feel about that?
<longsleep> i guess the other kernel settings could be made by a snap on boot (preferably the oem snap)
<longsleep> can the oem snap provide services?
<ogra_> why do you need them that early ?
<longsleep> ogra_: because DHCP might fail otherwise
<ogra_> uh ?
<ogra_> then we need to fix DHCP on the rootfs
<longsleep> yeah .. some chip issues with certain switches
<longsleep> no its a kernel driver thing
<longsleep> the DHCP client is not responsible
<ogra_> hmm
<longsleep> has todo with the interrupts which get used by default for the NIC
<elopio> fgimenez: did you hit this one? https://bugs.launchpad.net/snappy/+bug/1477657
<ubottu> Launchpad bug 1477657 in Snappy "Snappy update fails because of its looking for non existing /writable/cache/assets/vmlinuz" [Critical,Confirmed]
<ogra_> so my idea is the following: http://paste.ubuntu.com/11930798/ ... theoretically you could also have an img file alongside that provides top or bottom scripts for the initrd to be loop mounted on demand
<elopio> fgimenez: I'm seeing that message.
<fgimenez> elopio, i've seen that this morning but it was updating anyway
<longsleep> ogra_: sounds reasonable - though for me no modules are required in initrd
<fgimenez> elopio, my current problem is that it refuses to boot in b...
<longsleep> (i am not adding any modules or firmware)
<elopio> fgimenez: well, but I would think that this bug leaves a corrupted b.
<mterry> elopio, why in your format_strings1 branch, do you take setup_dirs() outside of the common test case class?
<longsleep> ogra_: why would you put the system-a/b into squashfs images as well?
<ogra_> longsleep, sure, but thats the generic bit ... i dont want to have porters to touch the initrd at all
<ogra_> longsleep, saving space and being able to ship everything readonly on one partition
<elopio> mterry: because not all tests need it. And when it is run, it will change the environment, so it needs a cleanup.
<ogra_> actually it shoudl rather look like http://paste.ubuntu.com/11930813/
<longsleep> ogra_: mhm ok - for this to work a general hook would be required so people can do things in initrd.
<mterry> elopio, sure...  so you could do addCleanup eh?  I get about not all tests needing it.
<elopio> mterry: so far there seems to be only one test needing it, so I put it there. If we need it in more places, we can make a specific test case for it
<ogra_> longsleep, as i said... there could be init-top.img and init-bottom-img
<ogra_> longsleep, so you would put your scripts inside and initrd would loop mount them in the respective script dirs
<mterry> elopio, you also put a blank line before 'import yaml', I think under the belief that it's a local import?  But it's not
<longsleep> ogra_: oh yeah got it - that would be nice
<ogra_> that way you can provide your own script without having to mangle the default initrd
<fgimenez> elopio, according to ogra_ and longsleep the update should work regardless of the error message, it's a cosmetic problem atm
<ogra_> fgimenez, right, it suppresses the reboot message though
<elopio> mterry: it's third party. From pep8, you should put the std python imports, a newline, the third party imports, a new line and then the local imports.
<mterry> elopio, if the pep8 tool doesn't care, I have a hard time caring.  ;)  But sure, OK.  I get it
<elopio> I should provide pep8-as-a-manual-service and make tons of money out of it.
<mterry> elopio, or just fix the pep8 tool to catch this stuff  :)
<mterry> (does it have a --pedantic mode?)
<jdstrand> tyhicks: this is kinda annoying:
<jdstrand> Jul 24 15:50:35 localhost kernel: [  261.778262] audit: type=1326 audit(1437753035.869:23): auid=1000 uid=1000 gid=1000 ses=1 pid=1016 comm="ls" exe="/bin/ls" sig=31 arch=c000003e syscall=41(socket) compat=0 ip=0x7f19462c40b7 code=0x0
<elopio> mterry: https://github.com/PyCQA/pep8/issues/329
<elopio> let's call it a --super-correct mode :)
<jdstrand> tyhicks: I used 'ls -l <something>' in an app that didn't have 'network-client/networking' and got a socket() denial
<jdstrand> seccomp arg parsing is getting to be more of a priority I think
<mterry> elopio, in CommonTestCase.test_set_plugin, shouldn't you have an addCleanup?
<tyhicks> probably so
<tyhicks> I can't imagine why that would require a call to socket()
<tyhicks> but it doesn't matter much
<jdstrand> netlink?
<tyhicks> possibly
<jdstrand> yeah, I wasn't going to spend time looking at it. just mentioning that it is annoying
<elopio> mterry: yes, I think I should have.
<tyhicks> jdstrand: I agree that arg parsing is going to important soon
<elopio> mterry: maybe, move that cleanup to the base TestCase ?
<elopio> so it's always cleaned up even if it wasn't changed.
<mterry> elopio, sure
<mterry> elopio, it's going to look weird without the corresponding setup_dirs call, so maybe add a comment explaining why we don't do that call
<elopio> ok.
<elopio> mterry: I dislike this global var in the module. But I couldn't think of an alternative.
<mterry> elopio, yeah the core of this code grew out of a prototype so some code barriers are a little loose
<ash_charles> Hello.  I'm running into a bug with ubuntu-device-flash (https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1464054)
<ubottu> Launchpad bug 1464054 in goget-ubuntu-touch (Ubuntu) "Fails to create a snappy image when using --install" [Undecided,Confirmed]
<elopio> mterry: could we try to use plugins from the local dir, and if not found, go to /usr/share ?
<ash_charles> it looks like the bug has been fixed but I'm looking for a debian package for this code that includes the fix
<ash_charles> any way to track down such a package?
<mterry> elopio, you mean always look at ../../share/snapcraft/plugins?  (where ../../ is relative path from wherever the python module for snapcraft is -- do we always know the install layout?)
<mterry> whoops
<mterry> I mean always look at ../../plugins
<mterry> (that's the one for the bzr dir
<jdstrand> tyhicks: erf, same with the 'id' command
<ogra_> ash_charles, https://launchpad.net/~snappy-dev/+archive/ubuntu/tools-proposed
<mterry> elopio, ^  feels odd to go looking at what would be /usr/lib/python3/plugins
<ogra_> (note that there might land things that had zero QA though
<ogra_> )
<elopio> mterry: yes. Always try. Like putting on get_plugindir:
<elopio> if os.path.exists(os.path.join(topdir, "setup.py")):
<elopio>    ../../plugins
<elopio> else:
<elopio>    /usr/hsare
<ash_charles> ogra_: thanks---I'll give this a whirl
<mterry> elopio, I suppose...  and then we can unit test that by mocking os.path.exists I guess
<elopio> mterry: yes, I still find it weird. But I think I like better to delay the check, instead of having to run a previous setup_dirs step.
<elopio> mterry: why don't we put the local plugins in ~/something, like bzr ?
<mterry> elopio, ...  those aren't local plugins
<mterry> elopio, that check is testing whether we're running from a bzr checkout or not
<elopio> oh, right.
<elopio> there was something in pkg_resources that I think we used once...
<longsleep> ogra_: there is another tool i would like to see on snappy by default: http://linux.die.net/man/8/fbset - any thoughts on that?
<elopio> It was like we could use pkg_resources to find stuff, either installed or relative to the module. I don't really remember.
<fgimenez> have a nice weekend  o/
<elopio> any way, this is weird. I think we can find a better way to handle it.
<ogra_> longsleep, hmm, not really for embedded ... that soounds like something for snappy-personal
<longsleep> ogra_: how do you control the framefuffer for bbb or rpi2 ?
<davmor2> ogra_: so why am I getting guid and uid issues following your guide to install snappy desktop?
<ogra_> we dont even enable graphical output on snappy devices yet
<longsleep> ogra_: a that explains it then
<davmor2> ogra_: http://paste.ubuntu.com/11929712/
<longsleep> ogra_: i am showing a full screen logo now
<ogra_> and i think you dont really want fbset on embedded setups
<ogra_> davmor2, using the wily u-d-f ?
<ogra_> (pre-wily cant build personal)
<davmor2> ogra_: yes or it doesn't download at all :)
<longsleep> ogra_: ok true - problem is that i need it in in initrd :/ so a snap would not help so much
<mterry> lool, tar and tarfile don't handle evil paths automatically?  That's stunning
<ogra_> longsleep, well, for that such a loop mounted img would serve as well :)
<longsleep> ogra_: exactly
<mvo_> tarfile even warns about this in its docs, but yes, its stunning
<ogra_> davmor2, what version of u-d-f exactly ?
<lool> mterry: yeah, it blew my mind too
<davmor2> ogra_: I installed ubuntu-device-flash_0.27-0ubuntu1_amd64.deb which is the wily version right
<ogra_> hmm, i'm even on 0.26 and it worked last time i tried personal
<ash_charles> ogra_: thanks---this worked for me :)
<davmor2> ogra_: I just grabbed it from packages.ubuntu.com under wily :)  http://paste.ubuntu.com/11930919/   see it has personal listed which the vivid one didn't
<ogra_> davmor2, there is bug 1470727
<ubottu> bug 1470727 in goget-ubuntu-touch (Ubuntu) "ubuntu-device-flash touch fails with: failed to find user uid/gid" [Undecided,Confirmed] https://launchpad.net/bugs/1470727
<ogra_> but no movement on it
<elopio> rsalveti: were you following federico's issue with update from 7 to 8?
<elopio> I've just reproduce it.
<davmor2> ogra_: so this 9.1GB is crap then right which would explain why it doesn't run then right :)
<ogra_> most likely, yes
<rsalveti> elopio: not yet, which issue?
<rsalveti> (still on call)
<davmor2> ogra_: that's fine as long as I know it is not something else :)
<ogra_> i would try to confirm, but i dont really feel like doing a 2h download right now
<davmor2> ogra_: not a worry dude just wanted to be sure :)
<ogra_> definitely a u-d-f thing i think
 * mvo_ gets dinner, telegram if the world explodes
<elopio> rsalveti: flash 15.04 alpha#7, update to #8, reboot. It returns to #7, but keeps #8 selected for the next reboot.
<elopio> ogra_: was it you he was working on it? ^ I don't remember what he said.
<davmor2> mvo_: telegram telegram telegram.......oh wait no your safe just some muppet letting of fireworks ;)
<davmor2> you're even
<ogra_> elopio, 7 has a broken snappy still
<ogra_> i only tested on the edge channel from 130 to 131
 * Chipaca just leaves this here: http://www.cnx-software.com/2015/07/22/odroid-c1-board-is-an-upcoming-upgrade-to-odroid-c1-board/
<longsleep> ogra_: cant you guys just trigger a 132 so we could test a real update with uboot.env ?
<ogra_> rsalveti, ^^^ what do you think ?
<longsleep> Chipaca: yeah the Spreedbox will have the ODROID-C1+
<mterry> elopio, you use {!r} for a path.  Why is repr preferred for a path?
<rsalveti> ogra_: sure, just trigger it
<elopio> mterry: not for a path. For a string that you want to keep quoted.
<ogra_> longsleep, rsalveti ... build running
<elopio> we have an inconsistent use of things that we keep quoted and things that we don't. But if we want quotes, !r makes it nicely.
<mterry> elopio, that seems like a really backdoor way to get quotes.  repr is defined as a string that eval can consume.  It happens to have quotes for some things but maybe the object passed to format is a complex object whose str() and repr() are very different.  Isn't it more robust to just put the two ' quote strings in the message itself?  It's the same number of characters.  It also lets translators use language-specific quotes (some languages do << an
<mterry> d >> right?)
<mterry> elopio, (not that we translate snapcraft yet)
<ogra_> rsalveti, oh, and i got the ok to seed ubuntu-fan now
<ogra_> (and the dnsmasq dep is actually gone i was told)
<elopio> mterry: I had the feeling that !r was better, but you broke it for me. I'll replace it.
<mterry> elopio, actually, if you wanted to be REALLY fancy, you'd use unicode curved quotes too
<mterry> :)
<elopio> ã
 * longsleep cannot grep anything because the stuff has so many typos :/
<longsleep> kernel get hdmimode form uboot is 720p
<longsleep> of course i grepped for "from uboot" ...
<longsleep> is there some snappy logo artwork (svg or similar) i can use to display on the odroid?
<longsleep> now that i can display full screen logos whould be a shame to ship a oem snap without one
 * ogra_ would just grab the one from the websire
<ogra_> *site
<longsleep> if i would find a svg
<longsleep> svn source for this one would be nice: http://1.bp.blogspot.com/-WgJN2_s3n5s/Va02zVflRDI/AAAAAAAA944/Sfi8vpEqNgQ/s1600/Screenshot%252Bfrom%252B2015-07-20%252B12%25253A58%25253A17.png
<ogra_> potrace ftw ;)
<longsleep> err no :P
<Rlyeh> Hello guys
<Rlyeh> Ogra_, I want to install the "OS.js". It's not available in snappy store, but in uappexplorer.com! How Can I install it on BBB?
<ogra_> Rlyeh, it wont be installable currently ... the format of snaps changed and i didnt find the time to port the os.js snap over
<ogra_> http://people.canonical.com/~ogra/snappy/snaps/ you could try to sideload it ... but i'm pretty sure snappy will just error and tell you that snaps with namespace arent allowed
<longsleep> ogra_: did you push the updated BBB oem snap to the store already?
<ogra_> longsleep, mvo did
<ogra_> shoudl be at 1.11
<longsleep> ogra_: so it will just not work when you install that OEM with stable channel?
<ogra_> longsleep, not until we released the rootfs
<longsleep> ogra_: ok - so i suppose i can add this breakage too then
<ogra_> Rlyeh, i'll try to get to that on the weekend and will produce a new OSjs snap
<Rlyeh> ogra_, Greaaaaaaaaaaat. Thank you :)
<ogra_> np, it was low on my prio list since i didnt actually expect any users :)
<Rlyeh> It's an useful app for snappy
<ogra_> yeah, ist a fun thing
<longsleep> yeah autopilot just triggered
<ogra_> oh, really ?
<ogra_> i dont see the new rootfs on system-image yet
<longsleep> yeah i also do not get what it actually did
<longsleep> seems i am booted to 129 for some reason
<ogra_> lovely
<longsleep> probably changed to many vars manually
<ogra_> yeah
<ogra_> i had the same issue yesterday
<ogra_> being on b while the system expected a
<longsleep> exactly
<longsleep> let my try to clean this up
 * ogra_ just did a clean re-flash 
<ogra_> ah
<longsleep> i guess i should do that too
<ogra_> and there is 132
<longsleep> at least now i am at 131
<longsleep> so lets try update then
<longsleep> so far so good - it replaced the old 129 - now reboot
<longsleep> yah
<longsleep> (ODROIDC)ubuntu@odroid:~$ snappy list -v
<longsleep> Name        Date       Version Developer
<longsleep> ubuntu-core 2015-07-24 132     ubuntu*
<longsleep> ubuntu-core 2015-07-23 131     ubuntu
<longsleep> odroidc     2015-07-23 0.3     *
<longsleep> worked like a charm
<longsleep> great job!
<ogra_> :D
<ogra_> was your job too ... dont underestimate how much you helped us :)
<longsleep> ogra_: well i try to help myself and get need to get detail understanding how things work with snappy. And you guys are really helpful with that - i highly appreciate it
<Rlyeh> How can I change timezone? I read about 'config' command, but I don't understand how to set the timezone!
<Rlyeh> "(BeagleBoneBlack)ubuntu@localhost:~$ snappy config ubuntu-core" just returns values :(
<lazyPower> question, if i need to modify the docker sandbox on the arm2 package, i should be able to just edit the snap in /apps/docker/current/meta/packageyaml and rebuild/isntall from this on the host correct?
<lazyPower> s/arm2/armhf/
#snappy 2016-07-25
<mup> Bug #1606100 opened: "snap revert" command  cannot be found <Snappy:New> <https://launchpad.net/bugs/1606100>
<ali1234> okay i figured it out. my qmake .pro has target.path=build because i copied it from the Qt examples
<ali1234> so fixed it... now let's see what the next problem is
<ali1234> This application failed to start because it could not find or load the Qt platform plugin "eglfs" in "".
<ali1234> getting closer...
<qengho> Nice!
<zyga> good morning
<didrocks> hey zyga
<liuxg> elopio, ping
<mup> PR snapd#1581 opened: asserts: remove/disable comma separated lists and their uses <Created by pedronis> <https://github.com/snapcore/snapd/pull/1581>
<liuxg> does anyone know how to use a license file in the snap?
<mardy> I'm try build snapd, and I'm getting this error (I'm new to golang): http://paste.ubuntu.com/20849102/
<stevebiscuit> mardy: try `cd $GOPATH/src/github.com/snapcore/snapd; go build -o /tmp/snap ./cmd/snap`
<mardy> stevebiscuit: thanks! I missed the fact that I have to build it from within $GOPATH
<stevebiscuit> mardy: np!
<mwhudson> hi, i have a firstboot question
<mwhudson> the console-conf stuff i'm working on prompts for username and password
<mwhudson> should it just call /sbin/useradd with this info or is there/will there be a snapd api to call?
<mup> PR snapd#1554 closed: store: Find now takes a Search instead of a query and channel <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1554>
<mup> PR snapd#1554 closed: store: Find now takes a Search instead of a query and channel <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1554>
<hikiko> hello :)
<netphreak> Hi, guys!
<netphreak> Has there been any new releases of snappy for RPI3?
<hikiko> question: I was about to change hexchat on snappy-playpen to use the git repo that doesn't have compile errors and noticed that we use the  https://dl.hexchat.net/hexchat/hexchat-2.12.1.tar.xz, and I was wondering if I should change it or leave it like it is now +what about the readme? should I remove the todo?
<hikiko> the official hexchat repo is this: https://github.com/hexchat/hexchat
<mup> PR snapd#1582 opened: debian: move snapd.refresh.timer into timers.target <Created by mvo5> <https://github.com/snapcore/snapd/pull/1582>
<hikiko> +another question :) I want to make a snap for blender, and in their page they have a 32bit tarball, an 64 bit tarball and a link to the git repo which one should I use in source?
<hikiko> what's preferable tarball or repo?
<tsimonq2> hikiko: well it depends
<qengho> hikiko: tarball.
<tsimonq2> hm qengho :P
<tsimonq2> hikiko: if using the repo fixes all the issues, mark it somehow as a daily snap and keep it like that until the next release
<hikiko> I was thinking that if the user clones the repo he will then build the appropriate version for his architecture
<hikiko> tsimonq2, how can I mark it as a daily snap?
<tsimonq2> hikiko: s/hexchat/hexchat-daily/g
<hikiko> +how are you? :)
<tsimonq2> great, you? :)
<hikiko> good!
<hikiko> alright :) I'll do this to blender then because someone changed hexchat to use this:
<hikiko>     source: https://dl.hexchat.net/hexchat/hexchat-2.12.1.tar.xz
<hikiko> so I guess it's not a daily-build
<qengho> hikiko: Assuming your dependencies are all in Ubuntu OR are in public and compilable, and assuming your builder is already a plugin, then use tarball.
<hikiko> qengho, but which tarball?
<hikiko> the 32 or the 64?
<hikiko> can I support both?
<qengho> hikiko: source tarball.
<hikiko> oh :)
<hikiko> ok :)
<qengho> hikiko: sorry, I confused you. I'm advocating sourceonly.
<hikiko> thanks qengho tsimonq2 :)
<qengho> hikiko: The builderson launchpad can make a blender-i386.snap and a blender-amd64.snap and (maybe) blender-armhf.snap and blender-arm64.snap
<ogra_> mwhudson, you need adduser ... not useradd, since we default to libnss-extrausers, not to shadow for password management ... also i though that we are forced to use cloud-init for this
<mwhudson> ogra_: uh yes, i should have said "useradd or something like that"
<ogra_> netphreak, there havent been any image releases for any arch yet ... (so not, not even the pi3 .. but flexiondotorg and kgunn made some awesome progress to get graphics up and running during the snappy sprint)
<ali1234> okay now i'm really getting somewhere: * failed to open vchiq instance
<ogra_> ali1234, is that a 15.04 image ?
<ali1234> ogra_: no
<ogra_> (16.04 ones should have vchiq)
<ali1234> ogra_: i am using the server classic image
<ogra_> (on the device side that is though  ... )
<ogra_> ah, might be that doesnt have such fancy things :)
<ali1234> yeah i need my snap to be able to access it
<ogra_> do you see a device in /dev ?
<ali1234> the server image has vchiq... app works when run normally
<ali1234> yes
<ogra_> ah, k
<ogra_> bug 1533265
<mup> Bug #1533265: /dev/vchiq is inaccessible for unprivileged user <snapd-interface> <Snappy:Confirmed> <https://launchpad.net/bugs/1533265>
<ali1234> wow, other people actually tried this?
<ali1234> i thought i was the only one
<ogra_> yeah...
<ogra_> but i fear that wont happen before we have actual new images ... which is still a few weeks
<ogra_> kernel and gadget snaps have just seen their final definition during last weeks sprint
<ali1234> well, can i work around it?
<ogra_> you can indeed install your snap with --devmode
<ali1234> the snap itself is marked as confinement: devmode
<ogra_> thats only for the store
<ogra_> you need to specify --devmode at install time
<ali1234> okay
<ogra_> and probably poke zyga to get the needed interface in place faster
<ali1234> what does the store do with it btw?
<ogra_> not sure that is high on his prio list
<ogra_> it prevents the snap from going into the stable channel
<ali1234> i see
<ali1234> so now i got "qrc:///main.qml:1:1: module "QtQuick" is not installed"
<ogra_> did you include it in your snap ?
<ogra_> and is the searchpath pointing to the right place ?
<ali1234> i included the desktop/qt5 thingy
<ogra_> not sure if that has qtquick ... didrocks would know i guess
<ali1234> maybe only the older one includes qml
<ali1234> qt5conf
<ogra_> i think the new one is just the onld one included in the generic tree
<ogra_> not sure if thre are actual differences
<ali1234> it's quite a bit different
<ali1234> installs a lot more stuff
<ogra_> ah
<ogra_> might be a bug with the new one then
<ogra_> (if the old one actually works)
<ali1234> well ti never saw the old one work due to bugs
<ali1234> but i thought it said it set up Qt "and QML" according to the readme
<ali1234> so regarding snapcraft cleanbuild
<ali1234> how can i notify it that it must use some PPAs?
<ogra_> that still doesnt work with external parts i think
<ali1234> okay but i can just include all my parts, that's not a problem
<ogra_> i think it is possible to set up a pre-created container where you can do such config stuff in advance ... but dont ask me how :)
<ali1234> i will probably need a custom launcher anyway
<ali1234> i do definitely need to include a ppa with the raspberry pi libraries, and another ppa with a patched Qt that uses it
<ogra_> using PPAs for a non cleanbuild build is trivial though ... it just uses the hosts sources.list
<ali1234> yes i know, that's what i am doing currently
<ali1234> (that's why i am using the server image)
<ogra_> well, i dont know how exactly you can use pre-created lxc containers for cleanbuild, but i knwo it is possible
<ali1234> hmm i staged qml-module-qtquick2 and qml-module-qtquick-xmllistmodel and libqt5declarative5 but it still says module QtQuick is not installed
<ali1234> hmm wait i think i need to clean
<ali1234> it works :)
<ogra_> \o/
<ogra_> congrats
<ali1234> it would be really nice if someone who knew what they were doing packaged up Qt for EGLFS... then snappy would be a competitor for boot2qt (which is commercial only)
<sborovkov> zyga: Hello. So can I get snap-confine 1.0.38 or whatever version  I need to get getwpuid working
<ogra_> sborovkov, i think there is one in xenial-proposed (i.e. not released and fully tested yet)
<sborovkov> ogra_: hmm, so is that possible to install it?
<sborovkov> Ah, found the repo
<ogra_> yes, (temporary) enable proposed, apt update ... apt install snap-confine ... disable -proposed again
<ogra_> (and apt update for making it clean)
<didrocks> ali1234: are you sure you have the right version? If it's qtquick 1, you need qt4
<didrocks> and so the qt4 launcher
<ali1234> didrocks: yes i am sure
<sborovkov> ogra_: do you by chance have any idea when snapd 2.0.11 will be released/appear in proposed
<didrocks> otherwise, yeah, I only stage some declarative lib, but not the whole stack
<mup> PR snapcraft#683 opened: Release changelog for 2.13.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/683>
<didrocks> (to keep the launcher lighter for non qml projects)
<ogra_> sborovkov, nope ...
<ali1234> didrocks: why the gtk pixmap stuff?
<didrocks> if you are using a qt5 project on a GNOME-based desktop, you need gtk pixmaps for the icon themes
<ogra_> sborovkov, you can watch bug 1605303 though
<mup> Bug #1605303: [SRU] 2.0.11 <snapd (Ubuntu):New> <snapd (Ubuntu Xenial):New> <https://launchpad.net/bugs/1605303>
<didrocks> (as it's using the gtk engine)
<ali1234> i'm not running any desktop at all... what should i do?
<ali1234> make my own launcher?
<sborovkov> ogra_: Oh, nice, thanks
<didrocks> ali1234: you can reuse the same launcher, and override stage-packages
<ali1234> i literally don't need any of the things you stage
<didrocks> that way, you only pick what you want
<ali1234> oh, that's cool
<didrocks> still keeping the same "executable"
<ali1234> so i don't need to fork it
<didrocks> exactly!
<didrocks> if the script doesn't work because of some missing deps which should be optional, we could fix it
<ali1234> it complains when i remove gdk pixbuf
<didrocks> (I didn't try, so I may required some executables without testing for their existence first, I'm happy to fix if you poke me ;))
<didrocks> let me look
<ali1234> although actually i'm not sure *how* i removed it
<ali1234> it still works
<ali1234> it just prints an error "file not found"
<ali1234> hang on let me try thing
<ali1234> oh i see
<ali1234> what i did was add a new part that references the github one
<ali1234> let me pastebin my yaml
<ali1234> http://paste.ubuntu.com/20860640/
<didrocks> that works as well :)
<ali1234> the git repo is an identical fork of yours
<ali1234> but i suppose it is unnecessary
<ogra_> whee, version 0
<ogra_> :)
<didrocks> ali1234: right!
<didrocks> ali1234: the error was on gdk-pixbuf-query-loaders?
<ali1234> i can't find the error now, seems to have stopped happening... i dunno whats going on
<didrocks> we only compile first time you install
<didrocks> and after each update of the snap
<ali1234> ah that would be why it went away
<didrocks> (some steps can be long)
<didrocks> yep!
<ali1234> i wondered why it took so long to start actually
<didrocks> ok, it seems to be on this run, I didn't protect it, doing now
<ali1234> /snap/infodump/x19/bin/desktop-launch: line 113: /snap/infodump/x19/usr/lib/arm-linux-gnueabihf/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders: No such file or directory
<ogra_> you could just put libglib2.0 into your stage packages (if that doesnt pull in too many debs)
<ogra_> *deps
<didrocks> yeah
<didrocks> fixing this
<didrocks> you need to ensure that you then have all working on various env
<ogra_> the script should probably get a check though and give you a nice hint ;)
<didrocks> like icons and such
<ali1234> icons?
<ogra_> in case someone runs your snap on a desktop install
<ali1234> if they run my snap on a desktop install it absolutely definitely will not work
<ogra_> dont forget that your package is installable everywhere on different distros, desktops or core installs
<ali1234> it bundles a Qt built for eglfs
<ali1234> if your computer doesn't support eglfs it won't work
<ogra_> well, you should probably add a wrapper script that spits out a proper warning then
<ali1234> the binary already does that
<ogra_> ah, k
<ali1234> it will say that error i pasted early
<ali1234> * can't open vchiq probably
<ogra_> i'd also add that info to the long description of the package
<ogra_> so people dont accidentially install it because they dont know what it is
<ali1234> i'm not going to upload it to the store anyway
<ogra_> ah
<ali1234> it uses reverse engineered APIs, not just rss
<ogra_> then this doesnt matter indeed
<ali1234> i could make a "clean" version i suppose
<ali1234> actually it should be possible to make a snap that works in eglfs or xcb
<didrocks> ali1234: pushed on master
<ogra_> it surely is ... the question is what overhead you need to ship then
<ali1234> didrocks: okay, so i should adjust my yaml to point back to the original repo? or is there a way to override the stage packages via the wikipart syntax?
<ogra_> (unused dependencies etc)
<didrocks> ali1234: I think there is, wait a sec
<ali1234> i'm really impressed with snapcraft btw
<ali1234> it's so easy
<didrocks> ali1234: http://blog.sergiusens.org/posts/The-Snapcraft-Parts-Ecosystem/, "composition"
<didrocks> "composing"*
<didrocks> sorry
<ogra_> ali1234, send your flowers to sergiusens and kyrofa ;)
<didrocks> so, you just redifine the part
<didrocks> redefineÃ¹
<ogra_> (yes, it is the best thing since sliced bread)
<didrocks> and restart stage-packages (and build-packages)
<ali1234> neat
<ali1234> so how do i say stage-packages: none?
<didrocks> stage-packages: []
<didrocks> empty list ;)
<ogra_> crazy stuff :)
<ali1234> so you *can* put all the packages into one line?
<ali1234> stage-packages: [foo, bar]
<ali1234> like that?
<didrocks> yeah, that's pure yaml
<ogra_> yeah, yaml is very flexible with that
<didrocks> can be quite unreadable easily though :p
<didrocks> but for few ones, it's better to have one line IMHO
<ogra_> for long lists it surely is
<ali1234> hmm can't get this to work
<didrocks> oh?
<didrocks> can be a bug in snapcraft, I don't know who apart from Sergio really tested/used this override
<ali1234> i say after: [desktop/qt5]
<ali1234> but then i don't know what to put for the override part name
<didrocks> after that, you set another part:
<didrocks>    destkop/qt5:
<didrocks>       stage-packages: []
<didrocks> that should be enough
<e^1> after coming across snappy i very much liked it, if i liked to contribute from where i can start ?
<ali1234> that doesn't work
<ali1234> Issues while validating snapcraft.yaml: The 'parts' property does not match the required schema: Additional properties are not allowed ('desktop/qt5' was unexpected)
<didrocks> what do you get?
<didrocks> interesting
<didrocks> sergiusens: do you kow about that? ^
<didrocks> ali1234: so, meanwhile, redefine your part, refering to upstream source git
<ogra_> e^1, to what would you like to contribute ? to snappy itself, to the build tool (snapcraft) or do you want to snap packages ?
<icey> does the snap store support private snaps?
<e^1> ogra_: to snappy as well as snapcraft
<ogra_> icey, it is surely planned, not sure it does for single snaps yet (you could always have a private sub-store though)
<e^1> wow it's in pythong :) :)
<e^1> snapcraft
<ogra_> e^1, https://github.com/snapcore/ should be a good start then
<e^1> s/pythong/python
<e^1> yeah just stumbled there..
<e^1> ogra_: what about learning more snappy ?
<icey> Thanks ogra_
<ali1234> actually, does anyone have a raspberry pi running ubuntu/snapd/x11?
<ali1234> i could make a simple QML hello world, and see if it runs on x11
<ogra_> e^1, for building snaps come to http://gitter.im/ubuntu/snappy-playpen ... there is where regular package sessions happen and people can answer questions regading snaps
<sborovkov> ogra_: unfortunately, getpwuid still fails for me with newer snap-confine :(
<e^1> ogra_: arrived there :)
<ogra_> sborovkov, you had a bug for that, right ? make sure to note it there
<e^1> ogra_: how to know how exacly snappy works and how it is diff from regular linux distro ?
<sborovkov> ogra_: No, I did not. I will create one though now.
<ogra_> e^1, https://developer.ubuntu.com/en/snappy/guides/ shows some basics ... i guess beyond this, mainly by asking people :)
<e^1> ogra_: cool :)
<e^1> ogra_: also is it possible to build snappy from scratch so we can understand what's going on ?
<ogra_> sure
<e^1> ogra_: can you shed some light about  it ?
<ogra_> talk to zyga about that if you dont want to build deb packages for snapd and friends
<ogra_> (he is at a sprint this week though ... might only be rarely around)
<e^1> ok will ask zyga more regarding this
<ogra_> cjwatson, is bug 1606203 a bzr or LP bug ? (the log doesnt look like it is snapcraft)
<mup> Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' <launchpad> <snappy> <Snapcraft:New> <https://launchpad.net/bugs/1606203>
<e^1> it's just that i discovered a cool open source project i can work on..
<ogra_> shiny title :)
<e^1> title ?
<ogra_> the bug that mup (the bot) posted
<e^1> ooh ok :)
<sergiusens> didrocks it is fixed in master
<sergiusens> didrocks and in snapcraft in -proposed
<mup> PR snapd#1583 opened: snap: remove meta/kernel.yaml again <Created by mvo5> <https://github.com/snapcore/snapd/pull/1583>
<sborovkov> ogra_: created the bug, do you know if I can bug anyone specific to take a look at that https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1606212
<e^1> ogra_: can i installed updated versio of apps which are not available in snappy ?
<mup> Bug #1606212: getpwuid is failing on classic image <snapd (Ubuntu):New> <https://launchpad.net/bugs/1606212>
<ogra_> sborovkov, add the snapd-interfaces tag to the bug, then jdstrand or tyhicks should see it on their lists
<e^1> ogra_: okay everything is similar only change is there is apps dir and almost nothing installed
<didrocks> ali1234: ok, so wait for next-coming snapcraft release to do proper override ^ :)
<didrocks> thanks sergiusens!
<sborovkov> ogra_: thanks
<cjwatson> ogra_: Looks like bzr has trouble talking to the Launchpad directory service through an authenticated proxy (it's getting a bit confused and using the proxy credentials in the wrong place), which is at least arguably a bzr bug.
<cjwatson> ogra_: That will probably be no fun to fix, and bzr is largely unstaffed at the moment, so it may be most economical to hack snapcraft to unset https_proxy when calling bzr, with a comment explaining that this is due to this bug.
<cjwatson> ogra_: It's definitely not an LP bug, I can say that much.
<ogra_> k
 * cjwatson copies and pastes this into the bug report
<ogra_> :)
<ogra_> i was about to
<timothy> cjwatson: and if you need https_proxy to go to internet? :P
<sergiusens> cjwatson I guess disabling the proxy if it would fail anyways is fine, more so that if you are using bzr you will most likely be using launchpad too
<cjwatson> timothy: Right, hence the comment.
<sergiusens> can we get this comment in the bug or can I paste this conversation?
<cjwatson> timothy: But any non-LP-hosted bzr branch can be mirrored to LP, so there's a workaround.
<cjwatson> sergiusens: Just did.
<sergiusens> thanks cjwatson
<timothy> I hope anything will be migrated to git (github) soon ;)
<cjwatson> Or git (Launchpad)
<timothy> it's the same
<cjwatson> Sure, so just leave out the parenthetical :P
<lool> ysionneau: Yop
<ysionneau> hi!
<e^1> ogra_: were my questions too silly :P
<ogra_> e^1, sorry, i got distracted by actual work :)
<ogra_> can you re-phrase the questions a bit, i dont really understand them
<sborovkov> ogra_: hmm, is snap-interfaces right though? I run unconfined
<ogra_> snapd-interfaces
<ogra_> i think
<ogra_> and yes, even when running unconfined (thats then actually a bug in the unconfined mode :) )
<zyga> sborovkov: let me check and get back t oyou
<zyga> sborovkov: so looking at snapd, this system call is not allowed
<zyga> sborovkov: you can use devmode for now
<zyga> sborovkov: is there a bug on this?
<sborovkov> zyga: Well there is no way to run without full screen apps on rpi without devmode anyway :) Created a bug just today https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1606212
<mup> Bug #1606212: getpwuid is failing on classic image <snapd-interfaces> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1606212>
<sborovkov> zyga: the issue is it's not working in devmode as well :(
<zyga> sborovkov: thank you, I will work on my backlog as time permits
<zyga> sborovkov: that's unexpected, could be a kernel isuse
<zyga> sborovkov: does it work outside of snaps?
<sborovkov> zyga: Did not test that. I will create a simple app to test. Give me few minutes. Note that on snappy only system everything was working perfectly (though image I used was from few weeks ago). going to retest on snappy only system as well.
<e^1> ogra_: is it possible to update any app to latest version for example docker ?
<e^1> right now docker is quite older version
<sborovkov> zyga: yup, just ran python, it works perfectly outside of snaps
<zyga> sborovkov: ok, maybe you can share that demo
<zyga> sborovkov: I can dig more
<e^1> zyga: np mate :)
<zyga> sborovkov: but maybe just next week :)
<ogra_> e^1, sure, if you have a snapcraft.yaml or if upstream releases a new versuin
<ogra_> *version
<sborovkov> zyga: demo? I just ran python3. import pwd; pwd.getpwuid(0);
<ogra_> i think a docker snap update is being worked on (i think someone said that here recently)
<zyga> sborovkov: ok
<zyga> sborovkov: thanks
<zyga> sborovkov: does it work on x86?
<sborovkov> zyga: I am not sure if it's architecture specific. We have screenly only working under arm at the moment. So I don't have snap for x86. is there easy way to just call python interpreter at the moment so I can check that?
<sborovkov> from the snap I mean
<zyga> sborovkov: I mean the tiny python one liner
<zyga> sborovkov: no worries, I'll check it out
<sborovkov> zyga: it works outside of snaps at least
<e^1> ogra_: cool
<ogra_> zyga, is mvo at the sprint ? there is an old snap-cconfine package in the image PPA that gets pulled into my os snap builds, can i remove that from the PPA ?
<ogra_> (still including the copmare-versions bug... i see it in my logs)
<zyga> ogra_: yes he is
<zyga> ogra_: old as in older than current?
<zyga> ogra_: I think so, as long as it gets replaced by the new one in the archive
<zyga> ogra_: though I'll let mvo answer with authority
<sborovkov> zyga: Anyway I will test it on snappy only as well. It seems like I was using quite old image before. Have not updated for pretty long time since everything was working. May be it's not classic only issue.
<ogra_> zyga, older than whats in proposed ... but my builds dont use proposed atm, so the PPA version gets pulled in
<sborovkov> zyga: yup, just build image with latest kernel/gadget snap. INstalled the same snap and it's working. So classic only issue
<zyga> sborovkov: interesting, that is unexpected then
<mup> PR snapcraft#683 closed: Release changelog for 2.13.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/683>
<ogra_> sergiusens, any chance you can put the prime/stage fixes for type: os on a high prio ? i dont really want to go back to cdimage builds if possible
<ogra_> (and i dont count on kyrofa this week given he will have to de-jetlag)
<ogra_> (i'd try to come up with a PR myself, but looking at the prime code i fear that would cause more work than helping)
<ali1234> i snapped the QML rssnews demo https://github.com/ali1234/rpi-qml-eglfs-snap
<josepht> ogra_: is there a bug (or bugs) for the prime/stage fixes for type: os?
<ogra_> ali1234, oh, careful with silo ppas ... their content changes frequently ...
<ali1234> yes i know
<ali1234> but i could not find Qt 5.6 anywhere else
<ogra_> josepht, bug 1605903
<mup> Bug #1605903: "type: os" should prevent stage and prime stages from mangling content <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1605903>
<ogra_> ali1234, Mirv (in #ubuntu-devel or -touch) should have a pre-release PPA for the stuff before he pushes it to release
<ali1234> yeah, i'm going to ask him about that next
<ali1234> afaik silo 11 *is* the prerelase repo
<ali1234> (for xenial)
<ogra_> josepht, the best would be if they would just be skipped for anything but moving the content and creatings the files in meta/
<ogra_> ali1234, ah ... then it might actually stay around for some weeks
<ali1234> is there a working all-snap image for rpi3 yet?
<ogra_> there isnt a working all-snaps image for anything yet
<ali1234> hmm what was i using before on rpi2 then?
<ogra_> we're  waiting for the new ubuntu-image and teeh finalization of the new gadget and kernel snap specification
<ogra_> whatever is out there is obsolete
<ali1234> okay
<ogra_> or lets rather say "experimental"
<ogra_> :)
<Pharaoh_Atem> Hello everyone!
<liuxg> sergiusens, I have a snapcraft.yaml at http://paste.ubuntu.com/20872098/, which uses the license.txt file. however, when I compile it, I get a warining like http://paste.ubuntu.com/20872098/. when I install the snap file, it does not prompt me the license file. is there any problem with my snapcraft.yaml file? thanks
<sergiusens> liuxg I guess that maybe these might be questions for Chipaca
<liuxg> sergiusens, thanks! Chipaca, would you please have a check with my question? thanks
<Croepha> you guys ever have snapd just die on you? and refuse to come back up with: could not unmarshal state entry "snaps": json: cannot unmarshal...
<ogra_> Chipaca, ^^^^
<ogra_> bug 1604606
<mup> Bug #1604606: snapd fails to start due to: could not unmarshal state entry "snaps": json: cannot unmarshal string into Go value of type int <snapd (Ubuntu):New> <https://launchpad.net/bugs/1604606>
<ogra_> smells like that one
<liuxg> elopio, ping
<elopio> liuxg: 'sup?
<liuxg> elopio, I found that you once tested the license implementation at https://github.com/snapcore/snapcraft/pull/201 however, I am now having a problem in using the license http://paste.ubuntu.com/20872098/
<mup> PR snapcraft#201: Add licensing support <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/201>
<liuxg> elopio, do you know how to implement a license in the snapcraft? I once reported a bug againt it long time ago. thanks
<elopio> liuxg: this is what you need from the snapcraft side: https://github.com/snapcore/snapcraft/tree/master/integration_tests/snaps/license
<elopio> I'm not sure if that's working on the snapd side. If it is not, and there is no bug reported, you can open one for them.
<liuxg> elopio, this is what I built for the project http://paste.ubuntu.com/20877984/. when I install it, it does not prompt the license.
<elopio> liuxg: you can file a bug in launchpad.net/snappy
<liuxg> elopio, is this a bug in the snapcraft or snappy?
<elopio> liuxg: snappy, afaik.
<liuxg> elopio, ok. I will do that.
<liuxg> elopio, however, there is a warning like DEPRECATED: 'license' defined in snapcraft.yaml
<liuxg> elopio, I think this could be related to the snapcraft, right?
<elopio> liuxg: snapcraft puts the license in meta.
<liuxg> elopio, however, it says that it is a deprecated "license" defined in the snapcraft.yaml. what should be correct way to do it?
<elopio> the new style is to put it there yourself. We might be putting it in the wrong directory, or snappy could be ignoring it.
<liuxg> elopio, when I build the project for the second time, it says http://paste.ubuntu.com/20878500/
<mup> PR snapd#1584 opened: asserts: introduce new parseHeaders <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/1584>
<elopio> liuxg: that is a bug in snapcraft. Please report it in launchpad.net/snapcraft
<liuxg> elopio, I have reported the bug at https://bugs.launchpad.net/snapcraft/+bug/1606283
<mup> Bug #1606283: license does not work in the snap installation. <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1606283>
<elopio> thank you.
<liuxg> elopio, you are welcome!
<jdstrand> zyga: hi! hope you had a nice weekend and week last week :)
<jdstrand> zyga: fyi, bug #1606277
<mup> Bug #1606277: log-observe interface is broken in latest snap-confine <snapd-interface> <snap-confine (Ubuntu):New> <https://launchpad.net/bugs/1606277>
<mup> Bug #1606283 opened: license does not work in the snap installation. <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1606283>
<zyga> jdstrand: I just noticed, thank you for reporting this, I will fix and release it today
<cwayne> zyga: hey, do you know when the next planned release of ubuntu-core snap is?
<cwayne> and do you think there's a chance https://github.com/snapcore/snapd/pull/1563 lands before that
<mup> PR snapd#1563: Interfaces: hardware-observe <Created by cwayne18> <https://github.com/snapcore/snapd/pull/1563>
<timothy> cwayne: snapd and snap-core are different projects
<timothy> err snapd-confine
<jdstrand> tyhicks: hey, fyi latest comments in bug #1584456
<mup> Bug #1584456: apparmor denial using ptmx char device <apparmor> <Snappy:Confirmed> <https://launchpad.net/bugs/1584456>
<zyga> cwayne: nope, I don't know
<zyga> cwayne: maybe mvo knows
<jdstrand> zyga: thanks
<tyhicks> jdstrand: thanks - I hope that I can work on fixing that bug this week
<renatu> jdstrand, do you know who wrote the "calendar" policygroup for calendar?
<renatu> apparmor used by the phone
<renatu> zyga, what is the difference btw the permanent rule and connected rule, on a snap interface?
<jdstrand> renatu: I did
<renatu> jdstrand, could you take a look on that: https://github.com/renatofilho/snapd/commit/198974dddac4e30a971f893b7fb402d662acf637
<renatu> jdstrand, I did some small changes, to adapt it to a snap interface. Still not clear for me why do we need permanent and PermanentSlotDBus
<jdstrand> renatu: I can explain permanent vs connected. a permanent rule is something that is always there regardless of whether snaps are connected. slot side permanent policy is typically used for whatever is needed to allow a server that connecting snaps talk to to run. permanent plugs policy isn't used much
<jdstrand> renatu: where is this interface supposed to be used? are you implementing an eds-calendar snap for other snaps to connect to or are you having snaps connect to the session eds on classic?
<renatu> jdstrand, ubuntu-calendar-app
<jdstrand> sure, that is an app
<renatu> jdstrand, https://code.launchpad.net/~renatofilho/+junk/ubuntu-calendar-app-snappy
<jdstrand> but what is it connecting to?
<renatu> jdstrand, eds.
<renatu> we do not have eds snappy yet
<jdstrand> yes, but an eds provided by a snap or by the system?
<jdstrand> ok
<renatu> jdstrand, by the system now
<jdstrand> so if provided by the system, then you don't worry about slot side policy
<jdstrand> slot side policy is for snaps that provide a service that other snaps plug into
<jdstrand> so, if/when you implement eds as a snap, then you'd need to create slot policy
<jdstrand> based on what you've said here, you just need connected plug policy
<jdstrand> and return nil for everything else
<jdstrand> (permanent slot, connected slot and permanent plugs)
<renatu> jdstrand, should I create a new interface for the server? or I can mix both?
<jdstrand> you can mix
<renatu> jdstrand, in EDS case, we have contacts and calendar
<jdstrand> but if you are planning on doing that, it would be good to name it so that it fits
<renatu> probably we will want a contact interface
<jdstrand> that's fine but they can still be split into eds-calendar and eds-contacts
<jdstrand> since those are different dbus APIs
<renatu> jdstrand, they share the same source registry
<renatu> interface
<jdstrand> I see what you mean-- the slot would be the same but the plugs could be different
<jdstrand> ok, so, probably should be named 'eds', not 'eds-calendar'
<jdstrand> then we can use interface attributes to specify calendar, contacts or both
<renatu> jdstrand, any example of that?
<jdstrand> in this manner, an eds snap can 'slots; [ eds ]' and a consuming snap could pick which it needs
<jdstrand> renatu: bool_file and seriral_port both use attributes
<jdstrand> renatu: there are some other PRs in flight that do too
<renatu> jdstrand, nice, I will take a look. Thanks
<jdstrand> renatu: but the basic idea would be, you set up cariables for common policy for talking to eds at all, then calendar policy and contacts policy. you look at the interface attributes and always add common, and then calendar and/or contacts depending on the attributes
<renatu> jdstrand, ok, I think I got the idea. Let me se if I can implement that ;)
<renatu> jdstrand, if I have a permanent rule means that any app that make use of this rule can use that? Could a app take ownership of the service by mistake?  Or there is a specific rule/property for that?
<jdstrand> renatu: a permanent rule simple means that it is given unconditionally to the snap regardless of auto-connect
<jdstrand> renatu: they are typically only used on the slot side since a server implementing the slot side (ie, eds itself) may need certain things to run at all
<jdstrand> renatu: so, a slot permanent rule might be an apparmor rule for binding to a dbus well-known name
<jdstrand> renatu: a connected rule on the slot side might be an apparmor rule allowing a specific security label (ie, snap) to connect to the server
<jdstrand> renatu: a connected rule on the plug side might be an apparmor rule allowing connecting to the slot side security label (ie, the eds snap or the unconfined eds system-supplied snap)
<jdstrand> renatu: does that make sense?
<jdstrand> renatu: if you haven't already, you might want to read zyga's blog series: http://www.zygoon.pl/2016/04/snappy-snapcraft-and-interfaces.html
<elopio> didrocks: can you please add me to the ubuntu team in github?
<elopio> I want to make a docker image with autobuild for snapcraft:master. And we can move yours to a team too.
<elopio> we can put both dockerfiles in snappy-playpen.
<Pharaoh_Atem> zyga: just saw your review request and I'm taking the review for goconfigparser
<zyga> Pharaoh_Atem: thank you
<zyga> Pharaoh_Atem: I have a few important emergency things I need to do upstream but I will request snap-confine review next
<zyga> Pharaoh_Atem: and snapd, without the preset bits
<Pharaoh_Atem> does snap-confine have selinux integration at this point, or is it essentially a stub still?
<elopio> marcoceppi: arosales: or maybe you can add me to the ubuntu org in github.
<mup> PR snapcraft#684 opened: Run tests from /tmp <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/684>
<didrocks> elopio: added!
<didrocks> elopio: this is the repo having the docker recipe: https://github.com/ubuntu/docker-snapcraft
<zyga> Pharaoh_Atem: no, it's not even in master yet,
<zyga> Pharaoh_Atem: it's not a stub, it does other things but doesn't do anything selinux yet
<Pharaoh_Atem> ah okay
<zyga> Pharaoh_Atem: I need to stop sprinting at some point and actually sit down and do stuff ;-)
<elopio> didrocks: awesome! thanks.
<didrocks> yw :)
<e^1> zyga: hey :) i would like to know how to create ubuntu core from scratch ?
<ogra_> e^1, that happens in the image build machinery of ubuntu ... the same place where the CD image isos are built
<ogra_> it uses ubuntu-cdimage and live-build currently ... the config lives in the livecd-rootfs package
<e^1> ogra_: ok let me google more about it..
<e^1> ogra_: what is the basic difference between ubuntu core and normal ubuntu desktop ?
<e^1> only snappy makes the difference ?
<ogra_> ubuntu core is about 70MB big
<e^1> it seems that snappy is added on ubuntu core if i am not mistaken..
<ogra_> it is just enough OS to boot and run snapd
<jrwren> i can't figure out the difference between ubuntu-base and ubuntu-core
<ogra_> e^1, http://wiki.ubuntu.com/ReleaseTeam/CDImageSetup
<ogra_> that has some info about the ubuntu build system and where to get the source
<ogra_> jrwren, one is a tarball to be used for build chroots, the other is an embedded OS
<jrwren> ogra_: interesting. thanks!
<ogra_> (well, for build chroots, or as base for creating some other installs etc etc)
<ogra_> ubuntu-base -> non booting rootfs, just enough to run apt
<ogra_> ubuntu-core -> embedded bootable OS based on snaps, just enough OS to boot and run snapd
<e^1> ogra_: nice info
<e^1> ogra_: so following CDImageSetup we can create 70MB ubuntu core image ?
<e^1> but that's CD so it must be quite big
<ogra_> no
<ogra_> well, yes, but the cdimage setup is very complex
<ogra_> that page is just about how to contribute code
<ogra_> i dont think the setup is well documented beyond the source code itself
<e^1> ogra_: where i can find more info regarding ubuntu core image ?
 * ogra_ has seen others gove up after spending ages on trying it locally
<Pharaoh_Atem> zyga: golang(github.com/mvo5/goconfigparser) review approved: https://bugzilla.redhat.com/show_bug.cgi?id=1359804
<ogra_> the image is built from a kernel snap, a gadget snap and the ubuntu-core snap ...
<e^1> ogra_: doubt cleared :)
<SamYaple> yo yo jdstrand . RE our conversation the other day about named sockets and what have you, all is good i believe. if we implement the /etc/* bindmount/overlay like you were suggesting I can tie all of this together and have it work well
<ogra_> the ubuntu-core snap and the kernels snap are currently created by the cdimage build system
<e^1> ogra_: now say if i want to install any specific app i need to first package it in snappy format is that correct ?
<SamYaple> jdstrand: i gave it a good once over and it should be solid
<ogra_> atm we use a tool called ubuntu-device-flash to assemble these snaps ... it downlods them from the snap store and assembles an img
<ogra_> but that tool is rather abandoned, a new tool called ubuntu-image is in the works. that will directly hook into the cdimage build system
<ogra_> e^1, right ... if you wanted ... say a raspberry PI kodi image you would have to package kodi as snap and push it to the store ... then create a gadget snap with the rpi uboot setup inside that says you want a rpi kernel and that you want the kodi snap from the store pre-installed
<ogra_> currently ubuntu-device-flash would then take your gadget snap from disk, pull the pi kkernel from the store, the ubuntu-core snap and the kodi snap ... and roll all of them into a bootable SD card image
<jdstrand> SamYaple: nice! if you haven't already, you might mention the bind mount stuff in bug #1577514
<mup> Bug #1577514: Support preloading to make snaps feel at home <snapd-interface> <Snapcraft:Triaged by sergiusens> <https://launchpad.net/bugs/1577514>
<SamYaple> jdstrand: alrighty ill do it now
 * ogra_ has the feeling that "tiny preloading library" might become rather big ... 
<ogra_> seeing it mentioned in so many bugs
<SamYaple> ogra_: LD_PRELOAD solves all the things and isnt full of security problems dont ya know?
<jdstrand> I think niemeyer has a creative way to keep it small and generic (as I outlined my understanding in the aforementioned bug)
<jdstrand> hehe
<e^1> ogra_: it's quite difficutl to digest but getting a rough idea..
<jdstrand> well, LD_PRELOAD in this context is ok cause the process is running under confinement and can still only access its own stuff
<ogra_> SamYaple, haha
<ogra_> the prob is to get all the APIs right and not miss anything an app expects from the function you replace
<ogra_> and by the looks of it there will be a lot of functions piling up over time
<Pharaoh_Atem> zyga: you have a problem in https://bugzilla.redhat.com/show_bug.cgi?id=1359802
<e^1> ogra_: can i use ubuntu base and chroot into ubuntu core and customize it ?
<e^1> or how can i customize ubuntu core ?
<ogra_> for local experiments you caan re-pack the snap ...
<e^1> ogra_: i am not getting you mate..
<ogra_> you can re-pack the snap and sideload it
<e^1> ogra_: you have any wiki or something on this /
<ogra_> nope
<ogra_> it isnt even done yet ...
<e^1> ogra_: say for example i want to install apt-get than how can i do that ?
<ogra_> docs will come once we actually provide images :)
<ogra_> you cant ...
<ogra_> there is a classic mode shipped though
<e^1> ogra_: okay..
<ogra_> that can give you a container to run apt in
<e^1> ogra_: than what about adding a custom binary ? that too no ?
<e^1> this means ubuntu core is locked, you can change anything straight away..
<ogra_> i think mvo wrote a longish mail to the mailing lists a few weeks ago ... check the archives
<e^1> okay
<e^1> will dig mailing list..
<ogra_> for experimenting around you can unpack the ubuntu-core snap, make your changes and snap it again
<ogra_> (and then sideload it into your image)
<e^1> ogra_: in simple terms unpack this image  ubuntu-15.04-snappy-amd64+generic.img.xz ?
<ogra_> ah, no, that is old cruft
<e^1> than which image ?
<ogra_> the 15.04 model is obsolete
<e^1> 16.04 ?
<ogra_> people.canonical.com/~mvo/all-snaps/ has some very old (and possibly completely broken today) images
<e^1> the image is not available http://releases.ubuntu.com/16.04/
<ogra_> and an ubuntu-device-flash-experimental that you can use to roll something more recent
<ogra_> there have been no proper or official 16.04 images yet ...
<ogra_> all resources that could work on this have been focused on cross-distro stuff and integration into classic installs, so the images are a bit behind
<e^1> ogra_: haha lots of new stuff :)
<ogra_> we just had a sprint last week where we met to finalize the specs for the images
<e^1> ogra_: if i want to contribute in all this stuff than where should i start from ?
<ogra_> depends what you want (i think i said that in th beginning already ;) )
<e^1> hmm yeah :)
<mup> PR snapd#1585 opened: store, daemon, client, cmd/snap, docs/rest.md: adieu search grammar <Created by chipaca> <https://github.com/snapcore/snapd/pull/1585>
<e^1> ogra_: so i have to unpack this ubuntu-device-flash image and make changes and pack it ?
<ogra_> no
<e^1> than which image i should work on ?
<ogra_> you would grab the ubuntu-core snap from inside it (easiest would be from a booted image)
<ogra_> and unpack that ...
<ogra_> then change it
<ogra_> and ssnap it again
<ogra_> then sideload it into the running image
<e^1> ogra_: i am already booted into ubuntu snappy
<e^1> ubuntu-core
<ogra_> it isnt really clear to me what you want to do there though
<ogra_> it is more likely that we remove (a lot) more stuff than that we add anything to it ...
<e^1> ogra_: i want to add custom binaries to it
<e^1> or custom apps
<ogra_> then do it like i explained in the kodi example above
<e^1> that's the main thing..
<ogra_> you dont modify the ubuntu-core snap
<ogra_> but add another snap package
<ogra_> through a definition in your gadget snap ... at image build time
<e^1> ogra_: as you said 'grab the ubuntu-core snap from inside it from the booted image' so just curious how to do that ?
<ogra_> using scp
<e^1> and i am sorry i am annoying you much..
<e^1> if*
 * Chipaca hugs ogra_ 
 * ogra_ hugs Chipaca 
<ogra_> no worries, i'm fine :)
<e^1> ogra_: yeah but what should i scp ? which exact location ?
<ogra_> check the output of the mount command ;)
<ogra_> you will see i guess
<ogra_> (piping to a "grep ubuntu-core" might be helpful to filter a bit
<ogra_> )
<ogra_> iirs it is somewhere in /var/snap
<ogra_> or /var/lib/snap or so
<ogra_> still though ... adding stuff ... if it is more complex than a standalone binary in /usr/bin will mean a lot of other changes
<Chipaca> /var/lib/snapd/snaps/ubuntu-core_potato.snap
<ogra_> i.e. apt will definitely not work if you just add it
<ogra_> such a change needs extra integration work in other places
<Chipaca> ogra_, I'm assuming it's for educational purposes
<ogra_> me too :)
 * Chipaca goes back to watching spread like a hawk
<e^1> yeah got that :)
<e^1> this means this is not like other ordinary linux distro..
<e^1> in this lots of stuff have been changed
<ogra_> not really
<ogra_> but if you change stuff at the readonly core you need to do other stuff
<ogra_> this system is designed for and around snaps
<ogra_> so if you want to add things, create a snap for it
<ogra_> ;)
<e^1> first of all i need to understand the structure of ubuntu core and than how snaps work
<e^1> this will make things more clear in my brain.
<ogra_> the image boots into the readonly snap ... then bind mounts writable bits for it into the writabble partition during the boot process ... then it starts snapd
<ogra_> thats all
<ogra_> (well, there is a normal ubunt boot process around it using systemd )
<e^1> ogra_: okay, there are 2 new dir apps and writable under / dir
<ogra_> ?
<e^1> ogra_: according to me only certain dir or portion of the system might be getting version control thus it can be roll back to previous state
<e^1> thus keeping the config files intact is that correct ?
<ogra_> well, the rollback mchanism relies on the fact that the snaps are readonly blobs that do not change
<ogra_> config files are kept for the specific version of a snap
<ogra_> so when you roll back you actually go back to both, the old snap and the old config
<e^1> cool :)
<ogra_> a snap allwayskeeps two versions around
<e^1> old and new
<ogra_> right
<e^1> the same concept as git
<e^1> Directed Acyclic graphs :)
<ogra_> and since everything is a snap (kernel, rootfs, bootloader) this concept applies to everything in the system
<ogra_> (well, and app snaps too indeed)
<e^1> super cool
<e^1> ogra_: now i reallly very much interested to learn the complete process of packing ubuntu core, this  would unravel lot's of important info..
<ogra_> not really ... the magicis in snapd and in snapcraft really
<e^1> how each piece stick to each other and work, the version control thing..
<ogra_> it works exactly the same on any ubuntu 16.04 desktop or server ...
<e^1> ogra_: okay, let me first investigate snapd and snapcraft
<ogra_> just that ubuntu-core actually boots from the ubuntu-core snap instead of a classic riootfs
<e^1> ogra_: so this provides the advantage or rollback of even the older kernel  right ?
<e^1> s/or/of
<e^1> or booting older kernel
<ogra_> yes
<e^1> awesome
<ogra_> there is some logic in our bootloader scripts that will do that automatically
<ogra_> if the system gets a kernel panic on boot, it willl automatically roll back
<e^1> ogra_: are those opensource i.e. available on github ?
<ogra_> they are in llaunchpad
<ogra_> public, yes
<e^1> can you link me if possible ?
<ogra_> not easily ... i'm running an eyperimental unity8 here ... copy paste beween browser and irc client doesnt work atm :P
<ogra_> one sec
<ogra_> (yes, it is as painful as it sounds)
<e^1> hehe np, what the name of the repo ?
<ogra_> google for "launchpad snappy-hub snappy-systems"
<ogra_> the first hit should be the right one
<e^1> ogra_: https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems :)
<ogra_> right
<ogra_> these are the sources for the currennt gadget snaps
<ogra_> if you look at the snappy_boot variablein the uboot.env.in files you see the boot logic ...
<ogra_> that works hand in hand with snapd which takes over once the system is booted and sets the right variables in the bootloader to notify a successful boot
<e^1> yeah saw that file
<e^1> but right now that's only for dragonboard ?
<zyga> Pharaoh_Atem: replied
<zyga> Pharaoh_Atem: I think it is actually okay
<e^1> looks like ogra_ you are a core developer
<ogra_> e^1, nope
<e^1> contributor ?
<ogra_> (nope, not only for dragonboard)
<e^1> ohh ok :)
<ogra_> (yes, i'm responsible for the image builds ... )
<e^1> ogra_: than you can become my mentor :P in image build stuff :) ( i know it's not possible but still in my wildest dreams :) )
<ogra_> why wouldnt it :)
<ogra_> we appreciate all contributions ...
<e^1> super awesome :)
<e^1> give me HW to start with, like an assignment hehe
<ogra_> well, get a raspberry pi2
<e^1> will pi3 do, it's available right now on amazon
<ogra_> pi3 will do as well
<e^1> ordered pi3
<e^1> now ?
<ogra_> well, you wait i guess :)
<e^1> ogra_: once i get it let me know what i am suppose to do and will start with that..
<ogra_> yup
<e^1> cool :)
<e^1> thanks for todays useful info :)
<ogra_> np
<e^1> ordered a beautiful  case too
<e^1> ogra_: do i need to order any other stuff which will be useful ?
<ogra_> a serial cable for it
<e^1> okay
<e^1> ogra_: like this one ? http://www.amazon.in/Honey-House-USB-Serial-Cable/dp/B00PQMUBQK/ref=sr_1_1?ie=UTF8&qid=1469474224&sr=8-1&keywords=serial+cable+raspberry+pi2~
<ogra_> yes
<e^1> what will be this useful  for ?
<ogra_> if you want to tinker with the bootloader or initrd you need console access
<e^1> okay
<e^1> ogra_: are those cable specific for pi2  pi3 or pi1 ?
<ogra_> they are pretty unniversal
<e^1> okay, because i found some product listing written pi2 on it.. so i thought it's better to clear the confusion
<zyga> Pharaoh_Atem: are you and Son_Goku one person?
<Pharaoh_Atem> zyga: yes
<Pharaoh_Atem> zyga: Son_Goku is my laptop, while Pharaoh_Atem is my workplace workstation
<ogra_> thats confusing :)
<ogra_> (as someone talking to you)
<Pharaoh_Atem> the server I used to have for doing IRC stuff normally used Conan_Kudo
<Pharaoh_Atem> and my home desktop computer used King_InuYasha
<ogra_> oh m
<ogra_> y
<ogra_> and you expect people to memorize all these names to remember whom they talk to ?
<Pharaoh_Atem> nah
<Pharaoh_Atem> most of my other selves aren't really around anymore
<ogra_> well, it makes sustained conversations over multiple days quite hard
<Pharaoh_Atem> just Pharaoh_Atem and Son_Goku most of the time
<ogra_> k, 2 are handleable :)
<Pharaoh_Atem> I don't often talk much as Pharaoh_Atem, since it's just my workstation
<Pharaoh_Atem> usually I'm at work doing work things :)
<ogra_> i heard of that "work" thing before
<Pharaoh_Atem> but when people need to reach me, I'm always available (or at least able to respond later
<Pharaoh_Atem> )
 * ogra_ kind of got used to having a well paid hobby instead ... :D
<Pharaoh_Atem> unfortunately, most of us don't have one of those
<Pharaoh_Atem> and some of us have to work hard to keep work and things we like doing separate
<ogra_> well, doing your hobby as your job isnt that easy ... since it is really really hard to stop working then
<ogra_> look at zyga ... he is at a sprint, it is 10pm and he should sit in a bar with his colleagues ... instead he chats on IRC ;)
<e^1> ogra_: while ordering sd card should i get NOOBS preinstalled or anyway i need to format it to install snappy on it..
<Pharaoh_Atem> for me, it just means that I have to push out the time I get to do the stuff I want to do to even later at night
<ogra_> e^1, just any SD card will do
<Pharaoh_Atem> it's not uncommon for me to be working from when I leave work at around 7pm to about 1am
<e^1> ogra_: cool :)
<stokachu> i've got a snap built but hitting a problem with the binary, my setup.py uses the console-scripts entrypoint https://github.com/ubuntu/conjure-up/blob/master/setup.py#L21
<stokachu> how do i make that work with snaps?
<stokachu> http://paste.ubuntu.com/20912532/ thats my snapcraft.yaml
<ogra_> stokachu, does entry point refer to a service being up ?
<stokachu> ogra_: its just the resulting cli tool
<ogra_> but you refer to console-setup in the host system your snap runs on ?
<e^1> ogra_: done :) so we are going to install snappy on pi and learn building images ?
<e^1> just thinking where was i this many days, not ordering a pi :P
<stokachu> ogra_: yea
<stokachu> ogra_: i just want to translate python3 setup.py install that creates the bin/conjure-up in the snapcraft file
<ogra_> e^1, well, i need to write a porting documentation ... so we can exercise that you build all bits from scratch and i can take notes for the doc from a new-users perspective ;) ... note though that it will still be some days/weeks til the new image setup is ready
<Pharaoh_Atem> ogra_: zyga and I are going to wind up being close buddies for a long time :)
<ogra_> stokachu, well, thats tricky, you can ship console-setup in build-packages but thats only living inside your snap ... you wont actually get anything fro the host system without having an interface if you want any runtime stuff
<ogra_> Pharaoh_Atem, you doing a distro port with him ?
<Pharaoh_Atem> yep
<Pharaoh_Atem> we're working on the Fedora stuff
<ogra_> ah
<Pharaoh_Atem> and once Fedora is working, I'll be pulling it into Mageia
<ogra_> yay
<Pharaoh_Atem> and I'll be comaintainers with him in Fedora
<ogra_> bring it on !
<stokachu> ogra_: so i'd need to make a service on the host system in order to interact with it via the cli?
<stokachu> as its interface
<e^1> ogra_: cool :)
<ogra_> stokachu, your app will run in a sandbox ... to talk to the outside world you need to have an interface
<ogra_> one half of the interface is provided by the OS (and needs to be implemented there) ... the other has to be provided by you
<ogra_> stokachu, zyga is your man for details
<Pharaoh_Atem> though the snap system has some serious issues to resolve before we can get to that point
<stokachu> ok thanks
<ogra_> yo mean like selinux ?
<Pharaoh_Atem> selinux, snapcraft stuff, etc.
<ogra_> well
<ogra_> the only way to make snapcraft usable is to have a cross distro db to map package names
<Pharaoh_Atem> or do "on <distro:rel>" stanza
<ogra_> else snapcrafts idea of having one snapcraft.yaml you can use foor everything becomes pointless
<ogra_> uh
<Pharaoh_Atem> that will allow it to point to specific repositories no matter where it's being run from
<ogra_> but that would mean you need to do that for every build and stage package for all distros to get a universal snapcraft.yaml
<Pharaoh_Atem> no
<ogra_> ending up with multi page yaml files
<Pharaoh_Atem> it means that no matter what distro you use, it would ALWAYS use whatever you declared
<Pharaoh_Atem> so if I made a snapcraft.yaml that says the snap uses Fedora as a base, it will ALWAYS use Fedora, even if you build on an Ubuntu system
<Pharaoh_Atem> that's a much cleaner way to solve the problem
<ogra_> but that snp that someone built on an outdated debian system that missed all security updates now will always use the outdated libssl
<Pharaoh_Atem> and that's important
<ogra_> even if i re-build it on ubuntu
<Pharaoh_Atem> otherwise snaps are not reproducible
<Pharaoh_Atem> it would be utterly stupid if you can't make reproducible snaps
<ogra_> well, but then i cant just re-build it with a known safe system
<Pharaoh_Atem> so you're saying the snap author is incapable of being smart about this?
<Pharaoh_Atem> also, very rarely is the host environment a known safe system
<ogra_> the snap author is preferably an upstreaam who has no clue about packaging
<ogra_> nah, your cleanbuild env is ...
<ogra_> since it runs in a freshly pulled up container
<ogra_> snapcraft is a massive chance to get rid of app package management in distros ...
<ogra_> so that a distro developer team can concentrate on the core and save manpower
<ogra_> and that an upstream just has the most easy way to package his app without having to know distro internals
<ogra_> (beyond package dependency names indeed)
<ogra_> at least thats my vision
<e^1> ogra_: we can also install snappy on x86 and x64 systems right ?
<ogra_> sure
<Pharaoh_Atem> ogra_: as much as you want to think about it, it'll never happy
<Pharaoh_Atem> *happen
<Pharaoh_Atem> and it's arguable that it would be a good thing if it did
<ogra_> well, after ~15years in the linux business my biggest dream is that distros go away ... and drag all their political issues with tghem ;D and we can just all work together all the time
<Pharaoh_Atem> there have been many, many, many attempts
<ogra_> all of them failed ... but thats human nature i guess
<Pharaoh_Atem> hell, nearly a decade ago, Jeff Johnson actually suggested implementing deb management in rpm
<Pharaoh_Atem> when he forked rpm to create his rpm5, he actually did it
<ogra_> lol, i remember
<Pharaoh_Atem> there's literally no reason why we can't implement deb format in rpm.org and actually unify on a common package manager implementation for different formats
<Pharaoh_Atem> the fact that we don't is only because we can't get people to agree it's a good idea
<Pharaoh_Atem> as others have said, what makes up Debian, Fedora, Ubuntu, or whatnot isn't necessarily the tools, it's the policy and the people
<Pharaoh_Atem> there's literally no reason that we couldn't get everyone to use rpm (as LSB proposed a decade ago) and just implement the database/package support layer on top of it for the distros
<Pharaoh_Atem> and a translation mechanism to get everything working
<Pharaoh_Atem> ogra_: I held out hope for many, many years for that to happen
<Pharaoh_Atem> things like niemeyer's smartpm gave me hope it would happen, but it never did :(
<ogra_> yeah
<Pharaoh_Atem> if someone ever became interested in the idea again, I would definitely help out
<Pharaoh_Atem> but it seems like the walls have gotten higher over the years :(
<Pharaoh_Atem> it's been a hard battle to get Fedora and Mageia more in sync over the course of this last year
<Pharaoh_Atem> but we're getting there
<Pharaoh_Atem> and the two distros are fairly independent
<Pharaoh_Atem> the biggest irony about smartpm is that it only started becoming popular after niemeyer abandoned it
<Pharaoh_Atem> it's now used in yocto and is a rather popular alternative in pclos and several other distros
<ogra_> well, i effectively think debs and rpms are an anacronism, we still need them on a system level, but in the end, if you look at the world, there are more apk's installed than there are installed debs and rpms together so flatpack and/or snap are rather the future for apps imho
 * genii sips his coffee and ponders Click N Run
<ogra_> and the even more fun about snap and flatpak is that this battle is completely not fought/fightable by the distros .... in the end the format that upstreas pick is winning ... no matter what you or me want in $favourite_distro
<ogra_> *upstreams
<Son_Goku> ogra_, perhaps, but I think there's a place for package managers
<Son_Goku> we keep seeing them reinvented over and over again, often poorly
<ogra_> yes, in the distro
<ogra_> distros wont go away
<ogra_> but they should shrink a lot
<Son_Goku> that indicates that no matter how much people think we can get away from it, we're still going to need them
<ogra_> sure
<Son_Goku> arguably, they'll probably grow in usage rather than shrink
<ogra_> but a distro can become a way better maintained core of packages
<Son_Goku> and things like flatpaks/snaps/etc. will choose to use these as units to compose a software bundle
<ogra_> you need whatever your install needs, buuld deps, toolchains and such ... but thats it
<sergiusens> stgraber when you have time, can you pass me your snapcraft.yaml
<stgraber> sergiusens: http://paste.ubuntu.com/20924678/
<stgraber> sergiusens: still very much work in progress but it does at least get to the go part and fails
<stgraber> sergiusens: I'm trying with go-importpath now since that's probably the right way to get around my current error
<mup> PR snapcraft#684 closed: Run tests from /tmp <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/684>
<mup> PR snapcraft#685 opened: Release changelog for 2.13.2 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/685>
<stgraber> sergiusens: current is http://paste.ubuntu.com/20926345/
<stgraber> sergiusens: the problem I have now is that I need to set a bunch of env variables for golang to be happy, is there some key I can set in snapcraft.yaml to do that?
<stgraber> sergiusens: looking at our snappy 15 snap, I need to be able to set PKG_CONFIG_PATH, CGO_CFLAGS and CGO_LDFLAGS so I can have them point to where the lxc bits are
<stgraber> sergiusens: (and have those 3 env variables only be set while building the lxd part, not the lxc or lxcfs ones, so can't seem that globally in my env before calling snapcraft)
<sergiusens> stgraber not yet, you probably want to wait for the `build-environment` keyword for this, should be available next week
<sergiusens> stgraber ah, that makes things interesting; we should get together tomorrow
<sergiusens> I am too tired right now to think straight
<stgraber> sergiusens: do you have a branch for that already? Mark kinda said this morning that he'd like to see some progress on the lxd snap this week and that's kinda a blocker (I expected to run into problems with the security policy stuff, not with snapcraft) :)
<stgraber> sergiusens: I'm not going to be building stuff on Launchpad for probably a few more weeks and I'm running snapcraft in a container, so I can certainly run experimental code in there without any problem :)
<stgraber> sergiusens: anyway, we can chat tomorrow, I should get some sleep too
<sergiusens> stgraber I can crank up a branch
<stgraber> that'd be very helpful
<invapid> if you have a dependency that also needs to be installed from github
<invapid> is that easy to do?
<invapid> would that be under "parts"
<invapid> yes - got that squared away
<invapid> is there a way to select a specific commit hash or tag?
<invapid> "source-tag" kinda
<mup> Bug #1605080 opened: package snap (not installed) failed to install/upgrade: trying to overwrite '/usr/share/man/man1/snap.1.gz', which is also in package snapd 2.0.10 <amd64> <apport-package> <package-conflict> <xenial> <One Hundred Papercuts:Confirmed> <Snappy:Confirmed> <snap (Ubuntu):Invalid>
<mup> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1605080>
#snappy 2016-07-26
<liuxg> can anyone tell me why the "hello-world" example snap does not have the wrapper files after installation?
<liuxg> elopio, ping
<mup> Bug #1604964 opened: huge download for nothing - snap does not exist <Snappy:New> <https://launchpad.net/bugs/1604964>
<zyga> good morning
<e^1> good morning :)
<e^1> zyga: looks like you are closer to my TZ
 * e^1 reboots
<didrocks> good morning
<dholbach> hey hey
<zyga> Son_Goku: https://bugzilla.redhat.com/show_bug.cgi?id=1360199 :)
<lpotter> :)
<Son_Goku> zyga: check it again :)
<zyga> Son_Goku: I just saw, thank you :)
<zyga> Son_Goku: btw, you are up early ;)
<zyga> Son_Goku: are you jetlagged?
<Son_Goku> yep
<Son_Goku> my coworkers were all freaked because I was cheery as hell when I got in at 9am
<Son_Goku> because I'm usually more sour in the morning
<Son_Goku> looks like it'll be the same today...
<ogra_> lol, thats awesome !
<Son_Goku> zyga, I think I've addressed all the things I noticed in the ticket
<Son_Goku> so take a stab at resolving them, please :)
<zyga> Son_Goku: with pleasure
<Son_Goku> zyga, more feedbacks :)
<zyga> Son_Goku: THANK YOU, the feedback you get is immensly valuable
<zyga> Son_Goku: let me spend some time on iterating now
<zyga> Son_Goku: snap-confine is "easy" but the C conventions for packaging are a new thing there
<Son_Goku> :)
<dpm> hi Son_Goku, did you get back home allright? :)
<Son_Goku> yep
<dpm> excellent
<Son_Goku> â¬160 poorer due to emergency taxi to FRA, but managed it :)
<dpm> argh, glad you made it in any case
<Son_Goku> thank god I had the foresight to enable my credit cards in Europe
<Son_Goku> otherwise I would have been really screwed
<dpm> good thinking :)
<Son_Goku> only reason I needed to do it was because I woke up too late :/
<Son_Goku> I missed my shuttle and the next one would have been far too late
<Son_Goku> made it to the plane with 10 minutes left on the clock
<cking> hi there, how long does it take for a snap name registration to take to be reviewed? I've had one pending review since yesterday
<Son_Goku> I definitely enjoyed being in Germany for the sprint though
<Son_Goku> zyga, in regards to C conventions for packaging, at least for RPM based distros as long as you're using the correct macros, it should just "agree"
<Son_Goku> SUSE defines %_libexecdir as /usr/lib, while Mageia defines it as %_libdir
<Son_Goku> provided you pass the macro parameters to snapd, it should agree with snap-confine
<zyga> Son_Goku: I revertee back to just plain %configure for now
<zyga> Son_Goku: we can change it once it actually matters
<Son_Goku> right
<Son_Goku> afaik, plain %configure should define --libexecdir
<Son_Goku> then your autoconf stuff can just automatically install to the subdirectories it creates in %_libexecdir
<Son_Goku> yep, rpm -E %configure indicates as much
<sergiusens> cking registering snap names should be instant
<sergiusens> cking uploads of snaps can get blocked
<sergiusens> cking or did you claim a name
<cking> I claimed a name
<cking> and that's "pending review"
<cking> considering it's a package that I own anyhow in Debian and Ubuntu, I thought it would be trivially fast to get it reviewed and accepted
<noise][> cking: I can look into that for you, we are still ironing out processes around these things
<cking> noise][, ok, thanks!
<noise][> cking: approved!  sorry for the delay
<cking> thanks \o/
<stgraber> zyga: https://bugs.launchpad.net/snappy/+bug/1606510
<mup> Bug #1606510: Interfaces for LXD <Snappy:New> <https://launchpad.net/bugs/1606510>
<mup> PR snapd#1577 closed: daemon, cmd/snap: refresh --devmode <Reviewed> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1577>
<mup> Bug #1606510 opened: Interfaces for LXD <Snappy:New> <https://launchpad.net/bugs/1606510>
<hades|2> can i upgrade my ubuntu core 15.04 kernel to 16.04 ?
<hades|2> using ubuntu-core-upgrader ?
<hades|2> is it possible to use ubuntu-core-upgrader to upgrade an existing ubuntu-corehost using  an img file ?
<ogra_> hades|2, nope
<ogra_> hades|2, snapd manages upgrades of snap packages ... upgrading the system is just "snap refresh"
<ogra_> that will upgrade all snap packages including kernel and rootfs
<Chipaca> what is ubuntu-core-upgrader?
<ogra_> that package that carries do-release-upgrade
<ogra_> (update-manager for headless systems)
<hades|2> my host doesnt have snap refresh
<Chipaca> ogra_, is it anything to do with snap?
<ogra_> nope
<Chipaca> sigh
<ogra_> it is for classic installs
<hades|2> starting from 16.04 ?
<ogra_> Chipaca, would be trivial to make it call "snap refresh" at the end of the upgrade though :)
<ogra_> but i guess thats kind of pointless given snaps refresh themselves
<Chipaca> ogra_, 15.04 is so long ago, i'm pretty sure 'snap refresh' wasn't a thing then
<hades|2> what about old ubuntu-core based on vivid/15.04 , how to upgrade to 16.04 ?
<ogra_> oh, i missed the 15.04 part above
<ogra_> (just rebooted to switch my session to unity8 ... backklog slipped through)
<ogra_> hades|2, you cant
<Chipaca> hades|2, wait, are you asking about *snappy* ubuntu core, or classic ubuntu core?
<hades|2> snappy
<ogra_> the image setup has changed in incompatible ways
<Chipaca> and we don't have blessed core images yet anyway
<ogra_> (as has the snap format and other things)
<ogra_> right, there are no 16.04 images yet ...
<hades|2> ok thx
<ogra_> i assume that wont happen anymore though ... series 16 snap images should be upgradeable to series 18 snap installs later on
<ogra_> 15.04 was kind of special in that regard, nothing was really finalized back thn
<ogra_> *then
<mup> PR snapd#1580 closed: wrappers: set BAMF_DESKTOP_FILE_HINT for unity <Created by mvo5> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/1580>
<mup> PR snapd#1586 opened: wrappers: set BAMF_DESKTOP_FILE_HINT for unity <Created by chipaca> <https://github.com/snapcore/snapd/pull/1586>
<ogra_> uh... bamf ... thats still alive ?
<Chipaca> ogra_, as much as unit7 is
<Chipaca> :-)
<ogra_> heh
<hades|2> ill reflash a host using a series 16 img then
<Chipaca> ogra_, I think we do want to support 15.04->16 upgrades, but it's definitely not there yet
<Chipaca> hades|2, there are no official 16 core images yet
<ogra_> Chipaca, yeah, i was talking about 16->18 :)
<hades|2> so is it safe to keep my current snappy 15.04 host ?
<ogra_> until we announce official 16 series images you should better keep it, yeah
<hades|2> using snappy update / snap refresh i might be ablke later on to upgrade "safely" too ?
<Chipaca> hades|2, that is the plan as i understand it
<Chipaca> hades|2, no reverts of that refresh though
<Chipaca> hades|2, or in 15.04 parlance, no rollbacks of that upgrade
<Chipaca> *update
<Chipaca> :-)
<hades|2> it should be fine for me although
<kalikiana> Hrm. What is normally supposed to update snaps? Because of a blog post I "snap refresh"ed vlc, it evidently didn't update automatically. Am I missing some package for that?
<ogra_> nope, there is a system service (systemd timer) that does the automated snap refresh runs
<ogra_> not sure on what schedule that runs on classic installs though
<ogra_> Chipaca, might know
<mup> PR snapd#1529 closed: snap: rework the output after a snap operation <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1529>
<stokachu> sergiusens: could we invoke any parts this way before the npm install takes place? https://www.irccloud.com/pastebin/5m23iw2R/
<stokachu> the hook could be preinstall
<Cavan> I disconnected so I dont know if my messege sent (Sorry if It did): I still cant get Karaf to write to files, my wrapper is '#!/bin/sh set -e set -x  export KARAF_DATA="$SNAP_DATA" export KARAF_HOME="$SNAP"   mkdir -p "$KARAF_DATA/data/logs" mkdir -p "$KARAF_DATA/instances" if ! [ -d $KARAF_DATA/conf ]; then     cp -rd $KARAF_HOME/karaf-conf $KARAF_DATA/conf fi  LD_LIBRARY_PATH=$SNAP_LIBRARY_PATH:$LD_LIBRARY_PATH $KARAF_HOME/bin/karaf r
<ogra_> Cavan, $SNAP_DATA is not user writable, is that a service or a binary a user would execute ?
<ogra_> in case of the second you would have to use SNAP_USER_DATA
<ogra_> (also setting HOME to SNAP if your app tries to write to its home wont work, $SNAP is readonly)
<mup> PR snapd#1563 closed: Interfaces: hardware-observe <Created by cwayne18> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1563>
<Cavan> ogra_, So is this how it should be? 'export KARAF_DATA="$SNAP_USER_DATA" export KARAF_HOME="$SNAP_DATA"'
<ogra_> i would point both to SNAP_USER_DATA actually
<ogra_> if thats an enduser app that a user executes
<Cavan> ogra_, Im still getting 'mkdir: cannot create directory â/snap/karaf/x17/data/logâ: Read-only file system' any idea what I could do?
<ogra_> thats $SNAP
<ogra_> so whatever you use in that mkdir should point to $SNAP_USER_DATA
<ogra_> (and your config shoul point to that dir)
<mup> PR snapcraft#686 opened: Add missing dependencies <Created by cholcombe973> <https://github.com/snapcore/snapcraft/pull/686>
<Cavan> ogra_, so like this? export KARAF_DATA="$SNAP_USER_DATA" export KARAF_HOME="$SNAP_USER_DATA"   mkdir -p "$KARAF_DATA/data/logs" mkdir -p "$KARAF_DATA/instances"
<ogra_> yeah
<Cavan> ogra_, anychance you could check out my stack overflow quickly if I link it?
<ogra_> sure, just paste it on paste.ubuntu.com
<Cavan> ogra_, thanks http://paste.ubuntu.com/20997635/
<Cavan> ogra_, it hasnt been updated since you told me thye should both have SNAP_USER_DATA, so assume they're there
<ogra_> heh
<ogra_> i thoght you had a stak to look at, sorry
<ogra_> that wouldnt have needed a pastebin :)
<Cavan> Ah right aha, also I just noticed my wrapper is more up to date than that now 'set -e set -x  export KARAF_DATA="$SNAP_USER_DATA" export KARAF_HOME="$SNAP_USER_DATA"   mkdir -p "$KARAF_DATA/data/logs" mkdir -p "$KARAF_DATA/instances" if ! [ -d $KARAF_DATA/conf ]; then     cp -rd $KARAF_HOME/karaf-conf $KARAF_DATA/conf fi  LD_LIBRARY_PATH=$SNAP_LIBRARY_PATH:$LD_LIBRARY_PATH exec "$SNAP/bin/karaf" "$@"'
<mup> PR snapd#1587 opened: store: deal with 404 froms the SSO store properly <Created by mvo5> <https://github.com/snapcore/snapd/pull/1587>
<ogra_> Cavan, have a look at https://github.com/ogra1/jtiledownloader
<ogra_> that ships a wrapper script
<ogra_> (though this executes a jar )
<ogra_> so far your wrapper looks ok though
<ogra_> so what happens if you try to run it ?
<ogra_> zyga, uuuh, is the base snap still public in the store ? can you please unpublish it ?
<Cavan> ogra_, basically when I try to run the ./karaf I get
<Cavan> mkdir: cannot create directory â/snap/karaf/x18/data/logâ: Read-only file system WARN: can't update etc/config.properties with the generated command shutdown. We advise to manually add the karaf.shutdown.command property. Unable to update instance pid: Unable to create directory /snap/karaf/x18/instances /snap/karaf/x18/data/log/karaf.log (No such file or directory) Unable to update instance pid: Unable to create directory /snap/kar
<ogra_> when you run ./karaf ?
<ogra_> you mean you execute something inside $SNAP manually ?
<ogra_> that cant work
<ogra_> you need to use /snap/bin/karaf ... or just karaf ... (since /snap/bin should be in your PATH(
<Cavan> I go into the /bin and execute karaf? I thought you had to boot it the normal way after the snap is installed, in the directory of course
<ogra_> else you miss one layer of wrappers
<ogra_> well, try /snap/bin/karaf ... see what that does
<mup> PR snapd#1579 closed: snapstate: add daemon-reload to fix autopkgtest on yakkety <Reviewed> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1579>
<Cavan> ogra_, I get the same result
<ogra_> Cavan, well, the mkdir errors look like your wrapper has not been updated
<ogra_> the mkdir seems to still point to the wrong dir
<ogra_> Cavan, are you use the karaf binary actually uses these $KARAF_* vars at all ?
<ogra_> or does it just try to write to ./ by default
<ogra_> then you would need to add a "cd $SNAP_USER_DATA" to your wrapper before the exec line
<Cavan> ogra_, If i go into the bin folder there is a setenv file which has the '# export EXTRA_JAVA_OPTS # Additional JVM options # export KARAF_HOME # Karaf home folder # export KARAF_DATA # Karaf data folder # export KARAF_BASE # Karaf base folder # export KARAF_ETC  # Karaf etc  folder' so I assumed thye would be the binaries?
<ogra_> well, the binary doesnt seem to use the vars ...
<ogra_> try the cd ... that might work around it
<Cavan> ogra_, Okay, do I literally put it the line before the exec?
<ogra_> a line above the exec line, yes
<Cavan> ogra_, again same result. But for a test I ran the wrapper in /bin and I got '+ export KARAF_DATA= + export KARAF_HOME= + mkdir -p /data/logs mkdir: cannot create directory â/dataâ: Permission denied' If that is any help?
<ogra_> well, that is if you execute /snap/bin/karaf ?
<ogra_> (literally that string)
<Cavan> No, thats if I execute /snap/bin/wrapper
<ogra_> uh
<ogra_> dont
<ogra_> and how did wrapper get into /snap/bin ?
<ogra_> your wrapper should live inside your snap ... not in the /snap/bin system dir of your host system
<Cavan> When I've looked at online examples a few have created wrappers in the /bin, is that incorrect?
<ogra_> as i said before, when you install the snap there are more layers of wrappers added automatically
<ogra_> the top level wrapper (according to your snapcraft.yaml) will be /snap/bin/karaf
<ogra_> and only that is what you should ever execute
<mup> PR snapd#1582 closed: debian: move snapd.refresh.timer into timers.target <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1582>
<ogra_> do not exec anything in /snap/karaf/$version/ directly
<ogra_> that can not work
<Cavan> So where should I install the wrapper? Also to atempty to run karaf I go /snap/karaf/current/bin/karaf Should I not be doing that aswell?
<ogra_> you should install the wrapper where your snapcraft.yaml expects it
<ogra_> looking at your stackoverflow post it is all correct
<ogra_> just leave it like that
<ogra_> just dont try to runanything else but /snap/bin/karaf
<Cavan> If I do that I get this though '/snap/bin/karaf: No such file or directory'
<ogra_> that cant really be ... your snapcraft.yaml defines it
<ogra_> if you built your snap with that snapcraft yaml and snap installed it this commmand must be there
<Cavan> i'll install it again to make sure
<ogra_> oh
<ogra_> wait !
<Cavan> Okay
<ogra_> why do you define "daemon: simple"
<ogra_> thats for system daemons ... and will definitely not create the user binary in /snap/bin
<Cavan> What should I do instead?
<ogra_> but will instead create a systemd unit and install it
<ogra_> just drop that one line
<ogra_> and rebuild your snap
<ogra_> (unless indeed ... your app is actually a system daemon)
<ogra_> (but then you cant start it ... systemd will handle it)
<ogra_> s/start/run it as a user/
<Cavan> So I'm re-installing it back to my Stackoverflow post and dropping that one line correct?
<ogra_> yes
<ogra_> if karaf is actually something a user can run then thats the right way
<Cavan> ogra_, okay now I'm getting 'Error: Could not find or load main class org.apache.karaf.main.Main' when typing /snap/bin/karaf
<ogra_> you might need to set some app options then ...
<ogra_> you said something about EXTRA_JAVA_OPTS  above
<mup> Bug #1606574 opened: SSH Interface is missing <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1606574>
<ogra_> so whatever java needs (i'm really not a java specialist, i know how to make it exec a .jar ... thats about it)
<Cavan> should I get the MakeFile to install the .jar?
<ogra_> well, if you have a jar, just look at my jtiledownloader branch (linked above)
<ogra_> that should get you going
<Cavan> ogra_, thanks so much for your help, although you'll probably be hearing from me soon with another problem aha
<ogra_> heh, well, good luck for now
<Chipaca> jdstrand: on #1592696 I think you meant 16.04 not 14.04 :-)
<mup> Bug #1592696: snaps dont work with encrypted home: failed to create user data directory. errmsg: Permission denied <amd64> <apport-bug> <xenial> <snapd (Ubuntu):Invalid> <ubuntu-core-launcher (Ubuntu):Fix Released by jdstrand> <snapd (Ubuntu Xenial):Confirmed> <ubuntu-core-launcher (Ubuntu
<mup> Xenial):Incomplete> <https://launchpad.net/bugs/1592696>
<timothy> I think it's fixed on new snap-confine
<Chipaca> timothy: so do i :-) and jdstrand says as much in his latest update to that bug; i'm pointing out a typo in that comment, is all
<mup> PR snapd#1585 closed: store, daemon, client, cmd/snap, docs/rest.md: adieu search grammar <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1585>
<ogra_> hmm
<ogra_> so how do i access any packages owned by the shared store account now that it is locked
<ogra_> i know all packages were shared with me ...
<ogra_> but i dont see them in my myapps.d.u.c page
<zyga> ogra_: I cannot, I didn't publish it
<ogra_> zyga, crap ... and i cant see it and the shared account is locked down
<ogra_> zyga, is mvo anywhere near you ? he might know
<zyga> ogra_: I bet he did it
<ogra_> did what ? unpublish ?
<ogra_> i still find it with snap find
<Pharaoh_Atem> morning all
<ogra_> zyga, i'm happy to do the unpublishing if someone tells me how we access the shared packages now ... we all should be able to since heidelberg
<ogra_> but my myapps page simply doesnt show it
<mup> PR snapd#1588 opened: tests: added spread find private test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1588>
<mup> Bug #1605003 changed: cannot communicate with server - openSUSE Tumbleweed <Snappy:Invalid by zyga> <openSUSE:Confirmed for zyga> <https://launchpad.net/bugs/1605003>
<jdstrand> Chipaca: yes, thanks
<zyga> ogra_: I'm sorry, I don't know that; I never used the shared account
<ogra_> zyga, well ...
<zyga> jdstrand: hey, we will need to have snapd manage groups and users
<zyga> jdstrand: for the case of lxd
<zyga> jdstrand: so that ldx snap will be able to create the ldx socket that is not world writable
<zyga> jdstrand: I'm just letting you know
 * ogra_ vomits 
<ogra_> so mvo tied all the shared packages to ogra@canonical.com ... which is not assigned to my U1 account at all
<Pharaoh_Atem> O.o
<ogra_> trying to add the new address to U1 while being in a unity8 session breaks because launchpad is to dumb to show me the capcha !!!
<ogra_> (it considers the webbrowser appp as not capable to use captchas ... sigh)
<ogra_> so silly
 * Pharaoh_Atem sighs
<Pharaoh_Atem> zyga: looks like F25 branching is starting
<Pharaoh_Atem> you accidentally don't have F25 commit power: https://admin.fedoraproject.org/pkgdb/package/rpms/golang-github-mvo5-goconfigparser/
 * Pharaoh_Atem sighs
<Pharaoh_Atem> time to prepare for messages about my entire world branching for F25...
<chile> hi snappers
<Cavan> orga_, How would I extract org.apache.karaf.main-4.0.5.jar fromthe make file, when I try it just places the file instead of extracting it
<sergiusens> ogra_ heh, oSoMoN has a bug for that already
<ogra_> great
<ogra_> hmpf ... so i see a "core" package that was shared with all of us ... but there is no "base" package anywhere
<ogra_> and that core package is also unpublished properly
<ogra_> MVOOOOO !!!
<ogra_> Cavan, well, you dont want to extract it ... look at my jtiledownloader snap
<ogra_> (i gave you the github url above)
<ogra_> just copy the exec line and replace my jar with yours in there
<jdstrand> zyga: I saw that. note that in 15.04 what we did instead as a quick workaround was to add the lxd group to the system
<jdstrand> zyga: tyhicks and I should be involved in the designs surrounding adding groups to the system via snaps
<ogra_> uh
<jdstrand> zyga: and possibly a memnber of foundations (slangasek or someone he assigns)
<ogra_> adding system groups sounds slightly scary with libnss-extrausers in place and using a readonly /etc/groups
<ogra_> (how do you make sure the GID doesnt clash if somme package added the same GID to the readonly side at core snap build time)
<ogra_> (it would just come with the next oos snap update)
<ogra_> *os
<jdstrand> it indeed sounds scary since it would be easy for a snap to pick a group to add (eg, 'ogra')
<ogra_> well, not only that
<ogra_> you dont know what comes down the drain from the store
<jdstrand> so maybe it wouldn't be arbitrary groups, but rather, the snappy interface says (ok, we'll set up this group)
<ogra_> so you cant really predict if a GID will clash
<Pharaoh_Atem> ogra_: mvo isn't even here, so he can't really hear you.... :/
<ogra_> Pharaoh_Atem, there are enough people at his sprint ... i guess he is stuck in some session ;)
 * Pharaoh_Atem shrugs
 * ogra_ relies on mouth propaganda with that one ;) 
<chile> any body
<chile> with some idea on native apps in jquery+php+html experience
<ogra_> jdstrand, well, i guess we'd need to define some range that cant get touched by image builds ... iirc we already define that system groups have to be below 1000 ... so we'd need a range ... say 1000-2000 that gets reserved for extra groups ... and make sure that user accounts only get created from 2000 onwards ... or something like that
<ogra_> but thats fiddly to implement for sure
<chile> any body with ubuntu cloud here
<zyga> Pharaoh_Atem: hey
<zyga> Pharaoh_Atem: why do you have two IRC nicknames
<Pharaoh_Atem> zyga: yo
<Pharaoh_Atem> this self is my workstation at work
<Pharaoh_Atem> my other self (Son_Goku) is my laptop
<zyga> Pharaoh_Atem: I've updated the snap-confine.spec
<zyga> Pharaoh_Atem: pushed updates to fedorapeople
<Pharaoh_Atem> this guy is persistent, the other one shows up when I'm away :)
<zyga> Pharaoh_Atem: magic :)
<zyga> Pharaoh_Atem: should I just indicate the changes on the bug report?
<Pharaoh_Atem> yes
<Pharaoh_Atem> always do that, as it's for the benefit of me, you, and others potentially watching
<zyga> Pharaoh_Atem: you can also check what I did by looking at github (for all the real details)
<zyga> ok, will do
<Pharaoh_Atem> right
<zyga> Pharaoh_Atem: I could use a hint that tells me how to do a fedkpg build against something from koji (the gopkg.in/check.v1 thing)
<Pharaoh_Atem> you need to create the buildroot override
<Pharaoh_Atem> https://fedoraproject.org/wiki/Package_update_HOWTO#Updating_inter-dependent_packages
<Pharaoh_Atem> it would automatically be in effect for builds you do from your user with koji (via fedpkg)
<Pharaoh_Atem> you should be able to build from F25 and Rawhide with no problems, though
<Pharaoh_Atem> since both will have check in there already
<elopio> stevebiscuit: why don't you ship your patched go plugin in snapweb in parts/plugin/x-go.py ?
<elopio> that way we don't have to wait for a new release.
<Pharaoh_Atem> zyga: I've approved snap-confine
<zyga> Pharaoh_Atem: I'll do the change to the remaining two pkgconfig files
<zyga> Pharaoh_Atem: I'm somewhat exhausted by the sprint and I'm very glad and I very much appreciate your detailed review
<stevebiscuit> elopio: that's an option, I'd already mentioned godeps to kyrofa and he created the bug on LP
<Pharaoh_Atem> zyga: that's why we do these in Fedora :)
<Pharaoh_Atem> one more set of eyes tends to help at times
<zyga> Pharaoh_Atem: I hope to get more so that we can have a day off sometime ;)
<zyga> Pharaoh_Atem: I'll work on fedpkg builds now
<zyga> Pharaoh_Atem: but it does look like we are down to snapd now :)
<zyga> Pharaoh_Atem: I didn't check go-flags yet, is the update also going to f23+?
<Pharaoh_Atem> yes
<Pharaoh_Atem> it's going everywhere
<zyga> that's good then
<zyga> We had a release just now, 2.11 :)
<Pharaoh_Atem> zyga: https://bodhi.fedoraproject.org/updates/?packages=golang-github-jessevdk-go-flags
<zyga> I'll do COPR but I'm super happy I will be moving closer to fedora :)
<Pharaoh_Atem> you can try out those packages and see if they work
<zyga> Pharaoh_Atem: nice, I see
<Pharaoh_Atem> and leave feedback :)
<zyga> Pharaoh_Atem: yes, I will download them
<zyga> Pharaoh_Atem: is there a better way rather than just to get them from bodhi?
<zyga> Pharaoh_Atem: I will build against it in my local repo
<Pharaoh_Atem> http://koji.fedoraproject.org/koji/packageinfo?packageID=20509
<Pharaoh_Atem> you grab them from Koji
<Pharaoh_Atem> looks like an override is already in place for go-flags
<Pharaoh_Atem> it might "Just Work"
 * Pharaoh_Atem shrugs
<ahoneybun> tsimonq2, heard of KDE Connect?
<tsimonq2> ahoneybun: no clue what it is
<ahoneybun> you can send and recieve files between phone and PC
<ahoneybun> also control mouse and keyboard
<ahoneybun> it pulls a lot in from KDE in Libs
<ahoneybun> so it would be cool to snap it
<Cavan> ogra, I did exec $SNAP/org.apache.karaf.main-4.0.5.jar (Which I'm hoping is what you meant before) and I keep getting '/snap/karaf/x23/org.apache.karaf.main-4.0.5.jar: 1: /snap/karaf/x23/org.apache.karaf.main-4.0.5.jar: Syntax error: word unexpected (expecting ")")''  '
<qengho> ogra_: WAT
<qengho> I mean, not ogra_.
<qengho> Cavan: That is very very wrong.
<Cavan> qengho, which part, the exec?
<Cavan> or the return im getting from the terminal?
<qengho> Cavan: A jar file is a kind of zipfile that is specific to Java. You can't ask the linux kernel to just execute it. It's not a java virtual machine.
<qengho> Cavan: So, "exec jarfile" is wrong.
<qengho> Cavan: you probably want to read up on what to do with the jarfile, and how one runs karaf. It's joing to have something to do with the program "java", though.
<Cavan> qengho, Yeah I figured, I'm trying to figure out where its meant to go, ogra gave me fantasic advice earlier but im to terrible at this to figure it out aha
<qengho> Cavan: I am guessing you should have in your snapcraft "command: wrappernamesomethingyouinvented", and in your wrapper, a shell script, you set up some variables and execute  java -Dhomesomethingsomething -classpath $SNAP/something jarfilesomething classnametobootstrap
<qengho> Cavan: stop with the snap part for a while. Figure out how you run that. Once you have a firm grasp how it NORMALLY starts up, come put those commands in a snap.
<mup> PR snapd#1581 closed: asserts: remove/disable comma separated lists and their uses <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1581>
<qengho> Cavan: You only have problems that have nothing to do with snappy so far. We're going to be terrible at answering those. :(
<Cavan> qengho, ah thats fair enough, I'll give it a good go aha, thanks!
<qengho> Cavan: We'd love to help. Don't be shy about questions, but realize I have never even heard of karaf before your questions.
 * qengho Zzzz
<ogra_> Cavan, https://github.com/ubuntu/snappy-playpen/blob/master/jtiledownloader/launcher
<ogra_> Cavan, see the last line
<ogra_> you want that
<ogra_> (indeed with a path to *your* .jar
<ogra_> )
<zyga> Pharaoh_Atem: so what is the "there might be more..." comment about
<zyga> Pharaoh_Atem: is there anything I should fix in snap-confine packaging?
<Pharaoh_Atem> forgot to run fedora-review
<Pharaoh_Atem> it has a checklist of things
<zyga> oh, I will do it
<zyga> thank you
<zyga> Pharaoh_Atem: I must say fedora-review -n seems to assume SRPMs are in ~/rpmbuild/SPECS which is odd, I'll try it with the bug number
<Pharaoh_Atem> zyga: I have to run it, and I posted the results in the bug
<Pharaoh_Atem> though it's useful for you to do while crafting the spec
<zyga> Pharaoh_Atem: I have a call now, I'll review it after that
<Pharaoh_Atem> okay
<zyga> I just saw the report, very useful!
<Pharaoh_Atem> zyga: yeah, unfortunately I can't run it for golang stuff because it throws too many errors to be useful
<Pharaoh_Atem> but it's a good blueprint regardless
<Pharaoh_Atem> we make too many exceptions for golang that we do reviews for those differently
<kyrofa> elopio, stevebiscuit indeed, sorry for moving slowly on the godeps plugin. I actually have one locally, but I need to clean it up and push. There were some things that needed to happen before then, but Fridays are my only snapcraft days currently so things take a sad amount of time
<stevebiscuit> kyrofa, elopio: grand, I'll remind you about it during Friday's standup ;)
<wililupy> Are there plans to have a docker snap?
<mhall119> zyga: how do give a snap access to certain hardware?
<mhall119> I'm getting Log: apparmor="ALLOWED" operation="open" profile="snap.arduino.arduino" name="/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/serial" pid=18376 comm="java" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<mhall119> File: /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/serial (read)
<mhall119> Suggestion:
<mhall119> * use gadget hardware assign to access '/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/serial'
<mhall119> also in the arduino IDE: can't open device "/dev/ttyACM0"; Permission denied
<ahoneybun> mm I'm wondering about getting code from git
<ahoneybun> mhall119, I'm thinking about making a snap on KDEConnect
<jdstrand> mhall119: I think you want to use the serial-port interface
<jdstrand> mhall119: you might be the first user of that interface so please file 'snapd-interface' bugs if you see them
<Dubstar_04> Is there anynew on a fix for running OpenGL snaps on Nvidia systems?
<Dubstar_04> *news
<timothy> Dubstar_04: for example? on which distro? with nvidia or nouveau?
<Dubstar_04> timothy: I'm on 16.04, snaps work with nouveau but no with Nvidia.
<Dubstar_04> this is the output: http://paste.ubuntu.com/21041858/
<timothy> using the snap-confine from proposed worked to me
<ahoneybun> mm franz does not want to launch as a snap
<ahoneybun> tsimonq2, ^
<Croepha> so, on the ubuntu site, it says that Snappy uses delta's to reduce bandwidth, how does that work? like does it use vcdiff? does the server have all the diffs handy?
<timothy> iirc it's need to be re-added
<Croepha> timothy, the functionality was there, but isn't now
<Croepha> ?
<timothy> Croepha: http://askubuntu.com/a/789634
<Croepha> timothy: thanks
<Dubstar_04> timothy: i have installed that. now I am getting: multiple nvidia drivers detected, this is not supported
<timothy> maybe you have multiple nvidia drivers installed?
<Dubstar_04> Umm, I have been switching between nouveau and nvidia while testing snaps. maybe something got messed up.
<ahoneybun> let's try this again
<mhall119> jdstrand: is serial-port interface in snapd on xenial?
<mhall119> because I don't see it in `snap interfaces`
<jdstrand> mhall119: it is and has been for a long time. I'm not sure why it doesn't show up. that may be one of the bugs (it was implemented a very long time ago)
<Croepha> if I deployed with 16/rolling/edge would there be a clear upgrade path once 16 comes out as stable? without having to reflash?
<mhall119> jdstrand: where do I file bugs for it? has that moved to github too?
<jdstrand> bugs are still LP
<mhall119> jdstrand: lp:snappy ?
<jdstrand> https://bugs.launchpad.net/snappy/+filebug
<ahoneybun> could anyone look at these errors http://pastebin.ubuntu.com/21044760/
<jdstrand> add the 'snapd-interface' tag
<ahoneybun> it's complaining about gtk but I have desktop gtk in the yaml
<Dubstar_04> timothy: I only have one nvidia driver installed
<ahoneybun> yaml: http://pastebin.ubuntu.com/21044876/
<jdstrand> mhall119: a super-cursory reading of the test code indicates that slot implementation should define the serial ports and then you would plugs what it exports. that doesn't sound like it will do what you are looking for since classic and the os snap don't do any of that atm
<jdstrand> s/test code/serial_port*.go code/
<jdstrand> I think this was implemented thinking a gadget snap would 'slots: ...' and then snaps would plug into that
<jdstrand> (which would make sense)
<jdstrand> and/or the os/core snap would auto-detect these ports and supply implied slots
<jdstrand> (which would also make sense)
<jdstrand> but that today, there is no gadget snap on classic and snapd is not detecting the serial ports to provide an implied slot
<jdstrand> I *think* the hooks work may in part be for this sort of thing, but would need zyga to confirm
<mup> Bug #1606674 opened: Unable to drive Adruino over USB from Arduino IDE snap <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1606674>
<mhall119> jdstrand: https://bugs.launchpad.net/snappy/+bug/1606674
<mup> Bug #1606674: Unable to drive Adruino over USB from Arduino IDE snap <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1606674>
<jdstrand> I see that, thanks
<jdstrand> zyga, can you take a look at bug #1606674 when you have a moment?
<mhall119> otherwise my arduino IDE snap is fully functional
<mhall119> with the exception of being able to, you know. function :)
<jdstrand> that interface is absolutely what you should be using
<timothy> mhall119: I think you can access /dev/ttyACM0 without using snap :P
<jdstrand> but I think the implementation hasn't been revisited since classic was a focus and other things got prioritized over the gadget/all snaps finishing touches
<jdstrand> timothy: well, he can also use --devmode
<timothy> "However, it is unable to access the board, even in devmode."
<jdstrand> ah, I didn't read the bug yet. that is weird
<jdstrand> mhall119: what are the permissions on /dev/ttyACM0 ?
<jdstrand> mhall119: I suspect devmode isn't working right cause of that. /dev is listed as a source mount in snap-confine, so that shouldn't be it (are you using snap-confine from proposed?)
<jdstrand> mhall119: is the output the same regardless of if you are in devmode or not or is the output different? if different, you should list that in the bug. I suspect there are two different bugs
<timothy> mhall119: can you do an ls /dev/ttyACM0? maybe it's using some acl, that you can see with getfacl /dev/ttyACM0
<timothy> ls -l*
<mhall119> jdstrand: from within the snap, or normally?
<mhall119> crw-rw---- 1 root dialout 166, 0 Jul 26 14:15 /dev/ttyACM0
<mhall119> oh, hangon, I seem to recall needing to make my user part of the dialout group to use the arduino ide
<timothy> yes, you need dialout group
<timothy> sudo gpasswd -a $USER dialout
<jdstrand> right
<jdstrand> so that should make it work in devmode
<timothy> yep
<jdstrand> (please comment in the bug if it does)
<timothy> ofc you need to reload or to do su - $USER
<mhall119> sure enough, getting into the dialout group lets it work in --devmode
<ahoneybun> tsimonq2, did you see the links?
<tsimonq2> ahoneybun: what links?
<ahoneybun> I'm trying to work on Franz snap anyway
<ahoneybun> getting some gtk errors when running it
<mup> Bug #1574114 opened: snapd should not conflic with mediaplayer snappy <amd64> <apport-bug> <xenial> <One Hundred Papercuts:Confirmed for mvo> <Snappy:Confirmed> <snapd (Ubuntu):Confirmed for mvo> <https://launchpad.net/bugs/1574114>
<ahoneybun> this darn connection today is back
<timothy> let's try apparmor with confinement on archlinux with nvidia drivers :)
<timothy> s/apparmor/snap/
<Dubstar_04> Anyone using snappy with Nvidia cards?
<Dubstar_04> I have purged all nvidia drivers and I still get this message: http://paste.ubuntu.com/21048959/
<timothy> Dubstar_04:
<timothy> ls /usr/lib/nvidia-[1-9][0-9][0-9]
<Dubstar_04> timothy: how do i remove those?
<timothy> did you installed those by installing the driver by hand?
<Dubstar_04> http://paste.ubuntu.com/21049367/
<Dubstar_04> I have only ever installed through ubuntu drivers, I think
<Dubstar_04> can i just rm -rf /usr/lib/nvidia*
<timothy> dpkg -S /usr/lib/nvidia-346/libnvidia-fbc.so.1
<dz0ny> Dubstar_04: purge will not help since it rewrites gl load paths
<Dubstar_04> Its working!!!
<Dubstar_04> timothy: thanks!!
<Dubstar_04> My snap works at last!!
<timothy> you're welcome, you are like I studied snap-confine last week :P
<timothy> lucky*
<ahoneybun> Dubstar_04, I have NVIDIA but it's using the Intel atm
<ahoneybun> I'm just trying snaps today
<ahoneybun> first time working with snapcraft lol
<Dubstar_04> I might try and reboot and reinstall nvidia drivers before i get too excited...
<ahoneybun> I have Intel and NVIDIA
<ahoneybun> but I have not install the driver for the Nivida
<mup> PR snapd#1589 opened: interfaces: miscelleneous policy updates for default, mount-observe, opengl and unity7 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1589>
<Dubstar_04> Are there snap channels, like alpha, beta, stable?
<timothy> http://snapcraft.io/ search for channels
<Dubstar_04> timothy: perfect, thanks.
<timothy> Dubstar_04: works?
<Dubstar_04> I switched back to Nvidia drivers and i'm still getting the opengl errors
<Dubstar_04> :(
<timothy> sorry I have to go
<mhall119> sergiusens: you around?
<mup> PR snapcraft#687 opened: Enable integration tests to run in the production store <Created by elopio> <https://github.com/snapcore/snapcraft/pull/687>
<mup> PR snapcraft#688 opened: Strip common path prefixes from linkname as well as name when extracting a tarfile <Created by mhall119> <https://github.com/snapcore/snapcraft/pull/688>
<ahoneybun> wonders
<mup> PR snapd#1590 opened: interfaces: add process-control interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1590>
<thurston> I'm getting this error in my Snap package:
<thurston> X Error: BadValue
<thurston> Request Major code 154 (GLX)
<thurston> Request Minor code 3 ()
<thurston> Value 0x0
<thurston> Error Serial #23
<thurston> Current Serial #24
<thurston> any help?
#snappy 2016-07-27
<Trevinho> thurston: mhmh, you need to get something more by using XGetErrorText
<thurston> i'll check that out thanks
<Trevinho> thurston: in case, you can still avoid the crash by using the trapping...
<Trevinho> thurston: for example, something like https://code.launchpad.net/~3v1n0/bamf/trap-x-errors/+merge/192980
<thurston> for the record,  i'm only getting this error when running from the snap installed on my system.   my own executable binary runs just dandy on just about every system i've tried it on
<mup> PR snapd#1584 closed: asserts: introduce new parseHeaders <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1584>
<mup> Bug #1583250 opened: upstream use of build-time defined DATADIR incompatible with snaps relocation <snap-desktop-issue> <Snapcraft:New> <Snappy:New> <snapcraft (Ubuntu):Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1583250>
<mup> PR snapcraft#550 closed: Add python package dependencies to setup.py <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/550>
<balloons> "There has been a problem while analyzing the snap, check the snap and try to push again."
<balloons> Anyone have insights into why I may be seeing this error? The snap itself installs and runs fine
<ogra_> balloons, when do you see that ?
<mwhudson> is it possible to run an all-snap / ubuntu core image in lxd?
<mup> PR snapcraft#579 closed: Add new plugin: rust <Created by mariogrip> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/579>
<ogra_> think about the technology ....
<balloons> ogra_, sorry. Trying to push my snap. snapcraft push *.snap
<ogra_> mwhudson, the main bits of preparing the rootfs happen in the initrd ...
<mwhudson> ogra_: heh fair enough
<ogra_> mwhudson, kvm is fine though
<mwhudson> then i guess i want something as easy to use as lxd but using kvm underneath
<mwhudson> i hate qemu's command line with a burning passion
<mwhudson> and i'm not massively keener on libvirt
<mup> PR snapcraft#685 closed: Release changelog for 2.13.2 <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/685>
<ogra_> mwhudson, kvm -m 512 -redir :8022::22 /path/to/img
<ogra_> let it boot ...
<ogra_> then: ssh -p 8022 ubuntu@localhost
<mwhudson> oh it's that easy?
<ogra_> if you feel like, put -nographics in the cmdline
<ogra_> yeah
<ogra_> note that you need to define the -m option (no idea why there is no sane default)
<mup> Bug #1606813 opened: create-user gives nonsensical error when passed invalid email address <Snappy:New> <https://launchpad.net/bugs/1606813>
<mup> Bug #1606815 opened: create-user leaves new user's .ssh owned by root <Snappy:New> <https://launchpad.net/bugs/1606815>
<imexil> Hi, I'm trying to find the repository with some example snap yaml files. I've heard popey talking about it on the podcast but I just can't remember the name of that github place.
<sergiusens> balloons you will get an email from the store with the link to request a review
<balloons> sergiusens, I don't have any mails
<trijntje> imexil: snappy playpen probably
<imexil> trijntje: yes that's it! Thanks.
<trijntje> https://github.com/ubuntu-core/snapcraft/tree/master/demos
<trijntje> https://github.com/ubuntu/snappy-playpen
<mwhudson> ogra_: where has http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/ gone?
<ogra_> mwhudson, deleted on "upper mgmt" request
<mwhudson> ogra_: so i get to roll my own?
<ogra_> mwhudson, https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/ still has the snaps
<mwhudson> ah ok
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/ should only have the resulting img files once ubuntu-image is ready
<mwhudson> wait
<mwhudson> how do i actually download the snap from this page?
<ogra_> you click on "Successfully built" for the arch you want
<mwhudson> the largest 'built file' for amd64 is 15kb
<ogra_> oh, crap ... looks like they got deleted
<ogra_> they were next to the manifest files
<mwhudson> hooray
<ogra_> https://code.launchpad.net/~ogra/+snap/os-snap-test has the latest builds but they are still haunted by bug 1605903
<mup> Bug #1605903: "type: os" should prevent stage and prime stages from mangling content <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1605903>
<ogra_> you could grab them from there, unsquashfs them and make /home/ubuntu owned by UID 1000 ... then just call snapcraft snap squashfs-root to re-squash them
<drizztbsd> hi, is mvo5 here?
<ogra_> drizztbsd, he is at a sprint and probably busy in real-life, so i wouldnt expect him much around this week
<mwhudson> ogra_: alternatively is there some way i can run live-build locally and have it install this one extra package as part of the build?
<drizztbsd> ogra_: so maybe you can answer :P yesterday he tagged snapd 2.11, but last version was 2.0.11 and the new tag is not signed
<drizztbsd> is it a new versioning scheme?
<drizztbsd> wrt https://github.com/snapcore/snapd/releases/tag/2.11
<mwhudson> uh this involves a private ppa, never mind!
<ogra_> mwhudson, push your package to a PPA ... bzr branch lp:~ogra/+junk/os-snap-test ... then add your PPA to ENV in the Makefile ... and call snapcraft in the toplevel dir
<ogra_> oh, your package is private ?
<mwhudson> yeah
<ogra_> well, then the good old ... unsquashfs ... mount /proc and /sys ... chroot and dpkg -i will help ... afterwards just "snapcraft snap squashfs-root" again
<mwhudson> yeah
<tempuser> hi
<tempuser> can anyone lend me a hand with building a snap package? I'm growing wrestless as I don't have much experience with python language and I need to build a package for a python2
<tempuser> I'm getting parts/cumulus/install/usr/bin/pip2': [Errno 2] No such file or directory
<tempuser> is anyone seeing what I'm writing btw?
<dholbach> yes
<tempuser> ok, thanks
<trijntje> tempuser: can you post your snapcraft.yaml file?
<dholbach> did you try running "snapcraft clean" and then trying again?
<tempuser> yup
<dholbach> it's http://askubuntu.com/questions/801388/how-do-you-build-a-python-application-using-snapcraft
<dholbach> right?
<joc_> Does anyone know when the parts service will be updated to snapcraft 2.13.1 (which i see has been SRUed)? It also seems to have not run for a couple of hours.
<tempuser_> sorry disconnected
<dholbach> it's http://askubuntu.com/questions/801388/how-do-you-build-a-python-application-using-snapcraft
<tempuser_> wireless randomly disconnects
<dholbach> right?
<tempuser_> yes
<tempuser_> it is
<dholbach> ok
<dholbach> trijntje, ^
<Son_Goku> morning all
<tempuser_> I actually didnt done a clean after chaning the yaml, i'll do it now and come back
<dholbach> cool
<tempuser_> nope, same issue
<tempuser_> in the directory indeed pip2 is missing I have pip / pip3 / pip3.5
<dholbach> mh, that's weird
<Spads> Is there a good way to make the autotools plugin cd into a subdir of the source archive before running?
<trijntje> tempuser_: you might want to use pip directly, instead of git
<trijntje> tempuser_: like this http://pastebin.com/V79SGYJX
<trijntje> it will use pip to get the specified packages
<Spads> I tried using source-subdir: to limit to a subdir, but that actually REMOVED all the essential stuff that was a parent of that
<tempuser_> I see
<tempuser_> ok I'll give it a shot :)
<mup> PR snapcraft#660 closed: Fix python2 compile cache removal <Created by SamYaple> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/660>
<Spads> I just filed https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1606833 after looking at the plugin source and coming to the conclusion that there's nothing to do this
<mup> Bug #1606833: Need to build from subdir of source without removing rest of repo <amd64> <apport-bug> <xenial> <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1606833>
<ogra_> Spads, well, worst case you could use the make plugin and have a toplevel Makefile from where you call the autofoo commands and then cd into the right dir
<ogra_> as a workaround
<Spads> ogra_: how do I "have" that makefile?  It's an upstream source archive
<ogra_> you have it next to your snapcraft.yaml
<Spads> Hm, and I do something to copy it into the source thing?
<ogra_> this is my build of the debian upstream git tree of approx: https://github.com/ogra1/packageproxy/blob/master/Makefile
<Spads> hm
<Spads> so I replace EVERYTHINg with this makefile?
<ogra_> you could as well just run *any* command in such a makefile
<Spads> like, why didn't you keep sources in the snapcraft.yaml?
<Spads> ah, source .
<ogra_> because then the local makefile is ignored
<Spads> yikes
<ogra_> but effectively you can always use a makefile like a script
<Spads> okay thanks that's a good workaround
<Spads> but I suspect that's not the way they'd want to do this in future âº
<ogra_> indeed, fixing your bug is the right thing long term
<Spads> ðªð¸
<ogra_> but til thats there you can use other ways to roll your snap ;)
<Spads> yep thanks
<ogra_> (the makefile thing is really nice if you need to apply extra patches and dont want to maintain a whole forked git tree btw ... )
<Spads> yeah saw that
<Spads> heh
<mwhudson> ogra_: so i unsquashed your rootfs, ran enable.sh and then apt update did this:
<mwhudson> 0% [1 InRelease gpgv 94.5 kB] [2 InRelease 43.1 kB/247 kB 17%]Couldn't create tempfiles for splitting up /var/lib/apt/lists/partial/security.ubuntu.com_ubuntu_dists_xenial-security_IErr:1 http://security.ubuntu.com/ubuntu xenial-security InRelease
<mwhudson>   Could not execute 'apt-key' to verify signature (is gnupg installed?)
<ogra_> mwhudson, oh, did you copy a working resolv.conf in place ?
<mwhudson> ogra_: yes
<ogra_> hmm
<mwhudson> not before something else broke, of course :-)
<mwhudson> ogra_: strace from outside sez 20661 open("/tmp/apt.sig.VSyu5J", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
<mwhudson> ogra_: which doesn't make masses of sense
<ogra_> check the permissions of tmp
<mup> PR snapd#1591 opened: spread.yml, .travis.yml: read store credentials from environment and pass them encrypted to travis <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1591>
<ogra_> it does in the light of Bug #1605903
<mup> Bug #1605903: "type: os" should prevent stage and prime stages from mangling content <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1605903>
<mwhudson> oh hehe
<mwhudson> drwxr-xr-x 2 root root 4096 Jul 27 10:00 /tmp
<ogra_> yeh :/
 * mwhudson tries to remember what chmod flags he needs
<ogra_> i hope i can get some help from the snapcrafters soon to get this fixed
<mwhudson> yeah, that's an ugly one
<ogra_> and probably easy to fix if you know the code (just skip ebverything but the copy) but i cant really find my way around the prime stage code
<Spads> Ah!
<Spads> Okay, it looks like I just had some noise in there
<Spads> source-subdir: does indeed dow hat I want
<ogra_> ha
<Spads> are there any good examples of passing include/lib dirs from one part as args to another part?
<Spads> I'm mostly thinking about how I refer to the directory
<Spads> I mean I could do a lot of ../../../.. stuff, but...
<mup> PR snapd#1457 closed:  snapstate: drop revisions after "current" on refresh <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1457>
 * Spads links a snapcraft.yaml from his bug to illustrate
<Odd_Bloke> I'm looking at snapping something which ships scripts containing underscores; snapcraft won't parse my snapcraft.yaml if I use them in application names.
<Odd_Bloke> Is this expected behaviour, or should I file a bug?
<mwhudson> so...
<Chipaca> Odd_Bloke, "^[a-zA-Z0-9](?:-?[a-zA-Z0-9])*$"
<Chipaca> Odd_Bloke, valid app names match that
<mwhudson> i have this service that runs on first boot
<Chipaca> Odd_Bloke, no underscores for you i'm afraid
<mwhudson> and it's crashing and systemd restarts it before i can see the traceback
<mwhudson> any way i can see the traceback?
<Chipaca> mwhudson, journalctl -u $unit ?
<mwhudson> Chipaca: how can i run that though?
<Chipaca> mwhudson, what do you mean?
<mwhudson> Chipaca: the service i am debugging is running on tty1
<Chipaca> mwhudson, I'm missing something, probably something obvious, here
<mwhudson> Chipaca: i'm probably explaining myself really badly
<Chipaca> so many questions actually :-)
<Chipaca> mwhudson, how are you running a service on tty1
<Chipaca> ?
<mwhudson> Chipaca: it's a systemd unit
<Chipaca> mwhudson, or do you mean it's run before getty?
<mwhudson> that disables getty in it's preexec
<Chipaca> ahh
<Chipaca> mwhudson, 1 sec
<Chipaca> mwhudson, grub system?
<mwhudson> i think so
<Son_Goku> zyga, any luck iterating through the fedora-review report for snap-confine?
<mwhudson> Chipaca: ah, i remembered finally how to switch to tty2
<Chipaca> mwhudson, oh it only disabled getty on tty1?
<mwhudson> yeah
<Chipaca> oh
<Chipaca> then yeah, alt+FN, or alt-left,right
<mwhudson> unfortunately the output is not in journalctl
<Chipaca> otherwise from grub add systemd.debug-shell to the boot commandline
<Odd_Bloke> Chipaca: ;.;
<Chipaca> Odd_Bloke, how important are the underscores?
<Odd_Bloke> Not very.
<mwhudson> ah haha i fail at regular expressions
<Chipaca> mwhudson, ...?
<mwhudson> Chipaca: i found a log file and my bug
<Odd_Bloke> Just talked to sergiusens, so I understand the reasons behind it.
<Chipaca> mwhudson, :-)
<mwhudson> Chipaca: thanks for being a rubber duck :-)
<Chipaca> mwhudson, http://i.imgur.com/eTic1wS.jpg
<mwhudson> :-)
<ogra_> queck !
<zyga> Son_Goku: yes, some, also still sprinting and more meetings
<zyga> Son_Goku: I will find a quiet spot to do that today
<Son_Goku> cool
<mwhudson> does snapcraft by any change have an option to compress less but snap faster?
<mup> Bug #1606893 opened: snap find fails with an empty query error but the help suggests query is optional <Snappy:New> <https://launchpad.net/bugs/1606893>
<mup> PR snapd#1592 opened: many: update code for the new snap_mode <Created by mvo5> <https://github.com/snapcore/snapd/pull/1592>
<qengho> mwhudson: No
<mup> PR snapcraft#689 opened: kernel plugin: kernel targets depending on debarch <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/689>
<qengho> mwhudson: Also, we want reproducable snaps. So options are bad. A snapcraft.yaml with stable sources should, one day, produce the same snap file, bit for bit.
<mup> PR snapcraft#690 opened: Preserve file ownership for 'os' snaps <Created by josepht> <https://github.com/snapcore/snapcraft/pull/690>
<mup> PR snapd#1593 opened: asserts,many: start supporting structured headers using the new parseHeaders <Created by pedronis> <https://github.com/snapcore/snapd/pull/1593>
<mup> Bug #1606932 opened: snapd tests fail on snapd 2.11 on Arch Linux <Snappy:New> <https://launchpad.net/bugs/1606932>
<josepht> sergiusens: I created a bug for removing the namespacing of remote parts.  Please update with anything I missed.  https://bugs.launchpad.net/snapcraft/+bug/1606933
<mup> Bug #1606933: parser - Make all parts top-level parts <Snapcraft:New for joetalbott> <https://launchpad.net/bugs/1606933>
<kyrofa> stevebiscuit, you still around?
<Spads> sergiusens: okay, so what do I do if the makefile builds, but has no install target? âº
<Spads> sergiusens: the make plugin runs make install after building ð
<kyrofa> Spads, do you know what needs to go into the snap?
<Spads> kyrofa: yeah but unfortunately the build step bombs out
 * Spads expects he'll have to make a custom make plugin 
<Spads> that's two custom plugins in one snap!
<kyrofa> Spads, of course. Snapcraft assumes the presence of the install rule since it has no other way of knowing what needs to go into the snap
<Spads> sure
<Spads> but maybe I want to make the build and then copy the install
<kyrofa> Spads, so yes, you'll need to write a local plugin that just calls make and copies stuff instead
<Spads> Â¯\(Â°_o)/Â¯
<kyrofa> Spads, if you know what needs to be installed, may I suggest proposing an install rule upstream as well?
<Spads> yeah well upstream is pretty quiet
<Spads> and clearly aren't following common practice on a lot of things
<Spads> but I'm so close to finishing this I'm not bovvered
<kyrofa> Yeah that makes things more difficult :( . But hopefully you can get by with local plugins!
<Spads> kyrofa: I feel like "use this other thing for install" would have been a nice option on the make one tho
<kyrofa> Spads, what "other thing." Another part?
<kyrofa> Spads, note also: if upstream is quiet, another option may be to fork it, add install rules, and package that
<Spads> heh
<Spads> I kind of wish I had a step to append text to the Makefile
<stevebiscuit> kyrofa: pong
<kyrofa> Spads, but then we'd need to figure out some way to do that for cmake projects that don't have install rules, etc.
<Spads> right
<Spads> I wouldn't make it part of the build plugins
<Spads> but like, being able to chuck diffs at this would be p.sweet
<kyrofa> Spads, you mean like a patch step?
<Spads> yeah
<kyrofa> stevebiscuit, since go has a few different dependency management solutions, a more scalable approach is probably to make different plugins. I actually have a godeps one and will be proposing it first thing. I know you're EOD, but will you take a look tomorrow?
<stevebiscuit> kyrofa: I can look at it today seeing as I'm back in the UK
<kyrofa> stevebiscuit, that prevents the go plugin from having to grow support for everything
<kyrofa> Oh!
<kyrofa> Spads, you're not the first to request such a feature. I think it will probably happen, but needs some thoughtful design
<Spads> yeah
<kyrofa> stevebiscuit, okay, I'll ping you
<stevebiscuit> kyrofa: sweet
<ogra_> kyrofa, yo !
<kyrofa> Hey ogra_!
<kyrofa> Got home safely?
<ogra_> kyrofa, could i drag your attention towards bug 1605903 ... ? it kind of blocks moving forward with os snap bulds atm ...
<mup> Bug #1605903: "type: os" should prevent stage and prime stages from mangling content <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1605903>
<ogra_> kyrofa, yeah, you too i guess ?
<ogra_> how is the jetlag ? :)
<ogra_> i would cook up a patch, but the prime stage is really hard to understand by just reading the code
<kyrofa> ogra_, sure, I'll take a look :)
<ogra_> thanks !!
<kyrofa> ogra_, well, it was really hard to get up for standup at 6am this morning, so I must be doing better!
<ogra_> i guess it is effectively just needing an "if type = os then skip the world and just copy"
<ogra_> hah, yeah
<mhall119> sergiusens: when is snapcraft getting that new feature to add runtime env vars?
<mhall119> also, are the automated tests broken? Things are failing on my pull request that I haven't touched
<didrocks> hey kyrofa!
<kyrofa> didrocks, hey man!
<didrocks> seeing you are catching up on jetlag, good :)
<kyrofa> mhall119, sergiusens is still sprinting this week
<kyrofa> mhall119, I can take a look at the tests, though
<mhall119> oh, is zyga also sprinting?
<mhall119> thanks kyrofa
<ogra_> yeah, everyone is sprinting apparently
 * mhall119 is just sitting at home snapping stuff
<ogra_> we should have a sprint to discuss all that sprinting !
<kyrofa> mhall119, yup :P
<mhall119> ogra_: isn't that what the manager sprints are?
<ogra_> hah
<timothy> a meta-sprint
<timothy> One Sprint to rule them all.
<mhall119> Like some kind of Ultmate Decisions Sprint?
<mhall119> we could do one every 6 months
<kyrofa> mhall119, the integration tests seem unable to find npm. Since npm is grabbed via the tar source, it may be caused by your change
<mhall119> oh, hmmm....
<kyrofa> mhall119, try running the shout demo
<kyrofa> mhall119, does it work for you?
<mhall119> kyrofa: what's the command to do that?
<kyrofa> mhall119, just cd into demos/shout and run snapcraft
<kyrofa> mhall119, I re-ran the test just to be sure
<ogra_> mhall119, Ultmate Decisions Sprint? i like that ... but we should shorten that somehow UlDeS ? or some such ? :)
<ogra_> hah, now we scared olli
<mhall119> kyrofa: trying it in a cleanbuild now
<mhall119> oh wait, that won't get the changes
<ahoneybun> heyo
<mhall119> ogra_: it fails on npm install -g shout, which I believe is after snapcraft has unpacked the tarball
<mhall119> kyrofa: ^^ not ogra_
<mhall119> also other pull requests are failing on the same test
<ahoneybun> o/ mhall119
<ahoneybun> errors: http://pastebin.ubuntu.com/21044760/
<ahoneybun> yaml: http://pastebin.ubuntu.com/21044876/
<mup> PR snapd#1594 opened: daemon: always mock release info in tests <Created by chipaca> <https://github.com/snapcore/snapd/pull/1594>
<sergiusens> mhall119 ogra_ cloud sprint
<sergiusens> kyrofa hey! mind looking into the shebangs PR?
<sergiusens> or are you going to pull the snap card on me? ;-)
<ogra_> sergiusens, well, eventually it will rain ... then the clouds are gone and you can take vacation ;)
<sergiusens> josepht will update that bug in a bit
<sergiusens> mhall119 wrt environment, that just landed today in snap-confine... should be added to the next release
<ogra_> did snap-confine even make it into the archive yet ?
<ogra_> last time i checked it was sitting in proposed
<ogra_> (i mean in general, not a specific version)
<sergiusens> ogra_ yeah, right, there was a regression and mvo pushed another package, could be soon though (as soon as all the adt tests pass)
<ogra_> cool
<seb128> is there a vcs or something where one can look at the changes done to the ubuntu-core snap?
<mup> Bug #1606961 opened: snapd tests: checking for nogroup breaks Fedora, Arch Linux and maybe other distributions <Snappy:New> <https://launchpad.net/bugs/1606961>
<ogra_> seb128, not yet ...
<seb128> hum, k :-/
<seb128> is there anywhere to download the snap from different channels?
<ogra_> seb128, i'm just completely re-working the build setup (switching from cdimage to snapcraft) ... there used to be people.canonical.com/~ogra/core-image/stats
<timothy> sorry for my bunch of bugreports
<seb128> I don't even know if the snap is different between channels
<ogra_> seb128, i plan to have something similar again after the switch
<seb128> ok
<ogra_> it isnt different
<ogra_> it will be though
<seb128> ogra_, so being more specific, do you know if the SafeLauncher/xdg-open wrapper ever landed?
<seb128> mvo did https://github.com/snapcore/snapd/pull/1167
<mup> PR snapd#1167: interfaces: add  com.canonical.UrlLauncher.XdgOpen to unity7 interface <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1167>
<ogra_> thats pretty old, it should
<seb128> well I can't find it
<seb128> the only reference in ubuntu-core (according to grep) is in the unity7 interface
<seb128> at the time it landed mvo said it was in the beta(?) channel
<ogra_> sigh, i wish copy/paste would work in unity8
<ogra_> (in hexchat)
<seb128> I guess I would need mvo...
<seb128> where is he hidding? ;-)
<ogra_> https://wiki.ubuntu.com/QATeam/OSSnapPromotionPipeline
<ogra_> thats how the snaps and channels are supposed to work together in the future
<seb128> k
<seb128> in any case I guess I need mvo
<seb128> I don't know if I'm looking at the wrong channel/version
<seb128> or if the thing is named differently
<seb128> or if never landed
<seb128> +it
<ogra_> the ubuntu-core snap is currently the same in all channels
<seb128> k
<ogra_> so there is nothign to look at
<seb128> well either it's missing
<mup> PR snapd#1595 opened: many: make seed.yaml on firstboot mandatory and include sideInfo <Created by mvo5> <https://github.com/snapcore/snapd/pull/1595>
<seb128> or it's named differently that what I'm looking for
<ogra_> if it isnt in the current one then it isnt in
<seb128> well maybe it is
<ogra_> i suspect mvo is locked into some room for sprint discussions
<seb128> but I don't know how the tool is supposed to be named
<ogra_> i wouldnt count on seeing him much in here this week
<seb128> or in what location it's supposed to be stored
<seb128> who would know about that who isn't locked down in a dungeon? ;-)
<ogra_> probably Chipaca
<Chipaca> *always* chipaca
<Chipaca> what?
<seb128> Chipaca, ^ do you have any idea about that?
<Chipaca> seb128: from where on? that's a lot of backlog :-)
<seb128> Chipaca, do you know if the script/code corresponding to https://github.com/snapcore/snapd/pull/1167 landed somewhere and where
<mup> PR snapd#1167: interfaces: add  com.canonical.UrlLauncher.XdgOpen to unity7 interface <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1167>
<ogra_> Chipaca, did https://github.com/snapcore/snapd/pull/1167 land yet
<seb128> yes
<seb128> that landed
<seb128> but it's only the interface permission
<seb128> we need an actual xdg-open script or something which does that call
<ogra_> ah
<Chipaca> I think the xdg-open thing is in the ppa
<ogra_> i guess that would be in snap-confine though
<seb128> ppa?
<seb128> ah
<Chipaca> and in /usr/local in the image
<seb128> I looked in ubuntu-core
<ogra_> which should be in poroposed
<ogra_> Chipaca, dude ! /usr/local ?
<Chipaca> I think so?
<seb128> doesn't seem to be in snap-confine
<seb128> nor ubuntu-core snap
<seb128> not in /usr/local/bin either in a mounted snap
<didrocks> yeah, see the message on the ML
<seb128> or rather an installed snap starting a bash
<seb128> didrocks, "the"? which one?
<didrocks> someone had that issue yesterday
<ogra_> the right one indeed :)
<didrocks> and I asked for the status, I don't find it in ubuntu-core
<didrocks> (ccing mvo)
<Chipaca> yeah, mvo will know more. sorry :-(
<didrocks> I think last time he told me that it's in an ubuntu-core snap which isn't released
<seb128> didrocks, right, I saw your message, but seems like your status is the same as mine
<seb128> which is why I was trying to get info here ;-)
<seb128> looks like we need to wait for mvo
<ogra_> check https://lanuchapd.net/~ogra/+snap/os-test-snap/+build/1889
<ogra_> if you find it in there
<seb128> lanuchapd
<ogra_> (thats todays build)
<ogra_> heh, sorry
<mhall119> sergiusens: will you have a chance this week to look at the test failures in the snapcraft pull requests?
<ogra_> i'm in a unity8 session with a liberting hexchat ... cant copy/paste
<mhall119> https://github.com/snapcore/snapcraft/pull/688 is currently blocking easy builds of the Arduino IDE
<mup> PR snapcraft#688: Strip common path prefixes from linkname as well as name when extracting a tarfile <Created by mhall119> <https://github.com/snapcore/snapcraft/pull/688>
<tedg> jdstrand: Looking at your dbus name branch, don't want to bike shed there, but we probably need a "user" field vs. system and session. Not sure if it should replace session or not. But since we're moving to a user bus should probably be in snapd.
<seb128> didrocks, ogra_, right, https://launchpadlibrarian.net/275283297/buildlog_snap_ubuntu_xenial_i386_os-snap-test_BUILDING.txt.gz has "usr/local/bin/xdg-open"
<mup> Bug #1592901 changed: gvfs confinement issues <snapd-interface> <verification-done> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1592901>
<ogra_> seb128, my prob now is that i cant upload the snap you are looking at until bug 1605903 is fixed or worked around :/
<seb128> ogra_, that's a new ubuntu-core? how come the content is different from the current one?
<mup> PR snapd#1596 opened: osutil: support both "nobody" and "nogroup" for grpnam tests <Created by chipaca> <https://github.com/snapcore/snapd/pull/1596>
<ogra_> seb128, check the version of the currently published one (there is a date stamp in it)
<ogra_> it is simply outdated
<ogra_> and i had to shut down cdimage builds for $reasons
<seb128> ogra_, what's the master? like where was that xdg-open thing added?
<mup> Bug #1593957 changed: VLC snap Segmentation fault <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1593957>
<mup> Bug #1594318 changed: pulseaudio interface is missing permissions <snapd-interface> <Snapcraft:Invalid> <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1594318>
<ogra_> i dont know where mvo added it
<ogra_> me goes to a machine where he can actually copy/paste ... sigh
<seb128> well what sources/vcs is the builder pulling from?
<ogra_> seb128, https://wiki.ubuntu.com/QATeam/OSSnapPromotion
<ogra_> se dont have a seed for core
<ogra_> *we
<mup> PR snapd#1583 closed: snap: remove meta/kernel.yaml again <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1583>
<mup> PR snapd#1593 closed: asserts,many: start supporting structured headers using the new parseHeaders <Created by pedronis> <https://github.com/snapcore/snapd/pull/1593>
<ogra_> there is a list of packages set inside livecd-rootfs' config
<ogra_> (which usually doesnt change and i didnt see an upload from mvo)
 * zyga runs off to have more meetings
<ogra_> my assumption is that he added it to one of the PPA packages
<kyrofa> sergiusens, yep, I've got it
<seb128> ah
<seb128> https://launchpad.net/ubuntu/+source/livecd-rootfs/2.411
<seb128> ogra_, ^
<seb128>   * system-image: add /usr/local/bin/xdg-open dbus helper
<ogra_> thats yakkety
<ogra_> for which we dont build anything
<ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/image?field.series_filter=xenial
<ogra_> thats the livecd-rootfs used for xenial builds
<ogra_> but i guess that code is in there
<ogra_> (we usually forward port from the PPA into yakkety, not the other way round)
<seb128> the wrapper is in there
<ogra_> yeah, it is in there ... since may 26
<seb128> so yeah
<seb128> weird
<seb128> the ubuntu-core version is from may 31
<ogra_> and the last core snap was released on july 14
<mup> Bug #1579790 changed: Please support content-sharing interface <snapd-interface> <Snappy:Fix Released by mvo> <https://launchpad.net/bugs/1579790>
<mup> Bug #1597259 changed: Access to /lib/ denied <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1597259>
<seb128> hum
<seb128> so why is that script missing?
<ogra_> ogra@anubis:~/tmp$ ls squashfs-root/usr/local/bin/
<ogra_> apt  apt-cache  apt-get  no-apt  xdg-open
<ogra_> it isnt
<ogra_> i just pulled the edge snap
<ogra_> oh, sorry, i pulled i386
 * ogra_ checks amd64 instead
<seb128> well I'm on i386 :p
<ogra_> heh, well, it shoudl eb in there
<seb128> $ ls /usr/local/bin/
<seb128> apt  apt-cache	apt-get  no-apt
<seb128> that's in a .bash cmd from a snap using current xenial
<ogra_> whats the revision that snap list shows ?
<seb128> ubuntu-core     16.04+20160531.11-55  123  canonical  -
<ogra_> uuuh
<ogra_> thats from may
<seb128> yeah
<mup> PR snapd#1587 closed: store: deal with 404 froms the SSO store properly <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1587>
<seb128> there goes the promise of regular updates in snappy world :p
<ogra_> seb128, i rememkber mvo saying something about the re-exec logic that would break if we used newe core snaps in stable ...
<timothy> Chipaca: with your 2 pull requests, snapd 2.11 tests finished successfully on archlinux
<ogra_> seb128, nah, we are just not there yet
<seb128> ogra_, so there are different core versions in different channels?
<ogra_> seb128, right
<seb128> I though you said ubuntu-core was the same in all channels earlier
<ogra_> i thought it was
<ogra_> i didnt know we stopped promotion
<seb128> k, makes sense now
<mup> Bug #1570432 changed: Desktop example scummvm is broken <snapd-interface> <snappy-examples> <Snappy:Fix Released> <https://launchpad.net/bugs/1570432>
<mup> Bug #1584178 changed: OpenGL interface doesn't work <opengl> <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1584178>
<seb128> can I install ubuntu-core from another channel for testing on my xenial?
<ogra_> as i said though ... there will be a new system soon https://wiki.ubuntu.com/QATeam/OSSnapPromotion ...
<seb128> or is that going to make things grumpy?
<ogra_> you could try
<seb128> but...
<ogra_> snap install ubuntu-core --edge ?
<ogra_> dunno if snapd is clever enough
<seb128> error: cannot install "ubuntu-core": snap "ubuntu-core" already installed
<seb128> can't remove it either
<ogra_> Chipaca, is there a way to force it ^^^ ?
<seb128> refresh --edge seems to work
<timothy> sudo snap refresh ubuntu-core --edge ?
<seb128> let's see
<seb128> timothy, thanks, just tried that as well ;-)
<ogra_> yay
<ogra_> yup, that gets me 138 here
<ogra_> i386 should get 139
<mhall119> hey, so I was using 'snap try ./prime' on a local snap build, and then I ran 'snapcraft clean' before 'snap remove', and now snapd doesn't know what to do, how do I fix this?
<mhall119> zyga: ^^ ?
<mhall119> kyrofa: ^^ ?
<kyrofa> mhall119, now you've got snapd whining about mounted snaps?
<kyrofa> mhall119, first of all, that's supposed to be fixed. Maybe it hasn't been released yet, but are you sure you're up-to-date?
<mhall119> mounted snaps that aren't there anymore
<mhall119> update-manager just ran 30 minutes ago
<kyrofa> mhall119, ah, must not have been released yet, then
<kyrofa> mhall119, try unmounting the tried snap from /snap. Does that change anything?
<mhall119> is there a --force or something that I can use to make snapd remove it all
<mhall119> nope
<kyrofa> mhall119, eh... I'm not sure how snapd tracks that stuff. I know there's a way to recover from this, but I'm not sure what it is. Worst case, reboot
<mhall119> kyrofa: http://paste.ubuntu.com/21152275/
<seb128> ogra_, didrocks, so with "snap refresh ubuntu-core --edge" xdg-open works from inside the snap and correctly open the given url to my open firefox ;-)
<seb128> GNOME apps don't work though
<ogra_> yay
<seb128> but I guess it's because mimetype handlers are not set
<seb128> so a bit more work needed there
<kyrofa> mhall119, ah, but after unmounting, does it still show up in snap list and make it generally unusable?
<mhall119> kyrofa: it wasn't in snap list even before I unmounted
<mhall119> as soon as ./prime was gone, it didn't show in snap list
<kyrofa> mhall119, ah very good. Well, is it still complaining about the mounted snap?
<mhall119> yup, can't snap remove or snap try
<mhall119> for that particular snap
<kyrofa> Not being able to snap remove makes sense since it's not there, can you pastebin what it says when you attempt the snap try?
<kyrofa> mhall119, did you also unmount revision x1, by the way?
<mhall119> no, just x2
<kyrofa> mhall119, try unmounting x1 as well
<mhall119> mhall@mhall-thinkpad:~/projects/Ubuntu/snaps/git-playpen/logic$ snap try ./prime
<mhall119> error: cannot perform the following tasks:
<mhall119> - Mount snap "logic" (cannot find installed snap "logic" at revision x2)
<kyrofa> (I'm assuming that was also snap tried)
<kyrofa> mhall119, yeah... you've reached the extent of my snapd plumbing capabilities. I'm left with the reboot suggestion. I'm sure niemeyer, mvo, or zyga could help you, but I doubt any of them are available at the moment
<mhall119> thanks anyway kyrofa
<kyrofa> mhall119, sorry :(
<mhall119> not your fault, I should be more careful what I clean up
<kyrofa> mhall119, hardly, snapd needs to clean that up
<mhall119> (also snapcraft/snapd should prevent this, but that sounds like a fix in progress)
<kyrofa> mhall119, and it will! Just... not yet I guess :P
<mhall119> we really should make these desktop launchers leaner
<mhall119> (tangent)
<kyrofa> mhall119, more finely grained?
<kyrofa> mhall119, how would you distinguish between then?
<mhall119> not sure, all I know is that they're bigger than the app I'm snapping, and that doesn't make sense
<mhall119> the gtk2 launcher, for example, pulls in like 40MB of just icons
 * ogra_ hugs mhall119 
<didrocks> seb128: sweet! :)
<ogra_> now tell didrocks
<ogra_> :)
<didrocks> mhall119: well, content sharing man! you do want theming in your app, right?
<didrocks> seems like ogra_ isn't interested into well integrating apps
<ogra_> lol
<didrocks> mhall119: the launcher has the minimum (and even too minimum if you listen to vlc) set of deps
<mhall119> didrocks: theming yes, all the icons, not necessarily
<mhall119> actually, maybe not even always theming
<didrocks> like vlc doesn't integrate well on mate, or gnome shell or kubuntu
<didrocks> mhall119: this is the package dependencies, they are certainly there for a reason
<mhall119> didrocks: maybe there should be separate "launcher" and "integration" parts?
<didrocks> mhall119: they can be overriden through snapcraft
<didrocks> so if you don't like the list of stage-packages, you can override them
<didrocks> and have your own set
<seb128> +1 on having working defaults
<didrocks> but in that case, you will lose the benefit of having theming and icons integrated with default themes
<seb128> those who want to optimize then can do it
<didrocks> right
<didrocks> like ogra who don't want to contribute to the common set and keep ranting on the launcher :p
<ogra_> HAHAHAHA
<ogra_> i'm so evil
<didrocks> seriously, this is getting tiring
<ogra_> well, i'm not alone it seems
<didrocks> and why don't you just override the stage-packages then?
<didrocks> at some point, you will then get complains that your apps don't work/integrate well with X
<didrocks> and readd those deps :p
<didrocks> but you are free to do so
<ogra_> i dont need to atm ... my snaps all work fine, as soon as i snap a new desktop app i'll try that
<didrocks> nice then, not even sure you keep jumping on any occasion there then or what it does contribute to the discussion
<ahoneybun> did anyone look at those pastebins?
<ogra_> didrocks, well, like mhall119 i dont understand why we cant split these bits a bit finer grained
<didrocks> what is finer grained?
<didrocks> like "I don't want to have themes under Unity, or Mate orâ¦ ?)
<seb128> it's going to be as complex then than opting out from the stage-package you don't want today
<didrocks> or I don't want to have gsettings?
<ahoneybun> theme packs?
<ogra_> i might not want fonts in java apps which hardcode and ship their own ... so fonts might make sense to have in a separate part that the launcher can pull in ... same goes for themes or icons
<didrocks> ahoneybun: that's once we have content sharing working with our runtime snaps
<seb128> ogra_, keep in mind that those wrapper are not meant to be a proper solution
<didrocks> ogra_: sounds like you want debian packages granularity
<seb128> they just bridge a gap until we get content sharing and proper snaps
<didrocks> yeah, if only we had the interfaces upstream, this wouldn't be needed
<ahoneybun> mm I was working on Franz and I was getting some gtk-message errors
<ogra_> didrocks, i want just some granulatrity
<ogra_> not necessarily on a debian level
<ahoneybun> yet I added desktop/gtk3 and gtk2
<seb128> ahoneybun, what error do you get?
<didrocks> ahoneybun: that's maybe other errors?
<mhall119> didrocks: how do I strip files out that are being pulled in from desktop/gtk?
<didrocks> ogra_: it's on github, feel free to contribute there :)
<ahoneybun> http://pastebin.ubuntu.com/21044760/
<ahoneybun> errors
<ahoneybun> http://pastebin.ubuntu.com/21044876/ : yaml
<didrocks> mhall119: same, on your part, just use snap: [-path]
<mhall119> didrocks: so partA can remove files that are installed from partB?
<ogra_> mhall119, other way around
<didrocks> mhall119: no, you override partA
<ogra_> but since you define the launcher most likely via "after:" thats fine
<mup> PR snapd#1588 closed: tests: added spread find private test <Created by fgimenez> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1588>
<didrocks> mhall119: http://blog.sergiusens.org/posts/The-Snapcraft-Parts-Ecosystem/
<didrocks> ogra_: wrong
<ogra_> ?
<didrocks> mhall119: look at "composing"
<didrocks> ogra_: one part can only remove files from their own parts
<seb128> ahoneybun, the warnings about the modules not loading can be ignored
<didrocks> it's not a common set
<seb128> unsure what the real error is though
<ogra_> didrocks, hmm, how would mhall119 then remove his icons ?
<didrocks> ogra_: see the link above
<didrocks> and the "composing" dir
<didrocks> as I told you multiple times, you can override piece of cloud parts
<ahoneybun> seb128: https://github.com/imprecision/franz-app/releases
<didrocks> you can even remove the stage-packages you don't want to by redefining it
<didrocks> that way you can remove packages
<mhall119> didrocks: so in my "upstream" part, which has after: [desktop/gtk2], I can use the snap: -/usr/share/icons/ to remove them?
<ahoneybun> it has electron or something based
<didrocks> until people yells it's brorken :)
<didrocks> mhall119: not that
<didrocks> you use after: [desktop/gtk2]
<didrocks> than, you add another part:
<ogra_> mhall119, no, it is more complex
<didrocks> desktop/gtk2:
<didrocks> which has snap: [-/usr/share/icons]
<didrocks> for instance
<didrocks> it will override the cloud part as if this one would ship those
<mhall119> hang on, if my snapcraft.yaml has a desktop/gtk2 part, then it's not using the one from the part store, right?
<didrocks> apparently, it's smart enough to merge both
<mhall119> or does snapcraft have fancy part inheritance if the name is the same/
<ogra_> you still use after:
<didrocks> as per the blog post I listed above
<ogra_> so it first pulls the desktop remote part
<ogra_> then applies your local change
<mhall119> didrocks: the block post you listed doesn't use parts from the part store
<mhall119> it uses only local parts entirely defined in the snapcraft.yaml
<ogra_> mhall119, the example overrides the source: line
<ogra_> you just need to adapt the concept
<didrocks> mhall119: http://blog.sergiusens.org/posts/The-Snapcraft-Parts-Ecosystem/?
<didrocks> it does
<mhall119> right, this use canse needs to be better documented then, because currently I don't  know to do what didrocks is telling me to do, and will have to experiment
<didrocks> "curl" is a cloud part
<mhall119> oh, I see
<mhall119> so as long as (A) the part name matches and (B) I don't specify a plugin, it will inherit from the cloud part
<didrocks> right!
<ogra_> exactly
<mhall119> ok, I get it now
<mhall119> next topic
<mhall119> whenver I install an x2 snap that uses the desktop launcher, I get this:
<mhall119> ln: failed to create symbolic link '/home/mhall/snap/saleae/x2/.themes/themes': Read-only file system
<mhall119> doesn't happen on x1
<didrocks> oh, that might me a bug!
<didrocks> I think I know what's happening
<didrocks> mind filing it?
<ogra_> its not the first time i see it mentioned ...i bet we try to link before mkdir
<didrocks> no
<didrocks> the issues is the we try to symlink naming the dest dir
<mhall119> didrocks: against what?
<ogra_> oh
<didrocks> so second time, as the data are copied over, we try to nest into the symlink
<ogra_> yeah
<didrocks> which is a symlink to some $SNAP/something
<didrocks> ro
<ogra_> right
<didrocks> mhall119: the desktop-launcher github project (you already filed something against it, IIRC)
<didrocks> ogra_: others paths are versionned,so it's not an issue, but this one isâ¦
<ogra_> didrocks, indeed
<mup> PR snapd#1591 closed: spread.yml, .travis.yml: pass store credentials encrypted to travis and read them from environment <Created by fgimenez> <Closed by fgimenez> <https://github.com/snapcore/snapd/pull/1591>
<ogra_> seb128, how did you actually test that links work ? i cant get them to open from the telegram snap or my gitter snap
<mhall119> didrocks: https://github.com/ubuntu/snapcraft-desktop-helpers/issues/4
<seb128> ogra_, started a .bash cmd to be in a snap env and xdg-open http://www.ubuntu.com
<ogra_> heh, ok
<seb128> ogra_, as said earlier the gnome app lacks some mimetype handler definition to work
<seb128> I'm going to look at that
<ogra_> so it only works if the app is actually xdg aware
<ogra_> which probably rules out such web apps ...
<didrocks> mhall119: thanks! I'll tackle this tomorrow :)
<timothy> - Download snap "hello" (20) from channel "stable" (received an unexpected http response code (401) when trying to download https://public.apps.ubuntu.com/download-snap/mVyGrEwiqSi5PugCwyH7WgpoQLemtTd6_20.snap)
<seb128> hum
<seb128> so I upgraded ubuntu-core to the edge channel version
<seb128> using refresh --edge
<seb128> do you have any idea how to revert to the stable one?
<seb128> refresh --stable tels me that rev 123 is already installed
<seb128> can't remove it
<didrocks> and there is no more set command to force a rev
<didrocks> humâ¦ ogra_ ^
<kyrofa> flexiondotorg, you around?
<seb128> he's going to bounce to Chipaca I'm sure ;-)
<ogra_> seb128, just snap revert ubuntu-core
<ogra_> (at least this *should* work)
<popey> I have a snap which plays no audio, it prints an alsa error on launch (http://paste.ubuntu.com/21159662/) - any ideas? I have the pulseaudio plug (and devmode anyway).
<popey> it's an electron app fwiw
<ogra_> seb128, though there was a reson why mvo held back promotion if the new core snap ...
<ogra_> perhaps rollback will break
 * ogra_ goes afk for a bit
<Chipaca> sergiusens, you around?
<kyrofa> stevebiscuit, https://github.com/kyrofa/snapcraft/tree/feature/1595981/godeps
<kyrofa> stevebiscuit, it's still a little rough, but I gave it a quick test on snapweb and it seems to work
<Chipaca> sergiusens, nm, figured it out
<Chipaca> jdstrand, wrt your email about "namespace between commands"
<Chipaca> jdstrand, isn't the error the person is seeing due to them trying to call one wrapped command from another?
<Chipaca> jdstrand, that is, they're trying to call /snaps/bin/foo from inside /snaps/bin/bar
<Chipaca> jdstrand, AIUI that didn't work (yet)
<Chipaca> jdstrand, but it would work if they did called the binary directly (e.g. $SNAP/bin/bar.forrealz)
<jdstrand> Chipaca: oh, if that is the issue then you are correct. Maybe I missed something. /me re-reads
<stevebiscuit> kyrofa: could GodepsPlugin inherit from GoPlugin? Also, I think the `go get -t -d ./...` bit could be skipped? It would force *all* imported dependencies to be specified in the godeps-file
<stevebiscuit> kyrofa: in the docstring the "This plugin uses the common plugin keywords" bit is repeated
<kyrofa> stevebiscuit, yeah, docs are broken right now
<kyrofa> stevebiscuit, regarding inheritance, yes, but the go plugin has functionality that godeps won't use, so it would just override everything
<stevebiscuit> kyrofa: inheriting would be pointless then, np
<kyrofa> stevebiscuit, so when one uses godeps, one never uses go get?
<kyrofa> stevebiscuit, rather, you're saying they _shouldn't_ ?
<kyrofa> Easy change
<stevebiscuit> kyrofa: snapd and snapweb both use godeps and we never do a `go get` for the dependencies
<kyrofa> stevebiscuit, good deal
<popey> wat... anyone seen this before:- 'ascii' codec can't encode character '\u29f8' in position 19: ordinal not in range(128)
<popey> when running "snapcraft cleanbuild"
<timothy> popey: fix your locale
<popey> uhm
<timothy> do you have an UTF-8 locale?
<popey> yup
<timothy> uhm so it's strange
<timothy> it seems that python doesn't like your locale
<popey> this is inside an lxc container
<popey> so maybe not my host locale
<popey> but I haven't changed anything and this used to work
<timothy> ok, so it's the same problem I fixed on snapd tests
<popey> oh?
<timothy> if you read a string that includes an utf-8 character without a working utf-8 locale python doesn't like it
<jdstrand> Chipaca: ok, responded. still not sure if that was what he was asking, but I addressed that just in case
<popey> i see no strange characters in my yaml
<popey> this only affects one snap
<popey> other snaps build fine.
<timothy> cat -A of your yaml file?
<timothy> maybe some strange character
 * popey learned a new thing today!
<timothy> https://github.com/snapcore/snapd/pull/1468/commits/b66d3ea328ee42d3d4f56ed9736c315833dee67d this is how I fixed that in tests
<mup> PR snapd#1468: Fix ./run-checks --static <Created by drizzt> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1468>
<Chipaca> jdstrand, thanks! normally i would've butted in myself, but gmail is acting up on over here
<timothy> by force reading of file with utf-8
<popey> timothy: http://paste.ubuntu.com/21165798/ look okay to you?
<popey> (that's the output of cat -A snapcraft.yaml)
<jdstrand> Chipaca: np at all :)
<Chipaca> popey, is the - between [ and usr from cat, or from the yaml? in stage: and snap: at the bottom
<timothy> the character it doesn't like is an http://www.fileformat.info/info/unicode/char/29f8/index.htm
<timothy> but I can't see that in your pastebin
<Chipaca> haha
<Chipaca> ha
<popey> timothy: indeed, which is what's odd
<Chipaca> oh man
<popey> Chipaca: yeah, the - is in the yaml
<Chipaca> that BIG SOLIDUS is my fault :-D
<Chipaca> but yes, it is the locale
<popey> oh?
<Chipaca> snapcraft transforms parts that have / in them (sub-parts?) to have BIG SOLIDUS so it can mkdir it
<Chipaca> or something like that :-)
<timothy> Chipaca: maybe you should use codecs and open the file in utf-8
<Chipaca> oh, i didn't write the code
<timothy> to avoid locale madness
<Chipaca> i'm just the idea man
<timothy> oh ok
<timothy> I don't have ubuntu here, so :P
<popey> so the fix is? (given this is lxc, building on host is fine)
<timothy> popey: configure locale in lxc
<Chipaca> popey, can you install locales inside the lxc?
<popey> ah
<popey> i can add it to build packages?
<Chipaca> ah, perhaps
<Chipaca> not sure if that'll be early enough, but try
 * popey tries that
<popey> snapcraft-painfully-epigrammatic-jonathon
<popey> lxc names always amuse
<timothy> you need to uncomment the correct locale in /etc/locale.gen, launch locale-gen command and set LANG=you_locale
<popey> inside my lxc?
<popey> It's a pre-built container
<timothy> yep
<popey> I dont see how (or that) I'd want/like to do that
<timothy> it's scriptable
<popey> this seems needlessly odd
<popey> it should "just work"
<popey> I shouldn't be messing with the config of packages inside the container
<timothy> so someone should fix the code to use codecs
<popey> that's madness
<popey> ok
<popey> good, SEP
<timothy> like I did on tests, https://github.com/snapcore/snapd/pull/1468/commits/b66d3ea328ee42d3d4f56ed9736c315833dee67d
<mup> PR snapd#1468: Fix ./run-checks --static <Created by drizzt> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1468>
<popey> ok, guess I'll file a bug on snapcraft then :)
<popey> thanks for your valuable time chaps :)
<popey> https://bugs.launchpad.net/snapcraft/+bug/1607015
<mup> Bug #1607015: 'ascii' codec can't encode character '\u29f8' in position 19: ordinal not in range(128) <Snapcraft:New> <https://launchpad.net/bugs/1607015>
<popey> \o/
<mup> PR snapd#1592 closed: many: update code for the new snap_mode <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1592>
<kyrofa> jdstrand, what's the current status of seccomp argument filtering?
<mup> PR snapcraft#675 closed: Allow godeps to fetch Go dependencies <Created by stevenwilkin> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/675>
<mup> PR snapcraft#691 opened: Add godeps plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/691>
<kyrofa> josepht, elopio ^^ could use a review
<kyrofa> Note that I'm adding a demo for it now
<kyrofa> Nah... an integration test actually
<jdstrand> kyrofa: waiting on snap-confine 1.0.39 to land in xenial
<kyrofa> jdstrand, awesome. Will that automatically unblock setpriority, or do we also need profile changes in snapd?
<jdstrand> kyrofa: actually this is fine too: 1.0.38-0ubuntu0.16.04.3
<jdstrand> kyrofa: once that lands it will unblock me to fix things like setpriority
<kyrofa> jdstrand, alright
<kyrofa> Thanks for the update!
<jdstrand> I didn't want to land that stuff in snapd cause it lands a whole lot faster in the archive than snap-confine and then snapd would be blocked on the snap-confine landing
<jdstrand> so, waiting patiently :)
<josepht> kyrofa: that PR looks good to me.  Needs more double quotes ;)
<LBo> I had some problems with snapcraft
<kyrofa> josepht, I can't. elopio bruised the fingers I use to press that button
<LBo> Whenever I built something with snapcraft I got this error: execv failed: Permission denied
<LBo> After some triaging it seems that my umask is the problem
<kyrofa> jdstrand, understood, no rush! I was just curious where we were there
<kyrofa> LBo, yeah that may cause issues
<LBo> The default umask is 0002, then the snap works
<LBo> kyrofa: ah, thanks. I was pulling my hairs
<LBo> Is this documented somewhere?
<LBo> Another user on IRC had the same problems a few days ago
<LBo> Same error message, but nobody had an answer
<jdstrand> kyrofa: oh, I want to that thing landed in xenial so I can run with the arg filtering policy! :)
<LBo> Is it a bug, or just something by design?
 * jdstrand is chomping at the bit for that
<kyrofa> jdstrand, you'll have fun actually testing that stuff with the new re-exec stuff
<kyrofa> LBo, wait, I'm not sure I understand. You're getting those issues when running an installed snap?
<LBo> kyrofa: yeah, exactly
<LBo> http://paste.ubuntu.com/21186127/
<LBo> Well, when running the snap built with a specific umask
<kyrofa> LBo, if you change the umask after you create a snap that works, does it stop working?
<kyrofa> i.e. build the snap, change the umask, then install and run
<LBo> Then it works
<LBo> http://paste.ubuntu.com/21186621/
<kyrofa> LBo, okay so actually creating the snap isn't the problem?
<kyrofa> Rather, the snap works regardless of the umask when built
<LBo> No, the other way around
<LBo> Built with 0022 it always runs, with whatever umask
<LBo> Built with 0077 it only runs as root
<LBo> When I ls the snaps the permissions of the snap directories are "wrong"
<kyrofa> Huh... I thought squashfs got rid of that issue...
<LBo> Not-working snap: drwx------  5 root root   50 jul 27 22:07 usr
<LBo> Working snap: drwxrwxr-x  5 root root   50 jul 27 22:07 usr
<kyrofa> To clarify, you tried the umask the other way around? Restrictive when building and permissive when running?
<LBo> Yes
<LBo> In the last paste: http://paste.ubuntu.com/21186621/
<LBo> umask 0002 when building, 0077 when installing & running
<kyrofa> That seems to work fine, no?
<LBo> I'm sorry
<LBo> That was the other way around
<LBo> I will do a new one: 0077 when building, 0002 when running
<kyrofa> Yes, please do that
<kyrofa> Sorry for the confusion-- I don't typically utilize umask
<LBo> This is what you meant: http://paste.ubuntu.com/21187624/
<LBo> ls -hal /snap/xcape/{x10,x11}/
<LBo> total 4,5K
<LBo> drwxrwxr-x  4 root root   67 jul 27 22:16 .
<LBo> drwxr-xr-x 13 root root 4,0K jul 27 22:24 ..
<LBo> -rwxr-xr-x  1 root root  299 jul 27 22:16 command-xcape.wrapper
<LBo> drwxrwxr-x  2 root root   32 jul 27 22:16 meta
<LBo> drwxrwxr-x  5 root root   50 jul 27 22:16 usr
<LBo> ls: cannot open directory '/snap/xcape/x11/': Permission denied
<LBo> I don't know if it has anything to do with versions, but to be complete: snapd = 2.0.10, snapcraft = 2.13.1
<jdstrand> zyga: fyi, I think the last "RE: How do I share a namespace between snap commands?" may be due to how the bind mounts are setup
<jdstrand> zyga: (on snapcraft@, and hi! :)
<Pharaoh_Atem> does anyone know where the firefox snapcraft.yaml is?
<kyrofa> LBo, set your umask restrictive and install the hello-world snap. Do you have the same issues?
<LBo> No, that works fine: http://paste.ubuntu.com/21189027/
<zyga> jdstrand: hey
<zyga> jdstrand: checking now
<zyga> jdstrand: so it looks like the problem is the mount namespace
<zyga> jdstrand: I'm too tired to analyze this in detail
<zyga> jdstrand: I will have a "nice" backlog of things to work on after this sprint sprint
<mup> Bug #1607067 opened: Add a dotfiles / hidden files interface <snapd-interface> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1607067>
<jdstrand> zyga: sure, np, it's late there! I just wanted you to be aware of the issue. thanks and goodnight! :)
<LBo> What can I do to resolve this? Received 403: 'Developer has not signed agreement.'
<Chipaca> LBo: https://bugs.launchpad.net/snapcraft/+bug/1596777
<mup> Bug #1596777: trying to upload a snap without signing the agreement prints the error twice <Snapcraft:In Progress by tsimonq2> <https://launchpad.net/bugs/1596777>
<Chipaca> LBo: is that your issue?
<LBo> Chipaca: no, I just had to login to https://myapps.developer.ubuntu.com and register
<LBo> But it wasn't obvious at first what I had to sign
<Chipaca> LBo: sounds like the error should be a lot clearer
<Chipaca> yeah
<LBo> I thought at first I had to sign the code of conduct
<LBo> Got it working now!
<Chipaca> noise][: ^ not sure what component it is, but AIUI it's closer to things you have competence in than me
<tsimonq2> o/
<Chipaca> tsimonq2: o/
<Chipaca> bbiab, need to shut down this box to add a hard drive
<noise][> Chipaca: LBo: we have an open task to improve that and a bunch of other err messages
<LBo> noise][: awesome, thanks!
<noise][> things got a bit convoluted in the rush to 16.04 and other recent improvements
<mup> Bug #1603018 opened: snap create-user gets bad username <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1603018>
<tianon> jdstrand: I know I'm horrible and it's been forever, but when you've got a sec I'm finally ready for pointers about "docker" interfaces in snapd -- I've started looking at what's going to need to happen, and it _seems_ like we'll need an interface for the daemon (to confine it properly so it doesn't need --devmode), and a separate interface for the client (to talk to the daemon over the unix socket), â¦
<tianon> â¦but I can't seem to find any example of service confinement in interfaces/builtin to back up my theory O:) (they all appear to be only for handling/managing the client-side, not worrying about daemon constraints)
<tianon> I'm also happy to post to the list instead if that's easier to compile/discuss the topic :) (especially if it needs to be slightly more async)
<tianon> (figured I'd start here since you did ask me to prod you when I was ready O:) )
<tianon> "connected" vs "permanent" is what I'm currently exploring :)
<mwhudson> uh huh why does this image i'm building not dhcp by default
<tianon> permissions are hard, let's go ride bikes :)
<tianon> it would appear that "plug" profiles are for the client half, "slot" profiles are for the daemon, "permanent slot" is bits the daemon has all the time, and "connected slot" is the bits the daemon gets when a client/plug is actually hooked up?  might be way off base :D
<mup> Bug #1607121 opened: snap create-user creates user with silly gecos field <Snappy:New> <https://launchpad.net/bugs/1607121>
<mup> Bug #1607129 opened: snap create-user does not check that sso user has ssh keys <Snappy:New> <https://launchpad.net/bugs/1607129>
#snappy 2016-07-28
<stokachu> sergiusens: https://www.irccloud.com/pastebin/yctOxEI4/
<mup> PR snapd#1593 closed: asserts,many: start supporting structured headers using the new parseHeaders <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1593>
<sergiusens> stokachu interesting. Seems like a simple bug
<stokachu> sergiusens: i built it locally and tried installing and the act of installing gave me the same error
<sergiusens> ogra_ does josepht's branch solve your problems?
<sergiusens> stokachu installing the snap or the python setup?
<stokachu> installing the snap
<oparoz> I've seen that Libreoffice had been snapped, but has anybody tried to snap Libreoffice Online?
<didrocks> oparoz: not that I know of, interested in doing it?
<oparoz> dirdocks, well, actually, Nextcloud is interested in including it in an image along with the Nextcloud snap, but that's end of the year stuff, so I haven't looked at the implementation details yet
<qengho> oparoz: Meaning, the server component of some multiuser online libreoffice?
<oparoz> qengho, correct, it's a server, opened on a specific port which a Nextcloud app connects to
<qengho> oparoz: I'm hoping you just volunteered.
<oparoz> qengho, well, I'll definitely investigate how doable the project is and will probably get in touch with the person who has snapped Libreoffice since LO uses that source code
<oparoz> We currently have a Docker, so that could be plan B
<dholbach> balloons, how's the juju snap coming along?
<mup> PR snapcraft#692 opened: Use the new snapcraft mailing list as contact info <Created by seb128> <https://github.com/snapcore/snapcraft/pull/692>
<imexil> Hi I'm trying to create my first snap. Its a "make" project and I'm struggling to find out how to tell snapcraft to go into the "src/" directory of the tarball in order to execute make command. Any pointers?
<dholbach> imexil, use source-subdir
<dholbach> ("snapcraft help sources" lists it among other useful things)
<imexil> Thanks dholbach. So http://snapcraft.io/docs/build-snaps/syntax is not really complete at the moment?
<imexil> (that's where I went looking)
<dholbach> imexil, I'd agree with you that the "snapcraft help sources" bits should be on there
<imexil> :-)
<dholbach> probably not the plugin related bits, because some options only exist for certain plugins
<dholbach> I'll file a bug
<imexil> Thanks!
<dholbach> https://bugs.launchpad.net/snapcraft/+bug/1607249
<mup> Bug #1607249: docs/snapcraft-syntax.md should refer to source related syntax <snap-docs> <Snapcraft:New> <https://launchpad.net/bugs/1607249>
<imexil> OK almost there. I get a "install: cannot remove '/usr/local/lib/libipe.so.7.2.5': Permission denied" on the make install part when simply running "snapcraft build". Why would building the snap need sudo permissions on my system?
<mup> Bug #1607252 opened: User data is missing or lost when utilizing a snap instead of a traditional package <Snappy:New> <https://launchpad.net/bugs/1607252>
<mup> Bug #1607253 opened: User data is missing or lost when utilizing a snap instead of a traditional package <Snappy:New> <https://launchpad.net/bugs/1607253>
<dholbach> imexil, it shouldn't - I assume something went wrong in one of the steps before - you could try to run   snapcraft clean && snapcraft
<imexil> OK
<imexil> Still the same :-(  For what it's worth: https://github.com/dietmarw/snaps/blob/master/ipe/snapcraft.yaml
<qengho> imexil: Maybe your Makefile doesn't honor prefix and installdir and such.
<imexil> yes it does. compiling it manually works fine.
<qengho> imexil: does installing it work fine? "make install"?
<imexil> Basically I followed https://github.com/otfried/ipe-wiki/wiki/Downloading,%20Compiling,%20and%20Installing%20Ipe#debian-ubuntu-mint and am now trying to convert  that into a snap
<mup> Bug #1607253 changed: User data is missing or lost when utilizing a snap instead of a traditional package <Snappy:New> <https://launchpad.net/bugs/1607253>
<mup> Bug #1607265 opened: Ubuntu-core downloads before querying store for missing snap <Snappy:New> <https://launchpad.net/bugs/1607265>
<imexil> qengho: yes that works
<qengho> imexil: Can you you get it to install to /tmp/imexil/ using only "make install DESTIR=/tmp/imexil"?
<qengho> imexil: you might need to extend that makefile plugin, or use some "make-parameters: [ ... ]" in your YAML.
<ogra_> sergiusens, josepht  it looks like it could help, i need to do a PPA build and try an os snap build with it ...  it still does a lot directory walking and permission checking thought, why not just do the equivalent of mv for the top level dir
<sergiusens> stokachu http://paste.ubuntu.com/21252582/
<imexil> qengho: OK so this is strange. I've changed in the make-parameters "IPEPREFIX=/usr/local" to "IPEPREFIX=/tmp/imexil" and this works. Why would snapcraft want to install on my /usr/local whilst building the snap?
<qengho> imexil: It's not right. snapcraft only knows about DESTDIR. Instructions to install in /usr/local are not instructions to build a snap.
<qengho> imexil: I have only a trickle of bandwidth here, so I can't read much, but I'm sure someone else can tell you if it's possible to YAML that sets IPEPREFIX to the temporary directory that snapcraft is expecting the result to land in.
<qengho> imexil: you told it ot put it in /usr/local . That's why it's trying to write to /usr/local/ . snapcraft doesn't want the result in /usr/local/ .
<imexil> OK. I'll try to specify DESTDIR in addition. Thanks for the help qengho.
<qengho> You can't sepcify DESTDIR in the YAML. Thats backwards.
<imexil> Yes just noticed that this is not working. Still I don't get why snapcraft build would try to write to /usr/local on the file system
<qengho> imexil: it's because you told it to, right? You invented /usr/local in "IPEPREFIX", whatever that is.
<imexil> qengho: OK got your note with /usr/local. Since the original makefile expects to have IPEPREFIX to be set (it won't compile otherwise) I guess I can just set it to some tmp folder?
<qengho> No. You can't invent that. That belongs to snapcraft. You can't predict it.
<qengho> ogra_, dholbach, help? ^
<dholbach> I'm about to hop on a call - can you pastebin your current snapcraft.yaml somewhere so I can take a look in a bit?
<ogra_> dholbach, https://github.com/dietmarw/snaps/blob/master/ipe/snapcraft.yaml
<qengho> gist: wonky Makefile project expects "IMEPREFIX" instead of "DESTDIR". There's no way to use YAML here, right? No variable expenasion in  make-parameters: [ IMEPREFIX=$destdir ]
<dholbach> ogra_, cool - I can take a look in a bit
<ogra_> imexil, i have never used IPREFIX, but in a makefile i need to use $(DESTDIR)
<imexil> thanks dholbach, ogra_
<ogra_> (note the brackets)
<ogra_> i'm not sire how make-parameters: are used here
<ogra_> *sure
<qengho> imexil: You're going to have to change the Makefile to use DESTDIR instead of IMEPREFIX, or make a new snapcraft plugin that runs "make install IMEPREFIX=installdir". See /usr/lib/python3/dist-packages/snapcraft/plugins/make.py .
 * qengho afk.
<imexil> Right. I was hoping to not have to change the Makefile since I'm not upstream
<imexil> "IPEPREFIX=$(DESTDIR)" does not work btw.
<mup> PR snapcraft#692 closed: Use the new snapcraft mailing list as contact info <Created by seb128> <Closed by seb128> <https://github.com/snapcore/snapcraft/pull/692>
<cking> hiya, stress-ng is a published snap, yet I can't find it with snap find and hence I can't install it from the store. Not sure what's gone wrong.
<mup> PR snapcraft#693 opened: Implement "oneshot" daemon type <Created by stgraber> <https://github.com/snapcore/snapcraft/pull/693>
<cking> also, I have smemstat that's been pending review for a while, can somebody review that? I'm kinda blocked by the human processes involved in getting my snaps uploaded
<cking> it's not helping with "velocity"
<ogra_> cking, just stop using exotic interfaces :) .... most of us dont have to wait at all
<cking> ogra_, ok, well, that's all my code then ;-)
<seb128> cking, if the published one is in devmode it might not be listed by snap find by installing it should still work?
<seb128> (I think from what I read)
<seb128> do you force devmode?
<cking> i don't believe I did
<seb128> k, maybe you got confused by the store UI and didn't actually press the publish button?
<seb128> seem to happen to some people
<seb128> otherwise I don't know, you need somebody from the store team I guess
<cking> it says "Package status is Published"
<seb128> k, dunno then, sorry
<slangasek> ogra_: I've gotten myself into a strange situation where I have a grub.cfg looking for $snap_kernel variable and snapd is writing $snappy_kernel variable instead... which of these is the right variable?
<slangasek> i.e. is my grub.cfg stale or is my grubenv stale
<ogra_> i *think* you want snap_kernel ...
<ogra_> hmm, though looking at the arm configs it seems to be snappy
<ogra_> yeah, i take that back, it should be snappy_kernel, thats used everywhere else
<slangasek> hmm
<slangasek> so this was changed recently?
<ogra_> abd looking at http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/generic-amd64/grub.cfg the code agrees too
<ogra_> not that i'm aware
<slangasek> I had this working last time I built an image, using the same version of snap supporting 'snap weld', and something has changed ;)
<slangasek> ok, very confusing, I don't know where this grub.cfg is coming from
<ogra_> well, it doesnt look like the grub.cfg in the gadget has changed much since we switched to all-snap images
<slangasek> yes
<slangasek> I don't know where the broken grub.cfg is coming from - my problem to sort out
<ogra_> sergiusens, bah, the rust selftests fail in the PPA snapcraft build :/
<ogra_> slangasek, do you use the right build tool ? you need to use the u-d-f-experimental from mvo currently
<slangasek> ogra_: yes, I use the right build tool, it's called ubuntu-image. :P
<ogra_> lol
<slangasek> :P ;) :P
<ogra_> ok
<ogra_> then i agree that it is your problem to sort :)
<slangasek> hmm, there's a broken /system-data/boot/grub/grub.cfg
<slangasek> so that's actually coming from snap weld, so I probably need to get fixes to that
<ogra_> well, isnt snap weld dead ?
<ogra_> i thought it already got renamed
<slangasek> yes, but that's the interface we were writing to at the time
<ogra_> ah
<slangasek> and I was trying to debug why my previously-working image build pipeline regressed
<slangasek> ogra_: ok, now the problem I'm getting is that the initramfs scripts in canonical-pc-linux_32.snap are failing to remount the filesystem after fsck....
<ogra_> slangasek, do you have that from the store ?
<slangasek> ogra_: I have it as downloaded by 'snap weld' today, yes
<slangasek> tracking edge channel (which is a prereq)
<ogra_> hmm, weird
<ogra_> slangasek, is that on first boot ?
<slangasek> ogra_: yes
<ogra_> are there probably some format options missing ? i forgot how u-d-f did the formatting ... i think we called out to sgdisk
<mup> Bug #1607297 opened: Error with an example Python snap <Snappy:New> <https://launchpad.net/bugs/1607297>
<slangasek> ogra_: no idea, I'm getting no output from that bit of the initramfs script... it just tells me it's /trying/ to fsck
<mup> PR snapd#1597 opened: tests: add hardware-observe spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1597>
<ogra_> well, our fsck is actually not a real fsck ... (well, it is, but we mount -o remount before which commits the journal ... thats a lot faster to fsck)
<ogra_> 	# Mount and umount first to let the kernel handle
<ogra_> 	# the journal and orphaned inodes (much faster than e2fsck).
<ogra_> 	mount -o errors=remount-ro "$path" "$writable_mnt" || true
<ogra_> 	umount "$writable_mnt" || true
<ogra_> and then we run
<ogra_> /sbin/e2fsck -va "$path" >> "$logfile" 2>&1 || true
<ogra_> right afterwards
<ogra_> there should be a log in case you have an initrd prompt
<ogra_> under /run/initramfs/
<stgraber> zyga, jdstrand: Hey, so I have an interesting issue with the LXD snap. I'm running two daemons, one is lxcfs, the other is lxd. lxcfs runs a fuse filesystem which lxd must have access to.
<stgraber> zyga, jdstrand: the problem is that because snapd creates one mount namespace per process, lxd can't actually see the filesystem that lxcfs mounted, it just sees an empty directory
<stgraber> zyga, jdstrand: any chance we can alter the way this works to re-use the existing namespace (setns into it if it exists, instead of unsharing a new one)
<stgraber> (I may also be wrong and maybe the launcher already does that and I screwed something up in my setup)
 * ogra_ is surprised you can fuse-mount anything at all from inside a snap ... i tried sshfs and failed due to no /dev/fusectl access
<stgraber> ogra_: running devmode right now. I have a fuse interface implemented here but need a bunch more things for lxcfs to be happy (it needs to create its own mount namespace, mount a bunch of kernel filesystems, ...)
<slangasek> ogra_: /dev/vda2 has unsupported feature(s): metadata_csum
<stgraber> so yeah, that's an odd case where even --devmode still breaks you :)
<ogra_> stgraber, oooh lovely ... please make it a separate interface, not buried in an lxd inetrface or so ... i want to use it :)
<slangasek> ogra_: so it seems that creating a new filesystem with e2fsck in yakkety is not compatible with series 16's e2fsck, sigh :/
<stgraber> ogra_: yeah, the fuse one I have separate. lxd itself will use a new "unconfined" interface because well, we need unconfined apparmor and unconfined seccomp to run :)
 * stgraber -> lunch
<ogra_> slangasek, hooray for steady advancement of our software :P
<slangasek> ogra_: and I don't know how this regressed, either, because e2fsprogs hasn't changed in yakkety since 6/30, so that *should* have been the version I used for my previous round of testing
<ogra_> well, i'm not sure if u-d-f actually uses e2fsprogs or rather some fancy go implementation
<ogra_> http://bazaar.launchpad.net/~phablet-team/goget-ubuntu-touch/trunk/view/head:/diskimage/partition.go
<ogra_> looks like it actually uses parted directly
<ogra_> (which actually is a bit awkward when doing GPT stuff)
<slangasek> ogra_: /I'm not using u-d-f/
<ogra_> i know ... but it works with u-d-f
<ogra_> so you have something to compare to
<slangasek> with the yakkety version of e2fsprogs?
<ogra_> well, i know mvo tests his builds before pushing a change to u-d-f ... assuming he runs yakkety locally i would guess it has worked two weeks ago when he did the last u-d-f
<ogra_> (i personally have only tested in xenial though)
<slangasek> yes, and at that point it also worked for me with ubuntu-image
<slangasek> and e2fsprogs claims not to have changed since then ;)
<ogra_> i'm just not sure if parted actually uses e2fsprogs internally for its mkpart call
<slangasek> it does
<ogra_> ah, k
<slangasek> anything else would be layer-violating madness ;)
<ogra_> well, it doesnt call out to sgdisk for GPT partitions :)
<ogra_> so you never know :)
<slangasek> yes, because it's parted and because partitions
<slangasek> it's not fsed
<ogra_> (i wasnt serious ... :) )
<imexil> I think I got the snap build and installed but how can I make sure the snap version of an application is run and not the apt installed version?
<ogra_> sergiusens, josepht, no change with the patch /tmp and /home/ubuntu are still having 0755 permissions and are root:root
<ogra_> err
<ogra_> wait
<ogra_> i take that back, i'm blind
<slangasek> ogra_: the fsck failure was a red herring and must have always been there.  I've adjusted the mkfs.ext4 options in u-i, it now succeeds, and the rw remount still fails to happen
<slangasek> ogra_: so, what changed in the edge kernel snap since last week?  how can I see the history of the package, etc.?
<slangasek> (or even retrieve an older version for comparison, since I didn't keep the old working dir around, thinking I was done with it!)
<lool> ogra_: hey
<lool> ogra_: have you ever got: run-parts: /etc/network/if-up.d/ubuntu-fan exited with return code 1
<ogra_> lool, yeah, old bug that is fixed since a while ... iirc apw did an SRU
<apw> ogra_, right that should be fixed i beleive
<ogra_> slangasek, nothing should have changed, uploads are all manual
<lool> ogra_: I took https://people.canonical.com/~mvo/all-snaps/amd64-all-snap.img.xz did sudo snap refresh ubuntu-core (couldn't refresh canonical-pc as it fails with a pcspkr module loading error) and rebooted, then lost network (this is under KVM) because eth0 was ens3
<slangasek> hmm
<ogra_> slangasek, and to my knowledge nobody uploaded a new kernel snap
<slangasek> ogra_: how would I rule this out with certainty? :)
<lool> - Download snap "canonical-pc-linux" from channel "stable" (revision 24 of snap "canonical-pc-linux" already installed)
<lool> - Download snap "canonical-pc" from channel "stable" (revision 6 of snap "canonical-pc" already installed)
<lool> so I'm fully up-to-date thre
<lool> perhaps the snap isn't updated
<ogra_> slangasek, uh.oh ... so pobviously there was a kernel snap upload yesterday, i dont know where it comes from, my new kernel snapping isnt ready yet and i wouldnt know who else uploads under the shared store account
<slangasek> ogra_: mmhmm - ok, thanks for checking :)
<ogra_> apw, ppisati_, did one of you upload a canonical-pc-linux snap yesterday ?
<ogra_> (and how was the built ??)
<slangasek> ogra_: fwiw if there were something usable in a channel other than 'edge' I would happily use that for prototyping instead :-)
<ogra_> slangasek, try stable
<slangasek> ogra_: stable is too stable
<slangasek> ;)
<ogra_> but note that has a very old ubuntu-core
<slangasek> yes. too old for my purposes
<slangasek> ogra_: meanwhile... maybe you could back that rev out of the edge channel?
<apw> ogra_, i think that was bjf
<ogra_> slangasek, http://people.canonical.com/~ogra/snappy/canonical-pc-linux_31.snap (give it another munitee, still uploading)
<ogra_> apw, how did he build that ? there are a good bunch of packages that need to go in there
<apw> ogra_, i believe the snapcrafy.yaml is on the tip of our branches
<ogra_> sigh
<ogra_> apw, that wont work
<apw> ogra_, but ... i'd say you'd be better short circuiting to him direct
<apw> ogra_, oh i am sure, but hey, this is how you learn :)
<ogra_> we need all that meta pulls in ... and soon also mesa and some other bits
<ogra_> apw, i have a buiolld system nearly ready for the kernel snaps
<ogra_> slangasek, uploaded, grab it :)
<apw> ogra_, don't panic, i am sure we are not expecting it to work currently, he is likley working out how to join all the bits up
<ogra_> apw, well, it would be nice if you could upload it under a separate name then ... you just killed the edge channel for eveyone :)
 * ogra_ tries to find out how to unpublish a single revision
<apw> ogra_, we did what ?  oh perhaps i malign him, ask bjf if it was him and go from there
<slangasek> apw, ogra_: I'm talking with bjf here at sprint, he tells me he did not intentionally upload anything
<ogra_> apw, well, someone uploaded canonical-pc-linux under the shared store account
<ogra_> weird
<apw> ogra_, as far as i know it was not me
<slangasek> and it would've had to be an upload + publish
<slangasek> anyway, if we're downrevved to 31, yay
<ogra_> not for edge i think
<slangasek> ah, ok
<ogra_> sigh ... so i can only unpublish the whole package (all revisions)
<slangasek> ogra_: hmm but snap weld gave me 32 again. I thought the store was instantaneous!  how do I manually grab 31?
<ogra_> slangasek, i dont know ...
<slangasek> right
<ogra_> by default the store only gives you the latest ... and i cant mange to remove only one revision
<slangasek> ogra_: who should I hunt down here to fix it? ;)
<slangasek> ogra_: other option
<ogra_> i tried to uncheck the channle from the snap now ...
<ogra_> try again, probably that works
<slangasek> ogra_: can you point the beta channel to 31 for canonical-pc-linux and to 138 for ubuntu-core?
<slangasek> I'll try again, but it's inconveniently slow to iterate
<ogra_> done
<ogra_> 31 -> beta i mean
<slangasek> sweet
<slangasek> ah
<slangasek> what about for ubuntu-core? I only get to pick one channel for both
<ogra_> oh, wait thats i386
<slangasek> heh
<ogra_> 30 is actually amd64
<imexil> dholbach: FYI I changed the IPEPREFIX to $SNAPCRAFT_STAGE. Now the snap builds but the resulting snap package is not working. Basically it is not clear where the binary end up etc. Latest state is https://github.com/dietmarw/snaps/blob/master/ipe/snapcraft.yaml
<ogra_> pushed to beta too
<slangasek> um ok
<slangasek> thanks
<slangasek> and ubuntu-core?
<ogra_> yeah, its a bit weird since each upload bumps the revision and you need one upload per arch
<ogra_> on it
<slangasek> ta
<ogra_> looks like 138 and 139 are beta+edge already
<ogra_> so you should be fine
<slangasek> ogra_: sweeeeet thanks!
<ogra_> apw, https://code.launchpad.net/~ogra/+junk/kernel-test-snap ... that is what you actually need for a working kernel snap (amd64 only currently, i'm about to add all other arches til EOW) ... i guess it makes sense if you guys take that over once i have it done
<ogra_> that should then auto-upload to the store from LP snap builds
<mup> PR snapd#1598 opened: Implement a fuse interface <Created by stgraber> <https://github.com/snapcore/snapd/pull/1598>
<stgraber> ogra_: ^ (I won't actually need it, but hopefully it does cover the bits you need)
<ogra_> crap, the gadget in the store is also broken ... so i cant do the final test for josepht's fix :/
 * ogra_ hugs stgraber 
<stgraber> ogra_: given that my use case needs a lot more things and I'll be just running everything using a lxd interface, I didn't really get to test this so much. It may be that you need to add a few bits to the seccomp part maybe. Anyway, that's certainly a start and should work for some fuse fs.
<ogra_> stgraber, i'll poke around in it once i have some time for that
<bjf> ppisati_, have you uploaded a kernel snap to the store recently?
<ogra_> bjf, perhaps it was mb
<bjf> ogra_, we are trying to find out who uploaded the kernel snap to the store .. was not me
<ogra_> *mvo
<ogra_> bjf, seems someone also uploaded a gadget called just "pc" so it seems someone is working on that ... try to hunt down mvo
 * ogra_ dances 
<ogra_> \o/
<bjf> ogra_, hunting ...
<ogra_> sergiusens, josepht, patch verified, my os snap looks fine and i have a properly booting image
<ogra_> and on that note ...
 * ogra_ is off to the dentist ... back in 1-2h
<mup> PR snapd#1595 closed: many: make seed.yaml on firstboot mandatory and include sideInfo <Reviewed> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1595>
<dholbach> imexil, looks like stuff is not copied over from stage/ to prime/
<imexil> Yes. But I'm a bit at a loss since my lack of understanding of the internals. I assumed replicating the typical compiling workflow would be good enough. But looks like creating snaps is much more evolved.
<imexil> *involved
<imexil> I couldn't find any debug flags to turn on to see what is or is not done during building the snap. Are there any "verbose" switches?
<bjf> ogra_, apw yes it was mvo
<mup> PR snapcraft#693 closed: Implement "oneshot" daemon type <Created by stgraber> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/693>
<mup> Bug #1607344 opened: snap gives confusing error messages if snap login was ran with sudo <Snappy:Triaged> <https://launchpad.net/bugs/1607344>
<kalikiana> imexil: Did you look through parts/*/install where the files are? That's the first step I take if something appears to be missing
<kalikiana> I'm not sure that snapcraft does anything "special" during the build itself. It's mostly invoking make with the variables you defined.
<kalikiana> imexil: A basic fault could be that the default PREFIX is something inconvenient, like usr/local which isn't where you expect binaries in the final package - the convention is the same as a typical Linux-based distro, /usr/ or /
<jdstrand> stgraber (and zyga): personally, I would be ok with the shared-within-a-snap mount namespace because that would also solve the "/tmp shouldn't be separate" bug and conform to our design goal of "everything within a snap should be able to work together". That said, there has been resistance to that approach, so I'll let others comment
 * apw has just built the same snap in a xenial environment and in a yakkety environment (simple hello-world.c test) and the X one is 4k and the Y one is 600K
<jdstrand> stgraber: as for 'unconfined', we can discuss that in the PR but I don't think we'll want it to be named that based on previous design goals. the policy needs to be what it needs to be, but 'unconfined' won't be the name of the interface
<ahoneybun> trying to snap the new pithos release, wish me luck lol
<jdstrand> stgraber: aka, it should be named 'lxd' and docker's should be named 'docker'
<dholbach> imexil, I'd suggest sending a quick mail to snapcraft@lists.snapcraft.io asking for help
<ahoneybun> heyo dholbach
<dholbach> hi ahoneybun
<imexil> kalikiana: The problem is that the PREFIX can not be anything that is not writeable by user. I've now used $SNAPCRAFT_STAGE and after running `snapcraft`  the dir structure looks like: http://zb.dwe.no/?113bba383c80bdb9#gYrjz3cktMYOrRDu9OOmh62aQxN9YK0LyTManzrP978=
<ahoneybun> got time to debug a snap?
<stgraber> jdstrand: yeah, zyga already told me I should go with a lxd one which is effectively unconfined rather than make this generic
<imexil> dholbach: Yes probably a good idea.
<ahoneybun> yaml: http://pastebin.ubuntu.com/21269089/
<stgraber> zyga: so I just sent https://github.com/snapcore/snapd/pull/1598 (as mentioned before, we won't actually need it but ogra_ apparently has a use case for it :))
<mup> PR snapd#1598: Implement a fuse interface <Created by stgraber> <https://github.com/snapcore/snapd/pull/1598>
<ahoneybun> I'm getting local source is not a directory
<kalikiana> imexil: PREFIX=/usr is perfectly writable by the user as it's going to become parts/*/install/usr/ anyway
<ahoneybun> most likely did something wrong with curl and tar
<jdstrand> stgraber: and no, you didn't screw something up with regard to the private mount namespace
<kalikiana> imexil: I don't actually know what SNAPCRAFT_STAGE is. I haven't seen that in any docs. What does it point to?
<ahoneybun> ohhh
<ahoneybun> it's building
<ahoneybun> false alarm
<ahoneybun> just some stuff from curl
<jdstrand> tianon: hi!
<tianon> jdstrand: http://blogs.gnome.org/markmc/2014/02/20/naked-pings/ (this is an automated contentless pong to mirror your contentless ping - please provide more information and I'll respond when I'm around and have a minute)
<jdstrand> tianon: boy, I was just greeting you before I responded :) Maybe you should adjust your bot :)
<ahoneybun> so I changed the source to : ./ and it does something but fails
<ahoneybun> autoreconf -i returns with non-zero exit status 1
<jdstrand> tianon: anyway, re docker> you technically can do two interfaces (one for client and one for server) but snappy is designed for an interface to have two sides: a 'slots' side and a 'plugs' side
<jdstrand> tianon: the server implements the 'slots' side and the client the 'plugs' side
<ahoneybun> http://pastebin.ubuntu.com/21270061/
<imexil> kalikiana: it points to the stage dir. I found it described here: https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-advanced-features/
<jdstrand> tianon: when a snap provides a slot-implementation, that makes available the slot to be plugged by other snaps
<imexil> dholbach: Mail sent. (for moderation since I wasn't aware that it's for subsribed users only)
<jdstrand> tianon: in this case, you'd write a patch to snapd that implements the 'docker' interface. Then the docker snap would 'slots: [ docker ]'. when a user installs the docker snap, then 'snap interfaces' would show it as available and a client snap could 'plugs' it. eg, a client snap might 'plugs: [ docker ]'
<ogra_> stgraber, zyga, i even have a shiny bug for it... bug 1603113
<mup> Bug #1603113: add fuse filesystem interface <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1603113>
<jdstrand> tianon: more concretely, the docker snap's daemon command would 'slots: [ docker ]' and the docker interface implementation would put the apparmor rules needed for the daemon to run in PermanentSlotAppArmor and the daemon's seccomp rules in PermanentSlotSecComp
<jdstrand> tianon: then you put the rules for the client to connect to the server in ConnectedPlug[AppArmor|SecComp] and the rules for the server to connect to the client in ConnectedSlot[AppArmor|SecComp]
<ahoneybun> how do I tell snappy to look into parts/pithos-download/src/ ?
<dholbach> thanks imexil
<ahoneybun> dholbach: ^
<dholbach> ahoneybun, do you want to copy things over? or do you use some build system?
<jdstrand> tianon: if you haven't already, I suggest you read zyga's blog series: http://www.zygoon.pl/2016/04/snappy-snapcraft-and-interfaces.html and take a look at the the location-observe interface (interfaces/builtin/location_observe*.go)
<dholbach> ahoneybun, source-subdir for the latter ("snapcraft help sources" explains this)
<ahoneybun> there is a autogen.sh file in there thast needs to run
<ahoneybun> reading from here: https://github.com/pithos/pithos/wiki/Installing-from-Source
<dholbach> ahoneybun, autotools plugin with source-subdir then
<ahoneybun> source: source-subdir?
<kalikiana> imexil: Hmm thanks. Should "ipe" have an install target? Do the logs show its installing anything at all? I notice plugin: make but no *Makefile in parts/ipe/build
<mup> PR snapcraft#694 opened: Pass --root to the python3 plugin on build <Created by blakerouse> <https://github.com/snapcore/snapcraft/pull/694>
<ahoneybun> dholbach: http://pastebin.ubuntu.com/21269089/
<jdstrand> tianon: /me notes he meant to say PermanentSlotSnippet instead of PermanentSlotAppArmor/SecComp and the same for PermanentPlug*
<ahoneybun> this is the current yaml
<jdstrand> tianon: and ConnectedPlug*
<jdstrand> tianon: the blog post and the location-observe interface should make things clear
<dholbach> ahoneybun, I'm not sure... do you want me to figure this out for you now?
<ahoneybun> mm help me figure it maybe
<ahoneybun> does not have to be now now
<dholbach> ok
<ahoneybun> man snapcraft is picky about spacing
<ogra_> nessita, help ?
<ogra_> Launchpad uploaded this snap package to the store, but the store failed to
<ogra_> scan it:
<ogra_>   Can not create a new package with name ubuntu-core, multiple origins for ubuntu-core are not allowed.
<ogra_> what can we do there ?
<ahoneybun> making some progress dholbach
<ahoneybun> thanks to the playpen I've simplifed my yaml a lot
<kyrofa> ahoneybun, it has to be valid YAML :)
<kyrofa> If YAML isn't spaced right it can't be parsed
<ahoneybun> well I got to the point that it found the autogen.sh file
<ahoneybun> it said it was missing intltoolize
<nessita> ogra_, let me check
<ogra_> nessita, the ubuntu-core snap recently got changed to shared maintainership ... i could imagine that is realted
<nessita> ogra_, are you uploadingas yourself, and you can collaborate with the ubuntu-core package?
<ahoneybun> mm missing appstream.xml.m4?
<ogra_> nessita, yes, to both, i can manage it in myapps and i can upload it manually
<ogra_> jzst not through LP
<ogra_> *just
<ahoneybun> trying again
<dholbach> ahoneybun, how about this? http://paste.ubuntu.com/21272597/
<dholbach> (as you can see, I nicked the build plugin from autotools)
<dholbach> and we should probably file a bug for the autotools plugin to respect autogen.sh as well
<dholbach> ... or to allow specifying the build script
<ahoneybun> dholbach: http://pastebin.ubuntu.com/21272663/
<ahoneybun> this going somewhere
<dholbach> ahoneybun, can you try what I pasted earlier?
<ahoneybun> it's priming!
<dholbach> because that works for me
<ahoneybun> snapping!
<dholbach> what is mqtt-paho/python3 needed for?
<dholbach> ok
<ahoneybun> it needed python so I thought
<ahoneybun> mm
<ahoneybun> http://pastebin.ubuntu.com/21272895/
<ahoneybun> something about no module named gi
<dholbach> python3-gi maybe?
<ahoneybun> plugin?
<ahoneybun> it built but
<dholbach> no, in stage-packages
<dholbach> http://snapcraft.io/docs/build-snaps/syntax
<ahoneybun> it is in the build-packages
<ahoneybun> on I saw that
 * ahoneybun looks anyway
<ahoneybun> the docs are pretty good
<dholbach> or check out http://snapcraft.io/docs/build-snaps/parts
<dholbach> stage-packages lists the dependencies needed to actually run the contents of the snap. Theyâll be packed into the final snap. Here, the requirement is for the hello-world part to download and unpack libqt5gui5 with all its dependencies. This method can reuse any of the 48000 .deb packages that traditional Ubuntu provides. Itâs really that easy: just specify the packages you need embedded into your snap
<ahoneybun> alright cool let me try doing that
<ahoneybun> did you want me to test your yaml too?
<dholbach> no worries, if yours works, go ahead and use that
<ahoneybun> am I allowed to upload it to the store if it works well?
<ahoneybun> or do I need permission from the developer?
<dholbach> no, you can just upload
<ahoneybun> alright cool
 * ahoneybun needs to get his laptop charger
<ahoneybun> I'm getting a glib error
<ahoneybun> mm
<timothy> ahoneybun: which one?
<ahoneybun> http://pastebin.ubuntu.com/21273934/
<ahoneybun> I love chrome syncing <3
<timothy> ahoneybun: it seems a wrong prefix error, since it looks for /share intead of /usr/share
<seb128> timothy, what's your snapcraft.yaml?
<ahoneybun> so looking in the wrong place
<timothy> seb128: not mine :P
<seb128> sorry
<seb128> ahoneybun, ^
<seb128> ah, http://pastebin.ubuntu.com/21272663/
<seb128> so yeah
<ahoneybun> well I added a stage-package
<seb128> ahoneybun, you hit bug #1590831
<mup> Bug #1590831: having prefix='' by default is non standard and confusing <Snapcraft:New> <snapcraft (Ubuntu):Confirmed> <https://launchpad.net/bugs/1590831>
<seb128> you can use "configflags: [--prefix=/usr]"
<seb128> comment on the bug as well to say that's you got confused by the issue
<seb128> it might help to convince kyrofa & co that it's an issue
<ahoneybun> seb128: where do I put that line
<seb128> ahoneybun, under "      plugin: autotools" for example
<timothy> if you don't like /usr you can use prefix=/
<timothy> maybe :P
<mup> PR snapcraft#695 opened: Add process-dependency-links option to Python plugins <Created by OddBloke> <https://github.com/snapcore/snapcraft/pull/695>
<ahoneybun> done seb128
<ahoneybun> trying another buil
<ahoneybun> *build
<ahoneybun> dholbach: once it runs I'll see if I can remove mqtt-paho/python3
<zyga> stgraber: looking
<ahoneybun> seb128: that is not the issue
<ahoneybun> it's not in /usr/share/pithos/ either
<ahoneybun> mm
<ahoneybun> the heck
<ahoneybun> it's in prime/user/share/pithos though
<ogra_> sergiusens, hmm, so trying to upload the new ubuntu-core to the store it fails complaining that confinement should not be set for type: os ... i guess we need another change
<seb128> ahoneybun, ah, that fun bug
<ogra_> sergiusens, i guess if i leave it out in snapcraft.yaml the build will still push it into snap.yaml in the resulting snap ?
<seb128> ahoneybun, you basically hit bug #1583250
<mup> Bug #1583250: upstream use of build-time defined DATADIR incompatible with snaps relocation <snap-desktop-issue> <Snapcraft:New> <Snappy:New> <snapcraft (Ubuntu):Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1583250>
<ahoneybun> XD
<kyrofa> ogra_, indeed it will
<kyrofa> ogra_, I didn't know about that requirement :P
<ogra_> so we need to prevent that then
<ogra_> kyrofa, well, i blame jdstrand :)
<ogra_> 'confinement' should only be specified with 'type: app' lint-snap-v2_confinement_valid
<ogra_> i guess snapd or u-d-f dont really care about that field, so we could probably just fix it in the reviewer tools
<ogra_> (fix = ignore)
<ahoneybun> any way around it seb128?
<mup> PR snapcraft#696 opened: Replace 'strip' with 'prime' on intro page and step options <Created by bogdanap> <https://github.com/snapcore/snapcraft/pull/696>
<seb128> ahoneybun, you can try to --prefix=/snap/pithos/current/usr and organize: snap/pithos/current/usr: usr
<ahoneybun> organize is under the prefix?
<seb128> yes
<seb128> it's a hack
<seb128> but prefix makes things installed where you point
<seb128> but snapd relocates
<seb128> so you end up having files are /snap/pithos/current /snap/pithos/current/usr if you don't reorganize
<ahoneybun> I'm writing organize wrong
<ahoneybun> getting validatiing issues
<ahoneybun> the docs don't write an example of it
<ahoneybun> oh
<seb128> organize:
<seb128> organize: [ snap/pithos/current/usr: usr ]
<seb128> I guess?
<seb128> or - snap/pithos/current/usr: usr
<ahoneybun> none of those
<ahoneybun> [{' ': ' '}]
<seb128>         organize:
<seb128> snap/gedit310/current/usr: usr
<ahoneybun> is what the error says
<seb128> try like that
<seb128> with the current name
<ahoneybun> mapping valuse are not allowed here
<ahoneybun> *values
<seb128> can you share your snapcraft.yaml?
<ahoneybun> yea
<ahoneybun> http://pastebin.ubuntu.com/21276502/
<ahoneybun> funny thing
<ahoneybun> I'm making a snap using a snap
<ahoneybun> XD
<kyrofa> ahoneybun, "organize: snap/pithos/current/usr: usr" is not valid yaml
<ahoneybun> using the Atom editier
<timothy> snapception
<ahoneybun> yea lol
<seb128> ahoneybun, sorry, just got on a new line for the pair
<seb128> ahoneybun, like in https://github.com/8none1/gedit310/blob/master/snapcraft.yaml#L19
<ahoneybun> so far I have not found a snap that uses organize to learn from
<seb128> ahoneybun, ^
<ahoneybun> now it can't find python3-dbus1 in the cache
<ahoneybun> the heck
<seb128> weird
<seb128> can you pastebin the error?
<ahoneybun> http://packages.ubuntu.com/search?suite=xenial&section=all&arch=any&keywords=python3-dbus1&searchon=names
<ahoneybun> I can't find it here either
<ahoneybun> ohhh
<ahoneybun> no 1
<ahoneybun> fixed
<ahoneybun> I did not see the error before because of the organize thing
<ahoneybun> snapping now
<ahoneybun> this will be the last build for a few hours g2g out in a bit
<Pharaoh_Atem> zyga: I just saw your email
<ali1234> how do i snap a service?
<ahoneybun> mm why am I getting that gi module error again
<ahoneybun> I have it in stage-packages
<seb128> ahoneybun, oh, my fault I guess
<seb128> the reorganize probably move it
<ahoneybun> most likey
<seb128> ahoneybun, try moving stage-packages to a different part like in the gedit example I shared
<ahoneybun> ok
<seb128> that's better as well because it means you can clean/rebuild pithos without redownloading all the debs every time
<kalikiana> ali1234: http://snapcraft.io/create/ see "daemon: simple"
<ahoneybun> different part?
<ahoneybun> the deb: ?
<seb128> ahoneybun, ahoneybun like in https://github.com/8none1/gedit310/blob/master/snapcraft.yaml#L19
<seb128> sec
<ahoneybun> oh line 19
<seb128> ahoneybun, http://paste.ubuntu.com/21278483/
<seb128> ahoneybun, like that
<seb128> ahoneybun, it makes the deb build a different element so you don't need to redo that part every time you build the source
<seb128> also it means the reorganize is only going to apply to the pithos build
<seb128> not to the deb content
<ahoneybun> what plugin nil?
<seb128> oh right
<seb128> yes
<ahoneybun> yea running now
<seb128> :-)
<ali1234> kalikiana: if you make hello-world into a simple daemon, wouldn't it just start and then immediately exit indefinitely?
<ogra_> slangasek, FYI, i just re-owned the snap build for ubuntu-core to the snappy-dev team, if you go to https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core you should see a "request builds" link ... (i just noticed you are team admin for snappy-dev :) )
<ali1234> or until init decided it was respawning too fast and then disabled it...
<kalikiana> ali1234: I think the assumption is that hello-world keeps running. Otherwise it wouldn't make sense as a service.
<ali1234> it's GNU hello world
<ali1234> it just prints "hello world" and then exits
<kalikiana> No that's not what it is. It's a node application.
<ogra_> depends which hello-world package you refer to :)
<ogra_> there are plenty of them in the store
<kalikiana> Too many if you ask me...
<ali1234> source: http://ftp.gnu.org/gnu/hello/hello-2.10.tar.gz
<ogra_> the canonical owned one ships a bunch of sub commands
<ogra_> hello-world.env ... hello-world.evil and hello-world.sh
<kalikiana> ogra_: I do like the hello-world.env for the first steps into a snappy world. But there's no way to tell this from any of the others, let's be honest the name should've been reserved or an actually meaningful name should've been used.
<ogra_> +1
<ogra_> but it is what it is now ...
<kalikiana> And of course using two other hellos in the tutorial isn't helping
<kalikiana> ali1234: For the moment, try to re-read the steps in the service section and ignore the previous GNU hello example.
<kalikiana> It's unrelated.
<ali1234> steps?
<kalikiana> Sentences... words... whatever is said there :-)
<ali1234> i keep reading them over and over and they aren't giving me any useful information :(
<ali1234> as far as i can tell i just define an app like normal, but i also say "daemon: simple"
<ali1234> assuming it is a simple daemon, which it is in my case
<ogra_> yeah
<ogra_> thast line tells snapd to create a systemd unit for it at install time
<ali1234> called hello-service?
<ogra_> iirc it is a bit more complext ... sanp.foo.bar.baz ...
<ali1234> can it be named the same as the app?
<ogra_> *snap.
<ogra_> check with systemctl
<didrocks> Chipaca: do you know if there is any way to get the whole list of snap for my device in the store? (now search needs to have a string as a parameter)
<didrocks> find*
<kalikiana> 'snap find' works fine here, if you are patient
<didrocks> hum, here I have "empty search query"
<ogra_> yeah
<ogra_> the latter is the latest
<ogra_> you cant search with empty string anymore
<didrocks> right
<didrocks> which is annoying to get a list of "snap of the months" :p
<ogra_> didrocks, https://plus.google.com/+Uappexplorer-ubuntu/posts
<ogra_> ;)
<ogra_> you can even see them roll in (semi-live ... its a bit delayed)
<jibel> didrocks, you can do "snap find ." that'll return everthing apparently
<didrocks> ogra_: yeah, I was thinking about using this for the coming months
<didrocks> oh dot!
 * didrocks hugs jibel
<didrocks> thanks! that does the trick
<ogra_> didrocks, that only returns 100 results though (hardcoded at the store side)
<didrocks> how does it select what to return?
<ogra_> ogra@styx:~/Devel/branches/snapcraft$ snap find .*|wc -l
<ogra_> 101
<didrocks> it goes to x
<stgraber> sergiusens: snapcraft.io says to use "upload", the command line tool says to use "push" instead, guess the website should be updated
<didrocks> so just no x y z ? ;)
<ogra_> dunno, but there are more than 100 snaps
<ogra_> ... in the store
<didrocks> ok, let's say it's taking ascii order
<jibel> didrocks, http://paste.ubuntu.com/21281325/
<didrocks> jibel: that's "snap find ."? or juts a shell script?
<didrocks> just*
<jibel> didrocks, for x in a ...; find $x ... ;)
<ogra_> haha
<ogra_> quite awkward that we need such hacks instead of just having the store properly returning more than 100
<josepht> I think the intention is to not have 'snap find' return a list of "all" snaps in the store
<ogra_> yes, i understand the intention ... i just dont agree with it ;)
<ogra_> (it annoys me on the phone since i use it ... in android i can go on for hours to browse the store apps)
<ogra_> (on ubuntu it stops at 100 apps)
<jibel> if only it was 100 random apps, but it returns always the same
<ogra_> i suspect that is why people always say there are no apps in ubuntu phone ... if they would see the whole list the experience would be quite different :)
<josepht> ogra_: fwiw, I agree.  I want to be able to aimlessly browse them all as well.
<jibel> ogra_, they would discover all your webapps, that would be such an experience ;)
<ogra_> !
<ogra_> see !
<mup> Bug #1607297 changed: Error with an example Python snap <Snapcraft:New> <Snappy:Invalid> <https://launchpad.net/bugs/1607297>
<JamesTait> "< ~didrocks> how does it select what to return?" - the same way we did for Clicks: highest relevance, best ratings average, most recently updated.  The fact we can't browse endlessly on the Click scope is a bug in the scope, the server has pagination but the scope doesn't use it.
<didrocks> JamesTait: oh, interesting :)
<JamesTait> There's also the size parameter to the API endpoint to get more than 100 results.  This is all documented at https://search.apps.ubuntu.com/docs/#pagination-of-collections (formerly https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex#Pagination_of_Collections)
<didrocks> hum, we could may be hack something around this, would be better than the shell script for now :)
<mup> PR snapd#1599 opened: asserts,client: switch snap-build and snap-revision to be indexed by snap-sha3-384 <Created by pedronis> <https://github.com/snapcore/snapd/pull/1599>
<ali1234> well that didn't work
<ali1234> hmm i think it worked that time
<ali1234> oh wait, it didn't
<ogra_> funny monologue :)
<ali1234> http://paste.ubuntu.com/21293029/
<ali1234> doesn't work
<ali1234> doesn't create a service file, doesn't create a command in /snap/bin, doesn't even attempt to start anything when i install it
<ogra_> plugin: nil
<ogra_> ???
<ali1234> yes because it is already packaged
<ali1234> so i just stage it
<ogra_> and you are sure it ends up in the resulting snap ?
<ali1234> yes
<ogra_> and gmediarender is actually a daemon ?
<ali1234> meaning?
<ogra_> (i.e. it doesnt return)
<ali1234> yes, when you run it without arguments
<ali1234> http://paste.ubuntu.com/21293379/
<ali1234> that's /snap/gmediarender/current
<ali1234> the init.d is part of the package. i don't want to use it because it doesn't work
<ogra_> kyrofa, bug #1607459 for your pleasure
<mup> Bug #1607459: type:os should prevent adding "confinement" to the snap.yaml <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1607459>
<kyrofa> Thanks ogra_
<ogra_> ali1234, and when you install the snap you dont see systemd errors in the syslog ?
<ali1234> nope
<ali1234> [201393.122973] audit: type=1400 audit(1469724778.984:22): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.gmediarender.gmediarender" pid=3485 comm="apparmor_parser"
<ali1234> i see that
<timothy> correct
<ogra_> well, you should also see a start attempt of the service
<ali1234> there is no service for it to start, unless it has a really cryptic name
<ali1234> i did systemctl | grep media
<ali1234> all i see is the mounts
<ali1234> bbiab
<ogra_> ogra@styx:~/Devel/branches$ systemctl |grep upnp
<ogra_>   snap-upnp\x2dserver-1.mount                                                                 loaded active mounted   Mount unit for upnp-server
<ogra_>   snap.upnp-server.minidlna.service                                                           loaded active running   Service for snap application upnp-server.minidlna
<ogra_>   snap.upnp-server.webdav.service                                                             loaded active running   Service for snap application upnp-server.webdav
<ogra_> that is what i get for my upnp-server snap
<ogra_> so you shoudl actually see ...
<ogra_> snap.gmediarender.gmediarender.service
<tianon> jdstrand: epic, that helps a lot, thanks so much! :D (I've also adjusted by over-enthusiastic naked ping script O:)  I used to get folks pinging me with "tianon: hi" a _lot_ to check if I was online before asking me questions :P)
<ali1234> yeah i don't see that at all
<ali1234> ogra_: can i have your snapcraft.yaml please?
<ogra_> for the upnp-server ? thats a bit more complex, but sure ...  one sec
<ali1234> i just installed it from the store and it works
<ogra_> https://github.com/ogra1/upnp-server
<ogra_> indeed it does :)
<ali1234> well at least i got some service files anyway
<ali1234> this will actually be helpful for me, since i need a media server to test with :)
<ali1234> and gmediaserver sucks
<ali1234> don't suppose you know of another media renderer?
<ogra_> you can access it via webdav to dump files into it
<ogra_> (i always use nautilus' "connect to server" with: dav://$external_ip/)
<ali1234> gvfs consistently crashes on my system
<ali1234> https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1511626 - also affects gvfs-dav
<mup> Bug #1511626: gvfsd-smb crashed with signal 5 in g_settings_set_property() <amd64> <apport-crash> <vivid> <gvfs (Ubuntu):New> <https://launchpad.net/bugs/1511626>
<ahoneybun> seb128: it's looking in the wrong place again
<seb128> ahoneybun, :-/
<seb128> ahoneybun, pastebin?
<ahoneybun> the glib error about .gresource
<ahoneybun> let me get it
<seb128> ali1234, is that a snap or a deb?
<ali1234> seb128: which?
<seb128> ali1234, that gvfsd-smb bug is weird
<seb128> wth?
<ali1234> that's a deb. the one from the repos
<ahoneybun> seb128: http://pastebin.ubuntu.com/21299368/
<ahoneybun> brb
<ali1234> nothing to do with snappy, i;m just griping
<jdstrand> tianon: hehe - I was just trying to be friendly :)
<tianon> jdstrand: indeed! :D
<seb128> ali1234, can you "$ strace -f /usr/lib/gvfs/gvfsd-smb 2>&1 | grep schemas"?
<jdstrand> tianon: I can definitely relate to the motivation for that bot though. 'jdstrand: ping' just doesn't cut it :)
<tianon> hahaha yeah
<tianon> I get highlights on my phone too
<jdstrand> oh yeah
<tianon> so it's frustrating to be out somewhere and get "tianon: ping" as a notification
<jdstrand> that would be rough
<seb128> ahoneybun, can you pastebin your snapcraft.yaml? I guess it's going to be easier if I have a try there, it looks better but unsure why the resource is missing
<tianon> but "tianon: do you know XYZ about ABC?" is super useful and tells me whether I need to connect to irssi from my phone to reply :)
<ali1234> seb128: well lokk at that... it is opening something from /usr/local
<ahoneybun> seb128: http://paste.ubuntu.com/21278483/
<ali1234> /usr/local/share/glib-2.0/schemas/gschemas.compiled to be specific
<ahoneybun> wait
<seb128> ali1234, delete that one...
<seb128> ali1234, local install bitten users since linux :p
<ahoneybun> seb128: updated one
<ahoneybun> http://pastebin.ubuntu.com/21299830/
<seb128> ahoneybun, k, going to try it here
<ahoneybun> cool
<seb128> ahoneybun, is the resources not installed? ls  /snap/pithos/current/usr/share/pithos? do you know if that's supposed to be part of the make install or generated?
<ahoneybun> it is in the prime dir
<ali1234> seb128: still crashes though
<seb128> ali1234, same bt? can you pastebin the strace cmd?
<seb128> the ouput of the cmd I mean
<ali1234> http://paste.ubuntu.com/21300282/
<seb128> ali1234, you still have /usr/local lines, can you wipe out /usr/local/(share/)glib*?
<ali1234> i will nuke /usr/local
<seb128> or just move it away
<ali1234> still crashes, but maybe things are still in memory
<ali1234> hang on i will reboot
<ali1234> strace now says this http://paste.ubuntu.com/21300641/
<ahoneybun> any luck seb128?
<mup> PR snapd#1600 opened: many: various fixes around the `create-user` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/1600>
<seb128> ahoneybun, I didn't have the debs so it took a bit to build, almost done
<ahoneybun> oh ok
<ahoneybun> is there any docs for the file system of snaps?
<seb128> http://snapcraft.io/ has some details
<ali1234> seb128: still crashes
<ahoneybun> not much
<seb128> ali1234, interesting, does it do it if you start the process by hand from a cmdline?
<seb128> ahoneybun, what info are you after?
<ali1234> i don't know how to do that
<ahoneybun> where that /snap/pithos/current/ stuff it
<ahoneybun> like where to look for the file that seems to be missing
<ahoneybun> it is in the prime dir
<seb128> ali1234, what if you try "/usr/lib/gvfs/gvfsd-smb --spawner :1.9 /org/gtk/gvfs/exec_spaw/7"
<seb128> yes
<seb128> it's the prime that is mounter in /snap/pithos/current
<seb128> mounted
<ali1234> it says "call_spawned_cb: Error sending a message: The name :1.9 was not provided by any .service files (g-dbus-error-quark, 2)"
<ali1234> then it just continues to run doing nothing
<seb128> ali1234, how do you trigger the crash usually?
<ahoneybun> so it is in /prime/usr/share/pithos/pithos.gresource
<ali1234> open thunar and type a smb: or dav: url into the location
<ali1234> or anything else that uses gvfs
<seb128> ali1234, does that crash the process you just started?
<ali1234> this ia guaranteed crash 100% of the time
<seb128> ahoneybun, arg, sorry
<seb128> ahoneybun, I though your snap was name "pithos"
<ali1234> seb128: no
<ahoneybun> well pithos-ahoneybun is the name
<seb128> ahoneybun, --prefix=/snap/pithos-ahoneybun/current/usr
<seb128> then
<ahoneybun> ohhh
<seb128> same for the organize rule
<ahoneybun> building now
<ahoneybun> this will work!
<ahoneybun> I will keep trying
<seb128> :-)
<ahoneybun> Franz was a fail though
<ogra_> this will work unti you hit a distro where snaps dont get installed to /snap
<ogra_> :P
<ahoneybun> one step at a time lol
<seb128> ogra_, well I raised that issue several time but seems it's not judged important enough to be discussed yet, so let's see once we get there
<seb128> I can foresee what comes though
<seb128> it's going to happen
<seb128> we are going to get online rants about snaps
<seb128> and then it's going to be a priority to address
<ogra_> yeah, and lots of fun with ad-hoc sprints and such
 * ogra_ already looks forward to the traveling :P
<ogra_> (though i must admit i have never used that hack :P ... *my* snaps will work :) )
<seb128> yeah, you snap code from bc writen in stones :p
<kyrofa> Yeah I've not run into it either
<kyrofa> I suspect seb128 picks projects to snap based on whether or not this hack is needed :P
<ogra_> seb128, you mean nethack isnt a modern MMO ?
<kyrofa> Hahaha
<seb128> kyrofa, I'm just helping ahoneybun here
<kyrofa> seb128, I know, I'm just kidding :)
<seb128> :-)
<kyrofa> seb128, it's definitely a problem
<kyrofa> seb128, but the workaround that's needed is a hard one
<kyrofa> So it's slow
<ogra_> there is nothing five stacked wrapper scripts cant fix :P
<seb128> ahoneybun, seems to go further, need to stage-package gir1.2-gtk-3.0 now
<ahoneybun> oh
<ahoneybun> I'm building still lol
<kyrofa> ogra_, typically I agree, but there are really some projects that write this path into binaries
<seb128> kyrofa, the proper fix would be easy, just provide a stable location, e.g /var/lib/snap/name that point to the real mount
<ahoneybun> should I cancel it and add that?
<ahoneybun> seb128: ^
<seb128> ahoneybun, yes
<kyrofa> seb128, I'm not sure we can even guarantee that across distros
<seb128> why not?
<ahoneybun> I keep after every build so that's what slows me
<seb128> kyrofa, just make them in XDG_RUNTIME_DIR?
<seb128> ahoneybun, looking at your build-packages you are going to need more stage-package
<seb128> ahoneybun, if there is a deb around look at its depends and add that as stage
<seb128> apt-cache show gstreamer1.0-plugins-good, gstreamer1.0-plugins-bad, python3-pkg-resources, python3-gi, python3-gi-cairo, gir1.2-gtk-3.0, gir1.2-gstreamer-1.0, gir1.2-gst-plugins-base-1.0
<seb128> ups
<seb128> ahoneybun, ^ those
<ahoneybun> I added what the github page showed
<ahoneybun> that's to build no?
<seb128> no
<seb128> those ^ are runtime depends
<seb128> you need the bindings for cairo/gtk/gstreamer
<ahoneybun> that was apt-cache show pithos right?
<mup> PR snapd#1601 opened: partition: clear snap_try_{kernel,core} on success <Created by mvo5> <https://github.com/snapcore/snapd/pull/1601>
<seb128> ahoneybun, yes
<ahoneybun> alright put it in stage-packages
<kyrofa> ahoneybun, seb128 note that snapcraft will pull in libs if ldd shows them
<ahoneybun> I'm getting a error about file paths in common
<seb128> kyrofa, is that true for python instrospection bindings as well?
<seb128> I guess not
<ahoneybun> but different contents
<seb128> ahoneybun, pastebin?
<kyrofa> seb128, probably not, I figure that stuff is dlopened
<ahoneybun> http://pastebin.ubuntu.com/21305247/
<ahoneybun> most likely need desktop/gtk3
<seb128> ahoneybun, can you share the snapcraft.yaml?
<ahoneybun> http://pastebin.ubuntu.com/21305538/
<seb128> hum
<seb128> I wonder if that got fixed in a new snapcraft
<seb128> kyrofa, ^ do you know? the file conflict thing
<ahoneybun> I should have a new version
<ahoneybun> the newest
<kyrofa> ahoneybun, seb128 indeed, that bug was fixed in the version being SRUd now
<seb128> ahoneybun, install https://launchpad.net/ubuntu/+source/snapcraft/2.13.1/+build/10516627/+files/snapcraft_2.13.1_all.deb
<kyrofa> ahoneybun, until that fix gets to you you can filter one (or both) of them out using the stage and snap keywords
<ahoneybun> which are?
<kyrofa> ahoneybun, https://github.com/snapcore/snapcraft/blob/master/docs/snapcraft-syntax.md
<kyrofa> ahoneybun, ways to filter files out from parts
<ahoneybun> so - file to exclude
<ahoneybun> and * to include?
<ahoneybun> not sure
<seb128> ahoneybun, just install the new snapcraft with dpkg ^
<ahoneybun> yea just did that lol
<seb128> ahoneybun, you need gir1.2-secret-1 as well
<seb128> just hit that one missing, rebuilding...
<ahoneybun> oh
<ahoneybun> it's priming for me
<seb128> :-/
<ahoneybun> got a error about the desktop-launch
<seb128> iterating on snapcraft is not as easy as it should
<seb128> tends to need to wipe lot of the state and restart
<seb128> oh?
<seb128> which one?
<ahoneybun> well I have desktop-launch pithos
<ahoneybun> but there is no executable for that
<ahoneybun> to install it I think it needs to run the ./configure and then the make install
<ahoneybun> so the bin is in /usr/local/bin/pithos
<ahoneybun> but with our changes
<ahoneybun> it should be snap/pithos-ahoneybun/current/usr/local/bin/pithos
<ahoneybun> trying that now
<ahoneybun> mm
<ahoneybun> the geddit did it different
<ahoneybun> the command desktop-launch does not exist or not executable
<seb128> ahoneybun, your snapcraft was starting the right command, we wouldn't have had the import errors from the code otherwise
<ahoneybun> seb128: http://pastebin.ubuntu.com/21308132/
<ali1234> hmm okay, my gvfs is fixed, thanks seb128!
<seb128> yw!
<ali1234> now back to snappy...
<seb128> ahoneybun, weird, is that since the snapcraft update?!
<seb128> need to go for dinner but I might be back later
<seb128> bbl
<ahoneybun> I updated to 2.13.1
<ahoneybun> let me do a clean build
<ali1234> so i actually do have a service file for gmediarender
<seb128> works here
<seb128> weird
<ahoneybun> it builds?
<ali1234> http://paste.ubuntu.com/21308595/
<ali1234> but the thing is it doesn't ever show in systemctl
<ali1234> ah... i need to say "systemctl -a"
<ali1234> snap.gmediarender.gmediarender.service     loaded    inactive dead      Service for snap application gmediarender.gmediarender
<ali1234> how do i clean up all the old snaps i have installed?
<ahoneybun> snap remove
<ahoneybun> snap list will show the ones installed
<ali1234> i just want to remove the old revisions
<ahoneybun> I'm getting so close!
<zyga> ali1234: snapd 2.11 (in proposed soon) will do this automatically
<ahoneybun> now down to some gtk-warning and apparmor issue
<ahoneybun> http://pastebin.ubuntu.com/21315880/
<stokachu> trying to run conjure-up -h and it just hangs https://www.irccloud.com/pastebin/KP42oVnq/
<stokachu> i did run snap install conjure-up --devmode to attempt to run conjure-up -h
<stokachu> it works in snap try prime mode
<ahoneybun> so running pithos runs
<jdstrand> ahoneybun: the apparmor issue is bug #1590679. there is an exploratory PR. we are getting close to deciding what the final implementation should be
<mup> Bug #1590679: Apps can't own session bus names (unity7 interface) <snap-desktop-issue> <snapd-interface> <Snappy:In Progress by jdstrand> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1590679>
<kyrofa> Hey jdstrand, I figure it's not a high priority, but has any progress been made on the upstream changes necessary for seccomp errno
<kyrofa> ?
<ahoneybun> jdstrand: I got around it some how
<ahoneybun> daemon: simple fixed it
<ahoneybun> no clue how
<jdstrand> kyrofa: tyhicks is/will be working on it now/soon
<kyrofa> jdstrand, alright thanks!
<jdstrand> tyhicks: what are your thoughts on CAP_IPC_LOCK wrt interfaces?
<jdstrand> tyhicks: I'm conflicted-- on the one hand, an app should be able to lock memory I think, but on the other, it could be used to keep from swapping. its sorta like the oom_score_adj/setpriority discussion (where if you raise the score of other processes with your uid, you effectively raised yours) and sorta bleeds into process-control where you can renice
<jdstrand> honestly, I'm surprised we haven't seen it come up yet
<tyhicks> jdstrand: we probably need to allow it (disallowing it can result in security issues) but document that it can be used to DoS other programs that try to lock memory
<jdstrand> tyhicks: that is what I was thinking. I have no idea how we would sensibly mediate that
<tyhicks> jdstrand: currently, we're not allowing any programs to lock memory so allowing it is an improvement even if there is some snap that (un)intentionally locks the maximum amount of memory
<jdstrand> yeah, we can handle abuse through store processes
<tyhicks> jdstrand: store processes is how we'll handle it today but, in the future, snap-confine could place cgroup limits, or maybe use apparmor's rlimit mlock rules, on a specific snap app that is lower than the system mlock limit
<tyhicks> jdstrand: snap-confine could also call setrlimit(RLIMIT_MEMLOCK, ...) before setting the seccomp filter (assuming that we're still blocking setrlimit())
<jdstrand> tyhicks: we allow setrlimit but not CAP_SYS_RESOURCE (in safe interfaces)
<jdstrand> tyhicks: but we could always arg filter RLIMIT_MEMLOCK
<jdstrand> tyhicks: ok adding capability ipc_lock to default template (no idea where else to put it-- speak up if it should be somewhere else) wich comment, and created incoming card with this conversation
<jdstrand> tyhicks: I guess I could create a manual connected interface
<tyhicks> jdstrand: I don't think memory locking is something we should expose to users
<jdstrand> yeah, that was my feeling too
<ahoneybun> what happens if a name on the snap store is taken?
<kyrofa> ahoneybun, only one account can publish a given name
<ahoneybun> someone is holding pithos - the name of the app I'm summiting
<ahoneybun> so I got pithos-1 lol
<ahoneybun> kyrofa: how do rev's work?
<ahoneybun> like I just upload the same version to the store and it changes the rev ?
<kyrofa> ahoneybun, they're assigned by the store when you upload
<kyrofa> ahoneybun, right, the version you set is just a human-readable string
<kyrofa> ahoneybun, the revision is used to determine which snap is newer than another
<ahoneybun> I want to keep 1.2.0 as that is the version of the app that I packaged
<kyrofa> ahoneybun, sure
<ahoneybun> do you think the dev of pithos grabbed the name?
<ahoneybun> hey seb128
<seb128> hey ahoneybun, saw the backlog, congrats on getting your snap to work ;-)
<ahoneybun> it seems to
<ahoneybun> pithos launchs it from terminal
<ahoneybun> at some times I can get it to show in Dash
<ahoneybun> seb128: http://imgur.com/a/Kdrti
<ahoneybun> :)
<seb128> nice!
<ahoneybun> I can't seem to find it in Dash though
<ahoneybun> it worked that one time
<ahoneybun> but I have uninstalled it a few times
<seb128> it should work if you have  a .desktop in setup/gui
<ahoneybun> I do
<ahoneybun> also a icon
<seb128> that gets installed in /var/lib/snap/desktop/applications
<seb128> and unity should pick it up
<ahoneybun> followed dosbox
<ahoneybun> from the snappy playpen
<seb128> k, unsure about that one, maybe an unity bug
<seb128> need to go though, time to sleep here
<seb128> bye
<ahoneybun> it does not put a bin in /snap/bin mm
<kyrofa> ahoneybun, can I see your yaml?
<kyrofa> ahoneybun, as well as your desktop file?
<mup> PR snapcraft#696 closed: Replace 'strip' with 'prime' on intro page and step options <Created by bogdanap> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/696>
<ahoneybun> kyrofa: yaml: http://pastebin.ubuntu.com/21334564/ ; desktop: http://pastebin.ubuntu.com/21334623/
<kyrofa> ahoneybun, you're saying installing that puts nothing in /snap/bin/ ?
<ahoneybun> nope
<ahoneybun> funny that it is not in snap list either
<ahoneybun> mm
<ahoneybun> what?
<kyrofa> ahoneybun, huh-- is it in /snap/ at all?
<ahoneybun> ohhh
<ahoneybun> it makes a dir
<ahoneybun> in /snap/
<kyrofa> ahoneybun, indeed
<ahoneybun> wait
<kyrofa> ahoneybun, I do see a problem with the desktop file, though
<kyrofa> ahoneybun, installing this snap should create a /snap/bin/pithos-ahoneybun.pithos-app binary
<kyrofa> ahoneybun, the .desktop file needs to Exec=pithos-ahoneybun.pithos-app
<ahoneybun> somehow I'm launching it
<ahoneybun> though it is not installed though apt
<ahoneybun> I built it from source
<ahoneybun> not sure how to remove it though
<kyrofa> ahoneybun, you mean via `make install` ?
<ahoneybun> yea
<kyrofa> ahoneybun, I don't suppose it also generates a `make uninstall` or `make remove` target?
<ahoneybun> that worked
<ahoneybun> added that to .desktop btw
<ahoneybun> so I was running the source built version...
<kyrofa> ahoneybun, makes sense
<ahoneybun> snapping it up again with the changes
<ahoneybun> still not making anything in /snap/bin
<kyrofa> ahoneybun, and it shows up in snap list?
<ahoneybun> so it made something in /snap though
<ahoneybun> yea
<kyrofa> ahoneybun, can you pastebin `ls /snap/` and `ls /snap/bin/` ?
<ahoneybun> http://pastebin.ubuntu.com/21337330/
<kyrofa> ahoneybun, please also pastebin `cat /snap/pithos-ahoneybun/current/meta/snap.yaml`
<ahoneybun> http://pastebin.ubuntu.com/21337591/
<kyrofa> ahoneybun, oh! It's a daemon
<ahoneybun> oh
<kyrofa> ahoneybun, that won't put anything in /snap/bin/, it'll generate a systemd unit file in /etc/systemd/system/
<ahoneybun> mm
<ahoneybun> well it needed to do a service
<kyrofa> ahoneybun, is that what you want? Those aren't launched by desktop files
<ahoneybun> which AppArmor has denied
<ahoneybun> kyrofa: http://pastebin.ubuntu.com/21338511/
<kyrofa> ahoneybun, as jdstrand mentioned earlier, that's bug ##1590679
<mup> Bug #1590679: Apps can't own session bus names (unity7 interface) <snap-desktop-issue> <snapd-interface> <Snappy:In Progress by jdstrand> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1590679>
<ahoneybun> yea I saw that.
<ahoneybun> darn
<ahoneybun> what does it mean when it fails to load canberra-gtk-module?
<ahoneybun> installing it with --devmode gives me that error
<wililupy> Did we change ubuntu-device-flash for gadget snaps?
<wililupy> I get an error no hardware description in Gadget snap.
<wililupy> trying to use --gadget=canonical-pc
#snappy 2016-07-29
<tgm4883> If I'm adding stuff to stage-packages, how can I create a snap without needing to rebuild the whole thing?
<qengho> tgm4883: "snapcraft clean" takes a few arguments. -s stage is probably it.
<tgm4883> qengho: just found this page http://snapcraft.io/create/ Currently rebuilding the whole thing, but I'll try that next
<qengho> tgm4883: fyi, "clean" and build dependency is a little screwy this week, but usually works. You might hit a bug and have to build more than should be strictly necessary.
<tgm4883> qengho: ok, good to know. Currently trying to move some deb packaging to snap packaging and finally got it to build with the binaries in the right directory. Now trying to fix "This application failed to start because it could not find or load the Qt platform plugin "xcb"."
<qengho> tgm4883: ah yeah.
<qengho> tgm4883: Do you have mention of "desktop/qt5" in your yaml?
<tgm4883> qengho: no
<qengho> tgm4883: Okay, I think there's a built-in wrapper for you. In your main part, use "after: [ desktop/qt5 ]"
<qengho> tgm4883: and make your command: desktop-launch $SNAP/yourrealprogrampath
<qengho> I *think*. This is new to me.
<tgm4883> ok, trying now
<tgm4883> qengho: this is what it looks like so far https://github.com/tgm4883/mythtv-snap/blob/master/snapcraft.yaml
<qengho> tgm4883: you are a brave brave man.
<tgm4883> qengho: heh, why is that
<mup> Bug #1607604 opened: the user created by create-user is not a sudoer <create-user> <Snappy:New> <https://launchpad.net/bugs/1607604>
<tgm4883> qengho: so I just did the snapcraft commands starting at stage, it seemed to pull int he desktop/qt5 stuff, but still getting the same error
<qengho> tgm4883: huh. No idea.
<tgm4883> I'm going to try rebuilding it again from scratch
<qengho> tgm4883: Is the 6 line yaml of just "plugin: nil" and "stage-package: [ mythtv ]" not work?
<tgm4883> qengho: you mean just use it to pull in the deb packages?
 * qengho nods.
<qengho> I like easy.
<tgm4883> I've not tried it
<tgm4883> I'll try it after this build
<qengho> If it works, you owe me a beer.
<tgm4883> heh
<tgm4883> Would that install everything inside the snap?
<qengho> tgm4883: that and all its deps, yes.
<qengho> Not sure about Recommends.
<tgm4883> qengho: so this http://paste.ubuntu.com/21368648/
<tgm4883> that doesn't work
 * qengho files a Pull Request for -190 line change.
<tgm4883> nm
<qengho> :)
<tgm4883> stage-packageS
 * qengho nods.
<tgm4883> running now
<tgm4883> So if this works, that's great and means it can run inside a snap
<tgm4883> which gives me something to go on
<tgm4883> I wonder if "--runprefix=/usr" is causing me issues in the other build
<qengho> Oh, yeah, that looks suspicious.
<ahoneybun> where is it getting the deb?
<qengho> ahoneybun: Ubuntu repo, here.
<tgm4883> ahoneybun: well ideally it would build from source, but for the other test it would get the deb from the ubuntu repos
<ahoneybun> that yaml is missing that
<qengho> tgm4883: you need a command: in that pasted YAML.
<tgm4883> ahoneybun: this yaml  https://github.com/tgm4883/mythtv-snap/blob/master/snapcraft.yaml ?
<tgm4883> qengho: yea I noticed that, building again
<ahoneybun> pulling from git, nice
<tgm4883> qengho: yea using the deb doesn't work either. Getting some permissions issues
<ahoneybun> pastebin?
<ahoneybun> I just started today but I'll try lol
<tgm4883> ahoneybun: of running after using the deb package? I'd rather work out the building from source issue
<ahoneybun> from source would help get it on other distros
<tgm4883> what's the build variable for the install directory?
<qengho> tgm4883: "some permissions"?
<qengho> Are they secret?
<tgm4883> qengho: http://paste.ubuntu.com/21369624/
<qengho> tgm4883: peek in /snap/mythtvw/x2/usr/bin/mythfrontend and see if you can put the pidfile in a sane place and if you can get that dialog_functions to be loaded from $SNAP/...
<qengho> ("A sane place" is probabyly under $SNAP_DATA/...
<qengho> )
 * qengho afk in 10 minutes.
<mup> Bug #1607662 opened: "home" plug doesn't work with encrypted home dir <Snappy:New> <https://launchpad.net/bugs/1607662>
<kalikiana> Question: how would a snap go about accessing build tools like the go snap?
<kalikiana> It seems pointless to have a compiler snapped if other snaps can't use it
<kalikiana> So I will assume there's a way somehow
<didrocks> kalikiana: I don't think we are at the point (apart for devmode), where snap is suitted for that (yet)
<didrocks> I think we'll get the same kind of "shell" interface that will work for this as well
<mup> PR snapd#1602 opened: interface: add kernel-module interface for module insertion <Created by arges> <https://github.com/snapcore/snapd/pull/1602>
<kalikiana> didrocks: Hmm would it work if my snapcraft.yaml is confinement:strict but I'd say "use --devmode if you want to access xyz?"
<mup> Bug #1607662 changed: "home" plug doesn't work with encrypted home dir <Snappy:New> <https://launchpad.net/bugs/1607662>
<kalikiana> Or I need to investigate some kind of distcc-like setup
<mup> PR snapcraft#680 closed: Rewrite shebangs generated by the python plugins <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/680>
<didrocks> kalikiana: that's possible AFAIK (with the confinement and so on)
<didrocks> but keep in mind you have your own mount namespace, so you can have some surprises, even confined
<mup> PR snapcraft#694 closed: Pass --root to the python3 plugin on build <Created by blakerouse> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/694>
<imexil> Hi I'm using a git repo as source but would like snapcraft to pull down a specific tag which is on a non-master branch. Simply specifying source-tag seems not to be enough. Do I have to specify the git branch as well?
<imexil> never mind it looks like it is actually pulling down the correct tag.
<didrocks> imexil: you have also the "source-branch" parameter if you want (snapcraft help sources)
<imexil> didrocks: Ah thanks. It feels like finding the correct (up to date) documentation is my biggest challenge at the moment ;-)
<didrocks> imexil: heh, yeah, we are woroking on this :)
<imexil> didrocks: Probably not easy with snappy still being such a moving target.
<didrocks> that's exactly the biggest issue :) but with the start of snapcraft.io and crafting codelabs, we'll get there
<imexil> Yes I was going to say it would help already when all doc resources would be available from snapcraft.io and not some there and some on ubuntu dev pages and some on ubuntu wiki
<sergiusens> ppisati_ https://github.com/snapcore/snapcraft/pull/689
<mup> PR snapcraft#689: kernel plugin: kernel targets depending on debarch <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/689>
<ppisati_> sergiusens: /me tests it
<Guest40416> Hi, I Have a simple question: I try to associate an icon to my snap, using a desktop file in /setup/gui/aa.desktop and /setup/gui/aa.png. In the examples, I saw that the path to the icon in the desktop file is ${SNAP}/meta/gui/aa.png but it does not work. My guess is that the varable ${SNAP} is not correctly interpreted ?
<popey> does the icon get installed to /snap/yourapp/current/meta/gui ?
<popey> and the desktop file
<Guest40416> yes
<popey> if you cat the desktop file what does the Icon= line look like? can you paste that one line here?
<Guest40416> but the desktop file remains "empty"
<popey> Icon=${SNAP}/meta/gui/openttd.png
<popey> e.g. ^
<popey> thats what my installed .desktop file looks like
<popey> (well, one line of it)
<Guest40416> Mine, is also Icon=${SNAP}/meta/gui/jimbodicomviewer.png
<popey> you said the desktop file is empty?
<popey> where you built the snap, look in prime/meta/gui - is the desktop file / png in there?
<Guest40416> It is not in prime/meta/gui !!
<Guest40416> Thanks, I will try with this
<popey> snapcraft should put it there
 * Odd_Bloke has just filed https://bugs.launchpad.net/snappy/+bug/1607710; could someone give it a quick triage?
<mup> Bug #1607710: Use passwd to determine user home directory <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1607710>
<mup> Bug #1607710 opened: Use passwd to determine user home directory <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1607710>
<mup> PR snapcraft#697 opened: Also use INSTALLROOT for make plugin <Created by jhobbs> <https://github.com/snapcore/snapcraft/pull/697>
<mup> PR snapd#1599 closed: asserts,client: switch snap-build and snap-revision to be indexed by snap-sha3-384 <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1599>
<mup> PR snapd#1603 opened: overlord/snapstate: ensure calls to store are done without the state lock held <Created by chipaca> <https://github.com/snapcore/snapd/pull/1603>
<mup> Bug #1607717 opened: no snaps installed error <Snapcraft:Invalid> <Snappy:New> <https://launchpad.net/bugs/1607717>
<Spads> https://github.com/scummvm/scummvm/pull/795
<mup> PR scummvm/scummvm#795: POSIX: Add $SNAP to search path if available <Created by fuzzie> <https://github.com/scummvm/scummvm/pull/795>
<ogra_> neat !
 * Spads is arranging meetings with that upstream over lunch soon
<Spads> had to get over my debian packaging mentality of being a third-party maintainer and say "actually these changes should come from you folks and not have my name on them"
<Spads> and so they can fix this stuff in the right place, which is nice
<ogra_> yeah, definitely
<ali1234> hmm... gstreamer isn't seeing its plugins
<ali1234> ogra_: why do you do ">>$SNAP_DATA/log/daemon.log" - shouldn't you just let it all go to systemd?
<ogra_> i could, yeah
<mup> PR snapd#1604 opened: client, cmd/snap: better errors for empty snap list result <Created by chipaca> <https://github.com/snapcore/snapd/pull/1604>
<ogra_> grmbl ... gmane being dead is really annoying
<Chipaca> ogra_, it's not dead! it's nntp-only
<ogra_> Chipaca, doesnt help with google links :P
<Chipaca> until somebody picks up the nntp-to-web side of it
<Chipaca> ogra_, little green arrow next to the link, "cached"
<ogra_> dunno, but my google UI doesnt have that
<Chipaca> ogra_, do you have an example search?
<ogra_> https://www.google.de/search?client=ubuntu&channel=fs&q=IPELUAPATH%3D&ie=utf-8&oe=utf-8&gfe_rd=cr&ei=JDabV_LTN-Xj8wfnl4qYCA#channel=fs&q=IPELUAPATH%3D&pws=1
<ogra_> second hit was what i wanted to look at
<ogra_> oh
<ogra_> it isnt green and its a pulldown here
<Chipaca> ogra_, http://imgur.com/4eAk4wh
<Chipaca> green ... ok, it's a triangle not an arrow i guess
<ogra_> yeah, found it now
<ogra_> thanks !
<Chipaca> ogra_, np!
<ogra_> that used to just be a text link
<Chipaca> yep
<mup> Bug #1607744 opened: "snap install <filename>" over an already installed snap doesn't copy the user data <Snappy:New> <https://launchpad.net/bugs/1607744>
<Odd_Bloke> niemeyer: https://bugs.launchpad.net/bugs/1607710 is the bug I filed for the home directory issue.
<mup> Bug #1607710: Use passwd to determine user home directory <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1607710>
<mup> Bug #1607748 opened: Ability to use two registered names for the same snap <Snappy:New> <https://launchpad.net/bugs/1607748>
<niemeyer> Odd_Bloke: Thanks!
<slangasek> zyga: just got a bug report in Debian unstable that snapd is not buildable from source because of removal of a build-dependency (golang-pb-dev -> golang-github-cheggaaa-pb)
<slangasek> I see no bug report in Debian explaining why this was removed
<slangasek> but that means it's an unmaintained build-dep for Ubuntu also
<slangasek> zyga: ah, https://bugs.debian.org/830747 , "ROM; superseded by golang-gopkg-cheggaaa-pb.v1"
<ogra_> kyrofa, sergiusens, do you guys think we could avoid calling ldd on kernel modules in snapcraft builds ? (see the last lines of https://launchpadlibrarian.net/275652591/buildlog_snap_ubuntu_xenial_amd64_kernel-test-snap_BUILDING.txt.gz)
<dholbach> davidcalle, do you think it'd make sense to add "newest snaps" to the report? e.g. a summary of https://twitter.com/uappexplorer?
<didrocks> dholbach: it's already what we have (the 10 snaps of the months) on insights, right?
<didrocks> dholbach: maybe we should ensure we don't duplicate, so only have one list
<dholbach> didrocks, I just felt like we're getting so many snaps in that a weekly and a monthly review wouldn't hurt? :)
<dholbach> didrocks, in the monthly one you get the best of the last four weeks ;-)
<didrocks> dholbach: can be, at least, the efforts should be joined
<dholbach> sure - it'd be like the research work for the monthly blog post would already be done :)
<ppisati_> ogra_: is that a kernel snap build? how did you avoid the 'snapcraft login' problem?
<ogra_> ppisati_, it is more than just a kernel ... lp:~ogra/+junk/kernel-test-snap ... (see the makefile) for the official kernels we need a bunch of extra stuff (and tehere will be more, like mesa, nvidia drivers etc etc)
<ogra_> ppisati_, but it is "type: kernel" in which case i dont think snapcraft should call ldd at all on the modules dir
<ali1234> Jul 29 12:58:53 al-desktop ubuntu-core-launcher[24053]: Ready for rendering.
<ali1234> it works!
<ogra_> looks ready :)
<ogra_> congrats !
<ali1234> ogra_: how do i delete things from your upnp server?
<ppisati_> ogra_: oh i see
<ogra_> ali1234, thats a bug i still havent faound the reason for ...
<ogra_> you need to delete from commandline currently
<ali1234> okay... workaround? go into the snap
<ogra_> (sadly lighttpd doesnt give any errors)
<ogra_> right, rm it from commandline
<ali1234> where is the data?
<ali1234> found it
<ali1234> hmm storing the data in 1/ rather than common/ - do all my files vanish if reinstall the snap?
<ppisati_> ogra_: btw, do you have a prebuilt amd64 image somewhere?
<ogra_> ali1234, /snap/upnp-server/current/var/cache/lighttpd/uploads/
<ogra_> iirc
<ali1234> no it's in Media
<ogra_> err, no
<mup> Bug #1607763 opened: Interface to manage sudoers <cpc> <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1607763>
<ogra_> ali1234, right, /var/snap/upnp-server/current/Media/
<ogra_> ppisati_, see the mailing list, mvo announced an experimental one with the new world order yesterday
<ali1234> hmm no mp3 decoder plugin...
<ogra_> well, if you have a patch :)
<ogra_> all my music is .flac ... for which i dont seem to add any extra decoders it seems
<ogra_> *dont seem to need to
<ali1234> the server does not need the plugin the rendered (what i am snapping) does
<ogra_> ah, k
<ali1234> okay it claims to be playing but i don't hear anything
<ppisati_> ogra_: uhm nope, he just said there will be a new image, no links
<ogra_> ppisati_,  http://people.canonical.com/~mvo/all-snaps/16/
<ogra_> note that all package names changed (except for ubuntu-core)
<ppisati_> ogra_: ohhh
<ogra_> the kernel package is pc-linux now
<ogra_> oh
<ogra_> wrong
<ogra_> it is pc-kernel
<ogra_> (probably because it contains a lot more than linux :) )
 * ogra_ would actually raher call them hw-pack or some such ... 
 * ppisati_ tries to build an image
<ppisati_> ogra_: is the gadget still canonical-pc or what?
<ali1234> so how do i get audio from a snap?
<ogra_> ppisati_, just pc now
<ogra_> and we only have amd64 atm
<ogra_> ali1234, currently only via the pulseaudio interface i think
<ogra_> (and i'm not sure that fully works yet)
<ogra_> (well, it does for the vlc snap)
<ppisati_> uhm
<ogra_> there are discussions about an alsa interface as well as a raw audio device one ... but pulse is the only existing one currently
<ali1234> okay but how do i use it?
<ppisati_> http://people.canonical.com/~ppisati/bad_snappy_image_2016-07-29_14-22-07.png
<ogra_> you define it in your snapcraft-yaml and make sure your app uses a pulse output mode
<ppisati_> with this command line:
<ppisati_> sudo ./ubuntu-device-flash core 16 --channel edge --os ubuntu-core --kernel pc-kernel --gadget pc -o test.img
<ali1234> where is it defined in the vlc snapcraft?
<ogra_> ppisati_, yeah, the squashfs errors are weird, buti see them since a few weeks, unrelated to the new format
<ali1234> oh i see, plugs
<ogra_> ppisati_, it should work all fine on second boot for whatever reason
<ogra_> ppisati_, i was wondering if it might actually be related to having squashfs built into the kernel instead of a module ... i.e. if behaviour changes then
<didrocks> ogra_: nice timing on the ML :)
<ogra_> :)
<ali1234> ogra_: so it has to use pulseaudio... does that mean that pulseaudio alsa emulation does not work?
<ogra_> it should i think, but i'm not sure what the confinement lets through
<ogra_> yoou have to try
<ali1234> in devmode?
<ali1234> i get no audio in devmode...
<ali1234> okay got it
<ali1234> alsa emulation doesn't work, but i can tell it to use pulseaudio
<apw> ogra_, i can see no behaviour changes when squashfs is built-in as opposed to being a modules
<ogra_> apw, weird ... i wonder where it comes from then ... sadly i didnt build images for weeks because the world was so broken ... so i cant really ppin it down to a specific date
<ppisati_> ATM i'm using mvo all snaps image and it works
<ppisati_> except for all the changes in the kernel snaps, that made our kernel moot
<ali1234> okay so if my snap is configured to run as a service then audio doesn't work
<ogra_> but it was definitely there with my last images that were built the old way
<ogra_> so before we changed much
<ogra_> and it also seems gone on subsequent boots of the image
<ogra_> ppisati_, well, we will never be able to use a plain kernel snap anyway ... you need firmware, udev rules, mesa (when graphics are desired) etc etc
<ogra_> plain kernel snaps are for special purpose setups imho
<ppisati_> ogra_: yeah, i agree
<ppisati_> ogra_: but for example, now it looks for kernel.img, and without that file the image is dead
<ogra_> you mean kernel.yaml ?
<ppisati_> ogra_: nope, now it looks for the kernel.img file <- the kernel file
<ppisati_> linux (loop)/kernel.img $cmdline
<ogra_> sigh ... who came up with that
<ppisati_> from grub.cfg
<ogra_> ppisati_, i thought that was defined at the heidelberg sprint and you participated ?
<ogra_> i wasnt in the particular kernel.yaml sessions
<ogra_> onl yin gadget ...
<ogra_> but when i asked i was told everything is fine and agreed upon
<ppisati_> i was in the kernel session, but i don't remember that
<ppisati_> anyhow
<ogra_> smells fishy really :)
<ogra_> but yeah, it is how it is
<ppisati_> nope
<ppisati_> it's not part of the Heidelberg notes
<ogra_> weird
<ogra_> and mvo is off today
<ppisati_> we'll look into it next week
<ogra_> yeah
<sergiusens> ppisati_ did it work in the end?
<ogra_> it is rather awful having to rename the binaries all the time
<ogra_> when we used just vmlinuz before
<ppisati_> sergiusens: yes, your patch let me do 'snapcraft --target-arch=foo'
<ppisati_> sergiusens: and in the snapcraft.yaml i put:
<ppisati_> kernel-image-target: {'amd64': 'bzImage', 'arm64': 'Image', 'armhf': 'zImage'}
<ppisati_> and it worked
<ppisati_> i tested both the string and the map case
 * ogra_ still shudders seeing "arm64: image" 
<ogra_> :)
<ppisati_> ok, by renaming vmlinuz to kernel.img i can still use our vanilla kernel snap
<ppisati_> we'll need to augment it with all the other stuff, but at least they still work
<mup> Bug #1607796 opened: snapd-confine regression when running commands as root <Snappy:New> <https://launchpad.net/bugs/1607796>
<timothy> stgraber: I tought snap-confine bugs should be opened on github :)
<ogra_> that would be confusing
<timothy> so you should disable bug opening on github for snap-confine repo like you do for snapd
<ogra_> timothy, we want to use LP because it allows us to track bugs in other distros via bug tasks
<timothy> ogra_: ok, but allow opening bugs on github confuses people (like me) more :P
<ogra_> github issues cant do that
<ogra_> well, i dont know why zyga kept it enabled for snap-confine
<stgraber> zyga: so new snap-confine does mount /lib/modules but it also no longer defines a working $HOME for daemon (not a big deal) and more importantly, I can't run commands as root anymore because they don't have a HOME define which is a blocker for us
<stgraber> zyga: I marked the SRU as failed since it's a clear regression
<ogra_> stgraber, dude, this is ubuntu. use sudo
 * ogra_ hides somewhere wher stgraber cant reach him when throwing stuff
<ogra_> :P
<timothy> as root user I have HOME=/root
<ogra_> timothy, yes, but snap-confine doesnt mount /root into ubuntu-core
<ogra_> and your snapp gets executed inside there
<ogra_> so /root is readonly
<ogra_> its a missing bind mount
<stgraber> ogra_: well, it USED to work :)
<timothy> stgraber: on which version?
<stgraber> timothy: 1.0.27.1 to 1.0.38-0ubuntu0.16.04.3
<stgraber> timothy: so xenial-updates to xenial-proposed as far as what's in Ubuntu
<mup> PR snapd#1603 closed: overlord/snapstate: ensure calls to store are done without the state lock held <Created by chipaca> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1603>
<kyrofa> ogra_, is the ldd call causing issues?
<tkamppeter> I am snapping CUPS currently
<tkamppeter> I have now got together some basic snap: It starts CUPS as permanently running daemon and I have made all directories to where CUPS needs to write into $SNAP_DATA.
<seb128> I wonder if I'm the only one "priming" doesn't convey much sense to, I keep having to think about what that dir/step does
<tkamppeter> Problem now is that the CUPS daemon starts helper programs and these helper programs do not find the libraries contained in the snap.
<tkamppeter> How can I make programs called by the snapped CUPS daemon find the libs of the snap?
<ogra_> seb128, it used to be calles strip ... but someone found the naming nasty
<ogra_> *called
<seb128> yeah
<seb128> strip has another standard use
<seb128> but it could have been "prepare"
<ogra_> yeah, they even have clubs for it
<ogra_> and indeed it could have been prepare ... but thats probably not as hip as prime :)
<seb128> I still don't understand what "prime" is
<seb128> it might be because it's a word I never use in english
<ogra_> it mangles symlinks, cheks dependencies with ldd and all such stuff
<seb128> "prepare" would have made more sense
<seb128> oh well, it has been renamed once I guess they are not renaming it again
<ogra_> LOL !!!
<ogra_> hahahahahaha
<ogra_> if i now could find my access data for the quotes page
<seb128> I need to hint somebody that the name sucks
<seb128> lol
<seb128> "somebody"
<seb128> like seems like we are going to fix "app" which also sucked
<ogra_> nothing is as unstable as any kind of naming in the snappy world
<seb128> so why not prime... ;-)
<ogra_> even in a few years when the code is rock solid and proven we will still see renames of functions, variables, commands etc i bet
<ogra_> seb128, bring it up on the ML ... renaming it now will surely be easier than renaming it later
<seb128> I might
<mup> Bug #1576500 opened: Plasma fails to load:  "all shell packages missing" <amd64> <apport-bug> <xenial> <Snappy:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1576500>
 * ogra_ sighs ... looks like i'll spend my weekend in the basement fixing the heating ... as if it wasnt warm enough already i'll have to swing wrenches in a 40Â°C warm room for two days (or live with cold water)
<mup> Bug #1607796 changed: snap-confine regression when running commands as root <lxd> <Snappy Launcher:In Progress by zyga> <https://launchpad.net/bugs/1607796>
<bull> hi guys
<bull> can our snapped application make a call to external application which is installed on our system ?
<bull> popey,  can our snapped application make a call to external application which is installed on our system ?
<bull> ogra_,  hi
<seb128> bull, hey, they would need an interface for that
<mup> PR snapcraft#698 opened: Add option disable-parallel for autotools plugin <Created by blakerouse> <https://github.com/snapcore/snapcraft/pull/698>
<bull> we have such interface yet ???
<seb128> not that I know of
<bull> seb128, you talking to me ??
<bull> guys my app is qt based and called gsetting to change system settings i snapped my app and it became useless since it was not able to make call to gsetting
<seb128> bull, yes I'm taling to you, it uses the gsettings command line utility and not the glib api?
<bull> no i use glib just for showing the tray icon in collaboration with libappindicator
<bull> and i call gsetting using Qt's Qprocess lib
<bull> a packaging format should not effect Qt's libs an sure , in this since its a snappy app it may be calling gsetting inside the app's container
<bull> where it cant find gsettings
<seb128> gsettings the api?
<seb128> ah, the command line
<bull> seb128, you can check my code on github https://github.com/keshavbhatt/Deskie
<seb128> well you can stage-package libglib2.0-bin
<bull> i am able to make snap package but it become useless :(
<bull> app runs but wont work
<bull> its a wallpaper changer , better and much powerful then variety
<bull> seb128,  take a look http://www.ktechpit.com/deskie-wallpaper-changer-ubuntu-linux/
<seb128> it's not sueless, it's secure
<seb128> just include the binary
<bull> what u talking about
<bull> ?
<bull> i packaged it in debian format it works fine there
<mup> PR snapd#1605 opened: asserts: introduce support for assertions with no authority, first pass at serial-request <Created by pedronis> <https://github.com/snapcore/snapd/pull/1605>
<ogra_> hmm, i wish we could have a zenmity part
<ogra_> *zenity
<ogra_> some of my apps generate config on first start, would be nice to be able to pop up a message or bouncy progress bar when that happens
<kyrofa> ogra_, you need an install hook, so stuff like that would be part of the installation. No?
<ogra_> kyrofa, well, since it usually happens on first start of the app, it would be a launch wrapper
<ogra_> it is just that the first launch typically takes longer due to that
<kyrofa> ogra_, but if it's only the first start, isn't it really part of the installation?
<ogra_> the installation doesnt launch the app
<ogra_> i'm talking about apps, not services
<imexil> Hi. Does it make sense to use boths the x11 AND the unity7 plug or is unity7 simply x11+appmenu?
<kyrofa> ogra_, of course. I do the same thing for nextcloud, but that's only because there's no way to say "I want to do this once"
<kyrofa> ogra_, but you want to continue doing it upon first run even if that capability exists?
<kyrofa> imexil, I typically use them both
<ogra_> kyrofa, well, i check if the config file exists ... my code indeed only runs iif it does not :)
<ogra_> so usually only once on first start
<ogra_> the check if the file exists is cheap
<ogra_> nothing that delays the start much
<imexil> kyrofa:  well I'm trying to isolate a problem and since my my doesn't run with x11 but partly with unity7 I was wondering what is causing this.
<artmello> Hi. I am trying to make a snap for gallery-app. It seems to be working but QStandardPaths::PicturesLocation seems to be pointing to ~/snap/gallery-app/x1/Pictures instead of ~/Pictures
<artmello> how can I fix that?
<sethj> does snap find fail with connection refused for anyone else?
<sethj> oh, reinstalling snapd fixed it.
<Saviq> g
<tianon> jdstrand: should I embed rules that overlap with, for example, "network-bind" functionality in the "docker" interface, or should "dockerd" just plugs: for those bits?
<tianon> jdstrand: it seems like "docker" ought to imply everything Docker itself needs on the slot end at least
<hades|2> can i install http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/20160728/vivid-preinstalled-core-amd64.tar.gz and update later to xenial / 16.04 using snappy update / refresh ??
<hades|2> or i should use rather  https://people.canonical.com/~mvo/all-snaps/16/all-snaps-amd64.img.xz ? ou ubuntu server 16.04 ?
<hades|2> ???
<tgm4883> Is there a way to specify the $SNAP variable in the snapcraft.yaml file?
<tgm4883> specifically, I want to pull it not set it
<ali1234> you mean the actual value of it?
<ali1234> i don't think so, because you can't know what it is going to be until the snap gets installed
<tgm4883> ali1234: yea that's what I was wondering
<tgm4883> ali1234: because I think the issue I'm having is this app can't find the libraries because it's looking in the wrong place
<ali1234> you have to make a wrapper script then
<hades|2> what version of ubuntu-core should i use ?
<tgm4883> ali1234: hmm, a wrapper that adds where the libraries are?
<ali1234> yes, like the desktop-launch one
<tgm4883> hmm ok
<tgm4883> ali1234: what is $SNAP in this launcher?
<ali1234> for example: export LD_LIBRARY_PATH=$SNAP/usr/lib/$ARCH/dri:$LD_LIBRARY_PATH
<ali1234> https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports
<tgm4883> Yea I'm looking at that. I pull in desktop/qt5
<tgm4883> I don't see where $SNAP is getting set though
<ali1234> it is set by snapd
<ali1234> actually it is set by the script that gets generated and put in to /snap/bin
<tgm4883> ok, let me ask a different question. Where should I be installing the app to with --prefix
<ali1234>  /
<tgm4883> Hmm
<ali1234> but you shouldn't have to worry about that
<tgm4883> I'm not sure that's write. I think I was getting permissions issues when building when using that. But let me try again
<ali1234> you are supposed to let the build plugin figure it out
<tgm4883> ok, that's what I did on my last build
<tgm4883> I commented out both --prefix and --runprefix
<hades|2> can i use latest ubuntu-core vivid and update to ubuntu-core xenial later ? yes ? no ?
<tgm4883> ali1234: when running ldd on one of the binaries, it should point to stuff inside the install directory right?
<tgm4883> sorry if these questions are dumb, I don't compile much
<ali1234> what are you trying to compile?
<tgm4883> ali1234: mythtv
<ali1234> frontend or backend?
<tgm4883> ali1234: I've got it compiling and installing in the snap, but when I run it I get "This application failed to start because it could not find or load the Qt platform plugin "xcb"."
<tgm4883> ali1234: currently frontend
<tgm4883> since I think that is the lesser of 2 hurdles
<ali1234> okay
<ali1234> this i know quite a bit about
<tgm4883> you know quite a bit about mythtv?
<ali1234> i know a little bit about mythtv and a lot about Qt platform plugins
<tgm4883> sweet :)
<ali1234> so the platform plugin is the graphics backend for Qt basically
<ali1234> xcb is the X11 one
<tgm4883> ok
<ali1234> i assume you didn't compile Qt yourself?
<tgm4883> nope
<tgm4883> Here's my snapcraft.yaml file so far https://github.com/tgm4883/mythtv-snap/blob/master/snapcraft.yaml
<ali1234> okay i have never seen this "no-security" stuff before
<tgm4883> ali1234: In the docs it mentioned that it just disabled everything
<tgm4883> for testing I believe
<ali1234> i do "sudo snap install --devmode whatever.snap"
<ali1234> that seems to have the same effect
<tgm4883> or maybe I got that from a different snap
<tgm4883> ok, just installed with --devmode, same error on xcb
<ali1234> can you pastebin find inside the installed snap?
<ali1234> will be /snap/mythtv/current or somehting
<tgm4883> yea
<tgm4883> http://termbin.com/9f3b
<tgm4883> inside /snap/mythtv/current
<ali1234> ./usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so
<ali1234> that's the xcb platform plugin it claims to be looking for
<tgm4883> ok, so that's good that it's there. Why can't it find it?
<ali1234> hang on i need to turn on another computer to get to my Qt snaps
<tgm4883> Does it search all subdirectories of a path in $LD_LIBRARY_PATH? I do see $SNAP/usr/lib/x86_64-linux-gnu in the wrapper file
<ali1234> no
<tgm4883> hmm
<tgm4883> I don't see that directory then unless it's in the default $LD_LIBRARY_PATH
<tgm4883> or in $SNAP_LIBRARY_PATH
<ali1234> how long does this take to build?
<tgm4883> not long, under 2 minutes
<tgm4883> on my laptop anyway
<tgm4883> in launchpad for the deb packages, it takes like a half hour
<tgm4883> granted it's building more there, I'm not building the frontend plugins yet
<ali1234> okay let me build this and see what it does
<tgm4883> ok
<ali1234> okay it's built
<ali1234> oh, derp
<tgm4883> ali1234: broken for you too?
<ali1234> tgm4883: you included the desktop/qt5 but you didn't use the launcher script it provides
<tgm4883> oh, didn't know I needed to. That was recommended to me last night (the desktop/qt5 stuff)
<ali1234> it still doesn';t work, but the crash is totally different now
<tgm4883> ali1234: heh, progress is progress I suppose
<ali1234> 2016-07-30 00:17:18.478427 C  FATAL: Unable to load the QT mysql driver, is it installed?
<ali1234> so you need to stage that next
<ali1234> command: desktop-launch mythfrontend
<ali1234> is what you need to get the library paths configured properly
<tgm4883> that's what I need for the wrapper?
<ali1234> yeah
<tgm4883> ok, and staging the mysql package
<ali1234> also i don't think it is necessary to specify build-essential in the build-packages
<ali1234> and dependencies work like normal
<ali1234> so generally that list is quite short
<tgm4883> so then anything that is a dependency of the deb package should be in stage packages?
<ali1234> direct dependencies yeah
<ali1234> deps are pulled in recursively
<tgm4883> ok, building again
<tgm4883> ali1234: progress
<tgm4883> QXcbConnection: Could not connect to display :0
<tgm4883> forgot dev mode
<tgm4883> holy crap it loaded
<tgm4883> ali1234: this is awesome, it launches and works a little. Need to squash some other bugs, but this is way further than I was previously. Thanks
#snappy 2016-07-30
<Son_Goku> zyga, you can push https://bodhi.fedoraproject.org/updates/FEDORA-2016-4154def2ea and https://bodhi.fedoraproject.org/updates/FEDORA-2016-c6820c54b1 to stable now
<hades|2> how to run latest amd64-all-snap.img + LXD Containers ?
<hades|2> ans also how to get webdm working with latest  amd64-all-snap.img ? i get some apparmor error
<bull> hi friends
<bull> what after : do in snapcraft file ?
<bull> artmello, this is the problem man same happening with me ,
<bull>  QStandardPaths::DataLocation point to container's location instead of user's /home/.local/share/myapp/data
<bull> am getting this error- expected string or bytes-like object
<bull> anyone on ??
<bull> help
<bull> expected string or bytes-like object
<bull> what does this mean
<qengho> bull: From what command? Your questions don't ask enough.
<bull> snapcraft
<qengho> bull: Add "--debug" to the end of snapcraft command line.
<bull> my snapcraft file is here - http://paste.ubuntu.com/21494084/
<bull> and the output of --debug is  http://paste.ubuntu.com/21494119/
<bull> its been 3 hours and more i cant make snap of this application here
<bull> hard journey with snapcraft so far, i cant make my app  deskie work after snapping it .  it wont work perfectly like it should idk how people gonna use this tool its harder then debian packaging damn
<qengho> bull: There is a bug in snapcraft because it should have failed in a better way, but it should have failed because your YAML is bad. Its nor valid at all.
<qengho> bull: Indentation matters. Sections matter.
<bull> qengho,  whats wrong it should debug line no. etc man
<qengho> bull: What does "application:" mean?
<qengho> Did you make that up?
<bull> i used the same field in making snap for my previous application it works well
<qengho> stage-packages takes a list, but the next line is indented the same amount -- not valid.
<bull> okay let me check
<bull> application is a part ??
<qengho> bull: Notice how "plugs" and "architectures" doesn't look like "stage-packages"?
<qengho> bull: Okay, that is good. It needs a plugin, I am pretty sure.  Use "plugin: nil", maybe.
<bull> okay but it should output these things instead of such a horrible output
<bull> okay wait let me check
<bull> bro we use tab to make space or spacebar ??
<qengho> bull: that's a bug. It's never seen YAML like this. Please, run "$ ubuntu-bug snapcraft", title "snapcraft crashes with useless message on bad YAML" and attach a link to your YAML.
<qengho> bull: It's up to you. Be consistent.
<bull> okay
<bull> i will
<bull> i cant report bug
<bull> how to do that ??
<bull> my current snapcraft file is  this http://paste.ubuntu.com/21494890/      please report the bug
<bull> it still saying same after i fixed the indentions --  expected string or bytes-like object
<bull> its working now after removing architectures
<bull> snapcraft :- downloading icons whille snapping app make no sense or its useless -- Get:41 http://in.archive.ubuntu.com/ubuntu xenial/universe DEP-11 64x64 Icons [7,448 kB]
<bull> wow , am still not able to know what the hack is going on here with snapcraft !!! it still showing me same error at end of building process .
<bull> downloaded 28 mb of cache , 200mb + of packages and at last it fails haha with this line - expected string or bytes-like object
<bull> mhall119,  you there ??
<tsimonq2> bull: mhall119 is sleeping right now :)
<bull> tsimonq2,  damn
<bull> i reported bug https://bugs.launchpad.net/snapcraft/+bug/1608032
<mup> Bug #1608032: snapcraft crashes with useless message on bad YAML <output> <snap> <snapcraft> <snappy> <ubuntu> <useless> <Snapcraft:New> <https://launchpad.net/bugs/1608032>
<jdstrand> tianon: sorry I missed you (yesterday was a half day for me), the general guidance is that if the snap needs things here and there from other interfaces to use those interfaces *iff* the snap legitimately needs that access. for example, if docker does bind to a port and listen to network connections, then use network-bind, otherwise, add it to your interface
<jdstrand> tianon: also, don't worry about seccomp policy right this second-- I suggest using @unrestricted right now because the way seccomp works, you can't ever get more syscalls than the parent. Perhaps, maybe, you could get away with listing everything in snap-confine.git/debian/README.syscalls and leave out, say, init_module (and others that are kernel module related), keyctl and a few others that are listed as dangerous in the interfaces/seccomp/default
<jdstrand> tianon: point is, docker, like lxd, is quite special in that it can be thought of in some ways as an alternate launcher and it needs a lot of privileges to launch its app containers
<jdstrand> tianon: we can discuss this all next week. I'm happy to answer any questions and provide guidance/tips/etc
<mup> PR snapcraft#698 closed: Add option disable-parallel for autotools plugin <Created by blakerouse> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/698>
<tgm4883> If I'm just changing security settings in my snapcraft.yaml file, do I just need to run 'snapcraft snap' to test the changes? I'd rather not rebuild the whole thing everytime
<kyrofa> tgm4883, you mean changing the plugs/slots stuff? Indeed, no need to rebuild
<tgm4883> kyrofa: exactly. Right now this app only (semi-)works in --devmode
<kyrofa> tgm4883, anything not in parts you can modify freely and just run `snapcraft` again to get it in a snap. Snapcaft will regenerate the prime/meta directory each time
<tgm4883> oh that is nice
<kyrofa> tgm4883, so apps, snap name, version etc
<tgm4883> that will make adding apps much easier
<kyrofa> Indeed
<tgm4883> speaking of version, can that have a variable in it? Like $DATE
<kyrofa> tgm4883, are you aware of the `snap try` functionality?
<tgm4883> no, what's snap try?
<kyrofa> tgm4883, no, but you're not the first to ask. We'll add something like that soon
<tgm4883> sweet
<kyrofa> Okay, snap try. Hold on I need to move then I'll explain
<kyrofa> Okay, I'm back
<kyrofa> tgm4883, assuming you're running snapcraft on a 16.04 machine, you can just run `snap try prime/` after running `snapcraft prime`
<tgm4883> ok, running a build now, should be done in a few minutes
<kyrofa> tgm4883, that will bind-mount the prime directory and pretend it's a snap installed on the system
<tgm4883> what does that do for security confinement?
<kyrofa> tgm4883, which means you can run all the apps from it and everything, except it's not a squashfs image-- if you change the prime directory, you change the snap
<kyrofa> tgm4883, still works the same way. You can `snap try --devmode` too
<tgm4883> ah cool
<kyrofa> tgm4883, it makes for faster iteration
<tgm4883> yea that will help
<kyrofa> tgm4883, but a word of warning. There's a bug where, if you run `snapcraft clean` or otherwise remove the prime directory, snapd gets confused
<kyrofa> tgm4883, it's been fixed in master, but not released yet
<kyrofa> tgm4883, so if you're going to clean the prime directory, `snap remove` the snap first
<tgm4883> also if I stop running "snapcraft clean" and rebuilding the whole thing :)
<tgm4883> apparently I like to watch it do a git clone of the repo
<kyrofa> tgm4883, you know you can clean individual parts and individual steps of parts, right?
<tgm4883> yea
<tgm4883> I need to look at that part of the documentation again
<tgm4883> Are old versions of snaps ever removed?
<kyrofa> tgm4883, right now, no. But the next version of snapd will prune them
<ogra_> there are always only two versions kept around
<tgm4883> I doubt they are causing problems, but it's starting to get annoying when I do a 'df -h' and see 20 versions of the same snap mounted
<kyrofa> tgm4883, I think it'll remove once there are three
<tgm4883> hmm
<ogra_> (unless you sideloaded ... then it is up to you to do tthe clean up)
<kyrofa> tgm4883, agreed
<tgm4883> ah
<kyrofa> Hey ogra_!
<ogra_> hi
<tgm4883> sideloaded then via snap install
<ogra_> yeah, that will pile up forever
<ogra_> you need to run snap remove every once in a while
<kyrofa> tgm4883, indeed, sideloaded = snap install <local file> versus snap install <snap name in the store>
<tgm4883> Is there a limit to the number of snaps you can install? I noticed it started over on the /dev/loop# when it got to 20
<tgm4883> or maybe that is a coincidence
<tgm4883> I did remove the hello and hello-debug snaps around that time
<ogra_> well, i guess there is a limit ... i doubt the kernel can handle more than /dev/loop64435
<ogra_> err
<ogra_> 65535
<tgm4883> that makes sense
<ogra_> but if you have 65k snap packages installled then i want your HDD too !
<ogra_> that would likely be plenty petabytes :)
<tgm4883> cool, going to work on security stuff, then only like 9-10 more things to add/fix before this app is good
<ogra_> YAY !
<ogra_> https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core
<ogra_> first cronned build ...
<kyrofa> ogra_, awesome!
<ogra_> now only autoulpoad is missing ... waiting for a store fix for that one
<kyrofa> ogra_, can't auto-upload to a shared snap?
<kyrofa> I've run into that as well
<ogra_> yeah
<kyrofa> ogra_, is that a store issue or an LP issue?
<ogra_> i think a store issue ... store people are researching since wed.
<kyrofa> ogra_, have you tried uploading via snapcraft push yourself?
<ogra_> bug 1607389
<mup> Bug #1607389: shared snap packages can not be uploaded from LP builds <Software Center Agent:New for facundo> <https://launchpad.net/bugs/1607389>
<ogra_> kyrofa, nah, only manually through the web ui
<Cavan> After I create my snap I'm still getting '...log.dir can't be created read only file system' after I've declared the logs as $SNAP_USER_DATA. Any suggestions?
<Cavan> I did notice the log files are being made in a different directory (user/snap/..) but I'm unsure how to change that
<kyrofa> Cavan, you notice the log files being created in $HOME/snap/... but you're still getting a "read-only" error?
<Cavan> The snap is being created in /snap/zeppelin/current and the logs are being created in /home/cavan/snap/zeppelin/x33. But if thats the way they're meant to be then yes
<ogra_> yes, that is the location of $SNAP_USER_DATA
<ogra_> i.e. /home/$USER/snap/$PACKAGENAME/$VERSION
<Cavan> Yeah, the file which writes the files needed 'zeppelin-daemon.sh' is returning this everytime I try to run it /snap/zeppelin/x33/bin/zeppelin-daemon.sh: line 180: /snap/zeppelin/x33/zeppelin-cavan-cavan-HP-ENVY-15-Notebook-PC.out: Read-only file system' Is there a way to point it to the $SNAP_USER_DATA to read or a way to create in the main directory?
<ali1234> heh... snaps are quite big aren't they...
<ali1234> i'm still trying to figure out if it is even possible for a daemon to play audio
<ali1234> the funny thing is that the deb package of gmediarender has the same problem... it ships with an init script which doesn't work but if you just run it at a command prompt it works fine
<kyrofa> Cavan, that depends on if the application you're snapping supports that as some sort of config options or cli parameter
<kyrofa> ali1234, daemons aren't session-specific, but I suspect audio is
<kyrofa> (don't know for sure)
<kyrofa> Sheesh sergiusens, take a day off man
<sergiusens> :-)
<acheronuk> may be a simple reason for this, but any help appreciated. see: http://paste.ubuntu.com/21546329/
<ali1234> kyrofa: yes, that's the problem
<kyrofa> ali1234, what if you made it an app and configured it to run at startup, similar to how something like skype or the owncloud client fires up? Neither of those are snaps, but I assume it just uses the .desktop files
<kyrofa> Not startup sorry-- login
<ali1234> kyrofa: it won't work because nobody ever logs in to this system
<kyrofa> ali1234, oh interesting. But you want to play audio?
<ali1234> yes
<ali1234> with uPNP
<kyrofa> How would you do that without snaps?
<ali1234> i don't know
<ali1234> i would probably rip out all the session permissions management
<ali1234> or run everything as root
<ali1234> or something horrible like that
<ali1234> the point is the system won't even have a monitor
<ali1234> it will look like a piece of stereo equipment
<ali1234> another use case would be something like amazon echo or mycroft
<ali1234> actually doesn't mycroft run on ubuntu?
<ali1234> https://insights.ubuntu.com/2015/08/14/meet-mycroft-open-source-artificial-intelligence-powered-by-snappy/
<ali1234> how does that play audio?
<ali1234> https://github.com/MycroftAI/snapcraft-mycroft-core/blob/master/snapcraft.yaml
<ali1234> no daemons defined
<ali1234> so... i think there should be a proper way to do this
<ali1234> i should be able to grab the nase image, install my snap, and have it just work... without having to create users and configure auto login
<Son_Goku> zyga, did you finally submit the updates to stable?
<Son_Goku> and have you done any work to address the fedora-review feedback?
<Son_Goku> for snap-confine
<mup> PR snapd#1556 closed: asserts: add Assertion.Prerequisites and SigningKey, Ref and FindTrusted <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1556>
#snappy 2016-07-31
<pbek> Is it possible to get the revision from `snapcraft push` to use it for `snapcraft release` afterwards?
<ali1234> wow. i just snapped sigrok and it appears to have worked first time
<ogra_> *clap* *clap*
<ogra_> congrats :)
<ali1234> uh oh
<ali1234> i think the desktop helper is busted
<ali1234> oh hang on, it's probably a missing library
<ali1234> hmmmmmm
<ali1234> firmware files aren't found properly. still, it's pretty close
<mup> PR snapd#1606 opened: debian: add extra checks when debian/snapd.postrm purge is run <Created by mvo5> <Conflict> <https://github.com/snapcore/snapd/pull/1606>
<ali1234> okay i need to tell sigrok how to find device firmwares
<ali1234> they end up in $SNAP/share/
<ali1234> sigrok looks in $PREFIX/share and $XDG_DATA_DIRS/share
<ali1234> i would rather not patch the source
<ali1234> would it be reasonable to add $SNAP to XDG_DATA_DIRS at run time?
<ali1234> this is all the places it looks http://paste.ubuntu.com/21641468/
<ali1234> hmm it uses g_get_system_data_dirs
<ali1234> so it should work?
<ali1234> oh i see
<ali1234> it works :)
<ogra_> :)
<ali1234> now, is there a plug/interface for libusb?
<ogra_> not sure, zyga would know ...
<ogra_> there is an interfaces.md somewhere in either the snapd or the snapcraft branches
<ali1234> https://github.com/snapcore/snapd/blob/master/docs/interfaces.md
<ali1234> looks like the answer is no
<ogra_> yeah, that would be a bit broad
<ali1234> well sigrok talks to many different USB logic analyzers...
<ogra_> i'd expect a bunch of more fine grained device interfaces rather than all of usb
<ogra_> serial, disk, audio, input etc etc ...
<ali1234> "logic analyzer"
<ali1234> that's probably not going to happen
<ogra_> is that just using a usb serial interface ?
<ali1234> especially given they are all completely different and not defined in the kernel at all
<ali1234> it is using libusb
<ali1234> i expect some of them are serial-ish devices
<ali1234> mine isn't though
<ali1234> mine requires a firmware to be loaded at runtime, and then talks a custom protocol
<ali1234> sigrok can also talk over i2c
<ogra_> well, file a wishlist bug and lets see ... probably there will be such an interface
<ali1234> i have a lot of interfaces i need actually :)
<ogra_> gpio and i2c are definitely required interfaces for the embedded images
<ali1234> embedded audio too. ie audio without a user session, from a daemon
<ali1234> where should i file wishlist bugs? github?
<ogra_> iirc someone was working on a pulse snap
<ogra_> that should provide such an interface on snappy images
<ali1234> nice
<ogra_> see channel topic ;)
<ali1234> allowing the snap to own the audio device would also be acceptable
<ali1234> although really i feel like  daemon should be able to make sound even if a user is logged in
<ali1234> if you want it to i mean
<ali1234> what about feature requests for snapcraft? same place?
<ogra_> yep
<ogra_> or you can s/snappy/snapcraft/ ... in the url
<ogra_> both should work
<ali1234> https://bugs.launchpad.net/snappy/+bug/1608244
<mup> Bug #1608244: implement low level usb interface for snaps requiring libusb <Snappy:New> <https://launchpad.net/bugs/1608244>
<mup> Bug #1608244 opened: implement low level usb interface for snaps requiring libusb <Snappy:New> <https://launchpad.net/bugs/1608244>
<ali1234> when snapcraft clones a git source url, does it use --depth=1?
<ali1234> if not it should
<ali1234> ah it already does that. cool
<mwhudson> zyga: did you get your gpg key signed by a DD yet? :)
#snappy 2017-07-24
<mup> Bug #1705985 opened: snaps fail to install on juju1 deployed lxc container <canonical-bootstack> <Snappy:New> <https://launchpad.net/bugs/1705985>
<zyga-ubuntu> o/
<zyga-ubuntu> good morning everyone
<zyga-ubuntu> mvo: how are you doing?
<mvo> zyga-ubuntu: hey, good morning. doing fine, how are you?
<zyga-ubuntu> just finishing my coffee, good; today will be a nice day (for protests)
<mup> PR snapd#3592 closed: interfaces: opengl support pci device and vendor <Created by kyrofa> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3592>
<zyga-ubuntu> !!!
<zyga-ubuntu> kissiel: duda vetoes!
<zyga-ubuntu> \o/
<kissiel> zyga-ubuntu: you know it's because they voted for the wrong one?
<kissiel> zyga-ubuntu: the one pushed was not the one they wanted
<kissiel> it's a mess
<zyga-ubuntu> kissiel: well, they could have paper-wrapped that
<zyga-ubuntu> kissiel: but it seems he's not totally corrupt and spineless
<zyga-ubuntu> kissiel: this is a major step forward
<kissiel> we'll see
<Chipaca> zyga-ubuntu: thank for the reviews!
<mup> PR snapd#3612 closed: vendor: update go-flags to address crash in "snap debug" <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3612>
<zyga-ubuntu> Chipaca: my pleasure
<mup> PR snapd#3610 closed: snap: do not always quote the snap info summary <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3610>
<zyga-ubuntu> if it wasn't for the political turmoil I'd be pushing my branch for review so if you want to look at the query -> result API similarity I'd love your review
<zyga-ubuntu> but
<zyga-ubuntu> there's a lot of hope now
<zyga-ubuntu> after the week of protests the president just announced he will not sign the controversial law
<zyga-ubuntu> Chipaca: sorry, how have you been? :-) I keep talking about .pl lately
 * zyga-ubuntu is reviewing 3594
<Chipaca> zyga-ubuntu: sounds like you're back into .pl politics big time
<zyga-ubuntu> Chipaca: hard to ignore such changes
<zyga-ubuntu> Chipaca: during the sprint mvo, gustavo and me went for a walk and we passed by the presidential palace, having walked past 1000s of people peacefully protesting
<zyga-ubuntu> Chipaca: it's not over but there's a lot more hope now than during the last few days
<mup> PR snapd#3605 closed: packaging: have Ubuntu snapd package recommend squashfuse <Created by dustinkirkland> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3605>
<pedronis> zyga-ubuntu: mvo: Chipaca: hi
<zyga-ubuntu> pedronis: hey, how are you doing? :)
<pedronis> ok
<mvo> Chipaca: re tab-completion (forum) profile.d file - is that something you want me to look into? I am keen to get it for 2.27
<mvo> fgimenez: any word from CE yet about the 2.26.14 stable core? I would love to release that today if JamieBennett is ok with it too
<JamieBennett> mvo: I believe we are OK to release, lets leave it until this afternoon when our US colleagues come online to confirm.
<fgimenez> hey mvo, not yet, looks like they are running smoke test on it, according to the thread the results should be available today
<mvo> fgimenez, JamieBennett: thank you both!
 * zyga-ubuntu keeps fingers crossed for an open path to 2.27
<ogra_> zyga-ubuntu, congrats (nice president ...)
<zyga-ubuntu> ogra_: nice is too strong but it seems he's waking up
<zyga-ubuntu> mvo: partially reviewed 3594
<mvo> zyga-ubuntu: ta, nice
<zyga-ubuntu> Chipaca: tab completion question
<zyga-ubuntu> Chipaca: snap command --optio$ argument
<zyga-ubuntu> Chipaca: if I hit tab when cursor is indicated at $, should it complete --option
<zyga-ubuntu> Chipaca: as a user I'd say, sure
<zyga-ubuntu> but it doesn't
<zyga-ubuntu> er
<zyga-ubuntu> sorry
<zyga-ubuntu> reverse that
<zyga-ubuntu> Chipaca: snap command arg$ --option
<zyga-ubuntu> Chipaca: I try to tab complete "argument"
<zyga-ubuntu> both normally work but when cursor is not at the end, things misbehave
<ogra_> ppisati, any idea about https://forum.snapcraft.io/t/wifi-and-bluetooth-on-snappy-ubuntu-on-a-dragonboard/1297 ?
<zyga-ubuntu> Chipaca: I think 3399 is ready for review now
<ppisati> ogra_: replied
<Chipaca> zyga-ubuntu: sorry, was away
<zyga-ubuntu> Chipaca: no worries at all
<Chipaca> zyga-ubuntu: yes it should
<Chipaca> zyga-ubuntu: doing that is possible
<Chipaca> zyga-ubuntu: but, i have yet to see a completer that does it
<zyga-ubuntu> aha
<zyga-ubuntu> so it's just harder to do and requires some extra features in go-flags?
<Chipaca> zyga-ubuntu: not necessarily go-flags
<Chipaca> zyga-ubuntu: it's harder to do, and involves looking at some bash variables
<Chipaca> zyga-ubuntu: go-flags carefully avoids looking at bash variables i think
<Chipaca> zyga-ubuntu: by this i mean: it's probably the snapd completion snipped that needs the extra work, not go-flags
<zyga-ubuntu> aha
<Chipaca> snippet*
<ogra_> ppisati, thanks!
<ogra_> ppisati, hmm, i wonder if that guy in the forum uses an oldish "build a dragonboard" tutorial or what
 * zyga-ubuntu is hungry
<zyga-ubuntu> time for something that resembles breakfast and includes not just coffee
<niemeyer> Good morning all
<niemeyer> Good afternoon to the other all
<zyga-ubuntu> niemeyer: hey, how was the trip back?
<niemeyer> zyga-ubuntu: Heya!
<niemeyer> It was event-less ;)
<mvo> Chipaca: if I want to test my profile.d complete.sh integration, what is the best snap to test that with? do we have a test-snapd-with-completion in the store?
<zyga-ubuntu> niemeyer: please have a look at 3399 when you have a moment
<niemeyer> zyga-ubuntu: ack
<zyga-ubuntu> niemeyer: I think all the major issues are resolved and we should either land it or iterate on some details and land it
<zyga-ubuntu> niemeyer: after eating something I'll start working on layouts
<zyga-ubuntu> niemeyer: unless I forgot something and there's some catch up from last week, I'll review my nots
<zyga-ubuntu> noteS*
<niemeyer> zyga-ubuntu: Sounds great!
<zyga-ubuntu> niemeyer: and on the upside, president vetoed (2/3 bill) so +1 for democracy :)
<niemeyer> zyga-ubuntu: Wow, \o/
<niemeyer> zyga-ubuntu: Close call.. :)
<zyga-ubuntu> yes, not over but everyone is very suprised and enthusiastic, it was commonly assumed he would just sign it
<Chipaca> mvo: I don't think we have it in the store; there's tests/lib/snaps/complexion/
<mvo> Chipaca: thank you
<mvo> Chipaca: ok, I have complexion now installed, what is the easiest test to see if tab completion for it works?
<mvo> Chipaca: pardon my ignorace, I can dig into the tests to figure it out if you are busy
<Son_Goku> morning all
<Son_Goku> zyga-ubuntu, did you manage to fix the snap-seccomp failure on 32-bit arches?
<ogra_> flexiondotorg, "Once upgraded to stretch I ran sudo snap install snapd " ??
<ogra_> (did you mean apt install ?)
<mvo> flexiondotorg: thanks a bunch for the details - I'm back so I can try this now too. we tried it during the sprint but couldn't reproduce the issue
<flexiondotorg> mvo No problem.
<flexiondotorg> ogra_ Yes, I'll edit. Thanks,
<flexiondotorg> I type snap more than apt these days. Muscle memory is replaced :-)
<ogra_> yeah, i know what you mean :)
<zyga-ubuntu> Son_Goku: not yet, I'll look at it after lunch
<zyga-ubuntu> Son_Goku: just finished PR 3399
<Son_Goku> PR#3399?
<Son_Goku> oh, right... snapd#3399
<mup> PR snapd#3399: many: add the interface command <Created by zyga> <https://github.com/snapcore/snapd/pull/3399>
<Son_Goku> nope
<Son_Goku> what's the magic thing to make the bot tell us stuff?
<flexiondotorg> ogra_ Is now a good time to make an introduction?
<ogra_> as good as any time :)
<mup> PR snapd#3616 opened: cmd/snap-repair: implement Runner.Verify and use it to check signatures of repairs from Next <Created by pedronis> <https://github.com/snapcore/snapd/pull/3616>
<flexiondotorg> ogra_ I like to introduce you to ikey
 * ikey bows
<flexiondotorg> ogra_ ikey is the lead for Solus. A from scratch Linux OS.
<flexiondotorg> ikey ogra_ is, well, a bit a legend around here ;-)
<ikey> :] nice to meet ya.
<Son_Goku> O.o
<flexiondotorg> ogra_ As discussed last week ikey is interested in enabling snapd in Solus.
<Son_Goku> ikey, hello
<Son_Goku> wait, wut
<Son_Goku> really?
<ogra_> hey ikey !
<ikey> howdo :]
<ikey> Son_Goku, gotta adapt. i wont be the HD-DVD in this battle.
<Son_Goku> well, I guess that's fair
 * ikey figures its not appropriate to use tape comparisons anymore
<Son_Goku> that's why I have ze snapd in Fedora :)
<flexiondotorg> ogra_ From my discussion with ikey he would like someone on hand to answer questions regarding landing AppArmor (plus our patches) in the kernel Solus ship.
<ogra_> well, happy to help, thought we might need some help from kernel guys like ppisati or jj
<ogra_> *though
<flexiondotorg> ikey I think you'll generally be OK packaging snapd itself, but should you need any clue ogra_ can either assist or get the right people involved.
<ogra_> yeah
<ikey> sounds good to me
<ogra_> you will need the appramor patches but also some kernel config defaults (for seccomp cgroups etc)
<flexiondotorg> ogra_ Yes, JamieBennett did suggest that p_pisati and j_j might be needed.
<ogra_> yup
<ikey> are the apparmor patches contained anywhere .. sane?
<flexiondotorg> ogra_ ikey I'll consider you two introduced and bow out.
<ikey> by sane i mean "not a hidden kernel team ppa on launchpad that i cant access"
<flexiondotorg> But I'm happy to be tagged here and brought back into the discussion.
<ikey> which has been my experience so far ..
<ikey> cheers flexiondotorg
<ogra_> ikey, like  http://kernel.ubuntu.com/git/jj/linux-apparmor-backports/  ?
<ikey> anyways im not gonna be able to get snapd packaged for a couple of days yet, got a bit of a workload to get through myself
<ikey> looks legit
<ikey> cheers
 * ikey bookmarks
<ogra_> :)
<Son_Goku> hmm
<Son_Goku> well, if it's not all merged by 4.14, then I'll probably have to use some part of this too :/
<ogra_> ikey, so i'D suggest you just start once you have time for it and bomb me with questions as they come up :)
 * Son_Goku bookmarks
<ikey> thanks :]
<JamieBennett> Son_Goku: We are trying to get everything upstream by 4.14, it is down to the kernel upstream gods though
<Son_Goku> JamieBennett, with AppArmor, aren't you guys the upstream gods too?
<JamieBennett> Son_Goku: Yup but we rely on code flowing upstream to the kernel
<JamieBennett> i.e. Linus
<bloodearnest> hey folks. I've been trying to run nginx in strict confinement, but the setgroups(2) syscall is not allowed. The only interfaces I have are network and network-bind
<bloodearnest> is there another interface I can request to be able to do this
<bloodearnest> squid also has this issue, fwiw
<ogra_> snap services run as root ... try to reflect that in your config
<ogra_> (i.e. if there is a user/group option in the config, point it to root)
<bloodearnest> ogra_, yep, have done already
<bloodearnest> still seems to want to setgroups stuff
<bloodearnest> it runs as root fine in devmode
<zyga-ubuntu> bloodearnest: not yet, but this is going to be implemented soonish
<zyga-ubuntu> bloodearnest: we desiged how it would work
<zyga-ubuntu> bloodearnest: as there are a few snaps that are affected already
<bloodearnest> zyga-ubuntu, thanks for the info
 * ogra_ tickles zyga-ubuntu with https://github.com/snapcore/pi3-gadget/pull/11 again ... 
<mup> PR pi3-gadget#11: build uboot from source, pull blobs from upstream, use dtbs from archive <Created by ogra1> <https://github.com/snapcore/pi3-gadget/pull/11>
<ogra_> (i have pending stuff that waits for it to land ...)
<zyga-ubuntu> ogra_: I'll check today for sure, sorry, I'm getting back to "what shall I do" after all the backlog
<ogra_> zyga-ubuntu, thanks ... as i said before it has all been tested in and out and my local images all run with it already ... just needs a second ack so i can move on and apply the same to pi2 and cm3
<ogra_> the resulting binary snap is identical...
<zyga-ubuntu> excellent
 * mcphail wonders when we'll be seeing zyga-solus..?
<zyga-ubuntu> mcphail: I don't have enough desk space :)
<mcphail> heh :)
<pedronis> Chipaca: going to have a break and then will look at your open PRs I think instead of starting something new
<Chipaca> pedronis: that sounds like an objectively stupendous idea
<fgimenez> mvo: the title of bug #1690083 should be set to .14 instead of .10, right?
<mup> Bug #1690083: [SRU] 2.26.10 <verification-needed> <verification-needed-trusty> <verification-needed-xenial> <verification-needed-yakkety> <verification-needed-zesty> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Trusty):Fix Committed> <snapd (Ubuntu Xenial):Fix Released> <snapd (Ubuntu Yakkety):Fix
<mup> Committed> <snapd (Ubuntu Zesty):Fix Committed> <https://launchpad.net/bugs/1690083>
<mvo> fgimenez: yes
<mvo> fgimenez: eh, one sec
<mvo> fgimenez: actually we only release 2.26.10 as a deb, the other fixes were all re-exec releated so not releavant for the deb itself
<mvo> fgimenez: but if you feel it should be in sync I can do that too
<fgimenez> mvo: np not needed at all, then there won't be a 2.26.14 deb release, right?
<mvo> fgimenez: correct
<fgimenez> mvo: cool thx
<zyga-ubuntu> mvo: when you reproduced the problem on raspbian, which versions did you have and what did system logs say?
<mvo> zyga-ubuntu: I started with 2.21 and when to stable (2.26.10). the configure hook was in defunct state in ps afx
<mvo> zyga-ubuntu: no denials AFAICS in the system logs, but let me double check that
<mvo> zyga-ubuntu: also subsequent dpkg --purge snapd; apt install snapd; snap install core worked so something is either racy or setup on first deb install or something, I'm running this in a loop now (except that it takes forever so the loop iteration is ~2 or so so far)
<zyga-ubuntu> aha
<zyga-ubuntu> interesting
<ogra_> raspbian should just switch to ubuntu core :P
<ogra_> reading about hours for upgrading always makes me think that
<cachio> niemeyer, so, should i leave 1 worker for fedora?
<cachio> I have merged with trunk and testing new tests within fedora, I'll be pushing soon
<ogra_> mvo, did you see bug 1705708 ? ... fun fact ... having the same core on two different machines here (laptop vs desktop) and using the same gui snap , on one machine opening urls does actually still work, the other doesnt ...
<mup> Bug #1705708: latest change to xdg-open not applied to the unity7 interface <snapd:In Progress by ogra> <https://launchpad.net/bugs/1705708>
<ogra_> (both run core 2381)
<Chipaca> ogra_: something something armel something
<ogra_> Chipaca, hmm ?
<Chipaca> ogra_: re <ogra_> raspbian should just switch to ubuntu core :P
<ogra_> ah
<ogra_> yeah
<ogra_> we need a v6 build
<cachio> niemeyer, it is ready PR 3505
<cachio> merged with latest changes in trunk and running with 1 worker for fedora
<niemeyer> cachio: Thanks!
<niemeyer> The report is out:
<niemeyer> https://forum.snapcraft.io/t/weeks-24-29-of-2017-in-snapd/1421/1
<pedronis> Chipaca: posted some first pass comments on two of the PRs
<Chipaca> pedronis: i saw them, thank you! haven't replied yet though
<flexiondotorg> Snapcraft Office Hours is starting in a few minutes here - https://www.youtube.com/watch?v=xPtPiaHIghs
<diddledan> I'm there, thanks flexiondotorg
<cachio> Chipaca, if you have some time, could you please take a look to this one PR 3505
<cachio> Chipaca, it is almost ready to lunch
<Chipaca> cachio: hungry lapsus there?
<cachio> Chipaca, hehehe, land, sorry :)
<cachio> Chipaca, my stomach betrays me :)
<Chipaca> cachio: question for you: why dropping the call to MountDir() in snapEnv?
<Chipaca> ahhhh
<Chipaca> because of inside vs outside
<Chipaca> this is going to get confusing :-(
<Chipaca> cachio: anyway, you have two +1's already, go for it
<cachio> Chipaca, yes
<cachio> also we could join dirs.CoreSnapMountDir, info.MountDir()
<mcphail> That ruby plugin looks good. I'm sure there was a ruby app I was going to try to snappify. If I could only rememebr what it was...
<cachio> niemeyer, do you think the fedora PR is ready to be landed?
<niemeyer> cachio: Which one?
<cachio> 3505
<cachio> niemeyer, once that is merged, I'll push the changes on the opensuse one
<niemeyer> cachio: "The snap is leaving in $SNAPMOUNTDIR the .sh, and in $SNAP_INSTALL_DIR the commands."
<niemeyer> cachio: The question is why SNAP___INSTALL___DIR vs. SNAPMOUNTDIR.
<cachio> niemeyer, looking
<cachio> niemeyer, as I see, both can be used
<cachio> $SNAP_INSTALL_DIR/bin/sh or $SNAPMOUNTDIR/bin/test-snapd-tools.sh
<niemeyer> cachio: Do you see the clear difference in syntax in those two variables?
<niemeyer> cachio: Although they look *extremely* alike?
<cachio> niemeyer, between which ones?
<cachio> niemeyer, SNAPMOUNTDIR and SNAP_INSTALL_DIR?
<niemeyer> cachio: My obsessive-compulsive disorder is extremely bothered by the fact you can't even see what I'm talking about :P
<niemeyer> cachio: Of course.. isn't that why I just asked above
<niemeyer> cachio: The question is why SNAP___INSTALL___DIR vs. SNAPMOUNTDIR.
<niemeyer> cachio: See the underlines?
<cachio> yes
<niemeyer> cachio: SNAP***INSTALL**DIR
<niemeyer> cachio: SNAP**MOUNT**DIR
<cachio> niemeyer, you mean, why we are not using underscores?
<cachio> for SNAPMOUNTDIR
<niemeyer> cachio: I don't really care so much about which way we go.. the first question is why do we have those two conventions side by side instead of one
<cachio> and we are using for SNAP_INSTALL_DIR
<cachio> niemeyer, well, agree we should have a convention for that
<niemeyer> Phew ;)
<cachio> for example, TESTSLIB has not any _
<cachio> so, the convention seem to be "no _"
<niemeyer> cachio: I'd be fine with that.. it also doesn't have to be done in this PR
<niemeyer> cachio: We just need to ack the conflict and have a plan to eventually converge
<cachio> niemeyer, sure, I'll take a look to see in which places we have this divergence
<cachio> niemeyer, so if the change is so big, we can discuss it in the forum
<cachio> otherwise I'll create a PR to unify it
<niemeyer> cachio: Thanks
<niemeyer> cachio: We should evaluate which way is more clear
<niemeyer> cachio: Wehavesomelongstringsandingeneralreadingthingslikethisbecomeshard
<cachio> niemeyer, yes, I prefer with '_'
<cachio> but, it would be a big change
<niemeyer> cachio: We don't need to rush this.. at first just making sure we don't have such obvious divergences would be easy
<niemeyer> SNAP_MOUNT_DIR, for example
<cachio> niemeyer, sure
<cachio> niemeyer, doing a fast check, just TESTSLIB, SNAPMOUNTDIR and LIBEXECDIR are without _
<cachio> niemeyer, then, all the variables that we use for the environment and spread are using _
<cachio> niemeyer, the change is really easy but the diff will be huge, I could split it by variable
<niemeyer> cachio: If that's the only change, even if it's huge it's easy to review
<niemeyer> cachio: #3505 is in
<cachio> niemeyer, thanks
<mup> PR snapd#3505 closed: tests: enable main suite on fedora <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3505>
<jdstrand> zyga-suse: hey, I have a fix for gary's https://github.com/snapcore/snapd/pull/3587
<mup> PR snapd#3587: Using udev tagging for snap interfaces <Created by adglkh> <https://github.com/snapcore/snapd/pull/3587>
<jdstrand> zyga-suse: iirc, we can commit to other branches. what is the trick to doing that?
<zyga-ubuntu> jdstrand: hey
<zyga-ubuntu> jdstrand: oh, that's intereting
<zyga-ubuntu> jdstrand: the trick is to add a remote and just push to the branch directly
<zyga-ubuntu> jdstrand: git remote add adglkh git@github.com:adglkh/snapd
<zyga-ubuntu> jdstrand: that should do it
<zyga-ubuntu> jdstrand: then git fethc adglkh
<zyga-ubuntu> jdstrand: then git checkout udev_tagging
<zyga-ubuntu> jdstrand: then do whatever you want and "git push adglkh"
<zyga-ubuntu> jdstrand: quick question, I actually joined to ask you one :)
<zyga-ubuntu> jdstrand: location control is not constrained to core snap but the interface talkes about unconfined peers
<zyga-ubuntu> jdstrand: missing check?
<zyga-ubuntu> (well, partially talks about unconfined, maybe I'm mistaken)
<jdstrand> zyga-ubuntu: location-control is written to only be available as an app snap (ie, no deb)
<jdstrand> zyga-ubuntu: I assume you are talking about the rule at line 66?
<jdstrand> zyga-ubuntu: that should have a comment above it, but the idea is that unconfined is allowed to talk to location-service
<zyga-ubuntu> jdstrand: yes, I understand my mistake now
<jdstrand> zyga-ubuntu: sigh, I did what you said for adglkh but the review is all messed up. see https://github.com/snapcore/snapd/pull/3587/files
<mup> PR snapd#3587: Using udev tagging for snap interfaces <Created by adglkh> <https://github.com/snapcore/snapd/pull/3587>
<zyga-ubuntu> jdstrand: let me look
<jdstrand> zyga-ubuntu: eg, arch/arch.go. that isn't a change he made
<zyga-ubuntu> note that you can always push --force to undo your changes
<zyga-ubuntu> jdstrand: I refreshed the diff
<zyga-ubuntu> jdstrand: I cannot see any changes to arch.go
 * zyga-ubuntu goes to get some tea
<zyga-ubuntu> jdstrand: I'll be back shortly
<jdstrand> zyga-ubuntu: https://github.com/snapcore/snapd/pull/3587/files
<mup> PR snapd#3587: Using udev tagging for snap interfaces <Created by adglkh> <https://github.com/snapcore/snapd/pull/3587>
<jdstrand> zyga-ubuntu: first thing shows arch/arch.go
<jdstrand> tyhicks: hey, can you help me with a git thing?
<tyhicks> jdstrand: what's up?
<jdstrand> tyhicks: can you read backscroll between me and zyga? basically, I want to do the 'you can always push --force to undo your changes'
<jdstrand> tyhicks: I want to get this back to 8401774d3b2f5fa2d7e59120d56988b92e5995c6 in the remote branch
<kyrofa> jdstrand, create a new branch based on that commit: `git branch my-new-branch 8401774d3b2f5fa2d7e59120d56988b92e5995c6`
<kyrofa> jdstrand, then force-push it back to the branch in the PR
<kyrofa> `git push adglkh my-new-branch:udev_tagging --force`
<kyrofa> (assuming your adglkh remote is called that)
<tyhicks> I'd expect `git push --force adglkh 8401774d3b2f5fa2d7e59120d56988b92e5995c6:udev-tagging` to also work
<kyrofa> Man that is so hard to type
<jdstrand> neither works
<jdstrand> ah, I typoed something
<mup> PR snapd#3587 closed: Using udev tagging for snap interfaces <Created by adglkh> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/3587>
<jdstrand> now all the changes are gone
<jdstrand> jeez
<jdstrand> and it says I closed it
<jdstrand> maybe I picked the wrong commit
<kyrofa> Hahaha, you still have your modified branch around I assume?
<jdstrand> I do
<kyrofa> Yeah, make sure you grabbed the right commit
<tyhicks> "adglkh:udev_tagging was force-pushed and no longer has any new commits."
<tyhicks> "Pushing new commits will allow the pull request to be re-opened."
<tyhicks> I can help you with how to use git to do what you want to do but I'm not as much help in knowing what the result will be in the github web interface :/
<jdstrand> well, at this point I just want to go back to what he had
<tyhicks> jdstrand: what's the name of the local branch representing his last changes?
<kyrofa> jdstrand, can you push that branch to your fork?
<jdstrand> tyhicks: ok. I have a local branch called adglkh.udev_tagging
<tyhicks> jdstrand: it sounds like `git push adglkh adglkh.udev_tagging:udev_tagging` (try without --force first) will get the web ui back into shape
<jdstrand> tyhicks: this was created with: git checkout -b adglkh.udev_tagging upstream/master ; git pull git@github.com:adglkh/snapd.git udev_tagging
<zyga-suse> kyrofa: no need for a branch
<jdstrand> tyhicks: that has a merge from master and a fix to opengl_test.go. ie, where I was before I tried to undo things
<zyga-suse> hmm
<zyga-suse> I see some things happened since I made tea
<zyga-suse> (disclaimer, my lovely wife made tea and I just found it)
<zyga-suse> jdstrand: note that you stil have the full history locally in your machine in reflog
<zyga-suse> git reflog
<tyhicks> it sounds like he already has a branch with full history so I didn't want to steer him towards reflog just yet
<jdstrand> To git@github.com:adglkh/snapd
<jdstrand>  ! [remote rejected] adglkh.udev_tagging -> udev_tagging (permission denied)
<ubottu> jdstrand: I am only a bot, please don't think I'm intelligent :)
<jdstrand> error: failed to push some refs to 'git@github.com:adglkh/snapd'
<jdstrand> that is from inside a checkout of adglkh.udev_tagging
<tyhicks> I'm confused how you were able to write to that branch before if you're getting a permission denied error now
<tyhicks> (I did think it was odd that you could write to someone else's branch but I wasn't sure how github branch perms work)
<kyrofa> tyhicks, github magic
<kyrofa> tyhicks, when creating a PR there's a checkbox saying "allow modifications from maintainers"
<tyhicks> ah
<jdstrand> github seems to know that I don't know what I'm doing and took that away from me :P
<jdstrand> I'm guessing when the PR was closed that was unchecked?
<kyrofa> Ah, I bet so, indeed
<kyrofa> Hahaha, so it let you kill his branch, but won't let you fix it. How kind
<jdstrand> sigh, I was trying to help gary and I just created work for him
 * zyga-suse looks
<zyga-suse> yeah, no more push there
<zyga-suse> on the up side, atom has git and github integration now
<zyga-suse> so when git command line bites, there's a nice UI around the corner
<zyga-ubuntu> jdstrand: btw, not security related really but maybe you're interested in 3399
<jdstrand> zyga-ubuntu: ack
<zyga-suse> jdstrand: thank you
<zyga-suse> jdstrand: there's going to be a similar for connections
<zyga-suse> jdstrand: that will largely replace "snap interfaces" (with an s)
<tyhicks> jdstrand: did you ever figure out what the problem was? was that the wrong commit?
<jdstrand> tyhicks: I think so yes; I should've used e9a9366d74fe70b966d6020877efdd55a28675dd, which was gary's last commit
<tyhicks> ok
<jdstrand> there was something which made me think it was the other commit but since everything is gone I can't say what. sigh
<zyga-ubuntu> reflog knows the truth :)
<jdstrand> I did push up my branch which has all his commits: https://github.com/snapcore/snapd/compare/master...jdstrand:adglkh.udev_tagging?expand=1
<jdstrand> so the work is not gone. I left a comment in the pr
<bladernr> This seems kinda stupid, but how do you install a text editor on Ubuntu Core to edit config files that need to exist in snaps?  For example, if I need to edit the hosts file for the dnsmasq snap to work as a DNS server, the only option I can find is vi, I'd much rather have VIM.  I can install a pinano snap to get Nano, but it won't allow me to edit anything outside of the snap itself, making it a bit useless.  Did I
<bladernr> miss something for installing pinano?
<bladernr> Maybe it needs to be in classic mode? or dev mode?
<zyga-suse> bladernr: hey, you can snap install classic
<zyga-suse> (not sure if it is in --edge or stable now)
<bladernr> zyga-suse, thanks.. looks like --edge, installing now.
<zyga-ubuntu> bladernr: great o/
<bladernr> zyga-ubuntu, ummm.... so classic is installed.  How to I get into "classic" mode?
<bladernr> bladernr@localhost:~$ snap install --classic pinano
<bladernr> error: cannot install "pinano": classic confinement is only supported on classic systems
<zyga-ubuntu> bladernr: it's a snap, run the app
<zyga-ubuntu> bladernr: you cannot install classic confinement snaps
<zyga-ubuntu> bladernr: but inside clasic the snap you can install vim with apt-get
<bladernr> ahhhh ok
#snappy 2017-07-25
<mup> PR snapd#3617 opened: Using udev tagging for snap interfaces <Created by adglkh> <https://github.com/snapcore/snapd/pull/3617>
<didrocks> sergiusens_: kyrofa: hey, any idea what's happening on https://build.snapcraft.io/user/ubuntu/ubuntu-make/59531 ? Local build works (on artful), and the only change with latest successful build on amd64 (https://build.snapcraft.io/user/ubuntu/ubuntu-make/56636) is changing a README.mdâ¦
<didrocks> sergiusens_: kyrofa: as build.snapcraft.io doesn't have a way to retrigger any build, I did a small edit on README.md, but the failure is reproducible: https://build.snapcraft.io/user/ubuntu/ubuntu-make/59842
<didrocks> cjwatson: hey, btw, do you know if there is a hidden way to retrigger a build on b.snapcraft.io? ^
<mup> PR snapd#3618 opened: Merge release/2.26 back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/3618>
<mvo> stgraber: hey, I'm looking into https://forum.snapcraft.io/t/snapcraft-cannot-cleanbuild-in-snapped-lxd/1424/ right now and wonder where i can find the lxd snapcraft.yaml and the source of the snap?
<mvo> pedronis: unless you think gustavo should have a look as well, I'm keen to merge 3496. sorry for the long delay with the review.
<mvo> pedronis: if you could update 3560 once its in, that would be great, then the diff is smaller :)
<pedronis> mvo: hi, IÂ think it's ok to merge
 * pedronis has breakfast
<mup> PR snapd#3496 closed: cmd/snap-repair:  start of Runner, implement first pass of Peek and Fetch <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3496>
<pedronis> I'll update the descendants after
<mvo> pedronis: thank you! I can also do that I think
<mvo> pedronis: but its fine, I will wait for you (enjoy breakfast) - I am in the middle of a different branch right now anyway :)
<pedronis> mvo: might be better if IÂ do it, I used rebased in at least on of them at some point, fear it might get confusing
<pedronis> for me
<mvo> pedronis: sounds good, thank you
<pedronis> mvo: done with snapd#3560  , the later ones are based on that one
<mup> PR snapd#3560: cmd/snap-repair: implement most logic to get the next repair to run/retry in a brand sequence <Created by pedronis> <https://github.com/snapcore/snapd/pull/3560>
<mup> PR snapd#3616 closed: cmd/snap-repair: implement Runner.Verify and use it to check signatures of repairs from Next <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/3616>
<zyga-ubuntu> good morning
 * zyga-ubuntu waves from very very rainy warsaw
<zyga-ubuntu> hey Chipaca
<Chipaca> zyga-ubuntu: \o!
 * zyga-ubuntu is working from the quiet national library today
<Chipaca> zyga-ubuntu: i've got the ideal thing for you then!
<Chipaca> zyga-ubuntu: https://www.youtube.com/watch?v=yf0Amcgxot8&t=79
<zyga-ubuntu> Chipaca: well
<zyga-ubuntu> Chipaca: no sound allowed in here :)
<mvo> zyga-ubuntu: hey, good morning!
<mvo> Chipaca: hey, good morning!
<Chipaca> zyga-ubuntu: https://www.youtube.com/watch?v=g4mHPeMGTJM :-(
<Chipaca> mvo: o/!
<zyga-ubuntu> Chipaca: I'll watch it back home
<zyga-ubuntu> Chipaca: or at the 2nd library
 * zyga-ubuntu is sad that none of the libraries actually allow you to borrow books anymore
<zyga-ubuntu> just read on site
<Chipaca> zyga-ubuntu: whaat :-(
<zyga-ubuntu> they should be called more appropriately
<zyga-ubuntu> Chipaca: yep
<Chipaca> zyga-ubuntu: that speaks badly of y'awl
<zyga-ubuntu> Chipaca: both the national library and the university library
<zyga-ubuntu> at least for regular mere non-PHD folks like me
<Chipaca> zyga-ubuntu: wellp, time to work on your phd then
 * Chipaca runs
<zyga-ubuntu> yes, just need to find a lottery ticket that lets me not work for 5 years
<zyga-ubuntu> then 5 more
<zyga-ubuntu> ^_^
<zyga-ubuntu> but yeah, otherwise very much what I want tod o
<Chipaca> zyga-ubuntu: it's really easy, i have a 2-step plan for you
<Chipaca> zyga-ubuntu: 1. be rich; 2. don't be poor
<zyga-ubuntu> Chipaca: ah and you forgot one thing
<zyga-ubuntu> Chipaca: 3 be young and pretty
<Chipaca> zyga-ubuntu: i counted that under 'rich'
<zyga-ubuntu> Chipaca: in the mean time https://github.com/snapcore/snapd/pull/3619
<mup> PR snapd#3619: interfaces/builtin: reduce duplication and remove cruft in Sanitize{Plug,Slot} <Created by zyga> <https://github.com/snapcore/snapd/pull/3619>
<zyga-ubuntu> some gardening
<zyga-ubuntu> files changed, 52
<mup> PR snapd#3619 opened: interfaces/builtin: reduce duplication and remove cruft in Sanitize{Plug,Slot} <Created by zyga> <https://github.com/snapcore/snapd/pull/3619>
<Chipaca> zyga-ubuntu: i'll do that next then
<zyga-ubuntu> but lots of red in it :)
<zyga-ubuntu> just cruft lifting
<zyga-ubuntu> let me go and see if the book I'm interested in is available now
<mvo> Chipaca: any news on the profile.d stuff from last night? sorry for nagging
<Chipaca> mvo: no :-(
<mvo> Chipaca: can I help in any way, happy to poke at this too, high priority for me currently
<mup> PR snapd#3616 opened: cmd/snap-repair: implement Runner.Verify and use it to check signatures of repairs from Next <Created by pedronis> <https://github.com/snapcore/snapd/pull/3616>
<Chipaca> mvo: so... one thing we _could_ do
<Chipaca> mvo: but makes me uncomfortable to think about too much on my own
<Chipaca> mvo: is to make snap tweak the user's bashrc
<pedronis> mmh
<Chipaca> mvo: it could be either forwards, adding a 'source profile.sh # added by snap' line
<Chipaca> mvo: ir negative, seeking out the broken 'source bash-completion' and commenting it out
<zyga-ubuntu> re
<Chipaca> mvo: i like 0 of these -- but it'd get the job done
<zyga-ubuntu> on the upside I got the book :)
<zyga-ubuntu> and I can work here all day
<zyga-ubuntu> so win-win
<zyga-ubuntu> (and it's quiet)
<pedronis> Chipaca: sounds a strange idea (tweaking bashrc);Â IÂ supose everything else is worse?
<Chipaca> pedronis: more like nothing else works
<Chipaca> that i could think of at least
<Chipaca> but i'm an egg
<pedronis> because ?
<Chipaca> pedronis: there's a bug in â¦ debian i guess?
<Chipaca> pedronis: there's /etc/profile.d/bash_completion.sh
<pedronis> but nothing uses it?
<Chipaca> pedronis: that loads the bash completion work
<Chipaca> pedronis: that gets loaded by /etc/profle, along with everything else in profile.d
<Chipaca> pedronis: but then the default .bashrc, from /etc/skel, loads it _again_
<Chipaca> pedronis: our profile snipped needs to load after bash completion is loaded
<Chipaca> snippet*
<pedronis> I see bashrc ends up loading:  /usr/share/bash-completion/bash_completion
<Chipaca> yes
<Chipaca> so, there's a number of ways that we can make it work
<Chipaca> if we patch bash-completion itself
<zyga-ubuntu> Chipaca: step 1: fix debial stable
<zyga-ubuntu> Chipaca: ^_^
<Chipaca> but if we can't do that, then we're stuck
<zyga-ubuntu> but at least you can hope to fix that ;)
<Chipaca> zyga-ubuntu: aw bless
<Chipaca> the easiest way to fix bash completion is to make it not load the default completer if there is one already
<zyga-ubuntu> Chipaca: one more, this time fully red: https://github.com/snapcore/snapd/pull/3620
<mup> PR snapd#3620: interfaces/builtin: discard empty Validate{Plug,Slot} <Created by zyga> <https://github.com/snapcore/snapd/pull/3620>
<mup> PR snapd#3620 opened: interfaces/builtin: discard empty Validate{Plug,Slot} <Created by zyga> <https://github.com/snapcore/snapd/pull/3620>
<pedronis> Chipaca: fwiw it seems to source stuff from /etc/bash_completion.d  but as back compat thing
<Chipaca> pedronis: yes
<pedronis> and then ~/.bash_completion
<zyga-ubuntu> mvo: did you see latest comments on https://bugs.launchpad.net/snappy/+bug/1674193
<mup> Bug #1674193: core snap's configuration hangs on debian | openSUSE | mainline kernel <Snappy:Fix Committed by morphis> <snapd (Debian):Fix Committed> <snapd (Fedora):Fix Committed by morphis> <snapd (openSUSE):Fix Released by morphis> <https://launchpad.net/bugs/1674193>
<zyga-ubuntu> mvo: I fail to see how that is possible since that is exactly what was fixed last week
<mvo> Chipaca: modifying the users .bashrc makes me uneasy. the other thing is that is tricky is when/how do we do it? iterate over all users? do it in snap run (which is too late)? other?
<mvo> zyga-ubuntu: looking
<Chipaca> mvo: thank you
<mvo> Chipaca: sorry :/
<Chipaca> mvo: no, really thank you :-)
<Chipaca> mvo: easiest way to kill something that makes me uneasy to think about doing is by pointing out it wouldn't work :-)
<zyga-ubuntu> mvo: unless we are missing something and people start with not-up-to-date debian 9
<mvo> Chipaca: heh :)
<mvo> zyga-ubuntu: yeah, its very confusing, I download an image now
<pedronis> Chipaca: so we need to ship a different  bash_completion ? with some bits added?
<mvo> zyga-ubuntu: aha, I think I know what is happening there. on undo we will not restart into the old snapd. so I guess what happend is: snapd-2.21 refreshes, restarts into 2.26.14, something fails (configure hook?), things are undone. snapd 2.26.14 keeps running, however there is no 2.26.14 snap anymore.
<zyga-ubuntu> mvo: oh
<zyga-ubuntu> mvo: did you manage to reproduce it?
<zyga-ubuntu> mvo: and didn't we ignore configure hook on core errors?
<mvo> zyga-ubuntu: strange enough - I got a configure hang on debina9 though, then it fails with cannot stat /var/lib/snapd/seccomp: no such file or directory
<zyga-ubuntu> (errors in the configure hook when running on the core snap)
<mvo> zyga-ubuntu: yes, we ignore those I suspect the issue is that it starts from 2.21 but I need to double check
<cjwatson> didrocks: there is not
<mvo> zyga-ubuntu: ok, this is confusing - the configure hook (snap-confine to be precise) is waiting for /var/lib/snapd/seccomp/bpf/snap.core.hook.configure.bin to show up. it *does* show up in the host, however strace shows me that snap-confine (the configure hook) is not seeing this. we are not doing any namespace stuff on debian, right? so why would it not see it?
<zyga-ubuntu> mvo: we do namespace stuff on debian just the same but I believe we read the bpf parts before that *and* even if I'm wrong /var/lib/snapd is shared with the host
<zyga-ubuntu> mvo: there's systemd in your system, right/
<mvo> zyga-ubuntu: let me check, this is a stock skretch install
<mvo> zyga-ubuntu: yes, systemd is there
<zyga-ubuntu> hmm mhm
<zyga-ubuntu> magic
<zyga-ubuntu> and why didn't it ever happen in spread?
<mvo> zyga-ubuntu: spread uses sid, right ? maybe its rleated to stretch
<mvo> zyga-ubuntu: anyway, puzzling
<mvo> zyga-ubuntu: what was the nsenter magic again to get inside the env of the core configure hook?
<zyga-ubuntu> mvo: I think spread uses sid, yes
<zyga-ubuntu> mvo: but spread qemu is stretch
<zyga-ubuntu> mvo: nsenter -m/run/snapd/ns/core.mnt
<mvo> zyga-ubuntu: /var/lib/snapd is empty in there
<mvo> zyga-ubuntu: like completely empty
<mvo> zyga-ubuntu: but mount claims /var/lib/snapd is mounted (type ext4 etc)
<zyga-ubuntu> mvo: can you pastebin /proc/self/mountinfo
<zyga-ubuntu> (from that namespace)
<zyga-ubuntu> and from outside
<mvo> zyga-ubuntu: mountinfo says /var/lib/snapd//detleted /var/lib/snapd
<zyga-ubuntu> and pastebin both to the forum
<zyga-ubuntu> oh
<zyga-ubuntu> cute!?! (not)
<zyga-ubuntu> anyway, let's do this in the forum
<zyga-ubuntu> very interesting I must say
<mvo> zyga-ubuntu: created the topic now
 * zyga-ubuntu looks
<zyga-ubuntu> mvo: did you pure snapd at any time?
<zyga-ubuntu> mvo: maybe what happened is that the core.mnt namespace sticks around
<zyga-ubuntu> you purge snapd
<zyga-ubuntu> and re-install
<zyga-ubuntu> and we use a stale core.mnt file
<zyga-ubuntu> (hence //deleted)
<zyga-ubuntu> do a quick test please
<zyga-ubuntu> unmount /run/snapd/ns/core.mnt
<zyga-ubuntu> and install core again
<mvo> zyga-ubuntu: sure, one sec
 * zyga-ubuntu found the power plug and is happy not to live on a ticking clock anymore
<zyga-ubuntu> but whatever it is, my fix for stale mount namespace needs to include //deleted checks
<zyga-ubuntu> mvo: any luck with unmounted core.mnt?
<mvo> zyga-ubuntu: I was just trying to reproduce it again
<mvo> zyga-ubuntu: I did reboot into a different kernel for testing in the meantime
<mvo> zyga-ubuntu: hrm, hrm, now I cannot reproduce it anymore, even when I purge snapd
<zyga-ubuntu> mvo: replied
<zyga-ubuntu> mvo: run conifugre hook, purge, run configure hook
<pedronis> Chipaca: naming is hard(tm)
<mvo> zyga-ubuntu: did this now, not breaking
<Chipaca> (â¯Â°â¡Â°ï¼â¯ï¸µ â»ââ»
<zyga-ubuntu> mvo: I must say it is interesting how many edges we found to be rough over the months/year
<zyga-ubuntu> Chipaca: huh?
<mvo> zyga-ubuntu: yes, the re-exec thing from arbitrary starting points makes things complicated
<Chipaca> zyga-ubuntu: that was to pedronis :-)
<Chipaca> â¬ââ¬ï»¿ ã( ã-ãã) sorry
 * zyga-ubuntu wonders how many other fantastic emjoji we'd have if the table could include a teapot or a plant
<Chipaca> zyga-ubuntu: â¬ââ¬â°Í¡â(áµáµáµÍâ)
<Chipaca> zyga-ubuntu: it's just too small for your eyes to see
<zyga-ubuntu> hahah
<zyga-ubuntu> nice :)
<zyga-ubuntu> mvo: can you use snapshots in your vm?
<zyga-ubuntu> mvo: maybe start with a pristine image, snapshot that
<zyga-ubuntu> mvo: install snapd, snapshot that (separately)
<zyga-ubuntu> mvo: and try to get into the problem
<zyga-ubuntu> mvo: then whatever you have can be inspected forever
<mvo> zyga-ubuntu: yeah, too late now, whatever I did I did not snapshot  :(
<mvo> zyga-ubuntu: and can not get back into currently
<zyga-ubuntu> mvo: since now you said purging doesn't make it broken I wonder if that shoots my hypothesis
<mvo> zyga-ubuntu: like - now it is working
<mvo> zyga-ubuntu: I think your hypothesis is good, maybe it was not a purge, maybe it was something else (an upgrade?)
<mvo> zyga-ubuntu: I took a somewhat old VM, apt full-upgraded,  dpkg --purge snapd (because it had core already); snap install --edge core; BOOM
<zyga-ubuntu> mvo: do we remove /run/snapd/ns on purge?
<zyga-ubuntu> if we do then purge is not the thing
<zyga-ubuntu> because that thing cannot be stale when it is gone
<mvo> zyga-ubuntu: we do umount /run7snapd/ns on purge
<zyga-ubuntu> mvo: in that case it must have been something else
<zyga-ubuntu> mvo: is dpkg doing some fancy things when it updates packages? any directory changes?
<zyga-ubuntu> mvo: did the apt-get --dist-upgrade include snapd?
<pedronis> mvo:  when did we start to do that though?Â  (unmount /run/snapd/ns in purge? )
<mvo> pedronis: I see message related to it on my debian box, I need to check when exactly we started doing that
<mvo> zyga-ubuntu: yes, snapd was upgraded 2.21-2, 2.21-2+b1
<mvo> zyga-ubuntu: /me tries to reproduce using upgrade
<zyga-ubuntu> mvo: aha, interesting
<zyga-ubuntu> mvo: I doubt dpkg would do something that would cause the package update to remove a directory like /var/lib/snapd though
<zyga-ubuntu> mvo: but if you can try the 2.21-2 -> 2.21-2+b1 update again
<zyga-ubuntu> that would be a useful data point
<zyga-ubuntu> I recall that //deleted shows up when the backing store goes away
<zyga-ubuntu> I moved my kernel sources to my desktop so I cannot cross reference locally, let me check something online
<mvo> zyga-ubuntu: hrm, hrm, upgrade, purge, install, upgrade, no boom, just works
<zyga-ubuntu> mvo: http://elixir.free-electrons.com/linux/latest/source/fs/dcache.c#L3363 and http://elixir.free-electrons.com/linux/latest/source/fs/proc_namespace.c#L130
<ogra_> cjwatson, did anything change with the builders last night ? all (except s390x it seems) my daily builds of the core snap suddenly fail with:
<ogra_> P: Begin bootstrapping system...
<ogra_> [2017-07-25 04:17:00] lb_testroot
<ogra_> E: need root privileges
<ogra_> P: Begin unmounting filesystems...
<ogra_> P: Saving caches...
<ogra_> chroot: cannot change root directory to 'chroot': No such file or directory
<ogra_> cjwatson, https://launchpad.net/~snappy-dev/+snap/core for details
<cjwatson> ogra_: fix for https://bugs.launchpad.net/launchpad-buildd/+bug/1702656 was (mostly) rolled out
<mup> Bug #1702656: Run snapcraft as non-root (with passwordless sudo) <launchpad-buildd:Fix Committed by cjwatson> <https://launchpad.net/bugs/1702656>
<ogra_> cjwatson, ah, thanks
<cjwatson> ogra_: can you just run with sudo?
<ogra_> cjwatson, is that configured passwordless in the buildd ?
<cjwatson> ogra_: yes
<mvo> zyga-ubuntu: thanks, I give up on this for now and have lunch. slightly frustrating
<cjwatson> ogra_: I think just changing "ENV := PROJECT=ubuntu-core ..." to "ENV := sudo PROJECT=ubuntu-core ..." would do the trick
<cjwatson> Maybe with SUDO := sudo and $(SUDO) if you want a bit of extra configurability
<ogra_> thanks! will add that
<ogra_> (though it might need more, the check and install targets in the makefile touch the chroot as well)
<zyga-ubuntu> mvo: I'll check it myself back home
<zyga-ubuntu> mvo: one interesting fact is that snap-confine (which may run in classic snap environment) now needs to run snap-update-ns
<zyga-ubuntu> mvo: so if the rabbit hole wasn't deep enough I just brough a new shovel
<zyga-ubuntu> (now as in litterally right now on my disk in a new branch)
<niemeyer> Hello all
<zyga-ubuntu> niemeyer: o/
<cjwatson> ogra_: ah, right, yeah
<cjwatson> ogra_: would appreciate confirmation when you get a result, as we ought to do manual upgrades of s390x
<ogra_> cjwatson, will let you know
<cjwatson> ta
<Chipaca> mvo: i have good news: on fedora 25 the profile.d approach would work
<mup> PR core#51 opened: use sudo to work around LP: #1702656 <Created by ogra1> <https://github.com/snapcore/core/pull/51>
<ogra_> mvo, zyga-ubuntu ^^^^ can i get two acks to actually test-build in the LP buildd
<ogra_> (travis passes fine but wont help since the LP env is different now)
<zyga-ubuntu> yep
<zyga-ubuntu> ogra_: +1
<ogra_> thx
<mvo> ogra_: yes, go for it
<mvo> Chipaca: oh, nice. what is the difference?
<ogra_> thanks !
<mup> PR core#51 closed: use sudo to work around LP: #1702656 <Created by ogra1> <Merged by ogra1> <https://github.com/snapcore/core/pull/51>
 * ogra_ triggers test builds and crosses fingers that he catched all occurences
<cjwatson> ogra_: sorry for the disruption, I test-built various things but totally forgot about core being a special snowflake
<mup> PR snapd#3618 closed: Merge release/2.26 back into master <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3618>
<cjwatson> I think it's long-term better this way
<ogra_> cjwatson, well there is more in my set of snaps that uses chroots in chroots etc ... but now that i know about it i can adapt ... no prob
<ogra_> ppisati, ^^^ you might need to look into this too for the kernel snap builds (adding sudo to the commands that actually require root ... like the chroot and debootstrap commands in the Makefile)
<ogra_> grrr ... forgot to sync Gh to LP before hitting the build button ...
<ogra_> bah ... needs more sudo it seems
<ogra_> rm -f config/hooks/*
<ogra_> rm: cannot remove 'config/hooks/00-uid-gid-fix.chroot_early': Permission denied
<ogra_> rm: cannot remove 'config/hooks/01-divert-grub-install.chroot_early': Permission denied
<ogra_> rm: cannot remove 'config/hooks/01-setup_user.chroot': Permission denied
<ogra_> ...
<ogra_> funny, i wouldnt have expected that to be root owned
<ogra_> (given the unprivileged snapcraft did put it in place originally)
<mup> PR core#52 opened: also use sudo for all file operations <Created by ogra1> <https://github.com/snapcore/core/pull/52>
<ogra_> mvo, zyga-ubuntu ^^^^ one more please
<ogra_> (it should be fine then)
<zyga-ubuntu> ogra_: looking
<zyga-ubuntu> ogra_: done
<ogra_> thx
<mvo> +1
 * ogra_ waits for travis ... 
<Chipaca> mvo: they don't do bash completion in .bashrc :-)
<Chipaca> mvo: they just have the /etc/profile.d/bash_completion.sh
<niemeyer> Chipaca: More comments on snapd#3614.. let me know if you'd like to talk about those
<mup> PR snapd#3614: daemon, client, cmd/snap: implement "snap status" <Created by chipaca> <https://github.com/snapcore/snapd/pull/3614>
<Chipaca> niemeyer: i've seen them come in, yes
<Chipaca> i'm beyond the point of talking about this stuff. I'll just do whatever you say.
<mvo> Chipaca: aha, nice
<niemeyer> Chipaca: Okay, so let's keep that in the PR queue until you're ready to talk about it again
<Chipaca> niemeyer: i've been working on this same bit of functionality for over a month, i'm ready to be done with it
<niemeyer> Chipaca: Or somebody else is.. we need someone that is willing to think through the points made so we can have a shared idea of the problem
<mup> PR snapd#3621 opened: cmd/snap-{confine,update-ns}: apply mount proifles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
<zyga-ubuntu> first WIP branch on snap-update-ns/snap-confine and layouts
<zyga-ubuntu> ignore it for now, I mainly pushed it to see if tests pass and discuss something with jdstrand later
<niemeyer> Chipaca: In fairness, many of the points I made are exactly the same as a month ago
<Chipaca> i'm going to go have lunch
<niemeyer> Nice..
<zyga-ubuntu> I'm past starving now, so I can spend some time to collect notes and then have a call with everyone
<niemeyer> zyga-ubuntu: Tests are broken on snapd#3620
<mup> PR snapd#3620: interfaces/builtin: discard empty Validate{Plug,Slot} <Created by zyga> <https://github.com/snapcore/snapd/pull/3620>
<mup> PR core#52 closed: also use sudo for all file operations <Created by ogra1> <Merged by ogra1> <https://github.com/snapcore/core/pull/52>
<niemeyer> cachio: In #3604, why is it increasing the number of workers?
<niemeyer> mvo: Can you have a look at snapd#3604 when you have a moment, specifically on the #cgo statement on snap-seccomp, to see if it looks okay considering the issues we know about
<mup> PR snapd#3604: tests:  enable main suite for opensuse <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3604>
<zyga-ubuntu> niemeyer: oh, thanks
<zyga-ubuntu> cachio, fgimenez: random error on interface-cups-control: https://travis-ci.org/snapcore/snapd/builds/257218359?utm_source=github_status&utm_medium=notification
<zyga-ubuntu> sorry, interfaces-cups-control
<zyga-ubuntu> let me know if you want to collect the long
<zyga-ubuntu> *log
<zyga-ubuntu> and if not I'll re-trigger this
<zyga-ubuntu> "Error - scheduler not responding"
<ogra_> cjwatson, ... hmm the build succeeds, but the staging step in snapcraft falls over when it tries to make use of the resulting dir ... https://launchpad.net/~snappy-dev/+snap/core/+build/59965/+files/buildlog_snap_ubuntu_xenial_amd64_core_BUILDING.txt.gz
<ogra_> (since it is all root owned ... )
<fgimenez> zyga-ubuntu: thanks! indeed, lpr scheduler not working, have you seen it on other archs?
<zyga-ubuntu> nope, first time I saw this
<zyga-ubuntu> and I suspsect it's not related to the PR
<zyga-ubuntu> fgimenez: btw, I noticed that we have a disparity in debian testing
<zyga-ubuntu> fgimenez: the qemu image tests debian 9
<ogra_> cjwatson, snapcraft itself would have to run the staging step under sudo, i dont think i can do anything on the snap side for this ... :/
<zyga-ubuntu> fgimenez: but the linode machine tracks sid
<zyga-ubuntu> fgimenez: we should keep those separate as sid is moving
<ogra_> cjwatson, couldnt you make the sudo behaviour conditional based on the snap type in snapcraft.yaml so that "type: os" and "type: kernel" simple keep the old behaviour ?
<ogra_> *simply
<ogra_> (and run the build as root)
<niemeyer> snapd#3568 has a review.. any takes for the second review?
<mup> PR snapd#3568: snapctl: add new `snapctl internal configure-core`  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3568>
<zyga-ubuntu> niemeyer: I can do that after standup, on my way to find anything edible that doens't run away
<niemeyer> zyga-ubuntu: Thanks!
<niemeyer> zyga-ubuntu: and good luck :)
<cjwatson> ogra_: Hmm.  Ugly, but I guess we may have no alternative.
<sergiusens> niemeyer: mvo I've been pinged about https://bugs.launchpad.net/juju/+bug/1705988 (error is -> run hook "configure": cannot change profile for the next exec call: No such file or directory)
<mup> Bug #1705988: snap install --classic juju fails <canonical-is> <juju:Incomplete> <snapd:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1705988>
<cjwatson> ogra_: What about gadget?
<ogra_> cjwatson, usually doesnt need root
<cjwatson> ogra_: It'd mean we have to start parsing snapcraft.yaml directly in launchpad-buildd, which has previously been unnecessary.
<Chipaca> niemeyer: 'm back from lunch. Less grumpy now.
<Chipaca> niemeyer: let me rephrase what I said: I think you're right on most of the points, and on the points I don't, I haven't been able to convince you otherwise. I'll be implementing your suggestions as I understand them, and we can iterate.
<niemeyer> Chipaca: Thank you!
<ogra_> cjwatson, yeah ... understood ... os has always been special though ... since you have a full root that includes /dev and all ... not sure if there is any way to do it differently ...
<niemeyer> Chipaca: You'll also see some self-conflict on the comments.. which means I'm also trying to figure that stuff out
<cjwatson> ogra_: I'm inclined to just revert this launchpad-buildd change for now.
<ogra_> i'm fine with that as well ... :)
<pedronis> mvo: you already branched 2.27 a while ago right? you will not take a new snapshot?
<cjwatson> ev probably won't be, but such is life ...
<ogra_> cjwatson, doesnt lp-buildd actually call snapcraft step-wise ? (i.e. not plain snapcraft but each step)
<cjwatson> ogra_: Only in that it calls pull separately.
<ogra_> cjwatson, then "snapcraft stage" could simply always run as root while all other steps keep the dropped privs
<ogra_> ah, k ...
<cjwatson> ogra_: Yeah, that's one viable option for the future.  I think it requires more testing than I want to put into a "stop the bleeding" change, though.
<ogra_> yeah
<cjwatson> ogra_: I'll update the bug with some ideas once I've reverted.
<ogra_> snapcraft snap would likely also fall over on the /dev permissions
<ogra_> so it'd be more
<ogra_> cjwatson, can you keep the passwordless sudo in though ? ten i dont need to change core back :)
<ogra_> *then
<cjwatson> ogra_: sudo should be fine if it's already running as root.
<cjwatson> ogra_: I don't think you'll need to change core back.
<ogra_> oh, indeed, i call it as root
<mvo> pedronis: anything specially you want to see in 2.27, I would like to start of rc3 (mostly to avoid too much churn, we already have a ton)
<pedronis> mvo: no, IÂ misread some code, what I was interested in, is already there, sorry for the bother
<mvo> pedronis: no problem
 * Chipaca reads https://medium.com/@Raedwulf/6-go-tips-you-should-probably-not-use-b252dfd0a3c4 and laughs maniacally
<Chipaca> exhibit A: https://github.com/bouk/monkey
<Son_Goku> morning
<didrocks> Chipaca: excellent! :)
 * didrocks goes and rewrite code right away
<zyga-ubuntu> ooops
<zyga-ubuntu> niemeyer: start without me please
<zyga-ubuntu> niemeyer: I'm still stuck in the library :/
<zyga-ubuntu> lost track of time
<zyga-ubuntu> niemeyer: my update for today is: pushed inital work towards layouts that moves late initialization to snap-update-ns
<zyga-ubuntu> niemeyer: pushed some cleanups to interfaces
<zyga-ubuntu> niemeyer: plan for the day: re-assemble my fedora box and fix fedora i386 build back home
<zyga-ubuntu> niemeyer: and eat something
 * zyga-ubuntu is still starving
<zyga-ubuntu> niemeyer: next up: chipaca
<zyga-ubuntu> :D
<Son_Goku> you're going to eat Chipaca?
<Son_Goku> what did he ever do to you?
<zyga-ubuntu> with all due respect I think Chipaca doesn't work as a sushi
<niemeyer> zyga-ubuntu: Can you leave fedora to cachio, so you can focus on layouts and open PRs?
<zyga-ubuntu> niemeyer: I'll try that #define _FILE_OFFSET_BITS 64 and if that doesn't work I'll give that to cachio
<niemeyer> zyga-ubuntu: +1
<zyga-ubuntu> Son_Goku: https://fedoraproject.org/wiki/Changes/Platform_Python_Stack is pretty interesting
 * Son_Goku reads
<Son_Goku> oh boy
<Son_Goku> the issue I see right up front is how do we handle upgrading the platform python stack?
<Son_Goku> the reason we can do it without breaking the world in Python is because all the paths are versioned, including the interpreter itself
<zyga-ubuntu> Son_Goku: it seems like "in one big swoop during offline update" is the answer
<zyga-ubuntu> Son_Goku: and one big swoop says that *all* the packages follow
<Son_Goku> yeah
<zyga-ubuntu> Son_Goku: another answer is, not to
<Son_Goku> right, but that's dumb
<zyga-ubuntu> Son_Goku: as the platfrom python can say on 3.6 for decades
<zyga-ubuntu> Son_Goku: yes but it is also valid
<cjwatson> ogra_: https://portal.admin.canonical.com/104572 FYI
<Son_Goku> from a maint point of view, especially since sensitive tools would depend on it, it'd be very stupid
<zyga-ubuntu> s/decates/across Fx -> F(x+1) updates
<zyga-ubuntu> Son_Goku: well, it can stay on patched 3.6 for a long time with no issues
<Son_Goku> sure
<zyga-ubuntu> Son_Goku: backport any relevant patches but otherwise leave it be
<Son_Goku> yes, but at that point, why not just use micropython or something else actively maintained but fixed to specific lang version?
<zyga-ubuntu> Son_Goku: what it says is that new fedora and old fedora can share tooling easily (ish))
<Son_Goku> sure
<ppisati> ogra_: got it, ta
<zyga-ubuntu> Son_Goku: not sure if this is designed so that F27 can download F28 update tool
<Son_Goku> and that's what I'm concerned about
<Son_Goku> I'm not sure that is particularly addressed
<zyga-ubuntu> Son_Goku: but anyway, I found it interesting because traditionally it was not the case on any linux-based platfomr
<zyga-ubuntu> Son_Goku: *platfomr
<zyga-ubuntu> boy
<zyga-ubuntu> *platform
<zyga-ubuntu> Son_Goku: but it is the case on macos
<pedronis> niemeyer: as IÂ mentioned, it would be good to get some initial feedback on snapd#3573 , seems it was also a topic last week
<mup> PR snapd#3573: overlord: always try to get a serial, be lazy on classic with no special store, nor any snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/3573>
<Son_Goku> zyga-ubuntu, yes, historically it's that way on macos, but when mac bumps the stack, applications get broken
<Son_Goku> Apple literally does not care
<zyga-ubuntu> Son_Goku: indeed
<zyga-ubuntu> Son_Goku: though AFAIR the upstream python installers for mac are installing a separate copy
<Son_Goku> yes
<Son_Goku> but most people don't do that
<zyga-ubuntu> Son_Goku: I'll look forward to platform-{shell,perl,awk,sed,...} next ;)
<Son_Goku> that would be dumb
<zyga-ubuntu> well
<Son_Goku> we'll probably have a platform perl
<zyga-ubuntu> more or just the same?
<Son_Goku> but shell/awk/sed etc are already specified as part of the core platform
<Son_Goku> zyga-ubuntu: https://github.com/fedora-modularity/hp
<mvo> niemeyer: we talked about the "empty" base snap - is the name "empty-base" good? or would you prefer something else? I want to upload one to the store now for easier testing/validation
<niemeyer> mvo: Hmm
<niemeyer> mvo: How about "bare"?
<zyga-ubuntu> mvo: note that we're not quite ready to work in an empty base, unless empty actually has stuff inside :)
<mvo> zyga-ubuntu: well, I want to have it so that we can make it ready :)
<mvo> niemeyer: bare works for me
<zyga-ubuntu> mvo: understood
<niemeyer> mvo: It might not end up completely empty in the end.. we might want at least the mount points for /dev, /proc, /sys, ...
<zyga-ubuntu> right
<zyga-ubuntu> with a few of those it should soon work OK
<zyga-ubuntu> I need to introduce a few more small changes to make certain things non-fatal
<mvo> ok, "bare" it is and I created a bunch of stub dirs, lets see how this goes
<Chipaca> mvo: aw, am i too late to suggest calling it "classic-core"?
<zyga-ubuntu> Chipaca: uncore ;)
 * zyga-ubuntu cannot wait for busybox core 
<zyga-ubuntu> in fact, I may just make one
<ogra_> cjwatson, hmm, looks like the revert only landed in amd64, the other arches still have the former code
<zyga-ubuntu> it would be cool if we could have a base snap where if stuff fails we can go to "emergency" mode and just drop into a busybox rootfs
<ogra_> zyga-ubuntu, doesnt sound very secure though :)
<ogra_> (trigger a failure and you get root shell access)
<zyga-ubuntu> ogra_: I'm sure there's a way to make it sanely there (for development needs)
<zyga-ubuntu> ogra_: I agre having it in production is probably unnecessary
<ogra_> yeah, a toggle to turn it on/off manually would be good (defaulting to off)
<cjwatson> ogra_: It takes time
<ogra_> ah, k, i forgot  ... always working with snaps pretty much spolied me ;)
 * zyga-ubuntu goes to eat breakfast
<cjwatson> ogra_: it's not about debs, it's that the image update job is a periodic thing and there's one per arch
<cjwatson> (ish)
<ogra_> ah
<ogra_> i thought it was promotion
<ogra_> s/promotion/publishing/
<jdstrand> mvo: hey, is 'type: base' now a thing? ie, should I update the review tools?
<mvo> jdstrand: I think so, well, it should still emit a warning, i.e. we don't want to allow bases in without review
<mvo> jdstrand: if you could approve my busybox-static-mvo, that would be great. that is a snap with only the "bare" (empty) base
<jdstrand> mvo: sure, I can take care of all that, just wanted to make sure that the yaml is finalized
<jdstrand> mvo: so there is 'empty-base' and 'bare' and your 'busybox-static-mvo'
<jdstrand> mvo: ?
<mvo> jdstrand: empty-base can be removed. bare and busybox-static-mvo I would love to have
<jdstrand> mvo: ok
<jdstrand> mvo: 'base: foo'. foo must be a string?
<mvo> jdstrand: yes
<jdstrand> k
<jdstrand> mvo: fyi, I approved busybox-static-mvo. bare was already approved. updating the review tools now
<jdstrand> mvo: is 'base: foo' valid only for 'type: app'?
<mvo> jdstrand: so far yes
<zyga-ubuntu> o/
<zyga-ubuntu> what's up guys
<zyga-ubuntu> tests hate me today
<zyga-ubuntu> econnreset
<zyga-ubuntu> classic-ubuntu-core-transition-auth
<zyga-ubuntu> and more ...
<zyga-ubuntu> is it just me?
<mvo> zyga-ubuntu: no, seems master is equally unhappy
<zyga-ubuntu> but there is hope
<zyga-ubuntu> I found my breakfast
<niemeyer> zyga-ubuntu: Sent an update on the interfaces PR
<zyga-ubuntu> niemeyer: thank you!
<niemeyer> zyga-ubuntu: A bit long, but tried to provide concrete ideas that should unblock it
<niemeyer> zyga-ubuntu: I'll step out for lunch.. please let me know how you feel about them later so we can be in sync
<zyga-ubuntu> niemeyer: fantastic feedback, thank you!
<zyga-ubuntu> niemeyer: I'm still reading but I think it's all appropriate and good; thank you for taking care about the big picture in the code :)
<niemeyer> zyga-ubuntu: Sweet, glad you like it!
<zyga-ubuntu> jdstrand: FYI https://github.com/snapcore/snapd/pull/3621
<mup> PR snapd#3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
<zyga-ubuntu> jdstrand: some very early code there
<zyga-ubuntu> jdstrand: particularly one doing Ux
<zyga-ubuntu> jdstrand: I'm going to look at what would it take to move more of the startup logic to snap-update-ns
<zyga-ubuntu> jdstrand: and how we can do per-snap layout confinement profiles (just made that term up)
<zyga-ubuntu> jdstrand: as for the actual profile names, can I, say, use snap.foo.bar as the main apparmor profile and then do stuff like snap.foo.bar//layout as a sub-profile that applies to snap-update-ns?
<zyga-ubuntu> jdstrand: just syntax wise
<zyga-ubuntu> jdstrand: or do I need to encode that in some other way
<zyga-ubuntu> jdstrand: in each case snap-update-ns will run after pivot_root (I think pivot_root cannot move to goland easily)
<stgraber> mvo: https://github.com/lxc/lxd-pkg-snap
<zyga-ubuntu> jdstrand: anyway, I'm off
<zyga-ubuntu> jdstrand: lets sync later
<Chipaca> niemeyer: let me know when you have 15' to go over stuff?
<Chipaca> wtf, why is _everything_ breaking in spread :-(
<Chipaca> oh
<Chipaca> FTR, the store had a fairly bad hiccup ~1h ago
<Chipaca> so that's why
<niemeyer> Chipaca: Back just now
<pedronis> Chipaca: yes, being fixed since
<Chipaca> niemeyer: so, working from the commandline in, "snap status" as it stands in the PR is OK, yes?
<niemeyer> Chipaca: Double checking
<Chipaca> niemeyer: thank you
<niemeyer> Chipaca: The output sounds sane.. I'm just wondering a bit about the command name itself
<niemeyer> Chipaca: I wonder if it feels too much like "snap status" would result in what we have as "snap list"
<niemeyer> Chipaca: (the status of snaps in the system)
<niemeyer> Chipaca: WDYT?
<Chipaca> niemeyer: a little bit, yes
<Chipaca> niemeyer: OTOH we decided against "snap service status" AFAIK
<Chipaca> niemeyer: and if "snap status" feels like this, I reckon so will "snap restart"
<niemeyer> Chipaca: Indeed, and we have the same sort of ambiguity on enable/disable
<niemeyer> Chipaca: I guess status is fine from that angle, and the analogy of systemctl is definitely a plus
<niemeyer> Chipaca: Were you thinking about something specific when you asked?
<Chipaca> niemeyer: no, just walking over the changes i need to make to be sure
<Chipaca> layer by layer i mean
<niemeyer> Chipaca: I think we're good on that one.. I do wonder how we'll represent timers when they come
<niemeyer> Chipaca: Sounds like it'd make some sense to have them there..
<Chipaca> niemeyer: I don't understand your concern there, but that might be because I don't know what timers are for snapd
<Chipaca> I know what they are in systemd
<niemeyer> Chipaca: I think that's exactly my concern :)
<niemeyer> Chipaca: (the fact we don't have a clear view, which might lead to awkward corners soon)
<pedronis> well people asked to have systemd(-like) timers supported for snaps
<jdstrand> roadmr: hi! can you pull r891 of the review tools? it isn't super-urgent
<roadmr> jdstrand: sure!
<Chipaca> niemeyer: timers can be active and enabled too, fwiw
<jdstrand> mvo: ^ that has the base snap stuff and an override to allow 'bare' to pass automated review
<niemeyer> Chipaca: Right, that sounds sane
<niemeyer> and may be stopped/etc
<Chipaca> niemeyer: anyway, going one step further in, we'd have an Apps method on clients, that takes a list of things, and an options struct
<niemeyer> Chipaca: Yeah, singular I think
<cjwatson> ogra_: Any new snap build will start with a version of launchpad-buildd without that bug now.
<niemeyer> AppOptions?
<Chipaca> niemeyer: singular...?
<ogra_> cjwatson, ok
<niemeyer> I think that's what we do on other cases.. double checking
<Chipaca> niemeyer: and, here i'm not so sure: the options struct has an All bool, which if false means just services?
<niemeyer> Argh.. we have ChangesOptions.. we should really fix that one :(
<Chipaca> why?
<Chipaca> it's <method name>Options
<niemeyer> Yeah, maybe
<Chipaca> especially given that we used to have Change and Changes, ChangesOptions and ChangeOptions are clearly different beasts
<niemeyer> Yeah, that's actually the issue
<niemeyer> Often those option methods are useful in the context of a single thing
<niemeyer> Let me try to find an example
<niemeyer> func (client *Client) Install(name string, options *SnapOptions) (changeID string, err error) {
<niemeyer> vs.
<niemeyer> func (client *Client) InstallMany(names []string, options *SnapOptions) (changeID string, err error) {
<niemeyer> The options are snap-related, the thing, rather than method-specific
<niemeyer> thus ChangeOptions, AppOptions, etc
<niemeyer> Similarly, although we have ChangesOptions, we call it ChangeSelector in one of its fields
<niemeyer> With that background, yeah, indeed I'd suggest going with the singular, and eventually fixing ChangesOptions to agree
<Chipaca> So Apps([]string, AppOptions)?
<niemeyer> Yeah
<Chipaca> ok
<Chipaca> niemeyer: and would the options struct has an All bool, which if false means just services?
<niemeyer> Chipaca: The opposite case feels more natural: return all by default as it's an /apps endpoint, and allow constraining to services by providing {Service: true}
<Chipaca> ok
<niemeyer> Chipaca: That opens the door for us to have a special kind of service which is hidden as well
<Chipaca> niemeyer: and that translates to select="", "all", and "services" (with the two first ones being synonymous)
<niemeyer> Chipaca: and which we uncloak via a future All field
<niemeyer> Chipaca: Similar to what we do with snaps
<Chipaca> ah, so no select=all as synonymous for =""
<Chipaca> niemeyer: ok so far?
<niemeyer> Chipaca: Yeah, I'd keep just "" and "service" (again singular due to precedence in /v2/snap's refresh)
<niemeyer> s/refresh/select
<niemeyer> Chipaca: For that latter use case, perhaps just "" and "service"
<niemeyer> Chipaca: Again singular (precedence in /v2/snaps's select
<niemeyer> Thanks irccloud
<Chipaca> niemeyer: precedent, not precedence, i assume
<niemeyer> It told me it couldn't send my messages, and then did it later
<Chipaca> ok
<Chipaca> but note that snaps uses adjectives
<Chipaca> bah, not even
<Chipaca> in snap's select it's "refresh" or "private"
<Chipaca> uhm
<Chipaca> sorry, that's in find
<niemeyer> Chipaca: Sort of.. I think it's a similar use case.. "the snap is a refresh.. the snap is private.. the app is a service"
<Chipaca> in snap it's "all" or "enabled"
<niemeyer> Chipaca: Sorry, I was really thinking of find
<Chipaca> ok, singular
<Chipaca> niemeyer: then, inside daemon, there's the call to the helper that right now has a struct. I think I'll change that to mirror the client's options, for less surprises.
<niemeyer> Chipaca: Looking
<niemeyer> Chipaca: You mean the wantedAppInfo?
<Chipaca> yeap
<niemeyer> Chipaca: +1
<niemeyer> Chipaca: I'm tempted to suggest "snap services".. I've been dueling with myself for the past 30 minutes on it
<niemeyer> Chipaca: Part of the question is: are timers services as well?
<niemeyer> I suspect that as far as systemd is concerned, they are not
<Chipaca> niemeyer: they are distinct
<niemeyer> Chipaca: So will we have a {Timer: true} flag?
<Chipaca> niemeyer: although in systemd a timer is associated with a service of the same name
<niemeyer> /o\
<Chipaca> niemeyer: that is, the timer is _just_ a timer
<Chipaca> niemeyer: when it fires, it runs the service with the same name
<pedronis> I doubt we would model it that way though
<Chipaca> correct
<Chipaca> niemeyer: (you can change which unit it fires, but the default is the one with the same name)
<niemeyer> I guess the app would be a timer _and_ a service then?
<Chipaca> niemeyer: an app would be â¦ Daemon: timer ?
<Chipaca> probably not because the service will have its own daemon:
<Chipaca> niemeyer: a daemon can have a timer?
<niemeyer> Chipaca: I was thinking of just having something like Schedule: <timing spec>
<niemeyer> Chipaca: Or simliar
<Chipaca> yup
<Chipaca> so a service would have a timer / schedule / thing
<Chipaca> makes sense to me
<niemeyer> Chipaca: We might imply "Daemon: timer" in that case perhaps?
<Chipaca> niemeyer: no because the service can be one-shot or notify or â¦
<niemeyer> Chipaca: Or would it make sense for something to be a daemon *and* a timer?
<niemeyer> Chipaca: Ah, okay, combined even in that sense.. nice
<Chipaca> niemeyer: man systemd.timer fwiw
<Chipaca> niemeyer: also
<niemeyer> Chipaca: Yeah, I'm friends with that one.. have been trying to find a good syntax for ourselves
<Chipaca> niemeyer: systemctl list-timers
<niemeyer> Chipaca: Thanks, hadn't seen that one
<Chipaca> niemeyer: and i'd expect we'd want something similar, maybe under 'snap timers'
<Chipaca> but, dunno
<niemeyer> Chipaca, pedronis: Okay, so, what's the experience we want? Do we show timers on "snap status/services" output?
<Chipaca> because, dunno what timers are for snap :-D
<niemeyer> Chipaca: +1 on "snap timers"
<Chipaca> niemeyer: if a service has a schedule, maybe include a "last run" or "next run" column?
<Chipaca> niemeyer: or a "see snap timers"?
<Chipaca> i mean
<Chipaca> no, i wouldn't show timers as lines in 'snap status' output
<Chipaca> I'd show the services the timers fire, though
<niemeyer> Chipaca: Or perhaps just "Schedule", with the actual string, and leave the specialized output for "snap timers"
<Chipaca> niemeyer: that sounds reasonable
<niemeyer> Chipaca: Okay, thanks, that gives much better understanding of what's to come.. so back to your original question:
<niemeyer> Chipaca: I think the output is mostly fine.. a couple of points to ponder about:
<niemeyer> 1. Should we always have the first field?  That makes it more tooling-friendly (think awk, grep, ...)
<niemeyer> 2. Would it be useful to have Daemon with the value of that field?
<niemeyer> 3. I'm slightly conflicted about the name of the "Service" header.. not sure if "App" would make it more clear or more confusing
<Chipaca> 1. i think yes, although i'm not sure it makes sense for it to be split
<Chipaca> 2. i don't think Daemon tells the user of the app anything they need to know, no
<Chipaca> 3. i think Service is a little clearer than App, but not by a wide margin
<niemeyer> Okay.. for 1, should we just have it always then?
<niemeyer> For 2, sounds good
<Chipaca> 1., yes i think so
<niemeyer> 3. Okay
<niemeyer> Chipaca: Sounds like we have a plan then!
<Chipaca> niemeyer: one last question: about the split of AppInfo and ServiceInfo in the client libs. It's mainly driven by the desire for the json to be nice and clean for non-service apps, and nice and explicit for service apps
<niemeyer> Chipaca: I understand, but I also see value in the conceptual flattening.. we've already decided to make them look alike long ago, and it earned us many bonus points in terms of having plugs/etc handling not care, being able to have commands and services, etc
<niemeyer> Chipaca: I think this is just being more honest about that internal representation, and passing the advantage of that flattening on to the client
<niemeyer> Chipaca: It's analogous to systemd's "units", if you see what I mean
<niemeyer> I'm sure somebody complained about "starting a mount point", but hey, the flat CLI is nice
<Chipaca> hmm
<Chipaca> niemeyer: in systemd, status of a unit (that is, the common ancestor of services, mountpoints, timers, ...) makes sense
<Chipaca> niemeyer: whereas our apps are very distinct beasts
<Chipaca> but, i'll flatten it
<Chipaca> no worries
<niemeyer> Chipaca: Not really.. we do have a bunch of common ground for apps
<niemeyer> Chipaca: plugs and slots, security profiles, etc etc
<niemeyer> Chipaca: Thanks!
<niemeyer> Chipaca: Ah, and I suggest going with "snap services", given all of that useful background
<Chipaca> ok
<Chipaca> but not right now. Right now, time to walk the dog, and think of dinner, and maybe a beer
<Chipaca> o/
<niemeyer> Chipaca: Sounds great, thanks for the chat.. I'll copy that conversation into the forum
<Chipaca> tks
<Chipaca> that's another thing that's harder to do in a hangout :-D
<pedronis> niemeyer: did you get a chance to look at that branch? do you want to do a quick HOÂ instead?
<niemeyer> pedronis: I didn't manage to look yet, sorry, but it's definitely on my queue of things for today.. a HO might help
<mup> PR snapcraft#1418 opened: nodejs plugin: fix incorrect symlinks <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1418>
<pedronis> niemeyer: let me know I'm available for another couple of hours
<niemeyer> pedronis: Sounds good.. give me ~10 mins and I'll be with you
<pedronis> ok
<niemeyer> pedronis: Heading to the standup HO
<mvo> jdstrand: thank you! :)
<jdstrand> mvo: the strace?
#snappy 2017-07-26
<mup> PR snapd#3622 opened: tests: enable regression, upgrade and completion test suites for fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3622>
<zyga-ubuntu> good morning
 * zyga-ubuntu actually had brakfast today and starts hacking
<zyga-ubuntu> mvo: do you want to sync about the debian situation?
<mvo> zyga-ubuntu: in some minutes, hacking on base snaps
<zyga-ubuntu> okay
<mup> PR snapd#3620 closed: interfaces/builtin: discard empty Validate{Plug,Slot} <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3620>
 * zyga-ubuntu is puzzled
<zyga-ubuntu> single test doesn't fail, lets run the suite
<mup> PR snapcraft#1419 opened: add "base" to the snapcraft.yaml schema <Created by mvo5> <https://github.com/snapcore/snapcraft/pull/1419>
<ogra_> fgimenez, do our spread tests accept TMPDIR ? (see https://forum.snapcraft.io/t/how-to-use-spread-to-test-ubuntucore-image/1323 )
<fgimenez> ogra_: looking
<morphis> zyga-ubuntu: ping
<zyga-ubuntu> morphis: hey
<morphis> zyga-ubuntu: the changed way of describing interfaces in the snapd code, is that documented somewhere?
<zyga-ubuntu> morphis: changed as in how?
<morphis> bringing https://github.com/snapcore/snapd/pull/3615 into shape for kyle right now
<mup> PR snapd#3615: add broadcom-asic-control interface <Created by knitzsche> <https://github.com/snapcore/snapd/pull/3615>
<zyga-ubuntu> morphis: but I think it's not described in many places
<morphis> zyga-ubuntu: "Description is now out. Please open a thread on the forum, document the interface there and add a documentation link (I will try to land the related branch today so that you can do this)." is what you said
 * zyga-ubuntu looks
<morphis> I didn't saw this changed for any of the other interfaces yet
<zyga-ubuntu> morphis: ah, I see
<zyga-ubuntu> morphis: this is 3399
<zyga-ubuntu> morphis: which will hopefully land later today
<zyga-ubuntu> morphis: not much changes, just DocumentationURL -> DocURL and Description -> out
<ogra_> WOHOO !!!
<ogra_> the latest nplan fixed the wlan issues on pi3
<ogra_> \o/
<morphis> ogra_: nice :-)
 * ogra_ just set up a pi3 without any wired network 
<mup> Bug #1632387 changed: console-conf wifi only setup on pi3 beta3 image not possible <Snappy:Confirmed> <subiquity (Ubuntu):Confirmed> <https://launchpad.net/bugs/1632387>
<zyga-ubuntu> ogra_: did wifi work on first boot?
<zyga-ubuntu> ogra_: wow :)
<zyga-ubuntu> ogra_: what was the issue?
<mup> PR snapd#3623 opened: interfaces/builtin: implement broadcom-asic-control interface <Created by morphis> <https://github.com/snapcore/snapd/pull/3623>
<ogra_> zyga-ubuntu, netplan had a unbind/bind cycle hardcoded for all drivers
<ogra_> zyga-ubuntu, which the broadcom driver of the Pi doesnt suopport
<zyga-ubuntu> ah, I see
<zyga-ubuntu> interesting, I never worked with driver binding/unbinding before
<ogra_> https://forum.snapcraft.io/t/failing-raspberry-pi-3-config-wlan-disappears/1023/6 has all info
<mvo> does anyone know if there is a way to force snapcraft to *not* create a wrapper script?
<mvo> for the things in my apps: section
 * ogra_ doesnt think there is 
<zyga-ubuntu> mvo: AFAIK, no
<mup> PR snapd#3545 closed: many: support querying and completing assertion type names <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3545>
<mup> PR snapd#3611 closed: overlord/snapstate/backend: some copydata improvements <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3611>
<Chipaca> pedronis: niemeyer: snapd#3614 is ready for another look i think (spread failed so i'm re-running it, but errors were not related to the pr)
<mup> PR snapd#3614: daemon, client, cmd/snap: implement "snap services" <Created by chipaca> <https://github.com/snapcore/snapd/pull/3614>
<pedronis> Chipaca: thanks, I'm having lunch break and then I have an errands, but will look later in the afternoon
<Chipaca> np
<Chipaca> i'm about to break to see if i can't have my lunch run during a break in the rain
<mup> PR snapcraft#1420 opened: add new "no-wrapper" property to apps <Created by mvo5> <https://github.com/snapcore/snapcraft/pull/1420>
<zyga-ubuntu> mvo: wow, nice
<zyga-ubuntu> mvo: suggestion added as comment
<zyga-ubuntu> mvo: woot, 3621 is green :)
<zyga-ubuntu> mvo: I forgot to commit :'D
<zyga-ubuntu> mvo: this means I can pursue this idea further and do what we discussed on the call earlier today
<mup> PR snapd#3624 opened: rework for avahi interface <Created by kubiko> <https://github.com/snapcore/snapd/pull/3624>
<zyga-ubuntu> mvo, Chipaca: can I land https://github.com/snapcore/snapd/pull/3619 please?
<mup> PR snapd#3619: interfaces/builtin: reduce duplication and remove cruft in Sanitize{Plug,Slot} <Created by zyga> <https://github.com/snapcore/snapd/pull/3619>
<zyga-ubuntu> there are new interfaces coming up and I wanted to make sure they can benefit
<zyga-ubuntu> Chipaca: I need some advice
<Chipaca> zyga-ubuntu: delete facebook, hit the gym, lawyer up?
<zyga-ubuntu> Chipaca: can you have a look at https://github.com/snapcore/snapd/pull/3399#discussion_r129296043
<mup> PR snapd#3399: many: add the interface command <Created by zyga> <https://github.com/snapcore/snapd/pull/3399>
<zyga-ubuntu> haha, nice :)
<zyga-ubuntu> lawyer up?
<zyga-ubuntu> what does that mean?
<Chipaca> zyga-ubuntu: contact, and possibly retain, a lawyer
<mvo> zyga-ubuntu: 3619 has my review already, just needs a second one
<zyga-ubuntu> Chipaca: aha
<Chipaca> zyga-ubuntu: what's your question?
<zyga-ubuntu> mvo: thanks, I'll rally some help then ... (looks at Chipaca)
<zyga-ubuntu> Chipaca: so say I "snap list barf", that doesn't return 404 or anything similar but instead does client side translation from len(results) == 0 to a dedicated error
<zyga-ubuntu> Chipaca: I used the same approach for snap interface
<zyga-ubuntu> Chipaca: now the question is, should both change to server side error?
<Chipaca> zyga-ubuntu: the behaviour of 'snap list' probably needs revisiting; the logic has grown organically for a while with no active pruning
<Chipaca> zyga-ubuntu: it used to be that all filtering of snap list was client-side
<Chipaca> zyga-ubuntu: then a minimal change was added to move the filtering to the server
<Chipaca> zyga-ubuntu: but the error logic was probably left alone
<zyga-ubuntu> right
<zyga-ubuntu> I'm after a common front, we can change the code once we agree on how
<Chipaca> ok
<niemeyer> Mornings o/
<Chipaca> zyga-ubuntu: sounds good
<Chipaca> zyga-ubuntu: for snap list, it is not an error to say "snap list" and have it return nothing (it prints a message, but isn't an error)
<Chipaca> zyga-ubuntu: for snap list, it is an error to say "snap list foo" if foo is not installed
<Chipaca> zyga-ubuntu: for snap list, it is _not_ an error to say "snap list foo bar" if foo is not installed but bar is
<zyga-ubuntu> Chipaca: how would the results be conveyed?
<zyga-ubuntu> Chipaca: and why is the last thing different from the 2nd thing?
<zyga-ubuntu> Chipaca: I was thinking about an xml-rpc like multi-call request, (one request packing many requests and returning many responses)
<zyga-ubuntu> Chipaca: so that individual query elements can fail
<Chipaca> zyga-ubuntu: how do you tell bash that
<Chipaca> "snap list" takes the approach that if at least one succeeds, the op succeeded
<Chipaca> my question is whether that is appropriate for the other thing you're wanting to generalise it to
<zyga-ubuntu> Chipaca: well, bash can just fail with "error code 1"
<zyga-ubuntu> Chipaca: bash isn't a problem here, I think
<zyga-ubuntu> Chipaca: and we can either fail or succeed
<zyga-ubuntu> Chipaca: depending on the context
<zyga-ubuntu> Chipaca: but we need to know we did fail in the first place
<zyga-ubuntu> Chipaca: I think we need to get the wire format right first
<Chipaca> zyga-ubuntu: what's the advantage for the user?
<zyga-ubuntu> Chipaca: user advantage is can be defined later, right now I think we are still stuck at the request/response layer
<Chipaca> zyga-ubuntu: you're starting from the wrong place then :-)
<zyga-ubuntu> Chipaca: well, not sure, at the moment we cannot even convey this to the user because we have no data to say so
<niemeyer> Chipaca: I think it's awkward that "snap list foo bar" doesn't error if one of these is missing.. feels like a bug
<niemeyer> Chipaca: I don't think the wire format is involved in any of this
<niemeyer> Sorry, that was actually for zyga
<niemeyer> The user interface is what creates expectation.. depending on what is being done, the expectation is broken and becomes a bug
<zyga-ubuntu> niemeyer: by wire format I was referring to being able to encode this, right now I'm not sure if we should use status codes or what
<niemeyer> The API under it can work in many different ways
<niemeyer> zyga-ubuntu: We don't want to send bash status codes in the API.. makes no sense
<zyga-ubuntu> niemeyer: I wasn't talking about bash status codes
<zyga-ubuntu> niemeyer: just the fact that "snap list foo bar" didn't know about "bar" but found "foo"
<niemeyer> zyga-ubuntu: Well, which status codes are you talking about then? :)
<zyga-ubuntu> niemeyer: I was thinking about http status codes
<niemeyer> zyga-ubuntu: We use those fine I think
<Chipaca> niemeyer: it may well be, and if it is we can change it, but right now this is how it behaves -- changing it because it's a bug is fine, changing it because we want to change the wire format so we can change it is not
<zyga-ubuntu> niemeyer: should that give a 404, a 200 with some extra data or something entirely different/
<zyga-ubuntu> niemeyer: so far snap list doesn't 404 AFAIK
<niemeyer> Thankfully!!!
<niemeyer> One more for emphasis: !
<niemeyer> :P
 * Chipaca lends niemeyer a double â¼
<niemeyer> Thanks! :)
<Chipaca> maybe some bold ones as well ââ
 * Chipaca stops
<zyga-ubuntu> niemeyer: in any case, please have a look at 3399
<zyga-ubuntu> niemeyer: there is one outstanding point
<zyga-ubuntu> niemeyer: that is related to the discussion above
<zyga-ubuntu> niemeyer: and if you can, please +1 3619 as I want to fix some incoming interfaces
<pedronis> Chipaca: did another pass on your branch
<niemeyer> zyga-ubuntu: Some background: 404 generally means "nothing to see here" in HTTP protocols.. quite error prone to return it on a request that was processed and which has a richer response than simply "nothing to see here"
<niemeyer> zyga-ubuntu: In this specific case, the API returning one element out of two seems reasonable.. it's the user action of saying "list me those two" in a CLI that makes this an error
<Chipaca> pedronis: by "just check and transform the result" you mean "if it has â.â, call snap.SplitSnapApp, otherwise don't"?
<pedronis> Chipaca: no check if the two parts are equal, if they are return  one and ""
<Chipaca> pedronis: so if the user says "foo.foo" they still get all the apps from foo?
<Chipaca> :-/
<niemeyer> zyga-ubuntu: I think I just responded to that point?
<pedronis> Chipaca: well as I said I'm not happy with tha ambiguity
<Chipaca> pedronis: these are services, not â¦ not-services, so the "foo means foo.foo" doesn't apply
<pedronis> let me think
 * Chipaca steps back from the thinking pedronis 
<zyga-ubuntu> niemeyer: so if we ask about one interface and it is not there the server should then give us some kind of 404-ish error?
<pedronis> Chipaca: ok,  yes, I think you need to check if '.' is the thing then
<niemeyer> zyga-ubuntu: How does "snap list" report that today?
<pedronis> anyway it's a nitpick
<zyga-ubuntu> niemeyer: it translates that in the client
<niemeyer> zyga-ubuntu: How does it report?
<zyga-ubuntu> niemeyer: with identical if len==0 check
<zyga-ubuntu> niemeyer: zyga@fyke:~/go/src/github.com/snapcore/snapd$ snap list nothingtoseehere
<zyga-ubuntu> error: no matching snaps installed
<niemeyer> zyga-ubuntu: Sorry, for extra clarity: your question is about what the server does.. I'm driving an analogy with snap list, and asking how the server reacts to those requests
<niemeyer> zyga-ubuntu: We don't want these APIs side-by-side with diverging behaviors
<zyga-ubuntu> niemeyer: to the best of my knowledge snap inteface and snap list behave the same way server side, unknown things are skipped silently
<Chipaca> niemeyer: "list" does not error on returning empty
<Chipaca> niemeyer: /v2/snaps i mean
<Chipaca> niemeyer: does not consider returning an empty list to be a 404
<zyga-ubuntu> you just get an empty result container
<niemeyer> Chipaca: Great, thanks
<niemeyer> zyga-ubuntu: So that's what we want for interfaces too, on the server side
<zyga-ubuntu> niemeyer: that's exactly what happens now
<niemeyer> zyga-ubuntu: On the client side, a person asking to list something non-existing is generally an error
<Chipaca> we could change it so that, if "snaps" is specified to /v2/snaps, then it 404s if empty
<zyga-ubuntu> niemeyer: we just return an empty list and the client checks that
<Chipaca> but, for snaps, it's never a 404 for the result to be empty if "snaps" is not given
<niemeyer> Chipaca: It seems fine as it is.. as long as the behavior is consistent.. it's generally also easier to handle and less error prone per reasons above
<Chipaca> that is, an empty collection is not a not-found
<zyga-ubuntu> niemeyer: so from my POV, it's consistent and no further change is needed there
 * zyga-ubuntu would love to land that PR :-)
<Chipaca> but also note that /v2/snaps/foo will happily 404
<niemeyer> zyga-ubuntu: Ok.. so about the client: the CLI needs to error when an interface requested by the user is not found
<niemeyer> zyga-ubuntu: It can even list the first one, but it should error at the end pointing out the missing interface
<zyga-ubuntu> niemeyer: I think it does as well, the client checks if we got an empty response and returns an error
<zyga-ubuntu> aha
<zyga-ubuntu> niemeyer: note that we can only ask about one interface toaday
<zyga-ubuntu> niemeyer: so we do that
<zyga-ubuntu> niemeyer: you either see what you asked for or you get an error
<niemeyer> zyga-ubuntu: Okay, LGTM then
<zyga-ubuntu> \o/ woot :)
<niemeyer> and we need to fix snap list later to correct that behavior
<zyga-ubuntu> niemeyer: I'll just point out that you cannot ask about many interfaces and if you want that, I can happily change that
<niemeyer> zyga-ubuntu: On this specific point.. the rest of the review still applies obviously :)
<zyga-ubuntu> niemeyer: so there's more parity on list and interface
<niemeyer> zyga-ubuntu: Hmm
<zyga-ubuntu> niemeyer: I think the rest of the review is fully addressed
<zyga-ubuntu> niemeyer: if you don't ask about a specific interfaces you get the listing
<Chipaca> is it OK that the client is now calling them connections, even though the endpoint is interfaces?
<zyga-ubuntu> niemeyer: if you ask about a specific, you get it or you get an error saying it's not there
<Chipaca> or should it be /v2/connections?
<niemeyer> zyga-ubuntu: Yeah, I'd expect an API close to what we have with snaps
<zyga-ubuntu> Chipaca: that's a thing we want to untangle but we didn't want to break compatibility
<zyga-ubuntu> niemeyer: note that on the API layer you can ask for many
 * Chipaca shuts up and puts the bikeshed inside the shed and puts a padlock on the shed and burns down the whole house with the shed inside it
<zyga-ubuntu> niemeyer: it's just the command line tool asks for one
<niemeyer> Chipaca: It's the opposite unfortunately
<niemeyer> zyga-ubuntu: Ah, that's fine
<niemeyer> zyga-ubuntu: Easy to improve the CLI later
<niemeyer> zyga-ubuntu: Was mainly worried about the API
<niemeyer> Chipaca: The /v2/interfaces we have *today* is more like a "/v2/connections" thing
<niemeyer> Chipaca: So instead of creating a /v2/more-interfaces :), we introduced new behavior on /v2/interfaces in a compatible way, that makes it return something that looks more like an actual interface
<niemeyer> and we should really go back to the forum on those conversations.. all of that background will be trashed in a couple of hours
<pedronis> Chipaca: did you see my other comments, a table of bools doesn't seem very readable but maybe you discussed that already to death
 * zyga-ubuntu eats lunch quickly, see you at the call
<Chipaca> pedronis: no, we didn't discuss that aspect of it
<pedronis> Chipaca: also to be active it needs to be enable, right?   and vice versa if it's not enabled it cannot be active
<Chipaca> pedronis: it can be active and not enabled, and enabled but not active
<pedronis> Chipaca: ah, if you do systemd stuff
<pedronis> directly
<pedronis> anyway I still don't know if a wall of true/false is great
<Chipaca> pedronis: "snap stop" does not disable
<Chipaca> pedronis: "snap start" does not enable
<niemeyer> pedronis: Indeed
<Chipaca> pedronis: so "snap stop --disable" -> service is inactive,disabled; "snap start" -> service is active,disabled
<Chipaca> pedronis: me neither
<Son_Goku> why are you doing that?
<Chipaca> but it does need to be lined up
<niemeyer> Maybe  active vs. -, and enabled vs. -, would be more visually appealing
<Chipaca> Son_Goku: what "that"'s that?
<Son_Goku> [08:57:00 AM]  <Chipaca>	pedronis: so "snap stop --disable" -> service is inactive,disabled; "snap start" -> service is active,disabled
<Chipaca> Son_Goku: as opposed to what?
 * Son_Goku shrugs
<pedronis> all our services are created enabled though?
<pedronis> right?
<pedronis> that's the initial state
<Son_Goku> I mean specifically service management through snap command
<Chipaca> pedronis: yes
<niemeyer> Son_Goku: https://forum.snapcraft.io/t/command-line-interface-to-manipulate-services/262
<Chipaca> Son_Goku: it's been requested multiple times, for convenience
<niemeyer> And this is where we should be having this conversation too.. :)
<niemeyer> (so we can link next time)
<Son_Goku> I'll have to trawl through that and give my feedback on the whole thing
<Son_Goku> so far, I don't know if this is a good idea
 * Son_Goku sighs
<Son_Goku> the forum is too hard to follow
<niemeyer> Son_Goku: IRC is even harder to follow.. all of the conversation above will be gone in 2h tops
<Son_Goku> yes, but because it's real-time-ish, I can just ask people :)
<niemeyer> Son_Goku: Yes, and people can repeat the same thing they tell you 20 times more, to every next person asking.. /o\
<Son_Goku> haha
<Son_Goku> I'm still waiting for desktop snaps to be unbroken: https://forum.snapcraft.io/t/integrate-snapd-xdg-open-into-snapd-repository/100
<Son_Goku> niemeyer: the issue with the forum is that I don't get emails of threads that I can jump into arbitrarily
<Son_Goku> only things that I've already commented on
<Son_Goku> so I barely know what the heck is going on
<zyga-ubuntu> Chipaca: standup please
<niemeyer> Son_Goku: You can subscribe to categories, topics, or even the whole forum
<Son_Goku> I can?
<Son_Goku> how?
<niemeyer> Son_Goku: "Mailing list mode" in your preferences
<Chipaca> zyga-ubuntu: omw!
<niemeyer> Son_Goku: Per category, going to the category and selecting your subscription option
<Son_Goku> so if I just set mailing list mode without doing anything else, it'll send me everything, right?
<niemeyer> Son_Goku: Yep!
<Son_Goku> niemeyer: done, thanks
<Son_Goku> hopefully now I'll be able to be kept in the loop more
<fgimenez> niemeyer: mvo i've just promoted 2.26.14 to stable
<zyga-ubuntu> woot
<mvo> fgimenez: excellent, thanks a lot
 * zyga-ubuntu small break before doing more stuff
<zyga-ubuntu> I need to put my fedora box on my desk
<zyga-ubuntu> I miss it :(
<mvo> zyga-ubuntu: if you have a rpm based system at hand, could you please touch a file like /usr/bin/vi and then rpm install vi and see if rpm just overwrite the file if it  is already there? that is what dpkg is doing and if rpm is doing the same we are good for the bash-completion idea we had the other day
<mup> PR snapd#3625 opened: many: end-to-end support for the bare base snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/3625>
<zyga-ubuntu> mvo: checking
<Son_Goku> mvo: if it's not a config file, then that behavior is valid
<Son_Goku> if it's a ghost or a real file tracked by rpm and already exists, you're toast
<mvo> Son_Goku: great, thats my undersanding as well
<mvo> understanding
<Son_Goku> note that a ghost file is one that is known to be tracked by rpm once something creates it
<Son_Goku> they don't necessarily care about *everything* about them
<zyga-suse_> mvo: although I will use emacs :)
<Son_Goku> but rpm does track them for the purposes of being able to remove them
 * zyga-suse curses at packagekit for being ugly and stupid 
<zyga-suse> and not wanting to shut down
<Son_Goku> if you're on suse, you can force pk to give up
<zyga-suse> I just tired because it gave me that option
<zyga-suse> it doesn't work
<Son_Goku> lovely :(
<zyga-suse> "must be busy"
<zyga-suse> no shit sherlock?
<ogra_> stop  giving it so much to do then
<ogra_> poor thing ...
<Son_Goku> haha
<zyga-suse> it would have been nicer if it didn't just run on resume
<Son_Goku> mvo: the only semantic that differs between dpkg and rpm on file handling is the concept of ghost files
<zyga-suse> ok, installing emacs
<Son_Goku> they don't exist in dpkg
<Son_Goku> I believe it treats those as a conflict as well
<zyga-suse> zypper says "checking for conflicts amongs files"
<zyga-suse> must be doing something
<Son_Goku> it's resolving @System.solv against your proposed transaction
<Son_Goku> mvo: since unless you do %config %ghost (which is dumb for a variety of reasons), a %ghost file is a real file to the rpmdb like anything else
<zyga-suse> Chipaca: offtopic,if I have a huge snap, will it resume a partiall download?
<zyga-suse> mvo: it works as in dpkg
<zyga-suse> I just installed emacs
<zyga-suse> now how do I quit ;-)(
<Son_Goku> zyga-suse: really?
<zyga-suse> (just kidding, I know how to quit, emacs was my first editor)
<Son_Goku> mvo: this is why I declared certain files in the fedora snapd spec as %ghost, so that they're owned by snapd and other things can't collide with it
<zyga-suse> Son_Goku: I touched /usr/bin/emacs
<zyga-suse> Son_Goku: then zypper installed emacs
<zyga-suse> Son_Goku: then confirmed the file was overwritten
<Son_Goku> yep
<Son_Goku> mvo: even though they're not created by the rpm, rpm "knows" something "owns" it, and won't let something else "different" take it over
<Chipaca> zyga-suse: if you have a huge snap, and as part of an install the connection gets interrupted and needs to be redone, yes it continues
<zyga-suse> Chipaca: awesome
<zyga-suse> Chipaca: at some point it would be cool to be able to pause downloads
<zyga-suse> Chipaca: so you could snap install that-huge-thing and pause it while needing the bandwidth
<Chipaca> zyga-suse: if you get 50% through a download and the network goes away so badly that the install actually aborts after retrying a few times, then no, the tempfile gets nuked
<zyga-suse> Chipaca: ah, I see; I think we will want to re-visit that over time
<zyga-suse> Chipaca: unless the user aborts I'd keep the file around and try until it works
<zyga-suse> (knowing that the snap exists and can be pulled)
<Chipaca> zyga-suse: you're proposing that we have a cache
<zyga-suse> not even a cache
<zyga-suse> if I download a 5GB snap
<Chipaca> zyga-suse: I'm just saying, that thing behaves like a cache
<zyga-suse> and it aborts because I'm offline for 5 minutes
<zyga-suse> and it downloads it again
<Chipaca> zyga-suse: meaning it's Hard
<zyga-suse> it's the (insert emoji that flips the table now)
<Chipaca> zyga-suse: https://github.com/dysfunc/ascii-emoji
<zyga-suse> Chipaca: again, not hard, not cache, just keep the file around for as long as the user doesn't abort
<Chipaca> zyga-suse: right
<zyga-suse> Chipaca: and also perhaps not /tmp but /var/tmp that's on /writable
<Chipaca> zyga-suse: the user didn't abort but the install failed
<zyga-suse> Chipaca: as 5GB snap is valid, even on devices with 512M memory
<Chipaca> zyga-suse: so it's a year later and you now have 87G of half-downloaded snaps
<Chipaca> zyga-suse: and you ran out of space
<zyga-suse> Chipaca: no other consumer system does that (steam, gog, appstore.{ios,android})
<zyga-suse> Chipaca: if I don't abort the download that's what I wanted
<zyga-suse> Chipaca: and I hope it will install them actually
<zyga-suse> Chipaca: *and* we might be able go just mv the file rather than use 2x space for a copy out of /tmp
<Chipaca> zyga-suse: do you understand how what you are describing is a cache, meaning it has all the problems of a cache that need addressing?
<Chipaca> zyga-suse: we don't download to tmp
<zyga-suse> Chipaca: I don't think it is a cache or that it has any problems. We should just not abort at all if network is bad but we got at least one byte and can keep re-trying.
<zyga-suse> Chipaca: but I assume to be ignorant about things you know better
<zyga-suse> Chipaca: ah, that's good. I was afraid we did (must be confusing with sideload)
<zyga-suse> Chipaca: cache is another thing (e.g. remove and reinstall)
<zyga-suse> Chipaca: but I'd argue that what I described is not a cache and is easier
<Chipaca> zyga-suse: maybe i misunderstood; you're saying we should keep retrying forever?
<zyga-suse> Chipaca: yes, and never unlink the file unless the user "snap aborts"
<zyga-suse> Chipaca: again, think of the behavior on huge snaps and non-ideal network conditions, or metered connections
<ogra_> cyphermox, hey, thanks for the bind/unbind fix in netplan (it fixed the pi3 core image) ... one thing that struck me is that vendors that will build core images from their own BSP might hit that same issue (i guess it is pretty common that platform devices in SoCs do not support unbind) ... do you think we could make the code read a config file with a list of drivers that vendors could simply extend ?
<ogra_> it would avoid that they have to wait for another netplan fix to land
<cyphermox> ogra_: that's a good idea, can you please file a bug for it?
<ogra_> will do
<ogra_> cyphermox, bug 1706680 for you
<mup> Bug #1706680: add config file to list drivers that do not support unbind <nplan (Ubuntu):New> <https://launchpad.net/bugs/1706680>
<sergiusens> tyhicks , jdstrand hey there, is there an interface which would allow lttng /dev nodes to be used?
<Chipaca> niemeyer: hah!
<Chipaca> niemeyer: I had most of a post to the services forum post written :-)
<niemeyer> Chipaca: Hopefully we even agreed unkowingly? :)
<niemeyer> Chipaca: Sorry, I've spent the last 25 minutes writing and deleting my own proposals.. :P
<Chipaca> niemeyer: maybe i should post it anyway and then we can play "spot the differences"
<jdstrand> sergiusens: not currently
<niemeyer> Sure, having more data won't hurt..
<Chipaca> niemeyer: there ya go
 * ogra_ definitely likes niemeyer's proosal better because there are bars in it (it carries the subconcious promise of beer in it)
<ogra_> *proposal
<sergiusens> jdstrand: thanks, given that lttng is specifc to lttng can we update snappy-debug ?
<Chipaca> ogra_ walks into a bar
<Chipaca> >clonk<
 * ogra_ grins
<Vamsi> Hi, I don't seem to find info on error reporting and handling for snaps. Does anyone know where I could read about it?
<Chipaca> Vamsi: could you expand on what you mean?
<Chipaca> Vamsi: hi :-)
<Vamsi> Chipaca: Hi
<Vamsi> Chipaca: In case a snap fails to start or is behaving incorrectly, how is this conveyed to the user?
<Chipaca> Vamsi: currently it is not
<Chipaca> Vamsi: assuming that by "a snap" you mean a service inside a snap
<ogra_> well, if you are lucky the developer added some info to the description ... which you can obtin with snap info
<Chipaca> if the service fails to start entirely then the snap _should_ fail to install (but it's harder to detect than it should be, so we don't always catch that)
<Chipaca> and the user can inspect the service status and its logs if things aren't working
<Chipaca> but snapd itself doesn't tell the user
 * ogra_ read the above as "where to report bugs about specific snaps" ... (perhaps i misunderstood)
<Chipaca> ah, if it is indeed where to report bugs, snap info tells you
<Chipaca> that's what the "contact" field is for
<Chipaca> but the question was 'how was this conveyed to the user', not 'how does the user convey this to the snap author'
<ogra_> yeah
<ogra_> thus my comment
<ogra_> (that i might have misunderstood)
<Chipaca> ogra_: too much walking into bars :-p
<ogra_> :P
<Chipaca> Vamsi: why do you ask?
<zyga-suse> Chipaca: snappy, flatpak and appimage walk into a bar
<ogra_> and snappy is the only one who has an interface to the barkeeper to order beers ;)
<Chipaca> zyga-suse: rox wonders what they did to not be invited
<zyga-suse> ogra_: flatpak needs a beer portal, one is coming in F28, appimage just grabs the beer and snappy needs an assertion for the beer to be connected
<ogra_> dang
<Vamsi> Chipaca: I was read on in the documentation that it was possible to revert back to the older version of a snap in case the update causes a problem. Additionally, the documentation says that the revert for a snap app happens when the user manually refreshs the snap. So if it is manual, how does the user or say a developer know what went wrong and where. The was the idea behind the question.
<Vamsi> Chipaca: Okay I didn't realise that I typed so much :|
<Chipaca> Vamsi: "the revert for a snap happens when the user manually refreshes the snap" that's not quite right, not sure exactly what you understood
<Chipaca> but
<Chipaca> Vamsi: if "snap install foo" fails, you do not end up with half-installed things (compare with "apt install")
<Chipaca> Vamsi: if snap install succeeded, and then a later refresh (whether automatic or manual) fails, that refresh is undone
<ogra_> well
<ogra_> and you *can* snap revert manually indeed :)
<Chipaca> Vamsi: "snap revert" is a different operation, where the user manually reverts to a previous version
<Chipaca> Vamsi: the user would initiate the revert because something broke, even though snapd didn't realise
<Chipaca> Vamsi: we want to additionally introduce health checks, where if a snap has a health check, and that helth check fails, the snap is automatically reverted
<Chipaca> Vamsi: but this last bit of work is not started
<ogra_> we're such slackers!
 * Chipaca writes down "trick ogra_ into creating a slackware base snap"
<ogra_> lol
<ogra_> tarballs everywhere !
<Chipaca> ogra_: I'll take that as a "yes"
<ogra_> heh
<Vamsi> Chipaca: Thanks :-) The document said this: 'For application snaps the user does this with snap revert <snap>'. So I understood that the revert process for application snaps was manual.
<Chipaca> Vamsi: correct, revert is manual
<Vamsi> Chipaca: Okay. In case of a failure of a snap. I.e., the snap stopped working or etc., are these logged automatically somewhere? If not, Is there a standardized way that a developer can implement such logging?
<Vamsi> Chipaca: Lets say, I have a snap. A user reported an error in it's behavior or something like that. As the application's developer, is it possible for me to get logs from the user's device to understand what caused the problem?
<Vamsi> Chipaca: I am trying to understand the diagnostic capabilities of snappy core.
<Chipaca> Vamsi: that's not currently a feature we offer, no
<Vamsi> Chipaca: So it's safe to say that snappy core offers no diagnostic tools to remotely check the device for errors errors etc?
<Chipaca> Vamsi: It is safe to say that, today, that is correct.
<Chipaca> Vamsi: why do I get the impression that you should be talking with our commercial team and not with us
<Vamsi> Chipaca: Thanks :-) Additionally, in one of your previous messages you said it is possible for the user to see a service's status and its logs. Where could I see this.
<Vamsi> Chipaca: Oh I am in touch with them. They directed me to the some documentation. Questions I asked here were something that was not clear/available in the documentation :|
<Chipaca> Vamsi: today, the way to look at a service's status and logs is via systemctl and journalctl
<Chipaca> Vamsi: i'm working on giving a slightly nicer way to get that, because of user demand :-)
<Chipaca> Vamsi: wrt commercial, ok. I only mention it because it's one of the things that drive feature prioritization.
<Chipaca> eg if there's a clear "we need <feature> so we can <zomg>", it's a lot easier to get to it sooner on the roadmap
<zyga-suse> mvo: any idea what just happened here:
<zyga-suse> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/i386/s/snapd/20170726_141551_02f64@/log.gz
<zyga-suse> - Run install hook of "core" snap if present (internal error: no registered handlers for hook "install")
<zyga-suse> via https://github.com/snapcore/snapd/pull/3399
<mup> PR snapd#3399: many: add the interface command <Created by zyga> <https://github.com/snapcore/snapd/pull/3399>
<zyga-suse> mvo: I assume this is the new stable core
<Vamsi> Chipaca: Got it. Right now I am only evalutaing Snappy core. Perhaps once I figure out what are the features that we need that are missing in snappy core, perhaps then would be good to raise requests for features.
<mvo> zyga-suse: autsch
<Chipaca> Vamsi: ok. Good luck!
<mvo> zyga-suse: a new core was released today
<zyga-suse> right, I recall that
<zyga-suse> and this didn't fail earlier
<mvo> zyga-suse: looks like the new hook stuff is not quite working
<zyga-suse> and the branch is definitely unrelated to hooks
<mup> PR snapcraft#1421 opened: Travis: Wait for apt/ dpkg lock <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1421>
<zyga-suse> looks like we broke something again
<zyga-suse> maybe the old snapd setup hooks in one way
<zyga-suse> and new snapd does it in a different way
<zyga-suse> (just task names)
<zyga-suse> so now we get this
<zyga-suse> so maybe we need a .15 that adds re-adds the legacy hook task handlers
<zyga-suse> (just a shoot in the dark)
 * zyga-suse is super sleepy and feels like actually sleeping now
<ogra_> Vamsi, if you talk about core itself, the core and kernel snaps definitely have some self tests and auto-rollback features ... managed by the bootloader setup together with snapd ...
<ogra_> this is different from application snaps though
<ogra_> (it checks if after an upgrade a certain safe point inn thhe system boot was reached, if not, it will automatically go back to last kernel or core)
<fgimenez> mvo: zyga-suse fwiw refresh from latest stable to the new core when it was in beta has been successfully tested, incuding revert, not sure what can be causing that test/upgrade/basic error
<mup> PR snapcraft#1422 opened: tests: remove the old script to launch lxc <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1422>
<Chipaca> niemeyer: for your lunch break: https://thedailywtf.com/articles/the-nuclear-option
<niemeyer> Chipaca: Thanks! :)
 * Chipaca was closing tabs :-)
<mvo> zyga-suse, fgimenez: also funny that it only happens on i386
<fgimenez> mvo: yep, and refresh from latest stable was also successfully tested on i386 (on all the archs for that matter :)
<mvo> fgimenez: yeah, never doubted this :) I'm just puzzled, one would assume it would fail everywhere at least
<fgimenez> mvo: does it fail in more than one PR?
<mvo> fgimenez: I have not instigated that yet, sorry
<fgimenez> mvo: np thanks, looking
<pedronis> Chipaca: +1
<Chipaca> pedronis: grazie mille
<mup> PR snapd#3399 closed: many: add the interface command <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3399>
 * zyga-suse needs a second review for 3619
<zyga-suse> mvo: I had a look at the branch for bases and I need to think about it; in theory all the snaps have a base and I'd rather have something uniform (I'm thinking about the extra bool flag)
<zyga-suse> Chipaca, pedronis ^ (maybe)? I could help some folks with their interface PRs if this lands
<jdstrand> sergiusens_: what change are you thinking for snappy-debug?
<niemeyer> Chipaca: OMG.. that code
<zyga-suse> go generate xls plugin
<niemeyer> Okay, I'm being pinged by Linode again.. will need to work on Spread to reduce the API calls so we don't get our tests blocked again
<niemeyer> Moving to that now
<Pharaoh_Atem> zyga-suse: yo
<zyga-suse> o/
<Pharaoh_Atem> zyga-suse: did you ever send an email to the selinux@ mailing list asking about how to do the stuff we need for snap confinement to work?
<zyga-suse> no, I didn't :-(
<Pharaoh_Atem> it was pointed out to me in #fedora-devel that no one has ever actually asked there
<Pharaoh_Atem> so no one knows why snapd can't be plugged into selinux the same way it can be on apparmor
<zyga-suse> shall we start that thread today?
<Pharaoh_Atem> yes, hold on
<Pharaoh_Atem> need to sub to SELinux ML
<zyga-suse> yeah, me too
<zyga-suse> Pharaoh_Atem: this one?
<zyga-suse> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
<tyhicks> mjg's post in the snapcraft forum summarizes the problems quite well
<Pharaoh_Atem> zyga-suse: no, the upstream one: https://www.nsa.gov/what-we-do/research/selinux/mailing-list.shtml
 * Chipaca EODs
<Pharaoh_Atem> zyga-suse: though sending to fedora-selinux is also a good idea
<zyga-suse> Chipaca: noooo
<tyhicks> (https://forum.snapcraft.io/t/selinux-interface-support/255)
<Pharaoh_Atem> zyga-suse: I would send to both
<Pharaoh_Atem> zyga-suse: hold on, the fedora one is this: http://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.org/
<tyhicks> zyga-suse, Pharaoh_Atem: I think the better solution is to work towards getting the LSM stacking patches fully functional and upstream
<Pharaoh_Atem> tyhicks: it won't matter
<Pharaoh_Atem> downstream, hardly anyone will do it
<Pharaoh_Atem> it's just too much extra work
<Pharaoh_Atem> maintaining *one* security system is a lot of work as it is
<Pharaoh_Atem> if you expect people to maintain two for just *one* application, it's not going to fly
<tyhicks> it is far less work than attempting to write equivalent SELinux policy for interfaces
<tyhicks> many distros already have kernel and userspace support for multiple LSMs
<zyga-suse> tyhicks: I somewhat agree with Pharaoh_Atem here, I think that in Fedora/RHEL land specifically it would fly much better with native selinux support even if that is harder
<zyga-suse> (because they support selinux and not apparmor even if it technically gets stacked)
<Pharaoh_Atem> we don't even have the apparmor userspace stuff packaged in Fedora
<pedronis> zyga-suse: sorry, what was the "this"Â in your review request?  the PR before was merged
<tyhicks> zyga-suse: they don't need to support apparmor policy - they only need the tools available
<pedronis> zyga-suse: before as in the logs here
<zyga-suse> pedronis: https://github.com/snapcore/snapd/pull/3619
<mup> PR snapd#3619: interfaces/builtin: reduce duplication and remove cruft in Sanitize{Plug,Slot} <Created by zyga> <https://github.com/snapcore/snapd/pull/3619>
<Pharaoh_Atem> and unless zyga wants to add *that* to his plate of packages, it's unlikely to get in
<zyga-suse> pedronis: nothing fancy, just a small cleanup
<Pharaoh_Atem> nothing says that apparmor userspace can't be packaged, but you need to convince the kernel team to enable it
<Pharaoh_Atem> they currently do not
<jdstrand> tyhicks: technically, snapd could ship its own abstractions and parser there too
 * zyga-suse has stuff falling off his plate already
<tyhicks> jdstrand: that's a very good point
<Pharaoh_Atem> and all the things need to be compiled with apparmor support
<zyga-suse> jdstrand: technically, don't we already do that in core?
<zyga-suse> Pharaoh_Atem: I subscribed to both though I didn't get a confirmation from the NSA one
<zyga-suse> (maybe they need to login to all my machines to check first ;-)
<jdstrand> zyga-suse: yes. things would need to be shuffled around to use the internal parser, but yes
<Pharaoh_Atem> tyhicks: it's a humongous amount of work and coordination to get things through and enabled, even with no policy
<Pharaoh_Atem> zyga-suse: I've not seen an confirmation email either
<Pharaoh_Atem> I'm not sure it sends one...
<zyga-suse> Pharaoh_Atem: while it may not be supported by fedora I think tyhicks' point is that it can all be done in snapd as long as the kernel cooperates
<zyga-suse> which is another question
<Pharaoh_Atem> again, convincing the fedora kernel team is another obstacle toward that
<Pharaoh_Atem> unless you want to be "point man" for Fedora AppArmor, it's not something worth suggesting
<tyhicks> Pharaoh_Atem: what about all the technical limitations of attempting to write equivalent SELinux policy to match existing AppArmor policy? I feel like you're vastly ignoring the problems there
<zyga-suse> well, I think we want to attempt both ways
<zyga-suse> technically LSM stacking is easier and feels better
<zyga-suse> but socially it may be received less well
<zyga-suse> "easier" as in just easier, not easy though
<Pharaoh_Atem> tyhicks: I'm not
<Pharaoh_Atem> both are hard, but one involves working with a hell of a lot of other people
<jdstrand> I don't doubt that some may push back, but lots of people want stacking-- this isn't just a snapd thing. lots of distros enable both selinux and apparmor (and other LSMs) in their kernels, but either do nothing with policy or pick one
<Pharaoh_Atem> I think you underestimate how much coordination effort is actually required for getting even apparmor userspace up and going, even without policy
<tyhicks> they both do
<tyhicks> it is just different groups of people :)
<jdstrand> there is a spectrum
<jdstrand> Pharaoh_Atem: as mentioned, that could ll be packaged within snapd if the distro doesn't care about it
 * zyga-suse things one thing is horribly missing; a good barrel of beer and all the key people in one room
<zyga-suse> so that all the hard edges can be discussed
<Pharaoh_Atem> jdstrand: you're still missing that systemd can't filter profile things
<Pharaoh_Atem> that needs linking into libapparmor
<Pharaoh_Atem> look, adding apparmor as a userspace package is *easy*
<jdstrand> we don't use systemd's apparmor support in snappy
<Pharaoh_Atem> zyga-suse could propose it today, and I can have it added in right away
<jdstrand> snapd manages it all itself
<Pharaoh_Atem> that's not a big deal
<Pharaoh_Atem> if zyga-suse put on his nicest outfit and the best words, he probably could sweet-talk Fedora kernel team into enabling apparmor in the kernel
<Pharaoh_Atem> honestly, I'm not worried about those things
<Pharaoh_Atem> what I'm worried about is making sure that the apparmor stuff is usable
<Pharaoh_Atem> according to the folks I've talked to, there are currently no efforts in stacking selinux and apparmor
<zyga-suse> "I have the best words" doesn't sound like someone I want to be affiliated with, just look at my hair anyway
<tyhicks> that's not true
<jdstrand> if people want full apparmor userspace, that's great and yes that would include the tools and systemd and policy and .... my point is that all that isnt strictly needed with snapd. only the kernel to have it compiled in. I suspect booting without it enabled wouldn't be terrible too-- snapd could mention changing the command line to make it work (at least until it proves itself)
<tyhicks> we're (AppArmor upstream) working the author of the LSM stacking patch set
<zyga-suse> Pharaoh_Atem: offtopic, boltron feels ... bolted ... on ... who names those things?
<Pharaoh_Atem> zyga-suse: the Czech guys did
<tyhicks> in fact, he is working on testing his patch set with the apparmor regression test suite: https://lists.ubuntu.com/archives/apparmor/2017-July/010909.html
<Pharaoh_Atem> clearly, no sense for names
<Pharaoh_Atem> jdstrand: look, if the kernel feature is enabled, there's literally no reason not to have apparmor in Fedora as userspace package
<Pharaoh_Atem> it's probably easy for zyga to maintain as he works with you guys
<tyhicks> this is something that we're going to be discussing and working on between now and the Linux Security Summit, where there's a BOF discussion
<jdstrand> Pharaoh_Atem: I totally agree with that. In terms of steps and push back, etc, I'm just saying there are different options and paths
<zyga-suse> it's hard as we have a hard time to keep focus on packaging _and_ upstream work
<Pharaoh_Atem> and zyga-suse is friends with zbyszek, who is the fedora systemd maintainer :)
<Pharaoh_Atem> so getting apparmor switched on in Fedora systemd is probably not going to be hard
<Pharaoh_Atem> heck, for some reason, smack support is enabled
<jdstrand> I'd love to see full blown apparmor support in fedora. I suspect some people might like it too. maybe that happens right away. maybe it doesn't. maybe having only snapd use it makes it more interseting to make it available in the distro
<zyga-suse> s/friends/I was friendly towards him and vice versa but we never met IRL/g
<zyga-suse> but yeah ;)
<Pharaoh_Atem> I wish AppArmor had better diagnostics
<tyhicks> Pharaoh_Atem: am I looking in the wrong place? http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/baseconfig/CONFIG_SECURITY_SMACK
<jdstrand> anyway, I'm not advocating a particular path. I'm just mentioned some options
<jdstrand> mentioning*
<Pharaoh_Atem> tyhicks: I've never seen this before O.o
 * Pharaoh_Atem should read these things more often
<Pharaoh_Atem> tyhicks: yeah, it's not enabled in the kernel
<tyhicks> Pharaoh_Atem: how are you seeing that smack is enabled?
<tyhicks> ok
<Pharaoh_Atem> tyhicks: I mean it's enabled in systemd
<tyhicks> ah, I see
<Pharaoh_Atem> [neal@yu-ohki ~]$ systemctl --version
<Pharaoh_Atem> systemd 233
<Pharaoh_Atem> +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN default-hierarchy=hybrid
<zyga-suse> -apparmor :'-(
<Pharaoh_Atem> zyga-suse: I suspect if you packaged apparmor for fedora and got it in, zbyszek would be happy to enable it
<tyhicks> I don't want to discourage you from engaging with SELinux upstream but I did want to point out that AppArmor upstream is going to be working with the greater LSM community to get LSM stacking into shape and widely available
<zyga-suse> to be able to commit to that I'd have to become a full blown package maintainer and I have a lot of upstream work to be able to do that, I don't think it's realistic today
<Pharaoh_Atem> zyga-suse: tyhicks and jdstrand will gleefully support your endeavor to spread the AppArmors :P
<tyhicks> we're getting pretty off-topic here but I'll mention that opensuse's packaging for apparmor would probably be reusable
<Pharaoh_Atem> tyhicks: nothing is offtopic in a channel with no topic :)
<tyhicks> :)
<Pharaoh_Atem> but yes, it most likely would be
<Pharaoh_Atem> it does some dumb suse-y things, but it's generally okay
 * zyga-suse summons sysrich and gets popcorn
<Pharaoh_Atem> AppArmor has also been on the wishlist for literally years: https://fedoraproject.org/wiki/Package_maintainers_wishlist?rd=PackageMaintainers/WishList#A-D
<Pharaoh_Atem> tyhicks: I have my hands full working on the features I'm working on in Fedora now
<tyhicks> Pharaoh_Atem: I wasn't implying that you should do any work
<Pharaoh_Atem> between the pkgconf transition in f26 and the new debuginfo stuff in f27 and the core development work in mga7, I'm stretched quite thinly
<Pharaoh_Atem> nevermind keeping up with snappy stuff :)
<tyhicks> yeah, sounds like a lot
<Pharaoh_Atem> I need to find someone interested in snappy stuff in mga to pull into this
<Pharaoh_Atem> I can't juggle so many things :)
<zyga-suse> more hands is always good
<zyga-suse> if you know someone that would be a good fit please introduce such a person
<Pharaoh_Atem> I actually do
<Pharaoh_Atem> Remi Verschelde
<Pharaoh_Atem> Akien
<Pharaoh_Atem> https://twitter.com/akien
<Pharaoh_Atem> he's also one of the core developers of the Godot game engine
<Pharaoh_Atem> zyga-suse: you should reach out to him with your best words :)
 * zyga-suse thinks about another trump joke 
 * zyga-suse has super slow network 
<zyga-suse> I'm trying to follow him and I'll reach out as soon as my network recovers
<zyga-suse> for now I'll resort to reading a book and trying to fall asleep again
<niemeyer> I just deployed a new spread change that performs more caching to avoid hitting Linode so badly
<Pharaoh_Atem> zyga-suse: you could email him instead if you want
<niemeyer> Please let me know if you see any issue
<niemeyer> s
<zyga-suse> niemeyer: thanks! I assume locally installed spread should be updated as well
<zyga-suse> niemeyer: how many requests were we making?
<zyga-suse> Pharaoh_Atem: can you share his email address please?
<niemeyer> niemeyer: Too many.. we've never tried to optimize away that because it was created with 2 or 5 instances in mind, rather than 20 or 30
<niemeyer> zyga-suse: ^
<Pharaoh_Atem> zyga-suse: done, sent via PM
<niemeyer> zyga-suse: The Linode listing calls being the main offender, as they were done recurringly and per instance to check the power status
<niemeyer> Now it performs a single list call for all instances, and caches the result.. so not linear anymore
<Pharaoh_Atem> zyga-suse: feel free to cc me if you want
<niemeyer> Folks, please update spread on your systems as well
<niemeyer> cachio_ ^
<cachio_> niemeyer, ok
<sergiusens> jdstrand: today it tells you to adapts /dev/shm so that it is namespaced, but it is a common interface point for lttng so maybe suggest devmode until an interface exists
<mup> PR snapcraft#1421 closed: ci: wait for apt/dpkg lock when setting lxd up <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1421>
<niemeyer> pedronis: Did the final review on Chipaca's point, which is actually just a +1 on your point regarding the app name splitting
<niemeyer> pedronis: Since Chipaca is not around, LGTM on the PR assuming we fix that
<niemeyer> pedronis: The reason the PR had to introduce an independent split function is precisely that it's introducing an independent understanding of how to split, which seems unnecessary
<niemeyer> (and wrongish)
<niemeyer> This is about snapd#3614
<mup> PR snapd#3614: daemon, client, cmd/snap: implement "snap services" <Created by chipaca> <https://github.com/snapcore/snapd/pull/3614>
<mup> PR snapcraft#1410 closed: tests: remove download timeout workaround <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1410>
<mup> PR snapcraft#1423 opened: Revert "tests: workaround issue that causes failures to download coreâ¦ <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1423>
<mup> PR snapd#3626 opened: tests: fix refresh task not stopping fake store for fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3626>
<jdstrand> sergiusens: ack
<mup> PR snapd#3626 closed: tests: fix refresh task not stopping fake store for fedora <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3626>
<mup> PR snapd#3627 opened: tests: fix refresh task not stopping fake store for fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3627>
<cachio_> niemeyer, if you have a time for review this PR 3627
<cachio_> niemeyer, not sure why it shows 28 commits when I just did 2
<niemeyer> Looking
<niemeyer> cachio_: That's because you have a fork of master on your end with dozens of changes, some of which have been integrated
<niemeyer> cachio_: Create a new branch from master on your end, and then merge the patch from that branch on it, and it'll clean the PR up
<cachio_> niemeyer, ok, thanks
<pedronis> niemeyer: well afaiu  the code there wants use "foo"Â to always mean the snap,  and "foo.foo"Â to mean the app, not quite sure how to accomodate that and the idea that foo means "foo.foo"
<mup> PR snapd#3627 closed: tests: fix refresh task not stopping fake store for fedora <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3627>
<mup> PR snapd#3628 opened: tests: fix refresh task not stopping fake store for fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3628>
<pedronis> niemeyer: Chipaca: I fear it means probably the APIÂ is too dwimish for being an API
<pedronis> niemeyer: is this bit of API convention/doc that is problematic:   +// Apps returns information about all matching apps. Each name can be
<pedronis>  +// either a snap or a snap.app.
<niemeyer> Oh no.. there we go again.. Chipaca will have a heart attack :)
<niemeyer> pedronis: Hmm.. I think it may be okay, though
<niemeyer> pedronis: We can use the foo.foo syntax to disambiguate, perhaps
<pedronis> niemeyer: yes, exactly
<pedronis> that's why he need the different split though
<pedronis> niemeyer: my point is more whether this bit should be part of the RESTÂ API (or there app vs snap should be more explicit) or just part of cmd/snap code
<niemeyer> pedronis: Yeah, indeed
<mup> PR snapd#3628 closed: tests: fix refresh task not stopping fake store for fedora <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3628>
<niemeyer> Let me check it again
<Chipaca> niemeyer: ping
<mup> PR snapd#3627 opened: tests: fix refresh task not stopping fake store for fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3627>
<niemeyer> Chipaca: I know!
<niemeyer> :P
<Chipaca> ?
<niemeyer> Chipaca: Joking.. We were just discussing the PR and the comment above, seconds ago :)
<Chipaca> ah. missed it.
<niemeyer> Chipaca: Yeah, sorry, and no worries
<niemeyer> Chipaca: I know the issue with my suggestion.. trying to think through it
<Chipaca> niemeyer: but i'm hear about the pr and the review and the comment
<niemeyer> (pedronis pointed out)
<Chipaca> "the issue" being that AFAIK the only place where foo.foo == foo is in /snap/bin?
<niemeyer> Chipaca: Well, every place we use the main split function that logic plays again
<pedronis> Chipaca: also snap run IÂ think
<pedronis> and lots of places internally
<niemeyer> Chipaca: So this is sort of a fundamental rule we've been trying to respect
<niemeyer> Chipaca: Given the term Apps(foo) I think the most natural would be for foo to be names of apps
<Chipaca> FTR, the service units do not follow this
<niemeyer> Chipaca: So the app "foo" would IMO take precedence of the snap "foo"
<niemeyer> Chipaca: Yeah, but that's sort of an edge that we'll soon see fixed
<niemeyer> Chipaca: (that entry in the roadmap that we've been overlooking)
<Chipaca> in fact I don't see a place that usees snap.SplitSnapApp that isn't about /snap/bin, or aliases
<niemeyer> Chipaca: Where else do we talk about apps in the user interface?
<niemeyer> Chipaca: Ah, and look at JoinSnapApp as well
<niemeyer> Chipaca: This is the complement of Split
<Chipaca> sigh
<Chipaca> i don't see it being relevant for services :-(
<Chipaca> i don't get why it's so fundamental all of a sudden
<Chipaca> but, it's past my eod. i'll leave you to it.
<Chipaca> ttfn!
<niemeyer> Chipaca: The point is that it's not all of a sudden..
<Chipaca> â¦
<niemeyer> Chipaca: Wait..
<Chipaca> niemeyer: but it is?
<pedronis> DWIMish apis are strange
<pedronis> I think we had related problems with aliases
<zyga-suse> DWIM?
<pedronis> and had to think a bit
<pedronis> zyga-suse: do-what-I-mean
<niemeyer> Chipaca: No, we do that for apps for quite a while, and services are apps, as we've been going through a few times
<zyga-suse> aha
<zyga-suse> gcc --dwim would be a nice feature
<niemeyer> Chipaca: But, let's just try to fix this somehow.. hmm
<Chipaca> if the veredict is "it's always app names, never snap names", that's easy to do
<Chipaca> completion will be there, so users can always use alt-*
<niemeyer> Chipaca: Problem with that is that the most useful outcome for that specific command is that it's always snap names
<Chipaca> of course most users don't know about alt-* Â¯\_(ã)_/Â¯
<niemeyer> Chipaca: Maybe we should just split those apart
<mup> PR snapd#3629 opened: tests: fix refresh tests not stopping fake store for fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3629>
<niemeyer> Chipaca: That removes the ambiguity
<niemeyer> Yeah, I think that's the most sane
<Chipaca> niemeyer: io
<niemeyer> Chipaca: Two different parameters.. instead of names, "apps" and "snaps", on the API
<Chipaca> niemeyer: i'm not sure if you're agreeing with yourself or with me, there
<Chipaca> niemeyer: i don't understand how that helps
<mup> PR snapd#3627 closed: tests: fix refresh task not stopping fake store for fedora <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3627>
<cachio_> niemeyer, finally the PR to review is 3629
<niemeyer> Chipaca: apps resolves _only_ to apps, and snaps resolves _only_ to snaps (returning the set of all apps in that snap)
<cachio_> niemeyer, it is fixed now
<Chipaca> yes but the user doesn't talk to the api
<niemeyer> Chipaca: Then, on the CLI, let's accept snap names only
<niemeyer> Chipaca: Or, actually.. we can still accept both.. one sec
<mup> PR snapcraft#1408 closed: lxd: Stop setting $HOME in containers <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1408>
<niemeyer> Chipaca: Yeah, okay: if we receive "foo" we handle it as a snap name.. if we receive "foo.bar" we handle it as an app name
<niemeyer> Chipaca: Calling the respective APIs
<Chipaca> when you say "calling the respective APIs"
<niemeyer> Chipaca: The effect is pretty much the same as your current PR.. only difference is that the API becomes unambiguous
<niemeyer> I guess it doesn't matter much..
<niemeyer> We can always introduce the new parameters with the new meanings..
<niemeyer> Chipaca: Go rest
<niemeyer> Chipaca: PR LGTM once tests pass
<Chipaca> PR has conflicts, and tests fail I assume because of the core release
<Chipaca> will fix in the morning
<Chipaca> g'night
 * zyga-suse hugs Chipaca
 * Chipaca hugs zyga-suse back
<zyga-suse> have a good rest man
<Chipaca> mmm
<Chipaca> need a walk first i think
<Chipaca> \o
<pedronis> niemeyer: yes, having separate snaps vs apps seems similar to what we did with aliases I think
<niemeyer> pedronis: Yeah, I think that's what we need
<niemeyer> pedronis: Let's please make sure that the current parameters is "names" instead of "apps"
<niemeyer> pedronis: So we clear the path for the unambiguous version of those
<niemeyer> apps should be apps, not snaps
<pedronis> ah, yes, it's apps
<pedronis> atm
<pedronis> so it need some change anyway :/, we'll see what Chipaca thinks
<niemeyer> pedronis: Let's just call it "names".. makes no difference for this PR
<niemeyer> pedronis: We can keep support for "names" later as the magic matching, as is now, and have "snaps" and "apps" with the unambiguous versions of those
<pedronis> just pointing out that the PRÂ needs a change
<niemeyer> Yeah, it needs a change anyway
<pedronis> a small one
<niemeyer> (to solve conflicts)
<pedronis> ah, that too
<pedronis> ok
 * zyga-suse read https://lwn.net/Articles/728699/
<niemeyer> cachio_: Do you have the new PR?
<niemeyer> zyga-suse: Paywal
<niemeyer> l
<zyga-suse> niemeyer: I think you have a subscription
<zyga-suse> niemeyer: but I can give you a "free" link in a PM if you want one
<niemeyer> zyga-suse: Do I?  Either way, most people here don't I'd assume
<zyga-suse> niemeyer: everyone at Canonical does
<zyga-suse> I PMd you with a "freel" link
<cachio_> niemeyer, yes
<cachio_> niemeyer, I had to recreate the local master
<cachio_> niemeyer, and make cherry-pick to fix it
<niemeyer> cachio_: link?
<cachio_> niemeyer, https://github.com/snapcore/snapd/pull/3629
<mup> PR snapd#3629: tests: fix refresh tests not stopping fake store for fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3629>
<dpb1> hey all --- $ simplenote
<dpb1> cannot stat /var/lib/snapd/seccomp/bpf: No such file or directory
<dpb1> something missing with apparmor?
<zyga-suse> dpb1: hey, what is your "snap version"?
<zyga-suse> that looks like a bug in snapd
<zyga-suse> dpb1: (it's actually seccomp, not apparmor this time)
<dpb1> sec
<dpb1> snap    2.26.14
<dpb1> (xenial)
<dpb1> ah, snapd update is waiting
<zyga-suse> is this in a container?
<niemeyer> cachio_: I'm finding these prepare and restore in the refresh test pretty hard to follow
<niemeyer> cachio_: There are so many exit points.. pretty hard to track what is actually happening there
<dpb1> zyga-suse: no, it's a desktop workstation
<dpb1> I'm upgrading snapd and will try again
<zyga-suse> dpb1: can you open a topic on forum.snapcraft.io please?
<dpb1> zyga-suse: sure
<zyga-suse> dpb1: add things like "snap version" (the full output), "snap changes" and the name of the snap that you saw this with
<niemeyer> cachio_: Your changes are minor, so if they fix the problem, LGTM
<niemeyer> cachio_: But it would be good to clean that up at some point
<zyga-suse> dpb1: not sure what's wrong yet, I mean, I know but not sure why :)
<dpb1> zyga-suse: looks like it's still happening after the upgrade, so I will open that post
<cachio_> niemeyer, but I already did it
<zyga-suse> dpb1: ack
<niemeyer> cachio_: ?
<zyga-suse> when did it break on you?
<cachio_> niemeyer, the clean up for the commits
<zyga-suse> just now?
<zyga-suse> (we released a new stable core snap so you likely updated to it)
<zyga-suse> dpb1: paste the link to the forum once you have that topic up
<niemeyer> cachio_: Did you read the messages above? :)
<cachio_> niemeyer, no, now reading
<zyga-suse> niemeyer: can you squeeze a quick review of https://github.com/snapcore/snapd/pull/3619 ?
<mup> PR snapd#3619: interfaces/builtin: reduce duplication and remove cruft in Sanitize{Plug,Slot} <Created by zyga> <https://github.com/snapcore/snapd/pull/3619>
 * zyga-suse is 3/4 through "ponyo" but then needs to put kids to bed (including any extra food and cleaning they may need)
<cachio_> niemeyer, yes, agree with you, there are so many if
<cachio_> niemeyer, as part of this branch I just fixed the issue
<dpb1> zyga-suse: https://forum.snapcraft.io/t/simplenote-snap-cannot-stat-var-lib-snapd-seccomp-bpf-no-such-file-or-directory/1446
<zyga-suse> thanks!
<niemeyer> cachio_: Not just that, but the break outs via exit makes it all hard to follow
<zyga-suse> ha
<cachio_> niemeyer, ok, I can work in another branch to simplify that
<zyga-suse> snap    2.26.14
<zyga-suse> snapd   2.25
<zyga-suse> this is very very wrong!
<zyga-suse> can you add your journal logs? (like journalctl -u snapd)
<niemeyer> cachio_: Not super urgent, but worth an item in the backlog
<cachio_> niemeyer, in fact, the prepare/restore is repeated in 7 tests
<cachio_> niemeyer, prepare-image-grub, refresh-all-undo, refresh-all, refresh-devmode, refresh, revert-devmode and revert
<zyga-suse> dpb1: let's move the discussion to the forum
<cachio_> so, 1 fix would work for all of them
<dpb1> zyga-suse: adding
<dpb1> zyga-suse: and ok
<dpb1> :)
<cachio_> niemeyer, it goes to my queue
<zyga-suse> dpb1: more questions posted
<dpb1> zyga-suse: ok, I'm doing an apt-get dist-upgrade right now as I'm pretty out of date
<zyga-suse> dpb1: which version were you on?
<dpb1> zyga-suse: I'll post back results to the forum in a sec
<zyga-suse> thanks!
<mup> Bug #1681833 changed: Devmode Edge Snap not automatically updating <Snappy:Invalid> <https://launchpad.net/bugs/1681833>
<mup> PR snapcraft#1422 closed: ci: remove the old script to run with lxc <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1422>
<niemeyer> cachio_: Thanks!
 * zyga-suse afk for some time
<jdstrand> roadmr: hey, I added another check to the review tools. can you sync r892? this isn't urgent
<roadmr> jdstrand: sure thing!
<jdstrand> roadmr: thanks!
<mup> PR snapcraft#1373 closed: snapcraft.yaml: add support for reload-command and completer directives <Created by bloodearnest> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1373>
 * zyga-suse EODs
<mup> PR snapcraft#1416 closed: core: a clean command should clean <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1416>
<mup> PR snapcraft#1423 closed: Revert "tests: workaround issue that causes failures to download coreâ¦ <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1423>
<mup> PR snapcraft#1418 closed: nodejs plugin: copy the content of out of tree symlinks <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1418>
<mup> PR snapd#3629 closed: tests: fix refresh tests not stopping fake store for fedora <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3629>
<cachio> niemeyer, 2017-07-26 23:17:27 Cannot allocate linode:ubuntu-14.04-64: backend "linode" missing Linode API key
<cachio> niemeyer, all the builds failing because of that
<cachio> niemeyer, example: https://travis-ci.org/snapcore/snapd/builds/257940281?utm_source=email&utm_medium=notification
<niemeyer> cachio: Thanks, will have a look later today
<cachio> niemeyer, quick question, any idea is snapd will be uploaded to the zypper repository?
<niemeyer> cachio: I don't really know
<cachio> niemeyer, ok, np
#snappy 2017-07-27
<zyga-suse> good morning
<mvo> hey zyga-suse, good morning
<zyga-suse> mvo: hey,
<zyga-suse> mvo: did you see https://forum.snapcraft.io/t/simplenote-snap-cannot-stat-var-lib-snapd-seccomp-bpf-no-such-file-or-directory/1446/9 ?
<zyga-suse> mvo: I thought this is another instance of the rrexec bug from last week but I'm not so sure anymore
<zyga-suse> I found it interesting that half of snapd reexecuted
<zyga-suse> but the rest did not
<zyga-ubuntu> mvo: I'll grab some food and I'll be back soon to do code reviews
<mvo> zyga-ubuntu: yeah, will do the same
<mvo> zyga-ubuntu: interessting bug :/
<mup> PR snapd#3614 closed: daemon, client, cmd/snap: implement "snap services" <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3614>
<zyga-suse> mvo: last night gustavo asked everyone to upgrade spread
<zyga-ubuntu> I wrote a test simulating 2.0.2 and re-execing snapd, let's see how it works
 * zyga-suse wonders what the movie crew outside is doing?
<zyga-suse> I need a 2nd review for 3619
<zyga-suse> they are shooting a TV show outside now
 * zyga-suse wonders what's going on
<pedronis> zyga-suse: why each of this check that the interface match?  shouldn't this be done before/somewhere in the caller?  is there a case where that shouldn't hold?
<zyga-suse> pedronis: I think we never call this incorrectly but this is part of the code that was written veeery long time ago
<zyga-suse> pedronis: and I think we just kept the cross-checking semantics
<zyga-suse> pedronis: I wasn't trying to change it, just improve how it is done
<pedronis> well, given we are cleaning up, I question why not clean up even more
<pedronis> notice that pawel will have to touch these again btw
<pedronis> new names, new signatures
<zyga-suse> aha, indeed
<zyga-suse> well, I can yank the sanitize calls if you feel strongly about them
<zyga-suse> in theory this ensures that we are not, by mistake, allowing sanitize to pass with a wrong interface
<pedronis> I don't feel strongly but you are asking to check you put everywhere something, where that probably means it's done in the wrong place
<zyga-suse> I think it's more of a security paranoia at play; I just checked how we call Sanitize and we always call it with a matching interface that is looked up from the Interface field
<zyga-suse> so again, I can remove it as there seems to be no harm done
<pedronis> well, you can define helpers on repo
<pedronis> sanitizePlug  and sanizeSlot
<pedronis> that would do the check
<pedronis> if you feel the paranoia is worth
<pedronis> it's a bit strange to ask everybody writing an interface to help taking of this paranoia
<zyga-suse> they are taking another shot of the same scene
<zyga-suse> indeed
<pedronis> this things are called in 4 places at all
<zyga-suse> though I think we had those helpers and they were nacked before (they checked for any panics as well)
<pedronis> I think Gustavo was gainst the catching panics
<pedronis> not the helpers
<zyga-suse> I think you are right
<zyga-suse> let me put private helpers in the repo and drop the checks in each interface then
<pedronis> you could even have private helpers sanitize on Slot and Plug themselves
<zyga-suse> hmm, interesting
<zyga-suse> let me experiment
<zyga-suse> (and another shot)
<pedronis> mmh
<pedronis> sorry
<zyga-suse> about what?
<pedronis> nothing was thinking something
<zyga-suse> mvo: ha
<zyga-suse> mvo: so weird
<zyga-suse> mvo: if I start with 2.0.2
<zyga-suse> mvo: there's no core transition yet
<zyga-suse> so.... we're on 2.0.2 forever
<zyga-suse> (and ever and ever)
<zyga-suse> it seems
<zyga-suse> not sure if we can even do anything about it
<mvo> zyga-suse: does 2.0.2 do re-exec?
<zyga-suse> nope
<zyga-suse> I don't see any traces of that
<mvo> zyga-suse: then there is really nothing we can do :/
<mup> PR snapd#3615 closed: add broadcom-asic-control interface <Created by knitzsche> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3615>
<zyga-suse> I think we only managed to do it for a later version that was also in debian stable
<zyga-suse> mvo: yep, I just found this very unfortunate as this is the version the reporter of that bug was using
<mvo> zyga-suse: I mean, without re-exec its irrelevant if it fetches core or ubuntu-core. in general if things re-exec it will work even if ubuntu-core is used. then it will fetch ubuntu-core re-exec into that snapd and that snapd will transition to core
<mvo> zyga-suse: version 2.21 is doing re-exec but we had a experimental re-exec in some earlier versions that got disabled again. iirc 2.0.10 is also re-execing
<mvo> zyga-suse: unfortunate> totally :/
<zyga-suse> mvo: one idea, unpublish ubuntu-core
<zyga-suse> or even tweak the store to say something like "update your snapd package"
<zyga-suse> as an error message, if one can be shoved to 2.0.2
<mvo> zyga-suse: if people start from a version that fetches ubuntu-core, thats fine, things will work.
<zyga-suse> do we know which version is requesting the snap?
<mvo> zyga-suse: I mean, the problem with 2.0.2 is that it is not doing re-exec at all. or am I missing something?
<zyga-suse> maybe we could reject ubuntu-core on 2.0.2 installs
<zyga-suse> mvo: yes, that's the problem
<zyga-suse> and somehow people keep having it because it's on the ISO
<mvo> zyga-suse: aha, I see. well, ideally the store would reply to every request from 2.0.2 with "please upgrade your snapd". so +1 for this proposal, we just need to check if the error message is visiable to the end-user
<zyga-suse> now we just need to check with store people to see if we can craft this
<zyga-ubu1tu> Chipaca: o/
<Chipaca> zyga-ubuntu: \o
<mvo> zyga-ubuntu: does 3591 look good to you?
<mvo> zyga-ubuntu: you did a review before and jamie addressed things afaict
<mvo> hey Chipaca
<Chipaca> mvo: how's things with you?
<zyga-suse> mvo: just a sec
<zyga-ubuntu> mvo: I wrote a forum topic on the 2.0.2 problem https://forum.snapcraft.io/t/snapd-2-0-2-doesnt-reexecute-pulls-in-ubuntu-core-stays-stale/1455
<zyga-ubuntu> mvo: yep, +1
<mvo> Chipaca: doing well, finally doing reviews :)
<mvo> Chipaca: and you?
<Chipaca> mvo: no longer working on 'snap status'!
<zyga-ubuntu> Chipaca: congrats on merging your PR
 * Chipaca dances
<Chipaca> of course, the next one is 'snap logs', so... :-)
<Chipaca> Â¯\_(ã)_/Â¯
<zyga-ubuntu> Chipaca: just put an easter egg when you run "snap logs everything"
<mup> PR snapd#3591 closed: interfaces/greengrass-support: adjust accesses now that have working snap <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3591>
<zyga-ubuntu> could be an ester egg theme
<Chipaca> zyga-ubuntu: I couldn't possibly comment
<mvo> Chipaca: yay!
<ppisati> ogra_: since when we required the dtb to be part of the kernel snap? wasn't it supposed to be part of the gadget snap?
<zyga-suse> ppisati: it was discussed in london, the idea is that it is tied to the kernel snap as the kernel may or may not boot depending on the dbt that is used
<zyga-suse> ppisati: (in the pi specific case)
<ppisati> zyga-suse: ok
<zyga-suse> ppisati: https://forum.snapcraft.io/t/development-sprint-june-26th-2017/415/46?u=zyga
<ogra_> ppisati, it is only part of the gadget for pi ... all other boards use it from the kernel snap
<ogra_> ppisati, and what we discussed in london was to move for the pi to the same model and additionally include the binary blobs in the kernel snap
<ogra_> ppisati, essentially everything that is version wise bound together will go into the kernel snap on pi ... making us lose any kind of rollback for the kernel though
<ppisati> ogra_: ack
<zyga-ubuntu> changing anything about interfaces in genral is a chore
<morphis> mvo, zyga-ubuntu: do you guys have time to look at https://github.com/snapcore/snapd/pull/3260 ?
<mup> PR snapd#3260: cmd/snap: implement userd command as replacement for snapd-xdg-open <Created by morphis> <https://github.com/snapcore/snapd/pull/3260>
<zyga-ubuntu> morphis: not at present
<morphis> hm
<zyga-ubuntu> I'm wrapping up stuff to switch to packaging and layouts
<zyga-ubuntu> maybe after packaging
<flexiondotorg> Trevinho Afternoon. What is the current status of your Telegram snap?
<Trevinho> flexiondotorg: hey
<Trevinho> flexiondotorg: I've replied to an email from popey some weeks ago about it..
<flexiondotorg> Can you forward that to me please?
<Trevinho> flexiondotorg: basically, it needs work... Which I might do to finish if there's interest and we can have proper upstream contacts
<Trevinho> flexiondotorg: sure I can
<flexiondotorg> Thanks.
<flexiondotorg> Does the email outline what work is required?
 * zyga-ubuntu uses telegram snap all the time, would love to see upstream adopt it
 * ogra_ uses sergios telegram snap ... 
<ogra_> i didnt even know Trevinho has one as well !
<Trevinho> ogra_: mine is basde on sources
<Trevinho> ogra_: but I didn't publish on store
<Trevinho> ogra_: or well not public
<ogra_> ah
<Trevinho> I wanted to get snapcraft to do the cool job of compilinng all the ellemtns and such
<Trevinho> as they do upstream..
<Trevinho> ogra_: there is an email I sent to canonical-snapcraft ML
<ogra_> ages ago ... i remember that
<Trevinho> flexiondotorg: sent
<flexiondotorg> ty
<Chipaca> Trevinho: flexiondotorg: what's the relation between your telegram snap and sergiusen's?
<Trevinho> Chipaca: none..
<Trevinho> Chipaca: sergio's one takes the upstream built telegram and ships it
<Trevinho> mine takes upstream code, and builds it as telegram does
<Trevinho> it doesn't sign the binary of course, as it's something they only can do
<zyga-ubuntu> pedronis: 3619 updated
<pedronis> zyga-ubuntu: did you change anything in core/repo ?
<zyga-ubuntu> pedronis: I'm adding {plug,slot}.Sanitize
<zyga-ubuntu> and making Sanitize{Plug,Slot} optional :D
<pedronis> in the branch ?
<zyga-ubuntu> yep
<pedronis> but not yet?
<zyga-ubuntu> I just pushed the initial huge patch in case I missed something there
<zyga-ubuntu> in a moment
<pedronis> cachio: hi, I'm getting this unrelated errors on this branch, quite regularly:  https://travis-ci.org/snapcore/snapd/builds/257198925?utm_source=github_status&utm_medium=notification  do IÂ need to merge branch or they new problems
<cachio> pedronis, taking a look
<pedronis> merge trunk
<magicaltrout> hello folks
<magicaltrout> random snap creation question
<magicaltrout> if I use the maven plugin to build some archive
<magicaltrout> can i then use something to extract the finished tarball?
<magicaltrout> or use the dump plugin to extract stuff from a previous part?
<ogra_> snapcraft keeps every by-product around after build ... so yes, if there is a tarball created, you will find it somewhere in your build directory
<ogra_> btw, http://rocket.ubuntu.com is probably the better place for snapcraft questions
<ogra_> (there is a #snapcraft channel)
<magicaltrout> aww but that involves more browser tabs
<ogra_> snap install rocketchat-desktop
<ogra_> ;)
<ogra_> no tabs needed
<mup> PR snapcraft#1403 closed: lxd: Only remove container if one exists <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1403>
<ogra_> morphis, hey
<morphis> ogra_: hey
<ogra_> morphis, could i bribe you for a second ack on https://github.com/snapcore/pi3-gadget/pull/11 (already tested and ondra reviewed and approved it already)
<mup> PR pi3-gadget#11: build uboot from source, pull blobs from upstream, use dtbs from archive <Created by ogra1> <https://github.com/snapcore/pi3-gadget/pull/11>
<morphis> ogra_: sure
<morphis> will have a look in a bit
 * ogra_ hugs morphis 
<morphis> :-)
<zyga-ubuntu> fg
<zyga-ubuntu> bg
<zyga-ubuntu> ah
<zyga-ubuntu> darn )
<ogra_> pick the middle ground ... thats the best compromise
<fgimenez> cachio: you can point the suite to staging with "export SPREAD_REMOTE_STORE=staging" before executing
<cachio> fgimenez, ok, thanks
<fgimenez> cachio: np, this is the forum post with the beta validation details https://forum.snapcraft.io/t/core-snap-validation-process-at-beta-channel/1454
<cachio> fgimenez, great!!!
<fgimenez> zyga-ubuntu: this is the error in the orangepi using the latest core from edge https://forum.snapcraft.io/t/how-to-use-spread-to-test-ubuntucore-image/1323/44?u=fgimenez
<fgimenez> zyga-ubuntu: if you could take a look that would be great, it seems to pass with core from beta
<zyga-suse> ack
<zyga-suse> I'll check it out after lunch
<fgimenez> zyga-suse: great, thanks!
<zyga-suse> mvo: did you push that parser branch by any chance?
<zyga-ubuntu> mvo: we hit the hook issue again
<zyga-ubuntu> - Run install hook of "core" snap if present (internal error: no registered handlers for hook "install")
<zyga-ubuntu>  :/
<pedronis> zyga-ubuntu: is that on a revert?
<zyga-ubuntu> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-image/zesty/amd64/s/snapd/20170727_125232_a75a6@/log.gz
<zyga-ubuntu> upgrade/basic
<mvo> zyga-ubuntu: meh, how annoying
<zyga-suse> feels like a blocker to me
<zyga-suse> we need to understand what is going on
<fgimenez> it happened on amd64 this time, yesterday it was i386
<zyga-ubuntu> I think it is random
<zyga-ubuntu> something is racing there
<ogra_> hmm
<ogra_> ogra@styx:~/tmp$ snap run --shell hello-world
<ogra_> To run a command as administrator (user "root"), use "sudo <command>".
<ogra_> See "man sudo_root" for details.
<ogra_> why do i get that sudo hint ?
<Chipaca> of course the only path I didn't unit test has a off-by-one panic
<zyga-suse> huh, interesting
 * Chipaca hugs everything
<zyga-suse> is that done by profilerc perhaps?
<zyga-suse> hehe
<Slashman> hello, I'm stuck on debian 9 after "snap install lx" with "[/] Run configure hook of "core" snap if present", any idea how I can solve this?
<zyga-suse> Slashman: hey
<zyga-suse> hmm
<zyga-suse> mvo: ^
<zyga-suse> Slashman: I think rebooting will just fix that
<zyga-suse> and after that it will work OK
<Slashman> zyga-suse: ok, I wanted to avoid that but oh well
<zyga-suse> techincally
<ogra_> well, it is a bug ...
<zyga-suse> try this:
<zyga-suse> sudo umount /run/snapd/ns/core.mnt
<Slashman> too late, I just rebooted :p
<zyga-suse> ah
<zyga-suse> :D
<zyga-suse> ok
<zyga-suse> anyway, rebooting is easier to explain
<zyga-suse> ogra_: yes, but a pretty obscure one
<zyga-suse> it's not obvious what is going on
<ogra_> yeah, i just meant to say that it isnt normal that you have to reboot for anything *snap
<Slashman> hm, now I have 'error: cannot install "lxd": snap "lxd" has changes in progress'
<Slashman> snap list doesn't list lxd
<zyga-suse> Slashman: what does snap changes say?
<Slashman> "1    Doing   2017-07-27T14:51:42Z  -                     Install "lxd" snap"
<zyga-suse> snap change 1
<Slashman> https://apaste.info/GmKr
<zyga-suse> Slashman: is it stuck there now?
<zyga-suse> you can perhaps kill snapctl process (it should be stuck somewhere)
<Slashman> how can I know ?
<zyga-suse> that will unblock it
<zyga-suse> it should finish in a few seconds
<zyga-suse> if not it's the bug
<Slashman> snapctl is already dead it seems: https://apaste.info/1hOT
<Slashman> well I killed it
<Slashman> not sure if the error are a real issue: https://apaste.info/rut0
<zyga-suse> hmmm
<zyga-suse> man
<zyga-suse> mvo: ^^
<Slashman> https://apaste.info/qrre
<zyga-suse> yeah it's gone
<zyga-suse> please unmount /run/snapd/ns/core.mnt
<zyga-suse> sudo snap install core
<zyga-suse> and let's see if that works
<zyga-suse> which version of snapd are you on right now? 2.21 something?
<mvo> Slashman: what is the output of "snap version"?
<Slashman> yeah, the one on debian 9
<Slashman> 2.21-2
<mvo> Slashman: "snap version" may give different numbers, snapd will try to use bits from the core if it can
<Slashman> ok, here is the output: https://apaste.info/Vqic
<zyga-suse> ok
<zyga-suse> mvo: again
<zyga-suse> same case as https://forum.snapcraft.io/t/simplenote-snap-cannot-stat-var-lib-snapd-seccomp-bpf-no-such-file-or-directory/1446/9
<Slashman> anyway I can make it work?
<mvo> zyga-suse: yeah, snapd restarted, configure failed and it reverted to 2.21 but did not restart the new snapd
<mvo> Slashman: sudo systemctl restart snapd should bring it back to normal operation. then "snap install core"  - would be interessting to see if that works
<ogra_> what a mess :(
<mvo> yes, re-exec has a problem we have not found yet on debian
<Slashman> seems to work, one strange info message but I see the core snap: https://apaste.info/1z60
<Slashman> trying lxd now
<ogra_> devmode ?!?
<mvo> Slashman: and snap version should how now that you are on 2.26.14 - does it do that?
<Slashman> indeed
<zyga-suse> ogra_: that's been fixed post 2.21, I think new snapd will correct that
<mvo> Slashman: could you try something trivial like snap install hello ?
<ogra_> ah, k
<Slashman> I just installed the lxd snap
<ogra_> irritating though ... :)
<mvo> Slashman: even better!
<Slashman> mvo: https://apaste.info/olsa
<mvo> zyga-suse: I suspect it has something to do with "snap install $thing" without core, i.e. the implicit download of core
<zyga-suse> mvo: we need a debian-9 out of the box test ra
<zyga-suse> mvo: yes
<zyga-suse> mvo: I agree
<mvo> Slashman: yes, that looks better :)
<zyga-suse> mvo: note that we don't have a debian 9 linode image
<mvo> zyga-suse: yeah, I have a debian-9 and couldn't find a way to reproduce the error in there :/
<Slashman> so, if I understand correctly, after snap installation, I should: 1) reboot 2) snap install core 3) systemctl restart snap 4) snap install core ?
<ogra_> Slashman, normally not ... but yes
<zyga-suse> Slashman: I think we don't know yet
<ogra_> :P
<zyga-suse> Slashman: umounting one special file and restarting snapd is the trick
<zyga-suse> but we're hazy on the details
<ogra_> Slashman, the normal behaviour is that you snap install lxd and it automagically pulls in core first without you having to do anythinng
<Slashman> yeah, I understand that's not the normal behavior :D
<Slashman> but until it is fixed, I'll have to document it my team doesn't get stuck trying to install it
<Slashman> anyway, thank you for your help guys!
<mup> PR snapd#3630 opened: many: implement "snap logs" <Created by chipaca> <https://github.com/snapcore/snapd/pull/3630>
<zyga-suse> Slashman: thank you for reporting this, we're sorry for the bad experience
<Chipaca> ^ "snap logs" \o/
<zyga-ubuntu> Chipaca: nice!!
<Chipaca> favourite thing i learned: http.Flusher
<Chipaca> (making "snap logs -f" nice an' responsive)
<zyga-suse> what is it?
<Slashman> zyga-suse: don't worry about it, I'm grateful that snap exists ;)
<zyga-suse> flush an ongoing log?
<zyga-suse> like tail -f?
<zyga-suse> Slashman: thank you! :-)
<Chipaca> zyga-suse: http.ResponseWriter can optionally also be an http.Flusher
<Chipaca> zyga-suse: if it is, then you can call w.Flush()
<Chipaca> and it flushes the writer
<Chipaca> the default writers are flushers
<Pharaoh_Atem> ð©
 * Chipaca hugs Pharaoh_Atem 
<Pharaoh_Atem> ð«
<Chipaca> Pharaoh_Atem: what's wrong?
<Pharaoh_Atem> I was working late last night on a maint window and it went wrong
<Chipaca> ouh :-(
<zyga-suse> ouch
<Pharaoh_Atem> so now I'm really tired today
 * Chipaca sends cake
<mvo> fgimenez, cachio: 2.27~rc4 for testing is now available in beta
 * mvo hugs Pharaoh_Atem
<Pharaoh_Atem> zyga-suse: I don't suppose you've fixed 32-bit arches for fedora yet on snap-seccomp>
<Pharaoh_Atem> ?
<mvo> Chipaca: nice, I learned something new!
<Pharaoh_Atem> zyga-suse: it's the same thing that bit us before with snap-confine a long time back
<zyga-suse> no, I'm still burried
<zyga-suse> sorry :/
<Pharaoh_Atem> zyga-suse: could you please fix it before mvo makes 2.27?
<Pharaoh_Atem> I'd really rather not have to skip 2.27 :(
<mcphail> Is it safe to remove old revisions of the core snap?
<zyga-suse> yeah, I think it should be easy
<zyga-suse> mvo: when do you want to tag 2.27?
<zyga-suse> mcphail: yes
<mcphail> zyga-suse: thanks!
<Pharaoh_Atem> we should also probably add an i686 fedora test
<Pharaoh_Atem> to make sure we don't break this again
<zyga-ubuntu> I don't know if we have a compatible i386 image in linode today
<zyga-ubuntu> but totally agreed otherwise
<zyga-suse> pedronis: pushed with all the stuff I wanted
<zyga-suse> oh wow
<zyga-suse> github has a new "jump to symbol" feature!
<pedronis> sorry chasing something completely different
<zyga-suse> pedronis: no worries
<zyga-suse> -1449 +618
<zyga-suse> my fingers hurt
<ogra_> from running rm ?
<ogra_> :P
<zyga-suse> I think pawel's work will be easier now
<zyga-suse> 1722 removed
<zyga-suse> only 24 actual non-empty sanitize functions left
 * zyga-ubuntu -> coffee 
 * genii sips
<fgimenez> mvo: \o/ thanks a lot, cachio want to give it a try? :)
<cachio> fgimenez, mvo sure, I'll do
<cachio> fgimenez, starting now
<fgimenez> cachio: great thanks a lot, pls let me know how it goes and if i can be of any help, i think the forum post has all the details, let's see
<cachio> fgimenez, I'll follow that
<fgimenez> cachio: cool thank you
<cachio> fgimenez, yaw
<mup> PR snapd#3631 opened: tests: apply underscore convention for SNAPMOUNTDIR variable <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3631>
<zyga-ubuntu> mvo: do you intend to investigate the debian issue?
<zyga-ubuntu> if not I can pick that up
<zyga-ubuntu> Chipaca: why don't you write longer commit messages?
<cachio> mvo, if you have 1 minute to look at PR 3631
<cachio> it is trivial but large
<zyga-ubuntu> cachio, mvo: note that I'd like to squash merge it
<zyga-ubuntu> there's a lot of junk in the history for a patch like that
<cachio> zyga-ubuntu, yes, trying to fix that
<cachio> not sure why it is showing the history
<zyga-ubuntu> I can explain later, for now it's just a matter of squash merging that
<cachio> but most of the commits are already merged
<zyga-ubuntu> alternatively you can squash locally and push that over
<cachio> zyga-ubuntu, i'll try that
<zyga-ubuntu> cachio: git rebase -i origin/master
<zyga-ubuntu> squash everything
<zyga-ubuntu> and reuse the commit message from the PR (I edited it)
<zyga-ubuntu> cachio: also if you do this, please pull
<zyga-ubuntu> cachio: I pushed one patch into your branch
<zyga-ubuntu> cachio: did you force push?
<zyga-ubuntu> cachio: my commit is gone and the whole history is there still
<cachio> zyga-ubuntu, I found the problem why it is showing all the commits
<cachio> one sec
<cachio> zyga-ubuntu, I'll create a new Pr
<zyga-ubuntu> cachio: stop
<zyga-ubuntu> cachio: why?
<zyga-ubuntu> cachio: let me show you how to fix this, ok?
<zyga-ubuntu> cachio: do you want to hop on a hangout?
<cachio> I had differences between origin/master and upstream/master
<zyga-ubuntu> cachio: (why do you think a new PR is needed)
<zyga-ubuntu> anyway
<cachio> zyga-ubuntu, so I reset my master and then merged
<zyga-ubuntu> mmm
<zyga-ubuntu> why didn't you do what I said earlier?
<zyga-ubuntu> git fetch origin; git rebase -i origin/master; squash everything
<zyga-ubuntu> you have one commit then
<zyga-ubuntu> you can review it to ensure it's sane
<zyga-ubuntu> then push that over this
<cachio> zyga-ubuntu, tried, but ti was not fixing the root cause
<zyga-ubuntu> in which way?
<zyga-ubuntu> can we do that together?
<zyga-ubuntu> cachio: I'll join the standup HO
<cachio> just a minute, letme try to rebase the branch
 * zyga-ubuntu takes a break and will look at the hook issue breaking everything on master now
<zyga-ubuntu> I wonder why it doesn't show up in spread linode, just autopkgtest
<zyga-ubuntu> mvo: can this be related to autopkgtest talking directly to DC vs the CDN?
<zyga-ubuntu> and getting some weird different copy of the core?
 * zyga-ubuntu installs debian 9 to explore the bug
<cachio> Chipaca, could you please take a quick view to the PR 3631
<cachio> Chipaca, I would like to merge it asap  :)
<mup> PR snapcraft#1424 opened: Release changelog for 2.33 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1424>
<cachio> Chipaca, there?
<mup> PR snapcraft#1425 opened: options: properly handle missing compiler prefix <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1425>
#snappy 2017-07-28
<janisozaur> hi
<janisozaur> has anyone been successful in establishing opengl context from a snap on Arch Linux?
<janisozaur> yesterday I tried and nothing really worked, not even glxinfo
<janisozaur> it either crashed (on a host with nvidia + binary drivers) or reported an error (host with Intel GPU)
<janisozaur> the very same snap worked, however, in a ubuntu artful VM
<janisozaur> I tried specifying LIBGL_DRIVERS_PATH to the correct ($SNAP/usr/lib/x86_64-linux-gnu/dri) directory, but that didn't help
<janisozaur> has anyone been able to run e.g. glxgears on Arch? How can I help debug?
<janisozaur> hmm, perhaps my Arch system did not offer OpenGL slot properly?
<Chipaca> janisozaur: I think the guy that knows (or remembers) most about that is zyga
<Chipaca> s/guy/person/
<janisozaur> yeah, i saw his comments on issue trackers
<janisozaur> can he be met round these parts?
<zyga-ubuntu> re!
<zyga-ubuntu> man, I thought it is Saturday
<janisozaur> hi zyga-ubuntu
<zyga-ubuntu> hey
<janisozaur> I'm having issues running opengl snaps on my Arch systems
<zyga-ubuntu> using nvidia proprietary drivers or anything else?
<janisozaur> one machine with Intel reports errors in glxinfo, the other with nvidia just segfaults
<zyga-ubuntu> can you please describe this in detail on forum.snapcraft.io
<zyga-ubuntu> the nvidia issue is probably more well known
<zyga-ubuntu> the intel issue new to me
<janisozaur> I'm not around these machines right now, but I'm available for debugging in the evening
<zyga-ubuntu> there are some people working on improving opengl snap support (alberto) but it's not even a PR yet
<zyga-ubuntu> janisozaur: if you can stick around for some time (days) and help us understand the issue I'll make sure the solution is working and tested on arch
<zyga-ubuntu> unfortunately many opengl problems are hard to test for us (lots of distros and virtualization complexity)
<zyga-ubuntu> also the design we have now is pretty old and we learned about some of the issues
<zyga-ubuntu> so we really need people with hands-on access to the given distribution and hardware
<zyga-ubuntu> your help can be really invaluable to us
<janisozaur> sure, i'll try helping with that
<janisozaur> is there any debugging FAQ for snaps?
<janisozaur> I only started using them yesterday
<zyga-ubuntu> some but some issues are more complex than others
<zyga-ubuntu> as a few hints:
<zyga-ubuntu> you can look at the output of snapd systemd unit
<zyga-ubuntu> (journalctl -u snapd)
<zyga-ubuntu> that tells a lot about what is going on in the background
<zyga-ubuntu> you can also set SNAP_CONFINE_DEBUG=yes to see what's going on at application startup
<zyga-ubuntu> lastly snap version is the key thing many people will ask about
<zyga-ubuntu> the arch maintainer is, I believe, not updating the package lately,
<zyga-ubuntu> we don't have automatic regression tests for arch yet so we don't know if it's working really
<zyga-ubuntu> if you want to help in any of that it's all something I can guide you with
<zyga-ubuntu> we have automatic regression tests for debian, ubuntu, fedora and opensuse now
<zyga-ubuntu> and arch is not far away
<janisozaur> sounds like something i could maybe look into
<zyga-ubuntu> btw, what is the current version of snapd on arch?
<zyga-ubuntu> I have an arch VM and I can dual-boot on one of my laptops
<zyga-ubuntu> and I was working on small updates to the package
<janisozaur> the snap i was creating worked fine in ubuntu artful VM
<zyga-ubuntu> now with 2.26.14 released and upcoming 2.27 I think it would make sense to update everything
<janisozaur> it probably was using swrast, though
<zyga-ubuntu> yes, I suspect so
<janisozaur> https://www.archlinux.org/packages/community/x86_64/snapd/
<janisozaur> 2.26.1
<zyga-ubuntu> not too far off
<zyga-ubuntu> but the package can use some love
<zyga-ubuntu> as we added some new features lately
<zyga-ubuntu> and last time I looked they were not supported in arch yet
<zyga-ubuntu> how about this, let's talk later today or over weekend
<zyga-ubuntu> let's start a thread in the forum
<zyga-ubuntu> on arch package update
<zyga-ubuntu> and on opengl
<zyga-ubuntu> I'll let you start the one on opengl and I'll quickly start the one on arch package update
<zyga-ubuntu> and we can discuss there
<zyga-ubuntu> the forum is really nice, works paritally like a mailing list and partially like IRC (being in real time) and it scales better than IRC (timezones/offline problems)
<janisozaur> sure, i should be available at ~1730 CEST
<zyga-ubuntu> how does that sound?
<zyga-ubuntu> perfect
<zyga-ubuntu> I should be available all day (I'm in europe too), just may be offline for some moments
<janisozaur> great!
<zyga-ubuntu> janisozaur: https://forum.snapcraft.io/t/updates-to-snapd-package-on-arch/1467
<zyga-ubuntu> janisozaur: feel free to comment there!
<zyga-ubuntu> note that I used the "snapd" category as this involves snapd itself
<zyga-ubuntu> and "arch" tag (along with some other tags I use to organize my tasks)
<zyga-ubuntu> so if you create a post about opengl you can also use the "arch" tag to group posts this way
<jamesh> Is there any way to get the CI tests to rerun for my pull request?  I got a failure onlinode:ubuntu-14.04-64:tests/main/econnreset and it isn't clear how my changes could have caused that
<zyga-ubuntu> jamesh: I think it's not your fault, I think that test is flaky
<zyga-ubuntu> jamesh: but to answer your question, if you look for that id (ubuntu-14.04-64....) in the log you will see a *fold* that has the details of the error
<zyga-ubuntu> jamesh: and just below it another fold that has lots of debug information
<jamesh> zyga-ubuntu: right.  I read the CI log, and couldn't see how my changes impacted it
<zyga-ubuntu> jamesh: I think though, as I said, that that test is racy and sometimes fails incorrectly
<zyga-ubuntu> jamesh: if you re-run it it will likely pass
<zyga-ubuntu> though today master feels broken (on autopkgtests) as something odd has regressed in one of the upgrade tests after the 2.26.14 stable release
<zyga-ubuntu> I've been investigating that last night but no conclusions yet
<jamesh> zyga-ubuntu: do I need to make a trivial commit to get it to rerun, or is there a button to trigger it again?
<zyga-ubuntu> jamesh: what's the PR URL?
<zyga-ubuntu> jamesh: you can re-trigger from the UI
<Chipaca> jamesh: you don't have a "restart" at the top of the travis output?
<jamesh> zyga-ubuntu: https://github.com/snapcore/snapd/pull/3581
<mup> PR snapd#3581: Add polkit authorization support to /v2/login <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3581>
<zyga-ubuntu> (or maybe you cannot but I can help)
<zyga-ubuntu> jamesh: all tests passed there
<Chipaca> um
<Chipaca> yeah
<jamesh> Chipaca: no.
<Chipaca> jamesh: tests are all green
<jamesh> doh.  Hadn't reloaded the page.
<jamesh> so many other things seem to auto-update on github, but that didn't.
<jamesh> sorry for the noise
<Chipaca> jamesh: the auto-update breaks if the network hiccups, apparently
<jamesh> Chipaca: I guess the restart button only shows up for core developers?
<Chipaca> jamesh: maybe you need to log into travis?
<jamesh> Chipaca: I am logged in
<Chipaca> ah
<Chipaca> then maybe
<jamesh> It's not a big deal
 * zyga-ubuntu hits the road, will be off IRC today often
<zyga-ubuntu> Chipaca: hey
<Chipaca> zyga-ubuntu: wut
<Chipaca> zyga-ubuntu: hey :-)
<zyga-ubuntu> Chipaca: I plan to spend the day 1/3 on reviews 1/3 on master regression and 1/3 on mvo's SPDX parser
<zyga-ubuntu> do you need my help on anything?
<Chipaca> zyga-ubuntu: how do you divide 8 hours into thirds
<zyga-ubuntu> Chipaca: easy, just start with 12 hours
<zyga-ubuntu> everything is easy to divide then D:
<Chipaca> zyga-ubuntu: aw :-(
<zyga-ubuntu> I like languages with rational numbers
<Chipaca> zyga-ubuntu: the right answer is that it divides into 3 2-hour chunks, and a spanish lunch break
<zyga-ubuntu> 8/3 is such a nice construct
<Chipaca> zyga-ubuntu: other than a review, which is already on your list, i don't think i need anything
<zyga-ubuntu> Chipaca: the logs PR? or something else as well?
<Chipaca> zyga-ubuntu: sorry about my commit messages falling in quality. The first pass at this work I took the effort of doing them properly.
<zyga-ubuntu> Chipaca: I know that's extreme but I really like LKLM style commits
<Chipaca> the second pass i also did a fairly good job at keeping the commits tight and the messages clean
 * Chipaca looks for a link to show he isn't making it up (maybe)
<Chipaca> gah
<Chipaca> i might've been making that up after all
<Chipaca> https://github.com/snapcore/snapd/pull/3549/commits
<mup> PR snapd#3549: many: expose services commands for snap services <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3549>
<Chipaca> anyway
<Chipaca> zyga-ubuntu: i'm aware of making them better, and I'll continue improving them
<Chipaca> some days it's harder than others
<zyga-ubuntu> Chipaca: thanks, that's all I ask for :)
<mup> PR snapd#3631 closed: tests: apply underscore convention for SNAPMOUNTDIR variable <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3631>
<Chipaca> :-)
<zyga-ubuntu> Chipaca: I was just wondering if we can land "snap logs" today
<zyga-ubuntu> that shiny green button there
<Chipaca> zyga-ubuntu: just a simple matter of reviews and addressing issues found therein
<zyga-ubuntu> I mean do we have enough +1 votes with mvo and gustavo being off
<zyga-ubuntu> Chipaca: on that topic, I have one monster PR https://github.com/snapcore/snapd/pull/3619
<mup> PR snapd#3619: interfaces/builtin: reduce duplication and remove cruft in Sanitize{Plug,Slot} <Created by zyga> <https://github.com/snapcore/snapd/pull/3619>
<Chipaca> ah yes
<Chipaca> i was 3/8 through that the other day :-p
<zyga-ubuntu> that's a monster PR, sorry
<zyga-ubuntu> but you can go patch-by-patch
<zyga-ubuntu> it's actually easier to follow this way
<Chipaca> zyga-ubuntu: you mean commit-by-commit?
<zyga-ubuntu> Chipaca: yes
<Chipaca> zyga-ubuntu: you're aware it's 12 commits?
<Chipaca> if I +1 a commit, is github smart enough or does it think I +1'd the PR?
<zyga-ubuntu> Chipaca: GH doesn't support that (not gerrit) *but* you can open 12 tabs and just read one by one
<zyga-ubuntu> and only give +1 if you found nothing wrong
<Chipaca> yeah, doing that
<zyga-ubuntu> but you can easily comment on each patch and GH handles that nicely
<zyga-ubuntu> thanks, I'm reading logs now
<Chipaca> zyga-ubuntu: is there a reason the repo itself doens't do the ensureSlotIfaceMatch(iface, slot) before calling SanitizeSlot?
<zyga-ubuntu> Chipaca: yes, read on
<Chipaca> ok
<zyga-ubuntu> Chipaca: it's rolled into {plug,slot}.Sanitize
<zyga-ubuntu> and also somewhat silly since repo does plug.Interface lookup
<zyga-ubuntu> so it's a no-op test if the compiler is smart enough
<pedronis> zyga-ubuntu: which btw reminds, checking if a slot is for a given snap types is also done by base declaration, so maybe is something else that can go away, but that I think you should discuss with jdstrand
<zyga-ubuntu> pedronis: I think it's fine to keep as is, we don't check base declaration for sideloaded snaps, do we?
<zyga-ubuntu> pedronis: and the check is really really small now, just two lines in all of the tree
<pedronis> we don't indeed
<zyga-ubuntu> pedronis: and I'm very happy I took your suggestion: so much code got removed
<zyga-ubuntu> pedronis: vast majority of sanitize functions are out
<zyga-ubuntu> I think pawel will be happy as there will be less things for him to edit
<zyga-ubuntu> (really, going through 190 files to do one change is heart wrenching)
<pedronis> zyga-ubuntu: why did you change the errors to say operating system ?Â instead of core ?
<zyga-ubuntu> oh, not sure, I think I just unified it (it said various things)
<pedronis> mmh
<zyga-ubuntu> but we can now tweak it either way easily
<pedronis> I think  we need to say either "core snap"  or operating system (without snap)
<pedronis> but I fear that becomes a Gustavo's question
<zyga-ubuntu> aha, indeed
<zyga-ubuntu> I'm fine with core snap for now and I'll ask gustavo next week
<Chipaca> zyga-ubuntu: +1'ed with a suggestion
<zyga-ubuntu> I'll finish the review for chipaca and then I'll update
<zyga-ubuntu> Chipaca: woot, thank you!
<zyga-ubuntu> (that was fast!)
<Chipaca> zyga-ubuntu: reading the commits indeed made it fast
<Chipaca> a lot of it was repepepetititve
<Chipaca> zyga-ubuntu: and i know logs would've been easier to read in (at least) three separate commits :-(
<zyga-ubuntu> and all hand made, I tried to automate it but then just decided not to as the result wasn't perfect
<Chipaca> zyga-ubuntu: what are the autopackage failures on your pr about?
<pedronis> zyga-ubuntu: it's also interesting  that some had the comment "s allowed only by a gadget or os snap" but then allowed only os
<pedronis> zyga-ubuntu: maybe it would be good to cross check with the base decl?
<pedronis> actually there should be a way to write a generic test helper like that
<pedronis> maybe
<zyga-ubuntu> Chipaca: no idea, I'm checking that
<zyga-ubuntu> something broke with hooks
<zyga-ubuntu> not sure yet, I cannot reproduce, I plan to check if hook handler names changed lately
<zyga-ubuntu> pedronis: yes, but I choose to keep the semantics of the code now, I think we can review who can do what
<zyga-ubuntu> pedronis: good idea about cross checking with base declaration
<pedronis> zyga-ubuntu: actually I alread had a test like that
<pedronis> :)
<pedronis> zyga-ubuntu:  func (s *baseDeclSuite) TestSlotInstallation logic about compareWithSanitize seems to do that
<pedronis> or at leat a part of that
<pedronis> now that I read better
<pedronis> anyway seems something could be done there
<pedronis> or based on that
<pedronis> zyga-ubuntu: btw IÂ just noticed that the various definer interfaces in the backends have the same problem Chipaca mentioned
<zyga-ubu1tu> pedronis: aha, thank you, I will check it out
 * zyga-ubu1tu looks at Chipaca's review
<zyga-ubu1tu> pedronis: I started with public interfaces but Gustavo at the time wanted private ones
<pedronis> we have a bunch of essentially secret interfaces atm
<zyga-ubu1tu> pedronis: if they were public I'd have an easier life in some tests
<zyga-ubu1tu> pedronis: I can make a RFC PR with just the private -> Public switch for htem
<pedronis> I'm not sure what the reasoning was
<zyga-ubu1tu> I don't remember anymore
<pedronis> usually secret interfaces are for tightly coupled internal helpers
<zyga-ubu1tu> I think it was not perceived as necessary as they were only used by the backends
<pedronis> and usually then the methods are also private
<zyga-ubu1tu> I see
<pedronis> well, but the interfaces need to implement them
<pedronis> and the doc don't have a signature of what they need to implement
<pedronis> I find it strange as Chipaca did here
<zyga-ubu1tu> right, I think they could be public
<zyga-ubu1tu> eh, IRC, the protocol for wired mainframes
<pedronis> zyga-ubuntu: at least  the various methods would need to mention them in the docs
<pedronis> also the docs look strange
<pedronis> in the backends, like copy-paste strange
<zyga-ubuntu> yes, many of the interfaces have copy pasted stuff
<zyga-ubuntu> just little by little :)
<pedronis> like mount-specific  in apparmor?
<zyga-ubuntu> I'd happily remove useless docs
<zyga-ubuntu> I think I even noticed that a few months ago when doing a pass
<zyga-ubuntu> just forgot to correct it at the time
<pedronis> zyga-ubuntu: anyway +1 apart "core snap"Â and agreeing with Chipaca
<zyga-ubuntu> ack, thank you
<popey> ogra_: finaly got my serial cable hooked up to my nano pi. it only sees eth0 and not the wireless interface :(
<popey> ogra_: any ideas how I can get in and get it on the wifi, as I'm stuck in subiquity right now
<popey> lornajane: heya, couchdb landed in the snap store last night :)
<lornajane> popey: so twitter tells me :)  But I tried to install it and now I have questions
<lornajane> when I install a snap, how can I tell whether it has created me some commands, and what those are/do?
<lornajane> if it starts daemon things, how can I tell what those are and what services I can now start/stop?
<zyga-ubuntu> lornajane: Chipaca can help you!
 * Chipaca hides
<ogra_> popey, stop the boot at the uboot countdown
<lornajane> awesome :)  Long-time ubuntu user, but new to snaps and not really a sysadmin so I think my questions are newbie ones - but I promise to blog what I learn so hopefully will head off future newbie questions
<zyga-ubuntu> lornajane: \o/
<Chipaca> lornajane: _right_ now, there's not a super simple way. For services, systemctl status snap.<tab> should help.
<zyga-ubuntu> lornajane: also we have a very nice forum on forum.snapcraft.io
<ogra_> popey, then: setenv mmcargs 'setenv bootargs "console=ttyS0,115200 root=${mmcroot} init=/bin/bash"'
<ogra_> popey, then: saveenv; reset
<Chipaca> lornajane: really soon (1 or at most 2 releases away) there'll be a simplified interface so you don't need to look at systemctl unless you want to
<ogra_> popey, that should give you a prompt after boot
<Chipaca> but, today, that's what there is
<lornajane> I can manage systemctl, and I did realise there was a process running
<lornajane> it's not attached to the port I would expect though, and I don't know how to help it
<Chipaca> lornajane: and once you know the unit name, journalctl -u <that name> will show you logs
<Chipaca> lornajane: ah, that's down to the individual snap i'm afraid
<Chipaca> some'll let you configure it, some won't
<lornajane> oh poor thing is stuck in a loop
<Chipaca> aw
<lornajane> or maybe looped a bit when it started?  Hmm.  I notice that I have a couchdb command now but that is also unhappy
<popey> ogra_: ok, will play with taht thanks!
<lornajane> OK.  I'm not sure what to do next but I think it's couchdb-specific so I'll wander back over there and see if they can assist.  I'm so pleased though to see snappy stuff taking over the world :)
<popey> ogra_: yay, got a console prompt, now what? :)
<ogra_> popey, cat /proc/net/dev ... do you see a wlan device there ?
<popey> ogra_: no
<ogra_> popey, modprobe brcmfmac
<ogra_> and check in dmesg
<zyga-ubuntu> Chipaca: reviewed
<Chipaca> zyga-ubuntu: int((^uint(0)) >> 1) is only math.MaxInt64 on 64 bits
<Chipaca> zyga-ubuntu: there isn't a MaxInt
<Chipaca> :-(
<Chipaca> anyway, i'll comment on the PR when i get back from a run
 * Chipaca getting ready to go afk for a bit
<zyga-ubuntu> ah, Isee
<zyga-ubuntu> enjoy!
<zyga-ubuntu> I'll get to your feedback now
<Chipaca> uh, that println was debugging i needed to nuke
 * Chipaca goes afk
<popey> ogra_: [ 1247.038733] usbcore: registered new interface driver brcmfmac
 * zyga-ubuntu needs wording help
<zyga-ubuntu> pedronis:
<zyga-ubuntu> +// PlugSanitizer describes an interface that can sanitize plug instances.
<zyga-ubuntu> +type PlugSanitizer interface {
<zyga-ubuntu> WDYT?
<zyga-ubuntu> or just "that can sanitize plugs"
<ogra_> popey, any change in /proc/net/dev ? (or ifconfig)
<morphis_> zyga-ubuntu: there seems to be a problem on debian with latest snap-confine from 2.26.14
<morphis_> zyga-ubuntu: see https://github.com/anbox/anbox/issues/386
<morphis_> "snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks"
<pedronis> zyga-ubuntu: PlugSanitizer can be implemented by Interfaces that have a need to sanitize their plugs  ?
<pedronis> or "have reasons"
<zyga-ubuntu> morphis_: that machine must have apparmor enabled
<zyga-ubuntu> pedronis: nice, thank you!
<zyga-ubuntu> morphis_: (via boot command line argument)
<zyga-ubuntu> morphis_: but I'm aware of "something being off" on debian since we published the last stable snap, I intend to keep digging today, I cannot reproduce the problem yet (which drives me nuts)
<zyga-ubuntu> morphis_: we also know that once you are in the wedged state you are also affected by lack of reverse reexec
<morphis_> zyga-ubuntu: afaik we do --disable-apparmor on debian
<zyga-ubuntu> morphis_: no, that's not even it
<zyga-ubuntu> morphis_: the thing is that that message is *only* shown when the kernel has apparmor enabled (not just built but actually active) *and* snap-confine is not confined
<zyga-ubuntu> morphis_: may be a misalignment with snapd's appamror profile generation for core's snap-confine
<morphis_> zyga-ubuntu: but actually if we build snap-confine on debian with --disable-apparmor should that be respected when we re-exec?
<zyga-ubuntu> morphis_: but I haven't seen it before
<zyga-ubuntu> morphis_: no, remember that when we re-exec we use the one from core
<morphis_> right
<zyga-ubuntu> morphis_: so the compile time build option is not relevant
<morphis_> but it was the distro decision to disable AppArmor
<zyga-ubuntu> morphis_: can you reproduce that problem?
<morphis_> zyga-ubuntu: I can't, it's an anbox bug report from a user
<zyga-ubuntu> morphis_: is /sys/kernel/security/apparmor around?
<zyga-ubuntu> aha
<zyga-ubuntu> well, must be that then
<morphis_> feel free to comment on the report
<morphis_> it's just an hour old
<zyga-ubuntu> doing that now
<morphis_> thanks!
<pedronis> zyga-ubuntu: still lgtm,  don't know if Chipaca wants to chime in on the wording.
<zyga-ubuntu> morphis_: done
<zyga-ubuntu> pedronis: updated to what you suggested
<zyga-ubuntu> pedronis: I think chipaca might be back by the time tests finish
<morphis_> zyga-ubuntu: thanks
<popey> ogra_: nothing
<ogra_> popey, then i fear there is something missing in the devicetree file, the nanopi-air should use an ampak AP6212 http://linux-sunxi.org/Wifi AFAIK ... i guess the HW isnt properly initialized ... i'll have to dig a bit
<popey> ogra_: ok. lemme know if there's anything I can get off the device :)
<ogra_> popey, theer we go https://github.com/armbian/build/blob/master/patch/kernel/sun8i-dev/add-nanopi-neoair.patch
<popey> ogra_: so you need to make a new image with that patch?
<ogra_> popey, re-building my hackish allwinner kernel will take a while though, it is very fiddly ... but that seems to be the right patch top enable the AP6212
<popey> ok, great
<ogra_> s/top/to/
<ogra_> yeah, i need to make a new kernel
<popey> ok, I'l put him back in his box for now then :)
<popey> gimme a ping when you need me to test again :)
<ogra_> yeah, i'll try to get this done on the weekend
<popey> nice, thanks
<popey> beer++
<ogra_> :)
<Chipaca> pedronis: zyga-ubuntu: wording of what?
 * Chipaca still not fully back (mostly thinking about lunch right now)
<pedronis> Chipaca: zyga's branch,  doc comments for the new public interfaces
<Chipaca> ah, i thought that was to be separate because it needed discussion
<pedronis> Chipaca: ?
<Chipaca> pedronis: i thought as gustavo had originally said no to the public interfaces, zyga was going to make a separate pr to discuss it
<pedronis> Chipaca: in a different context
<pedronis> anyway pawel will need to redo this anyway
<pedronis> so another chance to argue one way or another
<zyga-ubuntu> re
 * zyga-ubuntu writes user docs
<zyga-ubuntu> Chipaca: just this https://github.com/snapcore/snapd/pull/3619/commits/f6fb74af3fcbcea7caa72ee645c169f9f33f962d
<mup> PR snapd#3619: interfaces/builtin: reduce duplication and remove cruft in Sanitize{Plug,Slot} <Created by zyga> <https://github.com/snapcore/snapd/pull/3619>
<Chipaca> zyga-ubuntu: hmmm
<Chipaca> zyga-ubuntu: i guess there's no way around interfaces vs interfaces :-)
<Chipaca> zyga-ubuntu: +1
<pedronis> yes, that is our self impose loss in the terminology battle
<zyga-ubuntu> hehe
<zyga-ubuntu> let's also add Channel so that we can have more confusion
 * zyga-ubuntu resumes writing docs
<zyga-ubuntu> writing docs is *fun*
<Chipaca> zyga-ubuntu: next feature we add is being able to expose only a subset of the full store to a device, something like a gadget-set filter
<Chipaca> zyga-ubuntu: we'll call that a "slice"
 * Chipaca runs for the hills
<zyga-ubuntu> Chipaca: slice and dice
<pedronis> interface, channel, slice       , map next?
<pedronis> we'll we dare to go where nobody has gone, and have features called "integers"Â and "bools"
<zyga-ubuntu> LOL :D
<zyga-ubuntu> map:\n\tbool:\n\t5
<Chipaca> registers and pointers, that's what's next
 * zyga-ubuntu writes stuff at https://forum.snapcraft.io/t/feature-snap-layouts/1471/2
<zyga-ubuntu> actually, I think this is a very good moment to take a break and eat lunch
<mup> PR snapcraft#1426 opened: tests: adapt opencv's test expectations <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1426>
 * Chipaca hunts for tea
<zyga-ubuntu> are we doing the standup today?
<Chipaca> yes
<Chipaca> omw
<Chipaca> bah, i think we are :-)
<Chipaca> pedronis: standup?
<cachio> pedronis, joining standup?
<Chipaca> pedronis: https://www.youtube.com/watch?v=pZG7IK99OvI !
<zyga-ubuntu> cachio: I'm reading your pastebin
<cachio> zyga-ubuntu, the failover tests are the one to see
<fgimenez_> cachio: about the test error in https://paste.ubuntu.com/25188524/ you should remove auto-refresh from the job definitions for the dragonboard executions on the lab, the post has the details
<fgimenez_> https://forum.snapcraft.io/t/core-snap-validation-process-at-beta-channel/1454
<zyga-ubuntu> error: cannot copy request into temporary file: write
<zyga-ubuntu>        /tmp/snapd-sideload-pkg-627586801: no space left on device
<zyga-ubuntu> This doens't look like that error
<zyga-ubuntu> looks like you ran out of space
<ogra_> not really out of space but out of ram
<cachio> fgimenez_, ok, the failover tests could be failed because of that?
<ogra_> since /tmp is a tmpfs
<ogra_> use TMPDIR and point to some place on disk
<fgimenez_> cachio: not sure, i ended up removing it because the whole suite started to fail after the auto-refresh error
<zyga-ubuntu> ogra_: indeed
<Chipaca> zyga-ubuntu: what would you call the const for the journal timestamp key?
<zyga-ubuntu> const magic = "__STUFF"
<zyga-ubuntu> as long as it is used >1
<zyga-ubuntu> the name isn't as relevant if it can stay private
<Chipaca> zyga-ubuntu: only other use is in the tests
<cachio> fgimenez_, zyga-ubuntu  I am running again the suite without the auto-refresh test
<cachio> i'll keep you updated
<kjackal_> hi everyone, how do I specify daemon dependencies? I want mysnap daemon to start after an optional service eg lxd.service
<ogra_> i dont think thats possible yet
<ogra_> (ICBW though)
<fgimenez_> cachio: great, by default tpr splits the suite in 4 parts, you need only to modify the part that includes auto-refresh (removing it) the rest of executions should be fine with the generated testflinger job definitions
<cachio> fgimenez_, yes, I forgot that :(
<kjackal_> ogra_: is there a way to manualy edit the systemd unit file?
<ogra_> nope
<ogra_> but you could use a wrapper script
<ogra_> i.e. have a single systemd unit that invokes the wrapper ... and have the wrapper start the daemons in the right order
<ogra_> ... as a workaround until such a feature is provided by snapd
<fgimenez_> cachio: np, the good thing of having the suite splitted in four is that you can run the dragonboard tests in parallel, so that it doesn't take >6h, each part takes 1-2h
<kjackal_> thanks ogra_
<fgimenez_> cachio: and because those are executed in the lab you can run other kvm and board tests locally
<cachio> yes
<cachio> fgimenez_, starting now with the pi's
<kjackal_> ogra_: is there a way to say i want my-snapped-service to start after all other services? like the Type=idle on systemd?
<fgimenez_> cachio: cool! let me know how it goes
<ogra_> kjackal_, not sure ... perhaps Chipaca knows, he played with systemd stuff a lot recently
<ogra_> but i think the bits we can define for systemd units are still pretty limited
<Chipaca> kjackal_: no, there isn't ordering yet
<ogra_> again though ... you can have a wrapper, use the system-observe interface to watch if something you wait for runs and sleep until it gets up
<Chipaca> kjackal_: and no support for Type=idle right now (although it _might_ work if you're sideloading)
<ogra_> (though that means manually connecting the interface)
<Chipaca> (I'd have to check)
<Chipaca> kjackal_: confirmed daemon: idle does not work
<kjackal_> Chipaca: ogra_: Just for some context, the questions I am asking have to do with this issue: https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/357 Where the kubernetes bundle will not work after rebooting the machine hosting a deployment of the bundle on lxd
<kjackal_> seems snap services should start after the lxd.service (if present) but they do not
<Chipaca> kjackal_: do you need a fix for the general problem, or for the particular instance?
<Chipaca> kjackal_: because you could drop a unit snipped in there
<ogra_> kjackal_, bug 1687079 ??
<mup> Bug #1687079: cannot change profile for the next exec call: No such file or directory <Snappy:Confirmed> <https://launchpad.net/bugs/1687079>
 * zyga-ubuntu solicits feedback on https://forum.snapcraft.io/t/feature-snap-layouts/1471/2
<kjackal_> ogra_: the bug is most probably related to what I see
<ogra_> yep
<ogra_> thats why i posted it :)
<kjackal_> Chipaca: since there are a bunch of services affected I would rather go for a generic solution (it affects practicaly all services)
<Chipaca> kjackal_: the lxd service the snap services are running are not part of the same snap?
<kjackal_> no, as I understand it, you have an lxd container that runs its services (including and lxd.service) and inside that container you want to deploy a snapped service eg etcd
<Chipaca> kjackal_: so you have lxd, and inside lxd you have snapd, and install a snap with it?
<Chipaca> that should just work, i don't see how it's a dependency
<kjackal_> Chipaca: it is not the install that fails. The failure comes after rebooting the host. After the reboot the mysnapped-daemon comes before the lxd.service (both running inside the lxd container)
<Chipaca> kjackal_: how can the mysnapped-daemon come up before the lxd service? the mysnapped-daemon is inside a container started by lxd
<kjackal_> Chipaca: wait, I am not explaining this correctly. Inside the lxd container there is an lxd service running.
<kjackal_> Chipaca: have alook here: http://pastebin.ubuntu.com/25190796/
<kjackal_> I ssh on a machine on AWS
<mup> PR snapcraft#1426 closed: tests: adapt opencv's test expectations <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1426>
<kjackal_> and then I juju ssh on an etcd/0 and ask for the lxd.service
<Chipaca> with you so far
<cachio> fgimenez_, the failover tests still failing after remobe the auto-refresh test
<cachio> fgimenez_, I'll dig into those
<cachio> niemeyer, there?
<fgimenez_> cachio: maybe something has changed in the lab, if they are the only failing tests you can run them locally on your db
<zyga-ubuntu> wat
<zyga-ubuntu> why is master not broken anymore
<zyga-ubuntu> WTF is going on :/
<kjackal_> Chipaca: ogra_: if I set the restart option to always is there a way to also set the delay between restarts (RestartSec=??? on systemd)
 * zyga-ubuntu merged interface sanitize change, cannot wait to patch other PRs now
<kjackal_> ?
<ogra_> zyga-ubuntu, want me to break it so you feel better ?
<zyga-ubuntu> ogra_: if you can break it the same way it used to be broken a moment ago? please !
<Chipaca> kjackal_: no
<mup> PR snapd#3619 closed: interfaces/builtin: reduce duplication and remove cruft in Sanitize{Plug,Slot} <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3619>
<ogra_> zyga-ubuntu, nah, thats not very creative ...
<Chipaca> kjackal_: you kinda wandered off mid-explanation back there
 * ogra_ would only break it in new and unexpected ways
<kjackal_> Chipaca: sorry about that there was the daily standup
<zyga-ubuntu> ogra_: indeed, it would be exactly very repetetive
<ogra_> cachio, fginther just run them with TMPDIR=/var/tmp ...
 * zyga-ubuntu looks at ondra's PR
<ogra_> err
<ogra_> s/fginther/fgimenez/
<kjackal_> Chipaca: So we were at the point where, inside an AWS machine I have an lxd container. Inside the container I have a snaped etcd running next to lxd.service
<Chipaca> kjackal_: i think we didn't get that far
<Chipaca> kjackal_: you ssh'd to a host, juju-ssh'd to another, and showed me the lxd.service
<Chipaca> i asusme juju-ssh is to a container
<kjackal_> Chipaca: Yes exactly (http://pastebin.ubuntu.com/25190796/)
<Chipaca> you also showed me that there wasn't an lxd.service in the "outside" host
<kjackal_> Chipaca: yes
<Chipaca> kjackal_: and it's in the "juju-ssh" container that you snap install something?
<kjackal_> Chipaca: I suspect the lxd on the host is packaged with the conjure-up snap
<kjackal_> Chipaca: yes
<Chipaca> kjackal_: and that thing you snap install depend son the lxd.service that runs on that same container?
<kjackal_> yes
<Chipaca> kjackal_: so you you "systemctl stop lxd.service", it dies?
<kjackal_> Chipaca: depends in the sence of a service/daemon
<Chipaca> it == the thing in the snap
<Chipaca> kjackal_: so, to be clear, I doubt very much there's going to be a way to be able to express this dependency in snapd any time soon
<kjackal_> Chipaca: I see so... what else can we do?
<kjackal_> Chipaca: thowing ideas, "Type=idle", "RestartSec=X"?
<zyga-ubuntu> ondra: hey
<ogra_> wrappers ;)
<zyga-ubuntu> ondra: I pushed to https://github.com/snapcore/snapd/pull/3624
<mup> PR snapd#3624: rework for avahi interface <Created by kubiko> <https://github.com/snapcore/snapd/pull/3624>
<Chipaca> kjackal_: does Type=idle fix the thing for you?
<ondra> zyga-ubuntu hey :)
<zyga-ubuntu> ondra: please look at my feedback and ping me if you want to talk
<ondra> zyga-ubuntu sorry I was off yesterday
<Chipaca> kjackal_: that might be the easiest
<kjackal_> Chipaca: it is a workaround
<Chipaca> clearly
<zyga-ubuntu> ondra: use go fmt, I changed 2/3 of your files after just saving them in vim :)
<Chipaca> but then, what you're wanting to do isn't supported
<ondra> zyga-ubuntu yeah I read then all good
<Chipaca> Â¯\_(ã)_/Â¯
<zyga-ubuntu> ondra: I resolved conflict after landing a small API change in master
<zyga-ubuntu> ondra: so you should be all good now
<ondra> zyga-ubuntu I have alerdady changes even
<ondra> zyga-ubuntu ahh you did it as well?
<Chipaca> kjackal_: but my question is whether it's a workaround that _works_ :-)
<zyga-ubuntu> ondra: well, I just said so on the PR :)
<zyga-ubuntu> ondra: pull, you should be fine
<Chipaca> if it's a workaround that leads to a race condition, then it's no good either
<kjackal_> Chipaca: tested it with etcd service and it works, yes
<zyga-ubuntu> (or rebase on top)
<Chipaca> kjackal_: but you said you had "a bunch"
<Chipaca> kjackal_: what happens if the whole bunch are all idle?
<zyga-ubuntu> ondra: feel free to iterate or stop as you see fit, I cna iterate on that next week as well
<ondra> zyga-ubuntu let's have a look next week
<kjackal_> Chipaca: If we identify this as a potential solution then I will need to test that before we commit to a fix/feature implementation
<ondra> zyga-ubuntu I did changes as per your comments, but then two of my tests were paninckin
<ondra> zyga-ubuntu and I was not able to figure out why
<zyga-ubuntu> ondra: ok, put a comment on the PR or here if you want some insta-hints
<kjackal_> Chipaca: can I ping you on monday with what I have? I am almost at EOD here
<Chipaca> kjackal_: so, the Type=idle thing is easy to implement at our end, but that's still a month away from you being able to use it
<zyga-ubuntu> Chipaca: unless edge
<zyga-ubuntu> Chipaca: then it's tomorrow :)
<Chipaca> kjackal_: so I think we can talk about whether allowing snaps to specify arbitrary After= lines is reasonable
<Chipaca> kjackal_: that's a day of discussion probably, but over a week away because our architect is on holiday
<Chipaca> I don't think it'd break anything conceptually to allow snaps to say After=bananas
<Chipaca> it's not a dependency, it doesn't pull in anything, it's just ordering
<ogra_> as long as the service is included in your snap at least
<Chipaca> although it can break a system :-(
<Chipaca> gah
<Chipaca> it can break a system by creating a loop
<ondra> zyga-ubuntu so those changes you pushed, are those just formatting changes?
<kjackal_> Chipaca: ogra_: After=?? would also need for Wants=???
<Chipaca> kjackal_: why? all you want is After=
<Chipaca> kjackal_: lxd is already being started, you just want to tweak the order
<Chipaca> anyway, it's for discussion with our architect, not for irc
<Chipaca> (and it's not super-obvious that it'll work)
<zyga-ubuntu> ondra: no, I resolved conflicts, fixed one more non-compiling-after-merge conflict (that git wasn't complaining about), re-formatted, dropped the Sanitize methods (empty, no longer needed)
<Chipaca> Wants= is super obvious to me that it's wrong for snaps
<zyga-ubuntu> ondra: that's all
<zyga-ubuntu> morphis: I'm going to push some changes to https://github.com/snapcore/snapd/pull
<morphis> zyga-ubuntu: which pull request?
<ondra> zyga-ubuntu so shall I rebased on your commit and to changes based on comments on top of that?
<kjackal_> Chipaca: sounds good Chipaca should we talk again towards the end of next week to setup a meeting?
<zyga-ubuntu> oh
<zyga-ubuntu> man
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/3623
<mup> PR snapd#3623: interfaces/builtin: implement broadcom-asic-control interface <Created by morphis> <https://github.com/snapcore/snapd/pull/3623>
<zyga-ubuntu> how did that happen
<Chipaca> kjackal_: sounds good
<zyga-ubuntu> ondra: yep, that sounds perfect
<morphis> zyga-ubuntu: what kind of changes?
<kjackal_> Thank you both Chipaca and ogra_
<ogra_> well, i was only shouting from the side-line ...
<zyga-ubuntu> morphis: I'll resolve conflicts and do small tweaks in line with recently landed huge interface cleanup PR
<morphis> ok
<Chipaca> ogra_: take your internet thank yous! they're tradeable for beer!!
<morphis> zyga-ubuntu: thanks!
<ogra_> Chipaca, noted ...
 * ogra_ puts in his bag
<zyga-ubuntu> just so that you and others don't have to wonder what to do after their branches break
<zyga-ubuntu> morphis: and rename the files, man, nobody noticed that !
<morphis> which files?
<ogra_> the wrongly named ones
<ogra_> :P
<zyga-ubuntu> morphis: dashes instead of underlines in filenames
<morphis> did that change recently?
<zyga-ubuntu> morphis: no, I think we never used dashes in filenames
<zyga-ubuntu> morphis: pushed
 * zyga-ubuntu moves to another PR
 * zyga-ubuntu moves to a coffee break
 * genii cartwheels by without spilling his coffee
<ogra_> fgimenez, the pi2-kernel in edge is behind the rest once again, are you fie with me bumping it to the version of beta/candidate ?
<fgimenez> ogra_: sure, we are currently not doing any testing of pi2 in edge, cachio, ok to have them in sync?
<janisozaur> zyga-ubuntu: jestem
<mup> PR snapd#3632 opened: asserts,overlord/assertsstate: auto refresh account-keys <Created by pedronis> <https://github.com/snapcore/snapd/pull/3632>
 * zyga-ubuntu EODs
<zyga-ubuntu> ttyl
<zyga-ubuntu> o/
<mup> PR snapd#3633 opened: overlord/devicstate: fix, don't assume that the serial is backed by a 1-key chain <Created by pedronis> <https://github.com/snapcore/snapd/pull/3633>
<mup> PR snapcraft#1427 opened: Add cx_Freeze options targeting bin/snapcraft <Created by alextnewman> <https://github.com/snapcore/snapcraft/pull/1427>
<mup> PR snapcraft#1428 opened: core: reexec as root for `os` snaps if necessary <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1428>
<mup> PR snapd#3634 opened: interfaces/many, cmd/snap-confine: miscellaneous policy updates <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3634>
<mup> PR snapcraft#1429 opened: cli: properly handle exceptions in lifecycle <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1429>
#snappy 2017-07-29
<zyga-suse> good morning snappers :)
<ricmm> o/
<mup> PR snapcraft#1430 opened: tests: enable the snaps installation in armhf <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1430>
#snappy 2017-07-30
<scoopex> if i build the snap package using "snapcraft" and install the package over the existing previous downloaded package using "snap install --dangerous *.snap" i do not get my modifications. i am
<scoopex>                  pretty new in snap packaging, probably i am doing something wrong...any hints?
<scoopex> how can i inspect what is going on in the snap envrironment? i discovered that i can open a shell with "snap run --shell wekan.wekan" but this shell is very restricted (i cannot browse files)...how can i inspect hwat is going on in the snap environment?
<ogra_> well
<ogra_> it is exactly that ...
<ogra_> "i can open a shell with "snap run --shell wekan.wekan" but this shell is very restricted (i cannot browse files)"
<ogra_> that is what makes a snap environment
<ogra_> you can see some writable spaces and have some additional env variables set (depening on what you defined in snapcraft at build time and depending on what interfaces (plugs and slots) your snap has in use at runtime)
<ogra_> in that snap shell run: env
<ogra_> you will see a bunch of variables starting with SNAP_ ... they point to the places your snap has access to
<ogra_> if you need additional access you need to use interfaces (plugs and slots)
<janisozaur> Anyone around to help out debugging Arch OpenGL issues? zyga?
<mup> PR snapcraft#1431 opened: tests: do not check the opencv command if it wasn't installed <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1431>
#snappy 2018-07-23
<mborzecki> morning
<mbeneto> morning
<mborzecki> mvo: morning
<mvo> mborzecki: good morning!
<mborzecki> mvo: shall we land #5122 ?
<mup> PR #5122: snap: add support for `snap advise-snap --from-apt` <Created by mvo5> <https://github.com/snapcore/snapd/pull/5122>
<mvo> mborzecki: let me quickly double check
<mvo> mborzecki: does it have two +1 already?
<mborzecki> mvo: yup
<mborzecki> mvo: 2.34.2 is tagged but it's not 'released' on github
<mvo> mborzecki: yeah, let me fix that, its just test fixes but still let me fix it
<mborzecki> google:ubuntu-core-16-64:tests/main/unhandled-task failed on master and journal is basically Jul 23 07:56:56 jul230742-893813 audit[8830]: AVC apparmor="DENIED" operation="accept" profile="snap.network-bind-consumer.network-consumer" pid=8830 comm="python3" laddr=127.0.0.1 lport=8081 family="inet" sock_type="stream" protocol=6 requested_mask="accept" denied_mask="accept" repeated over and over again
<mborzecki> thought that the patches cleaning up snap.network-bind-consumer.network-consumer were landed already?
<mborzecki> or not, merged #5477 just now
<mup> PR #5477: tests: change the service snap used instead of network-bind-consumer <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5477>
<mvo> mborzecki: thank you for this
<Chipaca> moin moin
<Chipaca> mborzecki: welcome back!
<mborzecki> Chipaca: hey
<Chipaca> mborzecki: are you appropriately revitalized
<mborzecki> Chipaca: i still think that vacation snould be at least 3 weeks long
<Chipaca> mborzecki: I see no problem with that
<Chipaca> mborzecki: (that's the way nearly everybody does it in Argentina)
<mborzecki> Chipaca: here it's usually 2 weeks :(
<Chipaca> mborzecki: ah, duration varies, i meant most everybody takes it in a single uninterrupted block
<Chipaca> indeed if memory serves the first full year you're working somewhere you get about a week
<mvo> hey Chipaca ! good morning
<Chipaca> on a completely unrelated note, the person behind https://play.jsgo.io/ just let me know they bumped the limit on git objects, so you can now import snapd in there
<mborzecki> Chipaca: the whole yearly allowance here is 26 days, but people usually take at least one 2 weeks block during summer (probablyl because that's also a minimum required by law when you're on permanent contract)
<Chipaca> https://play.jsgo.io/375878919304e8143970831774c69ee44f2b204a
<Chipaca> ^ that's snapd running in the browser :)
<Chipaca> allow me to find the biggest quotes in the uiverse to put around the 'running' word, there
<mborzecki> next step, snapd in wasm
<mvo> Chipaca: woah, fun
<Chipaca> mborzecki: snapd for android watches
<mborzecki> on android wear
<Chipaca> yus
<Chipaca> pedronis: are you around?
<pedronis> Chipaca: yes
<Chipaca> pedronis: hiya :-)
<mborzecki> pedronis: hi
<Chipaca> pedronis: I anwered myself already, but just to make sure: managers should no longer have a KnownTaskKinds, and their Ensure/Wait/Stop should no longer call the same thing on the runner, right? (and they shouldn't really be holding on to the runner anyway)
<pedronis> Chipaca: yes, no local runner, they should take one in
<pedronis> just look at any one
<pedronis> Chipaca: also I might do a follow up today that makes Wait/Stop on them optional
<Chipaca> yes, I was confused by what's probably a bad merge, but looked at master for a clear picture
<Chipaca> pedronis: thanks
<mvo> sil2100: mup is currently not working, so I play mup :) https://github.com/snapcore/core18/pull/47 is new and pretty trivial
<mup> PR core18#47: hooks: preserve /usr/local/share/fonts <Created by mvo5> <https://github.com/snapcore/core18/pull/47>
 * Chipaca wanders off to ponder lunch
<pedronis> mvo: Chipaca:    some recent change is making the tests print out squashfs output:   Parallel unsquashfs: Using 4 processors ...
<pedronis> that's a bit annoying
<pedronis> mvo: Chipaca: try for example the  overlord tetss
<pedronis> tests
<mvo> pedronis: oh, interessting. I saw this as well but thought it was because I had a locally modified version of squashfs
<pedronis> Chipaca: is that an affect of passing -no-progress ?
<Chipaca> hmmmm
<Chipaca> pedronis: mvo: I'll take a look
<Chipaca> it might be we're setting os.Stdout where  before we weren't?
<Chipaca> I thought I'd undone those for-testing changes but maybe I missed something
<Chipaca> +	cmd.Stdout = os.Stderr
<Chipaca> darn
<Chipaca> mvo: pedronis: my bad: https://github.com/snapcore/snapd/pull/5494/files#diff-f440ed51e6e7c93f4920731345213192R147
<mup> PR #5494: snap/squashfs, tests: pass -n[o-progress] to {mk,un}squashfs <Created by chipaca> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5494>
<mborzecki> Chipaca: some conflicts in #5506
<mup> PR #5506: cmd/snap: add a green check mark to verified publishers <Created by chipaca> <https://github.com/snapcore/snapd/pull/5506>
<Chipaca> mborzecki: yes. Was hoping to get a second review before deconflicting yet again
<Chipaca> mborzecki: HINT HITN NUDGE NUDGE
<mborzecki> understood :)
<mvo> does "configure: error: C compiler cannot create executables
<mvo> See `config.log' for more details" ring any bells? release/2.34 is currently failing with that it seems
<mborzecki> mvo: did it come up again?
<mvo> mborzecki: yes, in my PR from this morning
<mborzecki> mvo: builfing on fedora now
<mborzecki> maybe something changes with the deps
<mvo> mborzecki: you mean you are trying the build? what is also odd is that master seems to be ok
<mborzecki> configure: error: in `/root/rpmbuild/BUILD/snapd-1337.2.34~pre1/cmd':
<mborzecki> configure: error: C compiler cannot create executables
<mborzecki> heh
<mvo> mborzecki: yeah, thats the error I get (my version number is slightly different though)
<mborzecki> mvo: running cmd/autogen.sh works though
<mborzecki> configure:2740: gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-st
<mborzecki> rong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasyn
<mborzecki> chronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection  -Wl,-z,relro -z now conftest.c  >&5
<mborzecki> annobin: conftest.c: Error: plugin built for compiler version (8.0.1) but run with compiler version (8.1.1)
<mborzecki> cc1: error: fail to initialize plugin /usr/lib/gcc/x86_64-redhat-linux/8/plugin/annobin.so
<mborzecki> configure:2744: $? = 1
<mborzecki> mvo: ^^
<mvo> mborzecki: woah, what is annonbin
<mborzecki> cachio: can you update fedora 28 image?
<mborzecki> mvo: no clue, Son_Goku do you have an idea what that might be?
<Son_Goku> is this rawhide?
<Son_Goku> also, god damn it annobin
<mborzecki> Son_Goku: 28
 * Son_Goku growls in anger
<Son_Goku> mborzecki, is the f28 image fully up to date?
<mborzecki> Son_Goku: i'm afraid not, just pulled in >200MB of updates and retrying the build
<Son_Goku> you might be out of sync with gcc + annobin
<Son_Goku> mvo, mborzecki: https://fedoraproject.org/wiki/Changes/Annobin
<Chipaca> mvo, pedronis: #5547
<mup> PR #5547: snap/squashfs: stop printing unsquashfs info to stderr <Created by chipaca> <https://github.com/snapcore/snapd/pull/5547>
<Chipaca> heh
<Chipaca> pedronis: fastest +1 in the west
<Son_Goku> the compiler team has developed a number of plugins to enforce security hardening, expand debuginfo, and include extra information for auditing purposes
<Son_Goku> annobin is one of those plugins
<mborzecki> Son_Goku: interesting
<pedronis> Chipaca: mvo: #5546
<mup> PR #5546: many: make Wait/Stop optional on StateManagers <Created by pedronis> <https://github.com/snapcore/snapd/pull/5546>
<Chipaca> :-D
<mborzecki> mvo: the package builds after dnf upgrade
<mvo> pedronis: cool, I check in a bit
<mvo> mborzecki: ok, so cachio just needs to update the image?
<Son_Goku> annobin has the crappy requirement of being ABI sensitive to gcc
<Son_Goku> it has to use the same gcc it was built for
<mborzecki> mvo: yes, given what Son_Goku wrote we need to update it each time gcc is updated
<cachio> mvo, mborzecki Son_Goku I'll update images today
<mvo> cachio: thank you
<mborzecki> Son_Goku: hm another intersting thing, annonbin does not seem to depend on gcc
<Son_Goku> mborzecki, no, strictly speaking, it's a requirement from redhat-rpm-config
<sil2100> mvo: looking! :)
<Son_Goku> redhat-rpm-config has the following:
<Son_Goku> Requires: (annobin if gcc)
<Son_Goku> which is a rich dep that imposes annobin to be installed if gcc is
<mborzecki> Son_Goku: but does not seem to enforce any particular version
<Son_Goku> mborzecki, yeah, annobin should have a requirement to be run with the gcc it was built from, but it doesn't :/
<Son_Goku> hmm, it does
<mborzecki> Son_Goku: hm maybe it's implicit when using rich dependency https://paste.fedoraproject.org/paste/2Pdj7r~fbdHIj4jzae6kCA/raw
 * zyga waves 
<Son_Goku> hey zyga
<zyga> trying to catch up with my sleep credit
<mborzecki> zyga: hey
<zyga> anything on fire or can I get back to sleep?
<Son_Goku> zyga, you know we only have two weeks until flock, right?
<zyga> yes
<Son_Goku> I still need to make the presentation and you need to at least make a demo, if not prepare some basic code for plugging base snap building into fedora tools
<zyga> I will work on that this week
<zyga> next week I'd like to take a week off as that's the last chance for spending any time with my wife without a laptop
<Son_Goku> mborzecki, it looks like an error in the annobin packaging means that the version dep is not on annobin itself
<Son_Goku> it's on annobin-tests
 * zyga returns to slumber
<mborzecki> Son_Goku: can you file a bug?
<Son_Goku> yep
<mborzecki> Son_Goku: thank you
<Chipaca> what's up with travis eating logs?
<Chipaca> hmm
 * Chipaca hmm'ing
<Chipaca> master seems broken: if I run the unit tests of cmd/snap, there's a good chance it breaks in the aliases tests
<Chipaca> with a connection error
<Chipaca> (?!?)
<Chipaca> cachio: is this one of the ones you are chasing?
<cachio> Chipaca, no
<cachio> Chipaca, working with an opensuse repo error
<Chipaca> ok
<cachio> I see unit tests failing on master now
<cachio> Chipaca, https://travis-ci.org/snapcore/snapd/builds/407066445#L2043
<cachio> this is the one
<cachio> I already updated opensuse image, so it should be gone
<mvo> cachio: looking
<mvo> cachio: the "E: Could not read response to hello message from hook [ ! -f /usr/bin/snap ] || /usr/bin/snap advise-snap --from-apt || true: Connection reset by peer" bug has an open PR, one sec
<cachio> mvo, I saw this one https://travis-ci.org/snapcore/snapd/builds/407177600#L3637
<mvo> cachio: the apt error should be fixed with https://github.com/snapcore/snapd/pull/5548#partial-pull-merging
<mup> PR #5548: debian: ensure dependency on fixed apt on 18.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5548>
<mvo> niemeyer: btw, could you please re-enable mup for our github repos? AIUI github issues are fixed by now
<mvo> cachio: hm "... value client.ConnectionError = client.ConnectionError{error:(*url.Error)(0xc820192030)} ("cannot communicate with server: Post http://127.0.0.1:39530/v2/aliases: read tcp 127.0.0.1:44800->127.0.0.1:39530: read: connection reset by peer")" is strange, I don't think this has changed in a long time
<mvo> cachio: could you please ping me once the f28 images are good again? then I will trigger #5545 again :)
<mup> PR #5545:  snapstate: allow setting "refresh.timer=managed" (2.34) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5545>
<cachio> mvo, I am gonna update them now
<hunterk> mborzecki: Hi there, I was told you may be interested in vulkan+snap testing/examples
<mvo> cachio: thank you!
<cachio> mvo, fedora 28 is updated
<cachio> mvo, running tests now
<cachio> I'll check after lunch
<cachio> mvo, so far so good
<mvo> looks like we need to put the seed.yaml reodering higher on our todo :/ germintae reorder things so our code needs to ensure the right order
<cachio> mvo, do you want to check if it is everything ok?
<mvo> cachio: yeah, looking
<cachio> tx
 * Chipaca runs to the shops before they close
<Pharaoh_Atem> mborzecki: https://bugzilla.redhat.com/show_bug.cgi?id=1607430
<cachio> mvo, tests passed sucessfully on fedora-28
<mvo> cachio: nice
<mvo> kyrofa: do you know about the current rust snapcraft testsuite failures?
<mvo> kyrofa: there is a discussion in #ubuntu-devel right now and whether or not snapd has anything to do with those
<pedronis> mvo: ?   for classic or in general? at the moment prepare-image will not even grab bases or default-provider
<niemeyer> mvo: Good point, thanks for the reminder
<mborzecki> Pharaoh_Atem: thanks, already subscribed to the bug :)
<Chipaca> ok, giving up for today
<Chipaca> but something is still broken :-(
<Chipaca> several somethings actually because the more i try to pin it down the more other things break
<Chipaca> grr
<Chipaca> anyhow, tomorrow.
<shantanoo> hi all, is there a latest clamav snap?
<shantanoo> tried building one, but after install got '/snap/clamav/current/usr/local/bin/freshclam: error while loading shared libraries: libclamav.so.7: cannot open shared object file: No such file or directory'
#snappy 2018-07-24
<mborzecki> morning
<mborzecki> trivial review #5550
<mup> PR #5550: spread: switch Fedora and openSUSE images (2.34) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5550>
<mborzecki> mvo: hi
<mvo> mborzecki: hey, good morning
<mborzecki> mvo: i have a vague recollection that you were suppsoed to be off today :)
<mvo> mborzecki: I'm not really here today but the SRU is still pending and I need to do some testing to ensure it can go in in time :/
<mvo> mborzecki: so yeah, hopefully not here for long
<mborzecki> mvo: aah
<mborzecki> mvo: while at it, #5550 is really simple, i hope if fixes the issues with fedora we're seeing in 2.34
<mup> PR #5550: spread: switch Fedora and openSUSE images (2.34) <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5550>
<mvo> mborzecki: oh, nice!
<mborzecki> mvo: we somehow ended up using different image in 2.34 branch, and i'd guess only the one used in master branch got updated
<mvo> mborzecki: yeah, makes sense
<mvo> mborzecki: thanks for finding that
<mvo> mborzecki: long standing branches are always a bit of a pain :/
<mvo> mborzecki: feel free to merge once its green
<mborzecki> mvo: ack
<zyga> good morning
 * zyga sort of feels better now
<mborzecki> mvo: and merged, i've restart #5545
<mup> PR #5545:  snapstate: allow setting "refresh.timer=managed" (2.34) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5545>
<mborzecki> zyga: hey
<zyga> hey, how are things?
<mvo> zyga: good morning! how are you? well rested?
<zyga> mvo: so so but better, this trip was pretty unfortunate (lots of delays, lots of gate changes, terrible seats next to crying babies)
<zyga> mvo: but I'm much better than yesterday :)
<mvo> mborzecki, zyga: we have a bit of a problem - on a fresh install via http://cdimage.ubuntu.com/bionic/daily-live/current/ when doing "snap install gedit" it hangs forever in auto-connect
<mvo> zyga: trip> meh, not good
<zyga> hmm hmm, we had this bug before right?
<mborzecki> mvo: do we have any logs?
<zyga> auto-connect task would spin in a loop, failing and trying again
<zyga> I have a hunch I know what causes mount failures
<zyga> the "https://forum.snapcraft.io/t/unexplained-mount-failure-protocol-error-what-we-know-so-far/5682/7" issue
<zyga> increased parallelism
<zyga> if allocating a loopack device is racy
<zyga> then we have tow racing tasks that somehow end up both using one /dev/loopX
<mvo> fwiw, happens with 2.33 and 2.34
<mvo> http://paste.ubuntu.com/p/DDCFVn7d4d/
<mvo> zyga: yeah that sounds sensible
<mvo> mborzecki: the pastebin is the change changes output
<zyga> mvo: sadly we don't know what happens inside that task
<zyga> mvo: as in, there is no log of attempts and failures
<mvo> http://paste.ubuntu.com/p/VfKnHtHkzy/
<mvo> zyga: yeah
<mborzecki> hmm
<mborzecki> spins locally too
<pedronis> mvo: the seed order in wrong no?  we told them to fix it but they haven't
<mvo> pedronis: oh, right
<pedronis> mvo: or the last change in the gnome snap needs yet a different order
<mvo> pedronis: yeah, task <1> is also in doing
<mvo> pedronis: I think that explains it
<mvo> pedronis, mborzecki, zyga I think pedronis is right and the hang is just a side effect of the incorrect seed order. so less urgent and we can wait for the new ISO biuld with the seed order fix
<pedronis> mvo: do we know they fix the order?
<mvo> pedronis: yeah, they added a workaround in livecd-rootfs
<mvo> pedronis: where gtk-themes-common is sorted first now
<pedronis> ok
<mvo> pedronis: I hope it actually works, it was a bunch of shell
<pedronis> mvo: btw  I'm happy for us to fix it, but IÂ think for 2.34 is too much of a risk  (it would need to add a bunch of code)
<pedronis> we can try to have something for 2.36
<mvo> pedronis: +1
<mvo> 2.34.2 is now bionic-updates
<mvo> so we will be on the 18.04.1 iso :)
<pedronis> thx
<mborzecki> mvo: #5545 is finally green :)
<mup> PR #5545:  snapstate: allow setting "refresh.timer=managed" (2.34) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5545>
<zyga> small coffee break to be more awake
<jamesh> zyga: when you're more awake, could I get your opinion on this? https://forum.snapcraft.io/t/should-v2-interfaces-select-connected-return-unconnected-plugs-slots/6455
<jamesh> I ran into it last week, and the suggestion was to wait for you to get back from the sprint
<mborzecki> zyga: with this weather some cold brew would be great :P
<zyga> re, sorry, this took a while
<zyga> jamesh: looking now
<jamesh> zyga: no problem.  I was getting over my own jetlag last week :)
<zyga> jamesh: aha, curious, let me look at the code
<zyga> jamesh: so, the output is as intended, I think what is missing is connection-level information (that was supposed to be returned by the never-implemented "snap connections"
<zyga> jamesh: the last part I don't fully follow, the /v2/interfaces endpoint has two GET behaviors, legacy (which is more connection oriented) and non-legacy which is interface (not plug/slot but actual interface) oriented
<jamesh> zyga: I was just trying to work out what users would want the current behaviour
<zyga> jamesh: "Also, if one output mode is referred to as getLegacyConnections, should it be considered a bug that you canât get the equivalent information from the non-legacy interface?" - this is the part that I don't understand
<jamesh> zyga: I'm particularly concerned what the plug is connected to: just whether it is connected
<zyga> jamesh: right, the thing is that the /v2/interfaces?select=connected returns _interfaces_ for which a connection exists between a plug and a slot
<zyga> jamesh: currently there is no way to limit plug and slot references it returns (when prompted) to just those that actually have a connection
<zyga> jamesh: the behavior is specifically modeled for "snap interface" to show a smaller list of interfaces (just those that have some actual connections established), unlike what "snap interfaces" (plural) does
<jamesh> zyga: so the only way to find out if one particular plug is connected is by asking snapd to serialise every single connected plug/slot on the system and then filter it client side :(
<zyga> jamesh: still there is no great way to show the state of a particular plug or slot
<zyga> jamesh: I think we are open to improvements, I'm just explaining why it is the way it is now
<zyga> jamesh: I think we need a connection-oriented view
<zyga> jamesh: and perhaps that would also answer the query you are after
<zyga> jamesh: what is it specifically that you want to access?
<zyga> (or perhaps what is the UX that this is a part of)
<jamesh> zyga: "does snap A have a connected plug of interface type X?"
<zyga> jamesh: interesting, of interface type X or of name X
<zyga> one thing I was looking at just last week was that in spread tests we often grep for stuff while we just want to answer "is this connected"
<zyga> snap is-connected snap-name:plug-or-slot-name
<jamesh> this is for a trusted helper type use, making a decision based on the interface connection state
<zyga> and I was thinking we should implement the connections endpoint which returns all connections, with enough filtering to just answer that
<zyga> I see
<zyga> jamesh: note that in theory one snap can define multiple plugs or slots of the same type
<zyga> (as long as those have different names)
<jamesh> zyga: the particular use case is having pulse audio restrict access to microphones unless a particular interface is connected
<zyga> in conversations long time ago we wanted "snap connections" to essentially return a set of tuples, one per connection
<zyga> ah, right
<jamesh> since we can't handle that kind of thing at the AppArmor level
<zyga> jamesh: so I think that right now we don't have a nice API for that
<zyga> jamesh: I think we should write one (along with snap-connections)
<zyga> jamesh: as the only other alternative is the legacy endpoint and client side flitering
<jamesh> okay
<zyga> is mvo around today?
<pedronis> zyga: he is offically off
<zyga> ah, I didn't know
<zyga> just today or for a week?
<pedronis> just today I think
<zyga> ok
<mborzecki> hm building amzn2 using common fedora spec is triggering isseses when generating selinux policy files, looks like selinux-policy is missing map for file class :(
<Chipaca> I have code that refuses to work locally if I imported from snapd, but works elsewhere imported from purportedly the same code, and works locally if I paste it into somewhere else. i've removed pkg/ from my gopath and no change. Strace doesn't seem to point to any weird imports. Any ideas?
<jamesh> vendored dependencies?
<Chipaca> hmmm
<Chipaca> jamesh: moving aside vendor does make the code work!
<Chipaca> jamesh: but that makes even less sense: the code I'm running is in one of the unit tests that has to be using the vendored code
<Chipaca> but as soon as I run govendor sync again, it fails again
<Chipaca> jamesh: code is https://pastebin.ubuntu.com/p/rtv8QH34qB/ fwiw
<Chipaca> although I'm going to assume it's something local
<jamesh> Chipaca: either (a) you're running into a bug in a dep that has been fixed since the revision govendor pulls, or (b) something bad happens when two copies of the package exist in the same process
<jamesh> anything github.com/snapcore/snapd/strutil pulls in will reference github.com/snapcore/snapd/vendor/gopkg.in/yaml.v2
<jamesh> by "doesn't work", do you mean crashes, or failes to compile?
<Chipaca> jamesh: yaml: unmarshal errors:  line 2: cannot unmarshal !!map into yaml.MapSlice {[] map[]}
<Chipaca> jamesh: option (c) :-)
<jamesh> Chipaca: Looking at the yaml code, it has a branch of code dependent on  "reflect.TypeOf(MapItem{})"
<Chipaca> indeed it fails as soon as I copy gopkg.in into vendor/
<jamesh> Chipaca: so the MapItem as seen by strutil.OrderedMap is different to the MapItem the non-vendored yaml package sees
<jamesh> Chipaca: presumably you could change your program to instead import "github.com/snapcore/snapd/strutil/vendor/gopkg.in/yaml.v2"
<Chipaca> I thought go blocked that
<Chipaca> lemme see
<Chipaca> 	imports github.com/snapcore/snapd/strutil/vendor/gopkg.in/yaml.v2: must be imported as gopkg.in/yaml.v2
<Chipaca> eh, nevermind
<Chipaca> jamesh: now I understand it's not my go installation broken in weird ways (although arguably all installations are, given this), i can stop worrying
<jamesh> anyway.  You can see that strutil.OrderedMap.UnmarshalYAML asks the non-vendored yaml package to unmarshal into the vendored yaml.MapSlice type
<jamesh> which fails because it sees the vendored yaml.MapSlice as just some random third party type rather than something to handle specially
<Chipaca> jamesh: i thought it  was the other way around: the u function will be unvendored (as it's provided by the caller which is outside of snapd, so unvendored) and the MapSlice will be vendored (as it's imported by strutil which will use the vendored)
<jamesh> that's what I said, isn't it?
<Chipaca> ah maybe thats what you said
<Chipaca> :-)
<Chipaca> jamesh: yes
<Chipaca> jamesh: I'm easily confused, it seems
<niemeyer> Mornings
<mborzecki> niemeyer: o/
<Chipaca> could somebody run the unit tests on cmd/snap on master a few (10?) times and tell me if it fails?
<Chipaca> it fails here, at least once every 5-10 times; and it's failing every _single_ time on #5506 :-(
<mup> PR #5506: cmd/snap: add a green check mark to verified publishers <Created by chipaca> <https://github.com/snapcore/snapd/pull/5506>
<Chipaca> completely unrelated to the colour green :-(
<Chipaca> the error is in cmd_aliases_test, ... value client.ConnectionError = client.ConnectionError{error:(*url.Error)(0xc82034e030)} ("cannot communicate with server: Get http://127.0.0.1:34111/v2/aliases: dial tcp 127.0.0.1:34111: getsockopt: connection refused")
<mborzecki> Chipaca: got it on the first run
<mborzecki> Chipaca: on master
<mborzecki> niemeyer: can you upload the latest spread to s3? i've opened a pr for amazon linux but spread is complaining about invalid size string: "preserve-size"
<niemeyer> mborzecki: Ah, indeed I haven't updated, waiting for feedback on whether it worked
<niemeyer> cachio: have you had a chance to try it out?
<mborzecki> niemeyer: it worked :)
<niemeyer> mborzecki: There you go :)
<niemeyer> mborzecki: Updating
<mborzecki> niemeyer: thanks!
<cachio> niemeyer, yes, I updated the amazon image using this one
<niemeyer> mborzecki: Done, please let me know
<zyga> hey niemeyer
<zyga> how are you feeling?
<mborzecki> in case anyone wants to take a look #5552
<zyga> I had a rough ride home, I haven't felt this tired after returning from a sprint in a while
<mup> PR #5552: (WIP) Amazon Linux 2 packaging and spread tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5552>
<niemeyer> zyga: Yo
<niemeyer> zyga: Feeling pretty reasonable.. don't have much time to feel tired this week :)
<niemeyer> zyga: The sprint was intense indeed, though
<niemeyer> I blame the short sessions, in part
<zyga> indeed, lots of tasks switching during the week
<mborzecki> pedronis: did you get a chance to take another look at #5434 ?
<mup> PR #5434: overlord: introduce InstanceKey to SnapState and SnapSetup, renames <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5434>
<pedronis> mborzecki: I think IÂ skimmed it again, but didn't do a full re-review
<mborzecki> pedronis: do you think you could do it this week? it'd be nice to land it before you're off for vacation :)
<mborzecki> pedronis: i'm updating the store pr too, should be pushing the changes later today/tomorrow
 * zyga -> walk
<pedronis> mborzecki: yes, not today though, more likely tomorrow
<mborzecki> pedronis: works for me, thank you!
 * zyga actually goes for that walk...
<cachio> Saviq, yesterday I updated images, please tell me if you see any error
<mborzecki> zyga: vey nice umbrella :P
<hunterk> mborzecki: I have a snap package for a program that uses vulkan but it complains about not being able to find the vulkan loader. I was told you were the person to talk to. Any suggestions? :)
<mborzecki> hunterk: is it published?
<hunterk> yes, retroarch
<hunterk> it initially launches with a GL renderer, but I can walk you through enabling the Vulkan renderer if you like
<mborzecki> hunterk: let me check my notes, iirc there was some fishy stuff about vulkan an how it finds icd files
<hunterk> kk
<hunterk> i have to run to a meeting, so no hurry
<zyga> Pharaoh_Atem: hey
<zyga> around?
<Pharaoh_Atem> zyga: yes?
<zyga> hey, I
<zyga> hey, I'm looking into f29 base snap now, I've started playing with image factory, trying to get it to do _basic_ things (whatever those are) in a way I understand
<zyga> I wanted to quickly sync with you if that is the right way to start
<zyga> Pharaoh_Atem: my plan is to write a plugin for it (called snapcraft) that builds a base snap according to the stuff in the template (still hand-wavy at this stage)
<Pharaoh_Atem> sounds like a good strategy
<cachio> zyga, do you know why we are installing linux-image-extra-* ?
<zyga> Pharaoh_Atem: I don't know what the constraints are, I suspect more modern things may be a dependency problem, I plan to use python 2.7 and shell for now
<cachio> zyga, what so we need from it?
<zyga> cachio: AFAIK for the extra drivers, but not specifcially
 * Chipaca takes a break from bashing his head on tests and goes get a cuppa
<Pharaoh_Atem> zyga: you can email Brendan Reilly <breilley@redhat.com> about it
<Pharaoh_Atem> bah
<Pharaoh_Atem> Brendan Reilly <breilly@redhat.com>
<cachio> zyga, ok, because there is not a package for the latest update on ubuntu 16.04-64
<cachio> on gce
<zyga> cachio: I don't know what that means,
<Pharaoh_Atem> zyga: I'd plan on py3 compatible py2 code, since I think imgfac is going to be ported soon
<zyga> are you saying the package is out of sync somehow?
<zyga> it is built as a part of the kernel
<cachio> zyga, we are installing this on snapd test suite
<cachio> linux-image-extra-$(uname -r)
<zyga> Pharaoh_Atem: that's a good hint
<zyga> Pharaoh_Atem: who is Brendan?
<cachio> but the last kernel is 4.15.0-1014-gcp
<Pharaoh_Atem> he's the maintainer and main developer of Image Factory/Oz
<Pharaoh_Atem> at least for the last two releases, he's been the guy making them
<cachio> zyga, what I can so is to install 4.15.0-15 to make that work
<Pharaoh_Atem> zyga: https://github.com/redhat-imaging/imagefactory/blob/master/imagefactory.spec#L132-L147
<zyga> cachio: sorry, I don't know enough about the problem to help you
<cachio> zyga, ok, np
<cachio> I'll fix it
<zyga> Pharaoh_Atem: ah, I see
<zyga> Pharaoh_Atem: do you expect we will need to make changes outside of image factory in order to get the base snap building in place?
<Pharaoh_Atem> we may need to touch pungi and koji
<zyga> cachio: I know we are installing it in the test suite but I don't know what the problem is really, is the package uninstallable?
<Pharaoh_Atem> https://pagure.io/pungi & https://pagure.io/pungi-fedora; https://pagure.io/koji
<zyga> Pharaoh_Atem: to ping imagefactory or to do some other things?
<Pharaoh_Atem> oz is run by koji, which is kicked off by pungi
<zyga> and how does imagefactory fit into this?
<Pharaoh_Atem> for example: https://koji.fedoraproject.org/koji/buildinfo?buildID=1130195
<cachio> zyga, the problem is that when I update the image for xenial 64, there is not  linux-image-extra for the new kernel instlaled
<Pharaoh_Atem> zyga: imagefactory is run as a koji task
<zyga> cachio: I would ask the kernel team about htis
<cachio> zyga, ok, make sense
<zyga> Pharaoh_Atem: and how does this relate to pungi?
<Pharaoh_Atem> pungi is the tool that actually kicks off all the koji tasks
<Pharaoh_Atem> and tells the tools what they should do
<zyga> so koji can build things
<zyga> by deferring to imagefactory
<zyga> but it has no scheduler
<zyga> so pungi is doing that?
<Pharaoh_Atem> koji is the build system, imgfac is the tool, and pungi is the orchestrator
<Pharaoh_Atem> pungi -> koji -> imgfac
<zyga> ok
<zyga> thanks, I see now
<zyga> so I started with the right place it seems :)
<ogra_> hmm, did we have any recent snapctl changes ?
<Pharaoh_Atem> zyga: you can also ask mboddu in #fedora-releng for more details ;)
<ogra_> https://paste.ubuntu.com/p/9Qg7szthFq/
<ogra_> i'm seeing "snapctl: Permission denied" errors
<zyga> Pharaoh_Atem: for now I think this is enough to keep me busy but I will write that down, contact points are useful
<Pharaoh_Atem> Mohan will be at Flock, too
<ogra_> (this has worked before last edge update of core i think)
<zyga> ogra_: it moved from /usr/bin/ to /usr/lib/snapd/ so maybe apparmor is out of sync somehow
<zyga> see if you have any denials
<zyga> Pharaoh_Atem: Mohan == mboddu?
<Pharaoh_Atem> yeah
<Pharaoh_Atem> his name is Mohan Boddu
<ogra_> heh, surely a gazillion (but from other stuff ...)
<zyga> is he responsible for for koji and friends?
<zyga> ogra_: look for specific denial for snapctl
<ogra_> [ 1007.643957] audit: type=1400 audit(1532443192.989:1239): apparmor="DENIED" operation="exec" profile="snap.chromium-mir-kiosk.hook.configure" name="/usr/lib/snapd/snapctl" pid=4522 comm="configure" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
<ogra_> [ 1007.710435] audit: type=1400 audit(1532443193.053:1240): apparmor="DENIED" operation="exec" profile="snap.chromium-mir-kiosk.hook.configure" name="/usr/lib/snapd/snapctl" pid=4529 comm="configure" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
<ogra_> yeah
<ogra_> should another reboot help here ?
<zyga> no, one sec
<ogra_> (i'm freshly booted after core update)
<zyga> can you check if /var/lib/snapd/apparmor/profiles/snap.chromium-mir-kiosk.hook.configure talks about snapctl (grep for it)
<zyga> ogra_: if it doesn't then i think this is a bug
<ogra_> ogra@pi3:~$ sudo grep snapctl /var/lib/snapd/apparmor/profiles/snap.chromium-mir-kiosk.hook.configure
<ogra_>   # snapctl and its requirements
<ogra_>   /usr/bin/snapctl ixr,
<ogra_>   /usr/lib/snapd/snapctl ixr,
<ogra_> ogra@pi3:~$
<ogra_> looks like it is there
<ogra_> with the correct path
<zyga> that's interesting
<zyga> can you run apparmor_parser -r on that file (as root)
<zyga> and see if that fixes it
<zyga> I wonder if we have a cache issue
<zyga> it's also likely the file is correct now
<zyga> oh
<zyga> so run configure again
<zyga> maybe it will work without running apparmor_parser
<zyga> if it doesn't then do run apparmor_parser
<zyga> and then try to run configure again
<ogra_> i did run configure a few times already
<zyga> ok
<zyga> and it fails, right?
<ogra_> yes, running the parser now
<ogra_> now the configure works
<zyga> ha
<ogra_> ogra@pi3:~$ snap set chromium-mir-kiosk disablekiosk=true
<ogra_> ogra@pi3:~$
<zyga> can you reproduce that issue?
<ogra_> no issues
<zyga> I mean, can you get to a state where it happens again
<ogra_> phew ... that takes a while (takes minutes to install the chromium snap)
<ogra_> well, i'd remove and reinstall the snap
<ogra_> not sure if that changes anything though
<ogra_> the image is a week old or so and silently updated core but nothing else when i applied network 30min ago
<ogra_> not sure if i can repro that state
<ogra_> bah, dang !
<ogra_> ogra@pi3:~$ snap remove chromium-mir-kiosk
<ogra_> error: cannot remove "chromium-mir-kiosk": snap "chromium-mir-kiosk" is not removable
<ogra_> it is in the model assertion as required snap ...
<ogra_> so no way i could try to repro that by removing the snap
<Saviq> cachio: ack, thanks for the heads up (down?) ;)
<ogra_> isnt that also called "nodding" ?
<ogra_> "heads up (down)"
<mborzecki> pedronis: pushed fixes to the store PR too, thanks for the review comments there was indeed an error in mapping install errors there
<ogra_> zyga, aha ... seems a reboot gets me back into the broken state
<zyga> that's very interesting
<ogra_> [ 1178.619187] audit: type=1400 audit(1532445976.250:48): apparmor="DENIED" operation="exec" profile="snap.chromium-mir-kiosk.hook.configure" name="/usr/lib/snapd/snapctl" pid=4393 comm="configure" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
<zyga> because it seems to suggest that we load a profile from cache
<zyga> but loading a profile from the file (compiling it again) results in correct behavior
<ogra_> even when i ran the parser manually ?
<zyga> ogra_: that's different, the cache behaves in another wy
<ogra_> i thought that would also update the cache
<ogra_> ah
<zyga> no, that's separatet
<zyga> can you provide the details
<zyga> on the forum
<zyga> and save the cache / profiles somewhere
<zyga> this is very interesting to debug
<zyga> if you can (and this is a SD card)
<zyga> just save the card and don't change it
<zyga> e.g. fill empty space with zero, dd the card, compress and send to me
<ogra_> zyga, http://people.canonical.com/~ogra/snappy/kiosk/ ... it is just this image
<zyga> I should be able to extract cache data and debug this
<zyga> ogra_: do you have RTC on the device where this runs? is the hardware public?
<zyga> aha, pi
<zyga> do I need a specific pi?
<ogra_> it will auto-update core (built from edge) on first boto and then you should see the error when trying to set anything for chromium-mir-kiosk
<zyga> so I suspect this is a real bug in the cache system
<ogra_> nope, that uses my universal gadget
<zyga> and it affects devices that have no RTC that is battery backed
<ogra_> runs on every pi
<zyga> so on boot the time is very much wrong
<ogra_> (well, every pi we support in core indeed)
<zyga> thank you for this, this is very very useful
<ogra_> well, the clock is correct after first network connection
<ogra_> and the device was only rebooted, not powered off
<ogra_> so it comes up with a proper clock on reboot
<zyga> jdstrand_, jjohansen: ^ it looks like apparmor_parser cache is susceptible to misbehavior when loading profiles on boot on a device without battery backed RTC
<zyga> ogra_: yes but apparmor loads much earlier than that
<zyga> ogra_: before most of regular startup
<ogra_> earlier than what ?
<zyga> ogra_: and definitely before network
<ogra_> the HW clock is set correct on reboot
<zyga> ogra_: look at "systemctl cat apparmor.service"
<zyga> ogra_: how is it being set?
<ogra_> you dont understand :)
<zyga> ogra_: what sets the hardware clock?
<ogra_> ntp should call systohc
<ogra_> once it gets the correct time
<zyga> ogra_: does pi have an RTC on the board? AFAIK it doesn't
<zyga> so on reboot the time is constant
<ogra_> so the HW clock itself should be fine until you power off the board
<zyga> and only gets fixed by userspace later
<zyga> I see
<zyga> this is something to investigate
<ogra_> it surely has an RTC, just no battery
<zyga> can you please collect the apparmor cache and profiles, just in case
<ogra_> anyway, the board also boots with fixrtc set
<zyga> cachio: from /etc/apparmor and /var/lib/snapd/ and /var/cache AFAIR
<zyga> brb
<zyga> er
<zyga> ogra_: ^
<ogra_> so even if the clock was wrong, it would only be slightly off (set to the last mount time of the rootfs)
<zyga> I need to go afk for some time
<mborzecki> hunterk: so i've tried vulkaninfo from my graphics-debug-tools-bboozzoo snap and ran into issues, we're not picking up a library from the host which apparently is required
<ogra_> hmm, actually it doesnt have an RTC ... but fixrtc should still kick in from the initrd
<mborzecki> hunterk: i've opened a PR #5553, feel free to build it locally and check
<mup> PR #5553: cmd/snap-confine: (nvidia) pick up libnvidia-glvkspirv.so <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5553>
<mborzecki> zyga: ^^
<mborzecki> hunterk: also, you actually need to set a path to the nvidia ICD file, the way i'm running vulkaninfo is (inside snap run --shell): VK_ICD_FILENAMES=/var/lib/snapd/lib/vulkan/icd.d/nvidia_icd.json /var/lib/snapd/snap/graphics-debug-tools-bboozzoo/current/command-vulkaninfo.wrapper
<zyga> What does fixrtc do?
<mborzecki> hunterk: for comparison egl has icd search paths which is : separated list of dirs with icd files, libvulkan had no such thing :( hence the manual hack
<zyga> ogra_: what does fixrtc do?
<ogra_> zyga, running from initrd, setting the clock to the last mount time of the rootfs
<ogra_> on boot
<ogra_> so if the clock is off it is only by a really small margin
<zyga> mmm
<zyga> mount or unmount?
<zyga> it may well explain the problem
<zyga> mborzecki: reviewed
<jdstrand_> zyga (cc jjohansen): re battery backed rtc> yes, the clock needs to be right because of the mtime check. Ubuntu had a bug on one of the Touch devices for that
<hunterk> mborzecki: awesome. I'll take a look. Thanks for your help!
<zyga> jdstrand_: I think this would neatly explain this
<zyga> jdstrand: if it is really _mount_ time it is clearly a way to be wrong and reproduce the problem
<zyga> jdstrand: no immediate action now but I will look at reproducing this
<mborzecki> zyga: thanks!
<zyga> ogra_: can you point me to fixrtc sources?
<ogra_> zyga, apt-get source initramfs-tools
<zyga> ogra_: thank you very much sir!
<ogra_> ir uses dumpe2fs to read the last mount date from whatever root= is
<ogra_> *it
<ogra_> and then uses date to set the clock to it ... pretty simple thing (and ages old)
<zyga> ogra_: thank you
<zyga> ogra_: and I think that is the bug actually
<zyga> but I will confirm first
<ogra_> whats the bug ? tha the clock is some minutes in the past ?
<ogra_> *that
<ogra_> (i could imagine it being a but if it is in the future ... but the past ? )
<ogra_> *a bug
<zyga> ogra_: if it really is the mount time it will be wrong for the cache use case
<zyga> ogra_: it must be the unmount time to be correct
<ogra_> well, thats nothing the metadata of ext4 stores sadly
<ogra_> you only have creation, last mount and last write
<ogra_> oh, and last checked
<zyga> last write then
<zyga> last mount is 100% wrong in this case
<zyga> because depending on how the cache is made
<zyga> then you are in the past and the cache is from the future
<zyga> or you actually get the _old_ entry with the correct "window" of time
<zyga> I will reproduce this and gather some evidence
<ogra_> ah, right
<ogra_> that makes sense indeed
<zyga> yeah, it's such a interesting bug
<zyga> it dates back to 15.04
<zyga> ogra_: I cannot find fixrtc there
<zyga> I got the sid version of the package
<ogra_> ubuntu
<ogra_> it isnt in debian
<zyga> aha
<zyga> thanks
<zyga> getting now
<ogra_> great
<zyga> ogra_: can you please run this on your pi just now:
<zyga> dupe2fs -h /dev/mmcblk0XXX
<zyga> adjust to point to rootfs
<zyga> and uptime
<zyga> and pastebin both
<ogra_> oh ... i think we have a bug here
<ogra_> https://paste.ubuntu.com/p/pJqTTZzYkg/
<ogra_> damn ...
<zyga> if this is the bug we shall try those 1L beer mugs at the next sprint
<ogra_> well, the bug goes deeper
<ogra_> look at the timestamps
<zyga> Filesystem created:       Mon Jul  9 13:01:52 2018
<zyga> Last mount time:          Mon Jul  9 13:12:09 2018
<zyga> Last write time:          Mon Jul  9 13:12:09 2018
<zyga> July 9!
<ogra_> yeah
<ogra_> thats the image creation date
<zyga> and uptime?
<zyga> ogra_: ha, I suspected that :D
<ogra_> uptime ?
<ogra_> you mean date
<zyga> no, really uptime
<ogra_> Tue Jul 24 16:16:20 UTC 2018
<ogra_> ogra@pi3:~$ uptime
<ogra_>  16:16:22 up  1:09,  1 user,  load average: 2.34, 2.23, 2.64
<ogra_> ogra@pi3:~$
<zyga> to know when it booted
<zyga> ok
<ogra_> so for some reason the ext4 metadata doesnt get updated correctly in our weird stacked rootfs mounts setup
<zyga> ogra_: and date?
<ogra_> see above
<zyga> ogra_: it thinks it's 9th of July because that's what is baked as fallback when the image was not mounted, then it runs with that because maybe we never unmount cleanly so that is what stays there forever
<ogra_> (above the uptime call)
<zyga> ah, that's good (date)
<zyga> ogra_: if you have a serial, can you shut down / reboot
<ogra_> well, Chipaca's helper unmounts it
<zyga> ogra_: and see if things error on the poweroff tool we wrote
<ogra_> so technically it shoudl unmount cleanly
<zyga> ogra_: well, it unmounts stuff but it happily ignores errors
<zyga> ogra_: and refcount must go to 0 for the unmount to be effective
<ogra_> nope, they do not error ... i see it telling me it unmounts (i did a few reboots today)
<zyga> ogra_: and after reboot, let's look at that data again: from dumpe2fs
<zyga> ok
<ogra_> there is the usual systemd error for writable ...
<zyga> so this is golden:
<ogra_> then the helper kicks in at the very end and tells that it unmounted writable fine
<zyga> we have two bugs: one is that we must use "Last write time" to fix apparmor cache
<zyga> two is that we somehow not unmount cleanly (or so it seems)
<ogra_> yeah
<zyga> next up: look at dumpe2fs to see how that field is read
<zyga> ogra_: or maybe the kernel doens't flush buffers before pi reboots
<zyga> ogra_: "enough"
<zyga> to really sync the SD card
<zyga> can you reboot to just ensure once and for all that this is still the 9th?
<zyga> and I will look at dumpe2fs
<ogra_> ogra@pi3:~$ sudo touch /writable/foobar
<ogra_> ogra@pi3:~$ sudo sync
<ogra_> ogra@pi3:~$ sudo dumpe2fs -h /dev/disk/by-label/writable | grep "Last write time"
<ogra_> dumpe2fs 1.42.13 (17-May-2015)
<ogra_> Last write time:          Mon Jul  9 13:12:09 2018
<ogra_> ogra@pi3:~$
<ogra_> i think it is the stacked nature of our rootfs that breaks it
<zyga> ogra_: I only suspect that gets updated when we really unmount
<ogra_> even touching and syncing a file doesnt update the field
<zyga> ogra_: make a loopback mounted ext4 and see
<ogra_> really ?
<ogra_> i'd excpect sync to update it
<zyga> ogra_: it would be silly to sync that on _any_ metadata write
<zyga> ogra_: superblock
<zyga> ogra_: sync is really "buffers are flushed"
<ogra_> well, i explicitly tell the kernel to ...
<zyga> but this buffer gets dirty when we unmount the superblock
<zyga> if you see what I mean
<zyga> it is really only written once we unmount
<zyga> not at any time
<zyga> a loopback ext4 test will confirm that
<ogra_> well, then it is a miracle to me that the filesystem doesnt completely fall apart all the time
<zyga> I'm looking at e2fsprogs now
<ogra_> i mean ...
<zyga> ogra_: yeah, Last write time: ... is coming from the superblock
<ogra_> ... it effectively thimnks there hasnt been written anything in 3 weeks
<zyga> ogra_: I will check when the kernel writes there now
<zyga> ogra_: yes, fun finding eh? :)
<zyga> ogra_: I love things like this, casual chat ends up finding very serious bug :)
<zyga> and long long long standing one :)
<ogra_> and the journal can only hold 16M ...
<ogra_> (i definitely installed and wrote more stuff than 16M since july 9 )
<zyga> journal as in journald?
<zyga> ah
<zyga> this journal
<ogra_> ad in filesystem journal
<zyga> right
<ogra_> so where is my data !!!
<ogra_> (it isnt like its not there ... but ... but ... )
<zyga> ogra_: which kernel version do you have there, I'll sync the right tag
<ogra_> 4.4 whatever is in the stable channel
<ogra_> ah, no, i'm lying ... its edge
<ogra_> pi2-kernel          4.4.0-1092.100            56    edge      canonical  kernel
<zyga> thanks
<ogra_> zyga, btw, we can only walk iteratively over creation, last mount, last write ... mount and write wont be populated at all on new images ... and there are other boards relying on it where it works (if you simply use a server image without loop mounted stuff )
<zyga> https://github.com/torvalds/linux/blob/894b8c000ae6c106cc434ee0000dfb77df8bd9db/fs/ext2/super.c#L1251
<ogra_> so if we change fixrtc we have to do it very careful to not break the world
<zyga> mhm
<zyga> ogra_: this field is used by ext2, not sure if ext4 _also_ uses it
<zyga> looking
<ogra_> pretty likely
<zyga> https://github.com/torvalds/linux/blob/ca04b3cca11acbaf904f707f2d9ca9654d7cc226/fs/ext4/super.c#L4813
<zyga> interesting
<zyga> if the filesystem is mounted read only the superblock write time is _not_ touched
<zyga> I will do some tests now
<ogra_> sure
<ogra_> but we (the initrd) remount it rw
<zyga> wonder if this actually happens when we make / ro just before unmounting
<zyga> yeah
<zyga> but on shutdown
<zyga> it becomes ro for a sec AFAIR
<ogra_> well
<ogra_> ah
<zyga> so... maybe that's enough not to write this
<ogra_> yeah
<zyga> testing now
<ogra_> whats a bit bothering is that "Last checked" is also not updated ... i'd expect that to be done sepoarately from unmounting
<ogra_> and we definitely run fsck once per boot
<zyga> Filesystem created:       Tue Jul 24 18:36:09 2018
<zyga> Last mount time:          n/a
<zyga> Last write time:          Tue Jul 24 18:36:10 2018
<zyga> this is a loopback, freshly created, never mounted
<ogra_> obviously
<zyga> this is the same thing after mounting and writing a file
<zyga> Filesystem created:       Tue Jul 24 18:36:09 2018
<zyga> Last mount time:          Tue Jul 24 18:37:00 2018
<zyga> Last write time:          Tue Jul 24 18:37:00 2018
<zyga> note that mount time == write time
<ogra_> (the n/a is new with 16.04 ... before it was hardcoded to the epoch)
<zyga> and I obviously wrote _after_ (a few seconds after that)
<zyga> sync doesn't affect that
<ogra_> ok
<zyga> after unmounting I get this:
<zyga> Filesystem created:       Tue Jul 24 18:36:09 2018
<zyga> Last mount time:          Tue Jul 24 18:37:00 2018
<zyga> Last write time:          Tue Jul 24 18:38:14 2018
<zyga> so so far all is good
<ogra_> now ... if you remount ro and do an fsck ... is the check field updated ?
<zyga> I will now remount it ro before unmounting (repeating earlier experiments)
<zyga> :D
<ogra_> :)
<zyga> yep, that's what I want to know
<zyga> first, I mounted it ro as we would in initrd
<zyga> Filesystem created:       Tue Jul 24 18:36:09 2018
<zyga> Last mount time:          Tue Jul 24 18:37:00 2018
<zyga> Last write time:          Tue Jul 24 18:38:14 2018
<zyga> (after mounting as read only)
<zyga> note how the "last mount time" is not changed
<ogra_> yeah
<zyga> I will now unmount it (still ro) to just ensure this is changed (or not changed)
<zyga> Last mount time:          Tue Jul 24 18:37:00 2018
<zyga> it is not changed
<ogra_> there we go
<zyga> ok, now I will make it writable for a moment
<zyga> I mounted it ro, remounted to rw
<ogra_> i still dont get how it manages to not lose data that way ... unless your journal grows and grows
<zyga> Filesystem created:       Tue Jul 24 18:36:09 2018
<zyga> Last mount time:          Tue Jul 24 18:40:42 2018
<zyga> Last write time:          Tue Jul 24 18:38:14 2018
<zyga> last mount time has changed
<ogra_> yeah
<zyga> and it is still mounted
<zyga> so at least this suggests we should see "last mount time" changing
<zyga> unless we really cannot write the superblock back
<ogra_> well ...
<ogra_> we set the clock in initrd ...
<zyga> I touched the file again
<zyga> ah, right, when we ... have no time :)
<ogra_> then mount rw, do an fsck ...
<zyga> touching the file did not affect last write time
<zyga> remounting as ro and unmounting now
<ogra_> well, we have a time
<zyga> I re-mounted as ro and got no change
<ogra_> but only the time from that metadata
<zyga> Filesystem created:       Tue Jul 24 18:36:09 2018
<zyga> Last mount time:          Tue Jul 24 18:40:42 2018
<zyga> Last write time:          Tue Jul 24 18:38:14 2018
<zyga> and bingo!
<zyga> Filesystem created:       Tue Jul 24 18:36:09 2018
<zyga> Last mount time:          Tue Jul 24 18:40:42 2018
<zyga> Last write time:          Tue Jul 24 18:38:14 2018
<ogra_> so the snapd helper would need to remount rw once, go back to ro and only then shut down ?
<zyga> well, not sure yet
<ogra_> or force call the internal fs sync command
<zyga> but re-mounting the filesystem as read only means we never write the superblock
<ogra_> right
<zyga> so all the dates are stuck from any previous experiment
<zyga> this feels like a kernel bug
<zyga> it should remember the FS was writable and written to
<ogra_> it probably does somewhere in the journal
<zyga> ogra_: we could perhaps use an ext4 specific utility to write that date ourselves
<zyga> but anyway, this is the culprit right there
<ogra_> right
<zyga> that coupled with the other bug (wrong timestamp used)
<zyga> I will update the forum thread about this
<zyga> and let's down this beer in September :)
<zyga> 0.5 or more
<ogra_> +1 !
<zyga> I wonder who gets more drunk a polish guy or a german guy drinking beer :D
<zyga> :D
<ogra_> haha, we'll see :)
<zyga> like this cat that spins with a toast on his back;-)
<zyga> jdstrand: we got to the bottom of the issue!
 * zyga goes to the forum
<ogra_> zyga, https://forum.snapcraft.io/t/snapctl-permission-denied-with-latest-edge-core-update/6520
<zyga> ogra_: https://forum.snapcraft.io/t/apparmor-profile-caching/1268/9
<ogra_> bah
<zyga> look at this and check if I got things right
<zyga> let's just cross reference
<zyga> tomorrow we can discuss with mvo on how to fix this
<ogra_> yeah
<zyga> I need to make a coffee :)
<zyga> and play with fedora some more
<zyga> I'm super happy we found this
<ogra_> me too !
<zyga> all pi devices and other RTCless devices will benefit
<ogra_> yep
<zyga> high five orgra :)
<zyga> o/
 * ogra_ ^5 zyga 
<zyga> woot :-)
<ogra_> thanks for the cross-ref :)
<ogra_> zyga, i guess this should hold back the next release til we have a fix ... else all configure hooks will explode
<zyga> yes
<zyga> this is a release blocker
<zyga> CC cachio
<zyga> that's a very important observation ogra_
<ogra_> :)
<zyga> I cross-referenced mvo and will discuss with him tomorrow
<zyga> this was a good day :)
<zyga> what kind of beer do you like more dark or light?
 * ogra_ goes back to watch aquaman HD trailers in loops on the chromium kiosk RPi  ... SW rendered but it's *not* a slideshow !!
<ogra_> zyga, depends ... thats a daily mood thing
<ogra_> generally pilsner style but i have my dark-ale days :)
<ogra_> zyga, and on bad days:  https://d3r6kbofdnmd8.cloudfront.net/media/catalog/product/cache/image/1536x/a4e40ebdc3e371adff845072e1c73f37/1/0/100135_Fucking-Hell-Bier-6x033L-49-Vol_4.jpg
<ogra_> (thats actually real :) )
<cachio> zyga, thanks for the heads up
<cachio> hecking
<cachio> checking
<zyga> ogra_: I'm slowly getting into the more proper coffee
<zyga> ogra_: not "fire and forget"
<zyga> ogra_: I wonder if I will reach that level in beer :)
<ogra_> get a proper espresso machine and start drinking americano ... IMHO the only proper way of consuming coffee ;)
<zyga> americano? OMG I cannot stand it
<ogra_> oh, why ?
<zyga> it should be just called diluto
<zyga> !strong enough
<zyga> sorry ubottu :)
<ogra_> heh
<ogra_> but tasty !
<ogra_> (and it is as strong as the espresso you take for it ...)
<zyga> sure but then you can fit more espresso
<zyga> though I understand diluting wine with juice and fruit to make sangria
<zyga> so ... maybe I just need to find the taste
<ogra_> heh
<ogra_> the point is that putting clear water into an already produced espresso makes the thing keep its taste ... you just dont get a heart attack after three cupts (and i have ten during the day)
<ogra_> it is definitely my preferred coffee over any filter coffee or even crema
<ogra_> (though at times i like a straight espresso)
<zyga> re, just finished brewing it
<zyga> I never liked filtered
<zyga> but my parents drink that sometimes
<zyga> though I suspect it's just because it was easier to make
<ogra_> yeah
<ogra_> https://www.ecm.de/fileadmin/products/slider/ECM-Espressomaschine-Classika-II-Hauptbild.png
<ogra_> :D
<zyga> ogra_: I'll switch to fedora work now
<ogra_> (thats what makes my coffee)
<ogra_> yeah, enjoy !
<zyga> that's neat
<zyga> is that all metal?
<ogra_> yeah
<ogra_> hand made
<zyga> looks very nice
<ogra_> (german company from heidelberg)
<ogra_> brews very nice too ;)
<diddledan> new snap alert! WOOP WOOP. new snap alert! https://snapcraft.io/starruler2
<ogra_> wow ... revision 1 in stable !
<diddledan> :-D
<diddledan> I don't upload until it works :-p
<ogra_> ... 518kB/s ...
 * ogra_ twiddles thumbs
<diddledan> eep
<diddledan> it's "only" 490MB
<ogra_> smaller than supertuxkart :)
<mvo> jibel: good news (maybe you know already) the latest desktop image is fine, snap install gedit finishes as expected
 * cachio afk
<jdstrand> roadmr: hey, did you flip on resquashfs enforcement yet?
<roadmr> jdstrand: no! was waiting for your ok. I can do so now
<jdstrand> roadmr: please do so. thanks!
<roadmr> jdstrand: I'm 2 hours from EOD but the store never sleeps (tm) so feel free to holler if there're issues
<jdstrand> roadmr: yep, thanks :) I suspect few issues, if any. the last time it was on for a week and only had the couple failures we needed to look at
<jdstrand> roadmr: do remember it will make reviews take longer, in case there is a question wrt your monitoring infra
<roadmr> jdstrand: noted, but last time there was no issue with that
 * jdstrand nods
<roadmr> jdstrand: switch flipped!
<jdstrand> \o\
<jdstrand> /o/
<jdstrand> \o/
<jdstrand> :)
<jdstrand> roadmr: thanks again :) hoping this is the *one*
<roadmr> hopefully!
<FreeBDSM> hello
<FreeBDSM> does anyone have a snap file for firefox v52.9.0 ESR?
<FreeBDSM> I need it badly, I don't want to use any more recent version of firefox
<FreeBDSM> `snap install skype` -> `error: This revision of snap "skype" was published using classic confinement and thus may perform arbitrary system changes outside of the security sandbox that snaps are usually confined to, which may put your system at risk. If you understand and want to proceed repeat the command including --classic.`  how safe is it? I don't understand. Is it just a general warning or is Skype requiring some extra permissions?
<FreeBDSM> !classic
<halfbit> I'm confused by ubuntus use of snappy, it looks like they're using snaps for gnome applications? is that right?
<zyga> halfbit: yes, some gnome apps on 18.04 are shipped as snaps
 * zyga heads to bed so cannot have a long conversation
<zyga> FreeBDSM: firefox snap has a ESR track, for more info look at "snap info firefox", it is not at the exact version you wanted though
<FreeBDSM> zyga: exactly why I'm asking here for a particular version.
<zyga> FreeBDSM: classic confinement is "like typical distribution package", there is no confinement between the application process and the system
<zyga> it is as safe as a .deb or .rpm
<zyga> it is based on trust in the actual publisher (microsoft in this case) and that they are not attacking your machine
<FreeBDSM> when such a snap (with classical confinement) gets removed from the system - does it leave trails?
<zyga> FreeBDSM: usually only in logs and leftover data in your home directory (if any)
<zyga> but not in the system
<FreeBDSM> good
<zyga> technically when a snap is removed it is just unmounted, the whole snap is in one file
 * zyga hasn't seen jdstrand this happy in a while!
<FreeBDSM> I've heard there are also flatpaks, how do they differ from snaps?
<zyga> (just scrolling back and noticing the victory dance)
<zyga> FreeBDSM: in tons of ways, this is a huge topic and it's far too late to discuss here
 * jdstrand notes that a classic snap can do anything to the system, so it could leave trails. a well-behaved content snap won't do that of course
<zyga> (now, it's after midnight for me)
<jdstrand> zyga: goodnight! :)
<FreeBDSM> zyga: utc+3?
<jdstrand> s/content/classic/
<zyga> FreeBDSM: in the security model, in the distribution method, in the update method, in the scope and intended feature set ,etc
<FreeBDSM> okay, got it, it's a huge topic
<zyga> FreeBDSM: I'm sure that jdstrand can give you one difference to research
<FreeBDSM> thanks for the answers
<FreeBDSM> it's past midnight for me as well
<zyga> I can too but I'm not an expert on flatpak and I may be imprecise
<zyga> FreeBDSM: both projects use many kernel features to make the apps work
<zyga> and we also use some of the work on the portal system that flatpak initiated
<zyga> but I think we are building slightly different things in the end
<FreeBDSM> 230 users on #flatpak vs 245 on #snappy, hehe
<zyga> alex is a cool, skilled and motivated developer (really kudos for that)
<zyga> well, irc is kind of niche so I don't think that's a useful metric
<zyga> ask him too, I'm sure he will have interesting things to share
<jdstrand> yes. in terms of isolation, flatpak in general uses namespaces and trusted helpers (eg, portals). strict mode snaps can be unmodified, are wrapped with LSM and seccomp filtering (a form of containerization), but also use various traditional containerization techniques (eg, device cgroup, mount namespace, devpts new instance)
<jdstrand> but snaps as of recently can use portals. they can also run as classic snaps (ie, unconfined)
<jdstrand> there was talk of flatpak doing more with LSM, but afaik, that is still a roadmap item
<jdstrand> like zyga said though, trying to doing different things
<FreeBDSM> okay, sorry, I don't understand a thing, haha
<FreeBDSM> so, does anyone have a snap for firefox 52.9.0 esr?
<FreeBDSM> or any instructions on how to build it?
<halfbit> is there a chat for ubuntu core, looks like something I'd be interested in checking out
<halfbit> can I run all of gnome on ubuntu core?
<halfbit> or is that a standard deb based ubuntu only thing
#snappy 2018-07-25
<mborzecki> morning
<mborzecki> interesting failure in unit tests: https://paste.ubuntu.com/p/PB3FhvyfT7/
<mborzecki> mvo: hey
<mvo> mborzecki: hey, good morning
<mborzecki> mvo: have you seen something like this? https://paste.ubuntu.com/p/PB3FhvyfT7/
<mvo> mborzecki: yes, that rings a bell - not sure though what is causing this, maybe some incorrect mocking, i.e. your device is already registered
<mborzecki> mvo: happened once on travis, couldn't reproduce it locally, feels like some race between mock server being started and the actual code accessing it
<mvo> mborzecki: yeah, that sounds likely
<mborzecki> tests are super unhappy again
<mborzecki> new failure in unit gccgo unit tests https://paste.ubuntu.com/p/NfYDvfwGdg/
<mvo> mborzecki: woah, strange. what distro/system is that?
<mborzecki> Chipaca may be right that we're messing something up with fds in the tests
<mborzecki> mvo: 2018-07-25 06:25:13 Error executing google:ubuntu-16.04-64:tests/unit/gccgo :
<mborzecki> mvo: https://api.travis-ci.org/v3/job/407668444/log.txt full log
<mborzecki> mvo: the auto import unit test failed there too
<pedronis> we didn't see this errors a lot before
<pedronis> wondering what changed
<zyga> good good morning
<zyga> mvo: hey, welcome back
<zyga> I'm sorry for being late today, we were stargazing last night and ... well :)
<zyga> we saw Mars, red and bright like a cherry on the sky :)
<zyga> we also saw the ISS, I think,  I never saw it before
<cjwatson> it's very distinctive, quite a sight
<zyga> it was also the last call as it's a rare sight over here and it's expected to be cloudy for the next week
<mvo> zyga: hey hey
<mborzecki> mvo: will you be publishing busybox-static for more arches?
<mvo> mborzecki: yes, working on it as we speak
<mborzecki> mvo: got it, great :)
<mvo> mborzecki: its a bit of fiddling/clicking around in LP, but should be ready soon
<cjwatson> embrace the API :)
<mvo> cjwatson: *cough* I really should use it more
 * mvo is sometimes a bit set in his ways
<mborzecki> mvo: btw. i've seen apt-hooks test fail a couple of times on travis
<mvo> mborzecki: yeah, this is what 5548 should fix
<mvo> mborzecki: or rather, what do you mean with "fails"
<mvo> mborzecki: do you have an example?
<mvo> hrm, except that 5548 failed with the "MATCH" failure
<mvo> :(
<mborzecki> mvo: the output did not contain information about aws-cli snap
<mbeneto> Hey guys, sorry to interrupt, just a stupid question. Is the $SNAPCRAFT_STAGE variable empty when building a "classic" snap?
<mborzecki> mvo: unfortunately i didn't notice anyting specific in the debug log
<mvo> mborzecki: ohhh
<mvo> mborzecki: thats interessting, it might be a race with the update-catalog code
<mvo> mborzecki: also grrrr @snapcraft, it insistend on having a linker in the base, I'm looking for a workaround now
<mbeneto> I have a CMakeLists containing a $SNAPCRAFT_STAGE variable that works well when in a devmode (it takes the value the proper path) but remains empty when building it in classic
<mborzecki> wondering if those connection refused errors may be caused by http server taking a longer while to start accepting on the socket, looking in stdlib there is no synchronization between the http.Server.Start() and actual http.Server.Serve(), so just calling http.NewServer() there's a chance that the if you do a request the server won't be waiting in Accept() yet
<mborzecki> heh https://paste.ubuntu.com/p/Pw77jthXgQ/
<mvo> mborzecki: test-snapd-busybox-static should be ready on all arches now, might be easiest to just force push the base removal PR without the last commit
<mborzecki> mvo: pushed and restarted the build
<mvo> mborzecki: ta
<zyga> mvo: hey
<zyga> did you have a chance to look at the kernel->fixrtc->apparmor issue?
<zyga> specifically I think we must do something about it before the release
<zyga> we can either undo the snapctl change so that existing profiles remain compatible
<zyga> we could change apparmor caching but that's a bigger (beyond snapd) work
<zyga> I think we could also fix fixrtc (heh)
<zyga> since it involves several subsytems it's going to be a coordination issue more than bugfixing issue
<mvo> zyga: sure, let me check
<zyga> mvo: there's a trivial tweak to fixrtc to use the more appropriate timestamp
<zyga> mvo: and if we could somehow fix the shutdown process to write the last-write-time timestamp on shutdown/reboot we would not need any changes to apparmor
<zyga> mvo: I can send you debdiffs
<zyga> mvo: then those need review from ubuntu developers and need to be SRUd
<zyga> mvo: the shutdown fix is more subtle, no idea how to fix that yet
<zyga> mvo: we could (terrible terrible idea) hack something so that we write the last-write-time ourselves on core
<mvo> zyga: we have our own shutdown C program
<zyga> mvo: or perhaps instead of using last-write-time of the rootfs, instead look for mtime of a canary file in /writable
<mvo> zyga: maybe that helps?
<zyga> mvo: that would be an non-invasive way to fix it
<zyga> mvo: yes, we could use it to touch /writable/.timestamp
<zyga> and look at that from fixrtc
<zyga> mvo: longer term we should ask the kernel team for opinion/fix (maybe just foundations)
<mvo> zyga: lets fix fixrtc first, that seems a pretty obvoious one
<zyga> mvo: do you have a pi at home? I didn't bring any here
<zyga> mvo: note that fixing fixrtc alone won't solve the issue
<mvo> zyga: I have a pi
<zyga> but sure, let me start with that
<zyga> excellent
<mvo> zyga: let me look at our custom shutdown, maybe we can hook into that
<zyga> mvo: can you boot your pi and just do a sanity check please
<zyga> mvo: use "dumpe2fs -h" on the root filesystem
<zyga> mvo: and pastebin the result
<zyga> mvo: I'm also curious how we are special, my fedora system (using lvm and ext4) is not affected by that
<zyga> mvo: so something works correct in this case (timestamps updated) but not on core
<mborzecki> Chipaca: hi, did you get to anything debugging the connection refused issue?
<Chipaca> mborzecki: I was able to reduce its incidence a lot, but not eliminate it, meaning that the changes I did were not finding the root cause, just making it less probable
<mborzecki> Chipaca: tried this locally https://paste.ubuntu.com/p/Pw77jthXgQ/
<mvo> zyga: the remount -o ro - is that done by systemd?
<mborzecki> Chipaca: but at times i got no panic and the http requests still failed with connection refused
<mborzecki> Chipaca: stracing it now
<zyga> mvo: I _think_ so, not sure if intrinsic part of systemd or just some service we have
<Chipaca> mborzecki: Hmm. I'll add this to the changes I've done, let's see what gives
<zyga> mvo: I just recall seeing that message
 * zyga reboots
<mvo> Chipaca: good morning! do you think we can merge 5531 (it got plenty of +1) or shall we ask for a gustavo review first?
<zyga> so my fedora system is _not_ affected
<zyga> trying with ubuntu now
<Chipaca> mborzecki: cmd/snap/main_test.go:132: url.Hostname undefined (type *url.URL has no field or method Hostname)
<Chipaca> mborzecki: i think i might be losing it
<mborzecki> Chipaca: i'm using go 1.10.1
<Chipaca> mvo: I don't have a strong opinion either way; I think I described the pr in the standup on monday and he didn't flag it, fwiw
<Chipaca> mborzecki: hah
<mborzecki> Chipaca: url.Host instead?
<Chipaca> mborzecki: so url.Host is host+port
<Chipaca> yeah
<mvo> Chipaca: ok, I leave it to you, we can either double check in the standup or just go ahead (easy enough to revert if needed)
<Chipaca> mborzecki: ... value *os.PathError = &os.PathError{Op:"close", Path:"/tmp/check-4087160113880545930/34/var/lib/snapd/system-key.WWtDQKfmnsvk~", Err:0x9} ("close /tmp/check-4087160113880545930/34/var/lib/snapd/system-key.WWtDQKfmnsvk~: bad file descriptor")
<mborzecki> Chipaca: right, seen this one too
<Chipaca> mborzecki: WAT!!wat
<Chipaca> that's wat^(wat^....^wat) wat times
<zyga> Chipaca: close EBADFD - it got closed elsewhere, you have descriptor usage bugs?
<mborzecki> zyga: it's in master :P
<zyga> is golang protecting against close(-1) ?
<Chipaca> zyga: this is runnig unit tests for cmd/snap on master
<zyga> Chipaca: who would ever do that
<Chipaca> zyga: I've got a PR that fails with one particular race every time, but the race is on master already
<Chipaca> I think I described the issue yesterdya already
<Chipaca> eh
<Chipaca> new one: ... value *os.PathError = &os.PathError{Op:"read", Path:"/tmp/check-5611194952709039976/48/mountinfo", Err:0x9} ("read /tmp/check-5611194952709039976/48/mountinfo: bad file descriptor")
<Chipaca> but, importantly, different
<Chipaca> but, strangely, stll in auto_import
<mborzecki> Chipaca: i see int quite often here
<Chipaca> (where other bugs have been seen)
<Chipaca> mborzecki: you see int?
<mborzecki> Chipaca: yeah, int is all i see
<mborzecki> so much int :)
<Chipaca> isn't that an '80s ballad
<zyga> jdstrand: hey, 4.18 kernel seems to be misbehaving wrt apparmor again: https://bugs.launchpad.net/snappy/+bug/1709155
<zyga> jdstrand: I recall you said something about that a few weeks ago
<zyga> any bells?
<mup> Bug #1709155: Better error message for unsupported kernel <Snappy:Triaged> <Ubuntu:Confirmed> <https://launchpad.net/bugs/1709155>
<Chipaca> mborzecki: have you seen panics, with this change?
<pedronis> Chipaca: mmh,   I think we EBADF errors somewhere else at some point, trying to remember where
<mborzecki> Chipaca: twice
<mborzecki> Chipaca: strace when aliases failes with connection refused
<mborzecki> Chipaca: https://paste.ubuntu.com/p/NcVssQP7sY/
 * zyga cries a little wrt shell in fixrtc
<zyga> pedronis: I recall (a long time ago) when we didn't realize some part of golang did dup(2) on a FD and we were leaking fds in the server
<Chipaca> mborzecki: what're the openat â¦ /json things?
<mvo> zyga: my pi is unhappy right now, looking into it, but can't ssh into it right now
<Chipaca> seems to be the AuthFile
<zyga> that's okay
<zyga> mvo: do you have a serial port adapter?
<mborzecki> Chipaca: maybe because of successive connect attempts
<Wimpress> Morning.
<mvo> zyga: yes, it tells me the ip but no ssh, i may have used this to test disabling the ssh login :/
<Chipaca> mbeneto: what do you see if you run the tests under a 'ulimit -H -n 200'?
<Chipaca> mborzecki: ^
<Chipaca> mbeneto: sorry :-)
<zyga> mvo: ah, that bug :)
<zyga> mvo: heh, well
<Wimpress> Just want to confirm that only content snaps published by Canonical can be connected to by 3rd parties.
<zyga> Wimpress: or snaps with an appropriate store side declaration
<Wimpress> Yep.
<Wimpress> In this case we have a new content snap we want 3rd parties to be able to use freely.
<Wimpress> So publishing as Canonical is the way to go, right?
<Chipaca> mborzecki: ok now i got a panic in httptest/server itself
<pedronis> Wimpress: to be clear Canonical is not special here in code,  we setup a declaration either way
<pedronis> it's a policy question
<mborzecki> Chipaca: in listener?
<zyga> Wimpress: what content is that? will canonical maintain it?
<mborzecki> Chipaca: err i mean when setting up listener?
<Chipaca> mborzecki: https://pastebin.ubuntu.com/p/ryWkGQp3FD/
<mvo> zyga: dumpe2fs output https://paste.ubuntu.com/p/jzVHMqRJjP/
<zyga> Filesystem created:       Wed Jan 10 21:18:38 2018
<zyga> Last mount time:          Wed Jan 10 21:19:40 2018
<zyga> Last write time:          Wed Jan 10 21:19:40 2018
<zyga> now reboot
<zyga> and look again
<zyga> if those don't change in a sensible way (they are already off IMO) it's confirmed
<zyga> mvo: so in the early boot phase your device think it's still winter
<zyga> mvo: I'm looking at vanilla ubuntu, fedora is certainly not affected somehow
<zyga> mvo: classic ubuntu is also not affected
<zyga> though let me triple check to be certain
<zyga> I have a pi running raspbian as well, let me check that
<Wimpress> zyga pedronis I've not actually been involved in assertions for content snaps.
<Chipaca> ... value client.ConnectionError = client.ConnectionError{error:(*url.Error)(0xc82000a630)} ("cannot communicate with server: Post http://127.0.0.1:42000/v2/aliases: dial tcp 127.0.0.1:42000: getsockopt: connection reset by peer")
<Chipaca> EVERYTHING IS TERRIBLE
<mborzecki> Chipaca: stopped with dlv at a breakpoint in TestAliasesNoneFilterSnap
<mborzecki> Chipaca: there don't seem to be many fds open
<Wimpress> The content is the chromium-ffmpeg codecs. Will be published by Canonical since Canonical are the MPEG-LA license holder.
<Wimpress> We have an initial browser vendor who will connect to the that snap.
<zyga> mvo: interestingly raspbian _is_ affected
<zyga> Filesystem created:       Thu Jan  1 00:00:35 1970
<zyga> Last mount time:          Sun Jul 22 19:02:57 2018
<zyga> Last write time:          Thu Nov  3 17:16:45 2016
<zyga> but my dates are even more crazy than yours
<zyga> last write time is equally bogus there
<zyga> this machine is using a few snaps
<zyga> I will remove them now to see if there is any relation to shutdown without snaps
<pedronis> Wimpress: you will need to ask jdstrand to setup the declaration
<Wimpress> pedronis: Thanks, will do.
 * zyga rebooted his raspbian pi
<zyga> mvo: so last-write-time is unreliable in raspbian (somehow) but not on ubuntu (laptop)
<zyga> I wonder if lack-or-presence of rtc is a factor here
<zyga> I will look if I can capture the shutdown sequence somewhere
<mvo> zyga: ta
<mvo> zyga: fwiw, the downloaded base image I was using is from 10 Jan, so that might explain the date
<mvo> zyga: I rebooted now but the last-write-time is still the same
<zyga> yeah
<zyga> you can replicate the issue with just loopback ext4
<zyga> just mount -o remount,ro
<zyga> and then unmount
<zyga> I think the proper fix for now is a canary file
<zyga> we will need to patch shutdown scripts but that is ok
<zyga> well, the shutdown _helper_
<zyga> and fixtrc in our ppa
<zyga> mvo: the fixed fixrtc will restore clock based on the canary file
<zyga> mvo: and that should be it really
<zyga> then we pass this to foundations to untangle and fix properly with SRU candence
<zyga> mvo: I think that's the best case scenario for now
<zyga> mvo: I wonder if any other magic bugs can be attributed to devices waking up and thinking time is standing still
<zyga> mvo: also it would be interesting to have a core device metric with (has-hardware-rtc, has-working-ntp)
<mvo> zyga: it looks like this is somewhat specfic to core, on ubuntu my last-write-time looks vageuly ok
<mvo> zyga: so maybe the best case is we fix this?
<zyga> mvo: I agree but I also think there is something missing
<zyga> is the remount ro specific to core?
<zyga> is that a workaround for broken shutdown from 15.04
<zyga> and we just carry it?
<mvo> zyga: I think that is what we need to find out
<zyga> yeah,
<zyga> zyga@pi3-1:~ $ journalctl --list-boots
<zyga> -1 5a859aca24244b1aa150eadb4461c434 Wed 2018-07-25 10:49:49 UTCâWed 2018-07-25 10:49:55 UTC
<zyga>  0 a78a995e1b794fc3829e3ff69c90cc92 Thu 2016-11-03 17:16:45 UTCâWed 2018-07-25 10:50:47 UTC
<zyga> enabling persistent journal shows interesting dates
<ogra_> zyga, abeato has a patch for canary file support in fixrtc we havent merged
<zyga> ogra_: oh, nice, do you have a link for that?
<ogra_> ... should consider using that one ;(
<ogra_> err
<ogra_> ;)
 * abeato searching...
<ogra_> not off the top of my head, thats why i pinged abeato ;)
<zyga> thanks abeato
<ogra_> hmm, interesting ... i'm doing a snap build, but snapcraft clean fails with permission denied (files of the build in prime/ are root only apparently) i wonder how thats possible given i didnt use sudo or anything
<zyga> mvo: so interesting, there's a systemd unit
<zyga> Jul 25 10:55:19 pi3-1 systemd[1]: Stopped Remount Root and Kernel File Systems.
<zyga> it runs just before actual shutdown, inspecting it now
<zyga> systemctl cat systemd-remount-fs.service
<ogra_> thats an upstream one AFAIK
<zyga> that's just done on startup
 * zyga keeps looking
<zyga> (this is a non-issue)
<zyga> Jul 25 10:55:19 pi3-1 systemd[1]: Failed to set timeout to 600s: Invalid argument
<zyga> Jul 25 10:55:19 pi3-1 kernel: systemd-shutdow: 26 output lines suppressed due to ratelimiting
<zyga> I need to find the rate limit sysctl toggle
<ogra_> printk_ratelimit
<zyga> that's in sysctl.conf?
<ogra_> in sysctl.conf it is kernel.printk_ratelimit=X
<ogra_> (X is seconds, default is 5)
<abeato> zyga, ogra_ this was the additional initrd script I used in some projects: https://paste.ubuntu.com/p/mNw7qKpbyx/
<zyga> ok rebooting
<zyga> abeato: thanks
<abeato> it looks for dates on some files, when the mount date was not really reliable
<abeato> np
<ogra_> it sadly makes everything snap specific ...
<ogra_> so nothing for upstream
<abeato> right, although it can be modfified easily
<ogra_> yeah
<zyga> ogra_: fixrtc is not upstream
<mborzecki> Chipaca: heh, it stopped reproducing now
<Chipaca> mborzecki: on updated master?
<zyga> ha
<zyga> Chipaca: are you on 16.04?
<Chipaca> zyga: yes
<mborzecki> Chipaca: no, the same code, just stopped appearing
<zyga> Chipaca: can you run: lsblk -a and find your rootfs ext4
<zyga> Chipaca: then please run sudo dumpe2fs -h /dev/sdaX
<zyga> and look at the three timestamps and paste them here
<zyga> mvo: maybe it depends on systemd version
<zyga> and is fixed in bionic / fedora 28
<zyga> but not in xeial
<zyga> *xenial
<zyga> and not in my old raspbian
<Chipaca> zyga: i can do that on encrypted and non-encrypted /
<zyga> Chipaca: non-encrypted please
<zyga> though should not matter as ext4 doesn't see the encryption layer
<Chipaca> zyga: i mean, i have both, on separate machines (obviously)
<zyga> and this is an ext4 superblock feature
<Chipaca> zyga: http://paste.ubuntu.com/p/vqFY25f3zs/
<zyga> ha
<zyga> Filesystem created:       Sat Feb 24 17:42:06 2018
<zyga> Last mount time:          Fri Jul 13 21:11:46 2018
<zyga> Last write time:          Fri Jul 13 21:11:46 2018
<zyga> is this machine up since the 13th of July?
<Chipaca> zyga: probably yes
<zyga> hmmm, would you be ok rebooting it?
<ogra_> zyga, ubuntu upstream
<Chipaca> zyga: up 11 days
<zyga> ok
<Chipaca> zyga: http://paste.ubuntu.com/p/3KghN9nj7v/
<Chipaca> zyga: that one's up 8 days
<jdstrand> zyga: I don't recall knowing anything about https://bugs.launchpad.net/snappy/+bug/1709155/comments/4
<mup> Bug #1709155: Better error message for unsupported kernel <Snappy:Triaged> <Ubuntu:Confirmed> <https://launchpad.net/bugs/1709155>
<zyga> so somehow classic xenial is not broken
<zyga> jdstrand: thank you
<Chipaca> zyga: I would be ok rebooting it if needed
<zyga> unless you never rebooted before it should be consistent
<Chipaca> zyga: i've rebooted lots of times
<Chipaca> just not in the past few weeks
<zyga> ok
<jdstrand> jjohansen: hey, the bug description is wrong, but starting at comment #4, people are complaining about "cannot perform readlinkat() on the mount namespace file descriptor of the init process" in 4.18. this reminds me of https://bugs.launchpad.net/apparmor/+bug/1656121, but people aren't talking about complain mode
<mup> Bug #1656121: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace <verification-done-xenial> <verification-done-yakkety>
<mup> <AppArmor:Confirmed> <linux (Ubuntu):Incomplete> <linux (Ubuntu Xenial):Fix Released> <linux (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1656121>
<jdstrand> jjohansen: I've asked for more info (in particular, denials). does the 4.18 have the sauce patches?
<jdstrand> jjohansen: actually, seems most how are complaining are talking about mainline/upstream
<jdstrand> s/how/who/
 * Chipaca ~> lunch
<zyga> mvo: raspbian uses "fake-hwclock"
<zyga> but it runs in mid-early userspace (not in intrd)
<Chipaca> mborzecki: merged master insto the green cehck mark and didn't get the connection error this time (got others instead)
<Chipaca> now running tests in a loop with the race detector on
<Chipaca> we'll see
 * Chipaca ~> really lunch
<pedronis> Chipaca: btw  the advise tests do direct FD manipulations in goroutines
<pedronis> there might be something there
<Chipaca> pedronis: ack
<ogra_> zyga, yeah, that wont help with what initially triggered the fixrtc creation ... ("mount time is in the future yadda yadda, boom")
<zyga> mhm
<ogra_> zyga, though perhaps combining both might work
<zyga> I'm trying to understand why last-write-time is bad on raspbian
<zyga> and not on ubuntu
<ogra_> but that will indeed result in jumpy clock
<zyga> is it caused by some systemd shutdown logic
<ogra_> s/jumpy/more jumpy/
<zyga> are we using systemd in the initrd in classic ubuntu?
<zyga> AFAIK fedora does now
<ogra_> no
<ogra_> there were attempts from ... hmm, how was he called ... james something
<ogra_> he spent 6 months on it and gave up
<ogra_> i'd actually love if we could perhaps go the android approach one day ...
<ogra_> initrd as rootfs ... and just mount all subdirs from disk ... i.e. no rootfs pivoting at all
<ogra_> that would surely work with systemd ...
<ogra_> migrating todays initramfs logic will be a lot harder
<ogra_> (especially since there are tons of mudular bits that get dynamically added or removed ... every package can enhance the initrd)
<pedronis> Chipaca: I see some code similar to the one we had problem with here: ac0523dadf923f4dc6bb
<jdstrand> ogra_: james hunt?
<ogra_> jdstrand, ah, yeah, him !
<zyga> ok, so somewhat closer now
<zyga> I'm looking at source of part of systemd
<jdstrand> mborzecki: hey, did you implement timers? if so, fyi, https://forum.snapcraft.io/t/system-options/87/12
<pedronis> Chipaca: mborzecki: I think there's a chance the issues come from  https://github.com/snapcore/snapd/pull/5122
<mup> PR #5122: snap: add support for `snap advise-snap --from-apt` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5122>
<pedronis> s/the issues/some of the issues/
<jdstrand> mborzecki: but the reason I mention it is to ask if they are expected to work on 14.04? it seems it doesn't support 'systemctl list-timers' and though the timer file is generated, it doesn't ever seem to fire
<jdstrand> mborzecki: it is fine (with me anyway) if it isn't supported, but seems like something that should be documented. maybe it is and I just don't know where
<mborzecki> jdstrand: i'm aware of list-timers not working, but timers as such should likely work on 14.04, unless systemd is that old there
<mborzecki> jdstrand: well, it's possible to enable a timer unit and start it
<jdstrand> mborzecki: it has 229-4ubuntu21.2. I used 'timer: 0:00-24:00/24', but it never fired after reboot afaics. it worked as expected on 16.04
<jdstrand> mborzecki: I could start it. I thought I even enabled it... but it wouldn't fire hourly
<mborzecki> jdstrand: journalctl -u *.timer ?
<jdstrand> mborzecki: it's gone now. I guess I can create bug/topic. which do you prefer?
<mborzecki> jdstrand: let's do a topic first
 * zyga -> walk, see you at the standup
<jdstrand> mborzecki: ok, it seems the problem was actually with the logging to rsyslog on 14.04
<mborzecki> phew :)
<jdstrand> mborzecki: I created a timer that fires every minute and updates a file in SNAP_COMMON and echos to stdout. the file is updated, rsyslog is not. on 16.04, I see both
<jdstrand> mborzecki: journalctl shows it. so this is configuration issue with logging
<jdstrand> as it happens, the snap that I was using was specifically trying to generate a syslog entry
<jdstrand> I could use logger, etc. but between that and list-timers, I thought there was an issue. but there isn't
<mborzecki> well, at least we won't have to debug systemd
<mborzecki> jdstrand: btw. there are some timer related properties if you do systemctl show foo.timer
<jdstrand> mborzecki: I was surprised to see how long the timer file was for the pathological 00:00-24:00/1440
<mborzecki> jdstrand: but i don't recall if those are present in older releases
<mborzecki> jdstrand: yes, our syntax is more expressive, we could do some optimization and be smarted about generated schedules
 * jdstrand nods
<jdstrand> ok, thanks!
<mborzecki> hm something weird about how snaps run in amazon linux
<mborzecki> zyga: /etc/os-release inside a snap should come from the core snap right?
<zyga> Yes
<zyga> But by accident
<zyga> Because it is a slimlink
<zyga> On typical etc
<zyga> That goes to /lib
<abeato> jdstrand, hi, I think this MP is waiting for your review: https://github.com/snapcore/snapd/pull/5469
<mup> PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>
<mborzecki> Chipaca: anything came up with the race detector?
<Chipaca> mborzecki: just one minor thing in cmd_wait_test, so far
<cachio> mvo, did you see this one?
<cachio> https://travis-ci.org/snapcore/snapd/builds/407953474#L5654
<Chipaca> (cmd_wait_test uses a rather funny way of doing the check it does, fwiw...)
<Chipaca> i might just rewrite it out of spite
<Chipaca> mborzecki: infuriatingly, twice i've hit the 'connection refused' error with no race detection
<mborzecki> heh
<mborzecki> Chipaca: also funny how even a tiny change in code makes it disappear to pop up in another test
<jjohansen> jdstrand: there are no sauce patches in ubuntu or upstream around mount
<Chipaca> mborzecki: another one that I hit frequently is the 'queueing for later' (which is just another connection error)
<mborzecki> Chipaca: yup, same here
<jjohansen> the only patch missing upstream is af_unix
<mojtaba> Hello, after running df, I am seeing this: /dev/loop1           640       640         0 100% /snap/gnuchess/9    Could you please explain what it is and how can I unmount it to free some space?
<mborzecki> ok, interestingly the snaps with commands that use relative paths, eg. ../../../bin/sh fail on amazon linux, it's clearly doing something wrong with the paths and calling eg. /var/lib/snapd/bin/sh instead of /bin/sh
<mborzecki> zyga: any clues ^^ ?
<Chipaca> mojtaba: why would just unmounting it free some space?
<Chipaca> mojtaba: but, to answer your question with an explanation, look at the output of "snap list --all gnuchess"
<Chipaca> mojtaba: (pastebinit so I can see it as well)
<abeato> has anybody seen error when snapcraft downloads packages lately? like https://paste.ubuntu.com/p/M9mfqB9WcR/
<mborzecki> zyga: hm i guess it has something to do with the hosts /etc/os-release appearing inside the mount namespace, but i don't know why it happens yet
<mojtaba> Chipaca: http://paste.ubuntu.com/p/fChWFPp7Ct/
<zyga> mborzecki: is it a file?
<zyga> mborzecki: if so, that's why
<zyga> ogra_: ping
<zyga> ogra_: I need one more bit of help from your pi
<zyga> ogra_: can you spare 3 minutes
<zyga> ogra_: journalctl -u apparmor.service
<zyga> that's all I need
<zyga> thanks!
<Chipaca> mojtaba: so, snapd will keep a number of previous releases of the snaps around, to fall back to in case something breaks
<mojtaba> Chipaca: http://paste.ubuntu.com/p/JpyVcmYcmc/
<mojtaba> There is another one for core
<Chipaca> mojtaba: yes, by default it keeps a maximum of 3 around
<Chipaca> mojtaba: you can lower that to two, that is, it'll keep the current one and up to one older one (so when it refreshes it removes the previous old one)
<Chipaca> mojtaba: you can also remove them by hand if you need even more space
<mojtaba> Chipaca: I am running out of space in my root directory. Can I unmount the first two?
<Chipaca> mojtaba: unmounting won't free up space
<mojtaba> Chipaca: How can I change that to 2 and remove the first one by hand?
<Chipaca> mojtaba: and, note that snaps are heavily compressed, so if you're using "du" or similar, it's not giving you the whole picture
<mojtaba> Chipaca: What should I use then?
<Chipaca> mojtaba: (you can see the .snap files in /var/lib/snapd/snaps/)
<Chipaca> mojtaba: i'm getting there
<Chipaca> mojtaba: let me look up the command to change the default
<Chipaca> 1 se
<Chipaca> c
<mojtaba> Chipaca: I am there, should I remove the files? like gimp_38.snap?
<Chipaca> no, do not remove those files by hand
<Chipaca> mojtaba: snap set system refresh.retain=2
<Chipaca> ^ that sets it to keep max of 2 revisions
<Chipaca> mojtaba: (but it only kicks in during refresh)
<Chipaca> mojtaba: to remove a revision by hand, "snap remove --revision=<the revision> thesnap"
<Chipaca> mojtaba: e.g., given your 'snap list gnuchess' output, 'snap remove --revision=9 gnuchess'
<mojtaba> Chipaca: I am getting this error: error: cannot perform the following tasks:
<mojtaba> - Run configure hook of "core" snap (run hook "configure": cannot set "core.refresh.retain": unsupported system option)
<Chipaca> mojtaba: ah, maybe it's not in stable yet, sorry :-)
<Chipaca> should be there soon though
<ogra_> zyga, my pi is currently building a kodi snap ... that will keep it busy for another 1-2h (and it is already 2h in and i dont want to stop it)
<mojtaba> Chipaca: Do you know how can I change it? Or it is not possible to change it to 2?
<jdstrand> abeato: yes, on my list for today actually. was sprinting last week
<Chipaca> mojtaba: meanwhile there's a script that uses 'snap list' output to remove all "disabled" revisions
<zyga> Chipaca: can you ssh in and just run that or would that be a risk?
<abeato> jdstrand, cool, thanks
<Chipaca> zyga: ?
<ogra_> (keypresses on it take minutes to return atm)
<zyga> er
<zyga> that was for ogra_
<zyga> ah o
<Chipaca> mojtaba: if the 'set' command failed, your snapd does not have that option yet (so it's hardcoded to 3)
<mojtaba> Chipaca: What should I do know?
<mojtaba> Can I edit the config file?
<Chipaca> mojtaba: give me a moment
<mojtaba> Chipaca: thanks
<Chipaca> mojtaba: https://superuser.com/a/1330590/63234
<thresh> uhm
<thresh> hello!
<thresh> so I want to use my pkcs11-enabled smart card with a snapped firefox
<thresh> is there a way to grant it access to a real / ?
<ogra_> crazy ideas !
<ogra_> :)
<thresh> well
<zyga> thresh: it is in /var/lib/snapd/hostfs but it's not really available due to confinement
<ogra_> (i guess that would need some kind of smartcard interface ... i have seen people ask about it before)
<zyga> thresh: yes, we'd need a new interface
<zyga> we could craft one based on the denials you are seeing
<thresh> I don't have any denials, firefox just says it fails to load the library
<mojtaba> Chipaca: I could remove the first one of the three, but I just wonder if I could change the default value to 2. So in future it would limit to 2 versions.
<mojtaba> Chipaca: I could not find it in that link.
<thresh> (I need it to import /usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so)
<thresh> https://forum.snapcraft.io/t/snapped-firefox-unable-to-use-smart-card/5719 seems related
<pedronis> Chipaca: https://github.com/snapcore/snapd/blob/master/cmd/snap/cmd_advise_test.go#L129 vs https://github.com/snapcore/snapd/commit/ac0523dadf923f4dc6bb4fcecff8f2632d54020c I think
<mborzecki> zyga: os-reelase on amazon -> https://paste.ubuntu.com/p/ZsyX7stm74/
<mborzecki> zyga: it's an actual file :( damn
<mborzecki> that's why snap-exec may be getting confused with paths
<Chipaca> mojtaba: that configuration option is there from snapd 2.34, which isn't yet in "stable"
<mojtaba> Chipaca: Ok, thanks
<Chipaca> mojtaba: so you could look at switching to snapd candidate  (snap refresh core --candidate) to get the feature
<thresh> no denials afaict in journalctl | grep audit
<Chipaca> mojtaba: or, wait a bit :-)
<mojtaba> Chipaca: thanks a lot for the info.
<Chipaca> mojtaba: note 2.34.1 might have issues (there's already a 2.34.2 in the works), so take care
<Chipaca> i mean, there are reasons it's not stable yet :-)
<Chipaca> pedronis: tests are at loop #30 with no failures just by skipping TestAdviseFromAptIntegration
<mborzecki> zyga: should we fix /etc/os-release as part of quirks in snap-confine?
<Chipaca> pedronis: so, yeah, i think that's the one
<zyga> mborzecki: ish... it's longer than it seems
<pedronis> Chipaca: good, I think the 2nd link should have an idea what we can do
<pedronis> if I understand things
<mborzecki> zyga: something like if /etc/os-release is not a symlink to /usr/lib/os-release mount core /usr/lib/os-relase on top of it?
<zyga> that's racy :)
<mborzecki> zyga: in snap-confine?
<zyga> yes
<jdstrand> roadmr: hi! can you pull r1108 of CRT? not urgent
<roadmr> jdstrand: sure thing!
<jdstrand> one added test, couple of testsuite fixes for arm
<jdstrand> and an override
<jdstrand> roadmr: thanks
<roadmr> awesome!
<mborzecki> zyga: what alternatives you'd suggest?
<mborzecki> (aside from fixing the offending snaps)
<zyga> mborzecki: please hold on,
<zyga> jdstrand: hey, I think we have to bump the apparmor cache bug; it's blocking the release now and we should look at a high-priority fix.
<zyga> jdstrand: we now have a more firm understanding of what is wrong
<zyga> jdstrand: and this is blocking the release
<mvo> Chipaca: sorry, its the stress talking
<Chipaca> mvo: coming from you, I'm not offended
<zyga> jdstrand: let me know when we can talk
<Chipaca> pedronis: mborzecki: #5556
<mup> PR #5556: cmd/snap: fix two issues in the cmd/snap unit tests <Created by chipaca> <https://github.com/snapcore/snapd/pull/5556>
<jdstrand> zyga: how is apparmor_parser using mtime since (nearly) the dawn of time all of a sudden a release blocker for snapd? there is clearly a problem with how the system time is setup. that needs to be fixed any way. to unblock yourselves immediately, move the file back and then focus on the time fix
<jdstrand> zyga: jj is off today, and there is no way that a change to how apparmor_parser handles its caching is going to be fixed fast enough
<jdstrand> zyga: I mean, mtime may not be the best choice in retrospect, but it isn't a bad choice on its own. systems are expected to have a reasonable notion of time
<jdstrand> zyga: it isn't just apparmor that does this sort of thing after all (there is a reason mtime exists after all)
<zyga> jdstrand: one sec, meeting
<Wimpress> jdstrand: Can you hope on a quick video call with me?
<Wimpress> Somewhat urgent question about store assertions.
<ogra_> jdstrand, well, the way we handle the system clock has seemingly never worked right on core ... was the switch to mtime a recent thing ? (i wonder why it has not exposed itself before)
<jdstrand> zyga: iirc, there was talk of using some sort of a hash. this, afaik was never upstream. I'm not sure what the design was tbh
<jdstrand> ogra_: no. it was meant to use mtime forever. in the Touch days it was discovered to use ctime and went back to mtime
<ogra_> i mean ... the clock is definitely never set up the epoch when reading the filesystem metadataas input ... but that metadata has also obviously never been updated since we use the snapd shutdown helper
<jdstrand> ogra_: iirc, there were some small fixes for snapd surrounding this have have existed for a long time
<ogra_> *set up the/set to the/
<jdstrand> perhaps tyhicks recalls some details
<jdstrand> he isn't in this channel atm
<jdstrand> Wimpress: what is this in reference to?
<ogra_> i mean ... it could well be that we simply never noticed that we used outdated profiles ...
<ogra_> but that would even be worse i think
<jdstrand> zyga, ogra_: another unblocker workaround is to unconditionally delete the cache files for snap-confine on shutdown. these are small profiles that wouldn't take long to regenerate on boot
<zyga> jdstrand: the problem is that we found that time is essentially stuck in early boot
<jdstrand> that could be there until time is fixed and/or apparmor_parser
<zyga> jdstrand: and that it is causing (somehow) apparmor to load the wrong cache
<zyga> jdstrand: and we just got asked to actually go ahead and fix the cache for real rather than add another workaround
<ogra_> jdstrand, well, given that we see 20min+ boot times oin firstboot anyway on most arm devices (thanks to snapd seeding) ... a few seconds probably dont have that mauch imapct ;)
<jdstrand> I'd like to better understand how the cache is affected before suggesting any other workarounds. or having jjohansen/myself deprioritize roadmapped work
<zyga> jdstrand: it seems that the cache is from the future
<jdstrand> ogra_: exactly
<zyga> jdstrand: and then we load the cache from now
<zyga> where now == past
<jdstrand> but I need to go to a meeting
<zyga> ok
<zyga> jdstrand: I'll investigate the cache more but I think we cannot do another workaround, this is with us in some way or another since 15.04
<Jguy|> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Jguy|> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Jguy|> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Jguy|> Voice your opinions at https://webchat.freenode.net/?channels=#freenode
<jdstrand> zyga: well, the system needs to have a notion of reasonable time. sure, you can fix the symptoms like apparmor cache, but that isn't fixing the root cause and there might be other bugs
<zyga> jdstrand: that's not an assumption we can do
<zyga> jdstrand: those devices don't know the time
<jdstrand> zyga: but this will have to be escalated via ratliff/amurray to reprioritize people's work if you're demanding apparmor be changed to redo its caching calculation
<zyga> jdstrand: ok, I'll do some more digging and get back to you
<jdstrand> zyga: those devices are going to fail somehow, some way if they don't have proper time. they might not refresh, something might use kerberos, active directory, etc, etc
<zyga> they don't have proper time in early boot
<zyga> they have time once network is up
<jdstrand> zyga: I'm not saying it is an assumption you can do. I am saying that snapd or the gadget or something needs to make them have reasonable time
<jdstrand> zyga: I mean, I haven't thought through all this, but if it is true that the system time is correct once up, then that time can be stored off so fixrtc could use it
<zyga> jdstrand: yes, that's true
<pppingme_> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<pppingme_> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<pppingme_> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<pppingme_> <script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>
<pppingme_> This message was brought to you by Private Internet Access
<jdstrand> zyga: also note that simply supplying a patch isn't going to appreciably speed up the apparmor acceptance. the feature needs to be designed (I believe that jj has one in mind), implemented, reviewed, tested everywhere before it goes upstream. then it needs to go through SRU for trusty-bionic
<zyga> mvo: ^
<jdstrand> of course, this is all doable, but various people would be involved and it would have to be appropriately prioritized
<jdstrand> zyga (cc mvo): note that a lot has happened with caching lately upstream, and the work would need to be verified to work correctly with all of that (it should be orthoganl, but, again, would need jj to comment since he did the work)
<zyga> jdstrand: we have some ideas
<zyga> jdstrand: on a small patch that would work in this specific case
<zyga> jdstrand: or on a way to decouple the schedules
<zyga> so that we can fix this entirely on snapd schedule
<jdstrand> zyga: how can you decouple an apparmor parser patch from the the sru schedule? this needs to go through review which brings in everything else
<jdstrand> I don't see why it is unreasonable to properly fix the time issue
<jdstrand> I mean, fine, the caching algorithm can be adjusted, but with proper design and consideration
<odc> hi! Is there a way to debug what happens when I launch my snapped application? It seems to be stuck and consumes a lot of cpu
<odc> i don't think it's apparmor this time
<nandub> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<nandub> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<nandub> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<nandub> <script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>
<nandub> This message was brought to you by Private Internet Access
<zyga> odc: is it using classic confinement?
<odc> zyga: yes it is
<zyga> odc: it's calling itself in a loop
<odc> hm it worked when i was in devmode
<zyga> odc: make sure to set the path to say something like $SNAP/bin/myself
<zyga> rather than "myself"
<zyga> because that will resolve to /snap/bin/myself
<zyga> and will essentially execute itself forever in a loop
<odc> thx :)
<zyga> jdstrand: we could patch apparmor not to load snapd profiles
<zyga> jdstrand: roll snapd.apparmor.service
<zyga> jdstrand: use a wrapper around apparmor_parser
<zyga> jdstrand: and use content based hashing
<zyga> jdstrand: I mean, we have the code for all of that
<zyga> odc: in devmode that doesn't happen because PATH is reset
<zyga> odc: in classic mode it is not touched
<odc> that's treacherous
<zyga> it's unavoidable sadly
<zyga> jdstrand: this would decouple apparmor release cycle
<zyga> jdstrand: from snapd release cycle
<zyga> jdstrand: I like this property
<jdstrand> I don't know how to say it any more clearly. the fixrtc logic is broken. why not fix that?
<jdstrand> this is going to spin out to shell scripts, then go binaries, etc, etc. fix the time on the system, then, get moving away from mtime on the roadmap for the security team if you are still passionate about it
<jdstrand> as it is, you will slow down boot cause of all the apparmor_parser -p fork/execs and the sha1sums
<jdstrand> fix the time. mtime is used cause it is cheap on the very device you are trying to fix
<jdstrand> zyga, mvo: ^
<Cory26> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Cory26> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<zyga> jdstrand: we purge the cache on refresh because the mtime logic was broken
<Cory26> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Cory26> <script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>
<Cory26> This message was brought to you by Private Internet Access
<zyga> Cory26: please stop spamming
<jdstrand> zyga: that is something different. mtime is not 'broken'
<jdstrand> zyga: it may not be the best choice, but it is a timestamp. the computer is supposed to do things like keep track of time
<jdstrand> zyga: honestly, I'm surprised you purge the cache on refresh based on how snapd is supposed to work. also, your snap-apparmor-parser isn't going to fix the snap-confine issue unless you add something else to load it separately
<jdstrand> there are way to many things going on
<jdstrand> too
<jdstrand> it is supposed to be simple: if the profile is newer than the cache then recompile. if snapd detects that something changed on refresh, splat the profile on disk and load it, otherwise, no need to do anything
<jdstrand> if the time on the system is changing all the time, or set wrong, fix that because *anything* else is papering over the problem and something else is going to break
<StephenS18> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<StephenS18> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<StephenS18> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<StephenS18> <script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>
<StephenS18> This message was brought to you by Private Internet Access
<ephemer0l_6> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<ephemer0l_6> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<ephemer0l_6> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<ephemer0l_6> <script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>
<ephemer0l_6> This message was brought to you by Private Internet Access
<annieslmaos> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<annieslmaos> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<annieslmaos> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<annieslmaos> <script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>
<annieslmaos> This message was brought to you by Private Internet Access
<jdstrand> zyga: to put i more concrete terms. I may as well not even review abeato's PR 5469 if you are going to make extra forks and sha1 sums
<mup> PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>
<kyrofa> Hey kenvandine, any idea why my firefox windows are showing up under the slack icon in the dock (18.04)?
<zyga> jdstrand: at this stage we don't know yet
<zyga> jdstrand: I was explaining a possible scenario
<jdstrand> ok, well, I see github commits and what sounds like every saying 'this mtime thing is annoying, just throw it out'
<jdstrand> everyone*
<zyga> jdstrand: that was written a while ago, I pulled it out of git history
<zyga> jdstrand: it's march I believe
<zyga> jdstrand: gustavo asked us to understand the current cache behavior and fix it
<zyga> jdstrand: one idea we had was to sync the mtime of the text file and the cache file
<zyga> jdstrand: and only use the cache if they are in sync
<zyga> jdstrand: (not newer or older but just equal)
<zyga> jdstrand: this would decouple the time from the equation, we would really use mtime as a cookie
<jdstrand> zyga: the cache behavior seems undesrtood now. the clock is wrong and could be fixed by fixing fixrtc. has anyone communicated that?
<zyga> jdstrand: my patch about using content based caching was from an RFC branch (I showed you the patch before) https://github.com/zyga/snapd/tree/rfc/snap-apparmor-parser that I recalled we have and we discussed as a possible solution to the current problem
<zyga> jdstrand: yes, we don't want to rely on fixrtc, we have clear directions on addressing the cache semantics
<jdstrand> zyga: as for making apparmor more robust, sure, that can be looked at, but I think it needs to be driven by upstream apparmor and not emply wrappers and a bunch of work arounds
<zyga> jdstrand: the kernel / initramfs patches for other userspace programs that may suffer from wrong time in early boot should be fixed as well
<jdstrand> zyga: I maintain it is not snapd's problem to solve. the clock is wrong
<zyga> jdstrand: I'm reading the cache code now, I will try to provide a small patch that makes the cache correct even if the time is essentially random
<zyga> jdstrand: yes but the clock _cannot_ be fixed
<zyga> it can only be improved
<jdstrand> zyga: the clock *can* be set
<jdstrand> you said it yourself
<zyga> hold on, I think I need to do IRL stuff for a moment
<jdstrand> blocking the release on something that has been broken since day one makes no sense
<zyga> jdstrand: the clock can be made better but it will never be fully correct on early boot
<zyga> jdstrand: we want to block because it breaks people in the wild now
<zyga> brb, sorry
<zyga> 3 min
<jdstrand> so put snapctl back where it was to unblock and wait for the right people to look at this. ie, apparmor upstream which already has thought about this for a long time
<jdstrand> zyga: but, really, I mean, the fixrtc mechanism is meant to keep track of time across reboots. it was doing so wrong. it could be made to do it right so the time is right everywhere. then other things can be made more robust without rushing it
 * jdstrand -> meeting
<zyga> re
<zyga> sorry, rain just broke
<zyga> and I was rescuing the laundry :)
<jdstrand> I don't know why what I am saying seems so unreasonable. unblock yourself now. don't complicate caching and potentially slow down loads needlessly, work with the apparmor team to make it more robust
<jdstrand> you doing the patch isn't going to speed things up. doing an preprocess and sha1 isn't the hard part. it is working it all in within the larger design, getting the reviews, getting it pushed out, etc. that shouldn't be rushed
 * jdstrand is talking about you or someone else proposing an upstream patch to do caching differently
<zyga> jdstrand: I would like to do a small cookie based patch to the current code and SRU that (we can put it in the PPA for now)
<zyga> jdstrand: that's separately from the fixrtc logic
<jdstrand> zyga: that still needs security review if it is even reasonable. this is security sensitive code
<zyga> jdstrand: it would be in line with the current logic in apparmor and it could also be fixed upstream
<jdstrand> assuming you are talking about a patch to apparmor_parser
<jdstrand> if the fixrtc logic is fixed now, then you are better than you were yesterday. tomorrow the parser can be adjusted for the future...
<zyga> jdstrand: yes
<kenvandine> kyrofa, no... that is very odd
<jdstrand> why rush something that may not be approved upstream?
<jdstrand> double the work
<kyrofa> kenvandine, this is the second time I've noticed it happen
<zyga> jdstrand: because this issue was reported in 15.04 and I don't see it getting fixed for real anytime soon
<kyrofa> No orange dots next to firefox, a bunch next to slack. When I hover over slack I see all the firefox windows
<kenvandine> window matching bug
<jdstrand> zyga: this can up because of moving snapctl?!?
<kyrofa> Er, not hover, but click
<jdstrand> came*
<zyga> jdstrand: I think so, yes
<jdstrand> 15.04 is eol
<jdstrand> who cares?
<kenvandine> kyrofa, not sure how they could get those mixed up
<zyga> jdstrand: this is snapd today now, my point was that the mtime reliability issue was with us for a while
<zyga> jdstrand: we just now connected the dots to reproduce it
<jdstrand> *sigh*
<kyrofa> kenvandine, is there anything I can poke at? I don't know anything about how it works
<zyga> jdstrand: and see what is causing it
<jdstrand> the clock was always wrong
<zyga> jdstrand: I don't yet know what happens when the clock is wrong wrt apparmor cache
<zyga> jdstrand: perhaps we just _dont_ write the cache
<kenvandine> kyrofa, not sure, that's a shell thing
<zyga> jdstrand: and then on reboot we load the old cache
<kenvandine> i'd probably bug Trevinho about it :)
<jdstrand> fix the fixrtc logic and all that goes away. then fix the parser with full upstream involvement to make it more robust
<zyga> jdstrand: I don't know if the fixrtc thing can be done in core snap or if it involves the gadget (all of them)
<zyga> jdstrand: the cookie idea for aa seems like a way to solve it regardless of gadgets
<zyga> jdstrand: I mean,  want to fix it all
<zyga> jdstrand: but timeline wise it seems like the safest thing to go after
<jdstrand> zyga: but you haven't even discussed the cookie idea upstream
<zyga> jdstrand: right, we can share the patch upstream; even if it is dropped we would be in a position where we have more time to work
<jdstrand> how can that be considered the safest path forward? performant?
<zyga> jdstrand: time
<jdstrand> bah. I'm done. I can't be any more clear
<zyga> jdstrand: sorry about being stubborn here,
<zyga> as I said, I understand your point
<zyga> we need to do more research to see if we can get to a point where we are unbroken (we moved snapctl for a reason) _fast_
<jdstrand> I don't think so. this is blocking you. so I gave a *simple* way to unblock. move snapctl. then fix the parser with upstream involvement
<zyga> jdstrand: we cannot
<zyga> jdstrand: that was moved for a reason
<jdstrand> why?
<zyga> jdstrand: it is required for core18
<Cory21> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Cory21> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Cory21> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Cory21> <script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>
<Cory21> This message was brought to you by Private Internet Access
<jdstrand> why does it matter that snapctl is in /usr/lib/snapd?
<zyga> jdstrand: because of how core18 installs snapctl at runtime
<zyga> jdstrand: anyway, I think we said it all for now
<niemeyer> We can't move snapctl.. the reason it was moved out is core18 and the split of snapd..
 * zyga has network issues 
<zyga> rain
<niemeyer> jdstrand: let's have a call today if you have some time, on a slightly more positive foot
<niemeyer> jdstrand: We don't actually have any hard solutions that we must implement. we just need to solve the problem while preserving the ability to split snapd
<jdstrand> all I want is to not introduce more caching complexity. adding a new layer that wraps apparmor parser won't be performant and adds complexity. apparmor upstream has plans to do something different than mtime. I think we should discuss that when jj is back rather than rushing something else that might introduce more bugs
<zyga> jdstrand: note that I didn't say we would do that, that was _a_ idea, the idea for now is to change the caching as it exists to not rely on the ordering of mtime
<jdstrand> not to mention, it is just wrong that fixrtc isn't able to actually fix rtc
<jdstrand> if that were fixed, the mtime thing wouldn't be as pressing
<jdstrand> zyga: and I feel that doing a non-upstream patch without upstream review will result in more work
<jdstrand> and possibly bugs
 * zyga nods
<jdstrand> if this is all happening in the ppa, well, I guess that is something the snapd team can decide if it is worth doing the potentially throwaway work rather than working with upstream
<jdstrand> but if you do that, please file an upstream bug
<niemeyer> jdstrand: We had issues around this area before.. we'd not have this issue now if the caching was already based on mtime properly
<niemeyer> jdstrand: We can probably workaround this again in other ways once more, and wait for the next bug
<jdstrand> niemeyer: I can't speak to the issues before. I don't have the details at hand
<jdstrand> I didn't say that it wouldn't be done, I just asked to wait for upstream involvement
<jdstrand> but this time it seems clear that it *is* related to the actual time of the device
<niemeyer> jdstrand: You were part of the conversation as well, but I'm not pointing any fingers.. just saying that tuning the application to do an exact match plus mtime updates sounds trivial and much easier than it may sound
<jdstrand> I said above that the patch wouldn't be hard, but that it may not fit within upstream's design for fixing this
<niemeyer> jdstrand: It's okay.. we're fixing what exists, not the future thing that upstream may wish to design
<niemeyer> jdstrand: mtime is already in use, right?
<jdstrand> niemeyer: today, when the cache is updated the parser will set the mtime of the cache file to that of the profile
<niemeyer> jdstrand: Cool.. so on the other end we just need to make sure they match exactly
<niemeyer> Instead of doing a <=
<niemeyer> jdstrand: Hopefully a one-liner or close to it
<jdstrand> actually, what I said wasn't precise. in practice, it will be, but the algorithm is that it will use the newest mtime of the profile or any of its includes
<jdstrand> again, I don't have the plans for improving caching at hand (jj does, but he is off today). I was involved with the conversations before, and while I don't have those details at hand, I thought everything was working since I didn't see any new bugs, until it was discovered that fixrtc wasn't doing that it claimed to do
 * zyga still researches this
<niemeyer> jdstrand: We indeed had no known bugs until we found one :)
<niemeyer> jdstrand, zyga: Let's have a call tomorrow and figure something out
<zyga> ok
<zyga> sounds good
<niemeyer> In all cases, let's please relax a bit.. it sounds like there's quite some tension in the air
<niemeyer> There's nothing major broken today.. we have a release blocked, which is bad, but no fires
<zyga> I'd like to be able to point to a piece of code that misbehaves as right now it's all connected to time but I don't know why exactly
<jdstrand> I'm only tense cause it sounds like snapd is blocked on this and there seems to be a resistance to getting jj involved
<niemeyer> zyga: It'd be very useful to have that by our meeting tomorrow
<jdstrand> jj will be back tomorrow
<zyga> jdstrand: sorry if I gave that impression, I'm not opposed to fixing this upstream
<zyga> jdstrand: I was trying to share the various ideas we discussed during a call
<niemeyer> jdstrand: No suggestion of that on my end either.. I'd expect those changes to be coordinated with him, as usual, and if new ideas show up, even better.. we just need the issue fixed
<jdstrand> ok then :)
<jdstrand> I don't know if it was because I was in meetings and we (me and zyga) were trying to participate there and here and if there was some misunderstanding
<jdstrand> so glad the air is cleared
<zyga> jdstrand: I think that was the case, I was in a call, and chatting with other people at the time, a bit too much context switching and not enough time to discuss and listen
<jdstrand> I was in several meetings and conversations myself
<jdstrand> iirc, the idea from jj was that at the time of the compile the preprocessed checksum is stored in the cache file, and so it would be possible to verify that against the profile on disk. *but* I'm not sure that is what he had in mind, what options the parser would provide, how to avoid performance issues, etc, etc, etc
<lmartin928> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<mvo> niemeyer: when you have a moment, could you please enable mup again for the snapcore repos?
<niemeyer> mvo: Of course, thanks for the ping
<niemeyer> mvo: It's all back, in theory
<niemeyer> mvo: Let's see what happens next
<niemeyer> mvo: Please let me know if you perceive it not working or misbehaving again
<Shibe7> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<ravioli12> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Ugrastil19> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<SlashLife17> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<SlashLife17> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<SlashLife17> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<^v5> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<^v5> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<^v5> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<mvo> early feedback for #5567 would be great
<mvo> mup: hello
<mup> mvo: Roses are red, violets are blue, and I don't understand what you just said.
<mvo> mup: #5567
<Chipaca> mvo: #5557 ?
<mup> PR #5557: wrapper: generate all the snapd unit files when generating wrappers <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5557>
 * zyga -> food
<niemeyer> mvo: Spread PR reviewed
<CC669> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<niemeyer> mvo: I can't see 5567 either
<Chipaca> mvo: 5557
<Chipaca> niemeyer: i mean you
<Chipaca> anyway, eod here
<Chipaca> o/
<mvo> niemeyer: ups, sorry, indeed 5557
<mvo> niemeyer: thanks for the spread review, looking
<thiras> is this a joke?
<thiras> really?
<thiras> do i have to reinstall or reconnect all the snap packages after system update?
<mvo> thiras: do you have more details what happend to you? it sounds like a bug what you describe
<thiras> mvo, it's 18.04. after update (i couldn't catch which package but updated through "install updates while restarting") VLC/discord/gnome-calculator(why even this package is snap)/spotfiy throws permission denied error
<thiras> and doesn't work
<thiras> You need to connect this snap to the gnome platform snap.
<thiras> ./snap/gnome-calculator/180/bin/desktop-launch: line 23: /home/thiras/.config/user-dirs.dirs: Permission denied
<mvo> thiras: that clearly sounds like a bug
<thiras> this line is the common string for all
<mvo> thiras: could you please pastebin the output of "snap changes"?
<thiras> mvo, https://pastebin.ubuntu.com/p/fNWjKtNV3T/
<ogra_> likely the seed ordering bug that was recently fixed in the isos
<mvo> thiras: unfortunately its late here in my timezone and I will have to leave soon, do you think you could report the issue in the forum (forum.snapcraft.io) - this way it won't get lost
<mvo> thiras: please include "snap version"
<mvo> thiras: are these all changes? or just the last few?
<thiras> all the output
<mvo> thiras: thanks for reporting this issue btw
<thiras> but forum is not the place for reporting
<thiras> this project getting really really unprofessional each day
<thiras> but i'll report anyway
<mvo> thiras: thanks, that is appreciated
<mvo> thiras: so just to double check - this worked the other day, there was an update and then your snaps stopped working? the file /var/log/apt/history.log should contain the last package updates, this data might be useful as well, I wonder if the "snapd" deb package was part of a recent apt update
<thiras> i'll put that log into post too
<thiras> forums activation mail doesn't work also
<thiras> mvo, https://forum.snapcraft.io/t/bug-broken-snaps-after-each-update/6536
<mvo> thiras: thank you
<mvo> thiras: there is a bug related to snapd updates on shutdown but I don't think its the same, we will investigate
<thiras> thanks
<labviking> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<labviking> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<labviking> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<labviking> <script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>
<labviking> This message was brought to you by Private Internet Access
<Guest63153> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Guest63153> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Guest63153> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<weaksauce4> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<weaksauce4> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<weaksauce4> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<weaksauce4> <script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>
<weaksauce4> This message was brought to you by Private Internet Access
<MetaNova4> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<MetaNova4> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<MetaNova4> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<MetaNova4> <script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>
<MetaNova4> This message was brought to you by Private Internet Access
<roadmr> good lord, can something be done about those damn spammers?
<niko2> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<niko2> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<niko2> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<niko2> <script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>
<niko2> This message was brought to you by Private Internet Access
<FreeBDSM> hello. does anyone have a snap for firefox 52.9.0 esr?
<mup> PR snapd#5558 opened: tests: new gce image for fedora 27 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5558>
<SkyPatrol25> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<SkyPatrol25> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<SkyPatrol25> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<SkyPatrol25> <script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>
<SkyPatrol25> This message was brought to you by Private Internet Access
<Trevinho> kenvandine: mh, sorry, bug me about what (I don't see the context :))
<FreeBDSM> is it a good idea to keep all the programs (if available) installed as snaps, rather than from my distro's repo?
<elkalamar> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<elkalamar> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<elkalamar> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<elkalamar> <script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>
<elkalamar> This message was brought to you by Private Internet Access
<7JTAEXBQZ> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<7JTAEXBQZ> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<therock247uk29> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<therock247uk29> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<therock247uk29> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<therock247uk29> <script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>
<therock247uk29> This message was brought to you by Private Internet Access
<CodeMouse92> !ops
<ubottu> Help! Channel emergency! (ONLY use this trigger in emergencies) - Pici, Myrtti, jrib, Amaranth, tonyyarusso, Nalioth, lamont, CarlK, elky, mneptok, Tm_T, jpds, ikonia, Flannel, genii, wgrant, stdin, h00k, IdleOne, Jordan_U, popey, Corey, ocean, cprofitt, djones, Madpilot, gnomefreak, lhavelund, phunyguy, bazhang, chu, dax
<cjwatson> CodeMouse92: they're already been autokilled almost as fast as they can be
<CodeMouse92> Aw crikey.
<cjwatson> s/been/being/
<cjwatson> (though if an op of this channel were to /invite Sigyn here, it would let it react slightly faster)
<cjwatson> obvious attack against staff by some random with a stupid grievance is obvious, really
<d10n5> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<d10n5> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<17SAAHUO5> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
#snappy 2018-07-26
<linuxdaemon28> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<TriangleSausage4> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<ski_> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<ski_> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<ski_> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Sigals> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Sigals> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Sigals> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<RussellB287> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<RussellB287> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<SebastianFlyte14> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<SebastianFlyte14> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Guest84053> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Guest84053> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<7JTAEXEXK> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<7JTAEXEXK> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Ceber6> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<kepler_mach3> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<kepler_mach3> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<kepler_mach3> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<jim24> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<mborzecki> morning
<ptx023> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<ptx023> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<aphel> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<aphel> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<aphel> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<nullrouted> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<mborzecki> so much spam
<mup> PR snapd#5559 opened: tests/lib/snaps: avoid using relative command paths that go up in the  directory tree <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5559>
<mborzecki> yay, mup is alive again
<Caraway258> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<mborzecki> mvo: hi, looks like test-snapd-busybox-static has been released to edge only for i386, can you releease it to stable/beta/candidate too?
<mvo> mborzecki: sure, will do now
<mborzecki> mvo: ta
<mvo> mborzecki: done for all arches
<mborzecki> mvo: thanks i'm restarting #5456 then
<mup> PR #5456: snapstate: refuse to remove bases or core if snaps need them <Created by mvo5> <https://github.com/snapcore/snapd/pull/5456>
<mvo> mborzecki: thank you
<mborzecki> yay, only 14 tests failing on amzn2
<pbek> Hi folks, has anyone an example of building a Qt5 app as a snap on Launchpad with the Ubuntu 18.04 envronment? The 16.04 environment worked great. But on 18.04 I get all kind of strange errors while building like in https://launchpadlibrarian.net/380104791/buildlog_snap_ubuntu_bionic_arm64_hswitch_BUILDING.txt.gz
<pbek> that's the configuration: https://github.com/pbek/hswitch/blob/develop/build-systems/snap/snapcraft/snapcraft.yaml
<zyga> o.
<mvo> hey zyga ! good morning
<mup> PR core-build#30 opened: scripts: add fixrtc-munt script to fix time issues on pi2,3 <Created by mvo5> <https://github.com/snapcore/core-build/pull/30>
<mvo> zyga: right in time for -^
<mvo> zyga: I was thinking about the problem and the above seems like the quickest way out of the mess (especially since we want to release 2.34.2)
<mvo> zyga: WDYT?
<pedronis> what's the status of #5271 ?
<mup> PR #5271: cmd/snap: attempt to start the document portal if running with a session bus <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5271>
<pedronis> a 2nd review of #5515 would be great
<mup> PR #5515: daemon: make sure most change generating handlers can produce errors with kinds <Created by pedronis> <https://github.com/snapcore/snapd/pull/5515>
<mvo> pedronis: let me look at this one
<mborzecki> tests continue to be unhappy :(
<zyga> mvo: looking
<zyga> pbek: 18.04 is not fully baked yet,
<pbek> zyga: ah, thank you!
<mup> PR core-build#31 opened: add shellcheck on build and fix open issues <Created by mvo5> <https://github.com/snapcore/core-build/pull/31>
<mvo> zyga: I did a tiny fix and force pushed to #30
<zyga> I just noticed :)
<mvo> zyga: sorry, silly thing based on #31
<mup> PR #31: Feature/snapfs refactor <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/31>
<zyga> sorry for being slow, some interruptions at home and I'm the last one standing
<zyga> what was the change?
<mvo> zyga: for word in $(cat /proc/cmdline) must not be quoted
<mvo> zyga: I did this incorrectly in the initial push
<zyga> I see
<zyga> right
<mvo> zyga: its quite annoying that I had to disable the shellcheck test there but I don't see a good way to word split otherwise without using bash array (which we can't in initrd which uses ash iirc)
<mvo> zyga: "last one standing" - are you guys sick?
<zyga> mvo: not all sick but I'm the only one that can do stuff
<zyga> but all is good now
<mvo> ok
<zyga> as in: no fires, not starving, can work :)
<mborzecki> something funny about amzn, date --iso-8601=seconds -d 'tomorrow 8:05 UTC' yields '2018-07-27T08:05:00+0000', which does not parse in go, imo the output should be 018-07-27T08:05:00+00:00, https://play.golang.org/p/zfhZyaYpWKB
<mborzecki> heh fixed in 2015 https://git.savannah.gnu.org/cgit/coreutils.git/commit/src/date.c?id=17bbf6ce44eb543a95695fa9d2cbd70fb52c6f42
<zyga> mvo: reviewed
<zyga> mvo: thank you btw!
<zyga> mvo: lastly, this is something I would much much much rather write in C
<zyga> mvo: to break away from the mantra that we must endure shell
<zyga> mvo: the commit message is slightly wrong
<zyga> last mount time is updated
<zyga> but because of the mechanism I explained on the forum, it advances very slowly
<zyga> last write time is not updated
<mvo> zyga: ok, let me fix the commit message (is force push ok?)
<zyga> mvo: I'm looking the other way now ;)
<zyga> mvo: have you tried it on your device?
<mvo> zyga: not yet
<mvo> zyga: its a bit painful, I'm inclinded to merge and build a new edge core
<mvo> zyga: thanks for pointing the issue out, I will fix (it seems they were cargo culted)
<mvo> zyga: off-by-one space? I don't see this or look for the wrong thing, can you help me please :)
<NvpkD1y7Ez17> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<zyga> mvo: I'd suggest actually patching initrd in the wild unless that's very tough, iteration through master is slow
<zyga> mvo: there's one space ahead of "date", maybe tab-vs-spaces?
 * zyga wonders if the spam will stop anytime soon
<mvo> zyga: oh, probably tab vs space, its not visible for me
<zyga> mvo: also really think about coding this in C
<zyga> this is like 3 function calls, stat, current date,(conversion), comparison, set date
<zyga> (4 including some conversion perhaps)
<zyga> mvo: all the prereq stuff can go away
<zyga> all the cmdline stuff can go away
<zyga> it will never be off by a typo that we don't see
<mup> PR snapd#5515 closed: daemon: make sure most change generating handlers can produce errors with kinds <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5515>
<mvo> zyga: what do you mean by "iteration on master is slow"? what I have in mind is a) upload the fix b) test it c) build new core image with 2.34.2 and the fix d) push core image to beta/candidate
<mvo> zyga: is there an alternative that is quicker?
<pedronis> mvo: thx
<zyga> mvo: iteration through master -> build -> core snap -> refresh is slow
<zyga> mvo: I though that is what you meant
<mup> PR snapd#5434 closed: overlord: introduce InstanceKey to SnapState and SnapSetup, renames <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5434>
<pedronis> zyga: do you know what is the status of #5271 ?
<mup> PR #5271: cmd/snap: attempt to start the document portal if running with a session bus <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5271>
<zyga> pedronis: I don't think so, let me refresh my memory
<zyga> I mean, there was just the issue of old xdg-document-portal
<zyga> I will discuss this with jamie today
<zyga> old portal on a distribution
<mvo> zyga: hm, not sure I understand, sorry, maybe a bit slow this morning
<zyga> no worries,
<zyga> just do as you think is best
<mvo> zyga: hm, hm, we could look at /var/lib/snapd/state.json instead of /var/lib/snapd/snaps for the date, this would give us accurate time even on snap reverts which will not pull in new snaps into the /var/lib/snapd/snaps dir
<mvo> zyga: not-going-through-master> mostly worried I miss an important idea, maybe we can talk about it via a HO later so that you can explain your idea
<zyga> mvo: I was under the impression that you cannot test this now without merging it first and going through the automatic core build cycle
<mborzecki> Chipaca: could you take a look at #5559 ?
<mup> PR #5559: tests/lib/snaps: avoid using relative command paths that go up in the  directory tree <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5559>
<zyga> mvo: I was suggesting, if possible, to actually build and iterate locally as once you overcome the initial cost of setup this is much faster to iterate with
<Chipaca> mborzecki: no; looking now
<mborzecki> Chipaca: thx
<zyga> mvo: we can HO at any time if you want
<mvo> zyga: aha, got it now
<Chipaca> mborzecki: wrt /etc/os-release, I think we shouldn't be using the host's one
<mvo> zyga: I'm very confident in the fix :)
<mvo> zyga: but yeah, testing locally makes sense
<mborzecki> Chipaca: agreed, need to discuss the right solution with zyga though
<zyga> plus, anything you find and document as HOWTO will improve the next cycle :)
<mvo> zyga: I will wait for ogra_ and/or abeato to review https://github.com/snapcore/core-build/pull/30
<mup> PR core-build#30: scripts: add fixrtc-munt script to fix time issues on pi2,3 <Created by mvo5> <https://github.com/snapcore/core-build/pull/30>
<Chipaca> mborzecki: any reason not to implement dropping support for relative paths that  go outside the snap, and supporting absolute paths?
<Chipaca> mborzecki: other than it being a harder change i mean :-)
<mborzecki> Chipaca: frankly I haven't considered that at all, would be nice to know if there are any snaps in the wild that use this first
<Chipaca> mborzecki: there weren't when we checked last
<mborzecki> Chipaca: let me put that in my todo list then and i'll push that in a follow-up
<Chipaca> mborzecki: there's no rush imo
<Yoda22> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Yoda22> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<mup> PR snapd#5559 closed: tests/lib/snaps: avoid using relative command paths that go up in the  directory tree <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5559>
<ogra_> mvo, zyga ... do you actually want the boot to hang when setting the clock fails ?
<cjwatson> popey: It might be worth setting either +r (block unidentified users) or +q $~a (quieten them) here for a while to deflect the spam.
<zyga> mvo: no
<ogra_> mvo, i'D rather remove the -e and leave exit 0 in
<zyga> er, ogra_ no :)
<zyga> ogra_: yes, I commented about that
<cjwatson> JamieBennett: ^-
<popey> I am on vacation. If I op you cjwatson can you do it?
<cjwatson> Sure.
<ogra_> zyga, right, but only the exit 0 was removed ... and -e left in ... thats exactly the opposite of what i said ;)
<zyga> ah, I didn't see that
<zyga> mvo: ^ ogra is right
<zyga> we should not set -e this scrpit
<popey> Thanks
<zyga> and this highlights that shell sucks and this one should be C
* cjwatson changed the topic of #snappy to: Join the forum: https://forum.snapcraft.io/t/when-to-use-forum-vs-irc/38 | If you can't send messages here, authenticate to nickserv first
<zyga> popey: enjoy your time off, hide from IRC :)
<cjwatson> I'll leave myself opped in case I need to deal with any fallout from that
<zyga> thank you cjwatson !
<mvo> zyga: sure, let me fix that
 * zyga hugs mvo
<zyga> thank you!
<mvo> ogra_: might be worthwhile to do the same fix in the original fixrtc (remove the set -e)
<t1mp> hello
<mvo> zyga: shall I also use /var/lib/snapd/state.json?
<zyga> mvo: I'd keep using the directory
<zyga> mvo: and touch it in shutdown
<zyga> mvo: is the state.json _always_ guranteed to be there?
<zyga> guaranteed
<zyga> actually, we could even stat / itself
<zyga> and just touch that
<zyga> no chance for that to hide :)
<t1mp> I'm trying to package a python3 app using snapcraft. the snapcraft.yaml is pretty simple: https://pastebin.ubuntu.com/p/KHPy9d3Qr3/
<mvo> zyga: its not but thats easy enough to [ -f ] for
<t1mp> but I always get this error:
<t1mp>   Could not find a version that satisfies the requirement qmenta-gui (from qmenta-app==1.95.9) (from versions: )
<t1mp> No matching distribution found for qmenta-gui (from qmenta-app==1.95.9)
<mvo> zyga: touch on shutdown is one more moving part
<t1mp> because snapcraft uses pip to search for dependencies.. but in this case the dependency is not on PyPI, but in a previous part.. any ideas how I can resolve this?
<mvo> zyga: "/" might be readonly
<zyga> mvo: yes but note that state.json is also a moving part and it may still rewind the time in bad cases
<zyga> touching / on shutdown prevents that
<zyga> mvo: (where rewind time is that there are _any_ files in the filesystem that would appear from the future)
<t1mp> greyback_: :p
<mvo> zyga: with touch on shutdown I think the current PR is final now, I addressed the feedback from ogra_  and abeato
<zyga> mvo: thank you
<zyga> actually
<zyga> mvo: one more question
<zyga> mvo: what sets the "fixrtc" in the command line?
<zyga> I mean, does uboot on pi does that?
<mvo> zyga: its part of the gadget
<mvo> zyga: yes
<zyga> where is that specified
<zyga> aha
<zyga> would you feel ok not checking for that
<zyga> just dropping the whole cmdline parsing?
<zyga> after all, it cannot hurt
<zyga> if the time is more into the future we won't change it
<ogra> whoops, why am i OP ?
<zyga> and this would cut on complexity and need to teach other gadgets that this is a command line option and that it does something important
<ogra> mvo, agreen (regarding fixrtc) but that needs to happen in the distro package ...
<zyga> ogra: you have that special bit :)
<ogra> *agreed
<mvo> zyga: for this particular update I would prefer to keep the change as minimal as possible, because this will go into stable very soon (we need it to fix refresh issues)
<mvo> ogra: yeah, was just wondering alound, not urgent or anything
<ogra> zyga, well, i only changed my nick ... and registered ... wasnt aware that IRC keeps such states
<zyga> mvo: are you worried that the change could regress something elsewhere?
<cjwatson> ogra: baseline IRC doesn't, but chanserv has a configured access list for each channel
<cjwatson> (also you can register alternate nicks if you want to return to the underscored form ...)
<lool> abeato: here?
<ogra> cjwatson, nah, i'm fine i was just surprised
<mvo> zyga: yeah, risk is small but it would be super annoying
<mvo> zyga: especially since right now the impact is limited to a subset of devices, if it turns out there is a bug somewehre and it runs now on a magnitude more x86 device that would be bad(tm)
<ogra> zyga, we have fixrtc on the commandline of all relevant gadgets
<ogra> (just not on pc iirc)
<zyga> mvo: right but we must trust the code to DTRT where it matters
<mvo> ogra: I think zyga point is that the script should be safe everywhere so why bother checking
<zyga> mvo: I approved the PR and left two comments
<zyga> mvo: that essentially re-state those
<mvo> zyga: ta
<ogra> ah, k
<zyga> but I agree it's important to move
<mvo> zyga: yeah, lets do this minimal fix for now, maybe its just be being overly cautious
<mvo> zyga: thanks for the review and the ideas!
<mvo> ogra: I guess the bug itself is not reproducible, right? i.e. it happend to you but there is no way to bring the system into the state where it failed?
<ogra> mvo, just using a recent edge image and calling any "snap set" should expose it
<zyga> mvo: the time issue is easy to reproduce
<ogra> well ... hmm ... you might need to install an older one, install a snap with config hook and then update to latest edge actually
<zyga> mvo: the apparmor issue is something I'm exploring (outside of core, to show where it happens)
<zyga> s/where/how/
<ogra> so that there is an old cache file in place
<t1mp> is anyone here familiar with the python plugin?
<abeato> lool, ping
<lool> abeato: pong
<abeato> lool, ok looks like I can write here now, thanks :)
<abeato> zyga, hi, I am having some issues when opening a serial port from the modem-manager snap. I see https://paste.ubuntu.com/p/t92Wf3gdZ5/ , but no apparmor denials
<abeato> zyga, I created a small program that uses the same flags, and when run unconfined all is good
<abeato> this does not happens for USB serial ports, I wonder what is special here
<mvo> abeato: thanks for your script! its in now (and for the review)
<abeato> mvo, nice to see that merged in core, it was an issue we saw in some devices :)
<abeato> zyga, https://paste.ubuntu.com/p/qWV9FBzWtj/
<zyga> abeato: is that device present (major:minor) in the per-snap device cgroup?
<abeato> zyga, ah, cgroups, that might be the issue... I guess no, how can I check that?
<zyga> abeato: go to /sys/fs/cgroup/devices
<zyga> then look at snap.foo name groups
<zyga> then at various files, I think devices.allow is the one
<abeato> zyga, devices.list, and yes, I do not see the majour:minor for this device there, can this be modified from an interface?
<zyga> abeato: indeed it can
<zyga> abeato: this is the udev backend
<zyga> abeato: you can use a simple helper method to tag devices to add there according to udev rules
<abeato> zyga, got it, thanks
<mborzecki> pedronis: thanks for the review on snapsup/snapstate parts, do you think you'll get a chance to look at #5452 too?
<zyga> abeato: let me know if you need help
<abeato> :)
 * mborzecki wonders if he should try linux-hardened + apparmor on arch
<abeato> zyga, hm, so not sure how snap confine builds the list of cgroup devices, should not it add ttymxc6 as the modem-manager interface has '/dev/tty[^0-9]* rw,' in apparmor rules?
<zyga> no
<zyga> it's not related to apparmor in any case
<zyga> you need udev backend specification object to add a rule to tag a device at runtime
<zyga> abeato: look t...
<abeato> where can I find an example?
<zyga> https://github.com/snapcore/snapd/blob/master/interfaces/builtin/serial_port.go#L196
<zyga> look at anything that calls TagDevice
<zyga> I just found a random one
<zyga> the argument is a partial udev expresssion
<zyga> look at what happens to get a feeling about how this works
<zyga> it essentially expands to something like this
<zyga> if this-and-that-udev-expression-matches then append a tag to the device that udev is looking at, the tag is derived from snap name
<zyga> then snap-confine uses those tags to pre-populate the cgroup
<zyga> and also udev uses the same expression to add/remove devices as they are added/removed in the system (live changes)
<abeato> zyga, ah, got it now, thanks
<zyga> super, good luck!
<pedronis> mborzecki: yes, this afternoon
<mborzecki> pedronis: great, thank you
<mborzecki> pedronis: opened another PR #5561this is snapstate changes with run through tests
<mborzecki> #5561
<mborzecki> mup doesn\t work?
 * Chipaca kicks mup
<Chipaca> oh wait, that was lalita
<jdstrand> ogra: hi! have you ever seen this before: bbb-test kernel: [553472.131711] musb-hdrc musb-hdrc.1.auto: VBUS_ERROR in a_wait_vrise (90, <VBusValid), retry #3, port1 0008010c
<ogra> jdstrand, well, thats the micro USB driver that has never been rock solid
<ogra> though i dont remember this particular error
<ogra> smells like a wrong value in the dtb
<ogra> jdstrand, https://e2e.ti.com/support/arm/sitara_arm/f/791/t/324491?AM3352-USB-DRVVBUS-does-not-stay-active-when-device-connected#
<ogra> hmm, seems to also be triggered if the board is underpowered and the USB port draws too much current
<ogra> we should cross check that our kernel has all required MUSB options set http://processors.wiki.ti.com/index.php/MUSB_Linux_Driver_Configuration
<ogra> jdstrand, is that a new kernel ? i dont see the msg here with the latest stable linux-generic-bbb
<jdstrand> ogra: 4.4.0-93-1
<jdstrand> ogra: it is the first time I've seen it (saw it in my logs)
<ogra> do you have any USB devices attached ?
<zyga> ogra: hey, crazy idea
<jdstrand> ogra: no. I don't know if the ethernet is hardwired (I have the power and an ethernet cable plugged in)
<zyga> ogra: does pi have any form of RTC that runs as long as the board is powered?
<ogra> oh, i should probably push 4.4.0-127-1 from edge to stable :P
<zyga> ogra: and if so, could we at least retain RTC across reboot (not across poweroff)
<zyga> that would be neat IMO
<jdstrand> ogra: I do have the pings wired up for serial, but the usb end is not plugged into anything
<ogra> ethernet is hardwired ... not USB
<zyga> most of the time those devices will just reboot on upgrade
<ogra> jdstrand, let me release -127-1 to stable ... and lets see if you still get that ... i definitely dont have it in dmesg
<ogra> jdstrand, released ... let me know if you still see it after refresh
<ogra> zyga, no, sadly not, i was mixing it up with the dragonboard (that has an rtc but no battery .. pi doesnt have any rtc at all)
<zyga> nothing in the SoC ticks with 32K freq?
<ogra> dunno ... perhaps it does, but you'd still need to preserve the timestamp across a reboot
<ogra> there is definitely some kind of clock ... so you could count ticks, but i dont know if that doesnt get reset when you reboot
<ogra> did you look at that fake-hwclock from raspbian and how it works ?
<ogra> perhaps they have a better solution here
<kenvandine> mvo, i've been doing some profiling of desktop snaps and their first run being slow.  I've ruled out desktop-launch as the bottleneck
<kenvandine> desktop-launch elapsed time:  0.994528127
<kenvandine> Now running: exec gnome-calculator
<kenvandine> mvo, then it takes ~10-20 seconds for the UI to appear
<kenvandine> mvo, it looks like that exec is what's taking so long
<ogra> hmm, looking at the debian fake-hwclock script it does nothing with hardware, only reads and writes a file
<zyga> kenvandine: how do you measure?
<zyga> kenvandine: => forum is better
<zyga> kenvandine: but as a profiling case, run hello-world
<zyga> (shell)
<zyga> everything else is overhead of helpers and the app code itself
<kenvandine> yeah, that's fast... so it's puzzling
<kenvandine> i added some output to desktop-launch which shows the difference in time between the beginning and the end of the script
<kenvandine> the only thing i'm not timing is the exec itself
<zyga> I don't know desktop-launch
<zyga> can you collect this in the forum
<zyga> I bet we're missing something
<kenvandine> sure
<zyga> thanks!
<kenvandine> i'll post it
<ogra> desktop-launch does a ton of filesystem operations on first start ... but that shouldnt have much impact on second start of an app anymore
<kenvandine> ogra, i'm talking about the first launch
<ogra> ah
<kenvandine> i added profiling for that, and it's actually must faster than i thought
<kenvandine> but that exec is taking ages
<kenvandine> and that exec is much faster the second time
<ogra> well, you are calling out to other binaries from it, probably the exec is delayed till i.e. gdk-pixbuf-foo has run, fontconfig has generated everything etc etc
<kenvandine> yeah, i'm timing everything up until exec
<ogra> and you are sure the external binaries have all returned by then ?
<kenvandine> yes
<ogra> weird
<zyga> time the target of the exec
<jdstrand> kenvandine: is it possible that the desktop-launch script triggers things in the background and the app is somehow signaled (dbus, gsettings, something else) to proceed when the task is done? That could explain a fast script but slow launch (or the exec itself is doing a lot on that first launch because of glib/gtk/whatever)
<zyga> probably not the binary
<kenvandine> maybe it's loading all the libraries into memory the first time is slow?
<zyga> but just another layer of scripts
<zyga> kenvandine: rm -rf $SNAP_USER_DATA
<zyga> it will be slow again
<zyga> it's not the libraries
<jdstrand> loading all the libs would be slow after reboot. this is only after install/refresh afaik
<kenvandine> zyga, i am doing that for my testing
<zyga> also common I suspect
<kenvandine> i'm doing a reboot to see if that exec is slow again
<zyga> niemeyer, jdstrand: please let me know when you want to sync on the cache issue
<zyga> I will break for lunch now
<kenvandine> ah... that exec is slow again after a reboot
<kenvandine> so maybe it is all just overhead of library loading
<kenvandine> we do have quite a path
<zyga> that would be super odd
<zyga> do you have a HDD?
<kenvandine> yes... this is in a VM too
<zyga> kenvandine: aha
<zyga> kenvandine: as a "non scientific" ballpark test
<kenvandine> it is much faster in my laptop :)
<zyga> open a terminal after reboot
<zyga> run "dstat" in it
<zyga> let it run for a few seconds
<zyga> then run the app
<zyga> and correlate activity
<kenvandine> interesting
<zyga> it shows IP
<zyga> IO, CPU and lots of useful stuff
<zyga> in one simple format
<zyga> so you will see "aha, stuck on CPU, stuck on DISK, etc"
<kenvandine> rebooting to see
<kenvandine> but i did notice running a second gnome snap (which also uses gnome-3-26-1604 content interface) that exec is fast again.  So first run of the snap after reboot but the 2nd snap run that uses the content interface
<kenvandine> so maybe the libs from the content interface are loaded already
<kenvandine> zyga, dstat did see a jump in disk read on first run of the snap
<kenvandine> about 8M
<kenvandine> but then next to nothing on the 2nd run
<kenvandine> actually 8M and then almost immediately after that 10M
<kenvandine> then on the 2nd run the biggest spike was 102k
<kenvandine> zyga, then on additional runs there is no disk reads
<zyga> IRC spam intensifies
<cjwatson> /mode <yournick> +R may help
<cjwatson> (block /msg from unregistered users)
<zyga> oh, that's very useful, using that now!
<roadmr> TIL about that on #freenode, but if it doesn't help I'll probably have to stay off freenode until that crap blows over :/ it's very upsetting
<cjwatson> Those sort of basic strategies seem to be working OK so far
<mvo> kenvandine: just read backlog, sorry, was busy with core18 work :/
<mvo> pedronis: your opinion on 5563 would be great, its a bit minimal (too much?) right now
<kenvandine> mvo, no worries
<kenvandine> i really think it's library loading
<kenvandine> mvo, i've got it covered :)
<mvo> kenvandine: excellent
<Chipaca> pedronis: niemeyer: #5187 is ready for a (n+1)th look
<pedronis> mvo: I commented a bit
<mvo> pedronis: thanks!
<mvo> pedronis: sure, I will add checks on the assertion level
<mvo> pedronis: thanks for the review
 * mvo has fun with kernel crng blocking the boot of core18 in the meantime
<pedronis> Chipaca: I forgot 5187 is dauntingly big
<Chipaca> pedronis: â¦ maybe :-)
<pedronis> Chipaca: so  forget and check don't touch snaps,  but they touch things that restore and save touch?
<Chipaca> pedronis: yes
<pedronis> ok
<pedronis> Chipaca: I skimmed a bit but I'll look at it seriously in the morning I think
<Chipaca> pedronis: that is fair
<jdstrand> niemeyer, mvo, zyga: fyi, gave jjohansen the context of most recent issue. he'll be ready in a little bit for the meeting and can ping us
<zyga> great, thank you jdstrand
<zyga> jdstrand: btw, did you see my reply on https://forum.snapcraft.io/t/apparmor-profile-caching/1268/21
<niemeyer> Thanks!
<jjohansen> jdstrand, zyga, niemeyer: okay I'm available
<zyga> hey!
 * jdstrand is ready
<jdstrand> mvo: ^
<zyga> where shall we go?
<jjohansen> some where with a nice sandy beach, good weather and free drinks
<jdstrand> niemeyer, zyga, mvo, jjohansen: https://meet.google.com/tdg-hhbb-dip
<niemeyer> omw
<mvo> omw as well
<jdstrand> mvo (cc niemeyer, zyga): can you ping us if the strategic use of --skip-read-cache is deemed infeasible, which would escalate the priority on our end. If you have that change, then we can go through the proper channels on prioritizing this, but if you don't, jj and I will defend starting early
<zyga> jdstrand: ack, Iâm just staring on the patch right now
<jdstrand> zyga: thanks
<zyga> :-)
<jdstrand> rbasak: hey, so for the moment I have not granted classic. can you ping me if there is agreement to grant it early?
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/5564
<zyga> jjohansen: ^
<zyga> ah
<zyga> well, #5564
<zyga> :)
<zyga> PR 5564
<zyga> mup must be on holiday s:)
<zyga> jjohansen: https://github.com/snapcore/snapd/pull/5564
<FreeBDSM> how to get a snap of firefox 52.9.0 ESR?
<jjohansen> zyga: that looks okay
<zyga> jjohansen: great, thank you!
<zyga> FreeBDSM: I think you should ask in #mozilla about that, it's their snap, they are the publisher
<pedronis> the esr track has 60.1
<FreeBDSM> zyga: I think they hate their users
<pedronis> (afaict)
<zyga> pedronis: yeah, I checked,
<zyga> FreeBDSM: I don't think they do that but it's the question you should bring to mozilla
<FreeBDSM> zyga: it's pointless to do
<FreeBDSM> they want me to install their fresh bullshit, I refuse to
<FreeBDSM> so, snap goes against freedom as well :(
<zyga> ultimate freedom is anarchy, snaps are here to improve on known issues, it cannot be everything for everybody but we are here do make the world better
<FreeBDSM> not at all
<FreeBDSM> you could just store old versions
<FreeBDSM> but you don't
<abeato> t
<ogra> FreeBDSM, was 52.x ESR ever in the snap store ? (i dont think it ever was, so blaming us is a bit unfair, dont you think)
<FreeBDSM> ogra: looks like it was
<FreeBDSM> ogra: I get google links pointing to snap of firefox-esr 52.9.0 but now there's a more recent version
<ogra> AFAIK the first release to the esr track was 59.xx
<ogra> (and that was not promoted since it was a pre-release, they only announced esr availablility with 60)
<zyga> FreeBDSM: if debian had stored it it would also go away over time, that's not a fair thing to say, we actively give the developers the choice to publish old versions as tracks but we don't allow people to just get any version from the past because that is insecure and snaps are here to solve the update issues
<ogra> if you had a former version installed you can defiitely revert to it using snap revert though
<FreeBDSM> `we don't allow people to just get any version from the past because that is insecure` - b/s
<ogra> so nobody *forces new stuff on you* ... quite the opposite with snaps, they allow you to go back without breaking
<ogra> (that indeed only works if you had a former version)
<FreeBDSM> yes, and this approach sucks
<ogra> well, the rollback is a local thing ...
<FreeBDSM> wouldn't be a local thing, if repo had older versions available...
<zyga> FreeBDSM: it's your opinion
<FreeBDSM> just like mozilla has ALL of it's versions available for public...
<FreeBDSM> zyga: no, it's not, it's just some common sense
<zyga> FreeBDSM: you can always get mozilla from source and build it yourself
<FreeBDSM> zyga: which is like re-inventing a bicycle
<zyga> FreeBDSM: no, it's not common sense
<zyga> FreeBDSM: to argue you should present some facts
<zyga> FreeBDSM: not "common sense" or "b/s"
<FreeBDSM> Fact A. people sometimes want particular version of software
<zyga> FreeBDSM: I don't actually want to argue tonight, I'm just pointing out this is an opinion of yours, not a fact that is universally agreed upon
<FreeBDSM> Fact B. snappy/flatpak/etc. was partially invented to make self-contained builds distribution.
<FreeBDSM> Fact C. You say it's up to upstream to decide what to upload to your repo
<FreeBDSM> Fact D. You say you don't store older uploaded snaps because 'that is insecure'
<ogra> who said that ?
<FreeBDSM> Fact E. Uploader of snaps (mozilla) has their older versions publicly available.
<FreeBDSM> Fact(?) F. (from what I understood) Mozilla decided to turn off the availability of the previous version of firefox as a snap.
<FreeBDSM> ogra: grep the channel log
<zyga> FreeBDSM: I didn't say we don't store old revisions, we do store them, we don't allow everyone to install old revisions
<pedronis> the log says we don't allow to some degree to get them
<pedronis> the issue is really that only the maintainer can decide what is maintained
<FreeBDSM> zyga: I'm not everyone, please, let me download it
<zyga> FreeBDSM: only mozilla can do that
<FreeBDSM> pedronis: that is a dictate
<ogra> lol
<FreeBDSM> zyga: well, a poor decision on your part then to make it so.
<pedronis> it's trade offs all the way down like turtles
<FreeBDSM> yeah, that lead to digital dictate
 * ogra waits for godwins law invocation ...
<zyga> FreeBDSM: that's your opinion
<pedronis> the maintainer can create tracks for all the things maintained
<FreeBDSM> `we don't care what you think about what we've recently did, you either just update and agree to our terms, or FU and good luck building an older version yourself`
<pedronis> they have that option
<FreeBDSM> pedronis: a maintaner may have semi-evil intents
<pedronis> otoh I expect some of them not to want to  let unmaintained stuff get installed
<ogra> FreeBDSM, well, alternatively convince the responsible people to make it availble to you
<ogra> the responsible people being mozilla here ... the store is just a tool ... they drive it
<FreeBDSM> ogra: you've made responsible some scum, no chance I'm going to convince them shit
<zyga> FreeBDSM: you can take firefox, build a snap and upload any set of tracks that have every release
<zyga> FreeBDSM: but mozilla chose not to
<zyga> FreeBDSM: you can still do that
<zyga> FreeBDSM: you can also recommend your version to everyone
<zyga> FreeBDSM: but mozilla recommends theirs
<ogra> FreeBDSM, so why are you arguing with us now ?
<FreeBDSM> ogra: because it was your poor decision to make some scum responsible
<FreeBDSM> bad ideas are bad ideas
<FreeBDSM> zyga: I could take firefox and build it statically and forget about snap as a bad dream as well.
<ogra> FreeBDSM, well, you are trolling and arguing abour an app version with us that was never packaged as a snap making us responsible for the fact that you can not get it as a sanp
<ogra> *about
<FreeBDSM> with that kind of argument snap is useless
<FreeBDSM> ogra: no, you are trolling
<ogra> huh ?
<FreeBDSM> go troll someone else
<ogra> read the backlog please
<zyga> FreeBDSM: we can keep this discussion civilized or use words like "scum" and let you talk to yourself
<ogra> you are probably the most aggressive person i have seen in this channel in the last half year
<FreeBDSM> your nickname is like an ogre, ogres are like trolls, thus you are a troll.
<ogra> sure ...
<zyga> ogra: use your @
<FreeBDSM> check and mate
<ogra> in any case your complaints wont go anywhere, nobody of us can make esr52 available to you since it never existed in the snap store ...
<FreeBDSM> well, I understood it quite some time ago
<FreeBDSM> I just wanted to ridicule you
<ogra> so why are you still agruing
<FreeBDSM> because the situation is ridiculous
<ogra> it is as it is
<FreeBDSM> you've created an awesome util that's able to solve a problem
<ogra> if you want esr52 ask FF to upload it to the store
<FreeBDSM> and you make your ecosystem SO, that the problem won't be solved
<FreeBDSM> kind of, defies logic
<FreeBDSM> why bother with snap then?
<ogra> well, thats your POV
<ogra> dunno
<ogra> why do you ?
<FreeBDSM> I don't
<FreeBDSM> I just realized it's useless
<ogra> so why are you coming here then
<FreeBDSM> thus I won't use it
<FreeBDSM> ogra: read above
<FreeBDSM> to ridicule you
<ogra> thats fine and totally your right
<FreeBDSM> thanks
 * mvo calls it a day with an almost booting 4.15 kernel on core18
<FreeBDSM> it is also your right to waste your time making X and then taking decision Y which nullifies the profits of X
<zyga> FreeBDSM: let us agree that you have some opinion of how snaps are designed and we have another
<FreeBDSM> no
<FreeBDSM> snaps can be used for distributing fat packages
 * ogra fully agrees :P
<zyga> FreeBDSM: can we have our opinions without you being offensive?
<FreeBDSM> I'm not offensive
<ogra> lol
<FreeBDSM> you are being too defensive
<zyga> you are not kind, you don't try to understand our opinion
<FreeBDSM> defending what?
<FreeBDSM> I understood your opinion
<ogra> but you dont respect it :)
<FreeBDSM> you wanted to delegate as much as possible
<zyga> you came here to say we are ugly and stupid because we didn't do what you think
<FreeBDSM> I get it
<ogra> i didnt say "get"
<FreeBDSM> zyga: no, I didn't
<zyga> we want you to appreciate our opinion and the reasons for the design before you say this is stupid
<zyga> we can share that design vision with you if you are willing to listen
<FreeBDSM> I came here to say you've made an awesome tool, but you've made some horrible decisions about the way the infrastructure/service/ecosystem around that tool is built which in _some_ cases nullifies the pros of the tool
<zyga> but this has to be a civilized discussion because otherwise I don't think anyone will be interested in spending their time
<ogra> well, you didnt say it in that tone :)
<zyga> that's much nicer
<ogra> yes
<zyga> yes, now we can discuss pros/cons and the why's
<FreeBDSM> well, I wanted to ridicule you, after all, so I just had to make it as absurd as possible to make the point as obvious as possible
<zyga> let's suppose mozilla did upload ESR 59
<FreeBDSM> okay
<zyga> and it was in the store (I don't know if that's true or not(
<ogra> it was
<FreeBDSM> let's suppose it was
<zyga> FreeBDSM: believe me, if this was a face to face conversation it would not be received well
<zyga> FreeBDSM: now let's suppose we allow anyone to download any revision
<ogra> then they updated to 60 and annoounced the availability
<zyga> this is something we reserve to the publisher of the snap
<zyga> since they can publish any revision they can also get any revision
<zyga> how would the user experience look like?
<FreeBDSM> zyga: believe me, it'd be go way better, as text doesn't express my emotions
<zyga> you can get revision 12351 that happens to be firefox 59.0.1 build 7 (for example)
<zyga> what would happen next? do you stay there forever?
<zyga> do you move to 60.0 in half an hour
<FreeBDSM> I tell you
<zyga> do you move to 60.1 as soon as it is out?
<FreeBDSM> my answer is 'let the user decide'
<FreeBDSM> If they want to update - let'em
<zyga> out of that set, there's only one answer that's clearly insecure: stay on 59 *especially* in a browser
<FreeBDSM> if they refuse to update - let'em
<zyga> FreeBDSM: but the users cannot decide, this is well known that they don't understand security and only care about convenience
<FreeBDSM> don't fool yourself into thinking that you know better what's better for the user. you don't. period.
<zyga> if update was opt-in a large population of the users would never update and would be on the insecure version
<zyga> FreeBDSM: I'm curious, how many CVEs are in 59.0 that were fixed in 60.0
<FreeBDSM> zyga: the stupidest users don't know what linux is.
<FreeBDSM> zyga: they user the OS that came with the laptop
<FreeBDSM> and they ask their 'computer boi' to 'fix it when it gets to pornful'
<zyga> FreeBDSM: well, we are building a coherent experience for our users, snaps are aiming to provide something better than what we had
<zyga> so as a part of that design we said we would not allow people to just stay suck on old revision
<FreeBDSM> I believe that you had best intentions
<zyga> because even if they don't want to be insecure
<zyga> they don't understand the consequences
<FreeBDSM> but there's a saying: 'best intentions lead to hell'
<zyga> and they can be easily fooled into following a set of instructions that keeps them stuck forever
<FreeBDSM> they do understand the consequences
<zyga> we've seen this time and again
<FreeBDSM> every ubuntu monkey knows how to update
<zyga> countless forum posts with instructions on how to pin a package
<FreeBDSM> if someone doesn't - let the suffer
<zyga> or download a random deb or rpm
<FreeBDSM> that's their choice to be stupid
<zyga> you say "let them suffer"
<ogra> you miss the point
<zyga> I say "I want to make the world better"
<zyga> that's what we _chose_ to do
<ogra> it isnt *them* who sufferes alone
<FreeBDSM> and back to godwin's law
<zyga> the linux landscape is full of harder options
<FreeBDSM> hitler wanted to make the world better as well
<zyga> nobody is forcing you or like-minded people to use snaps
<ogra> they will file bugs that someone needs to handle
<zyga> ogra: there you go
<ogra> they will ask support questions that someone needs to deal with
<FreeBDSM> yup
<FreeBDSM> boil point
<ogra> they take away working time of mozilla devs to fix issues in a newer version
<FreeBDSM> no reason to continue the argument because you think you know better than the users what is better for them
<FreeBDSM> just like some gov
<FreeBDSM> I despise such approach
<ogra> o it is mozillas decision if they want to cope with that
<ogra> *so
<ogra> they obviously dont
<ogra> so they picked to only offer the latest esr
<FreeBDSM> this always leads to what's described in Orwell's antiutopias
<ogra> the store allows you to open tracks, and offer any number of versions you want to your users
<ogra> they decided not to
<FreeBDSM> mozilla is compromised. period.
<FreeBDSM> they chose the evil path.
<FreeBDSM> let them rot
<ogra> this is *again* not our decision and you deny to accep that fact
<ogra> the tool has the capability
<FreeBDSM> the fact that any organization may make turns in their path
<FreeBDSM> and become evil
<FreeBDSM> and the fact that you delegate too much to organizations
<FreeBDSM> just 2 facts
<ogra> well, thats a topic for #mozilla i guess
<FreeBDSM> nope
<FreeBDSM> mozilla does what it does
<FreeBDSM> it now does evil things
<ogra> and nobody here can change that
<ogra> and nobody here can change that either
<FreeBDSM> but you do stupid things when you let evil corps lock older versions
<ogra> we dont do *things*
<FreeBDSM> and you could change that
<ogra> we offer a tool
<FreeBDSM> you also offer a service, don't ya?
<FreeBDSM> a repo
<ogra> yes, thats the tool i'm talking about
<FreeBDSM> the tool is great, I'm here to blame the service
<ogra> it is super easy to offer a track for each version of firefox ever released in that tool
<FreeBDSM> I'm not sure I understood what you just said
<ogra> but the publisher of that ackage decided to not do that
<FreeBDSM> and back around
<FreeBDSM> you let the publisher do evil things
<FreeBDSM> now you just say `we dindo it! they did!`
<ogra> so again ... in easier words ... the snap store allows a publisher to make all versions available ever released as snaps in different tracks if he wants
<zyga> FreeBDSM: we shared why snaps work the way they work
<ogra> there is no limitation in snaps, snapd o the store here
<zyga> FreeBDSM: you shared your opinion how how that is wrong
<FreeBDSM> so again, it was your decision to make it so
<zyga> FreeBDSM: we disagree on principles
<FreeBDSM> it was a bad decision (IMO)
<ogra> if *you* would want to do that with a package fo yours you could do that at any time
<zyga> FreeBDSM: let's be civilized and carry on, the great thing is that you can make a better system
<kyrofa> Hey zyga, can you explain why we just split instead of supporting shell quoting? https://github.com/snapcore/snapd/blob/master/cmd/snap-exec/main.go#L181
<zyga> FreeBDSM: convince us we were wrong by doing something better
<ogra> just have a track for each version ever existing
<zyga> kyrofa: hey
<zyga> kyrofa: I suspect the answer is "gulp" but let me look
<FreeBDSM> (Â·Ì¿Ä¹Ì¯Â·Ì¿ Ì¿)
<zyga> https://github.com/snapcore/snapd/blob/master/cmd/snap-exec/main.go#L178
<zyga> is the comment above any good?
<zyga> kyrofa: we split because we apparently refuse shell quoting and other magic stuff
<zyga> kyrofa: so we split because the input is super restricted where that is the equivalent operation
<zyga> (that's much better than "gulp" I said above)
<kyrofa> zyga, the comment talks about how safe it is, but won't this blow up if the command name actually contains a space?
<zyga> kyrofa: can you give me an example please?
<ogra> a command name that contains a space ? in shell ??
<kyrofa> Yeah, let me actually verify my hypothesis
<zyga> kyrofa: I think we disallow that but not explicitly, the command _is_ the first word
<zyga> kyrofa: and since we don't allow quoting
<zyga> that's that
<ogra> i dont think thats possible in shell
<zyga> ogra: I suspect it is
<zyga> but very evil :)
<ogra> zyga, commands with spaces in the name ?
<zyga> yeah, just try it
<ogra> unless you do weird escaping the thing after the space will always be interpreted as the first arg
<FreeBDSM> zyga: ogra: by the way, thank you for the civilized discussion. Although I didn't cross any lines I know I sounded trollish (making the situation as absurd as possible -it just a way to argue).
<zyga> well, "weird escaping" is just escaping
<ogra> heh
<FreeBDSM> it's a pity that we disagree
<ogra> FreeBDSM, well, you didnt get me ... the store actually allows what you want
<FreeBDSM> ogra: it allows if I'm to become a maintainer
<ogra> so while we might disagree in principle, what you want it in fact possible
<ogra> it is just that mozilla decided not to
<FreeBDSM> and that defies the logic: why would I bother uploading stuff if I could just built something for myself and just use it?
<ogra> and we dont force anyone
<pedronis> kyrofa: we don't suppor quoting, so we also don't support commands with spaces in practice
<ogra> dunno, because you are a social person that wants others to benefit from it too ?
<FreeBDSM> ogra: please, don't repeat yourself, I already told you my counter-argument to that.
<zyga> FreeBDSM: calling mozilla compromized, us evil and users stupid feels a bit strong IMO
<ogra> definitely
<FreeBDSM> ogra: I am an asocial person and I want comfort for myself first and I neither care, nor mind about the comfort of others.
<roadmr> FreeBDSM: sorry, you did cross a line
<zyga> at least I hope you can understand _why_ we made the decisions you disagree with
<ogra> FreeBDSM, well, then you probably wont package what you built as a snap ... perhaps fame could bribe you ?
<ogra> roadmr, multiple :)
<FreeBDSM> zyga: 1. I didn't call you evil, I called mozilla evil. 2. you called users stupid and I said `that's their freedom to be stupid, you have to respect that`. 3. mozilla is in fact compromised and is now malicious.
<FreeBDSM> roadmr: no.
<roadmr> yes
<FreeBDSM> where?
<kyrofa> zyga, pedronis ah, indeed, quotes in the command actually result in an invalid snap
<roadmr> there
<ogra> well, by democratic vote of the people speaking here for the last hour you definitely did
<FreeBDSM> trollin, I see
<zyga> FreeBDSM: I don't think people are stupid, I do believe most of us are ignorant about the vast majority of topics
<zyga> FreeBDSM: most people are highly ignorant of security threats
<zyga> FreeBDSM: of how the software they use works
<FreeBDSM> zyga: okay. And that is fine.
<zyga> FreeBDSM: or what the consequences are
<FreeBDSM> warn them and go on
<FreeBDSM> do not limit them forcefully
<zyga> FreeBDSM: for that we _chose_ to do something so that would be less hurt by their decisions _despite_ being ignorant abou tthat
<FreeBDSM> because this is the road to hell
<zyga> FreeBDSM: we chose not to do this for the reasons I stated already: humans largely ignore security because they are ignorant about it and choose convenience
<kyrofa> zyga, pedronis so we don't expect any command args to have spaces either, then?
<zyga> FreeBDSM: to effectively make their lives better by handling security we took that option away
<zyga> kyrofa: not in the snap.yaml
<FreeBDSM> zyga: that can be very well rephrased into `we think we know better than the users what is better for the users, we will force our decision onto the users, because majority of users is stupid`
<pedronis> kyrofa: yes, no quoting anywhere, we don't support ' or "
<zyga> kyrofa: we need to improve that part to allow it
<pedronis> in the commands
<pedronis> atm
<zyga> FreeBDSM: no, that's totally not what I said
<zyga> FreeBDSM: I chose the words I used very carefully
<FreeBDSM> that's exactly how I understand it
<zyga> being ignorant is not being stupid
<zyga> FreeBDSM: well, you are ignorant of the meaning of the word ignorant then
<FreeBDSM> okay, read 'stupid' as 'ignorant'
<zyga> FreeBDSM: I am ignorant of tons of things
<FreeBDSM> doesn't change the meaning of the sentence much
<zyga> FreeBDSM: I don't know how to make electricity safe
<FreeBDSM> `we think we know better than the users what is better for the users, we will force our decision onto the users, because majority of users is ignorant`
<ogra> it totally changes the meaning
<zyga> FreeBDSM: I accept that some people do and I let them handle electric wiring at home
<ogra> one is an insult, the other isnt
<zyga> FreeBDSM: this is quite like that
<FreeBDSM> ogra: in my opinion it changes it a very little
<zyga> FreeBDSM: as I said before, total freedom is anarchy
<zyga> FreeBDSM: and we're not here to give people total freedom because we believe there's a better way
<kyrofa> Thanks zyga, pedronis. Makes what I'm working on simpler, although soon folks will be exposed to that limitation (right now snapcraft users aren't), so we might think about changing it if we get complaints
<zyga> FreeBDSM: those are choices we actively took to make the world better
<FreeBDSM> I find this of all your choices bad
<zyga> FreeBDSM: we cannot change humanity's knowledge about modern software issues, threats or consequences of certain actions
<zyga> FreeBDSM: we did the thing we could
<FreeBDSM> you could not use restrictions
<FreeBDSM> I think it would be better
<zyga> that's okay, nobody is holding a gun to your head asking you to love snaps or die
<FreeBDSM> it would be more fair
<FreeBDSM> but you are against fair
<zyga> you can think that too,
<FreeBDSM> because you think you know better
<zyga> we're just saying we disagree and this is how this project is designed to operate
<zyga> you also think you know better
<zyga> you think you know better than some of us do
<zyga> that's okay, you can do that too
<FreeBDSM> I understand, I'm criticizing the obvious flaws of your design, that's all
<FreeBDSM> not the whole idea, just the flaws
<roadmr> and you're saying it too, FreeBDSM : you say "in my opinion", "I think", "I find". Sounds like an agreement to disagree
<zyga> in absence of measurable data to the contrary we will hold our design firmly
<zyga> so far we've seen the world of old software that is never updated
<ogra> but what you see as flws might be seen as benefits by others ... can you accept that fact ?
<zyga> because it's hard or inconvenient
<FreeBDSM> in absence of data one can apply logic and logical experiment, logical judgement
<roadmr> or compare people to hitler
<zyga> we've seen threats spreading around the planet in half a day
<zyga> FreeBDSM: we have tons of data
<FreeBDSM> like what?
<zyga> FreeBDSM: security is very important to idea of snaps and the people who made them
<zyga> FreeBDSM: many of the same people were working on ubuntu and other distributions and saw first hand the impact of security issues
<zyga> FreeBDSM: and looking at the larger ecosystem and insecure old software being the de-facto norm we didn't want to repeat those mistakes
<FreeBDSM> what is a snap?
<FreeBDSM> in 1 sentence, please
<zyga> FreeBDSM: I'm sorry, do you understand my points?
<FreeBDSM> zyga: I understand them, I'm going to prove you are wrong
<zyga> I'm not playing
<FreeBDSM> zyga: what is snap in 1 sentence.
<zyga> I don't want to talk to you anymore, you made your point
<FreeBDSM> is it a tool to bring security?
<FreeBDSM> no
<zyga> I tried to do my best to explain my view
<FreeBDSM> it doesn't and can not solve the problem of the security
<zyga> please get some rest, enjoy fresh air, ride a bike, talk to friends
<zyga> if you want re-read this conversation piece by piece
<ogra> he said he's antisocial ... no friends ....
<FreeBDSM> containers solve some part of the problem of security, firewalls solve another part of the problem of security, anti-viruses solve another part of the problem of security, but snap is neither of them.
<zyga> I was generous to spend a good chunk of my evening to explain my motivation and the design behind snaps
<zyga> but I'm not offering to argue ad infinitum about that
<zyga> so enjoy, maybe someone else will continue the conversation
<FreeBDSM> most of the time you've repeated yourself and stood deaf towards counter-arguments
<FreeBDSM> so you didn't really argue
<zyga> you came here to say the design is wrong, I explained the design first because you didn't seem confident knowing that
<zyga> anyway, EOT
<ogra> +1
<roadmr> cheers zyga \o/
<zyga> :-)
<FreeBDSM> that's disappointing
<FreeBDSM> when people refuse to argue - they refuse to change
<FreeBDSM> when they refuse to change - they get obsolete pretty fast
<FreeBDSM> these are the laws of nature
<FreeBDSM> but still, I respect that at least you behaved in a civilized way
<FreeBDSM> I really came here to just ask if maybe some other user would share their snap with me
<zyga> hmm, /bin/bash: line 60: killall: command not found
<zyga> + echo 'Ensure no stray sleep processes are around'
<zyga> Ensure no stray sleep processes are around
<zyga> + killall sleep
<ogra> zyga, dont use killall ...
<ogra> use pkill
<zyga> we probably lack killall in the core snap
<ogra> killal isnt a standard
<zyga> funny that the test was written with killall before
<zyga> I just kept using it
<ogra> pkill is a standard iirc so that should be there
<zyga> thanks
<zyga> killall is not in the core snap
<zyga> that code never ran ^_^
<ogra> well, and you obviously dont set -e
<ogra> else it would have exploded in your face :)
<ogra> (or at least exited nonzero)
<zyga> it's more funny than that :D
<zyga> patch incoming
<ogra> oh my
<zyga> https://github.com/snapcore/snapd/pull/5566
<zyga> :)
<zyga> I did git grep in the root of the tree so that's all of them
<ogra> LOL !
<ogra> is that the "skype kills my session" issue ?
<ogra> (looking at the wayland interface ...)
<zyga> no, that's just a test
<zyga> skype caused a segvfault in X
<ogra> ah, right
<zyga> no idea why
<ogra> yeah, i missed the test/ at the beginning of the path
<ogra> *tests
<ogra> zyga, oh, btw, looks like nobody from ym team is invited to the sept. thingie ... so no beer :(
<ogra> *my
<zyga> oh
<ogra> yeah :/
<zyga> join me at flock! :)
<ogra> heh
<zyga> it's in Dresden
<zyga> is that far from you?
<ogra> 2-3h
<zyga> well, :)
<zyga> just sayin'
<zyga> jdstrand, jjohansen: is apparmor in 4.15 able to discover paths "across" bind mounts in a way that didn't exist in 4.4?
<zyga> debugging a very very curious issue
<zyga> we're seeing a denial
<zyga> this is the profile:
<zyga> http://paste.ubuntu.com/p/BSVrZV68RJ/
<zyga> this is the denial:
<zyga> [  318.394972] audit: type=1400 audit(1532637900.980:30): apparmor="DENIED" operation="file_mmap" profile="snap-update-ns.test-snapd-tools-core18" name="/snap/snapd/452/usr/lib/snapd/snap-update-ns" pid=1054 comm="3" requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0
<zyga> notice that it talks about snap-update-ns from the *snapd* snap
<zyga> the same profile works on 4.4
<zyga> in both cases (so on 4.4 and 4.15) snap-update-ns is actually opened from /snap/snapd/(some revision)/usr/lib/snapd/snap-update-ns
<zyga> now, having said that
<zyga> we also bind mount /snap/snapd/(revision)/usr/lib/snapd/ to /usr/lib/snapd/ on the host
<zyga> I may have a partial picture for now, this is still something we are exploring
<zyga> any advice on how to debug this would be great
<zyga> I'm looking for the knobs to enable kernel-level debugging of apparmor LSM
<zyga> do we need a better kernel for that (better = extra options)
<zyga> again, my kernel tree is in my home office so it's hard for me to check
<zyga> oh and I forgot to mention
<zyga> the denial went away after we tweaked the profile
<zyga> to allow snap-update-ns to come from either the core snap
<zyga> or from snapd snap
<zyga> it's just unclear to us why exactly this happened on 4.15 kernel (running core18+snapd) and not on the 4.4 kernel (also running core18+snapd)
<jjohansen> zyga: no
<jjohansen> my guess is a change in dpath but it could be something to do with mount flags and mount
<jjohansen> I'll have to dig
<zyga> jjohansen: any hints for us on how to look?
<jjohansen> zyga: well I can tell you its not in the apparmor commits
<jjohansen> its something, mount/namespace related
<zyga> can we somehow dump the checks that apparmor is doing?
<jjohansen> and its probably going to take bisect to trace down
<zyga> or get more context about the denial before we patch it
<zyga> ouch
<zyga> I mean, we will just add the patch that allows "snapd" in the path but it is curious what happened
<jjohansen> it is curious
<zyga> I will work with mvo tomorrow to get to a case we can easily reproduce and share
<zyga> so far it's 'elaborate' to do so perhaps the bug is elsewhere
#snappy 2018-07-27
<mborzecki> morning
<zyga> Good morning
<zyga> mvo: no apparmor changes in that window would cause that. For now this is unknown, perhaps other parts of the kernel did change
<mvo> zyga: hm, hm
<mvo> zyga: thank you
<mborzecki> zyga: mvo: hey
<mborzecki> zyga: something fishy going on in #5566
<mvo> mborzecki: hey
<zyga> I need to prepare breakfast for my daughter first
<zyga> mvo: also the stop signal test had one more bug!
<zyga> I sent a PR but perhaps not fully correct
<mvo> zyga: ok
<mvo> zyga: woah, yet another bug :(
<Chipaca> in other news, people keep on using 'disable' and finding bugs
<Chipaca> :-)
<mvo> Chipaca: thanks for tackling them!
<Chipaca> mvo: :-)
<Chipaca> I fixed them and no tests broke
<zyga> ok, ttyl, really need to make that bfast
<Chipaca> so, er, need to write tests :-)
<mvo> Chipaca: /o\
 * mvo hugs Chipaca 
<Chipaca> anyway, off to the gym before the day gets melty
<Chipaca> ttfn
<mvo> good plan! ttfn
<pedronis> Chipaca: reviewed the snapshotstate PR, looks good overall
<mvo> pedronis: I updated 5563 to add more checks
<pedronis> mvo: so the bit of bad new is that so far we tried to not import snap into asserts
<pedronis> (because asserts is used in places that are not snapd)
<mvo> pedronis: ok, I can revert that part and just parse manually
<mvo> pedronis: its not that much its needed for
<pedronis> but we will have the problem going forward
<mvo> zyga: OMG 5560 is green
<mvo> pedronis: either way is fine with me, for this particular case its easy enough to do the checks without importing the channel parser
<pedronis> mvo: that would be easier, I think if we need the struct later we can make a subpackage of snap
<mborzecki> pedronis: pushed some updates to #5452, switching between this and #5561 makes it a bit like brain surgery unfortunately
<mvo> pedronis: ok, I will undo the import and just parse the relevant bits by hand
<pedronis> mborzecki: I'm a bit confused,  5561 is not based on 5452 ?
<mborzecki> pedronis: no there are sort of in parallel
<pedronis> mborzecki: I'm not sure I'm up to that
<pedronis> it sounds confusing to me
<mborzecki> pedronis: otherwise the diff would be much larger
<mborzecki> pedronis: i suppose i can merge master into 5452 and rebase 5561 on top of it if it makes it easier to review
<pedronis> IÂ don't know
<pedronis> I'm just getting confused by some of the last comments in 5452
<zyga> rere, bfast and housework done, let's hack
<mvo> pedronis: this is updated now
<zyga> mvo: see, the world is not on fire ;)
<zyga> mvo: approved
<zyga> mvo: I need to focus on image factory, I spoke with upstream developers about my plans and got some super useful advice
<mvo> zyga: nice
<mborzecki> pedronis: which ones? i'll clear it up
<zyga> mvo: as for https://github.com/snapcore/snapd/pull/5564
<zyga> mvo: we need some before/after
<mvo> zyga: what does before/after mean?
<mvo> zyga: also what is the link the forum topic about the apparmor issue again? sorry, I misplaced it
<mvo> zyga: found it, nevermind
<zyga> no worries, it is
<zyga> https://forum.snapcraft.io/t/apparmor-profile-caching/1268/17
<zyga> before / after as in "without this patch and with this patch"
<zyga> jamie wanted to see the cost
<zyga> TBH based on jamie's question I would say the boot performance is exactly identical
<zyga> because without core refresh the system key is in sync
<zyga> and that means that startup is totally identical
<pedronis> mborzecki: I answered,  it seems you did the change in the follow up but it sounded like you didn't, but a bit unclear why you cannot do it here first
<mborzecki> pedronis: i've merged master to 5452 and rebased #5561 on top (force pushed there too)
<pedronis> mborzecki: I'm talking about  https://github.com/snapcore/snapd/pull/5561/files#diff-147f53d4ad040ca82e13d36e9fdd4e18R145
<zyga> mvo: so, I don't know, I think we should reboot the pi with stable kernel/core
<zyga> use systemd's boot analyzer to just measure the tiem
<zyga> do this 3-5 times and get some numbers out
<zyga> then apply this patch
<zyga> and do the same
<zyga> but as I said, since the patch doesn't change anything in the case when system key is stable
<zyga> I don't expect to see any difference
<pedronis> mborzecki: the best thing would be to get Chipaca to reivew #5452 today
<mborzecki> pedronis: will ping him
<mborzecki> pedronis: see your response now now, so you're saying f.snap() is like the store then? so with this instance key should be added in the caller rather than inside
<pedronis> yes
<pedronis> that's just my mental model
<pedronis> but that's where I'm coming from
<pedronis> also because snapSpec has a Name field atm
<pedronis> at least
<mborzecki> pedronis: got slightly confused as there's snapSpec coming in but snap.Info coming out
<pedronis> mborzecki: we had store.SnapSpec at some point
<pedronis> mborzecki: actually we still do
<pedronis> that's why it would be good to keep it working similarly
<pedronis> mborzecki: fakeStore.snap corresponds to store.SnapInfo
<pedronis> to some extent
<mborzecki> pedronis: i'm quite sure i replaced snapSpec with store.SnapSpec at some point and then dropped that change
<pedronis> we might change that at some point
<pedronis> but we haven't
<pedronis> it would be good to be somewhat consistent
<pedronis> it's all already all a bit confusing as it is :)
<mborzecki> pedronis: makes sense now, thanks for clearing it up
<pedronis> mborzecki: also for clarity  we had code in snapstate at some point that used SnapInfo and then snap was used to fake SnapInfo
<pedronis> we don't anymore, but we might later
<pedronis> (hopefully not)
<pedronis> anyway just to give more context
<Chipaca> pedronis: thanks for the review!
<zyga> hey Chipaca
<zyga> how have you been?
<Chipaca> zyga: 'sup
<Chipaca> zyga: hot :-)
<zyga> have the streets melted into canals of asphalt yet?
<zyga> yes, it's hot
<mborzecki> pedronis: i'll update 5452 then and leave 5561 hanging there for a while until we land the store part first
<mborzecki> zyga: did it rain at your place yesterday?
<zyga> mborzecki: not a drop of water
<zyga> I really want some now
<zyga> *except not when the moon thing happens
<zyga> that would suck
<mborzecki> zyga: it rained here during the night, but then the morning was south east asian style, you more twice and you're all sweaty
<zyga> yummy
<zyga> why take a shower when you can just get out of bed
<Chipaca> brb (reboot)
<pedronis> mborzecki: btw   this also means we should double check the places in api.go that use Store.SnapInfo they should always use a snap-name,  if we start from an instance name we need to split it, might it's alright right
<pedronis> mborzecki: I'm switching to something else that needs a bit of wrapping up for a bit, IÂ will get back to reviews in the afternoon
<mborzecki> pedronis: sure, thanks for the help
<ogra> mvo, did you consider to rename the pi kernel to just be pi-kernel instead of pi2-kernel with the switch to 4.15 ? (i think this is probably the best time to do it and the versioning in the na is completely pointless )
<ogra> *s/na/name/
<mvo> ogra: can you hop into #stable-kernel to see if that is much work for them?
<ogra> on freenode ?
 * zyga agrees with mvo and ogra
<zyga> pi-kernel is so much better with tracks
<zyga> it'd be only better if we could call it "IOT kernel"
<ogra> with everything
<zyga> and it would work on all the boards at once -)
<zyga> haha, right
<ogra> haha
<mvo> ogra: we also need sign-off by niemeyer if we want to rename pi2-kernel to pi-kernel for core18. but I think this is pretty uncontroversial
<ogra> yeah, it was pi2 only for probably 6 months since it exists
<zyga> yeah, it's super nice
<zyga> ogra: btw, I saw that pi3 has gotten much more aarch64 friendly?
<zyga> ogra: is it the moment where pi could be either armv7 or aarch64 in our images? (that both arches work)
<ogra> and toigether with a generalized gadget that runs on all pi'S you can then build an image (and model assertion) a lot easier
<ogra> zyga, it cant "get more aarch64 freindly" until it has actual ram to make use of aarch64 :P
<zyga> yeah but stuff and ponies and PRs
<ogra> aarch64 on 1G is extremely wasteful
<ogra> and you really dont benefit from anything 64bit on it
<ogra> unless you do big math computations or some such ...
<ogra> ... but for that you are lacking RAM again :)
<ogra> currently all binaries allocate about 1.5x the RAM ... the same binarides, simply built for arm64 ... so even running the idle core image will bump the ram footprint from 40 to 60MB
<zyga> ogra: yeah but it would mean people can use inexpensive pi to play with aarch64 on ubuntu
<zyga> now they need to find something more exotic
<zyga> or just use arch/fedora
<ogra> well, i dont mind if they try out OOM on arch or fedora and we dont get bad press :P
<mvo> zyga, mborzecki, pedronis there will be a snapd 2.34.3 to fix the apparmor cache problem - anything you want to have backported that is a) low-risk b) high-impact?
<zyga> mvo: easter eggs that play yankie-doodle are not in that set
<zyga> mvo: I think that's all for now
 * ogra admits he is exaerating ... just a little :)
<ogra> *exaggerating
<zyga> brb
<t1mp> can I open a shell into a snap container? For debugging
<mborzecki> mvo: nothing new, just the nvidia thing which is already 2.34 branch
<mvo> mborzecki: ta
<ogra> t1mp, snap run --shell <snapname>.<appname>
<t1mp> ogra: great, thanks! I'll try it.
<ogra> t1mp, for any installed snap
<zyga> t1mp: note that this will drop you into a confined shell
<zyga> t1mp: there's also a way to run an unconfined shell if you have sudo on your device
<t1mp> my device is my laptop :) I'm packaging a desktop app.
<t1mp> hmm, I'm a bit confused. The shell it gives me has the homedir in /home/tim/snap/qmenta-app/x37 but I don't have, for example, /bin/desktop-launch which I need
<zyga> t1mp: the home directory is not as relevant perhaps, the big thing is that /bin/desktop-launch exists on your machine but not in the snap container
<zyga> t1mp: what does desktop-launch do?
<ogra> desktop-launch comes from a desktop helper
<zyga> aha
<zyga> then it is probably in $SNAP/bin/desktop-launch
<ogra> your snapcraft.yaml needs to define some [after] statement to get it
<zyga> since /bin is the /bin directory from the core snap, not from your application snap
<ogra> it should be in your PATH by default
<ogra> (if the snap includes it that is)
<t1mp> right. desktop-launch is indeed there, but $SNAP/... is not in my PATH
<t1mp> tim@tim-XPS-13-9350:~$ snap run --shell qmenta-app
<t1mp> To run a command as administrator (user "root"), use "sudo <command>".
<t1mp> See "man sudo_root" for details.
<t1mp> tim@tim-XPS-13-9350:/home/tim$ echo $SNAP
<t1mp> /snap/qmenta-app/x37
<t1mp> tim@tim-XPS-13-9350:/home/tim$ echo $PATH
<t1mp> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
<zyga> ogra: that's not exactly accurate
<zyga> the PATH is changed by per-app wrappers for now
<zyga> so if you run --shell you get a shell but not the wrapers
<zyga> look at $SNAP/ and at the wrappers there
<zyga> and see what they do
<ogra> ah
<zyga> this will be fixed with the incoming work around snapcraft templates and layers
<zyga> sorry, not layers
<zyga> there is some new term for that
<ogra> layovers :P
<zyga> but essentially snapd will know about the sandwiched helpers
<t1mp> so how do I change my / now to $SNAP inside the snap shell. I need that so that python will be able to find the python libs that are installed in the snap
<zyga> t1mp: just 'cd $PYTHON'
<zyga> er
<ogra> zyga, btw, do we have an ETA foe layouts ? (i have a bunch of packages that would benefit from being able to  provide /opt/vc on Rpi)
<zyga> cd $SNAP
<zyga> ogra: next cycle for sure, sorry about the lag
<ogra> *for
<t1mp> python looks directly in /lib/python3.5/site-packages/ if there is no PYTHONPATH set
<zyga> t1mp: yeah, you can set PYTHONPATH in environment: section in your snapcraft.yaml
<ogra> zyga, well, its fine for me, its just awkward having to ask jamie for manual approval for each upload
<zyga> I believe that is per-app so you can customize this
<zyga> and it will be picked up by snap run --shell as well
<t1mp> in this case, I want to execute 'desktop-launch python3 -m my-lib.my-app', and it automatically reads the lib from /lib/python3.5/site-packages/my-lib (no need for PYTHONPATH if it is in that directory)
<ogra> butu it wont be in that directory :)
<ogra> *but
<ogra> since that directory is in your core snap ... which is most likely not shipping "my-lib" :)
<t1mp> right, it is in $SNAP/lib/python3.5/...
<ogra> so your PYTHONPATH needs to point to $SNAP/...
<ogra> right
<t1mp> I did that now.
<t1mp> ImportError: libxcb-dri3.so.0: cannot open shared object file: No such file or directory
<t1mp> so there are a bunch of other env vars to set... I suspect a whole bunch, before it works from the shell.
<t1mp> (just running the snap works fine)
<ogra> ... and your LD:LIBRARY_PATH needs to point to the right dirs too ...
<ogra> typically done by the wrapper
<t1mp> somehow that is already working for me when I run the snap. Or does it chroot to $SNAP or something like that?
<zyga> or in the environment section (more future proof, less shell to run)
<zyga> t1mp: the snap uses a bunch of  wrappers from snapcraft
<zyga> those are not active in --shell
<ogra> thats the bit that zyga referred top above ... if you use --shell, the wrappers arent executed
<ogra> s/top/to/
<t1mp> ah, right. command-qmenta-app.wrapper works
<t1mp> in $SNAP
<t1mp> which version of Ubuntu does the Snap use inside the images? (lsb_release is not installed in it)
<t1mp> it has python 3.5, and my app was tested as working with python 3.6
<ogra> xenial
<t1mp> which xenial? 16.04.1? I have 16.04.5 on my system and it has a newer python than the snap
<thresh> how do I go about restricting the number of snaps saved in /var/lib/snapd/snaps?  I probably only need the latest one +1.
<thresh> no fun having three libreoffice snaps each 500meg
<t1mp> oh, right, the system has python35 (my py36 was in a virtualenv)
<Chipaca> thresh: that's a feature that's in 2.34
<Chipaca> thresh: snap set system refresh.retain=2
<Chipaca> thresh: meanwhile, snap list --all thesnap, and snap remove --revision=revno thesnap
<zyga> thresh: you can get it early by refreshing to another channel
<pedronis> Chipaca: the comment about "snapshots" name is not super constructive IÂ know,  maybe Gustavo will have input about that, it might just be fine and a matter of habit,  they can be interpreted as  collections or namespaces those top state entries
<thresh> thanks Chipaca, zyga
<thresh> trying candidate core now
<zyga> :-)
<Chipaca> pedronis: https://github.com/snapcore/snapd/pull/5187#discussion_r196223469
 * zyga is super happy about what snaps can do
<thresh> ya
<thresh> I guess the changes will kick in (as in actually removing the file) on the next snapped package update?
<Chipaca> still wanting to add âsnap remove --disabledâ
<Chipaca> thresh: yeah
<thresh> makes total sense, thanks!
<Chipaca> thresh: you  could hurry it along by doing a 'snap refresh --revision=<an old revision you have> thesnap' and then a 'snap refresh thesnap'
<Chipaca> although at that point 'snap remove --revision' is probably quicker :-) but if you want to check it works, you can do the above
<zyga> Chipaca: can you +1 and merge https://github.com/snapcore/snapd/pull/5566 please
<zyga> one less flaky test
<Chipaca> zyga: that was a tough review
<zyga> I know
<Chipaca> i think i need a break
<zyga> haha
 * zyga hugs Chipaca 
<Chipaca> maybe some ice cream
<zyga> though a bit too hot for that
<zyga> I was thinking
<zyga> can we install a c-n-f handler
<zyga> and fail tests if it fired
<Chipaca> yeah, hug me but from a meter away dude
<Chipaca> things are sticky
<zyga> would catch things like tpyo || true
<zyga> icky sticky
<zyga> believe me, I don't know where to go to have less heat
<Chipaca> zyga: CÃ³rdoba, Argentina
<Chipaca> zyga: (cachio said it was <0C yesterday)
<zyga> is there winter there?
<zyga> hmm hmm
<zyga> that's settled then
<zyga> bye!
<Chipaca> also winter is dry season
<Chipaca> on the other hand, the president just authorized the army to intervene for "internal security"
<Chipaca> so â¦ maybe stay away for a bit
 * zyga looks at an oldish python codebase 
<zyga> with iffy bits here and there
<zyga> but docs make no sense
<zyga> so deep dive required
<Chipaca> zyga: you get all the fun
<zyga> it depends if upstream is happy to take patches
<zyga> it's the kind of code that makes you ask "python was about style?" questions
<zyga> definitely written by a C coder
<zyga> if(stuff): ..
<zyga> also try: ... except: print "drat"
<zyga> this enterprise vibe
<zyga> also, no tests
<Chipaca> zyga: âI'm sorry zyga the tests are in another castle^Wrepoâ
<zyga> hahaha
<zyga> also no __future__ imports anywhere
<zyga> la la la
<zyga> python 2.6 required
<zyga> la la la
<zyga> it's so hot I cannot think
<Chipaca> zyga: find a fox in the woods, and use it as a hat
<Chipaca> zyga: you will then no longer be worried about the heat
<zyga> have I told you the story of the peeing bunny?
<Chipaca> zyga: if you don't have foxes, a brace of ravens will do
<Chipaca> anything that will try to gouge your eyes out really
<Chipaca> zyga: â¦ no
<Chipaca> zyga: I'm going to have some lunch. No bunnies though.
<mvo> 5555 needs a second review, easy win
<mvo> (and a nice number!)
<zyga> with a number like that
<zyga> who can resist
<mborzecki> Chipaca: bunnies for lunch?
<mvo> 5562 is also an easy win
<mvo> cachio: could you please test the latest pi2-kernel and dragonboard kernel on edge when you have a free slot? we have an initrd update there and once its good we can move it up to candidate/stable
<Chipaca> mborzecki: I haven't sourced bunnies, no
<cachio> mvo, is there any plan for beta today?
<mvo> cachio: yes, probably after the standup
<cachio> mvo, nice
<zyga> back from lunch
<zyga> and back to image factory
<zyga> mvo: how is core18, are we green?
<cachio> mvo, niemeyer I have to take my son to the doctor, I'll try to be for standup
<zyga> cachio: ack
<zyga> mvo: kernel is green, is stuff safe-ish for 1st?
<cachio> mvo, tests runnign for db and pi2 with edge kernels
<zyga> mvo: is the current release (.3) also the one that will enable c18?
<zyga> mvo: or is that for 2.35?
<ogra> zyga, hmm... would it be possible to have a layouts entry the re-maps $SNAP_USER_DATA to /home or is that too recursive to work ?
<zyga> yes, but not yet
<zyga> it's on the roadmap for this cycle
<zyga> I'll get it done
<ogra> (i'm wordering if i could make an openbox-session snap with a handfull of defult apps to run on top of mir-kiosk with XWayland to run a desktop on core
<ogra> )
<zyga> let's sync in 3 weeks after my holidays and flock
<ogra> you would indeed only e able to operate inside confinement so the re-mapping should make it possible to use dotfiles in home in that case
<ogra> ... without having to tinker a lot with serach paths for configs etc in the binaries
<mborzecki> heh, managed to break tmux by resizing gnome-terminal :(
<Chipaca> tea? why yes
<mborzecki> nah, coffee, 3rd one today and still sleepy
<Chipaca> mborzecki: at this point I think sleep won
<thresh> hmm
<mvo> zyga: c18 is 2.35, 2.34.3 is just to unblock us
<thresh> is it just me having issues with firefox? http://thre.sh/stuff/ff-crash.txt
<Chipaca> kenvandine: ^ ?
<zyga> mvo: ack
 * Chipaca hugs mvo 
 * Chipaca sells mvo a universal random number generator
<mvo> Chipaca: hahaha
 * mvo hugs Chipaca 
<mvo> Chipaca: I have enough of random numbers for this week
<pedronis> mborzecki: are you going to merge #5452 and then update #5561 ?
<Chipaca> mvo: but this one comes with a yellow duck, and a plane ticket for four to canarias
<Chipaca> but ok, i'll throw it away
 * Chipaca throwws it away
<mborzecki> pedronis: merging right now
<juliank> mvo: Here's a joke wishlist bug from debconf for you to amuse: https://bugs.launchpad.net/ubuntu/+source/vrms/+bug/1783986
<Chipaca> niemeyer: pedronis: so, about snapshots' state entry, currently it's {"snapshots": {"last-set-id": 42}}
<Chipaca> juliank: clearly there needs to be a vrms snap
<juliank> There were rumours about a flatpak snap
<juliank> I'm also still waiting for the apt snap
<zyga> Chipaca: what would vrms say when invoked form a snap?
<Chipaca> juliank: was the flatpak snap distributed as an appimage
<juliank> Chipaca: Hmm, could be
<mvo> juliank: heh! I like that
<ogra> a classic apt snap should actually be trivial :)
<Chipaca> zyga: âstarting microsoft office 2019...â
<juliank> I'd do one on core18
<ogra> (wouldnt work on ubuntu core sadly)
<juliank> current core needs to many backports
<niemeyer> Chipaca: I guess the downside of that state entry is that if we ever decide to have a per-snapshot state, this would be the obvious key
<pedronis> niemeyer: that was my remark as well
<Chipaca> niemeyer: I think that is pedronis's point
<niemeyer> Ah, I didn't see that
<Chipaca> niemeyer: pedronis: I could do the simplest thing, and have it be a toplevel "last-snapshot-set-id"
 * cachio back
<Chipaca> cachio: kid ok?
<cachio> Chipaca, with fever
<Chipaca> cachio: aw
<cachio> 39Â°
<cachio> Chipaca, as usual seek on weekends
<cachio> it is a virus
<mvo> cachio: uh, good luck
<pedronis> Chipaca: it would work for me, we do have toplevel ones from snapstate for example
<niemeyer> Chipaca, pedronis: Conceptually okay.. it's just a mouthful.. let me grep a bit to see what else we've got
<Chipaca> k
<cachio> Chipaca, mvo I got a call from the kinder garden telling me he was with fever, so I took him the doc
<pedronis> we have last-refresh and last-refresh-hints
<Chipaca> cachio: good luck
 * niemeyer finds "ubuntu-core-transition-last-retry-time" :)
<mvo> cachio: yeah, I read, all the best that he gets well quickly
<cachio> Chipaca, mvo tx
<cachio> mvo, db and pi2 so far so good
<mvo> cachio: great, thanks
<cachio> running about 60 tests without any error
<cachio> using edge kernels
<Chipaca> niemeyer: "once-upon-a-time-a-snapshot-set-id-decided-they-wanted-to-know-what-lay-beyond-the-dark-forest"
<ogra> beavers ?
<niemeyer> Chipaca: Cool, sounds fine
<niemeyer> cachio: Aw.. sucks.. take your time if you need to take care of him
<Chipaca> ogra: https://www.youtube.com/watch?v=ZqH4rc0E1fc
<ogra> lol
<mborzecki> pedronis: and 5561 is updated now
<cachio> niemeyer, tx, he is sleeping now
<zyga> Chipaca: LOL
<pedronis> mvo: the things you added in snap/channel.go in #5563 ar not used anymore/yet ?
<mvo> pedronis: yeah, I can kill those off again, I left it mostly because we talked about that we might want to allow snap install foo=edge bar=stable but YAGNI and all that (easy enough to add again when needed)
<pedronis> mvo: that seems preferable
<pedronis> but yes keep the code around
<mvo> pedronis: sure, let me do that
<mvo> pedronis: I removed the relevant commit
<mvo> zyga: did you see the latest comment from jamie about skipCache when loading snap-confine?
<zyga> nope
<zyga> looking
<zyga> mvo: ah, nice
<pedronis> mvo: I think we do need the test you removed in some form, unless I'm confused
<mvo> pedronis: let me double check which got removed
<mvo> pedronis: you mean the tests in image ? I can add them back they will fail on model assertion assmbly time already though
<mvo> pedronis: or am I missing something?
<pedronis> mvo: I don't you have  a test  where   there's  "kernel: foo"  without track now
<pedronis> you have either kernel with track
<pedronis> or not kernel at all
<pedronis> I mean in asserts
<pedronis> not image
<pedronis> * IÂ don't think
<pedronis> mvo: making sense?
<pedronis> mborzecki: I'll try to give a look at 5561,  let's see how far I get
<mvo> pedronis: indeed, thank you, let me add this one
<mvo> pedronis: updated
<t1mp> how long does the automated review of a new snap package normally take?
<Chipaca> t1mp: seconds
<pedronis> mborzecki: Chipaca: btw I was thinking that maybe in a follow up we should rename though they are called "instance-key" on the wire the various JSON InstanceKey in store,  it's a bit confusing that we have Info.InstanceKey and those  but they don't have the same value
<t1mp> Chipaca: thanks. It was actually minutes for me. Maybe just the first upload.
<Chipaca> t1mp: ah, maybe if it's a biggun
<Chipaca> pedronis: agreed
 * Chipaca falling asleep, takes a break
<mvo> niemeyer, cachio good news, MATCH is fixed - #5539 no longer fails. I will close this PR now
<niemeyer> \o/
<cachio> mvo, great news
<cachio> mvo, thanks for the fix
<mvo> cachio: yeah, good news indeed - my pleasure
<t1mp> Chipaca: 216 MB. It includes a full Qt
<mvo> 5563 needs a second review, should be easy
<pedronis> mborzecki: I did a first pass on #5561,  I saw some issues
<pedronis> afaict
 * pedronis calls it a week, will be around on monday tough
<Chipaca> mborzecki: where does the "10" come from in mon-wed,fri,9:00-11:00/2 -> Monday to Wednesday and on Friday, twice between 9:00 and 11:10 ?
<pedronis> niemeyer: safe travels and move!
<Chipaca> pedronis: have a good one
<pedronis> thx
<niemeyer> pedronis: Thanks! Have a good rest there too
<mborzecki> Chipaca: that's discourse emojis, ð¯ makes it particularly hard to write those times
<mvo> pedronis: yeah, have a good weekend, thanks for the reivews!
<Chipaca> mborzecki: doesn't the backtick stop that from happening?
<t1mp> I'm running a test and build pipeline for my app inside a Docker image on Jenkins... Does it make sense to use 'snap cleanbuild' there then? The docker image should already be clean.
<mborzecki> Chipaca: nope
<mborzecki> pedronis: thanks for the review!
<Chipaca> t1mp: is the docker image on the same libc as your base?
<t1mp> the base is always Ubuntu 16.04?
<Chipaca> t1mp: unless you requested a different one, yes
<t1mp> I'm using python:3 as the docker base image. So chances are that libc is not the same. Possibly I have to change the docker image to an ubuntu one.
<t1mp> ah, I didn't know you can choose the base image
<mborzecki> cachio: regarding https://github.com/snapcore/snapd/pull/5552#discussion_r205799622 iirc storage: .. does not work at particular system level, i recall spread complaining about that
<Chipaca> t1mp: only 16.04 is supported right now, but more are emerging and should be supported soon
<Chipaca> t1mp: supported does not mean works (and viceversa) :-)
<t1mp> 16.04 is fine for me now
<cachio> mborzecki, ok
<cachio> it could be a problem inthe future
<mborzecki> cachio: this is what I get https://paste.ubuntu.com/p/yGQq5P9QT4/
<cachio> mborzecki, let me review spread and try that
<cachio> mborzecki, it should work
<mborzecki> cachio: maybe i'm missing something or misplaced it
<cachio> mborzecki, well, storage is not defined at system level
<cachio> that's why it doesn't work
<cachio> you can define it just at backend level
<mborzecki> cachio: yeah, we could probably fix it though, but that's a pr to spread
<cachio> mborzecki, so, we can go with it but we have to know that it could be a problem in the future
<cachio> I'll create a pr for spread with this change
<cachio> but it will take a time to land
<cachio> so lets go with the storage defined at backend level
<mborzecki> cachio: ok
 * cachio lunch
<zyga> jdstrand: FYI: https://github.com/snapcore/snapd/pull/5564#discussion_r205823848
<kyrofa> niemeyer, I'm not sure how up-to-speed your team is on https://github.com/snapcore/snapd/pull/5569, but I linked the forum proposal in there as well. Do you want to take a look before you head out?
<niemeyer> kyrofa: Sure, will have a look
<Chipaca> I think I'm heading out
<mvo> Chipaca: have a great weekend
<Chipaca> where "heading out" means "getting a beer" becaue the sky is tumbling onto our heads
<Chipaca> mvo: you too! also, go
<Chipaca> mvo: i mean: you too, get out of here :-)
<Chipaca> mvo: but also, have a great weekend
<mvo> Chipaca: heh, very soon, just one upload
<Chipaca> mvo: i'll allow it
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/5564#issuecomment-408483112
<zyga> mvo: merge it!
<zyga> jdstrand: tl;dr; its good :)
<jdstrand> nice :)
<mvo> cachio: 2.34.3 will be ready in ~1h, ppa is building as we speak
<zyga> Everyone: remember about the eclipse today
<zyga> :-)
<zyga> It starts very soon and will take several hours
<zyga> Going through various phases
<Chipaca> zyga: of course the sky is now overcast for the first time in weeks
<Chipaca> not complaining mind you, the houses aren't built for 30C+ weather here
<zyga> Chipaca: Iâll send annoyingly nice photos
<Chipaca> zyga: ok
<Chipaca> zyga: I'll take out your internet
<zyga> UK houses are built for being perpetually wet, no?
<Chipaca> deal with 15C like champs
<zyga> By drinking grog
<Chipaca> you don't need to turn on the heating until temps are <10C
<Chipaca> (outside i mean)
<Chipaca> but in none of the houses i've rented so far has there been a way to ventilate the top 20cm of a room for ex
<Chipaca> so the heat just lurks there (and in the whole attic!)
<Chipaca> anyway, enjoy the eclipse :-)
<Chipaca> i'll enjoy the coolth
<Chipaca> (first time in weeks i'm not having dinner on the deck though)
<Chipaca> o/ eow
<mvo> cachio: 2.34.3 is ready in beta
<cachio> mvo, great
<zyga> Thank you guys!
<cachio> I'll start
<mvo> cwayne: 2.34.3 is ready in beta :)
<mvo> cachio: thank you!
<zyga> ogra: try the beta on your pi
<zyga> :-)
<mvo> oh joy! uevent_test.go fails on s390x
<mvo> invalid data offset
<mvo> oh boy
<zyga> Uh
<zyga> Can you just rete
<zyga> I meant to say âretryâ
<mvo> zyga: its failing for some time
<mvo> zyga: I think there is something wrong
<mvo> zyga: anyway, will dig monday
<ogra> zyga, "the beta" ?
<ogra> oh, of snapd ....
<ogra> will do onthe WE
<zyga> :)
<ffejj> howdy folks... i have a snap application with a lot of *.desktop files in its common/app-data/applications directory-  how can i set that directory where the ubuntu mate desktop menu will see it ?
#snappy 2018-07-28
<t1mp_> hello
<t1mp_> question: are these docker images official and recommended to use? https://hub.docker.com/r/snapcore/snapcraft/
<t1mp_> I want to build snap packages from Jenkins, and I am currently running my pipelines inside docker containers so that I don't have to install anything (besides docker) on the jenkins execution nodes.
<t1mp_> so using snapcraft cleanbuild in a pipeline would fun a docker container, then start lxd inside that, and build the snap inside the lxd. That seems a bit overkill :) (I didn't test if it works), so if the docker image is official I'd rather just build it in there
<ogra> t1mp_, does that answer your question ? https://forum.snapcraft.io/t/snapcraft-docker-images-on-dockerhub/1759
<t1mp_> ogra: partially, I guess
<t1mp_> it seems official, since sergiusens mentions there that he updated it
<t1mp_> I still don't know if it is recommended. But it seems like the easiest solution for me right now, so I'll try it
<t1mp_> it is a bit odd that on dockerhub I don't see that there is a link between snapcore and Canonical
<t1mp_> where can I report bugs for https://github.com/snapcore/snapcraft ?
<t1mp_> snapcraft does not seem to run for me inside the container because sudo is not installed? sudo: no tty present and no askpass program specified
<t1mp_> even though I'm root inside the docker container
<t1mp_> hmm, sudo works in the container, but snapcraft not.
<t1mp_> also, it works locally for me, but not on jenkins
<ffejj> is it possible to have installed multiple versions of the same snap application?
<t1mp_> I don't think so, but it is easy to switch between versions
<ffejj> t1mp_: i don't want t
<ffejj> *to lose settings
#snappy 2018-07-29
<juliank> ffejj: switching won't lose settings AFAIUI, you can switch between versions via snap refresh --revision=<what you want> or --channel=<chanel you want>. But I don't think it's possible to have two active versions at the same time
<ffejj> juliank: wel that lameee
<ffejj> thanks for the info
<ogra> ffejj, it is on the roadmap
<ogra> Creating snapcraft-favoringly-distant-emil
<ogra> Starting snapcraft-favoringly-distant-emil
<ogra> such a sad name ... poor emil ... nobody likes him (or perhaps he smells)
#snappy 2019-07-22
<mborzecki> morning
<zyga> Good morning
<zyga> I will be around in 30
<mborzecki> zyga: hey
<zyga> Hey :-)
<zyga> Good to be back
<mborzecki> mvo: morning
<mvo> hey mborzecki ! good morning and welcome back
<mborzecki> mvo: anything interesting happened last week?
<zyga> o/
<zyga> I would love to know as well
 * zyga checks email and other administrativa
<mborzecki> zyga: mvo started with some cgroupv2 work https://github.com/snapcore/snapd/pull/7109
<mup> PR #7109: [RFC] snap-confine: fallback gracefully on a cgroup v2 only system <Created by mvo5> <https://github.com/snapcore/snapd/pull/7109>
<zyga> mborzecki: reviewing
<mvo> mborzecki: hm, not that much, but we did push some PRs forward so that was good
<mborzecki> mvo: i saw systemd guys pushed a fix for the mount problem we saw
<mvo> mborzecki: yes, I saw that too, iirc I even added a card in trello
<jwheare> Speaking of pushing prs forward, can anyone look into approving my cla for this? https://github.com/snapcore/snapd/pull/7129
<mvo> mborzecki: I looked at it briefly but even backporting to bionic did not look trivial
<mup> PR #7129: userd: allow setting default-url-scheme-handler <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129>
<zyga> mvo: reviewed
<zyga> jwheare: hey, let me look :)
<zyga> mvo: who can approve CLA things?
<mvo> mborzecki: but *maybe* its not hard, I have not looked but it definitely needs some prereq patches
<mvo> zyga: it should be enough to click through this web thing we have
<zyga> mvo: which web thing?
<mborzecki> mvo: i had some scripts to build the image with a version of systemdd from source, perhaps i could try that now
 * mvo looks
<mvo> mborzecki: that would be great
<jwheare> I submitted the web form
<mvo> mborzecki: I looked over the patch and it all seems to make sense
<mvo> jwheare: hey, sorry that you have trouble, let me try to find out what is going on
<mvo> jwheare: normally the web form should be fine
<jwheare> Had no idea what to put in the âproject manager contactâ field tho
<jwheare> And was a bit uncomfortable having to leave address and phone number with no explicit note on privacy on that page.
<jwheare> But I think I did it right?
<zyga> mvo: I think the web thing is still a queue for someone to approve
<mvo> jwheare: I need to inquire, I can't see these forms myself (and I think only very very few people can for the privacy reasons you mentioned above). btw, I can ask to clarify the privacy policy around the address
<mvo> zyga: I will find out, its possible
<mvo> zyga: I *thought* it got automated but maybe I misremember, if not automatic its not ideal on e.g. weekends :/
<mborzecki> mvo: hm perhaps there should be an explicit note given GDPR and such
<jwheare> Itâs this thing https://ubuntu.com/legal/contributors/agreement
<mvo> mborzecki: exactly
<jwheare> The pr template and contibuting.md should mention what to put in âProject contactâ imo
<mvo> jwheare: that looks good, is your launchpad-id the same as your irc nick?
<mborzecki> mvo: building an image with latest systemd
<jwheare> mvo: nope itâs l-james
<mvo> jwheare: excellent suggestion, let me fix that too
<jwheare> Email is james@wheare.org
<mvo> jwheare: thank you!
<jwheare> Thanks for taking a look :)
<mvo> jwheare: thanks, mail sent, I will get back to you as soon as I get a reply (but this involves legal people so things might be not super fast :/
<mvo> jwheare: thanks for the PR too, that looks pretty good - did you see the concern that james hensdrige had?
<jwheare> mvo: not really :)
<jwheare> afaik there's a dialog prompt when setting this anyway, it's pretty common functionality, and as james stated, it's no more of a concern than setting the default browser
<pedronis> mvo: hi,  sorry created quite a few PRs Friday and over the weekend, they have all cards now pointing to them
<mvo> pedronis: thank you!
<mvo> jwheare: ok, I have not looked myself in depth yet, just skimmed the comments will do so later
 * mvo needs a cup of tea first :)
<mborzecki> mvo: so far so good, cannot reproduce the mount problem with the script i used here https://github.com/systemd/systemd/issues/10872#issue-383105075
<mvo> mborzecki: awsome
<mvo> mborzecki: I guess we should explore how much work a backport would be
<mvo> mborzecki, zyga another "fun" issue last week: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836914
<mup> Bug #1836914: Doing multiple squashfs (and other loop?) mounts in parallel breaks <amd64> <apport-bug> <eoan> <rls-ee-incoming> <linux (Ubuntu):Confirmed> <https://launchpad.net/bugs/1836914>
<mborzecki> mvo: heh, that sounds familiar to the forum topic i opened
<pedronis> mvo: we landed a fix for this, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1824226 no ?
<mborzecki> mvo: john has assisted someone with this problem https://forum.snapcraft.io/t/cannot-launch-snaps-on-eoan-and-kernel-5-2/12341 and it looked the same as on arch
 * mvo is in a meeting right now, so appologies for not replying
<mborzecki> mvo: bad news, i can still reproduce the mount problem
<diddledan> popey_: you working today?
<popey_> ya, back at my desk today
<diddledan> cool, in that case then, we've had a person approach from irccloud: https://github.com/snapcrafters/irccloud-desktop/issues/22
<popey_> oooooh
<popey_> I'll take a look once I'm off the phone
<diddledan> cool
<jwheare> hi that's me :)
<popey_> Oh hai!
<popey_> Just talking about this on my current phone call with my boss.
<popey_> Will reply to it once I get off the phone
<jwheare> cool! just heading to the dentist, be back to chat in about half an hour
<popey_> groovy!
<jamesh> hi jwheare.  Thanks for the PR :-)
<Chipaca> pedronis: productive weekend for you i see
<diddledan> awesome :-)
<ackk> mvo, hi, we noticed the block-devices interface intentionally doesn't allow access to partitions, what's the reason for it?
 * diddledan hums.. humm.. the sailor man..
<diddledan> do do do de do do 'cos I eat's me spinich
<diddledan> :-p
 * diddledan is evil
<abeato> mvo, hey, morning! I've noticed the classic snap in the 18 track is only published for amd64, is there any plan to publish it for other archs?
<jwheare> back
<popey_> o/
<diddledan> \o
<diddledan> '\o/'
 * popey_ installs irccloud
<jwheare> diddledan: the main blocker we have now is a permissions error that crashes the app whenever the config file is written to (happens on quit)
<popey_> jwheare: where is that config file being written to?
<jwheare> i think it snuck in on a round of dep updates, since your last released build (0.11.0)
<jwheare> popey_: just the standard userdata dir. the issue is kind of convoluted
<popey_> i bumped irccloud-desktop to 0.12.0 the other day.
<jwheare> spread across a few github issues
<popey_> ah
<jwheare> https://github.com/sindresorhus/conf/pull/82
<mup> PR sindresorhus/conf#82: fix: do not use chown on write - system default permissions is enough <Created by develar> <https://github.com/sindresorhus/conf/pull/82>
<popey> hello from irccloud snap
<popey_> that works then :)
<popey_> One question we haven't discussed, is the name.
<popey_> Once these blockers are solved, do you want to keep irccloud, or would you like us to transfer irccloud-desktop to you?
<popey_> We can't rename snaps in the store, but we can "encourage" existing irccloud-desktop users to move over
<popey_> (not automatically, but they can be nagged to do it)
<mborzecki> mvo: left a note https://github.com/systemd/systemd/issues/10872#issuecomment-513703519 :/
<jwheare> irccloud is our preferred name, but would be nice if irccloud-desktop could be "merged"... ah, ok. well it's not a huge deal
<jwheare> nagging probably works well enough
<popey_> We did this with the vscode snap, to move them to code, and it works well enough
<popey_> active users will get punched in the face with a dialog to "recommend" they move over
<diddledan> we can replace the irccloud-desktop with a neutered snap that just says "not 'ere, guv'"
<popey_> it's annoying enough to make people want to move over
<popey_> well, the irccloud-desktop snap "only" has a few hundred users.
<jwheare> dialog sounds good
<jwheare> copy approved
<popey_> We could use this as an opportunity to promote the irccloud snap, to highlight it and help raise awareness of the app iself / service, and get people moving
<popey_> hah
<zyga> https://src.fedoraproject.org/rpms/gnome-software/pull-request/1 this thread is horrible
<zyga> anyone who ever says "*buntu is evil" should read it
<popey_> Not convinced that is a useful assertion to make in a public place zyga
 * diddledan edits history
<diddledan> oh wait, this isn't telegram
<zyga> I will just ignore this topic for now, work on productive stuff instead
<popey_> That's the spirit! :D
<zyga> mvo: I'm removing lxd now, let's see what happens, this is an easier way to fix this
<zyga> (for context: Qemu and google images differ in preinstalled package sets, this makes fighting tests leaking side-effects easier)
<mvo> mborzecki: uh, ok - if you can still reproduce the mount problem, mind to tell upstream?
<mvo> ackk: probably best to ask jdstrand why/if block-devices interface intentionally doesn't allow access to partitions
<mborzecki> mvo: yup, already left a note under the issue
<mvo> abeato: classic core18> I need to look
<ackk> mvo, thanks, will ping him later
<mborzecki> mvo: i'm double checking this on fedora 30 too, it's using 5.1 kernel and he probably used that during development, that would rule out any arch specific issues
<abeato> mvo, ack, thanks
<popey_> jwheare: on the subject of irccloud. Is it possible to globally disable logging for a particular irc server / network?
<jwheare> not at the moment. the usefulness of the service hinges pretty hard on logging. however, we do have plans for limited log retention policies
<popey_> jwheare: yeah, I figured as much. I can imagine *whisltes* certain corporations that use irc a lot might not be happy about a 3rd party having access to all that text
<jwheare> but "no logging" is a bit tricky. would make things like system or app restarts very destructive, even if you're privacy concious
<popey_> I wonder if people would be happier if they were encrypted with a personal key
<jwheare> but something like a 7 day retention policy is probably reasonable
<popey_> but that's quite a lot to do
<jwheare> encryption is a whole other kettle of fish
<popey_> btw, I *love* that you can easily add slack channels to irccloud and it looks and behaves just like irc
<jwheare> proper e2e has similar unwanted effects to no logging, i've often been baffled when e.g. signal completely forgets who i am and who i've communicated with if i simply stop using it for a few months
<popey_> yeah, wire is similar. messages just disappear
<jwheare> but having an off the record mode you can toggle for sensitive private messages would make sense
<pedronis> #7134 is quite simple and avoids running some test suite tests twice
<mup> PR #7134: image: clean up the validateSuite <Simple ð> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7134>
<zyga> brb
<mborzecki> mvo: well, same thing on fedora
<mvo> mborzecki: thanks
<mvo> abeato: I released classic/18 to edge now (and also building a new one)
<abeato> mvo, nice, thanks! will give it a go for arm64
<mvo> abeato: thank you, I think I never tested it there so please keep me updated
<abeato> sure thing
<mvo> ta - if it works for you I will move it to beta
<mvo> jwheare: hey, I got feedback, the process is manual so it may take a little bit but I did ping the right ppl so hopefully its reaosnable quick. they will also add a link to the table where each software project lists the respective project lead and clarify the privacy bits
<mvo> jwheare: thanks again for raising this!
<Wimpress> jwheare: Thanks for publishing `ircloud` to the edge channel. I've switched to it here ð
<jwheare> mvo: great to hear, thanks for following up
<jwheare> Wimpress: nice, let me know if you encounter any issues beyond the known problems here https://github.com/irccloud/irccloud-desktop/issues/142
<Wimpress> Will do.
<jwheare> That EPERM crash on quit/config change being the main one
<Wimpress> jwheare: That crash on exit recently started happening in the community maintained `irccloud-desktop` snap.
<Wimpress> But this is a new issue. Hadn't ever seen it until recently.
<popey_> I must say, I so rarely close it I hadn't noticed that issue
<Wimpress> And that.
<jwheare> Window resize/move might trigger it too
<jwheare> Or toggling full screen
<jwheare> actually those only get set on quit. but adjusting zoom level will crash i think
<ackk> jdstrand, hi, mind giving an opinion on https://bugs.launchpad.net/snapd/+bug/1837369 ?
<mup> Bug #1837369: Read-only interface for block devices <maas> <snapd-interface> <snapd:New> <https://launchpad.net/bugs/1837369>
<mup> PR snapd#7136 opened: tests: part4 making tests work on ubuntu-core-18 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7136>
<ppisati> ogra: do you have a json file that i can use to build a pi3 core 18 image?
<ppisati> ogra: nm, typo
<ogra> ppisati, nope, but there are some on the forum, th eonly core18 image i personally have is for pi4 currently
<ogra> forum post is here: https://forum.snapcraft.io/t/model-assertions-for-core18/6870
<zyga> hey ijohnson :)
<ijohnson> morning zyga
 * ijohnson needs coffee, brb
<mup> PR snapd#7134 closed: image: clean up the validateSuite <Simple ð> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7134>
<mup> PR snapd#7137 opened: gadget: support for writing symlinks <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7137>
<zyga> ijohnson: I have one more change to mountinfo-tool, when working on the test I realised that any change to the initial mount namespace ripples to per-snap and per-user simply because mount IDs and peer group numbers are consecutive. I had the idea to use a 1000 x "depth" as base, so on host the numbers start from zero, on per-snap they start from 1000 and per-user they start from 2000. I'll push that soon
<ijohnson> zyga: ack I can review that today
<zyga> thanks!
<Chipaca> had to turn off the camera because my laptop was literally melting the placemat i had it on
<Chipaca> i hope it un-warps when it cools back down =(
<ijohnson> pedronis, mvo, niemeyer: I posted https://forum.snapcraft.io/t/netplan-apply-inside-snaps/12411 as a starting point for our discussions
<pedronis> ijohnson: was looking at it , it reflects the current thinking, can you add a note that the attributre is similar to how browser-suppoer allow-sandbox work
<pedronis> s
<ijohnson> pedronis: sure
<pedronis> thx
<mvo> ijohnson: thank you!
<ijohnson> np, let me know if y'all have time for a meeting today to discuss
<mvo> ijohnson: I setup something, does that time work for you?
<ijohnson> mvo: yes
<ackk> jdstrand, hi, around?
<mborzecki> zyga: omg, silly typo
<zyga> mborzecki: haha
<zyga> mborzecki: I was preparing this nice batch for you
<zyga> but you pushed :)
<mborzecki> zyga: didn't push, not yet ;)
<zyga> ah, my bad, sorry
<zyga> GH changed the UI again
<mborzecki> zyga: ha, can't craete a batch on gh, wtf?
<zyga> you can but I opted not to because I cannot commit
<zyga> you can batch commit
<zyga> not batch suggest
<mborzecki> zyga: nah, 'add suggestion to batch' is greyed out
<Chipaca> mvo: question for you about some code you last touched in 2016 â¦ /o\
<mborzecki> nvm, i'll push a patch
<jdstrand> ackk: I answered in the bug
<jdstrand> mvo: fyi, block-devices intentionally does not allow access to partitions (it is a comment in the interface code)
<ackk> jdstrand, yes, we do use hardware-observe
<ackk> jdstrand, btw I reopened https://bugs.launchpad.net/snapd/+bug/1831473 with a comment
<mup> Bug #1831473: Can't run /usr/bin/systemd-detect-virt from inside snap <maas> <snapd:New for jdstrand> <https://launchpad.net/bugs/1831473>
<jdstrand> ackk: I saw that
<jdstrand> ackk: it should probably be a new bug, but that is fine
<ackk> jdstrand, hardware-observe doesn't let you read /dev/sd* or other block devices though
<jdstrand> ackk: please connect the interfaces, run in devmode and add the policy violation to the bug
<jdstrand> violations*
<ackk> jdstrand, will do, thanks
<mvo> Chipaca: what question (in a meeting so might be slow to reply)
<mvo> Chipaca: 2016 sounds scary
<ackk> jdstrand, sorry, one more question, related to snap_daemon. if a process spawn a subprocess which runs as snap_daemon, there's no way for the spawning process it to kill it right?
<Chipaca> mvo: tracing the code back it seems to be a can't-happen, but just in case: if overlord/snapstate/booted.go's UpdateBootRevisions would never actually run in snap_mode=="trying", right?
<Chipaca> s/if//
<jdstrand> ackk: also, in https://launchpad.net/bugs/1831473, can you comment wrt https://github.com/snapcore/snapd/blob/master/interfaces/builtin/hardware_observe.go#L112
<mup> Bug #1831473: Can't run /usr/bin/systemd-detect-virt from inside snap <maas> <snapd:New for jdstrand> <https://launchpad.net/bugs/1831473>
<ackk> jdstrand, you mean mention that we're using the interface?
<ackk> oh I see, hardware-observe has permission for /proc/1/sched commented out
<jdstrand> ackk: no, I mean, read the comment at line 112 and then comment in the bug relative to it. I'm surprised you are seeing it
<mup> PR snapd#7138 opened: tests: remove lxd / lxcfs if pre-installed <Created by zyga> <https://github.com/snapcore/snapd/pull/7138>
<mup> PR snapd#7139 opened: tests: don't leak /run/netns mount <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7139>
<jdstrand> ackk: ackk as for the other question, let me check something
<ackk> jdstrand, I see pid 1 in /proc/1/sched  both in my system and in a container
<ackk> jdstrand, I don't see /proc/1/sched inside the snap, if that's what you mean. which seems to be the issue with systemd-detect-virt
<jdstrand> ackk: can you comment in the bug? this should be non-fatal. comment on if systemd-detect-virt is reporting the wrong thing
<mup> PR snapd#7140 opened: overlord/devicestate: update gadget update handlers and mocks <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7140>
<ackk> jdstrand, I mean, I don't know if that's what's making s-d-v fail. but it does fail in a VM, and I see the denial
<ackk> jdstrand, in a container, s-d-v works and I don't see the denial
<ackk> jdstrand, which seems to point at the fact that it's not trying to read that file in a container (since /sched is not readable there as well)
 * cachio lunch
<mup> PR snapd#7141 opened: tests: add mountinfo-tool --ref-x1000 <Created by zyga> <https://github.com/snapcore/snapd/pull/7141>
<zyga> ijohnson: 7141 is the one I mentioned before
<zyga> I will look at reviews now, just need a small break
<ijohnson> zyga: ack will take a look
<zyga> ijohnson: thanks!
<jdstrand> ackk: ok, atm, depending on how your application is written, there are times when it is currently expected that you can't kill the child
<jdstrand> ackk: the policy is lacking 'capability kill,'. I need to think through how to allow that
<ackk> jdstrand, I see. so basically our current case is that we have supervisord spawn a process, which drops privileges to snap_daemon. it seems when supervisord needs to kill it, it doesn't happen
<jdstrand> ackk: so if you have root, that spawns a child that drops, then you will run into this. if you have a process that drops, then spawns a child, it will be able to send signals
<jdstrand> ackk: that is consistent with what I described and the current policy
<jdstrand> I need to think through how to expose this
<Chipaca> pedronis: https://github.com/snapcore/snapd/pull/7142 Â«boot, o/snapst, o/devicest: limit knowledge of boot vars to bootÂ»
<mup> PR #7142: boot, o/snapst, o/devicest: limit knowledge of boot vars to boot <Created by chipaca> <https://github.com/snapcore/snapd/pull/7142>
<Chipaca> wait mup lives
<ackk> jdstrand, mhm so maybe if we go back to having supervisord spawn the child with snap_daemon that might work better?
 * Chipaca hugs mup
<mup> PR snapd#7142 opened: boot, o/snapst, o/devicest: limit knowledge of boot vars to boot <Created by chipaca> <https://github.com/snapcore/snapd/pull/7142>
<jdstrand> ackk: probably not. supervisord is root and trying to kill a snap_daemon child.
<jdstrand> ackk: in either case, supervisord could temporarily drop, send the signal, then re-reaise
<ackk> jdstrand, uhm, you mean by just setuid/gid(0) again?
<jdstrand> it might be safe to add 'capability kill,' since we have signal rules to mediate things, so I may add it to the PR. but I also want to think through process-control, which currently does not have capability kill
<jdstrand> ackk: not setuid/gid, seteuid/gid.
<ackk> jdstrand, I see. so perhaps I can try that in the script that traps SIGINT/TERM and signals the child. dropping uid around that should work IIUC
<jdstrand> eg, seteuid(uid_t of snap_daemon), kill, seteuid(0)
<ackk> jdstrand, cool, lemme try that
<pedronis> Chipaca: thanks, feel free to request me as reviewer
<jdstrand> ackk: for 'uid_t of snap_daemon', do a getpwuid()
<ackk> jdstrand, yeah I'm doing it from python, using pwd.getpwnam(username).pw_uid
<ackk> (and grp.getgrnam(username).gr_gid)
<jdstrand> ackk: when the PR is finalized, you will be able to hardcode a value instead of doing a lookup, but the value isn't finalized yet
<jdstrand> getpwname/getpwent/etc is always acceptable
<ackk> jdstrand, thanks
<jdstrand> getpwnam*
<zyga> hmm, github is giving me 500
<zyga> anyone else?
<ackk> zyga, WFM
<zyga> https://www.githubstatus.com says is is in degraded performance
<zyga> oh well
<zyga> hmm
<zyga> + expected='(?s)Name +Version +Publisher +Notes +Summary *\n(.*?\n)?test-snapd-tools +.*? *\n.*'
<zyga> + grep -Pzq '(?s)Name +Version +Publisher +Notes +Summary *\n(.*?\n)?test-snapd-tools +.*? *\n.*'
<zyga> + snap find test-snapd-tools
<zyga> running that manually gives me test-snapd-tools-core18  1.0      canonicalâ  -
<zyga> Chipaca: ^ is that expected search result?
<zyga> ackk: now it says "major outage" :)
<zyga> ackk: not that I'm happy for GitHub, at least I can expect it to be down
<ackk> jdstrand, should we use seteuid/gid for dropping privileges too? we currently user set-uid/gid
<jdstrand> ackk: only if you need to re-raise. it is almost always 'no'
<ackk> jdstrand, ha yeah I meant to re-raise
<zyga> cachio, mvo: did anyone publish test-snapd-tools-core18?
<cachio> zyga, I dont
<jdstrand> ackk: fyi, I've decided that for now snaps by default will *not* have CAP_KILL for reasons that will be in the code comments. process-control will have CAP_KILL added
<cachio> zyga, why?
<zyga> it causes google:ubuntu-18.04-64:tests/main/searching to fail
<zyga> (on all systems)
<mvo> zyga: I probably did a long time ago, why? do you need anything there?
<zyga> ^
<zyga> or the store just changed?
<zyga> look at what I said earlier
<zyga> snap find test-snapd-tools
<zyga> it fills test-snapd-tools-core18 now
<zyga> not test-snapd-tools
 * zyga looks at the test
<cachio> zyga, which is the test?
<cachio> searching
<zyga> tests/main/searching
<mvo> zyga: maybe a store hickup?
<cachio> I didn't ready that
<zyga> it failed on all my PRs
<zyga> no worries :)
<cachio> I enabled that last week for core18
<zyga> noise][: was there a store rollout in the last 4 hours?
<zyga> cachio: oh?
<cachio> but I was working properly
<cachio> something has to be changed on the store I think
<cachio> zyga, do you have a link with this error?
<zyga> cachio: https://api.travis-ci.org/v3/job/562141949/log.txt
<zyga> this is from https://github.com/snapcore/snapd/pull/7139
<mup> PR #7139: tests: don't leak /run/netns mount <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7139>
<cachio> zyga, checking
<ijohnson> pedronis: would it be useful to convert the user-open command in snapctl to a more formal hidden snapctl command now that we have hidden snapctl commands?
<pedronis> ijohnson: I think is more complicated then that
<pedronis> it's done that way because it needs to work from the session
<ijohnson> ah I see looking at the code it needs to talk to userd
<pedronis> not via snapd
<ijohnson> right nevermind
<cachio> zyga, I changed the test listing, not the searching, I was confused
<cachio> zyga, I think it is something new
<noise][> cachio: zyga: looks like test-snapd-tools is marked as "unlisted" for search
<cachio> zyga, this is wrong https://paste.ubuntu.com/p/sRv5nqFZss/
<cachio> noise][, that makese sense
<zyga> cachio: I understand that, I wonder what changed to make that happen
<zyga> noise][: is there a way to see if that was recently different?
<noise][> zyga: i would assume it was, but I don't think we audit log that field
<zyga> noise][: can you tell me who owns that snap please?
<noise][> Canonical account - you can see it with snap info
<zyga> I see, thank you
<zyga> mvo, pedronis: do you recall making any changes to test-snapd-tools-core18 recently? (today?)
<zyga> Chipaca, ^ or yourself perhaps?
<cachio> zyga, other tests failing as well
<zyga> cachio: which one?
<mvo> zyga: definitely not today
<cachio> Auto-refresh on fedora
<cachio> zyga, first time I see this error https://paste.ubuntu.com/p/HqwKnnQP2K/
<cachio> zyga, not sure if it caused by the same but seems that could be related
<zyga> mmmm
<cachio> zyga, I see other weird errors on fedora as well, perhaps this new fedora has problems
<cachio> zyga, https://paste.ubuntu.com/p/yGbw4PRFmP/
<cachio> first line of the test fails
<cachio> perhaps there is something new causing this
 * zyga gives up for now
<pedronis> zyga: I don't even have access to it
<Chipaca> zyga: I set some test-snapd- snaps to unlisted, but not -core18
<Chipaca> i don't have access to that one
<zyga> Chipaca: that might explain it
<zyga> Chipaca: test-snapd-tools is now unlisted, failing the test
<pedronis> we use it in find tests
<Chipaca> hmm
<pedronis> we cannot have it both way
<Chipaca> whoops
<pedronis> might we should use something else
<Chipaca> my bad
<Chipaca> put it back to public
<zyga> Chipaca: thank you!
<zyga> Chipaca: I'll restart the test to confirm
<Chipaca> i'd like to make every hello-<developer> snap unlisted also :-)
<zyga> re
<zyga> sorry, lost power at home
<mup> PR snapcraft#2619 closed: make: add "none" and "core20" as supported bases <Created by xnox> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2619>
<mup> PR snapcraft#2635 closed: Legacy errors <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2635>
<zyga> ijohnson: https://github.com/snapcore/snapd/pull/7139 -- cherry picked out of the bigger mount namespace measurement PR
<mup> PR #7139: tests: don't leak /run/netns mount <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7139>
<ijohnson> zyga: approved
<zyga> thanks :)
<mup> PR snapd#7107 closed: overlord/ctlcmd: add netplan-apply cmd to snapctl <â Blocked> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/7107>
 * ijohnson relocates to coffee shop
<mup> PR snapcraft#2636 opened: Release changelog for 3.7 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2636>
<popey_> https://bugs.launchpad.net/snapd/+bug/1837460
<mup> Bug #1837460: snap refresh slows down computer dramatically <snapd:New> <https://launchpad.net/bugs/1837460>
<popey_> Be interested to know what additional debug info might be useful here.
<mup> PR snapcraft#2637 opened: unit tests: make lifecycle tests more robust <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2637>
#snappy 2019-07-23
<mborzecki> morning
<jamesh> mborzecki: are you able to restart the failed sub-job in https://travis-ci.org/snapcore/snapd/builds/562037700 ?
<mborzecki> jamesh: sure, let me check
<jamesh> thank you
<mborzecki> jamesh: ok, restarted
<zyga> Hello
<mborzecki> zyga: hey
<zyga> I will be around in 30
<mborzecki> need to run a quick errand
<mborzecki> mvo: morning
<mborzecki> zyga: mvo: i'm updating the notes on cgroups https://gist.github.com/bboozzoo/76b1535c93686a27bb7fdbaad0f560f7 and testing some things along the way
<mborzecki> back in 30 or so
<mvo> hey mborzecki
<mvo> mborzecki: nice, thank you!
<zyga> back now
<zyga> mborzecki: looking
<zyga> mvo: some good progress last week, apart from me forgetting to modify data sets for ubuntu core the new mount ns test is good
<mup> PR snapd#7139 closed: tests: don't leak /run/netns mount <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7139>
<zyga> mborzecki: I have answers to some of the TODOs there
<mup> PR snapd#7127 closed: tests: removing support for ubuntu cosmic on spread test suite <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7127>
 * zyga breakfast
<zyga> mborzecki: do you think my explanation on https://github.com/snapcore/snapd/pull/7138 makes sense?
<mup> PR #7138: tests: remove lxd / lxcfs if pre-installed <Created by zyga> <https://github.com/snapcore/snapd/pull/7138>
<mborzecki> re
<mup> PR snapd#7138 closed: tests: remove lxd / lxcfs if pre-installed <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7138>
<mvo> mup is back!
<mvo> woooooh!
<Chipaca> pedronis: WDYT of returning an ad-hoc struct from GetCurrentBlah?
<pedronis> Chipaca: it's fine,  adding Revision to PlaceInfo wouldn't be a bad idea
<pedronis> but is a chunk of work because Info.Revision exists
<Chipaca> pedronis: yeah, i'd need to hunt down all those first, but it's easy to do :-)
<Chipaca> pedronis: should I park this, do the revision thing, and then do this?
<Chipaca> i could timebox it to ~1h
<jamesh> zyga: did you have any more comments on https://github.com/snapcore/snapd/pull/6959 (adding osutil.EnsureTreeState) after the last round of changes?
<mup> PR #6959: osutil: add EnsureTreeState helper <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6959>
<pedronis> Chipaca: let's start with a simple struct
<pedronis> and consider the other issue separately
<mup> PR snapd#7141 closed: tests: add mountinfo-tool --ref-x1000 <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7141>
<zyga> jamesh: I'll review it now
<jamesh> zyga: thanks!
<Chipaca> pedronis: ack
<jamesh> zyga: I think everything is ready to land for https://github.com/snapcore/snapd/pull/7054 too
<mup> PR #7054: interfaces: add an interface that grants access to the PackageKit service <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7054>
<zyga> jamesh: I'll check it out as well
<zyga> ah, I remember it :)
<Chipaca> pedronis: a single struct with kernel and core names and revisions, or two structs each with just naem and revision?
 * Chipaca is full of silly questions today
<Chipaca> pedronis: i think two structs works better in this case
<Chipaca> pedronis: but I don't know how you expect this to grow, yet
<ackk> hi, is there a way to strace a program manually run inside a "snap run --shell" session ?
<pedronis> Chipaca: sorry, I still think this should take snap.Type
<Chipaca> :-(
<pedronis> (it's the thing we need anyway going forward)
<Chipaca> so much work done n times
<Chipaca> but, ok
<Chipaca> also it becomes a bunch of ifs again which is ugly
<Chipaca> augh
<pedronis> Chipaca: ?
<Chipaca> pedronis: if type is kernel look for snap_kernel if type is core or base or os look for snap_core
<pedronis> Chipaca: you understand that the one in booted goes way
<pedronis> then, though
<pedronis> that one has an if/switch anyway
<Chipaca> ah, good point
<pedronis> sorry, I thought this through but wasn't explicit
<Chipaca> pedronis: booted has two calls to this though, and one of them will be calling this twice
<pedronis> yes
<pedronis> I know
<Chipaca> ok
<pedronis> that was my comment about efficient
<Chipaca> on it
<Chipaca> yeah, i figured
<pedronis> but we'll need to change that anyway
<pedronis> because at some point base and kernel info will be in two different places
<pedronis> so something has to give
<Chipaca> pedronis: a problem(ish, maybe more so in the future) with making it take type is that UpdateBootRevisions would, on the surface, need to know whether to use base or core
<Chipaca> right now it makes no difference and I'll just use TypeOS
<Chipaca> but core20 might make that harder
<pedronis> Chipaca: I expect all this code to change again
<Chipaca> "Ave, Haxor, morituri te salutant"
<pedronis> Chipaca: I would use TypeBase thoug, no?  and have a comment where used
<Chipaca> pedronis: the result is the same either way -- why Base and not OS?
<pedronis> Chipaca: because OS is "legacy" (dreaded word)
<Chipaca> :-)
 * Chipaca does Â«legacy, err := boot.GetCurrentBoot(snap.TypeOS)Â»
<Chipaca> pedronis: base it is then
<Chipaca> pedronis: type NameAndRevno, or type NameAndRevision?
<mup> PR snapd#7140 closed: overlord/devicestate: update gadget update handlers and mocks <Gadget update> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7140>
<popey_> jwheare: is 0.13.0 based off an internal branch?
<jwheare> it's master
<jwheare> hence edge channel
<popey_> ahh okay
<popey_> we'll start the machinery to create a pr for irccloud-desktop to put a face-punching dialog in it later
<popey_> in preparation
<tomwardill> yay, irccloud and snaps <3
 * tomwardill switched
<pedronis> Chipaca: NameAndRevision
<Chipaca> hmm, i've had to add boot vars to one of the manager tests for it to pass
<Chipaca> something's leaking :-|
<Chipaca> should probably add ad-hoc methods to MockBootloader to set these things instead of raw boot vars
<pedronis> Chipaca: mmh, probably slightly better to have a function that takes a MockBootloader instead of a method
<pedronis> we might have many mock bootloaders laters
<pedronis> maybe
<pedronis> or something else
<pedronis> Chipaca: boottest.SetBoot(bootloader,...) or something
<Chipaca> pedronis: boottest.SetBootKernel(kernel, bootloader...)?
<Chipaca> wth why does seahorse suddenly refuse to see my gpg keys
<Chipaca> i'm going to have to edit the expiration on the terminal, like a caveman
<pedronis> Chipaca: that works though, and SetBootBase ?
<pedronis> doesn't need to take many for now
<pedronis> I mean many bootloaders
<Chipaca> pedronis: and SetBootMode maybe
<Chipaca> i'll look to see how much that one is set outside of boot itself
<Chipaca> first need to sort out my gpg keys as they've _just_ expired :)
<mup> PR snapd#7054 closed: interfaces: add an interface that grants access to the PackageKit service <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7054>
<jwheare> popey_: 0.13.0 has now been released, but the snap will continue to be edge channel due to the config perms crash
<mvo> pedronis 7132 has a small suggestion and needs a test fix - if you agree with the ideas in there I could do it before lunch if you are busy
<pedronis> mvo: given you have the changes, yes please, then it can be merged, right? if/when green
<pedronis> *changes already
<mvo> pedronis: I have the unroll, I need to fix one test failure that the PR has right now but hopefully easy
<pedronis> mvo: something is missing to call StartUp I suppose
<mvo> pedronis: yeah, happy to poke at it, just don't want to duplicate work :)
<mvo> (i.e. want to ensure I don't look at this if you also do or know what to do etc)
<pedronis> mvo: it's a one line fix
<pedronis> mvo: this is likely the safest (going forward) fix:  https://pastebin.ubuntu.com/p/bbg7hzqyyW/
<Chipaca> pedronis: I didn't add a SetBootMode one because the tests that are setting that seem to be caring about the mechanics of the whole update/rollback via boot things, so it'd be a rather bigger refactor
<pedronis> that's fine
<Chipaca> ie they set boot_mode and also snap_try_core
<Chipaca> er, snap_mode*
<Chipaca> probably worthwhile doing at some point, but not as part of this :)
<mvo> pedronis: \o/
<pedronis> Chipaca: +1, with some cosmetic nitpicks
<Chipaca> pedronis: thanks
<pedronis> probably need a 2nd look from mvo again
<pedronis> given it changed quite a bit
<jamesh> pedronis: re. your comments on https://github.com/snapcore/snapd/pull/6954, is designing a new REST API a blocker for the PR, or could that be delayed to a later PR (but before new API methods that actually do something are added)?
<mup> PR #6954: sessionagent: add a REST interface with socket activation <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6954>
<Chipaca> mvo: requested a re-review on #7142 as it's changed quite a bit
<mup> PR #7142: boot, o/snapst, o/devicest: limit knowledge of boot vars to boot <Created by chipaca> <https://github.com/snapcore/snapd/pull/7142>
<pedronis> jamesh: I plan to tweak it (slightly) and land it myself at this point, either today or tomorrow
<jamesh> pedronis: okay.  Thanks!
<mvo> Chipaca: sure, will do
<pedronis> jamesh: also, I made a small comment and asked a question in the EnsureTreeState one, it seems super close
<pedronis> mvo: Chipaca: I'm going to merge 6923 (I undid the renaming because I used cstrs all over the place, so if we want a better spelling we should change it across separately)
<mup> PR snapd#6923 closed: interfaces/policy: minimal policy check for replacing sanitizeReservedFor... helpers (1/2) <Complex> <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6923>
<Chipaca> pedronis: Â¯\_(ã)_/Â¯
<pedronis> Chipaca: I don't have a strong preference, I think I choose the horrible names because some lines were very long but oh well
<jwheare> jamesh: any thoughts on next steps for 7129?
<mborzecki> mvo: one of our dependencies, github.com/ojii/gettext.go is no longer available in fedora
<mborzecki> mvo: also they're using gopkg.in/cheggaaa/pb.v1 rather than github.com/cheggaaa/pb now
<mup> PR snapd#7121 closed: tests: part2 making tests work on ubuntu-core-18 <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7121>
<jwheare> mup ignored me https://github.com/snapcore/snapd/pull/7129
<mup> PR #7129: userd: allow setting default-url-scheme-handler <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129>
<zyga> mvo: https://github.com/snapcore/snapd/pull/7091 is green :)
<mup> PR #7091: tests: measure properties of various  mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/7091>
<zyga> mborzecki: can you have a 2nd look on the test
<zyga> mborzecki: I tweaked it a little
<zyga> mborzecki: I will adjust the wording, though ideally in a follow up since this took a while to get to
 * zyga lunch
<pedronis> is the hyper-v image still broken: https://forum.snapcraft.io/t/error-too-early-for-operation-device-not-yet-seeded-or-device-model-not-acknowledged/12421 ?
<mup> PR # closed: snapd#5644, snapd#5822, snapd#6108, snapd#6258, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6666, snapd#6697, snapd#6705, snapd#6708, snapd#6714, snapd#6767, snapd#6839, snapd#6891, snapd#6950, snapd#6954, snapd#6959, snapd#6972, snapd#7005,
<mup> snapd#7010, snapd#7031, snapd#7042, snapd#7066, snapd#7067, snapd#7073, snapd#7074, snapd#7079, snapd#7081, snapd#7087, snapd#7088, snapd#7091, snapd#7092, snapd#7109, snapd#7110, snapd#7111, snapd#7112, snapd#7124, snapd#7125, snapd#7126, snapd#7128, snapd#7129, snapd#7130, snapd#7131, snapd#7132,
<mup> snapd#7133, snapd#7135, snapd#7136, snapd#7137, snapd#7142
<mup> PR # opened: snapd#5644, snapd#5822, snapd#6108, snapd#6258, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6666, snapd#6697, snapd#6705, snapd#6708, snapd#6714, snapd#6767, snapd#6839, snapd#6891, snapd#6950, snapd#6954, snapd#6959, snapd#6972, snapd#7005,
<mup> snapd#7010, snapd#7031, snapd#7042, snapd#7066, snapd#7067, snapd#7073, snapd#7074, snapd#7079, snapd#7081, snapd#7087, snapd#7088, snapd#7091, snapd#7092, snapd#7109, snapd#7110, snapd#7111, snapd#7112, snapd#7124, snapd#7125, snapd#7126, snapd#7128, snapd#7129, snapd#7130, snapd#7131, snapd#7132,
<mup> snapd#7133, snapd#7135, snapd#7136, snapd#7137, snapd#7142, snapd#7143
<zyga> pedronis: I can check
<zyga> pedronis: I have my windows hyper-v laptop
<zyga> pedronis: there are two images available in the windows gallery: 19.04 and 18.04.2
<zyga> I'll create each and let you know
<mup> PR snapd#7091 closed: tests: measure properties of various  mount namespaces <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7091>
<mup> PR snapd#7144 opened: tests: measure mount namespaces on Ubuntu 14.04 <Created by zyga> <https://github.com/snapcore/snapd/pull/7144>
<mup> PR snapd#6959 closed: osutil: add EnsureTreeState helper <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6959>
<ogra> Chipaca, i assume hello and hello-world havent been updated to base: core18 ?
<Chipaca> ogra: correct
<Chipaca> ogra: snap info tells you as much i think
<ogra> right, then i guess my assumption is correct too
<ogra> (and the tutorial needs fixing)
<Chipaca> ogra: which is your assumption?
<ogra> snapd wont start because the core snap doesnt exist but the hello snap is a required snap
<ogra> so seeding cant complete
<ogra> since a UC18 image only has core18 ... obviously
<jdstrand> pedronis: fyi, I responded to https://forum.snapcraft.io/t/netplan-apply-inside-snaps/12411 (little surprised I wasn't invited to participate, but that's ok so long as the discussion continues in the forum)
<pedronis> jdstrand: sorry, I thought about maybe to invite but was a last minute meeting
<pedronis> jdstrand: also today we need to talk with foundation about the plan
<mup> PR snapd#7145 opened: packaging/fedora: github.com/cheggaaa/pb is no longer used <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7145>
<jdstrand> pedronis, mvo: also, fyi, https://github.com/snapcore/snapd/pull/7111, https://github.com/snapcore/snapd/pull/7112 and https://github.com/snapcore/snapd/pull/7124 should be ready for review (there is one small thing I want to do in a subsequent PR, but it isn't required)
<mup> PR #7111: many: support system-usernames for 'snap_daemon' user <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7111>
<mup> PR #7112: many: allow 'system-usernames' with libseccomp > 2.4 and golang-seccomp > 0.9.0 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7112>
<mup> PR #7124: many: create system-usernames user/group if both don't exist <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7124>
<jdstrand> pedronis: no worries
<jdstrand> I've unblocked all of them and marked for 2.441
<jdstrand> 2.41
 * jdstrand also has docs to write and forum posts to update
<Chipaca> 2.44.1.441.14
<jdstrand> hehe
<jdstrand> pedronis: oh, and I
<jdstrand> 'm mashing 'Restart' for PR 7124's tests (normal intermittent non-PR related failures)
<mup> PR #7124: many: create system-usernames user/group if both don't exist <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7124>
<jdstrand> the other two have passed
<Chipaca> mvo: https://knowyourmeme.com/memes/naruto-run
<mvo> Chipaca: ta
<Chipaca> mvo: can't have our manager falling that far behind
<mup> PR snapd#7146 opened: UC20: cmd/snap-verify: sketch of snap-verify <Created by pedronis> <https://github.com/snapcore/snapd/pull/7146>
 * cachio AFK
<mup> PR core-build#47 closed: initramfs: restore wait-for-root calls <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/47>
<ackk> jdstrand, hi, did you by chance manage to reproduce the issue with systemd-detect-virt not working in a VM?
<Chipaca> ackk: in which vm?
<Chipaca> ackk: and not working how?
<ackk> Chipaca, https://bugs.launchpad.net/snapd/+bug/1831473
<ackk> (recent comments)
<mup> Bug #1831473: Can't run /usr/bin/systemd-detect-virt from inside snap <maas> <snapd:New for jdstrand> <https://launchpad.net/bugs/1831473>
<Chipaca> ackk: ah ok
<Chipaca> ackk: for a moment i thought maybe it had something to do with systemd-detect-virt using capabilities instead of setuid
<ackk> Chipaca, it doesn't seems not being able to read /proc/1/sched is really an issue (I did mention it since I was getting a denial there)
<Chipaca> ackk: I blame mvo
<ogra> he's so easy to blame
<cwayne> ogra: not as easy as ondra though
<ogra> true dat ....
<mvo> Chipaca: wuut?
<ijohnson> cwayne: don't you mean ondras
<cwayne> I refuse to believe there's more than one
<ogra> since people recently start mixing up ogra and ondra all the time in pings i guess he just wants to be more than me now :P
<ackk> Chipaca, so you know what's going wrong, or just generically blaming mvo? :)
<Chipaca> ackk: just generically
<ackk> heh
<pedronis> we should really stop to naively nest test suite, we just get test duplication
<pedronis> I found another case
<pedronis> mvo: seems it's you again
<mvo> pedronis: oh no
<mvo> pedronis: I remember doing that recently but I thought I extracted into a baseFooSuite
<mvo> pedronis: which one is it?
<pedronis> yes, you did that
<pedronis> in validate_seed_test
<pedronis> I fixed it
<pedronis> yes, you need a base suite
<pedronis> though in that case
<pedronis> it was silly
<pedronis> we needed 2 things
<mvo> pedronis: thank you, let me check the PR to see what I did wrong
<pedronis> but I found another one
<pedronis> mvo: if you take a full suite an wrap in another check will run all the tests again
<mup> PR snapd#7132 closed: overlord,daemon,cmd/snapd:  move expensive startup to dedicated StartUp methods <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7132>
<mvo> pedronis: indeed, where did this happen?
<pedronis> mvo: now I find this one: https://github.com/snapcore/snapd/blob/master/cmd/snap/cmd_set_test.go#L33
<pedronis> this one is old
<mvo> pedronis: oh, right - shall I fix or will you? sorry for that :(
<pedronis> let me see how hard it is to fix
<pedronis> mvo: anyway I'm mostly mentioning because is the 2nd time I see this recently
<pedronis> and it's a bit annoying to untangle after the fact
<pedronis> also slower tests
<pedronis> and confusing failures
<mvo> pedronis: yes, sry again
<pedronis> seems there's a BaseSnapSuite
<pedronis> so maybe just a mistyping
<pedronis> not sure
<pedronis> it's old
<pedronis> easy fix
<mvo> pedronis: let me know if I can help
<pedronis> no it's fine
<pedronis> just I was doing something unrelated that breaks many tests (shallowly)
<pedronis> and I was getting many double failures
<pedronis> ijohnson: https://forum.snapcraft.io/t/netplan-apply-inside-snaps/12411/10 it sounds like the granularity of the api will be restarting services, it will be the full apply afaiu, double checking with mvo
<ijohnson> pedronis: perhaps I misunderstood, will `netplan apply` just have a check at the top for running in strict snap, and if so use dbus?
<pedronis> ijohnson: for some value of top
<pedronis> mvo: do you have your first pass somewhere?
<ondra> cwayne because one is not enough :P
<mvo> pedronis: yes, one sec
<mvo> pedronis, ijohnson https://github.com/CanonicalLtd/netplan/compare/master...mvo5:dbus?expand=1
<ijohnson> thanks mvo
<pedronis> yea, is the fully apply
<pedronis> that's what I had expected
<mvo> ijohnson, pedronis why would we do something different?
<ijohnson> okay, so what is the "snapd approved" way to check that a snap is in strict confinement? is checking for $SNAP is sufficient?
<ijohnson> mvo: I was confused from the meeting, I thought it would be just to call out for restarting the services
<mvo> ijohnson: no worries
<pedronis> ijohnson: there isn't one right now I think
<mvo> ijohnson: detecting strict confinement is something we need to think about, I have no clear answer
<ijohnson> ok, well what I've always recommended is just checking for $SNAP, so perhaps that's sufficient for netplan
<mvo> ijohnson: I think so
<mvo> ijohnson: as you can see in the pr this part is not done yet
<ijohnson> right I was just thinking that if you don't get it done before you are off I could try and take this over
<mvo> ijohnson: sure, I'm almost EOD (plus bad network) so feel free to branch from this repo and add what is needed :) the python bits plus I want to explore tests
<ijohnson> ok, I was going to work on the snap model first, but if I get blocked on that this afternoon/evening I will look into your branch
<mvo> ijohnson: also no strong opinion on gio vs libsystemd for the service, I slightly prefer libsystemd
<ijohnson> I'm not super familiar with either of them, so I'll go with whatever you prefer :-)
<mup> PR snapd#7147 opened: client,cmd/snap: stop depending on status/status-code in the JSON responses in client <Created by pedronis> <https://github.com/snapcore/snapd/pull/7147>
<mup> PR snapcraft#2636 closed: Release changelog for 3.7 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2636>
<mvo> ijohnson: heh, in this case I think you don't have to touch the C code, I think that part is done
<ijohnson> +1
<pedronis> Chipaca: #7147 is what we discussed briefly this morning (it just unblocks mentally to decide what to do in the agent PR)
<mup> PR #7147: client,cmd/snap: stop depending on status/status-code in the JSON responses in client <Created by pedronis> <https://github.com/snapcore/snapd/pull/7147>
<pedronis> ijohnson: could update your forum topic to reflect better the plan
<ijohnson> pedronis: ack
<pedronis> thx
<ogra> pedronis, did you follow https://forum.snapcraft.io/t/error-too-early-for-operation-device-not-yet-seeded-or-device-model-not-acknowledged/12421 ?
<pedronis> which part?
<ogra> it seems rather serious that you need to know in advance which base the snaps use that you put into required-snaps (and that the image fails in fatal ways if you dont)
<pedronis> recent prepare-image will error
<pedronis> if you miss one
<ijohnson> pedronis: updated forum post
 * ijohnson lunches
<ogra> well, prepate-image errors if you dont explicitly seed core
<pedronis> core is mostly always added
<ogra> not on core18 images
<pedronis> that's true
<pedronis> but then it will error
<pedronis> no?
<ogra> my core18 builds all only have snapd, core18, gadget and kernel
<pedronis> ah, maybe it doesn't
<pedronis> but it will
<ogra> ok
<pedronis> there's branch that is fixing some of this area
<pedronis> I think you are right, current code
<ogra> good, so we dont need a bug the
<pedronis> just ignores the missing core
<ogra> *then
<ogra> right ... and then seeding on firstboot explodes
<mvo> pedronis: uh oh https://paste.ubuntu.com/p/h369DwHwzZ/
<mvo> pedronis: snapd is crashing on me (edge)
<ogra> jdstrand, snap info joule-linux .... <- this smells pretty rotten (i wonder what we should do about it, i only found out about it because of https://tutorials.ubuntu.com/tutorial/create-your-own-core-image#2 (which i didnt know about til today))
<ogra> (some would perhaps say s/rotten/ripened/ :P )
<mup> PR snapd#7148 opened: configstate: fix crash in purgeNulls <Created by mvo5> <https://github.com/snapcore/snapd/pull/7148>
<bcdonadio> as a user of a snap package, what's the easiest way to have a given env var always set when invoking the app?
<bcdonadio> like: $ MYVAR=myvalue myapp
<bcdonadio> where myapp is a snap package
<jdstrand> ogra: jesse is the uploaded. he could request to have it removed
<jdstrand> uploader*
<diddledan> bcdonadio: if the snap doesn't overwrite that particular variable it is done the same way you'd do any app
 * ijohnson wonders what to do if a snap does overwrite that variable
<diddledan> in those cases unless the snap allows you to set it yourself, such as via a `snap set` command, then you're out of luck
<ijohnson> diddledan: yeah, it would be nice if there was a way to do that though, perhaps a mechanism where the snap can declare it either takes the user's value or the value defined in snapcraft.yaml
<ijohnson> (with the user's value taking precedence)
<zyga> kenvandine, mvo: I just tested the 19.04 hyper v image and it is busted
<zyga> I can create an account, log in and then the session dies
<zyga> 18.04.2 image is downloading, I'll report back
<zyga> ubuntu images download x10 slower than windows images
<zyga> windows image is 13GB and downloads in minutes
<zyga> ubuntu is 1/10th and downloads in hours
<ijohnson> zyga where is it downloaded from?
<kenvandine> zyga: snap is broken in that image
<kenvandine> we've been trying to get new images posted... but running into more problems
<zyga> ijohnson: I used the "gallery" built into windows hyper-v quick create
<zyga> ijohnson: I don't know
<ijohnson> hmm that's really odd
<zyga> kenvandine: ack, I just wanted to report this since pedronis asked today
<zyga> kenvandine: I'm booting the 18.04.2 image now
<zyga> kenvandine: the 18.04.2 image is also busted
<zyga> kicks me out of the system as soon as I log in
<kenvandine> zyga: yeah, same issue
<kenvandine> oh wait, you can't login in the one in quick create?
<kenvandine> the version in quick create has the snapd seeding problem
 * Pharaoh_Atem waves
<kenvandine> those both worked for me this morning
<kenvandine> zyga: but snap seeding was busted
<kenvandine> we're working on new images, but have run into dependency issues with the hwe packages
<zyga> kenvandine: yes, I tried the ones from quick create
<zyga> kenvandine: do you want me to report this somehow?
<zyga> Pharaoh_Atem: o/
<kenvandine> We are going to post new images anyway to fix the snap seeding issue
<kenvandine> which we'll run through the test plan
<zyga> kenvandine: ok
<kenvandine> i wonder if this month's Windows update broke something
<kenvandine> i've told it not to install the updates yesterday
<zyga> shall I just remove the one I created?
<kenvandine> yeah
<kenvandine> nothing you can do with it
<zyga> I'm running insiders
<kenvandine> ah!
<zyga> kenvandine: btw, I also created a windows machine for comparison and that one booted
<kenvandine> they might have other issues
<kenvandine> i'll have Will try it tomorrow with insiders to make sure it works
<zyga> ok
<zyga> I'll EOD now
<zyga> ttyl
<kenvandine> and maybe we'll have you test it next week too
<kenvandine> good night
<bcdonadio> diddledan: gotcha, I will try to work that out with the package maintainer then, currently there are no settings for that snap
<mup> PR snapcraft#2638 opened: remote-build rebased on 3.7 <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2638>
#snappy 2019-07-24
<mup> PR snapcraft#2638 closed: remote-build rebased on 3.7 <Created by cjp256> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2638>
<mup> PR snapd#7149 opened: cmd: add snap model command; daemon: add /v2/model, /v2/model/serial REST APIs <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7149>
<mborzecki> morning
<mborzecki> zyga: mount-ns test failed in pedronis' #7147, i've restarted the job, but in case you want to inspect the log it's here: https://paste.ubuntu.com/p/VYHQhc6zhQ/
<mup> PR #7147: client,cmd/snap: stop depending on status/status-code in the JSON responses in client <Created by pedronis> <https://github.com/snapcore/snapd/pull/7147>
<mborzecki> rawhide daily cloud compose doesn't even boot on GCE :/
<mborzecki> zyga: nvm, i looked at the log and it's /run/netns leaking which should already be fixed in master
<zyga> good morning
<zyga> mborzecki: I saw a failure last night, something leaks another mounted core
<zyga> looking at the log now
<zyga> mborzecki: hmm, odd, it is netns
<zyga> I'll look
<mborzecki> zyga: btw. that's how rawhide compose boots on GCE: https://paste.ubuntu.com/p/kKMwb6zgFW/
<zyga> mborzecki: quickly :D
<mborzecki> zyga: haha
<zyga> I have an idea on how to find broken tests
<zyga> But let me get coffee first
<zyga> We can use something like HOST.txt to ensure the mount table is not corrupted at each step
<zyga> I wish diff had a âfirst like differenceâ more
<zyga> mode*
 * zyga runs a quick test to look for leaky netns
<zyga> hey pedronis, mvo
<pedronis> zyga: here mount-ns failed: https://api.travis-ci.org/v3/job/562563021/log.txt  need to merge master?
<mvo> hey zyga
<zyga> pedronis: I'm debugging that, I assumed master _was_ merged and that some other test is leaking netns
<zyga> pedronis: which PR is this?
<zyga> pedronis: (that as in I got pinged by mborzecki earlier today and I'm running a scan of all the tests for netns leaking)
<pedronis> completely innocent one, the ones that does make(chan error, 1)
<zyga> ah, I remember it
<zyga> give me 30 minutes please
<pedronis> we have various red (many for different reasons)
<zyga> brb
<zyga> re
<zyga> hmm, I ran a pass through all tests on Xenial, nothing leaked netns
 * zyga checks the logic
<zyga> pedronis: your PR must have the netns unmount patch landed before the mount-ns test landed
<zyga> so I must be missing something
<pedronis> I can try to merge master in it again, if that might help
<pedronis> zyga: another one failed on mount-ns
<pedronis> https://api.travis-ci.org/v3/job/562748283/log.txt
<pedronis> also recent
<zyga> oh, that's odd
<zyga> something remounted /dev/pts
<zyga> different mode, different gid
<zyga> oh boy :)
<zyga> our tests are doing interesting stuff
<pedronis> I know snap-confine does things with dev/pts
<pedronis> I don't see it mentioned in the yaml
<zyga> not on the host
<zyga> this is the HOST filesystem
<zyga> nothing should change that
<mvo> zyga: 7148 also fails in mount-s
<mvo> zyga: mount-ns with the unified cgroup being "nsdelegate"
<zyga> hmmm, perhaps I should switch it to manual
<zyga> it seems there are lot of tests that leak here and there
<zyga> and running the test dozens of times before was not enough
<zyga> ideally I'd run a sequence of (a, mount-ns) for a in all tests
<mvo> and fails on ubuntu-core-16 with a bigger diff
<pedronis> yea, seems premature to have it on
<zyga> https://github.com/snapcore/snapd/pull/7150
<mup> PR #7150: tests: switch mount-ns test to manual <Created by zyga> <https://github.com/snapcore/snapd/pull/7150>
<zyga> please merge it
<mup> PR snapd#7150 opened: tests: switch mount-ns test to manual <Created by zyga> <https://github.com/snapcore/snapd/pull/7150>
<mborzecki> at least it's good that we're catching things
<ogra> mvo, pedronis do we have a way to use the force-reboot in snapd for non-snap upgrades ... it just struck me that we allow "snap set system someconfigtxt-option foo" on RPi which should theoretically always use a reboot to make the bootloader config change active
<pedronis> ogra: only upgrades of core or kernels reboot atm
<mborzecki> jdstrand: worked on the idea from your blog post about preparing images for local spread, came up with this cloud init config https://gist.github.com/bboozzoo/f14302d4fc3418200fe28a2d547d3780
<ogra> right, but is it a function that could easily be used here ?
<pedronis> not without some thinking/design
<pedronis> it strange to schedule a reboot from just a set
<ogra> ah. k
<ogra> sure, but in this case it is a bootloader config you are changing
<zyga> mvo: you mentioned that Sergio had a branch of spread that can run a sequence without randomised fuss?
<pedronis> zyga: yes, he spoke about it, you probably can ask him were it lives, don't know if there's PR
<pedronis> or it's just local to him
<Chipaca> mvo: gentle reminder about #7142
<mup> PR #7142: boot, o/snapst, o/devicest: limit knowledge of boot vars to boot <Created by chipaca> <https://github.com/snapcore/snapd/pull/7142>
<Chipaca> ubuntulog2: ubuntulog3: WAT
<zyga> jamesh: ack, I'll look
<mborzecki> zyga: finally running the whole suite locally with fedora rawhide image
<jamesh> thanks
<zyga> jamesh: thank you :)
<jamesh> zyga: I've updated the icon theme PR now that EnsureTreeState is merged.  Once it passes CI, it is probably ready for a real review.
<zyga> jamesh: super
<zyga> mvo: https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=snapd :-(
<pedronis> jamesh: thanks
<zyga> jamesh: I see what happened there, it's my fault, sorry; I'll re-trigger it after the new test is disabled
<zyga> two more buggy tests found
<mup> PR snapd#7151 opened: tests: remove local revision of core <Created by zyga> <https://github.com/snapcore/snapd/pull/7151>
<mup> PR snapd#7152 opened: tests: unmount leftover /run/netns <Created by zyga> <https://github.com/snapcore/snapd/pull/7152>
<zyga> Chipaca, pedronis: ^ those are the two leakers
 * zyga looks for more
<mborzecki> ehh, why does spread not include -smp <some-reasonable-number> in qemu command line
<zyga> mborzecki: I patched my local build but yeah
<zyga> mborzecki: also "kvm" is a debian specific thing, I don't have it on suse
<mborzecki> zyga: heh, have a wrapper :P
<mup> PR snapd#7150 closed: tests: switch mount-ns test to manual <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7150>
<mup> PR snapd#7153 opened: gadget: select the right updater for given structure <Gadget update> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7153>
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/7151/files updated
<mup> PR #7151: tests: remove local revision of core <Created by zyga> <https://github.com/snapcore/snapd/pull/7151>
<zyga> found two more leaky tests
<Chipaca> zyga: what happens if you force the mount-ns test to run after everything else?
<zyga> Chipaca: how do I force it?
<zyga> Chipaca: I didn't try but I'm working around the issue by running a variant of that test in prepare/restore logic
<zyga> it triggers instantly on flaky tests
<zyga> I'm expanding how much I measure so that I can fix issues one by one rather than see a wall of tests to look at
<Chipaca> zyga: priority: 1 or something?
<zyga> Chipaca: uh?
<Chipaca> ah
<zyga> no idea
<Chipaca> zyga: priority: -100
<Chipaca> zyga: default priority is 0
<Chipaca> zyga: bigger numbers â runs earlier
<zyga> I can try
<Chipaca> zyga: negative numbers are supported
<zyga> thanks for the idea :)
<Chipaca> this is backwards from what i'd expect of a priority, but it's documented :-)
<Chipaca> zyga: https://github.com/snapcore/spread/#ordering-tasks
<mup> PR snapd#7154 opened: packaging/debian-sid: merge debian upload changes back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/7154>
<mup> PR snapcraft#2637 closed: unit tests: make lifecycle tests more robust <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2637>
<mup> PR snapd#7152 closed: tests: unmount leftover /run/netns <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7152>
<mup> PR snapcraft#2539 closed: errors: Add InvalidAppCommand errors for non-existent and not-found <Created by clobrano> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2539>
<clobrano> \0/
<mborzecki> hm gadget updates is down to 2-3 patches at most now (not counting snap-image)
<mup> PR snapd#7155 opened: tests: remove locally installed core in more tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7155>
<mborzecki> pedronis: https://github.com/snapcore/snapd/pull/7147 is green, merge?
<mup> PR #7147: client,cmd/snap: stop depending on status/status-code in the JSON responses in client <Created by pedronis> <https://github.com/snapcore/snapd/pull/7147>
<pedronis> mborzecki: yes, please
<mup> PR snapd#7147 closed: client,cmd/snap: stop depending on status/status-code in the JSON responses in client <Created by pedronis> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7147>
<pedronis> thx
<Chipaca> 1hr18min travis run
<Chipaca> go, worker, go!
 * Chipaca â lunch
<mborzecki> anyone seen this? https://paste.ubuntu.com/p/4KyGXgvXpy/ initialize-device failing on f31 in some weird way
<ogra> why would f31 (assuming classic) do initialize-device at all ?
<pedronis> ogra: ?
<ogra> isnt that a core thing ?
<pedronis> no, it's classic too
<ogra> oh, i'm mixing it up ...
<ogra> sorry
<pedronis> both seeding and registration exist both on classic and core
<ogra> yeah
<zyga> mborzecki, pedronis: is that sensitive to gpg on the system?
<mup> PR snapcraft#2639 opened: deprecations: add deprecation notice for version-script (dn10) <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2639>
<pedronis> zyga: no, we don't use gpg on prod system, only the development tooling
<pedronis> uses it
<pedronis> we use ssh-keygen though
<pedronis> I think
<zyga> aha
<pedronis> a 2nd review of #7128 would be great (it's small but might need somebody that looked at remodeling code before)
<mup> PR #7128: overlord: DeviceCtx must find the remodel context for a remodel change <Remodel :train:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7128>
<mup> PR # closed: snapd#7142, snapd#7143, snapd#7145, snapd#7148
<mup> PR snapcraft#2640 opened: cli: improve help for push-metadata <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2640>
<mup> PR snapcraft#2641 opened: ant plugin: correct default channel and improve help <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2641>
<ijohnson> pedronis: thanks for the review on 7149
<ijohnson> pedronis: do you have any recommendations on how to test actually remodelling? is there an easy way to do so on classic, or should I build my own core image with a self signed model assertion and then update the model assertion?
<pedronis> ijohnson: it's complicated in both cases, we don't let remodel devices that don't have a serial
<pedronis> well that might be overstating it, but interesting kind of remodeling probably don't work or shouldn't without a serial
<pedronis> ijohnson: btw regarding output of snap commands, Chipaca is probably the best person to discuss things with
<pedronis> (related to my yaml-like output comments)
<ijohnson> ack, thanks
<jdstrand> mvo: hey, could you (assign someone to?) respond to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932815
<jdstrand> not sure why buster wasn't updated for a newer snapd 2.38 and don't know the plans, otherwise I would've
<jdstrand> s/a newer/the newer/
<Chipaca> mvo: btw, wdyt? https://bugs.launchpad.net/snapd/+bug/1837460
<Chipaca> mvo: (post-standup)
<mup> Bug #1837460: snap refresh slows down computer dramatically <snapd:New> <https://launchpad.net/bugs/1837460>
<jdstrand> ackk: I haven't circled back around to https://launchpad.net/bugs/1831473, but should today
<mup> Bug #1831473: Can't run /usr/bin/systemd-detect-virt from inside snap <maas> <snapd:New for jdstrand> <https://launchpad.net/bugs/1831473>
<ackk> jdstrand, hi, thanks!
<ackk> jdstrand, btw is there a way to strace a process run from a "snap run --shell" ?
<ackk> jdstrand, I've resorted to creating a shell script that basically prints the pid, calls "read" and then execs the actual command, so I can attach with strace, but it's a bit cluncky :)
<Chipaca> ackk: no
<Chipaca> ackk: because by the time you're in the shell inside you can't strace
<mup> PR snapd#7154 closed: packaging/debian-sid: merge debian upload changes back into master <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7154>
<mvo> jdstrand: I uploaded 2.40 to unstable now
<mvo> jdstrand: but that does not help, does it?
<mvo> Chipaca: oh, interessting
<mup> PR snapd#7156 opened: packaging/debian: use correct version for apparmor Depends <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7156>
<mup> PR snapd#7156 closed: packaging/debian: use correct version for apparmor Depends <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/7156>
<jdstrand> mvo: it doesn't help buster, no
<mup> PR snapd#7157 opened: packaging/debian-sid: use correct apparmor Depends for Debian <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7157>
<jdstrand> mvo: fyi, https://github.com/snapcore/snapd/pull/7157
<mup> PR #7157: packaging/debian-sid: use correct apparmor Depends for Debian <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7157>
<zyga> brb
<jdstrand> mvo: (unrelated to that Debian bug. just something I noticed was incorrect
<jdstrand> )
<mvo> jdstrand: nice
<cachio> zyga to use the spread I sent you just use
<cachio> do -> spread -order <test list>
<cachio> this will execute the tests following the order in the order list
<cachio> also you should use -workers 1
<cachio> this will make to use 1 worker so you don't need to update hte spread.yaml
<cachio> please, tell me if you have any problem
<ackk> Chipaca, I see so I guess the script trick is the only way
<zyga> re
<zyga> cachio: thanks! is your patch close to being merged usptream?
<cachio> zyga, no
<zyga> oh, why not?
<cachio> zyga, need reviews
<cachio> there are 2 PR related to this
<zyga> understood
<cachio> 1 for the order
<cachio> 1 for setting the number of workers
<cachio> also you can use -show-output if you want to see the output on real time
<cachio> zyga, once we are able to run spread tests on google on any PR it will be really easy to add tests for all these features and make sure they work well
<zyga> cachio: ping us for reviews
<zyga> I'm sure both me and mborzecki would happily review that
<cachio> zyga, ok, once I add the tests for validating those features I'll ping you for a review for sure
<cachio> mvo, any news about the spread tests on gce?
<cachio> is the key enabled?
 * zyga takes a break while tests run
<mup> PR snapd#7088 closed: tests: manually stop the gvfsd-metadata process <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7088>
<mborzecki> zyga: running test 72/353
<zyga> 7/350
<ogra> =0.02
<mup> PR snapd#7146 closed: UC20: cmd/snap-verify: sketch of snap-verify <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7146>
<mup> PR snapd#7146 opened: UC20: cmd/snap-verify: sketch of snap-verify <Created by pedronis> <https://github.com/snapcore/snapd/pull/7146>
<Chipaca> did we ever get back to #6679
<Chipaca> ?
<mup> PR #6679: many: implement user removal <Created by cmatsuoka> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6679>
<mup> PR snapd#7158 opened: tests: part5 making tests work on ubuntu-core-18 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7158>
 * cachio lunch
<ogra> ARGH !
<ogra> so multipass eats 100% CPU after a reboot of my laptop ... since i dont use it anyway (i did a few times though and there are a few GB of images apparently) i thought i'D remove it ...
<ogra> ogra@acheron:~$ snap remove multipass
<ogra> Save data of snap "multipass" in automatic snapshot set #1                                                    \error: cannot perform the following tasks:
<ogra> - Save data of snap "multipass" in automatic snapshot set #1 (tar failed: context canceled)
<ogra> ogra@acheron:~$ snap remove --purge multipass
<ogra> error: unknown flag `purge'
<ogra> (indeed i ctrl-C'ed the first command)
<ogra> how do i proceed to get it gone ?
<cmatsuoka> Chipaca: not yet, it was preempted by core20
<ijohnson> ogra: refresh core snap to edge
<ijohnson> then you have --purge
<ijohnson> otherwise you can set the core config option to never save snapshots
<ijohnson> snap set system snapshots.automatic.retention=no
<ogra> ijohnson, ah, thanks ...
 * ogra does the latter
 * zyga runs some more tests with more checks 
 * zyga is upset a bit 
<zyga> checking again
<mup> PR snapcraft#2642 opened: remote-build: detect early build errors <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2642>
<zyga> yess
<zyga> finally
<mup> PR snapd#7157 closed: packaging/debian-sid: use correct apparmor Depends for Debian <Simple ð> <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7157>
<zyga> mborzecki: making good progress here :)
<zyga> mborzecki: cannot wait to see this pass everything
<mborzecki> zyga: hm? hm?
<zyga> mborzecki: iterating on the dirty test detector, got it in the right spot now, fixing tests as I go :)
<zyga> mborzecki: even the diff it produces is super readable
<mborzecki> zyga: aah
<mborzecki> zyga: btw. looking at spread logs, lxd seems to have problems with cgroupsv2
<zyga> mborzecki: would be worth asking stgraber
<mborzecki> zyga: https://paste.ubuntu.com/p/Cz7qszmxPD/
<zyga> IO error
<zyga> could be anything
<zyga> but yeah, worth looking
<cachio> zyga, hey, do you know any way to do iptables on core?
<cachio> is there a snap for that?
<zyga> cachio: I don't know, perhap with one of the newer tools
<zyga> but I haven't used any for a very long time
<zyga> nftables? not sure
<cachio> zyga, I'll try that
<cachio> thanks
<mup> PR snapcraft#2641 closed: ant plugin: correct default channel and improve help <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2641>
<mvo> cyphermox:  quick question about "semaphoreci", I pushed pr#93 to netplan but it needs a new build-dependency - can I add this somehow myself (i.e. is there something equivalent to .travis.yml)
<mup> PR snapcraft#2640 closed: cli: improve help for push-metadata <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2640>
<zyga> 419/426
<zyga> all passed
 * zyga tweaks the detector to be more strict and re-runs
<zyga> I think now all tests are 100% good in not leaking mounts
<zyga> but we'll see
<mup> PR snapd#7159 opened: tests: add functions to make an abstraction for the snaps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7159>
<mup> PR snapcraft#2643 opened: project, cli: clean up snap asset messages <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2643>
#snappy 2019-07-25
<mup> PR snapd#7151 closed: tests: remove local revision of core <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7151>
<mup> PR snapcraft#2644 opened: Release changelog for 2.44 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2644>
<mborzecki> morning
<mborzecki> mvo: morning
<mvo> hey mborzecki
<mvo> mborzecki: lots of red PRs this morning it seems, anything in particular unhappy in the tests?
<mborzecki> mvo: nope, nothing in particular
<mborzecki> mvo: on the interesting-test-failures note, yesterday saw unit tests fail on travis (iirc it was daemon or cmd/snapd package) bc the port we tried to liste on was already busy
<mborzecki> mvo: oh, and the lxd spread test failed in a weird way with cgroupv2 (AFAIK it's supported by lxd 3.x)
<mvo> mborzecki: interessting
<mborzecki> mvo: anyways, woke up with some ideas to try out on F31, will discuss those with zyga again probably :)
<zyga> hello
<zyga> sorry for being late, stopped at 3AM
<mvo> hey zyga
<zyga> hey :)
<zyga> finishing coffee
<zyga> I'm eager to run downstairs to see what the test results say
<zyga> https://github.com/snapcore/snapd/pull/7155 <- lets merge it
<mup> PR #7155: tests: remove locally installed core in more tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7155>
<zyga> it's the same pattern as before, that got reviewed
<zyga> see you at 10
<zyga> I'll get prepped
<mvo> zyga: do you think you could have a look at https://github.com/snapcore/core/pull/105 ?
<mup> PR core#105: hooks: empty the configure hook <Created by mvo5> <https://github.com/snapcore/core/pull/105>
<mvo> zyga: should be pretty easy
<zyga> `looking
<zyga> mvo: done
<zyga> mvo: let's merge https://github.com/snapcore/snapd/pull/7155
<mup> PR #7155: tests: remove locally installed core in more tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7155>
<mup> PR core#105 closed: hooks: empty the configure hook <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/105>
<mup> PR snapd#7155 closed: tests: remove locally installed core in more tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7155>
<mup> PR core-build#48 opened: config: remove static files in etc,lib,usr,var <Created by mvo5> <https://github.com/snapcore/core-build/pull/48>
<mup> PR snapd#7160 opened: tests: reformat and fix markdown in snapd-state.md <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7160>
<zyga> a few trivial from my pool
<mup> PR snapd#7161 opened: tests: show stderr only if it exists <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7161>
<zyga> uff 29C in the morning
<Chipaca> pro tip: if you're used to running in the evening, getting up early to run in the morning because the evening is not going to drop below 30 is not necessarily a good plan
<Chipaca> mo'in all, sorry i'm late
<zyga> mvo: is https://github.com/CanonicalLtd/netplan/compare/master...mvo5:dbus#diff-a084b794bc0759e7a6b77810e01874f2R2 something I can review in a PR?
<zyga> Chipaca: hey :)
<mvo> zyga: https://github.com/CanonicalLtd/netplan/pull/93
<zyga> Chipaca: heat wave all around
<mup> PR CanonicalLtd/netplan#93: add dbus based "netplan apply" interface <Created by mvo5> <https://github.com/CanonicalLtd/netplan/pull/93>
<mvo> zyga: that is the final one
<zyga> it reached us now too
<zyga> mvo: thank you
<mvo> Chipaca: running> yeah heat is bad
<Chipaca> oh, my takeaway is that the morning is bad :-0
 * zyga wonders what https://semaphoreci.com/cyphermox/netplan is
<mvo> Chipaca: yesterday and the day before the other side of my dsl line got a heat stroke at around 16:30. and it takes ages to talk to someone on the telco to reset it :/
<zyga> as in semaphore
<pedronis> I marked a bunch of my PRs for 2.41
<mvo> pedronis: thank you
<pedronis> I mean ideally we get all in, but those are the important ones (because they fix something)
<Chipaca> mvo: if you can turn off your modem for ~5 minutes the port you're connected to gets returned to the pool, and you've got a chance of getting a new one
<zyga> mvo: there is https://github.com/CanonicalLtd/netplan/blob/master/rpm/netplan.spec but I don't know if that is used for CI
<zyga> mvo: also snap one https://github.com/CanonicalLtd/netplan/blob/master/snap/snapcraft.yaml
<mvo> Chipaca: oh? that is interessting,I will try that today at ~16:30 when the line goes down again
<pedronis> mvo: I think james #6954 is ready for merging, do you want to give a final look to the packaging/service bits?
<mup> PR #6954: sessionagent: add a REST interface with socket activation <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6954>
<mvo> zyga: yeah, they use something that I'm not familar with (semaphoreci) - no idea how to add deps there
<mvo> pedronis: sure, let me check that
<Chipaca> mvo: OTOH it might be your ISP telling you to work on your work/life balance
<mvo> Chipaca: hahaha - do you have your hands in this ;) ?
 * Chipaca whistles innocently
<jamesh> mvo: I think I got the packaging right in that PR (mostly just followed existing examples), but an extra set of eyes is welcome
<pedronis> Chipaca: can you look at #7149 when you have a bit of time, especially output formatting  in the command and api bits
<mvo> jamesh: happy to do this
<mup> PR #7149: [WIP] cmd: add snap model command; daemon: add /v2/model, /v2/model/serial REST APIs <Remodel :train:> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7149>
<Chipaca> pedronis: i have time now
 * Chipaca looks
<mvo> jamesh: do you happen to know if there is a way to exit dbus services gracefully (and racefree) when they are not needed? context is https://github.com/CanonicalLtd/netplan/pull/93 which is a very simple service that I would like to stop if idle
<mup> PR CanonicalLtd/netplan#93: add dbus based "netplan apply" interface <Created by mvo5> <https://github.com/CanonicalLtd/netplan/pull/93>
<jamesh> mvo: is it problematic if two copies of the daemon run simultaneously for a while?
<mvo> jamesh: I don't think so
<jamesh> mvo: in that case, releasing the name and exiting after current requests complete should be enough
<mvo> jamesh: nice!
<jamesh> mvo: I'm not sure if there is a good example of that using the systemd dbus lib though
<mvo> jamesh: no worries, I could change to gio
<jamesh> mvo: I'm sure there is a good example, I just don't know where it is
<mvo> jamesh: do you have one for gio?
<jamesh> should have been "not sure where there is"
<mvo> jamesh: but no worries, I can figure it out :) thanks for the hint!
<jamesh> mvo: I know I dealt with this a while back for some of the unity-api projects, but can't really remember which
<mvo> jamesh: no worries, thanks again
 * mvo goes back to reviewing before diving into this
<jamesh> mvo: this code is using a bus_event_loop_with_idle() helper: https://github.com/systemd/systemd/blob/master/src/timedate/timedated.c
<jamesh> that probably represents best practice with sd-dbus
<mvo> jamesh: sweet! thanks a lot, this looks like what I need
<Chipaca> hmm
<Chipaca> cannot run daemon: state startup errors: [cannot obtain snap-seccomp version information: invalid format of version-info: "cca7be4711160d1b940e8a87b8d572c8cb18e3dd 2.4.1 8c73f36d3de1f71977107bf6687514f16787f639058b4db4c67b28dfdb2fd3af"]
<Chipaca> what did i break now? :-|
<jamesh> mvo: https://github.com/systemd/systemd/blob/master/src/shared/bus-util.c#L92 <- this is the utility function.  It isn't part of libsystemd, but doesn't appear to be using private API
<pedronis> Chipaca: your snapd and you snap-seccomp are out of sync?
<Chipaca> pedronis: yeah that was it
<mvo> Chipaca: add a symlink from your build-tree to ../snap-seccomp/snap-seccomp
<mvo> jamesh: looking
<Chipaca> ijohnson: you there?
<mvo> Chipaca: probably not yet
<mvo> Chipaca: 4:29 for him
<Chipaca> the 'snap model' PR seems to panic
<Chipaca> mvo: psh, so lazy
<mvo> Chipaca: heh :)
<zyga> tr
<zyga> re
<zyga> sorry, interrupts
<zyga> (5200/5496) - no failures!
<zyga> wow
<zyga> with the mount-ns test as last (famous last words, it may still fail)
<mup> PR core#106 opened: core: remove config test, this moved to the snapd code <Created by mvo5> <https://github.com/snapcore/core/pull/106>
<mup> PR snapd#6954 closed: sessionagent: add a REST interface with socket activation <Needs Samuele review> <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6954>
<pedronis> Chipaca: it has no tests atm fwiw (I'm more of a write tests with the code sort of person)
<Chipaca> yeah, this is unlandable as is
<Chipaca> for several reasons
<mvo> zyga: if you could review https://github.com/snapcore/core/pull/104  too that would be great. should be easy
<mup> PR core#104: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
<mup> PR core#106 closed: core: remove config test, this moved to the snapd code <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/106>
<zyga> brb again
<mvo> or maybe someone else can check 104 on core? its really simple :)
<zyga> mvo: +1
<mvo> zyga: ta!
<mup> PR core#104 closed: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/104>
<mup> PR snapd#7161 closed: tests: show stderr only if it exists <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7161>
<ogra> ppisati, if i use the kdefconfig option in snapcraft.yaml, is that using ./scripts/kconfig/merge_config.sh from the kernel tree in the back or does it simply call the different configs in order ? (i see some weird behaviour between a snap kernel and a manually built one that indicates the configs are different)
<mup> PR snapd#7153 closed: gadget: select the right updater for given structure <Gadget update> <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7153>
<mup> PR snapd#7162 opened: usersession: move userd package to usersession/userd <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7162>
<mup> PR snapd#7163 opened: tests: measure testbed for leaking mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/7163>
<ppisati> ogra: hold on
<mborzecki> zyga: mvo: so lxd attempts some weird things on F31 with unified hierarchy: https://paste.ubuntu.com/p/Z4Qc4qq87v/
<zyga> mborzecki: what is fd=10
<mup> PR snapd#7164 opened: test: enable and run mount-ns test as last <Created by zyga> <https://github.com/snapcore/snapd/pull/7164>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7163
<mup> PR #7163: tests: measure testbed for leaking mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/7163>
<zyga> ideas welcome
<zyga> Chipaca: ^ you as well, this is something similar to what you've built before
<ppisati> ogra: 'make $kdefconfig[0] $kdefconfig[1] $kdefconfig[2] ...'
<ppisati> ogra: but after the first one is expanded, it should call merge_config.sh by default - that's part of the kernel build rules
 * Chipaca steals cookies
 * Chipaca steals biscuits also, for better i18n coverage
<ogra> ppisati, aha ... strange ... when using https://github.com/ogra1/pi4-kernel-hackery/blob/master/build-linux-5.1.sh#L10 vs https://github.com/ogra1/linux-raspberrypi-org/blob/master/snap/snapcraft.yaml#L30 i actually need to specify security=apparmor and apparmo=1 on the cmdline for the snap ... while the native build defaults to using apparmor ...
<ogra> the patches and trees are absolutely identical
<mup> PR snapd#7144 closed: tests: measure mount namespaces on Ubuntu 14.04 <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7144>
<Chipaca> mborzecki: https://www.redbubble.com/people/rodebubbel/works/31716594-i-use-arch?p=sticker
<mborzecki> Chipaca: hahah
<Chipaca> mborzecki: even better, https://www.stickermule.com/uk/products/unixstickers-pro-pack
<mborzecki> Chipaca: aaand placed an order :)
<Chipaca> mborzecki: <surprised zapdos>
<mborzecki> mvo: zyga: https://forum.snapcraft.io/t/lxd-3-15-fails-with-unified-cgroup-hierarchy/12462 the lxd thing
<mvo> mborzecki: thanks
<Chipaca> how do you spell "ALL THE LUNCH"
 * Chipaca all the lunches
 * zyga does reviews for a while
<mup> PR snapd#7160 closed: tests: reformat and fix markdown in snapd-state.md <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7160>
<mborzecki> some unfortunate project name, can anyone try `go get github.com/ojii/gettext.go`?
<mborzecki> the repo name causes a panic in fedora packaging tools :/
<zyga> mborzecki: perhaps we should fork it
<zyga> I think the .go suffix on a project name is a bit unfortunate
<mborzecki> zyga: hm there's a fork under snapcraft/go-gettext
<zyga> is it up to date?
<mborzecki> duh, snapcore/go-gettext
<mborzecki> zyga: yeah, perhaps we should just package it, dropping all i18n support feels to heavy
<zyga> yeah
<zyga> I think so
<zyga> we should craft a plan to support (maintain) our deps in Debian and Fedora
<zyga> we really need that
<zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/7163
<mup> PR #7163: tests: measure testbed for leaking mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/7163>
<zyga> it's super short and will hopefully open the path towards leakproof tests
<zyga> and it found stuff I wasn't testing... 18.04 is full of fun
<zyga> on it :)
<mup> PR snapd#7163 closed: tests: measure testbed for leaking mountinfo entries <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7163>
<mup> PR snapd#7164 closed: test: enable and run mount-ns test as last <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7164>
<ijohnson> hey Chipaca
<ijohnson> (and everyone else)
<ijohnson> Chipaca: thanks for the detailed review, I have in fact been running that PR, but I have been cherrypicking the commits on top of the 2.39 branch because that was easier to test without dealing with the system-key format and I naively assumed that master would work the same as that branch
 * Chipaca hands one of the cookies back
<pedronis> remodeling work has changed quite a few details about DeviceManager/devicestate
<cmatsuoka> mvo: won't be at the standup today, there's an interesting session at the same time slot
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7165
<zyga> ijohnson: https://github.com/snapcore/snapd/pull/7165 :)
<mup> PR #7165: tests: restore cpuset clone_children clobbered by lxd <Created by zyga> <https://github.com/snapcore/snapd/pull/7165>
<zyga> ijohnson: I'm fighting tests that break the testbed by doing changes to the mount table
<mup> PR snapd#7165 opened: tests: restore cpuset clone_children clobbered by lxd <Created by zyga> <https://github.com/snapcore/snapd/pull/7165>
<pedronis> Chipaca: Model was taking the lock for you in 2.39, it doesn't anymore
<pedronis> the older behavior had its reasons but was kind of weird (we don't take the lock for such small methods usually)
<ijohnson> zyga: nice, I can take a look in a bit, still reading through all of my cmd/model comments that I will need to address
<pedronis> ijohnson: 2.39 isv very different from master, if you look at changelog of 2.40 already lots have happened
<zyga> ijohnson: no worries :)
 * Chipaca grudgingly returns the rest of the cookies
 * Chipaca now needs to find his own
<ijohnson> Chipaca: costco near me sells a big box of 16 cookies for $4
 * ijohnson hands Chipaca some cookies
 * Chipaca discovered the meaning of win-win
<mup> PR snapd#7162 closed: usersession: move userd package to usersession/userd <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7162>
<zyga> I'll grab some food and return to reviews
<pedronis> a 2nd review for 7066 would be great (it's not urgent but it's old and there is one more on top)
<zyga> fedora tests look good but core is full of nasties
<mborzecki> zyga: mvo_: left a note under https://bugzilla.redhat.com/show_bug.cgi?id=1438079#c6
<zyga> I saw that :)
<zyga> (mail notification ahead of IRC)
<zyga> thank you
<zyga> and good luck with flock
<mborzecki> zyga: mvo_: also https://gist.github.com/bboozzoo/76b1535c93686a27bb7fdbaad0f560f7 got updated
<zyga> mborzecki: note, freezer is available since 5.2 or 5.3
<zyga> as in the freeze feature
<zyga> but as we discussed, we should switch to safe mount api
<zyga> and not freeze
<mborzecki> zyga: mhm, i doubt anyone on older kernels will switch to unified anyway :)
<zyga> yeah, just saying
<zyga> travis is starving us now
<mup> PR snapcraft#2643 closed: project, cli: clean up snap asset messages <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2643>
<zyga> pedronis: I did a pass over https://github.com/snapcore/snapd/pull/7066#pullrequestreview-266656756
<mup> PR #7066: overlord/assertstate: add Batch.Precheck to check for the full validity of the batch before Commit <Created by pedronis> <https://github.com/snapcore/snapd/pull/7066>
 * zyga can smell lovely curry from the kitchen and goes for a break
<fgiulianiint> hi guys, i'm trying to install Ubuntu Core on an embedded computer with an i5 CPU. I copied the ubuntu-core-18-amd64.img.xz image on the mSata disk and the boot the PC. When I press enter to make the configuration I got an error: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 31.. etc.. and the PC promt again "press enter to c
<fgiulianiint> onfigure"what can I do?
<mup> PR snapd#7166 opened: client: add doTimeout to http.Client{Timeout} <Created by mvo5> <https://github.com/snapcore/snapd/pull/7166>
<Chipaca> fgiulianiint: ouch
<zyga> fgiulianiint: hmmm, I think that image is DOA, where did you get it from?
<ijohnson> is `make hack` still supposed to work/be used?
<zyga> ijohnson: yes, though YMMV
<zyga> ijohnson: send patches to improve it
<zyga> I use it regularly
<zyga> but I have a local patch that's hard to upstream, to make it work on suse
<zyga> where the .real suffix is not used
<ijohnson> ok, yeah I'll send a small patch to make it work when using the go snap, because it's using options that don't work with read-only go install
<fgiulianiint> zyga: i downloaded from the official repo (at least I think) http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/?_ga=2.266211528.651887194.1563966098-1627888589.1561621113
<zyga> ijohnson: read-only go install?
<ijohnson> the go snap?
<zyga> ijohnson: I'm looking forward to the patch
<ijohnson> go build runtime/cgo: open /snap/go/4100/pkg/linux_amd64/runtime/cgo.a: read-only file system
<fgiulianiint> zyga: what DOA stands for?
<zyga> fgiulianiint: ouch, not sure what to do about it, can you raise the topic on a forum and we can see what to do from there; p
<zyga> dead on arrival
<zyga> I think that image is busted
<zyga> is the text localised in any way?
<pedronis> zyga: thx, updated, I did something slightly different
<zyga> +1
<fgiulianiint> zyga: yes, the only problem I can't copy the error becouse the monitor is cleared every time it prompts again "Press enter to configure"
<zyga> fgiulianiint: no worries, that's okay
<fgiulianiint> ok than
<zyga> fgiulianiint: thank you for reporting that, I think we should check how that happened, there's supposed to be QA around that
<zyga> mvo_: ^ who manages the images that are produced?
<pedronis> zyga: thx, I'll land it if/when it gets green. from uc20 spike work I learned that we should probably make Batch more versatile and move it to asserts. something maybe to try during travel
<zyga> +1
<zyga> pedronis: thank you
<mup> PR snapd#7167 opened: cmd/Makefile.am: support building with the go snap <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7167>
<ijohnson> zyga: see 7167 ^
<zyga> ijohnson: looking
<ijohnson> thanks
<zyga> +1
<ijohnson> btw is there a convenient "make unhack" to undo the changes from the make hack command? I just copied all of /usr/lib/snapd and was gonna re-copy it back when done
<ijohnson> not sure if there's a more convenient way to do that
<mup> PR snapd#7166 closed: client: add doTimeout to http.Client{Timeout} <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7166>
<mup> PR snapcraft#2639 closed: deprecations: add deprecation notice for version-script (dn10) <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2639>
 * cachio lunch
<zyga> ijohnson: no, just reinstall the package
<zyga> ijohnson: it's a quick and easy fix
<ijohnson> I see, I hadn't thought of that, but that sounds easy
<zyga> :)
<zyga> +1 on making that in make unhack
<zyga> if you feel like wanting that
<ijohnson> it would make it easy
<ijohnson> I'm also gonna add some more info to HACKING.md since it is a little dusty I think
<zyga> +1
<zyga> yeah, go for it :)
<zyga> I wish we'll reach a point where the makefile won't have to hide in the cmd directory
<zyga> one day
 * zyga restarted some local tests and returns to the kitchen where it is cooler
<abeato> zyga, hey, I'm doing some testing by bind mounting snapd, but I found this error:
<abeato> Jul 25 15:34:45 localhost snapd[5256]: cannot run daemon: state startup errors: [cannot obtain snap-seccomp version information: invalid format of version-info: "762c8972ff78d5e5d00275810e4dba7ae0ae0ea4 2.4.1 8c73f36d3de1f71977107bf6687514f16787f639058b4db4c67b28dfdb2fd3af"]
<zyga> abeato: hmmmm
<zyga> ah
<ijohnson> hey abeato, I ran into the exact same thing
<abeato> zyga, any idea on how can I workaround this?
<zyga> yeah, new snapd needs matching snap-seccomp
<ijohnson> I fixed it by doing make hack in cmd/ subdir
<zyga> bind mount snap-seccomp in the _same_ directory as snapd
<zyga> it uses /proc/self/exe
<zyga> if you develop from source ijohnson's advice is good
<zyga> make hack is your friend
<abeato> ijohnson, nice, so then I need to bind mount snap-confine or other binaries?
<zyga> abeato: make hack installs them
<zyga> abeato: if you just care about snapd then just providing snap-seccomp is sufficient to get past that
<ijohnson> abeato, go with what zyga says :-)
<abeato> zyga, ok, will do that, I am compiling in a different machine to where I am testing, as it is an UC system
<zyga> aha
<zyga> yeah, a symlink would work too
<zyga> whatever is convenient
<zyga> just need a "recent enough" snap-seccomp
<zyga> it's not that they have to be built together
<abeato> ok, will try that thanks ijohnson and zyga
<zyga> :)
<mup> PR snapd#7165 closed: tests: restore cpuset clone_children clobbered by lxd <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7165>
<mup> PR snapd#7168 opened: tests: measure testbed for leaking mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/7168>
 * ijohnson goes to go look at a used car
<ogra> you have weird hobbies
<mup> PR snapd#7166 opened: client: add doTimeout to http.Client{Timeout} <Created by mvo5> <https://github.com/snapcore/snapd/pull/7166>
<Chipaca> ok, I'm out
<Chipaca> AC is no longer keeping up
<Chipaca> send help
 * Chipaca heads for the showers
 * zyga is running away from the office
<zyga> it's the hottest part of the house now
<zyga> running another pass
<zyga> I found another general class of leaky tests
<zyga> core18 is often leaked on core systems
<zyga> because cleanup is different there
<zyga> this is now fixed, let's see what else is uncovered
<zyga> meanwhile, I *really* need to run away from the office
<zyga> ttyl
<ijohnson> is it expected / by design that snaps cannot run when snapd is unable to start?
<zyga> ijohnson: it's not exactly like that
<zyga> ijohnson: in general snaps *can* almost always run without snapd
<zyga> ijohnson: your case is different because you use a local build
<zyga> ijohnson: in that case you always need snapd to compute matching security profiles
<zyga> ijohnson: (matching to snap-run)
<ijohnson> I should specify, this is for a classic snap
<ijohnson> zyga: yes I know why my local snapd can't start
<zyga> the logic doesn't check for snap confinement type
<ijohnson> zyga: I'm just wondering if it's the case that something in snap-run/snap-confine needs to talk to snapd the daemon in order to continue
<zyga> yes
<zyga> but only in a specific case
<zyga> snap run computes the "system key"
<zyga> and if mismatches what's on disk (written by snapd)
<zyga> it waits
<zyga> or pokes snapd, I forgot
<zyga> but it waits anywa
<zyga> *anyway
<ijohnson> I see, so if the system key matched, but snapd still couldn't start for some other reason the snap would be able to start?
<zyga> no
<ijohnson> okay, so it does look like it's at least expected that the snap wouldn't be able to run, but perhaps that's not an explicit design choice
<ijohnson> I'm aware of the explicit design choice of snapd not blocking bootup and not getting in the way of other things running on the system
<ijohnson> I wasn't sure if there was a similar thing for running snaps specifically
<zyga> ijohnson: you are right with the design choice of not blocking startup
<zyga> ijohnson: but except for kernel or snapd changes
<zyga> ijohnson: and that's what's going on, effectively here
<zyga> ijohnson: running snaps is in the same area, since the boot up problem is really "snapd needs to work for system to boot"
<mup> PR snapd#7169 opened: tests: remove core18 if installed by tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7169>
<mup> PR snapd#7170 opened: tests: fix typo "current" <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7170>
<ijohnson> zyga: okay that makes sense
<mup> PR snapd#7169 closed: tests: remove core18 if installed by tests <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7169>
<mup> PR snapd#7066 closed: overlord/assertstate: add Batch.Precheck to check for the full validity of the batch before Commit <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7066>
<mup> PR snapd#7171 opened: tests: improve how the system is restored when the upgrade-from-2.15 test fails <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7171>
 * cachio afk
<zyga> found another bug, installing the "classic" snap clobbers the host
<zyga> fun fun fun
<zyga> uUUUUh
<zyga> omg
<zyga> man
<zyga> this is bad
<zyga> ah, wait
<zyga> I misread
<zyga> it's not bad
<zyga> geez :|
<sergiusens> zyga: chill!
<sergiusens> hard to do with your heat wave, come down south to our cold weather :-)
<zyga> sergiusens: polandball colors are somewhat appropriate now
<zyga> (being upside down)
<mup> Issue classic-snap#32 opened: Using classic clobbers /dev/pts on ubuntu-core 16 systems <Created by zyga> <https://github.com/snapcore/classic-snap/issue/32>
<mup> PR snapd#7172 opened: tests: work around classic snap affecting the host <Created by zyga> <https://github.com/snapcore/snapd/pull/7172>
<zyga> ogra: do you know who maintains the classic snap?
<zyga> jdstrand: ^ interesting PR
<zyga> jdstrand: tl;dr; security implication is that mounts that don't propagate to the other namespaces can still remount a mount point in the other namespaces if they have the permission (or attack vector) to do so
 * zyga takes a break 
<jdstrand> zyga: note devpts is special. I haven't read the code but it would surprise me if it honored propagation events. you just mount what you want at the place iirc and the kernel gives you that
<jdstrand> zyga: and the classic snap is performing mount -o mode=666,ptmxmode=666 -t devpts devpts /dev/pts
<zyga> jdstrand: that's odd, I tried "mounting over" but it would return EBUSY unless I passed -o remount
<zyga> jdstrand: did you strace the classic snap or inferred this from the source code
<zyga> jdstrand: as it does use -o remount in some if-then-else tree
<zyga> but anyway, it's interesting and was non-obvious to me what is the cause of this
<zyga> jdstrand: the mountinfo-tool work and the recent testbed-tool work is really paying off
<jdstrand> classic is doing a weird: mount -o mode=666,ptmxmode=666 -t devpts devpts /dev/pts ; $SCRIPT && umount  /dev/pts
<zyga> note && is a bug most likely
<zyga> it's horrible and should be rewritten away from shell IMO
<jdstrand> zyga: as mentioned, I didn't look at anything. I just know that devpts is special in many ways and it wouldn't surprise me if this was one of them
<zyga> jdstrand: ack, I'll read the kernel source to see what it does
<zyga> I just wanted to share it because I was definitely not expecting this and I learned something today :)
<zyga> jdstrand: in case you are interested where this is coming from: https://github.com/snapcore/snapd/pull/7168/files
<mup> PR #7168: tests: measure testbed for leaking mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/7168>
<jdstrand> zyga: it is interesting, but I don't consider it a security issue within snapd case the classic-support interface isn't meant to provide a security barrier and strict snaps can't do the mounting (and classic snaps are limited by DAC (which is only useful for non-root commands of course))
<jdstrand> ie, if you can do arbitrary devpts mounts, then well, I'm not surprised that can affect things
<zyga> jdstrand: I wonder if our apparmor policy that allows a particular mount also allows you to remount, in other words, if you don't say options=(remount), do you have that?
<zyga> jdstrand: or in other words, should way always say options=() to avoid having the effect of options=(*)
<jdstrand> zyga: remount is a different rule
<jdstrand> mount, umount, remount
<zyga> really? I didn't know that
<zyga> I recall we have some remount code
 * zyga looks
<zyga> https://github.com/snapcore/snapd/blob/7721bb9df44a136f31920515fc5d1a3c2e1e9850/cmd/snap-confine/snap-confine.apparmor.in#L296
<zyga> we say options=(remount, ...) here
<zyga> or did you mean that?
<zyga> based on what you said I was expecting "remount ..." as a top-level rule
<jdstrand> I do see options=(remount ro bind) etc in there
<jdstrand> there is a remount rule
<zyga> are they equivalent?
<jdstrand> zyga: it probably depends on how it was mediated. I can say that we use options=(...) which means that the mount options must exactly match. you can't omit or inject
<jdstrand> jjohansen: zyga and I were curious when 'remount ...' is used, vs 'mount options=(remount, ...)'
<jdstrand> zyga: also note that systemd-run is in play with the classic snap, so it might've done something too
<jdstrand> zyga: the classic snap is not using 'newinstance' either...
<jdstrand> anyway, I need to get back to what I was working on
<jjohansen> jdstrand: remount is the same as options=(remount,...)
<jjohansen> its just a convenience keyword
<ogra> zyga, classic should go away in favour of lxd
<jdstrand> jjohansen: ack, thanks (cc zyga ^)
<ogra> it comes from a time where we needed a quick way to use debs on core for development, it has never been more than a hack
<ogra> zyga, also note that there has never been a stable release for a reason ;)
<JordiGH> snapd ate all of my AWS CPU credits. It was running for several minutes. I restarted the VM. What was that thing doing? It made the VM unresponsive.
<JordiGH> I'm not even using snaps on this VM. :-\
<JordiGH> It looks like it was doing a lot of IO 'cause some kernel disk process was topping the charts.
<zyga> JordiGH: can you run "snap changes" to let us know?
<zyga> systemd logs could also be useful (of snapd.service)
<JordiGH> $ snap changes
<JordiGH> error: no changes found
<JordiGH> $ sudo journalctl -u snap.service
<JordiGH> -- No entries --
<JordiGH> Oh, sorry, snapd.
<JordiGH> Does this mean anything to you? http://paste.debian.net/1093102/
<zyga> looking
<zyga> is snapd still using CPU?
<zyga> so far all it did seems nurmal
<zyga> *normal
<JordiGH> No, it's not doing anything now.
<JordiGH> But what could it possibly have been doing?
<JordiGH> Is there some scheduled task?
<zyga> initially it seeds snaps
<zyga> snaps are on disk but are not installed
<JordiGH> Even on a system that, afaict, has no snaps?
<zyga> I see you have two snaps
<zyga> snap list?
<JordiGH> Oh, I do?
<zyga> I think so
<JordiGH> Ugh, Amazon has started to use snaps.
<JordiGH> amazon-ssm-agent
<zyga> so it installed the two snaps, the core is quick and easy but the amazon-ssm-agent might required some CPU startup time to configure the sandbox
<JordiGH> That, eh?
<zyga> yeah
<zyga> *might have required
<zyga> when you said it ate all your credits, what was the actual amount
<roadmr> I believe those are baked into the images
<zyga> did it run for minutes, hours?
<JordiGH> I'm really worried that Ubuntu is really trying to get rid of or hide apt.
<zyga> roadmr: yes
<JordiGH> zyga: It ran for about 30 minutes before I noticed and terminated the instance.
<zyga> JordiGH: we are doing neither, I can assure you; snaps do make a lot of sense for many payloads though
<zyga> JordiGH: ouch! that's certainly bad
<roadmr> was it snapd itself, or the agent snap? if the latter, this is probably best raised with amazon themselves, right?
<zyga> JordiGH: can you share the details please: what kind of instance, which image, etc
<zyga> JordiGH: so that we can reproduce and fix this
<JordiGH> roadmr: I don't know, I saw snapd in top(1) as well as a kernel IO process. I'm not sure if it was kswapd.
<roadmr> JordiGH: right, that doesn't look like the agent itself
<JordiGH> Not the agent itself? Something other than snapd?
<JordiGH> snapd was doing something that was doing a lot of disk writing.
<zyga> JordiGH: ideally we can reproduce this and determine the cause
<JordiGH> zyga: t2.large
<JordiGH> zyga: I was told that yeah, the goal was to make people stop using apt.
<zyga> JordiGH: can you collect this in a bug report please, I'll make sure the cloud people investigate this
<JordiGH> Was I mislead? Canonical employees told me this.
<zyga> JordiGH: who told you this?
<roadmr> it wasn't me :)
<zyga> I'm a canonical employee and I think both snaps and classic packages have their uses
<JordiGH> yeah, apt is for building snaps, right?
<JordiGH> Users should only use snaps.
<zyga> it depends
<JordiGH> I don't remember who said this.
<zyga> it's not as simple as that
<zyga> for some use cases one is more appropriate than the other
<zyga> for end user applications, despite the relative immaturity, snaps do make a lot of sense
<JordiGH> I thought the point is that Canonical was going to be spending all of its energy on making snap packages and make apt packaging secondary.
<JordiGH> Anyway, what am I going to report and to whom?
<zyga> for certain types of services and in headless consumer electronic stuff snaps make a lot of sense
<zyga> JordiGH: I think whoever told you that was sharing his personal view and not a company policy
<JordiGH> I don't have a lot of data. I don't even remember exactly what I was seeing in top(1).
<zyga> JordiGH: please collect the information and report it either on forum.snapcraft.io or on bugs.launchpad.net/snapd
<zyga> in either case please share the link, I'll get some eyes on it
<JordiGH> Link to what?
<zyga> JordiGH: region, instance type, image used, that should be enough to see if it happens all the time
<zyga> to the bug report or forum post you make
<JordiGH> I'm going to make a bug report?
<zyga> please, if you can
<JordiGH> eu-west-1a, t2.large, xenial-based image,
<JordiGH> Where should I make a bug report?
<zyga> xenial-based?
<zyga> was it an official image or something custom?
<zyga> I'm only asking to know if we can reproduce it on the stock one
<JordiGH> We grab the xenial image, add stuff to it, and deploy VMs based on that.
<zyga> I see
<zyga> JordiGH: please report the bug on https://bugs.launchpad.net/snapd
<jdstrand> ogra (cc zyga): is lxd viable for the workflow you described (ie, building things in an armhf container). are there official lxd images for armhf and arm64?
<zyga> jdstrand: I'm sure there are
<zyga> jdstrand: I used lxd on both
<jdstrand> hmm.. I recall wanting them at one point and not having them
<jdstrand> but that was a while ago
<JordiGH> zyga: Can't remember my password, my email reminder isn't showing up, I'm already cross and don't want to bother with this anymore.
<zyga> I think at this time you just install lxd and launch a container from it
<JordiGH> If it happens again I'll come back.
<zyga> JordiGH: thank you
<zyga> JordiGH: if you want to, a forum post on forum.snapcraft.io is also useful
<zyga> just anything that we can share with you as a way to continue the conversation
<JordiGH> That probably also requires creating accounts, and I'm already short-tempered, ttyl!
<jdstrand> zyga (cc ogra): sudo lxc launch ubuntu:16.04 xenial is working on arm65
<jdstrand> arm64*
<zyga> jdstrand: cool :)
<jdstrand> so, nm
<zyga> jdstrand: I switched off my arm machines to (ironically) save some power today so I cannot ssh into anything to check quickly
<jdstrand> heh
<zyga> and I'm too lazy to go down and see the office today
<zyga> it's 22:48 and here I am, working
<jdstrand> zyga: you should stop that :)
<zyga> I know but then we would not have this conversation about remount :)
<jdstrand> heh
<jdstrand> and sudo lxc launch ubuntu:16.04 xenial works on armhf too
<zyga> jdstrand: btw, if you could comment on https://github.com/snapcore/snapd/pull/7172 I would love to fix this and carry on
<mup> PR #7172: tests: work around classic snap affecting the host <Created by zyga> <https://github.com/snapcore/snapd/pull/7172>
<zyga> the context is that there's a new tool that shouts loudly if a test clobbers the machine
<zyga> so we get to see things like that easily
<mup> PR snapd#7170 closed: tests: fix typo "current" <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7170>
<ogra> jdstrand, yeah, absolutely, i use it every day
<ogra> jdstrand, and if you add your user into /var/lib/extrausers/group to the lxd line you can even get away without sudo ;)
#snappy 2019-07-26
<mup> PR snapcraft#2642 closed: remote-build: detect early build errors <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2642>
<mborzecki> morning
<zyga> Hey mborzecki
<mborzecki> zyga: hey hey
<zyga> Check out https://github.com/snapcore/snapd/pull/7172
<zyga> Magic :-)
<mup> PR #7172: tests: work around classic snap affecting the host <Created by zyga> <https://github.com/snapcore/snapd/pull/7172>
<mborzecki> zyga: looking
<zyga> Interesting behavior
<mborzecki> zyga: it'd be nice to pinpoint the reason
<zyga> As soon as I get to the office
<zyga> I spoke with Jamie and we have some ideas
<zyga> hmmm
<zyga> "newinstance" literally does nothing at all
<zyga> eedf265aa003b4781de24cfed40a655a664457e6
<zyga> devpts: Make each mount of devpts an independent filesystem.
<zyga> this option is from 2016
<zyga> it seems that before devpts was really magically shared no matter where it is mounted
<zyga> mborzecki: so the working theory is gone
<mborzecki> zyga: hah :P
<zyga> mborzecki: something like this:
<zyga> https://www.irccloud.com/pastebin/JdL7fdQS/
<mborzecki> zyga: we know it'll happen each time you run classic snap though? so it might be better to error when it does not, in case it's a regression or sth
<zyga> so you want more tests to fail? :)
<zyga> I'm happy if whoever fixes this adjusts workaround
<mborzecki> zyga: more like a failure accounted for :P but not a blocker
<mborzecki> zyga: let me +1 it
<zyga> I'm testing the change
<zyga> hey mvo
<zyga> mborzecki: I'll likely fix the original issue and adjust this test if that makes you feel better
<mborzecki> zyga: so classic snap mounts it's own devpts then?
<zyga> mborzecki: don't even get me started, that code is horrid
<zyga> yes
<zyga> let me show you
<mvo> zyga: hey, good morning
<mborzecki> haha
<mvo> and hey mborzecki
<zyga> https://github.com/snapcore/classic-snap/blob/master/bin/classic#L67
<mborzecki> feel sorry for whoever will have to explain all meanings of classic
<zyga> mborzecki: it uses systemd-run
<zyga> mborzecki: so, presumably, that's running on the host, right?
<zyga> it's a init-spawned service?
<zyga> mborzecki: what is curious
<zyga> if you experiment on your machine
<zyga> is that there's only one /dev/pts mounted
<zyga> it seems that whatever the kernel did affects the existing /dev/pts, not a newly mounted one
<zyga> it's not a new mount, it seems
<mborzecki> zyga: --scope makes the process a child of systemd-run
<zyga> mborzecki: do you know if systemd-run does reparenting to the initial mount namespace?
<zyga> I'll experiment some more in a moment, just need to get breakfast and take the dog out
<zyga> mborzecki: classic is not loved much, though
<zyga> that script cries for fixes
<zyga> even shellcheck pass
<mborzecki> zyga: perhaps if it's a normal unit, it wouldn't make sense with --scope
<zyga> mborzecki: pushed a small update
<zyga> mvo: wanna review this craze?
<mvo> zyga: sure
<zyga> https://github.com/snapcore/snapd/pull/7172
<mup> PR #7172: tests: work around classic snap affecting the host <Created by zyga> <https://github.com/snapcore/snapd/pull/7172>
<zyga> thank you!
<mborzecki> mvo: morning :)
<zyga> mborzecki: on the up side, we now found this :)
<zyga> I have more coming, core is a bug rich environment
<zyga> guys, just a heads up
<zyga> I noticed some unit tests hang
<zyga> we may have a racy deadlock or something like that
<zyga> I restarted about half a dozen tests like that yesterday
 * zyga spawns more tests and goes for a break
<zyga> I work way too long lately, need to take a walk and have breakfast
<zyga> back
<zyga> no breakfast yet but I feel much better
<zyga> walk + shower :)
<mup> PR snapd#7172 closed: tests: work around classic snap affecting the host <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7172>
<zyga> mvo: did you see the python-apt + snapd build regression?
<zyga> https://www.irccloud.com/pastebin/AcGQjDFA/
<zyga> it was reported by Dimitri
<abeato> zyga, hey, was testing the change to mount /lib/firmware, but it is not happening for me - besides bind-mounting snap-confine, is there anything else I should consider?
<abeato> zyga, nm, reinstalling the snap made the trick (plus reloading the snap-confine apparmor profile)
<mvo> zyga: looking
<Chipaca> mo'in, mo'in
<zyga> abeato: Due to the place where this change happens it requires the namespace to be discarded
<zyga> Hey Chipaca
<mvo> zyga: this looks like a bug in python-apt in eoan
<zyga> re
 * zyga made a coffee
<mvo> juliank: hey, do you already know about https://paste.ubuntu.com/p/DH8YZj8Gfd/ in python-apt 1.9 - fetch_source (and probably fetch_binary) is unhappy. I can try to look into it later today if you are busy
 * zyga chases another issue in core tests
<zyga> on the up side, fewer things fail now, it takes a while to get to a broken one
<mvo> zyga: nice
<zyga> mvo: little by little, it's not green yet though
<mup> PR snapd#7167 closed: cmd/Makefile.am: support building with the go snap <Simple ð> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7167>
<zyga> brb, need to help my wife
<zyga> re
<mup> PR snapd#7173 opened: Support Tegra display drivers in x11/opengl interfaces <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/7173>
<ogra> ogra@acheron:~/Devel/branches/snapd:master$ git pull
<ogra> ...
<ogra> 1578 files changed, 153607 insertions(+), 22623 deletions(-)
<ogra> ...
<ogra> hmm, i should perhaps do that more often ...
<zyga> abeato: reviewed
<zyga> ogra: wow
 * zyga fixed another core test bug
<abeato> zyga, thanks
<mup> PR snapd#7174 opened: allow setting start_x=1 which enables the CSI interface for the RPi câ¦ <Created by ogra1> <https://github.com/snapcore/snapd/pull/7174>
<ogra> thanks zyga
<zyga> thank you ogra
<Chipaca> hm, what's even the purpose of snap.PlaceInfo
<zyga> Chipaca: there must be a place for it
 * zyga hides
<mborzecki> hehe
<mborzecki> ogra: hmm  ogra@ubuntu.com (https://api.launchpad.net/1.0/~ogra) has NOT signed the CLA
<mborzecki> our CLA checker going bonkers?
<mborzecki> Chipaca: do you have any clue what could be happening here? ^^
<Chipaca> wat
<Chipaca> mborzecki: dunno. Is there a commit by ogra in the PR in question?
<mborzecki> Chipaca: yup, From: Oliver Grawert <ogra@ubuntu.com> checks out
<Chipaca> mborzecki: hadn't we landed a change to make it pull the whole repo?
<Chipaca> mborzecki: i can't see it in the .travis.yml though
<Chipaca> mborzecki: there should be a git: depth: false in the CLA section
<mborzecki> Chipaca: it was reverted apparently
<Chipaca> mborzecki: anyway, that would/should fix it :-/
<juliank> mvo: yes I have a fix in progress
<juliank> Both hardcoded md5 so kind of good they broke
<ogra> mborzecki, Chipaca, sorry, was melting^Wlunching ... do i need to do anything ?
<Chipaca> ogra: sweat
<ogra> at yur command !
<ogra> *your
<Chipaca> 'yur' worked well in context
<Chipaca> ogra: I don't think you need to do anything, no
<ogra> ok
<Chipaca> ogra: the CLA checker has a bunch of heuristics to work around the fact that we can't ask launchpad for all your emails :-)
<Chipaca> ogra: nor can we ask it about your group membership
<Chipaca> bah
<Chipaca> we can't ask it whether you're a member of a private team
<ogra> geez ... how silly ... given you could screen-scrape them from my LP page
<Chipaca> ogra: no you can't
<Chipaca> that's the point :-)
<ogra> ah, right, private
<ogra> silly security !
<ogra> always in the way
 * zyga chases systemd/snapd mount bug :/
<zyga> man that test is very har
<zyga> dd
<zyga> google:ubuntu-core-16-64:tests/main/ubuntu-core-gadget-config-defaults:ssh_common
<zyga> this test is leaking a mount for a test snap
<zyga> the test snap cannot be removed (gadget requirement)
<zyga> the code hand crafts the removal
<zyga> but the removal depends on the mount unit being okay
<zyga> but it isnt
<zyga> daemon-reload just a moment before _probably_ corrupts systemd state
<zyga> I'm debugging but iteration is slow
<mvo> juliank: thanks!
<mvo> Chipaca: if ogra  signes with @canonical.com things are fine, no?
<Chipaca> mvo: yes
<Chipaca> mvo: or @mozilla.com :-)
<Chipaca> mvo: or if he signs the CLA
<Chipaca> s/signs/commits/
<Chipaca> mvo: or with an email address in the commit history
<Chipaca> mvo: the latter is already done, so it should work if it doesn't do --depth=50
<zyga> DOH
<zyga> man
<zyga> that's sooooo frustrating
<zyga> solved the bug
<zyga> mvo, mborzecki: can we use systemd-escape in all tests or is it absent in 14.04?
<mborzecki> zyga: don't remember
<mborzecki> wow, it's standup coffee time
<mup> PR snapd#7175 opened: gadget: effective structure role fallback, extra tests <Gadget update> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7175>
<zyga> fun bug
<zyga> and there are more of it!
<zyga> running again
<zyga> :)
<zyga> https://github.com/snapcore/snapd/pull/7176
<zyga> mborzecki, Chipaca: ^
<mup> PR #7176: tests: correctly escape mount unit path <Created by zyga> <https://github.com/snapcore/snapd/pull/7176>
<mup> PR snapd#7176 opened: tests: correctly escape mount unit path <Created by zyga> <https://github.com/snapcore/snapd/pull/7176>
<zyga> though I think I've missed a nice pun chance there
<zyga> better now
<zyga> :D
<diddledan> @popey you're better at words - can you try to explain what I failed to please?: https://forum.snapcraft.io/t/vlc-cve-a-good-oportunity-for-snappy/12440
 * popey_ looks
<diddledan> thanks :-)
<ogra> note that this CVE is also very controversial ... vlc denies it is their issue blaming it on a distro lib)
<diddledan> even more reason to steer clear :-)
<ogra> mvo, have you seen last nights discussion about classic snap vs using lxd ? i wonder if we should sunset classic for core18 and onwards and point people to use lxd containers
 * ogra must admit he hasnt used classic in ages ... 
<mvo> ogra: I did not see that but it sounds great, I think lxd is really the better choice in many ways, only for real corner cases (like low level hw access) the real one might be needed
<ogra> yeah and there you could simply download an ubuntu-base tarball and chroot
<zyga> 180/277 core tests passed without leaking any mount entries
<zyga> doh - I take that back
<zyga> wrong branch :D
<zyga> mvo: I didn't want to take more time at the standup but we have one more general issue
<zyga> mvo: some snaps leave stuff on the system when we "remove" them
<zyga> classic is one
<zyga> lxd is another
<zyga> I'll file a bug on lxd to make sure this is tracked
<mvo> zyga: ok
<zyga> mborzecki, mvo: https://github.com/snapcore/snapd/pull/7177
<zyga> another simple one
<mup> PR #7177: tests: remove test-snapd-curl <Created by zyga> <https://github.com/snapcore/snapd/pull/7177>
<mup> PR snapd#7177 opened: tests: remove test-snapd-curl <Created by zyga> <https://github.com/snapcore/snapd/pull/7177>
<zyga> sorry, force pushed because there are two tests like that
<zyga> I'll dust my cleanup-tool patch
<zyga> this will be the biggest win for reliability and speed
<zyga> test prepare/restore won't be this "magic" anymore
<mup> PR snapd#7178 opened: tests: remove test-snapd-snapctl-core18 in restore <Created by zyga> <https://github.com/snapcore/snapd/pull/7178>
<mup> PR snapd#7179 opened: tests: remove installed test snap <Created by zyga> <https://github.com/snapcore/snapd/pull/7179>
<mup> PR snapd#7180 opened: tests: remove installed snap in the restore section <Created by zyga> <https://github.com/snapcore/snapd/pull/7180>
<zyga> cachio: https://github.com/snapcore/snapd/pull/7171#pullrequestreview-267225535
<mup> PR #7171: tests: improve how the system is restored when the upgrade-from-2.15 test fails <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7171>
 * zyga runs another pass
<zyga> and spawns core18 to see what happens there
<zyga> next up pass on more than main suite
<zyga> I will land the test fix PRs when they become green
<cachio> zyga, thanks
 * zyga takes a break for an hour
<zyga> ogra: what's up with the CLA test?
<ogra> zyga, dunno, Chipaca said i dont need to do anything (i asked above)
<Chipaca> is this happening in one PR, or everywhere?
<Chipaca> zyga: ^?
<juliank> Setting up snapd (2.39.2+18.04) ...
<juliank> Installing new version of config file /etc/apparmor.d/usr.lib.snapd.snap-confine.real ...
<juliank> md5sum: /etc/apparmor.d/usr.lib.snapd.snap-confine: No such file or directory
<juliank> ^ don't like that
<zyga> juliank: oh? where is that coming from
<zyga> perhaps the dpkg conffile helpers?
<zyga> mvo: ^ help
<juliank> I just upgraded: Unpacking snapd (2.39.2+18.04) over (2.38+18.04) ...
<zyga> Chipaca: in one PR
<zyga> juliank: looks like a bug, let me look
<Chipaca> zyga: that pr (or another one that lands and then is merged) needs to update .travis.yml
<zyga> juliank: I see it, let me fix that for the next update
<zyga> Chipaca: what needs to happen in travis.yml?
<juliank> ah md5sum /etc/apparmor.d/usr.lib.snapd.snap-confine is just hardcoded in an upgrade check w/o checking if the file exists
<Chipaca> <Chipaca> mborzecki: there should be a git: depth: false in the CLA section
<Chipaca> zyga: ^
<juliank> though there is a 2>/dev/null redirect
<juliank> but at the wrong part of the pipe :D
<juliank> md5sum /etc/apparmor.d/usr.lib.snapd.snap-confine | cut -f1 -d' ' 2>/dev/null
<zyga> juliank: the redirect is on cut, I think
<juliank> should be
<zyga> yeah
<juliank> md5sum /etc/apparmor.d/usr.lib.snapd.snap-confine 2>/dev/null | cut -f1 -d' '
<zyga> -        if test "$(md5sum /etc/apparmor.d/usr.lib.snapd.snap-confine | cut -f1 -d' ' 2>/dev/null)" = "2a38d40fe662f46fedd0aefbe78f23e9"; then
<zyga> +        if test -f /etc/apparmor.d/usr.lib.snapd.snap-confine && test "$(md5sum /etc/apparmor.d/usr.lib.snapd.snap-confine | cut -f1 -d' ')" = "2a38d40fe662f46fedd0aefbe78f23e9"; then
<zyga> or like this
<zyga> a bit more verbose but perhaps more to the point
<zyga> right?
<juliank> yeah
<zyga> I'll send a PR
<zyga> thanks for reporting this
<zyga> mvo: https://github.com/snapcore/snapd/pull/7181
<zyga> before you leave please
<mup> PR #7181: packaging/debian: don't md5sum absent files <Created by zyga> <https://github.com/snapcore/snapd/pull/7181>
<zyga> juliank: ^
<juliank> thanks zyga
<mup> PR snapd#7181 opened: packaging/debian: don't md5sum absent files <Created by zyga> <https://github.com/snapcore/snapd/pull/7181>
<zyga> core16 main is clean, running all suite now
 * cachio lunch
<zyga> core18 looks ok after 50% of the pass
<zyga> I think that's all of them :)
<mup> Bug #1838040 opened: delete user data thunderbird <Snappy:New> <https://launchpad.net/bugs/1838040>
<mup> Bug #1838040 changed: delete user data thunderbird <Snappy:Invalid> <https://launchpad.net/bugs/1838040>
<zyga> some unit tests are hanging in travis
<zyga> 10 minute timeout reached
<juliank> $ snap info mojo
<juliank> error: no snap found for "mojo/"
<juliank> ^ what's that?
<zyga> is there a mojo directory?
<juliank> Oh now it works, this was happening while snap install mojo --classic was running
<zyga> snap info can be used to look at unpacked snaps on disk
<juliank> ah but yes, there is a mojo dir too
<zyga> right, that's why
<Chipaca> zyga: re https://answers.launchpad.net/snappy/+question/682352 if they removed the snap, the data is gone from disk
<zyga> Chipaca: oh, no snapshot?
<zyga> but right
<Chipaca> zyga: (if new enough they'll have snapshots)
<zyga> can you comment about the snapshot aspect
<zyga> but if they removed snapd the snapshot data is gone as well
<zyga> all core16 tests are mountinfo clean
<zyga> that's all folks :)
<Chipaca> zyga: huzzah
<Chipaca> zyga: happy weekend
<zyga> nah, I'm rewriting a helper tool from shell into python
<zyga> it will be healthier for what it will do next
<zyga> I want to fix more test bugs
<Chipaca> I'm off to the gym, then I'll review ijohnson's PR when I get back while dinner cooks
<zyga> test bugs drive me crazy
 * Chipaca hugs zyga 
<zyga> Chipaca: have fun, :)
<Chipaca> zyga: you were crazy before we had anything to do with it
<zyga> hahaha
<ijohnson> thanks Chipaca
<zyga> I'll take that as a compliment :)
<Chipaca> zyga: :-)
<mvo> zyga: thank you
<mup> PR snapd#7176 closed: tests: correctly escape mount unit path <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7176>
<zyga> lxd leakes more state on fedora
<zyga> but I'll fix that later, need to run an errand now
<zyga> two more failures from fedora: lxd cgroup state and binfmt_misc being mounted by something traversing the automount point
<popey_> aaargh
<popey_> I have a snap in a wedged state
<popey_> installed:                               (11381)   0B disabled,broken
<popey_> i can't refresh, install, enable it
<popey_> - Setup snap "lxd" (11381) security profiles (cannot find installed snap "lxd" at revision 11381: missing file /snap/lxd/11381/meta/snap.yaml)
<popey_> it's right /snap/lxd is empty
 * popey_ starts https://discuss.linuxcontainers.org/t/lxc-snap-wedged-unable-to-refresh-install-enable/5343
 * diddledan points at popey's lxd and laughs :-p
<diddledan> https://media.giphy.com/media/Q8OOs80Hb5Bj1qNA1d/giphy.gif
<diddledan> this one's better https://media.giphy.com/media/cO39srN2EUIRaVqaVq/giphy.gif
<mup> PR snapd#7179 closed: tests: remove installed test snap <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7179>
<Chipaca> popey_: are you running 5.2?
 * ijohnson lunches back in hour or two
 * cachio afk
<mup> PR snapd#7180 closed: tests: remove installed snap in the restore section <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7180>
<Chipaca> ijohnson: you mind if i push a patch to your PR?
<diddledan> how rude
<Chipaca> ijohnson: otherwise I'll pastebin a diff
<diddledan> :-p
<Chipaca> ijohnson: even if I push the patch it's still a suggestion :-)
<Chipaca> it's just that it's easier to explain in code
<Chipaca> anyway, i'm going to carry on ignoring diddledan and go make dinner
<diddledan> github totally needs the ability to file a PR against someone's PR
<ogra> ah, and i thought the ability to make dinner for you
<Chipaca> diddledan: you can file a PR against someone's branch that's PR'ed though
<diddledan> true, tho it's more complex by being a repo that you didn't "fork" from on the github ui
<ijohnson> Chipaca: go for it
<Chipaca> ijohnson: did I understand pedronis right that the values are always strings?
<Chipaca> ijohnson: meaning that the list in the verbose test is bogus?
<Chipaca> i could check the code myself but i'd have to stop stuffing my face
<mup> PR snapd#7177 closed: tests: remove test-snapd-curl <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7177>
<mup> PR snapd#7178 closed: tests: remove test-snapd-snapctl-core18 in restore <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7178>
<Chipaca> ijohnson: i pushed, but i know it breaks a test
<Chipaca> ijohnson: but the tests were broken before so i'm feeling only 90% sorry
<Chipaca> now i need to go walk the dog (otherwise i would've spent more time on this)
<Chipaca> (dog has almost given up in a huff :-( )
<Chipaca> ijohnson: the test that was failing before is about the command not being categorised. Put it under 'other', beside 'known', at least for now
<Chipaca> we're still under 80 chars so it's ok
 * Chipaca hitches the dog up to the air con
<mup> PR snapd#7181 closed: packaging/debian: don't md5sum absent files <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7181>
<mup> PR snapd#7182 opened: tests: remove core18 if installed by tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7182>
<ijohnson> I think that's correct Chipaca, that's what I understood pedronis to mean
<ijohnson> thanks for the patch, will review it, and no worries about the tests I'll clean those up
<mup> PR snapcraft#2645 opened: file utils: better error for NotADirectory <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2645>
<sergiusens> zyga: you are quick
#snappy 2019-07-27
<zigford> Anyone know why snap-confine doesn't work without adding libncurses to the apparmor profile in snapd 2.4?
<zyga> zigford: hey
<zyga> zigford: snap-confine has an apparmor profile, on each distribution it is linked with a slightly different set of libraries
<zyga> zigford: where did you encounter this issue
<zyga> zigford: if you sent me the patch you applied I will merge it
<mup> PR snapcraft#2645 closed: file utils: better error for NotADirectory <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2645>
<Serverraum> Hi I want to install the snapstore. I've actually installed snapd, but now it threw an error.
<Serverraum> "sudo snap install hello-world"
<Serverraum> error: cannot communicate with server: Post http://localhost/v2/snaps/hello-world: dial unix /run/snapd.socket: connect: no such file or directory
<Serverraum> Where do I get this file?  Or should it have been created automatically?
#snappy 2019-07-28
<mup> PR snapcraft#2634 closed: remote build: fully preserve local sources and support packaging all sources <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2634>
#snappy 2020-07-20
<mborzecki> morning
<mborzecki> hmmm Jul 20 07:43:15 galeon kernel: BUG: kernel NULL pointer dereference, address: 0000000000000008
<zyga> pedronis we need your powers to force merge https://github.com/snapcore/snapd/pull/9037 and a few related master fixes
<mup> PR #9037: tests: adjust xdg-open after launcher changes <Simple ð> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9037>
<mborzeck1> zyga: hi, and yeah pinged pedronis in 9037 and #9034
<mup> PR #9034: cmd/snap-seccomp/syscalls: add faccessat2 <Simple ð> <â  Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9034>
<zyga-mbp> hi, yeah, thank you for linking them from the other pr
<mborzeck1> zyga: btw. pushed the base template tweak jdstrand suggested in 9034, can you take a look?
<zyga-mbp> I had a good weekend, mostly sleeping but relatively little pain
<zyga-mbp> sure, looking
<zyga-mbp> done
<mborzeck1> zyga-mbp: that's nice ;) glad you're in a better mood
<zyga-mbp> yeah, just 8 days left
<zyga-mbp> feels like it's tomorrow
<zyga-mbp> one day will be painful as I cannot take meds for testing
<zyga-mbp> but I'll manage
<zyga-mbp> mborzeck1 perhaps we could merge all fixes into one PR
<zyga-mbp> to ensure nothing is still broken
<mborzeck1> zyga-mbp: mhm, can try, let me open one
<zyga-mbp> great, thanks
 * zyga-mbp quickly pays taxes
<pedronis> I just merged #9037
<mup> PR #9037: tests: adjust xdg-open after launcher changes <Simple ð> <â  Critical> <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9037>
<mborzeck1> pedronis: cool, thanks!
<zyga-mbp> woot
<mborzeck1> pedronis: can you also land 9034 when the spread job finishes?
<pedronis> mborzeck1: yes
<mborzeck1> pedronis: and good morning :)
<pedronis> mborzeck1: there was a weird core 20 prepare failure though
<pedronis> we'll need to see the state of things
<mborzeck1> pedronis: the one i looked at before seemed to be a result of missing #8883
<mup> PR #8883: packaging: stop snapd early on purge <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8883>
<zyga-mbp> mborzeck1 perhaps after the critical fixes land we can look at the purge problem again
<zyga-mbp> ha :)
<zyga-mbp> taxes paid
<mup> PR snapd#9037 closed: tests: adjust xdg-open after launcher changes <Simple ð> <â  Critical> <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9037>
<pedronis> mborzecki: zyga-mbp: anyway we should try to focus on landing PRs for a bit, we definitely have too many open atm
<zyga-mbp> agreed
<mborzecki> pedronis: do you think we should have a chat about https://forum.snapcraft.io/t/installation-of-snap-with-content-snap-as-dependency/16103/11 ? looks like preqrequisites are only waited for in auto-connect, so link snap runs before and it is possible to start applications too early
<pedronis> mborzecki: if we waited in link snap we could get mutual blocked things
<pedronis> mborzecki: it's a big topic, it is kind of working as designed, in the sense that we don't have a concept of mandatory interfaces
<mborzecki> pedronis: as in task deadlock? link snap could accidentally keep waiting for another link snap?
<zyga-mbp> mborzecki could the new inhibition lock be of use?
<zyga-mbp> we could inhibit startup until the dependencies are met
<zyga-mbp> though it's not exactly designed for that
<pedronis> mborzecki: yes, the logic if I remember works exactly because the waiting is assymmetric, but I would need to reload a lot of state
<pedronis> mborzecki: anyway implicitly the current design says that app should do something reasonable if plugs are not connected, in practice if the content is libs that's hard
<pedronis> zyga-mbp: yes, the lock can probably help, if we decide to go that way
<mborzecki> pedronis: could you add a note to the topic stating it's somewhat convoluted and maybe we could discuss it once the PR count is down? even if the end game is just adding some comments to the code
<pedronis> zyga-mbp: we would need to be careful with hooks though
<zyga-mbp> yeah, I think it's not a perfect fit
<zyga-mbp> because things appear to run, just stall
<pedronis> I think that might be fine
<pedronis> but anyway this is too complex to deal quickly right now
<pedronis> mborzecki: I put it in my queue
<mborzecki> pedronis: thank you!
<pedronis> it also really relates to the desktop icon
<pedronis> in practical ux terms
<mborzecki> pedronis: yeah. perhaps it's a simple as making the desktop file appear later
<zyga> jamesh https://github.com/snapcore/snapd/pull/8861#pullrequestreview-451379010
<mup> PR #8861: data,packaging,wrappers: extend D-Bus service activation search path <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8861>
<jamesh> zyga: looking
<zyga> jamesh note that master is not fixed yet
<zyga> good morning :)
<zyga> but should be later today
<jamesh> zyga: thanks.  That should get the wrappers PR unblocked
<pedronis> gah: the last XXX in osutil became the package doc :/
<zyga> pedronis please merge https://github.com/snapcore/snapd/pull/9034 as well
<mup> PR #9034: cmd/snap-seccomp/syscalls: add faccessat2 <Simple ð> <â  Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9034>
<zyga> pedronis I can send a quick PR correcting the XXX after master is fixed
<mborzecki> zyga: i think centos-8 spread job is still running
<zyga> oh, sorry, didn't see that
<zyga> yeah
<pedronis> yea, is still running something
<pedronis> I'll do once it's done
<zyga> brb
<mborzecki> pedronis: all spread jobs are done now
<zyga> I've upgraded github actions on a single runner to see how they behave
<zyga> I'll be monitoring that runner today
<zyga> the new release brings a whole bucket of fixes over what we hav
<mborzecki> heh the tests/main/interfaces-process-control test is flaky
<mborzecki> and failed in a funny way
<zyga> oh, can you paste the link to the failure please
<mborzecki> https://paste.ubuntu.com/p/kXKbbzgzwZ/ the test was verifying that pid 2499 does not exist, which is ok, but grep did not account for pids that start with 2499 (eg 24998)
<zyga> lol
<zyga> ok
<mborzecki> once 9034 lands i'll open a fix, should land quickly
<pedronis> mborzecki: I landed 9034
<mborzecki> pedronis: thanks!
<pedronis> centos exploded in a lot of funny ways fwiw
<mup> PR snapd#9034 closed: cmd/snap-seccomp/syscalls: add faccessat2 <Simple ð> <â  Critical> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9034>
<zyga> mborzecki I've fixed the test
<mborzecki> zyga: hm? process-control one?
<zyga> yep
<mborzecki> ah, ok, my local spread run has finished and was about to push a branch
<zyga> how did you fix it?
<zyga> I used kill with signal 0
<zyga> https://github.com/snapcore/snapd/compare/master...zyga:fix/incorrect-pid-checks?expand=1
<mborzecki> zyga: your fix is better, i tweaked the grep pattern to "$pid "
<zyga> I'll rebase it on top of the fixed master and send the patch when that's possible
<mborzecki> cool
<zyga> pedronis btw, not sure if you noticed this before
<zyga> https://forum.snapcraft.io/t/injecting-snapd-tools-into-base-snaps-and-keeping-them-up-to-date/12139/8?u=zyga
<pedronis> zyga: yes, I noticed but didn't look at it closely yet
<pedronis> mborzecki: I reviewed #9030
<mup> PR #9030: bootloader/assets: helpers for registering per-edition snippets, register snippets for grub <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9030>
<mborzecki> pedronis: thanks, i'm tweaking 9033 and will fix that one next
<mup> PR snapd#9038 opened: tests: check for pids correctly <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/9038>
<zyga> mborzecki ^
<zyga> brb
<pedronis> zyga: I pushed some small adjustments to #9028, could you double check them?
<mup> PR #9028: interfaces: new helpers to get and compare system key, for use with seeding debug api (1/N) <Needs Samuele review> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9028>
<zyga> sure
<zyga> time for meds
<mborzecki> zyga: hmm https://paste.ubuntu.com/p/6h9PQm5QSK/ wierd, did /boot/efi just go away?
<zyga> it seems we are no longer booting in EFI mode?
<mborzecki> zyga: idk, why would that change?
<zyga> I have no idea
<zyga> new image?
<zyga> some tweak to some panel I never saw
<zyga> dunn
<zyga> *dunno
<mborzecki> same question, why would that change? :P
<zyga> I think that's a question for cachio
<zyga> he has more visibility into that layer
<zyga> I just don't know at all
<zyga> there's no trace of image updates that I know of
<mborzecki> hmm store throwing 408 too
<zyga> oh, thunder
<zyga> but the sky is blue
 * zyga looks
 * zyga sent more reviews for the point release break-out PRs
<zyga> https://github.com/snapcore/snapd/pull/9024#pullrequestreview-451499623
<mup> PR #9024: sysconfig/cloudinit: add RestrictCloudInit <Created by mvo5> <https://github.com/snapcore/snapd/pull/9024>
<pedronis> mborzecki: this is fix committed:  https://bugs.launchpad.net/snappy/+bug/1857128 because the portal stuff was landed?
<mup> Bug #1857128: Missing configuration option to allow a snap to openFile without prompting <desktop> <Snappy:Confirmed> <https://launchpad.net/bugs/1857128>
<mborzecki> pedronis: yes, it landed in https://github.com/snapcore/snapd/pull/8289, so maybe even fix released
<mup> PR #8289: xdgopenproxy: forward requests to the desktop portal <Squash-merge> <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8289>
<pedronis> yes, it was in 2.45
<mborzecki> pedronis: are you switching the status in LP or should I/
<pedronis> I'm switching it
<mborzecki> pedronis: thanks
<mup> Bug #1857128 changed: Missing configuration option to allow a snap to openFile without prompting <desktop> <Snappy:Fix Released> <https://launchpad.net/bugs/1857128>
<mup> PR snapd#9033 closed: osutil, many: add helper for checking whether the process is a go test binary  <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9033>
<zyga-mbp> I'll be back in 5
<zyga-mbp> I installed the new leap release
<zyga-mbp> it's interesting that it's not a sync of tumbleweed
<zyga-mbp> it's a more conservative upgrade
<jdstrand> zyga-mbp: hey, it plugs gtk2-common-themes. here is the full snapcraft.yaml: https://git.launchpad.net/~jdstrand/+git/hamster-jdstrand/tree/snapcraft.yaml. note, that version of the yaml has the layout at the bottom commented out, but when I pinged you, I was using that layout
<zyga-mbp> jdstrand hey, let me look
<zyga-mbp> jdstrand do you have the machine where this happened?
<jdstrand> zyga-mbp: yes
<jdstrand> it is my laptop :)
<zyga-mbp> jdstrand can you check if the mount profile had the layout entries?
<jdstrand> zyga-mbp: you mean the fstab file?
<zyga-mbp> yes
<pedronis> ijohnson: do you want to look at https://github.com/snapcore/snapd/pull/9028 before it lands?
<mup> PR #9028: interfaces: new helpers to get and compare system key, for use with seeding debug api (1/N) <Needs Samuele review> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9028>
<jdstrand> zyga-mbp: well, like I said, I removed the layout. I did look at that file and I'm quite sure it had it, but mountinfo after nsenter didn't
<ijohnson> pedronis: sure let me quickly review it now
<zyga-mbp> jdstrand mhm, the content interfaces there do not interact with /usr so I think we can rule out some bugs related to that
<zyga-mbp> I cannot explain why that would happen
<jdstrand> zyga-mbp: yeah, I don't really have enough info. I really just wanted you to know that I suspect it was happening after a refresh of the snapd snap
<zyga-mbp> of snapd snap - hmm!
<jdstrand> I can't say for sure though
<jdstrand> zyga-mbp: but I moved to snapd from edge to get an interface that is only there, and I was seeing this issue daily. we know edge updates daily...
<jdstrand> zyga-mbp: I don't know if it was coincidence or not though, but it made me suspicious
<jdstrand> let me try something in a vm
<zyga> re, sorry, even moving across vms suspens my laptop
<zyga> er
<zyga> not vms, rooms
<pedronis> ijohnson: the preseed test issue seems to be constant on 20.10, not sure what is going on, but is not related to cloud-init in particular
<mup> PR snapd#9028 closed: interfaces: new helpers to get and compare system key, for use with seeding debug api (1/N) <Needs Samuele review> <Preseeding ð> <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9028>
<ijohnson> pedronis: yes I will look into it shortly, just finishing up something else right now
<pedronis> zyga-mbp: cachio: what is blocking #8950 ?
<mup> PR #8950: tests: new to-one-line tool which replaces the strings.sh helper <Squash-merge> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8950>
<zyga-mbp> nothing from my POV
<cachio> pedronis, a second review?
<pedronis> zyga-mbp: cachio: there is discussion about a shellcheck override, that isn't to me if it's nice to have or a blocker
<pedronis> *isn't clear
<zyga-mbp> ah, that, we discussed that on mattermost and I'm +1 on the approach now
<cachio> pedronis, currently we have a check in the unit/go test
<cachio> we discussed that with zyga last week
<cachio> I'll prepare a pr to make a geniric shellcheck on each test this week, the idea is that each test defines which is the tool to test and that should be enought
<pedronis> zyga-mbp: cachio: I'm landing it then, there can always be follow up but is been open for enough time
<zyga-mbp> thansk!
<cachio> pedronis, tx
<zyga-mbp> *thanks
<mup> PR snapd#8950 closed: tests: new to-one-line tool which replaces the strings.sh helper <Squash-merge> <Created by sergiocazzolato> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8950>
<mup> PR snapcraft#3223 opened: sentry: don't report tool missing errors <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3223>
 * cachio lunch
<zyga-mbp> brb
<mup> PR snapcraft#3224 opened: cli: provide option to install ca certs into build environment <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3224>
<jdstrand> zyga: aha, here is your reproducer: https://bugs.launchpad.net/snapd/+bug/1888305
<mup> Bug #1888305: layout lost after snapd refresh with long running content plugging snap <snapd:New> <https://launchpad.net/bugs/1888305>
<ogra_> jdstrand, hmm ... do we have any interface where we could add mailbox access ?
<ogra_> Jul 20 21:55:38 pi4 kernel: audit: type=1400 audit(1595282138.714:760ð apparmor="DENIED" operation="open" profile="snap.node-red-rpi.node-red" name="/dev/vcio" pid=24279 comm="python" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<ogra_> (heh ... silly emoji plugin)
<ogra_> vcio seems to be the device to access the VC mailbox in the Pi GPU firmware
<jdstrand> ogra_: yeah, we do not. that seems like perhaps an addition to the opengl interface
<jdstrand> ogra_: I added a todo to investigate for 2.46
<ogra_> thanks !
#snappy 2020-07-21
<mborzecki> morning
<mborzecki> heh, vendor.json keep flipping between 2 revisions of secboot package
<mborzecki> jamesh: iirc pulseaudio tests fail pretty consistently on 20.10, i don't remember whether it's the same case for preseed though
<jamesh> mborzecki: thanks.
<mborzecki> hmm interesting behavior of shellcheck https://github.com/koalaman/shellcheck/issues/650
<mup> PR snapd#8851 closed: interface/fwupd: add more policies for making fwupd upstream strict <Needs security review> <Created by woodrow-shen> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8851>
<pedronis> mborzeck1: hi, could you finish the review of #8959 when you have a moment, I will also look at it today
<mup> PR #8959: gadget,gadget/install: refactor partition table update <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8959>
<mborzecki> it'd be nice if for queued check jobs, there'd be some info since when the job has been in that state
<mup> PR snapd#9023 closed: sysconfig/cloudinit: add CloudInitStatus func + CloudInitState type <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9023>
<jamesh> pedronis: do you think https://github.com/snapcore/snapd/pull/8861 is good to merge then?
<mup> PR #8861: data,packaging,wrappers: extend D-Bus service activation search path <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8861>
<pedronis> jamesh: I need to look at it again, I'll try to do that today or tomorrow
<jamesh> thanks.
<mup> PR snapd#8959 closed: gadget,gadget/install: refactor partition table update <UC20> <Created by cmatsuoka> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8959>
<jdstrand> zyga: not sure if you say, but I have a reproducer: https://bugs.launchpad.net/snapd/+bug/1888305
<mup> Bug #1888305: layout lost after snapd refresh with long running content plugging snap <snapd:New for zyga> <https://launchpad.net/bugs/1888305>
<jdstrand> zyga: saw*
<jdstrand> zyga: and hello :)
<ijohnson> jdstrand: I think Zygmunt is off today
<mup> PR core20#76 opened: hooks/001-extra-packages.chroot: add gdbserver <Created by anonymouse64> <https://github.com/snapcore/core20/pull/76>
<mup> PR core18#163 opened: hooks/001-extra-packages.chroot: add gdbserver <Created by anonymouse64> <https://github.com/snapcore/core18/pull/163>
<mup> PR snapd#9039 opened: cmd/snap-seccomp/syscalls: add faccessat2 (2.45) <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9039>
<mborzecki> pedronis: ^^
<pedronis> thanks
<mborzecki> pedronis: fwiw google:ubuntu-20.10-64:tests/main/interfaces-audio-playback-record seems to be passing in isolation
<pedronis> interesting
<mborzecki> pedronis: the recording bit i handled by snap policy module which is added by ubuntu patches, and it queries the snapd api to get the connected plugs
<pedronis> yes
<mborzecki> pedronis: there shouldn't be any races there though
<mborzecki> pedronis: otoh, it ECONNREFUSED, so maybe pulseaudio just died there?
<zyga> o/
<zyga> jdstrand: that's great news
<ijohnson> hey zyga
 * zyga woke up and catching up
<zyga> today was not the best but it's almost over
<zyga> ah
<zyga> jdstrand: interesting that it is related to snapd refresh
<zyga> it could be related to something i was looking at lately
<zyga> jdstrand: https://forum.snapcraft.io/t/injecting-snapd-tools-into-base-snaps-and-keeping-them-up-to-date/12139
<zyga> (the last comment there)
<zyga> no need to read it but I suspect that's really just uncovering a bug we knew existed for a while
<zyga> it's great that there's a reproducer, I will try to pull myself together and write a spread test based on your super detailed bug report
 * cachio lunch
<zyga> hey ijohnson :)
<pedronis> ijohnson: I did a review of #9010
<mup> PR #9010: cmd/snap-bootstrap/initramfs-mounts: call systemd-mount instead of the-tool <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9010>
<pedronis> zyga: hi, I reviewed #8977 in my morning
<mup> PR #8977: cmd/snap: track started apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/8977>
<zyga> thank you, I didn't look yet
 * zyga looks
<zyga> ah, thanks I'll send some updates there shortly
<zyga> I will be around normally tomorrow
<jdstrand> zyga: cool, thanks (though, I was told today you're off, so, only do it if it is fun and relaxing :)
<zyga> jdstrand: yes because it's a mystery and I want to know :)
<jdstrand> :)
<jdstrand> zyga: hopefully for a spread test you will create a smaller reproducer snap ;)
<zyga> yes, I just did
<pedronis> ijohnson: when you have time, #9030 needs your review
<mup> PR #9030: bootloader/assets: helpers for registering per-edition snippets, register snippets for grub <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9030>
<ijohnson> pedronis: yes I will review it today
<ijohnson> and thanks for the review
<pedronis> np, thank you
<pedronis> mostly eod but I will look again later at the tests of some PRs to see if they are landable
<zyga> jdstrand: btw, did you notice that the snap has this:     target: $SNAP/data-dir/icons
<zyga> twice
<zyga> (I guess we should validate better)
<jdstrand> zyga: ah, no, thanks! this doesn't use sounds so I never noticed it
<Elleo> what's the correct way to get the user's real home directory from within a snap?
<zyga> Elleo: there isn't a perfect way but most people use /home/$LOGNAME
<Elleo> zyga: okay, thanks
<zyga> I have a patch somewhere that provides that but it's not proposed anywhere
<Elleo> ah, okay
<Elleo> I vaguely remembered some discussion of adding an "$ORIG_HOME" variable or something, but wasn't sure if that ever happened
<zyga> right, I don't think it did
<cachio> ijohnson, hey
<cachio> ijohnson, about the comment https://github.com/snapcore/snapd/pull/9027#discussion_r458208030
<mup> PR #9027: tests: refresh/revert snapd in uc20 <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9027>
<cachio> ijohnson, cmatsuoka requested me to force the reboot when we refresh and revert snapd
<cachio> to check if tpm works well afte the reboot
<cachio> or it is ok and I should leave the code you proposed without explaining why we force the reboot
<ijohnson> cachio: I understand
<ijohnson> cachio: it's okay to still do a reboot after the refresh
<ijohnson> cachio but the code as is is masking whether or not snapd triggered a reboot for the given type of refresh
<cachio> ijohnson, yes, that could be a problem
<ijohnson> The code you have always reboots and so if there was a bug where we trigger a reboot when we shouldn't be, or vice versa, your code would mask the problem and make the test pass
<cachio> or perhaps it does not work properly if we dont reboot
<ijohnson> Yes exactly
<cachio> perhaps I could test both scnarios
<ijohnson> That's why I wanted you to refactor it to check what kind of snap was being refreshed, and ensure the change for snaps that don't automatically trigger a reboot don't trigger a reboot
<cachio> 1 forcing reboot and also without reboot
<ijohnson> I provided some example code for how to do that
<ijohnson> cachio: I don't think we need two tests
<ijohnson> Just make the existing test slightly more accommodating to the different scenarios
<cachio> ijohnson, I mean, same test test both thinks
<cachio> things
<cachio> ijohnson, but in the code you proposed it is going to reboot always for snapd and pc snaps
<cachio> it is waiting until the refresh is comppleted fedore the reboot
<cachio> right?
<ijohnson> cachio: yes it will reboot anyways but if snapd triggered the reboot it would make one of the commands fail if I understand what I wrote correctly
<ijohnson> Yes exactly if the reboot was triggered as part of the refresh then I think that command would exit non-xero and the test would fail
<cachio> ijohnson, ah, ok, in that case I'll apply that
<cachio> thanks for the suggestion
<ijohnson> cachio: yaw, hopefully it's not too difficult to make work
<cachio> trying now
<mup> PR snapd#9038 closed: tests: check for pids correctly <Test Robustness> <Created by zyga> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9038>
<zyga> jdstrand: interesting, the reproducer fails with
<zyga> + test-snapd-app.sh -c test -d /usr/share/hamster-applet
<zyga> update.go:85: cannot change mount namespace according to change mount (/snap/gtk-common-themes/1506/share/gtk2/Materia-compact /snap/test-snapd-app/x1/data-dir/themes/Materia-compact none bind,ro 0 0): cannot write to "/snap/gtk-common-themes/1506/share/gtk2/Materia-compact" because it would affect the host in "/snap"
<mup> PR snapd#9040 opened: spread: add opensuse 15.2 and tumbleweed for qemu <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/9040>
<jdstrand> zyga: huh
<jdstrand> zyga: fyi, don't worry about tumbleweed lzo. I am doing it
<zyga> k
<zyga> that log is just a warning, not an error (in the sense that it doesn't stop)
<zyga> but it's still wrong
<jdstrand> yeah
 * jdstrand idly wonders if his https://blog.strandboge.com/2019/04/16/cloud-images-qemu-cloud-init-and-snapd-spread-tests/ has been useful for others here... I've found it immensely useful for my spread testing :)
<mup> PR snapd#9018 closed: cmd/snap-preseed: check that target path exists and is a directory on --reset <Preseeding ð> <Simple ð> <Created by stolowski> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9018>
<zyga> kenvandine: hi
<zyga> I found a small bug in gtk-common-themes
<zyga> cat /snap/gtk-common-themes/current/meta/snap.yaml | grep Materia-dark-compact
<zyga> this shows
<zyga>       - $SNAP/share/gtk2/Materia-dark-compact
<zyga> but
<zyga> ls -ld /snap/gtk-common-themes/1506/share/gtk2/Materia-dark-compact
<zyga> ls: cannot access '/snap/gtk-common-themes/1506/share/gtk2/Materia-dark-compact': No such file or directory
<zyga> jdstrand: the error was a red herring
<mup> PR snapd#9041 opened: osutil/group.go: treat all non-nil errs from user.Lookup{Group,} as Unknown* <Bug> <Preseeding ð> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9041>
<zyga> something is weird in a way that makes no sense
<ijohnson> tell me about it
 * ijohnson is slightly bitter about error checking getpwnam_r
<pedronis> zyga: have we just too many PRs, started too many tests, or something else is off, we have some PRs with queued tests since hours, for example: https://github.com/snapcore/snapd/pull/9012
<mup> PR #9012: release/2.45: merge 2.45.2 release <Created by mvo5> <https://github.com/snapcore/snapd/pull/9012>
<zyga> pedronis: checking
<zyga> only 4 spread runs in progress
<zyga> now three
<zyga> we may be queued on the github hosted tests
<zyga> https://github.com/snapcore/snapd/actions?query=is%3Aqueued is very small
<ijohnson> it's odd that there's a bunch of jobs that are still waiting though
<ijohnson> for example https://github.com/snapcore/snapd/pull/9013
<mup> PR #9013: many: merge 2.45.2 fixes back into master <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9013>
<ijohnson> actually now that I mention it that's the only one I can find other than the one pedronis found
<zyga> hmmm
<zyga> I did the close & reopen dance
<zyga> now they show up in the queue
<zyga> ijohnson: when it says "expected"
<zyga> it means that it's not queued
<zyga> but the rules say it should run
<ijohnson> ah interesting
<zyga> so likely a bug on their side
<zyga> I close/reopend both
<zyga> that reliably fixes it
<ijohnson> zyga: so does it work to close and re-open someone else's PR?
<zyga> or not?
<zyga> yeah
<ijohnson> I seem to have thought that wasn't allowed
<zyga> it didn't change from queued
<zyga> er
<ijohnson> but maybe I just misremember that
<zyga> from expected
<zyga> I wonder if the fact it has conflicts matters
<zyga> could it be that actions don't run
<zyga> because it cannot be merged
<zyga> so it cannot create the workspace for actions?
<ijohnson> mmm interesting
<ijohnson> could be
<zyga> eh, shit
<zyga> I just got a note that I need to re-do blood tests
<zyga> for unknown reason
<zyga> so I need to go there again and endure the morning without painkillers
<zyga> eh, ...
<zyga> more details in the morning
<ijohnson> oh I'm so sorry to hear that
<zyga> oh well
<ijohnson> hope everything's still ok for your surgery
<zyga> every day is something now
<zyga> but it's just a few more days
<zyga> then it's going to be better
<zyga> week to get the stitches removed
<zyga> about two weeks for most of the cut to heal
<zyga> and in a month I should be able to sit normally again
<zyga> jdstrand: do you have any experimental options set?
<jdstrand> zyga: I do. is there an easy to list them all?
<jdstrand> ah yes
<jdstrand> $ sudo snap get system experimental
<jdstrand> Key                              Value
<jdstrand> experimental.hotplug             true
<jdstrand> experimental.parallel-instances  true
<jdstrand> zyga: ^
<zyga> thanks
<zyga> jdstrand: no luck with a reproducer
<zyga> I'll try more tomorrow
<zyga> I pushed what I have
<zyga> https://github.com/snapcore/snapd/compare/master...zyga:fix/lp-1888305?expand=1
<zyga> o/
#snappy 2020-07-22
<mborzecki> morning
<zyga> re
<zyga> 30 min
<zyga> till meds
<zyga> thank you for moving the call
<zyga> uh, lots of pain
<mborzecki> pedronis: hi, wondering maybe we should try to cherry-pick to 2.45 the commits that tweak spread.yaml so that we get the caching behavior from master
<mup> PR snapd#9042 opened: interfaces: optimize rules of multiple connected iio/i2c/spi plugs (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9042>
<pedronis> mborzecki: yes, possibly, I'm still trying to land #9012 first
<mup> PR #9012: release/2.45: merge 2.45.2 release <Created by mvo5> <https://github.com/snapcore/snapd/pull/9012>
<mup> PR snapd#9043 opened: daemon: decompose access check into smaller primitive access checkers <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/9043>
<mup> PR snapd#9044 opened: github: cherry-pick gh-action fixes (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9044>
<mborzecki> pedronis: ^^ let's see how far that PR will run
<zyga-x240> okay, so this is much more lucid now
<mborzecki> zyga-x240: https://github.com/snapcore/snapd/pull/9042 apparmor cherrypicks
<mup> PR #9042: interfaces: optimize rules of multiple connected iio/i2c/spi plugs (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9042>
<mborzecki> zyga-x240: and https://github.com/snapcore/snapd/pull/9044 that's the gh actins caching tweaks
<mup> PR #9044: github: cherry-pick gh-action fixes (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9044>
<mborzecki> and it's red (unsurprisingly?)
<ogra_> hmm, does command-chain only work for nondaemon apps ?
<zyga-x240> ogra_: it should not matter
<ogra_> (it does nto seem to get executed for me )
<ogra_> *not
<ogra_> weird
<zyga-x240> looking at the failures
<ogra_> oh !
<ogra_> seems snapcraft ignores changes in snap/local (where my script lives) ð
<zyga-x240> just preseed failures
 * ogra_ manually cleans the part 
<zyga-x240> well, in 19.10 - more failures elsewhere
<zyga-x240> shellcheck issues
<zyga-x240> pain slowly going away
<mborzecki> pedronis: i've left a note about failures in https://github.com/snapcore/snapd/pull/9012 i think we should just force merge and i'll start cherry-picking the obvious things (cc zyga-x240)
<mup> PR #9012: release/2.45: merge 2.45.2 release <Created by mvo5> <https://github.com/snapcore/snapd/pull/9012>
<zyga-x240> looking
<zyga-x240> I've ran the unit tests test alone and it passed
<zyga-x240> so maybe random as well
<zyga-x240> ah drat, wrong branch
<pedronis> mborzecki: thx, other emergency maybe solved
<pedronis> we'll see
<zyga-x240> I agree we should merge
<zyga-x240> and iterate
<pedronis> I'look in a bit
<pedronis> zyga-x240: mborzecki: merged
<pedronis> mborzecki: it seems most thing you mentioned worth cherry picking are kind of small?
<pedronis> mborzecki: maybe worth doing one PRs with them, most of them?
<pedronis> to 2.45?
<mborzecki> pedronis: yes, i'll do it
<mborzecki> pedronis: thanks for merging the branch
<mup> PR snapd#9012 closed: release/2.45: merge 2.45.2 release <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9012>
<zyga-x240> we have this 41d38c4b7f7554bdef88d567608241930a237cd9
<zyga-x240> let me check if that is in the release branch
<zyga-x240> (nfs fix)
<mborzecki> zyga-x240: ah, cool
<zyga-x240> one sec
<mup> PR snapd#9039 closed: cmd/snap-seccomp/syscalls: add faccessat2 (2.45) <Simple ð> <â Blocked> <Created by bboozzoo> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/9039>
<zyga-x240> https://github.com/snapcore/snapd/pull/9045
<mup> PR #9045: Disable part of the nfs-support test that checks udp proto on debian-â¦ <Created by zyga> <https://github.com/snapcore/snapd/pull/9045>
<zyga-x240> now about https://github.com/snapcore/snapd/pull/9044
<mup> PR #9044: github: cherry-pick gh-action fixes (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9044>
 * zyga-x240 looks at failures
<mborzecki> zyga-x240: looked at failures already, i'll stat pushing cherry-picks there
<mborzecki> zyga-x240: also, will pick 9045
<zyga-x240> ok
<mup> PR snapd#9045 opened: Disable part of the nfs-support test that checks udp proto on debian-â¦ <Created by zyga> <https://github.com/snapcore/snapd/pull/9045>
<mborzecki> zyga-x240: pushed most to #9044, i need to look at the PR with preseed tests, either pick everything from it or just https://github.com/snapcore/snapd/commit/0a9a25f1b4c3a711a96874a1d14933d01a97e0e8
<mup> PR #9044: many: cherry-picks for 2.45, gh-action, test fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9044>
<zyga-x240> mborzecki: shall I push there directly?
<mborzecki> zyga-x240: hmm, yes, but maybe let's wait for spread jobs to run through
<zyga-x240> ok
<mborzecki> zyga-x240: btw. tests/main/lxd has changed quite a bit, one from 2.45 branch is failing spread-shellcheck locally here: https://paste.ubuntu.com/p/W9htPXc3bx/
<mborzecki> zyga-x240: hm fixes are trivial, so i'll just fix it rather than picking even more patches :/
<zyga-x240> eh, silly shellcheck
<zyga-x240> ok
 * zyga-x240 backported preseed fixes, testing now
 * zyga-x240 looks at go
<zyga-x240> https://github.com/snapcore/snapd/pull/9046 has the preseed changes, it should be merged into https://github.com/snapcore/snapd/pull/9044 when another round of tests passes
<mup> PR #9046: tests: backport preseed test fixes to 2.45 <Created by zyga> <https://github.com/snapcore/snapd/pull/9046>
<mup> PR #9044: many: cherry-picks for 2.45, gh-action, test fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9044>
<mborzecki> zyga-x240: thanks
<mborzecki> wow, commits form april
<mborzecki> from
<zyga-x240> we should release 2.46
<zyga-x240> even if it's not in stable
<zyga-x240> just try to iterate
<mup> PR snapd#9046 opened: tests: backport preseed test fixes to 2.45 <Created by zyga> <https://github.com/snapcore/snapd/pull/9046>
<mborzecki> zyga-x240: hm maybe i should just cherry-pick everything from 9046 to 9044
<zyga-x240> yes
<zyga-x240> git merge it
<mborzecki> mhm
<zyga-x240> I opened it separately to see how it behaves
<mborzecki> will do
<mborzecki> zyga-x240: one more cherry-pick i didn't notice before: https://github.com/snapcore/snapd/commit/6c09de0f3f
<zyga-x240> ah
<zyga-x240> put it directly into your fixes branch
<mborzecki> yup
<pedronis> mborzecki: the plan is to land only 9044?
<mborzecki> pedronis: yes, i plan to push necessary fixes to 9044, land it, and then rebase #9042 on top
<mup> PR #9042: interfaces: optimize rules of multiple connected iio/i2c/spi plugs (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9042>
<mborzecki> pedronis: the good part is that most changes, if not all are in tests
<pedronis> mborzecki: sounds good
<zyga-x240> hmmm
<zyga-x240> is there anything in go that guarantees errno is set to zero before C calls?
<zyga-x240> because if not then user/ is buggy
<zyga-x240> ijohnson: around?
<zyga-x240> mborzecki: maybe cherry pick the travis test away as well :D
<pedronis> zyga-x240: go in general does it own syscall handling, it not following C conventions
<ijohnson> zyga, not quite yet still having breakfast but I'll be into the office in 30 min or so
<pedronis> I suspect cgo does the right thing
<pedronis> but would need to dig
<zyga-x240> mmm
<zyga-x240> ijohnson: ok
<zyga-x240> talk to you later
 * zyga-x240 reviewed https://github.com/snapcore/snapd/pull/9041#pullrequestreview-453246893
<mup> PR #9041: osutil/group.go: treat all non-nil errs from user.Lookup{Group,} as Unknown* <Bug> <Preseeding ð> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9041>
<mborzecki> zyga-x240: all of it now https://github.com/snapcore/snapd/pull/9044 hopefully we can land it once the spread jobs finish
<mup> PR #9044: many: cherry-picks for 2.45, gh-action, test fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9044>
<zyga-x240>  brb
<paul424> I try to modfiy the file : /snap/opendungeons/27/etc/opendungeons/plugins.cfg  ; I get non-writable file system. What should I do to modfiy the aforementioned file ? :)
<mborzecki> paul424: is this fil expected to be modified by the end users?
<mborzecki> heh, we have `var osutilFindGid = osutil.FindGid` in journal.go which does not appear to be used?
<paul424> well yes and no, the friend of mine created ad hoc solution of packaging the OD into snap; usually the user is expected to modfiy the file plugins.cfg in Ogre3d game engine for example : to set the proper path of the rendering plugins
<mborzecki> pedronis: all patches (sans apparmor backports) are now in https://github.com/snapcore/snapd/pull/9044 if you want to take a look
<mup> PR #9044: many: cherry-picks for 2.45, gh-action, test fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9044>
<paul424> so... but I remember I somehow by-passed this and run succesfully OD .... problem is I don't remember how...
<mborzecki> paul424: as those plugins something the user is expected to be able to add later?
<mborzecki> s/as/are/
<paul424> mborzecki: the rendering plugins comes with Ogre3d engine hmm ....
<paul424> PluginFolder=/usr/lib/OGRE
<paul424> cause troubles, also shoudn't that be reassigned to diffrent path if it is running under snap ? That is to the path of Snap's Ogre library ?
<paul424> the snap ogre lib is in :  /snap/ogre/151/lib/
<paul424> Does snapper create a virtual executable envoierment or something ?
<zyga-x240> paul424: snaps are immutable filesysytems, they cannot be modified at all
<paul424> great
<zyga-x240> paul424: snap author should arrage for files that need to be modified to live in other places
<zyga-x240> paul424: like $SNAP_DATA or $SNAP_USER_DATA
<zyga-x240> paul424: there are ways to make this work but it requires some cooperation with the snap author
<mborzecki> zyga-x240: in this case it sounds like ogre (the engine) is expected to be a content snap?
 * zyga-x240 doesn't want to jump into details 
<paul424> thanks for enlighting me :D
<zyga-x240> mborzecki: https://github.com/snapcore/snapd/pull/9044 looks optimistic
<mup> PR #9044: many: cherry-picks for 2.45, gh-action, test fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9044>
 * ijohnson is back
<mborzecki> zyga-x240: yup
 * ijohnson or maybe here for first time today
<zyga-x240> ijohnson: +1 on the error checking for user lookup PR
<ijohnson> thanks
<zyga-x240> I had a look through go and meh
<mborzecki> ijohnson: o hi, fun stuff with user lookup :/
<zyga-x240> too much inconsistency
<ijohnson> yeah it's a bit disappointing, but then again the man page for getgrpnam_r does kinda say it's impossible anyways
<ijohnson> mborzecki: oh? what more fun stuff ?
<zyga-x240> ijohnson: but I would expect _some_ level of consistency
<zyga-x240> between the various backends
<zyga-x240> but no, that's not the case
<ijohnson> yeah
<pedronis> zyga-x240: regarding your errno question, go in general seems to do it's own syscall handling, about cgo afaict it works as expected because th c code gets its own tls stuff, but this is as usual slightly hard to follow in the go code
<zyga-x240> pedronis: right, I was only curious because some calls do not reset errno
<zyga-x240> and I was wondering if cgo explicitly sets errno = 0 ahead of all calls
<zyga-x240> the real bug is in the higher layer in go
 * zyga-x240 starts a test and takes that break 
<pedronis> zyga-x240: anyway cgo itself seems to emit "errno = 0" in some cases
<pedronis> zyga-x240: see cmd/cgo/out.go in go itself
 * zyga-x240 looks
<mborzecki> ijohnson: while you're around, can you take a look at https://github.com/snapcore/snapd/pull/9030 ? :)
<mup> PR #9030: bootloader/assets: helpers for registering per-edition snippets, register snippets for grub <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9030>
<zyga-x240> mborzecki: tests are failing on ...
<zyga-x240>  2020-07-22T12:22:24.0548501Z        /tmp/sanity-squashfs-830795014: no space left on device
<zyga-x240> 2020-07-22T12:22:24.0542897Z ##[error]2020-07-22 12:22:24 Error executing google:ubuntu-19.10-64:tests/main/install-store-laaaarge (jul221201-927192) :
<mborzecki> pfffff
<ijohnson> mborzecki: ah so sorry yes I will submit it now, I wrote all the comments and it seems I forgot to submit it :-)
<zyga-x240> another failed on EOF from reboot
<zyga-x240> 2020-07-22T12:42:59.1435778Z ##[error]2020-07-22 12:42:59 Error executing google:ubuntu-core-16-64:tests/core/reboot (jul221201-861200) : kill-timeout reached after jul221201-861200 (google:ubuntu-core-16-64:tests/core/reboot) reboot request
<mborzecki> heh, gdoc does not like firefox
<zyga-x240> one failed on preparing due to purge
<mborzecki> zyga-x240: lxd?
<zyga-x240> no, just prepare up front
<ijohnson> mborzecki: submitted
<zyga-x240> one more is in progress
<mborzecki> zyga-x240: 8883 is still waiting
<mborzecki> ijohnson: thanks
<zyga-x240> I'd restart the three to see if they can land cleanly
<zyga-x240> but I'd be fine with override as well
<ijohnson> mborzecki: but did you see my question in IRC earlier? was there something else to know about the user stuff ?
<mborzecki> ijohnson: probably missed it, what was the question?
<ijohnson> mborzecki: oh you just said there was more fun, and I wasn't sure if you were just referring to the situation in general or something else that you found after looking at the PR
<zyga-x240> mborzecki: 640GB should be enough for a google doc
<mborzecki> ijohnson: ah, nah just the general state of things around that area
<ijohnson> yeah rather sad
<ijohnson> but good that we debugged it in MM some more and it sounds like CPC has a way forward in the meantime while waiting for the fix
<mborzecki> zyga-x240: that failure in prepare is 8883
<pedronis> ijohnson: standup?
<ijohnson> yes
<ijohnson> cachio: SU?
<mborzecki> zyga-x240: restarted the spread job in https://github.com/snapcore/snapd/pull/9044
<mup> PR #9044: many: cherry-picks for 2.45, gh-action, test fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9044>
<zyga-x240> ok
<zyga-x240> ahh
<zyga-x240> there's one thing I didn't do that jamie surely did
<zyga-x240> run this as user!
<mborzecki> zyga-x240: the caching behavior in #9044 is such a nice improvement now that i restarted the ci job
<mup> PR #9044: many: cherry-picks for 2.45, gh-action, test fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9044>
<zyga-x240> :D
<zyga-x240> why do we even bother with hangouts on non-mobile devices, mobile experience is just so much better
<pedronis> zyga-x240: mborzecki: we can close 9045 and 9046 right?
<zyga-x240> checking
<zyga-x240> yes
<zyga-x240> they are now in the big PR
<ijohnson> pedronis: ok, so looking again the ones that are blocking things are these PR's: 8890, 8612, 8854, 8652, and 8795
<mborzecki> pedronis: zyga-x240: closed them now
<ijohnson> pedronis: the only ones that are not strictly snap-bootstrap related are the _writable-defaults thing, and a cloud-init related thing that needs to land with the _writable_defaults, otherwise the _writable-defaults PR as-is will undo the cloud-init fix
<ijohnson> pedronis: if you like I can prepare a backport PR with all of those after 9044 lands cleanly
<mup> PR snapd#9045 closed: Disable part of the nfs-support test that checks udp proto on debian-â¦ <Created by zyga> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/9045>
<mup> PR snapd#9046 closed: tests: backport preseed test fixes to 2.45 <Created by zyga> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/9046>
<mborzecki> pedronis: ijohnson: for preseeding we may want https://github.com/snapcore/snapd/pull/9015 and https://github.com/snapcore/snapd/pull/9018 in .45 right?
<mup> PR #9015: cmd/snap-preseed: handle relative chroot path <Bug> <Preseeding ð> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9015>
<mup> PR #9018: cmd/snap-preseed: check that target path exists and is a directory on --reset <Preseeding ð> <Simple ð> <Created by stolowski> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9018>
<ijohnson> mborzecki: yes to 8015, 9018 is nice to have but not necessary, it is just better error handling
<mborzecki> ack
<zyga-x240> break
<mborzecki> pedronis: zyga-x240: so 9044 is looking good, the failure on 19.10 is probably related to user session fixes in tests that are done in master, but were not cherry-picked
 * pedronis in meeting
<zyga-x240> mborzecki: looking
<zyga-x240> hmm
<zyga-x240> 2020-07-22T13:47:54.7315113Z Failed to connect to bus: Connection refused
<zyga-x240> yeah I think that's ok to merge
<zyga-x240> +1 and let's rebase the rest
<mborzecki> yup, doing so now
<zyga-x240> ok
<mup> PR snapd#9044 closed: many: cherry-picks for 2.45, gh-action, test fixes <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9044>
<mborzecki> zyga-x240: rebased https://github.com/snapcore/snapd/pull/9042 please take a look
<mup> PR #9042: interfaces: optimize rules of multiple connected iio/i2c/spi plugs (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9042>
<mup> PR snapd#9047 opened: cmd/snap-preseed: backport fixes (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9047>
<mborzecki> ijohnson: can you take a look ^^ ?
<ijohnson> mborzecki: sure
<mborzecki> ijohnson: thanks
<ijohnson> I updated the getgrnam_r PR, but some of the code I changed has to do with sudo, so I would like some extra eyes on it
<ijohnson> cachio: so regarding #9027, I think it is actually pretty unfortunate but I don't think we have another option right now, because there doesn't seem to be a way for us to identify the case where we have a real bug in snapd vs this bug in qemu where the system gets rebooted randomly in the middle of the test
<mup> PR #9027: tests: refresh/revert snapd in uc20 <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9027>
<ijohnson> cachio: I think we need to just merge it with the changes you have and expect that the test is very flaky / fail often due to this qemu bug
<cachio> ijohnson,
<cachio> ok
<cachio> I'll try a new change with the gce platform to see if it improves
<mborzecki> ok, the ci jobs are running, seems like the most problematic bits of 2.45.3 are done, need to run some errands now, but i'll check in on the PRs later
<ijohnson> thanks mborzecki !
<zyga-x240> ijohnson: https://github.com/snapcore/snapd/pull/9041#pullrequestreview-453438323
<mup> PR #9041: osutil/group.go: treat all non-nil errs from user.Lookup{Group,} as Unknown* <Bug> <Needs security review> <Preseeding ð> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9041>
<ijohnson> thanks zyga-x240
 * cachio lunch
<pedronis> ijohnson: I need a break and then I'll try to go over that least of UC20 PRs
<ijohnson> pedronis: k, sounds good
<mup> PR snapd#8980 closed: tests: backport preseed test fixes to 2.45 <Test Robustness> <Created by stolowski> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8980>
<pedronis> mmh, I forgot about that one, that's bit the issue with long lived PRs
<ijohnson> which one ?
<pedronis> the backport pawel did
<pedronis> already
<pedronis> 8980
<ijohnson> ah yes
<ijohnson> well for that one I think pawel made changes there that weren't on master so it would have been a bit tricky to merge the release branch back to master when time came to actually finalize the release
<mup> PR snapd#9048 opened: .github/workflows/snap-build.yaml: build the snapd snap via GH Actions too <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9048>
 * ijohnson may have opened a new PR, but also closed an old one, so net PR count change is 0
 * ijohnson goes back to actual productive things
<mup> PR snapd#8143 closed: github: add github workflow <â Blocked> <Created by sd-hd> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8143>
<pedronis> ijohnson: that list of UC20-related PRs seems fine, the questions I suppose is whether they backport cleanly?
<ijohnson> pedronis: not sure, but I can check
<ijohnson> pedronis: if they backport cleanly shall I open a PR with them included ?
 * ijohnson is about to break for lunch
<pedronis> ijohnson: yes, but needs to be on top of the two things we want to land
<pedronis> ijohnson: so maybe wait a bit?
<ijohnson> pedronis: which ones, mborzecki already landed one of them I think
<pedronis> #9042 and #9047 ?
<mup> PR #9042: interfaces: optimize rules of multiple connected iio/i2c/spi plugs (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9042>
<mup> PR #9047: cmd/snap-preseed: backport fixes (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9047>
<ijohnson> ah ok
<pedronis> unless I'm confused, which can be, I'm slightly exhausted atm
<ijohnson> pedronis: it's okay I know what to do, I can land these PR's in my PM if they are green, I will do a double-check on 9042, but the other one is aleady approved
<zyga> re
<zyga> back after painkillers
<zyga> sorry the overlap hours are not great
<zyga> ijohnson|lunch: https://github.com/snapcore/snapd/pull/9048#pullrequestreview-453515399
<mup> PR #9048: .github/workflows/snap-build.yaml: build the snapd snap via GH Actions too <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9048>
<ijohnson|lunch> zyga, we may be able to leverage that in the builds themselves, I haven't looked into it too much I really just copied what joedborg did for the microk8s snap GitHub actions :-P
<cmatsuoka> build queue blocked again?
<zyga> look at the time 16 minutes!
<zyga> that's 16 less in each of the re-execing systems
<zyga> cmatsuoka: let me check
<zyga> not stuck - processing loads of jobs
<cmatsuoka> ah ok, thanks
<zyga> many are close to 40 minute CPU time
<zyga> this is usually when they end
<zyga> btw, if anyone has decent home network
<zyga> and a spare laptop
<zyga> I we can grow the pool
<zyga> anyway
<cmatsuoka> what kind of access is needed? I have a machine here but it's only accessible via ipv6
<zyga> only private IPv4 address
<zyga> a machine behind lan is ok
<zyga> it reaches out to github
<zyga> I don't think ipv6 is supported in practice
<cmatsuoka> I have ipv4 but it's behind a nat, if that's ok I can set up a couple of nodes here to see what happens
<cmatsuoka> just send me the directions
<zyga> sure
<zyga> let me find the repo
<zyga> hmmm, where is it?
<zyga> actually
<zyga> cmatsuoka: do you know things like ansible or other "magic" frameworks for deployment>
<zyga> my instructions work but are really manual
<cmatsuoka> zyga: I know that they exist, but never used them
<cmatsuoka> manual is good, we learn a lot doing things by hand
<cmatsuoka> as long as I don't have to do it multiple times
<zyga> cmatsuoka: let's do this some other time - the real version that would allow snapd to benefit requires admin access to the repo
<zyga> cmatsuoka: I can recommend two things
<zyga> cmatsuoka: I'll share the doc I wrote
<zyga> and the scripts
<zyga> and I'd recommend deploying that for a personal repo
<cmatsuoka> ok
<zyga> you will learn the process
<zyga> and improve it as well
<cmatsuoka> sounds good
<zyga> cmatsuoka: my recommendation is to do this on a focal system with focal containers
<zyga> drat, I'm terrible at google docs
<zyga> I know for a fact there's a gdoc
<zyga> let me try on my phone
<zyga> google is the worst UX company on this planet
<zyga> borland docs would be better
<cmatsuoka> finding stuff in gdocs is hard, these guys should learn something about searching
<cmatsuoka> oh wait
<zyga> haha
<zyga> right?
<zyga> installing the app
 * zyga searches gmail
<zyga> I'm lost
<zyga> sorry, I wonder where that is
<cmatsuoka> someday you'll find it, and then you tell me
 * pedronis admits to have made a gdoc with links to other gdocs
<mup> PR snapd#9024 closed: sysconfig/cloudinit: add RestrictCloudInit <Created by mvo5> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9024>
 * cachio kinesiologist
<ijohnson> zyga: https://github.com/snapcore/snapd/pull/9048#issuecomment-662625884
<mup> PR #9048: .github/workflows/snap-build.yaml: build the snapd snap via GH Actions too <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9048>
<zyga> jdstrand: I found one more bug in my implementation of the reproducer of the bug you found
<zyga> jdstrand: testing it now, fingers crossed that it finally shows something
<zyga> testing that now
<ijohnson> uggh why do we have to have infinite amounts of conflicts in cmd_initramfs_mounts.go
 * ijohnson cries a little a lot on the inside
 * zyga hugs ijohnson virtually
<ijohnson> haha
<zyga> I had to deconflict some of those snapstate.go things
<zyga> I learned how to tell my editor "yeah, you can use this much memory"
<ijohnson> haha so true
<ijohnson> before pstolowski split up that snapstate_test.go file, a conflict there was sure to crash my editor
<zyga> jdstrand: no luck, I wrote a much more elaborate test that really mimics what you experienced except there's no failure yet :|
<jdstrand> weird. I took my system out of it and did it in a vm in the bug...
<zyga> I will try with your snap verbatim
<zyga> I must have missed something
<zyga> I pushed the updated (non failing) test to fix/lp-1888305
<zyga> https://github.com/zyga/snapd/commit/db5c7c98b666ad3022d67a771706d11291f24da8
<zyga> if you could eyeball that and spot any obviously wrong things I'd love to know
<zyga> otherwise I will run with your snap in a VM tomorrow
<mup> PR snapd#9049 opened: release/2.45: backport of uc20 PR's <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9049>
<jdstrand> zyga: I think those experimental feature can be removed. I didn't carry those into the vm
<zyga> OK
<zyga> I will do one more round with a long running process
<jdstrand> zyga: something that I don't see in this (maybe I missed it?) is that I have a long running process
<zyga> right
<zyga> I didn't do that because it should not be a factor
<jdstrand> zyga: specifically, I have an app indicator that is long running
<jdstrand> hmm
<zyga> I though that it is caused by skew in snapd tools as snapd revisions change
<jdstrand> zyga: are you sure? if there is a process running, isn't there different behavior for mount namespace updates?
<zyga> no because snapd does not trigger mount namespace updates in our model
<jdstrand> zyga: note that I could always resolve the issue by stopping and starting the indicator
<zyga> that made me add the "observe" mode
<zyga> as I realized that may matter
<zyga> started one more round with the process running
<zyga> that is interesting bit of information as well actually
<zyga> it suggests that indeed the namespace "turns stale" somehow
<zyga> and that starting a process is enough to fix it
<zyga> but that's unusual as we must have done something to choose to update the namespace
<zyga> and snapd, again, is not a factor
<zyga> unless mount profiles changed somehow?
<zyga> jdstrand: no change with running process
<pedronis> ijohnson: I landed 9025, I suppose #9026 need a master merged now
<mup> PR #9026: tests/nested/manual: add spread tests for cloud-init vuln <Run nested> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9026>
<mup> PR snapd#9025 closed: overlord,o/devicestate: restrict cloud-init on Ubuntu Core <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9025>
<ijohnson> pedronis thanks yes I think so
 * zyga EODs
<zyga> o/
<mup> PR snapd#9040 closed: spread: add opensuse 15.2 and tumbleweed for qemu <Simple ð> <Created by jdstrand> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9040>
#snappy 2020-07-23
<mup> Bug #1888600 opened: snap run should autocomplete <Snappy:New> <https://launchpad.net/bugs/1888600>
<mborzecki> morning
<mup> PR snapd#9042 closed: interfaces: optimize rules of multiple connected iio/i2c/spi plugs (2.45) <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9042>
<mborzecki> so weird, some ci jobs appear stuck for no clear reason, and restarting the workflow makes those previously stuck jobs run immediately
<mup> PR snapd#9050 opened: Avoid exit when nested type var is not defined  (2.45) <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9050>
<mup> PR snapd#9047 closed: cmd/snap-preseed: backport fixes (2.45) <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9047>
<jamesh> yeah.  I had the ubuntu-nested-* jobs all waiting to start for a run I set going last night.
<mborzecki> jamesh: which PR? can you restart the workflow (instead of closing and reopening the PR)?
<jamesh> mborzecki: I restarted it, and the missing jobs ran
<jamesh> mborzecki: it was this one: https://github.com/snapcore/snapd/pull/8861
<mup> PR #8861: data,packaging,wrappers: extend D-Bus service activation search path <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8861>
<mborzecki> jamesh: cool
<mborzecki> jamesh: it's funny cause you can restart the workflow if it's seemingly stuck and it runs
<jamesh> I'd like to merge it, but the ubuntu-20.10 job is failing on the preseed and pulseaudio tests.
<jamesh> mborzecki: maybe the communication link with the self hosted runners got confused?
<mborzecki> jamesh: that's fine, preseed is known (the groovy images are preseeded now and that confuses the test)
 * jamesh hits merge then.
<mup> PR snapd#8861 closed: data,packaging,wrappers: extend D-Bus service activation search path <Created by jhenstridge> <Merged by jhenstridge> <https://github.com/snapcore/snapd/pull/8861>
<mborzecki> jamesh: pulseaudio is a known thing to, i'll do some digging today but if i fail to uncover anything useful we may need to poke someone frm the desktop team
<jamesh> mborzecki: I'm looking into this bug report from my end: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1886854 -- it doesn't obviously tie in with the spread failure though.
<mup> Bug #1886854: Race in load-module snap policy check in classic confinement <focal> <rls-ff-incoming> <pulseaudio (Ubuntu):New for jamesh> <https://launchpad.net/bugs/1886854>
<mborzecki> jamesh: interesting, i'll try to debug the test today, i'll let you know if it's related (though i suspect it's rather something about our user session setup)
<mup> PR snapd#9030 closed: bootloader/assets: helpers for registering per-edition snippets, register snippets for grub <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9030>
<mup> PR snapd#9026 closed: tests/nested/manual: add spread tests for cloud-init vuln <Run nested> <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9026>
<mborzecki> pedronis: hey, i've opened one more cherry-pick for 2.45 https://github.com/snapcore/snapd/pull/9050
<mup> PR #9050: tests: avoid exit when nested type var is not defined  (2.45) <Run nested> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9050>
<pedronis> mborzecki: I saw it, trying to run it with nested tests on
<pedronis> mborzecki: I merged master into #9013 which is now small, it needs a re-review
<mup> PR #9013: many: merge 2.45.2 fixes back into master <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9013>
<mborzecki> pedronis: ok, will do
<pedronis> thx
<zyga> o/
<zyga> 2AM schedule is not fun
<mup> PR snapd#8973 closed: tests: moving journalctl.sh to a new journal-state tool <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8973>
<mborzecki> pedronis: i've updated #9006
<mup> PR #9006: bootloader: compose command line with mode and extra arguments <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9006>
<pedronis> mborzecki: can we do the "go generate" thing?  looking at scripts changes in the middle of go changes is not great
<mup> PR snapd#9050 closed: tests: avoid exit when nested type var is not defined  (2.45) <Run nested> <Simple ð> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9050>
<zyga> brb coffee
<mborzecki> pedronis: i'll drop that commit bumping the edition and force push
<mborzecki> jamesh: https://paste.ubuntu.com/p/NRkvhFfVQZ/ hm interestingly haven't seen it before
 * jamesh looks
<jamesh> mborzecki: That is from today's landing.  I wonder why it didn't show up before?
<jamesh> mborzecki: I don't think we patched core to make /etc/dbus-1/session.d writable because I thought the core18 code didn't run there
<pedronis> jamesh: no, but we have some tests that try the core -> snapd/core18 transition
<pedronis> and that code will get involved
<jamesh> pedronis: right.  I'm wondering why it didn't show up in spread test runs for my PR
<jamesh> I realise we probably need to add the extra writable path
<mborzecki> jamesh: that would be core16, so /etc/dbus-1/ is not writable
<mborzecki> duh, dbus-1/session.d
<mborzecki> (dbus-1/systemd.d is)
<pedronis> anyway we need either a quick fix or to revert something temporarly
<pedronis> I fear
<jamesh> It is a one line change to the core snap build script.  Could that be landed fast enough?
<jamesh> pedronis: here is a PR if that is acceptable: https://github.com/snapcore/core/pull/114
<mup> PR core#114: writable-paths: make /etc/dbus-1/session.d writable <Created by jhenstridge> <https://github.com/snapcore/core/pull/114>
<zyga> I wonder if this will affect any tests back in snapd
<zyga> oh well
<zyga> I'm okay with the ping pong if that's what it takes
<jamesh> I'm still not sure why the test didn't fail in my own PR
<mup> PR core#114 opened: writable-paths: make /etc/dbus-1/session.d writable <Created by jhenstridge> <https://github.com/snapcore/core/pull/114>
<mborzecki> maybe the restore of tests doing remodel 16 -> 18 is not cleaning up all of the state properly?
<mup> PR snapd#9051 opened: tests/main/interfaces-pulseaudio: enable debug logging in pulseaudio <Precious Logs> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9051>
<zyga> mborzecki: possibly
<zyga> mborzecki: could we write an invariant check somehow?
<zyga> brb
<pedronis> jamesh: the change in itself seems fine
<zyga> I've updated https://github.com/snapcore/snapd/pull/8977
<mup> PR #8977: cmd/snap: track started apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/8977>
<pedronis> zyga: I have put it back into my queue
<zyga> thanks!
<ijohnson> morning folks
<zyga> ijohnson: hey :)
<zyga> brb
<ijohnson> hey zyga feeling better today ?
<ijohnson> also the github actions stuff is really exciting, I didn't realize globs work, and there's even a download artifact action too
<ijohnson> still a bit unclear how we feed things from the github actions into spread, but I don't have time to work on that anyways
<zyga> ijohnson: yeah
<zyga> ijohnson: the tests today don't require any special precautions so I'm my normal dose of painkillers
<zyga> ijohnson: but the surgery is so close I cannot wait!
<ijohnson> that's good to hear
<zyga> ijohnson: I may be able to stand at the tgif next week :)
<ijohnson> nice!
<zyga> I won't be able to sit for a while but that's really minor
<ijohnson> but certainly take it as slow as you need to
<zyga> after all the stuff heals it will be amazing
<zyga> ijohnson: as for actions, yeah they come in pairs
<zyga> ijohnson: we could even build snapd on a dedicated fast machine, with deps, with preserved go cache
<zyga> ijohnson: and just upload the artefacts for spread cloud
<zyga> ijohnson: so many options
<zyga> actions have great design
<ijohnson> my initial poc idea for how to feed that into spread would be to download the actions into the repo filesystem, so that when we build the tarball of the repo to send to the workers, they already have all the artifacts in them
<zyga> they are different from random CI solutions but the benefits are really nicw
<zyga> yeah
<zyga> exactly
<ijohnson> that would have increased network costs though
<zyga> you need the token to fetch that
<ijohnson> right so that avoids the token problem
<zyga> so it must be done by the action runner we host
<zyga> well, 16MB is not much
<zyga> those machines stream a *LOT* of uncompressed traffic
<ijohnson> well but if we really wanted to save time, we'd build the rpm, debs, etc.
<zyga> 16MB is like a drop in an ocean
<zyga> yeah, we could build remaining packages
<zyga> we could even build deb and use that to build the snap
<zyga> I think that's the way forward
<ijohnson> right, cause actually the snapd snap isn't really used anywhere in the tests right now
<zyga> and I think this will cut build time by about 20 minutes
<ijohnson> in fact the places we need to use the snapd snap for UC18 and UC20, we just stuff the snapd deb into the snapd snap :-)
<zyga> haha, right!
<zyga> so I think there are options to explore
<ijohnson> oh also I was going to ask you, for hosting a runner, what kind of network usage do you see ?
<zyga> but even having a .deb and a .rpm and a .snap on a PR is great
<zyga> it's easy to pick up and explore
<zyga> ijohnson: let me pull the stats
<zyga> network is pretty heavy
<zyga> constant ram + spiky ram and CPU on startup (a lot actually) and then loads of network
<zyga> go ssh does't implement any compression
<zyga> so we pay a lot for traffic that's silly
<zyga> it's easily in the megabit a sec for worker range
<ijohnson> I have some machines I could dedicate to runners, but I'm concerned about network performance, my network is fast, but it goes down quickly when there are lots of outgoing network connections, like my ISP seems to think that I am DDOS'ing the world when I try to run a full spread suite and my network entirely disappears
<ijohnson> but as soon as I kill that spread run, network comes right back
<zyga> I think running a few is probably okay
<zyga> but it adds up
<zyga> I used my TB quota that month when I hosted 32 workers at home
<zyga> (but it overflowed my other house usage, not a TB by itself)
<zyga> I think one major improvement would be to implement ssh compression
<zyga> but there's a bug for that for a few years
<zyga> and nobody touched that
<zyga> we send lots of text back and forth
<zyga> and that adds up
<zyga> https://github.com/golang/go/issues/31369
<zyga> ijohnson: another possibility might be to shell-out to real ssh
<zyga> ah, drat, I don't have the other laptop
<zyga> I'll ask my wife to bring it later if that's okay
<ijohnson> mmm
<zyga> I can then give you precise network usage figures
<ijohnson> sure no rush, just curious
<zyga> ha
<zyga> I was about to ask if we should merge that
<zyga> :D
<zyga> pedronis: can we trigger a core build faster?
<mup> PR core#114 closed: writable-paths: make /etc/dbus-1/session.d writable <Created by jhenstridge> <Merged by pedronis> <https://github.com/snapcore/core/pull/114>
<pedronis> zyga: maybe, but first the code needs to get to LP
<zyga> ah, via imporyt
<pedronis> zyga: yes
<zyga-x240> lost network, trying to rejoin
<mborzecki> trying to run pulseaudio tests with a fix now
<pedronis> https://github.com/snapcore/snapd/blob/master/cmd/snap-bootstrap/cmd_initramfs_mounts.go#L314
<mup> PR core18#164 opened: Core18 next <Created by xnox> <https://github.com/snapcore/core18/pull/164>
<mup> PR core18#165 opened: Cleanup /run in the core <Created by xnox> <https://github.com/snapcore/core18/pull/165>
<mborzecki> pushed a tweak to https://github.com/snapcore/snapd/pull/9051 let's see if the pulseaudio tests are happy this time
<mup> PR #9051: tests/main/interfaces-pulseaudio: enable debug logging in pulseaudio <Precious Logs> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9051>
<mup> PR snapd#9048 closed: .github/workflows/snap-build.yaml: build the snapd snap via GH Actions too <Simple ð> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9048>
<ijohnson> mborzecki: I just noticed a pulseaudio and audio-playback failure on focal, have you seen that before ?
<ijohnson> mborzecki: logs are here https://pastebin.ubuntu.com/p/zxTZtQnVmf/
<mborzecki> ijohnson: hm looks similar
<ijohnson> pedronis: btw looks like #9013 is ready
<mup> PR #9013: many: merge 2.45.2 fixes back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/9013>
<ijohnson> (but needs sudo git merge perms)
<mborzecki> ijohnson: do you have a debian-10 vm?
<ijohnson> mborzecki: not handy no
<ijohnson> mborzecki: I think jdstrand has some instructions on his blog on how to easily get a cloud image VM
<mborzecki> hm seems like the preset on sid is enabled for both snapd.socket and .service
<mborzecki> so i'm not sure how op in https://forum.snapcraft.io/t/snapd-not-start-automatic/19039/ got both in 'disabled'
<mup> PR snapd#9052 opened: release/2.45: backport writable_defaults dir changes <Run nested> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9052>
<mborzecki> anyways, time to start packing for a drive back home
<jdstrand> I do! https://blog.strandboge.com/2019/04/16/cloud-images-qemu-cloud-init-and-snapd-spread-tests/
<ijohnson> ah 3 seconds too late!
<jdstrand> ah bummer :)
 * jdstrand hopes that page is useful to others. I certainly have found it handy
<ijohnson> pedronis: I opened https://github.com/snapcore/snapd/pull/9049 with the manually ported patch from master for that bit we talked about
<mup> PR #9049: release/2.45: backport of uc20 PR's <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9049>
<ijohnson> oh whoops wrong PR number
<ijohnson> #9052 is the right PR
<mup> PR #9052: release/2.45: backport writable_defaults dir changes <Run nested> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9052>
<pedronis> thx
<mup> PR core20#76 closed: hooks/001-extra-packages.chroot: add gdbserver <Created by anonymouse64> <Merged by xnox> <https://github.com/snapcore/core20/pull/76>
<mup> PR core20#77 opened: Drop console-conf hack, fixed in subiquity. core18 pr#148 <Created by xnox> <https://github.com/snapcore/core20/pull/77>
<mup> PR snapd#9013 closed: many: merge 2.45.2 fixes back into master <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9013>
<pedronis> ijohnson: I merged that ^ and reviewed #9049
<mup> PR #9049: release/2.45: backport of uc20 PR's <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9049>
<ijohnson> thanks pedronis, looking now
<mup> PR snapcraft#3225 opened: specifications: default tracks <specification> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3225>
<mup> PR snapd#9053 opened: many/tests/preseed: reset the preseeded images before preseeding them <Bug> <Preseeding ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9053>
<mup> PR snapd#9029 closed: api: seeding debug api (2/N) <Needs Samuele review> <Preseeding ð> <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9029>
<mup> PR snapcraft#3226 opened: extensions: kde-neon: use gtk3 platform theme on gtk-based DE's <Created by galgalesh> <https://github.com/snapcore/snapcraft/pull/3226>
#snappy 2020-07-24
<mborzecki> morning
<mborzecki> heh, go templates are quite annoying
<mborzecki> pedronis: https://github.com/snapcore/snapd/pull/9054
<mup> PR #9054: bootloader/assets: generate bootloader assets from files <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9054>
<mup> PR snapd#9054 opened: bootloader/assets: generate bootloader assets from files <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9054>
<pedronis> thx
<mborzecki> quick errand, back in 30
<zyga> o/
<zyga> back now
<zyga> all tests done
<zyga> just surgery left
<zyga> how are things?
<pedronis> zyga: hi, we have some PR to fix some spread test issues, but otoh stuck/queued tests are definitely a frequent thing: https://github.com/snapcore/snapd/pull/9052 for example, it was already closed/reopened once
<mup> PR #9052: release/2.45: backport _writable_defaults dir changes <Run nested> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9052>
<zyga> hmm, I wonder if the fact that our workers are on older release is a factor
<zyga> perhaps I should switch all workers to the current release
<zyga> and see if that makes it better
<zyga> pedronis: do you know if all kinds of tests were uniformly stuck or were spread jobs more likely to be stuck?
<zyga> github-hosted workers are updated automatically
<zyga> I wonder if there's any indication that version skew is a factor
<mborzecki> re
<mborzecki> zyga: can you take a look at https://github.com/snapcore/snapd/pull/9051 ?
<mup> PR #9051: tests/main/interfaces-pulseaudio: enable debug logging in pulseaudio <Squash-merge> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9051>
<zyga> syre
<zyga> sure
<mborzecki> omg, debian packageing is calling go generate
<zyga> what is - in <<-EOF?
<mborzecki> discards leading space
<zyga> oh neat
<zyga> cool
<zyga> thank you for using tests.cleanup!
<zyga> +1
<zyga> mborzecki: should I restart tests there?
<mborzecki> zyga: restarted just now
<zyga> ok
<zyga> I'll fire up more workers, just let me automate the upgrade process
<zyga> ok, we should have 32 more workers now, running the latest version
<mborzecki> when we're building snapd deb, any clue how _build directory comes to life?
<mborzecki> it gets populated with go files, but clearly the data files are not copied, so go generate files
<zyga> it's a part of debhelper IIRC
<zyga> it constructs a gopath
<zyga> it only considers .go files
<zyga> similar issues are present in fedora and suse helper stacks
<pedronis> mborzecki: we do copy some things by hand already though
<pedronis> cp -a cmd/snap/test-data/*.gpg _build/src/$(DH_GOPKG)/cmd/snap/test-data/ for example
<mborzecki> pedronis: yeah, added a line there now
<mborzecki> pedronis: can you use your superpowers and merge https://github.com/snapcore/snapd/pull/9051 ? the failure in uc20 prepare is a known problem
<mup> PR #9051: tests/main/interfaces-pulseaudio: enable debug logging in pulseaudio <Squash-merge> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9051>
<mborzecki> feels wasteful to do another spread run hoping it succeeds this time
<pedronis> mborzecki: I'll look in a little bit
<mborzecki> pedronis: thanks
<zyga> mborzecki: systemd can now support v2 freezer
<zyga> and load apparmor policy
<zyga> on early boot
<zyga> wow
<zyga> systemd can also verify veriety hashes for filesystem images
<zyga> lots of very interesting things there
<pedronis> mborzecki: merging, do you know though why that failure log is unreadable? where is the journal printing done? is the debug stuff or some toher code
<mborzecki> pedronis: the failure log when prepare on a 20.04 host fails?
<pedronis> yes
<mborzecki> pedronis: it's all the debugging i and mvo added, https://github.com/snapcore/snapd/pull/8883 should fix the problem so we'll not need the debug output anymore
<mup> PR #8883: packaging: stop snapd early on purge <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8883>
<pedronis> mborzecki: to be clear if we need to keep we need to do something about it, because it doesn't make sense to a casual reader
<mborzecki> pedronis: i've pinged zyga for a review in 8883, maybe you could add it to your queue as well?
<mborzecki> there were some concerns where to call the helpers in postrm
<zyga> I'll look in 10 minutes
<mborzecki> s/helpers/DEBHELPER snippets/
<pedronis> mborzecki: I merged 9051, changed a bit description giving it has a fix, not just more logging now
<mborzecki> pedronis: cool, thanks
<mborzecki> i've updated https://github.com/snapcore/snapd/pull/9053 hopefully groovy spread jobs will be green now
<mup> PR #9053: many/tests/preseed: reset the preseeded images before preseeding them <Bug> <Preseeding ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9053>
<mup> PR snapd#9051 closed: tests/main/interfaces-pulseaudio: disable start limit checking for pulseaudio service / enable debug logging <Squash-merge> <Test Robustness> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9051>
<pedronis> mborzecki: oops, I missed the squash-merge label on it :/
<mborzecki> fairly self contained, should be a problem picking all 4 when we need to
<mborzecki> all 4 commits from that pr i mean
<mup> PR # closed: core18#148, core18#156, core18#163, core18#164, core18#165
 * zyga lunch and back to reviews
<pedronis> mborzecki: I review #8982 btw, you were asking about the other day
<mup> PR #8982: snapshots: export of snapshots <Needs Samuele review> <Created by slimjim777> <https://github.com/snapcore/snapd/pull/8982>
<pedronis> *reviewed
<mborzecki> pedronis: thanks, there's a sibling PR https://github.com/snapcore/snapd/pull/9036 which could use your review too
<mup> PR #9036: snapshots: import of a snapshot set <Created by slimjim777> <https://github.com/snapcore/snapd/pull/9036>
<pedronis> mborzecki: I know, not today
<zyga> re
<pedronis> mborzecki: #9054 looks good to me with small naming nitpick
<mup> PR #9054: bootloader/assets: generate bootloader assets from files <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9054>
<pedronis> it needs a 2nd review
<mborzecki> pedronis: thanks
<mup> PR snapd#9055 opened: tests: fix incorrect check in smoke/remove test <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9055>
<mborzecki> cmatsuoka: can you take a look at  https://github.com/snapcore/snapd/pull/9054 later on?
<mup> PR #9054: bootloader/assets: generate bootloader assets from files <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9054>
<cmatsuoka> mborzecki: sure
<mborzecki> cmatsuoka: thx
<zyga> afk for 15 min then back to reviews starting with maciek's fix for purge
<mborzecki> need to go and pick up some stuff fromt he hardware store, bbl
<mup> PR snapd#9049 closed: cmd/snap-bootstrap,seed: backport of uc20 PR's (2.45) <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9049>
<ogra_> now this is a curious suggestion ...
<ogra_> Log: apparmor="DENIED" operation="chmod" profile="snap.acsccid.pcscd" name="/var/snap/acsccid/common/" pid=26404 comm="pcscd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
<ogra_> File: /var/snap/acsccid/common/ (write)
<ogra_> Suggestion:
<ogra_> * adjust program to write to $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON
<ogra_> (and despite the denial the app actually creates its socket in SNAP_COMMON as required)
<jdstrand> ogra_: the idea is that is a difference to writing in SNAP_COMMON and writing SNAP_COMMON
<jdstrand> ogra_: I'll adjust the suggestion to make that clearer
<ogra_> oh, i'll make sure it writes to a subdir then ...
<zyga> re
<ogra_> jdstrand, the worse pare with this snap is this though:
<ogra_> Log: apparmor="DENIED" operation="open" profile="snap.acsccid.pcscd" name="/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2/2-2/idVendor" pid=26404 comm="pcscd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<ogra_> File: /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2/2-2/idVendor (read)
<jdstrand> hardware-observe should cover that
<ogra_> jdstrand, raw-usb is connected (this is on a Pi4 which has the USB ubs attached via PCI)
<ogra_> ah
<ogra_> let me try
<jdstrand> let me check raw-usb
<zyga> uh, that hurt
<ogra_> and i have another one ...
<ogra_> Log: apparmor="DENIED" operation="open" profile="snap.acsccid.set-power" name="/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/power/control" pid=26098 comm="set-power" requested_mask="wc" denied_mask="wc" fsuid=0 ouid=0
<ogra_> File: /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/power/control (write)
<ogra_> also with raw-usb connected
<jdstrand> yeah, the raw-usb interface should cover that, but doesn't: soc vs scb
<ogra_> yep, thats what i thought
<ogra_> i bet it would work on a regular pi or x86
<jdstrand> ogra_: the first was read, that is hardware-observe, but the second is write, which should be raw-usb. I've added this to the next batch of updates
<jdstrand> ogra_: what device is that? (for the git commit)
<ogra_> jdstrand, Pi4 trying to use an NFC reader (i'm actually trying to assemble a pcscd snap to provide a content interface for others snaps to use later ... thats longstanding missing)
<jdstrand> ogra_: ok, thanks :)
<ogra_> jdstrand, one issue i cant reall solve is that most of these usb readers actually require you to blacklist the pn533_usb module ... not sure what to do with that (i can modprobe -r when using kernel-module-control indeed)
<jdstrand> ogra_: if you get the pcscd to a point that you'd like to share, I can (finally) do the pcscd interface and we can iterate on it in the PR together
<ogra_> this is super ugly ... it seems the kernel added a module that most of the readers can not actually use ... they all come with userspace drivers instead ... and indeed that clashes
<jdstrand> ogra_: huh. that is something a gadget could do. we'll have to think through this more with pedronis if we want to expose this via interfaces somehow
<ogra_> yeah
<jdstrand> ogra_: or maybe a snap set :system... (would help the gadget scenario and anyone with snapd-control)
<ogra_> i'm not really keen on using kernel-module-control anywhere ...
<ogra_> not even in a gadget
<ogra_> i dotn ge why the kernel even defaults to the module ... it seems useless in 90% of the cases
<ogra_> *dont get
<jdstrand> ogra_: oh, that isn't what I meant. today, with the gadget, we could allow you via system-files to write out to a blacklist. a better solution would be a snap set option to unload/disable loading of the module
<ogra_> (each nfc howto you find starts with "add this to /etc/modprobe.d/blacklist.conf ð )
<jdstrand> heh
<ogra_> sure ... but i wonder if we shouldnt rather fix this on a kernel level ð
<ogra_> (though this might take even longer ...)
<jdstrand> that would be ideal. but a module disable facility is generally usable. can you create a topic?
<ogra_> will do
<jdstrand> thanks!
<jdstrand> pedronis: hey, do you have a rough estimate on when 2.46 will go to beta? (trying to plan the 2.46 batch of policy updates)
<jdstrand> pedronis: also, we've merge a tool for the store to use for verifying snap decls and roadmr is aware (and part of the review process)
<ijohnson> jdstrand: at least not until mvo is back in a week and a half
<pedronis> jdstrand: we plan to have a 2.45.3 in beta next week
<jdstrand> pedronis: and I plan to answer your forum questions today
<jdstrand> ijohnson, pedronis: thanks! :)
<jdstrand> pedronis: I think that is everything I have for you :)
<pedronis> jdstrand: thx
<pedronis> ijohnson: mmh, 9052 has no reviews atm
<ijohnson> yes that is true
<ijohnson> pedronis: otoh, https://github.com/snapcore/snapd/pull/9055 is basically ready to be merged I think
<mup> PR #9055: tests: fix incorrect check in smoke/remove test (2.45) <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9055>
<ijohnson> the tests ran especially quick this morning
<pedronis> ijohnson: I'm confused by this change:  https://github.com/snapcore/snapd/pull/9052/files#diff-cfcdf502f888d073b649e9c2e2140932R62  master seems to have only part of it, and there's still / in master
<mup> PR #9052: many: backport _writable_defaults dir changes (2.45) <Run nested> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9052>
<pedronis> there are similar things
<ijohnson> mmm interesting seems I was too naive in my patch
<ijohnson> let me quick put down what I was coding and look at this again
<pedronis> ijohnson: to be clear I don't think, it's material, but I'm confused why master has still the spurious /
<pedronis> #9055 can be merged
<mup> PR #9055: tests: fix incorrect check in smoke/remove test (2.45) <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9055>
<ijohnson> pedronis: shall I merge that or will you ?
<pedronis> please go ahead, I have a meeting now
<ijohnson> done
<mup> PR snapd#9055 closed: tests: fix incorrect check in smoke/remove test (2.45) <Simple ð> <Test Robustness> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9055>
<ijohnson> pedronis: so regarding master only having part of the patch, boot.InstallHostWritableDir is used both has the TargetRootDir and what we check, so master tests pass, but master tests should be using boot.InstallWritableDir like this PR has. I think probably what happened is that one of the writable-defaults PR's was opened before we adjusted all of those vars and then adjusted only the runtime vars, not the test vars
<ijohnson> before being merged to master
<ijohnson> I will prepare a small PR which fixes the dirs on master to make it more obvious
<pedronis> ijohnson: thx
<ijohnson> ahhh sorry no I misread parts of the code :-/
<ijohnson> let me finish reading this to give a full explanation
 * ijohnson is not a big fan of writable-paths
 * zyga hurts a bit, 50 min till next pill
<ijohnson> pedronis: so all of what I said above is inverted, master is correct (except the "/" at the end, seems testutil silently ignores that), but my patch to 2.45 is wrong, but again because it's wrong both in the TargetRootDir and what we check the test still passes
<pedronis> ijohnson: ok, sounds we want small tweaks for both master and 2.45
<pedronis> then
<ijohnson> to be clear, ConfigureRunSystem when called from devicemgr _should_ be writing to the _writable_defaults dir and from the initramfs when we call DisableCloudInit directly, we also want to write to _writable_defaults dir
<ijohnson> but! for fixing the cloud-init CVE, we want to not use _writable_defaults dir because at that point in time, writable-paths(5) has already applied the _writable_defaults stuff to writable/etc/cloud
<ijohnson> pedronis: but yes small patches to both 2.45 and master
<ijohnson> pedronis: I will rebase and force push the 2.45 branch to make it a simpler git history and hopefully reduce chance of conflicts when merging 2.45 back to master
<pedronis> ijohnson: ok
<ijohnson> pedronis: PR 9052 is updated
<mup> PR #9052: many: backport _writable_defaults dir changes (2.45) <Run nested> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9052>
<mup> PR snapd#9056 opened: sysconfig/cloudinit_test.go: add test for initramfs case, rm "/" from path <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9056>
<pedronis> ijohnson: reviewed
<ijohnson> pedronis: who else could review it so it could land today? cmatsuoka maybe ?
<zyga>  I will be available for review in ~ 45 min
<zyga> just under pain now
<ijohnson> zyga: no worries, even if we can't get it reviewed, it's fine to get it merged on monday too
<ijohnson> aiui it's the last PR with nothing blocking on it
<mborzecki> ijohnson: 9056?
<mborzecki> o 9052?
<ijohnson> mborzecki: 9052
<ijohnson> sorry I thought you had EOD'd already :-)
<mborzecki> ijohnson: yeah, haven't been to good at eod'ing recently
<ijohnson> haha
<mup> PR snapd#8977 closed: cmd/snap: track started apps and hooks <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8977>
<mborzecki> ijohnson: had to take a look at core20 pr again, but lgtm
<mborzecki> and a kernel update just finished, right on time
<ijohnson> Thanks mborzecki
<ijohnson> Ah right on time indeed
<zyga> +1 on https://github.com/snapcore/snapd/pull/9052
<mup> PR #9052: many: backport _writable_defaults dir changes (2.45) <Run nested> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9052>
<ijohnson> thanks zyga!
<zyga> ijohnson: is that the last of the backports?
<ijohnson> yeah looks like we will be able to land this today then, all the test are almost done
<ijohnson> yes
<zyga> that's great
<ijohnson> yeah should be in good order for monday
<zyga> I see all workers are lit up
<zyga> that's good
<zyga> man this hurts
<zyga> I'm really ready for Tuesday
<zyga> ijohnson: will you update https://github.com/snapcore/snapd/pull/8998 to test both variants?
<mup> PR #8998: tests/cmd/snap-bootstrap/initramfs-mounts: fix typo <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8998>
<ijohnson> zyga yes it's in my queue
<mup> PR snapd#9052 closed: many: backport _writable_defaults dir changes (2.45) <Run nested> <UC20> <Created by anonymouse64> <Merged by zyga> <https://github.com/snapcore/snapd/pull/9052>
<zyga> all is in
<mup> PR snapd#9056 closed: sysconfig/cloudinit_test.go: add test for initramfs case, rm "/" from path <Simple ð> <Test Robustness> <Created by anonymouse64> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9056>
<zyga> xnox: do you recall if there's something that makes systemd not mount /sys/fs/cgroup/unified?
<zyga> though I suspect it's just one of our tests breaking something
<xnox> zyga:  depends on the kernel you run on, and systemd you run, and kernel commandline, and systemd compiled time default.
<xnox> zyga:  so one has to check all that, all version numbers, etc.
<zyga> xnox: just noticing it magically goes away randomly on our 16.04 systems
<xnox> it has changed over time, when it was introduced, etc.
<zyga> so I really think that's another test messing up something
<xnox> zyga:  which kernel.
<zyga> stock 16.04 up-to-date kernel
<zyga> it's a vanilla xenial image
<xnox> zyga: which kernel
 * zyga looks
<xnox> zyga:  all our public clouds can have stock, stock-hwe, stock-cloud-specific kernel none of which match "generic"
<zyga> ah, I see
<zyga> eh, uname output is not in the log
<zyga> oh well
<zyga> I'll debug this somehow
<ijohnson> xnox: it should be a gce kernel
<zyga> linux/4.15.0-1078-gcp
<zyga> found it
<mup> PR snapd#9057 opened: overlord: use new tracking cgroup for refresh app awareness <Created by zyga> <https://github.com/snapcore/snapd/pull/9057>
<zyga> not very creative, but last of the content-rich patch from the big integration branch
<zyga> ijohnson: in how many hours do you plan to EOD?
<zyga> I will upgrade the other half of the workers then
<ijohnson> probably 3-4
<ijohnson> but feel free to upgrade things now,
<ijohnson> I have some meetings and more iteration locally before pushing up branches
<ijohnson> and all the PR's I would have restarted jobs on already landed this morning :-D
<zyga> ok
<zyga> that out-of-date worker is idle anyway
<zyga> let me take them offline first
<zyga> upgrading
<ijohnson> ð
<zyga> upgrade complete
<mup> PR snapd#8949 closed: tests: new fs-state which replaces the files.sh helper <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8949>
<zyga> ijohnson: https://github.com/snapcore/snapd/pull/9058
<mup> PR #9058: tests: drop accidental accents from e <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/9058>
<zyga> :D
<ijohnson> +1d
<zyga> thanks
<mup> PR snapd#9058 opened: tests: drop accidental accents from e <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/9058>
<xnox> ijohnson:  note that 4.15 is based off bionic kernel. Or like an hwe kernel. If you expect to test "xenial core16 as UC16 is shipped" try booting v4.4 based kernel somehow.
<ijohnson> xnox: those tests were for desktop/server
<xnox> ijohnson:  for which series.
<ijohnson> xnox: the tests we do for core boot an actual UC16 vm with an actual uc16 kernel snap
<xnox> ijohnson:  default server on xenial are v4.4 kernel too.
<zyga> I don't think we test 4.4 then
<ijohnson> xnox: for all the series ? I dunno we have 14.04, 16.04 18.04 20.04, 20.10, etc.
<ijohnson> for non-ubuntu core it's just whatever is on gce afaik
<zyga> though I was mostly after the mystery of why it changes sometimes (across re-run of same test)
<zyga> I'll write a detector to spot that though, should be uncovered soon
<xnox> ijohnson:  each series has their own base kernel. which doesn't match public cloud images kernel version. Because all public cloud images chose to control their own kernel versions on rolling basis.
<ijohnson> xnox: we aren't particulary interested in testing every kernel under the sun for ubuntu, we just want to test the ubuntu releases, i.e. we care about 16.04, if there's some kernel with 16.04 that acts weird it's not really our testing's job to find that
<ijohnson> I would expect the kernel team to be on top of testing that 4.15 and 4.4 and 5.whatever kernels all work well with xenial
<zyga> ijohnson: one more trivial https://github.com/snapcore/snapd/pull/9059
<mup> PR #9059: tests: replace _wait_for_file_change with retry <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/9059>
<zyga> thank you for the review cmatsuoka
<cmatsuoka> zyga: that was a quite strange typo :)
<mup> PR snapd#9059 opened: tests: replace _wait_for_file_change with retry <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/9059>
<zyga> cmatsuoka: I suspect a side effect of dead keys
<zyga> ijohnson: updated https://github.com/snapcore/snapd/pull/9057
<mup> PR #9057: overlord: use new tracking cgroup for refresh app awareness <Created by zyga> <https://github.com/snapcore/snapd/pull/9057>
 * zyga returns to https://github.com/snapcore/snapd/pull/8883/files 
<mup> PR #8883: packaging: stop snapd early on purge <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8883>
<xnox> ijohnson:  you asked me about why /unified is sometimes mounted and sometimes not.
<ijohnson> xnox: well I didn't ask
<xnox> the answer to that is that it depends on the host kernel.
<ijohnson> sure
<ijohnson> that makes sense
<xnox> and xenial ships both kernels that have support for it, and dont'.
<xnox> but even if one uses lxd, things like that leak. Cause one can boot focal without unified in a lxd container. and vice versa boot xenial with unified in a lxd container on new enough host.
<xnox> ijohnson:  yes sorry. the conversation originally was a ping from zyga.
<zyga> xnox: that's interesting
<zyga> xnox: can you tell me which kernel would do unified and which would not?
<xnox> i can't remember. check yourself
<zyga> ok
<xnox> google it?
<zyga> :D
<zyga> I'll just look at systemd
<zyga> I'll do a quick invariant check that you gave me an idea for
<zyga> ijohnson: do you think we could be getting two sets of kernels?
<zyga> usually one but sometimes another?
<xnox> zyga:  i think there is "requirements" text file or some such.
<xnox> zyga:  i think that does mention kernel levels for various things. i hope it is mentioned for unified cgroups too.
<zyga> thanks, I'll look it up
<xnox> or like log -p history of it.
 * zyga takes a break
<zyga> I pushed a comment to https://github.com/snapcore/snapd/pull/8883 and will come back to see if it passes with latest master
<mup> PR #8883: packaging: stop snapd early on purge <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8883>
<cmatsuoka> ijohnson: I have a theory for the game controller problem in core
<cmatsuoka> ijohnson: I think /dev/input/js0 is readable but SDL doesn't read it because it didn't receive the controller connection event
<ijohnson> cmatsuoka: I read that as "you have a game theory problem in core" and was simultaneously excited and terrified at the same time
<ijohnson> ah that's a good point
<cmatsuoka> ahah
<cmatsuoka> ijohnson: to test that I wrote a very simple SDL program that just reports button presses. It works nicely on classic but doesn't report anything on core.
<cmatsuoka> ijohnson: but the interesting thing is: it doesn't even try to read /dev/input
<ijohnson> cmatsuoka: mmm so you strace'd it?
<cmatsuoka> yes I did
<cmatsuoka> it doesn't open /dev/input/xx
<ijohnson> hmm yeah that does sound like a SDL problem indeed then
<cmatsuoka> I think it's not exactly a SDL problem, but rather something related to udev or USB hotplugging
<cmatsuoka> or how the confined application receives those events
<ijohnson> I confirmed with popey that the joystick is in the device cgroup, so I don't see how udev could be the problem
<ijohnson> unless SDL listens for udev events directly itself ?
<cmatsuoka> well that's a good question. I think I'll have to check how SDL does that
<cmatsuoka> ijohnson: it can use different methods to detect the joystick: libudev, HID directly, or maybe some other ways (I see some ioctls I don't recognize there)
<cmatsuoka> libudev is optional
<ijohnson> I mean if it is asking udev directly (i.e. not monitoring for events) if there exist joystick devices that should work
<ijohnson> did you minimal SDL app use libudev ?
<ijohnson> *your
<cmatsuoka> not explicitly, the code is: https://pastebin.ubuntu.com/p/m5Kpz7JmW4/
<cmatsuoka> it's also not in the ldd output
<ijohnson> hmm so it's probably using HID
<mup> PR snapd#8789 opened: interfaces/docker: use implicitOnClassic: true <Needs Samuele review> <â Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8789>
<mup> PR snapd#9059 closed: tests: replace _wait_for_file_change with retry <Simple ð> <Created by zyga> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9059>
#snappy 2020-07-25
<mup> PR snapd#9016 closed: secboot: improve key sealing tests <Test Robustness> <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9016>
<mup> PR snapd#9058 closed: tests: drop accidental accents from e <Simple ð> <Created by zyga> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9058>
#snappy 2020-07-26
<mup> PR snapd#9053 closed: many/tests/preseed: reset the preseeded images before preseeding them <Bug> <Preseeding ð> <Test Robustness> <Created by anonymouse64> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9053>
