#snappy 2015-05-04
<mehdi__> hey guys can somebody explain to me what is snappy exactly? i dont quite get it from what the website says
<dholbach> good morning
<leandrosansilva> Hey, is it possible to have non-dockered snappy-packages? Somethig similar to ubuntu-core?
<ogra_> i would assume the majority of snappy packages doesnt use the docker framework
<leandrosansilva> Oh, and is there any xserver package available? I'd like to run it on a physical machine instead of a virtualized one, but using the search command I found nothing, not a way of installing it. Is there any way of converting existing .deb packages to snappy ones?
<jdstrand> lool: hey, can you keep an eye on the 'Re: need help with freedomotic snappy app' thread in snappy-devel@. the person's system is out of date and they are on raspberry pi2. I have a feeling there might be questions regarding upgrading and/or reflashing
#snappy 2015-05-05
<JamesTait> Good morning all; happy Tuesday, and happy Ferret Day! ð
<tbr> is there a repository with the yaml files that I can look at? specifically the OEM files? I'd like to try and modify the x86_64 and the BBB files.
<ogra_> tbr, sergiusens would know, but i think he is off this week
<tbr> thanks anyway
<ogra_> probably the description in the sotre gives a hint
<mrjazzcat> I have a BBB with an old Angstrom still on the mmc and a lenghty uboot env.  I suspect that is messing with the stock BBB Ubuntu image, as I can't get that to boot.  Has anyone else ever seen that issue?  Does clearing the uboot environment fix it?  That's my next experiment.
<tbr> I find snappy extremely interesting, but at the same time if you want to go beyond the most basic things you immediately run in the concrete wall of undocumented everything
<ogra_> *store
<ogra_> yeah, we need to work on that ...
<ogra_> urgently
<tbr> I explicitly don't blame, but I can download tarballs of "random binaries" where I have no idea about provenance, licensing, compliance, anything.
<tbr> I know the u-boot/kernel sources must be _somewhere_, but where and how the tarball came to be is again "magic"
<ogra_> right
<tbr> I offered to help make the BBB image flashable, but fail at step zero and by FSM I'm not a person to give up easily if there is lack of documentation.
<ogra_> i think snappy should grow some meta field for that ... like apt has with the Vcs-Bzr or Git tags
<tbr> or some manifest or metadata output
<ogra_> right
<tbr> something where one can follow the breadcrumbs
<tbr> the fact that it's the third week in a row, where mostly everyone is not available doesn't help either.
<ogra_> yeah, they were all at a sprint
<ogra_> and this week is UOS...
<ogra_> next week we'll all be back to normal operations
<tbr> I think I had less problems to dive into MeeGo, set up my own OBS, rebuild the distro and have MIC spit out an image...
<tbr> and by FSM that was a major pain in the back
<tbr> ogra_: actually I have to correct myself. I find it upsetting that https://developer.ubuntu.com/en/snappy/guides/porting/ just points to a bag of binaries, with no checksum and no indication of GPL compliance.
<ogra_> yeah, thats definitely an issue
<sergiusens> ogra_: no, not off this week
<ogra_> oh
<ogra_> i thought you were
<ogra_> sergiusens, well, can you help tbr ?
<ogra_> to find the right sources for OEM snaps
<sergiusens> tbr: did you get the link? https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems if not
<dholbach> if there are issues with the docs, can you please file a bug at https://launchpad.net/developer-ubuntu-com/+filebug please?
<ogra_> sergiusens, and i think he has a valid point with the GPL compliance ...
<sergiusens> tbr: u-boot sources -> lool
<ogra_> we need to find a solution for that
<tbr> sergiusens: come again? what about u-boot source?
<sergiusens> tbr: the kernel comes from the debs
<sergiusens> tbr: http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-core/hooks/500-move-kernel-to-device-tar.binary
<sergiusens> tbr: heh, lool is an irc nick :)
<lool> lol
<sergiusens> tbr: http://people.canonical.com/~lool/snappy-bbb/build
<sergiusens> lool: how about we package u-boot for bbb and stick it in our ppa and I can create script that just grabs all the pieces?
<sergiusens> and assembles the oem package
<lool> sergiusens: perhaps we can just apply that to the u-boot package itself
<lool> it's just a config addition IIRC
<tbr> lool: umm, so does that archive the git sources or at least logs the git hash somewhere?
<sergiusens> lool: the patch? are we using the same git branch?
<tbr> lool: or do I need to try and build from upstream until I get a matching binary?
<lool> tbr: it's 2014.10 + the patch
<lool> sergiusens: let's just put that patch there?
<lool> http://people.canonical.com/~lool/snappy-bbb/0001-Enable-SUPPORT_RAW_INITRD-to-load-initrd.img.patch
<lool> it's a one line config change
<lool> tbr: yeah, you can try building every single revision with different compilers
<ogra_> lool, well, it would still be nice to be able to get a summary of used source trees via a snappy command ... at least for the binaries that want to define them
<lool> ogra_: like you can do on Android
<ogra_> can you ?
<lool> no
<ogra_> heh
<ogra_> well, we're better than that :)
<lool> a lot of things would be nice  :-)
<lool> the development experience is still TBD
<lool> we should offer a space for metadata like this at that point
<lool> there's a source meta already
<ogra_> snappy sources rpi2-oem
<sergiusens> lool: ogra_ that's what the sources of sourcery is for
<ogra_> and that would give you a list for source locations ...
<ogra_> or some such
<sergiusens> lool: ogra_  and readme.md is free for all text
<lool> or make get-sources
<lool> sergiusens: yup
<lool> for now: it's free-form, document things the way you want
<tbr> something that puts you easily into something that /could/ be considered compliance by non anal people would be immensely appreciated. I'm not an GPL nazi and don't insist on GPLv2 compliance being only possible by mailing me a CD/DVD...
<ogra_> we only mail packets of punchcards anyway ;)
<ogra_> that more environment friendly than plastic disks
<tbr> that I'd like to see, but won't pay the postage for. ;->
<ogra_> heh
<tbr> also things are a bit more clear now 'UBOOT_BRANCH="v2014.10"' is a misnomer, as it's a tag not a branch
<tbr> that at least should narrow it down to /one/ state of the source tree, not an arbitrary point of a branch
<tbr> one more question, where do I find the oem yaml files? is there a repository?
<ogra_> tbr, i thought the first branch sergiusens pointed to had them
<ogra_> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files
<tbr> ogra_: yeah, missed that I had it open already
<tbr> hmm, that doesn't seem to indicate any specific kernel
<tbr> *sigh*
 * tbr digs further down the rabbit hole
<ogra_> tbr, it uses the kernel from the archive
<ogra_> no magic involved here
<ogra_> http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-core/hooks/500-move-kernel-to-device-tar.binary
<ogra_> during build it does "apt-get install linux" ...
<ogra_> and that script above copies the binary bits around then
<tbr> ogra_: can I telll from the image or some _publicly_ available log which package was used?
<tbr> btw: where do I file a bug against releases.ubuntu.com? some of the images are not signed
<mwenning> lool, ping
<tbr> I mean if there is a bug in the kernel I'd like to know if I'm filing a bug against linux-image-foo-arch-bar version 42.23.5-1 or 42.23.5-666
<ogra_> uname -a
<tbr> .oO(pleas don't tell me to string the vmlinu* file)
<tbr> seriously?
<ogra_> anything wrong with that ?
<tbr> I mean I know that I can use uname on a _running_ system or string it, but did snappy really abolish all metadata?
<ogra_> you'd file it against the linux product in LP and give the info of system-image-cli ... that would be the other option ...
<ogra_> the person triaging can from that deduct which kernel was used ...
<tbr> denying me the possibility to try and easily figure it out myself. I mean it's great if canonical wants to sell consulting hours because nobody can figure it out, but on the other hand it might also have a bit of an impact on general adoption
<ogra_> nobody denies you
<tbr> let me rephrase that: making debugging things a ginormous pain in the back because I have to ask about everything and hope that somebody maybe answers my plea for help. to word this a bit inflamatory.
<ogra_> you can go to system-image.u.c weed through the index files, find the right rootfs stamp for your rootfs, then weed through the lifevs build logs, find the matching LP build ID for your rootfs build, go to the LP build job and read the log to find the kernel version that was used in that particular build
<tbr> so there are logs?
<mrjazzcat> mwenning:  Hey Mark.  I have a BBB with an older uboot environment.  That env is clearly f--king up my Snappy boot.  Did you have any trouble getting your stable Snappy image to boot?
<ogra_> if you feel comfortable with that, you can indeed do it ... you asked how to file a bug though ... for that i'd just add uname -a or system-image-cli -i
<tbr> yeah, I tend to provide patches with my bugs...
<mrjazzcat> mwenning:  If I just knew what variables were required, I'd fix it.  I deleted all of them, but that failed too.  Clearly there are dependencies.
<mrjazzcat> mwenning:  Could boot to uboot and do a "printenv" for me?  That might solve it
<ogra_> well, i would take the shortcut and use uname -a ... there should be matching tags on teh git tree at kernel.ubuntu.com
<tbr> is that documented somewhere? maybe it's a "no need to document things  for snappy as it's documented elsewhere" thing?
<lool> mwenning: pong
<ogra_> tbr, what, ubuntu kernel development ?
<ogra_> not sure the tags and versioning are ... ask in #ubuntu-kernel i guess
<tbr> ogra_: I mean something more like "how do I piece things together and how do I reproduce an image, find build logs, etc"
<ogra_> not yet, no ... and reproducing will be really hard, our image build infra is ratther complex
<tbr> :(
<ogra_> i once wrote a tool for doing phone builds ... that could probably be re-vived for snappy
<tbr> I'll try to summarize my points about lack of metadata and logs and such
<tbr> and traceability of sources
<ogra_> https://launchpad.net/project-rootstock-ng
<tbr> I hope filing against "snappy-ubuntu" is the right thing? there are so many places...
<ogra_> yeah, thats the generic landing place for snappy bugs
<ogra_> http://bazaar.launchpad.net/~ogra/project-rootstock-ng/trunk/view/head:/rootstock-touch would give you a rootfs tarball (if it would be modified for snappy) ... but thats only half the bits ...
<ogra_> the creation of the system-image out of that lives in the system-image server ... you would have to assemble that part yourself ...
<ogra_> and indeed it wouldnt be upgradeable since it wont be properly signed
<tbr> so basically platform development is impossible unless you are privy to run your own builds on that aystem-image machine or just resort to screwing around with the files manually
<ogra_> well, you patch deb packages for platform development .... thats what it boils down to
<ogra_> since snappy is assembled from debs in the archive
<ogra_> (except for u-boot in the BBB case)
<tbr> yeah, but you said I can't build my own image
<ogra_> right, for testing you would make it temporary writable, make sure your patch works, send a debdiff or bzr merge proposal (or a git one now that LP can do git) ... and get it in one of  the next image builds
<skay> ogra_: we have a tool for building phone images too
<skay> https://launchpad.net/capomastro
<ogra_> /join #ubuntu-uos-plenary
<ogra_> oops
<lool> Anyone seen such:
<lool> 2015/05/05 17:29:25 WARNING: [sc-filtergen --include-policy-dir=/var/lib/snappy/seccomp --policy-vendor=ubuntu-core --policy-version=15.04 --template=default --policy-groups=networking] failed
<lool> nymi-forgerock_1.0.1_all.snap failed to install: exec: "sc-filtergen": executable file not found in $PATH
<lool> sergiusens: ^ does that sound familiar?
<lool> jdstrand: ^ perhaps?
<lool> this is with:
<lool> ubuntu-core 2015-04-20 8       ubuntu
<lool> beagleblack 2015-04-21 1.7     canonical
<sergiusens> lool: that's strange, it should be on the image
<Chipaca> lool: hmm
<Chipaca> lool: could you check whether you have sc-filtergen?
<Chipaca> i'm assuming no, but another option is that your path got buggered :)
 * Chipaca peers at nothal 
<Chipaca> @ping
<nothal> Chipaca: pong
<Chipaca> nothal: some of your plugins don't expect you to be called something else
<Chipaca> @reviewlist
<nothal> https://code.launchpad.net/~chipaca/webdm/vendor-and-description/+merge/258281 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/install-progress-ui/+merge/258267 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/success-and-failure-messaging-view/+merge/258266 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/bem-html-css-for-great-justice/+merge/258265 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~sergiusens/webdm/sizeSupport/+merge/258144 | Approve: 1 (1 day old)
<Chipaca> verterok: Ã§a marche
<Chipaca> verterok: except maybe it's missing the lp:snappy mps?
<lool> Chipaca: I didn't find it
<lool> Chipaca: where should it be?
<Chipaca> lool: /usr/bin/
<lool> Chipaca: nope
<lool> (BeagleBoneBlack)ubuntu@localhost:~$ ls /usr/bin/sc*
<lool> /usr/bin/scmp_sys_resolver  /usr/bin/script
<lool> /usr/bin/scp                /usr/bin/scriptreplay
<mbroadst> hi, is there a workflow for creating raw (like dd) images of snappy+snaps, for automating the build of a reproducible "releasable image" for a product?
<mbroadst> like ubuntu-core plus 2 or 3 snaps, all bundled together (without having to log in an load the snaps etc)
<ogra_> mbroadst, there is ... using ubuntu-device-flash ... it has an --install option that allows you to install snaps from the store at build time
<sergiusens> lool: your core image is boken if not there
<sergiusens> nothal: are you operational?
<verterok> Chipaca: added snappy as a branch instead of project, maybe the multiple series confuses the bot
<verterok> sergiusens: it should
<lool> sergiusens: ok; thanks
<lool> will reflash
 * Chipaca -> dinner making and such
<sergiusens> lool: what was your oem snap name for rpi2?
<sergiusens> mvo: hey!
<mvo> hey sergiusens
<sergiusens> mvo: rested a bit?
<mvo> sergiusens: yes, thanks! you too?
<sergiusens> mvo: just a bit, I only arrived yeserday at 1AM, but took Monday off so feeling good and arrived to a bigger team today as well which felt good
<mvo> sergiusens: heh, true that
<sergiusens> mvo: btw, to think about https://walledcity.com/supermighty/building-go-projects-with-gb
<beowulf> sergiusens: want to enable bugs in webdm lp?
<sergiusens> beowulf: no, why would I want bugs?
<sergiusens> :-D
 * sergiusens enables bug reporting
<sergiusens> beowulf: done
<beowulf> sergiusens: ta
<lool> asac: I'll be a few minutes late
<Chipaca> mvo: what was the hangout url? (you reached me on my phone the first time)
<lool> asac: ok am on
<lool> mvo: Poke on URL too
<mvo> send it to you (both)
<Chipaca> ooh, look: code i hope to never need: https://github.com/dutchcoders/xmlgen
<beowulf> Chipaca: speaking of which, i need some reviews :)
<Chipaca> wha tac oincidence!
<Chipaca> beowulf: explain to me why i need to review a 6k-line diff :)
<Chipaca> ELI5, even
<Chipaca> beowulf: what does .destroy({stuff: blah}) do?
<Chipaca> beowulf: only destroy things that match?
<beowulf> Chipaca: stuff: blah?
<Chipaca> beowulf: dataType: 'html'
<beowulf> Chipaca: dataType: html ==> https://bugs.launchpad.net/webdm/+bug/1452011
<Chipaca> beowulf: and if we fix that, this code will need to change?
<beowulf> Chipaca: explain to me why it's 6k if 4k was removed and ~600 added :)
<beowulf> Chipaca: yes
<Chipaca> beowulf: no (easy) way around that?
<beowulf> Chipaca: around which?
<Chipaca> beowulf: having to change it
<beowulf> Chipaca: dataType: html
<Chipaca> beowulf: do you have an example of a query that returns an empty response?
<Chipaca> beowulf: am i spamming you with too many questions?
<beowulf> Chipaca: PUTs used to, they don't anymore
<beowulf> Chipaca: you're well within thresholds atm
<beowulf> Chipaca: i added the {} empty note just in case, as it catches people out
<Chipaca> ahh, gotcha
<Chipaca> ok
<Chipaca> i could fix this
<Chipaca> anyway, approving the branch
<beowulf> Chipaca: i await your bikeshedding the 10 line diff in the next mp ;)
 * Chipaca was trying to learn! bikeshedding is more fun tho
<beowulf> :D
<Chipaca> beowulf: how would i go around running the js tests?
<beowulf> Chipaca: assuming you have cd www/ && npm install, karma start
<beowulf> Chipaca: i think i should put the test running into build.sh too
<Chipaca> beowulf: i can do that in a bit if you want
<beowulf> Chipaca: feel free https://bugs.launchpad.net/webdm/+bug/1452027
<Chipaca> hehe
<Chipaca> i didn't know this BEM thing
<beowulf> Chipaca: i also plan to move all the gulp, npm stuff into the project root https://bugs.launchpad.net/webdm/+bug/1452028
<beowulf> Chipaca: BEM is kinda hard, but really helps keep CSS maintainable, among other things
<Chipaca> mhmm
<Chipaca> i have some hope of understanding the css :)
<Chipaca> beowulf: should all error responses also be json?
<beowulf> Chipaca: everything
<beowulf> Chipaca: orthe client needs to know, otherwise it'll throw an error trying to parse text as json
 * Chipaca looks at code that does fmt.Fprint(w, fmt.Sprintf(...)) and wonders if sergiusens knows about fmt.Fprintf
<sergiusens> Chipaca: MP that please!
<Chipaca> sergiusens: no
<Chipaca> sergiusens: am killing it in a different way :)
<Chipaca> sergiusens: making all errors be json
<sergiusens> Chipaca: yes, I have that in scope, and would welcome
<Chipaca> sergiusens: does your vi convert tabs to spaces?
<sergiusens> Chipaca: no, my goimports runner
<Chipaca> sergiusens: so if i change tabs to spaces in webdm's README.md, all is good?
<sergiusens> Chipaca: save hook, pre buf write or however you want to call it
<sergiusens> Chipaca: oh, yeah go for it
<Chipaca> not in all of it
<Chipaca> just in the bits that will make the here document work
<Chipaca> :)
<sergiusens> Chipaca: you can feel good now that I'm finally able to look at those MPs ;-)
<sergiusens> Chipaca: for error response btw, if you are going to do that, not sure if it's best to expand the response struct or jst use that as it is
<Chipaca> sergiusens: was tempted to put it in structs, but then thought it better to just send strings
<Chipaca> sergiusens: huzzah for reviews, btw
<Chipaca> sergiusens: build.sh fails complaining about www/public not existing; do i need to mkdir that?
<sergiusens> Chipaca: hmmm, never saw that, did you do the npm install dance?
<Chipaca> sergiusens: yep
<Chipaca> sergiusens: got a few warnings, that i ignored
<Chipaca> pm WARN engine imagemin@3.1.0: wanted: {"node":">=0.10.0","npm":">=2.1.5"} (current: {"node":"0.10.25","npm":"1.4.21"})
<Chipaca> s/^/n/
<Chipaca> and two about fsevents
<Chipaca> three actually
<Chipaca> Building web assets with gulp...
<Chipaca> --gulpfile www/gulpfile.js
<Chipaca> cp: cannot stat âwww/publicâ: No such file or directory
<Chipaca> sergiusens: ^ that's the full output of build.sh
<sergiusens> Chipaca: npm install as the ready me says; I guess we can automate that in build.sh
<sergiusens> Chipaca: but npm feels rather fragile from my little xp with it
<Chipaca> sergiusens: i did the two npm installs
<Chipaca> as per the readme
<sergiusens> Chipaca: heh, then beowulf to the rescue
<Chipaca> also had to mkdir ~/node, which i added to the readme
<sergiusens> he always complains about go being broken; now we get to nag him :-)
<Chipaca> mbuahaha
<Chipaca> sergiusens: could you show me what an "npm install" run looks like for you?
<sergiusens> Chipaca: sure
<sergiusens> Chipaca: btw, if you build snappy, copy it to a kvm and replace /usr/bin/snappy, does everything still work for you?
<sergiusens> Chipaca: I get this weird thing operation not supported
<sergiusens> hello-world failed to install: unpack /tmp/hello-world788964914 to /apps/hello-world.canonical/1.0.14 failed with exit status 1
<Chipaca> sergiusens: as much as i tried, yes
<sergiusens> during unpack
<Chipaca> sergiusens: hm! anything in dmesg?
<Chipaca> sergiusens: is that with trunk?
<Chipaca> sergiusens: or with copyfile?
<sergiusens> Chipaca: it's with the arch one (which includes copyfile), but I suspect I'll see the same with trunk
<sergiusens> Chipaca: yeah, even trunk fails for me
<Chipaca> sergiusens: works here on amd64
<sergiusens> hmmm
<sergiusens> Chipaca: so it works except for unpack here
<Chipaca> sergiusens: df ?
<sergiusens> Chipaca: did you follow the npm instructions even if it didn't make sense? and are you running npm from the npm dir or the system wide one?
<sergiusens> Chipaca: the problem is, if I revert to the original snappy binary everything is dandy
<sergiusens> Chipaca: I wonder if it's trusty related since unpack does some syscalls
<sergiusens> Chipaca: darn, forgot to set the buffer for the terminal, npm install overflowed
<Chipaca> sergiusens: i'll start over with them npm malarkey
<sergiusens> Chipaca: http://paste.ubuntu.com/10992420/ that's the end of it from a clean branch run from within ./www
<Chipaca> that's fairly similar, alhtough i didn't have the "npm http" lines (maybe you've got debug on or sth)
<sergiusens> Chipaca: I am running the latest npm bootstrapped from the system's npm
<sergiusens> Chipaca: oh, maybe not
<sergiusens> which npm
<sergiusens> /usr/bin/npm
<sergiusens> Chipaca: I do have /home/sergiusens/node/bin in my path (which only contains gulp)
<Chipaca> yep, ditto
<Chipaca> and npm --version is 1.4.21 here
<Chipaca> that's apparently fairly old though
<sergiusens> Chipaca: I have 1.3.10
<Chipaca> heh
<Chipaca> sergiusens: and what do you have in www/public ?
<sergiusens> Chipaca: however this worked fine when I was on vivid too
<Chipaca> sergiusens: what do you have in www/public ?
<sergiusens> Chipaca: s public only gets populated with gulp I believe since an npm install did nothing with public
<sergiusens> Chipaca: http://paste.ubuntu.com/10992476/
<Chipaca> :(
<Chipaca> waait
<Chipaca> gulp thinks it's echo
<Chipaca> something is rather wrong
<Chipaca> right!
<sergiusens> Chipaca: huh?
<Chipaca> sergiusens: gulp thinks it's echo
<Chipaca> not sure how that's happening
<Chipaca> trying to debug :)
<sergiusens> Chipaca: maybe some function you have somewhere
<Chipaca> http://pastebin.ubuntu.com/10992554/
<Chipaca> not that
<Chipaca> tried strace
<sergiusens> Chipaca: does the npm dir precede the system ones?
<Chipaca> 'which gulp' points to the right place
<Chipaca> don't have a gulp alias nor function
<Chipaca> strace shows that the right thing is exec'ed
<Chipaca> threw it all away and started over
<sergiusens> Chipaca: how about running it with the absolute path?
<sergiusens> Chipaca: just proves npm is rather flaky :-P
<Chipaca> dammit, same thing
<sergiusens> Chipaca: added one comment to https://code.launchpad.net/~chipaca/snappy/copyfile/+merge/258078
<sergiusens> at the very end
<Chipaca> durr
<Chipaca> you are correct :)
 * Chipaca fixes
<Chipaca> sergiusens: fixed & pushed
<Chipaca> wrt gulp, i'm an idiot; i didn't realize and it *wasn't* picking up the right gulp. sorry for the timewaste.
<sergiusens> Chipaca: what was it picking up?
<Chipaca> sergiusens: ~/bin/gulp
<Chipaca> which was a symlink to /bin/echo
<sergiusens> heh
<sergiusens> Chipaca: one comment for https://code.launchpad.net/~chipaca/snappy/deprecated-architectures/+merge/258112
<sergiusens> Chipaca: and I'll let you set the commit message
<Chipaca> sergiusens: you mean why not invert the if/else?
<sergiusens> Chipaca: yes, the == nil is empty
<sergiusens> Chipaca: one comment here too https://code.launchpad.net/~chipaca/snappy/description/+merge/258276
<Chipaca> sergiusens: no, the == nil is not empty
<sergiusens> Chipaca: hmm, it looked empty here :-P let me refresh just in case
<Chipaca> no need to refresh; you've just missed it
<Chipaca> it's a white line in a sea of red and green
<sergiusens> Chipaca: ah
<sergiusens> ah
<sergiusens> ah
<sergiusens> Chipaca: the all case!
<sergiusens> Chipaca: how does not hal tell me what's next in queue
<sergiusens> ?
<Chipaca> sergiusens: @activereviews ?
<Chipaca> @activereviews
<nothal> Chipaca: No existe esa orden!
<Chipaca> @reviewlist
<nothal> https://code.launchpad.net/~chipaca/webdm/vendor-and-description/+merge/258281 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~chipaca/snappy/description/+merge/258276 | Needs Information: 1 (less than a day old)
<nothal> https://code.launchpad.net/~chipaca/snappy/vendor/+merge/258272 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~jamesodhunt/snappy/install.yaml/+merge/256925 | Needs Information: 1, Needs Fixing: 1 (13 days old)
<Chipaca> @thank you
<nothal> Chipaca: No existe esa orden!
<Chipaca> @estÃºpida
<nothal> Chipaca: No existe esa orden!
 * Chipaca hugs nothal 
 * nothal hugs Chipaca 
<Chipaca> sergiusens: about "# blah", i don't think we're doing that
<Chipaca> sergiusens: i mean, if in the readme.md you put â# yaddaâ as the first line, that goes in verbatim
<sergiusens> Chipaca: that's bad /me things
<sergiusens> thinks
<Chipaca> the whole "make a half-arsed parser of the readme.md and use that to populate things that should be in the package.yaml anyway" is an excellent idea, we should do more of it
 * Chipaca is being mean
 * Chipaca stops
<sergiusens> Chipaca: please no
<sergiusens> Chipaca: I wish I was part of the team before this idea flourished :-)
<Chipaca> sergiusens: we should make the readme be html, and parse it with regexps
<sergiusens> Chipaca: that's what I was forced to do with cdimage fwiw, system-image was a welcomed addition in that respect ;-)
<Chipaca> see? told you it was a good idea
 * Chipaca runs
<sergiusens> Chipaca: good thing that we can get rid of readme.md and I would make it top level as that's what github renders by default anyways
<sergiusens> Chipaca: we just need to proposed it
<Chipaca> sergiusens: we should. and add any and all fields to the package.yaml, i think
<sergiusens> Chipaca: +1 on that
<Chipaca> i *imagine* the reason for not having everything in there is to allow people to change the metadata without reuploading
<sergiusens> Chipaca: then the readme.md in itself is useless
<Chipaca> oh, the readme.md thing is wrong from any angle you look at it
<sergiusens> harr harr
<Chipaca> drat, being mean again. i said i'd stop
<Chipaca> i blame you :)
<sergiusens> Chipaca: trolling is contaigeous
<sergiusens> Chipaca: can you merge trunk for https://code.launchpad.net/~chipaca/webdm/vendor-and-description/+merge/258281 ?
<Chipaca> ... maybe
<Chipaca> sergiusens: merged and pushed
<Chipaca> sergiusens: do you still need information on https://code.launchpad.net/~chipaca/snappy/description/+merge/258276 ?
<sergiusens> Chipaca: no, you answered my question
<sergiusens> Chipaca: maybe a TODO to get rid of it would be good though :-)
<sergiusens> Chipaca: meh, maybe just a trello
<sergiusens> Chipaca: oh, description is in the landing pipe, do you mind updating dependencies.tsv in https://code.launchpad.net/~chipaca/webdm/vendor-and-description/+merge/258281 ?
<sergiusens> once the merge completes
<sergiusens> beowulf: I'm liking that new progress bar :-)
<Chipaca> sergiusens: sure
<Chipaca> sergiusens: you around still?
<sergiusens> Chipaca: yeah, just went for abit
<sergiusens> but also leaving soonish, movie night tonight :-)
<Chipaca> sergiusens: could you try this in your setup (in webdm) plz?
<sergiusens> Chipaca: try what?
<Chipaca> sergiusens: (cd wwww && xvfb-run ./node_modules/karma/bin/karma start --single-run)
<sergiusens> Chipaca: xvfb-run?
<Chipaca> yes
<Chipaca> sergiusens: maybe one w less in the cd
<sergiusens> Chipaca: ok, I'll try with 3 w's and I'll apt install xvfb before that
<Chipaca> it's getting late here
<sergiusens> yeah :-P
<Chipaca> :)
<sergiusens> I'm trolling though :-)
<Chipaca> i'd call that bantering, not trolling
<sergiusens> Chipaca: so what does that do? ah, the tests, right?
<Chipaca> yes
<sergiusens> Chipaca: roll that in!
<sergiusens> Chipaca: so what is your opinion on icons?
<Chipaca> sergiusens: i had a friend who collected them
<sergiusens> Chipaca: nice
<Chipaca> sergiusens: especially the ones from the orthodox russian branch
<sergiusens> Chipaca: what about broken ones? do you know of an svg linter we could use?
 * Chipaca stops talking about gilded pictures of dead people
<Chipaca> sergiusens: how are they broken?
<sergiusens> Chipaca: they don't render in browsers
<sergiusens> Chipaca: error on line 500 at column 62: Namespace prefix xlink for href on image is not defined
<Chipaca> nice
<Chipaca> sergiusens: not for things that aren't even valid xml, no
<Chipaca> hmmm
<sergiusens> Chipaca: webdm is supposedly sending the right content-type http://paste.ubuntu.com/10993117/
<sergiusens> Chipaca: and I did find some proper svgs that do work last time I looked and I bet this is the reason the store converts svgs to pngs store side
<sergiusens> I could always just download them as before, but I want a better solution
<Chipaca> sergiusens: where would this cleaner run?
<Chipaca> sergiusens: because inkscape is fairly good at that, running headless, but not something i'd want us to ship in core ;)
<Chipaca> inkscape python-xkcd-webserver/meta/xkcd.svg --export-plain-svg /tmp/xkcd.svg
<Chipaca> sergiusens: ^ fixes it
<sergiusens> Chipaca: no, but maybe snappy build can do that
<sergiusens> Chipaca: maybe let's do this for now on the packages themselves
<sergiusens> @reviewlist
<nothal> https://code.launchpad.net/~chipaca/webdm/json-responses/+merge/258324 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~chipaca/webdm/vendor-and-description/+merge/258281 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~jamesodhunt/snappy/install.yaml/+merge/256925 | Needs Information: 1, Needs Fixing: 1 (13 days old)
<Chipaca> sergiusens: deps updated
<sergiusens> Chipaca: ok, seems we are good for now
<sergiusens> Chipaca: tomorrow I can tentatively update webdm in the store :-)
#snappy 2015-05-06
<Chipaca> https://code.launchpad.net/~chipaca/webdm/www-tests/+merge/258325 just for beowulf
<Chipaca> sergiusens: i'm not sure i've been clear in my answer to your question in json-respones
<Chipaca> sergiusens: holler if not :)
<sergiusens> Chipaca: last mp needs prereq ;-)
<mwenning> hi snappy guys, anyone around?
<davidcalle> Good morning all o/
<asac> ppisati: hey
<asac> ppisati: the bcm patchset for pi2 ... does that defeat the multiplat property of our kernel?
<ppisati> ppisati: yes, the bcm bsp is not multiplatform-ready
<ppisati> ops
<ppisati> asac: ^
<asac> ppisati: someone said you did a more minimalistic patchset?
<asac> i assume that is also not multiplat?
<ppisati> asac: ??? - it's the bcm bsp rebased, it's the same stuff
<asac> i guess making something multiplat is nothing that can be done with reasonble effort?
<asac> ppisati: ah ok. hanks
<asac> ppisati: is there a list of socs that are good for multiplat with dtb upstream.?
<ppisati> asac: dunno if you can reuse something of that code, and then there's the 'legal problem' of the missing sign-off - we don't knwo where that code come from, etcetc
<ppisati> asac: AFAIK there isn't a 'support soc' list - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/Kconfig
<ppisati> asac: follow the Kconfig under the 'menu "Multiple platform selection"'
<ppisati> asac: these are all multiplatform (and indeed we turn on as mane as we can already in -generic)
<ppisati> asac: but their supports vary
<ppisati> asac: and then's there's the rest of the hardware on the boards to take in consideration
<asac> ppisati: do you have a list of those that we enable?
<asac> yeah in know that the experience will vary quite a lot :)
<hawkowl> shouldnt snappy be making current/ directories?
<hawkowl> because mine only has the version numbers, no current
<hawkowl> (for data files)
<Chipaca> hawkowl: not in data dirs
<hawkowl> okay
<hawkowl> so, how do i have a current/ data dir?
<Chipaca> hawkowl: where?
<hawkowl> on the filesystem I guess?
<Chipaca> hawkowl: sorry, are you asking how come you have one, or how would you go around getting one?
<hawkowl> the latter
<hawkowl> because I want one :)
<Chipaca> hawkowl: you wouldn't
<Chipaca> hawkowl: why would you want one?
<hawkowl> to store mutable and persistent local state?
<Chipaca> sounds like you're doing something wrong
<Chipaca> hawkowl: you use $SNAPP_APP_DATA_PATH
<hawkowl> right
<Chipaca> hawkowl: that gets copied over on upgrade
<hawkowl> uh
<hawkowl> okay, that sounds interesting
<Chipaca> um, sorry
<Chipaca> hawkowl: $SNAP_APP_DATA_PATH
<Chipaca> hawkowl: SNAPP_* is deprecated :)
<Chipaca> hawkowl: you also have $SNAP_APP_USER_DATA_PATH, fwiw
<Chipaca> hawkowl: hello-world.env prints all these out
<Chipaca> or it would if not for a bug wrt tmpdirs
<Chipaca> hmm
<Chipaca> mvo: tmpdir
<Chipaca> mvo: i see a card about creating them
<Chipaca> mvo: but i thought we wanted to set up a namespace and use that
<mvo> Chipaca: a private mount of tmp? yes, thats the plan
<mvo> Chipaca: iirc there was still some dir that was not created I need to double check the card
<Chipaca> mvo: we've got a problem in the current implementation, afaict
<Chipaca> mvo: where some things will create their tempdir as root (e.g. webdm)
<Chipaca> mvo: and then you try to use hello-world.env and it can't create a tempdir because /tmp/snaps is owned by root :)
<mvo> Chipaca: *autsch*
<beowulf> Chipaca: morning, i added a comment to www-tests about an option to run without xfvb, feel free to tell me no :)
<Chipaca> beowulf: would you also want to reuse an existing karma server thing?
<Chipaca> beowulf: does the way i'm running it reuse it, or does it kill it?
<beowulf> Chipaca: hmm, i don't think so
<beowulf> Chipaca: let me see
<Chipaca> beowulf: does --single-run kill the browser window even if the test fails?
<Chipaca> i might not have dug into this as much as it warranted
<Chipaca> mvo: so, should i add a private /tmp/, or should i add $UID to the tempdir?
<beowulf> Chipaca: with an existing karam instance running and listening, 'karma start --single-run' does as you expect it to (start a new browser, run tests, close new browser)
<beowulf> (I'm assuming that's what you want/expect)
<Chipaca> i expect nothing
 * beowulf tries failing test
<beowulf> Chipaca: with failing test, same outcome, running karma watch reports failure, new instance reports failure and exits
<Chipaca> beowulf: in any case, perhaps the best way is allowing you to override the whole command
<Chipaca> ie ( cd www && ${JS_TESTER:-xvfb-run yadda-yadda yadda} )
<beowulf> Chipaca: maybe, i don't use build.sh very often
<beowulf> Chipaca: i build www and scp to an existing webdm, so it's only when i need to update anything go-like that i run build
<Chipaca> beowulf: i'm reading that as a "yes". Holler if you're trying to politely say "that's a stupid idea"
<Chipaca> beowulf: it's run-tests, not build.sh, fwiw
 * beowulf clears rubs eyes
<JamesTait> Good morning all; happy No Homework Day! ð
<Chipaca> JamesTait: \o/
<Chipaca> beowulf: does the json-responses branch behave as you expect?
<hawkowl> hmm okay so if i'm writing some docs for a user
<hawkowl> the app needs to write a .pid, so, I need to cd somewhere that it can write
<hawkowl> where should it cd to?
<Chipaca> hawkowl: should that pid be in tmp (non-persistent) or data (persistent)?
<Chipaca> hawkowl: (why would you cd to the dir to make the .pid?)
<beowulf> Chipaca: testing now
 * Chipaca hugs beowulf 
<beowulf> Chipaca: remind me what i do to make sure i have all deps?
<Chipaca> beowulf: build.sh should sort that out for you
<Chipaca> beowulf: that is, if build worked, you had all the deps
<beowulf> Chipaca: http://pastebin.ubuntu.com/10996220/
<Chipaca> or was that run-checks
<Chipaca> beowulf: yeah, run-checks is the bit that sorts that out
<Chipaca> beowulf: if you don't/can't run the whole run-checks, godeps -u dependencies.tsv
<beowulf> Chipaca: so... run-checks, tell me about this
<Chipaca> beowulf: assuming you have GOPATH and PATH set up right, just ./run-checks
<mvo_> Chipaca: private temp is prefered but $UID for tempdir sounds simpler and quicker for now(?)
<Chipaca> beowulf: if you don't, then GOPATH=path/to/folder/holding/src/ PATH=..../src/bin ./run-checks
<beowulf> Chipaca: run-checks fails with the same error http://pastebin.ubuntu.com/10996230/
<Chipaca> hmmm
 * Chipaca tests locally
<beowulf> Chipaca: in my GOPATH, launchpad.net/webdm is a symlink to ~/workspace/canonical/webdm
<Chipaca> beowulf: i'm afraid you need to merge trunk; let me confirm
<beowulf> Chipaca: never be afraid
<Chipaca> beowulf: i'm terrified
<Chipaca> beowulf: but also, right
<Chipaca> beowulf: bzr merge lp:webdm and all is good
<Chipaca> should update a single file, dependencies.tsv
<Chipaca> :)
<beowulf> Chipaca: \o/
<beowulf> Chipaca: however... build works, run-checks does not (same failure)
<beowulf> but i have what i need, so na-na-na
 * Chipaca fixes run-checks
<beowulf> Chipaca: https://code.launchpad.net/~stephen-stewart/webdm/json-responses/+merge/258355
<beowulf> Chipaca: so, we've exposed some inconsistency in the use of 'message', which until now really meant 'something bad happened'
<Chipaca> beowulf: we've exposed it, or we've started being inconsistent?
<beowulf> Chipaca: we've started being inconsistent, but consistency was maybe bad?
<Chipaca> beowulf: tell me more though; i've tried to make it more consistent, not less :)
<beowulf> Chipaca: for example, a failed install returns a 200 with a message, which the client interprets as an error and shows the error view
<beowulf> Chipaca: now, a PUT also returns a message, which the client ... blah blah
<beowulf> Chipaca: so, maybe the webdm shouldn't return 200's for errors
<beowulf> :)
<Chipaca> beowulf: it ... shouldn't
<Chipaca> beowulf: where is it doing that?
<beowulf> Chipaca: so i think your branch is correct, and we need to change what exists
<Chipaca> i tried to make it return the right status except in the most dire case
<Chipaca> well, 'most dire'; when the json encoder falled over
<Chipaca> i can also address that case if you're seeing it 'in real life' though
<Chipaca> (and for PUT, am already doing so)
<beowulf> Chipaca: so, in my webdm docker will fail to install and has a nice error message, but the response is a 200
<beowulf> Chipaca: i can screenshare if that makes it easier, but you should see for yourself if you try lp:~stephen-stewart/webdm/json-responses
<Chipaca> looking at the code, that doesn't make sense :)
<Chipaca> unless something weird is going on
<Chipaca> and that *never* happens, amirite
<beowulf> :)
<beowulf> Chipaca: want to hangout and you can show me where i'm probably reading somethign wrong :)
<Chipaca> beowulf: i'm in a coffee shop, so not sure if hangout will work, but can give it a try
<Chipaca> oh wait, no camera and no mic unless i reboot
<Chipaca> beowulf: screenshare should work though
<beowulf> Chipaca: bark twice for yes
<Chipaca> beowulf: what's the 'nice error message'?
<Chipaca> beowulf: try again! :)
<Chipaca> beowulf: wasn't logged in to hangouts with my canonical account on my laptop
<Chipaca> just on my phone, where i would not have been able to screenshare as much
<beowulf> Chipaca: https://plus.google.com/hangouts/_/canonical.com/chipaca-beowulf-to-the-death
<Chipaca> beowulf: so, "accepted" is not, actually, an error
<beowulf> Chipaca: yep
<Chipaca> ahh
<beowulf> but that is
<Chipaca> yes
<beowulf> Chipaca: make sense?
<Chipaca> yes. this is not that.
<Chipaca> ok.
<Chipaca> riiiiight
<Chipaca> cmd/snappy/handlers needs the same treatment
<Chipaca> i think
<Chipaca> maybe
 * Chipaca is not familiar enough with this code yet
<Chipaca> sergiusens: webprogress is closing errorchan from the receiving end (this is wrong)
<Chipaca> beowulf: what's the url that you were GETting from the progress bar?
<Chipaca> beowulf: how about now
<Chipaca> beowulf: (that is: json-responses should now return a 5xx when install fails)
<Chipaca> sergiusens: you probably want to take another look at json-responses :)
<beowulf> Chipaca: /api/v2/packages/docker
<Chipaca> beowulf: yep yep, figured it out in the end :)
<beowulf> Chipaca: looking
<Chipaca> beowulf: merged trunk also, just for you
<davmor2> ogra_: question how will snappy make use of the no rebooting kernels from 4.0?  I'm assuming it will be important for things like fridges that they don't turn off :)
<ogra_> davmor2, heh, no idea yet, i guess we'll use the feature somehow
<Chipaca> mvo_: you around?
<mvo_> Chipaca: yes, almost ready for lunch though
<Chipaca> mvo_: me too :0
<Chipaca> mvo_: so, about /tmp
<mvo_> Chipaca: what can I do for you?
<Chipaca> mvo_: completely private, or bound-mounted from /tmp/some/thing ?
<mvo_> Chipaca: I think ideally completely private
<Chipaca> mvo_: advantage of the latter is that we can dig in the tmp if we need it
<mvo_> Chipaca: hm, good point
<mvo_> Chipaca: lets do that for now
<Chipaca> ok :)
<Chipaca> this'll need changes on the snappy side as well, either way
<Chipaca> making it not bound is a trivial change, post hoc
<Chipaca> jdstrand: you around?
<Chipaca> jdstrand: https://code.launchpad.net/~chipaca/ubuntu-core-launcher/unshare/+merge/258367
<Chipaca> mvo_: ^ but needing jdstand's input wrt it not actually, you know, working :)
<Chipaca> (it's probably the unshare syscall getting blocked)
<Chipaca> May  6 11:29:30 localhost kernel: [  838.228966] audit: type=1326 audit(1430911770.184:17): auid=1000 uid=1000 gid=1000 ses=4 pid=899 comm="ubuntu-core-lau" exe="/usr/bin/ubuntu-core-launcher" sig=31 arch=c000003e syscall=272 compat=0 ip=0x7f06ba6a68e7 code=0x0
<Chipaca> ^ like so, see :)
<mvo_> Chipaca: what does scmp_resolve_syscall 272 print for this syscall?  I guess unshare?
<mvo_> Chipaca: do you do that before the seccomp is setup?
<Chipaca> mvo_: do i get a prize if it's "unshare"?
<mvo_> Chipaca: ignore me, I should look at the code instead of asking silly questions
<Chipaca> because it's "unshare" :)
<mvo_> Chipaca: push it before seccomp is setup :)
<Chipaca> mvo_: um. i should probably just
<Chipaca> yeah
 * Chipaca does that
<Chipaca> a'ight! much better. Now getting an apparmor error :)
<sergiusens> @reviewlist
<nothal> https://code.launchpad.net/~chipaca/ubuntu-core-launcher/unshare/+merge/258367 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/json-responses/+merge/258355 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~chipaca/webdm/www-tests/+merge/258331 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~chipaca/webdm/json-responses/+merge/258324 | Approve: 1 (less than a day old)
<nothal> https://code.launchpad.net/~jamesodhunt/snappy/install.yaml/+merge/256925 | Needs Information: 1, Needs Fixing: 1 (14 days old)
<Chipaca> jdstrand: [Wed May  6 11:50:43 2015] audit: type=1400 audit(1430913044.380:15): apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="/usr/bin/ubuntu-core-launcher" name="/tmp/" pid=847 comm="ubuntu-core-lau" flags="rw, private"
<sergiusens> beowulf: can karma run with a test based browser?
<Chipaca> sergiusens: "test based"?
<Chipaca> sergiusens: text based?
<sergiusens> Chipaca: mvo_ watch out with unshare and  3.4 kernels
<beowulf> Chipaca: like lynx?
<sergiusens> Chipaca: text of course, glad to see you are paying attention :-)
<Chipaca> sergiusens: 1. find a text browser that does xmlhttprequest
<Chipaca> sergiusens: 2. there is no 2, you're still on 1
<Chipaca> sergiusens: 3. stop lying
<beowulf> sergiusens: do you want headless, like phantomjs
<beowulf> or sort of headless, like casper(gecko)
<beowulf> or...
<beowulf> assuming you don't mean lynx
<Chipaca> beowulf: sergiusens: phantomjs sounds like would obviate the need for xvfb
<beowulf> Chipaca: yes
<beowulf> Chipaca: casper still needs xvfb but is heading in that direction
<ogra_> Chipaca, wget --header="X-Requested-With: XMLHttpRequest" -qO- $URL
<ogra_> :P
<Chipaca> lel
<sergiusens> beowulf: btw, this one is waiting on your ack https://code.launchpad.net/~chipaca/webdm/json-responses/+merge/258324
<Chipaca> sergiusens: we've iterated on that one
<Chipaca> sergiusens: and i've added IsError to snapPkg
<Chipaca> sergiusens: you probably want to take a look
<beowulf> sergiusens: Chipaca: i can ack, or i can push a friend for it so errors work and then ack
<beowulf> but i'm in meetings so it might be a while
<Chipaca> beowulf: no hurry; we might want to tweak it some more anyway
<sergiusens> beowulf: oh, I like that IsError although not all of the errors are internalservererrors
<sergiusens> err Chipaca I mean ^
<Chipaca> sergiusens: i agree; also you probably want to expose errors from other places as well?
<Chipaca> not sure tho :)
 * Chipaca does not know the codebase well enough yet
<Chipaca> sergiusens: IsError is the minimum for the problem beowulf pointed out (wrt not getting error codes when errors happened), but it's probably part of a bigger family that requires more expressiveness
<beowulf> isError means 'tell the user about this {{ message }}'
<sergiusens> Chipaca: for an installation instance, this is the only place
<sergiusens> Chipaca: oh, so it needs to be json encoded according to beowulf
<Chipaca> nope nope
<Chipaca> because is error iff error status
<Chipaca> wrt "richer interface", maybe making it an int and setting the status from inside progress
<Chipaca> but that's a little ... alabama-ish level of familiarity
<sergiusens> Chipaca: I don' know how to respond to that
<Chipaca> sergiusens: the part about setting an http status from inside webprogress being incestuous, or the part about error being univocal with an error http status?
<sergiusens> Chipaca: but wrt to installation, errors only come from there. If snappy install gave fine grained errors for everything we could start using internal status codes for easier debugging, but the text should be good enough for now
<sergiusens> Chipaca: about alabama
<Chipaca> sergiusens: i don't know how to move forwards with this either :-/
<sergiusens> Chipaca: I think it's fine for now
<Chipaca> sergiusens: \o/
<sergiusens> mvo_: I'm not sure who I talked to yesterday, but I'd love to move to git but only if we have tarmac support
<mvo_> sergiusens: aha, so tarmac does not do git right now?
<sergiusens> mvo_: I also want to move to gb instead of go get/build as soon as it's a bit stable
<sergiusens> mvo_: I am mostly sure it doesn't
<sergiusens> mvo_: afaik it was designed to work on launchpad
<mvo_> sergiusens: I guess we could just find dobey and ask :)
<beuno> it was very much designed for bzr as well
<sergiusens> mvo_: I just grepped the sources, no git
<Chipaca> beuno: maybe you were thinking of svn :-p
<beuno> ew.
<Chipaca> beuno: cvs then!
 * beuno mutes this channel for an hour
<mvo_> sergiusens: meh, yeah, I just looked at the code and it looks like adding git is quite a bit of work :/
 * Chipaca didn't get to mention rcs
<sergiusens> mvo_: yeah, we can probably branch (err clone) and get started with something that gets the job done
<sergiusens> mvo_: using launchpad lib and some git primitives
 * Chipaca afk for a bit
<mvo_> sergiusens: yeah, with a bit of luck its really just "class Branch" that needs a git equivalent
<mvo_> hm, maybe not I see some more bzrlib imports
<sergiusens> mvo_: it's full, not sure it's worth adapting tarmac to this, once we have webhooks we open the door for a better world :-)
<rsalveti> indeed
<rsalveti> looking forward for webhooks
<mvo_> sergiusens: zyga voiced some interesst in this as well (tarmac & git) fwiw
<mvo_> Chipaca: is the ubuntu-core-launcher still failing for you? if so, should I have a look?
<sergiusens> Chipaca: simple pimple for you https://code.launchpad.net/~sergiusens/webdm/sortResults/+merge/258375
<mvo_> Chipaca: I am working on mknod support for snappy right now (so that we can support the ubuntu-core tarfile, I wonder if the new copyfile using sendfile needs a update for this as well? the "old" cp -a coped with that, but I guess the new one needs some update?
<mvo_> sergiusens: I got questions about the rest interface, do we have anything like a draft already? I guess not but wnated to ask anyway
<sergiusens> mvo_: no, only what was originally done for pure webdm
<sergiusens> mvo_: which you reviewed a while back
 * mvo_ nods
<sergiusens> mvo_: I was going to look at that tomorrow and Friday
<Chipaca> mvo_: the launcher is failing wiht apparmor error (as pasted to jdstrand above)
<Chipaca> mvo_: note CopyFile does not replace cp -a (it doesn't deal with symlinks either fwiw)
<Chipaca> mvo_: clickdeb/deb.go's tarCreate is doing its own thing (which handles symlinks)
<Chipaca> mvo_: and the data directory copy is still done with cp
<mvo_> Chipaca: aha, excellent, thanks a bunch
<Chipaca> mvo_: we could make a CopyThing that handles arbitrary filesystem objects
<Chipaca> it would be quite fun actually
<Chipaca> but we haven't
<Chipaca> when you see CopyFile , read CopyRegularFile if you will
<mvo_> ta
<Chipaca> info.Mode()&os.ModeDevice) != 0 || (info.Mode()&os.ModeCharDevice) != 0
<Chipaca> mvo_: info.Mode() & (os.ModeDevice | os.ModeCharDevice) != 0 ?
<mvo_> Chipaca: good point
<Chipaca> whatever is more readable tho
<Chipaca> mvo_: want to include named pipes while you're at it?
<Chipaca> mvo_: that'd be a 'p' prefix, and os.ModeNamedPipe
<mvo_> yeah, I guess we need to add them all step by step, can add them now (phonecall right now)
<Chipaca> mvo_: https://code.launchpad.net/~mvo/snappy/snappy-refactor-progress-pkgname/+merge/258373 could use a commit message
<sergiusens> Chipaca: I'll need to change webdm if that change comes through
<Chipaca> sergiusens: i know
<Chipaca> sergiusens: i can do it for you though :)
<sergiusens> Chipaca: I'm doing a small refactor to that part of webdm for package removal though ;-)
<Chipaca> sergiusens: perfect timing, then :D
<mvo_> Chipaca: indeed, thanks, added that now :)
<dholbach> if you want to join the snappy roundtable session at uos, join us in #ubuntu-uos-core
<dholbach> and http://summit.ubuntu.com/uos-1505/meeting/22491/snappy-roundtable/ :)
<Chipaca> mvo_: did you push it?
<sergiusens> Chipaca: beowulf https://plus.google.com/hangouts/_/hoaevent/AP36tYfHZBi84WKZ-0wOaKVBAs8XrHT-vTYsPw9WeCO44hNSADN1ow
<mvo_> Chipaca: ups, I meant the commit message, the other stuff I need to still do
<mvo_> Chipaca: in the UOS session right now
<Chipaca> mvo_: and i guess you're heading into the next one
<mvo_> Chipaca: yeah
<beowulf> sergiusens: what what?
<sergiusens> beowulf: what what what?
<beowulf> sergiusens: i followed the hangout link, but i was all alone :(
<sergiusens> beowulf: Chipaca arg, lolz, that was supposed to be an MP link!
<sergiusens> beowulf: Chipaca https://code.launchpad.net/~sergiusens/webdm/deletePackage/+merge/258394
<ogra_> video editing for geeks ?
<sergiusens> there :-)
<ogra_> "merge these two hangouts" :)
<Chipaca> hate, hate hate hate, diffing structs forced upon me by silly formatting and non-whitespace-ignoring bzr
 * Chipaca looks at the diff manually
<Chipaca> sergiusens: conflict :)
<sergiusens> Chipaca: you mean the alignment thing for members?
<sergiusens> Chipaca: conflict of what, interest?
<sergiusens> :-P
<Chipaca> sergiusens: changes to the same struct (for vendor and description)
<beowulf> sergiusens: uninstalling --> installed in status
<beowulf> sergiusens: next GET is 'uninstalled'
<sergiusens> beowulf: hmmm, let me check that
<beowulf> sergiusens: all other attributes are as 'uninstalled' (icon, download_size)
<beowulf> but the package status appears wrong until the next GET
<beowulf> so, mostly success :)
 * beowulf makes note to remove uninstall progress bar
<sergiusens> beowulf: I think I fixed that, pushing
<sergiusens> beowulf: pushed
<sergiusens> Chipaca: I did a bzr merge lp:snappy and no conflicts
<sergiusens> Chipaca: vendor and description has landed already though, right?
<Chipaca> sergiusens: but you marked your branch as depending on json-responses
<beowulf> sergiusens: wfm, +1
<Chipaca> sergiusens: so maybe it conflicts against that :)
<sergiusens> Chipaca: yeah, I merged it into this, that's why (so the view is nicer)
<Chipaca> sergiusens: right, but then i changed it and you didn't remerge i guess
<sergiusens> Chipaca: as in, I might have done it the hard way, but I started out with bzr branch lp:webdm; bzr merge lp:json-responses; work; push
<sergiusens> Chipaca: I'll remerge
<Chipaca> sergiusens: ... i dunno, dude :)
<Chipaca> sergiusens: json-responses now landed; beowulf's json-responses coming up
<beowulf> Chipaca: ack, almost done, but another meeting coming up
<beowulf> Chipaca: ignore :)
<beowulf> Chipaca: i have a follow up to better handle error messaging in the ui, is what i meant
<sergiusens> Chipaca: fix merge conflict, which is just the struct spacing
<Chipaca> srsly
<beowulf> s/better handle/fix
<sergiusens> Chipaca: and pushed
<sergiusens> Chipaca: https://code.launchpad.net/~sergiusens/webdm/snappyUpdateDeps/+merge/258406 there
<sergiusens> and beowulf ^ easy way to solve your go get misery ;-)
<Chipaca> sergiusens: http://bazaar.launchpad.net/~chipaca/webdm/filter-by-type/revision/119 ?
<Chipaca> sergiusens: +1'ed yours
<Chipaca> sergiusens: are there tests for allPackages, or should i just propose this as is?
<sergiusens> Chipaca: no, I failed to write tests that drive the handler; I need to do these asap
 * sergiusens adds missing :-/
<Chipaca> sergiusens: so, i should propose that as is?
<sergiusens> Chipaca: writing a test for this doesn't seem that hard, I can write some tests and propose against your MP
<sergiusens> MP/branch
<Chipaca> you write all those words, but all i'm reading is "YES!"
<Chipaca> https://code.launchpad.net/~chipaca/webdm/filter-by-type/+merge/258408
<Chipaca> mvo_: https://code.launchpad.net/~mvo/snappy/snappy-hashes-yaml-for-devices/+merge/258372 missing a commit messag
<Chipaca> mvo_: eam
<Chipaca> augh
<Chipaca> eam: nothing, sorry
<eam> :)
 * beowulf goes for food
<sergiusens> beowulf: how dare you!
<Chipaca> mvo_: needs-fixing'ed your branch
 * Chipaca apologises profusely
<lool> does someone have a recent apparmor template example for 15.04?
<lool> unconfined is what I'm looking for; syntax from earlier doesn't work anymore
<lool> complains about policy_groups
<sergiusens> Chipaca: are you going to add that phantomjs stuff to https://code.launchpad.net/~chipaca/webdm/www-tests/+merge/258331 ?
<mvo_> Chipaca: needs-fixing is fine, thanks for the review (hope its not uber stupid what I did wrong)
<mvo_> Chipaca: excellent review, I will look at this tomorrow, I was looking into gnu_dev_{major,minor} which uses long long as input but gnu_dev_makedev does indeed only take ints, I will fix :)
<sergiusens> Chipaca: btw, I now remember the namespace issue we created when removing the . for frameworks and oem packages and not saving that information anywhere https://code.launchpad.net/~chipaca/webdm/filter-by-type/+merge/258408
<sergiusens> mvo_: we have no local searching, do we? or is activesnapbynames a lazy match?
<Chipaca> sergiusens: sounds like you want to use snappy.Dirname(part) as the Name of the snapPkg
<Chipaca> sergiusens: klopt dat?
<sergiusens> Chipaca: I might have missed snappy.Dirname or maybe haven't payed attention
<sergiusens> Chipaca: my problem is more related to remotes
<Chipaca> sergiusens: snappy.Dirname returns the name for frameworks and oems, and name+namespace otherwise
<Chipaca> sergiusens: it's the name of the directory above the version tree
<Chipaca> thing
<sergiusens> Chipaca: everything is still an app until we reupload everything
<beuno> we could probably set it for you, if you super needed to
<beuno> but it'd be better not to have that inconsistency
<sergiusens> Chipaca: so for uninstalled apps/frameworks I don't know how it will land on the system to keep the resource name the same
<Chipaca> sergiusens: if things magically change names between them being on the store and being installed, everything is terrible :)
<sergiusens> Chipaca: so just disable that for now is my summary to avoid hacks
<sergiusens> Chipaca: they do ;)
<Chipaca> sergiusens: that == the commented out bit?
<Chipaca> ex-commented out
<Chipaca> ex-commented out-to be
<Chipaca> should now instead be ex-(ex-commented out-to be)-to be
<sergiusens> Chipaca: they do because we stripped out origin from installed fw and oem packages so we have to refer to packages in different ways
<sergiusens> origin == namespaces
<sergiusens> the inconsistencies in naming are getting crazy too
<Chipaca> yes, we need to address that
<Chipaca> post-iot :)
<Chipaca> sergiusens: pushed
<sergiusens> beuno: well, the inconsistencies exist until everyone reuploads anyways
<Chipaca> mvo_: *unsigned* long long, even then, fwiw
<sergiusens> Chipaca: can we do a ho in a bit?
<Chipaca> sergiusens: yes
<beowulf> Chipaca: sergiusens: tough one for you two https://code.launchpad.net/~stephen-stewart/webdm/nice-favicon
<beowulf> plus, https://code.launchpad.net/~stephen-stewart/webdm/json-error-responses/+merge/258402 and https://code.launchpad.net/~stephen-stewart/webdm/install-as-behaviour/+merge/258424
<Chipaca> beowulf: will get to those in a few
<beowulf> Chipaca: no rush, i'm going to eod unless you need something from me
<beowulf> Chipaca: also, i can take care of adding phantomjs to the www-tests branch tomorrow if you'd like
<Chipaca> beowulf: i'm lying in bed, eating a bit of ice cream and hoping i won't have to get up too many times to shaddup the boys. I could use somebody playing a guitar, but there's a segovia guy here who'll do
<sergiusens> beuno: can you force reparse all the store info so we get proper snap types?
<sergiusens> beowulf: there's a conflict in https://code.launchpad.net/~stephen-stewart/webdm/install-as-behaviour/+merge/258424
<beuno> sergiusens, not easily, no
<sergiusens> beuno: hmm; Chipaca, plan is dead
 * Chipaca takes out the war paint
 * beuno places a bulk order of thinner on amazon
<Chipaca> sergiusens: .more()
<sergiusens> Chipaca: I'll just implement it and then say it doesn't work because the store is returning the wrong result ;-)
<sergiusens> that would tickle some wounds :-P
<Chipaca> sergiusens: there ya go
<Chipaca> sergiusens: what's blocking this?
<sergiusens> Chipaca: knowing the types from the store, or the re parsing you mean?
<sergiusens> I don't know what blocks the re parsing
<Chipaca> sergiusens: oh, wait, the plan is dead because no reparsing?
<sergiusens> Chipaca: yeah
<mwenning> hi snappy guys, anyone know what happened to 'unconfined' in apparmor templates?
<mwenning> when I try to use it I get :
<mwenning> http://cdimage.ubuntu.com/ubuntu-snappy/15.04/edge/ubuntu-15.04-snappy-armhf-bbb.img.xz
<mwenning> no, sorry
<mwenning>  - security_template_valid (meta/linerate.apparmor)
<mwenning> 	(MANUAL REVIEW) 'unconfined' not allowed
<mwenning> Any help would be appreciated..
<sergiusens> Chipaca: if still alive https://code.launchpad.net/~sergiusens/snappy/storeSnapType/+merge/258437
<sergiusens> couple more piled up too
#snappy 2015-05-07
<beowulf> morning
<Chipaca> mo'in
<JamesTait> Good morning all; happy Roast Leg Of Lamb Day! ð
<Chipaca> why would you call something âxubuntu coreâ?
<Chipaca> gosh i'm grumpy today
<Chipaca> i think i'll have second breakfast
<Chipaca> not sure whether it'll help, but i'll have had second breakfast
<mvo_> hehe, enjoy!
 * mvo_ will have more tea that always works for me
<beowulf> Chipaca: hey, would you mind casting an eye over https://code.launchpad.net/~stephen-stewart/webdm/nobody-puts-baby-in-the-corner/+merge/258466
<beowulf> Chipaca: as you will see, i fail at bzr, it should be based on your branch butâ¦ i fail at bzring
<mvo_> beowulf: no worries, it will be git soon once we solve the tarmac problem
<beowulf> :)
<beowulf> Chipaca: oops, forgot to remove xvfb, change pushed
 * Chipaca looks
<Chipaca> hmmm
<Chipaca> ah, it ignores node_moudles anywhere, not just in www, ok :)
<Chipaca> mvo_: https://code.launchpad.net/~mvo/snappy/meta-cleanup/+merge/258467 ...?
<Chipaca> mvo_: forgot anything?
<mvo_> Chipaca: ups, sorry, indeed
<Chipaca> beowulf: getting several of these, are they expected?
<Chipaca> npm WARN unmet dependency undefined,
<Chipaca> npm WARN unmet dependency which is version undefined
<Chipaca> npm WARN unmet dependency /home/john/canonical/webdm/src/launchpad.net/webdm/node_modules/gulp-imagemin/node_modules/imagemin/node_modules/imagemin-pngquant/node_modules/pngquant-bin/node_modules/bin-build/node_modules/decompress/node_modules/decompress-unzip/node_modules/strip-dirs/node_modules/sum-up requires chalk@'^1.0.0' but will load
<Chipaca> beowulf: that's a lot of node_modules
<ogra_> lool, isnt your ramdisk_size= cmdline option a bit small ? that defines the size of the unpacked ramdisk IIRC ...
<mvo_> Chipaca: I think there is a umask issue in CopyFile, i.e. snappy build with a 777 dir will not create a 777 dir in the snap, I look at this after lunch, just fyi that I stumbled over this
<lool> ogra_: that might be
<beowulf> Chipaca: you can ignore the warnings
<mvo_> Chipaca: had fun this morning with preparing for the OS snap stuff :)
<Chipaca> mvo_: :)
<Chipaca> mvo_: CopyFile doesn't create dirs tho
<lool> ogra_: I also didn't really know how to chose it's location
<lool> I tried closer to the end of the RAM, but that failed for some reason
<lool> and before linux or just after it and that gets clobbered
<ogra_> well, it finds it obviously
<ogra_> oh
<lool> I can try with a larger size
<ogra_> well ...
<sergiusens> morning
<ogra_> it seems to override your setting actually
<ogra_> Kernel command line: "earlyprintk=ttyMFD2 root=/dev/disk/by-label/system-a console=ttyMFD2 init=/lib/systemd/systemd ro ramdisk_size=50000"
<ogra_> vs
<ogra_> [    0.000000] Kernel command line: earlyprintk=ttyMFD2 root=/dev/disk/by-label/
<ogra_> system-a console=ttyMFD2 init=/lib/systemd/systemd ro ramdisk_size=19333091
<ogra_> thats weird
<lool> ogra_: actually this is me failing to update the first copy-paste
<ogra_> ah, k
<lool> but 19333091 is still wront (compressed instead of uncompressed)
<ogra_> it is kB ...
<lool> so that's more than enough then
<ogra_> right
<ogra_> red herring
<lool> that's too much in fact
<ogra_> it is a bit much, but i would expect the kernel to catch that ... should still unpack
<Chipaca> sergiusens: mo'i
<Chipaca> sergiusens: n
<beowulf> Chipaca: er, yeah, tarmac has no npm/node
<sergiusens> beowulf: one second
<sergiusens> beowulf: try again
<sergiusens> Chipaca: did you get to see my MPs
<sergiusens> ?
<Chipaca> sergiusens: no
<mvo_> Chipaca: heh, indeed
<sergiusens> @reviewlist
<nothal> https://code.launchpad.net/~chipaca/ubuntu-core-launcher/unshare/+merge/258367 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~sergiusens/webdm/filterInstalled/+merge/258440 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~sergiusens/webdm/originNamespacesInconsistencies/+merge/258438 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/install-as-behaviour/+merge/258424 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~chipaca/webdm/filter-by-type/+merge/258408 | Needs Fixing: 1 (less than a day old)
<Chipaca> sergiusens: helping rvba right now, will look at them in a few
<Chipaca> sergiusens: top-approve https://code.launchpad.net/~sergiusens/snappy/storeSnapType/+merge/258437 ?
<sergiusens> Chipaca: I would, but it's my own MP :-)
<Chipaca> @reviewlist
<nothal> https://code.launchpad.net/~chipaca/ubuntu-core-launcher/unshare/+merge/258367 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/nobody-puts-baby-in-the-corner/+merge/258466 | Approve: 1 (less than a day old)
<nothal> https://code.launchpad.net/~sergiusens/webdm/originNamespacesInconsistencies/+merge/258438 | Approve: 1 (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/install-as-behaviour/+merge/258424 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~chipaca/webdm/filter-by-type/+merge/258408 | Needs Fixing: 1 (less than a day old)
 * beowulf checks out lp:~chipaca/webdm/filter-by-type
<Chipaca> beowulf: that's missing a thing
 * Chipaca waits for sergiusens' branches to land so he can merge, and will then add the thing
<beowulf> Chipaca: what thing? the curl in the comments isn't correct, i believe
<Chipaca> beowulf: dunno, but the comment of what is missing is correct; there's one path i'm not filtering on
<beowulf> Chipaca: ack
<beowulf> Chipaca: would you look again at https://code.launchpad.net/~stephen-stewart/webdm/nobody-puts-baby-in-the-corner/+merge/258466
<beowulf> i missed the paths in gulpfile.js
<beowulf> and then i need to use all the nice new filters and data
<Chipaca> beowulf: that also might not work. but let's give it a go.
<beowulf> exciting
<Chipaca> beowulf: when you said the GET in https://code.launchpad.net/~chipaca/webdm/filter-by-type/+merge/258408 wasn't right, do you have a 'right' one?
<beowulf> Chipaca: it would be something like /api/v2/packages?types[]=app&types[]=core
<beowulf> /api/v2/packages/?types[]=app&types[]=core
<beowulf> Chipaca: as a query rather than in the body
<Chipaca> beowulf: h,, that's not what the docs say tho
<beowulf> Chipaca: which docs?
<Chipaca> mvo_: sergiusens: can seccomp be disabled?
<Chipaca> beowulf: sergiusens has a gist somewhere, give me a sec
<Chipaca> beowulf: https://gist.github.com/sergiusens/15949095c52a83a46c6b
<beowulf> Chipaca: right, so i don't think sergiusens meant for it to be in the body, it should be a query
<beowulf> Chipaca: see https://code.launchpad.net/~sergiusens/webdm/filterInstalled
<beowulf> Chipaca: see also https://groups.yahoo.com/neo/groups/rest-discuss/conversations/messages/9962
<Chipaca> beowulf: ah, fair enough. I'm planning on waiting for that to land and then merging with it, so i'll do the right thing anyway
<Chipaca> beowulf: if that is âsending a body with a GET is a horribly idea that should die in hellâ, i don't need to read it
 * Chipaca looks
<beowulf> Chipaca: then you don't need to read it
<Chipaca> :)
<Chipaca> body on GETs are the âoh and here are some pictures of my kids, aren't they cuteâ of REST
<beowulf> the only people that care are the owners
<mvo_> Chipaca: yes, just put @unrestritcted in the custom seccomp file
<mvo_> sergiusens, Chipaca: btw, can I/should I help with webdm too?
<Chipaca> mvo_: looking at this package's yaml, it's http://pastebin.ubuntu.com/11008516/
<Chipaca> mvo_: AIUI the 'integration' thing is the older way, and a better way would be to have the apparmor under the service, is that right?
<mvo_> Chipaca: is there a bzr branch that I could use to tweak it?
<Chipaca> mvo_: and the seccomp goes next to it when under the service, but is not supported under integration
<mvo_> Chipaca: yeah, we should not integration for apparmor anymore though,  should be fine to put that under service
 * Chipaca nods
<mvo_> Chipaca: what does the apparmor look like? json or a hand-craftet profile?
<beowulf> Chipaca: would you mind bouncing https://code.launchpad.net/~stephen-stewart/webdm/install-as-behaviour/+merge/258424
<Chipaca> mvo_: json
<Chipaca> beowulf: bounce
<mvo_> Chipaca: ok, security-override:\n  apparmor: ...\nseccomp should do it
<Chipaca> mvo_: and the seccomp file would just be â@unrestrictedâ?
<mvo_> Chipaca: yes, let me quickly double check, its not documented in meta/security.md (yet) - needs fixing :P
<mvo_> Chipaca: yes, @unrestricted shoudld work
<mvo_> sergiusens: was there anything pending in the install.yaml MP btw? I guess we just need to decide if its 15.04 material but I guess it is(?)
 * beowulf goes for lunch, then to pick a horse
<Chipaca> mvo_: so, the seccomp file should be yaml. do you have an example of how to put that @unrestricted in there?
<mvo_> Chipaca: uhhh, I hope jdstrand has a answer if he is up, if not I check the source now
<Chipaca> mvo_: maybe that's the template?
<mvo_> Chipaca: yeah, I think so
<mvo_> Chipaca: "template: unrestricted"
<mvo_> Chipaca: does that work?
<Chipaca> i'll try :)
<Chipaca> it's slow tho
<sergiusens> Chipaca: I fixed the MP but not the docs last night
<Chipaca> sergiusens: which em pee?
<Chipaca> sergiusens: assuming you mean the one about the id
<Chipaca> hmm, why isn't https://code.launchpad.net/~mvo/snappy/snappy-tar-unpack-mknod/+merge/258407 landing?
<sergiusens> Chipaca: dep?
<sergiusens> Chipaca: the MP I fixed is the types, installed_only one
<mvo__> Chipaca: I think deps, I fixed the dep I think
<Chipaca> mvo__: dep is merged
<Chipaca> mvo__: unless that's happened *just* now :)
<mvo__> ha! you are right (of course)
 * mvo__ throws his hands up helplessly
 * Chipaca makes a note to not be right, because it makes mvo quit
<mvo> Chipaca:lol
<mvo> Chipaca: looks like its time to inspect what tarmac is doing
<beowulf> what's the current status of webdm?
<Chipaca> beowulf: http://i.imgur.com/F6mBAWi.gif
<beowulf> good good
<sergiusens> mvo: you had access to tarmac, so feel free to login and mess around
<sergiusens> unless you want me to
<sergiusens> beowulf: maybe for this https://code.launchpad.net/~stephen-stewart/webdm/handle-missing-response-in-parse/+merge/258518
<sergiusens> beowulf: can you tell me what it's expecting in order to fix?
<beowulf> sergiusens: i'm getting errors on install or uninstall, 400s, the response is always of the form {"package":"8nzc1x4iim2xj1g2ul64","message":"Operation in progress"}
<sergiusens> beowulf: are you sending a PUT twice?
<sergiusens> beowulf: maybe you need my branch which is taking too long to land
<sergiusens> beowulf: your fix is fine for the just to be safe case
<beowulf> sergiusens: no, don't think so... yes i think i need your branch
<genii> -uos-core or -uos-showandtell or some other for questions? They are reading off questions that I do not see in uos-core for instance
<sergiusens> genii: -uos-core
<sergiusens> I see all questions there
<genii> Hm
<genii> OK, thanks
<sergiusens> beowulf: hey, I see you moved the npm/gulp stuff, does the readme need updating though?
<sergiusens> beowulf: I tripple checked and the only way to get that answer you got is if you do a PUT and a DELETE while the PUT is taking place
<Chipaca> sergiusens: can haz re-review of https://code.launchpad.net/~chipaca/webdm/filter-by-type/+merge/258408 ? now that your thing landed an' all :)
<sergiusens> Chipaca: /me tries
<sergiusens> Chipaca: heh, the diff only goes all the way to r120 but there's r122... oh well :-)
<Chipaca> hm?
<Chipaca> sergiusens: i'm seein 122 here
<sergiusens> Chipaca: refresh again ftw :-)
<Chipaca> :)
<beowulf> sergiusens: i think i did update the readme
<beowulf> sergiusens: i'm going to rebuild latest and try again
<sergiusens> beowulf: good
<sergiusens> beowulf: if you wait a bit you will get filtering by types btw
<beowulf> sergiusens: then i will break for dinner and try later
<sergiusens> beowulf: maybe don't ask for the oem ones
<sergiusens> beowulf: so in the installed list, list it, in the store listing keep it out
<beowulf> sergiusens: i can also hide install buttons for any types you want to show but not allow install
<beowulf> and i notice that uninstall removes the item in the store listing, i need to fix that
<genii> asac: It's a gcc switch will will embed into the binary all the compiler options that were used when it was built
<sergiusens> beowulf: make that the oem packages then ;)
<asac> genii: ic. don think we recommend anything like that. the app author is in charge and can make such decisions as it suites him best
<asac> dont
<genii> asac: So it then becomes possible for instance to compare those between two binaries
<asac> genii: who would that help?
<genii> OK, thanks
<asac> if its a thing that app author likes then he can use it... for sure :)
<genii> asac: It would help if a particular option for instance is problemmatic
<asac> but as i said in the q+a we try to be as rigorous in empowering the app author to be in charge to make the decisions for his apps that he needs to do
<asac> genii: yeah. could be that at some point we will have like tools available that make live of developers easier
<asac> if they have such option
<asac> but so far nothing like that is planned. we are just getting started to really think how to support app authors more :)
<Chipaca> sergiusens: a quick one: https://code.launchpad.net/~chipaca/snappy/snappy-tar-pack-mknod/+merge/258536
<sergiusens> Chipaca: ok
<sergiusens> Chipaca: here's one for you https://code.launchpad.net/~sergiusens/webdm/avahi/+merge/258539
<Chipaca> sergiusens: this is a long-lived thing, yes?
<Chipaca> as per the "loop forever"
<Chipaca> sergiusens: in which case, better make a timer and reuse it in the loop, instead of creating one over and over
<sergiusens> Chipaca: yes, loopForever is a better func name I guess
<sergiusens> Chipaca: it's my layman approach to change the hostname if changed somewhere
<Chipaca> sergiusens: that's fine
<Chipaca> sergiusens: what i'm saying is
<Chipaca> don't do time.After(blah)
<Chipaca> in a loop
<Chipaca> rather, create a timer outside the for
<Chipaca> and set it in the loop
<Chipaca> a silly change
<sergiusens> Chipaca: ok
<sergiusens> Chipaca: added one comment, not sure how to phrase it better though
<bjf> where does uEnv.txt come from? i'm trying to create a beaglebone black image and it's failing to boot because that file is missing
<sergiusens> bjf: the oem snap
<sergiusens> during provisioning
<bjf> sergiusens, i'm using: sudo ubuntu-device-flash core 15.04 -o bbb.img --size 4 --channel edge --oem beagleblack --enable-ssh --device-part=device.tar.xz
<sergiusens> bjf: strange, it should be in your system-boot partition then
<sergiusens> bjf: can you check?
<bjf> sergiusens, system-a/boot/uboot ?
<sergiusens> bjf: oh, you have a running system?
<sergiusens> system-boot is the label you need to look for
<bjf> sergiusens, no i'm looking at the sd card
<sergiusens> bjf: partition 1, called snappy-boot or something boot
<bjf> sergiusens, indeed, that is there but when my bbb boots i get "** Unable to read file uEnv.txt **"
<sergiusens> bjf: is the file corrupted?
<sergiusens> Chipaca: updated MP for avahi
<bjf> sergiusens, no, it looks correct
<Chipaca> sergiusens: um
<Chipaca> sergiusens: that won't work
<Chipaca> i don't think
<Chipaca> sergiusens: yeah, that's not what you want
<sergiusens> Chipaca: it does work fwiw
<Chipaca> sergiusens:  https://play.golang.org/p/gUA2uOEehv
<sergiusens> Chipaca: interesing, so what did I want?
<sergiusens> Chipaca: as in, what were you asking for? It felt strange, but I just went with it; is it for _ := range time.After... { or something like that?
<Chipaca> sergiusens: https://play.golang.org/p/b62amWnQu8
<sergiusens> Chipaca: oh, more words is what you want :-P
<Chipaca> sergiusens: or, do the reset before the <-t.C if you want the wait to be at least the timeout
<Chipaca> otherwise the wait will be the timeout - however much the func took
<sergiusens> Chipaca: the playground doesn't like your code though :-P
<Chipaca> heh
<Chipaca> try it locally
<sergiusens> Chipaca: I am, I was joking
<sergiusens> as in there are trolls on the playground :-P
<sergiusens> Chipaca: there
<sergiusens> hmm
<sergiusens> now
<sergiusens> beowulf: are we waiting for any tasty MPs today still?
<beowulf> sergiusens: i added install/uninstall to the store listing in haste, and it's slightly broken in that it removes the item from the list currently, so i'm trying to fix that now
<beowulf> sergiusens: other than that i have a couple of mps to tidy little things but they're more likely tomorrow now
<sergiusens> beowulf: darn; I didn't notice that
<beowulf> it's annoying
<sergiusens> it is, just saw
<Chipaca> sergiusens: pushed https://code.launchpad.net/~chipaca/snappy/snappy-tar-pack-mknod/+merge/258536
<Chipaca> sergiusens: let me know if context switching is driving you (more) bonkers
<beowulf> sergiusens: https://code.launchpad.net/~stephen-stewart/webdm/destroy-without-removal/+merge/258547
<sergiusens> Chipaca: heh, it does at times, but I feel more relaxed now than earlier today
<bjf> sergiusens, i just built a new image on Trusty and it boots just fine. images build using vivid fail. i've done an intial comparison of the two images and don't see any difference
<sergiusens> Chipaca: ping my avahi :-)
<sergiusens> bjf: I'm not sure how that is, lots of people use vivid here and the code is pretty much generic
<sergiusens> bjf: maybe a dd fail?
<bjf> sergiusens, this _is_ a different system Trusty is desktop and Vivid is macbook air
<Chipaca> sergiusens: trade you my https://code.launchpad.net/~chipaca/snappy/snappy-tar-pack-mknod/+merge/258536
<sergiusens> beowulf: it still dissappears here with your branch
<sergiusens> Chipaca: ok
<sergiusens> Chipaca: there's also the backporting one to calm down asac ;-)
<beowulf> sergiusens: sure?
 * beowulf needs to write tests
<sergiusens> beowulf: mostly
 * beowulf laments that isn't likely tonight
<sergiusens> beowulf: does it work for you?
<beowulf> sergiusens: switching back to checjk :)
<beowulf> sergiusens: works for me
<beowulf> i kinda love installing and uninstalling :)
<sergiusens> beowulf: hmmm, let me do something here
<sergiusens> beowulf: for some reason it needed a browser refresh, it's fine
<beowulf> also, errors trigger an error view but if you were to get >1 error the first would be clobbered, so that's something to fix later
<beowulf> possible on the store view, as it allows multiple install/uninstalls
<sergiusens> beowulf: you shouldn't be able to get more errors in theory
<sergiusens> beowulf: right, I need to lock that down deep inside
<beowulf> sergiusens: well, you could install 3 things and they could all error
<beowulf> it would be correct for them to report an error each
<beowulf> no?
<sergiusens> beowulf: right, but we should only support installing in sequence, so I need to queue your requests
<beowulf> sergiusens: i see
<beowulf> sergiusens: that makes it less likely
<sergiusens> beowulf: we had this talk returning from downtown Austin with Chipaca if you can recall :-)
<beowulf> oh yeah
<beowulf> good times
<sergiusens> beowulf: I don't recall it being an easy sprint though once Monday hit the door :-P
<beowulf> sergiusens: https://code.launchpad.net/~stephen-stewart/webdm/fix-snap-routing/+merge/258554
<beowulf> https://code.launchpad.net/~stephen-stewart/webdm/hide-installer-for-oem
<sergiusens> beowulf: yeah look at those now
<sergiusens> beowulf: you can type @reviewlist now at any given moment and save yourself from copy paste ;-)
<sergiusens> @reviewlist
<nothal> https://code.launchpad.net/~chipaca/ubuntu-core-launcher/unshare/+merge/258367 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/fix-snap-routing/+merge/258554 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/hide-installer-for-oem/+merge/258553 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~sergiusens/snappy/backportReviewNOT/+merge/258549 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~chipaca/snappy/snappy-tar-pack-mknod/+merge/258536 | Approve: 1 (less than a day old)
<beowulf> like i'd give Chipaca the limelight
 * sergiusens needs coffee
 * genii delivers one to sergiusens
<Chipaca> man, we need nothal to do that
 * Chipaca makes a note to add a plugin
<genii> Heh :)
<sergiusens> thanks
<sergiusens> meh, tarmac slow again
<sergiusens> beowulf: what does fix routing do? does it fix the pressing back thing being broken?
<beowulf> sergiusens: hard reload of snap page was broken
<sergiusens> beowulf: right, that too
<beowulf> sergiusens: back button broken?
<sergiusens> beowulf: maybe we need to change that 'name' to something else to not confuse it with name
<beowulf> sergiusens: yeah
<beowulf> sergiusens: so name there is /snap/$name
<beowulf> id would be better
 * beowulf changes
<sergiusens> beowulf: that should be the new 'id'
<beowulf> sergiusens: pushed
<sergiusens> great
<Chipaca> sergiusens: should i top-approve after ading the cosmic space?
<Chipaca> spaaaace
<sergiusens> Chipaca: yeah
<sergiusens> of course
<Chipaca> made sense to me, but not sure if you or mvo had a similar mp sitting there for ages because you wouldn't top-approve your own thing
<sergiusens> beowulf: last cool one would be for installed_only to work on the main page
<beowulf> sergiusens: one sec
<beowulf> sergiusens: https://code.launchpad.net/~stephen-stewart/webdm/installed-only/+merge/258559
<sergiusens> beowulf: looks legit, darn trailing '/' ...
<sergiusens> beowulf: set for review maybe?
<beowulf> sergiusens: done
<beowulf> hmm, webdm has a different sized icon...
<sergiusens> beowulf: heh, do you feel like finding a better icon?
<sergiusens> beowulf: can we make the webdm uninstallable too? meybe it needs some thought; but accidentally uninstalling may be a problem
<beowulf> sergiusens: sure
<beowulf> sergiusens: ubuntu-core too?
<sergiusens> beowulf: it is uninstallable in itself at the core of everything so it's fine to leave it
<beowulf> sergiusens: well, i think it's a bit confusing to have the button there so i added it to the list
<beowulf> you can reject the mp :)
<sergiusens> beowulf: whatever makes it easier on the user
<sergiusens> beowulf: you should ask clurr, not me :-P
 * beowulf invokes clurr
<beowulf> https://code.launchpad.net/~stephen-stewart/webdm/webdm-uninstallable/+merge/258560
<sergiusens> \o/
<beowulf> sergiusens: i guess you're aiming to publish webdm tonight?
<beowulf> sergiusens: will you be publising again before iot?
<sergiusens> beowulf: I aim for tonight
<sergiusens> maybe tomorrow
<sergiusens> a new version
<sergiusens> beowulf: I'm off next week
<sergiusens> beowulf: any dandy icon for webdm we want to use?
<beowulf> sergiusens: umm
<sergiusens> beowulf: you complained :-)
<beowulf> give me 1 min
<sergiusens> beowulf: do you know of a way to fix all our broken SVGs? as in just get proper svgs for the broken things we have?
<beowulf> sergiusens: if you give me the svgs i can convert them
<sergiusens> beowulf: one sec
<sergiusens> beowulf: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files
<sergiusens> beowulf: you can get an MP as well :-)
<beowulf> sergiusens: i don't see any ubuntu logos i can repurpose for webdm, and i don't really want to spend time inventing something that won't be acceptable, so what we have will do :)
<sergiusens> beowulf: also, ignore the element14 one
<sergiusens> beowulf: the high five one?
<beowulf> https://design.ubuntu.com/wp-content/uploads/pictogram-developer-orange-hex.svg
<beowulf> maybe that one?
<beowulf> for webdm
<sergiusens> beowulf: sure, looks good, will that render fine without conversion?
<beowulf> heh
<beowulf> because i don't yet understand that problem, i can't answer
<beowulf> let me give you a png of that
<sergiusens> beowulf: with store dimmension requirements?
<beowulf> yes
<sergiusens> beowulf: https://code.launchpad.net/~stephen-stewart/webdm/webdm-uninstallable/+merge/258560
<beowulf> sergiusens: https://drive.google.com/open?id=0B_entiKC77dtUWlzZFdkLWFRRVU&authuser=1
<sergiusens> beowulf: merge conflicts on that one
<beowulf> criss cross merge
<beowulf> sergiusens: should i just change these to png, in snappy examples?
<sergiusens> beowulf: yeah, just make sure package yaml points to the right file name
<sergiusens> Chipaca: not sure adding npm/node test stuff was such a good idea without doing some load analysis
<beowulf> serTABTABTAB
<beowulf> https://code.launchpad.net/~stephen-stewart/+junk/snappy-examples
<Chipaca> beowulf: why not an mp?
<beowulf> Chipaca: i am not one of you
<Chipaca> beowulf: fair enough
<Chipaca> beowulf: you'd be good at it hto
<Chipaca> tho*
<beowulf> Chipaca: i'd only make you all learn css
<Chipaca> i'd put you in charge of idiot population control
 * Chipaca 's government might stretch the definition of "democracy"
<beowulf> hehe
<Chipaca> sergiusens: when tarmac says âThere are additional revisions which have not been approved in review. Please seek review and approval of these new revisions.â, it's talking about top approval. Even when the times are off.
<sergiusens> Chipaca: I just turned off and upgraded the do droplet for 10 more dollars :-)
<sergiusens> Chipaca: let's try again
<Chipaca> we're using a droplet?
<sergiusens> Chipaca: yes
<sergiusens> Chipaca: https://code.launchpad.net/~sergiusens/webdm/newIcon/+merge/258571
<Chipaca> sergiusens: <beowulf> serTABTABTAB
<Chipaca> <beowulf> https://code.launchpad.net/~stephen-stewart/+junk/snappy-examples
<sergiusens> uhh
<sergiusens> lol
<sergiusens> beowulf: hey!
<sergiusens> beowulf: how about an MP and not junk but push to lp:~ss/snappy-hub/newIcons?
<beowulf> sergiusens: https://code.launchpad.net/~stephen-stewart/snappy-hub/newIcons
<sergiusens> beowulf: thanks
<beowulf> sergiusens: while all of the icons were svgs, they were svgs with the payload being a png, so kinda pointless
<sergiusens> beowulf: huh?
<sergiusens> beowulf: oh, only when fetching from the store
<sergiusens> beowulf: once installed we use the icon that's there
<sergiusens> beowulf: the store does a server side conversion which I disagree with
<beowulf> sergiusens: i mean the old svgs, they were svgs wrapping pngs, you can see in the diff
<beowulf> i don't think the store converts pngs to svgs
<sergiusens> beowulf: no, the other way around svg->png
<beowulf> well, that's actually a good thing
<sergiusens> beowulf: not really as the information gets split in to locations to search for
<sergiusens> beowulf: can you try installing hello-world.canonical on your webdm and see if you get a better icon?
<beowulf> yeah, but without spending a lot of time parsing svg for script blocks and whatnot, converting to png is a good solution for now
<beowulf> sergiusens: yeah, icon works (slighly different scale, but that's my fault...)
<beowulf> forgot the store icon would remain unchanged
<sergiusens> beowulf: want to redo?
<sergiusens> beowulf: or maybe just work out broken svgs
<beowulf> don't think it's a big deal
<sergiusens> beowulf: ack
<sergiusens> beowulf: any idea what this is?
<sergiusens> /home/tarmac/tmp/tmp.IAGqDnv6Vd/src/launchpad.net/webdm/node_modules/browserify/node_modules/module-deps/node_modules/through2/node_
<Chipaca> sergiusens: more tarmac woes?
<sergiusens> modules/readable-stream requires inherits@'~2.0.1' but will load
<sergiusens> Chipaca: nope, npm ones now
<sergiusens> Chipaca: I don't see any branch that should be merged except the avahi one :-/
<Chipaca> sergiusens: i saw those node_modules/node_modules/etc, apparently that's normal
<Chipaca> beowulf dixit
<sergiusens> Chipaca: right, but it just stops there...
<sergiusens> Chipaca: maybe it overflows the mp comment thingie
<Chipaca> npm WARN unmet dependency undefined,
<Chipaca> npm WARN unmet dependency which is version undefined
<sergiusens> Chipaca: and maybe we need to >/dev/null the npm install part
<beowulf> can you pastening the whole thing?
<beowulf> pastebin
<beowulf> dear fingers, what?
<Chipaca> beowulf: https://code.launchpad.net/~sergiusens/webdm/avahi/+merge/258539/comments/645395/+download
<beowulf> npm and nodejs version?
<sergiusens> beowulf: beowulf npm                                 1.3.10~dfsg-1
<beowulf> remove the npm update line from build.sh
<Chipaca> {"node":"v0.10.25","npm":"1.3.10"}
<beowulf> oh
<sergiusens> beowulf: ii  nodejs                              0.10.25~dfsg2-2ubuntu1               amd
<sergiusens> oh what?
<sergiusens> Chipaca: but it only fails with this mp
<beowulf> i thought npm was going to be lower...
<sergiusens> so I think I'm just not getting the information I need
<sergiusens> going to merge trunk
<beowulf> is the tail of that missing?
<sergiusens> beowulf: I suspect so, yes, so I'm sending npm install to dev/null, it's too verbose
<sergiusens> beowulf: does it have a quiet option if not?
<beowulf> sergiusens: well, that's what happens when your packages must contain all their deps...
<beowulf> sergiusens: -q ,it seems
<beowulf> --loglevel error
 * beowulf tries, rather than cnping from docs
<beowulf> sergiusens: 'npm i --loglevel error' seems pretty quiet
<sergiusens> beowulf: trying
<sergiusens> beowulf: ok, all problems fixed
<sergiusens> Chipaca: I want you to see what needed fixing
<sergiusens> please
<Chipaca> sergiusens: say agian?
<sergiusens> Chipaca: fyi http://bazaar.launchpad.net/~sergiusens/webdm/avahi/revision/140
<sergiusens> Chipaca: I don't know why this didn't show when I ran it locally initially though :/
 * sergiusens wants git more and more
<Chipaca> sergiusens: i think that means you get to make the first cake
<sergiusens> Chipaca: it does indeed, but making npm run quietly seems to make it faster too
<beowulf> i want to remove the image tasks, they pull in a lot of stuff and i don't think they should be run as a watch/deploy task, more as a manual task
<beowulf> that will speed up npm instal
<sergiusens> beowulf: sounds good to me
<Chipaca> guys and gals, that's all from me today
<Chipaca> p/
<sergiusens> Chipaca: thanks for everything
<sergiusens> beowulf: too btw
<sergiusens> lots of good stuff got in :-)
<beowulf> o/
#snappy 2015-05-08
<dholbach> good morning
<Halacs> hi
<Halacs> morning
<Halacs> somebody know where are can find a snappy ubuntu core iso to install it my bare metal servers? BTW what is the difference between snappy ubuntu core and ubuntu core (without snappy)?
<Halacs> I try to ask, but I am affraid everybody is sleeping right now
<JamesTait> Good morning all; happy Friday, and happy No Socks Day! ð
<tbr> Halacs: just a new user, but afaiu just core is deb based, while snappy core has all that stuff for app separation etc and no debs
<tbr> Halacs: if your bare metal machine has traditional BIOS, then you can just use the x86_64 image
<tbr> Halacs: if it only has UEFI, then you'll have to wait until they fix that
<tbr> and by 'just use the image' I mean you can just dd it to a drive
<Halacs> I have an IBM Balde Center H, and to be honest, currently I dont know whether is is UFI or not, but I will try this
<Halacs> but, could you give me a link for the image you mentioned?
<Halacs> just for sure
<tbr> http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-amd64-generic.img.xz
<Halacs> thanks tbr!
<tbr> just uncompress & write that to a disk or a usb device and boot it
<Halacs> okay, thanks, I will try it
<dduffey> anyone have a dhcp-server snap app?
<ogra_> dduffey, i would take a look at webdm ... not dhcp but avahi ...
<ogra_> shouldnt be hard to deduct how to roll a dhcp server snap from that
<dduffey> ogra_, what I want to do is setup a small snappy dhcpd server so all my other snappy devices will get an IP address from that server
<dduffey> ogra_, ah, I see
<utlemming> do we have an apparmor guide to debugging on Snappy? I'm having problems with NodeJS not playing well.
<alecu> sergiusens: hi! is the webdm package only released on armhf? I can't find it with "snappy search" on my amd64 kvm
<alecu> Chipaca: too ^
<Chipaca> alecu: it's only released for rolingas
 * alecu gets a new haircut
<alecu> Chipaca: how can I enable rolingas?
<alecu> is it a separate channel, or an installation option....
<Chipaca> alecu: not sure whether you can easily switch; at image creation time, it's something like: sudo ubuntu-device-flash core rolling --channel edge --output 386.img --developer-mode --enable-ssh --device generic_i386
<alecu> great, thanks.
<alecu> kyrofa: ^
<alecu> Chipaca: no luck. I created the image with that command, booted it in kvm, but still snappy search can't find webdm
<alecu> Chipaca: I check the channel.ini, and it says:
<alecu> channel: ubuntu-core/rolling/edge
<alecu> any ideas?
<beuno> maybe it's only available for armhf?
 * beuno looks
<beuno> Supported architectures:
<beuno>     64-bit x86, ARM
<beuno> so no
<beuno>  Supported releases:
<beuno>     rolling-core
<sergiusens> alecu: I have no idea why you can't find it.
<sergiusens> alecu: https://search.apps.ubuntu.com/api/v1/package/webdm
<sergiusens> beuno: did me pushing a new version for only rolling automatically unpublish 0.5 for 15.04? It was one of the things I wanted to test
<beuno> sergiusens, it did, because the store only shows one version of an app atm
<sergiusens> beuno: is that by design?
<sergiusens> or just something missing?
<beuno> sergiusens, by design originally, and now that's changed with snappy
<beuno> so there's an item in the backlog to change that
<sergiusens> beuno: that's fine then, or else we will be living confusing times
<sergiusens> beuno: I guess I can just tick 15.04 then or else I'll get a bunch of people asking for the link
<beuno> today you wouldn't be able to install a specific version, for example
<beuno> sergiusens, indeed
<beuno> we'll have channels soon to allow you to do releases better  )
 * sergiusens creates an image from scratch to see if he sees what alecu is seeing
<sergiusens> beuno: \o/
<alecu> sergiusens: I used the cmdline that chipaca pasted earlier, then started it with:
<alecu> kvm -m 768 -redir :8090::80 -redir :8022::22 386.img
<alecu> then I sshd into it, sudo snappy update, snappy search
<sergiusens> alecu: you don't need to run update to search though ;-)
<alecu> sergiusens: I tried search first, and when it didn't find anything I muscle memoried apt-get update
<alecu> but I see what you mean
<sergiusens> alecu: alias kvm_snappy
<sergiusens> alias kvm_snappy='kvm -m 1500 -redir :8022::22 -redir :8080::8080 -redir :4200::4200'
<sergiusens> that's what I use ;-)
<alecu> nice
<sergiusens> alecu: I can't reproduce http://paste.ubuntu.com/11026375/
<sergiusens> just created a fresh image
<beowulf> boo
<sergiusens> alecu: I know, Chipaca told you to create an i386 image; there's no webdm for 386!
<alecu> sergiusens: what command did you use to create it?
<alecu> ah!
<beowulf> my snappy as vmware image workflow seems to be broken now :(
<sergiusens> alecu: sudo ubuntu-device-flash core rolling --output amd64.img --developer-mode --channel edge
<sergiusens> beowulf: how so?
<alecu> sergiusens: I'll try that, thanks a bunch!
<sergiusens> np
<alecu> sergiusens: you don't use "--enable-ssh"?
<beowulf> sergiusens: converting i get a error message/warning: http://pastebin.ubuntu.com/11026387/
<beowulf> sergiusens: and vmware fails to ubuntu-core boot with that vmdk
<beowulf> PXE-E53: No boot filename received
<sergiusens> beowulf: you are seeing kpartx issues
<sergiusens> beowulf: clear the mappings (quickest is to reboot ubuntu)
<beowulf> sergiusens: does that make me special? do i get a badge
<beowulf> sergiusens: yes, I'll reboot ubuntu.... *whistles*
<sergiusens> @reviewlist
<nothal> https://code.launchpad.net/~chipaca/ubuntu-core-launcher/unshare/+merge/258367 | No reviews (1 day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/disabled-install-buttons-for-oem-types/+merge/258621 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~jamesodhunt/snappy/install.yaml/+merge/256925 | Needs Information: 1, Needs Fixing: 1 (16 days old)
<sergiusens> beowulf: added a comment to your MP
<beowulf> sergiusens: good spot, ta
<sergiusens> beowulf: Chipaca https://code.launchpad.net/~sergiusens/webdm/queryPackageNames/+merge/258639
<sergiusens> hmmm
 * sergiusens resubmits
<beowulf> sergiusens: you want me to take that and put search back?
<beowulf> sergiusens: which might not happen today, as i'm still trying to get a working ubuntu-core
<sergiusens> beowulf: no worries, I also have an improvement to make to that MP
<Chipaca> @reviewlist
<nothal> https://code.launchpad.net/~chipaca/ubuntu-core-launcher/unshare/+merge/258367 | No reviews (1 day old)
<nothal> https://code.launchpad.net/~sergiusens/webdm/queryPackageNames/+merge/258640 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~jamesodhunt/snappy/install.yaml/+merge/256925 | Needs Information: 1, Needs Fixing: 1 (16 days old)
<beowulf> sergiusens: know what this means? http://pastebin.ubuntu.com/11027355/
<sergiusens> beowulf: do you have the latest snappy?
<sergiusens> beowulf: how did this all start to happen?
<sergiusens> mvo: ideas? ^
<beowulf> sergiusens: on 14.04 i did udf, and vmware couldn't but the vmdk build from that img, so i've upgraded... and now i see this
<sergiusens> beowulf: trusty?
<beowulf> now on 15.04
<sergiusens> oh
<beowulf> sergiusens: which ppa should i be using?
<sergiusens> beowulf: snappy-dev/tools
<Chipaca> jdstrand: hullo hullo hullo!
<jdstrand> Chipaca: hi!
<jdstrand> unfortunately, I need to step away for a few minutes. but ask in backscroll and I'll get back to you in a bit
<Chipaca> jdstrand: sure. It's about https://code.launchpad.net/~chipaca/ubuntu-core-launcher/unshare/+merge/258367
<mvo> sergiusens: meh, I thought we had fixed all the "exit status without further info " issues, is this u-d-f build against latest stable (or unstable) of u-d-f ? I wonder if that helps
<Chipaca> jdstrand: apparmor complains, not about unshare(2), but about mount
<sergiusens> mvo: I think beowulf is on whatever is on vivid
<sergiusens> mvo: and yeah, we didn't fix all the exit status messages which kind of sucks a bit :-/
<beowulf> sergiusens: mvo: i initially added ppa:snappy-dev/beta, i don't know if that matters (looked at wrong docs)
<sergiusens> mvo: maybe he is just on an out of date u-d-f (I hope it's that)
<Chipaca> sergiusens: mvo: i hope/plan to get to that next week
<sergiusens> beowulf: using beta should be fine
<Chipaca> sergiusens: mvo: i expect your first few days back are going to be spent reviewing :)
<beowulf> sergiusens: mvo anything i can try to get a working img?
<sergiusens> beowulf: mvo I suspect snappy unpack is failing for some reason
<sergiusens> but that is just gut feeling
<mvo> beowulf: hm, I am not sure, maybe a rebuild against a up-to-date snappy
<sergiusens> mvo: does it fail for you using what's in the ppa?
<mvo> sergiusens: against what version is u-d-f in the ppa build?
<mvo> sergiusens: I need to check, give me a sec
<sergiusens> mvo: Built-Using: golang (= 2:1.3.3-1ubuntu4), golang-ar (= 0.0~git20150512-0ubuntu2), golang-go-flags (= 0.0~git20141007-1), golang-gocheck (= 0.0~bzr20131118+85-2), golang-goconfigparser (= 0.2-0ubuntu1), golang-juju-loggo (= 0.0~git20150318-0ubuntu1), golang-pb (= 0.0~git20131219-1), golang-yaml.v2 (= 0.0~git20150225-0ubuntu1), ubuntu-snappy (= 1.0-1+424~ubuntu15.04.1)
<Chipaca> 424 is not latest
<sergiusens> Chipaca: no, it was until last night
<Chipaca> i mean, 439 is what's in the ppa from last night
<Chipaca> *ancient* :-p
<mvo> sergiusens: I think r436 has some important error reporting fixes
<mvo> having that would be good
<sergiusens> mvo: I can trigger a rebuild, we have recipes for everything now ;-)
<mvo> that would be cool
<sergiusens> mvo: Chipaca to bookmark https://code.launchpad.net/~snappy-dev/+recipes ;-)
<mvo> yay! you found it!
<sergiusens> mvo: btw https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/bump_upstream/+merge/258651
<sergiusens> or the recipe will fail...
<sergiusens> mvo: and I've been thinking about snappy build and releases and rolling and haven't come up with anything smart yet, maybe we need to add the base release to packages.yaml
<jdstrand> Chipaca: what is the denial? I may be surprised if seccomp likes it too
<Chipaca> [Fri May  8 16:31:01 2015] audit: type=1400 audit(1431102661.774:53): apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="/usr/bin/ubuntu-core-launcher" name="/tmp/" pid=1928 comm="ubuntu-core-lau" flags="rw, private"
<Chipaca> jdstrand: sneakily, I do it before seccomp
<jdstrand> Chipaca: is it possible to do it before apparmor? right now things are quite clean wrt apparmor rules-- we don't allow any mounts, umounts or remounts
<Chipaca> jdstrand: bah. i do it before loading seccomp for the target executable, but i guess it's run under a seccomp of its own?
<jdstrand> Chipaca: that said, we could probably craft a rule that is acceptable
<Chipaca> jdstrand: i think the launcher is run under apparmor already
<jdstrand> the launcher is not
<jdstrand> the launcher does the equivalant of an 'aa-exec'
<Chipaca> jdstrand: then what is debian/usr.bin.ubuntu-core-launcher ?
<jdstrand> iirc, it do an aa_change_onexec
<jdstrand> Chipaca: oh, yes
<Chipaca> :)
<jdstrand> Chipaca: right, the launcher does run under a profile, for some reason I read the above denial as an app denial, but it is a launcher denial
<jdstrand> sorry
<Chipaca> yep yep, it's the launcher itself
<jdstrand> yep, I'm there now
<jdstrand> Chipaca: mount rules are tricky, hold on a sec
<Chipaca> jdstrand: i do two mounts, fwiw
<Chipaca> well, you can see 'em in the mp
<jdstrand> mount options=(rw private) -> /tmp/,
<jdstrand> Chipaca: can you add the above to /etc/apparmor.d/usr.bin.ubuntu-core-launcher, then do: sudo apparmor_parser -r /etc/apparmor.d/usr.bin.ubuntu-core-launcher
<jdstrand> Chipaca: actually we should change that (feel free to test it for now while I get the other other one)
<Chipaca> [Fri May  8 16:43:50 2015] audit: type=1400 audit(1431103430.829:55): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="/usr/bin/ubuntu-core-launcher" name="/tmp/" pid=1942 comm="ubuntu-core-lau" srcname="/tmp/snaps.1000/hello-world.canonical/1.0.15/tmp/" flags="rw, bind"
<Chipaca> ^ advanced to the second mount :)
<jdstrand> Chipaca: mount options=(rw bind) /tmp/snaps.[0-9]*/**/tmp/ -> /tmp/,
<Chipaca> jdstrand: \ooooooooo/
<jdstrand> yay!
<jdstrand> so feel free to add those to the profile with a comment
<jdstrand> fyi, I asked Tyler to review the mp. he'll be back on monday
<jdstrand> (he looked really hard at the launcher before)
<Chipaca> jdstrand: excellent; i'll wait for his review
<jdstrand> Chipaca: for Tyler's context, in the commit for the above profile changes, can you add the denials?
<jdstrand> the commit log that is
<Chipaca> i'll get mvo or sergiusens to +1 the basic code
<Chipaca> jdstrand: sure
<jdstrand> cool
<jdstrand> thanks
<Chipaca> jdstrand: thank you!
<beowulf> 'night all o/
<Chipaca> beowulf: have a good weekend!
<Chipaca> jdstrand: there
<jdstrand> Chipaca: great, thanks again :)
<Chipaca> mvo: sergiusens: log juggling done, for now at least
<Chipaca> mvo: perhaps now the parallel between logger and interacter is more obvious :)
<Chipaca> mvo: and then again, perhaps you were right and i was overthinking it :)
<mvo> Chipaca: heh, I like what I see in the branches! simple and does all we need for now, I guess one more for the error logging will come later(?). but yeah, the similarities are striking now, I wonder how to combine the log and the progress, maybe we can have a "human-friendly" log that omits all the crazy timestamps(?)
<Chipaca> mvo: i think the one for error logging is up already
<mvo> Chipaca: but I may talk nonsesens, haven't really thought this through yet
<Chipaca> mvo: but maybe you're talking about a different one
<Chipaca> oh
<Chipaca> oooooh
<mvo> Chipaca: I was thinking if all the logging in  lp:~chipaca/snappy/die-LogError-die  is covered in the followups
<Chipaca> mvo: I'D ALREADY FORGOTTEN
 * Chipaca hides in shame
<mvo> ha! at least I'm not the only one with a memory like a goldfish :P
 * mvo hugs Chipaca
<Chipaca> mvo: there :)
<Chipaca> mvo: is the target for https://code.launchpad.net/~mvo/snappy/selftest-failover/+merge/258655 the right one?
<thesheff17> is this what people are using for pip and snappy? http://www.wefearchange.org/2015/04/creating-python-snaps.html
<sergiusens> Chipaca: are you going to be around for a while longer?
<mvo> Chipaca: ups, its not, I updated the MP, silly me
<sergiusens> mvo: Chipaca mind taking a look at https://code.launchpad.net/~sergiusens/webdm/oemBrokeFix/+merge/258681 ?
<Chipaca> sergiusens: I am going to be around a while, now
<sergiusens> Chipaca: heh, if you would of replied sooner I would of taken the complicated approach to fix https://code.launchpad.net/~sergiusens/webdm/oemBrokeFix/+merge/258681 :-P
<sergiusens> now I await the needs fixings ;-)
<Chipaca> sergiusens: ah, i haven't top-approved
<Chipaca> sergiusens: what was the complicated approach?
<sergiusens> Chipaca: extend packageYaml in snappy and add an interface to get the branding
<Chipaca> sergiusens: at this stage, what's another spot on the liger
<Chipaca> ... wait, ligers don't have spots
<Chipaca> sergiusens: top-approved
<sergiusens> Chipaca: thunder cats you mean?
<Chipaca> sergiusens: http://en.wikipedia.org/wiki/Liger
<mvo> holly cow, I learned something new today (again!)
<Chipaca> mvo: no, that's AuÃ°umbla
<Chipaca> or maybe Gavaevodata
<sergiusens> mvo: what is this version number's granularity btw ? 1.4.0.0.2 ?
<mvo> sergiusens: we have support for "-" so 1.4.0-2
<mvo> sergiusens: maybe I'm not understanding the question actually
<sergiusens> mvo: so many dots, that's all :-)
<mvo> I think its a artifcat from the old days when we did not have a "-"
<mvo> so many dots where used to simulate the packaging version
 * Chipaca is going to make packages versioned â.â, â..â, â...â. Because the docs say I can.
<Chipaca> mvo: does selftest have tarmac?
<Chipaca> or otherwise auto-merge?
<mvo> I don't think so
<Chipaca> mvo: i don't think i'm going to manage to review your selftest branches today though
<Chipaca> not with any kind of proper testing
<sergiusens> mvo: I think it does, but it doesn't any sanity checks
<sergiusens> confirmed, it's there
<mvo> aha, ok
<mvo> having the selftest in tarmac and building a image etc would be cool, but I'm too tired to even think about this
<mvo> (i.e. as test run it on a fresh image)
 * mvo will vanish into bed soon
<Chipaca> mvo: by "snappy install typo", you mean a snappy install of a package that can't be found?
<Chipaca> mvo: if so, yes, we log those
<Chipaca> will reply on the mp, go to bed :)
<sergiusens> Chipaca: one last one please https://code.launchpad.net/~sergiusens/webdm/policies/+merge/258686
<Chipaca> sergiusens: go
<mvo> Chipaca: yes, that, its fine, just wanted to check :)
 * mvo waves
<sergiusens> Chipaca: i'll bbl, which means you should nt even be here btw ;-)
<mhall119> does snappy require root to install? I thought we got away from that with click.
#snappy 2015-05-09
<ryanprior> What's the relationship between snappy and click? Are they two different things?
<Zic> hi, I do not have a "true" question about snappy but just about Canonical's naming: does "snappy Ubuntu Core" and "Ubuntu Core" referenced the same things and the complete name "snappy Ubuntu Core" is just to emphasis that it is a snappy-based packaging Ubuntu? I am preparing an article about snappy and it will be great if I use the correct official name :}
<Zic> my primary thought was maybe, someday (with what UOS meetings said) we will have a "snappy Ubuntu Desktop", but it seems to be called internally "snappy Ubuntu Personnal", so I do not get the point :(
<devil> Zic: snappy core is bases on ubuntu core and is for cloud/Iot. snappy personal is some of the same principles rolled out on the Ubuntu desktop
#snappy 2015-05-10
<Zic> devil: thanks for your answer, I just saw it ;)
<devil> yw
<lantins> Hey, hoping someone can clear up a couple of things about snappy ubuntu core:
<lantins> 1) Can we use custom kernel's with Snappy Ubuntu Core?
<lantins> 2) Can snappy packages be used without making them public on the store?
<lantins> I have a couple more, but that's top of my list
<lantins> I'm having a hard time finding information about it on the interwebs :/
<ryanprior> lantins: I haven't had any luck getting questions answered here, I think the snappy devs must hang out elsewhere.
<ryanprior> lantins: maybe check out mailing lists?
<lantins> snappy devs dont hang in the snappy channel, what's the world coming to? :)
#snappy 2016-05-09
<milani> Very quiet. Do developers speak somewhere else?!
<pmp> milani: they are here usually, I get great answers most of the time.
<miken> Quite a few of the snappy devs will be travelling to a sprint, which will go for this week, so it may be hard to get peoples' attention :)
<ysionneau> ogra_ : hi! where do I open a bug for UDF not supporting armhf userspace + aarch64 kernel? is there a github or a launchpad bug tracker for UDF?
<noizer> zyga
<noizer> are you there?
<zzarr> hello! I'm new to snap packages, is it possible to make a package with a graphical environment?
<zzarr> I have a dragonboard 410c with a HDMI/USB connected touch screen
<zzarr> I wish to run a custom application on it
<blackout24> zzarr, Yes there are applications packaged as snaps with a GUI like the ubuntu-calculator app
<zzarr> nice!
<zzarr> thanks blackout24
<jdstrand> blackout24: fyi "apparmor restrictions don't seem to work on symlinks". They *do* work on symlinks, in precisely the way they are supposed to, but not in the way you are wanting. ie, apparmor will necessarily resolve symlinks when doing path name lookups for security reasons. That said, modifying the launcher profile to do what you want on Arch should not be particularly difficult
 * ogra_ curses the jetlag
<davmor2> ogra_: you just need to sleep
<ysionneau> ogra_ any link to the ubuntu-device-flash bug tracker page?
<ogra_> ysionneau, try https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch
<ogra_> davmor2, :P
<ysionneau> ogra_: thanks a lot!
<ysionneau> ticket created: https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1579767
<ubottu> Launchpad bug 1579767 in goget-ubuntu-touch (Ubuntu) "udf does not support using aarch64 kernel snap with armhf 32 bits user space" [Undecided,New]
<josepht> is running a snap application via sudo supported?
<qengho> josepht: Er, I don't think it matters. "sudo foo", where foo is a snap app name?
<josepht> qengho: 'nmap localhost' works but 'sudo nmap localhost' does not.
<ogra_> how does it fail
<qengho> Root PATH?
<wsnipex> hi, after the removal of old-security from snappy, is there still some way to provide apparmor profiles/overrides?
<qengho> Try "sudo /snap/bin/nmap"
<wsnipex> the reason I'm asking is that current plugs/slots are not sufficient to make my app work
<josepht> on pi2 it fails with: route_dst_netlink: can't find interface "lo"
<ogra_> wsnipex: file a bug
<wsnipex> ogra_, on launchpad?
<josepht> same on amd64 classic
<ogra_> wsnipex: indeed
<jdstrand> wsnipex: no. you can install the snap with --devmode to unblock you then file bugs at https://bugs.launchpad.net/snappy/+filebug addng the `snapd-interface` tag.
<josepht> where "lo" is which ever interface nmap tries to use
<wsnipex> jdstrand, bugs for what exactly? that the existing plugs will probably never be sufficient to make kodi work? or that there is no possibility to override apparmor/seccomp anymore?
<ogra_> uuh, indeed we will get to a point where the plugs are sufficient to run kodi at some point
<ogra_> else we would have failed
<wsnipex> good to hear
<ogra_> but we need to know which bits are missing, so we need bugs from you
<jdstrand> wsnipex: a bug on what you want
<jdstrand> wsnipex: in terms of new interfaces
<jdstrand> wsnipex: what denials are you seeing, why you need that functionality, what the interface should look like, code, etc
<wsnipex> I need at least this: https://github.com/wsnipex/xbmc/blob/246f93c30d51e8111e8ff8a6c268f7fb62643d9a/tools/Linux/apparmor-snap.kodi.kodi#L418
<wsnipex> and its certainly not everything, since I didn't test all use cases by far
<jdstrand> please file a bug
<ogra_> the pulse interface is underway
<ogra_> not sure you will get access to fstab though
<wsnipex> I'm actually expecting that some of those might be refused
<ogra_> or to the /media mountpoints
<wsnipex> but what good is a media center without access to media ;)
<ogra_> access to the homedir (and Video underneath etc) is there already
<wsnipex> I know
<wsnipex> but automounts usually end up on /media
<jdstrand> wsnipex: no need to be fatalistic. file the bug and we'll see how this should work
<wsnipex> ok
<jdstrand> interfaces are different than the previous 'caps' model. there is more flexibility, etc
<ogra_> jdstrand: i wonder if we shouldnt make the automounts end up in home somehow ... at least the user specific bits
<ogra_> (through some provileged link or some such... without touching the actual implementation of udisks)
<jdstrand> that gets tricky since the user has control of the directories things would be mounted into
<ogra_> well, does he on a core install ?
 * ogra_ thinks we'll bang our heads against quite a bunch of differences between desktop and core for the near future
<josepht> journalctl -xe shows: audit: type=1400 audit(1462802034.408:65): apparmor="DENIED" operation="open" profile="snap.nmap.nmap" name="/proc/31883/net/dev" pid=31883
<wsnipex> heh: /proc/@{pid}/net/dev r,
<jdstrand> I think I added that to trunk recently
<blackout24> jdstrand, thanks. Still hitting a wall right know trying to launch apps through ubuntu-core-launcher. I think I'll try compiling my kernel from the v4.4-aa3.5-beta1 branch instead of v4.5-aa.3.5-beta1 branch.
<noizer> Hi guys, I asked one week ago something about Soft Floating. Zyga answerd my question then you need to make a chroot and compile it then en check if it works then. But how can I check if my chroot is correctly?
<noizer> Or does somebody knows when Zyga is back?
<jdstrand> noizer: zyga is sprinting this week. I suspect he will be online in an hour or so, but due to sprinting, may not be terribly responsive
<noizer> jdstrand: Ok maybe someone else can help me out for now
<noizer> jdstrand: Do you know mutch about chroot ...
<jdstrand> noizer: I don't have any info on your question ("how can I check if my chroot is correctly?")
<sborovkov> Hello. I've asked about this around 2 weeks ago and at that time this was not working - snap install snap-name config.yaml. Does anyone know when this will be working?
<noizer> jdstrand: wait I will explain it totally.
<jdstrand> sborovkov: snappy config is not back yet
<jdstrand> I don't have an eta
<jdstrand> sborovkov: JamieBennett could give an eta. see the above re people sprinting
<noizer> I want to implement Nuance TTS on my snappy device on a rpi2 or 3. now the problem is raspberry pi 2 and 3 are hard float systems. Nuance works only with soft-float systems on ARM linux. What zyga told me is to debootstrap a arm soft-float system. mount /proc and sys and then chroot the debootstrapped build. Compile there my application with the Nu
<noizer> ance TTS and then run.
<noizer> jdstrand: now i compiled it and tested it but I have some problems maybe it isnt fully soft floating or I don't now what the exact problem
<sborovkov> jdstrand: understood, thanks
<qengho> Hmm, I don't think compiling on the same CPU is very important, but being on a no-hard-float CPU is important for testing.
<jdstrand> noizer: I'm going to defer to others who have experience in this area
<noizer> jdstrand: qengho What i done now is compiled it on a raspberry pi 1
<zyga> good morning
<noizer> zyga good morning
<qengho> noizer: Great. I think you could have compiled anywhere, including amd64.
<zyga> noizer: good morning
<qengho> noizer: You have to make sure that your compiler emits ARM instructions for the CPU you are targeting. That's all. It's not a chroot trick. It's a configuration trick.
<qengho> noizer: The important thing here is that even if you were on a RPi1, it could have been making instructions for hard-float CPUs. Compiling has nothing to do with running.
<noizer> qengho: zyga hmm wait I got an *.so file from Nuance that is compiled with soft-floating. and I made an applicatoin with it and compiled it against the *.so file from nuance
<noizer> but it should work?
<qengho> If everything you just said is true, then it should have no hard-float problems.
<zyga> noizer: hey, I'm going to be busy sprinting this week
<noizer> zyga:  ok qengho is helping right now but thanks forallthe help you gave me?
<qengho> noizer: Make sure your app -- the place YOU are running gcc or clang or whatever -- is making the right instuctions. Read its man page. When you compile, you are responsible for making sure what you're making is what you intend. The computer does not read minds. Tell it. Make sure. Read man pages.
<josepht> jdstrand: does my snap need to be rebuilt for the /proc/@{pid}/net/dev change that landed in trunk recently?
<jdstrand> it was added to trunk (I just checked), you do need trunk's snapd on your device. you will have to reinstall the snap
<josepht> jdstrand: ack, thanks
<ogra_> mvo, the livecd-rootfs change looks fine
<noizer> qengho: So soft-floating works can work on a hard floating system?
<qengho> noizer: yes. "floating point routines implemented in {soft,hard}ware". Some CPUs have instructions that handle the math faster, in silicon. If you don't' have it, you have to change the numbers into something you can compute in software, which is slower.
<noizer> qengho: i know but what is a good way to change a standard Hard floating system in a soft floating system? what I done for now is made a chroot for it
<qengho> noizer: The Right Wayâ¢ is to compile both, and test which path to take. But that's harder to get right. (Trust me. I know.)
<qengho> noizer: I can't help you with your program. I have things I must finish.
<noizer> qengho: ok np I will try further
<josharenson> How can I build a snap to run on my Pi2? I have it built on my amd64 box, but it won't cross compile and it doesn't seem that snappy has snapcraft available as a snap. Do I need a non-snappy armhf system to do this? (which isn't that bad because I guess I can use my phone)
<qengho> I found a Pandaboard ES b1 on my bookshelf yesterday, while cleaning. I'm pretty excited to try it out too.
<qengho> If it doesn't work, I'm just going to mail it to rsalveti. He will find a use for it.
<josharenson> qengho: I have an old one with several hundred days of uptime in my closet :-)
<sborovkov> josharenson: I am using MATE to build snap for RPI
<sborovkov> on RPI
<josharenson> sborovkov: so essentially the solution I proposed.. A non-snappy armhf system :-/ what a bummer
<popey> i build on my pi
<popey> with a snappy install using classic dimension
<popey> works well
<kyrofa> josharenson, you should use the Launchpad armhf snap builder-- way faster than building on-device
 * josharenson looks
<kyrofa> josharenson, you can actually build your snap for all supported architectures that way
<kyrofa> josharenson, and it's fast
<josharenson> kyrofa: have a link to some docs?
<kyrofa> josharenson, not actually documented I'm afraid, but you know what... I'll do that now
<josharenson> kyrofa: haha ok, thanks
<josharenson> kyrofa: I assume its similar to how PPAs work?
<josharenson> that are built on lp
<kyrofa> josharenson, easier, even
<josharenson> kyrofa: of course, cause snappy :-)
<kyrofa> josharenson, you just need your code on LP somewhere-- pushed to junk, pushed to a project, etc.
<Kamilion> kyrofa: I'd also like to know of that documentation once it exists
<kyrofa> Kamilion, almost done, I'll ping you both
<kyrofa> Kamilion, just a quick and dirty walkthrough-- it should be actually documented by launchpad, but that's not me
<Kamilion> Cool, thanks.
<Kamilion> no worries, used to it
<Kamilion> https://launchpad.net/~kamilion  <--- been doing it a while.
<kyrofa> Kamilion, josharenson, hope this helps: https://rainveiltech.com/posts/building-your-snap-on-device-there-s-a-better-way
<Kamilion> huh. How's owncloud been recently? I bailed like a year and a half ago after a mass exploit of owncloud vms.
<kyrofa> Kamilion, I use it anyway
<kyrofa> Kamilion, I like being able to share my calendar and files with my wife, etc.
<kyrofa> Kamilion, and sync my contacts between my phone and laptop, etc.
<Kamilion> has security been any better recently?
<Ayyad> kyrofa, good read.. thank you
<JanC> you can always run owncloud where it's only accessible through a tunnel/VPN or something like that, I guess
<kyrofa> Ayyad, no problem!
<kyrofa> Kamilion, I'm not an owncloud dev... I guess I can't speak to the security
<Kamilion> kyrofa: fair enough
<Kamilion> JanC: ssh tunneling has a very low WAF
<Kamilion> https://en.wikipedia.org/wiki/Wife_acceptance_factor
<kyrofa> Kamilion, but at least snappy makes the exploits less useful :)
<Kamilion> (not web application firewall)
<Kamilion> yeah, in theory
<Ayyad> Kamilion, yeah.. I was wondering how that makes sense :D
<Kamilion> https://mjg59.dreamwidth.org/42320.html
<JanC> Kamilion: obviously whatever you use for tunneling would require pre-configuration
<kyrofa> Kamilion, https://askubuntu.com/questions/760803/security-of-snaps-under-x11/760813#760813
<kyrofa> Kamilion, owncloud doesn't use X :)
<Kamilion> hahah, there IS no protection through X11
<Kamilion> any application can just grab the keyboard or mouse or sendkeys to applications
<kyrofa> Exactly
<Kamilion> because That's Just How X Works
<Kamilion> thankfully wayland doesn't have the same issues
<kyrofa> Kamilion, yeah, mir doesn't either
<Kamilion> ooh, is there a working wayland snap yet?
<Kamilion> kyrofa: uh, yes it does
<Kamilion> mir just kinda sticks two existing X components togther in an unholy mash of wtffery
<Kamilion> it's still using many of the major x libraries, unfortunately
<Kamilion> it's not like we could blame xorg or xfree86 either, they're working off the X Consortium's specs
<Kamilion> (and if I'm currently mistaken about Mir, I apologise, the only real information I have on it is from around 2012 and a lot of stuff might have changed)
<Kamilion> but last I knew the best description of it was "we embedded a window manager into the display server so we can call it a compositing server now"
<Kamilion> I went with wayland myself
<nhaines> That's... not how Mir works.
#snappy 2016-05-10
<kyrofa> Thanks nhaines. I didn't really know what to say there. You phrased it perfectly
<olympionex> is anybody using snaps to automatically pull in dependencies and setup a dev environment?
<Kamilion> nhaines: went and read the wikipedia page on it; seems like a lot has changed. Also; last time I had tested it, I must have been using xmir. Can't say I've touched it for more than a few minutes at a time since 13.10, honestly.
<Kamilion> looks like they use libinput now too. cool.
<nhaines> Kamilion: And the nice thing is that since they can just run an XMir instance for each application, problem solved eventually.  :)  (Probably when using snaps.)
<Kamilion> Ah, I see the appeal. especally seeing QT as the toolkit of choice (which has already had good wayland support for a long time)
<noizer> Hi how can i snap a debootstrapped system?
<jdstrand> Kamilion: this isn't the channel that has the mir devs. you may want to join #ubuntu-desktop and ask questions there. it does solve the problems with X
<cl-netbox> short question : how can I refresh (update) all snap packages with one command ?
<qengho> zyga: For https://bugs.launchpad.net/snappy/+bug/1574526 , you discovered the problem was getsockname. How?
<ubottu> Launchpad bug 1574526 in Snappy "x11 plug doesn't allow getsockname, breaks xeyes" [High,Fix committed]
<qengho> I know of "scmp_sys_resolver", but I can't figure out what reports the number on the failure I see. Nothing in dmesg or syslog.
<zyga> qengho: hi
<zyga> qengho: so I just got a kill originally, I looked up the system call number
<zyga> qengho: I checked apparmor / seccomp templates
<zyga> qengho: and patched the one that was missing
<zyga> qengho: that's roughly it
<qengho> Hmm.
<qengho> Okay, I need to recreate this package. It's not giving me a crash with a number. Just "Bad system call" and ending. It might be devmode.
<zyga> qengho: that's expected, but in syslog you see more details
<zyga> qengho: and then you can see the system call number
<qengho> zyga: that's where you're wrong. Nothing is in syslog except apparmor complaints about my ecryptfs home.
<qengho> zyga: same as in the bug report^.
<zyga> qengho: did you install your snap in devmode or not?
<zyga> qengho: I take that back
<zyga> qengho: so I think I just had a very educated guess
<zyga> qengho: I had a look at the seccomp template and noticed this is gone
<qengho> zyga: okay. Thanks.
<wililupy> with u-d-f it says cannot find gadget snap. Here is my command: sudo ./ubuntu-device-flash core 16 --channel=edge --kernel=canonical-linux-pc --gadget=canonical-pc os=ubuntu-core -o snappy-16.04.img
<qengho> zyga: Okay, I packaged it as "x11-apps" and put in the store. I think there's something new; will check more after lunch.
<qengho> zyga: ^only stage-packages: [x11-apps] and slots: [ x11 ] and one apps stanza per /usr/bin/....
 * qengho afk.
<qengho> """'slots' must be used with 'daemon' lint-snap-v2_daemon_required""" Eh?!
<kyrofa> kgunn, regarding bug #1575188, did that get OKd then?
<ubottu> bug 1575188 in Snapcraft "Fix for bug #1572664 had broken my snap package build" [Undecided,Confirmed] https://launchpad.net/bugs/1575188
<kgunn> kyrofa: i was just trying to ressurect it somehow
<kgunn> kyrofa: otherwise incomplete tends to languish
<kgunn> kyrofa: so i guess we need to bother jdstrand ^ ?
<kyrofa> kgunn, understood. Yeah, we don't want to produce snaps that will always fail review
#snappy 2016-05-11
<olympionex> I really like snapcraft and would like to use it to setup my development environment (automatically fetching and building dependencies and source).  Essentially I want what gets put into the stage directory although I would like everything to be located in standard directories relative to root (/usr/lib, /usr include, etc...).  I'd like to spawn a new computer and use the snapcraft recipe to get everything.  I don't see anyway to do this with snapcraft
<olympionex>  as such.  Am I missing an easier solution than either just copying stage to the root of a container or forking snapcraft and changing the stage directory to root?
<olympionex> *new computer = new container
<shuduo> morning
<shuduo> question: where is $SNAP_APP_DATA_PATH point to in recent image?
<popey> shuduo: I don't think that's used
<popey> SNAP_DATA is
<shuduo> popey: hmm, i need use a snap which uses SNAP_APP_DATA_PATH to point a file out of snap. sounds like I need rewrite code to use SNAP_DATA to point to that file instead of SNAP_APP_DATA_PATH. then where is SNAP__DATA point to? i see hello-world use /var/snap but i should not have permission to add a new file there, right?
<popey> shuduo: SNAP_USER_DATA is probably what you want, which points to $HOME/snap/<snapname>/<revision>
<shuduo> popey: great. may i know $HOME/snap/<snapname>/<revision> need extra code to generate? right now there is no such directory although the snap be installed and running as a service.
<popey> shuduo: i think it gets made when the snap is installed
<popey> I don't think I made it
<popey> yes, looking at my system, I have lots of directories in $HOME/snap/* which match the snap names, and I didnt make them
<shuduo> popey: since the original code is against old snappy. i ask Pedro Coca's favor to build by an old version snapcraft. do you think it may lead that not making directory in $HOME/snap?
<popey> shuduo: not sure, I'd certainly keep up to date with snapd/snapcraft
<popey> things move fast, and you're likely to be fighting to use old versions
<shuduo> popey: yes. i have to. :(
<popey> dholbach: have you made any snaps with multiple parts where one depends on the other, like foo needs libfoo?
<popey> I have one where i have foo making sure it builds after libfoo, and libfoo builds from source, but when building foo it doesn't see libfoo headers
<popey> like the make install bit of libfoo wasn't done, or it needs an ldconfig or something?
<qengho> popey: do you define the "after" clause on foo? Suppose you change to parts/foo/build, do you see references to stage/ libfoo stuff ?
<popey> i did
<popey> hm, no refrerence in the build dir,
<popey> is there some way to say that foo needs to pull in libfoo?
<popey> (i should probably say foo and libbar I guess) :)
<popey> i see the build for the library in parts/libfoo/build
<popey> ah, i guess my qmake plugin isn't doing the right things here, which I'm using for foo
<qengho> popey: Yeah, you should be using the stagedir variables to constuct your -I cflags and -L ldflags and such.
<popey> ahhh
<popey> ta
<dholbach> popey, I personally haven't, but I've seen the after keyword being used and played around with it a little bit
<dholbach> good to see that you got it working
<popey> heh, almost :)
<jcastro> sergiusens: electron 1.0. Soon would be a great time to enable app developers to just ship those apps. :D
<jdstrand> kgunn, kyrofa: responded in the bug
<kgunn> ta
<croepha> is there a lower level "debootstrap" like utility for creating a ubuntu snappy installation?
<croepha> nvm, I think the ubuntu-device-flash will do what I want, sorry stupid question still learning basics about snappy
<noizer> zyga: Hi any advice how i can snap my debootstrapped soft float system?
<zyga> noizer: just copy it using the copy plugin
<zyga> noizer: still sprinting
<noizer> zyga sorry
<kyrofa> didrocks, bug #1576411 was the one we were talking about
<ubottu> bug 1576411 in snapd (Ubuntu) "UTF-8 is not very well supported inside snaps" [High,Triaged] https://launchpad.net/bugs/1576411
<zyga> tyhicks: is it possible to constrain connect with apparmor/seccomp today?
<zyga> tyhicks: I'm thinking of cups interface
<zyga> tyhicks: is just having "network" enough to print?
<tyhicks> zyga: /etc/apparmor.d/abstractions/cups-client
<zyga> tyhicks: oooh, you just made my day easy
<zyga> thank you!
<tyhicks> :)
<zyga> tyhicks: I think we should patch u-c-l to bind-mount /etc/alternatives
<zyga> tyhicks: this will also address bug https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1580018
<ubottu> Launchpad bug 1580018 in snapd (Ubuntu) "ubuntu-core image missing awk" [Undecided,Incomplete]
<sborovkov> Hi. Is there something wrong with the command I am using -  sudo /home/ubuntu/ubuntu-device-flash core 16 --channel edge --enable-ssh --developer-mode --gadget canonical-pi3 --kernel canonical-pi2-linux --os ubuntu-core -o snappy-2016-05-11-16-08-pi3.img -> expected a gadget snaps: snap not found
<qengho> I get that^ too.
<qengho> And the "sudo" worries me.  "-o", so why?
<josepht> is there a cnonical-pi3 gadget?
<josepht> *canonical-pi3
<sborovkov> josepht: qengho: it's working with canonical-pi2 gadget. (exact same command, but gadget for pi2)
<sborovkov> it is existing
<sborovkov> https://uappexplorer.com/app/canonical-pi3.canonical
<sborovkov> I am not sure where ubuntu-device-flash downloads it from though
<tyhicks> zyga: I haven't looked at that bug until now but that seems like the most reasonable fix
<Sweet5hark> apt.cache.FetchFailedException: W:The repository 'mirror://mirrors.ubuntu.com/mirrors.txt xenial Release' does not have a Release file., W:Data from such a repository can't be authenticated and is therefore potentially dangerous to use ...
<Sweet5hark> ^^ seeing this with snapcraft on xenial -- any hints?
<Sweet5hark> "sudo apt update" works fine?
<seb128> Sweet5hark, that is apt.cache ... is snapcraft doing the caching or is that a local cacher from yours?
<qengho> Sweet5hark: snapcraft is less forgiving than apt install is. Repos with "W"arnings cause errors.
<Sweet5hark> seb128: thats the content of the exception that some snapcraft/python command wrapper throws ...
<Sweet5hark> well, an "apt-cache search libreoffice" isnt unhappy either.
<kyrofa> didrocks, https://github.com/kyrofa/qt-example-snaps
<qengho> Sweet5hark: it's not smart. "apt" exited with nonzero, so you get that failure.
<Sweet5hark> hmm, "sudo apt update; echo $?" gives a happy 0 ...
<seb128> Sweet5hark, but with W:?
<Sweet5hark> seb128: nope
<seb128> k, dunno then
<seb128> qengho, do you know where snapcraft is gettings its sources config from?
 * Sweet5hark will hack snapcraft to echo what commands it run, I guess.
<qengho> seb128: hardcoded internally. Constructed from variables.
<qengho> /usr/lib/python3/dist-packages/snapcraft/internal/repo.py
<kyrofa> seb128, qengho, only 1.x is hard-coded. 2.x uses the system sources by default
<qengho> Oh, nice! Sorry.
<Sweet5hark> No mirror file '/home/bjoern/checkouts/libreoffice-snap/parts/libreoffice-build/ubuntu/var/lib/apt/mirrors/mirrors.ubuntu.com_mirrors.txt'  <- iinteresting ..
<jdstrand> tyhicks: hey, can you take a look at: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1580463/comments/5
<ubottu> Launchpad bug 1580463 in snapd (Ubuntu) "Snap blocks access to system input methods (ibus, fctix, ...)" [Medium,New]
<jdstrand> tyhicks: I've already added something to the policy updates IV card
<jdstrand> tyhicks: and by 'take a look at', I mean, 'review the comment'
<tyhicks> jdstrand: yes, I'll need a little bit
<jdstrand> tyhicks: it isn't time-sensitive. I just want you to be aware
 * tyhicks nods
<seb128> jdstrand, tyhicks, @{HOME}/.config/ibus/bus/ is the snap home though?
<seb128> not the system one
<seb128> e.g it's not going to have the config needed
<jdstrand> seb128: /home is not mounted over, so @{HOME}/.config/ibus/bus/ is there
<jdstrand> seb128: note that $HOME is set to something like: /home/jamie/snap/hello-world/25
<jdstrand> seb128: which is why you copied the stuff into ~/snap/...
<jdstrand> but the apparmor policy actually currently allows /home/<user>/.config/ibus/bus/
<jdstrand> so if you could find it, you could use it
<seb128> k
<zyga> jdstrand: do you think we should have stuff like REAL_HOME?
<jdstrand> zyga: for sdoc, possibly to probably. for iot, I don't think so. it really depends on how much we want to expose. I mean, $REAL_HOME/.config/ibus/... means nothing on an iot system since there is no ibus daemon running. this is getting a bit into the area where I'm not super-comfortable with mixing policies of different target systems
<jdstrand> ie, core vs sdoc vs future personal
<jdstrand> I have concerns on the direction we're going that things are going to be quite muddled
<jdstrand> I also realize that things are still in flux and we are figuring out, so that isn't a criticism. I just would like to see a clear path for handling the three target system types
<zyga> jdstrand: about core vs iot: https://github.com/ubuntu-core/snappy/pull/1158 (already merged)
<jdstrand> zyga: awesome! :) yes, that is certainly aprt of it
<jdstrand> zyga: but I was getting more at target system security policy philosophy
<jdstrand> ie on core/iot it makes a *ton* of sense to set HOME to ~/snap/...
<jdstrand> but on Touch we did not do that because we wanted to reuse services like ibus, theme engines, etc and so we set HOME in the normal way with accesses to those directories, and app-specific directories in well-known XDG locations
<jdstrand> so now with sdoc I'm not clear what we are doing. that will likely affect personal
<jdstrand> I mean I know we are setting HOME to ~/snap/..., but that has implications like with what seb128 is facing
<jdstrand> and traditional apps and service don't know know HOME vs REAL_HOME or whatever
<jdstrand> so then we try to jump through hoops in the launcher to do bind mounts and things
<jdstrand> Touch is cleaner in some ways in that the services, themes, ibus, etc all work cause there are no bind mounts and HOME is normal. but it has its own issues, like apps having to know they can write to ~/.config/snap.foo but not ~/.config/bar
<jdstrand> on Touch, the toolkit handles that and apps must be designed for it, but sdoc is traditional apps, which are not
<jdstrand> which circles back, HOME in ~/.snap/... helps the apps in some ways (they can write anywhere in $HOME/...) but then breaks them finding ibus files and the like
<jdstrand> anyway, I'm just yammering here, but these are some of the things I've been thinking about
 * jdstrand goes back to being productive
<seb128> jdstrand, having a separate home mostly makes sense but maybe be could expose some selected dir in some way (bind mount, symlinks+apparmor access to the target,...)
<seb128> but yeah, not going to be resolved today
<zyga> jdstrand, tyhicks: https://github.com/ubuntu-core/snappy/pull/1160
<popey> sergiusens: you planning on publishing the yaml for your telegram snap somewhere? I am sure a few of us can learn from it :)
<zyga> elopio: ^^
<elopio> popey, zyga: https://github.com/sergiusens/telegram-snap
<popey> elopio: thanks
<sergiusens> popey it is in my git hub account
<sergiusens> Some things still don't work
<nealmcb> I want to play with snaps, but haven't upgraded to xenial yet.  So I'm trying to run it via docker: (docker run -it ubuntu), where I apt update; apt install -y snapd    But then I get "error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps?sources=local"
<popey> nealmcb: looks like your docker instance isn't a full install. maybe snap talks to snapd over dbus or something and the service isn't registered inside the docker container
<popey> ... at a guess
#snappy 2016-05-12
<w1nt3r> can snappy be used on regular Ubuntu 16.04? or can it only be used on Ubuntu Core right now?
<noizer> Hi short question is it possible to use usb devices in the shell classic?
<jdstrand> tyhicks: hi! when you see mvo can you let him know that I remove ubuntu-core-security* from the system-image seed (and added seccomp so scmp_sys_resolver doesn't go away), then removed ubuntu-core-security from the archive (all of this on yakkety)
<jdstrand> tyhicks: I'm not sure how the os snap is being generated so wanted to give him a heads up
<tyhicks> jdstrand: hi - I will let him know
<jdstrand> tyhicks: thanks! :)
<tyhicks> jdstrand: he's received the message
<jdstrand> tyhicks: thanks again :)
<cos-> sorry if this is faq but is there a qmake plugin?
<sergiusens> cos- there is no qmake plug in but can get one started by looking at what dpm did in one of his playpen branches
<cos-> i found this https://github.com/kyrofa/qt-example-snaps/tree/master/application
<cos-> will there be a official qmake plugin?
<sergiusens> cos- there will, once we get a Qt expert to contribute one (or we have time to study it a bit more)
<cos-> ok, nice
<cos-> after all it's the default build system for qt, although many projects prefer cmake
<sergiusens> elopio do we have the lxd for travis setup anywhere?
<sergiusens> 1.x maybe?elopio
<elopio> sergiusens: the ugly hack with lxc we did: https://github.com/ubuntu-core/snapcraft/pull/371/files and the recommended way to get xenial: https://docs.travis-ci.com/user/docker/
<nealmcb> popey: thanks.  But can we get a more definitive answer on why I can't run snappy on the official Ubuntu docker image?  It seems to me that using a premier feature of Xenial on the official Ubuntu image for one of the main ways that Ubuntu is used in the cloud needs to be addressed, even if it is something like "its too hard" or "it would be silly to run snappy in docker because......"
<popey> nealmcb: congratulations, you have reached the limit of my knowledge on this subject ã
<nealmcb> popey: no problem.  I'm just hoping that the right guru is lurking here, ready to snap up a juicy question ;)
<popey> hahah
<popey> I admire your optimism
<nealmcb> Or do we need a snappy AI bot to handle these?  Surely snappy is the answer to AI also ;)
<kyrofa> We have an official ubuntu docker image?
<kyrofa> nealmcb, not a docker pro, but do you get systemd and services running there?
<nealmcb> kyrofa: docker run -it ubuntu
<popey> kyrofa: that's the problem, no, i dont think they do
<nealmcb> hmmm - https://lwn.net/Articles/676831/  Systemd vs. Docker
<kyrofa> popey, indeed, that's certainly the issue then
<kyrofa> nealmcb, snap is a dumb client for a smart snapd service
<kyrofa> (which runs via systemd)
<nealmcb> So can I just start by manually starting snapd?
<nealmcb> Wow, that lwn article describes an epic fight, involving major new sytems like docker and systemd, and the Open Container Project's runC tool.  Rumors of Red Hat forking Docker to resolve the issues, and allow all this to run on Windows: "Walsh also pointed out that cgroups, sd_notify, and socket activation all work out-of-the-box with runC. This is because runC does not use Docker's client-server model; it is just an executable. He does not see the br
<nealmcb> In the meantime, Ubuntu needs to have a story about snappy and Docker today, and tomorrow....
 * nealmcb starts writing it up for launchpad
<kyrofa> nealmcb, yeah running it directly might work. But docker typically runs pretty confined, I think. You might still run into issues
<nealmcb> https://bugs.launchpad.net/snappy/+bug/1581188
<ubottu> Launchpad bug 1581188 in Snappy "How to run snappy from inside Docker - systemd issues?" [Undecided,New]
<example6> Is there any way to install java and have it available among all apps in 15.04, or do I need to put it in a custom snap along with everything that needs it?
<example6> My programs need to be able to have JAVA_HOME set
<qengho> example6: if you need it, you have to put it in your snap.
<qengho> (Do you mean 16.04?)
<example6> No, I'm running 15.04
<qengho> example6: Oh. Sorry. That is too strange for me to consider.
<kyrofa> example6, snaps contain their dependencies
<bull> new to snappy
<bull> how can i build my qt app with snappy
<bull> it uses qml too
<bull> how define dependencies , how to set icon of app , and how to set where to install files ??
<bull> anyone here ?
<ogra_> there should be a Qt example somewhere (dunno where though)
<bull> snappy will fail , debian was better
<bull> its like redefining anything , debian was not broken guys are saying debian store will shut down soon . is that right ?
<bull> i will not pack my apps in this shity format it first taking lot of bandwidth , and then making my app a crap load of idk what 300mb
<bull> dead
 * ogra_ wonders if people really expect to get help when coming into channels with such tone 
<sgclark> *says in a friendlier tone* if someone does come across that qt example I would be ever so happy. have a few days to toy around with kde stuff.
 * ogra_ makes mental note to ping sgclark if he comes around it :)
<sgclark> thanks!
<ogra_> i think dpm had one ... but he is surely asleep
<sgclark> np, I am going through tutorials. I have all weekend to play
#snappy 2016-05-13
<kyrofa> sgclark, there are a few here: https://github.com/kyrofa/qt-example-snaps
<kyrofa> Sorry the room is a little quiet-- most of the team is in a team meeting this week
<sgclark> no worries, tyvm!
<kyrofa> sgclark, they're literally qt examples (from the sdk)
<elopio> asac: can you please create a PPA for me in ~snappy-dev called edge? or give me access to do that
<sgclark> kyrofa: excellent, looks to be exactly what I need. thank you again.
<kyrofa> sgclark, certainly! They aren't perfect-- I'm missing a few stage packages; menus don't work
<kyrofa> sgclark, but elopio will fix that soon
<sgclark> cool, I have the kde community at my disposal to bug as well :)
<kyrofa> sgclark, I think https://code.launchpad.net/~dpm/ubuntu-calculator-app/snap-all-things will make for a QML example
<kyrofa> sgclark, very receptive to pull requests if you're able to improve things
<sgclark> excellent, I look forward to some fun. been wanting to work with snappy for some time.
<kyrofa> sgclark, wonderful! This room will be hopping again next week :)
 * sergiusens waves hello at sgclark
<sergiusens> nice to see you!
<sgclark> hi sergiusens :)
<sergiusens> sgclark so there is some interesting stuff coming up soon wrt that library snap I mentioned a while back. It should be worked on soon and make getting the full kde stack in fairly easily. In the meantime, I guess I can suggest to create a snap with one app and then continue adding on to it.
<sergiusens> sgclark I am just implying you are doing kde stuff from what I read above :-)
<sergiusens> In any case I hope you find the fun in it.
<sergiusens> :D
<vzioss> hello
<kyrofa> vzioss, hi! Welcome
<vzioss> thanks kyrofa!
<vzioss> I am trying to build a snap package
<vzioss> having doubts in the parts plugin thing
<kyrofa> vzioss, how can I help?
<vzioss> If I understood from the your-first-snap help page
<vzioss> you can write python3 in the plugin section
<vzioss> and have python3
<vzioss> and you can also use source to point to a python3 code
<kyrofa> vzioss, indeed, run `snapcraft list-plugins` to see all the options you could use there
<kyrofa> vzioss, if you want to see how to use the python3 plugin, try `snapcraft help python3`
<vzioss> but how does one tells that there is dependency on things like pyqt, numpy, and stuff like this ?
<vzioss> ah
<vzioss> ok
<kyrofa> vzioss, does that help a bit?
<vzioss> this help command tells me just that
<kyrofa> vzioss, very good :)
<vzioss> this is really useful
<vzioss> thanks
<kyrofa> vzioss, any time!
<kyrofa> vzioss, if you want some examples to refer to, take a look here: https://github.com/ubuntu-core/snapcraft/tree/master/examples
<vzioss> thanks kyrofa!
<vzioss> I'm am trying here, I think I can make this work... If it works, this is the most impressive thing I've seen.
<kyrofa> vzioss, then I hope it works! :)
<vzioss> kyrofa, have you used python3 plugin?
<kyrofa> vzioss, indeed
<vzioss> kyrofa, I understood that below the line plugin:python3, I should just place a line stating with python-packages:
<vzioss> the package names
<vzioss> how do I list them?
<vzioss> I wrote python-packages:pack1,pack2,pack3 and got "is not of type array"
<kyrofa> vzioss, yeah you need a YAML array
<kyrofa> vzioss, so you have two options: python-packages: [pack1, pack2]
<kyrofa> or
<kyrofa> python-packages:
<kyrofa>   - pack1
<kyrofa>   - pack2
<vzioss> ah, ok
<vzioss> This is really my first yaml file in my life
<vzioss> thanks, stage worked
<vzioss> damn pillow returns a error.
<vzioss> is there a plugin for apt ?
<kyrofa> vzioss, you mean you need debs in your snap as dependencies?
<vzioss> so I could just install python3-pillow from repo instead ?
<kyrofa> vzioss, you can (by using stage-packages), but you should be able to make it work from source as well
<vzioss> yeah, pip or whatever snapcraft stage call get's an error
<kyrofa> vzioss, is the pip package bad?
<vzioss> I don't know, let me try to install pillow from pip
<vzioss> I'm in a clean virtual bo
<vzioss> x
<kyrofa> vzioss, what error did you get? Maybe pastebin it?
<vzioss> just a moment
<vzioss> pastebin.com/EtY2ubiv
<kyrofa> vzioss, ah, looks like you need libjpeg
<kyrofa> vzioss, try adding build-packages: [libjpeg-dev] to your part
<vzioss> ok
<kyrofa> vzioss, do you see where I got that?
<vzioss> build packages is nested below my part?
<kyrofa> vzioss, example: https://github.com/ubuntu-core/snapcraft/blob/master/examples/py3-project/snapcraft.yaml
<vzioss> ok
<vzioss> it asked my sudo password
<vzioss> is this normal?
<vzioss> I gave it
<vzioss> just found unusual...
<kyrofa> vzioss, indeed, build-packages install on the host
<vzioss> ok, it build ok
<kyrofa> vzioss, so it just ran `apt install` for you
<vzioss> I will try adding pyqt4
<vzioss> this will be a ride...
<vzioss> I was never able to install pyqt4 from pip, always used the ubuntu packages
<kyrofa> vzioss, you still can. It looks the same as the build packages, but it's called stage-packages
<kyrofa> vzioss, but oftentimes debs are hard-coded to work in a typical debian system, and snappy is a little different, which is why I typically recommend using source
<kyrofa> vzioss, but wouldn't hurt to try
<vzioss> if I just add in build-packages
<vzioss> it should work right?
<vzioss> ok, it appears it worked
<kyrofa> vzioss, read about the differences between stage- and build-packages: https://github.com/ubuntu-core/snapcraft/blob/master/docs/snapcraft-syntax.md
<kyrofa> build-packages install on the host (and don't make it into the snap), stage-packages are unpacked into the snap
<vzioss> thanks, I am saving this chat and favoriting those links.
<kyrofa> vzioss, we're working hard on better docs as well, but glad you're asking the questions!
<vzioss> yeah, I really pyqt, it's really easy to use, being able to hop in the gigantic library of things in python gives faster results
<vzioss> and the snappy system is really way less daunting than packaging something to be available in debian.
<vzioss> how do I clean after having made a mistake before stage?
<vzioss> it should be written here: https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-usage/
<kyrofa> vzioss, check out `snapcraft -h`. Specifically, you can run `snapcraft clean` to clean completely, or `snapcraft clean --step=stage` to clean only the stage step
<vzioss> Collecting pyqt4  " Could not find a version that satisfies the requirement pyqt4 (from versions: ) No Matching distribution found for pyqt4 "
<vzioss> this is a weird error, let me first google this...
<vzioss> ok, used stage-packages
<vzioss> does anyone have some docs on the filesets ?
<kyrofa> vzioss, https://github.com/ubuntu-core/snapcraft/blob/master/docs/snapcraft-parts.md
<vzioss> ok, reading here: https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/
<vzioss> how does the source in the line: source: git://github.com/mikix/golang-static-http
<vzioss> goes to the right place ?
<vzioss> I understood filesets does that, but not exactly how
<vzioss> the source points to a single file, named main.go
<vzioss> in the filesets there is a entry named go-server
<vzioss> since this exact name isn't anywhere else I assume this name doesn't matter
<vzioss> and then there is the line bin/golang-*
<vzioss> how did it went to the bin folder ?
<kyrofa> vzioss, the go plugin puts it there
<vzioss> ok, the python plugin creates a folder named build
<vzioss> but then, I understand that unless I created a setup.py file
<vzioss> the program won't be in /opt or wherever I want
<vzioss> is this the correct understanding ?
<vzioss> I mean, what matters is what ends up in the folder "stage"
<kyrofa> vzioss, what REALLY matters is what ends up in the "snap" folder, but you have the right idea
<kyrofa> vzioss, indeed, the python plugin needs you to tell it somehow what to build, where stuff should go, etc.
<vzioss> yeah, I didn't get to the snap step yet
<vzioss> ok
<vzioss> thanks kyrofa
<vzioss> It seems I need to take some time with this, but it's very doable
<vzioss> I really liked
<vzioss> I am going to sleep because I have to work in 5 hours
<kyrofa> vzioss, just like the make plugin, or cmake-- you need install rules in order for snapcraft to know what is important to go into the snap. You don't want it to just copy everything (object files and whatnot)
<kyrofa> vzioss, alright, sleep well!
<vzioss> bye, thanks kyrofa!
<kyrofa> vzioss, any time!
<vzioss> company is CentOs, some day I need to findout how to run this there.. hahaha
<jdstrand> tyhicks: fyi, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1576287/comments/7
<ubottu> Launchpad bug 1576287 in snapd (Ubuntu) "unity7 plug needs to be updated to allow menus export" [Undecided,Fix released]
<ysionneau> http://paste.ubuntu.com/16388460/
<ysionneau> any idea what's going on?
<jdstrand> tyhicks: you mentioned appmenu, do you know of a failing app?
<jdstrand> ysionneau: this seems wrong: devpts on /dev/ptmx type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
<ysionneau> ah ?
<jdstrand> /dev/ptmx should be a file, not a filesystem
<ysionneau> hmm I wonder who's doing this mount then :o
<jdstrand> it can either be an actual file or a symlink to /dev/pts/ptmx
<jdstrand> aiui
<ysionneau> root@localhost:/etc/apparmor.d# ls -l /dev/ptmx
<ysionneau> c--------- 1 root root 5, 2 Jan  1  1970 /dev/ptmx
<jdstrand> ysionneau: is this on a classic system?
<ysionneau> this is on a Snappy system
<jdstrand> ysionneau: what type of snappy system?
<ysionneau> I took the rpi2 ubuntu-core (+ initrd) and modified it to run on my board
<jdstrand> amd64, rpi2, ...
<jdstrand> I see
<ysionneau> it's running on Tegra X1
<ysionneau> but it's basically an rpi2 ubuntu-core
<jdstrand> oh, you did it
<jdstrand> root@localhost:/etc/apparmor.d# mount -o bind,rw /dev/pts/ptmx /dev/ptmx
<jdstrand> no that's right
<jdstrand> meh
<ysionneau> nop actually the first line was already there before my mounting try
<jdstrand> ysionneau: looking at the apparmor message, it seems that on your system /dev/ptmx is a directory and not a file
<jdstrand> ysionneau: I suggest rebooting and confirming that
<ysionneau> but ls -l shows a character device :o
<ysionneau> ok let's try that
<jdstrand> ysionneau: perhaps because of the bind mount you did
<jdstrand> (re the ls)
<ysionneau> ah yes
<jdstrand> ysionneau: http://manpages.ubuntu.com/manpages/xenial/en/man4/ptmx.4.html
<jdstrand> "The  file  /dev/ptmx  is a character file..."
<jdstrand> if it comes up as a directory, that is the issue
<ysionneau> after a reboot: http://paste.ubuntu.com/16388554/
<jdstrand> that all looks fine
<ysionneau> I think it's just apparmor refusing the mount ... but why
<ysionneau> since the apparmor profile looks fine to me
<jdstrand> ysionneau: notice in the denial it said '/dev/ptmx/
<jdstrand> that trailing '/' indicates that apparmor interpreted the mount as on /dev/ptmx/ not /ev/ptmx
<jdstrand> the apparmor rules allow mounting on the file, not the dire
<jdstrand> ctory
<ysionneau> aaah ok
<jdstrand> why it was a directory at that time, I can't say
<ysionneau> weird because in ubuntu-core-launcher there is no trailing / : http://bazaar.launchpad.net/~snappy-dev/ubuntu-core-launcher/trunk/view/head:/src/main.c#L341
<jdstrand> ysionneau: right, that all supports what I'm saying
<jdstrand> ysionneau: the launcher just tries to mount on /dev/ptmx
<jdstrand> but *if* /dev/ptmx is a directory at the time that happens, apparmor (the kernel) will interpret that as /dev/ptmx/
<ysionneau> ah ok
<jdstrand> and the policy doesn't allow mounting on /dev/tpmx/ (a dir), it allows mounting on /dev/ptmx (a file)
<ysionneau> so something might remove the /dev/ptmx file when running ubuntu-core-launcher and replace it with a directory :o
<ysionneau> weird
<jdstrand> again, why it was a directory at the time of the mount is a mystery still. I suggest keeping on eye out for this and if you can find a reproducer, file a bug
<morphis> jdstrand: ping
<jdstrand> I'm not able to reproduce it here
<jdstrand> morphis: hey
<morphis> jdstrand: hey!
<morphis> jdstrand: did you saw my update on the network-manager PR?
<jdstrand> morphis: I just came on and haven't gotten through my email yet. I see the mails
<morphis> jdstrand: aye
<morphis> jdstrand: if you have a few min I have another quick thing and would like to see if you like it or not
<jdstrand> fire away
<morphis> we thought a bit how we could do just in-snap dbus communication
<morphis> like we put modem-manager into the same snap than network-manager
<morphis> which we require a very specific interface for this
<morphis> so instead of crafting a eventual vendor-specific interface here I have two new dbus interfaces: dbus-name and dbus-access
<morphis> dbus-name is provided by the OS snap and allows a snap to acquire a dbus name
<morphis> dbus-access is another interface to allow dbus communication between two apps on specified object paths
<morphis> which then summary allows soemthing like: https://pastebin.canonical.com/156418/
<morphis> dbus-access creates just one slot-side apparmor rule so far: https://paste.ubuntu.com/16388712/
<ysionneau> Isn't there any other possibility than /dev/ptmx being a directory ?
<ysionneau> 'cause I find this highly unlikely :/
<jdstrand> morphis: the fact that it slots the service1 and service2 means it would be connectable between snaps (in the current implementation). also, what if I create a snap that does path: /org/freedesktop/NetworkManager ?
<morphis> however this introduces one problem: anyone could try to get access to anything if not prohibited in some way
<jdstrand> ysionneau: there could be a bug somewhere-- but I can't reproduce. if you can, please file
<morphis> jdstrand: yeah, I see the same problem
<ysionneau> well I can reproduce it but on a hardware I am the only one to possess :p
<ysionneau> I would try on my rpi2 but I guess it won't reproduce
<morphis> jdstrand: but I don't see another way so far how we can allow dbus communication between apps of the same snap
<morphis> we could limit the dbus-access rule to check for label=snap.<snap-name>.*
<ysionneau> let's try on the rpi2 anyway
<jdstrand> morphis: so internal snap communications should be allowed imo, but using dbus in this manner is using a public bus to do internal communication
<morphis> sure
<jdstrand> I wonder if you used a private bus?
<morphis> then we loose the capability for other snaps to communicate with us
<jdstrand> just spitballing here
<morphis> or would require us to proxy between two dbus-daemons
<jdstrand> morphis: but you said modemmanager was only for internla?
<morphis> yes
<jdstrand> oh so you are saying nm is external and mm insternal, that is an issue. I can see that
<morphis> if we just leave modem-manager running against its own dbus-daemon we introduce a set of complex problems in the interface from network-manager
<jdstrand> if both were internal, maybe a private bus could be used
<morphis> yes
<jdstrand> morphis: I'm not sure... I think this needs zyga and niemeyer
<morphis> jdstrand: yeah, just wanted to get your first feeling about this
<jdstrand> morphis: well, I think the use case is interesting. I think there are some issues to work through
<morphis> jdstrand: basically I would like to escape a bit from the need to write an interface in snappy core for everything
<morphis> that slows things terrible down
<jdstrand> I can understand that
<jdstrand> I can say that things should go much faster once we have some experience and have worked through the corner cases
<jdstrand> the thing is now, everything is new and needs to be thought through a lot
<jdstrand> I mean,  they'll all need to be thought through a lot, but in the future we will have already thought through big parts
<morphis> yeah!
<jdstrand> man, why is my irc so laggy?!
<morphis> freenode :-)
<jdstrand> seb128: hi! do you know of something that uses appmenu that I can use for bug #1581191 ?
<ubottu> bug 1581191 in snapd (Ubuntu) "please add AppMenu to the unity7 interface" [Medium,Triaged] https://launchpad.net/bugs/1581191
<jdstrand> it seem slibreoffice does
<jdstrand> I'll see if I can work with that
<seb128> jdstrand, check with tedg I would say, I'm unsure when/when com.canonical.AppMenu is used
<jdstrand> codesearch indicated libreoffice does. I'll play with that
<jdstrand> seb128: thanks!
<seb128> yw
<seb128> k
<ShR3K> Is there a solution to have snappy on tablet like Nexus 7 or Aquaris M10
<ShR3K> ?
<ysionneau> hmmm I can't get the RPI2 to boot anymore with Snappy :o
<ysionneau> I've just generated a brand new rpi2 image using zyga's ubuntu-image
<ysionneau> it says "Starting kernel ..." and nothing more
<jdstrand> seb128: fyi, libreoffice in at least xenial does not use AppMenu
<ysionneau> is the rpi2 port broken as of today?
<jdstrand> tedg: hey, can you give me an example application that uses AppMenu (it could even be a test program)
<tedg> jdstrand: I believe that GTK apps do, it's the registration mechanism.
<tedg> jdstrand: It'll need to have the unity-menus module loaded
<tedg> jdstrand: Which might not be in your snap.
<jdstrand> tedg: so, I've seen some things with dbusmenu and a lot of things for gmenu. global menus seem to work
<jdstrand> tedg: it sounds like perhaps if I add unity-menus to stage-packages in a snap I might start to see AppMenu accesses?
<jdstrand> would it work for say, gnome-calculator-app?
<jdstrand> and ftr, I can't wait for unity8
<tedg> jdstrand: I believe so, it depends on the app. Let me check that one.
<jdstrand> these dbus apis for menus are not very mediation-friendly
<tedg> jdstrand: No, they were designed in a simpler time :-)
<jdstrand> I wonder what we are going to do when someone finds a way to attack the menu system of another app...
<tedg> jdstrand: It really only tracks by window ID really. So we have no good way to verify either.
<tedg> jdstrand: Perhaps with X11 AppArmor stuff?
<jdstrand> nope
<jdstrand> that was ruled out
<jdstrand> (in the sprint this week)
<tedg> jdstrand: Ah, makes sense, but not up to date :-)
<jdstrand> if anything is done for X (subject to desktop team priorities) it will be a nested X
<tyhicks> jdstrand: sit tight on the global menu stuff - I'm gathering info
<tyhicks> jdstrand: it sounds like people may be mixing up the global menu and the indicators
<jdstrand> tyhicks: well, I'm still going to fix the things I know are broken. eg, I have a PR for the systray bug for notifications and then preparing another one that makes libreoffice work
<jdstrand> tyhicks: I talked with tedg about AppMenu. See the conclusion: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1581191/comments/1
<ubottu> Launchpad bug 1581191 in snapd (Ubuntu) "please add AppMenu to the unity7 interface" [Wishlist,Won't fix]
<jdstrand> tyhicks: I guess that counts as 'sit tight'
<Trevinho> jdstrand: asf far I cheked, the appmenu interface was supported by ubuntu-qt module...
<jdstrand> Trevinho: do you have a snap I could try this on?
<jdstrand> tedg: was that one you looked at? ^
<tedg> jdstrand: No, I was looking at GTK apps, I thought they still used it.
<tedg> Didn't think of the Qt one.
<Trevinho> jdstrand: mh, no.. but you can do it with any simple electron app. They are using appmenus (sadly, so I'll probabably fix it upstream), but even the electron simple binary uses it
<Trevinho> tedg: yeah... as for qt btw I (or someone else) will probably move the things to menumodel... most of the pieces are already there
<jdstrand> Trevinho: I'm unfamiliar with electron apps. is there a simply one you can point me to?
<jdstrand> erf, it looks like they embed chromium
<jdstrand> sergiusens: don't you have an electron app?
<kyrofa> jdstrand, yes he does!
<kyrofa> jdstrand, vscode and atom in progress
<Trevinho> jdstrand: I guess snapcrafting https://github.com/electron/electron-quick-start is just enough
<zyga> good morning
<jdstrand> so, if it uses chromium, perhaps I can play with chromium to see if it needs the accesses
<jdstrand> chromium works fine with my two PRs
<elopio> ogra_: can you please change the daily os snap builds to use the new edge PPA, instead of the image one?
<ogra_> elopio, where is that ?
<ogra_> (you also need to let mvo know where to upload to then)
<elopio> ogra_: no, I've forbidden mvo to upload here. :)
<elopio> ogra_: https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages
<elopio> the rc snap will be generated from -proposed. And the stable from the xenial archive. But we can talk about that in a few mins.
<ogra_> yeah, lets talk
<ogra_> (there are a bunch of issues since we need the PPA for development)
<morphis> jdstrand: my current implementation is now at https://github.com/morphis/snappy/commit/7d4a725b6fa72ee80558fbb1ab19b4340acb8640 (dbus-name) and https://github.com/morphis/snappy/commit/38d60ce083d1684b20d7394ad5f6824a298efd9d (dbus-access)
<morphis> jdstrand: which actively prevents the interface connections from plugs/slots which are not part of the same snap: see https://github.com/morphis/snappy/commit/0489b6f23b190d817975247d460990f67e0c4d5c#diff-79bf2731f5c1893501e7731ecbcf7059R58
<morphis> zyga: ^^ you might be interested in that as well, prototyped a quick idea today to enable in-snap dbus communication
<morphis> not ready yet for an MP and we should discuss that next week or so a bit more in detail
<morphis> jdstrand, zyga: see https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/examples/tree/ for two snaps which are using those two things
<jdstrand> morphis: interesting
<morphis> don't count on any names/patterns or so yet
<jdstrand> well, it is a starting point for discussion
<kyrofa> jdstrand, I tested out https://github.com/ubuntu-core/snappy/pull/1165 and had a question on the PR
<morphis> jdstrand: yeah
<morphis> so, weekend time :-)
<jdstrand> kyrofa: hmm I didn't play with the indicator bit (I missed it)
<jdstrand> kyrofa: let me look at that
<kyrofa> jdstrand, excellent, thank you!
<jdstrand> ok yes I can confirm
<kyrofa> jdstrand, ping me if/when you add something there and I can retest
<zyga> morphis: interesting, let me see
<zyga> morphis: that's really cool
<zyga> morphis: I think we should explore the attribute matching on slots and plugs
<zyga> morphis: so you'd have a slot 'bus-name' with an attribute 'com.example.App'
<zyga> morphis: and a slot with something similar
<zyga> s/slot/plug/
<zyga> morphis: and only allow the connection to form when those match
<zyga> morphis: we need to get a callback for connection attempt
<zyga> morphis: by default it should just check the interface name on both ends
<jdstrand> zyga: one thing I'm concerned about is squatting a well-known name
<zyga> morphis: but this would need it to match attributes too
<zyga> jdstrand: that's a review process
<zyga> jdstrand: we'll let people do squatting in private
<zyga> jdstrand: then nail it in review
<zyga> jdstrand: (stateful review matters)
<zyga> brb
<jdstrand> zyga: I think we should discuss this with niemeyer next week
<jdstrand> zyga: (since morphis is eow)
<jdstrand> kyrofa: ok, pushed
<kyrofa> jdstrand, sweet, testing now
<jdstrand> kyrofa: https://github.com/ubuntu-core/snappy/pull/1165/commits/de024b32878e82d8b28e695a83641f2883d3f1f0
<kyrofa> jdstrand, perfect
<kyrofa> Works great
<zyga> jdstrand: that's a plan
<zyga> jdstrand: note that we anticipated some of this with the $syntax
<zyga> jdstrand: where an attribute starting with the dollar sign was reserved
<jdstrand> kyrofa: \o/
<jdstrand> zyga: interesting
<morphis> jdstrand: mostly eow
<morphis> zyga: thanks for a having a first look
<zyga> morphis: I'll have to talk to gustavo about the implication of getting the generic IPC interfaces in place
<morphis> zyga: thanks
<zyga> morphis: and we should open a pull request only after this is done
<morphis> zyga: the background for this is basically:
<zyga> morphis: one more thing, I think the connection "sanitization" method is needed in the interface
<zyga> morphis: so that we can reject right there without a hook
<zyga> morphis: and so that it is a natural place to enable hooks later
<morphis> we thought this morning about: what if we do a snap which privides modem-manager and network-manager but we only want it for a specific vendor and only want to provide an external interface for network-manager
<morphis> putting those bits into a network-manager interface doesn't sound right
<zyga> morphis: hmm, maybe
<morphis> and we should have a way to allow in-snap IPC communication
<zyga> morphis: yes, I agree about the 2nd part for sure
<zyga> morphis: still need to think about 1st
<sergiusens> jdstrand I have a vscode one to share with you if you want, give me a sec to upload to the store. Can you see unpublished snaps?
<morphis> zyga: for me it does, as we're cluttering a generic network-manager interface then with implementation specifics
<zyga> morphis: I need to think if n-m + mm is a special case
<morphis> zyga: sure, I am still playing with this, will folow up with you guys next week
<morphis> have to leave now!
<morphis> bye
<zyga> morphis: +1
<sergiusens> elopio mind testin 2.8.8b when it comes into proposed?
<elopio> sergiusens: no problem.
<sergiusens> jdstrand putting the snap somewhere you can get, expect to look at PMs
<jdstrand> sergiusens: ack
<Trevinho> jdstrand: a basic electron app could be just https://code.launchpad.net/~3v1n0/+junk/electron-quick-start-snap
<Trevinho> jdstrand: however, I don't see the menus exported there, but it might be cause of many reasons (electron might think that is not running in unity, or missing some gtk stuff - although adding it didn't change much)
<jdstrand> ok. I'll take a look. tedg said maybe some library just needs to be present
<Trevinho> jdstrand: yeah, in the past they were doing a check of the presency of libunity I think
<Trevinho> jdstrand: oh, it was just about including libdbusmenu-glib4 as stage package... http://i.imgur.com/RH6Jhgd.png
<jdstrand> nice!
<jdstrand> I'll take a look in a few minutes
<Trevinho> jdstrand: ah, I didn't check the unit7 rules, are the libunity apis already available for users (the ones that add badges and progress bars to the launcher)?
<jdstrand> Trevinho: some are, I'm sure there are some missing (I lacked an example)
<Trevinho> jdstrand: mh, hello-unity should be snappified in the examples, it's a good way to test things
<Trevinho> jdstrand: I mean this one http://bazaar.launchpad.net/~snappers/snappy-playpen/trunk/files/head:/hello-unity/
<jdstrand> Trevinho: ok. I think I tried that before, but it was weeks ago
 * jdstrand tries again
<jdstrand> Trevinho: did you commit your libdbusmenu-glib4 change to the junk branch?
<Trevinho> jdstrand: the wrapper has i386 arch, so I guess you want to change that
<jdstrand> oh maybe that is all it was
<Trevinho> jdstrand: speaking of which... do we plan to ship better "default" scripts for such cases?
<jdstrand> Trevinho: I think that is a sergiusens question
<Trevinho> and to to use the arch for the builder...
<Trevinho> jdstrand: ah, yeah...
<Trevinho> Also, it would be nice to be able to generate .cache files (such as the mime type or the libgdk pixbuf plugin liest....) from the files installed locally.. So chrooting where the fiels have been eextracted and running thr proper tools at build time
<Trevinho> same for compiling gsettings schemas...
<jdstrand> yeah, I think the desktop team maybe was looking into that
<jdstrand> I know I faced it and so did they
<Trevinho> I mean, a plugin that alows to run stuff on the staging dir
<jdstrand> sergiusens: ^
 * Trevinho is part of that team too (although, looking at this out of my work scope right now) :)
<Trevinho> So, what I'd like to know, sergiusens, is what would be the best way to do this with the current architecture...
<jdstrand> Trevinho: fyi, http://paste.ubuntu.com/16397996/
<jdstrand> Trevinho: that is what I recall seeing now that I think of it
<jdstrand> tedg: fyi, I can't seem to find anything related to 'unity-menus'. I'm going to try unity-gtk3-module
<Trevinho> jdstrand: what you need?
<tedg> jdstrand: Yes, that sounds right.
<Trevinho> jdstrand: the unity-gtk3-module is only used for gtk3 apps that export menus though libgmenumodel
<jdstrand> Trevinho: just mentioning that hello-unity doesn't work cause of that traceback. I know you're off so just fyi
<Trevinho> jdstrand: yeah, I've seen it... i was looking if I can find a solution
<jdstrand> oh you were asking about the unity thing
<jdstrand> the menu thing
<jdstrand> Trevinho: all you did for electron-quick-start was add libdbusmenu-glib4 to stage-packages?
<sergiusens> Trevinho ok, so you should be able to modify the staging dir, only consume from it
<Trevinho> jdstrand: yep
<sergiusens> Trevinho if you recompile this code patched that has fixed path expectations won't it be better?
<Trevinho> sergiusens: the problem is with file that are normally generated at post-install time... it's not about paths, since these are fixable even without recompiling
 * sergiusens really thinks that stage-packages are broken until people start making those stage-packages work wih PIC
<Trevinho> sergiusens: things like gsettings schema
<Trevinho> we'd need something that, once the staging dir is full of the things, we go into that in a mode like chroot, and we generate the files we should... Like mime cache, pixbuf helpers chace, compiled gsettings schema
<sergiusens> Trevinho does gsettings schema work with relative paths? Can it use envvars? Those are the things that would need fixing
<Trevinho> sergiusens: you can generate it wherever you want... All you need is call glib-compile-schemas /path/where/they/are
<Trevinho> sergiusens: but we need to do this just before the snap is going to be packaged
<Trevinho> in its context
<ogra_> why not from a startup wrapper (where you have the actual paths available) ?
<Trevinho> ogra_: since it's ro?
<ogra_> a snap has rw areas
<ogra_> at runtime
<Trevinho> well, sure... for something we could use it..
<Trevinho> so it's just about defining a XDG_DATA_DIR (for the glib-2 case), or an env pointing to that writable space
<Trevinho> but.. Since in general these paths can be modified with env variables, it would be also nice to build the most we can at snappification tiem
<Trevinho> time*
<ogra_> hmm, i think XDG_DATA_DIR is even being set by the ubuntu-app-launch bit
<Trevinho> we can redefine it.. it's a :-separated list
<Trevinho> and we already redefine it
<ogra_> i dont think u-a-l will allow re-defining
<ogra_> (though i'm not sure if it is less strict in the desktop/classic context)
<Trevinho> in the desktop snaps we've done so far we always redefine it...
<ogra_> but inside the snap ... not outside of it
<ogra_> i.e. if i set XDG_DATA_DIR=~/.foo ... that wont be handed to the app
<ogra_> only if it is done inside the snap via a wrapper or some such
<Trevinho> yes, sure...
<jdstrand> Trevinho: fyi, I need to move on to something else, but fyi, running electron-quick-start doesn't display anything. the command just hangs. I'll circle back next week perhaps
<Trevinho> jdstrand: well.. it works fine here... but maybe because i'm running it in --devmode?
<Trevinho> installing*
<jdstrand> I didn't see any denials
<jdstrand> I guess I can try with that
<Trevinho> Ah, yeah...it doesn't run in non-devmode
<Trevinho> I need to check what's going on
<Trevinho> it was my next step :)
<jdstrand> I see. I can confirm it does work in devmode
<jdstrand> weird that there were no denials
 * jdstrand disables rate limiting
<Trevinho> jdstrand: what shouuld I check to see what's wrong? I was thinking about strace, but... anything else?
<jdstrand> that is what I would start with
<jdstrand> well, after looking in syslog for denials
<jdstrand> (they're aren't any atm)
<jdstrand> it might be an explicit denial
<jdstrand> doesn't seem to be that
<jdstrand> sergiusens: erf, vscode is using gconf?
<jdstrand> this is going to be a lot to go through. I think I will do that next week :)
<sergiusens> jdstrand it uses a bunch of G stuff, yeAH
<Trevinho> jdstrand: you can test the launcher apis with https://code.launchpad.net/~3v1n0/+junk/unity-launcher-api-snap
#snappy 2016-05-14
<jdstrand> Trevinho: thanks!
<Trevinho> jdstrand: np, I'm also quite close in getting hello-unity working... Well I've already it running but I've to add .desktop files and some theming, at this point.
<Trevinho> jdstrand: basically that test checks the main things though, counter, progress and dynamic quicklists
<jdstrand> very cool. I've made a note to work through them both
#snappy 2016-05-15
<sgclark> probably me being a dummy, my snap seemed to build fine, installed fine, but I cannot for the life of me sort out how to run it ( I am in a KDE environment )
#snappy 2017-05-08
<zyga> good morning
<morphis> zyga: morning!
<morphis> zyga: did you find any solution for the "cannot find package "golang.org/x/crypto/ssh/testdata"" error on travis?
<morphis> ogra_: ping
<zyga_> morphis: hey
<zyga_> hey ara :)
<ara> morning zyga :)
<morphis> zyga: hey :-)
<zyga> morphis: I commented on https://github.com/snapcore/snapd/pull/3271 - trivial stuff if you want to apply that
<mup> PR snapd#3271: cmd/snap-confine: use /etc/ssl from the core snap <Created by morphis> <https://github.com/snapcore/snapd/pull/3271>
 * zyga goes back to reviews
<morphis> zyga: what is the difference between details and description?
<morphis> ah looks like I did that wrong until now
<morphis> and spread doesn't complain about details:
<morphis> s/details:/description:/
<zyga> morphis: it's not used at all
<morphis> zyga: yeah, just saw that I used description: in all my previous MPs
<zyga> morphis: but you didn't give any details or description so I wrote some :)
<zyga> morphis: it's a purely human-readable thing
<morphis> will clean that up
<zyga> morphis: thanks!
<morphis> zyga: fixed https://github.com/snapcore/snapd/pull/3271
<mup> PR snapd#3271: cmd/snap-confine: use /etc/ssl from the core snap <Created by morphis> <https://github.com/snapcore/snapd/pull/3271>
<zyga> morphis: thank you
<morphis> zyga: also updated https://github.com/snapcore/snapd/pull/3274
<mup> PR snapd#3274: cmd/snap,tests/main: add force-devmode switch instead of spread system blacklisting <Created by morphis> <https://github.com/snapcore/snapd/pull/3274>
<zyga> morphis: great, thank you
<morphis> that one still needs conversion of all other tests not converted yet but once I get a pass from travis I will do that
<zyga> morphis: replied
<zyga> morphis: one thing about !
<morphis> fixed
<zyga> morphis: great!
 * zyga -> coffee
<zyga> brb
<ali1234> morning. can i get some help finishing my sigrok snap and getting it into the store?
<zyga> ali1234: hey, what kind of help do you need
<ali1234> it works with strict confinement, i just need to finish off the house keeping: build dependencies, version number etc
<ali1234> and get it uploaded
<ali1234> cleanbuild still does not work for me
<ali1234> also i have a weird bug where Qt apps are not themed correctly, but that affects every snap afaict
<ali1234> every snap on my system i mean
<ali1234> https://github.com/ali1234/mysnaps/blob/master/sigrok/snapcraft.yaml is what i have
<ali1234> oh, also i'm not sure why i need the network plug. libusb uses netlink and raw-usb alone isn't enough to make it work
<zyga> ali1234: themes are hard :) https://forum.snapcraft.io/t/use-the-system-gtk-theme/496/4
<ali1234> oh, so its because i don't use the default theme?
<ali1234> okay, well i guess that's the least important issue
<zyga> ali1234: yes, because the theme in the snap is not the same as the themes in the system
<zyga> ali1234: can you share dmesg | grep DENIED
<ali1234> for what? the netlink thing?
<zyga> ali1234: and also dmesg | grep type=1326
<zyga> ali1234: this will show any apparmor and seccomp denials
<ali1234> if i have the raw-usb plug but not the network plug i get: type=1400 audit(1494097705.817:107): apparmor="DENIED" operation="create" profile="snap.sigrok.sigrok-cli" pid=8274 comm="sigrok-cli" family="netlink" sock_type="raw" protocol=15 requested_mask="create" denied_mask="create"
<zyga> so we can figure out what sigrok is doing that needs more interfaces
<zyga> aha so NETLINK_KOBJECT_UEVENT
<ali1234> it may be that sigrok supports analyzers on ethernet and is trying to scan for them
<ali1234> i am not sure, i only have a usb one to test with
<zyga> the good news is that we have some nice netlink interface lately
<zyga> even if sigrok requires a dedicated interface one can be crafted very quickly
<ali1234> as i said, it works with the network plug
<ali1234> and sigrok does support ethernet devices according to the hardware page
<ali1234> i think it can use rs232 devices as well
<ogra_> morphis, yes ?
<morphis> ogra_: I saw https://paste.ubuntu.com/24535422/ in a spread test this morning
<morphis> ogra_: any idea?
<ogra_> morphis, ouch ... looks like there was a newer shadow version uploaded to the archive ... overriding the PPA
<morphis> uups
<morphis> zyga: looks like you referenced the wrong link in https://github.com/snapcore/snapd/pull/3277#issuecomment-299792600
<mup> PR snapd#3277: cmd/snap, client: add "whoami" command <Created by chipaca> <https://github.com/snapcore/snapd/pull/3277>
<zyga> aha, thanks
<morphis> ogra_: if you want more details https://travis-ci.org/snapcore/snapd/builds/229850432?utm_source=github_status&utm_medium=notification
<ogra_> morphis, i dont need any details ... i need to merge a package :P
<morphis> :-)
<zyga> corrected :)
 * ogra_ sighs ... and indeed its a manual merge, the CVE fix touches the same file
<abeato_> ogra_, hey, is there any way I can avoid starting console-conf on first run?
<ogra_> abeato_, i think you can touch some file but not sure what the path was ... perhaps mwhudson can help
<morphis> abeato_: there is, have a look at our tests-extras repo
<ogra_> (not sure how the getty setup reacts on that though ... there is some special setup to print the IP and ssh keys)
<morphis> abeato_: https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/tests-extras/tree/create-image-scripts/create-image.sh#n135
<ogra_> (and to prevent spawning a login prompt)
<abeato_> morphis, I see, thanks
<abeato_> ogra_, well, provided I get a shell I can manage :)
<ogra_> if you would that would be a bug :)
<ogra_> you shouldnt get a shell login offered without configured user
<abeato_> yeah, I will try to create one with a system-user assertion
<ogra_> yeah, that shoudl work
<mwhudson> abeato_, ogra_: /var/lib/console-conf/complete i think
<abeato_> mwhudson, great... how can I some debugging for console-conf, anyway?
<ali1234> what approach should i take to automatic building and versioning?
<ali1234> upstream has this repo that contains build scripts for various platforms: http://sigrok.org/gitweb/?p=sigrok-util.git;a=tree;f=cross-compile;h=e3013fd578b6d07b55ca32a4c43d082e36cc5e24;hb=HEAD
<ali1234> as you can see, they already have an appimage
<ali1234> it would make sense to put the snapcraft.yaml in here i think
<ali1234> but it builds from several other repos
<zyga> ali1234: you can look at build.snapcraft.io
<zyga> ali1234: it's a free service that's very useful :-)
<ali1234> upstream does not use github though
<zyga> Chipaca: hey
<zyga> Chipaca: do you know if any of the sprint-going people will be around today?
<ali1234> i assume it does the same thing as https://snapcraft.io/docs/build-snaps/ci-integration
<Chipaca> zyga: I don't
<zyga> ali1234: ci integration is sligthly different but I'm not actively using it myself so I could be worng
<Chipaca> zyga: I do know I'm about to go off to a doctor's appointment :-)
<zyga> Chipaca: take care! Look after yourself!
<Chipaca> zyga: this is the physio \o/
<Chipaca> anyway, should be back for the standup
<zyga> sounds good
<ali1234> is it still a thing to prefix your name on packages to prevent collisions?
<mwhudson> abeato_: painfully
<abeato_> lol
<mwhudson> abeato_: ui things get debugged in dry-run mode
<abeato_> yes, that is something I suspected...
<mwhudson> more complicated things mostly by staring at the log file
<abeato_> mwhudson, it is more about some issue with handling interfaces
<zyga> ali1234: if this will be the official snap I'd skip the prefix
<ali1234> it wont be, i am not upstream
<zyga> ali1234: especially if it comes from the upstream repository
<mwhudson> abeato_: as in NICs?
<zyga> ali1234: aha
<zyga> ali1234: maybe try talking to them
<zyga> ali1234: it's just packaging :)
<abeato_> mwhudson, yes
<ali1234> i have done
<zyga> ali1234: and they may like it
<ali1234> they did like it
<zyga> ali1234: if they commit the snapcraft.yaml into their tree
<ali1234> they want to see it working
<mwhudson> abeato_: fun times
<abeato_> mwhudson, where is the log stored for console-conf?
<zyga> ali1234: I don't see why it should be prefixed
<mwhudson> abeato_: /var/log/console-conf
<ali1234> i added my repo on build.snapcraft.io and it says it does not have a snapcraft.yaml
<ali1234> this is not true, it actually has three
<abeato_> mwhudson, ok, thanks
<zyga> ali1234: it looks at a specific location, where are your snapcraft.yaml files?
<zyga> ali1234: perhaps ask in the forum (forum.snapcraft.io) as the people working on this are in other timezones
<ali1234> well the sigrok one is in sigrok/snapcraft.yaml
<ali1234> if it goes in upstream it will be in cross-compile/snap/snapcraft.yaml
<mwhudson> abeato_: you could try using a system user assertion to have an account created on first boot and then poke around more interactively
<zyga> ali1234: AFAIR it can be in (paths) snap/snapcraft.yaml or snapcraft.yaml relative to the root of the project
<mwhudson> but that's a bit hairy too
<zyga> ali1234: it cannot be in an arbitrary location
<ali1234> okay i will fork upstream repo and try with that
<abeato_> mwhudson, yes, that is something I want to do too
<mwhudson> abeato_: what sort of problem are you having?
<abeato_> mwhudson, the one signing the system-user assertion should be the same that signed the gadget snap, right?
<abeato_> mwhudson, some issue with interface configuration, it looks apparently configured but I cannot reach the store
<mwhudson> abeato_: s/gadget snap/model assertion/ i think, but yes
<abeato_> mwhudson, yes, model :)
<mwhudson> abeato_: ugggh
<ali1234> although it won't work for upstream since it isn;t on github
<ogra_> well, unconfigured interfaces still run a dhclient
<ogra_> even before cvonsole-conf ever comes up
<abeato_> mwhudson, not sure if maybe the issue comes  from some p2p0 interface that is around
<abeato_> mwhudson, ogra_ http://paste.ubuntu.com/24535879/
<ogra_> looks like you cant reach your nameserver
<mwhudson> yes i guess you should check for broken / bogus dhcp servers :)
<zyga> ali1234: where is upstream?
<abeato_> ogra_, in fact I can ping the device when I am in the "network connections" screen, but after "configuring" the network, the IP gets lost
<ali1234> http://sigrok.org/gitweb/?p=sigrok-util.git;a=tree;f=cross-compile;h=e3013fd578b6d07b55ca32a4c43d082e36cc5e24;hb=HEAD
<abeato_> it actually removes connectivity instead of providing it
<ogra_> abeato_, yeah, consiole-conf changes it
<ali1234> i am importing that repo to github just for testing purposes
<mwhudson> abeato_: anything incriminating in syslog?
<abeato_> mwhudson, it is pretty difficult for me to grab logs, will change initramfs to get those
<zyga> ali1234: perhaps you could create a launchpad project, setup git mirroring and just build on launchpad with a snap packaging recipe
<zyga> ali1234: build.snapcraft.io is just a fancy front end
<ali1234> yes, that's the thing i linked to before :)
<zyga> ali1234: aha :-)
<mwhudson> abeato_: system user assertion approach probably best then
<mwhudson> i wonder if that is documented anywhere yet...
<ali1234> but the thing is that repo gets pushes all the time for other things
<abeato_> ok
<ali1234> also it doesn't get pushes when the actual source repos are updated
<ali1234> so idk how to make it rebuild properly
<mwhudson> or i dunno, unpack core snap, chroot into it, add a user, repack, reimage, reflash, would that work?
<mwhudson> maybe not actually, you wouldn't get a getty, could always hack up systemd config to make sure you do but that gets a bit involved again
 * mwhudson is rambling, it's a bit late here
<zyga> ali1234: it pulls automatically every 6 hours
<zyga> ali1234: it's not amazing but not terrible either
<zyga> ali1234: and the recipe can build on each push
<zyga> ali1234: look at this:
<ali1234> yes, i understand that
<zyga> https://github.com/snapcore/pi2-gadget
<zyga> this is mirrored on launchpad and built to a snap
<zyga> exactly the way I described
<zyga> and it is documented in the readme
<ali1234> the problem is that the repo gets pushes eg when the appimage changes
<ali1234> but it doesn't get pushes when the source code of the app itself changes
<zyga> look at the links and you can do the same thing
<zyga> aha
<zyga> wait, so where is the source code?
<abeato_> mwhudson, it is an idea... will go first for the system-user assertion though ;)
<ali1234> in several other repos
<zyga> I see
<ali1234> look at the snapcraft.yaml :)
 * zyga looks
<ali1234> https://github.com/ali1234/mysnaps/blob/master/sigrok/snapcraft.yaml
<zyga> well
<zyga> no idea, ask on the forum :)
<zyga> it's an interesting problem for sure
<ali1234> so far everything i tried to snap ended up as an interesting problem :)
<ali1234> that's why my repo is called "museum of broken snaps"
<zyga> ali1234: this is how exploring the unknown feels like :D
<ali1234> none of them actually work
<morphis> zyga: any idea why `snap info core` doesn't print out the snap type on Fedora?
<ali1234> sigrok does now though so i want to promote it :)
<mwhudson> ali1234: i just have a launchpadlib script in cron that triggers a build every 24 hours
<ali1234> mwhudson: doesn't that mean users have to download an update every day, regardless of if anything changed?
<mwhudson> ali1234: http://paste.ubuntu.com/24535900/
<ali1234> the sigrok snap comes out at 74MB
<zyga> morphis: no, can you share the output?
<mwhudson> ali1234: ah yes, well nothing stops you being slightly cleverer in the script i guess :)
<mwhudson> ali1234: i agree this is a problem, i don't have a great solution
<morphis> zyga: https://paste.ubuntu.com/24535903/
<morphis> zyga: on ubuntu that gives me type: core
<zyga> yeah
<zyga> I see
 * zyga looks
<zyga> so we have maybePrintType
<morphis> zyga: yes, but that should print the type for the core snap
<ali1234> um... why doesn't the snapcraft forum have SSO?
<ogra_> its in the works
<morphis> zyga: ok, I know why
<morphis> zyga: `snap list` marks it as broken
<ogra_> morphis, new core with new shadow building ...
<zyga> morphis: aaah
<zyga> morphis: :)
<zyga> morphis: there you go
<morphis> ogra_: nice
<zyga> morphis: /var/lib/snapd/snap vs /snap issue somewhere
<zyga> morphis: broken meant that snapd didn't find the meta/snap.yaml file
 * zyga would really like for snapd to cache snap.info per revision 
<zyga> then we could even lazily mount snaps or keep only one revision mounted instead of three
<zyga> less memory use
<zyga> and we could keep a finite set mounted even if the user has many times more snaps installed (just not running)
<zyga> part of the lifecycle idea we had earlier
<ali1234> does the name: in snapcraft.yaml have to match the registered name on build.snapcraft.io?
<zyga> ali1234: yes
<zyga> ali1234: well
<zyga> ali1234: any name you want really but you need to be able to push snaps there
<ali1234> which?
<ali1234> okay it still can't see the snapcraft.yaml
<ali1234> https://github.com/ali1234/sigrok-util/tree/master/cross-compile/snap
<morphis> zyga: debian should run in force devmode true, right?
<zyga> morphis: yes
<zyga> morphis: unless with ubuntu apparmor patches, then it will be automatically not be devmode
<morphis> ok
<morphis> zyga: hm .. qemu:debian-9-64 .../tests/main/forced-devmode# snap forced-devmode
<morphis> false
<cjwatson> ali1234: one of snap/snapcraft.yaml, snapcraft.yaml, or .snapcraft.yaml has to exist at the *top level* of your branch
<cjwatson> ali1234: (I believe symlinks work)
<ali1234> yeah that's not going to happen
<cjwatson> not my choice, sorry
<ali1234> upstream won't accept it, and that's not my choice
<cjwatson> probably best bring it up on the forum or similar - it's not going to change without user protest
<ali1234> i have done https://forum.snapcraft.io/t/trying-to-build-sigrok-snap/503
<zyga> morphis: interesting
<zyga> morphis: I wonder how is this possible
<zyga> morphis: is it a boolean flip somewhere/
<morphis> zyga: it loosk like there is a problem in my code
<AdamH_> hello, is there a snap with the same sort of functionality as plymouth for Ubuntu core?
<morphis> zyga: ok, was again my fault ..
<ogra_> AdamH_, nope ... not yet (and it would be a bit tricky sinc eplymouth needs initrd inclusion for some use cases)
<ogra_> AdamH_, i'm locally playing with uboot spash screen but dont have anything to look at yet
<ogra_> *splash
<ogra_> that wont help much with the rest of the boot though ...
<fgimenez> ogra_: the new core (1870) fixes the ubuntu-core-create-user error https://travis-ci.org/snapcore/spread-cron/builds/229908080 all green now
 * ogra_ hugs fgimenez ... thanks for the feedback !
<zyga> :-)
<zyga> I could use a simple review for https://github.com/snapcore/snapd/pull/3262/files
<mup> PR snapd#3262: cmd/snap-confine: aggregate operations holding global lock <Created by zyga> <https://github.com/snapcore/snapd/pull/3262>
 * zyga goes back to other reviews
 * ogra_ ponders to add a check to the core build scripts with a blacklist of packages we dont want from the archive 
<ogra_> so it would fail the next time a newer shadow is there
<fgimenez> ogra_: :) thank you! morphis ubuntu-core-create-user should pass with the new core
<morphis> fgimenez: great!
<AdamH_> ogra_: Thanks, If you need any help testing let me know. I will come back to this task later. Still plenty to develop!
<ogra_> will do, thanks for the offer
 * zyga afk for a moment
 * Chipaca returns
<Chipaca> fgimenez: do you know what's up with ubuntu-core-16-64:tests/main/ubuntu-core-create-user ?
<Chipaca> ogra_: or maybe you?
<Chipaca> /usr/bin/chfn: unrecognized option '--extrausers'
<Chipaca> ^
<ogra_> Chipaca, fixed already
<ogra_> re-run wih a newer core
<Chipaca> woot
<Chipaca> ogra_: what had happened?
<ogra_> Chipaca, CVE upload in the archive with a higher version
<ogra_> so the PPA package wasnt used anymore
<Chipaca> ogra_: in an ideal world we'd get alerted when that happened, yes?
<ogra_> Chipaca, yes. see what i wrote above ...
<ogra_> gra_ ponders to add a check to the core build scripts with a blacklist of packages we dont want from the archive
<ogra_> <ogra_> so it would fail the next time a newer shadow is there
<Chipaca> ogra_: yeah!
<Chipaca> must be blind because i scanned up several times and didn't spot you saying that there
<sborovkov> Is mvo not around today?
<Chipaca> sborovkov: I wouldn't be surprised if he took the day off
<Chipaca> (he's been travelling back from the sprint)
<Chipaca> JamieBennett might know more
<sborovkov> that's fine. it's not urgent anyway
<sborovkov> just wanted to ask him to add another rpi config option
<JamieBennett> sborovkov: he is on vacation today
<ogra_> sborovkov, just provide a PR ;)
<ogra_> sborovkov, just provide a PR ;)
<ogra_> oope
<ogra_> *oops
<ogra_> sorry
<sborovkov> oh right I can do that
<sborovkov> and it seems it should be one liner
 * ogra_ notes he just killed his pi3 boot ... adding a unit to multi-user-target.wants that has a Before=network.service inside seems to not be such a clever thing ...
<Chipaca> ogra_: it shouldn't kill it though
<Chipaca> ogra_: systemd will break the cycle by ignoring a unit at random
<ogra_> Chipaca, well, ssh doesnt come up, i'm in the living room having some lunch, board is upstairs in the office ...
<Chipaca> ogra_: guess which one it chose to break the cycle
<ogra_> hehe
<Chipaca> ogra_: easy to fix without going upstairs: power cycle the house
 * ogra_ plugs two fingers in the socket
 * Chipaca sends flowers
<ogra_> ah, damn, you said cycle ... means i need to go to the basement after the fuse blew
<ogra_> so that ends up in being the same effort ... i'll just finish lunch :P
<AdamH_> Any pointers on where to look to rotate the screen to portrait and hide the cursor? I am using mir-kiosk but can't see any config files or options?
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<sborovkov> ogra_: who should I ask to take a look at that pr - https://github.com/snapcore/core/pull/38
<mup> PR core#38: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<ogra_> sborovkov, you are aware that enabling the usb mode isnt reversible ? ... not sure thats a clever thing to have in the default options
<ogra_> (or did that bevaiour change)
<ogra_> *behaviour
<sborovkov> ogra_: I am not sure about that behavior, but how can I set it otherwise? Configure hook will comment out everything else in config.txt and well without it I can't even set it
<sborovkov> at all
<sborovkov> and we want to use that option eventually because SD cards are dying very often and that's actually super cool feature
<Chipaca> sborovkov: question, have you signed the CLA?
<ogra_> sborovkov, oh, why are your SD cards dying ?
<Chipaca> (couldn't figure out your lp nick from your irc nick, if you have an lp account, which is the easiest way of me checking CLA status)
<sborovkov> ogra_: well we have around 10000 rpis in production... that's the most frequent case of failure
<sborovkov> Chipaca: not sure - https://launchpad.net/~serge-borovkov
<Chipaca> sborovkov: that's a nope
<sborovkov> Chipaca: where do i sign it actually? here? https://www.ubuntu.com/legal/contributors/submit
<ogra_> sborovkov, and adding 10000 USB keys is a cost effective solution ? :)
<Chipaca> sborovkov: yep
<sborovkov> ogra_: it actually is. Because for the bigger clients especially they can have a bunch of devices across the country. Sending technician to replace SD card for them is not very convenient and would cost more
<sborovkov> Chipaca: Please add the Canonical Project Manager or contact. Who should I list here?
<Chipaca> sborovkov: Jamie Bennett
<zyga> re
<Chipaca> mi
<ogra_> fa
<zyga> so
<zyga> Chipaca: I think we want to do a small experiment on exposing interface meta-data
<zyga> Chipaca: e.g. an optional method
<zyga> Chipaca: that returns a struct
<zyga> Chipaca: that has various stuff
<zyga> Chipaca: it could replace AutoConnect
<zyga> Chipaca: Name
<zyga> Chipaca: (well, if we do Name it could be mandatory)
<zyga> Chipaca: it could return description
<zyga> Chipaca: and one-to-many/many-to-many
<zyga> Chipaca: what do you think?
<Chipaca> zyga: you mean so the client could make smarter decisions for tab completion?
<zyga> Chipaca: yes
<zyga> Chipaca: and we could show nice stuff in CLI
<zyga> Chipaca: e.g. (what is this interface)
<zyga> Chipaca: is that interface restricted
<zyga> Chipaca: whatever we can come up with
<Chipaca> zyga: could do. Or we could add something on the daemon like "what can connect to <this>"
<zyga> Chipaca: it's just a struct
<Chipaca> ah, yeah, that'd be nice to have
<zyga> Chipaca: yes, that's possible too but I think we want the meta-data anyway; I agree that the daemon may make better decisions about what to suggest as an option
<Chipaca> zyga: that would make âsnap interface foo:barâ make sense
<zyga> Chipaca: especially if we could get rid of some of the optional boring copy pasted methods now
<zyga> Chipaca: yes!
<zyga> Chipaca: I just +1'd 3214
<zyga> shall I merge?
<Chipaca> oh! that old thing
<Chipaca> zyga: sure! :-)
<mup> PR snapd#3214 closed: cmd/snap: iterate interface tab completion <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3214>
<zyga> Chipaca: if you review https://github.com/snapcore/snapd/pull/3272 quickly we could land it
<mup> PR snapd#3272: add interfaces-shutdown-introspection spread test <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3272>
<zyga> it has 1.9 +1s
<Chipaca> zyga: on it
<Chipaca> jdstrand: snapd#3272 is GTG, unless you want to remove the restore section RSN we should land it
<mup> PR snapd#3272: add interfaces-shutdown-introspection spread test <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3272>
<Chipaca> bitrot an' all that
<jdstrand> Chipaca: hey, I can remove it
<Chipaca> jdstrand: your call :-)
<Chipaca> you've got the +1s either way
 * Chipaca goes in search of tea
<zyga> Chipaca: I can remove it
<zyga> jdstrand: oh
<zyga> jdstrand: hey :)
<jdstrand> zyga: hey :)
 * zyga read backlog in the wrong order :D
<zyga> jdstrand: go ahead then, I'll gladly merge it when tests show green
<zyga> fgimenez: did you see this:
<zyga>    __all__: The name test-snapd-kernel-module-control-consumer should not be longer than 40 characters.
<fgimenez> zyga: sure, there's a problem with snaps already in the store with a name longer than 40chars, currently they cannot be updated
<zyga> I need to look at that ensure prune loop test, it is failing again while it should not
<zyga> fgimenez: yeah, should we truncate the name then?
<fgimenez> zyga: i already pinged nessita about this, i think a fix is on its way to allow the snaps already in the store to be updated
<zyga> fgimenez: thanks
<fgimenez> zyga: anyway in the kernel-module-control case the snap changes are only related to add a simple command to the snap, this pattern is common to other tests and maybe we could create a generic-consumer snap, i'm working on a branch with this approach
<morphis> zyga: who else do we need to do a review on https://github.com/snapcore/snapd/pull/3271 ?
<mup> PR snapd#3271: cmd/snap-confine: use /etc/ssl from the core snap <Created by morphis> <https://github.com/snapcore/snapd/pull/3271>
<sborovkov> ogra_: but AFAIK rpi needs to be booted from SD card first before you can boot from USB? So how will that work if we set the option in gadget code initially
<ogra_> sborovkov, you would still need to boot from Sd first indeed .... the bootloader blob then sets the ROM option and on reboot you can use USB
<ogra_> (but thats completely unrelated to having the option in the config interface or not)
<zyga> niemeyer: hey, are you around for the standup today?
<sborovkov> ah alright, I will create a bug for this then
<ogra_> zyga, or Chipaca i'd appreciate a thumbs up for https://github.com/snapcore/core/pull/37 (fixes the tests along with the change)
<mup> PR core#37: install keyring (LP: #1670475), update pkglists <Created by ogra1> <https://github.com/snapcore/core/pull/37>
<Chipaca> ogra_: standup
<zyga> ogra_: standup?
<ogra_> OMW
<mup> Bug #1689301 opened: Can't set program_usb_boot_mode pi-config option <Snappy:New> <https://launchpad.net/bugs/1689301>
<mup> Bug #1689302 opened: Can't set program_usb_boot_mode pi-config option <Snappy:New> <https://launchpad.net/bugs/1689302>
<sborovkov> Just tried snapd from edge channel. My snap stopped working. Well not completely but I was showing web page and not it does not work (works with stable, installing beta at the moment). In the logs I only found this, any idea what can be the cause?
<sborovkov> May 08 12:49:35 localhost.localdomain kernel: audit: type=1326 audit(1494247775.268:70): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=1499 comm="ld-linux-armhf." exe="/snap/screenly-client/x7/viewer/lib/ld-2.18.so" sig=31 arch=40000028 syscall=281 comp
<sborovkov> May 08 12:49:35 localhost.localdomain audit[1499]: SECCOMP auid=4294967295 uid=0 gid=0 ses=4294967295 pid=1499 comm="ld-linux-armhf." exe="/snap/screenly-client/x7/viewer/lib/ld-2.18.so" sig=31 arch=40000028 syscall=281 compat=0 ip=0x7544b62c code=0x0
<zyga> jdstrand: I'd like to take over https://github.com/snapcore/snapd/pull/3045 by pushing the fixes you requested directly into that PR
<mup> PR snapd#3045: interfaces: add random interface <Created by femdom> <https://github.com/snapcore/snapd/pull/3045>
<zyga> jdstrand: I'm just letting you know in case you wanted to do that as well
<jdstrand> zyga: I didn't have any plans to do that
<sborovkov> ogra_: any idea about my error? Everything works with snapd from beta channel as well.
<ogra_> sborovkov, using the stable kernel i guess ?
<ogra_> could be a missing kernel feature
<ogra_> (definitely sceeomp blocking the linker there)
<ogra_> ask jdstrand if anything in the profiles changed in that regard
<sborovkov> jdstrand: any idea?
<sborovkov> ogra_: only difference is snapd version. gadget snap was not touched. Just upgraded core snap
<Chipaca> sborovkov: we're in a meeting, we're not ignoring you :-)
<sborovkov> haha
<zyga> fgimenez: can you tell me more about that test, so does it fail if I run it in qemu on master?
<fgimenez> zyga: sure, the tests are in this repo https://github.com/fgimenez/validator/tree/master/tests
<zyga> thank you, let me look
<fgimenez> zyga: you need to setup some env vars before executing 1sec
<fgimenez> zyga: http://paste.ubuntu.com/24536879/
<fgimenez> zyga: running "SNAP_CONFINE_DEBUG=yes /snap/bin/test-snapd-tools.echo hello" doesn't give any snap-confine debug output, just the same error "internal error, please report: running "test-snapd-tools.echo" failed: no such file or directory"
<zyga> fgimenez: this doesn't reach snap-confine AFAIK
<zyga> fgimenez: this error comes from snap-run
<zyga> fgimenez: do  you have the debug shell??
<zyga> fgimenez: might be faster than me running it
<zyga> ah actually, let me just
 * zyga runs that
<zyga> raise your hand if you hate ctrl-shit-c working as copy in shell but working as show inspector in firefox
 * zyga misses mac's command-c that works in both places while keeping ctlr-c sane
<fgimenez> zyga: not currently up but will have in a moment
<zyga> fgimenez: no worries, it's running locally already
<fgimenez> zyga: ok i have already the session open in case you need it
<Son_Goku> zyga, niemeyer, morphis: Yo
<morphis> Son_Goku: hey!
<Son_Goku> vacation approved!
<morphis> :-)
<Son_Goku> niemeyer: so I'm looking forward to the email to get things set up for me to be at the snappy sprint at the end of June!
<mup> PR snapd#3277 closed: cmd/snap, client: add "whoami" command <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3277>
<niemeyer> Son_Goku: Sweet, glad that you are going!
<niemeyer> Son_Goku: Let me sort out the initial steps to get the event set up on our end, and will let you know how to proceed
<Son_Goku> niemeyer: excellent
<Son_Goku> have you reached out to the elementary guys yet?
<Son_Goku> they've just completed the first bit of getting an actual appstore frontend
<niemeyer> Son_Goku: Wow, nice
<Son_Goku> https://www.indiegogo.com/projects/appcenter-the-pay-what-you-want-app-store#/
<niemeyer> Son_Goku: We haven't really invited anyone explicitly yet, other than people participating in the thread..
<Son_Goku> ah
<Son_Goku> well, since they do the thing where they actually are building an app ecosystem, it might be a good idea to invite some of those guys :)
<Son_Goku> Cody is on the Snap technical format board like I am, so there's at least that
<mup> PR snapd#3272 closed: add interfaces-shutdown-introspection spread test <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/3272>
<zyga> 3re
 * zyga took a longer lunch break but is now looking at the issue fgimenez reported
<zyga> hmm
<zyga> very interesting
<zyga> fgimenez: so there are a few things
<zyga> fgimenez: one is that I see this in the error log:
<zyga> May 08 16:31:24 autopkgtest /usr/lib/snapd/snapd[1798]: stateengine.go:98: state ensure error: internal error: could not unmarshal state entry "ubuntu-core-transition-last-retry-time": parsing time ""2017-05-08T1
<zyga> this implies that we don't patch the state correctly
<zyga> this is also interesting
<zyga> /snap/ubuntu-core/current/usr/bin/snap
<zyga> ah, wait
<zyga> this is not a core system
 * zyga reads
<fgimenez> zyga: aha, checking the state patching
<fgimenez> zyga: nope, classic
<zyga> fgimenez: right
<zyga> the actual error is that new snapd hard-codes this: /snap/core/current/usr/lib/snapd/snap-confine
<zyga> note the core vs ubuntu-core
<zyga> let me check if that's a bug in the code or is there a fallback
<fgimenez> zyga: ok thanks!
<zyga> fgimenez: yes, it's a simple bug
<zyga> runSnapConfine
<zyga> in this function we need to be bit smarter
<zyga> I think we used to have this code but we may have lost it
<zyga> I'll take the bug to fix it
<zyga> fgimenez: is this tracked anywhere/
<fgimenez> zyga: great thanks a lot
<fgimenez> zyga: not yet
<zyga> offtopic
<zyga> I should patch my systems for the AMT fiasco :(
<zyga> niemeyer: I want snapd to fix my firmware (I know, won't happen on pre-uefi machines) :-(
<ogra_> just turn it off :P
<ogra_> (why do your systems have AMT on ?!?)
<zyga> ogra_: yeah, I did but I actually like some of the features
<zyga> ogra_: well, not anymore ;)
<zyga> ogra_: and they are not on the network
<zyga> ogra_: but still :/
<ogra_> well, then nothing to worry about :)
<zyga> ogra_: my laptop actually has AMT but I just disabled it when I realized this was out there
<zyga> ogra_: I really hope lenovo will make all the bios updates
 * ogra_ has never enabled it in his life
<zyga> ogra_: I tried it since the linaro days, I really wish it wasn't closed and unfixable outside of intel
<ogra_> yeah, thats why i never disabled it ... i find any BIOS driven features that run a network-server a really bad idea
<zyga> ogra_: s/disabled/enabled/
<ogra_> err, indeed :P
<morphis> zyga: did you ever saw something like https://paste.ubuntu.com/24537293/ on Fedora?
<zyga> morphis: you mean the funky unit names?
<morphis> zyga: yes
<zyga> morphis: yes, they are normal
<morphis> really?
<zyga> morphis: this is a systemd requirement
<zyga> morphis: yes
<fgimenez> zyga: https://bugs.launchpad.net/snappy/+bug/1689332
<mup> Bug #1689332: internal error on any command due to missing snap-confine <Snappy:New> <https://launchpad.net/bugs/1689332>
<morphis> zyga: with the '?
<zyga> they must encode the name of the mount directory
<zyga> with ?
<zyga> I don't see ?
<zyga> '?' (question mark)
<zyga> - needs to be escaped
<zyga> as it escapes /
<zyga> as you can see
<zyga> morphis: systemd-escape /foo/bar-froz
<mup> Bug #1689332 opened: internal error with any command using ubuntu-core snap on classic <Snappy:New> <https://launchpad.net/bugs/1689332>
<morphis> zyga: that is fine, but the actual name is 'var-lib-snapd-snap-test\x2dsnapd\x2ddevmode-1.mount'
<morphis> with the quotes
<morphis> zyga: never saw yet that systemd requires the quotes in a file name
<zyga> yes
<zyga> it does
<zyga> run snapd-escape
<zyga> it's also documented in the manual page
<zyga> morphis: no
<zyga> morphis: the quotes are from bash
<zyga> morphis: it's not in the file name
<morphis> zyga: that is funky ..
<morphis> why is bash doing that or better said ls
<zyga> morphis: or actually ls :)
<zyga> morphis: for sescurity
<zyga> morphis: it escapes stuff so it is not nasty
<zyga> morphis: I like that feature :)
<ryebot> Can anyone explain why I'm seeing these?
<ryebot> cmd.go:114: DEBUG: not restarting into "/snap/core/current/usr/bin/snap" ([VERSION=2.24 2.24]): older than "/usr/bin/sn
<ryebot> cannot change profile for the next exec call: No such file or directory
<ogra_> the rest of the "older than" line would be interesting :)
<ryebot> sorry!
<ryebot> cmd.go:114: DEBUG: not restarting into "/snap/core/current/usr/bin/snap" ([VERSION=2.24 2.24]): older than "/usr/bin/snap" (2.24.1)
<zyga> ryebot: hey
<ogra_> that just means it uses the local binary from the deb (because thats newer) instead of re-execing into the snapd binary inside the core snap
<zyga> ryebot: yes, as ogra said
<ogra_> technically it sghould be harmless
<zyga> ryebot: the next line is more interesting
<zyga> ryebot: what were you trying to run?
<ryebot> okay cool
<ryebot> this is our kube-apiserver snap running as a daemon
<ryebot> more complete logs here: http://paste.ubuntu.com/24537348/
<zyga> ryebot: what is the distribution you are running on?
<zyga> ryebot: please pastebin the output of "snap version"
<ryebot> distro: http://paste.ubuntu.com/24537420/
<ryebot> snap version: http://paste.ubuntu.com/24537426/
<mup> PR snapd#3279 opened: tests: extend kernel-module-control interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3279>
<zyga> ryebot: hmm, everything looks ok
<ryebot> zyga: https://bugs.launchpad.net/snappy/+bug/1687079?comments=all
<mup> Bug #1687079: cannot change profile for the next exec call: No such file or directory <Snappy:New> <https://launchpad.net/bugs/1687079>
<ogra_> ryebot, snap refresh core --beta
<zyga> ryebot: can you look if /var/lib/snapd/apparmor/profiles exists
<ogra_> ;)
<ryebot> zyga: looks like I'm waiting on the 2.25 release
<ogra_> just try it from beta ...
<zyga> ah
<ogra_> you can go back to stable at any time with: snap refresh core --stable
<ogra_> (the biggest beauty about snaps ;) )
<zyga> ryebot: I'm afraid something else may be at play
<zyga> ryebot: look at that directory and tell me if you see the apparmor profile of the app you were trying to run?
<ryebot> ogra_: it's a little tricky as this is an automated installation and things seem to work fine after the fact
<ryebot> zyga: looking
<ogra_> ryebot, ah, yozu have no shell access ?
<ryebot> ogra_: not during the image build
<fgimenez> hi jdstrand, quick question, i've noticed that /proc/meminfo is readable by any snap, no matter its confinement, connected plugs, etc, is this intended? http://paste.ubuntu.com/24537464/
<ryebot> zyga: I do see one
<ogra_> fgimenez, same goes for /proc/cpuinfo i think
<fgimenez> ogra_: indeed, it's also readable
<zyga> ryebot: can you run "sudo apparmor_parser -r /path/to/that/file"
<ogra_> iirc it breaks to many things if we disable it
<zyga> ryebot: and try running the application again
<ryebot> zyga: after the first attempt, I am able to run the daemon just fine; sorry, should have made that clear.
<fgimenez> ogra_: aha, ok thanks good to know
<ogra_> also ... meminfo doesnt reveal anything super secret
<zyga> ryebot: interesting
<zyga> ryebot: can you reproduce the issue somehow?
 * ryebot thinks
<ogra_> __chip__, did you grow wings or is that a superhero cape ?
<__chip__> ogra_: it's an old joke about me being "special"
<ogra_> :)
<__chip__> (a pythony joke)
<ryebot> zyga: not trivially -- do you think there's more going on than that bug?
<zyga> ryebot: not sure
<__chip__> also this is my netbook, and i sync logs so i don't want to get them jumbled (nor have to do 3-way merge)
<zyga> ryebot: that bug was about running a kernel without apparmor
<zyga> ryebot: and I don't think you are doing that
<ryebot> This is running in an lxc, if that helps
<ogra_> morphis, so here is a super simple approach to the hciattach ... http://paste.ubuntu.com/24537569/ we'd then just add additional HW to the case statement
<ryebot> Really gotta stop giving you details piecemeal!
<zyga> ryebot: aha
<zyga> ryebot: :D
<zyga> ryebot: yes, that's an interesting and important fact
<ryebot> sorry!
<zyga> ryebot:
<zyga> ryebot: not sure, please let me know if it happens and if it is possible to reproduce
<ryebot> zyga: +1 thanks & will do!
<niemeyer> __chip__: You got a review on #3278
<__chip__> niemeyer: so I do! :-) huzzah
<__chip__> currently wondering about cat pages
<zyga> __chip__: cat pages?
 * ogra_ throws in a mouse page to distract the cat page
<zyga> furry(7)
<jdstrand> sborovkov: hey, what architecture is this on?
<jdstrand> fginther: meminfo should only be available under system-observe on devices where strict confinement is available. what distro is this?
<jdstrand> fginther: sorry
<jdstrand> fginther: that was for fgiminez
<kyrofa> Hey zyga, does the configure hook have a timeout nowadays?
<zyga> kyrofa: yes, but there's a bug that pstolowski is fixing
<zyga> jdstrand: quick questsion about https://github.com/snapcore/snapd/pull/3045 should I allow https://github.com/snapcore/snapd/pull/3045/files as "r" for the -observe interface?
<mup> PR snapd#3045: interfaces: add random interface <Created by femdom> <https://github.com/snapcore/snapd/pull/3045>
<pstolowski> yeah i'm on it
<kyrofa> zyga, how long is it?
<zyga> kyrofa: 5 minutes unless you are hit by a bug
<kyrofa> zyga, good deal, thank you
<kyrofa> zyga, last question: if the timeout expires, what happens? Does the hook "succeed," or does the snap revert?
<zyga> the hook is cancelled but we carry on
<zyga> AFAIR
<zyga> but that's a special-case on core
<zyga> (as in the core snap)
<zyga> not in the core system
<jdstrand> zyga: I'm about to head into a meeting. 'r' for observe, yes. if you are implementing 'control' too, that one has rw
<zyga> jdstrand: I did implement both
<zyga> jdstrand: I'll push and let you review, I probably got the apparmor part slightly wrong but I'll let you comment
<zyga> jdstrand: done
<zyga> ogra_: can you re-affirm my understanding of https://github.com/snapcore/core/pull/37#pullrequestreview-36832829
<mup> PR core#37: install keyring (LP: #1670475), update pkglists <Created by ogra1> <https://github.com/snapcore/core/pull/37>
 * zyga EODs
<ali1234> launchpad build failed with "sigrok.org: Name or service not known"
<koza> ogra_, thanks for the BT on RPI update, reading through it
<niemeyer> Need to step out to run an errand.. will be back later.
<ogra_> zyga, yeah, make check is run by snapcraft anyway (and with the right shellcheck installed)
<ali1234> hmm i broke launchpad
<ogra_> ali1234, no worries, we'll use github meanwhile
<ali1234> but you can't build from github on launchpad
<ali1234> you can't build from any remote afaict
<ogra_> well
<ali1234> you have to import them onto lp
<ali1234> and that doesn't work properluy
<ogra_> snapcraft.io is just a different frontend to the Lp builders ...
<ali1234> yeah the lp builders are what is broken
<ogra_> and you can set up auto imports for foreign git trees
<ali1234> that also doesn't work properly
<ogra_> good enough for our official packages at least
<ali1234> they must be really simple then
<ogra_> we build core, kernels and gadgets that way
<ogra_> not really
<ali1234> do you build anything that needs more than one repo?
<ogra_> we have one that chainloads another one ... but not at the same time though
<ogra_> s/same time/in parallel/
<ali1234> hang on i will write a bug report
<ogra_> yeah, do that
<ogra_> i used to have a kodi snap that used different GH trees in the past ... but that evolved to not do that anymore :)
<mup> PR snapcraft#1286 closed: lxd: Setup image and target arch for cross-compilation <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1286>
<ali1234> ogra_: https://bugs.launchpad.net/launchpad/+bug/1689369
<mup> Bug #1689369: Uploading multiple git repos to a project is confusing <Launchpad itself:New> <https://launchpad.net/bugs/1689369>
<ali1234> here's a crazy idea... what if, instead of having to mess around importing 8 different repos onto lp to make my snap build, what if lp would just read my snap build and import the needed repos automatically?
<ali1234> also its been half an hour and none of the repositories have imported yet
<ali1234> okay the builder can't clone from launchpad anyway
<ali1234> bzr: ERROR: Invalid url supplied to transport: "bzr+ssh://bazaar.launchpad.net/~a-j-buxton/sigrok-snap-test/+git/libserialport": no supported schemes
<ali1234> did anyone try to run snapcraft in docker?
<ali1234> i just get "'ascii' codec can't encode character '\u29f8' in position 19: ordinal not in range(128)"
<nacc> ali1234: fwiw, your earlier message from lp appears to be a mismatch between bzr and git
<ali1234> nacc: it might be because the repositories never imported (they still haven't)
<Chipaca> niemeyer: question for you sah
<ali1234> i have pretty much given up on launchpad at this point, and cleanbuild doesn't work either, hence why i am trying to use docker now, because i know that works
<Chipaca> niemeyer: is stringList still a good name given it's loaded from something that can be a list or not (in json)?
 * Chipaca is bad with names and defers to others' judgement on them (when not having too much fun)
<nacc> ali1234: why doesn't cleanbuild work?
<ali1234> nacc: it cannot connect to https URLs from inside the container
<nacc> ali1234: sounds like a bug in your lxd configuration?
<nacc> ali1234: cleanbuild relies on working lxd
<ali1234> i followed the lxd setup instructions
<ali1234> it doesn't work
<ali1234> *shrug*
<ali1234> docker doesn't require me to spend several days debugging it
<ali1234> it just works
<nacc> ali1234: 'lxc setup instructions'? on ubuntu, `sudo apt install lxd` generally works
<ali1234> yes
<nacc> ali1234: except ... it doesn't? you just said it didn't work
<ali1234> here is the error message: HTTPSConnectionPool(host='parts.snapcraft.io', port=443): Max retries exceeded with url: /v1/parts.yaml (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7f50da481748>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',))
<nacc> well, that's just weird -- parts.snapcraft.io redirects to snapcraft.io just fine
<nacc> and this loads ok: https://parts.snapcraft.io/v1/parts.yaml
<ali1234> yes it loads okay for me, as long as i am not trying to use lxd
<Chipaca> ali1234: are you on 16.04?
<ali1234> yes
<Chipaca> stgraber: you around?
<nacc> ali1234: lxc launch ubuntu:xenial; lxc exec <container> -- wget https://parts.snapcraft.io/v1/parts.yaml
<stgraber> Chipaca: what's up?
<ali1234> bash: container: No such file or directory
<Chipaca> stgraber: ali1234 is getting dns errors inside lxd ^ and i thought maybe you already knew what it might be
<nacc> ali1234: well, substitue the container name for what `lxc launch` retuned
<nacc> *retuned
<nacc> *returned, bah
<ali1234> wget: unable to resolve host address 'parts.snapcraft.io'
<stgraber> ali1234: host parts.snapcraft.io; lxc launch ubuntu:xenial test; sleep 5; lxc exec test -- host parts.snapcraft.io
<ali1234> http://paste.ubuntu.com/24538636/
<ali1234> it took a really long time to time out too
<ali1234> hmm launchpad is syncing those repos now
<nacc> ali1234: when you installed lxd, did you just take the defaults for the network config?
<ali1234> and every time it imports one it retriggers the snap build, so now i am getting spammed with failed build logs
<ali1234> nacc: i can't remember
<ali1234> probably
<ali1234> i can't think of a reason why i would change it
<ali1234> unless there was a question that says "do you want networking to actually work?" if so i would have said yes
<nacc> stgraber: default on 16.04 w/o backports is lxdbr0?
<stgraber> ali1234: can you pastebin "lxc info"?
<ali1234> is it safe to pastebin that certificate?
<stgraber> nacc: yeah which if unconfigured gives you just link-local ipv6
<stgraber> ali1234: yes, it's just the public half of the cert
<ali1234> http://paste.ubuntu.com/24538661/
<nacc> stgraber: right
<stgraber> ali1234: can you pastebin /etc/default/lxd-bridge?
<ali1234> http://paste.ubuntu.com/24538672/
<ali1234> okay i told launchad that the repos are git repos, now the builder says "error: cannot run ssh: No such file or directory"
<ali1234> Command '['git', 'clone', '--recursive', 'lp:~a-j-buxton/sigrok-snap-test/+git/libserialport', '/build/sigrok/parts/libserialport/src']' returned non-zero exit status 128
<stgraber> ali1234: ok, your network is unconfigured
<stgraber> ali1234: run dpkg-reconfigure -p medium lxd
<stgraber> ali1234: using the default values it gives you should be fine
<ali1234> how do i get rid of all the containers that i made while debugging this?
<ali1234> lol it still doesn't work
<ali1234> but now the error is the exact same as the one i got from docker half an hour ago!
<ali1234> 'ascii' codec can't encode character '\u29f8' in position 35: ordinal not in range(128)
<ali1234> apparently it is in a different position now
<ali1234> \u29f8 is â§¸ which looks a lot like / but isn't
<ali1234> Bug #1607015
<mup> Bug #1607015: 'ascii' codec can't encode character '\u29f8' in position 19: ordinal not in range(128) <eco-team> <Snapcraft:Won't Fix> <https://launchpad.net/bugs/1607015>
<ali1234> i see this is a well known problem
<Chipaca> ouh, i missed it
<ali1234> so the problem here is that you put the parts in a wiki, and the wiki turned / into BIG SOLIDUS because it's written by web designers not programmers?
<ali1234> looks like cleanbuild is finally workin
<ali1234> hmm noe
<ali1234> oh wait i've finally got to the point where i need to figure out the build-packages:
<stgraber> ali1234: good, sounds like the LXD side of things is fixed at least. You can use "lxc delete" to remove all the containers you created ("lxc list" to list them)
<ali1234> yeah it's working now, thanks
<ali1234> everything compiled, it got to the copy plugin, then couldn't find the file i asked it to copy
<icey> jdstrand: might be easier to talk about rg here too :)
<jdstrand> icey: hi :) note we are following a specific voting process for things like auto aliases so the discussion should really be in the forum. see https://forum.snapcraft.io/t/process-for-reviewing-aliases-and-auto-connections/455
<ali1234> okay i need to build a qt5 app, but it uses cmake for the build system so i can't use the cmake plugin
<icey> ah, no worries jdstrand  :)
<ali1234> what packages do i need to pull in to get it to build?
<icey> well jdstrand I want to get the actual maintainer to own the snap but he was lukewarm about including the snapcraft.yaml in tree
<icey> he did make the merge but I don't want to push him too fast :)
<lazyPower> How long does it take to get a name approved for the snapstore? I submit a registration for lazy-dex a little over 6 days ago, seems like its stuck in the process somewhere. No feedback that I'm aware of
<lazyPower> icey: nice :)
<lazyPower> thats progress right?
<jdstrand> icey: that is worth mentioning in the forum. note that upstream taking over maintaining the snap is not a requirement, it's just a data point
<icey> lazyPower: yeah :) I have another PR up on another project
<jdstrand> it is progres :)
<icey> jdstrand: I did reply on the forum as well :-D
<jdstrand> progress even :)
<jdstrand> ok, cool
<icey> lazyPower: I've done some community work on rust snaps :)
<lazyPower> i fear the commitment to rust
<icey> haha lazyPower
<lazyPower> :D
<icey> lazyPower: spare time :) (except the work on the plugin)
<lazyPower> I'm still bummed i cant push my snap :S
 * lazyPower is doing charm work with resources :S
<icey> lazyPower: most let me push pretty quickly
<lazyPower> icey: do you just get the ack or what? i submit a request for a non-top-level name last week, i'm still waiting ot hear back
<lazyPower> or do you just not register or?
<icey> lazyPower: I registered both alacritty and ripgrep
<icey> both are currently in --edge
<lazyPower> OH MY GOODNESS
<lazyPower> i didn't even need to request registration
<lazyPower> i can just snapcraft push
<lazyPower> welp nothing to do here then *whistles*
<icey> I think it only matters for "reserved" names lazyPower  :)
<icey> glad I could help lazyPower :-P
<lazyPower> that'll teach me for assuming stuff i guess
<lazyPower> i hit the dashboard and saw the "new snap" button and followed that process
<lazyPower> never again will i follow the rules
<icey> haha lazyPower
<icey> if you try to upload 'lynx' (or other popular? program) it will refuse you
<lazyPower> well i didn't want to own the dex snap until its complete so i figured prefix with my handle is a good starting place
<lazyPower> i think others have done that based on snapcraft search results
<icey> lazyPower: with ripgrep and alacritty, I'm working to push them upstream :)
<lazyPower> icey: dont make this about you :|
<lazyPower> <3
<icey> so I pushed them and published to --edge, you can always transfer ownership as well
<lazyPower> nice
<lazyPower> i doubt coreos is going to jump on maintaining any of their tech in snaps
<lazyPower> who knows though they might
<icey> touche
<icey> as jdstrand mentioned above, being maintained upstream isn't a requirement :) I liek using the --edge channel until a snap is "done" and then for dev style builds
<icey> s/liek/like
<lazyPower> ooo spiffy
<lazyPower> https://dashboard.snapcraft.io/dev/snaps/7608/
<lazyPower> not sure if that link will work for you
<lazyPower> but i'm sorted and in edge
<icey> nah, can't see it :-/ those pages aren't public, not sure if there's a really good place to show a snap that's up
<icey> +1 for somebody making that ^^
<lazyPower> icey: good plan. I'm not sure how to move forward with this until i've had more time to talk with the team about ownership
<icey> but congrats lazyPower !
<lazyPower> because i cant be a single point of failure. i'd rather CI own it tbh
<lazyPower> that way anyone can push button release the snap and sip tea
<icey> lazyPower: yeah, there's ways to setup travis to build / publish into --edge
<lazyPower> we're using jenkins for the k8s stuff so it'll live in there, but all the same, yeah.
<icey> or you can use build.snapcraft.io
<lazyPower> the one thing i've had an issue with is that the builders dont support github orgs yet
<icey> yea
<lazyPower> so we're kinda doing an alternative impl that we're not crazy about but it gets the job done
<ali1234> bug #1650087
<mup> Bug #1650087: [Tour] 20-PARTS-PLUGINS/01-reusable-part: missing g++ dependency <bitesize> <tour> <Snapcraft:Fix Released by kyrofa> <https://launchpad.net/bugs/1650087>
<ali1234> hmm
<mup> PR snapcraft#1293 closed: recording: record stage packages installed in the snap <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1293>
<mup> PR snapd#3278 closed: store, daemon, client, cmd/snap: handle PASSWORD_POLICY_ERROR <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3278>
<mup> PR snapd#3280 opened: configstate: return error if patch is invalid <Created by kyrofa> <https://github.com/snapcore/snapd/pull/3280>
<mup> PR snapd#3045 closed: interfaces: add random interface <Created by femdom> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3045>
<cjwatson> ali1234: so I would agree that we ought to make the lp: alias work by default in LP snap builds, one way or another, but you should just change lp: to https://git.launchpad.net/ so that your snapcraft.yaml isn't dependent on specific git configuration
<ali1234> and that works?
<cjwatson> ali1234: and cloning from github in LP snap builds works too, as long as you use https:// and not git://
<cjwatson> yes
<ali1234> i mean, ideally i would just clone from upstream, but the builders don't see to be able to resolve hostnames
<cjwatson> I bet you're using git://
<ali1234> yes, upstream only has git://
<cjwatson> so, I have a patch in review to fix that
<ali1234> okay
<ali1234> also i keep getting spammed with failed builds, any idea about that?
<ali1234> it keeps on trying to build it over and over, but i am not pushing anything to the repo with snapcraft.yaml, which is not an import
<cjwatson> not right now, about to go to sleep
<ali1234> i got it to build locally in cleanbuild so that's something
<nacc> ali1234: nice, sorry it was such a pain to get to that point
<cjwatson> can have a look tomorrow if you give me a link or something
<ali1234> https://code.launchpad.net/sigrok-snap-test
<nacc> ali1234: i mean, it appears to have tried 4 times so far to build?
<ali1234> i have 7 failure reports
<ali1234> i did delete the project a couple of times though
<ali1234> and one was a manual build
<ali1234> it seems like it triggered a rebuild each time it finished importing a repo
<ali1234> but rate limited
<ali1234> pushing the fixed build deps + https URLs... lets see if it triggers a build or not
<ali1234> hey its building :)
<ali1234> cloning is working
<ali1234> i think this might work :)
<diddledan> has anyone come across snapcraft complaining on a .desktop file containing non-ascii characters? specifically it dies with a message "'ascii' codec cannot decode byte 0xec at position 224: ordinal not in range (128)" which is a rather cryptic message not really telling us that the desktop file contains non-ascii chars
#snappy 2017-05-09
<diddledan> if it's a known issue, is there a plan to, or has it been, solve(d)?
<ali1234> snapcraft seems to have trouble with non-ascii
<diddledan> yeah. that's crazy considering that 90% of the population aren't English
<diddledan> of course 87% of all statistics are made up on the spot, but you get my point
<nacc> lol
<ali1234> 502 proxy error?
<diddledan> hmm?
<ali1234> probably https://bugs.launchpad.net/launchpad/+bug/1683819
<mup> Bug #1683819: Continuous 502 proxy error on snap upload to store <Launchpad itself:New> <https://launchpad.net/bugs/1683819>
<ali1234> diddledan: https://bugs.launchpad.net/snapcraft/+bug/1662456
<mup> Bug #1662456: snapcraft fails if desktop file included "ascii" cannot decode byte <isv> <Snapcraft:Triaged> <https://launchpad.net/bugs/1662456>
<diddledan> ah, thankyou
 * diddledan clicks that it affects me
<ali1234> so now i get: desktop interfaces (x11) specified without meta/gui/*.desktop. Please  provide a desktop file via setup/gui/*.desktop if using snapcraft or  meta/gui/*.desktop otherwise. It should reference one of the 'apps' from  your snapcraft/snap.yaml.
<ali1234> i have no idea what this means
<nacc> ali1234: does your yaml refer to the desktop interface?
<ali1234> no?
<ali1234> it refers to x11
<nacc> ali1234: right, that's what the above messages says is "desktop interfaces"
<ali1234> okay but what is setup/gui/*.desktop?
<nacc> ali1234: a .desktop file for yoru application
<ali1234> what is the setup/gui part?
<nacc> ali1234: i'm guessing a path in your snap's source
<ali1234> its nothing to do with anything i am trying to build
<nacc> ali1234: hrm? you're tyring to use an interface that apparently requires .desktop files
<nacc> ali1234: so ... absolutely has to do with wha tyou're building (a snap)
<ali1234> it doesn't require them, the snap works fine when i build and install it locally
<diddledan> setup is a snapcraft-specific thing that if desired needs to be a folder along-side your yaml file
<nacc> ali1234: could be a disagreement about the version of snapcraft you're using and the one the builder is using?
<ali1234> so it is telling me to create setup/gui/pulseview.desktop, and then put it in the snap somehow?
<nacc> ali1234: you put it in the repository containing your yaml
<diddledan> it'll put it in there automatically
<nacc> ali1234: at that path
<nacc> ali1234: and it will dtrt
<ali1234> so i just create it?
<ali1234> how does it know what filename to look for?
<diddledan> let me screenie my tree
<diddledan> https://usercontent.irccloud-cdn.com/file/I0ALdl5B/
<ali1234> so i do have to make the directories?
<nacc> ali1234: presumably via the application name that is using the interface?
<ali1234> and what is your app called?
<nacc> ali1234: yes, you ahve to make the directories
<nacc> ali1234: it's telling you, you need a file at setup/gui/<app>.desktop
<ali1234> the app is called pulseview but it shows up as sigrok.pulseview when installed, because the snap has two apps
<nacc> ali1234: so of course you need the directgories
<nacc> ali1234: how else would you create the file in the directories?
<ali1234> well, i would use dump plugin with a line like organize: pulseview.desktop: setup/gui/pulseview.desktop
<ali1234> that's how you normally get a file into the snap
<nacc> ali1234: this is not into the snap
<nacc> ali1234: this is in the 'source'
<ali1234> the error comes from store review of the built snap
<nacc> ali1234: the same place your yaml lives
<nacc> ali1234: right, so you put in the source and snapcraft will put it in the right place
<ali1234> so i would expect it means it wants the file in the snap
<nacc> that's my reading
<diddledan> it's an automatic thing
<diddledan> you don't do anything with it other than create it
<nacc> ali1234: i don't think you do anything with teh built snaps
<nacc> that's all snapcraft's job
<ali1234> you build them
<diddledan> i.e. don't try to put it in the build process
<nacc> except maybe organize them
<diddledan> snapcraft handles the setup/ folder automatically
<ali1234> so what did you put in the .desktop file?
<ali1234> ahi found an example
<nacc> diddledan: right that makes sense, it's like custom parts
<diddledan> I'm getting closer to finally achieving a custom gtk build
<diddledan> corebird 1.5 (released a few days ago) requires more recent gtk deps than xenial provides so my snap needs custojobby
<diddledan> I have managed a complete compile but I'm still working out the right stuff to force into the snap
<abeato> ogra_, it looks like --extrausers is not working for chfn command in latest core snap (for armhf at least), which prevents "snap create-user" to work, is that a known issue?
<morphis> abeato: we found that yesterday and ogra_ created a new core snap which should fix that problem
<morphis> abeato: that should be fixed in edge
<abeato> morphis, great... the perils of using edge ;)
<morphis> abeato: yes :-)
<mup> PR snapd#3281 opened: tests: add test for empty snap name on revert <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3281>
<zyga> re
<zyga> good morning
<pstolowski> morning zyga !
<Chipaca> good morning peeps!
<ali1234> morning
<ali1234> all that stuff last night about meta gui? turns out its just a warning, not an error
<ali1234> so now i have 6 versions of the same snap pending review in the store
<zyga> Chipaca: hey hey :)
<zyga> pstolowski: good morning!
<morphis> morning!
 * zyga coundn't help it and had to take a walk in the morning
<zyga> morphis: o/
<morphis> zyga: can you give https://github.com/snapcore/snapd/pull/3274 another look? I've added more test cases and printing a warning whenver a confinement check is ignored
<mup> PR snapd#3274: cmd/snap,tests/main: add force-devmode switch instead of spread system blacklisting <Created by morphis> <https://github.com/snapcore/snapd/pull/3274>
<zyga> morphis: I already am, I'm mid way through the new commit
<morphis> great
<mup> PR snapcraft#1295 closed: recording: record build packages installed in the snap <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1295>
<Chipaca> fgimenez: do we use travis oauth tokens?
<Chipaca> fgimenez: (good morning, also :-) )
<fgimenez> Chipaca: hey :) if you mean github oauth tokens from travis nope we let travis interact with github
<Chipaca> fgimenez: ah alright
<Chipaca> asking because of https://blog.travis-ci.com/2017-05-08-security-advisory
<Chipaca> but if we don't, great :-)
<Chipaca> âVarious GitHub OAuth tokens and secure environment variables that users included in their builds were accidentally exposed via inclusion in build logs on Travis CI.â
<fgimenez> Chipaca: yep, no problem for us, we push to gh, but from our side of the vpn
<zyga> morphis: quick suggestion, perhaps the skip part could be a function that we source so that we don't have to copy-paste the same line for consistency in behavior
<morphis> zyga: you mean the snap forced-devmode check?
<zyga> morphis: otherwise looks ok, I was doing some other things but I'll +1 it (again) in a moment
<zyga> morphis: yeah, something about that, it's tricky because it's simetimes if ... then exit; but sometimes not
<morphis> zyga: I was thinking about that before but actually like this to be really explicit and as it might be used in different combinations
<zyga> morphis: yeah, I understand
<morphis> lets leave it lets see how complex the logic gets into the future
<morphis> I will have multiple changes for fedora too which makes things more complicate and might refactor a few of these tests again
<pstolowski> zyga, hey, wrt to the problem of hanging configure hook on debian; I found out (by examining and comparing strace for that hook on both debian ubuntu) that a posible suspect is: "bind(3, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = ? "
<pstolowski> zyga, i'm not familiar with ipv6 peculiarities, any idea what may be different in that aspect on debian?
<zyga> pstolowski: hey
<morphis> pstolowski: isn't that what jdstrand found when initially looking at the bug?
<pstolowski> morphis, oh, where did he mention that?
<morphis> https://bugs.launchpad.net/snappy/+bug/1674193/comments/16 and https://bugs.launchpad.net/snappy/+bug/1644573
<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>
<mup> Bug #1644573: snapctl causes hooks to attempt to open ip/ipv6 tcp connection <Snappy:Triaged by zyga> <https://launchpad.net/bugs/1644573>
<morphis> pstolowski: the thing is that there was a fix merged in 2.23.6 merged which broke with 2.24 again
<morphis> pstolowski: verified once ago that this problem was fixed with 2.23.6: https://bugs.launchpad.net/snappy/+bug/1674193/comments/25
<pstolowski> morphis, oh, wonderful! thanks for these links
<morphis> pstolowski: they* are on your forum post already :-) https://forum.snapcraft.io/t/tests-broken-in-master/457/8
<pstolowski> morphis, oh indeed..
 * pstolowski embarassed
<morphis> happens :-)
<ali1234> so i finally have an approved snap in the store. do i just click release now?
<Chipaca> ali1234: as you wish :-)
<ali1234> what does the release button do?
<ali1234> what is the difference between releasing and publishing?
<Chipaca> ali1234: if my memory serves, the release button takes you to a page where you choose which channels to publish it to
<ali1234> oh
<ali1234> so it has a terrible name
<Chipaca> ali1234: the button?
<ali1234> and it should just say "edit channels"
<Chipaca> ali1234: you don't edit channels with it though
<ali1234> really?
<Chipaca> ali1234: editing a channel means changing the channel itself
<ali1234> why does it show a form labelled channels: which i can edit then?
<ali1234> "Select the channels to release current revision."
<Chipaca> yep
<ali1234> no, you mean publish
<mup> PR snapcraft#1297 closed: sources: validate unknown source-type in yaml <Created by EduardoVega> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1297>
<ali1234> "Select the channels to [publish] current revision [in]."
<Chipaca> ali1234: i'd suggest you open a forum topic about this
<Chipaca> it's possible the store uses publish and release inconsistently
<Chipaca> but i don't know; there might be nuance
<ali1234> if you have a button with a verb on it i expect clicking it will do that verb
<Chipaca> but it's definitely not "edit a channel"; it's editing a channel assignment, which seems to be called releasing
<Chipaca> ali1234: as i say, please open a forum topic
<Chipaca> unless you're just ranting, that is :-)
<Chipaca> ranting is fine btw
<ali1234> i can rant on the forum if you want
<Chipaca> ali1234: forum is for constructive, long-term engagement
<Chipaca> well, long-term in internet time :-p
<Chipaca> rants are fine here
<ali1234> okay. where do i go to just report a list of problems?
<ali1234> i am not interested in long term engagement. i will just come back in another 9 months and see if you have fixed all the problems
<Chipaca> ali1234: the forum is fine to just report a list of problems
<Chipaca> ali1234: (the 'long-term' side of that kind of post comes from the people going through the list and addressing them)
<Chipaca> maybe a better term would be 'asynchronous' actually
<Chipaca> vs irc that is synchronous
<ali1234> should i create one topic for each issue?
<ali1234> or just make one long rant post?
<Chipaca> ali1234: just one long one is probably easier for you
<Chipaca> ali1234: i believe moderators can then split it up
<ali1234> yeah but we both know they won't
<Chipaca> dude
<ali1234> someone will come along and address one of the problems (probably by saying "that isn't in scope of the project") and then the rest will be ignored
<ali1234> that's what happened yesterday
<Chipaca> ali1234: where?
<ali1234> https://forum.snapcraft.io/t/trying-to-build-sigrok-snap/503
<Chipaca> ali1234: that looks like the opposite
<ali1234> really? i was told to use launchpad, which addresses exactly one of the four problems i raised
<Chipaca> it's not being ignored; you even got ev following up a day later
<Chipaca> which was less than an hour ago
<ogra_> Chipaca, mind giving a second thumbs up on https://github.com/snapcore/core/pull/37 ? (trivial changes)
<mup> PR core#37: install keyring (LP: #1670475), update pkglists <Created by ogra1> <https://github.com/snapcore/core/pull/37>
 * ogra_ hugs Chipaca 
<mup> PR core#37 closed: install keyring (LP: #1670475), update pkglists <Created by ogra1> <Merged by ogra1> <https://github.com/snapcore/core/pull/37>
<Chipaca> ali1234: about the snapcraft.yaml in the root of the repo, I *think* (but am not sure) that you can also make it .snapcraft.yaml, or snap/snapcraft.yaml
<ali1234> you can
<ali1234> upstream will put it at cross-compile/snap/snapcraft.yaml because that is how their repository is organized
<juanrubio> Hi, I'm trying to create a snap of my app (https://github.com/tizonia/tizonia-openmax-il) and I'm currently facing problems with pulseaudio. The snap I've created installs correctly in Fedora 25 but it can't access pulseaudio (Access Denied)...is there any good reference or tuturial on how to create snaps that need access to pulseaudio?
<Chipaca> juanrubio: is it using the pulseaudio interface?
<morphis> Chipaca: we don't ahve any confinement on Fedora so the interface is useless unless its a seccomp issue
<morphis> juanrubio: can you give us the exact error message?
<juanrubio> yes, plugs section contains 'pulseaudio'
<morphis> juanrubio: is the plug connected?
<Chipaca> morphis: point
<juanrubio> the error message is coming from my app
 * Chipaca goes back to work
<morphis> juanrubio: is there an error in dmesg or journalctl?
<juanrubio> "Access denied" (which comes from pulseaudio's api)
<juanrubio> i can't seen any errors in journalctl's output
<morphis> juanrubio: and you're running your app with the same user you're logged into the system
<juanrubio> morphis: i thought the plug would be automatically connected?
<juanrubio> yes, same user
<morphis> juanrubio: is it connected or not?
<juanrubio> if I connect the plug with 'sudo snap connect tizonia:pulseaudio :pulseaudio' i get the same result
<Chipaca> juanrubio: can you share the .yaml?
<Chipaca> oh it's there in tools/snapcraft.yaml
<juanrubio> yes, in tools
<juanrubio> I created my snap in Ubuntu 16.04 and Fedora 25 runs on a Virtualbox VM
<Chipaca> juanrubio: and does it work in ubuntu 16.04?
<juanrubio> actually, I have not tried it in ubuntu
<Chipaca> please do
<juanrubio> ok, let me give it a try in an 16.04 VM i have over here
<zyga> pstolowski: re
<zyga> pstolowski: sorry, I was in a call
<mup> PR snapd#3282 opened: hooks: default timeout <Created by stolowski> <https://github.com/snapcore/snapd/pull/3282>
<zyga> pstolowski: so the problem is snapctl and golang's network stack that checks if you have ipv6 connectivity/support by creating that socket
<zyga> pstolowski: as you know on ubuntu & linode we disable ipv6 (as there was some problem with routing, historically)
<zyga> pstolowski: but I don't think we disable that on debian
<zyga> pstolowski: we may thus hit a confinement issue where seccomp kills part of snapctl
<zyga> pstolowski: I think in addition the actual hook, before it tries snapctl, checks something else which on ubuntu is blocked by apparmor
<zyga> pstolowski: so when the plug (core-support-plug) is disconnected, the hook exits gracefully
<zyga> juanrubio: hey
<fgimenez> hi zyga, i've filed this bug https://bugs.launchpad.net/snappy/+bug/1689332 wrt the issue with the 2.25 ubuntu-core snap and the hardcoded snap-confine path
<mup> Bug #1689332: internal error with any command using ubuntu-core snap on classic <Snappy:New> <https://launchpad.net/bugs/1689332>
<zyga> juanrubio: intersting, what is your snap doing with audio? just playback or something more?
<zyga> fgimenez: thank you! I'll assign it to myself
<pstolowski> zyga, my understanding - after looking at comments from jdstrand and later morphis - is that yes, it's ipv6 reatlated, Jamie recommended a specific policy rule. the problem was fixed but by mistake not included in the 2.24 release, but according to morhpis it's in the new release (https://forum.snapcraft.io/t/tests-broken-in-master/457/8?u=pstolowski)
<ogra_> morphis, https://github.com/snapcore/pi3-gadget/pull/6
<mup> PR pi3-gadget#6: make pi-bluetooth name more generic <Created by ogra1> <https://github.com/snapcore/pi3-gadget/pull/6>
<fgimenez> zyga: great thanks! :) do you think this issue should block the 2.25 sru?
<zyga> pstolowski: I'm not sure I understand, what do you aim to achieve in the end?
<mup> Bug #1689332 changed: internal error with any command using ubuntu-core snap on classic <snapd:New> <https://launchpad.net/bugs/1689332>
<zyga> fgimenez: well, hard to say, it only affects people that are on ubuntu-core (not just core)
<pstolowski> zyga, and i've just proposed a PR to have a default timeout in case we have a task created by old snapd with no timeout set
<mup> PR snapcraft#1288 closed: store: collaboration UI for snaps <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1288>
<juanrubio> zyga: audio playback
<zyga> fgimenez: I think it is not so critical but perhaps my view is just too optimistic
<fgimenez> zyga: ok thanks, we can talk later in the meeting
<zyga> juanrubio: so fedora 25 may have a more recent version of pulseaudio than ubuntu 16.04 but I bet that pulseaudio still supports the older protocol
<zyga> juanrubio: and even on fedora 26 I saw snaps play audio
<zyga> juanrubio: could you please open a forum topic for this (on forum.snapcraft.io), perhaps other people are facing the same issue and even if not we can try to help you there
<zyga> juanrubio: if your snap is public I could try it on my f26 machine
<zyga> juanrubio: and try to debug it there
<juanrubio> zyga: these are my first steps with snaps, so I'm sure I'm missing something
<zyga> juanrubio: does it work on ubuntu? if so, it should work on fedora too
<fgimenez> zyga: i think there's another issue with https://github.com/snapcore/snapd/pull/3218/files, i'm getting "Bad system call" trying to use systemd-cat from a snap, will file a bug about this too
<mup> PR snapd#3218: interfaces: allow writing to /run/systemd/journal/stdout by default <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3218>
<juanrubio> zyga: I'm currently updating a 16.04 VM that I have here. I will try it out in 16.04 in a few minutes
<ogra_> morphis, thx
<morphis> ogra_: np
<zyga> fgimenez: in lxc?
<fgimenez> zyga: nope, on a regular classic vm
<juanrubio> I'm opening a forum topic for this, which  category 'snap' or 'snapcraft'?
<zyga> hmm
<zyga> fgimenez: what was the system call? do you have the error message?
<zyga> juanrubio: snap please
<fgimenez> zyga: sure, [  910.074185] audit: type=1326 audit(1494320944.576:31): auid=1000 uid=12345 gid=12345 ses=1 pid=30704 comm="systemd-cat" exe="/usr/bin/systemd-cat" sig=31 arch=c000003e syscall=48 compat=0 ip=0x7fcdee899987 code=0x0
<zyga> fgimenez: 48 is "shutdown"
<zyga> fgimenez: hmm, probably closing some socket
<morphis> hm, did anyone run into this one with spread already: in test-snapd-tools.channels: extra keys: {'latest/candidate', 'latest/beta'}
<zyga> fgimenez: where did that fail? was it a specifi test?
<morphis> that is for tests/main/snap-info
<fgimenez> morphis: yep on it
<morphis> fgimenez: great!
<zyga> morphis: nope, but Chipaca wrote that so I bet he groks he messages
<Chipaca> where what?
 * Chipaca reads up
<morphis> Chipaca: https://travis-ci.org/snapcore/snapd/builds/230270742?utm_source=github_status&utm_medium=notification
<fgimenez> zyga: not yet, i was adding it while reviewing the 2.25 changelog https://github.com/snapcore/snapd/compare/master...fgimenez:spread-interfaces-default?expand=1#diff-e2f8bc979b0f080a4b32db7b71057b46R9
<Chipaca> morphis: that looks like a snap/snapd version mismatch
<Chipaca> as in, snapd sending track/channel, snap expecting channel
<Chipaca> but let me look at it a moment
<fgimenez> morphis: Chipaca probably related, i just uploaded an updated version of test-snapd-tools and the snap-info test started failing, reverted back to the previous version and keep failing
<Chipaca> fgimenez: it might be that the test expects it to be only in certain channels
<Chipaca> and you published it to more of them
<Chipaca> it'd look like this, also
<Chipaca> i.e. it used to only be in stable and edge, and now it's also in candidate and beta
<fgimenez> Chipaca: i tried to keep the same channels, rev 3 was in stable, candidate and beta (as it is now)
<fgimenez> Chipaca: aha, let me try to remove it from candidate and beta
<Chipaca> so, yes, the snap-info test expects it only in stable and edge
<Chipaca> morphis: found the problem :-)
<Chipaca>    ("channels", check,
<Chipaca>     ("latest/stable", matches, verRevNotesRx("-")),
<Chipaca>     ("latest/edge", matches, verRevNotesRx("-")),
<Chipaca>    ),
<Chipaca> that will fail if the channels key has more entries than those two
<juanrubio> actually, I said before that journalctl didn't show any messages, but actually i didn't realise that the older messages were at the top.. so yes I see a bunch of errors, not sure I understand much... what should I look for?
<Chipaca> juanrubio: anything with 'audit' in it
<morphis> juanrubio: can you paste those somewhere?
<juanrubio> I've pasted some of it here: https://gist.github.com/juanrubio/d7ed44344ef2e7a659dede5f788d07f5
<mup> PR snapd#3280 closed: configstate: return error if patch is invalid <Created by kyrofa> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3280>
<zyga> permissive=0 is curious,
<Chipaca> ogra_: remind me, how long does the prepare-device hook take on the bbb, worst case?
<ogra_> Chipaca, i havent tested in a while but it should not take long anymore
<ogra_> it used to be 10-15min in the wrst times
<ogra_> *worst
<juanrubio> and this are the steps I'm following to install the snap on Fedora 25 : https://gist.github.com/juanrubio/4ca10f5a6468fc12bcbed6bf01a7d8f7
<fgimenez> Chipaca: now i begin to rant about the release page too :) do you know if i can unpublish a released revision from a channel somehow?
<Chipaca> fgimenez: yes, you click on the channels and edit the map as you please
<ogra_> fgimenez, i dont think you can "unrelease" but you can release a former version
<Chipaca> fgimenez: i think i should be able to do it
 * Chipaca looks
<mup> PR snapd#3276 closed: tests: additional setup in docker test for core systems <Created by fgimenez> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3276>
<morphis> juanrubio: why do you had to do $ mkdir -p ~/snap/tizonia/x1/.config/tizonia ?
<ogra_> iirc the store spills an error if you just try to unrelease
<morphis> juanrubio: was that just because of ~/snap/tizonia/x1/.config missing or did even ~/snap/tizonia/x1/ not exist?
<fgimenez> Chipaca: releasing a former version leaves the candidate and beta channels in snap-info's output http://paste.ubuntu.com/24542209/ not sure if the test would pass with this?
<Chipaca> that looks like a bug
<Chipaca> noise][: are you around?
<juanrubio> morphis: my app needs this 'tizonia.conf' located in $HOME/.config/tizonia
<Chipaca> fgimenez: i mean, what looks like a bug is the not being able to remove channels
<morphis> juanrubio: so ~/snap/tizonia/x1/ was automatically created?
<Chipaca> maybe it's always been this way but i thought not
<juanrubio> so I currently copy this manually
<juanrubio> ~/snap/tizonia/x1 is automatically create
<juanrubio> ~/snap/tizonia/x1 is automatically created
<morphis> ok
<Chipaca> the idea of opening a channel, having a snap in it, and then closing it has existed forever
<fgimenez> Chipaca: yep i think so, the message from the release page is clear though "Released channels cannot be removed."
<fgimenez> Chipaca: this fixes the tests http://paste.ubuntu.com/24542214/ should i propose it?
<ogra_> right, thats the typÃ¼ical message
<Chipaca> fgimenez: if it can wait a bit, i'd rather first determine whether the store is broken in this way
<Chipaca> or if it's how it should be, in which case yes let's fix the test
<fgimenez> Chipaca: ok
<ogra_> Chipaca, it has always been like this (at least with the web UI)
<Chipaca> fgimenez: if determining this takes more than an hour, let's fix the tests
<ogra_> the above is the message you get when unticking the channel checkbox ... but ticking it on an older version will override and release that version instead
<fgimenez> Chipaca: ok sounds good
<ali1234> hmm something wrong with my snap. i now have both meta/gui and setup/gui
<juanrubio> My 16.04 is taking a bit long to update. I've uploaded the snap package to this location, in case someone might want to give it a try on Fedora 25 or 26: http://www.juanrubio.me/tizonia/tizonia_0.7.0_amd64.snap
<ali1234> actually it looks like it dumped everything from the source repo into the snap
<zyga> pstolowski: hey, I read https://github.com/snapcore/snapd/pull/3282/files and it looks OK but I recall you said it didn't work, do I remember that correctly?
<mup> PR snapd#3282: hooks: default timeout <Created by stolowski> <https://github.com/snapcore/snapd/pull/3282>
<pstolowski> zyga, I said that, yes, but later I figured out (correct me if I'm wrong) that the test I was using in qemu re-execs into new snapd from core image, so I wasn't really testing my change at that time
<zyga> pstolowski: I think you were, because the "new" snapd was the one from the package
<zyga> pstolowski: and the package is built
<zyga> pstolowski: I mean we re-write the core snap
<Chipaca> juanrubio: getting a 404
<Chipaca> juanrubio: ah now it worked
<fgimenez> Chipaca: anyway, something strange has happened with test-snapd-tools, it seems that beta and candidate have been used since rev 1 http://paste.ubuntu.com/24542284/ (i actually checked the channels used by rev 3 before releasing rev 6, and those included candidate and beta), how was snap-info test passing before?
<juanrubio> I've created a forum topic: https://forum.snapcraft.io/t/pulseaudio-access-denied-accessing-pulseaudio-for-audio-playback-in-fedora-25/519
<Chipaca> juanrubio: what do i do to run it?
 * Chipaca knows nothing about tizonia
<Chipaca> fgimenez: Â¯\_(ã)_/Â¯
<Chipaca> fgimenez: let's see what facu says
<ogra_> fgimenez, the pi2-kernel in edge is pretty outdated, i'll sync the newer one from beta into it (runs fine here, just FYI in case any tests start to misbehave in edge)
<fgimenez> ogra_: ok thanks! i'll give it i try
<pstolowski> zyga, hmm.. ok, i'm confused. i understand what you're saying, just not sure about my findings anymore. I could manually kill -9 the hanging configure script and this is what we do in hookmgr.
 * Chipaca hugs Facu 
<Chipaca> juanrubio: the help output for tizonia talks about ~/.config/tizonia/tizonia.conf, which is wrong
<zyga> pstolowski: I could try your branch and experiment
<ogra_> morphis, hmm, who owns the wifi-ap snap ? seems i cant run the setup wizard anymore ... http://paste.ubuntu.com/24542320/
<juanrubio> Chipaca: I was using it with my Spotify account, but the pulseaudio problem should be seen while trying to play a local mp3 file
<juanrubio> Chipaca: why do you say the help output is wrong?
<morphis> ogra_: we do
<Chipaca> juanrubio: because a snap won't be able to read ~/.config/tizonia/tizonia.conf
<ogra_> /find nikc "we"
<ogra_> *nick
<ogra_> :P
<Chipaca> juanrubio: apps usually set XDG_CONFIG_DIR (or whatever it was) to something inside ~/snap/
<morphis> ogra_: you ping'ed the right one :-)
<pstolowski> zyga, feel free to if you have a few moments
<morphis> ogra_: which syscalls are denied?
<ogra_> morphis, werll, seems "socket"
<juanrubio> Chipaca: right now I am only concerned about making it work on Fedora as a test, will deal with those other things later
<morphis> ogra_: are all plugs connected?
<Chipaca> XDG_CONFIG_HOME, actually
<Chipaca> juanrubio: ok fair enough
<ogra_> that worked before i reinstalled the image ... all auto-connect ones are
<Chipaca> juanrubio: fedora doesn't have apparmor confinement so it's less picky :-)
<morphis> ogra_: can you paste $ snap interfaces wifi-ap
<Chipaca> juanrubio: another question, why do you use the alsa plug?
<ogra_> morphis, http://paste.ubuntu.com/24542331/
<Chipaca> juanrubio: and yet another question, how do i play a local mp3 :-)
<juanrubio> Chipaca: tizonia can render audio with alsa and pulseaudio
<ogra_> morphis, and i'm only calling "sudo wifi-ap.setup-wizard"
<ogra_> nothing fancy
<morphis> but that will talk with the service over a local socket
<juanrubio> you could play an mp3 like : tizonia my-mp3.mp3
<Chipaca> juanrubio: ok. Just note that pulseaudio is connected by default, but alsa isn't (because it lets you do nasty things)
<morphis> ogra_: hm
<ogra_> morphis, well, whatever it does ... it worked 100 times for me before ...
<Chipaca> juanrubio: all it ever does is complain about a missing tizonia.conf
<ogra_> (probably only 87 ... i'm exaggerating ;) )
<morphis> ogra_: can you check if the socket syscall is in the seccomp profile?
<juanrubio> Chipaca: yes, please go to my post on snapcraft.io.. I've posted the files tizonia.conf and .log4crc
<juanrubio> https://forum.snapcraft.io/t/pulseaudio-access-denied-accessing-pulseaudio-for-audio-playback-in-fedora-25/519
<Chipaca> juanrubio: wait, it doesn't work in --devmode either?
 * zyga spends a moment on improving some tests
<zyga> pstolowski: I'll check your branch just after that
<ogra_> morphis, looks fine to me http://paste.ubuntu.com/24542345/
<Chipaca> juanrubio: anyway, thanks for those files, looking
<juanrubio> Chipaca: thanks for your time
<morphis> ogra_: yeah ..
<morphis> ogra_: which snapd version are you running?
<ogra_> ogra@pi3:~$ snap version
<ogra_> snap    2.25+201705082317.git.3ff5a56~ubuntu16.04.1
<ogra_> snapd   2.25+201705082317.git.3ff5a56~ubuntu16.04.1
<ogra_> series  16
<ogra_> kernel  4.4.0-1051-raspi2
<morphis> so edge
<morphis> can you try with beta?
<ogra_> edge ... from 2h ago or so
<ogra_> refreshing ...
<morphis> I fear that the seccomp arg filtering jdstrand landed recently might be the problem here
<ogra_> well, see line 525 of the profile paste ...
<ogra_> "# FIXME: remove this after LP: #1446748 is implemented"
<zyga> offtopic, I'd *love* to merge https://github.com/snapcore/snapd/pull/3026
<mup> Bug #1446748: implement seccomp filtering by argument <application-confinement> <ubuntu-core-launcher (Ubuntu):Fix Released by jdstrand> <https://launchpad.net/bugs/1446748>
<mup> PR snapd#3026: cmd/snap-confine: use defensive argument parser <Created by zyga> <https://github.com/snapcore/snapd/pull/3026>
<Chipaca> juanrubio: tizonia dies with "Unable to verify the component list." (and leaves the terminal in a bad state)
<morphis> ogra_: hm
<morphis> ogra_: lets verify first if this a regression
<Chipaca> fgimenez: btw did 'snapcraft close' work?
<ogra_> i wonder if all snaps in the store that use this workaround have to be updated in the store
<ogra_> morphis, yeah ... rollback to beta works
<morphis> ogra_: ok, then we have a regression, can you open a bug about that?
<ogra_> yep
<morphis> ogra_: that is then a blocker for 2.25
<zyga> pstolowski, Chipaca: https://github.com/snapcore/snapd/pull/3283
<mup> PR snapd#3283: overlord/hookstate: remove unused Context.timeout <Created by zyga> <https://github.com/snapcore/snapd/pull/3283>
<mup> PR snapd#3283 opened: overlord/hookstate: remove unused Context.timeout <Created by zyga> <https://github.com/snapcore/snapd/pull/3283>
<Chipaca> yuss
<ogra_> morphis, well ...
<ogra_> ogra@pi3:~$ snap version
<ogra_> snap    2.25
<ogra_> snapd   2.25
<ogra_> series  16
<ogra_> kernel  4.4.0-1051-raspi2
<juanrubio> Chipaca: you need to install tizonia.conf as posted in the forum topic
<Chipaca> juanrubio: done that
<ogra_> morphis, i'd rather say it blocks 2.26 :)
<Chipaca> juanrubio: until I did, all tizonia did was complain about that missing file
<juanrubio> Chipaca: ok, then could you please check that you have this in the config file? 'component-paths = /var/lib/snapd/snap/tizonia/x1/lib/tizonia0-plugins12;'
<Chipaca> uhhh
<mup> PR snapcraft#1302 opened: lxd: Mount project folder via sshfs in case of a remote <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1302>
<Chipaca> juanrubio: that's not right
<juanrubio> aha?
<Chipaca> juanrubio: that's the path from "outside" the snap
<Chipaca> juanrubio: (and only when that is where the snaps are installed)
<Chipaca> in ubuntu, snaps are installed in /snap/
<Chipaca> and not /var/lib/snapd/snap
<fgimenez> Chipaca: looks like it went fine http://paste.ubuntu.com/24542381/ running the test now
<Chipaca> juanrubio: but in any case, inside the snap, it's always /snap/
<juanrubio> Chipaca: I see
<Chipaca> editing the file now
<morphis> ogra_: ah right, getting confused ...
<Chipaca> juanrubio: also, you have a /home/joni in that file
<juanrubio> Chipaca: with that path, tizonia can locate the plugins (decoders, sources, renderers etc) and the proceed to do some playback
<Chipaca> juanrubio: do you know if tizonia supports using environment variables in its config?
<Chipaca> juanrubio: what is the 'resource manager database'?
<ogra_> Bug #1689536
<mup> Bug #1689536: snapd   2.25+201705082317.git.3ff5a56~ubuntu16.04.1 breaks seccomp handling <snapd:New> <https://launchpad.net/bugs/1689536>
<ogra_> jdstrand, morphis ^^^
<juanrubio> Chipaca: uhm.. let me see, it is a db used to figure out what plugins can be accessed by tizonia in some cases, but not relevant here
<Chipaca> yeah, noticed it's got enabled=false
<juanrubio> correct
<Chipaca> juanrubio: from a quick check it looks like tizonia doesn't support using environment variables in its config (but i haven't read the code to make sure)
<Chipaca> juanrubio: so you're going to have to generate the file (e.g. from a wrapper)
<juanrubio> Chipaca: that is correct, env vars are not supported right now
<Chipaca> juanrubio: but, on ubuntu, when not installed with devmode, you get
<Chipaca> juanrubio: [196128.136517] audit: type=1400 audit(1494329031.902:417): apparmor="DENIED" operation="connect" profile="snap.tizonia.tizonia" pid=22296 comm="audio_renderer" family="unix" sock_type="stream" protocol=0 requested_mask="send receive connect" denied_mask="send connect" addr=none peer_addr="@/tmp/.X11-unix/X0" peer="unconfined"
<Chipaca> why is a music app trying to talk to X?
<Chipaca> (a music app that doesn't ask for the x11 interface, as well)
<zyga> Chipaca: it may talk to X to get the pulseaudio auth cookie
<zyga> Chipaca: (beacause)
<juanrubio> Chipaca: in my Fedora VM, I've got to the point where I can load the spotify plugin, and the pulseaudio plugin. Spotify works but audio rendering fails with pulseaudio access denied error
<zyga> Chipaca: ah
<zyga> juanrubio: which desktop environment are you using?
<zyga> I think that the pulse cookie is in /tmp
<juanrubio> awesome wm
<zyga> morphis: we may need
<zyga> juanrubio: here you go
<zyga> this is why it doesn't work,
<zyga> morphis: we may need someting quite like xauthority support for puslseaudio cookie
<juanrubio> zyga: are you saying it would work on Gnome desktop?
<zyga> juanrubio: yes
<zyga> juanrubio: because it depends on how you initialize pulseaudio in the system
<zyga> juanrubio: and some peculiar ways snapd works
<juanrubio> zyga: let me log into gnome
<juanrubio> zyga: heyy... it works!
<juanrubio> really nice!
<zyga> juanrubio: yes, it's really annoying as well but at least we know what we're standing on :)
<juanrubio> zyga: so, is there anything I can do to workaround the cookie issue?
<zyga> juanrubio: and it's a bug in snapd
<zyga> juanrubio: just one that doesn't affect the default configuration for many
<zyga> juanrubio: so we didn't bump into it yet
<zyga> juanrubio: but it's just a bug, it'll get fixed
<zyga> juanrubio: no, it's nothing you can fix
<zyga> juanrubio: (in a snap)
<juanrubio> zyga: is there a launchpad issue?
<zyga> juanrubio: it's something that needs to be fixed in snapd/snap-confine pair
<zyga> juanrubio: I don't think so, please file a bug about it
<zyga> morphis: can you look at that bug please?
<morphis> zyga: really?
<zyga> morphis: ?
<morphis> why are those things in /tmp ..
<zyga> morphis: there are different ways to auth with pulse
<fgimenez> Chipaca: yes, the snap-info test is passing now
<fgimenez> morphis: ^
<zyga> morphis: and I think on ubuntu we use the cookie attached to the root window
<morphis> zyga: I know but /run exists to store those things
<zyga> morphis: but then if you for whatever reason cannot get that cookie
<zyga> morphis: auth looks for the next thing
<zyga> morphis: and I think that's somewhere inaccesislbe, maybe run but maybe not (perhaps $HOME somewhere)
<zyga> morphis: I don't know
<Chipaca> morphis: the x11 socket is in /tmp, not in /run, for instance
<morphis> yeah, I know what pulse does pretty well, caused my quite some headache to get that right for U-Core and the pulseaudio snap
<Chipaca> and the xim socket
<fgimenez> Chipaca: however this is superconfusing, from the test-snapd-tools page in the store i can see that rev 6 is released to beta, candidate and stable
<zyga> oh drat
<zyga> my wife is killing me with irresistible smell downstairs :)
 * zyga runs, bbl :)
<Chipaca> zyga: sometimes i wish i had your problems
<Chipaca> :-)
<juanrubio> Chipaca: I don't mind creating the defect, although you might be able to record the details more accurately than me...
<morphis> zyga, Chipaca: how are we sharing the X11 socket from /tmp with the snaps today?
<morphis> zyga: normal location of the cookie on a desktop is $HOME/.config/pulse/cookie
<Chipaca> morphis: I think all we do is copy .Xauthority to /run/user/etc
<morphis> Chipaca: right, that is what I added recently
<Chipaca> ah :-)
<morphis> however for the pulse cookie that gets harder
<morphis> juanrubio: can you file a bug about this on https://bugs.launchpad.net/snapd/+filebug , I will take it from there
<juanrubio> morphis: filed it here -> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1689539
<mup> Bug #1689539: Pulseaudio "Access Denied" on Fedora 25 with Awesome WM as desktop environment <snapd (Ubuntu):New> <https://launchpad.net/bugs/1689539>
<morphis> juanrubio: thanks
<juanrubio> thanks guys, that was very helpful... my wife also has some smells dowstairs!
<ogra_> morphis, erm ... isnt the pulse cookie in $HOME usually ?
<morphis> ogra_: yes
<morphis> .config/pulse/cookie
<morphis> or its set via X11
<ogra_> right
<ogra_> and the pulse interface should give you access to ~/.config/pulse afaik
<ogra_> yeah ... owner @{HOME}/.config/pulse/cookie rk,
<morphis> ogra_: right, but in this case it seems to be different, will look into that
<Chipaca> morphis: ogra_: some apps may just go to the x11 root window by default
<Chipaca> dunno
<ogra_> well, i see libboost in the error logs
<ogra_> and looking at the snapcraft.yaml it seems to pull in a good bunnch of other stuff https://github.com/tizonia/tizonia-openmax-il/blob/master/tools/snapcraft.yaml
<ogra_> dbus-x11
<ogra_> there you go ....
<ogra_> that pulls in athe whole x11 stack through deps
<ogra_> (at least the libs)
<ogra_> and the app uses mpris as well
<ogra_> so it is actually deeply hooked into X11 and should use the x11 interface
<Chipaca> mpris and dbus probably means it needs the unity7 one (for lack of a better match)
<zyga> Chipaca: I always joke that my wife and I should switch roles; we'd get thinner instantly :)
<zyga> morphis: no idea
<zyga> morphis: there must be another way to connect
<morphis> zyga: to connect to pulse you need the socket and the cookie
<zyga> morphis: I must say that the modern desktop stack is pretty complex
<morphis> and the cookie comes either from the fs or from X11
<morphis> it is
<morphis> zyga: I will look into this problem
<zyga> morphis: thank you!
<zyga> morphis: I have no idea but I'd love to help if you figure out what needs doing
<morphis> zyga: will ping you
<jdstrand> ogra_: don't worry about line 525. it is referring to socketcall. that is something different
<jdstrand> ogra_: I also answered in the bug
<ogra_> jdstrand, ok ... well, it dies on "socket"
<ogra_> ok
 * jdstrand is wondering if there is an AF_ that this kernel has that isn't in generic
<zyga> jdstrand: you mean custom address family?
<jdstrand> if it was netlink, I would expect needing a 'network netlink' apparmor rule and I checked all those (I could've missed something)
<ogra_> jdstrand, well, the kernel doesnt seem to matter, it is the core that breaks it
<jdstrand> zyga: yes
<jdstrand> ogra_: I understand that
<ogra_> ah, k
<jdstrand> ogra_: oh, for the strace. add 'socket' to the seccomp policy, then strace and show me all the socket calls
<jdstrand> if you don't allow it in the policy there won't be anything to trace :)
<ogra_> do we have strace in the toolbelt snap ?
<zyga> ogra_: no
<ogra_> bah
<zyga> ogra_: it's just busybox
<zyga> ogra_: but I could add it
<ogra_> yeah, that might make sense given how often we use it
<jdstrand> ogra_: https://code.launchpad.net/~jdstrand/+git/debug-tools
<jdstrand> ogra_: if using that snap. install it then run 'debug-tools' and it will tell you how to invoke
<jdstrand> ogra_: though with strace, you literally can scp the binary and it will work
<Chipaca> these days maybe not so well though
<Chipaca> because of go being hard to strace
<jdstrand> /path/to/strace -o ./trace -D -f -vv -e '!select <thing to strace>
<jdstrand> whoops
<jdstrand> /path/to/strace -o ./trace -D -f -vv -e '!select' <thing to strace>
<jdstrand> that works pretty well
<Chipaca> pstolowski: https://travis-ci.org/snapcore/snapd/builds/230295130#L3172
<Chipaca> jdstrand: i'll grep for this the next time i need it, thanks :-)
<Chipaca> pstolowski: is that something we should worry about?
<pstolowski> looking
<pedronis> pstolowski: hi, is snapd#3282 something we want soon/for 2.26? IÂ answered something there
<mup> PR snapd#3282: hooks: default timeout <Created by stolowski> <https://github.com/snapcore/snapd/pull/3282>
<mup> PR snapd#3283 closed: overlord/hookstate: remove unused Context.timeout <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3283>
<pstolowski> pedronis, I think it would be nice to have but not critical
<pstolowski> Chipaca, econnreset test failure, is that what you mean?
<Chipaca> pstolowski: yep
<Chipaca> pstolowski: the link should've taken you to the line, but maybe it fails with the slow async loading of the log
<pstolowski> Chipaca, it showed me the last summary line, yes, just wasn't sure
<pstolowski> Chipaca, this test had some when Michael introduced it and I remember he fixed it... or so he thought ;)
<pstolowski> s/some/some flakiness/
<Chipaca> pstolowski: so i should just re-run it?
<Chipaca> pstolowski: actually rather than re-run it, as it seems i was wrong about device-hook, could you revert that edit?
<pstolowski> Chipaca, re-run, yes, I'd say so. you mean you were wrong in the light of what pedronis said?
<Chipaca> yeh
<zyga> pstolowski: I have something for you to review
<zyga> https://github.com/snapcore/snapd/pull/3284
<mup> PR snapd#3284: interfaces: ensure that legacy interface methods are unused <Created by zyga> <https://github.com/snapcore/snapd/pull/3284>
<mup> PR snapd#3284 opened: interfaces: ensure that legacy interface methods are unused <Created by zyga> <https://github.com/snapcore/snapd/pull/3284>
<zyga> Chipaca: ^^ you too as you have better go insight than I did
<zyga> Chipaca: (I wanted to do this without introducing reflection in non-test code)
<zyga> Chipaca: and without making definers public
<morphis> fgimenez: do you got the CI fixed?
<zyga> s/did/do/ ;)
<ogra_> zyga, stop slacking ... standup ;)
<fgimenez> morphis: yes, should be working now
<zyga> this is an old branch that I wanted to resurrect
<zyga> ogra_: oh
<zyga> sorry
<niemeyer> zyga, fgimenez : stand up?
<ogra_> :)
<zyga> coming
<jdstrand> ogra_: let me try on my pi2
<morphis> fgimenez: thanks
<ogra_> jdstrand, not sure that works since you dont have a wlan device on it
<jdstrand> fgimenez: re /dev/meminfo> it is allowed by the base abstraction, so, yes, it will be allowed everywhere
<ogra_> jdstrand, i'll collect the info after our team standup ...
<jdstrand> I actually have a usb wlan I can plug in
<jdstrand> the device isn't rebooting into 1876 though...
<ogra_> you could try (if that can work in ap mode)
<jdstrand> 'Setup snap "core" (1876) security profiles (phase 2)'
 * jdstrand taps fingers
<ogra_> ctrl-C if you dont want to wait for the auto reboot
<ogra_> and just sudo reboot
<jdstrand> ah
<ogra_> (it wont return)
<jdstrand> ok
<jdstrand> that seems odd, but... unblocked
<ogra_> yes, is odd
<fgimenez> jdstrand: great thanks, then do we need this rule https://github.com/snapcore/snapd/blob/master/interfaces/builtin/system_observe.go#L53 ?
<jdstrand> fgimenez: no, we don't, ar it should at least be commented
<jdstrand> or*
<jdstrand> fgimenez: I took a note to do one of those things
<fgimenez> jdstrand: ok thank you! :)
<jdstrand> ogra_: fyi, not having the wlan is enough to trigger it
 * jdstrand takes over
<ogra_> ah, nice
<pedronis> jdstrand: yes, that waiting command was the result of a quick bug fix, we know we have to improve the UX, it's on my todo list for soon
<Chipaca> hmm
<pedronis> Chipaca: hmm?
<Chipaca> niemeyer, fgimenez: i do still see the right reply from the store for snap info
<Chipaca> so maybe we broke something?
<pedronis> Chipaca: we switched to use it afaik (2.24 was still using the hack)
<Chipaca> this is wrt the "^" channels
<pedronis> so maybe we are using it wrong
<Chipaca> oh wait let me make sure i'm using the right snap + snapd first :-)
<pedronis> and didn't notice
<fgimenez> Chipaca: not sure, this is from 2.25 http://paste.ubuntu.com/24542694/ and this from 2.24.1 http://paste.ubuntu.com/24542709/ 2.25 doesn't show the closed channels
<Chipaca> fgimenez: right, that means we've got a bug wrt closed channels
<jdstrand> pedronis: nice!
<Chipaca> fgimenez: which we've actually written into the tests
<Chipaca> i wonder how this slipped past me :-)
 * Chipaca knows how this could slip by
<Chipaca> anyway, i'll push a branch for this
<fgimenez> Chipaca: :) is it on snapd side then? Facu suggested to file it under https://bugs.launchpad.net/snapstore/
<pstolowski> Chipaca, reverted prepare-device timeout change
<Facu> Chipaca, no, wait, which bug you mean?
<Chipaca> fgimenez: yes, snapd side
<Chipaca> Facu: what
<Chipaca> Facu: we've got a bug in the way 'snap info' formats its output
<Chipaca> Facu: this is not a launchpad bug
<Facu> Chipaca, it should say (for the fgimenez example) "candidate: closed" (same for beta), right?
<Facu> (at first I thought something else was broken, then I understood, and I just want you to NOT work twice)
<Chipaca> Facu: candidate: ^
<jdstrand> socket(PF_NETLINK, SOCK_RAW, NETLINK_ROUTE)
<jdstrand> ogra_: ^
<Chipaca> jdstrand: la que te recontra por las dudas
 * Chipaca runs
<jdstrand> Chipaca, ogra_: fyi, updated strace command for armhf (for grepping backscroll :) -- sudo ./strace -o /tmp/trace -D -f -vv -e '!_newselect,select,clock_gettime' -- /usr/bin/snap run --shell wifi-ap.automatic-setup
<Chipaca> nice
<jdstrand> on x86 you need to !select, but on armhf need to also not trace _newselect and clock_gettime otherwise it hangs
<Facu> Chipaca, no, it should say "candidate: closed" and "beta: closed" (that's why CPI returns "null" for those channels, not "tracking" or something, see Mark's answer to my specific question about this in https://bugs.launchpad.net/snappy/+bug/1628640
<mup> Bug #1628640: Add 'snap info' command showing publisher, channel map <Snappy:Fix Released by chipaca> <Software Center Agent:Fix Released by facundo> <https://launchpad.net/bugs/1628640>
<Chipaca> pstolowski: i thought you'd just 'git reset --hard HEAD^ && git push --force', but yours is much more polite
<pstolowski> Chipaca, yeah, I wasn't sure if github likes rewritten history
<Chipaca> Facu: oh. Hm. There might be conflicting info here.
<Facu> Chipaca, HO?
<jdstrand> ogra_: the simple instructions are that automatic-setup needs to 'plugs: network-bind', but don't do that yet. let me review my notes on NETLINK_ROUTE, maybe I should just add it to network
<Chipaca> Facu: nah, let me find things
<jdstrand> ogra_: (which it already plugs)
<Chipaca> Facu: either my memory plays tricks, or different people have different opinions on this and they need to settle it between themselves before we go off and implement it :-)
<Facu> Chipaca, no problem! note we modeled server behaviour around that specific Mark's answer, we may need to change stuff if that changes
<zyga> Chipaca: is the snap-info failure that's affecting PRs something you are on top of now?
<jdstrand> ogra_: what you could do is add to /var/lib/snapd/seccomp/profiles/snap.wifi-ap.automatic-setup at the end: socket AF_NETLINK - NETLINK_ROUTE
<Chipaca> zyga: the snap-info failure is resolved
<jdstrand> ogra_: and let me know if that fixes it for you
<Chipaca> zyga: it is no longer affecting PRs, since a while before the standup
<jdstrand> ogra_: you'll have to service snap.wifi-ap.automatic-setup stop, then start
<jdstrand> if I do that, I don't see the seccomp denial
<jdstrand> but I don't have the wlan plugged in
 * jdstrand goes to find it
<zyga> Chipaca: aha
<zyga> Chipaca: thanks!
<zyga> pstolowski: why are you doing the get/set thing? https://github.com/snapcore/snapd/pull/3282/files#diff-3a26c6cd9ed243bb3b102f2d9589ba30R300
<mup> PR snapd#3282: hooks: default timeout <Created by stolowski> <https://github.com/snapcore/snapd/pull/3282>
<zyga> pstolowski: specifically the set?
<Chipaca> fgimenez: do we have any test-snapd- snap that is not in stable?
<jdstrand> ogra_: huh, seems like it worked
<pstolowski> zyga, ah, good catch, it's unneeded, copy/paste from other test
<fgimenez> Chipaca: i think so, lately we have been releasing only to edge, let me check
<jdstrand> ogra_: $ sudo wifi-ap.status
<jdstrand> ap.active: true
<Chipaca> Facu: in the "snap and snapcraft ux" doc there's a ^ in 'snapcraft status' (with a comment elsewhere of 'snap info' having the same layout as that)
<jdstrand> ogra_: ok, so, yes, please test that, and I'll do a little research
<fgimenez> Chipaca: test-snapd-openvswitch-consumer
<Chipaca> Facu: where a closed channel that doesn't have a tracking thing shows "-", but closed-but-tracking is "^"
<Chipaca> fgimenez: thanks!
<pstolowski> zyga, updated
<Chipaca> niemeyer: ping, if you're around
<niemeyer> Chipaca: pongus
<Facu> Chipaca, can you give me the doc url, please?
<Chipaca> if you're not around, also ping, but Â¯\_(ã)_/Â¯
<Facu> :)
<zyga> pstolowski: thank you
<Chipaca> niemeyer: so i have conflicting specs for 'snap info', one from "make the channel map like 'snapcraft status'", which uses ^ or - to indicate closed channels (depending on whether they're tracking something or not), and a later comment in bug#1628640 that says they should show <channel>: closed
<Chipaca> bug #1628640
<mup> Bug #1628640: Add 'snap info' command showing publisher, channel map <Snappy:Fix Released by chipaca> <Software Center Agent:Fix Released by facundo> <https://launchpad.net/bugs/1628640>
<jdstrand> ogra_: where is the source code for bin/client?
<Chipaca> mup, you so confusing with "snapd#foo" and "bug #foo" :-)
<mup> Chipaca: I really wish I understood what you're trying to do.
 * zyga goes to take the garbage out
<jdstrand> morphis: maybe you know. where is the source code for bin/client in the wifi-ap snap?
<ogra_> jdstrand, lp:~snappy-hwe-team/snappy-hwe-snaps/+git/wifi-ap
<jdstrand> ah, thanks
<jdstrand> morphis: nm
<Chipaca> niemeyer: personally I think the ^/- communicates more than just "closed"
<Chipaca> and I think there is value in it being similar to 'snapcraft status'
<Chipaca> niemeyer: (right now we don't do either, because of a bug, which is why i'm bothering you with this :) )
<niemeyer> Chipaca: Can we have a forum topic for this?
<Chipaca> niemeyer: forum topics don't just grow on trees, you know
 * Chipaca creates
<Facu> Chipaca, niemeyer, I personally think that "^/-" is better, that's why I asked Mark specifically about that, and Mark said "<channel>: closed" (in that bug â)
<niemeyer> Chipaca: I know.. that's why I bother people to create them :)
<Chipaca> Facu: yeah, i'm suspecting that was a miscommunication / thinko
<Chipaca> Facu: but let's settle it one way or t'other
<niemeyer> That's exactly the sort of topic we should keep in the forum
<Facu> Chipaca, for me it's settled, in the bug :)
<Chipaca> Facu: either way you're good
<Chipaca> Facu: bug is all my end
<niemeyer> Let's please move the thread there so we have track record and rationale well kept
<Chipaca> yep yep
<Chipaca> on it
<Facu> Chipaca, not really, the store should not answer "null" for those tracks, otherwise you'd need to start doing algorithms in the client to see if the channels is tracking or nothing is really released into it
<niemeyer> Facu: Even if the bug isn't in your end, please join the thread with the details you have
<Chipaca> niemeyer: in our defense all this wandering and wondering comes from before the forum was a thing :-)
<Facu> Chipaca, the store should say "tracking" for you to present "^" and "null" for "-"
<Chipaca> Facu: you and your nullable strings
<Facu> Chipaca, this is what we're doing for snapcraft, anyway, so logic for channel interactions are defined in one place only (server side)
<Facu> niemeyer, of course
<Chipaca> now hush, i'm creating a forum topic :-p
<niemeyer> Chipaca: Yeah, no worries or blame assigned.. just trying to get ourselves (certainly including myself) into the practice of organizing these exchanges
<Chipaca> niemeyer: none implied either, just explaining how we got here
<Chipaca> and yes, agreed
<niemeyer> ð
<zyga> Facu: now that you said it â looks better than ^
<Facu> zyga, :)
<zyga> jdstrand: question about https://github.com/snapcore/snapd/pull/3051 -- did you have a chance to look at the kernel to see if this interface can land; I'm asking to know if I should spend effort trying to get it to be mergable today or should I just look at another PR
<mup> PR snapd#3051: interfaces: add consoles interface <Created by femdom> <https://github.com/snapcore/snapd/pull/3051>
<jdstrand> zyga: please look at another PR
<jdstrand> zyga: this requires extensive investigation to make sure we dtrt
<jdstrand> and it is behind a lot of other work atm
<jdstrand> zyga: in fact, please add the blocked tag
 * jdstrand commented in the pr already that it is in the queue, but behind other things
<Chipaca> niemeyer: the more I write in the description of this, the more it feels like a 1-minute conversation with mark would resolve it :-)
<Chipaca> anyhow, nearly done
<niemeyer> Chipaca: Mark is the forum too..
<Chipaca> good point!
 * Chipaca calls him out
<bdx> hey everyone, how can I list the available config params for a snap?
<Chipaca> Facu: niemeyer: https://forum.snapcraft.io/t/snap-info-channel-map-format/521
<niemeyer> Thanks!
<Chipaca> bdx: I don't think you can
<ogra_> well, you can dig into the hook script usually
<Chipaca> bdx: not sure if that's intentional or not-gotten-around-to-it yet
<Facu> Chipaca, gracias
<Chipaca> Facu: niemeyer: de nada caez's
<ogra_> (unless the package provides some binary config hook)
<Chipaca> caez'ns*
<Chipaca> zyga: â vs ^ TBD (when we have something that knows whether it's writing to something UTF-8 friendly or not
<zyga> jdstrand: OK
<Chipaca> )
<zyga> will do
<Chipaca> niemeyer: is it intentional that 'snap get' doesn't let you list all config keys?
<mup> PR snapcraft#1303 opened: kernel plugin: slightly improve the messaging of check_config() <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1303>
<Chipaca> niemeyer: e.g. 'snap get foo' dumping the whole config (vs 'snap get foo bar' just getting bar)
<Chipaca> also why does snap get return json instead of yaml /o\
<Chipaca> so many questions :-)
<pedronis> Chipaca: that would be part of having a schema, at the moment we could only list the currently set ones
<Chipaca> pedronis: https://forum.snapcraft.io/t/snap-get-config-dump/522/1
<Chipaca> :-)
<pedronis> that's not an official answer, you need niemeyer for that
<Chipaca> pedronis: ð
<Chipaca> :-)
<ogra_> ogra@pi3:~$ snap get core system
<ogra_> error: snap "core" has no "system" configuration option
<ogra_> ogra@pi3:~$ snap set core system.power-key-action=halt
<ogra_> ogra@pi3:~$ snap get core system
<ogra_> {
<ogra_> 	"power-key-action": "halt"
<ogra_> }
<ogra_> the error is also definitely a lie
<ogra_> (i guess adding "set" at the end of the error text would be enough though)
<Chipaca> pedronis: i think getting the set ones would be fine, at least until we have schemas (if a snap cares about this, all they need to do is set the defaults on first config call)
<niemeyer> Chipaca: I feel like a broken record, but can you open a forum topic to discuss those points?
<ogra_> write an IRC macro!
<Chipaca> niemeyer: way ahead of you dude
<ogra_> ;)
<Chipaca> niemeyer: in fact you already replied to one of them
<om26er> niemeyer, I tried to subscribe to snapcraft mailing list a few days ago, it said to be waiting for moderation from you. Can you please add me ?
<niemeyer> Chipaca: So are you just trying to confuse me?  :P
<Chipaca> niemeyer: which makes me think you've been using the wrong flask to top up your mate
<niemeyer> om26er: Heya
<Chipaca> niemeyer: :)
<niemeyer> om26er: Per the note at the front of the subscription page, we've integrated the mailing list into the forum
<Chipaca> niemeyer: i said those things on irc, then created the topics; i think you just read them here later
<niemeyer> Chipaca: You win
<niemeyer> :)
 * Chipaca takes the rest of the day off to celebrate
<niemeyer> om26er: So all conversations previously in the list are now landing directly into the forum
<niemeyer> om26er: You can still use it via email, if that's your preference
<niemeyer> om26er: https://forum.snapcraft.io
<om26er> niemeyer, interesting, will make finding old conversations easier.
<niemeyer> om26er: Yeah, quite a few things get nicer
 * om26er creates a new account.
<ogra_> and if you insist in email, you can actually use the email frontend to the forum ;)
<Chipaca> niemeyer: http://pastebin.ubuntu.com/24543228/ OK?
<Chipaca> zyga: ^
<Chipaca> or should i say zyga: ð
<Chipaca> (i'm only kidding about the ð; changed it back to ^ already)
<niemeyer> LOL
<om26er> are the release announcements also made on the forum now ?
<niemeyer> @Chipaca To be honest, it does look more clear than ^ :)
<nothal> niemeyer: No such command!
<om26er> 1 month and it all looks different already ;)
<Chipaca> mostly because ð is very hard to tell apart from ð
<niemeyer> @nothal You should ignore it then
<nothal> niemeyer: No such command!
<niemeyer> Chipaca: ROTFL
<niemeyer> Chipaca: Depending on the situation the second one might be more appropriate
<Chipaca> (but also, technically, because our output path does not know whether it's writing to something that likes UTF-8)
<niemeyer> Chipaca: Like.. "No stable, ð"
<Chipaca> oooh
<Chipaca> so one instead of -, the other instead of ^
<Chipaca> makes sense
<Chipaca> super easy to read :-p
<Chipaca> http://pastebin.ubuntu.com/24543243/
<zyga> Chipaca: looking
<zyga> Chipaca: haha
<zyga> Chipaca: well..
<zyga> Chipaca: if it gracefully degrades in ASCII-only terminals then +1
<Chipaca> TODO on this front:
<zyga> lol
<Chipaca> 1. patch yaml to not revert to binary mode when it finds printable non-ascii characters
<zyga> should we display ð©  instead of edge?
<Chipaca> [...lots more points...]
<Chipaca> 42. profit!
<Chipaca> 43. detect UTF-8 console
<zyga> Chipaca: that's spelled â¦
<Chipaca> Facu: wrt having "tracking" in the json from the store, that wouldn't really help us at the moment
<Chipaca> Facu: Â¯\_(ã)_/Â¯
<Chipaca> Facu: changing subjects: can a snap have a track with no open channels?
<noise][> Chipaca: I believe that would be the default state when we first create a track
<Chipaca> noise][: do you know of any snap with such a track in the store right now?
<Chipaca> wanting to see what it looks like in 'snap info'
<noise][> i don't think so but i could easily add a track for a test snap
<Chipaca> noise][: otherwise, if it's easy for you to do, can you create an 'ingest' track in the http snap?
<Chipaca> heh
<noise][> yep
<Chipaca> noise][: yes please
<Chipaca> just to have a concrete example for discussion
<noise][> Chipaca: created
<niemeyer> Lunch!
<Chipaca> noise][: looks like a track with no channels does not appear in channels_maps_list
<Chipaca> noise][: (and that's fine)
<noise][> yeah, there's no there there
<roadmr> ?
<noise][> seems reasonable since nothing has ever been released into any channels in the track, there's no channel map or history
<Chipaca> yup, as i say, that's fine
<Chipaca> if it had appeared we would've had to decide whether to show it at all on the client, or just hide it
<Chipaca> so huzzah, less stuff to decide :-)
<noise][> \o/
<nacc> niemeyer: i wonder if someone from the snap team can update the open bot code to respond to !snap like it does to !info? The latter does a apt query (iirc) or it might look at the archive. It seems like we would like to be able to query the store just as easily from IRC for status.
<nacc> niemeyer: let me find the linnk
<nacc> https://launchpad.net/ubuntu-bots
<nacc> niemeyer: we are starting to see some #ubuntu questions re: snaps and what's available periodically and i have to go run `snap find` myself :)
<ogra_> nacc, add a !snapforum command to that just prints "Please add this as a topic to the forum" ...
<ogra_> s/to/too/
<nacc> ogra_: heh :)
<mup> Bug #1689578 opened: Lack of shell completion installation support for command line apps <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1689578>
<nacc> ogra_: yeah, i was going to take a stab at it myself, but was hoping someone with more snap api knowledge could do it if not :)
<zyga> Chipaca: hey, tests/main/completion often fails on zesty
<zyga> Chipaca: are you running zesty by any chance?
<Chipaca> zyga: I am not. When it fails, can I see *how* it fails?
<Chipaca> zyga: spread, or autosmackagetest?
<zyga> Chipaca: just run it in qemu in a loop
<zyga> Chipaca: I think autosmacketest
<Chipaca> zyga: i'll give it a look later tonight
<zyga> Chipaca: thanks!
<Chipaca> meanwhile if you come across it in the wild, point me at the logs
<zyga> Chipaca: yep
<zyga> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-image/zesty/amd64/s/snapd/20170509_140006_d459a@/log.gz
<zyga> times out
<jdstrand> what's the trick these days with uploading something to the canonical account?
<jdstrand> s/to the/with the/
<zyga> jdstrand: not sure :/
<Chipaca> zyga: there are some improvements in tests/completion/lib.exp0 that are not in tests/main/completion/lib.exp0 which might make it better, if it's just timeouts
<zyga> jdstrand: the aha
<zyga> I meant
<Chipaca> jdstrand: i think you get given access per snap
<zyga> Chipaca: aha
<jdstrand> ah
<Chipaca> jdstrand: which snap?
<jdstrand> ogra_: do you have access to the classic snap?
<zyga> jdstrand: FYI: I added something that will make sure we're not happily running with old unused interface APIs https://github.com/snapcore/snapd/pull/3284/files#diff-634051b94f9aae657f75a08bc250a139L113
<mup> PR snapd#3284: interfaces: ensure that legacy interface methods are unused <Created by zyga> <https://github.com/snapcore/snapd/pull/3284>
<jdstrand> Chipaca: classic
<zyga> jdstrand: +1 welcome :)
<diddledan> jdstrand: if some of us, like me - being non canonical employee, knew the trick then we might be labelled haxx0rs ;-)
<Chipaca> zyga: that test failure looks like an actual timeout from the store
<jdstrand> yeah, I forgot it was per snap
<zyga> Chipaca: another bump in your graph/
<diddledan> I've lost count of how many times I've compiled my corebird snap trying to get a custom gtk build to work :-)
<Chipaca> jdstrand: i've got access to classic
<jdstrand> Chipaca: this will greatly improve the experience: http://paste.ubuntu.com/24543356/
<Chipaca> jdstrand: what's your lp email?
<jdstrand> Chipaca: jamie at canonical.com
<Chipaca> jdstrand: you've got mail
<jdstrand> I'm happy to be added and to do the upload, etc
<jdstrand> cool thanks
<Chipaca> jdstrand: shouldn't that have an 'assumes' also?
 * Chipaca doesn't know
<jdstrand> Chipaca: I've seen comments that assumes isn't well tested. I can add it since I'm going to leave the one in beta alone
<Chipaca> jdstrand: I don't really know :-)
<Chipaca> jdstrand: ev seems to really like it though
<jdstrand> the interfaces code has always handled it ok
 * jdstrand shrugs
<mup> Bug #1689578 changed: Lack of shell completion installation support for command line apps <Snapcraft:New> <snapd (Ubuntu):Fix Committed by chipaca> <https://launchpad.net/bugs/1689578>
<Chipaca> sergiusens: hiya
<Chipaca> sergiusens: dunno if you saw about the 'completer' thing
<Chipaca> oh that reminds me
<sergiusens> Chipaca: yeah, I saw things here and there
<Chipaca> jdstrand: i haven't tried to push something to the store that has a 'completer' key; will it break?
<Chipaca> validation i mean
<sergiusens> Chipaca: I wish you just create a PR against snapcraft though :-P
<Chipaca> sergiusens: do you need anything from me to be able to do support it?
<Chipaca> sergiusens: i know, but that'll not really be a good use of our time
<sergiusens> I don't think so, if all we need is to point into a file inside `prime` (aka, the snap), then it is all good
<sergiusens> when is this released?
<Chipaca> sergiusens: it's in edge already
<Chipaca> sergiusens: it'll move to beta tomorrow
<sergiusens> Chipaca: when to us normals?
<Chipaca> sergiusens: and it'll take a couple of weeks to reach the normies :-p
<Chipaca> sergiusens: (modulo QA passing)
<sergiusens> Chipaca: I can create a PR but not merge to see how it goes, but not going to make it in as we have bad precedent on introducing assumes and environment before it reached users
<Chipaca> jdstrand: if the validator needs work for this, a bug task on #1689578 might be appropriate
<mup> Bug #1689578: Lack of shell completion installation support for command line apps <Snapcraft:New> <snapd (Ubuntu):Fix Committed by chipaca> <https://launchpad.net/bugs/1689578>
<Chipaca> sergiusens: oh, totally
<sergiusens> if `assumes` were functional, we could use that to proceed in an elegant way
<zyga> I thought that assumes are functional
<Chipaca> so did i :-)
<Chipaca> sergiusens: in any case, I added a snapcraft bug task to the above bug, to track this
<Chipaca> sergiusens: and i think not implementing it in snapcraft until it's fix-released in snapd is fine
<zyga> pstolowski: can you review that branch (no-funny-interfaces) and once it lands, merge it into your PR
<zyga> pstolowski: I'd like to detect the attribute-unaware methods this wayt
<jdstrand> Chipaca: task added. classic updated. PR for classic submitted
<sergiusens> zyga: Chipaca functional internally maybe, but where is the documentation and where are the allowed keywords?
<Chipaca> jdstrand: huzzah
<pstolowski> zyga, ok
<Facu> Chipaca, just arrived, was AFK; may I help you with anything or it's solved?
<jdstrand> now people's logs won't fill up when using classic :)
<Chipaca> Facu: i don't think there's anything to do at this point in time
<zyga> sergiusens: we have had a few but I think the idea is to use "assumes snapd25" or similar so that you can know you are using at least certain snapd version
<ogra_> jdstrand, i do
<ogra_> (i think)
<diddledan> ooh, getting closer. corebird now fires-up into a gui
<diddledan> I needed to hack the desktop-gtk3 definition
<jdstrand> ogra_: ah, thanks, but nm, got it sorted
<ogra_> jdstrand, source is at https://github.com/snapcore/classic-snap
<ogra_> (in case you didnt know that yet)
 * jdstrand ods
<jdstrand> nods even
<jdstrand> I already have a PR
<ogra_> cool
<Chipaca> zyga: did you see that we've got kernel debs to try? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819
<mup> Bug #1672819: exec'ing a setuid binary from a threaded program sometimes fails to setuid <amd64> <apport-bug> <kernel-da-key> <xenial> <Linux:Unknown> <linux (Ubuntu):Triaged> <linux (Ubuntu Xenial):Incomplete by colin-king> <https://launchpad.net/bugs/1672819>
<zyga> Chipaca: nope, not yet
<pstolowski> zyga, +1 with one comment
<zyga> pstolowski: thank you, looking
<zyga> pstolowski: thanks! applied :)
<sergiusens> zyga: great, now I need a map of snapd versions and features provided ;-)
<Chipaca> sergiusens: {i: awesomeness*i for i in range(...)}
<mup> PR snapd#3285 opened: interfaces/network: workaround Go's need for NETLINK_ROUTE on ARM with 'net'. LP: #1689536 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3285>
<zyga> sergiusens: just set to current ^_^
<mup> PR snapd#3286 opened: cmd/snap: tweak info channels output <Created by chipaca> <https://github.com/snapcore/snapd/pull/3286>
<zyga> Chipaca: can you do a 2nd review on trivial, important: https://github.com/snapcore/snapd/pull/3285
<mup> PR snapd#3285: interfaces/network: workaround Go's need for NETLINK_ROUTE on ARM with 'net'. LP: #1689536 <Critical> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3285>
<Chipaca> zyga: ew
<zyga> Chipaca: another timeout on tab completion https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-snappy-dev-image/yakkety/amd64/s/snapd/20170509_083625_159d3@/log.gz
<mup> PR snapd#3281 closed: tests: add test for empty snap name on revert <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3281>
<zyga> niemeyer: can you please +1 https://github.com/snapcore/snapd/pull/3026
<mup> PR snapd#3026: cmd/snap-confine: use defensive argument parser <Created by zyga> <https://github.com/snapcore/snapd/pull/3026>
<Chipaca> zyga: and in the same place
<Chipaca> May 09 08:26:32 autopkgtest snapd[611]: 2017/05/09 08:26:32.144671 daemon.go:176: DEBUG: uid=0;@ GET /v2/find?name=test%2A 5.073657694s 200
<Chipaca> zyga: the store takes 5 seconds to reply
<Chipaca> zyga: expect's timeout is 5 seconds
<Chipaca> Â¯\_(ã)_/Â¯
<zyga> Chipaca: thanks!
 * Chipaca is wearing out his :shrug: today
<zyga> Chipaca: I wish that was easier to grok :D
<zyga> Chipaca: like if >5.0 printf "WTF is so slow?"
<Chipaca> zyga: suggest bumping expect timeout to, say, 7 seconds :-)
<niemeyer> zyga: +1
<zyga> niemeyer: thank you!
<zyga> niemeyer: can you also look at https://github.com/snapcore/snapd/pull/3284 perhaps, I'd appreciate advice on how to make that better
<mup> PR snapd#3284: interfaces: ensure that legacy interface methods are unused <Created by zyga> <https://github.com/snapcore/snapd/pull/3284>
<zyga> I wanted to avoid using reflection in non-test code
<niemeyer> zyga: I really want to finish my expense reporting.. it's way to tempting not to
<zyga> I could also make the tinye "definer" interfaces public
<niemeyer> too
<zyga> niemeyer: understood :)
<zyga> we are two PRs away from being one-page-long
<mup> PR snapd#3026 closed: cmd/snap-confine: use defensive argument parser <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3026>
 * zyga goes after another interface
<Chipaca> niemeyer: dunno if you saw but in the 'snap info' output i've had to change the - to a -- (for the 'channel is closed, and no less risky channel is open' case)
<Chipaca> because, âstable: -â is not valid yaml
<Chipaca> :-)
<Chipaca> âstable: --â is, though, so i'm going with that
<niemeyer> Ouch
<Chipaca> :-)
<niemeyer> Chipaca: How about an ndash?
<niemeyer> Too confusing?
<Chipaca> niemeyer: not confusing, but it'll look nasty in some cases
<zyga> what is an ndash?
<Chipaca> niemeyer: (non-utf8 aware cases, which will already look nasty for other reasons i'm sure)
<Chipaca> zyga: a dash the width of an n
<zyga> aah
<Chipaca> zyga: as opposed to the mdash which is a dash the width of an m
<niemeyer> This: foo: â
<Chipaca> zyga: also an ndash is 1 en wide, and an mdash is one em wide
<Chipaca> also an x is one en tall
<zyga> I think I will hug my 1-cell sized monospace fonts :
<Chipaca> ... and onf of those can be false in weird fonts
<zyga> Chipaca: about our discussions earlier
<zyga> Chipaca: double-cell glyphs!
<zyga> Chipaca: back to regular broadcast
<niemeyer> Chipaca: It does look nicer than -- though
<mup> Bug #1673763 changed: Help for 'version' <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1673763>
<mup> Bug #1680097 changed: core:network-bind plug is not connected after ubuntu-core -> core transition <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1680097>
<Chipaca> zyga: hah. what about characters that are wide or thin depending
<Chipaca> depending on what? who knows. depending.
<Chipaca> (but people get upset)
 * niemeyer wonders how unreasonable that is
<Chipaca> niemeyer: it does
<zyga> Chipaca: there is a block like that
<zyga> Chipaca: they are so-called ambiguous characters
<zyga> Chipaca: and may be half-width or regular size
<Chipaca> i know
<zyga> Chipaca: where half width is really "regular" and regular is "double cell"
<zyga> anyway
<zyga> insane stuff
<Chipaca> niemeyer: so... should I just do it?
<niemeyer> Chipaca: If we also used hands it'd be more clear that it's UTF-8 :)
 * niemeyer teases
<Chipaca> niemeyer: i was about to suggest using an actual arrow
<zyga> actual arrows are really ... plentiful in unicode
<niemeyer> Chipaca: Can you make an example for us to ponder on?
<niemeyer> Chipaca: An arrow seems nicer than ^ as well, and not a big departure
<Chipaca> niemeyer: â â§ âª â« â° â¤ â¥ â¥ â¥£ â¥¾
<niemeyer> First one seems nice
<niemeyer> Although a bit too invisible
<niemeyer> Chipaca: Do we have a larger one that looks like it
<niemeyer> ?
<niemeyer> Chipaca: I'm sure unicode must have hundreds of arrows that look almost exactly like that :)
<Chipaca> yeah
<zyga> that last one looks like a fountain
<Chipaca> there's a lot more arrows pointing right than up though
<zyga> http://www.fileformat.info/info/unicode/block/arrows/utf8test.htm
<Chipaca> niemeyer: let me put it in code so you can see it in context
<zyga> http://www.fileformat.info/info/unicode/block/arrows/list.htm
<zyga> I see fields of ... arrows
<zyga> I myself am quite fond of â¡
<zyga> though â¯ is funky, just goes the wrong way
<Chipaca> niemeyer: http://pastebin.ubuntu.com/24543901/
<Chipaca> niemeyer: looks like a tree
<Chipaca> niemeyer: if anything it's _too_ big
<zyga> Chipaca: I'd add a "legend" line at the bottom saying what those arrows and funkiness all mean
<Chipaca> i think if we need that, we're doing it wrong
<Chipaca> ah, â is a lot less bold in the ubuntu mono font
<Chipaca> bah. not in the ubuntu font. it's coming from DejaVu Sans
<zyga> Chipaca: look at a map
<zyga> Chipaca: maps have legend, they are not doing it wrong, it's just everything is unfamiliar at first
<zyga> Chipaca: you may skip the legend later but it's useful to have one
 * Chipaca likes mapmaking, but doesn't feel the terminal is an adequate place for it
<Chipaca> anyway, i must EOD
<cratliff> I'm working on converting some systemd services to snaps.  Is there a snappy way to edit variables that would be included in a environment file?
<Chipaca> niemeyer: zyga: leave me a comment on the PR if you decide anything wrt this
 * Chipaca off
<zyga> cratliff: in the environment of everything else in the system?
<cratliff> that could probably work for me, but the way it is working right now is the services start with an EnvironmentFile parameter that sets a few variables used in the ROS launch file and other places.
<zyga> cratliff: aha
<zyga> cratliff: can you use the environment section in the snapcraft yaml? are those constants ore variables?
<cratliff> I must have missed the environment section details.  They are used to reuse packages on multiple devices so at runtime they are constants.
<zyga> cratliff: give that a try!
<cratliff> can you send me a link to a doc? I'm still having trouble finding it.
<zyga> cratliff: I don't know where this is documented, perhaps sergiusens or kyrofa does
<kyrofa> cratliff, zyga I'm not sure where it's documented either, but here's an example: https://github.com/snapcore/snapcraft/blob/master/demos/git/snap/snapcraft.yaml
<zyga> niemeyer: can you please re-review https://github.com/snapcore/snapd/pull/2869; it has jdstrand's +1 and I added one missing bit and reviewed it myself
<mup> PR snapd#2869: interfaces/builtin: add online-accounts-service interface <Created by mardy> <https://github.com/snapcore/snapd/pull/2869>
<zyga> kyrofa: thank you!
<niemeyer> zyga: Still doing expenses
<zyga> niemeyer: sure
<cratliff> Cool, thanks for pointing me in the right direction.
<kgvelkov> hey
 * zyga_ breaks for evening walk
<mup> PR snapd#3285 closed: interfaces/network: workaround Go's need for NETLINK_ROUTE with 'net'. LP: #1689536 <Critical> <Created by jdstrand> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3285>
<mup> PR snapd#3279 closed: tests: extend kernel-module-control interface test <Created by fgimenez> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3279>
<mup> PR snapd#3251 closed: packaging: cleanup how built-using is generated  <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3251>
<Chipaca> zyga: you around?
<Chipaca> zyga: have you done the thing about the expect timeout?
#snappy 2017-05-10
<abes> dragonboard emmc flashing instead of SD
<abes> https://discuss.96boards.org/t/ubuntu-core-on-emmc/1611
<mup> PR snapcraft#1304 opened: cleanbuild: set the container language to en_US.UTF-8 <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1304>
<mup> PR snapd#3284 closed: interfaces: ensure that legacy interface methods are unused <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3284>
<zyga> good morning
<zyga> hey there mvo! :)
<zyga> thanks for merging that :)
<zyga> woot, we are on one-page-long of PRs :)
<mvo> zyga: hey, good morning
<mup> PR snapd#3286 closed: cmd/snap: tweak info channels output <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3286>
<zyga> mvo, jdstrand, tyhicks: in addition to coverity I would consider adding https://github.com/google/oss-fuzz
<pstolowski> morning
<zyga> hey hey :)
<zyga> pstolowski: can you please merge master into https://github.com/snapcore/snapd/pull/3119 and add the extra description for the old interface methods
<mup> PR snapd#3119: interfaces: API additions for interface hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3119>
<pstolowski> zyga, yes, doing right now
<zyga> excellent, thank you!
<mup> PR snapd#3287 opened: tests: unify tests/{main/completion,completion}/lib.exp0 <Created by chipaca> <https://github.com/snapcore/snapd/pull/3287>
<mup> PR core-build#10 closed: make /etc/environment writable <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/10>
<Chipaca> zyga: ^ 3287 should fix the expect timeouts
<mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<zyga> Chipaca: looking
<zyga> Chipaca: thank you!
<pstolowski> zyga, update iface-hooks-api with master, waiting for tests
<zyga> pstolowski: did you find any stale APIs?
<pstolowski> zyga, note, I didn't add the checkers for optional ValidatePlug/Slot methods since they really appear in the followup PR #3120, so if we want them, they should be added in that other PR
<pstolowski> zyga, yes, but only in the "expected" ones (new interfaces that appeared in msaster)
<pstolowski> *master
<zyga> pstolowski: excellent, thank you!
<morphis> zyga: feeling comfortable to give https://github.com/morphis/meta-snappy/pull/9 a shot?
<mup> PR morphis/meta-snappy#9: Add support for pyro and drop golang toolchain <Created by morphis> <https://github.com/morphis/meta-snappy/pull/9>
<zyga> morphis: yes, if you tell me how to try this
<morphis> zyga: https://github.com/morphis/meta-snappy/blob/master/README.md but checkout out the pyro branch of poky instead of morty
<zyga> ok
<zyga> morphis: btw, what is it with the naming scheme?
<zyga> pyro/morty/poky?
<morphis> pyro and morty are release code names
<morphis> poky is the name of the collection of recipes Yocto releases
<morphis> https://www.yoctoproject.org/tools-resources/projects/poky
<morphis> morty is the current stable release and pyro the next one
<morphis> https://wiki.yoctoproject.org/wiki/Releases
 * zyga mentally paste's chipaca's signature ascii emoji
<zyga> mvo: is good-to-go, if you want you can override the review from gustavo (it is applied) and merge when green https://github.com/snapcore/snapd/pull/2929
<mup> PR snapd#2929: interfaces/builtin: add storage-framework-service interface <Created by michihenning> <https://github.com/snapcore/snapd/pull/2929>
<mvo> zyga: nice, thank you
<Chipaca> zyga: you mean ã½(Â´â½`)/ right?
<zyga> Chipaca: lol :D
<Chipaca> zyga: ( Ë Â³Ë)â¥
<Chipaca> zyga: do the mount namespace thingies do the right thing on snapd restart?
<mup> PR snapd#3287 closed: tests: unify tests/{main/completion,completion}/lib.exp0 <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3287>
<zyga> Chipaca: which is?
<zyga> Chipaca: (we don't touch them)
<zyga> Chipaca: which is arguably perhaps wrong (I have a bug open for that)
<Chipaca> zyga: I don't know what the right thing is :-)
<zyga> https://bugs.launchpad.net/snapd/+bug/1667479
<mup> Bug #1667479: mount namespace is not discarded when core snap changes revision <snapd:In Progress by zyga> <https://launchpad.net/bugs/1667479>
<zyga> Chipaca: I only know about this thing being wrong
<Chipaca> zyga: but i was wondering whether it was leftover state that could break if expectations changed
<zyga> which is a special case of update-ns
<zyga> aha
<zyga> Chipaca: each test restore code unmounts them
<zyga> Chipaca: so they should go away
<zyga> Chipaca: as for restart
<zyga> Chipaca: we re-gen new seccomp and apparmor profiles then but those don't affect the mount namespace
<zyga> Chipaca: we don't regenerate (or update as update-ns is not finished) the mount profiles
<pedronis> mvo: hi, I +1ed snapd#3263 but it seems to have failing tests
<mup> PR snapd#3263: snap: make `snap prepare-image --extra-snaps` derive side info <Created by mvo5> <https://github.com/snapcore/snapd/pull/3263>
<mvo> pedronis: thanks, checking now
<mvo> pedronis: test failures were in the completion tests, I think some fixes went into master, lets see if that helps
<Chipaca> zyga: and should we?
<zyga> Chipaca: yes
<zyga> Chipaca: we should return to that
<zyga> Chipaca: it dates back to the BuildID thing
 * zyga thinks that https://github.com/snapcore/core-build/pull/11 is scary
<mup> PR core-build#11: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<zyga> mvo: what are your thoughts on https://github.com/snapcore/snapd/pull/3226#discussion_r115584968
<mup> PR snapd#3226:  snap-repair: add `snap-repair run`  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3226>
<Chipaca> brb, new kernel to test
<zyga> pstolowski: some test failures here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/ppc64el/s/snapd/20170510_094222_ff1d7@/log.gz
<pstolowski> looking
<zyga> pstolowski: for your 3120 PR
<zyga> morphis: I'll look at building oe soon
<zyga> morphis: but I will do a few more reviews before that
<morphis> zyga: ok
 * zyga looks at mvo's https://github.com/snapcore/snapd/pull/2592
<mup> PR snapd#2592: many: add support for session dbus services via snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/2592>
<zyga> fgimenez: hey, do you know why the openvswitch tests are failing? I see them fail frequently
<zyga> fgimenez: e.g. debian-unstable-64:tests/main/interfaces-openvswitch failed here: https://travis-ci.org/snapcore/snapd/builds/230619514?utm_source=github_status&utm_medium=notification
<fgimenez> zyga: looking
<zyga> fgimenez: thanks!
<mvo> zyga: makes sense, no disagreement, I think we need to consider how far we want to go in each iteration
<mvo> zyga: re the reapir run code question
<morphis> pedronis: is the syntax of the `snap alias` command changing with the upcoming 2.26?
<pstolowski> zyga, ah, looks like one of the failing spread tests needs some reworking now. thanks, will look at it some time later. in the meantime it looks like 3119 is ok
<zyga> pstolowski: great, do you want to wait for gustavo's review
<fgimenez> zyga: the package installation seems to fail in debian-unstable https://travis-ci.org/snapcore/snapd/builds/230619514#L2868 i haven't seen this error on ubuntu
<fgimenez> zyga: i'll try to reproduce and get a debug console for getting more info
<zyga> fgimenez: thank you!
<zyga> fgimenez: note that it happens frequently but not always
<zyga> perhaps related to ordering?
<zyga> fgimenez: can I restart that run now?
<fgimenez> zyga: ok thanks! no idea, will let you know how it goes
<pstolowski> zyga, with 3119 yes, i'd like niemeyer to review it too
<zyga> pstolowski: ok
<pedronis> morphis: ?
<pedronis> it already changed in 2.25
<morphis> pedronis: hm, which isn't yet in stable, right?
<pedronis> no
<morphis> that would explain why it breaks all our tests
<morphis> but only when run against edge/beta/candidate
<pedronis> morphis: what kind of tests?
<zyga> morphis: you have some real test failures on https://github.com/snapcore/snapd/pull/3222
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<morphis> pedronis: spread tests we have for all snaps we maintain
<morphis> pedronis: we call `snap alias pulseaudio parec` and then expect /snap/bin/parec to show up
<pedronis> morphis: aliases work very differently now, unless you have them setup in the store, there is little point in playing witht them, it is something only the user can do now picking their own names
<morphis> pedronis: we have them all in the store
<pedronis> morphis: ok, then not sure why you are using "snap alias"Â in those tests, we their are not the main spread tests
<morphis> pedronis: need to look a bit more into that
<pedronis> bit confused here
<morphis> pedronis: we list them in snapcraft.yaml
<morphis> and then a `snap alias pulseaudio pactl` call was meant to create the alias in /snap/bin
<pedronis> morphis: well if they are in the store, no need for that
<morphis> the snap-declaration in the store allows those aliases to be setup automatically
<pedronis> IÂ mean that tests is not relevant anymore
<pedronis> that doesn't work that way, it's not inteded to work that way anymore
<pedronis> you get what the store sets up
<morphis> pedronis: so how do I get now an alias for a locally installed snap?
<pedronis> morphis: it's all in the forum post:  https://forum.snapcraft.io/t/improving-the-aliases-implementation/18
<pedronis> morphis: you can setup what we call manual aliases
<pedronis> the syntax is a bit different:   snap alias  SNAP.APP ALIAS
<morphis> ah
<morphis> that is why it breaks
<morphis> so a `snap alias pulseaudio pactl` doesn't work anymore
<pedronis> yes, I said so maybe 3 times :)
<morphis> but I didn't got the point that it now needs to be <snap>.<app>
<pedronis> well, as I said I don't understand why you need that command?
<pedronis> is the test installing the snap locally?
<morphis> yes
<pedronis> ah
<morphis> pedronis: we were verifying that the alias defined in the snap was working
<morphis> but as you said, that isn't needed anymore
<pedronis> that doesn't make sense anymore
<pedronis> there's is no alias defined in the snap concept anymore
<pedronis> IÂ mean you can fix the test  for the new syntax but as well drop it
<pedronis> if the intention was checking the aliases in the snapcraft.yaml
<pedronis> we will deprecate those at some point
<morphis> ok
<pedronis> anyway the forum post explains a bit all of this
<morphis> pedronis: are all assertions on the store side are updated automatically?
<pedronis> morphis: we did a pass of doing that with jdstrand
<morphis> if I remember well they just defined a list of allowed aliases like [pactl, parec]
<morphis> pedronis: great
<zyga> linode seems busy now
<zyga> coffee break then :)
<pedronis> morphis: the syntax is a bit different in the assertion as well, at the moment we defined both old and new syntax in the assertions (the store checks for that)
<morphis> good
<pedronis> because now the assertions needs to list a target too
<morphis> pedronis: so with 2.25 going to stable it is safe to drop the aliases:  part from the snap, right?
<morphis> however I think we will leave them for a bit more to gurantee everyone gets correctly updated
<pedronis> yes, when all your clients you care about are updated to 2.25 though
<morphis> yeah, that is tricky
<pedronis> morphis: this is the pulseaudio assertion btw atm: http://pastebin.ubuntu.com/24548266/  you can see the old syntax (auto-aliases) and the new (aliases)
<morphis> pedronis: thanks!
 * pedronis lunch
<Chipaca> as best as I can tell so far, cking's fix for bug #1672819 works
<mup> Bug #1672819: exec'ing a setuid binary from a threaded program sometimes fails to setuid <amd64> <apport-bug> <kernel-da-key> <xenial> <Linux:Unknown> <linux (Ubuntu):Triaged> <linux (Ubuntu Xenial):Incomplete by colin-king> <https://launchpad.net/bugs/1672819>
<Chipaca> nearly done with all the reproducers
<Chipaca> \o/
<zyga> re
<morphis> zyga: something has changed in suse.. https://build.opensuse.org/package/live_build_log/system:snappy/snapd/openSUSE_Tumbleweed/i586
<zyga> morphis: aha, it seems that rst2man is no longer shipped by the package we install
<morphis> yes
<zyga> morphis: we can fix this by (perhaps) depending on /usr/bin/rst2man directly
<zyga> (whatever the package name)
<jdstrand> pedronis: re no alias in the snap concept> I still see these trickle in. should I add a warning (and therefore needs human review) to the review tools to let people know to not include that?
<morphis> zyga: is there macro for that?
<fgimenez> zyga: the openvswitch test is disabled for debian on master and is enabled in https://github.com/snapcore/snapd/pull/3274 right?
<jdstrand> pedronis: also, I've been adding v1 to the snap declaration as a matter of course in all cases in case of rollbacks, etc. how long do you think I should do that?
<mup> PR snapd#3274: cmd/snap,tests/main: add force-devmode switch instead of spread system blacklisting <Created by morphis> <https://github.com/snapcore/snapd/pull/3274>
<jdstrand> pedronis: also, hi :)
<zyga> morphis: no, it's just Requires: /usr/bin/rst2man AFAIR, let me check
<morphis> fgimenez: yes, something I still need to look into
<morphis> zyga: nice, let me try that
<zyga> fgimenez: yes, parts of that test are now enabled
<zyga> fgimenez: note that this test was also failing on ubuntu
<zyga> fgimenez: just not always
<fgimenez> morphis: zyga aha ok thanks, i'll pull that branch and try to reproduce
<zyga> fgimenez: it would be good to try to run that same seqeunce with -debug
<fgimenez> zyga: do you have any reference to a failure in ubuntu? i haven't seen that one
<mup> PR snapd#3263 closed: snap: make `snap prepare-image --extra-snaps` derive side info <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3263>
<zyga> fgimenez: not at hand, I recall re-triggering tests a few times on this test
<fgimenez> zyga: ok will try on ubuntu too
<morphis> zyga: that requires line doesn't seem to help
<mup> PR snapd#3288 opened: tests: disable create-key test on ppc64el for artful (expect not working) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3288>
<zyga> morphis: let me look
<zyga> morphis: maybe it's just a fedora thing, e.g. look at Requires: /sbin/ifconfig in https://fedoraproject.org/wiki/Packaging:Guidelines
<morphis> possible
<zyga> morphis: worth asking in a opensuse IRC channel perhaps?
<zyga> morphis: or looking at a few random packages
<morphis> yeah, let me spend a bit more time with this and then I will do that
<morphis> zyga: ok, looks like it is python-doctuils vs. python3-docutils
<jdstrand> mvo: hey, is 2.26 cut yet such that we are doing point releases?
<mvo> jdstrand: not quite done yet, zyga brought 1689332 to our attention and I think we want to fix this first
<jdstrand> mvo: ok. I just wanted https://github.com/snapcore/snapd/pull/3285 in there, but that is already in master so sounds like we are good
<mup> PR snapd#3285: interfaces/network: workaround Go's need for NETLINK_ROUTE with 'net'. LP: #1689536 <Critical> <Created by jdstrand> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3285>
<zyga> mvo: do you need a hand with that? I will be done with reviews shortly (well, in 1-2 hours)
<zyga> mvo: I can help you after the standup
<pedronis> jdstrand: well 2.25 is not even in stable, it will take a bit
<mvo> jdstrand: yes, that one is in
<pedronis> jdstrand: but we do want to deprecate aliases in snap.yaml and not need auto-aliases in decls but it will take a while
<jdstrand> pedronis: sure, I was more talking about making sure that PR made it into the correct branch if there was one outside of 2.26
<mvo> zyga: it should be fine, I was thinking we could simply forbid to install ubuntu-core. existing systems with older ubuntu-core will auto-transition on refresh so it is really only a problem if you frehsly install ubuntu-core
<zyga> mvo: I think we should instead ask if we need to release ubuntu-core ever again
<jdstrand> pedronis: oh haha. you were talking about aliases. funny cause your comment actually sorta worked for what I was talking about with mvo :)
<jdstrand> pedronis: ok, let me take a note of that and at some point I'll introduce a warning
<mvo> zyga: maybe that works as well, we just need to make sure that the transition works for those people who install from old 16.04.1 mediums (dvd/thumb)
<morphis> zyga: ok, fixed it: https://build.opensuse.org/package/show/home:mrmorph:branches:system:snappy/snapd
<zyga> morphis: let's stop building for 42.1
<zyga> morphis: why do we depend on openssh? for git clones?
<pedronis> mvo: did we ever tested anything working but apt upgrade for 16.04.1 ?
<ogra_> what else would you test ?
<morphis> zyga: we now depend on ssh-keygen
<jdstrand> mvo: oh (not that this needs to be handled with priority), did you see my PR for the classic snap?
<zyga> ahh
<jdstrand> mvo: (just want in on your radar)
<ogra_> jdstrand, given you already uploaded it ... thats just paperwork :)
<jdstrand> ogra_: indeed, but I didn't want someone to upload without it :)
<ogra_> mvo, btw, could i have commit access to the core-snap branch (i'd have merged jamies PR already if i was able)
<jdstrand> and let me tell you, my logs are much happier now :)
<ogra_> yay
<ogra_> there is another issue with the pty (again)
<mvo> jdstrand: not sure, I have a look
<ogra_> that i want to tackle soon
<mvo> ogra_: not sure I can give you that, access is mostly done by gustavo
<ogra_> niemeyer, can i get commit access to https://github.com/snapcore/classic-snap ?
<jdstrand> mvo: https://github.com/snapcore/classic-snap/pull/9
<mup> PR classic-snap#9: plugs classic-support and update dump for latest snapcraft <Created by jdstrand> <https://github.com/snapcore/classic-snap/pull/9>
<jdstrand> mvo: again, not high priority
<mvo> jdstrand: thank you!
<mvo> jdstrand: merged, thank you. and you are very welcome to upload
<jdstrand> mvo: thanks!
<stokachu> noise][, cprov: could I get some assistance with https://forum.snapcraft.io/t/sosreport-moved-under-sosreport-team/480
<mvo> ogra_: I will land #30 for snapcore/core and #5 for snapcore/core-build
 * ogra_ checks
<noise][> stokachu: I can take a look in a couple hrs i think
<ogra_> is that the cloud stuff ?
<stokachu> noise][: ok thanks
<ogra_> mvo, perfect, i wanted to bring that up in todays standup ...
<mup> PR core#30 closed: Update core snap cloud-init configuration <Created by raharper> <Merged by mvo5> <https://github.com/snapcore/core/pull/30>
<mup> PR core-build#5 closed: Update cloud-init configuration <Created by raharper> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/5>
 * ogra_ hugs mvo 
<ogra_> rharper, ^^^ happy testing
<mvo> ogra_: my pleasure, we really need to hug rharper here :)
<ogra_> yeah
<ogra_> mvo, oh, the second one needs a PPA upload and there is another sync missing that i need to do before
<ogra_> (i'll handle that)
<zyga> pstolowski: what are the next steps for https://github.com/snapcore/snapd/pull/3212
<mup> PR snapd#3212: api, ifacestate: resolve disconnect early <Created by stolowski> <https://github.com/snapcore/snapd/pull/3212>
<mvo> ogra_: cool, thank you
<morphis> zyga: can you disable the 42.1 build?
<zyga> morphis: let me know when you want to update the opensuse repository with the extra patches
<zyga> morphis: yes
<morphis> zyga: what do you mean with extra patches
<zyga> morphis: extra build deps for the next release
<morphis> ah
<zyga> morphis: https://build.opensuse.org/package/show/system:snappy/snapd no longer builds for 42.1
<morphis> I will propose a review soon
<zyga> excellent, thank you!
<pedronis> zyga: I need to look at it again it seems
<pstolowski> zyga, probably a discussion whether we want to do anything about the fact that we may have conflicting changes (other than disconnect) in progress and currently there is no way to achieve this sort of dependency; plug CheckChangeConflict question needs adressing/answering but I haven't looked at this yet
<pstolowski> s/plug/plus/
<zyga> pedronis, pstolowski: aha, thank you;
<zyga> Chipaca: can you do a trivial 2nd review on https://github.com/snapcore/snapd/pull/3288
<mup> PR snapd#3288: tests: disable create-key test on ppc64el for artful (expect not working) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3288>
<Chipaca> zyga: already am
<zyga> thank you :)
<mup> PR core-build#12 opened: sync missing deb upload into branch <Created by ogra1> <https://github.com/snapcore/core-build/pull/12>
<jacekn> hello. Is there a way to install and connect snap to a slot in one step? I'm building a snap that will not start unless it's connected to log-observe slot
<ogra_> morphis, mvo, https://github.com/snapcore/core-build/pull/12 please ...
<mup> PR core-build#12: sync missing deb upload into branch <Created by ogra1> <https://github.com/snapcore/core-build/pull/12>
<zyga> jacekn: if an assertion is present in the store it will connect to log-observe
<zyga> jacekn: other than that, no]
<morphis> zyga: https://build.opensuse.org/request/show/494230
<morphis> ogra_: will have a look
<ogra_> thx
<zyga> morphis: thank you
<zyga> morphis: I approved but perhaps we can drop the python-docutils dependency
<zyga> morphis: is one needed for 42.2 and other for tumbleweed?
<morphis> zyga: joining us?
<morphis> zyga: I think so
<jacekn> zyga: so I'm after allow-auto-connection yes? Where can I find docs about how to get it set up?
<zyga> jacekn: I think you need to request a new snap declaration assertion from the store, jdstrand can set one up for you, I think
<pedronis> pstolowski: givent that connect/disconnect involve exactly two snaps it should be possible to fix CheckChangeConflict
<jacekn> zyga: ok thanks a lot
<pedronis> (autoconnect is a different story but we will get there)
<jdstrand> jacekn: follow the first bulletpoint under 'Process' in https://forum.snapcraft.io/t/process-for-reviewing-aliases-and-auto-connections/455
<jacekn> jdstrand: aha (I was looking for something in the official docs: https://docs.ubuntu.com/core/en/reference/assertions/snap-declaration )
<jdstrand> jacekn: this is all new
<jdstrand> so the docs haven't caught up yet
<pstolowski> pedronis, fair point. i'll take a look at this soon, got sidetracked by other things (namely snapctl outside of hooks)
<jacekn> jdstrand: ok understood
<mup> PR snapd#3289 opened: daemon: do not allow to install ubuntu-core anymore <Created by mvo5> <https://github.com/snapcore/snapd/pull/3289>
<niemeyer> Mornings
<niemeyer> mvo: I think you could as you were an admin on that repo, but done either way
<niemeyer> mvo: I usually give access to a team rather than a person, btw..
<niemeyer> mvo: snapd-committers in this case
<niemeyer> ogra_: Done
<mvo> niemeyer: thank you
<ogra_> niemeyer, thanks ... i think that was rather special since it initially lived in a private branch...
<ogra_> well, not private but personal
<mup> PR snapd#3288 closed: tests: disable create-key test on ppc64el for artful (expect not working) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3288>
<niemeyer> ogra_: Yeah, that should be it
<mvo> zyga: 3262 has a conflict
<mvo> zyga: looks good otherwise I think
<zyga> mvo: I'll take care of that, thank you
<mvo> ta
<mup> PR core-build#12 closed: sync missing deb upload into branch <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/12>
<ogra_> mvo, thx!
<sborovkov> Hi. My snap build started failing recently. Because dbus-python can't be compiled... Anyone encountered such issue? dbus/dbus-arch-deps.h: No such file or directory. It's present though - /build/snaps/full/parts/playlist/install/usr/lib/arm-linux-gnueabihf/dbus-1.0/include/dbus/dbus-arch-deps.h
<ogra_> sborovkov, do you have libdbus-1-dev in build-packages ?
<sborovkov> ogra_: in stage-packages
<sborovkov> is that incorrect
<ogra_> try build-packages ...
<sborovkov> thanks!
<abeato> ogra_, is there any good description around of what UC does on first boot? Is there any special service that is run?
<ogra_> abeato, well, the stuff happening before console-conf runs is probably only documented in the snapd source ... pedronis and mvo know the process in and out though ... then there is console-conf .... mwhudson is the specialist here
<abeato> ogra_, ok
 * abeato waiting for some more info from pinged guys ;)
<zyga> abeato: yes it does special stuff
<zyga> abeato: it installs all the pre-seeded snaps
<zyga> abeato: and runs the device-prepare hook
<sborovkov> ogra_: that helped, thanks!
<ogra_> :)
<ali1234> if i put snapcraft.yaml in the root of a repo, and it is a symlink to the real location, will it be dereferenced before running it? eg if it does things like "source ."?
<abeato> zyga, where is that done? from a systemd unit?
<zyga> abeato: internally by snapd
<pedronis> abeato: it's all doen from inside snapd
<pedronis> there are no special units anymore
<ogra_> we should have some blog post or a doc for it one day ;)
<abeato> zyga, pedronis got it, thanks
<pedronis> abeato: notice thought that one of the things we discussed recently is to reintroduce some way to know seeding has happened at the systemd level
<ogra_> a little step by step overview would be nice
<pedronis> ogra_: yea, mvo or me should do at least a doc forum post on this
<abeato> ogra_, +1
<ogra_> +1
<zyga> fg
 * ogra_ backgrounds zyga again
<fgimenez> zyga: no luck reproducing the openvswitch test error in isolation so far, will try the full suite next
<zyga> fgimenez: perhaps get it to run with the same seed
<zyga> fgimenez: as it failed in the PR
<zyga> fgimenez: and thank you for checking!
<fgimenez> zyga: indeed, i didn't save it though, do you happen to have it?
<fgimenez> zyga: np :)
<zyga> fgimenez: ah, I think not
<fgimenez> zyga: no problem, i'll execute with -reuse in a loop
<mup> PR snapd#3290 opened: add support for `snap install foo --channel=3.4` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3290>
<zyga> thanks
<mvo> fgimenez: could you please double check if 1689332 also happens with ubuntu-core from stable?
<Chipaca> mvo: niemeyer: dunno if you decoded my blathering earlier about cking having found a fix for bug #1672819
<mup> Bug #1672819: exec'ing a setuid binary from a threaded program sometimes fails to setuid <amd64> <apport-bug> <kernel-da-key> <xenial> <Linux:Unknown> <linux (Ubuntu):Triaged> <linux (Ubuntu Xenial):Incomplete by colin-king> <https://launchpad.net/bugs/1672819>
<Chipaca> was going to mention it in the standup and forgot
<Chipaca> with that, and mwhudson having backported go 1.8's fix for the EAGAIN from pthread_create, we should have no more issues with exec
<fgimenez> mvo: sure, on it, iirc snap and snapd weren't from the snap (2.25 was reported in snap version), will let you know how it goes
<rharper> ogra_: mvo \o/
<fgimenez> mvo: yes, all works fine with ubuntu-core from stable http://paste.ubuntu.com/24549041/
<mvo> fgimenez: thank you!
<ogra_> niemeyer, https://forum.snapcraft.io/t/allow-handling-of-certain-system-services-on-ubuntucore-images/531
<zyga> who wants to take https://github.com/snapcore/snapd/pull/3291
<mup> PR snapd#3291 opened: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3291>
 * zyga goes to get some water and will garden PRs 
<Chipaca> niemeyer: fyi go's ProxyFromEnvironment docs say the HTTP_PROXY and http_proxy are both checked (and the code confirms this)
<Chipaca> not wanting to describe your trousers as aflame, but there's that
<mvo> fgimenez: where is that test that was used to find bug 1689332 ?
<mup> Bug #1689332: internal error with any command using ubuntu-core snap on classic <snapd:In Progress by zyga> <https://launchpad.net/bugs/1689332>
<mvo> ogra_: can you please stop auto-building ubuntu-core for now?
<ogra_> mvo, ok
<zyga> pstolowski: maybe you? :)
<ogra_> mvo, done (cronjob on lillipilly disabled)
<mvo> ta
<pstolowski> zyga, sure, will take a look
<fgimenez> mvo: https://github.com/fgimenez/validator/blob/master/tests/tasks/validate-ubuntu-core-snap/task.yaml i've started adding there tasks that i needed to do manually before, and them wire it with spread-cron
<fgimenez> mvo: in this case it is very similar to the transition tests in snapd's suite, but refreshing ubuntu-core to the channel with the new rev
<mvo> fgimenez: I think we will just need to tweak like this: https://github.com/snapcore/snapd/pull/3289/commits/cecad5139c5867a03ae50607a46f1d5b35058b83
<mup> PR snapd#3289: daemon: do not allow to install ubuntu-core anymore <Created by mvo5> <https://github.com/snapcore/snapd/pull/3289>
<mvo> fgimenez: I can have a look in  a tiny bit and then the test can continue to run as is. I will set all channels of ubuntu-core to the current stable release
<mvo> fgimenez: i.e. we need a test that ensures the current ubuntu-core transitions correctly to core which I think this validation test is doing(?)
<fgimenez> mvo: great, thank you! :) i'll give it a try
<fgimenez> mvo: yes, the test is triggered when a new ubuntu-core is detected, does some validations that we don't have in snapd's transition test (rev number, snapd version) and then the same transition checks
<zyga> Chipaca: maybe you can look at https://github.com/snapcore/snapd/pull/3291
<mup> PR snapd#3291: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3291>
<zyga> Chipaca: if I can land this quickly I'll fixup the other PRs instead of constantly updating this one :)
<zyga> Chipaca: (other meaning remaining branches that add new interfaces)
<mup> PR snapcraft#1271 closed: tests: increase the staging registration limit to 100 <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1271>
<Chipaca> zyga: 's good
<zyga> Chipaca: btw, I didn't know that go sorts init() invocation order internally, I was pleasantly surprised. I added the sorting anyway to sort on interface name rather than file name but I think the result is the same
<Chipaca> zyga: any sorting beyond dependency analysis is probably circumstantial
<mup> PR core#21 closed: allow disabling of timesyncd and syslog (LP: #1504657, LP: #1587453) <Created by ogra1> <Closed by niemeyer> <https://github.com/snapcore/core/pull/21>
<mup> Bug #1674794 changed: journald.conf storage=volatile config support <Snappy:Invalid> <https://launchpad.net/bugs/1674794>
<fgimenez> mvo: works great, thanks a lot! :)
<mvo> fgimenez: \o/
<mvo> fgimenez: could we also run this test as part of spread cron when a new "core" is released? i.e. we will freeze ubuntu-core but we will still want to ensure that ubuntu-core->core works for each new core
<fgimenez> mvo: sure sounds great, i'll prepare spread-cron branches to make it happen
<mvo> fgimenez: thanks \o/
<mvo> fgimenez: I updated edge for ubuntu-core, could you please run the test again to see if things are happy now?
<juanrubio> Hi guys, wrt tizonia's snap pulseaudio issue that we discussed yesterday, I've noticed that pulseaudio is not accessible in 16.04 when my snap is installed without the --devmode flag...
<zyga> juanrubio: do you get any apparmor denials (tip: dmesg | grep DENIED)
<juanrubio> zyga: yes, I'm getting that
<zyga> juanrubio: can you please share them
<juanrubio> zyga: in Fedora 25, this work always (with or without --devmode)
<zyga> juanrubio: in fedora 25 confinement is disabled
<juanrubio> zyga: I see.
<juanrubio> https://github.com/tizonia/tizonia-openmax-il/blob/master/tools/snapcraft.yaml
<juanrubio> zyga: the snap link is coming
<Chipaca> confinement is *currently* disabled
<Chipaca> in the fullness of time that will not be the case
<zyga> juanrubio: I'd rather see the list of denials on 16.04 than the snap
<juanrubio> zyga: denials -> https://gist.github.com/juanrubio/d8752890ac6780d3627d9a1eae048de9
<zyga> juanrubio: quick comment, what did you hope to achieve with this declaration? https://github.com/tizonia/tizonia-openmax-il/blob/master/tools/snapcraft.yaml#L21
<zyga> juanrubio: (it is wrong)
<zyga> morphis: [ 1832.541645] audit: type=1400 audit(1494426806.130:76): apparmor="DENIED" operation="connect" profile="snap.tizonia.tizonia" pid=7495 comm="audio_renderer" family="unix" sock_type="stream" protocol=0 requested_mask="send receive connect" denied_mask="send connect" addr=none peer_addr="@/tmp/.X11-unix/X0" peer="unconfined"
<zyga> morphis: does X11 use abstract sockets too?
<pstolowski> niemeyer, i've read again all the comments you made to the old PR for snapctl-outside-of-hooks PR; I agree with almost all suggestions, but one is disputable/problematic; do you have a moment do discuss in the HO?
 * ogra_ has a dejavu ... 
<ogra_> zyga, the player uses mpris and dbus-x11
<ogra_> we discussed that yesterday
<zyga> juanrubio: the dbus plug/slot need an attribute, instead of saying: `plugs: [foo]' alone you need to say plugs: [my-happy-plug] and then in another section say plugs:\n  my-happy-plug:\n    interface: dbus\n    key: value... (with appropriate attributes)
<ogra_> it will at least need the x11 interface (and ofr mpris even the unity7 one since i think no other interface provides mpris currently)
<juanrubio> zyga: dbus? - tizonia uses a resource manager daemon, but that fuctionality is disabled right now
<ogra_> s/ofr/for/
<zyga> juanrubio: in any case, the dbus plug definition is wrong
<ogra_> juanrubio, y<ou have dbus-x11 in your snapcraft.yaml
<ogra_> (at least you did yesterday when i looked :) )
<zyga> juanrubio: you need to add an entry as I said, with bus: and name: keys
 * zyga gets back to coding
<zyga> mvo: maybe you can do a 2nd review on https://github.com/snapcore/snapd/pull/3291
<mup> PR snapd#3291: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3291>
 * zyga wants to land that before it conflicts
<Chipaca> mvo: it's long, but mechanical
<zyga> Chipaca: it shows that github stops parsing/colorizing code at some point :)
<juanrubio> zyga,ogra_: the dbus stuff in my yaml is still work in progress. It will most likely be removed since I'm not planning to enable that feature in snap installations
<Chipaca> zyga: not here
<Chipaca> zyga: suspect it might be your browser giving up in disgust
<mup> PR snapd#2929 closed: interfaces/builtin: add storage-framework-service interface <Created by michihenning> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2929>
<lutostag> Can other's not upload new snaps to the store? I'm hitting Oops! There was an unrecoverable error, please try uploading your file again. (Sentry id: 2232db8e490a485b87961d3c3c9b08f8)
<lutostag> and snapcraft push fails with a similar but different error...
<zyga> mvo: replied to your questions, thank you for reading that monster :)
<zyga> mvo: either merge all the interfaces or refrain from doing so, so that 3291 won't conflict
<zyga> mvo: I'm happy with either :)
<mvo> zyga: hm, 2869 looks like an easy win too
<zyga> mvo: get them all in then
<ogra_> mvo, http://paste.ubuntu.com/24549394/  (in conclusion with https://forum.snapcraft.io/t/allow-disabling-system-services-on-ubuntu-core/531/12 )
<mvo> zyga: it now conflicts though and 2941 too
<zyga> mvo: I'll do all de-conflicting on the other side
<zyga> mvo: hehe
<zyga> mvo: all those conflicts is why I made the 3291 in the first place :)
<zyga> mvo: no worries, just give me +1 to merge and I'll resolve the rest
<mvo> ogra_: oh, I guess I will need to read that
<juanrubio> zyga: do we know what's the issue with the apparmor denials?
<mvo> ogra_: slightly concerned about backward compat and remote logging and all that. and funny since I was against rsyslog a long time ago in the default. oh well
<zyga> juanrubio: no, I don't know
<zyga> juanrubio: I didn't dig deeply though
<ogra_> mvo, well, niemeyer suggests in the discussion that we can ship rsyslog as a snap for remote logging ... all other bits seem to be moot
<ogra_> seems sensible to me ...
<ogra_> not sure where backward compat would be an issue
<rharper> mvo: when and where would I look for new core snap with those PR's landed ?
<ogra_> rharper, in edge ... but it didnt land yet
<juanrubio> zyga: thanks. Do you feel a bug should be filed for this?
<ogra_> rharper, the ubuntu-core-config deb still needs to land in the PPA (i'm working on this atm) ... once thats there i'll trigger a new core
<zyga> juanrubio: no, not immediately, please open a forum topic, use the snap category
<rharper> ogra_: ok, thanks
<mvo> zyga: hm, hm, I guess your sequence (3291, then the other interface code) would have been more efficient, each interface branch that lands conflicts right now
<juanrubio> zyga: ok, i'll do that
<zyga> mvo: no worries :)
<mvo> zyga: sorry for that!
<mvo> zyga: its just two interface branches left, right? so not toooooo terrible
<zyga> mvo: I'm just happy to land this eventually so that other people have less headache :)
<zyga> mvo: yep
<zyga> mvo: plus several waves of cleanups I'm working on
<zyga> lots of silly stuff that's crufily copy-pasted around
<pstolowski> zyga, ah, 3291 has conflicts now
<zyga> yeah, I'll resolve them after finishing one more branch
<morphis> zyga: looks like
<morphis> zyga: need to explore a bit what the X abstraction allows today
 * zyga nods
<mup> PR snapd#3119 closed: interfaces: API additions for interface hooks <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3119>
 * zyga looks at https://github.com/snapcore/snapd/pull/3291 and cries a little
<mup> PR snapd#3291: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3291>
<zyga> well :D
<juanrubio> zyga,morphis: I've replied to the same pulseaudio thread I created yesterday -> https://forum.snapcraft.io/t/pulseaudio-access-denied-accessing-pulseaudio-for-audio-playback-in-fedora-25-and-ubuntu-16-04/519?u=juanrubio
<zyga> juanrubio: thanks
<morphis> juanrubio: thanks!
<cachio> Chipaca, hey, I need to add the proxy to a ubuntu core instance to run spread tests
<Chipaca> cachio: hey
<Chipaca> cachio: I think the fix to make /etc/environment writable in core isn't ready yet
<Chipaca> cachio: but if it's just for testing, it's easy to work around
<cachio> Chipaca, yes, I need to run the spread tests on that machine
<Chipaca> cachio: pop a file anywhere (e.g. /root/, or /var), and then mount --bind /the/file /etc/environment
<Chipaca> cachio: (it's also very easy to make this fix permanent, if it were something that needed to work longer term)
<Chipaca> just a matter of doing the above (possibly with the file in under /etc/writable to make it less hackish) and then write an appropriate .mount file and drop it in /etc/systemd/system
<cachio> Chipaca, ok
<cachio> Chipaca, do you know if the snap client will support proxy?
<Chipaca> cachio: there's some tricky details for the second half; give me a shout if you need it
<Chipaca> cachio: yes, in the same way as snapd
<Chipaca> (set HTTPS_PROXY or https_proxy or HTTP_PROXY or http_proxy in the environment)
<Chipaca> usually your login shell sources /etc/environment also, so you should be set
<cachio> Chipaca, since when?
<Chipaca> cachio: since when what?
<cachio> Chipaca, is it already upported? or will be supported?
<zyga> hmm hmm hmm
<zyga> I think pawel's branch had a bug
<Chipaca> cachio: already
<Chipaca> cachio: super easy to confirm, also: http_proxy=potato snap download what
<Chipaca> <snap vomits>
<zyga> aww
<zyga> yes it does
<zyga> pawel, you didn't listen to me :/
<zyga> master is broken
<cachio> Chipaca, ok, I'll try that too, tx
<Chipaca> zyga: psh, who needs master
<mup> PR snapd#3292 opened: wrappers: make StartSnapServices cleanup any services that were added if a later one fails <Created by chipaca> <https://github.com/snapcore/snapd/pull/3292>
<morphis> Pharaoh_Atem: any reason why you dropped those lines https://github.com/snapcore/snapd/blob/master/packaging/ubuntu-14.04/snapd.postrm#L86 from the snapd-mgmt.sh script?
<Chipaca> zyga: so how do we fix?
<zyga> master is fixed with https://github.com/snapcore/snapd/pull/3291
<mup> PR snapd#3291: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3291>
<zyga> I'll add the missing tests pawel didn't add
<zyga> ok, tests written
<zyga> Chipaca: I'm going to EOD now, can you merge https://github.com/snapcore/snapd/pull/3291 once green
<mup> PR snapd#3291: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3291>
<zyga> Chipaca: I pushed the missing test as well
<Chipaca> zyga: yes
<niemeyer> zyga: Which PRs were blocking you?
<zyga> niemeyer: I'd like to land https://github.com/snapcore/snapd/pull/3225 and iterate on integration, testing and perhaps discard the change.IsNeeded code
<mup> PR snapd#3225: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3225>
<zyga> I'll probably come back later tonight to de-conflict remaining interface PRs
<niemeyer> zyga: Looking, and thanks
<zyga> thanks, and see you tomorrow!
<niemeyer> zyga: Feedback provided
<niemeyer> zyga: Some of the points still seem open
<morphis> niemeyer: do you have time to look at those PRs https://github.com/snapcore/snapd/pulls/morphis except the snapd --user one today?
<niemeyer> morphis: I'm keen on sorting these out first, and would appreciate help doing that: https://forum.snapcraft.io/t/review-sprint-1/377
<morphis> I can see what I can do tomorrow
<niemeyer> morphis: Anything in there is open for more than two weeks
<niemeyer> morphis: Thanks!
<morphis> niemeyer: https://github.com/snapcore/snapd/pull/3222 being one of them
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<niemeyer> morphis: Looking right now
<morphis> thanks!
<mup> PR snapcraft#1305 opened: Use architectures field which existed in older LXD <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1305>
<ogra_> rharper, a new core is building, should be ready within the next 30-45min
<ogra_> (including your changes)
<rharper> ogra_: thanks!
<zyga> jdstrand: ouch https://lwn.net/Articles/722363/
<jdstrand> zyga: yeah
<jdstrand> the kerenls should be all fixed already though
<jdstrand> kernels even
<zyga> jdstrand: except for core pi2/3
<nanday> I'm doing an article about packages for The New Source. Anybody involved with the design of snap packages who has the time to reply to some basic questions?
<nanday> Alternatively, does anyone have any suggestions about who I might talk to?
<zyga> nanday: hey
<zyga> nanday: you may want to talk to niemeyer
<zyga> nanday: but I can also answer some questions if you post them
<jdstrand> zyga: well, yes, which is the lack of updates is something I keep bringing up. hopefully that was resolved at the sprint?
<zyga> jdstrand: I think it was discussed but we need to work on the implementation
<zyga> jdstrand: I think the design was resolved
<jdstrand> that's good news
<zyga> jdstrand: I made some improvements to interface code, there should be less conflicts now
<zyga> jdstrand: I have some more cleanups piled up, nothing semantic, just lots of cruft in tests and copy-paste badness
<jdstrand> zyga: fewer conflicts? what do you mean?
<zyga> jdstrand: adding a new interface will no longer change many files
<jdstrand> oh with PRs?
<zyga> jdstrand: well, less many :-)
<zyga> jdstrand: yes
<zyga> https://github.com/snapcore/snapd/pull/3291/files
<mup> PR snapd#3291: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3291>
<jdstrand> I see. that'll be nice
<ChipAway> zyga: the tests on snapd#3291 have only just started running (~10 mins ago)
<zyga> jdstrand: also merging a PR will now test if it's using any of the old APIs
<zyga> Chipaca: yeah, I restarted them
<Chipaca> oh
<zyga> Chipaca: we ran out of machines
<Chipaca> when i left for dinner it hadn't started yet
<zyga> Chipaca: gustavo added more to the pool so I'm hoping this one will pass
<zyga> Chipaca: yes, it ran but timed out after 49 minutes
<jdstrand> zyga: oh, that's cool
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/3291/commits/f1faec05b48d70f0ebf4a45e48226cbc9278c21b :-)
<mup> PR snapd#3291: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3291>
<Pharaoh_Atem> morphis: I dropped them because rpm will remove it
<Pharaoh_Atem> the directory is owned by the package, and if all contents are already gone, rpm will get rid of the directory
<jdstrand> huh, neat
<mup> PR snapd#3293 opened: spread.yaml: increase linode workers by 50% <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3293>
<cachio> Chipaca, did you see what I wrote? I lost connection
<cachio> do you have an example of that .mount?
<mup> PR snapd#3294 opened: interfaces: fix broken master after merging the storage_framework_services branch <Created by mvo5> <https://github.com/snapcore/snapd/pull/3294>
<Chipaca> cachio: I did not see what you wrote
<Chipaca> cachio: I do have an example of that mount
<Chipaca> cachio: do you have the snapd tree?
<Chipaca> if so it's super easy to show you :-)
<Chipaca> otherwise i'll pastebin
<cachio> pastbin please
<mup> PR snapd#3291 closed: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3291>
<cachio> Chipaca, I wrote that spread tests are rebooting the target machine and it is making the mount unusable
<Chipaca> cachio: http://pastebin.ubuntu.com/24550581/
<Chipaca> cachio: that's a bind mount .mount unit
<Chipaca> cachio: basically What=<the rw file>, Where=/etc/environment
<Chipaca> for you
<Chipaca> the rest remains the same (but edit the description :-) )
<Chipaca> cachio: and, the tricky bit is
<Chipaca> cachio: it *needs* to be called etc-environment.mount
<cachio> Chipaca, great, and just I need to leave it in /etc/systemd/system ?
<cachio> nad restart snapd?
<Chipaca> drop it in /etc/systemd/system/etc-environment.mount
<Chipaca> then enable it (systemctl enable etc-environment.mount)
<Chipaca> then start it (systemctl start ...)
<Chipaca> then confirm it worked
<Chipaca> then restart snapd :-)
<cachio> Chipaca, great, I'll try now
<cachio> Chipaca, tx
<Chipaca> cachio: man systemd.mount if you want to learn the how and the why
<cachio> Chipaca,  :) sure
<Chipaca> zyga: src/github.com/snapcore/snapd/interfaces/builtin/storage_framework_service_test.go:87: not enough arguments in call to spec.AddConnectedSlot <- wat
<morphis> Pharaoh_Atem: hm, then that works differently on suse
<morphis> I don't see /var/lib/snapd removed
<mup> PR snapcraft#1301 closed: recording: record global build-packages installed on the host <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1301>
<mup> PR snapcraft#1306 opened: recording: record global build-packages installed on the host <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1306>
 * Chipaca looks for the big red STOP THE LINE button
<rharper> ogra_: testing the edge image;  what's the best way to ask if the system booted is a ubuntu-core  system? cloud-init had used either 'channel.ini'  or 'config.d' in /etc/system-image to check; but the current core snap only has 'writable-paths' present;  That'll need fixing in cloud-init and I'd like to find something stable
<Chipaca> rharper: "snap version" output should be enough to know
<Chipaca> (if not, we should improve it :) )
<rharper> ok, we run early in boot, would snap version run ?
<Chipaca> rharper: if you're in early bring up and not yet at the stage of having snapd running, /etc/os-release might help
<rharper> ok
<Chipaca> or early boot yeah
<Chipaca> dunno if etc/os-release is there in early boot; it's in the root filesystem
<rharper> it will
<Chipaca> k
<rharper> cloud-init runs after localfs is mounted (one of the stages)
<Chipaca> ah ok
<rharper> that looks solid, ID=ubuntu-core is similar to the match we did in channel.ini
<Chipaca> rharper: another way is to check whether the root fs is a squashfs :-)
<rharper> well, we boot root squashfs in  maas ephemeral, os-release looks good though
<rharper> thanks for the suggestion
<mup> PR snapcraft#1307 opened: cli: new UI and internal refactor <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1307>
<rharper> Chipaca: for snap version:  the only difference I can tell between classic and core is that in classic, snap version includes 'ubuntu  16.04'  where as my core image does not include the ubuntu line;  both say series 16 .
<rharper> not sure if it it's worth saying classic vs. core or something like;   cloud-init has to do somethings differently (like using extrausers database in core)  vs. in classic
<Chipaca> yeah, maybe we should include the flags as we do in the user-agent string
<mup> PR snapcraft#1308 opened: allow capital Y to accept the dev agreement <Created by felicianotech> <https://github.com/snapcore/snapcraft/pull/1308>
<mup> PR snapd#3294 closed: interfaces: fix broken master after merging the storage_framework_services branch <Created by mvo5> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3294>
<newbsie> I'm having some problem login into my Raspberry Pi after first time setup with Ubuntu Core. Putty keeps responding with key is denied. Anyone know what to do?
<zyga> newbsie: is your putty key added to your launchpad account?
<newbsie> zyga: yes.
<zyga> newbsie: note that putty and ssh on linux/macos don't use the same key format
<newbsie> zyga: I'm trying to get ssh working on Linux subsystem for Windows 10, but don't know where to put the private key file. Trying to locate the .ssh dir.
<zyga> newbsie: aha
<zyga> newbsie: so are you using putty or ssh on windows+ubuntu
<newbsie> zyga: I was using putty, but since it didn't work, I'm trying ssh on windows+ubuntu.
<zyga> newbsie: so is your windows+ubuntu ssh key on launchpad?
<zyga> newbsie: it is in ~/.ssh/id_rsa.pub by default
<newbsie> zyga: It's the same key as on putty, but I exported the private key to ssh format.
<zyga> newbsie: the id_rsa is the private key
<zyga> newbsie: id_rsa.pub is the public key
<zyga> newbsie: public key is short, the private key is a longer block of stuff that begins with -----BEGIN RSA PRIVATE KEY-----
<newbsie> zyga: The key is generated in puttygen. For the public key, I did ssh-rsa <long hex string> and put it into launchpad.
<newbsie> zyga: for the private key, it is in ppk format, and then I export it to openssh format
<newbsie> zyga: but it is not working. Maybe I should start from scratch and use openssh to generate the keys.
<zyga> newbsie: not sure, it's too late for me :)
<zyga> newbsie: you can always yank the card from pi
<zyga> newbsie: put it into your laptop
<zyga> newbsie: and look at what is in the .ssh/authorized_keys
<newbsie> zyga: how do I tell ssh to use a private key?
<zyga> newbsie: man ssh has all the secrets, I believe it is the -i option
<zyga> newbsie: (and I assume you meant to ask "which key to use", it always uses private keys
<newbsie> zyga: this whole SSO is frustrating
<Chipaca> newbsie: ssh is very picky about permissions
<Chipaca> newbsie: if you add the -v option it will print a lot of info about what's going on
<Chipaca> newbsie: if you want you could pastebin that, maybe it'll help us help you
<Chipaca> otoh, putty _should_ work but i don't have a way to try it
<zyga> Chipaca: oh, good idea
<Chipaca> oh wait, there's a putty for ubuntu
<zyga> newbsie: on windows+ubuntu files is often 777 by default
<Chipaca> wonder if it's the same
<zyga> chmod -og= -R .ssh
<newbsie> Chipaca: ssh complaining about file permission is to open.
<zyga> newbsie: yep
<zyga> do the chmod
<Chipaca> newbsie: that thing with the chmod zyga suggested is not him having a fit, he was trying to tell you to run that :-)
<newbsie> it's saying there is no -og= mode
<zyga> hmm
<zyga> my bad
<Chipaca> og-r, i think?
<zyga> chmod -R og= ~/.ssh/
<Chipaca> ah
<zyga> ^ tested
 * Chipaca looks up =
<zyga> Chipaca: assign
<zyga> Chipaca: I fixed master and all the open branches that touch interfaces
<Chipaca> assign nothing, ie clear
<Chipaca> gotcha
<Chipaca> zyga: i saw my branch magically fix itself
<Chipaca> zyga: thanks :-)
<zyga> Chipaca: with the extra workers we can now run several tests in parallel
<zyga> Chipaca: I have one more branch if you want to read :)
<newbsie> So I do the following: ssh -i private_key.pub <username>@192.168.1.9 -v
<zyga> Chipaca: makes all of interface implementation private
<zyga> Chipaca: and exposes only one function, interfaces.Interfaces()
<zyga> Chipaca: doing that makes goling happy and found a few ugly things in tests
<newbsie> But then get an error, unable to open file. Permission denied.
<Chipaca> newbsie: which file?
<Chipaca> zyga: sure, shoot
<zyga> Chipaca: one sec, just need to rebase it
<zyga> Chipaca: it's another monster-ish branch
<zyga> Chipaca: :D
<newbsie> Chipaca: private_key.pub
<newbsie> which is the private key. I think it is misnamed.
<zyga> with a space?
<newbsie> zyga: It's underscore
<Chipaca> newbsie: permission denied might mean exactly that
<Chipaca> newbsie: what does "ls -l private_key.pub" say?
 * zyga looks at http://paste.ubuntu.com/24551684/
<zyga> and cries a little :D
<newbsie> Chipaca: only owner has read, everything else is disabled.
<Chipaca> newbsie: and the owner is the user you're trying to ssh as?
<Chipaca> newbsie: in other words
<Chipaca> easy way to check
<Chipaca> if you enter "cat private_key.pub"
<Chipaca> do you see the contents of the file
<zyga> (just don't paste them)
<newbsie> Chipaca: No. That's odd.
<newbsie> Chipaca: I created the file as the current user, and it has my username
<Chipaca> newbsie: what does âidâ say?
<Chipaca> that is, does âidâ agree that you are you
<newbsie> Chipaca: Yes
<zyga> newbsie: quick question
<zyga> newbsie: how did you create it
<zyga> newbsie: did you created it from windows?
<zyga> newbsie: or from windows+ubuntu?
<newbsie> zyga: nano private_key.pub
<zyga> newbsie: ok
<newbsie> zyga: from within windows+ubuntu
<zyga> Chipaca: if you don't know you cannot ever touch anything from windows that is in windows+ubuntu or it explodes in magic ways
<Chipaca> zyga: I thought they'd fixed that with the latest patch
<Chipaca> the ... anniversary edition, or something
<newbsie> So, I can't change it to chmod a+r, because ssh complains, but if I change it to chmod o+r, then I cannot read it.
<zyga> Chipaca: not that I know
<zyga> fo
<zyga> of
<Chipaca> Â¬_Â¬
<zyga> newbsie: wait
<zyga> newbsie: not o
<zyga> newbsie: o is 'oter'
<zyga> other
<zyga> newbsie: you want 'u'
<zyga> newbsie: chmod og=,u=rwX
<Chipaca> yeah, don't let otters read your keys
<zyga> chmod that recursively on .ssh
<Chipaca> hands up if you think it should've worked from putty
<Chipaca> o/
<zyga> \o
 * zyga is left handed
<Chipaca> newbsie: i think we asked you this before, but, the key you uploaded to launchpad, was it in the format openssh expects?
<newbsie> It should have worked from putty and would have saved me a lot of trouble. There should be an official guide on Ubuntu Core website. They only did one for Ubuntu.
<Chipaca> (is it to launchpad you upload your ssh keys, still)
<mercurio56> help
<Chipaca> newbsie: they == us :-)
<Chipaca> mercurio56: wat
<newbsie> Chipaca: I believe so. That's the same format I used to configure Ubuntu Server i.e. ssh-rsa <long hex string>
<newbsie> The problem is private key is missing begin marker.
<Chipaca> newbsie: progress!
<newbsie> Chipaca & zyga: I appreciate the help so far!
<Chipaca> newbsie: so
<Chipaca> newbsie: silly question
<Chipaca> newbsie: is there a reason you can't generate a whole new key pair direclty with openssh?
<Chipaca> newbsie: that's "ssh-keygen"
<newbsie> Chipaca: no, there is no reason. Probably save me more time than doing this. It's just that I have one keyboard and the stupid thing requires first time signup to have physical access. Completely bonkers that it has so many barriers.
<zyga> newbsie: otherwise it'd be totally insecure
<zyga> newbsie: how would you log in? ubuntu/ubuntu?
<newbsie> zyga: yes, and change the password.
<Chipaca> newbsie: yeah, no, that's how the IoT botnets exist
<zyga> newbsie: what about 99% of the people who will never do that?
<newbsie> zyga: better yet, have a script to run and do whatever it needs to do
<Chipaca> anyhow, you are right in that we should make a guide for windows
<Chipaca> i wonder who has windows that could write a guide for this
<newbsie> I'm just frustrated since I spent so much time, and I'm not completely new to Ubuntu.
<newbsie> Just rusty.
<Chipaca> newbsie: if you could channel this frustration into a forum topic about this, it'll help other people pick it up and fix it
<Chipaca> newbsie: otherwise I'll do it
<zyga> newbsie: yes! you can help everyone!
<newbsie> I will definitely do that.
<Chipaca> excellent :-)
<Chipaca> also, try not to swear too much :-p
<newbsie> My wise fiance says, swearing is for those that cannot express themselves.
<newbsie> So I try to learn to express myself.
<zyga> Chipaca: almost done
<newbsie> Anyhow, I appreciate not being told to RTFM or that you suck during my outburst of frustration.
<Chipaca> i tell my boys that they have this awesome vocabulary, and it's a shame to waste it and go the lazy route of just swearing
<Chipaca> I only tell people to RTFM when I know they wrote the M in the first place :-)
 * Chipaca just realized that "write the fine manual" has a very apropos initialism
<Chipaca> zyga: huzzah
<newbsie> Chipaca: lol
<newbsie> Chipaca: How do the people that wrote the manual take it? :)
<Chipaca> they know me, so they take it well
<Chipaca> zyga: we should package putty as a snap
<zyga> Chipaca: for... ? nostalgia?
<Chipaca> zyga: to watch the world burn?
<Chipaca> zyga: i think it's just that it's 1am and my brain is easily amused
<zyga> Chipaca: ok, here it comes
<Chipaca> zyga: also, it's 2am for you (again)
<zyga> https://github.com/snapcore/snapd/pull/3295
<mup> PR snapd#3295: interfaces/builtin: make all interfaces private <Created by zyga> <https://github.com/snapcore/snapd/pull/3295>
<zyga> more red than green :D
<mup> PR snapd#3295 opened: interfaces/builtin: make all interfaces private <Created by zyga> <https://github.com/snapcore/snapd/pull/3295>
<newbsie> is the username@host after the ssh-rsa <key> needed?
<zyga> ah, wait, new interfaces are public
<Chipaca> newbsie: it's the key name or something like that
<Chipaca> newbsie: i've always copied it
<Chipaca> not sure if it's needed
<Chipaca> zyga: does that mean i should hold off reviewing?
<zyga> Chipaca: pushed again
<zyga> just one interface
<zyga> Chipaca: go ahead now
<Chipaca> youch
<Chipaca> +831 â1,165
<zyga> hahaha
<zyga> yes
<zyga> but the fact that interfaces are private now makes test easier to verify
<zyga> they can only observe what is public, and they must ask for an interface, by name, from the registry
<zyga> Chipaca: honestly I don't expect you to really review this today :)
<Chipaca> yeah, i'd not trust it to fit in my brain at this time
<Chipaca> if it were more mechanical, sure
<Chipaca> but it's not
<zyga> it's very boring
<zyga> there are a few interesting spikes
<zyga> but it is for tomorrow
<zyga> I think spread will be busy for now
<zyga> I'll just merge master into broken branches
<Chipaca> newbsie: i'm checking out, but i don't want to leave you hanging
<Chipaca> newbsie: so, um, i'll stay logged in here until i'm back from brushing my teeth?
<Chipaca> shout if you need me :-)
<Chipaca> (otherwise i'll assume everything worked and you're off to the races)
#snappy 2017-05-11
<newbsie> Chipaca: I have to reimage the Pi, and then I can try to relogin with the new key's. I appreciate your help, and especially not leaving me hanging.
<Chipaca> newbsie: how long does reimaging take?
<zyga> ok
<zyga> I think I'm done for tonight
<newbsie> Just done, the big moment
<zyga> Chipaca: can you look at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-image/zesty/amd64/s/snapd/20170511_000322_edb35@/log.gz
<zyga> ... Panic: sync: unlock of unlocked mutex (PC=0x45BDAC)
<zyga> this looks rather bad
<newbsie> zyga
<newbsie> zyga: sorry, what is known_hosts?
<zyga> yes?
<zyga> newbsie: it's a file where ssh remembers the hosts it saw and their keys
<Chipaca> zyga: that one's for pedronis :-)
<zyga> Chipaca: also here https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/i386/s/snapd/20170511_000455_63ba2@/log.gz
<newbsie> I'm now getting "Host key verification failed"
<newbsie> Yes, yes, yes!
<zyga> newbsie: becausethey ip you are sshing had changed identity
<Chipaca> newbsie: you reimaged, so the host key changed
<newbsie> It's working now.
<Chipaca> newbsie: wooo
<newbsie> That only took a day, but the more you put in, the more you feel like you accomplished, although I stood on the shoulder of zyga and Chipaca. XD
<Chipaca> *that's* why i'm so sore!
<zyga> we ran out of machines
<Chipaca> newbsie: let's make it suck less. Looking forward to the forum post.
<newbsie> Chipaca: I'm not that heavy. Although I do like burgers, steak and fatty food in general.
<Chipaca> zyga: la la la can't hear you i'm already asleep
<zyga> Chipaca: yes, good idea
 * zyga afk
<newbsie> zyga: I'm going to log off too, but I really appreciate your help earlier. Will definitely make that post on the snapcraft forum.
<mup> PR snapcraft#1309 opened: meta: read and write the desktop file with utf-8 encoding <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1309>
<mup> PR snapcraft#1310 opened: tests: use C.UTF-8 for the docker locale <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1310>
<mup> PR snapd#3293 closed: spread.yaml: increase linode workers by 50% <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3293>
<mup> PR snapd#2869 closed: interfaces/builtin: add online-accounts-service interface <Created by mardy> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2869>
<morphis> zyga: ping
<morphis> zyga: is https://paste.ubuntu.com/24553247/ expected?
<morphis> that is with 2.25 on suse
<pstolowski> morning
<fgimenez> good morning mvo :) wrt 2.25 SRU and bug #1689332 if we don't promote the ubuntu-core snap shipping 2.25 (2109 for amd64, currently in beta) we are good to go right?
<mup> Bug #1689332: internal error with any command using ubuntu-core snap on classic <snapd:In Progress by zyga> <https://launchpad.net/bugs/1689332>
<fgimenez> hey pstolowski
<mvo> fgimenez: good morning. yes, I think so, we just freeze ubuntu-core from now
<mup> PR snapd#2941 closed: interfaces/builtin: add network-status interface <Created by xavi-garcia-mena> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2941>
<fgimenez> mvo: ok, shall i put a comment in the sru bug and mark it as verification-done? we only found this issue
<mvo> fgimenez: yes, please do, I will revert beta ubuntu-core to stable so this issue will be gone
<fgimenez> mvo: ok thanks!
<mvo> fgimenez: hm, actually it won't be gone :/ we need to land 3289 first
<morphis> mvo: do you know if the message shown with https://paste.ubuntu.com/24553247/ is expected with 2.25? this is on suse so with forced-devmode
<fgimenez> mvo: aha ok, this won't be added to the current 2.25, will it? i mean, do we need to wait until 2.26?
<mup> PR snapd#3296 opened: image: fix go vet issue <Created by mvo5> <https://github.com/snapcore/snapd/pull/3296>
<mvo> morphis: that is something for zyga - but I got feedback on the sprint about this as well, quite a few people see this or a variation of it. iirc we added the message as a measure of debugging this, we always had this issue but silently ignored it.
<mvo> fgimenez: correct, for 2.25 we can do little without quite a bit of extra effort (doing a point release, re-doing the verifications)
<fgimenez> mvo: ack thanks
<mvo> morphis: the message also looks slightly odd, lets wait for zyga
<mvo> 3289 needs a second review fwiw, but I guess its a bit early still
<fgimenez> mvo: still about 2.25, pls correct me if i'm wrong but even if snapd#3289 hasn't landed, if the current ubuntu-core stable is available in all the channels then if snapd still allows installing it it wouldn't break anything? sorry maybe i'm missing something
<mup> PR snapd#3289: daemon: do not allow to install ubuntu-core anymore <Created by mvo5> <https://github.com/snapcore/snapd/pull/3289>
<zyga> morphis: known issue, thank you for reminding me
<zyga> pstolowski: hey, just a reminder, you didn't add the pre-attribute definers to the test
<zyga> pstolowski: I added them already but I thought you would in your attribute branch
<morphis> zyga: actually feels bad to have that, something we can easily fix for 2.25?
<zyga> morphis: yes
<zyga> morphis: the patch will remove two lines
<zyga> I will be back shortly, I worked too late last night
<mvo> fgimenez: lets try :)
<mvo> zyga: if you have a fix in mind, would be great to get it for 2.26
<mvo> zyga: please ping when you are back so that we can talk details
<morphis> zyga: just one last quick question: why do we have all the %dir /var/lib/snapd/.. lines in the spec file for snapd on suse? Isn't it enough to one for /var/lib/snapd and snapd will take care to create all sub dirs when necessary?
<mvo> fgimenez: you are right, things work fine with ubuntu-core from stable it seems
<mvo> fgimenez: so no blocker, all good. thanks for this info!
<pstolowski> zyga, sorry about that, it didn't occur to me
<fgimenez> mvo: np thank you! i've double checked that installing 1797 (current stable) from edge works fine too
<Chipaca> morning all
<zyga> re
<mvo> hey Chipaca, good morning
<fgimenez> mvo: http://paste.ubuntu.com/24553441/ i'll put a comment on the sru bug about this and mark it as verification-done, is that ok?
<fgimenez> hey Chipaca
<zyga> pstolowski: I made a remark in your PR before it was merged, no worries now but we need to be careful, tests will not always show us that stale code is in place
<mvo> Chipaca: maybe interessting for you - shellcheck in zesty gives me the following output  http://paste.ubuntu.com/24553330/
<zyga> mvo: yes, I'll prepare one shortly
<mvo> fgimenez: yes
<Chipaca> oooohhh
<Chipaca> oooooooooohhhh
<Chipaca> oh
<Chipaca> sigh
<Chipaca> read *with* -r misbehaves on 14.04
<mvo> zyga: great, please push it to the top of the todo, its the last blocker for the release (well, not blocker but really nice to have)
<mvo> Chipaca: meh, then we can just turn this warning off :)
<Chipaca> or was that only when combined with a timeout
<Chipaca> mvo: no, this might be the reason for a bug we've got :-)
<mvo> Chipaca: ohhhh
<mvo> Chipaca: interessting
<Chipaca> that's what I said :-)
<mvo> lol
 * mvo hugs Chipaca
 * Chipaca hugs mvo right back
<mvo> zyga: and very excited that you have a fix almost ready, great news :)
<Chipaca> if my memory serves (for once), it only misbehaves when combined with a timeout
<Chipaca> and we don't do that, so this should be good
<Chipaca> I'll give it a try
<Chipaca> mvo: thanks!
<Chipaca> mvo: wrt the last two warnings, I'll add a disably thing
<mvo> pstolowski: wooooh, 3119 landed! great job
<mvo> Chipaca: thank you
<pstolowski> mvo, yeah :}
<mvo> pedronis: and good news for you as well, the new number of machines increased and a PR takes currently 30min for a full test run
<mvo> (down from ~48min)
<zyga> mvo: doing that now
<zyga> mvo: https://github.com/snapcore/snapd/pull/3297
<mup> PR snapd#3297: overlord/ifacestate: don't spam logs with harmless auto-connect messages <Created by zyga> <https://github.com/snapcore/snapd/pull/3297>
<morphis> Son_Goku: did you test if the removal of the snapd package on fedora removes everything from /var/lib/snapd?
<mup> PR snapd#3297 opened: overlord/ifacestate: don't spam logs with harmless auto-connect messages <Created by zyga> <https://github.com/snapcore/snapd/pull/3297>
<mup> PR snapd#3298 opened: interfaces/builtin: ensure we don't register interfaces twice <Created by zyga> <https://github.com/snapcore/snapd/pull/3298>
<Chipaca> mvo: I might be wrong, but I blocked snapd#3290
<mup> PR snapd#3290: add support for `snap install foo --channel=3.4` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3290>
<Chipaca> mvo: just 'cause i'm ornery
<mvo> Chipaca: meh, branches
<zyga> mvo: can you consider https://github.com/snapcore/snapd/pull/3282 as well?
<mup> PR snapd#3282: hooks: default timeout <Created by stolowski> <https://github.com/snapcore/snapd/pull/3282>
<Chipaca> mvo: basically missing a âand !strings.ContainsWotsit(mx.Channel, '/')â
<mvo> Chipaca: I have a look after 2.26, maybe its not so un-ambigious as the doc made me believe
<mvo> Chipaca: aha, ok
<Chipaca> pedronis: did you see those panics? (are you awake? :-) )
<zyga> pedronis: did you see
<zyga> PANIC: snapstate_test.go:4416: snapmgrTestSuite.TestEnsureRefreshesAlreadyRanInThisInterval
<mvo> Chipaca: yeah, that is making sense
<zyga> ... Panic: sync: unlock of unlocked mutex (PC=0x809A45A)
<Chipaca> zyga: HAH! beat you to it
<zyga> mvo: ^^ (I'd also recommend to hold the release until we know what that is)
<mvo> zyga, Chipaca: where are those?
<zyga> mvo: in tests, randomly, very often
<zyga> mvo: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/i386/s/snapd/20170511_000455_63ba2@/log.gz
<zyga> for instance here: https://github.com/snapcore/snapd/pull/3051
<mup> PR snapd#3051: interfaces: add consoles interface <Blocked> <Created by femdom> <https://github.com/snapcore/snapd/pull/3051>
<zyga> Chipaca: did you talk to pedronis already?
<zyga> ah
<zyga> I see :D
<Chipaca> :)
 * zyga is not awake yet
 * Chipaca offers some really nice coffee
<zyga> Chipaca: yes, I should get some
<zyga> Chipaca: after working late I could not sleep
<Chipaca> zyga: happens
<zyga> Chipaca: so I went on reading, then my son woke up because he wasn't feeling well
<zyga> Chipaca: so more stuff at 3AM
 * zyga is in Z state today
<didrocks> (but as we saw with the ubuntu release name, after Z, there A)
<Chipaca> mvo: wrt the channel, i think it's unambiguous wrt lack of /
<mvo> Chipaca: cool
<abeato_> zyga, hey, where can I find a list of what should be enabled in the kernel for UC?
<zyga> mvo: sorry for spamming here but:
<zyga> /usr/lib/go-1.6/src/runtime/panic.go:443
<zyga>   in gopanic
<zyga> /usr/lib/go-1.6/src/math/rand/rand.go:64
<zyga>   in Rand.Int63n
<zyga> /usr/lib/go-1.6/src/math/rand/rand.go:203
<zyga>   in Int63n
<zyga> /tmp/autopkgtest.odhoEa/build.iw1/snapd/_build/src/github.com/snapcore/snapd/timeutil/schedule.go:106
<zyga>   in randDur
<zyga> mvo: does that say that Rand.Int63n panics?
<zyga> abeato_: no idea
<zyga> abeato_: sorry :/
<zyga> abeato_: I don't think anyone maintains a list
<zyga> abeato_: we only have "clues"
<abeato_> zyga, nw, the thing is that I remember having seen some sort of "bits" files that gave some clues
<Chipaca> zyga: DEBUG: host arch (kernel) is '1073741864'
<zyga> Chipaca: yes?
<zyga> Chipaca: that's seccomp's way of describing architectures
<Chipaca> zyga: is that a pointer getting printed as a string?
<zyga> (yuck but expected)
<zyga> no, that's an opaque thing
<Chipaca> yuck
<zyga> yep
<zyga> Chipaca: I think there are some flags inside there too
<zyga> anyway
<zyga> Chipaca: any insight into that trace above?
<zyga> aha
<zyga>     if n <= 0 {
<zyga>         panic("invalid argument to Int63n")
<zyga>     }
<zyga> so rand *can* panic
<zyga> mvo: I think this is the bug:
<abeato_> zyga, of these which should be included? : http://paste.ubuntu.com/24553511/
<zyga> func randDur(dur time.Duration) time.Duration {
<zyga>     return time.Duration(rand.Int63n(int64(dur)))
<zyga> }
<zyga> mvo: you convert this to int64 which is signed
<zyga> abeato_: I really don't know
<Chipaca> zyga: the panics very much say it's about locking something twice
<zyga> Chipaca: locking is another issue (perhaps)
<abeato_> zyga, ok ok :)
<zyga> Chipaca: but this is IMO wrong too
<Chipaca> ah
<Chipaca> sorry
<Chipaca> where's that coffee i talked about
<zyga> mvo: and then this:
<zyga>     when := a.Sub(now) + randDur(b.Add(-5*time.Minute).Sub(a))
<zyga> here we can call randDur with a negative duration
<zyga> when this happens we panic
 * zyga -> coffee
<Chipaca> looks like that needs to be b-a-5m only if b-a>5m
<morphis> Son_Goku: ok, remoable doesn't really work for me with your snapd package in testing
<Chipaca> mvo: zyga: i'll fix this :)
<zyga> thank you!
 * zyga thinks that with snapd architecture growing we could consider some better error resilience,
<zyga> like not crashing the whole damn thing at once
<morphis> mvo: btw. I saw there is a name change in the vendor release tarball for snapd, 2.24 has vendor.orig.tar.xz and 2.25 has vendor.tar.xz
<morphis> mvo: is that intentional?
<mvo> morphis: sort of, I have a script now (finally) that is doing all this, so pick a name that you like best and from that point on it will be always the same
<mvo> zyga, Chipaca: thank you
<mvo> a second review for 3297 would be great
 * zyga looks
<zyga> aww, drat
<zyga> I cannot review my code
<zyga> pstolowski: ^^
<zyga> mvo: something you suggested https://github.com/snapcore/snapd/pull/3298/files
<mup> PR snapd#3298: interfaces/builtin: ensure we don't register interfaces twice <Created by zyga> <https://github.com/snapcore/snapd/pull/3298>
<morphis> mvo: great, I am fine with both names, just wondered that is has changed with 2.25
<mvo> zyga: thank you!
<mvo> morphis: ok, I will leave the 2.25 name then
<ogra_> rharper, a safe bet is snap_core or snap_kernel from /proc/cmdline
<abeato_> morphis, zyga I think you have seen this before: http://paste.ubuntu.com/24553598/ . Was there a kernel patch for this?
<morphis> abeato_: possible
<abeato_> it appeass here: https://bugs.launchpad.net/apparmor/+bug/1656121
<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>
<mup> PR snapd#3297 closed: overlord/ifacestate: don't spam logs with harmless auto-connect messages <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3297>
<morphis> abeato_: so we added support for /proc/*/ns/mnt with the single patch we imported into the 3.4 kernel, I fear we need a bit more than that
<abeato_> morphis, hmm, I see
<mup> PR snapd#3299 opened: timeutil: avoid panicing when the window is very small <Created by chipaca> <https://github.com/snapcore/snapd/pull/3299>
<Chipaca> zyga: mvo: ^
<Chipaca> mvo: what're you up to?
<Chipaca> mvo: (want me to fix snapd/#3290 for you?)
<Chipaca> snapd/3290
<Chipaca> snapd/#3290
<Chipaca> mup: OI!
<mup> Chipaca: Unknown commands are unknown.
<Chipaca> snapd#3290
<mup> PR snapd#3290: add support for `snap install foo --channel=3.4` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3290>
<Chipaca> sigh...
<Chipaca> it's going to be a long day
<mup> PR snapd#3296 closed: image: fix go vet issue <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3296>
<zyga> Chipaca: looking!
<mvo> Chipaca: yay, thank you!
<zyga> abeato_: that probably tells you that /proc/1/ns/mnt does not exist
<zyga> abeato_: is this a pre 3.8 kernel?
<zyga> Chipaca: we should really practice commit messages
<zyga> Chipaca: you cannot return 0 AFAIR
<Chipaca> zyga: why not?
<zyga> Chipaca: that function panics on zero too
<Chipaca> which function
<Chipaca> ah, rand.Int64n
<zyga> Chipaca: /usr/share/go-1.6/src/math/rand/rand.go on line 64
<Chipaca> 63n
<Chipaca> *
<zyga> yp
<zyga> yep
<Chipaca> <= then?
<zyga> random of 0 is pretty non random :D
<abeato_> zyga, it does exist, it is 3.4 + ns patch, but maybe we miss something still
<Chipaca> fo sho
<zyga> well, you cannot return 0 :)
<Chipaca> zyga: why can't i return 0?
<zyga> abeato_: try stracing
<zyga> Chipaca: ahh
<Chipaca> zyga: the rand call is in the function i'm returning from
<zyga> Chipaca: sorry, I misread that
<zyga> Chipaca: yes, that's ok
<zyga> Chipaca: I thought this returns the input to randint,
<Chipaca> zyga: still need to change it to a <=
<zyga> but it's not :)
<Chipaca> adding a test
<Chipaca> tested, fixed, pushed
 * zyga looks at http://radio.garden
<zyga> Chipaca: thank you!
<mvo> Chipaca: ideally we would simply not allow windows smaller than 30min
<pedronis> Chipaca: ?
<Chipaca> pedronis: look at the logs zyga pasted (with a double mutex lock panic)
<pedronis> that's refresh.schedule stuff
<Chipaca> pedronis: good morning :-)
<Chipaca> pedronis: sorry, i thought they were all the same things
<pedronis> ?
<Chipaca> pedronis: but the one that's for you is the mutex double lock one
<Chipaca> let me get the right one for you
<Chipaca> pedronis: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-image/zesty/amd64/s/snapd/20170511_000322_edb35@/log.gz
<Chipaca> not lock, unlock
<Chipaca> w/e :-)
<pedronis> Chipaca: well we have some codes that can hit that
<Chipaca> is anybody else getting a "los glaciares national park" google doodle, or is google being extra creepy with me?
<zyga> ?
<zyga> Chipaca: no
<zyga> Chipaca: on google.co.uk?
<Chipaca> yes
<Chipaca> (also in the chrome startup page)
<zyga> Chipaca: check out that radio thing, it's amazing :)
<Chipaca> mvo: so just make the schedule parser return an error?
<abeato_> zyga, morphis http://paste.ubuntu.com/24553660/    It seems that /proc/1/ns/mnt is not a link, but looking at my local machine it seems it should be...
<zyga> abeato_: aha, I know what's going on
<mvo> Chipaca: either that or just enlarge it to 30min
<zyga> abeato_: you found a bug :)
<mvo> Chipaca: but I guess for now this fine
<abeato_> lol
<zyga> abeato_: on older kernels it was not a link
<zyga> abeato_: hmm hmm hmm
<mvo> Chipaca: we can do a followup
<zyga> abeato_: let me wake up and think about this
<morphis> abeato_: interesting
<mvo> Chipaca: I want 2.26 out :) so followup
<zyga> abeato_: but if you can give me a way to run this locally to experimen
<zyga> abeato_: I would appreciate that
<zyga> abeato_: as a quick work-around do this:
<abeato_> zyga, hmm... maybe I can give you remote access to the board
<zyga> abeato_: comment-out the call to sc_reassociate_with_pid1_mount_ns in snap-confine.c
<zyga> abeato_: that's good too
<zyga> abeato_: perhaps we can discuss this on a private channel
<pedronis> Chipaca: what's the question,  the test does Unlock,  and will not relock under an unexpected panic
<morphis> zyga: you have any reference to resources who talk about ns/mnt being changed to a symlink=
<morphis> zyga: this really means we're still missing patches
<pedronis> Chipaca: I mean around Ensure
<zyga> morphis: no, it's just changed in a future kernel version
<zyga> morphis: it's even documented in namespaces(7)
<Chipaca> pedronis: i guess the question is "can this be fixed so it doesn't fail at random", with a side of "is this a bad test or can this actually happen"
<pedronis> Chipaca: it's a test trying to not get too fussy
<pedronis> Chipaca: there is nothing deep going on here
<pedronis> just read the code
<mup> PR snapd#3300 opened: cmd/snap-confine: don't fail on pre 3.8 kernel <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/3300>
<Chipaca> mvo: should i fix the --channel one for you?
<Chipaca> mvo: or do we bump it
<mvo> Chipaca: isn't that fixed, I thought I pushed a fix
<Chipaca> ah maybe i need to refresh
<pedronis> Chipaca: short story, we should in theory never use lock/unlock pairs without defer, in practice we trade that for readability sometimes under the assumption that what is enclosed shouldn't panic or we are in a test
<Chipaca> mvo: doesn't look fixed
<Chipaca> mvo: only one commit
<Chipaca> ohhhhh
<Chipaca> pedronis: this might actually be the same bug then :-)
<Chipaca> pedronis: i mean, this panic happens because the ensure panics
<Chipaca> and the defer then kicks in and panics again?
<pedronis> Chipaca: yes
<Chipaca> and the panic is inside rand, called from timeutil/schedule.go
<Chipaca> so it _is_ the same thing :-)
<pedronis> Chipaca:  we lock defer unlock  then unlock then panic, the deferred unlock is not pleased
<Chipaca> whee
<Chipaca> pedronis: then it's fixed already :-) (not on master yet but soon)
<Chipaca> pedronis: thank you
<pedronis> Chipaca: anyway it's a panic on panic as you noticed,  and at least with Unlock/Lock it will not deadlock
<mvo> Chipaca: hrm, test failure in snap auto mount test, looks like a flaky test, I have a look
<Chipaca> mvo: _did_ you push a fix to 3290?
<Chipaca> mvo: (no you didn't :-) )
<zyga> Chipaca: can you tell me why this failed perhaps? https://travis-ci.org/snapcore/snapd/builds/231080836?utm_source=github_status&utm_medium=notification
 * Chipaca looks
<zyga> Chipaca: the non-debug output is short and lacks data, the debug output is enormous and full of store stuff
<Chipaca> zyga: I don't know, but I do know that if that used MATCH instead of grep, we'd know :-)
<Chipaca> now trolling the debug output
<mvo> Chipaca: ups, sorry, forgoten push
<Chipaca> mvo: :-)
<mvo> zyga: I approved 3300 but it appears like there are still issues
<zyga> thank you
<zyga> I'm looking at that now
<mvo> zyga: aha, I see you are on it already
<mvo> zyga: thanks again
<Chipaca> zyga: mvo: wrt snapd#3299, I think it's flaky and restarting the test would be ok for now
<mup> PR snapd#3299: timeutil: avoid panicing when the window is very small <Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/3299>
<zyga> Chipaca: go for it!
<Chipaca> i also think the test is badly written, and will push a fix
<Chipaca> but that fix can wait for post-2.26
<mvo> Chipaca: thank you - what do you have in mind to improve it (just curious)
<Chipaca> mvo: for now, just switch it to use MATCH
<Chipaca> so we know why it failed :-)
<Chipaca> the debug output looks very wrong, like something else was going on in parallel
<Chipaca> what should be the last thing in the log is way at the top
<Chipaca> (the GET /v2/assertions/account-key)
<mvo> Chipaca: heh, very good point
<mvo> Chipaca: and agreed, the prepare is also doing much and the output of prepare is completly lost so +1 for improving the test
<mvo> Chipaca: also thnaks for the note about the test for the "/" in the shortcut branch, I will add this once 2.26 is out, this branch is not really needed for 2.26 I think
<pedronis> mvo: Chipaca: fwiw IÂ agree we should have a minimal spread
<pedronis> for refreshes
<pedronis> s/minimal/minimum/
<mvo> +1
<ogra_> mvo, so did you have a chance to read through https://forum.snapcraft.io/t/allow-disabling-system-services-on-ubuntu-core/531 ? (i dont want to upload http://paste.ubuntu.com/24549394/ withough your approval)
<ogra_> *without
<zyga> mvo: so I think the issue is solved
<mvo> ogra_: not yet, I will do 2.26 first and then have a look, I think its probably best to do this change after that
<mvo> zyga: oh, nice.
<ogra_> mvo, ok
<mvo> zyga: so no fchdir() - do you still want to fix that?
<mvo> zyga: if so, I can wait a little bit longer, if that is the remaining blocker for this kernel
<zyga> mvo: not sure yet, I think this may be a bigger issue as I never tested this on a kernel this old
<zyga> abeato_: ^
<zyga> abeato_: do you want to cherry pick a fix into your kernel
<zyga> abeato_: or would you see this as something that needs to change in snap-confine
<zyga> mvo: I need to do a survey of what else is failing on 3.4 hybrid
<mvo> zyga: ok
<abeato_> zyga, if a cherry pick for the kernel fixes it, that is perfectly fne
<zyga> abeato_: not sure how large the cherry pick is :)"
<zyga> abeato_: who maintains your kernel?
<abeato_> hehe, yeah, that i typically the issue
<abeato_> zyga, shrirang I guess
<mup> PR snapd#3299 closed: timeutil: avoid panicking when the window is very small <Critical> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3299>
<zyga> abeato_: ok, I'll refrain from changing anything more until you give me a ping
<abeato_> ok
 * zyga lunch
<pedronis> pstolowski: snapd#3212 has two +1 but the tests failed/are failing
<mup> PR snapd#3212: api, ifacestate: resolve disconnect early <Created by stolowski> <https://github.com/snapcore/snapd/pull/3212>
<ogra_> ppisati, argh ... http://paste.ubuntu.com/24554186/
<ogra_> fgimenez, hmm ... did you revert (or have someone revert) the pi2-kernel in edge ? i released rev30 (same as in beta) yesterday to edge ...
<zyga> mvo: is 2.26 tagged now? :)
<ogra_> but ...
<ogra_> ogra@pi3:~$ snap info pi2-kernel | grep edge
<ogra_>   latest/edge:      4.4.0-1048-55 (28) 100MB -
<ogra_> ogra@pi3:~$
<ogra_> oh, wow ... the store UI shows rev30 in edge ...
<zyga> Chipaca: ^^
<ogra_> ah, wait
<ogra_> my browser has myapps.d.u.c open ...
<ogra_> and thats also what i used to release it ...
<ogra_> might be a bug in the old UI
<Chipaca> zyga: sorry, what?
<ogra_> dashboard.snapcraft.io shows the samer the board shows on snap info
<zyga> Chipaca: discrepancy between snap info and store, I thought you might be interested
<ogra_> zyga, well, the old UI is broken ... works fine when i release via dashboard.s.io
<ogra_> we should force-redirect people
<ogra_> (half my open browser tabs point to old myapps.* urls)
<Chipaca> looks like i don't have store access to pi2-kernel
<Chipaca> ogra_: zyga: I don't know what'd happen if you used myapps to push snaps now
<Chipaca> hopefully nothing disastrous, but I don't know
<Chipaca> Facu: do you?
<Chipaca> zyga: in any case, "discrepancy between snap info and store" makes no sense to my addled brain
<Chipaca> zyga: you mean SCA and CPI are inconsistent?
 * zyga has no idea
<zyga> did I mention I didn't sleep long last night
<Chipaca> ogra_: can you pastebin the output of 'snapcraft list-revisions --arch armhf pi2-kernel' ?
<Facu> hola Chipaca
 * Facu reads
<Chipaca> ogra_: and the output of 'snap info pi2-kernel' as well
<ogra_> Chipaca, its a UI issue ...
<ogra_> writing a forum topic now
<Chipaca> ogra_: brother UI, UI, UI â«
 * zyga wants to hand out beer to anyone that wants to review  https://github.com/snapcore/snapd/pull/3295/files
<mup> PR snapd#3295: interfaces/builtin: make all interfaces private <Created by zyga> <https://github.com/snapcore/snapd/pull/3295>
<ogra_> hehe
<Chipaca> zyga: i'm working through that
 * zyga hugs Chipaca and offers to haul some booze to portugal
<Chipaca> zyga: and licorea.es delivers to my house
<Chipaca> :-)
<zyga> :D
 * zyga looks
<Chipaca> or was it .com
<Chipaca> zyga: .com
<zyga> Chipaca: what do you prefer?
<Chipaca> zyga: i was j/k
<pstolowski> pedronis, oh, this failure looks a bit worrying, and unrelated to my change
<Chipaca> pstolowski: which failure?
<pstolowski> Chipaca, https://travis-ci.org/snapcore/snapd/builds/231089319?utm_source=github_status&utm_medium=notification
<pstolowski> panic after retry, sync: unlock of unlocked mutex
<Chipaca> nice
<Chipaca> and not related to rand :-)
<Chipaca> (so it's not the one i fixed)
<ogra_> Chipaca, Facu https://forum.snapcraft.io/t/myapps-developer-ubuntu-com-vs-dashboard-snaopcraft-io/549
<Chipaca> ogra_: when you say myapps, do you mean dashboard.snapcraft.io?
<Chipaca> ogra_: or do you actually mean myapps?
<ogra_> Chipaca, no, i mean https://myapps.developer.ubuntu.com/dev/click-apps/5573
<Chipaca> ah
<ogra_> (thats the pi2-kernel snap)
<Chipaca> right
<Chipaca> ogra_: sorry i hadn't finished reading :-)
<Chipaca> ogra_: in myapps, what series is the pi2-kernel snap?
 * ogra_ waits for the UI to reload 
<ogra_> bah
<ogra_> it redirected me now :P
<ogra_> seems the "overview" like actually does a redirect ... but just reloading or going into one of the versions does not
<ogra_> s/like/link
<Chipaca> ogra_: in the list of all your packages in myapps, it lists the series of the snap. what does it show for pi2-kernel?
<ogra_> Chit doesnt show it at all
<ogra_> Chipaca, ^^
<ogra_> "Ubuntu Touch clicks and snaps for 15.04"
<Chipaca> ogra_: screenshot or it didn't happen
<Chipaca> because i'm seeing the series for everything, there
<ogra_> it shows all 15.04 packages i own ...
<ogra_> and says at the bottom "Your series 16 snaps can now be found at https://dashboard.snapcraft.io."
<Chipaca> ogra_: http://imgur.com/a/RQFnG
<Chipaca> ogra_: in the list of revisions
<ogra_> so i guess the frontpage as well the the package overview are fine ... (since that actually redirects me) ... but when i'm on the old page and click on a version on myapps it does not redirect
<Facu> ogra_, do you see pi2-kernel in myapps?
<Chipaca> ogra_: it shows you the series
<Chipaca> ogra_: my question is, in that list of the pi2-kernel, what does it show
<ogra_> Facu, not on the frontpage ... but in the myapps pages i have open i can still navigate around myapps
<Chipaca> ogra_: myapps is still active and functional for clicks and 15.04 snaps
<ogra_> Facu, i guess there is simply no redirect on pages that are deeper down the tree
<ogra_> Chit doesnt show the pi2.-kernel in that list ... but it doesnt redirect me if i'm on an old myapps site and click some version to set the checkmark on a channel
<ogra_> Chipaca, ^^
<ogra_> (geez ... cant get used to type three chars for tab completion )
<Chipaca> ogra_: how did you get to the old myapps site?
<Facu> ogra_, so, the scenario is that you had a page open showing a snap in myapps from a month ago, and now you go back to using it and it shows the snap info?
<ogra_> Chipaca, it is open in my broiwser
<Chipaca> ogra_: you must have a terabyte of ram :-)
<Chipaca> but ok
<Chipaca> Facu: over to you :-)
<pedronis> pstolowski: seems there's a codepaht in retryPostRequestDecodeJSON that returns nil, nil ?
<ogra_> Facu, it had it open and clicked on one of the versions ... did set a checkmark on a channel and went back to the overview
<ogra_> Facu, so the version links should simply redirect me too ... seems the "overview" one already does
<Facu> ogra_, or at least give some error
<ogra_> right
<Facu> ogra_, not leaving you with the impression "it worked"
<ogra_> yeah
<Chipaca> Facu: do myapps and the dashboard share a backend database?
<Facu> Chipaca, not sure
 * ogra_ adds a followup to the forum
<pstolowski> pedronis, checking
<pedronis> pstolowski: the traceback seems to say we explode on auth.go:306
 * Chipaca poddles off to investigate lunch
<zyga> Chipaca: do it
<zyga> Chipaca: but beware
<zyga> after lunch all I want is sleep
<zyga> and I think I will just do it
<Chipaca> i see no problem
<zyga> I may miss standup if I succeed
<zyga> if I do, I'll wake up and look at PRs and update-ns
<zyga> I think release is in good hands
<zyga> and apart from panick on unlock I think it's okay
<mvo> zyga: I'm about to finalize the release
<ppisati> ogra_: what did you do to get that?
<ogra_> ppisati, obviously running 4.4.0-1048-55  pi2 ... thats outrdated though, i guess you can ignore it
<ppisati> ogra_: oh ok
<ogra_> i only noticed later that the kernel was old .... i'tt shout if i see it with a newer one again
<ogra_> *i'll
<ppisati> ogra_: ack
 * Chipaca hugs mvo for being awesome (and because of read -r)
<Chipaca> it's the missing bit that makes in-snap tab completion purrfect
<Chipaca> i was dreading digging through it to figure this one out :-)
<pstolowski> pedronis, i'm going to create a test to try reproduce
<ali1234> ugh... why doesn't "snapcraft clean <part> -t <step>" work?
<pedronis> pstolowski: I'm not sure at all how it happens, but reading the traceback it would seem resp == nil (or I'm missing something something), that's the thing we read on 306
<niemeyer> Hello all
<niemeyer> How's spread behaving this morning?
<niemeyer> fgimenez: ^
<fgimenez> hey niemeyer all good, the execution times have reduced to ~30min
<niemeyer> fgimenez: Cool..  slightly over or slightly under?
<fgimenez> niemeyer: about 10min lower
<niemeyer> fgimenez: Sorry, I mean, slightly over 30 or sightly under 30
<pstolowski> pedronis, i thought the same, but it's strange, we should be remembering and returning the most recent error
<fgimenez> niemeyer: ah :) under, 28 or so, i hope to have proper metrics soon
<niemeyer> fgimenez: Okay, that's great!
<niemeyer> fgimenez: That means we can probably hit the 20 mins mark with another bump today
<fgimenez> niemeyer: yep, the remaining 50% should put the build close to 20min
<niemeyer> fgimenez: Can you please push another PR with that change?
<fgimenez> niemeyer: sure on it
<niemeyer> fgimenez: I'll keep an eye on resource utilization today and see whether we need more and how many
<niemeyer> Actually, we can probably guess the right number of machines from the Travis concurrency limit
<lazyPower> Correct me if i'm wrong, but is there a way to mount your snap from PWD instead of building the squashfs image? I'd like to debug my config hook and interactively execute some bits to test a script. I dont feel like i can do that reliably in the squashfs image... its read only in that context.
<lazyPower> i thought i recalled hearing about a path to do that, but i'm at a loss for finding it in the docs on snapcraft.io
<Chipaca> lazyPower: "snap try"
<lazyPower> aha! ty
<Chipaca> np
<Chipaca> so many mups!
<niemeyer> Uh?
<ogra_> mupvasion!
<Chipaca> niemeyer: one on ipv4, one on ipv6
<niemeyer> Ah.. that explains it
<niemeyer> Network is probably not so happy
<ogra_> network mupocalypse!
<mup> PR snapd#3301 opened: spread.yaml: increase the number of linode workers by 1 <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3301>
<niemeyer> morphis: Standup?
<mup> PR snapd#3302 opened: release: releasing package snapd version 2.26 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3302>
<Chipaca> mvo: in the second answer to that sd wear levelling question there's a link to bunnie pointing out that adding a wear levelling controller is cheaper than doing QA, so zyga's probably right in practice except for the most cheapestest cards (that don't do QA either way)
<mvo> Chipaca: yeah, that is my understanding of how this works too
<Chipaca> ok
<mvo> Chipaca: the controller lies to you but thats ok
<mvo> s/you/us/
<rharper> ogra_: thanks, I'll add that to the list
<mup> PR snapd#3300 closed: cmd/snap-confine: don't fail on pre 3.8 kernel <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3300>
<zyga> https://github.com/snapcore/snapd/pull/3289 needs a 2nd review
<mup> PR snapd#3289: daemon: do not allow to install ubuntu-core anymore <Created by mvo5> <https://github.com/snapcore/snapd/pull/3289>
<pstolowski> pedronis, got a test which reproduced the panic; it's enough to have a host name for the store server that doesn't resolve
<zyga> !
<zyga> wow
<pstolowski> and I think I've a fix. and I think (but need to verify) this problem is unique to this single case of retry
<pstolowski> the problem is err got shadowed
<zyga> pstolowski: don't we have a static analyzer that looks for variables that are assigned to but not used?
<pedronis> pstolowski: ah, the NewRequest line has :=
<pedronis> :/
<zyga> is that something we want to fix for 2.26 ?
<pstolowski> pedronis, yeah...
<pedronis> pstolowski: := creates all new variables
<pstolowski> zyga, it is used.. the func is defined as func(..) (err error, resp Response)
<pstolowski> pedronis, yeah I know. oversight.
<pedronis> pstolowski: was this code new in 2.25 ?
<pedronis> zyga: mvo: we might need a 2.25.1
<pedronis> pstolowski: so we were missing tests, for exiting on timeout of retries ?
<pstolowski> pedronis, I need to check this still
<pedronis> pstolowski: the code in store.go does have this problem it seems, only auth.go
<pstolowski> pedronis, yes I think so, but I'll add a test to store too
<pedronis> pstolowski: code seems to have been already there in 2.23 at least
<pstolowski> pedronis, yes, commits are from Jan 27
<pedronis> it's not a regression but if IÂ understand correctly it's also not very nice
<pstolowski> yes it's pretty bad actually
<pedronis> pstolowski: I let you and mvo decide what to do
<pstolowski> if you ask me, I'd include the fix in this release... now sure how much hassle that is for mvo
<mup> PR snapd#3303 opened: store: fix panic error in auth <Created by stolowski> <https://github.com/snapcore/snapd/pull/3303>
<pstolowski> pedronis, mvo ^
<mvo> pstolowski: cool, looking
<mvo> pstolowski, pedronis: a 2.26.1 works for me, let me check the fix
<mvo> pstolowski: woah, how does this happen?
<zyga> mvo: this looks like a bug I fixed in the interface code a few months ago
<zyga> mvo: the same pattern
<fgimenez> mvo: we are getting this error in prepare https://travis-ci.org/snapcore/snapd/builds/231151352#L1235 it seems that there's a new version of ubuntu-image, could you please take a look when you have a moment?
<pstolowski> mvo, err got shadowed... the test panics the same way without the fix
<morphis> niemeyer: sorry, was out around that time today, told zyga yesterday
<mvo> pstolowski: ohhh, shadowing. that makes sense
<mvo> fgimenez: sure, I have a look now
<mvo> fgimenez: could we simply switch --dvmode to --classic in the test to fix the error?
<fgimenez> mvo: i think so, let me check
<mvo> fgimenez: thank you
<mvo> fgimenez: we need to do 2.26.1 anyway now if all our tests are broken
<mvo> fgimenez: which is slightly annoying because the older spread-cron runs will also break now, no?
<mvo> fgimenez: so maybe we need to ask foundations to revert this
<fgimenez> mvo: np for spread-cron, most of the executions have finished but yes, with errors
<pstolowski> mvo, sorry for adding more work with .1 :(
<mvo> hey sil2100, good afternoon
<sil2100> Hey o/
<mvo> sil2100: quick question, it looks like ubuntu-image has changed to classic confinement recently?
<sil2100> mvo: yes, after some discussions with various people barry thought that it's more fitting for this confinement
<mvo> sil2100: this is currently breaking tests on our side and I wonder what the best way forward is. maybe just us fixing the tests but it means ubuntu-imgae can not be used on a ubuntu-core system anymore which is slightly odd
<mvo> fgimenez: can we fix spread-cron easily to use --classic when we generate the images?
<sil2100> https://bugs.launchpad.net/ubuntu-image/+bug/1638645
<mup> Bug #1638645: Make ubuntu-image a classic snap <Ubuntu Image:Fix Released by barry> <https://launchpad.net/bugs/1638645>
<sil2100> This is the relevant bug
<mvo> sil2100: thank you. let me read it
<fgimenez> mvo: sure np, we also need to fix snapd's prepare https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L177
<mvo> sil2100: thanks, I'm not sure this is the best decision but I think we can fix it on our side. I may come back to you and ask for !classic at some point mostly because it seems like it should also work on core systems. but I think for now we are ok. thanks for pointing me to the relevant bug
<mvo> fgimenez: yeah, I will do that now
<fgimenez> mvo: great thanks!
<mvo> fgimenez: it breaks all branches currently
<mvo> fgimenez: and our spread-cron and other tests use a different prepare than the one in our snapd git, right?
<morphis> Pharaoh_Atem: ping
<mup> PR snapd#3304 opened: tests: the new ubuntu-image snap needs classic confinement, adjust tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3304>
<Pharaoh_Atem> morphis: pong
<fgimenez> mvo: usually not, the suite is the same only tweaked setting the appropriate environment variables, there are cases where it is different, like the nightly or nested suites, ubuntu-image would affect only the nested suite i think, where we need to create and boot an instance
<morphis> Pharaoh_Atem: you saw my comments on bodhi?
<sil2100> mvo: ok, no problem! I guess we're open to suggestions regarding that
<mvo> pstolowski: no worries, this is a reason we need 2.26.1 anyway I think so all is good
<Pharaoh_Atem> morphis: yeah, I'm going to fix it asap and push a new build
<mvo> pstolowski: this being the uubntu-image fallout
<pstolowski> ok
<Pharaoh_Atem> morphis: what files are created by snapd to manage things?
<morphis> Pharaoh_Atem: thanks!
<Pharaoh_Atem> I can add them as %ghost files so that rpm deletes them correctly
<sil2100> mvo: I think we just looked and saw classic to fit our case the best (as it's a tool like that) and it fixed our problems with /tmp
<Pharaoh_Atem> morphis: is it just /var/lib/snapd/state.json, or are there other things?
<morphis> Pharaoh_Atem: other things too
<mvo> sil2100: yeah, the /tmp being a tmpfs is certainly annoying for the u-i use-case
<Pharaoh_Atem> morphis: do you have a list?
<morphis> Pharaoh_Atem: it looks like even the directories the rpm ships aren't cleared
<ogra_> sil2100, that makes it pretty much impossible to use ubuntu-image natively in some kind of ubuntu-core installer (where you would boot an ubuntu-core and run ubuntu-image to create a fresh image tailored for a target device), there is no support for classic interfaces on core
<morphis> Pharaoh_Atem: there is no "purge" option for dnf, right?
<Pharaoh_Atem> apt's purge comes from dpkg, so no
<morphis> ok
<morphis> Pharaoh_Atem: I can give you a list later, currently
<Pharaoh_Atem> that'd be helpful
<morphis> my system is loaded :-)
<Pharaoh_Atem> I can `%ghost` all the files that snapd itself creates so that on final uninstall, rpm clears them
<niemeyer> morphis: No worries!
<morphis> Pharaoh_Atem: ok, let me give you the list and we can fix that
<Pharaoh_Atem> excellent
<morphis> Pharaoh_Atem: otherwise the script works well on suse too so we should generalize it a bit more and push to the repo so all distros can use it
<Pharaoh_Atem> morphis: that's the plan :)
<morphis> Pharaoh_Atem: great :-)
<Pharaoh_Atem> I'd like to minimze what this script does as much as possible because I want the package manager to be as aware as possible
<sil2100> mvo, ogra_: could anyone of you open a bug for it for discussion?
<morphis> ogra_: did you ever try to boot one of our armhf core images in qemu?
<ogra_> morphis, well, on what HW emulation ?
<ogra_> does our qemu have any Pi or dragonboard emulation ?
<morphis> ogra_: just did a first attempt to boot a pi3 image
<morphis> ogra_: good question, was looking which could be used
<ogra_> i dont think there is
<ogra_> there is something for an early beagleboard (not bone)
<morphis> hm
<ogra_> but thats srtill omap i think
<morphis> -M vexpress-a9 -cpu cortex-a9 might be a start but not for the pi images
<morphis> we would need a more common kernel snap
<ogra_> sil2100, mvo i opened https://bugs.launchpad.net/ubuntu-image/+bug/1690170 ... mvo might be good if you could also add soemthing
<mup> Bug #1690170: classic confinement makes running ubuntu-image inside UbuntuCore images impossible <Ubuntu Image:New> <https://launchpad.net/bugs/1690170>
<sil2100> ogra_: thanks
<morphis> ogra_: https://wiki.ubuntu.com/Kernel/Dev/QemuARMVexpress suggests the lpae kernel should do the job
<ogra_> morphis, well ... vexpress
<ogra_> you'd need a kernel and gadget for that
<morphis> right
<ogra_> and it will crawl
<morphis> hm
<ogra_> not sure thats worth the effort (unless it improved massively since i used it last ... which is admittedly a while ago)
<pstolowski> oh my
<morphis> just wondering if using real hardware is the best approach these days to support our spread testing for armhf only snaps or if we can use qemu for a few things too
<pstolowski> so my DNS test fails differently on travis than locally :/
<fgimenez> morphis: i did something about qemu and pi2 but it didn't manage to boot https://github.com/fgimenez/pi2-qemu if you want to have a look
<ogra_> you should be able to us4e kvm on arm64 ...
<pstolowski> error string = "cannot query the store for updates: got unexpected HTTP status code 503 via POST to \"http://nonexistingserver909123.com/updates/\""
<ogra_> but i'm not sure how the armhf emulation on top of that is
<morphis> ogra_: we get armhf only binaries delivered we have to use
<morphis> fgimenez: nice! will have a look
<pstolowski> instead of ""Post http://nonexistingserver909123.com/updates/: dial tcp: lookup nonexistingserver909123.com on .*: no such host" locally
<ogra_> morphis, yes, i meant an armhf kvm on top of an arm64 server
<morphis> ah
<pstolowski> Chipaca, hey, do you have any idea why this could be? ^
<ogra_> morphis, i know we use kvm for the arm64 buildds ... perhaps wgrant knows if it is possible to use armhf machines on that
<morphis> fgimenez, ogra_: http://blog.3mdeb.com/2015/12/30/emulate-rapberry-pi-2-in-qemu/
<ogra_> ah, a patch :)
<morphis> fgimenez: see you're using -M raspi2, were you using this tree for qemu?
<niemeyer> pedronis: On it
<pedronis> niemeyer: thx, sorry for wrong channel
<niemeyer> pedronis: np, I didn't realize I was replying in a different channel, sorry
<Chipaca> pstolowski: what do you mean?
<Chipaca> it's not resolving
<Chipaca> Â¯\_(ã)_/Â¯
<niemeyer> pedronis: (read in the pop up)
<fgimenez> morphis: nope, qemu from the archive, afaik the (partial) support is available from 2.6? need to check
<ogra_> ooh !
<ogra_> now thats cool
<morphis> fgimenez: but you didn't used xenial, right?
<morphis> didn't saw a raspi machine on the xenial qemu
<pstolowski> Chipaca, it's not resolving when run locally, but gives 503 on travis (?!)
<pedronis> pstolowski: because there's a proxy setup
<pstolowski> Chipaca, see my comment to https://github.com/snapcore/snapd/pull/3303
<mup> PR snapd#3303: store: fix panic error in auth <Created by stolowski> <https://github.com/snapcore/snapd/pull/3303>
<pstolowski> ahh
<fgimenez> morphis: no, yakkety
<morphis> fgimenez: ah
<pedronis> pstolowski: so you get the 503 (from the proxy)
<pstolowski> right
<pstolowski> in that case I've no better idea than to dumb the check to only see if err != nil
<niemeyer> pedronis: Done
<morphis> ogra_: ok, current git tree of qemu has the raspi machine
<ogra_> make a snap ;)
<Chipaca> pstolowski: I'm going to ahead and guess that there's an http proxy that 503s when it can't resolve
<morphis> ogra_: you can read my mind :-)
<Chipaca> (when using an http proxy the client isn't the one doing the dns lookup)
<ogra_> *g*
<Chipaca> ah, what pedronis said
<Chipaca> sorry for the latency :-)
<pedronis> pstolowski: does snapd#3120 needs a test rerun or a new merge with master?
<mup> PR snapd#3120: interfaces/hooks: expose attrs to the interface API, snapctl enhancements (step #4) <Created by stolowski> <https://github.com/snapcore/snapd/pull/3120>
<pstolowski> Chipaca, yep. thanks
<pstolowski> pedronis, no, its spread test needs some work. I abused content interface there for a test, and what I did there needs changing
<niemeyer> Lunch here
<morphis> Pharaoh_Atem, zyga: 2017/05/11 17:47:26 Successful tasks: 89
<Pharaoh_Atem> ?
<morphis> Pharaoh_Atem, zyga: we're coming close to 100 working spread tests on Fedora :-)
<Pharaoh_Atem> ah
<Pharaoh_Atem> nice
<zyga> morphis: very nice; I'd like to discuss how we are going to support testing that is cross distribution
<zyga> morphis: I'd love to see your branches for that
<zyga> morphis: we need something that is scalable
<morphis> zyga: right
<mup> PR snapd#3304 closed: tests: the new ubuntu-image snap needs classic confinement, adjust tests <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3304>
<zyga> mvo: master is good again, we can merge it into failed PRs
<Chipaca> zyga: Q:    cat /var/lib/snapd/apparmor/profiles/snap.test-snapd-devmode.test-snapd-devmode | grep attach_disconnected | grep -v complain
<Chipaca> zyga: you're wanting to check that nothing that has attach_disconnected has complain?
<Chipaca> zyga: (also there's a bug in this test where apparmor is checked for @complain)
<nacc> is there a store way to say that a given snap has been replaced by another (and have end-users automigrate)?
 * zyga tries to parse Chipaca's question
<Chipaca> oh dear, store is taking a break
<zyga> Chipaca: why would I want to check that nothing that has attach_disconnet has complain?
<Chipaca> zyga: i dunno! you wrote the test :-)
<zyga> ah, which test is that?
<Chipaca> regression-jailmode-1641885
<zyga> so the first grep just gives us the right line
<zyga> the second test is checking for the interesting part
 * zyga looks 
<ogra_> hmm
<Chipaca> Facu: is CPI AWOL?
<zyga> Chipaca: indeed, I see the bug
<ogra_> where is my channel info gone ?
<ogra_> http://paste.ubuntu.com/24555462/
<Chipaca> ogra_: CPI is not responding
<ogra_> ouch
 * zyga drinks to CPI
<ogra_> oh, beer time!
<mvo> zyga: thank you, just returned from dinner, checking out the sttaus now
<zyga> mvo: the status may be ^^ bad
<mvo> zyga: yeah, just noticed
<mvo> jinxed again
<mvo> sound like I can extend my dinner ;)
<mvo> at least tests are pretty fast now
<zyga> Chipaca: sorry for asking dumb question but what is about that test?
<ogra_> "i got fat because of bugs"
<zyga> Chipaca: I get that the seccomp part is bogus
<zyga> Chipaca: (fixed locally)
<Chipaca> zyga: I'm in the middle of fixing a bunch of those, can do this in drive-by
<Chipaca> zyga: it's just a s/apparmor/seccomp/ in te path, right?
<zyga> Chipaca: the apparmor part is as you predicted, we want to check that the profile is not in complain mode
<zyga> Chipaca: yes
<zyga> Chipaca: if you fix that I can remove my branch now :)
<Chipaca> yes
<zyga> Chipaca: can you please also git mv the test to regression/ ?
<Chipaca> it's already fixed here :-)
<zyga> thanks!
 * zyga would like to see PR count drop below 20 today
<mup> PR snapd#3302 closed: release: releasing package snapd version 2.26 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3302>
<mup> PR snapd#3305 opened: release: snapd 2.26 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3305>
<mup> PR snapd#3306 opened: tests/main: move a bunch of greps over to MATCH <Created by chipaca> <https://github.com/snapcore/snapd/pull/3306>
<Chipaca> zyga: ^
 * zyga nice, looking
<Chipaca> http://status.snapcraft.io/
<zyga> LOL
<zyga> mvo: ^
<zyga> mvo: look at that with umatrix
<kyrofa> noise][, nessita I'm trying to refresh and getting this: "error: cannot refresh "nextcloud": cannot get refresh information for snap "nextcloud": Post https://search.apps.ubuntu.com/api/v1/snaps/metadata: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)"
<kyrofa> Are there known issues right now?
<Chipaca> kyrofa: store is down
<Chipaca> kyrofa: see status.snapcraft.io
<kyrofa> Huh, so it is
<noise][> Chipaca: apparently a lot of stuff down
<Chipaca> noise][: yeah
<Chipaca> bah
<Chipaca> things like ubuntu.com :-)
<Chipaca> psh
<Chipaca> :-D
<kyrofa> As soon as I post a call for testing! Hahaha
<Chipaca> kyrofa: so it's *your* fault!
<ogra_> Chipaca, ubuntu.com isnt down ... i still get a proper 503 page :P
<kyrofa> Hahaha
<zyga> oh
<zyga> someone tripped over the wrong cable?
<ogra_> or took it with him when leaving
<zyga> Chipaca: grep -c, what does it count?
<zyga> matches?
<Chipaca> matching lines
<Chipaca> echo aaa|grep -c a == 1
<zyga> ah, I see
<ogra_> equivalent to "grep | wc -l"
<zyga> one day someone will write a shell that contains a static anaylzer that rewrites stuff like "grep | wc -l" into proper optimized code
<zyga> all the core utilities have grown over time, to accumulate more and more options
<zyga> as optimization for what we do
<Chipaca> that's like saying that one day we'll sit down with the openbsd guys and unify everything
<Chipaca> their 'morse' program is so much cooler than the one in ubuntu
<kyrofa> Have we tweeted that we know the world is broken?
<zyga> Chipaca: no, we would never do that
<zyga> Chipaca: but a program might
<zyga> kyrofa: my twitter is broken
<kyrofa> zyga, THAT cable TOO?
<ogra_> ... -. .- .--. .--. -.--
<Chipaca> ogra_: https://www.freebsd.org/cgi/man.cgi?query=morse&sektion=6&manpath=FreeBSD+6.4-RELEASE
<ogra_> hah, cool
<Chipaca> see?
<Chipaca> :-)
<zyga> is that in CVS?
<zyga> actually nice :)
<jdstrand> noise][, nessita: fyi, getting 503 going to https://dashboard.snapcraft.io/dev/snaps/reviewer/
<kyrofa> jdstrand, yeah everything is busted
<Chipaca> ogra_: I especially like the bit in HISTORY
<ogra_> jdstrand, so better go to www.ubuntu.com then
<ogra_> :P
<zyga> is there a morse-modem so I can connect my PCs with pc-speakers and microphones and setup IP over that?
<Chipaca> ogra_: where people sign with their callsigns
<zyga> jdstrand: it's broken
<jdstrand> noise][, nessita: seems you probably already know that. ignore me
<noise][> there's a major network outage affecting multiple services
<zyga> jdstrand: status.snapcraft.io
<jdstrand> ok
<noise][> i posted to the forum as well
<Chipaca> anyway, seeing as everything is down, I'm going to EOD right about now.
 * zyga imagines IP over two 90's era text-to-speach and speach-to-text systems
<ogra_> farnsworth support !
<zyga> Chipaca: yeah :/
<zyga> Chipaca: I think that's the best to do
<zyga> I'll finish with your PR and I'll call it a day
<zyga> when the boat is on fire, you just take a swim and let others mend the fire ;)
<Chipaca> zyga: teamwork \o/
<mvo> zyga: heh, funny indeed, let me whitelist some things
<mvo> zyga: autsch, the status is slightly depressing
<zyga> mvo: thank you!
<zyga> mvo: on the upside, nobody will download the release anyway
<mvo> zyga: enjoy, I will see if I can do 2.26.1 today, if not, well, tomorrow morning
<mvo> zyga: hahahaa
<zyga> :)
 * zyga goes over some PRs
<mup> PR snapcraft#1310 closed: tests: use C.UTF-8 for the docker locale <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1310>
<zyga> drat, we have 26 PRs again
<zyga> mvo: I think you can override-merge https://github.com/snapcore/snapd/pull/3301
<mup> PR snapd#3301: spread.yaml: increase the number of linode workers by 1 <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3301>
<mvo> zyga: yeah, why not
<zyga> wow, chipaca did review https://github.com/snapcore/snapd/pull/3295 :D
<mup> PR snapd#3295: interfaces/builtin: make all interfaces private <Created by zyga> <https://github.com/snapcore/snapd/pull/3295>
<zyga> awesome!
<mup> PR snapd#3301 closed: spread.yaml: increase the number of linode workers by 1 <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3301>
<zyga> mvo: so it still doesn't work (in fact more services are down)
<zyga> mvo: I pushed fixes to several branches, did some more code reviews
<niemeyer> Need to step out for ~1h..
<zyga> mvo: and I think it's the best time to stop
<zyga> in the evening I'll check back and push udpdate-ns as all-in-one
<cratliff> Are there any plans for the catkin plugin to use catkin build instead of catkin_make?  If not, would this be a welcome change?
<kyrofa> cratliff, yeah I like catkin build as well
<kyrofa> cratliff, but it's not the standard-- I'm not sure what kind of ramifications moving to it would have
<kyrofa> cratliff, would love to hear your thoughts
<cratliff> kyrofa:  I'm fairly new to both ROS and snap, I just found out about catkin build today.  Using catkin build reduces my build time by about 10 minutes. It seems to build in isolated by default so I don't think there would be a big change in that regard.  The docs page has a list of make -> build translations.  If treated as simply a parallelized catkin_make it doesn't look to onerous, but is seems to have alot of additional feature
<pstolowski> is something terribly broken in master or with linode right now? got plenty of errors with my fix-panic branch
<ogra_> pstolowski, could they be related to the datacenter outage ?
<kyrofa> cratliff, yeah it's a bit more reminiscent of rosbuild, back in the fuerte days
<ogra_> (seems to all be up again now, but it lasted quite a while and affected a lot of services including store)
<pstolowski> ogra_, dunno, i wasn't aware of it
<kyrofa> cratliff, there are some hacks in the catkin plugin that were necessary because of catkin, when I know the issues were fixed in catkin build. If you're interested in taking a crack at that migration I'd be happy to review/test it out
<cratliff> Would having it as a separate plugin be a bad move since it isn't considered standard? The news announcement for it on ros.org seems like they think well of it at least.
<kyrofa> cratliff, might be easy to start that way. As an end user, what specifically would you notice? Just an increase in build speed?
<kyrofa> cratliff, I think the best reason to keep it as a separate plugin is probably "This package was announced in March 2015 and is still in beta. See the GitHub Milestones for the current release schedule and roadmap."
<kyrofa> If their API breaks, so does the plugin until we fix it
<kyrofa> cratliff, but I think we can make it a beta plugin, or beta mode on the catkin plugin, for now. I'd love to see it in there
<cratliff> kyrofa: An increase in speed is probably the biggest thing that would be noticeable, being able to get use out of scaling up to more cores and seeing something for it is nice.  It seems to have some more clean options.  I wonder if those could be used to make the clean step more robust as well, right now I have to clean everything for a new build.
<kyrofa> cratliff, indeed, that's something snapcraft needs to improve generally
<kyrofa> (definitely on the roadmap)
<kyrofa> cratliff, indeed, it looks like the migration from catkin_build_isolated is incredible straight-forward
<kyrofa> cratliff, is that something you're interested in doing, then?
<kyrofa> I'd be happy to help you learn the codebase/get tests running etc.
<cratliff> kyrofa, cool, I might be able to start on it next week depending on other responsibilities.  That would be great.
<kyrofa> cratliff, I'm in the PST timezone. Just ping me :)
<cratliff> kyrofa, sounds good. I'm in EST.
<kyrofa> Easy then! I look forward to working with you
<kyrofa> pedronis, can I use private snaps in a model assertion?
<kyrofa> zyga, perhaps you know? ^^
<kyrofa> noise][, status.snapcraft.io is all green, but I still can't refresh (same error)
<noise][> kyrofa: the api server is reachable but getting hammered right now, we're working on it
<jdstrand> zyga: fyi, this was pointed out to me: https://tingping.github.io/2017/05/11/flatpak-theming.html
<jdstrand> zyga: it has some grammatical issues, but the idea is interesting. flatpak has runtimes (eg, gnome2.34, gnome2.16, etc. so, you install a theme as a flatpak that targets the runtime, then every flatpak that targets that runtime gets that theme
<jdstrand> zyga: so, you install arc flatpak theme for 2.34 and 2.16 runtimes, then all flatpaks that target those runtimes gets arc. install a flatpak that target 2.10 runtime and it doesn't (until you install the arc flatpak for 2.10)
<jdstrand> zyga: it is an interesting idea. content snaps are roughly equivalent to flatpak runtimes, so it seems plausible to be able to extend a content snap with a theme snap
<jdstrand> zyga: ok, going back to other work, but thought I'd pass that along :)
<pedronis> kyrofa: yessish, but it won't refresh unless you login on the device, we don't have atm ways to open a private snapd to devices vs users, we usually use branded stores to have device-limited snaps
<kyrofa> pedronis, very good, makes sense, thank you :)
<pedronis> s/private snapd/private snap/
<mup> PR snapd#3303 closed: store: fix panic error in auth <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3303>
<Facu> sergiusens_, elopio, reading this https://forum.snapcraft.io/t/in-progress-snapcraft-2-30/347 and wondering if it should mention something about https://bugs.launchpad.net/snapcraft/+bug/1670471 or https://bugs.launchpad.net/snapcraft/+bug/1686162
<mup> Bug #1670471: Bad message after failed release <Snapcraft:Fix Committed by facundo> <https://launchpad.net/bugs/1670471>
<mup> Bug #1686162: Support "branch"es in Store responses <Snapcraft:Fix Committed by facundo> <https://launchpad.net/bugs/1686162>
<kyrofa> Hey jdstrand, seeing these on an lxc host with a guest running the nextcloud snap. Are they of concern? http://pastebin.ubuntu.com/24556341/
<kyrofa> That's during an upgrade
<kyrofa> jdstrand, and I'm hitting weird issues when upgrading (hook failures), so I'm wondering if that could be the cause
<kyrofa> jdstrand, opened this topic: https://forum.snapcraft.io/t/cannot-update-to-revision-introducing-configure-hook/556
<kyrofa> This actually might explain why other snap updates have not gone so smoothly on lxc. I always had to reboot to get it up and running
<jdstrand> kyrofa: the stdout is fixed in master and for sure in 2.26. /me checks 2.25
<jdstrand> kyrofa: yes, and 2.25
<kyrofa> jdstrand, would that explain the hook failure I'm seeing?
<jdstrand> kyrofa: that denial should be harmless. the systemctl denial would cause things to fail I suspect. it is probably trying to manage its daemon's service
<kyrofa> jdstrand, darn, so those are the weird log-missing denials I reported before, huh? So something else is happening on lxc with hooks
<kyrofa> Something weird happens when snaps update on lxc. Not sure what, though
<jdstrand> kyrofa: like I said, the stdout logging denial is fixed (that is what you reported before). but mysql.server in snap.nextcloud.mysql is clearly calling systemctl
<jdstrand> and that's a no no
<kyrofa> jdstrand, yeah I'm probably trying to stop it incorrectly, but it still seems to work fine, so also non-fatal
<jdstrand> you might mention that in the forum, since I said it could be fatal
<jdstrand> it depends on the snap, etc
<jdstrand> kyrofa: ok, I responded again just now
<Facu> sergiusens_, et al, do you know how to run snapcraft for it to show verbosely what is hitting in the server, and what the server is answering?
<kyrofa> Facu, wireshark
<kyrofa> (in seriousness, no, debug output doesn't include network exchanges)
<Facu> kyrofa, the ultimate tool, but was searching for something simpler
<Facu> kyrofa, thanks!
<kyrofa> Facu, although if you up the urllib logging you might get some
<kyrofa> Or... requests
<kyrofa> Facu, yeah, look at snapcraft/internal/log.py
<kyrofa> Facu, the requests lib was ratcheted down to INFO because it's so noisy
<kyrofa> Modify that and you should see all sorts of stuff
<Facu> kyrofa, thanks!
<zyga> jdstrand: reading
<zyga> jdstrand: interesting concept, thank you!
<mup> PR snapd#3305 closed: release: snapd 2.26 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3305>
<mup> PR snapd#3298 closed: interfaces/builtin: ensure we don't register interfaces twice <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3298>
<Pharaoh_Atem> wtf
<Pharaoh_Atem> we're now on 2.26.1?!
<zyga> Pharaoh_Atem: yep
<Pharaoh_Atem> welp
<zyga> Pharaoh_Atem: we found a but that may end up in panic so mvo did another release
<Pharaoh_Atem> due to that datacenter outage, 2.25 never got pushed fast enough to be released
<Pharaoh_Atem> so I guess I'll just yank it for 2.26.1 once morphis gives me that list of things
<zyga> Pharaoh_Atem: I don't know if the outage affected 2.25
<zyga> Pharaoh_Atem: I think we'll see 2.25.1 too
<zyga> Pharaoh_Atem: as one of the issues we found was there since 2.23
<Pharaoh_Atem> oh dear
<Pharaoh_Atem> that's not good
<zyga> Pharaoh_Atem: (but tomorrow :)
<zyga> soon :)
 * zyga pushed update to https://github.com/snapcore/snapd/pull/3295/files
<mup> PR snapd#3295: interfaces/builtin: make all interfaces private <Created by zyga> <https://github.com/snapcore/snapd/pull/3295>
<zyga> that's my scaries PR ever :)
 * Pharaoh_Atem shrugs
<Pharaoh_Atem> it's not that bad
<Pharaoh_Atem> you're just rewriting all the calls to every interface ever
<zyga> hahaha
<zyga> and tests :)
<Pharaoh_Atem> that's implied :)
<zyga> but the outcome is very positive
<Pharaoh_Atem> is it?
<Pharaoh_Atem> what does it mean?
<zyga> I found some nastiness by doing that
<zyga> I didn't finsh them today but I have some more cleanup piled up
<zyga> so that tests are better and more uniform
<zyga> I found, mostly, copy-pasted mistakes
<mup> PR snapcraft#1299 closed: asset-tracking: save the dependencies of build packages <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1299>
<mup> PR snapd#3212 closed: api, ifacestate: resolve disconnect early <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3212>
<mup> PR snapcraft#1311 opened: add missing VCS dependencies to HACKING.md <Created by felicianotech> <https://github.com/snapcore/snapcraft/pull/1311>
<mup> PR snapcraft#1303 closed: kernel plugin: slightly improve the messaging of check_config() <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1303>
#snappy 2017-05-12
<mup> PR snapcraft#1312 opened: state: fix the name of the source details <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1312>
<mup> PR snapd#3290 closed: add support for `snap install foo --channel=3.4` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3290>
<mup> PR snapd#3307 opened: tests: abstract common dirs which differ on distributions <Created by morphis> <https://github.com/snapcore/snapd/pull/3307>
<Chipaca> *yawn*
<mup> PR core#39 opened: add version-script <Created by mvo5> <https://github.com/snapcore/core/pull/39>
<mup> PR snapd#3308 opened: tests/lib: introduce pkgdb helper library <Created by morphis> <https://github.com/snapcore/snapd/pull/3308>
<Chipaca> ohhhhh
 * Chipaca figured out why so many tests failed
<Chipaca> MATCH *must* take the thing it's matching from via stdin
<Chipaca> ah well
<Chipaca> school run now, fix later
<zyga> re
<zyga> good morning
<morphis> zyga: morning!
<morphis> zyga: pushed two PRs this morning which start introducing things necessary for fedora/suse spread testing
<zyga> morphis: I saw, I'm reading one now! :)
<morphis> zyga: :-)
<zyga> morphis: commented on 3308
<pstolowski> morning
<zyga> morphis: commented on 3307 now
<zyga> o/
<zyga> pstolowski: if you remove this part of https://github.com/snapcore/snapd/pull/3282/files#r115504625 we can land that branch right away
<mup> PR snapd#3282: hooks: default timeout <Created by stolowski> <https://github.com/snapcore/snapd/pull/3282>
<zyga> pstolowski: then the extra change can be made in a separate PR
<pstolowski> zyga, the change from 5 to 10?
<zyga> pstolowski: yes
<pstolowski> zyga, ok, doing
<zyga> thank you!
<zyga> morphis: can you do a quick review of (tiny) https://github.com/snapcore/snapd/pull/3262
<mup> PR snapd#3262: cmd/snap-confine: aggregate operations holding global lock <Created by zyga> <https://github.com/snapcore/snapd/pull/3262>
<morphis> zyga: sure
<zyga> mvo: does https://github.com/snapcore/snapd/pull/3111 need more work or is that a definite +1?
<mup> PR snapd#3111: snapd: initial implementation for systemd software watchdog for snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/3111>
<morphis> zyga: replied on both PRs
<zyga> thanks
<mvo> zyga: it fails in tests currently
<mvo> zyga: in myserious ways
<mvo> zyga: let me have a look at it now
<morphis> zyga: done
<mvo> zyga: oh, looks like test-failure are gone
<mvo> zyga: strange
<zyga> morphis: replied
<zyga> mvo: I spent some time last night on gardening PRs, maybe that fixed it
<morphis> zyga: my point for the package installation barely is, when I add a new distribution I just have to edit a single file and not have to touch hundreds of test cases. If a test case needs a specific package there it should express that in a common way "netcat" and the layers below will map that correctly. The really becomes a maintenance burden. Also respect variants of distribution with different package names etc.
<zyga> morphis: that assumes that it is sufficient. My point is that it is a magic assumption that may not hold. What if you need two packages?
<zyga> morphis: I bet you will need to edit all files anyway
<morphis> why that?
<zyga> morphis: and this introduces extra layer that feels wrong
<zyga> morphis: because something may be installed by default on one distro and not in another
<morphis> zyga: I take this really like an "interface" which has different implementations
<zyga> morphis: I think there is no such thing because those packages can have different content
<zyga> morphis: (maybe not snapd but certainly true for others)
<zyga> morphis: anyway, I think another review is needed
<morphis> zyga: so if you express "netcat" and that is shipped by default the apt-get call will either do nothing or we tweak the install function to detect that an do nothing
<morphis> right now it falls back to the supplied name but we can also ignore any errors
<morphis> zyga: actually it feels wrong to me to express all these distribution specifics in the test cases we have
<morphis> zyga: but yeah, lets have another review :-)
<mvo> zyga: re the next cloud update - this only happens inside lxd apparently
<mvo> zyga: just fyi
<zyga> mvo: thanks for the hint!
<mvo> zyga: I could not reproduce on a regulra system and kyrofa also could not reproduce the nextcloud failure on a regular system, but it failed for him inside lxd. I will update the title of the post
<zyga> mvo: I honestly don't have a good feeling for lxd; I don't use it daily and we don't test it at all so there may be dragons of any sizes lurking inside
<Chipaca> TFW you're looking at a test and wondering how it ever passed before
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/3289 needs a 2nd review if you are in review mood
<mup> PR snapd#3289: daemon: do not allow to install ubuntu-core anymore <Created by mvo5> <https://github.com/snapcore/snapd/pull/3289>
<Chipaca> zyga: got a lot of MATCH-related state right now
<zyga> Chipaca: stay there then :) that branch would be great to land too :)
 * zyga -> breakfast
<mup> PR snapd#3262 closed: cmd/snap-confine: aggregate operations holding global lock <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3262>
<morphis> zyga: do you have time today to check https://github.com/snapcore/snapd/pull/3222 again?
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<zyga> morphis: yes, I certainly will; is the discussion there resolved? I recall gustavo had some questions/comments
<morphis> zyga: he didn't responded yet, will ping him as well when he comes online
<morphis> zyga: when you have a few min: https://build.opensuse.org/request/show/494796
<zyga> morphis: done, you may want to disable leap 42.1 on your branch
<morphis> zyga: yeah, this branch will be removed anyway once you merge :-)
<morphis> zyga: you had any time for the Yocto review?
<zyga> morphis: not quite, it's still open it my tab; I'll do my best to review it before the end of week today
<morphis> zyga: we're not in a hurry
<morphis> zyga: https://github.com/morphis/meta-snappy/pull/10 will only take a minute :-)
<mup> PR morphis/meta-snappy#10: snapd: update to 2.25 release <Created by morphis> <https://github.com/morphis/meta-snappy/pull/10>
<morphis> zyga: thanks!
 * zyga switches to coding mode
<Chipaca> zyga: ping
<zyga> Chipaca: yes?
<Chipaca> zyga: were you aware that in one of the tests, what used to be â! grep expr /sys/some/fileâ worked because /sys/some/file did not exist?
<zyga> nope
<zyga> Chipaca: are you uncovering a can of worms just now?
<Chipaca> zyga: /sys/fs/cgroup/devices/snap.test-snapd-tools.env/devices.list in particular
<Chipaca> zyga: should I change the test to check for nonexistance directly, or is it conceivable that the file could sometimes exist, depending on test ordering?
<zyga> Chipaca: I don't know, let me look at the test quickly
<Chipaca> zyga: main/security-device-cgroups/
<Chipaca> I think the file is removed by the cleanup, but I don't know if that is mandatory or incidental
<Chipaca> and âif [ -e /sys/yadda ]; then MATCH -v expr /sys/yadda; fiâ DTRT AFAIK
<zyga> Chipaca: that's cgroup, not a real file
<zyga> Chipaca: and I don't know how it behaves very well honestly
 * zyga looks
<Chipaca> sure looks like a file to sh :-)
<Chipaca> zyga: meh, then i'll leave the if [ -e
<zyga> sure, my point is that cleanup that removes it is whereR?
<zyga> I actually didn't read the cgroup code much
 * zyga looks
<Chipaca> zyga: in the same yaml
<Chipaca> udevadm --potato
<zyga> udev-support nees some refactoring love
<zyga> we spawn a shell for each device /o\
<zyga> Chipaca: so this looks like a layered can of worms, can you please add a FIXME there and I will get back to it
<zyga> this code has not changed at all since ubuntu-app-launcher
<zyga> and that particular test was written by jdstrand
<Chipaca> zyga:     # FIXME: this is, apparently, a layered can of worms. Zyga says he needs to fix it.
<Chipaca> zyga: (or tell me what to put so you remember)
<zyga> so I need to look at it for some time before I can make heads or tails
<zyga> Chipaca: yes, that's fine :)
<morphis> ogra_: what is the state on https://bugs.launchpad.net/snappy/+bug/1650688 ?
<mup> Bug #1650688: timedatectl set-timezone fails on UC16 <hwe> <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1650688>
<ogra_> morphis, well, i'm not sure mvo's suggestion will work (symlinking a bind-mount) ...
<zyga> ogra_: symlinking a bind mount?
<morphis> ogra_: just wondering as it was set to be fixed for 2.25 and we now released 2.26 and it is still not fixed and two customers are already asking for it
<ogra_> morphis, i guess what could work is to patch systemd to not handle it as link at all and write the data into it ...
<ogra_> zyga, https://bugs.launchpad.net/snappy/+bug/1650688/comments/25
<mup> Bug #1650688: timedatectl set-timezone fails on UC16 <hwe> <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1650688>
<morphis> ogra_: so what prevents us from patching systemd?
<ogra_> having to carry that patch ...
<ogra_> we're just at the point where we can drop systemd from the PPA
<morphis> something we could sent upstream?
<ogra_> (having it there caused quite some probs regarding libusb (there is a fixed version dependency)
<morphis> ogra_: yeah, ran into that problem multiple times
<ogra_> morphis, right, it must either be upstreamable or at least suitable for a distro patch we can hand to foundations
<morphis> ogra_: argument for distro patch would be already that Ubuntu Core is a first class citizen in our ecosystem, isn't it?
<ogra_> yes, but it must still be suitable :)
<morphis> sure, so what is the plan, get it fixed for 2.27?
<ogra_> we can work towards that, yeah
<morphis> just saying, we should fix it by 2.27, this is now delayed for two releases ..
<ogra_> right
<Chipaca> so, there's an important difference between "grep foo | wc -l" and "grep -c foo"
<ogra_> morphis, mvo .... oooh ... http://paste.ubuntu.com/24559979/ we already carry a patch, i guess we just need to adjust it
<mup> PR snapd#3309 opened: interfaces/mount: keep track of kept mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3309>
<mup> PR snapd#3310 opened: interfaces/mount: spell unmount correctly <Created by zyga> <https://github.com/snapcore/snapd/pull/3310>
<Chipaca> ogra_: âForwarded: OMGno, this is a rather nasty hack until we fix system-image to get a writable /etcâ
 * Chipaca giggles
<ogra_> Chipaca, well :)
<ogra_> the point is that we have a patch and it doesnt seem to work ....
<mup> PR core#39 closed: add version-script <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/core/pull/39>
<zyga> mvo: I just merged the version script, cannot wait to see this in snap list!
<ogra_> and i think the reason is:
<ogra_> 96         if (r >= 0 && startswith(realfile, "/etc/writable")) {
<ogra_> because ...
<ogra_> ogra@pi3:~$ ls -l /etc/localtime
<ogra_> lrwxrwxrwx 1 root root 18 May 12 04:20 /etc/localtime -> writable/localtime
<ogra_> it looks for an absolute name
<Chipaca> ogra_: what package is that patch for btw?
<ogra_> systemd
<Chipaca> ah
<Chipaca> ogra_: note that the filename is passed through readlink_and_make_absolute first
 * Chipaca looks at how that one works
<ogra_> yes, i''m just digging into that ... it calls readlinkat() in the end
<Chipaca> ogra_: maybe it should be changed to readlink_and_canonicalize?
<ogra_> because that calls chase_symlinks() ?
<ogra_> i have the feeling just making the link itself absolute would be sufficient
<ogra_> funnily the subsequent link *is* absolute
<ogra_> ogra@pi3:~$ ls -l /etc/writable/localtime
<ogra_> lrwxrwxrwx 1 root root 27 May 11 06:35 /etc/writable/localtime -> /usr/share/zoneinfo/Etc/UTC
<Chipaca> ah, fair enough
<ogra_> https://github.com/snapcore/core/blob/master/live-build/hooks/08-etc-writable.chroot#L14
<mup> PR core#40 opened: make links to /etc/writable absolute <Created by ogra1> <https://github.com/snapcore/core/pull/40>
<ogra_> :)
 * zyga requests a review for one-liner https://github.com/snapcore/snapd/pull/3310/files
<mup> PR snapd#3310: interfaces/mount: spell unmount correctly <Created by zyga> <https://github.com/snapcore/snapd/pull/3310>
<zyga> pstolowski: I think you could review this quickly https://github.com/snapcore/snapd/pull/3309/files
<mup> PR snapd#3309: interfaces/mount: keep track of kept mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3309>
<mup> PR snapd#3311 opened: difs,interfaces/mount: add support for locking namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3311>
<pstolowski> k
<zyga> mvo: and this is for you (no C :) https://github.com/snapcore/snapd/pull/3311/files
<mup> PR snapd#3311: difs,interfaces/mount: add support for locking namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3311>
<pstolowski> i'm not sure what's going on with travis test on my #3282.. seems to be infra issue:
<pstolowski> Error preparing linode:ubuntu-core-16-64:tests/regression/ : kill-timeout reached, cannot reconnect to linode:ubuntu-core-16-64 (Spread-15) after reboot: dial tcp 96.126.110.77:22: i/o timeout
<mup> PR snapd#3209 closed: interfaces/mount: add partial implementation of Change.Needed <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3209>
<zyga> pstolowski: I:m looking too
<zyga> just restarted
<zyga> ogra_: question about https://github.com/snapcore/core/pull/40 -- why were those relative in the first place?
<mup> PR core#40: make links to /etc/writable absolute <Created by ogra1> <https://github.com/snapcore/core/pull/40>
<pstolowski> zyga, I restarted it an hour ago.. with smiliar failure again
<ogra_> zyga, i have not idea :)
<ogra_> zyga, that patch came originally from pitti irc
<zyga> ogra_: maybe he remembers, could you ask him?
<zyga> ogra_: just in case we're missing something magic
<ogra_> zyga,  but i assume because he expectes readlink_and_make_absolute() to read a link and make it absolute :P
 * zyga hates expect tests :(
<ogra_> *expected
 * zyga goes for lunch and small break
<ogra_> zyga, i'm just ruling out the potential that it doesnt with this change ...
<ogra_> there is no guarantee it fixes anything
<ogra_> and it wont do any harm either (nothing else cares if the link is relative or absolute)
<zyga> fgimenez:     - linode:ubuntu-16.04-64:tests/main/interfaces-openvswitch failed here: https://travis-ci.org/snapcore/snapd/builds/231504228?utm_source=github_status&utm_medium=notification
<zyga> fgimenez: there's no good information there
<zyga> fgimenez: do you know if that is a massive package that has lots of IO during installation?
<mup> PR core#40 closed: make links to /etc/writable absolute <Created by ogra1> <Merged by ogra1> <https://github.com/snapcore/core/pull/40>
<fgimenez> zyga: i don't think so according to https://travis-ci.org/snapcore/snapd/builds/231504228#L3487 it is just 1820kb
<fgimenez> zyga: thanks a lot, i didn't have luck trying to reproduce, will try again
<zyga> fgimenez: it's just random, I don't know if the cause is the same
<fgimenez> zyga: ok, now with the seed it may be easier to confirm/discard the ordering cause, let's see
<zyga> note that it died on timeout so we don't really know what happened :/
<zyga> Chipaca: do you know MATCH sometimes works with an argument?
<zyga> Chipaca: could it be something as silly as missing -- ?
<Chipaca> zyga: stdin handling in that shell might be wonky
<Chipaca> zyga: like, if you do a match, the second match finds stdin closed (and so reads the args)
<Chipaca> that's an unproven hypothesis right now
<Chipaca> but you asked :-)
<zyga> thanks
<Chipaca> zyga: also, note grep always reads the args
<zyga> I think we should grok this, we rely on match too much :)
<Chipaca> the problem is that MATCH uses 'cat' to read stdin unconditionally
<Chipaca> so if cat is not connected, it hangs
<Chipaca> if cat is closed, it doesn't hang
<Chipaca> i mean if stdin is closed
<Chipaca> because cat returns immediately
<Chipaca> zyga: makes sense?
<Chipaca> needs testing but makes sense to me :-)
<zyga> mhm
 * zyga would like to see MATCH in C
<Chipaca> wat
<Chipaca> no dude
<Chipaca> i mean, it can be improved, sure
<pstolowski> #3282 failed again, this time on create-key test
<Chipaca> and probably should be, but "write it in c" is a whole new class of pain
<Chipaca> zyga: my pet peeve with it right now is that sometimes we really need the expressiveness of pcre, but we're stuck with -E
<Chipaca> this stdin is just a quirk
<Chipaca> (compared to that)
<zyga> me nods
<Chipaca> heh, somebody kicked off the test suite again
<Chipaca> but i'm working through the bugs :-)
<Chipaca> (just took me a bit because i didn't have a 32-bit image for local qemu)
<zyga> Chipaca: spread.zygoon.pl
<zyga> :D
<Chipaca> zyga: 1205993472 bytes transferred in 451 seconds (2.55 MiB/s)
<Chipaca> my network is lazy today
<zyga> lazy as in slow?
<zyga> my network is never this fast
<Chipaca> yeah, it should be about 4 times that
<Chipaca> (on paper i mean; in practice it's usually 2x)
<zyga> heh
<zyga> so my one character change PR keeps failing
<zyga> snap-sign this time
<zyga> because expect sucks :/
<zyga> what I find surprising is that travis fails way way more often than autopkgtests
<zyga> I wonder why that may be
<zyga> since the infra is actually dedicated, not shared
<zyga> I wonder if I should merge the private-interfaces branch now
<zyga> (now == just after release) :)
<Chipaca> zyga: which is your one character change PR?
<zyga> https://github.com/snapcore/snapd/pull/3310
<mup> PR snapd#3310: interfaces/mount: spell unmount correctly <Created by zyga> <https://github.com/snapcore/snapd/pull/3310>
<Chipaca> aw, i wanted to see the expect failure
<zyga> Chipaca: just killed by timeout
<Chipaca> zyga: expect timeout is how expect fails, always
<Chipaca> it times out waiting for a match
<Chipaca> (well, it can also fail with a syntax error :-) )
<Facu> sergiusens_, elopio, reading this https://forum.snapcraft.io/t/in-progress-snapcraft-2-30/347 and wondering if it should mention something about https://bugs.launchpad.net/snapcraft/+bug/1670471 or https://bugs.launchpad.net/snapcraft/+bug/1686162
<mup> Bug #1670471: Bad message after failed release <Snapcraft:Fix Committed by facundo> <https://launchpad.net/bugs/1670471>
<mup> Bug #1686162: Support "branch"es in Store responses <Snapcraft:Fix Committed by facundo> <https://launchpad.net/bugs/1686162>
<jdstrand> zyga, Chipaca: iirc, once a cgroup is setup the dirs and files stay until after a reboot. I recall trying to cleanup but being unable to. aiui, all you can do is reset the cgroup but the files are still there. it's possible there is a way that I didn't find
<zyga> jdstrand: interesting, I will look into this after working on namespaces
<pedronis> mvo: hi, IÂ updated the forum entry about the repair assertion to match the state of your branch
<mvo> pedronis: thank you very much
<Chipaca> man, tests/main/interfaces-openvswitch needs to be hacked into shape
<Chipaca> it takes _ages_
<Chipaca> (to the point that it often times out entirely)
<zyga> Chipaca: yep
<Chipaca> in _prepare_
 * Chipaca looks
<mup> PR core#41 opened: limit the version string to 32chars (this is what the store allows) <Created by mvo5> <https://github.com/snapcore/core/pull/41>
<zyga> Chipaca: apt-get install
<Chipaca> zyga: maybe it's just that the base prepare takes ages
<Chipaca> and this will push it over the edge
<Chipaca> zyga: because that apt-get got the stuff in 0s
<Chipaca> then, sure, it needs to dance the install dance
<Chipaca> but, we probably should bump the prepare timeout overall if it's this close
<zyga> can we do that for a particular test case?
<mvo> pedronis: also thanks a bunch for your review, I will add the missing test now
<Chipaca> zyga: yes
<Chipaca> niemeyer: is kill-timeout for the whole test, or separately for prepare and execute?
<niemeyer> Yo
<niemeyer> Chipaca: for each script individually
<Chipaca> niemeyer: and prepare and execute are scripts?
<Chipaca> niemeyer: hello! good morning :-)
<ogra_> mvo, so that rsyslog removal ...
<ogra_> mvo, any opinion yet ?
<Chipaca> huh, another test that was psasing who-knows-how
<zyga> ogra_, mvo: tests broken because of the version script on core snap
<zyga> mvo: specifically tests/main/listing
<kyleN> hi ara
<Chipaca> mvo: fgimenez: question about tests/main/ubuntu-core-create-user
<zyga> hmm
<zyga> or maybe not?
<Chipaca> mvo: fgimenez: the test currently purports to check that the output of create-user on a managed device (without the --force-managed flag) is âerror: while creating user: cannot create user "nosuchuser@example.com"â
<Chipaca> mvo: fgimenez: but that's not the output from that command (and it hasn't been that for a while)
<Chipaca> I don't pretend to understand how this test passed in the past
<Chipaca> but i want to know if the current message is what it should be, in which case i will make the test check for that
<Chipaca> and if it ins't, i'll fix the message
<Chipaca> mvo: fgimenez for the record the message currently is âerror: while creating user: cannot create user: device already managedâ
<MrGeneral> howdy
<MrGeneral> Is it possible to run snap @ debian jessie?
<zyga> MrGeneral: hello
<zyga> ah standup time
 * zyga never remembers debian codenames
<zyga> testing is OK
<MrGeneral> All good.
<zyga> before is too old
<MrGeneral> hmhm I see
<MrGeneral> so I need to enable testing I guess.
<MrGeneral> too old?
<MrGeneral> hmhm
<pedronis> Chipaca: the test is wrong it seems, it should try the wrong user before it sets up a real one
<pedronis> Chipaca: IÂ mean it seems to be mixing up failure modes
<zyga> MrGeneral: yes, kernel and systemd and perhaps something else
<fgimenez> Chipaca: something is indeed wrong there, is a "$" missing https://github.com/snapcore/snapd/blob/master/tests/main/ubuntu-core-create-user/task.yaml#L39 ?
<Chipaca> fgimenez: hah!
<Chipaca> omg
<Chipaca> fgimenez: yes, that is missing a $, but, even that does not fail
<Chipaca> fgimenez: it never reaches there
<Chipaca> fgimenez: (or if it reaches, it isn't enough to time out)
<Chipaca> to error out I mean
<mup> PR snapd#3312 opened: DO NOT MERGE YET: add coveralls.io integration <Created by mvo5> <https://github.com/snapcore/snapd/pull/3312>
<MrGeneral> Got it, thank you zyga :)
<mup> PR snapd#3312 closed: DO NOT MERGE YET: add coveralls.io integration <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3312>
<mup> PR snapcraft#1305 closed: Use architectures field which existed in older LXD <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1305>
<mup> PR snapd#3313 opened: send things to codecov.io <Created by mvo5> <https://github.com/snapcore/snapd/pull/3313>
<mup> PR snapcraft#1249 closed: Add Linux Mint support <Created by nefelim> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1249>
<ogra_> morphis, do we have any snap that uses the timedatectl dbus call that i could use to test https://bugs.launchpad.net/snappy/+bug/1650688 ?
<mup> Bug #1650688: timedatectl set-timezone fails on UC16 <hwe> <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1650688>
<ogra_> calling it locally will not use dbus but directly call the tool whihc works fine
<morphis> ogra_: not really
<ogra_> i'm pretty sure the missing line for /etc/localtime in the interface will also have some effect here
<mup> PR snapcraft#1306 closed: recording: record global build-packages installed on the host <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1306>
<mup> PR snapd#3314 opened: tests: allow 16-X.Y.Z version of core snap <Created by zyga> <https://github.com/snapcore/snapd/pull/3314>
<mup> PR snapd#3315 opened: rename host's http proxy env vars <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3315>
<mup> PR snapd#3316 opened: make /etc/localtime writable in timezone_control <Created by ogra1> <https://github.com/snapcore/snapd/pull/3316>
<morphis> ogra_: I got a basic qemu snap going which gives me latest git with raspi2 machine and got the kernel from the pi2-kernel snap booting
<morphis> ogra_: however didn't got uboot started yet and because of that the kernel fails to find its rootfs
<ogra_> push it to edge .... happy to poke at it
<diddledan> what is that error supposed to mean?: [Error 21] Is a directory: '/build_corebird/prime/usr/lib/locale' <-- I told it I wanted 'usr/lib/locale' in the prime section of my yaml
<ogra_> jdstrand, i'd appreciate a review of https://github.com/snapcore/snapd/pull/3316
<mup> PR snapd#3316: make /etc/localtime writable in timezone_control <Created by ogra1> <https://github.com/snapcore/snapd/pull/3316>
<mup> PR core#41 closed: limit the version string to 32chars (this is what the store allows) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/41>
<zyga> mvo: can you review https://github.com/snapcore/snapd/pull/3314 to unbreak master
<mup> PR snapd#3314: tests: allow 16-X.Y.Z version of core snap <Created by zyga> <https://github.com/snapcore/snapd/pull/3314>
<pedronis> niemeyer: this is the first issue(s) about auto-connect to address right? https://forum.snapcraft.io/t/what-should-the-auto-connect-logic-be-like/312
<zyga> pedronis: one thing that is perhaps related is that I want to add a small tweak to interfaces to give them a way to share more meta-data
<zyga> pedronis: we could then share more useful things, like auto-connect 1-no-N flags or anything else we need internally
<zyga> pedronis: (and useful things like human readable descriptions we just keep as code comments)
<ogra_> niemeyer, in case you feel like reading it https://lists.ubuntu.com/archives/ubuntu-devel/2017-January/039634.html ... (for a boring afternoon or so)
<ogra_> niemeyer, thats the discussion about dropping syslog from the distro
<niemeyer> ogra_: Can you please mention that in the forum thread? It's good background.
<ogra_> yep
<niemeyer> pedronis: Yeah
<Chipaca> looks like we ran out of travis coin
<pedronis> zyga: that's interesting but as niemeyer says on the forum, I think we should start fixing the initial bug before adding stuff
<niemeyer> Chipaca?
<zyga> pedronis: yes, as I said it's not directly related (my motivation is to get the user visible interface descriptions available in the API) but once we have a hold of the problem and know what to do it may be a handy mechanism
<pedronis> at the moment all auto-connecting interfaces are 1-to-N afaik
<pedronis> IÂ mean from slot (1) to plugs (N)
<mup> PR snapd#3317 opened: many: start implenting "base" snap type on the snapd side <Created by mvo5> <https://github.com/snapcore/snapd/pull/3317>
<zyga> pedronis: perhaps
<zyga> pedronis: things like gpio and other hardware might not be
<zyga> (it may be but might not be)
<zyga> we need to land https://github.com/snapcore/snapd/pull/3314 to fix master
<mup> PR snapd#3314: tests: allow 16-X.Y.Z version of core snap <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/3314>
<zyga> please review
 * zyga just lands it
<mup> PR snapd#3314 closed: tests: allow 16-X.Y.Z version of core snap <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3314>
<ogra_> niemeyer, hmm, is there a way that a non-creator of a topic could set a category in discourse (perhaps via a config option) ...
<ogra_> niemeyer, i.e. https://forum.snapcraft.io/t/3g-usb-modems-compatible-with-modem-manager-snap-on-ubuntu-core/582 would fit into "device" but the original creator didnt set it ... would be a cool feature if others could add a category in that case
<pedronis> ogra_: let me see
<mvo> zyga: nice one, thank you
<pedronis> ogra_: done
<pedronis> ogra_: I can change categories, it's one of those things discourse grants after some use afaict
<ogra_> pedronis, oh
<pedronis> part of one of the badges
 * ogra_ thought he did earn enough badges yet ... seems not :P
<pedronis> ogra_: I got it with "Regular"
<pedronis> you should have it too
<pedronis> afaict
<pedronis> https://forum.snapcraft.io/badges/3/regular
<zyga> mvo: OK to land https://github.com/snapcore/snapd/pull/3295 ?
<mup> PR snapd#3295: interfaces/builtin: make all interfaces private <Created by zyga> <https://github.com/snapcore/snapd/pull/3295>
<pedronis> ogra_:  "You can now recategorize and rename topics..."
<niemeyer> ogra_: Yeah, moderators can do it
<pedronis> niemeyer: also Regulars
<niemeyer> pedronis: Ah, indeed!
<niemeyer> discourse++
<pedronis> ogra_: click the pencil on the right of topic titles
<ogra_> oh man
<ogra_> yeah, i can
<diddledan> how do I get snapcraft to prime a directory? it's complaining that: [Error 21] Is a directory: 'path I want included'
<ogra_> it didnt strike me that i need to edit the headline for it
<pedronis> you should click all that is shiny :)
<morphis> ogra_: can we change https://bugs.launchpad.net/snappy/+bug/1650688 to be in-progress?
<mup> Bug #1650688: timedatectl set-timezone fails on UC16 <hwe> <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1650688>
<ogra_> diddledan, catching the snapcraft guys might be easier on rocket.ubuntu.com
<ogra_> morphis, done
<morphis> ogra_: thanks
<morphis> niemeyer: you have time to have another look on https://github.com/snapcore/snapd/pull/3222 today?
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<diddledan> really? why have they moved over therE?!
<niemeyer> morphis: Yeah
<diddledan> I hate this replacing with shiny just because
<pedronis> morphis: the icon here seems broken (or a cache issue?):  https://forum.snapcraft.io/badges/101/fedora
<morphis> niemeyer: thanks!
<diddledan> there wasn't anything wrong with IRC! </rant>
<morphis> pedronis: hm, didn't created that badge so not sure where it takes the icon from
<morphis> niemeyer: ^^
<morphis> pedronis: https://snapforum.s3.amazonaws.com/original/1X/bfb1e013ef4b1f1276a1ca3d38a40a789a056bb8.png -> doesn't exist ..
<niemeyer> Wow.. strange
<niemeyer> Let me check that
<ogra_> diddledan, nobody says there is anything wrong with it (and they are still idling here but probably dont check it as often as rocket)
<niemeyer> Apparently I screwed up by removing a reference to the image, and Discourse is smarter than I expected and removed the image that had no references
<niemeyer> morphis: Fixed, thanks for the note
<niemeyer> pedronis: ^
<pedronis> thx
<pedronis> IÂ just noticed because I went to the badges page
 * niemeyer => lunch
<pedronis> niemeyer: we should remember to remove upcoming from stuff that is done (I think you listed that in the process post)
<pedronis> mvo: Chipaca: is this resolved  https://forum.snapcraft.io/t/hashsum-failures-during-tests/198 ?
<Chipaca> I don't think so
<pedronis> niemeyer: mvo: I removed the "upcoming" tag from some stuff that was done
<morphis> pedronis: are you planing to solve and implement https://forum.snapcraft.io/t/gadget-snap-config-defaults-dont-work/409/4  for 2.27?
<pedronis> morphis: yes (https://forum.snapcraft.io/t/next-snapd-2-27/572 )
<pedronis> morphis: have a plan, should have PR(s) on Mon or Tue
<morphis> pedronis: awesome!
<pstolowski> pedronis, do you know from top of your head where do we create 'update-aliases' task? for some reason I can only find it in tests... but not where it's created
<niemeyer> pedronis: +1
<niemeyer> pedronis: Thanks for cleaning it up
<pstolowski> 2017-05-12 15:40:57 Failed tasks: 1
<pstolowski>     - linode:ubuntu-16.04-32:tests/main/create-key
<pstolowski> 2017-05-12 15:40:57 Failed task prepare: 1
<pstolowski>     - linode:ubuntu-16.04-32:tests/main/completion
<pstolowski> #3282 failed again ^ ...
<pedronis> pstolowski: there is no such task
<pedronis> pstolowski: aliasesv2.go has a comment listing all the aliases tasks
<pedronis> pstolowski: why the question?
<pedronis> pstolowski: ah, update-aliases, it's a backend operation, not a task
<pstolowski> pedronis, cause I unexpectedly get this in of the my failing tests; and grepping master gives a bunch of those..
<pedronis> lots of aliases tasks end up creating those
<pedronis> pstolowski: I fear I need to see the test to help
<pedronis> pstolowski: anyway under normal circucmstances (refresh/install etc) it comes from setup-aliases
<pstolowski> pedronis, i see. thanks
<pedronis> also I misremembered the comment listing tasks is in handlers.go
<mup> PR snapcraft#1313 opened: Meta: Version from deb <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1313>
<zyga> 2017-05-12 16:53:57 Cannot allocate linode:ubuntu-16.04-64: cannot create Linode disk with ubuntu-16.04-64: you do not have enough unallocated storage to create this Disk (608 requested, but only 0 available)
<niemeyer> Fixed.. that was Spread-06 FWIW
<niemeyer> All others are clean
<mup> PR snapd#3295 closed: interfaces/builtin: make all interfaces private <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3295>
<mup> PR snapd#3310 closed: interfaces/mount: spell unmount correctly <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3310>
<mup> PR snapcraft#1314 opened: catkin plugin: add support for rosinstall files <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1314>
<nacc> sigh, i think i've found a relatively serious issue with the store, on a friday :)
<nacc> oh nm, it's a bug in my snapcraft.yaml in the process of renaming a snap
<nacc> it does feel like the store should not try to cross-build/upload snaps: https://launchpad.net/~nacc/+snap/git-ubuntu/+build/37953
<nacc> snap is git-ubuntu, but the generated snap is usd-nacc, and yet it tried to upload it :)
<nacc> hrm, but it does seem like lp is a bit confused: https://launchpad.net/~nacc/+snap/git-ubuntu/+build/37953
<nacc> the 'manage this package in the store' url ends up pointing to the wrong snap (the one built, admittedly)
#snappy 2017-05-13
<mup> PR snapd#3306 closed: tests/main: move a bunch of greps over to MATCH <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3306>
<mup> PR snapcraft#1315 opened: lxd: Mock platform in FakeLXD fixture <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1315>
<mup> PR snapcraft#1316 opened: Run unit tests on Travis with mock armhf <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1316>
<mup> PR snapd#3318 opened: overlord/snapstate: Enable() was ignoring the flags from the snap's <Created by chipaca> <https://github.com/snapcore/snapd/pull/3318>
<mup> Bug #1667385 changed: devmode flag disappears after disabling+re-enabling a snap <snapd:In Progress by chipaca> <https://launchpad.net/bugs/1667385>
<mup> Bug #1669477 changed: Snap installed as devmode can end up running confined <snapd:New> <https://launchpad.net/bugs/1669477>
<mup> PR snapd#3309 closed: interfaces/mount: keep track of kept mount entries <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3309>
#snappy 2017-05-14
<mup> PR snapcraft#1317 opened: recording: save the details of the source pulled <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1317>
<boriseto> Why does this happen: snap "ubuntu-make" requires classic or confinement override ?
<ali1234> because all it does is install other things and it can't do that while confined
<immu> hi
<immu> my hexchat snap keeps freezing and will go dark
<immu> can some one tell me why does my hexchat snappy keeps freezing??
<immu__> <immu> can some one tell me why does my hexchat snappy keeps freezing??
<Chipaca> immu__: I don't know. When you say "my", do you mean you're the developer of that snap?
<Chipaca> immu__: or do you mean you installed it?
<immu__> i installed it Chipaca
<Chipaca> immu__: it might be a buggy snap? maybe improperly confined, or maybe it has interfaces that need manual connection
<Chipaca> give me a moment i'll see if i can instlal it
<Chipaca> Chipaca: hello
<Chipakeitor> immu, seems to work here
<Chipakeitor> immu, when does it hang?
<Chipakeitor> immu__, ^
<Chipaca> immu__: one thing that _might_ be making it hang is that it asks to use the "dbus" interface, but as that's very general you need to connect it by hand (and if you do, and hexchat were eevil, they could do nasty things to your system)
<Chipakeitor> immu__, yeah, what Chipaca said
<Chipakeitor> that guy is so knowledgable it's amazing
<Chipakeitor> I'm going to go make him a pizza, that's how awesome he is
<Chipaca> mmmmm pizza
<ali1234> didnt someone already package hexchat?
<Chipaca> ali1234: yes, immu is using it
<Chipaca> ali1234: and it hangs
<ali1234> oh okay
<Chipaca> for him (not for me so far)
<Chipaca> I mean ... er .. not for Chipakeitor here
<Chipaca> anyway, i'm off to make myself some pizza
<immu__> so Chipaca i removed snap hexchat and went for normal using synaptic
<Chipaca> immu__: Â¯\_(ã)_/Â¯
<immu__> and now i am here talking to you in the same software but unsnapped
<immu__> Chipaca,  :)
<ali1234> what's the best URL to give to people that explains "what is snap"?
<immu__> wait
<immu__> ali1234, https://www.ubuntu.com/desktop/snappy
<immu__> https://snapcraft.io/
<immu__> Chipaca, so u there?
#snappy 2018-05-07
<cjwatson> mcphail: snapcraft's README.md refers to the Launchpad one
<mborzecki> morning
<mborzecki> mvo: hey, how are things?
<zyga> Good morning
<mborzecki> zyga: hey
<mborzecki> zyga: i see we made it to 2.32.6
<mvo> hey zyga and mborzecki !
<mborzecki> mvo: morning
<mborzecki> mvo: how was the sprint?
 * zyga -> walk
<mvo> mborzecki: it was good
<mvo> mborzecki: no surprises, focus for the next couple of weeks is making core18 bootable and working on the upgrade path
<mborzecki> mvo: any updates to the roadmap then?
<mvo> mborzecki: but we knew that :)
<mvo> mborzecki: nothing new in the roadmap I think
<mvo> mborzecki: we will need to do a .7 to fix an important usecase (two PRs up for that already)
<mvo> mborzecki: and then we are hopefully fully back to 2.33
<zyga> Oh
<zyga> What is for .7?
<mborzecki> hm and i thought we were done with .6 :)
<mvo> zyga: a systemd target for when the system is fully seeded
<mvo> zyga: and a way for snaps to declare an "after: snapd.seeded"
<mvo> zyga: it is important for some 18.04 cloud image use-cases
<mvo> mborzecki: I thought so too :) but then reality disagreeded
<mvo> I think its pretty straightforward, it will need a design ACK from gustavo though
<zyga> I See
<mborzecki> mvo: a target taget? as in snapd.seeded.target?
<mvo> mborzecki: correct
<mvo> mborzecki: so that a unit can say "after=snapd.seeded.service"
<mvo> mborzecki: there is a PR up for this (5124) but it was written during the sprint so an extra careful review is needed :)
<mvo> the other one is 5132 and we will need 5133 for cosmic
<mup> PR snapd#5136 opened: tests: ubuntu 18.04 or higher does not need linux-image-extra- <Created by mvo5> <https://github.com/snapcore/snapd/pull/5136>
<mup> PR snapd#5128 closed: Revert "Skip test lp-1721518 for arch, snapd is failing to start afteâ¦ <Simple> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5128>
<mup> PR snapd#5121 closed: interfaces:minor autoconnect cleanup <Simple> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5121>
<mup> PR snapd#5069 closed: configcore: validate experimental.layouts option <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5069>
 * zyga is back home and working now
<zyga> my whole desk was covered with yellow powder
<zyga> something must be blooming nearby
<zyga> yuck
 * zyga catches up with email
<zyga> mvo: please ping me if something urgent is needed, I will start hacking at around noon, I need to get my inbox under control
<mvo> zyga: I will focus on .7 this morning and trying to make sure autopkgtests and spread is happy
<mvo> zyga: 5131 needs a second review but its pretty trivial and can probably go in with a single review even
<mvo> zyga: I got this error in one of my PRs so it might be a prereq for landing the 2.32 ones
<zyga> mvo: FYI, I think there's a real error that affects debian
<zyga> mvo: but it's rare
<zyga> mvo: if you see a network-bind or network test fail there, that's it
<zyga> it looks like we become unconfined in some situations
<mup> PR snapd#5136 closed: tests: ubuntu 18.04 or higher does not need linux-image-extra- <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5136>
<zyga> mvo: btw, do you know what is cosmic?
<zyga> cosmic ... c-what?
<mvo> zyga: I don't
<mborzecki> zyga: canimal?
<mvo> zyga: cockroach maybe
<zyga> mborzecki: no :)
<mvo> or maybe canibal
<mborzecki> haha
<mborzecki> canibal cockroach
<mborzecki> sounds like a great name for a death metal band ;)
<mvo> lol
<zyga> cosmic cosmonaut would be nice
<zyga> humans are animals too
<mvo> I like cosmonaut!
<pstolowski> mornings!
<mvo> hey pstolowski good morning and welcome back
<pstolowski> how was the sprint?
<mborzecki> pstolowski: morning
<zyga> good morning pawel
<mvo> pstolowski: good, no surprises, roadmap is pretty much what we discussed already
<mborzecki> arch package bumped to 2.32.6
<mborzecki> and wow, we have quite a lot of open PRs
<mup> PR snapd#5135 closed: Docs moved to forum <Created by abitrolly> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5135>
<mborzecki> need coffee
<mup> PR snapd#5133 closed: spread.yaml: add cosmic (18.10) to autopkgtest/qemu <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5133>
<mborzecki> zyga: regarding #1769203, haven't we looked at auto mounting snaps via .automount unit files?
<mup> Bug #1769203: every revision of snaps are mounted <amd64> <apport-bug> <bionic> <wayland-session> <snapd (Ubuntu):Invalid> <https://launchpad.net/bugs/1769203>
<zyga> mborzecki: I mentioned this and I think gustavo was sceptical about it
<mborzecki> zyga: do you recall what was his reasoning?
<mvo> mborzecki: we did use automount a long time ago, it may even be in the git history (a looooong time ago, very early days of the project)
<zyga> mborzecki: that it is not fully transparent
<zyga> mborzecki: you can observe automount points
<zyga> mborzecki: you can unmount them to break them
<mvo> zyga: hm, unmount them to break them is also true for .mount services, no?
<mup> PR snapd#5131 closed: tests: fix interfaces-network test for systems with partial confinement <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5131>
<zyga> mvo: are we pushing .6 to stable
<pstolowski> zyga: is there any concern still about https://github.com/snapcore/snapd/pull/5075 ?
<mup> PR #5075: snap/env: fix env duplication logic <Simple> <Created by didrocks> <https://github.com/snapcore/snapd/pull/5075>
<mvo> zyga: yes, today when cachio is around (probably after the standup
<zyga> mvo: brilliant
<mvo> zyga: is there any work to make 2.32 tested again that I can build upon? or just go over the master PRs and cherry-pick the right stuff?
<mvo> btw, a review for 5132 would be great. it need a final +1 from niemeyer to ensure he is happy with the language but beside that it should be ready for review
<zyga> doing
<mvo> ta
<zyga> mvo: done
<mvo> ta
<mup> PR snapd#5137 opened: tests: cherry-pick commits to move spread to google backend <Created by mvo5> <https://github.com/snapcore/snapd/pull/5137>
<zyga> hmmmmm
<zyga> mvo: I have a debian 10 vm with two snaps but no core
 * zyga wonders how that happened
<zyga> snap changes from debian 10 https://www.irccloud.com/pastebin/oU28h1jS/
 * mvo hugs mborzecki and zyga for the excellent review in 5131
<mvo> zyga: strange, what version of snapd is running?
<zyga> 2.30
<zyga> 3.30-5+b1
<zyga> mwhudson: hey
<zyga> mwhudson: not super urgent but it would be good to update snapd in debian to 2.32.6 or .7
<zyga> mwhudson: also (as before) not sure how to maintain this package
<zyga> mwhudson: what is the process for doing a new release? merge upstream and massage?
<mvo> we should also check if re-exec is enabled
<mvo> yay, cosmic autopkgtest for ppc64/s390x is green
<zyga> mborzecki: are you running arch or ubuntu now
<zyga> mborzecki: I may need your help
<mborzecki> arch
<mborzecki> zyga: what do you need help with?
<mup> Bug #1593141 changed: Each run of a snap app leak directories in /tmp <snapd:Fix Released> <https://launchpad.net/bugs/1593141>
<zyga> mborzecki: there's a bug, I cannot find it now
<zyga> maybe on the forum, maybe on laucnhpad
<zyga> it relates to this call
<mup> PR snapd#5137 closed: tests: cherry-pick commits to move spread to google backend <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5137>
<zyga> https://www.irccloud.com/pastebin/Wygky688/
<zyga> someone got a denial on that
<zyga> I wonder if the "none" is significant
<zyga> can you see if you got that denial?
 * zyga boots 18.04 live usb to test something else
<zyga> wow, I didn't know there are so many snaps on the live ISO
<mborzecki> zyga: ok, let me sync some stuff first
<zyga> mborzecki: thanks
<zyga> snap list truncates "tracking" too much
<mup> PR snapd#5129 closed: cmd/snap-confine: allow any base snap to provide /etc/alternatives <Simple> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5129>
<zyga> mvo: thank you
<zyga> mvo: I was working on a new base snap last weekend
<zyga> mvo: I ran into a serious bug, I didn't manage to debug it yet though
<mvo> zyga: oh? ok - anything you can share?
<mvo> zyga: what was the error etc?
<zyga> mvo: snaps based on that snap didn't start at all, something wrong in the deep guts of snap-confine
<zyga> I didn't get to the bottom of it, I can share later today if you want to play
<zyga> some issues from the live ISO
<zyga> failed refresh on live iso https://www.irccloud.com/pastebin/bLhbMBWf/
<zyga> failed mount on live iso (curious) https://www.irccloud.com/pastebin/h2R6g2mI/
<pedronis> afaik refreshes are not working on the live image, that's why they asked us how to turn them off
<zyga> ureadahead is creazy on the live iso, spamming with errors
<zyga> pedronis: they work on 2nd try
<pedronis> what IÂ mean, afaik they are not expected to work
<zyga> I see
<pedronis> I don't know the details, but they didn't ask to help fix them, but how to turn off auto-refreshes
<pedronis> I think there's a basic space problem as well
<mup> Bug #1443612 changed: please set /run/shm/snaps/@{APP_PKGNAME}/@{APP_VERSION}/ for apps <Snappy:Won't Fix> <https://launchpad.net/bugs/1443612>
<mup> Bug #1650389 changed: Installing snapd on 14.04.5 desktop downgrades xorg et al. <14.04> <Snappy:Invalid> <systemd (Ubuntu):Fix Committed by thomas-voss> <systemd (Ubuntu Trusty):Fix Committed by thomas-voss> <https://launchpad.net/bugs/1650389>
<mup> Bug #1659924 changed: Snap failures in 16.04 <Snappy:Fix Released> <https://launchpad.net/bugs/1659924>
<mborzecki> mvo: damn, that template is tricky
<mup> Bug #1458866 changed: hangs in uboot boot prompt if dtbs dir is missing <Snappy:Won't Fix> <https://launchpad.net/bugs/1458866>
<mcphail> cjwatson: thanks. that's the one i've used
<mup> Bug #1464396 changed: "sudo: unable to resolve host ..." when custom hostname is used. <Snappy:Won't Fix> <https://launchpad.net/bugs/1464396>
<mup> Bug #1471868 changed: automatic reboot fails with non executable empty systemd <snappy-robustness> <Snappy:Won't Fix> <https://launchpad.net/bugs/1471868>
<mup> Bug #1473465 changed: kvm/generic-amd64: system got in a broken state in the second boot <Snappy:Won't Fix> <Snappy 15.04:Won't Fix> <Snappy trunk:Won't Fix> <https://launchpad.net/bugs/1473465>
<mup> Bug #1650671 changed: Content sharing from snap common is broken <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1650671>
<mborzecki> pedronis: can you take a look at https://github.com/snapcore/snapd/pull/4844#issuecomment-384969859 ?
<mup> PR #4844: overlord/snapstate: allow core defaults configuration via 'system' key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4844>
<mup> Bug #1641132 changed: no way to include devmode snaps in snap prepare-image? <personal> <Snappy:Won't Fix by mvo> <Ubuntu Image:Expired> <https://launchpad.net/bugs/1641132>
<mup> Bug #1666074 changed: Can't update "snapweb' snap <snapweb:Fix Released by abreu-alexandre> <https://launchpad.net/bugs/1666074>
<mup> Bug #1752031 changed: core `service.ssh.disable` key not taken into account <Snappy:Fix Released> <https://launchpad.net/bugs/1752031>
<mborzecki-ubuntu> zyga: any particular revision you'd want to me check?
<mup> Bug #1467553 changed: automatic reboot fails with zero size kernel, no watchdog in grub <snappy-robustness> <snapd:Triaged> <https://launchpad.net/bugs/1467553>
<mup> Bug #1588192 changed: GL interfaces seem wedged for Krita on nvidia <patch> <Snappy:Fix Released> <nvidia-graphics-drivers-304 (Ubuntu):In Progress by albertomilone> <nvidia-graphics-drivers-340 (Ubuntu):Won't Fix by albertomilone> <nvidia-graphics-drivers-361 (Ubuntu):Won't Fix by albertomilone>
<mup> <nvidia-graphics-drivers-304 (Ubuntu Xenial):In Progress by albertomilone> <nvidia-graphics-drivers-340 (Ubuntu Xenial):Won't Fix by albertomilone> <nvidia-graphics-drivers-361 (Ubuntu Xenial):Won't Fix by albertomilone> <https://launchpad.net/bugs/1588192>
<mup> Bug #1484898 changed: device tarball needs to allow setting sysctl defaults <Snappy:Won't Fix> <https://launchpad.net/bugs/1484898>
<mborzecki> mvo: https://play.golang.org/p/QERhAshfyMC
<mborzecki> best i could come up with
<zyga> mborzecki-ubuntu: nope
<zyga> mborzecki-ubuntu: just anything
<zyga> mborzecki-ubuntu: maybe try latest stable + krita
<mborzecki-ubuntu> zyga: stable is 2.32.5+18.04 (distro package)
<mup> Bug #1507693 changed: please add gdb, strace, ltrace, etc to snappy-debug <Snappy:Invalid> <https://launchpad.net/bugs/1507693>
<mup> Bug #1668738 changed: core snap with configure hook fails for some people <Snappy:Fix Released> <https://launchpad.net/bugs/1668738>
<zyga> ogra_: do you know if this is still an issue in practice? https://bugs.launchpad.net/snappy/+bug/1496141
<mup> Bug #1496141: /etc/adduser.conf should default to use extra_users <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1496141>
<mup> Bug #1474463 changed: a networking service snap like xkcd doesn't wait for the server to be listening <Snappy:Won't Fix> <https://launchpad.net/bugs/1474463>
<ogra_> zyga, well, the tools we use all use the --extrausers option ... switching that default would allow to avoid this
<mwhudson> zyga: yes it would, wouldn't it
<ogra_> so nothing has changed but if you want to close it ...
<mwhudson> zyga: yes, merge + massage i think, we need to move it salsa too...
<zyga> mwhudson: I'm sooo out of date on this process
<mwhudson> zyga: i think there are some new deps that need to be packaged?
<zyga> mwhudson: I can merge and push my tree somewhere after some basic massaging
<zyga> mwhudson: I bet
<mwhudson> zyga: go for it!
<mup> Bug #1543764 changed: snappy classic must use officially supported lxd images from simplestream; not unsupported ones from linux-containers.org <Snappy:Invalid by mvo> <https://launchpad.net/bugs/1543764>
<mvo> mborzecki thank you!
<mwhudson> zyga: it's probably easier for me to do the new packages as a DD i guess
<zyga> mwhudson: yeah, for sure
<zyga> mwhudson: I'll merge and see what comes out, I'm very out of touch with that aspect, I'll send you a mail with the updates (or forum thread)
<mwhudson> zyga: +1
<mborzecki-ubuntu> zyga: i don't see any denials
 * mwhudson makes a thing in a trello
<mwhudson> need to zzz now
<zyga> o/
<zyga> mvo: who maintains the classic snap
<zyga> mvo: and what should it do since we now have 18 looming
<ogra_> zyga, mvo and me ... kind of
<zyga> should it be magic smart and follow the booted base?
<zyga> or ... what?
<ogra_> we should have a classic-18 snap i guess
<mup> Bug #1551747 changed: ubuntu-fan causes issues during network configuration <verification-done> <cloud-init:Invalid> <Snappy:Invalid> <ubuntu-fan (Ubuntu):Fix
<mup> Released by apw> <ubuntu-fan (Ubuntu Xenial):Fix Released by apw> <ubuntu-fan (Ubuntu Yakkety):Fix Released by apw> <https://launchpad.net/bugs/1551747>
<zyga> ogra_: but you cannot install arbitrary classic on arbitrary system, can you?
<ogra_> if it is suppsed do that magically we'd have to ship both chroots
<ogra_> (and have it pik the right one at runtime)
<ogra_> s/ship both/ship support for both/
<ogra_> i suspect 18 looks a litte different to 16 :)
<mborzecki-ubuntu> zyga: tried with "none" and NULL, no denials in either case
<zyga> Thanks
<zyga> hm, snapcraft still doesn't support license?
<zyga> kalikiana: is this fixed or am I using it wrongly?
<zyga> popey: offtopic
<zyga> popey: I have https://github.com/snaphub
<zyga> feels like something you should have instead
<mup> PR core#87 closed: snapcraft.yaml: update stage-packages during build <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core/pull/87>
<mvo> I updated 5132 based on the excellent feedback I got
<zyga> looking
<popey> zyga: looks empty?
<popey> What is it (intended to be)?
<zyga> I think it is very old
<zyga> popey: it was supposed to be a place for snaps under shared maintenance
<zyga> like snapcrafters today
<Son_Goku> mvo, I'm looking forward to seeing a dnf plugin for snapd from you :P
<pedronis> mborzecki: I'm not sure merging them would be useful, IÂ would suspect people putting a copy or more stuff under system
<mborzecki> pedronis: hm sounds fair, very well, i'll push a change replacing error with the log
<popey> Zyga feel free to delete if it's not used
<zyga> popey: ack
<pedronis> mvo: zyga: any PR I should prioritize vs starting to look at the full queue?
<zyga> pedronis: maybe pass through all simple first
<zyga> to allow them to land
<zyga> mborzecki, mvo: I will fix master as arch moved to a more restrictive compiler now
<mup> PR snapd#5138 opened: cmd/libsnap: fix compile error on more restrictive gcc <Critical> <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5138>
<zyga> https://github.com/snapcore/snapd/pull/5138
<mup> PR #5138: cmd/libsnap: fix compile error on more restrictive gcc <Critical> <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5138>
 * zyga -> walk dog
<cachio_> mborzecki, hey, build fail on arch
<cachio_>  failing
<cachio_> here https://api.travis-ci.org/v3/job/375775038/log.txt
<mborzecki> cachio_: yes, zyga is working on it
<cachio_> mborzecki, great, thanks
<mborzecki> i've updated to gcc 8.1 just now :)
<zyga> Fixed above :-)
<mborzecki> off to pick up my daughter
<mborzecki> pedronis: pushed an update to #4844
<mup> PR #4844: overlord/snapstate: allow core defaults configuration via 'system' key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4844>
<mup> PR snapd#5130 closed: interfaces/apparmor: allow bash and dash to be in /usr/bin/ <Simple> <Created by zyga> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/5130>
<Son_Goku> zyga, you waited until Arch had it too until you'd fix the problem I've had in Fedora 28 since February?
<Son_Goku> I'm hurt :(
<zyga> That is the problem?
<zyga> It broke master :/)
<Son_Goku> yes
<zyga> Hey jdstrand
<Son_Goku> you promised me you'd fix it back then, and you didn't :(
<Son_Goku> and you guys keep disabling the Fedora CI instead of fixing it, so I have nothing left to make you guys notice these things
<zyga> Hmmm? We only disabled it when golang was broken
<Son_Goku> zyga, I've been forced to modify the autofoo to drop -Werror since February so that snapd releases would even build
<zyga> I lost track of that
<Son_Goku> :'(
<zyga> We should have f28 in CI
<Son_Goku> you should have Rawhide in CI too
<Son_Goku> I distinctly remember help setting that up at the last sprint
<mvo> Son_Goku: heh, will look into that once the fires are out
<mvo> pedronis: the 2.32 ones would be great
<mvo> yay, cosmic autopkgtests are all green now
<zyga> Son_Goku: so to recap (I was afk)
<zyga> Son_Goku: it would be great if we had the error in CI so that it gets fixed instantly and not forgotten
<zyga> Son_Goku: I'll ask if we can move to F28 testing
<mvo> zyga: aha, the arch failure(s) I see right now are known and you take care of them
<mvo> ?
<zyga> mvo: correct
<zyga> Son_Goku: I encourage you to nag us more if there's a known issue
<Son_Goku> I gave up after three weeks
<mvo> zyga: ta, approved
<Son_Goku> that's why I keep doing this: https://src.fedoraproject.org/rpms/snapd/blob/master/f/snapd-2.32.4-Drop-Werror.patch
<Son_Goku> that started in 2.31.1
<zyga> Son_Goku: also the patch is pretty trivial, we could have merged it long ago
<zyga> sorry for dropping it
<Son_Goku> yes, but you didn't want to
<Son_Goku> you said you'd rather fix the bugs
<zyga> I mean the patch for fixing this, not dropping -Werror
<zyga> cachio_: do we have a f28 image?
<Son_Goku> and of course, I keep this little bugger alive: https://src.fedoraproject.org/rpms/snapd/blob/master/f/0001-cmd-use-libtool-for-the-internal-library.patch :)
<zyga> I would swap f26 for f28 (26 is about to EOL)
<zyga> mvo: where shall we track bugs for classic snap?
<mvo> zyga: hm, gut-feeling is lp:snapd
<zyga> ah, I'm blind
<zyga> https://launchpad.net/classic-snap
<mvo> zyga: aha, even better
<thresh> kyrofa, oh wow, many thanks for the investigation which led to https://github.com/snapcore/snapcraft/pull/2119
<mup> PR snapcraft#2119: repo: automatically prune unneeded stage-packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2119>
<thresh> kyrofa, \o/
<zyga> mvo: we should probably rename the project a little
<zyga> is this "classic dimension"
<zyga> (reword)
<zyga> what is the proper name for that?
<zyga> hmm, github imports are failing
<zyga> https://code.launchpad.net/~snappy-dev/classic-snap/master
<zyga> and have failed since 2017
<zyga> ouch
<mup> Bug #1653648 changed: classic does not properly unmount /dev/pts on exist <Classic dimension for snappy:New for ogra> <https://launchpad.net/bugs/1653648>
<ogra_> that has been fixed ages ago
<zyga> retried now
<ogra_> (the bug i mean, havent looked at your import above)
<zyga> ogra_: can you triage https://bugs.launchpad.net/classic-snap/+bug/1653648 please
<mup> Bug #1653648: classic does not properly unmount /dev/pts on exist <Classic dimension for snappy:Fix Released by ogra> <https://launchpad.net/bugs/1653648>
<ogra_> zyga, i obviously did 5min ago
<zyga> cjwatson: hey, would you mind helping me understand why this git import is failing https://code.launchpad.net/~snappy-dev/classic-snap/master
<ogra_> zyga, laos https://github.com/snapcore/classic-snap/commit/4ec9dec90c555c4c26995ca83b23a48cd61d6743
<ogra_> err
<ogra_> zyga, also https://code.launchpad.net/%7Esnappy-dev/classic-snap/+git/classic-snap/+ref/master
<ogra_> (sorry bad paste in the first one=
<ogra_> the imports work fine
<zyga> ogra_: ?
<cjwatson> zyga: missing trailing ".git" in the URL, which is needed for git-to-bzr imports.  But why do you need a git-to-bzr import in the first place?
<zyga> ogra_: I clicked retry and it failed once again
<cjwatson> zyga: (I've fixed the URL)
<zyga> thanks!
<zyga> I wanted a git->git mirror
<zyga> not a bzr import
<cjwatson> then you did it wrong
<cjwatson> zyga: https://help.launchpad.net/Code/Git#Mirroring_repositories_from_other_sites
<zyga> ah, sorry than, let me remove that and start over
<ogra_> zyga, the mirrored tree is at https://code.launchpad.net/%7Esnappy-dev/classic-snap/+git/classic-snap/+ref/master
<ogra_> there is no bzr involved
<cjwatson> ah, right, so just remove the git->bzr import and then there's nothing else to do
<cjwatson> oh, and you should configure https://launchpad.net/classic-snap to have git as its default VCS
<ogra_> yeah, not sure where that bzr stuff comes from, the snap has worked fine for the last years
<zyga> cjwatson: thanks!
<zyga> done :)
<ogra_> (including the mirroring)
<cjwatson> ogra_: "Created by Oliver Grawert on 2017-07-29 and last modified on 2017-07-29" is where it comes from :)
<ogra_> hmm
<cjwatson> (anyway, I see it's gone now, so you probably just made a mistake and then forgot about it)
<ogra_> yeah
<zyga> yeah, I just removed it
<zyga> everything is fine now, no dead links
<ogra_> it didnt interfere with anything though
<ogra_> (and the GH README clearly points to the right urls
<ogra_> )
<zyga> I wonder how to clean up https://code.launchpad.net/classic-snap
<ogra_> why do you think thats needed ?
<zyga> well, it's a bit messy
<zyga> why is lp:classic-snap in "other"?
<zyga> what does it even mean
<pedronis> mborzecki: lgtm, small comment about the message,  also  "core snap-id"   vs "core-snap-id"
<mborzecki> pedronis: thanks, i'll push a fix in a minute
<cjwatson> zyga: that's a bug
<cjwatson> but it's not something you can clean up (unless you want to fix the LP UI there)
<cjwatson> zyga: not as simple as just filtering that out of the list though; the default repository does still need to be linked to somewhere, as there's useful information on https://code.launchpad.net/~snappy-dev/classic-snap/+git/classic-snap that's not on https://code.launchpad.net/classic-snap
<cjwatson> I'm not totally sure whether the fix is to make that information available on https://code.launchpad.net/classic-snap (maybe in a more compact form), or to make the presentation of the link less confusing, or some combination
<cjwatson> slightly inclined towards the former
<niemeyer> Heya
<mup> Bug #1586248 changed: 96boards-kernel need change name <Snapcraft:Invalid> <Snappy:Fix Released> <https://launchpad.net/bugs/1586248>
<niemeyer> Can someone please send me an invite for the standup? The Android Hangouts app is somewhat broken still
<jdstrand> hey zyga :)
<zyga> jdstrand: hey, I'm sure you have plenty of things to catch up on, I will ask you for some reviews as you have the time (you are usually subscribed as a reviewer). How was your trip home?
<jdstrand> zyga: I have a fairly long list of things that you asked for last week (and others). I plan to get to them this week, hopefully by tomorrow
<jdstrand> zyga: trip home was fine, thanks. uneventful, which is just what you want :)
<zyga> jdstrand: sounds good
<zyga> jdstrand: just take your time to re-adjust, nothing urgent on my side
<pstolowski> jdstrand: hey, i hope you've recovered from the sprint! will you find some time to take a look at my interface hooks PR? as i said it was reviewed a few times already, so you can probably focus on the policy aspect
<sitter> Wimpress: heya, did you forget to schedule a new meeting or did it get lost in my inbox?
<mup> Bug #1738197 changed: Daemons do not have an /run/user/* dir created <snapd:Confirmed> <https://launchpad.net/bugs/1738197>
<nodeman> Does anyone know an easy way to provision an Ubuntu Core machine with use of vSphere?
<mborzecki> zyga: there's a couple more errors that need to be fixed in #5138
<mup> PR #5138: cmd/libsnap: fix compile error on more restrictive gcc <Critical> <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5138>
<mborzecki> zyga: https://paste.ubuntu.com/p/ztx9NMCSQ3/
<mborzecki> zyga: i can take over the pr in case you want to focus on something else
<zyga> mborzecki: yeah, push away
<zyga> I don't have the env available
<mborzecki> ok
<zyga> thanks
<mborzecki> zyga: we should really rewrite snap-confine in go
<mborzecki> ;)
<zyga> mborzecki: it's not doable
<zyga> mborzecki: unless you mean go + big C chunk that runs before main ;-)
<mvo> cachio_: from my side all clear for the .6 release, we just need to ensure the store is happy and then it can go out I think
<zyga> mborzecki: we can shrinkg the C parts for sure but there's no workaround otherwise
<jdstrand> pstolowski: yes, I hope to get caught up on reviews by eod tomorrow
<cachio_> mvo, ok, I'll talk to the store team
<mborzecki> zyga: iirc we discussed this a bit, i recall taking a look at libcontainer
<zyga> mborzecki: really ;)
<zyga> mborzecki: not doable
<zyga> mborzecki: not everything can be done, I read what libcontainer does
<pstolowski> jdstrand: thanks. we were just discussing about landing that PR now to have it in early (before next release); any comments you might have would be addressed in a followup
<zyga> mborzecki: I think we should really work on removing most of the hard-coded features to profiles
<mup> Bug #1769669 opened: Snapd causes corruption on upgrade  <Snappy:New> <https://launchpad.net/bugs/1769669>
<mvo> cachio_: thank you
<Wimpress> sitter: Oversight on my part and public holiday in the UK today. I send an invite when I'm back to work
<mvo> zyga: the arch fix PR has more failures
<mvo> I can paste if you want
<zyga> mvo: mborzecki is fixing those
<zyga> I only fixed the first one from the log
<cachio_> mvo, it is done
<cachio_> 32.6 in stable
<zyga> woot
<zyga> thank you cachio_
<mvo> cachio_: !!! thanks
<cachio_> np
<mvo> zyga, mborzecki out of curiosity, what version of gcc is causing these issues?
<mborzecki> mvo: 8.0 and up
<mborzecki> mvo: https://gcc.gnu.org/gcc-8/changes.html
<mvo> mborzecki: thanks. I can reproduce with the gcc-snapshot package. but I assume you have it all under control? or want a hand?
<mborzecki> mvo: i'll be pushing patches in a minute
<mvo> mborzecki: cool
<zyga> mborzecki: hey, are you handling 5138
<zyga> I can pick it up now
<mborzecki> zyga: i have all the changes now, just rerunning make check
<mborzecki> zyga: mvo: pushed
<zyga> I saw
<mborzecki> builds cleanly now
<mborzecki> the last one was funny, had to run the test to check if it's actually testing the right thing
<mvo> mborzecki: ta
<zyga> mborzecki: was the change from * to [] needed?
<mvo> mborzecki: works fine here with gcc-snapshot, thanks for the fix
<mborzecki> zyga: yes, it's the least effort fix
<zyga> mborzecki: can you explain it?
<mvo> zyga: you mean in snap-test.c ?
<zyga> yes
<mborzecki> zyga: i didn't want to hardcode the size to 41, but to avoid the check for truncation i had to switch to memcpy, if someone changed the length of good_bad_name this may break the tests
 * cachio_ afk
<zyga> I don't mean that
<zyga> I mean this specifically:
<zyga> - const char *good_bad_name = "u-94903713687486543234157734673284536758";
<zyga> +	const char good_bad_name[] = "u-94903713687486543234157734673284536758";
<zyga> is that for the sizeof to work?
<mborzecki> zyga: this is to be able to do char varname[sizeof good_bad_name] = { 0 };
<mborzecki> zyga: yes
<zyga> ok
<zyga> thanks
<zyga> +1
<mborzecki> didn't want to do alloca(strlen(good_bad..)+1)
<mvo> mborzecki: I pushed a tiny extra commit as it was breaking on ubuntu with the gcc8 fixes, but now it should work everywhere
<mborzecki> mvo: yup, works here too
<mvo> yay
<pedronis> pstolowski: once interface hooks lands it seems it will open up a lot of its follow ups to review
<pstolowski> pedronis: yes
 * zyga needs to break now; I will be back in 3 hours to work on more things
<zyga> mvo: gcc warns about unused result of those two?
<mvo> zyga: chdir only, I did the rmdir for symetry
<mborzecki> zyga: didn't warn here, but maybe there's something turned on by default in gcc-snapshot or ubuntu glibc
<mvo> zyga: I think we use -Wunused-result or something, let me look
<zyga> no worries, I was just curious
<zyga> the patches look good
<mvo> zyga: http://paste.ubuntu.com/p/B9TBshVG2n/
<mvo> zyga: just fyi
<mborzecki> mvo: looks like something in libc then
<mborzecki> mvo: zyga: extern int chdir (const char *__path) __THROW __nonnull ((1)) __wur; where __wur sets warn_unused_result but only if FORTIFY_LEVEL is > 0
<mup> Bug #1769669 changed: Snapd causes corruption on upgrade  <snapd:Confirmed> <https://launchpad.net/bugs/1769669>
<mvo> mborzecki: ok
 * zyga is really off now
<pstolowski> pedronis: you're going to make one more pass over interface hooks PR (Gustavo's comments), right?
<mvo> grr, now ubuntu-18.04-64 fails in spread-shellcheck with a pip install --user error
<mvo> (i.e. pip fails)
<mvo> mborzecki, zyga just fyi (pr 5138)
<mup> PR #5138: cmd/libsnap: fix compile error on more restrictive gcc <Critical> <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5138>
<pedronis> pstolowski: did something change since IÂ last looked?
<kyrofa> sergiusens, https://forum.snapcraft.io/t/proposal-snapcraft-provides/5275
<pstolowski> pedronis: i've addressed the comments from Gustavo that I missed from his earlier review; and refresh was moved into separate PR. that's about it
<pedronis> pstolowski: ok, I will look tomorrow morning at this point, also github is giving me unicorns
<pstolowski> pedronis: sure
<sergiusens> kyrofa: https://github.com/snapcore/snapcraft/blob/master/TESTING.md#testing-arm
<sergiusens> kyrofa: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#5xx_Server_errors
<sergiusens> kyrofa: from http.client import responses
<sergiusens> kyrofa: requests.status_codes.codes
<mup> PR snapcraft#2123 closed: file_utils: don't let FileNotFoundError escape <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2123>
<jdstrand> noise][: hey, I've been getting 504's on https://dashboard.snapcraft.io/reviewer/ubuntu/. https://status.snapcraft.io/ looks ok
<kyrofa> sergiusens, I just realized the sentry Always PR got rid of the environment variable with the same functionality-- how do you anticipate making this work in CI?
<kyrofa> I'm getting some tracebacks in CI, I'd like to set it up to automatically submit those
<kyrofa> I suspect LP will want to do the same at some point
<sergiusens> kyrofa: yeah, I got rid of the environment to force us into the workflow. For now you could just create the appropriate config
<kyrofa> sergiusens, sure, just curious what the long-term plan is. Adding something like that back?
<sergiusens> an env var is something we can add back, but I'd prefer something closer to a setting, that involves a larger/longer discussion though
<magicalt1out> out of curiosity hows this snap delay/schedule stuff coming along? Because with Gimp being a snap recommended at install time, if I was doing some design stuff (I can't design, we're talking hypothetics here) it'd be rather annoying if it suddenly stopped working or went a bit wacky cause Gimp got upgraded from under me.
<magicalt1out> thats the one that springs to mind, i'm sure you could say the same for a lot of apps
<magicalt1out> or maybe its a non issue
<magicalt1out> hence my curiosity :)
<kyrofa> Hey magicalt1out, I think most of the snapd team is EOD already, but there is a bit of info in the forum, and you can always ask there if you need async communication
<mcphail> magicaltrout: "snap revert" is supposed to be the solution to that problem. I don't 100% agree
<magicaltrout> interesting mcphail... I 100% agree with your not 100% agreeing
<mcphail> magicaltrout: it'll maybe be better when people start using tracks as standard. that way there might be a persistent 2.8 track
<kyrofa> mcphail, I don't think that's what magicaltrout was asking (correct me if I'm wrong magicaltrout). The concern is that, when a snap updates, if an app is already running, it may run into issues accessing the underlying data directories with the confinement
<kyrofa> magicaltrout, you can schedule updates today, but that ^ is still an issue for when an update _does_ happen as far as I'm aware
<kyrofa> Unless the snap in question is classically confined
<mcphail> yes, that's a particularly annoying problem
<mcphail> although i don't know if it is such an issue for snaps with the home plug
<om26er> BUG: wrong emphasis of headings on this page https://docs.snapcraft.io/build-snaps/scriptlets
<kyrofa> om26er, what are you talking about? That's obviously on purpose. Your eyes are drawn to the emphasis, no?
<kyrofa> *cough*
<kyrofa> om26er, mind logging an issue here? https://github.com/canonical-docs/snappy-docs
<om26er> wonder if we have a new design language ;-)
<magicaltrout> kyrofa is correct i'm curious about stuff that is up and running
<kyrofa> Heh
<magicaltrout> kyrofa: whats this schedule stuff you speak of?
<kyrofa> magicaltrout, let me go forum diving,  hold on a sec
<magicaltrout> snap set core refresh.schedule?
<kyrofa> magicaltrout, yeah https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/1239 is the first one I find
<magicaltrout> ah yeah thats cool, I'm really coming at it from a Charm angle. Because I want to ship Analytics tools and it'll be really sad for users if it updates mid workday mid month end
<magicaltrout> for example
<magicaltrout> thats cool though, i can try and set that during the install hook
<kyrofa> Yeah I hear ya
<mcphail> magicaltrout: i'm poking the devs about this :) https://forum.snapcraft.io/t/bug-saves-are-blocked-to-snap-user-data-if-snap-updates-when-it-is-already-running/3226
<kyrofa> mcphail, ah,  yes
 * mcphail feels it is his role to be an annoyance ;)
<magicaltrout> annoyances ensure the useful stuff not just the fun stuff gets implemented ;)
<mup> PR snapcraft#2115 closed: storeapi: ensure snap ID is sane before using it <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2115>
<popey> pbek: just noticed you have old versions in beta/candidate/edge of qownnotes
<popey> pbek: you can 'snapcraft close beta' for example to nudge people towards stable (and thus the latest build)
<popey> (same for the other channels)
#snappy 2018-05-08
<mborzecki> morning
<mup> PR snapd#5138 closed: cmd/libsnap: fix compile error on more restrictive gcc <Critical> <Simple> <Squash-merge> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5138>
<mup> PR snapd#5139 opened: cmd/libsnap: fix compile error on more restrictive gcc (2.32) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5139>
<mborzecki> mvo: morning
<Son_Goku> mborzecki, mvo: do we have fedora 28 CI live now?
<mborzecki> mvo: i've merged 5138 and opened a followup for 2.32 -> #5139
<mup> PR #5139: cmd/libsnap: fix compile error on more restrictive gcc (2.32) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5139>
<Son_Goku> and maybe even rawhide CI?
<mborzecki> Son_Goku: don't know if cachio has added f28 image yet
<Son_Goku> well, unfortunately I'm a bit unable to test much of anything on hotel wifi :/
<Son_Goku> so I was hoping that'd be up by now to be sure that the compilation errors are all fixed
<mvo> mborzecki: thank you! and good morning
<mvo> Son_Goku: I will followup with cachio on that today
<Son_Goku> mvo, zyga, I'm in San Francisco for Red Hat Summit this week
<Son_Goku> so among other things, I intend to talk to Fedora folks on a wide array of topics
<Son_Goku> which is why I was hoping zyga would have ironed out the issues that prevented a working fedora base snap
<Son_Goku> and created an app snap that uses a fedora base to demo the concept
<mvo> Son_Goku: woah, cool!
<mvo> Son_Goku: he was working on this, but this sounds great, lets catch up with him once he is online and see the status, it would be great to give you something to demo there
<mborzecki> Son_Goku: great news
<mborzecki> he mentioned he did play with fedora base on friday (?) last week and he had some progress
<mborzecki> afk for ~30 minutes
<mup> PR snapd#5139 closed: cmd/libsnap: fix compile error on more restrictive gcc (2.32) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5139>
<zyga> Hey
<zyga> Son_Goku: i have something close that you can show
<zyga> I will share it soon
<zyga> I have a bit of a hectic day
<zyga> Need to go with my mom to a hospital
<zyga> But I will work most of the time
<Son_Goku> ok
 * zyga commutes to the hospital
<mborzecki> re
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> pushed an update to arch package with gcc build fixes patch
<mvo> mborzecki: ta
<zyga> re
<zyga> mvo: how are we doing for .7?
<zyga> how can I help
<mvo> zyga: need an ACK from niemeyer for .7 on naming and approach (forum post is https://forum.snapcraft.io/t/snapd-seeded-target-and-how-to-order-after-it/5310)
<mvo> zyga: I'm looking at the screenly issue right now
<zyga> mvo: at the lower vs UPPER thing?
<zyga> mvo: do you think that we could use my suggestion on mounting fat in a specific way?
<zyga> mvo: I added one more option on the #5132 naming thing
<mup> PR #5132: snap,wrappers: allow "external:{snapd,snapd.seeded}" for snap apps <Critical> <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5132>
<mvo> zyga: yeah, the corruption thing, I wrote up https://forum.snapcraft.io/t/snapd-causes-corruption-on-upgrade/5253/20
<mvo> zyga: which includes all the details what goes wrong, I have the sd card and looking right now if I can find anything to help with the situation
<zyga> mvo: canyou check if mounting it with that option helps
<zyga> it should be a simple tweak to fstab
<mvo> zyga: I did, I still see two lower-case uboot.env files and cat gives me the wrong one
<zyga> bummer!
<zyga> an fsck?
<mvo> zyga: but let me try to write it
<zyga> does fscking fixes anything?
<mvo> zyga: fsck.vfat is clean :/
<zyga> well, at this stage I think linux is broken there :/
<mborzecki> well, how did they end up with both?
<mvo> mborzecki: thats the big question - uboot writes it, it contains snap_mode=trying
<zyga> mborzecki: FAT is apparently still hard
<mvo> mborzecki: however its unclear why it does it, in most cases it writes the right file
<mvo> zyga: here is something funny, if I mount with -o shortname=win95 I can see the two files with different filenames - but cat gives me the same output for both
<zyga> maybe magic sd card controller groking fat?
<mvo> this also works when I don't use a sd card but just the plain image
<mborzecki> which one was written by fw_setenv?
<mvo> and fatcat shows me the right "cluster"
<mvo> mborzecki: none
<mvo> mborzecki: the uboot binary writes with its own code (which may be reused in fw_setenv, I don't know)
<mborzecki> so it's the uboot script that wrote it?
<mvo> mborzecki: and we write using our own code
<mvo> mborzecki: correct
<mvo> mborzecki: one sec, I can paste it
<mborzecki> mvo: if you do fatls in uboot does it show both files?
<mvo> mborzecki: https://paste.ubuntu.com/p/7zCCzgh76j/ <- output sucks
<mvo> mborzecki: I think it does, let me double check, I played with fatls and fatload and md and could only get uboot to read the "wrong" UBOOT.ENV file. but it seems when it writes it always writes the "uboot.env" (lower-case) file
<mvo> mborzecki: https://paste.ubuntu.com/p/psgTgfwFz5/ - it shows both files
<zyga> mvo: what is the relationship of uboot.env to uboot.bin?
<zyga> there's only one .bin
<zyga> maybe (apart from .env being duplicated) the issue is really in .bin?
<mvo> mborzecki: doing fatload mmc 0 9999999 UBOOT.ENV gives me the same conent for upper and lower case
<mvo> zyga: we don't write anything on this sd except UBOOT.ENV
<zyga> mvo: how are you testing this? using a raspberry pi?
<Chipaca> moin moin
<zyga> hey Chipaca!
<mborzecki> zyga: uboot.bin is the actual uboot, it's loaded by one of the start*.elf binaries
<zyga> how are you doing?
<zyga> mborzecki: ah, thanks
<mborzecki> Chipaca: hey
<Chipaca> 'm hot =)
<Chipaca> how're you guys?
<mvo> zyga: yes, I got the corrupted image and wrote it to a sd card and play with it on my pi
<zyga> mvo: what happens if you use uboot
<zyga> and write some new variable
<zyga> and save that
<zyga> did you perform such an experiment?
<zyga> frozbonicator=schnibble
<zyga> saveenv or whatever that was
<zyga> and see what's on FAT
<mvo> zyga: it happens implicitly because snap_mode=try triggers snap_mode=trying and saveenv. I did not try explicitly though, can do
<zyga> I wonder where it will go
<mvo> zyga: pretty sur eit will go to uboot.env (lower) but I can try
<Chipaca> zyga: from snapd's pov that's a file mounted on a vfat fs, yes?
<zyga> Chipaca: yes
<Chipaca> zyga: why vfat and not msdos?
<zyga> Chipaca: mvo tried mounting it in a few ways
<zyga> Chipaca: ha, perhaps good question
<zyga> vfat implies long file names
<zyga> maybe uboot doesn't do that
<zyga> though msdos is AFAIK a variant of fvat with different options
<zyga> it would be good if we could reproduce this though
<zyga> mvo: question
<zyga> ha
<zyga> maybe a good one actually :D
<zyga> mvo: how do we write that file from snapd
<zyga> are we ... by any chance.. use atomic renames?
<zyga> write a new _long_ random file name a rename?
<zyga> could it be that by doing that our file lives in the LFS domain?
<zyga> and uboot just says "meh, don't grok"
<zyga> and writes a new file
<zyga> then stuff goes south
<zyga> though this doesn't explain why it only happens once in blue moon
<zyga> maybe the random pattern (if that part is random) needs to be special to trigger this
<mvo> zyga: we write the file in place iirc, never change the size. this is to avoid it ever moving on disk which seems to cause corruption easily (iirc)
<zyga> aha, so that's out the door then
<zyga> hmmmm
 * zyga looks at the code
<mborzecki> this is what writes the env to a file: https://git.denx.de/?p=u-boot.git;a=blob;f=fs/fat/fat_write.c;h=3b77557b3ede57951c4e35e0d5d753fda845e903;hb=HEAD#l902
<zyga> mborzecki: thanks
<zyga> mydata->fatsize
<zyga> I wonder if it would help if we mounted it as fat16
<zyga> is it fat16 or fat32?
<mvo> mborzecki: yeah, I remember looking at this file a while ago
<zyga> or fat12, I forgot the variants
<mvo> I think fat32
<mvo> but not 100% certain
<zyga>  980         downcase(l_filename, INT_MAX);
<mvo> things are more myserious - now I tried to remove uboot.env from linux, that worked and ls from linux does not show any uboot.env anymore. *but* fatcat still shows *both* and uboot happily show both and load the UBOOT.ENV one
<mborzecki> mvo: can you try mounting it with check=s ?
<zyga> so it's essentially using lower case for lookup
<mvo> mborzecki: done, no change afaict
<mborzecki> hm wonder what they set ENV_FAT_FILE to
<Chipaca> augh, laptop is suspend-cycling
<zyga> hmm
<Chipaca> wtf
<zyga> mvo: since both are lower case is there a chance that there's a space or something like that there?
<mvo> zyga: I can't see spaces with the tools I have, I can write some code though, let me see
<zyga> can you fatcat | od -t c
<zyga> from linux
<zyga> that should show invisibles
<mvo> zyga: it uses spaces all over the place, "f 18/4/2018 15:44:16  UBOOT.BIN                      c=11801 s=361144 (352.68K)
<mvo> "
<zyga> drat :/
<mvo> zyga: how would I know if the space is a space or part of the filename?
<zyga> yeah
<zyga> sucks
<mvo> it does
<zyga> FAT uses one table or two?
<mvo> two afaik
<mvo> fwiw, filesystem is FAT32
<zyga> mvo: does fatcat -o show anything?
<zyga> mvo: and what does fatcat -i say?
<mvo> zyga: https://paste.ubuntu.com/p/ZmShHTXkYY/
<mborzecki> hmm https://git.denx.de/?p=u-boot.git;a=commit;h=2c33b0c7d8deca7e9a907365a59fcbcde531c70d
<mvo> zyga: https://paste.ubuntu.com/p/HqzptYhJ9C/
<zyga> "exactly equals" ;-)
<zyga> hmmmm
<zyga> man, this is a curious issue :)
<zyga> thank you mvo
<mvo> mborzecki: interessting, worth checking if they have this in their tree
<zyga> mborzecki: do we have that patch in our uboot
<zyga> mborzecki: and how does it explain the random aspect
<mborzecki> zyga: 'our' uboot? where is that?
<mvo> mborzecki: they use https://github.com/Screenly/u-boot
<zyga> could it be uninitialized memory
<zyga> mborzecki: not sure, let me look at pi3 gadget
<zyga> uboot is fairly (totally?) deterministic
<zyga> but maybe something on reboot is not cleaned
<zyga> and uninitialized memory could make some memcmp fial
<zyga> *fail
<mborzecki> mvo: can you grab the welcome banner when uboot starts?
<mvo> mborzecki: sure, one sec
<mvo> mborzecki: U-Boot 2017.05-dirty (Mar 12 2018 - 09:55:39 +0000)
<mvo> mborzecki: I guess that is the answer
<zyga> woah
<zyga> dirty!
<mvo> mborzecki: definitely worth investigating
<mborzecki> haha ;)
<mborzecki> at least it's not some random chinese manufacturer :)
<mvo> I am still super puzzled that uboot happily loads uboot.env which I deleted from linux and is no longer visible in linux. apparently fat is hard
<zyga> mvo: fat is easy, bound checks are hard ;)
<zyga> mvo: at this stage I'd get back to screenly for their dirty uboot tree
<zyga> this is a goose chase until we know what they are booting
<zyga> mvo: would their patched uboot work on a vanilla pi?
<zyga> mvo: maybe worth trying with that?
<Chipaca> zyga: is that their uboot, or is it just the regular rpi uboot that's dirty?
<zyga> Chipaca: good question
<zyga> and if my pi had a serial port connected
<mvo> zyga: we have the branch they build from on github
<zyga> I would check
<zyga> mvo: who uploaded the gadget?
<mvo> zyga: their uboot works with my pi2, is that the question?
<mvo> zyga: I think they do that
<zyga> mvo: maybe the branch is not the thing that is really uploaed
<zyga> some dev hacked a little thing and built that
<zyga> and never commited
<mvo> possible, but they build from snapcraft.yaml I would give them the benefit of the doubt for now :)
<mvo> that they don't do crazy stuff
<zyga> mvo: I don't disagree that they use snapcraft.yaml now, just that the initial build was dirty :)
<zyga> mvo: can you swap to our pi SD card
<zyga> mvo: and see if we show the same dirty string
<zyga> (and if it builds and boots, ship it)
<mvo> zyga: I can't do this easily right now (would need to reflash the image)
<mvo> zyga: but iirc we are also dirty
<zyga> ah
 * zyga wonders where is ogra 
<mvo> zyga: I only have one fast sd card :)
<zyga> anyone with a pi handy?
<mvo> zyga: maybe washing ;)
<zyga> mvo: do you have a pi image for vanilla pi?
<zyga> maybe strings | grep dirty
 * zyga needs to move closer to the hospital, ttyl
<mvo> zyga: good luck
<pbek> thank you popey, I now closed those channels for qownnotes
<popey> yay
<pedronis> pstolowski: hi, so another reason not to do too big PRs seems github performance, I'm still struggling to open your PR :/
<pstolowski> pedronis: :(
<pstolowski> pedronis: pulling my branch and looking at latest commits might be faster?
<pedronis> maybe but ideally I need to look at the comments too
<pstolowski> right
<pedronis> seems to have opened in a different browser
<zyga> re
 * zyga waits at the hospital, focuses on existing branches
<pstolowski> pedronis: thanks for the NoOption comment, pushed
<pstolowski> zyga: commented on 5107
<zyga> pstolowski: thanks, looking
<popey> cjwatson: is there some way to get an rss feed from b.s.i builds in lp. feeds.launchpad.net/~build.snapcraft.io/snaps.atom  kind of thing?
<popey> (I couldn't find it)
<zyga> pstolowski: replied
<cjwatson> popey: no
<pstolowski> zyga: thanks!
<pedronis> pstolowski: lgtm
<pstolowski> pedronis: ty, merge then? i'd squash-merge it..
<pedronis> pstolowski: yes, squash merge because there's so many commits
<pedronis> needs to be green first
<pstolowski> sure
<mborzecki> mvo: hm the rspi image from cdimage.ubuntu.com has U-Boot 2016.03-rc3-00013-gf135e8f-dirty
<mborzecki> let me check if i can build something more recent
<zyga> mvo: I would check with ogra if we actually use the uboot from snapcraft.yaml
<zyga> older gadget unpacked something from a tarball
<zyga> which may have been made manually
<ogra_> that is long dead
<zyga> ogra_: hey
<zyga> ogra_: do you know what may have caused the "dirty" flag there?
<ogra_> sorry, my IRC proxy wendt down unnoticed ...
<ogra_> *wnt
<ogra_> bah
<zyga> no worries :)
<ogra_> zyga, in stable we still use the old stuff, but screenly never used that
<zyga> I don't understand
<ogra_> we switched to build-uboot-from-source ages ago but couldnt uzpgrade the gadget ... so stable still has the very first tries that used local builds from a tarball
<mborzecki> i'm building from upstream
<zyga> ogra_: which version shows the string "dirty"
<ogra_> zyga, the very first gadget we built
<zyga> ogra_: screenly's gadget shows that too
<zyga> ogra_: and mborzecki checked that rspi image on cdimage shows this too
<zyga> is that expected?
<nodeman> http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ubuntu-core-16-pi3.img.xz
<ogra_> i dont have a serial attached pi atm ... perhaps newer ones show it too, not sure (after alkl we have to patch it )
<mborzecki> zyga: it's probably due to patching of rspi default env
<nodeman> I'm having trouble getting this image working on the latest RPi, the model B+. Is it not supported?
<mborzecki> zyga: hopefully only this
<ogra_> zyga, sorry, i got confused ... the one in stable was built from master-tip when pi was initially added to uboot (there was no other branch for pi back then) and was used from a local binary build ... the newer ones come from a stable tag in the upstream u-boot branch and are built dynamically ...
<ogra_> zyga, since we patch it to handle the config in a way snapd understands i belive they both get the dirty tag, but one comes from a stable source and the other from an "initial commit for this HW"
<zyga> I see
<zyga> thanks
<ogra_> zyga, sorry, i mixed up source and binary
<zyga> mvo: I think #5132 would pass now if master is merged, shall I do that?
<mup> PR #5132: snap,wrappers: allow "external:{snapd,snapd.seeded}" for snap apps <Critical> <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5132>
<mborzecki> zyga: i think it should be enough to restart the build
<zyga> mborzecki: not sure, I can just merge
<zyga> mborzecki: I don't think we re-merge
<zyga> (on gh side)
<mvo> zyga: sure, go for it
<Chipaca> nodeman: the raspberry 1 B+ is not supported, no
<zyga> done
<Chipaca> nodeman: you need rpi 2 or 3
<zyga> nodeman: there's a preview image I think
<zyga> nodeman: it's on the forum
<zyga> ahhh
<Chipaca> zyga: armel?
<zyga> 1
<zyga> no no sorry
<Chipaca> right
<zyga> I confused that with 3B+
<Chipaca> wrong architecture
<zyga> sorry about that, pi 1 is not going to be supported due to CPU incompatibility
<Chipaca> nodeman: if by 'latest b+' you mean the 3 b+, then it can work as zyga says
<nodeman> I mean RPi3 B+, getting a rainbow screen every time I boot up.
<Chipaca> zyga: nodeman didn't specify :-) i started my answer with a question
<nodeman> Sorry, for not specifying the 3 Chipaca .
<Chipaca> nodeman: yep, the image from cdimage will not work
<Chipaca> nodeman: i think it's the wrong bootloader or something; there's a preview image
<Chipaca> let me find that for you
<nodeman> Chipaca: thanks, I appreciate it.
<Chipaca> nodeman: https://forum.snapcraft.io/t/support-for-raspberry-pi-3-model-b/4509/18?u=chipaca
<Chipaca> nodeman: read the caveats there =)
 * Chipaca takes a break
<zyga> anyone wants to have a 3rd look at https://github.com/snapcore/snapd/pull/5126
<mup> PR #5126: cmd/snap-update-ns: add support for ignoring mounts with missing source/target <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5126>
<zyga> it's +2 and green
 * Chipaca really breaks
<nodeman> Chipaca: thanks again.
<pstolowski> about to merge interface hooks... if anyone wants to say something, now is the last chance... merging in 3...2...1..
<mup> PR snapd#4358 closed: interfaces: interface hooks implementation <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4358>
<pstolowski> \o/
<pedronis> pstolowski: :)   almostlunch but once you have merged master into the follow ups, let me know which one I should look at first
<pstolowski> pedronis: thanks, just re-merging them, will let you know
<pstolowski> i started getting 'Cannot allocate google:ubuntu-16.04-64: google: could not find default credentials.' from spread without changing anything on my side afaict.. did anything change?
<zyga> hmm?
<zyga> no, feels like a bug
<pstolowski> zyga: does it work for you?
<zyga> pstolowski: let me try
 * zyga installs spread from a snap
<zyga> weird
<zyga> I'm sure I had it but maybe I broke something
<zyga> could not find credentials
<zyga> whaat?
 * zyga wonders
<zyga> pstolowski: which spread?
<zyga> pstolowski: it works now (I think)
<pstolowski> zyga: i've spread from snap
<zyga> pstolowski: it works
<pstolowski> zyga: ok, thanks for checking!
<zyga> pstolowski: spread from snap doesn't work
<zyga> not sure where the key comes from?
<zyga> but $SPREAD_GOOGLE_KEY is empty for me?
<zyga> no idea why
 * zyga goes out of the hospital, ttyl
<pstolowski> zyga: ok, got it working, not sure what happened, but i switched to non-snap based spread and also re-initialized my gcloud config
<zyga> pstolowski: weird, right?
<zyga> wait
<zyga> where's the google auth data storeD?
<pstolowski> zyga: in ~/.config/gcloud afaict
<mborzecki> played around with u-boot from our rpi3 image, could not get it to create duplicate files with lowercase/uppercase names
<mborzecki> building upstream u-boot for rpi is somewhat silly though, none of the linaro toolchains i usually use work, did some extra steps, doesn't work either, i'm downloading official rpi toolchain
<mborzecki> still amazed why people use it
<zyga> fun
<zyga> I spawnet some google machines
<zyga> closed my laptop
<zyga> moved out of the hospital
<zyga> opened my laptop and re-connected to LTE
<zyga> and I see those machines roll on :)
<zyga> mborzecki: ouch!
<zyga> mborzecki: and the bare armhf toolchain from ubuntu archive?
<zyga> mborzecki: it's the linaro toolchain
<mborzecki> i'm doing this on arch, besides official rpi toolchain is almost there
<zyga> mborzecki: does lxd work on arch?
<zyga> just curious
<zyga> how portable the snap is
<mborzecki> mborzecki: last time i used it it worked just fine
<zyga> nice
<zyga> Chipaca: should help say "command foo will print yada" or rather "command foo prints yada"?
<Chipaca> zyga: wat
<zyga> Chipaca: long help of snap commands
<zyga> what's the preferred wording?
<Chipaca> zyga: The foo command does x, y, and z
<zyga> mmm,thanks
<zyga> snap debug confinement doesn't follow that
<zyga> but I will change it separately
<zyga> thank you
<Chipaca> zyga: ah, i haven't looked at the debug commands, I don't think
<Chipaca> as they're hidden and not promised stable
<zyga> I think they should do the same thing
<zyga> as in, should be worded the same way
<Chipaca> agreed, would be good
<zyga> consistently
<zyga> just nobody noticed :)
<zyga> because <emoji>
<Chipaca> yep, as i say i didn't look at them in my last consistency pass
<mborzecki> pff what a joke, 'Your GCC is older than 6.0 and is not supported', obviously the official one is 4.7.1
<zyga> mborzecki: whaat? pi uses 4.7?
<zyga> is that the new 2.96?
<mborzecki> built it now with linaro toolchain, gcc 7.1
<pstolowski> pedronis: the next hooks PRs are #5120, #4767 and #4510, but the last two are not green now and i'm deconflicting them (5120 is ready for review and green)
<mup> PR #5120: interfaces:interface-hooks for refresh <Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5120>
<mup> PR #4767: interfaces: disconnect hooks <Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>
<mup> PR #4510: asserts: use Attrer in policy checks <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4510>
 * Chipaca ~> lunchy chunch
<ogra_> chipunch
<ogra_> ...
<niemeyer> Hellos!
<zyga> hey
<mup> PR snapd#5141 opened: tests: shellchecks, part 1 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5141>
<jdstrand> noise][ (cc wgrant, sparkiegeek since natalia and roadmr aren't here): hey, I've been getting 504s on https://dashboard.snapcraft.io/reviewer/ubuntu/ yesterday, today and last friday and have been unable to review the store queue
<jdstrand> noise][: https://status.snapcraft.io/ still looks ok
<zyga> woah
<jdstrand> cprov: fyi, ^
<cprov> jdstrand: ack, let me figure something out for you quickly
<jdstrand> cprov: thanks! (wgrant, sparkiegeek - fyi, cprov is on it)
<cprov> jdstrand: it loads for me, with a large number of snaps pending review
<jdstrand> hmm
<cprov> not really large, 27 new and 2 updated
<jdstrand> cprov: https://dashboard.snapcraft.io loads for me, and clicking ono random things loads for me. but if navigate to that url, I get a 504
<wgrant> https://oops.canonical.com/oops/?oopsid=OOPS-8bc2e0c613f245e2969f321efeb6a431 has 15s of SQL time
<jdstrand> cprov: most of those are kernel/gadgets that kyleN is a backlog that others are working through
<zyga> vim crashed while editing api_test.go
<jdstrand> s/that kyleN//
<jdstrand> kyleN: (sorry for the noise)
<cprov> jdstrand: yup, times out frequently here too
<jdstrand> kyleN: I tried to leave you out of it. I guess my backspace key was broken :)
<jdstrand> cprov: ah, so you got lucky
<cprov> jdstrand: exactly
<jdstrand> I mean, I can keep reloading the page (I had a few times today, yesterday and friday already)
<jdstrand> ah, I got ucky
<jdstrand> lucky even
<jdstrand> yeah, 4 of those need to be looked at by me
<jdstrand> cprov, wgrant: for the moment, shall I just keep retrying and you'll (get someone) to look into the timeouts?
<jdstrand> zyga: what is up with hello-classic? is this a test snap? it was uploaded under your account, not the shared one
<zyga> this is a demonstration snap that people can install and explore
<zyga> I got a PR for it lately so I thought it should be published
<cprov> jdstrand: I'd say so, it's not something we can fix instantly, but we should be able to improve things until EOD
<pedronis> jdstrand: our official test snaps should all start with test-snapd- now
<zyga> I can add it to a shared account but I don't know the process
<jdstrand> zyga: did you do a forum request?
<jdstrand> pedronis: yeah, that is what I thought
<zyga> jdstrand: no, I'll do one shortly
<jdstrand> cprov: thanks!
<Son_Goku> O.o
<Son_Goku> today I just learned that subiquity's engine can install CentOS?1
<Son_Goku> sabdfl, ^ ?!
<pedronis> Son_Goku: you mean 'curtin' ?
<Son_Goku> yes
<Son_Goku> I mean, it's kinda dumb in some ways (based on how I read the logic in there), but I'm more surprised it can do it at all
<ogra_> whats the logic ? dd ?
<ogra_> or tar xf ?
<ogra_> :)
<pedronis> IÂ think its scope has grown a bit driven by maas use cases
<Son_Goku> it can _sort of_ detect that it's targeting a CentOS system
<ogra_> AI !!!
<Son_Goku> and write ifcfg network files
<Son_Goku> and maybe write halfway correct yum repo files
<zyga> jdstrand: https://forum.snapcraft.io/t/request-for-classic-confinement-hello-classic/5321
<zyga> jdstrand: I made an RFC branch that you may be interested in #5142
<mup> PR #5142: many: add "snap debug sandbox" and needed bits <Created by zyga> <https://github.com/snapcore/snapd/pull/5142>
<mup> PR snapd#5142 opened: many: add "snap debug sandbox" and needed bits <Created by zyga> <https://github.com/snapcore/snapd/pull/5142>
<zyga> mvo: I would look at linux fs/fat/namei_*.c
<mup> PR snapd#5056 closed: cmd/snap: make confinement mode part of `snap version` output <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/5056>
<zyga> it's very interesting
 * ogra_ would probably rather describe it as painful over "interesting" :)
<zyga> mborzecki: hey, how to check what a given shellcheck disable does?
<mborzecki> zyga: pick the error and visit https://github.com/koalaman/shellcheck/wiki/SC2164 (change the number as required)
<zyga> nice, thanks!
<zyga> I'll review your PR soon
<Chipaca> mborzecki: zyga: http://www.scp-wiki.net/scp-2164
<diddledan> dang, #2120 didn't make 2.42 :-(
<mup> PR #2120: Fix installed-size not being set in GET v2/snaps <Created by robert-ancell> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2120>
<diddledan> err
<diddledan> not 2120
<Chipaca> snapcraft#2120 ?
<mup> PR snapcraft#2120: many: dedup environment entries <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2120>
<diddledan> yeah that one
<sergiusens> diddledan: well, 2.42 is tagged and bagged, 2.43 or 2.42.1 from the looks of it, will come forward this week
<diddledan> in related news, though, `snap install --candidate gimp`
<sergiusens> but SRUing (which is what you want for build.snapcraft.io, takes at least a week of testing)
<Chipaca> zyga: https://pastebin.ubuntu.com/p/Dmv6qgQcd8/
 * zyga drives his mother home
 * diddledan drives his mother crazy
<zyga> Ooooh
<zyga> Chipaca: i love that
<zyga> Can we do an Easter egg where we snap install and run a dungeon snap
<zyga> Or one of those old zork emulators
<diddledan> what about some colossal cave quotes/actions?
<diddledan> snap look: you are in a maze of twisty passages all alike
<diddledan> snap xyzzy: nothing happens.
<kyrofa> Hey mvo, if/when you have a minute, I'd appreciate your eyes on https://github.com/snapcore/snapcraft/pull/2119
<mup> PR snapcraft#2119: repo: automatically prune unneeded stage-packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2119>
<kyrofa> mvo, the apt API wasn't quite doing what I thought it was doing
<Chipaca> zyga: the easter egg can be "snap debug looks for snap-debug-xyzzy when you try snap debug xyzzy", a la git
<zyga> Chipaca: oh
<zyga> that's nasty :)
<zyga> in a good way
<mborzecki> size-wise very nasty
 * zyga looks at lwn and notices that https://lwn.net/Articles/753646/ has escallated quickly 
<mborzecki> zyga: glibc joke?
<zyga> aha
<mborzecki> mid age drama :)
<mup> PR snapd#5132 closed: snap,wrappers: allow "external:{snapd,snapd.seeded}" for snap apps <Critical> <Squash-merge> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5132>
<zyga> mvo: closed?
<zyga> $ snap debug sandbox  https://www.irccloud.com/pastebin/h9EwxAUO/
<zyga> Chipaca: ^ any suggestions on output?
<zyga> I was wondering if I should prefix all seccomp/apparmor features with something like "kernel-"
<mborzecki> zyga: hacker news got agitated too https://news.ycombinator.com/item?id=17015644
<Chipaca> zyga: what would kernel- add?
<zyga> Chipaca: allow us to define our own flags
<Chipaca> zyga: i didn't follow
<zyga> in case we want to say "kernel-dbus" and "we-do-something"
<zyga> Chipaca: to namespace things
<Chipaca> zyga: these flag names come from the kernel itself?
<zyga> Chipaca: the list for apparmor and seccomp is coming from the kernel
<zyga> Chipaca: for the rest it's a hard-coded constant
<zyga> Chipaca: in case we want to have some constants and some kernel derived data
<zyga> just a thought
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/5141/files#r186756803
<mup> PR #5141: tests: shellchecks, part 1 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5141>
<zyga> mborzecki: all the 1117s feel like a bug on our end
<mborzecki> zyga: afaict we want the explicit "\n"
<zyga> mborzecki: my understanding is that it says "\n" works by accident and wants us to use "\\n" which works explicitly
<zyga> s/accident/fallback/
<mborzecki> zyga: hmm, but we do not want a newline ("\\n"), but an actual "\n" because this is passed to grep
<zyga> then we can use ' '
<zyga> hmm
<zyga> actually
<zyga> mborzecki: echo "\n" and echo "\\n"
<mborzecki> heh :) shell quoting
<zyga> this is what you want
<zyga> \\n is what we want IMO
<zyga> without -e "\n" is nothin gspecial
<zyga> *nothing special
<zyga> mborzecki: does it make sense?
<Chipaca> zyga: then yes I'd namespace them, or group them
<zyga> Chipaca: kernel:foo or kernel<foo> or kernel-foo
<zyga> Chipaca: what do you think we should use?
<mvo> zyga: yes, I will summarize in the forum but create a separate PR with the before= fix
<zyga> : is kind of nice
<zyga> mvo: ack
<zyga> thank you :)
<mvo> zyga: its doing more than we most likley need (and is a bit of a can of worms)
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/5141/files#r186759886
<mup> PR #5141: tests: shellchecks, part 1 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5141>
<mborzecki> zyga: in this particular case neither exit nor true makes sense probably
<Chipaca> zyga: kernel:foo to distinguish it from kernel-foo
<mborzecki> i bet this was refactored from install && exit 1 || true  to the current variant with MATCH
<Chipaca> zyga: ie explicitly namespaced
<zyga> Chipaca: thanks, I'll tweak that
<Chipaca> zyga: that way we can have kernel-foo and kernel:foo and they be different (although we should try not to :-) )
<mborzecki> Chipaca: if you feel like doing some reviews, can you take a look at 5141? specifically the places where SC1117 is disabled need shell-expert-in-quoting level input
<Chipaca> heh
<Chipaca> mborzecki: looking
<Chipaca> mborzecki: any reason not to instead double up on the \s we do mean?
<Chipaca> I mean, to give shellcheck credit, in "\d foo \"bar\" meep" it isn't immediately obvious that you want one, and not three, backslashes in the output
<Chipaca> mborzecki: should i just ask in the pr :-)
<cjwatson> zyga: you want printf - echo is unportable across different shells as soon as backslashes are involved, basically
<ogra_> +1
 * Chipaca thinks about mentioning $'' quotes, but decides against it
<ogra_> shellcheck -s sh ... usually even tells you
<Chipaca> ogra_: to be fair, spread checks are defined to be bash
<Chipaca> so bashisms are ok (and encouraged when they help legibility)
<ogra_> thats insane
<cjwatson> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html#tag_20_37_16 describes the unportability more precisely but it's basically the above
<mborzecki> and shellcheck is run with -s bash by the helper
<ogra_> but we had this discussion ( niemeyer and I) and  I lost back then
<cjwatson> IMO printf is more legible than remembering when to use echo -e, in any case :)
<mborzecki> cjwatson: definitely agree!
<zyga> cjwatson: ack, good suggestion
<zyga> much nicer "snap debug sandbox" https://www.irccloud.com/pastebin/7juy1qfc/
<zyga> Chipaca: ^ :-)
<Chipaca> you say that, but i might disagree
<Chipaca> i mean, it's impossibly wide now
<Chipaca> OTOH it's a debug tool
<Chipaca> eh
<Chipaca> zyga: what are the commas adding?
<zyga> Chipaca: nothing, just a list delimiter
<Chipaca> zyga: I'd drop them unless you expect a space in the identifiers
<Chipaca> zyga: either way it's good to go
<zyga> Chipaca: I can drop them, sure
<zyga> that's client side
<zyga> the API just gives you a list
<zyga> Chipaca: done now
<zyga> jdstrand: hey
<zyga> jdstrand: I'd like to query your TODO list, when do you think you can spare time to do a review of https://github.com/snapcore/snapd/pull/5081
<mup> PR #5081: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081>
<zyga> I would like to plan subsequent work based on that
<jdstrand> zyga: planning on it today
<zyga> woot, perfect, thank you!
<zyga> :-)
<zyga> Son_Goku: about my fedora-derivative
<zyga> Son_Goku: I called it "folded hat" as it referes to origami style of snapcraft logo and to the hat reference to fedora
<zyga> Son_Goku: gustavo suggested a more catchy name in case it sticks longer
<zyga> Son_Goku: do you have any suggestions or preferences?
<niemeyer> zyga: How about fcore28?
<zyga> hmm, I don't personally like that, it's not a nice word
<zyga> maybe just f28
<zyga> would calling it f28 be okay Pharaoh_Atem?
<zyga> as long as we call f "folded hat" inside
<zyga> and can rename to fedora once it is approved
<zyga> f28 would be really short and nice
<niemeyer> Short, but not quite nice
<Chipaca> niemeyer: well, the f28 is a fokker
<Chipaca> so that's nice
<pedronis> it sounds a fortran version
 * pedronis ducks
<niemeyer> fedcore28
<mvo> I declare victory over understanding the vfat uboot.env/UBOOT.ENV and get dinner
<Chipaca> mvo: congrats!
<mvo> Chipaca: thank you!
<Chipaca> mvo: I see some reference to FSCK0000.000 from people complaining about gparted, fwiw
<Chipaca> mvo: aha! dosfstools creates those files
<zyga> mvo: what's the root cause?
<Chipaca> mvo: (dosfstools is where fsck.fat lives â¦ so it's probably not news to you :-|)
<zyga> niemeyer: I would say that fedcore is too close to fedora that we should not use it without getting this acked by the fedora trademark owners; I honestly think the temporary name I originally selected was okay and it's just for one demo; perhaps I can just send the snap to neal instead of uploading it to the store
<niemeyer> zyga: The goal is for it to be too close to Fedora, I believe
<zyga> not really, it's based on fedora but doesn't use the name
<niemeyer> zyga: We don't need acknoledgement from anyone for the use of the prefix "fed".. I'm pretty sure there's even prior art here ;)
<zyga> once we can we should just call it what it is, fedora
<zyga> niemeyer: I don't want it to live on as fedcore, I'm sure fedora would not want that either (they would like to pick the name as they would maintain and publish the snap)
<zyga> again, this is a demo
<zyga> the real name will belong to fedora server team
<niemeyer> zyga: That's a pretty awkward rationale.. you're trying to find something that specifically doesn't sound like it's related to Fedora for something whose only point is being related to Fedora
<niemeyer> zyga: anti-goal
<zyga> I can call it zygonix, it's just a demo based on fedora without the trademark
<niemeyer> zyga: That's not a competition for awkward names
<niemeyer> zyga: fedcore has no trademark
<zyga> I'm not a lawyer
<zyga> I didn't want to use a prefix of the real name
<niemeyer> zyga: Exactly
<zyga> it's a _temporary_ name as the real snap will be published by fedora if they choose to pursue this
<zyga> if not we can remove it from the store
<niemeyer> zyga: That's what we're talking about
<pstolowski> pedronis: thanks for the review!
<pedronis> np
<pedronis> it was mostly already reviewed in the previous one
<pedronis> before the splitting out
<pedronis> sorry it took me a bit, we had long chat after the HO and also my internet connection has been giving me troubles today a couple of times since standup
<pstolowski> np!
 * zyga needs to head home
 * Chipaca calls it a day
<mup> PR snapcraft#2126 opened: packaging: load the correct libraries on armhf <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2126>
<mup> PR snapd#5143 opened: tests: speed up save/restore snapd state for all-snap systems suring tests execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5143>
<mvo> niemeyer: I replied to 5124 (just fyi) happy to implement either approach
<pedronis> mvo: at the start we are not seeded nor there's a seed change, so just looking for the change or no change at all is fragile
<pedronis> I commented in the PR about this as well
<niemeyer> mvo: I think it would make sense in general for the command to have an option to say "wait for the change to exist, if it's not there yet"
<pedronis> well that doesn't work after the change is done but pruned
<pedronis> it will never show up
<pedronis> I fear if we want to reuse watch  we need to add some custom code for these kind of  changes
<pedronis> or we don't prune suceeded seed or become-operational changes (but that doesn't cover preexisting systems)
<mup> PR snapd#5144 opened: tests: update bionic release image on gce <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5144>
<mup> PR core-build#29 opened: ubuntu-core-rootfs: deal with leftover fsck files <Created by mvo5> <https://github.com/snapcore/core-build/pull/29>
<mvo> pedronis: good point(s)
<pedronis> tbh there is some argument to keep the last  seed and become-operational forever (for transparency) but wouldn't help for systems already out there since a bit
<zyga> Im home now
<zyga> Had to walk a bit because all the bikes were gone
<mup> PR snapcraft#2127 opened: delta: properly search for in-snap xdelta3 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2127>
 * cachio_ afk
<mup> PR snapcraft#2126 closed: packaging: load the correct libraries on armhf <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2126>
<mwhudson> is there a way to make snap dump out the api requests it's making to snapd?
#snappy 2018-05-09
<eraserpencil> when i "df -h" on my ubuntu machine, I get a lot of /snap/core/xxxx. what are these and why cant i remove them?
<mwhudson> eraserpencil: snaps are distributed as squashfses, so those are the mount points for them
<mborzecki> morning
<zyga> Good morning
<mborzecki> zyga: hey
<zyga> How arÄ things
<zyga> ArÄ, omg :-)
<mborzecki> heh
<zyga> Quick brekfast and reviews, reviews
<mborzecki> went to manufaktura yday, to meet some friends, left the car in the parking lot and came back to this: https://i.imgur.com/2Pis8il.jpg
<mborzecki> apparently some lady in her grand white bwm had trouble maneuvering the parking lot, knocked down 'give way' sign, hit my car and took off
<zyga> Holly Caro
<zyga> This sucks,
<mborzecki> spent 3h waiting for the police to come to write the report and secure monitoring footage
<zyga> But they should have her plate on camera
<zyga> Excellent
<zyga> Well
<zyga> Considering
<zyga> I hope she is caught quickly
<mborzecki> yeah, me too
<zyga> BMW is always something nasty in practice :-(
<mborzecki> on a side note, i really hate going to manufaktura, it's always super crowded
<zyga> I havenât been there yet
<zyga> I need to plan a trip to ÅÃ³dÅº :-)
<mborzecki> need to go to the hospital for a checkup, be back in ~2h
<pstolowski> mornings
<pstolowski> mborzecki: crap... good luck with that, i hope it won't take long to get resolved
<pedronis> pstolowski: hi, are you working on the post about disconnect/undo and interface hooks? or did you already and am IÂ not seeing it?
<pstolowski> pedronis: i didn't, i'm about to do it today
<pedronis> thx
<Chipaca> moin moin
<mvo> ogra_: can I make the pi2 boot output everything on the serial terminal somehow? currently I only get "booting kernel" and thats it
<mvo> Chipaca: hey
<popey> diddledan: reckon we should push gimp rev 37 to stable?
<ogra_> mvo, edit cmdline.txt, drop the console=tty0
<mvo> ogra_: ta
<mvo> ogra_: much better now :)
<ogra_> :)
<pedronis> pstolowski: I did a first pass over 4510
<pstolowski> pedronis: thanks
<mborzecki> re
<mborzecki> pstolowski: heh, notice the dark spot just in front of the car? https://i.imgur.com/nyDMOOQ.jpg this is where the sign was
<Chipaca> pedronis: if you could give the comments on #4790 a once-over just to make sure, I'd appreciate that
<mup> PR #4790: jsonutil/puritan: introducing puritan.String & etc <Created by chipaca> <https://github.com/snapcore/snapd/pull/4790>
 * Chipaca updates the description there
<pedronis> Chipaca: yes, one sec
<mborzecki> i still don't get how it's possible to pull shit like this with all the parking assitance, sensors, cameras etc.
<pstolowski> mborzecki: unbeliveable
<Chipaca> mborzecki: what happened?
<pedronis> Chipaca: looks good, but if you put an emoji in those comments my browser cannot or github is doing something that doesn't render it properly
<mborzecki> Chipaca: a lady in a large white bmw knocked down a give way sign and hit my car, then she took off
<pedronis> Chipaca: I see ï¿½
<Chipaca> pedronis: yes
<Chipaca> pedronis: I mean, I wrote a ï¿½
<mborzecki> Chipaca: all in a parking lot of a go-to shopping plaza in lodz, so lots of industrial cameras etc
<Chipaca> mborzecki: so they've got you covered? ie the plaza security people?
<pedronis> Chipaca: is that special?
<mborzecki> Chipaca: yeah, i called the police, waited 3h for them to get there, write a report and secure the footage
 * pedronis is likely missing something
<Chipaca> pedronis: maybe I should write âï¿½ (U+FFFD)â?
<Chipaca> mborzecki: :-/ were you stuck there alone?
<pedronis> Chipaca: you remove the charatecter that usually means something else couldn't process things?
<pedronis> just so IÂ understand
<Chipaca> pedronis: pretty much, yes
<Chipaca> pedronis: the strings are supposed to be valid utf8, so it shouldn't happen
<Chipaca> pedronis: and in fact they have to be, per json
<Chipaca> pedronis: so the only reason U+FFFD appears is if somebody intentionally put it there
<pedronis> Chipaca: ok, then   yes a paranthesis (U+FFFD, aka replacement character) would be useful
<Chipaca> and putting a character that means "something broke", intentionally, is not cool
<mborzecki> Chipaca: nah, i was meeting with some mates before, so we stayed in the parking lot chatting and waiting for the police :)
<Chipaca> mborzecki: "we waited, chatting and having a few beers"
<Chipaca> :_D
<pedronis> Chipaca: because otherwise somebody looking at that code will be confused about the replacement character showing up just as itself :)
<pedronis> as I was, maybe
<mborzecki> Chipaca: technically they had a few, i only had a soda and a tea :)
<Chipaca> pedronis: â¦ and that's why it's disallowed :-)
<Chipaca> mborzecki: :-)
<Chipaca> pedronis: there
<niemeyer> Morning folks
<pedronis> Chipaca: thx
<Chipaca> pedronis: now to wait for it to green
<pstolowski> pedronis: https://forum.snapcraft.io/t/disconnect-hooks-howto-undo-connect-hooks/5339 ; let me know if I missed something
<mup> PR snapd#4983 closed: osutil/sys, client: add sys.RunAsUidGid, use it for auth.json <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4983>
<mborzecki> Chipaca: you make my heart break ^^
<Chipaca> mborzecki: ikr
<mborzecki> Chipaca: runuser it is then?
<Chipaca> mborzecki: runuser + dd + mv + sync, probably
<Chipaca> for the write case
<ogra_> mvo, regarding your uboot.env research, you might also want to take a look at what systemd does to the partition (i think it runs an fsck too before mounting)
<Chipaca> mborzecki: arch doesn't use a weird dd or sync does it?
<Chipaca> mborzecki: i mean, all from coreutils?
<mborzecki> Chipaca: woo, nice combo, iirc in case we ever need it runuser suppors switching selinux contexts too (or maybe some other tool?)
<Chipaca> should I give up and just hand it off to /bin/sh
<Chipaca> grmbl
<mborzecki> Chipaca: nothing weird with dd or sync here
<Chipaca> k
<mvo> ogra_: yes, we do that (we set the fstab line to fs_passno to 2). it looks like this is part of the problem, fsck.vfat corrupts more than it fixes :(
<mborzecki> mvo: meanwhile, patching u-boot would be nice too, if you upload the boot partition somewhere i could take a stab at it over the weekend
<mvo> mborzecki: sounds good, I will send you the link to the corrupted image. I think the upper/lower case is a bit of a red-herring, it comes down to "lfn" (long-file-name) directory entries
<mvo> mborzecki: what is super annoying is that its really hard to recover once there is this corrupted file on disk
<mborzecki> mvo: running fsck does not fix it right?
<mvo> mborzecki: it claims it does, but I think it leaves the directory entires on disk in a state that confuses uboot so next write uboot will pick up the wrong file (short name fsck0000.000) again
<mvo> mborzecki: which is super annyoing nice that was got delete in my fixup script
<zyga> mvo: will we use the repair assertion?
<mvo> mborzecki: this is the only way that worked so farhttps://paste.ubuntu.com/p/ySvHbxRVH9/  - slightly terrible though
<mvo> zyga: interessting idea
<mvo> zyga: fixing this oob might not be a bad option
<mvo> zyga: my goal was to fix in initramfs but its harder than I anticipated
<zyga> what will we do about affected devices?
<zyga> they are "bricked" right?
<mborzecki> mvo: do you think there's a chance the file could have been there in the original image that was shipped with the devices?
<mvo> mborzecki: that is possible. however my theory is that our fsck created it. from looking at the code there it seems to rename files under some cirumstances but keep the lfn (long-file-name) the same, my theory is explained inhttps://github.com/dosfstools/dosfstools/pull/83  but no feedback yet
<mup> PR dosfstools/dosfstools#83: [RFS] check.c: do lfn_remove  on auto_rename() <Created by mvo5> <https://github.com/dosfstools/dosfstools/pull/83>
<mvo> mborzecki: we run fsck.vfat on mount for /boot
<mvo> mborzecki: even more annoying we don't have enough modules in initrd to mount as vfat and copying stuff around there is jjust terrible, i.e. this will be totally broken when the power is cut at the wrong point. so I'm still looking for options
<mvo> mborzecki: maybe I should write what I found in the forum to ensure everyone knows what is going on
<mborzecki> mvo: fwiw uboot ENV_IS_IN_FAT is a questionable idea
<mvo> mborzecki: what can we do to fix that?
<pedronis> pstolowski: seems to capture the problem, made a comment of a possible variant, IÂ suppose we need to discuss with niemeyer the options
<mborzecki> mvo: it'll be risky for devices that are already deployed
<mvo> mborzecki: yeah :/
<mborzecki> mvo: but i'd recomment ENV_IS_IN_MMC, and put it somewhere at the boundary of 2 separate erase block sizes (you'd really know what the size is with mmc but you can try and do an educated guess, or side channel benchmarks to find out)
<mborzecki> mvo: and instead of parsing uboot's env manually, work with fw_printenv/fw_setenv instead
<zyga> offtopic
<zyga> have you guys seen "checks"
<zyga> https://github.com/snapcore/snapd/pull/5144/checks for example
<mup> PR #5144: tests: update bionic release image on gce <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5144>
<mvo> mborzecki: the idea ENV_IN_MMC sounds good, we should talk about this after the fire is over. portability comes to mind. the fw_printenv stuff we did initially but it had its own set of problems, I need to dig into git history (and memory) to remember those.
<mborzecki> mvo: yeah, setting up fw_env.config is quite funny :)
<mvo> mborzecki: I think we actually are more careful with our writes than fw_setenv (but I'm biased so happy to accept that I'm wrong)
<mvo> (or grudgingly accept it)
<mborzecki> mvo: experimentation is key :)
<mborzecki> otoh, pull a power plug on rpi and there's a chance it's not coming back up
<mvo> mborzecki: yeah
 * Chipaca despairs and switches branches for a bit
<pstolowski|bbiab> pedronis: thanks
<mup> PR snapd#5073 closed: set up journal streams in user session application autostart (2.32) <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5073>
<popey> om26er: https://github.com/snapcrafters/android-studio/issues/23 :)
<niemeyer> mvo: +1 for following up in the forum
<mup> PR snapd#4387 closed: interfaces/gpg-keys: force use of '--no-random-seed-file' via explicit deny <Blocked> <Created by jdstrand> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/4387>
<diddledan> popey: yeah, everyone who's tested gimp 37 has reported back positively. let's ship it
<Chipaca> mvo: I feel you're missing a 'GOTO 4' in your sequence of events
<mvo> Chipaca: good point, I added a 10 which is not quite GOTO but close
<Chipaca> :-)
<diddledan> popey: I've just done it
<diddledan> popey: prepare for the hoards of complaints :-p
<popey> WoooHooo!
<popey> Thanks diddledan !
<ogra_> mborzecki, mvo, the only proper solution is to use u-boot only as SPL for a UEFI grub boot ... get rid of all u-boot patching, completely de-couple the OS by simply chainloading grub-UEFI ... redhat and opensuse only support that model nowadays and we should too (i had quite some discussions with the maintainers of both distros during embeddedworld)
<ogra_> mvo, i was wanting to write a prototype for this but customer work is eating my time
<diddledan> running snapcraft in an i386 container (lxd) on an amd64 host I'm getting: "sudo: main: unable to allocate memory" when it tries to install apt packages
<ogra_> mvo, we'd only need to maintain grub.cfg and porters can use u-boot as-is from their BSP
<ogra_> (no patching at all)
<ogra_> (along with that you get the full UEFI secureboot setup for free )
<mup> PR snapd#5145 opened: boot: clear "snap_mode" when needed <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5145>
<mvo> Chipaca: someone with a fresh and sharp mind should look at 5145
<Chipaca> mvo: we should hire somebody like that
<mvo> Chipaca: this should give us the first line of defense, i.e. no more bricking but also no more refreshes
<mvo> Chipaca: lol
<Chipaca> mvo: where does "trying" come into the picture
<Chipaca> ?
<ogra_> mborzecki, mvo in case one of you wants to take a look, http://download.opensuse.org/ports/armv7hl/factory/images/ has all images using this setup (not sure if the RH images are public, but it is a well maintained setup nowadays and has active upstreams)
<mborzecki> ogra_: thanks, will take a look
<mborzecki> ogra_: wow ..sabrelite, brings back bad memories
<ogra_> haha, yeah, i still have one running here with a 15.04 core install
<ogra_> (i still love the full SATA it has)
<mvo> Chipaca: trying is usually cleared by the snapd boot code, i.e. it switches to "". it is only used so that uboot knows it tried to boot and things did not work at all in which case it reverts back to the good core/kernel
<pedronis> mvo:  is the state sequence   try ->  trying -> "" ?
<mvo> pedronis: correct
<mvo> pedronis: I can write something in the forum if you want, seems like this should be documented better
<zyga> mvo: should snapd remove all the uboot.env files and write a new one to "recover"?
<mvo> pedronis: snapd sets to "try", bootloader from "try" to "trying" and snapd (after reboot) from trying to "" if things went well
<zyga> (recover FAT)
<Chipaca> mvo: would detecting the breakage and re-writing the boot partition be doable?
<pedronis> mvo: yes, IÂ see only a not very complete comment in partition/bootloader.go
<mvo> Chipaca, zyga yes, remove and rewrite seems to work
<zyga> mvo: as in while uboot.env exits, remove it // tricky
<mvo> Chipaca, zyga not very atomic but give this is already a holly-crap situation maybe an acceptable workaround
<mvo> pedronis: sure, will do
<zyga> this is somewhat less nuclear than repartitioning /boot
 * zyga -> coffee
<mvo> zyga: yeah, let me try something like that
<pedronis> we also should consolidate this code at some point, is a bit spread around  partiation snapstate etc
<mvo> pedronis: good point
<pedronis> anyway
<pedronis> mvo:  I think this also shows the issue that we need to detect reboot vs restart
<pedronis> which is a TODO pending since a bit
<mborzecki> pedronis: restart as in restart due to a failure?
<pedronis> yes
<pedronis> anyway IÂ looked at the PR and it's probably less urgent than IÂ thought
<mvo> pedronis: at what PR did you look?
<pedronis> your new PR
<mvo> pedronis: less urgent? how so?
<pedronis> mvo: your new code seems correct either way
<mvo> pedronis: aha, yes
<pedronis> mvo: aynway at some point you should review my #4497
<mup> PR #4497: many: make rebooting of core on refresh immediate, refactor logic around it <Created by pedronis> <https://github.com/snapcore/snapd/pull/4497>
<mvo> pedronis: thats a nice aspect about it, it also fixes the case when we snap refresh new-core, snap refresh current-core without a in-between reboot
<mvo> pedronis: yes, once the fires are out :) the next big fire for today is the snapd.seeded.service thing
<niemeyer> mvo: Let me know if/when you want to discuss it
<pedronis> niemeyer: I commented in the PR to your suggestion
<niemeyer> pedronis: I've seen it, but not sure I'm reading your point completely
<pedronis> niemeyer: I'm just trying to double check that we are doing this because we think snap wait  snap  key  will be generally useful, we will promote it
<niemeyer> pedronis: Right, that was the idea.. I think waiting for a state on the snap sounds generally useful
<niemeyer> pedronis: snapd and otherwise
<pedronis> niemeyer: ok,  but this state is config right?   IÂ mean snapd itself is already using bits of config to expose state, I'm just making sure we think that's the way to go also for other snaps
<mup> PR core-build#29 closed: ubuntu-core-rootfs: deal with leftover fsck files <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core-build/pull/29>
<pedronis> niemeyer: it will need to fit in in schemas as well when we get there
<niemeyer> pedronis: Not sure there's much to add in terms of schema
<pedronis> niemeyer: well, we want to make this things read-only no?   IÂ don't think we want a user to  do  snap set system seeded false
<niemeyer> pedronis: Config is state.. can't see it otherwise
<pedronis> IÂ mean read-only from outside the snap
<pedronis> or at least the snap should have that choice
<niemeyer> pedronis: Yeah, I think this depends on the use case at hand.. properties that are read-only outside the snap is definitely sensible
<niemeyer> pedronis: For seeded it makes sense too
<pedronis> indeed, that would fit into schemas
<mup> PR snapd#5146 opened: tests: fix user mounts test for external systems <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5146>
<mborzecki> zyga: Chipaca: updated 5141
<pedronis> niemeyer: and maybe my questions were redudant but we have already so many concepts flying around, I wanted to make sure the plan was what it looked like
<zyga> ack
<niemeyer> pedronis: The question seemed fine.. I was just concerned about missing some deeper underlying point
<mvo> niemeyer: probably after the standup, still working on mitigation on the vfat bug
<hi> Hi every one
<pstolowski> niemeyer: hey, i've documented https://forum.snapcraft.io/t/disconnect-hooks-howto-undo-connect-hooks/5339 , we should discuss the options
<Guest57528> i just want to know the command in snap.yaml file
<zyga> mborzecki: +1
<mup> PR snapcraft#1064 closed: pluginhandler: collide with directories and symlinks <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1064>
<peter___> HELP
<peter___> Any one tell me the command line process inside the snap.yaml file
<diddledan> huh?
<peter___> (App: Command: )in snap.yaml
<zyga> peter___: can you explain what you mean by that?
 * cachio_ afk
<peter___> I am not clear with (Command: Path to executable (relative to snap base) and arguments to use)?
<zyga> peter___: it is the command you want to associate with a given application
<zyga> peter___: any shell command you want to run
<peter___> I am new to snap.
<pstolowski> mvo: do you need more eyes on #5095? it has +2 and could be merged
<mup> PR #5095: snapstate: support getting new bases/default-providers on refresh <Created by mvo5> <https://github.com/snapcore/snapd/pull/5095>
<pedronis> pstolowski: it says explicitly it's missing spread tests
<pstolowski> pedronis: ah, right, should be marked blocked then
<pedronis> yea, doing that
<pstolowski> we did at the same moment ;)
<pedronis> :)
<pedronis> I see alot of branches failing spread tests today?
<zyga> I see timeouts
<pedronis> Chipaca: your safejson PR for example
<jdstrand> niemeyer: hi! I responded in https://github.com/snapcore/snapd/pull/4387
<mup> PR #4387: interfaces/gpg-keys: force use of '--no-random-seed-file' via explicit deny <Blocked> <Created by jdstrand> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/4387>
<Chipaca> pedronis: yes, timeouts downloadin core from the store
<Son_Goku> meeep
<niemeyer> jdstrand: Responded
<niemeyer> pstolowski: Thanks for the post!
<newbee> my project developed in netbeans how to create snapcraft.ymal for this, please assist
 * Chipaca ~> lunch
<pedronis> newbee: for java we have these docs: https://docs.snapcraft.io/build-snaps/java  , and snapcraft plugins has maven, gradle and ant plugins for dealing with java projects
<newbee> i have installed snapd and snafcraft snap on my linux mint 18. in netbeans IDE8 i have created a java helloworld program. after that i created a snapcraft build and snapcraf.ymal file is generated
<newbee> in this snapcraft.ymal file how to mention the hellowrold program
<zyga> hmm
<zyga> cat: write error: No space left on device
<zyga> that's on opensuse
<zyga> Chipaca: could slow / failed / retried downloads fill the disk of a VM?
<zyga> newbee: hey, have you seen: https://snapdocs.labix.org/the-snap-format/698 ?
<pedronis> newbee: what does the build produce  a jar ? something else?   in that doc example  the command goes into  apps: freeplan: command: (see the Apps section there)
<newbee> zyga: thanks, we have go through the snapcraft.io documents in ubuntu core site, will try this too..
<pedronis> zyga: your new doc page mentions a command that is not there yet?  it should probably list in which versions the various commands appeared
<zyga> pedronis: ah, great point, I'll add that
<newbee> pedronis: yes its creating .jar file, but in that we confused what are the commands should we use.
<zyga> pedronis: done
<pedronis> zyga: I think we just discovered that discourse has no conflicts checks
<zyga> pedronis: indeed, my changes are gone
<zyga> what did you do?
<pedronis> zyga: I did an edit too, it seems your changes are not there
<pedronis> I edited the last section about get-base-declaration
<pedronis> sorry :/
<zyga> no worries
<zyga> I'll add the edits back
 * zyga holds the forum lock ;-)
 * zyga drops the forum lock
<newbee> pedronis / zyga : sorry for the intruption, do you got my question..
<zyga> newbee: whatever commands are appropriate to run a jar file
<zyga> java -jar ... probably
 * zyga needs to take the dog out
<zyga> ttyl
<newbee> also want to know does the snap can be decompile ?
<pedronis> newbee: it's not compiled, is just a compressed filesystem
<pedronis> if you care about obfuscation you need to add it at the level of compiling/producing the jar
<newbee> is there any other sites to refer to create snapcraft.ymal file...?
<newbee> also please share example snapcraft.ymal file for java application ...
<zyga> It should be all documented
<zyga> Did you google for that?
<pedronis> newbee: here's is an example for a jar:  https://github.com/snapcore/snapcraft/blob/master/demos/gradle/snap/snapcraft.yaml
<jdstrand> niemeyer: responded
<newbee> pedronis: ok, will try with this..
<pedronis> newbee: what java plugin are you using?
<sergiusens> niemeyer: morning, hope the trip back home was good. Pinging you to see if we can get an rfc (request for comment) tag on the forum, to be used to specs and user stories of the work ahead so we can easily find them later.
<pedronis> newbee: you can do snapcraft prime   and look around in prime to see what gets built, where things are
<newbee> @pedronis : we are using netbeans default plugin - ant
<pedronis> ok
<niemeyer> sergiusens: Sounds reasonable, but request-for-comment and spec is not the same thing.. user stories is also not a spec.. how about a more general "design" tag?
<pedronis> newbee: this one example is using ant:  https://github.com/snapcore/snapcraft/blob/master/demos/java-hello-world/snap/snapcraft.yaml
<ogra_> niemeyer, oh, while sergio brings this up, does discourse have a way to allow more than one category for a post (a config option etc) .. . i often have posts that would benefit from being able to be in more than one category (specifcally in the device section)
<sergiusens> niemeyer: +1 on design tag
<Chipaca> ogra_: maybe device should be a tag instead of a category?
<newbee> @pedronis: Thanks, please clarify my understanding , in the command i have to mention the java path and the project path ..
<ogra_> Chipaca, dunno, would people still use it then ? the category is pretty visible which is helpful
<ogra_> it just happens often enough that i think "hmm, tis happens on core but would benefit from more attention via the snapd category" ...
<niemeyer> ogra_: No, one per post only
<ogra_> niemeyer, ok, thanks
<mvo> pstolowski: if pedronis is happy with 5095 then I would say we should merge it
<mvo> pstolowski: aha, spread tests, nevermind
<pedronis> mvo: I haven't checked it carefully but indeed spread tests
<niemeyer> sergiusens: done
<mup> PR snapd#5147 opened: snapd.core-fixup.sh: add workaround for corrupted uboot.env <Created by mvo5> <https://github.com/snapcore/snapd/pull/5147>
<pedronis> newbee: I'm not sure  what you mean with project path, the command can refer only to things inside the snap,  as I said, if you runÂ "snapcraft prime"   and look into the created "prime" dir  you should see what is inside and where
<pedronis> *things inside the snap or provided by the core snap
<newbee> @pedronis- ok will try, thanks
<niemeyer> Hey, just heating up some water.. will be with you in a moment
<Chipaca> pstolowski: https://www.reddit.com/r/AskReddit/comments/7r1395/besides_bmw_which_car_has_the_douchiest_drivers/
<sergiusens> thanks for the tag!
<pstolowski> Chipaca: ty :)
 * diddledan twiddles his thingies until alsa-project.org comes back online
<um1b0zu> is snap core down?
<pstolowski> Chipaca: on that note, we have a joke - since they generally don't use turn indicators here: the guy shows up at a car service saying his front light broke as it's blinking all the time
<um1b0zu> I've been trying to install a few packages and also just search the website
<pstolowski> um1b0zu: store is having issues today, yes
<um1b0zu> and I keep getting 500 and timeout errors
<um1b0zu> ok. so it's not a me problem
<um1b0zu> thanks!
<Chipaca> um1b0zu: https://status.snapcraft.io
<Chipaca> um1b0zu: down: very yes
<Chipaca> um1b0zu: although it might be coming back :-)
<pstolowski> and also https://forum.snapcraft.io/t/intermittent-outage-on-snap-downloads-and-uploads/5342
<um1b0zu> nbd I just figured I'd ask
 * zyga is back home now
<Shmam> Will snap packages use the same gtk settings?
<zyga> a storm is coming here
<ogra_> was that a trump reference ?
<zyga> it's a hot day, who knows ;)
<ogra_> :D
<cwayne> ogra: he said a storm, not a stormy
<ogra_> cwayne, didnt he qoute SNL ?
<ogra_> *quote
<cwayne> ogra_: oh dunno, didn't see it yet
<ogra_> heh
<ogra_> dont want to spoil ya then :)
<cwayne> lol
<zyga> I think in US the weather is officially "shit storm"
<zyga> here it's just rain
<zyga> and warm air ð
<popey> s/weather//
<kjackal_> Hi jdstrand. I am working on microk8s and it seems I am hitting a permission denied from AppArmor when trying to terminate a pod. However I am on devmode.
<zyga> kjackal_: hey, perhaps I can help you
<zyga> what is the denial that you see?
<kjackal_> Hi zyga, it is a permission denied from a docker deamon trying to sent signal kill 15 to a container
<zyga> kjackal_: can you please paste the denial
<kjackal_> let me see if i can spot it, give me a moment
<zyga> kjackal_: dmesg | grep DENIED might help
<kjackal_> zyga: let me ping you in a few minutes. I need to redeploy, just a sec
<zyga> sure
<kjackal_> zyga: are you still there? https://pastebin.ubuntu.com/p/d9pgT6sFXj/
<zyga> sure
<kjackal_> last couple of lines
<kjackal_> 4 lines
<zyga> kjackal_: thanks, can you dmesg | grep DENIED
<zyga> and pastebin that
<zyga> what I see is May  9 09:18:03 jackal-VGN-FZ11M kernel: [ 2699.709975] audit: type=1400 audit(1525846683.188:298601): apparmor="DENIED" operation="signal" profile="docker-default" pid=23021 comm="containerd" requested_mask="receive" denied_mask="receive" signal=kill peer="snap.microk8s.daemon-docker"
<zyga> but I want to make sure we're not missing something
<zyga> what is interesting is that this is the profile for docker, not for the snap, that is in the way
<kjackal_> https://pastebin.ubuntu.com/p/6bhqbBjKVQ/
<kjackal_> zyga: How does it get decided which profile to be used?
<kjackal_> is there some kind of pattern matching?
<kjackal_> If I rename the snapped docker daemon to something else would the right profile be used?
<zyga> kjackal_: this profile (docker-default) comes from docker, not from snap world
<zyga> it looks like a bug in docker
<zyga> I'm not a docker person, just googled for this and found https://docs.docker.com/engine/security/apparmor/
<kjackal_> For reference here is the snapcraft yaml https://github.com/juju-solutions/microk8s/blob/master/microk8s.yaml
<zyga> again, this is not related to snaps
<zyga> this is a profile generated by docker that doesn't allow container processes to be signalled
<zyga> it probably allows them to be signal by unconfined peers
<zyga> but not by confined peers
<zyga> please report this to docker
<kjackal_> zyga: How does devmode work? Do snaps in devmode apply their own apparmor profiles?
<zyga> devmode doesn't affect this
<zyga> the profile is that of docker, not snaps, docker snap or anything
<zyga> devmode works by using advisory confinement
<zyga> but again
<zyga> this is not related to devmode or snaps, look at the profile="..." string there
<zyga> if this were a snap profile it would say profile="snap.something"
<kjackal_> This is why I am asking, on all other snapped daemons the snap.samthing profile was used but not in the case of the snapped docker. I read at the docs of docker I could provide my own apparmor profile. I was wondering if in devmode one such profile already exists
<zyga> kjackal_: docker apparently generates its own profiles
<zyga> and has permissions to break out of confinement
<zyga> I don't know enough about docker to tell you more, I would suggest that you seek help with docker developers to ask about changing the automatically generated profile to allow it to send signals to confined processes
<kjackal_> zyga: question on snap created profiles. Where can I find the apparmor profiles applied in the case of devmode?
<kjackal_> Are there any files generated somewhere?
<zyga> in the same place as other profiles, they are all in /var/lib/snapd/apparmor/profiles
<kjackal_> awesome thanks
<kjackal_> will try that zyga, thanks
<zyga> good luck
<vidal72[m]> are snap packages and components builded with same flags as normal deb packages in ubuntu? i.e. are security related flags enabled by default (pie,ssp,rerlo,bindnow, fortify)?
<zyga> vidal72[m]: not necessarily
<zyga> noise][: is the store running again?
<noise][> zyga: yes, we are just waiting for a bit more stability time before updating announcements
<zyga> thanks!
<vidal72[m]> zyga: why?
<vidal72[m]> nowadays all major distro harden building packages, if snap doesn't then installing snap is a step back in this aspect
<zyga> vidal72[m]: because snaps don't mandate how software is built
<zyga> vidal72[m]: you can certainly harden your snap but there's no requirement that everyone does that or enforcement of that
<vidal72[m]> zyga: opt-in security?
<zyga> I don't know what you mean by that
<vidal72[m]> zyga: if snap creator doesn't care about hardening build then it won't be hordened...
<zyga> vidal72[m]: do you have a well defined definition of hardening and a reliable way to check?
<zyga> vidal72[m]: don't get me wrong, it's nice to improve stuff but this is not an easy task
<zyga> vidal72[m]: people find packaging hard as-is
<zyga> vidal72[m]: and distributions don't agree on hardening concepts or use same defaults or toolchain versions and patcehs
<zyga> *patches
<vidal72[m]> zyga: things which I mentioned are enabled by default in fedora,debian,ubuntu,archlinux,gentoo and probably more...
<zyga> vidal72[m]: can you be specific, which things
<vidal72[m]> zyga:  pie,ssp,rerlo,bindnow, fortify
<vidal72[m]> see links included in https://github.com/flathub/flathub/issues/353
<zyga> and how do you verify that those are set?
<zyga> vidal72[m]: what I'm trying to point out is that while an individual snap may be as hardened as you want, in general snaps don't come with source or build instructions and there's no way to require hardening
<zyga> vidal72[m]: we can improve snapcraft and the defaults used there
<zyga> vidal72[m]: and I would gladly support that
<zyga> vidal72[m]: I was just trying to explain my point
<vidal72[m]> zyga: there should be some way to pass some defaults to gcc during build
<zyga> vidal72[m]: we can improve snapcraft and the defaults used there <- I know
<vidal72[m]> flatpak
<vidal72[m]> zyga: sounds good
<vidal72[m]> zyga: flatpak is going to set in in runtimes (sdk)
<zyga> vidal72[m]: and is Spotify flatpak hardened? no because it's not using that
<vidal72[m]> zyga: https://github.com/flatpak/flatpak-builder/pull/142
<mup> PR flatpak/flatpak-builder#142: Load libdir and flags from SDK configuration file <Created by valentindavid> <Closed by alexlarsson> <https://github.com/flatpak/flatpak-builder/pull/142>
<zyga> kalikiana,sergiusens: ^ what is the hardening story in snapcraft?
<vidal72[m]> zyga: almost nothing (except runtimes) are hardened in flatpak yet. Spotify isn't builded from source so it isn't target for hardening.
<sergiusens> vidal72[m]: zyga I am all for it, but I would defer to the security team on that. If CFLAGS and such are already exported it is already achievable
<kyrofa> Yeah it wouldn't be hard, but it will obviously depend on the plugin being used
<tomwardill> zyga (and everyone): store is back and operating normally, FYI
<zyga> thank you!
<vidal72[m]> PIE and SSP can be enabled in gcc config. Probably they are enabled in ubuntu gcc package already.
<popey> tomwardill: thanks!
<mvo> pedronis, niemeyer I updated 5124 based on the feedback. it lacks some more unit tests but I would love to get a first look to ensure naming/approach is in line with what we discussed and I also need dinner :)
<pedronis> mvo: I don't like seed.done for what is worth
<mvo> pedronis: ok, just leave a comment for niemeyer I have no strong opinion about the particular name
 * zyga prefers the original "seeded"
<kyrofa> sergiusens, this diff allows classic snaps to be built on trusty... but I'm not sure why we're doing that in the first place: https://pastebin.ubuntu.com/p/jmnJCtpP75/
<kyrofa> LD_LIBRARY_PATH seems odd for classic
<kyrofa> Will this break other things? Or is that old?
<pedronis> mvo: did you discuss it with him already?
<kyrofa> Especially given that the host was already determined to be compatible with the core snap. Might as well just let it build against its own
<pedronis> mvo: it sounds very unenglish as well,  it would have to be seeding.done
<pedronis> seed as name is not an action afaik
<kyrofa> sergiusens, also, I'm fixing a conflict here but it could use another pass when you're able: https://github.com/snapcore/snapcraft/pull/2122
<mup> PR snapcraft#2122: many: introduce variables for part src and build <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2122>
<zyga> jdstrand: is that what you expected: https://github.com/snapcore/snapd/pull/5107/commits/bfdd7caca6dfb81df6fe7e218d3bd4d93dc08a87
<mup> PR #5107: cmd/snap-update-ns,tests: mimic the mode and ownership of directories <Squash-merge> <Created by zyga> <https://github.com/snapcore/snapd/pull/5107>
<mup> PR snapcraft#2127 closed: delta: properly search for in-snap xdelta3 <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2127>
<sergiusens> kyrofa that is there to be able to find libraries from the base when doing the elf search
<kyrofa> sergiusens, what happens if we don't do that? We build against the host, but then fix all the rpaths when priming to use the base
<kyrofa> Is that bad?
<jdstrand> zyga: that looks like a nice choice, yes
<jdstrand> kjackal_ (cc zyga): so, the issue is that signal rules have two sides: the sender and the receiver. the sender needs to be able to send to the receiver and the receiver needs to be able to receive from the sender
<zyga> jdstrand: ack, here the profile created by docker for the container doesn't allow this
<jdstrand> kjackal_ (cc zyga): so while microk8s is allowed to send to the receiver because of devmode, the receiver (in this case the process running under the 'docker-default' apparmor profile) is not allowed to receive the signal from microk8s
<jdstrand> kjackal_ (cc zyga): this is a variation of https://forum.snapcraft.io/t/htop-snap-unable-to-signal-aa-enforced-processes/5222/2
<jdstrand> kjackal_: it seems like microk8s is trying to talk to docker install via a deb. is this accurate?
<jdstrand> installed*
<kjackal_> jdstrand: yes, we deploy dockerd from docker.io
<zyga> that last link is very interesting, thank you for sharing
<kjackal_> jdstrand: is there another option?
<zyga> jdstrand: just as a quick check in #5090 is there a deeper issue or are you just after the comment changes?
<mup> PR #5090: cmd/snap-update-ns: poke holes when creating source paths for layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/5090>
<jdstrand> kjackal_: honestly, I thought that microk8s would ship its own docker and plugs 'docker-support'
<jdstrand> kjackal_: you *could* use a deb or other docker, but you would *not* be able to send signals directly to those processes, because those docker's don't know about microk8s and to add the signal receive rule
<jdstrand> kjackal_: you *could* instead of sending signals directly use the docker socket to manage the containers though
<jdstrand> kjackal_: even more honestly, I thought k8s used its own runc and didn't use dockerd, but I'm not up on the current implementation
<jdstrand> zyga: yes-- all comments. based on your answer for returning the changes, I requested a comment there too
<sergiusens> kyrofa: as we everything classic, we will need to try it out.... this is mostly for the ldd story (if memory serves correctly), so there might be side-effects
<wililupy> I'm trying to use the layout feature in snapcraft but I am getting the following error: Issues while validating None: Additional properties are not allowed ('layout' was unexpected)
<zyga> wililupy: I think that for now you must use passthrough for that
<sergiusens> wililupy: use passthrough for that
<wililupy> so instead of bind: $SNAP/usr use passthrough: $SNAP/usr?
<zyga> wililupy: put all of the layout section under passthrough:
<zyga> intent it one level deeper
<wililupy> Ok. I'll try that. Thanks zyga and sergiusens
<kyrofa> sergiusens, alright, I'll propose and create a snap of it. See if we can break it
<mvo> 5147 also needs a careful review
<zyga> mvo: question about 8.
<zyga> do you remove both files and write one new one
<zyga> mvo: or do you remove one at random (whatever kernel chooses)
<zyga> mvo: and if the answer is the latter, how do you know you removed the right file for uboot?
<zyga> mvo: ah, I see the diff now
<zyga> this is interesting
<zyga> and linux picks up the non-corrupt one
<zyga> mvo: the grep is incorrect
<zyga> mvo: it will trigger when boot.env.GARBAGE is there
<zyga> or uboot.env.save
<zyga> or whatever
<wililupy> so I tried to install my snap and it says error: cannot install snap file: cannot use experimental 'layouts' feature, set option 'experimental.layouts' to true and try again so I use snap set experimental.layouts=true and get the following: error: the required argument `<conf value> (at least 1 argument)` was not provided.
<wililupy> Is there any documentation on this?
<zyga> wililupy: yes, please see
<zyga> https://forum.snapcraft.io/t/layouts-re-mapping-snap-directories/1471/63?u=zyga
<zyga> in short: snap set core experimental.layouts=true
<zyga> let me know of any issues you find
<zyga> I know of three issues that have pending fixes but are not in edge yet
<zyga> (though two will soon be)
<wililupy> zyga: thank you!
<zyga> better yet, please add your observations to that thread
<niemeyer> pedronis: The "seed" name is the path towards options related to seeding.. much like we have "proxy", for instance
<niemeyer> (not proxyign)
<niemeyer> pedronis: We also have /var/lib/snapd/seed, for similar reasons
<niemeyer> pedronis: The goal was having something that we might use when we need more seed-related options
<zyga> niemeyer: have you seen https://github.com/snapcore/snapd/pull/5141/checks ?
<mup> PR #5141: tests: shellchecks, part 1 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5141>
<zyga> (the PR number is not relevant)
<niemeyer> zyga: Ohhh, nice!
<zyga> it seems we can now pay for travis and get more slots
<zyga> and it feels like we want to have snapcraft there :)
 * cachio_ afk
<pedronis> niemeyer: I understand but /var/lib/snapd/seed is a "seed",  and a proxy proxies,  but a seed doesn't seed and cannot be done
<niemeyer> Hmmm.. my messages didn't go through
<niemeyer> Trying again..
<niemeyer> pedronis: The "seed" directory has plenty of content inside it too, so we could organize things there
<niemeyer> pedronis: I was driving for something similar here
<niemeyer> refresh, proxy, seed, ... would be top documents inside the system configuration
<niemeyer> pedronis: The "seed" directory has plenty of content inside it too, so we could organize things there
<niemeyer> pedronis: I was driving for something similar here
<niemeyer> refresh, proxy, seed, ... would be top documents inside the system configuration
<niemeyer> Heh, thanks IRC
<niemeyer> pedronis: "done" is less important, though.. we could use something else there maybe?
<zyga> pstolowski|afk: can you please merge master into your PRs after 4358 got merged
<pedronis> niemeyer: the problem is the relationship of seed noun and seed verb,  you seed a seed,   seed is the object is seed the verb,  while proxy can be the subject of proxy the verb, and refresh is action of refresh the verb
<niemeyer> pedronis: Sure, but that doesn't sound like an issue.. we have proxy and refresh as top documents, and seed would be no different
<niemeyer> It's clearly not an issue for the directory under snapd/
<zyga> jdstrand: not sure if you registered this, it has two +1s and I'm inclined to merge it https://github.com/snapcore/snapd/pull/5126
<mup> PR #5126: cmd/snap-update-ns: add support for ignoring mounts with missing source/target <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5126>
<pedronis> niemeyer: because that directoriy is a "seed"
<niemeyer> pedronis: Yep.. the configuration too
<niemeyer> pedronis: seed/*, seed.*
<jdstrand> zyga: I did not see it. looking
<pedronis> niemeyer: you would need to spell "seed.processed" not "seed.done" though
<niemeyer> pedronis: That sounds fine to me.. any other good alternatives, just for brainstorm purposes?
 * niemeyer synonyms
<zyga> seed.achieved?
<pedronis> seed.installed
<zyga> seed.completed
<zyga> seed.up-to-date
<pedronis> seed.seeded (but that's too repetitive)
<zyga> (in case seed changes)
<zyga> seed.ed (too geeky)
<pedronis> zyga: the linguistic problem of those is that seed is not an action, is the object of an action
<zyga> not sure, we call it "seeding" too
<zyga> English is too flexible it seems
<pedronis> zyga: the action indeed is seeding
<niemeyer> primed
<zyga> https://www.macmillandictionary.com/dictionary/british/seed_2
<zyga> "to put seeds in the ground so that they can grow"
<pedronis> zyga: yes,   but indeed seed  is already a name, so you cannot take the verb and nominalize it
<pedronis> the seed is primed,  the seed is installed, the seed is processed  sounds all okish
<jdstrand> zyga: approved
<niemeyer> loaded
<zyga> jdstrand: thank you!
<pedronis> niemeyer: loaded also works
<zyga> seed.planted? :D
<pedronis> the seed is achieved  or the seed  is completed sounds stranger
<mup> PR snapd#5126 closed: cmd/snap-update-ns: add support for ignoring mounts with missing source/target <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5126>
<zyga> seed.sprouted
<niemeyer> planted is not bad either
<niemeyer> Follows the analogy
<zyga> remember that small version of ubuntu on some dell machines?
<zyga> what was t hat name
<zyga> light?
<niemeyer> placed, planted
<pedronis> anyway atm  our terminology follows both  seed as of a plant and seed as of a crystal
<niemeyer> pedronis: primed works well for the crystal
<niemeyer> priming also has the connotation of making it ready which fits well in this case
<zyga> I'm unfamiliar with that term, is is the act of growing a crystal from a single attachment point?
<pedronis> zyga: seed for crystal?
<pedronis> yes
<zyga> yes
<niemeyer> pedronis: Pick one.. :)  primed, planted, loaded
<pedronis> I'm ok with either loaded or primed
<zyga> I'd go for planted as it is most simple for English non-natives
<pedronis> planted is doubling down on the metaphor a bit too much for my taste
<pedronis> also a planted seed is not fully grown yet
<pedronis> zyga: it's a bit misleading metaphor wise tough
<zyga> sprouted?
<zyga> is this about the systemd service name? :D
 * kyrofa breaks out the chemistry book to understand snapd's code
<pedronis> no, the flag
<niemeyer> seed.primed sounds nice
<zyga> what does it mean to prime a seed?
<niemeyer> Let's go with that then..
<zyga> to start growing it?
<niemeyer> zyga: Installs the snaps in the system and configure the whole system appropriately.. ;)
<pedronis> nothing in particular
<zyga> and does it relate to prime/ directory in snapcraft?
<pedronis> but that's not too bad, as I said our metaphor is already ambiguous and breaks down if you look too close
<niemeyer> zyga: Right, the motivation for the word is the same there
<niemeyer> zyga: "snapcraft prime" makes the snap ready for packing
<niemeyer> seed.primed means the seed was processed
<zyga> as long as it is documented :)
<zyga> I think it will raise eyebrows as it doesn't sound natural but if it is documented and consistent then +1
<niemeyer> This is also something pretty much nobody will look into, other than system hackers, so it's good enough I think
<niemeyer> zyga: seeds are very natural :)
<zyga> niemeyer: I mean the prime part
<zyga> prior to this moment I didn't consider that a word I'd associated with seeding (prime)
<niemeyer> zyga:      3. To prepare; to make ready; to instruct beforehand; to
<niemeyer>         post; to coach; as, to prime a witness; the boys are
<niemeyer>         primed for mischief. [Colloq.] --Thackeray.
<niemeyer>         [1913 Webster]
<zyga> as I said, it's just my familiarity with the word
<niemeyer> ack
<mvo> once there is agreement I guess we also need to rename the systemd unit(?)
<pedronis> niemeyer: mmh,  to be fair   prime works best  with snapcraft because  after prime there is pack
<pedronis> niemeyer: prime seems to have more the sens of make ready  for something else,  but for seed is a bit open/unclear wht the something else after is
<niemeyer> pedronis: seed.loaded is fine too
<pedronis> IÂ think it would be less unclear
<niemeyer> Cool, let's go with that then
<niemeyer> mvo: ^
<zyga> As a non-native speaker I only know the word "prime" from movies and games where it usually only refers to primed explosive
<niemeyer> :P
<niemeyer> mvo: Heya :)
<mvo> niemeyer: sorry, it irc client crashed
<niemeyer> Isn't that like 10pm for you guys?
<pedronis> zyga: yea,  it means prepare/make ready for detonation
<mvo> niemeyer: it is :(
<pedronis> in that context
<mvo> niemeyer: seed.loaded it is then?
<niemeyer> mvo: Yeah
<mvo> niemeyer: also - snapd.seed-loaded.service for the unit?
<bashfulrobot> Quick question all. I am not sure why I can;t find it in the docs. Is it possibel to remove all revisions from a channel?
<bashfulrobot> Quick question all. I am not sure why I can't find it in the docs. Is it possible to remove all revisions from a channel?
<niemeyer> mvo: snapd.seeded still sounds nicer I think
<bashfulrobot> darn - edits duplicate.
<mvo> niemeyer: so snapd.seeded and not snapd.seed-done ? happy with that
<zyga> bashfulrobot: you can close a channel, yes
<pedronis> bashfulrobot: snapcraft help close
<zyga> niemeyer: curious observation, unrelated to seeding
<niemeyer> mvo: Yeah, for the unit we don't have the same benefits of nesting as we do in the documentation
<zyga> niemeyer: I'm just installing windows 10 on an old netbook
<niemeyer> erm.. in the configuration I mean
<bashfulrobot> pedronis: ah ok - didn;t realise closing the channel was the same thing
<zyga> the latest version that's been released last week
<zyga> it asks for every wifi connection if this is a metered connection
<zyga> (offers to make it so)
<mvo> niemeyer: great, I updated the PR comment - once the rest is reviewed I will push the fixes, I will see what i can do about the upload of .7, its getting late here, maybe tomorrow morning
<bashfulrobot> thank you both zyga and pedronis
<niemeyer> mvo: Yeah, definitely.. some rest is due
<niemeyer> Oh, wait, and tomorrow is a holiday isn't it? /o\
<pedronis> mvo: systemd.special unit are a bit of a zoo,  most  are NAME.target/service with a few ADJECTIVE.target/service, but  IÂ don't see anything like foo-done there
<mvo> fwiw, the image with the corrupted uboot.env rerfreshed itself out of misery after I (manually) run the core-fixup.sh and the double uboot.env was gone. so one revert but on the next auto-refresh it went to the right revision
<mvo> pedronis: yeah, it was just a strawman, snapd.seeded.service is the current agreement with niemeyer which sounds fine to me
<pedronis> and sorry for being annoying about names but given this is part of the packaging and an interface we will be stuck with them for a while
<niemeyer> pedronis: Thanks for worrying, actually!
<zyga> mvo: https://twitter.com/oheather1337/status/993993156793221120
<niemeyer> pedronis: The options we discussed are much better than the quick name I suggested
<zyga> names are hard, we should go back to magic numbers
<zyga> this can be feature 42
<zyga> (voice from the side) but I like the number 64 better
<mup> PR snapd#5107 closed: cmd/snap-update-ns,tests: mimic the mode and ownership of directories <Squash-merge> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5107>
<mup> PR snapd#5141 closed: tests: shellchecks, part 1 <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5141>
<mup> PR snapd#5144 closed: tests: update bionic release image on gce <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5144>
<mup> PR snapd#5082 closed: cmd/snap-update-ns: use Secure.BindMount to bind mount files <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5082>
<zyga> jdstrand: #5116 has 2 +1s and I'm inclined to merge when green
<mup> PR #5116: interfaces: move host font update-ns AppArmor rules to desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5116>
<zyga> it is a simple refactor of how we share fonts
<jdstrand> zyga: approved
<zyga> thank you!
<mup> PR snapd#4790 closed: jsonutil/safejson: introducing safejson.String & safejson.Paragraph <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4790>
<zyga> jdstrand: having read the wiki page do you have any suggestions on the new debug command?
<zyga> jdstrand: I renamed it to "sandbox-features" and added a way to use it for scripting (return true/false if a set of features is available)
<zyga> otherwise I feel it is ready
<jdstrand> zyga: not otoh. I like the name change to sandbox-features
<zyga> thanks, I was wondering if I should add one for apparmor that's not from the kernel but I think for now it's fine
<zyga> it will help me with experiments
<jdstrand> we can always add stuff
<mvo> zyga: I slightly tweaked the test for 5147
<zyga> Just now?
<zyga> I just approved it
<mvo> zyga: like 2min ago, please have another look, very much like before but tests a bit more
<zyga> ok
<mvo> zyga: not the actual recover unfortunately, I need to think how to do that, we could try to build a broken image somehow but not tonight
<zyga> the test looks nice
<zyga> note, there's a shorter way to test the size of a file, if it is zero
<mvo> zyga: hm, test -s was what I had in mind but that is >0 iirc
<zyga> ah, indeed, I though there's a "exits but empty" test as well
<zyga> +1 :)
<mvo> thanks zyga !
<mvo> pedronis, niemeyer thanks for your input  on 5124!
<zyga> jdstrand: I'll handle the rest of your feedback tomorrow, I need to sleep now
<zyga> good night everyone
<jdstrand> zyga: good night :)
<bashfulrobot> Forthose that pop up in the AM... How long does the channel stable/ubuntu-18.10  Need to exist before closing to seed snaps on an ISO? Or do they need to exist for all ISO builds? And they exist until you are no longer building that ISO version? I seem to remember reading that it just had to be opened once with a revision, then could be closed immediately. I had set it up a while ago, and I am updating my personal docs... Plus since there
<bashfulrobot> is no meantion of these details, I would likely also add to https://wiki.ubuntu.com/UbuntuSeededSnaps
<bashfulrobot> TA
<mup> PR snapcraft#2128 opened: project_loader: stop setting LD_LIBRARY_PATH <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2128>
<mwhudson> is there any way to tell snapd about a proxy without restarting it?
<mwhudson> oh _looks_ like it can be set with core config
<mup> PR snapcraft#2116 closed: storeapi: handle 5xx error codes for all store endpoints <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2116>
<mup> PR snapcraft#2122 closed: many: introduce variables for part src and build <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2122>
#snappy 2018-05-10
<mborzecki> morning
<mup> PR snapd#5116 closed: interfaces: move host font update-ns AppArmor rules to desktop interface <Created by jhenstridge> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5116>
<zyga> Thanks!
<mborzecki> zyga: hey, pushed more test cases  to 4504 https://github.com/snapcore/snapd/pull/4504#discussion_r187152683
<mup> PR #4504: snap, wrappers: systemd WatchdogSec support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4504>
<mborzecki> zyga: i think you missed the parenthesis in the if condition
<zyga> Ack
<zyga> I will check shortly
<mborzecki> store hiccups continue today?
<zyga> please tell me that isn't so :)
<pstolowski> morning
<zyga> czeÅÄ
<zyga> jak tam? :)
<zyga> I need to plan an upgrade from artful
<zyga> I should probably do a clean bionic install from the final iso to see how that is like
<zyga> and then move my data over
<zyga> jamesh: hey, I merged master into #5115
<mup> PR #5115: interfaces: add xdg-document-portal support to desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5115>
<zyga> is it the final state of that PR, there are some pending comments
<zyga> also I recall reading your report on ubuntu-devel, what's the state of the portal work, is it the last branch you expect in this area for now, is there anything buggy or missing from your pop?
<zyga> pov
<jamesh> zyga: I was just updating it now, and running some of the spread tests locally (which failed due to a 503 error from the store)
<zyga> ack, feel free to force push if it makes your life easier, just merge master to get the diff updated please :)
<jamesh> hmm.  there's a new "checks" tab on pull requests
<jamesh> zyga: fwiw, I've been able to run the full file open/file save workflows using these snapd changes
<mborzecki> and it's somewhat confusing, there's checks that are run on each PR listed just below the review statuses and a separate checks tab (github apps marketplace?)
<zyga> jamesh: sweet! lots of lots of people will love that
<zyga> jamesh: yes, it's a new GitHub feature apparently
<jamesh> checks sound like it could be useful for automated syntax checking and the like
<jamesh> or a compile test.
<mborzecki> afk for a bit
<jamesh> The "status" feature is probably still what you want for test suites though
<zyga> yes, but we may opt into the new thing
<zyga> it seems travis now has a unified model where we could pay to get more test slots for FOSS projectsa
<mborzecki> re
<mborzecki> heh error: received an unexpected http response code (503) when trying to download https://api.snapcraft.io/api/v1/snaps/download/b8X2psL1ryVrPt5WEmpYiqfr5emixTd7_1797.snap
<mborzecki> zyga: don't want to upset you.. but ^^
<zyga> sigh :)
<zyga> well
<zyga> weather is weather
<zyga> and the store is the store
<zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/5142 again please
<mup> PR #5142: many: add "snap debug sandbox-features" and needed bits <Squash-merge> <Created by zyga> <https://github.com/snapcore/snapd/pull/5142>
<zyga> I updated it and documented the behaviour on the forum
<mborzecki> zyga: already reviewed it in the morning https://github.com/snapcore/snapd/pull/5142#pullrequestreview-118985554
<mup> PR #5142: many: add "snap debug sandbox-features" and needed bits <Squash-merge> <Created by zyga> <https://github.com/snapcore/snapd/pull/5142>
<zyga> oh, indeed, my tab was out of date
<zyga> replied :)
<kjackal> hello
<kjackal> is there a way to fill the snap version at build time?
<zyga> yes
<zyga> version-script
<zyga> AFAIR, google that there are examples around
<kjackal> version-script the keyword I was looking for, thanks zyga
<zyga> ogra_: https://github.com/snapcore/pi3-gadget/pull/14/files
<mup> PR pi3-gadget#14: Update SPI slot definition <Created by tokurz> <https://github.com/snapcore/pi3-gadget/pull/14>
<zyga> ogra_: can you please have a look at this
<Chipaca> moin moin
<zyga> hey hey
<mcphail> kjackal: if you're using git you can also pass 'git' as the version: field but it is slightly broken
<kjackal> thanks for the suggestion mcphail, I am packaging kubernetes so I would like the version in the snap to reflect the version of kubernetes binaries. I will take a look at git
<mcphail> kjackal: i hit this issue with underscores in the git tags, though: https://bugs.launchpad.net/snapcraft/+bug/1769519
<mup> Bug #1769519: Setting the snapcraft.yaml version field to 'git' produces undocumented and broken magic <Snapcraft:New> <https://launchpad.net/bugs/1769519>
<mborzecki> zyga: mvo is off today?
<zyga> I think so
 * zyga hears a lot of fire sirens
<zyga> hmm
<zyga> a *lot*
<mborzecki> zyga: too early for warsaw uprising anniversary
<zyga> feels like something major nearby
<Chipaca> pedronis: zyga: is there anything useful we can do to not use  a lot of cpu while not making progress when there's something wrong with the seed?
<zyga> can you give me an example
<Chipaca> maybe #1767896
<mup> Bug #1767896: Live 18.04 with persistence snapd high CPU usage <OEM Priority Project:Confirmed for swem> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1767896>
<Chipaca> grah! why does 18.04 not have keyboard shortcuts for menu items >:-(
 * Chipaca is glad he hasn't upgraded every time he runs it in a vm
<zyga> Chipaca: because gnome decided they are not desired or something?
<Chipaca> ogra_: do you know how the live cd dance happens? asking because i want to tweak /etc/environment before snapd gets a chance to run
<zyga> hmmmm
<zyga> Chipaca: should we refresh/seed on live CD?
<Chipaca> zyga: yep
<Chipaca> zyga: some work in to making it work, evne
<Chipaca> even
<zyga> pedronis said that was not expected to work
<Chipaca> but the daily livecd broke
 * zyga is getting confused
<zyga> still
<Chipaca> ?
<zyga> 2018-05-09T06:45:35-04:00 ERROR rename /var/lib/snapd/snaps/gtk-common-themes_3.snap.partial /var/lib/snapd/snaps/gtk-common-themes_3.snap: no such file or directory
<zyga> this is the thing to debug
<Chipaca> it totally is expected to work
<Chipaca> zyga: no
<zyga> I asked pedronis yesterday and he said no
<Chipaca> i mean
<Chipaca> zyga: the snap not being there is the cause of this bug, yes
<Chipaca> zyga: snapd trying again and again and again is less than smart
<Chipaca> and that's what burns up cpu
<zyga> yeah, no disagreement there
<zyga> it should slow down exponentially
<Chipaca> OTOH, if you boot the live cd _with network_, by the ~2nd try it just works
<Chipaca> because the download succeeds
<Chipaca> somehow? i think
<zyga> oh I saw that
<zyga> I have a live USB (not persistent) of bionic
<zyga> and I installed a snap
<zyga> and it failed
<zyga> then again
<zyga> and it worked
<zyga> no idea
<pedronis> Chipaca: zyga: I'm not here, but in budapest live cd people said they had space problems with refreshes, asked how to turn them off, explained about hold, if they didn't do it, not sure whay
<zyga> ah, I see
<zyga> thanks for the clarification
<Chipaca> pedronis: I think they have done it, at least i understood they have and i see something like it in this daily
<Chipaca> pedronis: now go away
<mborzecki> Chipaca: https://github.com/snapcore/snapd/pull/5091#issuecomment-385631992 you mean to show the log only then, i.e. one week in since the last refresh? right now there's a message logged each time refresh is held by being on a metered connection
<mup> PR #5091: many: hold refresh when on metered connections <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5091>
<Chipaca> mborzecki: I meant âin a week's time we're going to update *no matter what* so get to some cafe or something you nitwitâ
<mborzecki> Chipaca: ah ok
<Chipaca> mborzecki: also the // TODO use warnings for this
<mborzecki> Chipaca: pushed some updates to 5091, please rereview
<Chipaca> mborzecki: will make it easier to remember / find them :-)
<Chipaca> mborzecki: looking
<mborzecki> Chipaca: hah totally forgot about timeutil.Human ;)
<Chipaca> mborzecki: :=D
<Chipaca> uh, that was meant to be a smile
<Chipaca> not â¦ anything that isn't a smile
<mborzecki> hm one thing though, i can't drop the time in timeutil.Human right?
<Chipaca> not with that attitude
<pstolowski> for that you need timeutil.Puritan ;)
<Chipaca> mborzecki: you're right
<Chipaca> mborzecki: maybe leave it for now and then add a flag to Human (or find a name for the new thing)
<mborzecki> HumanDays
<zyga> we need Klingon package for i18n
<zyga> ;-)
 * Chipaca half-smiled half-groaned
 * Chipaca ~> moar coffee
 * Chipaca ~> really moar coffee
<mborzecki> the review board does not auto update?
<zyga> mborzecki: no, or if so it does so very infrequently
<Chipaca> mborzecki: gustavo mentioned it was stuck
 * Chipaca might have his snark levels dialed up too much today
<Chipaca> a user said something about a bug being a issue *we're* having, and I almost replied "oh, we aren't having it; you are"
<zyga> heh, someone is in a mood today :)
<zyga> but that could be me, I have a food poisoning since last night
<zyga> some cream was added to a sauce I didn't know about
<Chipaca> zyga: have you upset your wfie again
<zyga> sucks to be me today
<Chipaca> :-)
<zyga> Chipaca: my mother in law
<Chipaca> zyga: I flagged you about something in the forum btw, if you want to pick that up
<mborzecki> the weather outside is so nice today
<thresh> meh, no fonts in Qt apps again
<thresh> zyga, you've asked fro SNAP_CONFINE_DEBUG=1 snap run ... when this happens, so here goes: https://gist.github.com/thresheek/05e0343b19cb1e16b745ebf6162d6599
<thresh> also, good morning
<thresh> and again, it's fine after a reboot
<mborzecki> thresh:  `/usr/lib/snapd/snap-discard-ns <snap>` should be enough
<thresh> mborzecki, ok, I'll try next time this happens.  What could be the cause?
<mborzecki> thresh: maybe it's something with how the fonts are made available to snaps
<Chipaca> thresh: do you have an nvidia prime thing?
<Chipaca> (no, it's not a subscription service from nvidia to get free shipping)
<Chipaca> (and no it's not condoms either)
<thresh> Chipaca, yes I do
<thresh> bumblbee or whatever
<Chipaca> thresh: bumblebee was the old thing that supported per-window, right?
<Chipaca> anyway, that confuses snapd
<thresh> possibly
<Chipaca> every time i switch from one to the other i need to snap-discard-ns
<Chipaca> not sure if the fix is to tell snapd about this, or to tell whatever it is that does the switching about snapd :-)
<niemeyer> Moin
<Chipaca> who's the publisher of the gtk-common-themes snap?
<Chipaca> i mean, who are the devs
<pstolowski> zyga: is there any concern still about #5075 ?
<mup> PR #5075: snap/env: fix env duplication logic <Simple> <Created by didrocks> <https://github.com/snapcore/snapd/pull/5075>
<pstolowski> hello niemeyer!
<Chipaca> popey: do you know who pushes gtk-common-themes?
<niemeyer> pstolowski: Yo o/
<popey> Chipaca: desktop team own that. kenvandine probably
<Chipaca> kenvandine: O HI
<Chipaca> 6am for him, probably too early
<Chipaca> popey: thanks
<greyback> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1770364 is the issue I was struggling with yesterday
<mup> Bug #1770364: Using 2 remote parts, file not being copied from stage to prime <Snapcraft:New> <https://launchpad.net/bugs/1770364>
<mup> PR snapd#5124 closed: many: add wait command and seeded target <Critical> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5124>
<niemeyer> cprov: ping for when you're around
<cprov> niemeyer: I am in a dentist appt. and will be back in 30m. Urgent ?
<ogra_> Chipaca, to change livecd defaults you wantz ro change casper and re-build the image
<ogra_> *want to
<Chipaca> ogra_: I want many things, but that is not one of them
<Chipaca> ogra_: :-)
<ogra_> Chipaca, well, thats the only sane way to change /etc/environment that i know
<Chipaca> ogra_: then i guess i won't
<ogra_> casper creates all defaults in the livefs overlay
<Chipaca> ogra_: it was to debug a bug that i've now marked as won't fix, so Â¯\_(ã)_/Â¯
<ogra_> (alternative you could hack it in on the fly ... by adding "break=bottom" to the kernel cmdline, injecting it into the "nearly booted" system from the initrd shell and then move on with the boot by exiting the shell
<ogra_> )
<ogra_> ah, k
 * zyga is unsuited for work today :/
<om26er> is there a way to set environment variable for an installed snap, maybe using snapctl ?
 * zyga files a sick day, sorry folks, I cannot help it today
<Chipaca> om26er: no
<ogra_> for testing you can copy the wrapper script to ~/ ... edit it and bind-mount it over the one in the snap ...
<ogra_> but thats indeed no permanent solution or in any way sane :)
<cprov> niemeyer: ping, I am back home
<Chipaca> om26er: what are you needing to do?
<om26er> Chipaca: my snap requires an environment variable exported for a specific feature to work, though I opted for a system-wide export and that did the trick.
<Chipaca> om26er: it sounds like your snap should be using a config hook :-)
<om26er> So not blocked on anything, just wanted to know if that was possible
<om26er> I'll look into that
<zyga> om26er: is is a fixed flag?
<zyga> ogra_: like FOO_ENABLE=1
<kenvandine> Chipaca, that's my team, jamesh most specifically
<om26er> zyga: yeah
<zyga> er om26er ^
<Chipaca> kenvandine: O HI
<Chipaca> kenvandine: :-)
<zyga> om26er: can you juse add that to environment: in snapcraft.yaml?
<kenvandine> Chipaca, but didrocks does the regular pushes
<Chipaca> kenvandine: #1767896 is why i was wondering
<mup> Bug #1767896: Live 18.04 with broken seed causes snapd high CPU usage <OEM Priority Project:Confirmed for swem> <snapd (Ubuntu):Won't Fix> <https://launchpad.net/bugs/1767896>
<om26er> zyga: don't want to make it permanent. On some systems exporting that variable is not needed, on other it is.
<ogra_> zyga, or CRAZY_ENABLE=1, yeah :)
<zyga> is it harmful on the first group?
<Chipaca> kenvandine: daily live cd broken because one of the snaps now depends on something that isn't seeded, and can't be seeded because it's not in the channel
<zyga> if it is a configuration then yes, use configure hook
<kenvandine> Chipaca, ugh
<om26er> zyga: its untested, so can't really say. Would probably need a wide testing
<zyga> if it can be globally enabled then just do so
<kenvandine> Chipaca, i'll open and close the branch
<om26er> So it basically tells Android Studio to use system-wide libstd instead of the one that's shipped with its source.
<Chipaca> om26er: you could always have a wrapper check for e.g. [ -e $SNAP_USER_DATA/.do_the_crazy_thing ]
<Chipaca> kenvandine: will you update the bug when you do?
<kenvandine> Chipaca, done and done
<Chipaca> kenvandine: awe, and some
<kenvandine> :)
<mup> PR snapd#5117 closed: interfaces/apparmor: enable apparmor, even if partial <Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5117>
<mborzecki> zyga: there are conflicts on #5090
<mup> PR #5090: cmd/snap-update-ns: poke holes when creating source paths for layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/5090>
<zyga> oh
<zyga> thanks
<mup> PR snapd#5145 closed: boot: clear "snap_mode" when needed <Critical> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5145>
<greyback> kenvandine: hey, got a sec to look at https://github.com/ubuntu/snapcraft-desktop-helpers/pull/115 ?
<mup> PR ubuntu/snapcraft-desktop-helpers#115: Fix FONTCONFIG_PATH to point to where we generate fonts.conf <Created by gerboland> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/115>
<Son_Goku> niemeyer: https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org/message/XWJPNR2BIT6ZTA5M7OKSW7U6GY5EKQWH/
<kenvandine> greyback, saw that, it's in my queue to look at today
<greyback> kenvandine: ack, thanks!
<smoser> o/
<om26er> Wimpress: Hey! Who owns the name 'axel' on the snap store ? Can we reclaim that ?
 * Wimpress goes looking...
<om26er> I have proposed packaging upstream but they seem to be on a long vacation or something ;)
<om26er> https://github.com/axel-download-accelerator/axel/pull/156
<mup> PR axel-download-accelerator/axel#156: Add snap packaging <Created by om26er> <https://github.com/axel-download-accelerator/axel/pull/156>
<om26er> elopio: Hey!
<om26er> elopio: do you know what will it take to get the Keybase Desktop app as snap ? The packaging you proposed upstream looks to be the CLI client.
<Wimpress> om26er: That name is not taken as far as I can tell
<om26er> Wimpress: hmm, says "The name 'axel' is already taken."
<popey> sparkiegeek: ^ help. why does that snap not show in search but snapcraft thinks it's registered?
<niemeyer> zyga: ping
<zyga> Yes?
<zyga> niemeyer: pong
<niemeyer> zyga: Hey
<om26er> Wimpress: is it fine to create a new repository under snapcrafters ?
<om26er> apparently I can click the 'New' button
<Wimpress> om26er: Do you want to repo to be called `axel`?
<om26er> Wimpress: yes.
<Wimpress> I can create it and you can submit a PR :-)
<om26er> sure
<Wimpress> om26er: https://github.com/snapcrafters/axel
<zyga> Pharaoh_Atem: matthew miller supports fedora base snap :)
<popey> om26er: https://news.ycombinator.com/item?id=17038734 - thank you!
<om26er> \o/
<popey> :)
<popey> Thought you might like that :)
<om26er> popey: Definitely great to know and fyi android studio neared 10k installs :)
<popey> Nice!
<popey> One of them is me :)
<om26er> Its exciting how snaps are fixing real issues, making my life a breeze every day.
<popey> That's great to hear. Looking forward to the next developer tool you need to snap ;)
<om26er> I have my eyes on https://hub.github.com/
<kyrofa> Hey niemeyer are you planning on updating blender to 2.79b?
<niemeyer> kyrofa: Yeah, definitely, and also need to update 2.8
<mup> PR snapd#5148 opened: boot: clear "snap_mode" when needed (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5148>
<mup> PR snapd#5149 opened:  many: add wait command and seeded target <Created by mvo5> <https://github.com/snapcore/snapd/pull/5149>
<mup> PR snapd#5150 opened:  snapd.core-fixup.sh: add workaround for corrupted uboot.env <Created by mvo5> <https://github.com/snapcore/snapd/pull/5150>
<om26er> Wimpress: https://github.com/snapcrafters/axel/pull/1
<mup> PR snapcrafters/axel#1: Add initial packaging <Created by om26er> <https://github.com/snapcrafters/axel/pull/1>
<om26er> So I think you will need to register/own that name first to be actually able to publish that to the store.
<popey> om26er: i am trying, getting a store problem.
<popey> om26er: ok, axel is now registered to snapcrafters
<mup> PR snapd#5151 opened: tests: use journalctl cursors instead rotating logs <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5151>
<om26er> popey: lets merge that PR and enable builds for it :)
<popey> I can't enable builds yet. https://github.com/canonical-websites/build.snapcraft.io/issues/1091
<noise][> FYI https://forum.snapcraft.io/t/new-cdn-for-snap-downloads/5363 - new CDN online, 50% mix at the moment, please post on that forum thread is you see any download issues
<mup> PR snapcraft#2129 opened: Swap FROM in Dockerfiles from 'xenial' to 'bionic' <Created by felicianotech> <https://github.com/snapcore/snapcraft/pull/2129>
#snappy 2018-05-11
<mborzecki> morning
<Pwnna> is there a way to build an ubuntu core image without a snapcraft account
<zyga> good morning
 * zyga feels more or less normal now, let's hope it will stay that way :)
<mborzecki> zyga: hey
<cachio_> zyga, hey
<cachio_> mborzecki, you start early
<mborzecki> cachio_: yup, always like this, leaves more day to attend kids & other things
<mborzecki> cachio_: what time is at your place now? midnight?
<cachio_> mborzecki, 2 am
<cachio_> 2:22
<cachio_> I am almost done
<mborzecki> cachio_: wow ;) insomnia?
<cachio_> mborzecki, no, fixing the images
<mborzecki> cachio_: ayy
<cachio_> all the builds were failing with the 16.04-32 and fedora-27
<mborzecki> cachio_: was that a no space left thing?
<cachio_> mborzecki, no, Error: Failed to synchronize cache for repo 'updates'
<cachio_> installing, or updating with dnf
<mborzecki> maybe  high load on fedora mirrors, people updating their systems
<cachio_> mborzecki, yes, it could be, I regerenated the image many times with different changes and it didin't work
<mborzecki> didn't the same happen when 27 was released?
<mborzecki> iirc we switched fedora to manual then
<cachio_> mborzecki, yes, something similar, but as yesterday I updated this iamge I thought that perhaps something new was causing this
<cachio_> mborzecki, I'll create a PR to set fedora as manual until it is fixed
<mborzecki> ok
<mborzecki> cachio_: have you looked into preparing f28 image by any chance?
<cachio_> mborzecki, no, should I?
<cachio_> mborzecki, I mean, are we going to support it?
<mborzecki> cachio_: yeah, it'd be great
<cachio_> mborzecki, is it already released?
<cachio_> or it is comming soon?
<mborzecki> cachio_: it's released (that's probably why the high load on the mirrors)
<cachio_> mborzecki, ah, ok
<cachio_> mborzecki, I am runnin a script to create the google image
<cachio_> mborzecki, not sure if it is gonna work
<mborzecki> cachio_: no need to do it now, it's already late for you anyway
<cachio_> mborzecki, I jut changed few 7 for 8
<cachio_> mborzecki, not big deal :)
<mborzecki> cachio_: hah ;)
<cachio_> mborzecki, failed, google packages not ready for 28
<cachio_> mborzecki, I'll try in few days
<mborzecki> ok
<zyga> cachio_: what does it mean "google packages not ready for 28"?
<cachio_> zyga, things like this package google-compute-engine-init-2.1.2-0.1488484921.el7.x86_64 requires google-compute-engine, but none of the providers can be installed
<cachio_> nothing provides libjson-c.so.2()(64bit) needed by google-compute-engine-oslogin-1.3.0-1.el7.x86_64
<zyga> and we cannot use fedora 28 without that package?
<cachio_> zyga, not in google
<zyga> uh
<cachio_> it is required
<zyga> Son_Goku: hey, do you know if f28 support in google compute engine is something that fedora is doing or is that google themselves?
<Son_Goku> that's probably something the fedora server WG would know
<Son_Goku> but I would not be shocked if it's a bit of both
<Son_Goku> but libjson-c.so.2()(64bit) is missing, which means json-c was upgraded
<Son_Goku> cachio_, where do you get gce-oslogin?
<cachio_> Son_Goku, so far from here https://packages.cloud.google.com/yum/repos/google-cloud-compute-el7-x86_64
<Son_Goku> then f28 images are definitely all google
<cachio_> for fedora 26 and 27
<Son_Goku> because fedora would have required these packages to be available in fedora itself
<zyga> yeah, that's what I thought too
<mup> PR snapd#5152 opened: tests: move fedora 27 to manual <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5152>
<mborzecki> cachio_: could we do the same as for arch?
<Son_Goku> cachio_, it's definitely fixable though
<Son_Goku> it'd be trivial to make a compat package for it to work
<cachio_> mborzecki, for arch I download the image which already has that package
<cachio_> mborzecki, there is not any fedora image for gce afaik
<mborzecki> cachio_: i mean build the google services form source for the time being
<cachio_> mborzecki, well yes
<Son_Goku> I mean, the spec files for building the gce stuff is available
<Son_Goku> so we could just _build_ them to Fedora
<zyga> copr :)
<cachio_> Son_Goku, perfet
<Son_Goku> https://github.com/GoogleCloudPlatform/compute-image-packages/blob/master/google_compute_engine_oslogin/packaging/rpmbuild/SPECS/google-compute-engine-oslogin.spec
<Son_Goku> the packaging is actually slightly wrong :(
 * Son_Goku fixes
 * cachio_ EOD
<Son_Goku> cachio, zyga, I need sleep so I'll deal with it in the morning
<zyga> Son_Goku: ack, good night!
<zyga> thank you both
<mborzecki> https://www.reddit.com/r/linux/comments/8icx4w/gimp_20_flatpak_and_snap_side_by_side/
<mborzecki> still at 50 PRs
<kjackal> hello, is there a way to edit an apparmor profile and reload the profiles from a hook?
<kjackal> I am probably thinking it wrong..
<kjackal> I should be creating an interface or something, right?
<jamesh> mborzecki: we should be able to improve the file pickers once portals lands
<mborzecki> jamesh: looking forward to it ;)
<jamesh> that's assuming Gimp uses the FileChooserNative APIs
<jamesh> which is not guaranteed
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> afk for ~2h, need to go to the car shop, start the claims process
<Chipaca> *yawn*
<zyga> hey john
<zyga> I was thinking
<zyga> about that seeding issue
<zyga> it would be interesting if snapd could model being online or offline
<zyga> because then we could be smarter about many decisions
<zyga> e.g.: refreshing snap foo will make us offline temporarily
<zyga> or stopping it will make us offline
<zyga> or we are offline/online and a system package (not snap) is managing that
<Chipaca> zyga: i'm wary of adding dimensions to our state
<Chipaca> zyga: also, http://www.linusakesson.net/programming/pipelogic/index.php
<Chipaca> ogra_: you might enjoy it too ^ :-)
<zyga> woah
<jamesh> zyga: I think https://github.com/snapcore/snapd/pull/5115 should be complete now.  Everything is passing except the fedora 27 issue (which in theory is down to load caused by the fedora 28 release)
<mup> PR #5115: interfaces: add xdg-document-portal support to desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5115>
<zyga> ack
 * zyga looks
<jamesh> zyga: I've also put together some instructions on testing the current state of the code at https://forum.snapcraft.io/t/snapd-support-for-xdg-desktop-portal/161/9?u=jamesh
<jamesh> one thing that may be controversial is getting "snap run" to try and launch various D-Bus session services before transferring control to snap-confine
<jamesh> we can't very well rely on service activation for the mount point.
<zyga> jamesh: what normally starts the document portal?
<zyga> is it run by the session
<zyga> or is that run by snap/flatpak as needed
<jamesh> zyga: it doesn't auto-start with the session on Ubuntu.  I suspect flatpak just activates it via dbus.  Let me check
<zyga> thanks
<zyga> jamesh: if snap run would need to start the document portal, how would it know
<jamesh> zyga: yep.  It's relying on D-Bus service activation, doing a synchronous method call: https://github.com/flatpak/flatpak/blob/master/common/flatpak-run.c#L1682
<zyga> jamesh: the desktop interface in one of the plugs
<zyga> jamesh: even if so, we don't know if it is connected
<zyga> looking at that code the nice thing is that it doesn't seem to be specific to an app
<zyga> so we could even start it from snapd userd
<jamesh> zyga: is that any better?  Isn't userd a dbus activated service too, and not generally run until you use xdg-open?
<zyga> userd has an auto-start feature now
<zyga> though it still feels racy
<zyga> my point is that I don't know what would be the condition that would make 'snap run' start the portal
<mborzecki> re
<jamesh> I think at some point we will want a long running session service, and niemeyer seemed to think userd shouldn't do that
<zyga> and if we had that?
<zyga> I'm still trying to piece together how it is expected to work in the end
<jamesh> (i.e. he wanted userd to be able to restart at any point)
<jamesh> if "snap run" is going to ensure userd is running, then having userd try to activate xdg-document-portal should be fine
<zyga> how would that work in a headless system without sessions
<jamesh> if there is no session bus, then there's no portals
<jamesh> and we'd continue without it
<jamesh> The safe scenarios are (1) document-portal starts before confined app, and (2) document-portal is never started while confined app is running
<jamesh> unsafe is "document-portal started while confined app is running"
<jamesh> For flatpak, this last scenario is safe because the entire /run/user/$uid tree is private
<zyga> ck
<zyga> ack
<newbee> when i try to execute snapcraft prime or  snapcraft pull or snapcraft build , we are getting the error message in Linux mint 18.1 64 bit   "Native builds aren't supported on Linux Mint. You can however use 'snapcraft cleanbuild' with a container".
<zyga> newbee: that's right
<newbee> @zyga : also getting error for snapcraft cleanbuild "The container you are starting doesn't have any network attached to it."  what it means..
<zyga> newbee: it means the container doesn't have a network interface (probably)
<zyga> perhaps kalikiana can help you, I'm not an expert on snapcraft
<mborzecki> something wrong with local lxc/lxd installation?
<mborzecki> eg. on arch you have to tweak the configuration shipped with distro package
<mborzecki> otherwise the containers that are started have no network interfaces
<newbee> @mborzecki / @zyga :  please tell us, can i run snapcraft in linux mint.. also give a clue to configure the network interface to lxc
<zyga> newbee: I don't know how to setup lxc in linux mint
<zyga> you can run snapcraft (I suspect) but I don't know how to set it up for you
<ogra_> Chipaca, mosfets !!! now it just needs to play music !
<ogra_> (lovely article indeed)
<mup> PR snapd#5148 closed: boot: clear "snap_mode" when needed (2.32) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5148>
<mup> PR snapd#5150 closed:  snapd.core-fixup.sh: add workaround for corrupted uboot.env (2.32) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5150>
<thresh> hello there
<thresh> would anyone accept a bribe to get https://github.com/snapcore/snapcraft/pull/2119 merged?
<mup> PR snapcraft#2119: repo: automatically prune unneeded stage-packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2119>
<Chipaca> thresh: I hear kyrofa likes craft beer
<thresh> I doubt he has powers to do self-review and merges :-)
<Chipaca> thresh: sergiusens might be needing a new aikido outfit, a slimmer one\
<sergiusens> Chipaca, thresh: so on that one, mvo was going to review this week, but apparently some issues showed up and he got put on the hook for them
<sergiusens> these resolver ones can have tricky side effects not viewable at plain sight and his input is really welcomed on it
<thresh> we can ship one of these nice costumes: https://pbs.twimg.com/media/DVMNuAoX0AU7gKS.jpg:large
<Chipaca> thresh: mvo would rock hockey in one of those
<thresh> sergiusens, ah, good to know.  It kinda looked abandoned since no reviewers set etc, so I thought to nudge here. Thanks!
<Chipaca> thresh: (mvo spent most of his week hunting down a bug in the interplay of uboot and linux's FAT implementations
<Chipaca> )
<thresh> the horrors
<Chipaca> IKR
<mvo> sergiusens: yeah, this week was slightly bad, just go ahead with the PR it looks good and I can do a proper indepth PR next week when things are a bit more calm
<sergiusens> mvo: why are you here at all! :-)
<Chipaca> mvo: get out of here
<Chipaca> mvo: shoo!
<mvo> sergiusens: because this update is not released yet that we promised for tihs week
<mvo> Chipaca: yeah, I know :/
<sergiusens> oh, :-(
<Chipaca> mvo: what's missing?
<mvo> Chipaca: one test is still running, once that is in I will do .7 and run away
<mvo> Chipaca: i.e. 2.32.7, sru to bionic (that is what we promised) and push to beta for screenly to test
<sergiusens> thresh: btw, I am a happy user of the vlc snap, everyday user here :-)
<thresh> sweet :-)
<mup> PR snapd#5149 closed: many: add wait command and seeded target (2.32) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5149>
 * cachio afk
<zyga> mmm, good idea
<zyga> mvo: ppc failed on tests
<zyga> https://launchpadlibrarian.net/369787126/buildlog_ubuntu-xenial-powerpc.snapd_2.32.7_BUILDING.txt.gz
<zyga> FAIL: devicestate_test.go:478: TestFullDeviceRegistrationHappyClassicFallback.pN66_github_com_snapcore_snapd_overlord_devicestate_test.deviceMgrSuite
<mvo> zyga: hm, I think this is just flaky on gccgo
<zyga> ack
<zyga> is it an issue for the release?
<mvo> zyga: this one is not (if its transient) but https://github.com/snapcore/snapd/pull/5147/commits/f73fa6f48687aeae69a26c95951b72fcc9404e03 is
<mup> PR #5147: snapd.core-fixup.sh: add workaround for corrupted uboot.env <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5147>
<mvo> zyga: 5147 has a proper test now (yay) but it shows an issue with the fixup (meh) so I think I need .8 :/
<zyga> :-(
<zyga> well
<mvo> zyga: yeah
 * zyga hugs mvo
<mvo> zyga: could be worse, at least we have a real test and real fix this way :)
<mvo> zyga: a re-review of that pr would be great, tests are running locally (and in spread) right now
<zyga> looking
<mvo> zyga: fwiw, the binary file with the partition image is 200kb which I think is acceptable given the importance of the bug
<zyga> mvo: done
<mup> PR snapd#5153 opened:  snapd.core-fixup.sh: add workaround for corrupted uboot.env (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5153>
<mvo> zyga: \o/ thank you
<mborzecki> mvo: i was looking into writing something to generate that 'semi-corrupted' vfat in python
<niemeyer> Mornings
<niemeyer> pstolowski|lunch: Replied on #5120.. btw, the PR summary isn't following the usual pattern
<mup> PR #5120: interfaces: interface hooks for refresh <Critical> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5120>
<mvo> mborzecki: yeah, I think that would be good, in the meantime I took the original corrupted image, cleaned it, zeroed all unused blocks and this means its compressed small enough to put into the tree
<niemeyer> pstolowski|lunch: I've slightly adjusted it, but still needs further tweaking to reflect what's in the PR
<pstolowski> niemeyer: thanks, looking
<zyga> mvo: as for the partition image, yeah, no doubt it is useful
<pstolowski> niemeyer: updated the summary. re the methods with identicals args, do you want me to change to a single method?
<Chipaca> I need to go to the school. Will miss the standup today.... ttfn
<mborzecki> bumped arch package to 2.32.7
<zyga> mborzecki: .8 is coming :(
<zyga> mborzecki: I will update opensuse after lunch/standup
<niemeyer> I'm also going to be a bit late as I have a conflicting meeting today
<niemeyer> (in theory, low on attendance atm)
<AnaValencia> Hi
<zyga> AnaValencia: hey
<zyga> niemeyer: we all went (including mvo) so I think that's it for today
<zyga> niemeyer: apart from .8 release nothing major to report
<mvo> niemeyer, zyga: yeah, just waiting for tests on this one
<niemeyer> zyga, mvo: Cool, sorry for being late.. should have rescheduled it
 * zyga needs to run an errand for CE, 
 * ogra_ grins about the forum ... 
<ogra_> jdstrand, you need to implement an "open-giant-security-hole" interface that bind-mounts /usr/lib/flashplugin-installer into browser snaps ;)
<mup> PR snapd#5153 closed:  snapd.core-fixup.sh: add workaround for corrupted uboot.env (2.32) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5153>
<Lin-Buo-Ren> https://forum.snapcraft.io/t/feature-proposal-source-submodules-option/5372
<kjackal> ey jdstrand, you are spot on the kill signal recieve issue of docker containers. I couldn't find a way to provide my own apparmor profile for each container the dockerd spawns, however I could add a single line in the docker-default apparmor profile and reload the profiles. This does not feel right though. Do you think the only option we have is to build our own dockerd and ship it?
<kjackal> *hey
<mup> PR snapd#5147 closed: snapd.core-fixup.sh: add workaround for corrupted uboot.env <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5147>
<Lin-Buo-Ren> https://forum.snapcraft.io/t/bug-docs-should-specify-the-default-behavior-when-stage-key-is-absent/5384
<mup> PR snapcraft#2130 opened: tests: remove obsolete env var <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2130>
<mup> PR snapd#5154 opened: releases: merge 2.32.8 back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/5154>
<mup> PR snapcraft#2129 closed: Swap FROM in Dockerfiles from 'xenial' to 'bionic' <Created by felicianotech> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2129>
<pstolowski> another store error on travis.. cannot get nonce from store: store server returned status 418
<mup> PR snapcraft#2131 opened: No user site for snapcraft <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2131>
<mvo> cachio: could you please sru test 2.32.8 for bionic only? it contians an important customer fix
<mvo> cachio: and please ping apw on monday and ask for the release of .5 into -updates so that we can get .8 into proposed on all !bionic series :) thank you!
<kyrofa> zyga, snap run --shell doesn't seem to take stdin. Is there any way I can use it in a script?
<kyrofa> Wait I lied, shell script fail
<mvo> cachio: also 2.32.8 is in the beta channel now ready for validation
<zyga> re
 * zyga delivered edge gateway to a colleague, needs water and will be hacking soon
<kyrofa> zyga, ubiquity? Did you switch to something else?
<zyga> kyrofa: hmm? :)
<zyga> kyrofa: I meant that I returned a borrowed dell edge gatweay
<zyga> kyrofa: to a colleague that lives nearby
<kyrofa> Ahh
<kyrofa> Too much similar-sounding network hardware :P
<zyga> it's so hot today I could drink a river
 * ogra_ de-routes the rhine to warsaw to zyga's house
 * kyrofa is impressed with ogra_'s `route` foo
<ogra_> route add ... blah
<ogra_> :)
 * zyga breaks for some time
<mborzecki> currently have this for manipulating FAT entries: https://gist.github.com/bboozzoo/e68254507eef4673dd8c6f9b82f65d92
<mup> PR snapd#4588 closed: Snapshots! <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4588>
<pstolowski> niemeyer: would you like me to tweak these Reconnect/Autoconnect functions in #5120 or can I merge?
<mup> PR #5120: interfaces: interface hooks for refresh <Critical> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5120>
<zyga> Nice :-)
<niemeyer> pstolowski|afk: Feel free to merge either way as this is a trivial point and easy to fix afterwards, but you do have two functions there which have exactly the same parameters and do exactly the same thing, apparently for no reason..
<niemeyer> pstolowski|afk: No pressing need, but this is really a single function
<pstolowski|afk> niemeyer: yes I get your point. the reason though is that I couldn't come up with a good single name. but i'm ok to change this in a followup
<mup> PR snapd#5120 closed: interfaces: interface hooks for refresh <Critical> <Squash-merge> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5120>
<Son_Goku> zyga, cachio: https://copr.fedorainfracloud.org/coprs/ngompa/gce-oslogin/build/752832/
<Son_Goku> zyga, since I am waiting tor my flight boarding, I figured I'd just take care of this ;)
<Son_Goku> it covers F27, F28, and Rawhide (targeting F29)
<zyga> Thank you :-)
<Son_Goku> zyga, cachio: built successfully: https://copr.fedorainfracloud.org/coprs/ngompa/gce-oslogin/build/752841/
<mup> PR snapcraft#1769 closed: lxd: add an --image argument to cleanbuild <Created by mwhudson> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1769>
<mup> PR snapcraft#1969 closed: Add a "--profile" parameter to cleanbuild <Created by chrisglass> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1969>
<mup> PR snapcraft#2132 opened: errors: generic exception for common.run[_output] <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2132>
<mup> PR snapcraft#2131 closed: No user site for snapcraft <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2131>
<mup> Issue snapcraft#2133 opened: gradle plugin treats spaces as delimiter in gradle-options <Created by bsutton> <https://github.com/snapcore/snapcraft/issue/2133>
#snappy 2018-05-12
<mup> Issue snapcraft#2134 opened: gradle plugin doesn't generate a ware <Created by bsutton> <https://github.com/snapcore/snapcraft/issue/2134>
<mup> PR snapcraft#2130 closed: tests: remove obsolete env var <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2130>
<mup> PR snapcraft#2135 opened: Update gradle.py <Created by bsutton> <https://github.com/snapcore/snapcraft/pull/2135>
<mup> PR snapd#5152 closed: tests: move fedora 27 to manual <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5152>
<mup> Issue snapcraft#2136 opened: Crash qt gui aplication (build with core 18 on ubuntu 18.04(LXD)) <Created by EndrII> <https://github.com/snapcore/snapcraft/issue/2136>
<Mikaela> Hi, the Travis CI continuous integration guidd which link I lost links to empty demo repository
<mup> Bug #1619420 changed: snappy removal of dpkg-query breaks lsb_release --all <cloud-init:New> <Snappy:Fix Released by ogra> <livecd-rootfs (Ubuntu):Fix Released by ogra> <https://launchpad.net/bugs/1619420>
<mup> Bug #1662357 changed: Can't use lsb_release on Ubuntu Core 16 <lsb:Invalid> <Snappy:New> <Snappy Ubuntu Core:New> <lsb (Ubuntu):Invalid> <https://launchpad.net/bugs/1662357>
<kyrofa> Mikaela, https://github.com/elopio/hello-snap-username.git ? That's not really a demo, it's just an example in the tutorial-- you're supposed to replace it with your own :)
<Mikaela> kyrofa, "Your final code should contain a .circleci/ directory containing both a config.yml as well as a credentials.enc, similar to this demo repository." says https://tutorials.ubuntu.com/tutorial/continuous-snap-delivery-from-circle-ci?backURL=https://docs.snapcraft.io/build-snaps/ci-integration#5 immediately under "final code" and if it's not supposed to be a demo, I think there is a problem with the
<Mikaela> tutorial
<Mikaela> I don't actually have anything to package that I know of, but I was curious and thought that reading how it happens in theory won't be hurting me :)
<kyrofa> Mikaela, fair point. Although THAT repo actually exists ;)
<Mikaela> sorry, GitHub mobile has lied to me or it has some technical problem when I messaged :(
<vidal72[m]> https://forum.snapcraft.io/t/bogus-apps-in-store/4703/31
<vidal72[m]> djinn is out of the bottle
#snappy 2018-05-13
<eraserpencil> hi guys!
<eraserpencil> is there any pros/cons to switchy stock apps to snaps?
<eraserpencil> for example uninstalling the firefox browser that comes pre-installed and getting it in a snap
<mr_lou> Morning
<mup> Issue snapcraft#2137 opened: vlc language indonesian <Created by candrapersada> <https://github.com/snapcore/snapcraft/issue/2137>
<diddledan> anyone who's around, https://forum.snapcraft.io/t/proposal-add-dev-shm-namespace-to-all-snaps-by-default/5416
<diddledan> I'd particularly like jdstrand to look at that
<Pretheist> Okay, so if I'm absolutely ignorant of all things computer, and I want to learn the necessary foundational knowledge for how snapd and other things work, what is the fastest and easiest way to fully understand it?
#snappy 2019-05-06
<mborzecki> morning
<zyga> Good morning
<mborzecki> zyga: hey
<zyga> hey, how are you doing
<zyga> it's gotten pretty cold :/
<mborzecki> zyga: yeah, it could rain a bit though, so far it's been rather dry
<mborzecki> hmm somehow arch package of 2.39 is 4M smaller than 2.38 :/
<zyga> mborzecki: it was raining almost daily here
<zyga> mborzecki: perhaps something changed from a copy to a link?
<zyga> mborzecki: worth du-ing though
<mborzecki> zyga: s-u-n is half the size
<zyga> that is unusual!
<zyga> perhaps we stopped importing something big
<zyga> but half the size is very surprising
<mborzecki>  12M -rwxr-xr-x 1 maciek maciek  12M 05-06 07:27 sun-2.38
<mborzecki> 6.1M -rwxr-xr-x 1 maciek maciek 6.1M 05-06 07:26 sun-2.39
<mborzecki> hm
<mborzecki> wow, how the hell did image end up in s-u-n
<mborzecki> zyga: image as in this one https://godoc.org/image
<zyga> LOL
<zyga> golang linking magic
<zyga> how are you inspecting the binary?
<mborzecki> zyga: looking at readelf output, i'm not aware of any other go friendly way
<mborzecki> zyga: package is included in symbol names
<zyga> I spent all of previous-work-day in readelf/strace/ltrace
<zyga> we should add support for snap run --ltrace
<mborzecki> yeah, ltrace would be nice
<mborzecki> oh, and an up to date strace-static snap :P
<zyga> yeah
<zyga> maybe something to try to get to this week though I haven't set my priorities yet
<zyga> man, resuming a virtual machine from hdd is super painful
<zyga> (ram dumps)
<mborzecki> zyga: http://paste.ubuntu.com/p/xypbbFqtd7/ quite a bit of packages gone in s-u-n 2.39
<zyga> mborzecki: perhaps go linking changed?
<zyga> for real
<zyga> I was joking before but maybe it's not a joke
<mborzecki> zyga: same go version
<zyga> perhaps something did import the image package before but not anymore?
<zyga> dunno, it's a bit magic
<mborzecki> zyga: hmm snapd in 2.38 also includes image :P
<zyga> batteries and image processing included, that's the motto ;)
<mborzecki> zyga: asserts pulls in golang.org/x/crypto/openpgp/packet which in turn imports image
<zyga> what... the...
<zyga> lol
<zyga> so how did we end up dropping that from sun?
<mborzecki> zyga: we dropped asserts, which probably was a dep of some other package
<zyga> good find,
<zyga> if you can automate enough it would be nice to have a tool that dumps, roughly, the imported go packages of a given binary
<mborzecki> well, so probably nothing we can do about that import
<mborzecki> at least i can proceed with the update now that we know where the 4MB went
<zyga> mborzecki: indeed
<zyga> hello mvo
<mvo> hey zyga
<mvo> zyga: good morning!
<mborzecki> mvo: hey
<Eighth_Doctor> ugh
<Eighth_Doctor> I think I finally did it
<Eighth_Doctor> and yay, I can sign into snapcraft forum again
<mvo> hey mborzecki !
<mborzecki> mvo: did you know we can do image processing in snapd? :D
<mborzecki> need to run a quick errand, back in 30
<mvo> mborzecki: image processing?
<Eighth_Doctor> snapd 2.39 is currently held up due to https://pagure.io/fedora-infrastructure/issue/7762
<zyga> mvo: snapd was linking to the go imaging package
<zyga> mvo: because reasons
<zyga> mvo: mborzecki went investigating why snapd suddenly is 4MB smaller
<zyga> that's why
<pstolowski> mornings!
<mvo> zyga: woah, nice job mborzecki
<mvo> hey pstolowski
<zyga> mvo: on similar spirit, did you know that opengl on the linux desktop requires libtinfo for terminal control sequences?
<pedronis> mvo: morning
<mvo> hey pedronis
<mvo> zyga: I had no idea :)
<zyga> brb
<zyga> re
<mborzecki> re
<mborzecki> pstolowski: pedronis: hey
<pstolowski> o/
<pedronis> mborzecki: pstolowski: zyga: hi
<pedronis> mvo: I made a couple more comments on your remodel PRs
<mvo> pedronis: thanks, working on this now
<pedronis> mvo: also (still WIP) but this is were my own efforts or re-reg etc are heading:  https://github.com/pedronis/snappy/commit/bd6908d1c5a87f7ceb1c51bf9b4b4bedb3f7a0af#diff-57a9337573ecc46801d40ff4e140872cR32  probably worth a quick look to get a sense of things
<mvo> pedronis: ok
<mborzecki> Eighth_Doctor: that's somewhat unexpected
<mborzecki> Eighth_Doctor: but it's epel only?
<Eighth_Doctor> yep
<mborzecki> Eighth_Doctor: maybe some update didn't land for ppc64le just yet
<Eighth_Doctor> probably
<mborzecki> Eighth_Doctor: did you have any issues with snapd selinux transition in 2.39? (aside from the reboot to patch the mount units)
<Eighth_Doctor> ð¤·
<Eighth_Doctor> on the clean machines I have, no
<Eighth_Doctor> but that doesn't tell me anything
<Eighth_Doctor> mborzecki: https://fedoramagazine.org/use-udica-to-build-selinux-policy-for-containers/
<mborzecki> Eighth_Doctor: interesting, didn't we look at this a year ago or so?
<Eighth_Doctor> we looked at CIL, I think
<Eighth_Doctor> I don't remember if we looked at udica
<mborzecki> or maybe i was browsing wrabcak's projects :P
<pedronis> mvo: tried to answer in 6775
<pedronis> let me know if it's still unclear
<Eighth_Doctor> mborzecki: heh
<pedronis> mvo: I'm mostly trying us to have to refactor the refactor later, but don't want to make a time sink for you either
<pedronis> s/to have/to not have/
<Eighth_Doctor> wow, I really haven't gotten any sleep at all
<Eighth_Doctor> this is terrible
<mborzecki> zyga: void is 111 instead of 000, i guess i need to update it in the fs otherwise things will blow up?
<Eighth_Doctor> the package should update this...
<Eighth_Doctor> mborzecki: the selinux-policy issue should be fixed in the next half hour or so
<Eighth_Doctor> so I'll try building snapd then and go from there
<pedronis> mborzecki: pstolowski: I did some first pass review on some of your PRs
<pedronis> mborzecki: pstolowski: also I have a long chain of refactory PRs (related to remodeling and rereg) that need review
<pstolowski> pedronis: yep, thank you, i'm working on the ensure timings stuff
<mborzecki> pedronis: thx
<mborzecki> pedronis: 6821 is the first one in your batch?
<pedronis> mborzecki: no it actually starts with 6810
 * pedronis has 6 open PRs and more coming
<pedronis> mvo should review those, but they will need 2nd reviews
<mup> PR snapd#6824 closed: release: 2.39 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6824>
<zyga> mborzecki: yes
<zyga> mborzecki: the PKGBUILD change was insufficient?
<mborzecki> zyga: pacman only issues a warning that the local permission bits are different
 * dot-tobias says hi
<mborzecki> mvo: left some comments under 6825, played with this locally and i think handling this from Go will be super tricky
<zyga> mvo: offtopic-ish: I'd love to see snap run ltrace
<zyga> perhaps doing per-tool hacks could be changed to a some sort of special hook (which could be a shell script) that allows us to add tools at ease?
<mvo> mborzecki: thanks, in a meeting right now - does that mean the approach is doomed?
<mborzecki> mvo: i don't think it's doomed, we just need to figure out a way how to make gdb, inferion and snap run not fight for the terminal
 * mvo nods
<zyga> mborzecki, mvo: https://forum.snapcraft.io/t/gpu-support-proposal/11247
<zyga> Brb
 * pstolowski lunch
<mborzecki> pedronis_: answered some of your questions under https://github.com/snapcore/snapd/pull/6750 maybe we could have chat with mvo after the standup
<mup> PR #6750: overlord/devicestate: update-gadget task handler with stubbed gadget callbacks <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6750>
<mup> PR snapd#6830 opened: interfaces/dbus: fix unit tests when default snap mount dir is not /snap <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6830>
<mborzecki> super simple PR ^^
<mup> PR snapd#6765 closed: tests: add security-seccomp to verify seccomp with arg filtering <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6765>
<pedronis> mborzecki: yes, we should have a chat with mvo
<pedronis> mborzecki: this was fun btw:  https://github.com/snapcore/snapd/pull/6828/commits/88b5794137a15266c7751ef865272402b26a8dd8 :)
<mup> PR #6828: many: use a fake assertion model in the device contexts for tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/6828>
<mborzecki> pedronis: nice
<mborzecki> pedronis: mvo: after standup then?
<pedronis> mborzecki: could work if it's not too long, we have a meeting after
<mborzecki> pedronis: ok, otherwise tomorror morning maybe?
<pedronis> yes
<mborzecki> ack
<mborzecki> off to pick up the kids
<jdstrand_> mborzecki: thanks for keeping an eye on that PR
<mup> PR snapd#6830 closed: interfaces/dbus: fix unit tests when default snap mount dir is not /snap <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6830>
<pedronis> pstolowski: thanks for looking at my PRs
<pstolowski> np
<zyga> drat, the forum does not support SVG images
<roadmr> :(
<mborzecki> zyga: github does (kind of), maybe if you link to it?
<zyga> I will link to a repo with the .dot files, for now the image is enough
<zyga> mborzecki: fyi https://forum.snapcraft.io/t/hello-world-cuda-analysis/11250
<zyga> mborzecki: isn't that image nice? :)
<mborzecki> zyga: that's from strace logs?
<zyga> mborzecki: yep
<zyga> mborzecki: + some tooling
<zyga> mborzecki: + love :)
<mborzecki> zyga: nice!
<zyga> mborzecki: I have much more, just finally nailed how I want the FS access to look like
 * zyga updated https://forum.snapcraft.io/t/hello-world-cuda-analysis/11250 and goes for lunch
<zyga> hey ijohnson
<ijohnson> hey zyga
<zyga> ijohnson: I've added https://forum.snapcraft.io/t/hello-world-cuda-analysis/11250 and I will soon make a post like that about openGL (which will be much much longer as there is far more data and complexity there)
<ijohnson> zyga: nice, I saw your post there! BTW, not sure if you're aware but I also created a snap with cuda samples from the SDK that bundles libcuda inside the snap, not sure if that would be useful to you or not
<zyga> ijohnson: I think I saw that a while ago, the snap itself is interesting but I followed a simple cuda tutorial on the nvidia website, I mainly itererated on the tooling and analysis of what is going on at runtime so that I can form some kind of vision about how to support GPUs in snapd better
<zyga> ijohnson: I have 4 GPUs on my desk and I've been experimenting with various drivers for a few days
<ijohnson> zyga: I may be mistaken, but using CUDA with multi-GPU setups may use different accesses (not libraries but like /dev) - if you're able it might be worth trying to setup your machine with multiple nvidia GPUs that are compatible (I think as long as your GPUs aren't more than 5 years old they should work) with multi-GPU CUDA and then you can try to run the multi-GPU samples from my snap
<zyga> ijohnson: there are more /dev/nvidia{1,2,3} entries for sure, I only have one quadro card but your remark is spot on. I will look for a few more cards to buy before Lyon
<ijohnson> I have a discrete GPU in my desktop and another discrete in my laptop but unfortunately haven't been able to get ahold of 2 discrete cards I can plug into my desktop
<zyga> ijohnson: the magic of olx.pl (like craigslist, I guess) and my mobo-on-desk setup  :)
<ijohnson> nice :)
 * cachio lunch
<albertosottile> Hi guys, what are usually the times needed for a classic confinement approval request?
<zyga> I'll EOD now
<zyga> albertosottile: hey, it  usually takes a few days, sometimes longer when holidays or a longer backlog intervene
<albertosottile> zyga: thanks, we have been waiting for 5 days but there was a weekend in between, so it might be that
<mup> PR snapcraft#2555 opened: extensions: block direct use of private extensions <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2555>
<zyga> jdstrand: FYI https://forum.snapcraft.io/t/hello-world-cuda-analysis/11250
<jdstrand> zyga: nice writeup
<AlexPortable> Can someone help me creating a snap for a wine application?
<AlexPortable> I used this https://github.com/mmtrt/notepad3 as a basis, but i'm stuck at the copying of the file, it says can't find the file (in the original script it uses wget)
<AlexPortable> should I start over from scratch?
<mup> PR snapd#6810 closed: many: do without device state/assertions accessors based on state only outside of devicestate/tests <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6810>
<pedronis> I rebased on #6817 on master, it's ready for reviews (it's not too big)
<mup> PR #6817: overlord,overlord/devicestate: do without GadgetInfo/KernelInfo in devicestate <Created by pedronis> <https://github.com/snapcore/snapd/pull/6817>
<mup> PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mup> PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mup> PR snapd#6831 opened: tests: retry govendor sync to minimize the number of connection errors on prepare <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6831>
<mup> PR snapcraft#2556 opened: cli: snapcraft promote <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2556>
<mup> PR snapcraft#2557 opened: ci: remove dependency on LXD from travis tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2557>
#snappy 2019-05-07
<mup> PR snapcraft#2551 closed: project: read local plugins from build-aux <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2551>
<mup> PR snapcraft#2555 closed: extensions: block direct use of private extensions <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2555>
<mborzecki> morning
<mborzecki> kernel update, brb
<zyga> Good morning
<mborzecki> zyga: hey
<mborzecki> zyga: so when do we get to work on snaps for windows?
<zyga> Exactly
<zyga> I wonder if they will just work
<zyga> Quick walk and I will be in the office
<mvo> good morning
<zyga> Good morning pedronis, mvo
<pstolowski> morning
<mborzecki> pstolowski: mvo: pedronis: hey
<mborzecki> pstolowski: any branches for review?
<zyga> hey pawel
<pstolowski> mborzecki: hey, #6793 needs 2nd review, ty!
<mup> PR #6793: cmd/snap: support for --ensure argument for snap debug timings <Created by stolowski> <https://github.com/snapcore/snapd/pull/6793>
<mborzecki> pstolowski: k, looking
<mvo> 6819 needs a review and is quite simple
<mvo> unless you guys disagree I would like to delete some labels, the list gets a bit unwieldy. I would like to kill: "reviewed", "decaying", "parallel installs", "selinux", "complex", "core18" - wdyt?
<mup> PR snapd#6813 closed: data: update XDG_DATA_DIRS via the systemd environment.d mechanism too <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6813>
<mup> PR snapd#6832 opened: gadget: more validation checks for legacy MBR structure type & role <Gadget update> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6832>
<mborzecki> another super simple PR ^^
<mvo> mborzecki: any concerns if I delete the "selinux" label?
<mborzecki> mvo: no, go ahead, we can always add it back if there's more selinux work
<mvo> mborzecki: same for parallel installs?
<zyga> GH projects work nice for concentrators
<zyga> labels feel more like "bug" "feature" "simple" "critical"
<mvo> zyga: aha, I need to look at those haven't done so yet :/
<mvo> zyga: yeah, this is why I wanted to thin them a bit
<zyga> mvo: I use them (better to ask for forgiveness as they say :)
<mborzecki> mvo: we'll have some parallel installs work, but it's ok to drop this label too
<mup> PR snapd#6833 opened: many: intrroduce assertstest.SigningAccounts and AddMany test helpers <Created by pedronis> <https://github.com/snapcore/snapd/pull/6833>
<mup> PR snapd#6819 closed: osutil: fix TestReadBuildGo test in sbuild <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6819>
<pedronis> mvo: #6833 is the refactoring I started on Friday about signing models, fun ride
<mup> PR #6833: many: introduce assertstest.SigningAccounts and AddMany test helpers <Created by pedronis> <https://github.com/snapcore/snapd/pull/6833>
<mvo> pedronis: cool
<pedronis> maybe :)
<zyga> heh :)
<mvo> pedronis: heh
<mvo> pedronis: 6817 is the one that needs the next review, right?
<pedronis> mvo: yes, next in chain (then the chain becomes  a tree a couple of times)
<zyga> https://github.com/snapcore/snapd/pull/6796 is an easy one
<mup> PR #6796: cmd/snap-update-ns: add no-op load/save current user profile logic <Created by zyga> <https://github.com/snapcore/snapd/pull/6796>
<mborzecki> pstolowski: can you ask for snap debug timings --ensure=foo <change-id> ?
<pstolowski> mborzecki: atm no, i dropped it in favor of getting the latest ensure or all of them. i can add it back though
<mborzecki> pstolowski: ok, but if you do snap debug timings --ensure=foo you can still get timing data on related changes right?
<pstolowski> yes
<mup> PR snapd#6834 opened: daemon: pass the model to the create known user helpers (instead of full Overlord) <Created by pedronis> <https://github.com/snapcore/snapd/pull/6834>
<pedronis> pstolowski: mborzecki: I did the thing we discussed yesterday in the last commit here ^
<mborzecki> ack
<pstolowski> pedronis: ty
<zyga> mvo: I'm preparing proper demo snaps, I have a CUDA snap that works in both legacy (current nvidia sharing) and modern (content based sharing) mode now
<zyga> mvo: I need to take a break for an hour because my father in-law just sold the desk I'm using for my testbench
<zyga> so... small inconvenience there
<mvo> zyga: nice
<mvo> zyga: well, that your desk is sold is not so nice
<zyga> mvo: we wanted to sell it for several weeks now
<zyga> but now his work colleague just decided he could use it :)
<zyga> it's an older desk and I wanted to get rid of it because it doesn't fit the rest of office furniture and is too small for my needs
<zyga> I just used it to place the testbench on it :)
<zyga> my main desk is safe :D
<zyga> mvo: on the up side I will get a standing desk
<zyga> just ordered one from ikea :)
<mborzecki> zyga: hahah afer all :P
<mborzecki> zyga: bekant?
<zyga> mborzecki: exactly
<mup> PR snapd#6832 closed: gadget: more validation checks for legacy MBR structure type & role <Gadget update> <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6832>
<zyga> mborzecki: actually, I just cancelled and got IDASEN
<mborzecki> zyga: ha, they have those again?
<zyga> apparently, there are three in the ikea closest to us
<zyga> the legs look more sturdy
<mborzecki> zyga: last i checked (last staurday), they were unavailable online
<zyga> and the price is the same
<mborzecki> zyga: mhm, nice, it should be more sturdy than bekant
<zyga> mborzecki: I also got the TROLLBERGET stool because it will look nice together :)
<mborzecki> zyga: troll's hill? :)
<zyga> haha, does that mean troll's hill?
<zyga> am I the troll now :D
<mborzecki> hill/mountain iirc
<pstolowski> mborzecki: pushed changes to 6793
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#104 closed: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#104 opened: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
 * mvo thinks mup is a bit confused
<mborzecki> fatal: unable to access 'https://github.com/snapcore/snapd.git/': The requested URL returned error: 503
<mborzecki> hm so a day off then?
<pstolowski> hmm yeah i see a pony
<mborzecki> and a unicorn: https://i.imgur.com/ikJTURq.png
<pstolowski> right, s/pony/unicorn/ :)
<pstolowski> https://www.githubstatus.com all green
<pstolowski> ok, not anymore
<mborzecki> pnycorn
<zyga> re
<zyga> back to work :)
<zyga> well, I mean, I stopped doing the office changes and desk departure preparations
<zyga> github is still down
<ackk> hi, I have a weird multipass issue, is discussing here fine or is there a better channel?
<ackk> actually, it seems related to snapd
<ackk> it seems snapd is running 2 versions of the multipass snap in parallel
<ackk> how do I remove a snap revision that's unknown to snapd?
<ackk> ah, I had to kill all processes and squashfuse to make it go away
<mborzecki> heh git fetch still broken
<mwhudson> is there any chance of snapcraft growing the ability to verify that a source tarball is signed by a particular key?
<mwhudson> i'm sure i found a bug for this at some point but can't find it now
<mwhudson> ah https://bugs.launchpad.net/snapcraft/+bug/1626632
<mup> Bug #1626632: snapcraft part sources are not verified for authenticity <Snapcraft:Triaged> <https://launchpad.net/bugs/1626632>
<mwhudson> not quite a year since i commented on it...
<zyga> mwhudson: I think your best chance is to catch sergio or claudio early in your day
<mup> PR snapd#6835 opened: snapstate: allow removal of non-model kernels <Created by mvo5> <https://github.com/snapcore/snapd/pull/6835>
<zyga> mvo: ^ reviewed
<mvo> zyga: thank you!
<pstolowski> pedronis: #6817 can land
<mup> PR #6817: overlord,overlord/devicestate: do without GadgetInfo/KernelInfo in devicestate <Created by pedronis> <https://github.com/snapcore/snapd/pull/6817>
<pedronis> thx
<zyga> hmmm
<zyga> LD_LIBRARY_PATH=/var/lib/snapd/lib/gl:/var/lib/snapd/lib/gl32:/var/lib/snapd/void:/snap/snapd-cuda-sample/x6/usr/lib/cuda-runtime::/snap/snapd-cuda-sample/x6/usr/lib
<zyga> how did we add /var/lib/snapd/void to LD_LIBRARY_PATH?
<zyga> aha https://github.com/snapcore/snapd/pull/2732#pullrequestreview-18827193
<mup> PR #2732: snapenv: do not append ":" to the SNAP_LIBRARY_PATH <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2732>
<mup> PR snapd#6817 closed: overlord,overlord/devicestate: do without GadgetInfo/KernelInfo in devicestate <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6817>
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#104 closed: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#104 opened: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
 * cachio afk
<zyga> afk for lunch and walk
<mup> PR snapd#6836 opened: overlord/snapstate: add update-gadget task when needed, block other changes <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6836>
<mborzecki> mvo: pedronis: ^^ conflicts check & snapstate changes
<pedronis> mvo: where?
<pedronis> sory
<pedronis> mborzecki: where, in your PR ?
<mborzecki> pedronis: yeah, the PR adding the task handler is actually separate, but that shouldn't be a problem
<cmatsuoka> zyga: any chance of snapd working with wsl2? not many kernel configuration details at this point, but do you see any big show stopper?
<mborzecki> cmatsuoka: probably hard to tell now knowing their kernel config, but they claim to be able to run docker and fuse
<mborzecki> pity they don't share the details about how it's all wired with windows kernel, wheether that's some elaborate hyper-v setup or something else
<cmatsuoka> yep, I see the possibility there, but I think there are many things that could go wrong
<cmatsuoka> mborzecki: whoops, posted a comment to the PR and forgot to +1
<cmatsuoka> ok
<cmatsuoka> niemeyer: diddledan addressed most the issues you raised for the gnome extension PR (only the error message wording open for discussion)
 * diddledan lurks like a lurky thing lurking
<ondra> zyga ping
<zyga> standup
<zyga> ondra: what's up? :)
<ondra> zyga hey, wanted to ask about spi device node name check
<ondra> zyga you added there /dev/spidev[0-9].[0-9]+$
<ondra> zyga I have device with /dev/spidev32766.0
<ondra> zyga I wonder it this is usual or we are too conservative about name sanity check
<zyga> ondra: is that number stable? where does it come from?
<zyga> ondra: it looks ugly TBH but then again, it's hardware, if there's a good reason for it perhaps that's just the case
<ondra> zyga I can't comment how stable is that number, or do you mean over reboots?
<zyga> yes, ideally we'd know exactly where it comes from
<zyga> is it hardcoded in the driver?
<zyga> is it coming from the device tree?
<zyga> etc
<ondra> zyga let me ask dev working with that device if number is persistent over reboots
<zyga> this will help us weigh on the decision
<ondra> zyga I asked, but I think it's persistent, given it's 0x7FFE, so not exactly random
<zyga> 0xCAFEBABE
<zyga> ;-)
<zyga> ondra: thanks, please let me know once you know more
<zyga> ondra: a forum topic is a nice way to record the conversation for proposal to pedronis later on
<ondra> zyga sure :)
<zyga> thank you!
<zyga> I'm sorry for being slow on some older bugs you reported, I really want to get to them but for now sprint preparation takes priority
<mup> PR # closed: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6541, snapd#6564, snapd#6588, snapd#6618, snapd#6648, snapd#6653, snapd#6666, snapd#6679, snapd#6680, snapd#6681,
<mup> snapd#6691, snapd#6695, snapd#6697, snapd#6703, snapd#6705, snapd#6708, snapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6751, snapd#6759, snapd#6760, snapd#6767, snapd#6775, snapd#6776, snapd#6790, snapd#6793, snapd#6795, snapd#6796, snapd#6798, snapd#6803, snapd#6804, snapd#6805, snapd#6811,
<mup> snapd#6816, snapd#6820, snapd#6821, snapd#6822, snapd#6823, snapd#6825, snapd#6826, snapd#6828, snapd#6829, snapd#6831, snapd#6833, snapd#6834, snapd#6835, snapd#6836
<diddledan> someone just had a productive afternoon :-p
<mup> PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6541, snapd#6564, snapd#6588, snapd#6618, snapd#6648, snapd#6653, snapd#6666, snapd#6679, snapd#6680, snapd#6681,
<mup> snapd#6691, snapd#6695, snapd#6697, snapd#6703, snapd#6705, snapd#6708, snapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6751, snapd#6759, snapd#6760, snapd#6767, snapd#6775, snapd#6776, snapd#6790, snapd#6793, snapd#6795, snapd#6796, snapd#6798, snapd#6803, snapd#6804, snapd#6805, snapd#6811,
<mup> snapd#6816, snapd#6820, snapd#6821, snapd#6822, snapd#6823, snapd#6825, snapd#6826, snapd#6828, snapd#6829, snapd#6831, snapd#6833, snapd#6834, snapd#6835, snapd#6836
<zyga> diddledan: mup had a long nap ;)
<diddledan> bah. and now a less productive one :-p
<diddledan> haha
<roadmr> holy crap :)
<niemeyer> cmatsuoka, diddledan: The response about the adapter seems like a blocker to me
<niemeyer> cmatsuoka, diddledan: The question was asked precisely because the logic is obsolete and needs to go away.. Sergio seems to confirm that.. we should not release a brand new extension that cooks into it behavior that is obsolete and needs to be removed. Extensions need to respect their interface forever, as long as the base is the same.
<zyga> cmatsuoka: re wsl2, I strongly believe it will work, the question remains on kernel configuration cooked by microsoft; I suspect someone at canonical might know but that's not me
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#104 closed: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#104 opened: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
<mup> PR # closed: snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433, snapcraft#2470, snapcraft#2495, snapcraft#2500, snapcraft#2514, snapcraft#2518, snapcraft#2527, snapcraft#2537, snapcraft#2539, snapcraft#2541, snapcraft#2544, snapcraft#2556, snapcraft#2557
<mup> PR # opened: snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433, snapcraft#2470, snapcraft#2495, snapcraft#2500, snapcraft#2514, snapcraft#2518, snapcraft#2527, snapcraft#2537, snapcraft#2539, snapcraft#2541, snapcraft#2544, snapcraft#2556, snapcraft#2557
<mup> PR # closed: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6541, snapd#6564, snapd#6588, snapd#6618, snapd#6648, snapd#6653, snapd#6666, snapd#6679, snapd#6680, snapd#6681,
<mup> snapd#6691, snapd#6695, snapd#6697, snapd#6703, snapd#6705, snapd#6708, snapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6751, snapd#6759, snapd#6760, snapd#6767, snapd#6775, snapd#6776, snapd#6790, snapd#6793, snapd#6795, snapd#6796, snapd#6798, snapd#6803, snapd#6804, snapd#6805, snapd#6811,
<mup> snapd#6816, snapd#6820, snapd#6821, snapd#6822, snapd#6823, snapd#6825, snapd#6826, snapd#6828, snapd#6829, snapd#6831, snapd#6833, snapd#6834, snapd#6835, snapd#6836
<zyga> re
<cmatsuoka> niemeyer: thanks! I'll coordinate with sergiusens and diddledan to address the adapter issue
<mup> PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6541, snapd#6564, snapd#6588, snapd#6618, snapd#6648, snapd#6653, snapd#6666, snapd#6679, snapd#6680, snapd#6681,
<mup> snapd#6691, snapd#6695, snapd#6697, snapd#6703, snapd#6705, snapd#6708, snapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6751, snapd#6759, snapd#6760, snapd#6767, snapd#6775, snapd#6776, snapd#6790, snapd#6793, snapd#6795, snapd#6796, snapd#6798, snapd#6803, snapd#6804, snapd#6805, snapd#6811,
<mup> snapd#6816, snapd#6820, snapd#6821, snapd#6822, snapd#6823, snapd#6825, snapd#6826, snapd#6828, snapd#6829, snapd#6831, snapd#6833, snapd#6834, snapd#6835, snapd#6836
<niemeyer> Looks like GitHub is unhappy lately
<zyga> yep, many unicorns today
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38
<mup> PR # closed: snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433, snapcraft#2470, snapcraft#2495, snapcraft#2500, snapcraft#2514, snapcraft#2518, snapcraft#2527, snapcraft#2537, snapcraft#2539, snapcraft#2541, snapcraft#2544, snapcraft#2556, snapcraft#2557
<mup> PR # opened: snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433, snapcraft#2470, snapcraft#2495, snapcraft#2500, snapcraft#2514, snapcraft#2518, snapcraft#2527, snapcraft#2537, snapcraft#2539, snapcraft#2541, snapcraft#2544, snapcraft#2556, snapcraft#2557
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38
<pstolowski> pedronis: could you merge master into #6821?
<mup> PR #6821: many: make which store to use contextual  <Created by pedronis> <https://github.com/snapcore/snapd/pull/6821>
<pedronis> pstolowski: yes, in a little bit (in a meeting)
<pstolowski> k
<pedronis> pstolowski: done
<pstolowski> ty
<mup> PR # closed: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6541, snapd#6564, snapd#6588, snapd#6618, snapd#6648, snapd#6653, snapd#6666, snapd#6679, snapd#6680, snapd#6681,
<mup> snapd#6691, snapd#6695, snapd#6697, snapd#6703, snapd#6705, snapd#6708, snapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6751, snapd#6759, snapd#6760, snapd#6767, snapd#6775, snapd#6776, snapd#6790, snapd#6793, snapd#6795, snapd#6796, snapd#6798, snapd#6803, snapd#6804, snapd#6805, snapd#6811,
<mup> snapd#6816, snapd#6820, snapd#6821, snapd#6822, snapd#6823, snapd#6825, snapd#6826, snapd#6828, snapd#6829, snapd#6831, snapd#6833, snapd#6834, snapd#6835, snapd#6836
<mup> PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6541, snapd#6564, snapd#6588, snapd#6618, snapd#6648, snapd#6653, snapd#6666, snapd#6679, snapd#6680, snapd#6681,
<mup> snapd#6691, snapd#6695, snapd#6697, snapd#6703, snapd#6705, snapd#6708, snapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6751, snapd#6759, snapd#6760, snapd#6767, snapd#6775, snapd#6776, snapd#6790, snapd#6793, snapd#6795, snapd#6796, snapd#6798, snapd#6803, snapd#6804, snapd#6805, snapd#6811,
<mup> snapd#6816, snapd#6820, snapd#6821, snapd#6822, snapd#6823, snapd#6825, snapd#6826, snapd#6828, snapd#6829, snapd#6831, snapd#6833, snapd#6834, snapd#6835, snapd#6836
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#104 closed: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#104 opened: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117
<mup> PR # closed: core18#43, core18#72, core18#90, core18#98, core18#122, core18#126, core18#127
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117
<mup> PR # opened: core18#43, core18#72, core18#90, core18#98, core18#122, core18#126, core18#127
<zyga> mvo: btw, I solved that issue I mentioned during the standup :)
<zyga> mvo: and in an elegant way as well, I'd love to show you in a moment
<mvo> zyga: in a meeting - but sounds amazing
<cachio> pstolowski, hey
<zyga> mvo: sure, nothing urgent :)
<cachio> pstolowski, a test failed in a board https://paste.ubuntu.com/p/s9xrbG6mgc/
<pstolowski> cachio: hey, what's up?
<cachio> for 2.39
<pstolowski> cachio: oh, interesting. looking
<cachio> pstolowski, perhaps you have an idea
<cachio> it happened in a caracalla
<cachio> it is amd64
<pstolowski> cachio: i implemented the option, not sure what happened. need to check
<cachio> pstolowski, sure, thanks
<mup> PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mup> PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<cachio> mvo, hey, could you please include this #6753 on 2.39?
<mup> PR #6753: tests: fix spaces issue in the base snaps names to remove during reset phase <Simple ð> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6753>
<cachio> mvo, for next cycle?
<pstolowski> cachio: https://github.com/snapcore/snapd/pull/6837
<mup> PR #6837: tests: extra debug for snapshot-basic test <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6837>
<mup> PR snapd#6837 opened: tests: extra debug for snapshot-basic test <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6837>
<mvo> cachio: sure, thank you
<pstolowski> mvo: do you have moment for this trivial https://github.com/snapcore/snapd/pull/6837 ? i'll then prep 2.39 PR
<mup> PR #6837: tests: extra debug for snapshot-basic test <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6837>
<mvo> cachio: merging
<mvo> pstolowski: in a meeting
<zyga> sergiusens: is there a way to tell snapcraft to use my apt proxy?
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#104 closed: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#104 opened: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
<mup> PR snapd#6838 opened: overlord/devicestate: introduce remodel kinds and contexts <Created by pedronis> <https://github.com/snapcore/snapd/pull/6838>
<pedronis> mvo: in #6838 interesting things start to happen
<mup> PR #6838: overlord/devicestate: introduce remodel kinds and contexts <Created by pedronis> <https://github.com/snapcore/snapd/pull/6838>
<mup> PR snapcraft#2495 closed: Hide progress bar for dumb terminals - legacy branch <Created by eberkund> <Closed by eberkund> <https://github.com/snapcore/snapcraft/pull/2495>
 * zyga needs to take a break
<cachio> mvo, thanks
 * zyga hacks some more
<pedronis> do we need what's broken atm that give lots of failing runs?
<pedronis> s/need/know/
<mup> PR snapd#6837 closed: tests: extra debug for snapshot-basic test <Simple ð> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6837>
<sergiusens> zyga: no, not currently
<zyga> sergiusens: feature request :)
<sergiusens> zyga: you missed the window, there was a spreadsheet to propose that got locked down today with all the managers ;-)
<zyga> sergiusens: we always have blue
<zyga> it's just a pain to rebuild big snaps now
<sergiusens> zyga: let cmatsuoka return to the realms of snapcraft and we will see what we can do :-)
<sergiusens> until then, I will be ramping up someone new for the next month or so
<zyga> sergiusens: is there a way to run post-spawn hook in multipass?
<zyga> anything that I could use to do it myself?
<sergiusens> zyga: no, the only thing I can think of is for you to edit snapcraft.yaml, for a part to be the first to run, override-pull, setup your proxy and then trigger the actual pull if it is to do anything at all
<zyga> sergiusens: thanks!
<mup> PR snapd#6839 opened: devicestate: allow remodel to different kernels  <Created by mvo5> <https://github.com/snapcore/snapd/pull/6839>
<zyga> woot
<zyga> cuda awesomeness :)
<zyga> sergiusens: command-chain is funky
<zyga> :)
<zyga> I'm using it now
<zyga> mvo: hey
<zyga> mvo: still working?
<mup> PR snapcraft#2558 opened: vcs: ignore .idea <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2558>
<zyga> uh
<zyga> gaah
<zyga> jdstrand: hey
<zyga> jdstrand: do you have a moment?
<zyga> oOoohh
<zyga> I think I got it!!!
<jdstrand> zyga: just in time! seriously, what's up?
<zyga> jdstrand: do you have a moment for a quick HO
<zyga> I was debugging something all day
<zyga> and I think I got it
<jdstrand> ok
<zyga> but I need your wisdom
<jdstrand> you caught me at just the right time
<jdstrand> (between things)
<jdstrand> well, I don't know about wisdom, but happy to talk :)
<zyga> https://meet.google.com/ezm-mvjc-evs?authuser=0&ijlm=1557256621565&adhoc=1&hs=125
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117
<mup> PR # closed: core18#43, core18#72, core18#90, core18#98, core18#122, core18#126, core18#127
<mup> PR snapcraft#2558 closed: vcs: ignore .idea <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2558>
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117
<mup> PR # opened: core18#43, core18#72, core18#90, core18#98, core18#122, core18#126, core18#127
<zyga> jdstrand: man
<zyga> jdstrand: that bug
<zyga> it's so dumb
<zyga> jdstrand: I recall fixing it already
<zyga> jdstrand: it didn't land, it was a part of feature branch somewhere
<jdstrand> zyga: oh! well, at least you very much know what it is :)
<zyga> jdstrand: we unshare once too many
<jdstrand> I think I remember looking at that feature branch and you saying it now that you mention it
<zyga> jdstrand: unshare, change to rslave, unshare
<zyga> jdstrand: the bug is different though, caused by tmpfs
<mup> PR snapcraft#2557 closed: ci: remove dependency on LXD from travis tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2557>
<mup> PR snapcraft#2559 opened: manifest: expose snapcraft-started-at <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2559>
<LuckyMan> I did a snap refresh but the info on a snap I'm making (and have deployed to edge) appears with two different timestamps, one on lubuntu 18.04 and other time on ubuntu 19.04. Which version is installed on 18.04?
<LuckyMan> (the oldest info is on 18.04)
<LuckyMan> oh wait, I can see the revision number
<LuckyMan> It seems on lubuntu 18.04 I get an old rev installed
<roadmr> jdstrand: hey! reviewer-tools r1228 are now in production
<jdstrand> roadmr: awesome, thanks! :)
#snappy 2019-05-08
<mborzecki> morning
<zyga> Hey
<zyga> mborzecki: I found a hell of a bug yesterday
<zyga> Working >12 hours but was worth it
<mborzecki> zyga: hey, what bug?
<zyga> Mount namespaces are seriously busted
<zyga> This explains all the odd reports I got
<zyga> I am tired a bit, still in bed
<mborzecki> zyga: nice that you found it :)
<zyga> I spent half of yesterday trying to nail what was going on
<zyga> There are several bugs
<zyga> I know of two for sure because those got fixed in my branch
<zyga> The third one I know where it is but I was too tired to figure out where it is past 23:00
<zyga> Hehe
<zyga> To figure out exactly where it is
<zyga> Those are all serious enough I think we should do .2
<zyga> Hey mvo
<zyga> I found a naaaasty bug last night
<mvo> hey zyga ! good morning
<mvo> zyga: uh, that sounds bad - can you tell me more please?
<zyga> Mvo: mount namespaces have three bugs that cripple content sharing
<zyga> 1) we unshare one too many times, this was fixed about 6 months ago but not merged, lost in a feature branch
<zyga> 2) sharing is broken so user mount namespace does not get propagation correctly, breaking on refresh or reconnect depending on use
<zyga> 3) ordering of mount operations is wrong, causing shadowing of past mounts
<zyga> Lots of craze last night
<zyga> I had a call with Jamie to discuss some of this
<zyga> 1 is simple
<zyga> 2 is todo, didnât debug as I realized this was broken after 23:00
<zyga> 3 is complex and requires some algorithm work
<zyga> Together those break gnome runtime sharing, theme sharing and perhaps other cases
<mvo> zyga: uh, that sounds nasty
<mvo> zyga: lets talk some more in some minutes, I make a cup of tea
<zyga> Excellent idea :-)
<mborzecki> mvo: morning
<mvo> hey mborzecki
<zyga> mvo: back in the office
<zyga> slowly waking up
<pedronis>  morning
<pedronis> could we get a 2nd review of #6775
<mup> PR #6775: devicestate: make Remodel() return a state.Change <Created by mvo5> <https://github.com/snapcore/snapd/pull/6775>
<pstolowski> morning
<pedronis> pstolowski: hi, I have a question in #6793
<mup> PR #6793: cmd/snap: support for --ensure argument for snap debug timings <Created by stolowski> <https://github.com/snapcore/snapd/pull/6793>
<mborzecki> pedronis: pstolowski: hey
<pstolowski> pedronis: yes... you're right, i forgot about those
<pstolowski> i mean about nesting them visually
<mup> PR snapd#6790 closed: interfaces: add login-session-control interface <Created by AlanGriffiths> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6790>
<mvo> zyga: was wondering about 6751, it seems it just misses a unit test to go into master, can I help you with that? I would love to land this before lyon
<zyga> mvo: perhaps, I will try to devote an hour to it today
<zyga> sorry for taking so long, yesterday was a marathon of debugging
<mvo> zyga: I can look at it, I understand you are looking at important bugs
<pedronis> pstolowski: thanks, so  I wasn't confused, I think we do the same with ^ as for the change.
<pstolowski> pedronis: yes
<pedronis> pstolowski: let me make a comment in the PR itself
<pedronis> mborzecki: made a couple of comments in 6750
<pedronis> one is not of immediate relevance
<mborzecki> pedronis: thanks, reading through them now
<pedronis> pstolowski: for Ensure, is the label of level 0 usually the same as the "ensure" tag, or is just for some ?
<mup> Bug #1828175 opened: Lack of proxy support for snap prepare-image <Snappy:New> <https://launchpad.net/bugs/1828175>
<pstolowski> pedronis: using refresh catalogs as an example: we have "ensure": "refresh-catalogs", then two nested measurements under it: with "get-sections" and "write-catalogs" labels
<pedronis> pstolowski: thx, noticed the same
<pedronis> pstolowski: I was thinking a bit about what to put in ID, but given that we don't want to make lines too long
<pedronis> "ensure" seems fine  (it's a debugging thing and one should know what they asked)
<mvo> zyga: I will push something shortly
<mborzecki> pstolowski: if we can tweak the formatting of timing entries a bit, may we use ---^ or --- to fill the line before ^ sign?
<mborzecki> pstolowski: http://paste.ubuntu.com/p/7dWSfRbTrc/ this is what i mean, the ^ dashes feel a bit hard to follow
<pstolowski> pedronis: actually, we won't see "^" nesting for ensures right now, the refresh-catalogs is the root node with tags, then get-sections and write-catalogs are at level 0. for tasks level 0 measurements appear nested visually because we put them under task line
<mborzecki> Chipaca: welcome back
<Chipaca> mborzecki: :)
<pstolowski> mborzecki: yep, i tend to agree, but i'd leave it for a potential followup, this had already been disputed about in one of the first PR in these series ;)
<mborzecki> pstolowski: mhm, sounds good to me, i don't have an immediate suggestion now either, but maybe we'll come up with something once people start using it
<Chipaca> pedronis: you around?
<mborzecki> got a quick errand to run, back in ~30
<pstolowski> pedronis: pushed some changes + reply to your comment
<pstolowski> pedronis: also, i need to discuss with you some aspects of snap unset implementation that i touched breifly with mvo yesterday in the standup; would be great to meet (three of us) today
<mborzecki> re
<pedronis> pstolowski: sorry was in meetings,  interesting about the 0 level, maybe we should have an articial one
<pedronis> though maybe is just a wasted line, but it would clarify things
<pstolowski> pedronis: yes, i can add this
<pstolowski> pedronis: nb, can you merge master into your PRs? i'm about to do reviewing, will make diffs smaller
<pstolowski> pedronis: eg #6822 (and it has a conflict)
<mup> PR #6822: overlord/devicestate: introduce registrationContext <Created by pedronis> <https://github.com/snapcore/snapd/pull/6822>
<pedronis> pstolowski: basically the articial line should contain  "ensure" and somewhere the ensure tag
<pedronis> pstolowski: can also be a follow up a this point though
<pedronis> pstolowski: yes, need a little break after the meetings but will look at my PRs, I'm also doing reviews
<pedronis> of some team PRs
<pedronis> pstolowski: btw you can review mvo 6775 and 6776 if you are wating to review mines
<pstolowski> pedronis: ok. yep i'd prefer a followup
<pstolowski> pedronis: did you see my message about the need of discussing snap unset?
<mborzecki> anyone up for a 2nd review of https://github.com/snapcore/snapd/pull/6798 ?
<mup> PR #6798: gadget: introduce checkers for sanitizing structure updates <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6798>
 * zyga woke up again
<zyga> sorry everyone, had a rough night
<zyga> mvo: thank you for the tests
<pedronis> pstolowski: yes, are you blocked?  I can do after lunch or immeditately after standup, but not sure when mvo can
<pstolowski> pedronis: a bit blocked yes, but i'm doing reviews so it can wait for later today
<mup> PR snapd#6826 closed: tests: enable tests on centos 7 again <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6826>
 * Chipaca afk for a while
<zyga> man that's so darn annoying
<zyga> I'm staring the bug in the face
<zyga> I see it's wrong
<zyga> but yet WHY eludes me
<cachio> mvo, hey
<cachio> mvo, could you please merge #6694 to 2.39? I need that to finish snapd validation
<mup> PR #6694: tests: improve how snaps are cached <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6694>
<mvo> cachio: uh, 27 commits, let me see how we can do this
<mvo> I can't cherry pick this indivudally
<mvo> cachio: lets talk after (my) lunch, we get this in I might need to do it with conflicts instead of as cherry-picks
<cachio> mvo, sure
<cachio> thanks
<zyga> brb
<zyga> uhhhh
<zyga> re
<pedronis> pstolowski: we could chat now but maybe you and mvo are having lunch atm
<pstolowski> pedronis: works for me if mvo is around
<pedronis> pstolowski: do we need mvo?
<pedronis> pstolowski: I'm in the standup channel
<pstolowski> pedronis: ok, coming
<mup> PR snapcraft#2560 opened: meta: do not wrap commands by default <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2560>
 * Chipaca goes in quest of food
<mup> PR snapd#6821 closed: many: make which store to use contextual  <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6821>
<pedronis> Chipaca: ^ that provoked conflicts in your PRs I fear
<pedronis> I can look into that myself in a bit
<cmatsuoka> niemeyer: do you prefer adapter: none or no adapter line at all in the gnome extension?
<cmatsuoka> (sergiusens is changing that now and we can do it in either way)
<cachio> q
<pedronis> #6828 can be reviewed  (because of later pushes 6822 comes later in the chain now)
<mup> PR #6828: many: use a fake assertion model in the device contexts for tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/6828>
<mup> PR snapd#6840 opened: gadget: fix handling of positioning constrains for structures of MBR role <Gadget update> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6840>
<mborzecki> simple PR ^^ cmatsuoka pstolowski maybe?
<cmatsuoka> mborzecki: checking that
<mborzecki> cmatsuoka: thanks
<mvo> pedronis, pstolowski sorry, had lunch indeed
<pstolowski> mvo: np, i think the solution is uncontroversial, we will brief you in a momentr
<Chipaca> pedronis: conflict is life
<mvo> pstolowski: \o/
<niemeyer> cmatsuoka: none or none at all seem similar
<cmatsuoka> niemeyer: ack
<niemeyer> cmatsuoka: But I'm still not sure I get what's going on there.. does adapter: full really mean no adapter?
<niemeyer> That seems pretty absurd
<cmatsuoka> From what I see there adapter: none means no adapter, "full" means command chain and "legacy" means wrappers
<cmatsuoka> but sergiusens is changing the default to command chain
<cmatsuoka> (I do agree that the choice of words isn't very clear)
<mborzecki> off to school
 * zyga is onto something!
<niemeyer> cmatsuoka: Yeah, the command chain isn't an adapter.. it's also under the control of the command-chain field itself, so there's no need to say anything else
<pedronis> cachio: we got this:  https://api.travis-ci.org/v3/job/529764900/log.txt
<pedronis> internal error: a core16 snap is installed, earlier test cleanup did not work
<sergiusens> niemeyer: as absurd as it feels now, it is was we concluded with kyrofa on https://forum.snapcraft.io/t/proposal-add-command-chain-to-apps-instead-of-generating-opaque-wrappers/6018 ... I'll see how we can get out of that, but it won't be as easy
<mvo> cachio: I looked at 6694 but cherry-picking it in isolation to release/2.39 shows conflicts on the first patch already so I think there is another PR before that that modified this part of the prepare.sh. do you remember which one that might be? did we had something similar before? we may need to cherry-pick both
<pedronis> mvo: I'll do the small fix pstolowski asked in your #6775
<mup> PR #6775: devicestate: make Remodel() return a state.Change <Created by mvo5> <https://github.com/snapcore/snapd/pull/6775>
<niemeyer> sergiusens: We discussed that when introducing bases
<niemeyer> sergiusens: We added the command chain concept at the same time so we would  not break compatibility in the future
<niemeyer> sergiusens: So I hope at least with a base, the default is no adapter.. is that the case?
<niemeyer> Small? Large?
<mvo> pedronis: thank you
<pedronis> mvo: done
<cachio> pedronis, checking
<mvo> pedronis: \o/
<cachio> pedronis, this is on master right?
<cachio> because that should be fixed
<pedronis> cachio: one of my PRs
<cachio> mvo, checking
<pedronis> but I had merge with master today I think
<cachio> pedronis, in that case I'll need to take a look, that should be fixed, which is the PR?
<pedronis> cachio: this one:  https://github.com/snapcore/snapd/pull/6828  (doesn't touch spread stuff)
<mup> PR #6828: many: use a fake assertion model in the device contexts for tests <Remodel :train:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/6828>
<cachio> pedronis, thanks
<pedronis> it's actually all unit tests changes I think
<ijohnson> hi folks, what's the status of building core18 snaps on travis (especially with respect to using build-snaps)? is launching a docker container still the thing to do on travis?
<cachio> mvo, this is giivng conflicts?  git cherry-pick 2e10db98657923a58fd7461586d150cfa97fc5b2
<cachio> mvo, I could cherry pick all of them
<mvo> cachio: this one looks fine, let me see if that is the one I was missing
<cachio> mvo, the problem with this PR is that I tried many alternative during time until the last one was choosend
<mvo> cachio: ohhhh, so only the last one is relevant? and that applies cleanly?
<mvo> cachio: in this case we are good :)
<cachio> mvo, no
<cachio> mvo, it is a mix
<mvo> zyga: a re-review of 6820 would be great, it already has a +0.9 from you :)
<cachio> mvo, let me check which are needed
<cachio> I'll give you a list
<mvo> cachio: thanks
<mvo> cachio: alternatively, feel free to branch off releae/2.39 and cherry-pick as needed
<mvo> cachio: it seems like we just have to live with some conflicts when merigng back but thats ok
<sergiusens> niemeyer: it is not, we can discuss the reasons next week; we did discuss this with bases, but at the end of last cycle, command-chain had not made the release cut in snapd ...
<zyga> mvo: looking
<zyga> mvo: +1
<cachio> pedronis, this seems to be new, I'll try to reproduce it locally, thanks for the log
<niemeyer> sergiusens: This is extremely unfortunate.. the whole point of command-chain was to avoid breaking compatibility in the future after bases were introduced
<niemeyer> sergiusens: What's your plan now to make them the default and adapters gone without breaking people?
<niemeyer> There's zero gain in command-chain if everybody has adapters
<niemeyer> :/
<sergiusens> niemeyer: I will bring a proposal to discuss with you for next week, migrating is something we already discussed with kyrofa
<pstolowski> mvo, pedronis hotplug mystery wrt core18 solved
<pstolowski> mvo, pedronis serial-port interface doesn't contain hotplug changes in 2.38.1. hotplug subsystem is triggered, just 0 interfaces support it. i have no idea how that happened that it didn't land in release brach :(
<ijohnson> sil2100: hey where is the "official" repository for pi gadgets these days? is it https://github.com/snapcore/pi-gadget ?
<mvo> pstolowski: so 2.39 fixes it?
<mvo> ijohnson: this looks correct
<ijohnson> mvo: cool thanks, we need to add the bt-serial interface back to the gadget there for uc18
<mvo> ijohnson: oh, that got lost? yeah, totally
 * mvo wonders why :(
<mvo> ijohnson: are you looking into this or sil2100 ?
<ijohnson> I was just wondering because the snapcore repo is more active but there's also github.com/CanonicalLtd/pi-gadget
<ijohnson> mvo: I'm actually looking into this because I wasn't able to use hotplug for the bluetooth adapter serial port, then learned that the gadget is supposed to include a slot for that and it's missing from the gadget on uc18 for some reason
<ijohnson> mvo: I was just going to file a PR to quick add it since it's 3 lines
<ijohnson> mvo: but I'm not sure which repo is watched for PR's :-)
<mvo> ijohnson: it should show up here :)
<pstolowski> mvo: 2.39 has the serial-port changes so yes, should work. i'm going to verify that
<mvo> ijohnson: mup should tell us
<mvo> pstolowski: it will work once the gagdet is fixed? or today?
<pedronis> pstolowski: did you look whether system snap setting up is correct overall?
<pstolowski> pedronis: yes, it looks ok (mapper says it's "snapd"). however i haven't checked seeding etc. i'm not sure how my manual testing affects it
<pedronis> pstolowski: ok, I'll try to look at that myself (I don't remember the details)
<sil2100> ijohnson: yes, that's the right repository
<sil2100> ijohnson: (snapcore)
<ijohnson> sil2100: great thanks for confirmation
<sil2100> ijohnson: I need to remove the CanonicalLtd ones, I created those when Foundations had no powers to manage the snapcore ones ;)
<ijohnson> ah I see that makes sense
<sil2100> (sorry for the confusion)
<ijohnson> np
<sil2100> ijohnson: just in case https://wiki.ubuntu.com/UbuntuCore/Development should be up-to-date with this things
<ijohnson> thanks sil1200 that's really helpful I wasn't aware of that page
<ogra> should be promoted on the forum and snapcraft docs
<ijohnson> +1
<ijohnson> also, question for mvo and pedronis if it's quick (if it's not quick/easy let me know and I'll start a forum post instead), how does snapd handle gadget slots for devices like a serial port that doesn't actually exist?
<ijohnson> the idea here being that we declare a serial port slot on a gadget for pi2 and pi3, but the serial port actually only exists on the pi3 and not on the pi2
<ogra> yeah, specifically with interfaces that define a device path in their interface declaration, is snapd checking the device actually exists before exposing the interface ?
<pedronis> ijohnson: I don't think we check/supress atm, we do trust the dgadget
<ogra> (thats what i would expect actually)
<pedronis> it could be considered a bug
<pedronis> but that's current behavior
<ogra> ouch
<ijohnson> ok, do you want me to start a conversation on the forum for this?
<pedronis> yes
<ijohnson> ack thanks
<cachio> mvo, change cherry picked to 2.39
<cachio> mvo, pushed to branch on snapcore, is it ok or I should push to my own copy and then create a PR?
<mvo> cachio: thanks! doing in a PR would be ideal but if travis is happy thats fine. thanks for doing this
<cachio> mvo, ok, sorry, lets see if it works
<mvo> cachio: aha, nice! it looks like it all merges back into master nicely, no conflict afaict. cool
<mvo> cachio: yeah, I wasn't clear in my original question/request so no worries
<cachio> mvo, I found another improvement to implement by reviewing the change :)
<pstolowski> mvo, pedronis: there is a bug though with core18 related to snapd transition and hotplug; serial-port hotplug slot doesn't pass sanitization because of "if slot.Snap.Type != snap.TypeOS && slot.Snap.Type != snap.TypeGadget" check
<pedronis> ah
<mvo> cachio: nice
<mvo> pstolowski: ha! good catch
<ijohnson> pedronis: posted as https://forum.snapcraft.io/t/gadget-slots-for-devices-that-dont-exist/11278
<pedronis> thx
<pedronis> pstolowski: does this come from the base declaration or so something else?
<pedronis> I thought we made core mean snapd or core at that level
 * cachio lunch
<pstolowski> pedronis: no, we have a few helpers (sanitizeSlotReservedForOSOrGadget, sanitizeSlotReservedForOS...) that various interfaces call in their sanitize methods, they check SlotInfo.Snap.Type
<pedronis> ah, I think we should drop those if I understand things correctly
<pedronis> that job is done by the base declaration now
<pstolowski> pedronis: hmm, interesting
<Chipaca> ok, I'm going offline, ttfn ttyl
<pstolowski> pedronis: right, slot-snap-type: in base decl does that
<pedronis> yes
<pedronis> I mean there might be reason to keep them
<pstolowski> pedronis: does it treat "snapd" special though?
<pedronis> yes
<pedronis> as I said there is code to make core mean (core or snapd)
<pedronis> you can find it in policy I think
<pedronis> we should maybe sanitize that at some point but is not trivial
<pedronis> I mean switch to something like system instead of core
<pstolowski> pedronis: i don't see a point in keeping these helpers anymore then
<pstolowski> or they should special-case "snapd" if we want to keep them for a while
<pedronis> pstolowski: that might be a smaller change?
<pedronis> for now
<pedronis> not sure
<pstolowski> pedronis: around 12 interface files call them, but then over 80 test files are affected too (because of common interface). the change should be pretty mechanical though, as long as base declarations for them are complete in that regard
<pstolowski> pedronis: for 2.39 though might be better to make a simple fix in the helpers, and then a followup which removes them all
<pedronis> pstolowski: yes
<pstolowski> ok, will do
<pstolowski> ok, i've a tentative fix, need to test it on pi3 though to see if that's the only issue, will do that tomorrow morning
<mup> PR snapd#6775 closed: devicestate: make Remodel() return a state.Change <Remodel :train:> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6775>
<mvo> 6776 is now a very simple review :)
<mup> PR snapcraft#2556 closed: cli: snapcraft promote <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2556>
<mup> PR snapd#6820 closed: snap-confine: improve error when running on a not /home homedir <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6820>
<mup> PR snapd#6840 closed: gadget: fix handling of positioning constrains for structures of MBR role <Gadget update> <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6840>
<mup> PR snapd#6828 closed: many: use a fake assertion model in the device contexts for tests <Remodel :train:> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6828>
<cachio> zyga, hey this is interesting https://paste.ubuntu.com/p/tG5MmWSH8n/
<cachio> base snaps mounted after snap remove
<cachio> in the tests
<mup> PR snapd#6841 opened: overlord: make changes conflict with remodel <Created by pedronis> <https://github.com/snapcore/snapd/pull/6841>
<cachio> zyga, I already fixed the issue
<mup> PR snapd#6842 opened: tests: fix how the base snap are deleted when there are multiple to deleted on reset <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6842>
<mup> PR snapcraft#2559 closed: manifest: expose snapcraft-started-at <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2559>
<mup> PR snapd#6843 opened: tests: avoid removing snaps which are cached to speed up the prepare on boards <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6843>
#snappy 2019-05-09
<mborzecki> morning
<zyga> Hey hey
<zyga> Will you have a moment to look at my reasoning today?
<zyga> As soon as the kids go to school we could have a quick call
<mborzecki> zyga: hey
<mborzecki> zyga: sure, ping me
<zyga> Also https://github.com/snapcore/snapd/pull/6796 is simple and I have more later :/
<mup> PR #6796: cmd/snap-update-ns: add no-op load/save current user profile logic <Created by zyga> <https://github.com/snapcore/snapd/pull/6796>
<zyga> ok, both kids are handled now
<zyga> mborzecki: https://meet.google.com/rug-kzid-ewz?authuser=0
<mborzecki> zyga: ok, let me get some coffee
<zyga> sure, thank you
<mup> PR snapd#6829 closed: devicestate: use deviceCtx in checkGadgetOrKernel <Remodel :train:> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6829>
<zyga> https://github.com/zyga/hello-cuda
<pedronis> mvo: hi, #6833 is the next one in the series, is actually the refactoring about creating models in tests I started Friday (that derailed me a bit)
<mup> PR #6833: many: introduce assertstest.SigningAccounts and AddMany test helpers <Remodel :train:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/6833>
<pedronis> mvo: I'm going to merge 6776, it will be turned into calls to remodel ctx methods soon
<mvo> pedronis: ok, I will check 6833 hopefully this morning
<pstolowski> morning
<mup> PR snapd#6776 closed: devicestate: set "new-model" on the remodel change <Remodel :train:> <Simple ð> <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6776>
<mvo> pedronis: about 6776> sounds good, will you work on the rmeodel ctx method transition or shall I?
<mvo> pedronis: having it will make the kernel-remodel PR much smaller, so thats nice
<zyga> mvo: we fixed it
<zyga> mvo: wooooot
<zyga> the bug is real, it's easy to fix and it's well understood now
<mvo> zyga: \o/
<mvo> zyga: is it a kernel bug?
<zyga> no, my bug :)
<zyga> but very elusive, you'll see soon
 * zyga is euphoric 
<zyga> I'll chop the fixes up and start sending it right away
<zyga> kenvandine: I've fixed a massive bug relating to layouts, content and magic-it-is-broken-bugs
<zyga> that explains a lot of things not working :D
<mvo> zyga: is this a 2.39.1?
<zyga> mvo: yes, we should
<zyga> it will help everyone on the desktop
<zyga> mvo: the fix is small
<zyga> so should be fine, I'll start preparing branches
<zyga> mvo: it's really this:
<zyga> when we mount tmpfs we don't set propagation so it stays private
<zyga> that's all :)
<zyga> this applies to layout tmpfs and mimic tmpfs
<zyga> mborzecki and me just spent last hour debugging it in a live pair programming session
<zyga> mborzecki thank you so much for helping :)
<mborzecki> mvo: hey
<mborzecki> zyga: not sure i helped much though :)
<zyga> mvo: so the nvidia state is not only great but also working reliably now :)
<mborzecki> pstolowski: hey to you too :)
<pstolowski> o/
<mvo> zyga: cool
<mvo> hey mborzecki and pstolowski
<mvo> zyga: can we spread test this somehow?
<zyga> Yes
<mvo> zyga: excellent
<pedronis> mvo: sorry, I will work on the remodel methods translation, my next task is actuall implementing brand store switch for real
<mvo> pedronis: excellent, thanks
<mvo> pedronis: just wanted to double check if I can help you in this specific task
<zyga> mvo: though with some loopholes because of per user mount namespaces
<zyga> mvo: but yes; we can test this
<mvo> pstolowski: I reviewed 6793 - do you think a unit test cmd_debug_timings_test.go for a followup would be hard? just something simple?
<mvo> zyga: cool!
<pedronis> mvo: we need a follow up anyway because of the discussion about having an artificial line to make the ensure bits more like the change bits
<pstolowski> mvo: yes, i was thinking about that, some rudimentgary unit tests would be good to have, will do in a followup
<pedronis> pstolowski: but with the branch we can gather data on the pis which would be great
<pstolowski> yes
<mvo> pstolowski: great! I +1 as not having this test is not a regression and we can fix in a followup :)
<pstolowski> ty
<zyga> Saviq: hey
<zyga> Saviq: I think I also fixed the bug that was affecting mir
<zyga> the one you asked me about a few weeks ago
<zyga> this is the bug of the month for me :)
 * zyga reports bugs to begin working on regression tests to begin chopping fixes into patches
<Saviq> zyga: got a bug#? :)
<zyga> Saviq: I'm reporting it now
<zyga> Saviq: but this is when you wanted to share mir backend drivers with mir and then share mir stack + backend driver to apps
<zyga> I know why this is broken now
<Saviq> Oh
<zyga> yeah :)
<zyga> it's getting fixed today
<Saviq> That'd be awesome :)
<zyga> this single bug explains LOADS of mysteriously incorrect behavior
<zyga> kenvandine: ^ this is the bug that was breaking themes and gnome platform snap and all kinds of "connected but not connected" bugs
<zyga> mvo: ^ you can see why I'm so happy now
<mvo> zyga: \o/
<pedronis> zyga: great, is it easy to add tests about it?
<zyga> pedronis: not every easy but 100% doable, the bug is extremely elusive and two of the components of the bug would make a simple spread test not catch it
<zyga> pedronis: I'm describing the bug in detail
<zyga> pedronis: and I know how to write a spread test for it
<zyga> pedronis: none of our current tests doing content or layout would capture it
<pedronis> ok, just wondering because we didn't catch it so far
<zyga> it's a tricky bastard :)
<pedronis> but good if we can have a spread test
<zyga> yes, that's 2nd step after reporting the bug :)
<zyga> write a test and show it fail :)
<pedronis> mvo: I'm going to cleanup managers_test.go a little bit as a drive-by, mostly ms -> s, and using testutil AddCleanup
<mvo> pedronis: \o/
<mup> PR snapd#6844 opened: interfaces: special-case "snapd" in sanitizeSlotReservedForOS* helpers <Simple ð> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6844>
<pstolowski> mvo, pedronis ^ so this fixes hotplug on core18+snapd, tested manually on pi3
<pstolowski> and i'll prep proper followup (touching 80+ files) as discussed yesterday
<mvo> pstolowski: nice
<mvo> pstolowski: this is also 2.39.1 I suppose?
<pstolowski> mvo: yes
<mvo> ta
<zyga> mborzecki, mvo, pedronis, Saviq: https://bugs.launchpad.net/snapd/+bug/1828354
<mup> Bug #1828354: mount event propagation on snapd-mounted tmpfs is incorrect <snapd:In Progress by zyga> <https://launchpad.net/bugs/1828354>
<zyga> I will start writing the spread test
<zyga> in case I get hit by a bus mborzecki knows how to fix it too :)
<mborzecki> hahah
<zyga> let me know if the bug description is unclear
<pstolowski> i'll also think about spread test for core18+snapd & hotplug, need to talk to Sergio about that
<Saviq> zyga: any news on https://bugs.launchpad.net/snapd/+bug/1819875 ?
<mup> Bug #1819875: base core16->core18 migration <snapd:In Progress by zyga> <https://launchpad.net/bugs/1819875>
<zyga> Saviq: it's stalled, I know what to do, will attack it after Lyon
<zyga> Saviq: the initial patch was ANACked, I started working on v2 and have close-but-not-quite code for that
<zyga> mborzecki, mvo: I also reported https://bugs.launchpad.net/snapd/+bug/1828357
<mup> Bug #1828357: snap-update-ns incorrectly sorts mount profile entries <snapd:New> <https://launchpad.net/bugs/1828357>
<zyga> Saviq: there are several more bugs in core->core18 migration
<zyga> Saviq: one is that snapd tools go stale
<zyga> Saviq: there are several other bugs affecting core18, I don't think they are all reported
<Saviq> so "not yet" :)
<zyga> no, apart from Lyon-driven work it is close to the top of my queue
<zyga> (no as in: "no, not yet")
<pstolowski> mborzecki: replied to your comment in https://github.com/snapcore/snapd/pull/6793 ; can you re-review?
<mup> PR #6793: cmd/snap: support for --ensure argument for snap debug timings <Created by stolowski> <https://github.com/snapcore/snapd/pull/6793>
<mborzecki> pstolowski: thanks, it was more like an open question, nothing to be done in that PR anyway
<mvo> pedronis: should I add switching gadgets (with the caveat that we cannot do asset upadates yet) or do you think thats premature?
<pedronis> mvo: that is more delicate, we really need to do the right thing with GadgetInfo
<pedronis> it's used much more than KernelInfo
 * mvo nods
<mvo> a second review of 6835 would be great - its small
<pedronis> mborzecki: I tried to answer your question, bit confused by the 2nd because that's the central point of the PR, though it might be sutble
<mvo> 6751 has two +1 but I added the unit test - so a second review from someone who is not me would be great
<mvo> its pretty small and should be simple to review
<pedronis> mborzecki: I changed the description of 6822, made that should makes thing clear. It also go outdated at some point.
<pedronis> s/made/maybe/
<pedronis> mvo: I can look in a little bit
<mborzecki> pedronis: what i meant in the 2nd question is cosmetic mostly, whether to embed *DeviceManger or have it as a field like `manager *DeviceManger`
<pedronis> mborzecki: ah, I didn't understand that way
<mborzecki> pedronis: sorry, should have made it more clear in the comment
<pedronis> mborzecki: no, you are right, the wrapper implements all the interface methods
<pedronis> so it could be a field
<pedronis> this changed a bit over the history of the branch
<pedronis> or I could remove .DeviceManager
<pedronis> and keep it this way
<pedronis> but as it is is all a bit silly
<mborzecki> pedronis: i mean it's not a problem, we could clean it up later on, or keep it like this, either way the code works
<Chipaca> pstolowski: o/
<pedronis> mborzecki: yea, for context,  at some point DeviceManager had Device
<pedronis> but now that is hidden
<pstolowski> hey Chipaca
<Chipaca> pstolowski: hiya. I've got a question about hooks :-)
 * pstolowski is hiding
<pstolowski> shoot
<Chipaca> pstolowski: I'm getting 'cannot find hook' when trying to install (of a hook i've added), from snap-exec, but in snap-exec I print info.Hooks and the hook is right there, but the snap-exec does not seem to be the one from /usr/lib/snapd â¦ is it always from core or sth?
<pstolowski> Chipaca: what hook?
<Chipaca> pstolowski: I've just answered myself by doing a bind-mount, and yes it's the one from core
<Chipaca> (i got a different panic now \o/ )
<Chipaca> pstolowski: check-health
<pstolowski> Chipaca: you'll need to whitelist a new hook in supportedHooks (and possibly in one other place, but not sure from top of my head). but you probably already found that out
<Chipaca> pstolowski: yep :-)
<Chipaca> pstolowski: I just got the whole thing working \o/
<pstolowski> nice! \o/
<mup> PR snapd#6796 closed: cmd/snap-update-ns: add no-op load/save current user profile logic <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6796>
<Chipaca> pedronis: can we talk about storage for a bit?
<Chipaca> pedronis: actually, i'll just write out my question and you answer when you have time
<Chipaca> pedronis: some decisions need to be done on 'edge', ie when transitioning from good to bad or vice versa, and I wonder if what we actually want is a log of all the runs (or the last N)
<mup> PR snapd#6845 opened: cmd/snap-update-ns: move apply{Profile,{User,System}Fstab} to same file <Created by zyga> <https://github.com/snapcore/snapd/pull/6845>
<Chipaca> pedronis: so the question is: should I make it an in-state thing that keeps the current result and the previous one, or the current result and the previous status, or should it be on disk with a log of everything?
<zyga> pstolowski: asked a question in https://github.com/snapcore/snapd/pull/6844
<mup> PR #6844: interfaces: special-case "snapd" in sanitizeSlotReservedForOS* helpers <Simple ð> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6844>
<Chipaca> pedronis: are actions going to be taken in-hook-handler, looking at current and previous result only, or are they going to be run from outside and look at all history, or...?
<pedronis> Chipaca: which decisions need to be made on edge ? I don't remeber that
<Chipaca> pedronis: when it was ok but suddenly isn't
<Chipaca> pedronis: warning the user? alerting the backend?
<Chipaca> not sure (it's not part of this round of work)
<Chipaca> but there was some action we wanted to do when a snap had been fine and then started being broken
<pedronis> we want to check more often when is broken
<pedronis> but that itsn't about the edge
<pedronis> we do need to know what the status was before a refresh and after
<pedronis> Chipaca: atm I would expect to take "actions" from check-rerefresh
<pedronis> Chipaca: I mean, we always discussed needing to run the hook both at the start and during a refresh
<Chipaca> pedronis: and then take actions based on the difference, right?
<pedronis> possibly yes
<Chipaca> ie bad->good vs good->bad
<pedronis> but that info could be kept on the change/task in the change
<pedronis> anyway if you think we should keep the last two different values
<pedronis> that's fine
<pedronis> I would put this in the state
<Chipaca> ok
<pedronis> Chipaca: we need to remember for which revision they are though? though the idea is that health itself is not for a revision
<zyga> brb, coffee
<pedronis> Chipaca: I mean, is not clear to me whether we should just stick the last value in the change , or we keep always two, but we haven't dug deep into all the things we might want to do with this
<Chipaca> pedronis: I'll make it a map[instance]HealthState; we can always have HealthState have a Previous HealthState
<Chipaca> pedronis: I'll add Revision to HealthState: like the timestamp, it's not that the health is 'for' a timestamp or revision, but that when the health was this, these were the timestamp and revision
<Chipaca> will help with debugging / auditing / developing at the least
<pedronis> yes
<Chipaca> pedronis: initial PR will just run the hook at the end of install
<Chipaca> fwiw
<pedronis> yea, that's fine
<pedronis> Chipaca: you mean install/refresh, or only install?
<Chipaca> pedronis: doInstall :-) install/refresh/try/revert
<pedronis> ok
<pstolowski> zyga: replied
<zyga> pstolowski: thanks, looking
<zyga> pstolowski: +1
<pstolowski> zyga: ty
<pstolowski> zyga: i'm preparing a followup to remove these helpers from all interfaces. that means reservedForOS in common.go will go away
<zyga> pstolowski: why?
<pstolowski> zyga: because base declaration do the same
<zyga> pstolowski: but base declaration is *not* considered when doing snap install --dangerous
<zyga> or am I mistaken?
<pstolowski> zyga: oh
<zyga> it will give people false impressions when developing snaps
<zyga> perhaps we should run the base policy checker but just print a warning on install when --dangerous is used
<pstolowski> zyga: fair point if this is the case
<zyga> then I think this is sensible
<zyga> and far less code too
<mvo> pedronis: do you want to tweak 6822 further or can it go in ? it has two +1 but there is this discussion about initialRegistrationContext
<mup> PR snapd#6846 opened: cmd/snap-confine: unshare per-user mount ns once <Created by zyga> <https://github.com/snapcore/snapd/pull/6846>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6846
<mup> PR #6846: cmd/snap-confine: unshare per-user mount ns once <Created by zyga> <https://github.com/snapcore/snapd/pull/6846>
<pedronis> mvo: I can change it a bit in a follow up
<pedronis> it can go in
<mup> PR snapd#6822 closed: overlord/devicestate: introduce registrationContext <Remodel :train:> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6822>
<Chipaca> pstolowski: why is hookstate.Context's SnapRevision "unset", when the revision is something like -4?
<mvo> pedronis: it can I think - I'm inclined to merge 6833 as well or do you think this needs further reviews (all tests/test-helpers)
<Chipaca> ooohhh hooksetup
 * Chipaca looks into it
<pedronis> we never set the revision I think
<pedronis> actually
<pedronis> there was a lot of back and forth on that
<pstolowski> Chipaca: this predates the time i started working on snapd.. i think Gustavo and Kyle worked on this, i don't know the background
<pedronis> mvo: I don't know about 6833 , it's all tests but it's big
<pedronis> also maybe people have opinions on names
<pedronis> I don't know
<pedronis> pstolowski: I answered your question in 6822
<pstolowski> ty
<mvo> pedronis: I think its a thing of beauty so maybe someone more reviews are actually good :)
<pstolowski> mvo: updated #6844
<mup> PR #6844: interfaces: special-case "snapd" in sanitizeSlotReservedForOS* helpers <Simple ð> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6844>
<mvo> pstolowski: \o/
<zyga> mvo: replied on that unshare bug
<zyga> let me know if you want me to pursue the test, I personally think it's not worth it
<mup> Bug #1828374 opened: Unable to install qabro <Snappy:New> <https://launchpad.net/bugs/1828374>
<mvo> zyga: thank you
<zyga> mvo: we could write a test that would use trace but it would be super tricky because this code only runs when *not* root but we'd need to run snap-confine via sudo + strace and then somehow drop back to user while running under strace already
<zyga> CE has reported a bug related to seeding
<zyga> https://bugs.launchpad.net/snappy/+bug/1828374
<mup> Bug #1828374: Unable to install qabro <Snappy:New> <https://launchpad.net/bugs/1828374>
<zyga> there's one change, seeding, it is stuck for two days
<zyga> the Doing task is Doing 2 days ago, at 04:16 EDT - Ensure prerequisites for "gnome-calculator" are available
<zyga> is this the ordering bug
<mvo> zyga: hm,hm and there is nothing else with propagation (or lakc thereof) that is easy(ish) to observe?
<zyga> where bases must be before snaps?
<zyga> mvo: correct
<mvo> zyga: is this 2.39 material?
<zyga> mvo: yes, but only because I would like to test this together with the 2nd bug fix and not without
<zyga> mvo: and if it passes and nobody spots any hole in reviews it is a clear bug to get rid of
<mvo> zyga: ok, we should probably have a quick call on it if it goes into 2.39 without some sort of test
<zyga> mvo: what would we discuss?
<mvo> zyga: a bit later though, I will wait for the second PR
<zyga> mvo: ok
<zyga> mvo: I can write the allocation test
<mvo> zyga: not sure thats worth it
<zyga> it'd be a bit fugly but if you strognly one one
<mvo> zyga: maybe I'm too cautious
<pedronis> zyga: yes, that seems and ordering bug
<pedronis> or missing base
<zyga> pedronis: is the ordering documented somewhere that I can point CE to?
<mvo> zyga: anyway, please focus on the second PR and then we can talk a bit more
<zyga> mvo: ok
<zyga> doing that now
<mvo> zyga: thank you!
<pedronis> zyga: we really shouldn't have ordering bugs actually, but missing stuff is an issue
<zyga> pedronis: I agree, I would add that snapd should bail if it detects a missing base and not just stall for dayts
<pedronis> the more focuses we are on the big things the more is likely we can do something about the small ones
<zyga> pedronis: yeah, agreed
<niemeyer> Mornings
<niemeyer> mvo, pedronis_: Do you have a moment for a quick call?
<mvo> niemeyer: yes, can be there in 1min
<niemeyer> Sweet
<niemeyer> Let's use the standup link
<Chipaca> pstolowski: question about something I'm finding hard to follow: I'm getting my hook run even for snaps that don't have the hook. Where does the decision not to run hooks that aren't present happen? the (to me) obvious place, hookmgr's runHook, knows there isn't a hook and carries on
<Chipaca> bah
<Chipaca> it's not the (non-existent) hook that's run, it's the handler
<Chipaca> the Done() thing
<Chipaca> pstolowski: so i change my question: how can the Done handler know whether the hook was run?
<Chipaca> pstolowski: or, why doesn't runHook just return nil when it knows there isn't a hook to run?
<pstolowski> Chipaca: it seems it's always called even if hook doesn't exist. and the only case when it's not run is when error occurs and IgnoreError is not set
<zyga> 	Failed for "golang.org/x/crypto/cast5" (failed to clone repo): exit status 128
<pstolowski> Chipaca: i think we have never relied on Done() so far
<mborzecki> hmm ubuntu-image is full of surprises
<mborzecki> calculated = ceil(farthest_offset / 1024 + 17) * 1024
<Chipaca> pstolowski: grmbl
<mborzecki> that's how image size is calculated befire it's actually built
<zyga> there's more from godbus :/
<Chipaca> pedronis: looking at blame maybe i should've asked you the above :-) or maybe kyrofa
<pstolowski> Chipaca: again.. this is old code, almost untouched since initial impl
<pstolowski> Chipaca: what you're saying sounds reasonable to do imho
<mborzecki> and a TODO note too: # TODO: Hard-codes last 34 512-byte sectors for backup GPT, empirically derived from sgdisk behavior.
 * pstolowski lunch
 * zyga is hungry too
<kenvandine> zyga: great!
 * kenvandine high fives zyga 
<zyga> kenvandine: I'm totally crazy happy about this bug finally coming out of the shadows :)
<zyga> kenvandine: this is https://bugs.launchpad.net/snapd/+bug/1828354 if you want to track
<mup> Bug #1828354: mount event propagation on snapd-mounted tmpfs is incorrect <snapd:In Progress by zyga> <https://launchpad.net/bugs/1828354>
<zyga> I'll fix it today
<zyga> but first, I need to take the dog out, he's looking at me and asks for it :)
<mup> PR snapd#6845 closed: cmd/snap-update-ns: move apply{Profile,{User,System}Fstab} to same file <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6845>
<mup> PR snapd#6847 opened: cmd/snap-update-ns: make apply{User,System}Fstab identical <Created by zyga> <https://github.com/snapcore/snapd/pull/6847>
<mup> PR snapd#6848 opened: First pass at healthstate (no tests yet) <Created by chipaca> <https://github.com/snapcore/snapd/pull/6848>
<Chipaca> pedronis: ^^ draft PR (working on adding tests)
<Chipaca> pedronis: will probably drop the IsCtrl thing until later, as it's not essential and clutters the pr
<pedronis> Chipaca: thx
<Chipaca> pedronis: but thought you might want an early look
<mborzecki> do we have some code already that escapes runes into \x.. hex encoding like systemd-escape?
<pedronis> Chipaca: is SnapRevision actually set? doesn't need to be set in CheckHealth ?
<Chipaca> mborzecki: systemd.Escape ?
<Chipaca> mborzecki: systemd.EscapeUnitNamePath
<Chipaca> pedronis: it is set
<mborzecki> Chipaca: thanks!
<Chipaca> pedronis: it's always "unset" for local revisions
<Chipaca> pedronis: it is set for store revisions
<Chipaca> pedronis: so that's probably good enough
<pedronis> Chipaca: ok, bit puzzled by that
<Chipaca> me three
<Chipaca> :)
<pedronis> I don't remember it being that way
<mvo> woah, this "draft" feature is cool
<Chipaca> pedronis: you can try it locally, becaues Done is always called so health is always set to something
 * mvo hugs Chipaca for learning something new
<pedronis> Chipaca: the other question, not immediate, if it will always want to write directly to the health state, or sometimes we'll need to keep the health pending somewhere
 * Chipaca hugs mvo for the attitude
<pedronis> but we should have ways to add that indirection if needed
<Chipaca> pedronis: yep
<pedronis> mvo: 6751 looks good but I have a comment about lack of comments :)
<mvo> pedronis: thanks, will fix
<ogra> Download snap "motion-ogra" (16) from channel "edge"                                                                                       0% 17.2kB/s 63.3m
<ogra> hmpf !
<mborzecki> off to pick up the kids
<zyga> back from lunch and walk
<zyga> mvo: can you revise your review on https://github.com/snapcore/snapd/pull/6751
<mup> PR #6751: overlord/snapstate: perform hard refresh check <Created by zyga> <https://github.com/snapcore/snapd/pull/6751>
<cwayne> ogra: heya! Youve got a pi 3b+ yeah?
<mvo> zyga: sure, checking
<zyga> mvo: I think the PR needs a comment
<zyga> but perhaps one can be added via github directly
<ogra> cwayne, who hasnt ? (its the default you get since 1.5y if you order one :P )
<mvo> zyga: yeah, I have a meeting now will see when I can add it
<zyga> mvo: I can add the comment, just need your review change
<mvo> zyga: +1
<zyga> thanks!
<cwayne> ogra: :) was just curious if you've seen any wifi issues with the latest core/snapd
<ogra> cwayne, not on core 16 and 18 is still too immature for daily use IMHO
<cwayne> ogra: with every snap on stable? Just curious as we're seeing wifi issues on ours in the lab but only one of them
<ogra> cwayne, with core and kernel on stable (i mostly use my own gadgets for my in-house images that run sensible stuff)
<cwayne> Hm ok so it's not a kernel issue then, that's good
<cwayne> I think our pi may just be flaky
<ogra> or there is some freequency distortionn/noise ... the wlan isnt very good through walls either
<cwayne> Doesn't go through any walls iirc, but could be lots of things
<cwayne> Just weird that it happened so suddenly
<mup> PR snapd#6798 closed: gadget: introduce checkers for sanitizing structure updates <Gadget update> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6798>
<mup> PR snapd#6849 opened: many: introduce a gadget helper for locating device matching given structure <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6849>
<mup> PR snapd#6850 opened: gadget: add volume level update checks <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6850>
<pedronis> a 2nd review for 6833 , it's a tests refactor
<pedronis> would be great
<popey_> where should I file a crasher bug against the snap command line tool?
<Chipaca> popey_: oooh
<Chipaca> popey_: tell me more
<popey_> https://paste.ubuntu.com/p/zZwqpZ2N2w/
<popey_> snap info qtencodegui
<popey_> run that
<Chipaca> popey_: https://bugs.launchpad.net/snapd/+filebug?field.title=snapd+went+boom
<popey_> :)
<Chipaca> s/snapd\+/snap+/ but that
<Chipaca> fffantastic
<popey_> https://bugs.launchpad.net/snapd/+bug/1828425
<mup> Bug #1828425: snap went boom <snapd:New> <https://launchpad.net/bugs/1828425>
<Chipaca> WTheck
<Chipaca> grahrrr
 * Chipaca hates self
<roadmr> great bug description :)
<zyga> dinner
<Chipaca> mvo: we've got a snap crasher, and a fix for it coming up, what should i target it to?
<Chipaca> mvo: (this is not a regression)
<Chipaca> mvo: (this is not a drill either)
<mvo> Chipaca: 2.39
<mvo> Chipaca: we need to do  a 2.39.1
<Chipaca> mvo: tagging is enough?
<mvo> Chipaca: yes
<Chipaca> k
<Chipaca> mvo: thanks
<mup> PR snapd#6851 opened: cmd/snap: mangle descriptions that have indent > terminal width <Simple ð> <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6851>
<Chipaca> mvo: popey_: ^^ tadaa
<Chipaca> popey_: and before you go "i set my terminal to 1000 columns wide and it still crashes", snap caps the terminal width to ~100 so paragraphs are legible
<kenvandine> jdstrand: if i want USN notifications to be sent to a list for a bunch of snaps, do i have to add the list as a collaborator?
 * kenvandine hopes not
<jdstrand> kenvandine: no. just tell me and I'll adjust
<jdstrand> kenvandine: it needs to be an open list
<kenvandine> cool
<jdstrand> otherwise you'll need to moderate the emails
<mup> PR snapd#6847 closed: cmd/snap-update-ns: make apply{User,System}Fstab identical <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6847>
<cachio> Chipaca, niemeyer hey, when you have time, could you please take a look to those PRs on spread project https://github.com/snapcore/spread/pull/70 and https://github.com/snapcore/spread/pull/75 ?
<cachio> thanks
<mup> PR spread#70: Close ssh connection when reboot is stuck <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/70>
<mup> PR spread#75: Make spread tests for spread project run on google backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/75>
<mup> PR snapd#6852 opened: cmd/snap-update-ns: merge apply functions <Created by zyga> <https://github.com/snapcore/snapd/pull/6852>
<Chipaca> cachio: yes
<mup> PR snapd#6844 closed: interfaces: special-case "snapd" in sanitizeSlotReservedForOS* helpers <Simple ð> <Squash-merge> <â  Critical> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6844>
<mup> PR snapd#6853 opened: interfaces: special-case "snapd" in sanitizeSlotReservedForOS* helperâ¦ <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6853>
<pedronis> mvo: going to merge 6833 at this point, happy to get later feedback
<zyga> thanks for all the review guys! that's the best day for this feature for a looooong time
<mup> PR snapd#6833 closed: many: introduce assertstest.SigningAccounts and AddMany test helpers <Remodel :train:> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6833>
<mvo> pedronis: +1
<pedronis> now the next one is real code and it has turned out bigger than I expected (mostly because of unit tests), I might have to split it, #6838
<mup> PR #6838: overlord/devicestate: introduce remodel kinds and contexts <Remodel :train:> <â Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/6838>
<zyga> mvo: I need to break and run an errand but I experimented a bit more and I have good feeling about the propagation bug tests
<zyga> mvo: perhaps tomorrow we can attempt to do .1 and put it into beta?
<zyga> mvo: though not sure if that's super required
 * cachio lunch
<Chipaca> cachio: what about spread#73?
<mvo> zyga: I will see what I can do
<mup> PR spread#73: Run tests on travis <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/73>
<popey_> Chipaca: i actually was running snap info in a terminal, so no idea what it thinks the terminal width is
<zyga> mvo: let's talk tomorrow
<zyga> mvo: thank you for everything today!
<popey_> s/terminal/script/
<mvo> zyga: thank you!
<Chipaca> popey_: https://imgflip.com/i/30jols
<popey_> that'll do :)
<zyga> Chipaca: buhahaha, that's too funny :)
<Chipaca> zyga: :)
<Chipaca> zyga: "A bug reference, if one exists, would be nice to add as a comment." i'm not sure what you mean, given the link in the description
<zyga> I mean the comment :)
<zyga> the // giving up one
<Chipaca> zyga: ohhh
<Chipaca> zyga: I'll add it if I need to bump spread
<Chipaca> :)
<zyga> +1
<Chipaca> OTOH it's only just started
<Chipaca> i could cancel the whole thing
 * Chipaca goes for it
<mup> PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mup> PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<Chipaca> zyga: like so?
<zyga> very nice
<zyga> thank you!
<Chipaca> huzzah
<kenvandine> Chipaca: some snaps with contact urls set aren't showing them in the output of snap info
<kenvandine> Chipaca: any idea why?
<Chipaca> kenvandine: impossible :-p
<kenvandine> :)
<kenvandine> Chipaca: look at libreoffice and gnome-system-monitor
<kenvandine> the latter doesn't have contact at all
<Chipaca> kenvandine: it does if you don't have it installed
<kenvandine> oh
<kenvandine> that seems like a bug :)
<Chipaca> contact:   https://bugs.launchpad.net/ubuntu/+source/gnome-system-monitor/+bugs?field.tag=snap
<Chipaca> ^ that's what i get
<kenvandine> ok, that's what it should be
<kenvandine> weird you don't have it installed, that's a seeded snap :)
<Chipaca> kenvandine: so, the snap does _not_ have contact info
<Chipaca> kenvandine: I'm on 16.04
<kenvandine> ah
<Chipaca> kenvandine: some fields, if the store has edited versions, get pulled down
<Chipaca> kenvandine: contact is not one of those fields
<Chipaca> kenvandine: that is
<Chipaca> kenvandine: some fields are per snap, some fields are per revision
<Chipaca> kenvandine: if they're per snap, they should be fetched from the store on install, etc, like description does
<Chipaca> today only title, summary, and description get this treatment
<kenvandine> i think contact would be very interesting info for installed snaps
<kenvandine> makes it easier to file bugs for snaps you have installed
 * kenvandine files bug
<Chipaca> kenvandine: if the snap has contact info it will be shown
<Chipaca> hmmm
<Chipaca> OTOH sideinfo has contact
<Chipaca> hmm
<Chipaca> something's wrong
<Chipaca> kenvandine: maybe i lied, let me test this
<popey_> :)
<kenvandine> :)
<Chipaca> sudo jq '.data.snaps."gnome-system-monitor".sequence[0].contact' /var/lib/snapd/state.json
<Chipaca> kenvandine: ^ what does that say?
<kenvandine> Chipaca: null
<kenvandine> could it be that when i installed the snap there wasn't contact info?
<Chipaca> kenvandine: and if you change the [0] to []| ?
<kenvandine> null null null
<Chipaca> kenvandine: so, i was wrong, and we do fetch the contact on install / refresh
<Chipaca> kenvandine: (i was confused because i'm easily confused)
<kenvandine> :)
<Chipaca> kenvandine: if you were to remove it and reinstall it you should get your contact info (in both info and in that jq)
 * Chipaca tries to remember if doing it with a cached snap will still ping the store, and hopes it does
<kenvandine> Chipaca: indeed that works
<Chipaca> k
<kenvandine> should it work after refresh too?
<Chipaca> kenvandine: after a refresh that fetches a new snap, yes
<kenvandine> ok
<Chipaca> kenvandine: it should also work after a refresh that doesn't refresh the snap, but that's unplanned work
<Chipaca> (the store does actually tell us all this info just to say "no refreshes dude")
<kenvandine> so basically this won't really help users until i publish updates for all the snaps
<Chipaca> (granted it tells us because we ask for it)
<kenvandine> although, i've refreshed most of my snaps since updating the contact fields
<kenvandine> refreshed == rebuilt
<kenvandine> so shouldn't be too bad
<Chipaca> kenvandine: yes (and a bug about refreshing the fields on refresh would be useful)
<Chipaca> not that there's any hope of slipping this in before 2040
<Chipaca> or is that 20.4
<Chipaca> :)
<kenvandine> 21 years, not bad :)
 * Chipaca meant 20.04 but Â¯\_(ã)_/Â¯ 
<Chipaca> kenvandine: I might even have saved up enough for a deposit on a house by then! woo
<kenvandine> :)
<Chipaca> anyway, HTH, sorry it couldn't be entirely good news
<kenvandine> no worries
<Chipaca> kenvandine: could you add "double-check contact fields" to the getting-snaps-ready-for-seeding checklist?
<kenvandine> in a bug report?
<Chipaca> kenvandine: I have no idea -- this was a mythical checklist i imagined was used to vet snaps before they landed on the iso
<kenvandine> lol
<kenvandine> ok
<kenvandine> i see what you mena
<kenvandine> mean
<kenvandine> this time i was confused
<Chipaca> oh no
<Chipaca> it's contagious
<Chipaca> run
<kenvandine> :)
<zyga> oh
<zyga> pedronis: is this expected? https://www.irccloud.com/pastebin/KcYvl1zT/
<zyga> there's some more odd stuff
<zyga> - Download snap "snapd" (3028) from channel "stable" (Get https://api.snapcraft.io/api/v1/snaps/download/PMrrV4ml8uWuEUDBT8dSGnKUYbevVhc4_3028.snap: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "Let's Encrypt Authority X3"))
<pedronis> that's SSL issues
<pedronis> worth poking the store people if it persists
<zyga> OK
<zyga> Pharaoh_Atem: hey, did you recently fix this https://bugzilla.redhat.com/show_bug.cgi?id=1707422 ?
<Chipaca> cachio: is snapd#6541 still a thing we want?
<mup> PR #6541: tests: change how xdg-desktop-portal is prepared and restored for desktop-portal-* tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6541>
<cachio> Chipaca, yes, I am testing a fic for the document-portal-activation test
<cachio> because it is failing since I am installing the xdg-desktop-portal package on the prepare
<cachio> I'll push a fix today
<Chipaca> cachio: k
<mup> PR snapd#6852 closed: cmd/snap-update-ns: merge apply functions <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6852>
<mup> PR snapd#6854 opened: cmd/snap-update-ns: rename applyFstab to executeMountProfileUpdate <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6854>
<mup> PR snapd#6842 closed: tests: fix how the base snap are deleted when there are multiple to deleted on reset <Simple ð> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6842>
<mup> PR snapcraft#2561 opened: Promote branches fix <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2561>
<zyga> jdstrand: hey, can you please look at (3 line) https://github.com/snapcore/snapd/pull/6846
<mup> PR #6846: cmd/snap-confine: unshare per-user mount ns once <Bug> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6846>
<zyga> jdstrand: oh, and perhaps if you are curious, we've solved the issue I showed to you that other evening
<zyga> jdstrand: it's all described here https://bugs.launchpad.net/snapd/+bug/1828354
<zyga> jdstrand: I'm working on fixing that with tests for all the variants now
<mup> Bug #1828354: mount event propagation on snapd-mounted tmpfs is incorrect <snapd:In Progress by zyga> <https://launchpad.net/bugs/1828354>
<jdstrand> zyga: nice
<mup> PR snapd#6855 opened: overlord: implement store switch remodeling  <Created by pedronis> <https://github.com/snapcore/snapd/pull/6855>
#snappy 2019-05-10
<mborzecki> morning
<zyga> Hi
<zyga> Sooooo sleepy
<zyga> Hey mvo
<mvo> hey zyga
<mvo> zyga: if you adress the feedback from jamie in 6846, could you please force push so that I can cherry pick more easily?
<mup> PR snapd#6843 closed: tests: avoid removing snaps which are cached to speed up the prepare on boards <Simple ð> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6843>
<mborzecki> zyga: mvo: hey
<mvo> hey mborzecki
<mup> PR snapd#6831 closed: tests: retry govendor sync <Simple ð> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6831>
<zyga> low hanging fruit: bump the delta tag please
<zyga> https://github.com/snapcore/snapd/pull/6855 is a bit big
<mup> PR #6855: overlord: implement store switch remodeling  <Remodel :train:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/6855>
<mup> PR snapd#6846 closed: cmd/snap-confine: unshare per-user mount ns once <Bug> <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6846>
<mvo> zyga: I cherry picked 6846
<zyga> Thank you
<zyga> I'm still working on the main dish
<pstolowski> morning
<zyga> hey pawel
<pedronis> mvo: hi, the PR to do store switch remodeling is up, some TODO related to conflicts, but otherwise is all there. Re-reg is a bit more complicated but not complex, needs the dedicated context and a new task kind.
<pedronis> PRs are a bit big though (espcially tests) might need splitting.
<pstolowski> mvo: hey, thanks for moving our 1-1!
<mvo> pstolowski: is that time ok? I'm relatively flexible thanks to mborzecki who also moved the meeting :)
<pstolowski> mvo: yes, it's perfect!
<mup> PR snapd#6854 closed: cmd/snap-update-ns: rename applyFstab to executeMountProfileUpdate <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6854>
<mvo> we are below 60 again!
<mup> PR snapd#6851 closed: cmd/snap: mangle descriptions that have indent > terminal width <Simple ð> <â  Critical> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6851>
<Chipaca> moin moin
<pstolowski> hey Chipaca
<mup> PR snapd#6856 opened: cmd/snap-update-ns: add tests for executeMountProfileUpdate <Created by zyga> <https://github.com/snapcore/snapd/pull/6856>
<mup> PR snapd#6850 closed: gadget: add volume level update checks <Gadget update> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6850>
<mborzecki> another one lands :)
<mvo> !!!
<mup> PR snapd#6857 opened: gadget: record sector size in positioned volume <Gadget update> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6857>
<mborzecki> and one more up /o\
<mborzecki> off to school, back in a bit
<zyga> mborzecki: thank you
<zyga> man, I needed this coffee
<Chipaca> pedronis: you around?
<pedronis> Chipaca: yes
<Chipaca> pedronis: wrt health-checks, is there anything you'd rather see up in a pr next?
<pedronis> Chipaca: did you push one already?
<Chipaca> pedronis: just the draft one
<Chipaca> pedronis: working on the tests still
<pedronis> Chipaca: is it too big?
<Chipaca> pedronis: no i don't think so
<pedronis> I'm not sure I understand the question
<Chipaca> pedronis: the pr that is up, that i expect to finish today while you're travelling, covers only a small portion of the feature
<Chipaca> pedronis: so, what should i work on once that is 'done' (code complete)?
<pedronis> Chipaca: the PR runs the hook and let the hook set the health, right?
<Chipaca> pedronis: yes, post-refresh
<Chipaca> or post-install
<Chipaca> i mean it doesn't do the pre-refresh nor the on-demand, nor the info, nor the list
<pedronis> I think the next bit is snap info
<Chipaca> okie doke
<pedronis> now that I understand the question
<Chipaca> :)
 * Chipaca is always very clear
<Chipaca> pedronis: and after that? (being optimistic here)
<pedronis> regular running of the hook?
<pedronis> and then the pre refresh one we need to think a bit, we can run it but we wouldn't do much with, would we?
<pedronis> so it well might be on-demand
<pedronis> I expect on-demand to be a bit complicated, to do the UX as we discussed it
<pedronis> because we don't have anything quite like that
<pedronis> atm
<zyga> oh
<zyga> what are you discussing? it sounds curious
<pedronis> health checks
<pedronis> or you mean the last bit in particular?
<pedronis> the last bit is about snap health and returning info to the user for each snap as soon as it is available
<zyga> about on-demand things, I was wondering if there's some new functionality in hooks that is planned
<pedronis> don't think is about hooks
<pedronis> it's more about how we return results
<pedronis> from API
<pedronis> but it depends exactly how we implement it
<pedronis> Chipaca: so, info, regular,  on-demand
<Chipaca> pedronis: regular as in on-a-timer?
<pedronis> Chipaca: that part of the spec that says we run them (probably triggered from ensure) at given interval,
<pedronis> more often if unhealthy
<Chipaca> yep
<Chipaca> ok
<pedronis> there are some fun issues there to, but we can have a general sketch of that before digging
<pedronis> *there too
<mup> PR snapd#6858 opened: cmd/snap: unit tests for debug timings <Created by stolowski> <https://github.com/snapcore/snapd/pull/6858>
<zyga> mborzecki: not sure if intersects with your work
<zyga> running snapd a while prints this a loooot
<zyga> maj 10 11:00:53 yantra snapd[57785]: kernel_os.go:198: cannot get boot settings: cannot determine bootloader
<Chipaca> pstolowski: "(and optionally the)" because code is optional!
<Chipaca> :-p
<pstolowski> :)
 * pedronis starts early travel to Lyon
<pedronis> have great day and weekend!
<zyga> pedronis: see you soon :)
<zyga> pedronis: I'm going through geneva
<zyga> pedronis: perhaps we might even share a train ride
<pedronis> maybe, depends on times, but will do geneva -> Lyon on Sunday
<zyga> same like me
<pedronis> at some point
<mup> PR snapd#6751 closed: overlord/snapstate: perform hard refresh check <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6751>
<Chipaca> what was the right name for 'sideloads'?
<zyga> Chipaca: none :)
<zyga> snap install from a file?
<Chipaca> unsigned? unverified? unpotatoed?
<zyga> unasserted?
<Chipaca> unasserted, thanks
<zyga> note, I just made that up
<zyga> but it sounds okay :)
<Chipaca> 'twas that afair
<Chipaca> AFAIR
<Chipaca> also
<mup> PR snapd#6853 closed: interfaces: special-case "snapd" in sanitizeSlotReservedForOS* helperâ¦ <Simple ð> <â  Critical> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6853>
<mvo> second review for 6793 would be nice (maybe mborzecki because he already did a first pass :) ?
<zyga> mvo: mborzecki will be back in half an hour
<zyga> mvo: can I help
<zyga> mvo: I ran into another bug, don't understand it yet, looks related to recent changes
<zyga> mvo: snap-confine cannot open the base directory in /tmp
<zyga> debugging now
<pstolowski> mvo: https://github.com/snapcore/snapd/pull/6823 can land?
<mup> PR #6823: packaging: build empty package on powerpc <Created by mvo5> <https://github.com/snapcore/snapd/pull/6823>
<mvo> pstolowski: if it has two reviews I think it can land
<mvo> zyga: oh, where do you see this bug?
<zyga> mvo: when developing on opensuse
<zyga> mvo: just added debugging, hold on
<zyga> it's odd, I didn't see it before
<pstolowski> mvo: 2nd review is from vorlonofportland
<mvo> pstolowski: aha, indeed, then yeah, lets merge it
<mup> PR snapd#6823 closed: packaging: build empty package on powerpc <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6823>
<mvo> pstolowski: thank you! I also cherry-picked it into 2.39
<pstolowski> Chipaca: 6803 has a few conflicts
<Chipaca> nevah
<mvo> 6795 also needs a second review, should be an easy win
<pstolowski> mvo: i've merged #6811 but we need to ping Sergio re your question about if it needs to go to 2.39
<mup> PR #6811: tests: make create-user test support managed devices <Simple ð> <Created by sergiocazzolato> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6811>
<mvo> pstolowski: indeed
<mvo> pstolowski: thank you!
<mup> PR snapd#6811 closed: tests: make create-user test support managed devices <Simple ð> <Created by sergiocazzolato> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6811>
<zyga> I need a break
<zyga> mvo: I think master may be broken
<zyga> mvo: the /tmp changes affecte stuff that is only picked up by tests running as user
<zyga> meh
<zyga> not fun
<zyga> anyone can run edge and say if stuff is falling apart?
<zyga> but first
<zyga> really
<zyga> break
<zyga> meh
<zyga> it's so odd
<zyga> something must have landed
<mvo> zyga: I just refreshed my bionic to edge and ran hello-world
<mvo> zyga: seems to be fine
<mvo> zyga: hold on, that was core not the snapd snap
<zyga> perhaps it's something in my setup
 * zyga explores
<zyga> so I get permission denied
<zyga> but it doesn't seem like apparmor
 * zyga rechecks
<mborzecki> re
<mvo> zyga: on my system(s) things seem to be ok - at least with test-snapd-tools.echo
<zyga> thanks for checking
<zyga> mvo: what are the permissions on /tmp/snap.test-snapd-tools?
<sparkiegeek> is there a potential for a race when 'snap install thing-with-home-interface', then running thing-with-home-interface and expecting :home to be connected?
<popey_> Wimpress: mvo: Chipaca you guys around for catch up at half past?
<sparkiegeek> Interface  Plug                        Slot  Notes
<sparkiegeek> home       documentation-builder:home  -     -
<sparkiegeek> trying to work out how that happened, in a fresh LXD container, immediately after 'snap install documentation-builder'
<zyga> sparkiegeek: odd, is core or snapd installed?
<mvo> zyga: drwx------ 3 root root 4,0K Mai 10 13:00 /tmp/snap.test-snapd-tools
<sparkiegeek> zyga: good question, this is repeatedly happening in aforementioned container - in a test run, so can add debugging but loop is longer than I'd like
<zyga> mvo: thanks
<mvo> popey_, Wimpress, Chipaca I'm around but I would not mind skipping given that we meet in lyon next week anyway
<zyga> mvo: for me it is root.users!
<zyga> mvo: whaaat?
 * zyga inspects
<zyga> mvo: can you remove that
<zyga> and run it again
<zyga> and see if that fails?
<zyga> mvo: I think I know what's wrong
<zyga> mvo: look at https://github.com/snapcore/snapd/pull/6714/files
<mup> PR #6714: cmd/snap-confine: reject crafted /tmp/snap.$SNAP_NAME <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/6714>
<zyga> mvo: you don't see it on debian
<zyga> see that code that changes groups?
<mvo> zyga: yes
<zyga> I think we need that now
<zyga> what's the permission of /usr/lib/snapd/snap-confine?
<popey_> mvo: ok, that's cool
<mvo> zyga: -rwsr-sr-x 1 root root 99K MÃ¤r 15 20:54 /usr/lib/snapd/snap-confine
<zyga> mvo: also in snapd.snap
<mup> PR snapd#6857 closed: gadget: record sector size in positioned volume <Gadget update> <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6857>
 * zyga is confused
<zyga> mvo: thank you
<mvo> popey_: cool, declined it now
<sparkiegeek> zyga: appears to be neither core nor snapd, but our good friend core18
<zyga> sparkiegeek: that's a known bug
 * zyga looks for the bug URL
<popey_> bug 1819318
<popey_> ?
<zyga> https://bugs.launchpad.net/snapd/+bug/1819318
<zyga> yep
<mup> Bug #1819318: no interfaces when installing only core18 <snapd:In Progress by zyga> <https://launchpad.net/bugs/1819318>
<sparkiegeek> zyga: ok, and workaround is to ... manually install core too?
<zyga> yes
<mvo> sparkiegeek: yes, this will be fixed in 2.39 (which is in candidate already and should go to stable early next week)
<mvo> sparkiegeek: sorry for the trouble
<sparkiegeek> mvo: np. Due to a separate SNAFU that took me out all of yesterday, glad to finally be able to get debugging on this and look under the curtain, happy it's a known issue
<mup> PR snapd#6795 closed: cmd,sandbox: tweak seccomp version info handling <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6795>
<sparkiegeek> is there a 'grep-friendly' way of determining if I'm hitting ^ that bug. i.e. snap connected documentation-builder | grep -v ':home' || snap install core ?
<zyga> sparkiegeek: just snap list is sufficient
<zyga> sparkiegeek: then snap connections will show you there are no slots
<sparkiegeek> zyga: right, just trying to build a snippet in a Makefile to workaround the bug if I need to, but don't install core if the interface is connected
<zyga> mborzecki: hey, do you want to repeat our experiment?
<zyga> mborzecki: I'm stuck, perhaps you will just see what's obviously broken
<zyga> https://meet.google.com/rha-xhdp-vic?authuser=0
<zyga> mvo: or you perhaps?
<zyga> anyone?
<mborzecki> zyga: in 5? i'm finishing reading through pstolowski's pr
<zyga> sure
<mup> PR snapcraft#2500 closed: cli: add remote build <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2500>
<cmatsuoka> \o/
<zyga> Chipaca, pstolowski: saving data of multipass, on removal, is loooong
<zyga> Chipaca: curious, how do we remove snapshots?
<Chipaca> zyga: snap forget
<pstolowski> zyga: uhmmm.. it can be disabled
<zyga> can I forget all snapshots of a given snap?
<Chipaca> zyga: yes
<Saviq> cachio: hey, any chance for a fedora-30 image please? :)
<Chipaca> zyga: not easily tho :-|
<Chipaca> zyga: maybe we should add that, although it'd be tricky
<zyga> Chipaca: I noticed
<zyga> given that the things are called NNN_$SNAP_NAME_*
<zyga> is that enough of a hint?
<zyga> Chipaca: can I just rm them manually?
<Chipaca> zyga: snap saved thesnap | <some magic> | xargs snap forget {} thesnap \;, or something
<zyga> or is there state
<zyga> :/
<Chipaca> zyga: there is no state
<zyga> ah
<zyga> off they go :)
<Chipaca> that was part of the design of snapshots
<zyga> thanks!
<zyga> though for usability
<zyga> killing snapshots of a snap
<zyga> very likely useful
<Chipaca> zyga: there is state about auto-snapshots, but it shouldn't break anything if it tries to remove them and they're gone
<Chipaca> zyga: file bugs if it breaks and eats your thesis
<zyga> who knew
<zyga> sudo has --background and --command-timeout options
<Chipaca> should we add a --purge to snap remove to mean "don't auto-snapshot"?
<zyga> Chipaca: yeah
<zyga> feels like something I'd do in tests
<zyga> our tests don't have much data but removing multipass hit my fans running
<Chipaca> pstolowski: wtyt?
<zyga> 2GBs
<Chipaca> wdyt*
<pstolowski> Chipaca: +1 to 'snap remove --purge', i like that. gives more control than all-or-nothing flag we have now
<Chipaca> we should either put up a pr, or write something in the forum, before we forget
<Chipaca> me, i'm going to have lunch
 * Chipaca prioritises like a baws
<cmatsuoka> mborzecki: PR #6849 failed some integration tests
<mup> PR #6849: many: introduce a gadget helper for locating device matching given structure <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6849>
<Saviq> mborzecki: it's != its ;)
<Saviq> https://github.com/snapcore/snapd/pull/6849/files#diff-f57f6320470091f8bb514620cc2fbbddR35
<mup> PR #6849: many: introduce a gadget helper for locating device matching given structure <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6849>
<zyga> mvo: mystery solved
<mborzecki> Saviq: duh, missed that, thanks for spotting
<mborzecki> pstolowski: May 10 12:01:02 may101137-895818 nsenter[32024]: retry.go:120: DEBUG: Retrying because of temporary net error: &net.OpError{Op:"dial", Net:"tcp", Source:net.Addr(nil), Addr:net.Addr(nil), Err:(*net.DNSError)(0xc00006c5c0)}
<mborzecki> we're logging the error as #+v ?
<mborzecki> %+v
<pstolowski> mborzecki: %#v, yes
<pstolowski> this is Debug though
<mborzecki> pstolowski: yup, so probably fine
<pstolowski> mborzecki: yeah, an it helps understand error conditions better if we need to peel them :}
<cachio> Saviq, sure, I'll try today
<mvo> zyga: what is the mystery?
<pstolowski> cachio: hey, can you take a look if that PR that we landed today needs to go to 2.39? https://github.com/snapcore/snapd/pull/6811
<mup> PR #6811: tests: make create-user test support managed devices <Simple ð> <Created by sergiocazzolato> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6811>
<zyga> joining
<mup> PR snapd#6793 closed: cmd/snap: support for --ensure argument for snap debug timings <Created by stolowski> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6793>
<pstolowski> Chipaca: so, i'll create forum topic re --purge and do impl sometime next week
<Chipaca> pstolowski: <3
<pstolowski> k
<pstolowski> degville: btw, we need to update documentation with automatic snapshots; is it ok if i send you a short description of it, and you flesh it out/reword and put in a proper context of existing doc?
<degville> pstolowski: absolutely, yes, of course.
<mvo> Chipaca: I couldn't help it and de-conflicted 6803
<mvo> Chipaca: hope you don't mind
<Chipaca> mvo: HULK SMASH
<Chipaca> mvo: sorry, i meant "thank you"
<Chipaca> mvo: typo
<Chipaca> :-Ã¾
<mvo> haha
 * mvo hugs Chipaca 
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#104 closed: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#104 opened: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
<cachio> mborzecki, zyga if you could take another look to #6541 should be great, thanks
<mup> PR #6541: tests: change how xdg-desktop-portal is prepared and restored for desktop-portal-* tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6541>
<mborzecki> cachio: ok
<cachio> mborzecki, thanks
<pstolowski> Chipaca: https://forum.snapcraft.io/t/automatic-snapshots-snap-remove-purge-proposal/11294
 * Chipaca reads
<Chipaca> pstolowski: thank you
<pstolowski> cmatsuoka: almost forgot - safe travels!
<cmatsuoka> thanks! :)
<cachio> pstolowski|afk, hey
<pstolowski|afk> cachio: hey
<cachio> I have few issues with core
<cachio> for example sudo usermod -a -G dialout user1
<cachio> does not work
<cachio> pstolowski|afk, https://paste.ubuntu.com/p/DdZsrRCxnB/
<cachio> is it required on core?
<pstolowski|afk> cachio: dialout is the group owner of serial ports by default; it's needed to actually access serial ports in nested vm (because we log as regular user, not root). you can skip it but the test will need to be much simpler (no tests for actual writing to the port)
<pstolowski|afk> cachio: but as discussed that's fine, we should start with a much simplified test
<cachio> pstolowski|afk, ok
<pstolowski|afk> cachio: don't worry too much about actual test, i can work on tweaking it further. just plugging in the qemu virtual serial adapter + checking if slot was created succesfully will be enough
<cachio> pstolowski|afk, ok,
<cachio> and at which point the test should fail?
<cachio> currently on core16 when I list connections the
<cachio> qemuusbserial doesn't exist
<cachio> this is not matching at all --> execute_remote "snap connections system" | MATCH "serial-port .* - .* :$SLOT_NAME"
<cachio> but /dev/ttyUSB0 exists
<pstolowski|afk> cachio: it's on official core16?
<cachio> core 2.38.1
<cachio> the stable one
<cachio> it created an image on nested vm
<pstolowski|afk> cachio: right. yes, so you won't see the slot there because hotplug changes for serial-port interface didn't land
<cachio> ah
<cachio> ok
<cachio> makes sense
<pstolowski|afk> cachio: so the test will fail as soon as we check snap intrfaces, expecting the slot to be there
<pstolowski|afk> cachio: if you see ttyUSB0 then it's good, qemu works as expected with core \o/
<cachio> pstolowski|afk, ah, nice
<cachio> I'll recheck on core18 and I'll create a PR so next week we can test it once the change is landed
<cachio> pstolowski|afk, thanks
<pstolowski|afk> cachio: np, ty! i'm signing off for this week, see you!
<cachio> pstolowski|afk, sure, enjoy your weekend
<mup> PR snapcraft#2541 closed: Desktop meta: strip ${SNAP} from .desktop icon <Created by diddledan> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2541>
<dcarmich> When I try to run classically-confined snaps on a Salt-managed Linux system as a user, I get the error: "cannot create user data directory: /Users/username/snap/(name of snap)/version: not a directory". However, when I install them on a stock Ubuntu 18.04 VM, they run just fine as a user. Is there a specific security setting I should look for that is causing this issue?
<dcarmich> I'm using snap version 2.38+18.04 on Ubuntu 18.04 LTS.
<cmatsuoka> niemeyer: we managed to remove adapter:full, using adapter:none now
<mup> PR snapcraft#2562 opened: extensions: add KF5 Neon extension <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2562>
<cachio> Saviq, hey, image fedora-30-64 ready
<cachio> I had to fix some issues with google packages
<cachio> but right now it is working
<cachio> just replace tha name you have set for fedora-29 and that should work
<mup> PR snapd#6859 opened: tests: new hotplug test executed on ubuntu core  <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6859>
 * cachio EOW
<mup> PR snapd#6860 opened: tests: running tests on fedora 30 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6860>
#snappy 2019-05-11
<mup> PR snapcraft#2561 closed: Promote branches fix <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2561>
<mup> PR snapcraft#2562 closed: extensions: add KF5 Neon extension <Created by cmatsuoka> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2562>
<mup> PR snapcraft#2563 opened: Release changelog for 3.5 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2563>
<mup> PR snapd#6861 opened:  packaging/fedora: Merge changes from Fedora Dist-Git and drop EOL Fedora releases <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/6861>
<Eighth_Doctor> zyga: https://github.com/snapcore/snapd/pull/6861
<mup> PR #6861:  packaging/fedora: Merge changes from Fedora Dist-Git and drop EOL Fedora releases <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/6861>
#snappy 2019-05-12
<zyga> Eighth_Doctor: https://github.com/snapcore/snapd/pull/6861#pullrequestreview-236401452
<mup> PR #6861:  packaging/fedora: Merge changes from Fedora Dist-Git and drop EOL Fedora releases <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/6861>
<Eighth_Doctor> zyga: I think I've responded accordingly
<lotuspsychje> good afternoon to all
<lotuspsychje> are we suppose to file canonical snaps to launchpad, or redirect users to 'the maintainer', aka canonical?
<Girtablulu> Save data of snap "retroarch" in automatic snapshot set #11 (cannot create archive: runuser: failed to user credentials: Fehler beim Festlegen der Benutzerberechtigung (and 0 more)) "Error with permission" this happens while removing a snap but installing is no issue, anyone knows what's going on?
<mup> PR #11: Publish coverage reports to coveralls <Created by elopio> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/11>
#snappy 2020-05-04
<mup> PR snapd#8592 opened: Add initial support for the hardware-control interface <Created by devec0> <https://github.com/snapcore/snapd/pull/8592>
<pstolowski> morning
<zyga> Hi
<BjornT> hi. i get this when trying to install a snap in a fresh ubuntu:20.04 lxd container: error: too early for operation, device not yet seeded or device model not acknowledged
<zyga> Hey BjornT
<zyga> This is a rather unfortunate part of our current implementation. After installing snapd there is a brief moment when snapd responds on the socket but is otherwise unable to do anything yet, as it is setting up some stuff
<zyga> Normally it lasts a moment
<zyga> Does it still happen?
<BjornT> zyga: yes, it doesn't seem to go away
<zyga> Can you run âsnap changesâ please
<BjornT> zyga: https://paste.ubuntu.com/p/XmmVZfjgNG/
<zyga> I can you try doing what you wanted before again? It seems that initialization is now done
<BjornT> zyga: ah, yes, now it works
<zyga> Cool
<klaasvakie> Hi, if I have a snap refresh timer set to our maintenance windows, is there a way to check if there is actually a new snap that's going to be installed during that time?
<zyga> klaasvakie: I don't believe there is, we don't have "snap refresh --dry-mode"
<zyga> but there's a chance you could guesstimate that by looking at snap info
<zyga> and checking the revision numbers installed on your system
<zyga> and the channel you are tracking
<zyga> and checking if snap info reports a different revision in the channel that is being tracked
<zyga> if so, "snap refresh" will pick that revision
<zyga> pstolowski: challenge for today, figure out what nukes some packages so that we don't have user-session services
<klaasvakie> ok, thanks zyga. I'll script something around this. It basically makes the difference whether I have to stay at work on Friday nights or if I get to go home :)
<zyga> the tests/main/session-tool-support test picks it up
<zyga> normally this test passes all the time but there's an interaction with another thet where /{,usr/}lib/systemd/user/dbus.socket goes away
<zyga> we probably remove the package with --autoremove or something similar
<zyga> it's only occurring on deb-based systems so it may be using something hand-coded to apt-get remove stuff
<zyga> klaasvakie: have you thought of using an enterprise proxy?
<zyga> it's a fantastic way to manage your fleet
<zyga> no need to worry about anything
<zyga> it lets you control the revisions your systems see
<zyga> https://docs.ubuntu.com/snap-store-proxy/en/
<zyga> it's super nice iMO
<klaasvakie> I have read about it, but I only started playing with 20.04 and snapd recently so I still have lots to learn
<zyga> klaasvakie: you install the proxy on your network and configure each device to use it
<zyga> klaasvakie: and then the proxy acts both as a cache
<zyga> and as a control point where you can pick which revisions are "current"
<zyga> let's you manage upgrades this way
<klaasvakie> I'll consider the enterprise proxy, thanks for pointing it out
<zyga> pstolowski: check this out please
<zyga> https://github.com/snapcore/snapd/pull/8592/checks?check_run_id=641794081
<mup> PR #8592: Add initial support for the hardware-control interface <Created by devec0> <https://github.com/snapcore/snapd/pull/8592>
<zyga> panic in overlord/ifacestate tests
<pstolowski> zyga: oh, not good, will check
<pstolowski> zyga: running ifacestate tests in a loop, no panic so far (will run hooktest too)
<zyga> is mvo off today?
<seb128> zyga, yes, according to hr.c.c at least
<zyga> ah, thank you
<seb128> np
<seb128> he should be back tomorrow according to the calendar
<pstolowski> zyga: i think they took a swap day for the sprint
<zyga> yeah
<zyga> well deserved
<mup> PR snapd#8593 opened: Stumb implementation of image.Prepare for darwin <Created by stolowski> <https://github.com/snapcore/snapd/pull/8593>
<pstolowski> zyga: ^
<zyga> oh :)
<pstolowski> zyga: it's fine as is in master but fails on my other PR, so making it a prerequisite to reduce diff there
<zyga> ok
<pstolowski> i've tweaked the description
<zyga> +1
<pstolowski> ty
<zyga> so, what's the most broken thing on master today
<zyga> actually the preseed test
<zyga> pstolowski: is the test fixed?
<zyga> pstolowski: IIRC you sent updates
<zyga> is it just unlucky, can it land now?
<pstolowski> let me check
<zyga> thank you
<pstolowski> ah no, it landed. where is it failing?
<pstolowski> zyga: ^
<zyga> ah, great
<zyga> I just need to rebase then
<zyga> older branch from last week
<pstolowski> ok
<pstolowski> zyga: i see tests/main/interfaces-audio-playback-record failure
<zyga> yeah
<pstolowski> it's interesting
<pstolowski> + rm -rf /run/user/12345 /home/test/.config/pulse
<pstolowski> 1476
<pstolowski> rm: cannot remove '/run/user/12345/doc': Is a directory
<zyga> https://github.com/snapcore/snapd/pull/8581
<zyga> :|
<zyga> maybe I could merge all the fix branches
<mup> PR #8581: tests: port pulseaudio test to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8581>
<zyga> and just merge them together
<pstolowski> ah, that, right..
<zyga> I guess
<zyga> with some luck
<zyga> we can land them
<zyga> just reduce the failure ratio one by one
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8578 is rather simple if you want to look
<mup> PR #8578: interfaces: add host-docs interface <Created by zyga> <https://github.com/snapcore/snapd/pull/8578>
<pstolowski> zyga: right, i'll
<oSoMoN> forum.snapcraft.io appears to be down
<slyon> hey #snappy! What is the best way to build a snap, which uses "base:core20"? The "core20" release does not yet seem to be available inside multipass, which makes my build fail...
<zyga> slyon: that's a great question, I don't actually know
<mup> PR snapcraft#3096 closed: pluginhandler: export SNAPCRAFT_BUILD_BASE to build environment <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3096>
<zyga> slyon: core20 beta will be released soon,
<zyga> slyon: I suspect it will be generally available after that
<oSoMoN> jdstrand, when you have a chance, can you comment on bug #1876442, please?
<mup> Bug #1876442: [snap] chromium causing many audit messages in syslog <snap> <chromium-browser (Ubuntu):New> <https://launchpad.net/bugs/1876442>
<slyon> zyga, hmm... thanks for the reply, anyway!
<cjp256> slyon: you should be able to use core20 if using snapcraft from candidate/edge channels.  there are rough edges still, so it's not yet in the stable channel.
<zyga> jamesh: hey
<zyga> jamesh: it's kind of late, are you around by any chance?
<ijohnson> morning folks
<zyga> hey Ian
<zyga> roses are red
<zyga> and so is master
<zyga> there is no rhyme
<zyga> it's a disaster
<ijohnson> just like there is no green
<zyga> # just made up on the spot
<zyga> :D
<ijohnson> is it just you and pstolowski today?
<zyga> so far
<pstolowski> hi ijohnson !
<ijohnson> o/ pstolowski
<ijohnson> I think Claudio said it was a public holiday there, not sure about Sergio
<pstolowski> ijohnson: one tiny nitpick to our lxd test PR, i'm happy to approve
<ijohnson> sure, let me look now
<zyga> pstolowski: thanks for spotting that, I missed it!
<zyga> my back hurts, I would like to exercise a little
<zyga> maybe after standup
<ijohnson> zyga: so what's all red, is it many things?
<ijohnson> zyga: is it anything related to the session-tool stuff we landed last week?
<zyga> ijohnson: random stuff we fixed last week that we couldn't land because $(other_thing)
<ijohnson> ah
<zyga> ijohnson: nothing new AFAIK
<zyga> ijohnson: I think we can push it all in with some luck in sequencing
<zyga> ijohnson: I'd love to land the pulse test first as it fails most often
<zyga> ijohnson: there _is_ something new, something picked up by one of the new tests (session-tool-support)
<zyga> ijohnson: something removes a debian package in during execution
<zyga> and that breaks all session tests as systemd --user has no service definitions for dbus anymore
<ijohnson> ah right I remember you talking with Maciej about this a bit last week
<zyga> that's the dbus-user-session package
<zyga> I'm trying to find it but no luck yet (though I was distracted with general catch-up and the shutdown bug from Alex)
<zyga> ijohnson: if all else fails let's "apt-get install" it in per-test prepare
<zyga>  or flag its absence in restore
<ijohnson> zyga: re the shutdown bug, did you see my notes on that in the SU doc?
<zyga> I'll try to get to that later today but if you beat me to it I'd love to
<zyga> oh, no
<zyga> let me look
<zyga> reading
<zyga> My gut feeling was
<zyga> it's the same bug we fixed recently in the context of lxd-in-classic
<zyga> it's a core system so perhaps this is a false trail
<zyga> but perhaps it's a "snap stop ..." command that runs in ExecStop=
<zyga> and the sequence is that core18 unmounted snapd
<zyga> but we have core
<zyga> and now there's a skew
<zyga> I wonder what happens on a core system
<zyga> where get core18 + snapd
<ijohnson> zyga: let's discuss the bug in the internal channel
<zyga> and core
<zyga> ok
<ijohnson> zyga: SU?
<zyga> joining
<cachio> pstolowski, https://travis-ci.org/github/snapcore/spread-cron/builds/682751904#L3799
<cachio> error in the preseed test
<cachio> cmatsuoka, https://travis-ci.org/github/snapcore/spread-cron/builds/682751904#L4031
<cachio> error in encript test
<pstolowski> cachio: thanks, i'll investigate
<cachio> pstolowski, thanks
<zyga> pstolowski: so journal test failed again
<zyga> makes me wonder about something you said recently
<zyga> that restarting journal restarts snapd
<zyga> do I remember that correctly?
<pstolowski> zyga: yes
<zyga> pstolowski: on core or on classic as well?
<pstolowski> zyga: but now i'm sending sigusr1. i added some debug to the test
<pstolowski> zyga: it's core-only config, i didn't check classic
<zyga> I tried various things on my system and journal restarts fine
<zyga> and snapd does *not* restart
<zyga> I wonder why it would behave differently on core
<pstolowski> zyga: i think it was only on core 16
<pstolowski> zyga: do you have a log from this failure?
<zyga> pstolowski: yeah,
<zyga> I just restarted journal on core16 - no snapd impact
<pstolowski> hmm
 * ijohnson -> quick break
<zyga> pstolowski: the failure was on
<zyga> https://github.com/snapcore/snapd/runs/642670950
<zyga> I need a break to stretch my back
<zyga> but I will look next
<zyga> don't worry :)
<pstolowski> zyga: my debug there shows: Process: 21744 ExecStart=/usr/lib/snapd/snapd (code=killed, signal=PIPE)
<zyga> oh :)
<zyga> hahah
<zyga> funny
<zyga> sigpipe is ignored in systemd in the future
<zyga> I bet we just need a small tweak
<zyga> let me check this, this is great hint!
<pstolowski> zyga: but why is this?
<zyga> pstolowski: I will explain in a sec, just need to check it
<zyga> pstolowski: stdout/stderr are piped to journald
<zyga> pstolowski: https://github.com/cybozu-go/well/issues/13
<pstolowski> zyga: aaaah
<pstolowski> zyga: that's annoying, becuase we tell journald to just reload config :/
<pstolowski> not to restart
<zyga> software
<pstolowski> sigusr1
<zyga> must be broken somehow :)
<zyga> it may just to that, it's still closing the pipe apparently
<zyga> I wonder though
<zyga> if that leaves us without any logging
<zyga> because if we ignore it
<zyga> ...
<zyga> do we log anywhere?!
<zyga> https://bugs.freedesktop.org/show_bug.cgi?id=84923
<pstolowski> heh, indeed
<zyga> oh my god
<zyga> this is so bad
<zyga> I mean
<zyga> it's just literally killing snapd at _arbitrary_ point due to snap set
<zyga> well
<zyga> first thing is first
<zyga> let's fix the test not to break
<zyga> then let's figure out what needs to be done
<pstolowski> it's worse, it's killing it while in configure hook
<pstolowski> the test cannot be fixed really afaiu, snapd simply gets killed as snap set is being executed
<zyga> pstolowski: https://bugs.freedesktop.org/show_bug.cgi?id=84923#c9
<zyga> this is the killer
<zyga> pstolowski: essentially on core16 we cannot have this feature
<zyga> pstolowski: OR
<zyga> pstolowski: we need to architect it so that snapd saves state and organizes a controlled "semi shutdown", anticipating SIGPIPE
<zyga> pstolowski: we should escalate this
<pstolowski> yes
<pstolowski> i can prepare a PR that disables the feature & test for now (but not reverts it, just disables)
<pstolowski> and then we can think
<pstolowski> ah, we can disabled it just on core16
<pstolowski> *disable
<pstolowski> zyga: thanks for finding these bug reports!
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8594
<mup> PR #8594: tests: work around journald bug in core16 <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8594>
<zyga> pstolowski: I think we should consider disabling this *feature* on core16
<zyga> or consider a backport of journald fix - if feasable - from foundations
<mup> PR snapd#8594 opened: tests: work around journald bug in core16 <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8594>
<pstolowski> zyga: giving that core16 will eventually *cough* go away...
<zyga> pstolowski: in 2016 ;)
<pstolowski> zyga: thank you for the PR, looks great, i wonder if we shouldn't make retry conditional on core16 though, so we don't hide potential issue on other cores
<zyga> yeah, I thought about that for a sec
<zyga> it's testing now, if it passes I'll send a tweak
<pstolowski> sounds good
<zyga> pstolowski: ohh
<zyga> https://www.theverge.com/2020/5/4/21245940/macbook-pro-13-inch-apple-new-magic-keyboard-price-release-date
<zyga> ijohnson, pstolowski, cmatsuoka: please review https://github.com/snapcore/snapd/pull/8594 - mvo can merge this later today if it's +2
<mup> PR #8594: tests: work around journald bug in core16 <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8594>
<ijohnson> zyga: looking
<cmatsuoka> zyga: ack, checking it
<zyga> to clarify, retry-tool there just gives us more chances
<zyga> snapd still restarts
<zyga> but snap the client, may get a chance to talk to it after reconnection more often
<zyga> and may eventually work
<zyga> that's all
<zyga> this test fails in master randomly but often enough to be annoying
<pstolowski> yeah, my only remark is to make retry conditional on core16
<ijohnson> zyga: reading backlog, IMHO I think this needs to be escalated to foundations for a core16 backport
<ijohnson> zyga: this feature was originally slated for a uc16 customer IIRC
<ijohnson> so we can't just not have this feature on uc16 I think
<ijohnson> also I agree with pstolowski I think we should only do this on uc16
<zyga> I agree on both
<zyga> Afk because back pain
<mup> PR snapcraft#3104 opened: packaging: use git-based versioning for python package <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3104>
 * cachio lunch
<zyga> I made the modifications and will push after round of local testing
<zyga> pushed now
<zyga> pstolowski, ijohnson: the relevant systemd commit is 13790add4bf648fed816361794d8277a75253410
<zyga> I will look if we can have a backport
<ijohnson> thanks for digging into that zyga, a LP bug is probably a good place to co-ordinate with foundations?
<zyga> yeah, I will file one today
<ijohnson> cool
<pstolowski> zyga: \o/
<zyga> ugggh
<zyga> ijohnson: it's hopeless
<zyga> we are on 219
<zyga> we need at least 236
<ijohnson> damn
<zyga> the infrastructure to support it is substantial
<zyga> journald passes a bunch of FDs to save to systemd
<zyga> restartes
<zyga> *restarts
<zyga> and gets them back
<zyga> there's no other way
<zyga> so I guess ... SOL
<zyga> I need to rest again, my back is killing me today :/
<zyga> if I forget, please escalate this tomorrow to mvo
<ijohnson> of course
<ijohnson> I will put some thoughts into the SU doc so we don't forget
<zyga> thank you!
<ijohnson> pstolowski: so when we go to change the persistence of journald, can we change a config file and then just reboot the whole system ?
<ijohnson> it wouldn't be  great that we have to restart the system just to change logging but it's certainly better than having things all randomly die
 * ijohnson goes to read the implementation in snapd
<pstolowski> ijohnson: reboot is not needed, it's a problem only with core16
<ijohnson> pstolowski: no I mean for core16 could we reboot?
<pstolowski> ijohnson: ah, i see. well, yes we could i suppose
<ijohnson> pstolowski: because afaict the issue is that when we reload journald it kills everything which is bad, so maybe instead of reloading journald we just change some config file behind journald's back and then reboot the system so upon boot it would be fixed
<ijohnson> I presume that journald is not inotify'ing the config files, etc.
<pstolowski> ijohnson: heh, there is no config file
<ijohnson> pstolowski: so there's just the dir that's created in /var/log/journal?
<pstolowski> ijohnson: you just create /var/log/journal
<pstolowski> ijohnson: and reboot
<ijohnson> pstolowski: hmm maybe worth a try
<pstolowski> ijohnson: normally you send sigusr1 to notify journald about change
<ijohnson> right, so on uc16, instead of sending sigusr1, we would just request a restart
<pstolowski> ijohnson: yes
<ijohnson> pstolowski: would we need some kind of special code to make the change/tasks associated with this work, or could I just try putting in handleJournalConfiguration a call to restart snapd ?
<ijohnson> hmm although that's probably not the level we want to restart things
<ijohnson> err I mean reboot the system
<pstolowski> ijohnson: that's a fair point
<ijohnson> alright well I'll just leave this idea in the SU docs for folks to think about, I have a bit too much on my plate to dig more deeply on this
<ijohnson> pstolowski: did you see I assigned you a bug on Friday related to hotplug and auto-connect?
<ijohnson> https://bugs.launchpad.net/snapd/+bug/1876356
<mup> Bug #1876356: greedy auto-connect doesn't work with hotplug <snapd:Confirmed for stolowski> <https://launchpad.net/bugs/1876356>
<ijohnson> just curious if you have any thoughts on why that doesn't "just work"
<pstolowski> ijohnson: ah, no, i didn't
<ijohnson> no worries, I think it's a lowish priority thing
<pstolowski> ijohnson: thanks for all the details in the report, i'll see if there is anything obvious
<pstolowski> missing
<mup> Bug #1876478 changed: Automatic snap refreshes changes state of service from stopped to running <Snappy:Invalid> <https://launchpad.net/bugs/1876478>
<mup> PR snapcraft#3105 opened: build provider: clean incompatible build-environments <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3105>
<zyga> it seems the portal test is leaking stuff
<zyga> | |-/run/user/12345                   tmpfs                                                                                    tmpfs      rw,nosuid,nodev,relatime,size=377196k,mode=700,uid=12345,gid=12345                                   shared
<zyga> | | `-/run/user/12345/doc             /dev/fuse                                                                                fuse       rw,nosuid,nodev,relatime,user_id=12345,group_id=12345                                                shared
<zyga> oh well
<zyga> another test to fix
<ijohnson> zyga: could we just do `[ -d $XDG_RUNTIME_DIR/doc ] && umount $XDG_RUNTIME_DIR/doc` ?
<ijohnson> at the end of teardown_portals ?
<zyga> ijohnson: perhaps but I doubt that is the problem
<zyga> the problem is more comple
<zyga> *complex
<zyga> we *activate* portals each time we invoke a program that seems to have a desktop plug (at all)
<zyga> so any test using snap run may trigger it
<ijohnson> Hmm really?
<zyga> yeah
<zyga> I suspect we run a program via su -u test
<zyga> and that runs the portal outside of the session
<zyga> so just happily in the space
<zyga> I'll add a small check and run all the tests
<zyga> what we really need is proper session teradown
<zyga> we may need to change session-tool --restore to wait for linger shutdown as well, I need t ocheck
<zyga> but first, need to find that test that leaks this
<zyga> saving the log archive
<zyga> we ran this before: 2020-05-04T16:33:35.0630508Z 2020-05-04 16:33:35 Preparing google:ubuntu-19.10-64:tests/main/interfaces-desktop-document-portal (may041608-600544)...
<zyga> https://www.irccloud.com/pastebin/y3YiWMAY/
<zyga> it's one of those tests for sure :)
<zyga> ijohnson: oh my
<zyga> that test *badly* need session-tool
<zyga> why is that test using snap-try?
<zyga> ijohnson: session-tool beats su not because of any technical choices but simply becaues it puts the damn username before the damn command
<ijohnson> Hahaha
<ijohnson> Yeah I will look into this some more after lunch if you haven't figured it out
 * ijohnson -> lunch 
<zyga> done
<zyga> ijohnson: I'll send a PR shortly
<zyga> ijohnson: I wonder if I should grep for "su" in the code
<ijohnson> you might be afraid of what you find
<mup> PR snapd#8595 opened: o/ifacestate/handlers.go: fix typo <Simple ð> <Skip spread> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8595>
<mup> PR snapd#8589 closed: tests: port user-session-env to session-tool <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8589>
<mup> PR snapd#8594 closed: tests: work around journald bug in core16 <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8594>
<zyga> wooooot
<mup> PR snapd#8581 closed: tests: port pulseaudio test to session-tool <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8581>
<mup> PR snapd#8587 closed: tests: session-tool allows preparing/restoring for many users <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8587>
<ijohnson> yay mvo for the win
<zyga> interesting stuff I find
<zyga> I wonder if 19.10 specific
<zyga> maybe some fluke of bugs interacting
<zyga> so on 19.10 session-tool -u test --prepare
<zyga> seems to ... not make a session
<ijohnson> that's the only reason snaps work at all sometimes is that bugs interact and cancel each other out
<zyga> ??!
<zyga> hahaha
<ijohnson> so session-tool has become the-tool
<zyga> isn't that like half of current physics theories ;)
<ijohnson> on 19.10 at least
<zyga> all the infinities cancel each outher ;)
<ijohnson> yep!
<zyga> ijohnson: totally off-topic, over weekend I got an i2c DS 1307 RTC add-on to my raspberry pi
<zyga> maybe next weekend I'll have a snap that manages time
<ijohnson> very nice
<zyga> though not perfectly (late boot)
<zyga> I wonder if there would be a way to run some super-special things earlier via snapd
<ijohnson> I have an RTC board too ... somewhere in my collection of random add-on things
<zyga> (with appropriate interfaces)
<zyga> cool
<ijohnson> true, it would be most useful to have a RTC available during early boot
<zyga> I wonder if it uses the same chip, I heard DS 1307 is popular
<zyga> ijohnson: sadly it's not a /dev/rtc kind of thing
<zyga> maybe it could be if device tree said something
<ijohnson> yeah most rpi things seem to not be quite as simple plug and play like that
<zyga> but I don't know how to do that
<ijohnson> yeah I haven't looked into that at all either
<zyga> https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/rtc/rtc-ds1307.txt <- it seems to be supported
<ijohnson> nice so I bet with your own pi gadget it would probably just work
<zyga> I don't know how to use DBTs though :)
<zyga> more to learn
<zyga> digging deeper
<zyga> but I will EOD soon
<zyga> really not well today
<zyga> and it's late
<mup> PR snapd#8595 closed: o/ifacestate/handlers.go: fix typo <Simple ð> <Skip spread> <Created by anonymouse64> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8595>
<zyga> drat
<zyga> my daughter turned off my laptop
<zyga> I see a pattern now, I wonder what's the cause
<zyga> but I also have a solution
<zyga> just cannot justify it apart from "it seems to work"
<zyga> I guess some systemd sources are to be read
<mup> PR snapcraft#3106 opened: sources: enable git, local, and tar handlers for all platforms <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3106>
<mup> Bug #1875543 changed: Ubuntu 20.04 "A stop job is running for Snappy Daemon" during shutdown <20.04> <ubuntu> <Snappy:New> <https://launchpad.net/bugs/1875543>
<mup> Bug #1876478 opened: snap stop does not explain that automatic snap refreshes starts stopped, enabled svcs <Snappy:Confirmed for morrisong> <https://launchpad.net/bugs/1876478>
<zyga> ijohnson: around? :)
<ijohnson> yep
<zyga> ijohnson: so here's what I learned: on 19.10 loginctl disable-linger leaves user@12345.service in user-12345.slice
<zyga> why? I don't know yet
<zyga> stopping the slice reliably stops everything and /run/user/12345 goes away
<zyga> on 20.04 I don't see it
<ijohnson> huh
<zyga> I wonder if there's an interplay with some workarounds
<ijohnson> that feels like a bug to me
<zyga> so I patched session-tool to add the stops and the extra check for /run/user/12345 (for the test user obviously)
<ijohnson> in systemd that is
<ijohnson> wait but shouldn't the systemd version be basically the same between 19.10 and 20.04 ?
<zyga> and I'm running a pass to see how it affects the "fleet" of systems running user-mounts test
<zyga> ijohnson: 242 vs 245
<zyga> ijohnson: we have a logind workaround for 242 (fixed in ... wait for it ... 243!)
<zyga> ijohnson: so maybe more bugs bugs bugs
<zyga> ijohnson: I've yet to look at logind source but that's my next plan
<zyga> I kind of want core 20 now
<zyga> at least so many systemd bugs are gone there
<ijohnson> haha
<zyga> ijohnson: with the change user-mounts with trivial restore (session-tool -u test --restore) leaves no junk behind
<zyga> and I bet this improves interplay with other tests
<zyga> but why? :D
<zyga> beats me
<ijohnson> bugs that's why
<zyga> it's super late and my wife looks at me with that very clear "STOP WORKING" eyesight
<zyga> so I'll defer that
<ijohnson> ttyl zyga :-)
<zyga> but I'll send the patch for user-mounts in today still
<zyga> now suppe r:)
<zyga> ijohnson: session-tool patch https://github.com/snapcore/snapd/pull/8596
<mup> PR #8596: tests: session-tool --restore -u stops user-$UID.slice <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8596>
<mup> PR snapd#8596 opened: tests: session-tool --restore -u stops user-$UID.slice <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8596>
<ijohnson> Nice
<zyga> it's not perfect because "Unknown reasons" but it's progress
<zyga> I also suspect this could have some impact on other tests, as they were effectively leaking more bits
<zyga> plus this is a PR for master after mvo landed all the good fixes
<zyga> so with a bit of hope it won't fail
<zyga> ijohnson: and this is the user-mounts test
<zyga> https://github.com/snapcore/snapd/pull/8597
<mup> PR #8597: tests: port user-mounts test to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8597>
<zyga> and some typo fixes
<mup> PR snapd#8597 opened: tests: port user-mounts test to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8597>
<zyga> I'll break for an hour and walk the dog
<ijohnson> zyga approved the session-tool one and commented on the other one
 * ijohnson EODs
<mup> PR snapcraft#3106 closed: sources: enable git, local, and tar handlers for all platforms <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3106>
#snappy 2020-05-05
<mborzecki> morning
<zyga> hey
<zyga> mborzecki: I'm fixing the tumbleweed degraded test now
<mborzecki> zyga: hey, it's failing?
<zyga> yeah, some vty thing is complaining
<zyga> nothing relevant
<zyga> https://github.com/snapcore/snapd/pull/8596 needs a review
<mup> PR #8596: tests: session-tool --restore -u stops user-$UID.slice <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8596>
<zyga> mborzecki: we have a problem with journal test but let's do one thing at a time
<zyga> (and the feature, not just the test)
<mborzecki> persistent journal test?
<zyga> yes
<zyga> it's soaky wet ouside, my dog will not be happy
<zyga> mborzecki: look at the test if you are curious
<zyga> it has some countermeasures
<zyga> but it's a real problem
<zyga> and they are insufficinent apparently, it failed again on the unprotected "snap set" code path at the end of the test
<zyga> how was the long weekend?
<mborzecki> zyga: it was ok, but felt a bit weird since everyone else had friday off and i swapped for monday ;)
<mborzecki> zyga: btw. our fonts cache handling is broken i think, we'll need to discuss what to do about that, but the current observation is that we should not trust the font cache generated on the host to be compatible
<zyga> mborzecki: happy to
<zyga> mborzecki: can we stop sharing caches
<zyga> caches belong to /var/snap/$BASE/
<zyga> anything else is broken
<mborzecki> hm idk, caches belog to whatever fontconfig is used
<mborzecki> that can be base, gnome/kde/freedesktop runtime, or the snap
<mborzecki> anyways, desktop apps render boxes or straight out segfault on fedora 32 now
<zyga> mborzecki: I'm only talking about the fonconfig managed by snapd
<mborzecki> zyga: but none of the bases we have ship fontconfig
<zyga> but each of them has an associated gnome
<mborzecki> zyga: idk, we need to think this though, it was a nice idea for an optimization, but it looks like it's misplaced and doing harm to the cross distro story
<zyga> and derived fontconfig
<zyga> but yeah
<zyga> needs thought
<mborzecki> zyga: the snap can ship a different fontconfig, or not not use the gnome runtime at all
<zyga> mborzecki: snaps may ship it, we can just disable the shared (base) cache then
<zyga> mborzecki: if they do the simple thing, the use the same version that's in the base
<zyga> mborzecki: either via bundling or via content to gnome runtime
<zyga> mborzecki: base is just the easiest sharing "key"
<mborzecki> zyga: kenvandine had an idea for per snap cache, with fc-cache getting called in the configure hook
<zyga> mborzecki: that will work but it it would be *very* costly IMO
<zyga> and the cache has non-insignificant size
<mborzecki> in the meantime, i need to think of a way to disable mounting of cache from hsot on arch and fedora, i'd rather have a longer statup than a segfaulting app
<zyga> mborzecki: +1
<zyga> mborzecki: that should be easy
<zyga> mborzecki: where is the cache again?
<mborzecki> zyga: the configure hook runs during install, so it's just the snap install that takes longer
<zyga> mborzecki: that is true, I do like that part
<zyga> mborzecki: but does it mean all snaps get a virtual hook
<mborzecki> zyga: /var/cache/fontconfig and ~/.cache/fontconfig
<zyga> mborzecki: or do they need to explicitly cooperate?
<mborzecki> zyga: well, if we make it a gnome extention, then snaps need to be rebuilt/cooperate
<mborzecki> mvo: hey!
<mvo> mborzecki: good morning
<zyga> mvo: hey
<mvo> zyga: and good morning to you as well!
<zyga> https://github.com/snapcore/snapd/pull/8598 <- last of the always-happening failures
<mup> PR #8598: tests/degrated: ignore failure in systemd-vconsole-setup.service <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8598>
<mvo> zyga: looking
<mup> PR snapd#8598 opened: tests/degrated: ignore failure in systemd-vconsole-setup.service <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8598>
<zyga> mvo, mborzecki <- please look at https://github.com/snapcore/snapd/pull/8596 as well
<mup> PR #8596: tests: session-tool --restore -u stops user-$UID.slice <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8596>
<zyga> ok, I need to take the dog out
<zyga> onto the rain :|
<zyga> or maybe into the rain actually
<mup> PR snapd#8593 closed: image: stub implementation of image.Prepare for darwin <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8593>
<mup> PR snapd#8596 closed: tests: session-tool --restore -u stops user-$UID.slice <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8596>
<jamesh> zyga: re. your questions about me trying to use session-tool: https://github.com/snapcore/snapd/pull/5822#discussion_r419901621
<mup> PR #5822: wrappers: allow user mode systemd daemons <:birthday:> <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5822>
<pstolowski> morning
<zyga> jamesh: good morning
<zyga> lookijg
<zyga> jamesh: I ported user-mounts to session-tool yesterday
<jamesh> zyga: the problems seem to suggest that sessions are not being cleaned up between tests
<zyga> jamesh: I think https://github.com/snapcore/snapd/pull/8596 may address this
<zyga> which just landed
<mup> PR #8596: tests: session-tool --restore -u stops user-$UID.slice <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8596>
<zyga> have a look, it's still a bit murky
<zyga> I will look at logind changes
<zyga> as it definitely behaves differently from one version to another
<jamesh> zyga: okay.  I'll give it another try.
<zyga> thanks
<jamesh> zyga: overall, I like what you've done.
<zyga> I think we are not quite fully there yet, with groking various quirks in session handling across time
<zyga> but I feel we are much closer to actually running representative tests
<zyga> and getting familiar with bugs that may also impact us
<jamesh> hopefully we don't end up with anything that depends on systemd environment vs. login shell environment...
<zyga> jamesh: login shell environment?
<jamesh> zyga: the environment you get in a login shell, which could be different to the one systemd units are launched in
<zyga> oh, it is
<zyga> but we use runuser -l
<zyga> which gives us /etc/pam.d/runuser-l
<zyga> but it's a good point that we should understand that difference better and see what's different still
<zyga> due to runuser-l we get a real logind session and we get a few more pam modules
<jamesh> zyga: it's probably not an issue
<jamesh> since a test can add anything extra it needs in the env
<zyga> looking just now, I see we don't get this pam module:
<zyga> session required        pam_env.so readenv=1 user_readenv=1 envfile=/etc/default/locale
<zyga> surreal, we will have first green PR in a week, I think
<zyga> or more perhaps
<zyga> mvo: thank you
<zyga> mvo: I was waiting for that green tick
<zyga> but let's see it on ALL THE BRANCHES now :)
<mup> PR snapd#8598 closed: tests/degrated: ignore failure in systemd-vconsole-setup.service <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8598>
<mvo> zyga: yeah, this looks super nice now
<mvo> zyga: I hope we overcame most of the flakiness for now
<zyga> checkSnapSuite.TestCheckSnapSystemUsernamesCalls fails if you have daemon users installed
<mborzecki> zyga: slightly tweaked #8580
<mup> PR #8580: data/completion: add `snap` command completion for zsh <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8580>
<Chipaca> hehe, booting old work laptop -> log in to old irc channels
<Chipaca> morning all
<mborzecki> Chipaca: morning sir!
<Chipaca> :-)
<mborzecki> zyga: the pulseaudio test is still kinda flaky, https://github.com/snapcore/snapd/pull/8537/checks?check_run_id=645190804 recording failed on 19.10 and pulseaudio iface test failed on 18.04
<mup> PR #8537: store: handle error-list in fetch-assertions results  <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8537>
<pstolowski> i'm seeing new selinux denials on centos 7 & fedora, not sure if this is my branch onl
<pstolowski> *only
<pstolowski> howdy Chipaca!
<Chipaca> pstolowski: how're things going?
<pstolowski> Chipaca: red color has been dominant recently. otherwise - excellent :)
<zyga> Chipaca: did you see my poem? :)
<zyga> mborzecki: looking
<zyga> mborzecki: oh, it's in the old style with manual masking and all the hacks
<zyga> mborzecki: let me fix it
<Chipaca> zyga: yep :) 'twas good. Also wondering what the background you were talking about looked like.
<zyga> Chipaca: a week+ of master red
<zyga> Chipaca: and mvo (who can override) being at a sprint
<zyga> Chipaca: but it was good, vast majority was fixed already
<zyga> mborzecki: testing now
<pstolowski> mvo: hi, can the initrd PRs for early config land?
<mvo> pstolowski: I think so
<mvo> pstolowski: would be nice to get a review from xnox onhttps://github.com/snapcore/core20/pull/46
<mup> PR core20#46: static: add new handle_writable_defaults() to handle-writable-paths <Created by mvo5> <https://github.com/snapcore/core20/pull/46>
<mvo> pstolowski: but yeah, I think the code is good now
<xnox> mvo:  looks good, two minor unresolved conversations on it.
<mvo> xnox: aha, thank you, I will check what's missing there
<zyga> brb
<zyga> re
<zyga> man, it's surely raining today
<zyga> soaky day
<zyga> today is a tea day
<pedronis> mvo: hi, the travis test for core20 in your PR failed
<mborzecki> pedronis: i've added some reviews for the bulk assertions PR, we should probably land the ones that precede #8564
<mup> PR #8564: asserts: introduce Pool <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8564>
<mvo> pedronis: checking
<mvo> pedronis: and hello :)
<pedronis> mborzecki: yes, trying but red and queueing atm
<pedronis> mborzecki: thanks for the reviews btw, same pstolowski
<pstolowski> pedronis: yw. i'm keen to review the others but would be nice to land the prereqs, it was kinda confusing to review stacked PRs
<pedronis> pstolowski: yes, agree
<mvo> pedronis: fun "--2020-05-05 09:45:09--  http://cdimage.ubuntu.com/ubuntu-base/daily/current/focal-base-amd64.tar.gz is 404 now", I guess that needs an update first :)
<zyga> oh about focal, mvo do you remember that bug where hardlinking on livecd used 400MB?
<zyga> we got a comment that apparently the releaes iso shipped with that bug :|
<zyga> so maybe something was off
<mvo> zyga: oh, I thought we fixed this
<zyga> we did but maybe didn't really
<mvo> zyga: https://bugs.launchpad.net/snapd/+bug/1867415
<mup> Bug #1867415: Hardlinking snaps wastes 400 MB tmpfs RAM in live CDs <rls-ff-incoming> <snapd:New for mvo> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1867415>
<zyga> mvo: comment #6
<mvo> zyga: yeah, just saw it
<mup> PR core20#51 opened: Makefile: updated now that focal is released <Created by mvo5> <https://github.com/snapcore/core20/pull/51>
<mup> PR snapd#8599 opened: tests: port interfaces-audio-playback-record to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8599>
<pedronis> fwiw it seems we hit queuing quite a bit atm with actions, have things queued for many hours now
<zyga> pedronis: result of fixing most of master annoyances
<zyga> pedronis: I think it will clear in a few hours, let me look at the state
<zyga> pedronis: yeah, we have a few branches queued and lots running as well
<zyga> mvo: I got a weird email about authorization refresh
<zyga> Launchpad failed to refresh the authorization tokens used to upload this snap package to the store:
<zyga> (then) Provided email/password is not correct.
<zyga> this is from test-snapd-sh-core18
<mborzecki> zyga: got one too
<mborzecki> zyga: do you remember a change where we checked whwether the system is going down? was that in snap run?
<zyga> yes I do, yes it is
<zyga> cmd_run.go
<zyga> isSystemStopping IIRC
<zyga> why?
<mborzecki> zyga: if the logs ehere are to be belived: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1873550/comments/3 we may need to check if system is shutting down in snap-failure
<mup> Bug #1873550: Snappy daemon reaches 1min30s timeout during shutdown process <focal> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1873550>
<zyga> ha
<zyga> fun
<zyga> why does OnFailure trigger?
<mborzecki> zyga: because we hit the stop timeout, there's a wait for api clients to shut down, hits a 25s timeout, then before snapd stopped systemd killed it?
<zyga> I see
<mborzecki> hm maybe that client shutdown timeout is too long still
<mborzecki> 25s is pretty log for any api activity
<mborzecki> btw. pretty lame that systemd triggers onfailure when the system is shutting down
<mborzecki> still, why is there a 5s break between snapd logging the warning and being killed by systemd
<zyga> mborzecki: I think systemd.exec knows
<mborzecki> zyga: yeah, noticed a log that there's a stop action queued, so it's not going to enqueue start
<mborzecki> anyways, one of the commenters clearly had a newer snapd version
<zyga> hmm, nothing useful in the man page
<zyga> there's also systemd.kill
<zyga> maybe it's one of the defaults
<pstolowski> ijohnson: hey, i've checked your hotplug + greedy plugs issue, replied to your bug report, does it make sense?
<mup> PR snapcraft#3107 opened: fix yarn version url <Created by fkromer> <https://github.com/snapcore/snapcraft/pull/3107>
<mup> PR snapd#8600 opened: tests: run smoke test with different bases <Created by mvo5> <https://github.com/snapcore/snapd/pull/8600>
<mup> PR snapd#8580 closed: data/completion: add `snap` command completion for zsh <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8580>
 * zyga -> errand
<mup> PR snapd#8601 opened: Adds missing paths to apparmor, solves lp:1876804 <Created by sklei4> <https://github.com/snapcore/snapd/pull/8601>
<zyga> https://github.com/snapcore/snapd/pull/8597 is green :)D
<mup> PR #8597: tests: port user-mounts test to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8597>
<ijohnson> zyga: that's great
<zyga> wait, is there a bzr tree of snapd?!?
<zyga> https://bugs.launchpad.net/snapd/+bug/1876804/comments/1
<mup> Bug #1876804:  apparmor logs filled when ubuntu store launches  <snapd:New> <https://launchpad.net/bugs/1876804>
<ijohnson> zyga: I'm still a little confused though, does the old test really have coverage of something we care about on 14.04
<ijohnson> zyga: haha yeah I was confused too
<zyga> ijohnson: I'm slowly inclined to restore 14.04 support by writing a 14.04 version of session-tool
<ijohnson> zyga: I'm fine if you want to do a followup to re-add 14.04
<ijohnson> zyga: but I don't feel comfortable just dropping coverage for 14.04 yet as afaik the policy is don't break it if we don't have to
<zyga> ijohnson: I think it's preferable to be able to fix issues globally by changing session-tool
<ijohnson> zyga: maybe a followup to add  TODO to that test to say "re-add 14.04 when session-tool is updated"
<zyga> ijohnson: sure,
<ijohnson> ok, I will +1 your PR
<zyga> I can bundle that with something else not to clog the pipe today
<zyga> with the next -porting-NNN branch
<ijohnson> right
<pedronis> mvo: #8537, please double check but I think can probably be force landed
<mup> PR #8537: store: handle error-list in fetch-assertions results  <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8537>
<pstolowski> zyga: do you know what was the first good systemd version wrt to persistent journal issue?
 * zyga is in the car
<zyga> pstolowski: yes, one sec
<zyga> https://github.com/snapcore/snapd/pull/8594#issuecomment-623584798
<zyga> pstolowski: ^
<mup> PR #8594: tests: work around journald bug in core16 <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8594>
<pstolowski> zyga: thanks!
 * zyga is in the car, delivering supplies 
<zyga> and reading about how to send the control bugs to BTS
<mborzecki> whcih package ships translations for snapd?
<mborzecki> in ubuntu
<zyga> mborzecki: ubuntu uses a special langpack system
<zyga> apt-cache search langpack
<ijohnson> pedronis: 8557 lgtm, thanks for the changes
<zyga> mborzecki: translations are extracted from individual packages (in main)
<zyga> mborzecki: and bundled into language-specific package
<mborzecki> zyga: ok, installing bits for uk_UA
<zyga> haraszo
<mborzecki> haha
<mborzecki> zyga: hmm there does not seem to be a gettext file for snap tho
<pedronis> ijohnson: thanks
<pedronis> #8557 needs a 2nd review, it's mostly a test refactoring
<mup> PR #8557: c/snap-bootstrap: check mount states via initramfsMountStates <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8557>
<mborzecki> zyga: heh, so we ignore LC_ALL and just use LC_MESSAGES and LANG (a bug then?)
<mborzecki> haa
<mborzecki> got it
<mup> PR snapd#8602 opened: configcore: only reload journald if systemd is new enough <Created by stolowski> <https://github.com/snapcore/snapd/pull/8602>
<mvo> pedronis: in various meeting, will check in a wee bit
<zyga> mborzecki: re
<zyga> mborzecki: there are two langpacks, base and "graphical"
<zyga> not sure which one you checked
 * cachio lunch
<ijohnson> zyga: shall I merge #8599 since it's green (except unstable system) ?
<ijohnson> I just approved it
<mup> PR #8599: tests: port interfaces-audio-playback-record to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8599>
<zyga> looking
<zyga> ijohnson: oh, there's a small comment
<zyga> I guess, yes
<zyga> I will follow up in a moment
<zyga> thanks!
 * ijohnson just wants to see green PR's get merged 
<ijohnson> :-)
<zyga> yeah, that's the spirit!
<zyga> keep master rolling
<zyga> wanna press the button or shall I?
<pedronis> #8557 is completely green, incredibly, but needs a 2nd review
<mup> PR #8557: c/snap-bootstrap: check mount states via initramfsMountStates <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8557>
<zyga> pedronis: it feels good, right? :)
<ijohnson> I pressed the button
<mup> PR snapd#8599 closed: tests: port interfaces-audio-playback-record to session-tool <Test Robustness> <Created by zyga> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8599>
<zyga> \o/
<zyga> I will read it on my way back
<zyga> will be heading back home soon
<mvo> pedronis: merged, sorry for the delay
<mup> PR snapd#8537 closed: store: handle error-list in fetch-assertions results  <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8537>
<pedronis> mvo: thanks, I need to deconflict the next one now
<mup> PR snapd#8597 closed: tests: port user-mounts test to session-tool <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8597>
<mup> PR pc-amd64-gadget#46 opened: gadget.yaml: bump edition <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/46>
<ijohnson> mmm should we be installing snap-failure service on systems that only have the core snap ?
<ijohnson> mvo: pedronis: should we have the snapd.failure service when only the core snap (or only the snapd distro pkg) is installed (and thus no snapd snap?)
<ijohnson> seems like `snap-failure snapd` just no-ops if there is no snapd snap installed, so probably yes it seems
<mup> PR snapcraft#3102 closed: build providers: prevent snap refreshing in build environment <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3102>
<mup> PR snapcraft#3104 closed: packaging: use git-based versioning for python package <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3104>
<cachio> cmatsuoka, hey
<cachio> cmatsuoka, for testing pi3 with uc20 do we need to use the model signed by canonical?
<cachio> or we can use a model signed by me?
<cmatsuoka> cachio: afaik you can use your model
<cachio> ah, ok
<cachio> cmatsuoka, I wanted to make sure it was not going to produce an problem with tpm/secboot
<cmatsuoka> we don't have it in arm yet so you'll install unencrypted
<cachio> cmatsuoka, good
<ijohnson> cachio: we also have dangerous models signed by canonical you can use too
<cmatsuoka> well unless you have an arm board with tpm, but we never tested that
<cachio> ijohnson, yes
<cachio> I'll test new images signed by me first
<cachio> then canonical
<jdstrand> ijohnson: I think I fixed your serial-port issue (see the bug)
<ijohnson> jdstrand: nice! I was going to look at pawel's response and ping you about it but you saw it first, thanks!
<ijohnson> jdstrand: re: including the snapd snap type, I'm not sure, on your system you tested it are you using the snapd snap?
<jdstrand> ijohnson: it isn't installed, no
<ijohnson> I have it installed, let me see if your new declaration works
<ijohnson> jdstrand: it seems to have auto-connected anyways
<jdstrand> I just installed it and am trying
<jdstrand> the slot comes up as snapd:ft232serialuartic
<ijohnson> yes I see snapd:unor3cdcacm but it still auto-connected
<jdstrand> serial-port             arduino:serial-port      :ft232serialuartic                -
<jdstrand> but it connected
<jdstrand> ok. as it happens, a different store bug prevents me from specifying 'snapd' for slot-snap-type, so, glad this worked :)
<ijohnson> jdstrand: and just to double confirm, when I disconnect the raw-usb interface and just use the serial-port hotplug interface I can upload a sketch / use the serial-port for the arduino and it works perfectly
<ijohnson> and then disconnecting the serial-port hotplug interface, it no longer is able to upload
<ijohnson> so this looks to "just work" when the declaration is good :-)
<ijohnson> thanks jdstrand
<jdstrand> ijohnson: np. sorry for the bug and thanks for reporting it. fyi, I commented on the 'snapd' slot-snap-type bits in the bug
<ijohnson> no problem, happy to know that it was an easy thing to fix :-)
<jdstrand> indeed! :)
<ijohnson> I'm sure galgalesh will be happy as well (not sure if they are on IRC or not)
<mup> PR snapd#8539 closed: tests: update encrypted partition creation test <UC20> <â Blocked> <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/8539>
<mup> PR core20#52 opened: Makefile: only use focal from now on for core20 <Created by xnox> <https://github.com/snapcore/core20/pull/52>
<mup> PR core20#51 closed: Makefile: updated now that focal is released <Created by mvo5> <Closed by xnox> <https://github.com/snapcore/core20/pull/51>
<mup> PR core20#52 closed: Makefile: only use focal from now on for core20 <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core20/pull/52>
<mup> PR core20#46 closed: static: add new handle_writable_defaults() to handle-writable-paths <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/core20/pull/46>
#snappy 2020-05-06
<mborzecki> morning
<mvo> zyga, mborzecki: good morning
<mborzecki> mvo: hey
<mup> PR snapd#8600 closed: tests: run smoke test with different bases <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8600>
<mborzecki> mvo: pinged you in some prs
<mvo> mborzecki: yeah, saw it in the first, will look for the others now :)
<mborzecki> ok
<mborzecki> maybe we should just make those pulseaudio tests manual
<mborzecki> mvo: this one too https://github.com/snapcore/snapd/pull/8562
<mup> PR #8562: store: implement DownloadAssertions <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8562>
<mup> PR snapd#8562 closed: store: implement DownloadAssertions <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8562>
<pstolowski> morning
<zyga> Good morning
<mvo> pstolowski: hey, good morning
<mborzecki> zyga: pstolowski: hey
<mup> PR snapd#8557 closed: c/snap-bootstrap: check mount states via initramfsMountStates <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8557>
<mborzecki> zyga: did you get a link to activate your suse account?
<mup> PR snapd#8436 closed: configcore,tests: use daemon-reexec to apply watchdog config <Squash-merge> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8436>
<zyga> mborzecki: checking
<zyga> hmm
<zyga> no?
<zyga> I got an email earlier
<zyga> about the new account system
<zyga> mborzecki: I _hope_ that with the current changes the pulseaudio tests will no longer fail this way
<zyga> now that both tests kill PA reliably via systemd
<zyga> remarkable little failures
<zyga> >0 but usually just one
<zyga> and a pretty short quuee
<zyga> hmmm
<zyga> upgrade/basic
<zyga> - Download snap "core" (9066) from channel "stable" (read tcp 10.240.0.214:45966->91.189.88.179:443: read: connection reset by peer)
<zyga> eh, just network woeas
<zyga> *woes
<zyga> https://github.com/snapcore/snapd/pull/8571 is super-simple and needs a 2nd review
<mup> PR #8571: overlord/snapstate: warn of refresh/postpone events <Created by zyga> <https://github.com/snapcore/snapd/pull/8571>
<zyga> just warnings behind an experimental flag (though the flag is check in the code that is not in the diff)
<mup> PR snapd#8571 closed: overlord/snapstate: warn of refresh/postpone events <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8571>
<mup> PR pc-amd64-gadget#46 closed: gadget.yaml: bump edition <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/46>
<zyga> \o/
<zyga> thank you mvo!
<mborzecki> https://github.com/snapcore/snapd/pull/8563 needs a 2nd review, pstolowski maybe you cuold take a look, since we both reviewed the other bulk assertions PRs? :)
<mup> PR #8563: asserts/internal: introduce Grouping and Groupings <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8563>
<mup> PR snapd#8603 opened: tests: pair of follow-ups from earlier reviews <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8603>
<pstolowski> mborzecki: yes absolutely, i meant to, thanks
<pstolowski> ok :)
<zyga> huh
<zyga> gnome 3.36.2 has this changelog entry
<zyga> - Reenable TLS 1.0/1.1 protocols due to COVID-19.
<zyga> !??!
<pedronis> mvo: pstolowski: hi, #8602 will need to be cherry picked for 2.45, right?
<mup> PR #8602: configcore: only reload journald if systemd is new enough <Created by stolowski> <https://github.com/snapcore/snapd/pull/8602>
<mvo> pedronis: it looks like it, yes
<pedronis> mvo: I put the milestone on it
<zyga> pedronis: I requested your review on https://github.com/snapcore/snapd/pull/8566 -- it is the principal part of the refresh-app-awareness that is yet to be designed
<mup> PR #8566: cmd/cmdutil: add run inhibition operations <Created by zyga> <https://github.com/snapcore/snapd/pull/8566>
<zyga> this PR contains my take on the idea
<pedronis> ok, I probably need to look at older PRs first... hopefully I can go back doing some reviewing later today
<zyga> ok
<zyga> if you want to talk about it apart from the review and have some time just ing me
<zyga> *ping me
<zyga> I have enough to work on that it is not a problem
<zyga> (not urgent)
<zyga> having an idea for next week would be brilliant
<pstolowski> pedronis, mvo: yes
 * zyga reboots to unbreak his touchpad :/
<zyga> Those ThinkPads....
<zyga> re
<mborzecki> Those touchpads :P
<mborzecki> zyga: pedronis: when is the desktop sync meeting? can you invite me in case we discuss the fonts issue?
<mborzecki> s/pedronis/mvo/ ^^
<zyga> IIRC tomorrow
<zyga> let me check
<zyga> note, the meeting tomorrow is the code review sync
<zyga> invited you
<mborzecki> zyga: thanks!
<pedronis> zyga: fwiw, pulseaudio failed again here: https://github.com/snapcore/snapd/pull/8563/checks?check_run_id=648645627
<mup> PR #8563: asserts/internal: introduce Grouping and Groupings <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8563>
<pedronis> with master from this morning
<zyga> looking
<zyga> hmmm, interesting
<zyga> I was adding some precondition code
<zyga> but perhaps something else is going on here: look that we check for the socket first
<zyga> and initially it is not there
<zyga> then it shows up
<zyga> pulseaudio --check looks if the daemon is there
<zyga> but does not connect to it IIRC
<zyga> thanks, let me try something and I'll send a PR shortly
<zyga> it reads /run/user/UID/pulse/pid
<zyga> so perhaps we are socket activated but not really running
<zyga> pedronis: I have the logs now, feel free to restart or override
<pedronis> mvo: did you squash merge the watchdog one? it had the label
<mvo> pedronis: yeah, I overlooked it and realized when pressing merge :(
 * mvo is a muppet
 * zyga hugs mvo
<mup> PR snapd#8604 opened: interfaces/builtin/desktop: do not mount fonts cache on distros with quirks <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8604>
<pedronis> mvo: we need to ping Taipei when it's in edge
<mvo> pedronis: I added a comment to the bugreport asking for testing
<mvo> pedronis: I can also add it to the sync doc
<pedronis> thx
<mvo> pedronis: added to the sync doc as well, if we need to revert I will take care of this (to make up for my blunder to not squash it)
<pedronis> let's see how it goes
<zyga> fascinating :)
<zyga> some seriously weird stuff is happening
<zyga> so I ran the pulseaudio test and tweaked the prepare section a little
<zyga> no other tests, no other stuff
<zyga> on *some* runs pulse starts and works
<zyga> on some runs pulse starts, dies and cannot recover
<zyga> starting it again fails
<zyga> I have a debug shell, can strace and stuff
<zyga> just wondering what the real issue is
<mborzecki> zyga: i have a fascinating story to share, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1876583 i can reproduce it in a terminal that has 80 colums, with that specific locale, because the unicode messages add up to fewer bytes than expected
<mup> Bug #1876583: "panic: runtime error: slice bounds out of range" while installing any snap package <amd64> <apport-bug> <focal> <snapd (Ubuntu):In Progress by maciek-borzecki> <https://launchpad.net/bugs/1876583>
<zyga> heheh
<zyga> are we slicing utf-8 by bytes?
<mup> PR snapd#8603 closed: tests: pair of follow-ups from earlier reviews <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8603>
<mborzecki> zyga: i think the translation is wrong, not what we expected
<mborzecki> mvo: zyga: where are the non-packed translations for snapd?
<zyga> dunno
<zyga> what do you mean by non-packed?
<zyga> probably in rosetta
<zyga> but just guessing
 * zyga tests a fix for pulseaudio tests
<zyga> and I suspect I know why it passed sometimes too
<zyga> the long story short is that pulse quits when idle
<zyga> it starts up on specific request (socket activated)
<zyga> and just quits
<zyga> the two sanity chceks up front are checking the socket and the service
<zyga> and if fast enough, pulse is still running after starting the session
<zyga> (it takes a moment to start and quick)
<zyga> *quit
<zyga> so the solution is just not to run pulseaudio --check
<mborzecki> #. TRANSLATORS: this needs to be a single rune that is understood to mean "minutes" in e.g. 1m30s
<mborzecki> msgid "m"
<mborzecki> msgstr "ÑÐ²"
<mborzecki> heh
<mborzecki> so this breaks our message/column calculation
<jamesh> and the translator probably said "what on earth is a rune?"
<mborzecki> nevertheless, we shouldn't panic :P
<mvo> mborzecki: nice
<mvo> mborzecki: also this requirement that it needs to be a single rune is silly, I mean, do we know that it always is in all the languages :) ?
<mvo> mborzecki: (not your fault of course, just saying)
<mborzecki> mvo: well, yeah agreed ;)
<mvo> mborzecki: thanks for looking into this!
<mvo> jamesh: lol, indeed
<zyga> pedronis: https://github.com/snapcore/snapd/pull/8605 fix for what you reported
<zyga> mborzecki: ^ fun
<mup> PR #8605: tests: fix racy check for pulseaudio activity <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8605>
<mup> PR snapd#8605 opened: tests: fix racy check for pulseaudio activity <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8605>
<zyga> mborzecki: you need to adjust spread test in the fix for fonts https://github.com/snapcore/snapd/pull/8604/checks?check_run_id=648902472
<mup> PR #8604: interfaces/builtin/desktop: do not mount fonts cache on distros with quirks <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8604>
<mborzecki> aah right
<jamesh> zyga: I've left a comment on your PA PR
<zyga> thanks, looking
<zyga> jamesh: replied
<jamesh> zyga: waiting for default.target would probably be worthwhile, yeah.
<zyga> yeah, let's do it
<zyga> I will keep the check for "active" as a sanity check
<zyga> and add an extra patch that waits in prepare
<jamesh> zyga: you should be able to rely on the return value of "systemctl is-active" rather than needing the extra MATCH call
<zyga> jamesh: yeah, just more obvious what went wrong when it does fial
<zyga> though I guess the log would contain that as well
<zyga> hmm, default.target does not seem to be related to sockets
<zyga> perhaps I should wait for sockets.target as well?
<zyga> jamesh: something like this:
<zyga> https://www.irccloud.com/pastebin/qZYsG5ek/
<jamesh> zyga: probably.  That's the one I try to start in e.g. tests/main/snap-session-agent-service-control/task.yaml
<zyga> ah, indeed
<jamesh> zyga: actually, default.target should handle it
<zyga> I _suspect_ so but I've started both
<jamesh> default.target requires basic.target, which requires sockets, timers, and paths.target
<zyga> ah
<zyga> I can drop sockets then
<zyga> jamesh: please look again
<mborzecki> heh, that fix isn't as simple as i thought
<zyga> mborzecki: isn't that my line? :D
<zyga> nothing is
<jamesh> zyga: looks good!
<zyga> thanks!
<zyga> quite a journey to test session-level user code
<jamesh> zyga: fwiw, I think the session-tool changes have made the tests in my user-daemons PR more reliable.  I'm still seeing an occasional failure where connecting to the session agent socket fails, but that seems less common too
<zyga> jamesh: do you have an idea why that could be the case?
<jamesh> zyga: sadly no.  I've added some extra debug output, but I'm not sure what the cause was.
<zyga> ok
<zyga> well, little by little :)
<zyga> I think we made a lot of progress
<zyga> apart from gradual growth of reliability
<zyga> writing tests is actually easier
<zyga> less mucking with environment varibales, chown, quoting su -l ... test correctlyt
<jamesh> zyga: I thought it might have been a stray session from a previous test, but you fixed things to shut down the user slice
<zyga> yeah
<zyga> it's a surprise it doesn't shut down though
<zyga> so many weird things across releases of systemd
 * zyga -> afk
<mup> PR snapd#8606 opened: progress: fix progress bar with multibyte duration units <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8606>
<mborzecki> mvo: ^
<mvo> mborzecki: nice
<mup> PR snapcraft#3108 opened: tools: install wheel in snapcraft-dev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3108>
<cmatsuoka> niemeyer: could you have a look at https://github.com/snapcore/spread/pull/104 when you have time? it's needed for the encrypted partition creation tests on gce
<mup> PR spread#104: Adding option for systems created on google to start with secure boot enabled <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/104>
<zyga> re
<cmatsuoka> cachio: could you have a look at the error message mvo reported in https://github.com/snapcore/snapd/pull/8551? it seems that we have an unsupported system error there
<mup> PR #8551: snap-bootstrap: remove create-partitions and update tests <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8551>
<cmatsuoka> (is it caused by the still missing spread PR?)
<cachio> cmatsuoka, I know the  problem
<zyga> kenvandine: hey, is there any plan to surface snap warnings to the user in a desktop session?
<cachio> cmatsuoka, in nested.sh
<cachio> in functinos get_google_image_url_for_nested_vm and get_ubuntu_image_url_for_nested_vm
<cachio> plase add a * at the end of any system
<cachio> cmatsuoka, I can fix it otherwise
<cachio> as you prefer
<cmatsuoka> cachio: the name would become ...-.img*?
<cachio> cmatsuoka, no
<cmatsuoka> or ...*.img?
<cachio> ubuntu-16.04-64) -> ubuntu-16.04-64*)
<cmatsuoka> ah, got it
<cmatsuoka> thanks
<cachio> for all the systems in both functinos
<cachio> cmatsuoka, yaw
<mup> PR snapd#8607 opened: tests: remove user.sh <Created by zyga> <https://github.com/snapcore/snapd/pull/8607>
<mup> Bug #1876482 changed: There is no way to trace the upgrade history of a snap <Snappy:Invalid> <https://launchpad.net/bugs/1876482>
<cmatsuoka> degville: this is the line I use for non-encrypted installs (it's a stripped down version of the other one, possibly it can be further reduced): https://pastebin.ubuntu.com/p/8tfnS642yM/
<cmatsuoka> (smp 4 because I have a lot of cpus, the typical user will probably want smp 2)
<degville> cmatsuoka: thank you! perfect.
<mup> PR snapd#8608 opened: configcore: issue a warning on core16 when journal.persistent option is set <Created by stolowski> <https://github.com/snapcore/snapd/pull/8608>
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8608/files#r420780119
<mup> PR #8608: configcore: issue a warning on core16 when journal.persistent option is set <Created by stolowski> <https://github.com/snapcore/snapd/pull/8608>
<pstolowski> zyga: thanks!
<zyga> ijohnson: could you look at https://github.com/snapcore/snapd/pull/8605/commits/e3f01f69bb67376ac0f9065493b31d9e4efcd3f0 -- it's a part of thet fix but I pushed it after you approved
<mup> PR #8605: tests: fix racy check for pulseaudio activity <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8605>
<ijohnson> sure
<zyga> the *essential* change is https://github.com/snapcore/snapd/pull/8605/commits/e3f01f69bb67376ac0f9065493b31d9e4efcd3f0#diff-a8fce2de6a6829d98f798117050b6c93R134 line
<zyga> everything else is the consequence of that
<kenvandine> zyga: we haven't really put any thought into that
<zyga> hey!
<kenvandine> zyga: got an example?
<zyga> sure
<zyga> one main example is the warnings we show when an app was not refreshed when it was open
<zyga> and when it got refreshed despite being open
<kenvandine> ah
<zyga> but as we just stared to use warnings now, there will be many more
<kenvandine> well that is something there are plans for
<zyga> we *could* convert those two to special events that are handled differently as well
<zyga> just wanted to start a conversation about it
<kenvandine> the whole "firefox needs a refresh, do you want to restart to refresh now?"
<zyga> not quite, that's not what this is
<zyga> what you describe is more like an interacting application that is snap aware
<zyga> let's say gimp is snapped
<zyga> and it has a refresh
<zyga> and we just tried but postponed it because you had gimp open
<zyga> without gimp being snap aware, we emit a warning
<zyga> now that warning shows up in command line
<zyga> when you interact with "snap" in any way
<zyga> that's the context
<zyga> you *can* see this today on edge
<zyga> just run an app, switch to a different channel and refresh
<zyga> (with refresh app awareness enabled)
<zyga> kenvandine: so in my naive thought
<zyga> I had two ideas
<zyga> 1) we could show a desktop notification that just goes away
<zyga> it's a one off it flies off
<zyga> but you see it (if you look at the screen)
<zyga> 2) we could show them in gnome-software
<zyga> bonus points for showing this in the context of a particular app
 * roadmr awards zyga ð¯  bonus points ð¾
<zyga> woot :)
 * zyga notices his ideas left people speechless ;-)
 * zyga -> lunch
<kenvandine> zyga: we're looking to monitor snapd for those refresh warnings and provide a notification with a button to restart the app.  This way the app doesn't need to know how to talk to snapd
<kenvandine> we could surface other warnings the same way, perhaps with a different action attached.
<pstolowski> pedronis: mind if i merge master into #8564?
<mup> PR #8564: asserts: introduce Pool <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8564>
<pedronis> pstolowski: no
<mup> PR snapd#8607 closed: tests: remove user.sh <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8607>
<zyga> thank you
<zyga> mvo: after https://github.com/snapcore/snapd/pull/8605 we will have much less red PRs
<mup> PR #8605: tests: fix racy check for pulseaudio activity <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8605>
<zyga> just a little more :)
<zyga> brb
<mvo> zyga: nice one
<mup> PR snapd#8609 opened:  Adds missing paths to desktop, solves lp:1876804 <Created by sklei4> <https://github.com/snapcore/snapd/pull/8609>
<mup> PR snapd#8601 closed: Adds missing paths to apparmor, solves lp:1876804 <Created by sklei4> <Closed by sklei4> <https://github.com/snapcore/snapd/pull/8601>
<mvo> pedronis: 8563 has two +1, should I merge or do you want to push the tweaks to it (some style suggestions in there)?
<pedronis> mvo: please merge, I can do the tweaks in a follow up or the follow up, depending
<cachio> ijohnson, hey, did you have this issue with pi image https://paste.ubuntu.com/p/f6C5BD9NK8/ ?
<mup> PR snapd#8563 closed: asserts/internal: introduce Grouping and Groupings <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8563>
<ijohnson> cachio: how big is the SD card ?
<cachio> ijohnson, 32GB
<ijohnson> cachio: how big is the image you are trying to write?
<cachio> 8GB
<ijohnson> hmm I have only see that issue with no space left on device when the SD card is physically too small
<ijohnson> cachio: maybe try deleting all partitions on the SD card first before flashing?
<cachio> ijohnson, I already did it
<ijohnson> cachio: does it happen everytime for you that it fails to write with No space left on device ?
<cachio> ijohnson, first time trying to write a core 20 image for a pi3
<ijohnson> cachio: I'd say just try again, I don't know why that would happen for you
<cachio> I'll download another image
<cachio> ijohnson, I see the problem
<cachio> the systemd detects my sdcard as it'd have 3.3GB
<cachio> instead of 32GB
<cachio> not sure why
<cachio> it is doing the same with all mys cards
<zyga> there's one more race in that pulse test
<zyga> pulse server writes the cookie
<zyga> but we race trying to read it
<zyga> I fixed that locally, will push in a while
<ijohnson> cachio: ahh that's weird
<pedronis> pstolowski: I tried to answer your questions in the review
<pstolowski> pedronis: thanks, checking
<zyga> ijohnson: I pushed to https://github.com/snapcore/snapd/pull/8605 again, to fix one more race
<mup> PR #8605: tests: fix racy check for pulseaudio activity <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8605>
<zyga> ijohnson: explained in the commit message
<ijohnson> I haven't had a chance to look at it, it will be a while before I can look at it today unfortunately
<ijohnson> need to get uc20 things in order asap for the beta
<zyga> ijohnson: this test keeps on giving but it also shows us that ~test matters
<zyga> ijohnson: specifically, one test can leave home data that is relevant (as in, influences) another test
<zyga> ijohnson: no worries, thank you
<zyga> ijohnson: I will merge it iff it is green
<zyga> ijohnson: and will happily iterate on feedback
<zyga> just because red master is a disaster
 * zyga EODs
<pstolowski> mvo: do you think you could merge https://github.com/snapcore/snapd/pull/8520 directly (see my comment there re cla-check)
<mup> PR #8520: data: fix shellcheck warnings in snapd.sh.in <Created by jelovac> <https://github.com/snapcore/snapd/pull/8520>
<zyga> weird apt error https://www.irccloud.com/pastebin/y0zj5y5y/
 * zyga bangs his head against pulseaudio wall
<mvo> pstolowski: looking (sorry, was in meetings)
<pstolowski> np, ty
<mup> PR snapd#8610 opened: many: use /run/mnt/data over /run/mnt/ubuntu-data for uc20 <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8610>
 * cachio lunch
<zyga> re
<zyga> test leakage is the bane of our testing stack
 * ogra hands zyga a bucket
<zyga> and a mop
<ogra> oh, i had hoped i was in time for not needing that ... didnt notice your floor is full of leaked tests already :)
<zyga> one of those days where it's both leaks and tears
<ogra> oh my
 * ijohnson hugs zyga
<zyga> thanks :)
<zyga> I started my side server to have more spread slots while others have to re-start tests more often
<zyga> in the end we all learn, as a team
<ijohnson> I see you pushed some debug messages to your pulseaudio branch, should I review those ?
<zyga> yeah
<zyga> please have a look
<ijohnson> ok, cool
<zyga> my current working theory is that ~test/.config is root-owned
<zyga> and that this makes pulse start but not write the cookie
<zyga> which makes subsequent unconfined paplay fail
<ijohnson> well that's silly
<zyga> I found ~test/.cache/go-build is huge and left over by other tests
<zyga> in general, look at the commit messages please
<zyga> I need to try with -seed the next time it fails
<zyga> I entirely forgot about that
<zyga> it's not perfect because of job-stealing but it's better than random
<zyga> ijohnson: I stand by all prior commits that improve the test
<zyga> now some policykit test failed on something random
<zyga> er, package kit
<ijohnson> what do you mean by job-stealing ? for spread ?
<zyga> spread has a inherently indeterministic scheduler
<zyga> out of a pool of jobs, threads that are idle steal tasks to run
<zyga> so if server side timings are not identical, you don't get the exact same ordering
<zyga> it's not bad but it's not a guarantee to reproduce a failure
<ijohnson> interesting I didn't know that
<zyga> ijohnson: obviously, after adding the debug section, the tests pass
<zyga> heh
<ijohnson> hooray schrodenbug problem solved by looking at
<zyga> hehe
<zyga> 13 tests are in progress now
<zyga> so some chances to reproduce it
<tianon> anyone know whether "getent group foo" inside a snap environment will check /var/lib/extrausers/group appropriately? O:)  (my google-fu is failing me, and I'm not well-versed enough to easily test /o\)
<zyga> tianon: on a core system yeah, it should
<tianon> zyga: awesome, thank you! :D  (that makes my life easier)
<zyga> tianon: because /etc/nsswitch.conf has extrausers entries
<tianon> right, makes sense :)
<ijohnson> hey tianon o/
<tianon> ijohnson: hello :D  I bet you can imagine why I'm asking about snap-related things O:)
<ijohnson> I can indeed!
<ijohnson> let me know if I can be of any help
<tianon> for sure, thank you! <3
<ijohnson> :-)
<tianon> hopefully this bump is uneventful, but you know, interesting things happen when you run a containerization platform inside a container, so who knows where we're headed xD
<ijohnson> tianon: yes, hopefully uneventful
<ijohnson> tianon: also btw I was meaning to ask you about a different project of yours, gosu, would you accept a patch to gosu to make it work with extrausers so we can use it on ubuntu core devices from inside snaps ?
<tianon> ijohnson: really curious about the use case there -- you've got root inside the snap to do some initial setup and want to use gosu to step down after startup like is commonly done in Docker land?  or something more esoteric?
<ijohnson> tianon: basically yes, we have now some support for dropping to users, specifically to the snap_daemon user, but the catch is that you have to use setgroups(...,NULL), which libc does not, and so to use standard linux tools you need to patch them or do a LD_PRELOAD hack to get it to work
<ijohnson> tianon: gosu however doesn't suffer from that problem, but it doesn't understand extrausers
<ijohnson> see https://snapcraft.io/docs/system-usernames for example
<zyga> ijohnson: btw, about https://github.com/snapcore/snapd/pull/8605
<mup> PR #8605: tests: fix raciness in pulseaudio test <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8605>
<zyga> you indicated you a review request there, is that something you still plan to carry on
<zyga> I'd like to merge it when green, just to expand the reach of the fixes so far
<ijohnson> zyga: yes hopefully this afternoon, but feel free to merge if it goes green before I get to it
<zyga> and to get more data from other runs as people develop and we  get more scheduling runs
<zyga> ok
<zyga> thanks!
<zyga> I'm happy to send follow-ups of any kind
<tianon> ijohnson: interesting :D  have you tried setpriv from util-linux (2.32.1-0.2+)?  it's pretty flexible, and is essentially gosu but more "standard" O:)
<ijohnson> tianon: iirc setpriv suffers from the same or a different problem and doesn't just work ootb
<ijohnson> tianon: anyways I have a patch to gosu I could propose, and Ialso started an issue with upstream libcontainer but it would be more work to make it work upstream libcontainer
<tianon> ijohnson: certainly open to further conversation -- maybe open the PR and we can discuss more there? :)
<tianon> (then the conversation / thoughts can be recorded more persistently :D)
<ijohnson> tianon: sure when I get some spare cycles I'll throw something up in GitHub
<tianon> :+1:
<zyga> ijohnson: I KNEW IT
<zyga> 2020-05-06T19:49:53.9291698Z May 06 19:49:53 may061928-848515 pulseaudio[52998]: Failed to create secure directory (/home/test/.config/pulse): Permission denied
<zyga> 2020-05-06T19:49:54.2159546Z + echo 'Files present in the test user'\''s home directory, that are owned by root'
<zyga> 2020-05-06T19:49:54.2160021Z Files present in the test user's home directory, that are owned by root
<zyga> 2020-05-06T19:49:54.2160438Z + test -d /home/test
<zyga> 2020-05-06T19:49:54.2160837Z + find /home/test -user root
<zyga> 2020-05-06T19:49:54.2160999Z /home/test/.local
<zyga> 2020-05-06T19:49:54.2161142Z /home/test/.local/share
<zyga> 2020-05-06T19:49:54.2161313Z /home/test/.local/share/applications
<zyga> 2020-05-06T19:49:54.2161455Z /home/test/.config
<ijohnson> haha wow that's broken
<zyga> I'll find the guilty test tomorrow
<zyga> small fix to unbreak master
<ijohnson> when every day we have to land multiple small fixes to unbreak master are they really small anymore
<ijohnson> and is master really "master" at that point
<ijohnson> clearly something else is in control at this point
<zyga> ijohnson: pushed
<zyga> ijohnson: and EOD
<zyga> and tomorrow I just, dunno, sleep longer
<zyga> see you :)
 * zyga waves
<ijohnson> see you
<zyga> cmatsuoka, ijohnson: please merge master / rebase rather than retrigger
<zyga> it's merged!!!
<cmatsuoka> zyga: \o/
<ijohnson> hooray
<mup> PR snapd#8605 closed: tests: fix raciness in pulseaudio test <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8605>
<ijohnson> zyga: also what do you mean merge master rather than retrigger ?
<zyga> I often retrigger tests
<zyga> just to roll the dice again
<zyga> if you merge master *this* particular failure can hopefully go away for good
<cmatsuoka> merged and pushed a couple of branches, let's see what happens... :)
<zyga> thanks!
<zyga> I pushed to one of mine
<zyga> one of my? or one of mine?
<cmatsuoka> mine I guess
<cjwatson> one of mine, yes
<cmatsuoka> dinner time! will be back to see what happened to the PRs...
<cmatsuoka> zyga: yay, it worked
 * cmatsuoka EODs
#snappy 2020-05-07
<mup> PR core20#53 opened: Add secureboot-db <Created by xnox> <https://github.com/snapcore/core20/pull/53>
<mup> PR snapd#8611 opened: tests: not fail when boot dir cannot be determined <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8611>
<mborzecki> morning
<jamesh> Wow.  I've got a green tick on PR 5822
<mup> PR #5822: wrappers: allow user mode systemd daemons <:birthday:> <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5822>
<mborzecki> wow, that PR is old :P
<jamesh> zyga's session-tool work has made the tests a lot more reliable
<mborzecki> eagerly waiting for something else to break, at times it really feels like we're only maintaining the ci system
<mborzecki> quick errand, back in 30
<mup> PR snapd#8610 closed: many: use /run/mnt/data over /run/mnt/ubuntu-data for uc20 (2.45) <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8610>
<zyga> jamesh: woot
<zyga> :-)
<jamesh> zyga: needed a minor change to session-tool to get things working on 16.04
<zyga> Good morning everyone
<zyga> Cool, what was it?
<jamesh> zyga: "session-tool --has-session-systemd-and-dbus" returns false on 16.04, yet it has a working user instance of systemd
<jamesh> you don't need a systemd controlled session bus to talk to systemd
<zyga> Ah, bit that is real
<zyga> You indeed a package installed
<zyga> Some of our tests do that
<zyga> Dubs-user-session or something like that
<zyga> Dubs-session-bus maybe
<zyga> After you install that package, session to gives you a green light
<jamesh> zyga: try running "strace --trace=connect systemctl --user status default.target" locally, and find out where it connects to the session bus :-)
<zyga> Where does it connect?
<jamesh> a socket at "$XDG_RUNTIME_DIR/systemd/private", which talks directly to the systemd instance
<zyga> Iirc the package ships usr lib systemd user dbus.socket
<jamesh> yes, but "systemctl --user" doesn't rely on it
<zyga> Oh. Interesting
<zyga> But we kind of do, you donât get the environment variable without it
<jamesh> and it just so happens 16.04 is a system where it makes a difference
<zyga> I worked kind of late yesterday
<zyga> Iâll wake up and gladly look at changes
<jamesh> zyga: Here's the change I made: https://github.com/snapcore/snapd/pull/5822/commits/043ba49f8f95d5111875f99e34425e52674c88cd
<mup> PR #5822: wrappers: allow user mode systemd daemons <:birthday:> <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5822>
<jamesh> it's sitting at the tail end of my user-daemons PR at the moment
<jamesh> I can cherry pick it out into an independent PR, but my preference would be to just land user-daemons :-)
<zyga> Does it pass on centos-8
<zyga> 7
<jamesh> It passed everywhere
<zyga> Mmmm
<jamesh> I'm doing a "systemctl --user is-enabled default.target" call first, which should only fail if we can't talk to systemd
<zyga> The reason I ask is that centos 7 disabled systemd âuser explicitly
<zyga> Ahh
<zyga> Perhaps that is the trick then
<zyga> Cool
<zyga> Looking forward to having this all merged :-)
<jamesh> if there is a simpler availability check, we can use that
<zyga> I need a coffee though
<zyga> Few hours of sleep today
<zyga> Iâm very happy all this work is paying off
<mborzecki> re
<mborzecki> zyga: i'm glad it's seems to be working now, but i'm also amazed how complicated user session setup is
<pstolowski> morning
<mborzecki> makes me wonder whether it really has to be that complicated
<mborzecki> pstolowski: hey
<mvo> good morning pstolowski
<mvo> and morning to mborzecki and zyga  :)
<zyga> mborzecki: I can gladly pass the baton
<mborzecki> zyga: nah, thanks :)
<zyga> at my desk
<zyga> green ticks
<zyga> not everyone
<zyga> but man :)
<zyga> call me eco-friendly ;D
<zyga> mvo: I worked to like 2AM
<zyga> mvo: I kind of feel tired today
<zyga> I will probably just attend meetings
<zyga> and not do much meanwhile
<zyga> maybe push some small fixes
<zyga> and two claudio's branches are green too
<jamesh> mborzecki: just wait until we try to set up a working user session on a real Ubuntu Core system, rather than just in the test environment...
<zyga> mborzecki: rebase / merge master
<zyga> :D
<zyga> jamesh: btw, did you notice that core 20 seems to have everything required for user services already?
<jamesh> zyga: more so than core18?
<zyga> yes
<zyga> check this out
<zyga> https://github.com/snapcore/snapd/blob/master/tests/main/session-tool-support/task.yaml
<zyga> core 20 ships /lib/systemd/user/dbus.socket
<jamesh> zyga: ah. I agree that makes a difference for D-Bus services, yes :-)
<jamesh> user services are working all the way back to core16
<zyga> indeed
<zyga> jamesh: one relevant aspect that I didn't explain properly before
<zyga> because I was typing from a phone
<zyga> was that dbus.socket unit injects DBUS_SESSION_BUS_ADDRESS into session environment
<zyga> and .e.g. snap run checks for it
<zyga> so it's plausible that other programs also check for it
<zyga> and not fall back to other locations
<zyga> but in general, having dbus in the session is desired
<jamesh> definitely
<jamesh> and maybe in a year we can pretend that it is always true
<jamesh> once 16.04 goes EOL
<zyga> jamesh: well, that 10 year support probably means my kids can gro up to become engineers and support it
<mborzecki> hahah
<zyga> (for the record, my son is almost 14 now)
<jamesh> neither the desktop or snapd were included in 14.04's ESM
<jamesh> snapd might not be so lucky for 16.04, but you might not need to care about desktop sessions there any more
<zyga> jamesh: so about that
<zyga> there's some discussion to extend session-tool to 14.04
<zyga> so that we have better coverage
<zyga> I _might_ just do it
<jamesh> there's no user instance of systemd on 14.04, so it will probably look like CentOS 7
<zyga> I was thinking about emulating all the upstart-goodies there
<zyga> so not based on systemd
<zyga> but stil following PAM
<zyga> and doing "something" that is representative
<pedronis> the agreement on 14.04 is mostly livepatch should install and work
<zyga> mmm, I see
<zyga> maybe it's just not worth it then
<pedronis> afaiu no
<mup> PR snapd#8606 closed: progress: fix progress bar with multibyte duration units <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8606>
<mborzecki> yay
<zyga> see you at the code review meetign!
<zyga> *meeting
<pedronis> mvo: I did a pass on #8334
<mup> PR #8334: many: add core.resiliance.vitality-hint config setting <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8334>
<mvo> pedronis: \o/ thank you
<mup> PR snapd#5822 closed: wrappers: allow user mode systemd daemons <:birthday:> <Needs Samuele review> <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5822>
<mup> PR core20#53 closed: Add secureboot-db <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/core20/pull/53>
<zyga> I identified and fixed the tests that were breaking the pulseaudio test before
<zyga> it was the portal and xdg-open tests
<zyga> they created ~test/.config as root
<zyga> and that was enoguh
<zyga> I'll send patches shortly
<Mirv> hi I'm once again searching for bug which may or may not be a bug.. after Tumbleweed upgrade to GNOME 3.36 on two machines, the other one is missing snap in XDG_DATA_DIRS and also missing snap_bin_path and snap_xdg_path - what should be setting those? and I wonder if there's anything that could be made bullet proof regarding setting them.
<zyga> Mirv: hello
<Mirv> I can obviously workaround by setting the missing parts manually
<zyga> those are set by IIRC the environment generator
<zyga> (systemd env generator)
<zyga> Mirv: do you have ...
<zyga> Mirv: /usr/lib/systemd/system-environment-generators/snapd-env-generator
<Mirv> yes I have on both machines. I'm doing random grepping but not finding differences between the machines yet
<zyga> mborzecki: ^
 * zyga needs to go afk for a moment
<mborzecki> zyga: snapd-env-generator is for services iirc
<zyga> what? why?
<pedronis> pstolowski: is #8533 really just the test?  does it need  master merge?
<mup> PR #8533: image, tests: core18 early config test <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>
<mborzecki> zyga: for user sessions there's systemd-environment-d-generator
<mborzecki> zyga: and as for why, i have no clue ;)
<mborzecki> Mirv: does /usr/lib/environment.d/990-snapd.conf exist in your system? does `systemctl --user show-environment | grep '^XDG_DATA_DIRS='` list /var/lib/snapd/desktop ?
<pstolowski> pedronis: ah, no, it's also actual image.go change, i will update the desc
<pedronis> pstolowski: ah, ok
<Mirv> mborzecki: exists on both, on the affected system however /var/lib/snapd/desktop is missing while on the working system it's there
<Mirv> (ie 990-snapd.conf exists on both)
<zyga> Mirv: any chance you are using zsh?
<Mirv> bash on both
<pedronis> pstolowski: maybe the configcore changes should be in their own PR?
<mborzecki> hmm looks like the issue we had on centos and rhel, where it worked in my vm, but didn't work in degville's
<degville> mborzecki: I think I'll try a fresh install and see what happens.
<pstolowski> pedronis: sure, i can extract them
<pedronis> pstolowski: if it's not too annoying
<pstolowski> pedronis: it shouldn't
<pedronis> thank you
<Mirv> anyway, the problem seems a bit more like systemd problem now that it is in environment.d correctly, not snap problem
<Mirv> erh... I noticed there is also 99-environment.conf symlink to /etc/environment , so out of interest I tried to copy-paste the content of 990-snapd.conf into /etc/environment and rebooted.. upon login, it seemed like I could not launch any apps, and no extensions were loaded. so I removed the lines from /etc/environment and rebooted again and... now, for some reason XDG_DATA_DIRS has the snapd dir!
<Mirv> maybe it's a systemd bug
<Mirv> before this I had used the system with multiple reboots since last week
<mborzecki> perhaps some race condition
<mborzecki> Mirv: is there a /usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator in your system?
<mborzecki> btw. noticed therels /usr/lib/systemd/user-environment-generators/60-flatpak that runs after, but it seems to be handling the XDG_DATA_DIRS path correctly
<mborzecki> Mirv: if you have that 60-flatpak file ^^ can you run `XDG_DATA_DIRS=/var/lib/snapd/desktop /usr/lib/systemd/user-environment-generators/60-flatpak` and make sure that output contains /var/lib/snapd/desktop path?
<Mirv> mborzecki: yes there is 30-systemd-environment-d-generator on both machines, and yes the output contains snapd/desktop path. but as said, after I made something error out by modifying /etc/environment and then reverting that change, now the /var/lib/snapd/desktop is correctly there also on this system that didn't have it for the past week, so I can't reproduce the problem anymore.
<Mirv> mborzecki: .. I rebooted again, and now the problem is again there .. still the output containts the desktop path
<Mirv> it's something causing the systemd not generate the environment correctly, quite consistently on this machine but not the other
<mborzecki> Mirv: are you using gdm?
<Mirv> mborzecki: yes
<mborzecki> Mirv: ok, can you `cat /usr/share/gdm/env.d/flatpak.env`?
<mborzecki> if it exists
<Mirv> -> XDG_DATA_DIRS=$HOME/.local/share/flatpak/exports/share/:/var/lib/flatpak/exports/share/:/usr/local/share/:/usr/share/
<mborzecki> Mirv: heh ok, can you mv that file to say $HOME for a bit, and then reboot/relogin?
<mborzecki> jamesh: are you familiar with gdm internals by any chance?
<jamesh> mborzecki: not deeply, but maybe I can help?
<mborzecki> jamesh: when the user session starts up, are env files from /usr/share/gdm/env.d/ applied, and if so would that happen to run after/before systemd user env generators?
<mup> PR snapd#8612 opened: sysconfig: use new _writable_defaults dir to create cloud config <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8612>
<mborzecki> jamesh: from the code i see it's in the worker https://github.com/GNOME/gdm/blob/2155ffa023d94fd269cf01d69d897ebe9a63a386/daemon/gdm-session-worker.c#L1633 but does it run when user logs in or is it only for the actual gdm process?
<mup> PR core20#54 opened: static: switch /etc/cloud from synced to persistent <Blocked> <Created by mvo5> <https://github.com/snapcore/core20/pull/54>
<jamesh> mborzecki: I'm not sure
<Mirv> mborzecki: I've moved that away and the problem is gone for at least two subsequent boots (more than ever before).. so maybe it's a race condition
<Mirv> anyway, I'll need to go now for a bit
<mborzecki> jamesh: hmm the call chain goes up to do_start_session() https://github.com/GNOME/gdm/blob/2155ffa023d94fd269cf01d69d897ebe9a63a386/daemon/gdm-session-worker.c#L2764
<zyga> I found and fixed a bug affecting all portals tests
<zyga> that should remove some more random failures
<zyga> two PRs to go though
<mborzecki> wtf is /usr/lib/systemd/user/dbus.service.d/flatpak.conf ? why are all 3 ways of injecting environment used by flatpak?
<zyga> lol
<zyga> what?
<mborzecki> at least 2 of those just override whatever is set via user env generators
<zyga> what's there?
<jamesh> are you sure it is only 3?
<mborzecki> # /usr/lib/systemd/user/dbus.service.d/flatpak.conf
<mborzecki> [Service]
<mborzecki> Environment=XDG_DATA_DIRS=%h/.local/share/flatpak/exports/share/:/var/lib/flatpak/exports/share/:/usr/local/share/:/usr/share/
<zyga> heh
<zyga> so kind
<mborzecki> jamesh: skipped pam_env since we know it's off limits :P
<jamesh> it's not using /etc/profile.d too?
<zyga> maybe we should file a bug?
<mborzecki> that file and /usr/share/gdm/env.d/flatpak.env just set XDG_DATA_DIRS
<jamesh> unilaterally overriding (rather than appending/prepending) is bad manners
<zyga> mborzecki: just ship aaa-snapd and zzz-snapd.conf
<zyga> and set it again
<mborzecki> also found this comment https://bugzilla.gnome.org/show_bug.cgi?id=766176#c11 there's like 4 possible scenarios how env is injected
 * zyga queues for the best tech solution award ;)
<zyga> jokes aside
<zyga> it's a bug
<zyga> and a bit eivl
<zyga> *evil
<jamesh> we've definitely had problems where the environment injection methods we thought we universal turn out not to be
<jamesh> they're probably just adding new ones as they find new corner cases
<mborzecki> we are seriously doomed
<mup> PR snapd#8613 opened: o/configcore: pass extra options to FileSystemOnlyApply <Created by stolowski> <https://github.com/snapcore/snapd/pull/8613>
<mborzecki> well the linux desktop is xD
<pedronis> zyga: I did a pass on #7825
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> pedronis: thank you!
<pedronis> zyga: I should look at 8566 next, is that right?
<zyga> yes please
<pedronis> ok, lunch first
<zyga> pedronis: the main remark about the transient unit code is that test tests will be probably 500+ lines and I just didn't want to do them all here (behind a feature flag) - the main innovation is being able to do the tests in the first place (but that has since landed to master)
<zyga> pedronis: I'm happy to do the tests in the same PR if people are ok with that
<pedronis> zyga: tbh, I think it makes more sense to split out the helper to meaningful packages and do the tests there
<pedronis> *helpers
<zyga> pedronis: sure, just tell me where
<pedronis> zyga: I made some suggestions in the comments
<zyga> pedronis: cmd/dbusutil? dbusutil top level... somewhere else?
<pedronis> zyga: I think some bits belong to systemd, some bits might belong to a dbusutil package
<pedronis> and some bits belong to sandbox/cgroup
<pedronis> the latter point is the more unclear
<pedronis> I have a comment with a question about it
<zyga> so should I split that into bits that can be discussed
<zyga> or do you suggest to continue in the branch, just iterating on the parts there
<zyga> (the branch has the advantage of having spread tests to check things end to end)
<mup> PR core20#55 opened: hooks: make systemd-modules-load depend on mounts at /usr/lib/{firmware,modules} <Created by anonymouse64> <https://github.com/snapcore/core20/pull/55>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8614
<mup> PR #8614: tests: don't create root-owned things in ~test <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8614>
<mup> PR snapd#8614 opened: tests: don't create root-owned things in ~test <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8614>
 * zyga needs to run an errand for his parents, I will probably miss standup as we need to drive around
<zyga> the portal tests are still not reliable, I found one more bug that is fixed locally
<zyga> but there is more, I just cannot understand why it fails
<pedronis> zyga: you can do the work in the branch and then split it, atm it has the problem that is both too big and not big enough (missing coverage, too much code directly in cmd_run.go)
<zyga> Ok, sounds good
<zyga> And I agree
<pedronis> mborzecki: mvo: seems #8464 can be merged
<mup> PR #8464: cmd/snap-boostrap, boot: use /run/mnt/data instead of ubuntu-data <Squash-merge> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8464>
<mvo> pedronis: thank you, merged
<mvo> pedronis: I updated the vitality-score PR
<mup> PR snapd#8464 closed: cmd/snap-boostrap, boot: use /run/mnt/data instead of ubuntu-data <Squash-merge> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8464>
<mborzecki> yay
<ijohnson> thanks folks
<ijohnson> and g'morning
<zyga> ijohnson: hey :)
<ijohnson> hey zyga
<ijohnson> I had a look at your session-tool pulseaudio PR that you merged last night, it all looked good to me
<zyga> ijohnson: I fixed that bugger and found the cause for the failure
<ijohnson> very nice
<zyga> https://github.com/snapcore/snapd/pull/8614
<mup> PR #8614: tests: don't create root-owned things in ~test <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8614>
<ijohnson> zyga: nice
<ijohnson> it feels good to see master very green
<zyga> it is not over
<zyga> I found two more bugs in portal tests
<zyga> fixed one
<zyga> investigated the other but cannot grok it yet
<zyga> race
<zyga> but cannot grok why
<zyga> but little by little :
<zyga> :)
 * mvo hugs zyga 
<mup> PR snapd#8615 opened: github: register the problem matcher in a separate step to running spread <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8615>
<mvo> thank you ijohnson and good morning as well :)
<ijohnson> o/ mov
<ijohnson> ah typing is hard
<ijohnson> o/ mvo
<zyga> oho
<zyga> kid invasion
<ogra> dont call ian a kid !
<zyga> I have a sleeping lucy hugging me now
<ijohnson> haha
<ijohnson> mborzecki: just noticed this unit test failure from one of my runs where I merged master: https://pastebin.ubuntu.com/p/RbzqwMKSbP/
<ijohnson> I'm a bit unclear what went wrong in the regex there, but it looks related to your change
<ijohnson> it came from https://github.com/snapcore/snapd/pull/8559/checks
<mup> PR #8559: boot, bootloader: adjust comments, expand tests <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8559>
<mborzecki> ijohnson: hmm yeah, 0B/s weird
<mborzecki> maybe something needs tweaking
<zyga> https://github.com/snapcore/snapd/pull/8602 is green
<mup> PR #8602: configcore: only reload journald if systemd is new enough <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8602>
<zyga> and +3
<zyga> pstolowski: ^^
<pstolowski> grea, and it's green finally
<mup> PR snapd#8602 closed: configcore: only reload journald if systemd is new enough <Squash-merge> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8602>
<mup> PR snapd#8616 opened:  progress: tweak multibyte label unit test data  <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8616>
<mborzecki> ijohnson: this should fix it ^^
<mborzecki> (or at least make it more robust)
<pedronis> cmatsuoka: hi, I wanted to review #8577 but it has conflicts atm
<mup> PR #8577: secboot,cmd/snap-bootstrap: move initramfs-mounts tpm access to secboot <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8577>
<cmatsuoka> pedronis: yes, I'm fixing the conflicts but then in a test installation broke for some reason, I'm checking with ian
<cmatsuoka> pedronis: I'm retesting installation with pure master now
<cmatsuoka> pedronis: resolved
<pedronis> thx
<cmatsuoka> pedronis: there's a handle type there I couldn't come with a good name for, suggestions welcome
<cachio> pstolowski, hi
<cachio> pstolowski, I see an error in preseed test https://paste.ubuntu.com/p/j5x2pHBH9m/
<ogra> have there been any snapd changes to make anything talk to avahi via dbus recently ?
<cachio> pstolowski, is it familiar for you?
<ogra> seems oSoMoN and I both see avahi denials for apps that did not have them before ... but funnily we see similar denials for different apps
<ogra> msg='apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/" interface="org.freedesktop.DBus.Peer" member="Ping" mask="send" name="org.freedesktop.Avahi" pid=431942 label="snap.chromium.chromium"
<ogra> (i see it for chromium, olivier for libreoffice ... neither app has used avahi before)
<zyga> chrome is pinging avahi
<ogra> zyga, well ... here it is
<ogra> seems for oSoMoN libreoffice is all of a sudden pinging avahi :)
<ogra> hmm, could that be portal integration stuff?
<oSoMoN> to be fair IÂ don't know whether it was doing it before, I never noticed but then again I'm not watching denials all day long
<ogra> i tend to have a terminal with journalctl -f while trying our new snaps or fixing something ... i dont run my logs regulary though, but every now and then ... and i thinnk i'D have noticed Avahi denials
<ogra> s/our/out/
<ogra> for me this is definitely new ... though i have only upgraded to focal end of last week
<ogra> perhaps it is focal related
<zyga> pedronis: updated https://github.com/snapcore/snapd/pull/8566
<mup> PR #8566: cmd/cmdutil: add run inhibition operations <Created by zyga> <https://github.com/snapcore/snapd/pull/8566>
 * zyga -> standupo
<zyga> standup even
<pstolowski> cachio: looks like deb is old and doesn't ship snap-preseed binary?
<mup> PR snapd#8615 closed: github: register the problem matcher in a separate step to running spread <Created by jhenstridge> <Closed by jhenstridge> <https://github.com/snapcore/snapd/pull/8615>
<mup> PR snapd#8617 opened: tests: new directory used to store the cloud images on gce <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8617>
<seb128> bah, don't use --gdb it screws up configs/application
<seb128> I just spent an hour figuring out my snap-store was b0rked because I tried to get a bt a few weeks ago
<seb128> (thanks Ken for helping debugging ;-)
<pstolowski> cachio: the preseed nested test fails because of these changes made recently to nested suite, where current snapd deb is not installed on the host. if you install it it will have snap-preseed command
<cachio> pstolowski, ah
<pstolowski> cachio: so solution is to install snapd.deb from /home/hopath
<pstolowski> *gopath
<cachio> is that part of a PR right?
<cachio> which is not merged yet?
<pstolowski> cachio: no
<cachio> ah, ok
<cachio> in that caase I'll add that to my current pr
<pstolowski> cachio: you probably confused it with another test that I've in a PR where I hit similiar problem
<cachio> pstolowski, right
<cachio> I'll fix that
<cachio> Could you please take a look #8558
<mup> PR #8558: tests: make the nested library usable independently of spread <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8558>
<cachio> pstolowski, I already included that
<pstolowski> cachio: ok
<cachio> pstolowski, I am running tests here
<cachio> pstolowski, I see error now https://paste.ubuntu.com/p/489MC2WnNw/
<cachio> seccomp-compiler-version is different
<pstolowski> cachio: yes
<mup> PR snapd#8618 opened: gadget: fix fallback device lookup for 'mbr' type structures <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8618>
<mborzecki> cmatsuoka: mvo: ^^ this will fix gadget updates to rev 100 of pc gadget
<mvo> mborzecki: do we need this in snapd beta for uc20 beta?
<mvo> mborzecki: also if that is a problem, why did we not see this earlier? also thanks for the fix :)
<mvo> mborzecki: if we need it for 2.45 then let's add a tag
<mborzecki> mvo: it'd be nice, otherwise if `update.edition:` is bumped again, the update will fail until one updates snapd first
<mborzecki> mvo: and we did not see this earlier because pc gadget started using assets update in rev 100, the spread test we have did not update mbr because if we screed that up the spread node would be inaccessible, and there was no unit test :)
<mborzecki> (or there was a unit test but not for this particular 'mbr' type)
<mvo> mborzecki: aha of course - that's fine then
<mvo> mborzecki: so not criticial for beta, that's good
<mvo> mborzecki: but nice to have
<mborzecki> mvo: verified this locally in qemu updating pc gadget from 96 -> 100
<mborzecki> (still wodnering whether updating the boostrap bit in mbr is a good idea)
<mborzecki> if this goes bad the chances of bricking the device is high
<pstolowski> cachio: i need to think about this test
<cachio> pstolowski, sure, thanks for checking it
<pedronis> jdstrand: hi, irrespective of detailed review, I think in https://github.com/snapcore/snapd/pull/8592 a more specific interface would be better, do you have (different) input on that?
<mup> PR #8592: Add initial support for the hardware-control interface <Created by devec0> <https://github.com/snapcore/snapd/pull/8592>
<mborzecki> hmm session agent unit test panicked https://pipelines.actions.githubusercontent.com/xS8oSnypZkPEQZqiZgDaRp2kdvQJKbOY08TesHp7E8vn7g4hYR/_apis/pipelines/1/runs/3849/signedlogcontent/3?urlExpires=2020-05-07T14%3A34%3A52.7708746Z&urlSigningMethod=HMACV1&urlSignature=Cu8PuD6tbXaeK9XSQWsuVXqbd8jH%2B62vrOPPofc0KA0%3D
<mborzecki> a better link https://paste.ubuntu.com/p/Cc4YQ4tCPQ/
<pedronis> mborzecki: it's actually wrappers that paniced, no?
<mborzecki> more like it hit a timeout and go-check aumatically panicked
<mborzecki> but it's weird why it'd timeout
<pedronis> something deadlocked
<pedronis> or didn't Stop
<pedronis> seems the tests are running usersession for real
<pedronis> and stop didn't work
<pedronis> github.com/snapcore/snapd/usersession/agent.(*SessionAgent).Stop(0xc4204222d0, 0x0, 0x0)
<pedronis> is sitting there for 4 minutes
<pedronis> the http server bits are in Accept
<mborzecki> mhm
<pedronis> actualy there's a workaround added recently about this
<pedronis> that doesn't seem to help
<pedronis> mborzecki: what go version is that on?
<mborzecki> pedronis: 1.9
 * zyga is still helping his parents
<pedronis> mborzecki: this is annoying(tm)
<mborzecki> failed again
<mborzecki> https://github.com/snapcore/snapd/runs/653302161
<mborzecki> at laest it's consistent
<mborzecki> need to run an errand with the kids, bbl
<pedronis> trying to run it locally with 1.9
<pedronis> a bunch of times
<pstolowski> cachio: that tests passes on master for me (but i had to add installation of the .deb on the host)
<cachio> pstolowski, works well on 20.04?
<pstolowski> cachio: ah, i only checked 19.10 that was failing for you. let me run on 20.04
<cachio> pstolowski, sorry, 19.10 is working well now
<cachio> 20.04 is failing with that error
<pstolowski> aah
<ijohnson> mborzecki: mvo: can't we avoid putting that into the beta by having the gadget snap just use assumes on a new snapd version?
<mvo> ijohnson: oh, nice, yeah, that should work. I'm not sure we have assumes for pre versions yet :)
<ijohnson> True that would only work 2.45 -> 2.46 right now
<pedronis> mborzecki: it's not blocking here with 1.9.3, we are missing something
<mup> PR snapd#8619 opened: o/devicestate,cmd/snap-bootstrap: seal to recover mode cmdline <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8619>
<cmatsuoka> ijohnson, mvo: a quick fix for the recover mode cmdline: https://github.com/snapcore/snapd/pull/8619/files
<mup> PR #8619: o/devicestate,cmd/snap-bootstrap: seal to recover mode cmdline <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8619>
<ijohnson> cmatsuoka: ack looking now
<cmatsuoka> ijohnson: feel free to push any fixes, I'll be back after lunch
<cmatsuoka> ijohnson: I didn't actually test it in a real image
<ijohnson> cmatsuoka: I'll test it out here for ya
<ijohnson> hmm didn't work ootb
<pstolowski> cachio: ok, i investigated (20.04 test fails for me too)
<pstolowski> cachio: and i understand the issue
<cachio> pstolowski, good, thanks for digging
<pstolowski> cachio: is the .deb on the nested vm the official one from the distro? i assume so since it is version 2.44.3?
<cachio> yes
<pstolowski> right
<pstolowski> cachio: so the issue is: the deb in the 20.04 image has a newer version of snapd than the one that is in seeds/
<pstolowski> cachio: snap-preseed mounts the vm image and runs snapd from seeds (the old one)
<cachio> ahhh
<pstolowski> cachio: then the vm is started, but since snapd from deb is newer it doesn't re-exec
<cachio> pstolowski, is it easy to fix it?
<pstolowski> cachio: so everything runs as expected, but the test expects that the snapd from seeds was used
<pstolowski> cachio: the fix will be in test. we should probably inject latest snapd into seeds/ of the image (which i was doing intially in these tests some time ago)
<cachio> pstolowski, right
<pstolowski> i wonder if this is a valid scenario that we should handle better in preseeding, need to talk to pedronis
<cachio> pstolowski, download snapd from beta/edge and copy it right?
<pstolowski> cachio: that could work, or repack
<pstolowski> yeah, edge would do
<cachio> pstolowski, nice
<cachio> are you testing this?
<cachio> to see if it works?
<pstolowski> cachio: no, not now, i can look at it tomorrow
<cachio> pstolowski, ok, if I finish a fix I am doing I'll try to make it
<pstolowski> cachio: it's a bit annoying as you need to mount the image, modify seed.yaml etc
<cachio> pstolowski, ah, ok, well, in case you know the details you can do it :)
<pstolowski> cachio: it was implemented initially in preseed.sh helpers, you can find it in git history
<cachio> no hurry
<pstolowski> cachio: ok, sure, i can do it
<cachio> pstolowski, thanks
<pstolowski> yw
 * cachio lunch
<mup> PR core20#56 opened: Revert "Add secureboot-db" <Created by xnox> <https://github.com/snapcore/core20/pull/56>
<mup> PR core20#56 closed: Revert "Add secureboot-db" <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core20/pull/56>
<mup> PR pc-amd64-gadget#47 opened: gadget: bump edition to 2, using production signing keys for everything <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/47>
<mup> PR snapcraft#3109 opened: pcache: introduce persistent cache decorator <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3109>
<cachio> zyga, hey, I see this error in un18 https://paste.ubuntu.com/p/7yxW5zcspd/
<cachio> uc18
<cachio> zyga, is this something that you have change right? Initially the test fails like this https://paste.ubuntu.com/p/tM9HDxWsMp/
<mup> PR snapcraft#3110 opened: repo: use persistent cache for fetching stage packages <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3110>
<mup> PR pc-amd64-gadget#47 closed: gadget: bump edition to 2, using production signing keys for everything <Created by xnox> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/47>
<jdstrand> pedronis: re 8592. yes, 'hardware-control' is way too general. also, it says it is for 'lspci -A linux-sysfs', but that command is read-only (and the r access is in hardware-observe)
<jdstrand> pedronis: beyond the name, 'w' access over a huge swath of /sys is too general
<pedronis> jdstrand: yes, that's what I thought as well
<pedronis> I asked to propose something more specific to the use case, it will be also clearer what the access really is
<jdstrand> pedronis: we have a cpu-control interface that this might fit in, or perhaps fan-control. I think we need to understand all the desired accesses. running lm-sensors to configure the host from a snap... ehh
<jdstrand> pedronis: but we can look at it
<pedronis> jdstrand: yes, I also mentioned that maybe there is one were it can fit already
<pedronis> *where
<jdstrand> tbc, we have cpu-control, fan-control would be new, but the submitter likely wants a lot of different accesses. we should look at them all specifically to decide how to organize
<jdstrand> emitorino: fyi ^
<mup> PR snapd#8620 opened: Adds GPL-3.0-or-later license <Created by prabhu> <https://github.com/snapcore/snapd/pull/8620>
<mup> PR snapd#8618 closed: gadget: fix fallback device lookup for 'mbr' type structures <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8618>
<mup> PR snapd#8619 closed: o/devicestate,cmd/snap-bootstrap: seal to recover mode cmdline <Squash-merge> <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8619>
<mup> PR snapd#8616 closed:  progress: tweak multibyte label unit test data  <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8616>
<mup> PR snapd#8621 opened: o/devicestate,cmd/snap-bootstrap: seal to recover mode cmdline, unlock in recover mode initramfs <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8621>
<mup> PR snapd#8622 opened: cmd/snap-bootstrap/initramfs-mounts: add sudoers to dirs to copy as well <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8622>
<mup> PR snapd#8621 closed: o/devicestate,cmd/snap-bootstrap: seal to recover mode cmdline, unlock in recover mode initramfs <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8621>
<om26er> Hi! How does the Snap Store calculate "territory" matrix ? Is there a place where I could read about the technical information about that ? Is that anonymous ?
<om26er> https://snapcraft.io/docs/snap-store-metrics -- The page I found, does not answer my question
#snappy 2020-05-08
<mup> PR core20#55 closed: hooks: make systemd-modules-load depend on mounts at /usr/lib/{firmware,modules} <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/core20/pull/55>
<mup> PR snapd#8623 opened: tests/lib/prepare.sh: delete patching of the initrd <UC20> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8623>
<mborzecki> morning
<mup> PR snapd#8622 closed: cmd/snap-bootstrap/initramfs-mounts: add sudoers to dirs to copy as well <UC20> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8622>
<mborzecki> mvo: hey
<mborzecki> mvo: we can land https://github.com/snapcore/snapd/pull/8623
<mup> PR #8623: tests/lib/prepare.sh: delete patching of the initrd <UC20> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8623>
<mvo> mborzecki: cool
<mvo> mborzecki: done
<mborzecki> mvo: thanks
<mup> PR snapd#8623 closed: tests/lib/prepare.sh: delete patching of the initrd <UC20> <â  Critical> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8623>
<mborzecki> seems like that go 1.9 failure in wrappers is random after all
<zyga> good morning
<zyga> eventful evening?
<mvo> zyga: good morning - we did all the bits missing for beta I think
<mvo> zyga: snapd snap just building, that was the last piece, then we hopefully have a working beta
<zyga> that's impressive
<zyga> mvo: I'll do what claudio mentioned
<zyga> boot it and leave it running
<zyga> an aging test
<mvo> zyga: nice
<mborzecki> zyga: hey
<zyga> :-)
<zyga> guys, if you have daughters
<mborzecki> hm?
<zyga> then spend 30zÅ / < 10 euro
<zyga> and play it with them
<zyga> https://www.gog.com/game/foxtail
<zyga> this game is incredibly beautiful and fun
<zyga> localized, with click-to-advance in dialogue, so kids can read at their own pace
<mborzecki> zyga: hmm looks like an old school adventure game?
<zyga> it is
<mborzecki> zyga: do you remember teenagent? :P
<zyga> and the mood and looks are just so nicely crafted
<zyga> mborzecki: yes but this is way better :)
<zyga> (I bought teenagent as a teen)
<mborzecki> no way xD
<zyga> yeah :D
<mborzecki> too bad gog doesn't support their client on linux
<zyga> there's no DRM and it supports linux as well
<zyga> mborzecki: yeah but the game is just a zip to download and run
<mborzecki> zyga: well, it is, but it's clearly a work in progress title, so on linux you'll have trouble keeping up with the updates, none of the open source clients i tried seem to support updates nicely and there's some issue with gog updates api that apaprently makes it hard to integrate
<zyga> mborzecki: this game is updated roughly once a year
<zyga> mborzecki: anyway, just consider it
<zyga> it really is worth the money
<zyga> mborzecki: each update brings the next episode (3 out of 7 are available now)
<zyga> it is made by a tiny studio
<pstolowski> morning
<zyga> good morning pawel!
<mborzecki> anyone able to reproduce the unit test timeout in wrappers package?
<zyga> mborzecki: on master?
<zyga> mborzecki: I started go test -count 1000 ./wrappers/
<zyga> I'll let you know if it triggers
<mborzecki> pedronis: hi, were you able to reproduce the unit test timeout in wrappers by any chance?
<pedronis> no
<mborzecki> hm intersting, also the PRs that ijohnson opened yesterday were green today
<pedronis> it's definitely weird
<pedronis> also it might be that something else failed and the panic covers it because it doesn't get printed
<mborzecki> yeah, that's true
<pedronis> mvo: hi, it's not needed for the beta but this also needs to be backported https://github.com/snapcore/snapd/pull/8602  I don't see it in 2.45 yet
<mup> PR #8602: configcore: only reload journald if systemd is new enough <Squash-merge> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8602>
<pedronis> mvo: this also wasn't ported  https://github.com/snapcore/snapd/pull/8622/ ?
<mup> PR #8622: cmd/snap-bootstrap/initramfs-mounts: add sudoers to dirs to copy as well <UC20> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8622>
<mvo> pedronis: yes, that is right, let me fix that
<zyga> pedronis: I moved https://github.com/snapcore/snapd/pull/8566 to snaplock
<mup> PR #8566: cmd/cmdutil: add run inhibition operations <Created by zyga> <https://github.com/snapcore/snapd/pull/8566>
<zyga> once this is +1 I will adjust the dependencies
<pedronis> thx
<pedronis> need to do some other things before getting back to reviews
<zyga> sure
<zyga> I have plenty of things to write so not blocked
<mup> PR snapd#8624 opened: cmd/snap: fix the order of positional parameters in help output <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8624>
<mborzecki> trivial fix ^^
<zyga> mborzecki: I reproduced the panic
<zyga> https://www.irccloud.com/pastebin/vmigrXPM/
<zyga> mborzecki: so
<zyga> mborzecki: this trace is funny
<zyga> mborzecki: we clearly exec something
<zyga> yet the SetUpTest says
<zyga>     s.systemctlRestorer = systemd.MockSystemctl(func(cmd ...string) ([]byte, error) {
<zyga>         s.sysdLog = append(s.sysdLog, cmd)
<zyga>         return []byte("ActiveState=inactive\n"), nil
<zyga>     })
<zyga> which seems to suggest this mock is one thing
<zyga> but calling "systemctl" executable is another
<mborzecki> zyga: which go version is that?
<zyga> 1.13.8
<zyga> brb
<mborzecki> ok, so not go specific, probably just borked setup
<mborzecki> or test
<zyga> bugs, bugs, bugs
<zyga> but also progres
<pedronis> #8564 got a +1 from pstolowski and now I applied his suggestions and is ready for 2nd reviews
<mup> PR #8564: asserts: introduce Pool <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8564>
<zyga> pedronis: what is the 'h' assertion header for?
<ackk> mvo, hi, I canceled today sync as there isn't really anything to talk about
<mvo> ackk: ok, I see there is a bug mentioned, I have a look at that
<ackk> mvo, ah yeah, not sure if it's really relevant for snapd, but if you want we can talk about it. it's just me today
<ackk> mvo, mostly, I added it there to ask if there was a best practice for knowing the underlying OS details from a snap
<mvo> ackk: no need to meet just for that :)
<mvo> ackk: we can cover it next time
<ackk> right
<pedronis> zyga: they are test-only assertions, they look a bit like snap-declarations and snap-revisions
<pedronis> zyga: but unless you reviewed the other ones in this chain, I wouldn't recommend looking a tit
<pedronis> heh
<pedronis> at it
<pedronis> mborzecki: so that test failed again with the timeout
<pedronis> mvo: some the unit tests changes that came with jamesh PR that was merged yesterday are failing regularly but is not super clear what is going on
<pedronis> mvo: do you need to do a pre4 ?
<ackk> mvo, I have a very basic snap with just meta/snap.yaml (to test the system-files interface). I snap pack it but when I install I get - Run configure hook of "testsnap" snap if present (run hook "configure": cannot snap-exec: no such file or directory)
<ackk> mvo, why is it trying hooks when there are none?
<zyga> ackk: do you have meta/hooks/configure?
<ackk> zyga, nope
<zyga> though the snap-exec error is also curious
<ackk> just meta/snap.yaml and "script" , which is a bash script
<ackk> I'm using base: bare if that mattes
<ackk> *matters
<zyga> ah
<zyga> bare base has no shell?
<zyga> no /bin/sh
<ackk> oh,
<zyga> though the configure hook is weird still
<zyga> it's bare for a reason :D
<zyga> in fact, it has nothing
<zyga> you must provide a static binary
<ackk> right, I forgot
<mborzecki> pedronis: can you reproduce it?
<mborzecki> pedronis: or was that in some PR?
<pedronis> mborzecki: a PR
<mvo> pedronis: not sure if we need a pre4, I hope we can test what we have in beta and if it's all working fine I can do a 2.45 for real but it depends a bit. do you know already something that is broken?
<pedronis> mvo: no, just wondered because sudoers bits are not in pre3
<pedronis> so you cannot really test recover
<pedronis> afaiu
<mvo> pedronis: yeah, that was silly of me, I cherry picked it and pushed to release/2.45 and rebuild the beta. so it will be ~pre3+git but that should be ok for testing :)
<mborzecki> pedronis: commit d16c44f0aa mentiones some issues with shutting down the session agent
<pedronis> I know
<pedronis> maybe we should try undoing and then it happens for often and try to really understand
<pedronis> s/for/more/
<pedronis> anyway this is very annoying
<mborzecki> hm wonde rif it's possible that the agent hits idle timeout and stops listening
<pedronis> mborzecki: ah
<pedronis> maybe should be possible to write a test to see what happens in that case
<mborzecki> trying to provoke that in tests
<pedronis> but there's shoould be an Accept around
<pedronis> in that case, no?
<pedronis> sorry, there shouldn't be
<mborzecki> ah right
<pedronis> zyga: I did another pass on #8566
<mup> PR #8566: c/snaplock/runinhibit: add run inhibition operations <Created by zyga> <https://github.com/snapcore/snapd/pull/8566>
<pstolowski> hmm we could use systemd version check to avoid LazyUnmount on core16 (which generates a lot of noise in system log)
<zyga> pedronis: thank you for the review, I replied to one comment and I'll adjust the rest later today
<zyga> pstolowski: +1
<zyga> pstolowski: but then we never rewrite .mount units
<zyga> pstolowski: so -1 unless you know how to do that on systemd upgrades
<pstolowski> ah, hmm
<pstolowski> anyway, something to think about
<mup> PR snapd#8625 opened: wrappers: tweak the  order of restoring, use client timeout in services test teardown <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8625>
<mborzecki> pedronis: ^^ maybe this will give us more insight
<mborzecki> hm removed that thing poking the client in teardown and can reproduce the timeout now
<pstolowski> zyga: maybe we could make systemd version part of systemkey
<zyga> pstolowski: we don't rewrite mount units on system key
<pstolowski> zyga: yes, but maybe then we would
<zyga> pstolowski: what happens when you rewrite mount unit
<zyga> I tried to propose that but it got stuck on this discussion
<zyga> do we remount things? we cannot really
<pstolowski> allright... just thinking aloud
<zyga> no no, that's good
<zyga> it's just we need to think how to do that in practice
<pedronis> zyga: interesting, firefox does this HOME: $SNAP_USER_COMMOM in its snap.yaml
<zyga> I hope it's COMMON :)
<zyga> but interesting, yeah
<zyga> we give people the means and they get creative
<mborzecki> meh, go test -timeout is kinda silly
<mup> PR snapd#8626 opened: tests: fix passing stdin via session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8626>
<zyga> mborzecki: ^ a trivial patch and an annoying discovery
<pedronis> mborzecki: your PR is green,  so maybe we were trying to talk to the real agent?
<pedronis> do we need that poking code?
<mborzecki> yeah, but it'd hard to explain why there would be another agent
<zyga> maybe we activate it via socket?
<zyga> do we mask the real agent?
<mborzecki> however, go test ./... runs all package tests in parallel, if there's another package starting the agent, we could try to talk to taht other agent ?
<zyga> ah, unit tests
<mborzecki> (assuming mocking elewhere is incorrect too)
<pedronis> mborzecki: that sounds fragile,  well there are agents own tests of course
<pedronis> mborzecki: anyway I'm still unsure why we need that poking code
<mborzecki> right
<mborzecki> perhaps we could land #8625 while i'll try to poke further
<mup> PR #8625: wrappers: tweak the  order of restoring, use client timeout in services test teardown <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8625>
<pedronis> mborzecki: yes, that's fine
<zyga> it's finally warm enough to use the standing desk in the colder corner of the office :)
<cachio> zyga, hi
<zyga> hi
<cachio> yesteday I left some errors related to session tool
<cachio> I see you created a new PR with fixes
<zyga> oh?
<zyga> I didn't see those
<zyga> which fixes? :)
<cachio> zyga, is it related to this? https://paste.ubuntu.com/p/9Svw3Qd7yB/
<cachio> https://paste.ubuntu.com/p/k7fyPJch78/
<zyga> no
<zyga> restore EOFs?
<cachio> zyga, ahh, these fixes #8626
<mup> PR #8626: tests: fix passing stdin via session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8626>
<zyga> that is related to another PR but not to the pastebin
<zyga> is this EOF a one-off or something that always happens/
<cachio> zyga, restore EOF and also the other test
<cachio> zyga, the test failing on this https://paste.ubuntu.com/p/k7fyPJch78/
<cachio> zyga, cannot connect to server -> curl --unix-socket /run/user/12345/snapd-session-agent.socket -D- -X POST -H 'Content-Type: application/json' -d '{"action": "daemon-reload"}' http://localhost/v1/service-control
<cachio> zyga, this is also failing on uc20 https://paste.ubuntu.com/p/NgHhWVVPFW/
<cachio> zyga, the problem is that as it is failing on restore, it breaks the whole test suite
<cachio> zyga, my concern is why it is not failing in google execution
<cachio> but fails on edge and beta validation
<zyga> re
<zyga> cachio: probably random
<zyga> cachio: unless it happens each time when executing a specific test
<mborzecki> cachio: can you reproduce the problem in tests/main/snap-session-agent-service-control?
<cachio> zyga, mborzecki it happens 100% of the time
<cachio> mborzecki, yes I can
<zyga> cachio: did you collect information about the other session?
<zyga> cachio: from the session-tool failure?
<zyga> ah
<zyga> wait
<zyga> sorry,  I misread
<zyga> it's the EOF
<zyga> so no new data
<mborzecki> perhaps the session agent isn't running yet/already/at all
<cachio> zyga, no, but I can do it
<zyga> it's only interesting iff we can reproduce it in isolation
<zyga> cachio: if you can run session-tool test _alone_
<cachio> zyga, sure
<zyga> ok
<cachio> zyga, running
<cachio> gime me 5 minutes until it fails
<cachio> zyga, I reproduced the error
<cachio> is any info which I could provide?
<cachio> I have an ssh opened
<zyga> what's the last thing that was logged in the spread run?
<cachio> 2020-05-08 09:15:58 Error restoring external:ubuntu-core-18-64:tests/main/session-tool:test (external:ubuntu-core-18-64) : + session-tool --restore -u test
<cachio> 2020-05-08 09:15:58 Error debugging external:ubuntu-core-18-64:tests/main/session-tool:test (external:ubuntu-core-18-64) : EOF
<cachio> 2020-05-08 09:15:58 Restoring external:ubuntu-core-18-64:tests/main/ (external:ubuntu-core-18-64)...
<cachio> 2020-05-08 09:15:58 Error restoring external:ubuntu-core-18-64:tests/main/ (external:ubuntu-core-18-64) : EOF
<cachio> I could run with the flag to show the output
<zyga> cachio: how do you log into the system?
<cachio> it is a vm here
<zyga> cachio: how does spread log into the system?
<cachio> I it does not log
<zyga> well, does it execute test by magic?
<cachio> I have a spreac which show ssh on real time
<zyga> it must connect to the system somehow
<cachio> zyga, I have an image to reproduce the error if you want
<zyga> no
<zyga> I'd like to understand if this is a normal spread run that uses ssh to connect
<cachio> zyga, it is a normal spread run
<zyga> ok
<cachio> using external backend
<zyga> is it using ssh to log in as the root user on the device under test?
<zyga> or is there any other user used
<cachio> zyga, it uses root
<cachio> same as in google backend
<mup> PR snapd#8627 opened: c/snap-bootstrap: port mount state mocking to the new style on master (2.45) <Created by pedronis> <https://github.com/snapcore/snapd/pull/8627>
<zyga> ok
<zyga> cachio: can you log into the system
<zyga> and run, as root
<zyga> session-tool --prepare -u test
<zyga> session-tool --restore -u test
<cachio> zyga, done
<zyga> did it EOF?
<cachio> no
<zyga> ok
<zyga> is there anything in journal from the time of the failure?
<cachio> zyga, https://paste.ubuntu.com/p/bfJYGthXwB/
<cachio> this is the only I see which seems to be relevant
<cachio> I see it many times
<zyga> cachio: what specifically?
<cachio> May 08 12:15:58 localhost systemd[1]: session-tool-c24e7dda-59d7-4fbd-a871-fc2431b4f5d1.service: Main process exited, code=exited, status=1/FAILURE
<zyga> the test is running "false"
<zyga> Starting session-tool running false as test...
<zyga> to check that exit status is forwarded
<cachio> ah
<zyga> cachio: K w
<zyga> I wonder if this is just a network timeout over ssh
<zyga> this test takes a while to run
<zyga> maybe tweak it so that there's fewer iterations
<zyga> and see if that changes anything
<cachio> I am running again but now showing the output
<cachio> so I'll see on which line fails
<cachio> zyga, perhaps it helps
<zyga> yeah, let's try
<cachio> it is looping
<zyga> cachio: any failures?
<cachio> still preparing
<zyga> ok
<ackk> zyga, am I doing something wrong here https://bugs.launchpad.net/maas/+bug/1876217/comments/5 ?
<cachio> I had to re-execute
<mup> Bug #1876217: Controllers report Ubuntu Core version in the Snap <MAAS:In Progress by ltrager> <snapd:Incomplete> <https://launchpad.net/bugs/1876217>
<cachio> because once it fails, then the session is not correctly cleaned and fails the next run
<ackk> zyga, (wrt system-files plug)
<cachio> zyga, I see same behaviour
<cachio> as it calls itself it goes into an infinite loop
<zyga> ackk: yeah
<zyga> ackk: probably ..l
<zyga> ls -ld /etc/os-release
<zyga> is it a symlink?
<ackk> zyga, outside or inside the snap?
<zyga> well
<zyga> outside
<zyga> the hostfs one is failing
<ackk> /etc/os-release -> ../usr/lib/os-release
<zyga> so
<ackk> ah I see
<ackk> so I have to use the actual file?
<zyga> apparmor grants you rights to read /var/lib/snapd/hostfs/etc/os-release
<zyga> but you that is a symlink
<zyga> so you need /var/lib/snapd/hostfs/usr/lib/os-release
<zyga> and you need to understand this in your app
<zyga> it kind of sucks because symlinks seen via hostfs are "hard"
<zyga> it's good we don't have absolute paths in them
<zyga> extend the read section
<zyga> to say /var/lib/snapd/hostfs/usr/lib/os-release
<zyga> (in addition to the etc line)
<zyga> and you should be good
<ackk> zyga, so I suspect that won't work for the purpose of being os-agnostic, as on other OSes that might not be a symlink
<zyga> yeah
<ackk> zyga, so it won't work even if the interface allows both?
<zyga> the denial would also tell you
<zyga> well
<zyga> the symlink can in theory point anywhere
<zyga> in practice it either is not a symlink
<zyga> or it points to a finite set of files
<zyga> which do differ by OS flavour (I recommend booting a fedora workstation)
<ackk> zyga, I see, thanks
<zyga> good luck! :)
<zyga> oh
<zyga> standup!!
<zyga> ackk: I would prefer a snapctl os-release -like API
<zyga> where you could just ask
<zyga> and we'd tell you without this mess
<ackk> zyga, yeah, that'd be good
<ackk> zyga, alternatively the actual /etc/os-release content could be exposed in some other file, like /etc/os-release-host or something
<ackk> although that would only work for core* bases
<zyga> ackk: that's tricky too
<zyga> it's easier to have an API
<ackk> zyga, yeah I assumed it would be trickier :)
<cachio> zyga, this is the last part of the output
<cachio> https://paste.ubuntu.com/p/mysVkdXQ4M/
<zyga> "last" :D
<zyga> I don't know where to look
<zyga> the end looks like just cleanup
<cachio> I am logging the full run now
<zyga> no
<zyga> maybe just look at the log
<zyga> I mean
<zyga> I just don't know what to look at
<zyga> there are 35K lines there
<zyga> so a longer log doesn't really help much
<zyga> do you see where it failed?
<cachio> zyga, https://paste.ubuntu.com/p/2NT6zGG5QB/
<cachio> this could help
<zyga> what is the status of user-1001.slice?
<zyga> cachio: that does not seem to be a fragment of the earlier log
<zyga> as I cannot see the EOF messages there
<cachio> zyga, no, it is a new run
<cachio> zyga, this is from journal https://paste.ubuntu.com/p/hkcJwwpsV3/
<zyga> May 08 13:07:54 localhost sshd[19701]: pam_unix(sshd:session): session closed for user test
<zyga> this is weird
<zyga> how come are we logging in as the test user?
<cachio> cheking
<zyga> so
<zyga> cachio: let me tell you what I think
<zyga> session-tool --restore does stop the slice of the test user
<zyga> that stops all the services running as the test user
<zyga> and kills all the test users's processes
<zyga> the only explanation for the EOF
<zyga> is that we ssh as the test user
<zyga> not as root
<zyga> maybe both, dunno
<zyga> but that message looks like we just ssh as test
<cachio> zyga, I ran with -vv and I see it is running as root
<cachio> export USER="root"
<zyga> cachio: can you find the moment where we ssh
<zyga> or log into the machine and see if we've ssh'd as root or as test/
<zyga> pstolowski: maybe move the window to the mac's main screen?
<zyga> mvo: if you review the shell fix, please merge it, it failed on mount-protocol-error :/
<mvo> zyga: will do
<zyga> thanks
<zyga> cachio: I know what the problem is
<zyga> cachio: look at spread.yaml
<zyga> cachio: and look for user: test
<zyga> that's the problem
<zyga> we do connect as the test user
<zyga> no idea why
<zyga> it's probably not a good idea
<zyga> (username: test)
<cachio> zyga, yes
<cachio> you are right
<cachio> Let me update the test user and try again
<zyga> ok
<zyga> some tests failed on the store
<zyga> updates: got unexpected HTTP status code 408 via POST to "https://api.snapcraft.io/v2/snaps/refresh"
<zyga> pedronis: ^ is that expected?
<cachio> zyga, https://paste.ubuntu.com/p/fww8t62NbC/
<cachio> thanks!
<zyga> excellent
<zyga> thanks!
<cachio> I'll create a PR with the fix
<mup> PR snapd#8628 opened: cmd/snap: coldplug auto-import assertions from all removable devices <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8628>
<zyga> mvo: if you look at https://tracker.debian.org/pkg/snapd it says there were 8K new commits since release
<zyga> https://qa.debian.org/cgi-bin/vcswatch?package=snapd
<zyga> mvo: overrides for https://github.com/snapcore/snapd/pull/8626 and https://github.com/snapcore/snapd/pull/8614 would be great
<mup> PR #8626: tests: fix passing stdin via session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8626>
<mup> PR #8614: tests: don't create root-owned things in ~test <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8614>
<zyga> I could re-trigger but that would just waste time
<mvo> zyga: sure, OMW
<zyga> thank you
<mup> PR snapd#8614 closed: tests: don't create root-owned things in ~test <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8614>
<mup> PR snapd#8626 closed: tests: fix passing stdin via session-tool <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8626>
<zyga> thanks!
<mup> PR snapcraft#3111 opened: elf: fix parsing of notes after patchelf mangling <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3111>
<ijohnson> mvo: you might want to cherry-pick https://github.com/snapcore/snapd/pull/8623 onto 2.45 as well, since spread tests on the release/2.45 branch will fail there without that PR
<mup> PR #8623: tests/lib/prepare.sh: delete patching of the initrd <UC20> <â  Critical> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8623>
<ijohnson> mvo: I milestoned the PR as 2.45 for you
<mvo> ijohnson: \o/
<mup> PR snapd#8629 opened: tests: new test user is used for external backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8629>
<zyga> cachio: thank you :)
<cachio> zyga, yaw
<cachio> zyga, thaanks to you for helping with the issue
<zyga> :)
<zyga> yeah, it was a fun thing to discover :)
<pedronis> #8577 needs a 2nd review, maybe ijohnson ?
<mup> PR #8577: secboot,cmd/snap-bootstrap: move initramfs-mounts tpm access to secboot <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8577>
 * zyga is sorry for missing the TGIF
<zyga> lunch
<ijohnson> pedronis: yes it's been in my queue, will take a look
<pedronis> I forgot about your 8559
<pedronis> mborzecki: so I double checked, the workaround would have poked the real agents, so it cannot have a useful effect
<mborzecki> pedronis: i think we should just drop that bit that pokes the agent and see how it will perform in the unit tests accross more runs
<mborzecki> let me push that change actually
<pedronis> mborzecki: one other thing I notice is that the agent uses SdNotify but I don't see it mocked
<mborzecki> pedronis: that code shoudl be noop mostly withouth the env vars
<mup> PR snapd#8630 opened: tests: inject snapd from edge into seeds of the image in manual preseed test <Created by stolowski> <https://github.com/snapcore/snapd/pull/8630>
<pstolowski> cachio: ^ this should fix the problem, passes for me on 19.10 & 20.04
<mborzecki> pedronis: so i dropped that bit that poked the session agent, and it failed now ;P
<pedronis> mborzecki: it failed here too, but only with 1.9
<zyga> :D
<mborzecki> maybe that shitdown is buggy
<zyga> is it a bug in go?
<mborzecki> shutdown
<zyga> shitdown :D
<mborzecki> heh, funny typo
<zyga> shit happens
<zyga> shutdown may hang
<pedronis> likely yes, but is not obvious because the shutdown code seems the same
<pedronis> so it would be lower level
<zyga> maybe it relies on infra beneath
<mborzecki> if we only could restart successful unit test jobs
<zyga> oh about that
<zyga> mvo: what about bit pusher?
<mvo> zyga: bit-cacher? still an option, someone needs to review my pr
<mborzecki> got to go, my father's name day, bringing him some cake and all
<zyga> mborzecki: ^ you have a solution there
<zyga> mborzecki: o/
<pedronis> mmh
<pedronis> there is something odd about the code
<pedronis> maybe it relates to the problem
<pedronis> or not
<seb128> kenvandine, btw, I reported https://bugs.launchpad.net/snapd/+bug/1877610 now
<mup> Bug #1877610: The gdb option takes over the user configurations <snapd:New> <https://launchpad.net/bugs/1877610>
<seb128> about the 'gdb screws the configuration and breaks your application'
<kenvandine> seb128: thanks
<cachio> pstolowski, great, thanks
 * cachio lunch
<mup> PR snapd#8631 opened: image,cmd/snap,tests: add support for store-wide cohort keys <Created by xnox> <https://github.com/snapcore/snapd/pull/8631>
<pedronis> maybe I understand what is going on
<mup> PR snapd#8624 closed: cmd/snap: fix the order of positional parameters in help output <Simple ð> <Skip spread> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8624>
<mup> PR snapd#8627 closed: c/snap-bootstrap: port mount state mocking to the new style on master (2.45) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8627>
<mup> PR snapd#8629 closed: tests: new test user is used for external backend <Simple ð> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8629>
<mup> PR snapd#8632 opened: configcore: only reload journald if systemd is new enough (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8632>
<mup> PR snapd#8633 opened: tests: detect and report root-owned files in /home <Created by zyga> <https://github.com/snapcore/snapd/pull/8633>
<zyga> ijohnson: I guess with this ^ we could drop the FIXME comments in the pulseaudio tests
<ijohnson> zyga: there's a lot of things there, which one?
<pedronis> I think I have a fix for the wrappers mystery, actual the workaround would have also helped (if it talks to the right agent as now in Maciej PR)
<zyga> ijohnson: ah sorry, this code says BZZ BROKEN if a test leaks root-owned files in /home
<zyga> ijohnson: this is the code that showed the three tests fixed today
<pedronis> the issue is that on older go it seems if you call Shutdown before Serve, you get a race and Shutdown will not quite work
<zyga> pedronis: nice
<zyga> pedronis: what was the problem?
<zyga> ah :)
<pedronis> in normal usage that shouldnd't happen, but because this is setting up the agent also for a lot of cases that don't use it
<pedronis> it happens
<zyga> ijohnson: if you scroll to the bottom, you can see how this works
<zyga> pedronis: which go version is fixed?
<zyga> I was looking at some hangs that I could not explain and perhaps those are related
<ijohnson> zyga: no sorry I meant which PR were you referring to, there was like 8 messages from mup above your msg
<ijohnson> the "^" was ambiguous
<zyga> ijohnson: ah :D
<zyga> ijohnson: see here please https://github.com/snapcore/snapd/pull/8633/files#diff-01bb876cbb65b7a336cd99a41c4b97a9R5
<mup> PR #8633: tests: detect and report root-owned files in /home <Created by zyga> <https://github.com/snapcore/snapd/pull/8633>
<pedronis> zyga: I don't know
<pedronis> actually
<ijohnson> ack looking now
<pedronis> zyga: it's not a change in Shutdown itself
<pedronis> so it's not very easy to track
<pedronis> and haven't looked deeply
<zyga> ijohnson: some things we do in ad-hoc way could move there, like looking for selinux denials or apparmor denials or messages from broken udev rules
<zyga> ijohnson: I have one more checker, that shows we don't have processes running as "test" user
<ijohnson> this checker looks nice and I like having more checker things like this that make sure tests clean up after themselves
<zyga> one thing this buys us
<zyga> is perhaps a way to accelerate prepare/restore
<zyga> as now it's somewhat heaveyweight because it must be very conservative
<zyga> we could maybe make it faster over time
<ijohnson> right
<ijohnson> It would be good to see what kind of performance that is though, because I wouldn't be surprised if it's not actually that slow
<zyga> that fast or that slow?
<ijohnson> or rather than not doing automatic cleanup doesn't net us that much total performance
<zyga> ah, I see
<ijohnson> *performance gain
<zyga> I would be happy if we get a clear message from broken tests :)
<ijohnson> yes I think that's  the MVP we should be looking for right now :-)
<zyga> and not "one of the tests before, guess which please" but "this test right here" :)
<zyga> agreed
<ijohnson> also zyga what happened to "let's write all the -tool's in python :-P
<ijohnson> "
<zyga> well
<zyga> I did
<zyga> believe me
<zyga> but it's 20K lines now
<ijohnson> haha what
<zyga> and I just realized this will never get merged
<zyga> I wrote this
<zyga> waaaay more complex
<zyga> that's testbed-tool
<zyga> it supports python and shell plugins
<zyga> and has tests
<zyga> and man
<zyga> this shell script is good enough
<ijohnson> ah I see what you mean
<ijohnson> indeed
<zyga> but
<ijohnson> also much easier to review than 20000 lines of python
<zyga> since this is not a source-me shell program
<zyga> we can :)
<zyga> that's the important distinction
<pedronis> zyga: seems it's this issue: https://github.com/golang/go/issues/20239 and it's still thee 1.10 but fixed in 1.11
<zyga> and we are building with 1.10?
<pedronis> we use 1.9 and 1.10
<zyga> I see
<pedronis> and 1.13
<zyga> well, maybe after beta we could discuss having more recent builds
<pedronis> in our tests
<zyga> maybe for snapd.snap
<zyga> dunno
<zyga> I guess apart from core / snapd nobody is on go this old anymore
<zyga> but after beta
<zyga> pedronis: and great find!
<zyga> ok I should EOW now
<zyga> ijohnson: I'll push a few more checker patches that covert existing random checks into something more organized but probably later tonight only
<ijohnson> sure sounds godo
<ijohnson> good even
<zyga> thanks, have a great weekend everyone :)
<zyga> o/
<ijohnson> you too zyga o/
<mup> PR snapd#8625 closed: wrappers: tweak the  order of restoring, use client timeout in services test teardown <Skip spread> <Created by bboozzoo> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8625>
<mup> PR snapd#8634 opened: usersession/agent,wrappers: fix races between Shutdown and Serve <Created by pedronis> <https://github.com/snapcore/snapd/pull/8634>
<pedronis> mvo: ijohnson: ^
<ijohnson> mmm pedronis I haven't been following this discussion super close, is it ok if I review a bit later, trying to wrap up the reboot from recover -> run PR to propose first
<pedronis> yes
<pedronis> mostly I pointed it out because it should help with some of the red we are seeing
<ijohnson> ack, sounds good
<mvo> pedronis: nice!
<cmatsuoka> mvo: is the network fix for recover mode already in 2.45?
<cmatsuoka> mvo: well it seems so, it worked now (but for some reason it failed once before)
<ijohnson> cmatsuoka: yes it should be in the kernel snaps available on edge/beta
<mup> PR snapd#8635 opened: o/devicestate: support doing system action reboots from recover mode <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8635>
<cachio> zyga, any idea for this? https://paste.ubuntu.com/p/MRVj2xkQJf/
<cachio> it is happening with the new bionic image
<cachio> this happens with session tool as I see
<pedronis> ijohnson: I added some small comments/questions to that PR
<ijohnson> pedronis: ack I'm addressing them now
<zyga> cachio: re
<zyga> cachio: I think it's the race I mentioned during standup, I'll send a patch that probably fixes it next week
<cachio> zyga, nice, thanks
<zyga> so, why do our test images have an "ubuntu" useR?
<zyga> sorry
<zyga> why does spread-created core-16 and core-18 have an ubuntu user?
<zyga> it's really weird
<zyga> there's a /home/ubuntu/.ssh/authorized keys that's empty
<zyga> but /home/ubuntu is owned by root:root
<zyga> but /home/ubuntu/.ssh is ubuntu:ubuntu
<zyga> do we have a snap changes change for creating users?
<zyga> ok, found the bug
<cachio> zyga, did you find it?
<zyga> no, it was a false trail
<zyga> I added a few more checks
<zyga> if you know I'm all ears :)
<cachio> zyga, I also see this error + session-tool -u test --has-systemd-and-dbus
<cachio> grep error: pattern not found, got:
<cachio> no user dbus.socket
<cachio> is it related?
<zyga> no
<zyga> where do you see it?
<zyga> 16.04?
<cachio> bionic
<cachio> using the new image
<cachio> which I didnt publish yet
<cachio> image: test-bionic-1
<cachio> for this test google:ubuntu-18.04-64:tests/main/session-tool-support:test
<zyga> no-install-recommends probably ate dbus-user-session
<cachio> should I install dbus-user-session ?
<cachio> as a dependency
<zyga> if it was preinstalled in the other image, yeah
<zyga> or adjust the test, the test really shows us what the system defaults are
<pedronis> now we hit a different snapd-session-agent issue
<cachio> zyga, it is not installed in the previous version
<zyga> cachio: that's odd, the test really checks if you have dbus.socket as systemctl --user
<zyga> cachio: and we seem to have it in a vanilla bionic image
<zyga> cachio: otherwise it would not pass
<zyga> cachio: perhaps something just removed it
<zyga> cachio: if you have a debug shell, maybe it is in apt/dpkg history log
<cachio> zyga, I think the problem is that now we have installed dbus-x11 installed and previously we didnt
<zyga> pedronis: what did you run into?
<zyga> cachio: dbus-x11 is not checked by session-tool-support
<zyga> cachio: look at the test and at the filesystem please
<pedronis> zyga: test are failing in on core 16 for user services saying there's a start limit issue with the snapd-session-agent
<zyga> pedronis: start limit, as in it starts and crashes quicky?
<pedronis> maybe
<zyga> pedronis: core 16 and core 18 did not ship dbus for user sessions  (20 did)
<zyga> but did that test ever pass there?
<pedronis> maybe is my code change, but unsure it happens only on core 16
<zyga> I see
<zyga> oh fun
<zyga> Friday :/
<pedronis> I'm trying to run the test alone, to see if it's flaky or always fail
<pedronis> zyga: alone it works
<pedronis> fwiw
<pedronis> zyga: do we start sessions for root in tests?
<zyga> pedronis: if the test explicitly wants to, as in runs session-tool --prepare (-u root is default) and session-tool ....
<zyga> pedronis: IIRC some tests do but most don't
<zyga> pedronis: probably only tests that I wrote do that
<pedronis> maybe those tests are leaving something behind
<zyga> pedronis: try with -repeat 30 or something like this
<zyga> it is good at catching weird mistakes
<zyga> like test breaking itself
<zyga> as well as some chance of catching races
<zyga> pedronis: perhaps, which test did you see fail?
<zyga> if you dump all the information you have here I may have luck over weekend
<pedronis> zyga: https://github.com/snapcore/snapd/pull/8634/checks?check_run_id=657046716
<mup> PR #8634: usersession/agent,wrappers: fix races between Shutdown and Serve <Test Robustness> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8634>
<zyga> - Make snap "test-snapd-user-service" (unset) available to the system (Post http://0/v1/service-control: read unix @->/run/user/0/snapd-session-agent.socket: read: connection reset by peer)
<pedronis> yes, see /0 is root
<zyga> yeah
<zyga> let me check the test quickly
<pedronis> but the tests really set up a session only for test
<pedronis> sorry the test
<pedronis> I think there's an issue with the tests but also probably a robustness issue in general
<zyga> well
<zyga> the root user has a session
<zyga> because spread logs in over ssh
<zyga> perhaps we should mask session services for root
<zyga> at least for testing
<zyga> until we understand what's going on
<zyga> so, without using session-tool, there is a session
<zyga> loginctl shows it
<zyga> it's the ssh we use to connect
<pedronis> maybe yes
<zyga> so you get session services there
<zyga> including auto-start and other things
<zyga> if snapd does something to per-user sessions now
<zyga> (I kind of forgot how this works)
<zyga> it's plausible it talks to root's session as well
<zyga> as a quick way to check
<pedronis> it does, the logic is very naive in some ways
<pedronis> that's why I said we might have to think a bit
<pedronis> but indeed my concern right now is not even the feature
<pedronis> but more test robustness
<zyga> systemctl --user mask snapd.session-agent.{socket,service}
<zyga> right
<zyga> that line in core-16 prepare should disable this for the root user
<zyga> so no socket, no autostart
<zyga> if you want to get sanity quickly, maybe that's the solution
<pedronis> not today at this point
<zyga> sure,
<zyga> it's super late
<pedronis> I probably should look a bit more how the world looks when it works
<zyga> the one problem with root session
<zyga> is that we cannot "wipe the slate" like we do for test
<zyga> since we're connected as root
<zyga> so I guess we must be more careful with what happens across tests
<pedronis> well it seems we get the user agent for root not working somehow
<pedronis> ijohnson: I don't think I will get to re-review that PR today, also seems the check I made you add is redundant otoh I don't know how covered all that is
<zyga> the connection reset by peer is simply the agent closing?
<ijohnson> pedronis: no problem, I think it's reasonably well tested the only thing I don't have more tests for there that I could add would be that doing various combos of some mode to a differnet mode with a different system
<ijohnson> pedronis: but as mentioned all such cases currently just fail
<ijohnson> err are not supported, and thus fail
<pedronis> zyga: it's socket activated
<pedronis> or should be
<zyga> maybe the agent crashes?
<zyga> do we get a journal entry?
<zyga> note
<zyga> it's funny
<pedronis> or mabye the stop on idle is naive
<zyga> because journalctl --user is distinct
<zyga> so maybe we should look at journalctl --user as ewll
<zyga> *well
<zyga> the test does this in debug
<zyga> + session-tool -u test systemctl --user status snapd.session-agent.service
<zyga> we should also do
<zyga> + session-tool -u root systemctl --user status snapd.session-agent.service
<zyga> or really just
<zyga> systemctl --user status
<zyga> (without the extra fanfare)
<zyga> May 08 20:23:40 may082014-475733 passwd[1570]: password for 'ubuntu' changed by 'root'
<zyga> cloud init?
<zyga> is our core16 system affected by cloud init data from GCE?
<zyga> ha
<zyga> it seems so
<zyga> :D
<zyga> May 08 20:23:40 may082014-475733 passwd[1570]: password for 'ubuntu' changed by 'root'
<zyga> that's from cloud-init.service
<zyga> pedronis: ^^ lol
<zyga> is this expecteD?
<zyga> cachio: so, do you know why we get the "ubuntu" user on core16?
<zyga> cachio: we do have a weird ubuntu user that belongs to grup "niemeyer"
<zyga> this looks very much like an artefact of cloud-init
<zyga> but I cannot put my finger on it
<zyga> specifically the group is surprising
<pedronis> how do we build images, do we take a image, ssh to it, add package and then clean up and snapshot it?
<zyga> we build an image and copy some bits but I confirmed that /home/ubuntu does *not* exist at that stage
<zyga> it really shows up during boot
<zyga> even timestamps support that
<zyga> I'm unfamiliar with cloud init detials, looking at some of what the logs say now
<zyga> (so the directory and the user get added on first boot)
<zyga> and it really seems that it's cloud init
<zyga> and I would not really complain
<zyga> except that it's buggy
<zyga> the owner of /home/ubuntu is root :D
<zyga> another fun find
<zyga> core 16 ships this file
<zyga>  /usr/share/click/frameworks# cat ubuntu-core-15.04-dev1.framework
<zyga> (messed up but you get the idea)
<zyga> we also have /usr/share/upstart
<zyga> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1639955
<mup> Bug #1639955: bad test for snappy systems <cloud-init:Confirmed> <cloud-init (Ubuntu):Confirmed> <https://launchpad.net/bugs/1639955>
#snappy 2020-05-09
<mup> PR snapd#8636 opened: tests: add dependency needed for next upgrade of bionic <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8636>
#snappy 2020-05-10
<exit70> hi, is it just me or snap mpv crashes on startup in 18.04?
