#snappy 2016-04-04
<dholbach> good morning
<didrocks> hey dholbach, how was your week-end?
<dholbach> salut didrocks
<dholbach> great - how was yours?
<didrocks> at jdll on the ubuntu both, presenting snappy, giving a small workshop and such
<didrocks> + fixing some snapcraft copy plugin over the week-end
<dholbach> wow
<dholbach> I hope you're going to be able to free up some time this week to take it easy then :)
<didrocks> well, can't swap: on holidays on Wednesday and thing to finish up first
<dholbach> ah yes, you're going to be on holidays :)
<dholbach> nice
<zyga> good morning
<JamieBennett> Morning all
<mvo> hey JamieBennett, good morning!
<dholbach> hey JamieBennett
<zyga> JamieBennett: hey :)
<didrocks> good morning JamieBennett
<ara> Hello! is there a place (i.e. URL) where I can get a list of the env variables in snappy for developers?
<ara> (like SNAP_DATA)
<fgimenez> morning JamieBennett :)
<didrocks> ara: there are some, but it's not always up to date. The easiest for now is to run hello-world.env
<ara> didrocks, that "some", where are those? :)
<didrocks> ara: in the snapcraft guys, they are introduced one after another if you read the whole content: https://developer.ubuntu.com/en/snappy/build-apps/
<didrocks> ara: but not a definitive list, hence my "you should for now point to this command"
<ara> didrocks, thanks
<didrocks> yw
<zyga> ara: one sec
<zyga> ara: https://github.com/ubuntu-core/snappy/blob/master/snap/snapenv/snapenv.go
<zyga> ara: look at around lines 62, 76
<zyga> ara: it is not final
<ara> zyga, OK, thanks
<zyga> ara: we're still changing that area as other parts land
<kyrofa> Good morning
<didrocks> hey kyrofa!
<kyrofa> Hey didrocks, good day so far?
<didrocks> kyrofa: yeah! rushing things before my holidays actually :)
<davidcalle> didrocks: hey, I remember you were trying to snap vlc, right?
<didrocks> davidcalle: not vlc, but the ascii streaming of it, yeah
<davidcalle> didrocks: ok, I thought at some point you were also trying vlc and building it is a bit painful, nevermind then, I'll dig further :)
<didrocks> good luck! :)
<didrocks> davidcalle: I was reusing the deb from the distro FTR
<davidcalle> didrocks: that's cheating :p
<didrocks> davidcalle: well, vlc takes 6h to build on the pi2, I didn't want the "create your first snap" to be 6h25 minutes :p
<davidcalle> :)
<asac> classic for arm64 not there yet?
<ogra_> asac, nope, still not :(
<asac> ogra_: can i convince udf to use 32-bit rootfs?
<asac> and dragonkernel
<davidcalle> kyrofa: https://github.com/ubuntu-core/snapcraft/blob/master/docs/intro.md refers to "snappy try", but "snappy try" doesn't seem to exist anymore, what can we use instead?
<kyrofa> davidcalle, I'm not sure it ever did (if so it was before my time). I think it's still something we're wanting to make
<davidcalle> kyrofa: ok, thanks
<qengho> I got a Raspberry Pi 3. I assume it's pretty close to the 2.
<qengho> I used these instructions: https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/
<qengho> And it never progresses past the power-on rainbow square.
<qengho> Are those instructions verified?
<kyrofa> qengho, ogra_ has the rpi3 working with the rpi2 gadget, but I'm not sure it's been released just yet
<adaw> Suppose I have a web app on my own cloud server. I want to use snappy to build a gateway such that  only traffic from this gateway can communicate  with my server. Can such a security feature be achieved with snappy?
<adaw> the server web app somehow recognizes some hardware mac address from the snappy iot gateway. can this be done?
<qengho> adaw: Where is the server, physically related to the device?
<zyga> adaw: you could write a snap that controls networking on the device
<qengho> Same room, or across the country?
<adaw> qengho: i intend to use this server from digitalocean, a cloud provider
<zyga> adaw: to implement a firewall that restricts it as you described
<zyga> adaw: you'd use the firewall-control interface
<adaw> zyga: pardon my ignorance. what is a snap?
<zyga> adaw: I suggest you read about snappy first
<zyga> adaw: snap is the smallest package in a snappy ecosystem
<adaw> the firewall is on the server or snappy?
<zyga> adaw: on the device running snappy
<qengho> adaw: You know that the link address, MAC in this case, is only used to communicate with things on the same link? So, it's used from your device to the everything connected on that Ethernet link, but after that, it's not part of communicating?
<adaw> qengho: if that's the case, is there any way to do hardware authentication?
<zyga> (that is another issue)
<zyga> adaw: TPM?
<zyga> adaw: depends on what you really want to achieve in the end
<qengho> adaw: No. There's no hardware that's shared. You're going to have to share a secret in software somehow.
<adaw> so, to do hardware authentication, there has to be some sort of security chip. Nothing to do with snappy, right?
<qengho> adaw: We haven't begun talking about Snappy yet. This is just the reality of networking.
<zyga> adaw: it depends on what you want, perhaps an SSL cert is enough
<adaw> TPM is a chip for hardware authentication.  correct?
<zyga> for your snap to check that we're talking to a given server
<zyga> but snappy will still talk to other places
<adaw> suppose i want my server web app to be able to talk to only 1 single gateway in the world. Can this be achieved without using TPM?
<qengho> adaw: Here's my opinionated idea: You should fabricate a secret key there, and install OpenVPN on your server, and on your device.
<adaw> qengho: so, in this way, i can achieve my objective using software means only?
<qengho> The local, snappy end, of your VPN is both the OpenVPN client and whatever app you wish to run on it.
<qengho> Yes, software only.
<adaw> qengho: u're a genius! by the way, why don't other folks adopt your solution? why use a more expensive and cumebrsome solution like TPM?
<qengho> People do. They might not if they don't control servers. TPM is rare.
<adaw> Let me understand u correctly. I install OpenVPN server on the cloud server.  Then, install OpenVPN client on the snappy gateway. Finally, open a secure VPN link between them. Correct?
<zyga> TMP is really for different things than this IMHO
<zyga> openvpn and tpm have almost nothing in common
<ogra_> quengho, kyrofa, there is an image with the pi3 gadget though
<zyga> you can use TPM for many interesting and useful things that openvpn cannot do
<qengho> ogra_: Yay. I was hoping for a 16.04~ thing anyway.
<qengho> adaw: You got it. You have to make the OpenVPN client as part of making your snap. Assemble all the pieces together and package it.
<qengho> adaw: snapcraft parts. One is your app. Another is the VPN code.
<adaw> qengho: can I just use normal Ubuntu instead of snappy to do this openVPN client stuff?
<ogra_> qengho, http://people.canonical.com/~ogra/snappy/all-snaps/rpi3/
<qengho> adaw: I have to warn you, it might be hard. Making a snap listen for network connections isn't usually allowed.
<zyga> adaw, qengho: I'd suggest waiting
<qengho> adaw: No. Snappy is a whole new world.
<zyga> I'm sure that openvpn uses network-manager and I know some people are looking at that already
<adaw> qengho: since it is just a VPN client, wouldn't using normal UBuntu and then running python scripts be easier?
<zyga> qengho: to listen for network connection all you need is the network-bind interface
<qengho> Ah$
<zyga> adaw: ubuntu snappy and ubuntu classic are two different worlds; if snappy virtues appeal to you or your use case, use snappy
<adaw> besides raspberry pi, what are the hardware boards that can run snappy today?
<ogra_> dragonboard, beaglebone, minnowboard ...
<adaw> am i right to say the most value-for-money board is Rpi today?
<zyga> adaw: for what money?
<zyga> adaw: for the price?
<ogra_> depends on the usecase reallt
<ogra_> *really
<adaw> any commercial boards instead of the hobbyist boards?
<zyga> adaw: such as?
<adaw> something from Intel?
<zyga> adaw: you can use certified kernels on any x86/amd64 devices
<zyga> adaw: dell announced support for snappy on some devices, you might want to check that
<zyga> adaw: https://insights.ubuntu.com/2015/10/21/snappy-core-unlocks-iot-value-within-the-dell-edge-gateway-5000-series/
<ogra_> adaw, there is the dell gateway that comes preinstalled with snappy (still 15.04 though)
<adaw> What are situations to use Snappy Ubuntu Core instead of Ubuntu Classic? i'm rather confused here
<zyga> adaw: snappy has transactional updates
<zyga> adaw: snappy updates automatically
<zyga> adaw: snappy is a greate way to build an unattended product
<zyga> adaw: classic is a great workstation
<zyga> adaw: and a great server
<adaw> for ubuntu, I just do "apt-get update and upgrade". u mean for snappy, it just updates automatically without needing to run commands?
<zyga> adaw: snappy is something you'd use for mass-market devices due to reliability and resiliance
<zyga> adaw: and then you get a debconf prompt
<zyga> adaw: and all your devices in the field got the same debconf prompt, half of your users input wrong value, the other half had no UI and update was fronzen until the next power-cycle where the device didn't boot
<zyga> adaw: snappy makes that  better
<zyga> anyway, good luck
 * zyga -> hacking
<olli> end
<ogra_> adaw, debs always have full root access to your system ... (a postinst script from some PPA can easily replace your kernel with some malicious binary) ... snaps cant do that
<adaw> if snappy updates automatically, wouldn't that be dangerous? Someone can hake and  automatically several snappy boards at the same time.
<ogra_> if you only stick to the ubuntu archive thats indeed moot, but as soon as you need some newer version of some SW that some guy offers in a PPA you already giave him full root access
<adaw> u folks are convincing. snappy sounds better. why doesn't UBuntu just migrate to snappy?
<ogra_> because snappy is still very young and not all bits are solved yet ...
<ogra_> i.e. you can easily package an app ... but it is hard to package something that integrates with ... say a desktop that you ship as snap
<adaw> andywojo: are there commercial applications using snappy today? is it mature enough?
<adaw> ogra_: so, snappy are for embedded devices, right?
<ogra_> not generally .... 16.04 desktop will have snappy support by default
<ogra_> and you should be able to run desktop apps that are packaged as snaps
<adaw> ogra_: wow. so, ubuntu is indeed going to migrate to snappy. in 16.04
<ogra_> a snappy img today will rather be focused on embedded though
<ogra_> and not ship a desktop
<adaw> ogra_: so, in 16.04, when i do apt-get, i will be getting snaps?
<ogra_> not migrate .... but support
<ogra_> when you apt-get you update your system
<ogra_> when you use snappy your snappy app will run in a container and interface with the desktop
<ogra_> there will still be a few releases til you see a full snappy based desktop
<ogra_> today snappy in deskop is an addon ... you will be able to use snappy apps but your desktop is still the good old thing you know
<adaw> ogra_: are there other linux distributions that are copying snappy features? Windows?
 * ogra_ doesnt know
<adaw> for iot, snappy will be ideal for iot gateways, right?
<ogra_> yes
<ogra_> also for NAS ... or routers/switches ...
<adaw> any iot gateways in commercial use today that is using snappy?
<ogra_> at some point we should have a kodi snap so you could easily build a kodi appliance image
<ogra_> things like that will surely show up soon
<adaw> u mean, not at the moment yet?
<zyga> adaw: snappy is generally better than ubuntu except not features are supported yet so you can expect the scope of supported things to increse which in turns unlocks more places where snappy is appropriate
<ogra_> yes, the dell gateway ... and i think there are more in teh works with various partners
<zyga> s/ubuntu/classic/
<ogra_> kyrofa worked on an owncloud image for teh rpi that seemingly will be used by WD for their diskstation+rpi project
<adaw> Intel NUC works on snappy. https://insights.ubuntu.com/2016/03/02/intel-and-canonical-continue-to-build-large-iot-gateway-ecosystems/
<ogra_> yep
<ogra_> basically all x86 based devics should work more or less
<adaw> even my PC?
<ogra_> sure
<ogra_> would be a bit more fiddly to install thogh :)
<ogra_> (boot from USB stick and dd to internal disk ...)
<adaw> So, i can install ubuntu classic and snappy on top on it on my virtual machine on virtualbox?
<ogra_> by release day you should just be able to install ubuntu-desktop and automatically have snappy support in there
<adaw> Confused by the instructions here. Why install ubuntu classic and not snappy? https://developer.ubuntu.com/en/snappy/start/intel-nuc/?_ga=1.260177357.1317873563.1456655626
<davidcalle> adaw: to have a system running somewhere (from a live USB in this case), from which you will install snappy on the nuc.
<adaw> davidcalle: i see. thanks.
<adaw> can snappy be installed onto a virtual machine on virtualbox?
<davidcalle> adaw: see https://developer.ubuntu.com/en/snappy/start/#snappy-local
<ogra_> kvm is easier though
<ogra_> (no need to convert anything)
<davidcalle> adaw: sorry, I meant https://developer.ubuntu.com/en/snappy/start/#ova
<adaw> thanks all. I have much to learn. Don't even know what's the difference between virtual machine and container at the moment.
<mvip> hey guys, have anyone spent any cycles on remote logging for Snappy? Are there any guidelines there?
<mvip> For us it's important to capture these logs, but rsyslogd isn't ideal to use natively (as it's somewhat messy to setup with TLS).
<mvip> Ideally I want to ship logs over HTTPS (to avoid additional port requirements).
<mvip> I'm thinking something like Fluent (https://github.com/fluent/fluentd) would do well, but I wanted to check with you guys before I start diving into this too far.
<qengho> How do you folks build snapcraft packages on armhf?
<ogra_> snappy shell classic ..
<qengho> Ah.
<zyga> qengho: there's some limited support for cross compilation in snapcraft for certain plugins
<zyga> qengho: but ogra gave the correct and generic answer
<ogra_> only for kernel AFAIK
<zyga> ogra_: I read that someone got go plugin to cross compile
<ogra_> ah, never used that
<qengho> Yeah, it's close to working. I started a C/C++ support patch for autotools and make, but found I wasn't doing it the right way and aborted.
<kyrofa> ogra_, the launchpad builders work now too
<kyrofa> ogra_, and are way WAY faster
<kyrofa> qengho, ^^
<ogra_> kyrofa, not for armhf/arm64
<qengho> You tease.
<kyrofa> ogra_, qengho you should be able to enable those if you edit the snap. Just check the boxes
<kyrofa> ogra_, qengho also exposed via the python API. Can't wait to get travis builds firing off
<qengho> kyrofa: Edit how? I have a bzr branch. Snapcraft config mentions no architecture. "Request builds" in snap packaging on LP asks "amd64 or i386?"
<kyrofa> qengho, click on the snap and say edit details
<kyrofa> qengho, see more arch options there?
<qengho> I sure do. The defaults perplex me. Thanks!
<kyrofa> qengho, note that the builders only have internet access in the pull step
<kyrofa> qengho, also note that Snapcraft 1.x is used if targeting vivid, Snapcraft 2.x is used if targeting xenial
<qengho> Cool. I pushed it up the hill and let go. I'll see what happens.
<kyrofa> didrocks, by the way, any progress on that unversioned directory in snappy?
<didrocks> kyrofa: I was hoping to start getting to it this week. More work was dumped on me. I'll have a try but if I can't (and if that's urgent), I'm happy to warn if I can't get to it before my holidays
<kyrofa> didrocks, yeah let me know if you don't mind :)
<didrocks> sure!
<qengho> kyrofa: The LP snap integration is still a mystery to me. My packages compiled well. Yay! But, where did they go? How do I use them?
<didrocks> qengho: you have a link to download them
<didrocks> if you click on each ones
<qengho> Okay, then. I downloaded, then uploaded to the same place my earlier "snapcraft upload" emitted as the URL to manage my package, once for i386, arm64, and armhf. That felt weird.
<qengho> Seems to have worked, though.
<qengho> Thanks, didrocks, all.
<qengho> I welcome feedback. tor-middle-relay.chadmiller  Now for ARM too!
<qengho> Service crash at startup. "seccomp_load failed with -22" "seccomp_load_filters failed with -22. errmsg: Invalid argument"
<asac> qengho: https://bugs.launchpad.net/snappy/+bug/1561920
<ubottu> Launchpad bug 1561920 in linux-raspi2 (Ubuntu) "Seccomp error on recent builds of snappy" [Undecided,New]
<asac> ogra_: any idea when we will get that fix?
<ogra_> asac, i would assume as soon as the kernel moves out of proposed (where it sits since the 22nd)
<ogra_> you have to ask the kernel team what keeps it stuck there
<qengho> Between #1564369 and #1561920, my first day with new RPi3 is a sad one.
<ogra_> qengho, well, the first one has a workaround at lest
<ogra_> *least
<qengho> ogra_: does it?  Bind mount, or the correction?
<ogra_> not much we can do about the second one except waiting for the kernel to go to the archive (though i'm not sure that one actually has the fix already, ppisati would know)
<ogra_> bind mounting /dev/pts
<ogra_> you could bribe mvo to do an extra nightshift to fix all the mounting issues we have with the classic shell now though :)
<ogra_> (there is a bunch since a week or so)
<kyrofa> elopio, https://github.com/ubuntu-core/snapcraft/pull/421 easy review
<elopio> kyrofa: sorry, I still haven't figured out notifications on irssi.
<elopio> looking at your pr
<kyrofa> elopio, hahaha
<kyrofa> elopio, no problem, thanks for taking a look :)
 * elopio <- lunch
<asac> ogra_: guess i cant switch channel to downgrade to 4.3 kernel?
 * asac prepares a reflash
 * asac goes back to stable channel to get work done (TM)
<asac> how does/will it work in 16 to get top level cli entries? like docker?
<sergiusens> asac, name the app like the snap
<sergiusens> asac, that is already working
<asac> ic thanks sergiusens
<sergiusens> elopio, back?
<ogra_> asac, you can snappy install the older kernel snap
<ogra_> (with --allow-unauhenticated)
<asac> oh...ok... didnt know that
<asac> next time :)
<asac> pretty cool
<asac> now just switching channels then easy
<asac> ogra_: the pi3 ... is that working well?
<ogra_> so so... we have an issue with the serial console when using the pi3 uboot on a pi2 still (we want a shared image)
<ogra_> and the wlan firmware is missing
<ogra_> beyond that the pi3 is fine
<asac> graphics?
<ogra_> never tried
<ogra_> (neither on the pi2)
<qengho> I have a Pi3! I skipped the Pi2. I will help test or debug.
<dduffey> if I have a custom kernel snap, and downloaded a os.snap, what do I use for the gadget snap (standard amd64)?  or the full command line for ubuntu-device-flash
<kyrofa> dduffey, probably canonical-pc.canonical
<kyrofa> dduffey, https://github.com/zyga/devtools/blob/master/ubuntu-image may interest you
<mhall119> hey guys, I'm trying to play around with snapcraft, but "snapcraft add-part" says: No module named 'snapcraft.commands.add_part'
<mhall119> am I missing something?
<mhall119> snapcraft --help shows it
<dduffey> kyrofa, awesome ... I'm getting the following error (which is the same error when I try to run ubuntu-device-flash by hand)
<dduffey> expected 3 partitons but found 0
<qengho> mhall119! 'Sup. I want to say that's going away, but I could be wrong. In any case, sounds like a bug to report.
<dduffey> same if I use the ubuntu-image script and just select "pc", or run the following:
<dduffey> ./ubuntu-device-flash core rolling --channel edge --gadget canonical-pc.canonical --os xenial-preinstalled-core-amd64.os.snap --kernel kernel.snap/45-kernel_4.5_amd64.snap -o custom.img
<qengho> mhall119: I hate to say it, but I found the most instructive thing was to look at the snapcraft source code in  /usr/lib/python3/dist-packages/snapcraft /
<mhall119> qengho: heh, that's not ideal :)
 * zyga agrees with qengho
<zyga> mhall119: we should have solid manual pages
<zyga> mhall119: developer docs on the website are always out-of-sync
<zyga> mhall119: snapcraft is great when it works, utterely confusing when your file is wrong and you have no help to follow
<qengho> mhall119: You're using snapcraft on 16.04 yes?
<qengho> Silly question, I know.
 * zyga is supper happy about what's landing in snappy
<mhall119> qengho: yes
<zyga> jdstrand: all four backends are in place, I need to tweak apparmor slightly but I'm not only working on integrating with install/remove/upgrade
<mhall119> ok, next question, how do I specify a git branch name in a cmake plugin part?
<mhall119> oh, source-branch, dug
<mhall119> ignore me
<qengho> I just published my first package on 4 architectures, so I'm already pretty happy with it.
<qengho> zyga: Give a changelog precis?
<zyga> qengho: ?
<qengho> zyga: You're excited about changes in snappy. What changes?
<zyga> qengho: interfaces are an inch/cm away from working
<zyga> qengho: I'll blog about this heavily when it goes live
<zyga> qengho: (on g+ and planet ubuntu)
<mhall119> is there a way to not use `--depth 1` in the git plugin?
<zyga> mhall119: read the source :-(
<mhall119> yeah, I edited the source, I feel bad
<zyga> mhall119, sergiusens: is doing an amazing job coding but I feel that a tech writer could make snapcraft x10 more discoverable to everyone in a month
<mhall119> zyga: I agree, and I believe davidcalle is working on that
<zyga> oh, that's great to hear
<mhall119> when I'm not stealing him to work on the devportal deployments
<zyga> I know some people have been looking for technical training on snapcraft
<qengho> mhall119: When you make a plugin that extends git, you know you are pro.
<mhall119> or dholbach is stealing him to work on devportal docs importers
<mhall119> or dpm isn't stealing him to run scopes showdowns.....
<sergiusens> zyga, mhall119 not sure if davidcalle is just making our existing docs land into d.u.c
<mhall119> qengho: for not I just modified the code in /usr/lib/python3/dist-packages/snapcraft, so I just feel like a vandal :)
<sergiusens> they ones on d.u.c are outdated
<zyga> sergiusens: use readthedocs
<sergiusens> mhall119, why do you need to not use --depth 1?
<zyga> sergiusens: at least you'll have control
<mhall119> sergiusens: it causes the git clone to fail
<zyga> sergiusens: and you can have them built live
<sergiusens> zyga, I prefer md and just github, it is fully navigational as is
<zyga> sergiusens: well, whatever works
<sergiusens> mhall119, how so? I'll leave that to kyrofa but you must log a bug ;-)
<sergiusens> zyga, https://github.com/ubuntu-core/snapcraft/blob/master/docs/get-started.md
<mhall119> sergiusens: kyrofa: git clone --depth 1 --recursive --branch Subsurface-branch git://git.subsurface-divelog.org/marble /home/mhall/projects/Ubuntu/snaps/snappy-playpen/subsurface/parts/marble/src
<mhall119> try running that
<zyga> sergiusens: perhaps you could use github pages
<zyga> sergiusens: that's give you snapcraft.github.com, right?
<zyga> sergiusens: (sorry, that'd be ubuntu-core.github.io)
<qengho> You can cname too, so could be snapcraft.ubuntu.com
<zyga> sergiusens: e.g. http://zyga.github.io/git-lp/
<sergiusens> mhall119, I see it; I wonder why it doesn't work though
#snappy 2016-04-05
<mhall119> sergiusens: blame Linus :)
<sergiusens> mhall119, I can ask Dirk; I have some minor contributions to subsurface ;-)
<sergiusens> if anything they will save bandwidth ;-)
<mhall119> sergiusens: I may trouble you for help in the near future then :)
<mhall119> well, I almost certainly will trouble you for help, but it *may* be about subsurface
<mhall119> [ 83%] Linking CXX shared library libssrfmarblewidget.so
<mhall119> [ 83%] Built target ssrfmarblewidget
<mhall119> Makefile:160: recipe for target 'all' failed
<mhall119> make: *** [all] Error 2
<mhall119> Command '['/bin/sh', '/tmp/tmpiqorb2d5', 'make', '-j4']' returned non-
<mhall119> zero exit status 2
<mhall119> darn, I thought I was getting close
<thomas25> Hi
<thomas25> Last weeek end I was attending a conference in Lyon about snappy (given by didrocks) and I have a question I did not think about.
<thomas25> You are using squashfs to store the "snaps" but it is a read only fs, however you are also ablo to rollback the data.
<thomas25> So how do you store the data in the snaps ?
<didrocks> thomas25: hey! we don't store the data themselves in snaps, only the executables code+assets
<didrocks> thomas25: the data are just traditional file in a writable subdirectory
<didrocks> and we have a "current" pointer to know to which folder to point at
<thomas25> So you juste copy the data when you update the snaps ?
<thomas25> It means that a developer which package an app need to give all the data files present in its snap ?
<didrocks> thomas25: hardlinks (just need to recheck this though)
<didrocks> thomas25: no, this is the data that the snap is writing, not the assets
<didrocks> the assets is part of the code, and normally, not changed by the app
<didrocks> so this is part of the .snap file
<didrocks> (as they live on a traditional system in /usr/share for instance)
<thomas25> okay
<thomas25> Thanks for your quick answer and for the great conf last week end.
<didrocks> thomas25: with pleasure! Do not hesitate to come by if you have any other questions :)
<shuduo> hello, may i know if snap store still accept new snap for 15.04?
<zyga> shuduo: I think it should but I haven't checked
<zyga> shuduo: give it a try?
<shuduo> zyga: i submitted a snap built on 15.04 then be rejected by review tool. i guess only new version snapcraft will warn me. the fail msg is "Unexpected output from click-review."
<zyga> I don't know what's the cause of that
<shuduo> zyga: I see different set of snaps on store from 1504 snappy system and 1604. so if someone want to submit his/her app to both he/she should build twice and submit twice. right?
<shuduo> as 16 is under developent but i need show something with 1504, so i have to submit my app to store for 1504. even the store still accept it, i have to build it by 2.x snapcraft to make sure no warning and will not be rejected by store.
<zyga> shuduo: I believe so
<zyga> shuduo: snapcraft 2.x only works for 16.04
<zyga> shuduo: for 15.04 you have to use snapcraft 1.x
<shuduo> zyga: yes, i understood it.
<sergiusens> dholbach, hey, anything we can do about https://bugs.launchpad.net/snapcraft/+bug/1558296 ?
<ubottu> Launchpad bug 1558296 in Ubuntu Developer Portal "snappy build-apps broken link to devel ref page" [Medium,Confirmed]
<dholbach> sergiusens, I thought anyone of you would add their opinion to it?
<sergiusens> dholbach, is it generated from one of our MD files?
<sergiusens> kyrofa, is this still valid https://bugs.launchpad.net/snapcraft/+bug/1532515 ?
<ubottu> Launchpad bug 1532515 in Snapcraft trunk "Copy plugin doesn't copy symlinks" [Low,In progress]
<kyrofa> sergiusens, yes. I finally closed the PR as the discussion wasn't progressing
<kyrofa> sergiusens, I think we have a good solution for it though. Just need to do it
<kyrofa> sergiusens, oh wait
<dholbach> sergiusens, https://github.com/ubuntu-core/snapcraft/blob/master/docs/intro.md
<kyrofa> sergiusens, that may have been solved my the most recent copy plugin change
<kyrofa> sergiusens, let me test real quick
<sergiusens> kyrofa, yeah, that's why I ask; maybe a PR with a test is enough ;-)
<sergiusens> dholbach, ic, thanks
<kyrofa> sergiusens, yeah I haven't had my coffee yet
<didrocks> hey kyrofa, sergiusens :)
<sergiusens> hey
<didrocks> hum, seems files: is still required? wasn't my argument good enough yesterday?
<didrocks> (well, that can be enhanced later on, but I think there is a good use of having a consistent behavior by making it optional)
<jdstrand> zyga: hi! did you say that the udev branch landed or it is ready to landed? I ask because, well, I wanted to take a look but I also wanted to make sure of a couple of things, like the former oem assign (from oem.go) was preserved and that the lenient apparmor rules were conditionally applied only when hardware is assigned
<sergiusens> didrocks, I convince kyrofa to go the other way
<zyga> jdstrand: it has landed
<zyga> jdstrand: if you want to change it, go ahead
<zyga> jdstrand: note that hw-assign is gone (as soon as we land install with --developer-mode)
<zyga> jdstrand: so many things get simplified
<zyga> jdstrand: I'm working on install support and auto connect
<zyga> jdstrand: I'll ask you to review a small/boring branch that adds auto-connect flag to some interfaces
<jdstrand> zyga: well... I don't think I'm the right person to implement oem assign (ie, where the gadget snap does assignments for things that match stuff like idVendor, etc, and the udev interface is going to need to add an apparmor snippet
<zyga> jdstrand: I also created https://github.com/ubuntu-core/snappy/pull/785/files
<zyga> jdstrand: oem assign -> post 16.04
<zyga> jdstrand: current oem assign is gone
<zyga> jdstrand: kernel/gadget snap is specced for post 16.04
<jdstrand> zyga: oem assign is going to be needed for GA though, no?
<zyga> jdstrand: yes
<zyga> jdstrand: but perhaps as a different thing
<jdstrand> ok, that's fine
<zyga> jdstrand: I suspect it will be a way for the gadget snap to pre-connect stuff
<jdstrand> zyga: but hardware assignment still won't work with what you landed unless you already realized you had to add general apparmor rules when applying udev rules
<zyga> jdstrand: hw assign is removed too
<zyga> jdstrand: the replacement is developer mode and working on a new interface
<jdstrand> whatever its called doesn't matter
<zyga> it's not abou the name, we remove the functionality entirely
<jdstrand> the point I'm making is that what is using the udev backend won't work
<zyga> so anything that used to be related to hw-assign is gone
<jdstrand> because apparmor will continue to block it
<zyga> ah, I see
<zyga> I think we can ignore that and solve it with the first udev-using interface
<zyga> jdstrand: this week will be filled with more removals
<didrocks> sergiusens: mind if we discuss that during our standup?
<didrocks> sergiusens: I really think this just makes it verbose for no good reason (but again, we can change it later on, as it would be backward compatible anyway)
<jdstrand> zyga: ok, so it sounds like anything resemblinb hw-assign is gone forever, therefore you would never have a udev interface without a corresponding apparmor snippet. that makes sense (though it is very limiting while interfaces are being bootstrapped)
<didrocks> sergiusens: or beforehand otherwise :)
<zyga> yes
<zyga> jdstrand: yes, I think that's exactly true
<zyga> jdstrand: hence the change will happen with --developer mode
<zyga> jdstrand: I think for that we should let the launcher not create a device cgroup
<jdstrand> zyga: I don't understand what you mean by ghat
<zyga> jdstrand: so "everything is allowed"
<jdstrand> yeah, sure, that's fine
<zyga> jdstrand: ah, sorry, yes this limits usability while interfaces are being boostrapped but our idea is to use developer mode as a replacement
<zyga> jdstrand: so that in developer mode you can really access anything you like
<zyga> jdstrand: and steer towards creating proper interfaces
<jdstrand> cause cgroups don't log denials (it is just a DAC issue) and there is no complain mode
<zyga> jdstrand: yes, that's true
<zyga> jdstrand: I think it will be better than nothing still
<jdstrand> what I'm saying is no cgroups in developer mode is just fine
<zyga> jdstrand: and note that hw-assign can come back
<zyga> jdstrand: as an interface
<zyga> jdstrand: likely after 16.04 when hooks are back
<zyga> jdstrand: (or some simple state can be kept)
<jdstrand> well, hw-assign in some future interation of gadget assign for GA I suspect is going to have some interplay with the apparmor issue I just mentioned
<zyga> jdstrand: (I'd like to createa dir-assign interface that lets users create slices of $HOME for specific needs)
<jdstrand> s/of gadget/or gadget/
<zyga> jdstrand: (and hand those out to apps)
<zyga> jdstrand: hw-assign is _gone_ even for GA
<jdstrand> I understand that
<zyga> jdstrand: for GA we'll work with interfaces and setting up auto-connections
<jdstrand> you said "and note that hw-assign can come back"
<zyga> jdstrand: so whatever issues are ahead will be solved in an uniform way, not specific to hw-assign replacement
<zyga> jdstrand: I meant that the functionality can come back as a simple interface
<jdstrand> I knew what you meant
<zyga> jdstrand: and as you said we can then marry apparmor and udev
<zyga> jdstrand: sorry, I'm confusing today :-)
<zyga> jdstrand: I think we are good for 16.04 and we have a plan for a plan for GA
<jdstrand> I'm saying that simple udev matching as happens with current oem assign that is presumably going to be a part of GA gadget assign will have to deal with the apparmor issue I mentioned. whatever some future hw-assign looks like could also depending on how it is implemented
<jdstrand> anyway, this was meant to call out the issue that udev alone won't work
<jdstrand> not be an argument or prolonged discussion :)
<zyga> jdstrand: sorry I understand what you mean now
<zyga> jdstrand: I think I've seen a variant of this while working on a i2c interface locally
<jdstrand> yeah
<zyga> jdstrand: where I also used two subsystems to get it to work (udev and apparmor)
<jdstrand> cause things go hooping around in /sys/devices after they get the device in /dev
<zyga> jdstrand: I think over time our snippet-based approach might evolve to make some things like that easier
<jdstrand> hopping*
<zyga> but that's something post 16.04
<sergiusens> didrocks, sure, the only reason I said no to it was because it made things harder to explain to people; did I mention I hate the copy plugin? :-)
<jdstrand> so *if* hw-assign and oem-assign are gone, then is no issue (other than them being gone and not replced yet)
 * sergiusens goes out to run some errands
<jdstrand> zyga: as for dir-assign-- yes, we totally need that for sdoc
<didrocks> sergiusens: heh, yeah, you do :) however, with the current behavior and no filtering, depending on when you run snapcraft (after a first build or other parts are pulled), we may end up with other results
<zyga> jdstrand: what is sdoc?
<didrocks> sergiusens: anyway, yeah, if we change that later on, this will be backward compatible, so good :)
<jdstrand> zyga: at one point we said there would be a home-hidden interface that you'd set a property on (or whatever the term is) the interface to specify the directory. is that now a general purpose dir-assign?
<zyga> jdstrand: there was no bigger discussion on that that I'm aware of; dir-assign is just something I was thinking about as a cool and useful interface
<zyga> jdstrand: as a way to let a snap consume HOME and produce slices of home as separate interfaces
<zyga> jdstrand: and as a nice way to introduce more features (hook-based plugs/slots)
<zyga> jdstrand: it has many parallels to device discovery but is easier to work with (not hardware)
<jdstrand> ok, well as we decided last week, the security team would like to see branches to interfaces and changes to security policy whenever they are proposed
<zyga> jdstrand: noted and understood
<jdstrand> zyga: I look forward to the connecting stuff landing-- I'll let you work on it now
<ogra_> mvo_, you didnt merge all-snaps along the way to support the new adb in u-d-f `
<ogra_> ?
<mvo_> ogra_: no, support for bulding core images is temporarly removed until the final format of kernel and gadget snap is decided upon. plus the model-assertions work is pending
<ogra_> you are aware that we need to SRU even livecd-rootfs after release day to have the changes for the snaps we build ?
 * ogra_ would really like to have some kind of working state before release
<ogra_> or do you expect it to be "all-done" before ?
<shuduo> is there a workable example snap consuming docker just like old version owncloud snap?
<ogra_> hrm
<ogra_> ubuntu@localhost:~$ snap find
<ogra_> error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps?sources=store: dial unix /run/snapd.socket: connect: no such file or directory
<ogra_> (yesterdays ubuntu-core snap ... that used to work before)
<ogra_> seems like snapd isnt coming up on boot anymore
<ogra_> works after "systemctl start ubuntu-snappy.snapd"
<ogra_> mvo_, did you upload a new ubuntu-core to the store today ?
<ogra_> (seems whoever did that forgot armhf)
<shuduo> kyrofa: hello, do you know if there is a workable example snap consuming docker just like old version owncloud snap? I notice you are author of new owncloud snap but seems it does not consume docker.
<kyrofa> shuduo, not that I know of. Indeed, the new ownCloud is native
<ogra_> yeah, that would just be a massive waste of resources :)
<ogra_> but i would assume docker still works the same ... so grabbing the old owncloud from 15.04 might be enough to find the docker bits you need in it
<shuduo> kyrofa, ogra_ i have a customer use a close-source legacy software which run well with classic ubuntu 14.04. so seems only docker is solution to move to snappy.
<shuduo> ogra_: old owncloud is designed to be built by "snappy build".
<ogra_> i'm bnot talking about the snappy side :)
<kyrofa> ogra_, I actually imagine docker is broken due to interfaces
<ogra_> might be
<ogra_> but i assume the scripts you will need to set up the container and all that should still be the same
<kyrofa> shuduo, what makes you say that docker is the only solution? Just because it's closed-source?
<ogra_> so starting with an unconfined snap that consumes docker should work ... and then you slowly port over to interfaces once they are 100% done
<shuduo> kyrofa: yes, i think so. or maybe lxd works too
<kyrofa> shuduo, depending on how it works in the confined environment there's nothing stopping you from still snapping it
<shuduo> kyrofa: so i can use snapcraft to copy exist legacy binary with rootfs in place then run a script to run docker with a rootfs?
<kyrofa> shuduo, you can use snapcraft to copy the binaries into a snap and potentially run _without_ docker
<rajen> Hi, I am not able to build a snap due to download error. http://pastebin.ubuntu.com/15629597/ Any clue what is going on?
<ogra_> unless there are hardcoded versioned dependencies :)
<shuduo> kyrofa: yes, if it has no dependencies. :)
<ogra_> rajen, what is build_snap.sh ?
<kyrofa> shuduo, you can pull in .debs and whatnot and LD_LIBRARY_PATH will be setup for you-- not gonna work you think?
<rajen> it is our wrapper around "snapcraft snap"
<kyrofa> shuduo, I just think you'll run into some pain using docker in 16.04 right now is all. And I haven't heard anything that makes what you're discussing sound like it really needs it
<ogra_> sergiusens, ^^ do we use the hosts package lists ?
<ogra_> (looks like an "apt update" is missing there
<ogra_> )
<shuduo> kyrofa: it's a single prebuilt binary executive. not a deb.
<kyrofa> shuduo, I mean for its dependencies
<kyrofa> rajen, just gotta run again
<kyrofa> rajen, it's a temporary archive error
<rajen> I have been running it for the past 30min
<sergiusens> ogra_, not yet
<ogra_> where does it get the "us." from ?
<kyrofa> ogra_, geo location on the ip
<ogra_> inside snapcraft ?
<kyrofa> ogra_, yep
<ogra_> wow .. any way to override that ?
<kyrofa> ogra_, no, but we have a bug for it
<ogra_> heh
<rajen> "/etc/apt/sources.list" also has it as us...
<kyrofa> ogra_, actually because of people hitting exactly that problem-- archive errors that don't go away for a while
<rajen> By the way even "apt update" fails.
<kyrofa> rajen, which makes sense if they're using the same archive
<ogra_> kyrofa, yeah, i never use the german mirror on my dev machines (only on the stable ones)
<ogra_> simply because it is always a few hours behind
<kyrofa> Yeah
<rajen> So..do you want me to wait for few hours till all the archives are synced across geo's?
<ogra_> well, the hash sum mistmatch is happening if the publisher re-creates the sums on the server ... that usually takes only a few minutes
<sergiusens> ogra_, kyrofa 2.8 will use your hosts sources by default
<cjwatson> kyrofa,ogra_: proper fix for that should roll out today-ish
<ogra_> yay
<beuno> ogra_, you are are  #3 of the devs with most uploaded apps in the store (phone & snappy)
<beuno> congrats!
<ogra_> oh, who are #1 and 2 ?
 * ogra_ guesses popey is one of them :)
<ogra_> beuno, and thanks :)
<beuno> ogra_, if I tell you, I'd have to kill you.
<ogra_> lol
<dduffey> kyrofa, mvo_  so found the problem I was having building an image with ubuntu-device-flash, I was running it under a 16.04 lxc container and it didn't like that for some reason ... I ran it under a 16.04 KVM and the tool created an image
<kyrofa> dduffey, ah, yeah I've run into that as well
<dduffey> kyrofa, ubuntu-device-flash was updated today in ~mvo, so you'll need to update the md5
<kyrofa> dduffey, no idea why that happens
<kyrofa> dduffey, ah, zyga ^^ for your ubuntu-image script
<zyga> hmm
<zyga> dduffey: can you open a pull request please?
<dduffey> maybe lxc doesn't support kpartx / loopback devices and that is why it fails to run there?
<zyga> mvo_: is the updated version the one without core support?
<dduffey> zyga, not a dev ... just play one on TV :/
<mvo_> zyga: yes
<zyga> mvo_: ah, I see, thanks
<zyga> dduffey: so I guess for now we should not update
<zyga> dduffey: as that would entirely stop ubuntu-device-flash from working with snappy
<mvo_> zyga: so the package in the archive removed support. however the version on people.c.c still has it
<zyga> mvo_: ah,
<zyga> mvo_: has that one (on p.c.c) been updated as well?
<zyga> mvo_: should I update ubuntu-image to use it?
<mvo_> zyga: yes, some minutes ago, I'm doing some final testing
<mvo_> zyga: yeah, I do some final testing now, but we need a new one because snappy is no longer compatible with the previous one (the removal of the developer from all paths)
<oparoz> Hello, what's the path to the installed snaps from classic?
<zyga> oparoz: /snaps
<ogra_> schnaps !
<oparoz> zyga: It doesn't exist
<oparoz> zyga: ls: cannot access '/snaps': No such file or directory
<ogra_> yeah, i think there is an lxc container on classice where /snaps is
<oparoz> ogra_: Maybe it's a bug that /snaps isn't mounted, but is there a way to manually mount it in classic?
<oparoz> ogra_: Like mounting /dev/loopXX
 * ogra_ hanst dont anything with snappy on classic yet ... no idea, sorry
<ogra_> *done
<sergiusens> mvo_, or Chipaca` mind looking at bug #1566363 ? It looks unrelated to snapcraft but I'm not sure how this is possible at all
<ubottu> bug 1566363 in Snapcraft "snapcraft deb touches snap-package systemd files" [Undecided,New] https://launchpad.net/bugs/1566363
<sergiusens> dholbach, maybe you can explain this? ^
<dholbach> wow, no idea
<elopio> fgimenez: let's skip the meeting today. I wasn't productive yesterday, I'm running today :)
<fgimenez> elopio, ok np, i've been revamping the snappy-jenkins' data-container branch, so much that now it doesn't even uses data containers :D
<elopio> :D:D:D
<mvo_> sergiusens: this looks like chad has etckeeper running?
<fgimenez> elopio, this volume https://github.com/ubuntu-core/jenkins-ubuntu/blob/master/Dockerfile#L16 is enough for the purposes of the branch, it was there all the time
<mvo_> sergiusens: it gets called automatically when apt runs dpkg via a apt/dpkg integration hook
<mvo_> sergiusens: DPkg::Post-Invoke or Pre-Invoke
<fgimenez> elopio, anyway i've taken the opportunity to write the backup/restore scripts and the needed code to allow the configuration from the image to overwrite the files from the instance
<fgimenez> elopio, with this in place we only need the secrets branch, i hope that we'll redeploy tomorrow
<fgimenez> elopio, today i'll try to finish the practitest requirements, with the previous changes it won't take too long
<elopio> fgimenez: +1. sounds great.
<sergiusens> mvo_, thanks
<didrocks> sergiusens: waow, the bot is more advanced that I was expecting! (j/k)
<morphis_> sergiusens: was there a reason why snapcraft run was removed?
<sergiusens> morphis_, because `snappy try` was supposed to happen
<morphis_> sergiusens: which didn't?
<ogra_> morphis_, as usual :P
<ogra_> but it will :)
<morphis_> ogra_, sergiusens: I see :-)
<morphis_> ogra_: as usual :-)
<ogra_> :)
<qengho> sergiusens: sorry about that bug report.
<sergiusens> no worries
<rajen> Hi folks, I observed in latest ubuntu-core image that psuedo terminal behavior has changed. Inside our snap app we do an open /dev/ptmx and it in turn creates a /dev/pts/0  But in the latest image,  I don't see the /dev/pts/0 file. Any clue what has changed in recent times.
<zyga> rajen: AFAIR that's been changed in ubuntu-core-launcher
<zyga> rajen: more security, I don't know
<zyga> rajen: ask jdstrand
<rajen> okay will check with jdstrand
<nessita> elopio, hi! you around?
<oparoz> Is there a plugin which allows downloading a list of files from various sources? I don't want to have to create a part for each file
<elopio> nessita: hello!
<nessita> elopio, hi! I was chasing you for getting a green light on the latest changes we did for summary/description metadata field in the package index
<elopio> nessita: let me finish a couple of tasks, and I'll try uploads to staging. ~30 mins.
<nessita> elopio, great, thank you!
<zyga> oparoz: can you just download a tarball?
<zyga> oparoz: or stick those files into a git repo?
<oparoz> zyga: Not really, it's apps coming from various locations and I don't want to have to start maintaining a repo just to aggregate those apps
<zyga> oparoz: when you say apps, what do you mean exactly?
<oparoz> zyga: It looks like I need to write a go or pything plugin to do that, but I'm wondering if there isn't a use case here
<oparoz> zyga: I'm talking about apps published here per example: https://apps.owncloud.com/
<jdstrand> I talked to rajen in privmsg but will respond here for others
<jdstrand> this is a result of old-security/security-template going away and not being able to set confined
<jdstrand> unconfined*
<zyga> oparoz: how would those apps be consumed by users? as a part of an owncloud snap or as separate snaps?
<jdstrand> so the default policy is being applied, which currently doesn't allow /dev/ptmx
<zyga> jdstrand: thanks for doing this
<jdstrand> once all the interfaces stuff lands, I have some tweaks to policy that are queued up
<jdstrand> one is allowing /dev/ptmx by default now that we have a devpts newinstance and it is safe to do so
<zyga> jdstrand: you can make modifications to the security right now, interfaces/ is stable for 16 IMHO
<zyga> jdstrand: (except for more interfaces and misc changes to repo.go)
<jdstrand> zyga: it isn't enforcing yet is it or did that land today?
<oparoz> zyga: As part of the ownCloud snap. The ownCloud git tree comes with a default set, but I'd like to extend that set by downloading some apps from the app store when building the snap instead of writting a script which will download everything at install time
<zyga> jdstrand: it's not live yet, no, I'm still trying to get to a patchset that will be accepted
<zyga> jdstrand: plus mvo's branch hasn't landed so I'm also waiting for that
<zyga> oparoz: hmm
<zyga> oparoz: I'd do a custom plugin for now
<zyga> oparoz: to see that it works
<oparoz> zyga: That must affect other web apps which come with an app store as well
<jdstrand> ok. well I have a number of things I'm working on, but thanks for the heads up on me being unblocked to land stuff like that
<zyga> oparoz: when you have more experience with how it looks like we can think about what the next step is
<oparoz> zyga: Well, I know what it looks like since that's how it's done in the official VM already. I'm just trying to translate that into the Snappy world, but was surprised to see that source wasn't an array
<oparoz> zyga: It's simply, download, unzip and let the install script move these to the correct location at install time
<zyga> oparoz: I'd be surprised if it was
<zyga> oparoz: in any case, I'd suggest starting with a plugin
<zyga> oparoz: and a bunch of parts
<oparoz> zyga, maybe a simple makefile will do
<zyga> oparoz: good luck
<oparoz> :)
<elopio> nessita: is staging alright? I'm getting "Remote end closed connection without response" when I run the upload test.
<elopio> nessita: nevermind, I uploaded it fine now.
<nessita> elopio, ack! this particular test is about getting the right metadata from the package index
<nessita> elopio, so would that be covered by your tests?
<elopio> nessita: not on the previous one. I'm trying now to install the snap I uploaded, but snappy is not cooperating.
<nessita> elopio, any error I can help with?
<elopio> nessita: yes, I'm pasting it...
<elopio> nessita: https://paste.ubuntu.com/15636132/
<elopio> I see basic.snappy-test in the index. Do you know of something I might be missing?
<nessita> looking
<nessita> elopio, so the snap is there and I can download it, see https://search.apps.staging.ubuntu.com/api/v1/package/basic.snappy-test
<nessita> elopio, is available only on amd64, is that the arch you are using?
<elopio> nessita: yes, I can do that too. And yes, amd64.
<nessita> elopio, there seems to be something in the snap code that can not completes the operation. Have any more information?
<nessita> elopio, also, the main thing I needed QAd is that there is a new summary field, and the description field no longer has the summary (ex tagline) prepended
<elopio> nessita: I'm looking at the code. https://github.com/ubuntu-core/snappy/blob/master/store/snap_remote_repo.go#L261
<elopio> nessita: I can see that on https://search.apps.staging.ubuntu.com/api/v1/package/basic.snappy-test
<elopio> everything looks good on the cpi side. I can't install, but that might not be your fault.
<nessita> elopio, right, if you try again, does it work?
 * sergiusens is happy to know that the snapcraft side of the work is at least on track
<elopio> nessita: nop. I can install hello-world using staging, so that makes me a little uneasy.
<elopio> still, as so many things are in flux and will be changing soon, I don't worry too much about this. A deploy of this summary field to production seems a step forward.
<elopio> um, hello-world is not in the staging index, so it's likely not using this env var.
<nessita> elopio, oh, so is trying to use prod?
<elopio> nessita: ah, got it. It's just my fault, I was passing the env var on the wrong side of sudo. I installed it.
<nessita> oh, great news!
<elopio> nessita: so the install works. I have no way to show the summary because snap find is not working atm, but if anything is wrong there it should be fixed on the snappy side.
<elopio> nessita: so go for it, let me reply to the list.
<nessita> elopio, excellent, thank you
<elopio> sergiusens: is the summary going to be added to snapcraft.yaml ?
<elopio> oh, no, it's there already.
<nessita> elopio, is there already!
<nessita> elopio, and the store is parsing and using it
<elopio> nessita: I had to manually fill it when I hit publish.
<nessita> elopio, yeah, we are deploying that :-)
<elopio> nessita: on staging.
<nessita> elopio, was this a new package, or new version for existing package?
<elopio> nessita: a new version for an existing package.
<nessita> elopio, right, for this I followed the existing code, where new uploads do not change existing metadata for a package
<elopio> nessita: ok, I don't know what to expect there. Now that I'm here, let me do a new upload to confirm it fills the summary.
<nessita> elopio, a new package you meant, right?
<nessita> new upload, in the store terminology, is a new version for an existing package
<elopio> nessita: yes, that's what I meant, new package.
<nessita> great :-)
<elopio> nessita: +1.
<nessita> elopio, thanks!
<elopio> thanks to you.
<sergiusens> elopio, it already is, isn't it?
<code1o6> sergiusens, do you know Manik Taneja? he is reviewing my snappy app for permissions. Do you know his nic IRC?
<code1o6> sergiusens, *nick
<JamieBennett>  code1o6 its manik
<jdstrand> tyhicks: fyi, lp:~jdstrand/ubuntu-core-launcher/fix-udev-for-1604
<jdstrand> tyhicks: I'm moving to preparing the MP for seccomp arg filtering next
<tyhicks> jdstrand: I saw that but I think it is going to be hard for me to get to it today - what kind of timelines are you needing for that review?
<jdstrand> it doesn't have to be today
<sergiusens> code1o6, what JamieBennett said
<code1o6> JamieBennett, sergiusens thanks
<jdstrand> tyhicks: but trying to get these launcher changes done and into release so I can work on developer mode
<tyhicks> ok
<ogra_> code1o6: i think he is traveling today
<JamieBennett> ogra_, yeah, he is
<code1o6> ogra_, thanks
<code1o6> ogra_, JamieBennett , do you what timezone he is in?
<JamieBennett> code1o6, Pacific
<JamieBennett> *usually*
<JamieBennett> no idea where he is travelling to atm
<elopio> sergiusens: yes, it's just not updated when a previous version of the package exists.
 * elopio <- lunch
<qengho> I admire mksquashfs for being able to use 387.7% of my CPUs.
#snappy 2016-04-06
<T-mon> #unity
<sergiusens> morning
<sergiusens> kyrofa, is this good to go? https://github.com/ubuntu-core/snapcraft/pull/429
<kyrofa> Ah, sorry sergiusens looking now
<kyrofa> sergiusens, yeah I'm liking this
<kyrofa> sergiusens, looks like a pip hickup on the webui test?
<zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/801
<noizer> Hi guys how is it with the stable release of snappy?
<zyga> noizer: perhaps next week
<noizer> zyga:   niceee :D
<zyga> noizer: all depends on how good this week is :)
<noizer> zyga: Ok but that is just good news!
<sergiusens> kyrofa, its been like this the whole week
<ogra_> sergiusens, yo
<kyrofa> *grumble*
<sergiusens> kyrofa, but it works locally and on whatever the official autopackage tests servers are
<ogra_> sergiusens, so i'm planning to get rid of the binary initrd-generic package ...
<sergiusens> it is in my opinion and as elopio pointed out, scalingstack
<sergiusens> ogra_, why are you so mean?
<sergiusens> :-)
<ogra_> sergiusens, because i cant bear the headdaches that fakechroot gives me :)
<ogra_> sergiusens, so the plan is to run update-initramfs during image build before a kernel is installed
<sergiusens> ogra_, I will unleash the kraken on you by calling ricmm  ;-)
<ogra_> that should give us the same result but with a lot less hoops
<ogra_> hahaha
<sergiusens> ogra_, that means the image building tool is arch dependant?
<ogra_> you download the os snap anyway, right ?
<sergiusens> yes
<ogra_> indeed, it has always been arch dependent
<ogra_> so if i make sure the binary ends up in the same place the package did put it i guess we are fine
<ogra_> (and if i keep the name)
<sergiusens> ogra_, oh, so if you don't break the "interface" I really don't care :-)
<sergiusens> as long as a kernel generic initrd lands there
<ogra_> sergiusens, well, long term i'd like to clean that up
<ogra_> and keep the initrd in /boot or so
<sergiusens> which would also allow for step two which is for snappy to deal with that whole lot
<ogra_> right
<ogra_> for now i only want to get rid of fakechroot in the whole loop
<ogra_> (and also save one turnaround cycle in the whole game ... i.e. no extra upload of the package)
<sergiusens> ogra_, well the discussion with infinity was that the os snap would provide a kernel indep initrd and the kernel snap the one with modules; snappy would DTRT WRT how to deal with that
<ogra_> right
<ogra_> which is what i'm proposing above
<sergiusens> ogra_, your plan is sane ;-)
<ogra_> i initially went the package route because that makes it easier for porters
<ogra_> you only need to pull the one package, not the whole os snap ... but in the end it is more work and more risk on our side to do that
<sergiusens> ogra_, yeah, and fwiw, I didn't even take a hint on your guidance and just downloaded the os.snap ;-)
<ogra_> yeah
<ogra_> so evil !
<ogra_> :)
<zyga> https://github.com/ubuntu-core/snappy/pull/803
<zyga> jdstrand: ^ before we get the OS snap to declare those
<kyrofa> zyga, I have a piece of hardware whose install process in regular ubuntu involves a custom udev rule that runs its own script. Is there a way to do something equivalent in snappy using interfaces?
<zyga> kyrofa: yes
<zyga> kyrofa: can you tell me more?
<kyrofa> zyga, definitely. It's an intel RealSense camera (similar to xbox kinect, gets depth information). The classic installation guide is here: https://github.com/IntelRealSense/librealsense/blob/master/doc/installation.md
<zyga> ah, I'm familiar with it
<kyrofa> zyga, I'm hoping I don't actually need to patch uvcvideo, and that the only thing I'll actually need are the udev rules
<kyrofa> (since I know our kernel folks were working with them recently)
<zyga> kyrofa: does it require a kernel driver or is current kernel supported?
<zyga> kyrofa: this looks more like something to fix in the os snap
<zyga> kyrofa: and then expose as an interface for snaps to use
<kyrofa> zyga, I'm led to believe our kernel should support it, but I've not verified just yet
<zyga> kyrofa: in any case, yes, we can do suff with udev
<zyga> kyrofa: but you need to have a working kernel and you need to define the interface first (how apps would use this device)
<kyrofa> zyga, alright good deal. I'll get it working in a normal installation first and make sure I understand what's required, then I'll talk to you about the interface. Sound okay?
<zyga> kyrofa: yes, and once you are ready start a thread on snappy-devel please
<kyrofa> zyga, sounds good
<zyga> kyrofa: good
<zyga> :)
<kyrofa> sergiusens, I want to talk about https://bugs.launchpad.net/snapcraft/+bug/1537790 real quick
<ubottu> Launchpad bug 1537790 in Snapcraft "lifecycle: rebuild with snapcraft clean part1; snapcraft build part1 breaks if part1 has an 'after' field" [High,In progress]
<kyrofa> sergiusens, currently is part1 depends on part2, and you call `snapcraft build part1` it bails since it requires part2. So you have to say `snapcraft build part1 part2`
<kyrofa> sergiusens, how would you feel about it automatically building dependencies?
<sergiusens> kyrofa, currently with the new changes you mean? Previously we built through all of them
<sergiusens> kyrofa, we can do either; I like explicit so you know the implications
<sergiusens> but implicit is easier
<kyrofa> sergiusens, nothing new-- this is old. This test, specifically: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/tests/test_lifecycle.py#L30
<kyrofa> sergiusens, well, when I implemented the per-part cleaning for instance I made sure dependents were cleaned as well. I should probably either update that to raise for consistency, or update this to build dependencies for consistency. What do you think?
<kyrofa> per-step, rather
<sergiusens> kyrofa, ok, let's discuss that during standup
<kyrofa> sergiusens, sounds good
<zyga> https://github.com/ubuntu-core/snappy/pull/804
<zyga> jdstrand: ^^ probably not super security sensitive
<zyga> jdstrand: I'm persistently storing intents-to-connect
<zyga> jdstrand: so that when you upgrade a snap it gets re-connected
<zyga> jdstrand: there's no policy as to what happens when you remove a snap
<jdstrand> boy, lots of PRs :)
<zyga> jdstrand: heh, two days left :)
<zyga> jdstrand: I have lots of more locally but I'm blocked by bit landing now
<jdstrand> what's in two days?
<zyga> jdstrand: weekend
<zyga> jdstrand: I'd like to have peace of mind :)
<jdstrand> oh, heh
<jdstrand> then they pick up again next week, got it :)
<zyga> and actually work on my hobby compiler
<zyga> and use snappy to package a few games for my kids
<zyga> not that they have ssh or gpg keys in ~
<jdstrand> it would be nice to not dream about what is left to land every night and wake up at a reasonable time
<zyga> jdstrand: you can say that again;
<zyga> but I think we're super close now
<zyga> the only thing I'm worried about is everything not working in the end :D
<zyga> because of small issues that will be frustrating to fix for some unexpected reason
<jdstrand> I suspect those issues will be shallow
<jdstrand> at least for the existing builtins
<zyga> unless we forgot something major but I hope we didn't
<zyga> e.g. mandatory launcher change to fix something that's not fixable otherwise
<jdstrand> I've been working on the launcher a lot lately
<jdstrand> I think we are in ok shape wrt the security sandbox and interfaces. I've brought up what I know is missing
<zyga> jdstrand: pedronis is about to land some changes to how we invoke the launcher
<zyga> jdstrand: but that will change in a sec so even if we break something, it's temporary
<jdstrand> zyga: does that require a launcher change?
<kyrofa> pedronis, are you planning on removing the creation of the user data dir from the binary wrapper as well?
<jdstrand> or just the scripts/systemd stuff
<zyga> jdstrand: I don't think so; do you still parse the apparmor profile for snap version?
<zyga> jdstrand: in any case, I plan to see if this really works soon
<zyga> jdstrand: so we'll know :)
<jdstrand> zyga: the launcher doesn't parse the appname or apparmor profile name. it just takes what it is given
<zyga> jdstrand: then it should work :)
<jdstrand> zyga: it does a light regex: "^[a-z0-9][a-z0-9+._-]+$"
<jdstrand> but that is all
<zyga> mmm, should be fine
<jdstrand> zyga: is this the snap.<snapname>.<app> change?
<zyga> jdstrand: not yet
<zyga> jdstrand: that's what interfaces do
 * jdstrand wonders what change this is
<zyga> jdstrand: just gardening
<jdstrand> ok
<zyga> jdstrand: snappy has lots of redundant ideas
<zyga> jdstrand: we're killing some because it's impossible to make changes otherwise
<jdstrand> I see
 * zyga will return ~ 1 hour
<sergiusens> elopio, kyrofa seems our issue might be an upstream one https://bitbucket.org/ronaldoussoren/pyobjc/issues/141/error-code-9-with-pip-install-on-osx-10111 http://stackoverflow.com/questions/19632714/installation-error-of-python-package-using-pip
<sergiusens> I guess we can version lock pyyaml to avoid this
<kyrofa> sergiusens, good find!
<mhall119> sergiusens: is there a way to tell snapcraft the order in which to build parts? Or does it follow the order they are defined in the yaml?
<elopio> mhall119: you can alter the order with the after keyword. If you don't use that, then it would be the order in which python parses the yaml, which afaik is not always the same.
<elopio> sergiusens: thanks for the link.
<mhall119> thanks elopio
<sergiusens> mhall119, yaml by definition has no order; if you have dependencies use the `after` key
<kyrofa> Hey jdstrand what are the security limitations of `kill` in snappy? e.g. if I have a stop command for my service, am I limited in the signals I can send or the pids I can send them to? (I assume yes in the latter at least)
<jdstrand> kyrofa: you can send any signal to any app in your snap
<kyrofa> jdstrand, okay good deal
<jdstrand> kyrofa: you may not send signals to other snaps
<kyrofa> jdstrand, alright perfect, thank you :)
<qengho> kyrofa: yeah, I kill in one of mine. No trouble.
<kyrofa> I do too, just wanted to make sure I understood the limitations
<qengho> Though, I suspect I should be using systemd somehow to restart or signal it to reload. I don't understand systemd. :(
<code1o6> ssls
<code1o6> Is manik in today?
<netphreak> Hi, guys!
<popey> I have a bunch of snaps on my desktop which fail to launch because the application requires access to the openGL graphics card. It fails out like there's no libGL present - http://paste.ubuntu.com/15658255 - it's not just one app, a few common apps do this. Anyone seen this with graphical snaps?
<popey> Suggestions for things to try most welcome!  ð
<netphreak> Can anyone point me to a snappy gadget .yml for eg. Raspberry pi?
 * ssweeny saw a thread/discussion somewhere that said for instance if an app was built on a machine with intel graphics it won't work on nvidia and vice-versa until a solution is found
<ssweeny> popey, ^^
<popey> well that sucks
<popey> also, I am building on an nvidia machine and trying to run on same machine
 * popey looks for said thread
<ssweeny> a solution is in the works IIRC
<popey> found it, ta
<ogra_> netphreak, https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems
<netphreak> Superb, thanks ;)
<netphreak> I suppose one for RPI 3 will appear some time?
<ogra_> Yeah... Thereis one on my people.ubuntu.com account but I haven't put up the source yet
<ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/rpi3/
<netphreak> thx, ogra ;)
<netphreak> Will the rpi3 release support bluetooth?
#snappy 2016-04-07
<netphreak> how do i build a snappy gadget?
<mwhudson> mvo: ping
<mvo> mwhudson: pong
<mwhudson> mvo: did you see my question about golang-github-coreos-go-systemd a week ago?
<mvo> mwhudson: uh, I did but I did not looked into the details. we do use very little of systemd
<mvo> mwhudson: let me check
<mwhudson> mvo: maybe we just don't care then :-)
<mwhudson> in which case it case stay in -proposed until y for all i care
<mvo> mwhudson: we only use the "activation" part
<mvo> mwhudson: the activation.Listerners part to be precise
<mvo> mwhudson: I certainly do not care :)
<mwhudson> mvo: noted
<mwhudson> :-p
<oparoz> Hello. What should we do with packages which rely on alternative-updates (/etc/alternatives) ? Manually re-create all symlinks in the yaml?
<ogra_> which alternatives would they set (i mean, where..-. the alternatives system of the OS itself wont be reachable by the snap package)
<ogra_> all you could do it ship it inside your snap and set an alternative inside the snap work dir ... not sure that makes any sense
<oparoz> ogra_: the problem is that we're not being asked, some packages install their binaries that way and they will be missing from the snap if we don't do something
<ogra_> asked for what ?
<oparoz> ogra_: Where to install the binary
<ogra_> you could use the copy plugin to copy binaries around
<ogra_> the alternatives system in ubuntu doesnt ask you either normally ... it uses the defaults
<oparoz> ogra_: Well in the case of ImageMagick, they're not even being created in the snap, so symlinks have to manually be created
<ogra_> (that would be a viloation of "no asking questions" that we have in all ubuntu packages)
<oparoz> ogra_: Yes, that makes sense for Ubuntu, but since it's one of the things which doesn't work in s snap, I was wondering if the Snappy team had designed a workaround
<ogra_> and snapcraft does not run postinst scripts by design ...
<ogra_> so your best bet is to use the copy plugin i guess
<oparoz> ogra_: How do you copy a symlink whch doesn't exist?
<oparoz> ogra_: I guess it doesn't exist but outside of the snap where the package was installed
<oparoz> ogra_: *I guess it does exist
<ogra_> you copy a file to the name of the symlink
<seb128> so attente pointed out that removing/purging ubuntu-snappy still leads to snappy wanting to reboot your system
<ogra_> pitti, yo ... how are systemd timers supposed to be removed if a package that created it is removed ?
<seb128> seems like because the systemd timer is left behind
<seb128> what ogra said :p
<ogra_> heh :)
<seb128> I guess the snappy rm script should clean that out?
<seb128> what is adding the timer? is that the snappy postinst?
<ogra_> dunno
<ogra_> debian/snappy-autopilot.timer it seems
<oparoz> ogra_: If I use copy, I'll end up with a copy, not a symlink, the plugin help doesn't mention symlinks
<ogra_> right
<ogra_> you could file a bug against snapcraft to allw adding links
<ogra_> in the copy plugin
<oparoz> ogra_: I'll do that, thanks
<ogra_> til then, just copy them around as an interim solution
<ogra_> (its not like that will created gigabytes :) )
<ogra_> *create
<oparoz> ogra_: True, those files are tiny. I was just wondering about their dependencies if it used relative paths internally, but we'll see
<pitti> ogra_: hm, they aren't stopped with some autogenerated prerm "systemctl stop" commands from dh_systemd_start?
<pitti> ogra_: do you mind doing a bug report against init-system-helpers with details about this for reproduction?
<ogra_> i will have to check the snappy source
<pitti> sorry, /me just spent some 3 hours reviewing a 500 kB hilariously bad openssl patch, I need a break now
<ogra_> yeah, no hurry
<pitti> ogra_: at first sight, I guess the intention is that dh_systemd_start foo.timer ought to start it at package install and stop it at removal?
<pitti> or am I missing more context here?
<ogra_> no, thats correct ... the issue is that it keeps trunning even if the package is removed
<ogra_> there is no pre/postrm in the debian dir apparnelty
<ogra_> *apparently
<pitti> so I guess the timer is also not started on pacakge install
<ogra_> only a completely generic debian/ubuntu-snappy-cli.postinst
<pitti> or maybe it is, and dh_s_s is only doing half of its job
<pitti> oh, it should be autogenerated, not in teh source
<pitti> i. e. /var/lib/dpkg/info/package.{pre,post}rm
<pitti> dh_* goes into debian/rules, not d/{pre,post}{inst,rm}
<ogra_> ah
<ogra_> debian/ubuntu-snappy-cli.install ...
<ogra_> debian/*.timer /lib/systemd/system/
<ogra_> it is in the wrong package
<ogra_> mvo, ^^^ can we move the timer to ubuntu-snappy.install ?
<seb128> the rules has
<seb128> # we want the autopilot timer enabled by default
<seb128> 	dh_systemd_enable \
<seb128> 		-pubuntu-snappy \
<seb128> 		snappy-autopilot.timer
<ogra_> i guess thats enough (since we dont even seem to use debhelper here)
<seb128> but yeah, I guess the .install is wrong
<seb128> ogra_, you do ^
 * ogra_ is busy with livecd-rootfs atm ... i was hopng mvo could quickly do it with his next upload
<asac> docker not working on latest builds is known?
<asac> docker
<asac> /snaps/docker/1.6.2.005-16.04.1-2/bin/docker: line 4: /var/lib/snaps/docker/1.6.2.005-16.04.1-2/bin/bin_arch: No such file or directory
<asac> /snaps/docker/1.6.2.005-16.04.1-2/bin/docker: line 11: select_bin: command not found
<asac> ok ic
<asac> docker assumed that it gets started in the SNAP direcxtory
<asac> not DATA
<asac> kickinz1: when do you plan to do a new docker build?
<mvo> ogra_: hm, we need the autoupdate timer in snappy (or we won't get updates)
<mvo> ogra_: I guess what we don't want is the autoreboot
<ogra_> mvo, doesnt ubuntu-snappy debeond on -cli ?
<ogra_> *depend on
<mvo> ogra_: it does
<mvo> ogra_: but we want auto updats on the desktop as well
<ogra_> yeah, then we need to split out the reboot bit
<mvo> yes
<sergiusens> kgunn, mvo give me 5 min, I overslept and need coffee
<kgunn> sergiusens: mvo well...i completely overslept sorry
<kgunn> you likely didn't need me
<kgunn> ?
<sergiusens> kgunn, we were done in 10 minutes and then just caught up with life stuff :-P
<sergiusens> an email will come out soon explaining the plan
<kgunn> sergiusens: mvo i apologize...
<mvo> kgunn: no worries
<mvo> kgunn: I missed a pretty important meeting myself this morning too, so no worries.
<kgunn> :)
<mvo> kgunn: but sergiusens and I discussed the issue and I will send a mailafter my current meeting with the outcome. I think we have a good plan
<kgunn> that's great
<kgunn> mvo: sergiusens if my team can or needs to help in any way lemme know
<kyrofa> sergiusens, github now verifies signed commits!
<sergiusens> kgunn, actually I want to talk to you about the qml plugin; but later today as daytime is in diapers for us still :-)
<sergiusens> kyrofa, what does that mean? sorry for my lack of excitement :-P
<kgunn> sure
<sergiusens> kyrofa, fwiw, I finished the command refactor and am happy with it; I barely had to change any tests ;-)
<kyrofa> sergiusens, did you know you could sign your commits with your gpg key? I've always done it, but now github actually supports uploading your public key and it'll verify the commit actually came from that person
<kyrofa> sergiusens, ah, good news! I'll be looking at it momentarily
<sergiusens> kyrofa, I'm going to try and fix the webui one now; it is annoying me.
<kyrofa> sergiusens, sounds good
<sergiusens> kyrofa, maybe I won't disable as it didn't fail this time :-P
<kyrofa> sergiusens, *sigh*
<ysionneau> hmm there was a script to generate snappy image somewhere, does anybody have the url?
<ysionneau> called "ubuntu-image"
<ogra_> ysionneau, thats zygas script
 * ogra_ has lost the url though, i always just use ubuntu-device-flash directly
<ysionneau> I can't find it in his ~zyga web dir :'
<ogra_> it was somewhere on github iirc
<ysionneau> ah!
<ysionneau> https://github.com/zyga/devtools/blob/master/ubuntu-image
<ysionneau> here it is!
<ysionneau> thx
<kyrofa> ogra_ is elite though. He can remember all those magical incantations
<ogra_> haha, well, i usually need my special incarnation anyway ... so a wrapper script just gets in the way :)
<kyrofa> ogra_, good point
<qengho> On config change, should I be using systemctl/systemd to reload the configuration of services that my snap provides?
<qengho> I would guess I'm supposed to have implemented all my own PID-finding-and-killing logic, but that makes me sad.
<ogra_> snappy service ...
<qengho> ogra_: Is that requirement supposed to be exposed to the user?  On "snappy config NewFile", they should know this program needs to get "snappy service restart"?
<ogra_> well, dont you require sudo for your cobfig call ?
<ogra_> *config
 * ogra_ wouldnt let ordinary users change snap configs 
<qengho> ogra_: Yes, config file is writable by root only. Why?
<ogra_> and i think there was a bug open for Chipaca` to actually tellÃ¶ users about the needed service restart or do it automatically
<qengho> Ah!
<elopio> nessita: is there a group without the 24 hour restriction for registering snaps?
<elopio> I have to add like three today.
<nessita> elopio, nopes, but we are lowering that right now to 3 minutes
<nessita> elopio, branch is on its way to trunk and then staging
<qengho> tar-content plugin is going away. copy replaces it. But, copy also requires "files" schema key. Hrm.
<elopio> nessita: ok, I can live with 3 minutes. Thanks.
<netphreak> hi, guys!
<nessita> elopio, Ã³/
<nessita> \o/
<netphreak> I have a snap.yml gadget file and some boot-assets. How do i build a image?
<kyrofa> qengho, if you want to duplicate how tar-plugin works, just use '*': '.' for files
<kyrofa> qengho, it's just explicit is all
<noise][> mvo: I'm assuming desktops will use the same 4x daily (spread out) autoupdate checks? is that accurate?
<mvo> noise][ yes
<mvo> noise][ that is the plan at least - any concerns?
<noise][> mvo: excellent, thanks
<mvo> noise][ fwiw, the apt timer change has also landed in xenial
<noise][> mvo: apt timer change?
<mvo> noise][ oh, nevermind
<mvo> noise][ sorry, I I thought you might be concerned about upload load in general, snappy is one part of it, apt is another one
<noise][> ok, my main concern is just that snappy doesn't hammer the package index in herds, and sounds like that's sorted (or will be for desktop as well)
<netphreak> What's the latest version of snap craft?
<sergiusens> kyrofa, fixed your commented things except for the execute one which I don't really follow
<kyrofa> sergiusens, just a typo in the doc string
<kyrofa> sergiusens, not part of your PR technically
<kyrofa> Not super important
<kyrofa> netphreak, 2.7
<sergiusens> available for xenial only
<kyrofa> netphreak, future reference: https://github.com/ubuntu-core/snapcraft/releases
<sergiusens> kyrofa, oh, sorry my eyes read it correctly! :-P
<kyrofa> netphreak, indeed. For pre-xenial, 1.1.0
<kyrofa> sergiusens, hahaha, I had you questioning your english skills
<sergiusens> kyrofa, done :-)
<sergiusens> kyrofa, more that there's a docstring PEP mentioning the language of a docstring (Execute or Executes)
<kyrofa> sergiusens, ohhh
<netphreak> How do i upgrade to the latest xenial version?
<kyrofa> netphreak, just apt-get upgrade
<kyrofa> (assuming that you're running xenial, of course)
<netphreak> which i'm not ;)
<kyrofa> netphreak, then you'd need to run from source, which can be done but will have some issues and may not build snaps that can actually target 16.04
<kyrofa> netphreak, I can walk you through that if you want to do it anyway
<netphreak> ok.. i'll just download a xenial virtual box image, if available?
<netphreak> might save us both some time ;)
<kyrofa> netphreak, do you have any device with snappy ubuntu core 16.04 on there?
<netphreak> nope
<kyrofa> netphreak, because you can run snapcraft from there (and then test out the resulting snap immediately)
<netphreak> I'm just about to get into the whole world of snaps ;)
<kyrofa> netphreak, you can do that in vbox if you like. But if you just want the normal desktop, just use http://cdimage.ubuntu.com/daily-live/current/
<netphreak> vbox is fine.. I have my other devtools running on osx
<sergiusens> kyrofa, netphreak I wouldn't run from source; I'd install lxd and create a xenial container
<sergiusens> I do that on my DO droplet to work from my phone ;-)
<kyrofa> netphreak, let me be more clear. If you run ubuntu desktop in a VM, you'll need to have another snappy install to run the snaps (e.g. another VM). You can, however, use snapcraft from the snappy install directly, thus potentially saving you a VM
<sergiusens> oh that works too
<netphreak> ahh.. well.. i Have a Raspberry 2 lying around i will install ubuntu snappy on - to test the snaps
<kyrofa> sergiusens, yeah that's my daily workflow-- my dev laptop is still trusty
<kyrofa> netphreak, ah, snapcraft doesn't cross-compile, so you should probably run snapcraft from there as well
<kyrofa> (lxc I mean)
<netphreak> my plan was to make a gadget (provision) a custom image for the rpi.
<sergiusens> vila, hey I saw your macaroon branch, a bit too late though; it looks good but there was a refactor going on in place; would you mind rebasing? If not I can do it for you. It's about https://github.com/ubuntu-core/snapcraft/pull/433
<vila> sergiusens: rebasing is not a problem. /me looks at pull/443
<netphreak> is this possible from a VM with Xenial?
<kyrofa> sergiusens, yeah this looks good, only have the [<directory> --output <snap-file>] thing now
<vila> sergiusens: also, are you ok with me proposing that work piece by piece or do you prefer to see the whole first ?
<kyrofa> netphreak, yeah that should be arch-independent
<netphreak> ok.. thx.. ;)
<kyrofa> vila, smaller PRs are ideal
<netphreak> Another question.. The snappy maven plugin.. Does it support other versions than openjdk 7?
<vila> sergiusens, kyrofa: RIght, but given the flux in the store with macaroons, I'll have to carry some more baggage (like the SNAPCRAFT_WITH_MACAROONS env var) during the transition. If it's ok for you, it's ok for me ;)
<kyrofa> vila, we can always land to an intermediate branch for easier reviews, then one big merge once the feature is done
<sergiusens> vila, as kyrofa mentions, an intermediate branch might be better
<vila> sergiusens, kyrofa: right, things are still too much in flux to know what's the best ;) I'm working locally on a stack of branches anyway, I'll come back when things get clearer
<vila> sergiusens: wow, that pull/433 shuffle lots of things around, time for me to re-learn ;)
<sergiusens> vila, not that much; ideally snapcraft.config and snapcraft._store should go into snapcraft.storeapi; we inherited snapcraft.storeapi because no one wanted to push a new package into ubuntu and we were involved late in the game ;-)
<vila> sergiusens: ack. Yeah, well, if there was a package in ubuntu today it would make our life harder anyway ;) Let's revisit when the dust settle...
<vila> sergiusens: oh, pull/433 hasn't landed yet ! Close to EOD so I'll rebase tomorrow. What was the rationale to get rid of the commands ?
<kyrofa> Hey ogra_ any idea why libxml was removed from the edge ubuntu-core?
<kyrofa> vila, trying to get rid of some global state and better command-line parameters
<ogra_> kyrofa, are you sure it was ever there ?
<kyrofa> ogra_, yeah unsquashfs comparing stable to edge
 * ogra_ doesnt see it removed within the last weeks on http://people.canonical.com/~ogra/core-image-stats/
<ogra_> kyrofa, stable ?
<ogra_> 15.04 you mean ?
<kyrofa> ogra_, ah, I'm talking about the ubuntu-core snap
<kyrofa> ogra_, no, the channels
<ogra_> we never had a stable release of 16.04 to my knowledge
<vila> kyrofa: ack, thanks
<ogra_> ah
<ogra_> kyrofa, seems it was dropped here http://people.canonical.com/~ogra/core-image-stats/20160318.changes
 * ogra_ would suspect the dhcp client dropped a superflouous dep
<sergiusens> vila, long story short, we are getting rid of global state in `common`
<kyrofa> ogra_, ahh, okay
<sergiusens> vila, so we are creating a ProjectOptions class and initializing with that
<sergiusens> vila, the problem is, we will end up with a bunch of comand duplication and sanity check code if we kept commands
<sergiusens> vila, like seen here https://github.com/ubuntu-core/snapcraft/pull/430/files#diff-d2ba7d06874f884cc15ce0ef1fa9d31fR27
<vila> sergiusens: ack, thanks for the detailed explanation, appreciated (will save me time when rebasing) !
<ogra_> kyrofa, bug 1551351 and bug 1556175 ... seems the dhcp client switched to use some internal libs instead because they handle signals differently
<ubottu> bug 1551351 in isc-dhcp (Ubuntu Xenial) "dhclient does not renew leases" [High,Fix released] https://launchpad.net/bugs/1551351
<ubottu> bug 1556175 in isc-dhcp (Ubuntu) "networking.service hangs on shutdown -- killing dhclient has no effect any more" [High,Fix released] https://launchpad.net/bugs/1556175
<kyrofa> ogra_, ah very interesting, okay thanks for digging into that! :)
<ogra_> np
 * ogra_ finds it funny that firefox offers to open snaps with vlc 
<netphreak> ogra_: How do i build/assemble a gadget (downloaded the one you gave me a link to yesterday)
<ogra_> netphreak, currently still with snappy build --squashfs
<ogra_> i hope to get to it tomorrow to make it use snapcraft snap instead
<netphreak> ok ;)
<netphreak> thx for the pointer..
<ogra_> sergiusens, so it would be nice to have snapcraft use /boot/initrd.img-core instead of /usr/lib/ubuntu-core-generic-initrd/initrd.img-core with the kernel plugin, do you need a bug for that ?
<ogra_> (i copy it from /boot to /usr/ib atm but would like to drop the duplication before release)
<netphreak> Is it possible to setup a private snap repo?
<kyrofa> ogra_, please do make a bug if you can
<ogra_> sure
<netphreak> any docs on that?
<kyrofa> netphreak, I don't believe that's supported. Not sure if there are plans to
<ogra_> bug 1567564
<ubottu> bug 1567564 in Snapcraft "kernel plugin should use initrd from /boot in the os snap, not from /usr/lib" [Medium,New] https://launchpad.net/bugs/1567564
<ogra_> kyrofa, ^
<kyrofa> ogra_, thank you!
<ogra_> np
<netphreak> according to this it might be?
<netphreak> https://lists.ubuntu.com/archives/snappy-devel/2015-October/001076.html
<sergiusens> ogra_, yes please
<kyrofa> netphreak, ah, I do actually think the store supports private snaps. I remember seeing something about that
<sergiusens> ogra_, I can land the change as soon as the ubuntu-core that is in makes its way to stable
<ogra_> sergiusens, well, we dont have a stable 16.04 yet
<ogra_> (we really should just throw one out ... even without any testing so we have a base to work with)
<kyrofa> ogra_, not sure what I got when I generated a stable image then :P
<netphreak> iÂ´ve browsed through lots of documentation - but can't seem to figure out how it works..
<ogra_> kyrofa, most likely some old tarball based thing
<ogra_> none of the all-snap builds have been pushed to stable yet to my knowledge
<kyrofa> ogra_, I'm able to install all-snap stuff there... curl https://search.apps.ubuntu.com/api/v1/package/ubuntu-core
<ogra_> and we never actually released any image on cdimage
<kyrofa> Huh.
<ogra_> http://cdimage.ubuntu.com/ubuntu-snappy/
<ogra_> only 15.04
<ogra_> i know that elopio and mvo wanted to do that and then we didnt
<ogra_> ... and i guess now we are waiting for the changes to gadget and kernel ... (once again)
<kyrofa> ogra_, edge breaks every other day. Is that really all there is?
<ogra_> yes
 * kyrofa cries
<ogra_> 16.04 all snaps never had an actual release
<ogra_> only what mvo and I produce in your people.canonical.co dirs
<ogra_> *com
<kyrofa> ogra_, which is all edge then, I assume?
<ogra_> yeah
<kyrofa> That doesn't explain why I can install my squashfs snaps on the image I generated using stable though
<ogra_> thoggh it might be that mvo released one of each snap to stable for his images (but they still werent released in the actual release spot)
<kyrofa> ogra_, yeah maybe that's it
<kyrofa> Hmm... ogra `snappy purge` seems to be gone. Know anything about that?
<ogra_> nope ... but someone complained that snappy purge only works after you called snappy remove
<ogra_> (which i found weird TBH)
<kyrofa> ogra_, yeah I remember seeing a special purge flag in the code that will allow you to purge an installed snap
<kyrofa> But now `snappy purge` results in "Unknown command `purge'. Please specify one of [...]"
<ogra_> my focus was more on image builds this week though ... i didnt do much inside snappy systems themselves
<ogra_> so i wouldnt have noticed it being dropped
<kyrofa> Ah, apparently `remove` also purges now
<kyrofa> So they removed purge
<ogra_> they purged it :)
<kyrofa> ogra_, by the way, thanks to the launchpad builders, I published owncloud for arm64 a few days back
<kyrofa> (finally)
<netphreak> ubuntu-device-flash gives me an error 'unknown flag `gadget''
<netphreak> Running on 16.04 desktop
<sergiusens> kyrofa, can you merge master?
<kyrofa> sergiusens, did it ages ago ;)
<kyrofa> i.e. about 2 minutes
<sergiusens> kyrofa, heh, so the squashing thing has changed a bit
<kyrofa> sergiusens, how so?
<sergiusens> kyrofa, look at the commit
<sergiusens> kyrofa, it adds a ref to the PR
<kyrofa> Hmm
<sergiusens> kyrofa, what I regret is that I didn't pay attention to the small box for the message and got the stack of commits in there
<kyrofa> sergiusens, doesn't look like you cleaned up the squashed commits either :P
<kyrofa> sergiusens, yeah I say fix it
<sergiusens> kyrofa, you wanna do it? pretty please? :-)
<kyrofa> sergiusens, doing now
<kyrofa> sergiusens, so should we leave titles off of that little box, then? Since it puts in the reference?
<kyrofa> Just make sure the PR title is what we want?
<sergiusens> kyrofa, I am lost with what you mean
<sergiusens> what little box?
<kyrofa> When you merge, the box with the message in it
<kyrofa> Or was this in there?
<kyrofa> My questions will be answered next time I merge something. Just let me do the next one
<sergiusens> oh, that has the bug number and the sign-offs, not sure we can just wipe it
<sergiusens> kyrofa, by default it prefills with all the commits
<sergiusens> kyrofa, you have to edit to get the right thing still
<kyrofa> Oh no, I didn't mean wipe it. I was asking if github ALSO adds the title to it
<sergiusens> kyrofa, it adds it because there are N commits
<kyrofa> sergiusens, do we like the PR references?
<sergiusens> kyrofa, I think we do; but that was automatic
<kyrofa> Sounds good, just want to know for my cleaning here
<kyrofa> sergiusens, note those references will show up in our changelogs
<kyrofa> Which might actually be awesome
<kyrofa> sergiusens, fixed by the way
<sergiusens> kyrofa, remerge yourself now then :-)
<kyrofa> sergiusens, already done
<kgunn> so i just took a moment to update and try to build with snapcraft 2.7....not sure it's 2.7s fault...but i'm failing
<kgunn> curious what anyone else is experience is?
<kgunn> i've built mir snap easily with no issues updating each time since 2.2
<stgraber> jdstrand: lxd 2.0 rc9 uploaded to the store
<oparoz> Is /tmp noexec in a snap?
<oparoz> Or is it even writable?
<sergiusens> kgunn, what's the error?
<Domi> Hello, I have to write a paper on Windows IoT and Ubuntu Snappy Core. What hardware should I get to try these Operating Systems? Raspberry Pi 2 or 3?
<jdstrand> stgraber: approved
<stgraber> jdstrand: thanks
<catbus1> Hi, snapcraft login uses ubuntu one sso, I entered the email, password with or withou the one-time password, neither worked.
<catbus1> Failed to establish a new connection: [Errno -3] Temporary failure in name resolution
<catbus1> uh dns doesn't work
<catbus1> nm
#snappy 2016-04-08
<sergiusens> kgunn, I am back if you still have issues or a question
<Domi> Does anyone use Ubuntu Snappy on a Raspberry Pi 3?
<sergiusens> kgunn, here's the solution http://paste.ubuntu.com/15680718/
<sergiusens> kgunn, but fwiw, you can also just move those stage-packages to build-packages
<sergiusens> kgunn, also, mircommon should provide a .pc file ;-)
<robert_ancell> Is there a method to extract metadata from a .snap file?
<vila> kyrofa, sergiusens: https://github.com/ubuntu-core/snapcraft/pull/427 should be mergeable now
<vila> sergiusens: and https://github.com/ubuntu-core/snapcraft/pull/428 has been rebased
<vila> sergiusens: huh ? You're up ?!?
<sergiusens> 7am
<sergiusens> yes
<sergiusens> just a bit before coffeee :-)
<vila> sergiusens: haaaa ! ok ;-)
<vila>  https://github.com/ubuntu-core/snapcraft/pull/428 has been re-rebased
<vila> sergiusens: enjoy coffee ;-)
<vila> sergiusens: a bit of advice needed: https://pastebin.canonical.com/153789/ the second chunk breaks the alignment of command descriptions, should I just fix them (no tests are failing is that expected ?)
<sergiusens> vila, yeah, just shove the rest so they are aligned
<sergiusens> vila, leave 2 spaces between the command and desc (it is not parsed by docopts but is consistent with Options)
<vila> sergiusens: ha ! 2 space, ack, will do
<kyrofa> Good morning
<sergiusens> kyrofa, mind reviewing the geoip branch?
<kyrofa> sergiusens, sure!
<sergiusens> kyrofa, thanks!
<sergiusens> kyrofa, and I didn't say good morning as I thought you weren't in yet :-P
<sergiusens> sort of a fire and forget thing ;-)
<kyrofa> sergiusens, haha, I'm offended
<kyrofa> Good morning ;)
<zyga> jdstrand: I got interfaces to work
<zyga> jdstrand: I have a pile of patches, some will need your approval
<jdstrand> zyga: ack-- I've got a number of things going on this morning. I can probably start looking at stuff in ~4 hours
<kyrofa> sergiusens, our commit messages are garbage with this squash thing. We need to keep the wrap at 72
<zyga> jdstrand: ok
<seb128> is the "snap" command supposed to work out of the box?
<seb128> or what is it used for?
<seb128> is that a snappy tool? :p the manpage doesn't even introduce/describe it
<ogra_> it is supposed to replace the "snappy" command
<seb128> no description
<seb128> just the arguments
<ogra_> something at least :P
<kyrofa> seb128, snap is the snappy commands successor. snappy makes direct function calls, whereas I believe snap uses snapd
<kyrofa> seb128, I'm surprised there's a manpage at all :P
<seb128> on a fresh xenial install, "snap find" gives a "error: cannot list snaps: cannot communitcate with server: Get http://localhost... /run/snapd.socket no such file or directory"
<ogra_> kyrofa, for archive inclusion you need it :)
<kyrofa> ogra_, ahhhh
<ogra_> seb128, what arch is that ?
<seb128> i386
<ogra_> native or vm ?
<seb128> virtualbox
<ogra_> looks like there is something with your network
<seb128> desktop install
<ogra_> so snapd didnt start
<ogra_> oh, desktop install
<ogra_> i wonder if mvo removed to much from the ubuntu-snappy-cli command ... we definitely need the snapd systemd unit
<ogra_> s/command/package/
<mvo> ogra_: I got a report like this yesterday too
<mvo> ogra_: I'm not sure, something is broken
<seb128> the systemd job is loaded but inactive
<ogra_> aha
<jdstrand> zyga: if it would help, feel free to send an email, otherwise I'll circle back
<ogra_> i see something similar on a rpi3 where i manually need to start the snapd service ... might be some race
<zyga> jdstrand: it's okay, no rush :)
<seb128> ogra_, mvo, works after a "systemctl start ubuntu-snappy.snapd"
<ogra_> yeah
<seb128> so the job is not active by default?
<ogra_> well, i see it active on a dragonboard and pi2 ... i dont see it active on a pi3
<ogra_> which makes me suspect some race with i.e. network bringup
<seb128> ogra_, mvo, ubuntu-snappy.snapd has a After=...firstboot which is an unit in ubuntu-snappy not -cli
<seb128> unsure if that's the issue
<seb128> I don't remember what systemd does in those cases
<seb128> there is no Requires so does it prevent start anyway?
<ogra_> thats most likely the issue, i think firstboot moved to ubuntu-snappy
<seb128> right
<seb128> also firstboot fails to start
<seb128> "Unknown interface unp0s3"
<seb128> "no gadget snap"
<seb128> is what is in the status log
<ogra_> fun
<cjwatson> ogra_: archive inclusion> erm, not true, not that I object to stuff having man pages
<cjwatson> it's recommended but not a requirement
<ogra_> isnt that linitian complaint a blocker ?
<cjwatson> no
<ogra_> oh, i thought it was
<cjwatson> don't let me discourage you from writing man pages, of course, but it has never been a blocker :)
<ogra_> heh
<ogra_> i usually try to get my new submissions linitian clean ... (though i usually also only do that for the first upload)
<ogra_> (like most people i guess  .... :P )
<elopio> sergiusens: kyrofa: this is finally ready for a review: https://github.com/ubuntu-core/snapcraft/pull/418
<Domi> Hello, does ubuntu core work on Rasbpery pi 3?
<ogra_> Domi, still experimental but here is an image http://people.canonical.com/~ogra/snappy/all-snaps/rpi3/
<Domi> ogra_ I have to write a paper on ubuntu core. Will it boot and work so that I'm able to get an impression ?
<ogra_> yes, but be aware there might still be bugs
<Domi> ok I just have to decide if I buy a Raspberry pi 2 or 3 but my mentor at the universtiy would favor the raspberry pi 3.
<ogra_> that image works on both ;)
<Domi> ok but is it alpha, beta or close to release on the rpi3?
<ogra_> somewhere between alpha and beta i'd say
<Domi> ok then I will go with the raspberry pi 3. Thank you for your support. I think there is a post that offical support of the raspberry pi 3 will start on 16.04 is that correct?
<zyga> jdstrand: okay, I'm close to having something for you to review
<zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/838
<zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/840
<zyga> jdstrand: I'd like to change template.go so that we don't have all those confusing old variable names for 16.04
<zyga> jdstrand: and keep just SNAP_NAME, SNAP_REVISION and APP_NAME
<zyga> jdstrand: if you agree I'll do the branch
<sergiusens> kgunn, hey, did you catch my response on irc last night?
<kgunn> sergiusens: yes i did and thank you!
<kgunn> just haven't had a chance yet to follow up
<sergiusens> kgunn, great
<sergiusens> kgunn, also, qml plugin; I want to get rid of it but I saw you use it or some form of it still so maybe it shouldn't go away; I do want to reform it though
<sergiusens> the main thing it has is setting up config and envvars,  right?
<ogra_> YAAAY ... !
<ogra_> snappy build all gone from the image builds !
<ogra_> (all snapcraft now)
<sergiusens> \o/
<netphreak> hi, guys!
<netphreak> How do i install latest snap craft..
<netphreak> appears i only have 1.1.0
<zyga> netphreak: you need to use ubuntu 16.04 daily images for that
<netphreak> makes sense
<netphreak> thx
<kgunn> sergiusens: wrt qml plugin, do you mean qtmir? that is the plugin i/f for qml to render on mir surfaces...so don't think we can get rid of that
<kgunn> or did you mean something else?
<sergiusens> kgunn, the snapcraft qml plugin
<sergiusens> kgunn, an in ref to the example client you have which has a local plugin there doing sort of what the qml plugin does
<kgunn> sergiusens: oh!!
<kgunn> :)
<kgunn> yeah, if you wanted to drop qml plugin, we could easily move anything i'm relying on into the local pluing of my snap
<kgunn> it's an example anyhow...and should be used as a template to fork
<kgunn> by other qml/mir client app devs
<zyga> jdstrand: I've sent you two pings on github
<zyga> jdstrand: if you follow on them quickly we _might_ merge the switch to interfaces today
<mhall119> sergiusens: I need help with snapcraft and the python2 plugin
<mhall119> I'm trying to package a simple python2/gtk3 app
<mhall119> and I get this: http://paste.ubuntu.com/15691803/
<zyga> mhall119: that looks like distutils vs setuptools
<netphreak> I'm trying to build a gadget, with a built-in snap, and get the following error:
<netphreak> http://pastebin.ubuntu.com/15692050/
<ogra_> is system-status.victor in the store (for the channel you build for)
<ogra_> the snaps get pulled from there :)
<netphreak> It's located in the store here:
<netphreak> https://uappexplorer.com/app/system-status.victor
<netphreak> i set the channel to victor
<ogra_> netphreak, you set the channel to "victor" ?
<ogra_> it needs to be in the channel you use for your ubuntu-device-flash command ... i.e. "rolling --channel=edge"
<ogra_> (that would be the 16.04 "edge" channel)
<netphreak> failed to install "system-status.victor" from "edge": system-status.victor failed to install: snap not foundfailed to install "system-status.victor" from "edge": system-status.victor failed to install: snap not found
<netphreak> failed to install "system-status.victor" from "edge": system-status.victor failed to install: snap not foundfailed to install "system-status.victor" from "edge": system-status.victor failed to install: snap not found
<netphreak> failed to install "system-status.victor" from "edge": system-status.victor failed to install: snap not found
<netphreak> sorry
<mhall119> zyga: what would my fix be in that case?
<zyga> mhall119: fork that code for a sec and use setuptools in setup.py; if that fixes it then you are good to go
<zyga> mhall119: if not then ignore me
<zyga> mhall119: the error you're seeing is because (apparently) snapcraft uses something that's setuptools-specific (which is sensible because disttools are terrible)
<zyga> s/disttools/distutils/
<mhall119> hmmm, I think quickly used distutils :(
<zyga> mhall119: it might be possible to support distutils in the plugin; you'd have to check with sergiusens
<zyga> jdstrand: around?
<netphreak> ogra_: I want to preinstall/make my own app built-in - was using the system-status.victor app for that.
<ogra_> netphreak, sure, i get what you want ... but your app needs to be in the right place for that
<netphreak> eg. in edge?
<ogra_> in myapps.developer.ubuntu.com the "Supprted Releases" bit needs to list "rolling-core" ... and the Channel shoudl eb the same as the one you use in ubuntu-device-flash when building
<netphreak> Ok..
<netphreak> Was there support for private snaps?
<ogra_> (most likely edge since thats the only one you can get the recent image bits from)
<ogra_> dunno, thats a question to the store people
<kyrofa> matiasb, do you know anything about private snaps? ^^
<jdstrand> zyga: just got out of my meeting. I have to do a followup real quick. feel free to ask questions, but I also have backscroll
<zyga> jdstrand: thanks for responding; I have a pair of small branches ready for review; one bigger branch and one upcoming branch because snappy just switched to revisions
<zyga> jdstrand: with some luck we'll still land interface switch today
<zyga> jdstrand: I also wanted to catch up on apparmor template variable names; I think we could do a simple pass that renames them to be more sensible and to drop unused ones
<zyga> jdstrand: that's all I had; no need to look at backlog (for me)
<zyga> jdstrand: :-)
<netphreak> ogra_: tried with webdm - and it appears to work. Though browsing https://system-image.ubuntu.com/ubuntu-core/rolling/edge/ i do not see anything about webdm?
<matiasb> kyrofa, netphreak, sorry, was otp; there is support for private snaps, server side at least (not sure that's being handled in the client though)
<netphreak> any docs or description?
<mhall119> zyga: ok, switching to setuptools made snapcraft happy
<mhall119> I built my snap and installed it
<mhall119> but I can't run *any* snap
<mhall119> $ ubuntu-core-launcher foo foo foo
<mhall119> unable to bind /snaps/ubuntu-core.canonical/current//lib64 to /lib64. errmsg: No such file or directory
<mhall119> I always get the same error
 * mhall119 is on i386 still
<mhall119> it seems like ubuntu-core-launcher tries to use 64bit stuff regardless
<zyga> mhall119: image is out of date perhaps
<zyga> mhall119: you really really want to wait till next week
<zyga> mhall119: so many big features are landing
<zyga> mhall119: (revisions, interfaces, snappy removal, new fs layout)
<mhall119> zyga: that will be true again next Friday though :-P
<zyga> (from the top of my head)
<zyga> mhall119: we're building the image tonight
<zyga> mhall119: I showed working interfaces this morning; most of the stuff on this list is merged now
<mhall119> zyga: will interfaces make it easier to build desktop app packages?
<zyga> mhall119: perhaps
<zyga> mhall119: the biggest thing we've been busy lately is fighting cruft in the code
<zyga> mhall119: so that we can make changes
<zyga> mhall119: one thing we might explore for the desktop is library interface
 * mhall119 looks forward to having reasonable-sized desktop app packages
<zyga> mhall119: e.g. to share some big snap with libraries across other snaps
<zyga> mhall119: but this requires careful planning
<mhall119> zyga: I just want a "GTK" and "Qt" thing apps can depend on, so they don't have to include all that
<zyga> mhall119: e.g. by starting with one big fat library (SDK runtime perhaps)
<kyrofa> mhall119, yeah the ROS folks are wanting that as well
<mhall119> zyga: yeah, something like that
<zyga> mhall119: I suspect that's not something we can make in one week though
<mhall119> kyrofa: I'm not surprised, a "platform" snap that apps can target just makes sense
<zyga> mhall119: smells like SRU
<mhall119> zyga: SRU? Just snap-package it and deliver updates through the store ;)
<zyga> mhall119: interfaces are in the snappy codebase
<zyga> mhall119: you'd have to release new snappy first
<zyga> mhall119: metaphorical SRU
<kyrofa> mhall119, the OS snaps are still based on the archives
<mhall119> kyrofa: I was mostly joking :)
<elopio> ogra_: the PPA has the new snapd package that mvo wanted to publish. Can you please trigger the image generation?
<ogra_> elopio, mvo said there might be seed changes needed
<elopio> ogra_: the deb is now called snapd instead of ubuntu-snappy. Could it be related to that?
<ogra_> (but yes, I can trigger a build if that makes sense)
<ogra_> elopio, https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/ ... building
 * ogra_ vanishes back to the TV
<ogra_> Oh, that was a quick build
<elopio> hash mismatch :(
<ogra_> elopio, looks like the builders are borked atm... Seems cjwatson is working on a fix according to #ubuntu-devel
<ogra_> or rather waiting for infinity to do it :)
<elopio> got it.
<sergiusens> mhall119, zyga kyrofa even if you have the infra, given he have no real design for this, developer tools that use this will come much later
<sergiusens> you will have to snap craft your own stuff when using the "shared content" interface
<zyga> sergiusens: totally agreed
<dtoebe> hey guys, I am getting snappy-tools not found on 16.04 (https://developer.ubuntu.com/en/snappy/guides/) I also looked at the ppa I used from 15.10 and filtered for Xenial, and no snappy-tools build... Is there snappy-tools for xenial yet?
<kyrofa> dtoebe, just install snapcraft directly (assuming that's what you're going for)
<dtoebe> kyrofa, thanks doing it now... whats the difference between the 2
<kyrofa> dtoebe, snappy-tools was a meta package that pulled in some other things. It seems to be PPA-specific
<kyrofa> (pre-xenial)
<dtoebe> kyrofa,  oh ok... Then the url I ref'ed should be updated... Who do I contact?
<kyrofa> dtoebe, hold on, let's get to the bottom of this. sergiusens do you know if we ever plan on shipping snappy-tools in xenial?
<kyrofa> sergiusens, or should we update that document to only mention snapcraft?
<ogra_> We should, but only after release day
<kyrofa> elopio, also, according to some bug responses I've seen from you snappy-remote isnt in the xenial archives either. Can you confirm?
<kyrofa> ogra_, should what-- ship snappy-tools or update the document?
<sergiusens> kyrofa, ogra_ I say we copy package it in the ppa but also remove it from the documentation
<dtoebe> sergiusens, should I watch for it in the ppa then?
<kyrofa> sergiusens, just mention snapcraft in that doc, then?
<elopio> I can't install snappy-tools because I don't have snappy-remote. And I can't install snappy-remote because it doesn't exist.
<sergiusens> kyrofa, yeah
<elopio> I think we need to rewrite our strategy related to that. Instead of snappy-remote, I think we should have something like snappy try and snappy install --ip, or something
<kyrofa> elopio, it depends on how snappy try is implemented. Right now no one has the snappy-cli, right? That's not a dependency of snapcraft anymore
<dtoebe> kyrofa, I have the `snappy` command after I installed snapcraft `--help` has `[activate, booted, build ...]`
<dtoebe> ^ is that what you wereasking?
<dtoebe> * were asking
<kyrofa> dtoebe, which version of snapcraft?
<dtoebe> kyrofa, 2.7
<kyrofa> dtoebe, huh, I don't see it in debian/control
<dtoebe> kyrofa, I got it from http://us.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages
<zyga> jdstrand: around?
<jdstrand> yes, I will be looking at that stuff very soon
<jdstrand> as for the variables. I think it is fine to get rid of the old ones, but I'm going to need to review the policy. are you planning on doing the policy updates?
<jdstrand> I'm pretty sure we are going to want a SNAP_NAME_DBUS at a minimum if not SNAP_NAME_DBUS_CMD
<zyga> jdstrand: yes
<zyga> jdstrand: can we do dbus variables when we have real dbus interface
<zyga> jdstrand: I'm trying to trim anything unsed and minimze what needs testing
<jdstrand> I might mention that with frameworks gone, these variables are really just an implementation detail internal to snappy
<zyga> jdstrand: yep, that's why I'd like to postpone those
<jdstrand> didn't I see bluez just float by?
<zyga> jdstrand: I'd like a quick eye on https://github.com/ubuntu-core/snappy/pull/838
<zyga> jdstrand: bluez can wait a week :)
<jdstrand> well, if you prefer to remove them and adjust the policy, I can then do the review of that
<zyga> jdstrand: 16.04 can ship without it
<zyga> jdstrand: I'll change policy next week; today just this please
<zyga> jdstrand: and review earlier pings on github, we landed revisions
<zyga> jdstrand: and dropped .developer entirely
<jdstrand> what 'this' in 'just this'? the other commits not related to variables?
<zyga> jdstrand: today is a bit crazy
<zyga> jdstrand: various things have landed that relate to security
<zyga> jdstrand: but mostly marginal
<zyga> jdstrand: the branch I linked to above is the one that's not merged that I'd like a real review on
<jdstrand> zyga: is there more than the branches you referenced earlier and github email?
<zyga> jdstrand: not related to security
<jdstrand> ok
<zyga> jdstrand: look at git log, crazy day :)
<jdstrand> nice!
<zyga> jdstrand: I'm about to post the ifaces switch branch now
<zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/854
<elopio> kyrofa: sorry, you lost me. You can install ubuntu-snappy-cli in classic, and then you'll be able to run snap install.
<kyrofa> elopio, yeah my comment was kind of pointless-- you can safely ignore it
<jdstrand> zyga: 838 and 840 reviewed with comments
<zyga> jdstrand: thanks!
<zyga> jdstrand: fixed to 0644
<jdstrand> zyga: oh wow, dropping .developer breaks list
<jdstrand> $ /tmp/snappy list
<jdstrand> Can not get the installed snaps: broken snap directory path: "/snaps/cap-test.mvo/2.2b1-3.16.04.5"
<mvo> jdstrand: yes, sorry
<mvo> jdstrand: its all broken
 * jdstrand manually uninstalls everything
<mvo> jdstrand: and its getting worse
<jdstrand> heh
<mvo> jdstrand: revisions are also landing
<mvo> but at some point it will get better
<mvo> it must!
<jdstrand> yes! :)
 * jdstrand hugs mvo, zyga, niemeyer and Chipaca` 
<jdstrand> I know I missed people
<zyga> jdstrand: snappy?
<zyga> jdstrand: snappy is gone
<zyga> jdstrand: try snap list
<jdstrand> the README.md still says to build snappy
 * jdstrand builds snap
<jdstrand> $ /tmp/snap list
<jdstrand> error: cannot list snaps: not found
<jdstrand> zyga: I may have some trouble testing your overload branch at this point. I don't mean to distract you
<jdstrand> overlord*
<zyga> jdstrand: yes, it's all broken-ish
<zyga> jdstrand: I can tell you how to test it in a sec
<zyga> jdstrand: okay
<zyga> jdstrand: I'm using github.com/zyga/devtools
<jdstrand> I have that branch here. never used it
<zyga> jdstrand: pull it and try
 * jdstrand pulled
<zyga> jdstrand: build a pc image and run a pc vm
<zyga> jdstrand: then run ./refresh-bits snap snapd setup run-snapd
<zyga> jdstrand: with a fresh pull of the branch we're talking about (pull just in case, I push --forced it once or more)
<zyga> jdstrand: then in another tty ssh to the box (ssh snappy-vm if you do follow ssh configuration instruction)
<zyga> jdstrand: and run sudo ./snap install hello-world
<zyga> jdstrand: then play with security files and see what's going on
<zyga> jdstrand: ask me anything anytime
<jdstrand> Failed to verify integrity of http://people.canonical.com/~mvo/all-snaps/ubuntu-device-flash
<mvo> jdstrand: yes, zyga needs to update his script
<zyga> mvo: oh, sorry, I just noticed
<zyga> mvo: what's the new hash?
<jdstrand> 5702008cf61124d7a44f9a0fddc6e466b8a87d3d0e7d3fe04993081986e190c4080ebcd402b720fc4033c988667d9cd623c37ac44ee34fd3daae1ae398797fd1
<zyga> jdstrand: thanks, pushed
 * zyga is building a new image now
 * jdstrand is tapping fingers
<jdstrand> ok, finally a login
<zyga> jdstrand: cool
<zyga> jdstrand: try it :)
<jdstrand> no network
<mvo> jdstrand: run sudo snap firstboot
<mvo> jdstrand: did I mention that its all broken?
<jdstrand> mvo: you did, and then zyga convinced me to keep going :)
<zyga> jdstrand: note that connect/disconnect/interfaces are detached from reality
<zyga> jdstrand: but security policy generation is okay (except that there are no connections yet)
<zyga> jdstrand: and I got connect/disconnect/interfaces done but with broken tests that need some love to show the code really works
<zyga> jdstrand: I'll do that tomorrow
<zyga> jdstrand: next week it should start to look norma
<zyga> normal*
<jdstrand> cool
<zyga> jdstrand: did you get to install hello-world?
<jdstrand> no
<jdstrand> I can't get networking to work
<zyga> jdstrand: ah
 * zyga tries
<jdstrand> I have an ip, but I can't ssh into it
<jdstrand> the device can't ping either
<zyga> jdstrand: can you login from the console?
<jdstrand> yes
<jdstrand> hmm, but snap find from the device works, so some networking is there
<zyga> jdstrand: mvo just merged that!
<zyga> jdstrand: we'll patch up the remaining issues over the next few days
<jdstrand> ok, well, if I can't login I can't update snap and snappy
<jdstrand> I think maybe I'll circle back around
<zyga> jdstrand: it's one of the things that cannot be done cleanly without a lot of time
<jdstrand> that's fine. I'm not complaining
<jdstrand> just trying to help. seems I'm distracting more than helping
<jdstrand> so I'll leave it alone for the moment and put it through its paces next week
<zyga> jdstrand: your help is much appreciated; I'm sorry you cannot test this reliably right now
<zyga> jdstrand: thanks!
<jdstrand> like I said, it's fine :)
<jdstrand> you're more than welcome :)
<jdstrand> thanks for all the hard work on all of this :)
<jdstrand> like mvo said, it'll be better soon (of course, I'm talking about more than just the image :)
<mvo> jdstrand: I fixed the firstboot thing
<jdstrand> cool
<cjwatson> ogra_: no, that wasn't "the builders are borked", that was "there is a relatively rare race condition that isn't totally fixed until infinity rebuilds the chroots, but it's nothing new and in the meantime just retry the build"
<cjwatson> not every build problem is "the builders are borked"
<oparoz> Could someone please confirm that the builders don't prompt for a password when using sudo in a Makefile?
<cjwatson> oparoz: In a package build?  Nack - you don't get root.
<cjwatson> oparoz: Classically all you need is fakeroot to make tar think files are owned by root and suchlike.
<cjwatson> oparoz: Hm, I think we may run snapcraft as root though.  Should probably fix that to avoid accidents.
<oparoz> cjwatson: Ah, thanks cjwatson. I need to add a symlink to /lib because libtool freaks out. Travis allows sudo, but maybe they don't allow /lib hacking
<cjwatson> oparoz: I've spent a lot of time with libtool and never ever ever seen that actually being necessary.  I suspect other solutions are available.
<oparoz> cjwatson: Probably hacking the configure script, but I don't have the knowledge to do it. The libs are in the staging area, -I and -L include all the needed paths and yet the script ends up trying to do something with /lib
<cjwatson> snapcraft pull may require sudo, maybe that's why we called it as root in the first place.  But now that we run the pull phase separately anyway ...
<cjwatson> maybe LD_LIBRARY_PATH?
<cjwatson> I'd suggest arranging for libtool to run with set -x.  You'll get a ton of output but it's generally at least possible to debug it from that
<oparoz> cjwatson: I tried that and everything I could think of in terms of switches, but it always fail with a grep error
<cjwatson> Hacking /lib is very very evil and we should go to all lengths not to need that
<cjwatson> Anyway, /me -> bed
<oparoz> cjwatson: I agree :). That was a temp solution while I wait to see if the project can fix its builder, if possible
<oparoz> cjwatson: But thanks for the tip about -x. I did try to use a different shell for the Makefile, but al I get is the list of calls, but no debud info
#snappy 2016-04-09
<netphreak> hi, guys!
#snappy 2016-04-10
<Domi> Hello, I search a programming language which runs on Ubuntu core, Raspbian and Windows IoT. Java is not possible because there is no JVM for Windows Iot but does C#(mono) work on Ubnutu Core?
<oparoz> NodeJS? Python? PHP?
<oparoz> Ah, no you mean core without any other snaps available...
<Domi> Is ist possible to use the gpio with NodeJS or PHP? No I mean with snaps
<oparoz> It's possible to make the calls, but I don't know if Snappy will block access to the hardware or not
<oparoz> Note, I'm just an enthusiast
<oparoz> Should be really quick to find out
<Domi> I did not find a tutorial on how to use the gpio pins of the rasberry pi with ubuntu snappy
<ogra_> for 15.04 images there is the piglow package in the store, you could take a look at that one
<ogra_> 16.04 (even though it wil completely replace 15.04 soon) is still re-defining the security bits ... the first chunk landed on friday but there is still some fine tuning needed ... ou will definitely be able to fully use your gpios :)
<ogra_> as for languages ... snap package require you to bundle your language bindings, whi9ch means you can use anything you want as long as you have/find working binaries
<ogra_> there is no limit in languages, C# will definitely work if you bundle the right bits
<ogra_> (there is no default plugin for snapcraft though ... will be a bit more fiddly than packaging a java or nodejs app)
<Domi> ok what language would you recomment for easy use?
<ogra_> the one you are most familiar with :) and the snapcraft autotools or make plugins
<ogra_> thats surely the easiest ... or ... the copy plugin which only copies binaries in place ... and you produce the binaries as you like
<ogra_> there are plenty of ways ;) pick your own poison
<ogra_> there are some examples and a hacking guide at https://github.com/ubuntu-core/snapcraft
<Domi> is there any example how to use the gpio pins of the rasbperry pi?
<ogra_> http://blog.mattyw.net/blog/2015/10/09/simple-piglow-snap-for-raspberry-pi-2/
<ogra_> but as I said, this is for 15.04 snappy... which will be EOL soon
<ogra_> 16.04 does use snapcraft to biuld the snaps
<Domi> ok thank you
<Domi> is there a list which snaps i can use with snappy install
<netphreak> Hi, guys!
<popey> enabled snappy classic mode on my pi 3, and now get this when i sudo in classic... "sudo: no tty present and no askpass program specified"
<popey> I even tried destroying my classic dimension and recreating it
<popey> same
<ogra_> yeah, known bug ....
<ogra_> (there was a workaround ... )
<ogra_> bug 1564369
<ubottu> bug 1564369 in Snappy "sudo broken in latest classic" [Critical,Confirmed] https://launchpad.net/bugs/1564369
<oparoz> Type it from the non-classic shell
<Domi> is there a tutorial on how to pack python code into a snap?
<ogra_> Domi: yes, see the python examplers in the snapcraft source
<popey> thanks ogra_
<popey> ogra_: that workaround worked.. around. :)
<ogra_> :)
<baum_> Will there be openstack on ubuntu core arm?
<ogra_> if someone packages it
<baum_> And how do I use dnsmasq-arm on there
<ogra_> no idea what dnsmasq-arm is ...
<netphreak> Is it possible to set target architecture on the snappy maven plugin?
 * ogra_ only knows dnsmasq ... and i guess you would have to bundle it in your owncloud snap  together with all other services 
<baum_> I is availabe on the snappy store by it self
<baum_> It should be used as a dns-server
<baum_> In didn't find really find any docs on the /apps/dnsmasq-arm.howy directory
<netphreak> Does snappy maven plugin support armhf architecture?
#snappy 2017-04-03
<zyga> good morning
<mvo> hey pstolowski! I'm keen to land #3119 (once tests are green). I assume the API is alreaady agreed on with niemeyer? i.e. the high level part does not need review?
<zyga> hey mvo
<pstolowski> mvo, hey! thanks for looking at it. well, it was briefly discussed long time ago. I think niemeyer may still want to take one more look at it
<JamieBennett> hey jibel, how did testing snapd 2.23.6 go last week, I didn't hear anything back.
<mvo> pstolowski: ok, then I will wait with the merge
<mvo> hey zyga!
<jibel> JamieBennett, we had some tests to re-run due to the issue with the kernel in candidate, but everything should be ok by now. I'm checking the results
<fgimenez> hey mvo good morning :) now that we have the expect snap in the staging store i'm preparing a branch for enabling the tests that use it and were disabled for ubuntu-core systems, these are the initial results with some errors http://paste.ubuntu.com/24305344/ could you please take a look when you have a moment?
<zyga> fgimenez: I think I have a branch like that ...
<zyga> https://github.com/snapcore/snapd/pull/3063
<mup> PR snapd#3063: tests: re-enable tests for /dev/pts on core <Created by zyga> <https://github.com/snapcore/snapd/pull/3063>
<zyga> fgimenez: feel free to take it :)
<fgimenez> zyga: thanks! in my case we actually install the expect snap, this is the current wip https://github.com/snapcore/snapd/compare/master...fgimenez:expect-snap?expand=1
<mvo> fgimenez: thanks, just looked over it and it looks like it needs more investigation. the expect output seems to be slightly different :/ ?
<zyga> fgimenez: right, I my branch didn't have the expect snap
<fgimenez> mvo: yep, in some cases it seems to wait for more input, looking into it right now, you can reproduce with "SPREAD_REMOTE_STORE=staging spread -v ..."
<morphis> Son_Goku: great work on getting all the bodhi requests up for snapd!
<morphis> zyga: you have some time testing snapd on fedora 24/25/26 in the next days?
<morphis> Son_Goku, zyga: would like to send out a call-for-testing on forum.snapcraft.io soon, what do you guys think?
<zyga> morphis: yes
<morphis> great!
<fgimenez> mvo: superlow priority but we are getting errors in the 2.21 -> edge reexec scenario about missing dependencies https://travis-ci.org/snapcore/spread-cron/builds/216619076#L376 in this case we get snapd from a ppa but i get the same error getting it from https://launchpad.net/ubuntu/+source/snapd/2.21, snap-confine and ubuntu-core-launcher are requested as dependencies of snapd at the same version of the latter (which doesn't exist for snap-
<fgimenez> confine nor ubuntu-core-launcher)
<mvo> fgimenez: oh, of course. we need to tweak our tests to install those two (snap-confine,ubuntu-core-launcher) when testing with older versions of snapd
<morphis> mvo: can you tag https://github.com/snapcore/snapd/pull/3089 for inclusion in 2.24?
<mup> PR snapd#3089: interfaces: drop udev tagging from framebuffer interface <Created by chunsangjeong> <https://github.com/snapcore/snapd/pull/3089>
<mvo> morphis: sure
<morphis> mvo: and didn't know about exec.LookPath, nice one :-)
<mvo> morphis: its very well hidden
<morphis> yeah ..
<mvo> morphis: like google golang find path will not find anything
<fgimenez> mvo: ok, but the requested version, in the 2.21 case, is (= 2.21), where can we get that version of snap-confine?
<morphis> mvo: yeah, did exactly that
<mvo> fgimenez: where are we getting it currently from? its a ppa?
<mvo> fgimenez: or do we build it? (pardon my ignorance here)
<mvo> morphis, zyga: my reviews this morning were a bit over nitpicky, sorry for that, I guess I need to switch to a stronger type of tea or something :)
<morphis> mvo: no problem, much appreciated :-)
<fgimenez> mvo: np :) we are getting it from https://launchpad.net/~snappy-dev/+archive/ubuntu/snapd-2.21/+packages, i see the additional packages there, thanks!
<zyga> mvo: thanks for the review, I'm still working on that code
<zyga> mvo: trying to make cgo/go parts work nicely with testing
<zyga>   hmmm
<zyga> mvo: do you have an idea why .a file is not made in $GOPATH/pkg/$arch/... if I "go build" something that uses cgo?
<mup> PR snapd#3089 closed: interfaces: drop udev tagging from framebuffer interface <Created by chunsangjeong> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3089>
<zyga> go/cgo bridge has some rough edges :/
<zyga> mvo: I need to *not* run the bootstrap code for testing
<zyga> mvo: but *do* run it in production
<zyga> mvo: cgo cannot be used in tests
<zyga> mvo: we cannot do anything in Go land to enable/disable the C code
<zyga> mvo: I tried setting a flag to zero and hang the bootstrap code on that value being 1
<zyga> mvo: (so it would never run by default or in testing)
<zyga> mvo: and then use a 2nd constructor, with higher priority, in the main code to actually set the flag to 1
<zyga> mvo: but whatever go does to link things it doesn't seem to allow any C symbols to be seen in other go packages
<zyga> mvo: I'll try putting this all in one package next
<morphis> zyga: about the xauth thing, it would be the best if we loop through each xauth cookie in the file XAUTHORITY points
<morphis> zyga: which would either require us to link against libx11 (not what we want) or to reimplement functions like XauReadAuth (https://www.x.org/archive/X11R6.7.0/doc/Xau.3.html)
<zyga> morphis: hmm, lovely
<zyga> morphis: let's start a thread about this
<morphis> zyga: flatpak does a few more things and also ensures that the confined app only gets access to cookies for local X11 servers
<zyga> morphis: my 0.02 is to implement this in go
<morphis> zyga: yeah wnated to do this
<zyga> morphis: and call a helper if needed
<morphis> from snap-confine?
<zyga> morphis: we can _maybe_ exec a helper in go
<zyga> morphis: or do this in snap-run even
<morphis> snap-run is before snap-confine in the chain, right?
<zyga> morphis: we probably cannot fork too much from snap-confine in case that systemd expects a forking daemon
<zyga> yes
<zyga> morphis: I'd do it like this though:
<zyga> morphis: think of snap-confine as one thing
<zyga> morphis: and think about some parts that you can write in go
<zyga> morphis: before/after the main low-level part
<zyga> morphis: if we do it like this we may write a go program
<zyga> morphis: that execs a helper in C
<zyga> morphis: that helper execs the go program again (after setting a flag or something)
<zyga> morphis: so you can do all go code
<zyga> morphis: and a predictable system level code in the middle
<morphis> so point is that we need to have a place we can share data through, do we have a dir which is available in the confinement and outside?
<zyga> morphis: I think that is sufficient for snap-confine
<zyga> morphis: yes, /run is one such place
<zyga> morphis: we have /run/snapd/ns today
<morphis> zyga: do we have a private dir in there?
<morphis> ah
<morphis> a per app dir?
<zyga> morphis: does it have to be per app?
<zyga> morphis: (it can be)
<morphis> it has to
<zyga> morphis: we can make a per-app file
<zyga> morphis: and restrict it with apparmor
<morphis> think about multi-user systems
<morphis> then doing this inside snap-run sounds like a good idea
<mup> PR snapd#3121 closed: WIP: cmd/snap-confine: always pass xauth file through regardless where it is located <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/3121>
<mup> PR snapd#3125 opened: tests: download and install additional dependencies when using prepackaged snapd <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3125>
<fgimenez> mvo: ^ should fix the dependency problems in the 2.21 -> edge reexec scenario, thanks
<zyga> morphis: aha
<zyga> morphis: so it has to be in xdg somewhere
<zyga> morphis: there's unfinished code that sets XDG_RUNTIME_DIR
<zyga> morphis: I think it fits there
<zyga> morphis: (mkdir the XDG_RUNTIME_DIR, somewhat tricky because part needs to run as root, part as user)
<fgimenez> mvo: i've updated https://github.com/snapcore/snapd/pull/3105 to download the additional dependencies too (with this branch we don't need to maintain ppas for specific old versions), it works fine on local executions
<mup> PR snapd#3105: tests: download previous snapd package from published versions instead of specific PPA <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3105>
<morphis> zyga: who says the auth file needs to be in XDG_RUNTIME_DIR?
<mvo> fgimenez: excellent, thank you. I have a look
<mvo> zyga: thank for the update on the cgo stuff, this does indeed sound tricky :/
<morphis> zyga: who sets up /run/snapd/ns at the moment?
<zyga> morphis: I think it makes sense as that is per user and ont in home
<zyga> mvo: I have a hacky solution
<zyga> mvo: just commiting now
<zyga> morphis: only snap-confine
<morphis> zyga: I think the copy needs to be more per instance
<morphis> rather than per app
<morphis> what if the XAUTHORITY file changes over time and a second instance of an app is started, then we would override that file in /run/snapd
<morphis> so I think putting this into snap-confine makes most sense and then placing the content after parsing in the snap own /tmp
<zyga> morphis: why per instance?
<zyga> morphis: aha
<zyga> morphis: we can overwrite the old value too
<morphis> yes
<zyga> morphis: (since apps probably just read it on startup)
<zyga> morphis: if you do it per instance there's no easy way to clean up
<morphis> if you do per instance you have it in /tmp
<zyga> morphis: note that /tmp is per-snap, not per user or instance
<morphis> ah
<morphis> zyga: quick and dirty fix would be a bind-mind into /run/snapd
<morphis> s/mind/mount/
<morphis> + setenv("XAUTHORITY", "/run/snapd/xauth.<uid>")
<morphis> if we want parsing of that file + skipping cookies for remote X11 instances then we need more logic
<zyga> morphis: wait, bind mount what into that?
<zyga> morphis: I think bind mount of anything is tricky
<morphis> whatever XAUTHORITY points to on /run/snapd/xauth.<uid>
<zyga> morphis: I'm -1.5 on bind mount as that tends to make /home live forever and I'm not sure if systemd will untangle this
<zyga> morphis: why does flatpak filter remote connections?
<morphis> yeah .. that's why I said quick and dirty
<morphis> zyga: to make the app local-bound
<zyga> morphis: I'd rather just copy it to /run/user/$UID/snap.$SNAP_NAME/.Xauthority
<morphis> hm
<morphis> zyga: let me play with that and then start a discussion
<zyga> morphis: sounds good, thank you
<zyga> mvo: morphis: can you please have a 2nd look at https://github.com/snapcore/snapd/pull/3095/files
<mup> PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095>
<morphis> sure
<zyga> offtopic: somewhate appropriate now that we are doing all the mount craze: https://lwn.net/Articles/718638/ -- I'm looking forward to see this evolve
<zyga> pstolowski: hey, I think you need to merge master into: https://github.com/snapcore/snapd/pull/3119
<mup> PR snapd#3119: interfaces: API additions for interface hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3119>
<zyga> fgimenez: should I close https://github.com/snapcore/snapd/pull/3063 ?
<mup> PR snapd#3063: tests: re-enable tests for /dev/pts on core <Created by zyga> <https://github.com/snapcore/snapd/pull/3063>
<fgimenez> zyga: yes please, we need to use the expect snap for that to work, it is covered in my branch
<mup> PR snapd#3123 closed: osutil: introducing GetenvInt64, like GetenvBool but Int64er <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3123>
<zyga> fgimenez: ok, thank you
<mup> PR snapd#3063 closed: tests: re-enable tests for /dev/pts on core <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3063>
<fgimenez> zyga: np thx :)
<mup> PR snapd#3087 opened: overlord/snapstate: introduce tasks for aliases v2 semantics with temporary names for now (aliases v2) <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3087>
<mvo> fgimenez: do you have any idea what is going on with the autopkgtest currently? looks like all are failing. do you know if anyone has looked into this yet?
<pstolowski> zyga, indeed, will do in a moment, thanks
<fgimenez> mvo: yes, we are building spread on each autopkgtest execution, and this started to fail on friday
<mvo> fgimenez: oh, ok
<fgimenez> mvo: i've proposed a branch for using spread from the snap, but this only works for amd64, no spread snap on i386 nor ppc
<mvo> fgimenez: and I see there is a branch already
<mvo> fgimenez: hrm, hrm, ok
<fgimenez> yep
<fgimenez> mvo: maybe there's a better approach of course, not sure of what is the root cause
<fgimenez> mvo: fwiw it seems that if you try to build spread in an up to date xenial, the resulting binary is not able to ssh to the testbed
 * zyga fires spread tests for snap-update-ns and takes a break 
<mvo> fgimenez: ta
<morphis> Son_Goku: we have to fix all the rpmlint/rpmgrill errors, right?
<mvo> fgimenez: I wonder if we can just mirror spread and lp build snaps - but we need gustavo to share the snap with us or ask him to setup the snap build recipe
<pedronis> mvo: hi, btw Gustavo has asked to turn them off (the autopkgtest) if we don't find a quick solution
<mvo> pedronis: ok
<zyga> pstolowski: can you review https://github.com/snapcore/snapd/pull/3095 again please
<mup> PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095>
<pstolowski> zyga, will do in a bit.. running to school in a moment
<pstolowski> hah, I think I got the the bottom of EOFs in store/retries
<morphis> zyga: https://forum.snapcraft.io/t/migrate-x11-authentication-cookies-into-snap-environment/116
<zyga> pstolowski: oh, what was it?
<pstolowski> zyga, we get url.Error, need to convert into that an inspect its Err member
<pstolowski> crazy
<zyga> pstolowski: aha
<zyga> pstolowski: well, I'm +100 on having sane downloads :)
<pstolowski> the simple return err == io.ErrUnexpectedEOF || err == io.EOF check we have doesn't cut it
<pstolowski> bbiab
<nanodrone> whats the smallest sized snap ever? do snaps share installed libraries between packages?
<clobrano> hey there, I was wondering where is the best place to submit a (possible) bug in konversation snap package
<zyga> nanodrone: smallest size is the size of snap/meta.yaml + empty application that may be a tiny elf file or a shell script saying "hi"
<ogra> nanodrone, the smallest one is probably a few bytes
<zyga> nanodrone: snaps don't share anything unless that is designed by snap author
<ogra> well
<ogra> they all use libc and some basics from the core snap
<zyga> clobrano: I think you can to that on the forum, using the "snap" category: https://forum.snapcraft.io/t/about-the-snap-category/55/2
<nanodrone> but they can cut down on their size if needed?
<ogra> but usually snap dont chare anything among each other ... that would break the security model ... you *can* make them share bits on purposes though
<zyga> ogra: iff they want to :)
<nanodrone> i dont understand the security part... :(
<zyga> nanodrone: note that you may be limited by the size of an empty squashfs file :)
<ogra> nanodrone, a snap can only see its own parts of the system
<zyga> nanodrone: I can explain that if you want to
<ogra> nanodrone, there is a mechanism called interfaces that allows to extend this
<ogra> nanodrone, one of these interfaces is the content interface ... that would for example allow you to have a shared library snap that your apps can make use of
<nanodrone> please do
<clobrano> zyga, thanks!
<zyga> nanodrone: snapd uses several kernel mechanisms to constrain what application code can do
<zyga> nanodrone: we limit the system calls you can use
<zyga> nanodrone: we limit some of the arguments to some of the system calls
<morphis> Son_Goku: I've snapd now building with relro, a bit hacky but works: https://paste.fedoraproject.org/paste/TcD8VNEWY~aV9-0eW~wUIF5M1UNdIGYhyRLivL9gydE=
<zyga> nanodrone: and we limit the set of files you can read, write, map, lock, etc on
<ogra> ppisati, soo ... no broccoli for me regarding bluetooth ... not even with your new kernel :(
<zyga> nanodrone: we also limit the IPC between all the apps and the rest of the system
<zyga> nanodrone: so by default every application gets a sane set of rules that define the sandbox
<nanodrone> that sounds nice. can i package a node app using snap
<zyga> nanodrone: if the app tries to use more it either gets an error or gets killed (depending on some technical details)
<zyga> nanodrone: yes
<zyga> nanodrone: the system of "interfaces" is how we model extensions to the default sanbox
<ogra> nanodrone, if you want to dig really deep into the security models ... https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/ has all the dirty details ;)
<zyga> nanodrone: you can say that your application needs to talk to the network by adding a "network" plug in your applicatoin
<zyga> nanodrone: interfaces work in pairs "plug" wants to consume something that a "slot" provides
<nanodrone> how do i update the snap...
<zyga> nanodrone: only when a plug is connected to a slot is the actual permission granted
<zyga> nanodrone: once connected (some are auto connected, some need to be connected by the user) your app can just access more of the system
<nanodrone> also, do i have to publish the snap somewhere or can i distribute it offline
<zyga> nanodrone: that's the overview, let me know if you have any questions
<zyga> nanodrone: you can publish your snap into the store, if you push more versions everyone will update automatically
<zyga> nanodrone: you can use channels (stable, candiate, beta, edge) to publish multiple stability levels at the same time; everyone installs stable by default
<zyga> nanodrone: if you publish your snap e.g. on a 3rd party web server anyone can download it and install locally
<zyga> nanodrone: but that means there will be no updates
<zyga> nanodrone: and that removes the possiblity of using some more privlieged interfaces
<nanodrone> like?
<zyga> nanodrone: in the store your snap can be free (gratis) or priced, so you can also sell it
<ogra> and you can indeed also install local snaps during development ...
<zyga> nanodrone: all that require an assertion (a signed document) saying that your snap can use a given privileged interface
<nanodrone> i dont think i'll need too many privileges, just like internet/network access and filesystem access..
<zyga> nanodrone: some interfaces give a lot of power so we want to control who has access to them
<zyga> nanodrone: "filesystem access" is very broad
<zyga> nanodrone: each snap gets a portion of the filesystem it can access by default
<nanodrone> i just need to write/read files from the app's own directory
<zyga> nanodrone: that is placed inside each users home directory
<zyga> nanodrone: that's allowed by default
<nanodrone> yup that'll suffice
<zyga> nanodrone: but you won't be able to read arbitrary user files this way
<nanodrone> arbitrary user files?
<nanodrone> you mean i'll be limited to my own files?
<zyga> nanodrone: yes
<nanodrone> that's ok i dont need that.
<zyga> nanodrone: your application will not see any user files that don't belong to your snap
<zyga> nanodrone: great, good luck :)
<zyga> nanodrone: note that your snap will work on many distributions but you will most likely need to use ubuntu or debian to build it (for now, we're working on making this better)
<nanodrone> but i can optionally access user files somehow?
<zyga> nanodrone: if you use the home interface you can access certain files
<nanodrone> all my "app users" have ubuntu.
<zyga> nanodrone: we're looking at allowing file-picker like thing as well but that's not implemented
<zyga> nanodrone: your app will also work on fedora, suse, debian and other distributions though,
<zyga> nanodrone: and it will be visible in things like gnome-software there (if it is properly described in the desktop file)
<morphis> mvo: btw. do we have milestones on launchpad for snapd releases?
<zyga> morphis: nope
<nanodrone> here's a scenario, like the user puts files in a user specified directory and the app can access just that directory.
<zyga> morphis: we stopped using those
<zyga> morphis: I think we could / should do that and mirror github milestones
<zyga> nanodrone: yes
<morphis> zyga: so how do we know when a bug is fixed / targetted to be fixed?
<nanodrone> thats all i need.
<zyga> nanodrone: yes, e.g. $HOME/snap/yoursnapame/common
<zyga> morphis: I spoke with mvo about this but we don't usually say when it was fixed
<nanodrone> network access plus file access like that. i can't think of anything else.
<zyga> morphis: I'd love to have those milestones
<nanodrone> can i still show my app's indicator or menu entries in the sound/messaging menu + notifications?
<zyga> nanodrone: note that if you upload your snap to the store it will be far easier to install
<morphis> zyga: yeah ..
<zyga> nanodrone: we have mpris interface for that
<zyga> nanodrone: notifications are probably handled by the unity interface
<zyga> nanodrone: give that a try
<nanodrone> it's using notify osd for basic notifications for now.
<zyga> nanodrone: in your app you can say: plugs: [network, unity7]
<zyga> nanodrone: for mpris there's a more interesting example to look at AFAIR
<zyga> nanodrone: i think `vlc' snap uses it
<nanodrone> is snap = ubuntu or is it available on arch and gentoo as well
<zyga> nanodrone: it's available in many distributions, have a look at https://github.com/snapcore/snapd/wiki/Distributions
<zyga> morphis: ^^ that is out of date
<zyga> nanodrone: fedora and opensuse are now supported
<ogra> and should move to the forum :)
<zyga> morphis: can you edit and fix that quickly
<zyga> ogra: yeah, I think that's sensible as long as it is up-to-date
<nanodrone> okay this is enough reading for me for today. i'll be back later ( i didn't think i'd get this quick an answer to all of my questions )
<nanodrone> putting #snappy on autojoin haha
<morphis> zyga: Fedora rawhide is supported now, yes
<ogra> yeah, it is more likely that it is kept up to date in the forum i guess :)
<ogra> (more eyes)
<zyga> nanodrone: good luck :)
<nanodrone> thanks everyone. zyga ogra...
<ogra> :)
<nanodrone> truly grateful convert.
<morphis> zyga: however supported == included in the distribution archive, isn't it?
<morphis> zyga: https://bugs.launchpad.net/snapd/+bug/1657100 can be closed with the work Son_Goku did, right?
<mup> Bug #1657100: snapd needs a SELinux profile to run on Fedora <snapd:Confirmed> <https://launchpad.net/bugs/1657100>
<zyga> morphis: no, supported is something we just support
<zyga> morphis: feel free to make that clearer
<zyga> morphis: it's an arbitrary choice
<zyga> morphis: (of words)
<morphis> ok
<morphis> something I need to work through, don't feel well maintain all these version numbers etc. on a wiki page
<zyga> morphis: yes, I wanted a dynamically generated table but the wiki lets us start with something quickly
<morphis> zyga: I think we need to drop the version numbers there alltogether at one point in the near future
<zyga> mvo: can you re/review https://github.com/snapcore/snapd/pull/3114 please
<mup> PR snapd#3114: interfaces/mount: add function for saving fstab-like file <Created by zyga> <https://github.com/snapcore/snapd/pull/3114>
<zyga> mvo: if you want I can make the extra rename
<zyga> mvo: I'd like to propose more useful stuff on top
<mvo> zyga: I would like the naming part for gustavo, I'm not great at names
<zyga> mvo: ok, let's wait for a 2nd review for it
<mvo> zyga: but I will go over it again
<Son_Goku> morphis: rpmgrill errors can be fixed later, some of them can be ignored too
<mup> PR snapd#3126 opened: store: handle EOF via url.Error check <Created by stolowski> <https://github.com/snapcore/snapd/pull/3126>
<pstolowski> mvo, this should be the final blow at EOFs, hopefully ^
<zyga> Chipaca: hey
<zyga> Chipaca: do you know any snaps that use ubuntu-app-platform
<zyga> Chipaca: I'm looking and snap-update-ns hand-testing
<morphis> Son_Goku: ok, good to hear
<Chipaca> zygaâ I don't, but give me a mo'
<mvo> pstolowski: very nice!
<zyga> Chipaca: I'll write spread test based on the existing content stuff next but I want to have something at hand to play with
<zyga> Chipaca: I don't know if there's a way to ask the store "what works with this snap"
<morphis> Son_Goku: so anyone we need to fix before the first release?
<Son_Goku> I think I fixed all the things that were actually important, I think
<zyga> morphis: \o/
<morphis> Son_Goku: nice!
<Son_Goku> * Fri Mar 31 2017 Neal Gompa <ngompa13@gmail.com> - 2.23.6-2
<Son_Goku> - Fix the overlapping file conflicts between snapd and snap-confine
<Son_Goku> - Rework package descriptions slightly
<Son_Goku> * Sat Apr 01 2017 Neal Gompa <ngompa13@gmail.com> - 2.23.6-3
<Son_Goku> - Fix profile.d generation so that vars aren't expanded in package build
<morphis> Son_Goku: are you ok with me writing a call-for-testing on forum.snapcraft.io?
<Son_Goku> please do
<Son_Goku> I'm so tired...
<morphis> get some sleep :-)
<Son_Goku> I spent literally all weekend hacking at this, because snapd is too complex for its own good...
<zyga> Son_Goku: thank you! You made a lot of this happen!
<morphis> Son_Goku: great work!
<Son_Goku> :/
<zyga> hmm
<zyga> mvo: `-                             core:core-support
<zyga> mvo: I didn't do anything
<zyga> mvo: and it got disconnected
<zyga> mvo: when core support is disconnected snapd is really wonky
<zyga> mvo: like a "be broken" switch
<Chipaca> zygaâ lonewolf, neverbore, extia-webapp, mendiapp, facebook-webapp-mardy, chronoburn, soracom-console
<Son_Goku> zyga, morphis: there's still so much to go
<mvo> zyga: core:core-support got disconnected?
<zyga> mvo: yes
<zyga> Chipaca: thanks!!
<morphis> Son_Goku: yeah, one of the next major milestones after this one is that we get CI up and running for fedora so nothing breaks it
<mvo> zyga: out of the blue? geh
<Son_Goku> snapd needs to properly support generating selinux policies at runtime for snaps... splitting base from core and being able to swap both of those is also missing
<mvo> zyga: what if this happens in the wild?
<zyga> mvo: not sure, I just noticed now
<Chipaca> zygaâ curl to get the raw yaml, python to filter
<zyga> mvo: yeah
<zyga> mvo: ensure connecting core:core-support?
<Son_Goku> and of course, nobody can create snaps on Fedora :(
<zyga> Son_Goku: base/core will happen as we approach 18
<Son_Goku> that's far too long from now
<zyga> Son_Goku: and once we have that we may try fedora-based sonps
<zyga> snaps
<morphis> Son_Goku: there is a snapcrat snap already these days, something you can use
<zyga> Son_Goku: not when 18 hits, I'm sure it will be started soon
<Chipaca> zygaâ more exactly, curl -H "Accept:application/hal+json" -H "X-Ubuntu-Wire-Protocol:1" "https://search.apps.ubuntu.com/api/v1/snaps/search?q=&fields=package_name,snap_yaml_raw"
<Chipaca> zygaâ and then
<Son_Goku> morphis: can't, because lxd doesn't work
<Chipaca> ", ".join([i["package_name"] for i in json.load(sys.stdin)["_embedded"]['clickindex:package'] if "ubuntu-app-platform" in i.get("snap_yaml_raw", "")])
<Son_Goku> morphis: the problem with snaps right now is that everything has a built-in assumption for Ubuntu
<morphis> Son_Goku: sounds like we need another backend in snapcraft for cleanbuild
<Son_Goku> and that makes things more rickety than I wish it did
<mvo> fgimenez, pedronis: fwiw, I'm investigating the autopkgtest issues
<Chipaca> probably expressable in jq, but Â¯\_(ã)_/Â¯
<zyga> Chipaca: thanks, this will make my experiements happy!
<Chipaca> hth
<Chipaca> zygaâ also there's probably more, as that's just looking at the first page of results
<Chipaca> bah, might as well get the whole thing
 * Chipaca tweaks
<morphis> Son_Goku: yeah that is really a problem but something we need to work torwards too, however lets fix the basic things first
<Chipaca> zygaâ lonewolf, neverbore, extia-webapp, mendiapp, facebook-webapp-mardy, chronoburn, soracom-console, wuziqi, google-webapp, fcole90-hexgl-webapp, volleyball2d, qcheckers, ubuntu-app-platform, quassel-kalikiana, ubuntu-calculator-app
<pstolowski> zyga, looking ar 3095 now; quick question - did you decide not to be paranoid wrt close(fd) return values after all?
<fgimenez> mvo: thanks, greaat finding in https://forum.snapcraft.io/t/autopkgtest-broken/121
<mup> PR snapd#3127 opened: use github.com/mvo5/spread/cmd/spread until https://github.com/snapcoâ¦ <Created by mvo5> <https://github.com/snapcore/snapd/pull/3127>
<morphis> Son_Goku: one thing I've found is the that snapd.socket isn't started after I've installed the snapd pkg, is that expected?
<Son_Goku> no
<zyga> pstolowski: no
<zyga> pstolowski: because of what I referenced
<zyga> pstolowski: close return values are bogus
<Son_Goku> it's supposed to be started, since zyga and I got it added to the preset for Fedora 25
<zyga> pstolowski: and checking them makes no sense
<Son_Goku> actually, no
<Son_Goku> it's just enabled
<Son_Goku> morphis: afaik, you shouldn't need anything more than enabling a socket for it to work?
<Son_Goku> hmm, I guess not
<morphis> Son_Goku: I had to start it
<Son_Goku> morphis: fixed
<morphis> Son_Goku: great!
<morphis> mwhudson: ping
<morphis> zyga: so just confirmed, we have: INFO: snap "core" has bad plugs or slots: core-support (unknown interface) on debian too
<ogra> mvo, a second review for the PRs at https://github.com/snapcore/core-build/pulls would be appreciated (if you find a spare minute)
<mvo> ogra: sure, I have a look. I can't merge there it seems
<ogra> mvo, only niemeyer can, i hope we get that fixed today ... i want to merge the initrd scripts source into that tree after we got thie set of PRs in
<zyga> morphis: yeah, expected
<Son_Goku> morphis, hughsie has discovered issues with the snap backend in gnome software and is hacking on that now
<Son_Goku> I expect he'll enable it in gnome software shortly after snapd lands in the repos
<Chipaca> everything is terrible. Let's go back to netbsd.
<ogra> +1
<mup> PR snapcraft#1227 closed: docs: remove docs and link to snappy-docs <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1227>
<Son_Goku> also, why is snappy-docs in Canonical's github org rather than the snapcore one?
<Son_Goku> that's not an obvious place at all
<niemeyer> Mornings
<morphis> Son_Goku: great!
<Son_Goku> niemeyer: morning
<morphis> niemeyer: morning!
<niemeyer> ogra: Ah, sorry, let me get that fixed
 * Son_Goku grumbles
 * ogra hugs niemeyer 
<morphis> Son_Goku: good question for davidcalle
 * Son_Goku jumps off a cliff
<niemeyer> ogra: Should be working now
<ogra> Son_Goku, video or it didnt happen (and we want to see some fancy gymnastics !)
<niemeyer> Just added the usual snapd-committers team there
<Son_Goku> ogra: I'm too fat for that
<ogra> Son_Goku, nah, that just makes it extra funny (i'm not much slimmer than you iirc :P )
<Son_Goku> haha
<ogra> niemeyer, yep, worked, thanks
<niemeyer> Sweet, np
<mup> PR core-build#4 closed: Remove snapd.generate-network-conf.service <Created by zyga> <Merged by ogra1> <https://github.com/snapcore/core-build/pull/4>
<ogra> niemeyer, i'll creat an initrd/ subdir in there this afternoon to merge the initramfs-tools-ubuntu-core source in there then ... or would you prefer a different dir name ?
<mup> PR core-build#3 closed: Remove 10-ubuntu-core-secure-path <Created by zyga> <Merged by ogra1> <https://github.com/snapcore/core-build/pull/3>
<mup> PR core-build#1 closed: adjust README file to proper reflect repo content <Created by ogra1> <Merged by ogra1> <https://github.com/snapcore/core-build/pull/1>
<mup> PR core-build#2 closed: Rename snappy-set-hostname to snapd-set-hostname <Created by zyga> <Merged by ogra1> <https://github.com/snapcore/core-build/pull/2>
<davidcalle> Son_Goku: because it predates it :) But this will be fixed, agreed
<mup> PR snapcraft#1228 opened: nodejs plugin: switch to the newer LTS <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1228>
<Son_Goku> niemeyer: what happens to "channel" in a snapd json blob when someone sideloads a snap?
<jdstrand> cachio: did someone answer your question re reinstalling without downloading?
<niemeyer> Son_Goku: On the standup call.. will be with you shortly
<mup> PR snapd#3127 closed: use github.com/mvo5/spread/cmd/spread until https://github.com/snapcoâ¦ <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3127>
<niemeyer> Son_Goku: Okay, so.. can you open a topic in the forum with more details about the question?  (not sure about what "snapd json blob" means there)
<Son_Goku> niemeyer: hughsie is asking me about this for gnome-software in the #gnome-software channel on gimpnet
<niemeyer> Son_Goku: Easier to explain things there and sticks around for others to participate and learn from
<Son_Goku> he's trying to fix the snappy integration in gnome-software
<zyga> niemeyer: I could use a simple review on https://github.com/snapcore/snapd/pull/3114
<mup> PR snapd#3114: interfaces/mount: add function for saving fstab-like file <Created by zyga> <https://github.com/snapcore/snapd/pull/3114>
<Son_Goku> it's not really forum appropriate since the target audience isn't there
<niemeyer> Son_Goku: Chicken and egg
<Son_Goku> in this case, the chicken won't go across the road :)
<niemeyer> Son_Goku: It's okay, they don't have to.. they can simply learn from what the two of us discuss there
<niemeyer> Son_Goku: And others will too
<niemeyer> Son_Goku: The important thing is not losing these interesting discussions to IRC logs
<Son_Goku> is this really all that interesting?
<niemeyer> zyga: Looking
<zyga> Son_Goku: I think thre are other front-ends to install stuff
<zyga> Son_Goku: I bet it will be interesting
 * Son_Goku sighs
<niemeyer> Son_Goku: if you don't want to, I'm happy to make a monologue there.. just provide more details about the question and I'll write it all
<Son_Goku> sure, one sec
<mup> PR snapd#3128 opened: interfaces/mount: fix golint issues <Created by zyga> <https://github.com/snapcore/snapd/pull/3128>
<cachio> jdstrand, the solution I got is to download the snap and then install as many times as I want
<cachio> jdstrand, is it the best way to do it?
<Son_Goku> niemeyer: here: https://forum.snapcraft.io/t/how-to-determine-source-of-snap/125
<jdstrand> cachio: that is the way to do it. snap download foo. sudo snap ack ./foo*.assert ; sudo snap install ./foo*.snap
<niemeyer> Son_Goku: Thanks so much
<niemeyer> Son_Goku: Going there right now
 * Son_Goku is tired
<jdstrand> cachio: if you ack the assertion, you don't need --dangerous
<niemeyer> Son_Goku: I've heard you did some great work over the weekend.. thanks a lot for that!
<cachio> jdstrand, great, I'll do that
 * Son_Goku sighs
<cachio> jdstrand, tx
<jdstrand> I'm not sure if you were told that, but that is handy and is equivalent to an install from the store
<Son_Goku> niemeyer: I really hope it isn't going to be as hellish in the future
<Son_Goku> I spent all weekend on it :(
<jdstrand> where --dangerous is not in terms of base declaration checks
<niemeyer> Son_Goku: Yeah, it probably won't.. the integration points with the distribution don't really change all that often.. very seldom we need to touch the package
<Son_Goku> niemeyer: of course, that's easy for you, since you mainly care about it working on Ubuntu and Ubuntu Core
<Son_Goku> :)
<Chipaca> https://go-review.googlesource.com/c/39207/ <- log.Fatal(http.Serve(autocert.NewListener("example.com"), handler)) <- i.e. letsencrypt oneliner
<Son_Goku> zyga: did you see my response to the cgroups bug?
<niemeyer> Son_Goku: That's misjudging what I care about.. :)
<zyga> Son_Goku: not yet, I just replied to it in the morning
 * zyga looks
<zyga> Son_Goku: noted
<zyga> morphis: I think we want to talk to Zbigniew there to understand what we need to do
<zyga> morphis: https://bugs.launchpad.net/snappy/+bug/1678342
<mup> Bug #1678342: snapd udev rules are incompatible with unified cgroup hierarchy <Snappy Launcher:New> <snapd:New> <Snappy:Incomplete by zyga> <snapd (Fedora):Unknown> <https://launchpad.net/bugs/1678342>
<zyga> morphis: if you initiate the conversation I'm happy to make all the changes required
<Son_Goku> zyga: he's zbyszek in #fedora-devel
<Son_Goku> morphis ^
<zyga> morphis: maybe Zybszek is on IRC around as he seems to be in the same timezone
<zyga> :D
<zyga> Son_Goku: I was typing the same thing :)
<jdstrand> kyleN: I answered on the list
<kyleN> thanks jdstrand
<jdstrand> pekkari: hey, 'ubuntu-kernel' is a very official sounding name for a kernel snap. you might want to run the name of your snap by JamieBennett, et al
<morphis> zyga, Son_Goku: yeah saw that bug earlier today, and its on my list to look into
<Son_Goku> mvo: is the focus now on snapd 2.24?
<jdstrand> pekkari: I put a comment in the snap asking for feedback
<jdstrand> in the store*
<pekkari> jdstrand: got it, thanks for reviewing!
<pekkari> I'll ask Jamie
<zyga> Son_Goku: yes
<Son_Goku> zyga: does snapd-login-service require snapd to be installed?
<mup> PR snapd#3129 opened: interfaces/mount: add InfoEntry type <Created by zyga> <https://github.com/snapcore/snapd/pull/3129>
<zyga> Son_Goku: I don't know, I think it talks to snapd over the socket
<Son_Goku> hmm
<zyga> Son_Goku: if you just install it those calls will fail
<zyga> Son_Goku: but it should be OK
<Son_Goku> then I should drop the Requires
<Son_Goku> because Fedora Workstation is going to be pissed if gnome-software pulls in snapd when they don't want it
<zyga> Son_Goku: what happens when you don't have snapd and you have the login package
<Son_Goku> I have no idea
<zyga> Son_Goku: does gnome-software work correctly?
<Son_Goku> again, no idea
<zyga> morphis: ^ something to try
<zyga> Son_Goku: as long as it just works droping the Requires is correct
<zyga> Son_Goku: if it breaks we should see so that it doesn't
<jdstrand> ogra: hi! I see linux-generic-bbb has 71 in edge-- when do you plan to release that to stable?
<Son_Goku> well, the Requires was originally written by you, I think, so hell if I know
<zyga> Son_Goku: (maybe offer a GUI action to install snapd)
<Son_Goku> zyga, uhh wut? [10:15:49 AM]  <hughsie>	Son_Goku, so, a packaging error? http://imgur.com/a/CowmR
<Son_Goku> any explanation for the random Turkish?
<zyga> Son_Goku: woah
<zyga> Son_Goku: no, something very very weird indeed
<ogra> jdstrand, oh, sorry, forgot about the extra click ... doing now
 * zyga waves hi to Richard and his fantastic hardware :)
<Son_Goku> zyga: morphis: someone needs to hop into #gnome-software on irc.gimp.org
<ogra> jdstrand, done
<zyga> I think we should find Robert that wrote that part
<morphis> Son_Goku: I am on the way
<jdstrand> ogra: thanks!
<zyga> morphis: ^ can you hop into #g-s there
<zyga> morphis: thanks!
<zyga> Son_Goku: meanwhile I'll be working with mount more until it works
<Son_Goku> I gotta go to work, but I can't leave hughsie hanging
<zyga> Son_Goku: I think morphis will take over, thank you for keeping an eye out for this!
<morphis> Son_Goku: #g-s or #gnome-software?
<morphis> ah have the right one
<niemeyer> Son_Goku: Answered
<niemeyer> Son_Goku: Sorry, answering it properly took a little while..
<niemeyer> morphis, zyga: ^
<morphis> niemeyer: an answer to what? :-)
<niemeyer> morphis: Sorry, I thought you were following the conversation.. I suggest reading the backlog from 1h10min ago that we had here, as that's relevant for the conversation you'll have in #g-s
<morphis> niemeyer: ah I see, you're referring to the "How to determine âsourceâ of snap?" thread
<niemeyer> morphis: Are you on top of these exchanges?
<mvo> Son_Goku: yes, the next release will be 2.24, 2.23.6 is hopefully in good shape now. if you have anything that you need in there, please add a reply to the topic
<morphis> niemeyer: I am on it, yes
<Son_Goku> mvo: I'll add a reply soonish, as there's *a lot* I need to be in 2.24
<mvo> Son_Goku: oh, ok :)
<Son_Goku> mvo: http://pkgs.fedoraproject.org/cgit/rpms/snapd.git/tree/snapd.spec#n52 :)
<Son_Goku> actually, not so much I guess
<Son_Goku> just a couple more PRs
<Son_Goku> anyway, bye for now
<morphis> mvo: 2.24 is targetted for this thursday?
<mvo> morphis: no ETA yet, we should discuss that
<mvo> morphis: we can target anything that Son_Goku needs in GH so that its on the radar
<mup> PR snapd#3130 opened: overlord/devicestate: switch to keygen for device key generation <Created by vosst> <https://github.com/snapcore/snapd/pull/3130>
<pedronis> mvo: are we cutting 2.24 tomorrow?
<morphis> mvo: there are some he has in his list I am currently prepping to be ready
<mvo> pedronis: I think we should discuss in the standup, JamieBennett also has a say in this of course.
 * zyga goes to merge https://github.com/snapcore/snapd/pull/3114 with 2 +1 already
<mup> PR snapd#3114: interfaces/mount: add function for saving fstab-like file <Created by zyga> <https://github.com/snapcore/snapd/pull/3114>
<mup> PR snapd#3114 closed: interfaces/mount: add function for saving fstab-like file <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3114>
<JamieBennett> mvo: pedronis:, morphis: Well, it would be good to push out this release asap as it contains a lot of changes, so sooner rather than later. What is a sensible cut off day for the release?
<pedronis> mvo: zesty will not have 2.24 either way out of the door right?
<morphis> JamieBennett: if there are more important things we don't have to block on the PRs King_InuYasha pointed out, having them included would only allow us to drop all these patches on the distro packages
<JamieBennett> morphis: what is the eta for these landing?
<morphis> JamieBennett: I am trying to finish these as we speak
<mup> PR snapd#3131 opened: interfaces/mount: add OptsToFlags for converting arguments to syscallâ¦ <Created by zyga> <https://github.com/snapcore/snapd/pull/3131>
<morphis> niemeyer: https://github.com/snapcore/snapd/pull/3039 needs another review from your side
<mup> PR snapd#3039: many: add support for partially static builds <Created by zyga> <https://github.com/snapcore/snapd/pull/3039>
<mup> PR snapcraft#1077 closed: Shout -> Lounge, the official fork <Created by MaxLeiter> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1077>
<mup> PR snapcraft#1225 closed: channels: Fix staging store test for Tracks <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1225>
<mvo> pedronis: probably not, final freeze is thursday, highly unlikely. I'm pretty sure there will be a 0-day SRU for this one
<pedronis> mvo: anyway if we cut it tomorrow is unlikey that new aliases will make it, maybe slightly more likely if Thu, but not sure (depends on reviews)
<pedronis> otherwise they will be in 2.25
<mvo> pedronis: ok, thank you. we can hear what JamieBennett thinks about cutting the release thur/fri, preparing everything in beta and moving forward with candidate on monday maybe? if it means that new aliases may make it this way
<niemeyer> morphis: Reviewed
<niemeyer> and lunch time.. back in a bit
<mup> Bug #1679210 opened: snap install --revision tracks stable by default <Snappy:New> <https://launchpad.net/bugs/1679210>
<morphis> niemeyer: thanks!
<zyga> niemeyer: can I get a trivial review for: https://github.com/snapcore/snapd/pull/3131/files
<mup> PR snapd#3131: interfaces/mount: add OptsToFlags for converting arguments to syscallâ¦ <Created by zyga> <https://github.com/snapcore/snapd/pull/3131>
<zyga> I could use a review of https://github.com/snapcore/snapd/commit/26ebf0c2866e14ab14099d550e723dc78561536d
<zyga> I'll propose it after https://github.com/snapcore/snapd/pull/3131 lands
<mup> PR snapd#3131: interfaces/mount: add OptsToFlags for converting arguments to syscallâ¦ <Created by zyga> <https://github.com/snapcore/snapd/pull/3131>
<niemeyer> zyga: I need to have a look at pending topics and PRs first, but will be there soon
<zyga> niemeyer: sure, thanks!
<zyga> niemeyer: I'll take a break now, I have a few more useful bits and I'll try to land most that I wrote today
<zyga> niemeyer: if you can please focus on https://github.com/snapcore/snapd/pull/3095
<mup> PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095>
<zyga> niemeyer: after that in any order
<zyga> pstolowski: ^^ can you please review this again as well
<zyga> pstolowski: you are also blocking it ATM
<pstolowski> k
<pstolowski> zyga, blocking? i aproved it last time
<zyga> pstolowski: oh, I need to refresh :)
<pedronis> niemeyer: it seems we never had to delete a top key in state, is there a use case for state.Set(key, nil)Â not to mean delete?
<zyga> pstolowski: indeed, thank you :)
<pstolowski> zyga, :)
<niemeyer> pedronis: Ideally those would mean the same thing
<pedronis> niemeyer: it's not implemented like that atm, but it seems the right thing (instead of growin state.Del or state.Delete)
 * zyga -> off
<niemeyer> pedronis: https://forum.snapcraft.io/t/should-missing-state-keys-and-null-keys-be-the-same/128
<morphis> zyga, King_InuYasha, Pharaoh_Atem: if you don't follow the conversation in
<morphis> #gnome-software, looks like we miss gettext support in policykit on other distros
<morphis> zyga, King_InuYasha, Pharaoh_Atem: https://bugs.freedesktop.org/show_bug.cgi?id=29639
<morphis> Robert filed that ages ago
<morphis> will go a little bit more in the details tomorrow but the easiest we can do is dropping all other languages from the .policy file and only keep en there
<morphis> as it always picks the last one
<morphis> (which is turkish in the default case)
<ogra> morphis, how lame, so fedora has no zulu translations ?
<ogra> :)
<cmars> is it possible to publish snaps in such a way that they're private to a list of users, or maybe a LP team?
<mup> PR snapd#3132 opened: overlord/state: make sure that setting to nil a state key is equivalent to deleting it <Created by pedronis> <https://github.com/snapcore/snapd/pull/3132>
<ogra> pedronis, http://paste.ubuntu.com/24307672/ thats an image using ssh-keygen i just tested ... 17:08:57 Generate device key ... 17:09:45 Mark system seeded ... lots faster :)
 * ogra goes afk 
<mup> PR snapcraft#1221 closed: pluginhandler: factor out state bits into the state package <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1221>
<mup> PR snapcraft#1226 closed: Better check of the error code in StatusTracker <Created by facundobatista> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1226>
<niemeyer> Taking a break for exercising, then back for more reviews..
<datajerk> hi all, i'm trying to get snaps working on the nvidai tx2, i patch the kernel config so that snap would mount, etc..., but am now getting the following error with snap install hello-world: Run configure hook of "core" snap if present (run hook "configure": execv failed: No such file or directory).  Google not much help with this one.  Thanks.
<datajerk> from syslog: /usr/lib/snapd/snapd[3391]: snapmgr.go:807: Reported problem as c3074eec-18a3-11e7-a49b-fa163ebeb28a OOPSID
<mup> PR snapd#3128 closed: interfaces/mount: fix golint issues <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3128>
<kyrofa> datajerk, does the kernel include apparmor?
<zyga> datajerk: hey
<zyga> datajerk: can you tell me more about your system, I assume you have the tx2 devkit (nice, how did you get one?)
<zyga> datajerk: can you tell me if this is a classic system? (with apt-get and such) and snapd as an extra or just snapd (no apt, dpkg, just snaps)
<datajerk> CONFIG_SECURITY_APPARMOR=y
<datajerk> CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
<datajerk> CONFIG_SECURITY_APPARMOR_HASH=y
<datajerk> CONFIG_DEFAULT_SECURITY_APPARMOR=y
<datajerk> kyrofa ^^
<zyga> datajerk: which kernel are you running?
<zyga> datajerk: and which version of snapd?
<datajerk> zyga tx2 devkit, yes, ubuntu classic 16.04.02.  nvidia kernel 4.4.15, patch kernel to support docker and snap (just .config).
<zyga> datajerk: aha
<zyga> datajerk: so
<zyga> datajerk: you need either bleeding edge snapd that understands you don't have the full apparmor patchset
<zyga> datajerk: or you need to patch the nvidia kernel to contain all the apparmor ubuntu sause
<kyrofa> datajerk, snapd requires apparmor patches that aren't available upstream just yet
<kyrofa> Yeah, that
<datajerk> zyga which is recommended, faster?
<datajerk> URLs?
<zyga> datajerk: I think trying to get apparmor patches may be better, one sec
<zyga> datajerk: http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/log/
<zyga> datajerk: try to see what's in security/apparmor that is not in 4.4
<zyga> datajerk: the execve failure is very curious though
<zyga> datajerk: I think we should see that error report
<zyga> datajerk: can you run "snap changes" and then "snap change 123" where 123 is the ID of latest change
<zyga> datajerk: quick search shows about three pages of apparmor patches http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/log/security/apparmor?qt=grep&q=SAUCE:+apparmor&ofs=100
<jdstrand> tyhicks: iirc you have a more up to date list? ^
<zyga> jdstrand: oh, thank you
<zyga> jdstrand: I'd love to have this
<zyga> tyhicks: if you have a better list can you please post that on a forum and refer to the forum here
<jdstrand> well, I think the canonical (little 'c') list of patches is in the porting guide
<tyhicks> jdstrand: I don't have a list
<zyga> jdstrand: where is the porting guide?
<zyga> jdstrand: last time I looked at sample kernels it was vary out of date
<zyga> very*
<Pharaoh_Atem> there's a porting guide?
<tyhicks> a list isn't really maintainable because the patches needed are ever-changing
<jdstrand> tyhicks: I actually meant the porting guide
<zyga> tyhicks: yes, exactly
 * jdstrand is looking
<zyga> tyhicks: I think having a branch against 4.x (some important releases) would be fantastic
<tyhicks> oh, that's not really helpful
<tyhicks> https://github.com/snapcore/sample-kernels/blob/master/README.md
<tyhicks> that's the porting guide
<Pharaoh_Atem> that's not helpful at all
<tyhicks> zyga: that's what the samples-kernel tree is supposed to be but it would take quite a bit of time to backport, maintain and test
<zyga> tyhicks: I think what people start with is a kernel (various versions) and they keep asking "how do we get apparmor support in this kernel"
<jdstrand> that's it. jeez, I could not find it :P
<zyga> tyhicks: aha
<zyga> tyhicks: is there more than the apparmor sauce required?
<tyhicks> zyga: yes, depending on what kernel version you're backporting to
<datajerk> zyga changes output: http://termbin.com/8esh
<zyga> tyhicks: we commonly see 4.x (including mainline) and 3.4 (some android support kernel I suspect)
<Pharaoh_Atem> zyga: for example, depending on which point in time of the CentOS 7 kernel you're porting to, you may or may not have to just do apparmor stuff
<kyrofa> seccomp filters was only v3.5, but I think it's its own config option
<zyga> datajerk: thank you, checking
<Pharaoh_Atem> and 3.4 is the ancient kernel required for loads of old Android devices :(
<tyhicks> zyga: I doubt 3.4 is possible without serious amounts of work
<kyrofa> Pharaoh_Atem, yeah I backported seccomp filters to v3.4. Super fun
<zyga> datajerk: huh, that's curious
<sborovkov> jdstrand: Hi. I answered your request for clarification about dbus issue in the mailing list. Could you take a look when you have time please.
<zyga> datajerk: I'd love to see what is there (the error report)
<zyga> tyhicks: and mainline?
<Pharaoh_Atem> kyrofa: the only time I have to work with v3.4 is when some ass decides that Android hardware is Good for Regular Linux(TM)
<zyga> tyhicks: (this will be often the story of another distribution that may choose to take our patches)
<kyrofa> Haha
<zyga> Pharaoh_Atem: android hardware is, android software is not
<datajerk> zyga location of error report?
<Pharaoh_Atem> right, but uninformed people confuse and conflate
<tyhicks> zyga: maineline should be possible
<Pharaoh_Atem> tyhicks: last I checked (4.9), it wasn't
<zyga> datajerk: I'm afraid I cannot see that, it goes to errors.ubuntu.com, it's pretty restricted as some reports may be sensitive
<zyga> tyhicks: I think that would be very useful
<zyga> tyhicks: who is maintaining sample kernels? kernel or security team?
<jdstrand> sborovkov: you have two services? that offer dbus interfaces?
<Pharaoh_Atem> zyga: according to readme, no one?
<tyhicks> zyga: kernel team set it up - nobody is maintaining it
<zyga> aha
<zyga> perhaps jjohansen could maintain a mainline + patches branch as he probably has that already for upstreaming
<tyhicks> he periodically does that
<zyga> tyhicks: do you think that would be low cost?
<zyga> (useful without a lot of extra burden on the security team)
<sborovkov> jdstrand: well one exposes it. the second one just does some IPC calling those methods from system bus. I actually have more services that expose dbus interfaces. But they are in another branch at the moment.
<tyhicks> jjohansen: let me save you some backscroll reading - zyga and Pharaoh_Atem were curious if you have the apparmor kernel delta forward ported to Linus' tree anywhere?
<sborovkov> jdstrand: I meant only one exposes dbus interfaces :-)
<zyga> tyhicks: thank you! :)
<Pharaoh_Atem> :)
<jdstrand> sborovkov: so you have something like a <-> b <-> c, where 'a' is a dbus service that binds to a well-known name, 'b' talks to it and exposes to other things, like 'c'?
<NicolinoCuralli> hi all i need to chanche the systemd timer for snap.refresh: is it possibile by setting a configuration option with snap set command?
<jdstrand> datajerk: to circle back to you, what kernel are you wanting patches for?
<jdstrand> datajerk: 3.4 based, 3.10, 4.4, ...?
<sborovkov> jdstrand: I am not familiar with dbus therminology, so I've got this basically. Service 1 - exposes interface. Service 2 - gets the bus and makes a call to the exposed interface
<jdstrand> sborovkov: so, client and server, nothing else?
<datajerk> jdstrand 4.4.15 is what nvidia provides with *their* patches, so i have to patch that kernel, cannot use stock
<jdstrand> sborovkov: service 1 binds to com.screenly.playlist and service 2 talks to it?
<sborovkov> jdstrand: at the moment, nothing else. In the future there will be a few more services that will be client and the server at the same time, i.e. expose some stuff and call some other stuff.
<sborovkov> jdstrand: correct
<jdstrand> datajerk: ok, so with 4.4 you can look at the Ubuntu delta for 16.04, since that is a 4.4 kernel
<datajerk> jdstrand thanks, do you happen to have a url for that, i'm not familiar with where ubuntu stores all their patches and deltas, thanks
<jdstrand> sborovkov: ok, and in your yaml, playlist binds to the well-known name and websocket talks to it?
<jdstrand> sborovkov: I thought I saw a url go by. I'll refer you to tyhicks to verify
<sborovkov> jdstrand: yes, see my first mail I quoted that yaml subsections
<jdstrand> sborovkov: right, I am looking at that email. I wanted to verify your code did that too
<Pharaoh_Atem> jjohansen: main reason for this is because I considered pushing for AppArmor to be enabled in 4.9 for Mageia
<Pharaoh_Atem> but there's no value if the patches aren't upstreamed
<zyga> Pharaoh_Atem: they are, look at mainline man, it's just not _all_ ready
<Pharaoh_Atem> zyga: I don't know what to look for
<tyhicks> Pharaoh_Atem: 60 patches went up for 4.11 and some more should go up soon for 4.12
<zyga> Pharaoh_Atem: changes in security/apparmor
<tyhicks> Pharaoh_Atem: good progress is being made
<Pharaoh_Atem> excellent
<jdstrand> sborovkov: I was a bit confused about the phrasing in the last email. I don't understand how websocket, ie, service 2 (the client of playlist) can 'get system bus without any issues' if service 1, playlist, can'
<Pharaoh_Atem> then that means that when the next longterm kernel rolls around this fall, it'll all be there
<jdstrand> t register on dbus
<sborovkov> jdstrand: well second service obtains system bus. When it tries to call method from "com.screenly.playlist" I get an exception that the name was not provided by any service file. In the server though the same line bus = SystemBus() triggers an exception (I am using pydbus)
<NicolinoCuralli> all: Hi, a question about snapd.refresh timer: is it possibile by setting a configuration option with snap set command?
<sborovkov> jdstrand: https://hastebin.com/lezozujaxi.sql
<jdstrand> sborovkov: ok, so playlist didn't start because of an apparmor denail, and then websocket can't connect to it because it didn't start?
<sborovkov> jdstrand: yup
<zyga> NicolinoCuralli: hey, no but that timer has a purpose differen from what you may think
<tyhicks> datajerk: the patches for a 4.4 are here: http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/log/security/apparmor
<jdstrand> sborovkov: what is the apparmor denial you see when playlist doesn't start?
<zyga> NicolinoCuralli: that is a failover refresh
<Pharaoh_Atem> zyga: the other reason is for figuring out if I wanted to attempt the backport, what I need to look for to get enough working for snapd
<jdstrand> sborovkov: let's look at playlist first, then look at websocket
<zyga> NicolinoCuralli: snapd does refresh internally and there's work (branches) in progress that will allow to configure how / when the refresh happens
<tyhicks> datajerk: you'll need them all back to "UBUNTU: SAUCE: (no-up) apparmor: add parameter to control whether policy hashing is used"
<sborovkov> jdstrand: https://hastebin.com/pakuciqide.go
<sborovkov> jdstrand: and this is   from python: GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.7" (uid=0 pid=1478 comm="python3 -m screenly.client.playlist -c /var/snap/s") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (
<sborovkov> bus) (9)
<jdstrand> why is there an overlay in the upper right that is covering important info?...
<sborovkov> you mean on hastebin? I have 2560x1440 resolution so I never noticed that
<jdstrand> sborovkov: can you paste the denial here?
<jdstrand> line 2
<jdstrand> sborovkov: nm, I went to https://hastebin.com/raw/pakuciqide
<NicolinoCuralli> zyga: i need to understand the algorithm used for update the snap : after a publication on store how many time i need to wait for update on my board? i just test it and no autoupdate happen
<mup> Bug #1679295 opened: Interface to access /sys filesystem <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1679295>
<tyhicks> jdstrand: it looks like an incomplete paste to me
<jdstrand> sborovkov: well, I take that back. it seems the log entry was truncated
<jdstrand> sborovkov: look at interface="org.freedesktop.
<zyga> NicolinoCuralli: I think it is randomized 6 hours
<zyga> NicolinoCuralli: you can refresh manually
<jdstrand> sborovkov: that is incomplete. can you paste the complete denial?
<NicolinoCuralli> zyga: my board run unattended: it is not possibile to run manually snap refresh on the board
<sborovkov> jdstrand: oh one sec
<sborovkov> jdstrand: https://hastebin.com/nijayemime.scala
<zyga> NicolinoCuralli: setup ssh and log in
<zyga> NicolinoCuralli: you had to install your snap somehow right?
<jdstrand> sborovkov: that denial is saying an unconfined process is trying to introspect the playlist. is this on Ubuntu classic distro or all snaps?
<sborovkov> jdstrand: it's on core
<NicolinoCuralli> zyga: yes, my problem is after first installation : after this moment i can't login on board
<jdstrand> sborovkov: ok. what is introspecting playlist?
<zyga> NicolinoCuralli: did you setup ssh on your launchpad account?
<NicolinoCuralli> yes
<jdstrand> sborovkov: (because on core there are no rules allowing introspection by unconfined)
<zyga> NicolinoCuralli: can you ssh ubuntu@IP-of-the-board?
<sborovkov> jdstrand: I've no idea. I have nothing else running there especially in unconfined. Image was created by ubuntu-image. With confinement set to strict in screenly-client snap
<jdstrand> it looks like maybe dbus-daemon is introspecting it
<NicolinoCuralli> zyga: i will have several board ( thousand ) i can't ssh into all of them: this is the reason about my question on snap refresh mechanism
<jdstrand> sborovkov: does your playlist code Introspect()?
<sborovkov> jdstrand: not manually. pydbus might be doing that I guess?
<jdstrand> maybe
<sborovkov> jdstrand: yeah I am pretty sure it does that, because it required library that supported introspection. gio something. or it's dependency.
<jdstrand> sborovkov: can you add to /var/lib/snapd/apparmor/profiles/snap.screenly-client.playlist this rule before the ending '}'
<jdstrand> sborovkov: http://paste.ubuntu.com/24308617/
<datajerk> tyhicks thanks!
<tyhicks> np!
<jdstrand> sborovkov: after you add that you need to load it into the kernel with: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.screenly-client.playlist
<sborovkov> trying
<jdstrand> sborovkov: after you do that, please stop and start your service (eg, sudo service snap.screenly-client.playlist stop ; sudo service screenly-client.playlist start
<zyga> NicolinoCuralli: the mechanism is as I described, for development you should have one board with working ssh
<jdstrand> sborovkov: and let me know if there are any more denials
<jdstrand> sborovkov: whoops, I meant: sudo service snap.screenly-client.playlist stop ; sudo service snap.screenly-client.playlist start
<sborovkov> jdstrand: why not just restart it?
<sborovkov> is there any difference?
<jdstrand> sborovkov: I just wanted to make sure of a clean start. it shouldn't matter
<sborovkov> jdstrand: getting the same denial it seems.
<jdstrand> sborovkov: you loaded the profile with apparmor_parser?
<sborovkov> yes
<jdstrand> sborovkov: can you paste the new denial as well as /var/lib/snapd/apparmor/profiles/snap.screenly-client.playlist?
<sborovkov> jdstrand: sure one moment
<jjohansen> Pharaoh_Atem, zyga, tyhicks: they exist again 4.10 in the bacport tree http://kernel.ubuntu.com/git/jj/linux-apparmor-backports/log/?h=v4.10-aa3.6-backport-base
<jjohansen> I have not done an updated diff to 4.11 yet
<NicolinoCuralli> zyga: i want to use snappy on a production environment : i tested it on my development board and i find that snapd don't upgrade automatically after publication on store ; what mean it?
<sborovkov> jdstrand: Denial - https://hastebin.com/jahisohuba.scala apparmor file - https://hastebin.com/upuminowup.pl
<jjohansen> the plan is to maintain a backwards/forwards port until everything lands upstream, then well just backports
<jdstrand> sborovkov: oh, well, yes, the rule I gave was for 'receive', it should've been for send. let me rewrite the rule
<Pharaoh_Atem> jjohansen: is aa3.6 referring to userspace utils version?
<Pharaoh_Atem> I don't recall a 3.x series existing
<sborovkov> jdstrand: after replacing receive with send it works. Or does it need more changes?
<jjohansen> Pharaoh_Atem: no, its the versioning for the dev kernels
<jdstrand> sborovkov: it needs an additional change. please remove that rule and try: http://paste.ubuntu.com/24308686/
<NicolinoCuralli> zyga: i would like understand that what happen is it a bug? how could I help you to understand?
<jjohansen> Pharaoh_Atem: it wasn't supposed to be that way, and we will get back to things being more in sync,
<Pharaoh_Atem> jjohansen: any idea on the timeline for that? as it is, I get pretty confused trying to figure out what I need for aa
<sborovkov> jdstrand: done. it works.
<jjohansen> Pharaoh_Atem: hrmmm, this year sometime, we have agreed in principle to spin a 4.0 release for userspace, and what goes into upstream will be referred to as 4.x
<jdstrand> sborovkov: ok, this is a bug in snapd. I'll prepare a PR and respond to the list
<sborovkov> jdstrand: thanks for your assistance! Is there some workaround meanwhile?
<jdstrand> sborovkov: in the meantime, you can workaround the issue by adding that rule and loading the policy. note that snapd occasionally refreshes the security policy so your changes may disappear at any time
<jjohansen> I am hoping for 4.13, for everything landed
<jdstrand> jjohansen: everything? that would be awesome :)
<sborovkov> jdstrand: hmm, I can't use that. Since we would distribute images created with ubuntu-image to clients who don't have access to it. Guess I will need to wait for snapd update.
<Pharaoh_Atem> jjohansen: that would make things really nice
<Pharaoh_Atem> openSUSE Leap will rebase on the next summer longterm kernel for 42.3
<Pharaoh_Atem> or actually, it might be frozen now, I'd have to check
<jdstrand> sborovkov: like I said, I'll have the PR up in a few minutes and it should be in 2.24. you can go through your normal channels and see if someone wants to backport it to 2.23
<Pharaoh_Atem> but openSUSE Leap 43.1 and SLE 13 would be in good shape (both are under development now)
<sborovkov> jdstrand: understood. thanks again :-)
<jdstrand> sborovkov: I don't know the snappy team's plans for 2.23 update vs 2.24 otherwise I could be more specific
 * jdstrand goes to fix the bug
<jjohansen> Pharaoh_Atem: I have been meaning to provide a kernel for suse in the obs, would that be of interest to you?
<Pharaoh_Atem> jjohansen: for my purpose of figuring out AppArmor, yes
<sborovkov> jdstrand: At least I can go to sleep knowing that this is going to be resolved. Just 5 minutes from midnight here :-)
<Pharaoh_Atem> jjohansen: good news is, openSUSE maintains their kernel tree publicly in git, so you can work from it
<jjohansen> Pharaoh_Atem: okay, I'll see what I can do sooner than later
<Pharaoh_Atem> jjohansen: https://github.com/openSUSE/kernel-source
<Pharaoh_Atem> https://github.com/openSUSE/kernel
<jjohansen> Pharaoh_Atem: hehe, yeah I know though its only sort of git, they still use the old build patch queue system, they just shoved that into git. Well at least for the obs build sources I have played with, when building test kernels for cboltz
<Pharaoh_Atem> jjohansen: yeah, it's really weird
<jjohansen> its okay, I understand the old system, I used to work for suse on the kernel :)
<Pharaoh_Atem> jjohansen: it's good someone understands it
<Pharaoh_Atem> I certainly don't
<mup> PR snapd#3133 opened: interfaces: allow slot to introspect dbus-daemon in dbus interface, allow /usr/bin/arch by default <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3133>
<jdstrand> ondra: fyi, https://github.com/snapcore/snapd/pull/3133 has the 'arch' fix
<mup> PR snapd#3133: interfaces: allow slot to introspect dbus-daemon in dbus interface, allow /usr/bin/arch by default <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3133>
<zyga> niemeyer: any chanece for a re-review on https://github.com/snapcore/snapd/pull/3095 ?
<mup> PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095>
<ondra> jdstrand o/ thanks!
<mup> PR snapd#3133 closed: interfaces: allow slot to introspect dbus-daemon in dbus interface, allow /usr/bin/arch by default <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/3133>
<mup> PR snapcraft#1229 opened: source: add bazaar tracking <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1229>
<mup> Bug #1679432 opened: Bluetooth SCO connections don't work on Dragonboard 410c <Snappy:New> <https://launchpad.net/bugs/1679432>
#snappy 2017-04-04
<mwhudson> maybe the Status update for version mails from the store should mention architecture?
<morphis_> robert_ancell_: ping
<robert_ancell_> morphis_, hi
<morphis_> robert_ancell_: we're currently porting snapd-glib to Fedora and enabling support for it in gnome-software there too
<robert_ancell_> morphis_, awesome, thanks!
<morphis_> robert_ancell_: however we saw something very interesting: http://imgur.com/a/CowmR
<morphis_> the default locale of the user is en_GB but he gets turkish messages; I figured out later yesterday that this is because policykit in Fedora doesn't have gettext support
<robert_ancell_> oh
<morphis_> robert_ancell_: and found an old upstream bug you filed years ago https://bugs.freedesktop.org/show_bug.cgi?id=29639
<morphis_> so policykit always falls back to the last <message ..> entry in the .plolicy file
<robert_ancell_> morphis_, ah, I probably forgot about that and should generate the PolicyKit file with the translations as per the spec
<robert_ancell_> morphis_, I can fix that up tomorrow and make a 1.10 release
<morphis_> robert_ancell_: awesome!
<robert_ancell_> morphis_, thanks for finding the problem!
<morphis_> robert_ancell_: so upstream polkit has gettext support but in a different way?
<robert_ancell_> morphis_, I think it never got accepted upstream and I didn't notice because I'm testing on Ubuntu
<morphis_> robert_ancell_: np, Son_Goku and a gnome-software developer found it :-)
<morphis_> robert_ancell_: yeah.. :-)
<morphis_> robert_ancell_: as I am mainly focussing on cross-distro these days I am seeing  a lot of these things
<morphis_> robert_ancell_: btw. would it make sense to move snapd-glib over to github.com/snapcore?
<robert_ancell_> morphis_, possibly. I ended up putting on LP just to get going quickly.
<robert_ancell_> morphis_, do you know who I'd have to ask to migrate there?
<morphis_> robert_ancell_: I think zyga or niemeyer can do that
<morphis_> robert_ancell_: if you don't overlap with them today I can talk with them or maybe better you create a forum topic on forum.snapcraft.io
<robert_ancell_> morphis_, I'm past EOD, so I have to head off now. If you could raise it with them today that would be helpful.
<robert_ancell_> bye
<zyga> good morning
<zyga> mvo: hey, could you please review https://github.com/snapcore/snapd/pull/3131
<mup> PR snapd#3131: interfaces/mount: add OptsToFlags for converting arguments to syscallâ¦ <Created by zyga> <https://github.com/snapcore/snapd/pull/3131>
<zyga> mvo: and perhaps https://github.com/snapcore/snapd/pull/3129 (just a struct)
<mup> PR snapd#3129: interfaces/mount: add InfoEntry type <Created by zyga> <https://github.com/snapcore/snapd/pull/3129>
<mvo> zyga: sure
<mup> PR snapd#3039 closed: many: add support for partially static builds <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3039>
<zyga> thanks :)
<zyga> mvo: ^^ I just landed partially static builds, let me know if something starts to misbehave
<mvo> ok
<mup> PR snapd#3125 closed: tests: download and install additional dependencies when using prepackaged snapd <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3125>
<zyga> oho, a bug in regression test
<zyga> /bin/bash: line 56: [: missing `]'
<mup> PR snapd#3134 opened: tests: fix incorrect shell expression <Created by zyga> <https://github.com/snapcore/snapd/pull/3134>
<zyga> mvo: https://github.com/snapcore/snapd/pull/3134 this will fix some autopkgtest failures
<mup> PR snapd#3134: tests: fix incorrect shell expression <Created by zyga> <https://github.com/snapcore/snapd/pull/3134>
<mup> PR snapd#3106 closed: tests: enable docker test for more ubuntu-core systems <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3106>
<zyga> morphis_: hey, I wanted to get this on your radar https://bugzilla.novell.com/show_bug.cgi?id=1028568
<zyga> morphis_: I'll open a forum topic to discuss this
<mvo> zyga: thanks, I'm going over all the one ones now
<mvo> zyga: keen to see the tests, autopkgtest should be fixed
<zyga> mvo: I'll merge master into https://github.com/snapcore/snapd/pull/3085 once the fix above lands and everything (maybe) goes green
<mup> PR snapd#3085: .travis.yml: remove travis matrix and do a single sequential run <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3085>
<mup> PR snapd#3112 closed: interfaces: add a joystick interface <Created by kyrofa> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3112>
<mvo> ha! #3115 has all tests green again, so nice to see that autopkgtest is now fixed again
<morphis_> zyga: hey! yeah I saw already that lxd is broken both on Fedora and openSUSE, but good that we have a dedicated bug for that
<zyga> morphis_: I did a quick branch to fix that but we need coordination from ogra and the core snap
<morphis_> mvo: if you have a min, another review on https://github.com/snapcore/snapd/pull/3096 and a merge later today would be great!
<mup> PR snapd#3096: many: abstract path to /bin/{true,false} <Created by morphis> <https://github.com/snapcore/snapd/pull/3096>
<zyga> morphis_: my plan was to essentially stop sharing /etc
<morphis_> zyga: is that easily possible?
<zyga> except for hostname and resolv.conf
<zyga> morphis_: yes
<zyga> aww, brb
<morphis_> we may have a few more dependencies on it don't we?
<morphis_> like /etc/netplan
<morphis_> zyga: and grep'ing through interfaces/builtin shows a lot more
<morphis_> at least 12 which have rw permissions
<morphis_> zyga: https://paste.ubuntu.com/24311669/
<mvo> morphis_: sure, happy to
<morphis_> mvo: thanks
<mvo> morphis_: looks great! thanks for your patience
<morphis_> mvo: np
<zyga> morphis_: re :)
<zyga> morphis_: so that will all work, but we need to tweak one symlink
<morphis_> zyga: you saw the list I've pasted above?
<zyga> morphis_: as if we stop sharing all of /etc one of the writable things has to be adjusted
<zyga> morphis_: no
<morphis_> https://paste.ubuntu.com/24311669/
<zyga> morphis_: sorry, I had to do IRL stuff
<morphis_> IRL?
<zyga> morphis_: in-real-life
<morphis_> ah :-)
<zyga> morphis_: not sure what I'm looking at
<morphis_> zyga: that is a grep through interfaces/builtin for things which refer to /etc
<morphis_> there are quite a few writable things in /etc
<morphis_> if we stop sharing those with the host things will break
<zyga> morphis_: and they work with /writable and symlinks and such AFAIR
<morphis_> zyga: what is with classic?
<zyga> morphis_: the whole point is that it already works in core/all-snap
<morphis_> zyga: ok, then I may don't get yet what you're planing to do
<morphis_> we have symlinks in /etc in the core snap, I get that, but wont those break too if we have the same core snap on multiple distributions as they would point to /writable which doesn't exist there
<morphis_> so if we stop sharing /etc with the host it looks to my like we have to repeat all the writable-paths handling the initramfs on Ubuntu Core currently does for classic
<mvo> morphis_: 3084 has some more suggestions, but I must say I think its looking super nice, the extra bit in there will just make it even more nice :) great work there!
 * mvo hugs zyga for the review too
<morphis_> mvo, zyga: will change that in a bit
<mvo> zyga: 3096 needs a second review, if you have a moment, should be trivial then it can land
 * zyga will review/read stuff in a sec
<zyga> just sending kids to school
<mvo> zyga: thank, no real rush
<zyga> ok :)
<zyga> all gone now
<zyga> morphis_: of coruse writable would exist
<zyga> morphis_: it is in the core snap after all
<zyga> morphis_: and we look at the world _after_ the pivot_root is done
<zyga> morphis_: so it is just a matter of putting the right host data files to /writable
<zyga> morphis_: and setting everything up so that after pivot_root it's all resolving correctly
<zyga> morphis_: writable would have to be a tmpfs
<zyga> morphis_: and would need to be managed by either snapd or by snap-confine
<zyga> mvo: I was already looking at 3096 :-)
<mup> PR snapd#3122 closed: packaging: do not compile spread for autopkgtests <Created by fgimenez> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3122>
<morphis_> zyga: right, and we need to bind mount things there from the real /etc
<morphis_> otherwise snaps wont be able to change timezone/locale/...
<mup> PR snapd#3131 closed: interfaces/mount: add OptsToFlags for converting arguments to syscallâ¦ <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3131>
<zyga> morphis_: interesting
<zyga> morphis_: yes, perhaps
<zyga> mvo: looks like adt will be green now :) https://github.com/snapcore/snapd/pull/3134
<mup> PR snapd#3134: tests: fix incorrect shell expression <Created by zyga> <https://github.com/snapcore/snapd/pull/3134>
<mvo> zyga: yeah, I like the level of greeness
<zyga> once this passes I'll merge it and start merging it into pending brnaches
<zyga> mvo: I'll start with those for 2.24
<zyga> oh, no more 2.24 :)
<zyga> just one test yellow :)
<morphis_> zyga: but lets explore this a bit more, worth a forum topic :-)
<zyga> morphis_: what?
<zyga> all green, merging!
<morphis_> zyga: the unshared /etc on classic
<zyga> morphis_: aha, yes, definitely
<mup> PR snapd#3134 closed: tests: fix incorrect shell expression <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3134>
<zyga> eveyone, let's not land failing tests now
<zyga> everything should be green
<mup> PR snapd#3132 closed: overlord/state: make sure that setting to nil a state key is equivalent to deleting it <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3132>
<zyga> pstolowski: hey
<pstolowski> zyga, o/
<zyga> pstolowski: I just resolved conflicts on https://github.com/snapcore/snapd/pull/3119 and I worry that it is too easy to add a wrong version of AddConnected{Plug,Slot}
<mup> PR snapd#3119: interfaces: API additions for interface hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3119>
<zyga> pstolowski: I'd like to do a sanity test that looks at each interface and makes sure it doesn't implement the old APIs
<zyga> pstolowski: no snippets, no attr-less connected plugs or slots
<zyga> pstolowski: with the definer hack we essentially turned to duck typing on a security component
<zyga> pstolowski: and this is a bit risky :/
<pstolowski> zyga, thanks for resolving conflicts in that branch;
<zyga> fgimenez: conflicts on https://github.com/snapcore/snapd/pull/3105
<mup> PR snapd#3105: tests: download previous snapd package from published versions instead of specific PPA <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3105>
<fgimenez> zyga: thanks on it
<pstolowski> zyga, as for duck typing yes, I realized these risks too. I think from now only every interface needs to have full tests
<pstolowski> zyga, good idea about sanity test, a simple shell script will do
<zyga> pstolowski: I was thinking about a go based test actually, let me try something
<zyga> everyone: I'm going through PRs and merging master into them, this should fix adt failurs
<zyga> *failures
<zyga> please don't merge things if they are not green anymore
<zyga> hmm
<zyga> FAIL: overlord_test.go:360: overlordSuite.TestEnsureLoopPrune
<zyga> this failed on my laptop just now
<zyga> was that known racy?
<zyga> pstolowski: we need to plan a 2nd pass through all PRs to adjust them to the new interface APIs
<zyga> pstolowski: but I'd like to see this new test merged first
<zyga> pstolowski: I'll take a break, prepare for some meetings today and then start working on it
<zyga> pstolowski: if you could do a trivial review on a struct: https://github.com/snapcore/snapd/pull/3129
<mup> PR snapd#3129: interfaces/mount: add InfoEntry type <Created by zyga> <https://github.com/snapcore/snapd/pull/3129>
<zyga> pstolowski: that would help me move update-ns effort forward :)
<mup> PR snapd#3135 opened: interfaces/mount: add high-level Profile functions <Created by zyga> <https://github.com/snapcore/snapd/pull/3135>
<mup> PR snapd#3108 closed: cmd: use libtool for the internal library <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/3108>
<zyga> mvo: I'm done, nearly everyting is either yellow now or has been commented upon to have the author do something
<zyga> mvo: probably we'll run out of machines but spread can be restarted
<zyga> mvo: and adt will nicely queue
 * zyga afk
<mup> PR snapd#2971 closed: data: ship "snap.mount" service that ensures /snap is MS_SHARED <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2971>
<morphis_> zyga: can you have another look on https://github.com/snapcore/snapd/pull/3084 ?
<mup> PR snapd#3084: packaging: use templates for relevant systemd units <Created by morphis> <https://github.com/snapcore/snapd/pull/3084>
<zyga> morphis_: yes, after my calls
<morphis_> thanks!
<zyga> fgimenez:     - autopkgtest:ubuntu-16.04-ppc64el:tests/main/classic-custom-device-reg failed on https://github.com/snapcore/snapd/pull/3129
<mup> PR snapd#3129: interfaces/mount: add InfoEntry type <Created by zyga> <https://github.com/snapcore/snapd/pull/3129>
<zyga> fgimenez: died on kill timeout there
<zyga> mvo: it would be awesome if we had a way to re-try adt tests
<zyga> we're starting to see green tests :)
<zyga> not all but at least some
<zyga> random failures on adt are annoying as they are harder to re-try
<mvo> zyga: yeah, I have no idea how to retrigger those, we need help from the adt people on that. but its worth investigating the failures I think
<zyga> mvo: if it is just slower infrastructure we should tweak knobs to kill them later
<zyga> mvo: if it is real failure we want to investigate
<zyga> mvo: so yeah, agreed!
<zyga> aha, that looks like a real bug
<zyga> [ 1602.570508] audit: type=1400 audit(1491294017.372:1090): apparmor="DENIED" operation="create" profile="snap.classic-gadget.hook.prepare-device" pid=27121 comm="snapctl" family="inet" sock_type="stream" protocol=6 requested_mask="create" denied_mask="create"
<zyga> snapctl + ipv6
<zyga> mvo: did your branch with config that was addressing that landed?
<zyga> s/landed/land/
<zyga> I added https://github.com/snapcore/snapd/pull/3129/commits/f82c78c07facd73f5ad1a31f26b0b337dc6ce4ce to try to figure out what is failing on ppc64
<mup> PR snapd#3129: interfaces/mount: add InfoEntry type <Created by zyga> <https://github.com/snapcore/snapd/pull/3129>
<ogra> zyga, i dont see a PR for the lxd bit
<fgimenez> hi mvo: i'm looking into the expect errors on ubuntu-core http://paste.ubuntu.com/24305344/ and, trying manually tests/main/create-key on amd64 with edge core, it gets stuck after the "Confirm password" prompt http://paste.ubuntu.com/24312255/ if you could take a look when you have a moment that would be great
<morphis_> zyga: so for gnome-software we have a hardcoded /snap/bin in snapd-glib we need to workaround
<morphis_> err, a hardcoded /snap/bin in gnome-software
<zyga> morphis_: aha
<zyga> morphis_: we can do a small patch or we could maybe have it ask snapd
<zyga> morphis_: but I think we can do it easily with a small patch
<zyga> ogra: hmm
<morphis_> zyga: yeah that is the plan
<morphis_> zyga: talked with Robert this morning and he wants to do a minor release of snapd-glib tomorrow anyway so I am asking him now if he can add a small API function returning the snap mount dir
<morphis_> we can than set it statically via a configure switch and later ask snapd
<niemeyer> Good mornings
<mvo> hey niemeyer! good morning
<morphis_> niemeyer: morning!
<niemeyer> o/
<zyga> morphis_: sounds good!
<zyga> niemeyer: good morning :)
<morphis_> zyga: you already had time to give snapd on Fedora a try or is that something for later this week?
<zyga> pstolowski: error: cannot refresh "test-snapd-delta-refresh": cannot get refresh information for snap "test-snapd-delta-refresh": Post https://search.apps.ubuntu.com/api/v1/snaps/metadata: EOF
<zyga> morphis_: I'll try that today, I have my 2nd machine standing by
<zyga> pstolowski: this failed here: https://github.com/snapcore/snapd/pull/3111
<mup> PR snapd#3111: snapd: initial implementation for systemd software watchdog for snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/3111>
<zyga> pstolowski: will that be fixed with https://github.com/snapcore/snapd/pull/3126 ?
<mup> PR snapd#3126: store: handle EOF via url.Error check <Created by stolowski> <https://github.com/snapcore/snapd/pull/3126>
<morphis_> zyga: sounds great! we need 6 points to get the update done, so need to collect people :-)
<zyga> morphis_: I'll boot F25 first
<morphis_> ok
<zyga> fgimenez: tests/main/interfaces-network-observe failed on timeout (seems like test was stuck)
<zyga> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-snappy-dev-image/yakkety/amd64/s/snapd/20170404_092050_bb1cd@/log.gz
<fgimenez> zyga: thanks looking..
<zyga> fgimenez: your new dbus interface spread test seems to be geuinely failing https://github.com/snapcore/snapd/pull/3014
<mup> PR snapd#3014: tests: add dbus interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3014>
<Chipaca> had to reboot because my tests leaked out and borked the environ, and spread realised and restarted qemu without me having to meddle
 * Chipaca hugs niemeyer 
<ogra> koza, next customer ... Bug #1679432 ...
<mup> Bug #1679432: Bluetooth SCO connections don't work on Dragonboard 410c <Snappy:New> <https://launchpad.net/bugs/1679432>
<zyga> Chipaca: good morning :)
<zyga> hmm, I really wish we could retry adt tests
<zyga> error: RPC failed; curl 56 GnuTLS recv error (-110): The TLS connection was non-properly terminated.
 * niemeyer feels the love and hugs Chipaca back
<zyga> random error on git clone
<Chipaca> zyga, niemeyer :-)
<pstolowski> zyga, yes, i hope so..
<fgimenez> zyga: indeed, the test snaps weren't being built for ppc64el, doing that now
<fgimenez> zyga: and thanks! :)
<zyga> pstolowski: let's merge it then!
<zyga> fgimenez: thank you!
<zyga> fgimenez: I think we have a chance at all-green tests today
<zyga> fgimenez: I'll do my best to help
<pstolowski> zyga, i've just pushed the little fix for unneeded var error;
<fgimenez> zyga: \o/ thanks a lot, spring is definitely coming to our poor test results :)
 * zyga reviews 3126
<mup> PR snapcraft#1230 opened: Refactor Cleanbuilder into Containerbuild and add Project <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1230>
<Chipaca> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819/comments/10 is exciting
<mup> Bug #1672819: exec'ing a setuid binary from a threaded program sometimes fails to setuid <amd64> <apport-bug> <kernel-key> <xenial> <linux (Ubuntu):Triaged> <linux (Ubuntu Xenial):In Progress by colin-king> <https://launchpad.net/bugs/1672819>
<Chipaca> which reminds me
<Chipaca> zygaâ do you have a fedora system/vm up?
<brunch875> Guys I noticed that telegram puts downloads in /snap/.../Downloads/ instead of ~/Downloads. I know it's for the sake of confinement, but wouldn't it be a better idea to also mount this folder into ~/Downloads?
<brunch875> that way, the snap doesn't see other snaps downloads but I can go to ~/Downloads to get my stuff
<brunch875>  /snap/Downloads is a long path
<zyga> Chipaca: yes
<Chipaca> zygaâ can you check whether that bug happens in fedora also? (it should, but maybe they patch their kernel for this already)
<Chipaca> brunch875â it's tricky
<Chipaca> brunch875â ~/Downloads isn't guaranteed; in fact, it's localised
<zyga> Chipaca: sure
<Chipaca> brunch875â if you're in spanish I think it's ~/Descargas
<zyga> Chipaca: we have $XDG_CONFIG_DIR/user-dirs.dirs
<brunch875> damn translations... how does firefox deal with this?
<Chipaca> zygaâ exactly, but people editing that is rarer than people speaking something different
<Chipaca> not saying it's impossible; it's tricky
<zyga> Chipaca: yeah
<zyga> Chipaca: just sligthly trickier than fixed path
<zyga> Chipaca: it's tricky if it changes underneath
<ogra> Chipaca, i think we stopped localizing it ... your original install must be old
<Chipaca> it's three indirections to get the thing
<zyga> but that is rare I hope
<zyga> yep
<Chipaca> is it bad that i made tests pass by removing the failing ones :-D
<zyga> Chipaca: I bet there's a bible rerefence that fits this but I don't think we want that ;)
<Chipaca> zygaâ âAnd the beast shall come forth surrounded by a roiling cloud of vengeance. The house of the unbelievers shall be razed and they shall be scorched to the earth. Their tags shall blink until the end of days.â (here "beast" could be "snapd")
<koza> ogra, haha thanks, reading now
<zyga> Chipaca: the church of snapd
<zyga> Chipaca: apply for tax deductions
<Chipaca> in civilization i always name my religion "worms"
<Chipaca> because i spread worms to other civilization and that makes me chuckle
<Chipaca> but "the church of snapd" could work also
<mvo> reviews for https://github.com/snapcore/snapd/pulls?q=is%3Aopen+is%3Apr+milestone%3A2.24 would be great - so that we can get 2.24 ready
<zyga> Chipaca: thu shal not have other packages before me ;-)
<zyga> thu shall refresh on weekends ;)
 * zyga gets back to being useful
<mup> PR snapd#3136 opened: snap-confine: add code o ensure that / or /snap is mounted "shared" <Created by mvo5> <https://github.com/snapcore/snapd/pull/3136>
<niemeyer> mvo: I'm about to jump into it shortly.. just want to get a discourse snap with SSO support building meanwhile
<niemeyer> Chipaca: So it was indeed a bug in the kernel..
<mvo> niemeyer: thank you!
<zyga> Chipaca: fedora booting, sorry, vmware decided it's time for upgrade
<zyga> fgimenez: DEBUG: restarting into "/snap/core/current/usr/bin/snap"
<zyga> fgimenez: this seems to clober and affect tests on https://github.com/snapcore/snapd/pull/3010
<mup> PR snapd#3010: snap: skip /dev/ram from auto-import assertions to make it less noisy <Created by mvo5> <https://github.com/snapcore/snapd/pull/3010>
<zyga> fgimenez: I wonder why it only happens here. it looks like either we reexec where we previously did not
<zyga> fgimenez: or we log where we previously did not
<zyga> fgimenez: I have no other ideas
<zyga> oddly
<zyga> fgimenez: same spread run has this message:
<zyga> 2017/04/04 09:49:49.300407 cmd.go:114: DEBUG: not restarting into "/snap/core/current/usr/bin/snap" ([VERSION=2.23.6 2.23.6]): older than "/usr/bin/snap" (1337.2.23.6)
<zyga> so it restarted once
<zyga> but not another time
<zyga> during one run
<zyga> mvo: does this make any sense to you?
<zyga> it seems that all the failures there are caused by the extra DEBUG message
<zyga> mvo: aha, so that branch sets  +    SNAPD_DEBUG: 1
<zyga> mvo: I think we need something more flexible
<mvo> zyga: indeed - maybe going back to snappy_testing?
<zyga> mvo: I commented on the PR
<zyga> mvo: snappy_testing? what is that
<mvo> zyga: its a flag we set when spread runs, it tells that the system is being tested
<mvo> zyga: let me try that
 * mvo really lunch now
<zyga> Chipaca: ok, updated my f25 to latest kernel and trying the suid bug now
<zyga> fgimenez: I have a question about https://github.com/snapcore/snapd/pull/3085/files
<mup> PR snapd#3085: .travis.yml: remove travis matrix and do a single sequential run <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3085>
<zyga> fgimenez: what happened to the prepare_all_snap vs prepare_classic code?
<zyga> aha I see you excluded core
<zyga> fgimenez: so do we run any tests on core with that PR now?
<fgimenez> zyga: of course, the core system filtering is a refactor only for the unit suite, previously the tasks in that suite were excluding the core systems, with this PR the exclusion is done at the suite level
<zyga> aha, makes sense
<zyga> thanks!
<zyga> let's merge it when it goes green
<fgimenez> zyga: np thank you
<zyga> Chipaca: yep, it also affects fedora
<zyga> Chipaca: but curiously the go version is ok
<zyga> Chipaca: but the c+pthread version is not
<zyga> Chipaca: maybe fedora has different golang build defaults?
<mvo> zyga: https://github.com/snapcore/snapd/pull/3096 has some strange commits, did you maybe push the wrong branc there?
<mup> PR snapd#3096: many: abstract path to /bin/{true,false} <Created by morphis> <https://github.com/snapcore/snapd/pull/3096>
<Chipaca> zygaâ the go version might be ok if you have only one (real) cpu on your vm
<zyga> mvo: checking
<zyga> oh, I must have
<zyga> sorry,
<zyga> shall I push --force to remove them?
<zyga> ah
<zyga> no sorr
<mvo> zyga: sounds reasonable
<zyga> I did this on purpose!
<mvo> zyga: you did?
<zyga> earlier run failed on EOF bug
<zyga> so I merged the EOF fix branch
<mvo> zyga: the eof stuff is random
<zyga> as that is coming to land soon in another PR
<zyga> mvo: yes but I wanted to give it a try to see if it fails on EOF
<mvo> zyga: honestly I think that is not a good idea, its mixing two branch changes and makes the review harder
<zyga> mvo: we can back those out or wait for https://github.com/snapcore/snapd/pull/3126 and merge master again
<mup> PR snapd#3126: store: handle EOF via url.Error check <Created by stolowski> <https://github.com/snapcore/snapd/pull/3126>
<mvo> zyga: yeah, we can deal with this easily, I think we should avoid this in the future, i.e. 3126 was almost in master so a little wait and its all easier to review/land
<zyga> mvo: noted, I'll refrain from doing this
<mvo> ta
<niemeyer> zyga: #3039 again went in with unanswered comments
<niemeyer> zyga: Starting to get worried about the fact we're getting used to overrunning comments
<zyga> niemeyer: aha? checking,
<zyga> niemeyer: are you referring to https://github.com/snapcore/snapd/pull/3039#discussion_r109441348 ?
<mup> PR snapd#3039: many: add support for partially static builds <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3039>
<zyga> niemeyer: I didn't see it, it's another case where github had stale UI :/
<niemeyer> zyga: I'm referring to my comment there made before the merge and unanswered
<zyga> niemeyer: it seems to refresh sometimes but not always
<zyga> niemeyer: right, I'm tring to clarify which comment that was
<zyga> niemeyer: I checked for past comments to make sure it was all addressed
<niemeyer> zyga: I had one comment with Request Changes.. the Approve came together with the comment
<zyga> niemeyer: I think the lesson is to reload a tab before merging
<niemeyer> So either you didn't see the approve, in which case Request Changes was still in place, or you saw the Approve
<niemeyer> and the comment
<zyga> niemeyer: I really didn't see the comment
<zyga> niemeyer: I don't know why exactly or how github works there
<niemeyer> zyga: In either case, let's please be more careful.. we had two such cases in the last couple of days
<niemeyer> zyga: Those were pretty minor, but my concern is obviously that we overrun critical things and nobody notices
<Chipaca> ograâ the 1m you're calling copying also involves sha3'ing the files, which omnoms a cpu for about a minute also
<ogra> ah
<Chipaca> at least afaik :-)
<ogra> yeah, i thought it is related to that step at least
 * Chipaca nods
<ogra> probably not much we can do apart from adding a progress bar :P
<ogra> the key gen change is super impressive though ... it takes almost no time
<mvo> Chipaca: hey, I was wondering if you had a chance to look at the channel2.0 stuff, looks like channels_map_list is now available from the store and I was wondering if I can start doing some of the groudnwork or if you are already on it
<Chipaca> ograâ zyga promised us some assembler work to make it faster :-D
<Chipaca> mvoâ i am not on it
<ogra> heh, good luck with that ...
<Chipaca> mvoâ i don't want to delay completion further
 * ogra waits for the s390x assembler to land 
<Chipaca> ograâ in any case that'd buy us a ~15% perf bump, not more
<mvo> Chipaca: no problem, just wanted to double check to avoid duplicating work
<Chipaca> mvoâ it should be really straightforward to do though
<Chipaca> mvoâ good luck :-D
<Chipaca> (famous last words)
<ogra> Chthats at least 9secs from a 1min run !
<ogra> damn, auto-completion fail
<niemeyer> pstolowski: #3126 reviewed
<ogra> well, in any case we should get  https://github.com/snapcore/snapd/pull/3130 landed asap IMHO
<mup> PR snapd#3130: overlord/devicestate: switch to keygen for device key generation <Created by vosst> <https://github.com/snapcore/snapd/pull/3130>
<ogra> the difference is massive
<pstolowski> niemeyer, ty
<mup> PR snapd#3137 opened: overlord: switch to aliases v2 tasks for install/refresh etc ops plus transition <Created by pedronis> <https://github.com/snapcore/snapd/pull/3137>
<morphis> Son_Goku: we're moving torwards a working gnome-software, just if you didn't follow the conversation in #g-s
 * zyga lunch
<mup> PR snapd#3138 opened: interfaces/mount: add Change.Perform <Created by zyga> <https://github.com/snapcore/snapd/pull/3138>
<zyga> niemeyer: some more progress for your attention https://forum.snapcraft.io/t/fixing-live-propagation-of-mount-changes/23/13
<zyga> niemeyer: I suspect you will be busy with 2.24 tasks today but if you can revise feedback on the oldest PR of that set I could progress significantly
<Chipaca> I love how the whole edifice of tab completion falls down if you have something with a newline in it
<Chipaca> I'm using edifice here in the same sense you'd use it to describe an 8m column of toothpicks stood on end
<zyga> Chipaca: try adding tab completion for a file with a newline in it :)
<Chipaca> zygaâ this is what i meant
<Chipaca> just a space is enough to trip up some of it
<Chipaca> a newline just causes giggling
<niemeyer> pstolowski: Why the else if on 3126?
<niemeyer> zyga: Thanks, I'll check it out soon
<niemeyer> zyga: I started yesterday, actually, but this one needs a fresher mind
<zyga> niemeyer: understandably so, thank you
<pstolowski> niemeyer, because it turns out that after unwrapping the error becomes a net error, so it falls into the check. and goes into return netErr.Timeout() check, which is not what we want
<niemeyer> pstolowski: Seems fishy.. let's discuss in the call
<niemeyer> tvoss: Heya
<tvoss> niemeyer: o/
<niemeyer> tvoss: Can you open a thread in the forum with details of the issue about the ssh-keygen vs. internal generation issue?
<niemeyer> tvoss: Curious about your findings so far about where the problem lies
<tvoss> niemeyer: sure, good part of the findings is on the PR, too
<tvoss> niemeyer: https://github.com/snapcore/snapd/pull/3130
<mup> PR snapd#3130: overlord/devicestate: switch to keygen for device key generation <Created by vosst> <https://github.com/snapcore/snapd/pull/3130>
<niemeyer> tvoss: Thanks
<pstolowski> niemeyer, ok, tweaked retry error check as just discussed
<tvoss> niemeyer: in summary, the current theory is that check for primality in the key generation is killing performance. Mostly due to the BigInt implementation in Go not being as optimized as the ssh one.
<niemeyer> tvoss: Ack, will have a look at the PR
<zyga> mvo: reviewed the snap-confine change, have a look
<zyga> niemeyer: can you have a look at https://github.com/snapcore/snapd/pull/3085/files -- if it lands we will have more travis slots for testing and we will have faster iteration overall
<mup> PR snapd#3085: .travis.yml: remove travis matrix and do a single sequential run <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3085>
<mvo> zyga: yeah, thank you
<niemeyer> zyga: Looking
<mup> PR snapd#3085 closed: .travis.yml: remove travis matrix and do a single sequential run <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3085>
<sborovkov> Hello, Is there some builtin executable to test snapd's REST API?
<sborovkov> on core.
<ogra> sborovkov, snap install http ...
<ogra> then you can talk to it using the http tool
<sborovkov> Meh. I can't install it easily. I need another image then. because my image uses branded store. oh well.
<ogra> sborovkov, well, perhaps Chipaca has a local version of that snap you could install
<Chipaca> sborovkovâ why can't you install it easily?
<pedronis> sborovkov: so it's a branded store not setup to inherit the main one?
<sborovkov> pedronis: yes, It only has 2 snaps
<sborovkov> Chipaca: store I am using is not inheriting anything from the main one.
<Chipaca> nice
<Chipaca> sborovkovâ if you have a snapd running against the regular store somewhere, you can 'snap download http' and then copy the two resulting files over
<sborovkov> Right, I should have classic image lying somewhere around. It's easier to change what store it's using on the fly.
<Chipaca> :-)
<ogra> yeah ... that silly IoT stuff ... way to secure nowadays
<ogra> :)
<Chipaca> sborovkovâ you also should have a way of copying snaps into your store
<Chipaca> i don't know how that side of things work though
<sborovkov> Documentation on REST API says that - "The API documents three levels of access: open, authenticated and root" and " The root user also gains authenticated access without having to send authorization." - Does that apply to snaps that run under root?
<Chipaca> sborovkovâ if you do 'snap download', make sure to copy the .assert as well as the .snap
<sborovkov> Chipaca: understood.
<Chipaca> sborovkovâ no, snaps need the snapd-control to talk to snapd even as root
<Chipaca> otherwise they can't even open the socket
<sborovkov> ah, alright. So if I connect to that interface I won't need to send authentication header? I want to make requests to core/conf to modify config.txt on RPI
<zyga> re
<zyga> yay, thank you for merging that niemeyer :-)
<niemeyer> zyga: No problem, thanks for bringing it up
<niemeyer> fgimenez: Btw, I think we could run the gccgo test on amd64 only
<niemeyer> ubuntu-16.04-64 to be precise
<zyga> I'm seeing hook error reporting failure in spread
<zyga> Apr 04 13:31:57 autopkgtest /usr/lib/snapd/snapd[13737]: hookmgr.go:380: DEBUG: Cannot report hook failure: cannot upload error report, return code: 500
<niemeyer> zyga: Btw, I've created custom badges for distinguished community groups, per Ryan's request
<zyga> I thouht we didn't send those from tests
<zyga> niemeyer: yeah, I saw those
<fgimenez> niemeyer: ok, i'll propose a branch for that
<zyga> niemeyer: when I had a look at badges I saw some UI in account preferences
<niemeyer> zyga: Got morphis and songoku on Fedora.. Ryan on system76.. any other suggestions?
<zyga> niemeyer: specifically https://forum.snapcraft.io/users/zyga/preferences/badge_title
<zyga> niemeyer: but that's not the same, is it?
<morphis> niemeyer: nice one!
<zyga> niemeyer: we may want to tag Canonical CE as such
<niemeyer> zyga: It's related.. specific badges allow using them as titles
<niemeyer> zyga: See how Neil shows up now, for example
<zyga> niemeyer: looking
<niemeyer> or Ryan
<zyga> nice
<zyga> I wish we had icons too
<zyga> (such a forum thing but I like it :)
<niemeyer> Yeah, those badges may have icons associated too
<niemeyer> But, one step at a time :)
<niemeyer> zyga: Who's responsible for the Debian packaging those days?
<niemeyer> and arch, opensuse, etc
<zyga> niemeyer: I think that's mwhudson
<zyga> niemeyer: opensuse that's me and morphis
<zyga> niemeyer: arch that's timothy (not sure if he participates in the forum)
<zyga> niemeyer: (we cannot upload to the arch packge ourselves)
<niemeyer> zyga: Do you plan to remain directly involved in those efforts?
<zyga> niemeyer: yes, I want to say involved, maybe 10%/20%, depending on need
<morphis> niemeyer: worth adding Yocto too
<niemeyer> zyga: Okay, I'll keep morphis as the main point of contact for now then
<zyga> niemeyer: I can help with reviews, some release testing and being a backup so that there are several people involved and aware of what's going on
<zyga> niemeyer: sounds good
<zyga> niemeyer: yocto yes, morphis updated snapd in yocto AFAIR
<morphis> zyga: I maintain it :-)
<niemeyer> morphis: Who's handling Yocto, only you for now?
<zyga> niemeyer: do you think we should have "snapd developer" badge?
<morphis> niemeyer: yes
<zyga> niemeyer: can we do many badgets for one person?
<niemeyer> zyga: Well, looks at your own badges :)
<niemeyer> s/looks/look
 * zyga looks
<zyga> oh
<niemeyer> zyga: Not sure, let's think about that one (developer)
<zyga> forum does feel like a massive upgrade over mailing lists
<zyga> brick by brick it builds a community
<niemeyer> zyga: Feels a bit too generic to be useful.. everyone should feel like they are developers.. PRs for all
<zyga> indeed
<zyga> we can revisit that once the forum has 100s of users
<niemeyer> Yeah
<zyga> pedronis: can we merge master into https://github.com/snapcore/snapd/pull/3087
<mup> PR snapd#3087: overlord/snapstate: introduce tasks for aliases v2 semantics with temporary names for now (aliases v2) <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3087>
<pedronis> zyga: I did
<zyga> pedronis: thanks!
<pedronis> zyga: did something else got merge to master recently that fixes something?
<niemeyer> https://usercontent.irccloud-cdn.com/file/OldF6S1B/
<zyga> pedronis: one thing that was breaking many adt runs and one simplification from federico that will make test runs faster
<niemeyer> Did I miss anything?
<zyga> niemeyer: gentoo, but we don't actively maintain it really
<zyga> niemeyer: I would also consider centos
<niemeyer> Okay.. let's create it on demand then
<zyga> niemeyer: as many people love it
<zyga> niemeyer: and it feels distinct from fedora
<niemeyer> Hmm.. what's the packaging story there?
<zyga> niemeyer: once the fedora package is out we will request a package for centos
<zyga> niemeyer: I was wondering if we want to have 'Ubuntu & Derivatives' instead of Ubuntu
<niemeyer> zyga: What does that mean?
<zyga> niemeyer: (elementary, mint and multitude of [KLX...]buntu)
<niemeyer> zyga: I mean, requesting a package for CentOS.. what does that mean in practice?
<zyga> niemeyer: it means that you get a permission to target your package to "enterprise" distros
<zyga> niemeyer: it's distinct from fedora
<zyga> niemeyer: you go through the review process again
<zyga> niemeyer: different people decide, etc
<niemeyer> Is it the same package, though?
<zyga> niemeyer: then you get a branch that you can use for that distribution
<zyga> niemeyer: not quite, it's the same package _name_ but it can be different _packaging_
<zyga> niemeyer: it typically is somewhat different in the end
<zyga> niemeyer: for snapd we will reuse the same package but build it with different switches
<zyga> niemeyer: as centos doens't have golang much so what happens is you built it with fedora deps that are bundled / linked statically
<zyga> niemeyer: that's what I understand from the process
<morphis> niemeyer: it can be the same .spec file but build with different parameters
<zyga> niemeyer: yes
<zyga> niemeyer: it's actually automatic as our package has those switches onw
<zyga> now*
<morphis> niemeyer: King_InuYasha build the .spec file in a way that it can work on RedHat, CentOS and Fedora
<zyga> niemeyer: we mainly need to apply for the permission and come up with a working srpm for review
<niemeyer> Okay, sounds good.. badge created
<niemeyer> We're only handing it off when it lands though!  :P
<zyga> niemeyer: exactly, this is why the spec files for golang are so convoluted
<zyga> niemeyer: sounds good :)
<zyga> niemeyer: question: what do you use for those tiny screenshots?
<niemeyer> zyga: Which tiny screenshots?
<zyga> niemeyer: like the one you linked to above
<niemeyer> zyga: Ah, you mean the screen cropped ones?
<zyga> yes
<niemeyer> zyga: Stock gnome-screenshot with proper keyboard shortcuts
<mup> PR snapd#3139 opened: tests: run gccgo only on ubuntu-16.04-64 <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3139>
<zyga> Chipaca: does this test failure ring a bell to you? https://github.com/snapcore/snapd/pull/2982#issuecomment-291524618
<mup> PR snapd#2982: daemon: add desktop file location for app to the API <Created by mvo5> <https://github.com/snapcore/snapd/pull/2982>
<zyga> Chipaca: it's odd that it failed on some places and passed in others
<Chipaca> gocheck's output for diffing maps sucks :-(
<Chipaca> but no
<zyga> yep
<zyga> Chipaca: thanks!
 * zyga looks at TestEnsureLoopPrune
<mup> PR snapd#2982 closed: daemon: add desktop file location for app to the API <Created by mvo5> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2982>
<mup> PR snapd#3140 opened: overlord: increase prune test wait by x10 <Created by zyga> <https://github.com/snapcore/snapd/pull/3140>
<Chipaca> zygaâ so, apps is different
<Chipaca> zygaâ missing desktopfile stuff
<Chipaca> ?
<Chipaca> ah!
<Chipaca> no
<Chipaca> zygaâ something is wrong in that test or something
<Chipaca> there is no order to apps and the test is checking an ordered struct
<zyga> Chipaca: aah
<zyga> Chipaca: thanks, I'll look at fixing that
<zyga> fgimenez: commented on https://github.com/snapcore/snapd/pull/3139#pullrequestreview-30806386
<mup> PR snapd#3139: tests: run gccgo only on ubuntu-16.04-64 <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3139>
<Chipaca> zygaâ it should probably be a map[string]daemon.appJSON instead of a []daemon.appJSON
 * ogra laughs about the forum
<mup> PR snapcraft#1211 closed: sources: add git source tracking <Created by josepht> <Closed by josepht> <https://github.com/snapcore/snapcraft/pull/1211>
<ogra> "You earned an Ubuntu"
<mup> PR snapcraft#1213 closed: sources: add bazaar source tracking <Created by josepht> <Closed by josepht> <https://github.com/snapcore/snapcraft/pull/1213>
<ogra> yay
<zyga> ogra: it's yours to keep :)
 * ogra hugs his Ubuntu
<ogra> my precious!
<daker> lol
<daker> zyga: can we have other providers for the login ? i don't want to create another account for it
<zyga> daker: https://forum.snapcraft.io/t/support-for-sso-on-forum-snapcraft-io/75
<daker> zyga: thanks
<mup> PR snapd#2982 opened: daemon: add desktop file location for app to the API <Created by mvo5> <https://github.com/snapcore/snapd/pull/2982>
<zyga> Chipaca: about map[string]daemon.appJSON, should the key be just the app name?
<Chipaca> zygaâ yah
<zyga> Chipaca: the problem is that this is client-visible protocol, right?
<zyga> Chipaca: alternatively I can sort by that
<zyga> Chipaca: so that it shows up in good order
<Chipaca> yeah
<zyga> Chipaca: but I also recall the need to have a "launch" button that may imply order cannot be alphabetic
<Chipaca> sorting works
<zyga> Chipaca: and needs to be something special :/
<Chipaca> the launch is per desktop
<Chipaca> Â¯\_(ã)_/Â¯
<zyga> Chipaca: yes but in gnome software you have one buttn
<zyga> button
<Chipaca> zygaâ imagine :shrug:, but where each stroke is a Â¯\_(ã)_/Â¯
<Chipaca> heh
<Chipaca> hexchat fail
<zyga> Chipaca: something like this http://paste.ubuntu.com/24313896/
<zyga> Chipaca: if you +1 I will push that into mvo's PR
<sborovkov> Hello again. Am I doing something wrong here? Trying to get conf details for core snap. r = session.get('http+unix://%2Frun%2Fsnapd.socket/v2/core/conf') - this returns me 404. I was doing it according to this https://github.com/snapcore/snapd/wiki/REST-API#get-v2snapsnameconf
<ogra> sborovkov, if there are no config options set (the default) you probably wont get any back
<Chipaca> sborovkovâ is your url correct? e.g. does /v2/system-info work?
<ogra> sborovkov, try something like: "snap set core system.powerkey-action=poweroff" (thats a harmless one) and see if you then get something else than 404
<zyga> Chipaca: pushed, please comment on the PR
<Chipaca> zygaâ sorry got delayed
<Chipaca> zygaâ recommend leave the code as it was, and then use sort.Slice directly
<mup> Bug #1679739 opened: System-User Assertions and the system time <Snappy:New> <https://launchpad.net/bugs/1679739>
<Chipaca> zygaâ saying as much on the pr
<Chipaca> there
<zyga> Chipaca: aha, looking
<mbruzek> Setup snap "core" (1441) security profiles (cannot setup apparmor for snap "core": cannot load apparmor profile "snap.core.hook.configure": cannot load apparmor profile: exit status 243
<mbruzek> apparmor_parser: Unable to replace "snap.core.hook.configure".  Permission denied; attempted to load a profile while confined?
<zyga> Chipaca: odd, I don't have sort.Slice
<zyga> Chipaca: is that a 1.7 thing?
<Chipaca> ah
<Chipaca> if it is, then ignore me
<Chipaca> zygaâ quite possibly
<pedronis> living in the future (well past)Â ?
<zyga> Chipaca: I wish go docs had a @since thing
<Chipaca> yeah
<zyga> :/
<Chipaca> me too
<zyga> ok
<sborovkov> Chipaca: /v2/system-info works '{"type":"sync","status-code":200,"status":"OK","result":{"kernel-version":"4.4.0-1048-raspi2","managed":true,"on-classic":false,"os-release":{"id":"ubuntu-core","version-id":"16"},"series":"16","version":"2.23.6+201704032253.git.e2ab58d~ubuntu16.04.1"}}'
<sborovkov> ogra: command you have me works as well.
<fgimenez> zyga: the test snaps are already in place since this morning for the dbus interface branch, could you please retrigger the tests? (i don't have the right permissions sorry)
<mbruzek> Has anyone had problems with apparmor profiles while running snaps in lxd?
<ogra> sborovkov, well, does it stop returning 404 after you used that  ?
<tyhicks> mbruzek: what ubuntu release for the host and container?
<Chipaca> sborovkovâ and /v2/snaps/core/conf ?
<mbruzek> xenial and xenial
<Chipaca> sborovkovâ you might be missing the /snaps/ in there
<mbruzek> tyhicks: snap version 2.22.6
<sborovkov> Chipaca: oh you are right, my bad :-( How did I not notice that. So it's not gonna return the full list of settings anyway? Because with corrected url I get '{"type":"error","status-code":400,"status":"Bad Request","result":{"message":"invalid option name: \\"\\""}}'
<mbruzek> tyhicks: actually the host is yakkety
<zyga> fgimenez: I don't have permissions for adt, I can merge master and push though
<fgimenez> zyga: np, i'll do it
<Chipaca> sborovkovâ I don't know enough about config to answer that
<tyhicks> mbruzek: and the container OS?
<mbruzek> Ubuntu
<tyhicks> oh
<tyhicks> you didn't higlight me in you orig answer
<tyhicks> mbruzek: is the container unprivileged?
<mbruzek> tyhicks: so xenial, and yakkety
<mbruzek> tyhicks: it is a privileged container
<tyhicks> mbruzek: that's a problem - that means that /sys/kernel/security/apparmor doesn't exist inside your container, does it?
<tyhicks> mbruzek: well, you'll probably see "permission denied" even as root when trying to look at that directory
<mbruzek> when I sudo su - I can see the profiles file.
<ogra> sborovkov, try querying for "system" after you set the powerkey-action key it should contain something ... what you are running is teh equivalent of: snap get core " " ... that returns the "invalid-option" while: "snap get core system" will return the json for the system category
<tyhicks> mbruzek: your inside the container?
<mbruzek> tyhicks: oh that was on host
<tyhicks> mbruzek: right - the problem is that you don't have access to apparmorfs inside of the privileged container so snapd can't load profiles
<mbruzek> tyhicks: Nope I can see in that folder and the files in it when inside the container
<sborovkov> ogra: Trying.  r = session.get('http+unix://%2Frun%2Fsnapd.socket/v2/snaps/core/conf', data={'keys': 'system'}) -> '{"type":"error","status-code":400,"status":"Bad Request","result":{"message":"invalid option name: \\"\\""}}'
<sborovkov> snap get core system does return proper values though
<zyga> fgimenez: thank you!
<zyga> tyhicks: hello :)
<ogra> ogra@localhost:~$ snap get core system
<ogra> {
<ogra> 	"powerkey-action": "poweroff"
<ogra> }
<tyhicks> mbruzek: inside the container, run `"echo profile ctest {}" | sudo apparmor_parser -qr`
<ogra> sborovkov, it does for me
<tyhicks> hey zyga!
<ogra> sborovkov, oops, sorry, i read "doesn't"
<zyga> morphis: I'll EOD and focus on giving F25 workstation and server a quick test
<sborovkov> ogra: Yup that works. But not when I am doing request myself. Not sure what's the difference. I see that I am supposed to pass keys to it which I do
<ogra> perhaps try the full key name ... "system.powerkey-action"
<mbruzek> tyhicks: # `"echo profile ctest {}" | sudo apparmor_parser -qr`
<mbruzek> echo profile ctest {}: command not found
<sborovkov> ogra: Same error :-( It does not like "keys" it seems.
<mbruzek> tyhicks: same error if I run as "ubuntu" inside the contaienr
<ogra> hmm
 * zyga waves o/
<tyhicks> mbruzek: I goofed up the quotes
<sborovkov> ogra: Ok I figured it out, mistake in my code
<ogra> ah, cool
<tyhicks> mbruzek: `echo "profile ctest {}" | sudo apparmor_parser -qr`
<Chipaca> sborovkovâ does 'data' work with a dictionary like that?
 * ogra never used the REST api for config ... always only snap set/get
<Chipaca> sborovkovâ what's the request you're doing, once you're past your library?
<mbruzek> tyhicks: apparmor_parser: Unable to replace "ctest".  Permission denied; attempted to load a profile while confined?
<mup> Bug #1679747 opened: Cannot send bluetooth SCO packets with Raspberry Pi 3 internal bluetooth module. <Snappy:New> <https://launchpad.net/bugs/1679747>
<sborovkov> Chipaca: Yeah, I replaced data with params and it works. I rarely use REST API so hence that mistake.
<Chipaca> sborovkovâ out of curiosity, why are you using the api directly?
<tyhicks> mbruzek: in the host, look in /var/log/syslog for any lines containing apparmor="DENIED" and /sys/kernel/security/apparmor/.replace
<morphis> zyga: nice!
<morphis> zyga: don't forget to comment in bodhi!
<sborovkov> Chipaca: well we distribute our software with users not having access to the system. So for some cases (for some TVs) they might need to change config.txt values from webinterface to get it to work. So I need an ability to modify it programmatically from our snap
<mbruzek> tyhicks: Yep I see it
<mbruzek> tyhicks: Apr  4 08:48:58 pandora kernel: [ 1782.858544] audit: type=1400 audit(1491313738.389:146): apparmor="DENIED" operation="file_mmap" namespace="root//lxd-juju-70fced-0_<var-lib-lxd>" profile="/usr/lib/lxd/lxd
<mbruzek> -bridge-proxy" name="/usr/lib/lxd/lxd-bridge-proxy" pid=17468 comm="lxd-bridge-prox" requested_mask="m" denied_mask="m" fsuid=165536 ouid=165536
<Chipaca> sborovkovâ and your snap is python already so you prefer to talk to the rest api directly?
<tyhicks> mbruzek: that's not the one I'm looking for since it doesn't mention the ".replace" file
<sborovkov> Chipaca: yes
<Chipaca> fair
<zyga> morphis: will do :)
<morphis> zyga: we need to talk in the next days a bit more about your research in the past about the policy for golang packages in openSUSE
<zyga> morphis: sounds good
<mbruzek> tyhicks: The DENIED ones do not contain replace, the STATUS ones do. http://pastebin.ubuntu.com/24314095/
<tyhicks> mbruzek: ok, I'll need a little bit to look through lxd's code and/or poke at this myself
<mbruzek> would you like me to create a bug?
<tyhicks> mbruzek: this is an intentional decision by lxd to not allow apparmor profile loads inside of privileged containers: https://github.com/lxc/lxd/blob/master/lxd/apparmor.go#L321
<tyhicks> mbruzek: we're not seeing a denial message in the syslog because the rule on line 326 denies without auditing those filesystem accesses
<tyhicks> mbruzek: you should use an unpriv container if you need to run snaps inside the container today
<mbruzek> tyhicks: I thought priviledge containers should be able to do everything? why can they not load apparmor profiles?
<tyhicks> mbruzek: no, they cannot do everything
<mbruzek> OK
<tyhicks> mbruzek: they're still confined and there attempts made at trying to keep them from affecting the system
<tyhicks> s/there attempts/there are attempts/
<tyhicks> mbruzek: you could file a bug against lxd and subscribe the security team so that we can discuss if it is safe to enable profile loads inside of a privileged container using apparmor namespaces
<tyhicks> mbruzek: I don't know the answer to that off the top of my head and we'd need broader discussion
<mbruzek> will do after my meeting.
<tyhicks> ok
<mup> PR snapd#3141 opened: many: show available "tracks" in `snap info` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3141>
<pedronis> mvo: this test seems to fail often, at least under autopkgtest: autopkgtest:ubuntu-16.10-amd64:tests/main/refresh-core-with-hanging-configure-hook
<mdye> I have snapd 2.23.6 and a snap installed in devmode and tracking from the beta channel. "snap info" shows a new version (2.0.1 vs. my current 2.0.0) in that channel, but "snap refresh" doesn't update my running instance. Is that intended or a bug?
<ogra> you need to pass --devmode to the refresh command too if you installed with --devmode
<ogra> (security feature)
<mdye> ogra: thx; automatic updates and rollbacks are handled by snapd as of something like 2.22 instead of the systemd timer, right? is there a way today to enable automatic updates and rollbacks of snaps installed with devmode?
<pmcgowan> mdye, not currently, there is an open bug on it
<mdye> thx. do you have a URL to the bug? I'd like to track it
<pmcgowan> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1665102
<mup> Bug #1665102: Snap refresh not working as expected on devmode snaps <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1665102>
<mdye> thx :)
<pmcgowan> yep
<mup> Bug #1676928 opened: snap shell can't reach $SNAP_USER_DATA: Permission denied <cdo-qa> <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1676928>
<Chipaca> why, oh *why*, does setting IFS to \n make compgen not print newlines?
<jrwren> in bash, IFS is internal field separator. its not awk where it is input field separator with corresponding output field separator
<mup> PR snapcraft#1214 closed: sources: add subversion source tracking <Created by josepht> <Closed by josepht> <https://github.com/snapcore/snapcraft/pull/1214>
<Chipaca> jrwrenâ so why does setting it to \n make the output of compgen not include it?
<Chipaca> I'd be unsurprised if compgen used ${IFS[0]} to separate its output
<Chipaca> but ... this is the opposite
<jrwren> Chipaca: sorry, not sure, just trying to help with pointers, hopefully not bad pointers.
<Chipaca> :-D
<mup> PR snapcraft#1215 closed: sources: add mercurial source tracking <Created by josepht> <Closed by josepht> <https://github.com/snapcore/snapcraft/pull/1215>
<chani_> hi guys i got a doubt
<Chipaca> chani_â shoot
<chani_> i am trying to include a debian package in my snap using stage-packages
<chani_> and when i try to run that package from a coustom script via deamon
<chani_> its not working as the deb executable script has hard links to other files like /usr/bin/...
<chani_> which it can't find as they are included in /snap/my-snap/usr/bin....
<chani_> so what can i do here
<chani_> should i use docker instead as where i have a complete virtualization
<chani_> or is there some way i can use virtualization in my snaps
<niemeyer> Okay, I'm going to take a break now..
<niemeyer> Sorry, didn't manage to get to 2.24 yet.. will try to do some work there today still
<niemeyer> chani_: Can you please ask a question under the snapcraft category in the forum, if that's not asking too much?  I'll back back later and  would like to hear/collaborate on the conversation
<niemeyer> chani_: There are a few tricks you can use to make that work, and I have some ideas to improve on that exact area
 * niemeyer back later
<chani_> can you give me the link as to where to post the question
<chani_> and also if there is any document reference for the tricks you mentioned
<pedronis> chani_: https://forum.snapcraft.io/
<chani_> got it i am posting it right there now
<mup> PR snapcraft#1224 closed: tests: update name registration window limit test <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1224>
<mdye> is there a way to prevent snapd from doing updates ? (to lock a version indefinitely or delay updates for a time?)
<chani_> niemeyer: hai i had posted my question in the form here is the link https://forum.snapcraft.io/t/how-to-ship-deb-packages-along-with-snaps/149
<mup> PR snapcraft#1231 opened: pluginhandler: exclude `/snap/` from libraries <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1231>
<mup> PR snapcraft#1228 closed: nodejs plugin: switch to the newer LTS <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1228>
#snappy 2017-04-05
<mup> PR snapcraft#1231 closed: pluginhandler: exclude `/snap/` from libraries <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1231>
<mup> PR snapcraft#1232 opened: nodejs plugin: switch to the newer LTS. (#1228) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1232>
<mup> PR snapcraft#1233 opened: docs: update contribution guide <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1233>
<Haxxa> Should I be using snap? Is it like docker or lxc?
<mup> PR snapcraft#1234 opened: core: find the correct libraries as a snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1234>
<mup> PR snapd#3142 opened: daemon: Give the snap directories via GET /v2/system-info <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/3142>
<mup> PR snapcraft#1232 closed: nodejs plugin: switch to the newer LTS. (#1228) <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1232>
<_28Kb> can I list core interfaces and stuff to mess with im my ubuntu core 16?
<_28Kb> I want to do some code and make my own snaps... how do I find those "system variables" that I want to call and controll?
<_28Kb> to tell my core: do that and then that..
<_28Kb> and snacraft is not actually a snap?
<_28Kb> snapcraft*
<_28Kb> snap help
<niemeyer> Forum going down for an update... please assume crash landing position.
<niemeyer> We've landed successfully. Please calmly return to your cell phones.
<morphis> robert_ancell: ping
<robert_ancell> morphis, hi
<morphis> robert_ancell: thanks for doing those changes!
<robert_ancell> np
<morphis> robert_ancell: just commented on the bug
<robert_ancell> morphis, weird, is that the query you were doing from inside g-s?
<morphis> robert_ancell: but why do we have extra code in gnome-software to query snapd?
<morphis> robert_ancell: yes
<morphis> let me give this another try
<robert_ancell> morphis, it existed before snapd-glib existed and I haven't switched all the functions over yet (there seems to be a weird interaction with the g-s threading model I haven't solved)
<morphis> ah ok
<robert_ancell> morphis, so weird your g-s did a short read. Your response is the same length as mine.
<robert_ancell> I'll have another look tomorrow
<morphis> robert_ancell: tried it again now in my 17.04 VM and now it works with gnome-software
<morphis> robert_ancell: I now removed rocket-chat and installed through gnome-software again and get the truncated message again
<robert_ancell> morphis, this is 17.04 with standard snapd?
<morphis> with 2.23.6
<morphis> robert_ancell: but I can debug through this a bit over my day
<robert_ancell> morphis, cool
<robert_ancell> gtg, bye all!
<morphis> robert_ancell: bye!
<zyga> good morning
<zyga> mvo: hello
<mvo> hey zyga - good morning
<zyga> mvo: I just re-triggered tests on https://github.com/snapcore/snapd/pull/3126 (they failed on github connectivity before), once those land I will do another pass at merging master into open branches
<mup> PR snapd#3126: store: handle EOF via url.Error check <Created by stolowski> <https://github.com/snapcore/snapd/pull/3126>
<zyga> mvo: yesterday's exercise was worthwhile as most open PRs got green
<zyga> mvo: still, I have a question about one particular problem:
<zyga> mvo: https://github.com/snapcore/snapd/pull/3140
<mup> PR snapd#3140: overlord: increase prune test wait by x10 <Created by zyga> <https://github.com/snapcore/snapd/pull/3140>
<zyga> mvo: I attempted a naive "fix" for this racy test
<zyga> mvo: but was surprised when it just failed again after making it wait x10 longer
<zyga> mvo: do you think it is worth mocking time all the way so that it is reliable?
<zyga> mvo: or finding another approach at making it fail less
<zyga> mvo: (it consistently fails in many PRs)
<mvo> zyga: I have a look, I'm not really sure what the best course of action is
<mvo> zyga: but I did notice that its one of the culprits for a lot of the failures too
<zyga> mvo: maybe it could run in a loop
<zyga> mvo: and any out of N tries could succeed
<zyga> mvo: what surprised me is that making the timer longer has caused the test to fail everywhere in that particular run
<zyga> mvo: did I misunderstand something about it? I would assume the opposite behavior
<mvo> zyga: I need to look at the test, but we have one test that checks that purge happens only after a specific time, i.e. wait a little bit: change still there, wait a bit more: change gone - maybe it was this test, I need to look at it though to be sure
<zyga> mvo: thanks, let me know when you chceked that
<mvo> zyga: right after I finished my open review tabs :)
<zyga> mvo: did you see this failure:
<zyga> Apr 04 13:31:57 autopkgtest /usr/lib/snapd/snapd[13737]: hookmgr.go:380: DEBUG: Cannot report hook failure: cannot upload error report, return code: 500
<zyga> mvo: should we try to upload error reports in spread runs?
<mvo> zyga: we should not, there is code that prevents this (i.e. checks if its run under spread). but we had a bug there before (some test nuked the snapd systemd config). maybe we have it again :/
<zyga> mvo: it seems so
<zyga> mvo: but when you wrote that test, would it just fake the upload but say it did upload anyway
<zyga> mvo: or would it skip the upload and the message entirely?
<zyga> mvo: I prepared a tiny patch for this but I'm not sure if it should be sent:
<zyga> http://paste.ubuntu.com/24318730/
<mvo> zyga: thanks, checking
<mvo> zyga: aha, I think I found the issue, the wrong spot is checking for the snappy_testing :/ let me fix that
<mvo> zyga: thanks for discovering!
<zyga> mvo: perfect, thanks!
<zyga> mvo: what's curious is that it fails infrequently
<zyga> mvo: so we either submit most error reports successfuly
<zyga> mvo: or something else is wrong
<mvo> zyga: the normal snap install failures are all skipped, just the new hook failure stuff is not doing that :/ so its only very few tests plus daisy is usually reliable
<zyga> mvo: so will the test stay as-is and we just print the message that the report got sent but not really send anything?
<tvoss> mvo: after a quick chat with tyhicks yesterday, he would appreciate your feedback/commitment on https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1660550. Once we have that, we can continue the MIR process
<mup> Bug #1660550: [MIR] snapd in trusty <snapd (Ubuntu):Incomplete by ubuntu-security> <https://launchpad.net/bugs/1660550>
<mvo> tvoss: sure, checking
<tvoss> mvo: thx
<mvo> updated
<morphis> zyga, mvo: I've seen https://paste.ubuntu.com/24318373/ this morning when I tried to use snapd on a Ubuntu 16.04.2 live cd
<tvoss> mvo: ack
<morphis> zyga, mvo: after doing an apt upgrade though
<zyga> morphis: looking
<zyga> morphis: interesting
<zyga> morphis: not sure if related but live CD has things that make snapd not work
<zyga> morphis: not sure if it is overlayfs or aufs or something like that
<zyga> morphis: did you get any apparmor denials for snap-confine?
<zyga> morphis: if you did that would probably explain it
<morphis> zyga: didn't checked that but after loading the apparmor profile for snap-confine I got the the libudev error
<zyga> morphis: do you still have that environment around?
<zyga> morphis: dmesg | grep DENIED
<morphis> zyga: its easy to recreate
<zyga> mvo: I'ld like to land https://github.com/snapcore/snapd/pull/3084
<mup> PR snapd#3084: packaging: use templates for relevant systemd units <Created by morphis> <https://github.com/snapcore/snapd/pull/3084>
<morphis> but no, don't have it anymore
<zyga> mvo: has 2 +1s
<zyga> morphis: ok
<zyga> morphis: I'll try it out today
<mvo> zyga: yeah, I was wondering about the foreach()
<mvo> zyga: otherwise it looks really great
<morphis> zyga: thanks
<mvo> zyga: but its not a blocker
<zyga> mvo: looking at foreach
<morphis> zyga, mvo: just tell me what you guys prefer, happy to change it again :-)
<zyga> aha
<morphis> zyga, mvo: need go for errands now but can change once I am back or do a followup PR
<zyga> morphis: I think mvo means that the foreach is OK but the particular install command is different
<zyga> ah
<zyga> it even means we don't need foreach
<zyga> yeah, less magic is fine with me ;)
<zyga> morphis: if you can quickly push that change I'd love to merge it
<mvo> zyga, morphis: lets just merge it and we do a followup, poor morphis had to do enough in this already :) but I'm super happy about the structure now, I think it looks really nice
<zyga> mvo: +1
<jibel> mvo, morning
<mvo> hey jibel! good morning
<jibel> mvo, will you reupload a version of 2.23.6 with the fix for bug 1679616 ? or what is the plan there
<mup> Bug #1679616: ADT failure in snapd 2.23.6+17.04 <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1679616>
<jibel> mvo, because currently 2.23.6 is blocked in proposed and it'll block the srus too
<mvo> jibel: this error should be fixed with the new spread, i.e. we just need to retrigger the adt runs, it should be fine without a new upload
<mvo> jibel: hm, not sure how to do that for zesty, let me explore
<jibel> mvo, ah good, can you re-run it please http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd I'm cannot
<mvo> jibel: sure, let me do that
 * zyga packs and goes to the library
<zyga> see you soon
<mvo> jibel: done for 17.04
<mvo> zyga: enjoy
<jibel> mvo, thanks!
<zyga> mvo: can you do a sanity check and merge https://github.com/snapcore/snapd/pull/3126 ; I think it's okay but I want to be on the safe side :)
<mup> PR snapd#3126: store: handle EOF via url.Error check <Created by stolowski> <https://github.com/snapcore/snapd/pull/3126>
<Chipaca> mvoâ o/
<Chipaca> mvoâ about #3141
<Chipaca> mvoâ I think I'd rather have the current channels be foo/bar instead of having a nested structure
<Chipaca> mvoâ however I suspect ordering is going to be an issue with either approach
<Chipaca> we can probably ignore ordering for a first pass though
<Chipaca> hmm
<mvo> Chipaca: ok, I agree
<mvo> Chipaca: I will rework :)
<Chipaca> mvoâ hold on
<mvo> Chipaca: sure
<Chipaca> mvoâ the fact that not all snaps have a channel_maps_list is a blocker in my mind
<Chipaca> mvoâ what're you going to do for snaps that don't?
<mvo> Chipaca: just use the fakeChannels as before
<mvo> that was my thinking
<Chipaca> :-(
<mvo> and ensure that the store is aware of this cludge
<mvo> kludge
<mvo> Chipaca: but either way is fine, I can hold back too. but it seems the workaround is relatively cheap and I would love to land basic support soon(ish) (but maybe thats not wise, I'm just a bit impatient sometimes)
<Chipaca> mvoâ just cc'ed you on an email asking about that
<Chipaca> mvoâ the problem with sending a big fat list is twofold
<mvo> Chipaca: thank you!
<mup> PR snapd#3139 closed: tests: run gccgo only on ubuntu-16.04-64 <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3139>
<Chipaca> mvoâ one, it makes printing it nicely grouped by track harder
<Chipaca> mvoâ two, it makes sorting an issue
<Chipaca> mvoâ so, i propose this: keep on having "channels", using foo/bar, but *also* have a *list* of track names
<Chipaca> tadaaa
<mup> PR snapd#3084 closed: packaging: use templates for relevant systemd units <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3084>
<Chipaca> mvoâ finally, at least for a little bit, keep having the latest/foo appearing as foo in the channel map (either exclusively, or duplicated, i don't know)
<mvo> Chipaca: *nod*
<Chipaca> mvoâ my assumption here is that the server knows what it's doing wrt ordering (note the channel map list is a list after all), and follow that order
 * mvo nods
<mvo> Chipaca: thanks, I think this makes sense
<Chipaca> mvoâ also it's the cheapest approach :-)
<mvo> Chipaca: ha! that I also like
<mup> PR snapd#3143 opened: data/systemd: tweak data/systemd/Makefile to be slightly simpler <Created by mvo5> <https://github.com/snapcore/snapd/pull/3143>
<mup> PR snapd#3126 closed: store: handle EOF via url.Error check <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3126>
<pstolowski> thank you!
<JamieBennett> fgimenez: I want to push out 2.23.6 in the ubuntu-core snap today, can you do a validation of the beta channel please?
<mvo> Chipaca: I updated the forum post to include what we just discussed, thanks again for your input
<mvo> pstolowski: thank *you* - really nice work on that branch
<Chipaca> mvoâ I've adjusted to being back on IRC just fine, but not so much to the forum
 * Chipaca looks
<pstolowski> mvo, yw. i hope it helps
<mvo> Chipaca: no worries - fwiw, I made the forum entry a wiki so you can also edit it if you want/need
<fgimenez> JamieBennett: sure on it
<Chipaca> mvoâ tweaked it because that's how i roll, but it seems fine
<fgimenez> JamieBennett: we have rev 1940 of ubuntu-core in the beta channel, is that the version to be validated?
<renat> Hi, guys=)
<renat> It's Renat, from Screenly=)
<morphis> Son_Goku: ping
<renat> I have a question related to the network_setup_control interface. Do I need any additional interface/permission to run the netplan to generate the config after I update netplan config files?
<mvo> Chipaca: what can I say
<mvo> Chipaca: thank you!
<JamieBennett> fgimenez: just checking now
<Chipaca> mvoâ you're welcome. Also, check your PMs :-)
<JamieBennett> fgimenez: yes, r1940
<JamieBennett> Hey renat, I personally have no idea, maybe mvo knows more about this?
<Chipaca> renat!
<Chipaca> renatâ did you get the image working? i'm left waiting for it to debug at my end
<renat> Chipaca, I think - I missed something. The issue with a snapd and gadget snaps installed from the store is not resolved (or, I don't know about it=)) Even signing the model with the store owner's key didn't help=(
<fgimenez> JamieBennett: thanks will let you know how it goes
<Chipaca> renatâ ack. When yo get around to it, if you send a link to the image our way we'll take a look (ogra and myself)
<mvo> renat: you should be able to do read/write of netplan config when you have network_setup_control.
<mvo> renat: did you try it and it did nt work? if so, what kind of denial did oyu get?
<mvo> renat: you may need the extra network-control iface to actually apply the config though
<renat> mvo, I didn't try, honestly. Just checked the interface file (network_setup_control.go) and I didn't see anything related to the netplan. network_control seems too poweful to me.
<renat> I mean, netplan execution. There is only access to the netplan config dir.
<renat> Hm. network control may do the trick for now, really. Thanks, mvo, I will try!
<mvo> renat: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/network_setup_control.go#L27 mentions /etc/netplan but yeah, not netplan the binary
<Chipaca> mvoâ network_setup_control sounds like it should be able to run netplan (i mean, from the name :). Maybe it was an oversight?
<mvo> Chipaca: worth checking with jdstrand
<zyga> mvo: you now have conflicts in https://github.com/snapcore/snapd/pull/3111
<mup> PR snapd#3111: snapd: initial implementation for systemd software watchdog for snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/3111>
<mvo> zyga: thanks, I have a look. there is a super strange error in there that kill the network-observer-test
<zyga> mvo: aha, looking
<mvo> zyga: which i have not tracked down, I have no idea where this issue comes from, looks like snap-exec gets killed from seccomp for trying to bind
<mvo> zyga: but how my branch does trigger this is a bit a mystery
<zyga> mvo: lets land this: https://github.com/snapcore/snapd/pull/3129/files
<mup> PR snapd#3129: interfaces/mount: add InfoEntry type <Created by zyga> <https://github.com/snapcore/snapd/pull/3129>
<zyga> mvo: I added a tweak to debug output
<zyga> mvo: we should be able to see seccomp kills better
<zyga> mvo: and see what was connected
<zyga> mvo: if you want I can cherry pick that to a separate branch
<mvo> zyga: aha, interessting. fwiw, this PR is slightly strange, it seems to mix two things. but yeah, the extra debug output will be very useful
<zyga> mvo: I added that to chase the failure i saw there
<zyga> Chipaca: can you please have a look at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/amd64/s/snapd/20170405_014746_f1886@/log.gz
<zyga> there's a failure in tab completion there
<zyga> + systemctl stop snapd.service snapd.socket
<zyga> Job for snapd.service canceled.
<zyga> ah, sorry
<zyga> the error is:
<zyga> + rm testdir/foo.snap bar.snap
<zyga> rm: cannot remove 'testdir/foo.snap': No such file or directory
<zyga> Chipaca: probably trivial to address
<Chipaca> zygaâ error in prepare
<nanodrone> snappy vs flatpak (i came across it just like a few minutes ago), which one is better for a beginner?
<Chipaca> zygaâ that's probably not completion failing
<zyga> pedronis: there's a failure in TestEnsureRefreshesAlreadyRanInThisInterval here, can you have a look https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-image/zesty/amd64/s/snapd/20170404_110852_3f885@/log.gz
<zyga> pedronis: if that's just a race please let me know
<Chipaca> nanodroneâ you're asking us, we're going to say snappy :-)
<fgimenez> mvo: regarding the 2.21 -> edge reexec scenario in spread-cron, after installing the missing debs from the ppa we are getting these errors https://travis-ci.org/snapcore/spread-cron/builds/218741347 iirc those are expected (some required changes haven't landed yet) if you could take a look to confirm that would be great
<zyga> nanodrone: I think it doesn't matter if you are a beginner or not, it depends on what you want to do
<zyga> nanodrone: snappy has wider scope
<Chipaca> zygaâ worse, I can't see why prepare failed :-/
<nanodrone> flatpak seems like a fedora/redhat project, and snappy seems more debian/ubuntu (i dont know much)
<mvo> fgimenez: sure, checking
<nanodrone> where's the snappy hello-world page?
<zyga> nanodrone: if you trace the money (who is working on a payroll) then that is probably redhat / canonical, respectively but that doesn't matter in any way
<zyga> nanodrone: everyone makes a living somehow
<zyga> nanodrone: did you see snapcraft.io?
<zyga> Chipaca: another interesting failure: we ran out of memory in a test on zesty: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-image/zesty/amd64/s/snapd/20170404_114038_f7ff1@/log.gz
<zyga> tests/main/interfaces-snapd-control
<nanodrone> of course.
<zyga> aha
<zyga> -- /tmp/go/src/golang.org/x/crypto/ssh/session.gotee: /tmp/autopkgtest.1y2jH6/integrationtests-stderr: No space left on device
<zyga> no space left on device
<zyga> may be a test bed failure more than our fault
<nanodrone> but there's no hello world like flatpak, there should be one dont you think
<nanodrone> i really liked that they have a hello world page.
<pedronis> zyga: IÂ don't understand what you are doing with your remark on PRs and failures?
<zyga> nanodrone: what do you mean a 'hello world' page?
<nanodrone> it makes it less scary to start learning fast
<zyga> pedronis: I'm going through all the PRs that have failing tests
<Chipaca> zygaâ http://flatpak.org/hello-world.html
<zyga> pedronis: and try to figure out what is wrong
<nanodrone> just look at this and you'll know what i'm trying to say http://flatpak.org/hello-world.html
<mvo> fgimenez: hm, maybe edge is a tiny bit outdated, we should definitly keep an eye on this though, afaics the last build is yesterday so this is probably ok but lets double check tomorrow
<zyga> nanodrone: go to https://snapcraft.io/ and scroll to "hello-world"
<zyga> nanodrone: and then read https://snapcraft.io/create/
<zyga> pedronis: some failures are racy tests
<pedronis> zyga: yes
<pedronis> so?
<zyga> pedronis: some failures are buggy code or buggy tests
<zyga> pedronis: I'm trying to make our tests less broken
<nanodrone> i already did, but i'm saying shouldn't there be a big hello world link somewhere...
<fgimenez> mvo: ok thanks
<nanodrone> like at the very top
<pedronis> zyga: well, no, IÂ don't understand why you pointed me at that log? is it one my PRs, do you think IÂ can help? IÂ don't remember writing that test
<Chipaca> nanodroneâ the "create" link is at the very top though
<zyga> nanodrone: I think it depends on who you are, the front page shows you what snaps are and how to use them, we have prominent links to instructions on how to create a snap
<zyga> pedronis: aha, sorry
<zyga> pedronis: I assumed you did as it was in the overlord/state engine parts
<davidcalle> nanodrone: have you seen https://tutorials.ubuntu.com/tutorial/create-first-snap? That's less scary than create
<davidcalle> (in terms of time investment)
<nanodrone> no i haven't davidcalle
<nanodrone> thanks.
<Chipaca> davidcalleâ I think nanodrone's point, which is valid, is that it's not easy to find that page
<pedronis> zyga: no, I think mvo wrote that bit
<zyga> pedronis: I see, thanks!
<davidcalle> Chipaca: there is change coming next week on this front, tutorials being front and center
<pedronis> zyga: anyway maybe better using a forum posts to collect these? or something, lots of micro pings on these are not helpful
<davidcalle> Chipaca: nanodrone: so yeah, I fully agree
<nanodrone> Chipaca, you know those huge COLORED DOWNLOAD links or SIGN UP links you see on websites, that kinda link i'm sure there's an ubuntu theme (?template) we can follow
<nanodrone> it can be an orange creat/hello world link, super friendly
<nanodrone> create*
<Chipaca> nanodroneâ the problem is that the snapcraft.io is not only for developers
<nanodrone> who is it for then
<Chipaca> so not everybody there will want to jump straight for creation
<Chipaca> nanodroneâ users? system integrators?
<Chipaca> nanodroneâ packagers?
<zyga> pedronis: yeah, I'll start tracking those on the forum
<pedronis> zyga: anyway IÂ think most tests with a time.Sleep in them are potentially racy (there's probably only a couple where that is not true)
 * zyga actually goes to the library now
<nanodrone> but i'm a user and a developer and i'm being referred to that site...
<zyga> pedronis: yeah, I understand
<zyga> ttyl
<Chipaca> nanodroneâ "not only for X" does not mean "not for X"
<Chipaca> in any case i look forward to the new thing, davidcalle
<nanodrone> so it's really broad
<Chipaca> also i need to get back to work
<nanodrone> either way i'm packaging using snap now.
<nanodrone> time already invested.
<mvo> zyga: happy to help with the test, is that the same prune one we talked about before?
<pedronis> mvo: no, actually, is a new/modifired test in your refresh schedule branch
<pedronis> so why zyga pinged me is even more mysterious
<pedronis> mvo: but yes all Prune tests seem prone to fail because of slowness/raciness
<mvo> pedronis: yeah, I have that on my list, just wanted to finish some other things first, I will also have a look at my branch failure thing (that is also on my list :)
<zyga> re
<zyga> ah, what a great idea to move and work at a library
<zyga> it's summer all around :)
<zyga> pedronis: I started the thread as suggested
<zyga> I could use some reviews on https://github.com/snapcore/snapd/pull/3135 and definitely on https://github.com/snapcore/snapd/pull/3095
<mup> PR snapd#3135: interfaces/mount: add high-level Profile functions <Created by zyga> <https://github.com/snapcore/snapd/pull/3135>
<mup> PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095>
<pedronis> zyga: the issue why we don't mock the time is that the time is checked in a different package
<morphis> Son_Goku, zyga: ok, I've found the problem why snapd.socket doesn't get enabled on Fedora
<morphis> Son_Goku, zyga: the rpm macro only calls systemctl preset <unit>
<morphis> and we don't install any preset file for systemd
<morphis> so systemctl doesn't know what to do and leaves the units unstarted
<pedronis> zyga: anyway IÂ think IÂ have an idea that might work for Prune, if it still doesn't work then we try to mock time
<zyga> pedronis: thank you for the insight, if you comment on the forum I can try to implement your idea
<zyga> morphis: I think the preset files cannot be installed by any random package, aren't they all collected in one special package? I reacall we got a pull request accepted there that aded snapd.socket and snapd.refresh.timer
<zyga> morphis: and if I systemctl status snapd.socket it does say vendor preset: enabled
<zyga> morphis: I'm installing Fedora 24 Server now, let's see what we get there
<morphis> zyga: yeah its there
<morphis> in /usr/lib/systemd/system-presets/90-default.preset
<morphis> zyga: https://bugzilla.redhat.com/show_bug.cgi?id=1367932
<zyga> morphis: so I don't think I understand your comment, let me re-read
<zyga> morphis: so we don't install any preset file, yes
<zyga> morphis: should we?
<morphis> no
<morphis> its done by the system
<morphis> and snapd.socket is already
<morphis> if you install snapd you need to reboot, then snapd.socket is started
<zyga> morphis: aha
<zyga> morphis: so is this a bug in the preset system or in our %post script/
<morphis> but wondering if we're allowed to do systemctl start snapd.socket
<morphis> zyga: presets only allow enable/disable as far as I know
<morphis> https://www.freedesktop.org/software/systemd/man/systemd.preset.html
<zyga> morphis: aha
<zyga> morphis: let's ask what Son_Goku thinks, we can also ask for advice on the fedora mailing list
<morphis> yeah that would be my next step, hardcoding a `systemctl start snapd.socket` in the spec file doesn't sound great
<morphis> but let me see if I find other examples
<zyga> morphis: I think it is not allowed
<morphis> yeah most likely
<morphis> zyga: ok, looks like this is the default, you need to reboot to get the service active, no direct start
<morphis> zyga: same happens for lircd.socket for example
<zyga> morphis: aha
<zyga> morphis: we can say something like that in %post maybe, is there a way to signal this to the user?
<morphis> zyga: not sure, asking on fedora-devel now
<morphis> as even https://fedoraproject.org/wiki/Packaging:DefaultServices isn't saying anything about this
<morphis> but would expect on systems like a server you want services to run out of the box after installation without manual work
<pedronis> zyga: posted some diff pastebin in the forum
<zyga> pedronis: thanks!
<zyga> morphis: FYI, rebooting on f24 doesn't start the socket
<zyga> morphis: vendor preset is disabled
<morphis> zyga: can you check /usr/lib/systemd/system-presets/80-default.preset?
<morphis> zyga: looks like they only submitted packages for 25 with https://bugzilla.redhat.com/show_bug.cgi?id=1367932
<mup> Bug #1680011 opened: snapd support for xdg-desktop-portal <Snappy:New> <https://launchpad.net/bugs/1680011>
<zyga> morphis: looking
<zyga> morphis: I have system-preset (not presets) and I have 90-default.preset (not 80), nothing in that directory mentions snapd
<zyga> morphis: in general, I'd patch snap (client) to give a smarter message
<zyga> morphis: the current one is terrible
<zyga> morphis: installing hello-world just to see if it works
<zyga> it does :)
<nanodrone> zyga, what's the snappy 'core' that's downloaded at the very start?
<zyga> morphis: so I'd change the narrative in client/*.go
<zyga> nanodrone: it's a snap that provides base runtime environment for all other snaps
<zyga> nanodrone: it contains the root filesystem, basic executables and basic libraries
<zyga> nanodrone: on core systems (those that use snaps exclusively) it is also used as the actual root file system
<zyga> nanodrone: over time it will shrink and get split into a core snap that has just skeleton rootfs and snapd, and one of many base snaps
<nanodrone> wow...
<zyga> nanodrone: (e.g. a base snap providing ubuntu 16.04 runtime, a base snap with fedora 26 runtime, etc)
<zyga> nanodrone: a particular snap will then declare which base snap it was built against
<zyga> nanodrone: so you can run 16-based apps alongside 18-based apps or fedora/yocto/etc
<zyga> nanodrone: the core snap is already small but with this approach it will shrink significantly
<Chipaca> jdstrandâ you around?
<nanodrone> who's programming this stuff, it sounds really awesome.
<zyga> nanodrone: and it will be possible to build even smaller embedded devices, with stripped down base snaps
<zyga> nanodrone: we also have kernel snaps but those are not used on classic systems (those that use regular distribution filesystem alongside snaps)
<zyga> nanodrone: let me know if you have any more questions, feel free to post this conversation in the forum for others to find
<nanodrone> ubuntu core comes to mind... lol
<nanodrone> can i just publish my app now, is that okay?
<zyga> nottrobin: snapd is made by a wide variety of individuals, you can see full development history on github.com/snapcore/snapd (e.g. here: https://github.com/snapcore/snapd/graphs/contributors
<zyga> nanodrone: ^
<morphis> nanodrone: sure, the store is open for your apps :-)
<zyga> sorry, tab completion error :)
<zyga> nanodrone: in addition various parts of the core snap are made by 100s of people in various communities
<morphis> nanodrone: https://snapcraft.io/docs/build-snaps/ will get your started
<zyga> nanodrone: yes, you are welcome to publish your snaps at any time
<nanodrone> this is huge, i can't wrap my head around this concept, and to think it actually works and i have access to it right now.
<nanodrone> i've already built a snap
<nanodrone> lol
<nanodrone> it was easy.
<morphis> :-D
<zyga> nanodrone: they can be immediately installed on ubuntu/debian and deriviatives and also on fedora (currently in testing but should go out this week) and opensuse (not in the main archive yet, a separate system:snappy repo exists)
<zyga> nanodrone: you are welcome :)
<morphis> zyga: you saw https://bugs.launchpad.net/snappy/+bug/1680011 ?
<mup> Bug #1680011: snapd support for xdg-desktop-portal <cross-distro> <Snappy:New> <https://launchpad.net/bugs/1680011>
<zyga> nanodrone: snapd is also pretty portable so your application can easily be installed on a new distribution by simply working on packaging snapd there
<morphis> zyga: wondering if there were already any conversations regarding support for portals
<zyga> morphis: looking
<nanodrone> i was really scared when i first saw the ~80megs core installation at first but after actually getting to know the basic concepts, i'm a fan...
<zyga> morphis: intereting
<zyga> nanodrone: note that the 80mb is shared by all the snaps you can currently install
<nanodrone> maybe yall should mention this on the homepage
<morphis> nanodrone: https://docs.ubuntu.com/core/en/ may help you to dive a bit deeper
<zyga> nanodrone: and we also have delta updates so they should not be noticeable
<zyga> morphis: so I see some benefits here and some issues
<zyga> morphis: one is that we probably don't want to delegate security to a 3rd party trusted helper
<zyga> morphis: let's start a thread about this and see what jdstrand and tyhicks think about it
<nanodrone> just to be sure, is snapcraft.io the official homepage?
<zyga> morphis: one think that feels like an obvious approach is to stack the helpers
<morphis> nanodrone: yes
<zyga> morphis: so that we can sit between snaps making requests and if we veto it ok relay that to platform helper
<morphis> nanodrone: for snaps in general it is
<zyga> nanodrone: yes
<morphis> nanodrone: if you want more about Ubuntu Core https://docs.ubuntu.com/core/en/ is the official documentation
<nanodrone> noted. thanks.
<zyga> morphis: I'm curious about `.flatpak-info`
<morphis> zyga: I guess it is similar to snap.yaml
<zyga> morphis: aha, I see
<zyga> morphis: so we'd have to generalize that aspect
<zyga> morphis: I think if we can engage in portal development
<zyga> morphis: that is something to consider
<zyga> morphis: currently portals look too flatpak centric given their "xdg" branding (though that is to be expected)
<morphis> zyga: so you say having an xdg-portal snap which overs all these services?
<zyga> morphis: I think we can collaborate on those though
<zyga> morphis: I wasn't thinking about that
<zyga> morphis: I see some possiblities (making portals really generic and just adopting them)
<zyga> morphis: implement portal api in snapd
<morphis> I see
<zyga> morphis: or put snapd as a proxy between platform portals and snaps
<zyga> morphis: it depends on security aspects
<zyga> morphis: on design considerations (does this block any cool ideas on first having an agreement with flatpak developers working on portals)
<zyga> morphis: and usability considerations (is this what we want?)
<zyga> morphis: let's start a thread about this or discuss on the bug report
<pedronis> morphis: IÂ tend there was a thread on a mailing list about portals
<pedronis> s/tend/think/
<morphis> pedronis: ok, worth bringing this into the discussion
<zyga> morphis: I would love if we could collaborate on shared technology with flatpak developers personally
<tvoss> zyga, I think we want to have snapd being the ultimate source of anything trust in the system. That being said, a backend talking to snapd does not seem to be unreasonable. I'm working on a similar setup for PolicyKit
<zyga> tvoss: I agree
<morphis> tvoss: +1
<zyga> tvoss: I think that is not negociable as this is the root of trust on the system really
<zyga> negotiable*
<morphis> let me comment on the bug so we get that discussion started in the forum
 * zyga jumps off IRC to work on some test improvements
<popey> ogra: remember the pinebook? https://www.pine64.org/?page_id=3707 - they just sent out pre-order emails. $99 for an arm laptop :)
<popey> "We do not wish to discourage anyone from getting a Pinebook, as it is a good piece of hardware, but if you are looking for a device to replace your current work or school laptop, then perhaps itâs wise to look elsewhere."  :)
 * Chipaca ~> lunch
<ogra> popey, heh, yeah, it is closer to a chromebook i guess
<Chipaca> popeyâ 99 for the 14", 89 for a 12"?
<popey> yeah
<Son_Goku> zyga, morphis: hardcoding starting the socket isn't allowed
<morphis> Son_Goku: so what is the recommend way for the user here? reboot?
<Son_Goku> well, actually, it looks like we could technically start the socket if the preset enables it
<Son_Goku> I see that we do this for lvm2
<Son_Goku> morphis, zyga: systemd presets were designed for the provisioning use-case, so I guess I don't see a reason not to auto-start it
<Son_Goku> since we *are* enabling it for F25 and up
<morphis> Son_Goku: maybe we do a is-enabled check before we start it
<sborovkov> Hi
<sborovkov> What's going on here?
<sborovkov> root@localhost:/home/pi# snap set core pi-config.disable-overscan=true
<morphis> Son_Goku: so we respect if an administrator has a preset which disables snapd in contrast to the distro default
<sborovkov> error: cannot perform the following tasks:
<sborovkov> - Run configure hook of "core" snap (run hook "configure": awk: not an option: --sandbox)
<Son_Goku> morphis: right
<sborovkov> My snapd is: snapd   2.23.6+201704041910.git.e7f0423~ubuntu16.04.1
<morphis> sborovkov: is that on a stable core snap or edge?
<sborovkov> morphis: stable. Should I upgrade to edge?
<sborovkov> nvm
<sborovkov> it's edge
<sborovkov> installed:   16-2 (1632) 70MB -   edge:      16-2 (1632) 70MB -
<morphis> sborovkov: ok, but still a bug
<sborovkov> morphis: manually trying to get pi-config from the REST api does not work as well
<morphis> ogra, mvo: ^^
<sborovkov> >>> r = session.get('http+unix://%2Frun%2Fsnapd.socket/v2/snaps/core/conf', params={'keys': 'pi-config'})
<sborovkov> >>> r.text
<sborovkov> '{"type":"error","status-code":400,"status":"Bad Request","result":{"message":"snap \\"core\\" has no \\"pi-config\\" configuration option"}}'
<sborovkov> >>>
<zyga> morphis: I like the is-enabled check
<zyga> sborovkov: that's gawk/mawk
<zyga> sborovkov: I think we fixed that (^ mvo )
<sborovkov> zyga: why is there no pi-config option returned by rest api though?
<zyga> sborovkov: no idea
<sborovkov> or it because nothing is set there.
<morphis> zyga: me too
<morphis> Son_Goku: is that an option for you?
<Son_Goku> morphis: yes
<Son_Goku> it's certainly better than what some other people have been doing
<zyga> Son_Goku: I think we want to start it if enabled and patch snap to give useful advice if it's not started
<zyga> Son_Goku: right now it's really barf-from-the-system
<mvo> sborovkov: its because nothing is set there, only once you set something it will return something, its not (currently) smart enough to look at existing values that have not been set via the config. if that is something you need, it might be worth catching up with niemeyer so that we put it on the agenda
<Son_Goku> snap will need to give useful advice anyway, since F24 won't have it
<zyga> Son_Goku: can we push an update to F24 to enable it there too?
<Son_Goku> no
<zyga> Son_Goku: not ourselves I mean
<zyga> Son_Goku: via the same process we used for F25
<sborovkov> mvo: well I guess, I can live with it not returning anything. And just handling that case.
<zyga> pedronis: I applied your patch and got to the point were I think I understand how it works, I'll follow up with the 2nd test now
<Son_Goku> zyga: yes, technically, but I think they don't like modifying presets for released distros
<zyga> Son_Goku: I see
<Son_Goku> remember that F25 got it because we requested it back before F25 was released
<zyga> Son_Goku: I think that's fine
<Son_Goku> and F24 EOLs a month after F26 releases anyway
<zyga> Son_Goku: we can try but we should definitely patch snapd to just be nicer UX wise
<Son_Goku> so it's not a terrible situation
<zyga> Son_Goku: right
<zyga> Son_Goku: exactyl
<zyga> *exactly
<zyga> morphis: the install instructions can say that on F24 we need to enable+start the services manually
<sborovkov> One more question about rest API. Am I doing something wrong here? >>> r = session.put('http+unix://%2Frun%2Fsnapd.socket/v2/snaps/core/conf', data={'pi-config.disable-overscan': 'true'}) ,"result":{"message":"cannot decode request body into patch values: invalid character \'p\' looking for beginning of value"}}'
<sborovkov> Might be dumb question, but I am not working with REST apis very often :(
<morphis> zyga: sounds good, will take care to update the instructions on snapcraft.io
<zyga> sborovkov: no idea but I bet Chipaca knows
<Son_Goku> morphis: don't forget I already have a PR for the Fedora instructions
<zyga> meanwhile I'm going to get back to test reliability :)
<sborovkov> Chipaca: hello :-) do you know what I might be doing wrong there?
<morphis> Son_Goku: you have one?
<Son_Goku> go look at snappy-docs :)
<morphis> ah great!
<morphis> didn't saw that one yet
<davidcalle> Son_Goku: do you have any timing on when this will be mergeable btw?
<morphis> Son_Goku: let me review
<Son_Goku> davidcalle: Fedora bodhi updates can be pushed after five days of being in updates-testing with zero changes and not enough feedback
<morphis> Son_Goku: really?
<morphis> so karma is optional?
<Son_Goku> morphis: karma makes it go faster
<morphis> ah!
<Son_Goku> I have autokarma enabled, so that means that if enough positive karma is set, bodhi will push immediately
<zyga> morphis: I tested F24 and will give my +1 soon
<zyga> morphis: did you see my feedback there?
<zyga> morphis: we could look at bumping the progress bar library
<morphis> zyga: yes
<zyga> morphis: and perhaps do a survey to see where the libs in fedora are older than what we vendor
<morphis> zyga: I am testing f24 currently too
<zyga> morphis: it's just a _visible_ difference so I noticed
<zyga> morphis: but we may be facing other issues
<morphis> right, I already have that on my list
<zyga> excellent!
<morphis> zyga: would be good if we can automate that somehow
<morphis> against any distro
<morphis> (for those where we don't use vendor=
<zyga> morphis: I bet you can
<zyga> morphis: but I'd do it manually at least once too
<morphis> zyga: let me do that :-)
<morphis> zyga: btw. interesting is that docker for openSUSE uses vendoring
<zyga> morphis: oh, who maintains the package?
<Son_Goku> morphis: there was some SERIOUS drama being golang packaging
<zyga> morphis: maybe it is a commercial thing
<morphis> zyga: https://build.opensuse.org/package/view_file/Virtualization:containers/docker/docker.spec?expand=1
<Son_Goku> zyga: remember I told you about that
<zyga> Son_Goku: no, I didn't
<morphis> zyga: Copyright (c) 2017 SUSE LINUX GmbH, Nuernberg, Germany.
<zyga> :-)
<davidcalle> zyga: for now, until the above gets pushed, what's the missing command for fedora install, I'm deploying in a couple hours, so can be added right now
<Son_Goku> zyga: you mentioned it here: https://new.zygoon.pl/post/state-of-snapd-support-across-distros/
<Son_Goku> davidcalle: the current instructions for Fedora are correct for now
<Son_Goku> my PR revises it for the state it will be once they are merged into the repos
<Son_Goku> zyga, morphis, davidcalle: if I don't get +6 karma before Friday, I think, I'll be able to push it manually
<davidcalle> Ok, from reading up, I thought there was a missing command to start the services (in addition to enabling them)
<morphis> zyga: sounds good
<Son_Goku> davidcalle: in the instructions, no
<davidcalle> Alright
<zyga> Son_Goku: my memory is very rusty then :)
<Son_Goku> zyga and morphis would like me to make it start them automatically from package install
<zyga> Son_Goku: I should send a follow-up to that post
<zyga> Son_Goku: as the reality now is much happier than before
<Son_Goku> that's a different thing ;)
<zyga> I just commented on https://bodhi.fedoraproject.org/updates/FEDORA-2017-ce0fdd87a4
<zyga> I didn't test snapd-glib in any way though
<Chipaca> sborovkov, zyga, sorry was having lunch. What's the question?
<zyga> I'll do F26 in the evening, I have to download the alpha ISOs and I have little power to spare on the installation now
<zyga> Chipaca: some questions about the REST APIs earlier
<zyga> Chipaca: about config specifically
<Son_Goku> zyga: morphis and I already know there are issues with snapd-glib
<Chipaca> ah, I don't know much about config; that's pstolowski
<Son_Goku> zyga: hughsie is trying to use it and is getting weird/broken results
<pstolowski> what's up?
<Chipaca> pstolowski, sounds like the REST docs for config aren't enough for sborovkov here to apply them in the real world
<zyga> I'll let you figure it out , scroll back to "13:54 < sborovkov> One more question about ..."
<fgimenez> zyga: quick question about the core:network-bind plug, on a classic system with ubuntu-core installed, if i install a snap which declares a plug on network-bind before the transition happens, after the transition i see core:network-bind disconnected, is that the expected behaviour?
<zyga> Son_Goku: about the extra APIs for figuring out where /snap directory is?
<zyga> fgimenez: mhh
<Son_Goku> zyga: no, that's a different thing
<zyga> fgimenez: and it was connected before the transition?
<Son_Goku> though I'm not sure if gnome-software needed that
<morphis> zyga: ignore snapd-glib for now
<zyga> morphis: ok
<zyga> fgimenez: if it was then this does feel like a bug
<morphis> Son_Goku, zyga: I am currently trying to get g-s/snapd-glib into shape
<Son_Goku> okay
<morphis> zyga: you should have a mail in your inbox about that topic
<pedronis> fgimenez: seems a bug, bit strange we never noticed it? IÂ thought the test were actually testing that case
<zyga> morphis: aha
<morphis> Son_Goku, zyga: but getting g-s requires some more work
<pedronis> fgimenez: IÂ mean the core transition spread tests, anyway seems a question for mvo
<morphis> zyga, Son_Goku: as upstream isn't that happy with the current snap-support state
<zyga> fgimenez, pedronis: we definitely move connections over from ubuntu-core to core but perhaps something else is intervening; I also recall that if you had both core snaps installed you'd not auto-connect
<zyga> fgimenez: so if you are 100% sure it was connected before then this is a bug
<Son_Goku> morphis, zyga: I'm not surprised
<morphis> zyga, Son_Goku: list of bugs I filed so far https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bugs?field.tag=cross-distro
<Son_Goku> morphis: you should connect those to gnome-software package in Fedora in LP
<morphis> Son_Goku: not yet
<zyga> morphis: it would be interesting to grow UI for connections in g-s
<morphis> zyga: yes but I am wondering on which list that is
<zyga> morphis: so that you can click on something "interface connections" and have something sensible there
<fgimenez> zyga: before the transition core:network-bind is not llisted as plug, this is the complete sequence http://paste.ubuntu.com/24319937/
<pstolowski> sborovkov, i'm not familiar with that side of config (rest api) either, but quick look at the code where this error is thrown reveals that a json map is expected at this point
<mvo> fgimenez: uh, that should not happen. there is even a test (xkcd-webserver iirc) that checks for this
<pstolowski> sborovkov, i.e. data should be a json map
<pstolowski> afaict
<zyga> fgimenez: woah
<zyga> fgimenez: that's so weird
<zyga> note that network-bind is listed _twice_
<fgimenez> zyga: mvo if no snap declaring a plug on network-bind is installed, then after the transition you see ":network-bind    core,test-snapd-python-webserver"
<zyga> give me a sec
<fgimenez> i mean ":network-bind    core"
<mvo> fgimenez: what did you do to reproduce?
<sborovkov> pstolowski: well I tried r = session.put('http+unix://%2Frun%2Fsnapd.socket/v2/snaps/core/conf', json={'pi-config.disable-overscan': 'true'}). That does nothing though, hmm. '{"type":"async","status-code":202,"status":"Accepted","result":null,"change":"27"}'
<fgimenez> mvo: it's all in the paste, this is from a fresh 16.04.2, while validating ubuntu-core from beta
<morphis> zyga: sounds like a good idea
<pstolowski> sborovkov, mind creating a forum topic with that?
<fgimenez> mvo: "apt install -y snapd" is missing, other than that is all there
<zyga> fgimenez: do you have that system around?
<zyga> fgimenez: can you get the raw response for GET /v2/interfaces
<mvo> fgimenez: thank you
<fgimenez> zyga: i can bring it up again, 1sec
<pstolowski> sborovkov, actually nvm, let's try to figure out here
<zyga> fgimenez: so what that looks like to me
<zyga> fgimenez: is that the transition failed but we have both installed
<zyga> fgimenez: note that we hide both "core" and "ubuntu-core" in the client
<zyga> fgimenez: so that thing at the end is a plug, not a slot actually
<zyga> fgimenez: so that's the disconnected "network-bind" plug on the core snap
<zyga> (sorry I got confused earlier)
<morphis> zyga, mvo: are you guys happy with https://github.com/snapcore/snapd/pull/3096 so that we can merge it?
<mup> PR snapd#3096: many: abstract path to /bin/{true,false} <Created by morphis> <https://github.com/snapcore/snapd/pull/3096>
<zyga> fgimenez: still, really weird
<zyga> morphis: checking
<zyga> morphis: you need to get +1 from niemeyer on that
<morphis> zyga: "Please feel free to merge when you're happy about the handling of these problems."
<pstolowski> sborovkov, so looks like it worked, that should have triggerd your configure hook?
<morphis> niemeyer: can you review https://github.com/snapcore/snapd/pull/3096 again?
<mup> PR snapd#3096: many: abstract path to /bin/{true,false} <Created by morphis> <https://github.com/snapcore/snapd/pull/3096>
<zyga> morphis: yes but you'd have to override a review that requested changes to do that
<niemeyer> Hellos
<sborovkov> pstolowski: No. Since it did not set anything. Doing get after that: '{"type":"error","status-code":400,"status":"Bad Request","result":{"message":"snap \\"core\\" has no \\"pi-config\\" configuration option"}}'
<niemeyer> morphis: Will do
<zyga> fgimenez: I have a theory
<morphis> niemeyer: thanks!
<zyga> fgimenez: when we install new core over ubuntu-core
<zyga> fgimenez: we briefly have both installed
<zyga> fgimenez: and then auto-connects bail out
<zyga> fgimenez: I think that's easy to test
<morphis> Son_Goku: can you cross-check if we now have all PRs merged we need for fedora?
<zyga> fgimenez: we should fix the auto-connect logic to skip ubuntu-core if core is installed
<zyga> niemeyer: hey
<Son_Goku> morphis: there's one issue we still need solved, and that's the thing with the constants
<Son_Goku> there's no pr for that because you said you'd fix it properly
<zyga> niemeyer: will you have the time to look at https://github.com/snapcore/snapd/pull/3095 today?
<mup> PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095>
<fgimenez> zyga: aha fwiw the core:network-bind plug seems to work fine (ie autoconnects) when no snap declaring a plug on network-bind is installed before the transition start
<morphis> Son_Goku: ah right
<morphis> Son_Goku: let me look into that today
<zyga> fgimenez: ubuntu-core doesn't use it
<zyga> fgimenez: so it's not connected
<zyga> fgimenez: then you install core which currently does use network-bind
<zyga> fgimenez: and since you have two provides auto-connect does nothing
<niemeyer> morphis: Why is it bundling changes from retry?
<niemeyer> morphis: That doesn't look right
<morphis> ?
<zyga> fgimenez: so you just install core but that plug just is left as-is
<niemeyer> morphis: https://github.com/snapcore/snapd/pull/3096/files#diff-373b88c8996bc0465932cbb690320cf6
<mup> PR snapd#3096: many: abstract path to /bin/{true,false} <Created by morphis> <https://github.com/snapcore/snapd/pull/3096>
<zyga> niemeyer: that's my fault, sorry
<morphis> niemeyer: yeah somebody updated my branch
<zyga> niemeyer: we discussed that with mvo yesterday
<morphis> niemeyer: just placed my last change on top of what was pushed
<Son_Goku> zyga, morphis: https://paste.fedoraproject.org/paste/sVS0uNm4fHAmKSKVAlgi815M1UNdIGYhyRLivL9gydE=
<Son_Goku> how does that look?
<zyga> niemeyer: I can revert that there, at the time we hoped it would land in master and the extra EOF retry would fix the failures we (randomly) got there
<Chipaca> zygaâ is there a sh-friendly runtime way of knowing libexecdir?
<morphis> Son_Goku: looks good to me
<niemeyer> zyga: That's pretty dangerous.. the other branch was still unreviewed
<zyga> Son_Goku: looks good to me
<zyga> niemeyer: at the time it had only positive feedback and it looked as if it would land imminently
<mvo> niemeyer: https://irclogs.ubuntu.com/2017/04/04/%23snappy.html#t11:42
<zyga> niemeyer: lesson learned
<niemeyer> morphis: Right thing here now is to merge master on it, and then fix conflicts.. these unrelated lines must go away from the diff
<fgimenez> zyga: so, going back to the initial question :) is that the expected behaviour, is it ok to have the core:network-bind plug disconnected in some cases after the transition?
<niemeyer> morphis, zyga: The PR did change before landing
<zyga> fgimenez: no, it's a bug
<mvo> niemeyer: i.e. the same point was raised yesterday, no disagreement
<pstolowski> sborovkov, can you execute your snap-set request again and check if 'snap changes' as well as journalctl show anything interesting?
<morphis> niemeyer: fine with that
<Son_Goku> morphis: if everything is dealt with, then I can propose to merge the snapd spec for Fedora for snapd 2.24
<zyga> mvo: I think we have one interesting bug in core transition
<zyga> mvo: something that didn't affect us at the time
<mvo> zyga: yeah, I was just reading backlog
<niemeyer> mvo: *thumbs up*
<zyga> mvo: if you are in the transition then none of the new plugs on core will be connected
<zyga> mvo: I'll try to fix it today with something very simple but I wanted to let you know
<niemeyer> zyga: About 3095, I will
<mvo> zyga: \o/
<zyga> niemeyer: thank you
<mvo> zyga: I was about to ask if you have an idea for a fix :)
<zyga> mvo: yes, I would check if core and ubuntu-core are both installed and then totally ignore ubuntu-core when looking for auto-conncet candidates
<zyga> mvo: it would then connect correctly unless I'm missing some detail
<mvo> zyga: that sounds good
<Son_Goku> morphis: the (bad? good?) news is that snapd-qt from snapd-glib isn't used at all by Plasma Discover
<morphis> niemeyer: done
<niemeyer> morphis: Looks great, thank you for the changes!
<mvo> fgimenez, zyga: how to best track this? a new forum post? or should I just put it on the 2.24 release page?
<morphis> niemeyer: np
<sborovkov> pstolowski: Alright, so one of my commands worked. The one with typo in command. So I am trying to figure out which one. Or if there is just a big lag between execution of async request.
<morphis> Son_Goku: :-)
 * zyga -> quick walk before the standup
<morphis> a different story ..
<zyga> see you soon
<sborovkov> pstolowski: Apr 05 12:28:35 localhost.localdomain /usr/lib/snapd/snapd[1016]: task.go:303: DEBUG: 2017-04-05T12:28:35Z ERROR run hook "configure": awk: not an option: --sandbox
<sborovkov> after post requests.
<sborovkov> put*
<Son_Goku> morphis, so I can update snapd and snapd-glib with the new changes (new scriptlet for snapd, new version for snapd-glib), but that will kick the update back out
<Simooon> The snaps available using the "snap find" command are the same, regardless of what system I'm on, correct?
<Son_Goku> and unless you have a number of people who have Fedora accounts to give karma on the new update, it's going to have to wait another week
<fgimenez> mvo: not sure, maybe the branch with the fix could be added to the release page once it's up?
<Son_Goku> morphis, on the other hand, the user experience improvement might be worth it
<fgimenez> mvo: quick question, this problem showed up while validating the ubuntu-core snap on beta in order to promote it, other than that all looks fine, do you think we should continue with the promotion or wait for the fix?
<mvo> fgimenez: I think the issue is independant of ubuntu-core, i.e. it will also manifest itself with the stable ubuntu-core. its core itself that is the problem
<fgimenez> mvo: great thank you
<mvo> fgimenez: do you see ill effects ? can you run snap config get core refresh.disabled
<mvo> fgimenez: or do you get apparmor/seccomp denials in syslog if you do that on the system that you transitioned?
<fgimenez> mvo: haven't checked, let me try
<pstolowski> sborovkov, if you have an error in your configure script (if it exits with status 1), then this will abort entire change to the config, so the config option won't be set
<sborovkov> pstolowski: why does it even set unsupported keys then? '{"type":"sync","status-code":200,"status":"OK","result":{"pi-config":{"disble-overscan":"false"}}} :-(
<pedronis> so awk on that system doesn't have --sandbox?
<pedronis> how is that possible
 * pedronis is confused
<sborovkov> I don't know. zyga mentioned that it was fixed somewhere I think.
<sborovkov> alright, I can set the options now. I guess I need to reboot to see if config.txt will change?
<Chipaca> mawk vs gawk?
<sborovkov> Or when that change is going to be triggered?
<pedronis> Chipaca: yea, but it comes from core
<pedronis> did we have the wrong one setup for a bit?
<mvo> sborovkov: I'm not an expert for the pi config.txt details, but my understandig is that this is pretty lowlevel (firmware) so a reboot seems to be needed
<Chipaca> pedronisâ on classic you get a symlink
<Chipaca> or used to, i haven't tracked that one
<pedronis> so much fun for classic snaps
<pedronis>  /snap/core/current/usr/bin/awk -> /etc/alternatives/awk
<pedronis> not that I think it's the issue here
<Chipaca> niemeyerâ is it expected that spread'd segfault?
<Chipaca> http://pastebin.ubuntu.com/24320095/
<sborovkov> mvo: Ok I rebooted. Config.txt is unchanged. Hmm.
<mvo> sborovkov: meh
<mvo> sborovkov: the option did not get applied?
<sborovkov> disregard that. I had typo in option name.
<sborovkov> Let me recheck
<sborovkov> why does it not reject arbitrary keys in such cases?
<mvo> sborovkov: this indicates that we really need to validate those option names!
<sborovkov> does that make sense?
<fgimenez> JamieBennett: all seems to be fine with ubuntu-core at beta, there's a problem with the ubuntu-core -> core transition (see the backlog) but it's not specifically related to the ubuntu-core snap
<niemeyer> Chipaca: Definitely not, thanks for the traceback
<pstolowski> sborovkov, i'm not familiar with pi config, but in general you can make up any options as long as the configure script of given snap allows this and doesn't error out on something unknown (which is probably impossible to implement in configure script anyway because there is no way of getting all options afair)
<mvo> sborovkov: its not doing it right now because we have no "schema" for the config currently. afaik niemeyer has some ideas about config validation so that we can reject invalid options (or option values) early
<sborovkov> mvo: Ok I understand why I am going crazy here
<sborovkov> So it does not work when I set proper name
<sborovkov> any arbitrary name is working though
<fgimenez> JamieBennett: if you want to take a look to the tests executed i've written a small spread task for this kind of validations https://github.com/fgimenez/validate_image/pull/6/files
<sborovkov> >>> r = session.put('http+unix://%2Frun%2Fsnapd.socket/v2/snaps/core/conf', json={"pi-config.disable-oasdfsdfverscan": "true"}) - works
<mvo> sborovkov: what error do you get with the correct name?
<Chipaca> niemeyer, I'd pretend to be surprised, but this endeavour has been hitting this kind of corner case weirdness all across the stack :-)
<mvo> sborovkov: sorry for the trouble :/
<sborovkov> >>> r = session.put('http+unix://%2Frun%2Fsnapd.socket/v2/snaps/core/conf', json={"pi-config.disable-overscan": "true"}) no change
<sborovkov> mvo: that's fine. I get no error. It just gets ignored
<mvo> sborovkov: ok, let me try to reproduce
<JamieBennett> fgimenez: so you are happy to us to promote to candidate and have jibel do a test?
<niemeyer> Chipaca: Sorry for the pain there :)
<sborovkov> mvo: https://hastebin.com/alovofejaz.scala
<fgimenez> JamieBennett: yes, all looks fine
<niemeyer> Chipaca: Some of them are pretty amazing I must say
<Chipaca> sborovkovâ so
<JamieBennett> jibel: Are you the team OK to do a sanity check on the ubuntu-core snap?
<Chipaca> sborovkovâ you're getting 202 Accepted
<Chipaca> sborovkovâ do you then look at the change?
<Chipaca> sborovkovâ (sorry, jumping in because i happened to look at the pastebin, haven't been following)
<Chipaca> 2m test startup time does that to me
<niemeyer> Chipaca: We should suggest a replacement of Spotlight Awards by Breakage Awards.. I think that makes a lot more sense
<sborovkov> Chipaca: look at the hastebin. If I set proper name it's accepted. next get returns no difference. With arbitrary key I see that it changes.
<Chipaca> sborovkovâ Accepted does not mean it worked
<Chipaca> sborovkovâ you need to look at the change to know that
<sborovkov> Ah, alright, I will check
<Chipaca> sborovkovâ you get the change id as part of the 202 response
<pedronis> sborovkov: it's an async api
<Chipaca> sborovkovâ and then you hit /v2/changes/<id>
<Chipaca> (from memory)
<jibel> JamieBennett, yes, when do you need it done?
<JamieBennett> Well, I have published the core snap, just waiting for a validation of the ubuntu-core snap so when ever you are ready
<jibel> JamieBennett, ubuntu-core not core, correct?
<JamieBennett> jibel: right
<sborovkov> Chipaca: '{"type":"sync","status-code":200,"status":"OK","result":{"id":"50","kind":"configure-snap","summary":"Change configuration of \\"core\\" snap","status":"Error","tasks":[{"id":"135","kind":"run-hook","summary":"Run configure hook of \\"core\\" snap","status":"Error","log":["2017-04-05T12:50:02Z ERROR run hook \\"configure\\": awk: not an option: --sandbox"],"progress":{"label":"","done":1,"total":1},"spawn-time":"2017-04-05T12:50:01.752141739Z","
<sborovkov> ready-time":"2017-04-05T12:50:02.953066325Z"}],"ready":true,"err":"cannot perform the following tasks:\\n- Run configure hook of \\"core\\" snap (run hook \\"configure\\": awk: not an option: --sandbox)","spawn-time":"2017-04-05T12:50:01.752253041Z","ready-time":"2017-04-05T12:50:02.953071898Z"}}'
<pedronis> so the awk wrong
<mvo> sborovkov: $ sudo snap set core pi-config.disable-overscan=true
<mvo> error: cannot perform the following tasks:
<mvo> - Run configure hook of "core" snap (run hook "configure": awk: not an option: --sandbox)
<mvo> sborovkov: is what I get :/ I'm working on that no, sorry for this
<Chipaca> maybe our awk is suddenly bb.awk or sth
<Chipaca> on core rpi
 * Chipaca looks at ogra 
<Chipaca> :-D
<sborovkov> mvo: Alright, I guess that's all related. Can you ping me when it gets fixed or there is some PR for this or whatever
<ogra> heh, no, it is still gawk as always :)
<Chipaca> mvoâ this is an extra nice reason to move the python configure hook in; what's that blocked in again?
<pedronis> it seems not to believe that
<Chipaca> s/blocked in/blocked on/
<mvo> Chipaca: not sure if there is anything blocking, zyga did raise an issue with the context manager iirc
<Chipaca> sigh
 * Chipaca looks
<zyga> Chipaca: sorry, I think you want to fix/test that context manager
<ogra> hmm, or not ... looks like the alternative points actually to mawk
<mvo> Chipaca: lets talk aobut it during the standup
<niemeyer> Sorry, omw
<mvo> Chipaca: but +1 for python
<ogra> mvo, mawk doesnt know --sandbox (dont ask why we ship mawk instead of gawk now)
<mvo> ogra: yeah, I'm slightly uneasy without --sandbox, feels to me like going to python is indeed the easiest option
<Chipaca> oh, standup
 * Chipaca runs
<ogra> well, it is definitely a diff towards any normal ubuntu that we dont have gawk
<ogra> jdstrand, mind taking a look at https://bugs.launchpad.net/snappy/+bug/1674509 (specifically my last comment)
<mup> Bug #1674509: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 <Snappy:Confirmed> <linux-raspi2 (Ubuntu):Invalid by p-pisati> <https://launchpad.net/bugs/1674509>
<Son_Goku> zyga, why is it that we don't modprobe squashfs as ExecStartPre for snapd.service?
<ogra> (after checking /proc/filesystems first indeed :P )
<zyga> Son_Goku: mmmm, not sure, I think we used to have that
<zyga> Son_Goku: but I didn't notice it is needed now
<zyga> Son_Goku: I didn't test the cloud variants, just workstation _and_ server though
<zyga> Son_Goku: but good catch, I think we should
<Son_Goku> I guess would squashfs be loaded automatically when you attempt to mount?
<Son_Goku> it would make sense, since you don't really need it if nothing is mounted...
<mup> PR snapcraft#1207 closed: kernel plugin: stop duplicating initrd and image file, use symlinks fâ¦ <Created by piso77> <Closed by piso77> <https://github.com/snapcore/snapcraft/pull/1207>
<Chipaca> zygaâ sprinkled some exception handling to core#24, if you can take another peek
<mup> PR core#24: Rewrite meta/hooks/configure into python3 <Created by mvo5> <https://github.com/snapcore/core/pull/24>
<sborovkov> mvo: I submitted a bug for that btw. https://bugs.launchpad.net/snappy/+bug/1680088
<mup> Bug #1680088: Can't change Pi-config values using snap set command or via REST API <Snappy:New> <https://launchpad.net/bugs/1680088>
<mvo> jibel: looks like http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd is happy again(except ubuntu-image, I did a retry on that, lets see if it was a fluke)
<mvo> sborovkov: thank you! https://github.com/snapcore/core/pull/24 is one possible fix
<mup> PR core#24: Rewrite meta/hooks/configure into python3 <Created by mvo5> <https://github.com/snapcore/core/pull/24>
<mup> Bug #1680088 opened: Can't change Pi-config values using snap set command or via REST API <Snappy:New> <https://launchpad.net/bugs/1680088>
<jibel> mvo, yup, I saw, thanks.
<sborovkov> mvo: understood. Btw why is the full list of config.txt commands not supported? Should not be a lot of code to have them all there
<jibel> mvo, why is 2.23.1 still in -proposed and not 2.23.6?
<jibel> for t, x, y
<mvo> sborovkov: its trivial to extend, we just went a conservative route, happy to add more if you need more
<sborovkov> understood
<mvo> jibel: I have no idea, I suspect because z is not updated yet :/(
<mvo> sborovkov: I'm here for you :) just let me know which one you need, if it's not super dangerous I'm happy to add it
<mvo> (dangerous as in "brick it")
<Son_Goku> zyga, morphis: so I'm going to bump to 2.23.6-4 to add the test for starting socket+timer
<Son_Goku> that will be for F25+ updates
<ogra> mvo, for the moment, no dtoverlay option please ...
<Son_Goku> and I'll simultaneously update snapd-glib to 1.10
<Son_Goku> and drop the karma requirement from +6 to +3
<mvo> ogra: you have veto on the PRs :)
<ogra> (until we have a proper sotry for upgrating dtbs from the kernel snap into gadget)
<ogra> ah, indeed :)
<Son_Goku> for F24, snapd-glib will also be updated, and I will drop the karma requirement to +3 as well
<sborovkov> mvo: haha, alright. I will check if we are using any other options.
<mvo> sborovkov: thank you
<zyga> Son_Goku: we shuold rally more people to give it a try
<jibel> mvo, ah autopkgtest of snapcraft are failing on y & x, and for trusty need to poke the release team
<Son_Goku> zyga: well clearly no one seems to give a damn :(
<zyga> morphis, Son_Goku: we should look at (later perhaps) upstreaming kernel fixes we found recently (not apparomr related) and making them available in fedora as well
<zyga> Son_Goku: I bet people will over time
<zyga> Son_Goku: it's the firs time this is available
<Son_Goku> zyga: if they are merged into mainline tree, you can request them to be backported into Fedora kernels
<zyga> Son_Goku: that's good, I think those will be merged quickly
<zyga> Son_Goku: I can recall bugs in clone and AT_SECURE
<zyga> Son_Goku: and there's one more bug related to clone AFAIR
<Son_Goku> zyga, morphis: all karma has reset on the updates
<Son_Goku> zyga, morphis: https://forum.snapcraft.io/t/call-for-testing-snapd-2-23-on-fedora/127/7?u=conan_kudo
<zyga> Son_Goku: yep, nice :)
<mvo> ogra: I just had a look at the cloud-init thing, how about we merge it and create a new core right away (the usualy sync-lp, create core dance). this way we can verify now that it has no regressions. if that sounds good, could you pull the trigger(s)?
<ogra> mvo, i can indeed ... but given that the self-tests already create a core snap by default, how about we hook up something that makes use of this snap too ;) (will indeed make the tests really long i guess)
<ogra> (not right now, but as a long term plan indeed)
<Son_Goku> wow, I got super lucky
<Son_Goku> I managed to update the updates in time for bodhi mash
<ogra> i'm also not sure if these changes need to go hand in hand with the ubuntu-core-config change that rharper has pending ...
<Son_Goku> davidcalle: if zyga and morphis can rustle up people to test the updates, we might even be lucky enough to release to stable today
<Son_Goku> today/tomorrow
<Son_Goku> zyga, morphis: doc update PR: https://github.com/CanonicalLtd/snappy-docs/pull/60
<mup> PR CanonicalLtd/snappy-docs#60: [DO NOT MERGE YET] Revise content related to Fedora <Created by Conan-Kudo> <https://github.com/CanonicalLtd/snappy-docs/pull/60>
<morphis> Son_Goku: I am on fedora 24 currently
<morphis> and a 26 alpha1 is installing
<Son_Goku> excellent
<morphis> but I see I need to give 25 another try :-)
<morphis> wish we had automation for this already :-)
<morphis> Son_Goku: btw. how do you want to celebrate once we landed snapd? you have a blog you could post a story about this?
<Son_Goku> I don't really have a blog or anything
<Son_Goku> well, I technically do
<Son_Goku> but I haven't updated it since 2009 :)
<Son_Goku> http://pharaohtechblog.blogspot.com/ :P
<fgimenez> zyga https://bugs.launchpad.net/snappy/+bug/1680097 i've updated the test to check for core:network-bind connected after the transition https://github.com/fgimenez/validate_image/pull/6/files
<mup> Bug #1680097: core:network-bind plug is not connected after ubuntu-core -> core transition <Snappy:New> <https://launchpad.net/bugs/1680097>
<morphis> Son_Goku: up to you :-)
<zyga> fgimenez: thank you
<fgimenez> zyga: np thank you!
<mup> Bug #1680097 opened: core:network-bind plug is not connected after ubuntu-core -> core transition <Snappy:New> <https://launchpad.net/bugs/1680097>
<zyga> Son_Goku: I think we should also celebrate with beer and a hangout together
<zyga> Son_Goku: I would love to know if your nintendo switch is getting bent
<zyga> Son_Goku: or if it gets hot while gaming
<Son_Goku> it does get warm, but not "hot"
<Son_Goku> and bent? don't think so
<zyga> Son_Goku: did you see the article on slashdot where some devices started bending about a month after purchase?
<zyga> Son_Goku: looks heat related
<Son_Goku> eek
<zyga> Son_Goku: yes
<zyga> Son_Goku: nintendo WRAP
<mvo> ogra: I'm all for doing more tests
<mvo> ogra: I have no idea if it needs to be synced with the core config change, so maybe worth double checking first
<rharper> ogra: mvo : the core config changes are also needed;  in particular the ubuntu-core-config package will include the ds-identify policy file which configures cloud-init to ensure a datasource is present so it dones't needlessly run
<mvo> ogra, zyga, Chipaca, niemeyer: what do you think needs to happen before https://github.com/snapcore/core/pull/24 can land?  my (biased) opinion is that the python code is more readable and (much) more (unit) tested. but I'm open for concerns, maybe a good forum topic actually?
<mup> PR core#24: Rewrite meta/hooks/configure into python3 <Created by mvo5> <https://github.com/snapcore/core/pull/24>
<mvo> rharper: can we land one before the other or do they need to land strictly in sync? i.e. does landing them out-of-sync break anything?
<Chipaca> mvoâ any reason not to plop it on edge and see how it fares? especially in view of the mgawk thing
<rharper> mvo: no; the final piece would be the snap prepare change which removes the writing of cloud-init.disabled
<zyga> mvo: looking
<mvo> Chipaca: not from my POV :) but I'm (super) biased, I have a thing with shell
<Chipaca> mvoâ you should play with expect for a while
<rharper> as long as that file is present, then cloud-init won't run at all; so the remaining changes won't have an affect for users not enabling cloud-init
<mvo> rharper: great, so we can just land things and eventually fix ubntu-image and it all works
<Chipaca> mvoâ tcl is awesome for making you appreciate the shell
<mvo> Chipaca: lol
<rharper> mvo: there may be some users of gadgets which supply a cloud.conf which could be affected since they wouldn;t have a cloud-init.disabled file in the image created
<mvo> Chipaca: when I did that I was (more than once) abou to rewrite those tests, I did the gpg2 expect stuff and it was a PITA. but I guess nothing compared to your tab completion work
<mvo> rharper: hm, do we have a way to notify them (or know about them)?
<Chipaca> mvo, it's been a learning experience
<Chipaca> it boils down to not a lot of code fortunately
<mvo> Chipaca: a learning experience in zen like stoicism ;) ?
<rharper> not sure; certainly we can poke on mailing list (like devices?)  I don't think their behavior will change if they're supplying cloud-init config (via usb or cdrom, or the nocloud datasource) that all gets detected anyhow
<Chipaca> mvo, well, I didn't know {} were quotes in tcl, for example
<Chipaca> mvo, nor that you grouped things with []s
<rharper> mvo: I was hoping there might be a way to have daily images or something with the changes together
<Chipaca> e.g.: set back1 [string repeat "\b" [string length $::env(_KEY1)]]
<Haxxa> Will snappy packages work under lxc containers in proxmox? I heard their may be some issues present at this time?
<Chipaca> in python that would be: back1 = "\b".repeat(len(os.getenv("_KEY1")))
<Chipaca> close
<zyga> mvo: I'm with you on the bias to drop shell
<rharper> mvo: I've got to run to an appt; but please ping me here with any issues and i'll respond when I get back
<zyga> mvo: python is a much safer and better language for this kind of functionality
<zyga> Chipaca: why did you have to touch tcl?
<Chipaca> zygaâ expect is tcl
<mvo> Haxxa: once https://github.com/snapcore/snapd/pull/3136 has landed lxd should be fine
<mup> PR snapd#3136: snap-confine: add code o ensure that / or /snap is mounted "shared" <Created by mvo5> <https://github.com/snapcore/snapd/pull/3136>
<mvo> rharper: thank you!
<morphis> zyga: how do you feel about https://paste.ubuntu.com/24320508/ ?
<stevehope> I'm trying to learn a bit more about snap packaging and have some time if anyone could use a tester, know some python but snapcraft newcomer
<Haxxa> mvo, wow this is hot of the press indeed - issue I guess it won't find its way into ubuntu for awhile and are their any preconditions for how old a kernel can be? proxmox is based on debian and thus host kernel is pretty old.
<zyga> morphis: note that suse should be fine
<morphis> zyga: yeah, though I didn't tried and we may have to drop the global /snap dir there
<morphis> too
<zyga> morphis: it's just fedora/centos/rhel that need more love
<zyga> morphis: otherwise fine with me
<zyga> morphis: and add "yet" to it
<zyga> morphis: not *yet* supported
<zyga> morphis: I hope we don't have to
<zyga> mvo: I have a few low-priority comments on the python branch
<zyga> mvo: but I honestly didn't read it in depth
<zyga> mvo: so if you plan to push it through serious testing +10
<morphis> zyga: so you think we should leave suse in there?
<morphis> I feel if we move it now closer to inclusion in suse we need to drop the global /snap directory
<zyga> morphis: yes, it should work out of the box today
<morphis> and with that it will stop working
<zyga> morphis: maybe so maybe not
<mvo> zyga: thank you, looking
<fgimenez> jibel: JamieBennett ubuntu-core 1941 (i386) is ok on beta, ready on candidate for validation
<morphis> zyga: ok, so we leave it for now and disable once that happens
<zyga> morphis: s/once/if/
<King_InuYasha> zyga: yes you will have to
<King_InuYasha> the /snap directory is _verboten_ in SUSE
<King_InuYasha> and they don't have an exception process like Fedora does
<zyga> King_InuYasha: you know what they say
<zyga> King_InuYasha: rules are made to be broken :)
<zyga> King_InuYasha: maybe it will not be that much vreboten ;)
<King_InuYasha> well, the only reason rpmlint hasn't been rejecting your builds is because you weren't properly creating and owning /snap in the package
<King_InuYasha> once you do that, OBS will refuse to allow your builds to succeed
<Chipaca> zygaâ os.path.sep is '/', not ':' :-)
<zyga> King_InuYasha: it's like docker I think, where there is will there are means
<King_InuYasha> uhh
<King_InuYasha> no?
<King_InuYasha> with Docker, the paths are changed
<zyga> Chipaca: os.path.pathsep
<zyga> correcting
<King_InuYasha> and the vendoring thing was because of the feud with golang packagers
<zyga> Chipaca: thanks!
<Chipaca> np
<zyga> King_InuYasha: I mean if SUSE really wants to embrace snaps they can allow /snap
<zyga> King_InuYasha: it's entirely within their will
<Chipaca> mvoâ I'm going to pretend you're picking core#24 back up now :-)
<mup> PR core#24: Rewrite meta/hooks/configure into python3 <Created by mvo5> <https://github.com/snapcore/core/pull/24>
<pedronis> Chipaca: there's pathsep, seems a bit overkill (this things won't run on non unix)
<Chipaca> Â¯\_(ã)_/Â¯
<zyga> pedronis: sure but it looks nicer :)
<pedronis> does it?
<pedronis> sep vs pathsep sounds super obscure
<ogra> mvo, well, wh9ile i'm not particulary tied to shell for the config hook (you knwo i prefer it, but i can live with other langs there), i'm particulary sceptical about using python there ... remember that one of the reasons of re-writing snapd in go was that it sucked in python on embedded ... my fear is that the configure hook will easily exceed 100 lines at some point (especially if we add each and every boards gadget config to it over time)
<ogra> and then just kill single core ARM boards with low ram
<ogra> mvo, i wonder  how hard would it be to do it in go instead ?
<mcphail> zyga: are there reasons it needs to be /snap rather than /opt/snap? I've always wondered why the root directory gets polluted like that
<zyga> mcphail: we cannot use /opt/snap everywhere
<zyga> ah, time to run for kids
<shuduo> zyga: hi, i'm reading https://snapcraft.io/docs/core/interfaces and confuse about "Creating an interface" part. To say, The OS snap exposes a number of interfaces to grant snaps access to system functions. You can extend this access by creating your own interfaces.
<zyga> shuduo: hey
<shuduo> zyga: does it mean anyone (end user) can add a new interface to snapd and make it working with all-snap system?
<zyga> brb
<kyrofa> shuduo, no, they must be supported in snapd, so that's saying "you can extend this by contributing your own interfaces" basically
<shuduo> zyga: I suppose we only encourage requesting an interface via bugs.lp.net or submit a PR but always be reviewed by core team, right?
<shuduo> kyrofa: ^
<zyga> shuduo: re
<kyrofa> shuduo, that's the only way, yes
<shuduo> zyga: I suppose we only encourage requesting an interface via bugs.lp.net or submit a PR but always be reviewed by core team, right?
<zyga> shuduo: so the answer is simple: anyone can propose an interface for inclusion and once merged it will make its way to all the users
<shuduo> zyga: kyrofa already answered me. :)
<zyga> shuduo: yes
<zyga> (sorry, I was going to my car)
<shuduo> zyga, kyrofa thanks. one customer is asking "How to write our own interface that could act as a provider(slot) for multiple snaps ?"
<kyrofa> shuduo, it's important to note that not only does the interface need to be supported in snapd, but the application the end-user is using must utilize that interface
<kyrofa> shuduo, indeed, assuming it's not a slot already supported in snapd that they simply need to implement in their snap, they'd need to write and propose it
<zyga> shuduo: it depends on what that interface is about
<zyga> shuduo: we have existing interfaces that can be consumed by many snaps at the same time
<shuduo> kyrofa: so the answer to customer is "no. or you can request it if it's common scenario".
<zyga> shuduo: the best answer is "let's discuss this", it really depends on what you need the interface for
<zyga> shuduo: central review is requred as it is the only way to ensure the system remains secure
<shuduo> zyga: kyrofa. Customer requests "Example use case: Location Service/ Alarm Service in iOS/ Android. â
<zyga> shuduo: we have an interface for location services
<zyga> shuduo: we have no notion of alarm service, you'd have to tell us what permission is needed for it
<shuduo> zyga: is the location interface landed in latest snapd?
<zyga> shuduo: it was there for months, the snap that uses the interface is separate though (it is not provided by core)
<zyga> shuduo: not all interfaces have slots on the core snap
<zyga> shuduo: but all interfaces are defined inside snapd
<shuduo> zyga: so i can't see it from my desktop is expected.
<zyga> shuduo: yes
<kyrofa> zyga, let's say the "alarm service" they want is super wonky and non-generic. Would that still go become a built-in interface, just not implemented by the core snap?
<zyga> shuduo: you should look at the snapd tree, at the interfaces/builtin directory
<shuduo> zyga: got it. thanks!
<zyga> shuduo: also writing an interface is 2nd step, you should just try to do something and see if you need any extra permissions
<kyrofa> zyga, I guess the location service is a bit non-generic in that sense
<zyga> shuduo: if in doubt ask in the forum (forum.snapcraft.io)
<shuduo> zyga: okay. i will.
<zyga> shuduo: good luck
<mvo> ogra: I can create a forum topic to discuss, this way its easier to follow than irc. I'm not aganst go at all, just feels like more work to make the build per-architecture etc
<mvo> Chipaca: yeah, I pick up the python stuff again
<ogra> mvo, well, we're building the core snap pre arch anyway, it could just be part of that ... i just want to go back to the python issues we had before
<ogra> mvo, i commented on the PR btw
<ogra> *i just *dont* want to go back (indeed)
<zyga> mvo: I gave my feedback on the PR now
<zyga> I'll switch to another task
<ogra> zyga, dude ... multi-tasking ...
<ogra> :)
<zyga> ogra: I just *swapped* to my car :)
<ogra> lol
<zyga> the car power adapter works very well though
<zyga> I'm super happy with what I ended up with :)
<mvo> zyga: I addressed some/most
<zyga> mvo: offtopic, I was meaning to ask you: how do you disable touchpad while typing on your laptop?
<mvo> zyga: I totally disabled mine, I only use the trackpad
<zyga> mvo: how did you do that?
<zyga> mvo: I really miss the fn+Fsomething that used to do it on older models
<mvo> zyga: system-settings/mouse&touchpad/touchpad: "off" on the right hand side
<mvo> zyga: yeah, I (much) prefer the old keyboard
<mvo> zyga: I wish there was a model with that, I would buy it instantly
<zyga> mvo: ohh, fantastic :)
<zyga> mvo: I didn't see that option before :)
<zyga> thanks!
<Chipaca> if I make changes to interfaces/apparmor/template.go, is that picked up by the tests somehow?
<zyga> x250 is so far really the best laptop I ever had, by far
<Chipaca> spread tests i mean
<zyga> Chipaca: yes
<zyga> Chipaca: well
<zyga> Chipaca: what do you mean picked up?
<zyga> Chipaca: it gets used
<zyga> Chipaca: if that what you mean
<Chipaca> zygaâ is it used in the core under test?
<zyga> if that's what you meant
<zyga> yes because we swap snapd with the one we built
<zyga> and we refresh security on startup
<zyga> Chipaca: and even if not, we install snaps in each test so it does get used
<mup> PR snapd#3143 closed: data/systemd: tweak data/systemd/Makefile to be slightly simpler <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3143>
<zyga> pedronis, mvo: https://github.com/snapcore/snapd/pull/3140
<mup> PR snapd#3140: overlord: fix TestEnsureLoopPrune not to be so racy <Created by zyga> <https://github.com/snapcore/snapd/pull/3140>
<zyga> I can do the 2nd test as a separate branch on top, this will help people with random failures already
<mvo> zyga: nice work
<zyga> mvo: all the credit goes to pedronis :)
<zyga> mvo: I just pasted and studied that code
<mup> PR snapd#3096 closed: many: abstract path to /bin/{true,false} <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3096>
<morphis> mvo: thanks!
<mvo> morphis: thank oyu
<mvo> you
<mup> PR snapd#3144 opened: overlord,release: disable classic snap support for fedora/rhel/centos <Created by morphis> <https://github.com/snapcore/snapd/pull/3144>
<morphis> mvo, zyga: ^^
<morphis> mvo: can you tag that one for 2.24?
<morphis> only if you guys agree
<mvo> morphis: done
<morphis> mvo: thanks
<zyga> shuduo: I replied on the forum
<zyga> morphis:looking
<morphis> zyga: adding a test case for snapstate.go still
<Pharaoh_Atem> morphis, zyga: I can practically guarantee that suse will flip from true to false if we want it to get into Factory
<zyga> morphis: have a look
<zyga> Pharaoh_Atem: let's not use our crystall balls (sic!) yet :)
<zyga> Pharaoh_Atem: once we get there
<Sky_> Hi everyone,  I just want to know how to run the snaps
<morphis> zyga: updated
<zyga> Sky_: hey, snap install hello-world; hello-world
<Pharaoh_Atem> zyga: I don't need a crystal ball
<Pharaoh_Atem> you shouldn't assume optimism for this
<zyga> Pharaoh_Atem: but you cannot say what SUSE the company will do
<Sky_> Then I get hello 2.10 from 'canonical' installed
<Pharaoh_Atem> suse the company doesn't care, but opensuse the distribution does
<zyga> Sky_: then run hello-world
<Pharaoh_Atem> they're unlikely to include snapd in sle13
<zyga> Sky_: you've just ran your first snap :)
<zyga> Pharaoh_Atem: I think we are fine where we are now, let's not worry too much
<zyga> morphis: did you push? I don't see any changes
<morphis> zyga: refresh, jsut added the snapstate test case
<morphis> other fixes are coming
<zyga> morphis: ah, great
<Pharaoh_Atem> morphis: added comments
<morphis> zyga: check again
<zyga> morphis, Pharaoh_Atem commented again
<zyga> sorry for not realizing this earlier
<ogra> rharper, did you see my comment in the mail i CCed you on ? could you move your MP from the bzr tree of ubuntu-core-config to https://github.com/snapcore/core-build ?
<zyga> is it reali-z-ing or reali-s-ing
<morphis> zyga: good point
<Pharaoh_Atem> realizing
<zyga> ah, thanks :)
<ogra> i think depends on the dictionary you use ;)
<Pharaoh_Atem> unless your a barmy British idiot, then it's "realising"
<Pharaoh_Atem> :)
<Pharaoh_Atem> s/your/you'
<Pharaoh_Atem> s/your/you're/
<zyga> Pharaoh_Atem: maybe after brexit UK will adopt US englishg
<Pharaoh_Atem> haha
<ogra> lol
<Pharaoh_Atem> well, ours was the original English
<ogra> suuure ... thats why they left after all ... to be more american :)
<Pharaoh_Atem> they de-emphasized /z/ in UK English and writing to be more French
<popey> Oi!
<Pharaoh_Atem> though in contemporary UK English, /z/ is present in most dialects, and leaks in to Received Pronounciation from time to time
 * ogra gets the popcorn
<Pharaoh_Atem> they still spell with "s" though, as a holdover from the Victorian era
<mcphail> Pharaoh_Atem: I'm sure it was just an Oxford/Cambridge thing
<Pharaoh_Atem> prior to the Victorian era, it was somewhat mixed
<Pharaoh_Atem> Scots and Irish used spelling familiar to Americans, as their accents used /z/ and even today that remains the case for speech
<Pharaoh_Atem> English and Welsh were mixed, though the affluent sections of England used the current UK English spellings more often
<morphis> zyga: ok, this gets a bit more tricky, dirs and release have a dependency on each other
<zyga> morphis: oooh :)
<zyga> morphis: have fun untangling that
<morphis> hah :-)
<zyga> morphis: but I think that's the correct solution for this problem
<zyga> morphis: you can move some logic so that deps go one way
<morphis> yeah, I think I know what I do
<morphis> I make the logic part of dirs so its a CurrentDirConfigSupportsClassicConfinement-thing
<morphis> as that is what it really is
<morphis> its not a distro specific thing its a setup thing
<ogra> ooooh !
<ogra> the electron forum app actually integrates with the desktop notifications of unity8 properly Â°!
<Pharaoh_Atem> that's... terrifying
 * ogra just got a proper notification for a reply on the forum ... so awesome
<zyga> ogra: oooh
<zyga> ogra: I need to try that
<zyga> ogra: does it work on fedora?
<ogra> zyga, no idea, i never used fedora in my life
<zyga> ogra: really?!
<zyga> ogra: why not, try it :)
<zyga> ogra: at least a VM
<ogra> RH 4.2 was the last redhat product i used
<ogra> since then i never had to touch any
<zyga> ogra: some nice things there
<zyga> ogra: look at fedora server booting, really beautiful and fast
 * zyga breaks from coding and goes to read the forum
<zyga> niemeyer: for all the experiments we did as a team the forum is by far the clearest 'win-win' we did
<zyga> pedronis: can I merge https://github.com/snapcore/snapd/pull/3140 now?
<mup> PR snapd#3140: overlord: fix TestEnsureLoopPrune not to be so racy <Created by zyga> <https://github.com/snapcore/snapd/pull/3140>
<zyga> (when green, I'm asking if you can +1 it(
<morphis> zyga: check again
<mup> PR snapcraft#1235 opened: Store API interactions for developer collaboration  <Created by psivaa> <https://github.com/snapcore/snapcraft/pull/1235>
<zyga> aha
<zyga> morphis: look again
<zyga> morphis: +1 overall
<morphis> zyga: thanks!
<niemeyer> zyga: +1!
<niemeyer> Wait.. I mean, ..
<niemeyer> zyga: Indeed, the experiment is working well.. I didn't mean to +1 some PR :)
<zyga> niemeyer: haha OK :)
<zyga> niemeyer: it's just so great to see lots of people flock to the forum
<niemeyer> Yeah, it's just so much nicer to learn about what's going on and to talk to people this way
<zyga> niemeyer: about our discussion on security
<zyga> niemeyer: http://source.android.com/security/bulletin/2017-04-01.html
<zyga> niemeyer: that's a crazy baaaaaaaaaad list to be in
<zyga> niemeyer: I think we need to find the right way forward
<rharper> ogra: I can move it to core-build
<ogra> rharper, thanks !
<niemeyer> zyga: Indeed
<zyga> garage
<zyga> checking if 3G works here
<mup> PR core-build#5 opened: Update cloud-init configuration <Created by raharper> <https://github.com/snapcore/core-build/pull/5>
<pedronis> zyga: it failed on the job taking too much in general :/
<pedronis> IÂ have seen that happen more, haven't looked if it's machine allocation or something else
<zyga> pedronis: yes, we have many tests sometimes
<zyga> pedronis: that's all right, it is another cause of failure we know about
<Chipaca> how is apparmorspeak for "can read stuff in this directory"?
<Chipaca> (where stuff are shell scripts)
<zyga> Chipaca: mmm
<zyga> Chipaca: /path/to/dir/** r,
<zyga> Chipaca: note that you may need /path/to/dir/ r, as well
<zyga> (try)
<Chipaca> zygaâ ** means all subdirs also, no?
<mup> PR snapd#3145 opened: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145>
<zyga> Chipaca: yes
<zyga> Chipaca: if you just want stuff in one dir use one star
<zyga> mvo: not sure if still around: https://github.com/snapcore/snapd/pull/3145
<mup> PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145>
<zyga> mvo: I think we want this for 2.24
<zyga> we should close 2.23.6 milestone
<zyga> Chipaca: can you have a look at that too, I bet the switch code can be simplified but I had no idea how
<Chipaca> zygaâ what's the deadline for branches for this release?
<Chipaca> is it 20 minutes ago?
<zyga> Chipaca: welll
<zyga> mvo: what is it?
<zyga> (I think we want this branch, it may break people upgrading)
<Chipaca> i was asking for mine, not for yours -- mine is still too far away i fear :-(
<zyga> Chipaca: oh, which one is that
<zyga> Chipaca: can I help with review?
<Chipaca> zygaâ completion
<Chipaca> zygaâ was racing to get it out today, but alas
<dougquaid> I'm having problems with mongo and rocketchat installed via snap. Where can I find their logs? They're not in the usual /var/log
<Chipaca> dougquaidâ they'll be under /var/snap/
<dougquaid> thanks
<Chipaca> I'm going to go for a run, see if I find a different approach to this
<dougquaid> I guess rocketchat-server doesn't have a log file. All I see in /var/snap/rocketchat-server is its mongo database files
<Chipaca> dougquaidâ I don't have rocketchat here (and i'm about to leave for a bit), but if you know the rocketchat unit name you can get the logs
<Chipaca> dougquaidâ try:
<Chipaca> systemctl | grep rocket
<Chipaca> that should get you the unit names
<Chipaca> then, journalctl -u <the unit>
<Chipaca> should get you the logs
<dougquaid> awesome, thanks
<dougquaid> systemctl | grep rocket retured 5 unit names, but journalctl -u on each of the 5 units returned no entries
<zyga> Chipaca: good luck
<zyga> dougquaid: are you on 14.04?
 * zyga EODs for now
<dougquaid> zyga: 16.04
<dougquaid> My problem is that rocketchat won't start. Here's systemctl status: https://pastebin.com/D6mZktxV
<pedronis> niemeyer: getting issues with tests taking too long quite frequently https://travis-ci.org/snapcore/snapd/builds/218925359
<zyga> dougquaid: I'm sorry I cannot help you today, I need to take a break now
<dougquaid> zyga: no problem
<mup> PR snapcraft#1234 closed: core: find the correct libraries as a snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1234>
<pepe__> hi, I have a basic question while researching if snap fits our needs. Can it be used to package configured apps like an apache web server + mysql DB + perl web app? Anyone did this?
<nacc> pepe__: well owncloud is snapped
<pepe__> nacc: thanks! will look into it.
<nacc> pepe__: that seems like the closest to what you described, to me
<nacc> pepe__: np
<ogra> nacc, is it ? i thought nextcloud was snapped ;)
<nacc> err, maybe i meant nextcloud :)
<nacc> *cloud :)
<ogra> heh
<niemeyer> pedronis: That's definitely due to the merge of unit tests into spread
<niemeyer> pedronis: We've padded our tests by 6-8 minutes on amd64 due to that
<zyga> niemeyer: I wonder if we can run on VMs with less RAM now
<zyga> niemeyer: and just run more of them
<niemeyer> No, we can't
<niemeyer> zyga: We need more than a machine needs to just run it
<chani_> hi guys a question is it possible to install snaps in docker containers
<zyga> chani_: hi, I don't believe I tried; we recently made it possible to install snaps in LXD so it's definitely possible but I don't know if docker and snapd connected all the pieces
<zyga> chani_: it also depende on the docker host (kernel)
<chani_> cool
<zyga> chani_: if you try please share your experience here: https://forum.snapcraft.io/
<chani_> yeah sure
<chani_> i have tried to install snap on docker with host as ubuntu 16.04 but no luck
<chani_> i was getting this error
<chani_> 2017/04/05 19:19:19.113943 main.go:220: WARNING: cannot create syslog logger error: cannot communicate with server: Post http://localhost/v2/snaps: dial unix /run/snapd-snap.socket: connect: no such file or directory
<chani_> zyga: by the way have you documents the process with LXD some where
<zyga> chani_: I think it was blogged about frequently a few weeks ago when it went live
<zyga> chani_: technically some kernel features were needed (stacked apparmor)
<zyga> chani_: and some integration points between lxd and snapd
<zyga> chani_: what happens when you "sudo systemctl start snapd"
<chani_> zyga: it says no such file or directory
<zyga> chani_: oh, that's curious
<chani_> zyga: "Failed to connect to bus: No such file or directory"
<zyga> chani_: so your host is ubuntu 16.04?
<zyga> chani_: and the guest? same?
<chani_> yes
<zyga> chani_: ok, I'd suggest opening a forum topic
<chani_> yes both are 16.04
<zyga> chani_: I bet we'll get to the bottom of it
<zyga> chani_: but I was about to close my laptop and read a book now (it's late)
<chani_> thanks zyga
<zyga> chani_: and the forum has more feedback from diverse timezones
<zyga> chani_: I think stgraber may help out as he is the lead dev of lxd
<zyga> chani_: and I bet the rest of the snapd team will be eager to help too :)
<chani_> zyga: oh thats good to hear
<chani_> zyga: thanks again i will open a thread on forms
<niemeyer> pedronis, zyga: I'll take a break outside now, and will be back later to dive into PRs and see what I can do to bring the total execution time down again
<zyga> niemeyer: thanks, enjoy the rest of the sunshine :)
<mup> PR snapd#3140 closed: overlord: fix TestEnsureLoopPrune not to be so racy <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3140>
<mcphail> sabdfl: Is the plan for snaps to use Wayland? Can this offer the same containment as Mir? Or are we going to be using X for the immediate future? Curious to know how much to invest in snaps, but much less enthused if we are going to be relying on X
<kyrofa> mcphail, that may be a better forum topic
<mcphail> kyrofa: yes, maybe you're right
<nacc> is it possible to tell me what/who is reserving the 'usd' snap?
<kyrofa> nacc, I doubt it, but you can submit a complaint if you think you should have it
<kyrofa> Dispute rather, heh
<nacc> kyrofa: ok
<nacc> "We can rename snaps to ensure their names match the expectations of most users. If you feel that needs to happen please fill a dispute by filling this form"
<kyrofa> Yep, that one
<nacc> where "this form" is not a link and is on the page for registering the snap
<nacc> so ... no form :)
<nacc> oih i see the page changed
<nacc> subtle
<mup> PR snapcraft#1210 closed: Add platforms for the nightly tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1210>
<mup> PR snapcraft#1236 opened: snap: use the gpg tarball instead of git:// <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1236>
#snappy 2017-04-06
<_28Kb> i wonder why snapcraft is only available as apt and not as snap too
<jrwren> _28Kb: IIRC it is available as a snap too.
<_28Kb> snap find snapcraft finds nothing
<jrwren> for some reason it isn't in the store. Maybe it is not stable. There are snaps here: https://launchpad.net/~sergiusens/+snap/snapcraft  It was announced here: https://lists.ubuntu.com/archives/snapcraft/2017-March/003711.html
<jrwren> Probably best to stick to using it from xenial-updates as it says here: https://snapcraft.io/create/
<_28Kb> it's ok.. I'm trying this apt version.. result should be the same > make my own snap :)
<mup> PR snapd#3144 closed: overlord,release: disable classic snap support when not possible <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3144>
<mup> PR snapd#2982 closed: daemon: add desktop file location for app to the API <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2982>
<morphis_> mvo: thanks!
<morphis_> mvo: I have one other PR in a bit which would be nice to get into 2.24
<mvo> morphis_: sure, happy to review
<morphis_> need to make snap-confine building fine on i386 on other distros
<morphis_> mvo: btw. does QA do any testing of snapd on debian when we do releases?
<mvo> morphis_: thats up to the debian maintainers
<morphis_> I see
<mvo> morphis_: we as a team don't do any currently, but I would love to fix that
<mvo> morphis_: i.e. having a spread debian machine
<morphis_> right, that is what I think I will look into next as debian is the next natural target for this after Ubuntu
<morphis_> mvo: https://github.com/snapcore/snapd/pull/3146
<mup> PR snapd#3146: cmd: explicitly set _GNU_SOURCE and _FILE_OFFSET_BITS for xfs support <Created by morphis> <https://github.com/snapcore/snapd/pull/3146>
<mup> PR snapd#3146 opened: cmd: explicitly set _GNU_SOURCE and _FILE_OFFSET_BITS for xfs support <Created by morphis> <https://github.com/snapcore/snapd/pull/3146>
<morphis_> Son_Goku: ^^
<jibel> morphis_, I've jenkins jobs running spread tests on debian sid for releases
<jibel> morphis_, but it is not really useful right now since lot of tests are failing due to confinement
<jibel> morphis_, it's pretty straightforward to run on debian with autopkgtest
<mup> PR snapcraft#1236 closed: snap: use the gpg tarball instead of git:// <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1236>
<morphis_> jibel: nice!
<morphis_> jibel: do you have some instructions?
<jibel> morphis_, yeah, I can show you the code
<jibel> morphis_, school run, back in 15min and I'll show you
<morphis_> jibel: ok, just ping me
<oops> hi, is there a guide for setting up a caching proxy for snapstore like apt-cacher for debs?
<zyga> good morning
<zyga> oops: hey, not yet but it should be doable
<zyga> oops: I was pretty interested in that actually but I didn't get to try anything
<zyga> oops: snapd respects proxy settings so it might be possible to build a specialized proxy that just caches snaps / assertions
 * zyga looks at PRs
<zyga> mvo: thank you for updating the /snap sharing PR, looking at it now
<zyga> mvo: let me see if I can help with locking
<jibel> morphis_, re-spread on debian, for lack of better documentation, the code to create the VM, run the tests are there http://bazaar.launchpad.net/~canonical-platform-qa/snapcore-qa-tests/trunk/files/head:/cross-distro/Debian/
<jibel> morphis_, and the job definition to deploy in Jenkins is there http://bazaar.launchpad.net/~canonical-platform-qa-jenkins/qa-jenkins-jobs/trunk/files/head:/jobs/snapcore-qa-tests/
<jibel> morphis_, basically, there is a script called create_debian to create the testbeds
<jibel> morphis_, then an wrapper around autopkgtest to run the tests from git or the deb package
<fgimenez> hi mvo we got the same errors in the latest 2.21 -> edge reexec scenario https://travis-ci.org/snapcore/spread-cron/builds/219142686 if you could take a look when you have a minute that would be great (no rush at all), this execution was triggered after the last core snap was published to edge this morning (uses that snap for the test)
<zyga> jibel, morphis_: I'd love to get some debian love here: https://github.com/zyga/spread-qemu-images
<mvo> fgimenez: hm, I have a look - strange
<morphis_> jibel: thanks!
<morphis_> zyga: will have a look
<mvo> jibel: just a FYI, zesty needs a 2.23.6ubuntu1 upload with a tiny diff for cloud stuff, I am preparing this now. should not afffect anything else but zesty
<mvo> fgimenez: aha, we have snapd FTBFS currently in the PPA, this is why the tests fail
<fgimenez> mvo: great thank you! we can retrigger the test when snapd builds correctly, or just wait for the next core publication to edge
<mvo> fgimenez: its slightly mysterious why it fails, given that it builds fine in spread (regular spread)
<mvo> fgimenez: I'm still looking at this (sort of, next, some more stuff is pending right now :/)
<fgimenez> mvo: ok thanks let me know if i can be of any help
<mvo> zyga: re locking> adding it is fine with me, maybe extracting the lock code from the ns_initialize thing as a helper and put it around the /snap bind mount code?
<zyga> i.e.: re
<zyga> mvo: yes, I think that is desirable, I was thinking about host_support module where we have a function that initializes the host
<zyga> mvo: (with a way to pass a set of functions to call)
<pedronis> zyga: have you started working on the other Prune test ? otherwise IÂ can work on that
<mvo> zyga: lets keep it simple for now
<zyga> pedronis: yes but I didn't finish, if you can wait I could try to finish and let you review it
<pedronis> ok
<zyga> mvo: very simple, just one varadic function that grabs the lock and processes a NULL terminated argument list of functions to call
<zyga> mvo: then it doesn't have to live in one module
<zyga> mvo: and it should be easy to adjust the existing code
<zyga> mvo: what do you think?
<mvo> zyga: that will work. I was thinking about lock_for_snap(snapname); ensure_snap_shared_mount(); unlock_for_snap(snapname); but maybe thats too simplistic
<mvo> zyga: and extract the locking into that lock_for_snap() (or whatever name)
<Chipaca> ogra_â you around?
<mvo> zyga: but again, you know that part way better so feel free to adjust
<zyga> mvo: let me make something quickly and share that with you
<ogra_> Chipaca, sure
<Chipaca> ogra_â sorry to bother you :-) but, did you see the email about gpio pins on the rpi?
<mvo> zyga: sure
<mvo> zyga: thank you!
<Chipaca> ogra_â it's a reply to an email from the prehistoric past (~january)
<ogra_> Chyeah, i see it ... nothing changed, we cant upgrade the gadget on the pi yet ... only edge works
<Chipaca> ogra_â it being in edge is a change over your last email though (where you say you'll put it in edge)
<ogra_> right
<Chipaca> ogra_â want to reply, or would you rather i did?
<ogra_> ogra@pi3:~$ snap interfaces | grep -c gpio
<ogra_> 27
<ogra_> (on edge)
<Chipaca> :-) cool
<Chipaca> maybe we could use tracks as a workaround until we let gadgets upgrade?
<Chipaca> anyway, was just worried that email would get lost in the deluge
<Chipaca> (if your inbox is as busy as mine is todya, it's very busy)
<ogra_> yeah, same here but well enough structured that i dont miss mails ;)
<Chipaca> my filters are usually quite good, but failed me on this :-)
<Chipaca> and it's all so interesting /o\
<ogra_> oh, wait ... he says debian armhf
<ogra_> sounds like he runs a classic debian install with snapd on it
<ogra_> there you wont have these interfaces indeed ... only what snapd delivers
<Chipaca> unless they've gone and built a debian-based core + gadget?
<Chipaca> doubt it though
<ogra_> yeah, highly
<ogra_> they would have to mix in the PPA packages to even have it booting
<ogra_> that would be a messy image i guess
<nanodrone> since canonical is killing unity/convergence, does that mean ubuntu core and snappy will die too?
<morphis_> zyga: you have time to give the fedora packages another spin today?
<morphis_> nanodrone: no
<nanodrone> why do yall have an '_' next to your names right now?
<Chipaca> nanodroneâ the opposite if anything
<morphis_> nanodrone: read the announcement https://insights.ubuntu.com/2017/04/05/growing-ubuntu-for-cloud-and-iot-rather-than-phone-and-convergence/
<Chipaca> nanodroneâ snappy and ubuntu core are the IoT in âgrowing Ubuntu for cloud and IoTâ
<nanodrone> OH!
<nanodrone> that's awesome.
<Chipaca> nanodroneâ :-)
<nanodrone> what DE do you guys use?
<fgimenez> hey Chipaca, i have this wip branch https://github.com/snapcore/snapd/compare/master...fgimenez:expect-snap?expand=1 for using the expect snap in snapd's suite and enable a bunch of tests on ubuntu-core systems, currently there are 3 failing tests http://paste.ubuntu.com/24326565/ could you please have a look when you have a moment?
<Chipaca> fgimenezâ sure!
<Chipaca> right now i need to take a break because the washing machine just finished :-)
<fgimenez> Chipaca: thx np! :)
<zyga> morphis_: yes
<morphis_> zyga: thanks
<Chipaca> nanodroneâ I use unity 7. I have a couple of fallbacks (I'd have to dig into backups to find my xmonad config, but it's there), but I'm really used to the super+N for switching :-)
<nanodrone> what super+N switching !!
<Chipaca> nanodroneâ "windows key" + a number, to switch to that number app?
<Chipaca> the windows key is called "super"
<Chipaca> (because of the space cadet keyboard)
<nanodrone> no i know that but is it on unity?
<Chipaca> nanodroneâ if you're in unity 7 now, press and hold super
<nanodrone> i switched to ubuntu-gnome-desktop like yesterday.
<Chipaca> hah
<nanodrone> it does have an extension that lets you switch like that. between windows and workspaces.
<Chipaca> nanodroneâ you dock the apps on the launcher, and then super+<the position in the launcher> switches to that app
<mvo> fgimenez: where is the script that does the auto-importing/creating for the vendor branch?
<Chipaca> anyway. that washing crumpling as i sit here and chat
 * Chipaca runs
<nanodrone> i'm gonna miss the unity touch handles :( :(
<mup> PR snapcraft#1237 opened: repo: enable elementary <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1237>
<fgimenez> mvo: it's this spread task https://github.com/snapcore/spread-cron/blob/snapd-vendor-sync/target/tasks/snapd-vendor-sync/task.yaml it is executed by spread-cron after every merge to snapd's master + green build
<mvo> fgimenez: it looks like for some reason the makefile in data/systemd is missing
<mvo> fgimenez: and I know why
<mvo> fgimenez: I will let you know, thanks for the file
<fgimenez> mvo: np, thank you, plz ping me if the sync task needs any tweaking
<mvo> fgimenez: PR is on the way, its our silly .gitignore it seems
<mup> PR snapd#3147 opened: git: ignore only the cmd/Makefile{,.in} <Created by mvo5> <https://github.com/snapcore/snapd/pull/3147>
<mvo> fgimenez: -^
<mup> PR snapcraft#1233 closed: docs: update contribution guide <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1233>
<Chipaca> âcannot open mount namespace of the init process: Permission deniedâ
<Chipaca> zygaâ does that mean anything in any language I may speak? :-)
<zyga> Chipaca: it says that you ran into the kernel bug and we are running reassociate fix somehow
<zyga> Chipaca: I think this got disabled, maybe the branch is still unmerged
<zyga> Chipaca: looking
<Chipaca> fgimenezâ how is the expect snap getting installed? I don't remember if it's classic or devmode or what
<fgimenez> Chipaca: it's installed with --devmode in the tests, this is the snapcraft.yaml file http://bazaar.launchpad.net/~snappy-dev/snappy-hub/expect/view/head:/snapcraft.yaml
<zyga> mvo: can you fetch my remote and look at the locking brnach please
<zyga> Chipaca: it's merged
<zyga> Chipaca: so if you see that this is old snap-confine
<Chipaca> zygaâ how old?
<zyga> Chipaca: aha, and we maaaay be just affected by lack of run-from-core on snap-confine
<Chipaca> zygaâ fgimenez is getting it a lot in http://paste.ubuntu.com/24326565/
<zyga> Chipaca: current :/
 * zyga looks 
<Chipaca> when using expect form a snap to run things from other snaps
<zyga> Chipaca: I think we're lucky actually, it seems that 2.23.6 did not have any re-associate code ye
<zyga> Chipaca: aaah
<zyga> Chipaca: yes
<zyga> Chipaca: that will happen then
<zyga> Chipaca: that's what I was fixing but then we ran into kernel woes
<zyga> Chipaca: you need to put that on hold until we get a new kernel in 6 weeks
<Chipaca> fgimenezâ ^ :-/
<zyga> mvo: have a look
<zyga> mvo: if you agree with the direction I can work on the TODOs and propose this
<mvo> zyga: where should I look?
<zyga> mvo: in my remote, in the 'locking' branch please
<zyga> mvo: or here https://github.com/snapcore/snapd/compare/master...zyga:locking?expand=1
<fgimenez> Chipaca: zyga ok thanks a lot, will wait then, i was getting also a kernel dump on syslog but it is not showing up anymore
<mvo> zyga: ta
<zyga> mvo: have a look at snap-confine.c changes
<Chipaca> fgimenezâ sad panda
<zyga> Chipaca: me too :/
<fgimenez> Chipaca: np :) i'm realizing now that tests/main/completion, which was also failing, is calling "snap create-key", which gets stuck on ubuntu-core systems, i'll skip it too and wait for the new kernel to be out
<mvo> zyga: I'm too simple for this, it looks nice and yet I would still prefer sc_lock(), sc_unlock() over this. sorry, maybe someone who enjoys C more should have a look and give feedback
<zyga> mvo: if you do that you need to pass state to unlock
<zyga> mvo: it's harder
<zyga> mvo: why do you want that?
<mvo> zyga: the state would be the lock_fd?
<zyga> mvo: yes
<mvo> zyga: I want it mostly because it feels simpler and I like simple. but again, I may just be the wrong person for this
<zyga> mvo: you also have the "scope" which lets us use one function for everything
<zyga> mvo: whatever we do, I'll -1 the share code without locking
<mvo> zyga: sure, I understand that. but sc_lock(); sc_initialize_ns_groups();sc_unlock(); also is in a single scope and feels simpler.
<zyga> mvo: so feel free to modify this or suggest changes
<mvo> zyga: sure, thats totally fine
<mvo> zyga: I will ponder a bit over the locking
<zyga> mvo: locking is two-fold
<zyga> mvo: we have gobal locking
<zyga> mvo: and per-snap locking
<mvo> zyga: yes, for this we need the global lock, right?
<zyga> mvo: yes
<mvo> zyga: and do we have global locks already?
<zyga> mvo: though the way I coded it it is holding the global lock longer, I think I could release it separately
<zyga> mvo: only the one in namespace initialization code
<zyga> mvo: if we carry on with my proposal all those locks get removed
<mvo> zyga: ok, so that would have to be extracted into a helper?
<zyga> mvo: hmm? no
<zyga> mvo: the helper is the new function
<zyga> mvo: everything else just gets simplified, remove all the other locks
<zyga> mvo: I pushed a small simplification so that locking is clearer
<zyga> mvo: I can show you what I mean
<zyga> mvo: e.g. on the sc_initialize_ns_groups
<zyga> mvo: do you want that?
<mvo> zyga: one question first - is it always acquiring a global lock?
<zyga> mvo: yes
<mvo> zyga: hm, I think I need to read this carefully then, I think I don't understand it
<zyga> mvo: with global_lock(): do_global_init; with snap_lock(snap_name): do_snap_init(snap_name);
<zyga> mvo: note that this is true both now (as is) and with this proposal
<zyga> mvo: we always grab the global lock to unshare /run/snapd/ns
<zyga> mvo: that python-ish example missed one important point
<mvo> zyga: aha, so NULL in sc_call_while_locked() means global lock?
<zyga> mvo: with global_lock(): \t do_global_init; \n with snap_lock(snap_name): \t do_snap_init(snap_name);
<zyga> mvo: yes
<zyga> mvo: (we can hold the global lock for a shorter amount of time)
<mvo> zyga: thanks, I understand the code now, I'm just not liking it, again, don't get me wrong, nothing is "wrong". its just does not feel right to me, but I get back to the branch and look at it with fresh eyes in a little bit
<zyga> mvo: if you want I can split the helper to lock/unlock
<zyga> mvo: just ensuring it is used correctly gets slightly harder
<zyga> mvo: but I can quickly do that if you prefer
<mvo> zyga: for my PR I would love to have that, yes. there could be a followup that uses the context manager and people who enjoy C more could then weight in and give their opinion
<mup> PR snapd#3148 opened: errtracker: never send errtracker reports when running under SNAPPY_TESTING <Created by mvo5> <https://github.com/snapcore/snapd/pull/3148>
<zyga> mvo: look again please
<zyga> mvo: I can now look at removing the redundant locking
<zyga> mvo: I should also port the sanity timer code to locking.[ch]
<zyga> mvo: so that we never hang while holding the lock
<zyga> mvo: er, not holdin, trying to grab it
<zyga> fg
<morphis_> zyga: can you approve https://github.com/snapcore/snapd/pull/3146 too?
<mup> PR snapd#3146: cmd: explicitly set _GNU_SOURCE and _FILE_OFFSET_BITS for xfs support <Created by morphis> <https://github.com/snapcore/snapd/pull/3146>
<zyga> morphis_: done
<morphis_> zyga: thanks
<mup> PR snapd#3146 closed: cmd: explicitly set _GNU_SOURCE and _FILE_OFFSET_BITS for xfs support <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3146>
<joedborg> o/
<joedborg> has anyone got any pointers for snapping Qt guis?
<joedborg> I get seg faults in strict and no fonts in classic
<zyga> mvo: any feedback?
<zyga> joedborg: nope, sorry :/
<mvo> zyga: let me check
<nanodrone> Chipaca, https://extensions.gnome.org/extension/413/dash-hotkeys/
<joedborg> I think it's this bug https://bugs.launchpad.net/snappy/+bug/1621568
<mup> Bug #1621568: Unable to access system fonts <snaps-interface> <Snappy:New> <https://launchpad.net/bugs/1621568>
<mvo> zyga: yes, I like it, I would also remove the bits that are not needed yet (and you can reintroduce later), i.e. sc_call_while_locked() is not yet used afaict and also the typedef for sc_locked_fn. but I can also do that if you want, the lock helper is what I wanted :)
<zyga> mvo: I'm on it
<zyga> mvo: I'll remove locking elsewhere
<mvo> zyga: thank you!
<zyga> mvo: just finishing tests
<Chipaca> nanodroneâ hope springs eternal, etc
<Chipaca> so... for this branch, I need the changes in the branch to be "inside" the core
<Chipaca> currently running tests with --debug, and bind-mounting inside there, works
<nanodrone> no idea what you mean Chipaca
<Chipaca> nanodroneâ the two sentences after 'hope springs eternal' weren't about unity vs gnome :-)
<Chipaca> nanodroneâ if your question is about 'hope springs eternal', https://en.wikipedia.org/wiki/Hope_Springs_Eternal
<nanodrone> thanks
<Chipaca> np
<Chipaca> as I was saying :-)
<nanodrone> thanks for being patient with my englisch
<Chipaca> i need to have the stuff from this branch in-core
<Chipaca> is there already a helper for this, or do i bind-mount in prepare/umount on restore?
<zyga> mvo: ok look again please
<zyga> mvo: https://github.com/snapcore/snapd/pull/3149
<mup> PR snapd#3149: cmd: make locking around namespaces explicit <Created by zyga> <https://github.com/snapcore/snapd/pull/3149>
<mup> PR snapd#3149 opened: cmd: make locking around namespaces explicit <Created by zyga> <https://github.com/snapcore/snapd/pull/3149>
<pedronis> Chipaca: for whom is that question?
<zyga> pedronis: I can now go back to the 2nd test
<pedronis> Chipaca: we do build a core in our tests and stick some stuff in it
<pedronis> Chipaca: do you need a pointer?
<pedronis> IÂ mean spread tests
<mvo> zyga: this line https://github.com/snapcore/snapd/compare/master...zyga:locking?expand=1#diff-5819ab7ed3c9b218d0b74c369e621862R114 looks a bit odd, why the "void " in front?
<zyga> mvo: ah, copy paste error
<zyga> mvo: (that's the function definition actually)
<mup> PR snapd#3147 closed: git: ignore only the cmd/Makefile{,.in} <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3147>
<zyga> good catch :)
<mvo> zyga: thanks
<Chipaca> pedronisâ I'll take a look
<Chipaca> pedronisâ i'm not sure they were for anybody in particular :-)
<Chipaca> sometimes i just need to ask for the brain to kick in
<mvo> zyga: I suspected that. can I also have a #define SC_LOCK_GLOBAL NULL or ideally without #define? so that I can write sc_lock(GLOBAL) instead of sc_lock(NULL) :) ?
<zyga> mvo: trivial review on https://github.com/snapcore/snapd/pull/3148
<mup> PR snapd#3148: errtracker: never send errtracker reports when running under SNAPPY_TESTING <Created by mvo5> <https://github.com/snapcore/snapd/pull/3148>
<mvo> zyga: ta
<mvo> zyga: yeah, thank you! I will fix the typo
<zyga> mvo: maybe a trivial function sc_lock_global() instead?
<mvo> zyga: sure, works as well
<zyga> mvo: I'll add one
<mvo> ta
<pedronis> Chipaca: see update_core_snap_for_classic_reexec  and setup_reflash_magic  in tests/lib/prepare.sh
<zyga> mvo: done
<pedronis> Chipaca: this could be a forum topicy IÂ suppose,  "How do we ensure we use the branch bits in spread tests"
<Chipaca> pedronisâ good idea. i'll do that.
<Chipaca> pedronisâ also i think i'll change update_core_snap_for_classic_reexec to copy all of /usr/lib/snapd, not just bits of it
<Chipaca> http://i.imgur.com/QMMtsAt.gif
<zyga> Chipaca: can I get a 2nd review on https://github.com/snapcore/snapd/pull/3135
<mup> PR snapd#3135: interfaces/mount: add high-level Profile functions <Created by zyga> <https://github.com/snapcore/snapd/pull/3135>
<zyga> Chipaca: gustavo already +1d it
<Chipaca> pedronisâ comme Ã§i? https://forum.snapcraft.io/t/you-add-files-to-snapd-how-do-you-run-tests-against-them-if-theyre-needed-inside/181
<pstolowski> zyga, hey, do you have any PRs I should re-review?
<zyga> pstolowski: I was just looking
<zyga> pstolowski: give me a sec
<Chipaca> zygaâ lovely pr, good one.
<zyga> Chipaca: thanks!
<zyga> Chipaca: I don't get your comment there
<Chipaca> zygaâ I mean, osutil.osutil.AtomicWriteFlags(0) is about as descriptive as just '0'
<Chipaca> zygaâ maybe we want an const AtomicWriteDefault AtomicWriteFlags = 0
<Chipaca> zygaâ hopefully that made sense despite me mangling it :-)
<zyga> aaah
<zyga> yes now I get it
<zyga> yeah, +1,
<zyga> I'll merge the branch but we can do a follow up with this
<mup> PR snapd#3135 closed: interfaces/mount: add high-level Profile functions <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3135>
<zyga> Chipaca, pstolowski, mvo: I could use feedback on tiny RFC branch: https://github.com/snapcore/snapd/pull/3138
<mup> PR snapd#3138: interfaces/mount: add Change.Perform <Created by zyga> <https://github.com/snapcore/snapd/pull/3138>
<Chipaca> Change.DanceForMe
<Chipaca> zygaâ you get my attention in two minute chunks, which is the time the 'prepare' stage of tests take
<ogra_> chunky
<zyga> Chipaca: you can also +1 a structure here: https://github.com/snapcore/snapd/pull/3129
<mup> PR snapd#3129: interfaces/mount: add InfoEntry type <Created by zyga> <https://github.com/snapcore/snapd/pull/3129>
<zyga> Chipaca: feel free to suggest different names (those match the C code)
 * zyga runs for lunch, see you at the standup
<zyga> re
<zyga> ah, standup is not in 5 minutes but an hour and five minutes
<zyga> mvo: will you review the locking branch?
<mvo> zyga: yes
<zyga> great, thank you :)
 * Chipaca ~> lunch
<Chipaca> also, whee, so close to passing tests
<zyga> mvo: updaed
<zyga> updated*
<zyga> Chipaca: yes, stuff is much greener lately :)
<Chipaca> zygaâ I was being selfish and talking about my own WIP branch
<Chipaca> but not so selfish i'd actually have lunch
<Chipaca> darnit
<Chipaca> got pulled into something else as leaving
<Chipaca> now *really* lunch
<zyga> niemeyer: replied to https://github.com/snapcore/snapd/pull/3095 -- have another look please
<mup> PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095>
<zyga> fgimenez: can you re-review https://github.com/snapcore/snapd/pull/3145 please
<mup> PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145>
<zyga> mvo: one more on https://github.com/snapcore/snapd/pull/3148 -- sorry, I should have noticed earlier
<mup> PR snapd#3148: errtracker: never send errtracker reports when running under SNAPPY_TESTING <Created by mvo5> <https://github.com/snapcore/snapd/pull/3148>
<fgimenez> zyga: i've done it already, dropped a comment about the last changes, we are loosing the network interface check with them
<zyga> pstolowski: did your first branch that adds attributes to all the methods finally land?
<zyga> fgimenez: loosing the check?
<fgimenez> zyga: yes, with your changes we no longer check that the network plug of the test snap is connected after the transition
<zyga> aha, let me check
<fgimenez> :)
<zyga> fgimenez: so, test-snapd-python-webserver, right?
<zyga> aha
<zyga> I see what you mean now
<zyga> sorry :)
<zyga> fgimenez: can I do it explicitly for network rather than network.*?
<fgimenez> zyga: np! :) sure, i think ":network +test-snapd-python-webserver" should do it, wdyt?
<zyga> yep, added
<zyga> thanks, your initial diff confused me
<zyga> and I didn't understand that both network and network-bind are tested
<fgimenez> zyga: yep sorry, now all looks fine, thanks!
<joedborg> I'm still having trouble with fonts (or lack of) when snapping a Qt GUI - has anyone got any pointers?
<pedronis> zyga: I made a comment in snapd#3095 , not clear why it cannot use a global flag to decide about bootstrap/no boostrap
<mup> PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095>
<pstolowski> zyga, no, i didn't
<sborovkov> mvo: Hello, I went thorugh the list of config.txt options which we actually change in production for RPIs. The list you exposed almost 100% matches what we had to modify actually. Except those 3 parameters - could they be added to rpi-config? sdtv_aspect config_hdmi_boost hdmi_force_hotplug
<mvo> sborovkov: yes, let me add those
<ogra_> mvo, ^^^ these sound all sane
<zyga> pstolowski: aha, I'm working on that extra test I told you about
<zyga> pedronis: looking
<zyga> pedronis: replied
<sborovkov> mvo: thanks!
<mvo> thanks ogra_
<pedronis> zyga: we can use a build tag though
<pstolowski> zyga, cool
<ogra_> jdstrand, a security team comment on bug 1674509  would be appreciated
<mup> Bug #1674509: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 <snapd-interface> <Snappy:Confirmed> <linux-raspi2 (Ubuntu):Invalid by p-pisati> <https://launchpad.net/bugs/1674509>
<Mirv> joedborg: the first pointer usually is https://developer.ubuntu.com/en/blog/2016/11/16/snapping-qt-apps/ - basically if you're fine with Qt you get from Ubuntu archives, use after: [desktop-qt5] and stage a few packages to go with your UI
<davidcalle> joedborg: fyi, there is a tutorial coming up on the topic next week at tutorials.ubuntu.com
<joedborg> hey Mirv, thanks for the heads up.  I've already been through that :).  I've also just tried to snap an Electron based app with exactly the same issue.  I've tried adding a raft of font packages to stage-packages and copying the font dir on my box into prime, but no luck
<Mirv> joedborg: right, I thought you might have been there already, it was just the first guess
<Mirv> hmm
<joedborg> Mirv: yeah, no problem :)
<Mirv> I wonder then what's the difference for example between one of the examples and yours
<joedborg> Mirv: the only difference I can see is that I'm just snapping a binary that's already been compiled
<Mirv> joedborg: FYI I just tried the first example and the three staged packages there are enough to pull in the following font related packages: http://pastebin.ubuntu.com/24327638/ - which sound pretty much enough from packages point of view
<joedborg> Mirv: whereas that's bulding QML
<Mirv> joedborg: right, it's then probably related to that binary not understanding living inside a snap far enough. do you use desktop-qt5 part and desktop-launch to launch it?
<Mirv> those set a whole lot of env vars, although it's not enough if the binary is hardcoding some more
<Chipaca> *gasp*
<Chipaca> 2017-04-06 14:32:27 Executing qemu:ubuntu-16.04-64:tests/completion/indirect:plain (1/1)... <- passed \o/
<Chipaca> woooo
<ogra_> something must be broken!
<joedborg> Mirv: I don't, I just call the bin
<Chipaca> ogra_â "plain" is the trivialest one; it means stuff is where it needs to be mostly
<ogra_> yeah, i was kidding indeed :)
<Chipaca> ogra_â i know you were :-)
<ogra_> :)
<Chipaca> but it also was worth mentioning :-)
<ogra_> yep, for that guy reading it via a google search in the logs
 * ogra_ waves to that guy
<mvo> niemeyer: your opinion on https://forum.snapcraft.io/t/use-python-for-the-core-snap-configure-hook/168 would be much appreciated
<Chipaca> i expect all the file-based ones to fail still (they're running now), as i need to run those as the 'test' user for access
<Chipaca> mvoâ as opposed to his opinion elsewhere, right?
 * Chipaca grins evily
<Mirv> joedborg: right, you'd probably want to use some launcher, either the cloud one or a custom one where you first set env vars and then launch the binary. the desktop-qt5 sets these: https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports + https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/qt/launcher-specific
<pedronis> zyga: this is what IÂ played with locally: http://pastebin.ubuntu.com/24327653/
<niemeyer> zyga: Replied to all points in #3095
<pedronis> zyga: notice it needs -tags test when running tests
<niemeyer> mvo: Thanks, let me re-read it
<mvo> Chipaca: *cough*
<ogra_> mvo, oh, thanks for collecting the data there (not sure why that edit didnt put it on top of the list for me in the UI(
 * zyga finished eating peanuts and drinking orange juice, now back to coding
<zyga> sorry for doing that during the call
<zyga> once you start it's hard to stop :D
<mvo> zyga: nobody noticed
<ogra_> you hid it very well from us
<jdstrand> ogra_: commented
<ogra_> thanks !
<joedborg> Mirv: thanks!  is there any example of how I used these within the yaml?
<mvo> Chipaca: I added some more example to the forum entry with grouping by track (but not a new hirarchy) and without the `^`
<Mirv> joedborg: well if you want to use the cloud part, just use the example from blog. if you want to define custom launcher, you could do something like this old example https://github.com/tjyrinki/timostestapp2/blob/master/snapcraft.yaml (see also launcher in the same dir that has a small portion of the possible env vars)
<Mirv> just define a launcher part you then use as a command for the app
<pedronis> zyga: if we can't use a build tag (too anoying)Â we can use a testing subpackage (bit overkill but might be easier for debian/rules)
<mup> PR snapd#3115 closed: interfaces/unity7: support unity messaging menu <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3115>
<niemeyer> mvo: replied
<mup> PR snapcraft#1237 closed: repo: enable elementary <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1237>
<Chipaca> um
<Chipaca> all tests passed
<Chipaca> and now what?
<Chipaca> i've been working on this so long i forgot how to move forward now :-)
<mvo> niemeyer_: \o/ thank you
<zyga> mvo: hmm, we should have unique plug/slot names on core
<pedronis> Chipaca: take a holiday? :)
<zyga> mvo: and now we seem to consume network-bind and core-support
<zyga> Chipaca: shave!
<zyga> mvo: those should be unique
<zyga> niemeyer_: ^6
<Chipaca> no! no shaving for me
<mvo> zyga: yeah
<Chipaca> did that a couple of years ago. Under my beard, I (a) look like my mum, and (b) am way older than i think i am
<Chipaca> the beard stays
<zyga> mvo: I'll have the fix in a moment
<zyga> mvo: just writing test, sorry I got side-tracked on that other test I was working on
<Chipaca> zygaâ https://goo.gl/photos/ceE95TpmBa7DDsEN7
<zyga> Chipaca: xmas!
<mvo> zyga: no worries
<Chipaca> JamieBennettâ #3150
<mup> PR snapd#3150 opened: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150>
<JamieBennett> \o/
<Chipaca> jdstrandâ ^ tab completion; it includes changes to apparmor/template.go
<Chipaca> jdstrandâ some but not all of which i discussed with you
<Chipaca> jdstrandâ (sorry for the 'not all' :-( )
<ogra_> so it is about time we finally remove the tab key from the keymap on our images, right ?
<jdstrand> Chipaca: ok
 * Chipaca *looks* at ogra_ 
<Chipaca> ogra_â yeah, map it to caps lock
<Chipaca> ogra_â who uses that thing anyway
 * ogra_ commits "reduce size of the keymap by 1 byte to save space on IoT images"
<ogra_> it's the small things :)
<mup> PR core#31 opened: Fix pi config and add new options <Created by mvo5> <https://github.com/snapcore/core/pull/31>
<mvo> ogra_: review of -^ would be great, should be trivial
<ogra_> already on it :)
<ogra_> mvo, shouldnt we just ship gawk ? so you can use sandbox ?
<mup> PR core#24 closed: Rewrite meta/hooks/configure into python3 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core/pull/24>
<mvo> ogra_: that would be the other option, yes
<Chipaca> and of course having pushed the branch i notice bugs i thought fixed
 * Chipaca pushes a little followup
<mvo> ogra_: if you could do that I will update the PR, then we can just revert that again once the hook moves to golang
<ogra_> seeding ...
<mvo> ta
<zyga> mvo: I found one more bug
<zyga> mvo: because plug and slot name are the same
<zyga> mvo: interfaces/Repository.Connected returns wrong data
<zyga> oh boy :/
<zyga> mvo: can you think about an action plan where we rename the clashing plug/slots on core
<zyga> mvo: and add tests so that it doesn't happen
<zyga> mvo: I suspect that we added in the core snap directly
<zyga> mvo: right?
<zyga> mvo: I think this is the missing validation that pstolowski found
<zyga> mvo: namely this: https://github.com/snapcore/snapd/pull/2932
<mup> PR snapd#2932: interfaces/repo: validate slot/plug names <Created by stolowski> <https://github.com/snapcore/snapd/pull/2932>
<zyga> niemeyer_: FYI ^
<niemeyer_> zyga: Ouch
<zyga> niemeyer_: I marked https://github.com/snapcore/snapd/pull/2932 as blocked
<mup> PR snapd#2932: interfaces/repo: validate slot/plug names <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/2932>
<brunorf> hello everybody
<brunorf> I would like to expose many commands on an snap package
<zyga> brunorf: you already can
<brunorf> Do I need to create one by one?
<zyga> brunorf: if you want to explose multiple top-level commands (not prefixed by your snap name)
<zyga> brunorf: you want to look at the new aliases v2 specification on the forum
<brunorf> ok
<brunorf> I will check it
<brunorf> I just like to have myapp.mycommands
<brunorf> but there are more than 50 commands
<zyga> brunorf: https://forum.snapcraft.io/t/improving-the-aliases-implementation/18
<zyga> brunorf: in that case just spell them out one by one
<brunorf> ok
<brunorf> thank you very much
<zyga> mvo: ok, fix is ready, pushing
<mvo> zyga: nice, thank you
<niemeyer_> Lunch, biab
<zyga> mvo: but we need a plan to fix this
<mvo> zyga: we added the network-client to the core snap directly. another option would be to add network-bind directly to core-support
<mvo> zyga: because core-support already is uniq and only used in core
<mvo> zyga: then the core snap only has a single interface and that is uniq to core
<zyga> mvo: can you please have a look
<zyga> mvo: I think we just need to rename the plugs on core
<zyga> mvo: e.g. core:network-bind core:internal-network-bind
<zyga> mvo: core:core-support core:internal-core-support
<zyga> mvo: anyway, please review the code at https://github.com/snapcore/snapd/pull/3145 (maybe patch-by-patcH)
<mup> PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145>
<mvo> zyga: so core even without the transition has duplicated slot/plug names? is that what you are saying?
<Chipaca> brunorfâ is that a problem?
<Chipaca> brunorfâ at 50+ i'd expect you have some sort of a makefile, and you can generate the yaml from there
<zyga> mvo, niemeyer_: https://forum.snapcraft.io/t/duplicate-plug-slot-names-inside-the-core-snap/184
<zyga> mvo: yes
<zyga> mvo: there are separare issues here
<zyga> mvo: the core transition is *not* related to duplicated plug/slot names in core
<mvo> zyga: aha, ok. sorry, that confused me for a sec
<zyga> mvo: tha's all right, I tried to summarize it at the forum
<zyga> (on the forum?)
<morphis_> zyga, mvo, fgimenez: can I skip the repack step for spread somehow? seems to take ages
<mvo> zyga: heh, a good question - I guess historally "on the forum" as it was a physical place. but *shrug* :)
<zyga> morphis_: repack?
<zyga> mvo: hehe, yes, quite curious evolution here :)
<mvo> morphis_: repacking the core snap? we have something that should make it quicker by not using xz but gzip in the tests
<ogra_> zyga, forumwards!
<zyga> ogra_: you should look at that post too
<morphis_> zyga, mvo: there is a repack step in spread.yaml
<zyga> ogra_: it's the core snap
<morphis_> which generates some kind of delta of the project path
<ogra_> zyga, yes, read it already
<ogra_> zyga, but you are doing evil things like mangling snap.yaml
<zyga> ogra_: I'm open to removing that mangling
<zyga> ogra_: but it would introduce another hop between adding an interface and being able to do testing on it
<zyga> ogra_: so that's why we have it
<zyga> ogra_: but I agree it is tricky
<mup> PR core#31 closed: Fix pi config and add new options <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/31>
<mup> PR snapd#3142 closed: daemon: Give the snap directories via GET /v2/system-info <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3142>
<fgimenez> morphis_: it shouldn't take too long, maybe you have large files in the project's directory?
<morphis_> fgimenez: right, I have some in there ..
<morphis_> my bad
<mvo> pstolowski: 3070 is failing tests, could you have a look please?
<fgimenez> morphis_: np :)
<pstolowski> mvo, sure
<morphis_> fgimenez: typpical user error :-)
<mup> PR snapcraft#1238 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1238>
<pstolowski> mvo, unit/gccgo and unit/go fail, doesn't look related to changes in the PR
<fgimenez> morphis_: yup i've hit that one more than once :)
<pstolowski> mvo, let me merge master and see what happens
<morphis_> hehe
<mvo> pstolowski: ta, master should be in good shape currently so fingers crossed
<Chipaca> i was needing this the other day: https://making.pusher.com/go-tool-trace/
<zyga> mvo: I'll take a break afther the current call, ping me if you need me for anything for 2.24
<mvo> zyga: I think your branch just needs a second review. its the last critical one for 2.24
<mvo> zyga: but I will have dinner soon too
<mikeb_> Hi.  I'm using python-daemon package to daemonize a python command.  I'm trying to use it as an app: in snapcraft with a daemon type of forking.  When I install the snap, I see the daemon running, but the installation of the snap never finishes - it looks like it's blocked waiting for something from the daemon.  What else do I need to do in my daemon?
<zyga> mikeb_: aha
<zyga> mikeb_: can you report that, add a trivial example if you can
<zyga> mikeb_: may be an interesting interaction with snap-confine, not sure
<zyga> mikeb_: open a new topic on the forum.snapcraft.io please
<mikeb_> Sure - by report - do you mean launchpad bug or just a forum post?
<zyga> mikeb_: a forum post first
<zyga> mikeb_: it has better interactivity features
<mikeb_> Will do.  Thanks!
<zyga> mikeb_: my quick theory is that snap-confine forks to setup the mount namspeace (just once per reboot per snap) and this confuses systemd
<zyga> mikeb_: thanks
<zyga> mikeb_: I'll check that out tomorrow, please add this discussion there (quote it please)
<zyga> mvo: I think we will do 2.24 tomorrow
<zyga> mvo: there's a few more things that we need to fix
<zyga> mvo: check out gustavo's post https://forum.snapcraft.io/t/duplicate-plug-slot-names-inside-the-core-snap/184/5
<zyga> mvo: I can pick that up first thing tomorrow but I must leave now
<niemeyer> mvo: I'm afraid 2.24 is something for next week
<niemeyer> mvo: These plug/slot issues need some careful investigation
<niemeyer> mvo: I have commented in the forum and also reviewed the related PRs
<mup> PR snapd#2932 closed: interfaces/repo: validate slot/plug names <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2932>
<pstolowski> ty niemeyer
<niemeyer> pstolowski: np, thanks for the fix!
<niemeyer> This was sitting there for a bit too long
<zyga> niemeyer, mvo: updated https://github.com/snapcore/snapd/pull/3145
<mup> PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145>
<mup> PR snapcraft#1239 opened: catkin plugin: create completely valid environment <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1239>
<mvo> niemeyer, zyga thanks for this update, I will update the release page
<Chipaca> huh
<Chipaca> how did this ever work
<sergiusens> jdstrand: hey, mind looking at telegram-sergiusens from edge and tell me why I can't see /usr/local/bin ?
<sergiusens> zyga: or if you have some time? ^
<jdstrand> sergiusens: what release?
<jdstrand> sergiusens: 16.04 classic? zesty? something else?
<sergiusens> jdstrand: I am on zesty
<jdstrand> sergiusens: ok, let me see
<sergiusens> jdstrand: I get permission denied for anything out of that path, but other snaps have xdg-open working (which means they can access /usr/local/bin I guess)
<sergiusens> thanks!
<jdstrand> sergiusens: I guess you are concerned about a snapd-xdg-open scenario?
<jdstrand> sergiusens: if I launch it, click Get Started and then click Settings and 'Telegram FAQ' it is reaching out to dbus but dying before any access is tried
<jdstrand> sergiusens: dbus-send: /snap/telegram-sergiusens/28/lib/x86_64-linux-gnu/libdbus-1.so.3: version `LIBDBUS_PRIVATE_1.10.6' not found (required by dbus-send)
<jdstrand> sergiusens: is there something else I should try?
<mup> PR snapcraft#1240 opened: cli: improve push output <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1240>
<pedronis> Chipaca: ?
<Chipaca> pedronisâ ? <- ?
<Chipaca> ah!
<pedronis> Chipaca: cp problems?
<Chipaca> we were setting up the for-testing core by doing âcp /usr/lib/snapd/snap-confine squashfs-root/usr/lib/snapdâ
<Chipaca> which drops the setuid bit
<pedronis> Chipaca: --preserve=mode should be the default and we run as root
<mvo> Chipaca: pretty sure one of my branches fixes that
<Chipaca> mvoâ heh
<mvo> iirc the 3027
<Chipaca> mvoâ fixed it in my branch too :-) (because i also changed that bit)
<pedronis> how did it ever work then?
<pedronis> the cp docs are lying?
<mvo> pedronis: its only done this way in the classic prepare
<pedronis> ah
<mvo> pedronis: the ubuntu core tests use dpkg-deb -x which preserves all the attributes
<mvo> pedronis: and because we don't (yet) run snap-confine from the core snap we did not notice
<pedronis> so it wasn't an issue because we weren't using snap-confine from core
<mvo> correct
<pedronis> ok, so cp docs a re a bit misleading :/
<pedronis> fwiw
<davidcalle> mvo or ogra_ (if you are still there), do you know how these images are updated? http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ I flashed the pi3 image today and it was not on the latest stable core rev
<mvo> davidcalle: cdimage is handled by steve nowdays
<davidcalle> slangasek: hey ^
<davidcalle> Thanks mvo
<pedronis> Chipaca: anyway IÂ would go with -a as mvo branch does
<mvo> -a ftw!
<mvo> (what was Chipaca using?)
<pedronis> just --preserve=mode
<pedronis> which confused me
<pedronis> because in theory that's part of the default
<pedronis> as I said man cp doesn't say a lot about setuid
<slangasek> davidcalle, mvo: hi, which rev are we expecting here?  We spin the images when I know that there's a new rev of core to update to
<pedronis> ah, maybe I'm reading it wrong
<mvo> slangasek: I don't know, I'm just the proxy here :)
<slangasek> mvo: sure - has there been a new core snap published since Mar 16?
<davidcalle> slangasek: I don't have the rev at hand (was wondering about the process mostly) but I'll come back with it :)
<slangasek> ok
<pedronis> mvo: Chipaca: I was reading the doc wrongs, what they mean is that cp --preserve === cp --preserve=mode,ownership,timestamps
<slangasek> I don't have any tooling here to detect that there's been a new rev of the core snap, so I'm at this point still dependent on someone giving me a heads up that one is published to stable
<slangasek> I know that in principle we want to build these every two weeks, but without a trigger I'm at risk of building them before the new snap is available on the channel, so..
<davidcalle> slangasek: yeah, makes sense
<mvo> davidcalle: rev of the pi2 for stable is 1580 - is that the one you are looking for?
<mvo> slangasek: there was a handoff in the process, the stable promotion is now done by JamieBennett, I guess we need to add "notify steve to build new images for cdimage" to the stable release checklist he is using :)
<slangasek> mvo: aha :)
<JamieBennett> slangasek: mvo: Oh, I thought they were automatically built on new revisions?
<slangasek> JamieBennett: no, I have no tooling to detect new revisions
<slangasek> JamieBennett: so for the moment, if you can let me know when there are publications to either candidate or stable, that would be a big help
<JamieBennett> slangasek: OK, maybe something to investigate for the future then. Will prod you on new versions.
<slangasek> thanks
<slangasek> I guess currently I should be spinning updates to both candidate and stable, then?
<davidcalle> slangasek: mbo: the pi3 (fresh image from above) started on 1443, then refreshed to 1580
<JamieBennett> slangasek: stable now, candidate when 2.24 has been validated in beta by fginther
<davidcalle> mvo*
<slangasek> ok
<JamieBennett> sorry fginther meant Federico
<mvo> davidcalle: correct
<davidcalle> Since I have the pi3 booted, is there anything odd in these changes ? changes 1 and 3 are missing
<davidcalle> https://www.irccloud.com/pastebin/e4lFhjVJ/
<sergiusens> jdstrand: interesting, if I `snap run --shell telegram-sergiusens.telegram` I cannot ls or cd to /usr/local/bin; is that the way it is supposed to be?
<davidcalle> (refresh of core to 1580 happened in 1 or 3, i still see it in list --all)
<jdstrand> sergiusens: the ls is correct, the cd is not (ie, you can't ls but can cd)
<jdstrand> sergiusens: confirmed locally. I suspect with the cd you are maybe trying to do tab completion?
<jdstrand> sergiusens: (and by confirmed, I mean it is operating how I described, which is intentional)
<sergiusens> jdstrand: ah, thanks for the help, that lib error is going to help me sort it out
<coreycb> sergiusens, for that python import issue you couldn't recreate, are you using the daily snapcraft ppa by any chance?
<sergiusens> coreycb: no, I am using the snapcraft snap, why? The daily ppa is not meant for users, not even built daily
<sergiusens> coreycb: that said, the snapcraft snap is almost identical to the deb
<sergiusens> hmm, but I did build on zesty, maybe there's something to that
<coreycb> sergiusens, ok i'm using the 2.28+17.04 deb on zesty
<mvo> niemeyer: I think 3027 is ready for a re-review - but not urgent if we need to delay 2.24 anyway
<niemeyer> mvo: Looking
<niemeyer> mvo, pedronis: How're doing in terms of test timing?
<niemeyer> Are we blowing the limit regularly due to the move of unit tests in still>
<niemeyer> ?
<coreycb> sergiusens, is the snapcraft snap in the store?  i can give that a try.
<sergiusens> coreycb: snap install snapcraft --edge --classic
<sergiusens> only on edge as you can see
<coreycb> sergiusens, ok thanks
<pedronis> niemeyer: my current PRs in the end passed their tests, haven't been looking a lot about that for PRs I have been reviewing
<niemeyer> pedronis: Ok, let me know if you see news about this please
<mup> PR snapcraft#1241 opened: help: replace dashes with underscores when printing plugins help <Created by EduardoVega> <https://github.com/snapcore/snapcraft/pull/1241>
#snappy 2017-04-07
<Pharaoh_Atem> Hey everyone, if there's anyone interested in trying out snappy on Fedora, it'd be great if you could test out snapd
<Pharaoh_Atem> more details here: https://forum.snapcraft.io/t/call-for-testing-snapd-2-23-on-fedora/127/6
<olympionex> does anybody know if there has been any other progress on this snap download connection reset bug? https://bugs.launchpad.net/software-center-agent/+bug/1617765
<mup> Bug #1617765: Connections reset when downloading snaps from CDN <Snapcraft:New> <Software Center Agent:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1617765>
<olympionex> my experience is similar to the comments from others on that bug, it seems to affect snapcraft being run inside containers in particular
<olympionex> have tried both building inside lxd and docker containers and the core snap fails to download the vast majority of the time
<morphis_> mwhudson: ping
<mup> PR snapd#3151 opened: Small adjustments for debian deb builds and packaging symlink for Debian Sid <Created by morphis> <https://github.com/snapcore/snapd/pull/3151>
<mup> PR snapd#3151 closed: Small adjustments for debian deb builds and packaging symlink for Debian Sid <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/3151>
<zyga> o/
<zyga> mvo: I will take a small detour to check something that gustavo requested (build system tweaks)
<zyga> mvo: meanwhile can you do a review on updates to https://github.com/snapcore/snapd/pull/3145
<mup> PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145>
<zyga> mvo: and let's plan how to change the plug names on core
<zyga> mvo: (i.e. how to test that)
<zyga> mvo: so that we don't cauese any regressions with this move
<zyga> mvo: after the build system detour I will look at ensuring plug/slot name uniqueness validation
<zyga> mvo: we have code for that but apparently it's not used or working
<zyga> mvo: (I suspect the way implicit slots are added side-steps that)
<mup> PR snapd#3152 opened: store: make hash error message more accurate <Created by mvo5> <https://github.com/snapcore/snapd/pull/3152>
<mvo> zyga: ok
<sabdfl> mcphail, we will figure out security in wayland
<sabdfl> we need to do that anyway to get snaps to be amazing on a GNOME desktop
<sabdfl> but we will keep Mir for IoT projects where security and simplicity are the main requirement
<zyga> about wayland, I think we could use a test on fedora 25 + wayland to see how the interface shoud look like, I think it will be relatively straightforward
<zyga> and try the same on ubuntu with apparmor to see what's to do with confinement
<zyga> morphis was recently working on better X11 auth support for snaps
<zyga> and that feels in line with similar work for wayland
<zyga> mvo: ok, experiment done
<zyga> now looking at plut/slot uniqueness again
<mvo> thanks zyga
<mvo> fgimenez: could you please have a look at 3148? it needs a second review and is pretty simple (I hope :)
<Aimilius> Hello, I'm trying to update the snapd PKGBUILD on archlinux form 2.21 to 2.23.6. I removed the biuld patches that move the /snap dir to /var/lib/snapd/snap and updated the verison number. Everytime I would try to build snapd, I would get a linking error I cannot resolve. https://pastebin.com/YY3Pa3U8
<fgimenez> mvo: sure on it
<mvo> fgimenez: btw, is the re-exec spread-cron happy now? with the new snapd now being build?
<zyga> Aimilius: hello! welcome :-) looking at the diff
<zyga> er, log :)
<zyga> Aimilius: aha, I think I know what's wrong
<Aimilius> That was quick :)
<zyga> Aimilius: can you do a master snapshot pleaes
<zyga> Aimilius: I landed a PR that makes the build system more flexible
<zyga> Aimilius: look at cmd/autogen.sh
<fgimenez> mvo: nope it seems to have the same errors https://travis-ci.org/snapcore/spread-cron/builds/219549331
<zyga> Aimilius: the problem is related to the set of libraries that are linked into snap-confine statically
<zyga> Aimilius: in master each library (that can) has a knob to control if it is linked dynamically or statically
<zyga> Aimilius: and the defaults are all dynamically as that is most easy to compile on all distributions
<zyga> Aimilius: in 2.23.6 that wasn't the case
<zyga> Aimilius: we are working on 2.24 now (not sure if it goes out today as we found some old bugs last night and want to fix them) but if you take master you will have a better chance at building it
<Aimilius> zyga: I'm trying to rebuild now
<zyga> Aimilius: excellent!
<fgimenez> mvo: snapd 2.23.6+201704061805.git.996da23~ubuntu16.04.1 in that execution, is that ok?
<mvo> fgimenez: that sounds good
<Aimilius> Master builds fine, though some checks fail
<Aimilius> I believe they are about apparmor confinement (test_restrictions test_complain_missed and test_unrestriced_missed, so I didn't excpect that would work
<mvo> zyga: one quick question in your 3145 PR - if correct I can quickly push a branch for core
<zyga> mvo: looking
<Aimilius> Oh, they're about the linux-grsec restrictions
<Aimilius> So everything works fine
<zyga> mvo: yes, that's correct, also replied there
<zyga> Aimilius: those are about seccomp I think
<zyga> Aimilius: aha
<zyga> Aimilius: interesting, feel free to report those on the forum, I'm sure the security team will be interested in them
<Aimilius> zyga: I've got linux-grsec installed, that blocks unpriviliged dmesg access
<zyga> aha
<Aimilius> zyga: The test-suites try to access dmesg, so that doesn't work
<mvo> zyga: ta, I will push a branch for core with that fix
<zyga> mvo: OK
<Aimilius> zyga: I think on plain linux (without grsecurity) it'll work fine
<zyga> mvo: branch with plug/slot uniqueness enforcement on AddPlug/AddSlot is almost ready
<mvo> zyga: it looks like snapcraft.yaml does not allow to use: "plugs: network-bind-hook: interface: network-bind" :/
<mvo> zyga: the valications allows only flat strings arrays
<mvo> zyga: whichi is very stange
<kristbaum_> jdstrand I have had an "review pending" on my snap for five or six days. Is this normal, should I change something? I just wanted to try and upload an beta of mdt for testing.. it's namespace is mdt.kristbaum.
<mvo> zyga: hm, looks like its just a bit of a strange syntax
<zyga> mvo: no, you need to spell that differently
<zyga> mvo: like this:
<mvo> zyga: yeah, silly me
<zyga> mvo: plugs:\n  network-bind-plug:\n    interface: network-bind
<Aimilius> zyga: After a build on clean linux (without-grsecurity) the tests still fail. https://pastebin.com/WH1JBmMe
<mup> PR core#32 opened: Rename core-support,network-bind plugs to make them unique <Created by mvo5> <https://github.com/snapcore/core/pull/32>
<zyga> mvo: have a look at https://github.com/snapcore/snapd/pull/3153 please
<mup> PR snapd#3153: interfaces: validate plug/slot uniqueness <Created by zyga> <https://github.com/snapcore/snapd/pull/3153>
<mup> PR snapd#3153 opened: interfaces: validate plug/slot uniqueness <Created by zyga> <https://github.com/snapcore/snapd/pull/3153>
<zyga> Aimilius: hmm, can you please open a topic for that on https://forum.snapcraft.io/ - make sure to report the kernel version used
<zyga> Aimilius: we may carry some seccomp fixes
<zyga> Aimilius: not sure yet, we'll check it out
<Aimilius> Ok, I'll open a topic
<zyga> morphis: ^^ have a look please
<Aimilius> zyga: uname -a Linux glorfindel 4.9.20-1-lts #1 SMP Fri Mar 31 15:23:31 CEST 2017 x86_64 GNU/Linux
<zyga> mvo: note that this branch may be a flag day for core revert
<zyga> mvo: as previous core won't validate and because the plugs are explicitly defined and slots are implicitly added later, may be dysfunctional (no network-bind slot, no core-support slot)
<zyga> mvo: I can do a separate patch that fixes this by detecting it and changing the snap via implicit.go
<zyga> mvo: let me know what you think
<zyga> mvo: I also thing we could use a `snap --validate ./path/to/file.snap` command
<zyga> (^ internal hidden thing maybe)
<mvo> zyga: hm, if we need a flag day we need to think about this more carefully, maybe a HO in a bit for some brainstorm?
<zyga> mvo: yes
<zyga> mvo: I think we can avoid it
<zyga> mvo: if we teach snapd to just rename those two plugs
<zyga> mvo: (core:network-bind -> core:network-bind-plug) (same for core-support)
<zyga> mvo: then no flag day needed
<zyga> mvo: do you want to jump into a HO to discuss?
<zyga> mvo: I'm in the standup HO if you want to
<mvo> zyga: yes, one minute, just addressing some things
<zyga> mvo: though sligthly complex, depending on where we do this exactly
<mup> PR core#32 closed: Rename core-support,network-bind plugs to make them unique <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core/pull/32>
<morphis> Aimilius, zyga: looking
<Aimilius> I posted a topic on the forum here: https://forum.snapcraft.io/t/checks-fail-on-arch-linux/200/1
<morphis> Aimilius: thanks, will respond there once I find something
<Aimilius> morphis: thanks for your effort
<morphis> np
<morphis> Aimilius: you're not building on a kernel with AppArmor support, right?
<Aimilius> zgrep APPARMOR /proc/config.gz # CONFIG_SECURITY_APPARMOR is not set
<Aimilius> morphis: though I do use apparmor
<morphis> Aimilius: ok, then you should compile snap-confine with --disable-apparmor
<morphis> Aimilius: how when the kernel side support is disabled?
<Aimilius> I normally run linux-grsecurity with apparmor compiled
<Aimilius> But the tests didn't like the dmesg restrictions so I booted my normal kernel without grsecurity and apparmor
<morphis> Aimilius: ok, when you don't have AppArmor in the kernel you should build with --disable-apparmor --disable-seccomp
<Aimilius> morphis: I'm running this command to build snap-confine ./autogen.sh --prefix=/usr --disable-apparmor --enable-merged-usr
<morphis> we don't have runtime detection (yet)
<morphis> please add --disable-seccomp too
<zyga> morphis: without apparmor the seccomp tests wont run either, I think the logic there assumes both
<Aimilius> morphis: does snap-confine depend on out-of-tree seccomp patches
<Aimilius> morphis: because the arch kernel does support seccomp
<Aimilius> morphis; and I have libseccomp installed
<morphis> Aimilius: the problem is that only using seccomp will unhide a few problems nobody didn't look into yet
<morphis> safest is to disable both right now
<Aimilius> Ok, rebuilding
<Aimilius> morphis: if I add --disable-seccomp, the checks still fail
<morphis> Aimilius: ok
<morphis> Aimilius: can you paste the log output for that?
<Aimilius> morphis: sure
<mcphail> sabdfl: thanks. Sorry Plan A didn't work out. Loved what you were trying to do
<Aimilius> morphis: https://pastebin.com/v2sh2f7Z
<morphis> Aimilius: will look in a bit
<Aimilius> morphis: I'll have to go leave soon
<morphis> Aimilius: ok
<Aimilius> But I'll look at the forum this afternoon
<morphis> Aimilius: I will see that I get an Arch setup and try to reproduce
<Aimilius> morphis: Shall I post my PKGBUILD?
<morphis> Aimilius: please!
<Aimilius> morphis: https://pastebin.com/qRRNSYmz
<Aimilius> I use a ugly hack to install the systemd unit files
<morphis> Aimilius: ok, we have something better for this in 2.24
<Aimilius> morphis: But with the --nocheck option, it appears to install
<Aimilius> morphis: great to hear
<morphis> Aimilius: something like make -C data/systemd DESTDIR=... install will do the job then
<Aimilius> morphis: that was what I did
<morphis> ah
<Aimilius> morphis: with SYSTEMDUNITDIR=/usr/lib/systemd/system, because of the usr merge
<morphis> ok, that is then what you should do
<Aimilius> But it felt like I shouldn't use a Makefile there
<zyga> mvo: have a look a tthis please https://github.com/snapcore/snapd/compare/master...zyga:rename-clashing-core-plugs?expand=1
<zyga> mvo: that's what I was thinking about (tests WIP)
<zyga> mvo: essentially this is the essence: https://github.com/snapcore/snapd/commit/59ae873d82883f8887ac7c55bead62e60ab749f6
<zyga> (the last two patches are new in this brancH)
<Kristbaum__> Is somebody here that is responsible for manual reviews in the snap store?
<zyga> Kristbaum__: I think so
<zyga> Kristbaum__: I think you may have better luck on forum.snapcraft.io, using the "store" category
<zyga> Kristbaum__: as they are in different timezones
<zyga> Kristbaum__: and you may get more organized replies there
<Kristbaum__> zygra okay will try that
<zyga> Kristbaum__: thanks!
<zyga> mvo: I'm adding tests to RenamePlug
<zyga> mvo: adding tests to ifacestate
<morphis> actually running snapd spread tests in QEMU doesn't look much reliable these days ..
<zyga> morphis: why? what are you getting?
<zyga> morphis: I sometimes get startup errors but if it runs, it is quite reliable
<morphis> timeouts for apt-get
<morphis> ala "running late"
<morphis> sometimes network connectivity dies
<morphis> but could be that I have a debian container I am trying to run the tests in
<zyga> morphis: late is normal
<zyga> morphis: aha, I dind't try it that way
<morphis> zyga: should the lxd backend work these days?
<Chipaca> morphisâ apt update/upgrade the base image to keep the time in check
<Chipaca> otherwise each test run does that, and it's hella slow :-)
<morphis> Chipaca: yeah doing that right now
<Chipaca> (that's a technical term)
<pstolowski> mvo, #3070 failed again, the failures seem to be unrelated to the branch, i.e. snap confine test failures, gccgo failures
<Chipaca> morphisâ niemeyer has a cron job for this, but not sure if it's reusable for qemu
<morphis> Chipaca: let me check
<zyga> morphis: I don't know
<zyga> morphis: we don't exercise it I think
<morphis> zyga: ok, worth a try later
<morphis> zyga: but I must say using the debian openstack images is working like a charm so far
<zyga> morphis: nice!
<zyga> morphis: can you add instructions on how to get them to spread-qemu-images please?
<morphis> zyga: had to modify the adt-* script a bit but will send a PR for your spread images repo later today or on monday
<morphis> zyga: you had a chance to test snapd on fedora yesterday again?
<morphis> Son_Goku: any more testing from your side happend? I've added +1 to all three bodhi requests now
<zyga> morphis: nice
<zyga> morphis: no, I didn't we found a new set of bugs that delayed 2.24 release
<zyga> morphis: I'm still working on fixing them
<morphis> ok
<morphis> zyga: what kind of bugs?
<zyga> morphis: https://forum.snapcraft.io/t/duplicate-plug-slot-names-inside-the-core-snap/184/7
<zyga> mvo: ok, I'm adding one more correction, I will migrate connection state as well
<zyga> mvo: that is done, just adding tests
<morphis> zyga: I see
<mup> PR snapd#3148 closed: errtracker: never send errtracker reports when running under SNAPPY_TESTING <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3148>
<zyga> mvo: ok ready
<zyga> mvo: let me open a PR
<mvo> pstolowski: some of the test failures in 3070 look real
<mvo> zyga: ok
<mup> PR snapd#3154 opened: many: rename two core plugs that clash with slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/3154>
<zyga> Chipaca: hey, mvo is off now
<zyga> Chipaca: I need a hand with critical 2.24 reviews
<Chipaca> zygaâ shoot
<Chipaca> zygaâ or i can look myself :-)
<Chipaca> on it
<zyga> Chipaca: https://github.com/snapcore/snapd/milestone/6
<zyga> Chipaca: there are two approaches used
<zyga> Chipaca: (and both should land)
<zyga> Chipaca: I added one more branch to 2.24
<zyga> Chipaca: - rename everything when starting so even old core snap is correct
<Chipaca> why is our test suite brittle all of a sudden :-(
<zyga> Chipaca: this is done in https://github.com/snapcore/snapd/pull/3154
<mup> PR snapd#3154: many: rename two core plugs that clash with slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/3154>
<zyga> Chipaca: - validate everything so it doesn't happen again
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/3153
<mup> PR snapd#3153: interfaces: validate plug/slot uniqueness <Created by zyga> <https://github.com/snapcore/snapd/pull/3153>
<zyga> Chipaca: and lastly because we found this by fixing a bug in core transition
<Chipaca> snapd#3145 needs niemeyer to re-review i guess
<mup> PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145>
<zyga> Chipaca: this branch fixes the damage done there https://github.com/snapcore/snapd/pull/3145/files
<Chipaca> (as he marked it as Changes Needed)
<zyga> yep
<zyga> that's fine
<zyga> I want to go through the first round on the two new PRs
<Chipaca> zygaâ wouldn't it make sense, in snapd#3154, for you to also test RenamePlug for a case where a plug and slot have the same name?
<mup> PR snapd#3154: many: rename two core plugs that clash with slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/3154>
<tvoss> pedronis: hey there, I was looking into replacing the exec'ing of ssh-keygen with using openssl via CGO as in: http://pastebin.ubuntu.com/24333148/
<zyga> Chipaca: sure, can do
 * zyga does
<tvoss> pedronis: do you have any guidelines on how to use CGo? Like place actual implementation into .c file or some such?
<zyga> tvoss: look at...
<zyga> tvoss: https://github.com/snapcore/snapd/pull/3095
<mup> PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095>
<zyga> Chipaca: ha, I cannot
<zyga> Chipaca: it's validated now
<zyga> Chipaca: http://pastebin.ubuntu.com/24333233/
<tvoss> zyga: ack
<Chipaca> zygaâ state twiddling direclty?
<Chipaca> zygaâ or make a for-testing way of overriding the validation
<Chipaca> because clearly you can be in that state
<Chipaca> so we need to test it
<zyga> Chipaca: I'll think of something
<zyga> Chipaca: good point about being able to be in that state
<Chipaca> zygaâ I'm now wanting to check it even more, to make sure we don't break people that are in that state already
<zyga> Chipaca: look at the other branches and suggest ideas
<zyga> Chipaca: note that it is not strictly speaking "hurtful" to have clashing names
<zyga> Chipaca: but we want to get away from that
<pedronis> I think it's a matter of order of things in the other branch fixing this
<pedronis> but we need to be able to load the state to fix it
<Chipaca> zygaâ idea: make space probes look futuristic to trick aliens into thinking we're more advanced than we are
<zyga> pedronis: state is not validated there (just connections are changed)
<zyga> pedronis: and interfaces.ConnRef has no validation
<Chipaca> zygaâ or did you mean ideas that were relevant to the branch
<pedronis> don't we do a big add all the snaps thing
<mvo> Chipaca: re brittle> https://forum.snapcraft.io/t/hashsum-failures-during-tests/198 is what I see in a bunch of them
<pedronis> zyga: initializes does addSnaps, no?
<zyga> pedronis: aha, good point
<pedronis> I don't see the aha there but yes, bit of a chicken and egg problem
<zyga> Chipaca: ok, I have something for that now
<zyga> pedronis: well, if we load core snap and validate it
<Chipaca> mvoâ D:
<zyga> pedronis: it won't reach that point
<pedronis> so it explodes
<pedronis> is that aha?
 * pedronis has probably no sense of humur today
<zyga> Chipaca: have a look, just pushed
 * Chipaca hugs pedronis 
<pedronis> anyway I agree with Gustavo's yesterday point that we need to tread carefully through these fixes
<zyga> pedronis: yes, I totally agree
<pedronis> will one of our spread tests exercise thiss?Â like the upgrade one?
<zyga> pedronis: spread tests do exercise this already
<zyga> pedronis: well, not directly this
 * pedronis anyway, lunch
<zyga> pedronis: but the branch that adds validation is all read
<zyga> red*
<zyga> pedronis: because now core doesn't validate anymore
<Chipaca> zygaâ dude, stop with the Not(IsNIl) :-)
<pshod> any way to create env variables or signals that can be accessed by two different processes inside a snap env?
<zyga> Chipaca: how should I do it?
<Chipaca> zygaâ NotNil
<Chipaca> zygaâ compare the failing output and you'll see what i mean
<zyga> Chipaca: oooh, didn't know about it :)
<zyga> Chipaca: ack, will do
<pshod> my snap exposes a noejs app which spawns a sh script which fires a banary
<pshod> binary
<Chipaca> pshodâ one easy way is to use the filesystem
<Chipaca> pshodâ that includes, for example, a unix socket
<pshod> i am notifying the event by writing into a file
<pshod> and then if the file has a particular content
<pshod> i close my watch in the node app
<pshod> chipaca : the sh script should write unto a socket and the node app listens on the socket?
<pshod> zyga: help help help!
<Chipaca> pshodâ it depends on what you need to do, etc etc
<Chipaca> pshodâ please tell us more
<pshod> ill try to be concise
<zyga> pshod: so
<zyga> pshod: if you set environment from a running process
<Chipaca> pstolowskiâ â- Download snap "core" (1577) from channel "stable" (unexpected EOF)â <- just got that :-(
<pshod> snap exposes a node app -> spawns a sh script that fires a binary->binary reads data from a sensor and writes into a file in SNAP_COMMON->node app reads the file and posts to a REST server
<zyga> pshod: you cannot just "see" that easily in other processes without looking at /proc
<zyga> pshod: not sure what you meant by a signal
<zyga> pshod: tell me what you want to achieve
<Chipaca> pshodâ with you so far
<zyga> pshod: (not how)
<zyga> pshod: and we'll recommend osmething
<pstolowski> Chipaca, is this with current code, or latest release?
<Chipaca> pstolowskiâ https://travis-ci.org/snapcore/snapd/builds/219327815
<pshod> no the node app is configurable..we pass the number of tmes the binary writes into the fuke
<pshod> file*
<Chipaca> pstolowskiâ upgrade/basic failed with that
<pshod> now what I have done is, i modifies the sensor binary so that after writing the said "n" observations into the file
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/3154#discussion_r110359632 (updated and added tests)
<mup> PR snapd#3154: many: rename two core plugs that clash with slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/3154>
<pshod> overwriting*
<pshod> it writes "Closing Session"
<pshod> so when i read the file from SNAP_COMMON
<pshod> and see it's contents as "Clossing Session" I remove the watch from SNAP_COMMON and my node app exits gracefully
<pstolowski> Chipaca, uhm. not good. would be great to find out how to provoke 'unexpected eof' in the test. what I did recently was a test with closing client connections, and that triggers normal EOF
<pshod> people dont like this design and I am not pretty confident about it too
<pshod> :|
<Chipaca> pstolowskiâ send a RST
<zyga> pshod: today I'm focusing on 2.24 release and I don't have much time to help
<Chipaca> pshodâ ah, so this is what you're doing now and you need to improve it?
<zyga> pshod: maybe ask on the forum and we'll get to that
<Chipaca> pshodâ yeah, maybe it's better as a forum question, rather long-winded for here
<pshod> zyga : hey thank you!
<Chipaca> pshodâ nothing wrong with the file-based approach as long as you're using locking appropriately
<Chipaca> pshodâ but there are other ways, sure
<pshod> zyga: have gotten much help from you in the past :D
<zyga> pshod: I'll gladly help next week but I need to focus on fixing something we just found out that is affecting core
<zyga> pshod: namely https://forum.snapcraft.io/t/duplicate-plug-slot-names-inside-the-core-snap/184/6
<Chipaca> pstolowskiâ no i don't know *how* to send a RST, i know a RST is the usual cause for that unexpected eof
<zyga> pshod: we won't release today (Friday = bad idea) but I want it to be ready
<pshod> chipaca : locking is done properly, I suggested we just update a variable which gets updated when API for posting is called
<zyga> pstolowski: network throttling things sent RSTs to kill connections
<pstolowski> Chipaca, exactly... i'll look into that later, thanks. in the meantime - E_TOOMANYISSUES_ATM
<pshod> but that was rejected too.
<pshod> zyga : duplicate plug names
<Chipaca> pshodâ ok, open a forum thread, write everything out there please
<pshod> zyga: sounds too much of fun :P
<pshod> chipaca : on it
<Chipaca> pshodâ what you want to achieve, what you are doing now, why it was rejected/requested to be improved, what other things were proposed but also rejected
<zyga> pedronis, Chipaca, pstolowski, mvo: I'm looking for proposals on how to fix the chicken/egg problem on core's snap.yaml: we need to load an invalid file to fix it
<Chipaca> pshodâ the 'what you want to achieve' there is missing in what you've written so far, afaict
<zyga> my naive idea is to add a way to load snap.Info that's invalid
<zyga> use that on the core snap only
<zyga> and apply the fix right there
<zyga> (the fix is currently in interface manager but it should move to snap manager)
<mvo> zyga: how about a forum.snapcraft.io topic? to have an archived discussion?
<zyga> mvo: +1
<pshod> chipaca : will do it like that
<mup> PR core#32 opened: Rename core-support,network-bind plugs to make them unique <Created by mvo5> <https://github.com/snapcore/core/pull/32>
<zyga> commented on the forum about it
<zyga> https://forum.snapcraft.io/t/duplicate-plug-slot-names-inside-the-core-snap/184/9?u=zyga
<pshod> chipaca : wont i be able to register using my company id?
<Chipaca> pshodâ I don't know. It's not (yet) tied into login.ubuntu.com, if that is what you mean
<Chipaca> zygaâ what calls snap.Validate on startup?
<mikeb_> Hi, I need some help with snapcraft.yaml syntax.  I'm trying to implement a command wrapper to start my apps.  I'm trying to pass a command and its arguments to the wrapper, but I can't get the syntax correct.  For example -  command: usr/bin/mywrapper --wrapper-arg1 --wrapper-arg2  --exec '$SNAP/usr/bin/cmd --cmd-arg1 --cmd-arg2'.  Snapd parses cmd-arg1 and cmd-arg2 as arguments to usr/bin/mywrapper.  What is the syntax to put them al
<mikeb_> What is the syntax to put them all in the string as the --exec argument?
<zyga> Chipaca: when you load the state, I think that's in snapmgr somewhere
<zyga> Chipaca: look at the interface manager, it asks for all the snaps and adds active ones to the repository
<zyga> Chipaca: with the validation code in place we will naver reach that spot
<zyga> Chipaca: as we will crash and burn on invalid core
<Chipaca> mikeb_â can you share the yaml in a pastebin?
<mikeb_> Chipaca: sure
<Chipaca> zygaâ I see interface/repo.go:73 calling ValidateName, but no Validate call
<Chipaca> interfaces*
<pshod> chipaca : i should tag my entry as "other"?
<mikeb_> https://pastebin.com/GhCBe4Gd
<Chipaca> mikeb_â ok, that seems alright. Can you show me the .service file that gets generated?
<mikeb_> Chpaca: is the generate service file located in the prime area? Or is it generated at snap install time?
<Chipaca> mikeb_â it'll be in /etc/systemd/system
<Chipaca> mikeb_â called something obvious
<Chipaca> mikeb_â ah, at install itme
<Chipaca> time*
<mikeb_> Chipaca: my install is failing, so I can't get to it.
<Chipaca> ah
<Chipaca> mikeb_â how is it failing?
<mikeb_> Chpaca: https://pastebin.com/4Ufw8WcE
<Chipaca> mikeb_â that happens on 'snap install', i take it
<Chipaca> or snap try
<mikeb_> Chipaca: snap install
<mikeb_> Chipaca: on a Ubuntu-core system
<Chipaca> mikeb_â so, what's *probably* happening is that the quoting there reaches the .service file intact, and then systemd reads it wrong
<Chipaca> I need to test this
<Chipaca> give me a bit
<Chipaca> (it's a bug at our end, but there's a workaround if this is the case)
<mikeb_> Chipaca: okay.  Thanks!
 * zyga will work on fixing the migration situation after lunch
<zyga> ttyl!
<pedronis> zyga: rememeber that we setup-profiles twice for core
<pedronis> the first time with old snapd code
<pedronis> the 2nd with new snapd code
<pedronis> and that one has passed managers init at that point
<zyga> pedronis: good point
<zyga> pedronis: thank you!
<pedronis> so need to think a bit exactly what sees what here
<zyga> pedronis: let's discuss this at the call, I think (all) of PRs are unlikely to land today
<Chipaca> mikeb_â huh, that's strange. When trying to do this myself I get an error.
<Chipaca> mikeb_â in that the command can't contain quotes
<Chipaca> mikeb_â so maybe you're in an older version that didn't validate this? i'd say move the long command into a shell script and use that as the command in the yaml
<mikeb_> Chipaca: FYI context - I have a snap that is made up of many .deb packages all with services to start up.  I'm trying to come up with a wrapper that will deal with service before/after/wants/requires/etc as well as the various preinst/postinst/prerm/postrm/etc
<pedronis> zyga: IÂ mean it might turn out that is less to do that we think,  (some fixes don't make sense), though there's the no reexec case as well to keep in mind, we don't reexec everywhere yet, do we?
<mikeb_> Chipaca: I'm running snapcraft 2.28
<Chipaca> mikeb_â sound slike fun
<Chipaca> mikeb_â I get this: error: cannot read snap info for /home/john/canonical/snappy/src/github.com/snapcore/snapd/tests/lib/snaps/test-snapd-service: app description field 'command' contains illegal "bin/start foo bar \"baz quux\"" (legal: '^[A-Za-z0-9/. _#:-]*$')
<mikeb_> Chipaca:  The upstream packages are still changing a lot.  It's more fun to try to manually translate all the service and inst files to snapcraft apps:
<pedronis> Chipaca: seems indeed that we don't support quotes in commands
<pedronis> (never did IÂ think,  maybe we need to ? )
<mikeb_> Chipaca: That's unfortunate...
<Chipaca> mikeb_â however, note you can set a per-app 'environment' entry that does have quotes
<pedronis> Chipaca: not sure though that env var in a command do the right thing
<Chipaca> pedronisâ they get set in the environ of the service
<mikeb_> Chipaca: I hadn't thought to escape my quotes in the yaml file.  That actually seems to be working... almost.  Give me a few to play around a bit more.
<pedronis> though you can always use a wrapper
<Chipaca> Apr 07 12:25:33 fogey snap[17032]: FOO=$'there once was a man from nantucket\nwho was very bad at limericks\n'
<Chipaca> ^ that's from
<Chipaca>   environment:
<Chipaca>     FOO: |
<Chipaca>       there once was a man from nantucket
<Chipaca>       who was very bad at limericks
<Chipaca> makes it all the way through, newlines and all
<pedronis> Chipaca: sorry, what I was saying is that IÂ don't know if:Â  command:Â bin/x $FOO   works
<pedronis> (I suspect not, might be wrong)
<Chipaca> pedronisâ no because $ is not in [A-Za-z0-9/. _#:-]
<pedronis> even if it were
<Chipaca> mikeb_â what version of snapd are you on? (output of âsnap versionâ)
<Chipaca> pedronisâ and, no, environment key is applied by snap run, not by systemd
<pedronis> Chipaca: I don't IÂ understand your suggestion, IÂ mean, it's not a direct transformation
<pedronis> Chipaca: cannot tunr    bin/x "a b"   into   FOO="a b"  bin/x $FOO
<Chipaca> pedronisâ mikeb_ is writing a wrapper for a bunch of services
<Chipaca> pedronisâ for a single snap to handle ordering of services itself
<mikeb_> Chipaca: snapd 2.23.6
<Chipaca> as we don't expose ordering
<mikeb_> among other things...
<pedronis> Chipaca: IÂ think IÂ should give up helping, I don't have context
<Chipaca> pedronisâ as such, he's currently taking a bunch of options to his script from the commandline itself
<Chipaca> but we dont' support that (and apparently we've introduced a breaking change around this between 2.23.6 and now? i need to dig a little)
<pedronis> ah, ok, I though it was tryign to call directly something not under his control
<Chipaca> pedronisâ but instead they *could* take it from environ
<pedronis> yes
<Chipaca> it's probably not as nice
<Chipaca> k? k.
<Chipaca> :-)
<pedronis> working beats nice, IÂ suppose
<Chipaca> mikeb_â I'm on 2.23.6 as well. something doesn't add up :-/
<Chipaca> ah
<pedronis> seems there's confusion around env from yaml working or not
<Chipaca> mikeb_â what's in your *snap.yaml*?
<Chipaca> mikeb_â in prime/meta/snap.yaml
<pedronis> IÂ have seen an open topic about that
<Chipaca> mupâ poke kyrofa
<Chipaca> ah, no ldap
<pedronis> https://forum.snapcraft.io/t/declaratively-defining-environment-variables/175/3
<Chipaca> it's 4am for kyle, i'll ask later
<pedronis> it actually pings you at the end
<pedronis> that topic
<Chipaca> me? nevah!
<pedronis> fwiw
 * Chipaca looks
<pedronis> well Gustavo does
<mikeb_> Chipaca: With the escaped quotes, it seems to be working as I intended.  I'm trying to fix some bugs in my test code right now, but the '--cmd' seems to be getting through now.
<Chipaca> mikeb_â i suspect snapcraft might be helping, hence me asking for your snap.yaml :-)
<mikeb_> Chipaca: Sorry, had to deal with an interrupt.  snap.yaml on the way.
<Chipaca> mikeb_â no worries
<Chipaca> speaking of interrupts, lunch would be nice sometime
<Son_Goku> anyone have any idea why I'm getting this error?
<Son_Goku> - Download snap "core" (1577) from channel "stable" (sha3-384 mismatch after patching "core": got 3ca758bb05ff3a422fffa2c02018aaf63909417180b3e902eaddcf0cbc4d4c317bfe26ac5c39567bc69abb94ece0d1e8 but expected cbdff81206101ef7063f2f91a4c3f36e1ad946fe8a809eca4c21fa5335968dfc0c696e5f364cbc9a4c83590aceb3fc15)
<Chipaca> Son_Gokuâ in tests, or in real life?
<zyga> re
<Son_Goku> real life
<Chipaca> whee
<Son_Goku> I'm trying to do "sudo snap install hello-world"
<Son_Goku> snapd 2.23.6 + Fedora 25
<Chipaca> Son_Gokuâ you crazy bleeding-edger you
<zyga> pedronis: we don't reexec everywhere (reading backlog and responding)
<Chipaca> :-)
<Chipaca> Son_Gokuâ can you pastebin `journalctl -u snapd`? the bit around the install in particular, not the whole thing :-)
<zyga> Son_Goku: I think there's some issue in deltas
<zyga> Son_Goku: I saw michael do some changes there today
<Chipaca> zygaâ michael's change is around the error, which always mentions deltas even if it's not a delta
<zyga> Son_Goku: hey man :) nice to see you today
<zyga> hah
<zyga> I mean, "aha"
<Chipaca> zygaâ you can mean both
<mikeb_> Chipaca:  https://pastebin.com/fc9jN3wd - I added prime/command-test-daemonize-notify.wrapper to the end of the paste.
<Chipaca> riiight
<zyga> ok, I'll get back to the key issue at hand
<Chipaca> mikeb_â so snapcraft is wrapping things for you
<Chipaca> mikeb_â that's why you're not seeing the error about using quotes in there :-)
<Chipaca> but it's doing a bad job of it
<Chipaca> :-)
<Son_Goku> Chipaca, zyga: https://paste.fedoraproject.org/paste/hzxtldZltZyI94LRqVeKr15M1UNdIGYhyRLivL9gydE=
<mikeb_> Chipaca: yes, wrapper for a wrapper for a command.  Fun.  Doesn't snapcraft always generate wrappers for commands?
<Chipaca> mikeb_â probably, yes
<zyga> mikeb_: there's a plan to stop that eventually
<morphis> Son_Goku: doesn't look good but maybe because of a network error?
<morphis> didn't had problems here switching between different core's
 * Son_Goku shrugs
<zyga> how do we compute the has? internally?
<zyga> maybe bug in golang that's fixed in ubuntu or maybe different (subtly) output in an external program?
<zyga> maybe delta?
<Son_Goku> well, we're on golang 1.7.5 on Fedora 25
<zyga> Son_Goku: the reverse may be true :-)
<Son_Goku> it could also just be this VM, but I doubt it
<Son_Goku> well fuck it
<Son_Goku> a reboot fixed everything
 * Son_Goku shrugs
<Son_Goku> Chipaca: lol i dunno anymore
<Son_Goku> maybe my VM was screwy?
<morphis> possible
<morphis> seeing some network issues from time to time here
<Son_Goku> I could have just been lucky, I guess
<Chipaca> fwiw
<Chipaca> we're getting that error in tests
<Chipaca> occasionally
<Chipaca> i suspect the cdn
<Son_Goku> huh
<Son_Goku> maybe related, then
<Son_Goku> well, that would explain corruption in the core snap download
<Chipaca> mhmm
<Son_Goku> and when I tried to fetch it myself, nothing happened :?
<Son_Goku> it timed out
<Chipaca> encouraging
<Son_Goku> well, it worked this time
<davidcalle> Can someone on 16.04 check if snap:// links work? http://www.omgubuntu.co.uk/2017/02/snap-url-support-coming-ubuntu-software-app-plus-love-news
<Son_Goku> so at least it passed the smell test
<Chipaca> Son_Gokuâ that does not make it better (in fact, the opposite :) )
<Son_Goku> Chipaca: I know :(
<Son_Goku> but I'm trying to make sure I didn't screw up everything with my Fedora packaging changes
<Son_Goku> ;)
<Chipaca> davidcalleâ I'm on 16.04, clicked the snap link, it went to xdg-open, which laughed a very deep laugh
<Son_Goku> haha
<Son_Goku> actually, this is interesting
<Chipaca> davidcalleâ actually it returned 0, no error output, so it seems to *think* it worked
<Son_Goku> snapd forced my VM's resolution down to 800x600
<Son_Goku> wtf
<davidcalle> Chipaca, ahaha, ok, no software center popping up?
<Chipaca> davidcalleâ correct
<Chipaca> Son_Gokuâ you need to scale the qubit's strangeness down a notch
<Chipaca> damn quantum-entangled snapd
<morphis> Son_Goku: really?
<davidcalle> Chipaca: thanks for the gunea pigging :)
<Son_Goku> morphis: yes really
<morphis> Son_Goku: do you have the vbox drivers installed?
<Son_Goku> it happened the moment the core snap finished installing
<morphis> Son_Goku: anything in dmesg/journal?
<Son_Goku> no, this is VMware Fusion, so open-vm-tools and regular vmware drivers are used
<zyga> Son_Goku: log out and log in without wayland
<Son_Goku> I'm using Plasma, with Xorg
<zyga> Son_Goku: hmm, then no idea
<zyga> Son_Goku: snapd doesn't touch anything X related
<zyga> Son_Goku: does it work if you remove snapd and reboot?
<Son_Goku> well, everything is fine *after* installing the core snap
<Son_Goku> it's just the act of installing the core snap seems to snap the resolution down to what it is when sddm is launched
<Chipaca> davidcalleâ oink oink (or, rather, squee squee)
<Son_Goku> sddm is Wayland, I think
<zyga> sddm?
<Son_Goku> sddm, Simple Desktop Display Manager
<Son_Goku> from the Hawaii OS (now Liri OS) guys
<Son_Goku> it replaced kdm for Plasma 5
 * zyga says "maaagic"
<zyga> no idea,
<morphis> Son_Goku: btw. can you check with a gui snap too on KDE
<Son_Goku> lol i dunno
<morphis> Son_Goku: like krita
<Son_Goku> morphis: I'm playing ohmygiraffe :)
<morphis> Son_Goku: good, so we're not affected by https://bugzilla.opensuse.org/show_bug.cgi?id=1031501#c3
<Son_Goku> we probably will be once Fedora 25 transitions to Plasma 5.9
<Son_Goku> morphis: Plasma 5.9 tightens the security a little bit
<Son_Goku> I'm still on Plasma 5.8
<Son_Goku> it'll probably fail on Fedora 26 KDE, you should try
<morphis> Son_Goku: yeah maybe
<morphis> Son_Goku: if it does we have a fix for that upcoming
<morphis> not 2.24 bur 2.25 maybe
<morphis> jdstrand: ping
<Son_Goku> morphis, zyga: anyway, I can't give karma for the snapd updates, so I need you guys to do so and find someone get it up to +3 across the board
<Son_Goku> and it has to be someone with a FAS account, because anonymous karma doesn't count for karma :/
<morphis> Son_Goku: yes, I gave +1 already
<morphis> Son_Goku: you think you can find someone
<Son_Goku> I'm going to try
<Son_Goku> morphis: zyga's karma was zeroed out, so he has to do it again
<morphis> yes
<morphis> Son_Goku: I've asked him already but he seems to be under time pressure to get things fixed for 2.24
<zyga> yes, sorry
<morphis> np
<Son_Goku> it only takes a couple of minutes to hit +1s for everything, since he's already tested it :)
<zyga> the clashing names need to be fixed really urgently
<zyga> Son_Goku: I didn't really test the new packages
<zyga> Son_Goku: I'd like to really test them before +1
<zyga> Son_Goku: (I mean after the next upload)
<Son_Goku> the only change is that I added the scriptlet to autostart them
<zyga> ah
<Son_Goku> well, and I bumped to snapd-glib 1.10, but we can't really test that with anything
<zyga> well, I'll +1 after testing it at least once still :)
<zyga> that's the point of the process
<Son_Goku> right
<Son_Goku> I just bundled that update with it because I want the buildsystem error emails to go away...
<Son_Goku> err, dependency error emails
<zyga> (not talking about glib specifically)
<Son_Goku> right
<Son_Goku> well, the sooner snapd and snapd-glib hit stable, the sooner that gnome-software can move to using it entirely
<Son_Goku> (snapd-glib, I mean)
<Son_Goku> because then hughsie will be able to test against it
<zyga> pedronis: looking at snap/*.go, we don't seem to validate loaded yaml's
<zyga> pedronis: validation is in ReadInfoFromSnapFile but I don't see any calls to that yet
<zyga> pedronis: specifically if you look at ReadInfo which is defined just above
<zyga> pedronis: we just don't validate it
<zyga> pedronis: and ReadInfo is used in readInfoAnyway
<zyga> pedronis: which in turn powers CurrentInfo
<zyga> pedronis: so this is both good and bad
<zyga> pedronis: it's bad for obvious reason, we should validate
<zyga> pedronis: it's good that maybe the rollback is "easier" as ... we don't validate
<zyga> pedronis: but I'd like to ask you if this is for a reason, the missing validation
<Chipaca> zygaâ validation is done on ingestion
<Chipaca> currently
<Chipaca> zygaâ which, not as good, we should do it on load, but it's there
<zyga> Chipaca: hmmm
<zyga> Chipaca: any reason not to always validate?
<Chipaca> zygaâ validation needs to be versioned?
<Chipaca> other than that, no
<zyga> Chipaca: I also worry that some "fixups" (see broken.go) are done in other places, it feels like this is responsibility for snap/ (package) to hide and do this internally
<Chipaca> zygaâ i mean, changing validation means patching
<zyga> Chipaca: why?
<zyga> Chipaca: patching as in overlord patches?
<Chipaca> zygaâ because valid state suddenly can become invalid without it
<Chipaca> zygaâ yes
<zyga> aha
<jdstrand> morphis: hey
<zyga> but we don't store info in state?
<morphis> jdstrand: hey!
<zyga> Chipaca: so "state" is still valid
<zyga> Chipaca: we may just notice disk is (and was) invalid
<morphis> jdstrand: I've pushed up an initial version of the Xauthority handling at https://forum.snapcraft.io/t/migrate-x11-authentication-cookies-into-snap-environment/116/10
<jdstrand> morphis: I'll add it to my list
<morphis> jdstrand: and implemented simple parsing of the Xauthority file, is that ok for you to do validation of that file?
<morphis> jdstrand: we don't have the xauth binary everywhere so need another way to handle this
<jdstrand> morphis: I think simple parsing is good enough. I mean, X is supposed to handle it itself and we aren't trying to protect the user from herself
<morphis> right
<morphis> jdstrand: then let me go and prep a PR for this then we can do a proper review
<jdstrand> ok
<ogra_> niemeyer, your opinion on bug 1674509 (regarding the last four/five comments) would be valuable ...
<mup> Bug #1674509: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 <snapd-interface> <Snappy:Confirmed> <linux-raspi2 (Ubuntu):Invalid by p-pisati> <https://launchpad.net/bugs/1674509>
<mikeb_> Chipaca: Just a follow up. It looks like surrounding my command arguments with escaped quote does, in fact, work as expected.  Now I have to figure out why my wrapper'daemonization is not
<mikeb_> working.
<zyga> tvoss: some small reviews on the rsa branch
<zyga> pstolowski: standup?
<tvoss> zyga: thanks, looking
<Son_Goku> zyga: all we need is one more +1 and then snapd rolls out to stable for F25
<Son_Goku> https://bodhi.fedoraproject.org/updates/FEDORA-2017-37a7331620
<zyga> Son_Goku: just after my standup
<zyga> Son_Goku: I'll boot my VMs and try
<zyga> Son_Goku: thanks for tracking this!
<Son_Goku> excellent
<Son_Goku> mhall119: it's happening! :D
<Son_Goku> zyga: if you do it quick enough, it might even sync out today!
<zyga> Son_Goku: I didn't buy 16GB of ram (it's 250 euro) so I'm still on 4G, with that and firefox and chrome I cannot do it now
<Son_Goku> damn
<zyga> Son_Goku: testing f25 server now
 * zyga hugs "dnf install --enablerepo=updates-testing snapd"
<zyga> morphis: F25 server is good to go
<morphis> zyga: great!
<zyga> morphis: added my +1
<zyga> going to try F24 while I wait for 26 alpha to download
<morphis> zyga: what a wonderful weekend present
<zyga> morphis: indeed
<pedronis> niemeyer: it might be easier to do a separate preparatory branch though, because with these decisions AliasesStatus the type goes ways, that's a boring but big diff in itself IÂ think
<mup> PR snapcraft#1242 opened: kernel_plugin: use CROSS_COMPILE to override the default toolchain <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1242>
<niemeyer> pedronis: Happy to follow your guidance on how to organize the changes in the easiest way
<Chipaca> SLIGHTLY_UPSET_COMPILE
<pedronis> niemeyer: thanks, I'll try and see just how big that is and go fromt there
<zyga> Chipaca: ?
<Chipaca> zygaâ CROSS_COMPILE?
<ogra_> zyga, that was a reaction to the PR line i think :)#
<zyga> ah
<zyga> I missed that :)
<zyga> (got used to ignoring what humble mup says)
<zyga> does ext4 do background initialization
<zyga> so you can format quickly
<zyga> and it will finish it in the background over time?
<niemeyer> ogra_: Replied in the bug
<morphis> zyga, niemeyer: what kind of ubuntu images are you using on Linode as a base? regular cloud images?
<Pharaoh_Atem> zyga: snapd for Fedora 24 needs +1 karma to go stable: https://bodhi.fedoraproject.org/updates/FEDORA-2017-ce0fdd87a4
<zyga> morphis: we use ubuntu images that were modified to be like vanilla ubunut, that is booting with grub and with ubuntu kernel
<zyga> Pharaoh_Atem: 24 is next on my list
<Pharaoh_Atem> F25 and F26 have the karma to go stable
<Pharaoh_Atem> so F24 is key now
<zyga> Pharaoh_Atem: oh great, I will test 24 and skip 26 then
<zyga> I reverted to the initial install snapshot
<zyga> so "dnf update" takes a long while
<tvoss> pedronis: so I'm looking into the BIO mem_buf stuff, encoding the key to a mem_buf BIO fails (not due to insufficient memory). Investigating
<morphis> zyga: ok, wondering if we can just use the official openstack debian images as a base and initialize them once via cloud-init
<morphis> Pharaoh_Atem: looks like F25 is close now :-)
<morphis> Pharaoh_Atem: who is the third one who gave +1 for F25?
<zyga> morphis: seems very sensible
<morphis> ok
<Pharaoh_Atem> morphis: decathorpe (Fabio Valentini)
<Pharaoh_Atem> he's the guy packaging Pantheon Desktop for Fedora
<Pharaoh_Atem> I asked him to test it out :)
<Pharaoh_Atem> GL is busted with nvidia on Fedora, though
<Pharaoh_Atem> it crashed for him when he tried to use ohmygiraffe
<pedronis> tvoss: ok, IÂ hope it can be made to work
<zyga> Pharaoh_Atem: that's expected :/
<zyga> Pharaoh_Atem: we need to redesign that
 * zyga wishes he had more ram and maybe dedicated, non-spare-junk HDD for the VMs
<morphis> Pharaoh_Atem: nvidia is still broken?
<Pharaoh_Atem> Yep
<zyga> morphis: yes, there was never support for fedora+nvidia
<zyga> Pharaoh_Atem: tell me, is Fabio using drivers from the archive (if so, which package) or from nvidia directly?
<Pharaoh_Atem> from the negativo17 repository, I believe
<Pharaoh_Atem> or rpmfusion
<Pharaoh_Atem> one of the two
<zyga> Pharaoh_Atem: ok
<zyga> I know how to fix it, just not a high priority (yet)
<zyga> and no time (yet)
<zyga> first need to get mount world in order
<morphis> zyga: feel free to give me pointers for a fix
<zyga> morphis: we don't print anything useful on isntall
<zyga> morphis: we should say "please log out to get PATH updates"
<zyga> or similar useful advice
<zyga> morphis, Pharaoh_Atem: there are selinux denials because of loopback mounted snaps
<zyga> for the gnome-shell
<Pharaoh_Atem> :/
 * Pharaoh_Atem makes a note to set up a Fedora Workstation system
<zyga> type=AVC msg=audit(1491576072.251:282): avc:  denied  { getattr } for  pid=1044 comm="gnome-shell" path="/dev/loop-control" dev="devtmpfs" ino=16235 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:loop_control_device_t:s0 tclass=chr_file permissive=0
<zyga> can we correct that from snapd-selinux
<zyga> I suspect it should go to gnome-shell selinux directly too
<Pharaoh_Atem> we cannot
<Pharaoh_Atem> well, we *could*
<Pharaoh_Atem> the gnome guys would kill us, though
<morphis> :-D
<morphis> I think there is a reason why this is denied for gnome-shell
<Pharaoh_Atem> yeah
<Pharaoh_Atem> it's out of scope for snapd-selinux anyway
<morphis> but why is it trying to do this at all?
<Pharaoh_Atem> maybe it's probing disks?
<zyga> morphis, Pharaoh_Atem: let's file a bug and correct this in the main policy
<zyga> Pharaoh_Atem: yes, I suspect so
<zyga> type=AVC msg=audit(1491575811.619:770): avc:  denied  { create } for  pid=39655 comm="systemctl" name="var-lib-snapd-snap-hello\x2dworld-27.mount" scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:systemd_unit_file_t:s0 tclass=lnk_file permissive=1
<zyga> I have 50 selinux denials after installing hello-world and rebooting in workstation
<morphis> Pharaoh_Atem, zyga: yeah lets get a bug and lets see why this happens and where we fix the best way
<zyga> Pharaoh_Atem: shall I report those on bugzilla now?
<Pharaoh_Atem> Yes
<zyga> kk
<zyga> Pharaoh_Atem: on redhat bugzilla, under fedora?
<Pharaoh_Atem> yes
<Pharaoh_Atem> component would be the source package name
<zyga> ok
<Pharaoh_Atem> well, at least the snappy denials are occurring permissively :D
<zyga> Pharaoh_Atem: yeah but for gnome-shell it is a real denial
<Pharaoh_Atem> yeah
<morphis> zyga: yeah something we need to fix
<zyga> morphis: I would love to get rid of the myriad of denials too
<zyga> morphis: even if they are in complain mode
<zyga> morphis: 100% of the users will see that
<zyga> and it's just annoying
<morphis> yes
<morphis> Pharaoh_Atem, zyga: so do we hold the release back until early next week?
<zyga> https://bugzilla.redhat.com/show_bug.cgi?id=1440207
<zyga> morphis: no, I think we can release
<zyga> morphis: release, iterate
<morphis> zyga: fine for me
<zyga> morphis: can you install f25 workstation
<zyga> morphis: snapshot it, install snapd + hello-world
<zyga> morphis: and file all the bugs (on snapd in bugzilla) for each unique denial
<zyga> morphis: it will be a while but I think that's the way to track them
<zyga> morphis: I can help this weekend as I was hoping to see something selinux for a while
<zyga> morphis: maybe I can squash one or two
<morphis> zyga: can do this on monday, for today I want to finish what I have currently
<zyga> morphis: ok
<zyga> morphis: let me do one as an example
<morphis> ok
<zyga> Pharaoh_Atem, morphis: https://bugzilla.redhat.com/show_bug.cgi?id=1440208
<zyga> suggestions on how to report those are welcome
<zyga> morphis: fixing those might take a while but we should at least fix the majority that may be as easy as a few extra rules in the policy
<morphis> yeah
<zyga> ok, booting f24 now
<morphis> zyga: can you add them to https://trello.com/c/Fvtml6A1/26-fedora-fix-selinux-denials ?
<morphis> zyga: the bug links I mean
<zyga> morphis: trello
<zyga> morphis: no, trello is dead
<morphis> zyga: it isn't :-)
<morphis> that is for my cross-distro work
<morphis> nothing else
<zyga> morphis: let's be consistent
<zyga> morphis: if anything use the forum
<morphis> zyga: lets not discuss this here, this has a different scope but I am fine with a forum post for this too
<zyga> morphis: +
<zyga> morphis: +1
<Pharaoh_Atem> zyga: are you able to give the F24 update a +1 yet?
<zyga> Pharaoh_Atem: yes, now mid way dnf update
<zyga> Pharaoh_Atem: at 335/763 updates
 * Pharaoh_Atem is trying to beat the clock for when bodhi mash starts
<zyga> Pharaoh_Atem: when is that?
<zyga> Pharaoh_Atem: I will be ready in 10-15 minutes
<zyga> (437 now)
<Pharaoh_Atem> I don't know
<Pharaoh_Atem> it's usually around now
<zyga> aha
<zyga> well
<zyga> if we miss it, when is the next one?
<zyga> daily
<zyga> ?
<Pharaoh_Atem> lemme check
<zyga> thank you
<tvoss> pedronis: I'll take a quick break
<zyga> 500/763 updates
<zyga> some updates are bigger than others...
<ogra_> thanks for implanting sesame street music in my head now...
<Pharaoh_Atem> zyga: it's irregular, but it happens about once a day
<zyga> 620 now
<zyga> still more than 10 minutes away I suspect, then all the disk IO starts and reboot and more installs
<Pharaoh_Atem> you know, you didn't have to do a full update...
<zyga> this is f24 vanilla iso install
<zyga> I wanted it to be more realistic
<Pharaoh_Atem> oh dear
<Pharaoh_Atem> wow
<Pharaoh_Atem> you reset all the way back to GA?
<zyga> (as I said, snapshot :)
<zyga> 741 now
<zyga> DRPMs now
<pedronis> pstolowski: I tried quickly, the issue is simply that json doesn't work with map[interface{}]interface{}
<pedronis> (even if the value have correct types)
<pstolowski> pedronis, yes, in fact json spec says only strings can be used as keys
<jfmcarreira> heyyy guys
<jfmcarreira> any help on this error? cannot create user data directory: /nfs/home/jcarreira.it/snap/vlc/x1: Read-only file system
<zyga> jfmcarreira: hey
<ogra_> jfmcarreira, looks like you are not trying to write to $SNAP_DATA but to $SNAP
<zyga> to put your home directory on NFS you need to do some extra things
<zyga> jfmcarreira: there's a bug report with details on launchpad
<ogra_> (or rather $SNAP_USER_DATA in your case)
<ogra_> oh
<zyga> jfmcarreira: I cannot find it now (busy)
<ogra_> ignore me
<zyga> jfmcarreira: but quick suggestion:
<ogra_> zyga, is right
<zyga> jfmcarreira: for now you will have issues with network denials and this is a kernel/nfs limitation
<zyga> jfmcarreira: if you --bind mount your home directory under /home/ you will have a better experience
<zyga> jfmcarreira: but it won't work really
<pedronis> pstolowski: yes, but this is an implementation detail, it could go over the key and still do the job if they are strings, but it doesn't
<pedronis> pstolowski: anyway wrote a bit more in the forum
<pstolowski> pedronis, ty
<jfmcarreira> zyga: ok thanks for the help.. but i only have ubuntu on a NFS system
<zyga> Pharaoh_Atem: finally updated
<zyga> hmm, I don't get tab-completion on fc24
<zyga> morphis, Pharaoh_Atem: we don't install tab completion files
<Pharaoh_Atem> do we have tab completion files to install?
<morphis> Pharaoh_Atem: yes
<zyga> Pharaoh_Atem: yes
<zyga> Pharaoh_Atem: I do that in suse
<zyga> Pharaoh_Atem: it's just one file really
<Pharaoh_Atem> well gee, I wish I had known :/
<morphis> Pharaoh_Atem: no bad, lets do it with the next release :-)
<zyga> Pharaoh_Atem: (and thanks to Chipaca's magic) they will now tab complete into snaps with confinement (really nice code to read)
<Chipaca> *blush*
 * zyga hugs Chipaca 
<zyga> really great stuff!
<zyga> Pharaoh_Atem: +1 to release
<Pharaoh_Atem> doesn't help me here :)
<Pharaoh_Atem> https://bodhi.fedoraproject.org/updates/FEDORA-2017-ce0fdd87a4
<zyga> Pharaoh_Atem: I was typing it there already :D
<zyga> Pharaoh_Atem: saved
<zyga> Pharaoh_Atem: after this is out I'll gladly get my feet wet and make a few trivial suggestions
<zyga> Pharaoh_Atem: do we need +3 for F24 / F26?
<Pharaoh_Atem> nope
<Pharaoh_Atem> I lowered the karma req so that they'd all make it
<zyga> ok
<Pharaoh_Atem> though feel free to add feedback there too :)
<zyga> I'll test 26 now
<zyga> and EOD
<Pharaoh_Atem> okay
<zyga> the 2.24 issues are for next week or this evening, I have some ideas but too taxed mentally today
<zyga> oh one more thing
<zyga> Pharaoh_Atem, morphis: do you have any fedora booted?
<zyga> I just shut down to install 26
<zyga> what does "snap version" say?
<zyga> is it correct?
<zyga> Pharaoh_Atem: release release release
<Pharaoh_Atem> zyga: looks like it already mashed... https://bodhi.fedoraproject.org/masher/
<Pharaoh_Atem> :(
<Pharaoh_Atem> zyga: it'll mash again early tomorrow, I think
<Pharaoh_Atem> though it may happen earlier, who knows
<zyga> Pharaoh_Atem: that's fine
<zyga> Pharaoh_Atem: so once this is out can we do the tab completion and some tweaks over weekend?
<Pharaoh_Atem> zyga: yeah
<zyga> Pharaoh_Atem: great, I'll do that
<mup> PR snapcraft#1240 closed: cli: improve push output <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1240>
<jdstrand> niemeyer: hi! :) re 'I'd put that ahead of pretty much anything else'> were you talking to me or Sergio?
<niemeyer> Oops.. fixing :)
<jdstrand> ok. I'll get to that other bit. it is slowly moving up the list
<niemeyer> Thanks
<mup> PR snapd#3155 opened: snapstate: simplify AliasesStatus down to just an AutoAliasesDisabled bool flag (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3155>
 * zyga takes a break now
<pedronis> niemeyer: created snapd#3155 and then used it to simplify snapd#3087
<mup> PR snapd#3155: snapstate: simplify AliasesStatus down to just an AutoAliasesDisabled bool flag (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3155>
<mup> PR snapd#3087: overlord/snapstate: introduce tasks for aliases v2 semantics with temporary names for now (aliases v2) <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3087>
<niemeyer> pedronis: Thanks!
<niemeyer> pedronis: Tests filaed on 3155.. the issue mvo reported with checksum problems on partial downloads
<niemeyer> Retrying
<pedronis> thanks
<morphis> zyga: https://paste.ubuntu.com/24335332/ doesn't look bad for the first day working on this :-)
<niemeyer> Taking a break
<Guest123> Is it possible to install Ubuntu Core without an Ubuntu One account?
<kyrofa> Guest123, install, yes. SSH into, no
<Guest123> Is it possible to install Ubuntu Core without an Ubuntu One account?
<coreycb> sergiusens_, hi, i added some details to bug 1675479. i have a work around but i'm not sure what's different in our environments that you weren't able to reproduce.
<mup> Bug #1675479: python plugin doesn't work for namespace packages <openstack> <plugin> <Snapcraft:New> <https://launchpad.net/bugs/1675479>
<coreycb> sergiusens_, probably can lower that from high though since i have a workaround
<tvoss> okay, when using unsafe.Pointer, is ownership transferred to the go runtime?
<tvoss> s/unsafe.Pointer/C.GoBytes/
<tvoss> pedronis: done,just updated the PR with changes to avoid file operations
<jdstrand> sabdfl: fyi, I already started poking at wayland: https://forum.snapcraft.io/t/wayland-dconf-and-xdg-runtime-dir/186/2
<jdstrand> sabdfl: I've got gnome/wayland now running on my laptop and plan to work on the initial interfaces
<kyrofa> jdstrand, nice
<jdstrand> sabdfl: (fyi based on backscroll from earlier today)
<jdstrand> it's kinda interesting cause snaps with gnome/wayland/portals should be a nice desktop security story
<mup> PR snapcraft#1243 opened: tests: update the location of the upstream retry autopkgtests script <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1243>
<sabdfl> hi jdstrand, thank you
<sabdfl> yes i think we can bring those two ideas together very neatly
<sabdfl> portals bear a startling resemblance to helpers so all the concepts are in place
<sabdfl> and i'll be glad to have snaps be first class across all the major desktops
<jdstrand> indeed
<jdstrand> and they do bear a startling resemblance to helpers-- they were clearly inspired by our work :)
<ahoneybun> sabdfl: are you taking about the flavors?
<sabdfl> ahoneybun, and upstream
<ahoneybun> right other distros too then
 * ahoneybun dreams of a snap that can detect the desktop (gtk, qt) and change the UI to that
<mup> PR snapcraft#1243 closed: tests: update the location of the upstream retry autopkgtests script <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1243>
<lutostag> anybody know how to set dns servers on core 16?
#snappy 2017-04-08
<thresh> hi.  I'm getting the following when trying to build a snap on Zesty: Error downloading stage packages for part 'desktop-qt5': The Ubuntu package 'appmenu-qt5' was not found
<thresh> it broke ~20 days ago.  how would I go about fixing it?
<mup> PR snapcraft#1244 opened: Add KDE Neon as supported distribution <Created by phanect> <https://github.com/snapcore/snapcraft/pull/1244>
<bulld> qt 5.5.1 app showing different cursor when packaged as snap
<bulld> here is how it look like http://imgur.com/a/0yitF
<bulld> any help
<bulld> i have to release my app to store after fixing this issue
<bulld> :(
<mup> PR snapd#3155 closed: snapstate: simplify AliasesStatus down to just an AutoAliasesDisabled bool flag (aliases v2) <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3155>
<karl_> Hi! I'm getting the following output when trying to start spotify (installed via snappy) https://paste.ubuntu.com/24342350/ A window shows up, but when I click login the login popup just blinks away Ubuntu 16.10
<karl_> at least the canberra-gtk-module is installed, but maybe it can't be reached for some reason
<mup> PR snapcraft#1245 opened: nodejs plugin: add support for yarn <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1245>
<mup> PR snapcraft#1244 closed: repo: enable KDE Neon <Created by phanect> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1244>
#snappy 2017-04-09
<Mirv> thresh: hmm, that's a tricky one. appmenu-qt5 got removed from zesty because the functionality is now in upstream Qt. but the package is required on xenial. file an issue at https://github.com/ubuntu/snapcraft-desktop-helpers would be a good start.
<thresh> Mirv, oh thanks.  Looks like it's already there: https://github.com/ubuntu/snapcraft-desktop-helpers/issues/62
<mup> PR snapcraft#1239 closed: catkin plugin: create completely valid environment <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1239>
#snappy 2018-04-02
<mup> Issue snapcraft#2044 opened: snap install process creates empty dirs on Home folder <Created by mmartinortiz> <https://github.com/snapcore/snapcraft/issue/2044>
<petan> how can I register an URI protocol so that my app is launched when someone clicks a link in browser?
<petan> is there any snappy option for this?
<petan> my app is irc client so I want to register irc:// and ircs://
<Mavrik> Hi, I'm having trouble finding in documentation on how to exclude a part from the final snap when defining snapcraft.yaml - I have parts that are essentially only build dependencies and their binaries shouldn't be included in the final snap. Any ideas?
<kyrofa> Mavrik, definitely-- you want to use the `prime` keyword to filter the entire part out
<kyrofa> Mavrik, let me find you an example
<kyrofa> Mavrik, here, boost is a part only needed to build mysql, and shouldn't be shipped in the final snap. Using the `prime` keyword, it is filtered out like this: https://github.com/nextcloud/nextcloud-snap/blob/master/snap/snapcraft.yaml#L246
<Mavrik> oh, hmm, lemme try this
<Mavrik> Yup, that did it. Thanks!
<kyrofa> Sure thing
<kyrofa> Mavrik, the syntax for these keywords is here, for future reference: https://docs.snapcraft.io/build-snaps/syntax
<kyrofa> Er, documentation, rather
<Mavrik> Yeah, I found that, I just didn't think of just wildcarding everything out.
<mup> PR snapcraft#2041 closed: kernel plugin: add kmod as build-package <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2041>
<mup> PR snapcraft#1930 closed: lxd: friendly errror with suggestions if network is broken <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1930>
<Mavrik> Hmm, another question - binary in my snap has to invoke a binary in /usr/local/bin or /usr/share/bin of the installed system. As I see, "strict" confinement prevents this. Any way to ask for access ?
<mup> Bug #1746710 opened: Snap creates redundant duplicate directories in home folder <amd64> <apport-bug> <artful> <bionic> <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1746710>
<kyrofa> Mavrik, no, that sort of defeats the purpose of confinement. Is there a reason you can't bundle these applications within the snap itself?
<kyrofa> You can use a different confinement type if necessary, but that depends on the use-case
<Mavrik> My tool is invoking "adb" from Android SDK which spawns a daemon on first invocation.
<Mavrik> And there's a plethora of problems if you invoke different versions of adb one after another.
<kyrofa> How do you ensure adb is actually installed?
<Mavrik> So if I package adb with my snap and the user is an Android developer, it'll interfere with their Android Studio IDE
<Mavrik> Hmm, the documentation implied I should use stage-packages: android-tools-adb for this
<Mavrik> To basically add system dependency.
<kyrofa> Mavrik, stage-packages get placed into the snap
<Mavrik> (I'm also opening a forum thread to see if there's a better way.)
<Mavrik> Ah.
<Mavrik> Hrmf.
<kyrofa> You can use classic confinement (i.e. unconfined) if such access is required, but that's subject to a more thorough review
<Mavrik> yeah, that's fine with me for now
<mup> PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#22 closed: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<mup> PR core-build#26 closed: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
<Mavrik> I'll open a topic as the review system demands and see what the conclusion is :)
<mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#22 opened: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<mup> PR core-build#26 opened: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
<mup> PR core-build#22 closed: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<mup> PR core-build#26 closed: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
<mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#22 opened: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<mup> PR core-build#26 opened: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
<mup> Issue snapcraft#2044 closed: snap install process creates empty dirs on Home folder <Created by mmartinortiz> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/2044>
<kyrofa> jdstrand, I'm getting a store review failure I've never seen before, and I haven't changed anything in the snap: found errors in file output: unusual mode 'rwxr-sr-x' for entry './error/include', unusual mode 'rwxr-sr-x' for entry './icons/small' security-snap-v2_squashfs_files
<kyrofa> The snap is being built on launchpad
<kyrofa> Any ideas?
<kyrofa> They're all failing that way, now
<kyrofa> Also, when I download the snap, I don't see that: drwxr-xr-x 2 kyrofa kyrofa  4096 Apr  2 09:48 include
<kyrofa> drwxr-xr-x 2 kyrofa kyrofa  12288 Apr  2 09:48 small
<jdstrand> kyrofa: you are shipping setgid files. don't do that
<jdstrand> hmm
<kyrofa> jdstrand, not that I can see
<jdstrand> kyrofa: what is the snap?
<kyrofa> jdstrand, here's a failed rev: https://dashboard.snapcraft.io/snaps/nextcloud/revisions/6106/
<jdstrand> kyrofa: by 'download the snap', you mean you are running unsquashfs and then examining? if so, unless you do that as root, the setgid bit is stripped. you can use 'unsquashfs -lls <snap>'
<jdstrand> kyrofa: $ unsquashfs -lls /home/jamie/Desktop/njObIbGQEaVx1H4nyWxchk1i8opy4h54_6106.snap | grep error/include
<jdstrand> drwxr-sr-x root/root                81 2018-04-02 11:48 squashfs-root/error/include
<jdstrand> ...
<kyrofa> Ah, yes that's what I meant
<kyrofa> Huh. jdstrand did we just add that check?
<kyrofa> I haven't changed anything, I'm not even sure which part is providing these files
<jdstrand> kyrofa: no. been there for ages
<kyrofa> How odd
<jdstrand> snapcraft is supposed to clean those up afaik
<jdstrand> maybe that cleanup changed?
<kyrofa> That's possible
<kyrofa> Not because anything changed of which I'm aware, but because a new snapcraft was released relatively recently
<kyrofa> Oh, Apache is doing this
<kyrofa> Yeah, what the heck-- the Apache tarball ships with setgid dirs
<mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR # closed: snapd#3963, snapd#4358, snapd#4369, snapd#4387, snapd#4399, snapd#4416, snapd#4443, snapd#4497, snapd#4504, snapd#4509, snapd#4510, snapd#4538, snapd#4545, snapd#4551, snapd#4562, snapd#4588, snapd#4600, snapd#4700, snapd#4750, snapd#4767, snapd#4790, snapd#4805, snapd#4832,
<mup> snapd#4833, snapd#4840, snapd#4844, snapd#4845, snapd#4868, snapd#4873, snapd#4880, snapd#4889, snapd#4900, snapd#4911, snapd#4917, snapd#4930, snapd#4938, snapd#4940, snapd#4942, snapd#4951, snapd#4957, snapd#4965, snapd#4967
<mup> PR # opened: snapd#3963, snapd#4358, snapd#4369, snapd#4387, snapd#4399, snapd#4416, snapd#4443, snapd#4497, snapd#4504, snapd#4509, snapd#4510, snapd#4538, snapd#4545, snapd#4551, snapd#4562, snapd#4588, snapd#4600, snapd#4700, snapd#4750, snapd#4767, snapd#4790, snapd#4805, snapd#4832,
<mup> snapd#4833, snapd#4840, snapd#4844, snapd#4845, snapd#4868, snapd#4873, snapd#4880, snapd#4889, snapd#4900, snapd#4911, snapd#4917, snapd#4930, snapd#4938, snapd#4940, snapd#4942, snapd#4951, snapd#4957, snapd#4965, snapd#4967
<cwayne> jeeze mup
<popey> cwayne: do you know who 'owns' the network-manager snap?
<cwayne> popey: abeato I think (or more generally, anewman's team)
<popey> ah okay.
<popey> anewman: hello. :) is it possible to get nmtui added to the network-manager snap?
<cwayne> Is there an issue with it?
<cwayne> Ah
<popey> nmtui is a great UI for connecting to networks, nmcli is not
<anewman> popey: is this for use on Ubuntu Core?
<popey> yes
<anewman> Okay. The most common user of network manager is a management system of some sort speaking d-bus so we havenât been super focused on UI. We also have some snap configure hooks for basic settings.
<popey> ok. I have installed core on a laptop and am using it like a weird person might
<anewman> Is nmtui part of network-manager itself? If so, that seems pretty straightforward.
<popey> on ubuntu proper it's in the network-manager package
<anewman> So we probably just stripped it out to keep the dependencies at a minimum. Sounds simple.
<anewman> popey: reckon you could file a bug here: https://launchpad.net/snappy-hwe-snaps
<popey> sho thang
<popey> done
<popey> jdstrand: i am getting the snap review fail for emoj. It's a command line tool and I added x11 because it uses xsel, but doesn't need a desktop file
<popey> https://dashboard.snapcraft.io/snaps/emoj/revisions/19/
<mup> Bug #1746710 changed: Snap creates redundant duplicate directories in home folder <amd64> <apport-bug> <artful> <bionic> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1746710>
<popeycore> huzzah. irssi on ubuntu core.
<popey> jdstrand: do you know what the plan is for a classic interface?
<popey> https://forum.snapcraft.io/t/classic-interface/4806 :)
<mup> PR snapcraft#2045 opened: many: add override-pull scriptlet <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2045>
<jdstrand> popey: not any more than what you asked about, no
<popey> ah okay.
<popey> it's a bummer not being able to run more than one thing at once on a core system
<Caelum> zyga: ping
<Caelum> zyga: guy I know from linux gaming discord who is deeply involved in oS suggested another addition to your canonical-docs PR, also update Leap version from 42.2 to 42.3
#snappy 2018-04-03
<zyga> Caelum: Yeah, Good idea. I will mÄkÄ that change unless already did
<zyga> Iâm back tomorrow
<Caelum> awesome, thank you!
<mwhudson> so is there any way to tell patchelf to leave certain files alone? https://launchpadlibrarian.net/363045593/buildlog_snap_ubuntu_xenial_ppc64el_go110_BUILDING.txt.gz
<mwhudson> the hints in the log seem to be about how to exclude the file, which i don't really want to do
<mborzecki> morning
<mborzecki> mvo: morning
<mvo> hey mborzecki ! good morning
<mvo> mborzecki: how are things? any fires?
<mborzecki> mvo: not that i'm aware of
<mvo> mborzecki: excellent
<mvo> mborzecki: I see the list of open PRs is also relatively tame
<mborzecki> mvo: yes, zyga was doing the 'trimming'
<mvo> mborzecki: nice!
<mvo> 4967 needs a "review" :)
<mvo> (just changelog updates so not really much of a review9
<mvo> )
<zyga> Hey
<zyga> Iâm trying to wake up
<zyga> Sorry for being late
<mvo> zyga: good morning!
<zyga> Good morning
<mvo> zyga: how are you? any issues that need attention?
<zyga>  Sleepy :-)
<zyga> I think one issue needs attention.  The release, I didnât publish the build to beta that day.
<mvo> zyga: ok, on it
<mvo> zyga: done
<zyga> Thank you
<zyga> I noticed a new recurring test failure
<zyga>     - google:debian-9-64:tests/main/interfaces-network fails very often, though not all the time
<zyga> and the failure looks real
<zyga> typical failure of the network test on debian https://www.irccloud.com/pastebin/KujuZdgP/
<FeelAporl> License error in discord app showing Up! https://paste.ubuntu.com/p/yHcHWGH2z2/
<kalikiana> good morning
<zyga> hey kalikiana
<zyga> mvo: I found an interesting bug
<zyga> snaps cannot be refreshed concurrently with core when reexec is supported https://www.irccloud.com/pastebin/46PfLThC/
<zyga> as snapd restarts and snapctl doesn't run
<mvo> zyga: uh, indeed
<zyga> we could sort the refresh list so that snapd-carrier is always first
<zyga> and make it so that core refresh blocks all the other guys
<zyga> but not sure how since they are in lanes
<zyga> we could perhaps make concurrentl downloads but apply them one by one
<zyga> (so lane some part but not all of it0
<zyga> but it would be a bigger redesign
<mvo> zyga: yeah, or we ensure core is done last
<mvo> zyga: fwiw, the nvidia fix works for me (tm) on bionic - thanks mborzecki for this!
<mborzecki> mvo: yay!
<zyga> I chose core first because of assumes: snapdXY
<zyga> mvo: can we have a "bug" tag on the forum?
<mvo> zyga: sure, I think you can add tags yourself
<zyga> oh, thanks, I didn't see that
<mvo> zyga: just write them and I think they appear. I'm not fully sure though, I did not use them much in the past (only for releases)
<zyga> mvo: I don't think I can do that actually
<zyga> mvo: anywy, I tried to capture this so that we don't forget: https://forum.snapcraft.io/t/musnt-refresh-core-concurrently-with-other-snaps-when-reexec-is-supported/4841
<pstolowski> morning
<pstolowski> do we have a fire with a configure hook?
<mvo> pstolowski: good morning! not really a fire more a bit of a wart: https://forum.snapcraft.io/t/musnt-refresh-core-concurrently-with-other-snaps-when-reexec-is-supported/4841 but we should fix it as it leaves ugly errors in the `snap changes`
<zyga> hey hey pawel
<mborzecki> pstolowski: hey
<pstolowski> o/
<zyga> pstolowski: I added some feedback to https://github.com/snapcore/snapd/pull/4917
<mup> PR #4917: repo: added repo ConnectionsInfo method (for the new snap connections API) <Created by stolowski> <https://github.com/snapcore/snapd/pull/4917>
<zyga> but I think it's close to landing otherwise
<zyga> though I think it warrants a gustavo/pedronis review
<pstolowski> zyga: thank you, i need to revisit this
<zyga> sure
<zyga> mvo: how do you feel about https://github.com/snapcore/snapd/pull/4911
<mup> PR #4911: daemon,client: add build-id to /v2/system-info <Created by mvo5> <https://github.com/snapcore/snapd/pull/4911>
<zyga> we can rebase it to make tests pass
<zyga> but we could also close it
<zyga> mborzecki: I have a question about https://github.com/snapcore/snapd/pull/4880
<mup> PR #4880: [RFC] cmd, data: plain make  <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4880>
<zyga> mborzecki: can we please close it, add a makefile and switch to it gradually
<zyga> mborzecki: it'd be easier to review and I have some strong opinions about how to use plain make to its full extent
<mborzecki> zyga: can you leave some comments on what you have in mind there?
<zyga> mborzecki: well, it's a lot of little thing
<zyga> *things
<zyga> I'm mainly saying it's easier to discuss this in PRs when the scope is smaller
<zyga> mborzecki: let me propose some skeletons to show what I mean
<zyga> but I need to finish trespassing branch first
<zyga> so in the afternoon
<mborzecki> zyga: ok, i'll close it for now
<mup> PR snapd#4880 closed: [RFC] cmd, data: plain make  <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4880>
 * zyga is once again reaffirmed that terminus is the best font for low-dpi displays
<mborzecki> morphis: can you take a look at https://github.com/morphis/meta-snappy/pull/17 ?
<mup> PR morphis/meta-snappy#17: updates: snapd 2.32.2, libseccomp 2.3.3 <Created by bboozzoo> <https://github.com/morphis/meta-snappy/pull/17>
<morphis> mborzecki: sure
<mborzecki> morphis: thanks
<zyga> brb
<seb128> mvo, hey, how are you? had a good easter w.e?
<mvo> seb128: hey, good morning! I had a really nice weekend, thank you. how are you?
<seb128> mvo, I'm good, thanks! I had a long relaxing w.e :) but now back to bionic crazyness :/
<seb128> mvo, did you see https://forum.snapcraft.io/t/translation-management/4798 ? is that something you could help with ? ;)
<seb128> mvo, basically how is snapd setup for translations? do you import the translation work from launchpad to github?
<mvo> seb128: I have seen it but not thought about it yet. we do not currently merge the translations back but we could easily do this of course
<mvo> seb128: and I think we have to for the benefit of the other distros
<seb128> mvo, do you have translators on github?
<mvo> seb128: I mean, for ubuntu langpacks are probably ok
<seb128> right
<mvo> seb128: not really, LP seems to be the better choice here
<seb128> but even on ubuntu, the template was outdated on launchpad
<seb128> Gunnar updated it manuallys
<seb128> -s
<seb128> so at least translators can do their job now, but it made us wonder what was the expected workflow around snapd translations
<mvo> seb128: uh, I though we had setup auto-sync :/ I need to look into this, we certainly want the auto-imported snapd LP tree for the translations
<seb128> k
<mvo> seb128: tbh we just had not put enough effort into the translations and to support them, but now is a good time to fix that I think
<Chipaca> moin moin
<seb128> mvo, k, well let me know if I can do anything to help. I think that with the template update from Gunnar translators can do their work, you might just want to do an export/import of those in github a bit later for other distros as you said
<seb128> mvo, and I'm going to keep an eye on what's going on with the template import, the package build generated a correct one but somehow launchpad ended up not having all the strings until Gunnar workarounded it
<Chipaca> is there an automated way to export it, so we can add it to the other distros build scrips?
<mvo> seb128: I look into it once I finished my current task
<seb128> mvo, thx
<seb128> Chipaca, launchpad can auto export to a branch/vcs I think
<zyga> Chipaca: hello
<Chipaca> zyga: hiya
<zyga> mvo: hey, do you think we could seed langpacks-all into the core as an experiment?
<Chipaca> zyga: did you see #1760416?
<zyga> Chipaca: how have you been? :)
<mup> Bug #1760416: dropping privs did not work: Invalid argument <amd64> <apport-bug> <artful> <wayland-session> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1760416>
<zyga> oh, nope
<Chipaca> zyga: very lazy :D
<zyga> bummer, that's something nasty
<Chipaca> was tempted into looking at snapd things only twice in the last week \o/
<mborzecki> zyga: can you do antoher pass of #4942
<mup> PR #4942: cmd/snap: user session application autostart v3 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4942>
<zyga> mborzecki: queued, now looking into the bug chipaca referenced
<mborzecki> zyga: thanks
<zyga> I cannot reproduce that bug on bionic
<zyga> trying artful
<zyga> same
<zyga> is anyone on artful that can reproduce that bug?
<zyga> just running any snap should fail
<zyga> that code is on an unconditional code path
<mborzecki> zyga: any idea what's happening with fedora?
<zyga> in which sense?
<mborzecki> zyga: i mean the go build thing
<zyga> ah
<zyga> the one that was failing last week
<zyga> yes
<zyga> downstream package for gopkg.in/yaml.v2 was broken
<zyga> I added some information about this here: https://github.com/snapcore/snapd/pull/4832#issuecomment-377539457
<mup> PR #4832: tests: move fedora 27 to google backend <Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4832>
<mborzecki> zyga: https://src.fedoraproject.org/rpms/golang-gopkg-yaml/pull-request/1 ??
<zyga> maybe Pharaoh_Atem can help us speed up landing and releasing this
<zyga> as it's a terribly broken package now
<zyga> (out in stable)
<kjackal> Hey snappy people! Is there a way to disable elf stripping?
<zyga> kjackal: hey
<kjackal> 2.40 is breaking at least one of our banaries and trying to see why
<kjackal> binary is kubernetes-test
<kjackal> hi zyga (!?)
<zyga> kalikiana: ^ I think you know the answer
<kjackal> Just to offer some context. Here is the build with snapcraft 2.40 with -d: https://pastebin.ubuntu.com/p/jTm7TBJH4B/
<kjackal> and here is the segfault we are getting with builds from 2.39 vs 2.40 : https://pastebin.ubuntu.com/p/f4552kVxVK/
<mvo> zyga: 4967 needs a "review" :)
<zyga> OH
<zyga> ah :)
 * zyga mvo: #4938 needs a review as well
<mup> PR #4938: release-tools: add repack-debian-tarball.sh <Created by zyga> <https://github.com/snapcore/snapd/pull/4938>
<mup> PR snapd#4967 closed: release: 2.32.2 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4967>
<kalikiana> kjackal: yes, you can disable it. By adding build-attributes: [no-patchelf] to the part
<zyga> mborzecki: there are some unanswered comments on your PR
<zyga> well, one so far :)
<kjackal> trying that kalikiana, thanks
<zyga> thef first one down the line , aobut the error message
<zyga> thank you kalikiana :)
<kalikiana> sure
 * zyga does the review and enjoys the sunny day today :)
<zyga> finally less clouds and more sun
<mvo> zyga: oh, ah :) will do in a little bit
<mvo> zyga: thanks for the merge
<kjackal> kalikiana: zyga: seems to be working now. But I was wondering, why would snapcraft touch the banaries packaged? Seems like a bug to me. I guess I would better open a forum thread
<kalikiana> kjackal: Yeah, a forum post sounds sensible. If you think it's doing the wrong thing we can discuss it there.
<kjackal> thanks
<kjackal> You definetely have your reasons I just do not know them
<Chipaca> any other reviews i should do before going to add stuff to the error report?
<zyga> hmm hmm
<ogra_> hmm?
<zyga> wondering why tests on my branch failed
<zyga> it was supposed to work, just a re-factor
<zyga> but let me finish one review before jumping back into my branches
<zyga> hey ogra_, how have you been btw?
<ogra_> busy implementing workarounds for customers ;)
<Chipaca> ogra_: hehe
<Chipaca> ogra_: phrasing there makes it sound like you're working around customers =)
<ogra_> heh, well ...
<Chipaca> la la la la can't hear you
<Chipaca> zyga: wasn't snap-confine always in core?
<ogra_> not in the early days (IIRC it was also called differetly in the begining)
<ogra_> *differently
<zyga> Chipaca: yes, that's a good point
<zyga> Chipaca: but the one in core is correct and I have no idea how this could happen there
<Chipaca> zyga: ï¼­ï¼¡ï¼§ï¼©ï¼£
<pedronis> Chipaca: hi, #4900 needs reviews
<mup> PR #4900: many: use the new install/refresh API by switching snapstate to use store.SnapAction <Critical> <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4900>
<Chipaca> pedronis: hi
<Chipaca> pedronis: ack, on it in a bit
<pedronis> it's big, the big parts are the test changes
<zyga> hey pedronis, power is back?
<pedronis> yes
<pedronis> IÂ noticed the problems with interfaces-network on debian
<zyga> I haven't debugged that yet
<zyga> it's certainly random but also worrysome (related to security) and pretty frequent now
<zyga> I suspect it is related to system key somehow
<mvo> zyga: oh? how?
<zyga> mvo: nothing changed in that area for a while and we introduced system key recently, I don't know what else could cause this
<zyga> mvo: but it's just a guess, it needs to be debugged
<mup> PR snapd#4968 opened: RFC: ifacemgr: remove stale connections on startup <Created by stolowski> <https://github.com/snapcore/snapd/pull/4968>
<pstolowski> zyga: hey, thoughts on https://github.com/snapcore/snapd/pull/4968 ? some tests will need updating but before that I'd like to get +1/-1 on the approach
<mup> PR #4968: RFC: ifacemgr: remove stale connections on startup <Created by stolowski> <https://github.com/snapcore/snapd/pull/4968>
<zyga> looking
<mvo> zyga: isn't debian itself changing?
<zyga> mvo: debian 9 is not changing much
<zyga> this was on stretch, not sid
<mvo> zyga: hm, hm, ok
<pstolowski> zyga: thanks for the quick review; apart from that minor detail re logging, do you see any big no-no?
<cjwatson> ~/wg 40
<cjwatson> sorry
<zyga> pstolowski: no, it's fine I think
<zyga> pstolowski: sorry, I will be back with reviews in a moment
<zyga> some interruptions IRL
<pstolowski> np, ty!
<diddledan> snapcraft isn't working :-( (paste follows)
<diddledan> https://www.irccloud.com/pastebin/dOwZkaZC/
<diddledan> was fine when I went to bed last night
<zyga> 4327 is the core snap in candidate now
<diddledan> maybe related:
<diddledan> https://www.irccloud.com/pastebin/Us8ymABs/
<zyga> hmm, no idea though
<zyga> kalikiana: more fire ^
<zyga> ah, I found a typo in my PR
<zyga> fixed locally, should make it green now
<zyga> but I need to make that more robust, one sec...
 * Chipaca -> lunch
<zyga> sigh
<zyga> is there any gnome extension that makes alt-tab less moronic
<zyga> I have two virtual screens,
<zyga> two terminals open, one on each
<zyga> each screen also has one other unrelated window (browser and editor)
<zyga> (again, each)
<zyga> alt-tab from unrelated window should not jump to the terminal on another virtual screen
<zyga> man, I hate how gnome gets most things right and consistently breaks something very very commonly used
<zyga> and https://extensions.gnome.org/ says there is no "native connector", whatever that means
<tomwardill> zyga: I use https://extensions.gnome.org/extension/15/alternatetab/ and youâll need to install the extension for your browser to install gnome-extensions from that site
<zyga> I have that installed (apparently)
<zyga> the extension for firefox that is
<mborzecki> any idea for which snap we dump a dbus policy file in /etc/dbus-1/system.d?
<zyga> mborzecki: mmm
<zyga> let me look
<mborzecki> i've tried some of the test-snapd-* ones but no luck so far
<zyga> mborzecki: anything that uses dbus backend would
<mborzecki> zyga: hmm test-snapd-dbus-{consumer,provider} did not (at least on arch)
<zyga> mborzecki: oh, that's very weird
<zyga> let me try quickly
<zyga> hmm
<zyga> `func (iface *dbusInterface) getAttribs(attribs interfaces.Attrer) (string, string, error) {`
<zyga> need to name the return values
<mborzecki> heh :)
<mborzecki> probably, (ok, ok, not-so-ok)
<zyga> mborzecki: so dbus services need a policy only if they are on the system bus
<zyga> and the snaps you mentioned use the session bus
<zyga> so you'd have to find one that uses bus: system
 * zyga found one more bug the refactoring has introduced
<mup> Bug #1760841 opened: snapd does not parse /etc/fstab properly when using mhddfs <Snappy:New> <https://launchpad.net/bugs/1760841>
<zyga> more interesting than just a bug
<zyga> oh
<zyga> interesting bugs galore
<Chipaca> mhdwtfs?
<ogra_> a new filesystem !
<zyga> wtffs
<zyga> oh
<zyga> that's frelling interesting
<zyga> https://romanrm.net/mhddfs
<zyga> looks like another overlayfs?
<diddledan> yaffs = yet another ferking file system?
<diddledan> was yaffs invented by SuSE? :-p
<zyga> mtfs: me too file system ;)
<diddledan> lol
<zyga> anyway, I need to fix this bug
<ogra_> not overlay ... but union
<diddledan> htfs - hashtag filesystem
<zyga> yeah, overlay can do unions today
<ogra_> indeed
<zyga> everything-in-a-box filesystem
<ogra_> but that just looks like another unionfs-fuse stepchild
<diddledan> we missed April the 1st to launch our new bhfs - black hole file system. it's effectively >/dev/null
<zyga> diddledan: lol, indeed
<zyga> ogra_: wait for our own snapdfs
<zyga> it's really coming
<ogra_> oh my
<zyga> (not april 1st)
<ogra_> as if we had not more pressing issues to fix :P
<zyga> it will help a lot
<ogra_> well, not with the issues we're facig at customers :) but yeah
<zyga> ogra_: hey, we released the fix for /dev/ttymcsN
<ogra_> yeah, saw that
<ogra_> is that already ib stable ?
<ogra_> *in
<zyga> ogra_: no, needs to go through testing
<ogra_> yeah, thats what i thought
<zyga> should be out soonish though
<ogra_> yep
<zyga> mvo: we need to fix https://bugs.launchpad.net/snappy/+bug/1760841 for .3
<mup> Bug #1760841: snapd does not parse /etc/fstab properly when using mhddfs <Snappy:In Progress by zyga> <https://launchpad.net/bugs/1760841>
<zyga> mvo: this prevents snapd from starting :/
<zyga> mvo: the bug here is that when we cannot parse fstab we cannot start up
<zyga> I didn't expect that
<zyga> ogra_: I'm sure some of the issues faced by our customers will be addressed with layouts and the snapdfs idea will make that easier to work with, we could essentially allow merging content in arbitrary ways (finally)
<zyga> this would eliminate almost all reasons to patch or alter software with configuration
<pedronis> Chipaca: thx for the review
<ogra_> zyga, well, main issues atm are autoconnecting interfaces on first boot, and disabling of console-conf (which michael seems to be tackling atm)
<ogra_> also an option to disable the assertion auto-importer ... gadget updates ...
<zyga> ogra_: one of those, the auto-importer, why is that an issue
<ogra_> zyga, some customers want a 100% locked down device
<zyga> aha, I see
<zyga> so not performance related
<ogra_> with no way to insert anything, not even a valid assertion
<zyga> well, only they can issue assertions :)
<ogra_> well, also performance
<mvo> zyga: looking at the bug now
<zyga> thank you mvo
<zyga> ogra_: how is that performance critical?
<ogra_> zyga, thats not the highest prio though ... autoconnecting is most important (saves one of the build.sh script hacks) atm
<zyga> ogra_: I think that was the missing bit that we didn't understand when that PR was closed
<zyga> yeah, the auto-connect is something I totally agree iwth
<zyga> *wtih
<zyga> *with :)
<mvo> zyga: do you think I could push my suggestion for 4930?
<zyga> looking
<mvo> ogra_: iirc auto-connect from the gadget is something that pedronis will work on next
<zyga> yeah, go for it, great idea
<mvo> zyga: cool, thank you. but 176... first, looks more important
<ogra_> zyga, it mounts all attached devices on every boot (and also falsely mounts XrpmbX and XbootX partitions (and fails since they are not mountabe ... but that causes a systemd timeout counter)
<ogra_> )
<ogra_> zyga, but it isnt the super imortant thing anyway
<zyga> ogra_: is this attached to the bug report? this is relevant
<ogra_> as i said ... console-conf and auto-connect are high prio ... but seems they are properly on the TODO
<zyga> mvo: it basically is this:
<zyga>  Apr 03 13:43:33 asd snapd[4016802]: 2018/04/03 13:43:33.378103 helpers.go:115: error trying to compare the snap system key: cannot parse /etc/fstab: expected between 3 and 6 fields, found 1
<zyga> when this happens we mustn't die
<ogra_> zyga, i think i added it to the original description
<zyga> thanks!
<pedronis> mvo: yes,  need G-ustavo back to discuss syntax, but yes is next on my list after being done with 2.32.x stuff
<ogra_> zyga, it is the "#" (your fstab issue)
<zyga> oh?
<zyga> hmmm but don't we ignore those?
 * zyga looks
<ogra_> how silly can you be to require a # sign in your fs line
<zyga> ah
<zyga> yes
<zyga> man, is that how this operates
<zyga> foo# /some/other/shit?\
<ogra_> i think no space
<zyga> thank you ogra, I totally missed that
<ogra_> foo#/some/other/shit
<mvo> zyga: hm, I think I know what is going on
<mvo> zyga: with the statup issue
<zyga> I see
<zyga> mvo: thank you
<zyga> mvo: if you focus on this I will fix the parser
<zyga> ogra_: this is interesting (from man fstab):               mount(8) and umount(8) support filesystem subtypes.  The subtype
<zyga>               is defined by '.subtype' suffix.  For example 'fuse.sshfs'. It's
<zyga>               recommended  to  use subtype notation rather than add any prefix
<zyga>               to the first fstab field  (for  example  'sshfs#example.com'  is
<zyga>               deprecated).
<ogra_> aha
<ogra_> well, there you go .. deprecated
<ogra_> (though i'm surprised this was ever valid)
<zyga> especially since the suffix is ... empty
<zyga> this is going to be fun for parsing
<ogra_> Å·eah
<zyga> ogra_: that field is out of spec but I guess reality trumps specs
<zyga> and trump trumps reality
<zyga> and reality will trump trump eventually
<zyga> :-)
<zyga> brb, tea time
<ogra_> hopefully ...
<mup> PR snapd#4969 opened: interfaces: make system-key more robust against invalid fstab entries <Created by mvo5> <https://github.com/snapcore/snapd/pull/4969>
<vidal72[m]> it would be nice to have snapd in debian stable backports https://backports.debian.org/ , I'm little afraid of using it from normal repos
<vidal72[m]> flatpak is there already
<zyga> vidal72[m]: on debian we benefit from reexec
<ogra_> vidal72[m], snapd should re-exec itself to the binary from the core snap if this is newer so you should automatically always get the latest
<zyga> vidal72[m]: but yeah, no disagreement
<ogra_> vidal72[m], "snap version" will tell you
<zyga> and some things cannot be fixed with reexec
<ogra_> zyga, huh ? you mean it wont bring us world peas ?
<cwayne> That's a lot of peas
<ogra_> not *that* many https://imgur.com/gallery/MQWyj
<vidal72[m]> zyga ,ogra_ : thx, I may try it
<cwayne> ogra_: nice
<ogra_> :)
<kalikiana> diddledan: zyga: I just saw this before reading this. The `lxc push` seems to be failing consistently as if cleanbuild's source tarball didn't exist... I'm investigating what's going on there.
<zyga> kalikiana: thank you
<diddledan> \o/
<mvo> cachio: (for later) is it possible to run the sru validation against https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+sourcepub/8895866/+listing-archive-extra ? (2.32.2 from the ppa:snappy-dev/image) ? it would be great to know if the issues we saw with the sru validateion for 2.31 is now fixed
<zyga> mvo: the converstaion is spread among two PRs: https://github.com/snapcore/snapd/pull/4868 and https://github.com/snapcore/snapd/pull/4957
<mup> PR #4868: cmd/snap-update-ns: add secure bind mount implementation for use with user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4868>
<mup> PR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957>
<zyga> mvo: the tofu-meat is in this comment: https://github.com/snapcore/snapd/pull/4957#pullrequestreview-108131063
<mup> PR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957>
<kalikiana> diddledan: zyga FYI reported it here after narrowing it down a bit https://github.com/lxc/lxd/issues/4394
<mvo> zyga: thank you
<mvo> cachio: let me know if it is possible to run the sru vadlidation (or even just the subset that failed in 2.31) against the 2.32.2 ppa deb, if that is possible and the results are green I will do the sru based on 2.32.2 today
 * kalikiana now lunch
 * zyga -> walk
<zyga> kalikiana: thank you, will read soon
<pedronis> mvo: #4900 is the new APIÂ switch PR
<mup> PR #4900: many: use the new install/refresh API by switching snapstate to use store.SnapAction <Critical> <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4900>
<oSoMoN> jdstrand, hey, would you mind commenting on https://bugzilla.mozilla.org/show_bug.cgi?id=1449594#c9 ?
<mvo> zyga: hey, whats the latest on user-mounts? I am asked in a HO about this right now
<mup> PR snapd#4970 opened: Add SocketUser and SocketGroup options <Created by guilhem> <https://github.com/snapcore/snapd/pull/4970>
<jdstrand> oSoMoN: there are no current plans to mount /tmp/.X11-unix into the snap's mount namespace since X is typically accessed via an abstract socket. I guess the request is "since we are special and use 'allow-sandbox: true' and can unshare() the network namespace, we break because now we don't have access to the abstract socket and .X11-unix isn't in /tmp either"
<cachio> mvo, sure, I'll run that
<jdstrand> oSoMoN: the simple answer is "don't do that and you get the abstract socket". I'm not sure what the network namesapce is giving them over apparmor mediation, but maybe they are concerned about devmode classic distro
<jdstrand> oSoMoN: this requires a forum topic. it isn't a trivial request
<mvo> cachio: great, please keep me updated!
<oSoMoN> jdstrand, ack, that makes sense. it looks like they have a solution (not unsharing) even when /tmp/.X11-unix is not mounted in the snap's namespace, so that's alright. Can you just comment on the bug to state that there are no current plans to mount /tmp/.X11-unix, or shall I do it?
<alexlarsson> Relying on abstract sockets is kinda ass
<jdstrand> oSoMoN: well, just cause there aren't current plans doesn't mean there couldn't be
<alexlarsson> I'm recommending everyone to stop listening to them, because they are not properly sandboxed
<jdstrand> apparmor has mediation for abstract sockets with an out of tree patch (eg, Ubuntu, its derivatives and Solus have it). we are in the process of upstreaming that
<alexlarsson> Sure, but not everyone uses apparmor
<jdstrand> sure, hence the 'devmode classic distro'
<alexlarsson> abstract namespaces predate /run and are really made deprecated by it
<alexlarsson> since that is also auto-cleaned up, and additionally allows per socket access rights
<alexlarsson> And is properly namespaceable
 * zyga is back
<zyga> hey alexlarsson, I'm very happy to see you here
 * zyga is happy to see green tests on #4889 
<mup> PR #4889: cmd/snap-update-ns: don't trespass on host filesystem <Created by zyga> <https://github.com/snapcore/snapd/pull/4889>
<zyga> but it needs some more love before I'm happy with it
<zyga> mvo: about https://github.com/snapcore/snapd/pull/4969/files
<mup> PR #4969: interfaces: make system-key more robust against invalid fstab entries <Created by mvo5> <https://github.com/snapcore/snapd/pull/4969>
<zyga> I think we should return the error but log it at the caller
<zyga> as otherwise we neuter the whole error value
<zyga> ah, wait, actuall
<zyga> actually, hmmm
 * zyga thinks
<diddledan> is there any way to use snapcraft until lxd 3.1 comes along without uninstalling the lxd snap to clear it's configuration??
<diddledan> I can't rollback because: error: The database schema is more recent than LXD's schema.
<zyga> diddledan: doesn't lxd use $SNAP_DATA for the database location?
<diddledan> yes
<diddledan> it looks like the 2.0/* channels don't have the 2.21 release which is what I was running previous to the refresh
<diddledan> actually using `snap revert` to get to 2.21 now tells me: error: Error creating database: schema version '37' is more recent than expected '36'
<diddledan> I think whoever is in charge of lxd has made a mess
<nacc_> stgraber: --^ :)
<diddledan> :-p
<diddledan> shouldn't the database be backed-up by snapd so that reverts actually revert the database, too??
<cachio> mvo, the errors we used to see on sru are not happening with
<cachio> 2.32.2
<diddledan> it looks to be being stored in $SNAP_COMMON
<cachio> mvo, there are some problems to run on 17.10 which I have to fix
<stgraber> diddledan: snapcraft will be fixed in the next hour or so
<stgraber> diddledan: LXD can't be downgraded, we used to revert the database but then the rest of the data couldn't be read, so now we just don't allow it ever
<diddledan> hmm
<diddledan> ok
 * diddledan twiddly diddly
<mvo> cachio: yay, thats encouraging that most of the errors are fixed. can you pastebin the 17.10 errors?
<cachio> mvo, cannot find the linux-image-extra-4.10.0-20-generic
<mvo> cachio: i.e. I assume we need a 2.32.3 with the sru fixes?
<mvo> cachio: oh, heh :)
<mvo> cachio: thanks for finding this, do we hardcode this path?
<mvo> cachio: eh, package name
<cachio> yes
<cachio> I'll push a fix
<cachio> mvo,  but it is a test problem
<cachio> so I can patch that locally and run the tests
<mvo> cachio: thank you! once the fix is up I will prepare/sru 2.32.3
<cachio> ok
<zyga> mvo: what's the timeline for 2.32.3
<zyga> I can prepare the 2nd part of the fix soon, just driving home now
<vidal72[m]> jdstrand: I would prefer snap doesn't use abstract x socket https://forum.snapcraft.io/t/xorg-abstract-socket-is-mandatory-for-running-snaps/4580
<jdstrand> oSoMoN (cc vidal72[m]): I didn't answer your question because it is a matter of priority as opposed to me saying 'yes' or 'no' (tbh, I wouldn't probably be the one to implement it, but I would review it). this is why I suggested a forum topic. perhaps add to vidal72[m]'s
<oSoMoN> ack
<mup> PR snapd#4971 opened: errtracker: add more fields to aid debugging <Created by chipaca> <https://github.com/snapcore/snapd/pull/4971>
<jdstrand> oSoMoN: we aren't avoiding the named socket for security reasons. we just haven't needed it since the abstract is there
<Chipaca> jibel: ^^ fwiw (but i assume you're getting pinged via github and the forum on this already =)
<mvo> pstolowski: you have some feedback in 4940, looks reaonable to me, I wonder if we need gustavo for this or if we can just go ahead
<pstolowski> mvo: thanks for you review! i'd like Gustavo's opinion on the overall approach, afaict he hasn't really evaluated the approach I described in the forum post
<mvo> pstolowski: ok
<mup> PR snapd#4911 closed: daemon,client: add build-id to /v2/system-info <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4911>
<mvo> pedronis: I'm halfway through 4900, looks good so far and the non-test code is less than I expected it to be
<zyga> mvo: you now have a review on https://github.com/snapcore/snapd/pull/4969
<mup> PR #4969: interfaces: make system-key more robust against invalid fstab entries <Created by mvo5> <https://github.com/snapcore/snapd/pull/4969>
<zyga> jdstrand: hey,  have you seen https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1760416
<mup> Bug #1760416: dropping privs did not work: Invalid argument <amd64> <apport-bug> <artful> <wayland-session> <snapd (Ubuntu):New for zyga> <https://launchpad.net/bugs/1760416>
<zyga> I'm very puzzled why that could ever fail
<cachio> mvo, are you pushing 2.32.3 to beta too?
<zyga> mvo: is 2.32.3 already done?
<mup> PR snapcraft#2046 opened: lxd: specify arch in lxc image list command <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2046>
<zyga> I haven't fixed the fstab parser error (though your fix is sufficient, though not merged either)
 * kalikiana wrapping up for today
<kenvandine> alexlarsson, it was great to see the snap support PR for xdg-desktop-portals merged today
<jdstrand> zyga: give me a minute, it seems I got the lxd 3.0 snap and things are broken
<jdstrand> that's weird. 'snap interfaces lxd' shows nothing
<zyga> Oh
<zyga> Snap was not mounted or onterface was inwalidÃ³w?
<zyga> Invalid
<zyga> But sure, no rush
<jdstrand> the snap doesn't show as broken this time
<jdstrand> I have 16-2.32.2
<jdstrand> I stopped and started snapd and it seems to be back
<jdstrand> then I needed to disconnect/connect
<jdstrand> weird
<zyga> jdstrand: weird
<zyga> jdstrand: are you on bionic?
<jdstrand> zyga: the seteuid or setegid calls could fail for a number of reasons (see man seteuid)
<jdstrand> zyga: I am
<jdstrand> zyga: I responded to the bug
 * zyga breaks because kids are getting crazy
<mvo> zyga, cachio no 2.32.3 yet, we need the fstab fix and the sru fix in there at least
<zyga> what's the sru fix, the golang 1.6 thing?
<zyga> I'm almost home, I will resume work on the fstab fix shortly, i have most of it done but I need to add some tests and see if I broke anything by changing things
<mvo> zyga: the sru validation fails on 17.10 because of a hardcoded linux-image package name (with an abi) apparently
<zyga> ah
<zyga> uch
<cachio> ok, is the sru for 2.32.2 ready?
<cachio> tests for sru worked
<cachio> just some known issues
<mvo> cachio: almost ready, I think we need 4969 and then its a go (fixes a regression in 2.32.2)
<stgraber> diddledan: should be good now
<diddledan> yey
<diddledan> danke
 * diddledan pushes the button
<cwayne> mvo: so should we be expecting another beta?
<diddledan> yup everything good
<mvo> cwayne: yeah, we have one (corner case) regression we need to fix
<cwayne> mvo: ack, will keep an eye out
<mvo> cwayne: thank you
<cwayne> no problemo
<mup> PR snapcraft#1997 closed: lxd: merge existing image info contents <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1997>
<mup> PR snapcraft#2038 closed: Add an option for setting npm flags option <Created by guilhem> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2038>
<mvo> zyga: I updated 4969 based on your suggestion
 * zyga looks
<zyga> #4969 needs a 2nd review
<mup> PR #4969: interfaces: make system-key more robust against invalid fstab entries <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4969>
 * cachio afk
<popey> When is 2.32 going to be in stable?
<mup> PR snapcraft#2047 opened: pluginhandler: organize in build instead of stage <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2047>
<mup> PR snapcraft#2043 closed: cli: support exporting login to stdout <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2043>
#snappy 2018-04-04
<stgraber> hmm, there's something very wrong with auto-connected interfaces here
<stgraber> "snap install lxd" on a completely clean system (no core snap yet) leads to none of our interfaces being connected
<stgraber> removing the snap and reinstalling it then gets things connected properly
<stgraber> https://forum.snapcraft.io/t/auto-connected-interfaces-missing-on-initial-snap-install/4850
<stgraber> this is obviously rather critical
<stgraber> confirmed to affect all snaps on initial install (when no core snap is present)
<mborzecki> morning
<stgraber> mborzecki: good morning, looks like you're the first snap person around today, you may want to take a look at https://forum.snapcraft.io/t/auto-connected-interfaces-missing-on-initial-snap-install/4850
<mborzecki> stgraber: looking
<mborzecki> stgraber: working locally with latest snapd, even if i purge everything and start with clean state, i'm trying cloud image now
<stgraber> mborzecki: 16.04 cloud image should be affected, that's effectively what MAAS uses
<stgraber> mborzecki: it may or may not be related to re-exec, so latest snapd on your system may get you a different result, not sure
<mborzecki> stgraber: yeah, something is off: https://paste.ubuntu.com/p/6P4JpMhgPf/
<mborzecki> that's on cloud image
<stgraber> yup, matches what I'm seeing here and what our users have been reporting
<mborzecki> and that's my host: https://paste.ubuntu.com/p/hDzWMgY2zb/
<mborzecki> stgraber: left a note, i think the approach needs to be discussed with mvo/pstolowski/pedronis
<mborzecki> stgraber: refreshing the core snap first should workaround the problem
<mborzecki> mvo: speaking of mvo :P
<mborzecki> mvo: morning
<mvo> mborzecki: goooood morning
<mvo> mborzecki: what did I miss :)
<mvo> ?
<mborzecki> mvo: stgraber reported a problem with auto-connect https://forum.snapcraft.io/t/auto-connected-interfaces-missing-on-initial-snap-install/4850
<mborzecki> mvo: i looked around and my observation is that we're missing the 'auto-connect' task because the task list is created using the old 'snapd'
<mvo> mborzecki: yeah, I was just reading the forum
<mvo> mborzecki: I think your analysis makes sense, that is most likely the issue
<mborzecki> mvo: i looked in state.json and there's no auto-connect when old snapd creates the task list
<mvo> mborzecki: yeah, this makes sense. so its the race when you don't have a core snap and it restarts itself
<mborzecki> mvo:  do you think we could somehow patch it when core updates?
<mvo> mborzecki: yeah, I think we need to add compat code into the "old" task (setup-profiles)
<mvo> mborzecki: I mean, something like (in setup-profiles): scan the task list and if the task is missing either inject it or run it
<mborzecki> mvo: otoh, maybe we should rewrite the whole pending task list if core is updated in the process
<mvo> mborzecki: we will need pawel here
<mvo> mborzecki: yeah, its a bit of a generic problem
<mup> PR snapd#4972 opened: cmd/snap-mgmt: remove timers, udev rules, dbus policy files <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4972>
<mvo> mborzecki: I followed up in the forum, lets discuss with pawel once he is here
<mborzecki> mvo: ok
<zyga> good morning
 * zyga catches up with IRC
<zyga> stgraber: ack,
<zyga> oh, good analysis indeed mborzecki
<zyga> I would love if we could formalize the reexec protocol limitations somewhere
<mborzecki> zyga: hey, morning
<zyga> so we don't run into this willy nilly again
<zyga> mvo: do you consider this a release blocker?
<Caelum> zyga: I think we've satisfied everyone's requirements as far as my internet check PR goes
<Caelum> zyga: also, could you please change leap version in: https://github.com/canonical-docs/snappy-docs/pull/380
<mup> PR canonical-docs/snappy-docs#380: Use address --refresh on openSUSE <Created by zyga> <https://github.com/canonical-docs/snappy-docs/pull/380>
<Caelum> from 42.2 to 42.3
<Caelum> I would have submitted my own, but then it would conflict with yours
<zyga> Caelum: yes, I will do that now
<Caelum> thank you
<zyga> Caelum: I prepared an update that enables apparmor but I need to send a mail to suse security team and discuss some topics
<zyga> it's pretty complex how all those things interact
<Caelum> nice
<zyga> the goal is to land an apparmor-enabled version into the system:snappy and start the discussion with the security team on how to add snapd to factory proper
<Caelum> that would be awesome
<mvo> zyga: good morning! yes, I think this is a blocker
<mvo> zyga: I wonder if we need to re-think re-exec, maybe something like: if there is a new core, always *only* referesh that then re-exec and do the rest
<zyga> mvo: yes, I think this makes a lot of sense
<zyga> mvo: or introduce a formal protocol where snapd "new" can re-interpret partially finished tasks
<zyga> mvo: but whatever we do needs to work all the  way back
<zyga> or we would always have to adjust old versions
<zyga> or provide updates/backports
<zyga> I think doing this on the "new" side would be conceptually harder but easier to deploy
<zyga> we could also do both sides so in the future it is easier in general
<zyga> Caelum: PR updated
<zyga> mvo: in this case, do we have enough information to synthesize new tasks on snapd startup?
<zyga> mvo: cook old snapd state, start overlord, look at state;
<Caelum> zyga: awesome thank you!
<zyga> mvo: the new state should include the desired set of tasks
<mvo> zyga: I think so, in this case I think we can just insert a auto-connect task
<zyga> Caelum: I'll poke people to merge it soon
<zyga> Caelum: thank *you* :-)
<zyga> yes, that's my thinking
<mvo> zyga: and then we need to discuss a more general approach
<zyga> it should be simple enough for this one-off case
<mvo> zyga: its definitely making things very complicated (re-exec)
<mvo> zyga: yeah
<zyga> but yes, definitely a topic for discussion
<zyga> mvo: it's so much simpler to test and evaluate in distros where we don't support it
<zyga> mvo: so I agree totally
<mvo> zyga: I want to wait for pawel but hopefully its easy, we have code for task injecton already
<zyga> mvo: alternative, make shallow snapd
<zyga> mvo: that doesn't do stuff
<zyga> just reexecs
<zyga> sounds good, I'll get back to fstab
<mvo> zyga: yeah, but even with the shallow one we will need to deal with ugprades
<mvo> zyga: i.e. when to re-exec on upgrades
<mvo> zyga: but yeah, a much bigger topic that does not fit well into irc :)
<zyga> shallow one would not contain any logic apart from "fetch core in super generic way, re-exec"
<mvo> zyga: sure, that would fix step 0. but what if we have full snapd and refresh to full snapd+1 with new tasks
<zyga> ohh
<zyga> yes
<pstolowski> morning
<kalikiana> moin moin
<kalikiana> o/ pstolowski
<zyga> hey pawel
<zyga> we have some important work for you
<mvo> pstolowski: thanks for your reply in the forum!
<pstolowski> zyga: the auto-connect issue?
<zyga> indeed
<zyga> mvo: https://github.com/snapcore/snapd/pull/4973
<mup> PR #4973: osutil: fix fstab parser to allow for # in field values <Created by zyga> <https://github.com/snapcore/snapd/pull/4973>
<zyga> I'll make a backport after this lands
<mup> PR snapd#4973 opened: osutil: fix fstab parser to allow for # in field values <Created by zyga> <https://github.com/snapcore/snapd/pull/4973>
<mvo> zyga: ta
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/4938 updated
<mup> PR #4938: release-tools: add repack-debian-tarball.sh <Created by zyga> <https://github.com/snapcore/snapd/pull/4938>
<mvo> 4969 needs a second review
<mborzecki> zyga: yeah, i find `find .. -exec` utterly confusing syntax wise and replace it with `| xargs` where possible (also xargs has the nice -P switch which i abuse when possible)
<zyga> mborzecki: but find ... -exec works for any number of files; xargs will hit the kernel argument size limit eventually
<zyga> pstolowski: 4968 + 1 but add a test please
<pstolowski> zyga: will do, thanks
<zyga> mvo is https://github.com/snapcore/snapd/pull/4951 a 2.32 backport candidate
<mup> PR #4951: interfaces/desktop-legacy: allow access to gnome-shell screenshot/screencast <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4951>
<zyga> it needs gustao review
<mvo> zyga: it is, but blocked right now
<pedronis> it seems we need a new tests that is not about upgrades but about starting installing from stable deb
<mvo> pedronis: indeed
<mup> PR snapd#4974 opened: ifacestate: injectTasks helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/4974>
<pstolowski> mvo zyga pedronis can you please take a look at ^ ? it's a helper that I initially meant to propose with interface hooks, but it's going to be useful now for auto-connect fix
<zyga> ack
 * zyga sees a curious error:
<Chipaca> moin moin
<zyga> https://www.irccloud.com/pastebin/pVrMuty3/
<zyga> Chipaca: hey
<Chipaca> pstolowski: did you see zyga's comment (somewhere, on the forum maybe?) about making sure core is installed before doing anything further? wouldn't this solve the autoconnect thing?
<pedronis> Chipaca: this is about core
<pedronis> Chipaca: it's installed first, is just that the next install is not setup properly
<Chipaca> pedronis: because the tasks are created by the old snapd?
<pedronis> yes
<pedronis> the other issue is a bit different
<Chipaca> k
<pedronis> is about trying to run hooks while core is not active
<pedronis> that needs to wait in some form
<pedronis> Chipaca: to be clear, IÂ should probably write this on the forum, but first doesn't mean a lot in our world,  we either need to setup dependecies or wait
<pedronis> you can always start an install and a different change at the same time
<zyga> mvo: https://github.com/snapcore/snapd/pull/4973 updated
<mup> PR #4973: osutil: fix fstab parser to allow for # in field values <Created by zyga> <https://github.com/snapcore/snapd/pull/4973>
<mvo> zyga: ta!
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/4938 needs your re-review
<mup> PR #4938: release-tools: add repack-debian-tarball.sh <Created by zyga> <https://github.com/snapcore/snapd/pull/4938>
<zyga> oh
<Chipaca> zyga: no it doesn't
<zyga> you just did
<Chipaca> =)
<zyga> thanks :)
<Chipaca> despite you telling me your comment was *fine* when it wasn't :-)
<zyga> sorry ^_^
<zyga> I changed this a few times locally and I forgot what it was then
<Chipaca> 'twas fine, just confusing (but you got it sorted in the end)
<zyga> with that merged we will just have 6 more scripts from mvo's stash to port ;)
<pedronis> pstolowski: are you looking also into writing the spread?   start with current stable deb,  and install a snap that needs autoconnections  , probably needs the fakestore to use the latest code for snapd
<mvo> zyga: *cough*
<mvo> zyga: I'm looking at this as well now
<zyga> well, ok, 9
<zyga> mvo: I have a small README file to add there next
<mborzecki> wow, it's really sprint this time, +16 in the shade and sunny
<mvo> zyga: thanks, added a small comment
<zyga> mborzecki: it's bound to be 22 next monday
<zyga> I cannot wait for coding sessions in the park :)
<Chipaca> zyga: mvo: you both make good points about cpuinfo
<Chipaca> zyga: mvo: note however I am doing what apport does, there
<mborzecki> hah, can't wait to start bicycling again
<Chipaca> zyga: mvo: and what it does is fine, i think: if it doesn't look like the x86 ones, it ships the whole file
<Chipaca> (and the non-x86 ones i've seen so far are saner in this sense)
<mvo> Chipaca: yeah, I think its fine. also x86 will be the 99%
<mvo> (for now at least)
<Chipaca> mvo: non-x86 is where a lot more bugs happen though :-) proportionally
<zyga> mvo: did you see intel shares drop 10%
<zyga> mvo: when apple announced macs will move to arm in 2020
<zyga> well, not arm specifically but probably
<zyga> (some people think it might be riscV as well since it is free)
<zyga> and the core design is custom anyway, just instruction set was used
<zyga> pstolowski: can we close https://github.com/snapcore/snapd/pull/4965
<mup> PR #4965: ifacestate: injectTasks helper <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4965>
<pstolowski> zyga: yes, done
<mup> PR snapd#4965 closed: ifacestate: injectTasks helper <Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/4965>
<mborzecki> zyga: pushed an update to #4972
<mup> PR #4972: cmd/snap-mgmt: remove timers, udev rules, dbus policy files <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4972>
<Chipaca> siigh
<Chipaca> is it the 90s again
<Chipaca> except there's no NeXT
<mvo> mborzecki: thanks, looking
<Chipaca> apple going off and doing its own CPUs, not doing anything really new, fans still being fans
<zyga> mborzecki: ack
<zyga> thank you :)
<mborzecki> mvo: that's 2.32.3 right?
<zyga> mborzecki: did you shellcheck everything new?
<zyga> Chipaca: it's the 90s but we have linux
<Chipaca> zyga: i had linux in the 90s
<mvo> mborzecki: yes
<zyga> but linux now sucks less ;-)
<mborzecki> zyga: yeah, it will complain about -exec and recommend -execdir (but that's expected)
<Chipaca> zyga: i've been on linux since 1994, and i switched because it sucked less
<mvo> mborzecki, zyga hm, if shellcheck does not like, whats the advantage over find|xargs?
<zyga> mborzecki: interesting, I didn't know about execdir
<zyga> can we just use execdir then
<zyga> it looks very sane
<mborzecki> force push?
<zyga> mvo: xargs has size limits
<mborzecki> (trying to keep the commit count low)
<pedronis> there's -n
<pedronis> though
<zyga> and you can use + form to make fewer calls to rm even :)
<mvo> mborzecki: we can squash it on merge but I'm fine with force push too
<mborzecki> heh, -n, + bikeshedding :P
<mvo> yeah, this feels like we are deep in bikesheed land :)
<zyga> it's shell ;)
<zyga> it's the perfect candidate
<Chipaca> zyga: what's that about size limits?
<mup> PR snapd#4975 opened: osutil: fix fstab parser to allow for # in field values (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/4975>
<zyga> Chipaca: xargs wasn't smart and could run into issues with the size of cmdline
<zyga> that's why I traditionally don't like using it
<BjornT_> mvo: hi! do you know why core18 wasn't pushed to the store, even though it was built successfully for amd64? does it wait for all architectures to build?
<zyga> https://www.irccloud.com/pastebin/srWqXthX/
<zyga> Chipaca: ^
<mborzecki> zyga: Chipaca: iirc xargs will call the command a number of times if it hits a limit, but i'm not sure if that applies to all versions in the wild
<mborzecki> (or anything else than gnu)
<mvo> BjornT_: let me check
<Chipaca> zyga: ah
<mvo> BjornT_: I manually published it now, but let me try to figure out why it wasn't done so automatically
<Chipaca> mborzecki: that's intrinsic to xargs, yes, but see zyga's pastebin
<zyga> mvo: can we override gustavo's -1 since the issue is fixed now
<zyga> https://github.com/snapcore/snapd/pull/4930/files
<mup> PR #4930: skip test that requires internet when not present <Created by rkitover> <https://github.com/snapcore/snapd/pull/4930>
<mborzecki> Chipaca: ack
<Chipaca> how do I use adt-buildvm-ubuntu-cloud to get a bionic image for spread?
<Chipaca> in xenial
<zyga> (this is from man xargs)
<Chipaca> (it looks for a .disk1.img that's not there)
<mvo> zyga: looking
<mvo> Chipaca: adt-buildvm-ubuntu-cloud -r bionic does not work?
<BjornT_> mvo: thanks! i did confirm that the built core18 snap worked together with maas and snapcraft 2.40, btw
<Chipaca> mvo: it tries âDownloading https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64-disk1.imgâ and then crashes with a 404
<Chipaca> 404 -> traceback, because python
<mborzecki> Chipaca: iirc cloudimg' don't have .disk1.img
<Chipaca> but 404 nontheless :-)
<Chipaca> nonetheless*
<mvo> Chipaca: oh, indeed, iirc you need to do: "sudo apt install -t xenail-backports apport"
<mvo> Chipaca: to get the non-ancient version of apport
<mvo> Chipaca: eh, adt
<Chipaca> _apport_? for cloud images?
<mvo> Chipaca: silly me
<Chipaca> ah :-)
<mvo> Chipaca: autopkgtest
<mvo> Chipaca: but let me quickly double check
<mvo> Chipaca: yes, please try that
<mvo> (the version of *autopkgtest* from xenial-backports)
<Chipaca> E: The value 'xenail-backports' is invalid for APT::Default-Release as such a release is not available in the sources
<mvo> Chipaca: without my typo :(
 * Chipaca fixes the typo and tries again
 * Chipaca is copy-pasting commands that start with 'sudo'
<Chipaca> mvo: I _trusted_ you! /o\
<mvo> Chipaca: sorry for letting you down!
<Chipaca> I'm used to it by now :-p
<Chipaca> anyway, that worked, thanks!
 * mvo weeps a bit in the corner
<mvo> Chipaca: happy that it worked, this should give you an image
<Chipaca> yep yep, it's doing its thing
<mborzecki> damn, forgot to start the pomodoro timer
<mvo> mborzecki: for what specifically?
<mborzecki> mvo: work :P
<mborzecki> mvo: there's a nice gnome shell extension http://gnomepomodoro.org/
<mvo> mborzecki: do you use a physical one or software? if software, which one
<mvo> mborzecki: heh - you answered already
<timp> hello
<timp> I think snap or apparmor broke my lxd install. Is this the correct place to look for help?
<zyga> hey timp
<zyga> yes, what happeend?
<zyga> happened
<timp> zyga: thanks :)
<mborzecki> mvo: forces breaks on you, reminds me to do some stretching, squats etc
<timp> yesterday, my lxd worked fine. Today it does not. (I did an apt upgrade yesterday, that may be related. No snap refresh though)
<timp> $ lxc list
<Chipaca> mborzecki: zyga: not sure why I'm looking at this, but freebsd's find also has -execdir (but its xargs doesn't have --show-limits)
<timp> cat: /proc/self/attr/current: Permission denied
<timp> /snap/lxd/6492/commands/lxc: 6: exec: aa-exec: Permission denied
<zyga> timp: snaps refresh automatically
<timp> dmesg shows this:
<timp> [ 1140.618728] audit: type=1400 audit(1522829695.691:122): apparmor="DENIED" operation="open" profile="snap.lxd.lxc" name="/proc/8365/attr/current" pid=8365 comm="cat" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
<timp> [ 1140.619047] audit: type=1400 audit(1522829695.691:123): apparmor="DENIED" operation="exec" profile="snap.lxd.lxc" name="/usr/sbin/aa-exec" pid=8352 comm="lxc" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
<zyga> timp: can you check if "snap changes" has anything about lxd?
<timp> yes, it did:
<timp> 93   Done    2018-04-04T07:44:00Z  2018-04-04T07:45:55Z  Auto-refresh snaps "lxd", "aws-cli", "core"
<zyga> timp: and can you paste "snap interfaces | grep lxd"
<zyga> timp: ok
<timp> :lxd-support               lxd
<timp> :network                   lxd,nextcloud-client,simplenote,telegram-sergiusens
<timp> :system-observe            lxd
<timp> lxd:lxd
<zyga> hmm all looks good here
<zyga> let me look deeper
<timp> thanks
<pedronis> isn't there a discussion about in the forum
<timp> I can 'cat /proc/self/attr/current', so that permission denied is weird. I don't know how AppArmor works though.
<zyga> oh, perhaps
<pedronis> is this relevant:  curl https://assertions.staging.ubuntu.com/v1/assertions/account-key?account-id=canonical
<Chipaca> mborzecki: what version of systemd do you have over there? (on arch i mean :-) )
<pedronis> sorry
<pedronis> is this relevant:  https://forum.snapcraft.io/t/2-0-lxd-snap-fails-on-sytems-with-partial-apparmor-support/4707
<mborzecki> Chipaca: 238
<zyga> ahh
<zyga> timp: can you paste "snap version"
<timp> snap    2.32.1
<timp> snapd   2.32.1
<timp> series  16
<timp> ubuntu  16.04
<timp> kernel  4.13.0-37-generic
<timp> I'm on xenial
<zyga> timp: thank you
<zyga> so this is not a partial apparmor support issue
<zyga> ok, I'll look at what I was meant to before
<timp> what do you mean with partial apparmor support issue?
<mborzecki> zyga: mvo: force pushed to 4972
<zyga> timp: debian and ubuntu have different set of supported apparmor features because ubuntu still carries a patch with non-upstreamed extensions
<zyga> timp: can you please pastebin /var/lib/snapd/apparmor/profiles/snap.lxd.lxc
 * zyga -> brb 
<timp> zyga: sure, http://paste.ubuntu.com/p/hrrQFkXYSx/
<timp> https://forum.snapcraft.io/t/snapped-lxd-has-stopped-working-aa-exec-doesnt-exist-in-the-snap/2356 seems similar, but there's no solution there
<timp> hmm, this is unfortunate. I was doing all my work in containers so now I'm blocked.
<timp> so,
<timp> $ snap revert lxd
<timp> lxd reverted to 3.0.0
<timp> tim@tim-XPS-13-9350:~$ lxc list
<timp> that fixes it for now.
<timp> looks like the lxd update broke stuff
<ackk> timp, you might want to ask on #lxc-dev as well
<zyga> re
<zyga> timp: looking
<zyga> timp: it looks like the profile is wrong
<zyga> it doesn't contain contributions from lxd-support
<timp> hmm, 'snap refresh' tells me that there are no updates for lxd, even though I just did snap revert lxd
<zyga> can you snap disconnect lxd:lxd-support
<zyga> and then re-connect it
<zyga> and see if the profile is different
<zyga> (copy the current profile out)
<timp> note that after 'snap revert lxd', it is working again. And I cannot reproduce the problem any more.
<zyga> right because you are on a different revision
<zyga> you can look at the same file again
<zyga> and the header will say @{SNAP_REVISION} = ...
<timp> snap.lxd.lxc?
<zyga> yes
<zyga> in the pastebin it was 6492
<timp> this is with the working version: http://paste.ubuntu.com/p/vgJcv7dPRm/
<timp> hmm, also 6492?
<zyga> right, this one is correct
<zyga> the previous one looked like basic, unconnected (no interfaces) application
<timp> ah, so what I did is 'snap revert lxd'. And then 'snap refresh lxd'. Now I again have 6492, and it still works.
<zyga> pstolowski: ^ maybe some other bug?
<zyga> it looks like a bug in snapd, more than a bug in lxd IMO
<zyga> hmm hmm
<zyga> can you add this to a forum thread or a bug report
<zyga> I don't want to lose it here
<timp> on LP?
<zyga> yes, on snapd
<timp> ok
<pedronis> this a much more tested path than the   snap install lxd (without anything)
<pedronis> though
<zyga> timp: please include: snap version; snap changes; snap interfaces (from what you did, not from what is is now when it works)
<zyga> and the two profiles you made
<zyga> (the pastebins)
<zyga> I think it shows that we didn't really include the lxd-support snippets at all
<zyga> pstolowski: the bug on the forum feels related now
<zyga> the reporter there doens't have lxd-support
<BjornT_> mvo: didn't you publish the latest one? the one you published is still on glibc 2.26.
<BjornT_> mvo: this is the one i used when i confirmed it worked with maas: https://code.launchpad.net/~mvo/+snap/core18/+build/182036/+files/core18_very-unstable_amd64.snap
 * zyga afk again
<timp> zyga, pedronis: thanks for the help. I reported the bug here: https://bugs.launchpad.net/snapd/+bug/1761115
<mup> Bug #1761115: After lxd snap upgrade, it lxc stopped working <snapd:New> <https://launchpad.net/bugs/1761115>
<zyga> timp: thank you
<mvo> BjornT_: indeed, it was an older one
<mvo> BjornT_: pushed a new one to edge,
<mvo> BjornT_: and I think wgrant helped me fix the auto-upload issue, so hopefully this will be fixed now (testing this right now)
<ackk> mvo, hi, do you know why I'm getting this error when trying to switch to the channel? https://pastebin.canonical.com/p/KywXTYgC6y/
<BjornT_> mvo: nice, thanks
<mvo> ackk: this looks like snapd crashed or something, what do you see in "journalctl -u snapd"? anything that indicates a panic?
<ackk> mvo, no panics, but repeated errors like:
<ackk> Jan 08 15:11:47 maas systemd[1]: snapd.service: Failed to set invocation ID on control group /system.slice/snapd.service, ignoring: Operation not permitted
<ackk> Jan 08 15:11:47 maas systemd[1]: snapd.service: Failed to reset devices.list: Operation not permitted
<ackk> mvo, fwiw I can install/remove snaps
<ackk> it's just this operation that seems to fail
<ackk> mvo, removing the base and reinstalling from the store works
<mvo> ackk: ok, I will try to reproduce this, the EOF looks suspicious
<ackk> mvo, btw it seems snapd doesn't check if you have snaps that depend on a base you remove?
<ackk> I just removed core18 and maas which depends on it was installed
<Chipaca> ackk: mvo: yeah that EOF usually means snapd went away mid-request (typically because of a crash)
<ackk> Chipaca, but snapd seems to work fine for everythingelse
<Chipaca> ackk: systemd'll restart it unless it does it too often
<Chipaca> and yes, snapd does not do proper dependency management (yet)
<ackk> Chipaca, weird, I thought I saw an error when trying to remove a snap before
<Chipaca> ackk: it'll block core, gadget and kernel removes
<ackk> oh I see
<pedronis> we don't have that check for bases in use
<Chipaca> basically things you can't come back from :)
<Chipaca> pedronis: nor for default providers
<pedronis> afaik
<pedronis> well default providers are a bit of different issue
<Chipaca> we probably should at least warn / prompt
<pedronis> they are optional
<Chipaca> pedronis: about as optional as bases
<pedronis> not that we know what thÃ¢t means
<pedronis> Chipaca: well,
<Chipaca> pedronis: try running gnome-calculator without gnome-16.04-whatevs
<pedronis> it dpends
<pedronis> Chipaca: they are installed as if they were optional
<Chipaca> yes
<Chipaca> and we don't have, afaik, a way of expressing optionalness
<Chipaca> optionality
<Chipaca> optionionness
<pedronis> which mostly means we don't make a fuss
<pedronis> if they don't install
<pedronis> the snap uses them might
<pstolowski> zyga: ack. i'm working on auto-connect PR atm, I can look at this in a bit
<zyga> ok
<pedronis> pstolowski: are you looking into the spread test for that?   afaict is likely a very untested area atm
<zyga> pstolowski, mvo: https://forum.snapcraft.io/t/auto-connected-interfaces-missing-on-initial-snap-install/4850/16
<zyga> it's not just that we didn't connect
<zyga> we didn't even _load_ interfaces somehow
<zyga> this is very very nasty
<pstolowski> pedronis: not sure how to spread-test this particular case yet (other than by removing autoconnect task with jq, but that's not a good test). for regular auto-connect with current snapd we do have spread test(s)
<pedronis> pstolowski: we need to start from the deb in the archive
<pstolowski> pedronis: we can, but that's a moving piece no?
<pedronis> pstolowski: it is
<pedronis> but not different than what we do in the current upgrade test
<pstolowski> let me see
<pedronis> as I wrote probably a bit annoying because it will need the fakestore
<pedronis> because we hardcode  how we get core
 * Chipaca -> break
<pstolowski> pedronis: i think in the existing tests we install whatever version of snapd we have in distro (or whatever we build locally); now we would need an old version that doesn't have the feature
<pstolowski> zyga: yes, this looks rather bad..
<pedronis> pstolowski: xenial has 2.29
<pstolowski> pedronis: ah, indeed, and it will never get updated, you're right
<pedronis> well, it will
<pstolowski> hmm
<pedronis> but is good enough for testing the current problem
<pedronis> as it's happening
<pstolowski> ok, fair enough
<mvo> BjornT_, ackk, wgrant auto-upload of core18 works now, thanks for reporting and helping with the fix
<pstolowski> would be great to have a test that's stays valid for longer time
<ackk> mvo, great, thank you!
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/4973 needs a 2nd review for the release
<mup> PR #4973: osutil: fix fstab parser to allow for # in field values <Created by zyga> <https://github.com/snapcore/snapd/pull/4973>
<zyga> Chipaca: fstab, wanna take it?
<pedronis> pstolowski: well,  we have unit tests too
<zyga> mvo: can I remove the snappy.upstream part when we merge the other script that makes the input tarball
<zyga> that branch is green and it doesn't hurt much
<pedronis> pstolowski: also hopefully at some point soon we will get epochs  and testing jumping so much between revision will be a bit less needed
<mvo> zyga: ok, fwiw, I am working on git-buildpackage right onw
<zyga> Thanks!
<mup> PR snapd#4938 closed: release-tools: add repack-debian-tarball.sh <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4938>
<mup> PR snapd#4972 closed: cmd/snap-mgmt: remove timers, udev rules, dbus policy files <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4972>
<zyga> mborzecki: can you please provide a backport for this branch for 2.32 ^
<Chipaca> zyga: looking
<mup> PR snapd#4976 opened: cmd/snap-mgmt: remove timers, udev rules, dbus policy files (2.32) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4976>
<zyga> mborzecki: wrong target branch
<mborzecki> zyga: should be fixed now
<mup> PR snapd#4977 opened: debian: add gbp.conf script to build snapd via `gbp buildpackage` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4977>
<pedronis> mvo: what's the status of your review of #4900,  got half through it yesterday and then new emergencies today?
<mup> PR #4900: many: use the new install/refresh API by switching snapstate to use store.SnapAction <Critical> <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4900>
<mvo> pedronis: yes, continuing now
<zyga> is the store having a slow ceph day again?
<pedronis> not that IÂ know of,  a little bit of load with the release yesterday
<zyga> mvo: can I merge the backport https://github.com/snapcore/snapd/pull/4975
<mup> PR #4975: osutil: fix fstab parser to allow for # in field values (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/4975>
<mup> PR snapd#4973 closed: osutil: fix fstab parser to allow for # in field values <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4973>
<zyga> the master branch had 2 +1s and I just merged it
<zyga> pedronis: can you please do a 2nd review on release-critical https://github.com/snapcore/snapd/pull/4969 fix from mvo
<mup> PR #4969: interfaces: make system-key more robust against invalid fstab entries <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4969>
<zyga> jdstrand: hey, can you please enqueue https://github.com/snapcore/snapd/pull/4545 for re-review
<mup> PR #4545: interfaces/x11: allow X11 slot implementations <Created by gerboland> <https://github.com/snapcore/snapd/pull/4545>
 * zyga needs to plan an errand today :/
<zyga> are we doing the standup earlier? (now?)
<zyga> mvo: when is the standup today
<pedronis> 2pm we agreed
<zyga> ah, that's good then
<zyga> I can do the errand after that
<zyga> thanks
<cachio> mvo, hey
<mvo> hey cachio
<cachio> what time are we making the standup today?
<mvo> cachio: in 35min
<mvo> cachio: hope that works for you
<mvo> cachio: if not its ok to skip
<cachio> mvo it doesn't work today
<cachio> mvo, I have to go to my son's school
<cachio> are we making all wednesday at this time?
<cachio> every wednesday?
<mborzecki> zyga: mvo: pushed updates to #4942
<mup> PR #4942: cmd/snap: user session application autostart v3 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4942>
<zyga> thanks
<mvo> mborzecki: ta
<mborzecki> standup is @ 2pm?
<mvo> cachio: no problem, we need to discuss tomorrow/next week what time to pick then
<zyga> yes
<mborzecki> ack
<mvo> cachio: we also need a time that works for gustavo
<mvo> cachio: and for you obviously
<cachio> mvo, it works for me but not today
<cachio> but I'll block the calendar
<mup> PR snapd#4930 closed: skip test that requires internet when not present <Created by rkitover> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4930>
<mvo> cachio: ok, thank you
<cachio> mvo, is it gonna by just on wednesdays? or every day?
<mvo> cachio: only (some) wednesdays
<cachio> mvo,
<cachio> ok
<cachio> mvo, when is comming the new sru?
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/4968 is broken on tests FYI
<mup> PR #4968: RFC: ifacemgr: remove stale connections on startup <Created by stolowski> <https://github.com/snapcore/snapd/pull/4968>
<mup> PR snapd#4975 closed: osutil: fix fstab parser to allow for # in field values (2.32) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4975>
<pstolowski> zyga: yep i know, i had to park this for a while due to autoconnect
<zyga> ack
<zyga> thanks
<pstolowski> zyga: i have fixes and will also add new test
<jdstrand> zyga (cc timp): that was the exact issue I saw yesterday. apparmor denial on attr/current and aa-exec. no interfaces listed for lxd with snap interfaces. I had to stop/start snapd to get them back then do 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.lxd.*
<zyga> jdstrand: thank you for confirming that, I wonder what could be the cause
<zyga> jdstrand: wich core channel were you on then?
<zyga> I was suspecting some window when snapd restarts while there's an unmounted lxd snap
<zyga> jdstrand: it feels like the place when we read snap.Info is flaky in that the error is non-fatal
<zyga> and we carry on knowing *nothing* about that snap
<jdstrand> zyga (cc timp): oh I forgot. I did: sudo systemctl stop snapd ; sudo systemctl start snapd # now interfaces show up) ; sudo snap disconnect lxd:lxd-support ; sudo snap connect lxd:lxd-support # now the interfacec works
 * cachio afk
<zyga>  yeah, that's that
<jdstrand> ie, I tried apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.lxd.* before the disconnect/connect and realized it didn't have the policy in place
<jdstrand> zyga: I'm on beta still
<jdstrand> 16-2.32.2
<zyga> yep
<zyga> that all hints to missing snap info
<zyga> and missing interfaces
<jdstrand> zyga: it may not be related, but lxd-support is one of the few interfaces with an installation constraint
<zyga> oh, what is that constraint?
<zyga> are you referring to the policy?
<jdstrand> zyga: base declaration
<jdstrand> zyga: allow-installation: false
<zyga> right
<jdstrand> zyga: so a snap from the store must have a snap declaration to install the snap (--dangerous installs do not)
<jdstrand> I dono't know if it is related
<jdstrand> don't
<zyga> jdstrand: can you look at journalctl snapd.service
<zyga> there's a log if we drop an interface
<zyga> if it was that we'd have a trace
<jdstrand> but it is the only snap I know that has this
<zyga> that'd be a nice hit to what the issue is
<zyga> it may be that we did read it but then skipped it
<jdstrand> zyga: I experienced the problem yeserday. That put's us at something happening between 18:00 on Apr 2 through 10:25 Apr 3. I've pasted since Mar27 snapd start up through today here: https://paste.ubuntu.com/p/ySSrxXRgyK/
<jdstrand> puts*
<zyga> thank you
<zyga> I'll review it after standup
<jdstrand> zyga: there is some weird stuff in there
<zyga> woah
<zyga> Apr 03 10:25:29 localhost snapd[27535]: 2018/04/03 10:25:29.156759 helpers.go:214: cannot connect plug "lxd-support" from snap "lxd", no such plug
<jdstrand> Mar 27 12:44:27 localhost snapd[2848]: 2018/03/27 12:44:27.304321 stateengine.go:101: state ensure error: cannot refresh snap-declaration for "lxd": Get https://api.snapcraft.io/api/v1/snaps/assertions/snap-declaration/16/J60k4JY0HppjwOjW8dZdYc8obXKxujRu?max-format=2: dial tcp: lookup api.snapcraft.io on 127.0.0.53:53: server misbehaving
<zyga> pstolowski: ^ we cannot merge your fix for stale connections before we get to the bottom of this
<zyga> or we'll mess up real state
<zyga> thank you
<jdstrand> zyga: note that the snap declaration wasn't pulled down days before
<jdstrand> I don't know if later fetches worked out ok
<jdstrand> at 10:25 on Apr 3, that is when I stopped/started lxd manually
<jdstrand> actually, maybe that was 11:37
 * jdstrand checks irc backscroll
<jdstrand> ah, it was 11:37
<jdstrand> the thing at 10:25 was not me. 2708  Done    2018-04-03T15:24:34Z  2018-04-03T15:26:04Z  Auto-refresh snaps "chromium", "lxd", "core"
<jdstrand> that is in UTC and corresponds to the 10:25 restart
<zyga> jdstrand: did you see any snaps listed as broken at that time?
<zyga> jdstrand: we are discussing this issue now and we understand how it happens mechanically (we should be albe to reproduce that) but we have no idea (yet) why it happens
<jdstrand> zyga: no
<jdstrand> https://forum.snapcraft.io/t/snapped-lxd-has-stopped-working-aa-exec-doesnt-exist-in-the-snap/2356/27
<jdstrand> I lined up all the times
<jdstrand> it looks like at 10:24 *both* core and lxd were updated
<jdstrand> refreshed*
<zyga> yes, its' something we suspect
<jdstrand> then at 11:33 I noticed things went awry
<zyga> if snapd starts when snap (or snaps) are unmounted we would hit this
<zyga> it was just lxd for you, right?
<jdstrand> and 11:37 I stopped/started manually and 11:39 diconnected/connected
<zyga> (only a subset of the refreshed snaps could be affected)
<jdstrand> zyga: it was what I noticed. it seems chromium could've been affected (it was refreshed at the same time)
<zyga> but wasn't?
<jdstrand> I don't use it regularly
 * jdstrand uses firefox
<jdstrand> so I don't know
<zyga> we need to look at ordering and at things like ensuring that when systemd says "it's mounted" it really really is
<zyga> thank you
<jdstrand> I can say the firefox snap wasn't misbehaving
<popey> I have a core system which booted yesterday but today hangs
<popey> https://usercontent.irccloud-cdn.com/file/d1gWsl07/IMG_20180404_132619.jpg
<popey> Where should I file this? (can I revert back to previous core [given I can't boot it]) ?
 * kalikiana lunch
<popey> mvo: ^ do you know where I should file this?
<jdstrand> zyga: fyi, I added a few more comments
<mborzecki> zyga: snap switch && snap refresh ?
<mvo> popey: what happens if you power-cycle it? it always hangs at this point?
<zyga> jdstrand: we have a way to loop through this code to hit the issue ifff it is a timing bug
<popey> mvo: hangs at the same point
<zyga> mborzecki: yes, on a pair of core + lxd
<mvo> popey: the forum is a good place for a report - also here, because OMG and we want to know about it
<mvo> popey: what is strange is that there is only kernel message, nothing from userspace AFAICT
<mvo> popey: which indicates a kernel problem, can you get to the grub prompt?
<mvo> popey: also even if its a kernel problem the rollback magic should have saved us/you :(
<mvo> popey: so â¦
<popey> oh man, 4th boot now it's moving
<mvo> popey: *cough*
<mvo> popey: magic! :) :/ :(
<popey> :S
<zyga> logger.Noticef("cannot retrieve info for snap %q: %s", snapName, err)
<zyga> jdstrand: can you grep in your full journal for any hint of that
<mvo> popey: moving in what direction? successful boot? or just hangs differently?
<popey> its successfully booted now
<popey> <shrug emoji>
<zyga> mvo: if we had support for hardware watchdog we would be able to recover such issues automatically (what popey ran into)
<popey> it totally hung 3 times, but this time it went through, no idea why.
<zyga> jdstrand: I also totally missed this
<zyga> Mar 27 12:44:27 localhost snapd[2848]: 2018/03/27 12:44:27.303347 autorefresh.go:327: Cannot prepare auto-refresh change: cannot refresh snap-declaration for "lxd": Get https://api.snapcraft.io/api/v1/snaps/assertions/snap-declaration/16/J60k4JY0HppjwOjW8dZdYc8obXKxujRu?max-format=2: dial tcp: lookup api.snapcraft.io on 127.0.0.53:53: server misbehaving
<zyga> if there's no assertion, we should not even attempt to continue refreshing
<mvo> zyga: ohhhh
<mvo> zyga: that is an interessting hint
<zyga> Apr 03 10:25:29 localhost snapd[27535]: 2018/04/03 10:25:29.156224 helpers.go:214: cannot connect plug "gsettings" from snap "chromium", no such plug
<zyga> but it seems the issue did affect both chromium and lxd
<zyga> so unclear if this is just the assertion refresh
<zyga> Apr 03 10:25:29 localhost snapd[27535]: 2018/04/03 10:25:29.156232 helpers.go:214: cannot connect plug "home" from snap "chromium", no such plug
<zyga> for instance home is not gated
<zyga> so not having an assertion would not change anything
<zyga> I will try to reproduce this manually now
<zyga> mvo: I just confirmed that logger.Noticef does *not* work
<zyga> probably because at that stage, logger is just not setup yet
<zyga> Chipaca: ^
<Chipaca> zyga: ?
<zyga> mvo: I stopped snapd, stopped a mount unit of a random sanp, started snapd
<zyga> what was logged was
<zyga> kwi 04 14:43:28 fyke snapd[32408]: 2018/04/04 14:43:28.481566 helpers.go:106: invalid snap version: cannot be empty
<Chipaca> zyga: logger is set up in snapd/main.go's init()
<zyga> ha
<Chipaca> zyga: so I call shenanigans :-)
<Chipaca> in fact it's the first line of that init :-)
<Chipaca> of course, that init runs after all other inits, because of the deps tree
<Chipaca> but that's still pretty honking early :-)
<zyga> grepping for that message on my system I see a case of snapd starting and not having snaps mounted
<zyga> Chipaca: I will patch it to just print
<zyga> but I suspect something is wrong there
<popey> jdstrand: when you get a mo. can I have an exception for https://dashboard.snapcraft.io/snaps/emoj/revisions/19/ ?
<popey> (it doesn't need a desktop file, but needs x11 interface)
<pedronis> mvo: I applied feedback or answered in 4900
<zyga> ah
<zyga> mvo: we say "cannot read snap %q: ..." and assign that to info.Broken
<mvo> pedronis: thanks, I'm on the remaining bits now
<zyga> we don't return an error
<zyga> slightly funny to see this: https://github.com/snapcore/snapd/pull/4900#discussion_r179108664
<mup> PR #4900: many: use the new install/refresh API by switching snapstate to use store.SnapAction <Critical> <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4900>
<mborzecki> Apr 04 13:04:33 ubuntu snapd[1037]: 2018/04/04 13:04:33.934552 store.go:1459: DEBUG: Hashsum error on download: sha3-384 mismatch for "core": got 86d2a911e843c48c8f49c459b5b7259a5ca786ad4e05b1f98a353082aee6dc79c0cc08ca9c09a3c603675a3acead29d9 but expected 7b354270492a85a54b44ad78c000e6a61ca38a49d5ab57d79a2e9d5eca20db9af89a1186b7b14d78ae232ec2f4824372
<mborzecki> that's unexpected
<pedronis> zyga: maybe it should be moved lower?  I'm open to input,  in a meeting now though
<zyga> pedronis: I was just adding similar logging
<mborzecki> off to pick up the kids
<mup> Issue snapcraft#2048 opened: Thank you <Created by jsamr> <https://github.com/snapcore/snapcraft/issue/2048>
<pstolowski> pedronis, mvo : does this sound sensible/doable for autoconnect spread test: 1.snapd installed from distro deb; 2.snap download core; 3.unsquashfs core, inject new snapd, squash back; 4.snap download lxd; 5. point fake store at both modified core & lxd (plus do assertion magic which i'm not yet clear about); 6. snap install lxd?
<mvo> pstolowski: in a meeting right now (and so is pedronis) sounds sane
<mup> PR snapd#4978 opened: overlord,interfaces: be more vocal about broken snaps and read errors <Created by zyga> <https://github.com/snapcore/snapd/pull/4978>
<zyga> mvo: extra logging I'd like to add to this release: https://github.com/snapcore/snapd/pull/4978
<mup> PR #4978: overlord,interfaces: be more vocal about broken snaps and read errors <Created by zyga> <https://github.com/snapcore/snapd/pull/4978>
<zyga> also refuse adding broken snaps to repo
<zyga> pstolowski: ^
<zyga> I think you are the only one to review now :)
<pedronis> pstolowski: we already build that core  that way at some point
<pstolowski> pedronis: i know, I just need to prevent it from getting mounted immediately (it's update_core_snap_for_classic_reexec)
 * zyga -> walk
<pstolowski> zyga: looks sane, quick questions: why "[stderr]"? where does Stderr go? just journal?
<kalikiana> re
<zyga> Yes
<zyga> To error part of it
<zyga> The [stderr] is to see if we are doing something wrong with o logger
<mup> Bug #1761187 opened: ~/.snap/ not available for root on some systems <Snappy:New> <https://launchpad.net/bugs/1761187>
<jdstrand> zyga: journalctl|grep 'cannot retrieve info for snap' returns nothing
<zyga> Ack
<zyga> I will setup a loop
<zyga> Just afk now
<mup> Bug #1761187 changed: ~/.snap/ not available for root on some systems <Snappy:New> <https://launchpad.net/bugs/1761187>
<Chipaca> mup: you just said that
<mup> Chipaca: I apologize. I'm a program with a limited vocabulary.
<pstolowski> lol
<cachio> lol
<pstolowski> mup: Chipaca is making fun of you!
<mup> pstolowski: I really wish I understood what you're trying to do.
<cachio> :)
<pstolowski> yeah me too
<pedronis> Chipaca: can you look #4978
<mup> PR #4978: overlord,interfaces: be more vocal about broken snaps and read errors <Created by zyga> <https://github.com/snapcore/snapd/pull/4978>
<pedronis> zyga: IÂ think that code is logging too much,  CurrentInfo will call readInfoAnyway
<zyga> I can trim some, yeah
<mvo> mborzecki: 4976 fails, I guess you know about this already(?)
<mvo> zyga: any new data on the issue?
<zyga> mvo: re, I was afk (kids/lunch/dog)
<zyga> mvo: I did some digging and it seems we don't even return an error
<zyga> mvo: we return snap info with Broken field set
<zyga> mvo: I provided a patch that adds verbosity and barrages broken snaps from entering the repository
<mvo> zyga: ok, I see the PR
<mvo> zyga: thank you!
<zyga> mvo: I haven't setup a loop that would reproduce the refresh cycle issue yet
<pedronis> pstolowski: I think we can start with lxd,  lxd is a bit strange in the sense that is both our typical case, but a bit fragile on its own
<zyga> mvo: I will setup the loop soon, if I hit a case when it reproduces we will have some confirmation
<mvo> zyga: ta
<zyga> mvo: while that runs I will review tasks we do on refresh to look for issues
<mvo> zyga: why the logger.Noticef() and the fmt.Fprintf() ? is the notice not sufficient?
<pstolowski> pedronis: ok, that's what i'm basing my spread test on
<zyga> mvo: maybe, I think so but  wanted to double check
<zyga> mvo: I will drop the fmt.Fprintf calls if logger works
<zyga> better safe than sorry
<pedronis> zyga: we don't read snaps that early, if there's some logging there should be the rest
<jdstrand> popey: ok
<popey> jdstrand: thanks
<Chipaca> grah, grah, grah, everything is terrible
<Chipaca> pedronis: looking
<mvo> Chipaca: also 4969 if you have spare cycles for reviews
<Chipaca> mvo: I do
<Chipaca> for #1761193 I'm tempted to use 'cat' to read the auth.json file... :-/
<mup> Bug #1761193: ~/.snap/ not available for root on some systems <snapd:New> <https://launchpad.net/bugs/1761193>
<Chipaca> as in âif running under sudo, do 'su -c "cat the/file" $SUDO_USER'â
<Chipaca> the alternative is to leave goroutines stuck, which might not be so terrible
<Chipaca> as this is in client, they're short-lived
<zyga> FYI this test always fails on my laptop
<zyga> ... value *errors.errorString = &errors.errorString{s:"cannot obtain bus name 'io.snapcraft.Launcher'"} ("cannot obtain bus name 'io.snapcraft.Launcher'")
<zyga> FAIL: cmd_userd_test.go:62: userdSuite.TestUserd
<zyga> pedronis, mvo: updated https://github.com/snapcore/snapd/pull/4978/files
<mup> PR #4978: overlord,interfaces: be more vocal about broken snaps and read errors <Created by zyga> <https://github.com/snapcore/snapd/pull/4978>
<zyga> (force pushed for cherry pick)
<zyga> dropped fprintfs
<zyga> and one log
<mvo> ta!
<zyga> at the very least we will (maybe) get better logs next time
<zyga> mvo: is .3 scheduled for today?
<mvo> zyga: depends on when we get the fixes, but yes, would love to do it today
<mvo> zyga: the "exec: aa-exec: Permission denied" is also a bit alarming
<didrocks> kyrofa: hey! I hope you are well :) I'm really puzzled about bug #1761127 and can't even find a workaround
<mup> Bug #1761127: On Travis (not a real vte), releasing to a branch name during snapcraft push prints a stacktrace <Snapcraft:New> <https://launchpad.net/bugs/1761127>
<diddledan> is the libGL problem on Bionic (possibly related to nVidia binary drivers) with snaps being worked upon? : libGL error: No matching fbConfigs or visuals found
<diddledan> I think it's because of the move to a unified loader? *looks for the right deb* .. `libglvnd0`
<zyga> mvo: that is because aa-exec is not allowed by default template
<zyga> mvo: when lxd does't have the lxd-support interface at all this would happen
<pstolowski> mvo, zyga the spread test is painful, i'm learning through experimentation and trial-and-error
<zyga> diddledan: can you try beta? it should be fixed there
<pedronis> pstolowski: can IÂ help somehow?
<zyga> mvo: the fedora issue should be gone now
<mvo> zyga: right, I can reproduce this here on 17.10 by purging snapd and then installing it
<mvo> zyga: and then snap install lxd
<zyga> mvo: oh? can you be more specifc
<zyga> ah
<mvo> pstolowski: yeah, its hard
<zyga> but isn't that the auto-connect issue
<zyga> or are you saying that you can reproduce by pruging, installing lxd and then see lxd without any interface at all
<zyga> (as said by snap interfaces)
<pedronis> pstolowski: we have other tests using the fakestore but probably not exactly how you need it
<diddledan> zyga: ok, the beta fixes a game I've packaged (used for quick test) but the solus-runtime-based steam still fails
 * diddledan wonders where ikey got to
<pstolowski> pedronis: yes, and there are differences, so not easy to tell what's crucial and what not; if you can spot what might be missing still https://pastebin.ubuntu.com/p/6Jd6rRZJGk/ then this could save me some iterations
<zyga> diddledan: that is probably something for ikey and jdstrand
<mvo> zyga: I did "apt purge snapd; apt install snapd/artful-updates; snap install lxd; lxc": /snap/lxd/6492/commands/lxc: 6: exec: aa-exec: Permission denied
<mvo> zyga: lxd-support is not connected
<zyga> mvo: does it exist?
<pedronis> pstolowski: mvo: I fear we have a big issue
<pedronis> with the tests
<mvo> zyga: it does
<zyga> if it exists, that's the bug that is well understood now that I believe pawel is fixing
<zyga> ok
<mvo> pedronis: what exactly?
 * diddledan pokenprods jdstrand :-p
<zyga> in our case the bug is that the plug is gone, as evidenced on the forum...
<mvo> zyga: ok, if its the same bug its all good
<pedronis> pstolowski: mvo: we want to use the deb but also the fakestore, but by definition that's not possible
<mup> PR snapd#4979 opened: overlord,interfaces: be more vocal about broken snaps and read errors (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/4979>
<mvo> pedronis: uhhh, indeed
<pstolowski> pedronis: oh why
<pedronis> pstolowski: mvo: the official deb will never trust the fakestore
<pedronis> (that's a feature)
<pedronis> but is annoying here
<zyga> mvo: I sent a backport of the logging PR
<zyga> and will try to reproduce this in a loop
<mvo> pedronis: yeah, oh well
<mvo> zyga: ta!
<mvo> pstolowski: can you push what you have? without the spread test?
<mvo> pstolowski, pedronis I think we understand the issue, so getting this into edge might be good as a first pass.
<pedronis> mvo: pstolowski: at most we can write a daily test that uses the the deb and the snap in edge
<pedronis> there's still value to that
<pedronis> but cannot use what's on masrer
<pstolowski> mvo: i can, let me just finish unit test
<mvo> pstolowski: sure
<mup> PR snapd#4974 closed: ifacestate: injectTasks helper <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4974>
<mvo> pstolowski: once that has landed we can test locally by modifying release/2.29 to install the edge core by default and running it locally. then we do "snap install lxd" (with no core yet) and we get the (fixed) core from edge and the re-exec should work
<mvo> pstolowski: its not great but as pedronis said we have no way currently to test this for real
<kyrofa> Hey there didrocks! I'll take a look this morning, see if we can figure it out
<pstolowski> mvo: sounds good
<didrocks> kyrofa: thanks! As it only happens on Travis, it's a little bit painful it seems. FTR, I tried with snapcraft release as well and as a simple edge/test in https://travis-ci.org/ubuntu/communitheme-snap-helpers/builds/362179292, but same issue. Same command with local "docker run" works perfectly
<pedronis> pstolowski: sorry for making you chase impossible tests
<didrocks> (but basically, our Travis instruction don't work on non branch releases)
<pedronis> mvo: to write a daily we would need at least to have an envvar to change which channel we get core if it's not there
<pstolowski> pedronis: np
<kyrofa> didrocks, looks like you're successfully pushing, but then the store is giving us some error that we don't know how to parse
<kyrofa> didrocks, how did you install snapcraft?
<mup> PR snapd#4980 opened: Revert "spread.yaml: switch Fedora 27 tests to manual (#4962)" <Created by zyga> <https://github.com/snapcore/snapd/pull/4980>
<kyrofa> Oh, the docker image
<didrocks> kyrofa: docker run snapcore/snapcraft
<didrocks> yep
<didrocks> kyrofa: so, push is working, but release to a branchname don't
<didrocks> release to "edge" works
<didrocks> "edge/test" doesn't
<kyrofa> didrocks, but it works locally?
<kyrofa> How weird
<didrocks> (but works locally, with a docker image)
<didrocks> yeah :/
<didrocks> I think it's a vte vs non real vte thingâ¦
<kyrofa> didrocks, how are you authenticating?
<didrocks> kyrofa: encrypted file creds, decrypted on build
<didrocks> as told, replacing "edge/test" by "edge" only works, so, cred issues are out
<kyrofa> didrocks, i.e. using export-login?
<kyrofa> Or your own real creds?
<didrocks> snapcraft enable-ci travis created an encrypted file and pushed env var to travis
<kyrofa> didrocks, ah, then it is a creds issue
<didrocks> oh?
<didrocks> why edge would work when edge/test doesn't?
<kyrofa> didrocks, enable-ci travis creates credentials that can only push to edge
<didrocks> ahhhhhh
<kyrofa> didrocks, you want export-login
<zyga> Caelum: the instructions are merged now
<didrocks> kyrofa: let me look on instructions for this
<kyrofa> didrocks, use snapcraft export-login
<kyrofa> didrocks, you can tune your creds how you like
<didrocks> kyrofa: I think there is still the "it should tell you without printing a stacktrace" bug ;)
<kyrofa> didrocks, oh totally, that we can fix
<kyrofa> didrocks, snapcraft doesn't know what the creds can and can't do, so we rely on the store to tell us. But we get all sorts of different error formats from them :P
<didrocks> fun ;)
<didrocks> kyrofa: ok, I think I need to export that in a file, then, encrypt it before pushing
<didrocks> shouldn't --channels=edge including --channels=edge/* ?
<didrocks> include*
<kyrofa> didrocks, to the length of my knowledge, the store ACLs don't support wildcards
<kyrofa> cprov may know better
<didrocks> so, basically, I need to give unrestricted access with my creds
<didrocks> to create branch-on-the-go
<kyrofa> didrocks, you can at least limit it to the specific snap
<didrocks> (basically, based on the PR name)
<didrocks> yeah
<kyrofa> didrocks, also limit it only to uploads
<didrocks> is the list of acls somewhere?
<didrocks> (the help only mention acls option)
<kyrofa> didrocks, https://dashboard.snapcraft.io/docs/api/macaroon.html#post--dev-api-acl-
<didrocks> awesome!
<kyrofa> I've been meaning to get those into snapcraft itself
<kyrofa> cprov very helpfully documented them fo rus
<didrocks> kyrofa: thanks a lot, I would never have figured out this restriction with this stacktrace! ;)
<didrocks> at least, I'm unblocked now
<kyrofa> didrocks, my pleasure! Should be easy to reproduce, I'll triage the bug and we'll get it fixed, thanks for the thorough report as always :)
<didrocks> kyrofa: yw :-)
<kyrofa> didrocks, by the way, are you building snaps per PR or something?
<kyrofa> How do you plan on dealing with forks?
<kyrofa> didrocks, by the way, if you don't want to encrypt, you can `travis env set SNAP_TOKEN "$(cat my-exported-login)"` and then use `echo "$SNAP_TOKEN" | snapcraft login --with -`
<didrocks> kyrofa: yes, that's my plan. Basically, only PR made by core contributors will be built/testable this way
<kyrofa> Gotcha
<zyga> another bug getting in the way https://www.irccloud.com/pastebin/Q6aoFA0A/
<didrocks> I'm still ensure the build script can at least build on push for people to test
<didrocks> kyrofa: excellent! I'll use this :)
<zyga> bug.sh https://www.irccloud.com/pastebin/bzEWq7pw/
<zyga> not a happy day
<kyrofa> didrocks, you might also like this: https://github.com/travis-ci/dpl/pull/800
<mup> PR travis-ci/dpl#800: Add snap provider <Created by kyrofa> <https://github.com/travis-ci/dpl/pull/800>
<mvo> zyga: uhhh
<zyga> I think we must add some code that waits for core restart with rest of setup
<didrocks> kyrofa: oh, sounds that will enable me to reduce a lot what I'm doing right now
<zyga> pedronis: ^ not sure what you would suggest for this, I'm looking at the snapd restart code now
<zyga> mvo: FYI, I ran bug.sh exactly once :/
<zyga> mvo: holly cow
<zyga> reproduced the bigger bug
<zyga> 2nd run :|
<zyga> I have lxd without lxd-support now
<zyga> lxd-support bug trivially reproduced  https://www.irccloud.com/pastebin/rootNBq3/
<zyga> details of the change refreshing core and lxd together
<zyga> https://www.irccloud.com/pastebin/AxjIVck6/
<zyga> note that spawn and ready times are more interesting than task order
<pedronis> zyga: there's no easy way to achieve that
<pedronis> zyga: also there are no errors there?
<pedronis> how does we get no interfaces
<pedronis> and no errors
<zyga> no, no errors
<zyga> because the snap.Info is returned
<zyga> just has Broken field set
<zyga> :/
<pedronis> but that doesn't relate to core
<zyga> we never return error if meta/snap.yaml cannot be found
<zyga> pedronis: perhaps, I don't know yet
<zyga> I ran it together to force a restart
<zyga> this was done on my bionic laptop
<mvo> zyga: yeah, I also have the lxd without lxd-support issue, its trivial to reproduce for me as well. but isn't that what pstolowski is fixing right now?
<zyga> mvo: no
<zyga> mvo: this is from stable core
<zyga> mvo: and again, _threre is no plug_
<zyga> this is not a connect issue
<zyga> this issue is that we have nothing to connect to
<pedronis> do we think mount has happened but not?
<pedronis> like we don't wait on mount enough
<mvo> zyga: is https://www.irccloud.com/pastebin/raw/rootNBq3 the pastebin? if so, there is ":lxd-support                        -" in the snap intefaces? or am I confused?
<zyga> https://www.irccloud.com/pastebin/F2qfHSP1/
<zyga> this is key
<zyga> there's no plug at all
<zyga> there must be a plug on the lxd snap
<zyga> the slot you pasted is the implicit slot on core
<zyga> which is there even if we cannot read core's snap.yaml
<pstolowski> zyga: and you think this happens because we're not waiting for core install?
<zyga> no, I don't know why yet
<pedronis> what's the task task that does mount again
<mvo> zyga: aha, thanks! that was what I was missing
<zyga> more clear evidence of this bug (shorter) https://www.irccloud.com/pastebin/tmigy3Hi/
<zyga> pedronis: it is mount-snap
<pedronis> zyga: there's no Mount at all in your changes
<pedronis> afaict
<zyga> whaaaa
<zyga> is it another bug where old core vs new core taks are different?
<pedronis> we didn't change it in a while
<zyga> ??? https://www.irccloud.com/pastebin/XaWi8TtG/
<pedronis> but maybe we aren't setting up tasks correctly anymore
<zyga> why is that conditional?
<pedronis> that I don't know
<pedronis> but in you case the condition should be false
<pedronis> or so IÂ hope
<pedronis> but I don't see Mount in your pastebin
<zyga>     // check if we already have the revision locally (alters tasks)
<zyga>     revisionIsLocal := snapst.LastIndex(targetRevision) >= 0
<mvo> zyga: 2016 - thats a long time ago
<zyga> "locally" is confusing here
<zyga> it looks like switch specific artefact
<pedronis> yes, it means it already there on disk
<zyga> so perhaps red herring somehow
<zyga> because they are both mounted
<mvo> zyga: yeah, it will already be mounted
<mup> PR snapd#4981 opened: ifacestate: inject autoconnect <Created by stolowski> <https://github.com/snapcore/snapd/pull/4981>
<zyga> but good hunch
<pedronis> but if they are mounted
<pedronis> how can we have no plugs?
<pstolowski> mvo: the PR: https://github.com/snapcore/snapd/pull/4981
<mup> PR #4981: ifacestate: inject autoconnect <Created by stolowski> <https://github.com/snapcore/snapd/pull/4981>
<zyga> part of journal after affected snapd restart https://www.irccloud.com/pastebin/Rp3GCuu2/
<zyga> we add snaps first, reload connections next
<zyga> whatever could cause this is beyond me now
<zyga> though this code doesn't log the fancy broken snaps
<zyga> so ... maybe we can merge that PR and rebuild core
<zyga> for a low-tech reproducer
<mvo> zyga: yeah, I think that will definitely help
<mup> PR snapd#4978 closed: overlord,interfaces: be more vocal about broken snaps and read errors <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4978>
<mup> PR snapd#4979 closed: overlord,interfaces: be more vocal about broken snaps and read errors (2.32) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4979>
<zyga> mvo: what do we need now?
<mvo> Chipaca: 4845 is probably interessting for you
<zyga> mvo: ppa build trigger + core build trigger?
<pedronis> pstolowski: I don't understand that code,  a change can be about many snaps
<mvo> Chipaca: (mark asked about when we get version info for c-n-f :)
<pstolowski> zyga: i've just got state.json from the user who reported this originally.. nothing suspicions there and since we're able to reproduce we won't learn anything new from it I guess
<pedronis> pstolowski: we need to add an autoconnect for each snap, not just for the first
<mvo> zyga: yeah, let me do this
<mvo> zyga: vendor-sync first
<zyga> pstolowski: yeah, I think it's all too easy to reproduce
<zyga> mvo: thank you
<pstolowski> pedronis: you're right...
<zyga> mvo: I can work on this overnight but I need to break now, I'm on the phone all the time so if you have ideas I can come over
<zyga> I just need to manage kids for a while
<mvo> zyga: sure
<mvo> zyga: thanks for all your help
<mvo> zyga: I merge this now and once the new edge is ready I can re-run your script.
<pedronis> pstolowski: IÂ left a comment in the PR
<zyga> mvo: please backport https://github.com/snapcore/snapd/pull/4969
<mup> PR #4969: interfaces: make system-key more robust against invalid fstab entries <Squash-merge> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4969>
<zyga> ohhh shit
<zyga> forgot to squash
<mup> PR snapd#4969 closed: interfaces: make system-key more robust against invalid fstab entries <Squash-merge> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4969>
<Chipaca> mvo: +1
<zyga> mvo: sorry, I didn't mean to :(
<mup> PR snapd#4976 closed: cmd/snap-mgmt: remove timers, udev rules, dbus policy files (2.32) <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4976>
<pedronis> also there's  strange branch on the main repo:  revert-4969-system-key-robustness
<zyga> I think that was me clicking on the revert trying to undo
<zyga> we can remove it
<mvo> zyga: no worries, I can cherry-pick one-by-one, its not that terrible
<mvo> zyga: go and take care of the kids :)
<zyga> yeah, I'm going now
<zyga> ttyl
<mup> PR snapd#4982 opened: interfaces: make system-key more robust against invalid fstab entries (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4982>
<mup> PR snapd#4983 opened: osutil/sys, client: add sys.RunAsUidGid, use it for auth.json <Created by chipaca> <https://github.com/snapcore/snapd/pull/4983>
<Chipaca> mvo: ^ your old friend 'drop privileges'
<Chipaca> p.s. when are we moving to 1.10 :-)
<zyga> Just observation from a phone: it cannot be a mount issue as I had both snaps mounted
<zyga> So something else rejected the lxd snap (validation perhaps)
<Chipaca> huh, launchpad giving me 'address unreachable'
<Chipaca> and it's back
<pedronis> unless we have grown something that unmounts things
<pstolowski> pedronis: addressed your feedback + made a small addition to injectTasks helper, not strictly a bug, but I think it's good if extraTasks wait for main task - only affected tests at the moment that had very few tasks and no one waited for mainTask
<cmars> hi, where should i open a snapd bug?
<Chipaca> cmars: if it's snapd, https://bugs.launchpad.net/snapd/+filebug
<Chipaca> cmars: if it might be snapd, but it might be something else, https://bugs.launchpad.net/snappy/+filebug
<Chipaca> and then we assign it as appropriate
<cmars> Chipaca: thanks!
<Chipaca> cmars: what did you break _now_? :-p
<cmars> Chipaca: asking for a friend :)
<Chipaca> :-)
 * kalikiana wrapping up for the day
<Chipaca> holy potato, that's a lovely stacktrace
<pstolowski> zyga: i've run your bug.sh and got https://pastebin.ubuntu.com/p/SJTK4qP5Dc/
<zyga> that's another bug
<zyga> I also got it
<zyga> run it again
<pstolowski> ah, ok
<mvo> zyga, pstolowski fwiw, i triggered the new core build, we should have more debug info soon (~15-30min)
<zyga> that's very good, thank you
<pstolowski> ty
<pedronis> pstolowski: IÂ noticed something weird,    at the beginning of doSetupProfiles we do addImplicSlot but IÂ don't see that in doAutoconnect
<pedronis> do we need that or not
<pedronis> pstolowski: wasn't the idea at some point that we wanted to move that somewhere else
<mup> PR snapd#4982 closed: interfaces: make system-key more robust against invalid fstab entries (2.32) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4982>
<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>
<zyga> mvo: so, weird - new core, no error logged, still same bug
<zyga> plus, for chipaca, I got this error: kwi 04 19:35:14 t470 snapd[23332]: 2018/04/04 19:35:14.803094 stateengine.go:101: state ensure error: cannot decode new commands catalog: got unexpected HTTP status code 403 via GET to "https://api.snapcraft.io/api/v1/snaps/names?confinement=strict%2Cclassic"
<Chipaca> zyga: that's probably fine
<Chipaca> i mean, i don't know why the store is 403'ing that endpoint, but it's not fatal
<pedronis> Ensure errors should block further ensure step
<pedronis> should not
<zyga> ah, error is when I go back to stable
<zyga> so expecte d:/
 * Chipaca had a panic attack for 7 seconds there
<zyga> let's try the other way around now
<pedronis> Chipaca: yes, that 403 is a bit weird
<zyga> so
<zyga> stable -> edge
<zyga> confirmed new core is there
<zyga> but no messages
<zyga> WTF
<zyga> maybe it isn't broken?
<zyga> I'll enable debugging
<pedronis> mvo: 4900 is green, also I removed the strange logging given that zyga's PR added it at a lower level
<mup> Bug #1761253 opened: Installing a network-bind snap along with core fails results in incorrect permissions <Snappy:New> <https://launchpad.net/bugs/1761253>
 * zyga adds debugging and repacks core
<zyga> mvo: I added some debugging and ... at the time snapd starts there's no lxd snap
<zyga> I get it now
<zyga> pedronis: it's funny really
<zyga> pedronis: the bug is here
<pedronis> it's disabled
<zyga>     snaps, err := snapstate.ActiveInfos(m.state)
<zyga> we skip inactive snaps
<pedronis> that's correct
<pedronis> but when we re-activate them
<pedronis> we don't do the right thing
<pedronis> IÂ suppose
<pedronis> well "correct"
<zyga> hmm
<pedronis> disable removes profiles
<pedronis> but doesn't remove from repo
<zyga> log of the issue https://www.irccloud.com/pastebin/nxyEebVA/
<zyga> so after snapd starts up, ignoring lxd, it proceeds with the 2nd half of lxd setup
<zyga> kwi 04 19:54:42 t470 snapd[7142]: 2018/04/04 19:54:42.808109 taskrunner.go:403: DEBUG: Running task 2249 on Do: Make snap "lxd" (6508) available to the system
<zyga> I will review that code next
<pedronis> we setup profiles
<pedronis> before ?
<pedronis> but the snap is not active
<mvo> pedronis: thank you!
<pedronis> it's again an issue that active is conflating too many things
<pstolowski> pedronis: addimplicitslots is only relevant for repo.AddSnap call below
<zyga> pedronis: where? I don't see it yet
<pedronis> zyga: we setup-profiles already  so the snap has profiles but is not active
<mvo> zyga: nice catch! about the inactive ones
<pedronis> so when we restart we don't load it
<zyga> pedronis: I think in this run lxd was security setup before the restart
<zyga> because I don't see any tasks for it
<pedronis> in the repo
<zyga> but it wasn't active yet
<pedronis> so it has profiles but is not active
<zyga> so it wasn't added
<pedronis> but we don't add it to the repo
<pedronis> when is made active
<zyga> and no plugs/slots
<zyga> and thus no connections
<zyga> we should add inactive snaps but don't build their profiles IMO
<zyga> pedronis: ^
<zyga> because if core hadn't restarted it would be still in the repo
<zyga> just inactive
<zyga> well, inactive in the state, in the repo there's no such notion
<zyga> well, normally it's already there
<zyga> we cannot blindly add it
<pedronis> does remove remove the snaps from the repo?
<zyga> disable removes profiles, enable adds them
<zyga> but neither affects the repo
<pedronis> but that is profiles
<pedronis> not repo
<pedronis> also I'm talking about remove
<zyga> pedronis: AFAIR it does not, let me lookg
<zyga> *look
<mvo> pstolowski, pedronis 4981 looks good to me know, WDYT?
<pedronis> zyga: IÂ wonder why are we seeing thins only now though, we should have had this form of problem since a long while
<zyga> more paralellism, restart at the "unlucky" time
<pedronis> that part of parallelism was always there
<pedronis> just lxd and snapd sending out a new release close to each other?
<zyga> maybe
<pedronis> anyway afaict we AddSnap  when we setup profiles and at start
<pedronis> so in theory   something should be added if it has profiles
<pedronis> sadly that != active
<zyga> pedronis: setup profiles adds the snap to the repo
<zyga> and removes any old snap from the repo
<zyga> remove profiles removes the snap from the repo
<pedronis> we have no memory of the setup profiles add though
<pedronis> only later the get active
<zyga> no becaues that's just in memory
<zyga> that's not the state
<pedronis> I know
<pedronis> that's our problem
<zyga> the pre-restart remembered it
<zyga> yes
<zyga> I agree,
<zyga> mvo: I think we know what's the issue now but ideas on how to address it are welcome
<zyga> pedronis: so what is that state that lxd is in
<zyga> it's not active yet
<pedronis> is not active
<zyga> but we setup profiles for it
<pedronis> but had profiles setup
<zyga> what do we call that state
<pedronis> but that's not a state tracked in state
<zyga> pending?
<zyga> right, I'm trying to invent a new name
<pedronis> we don't track that
<zyga> but all old snapds won't track that
<zyga> so ...
<zyga> a bit of a chicken and egg
<pedronis> removeProfiles
<pedronis> also remove from repo
<zyga> yes
<pedronis> so active is almost right except when not
<zyga> setup ensures we have the latest snap in the repo and generates profiles
<zyga> remove ensures we don't know about it and removes profiles
<zyga> haha, yes :)
<zyga> pedronis: one more super fun fact
<zyga> pedronis: has-profiles flag is not per revision
<pedronis> can we add the same snap again?
<pedronis> what happens in that case
<zyga> add no, it would clash
<zyga> remove and add yes
<zyga> wel
<zyga> well adding a snap that's empty is a no-op
<zyga> we only really track interfaces
<pedronis> anyway it doesn't help
<pedronis> because our problem is reloading connections
<zyga> part of the logic remembers revisions (via snap info) so that's why we remove/add snap on setup-profiels
<zyga> *profiles
<zyga> pedronis: I think my suggestion is still correct
<zyga> pedronis: load all snaps into repo
<zyga> pedronis: but setup security only for those that are active
<zyga> this would fix this issue
<zyga> (only on snapd startup, that is)
<zyga> then we have the right state to reconnect
<zyga> and to setup stuff later
<zyga> though... if inactive, which is "latest"
<zyga> which revision to pick?
<pedronis> sounds like we need   ProfileRevision in SnapState
<pedronis> we have Current but that a guess
<pedronis> if we are in the middle of other ops
<pedronis> otoh is probably what we use anyway
<zyga> can we add ProfileRevision in a way that will work on refreshes from snapd that have no idea about it
<pedronis> well we use it only if not Active
<pedronis> by definition if Active    ProfileRevison == Current
<pstolowski> zyga: if you add all snaps to repo and not just active, that will make their slots/plugs available to the system, no?
<zyga> pstolowski: we cannot add all, we need to add one of each
<zyga> pstolowski: which revision should we add?
<zyga> pstolowski: and besides, it's still a bit broke
<pedronis> it will also create problem with autoconnect
<pstolowski> zyga: ah, i see what you mean
<pedronis> we shouldn't atuoconnect to disabled snaps
<zyga> pstolowski: even if we add "all" then snap interfaces will tell you about snaps that are disabled
<zyga> pstolowski: that's not supposed to happen
<zyga> pstolowski: what we need to is to ensure that lxd can be installed the same way if core wasn't restarting
<zyga> track something we don't
<pstolowski> zyga: yes, exactly
<pstolowski> (about interfaces whose snaps disabled)
<zyga> kwi 04 20:21:35 t470 snapd[11725]: 2018/04/04 20:21:35.357788 snapstate.go:1696: DEBUG: skipping inactive snap lxd with snap state &{app [0xc420497400 0xc420497480 0xc420497500] false 6492 edge {false false false false false false false false false false false} map[lxc:0xc42031b380] false true 0}
<zyga> some explicit debugging to confirm this
<zyga> kwi 04 20:26:08 t470 snapd[16117]: 2018/04/04 20:26:08.840805 snapstate.go:1696: DEBUG: skipping inactive snap lxd with snap state &snapstate.SnapState{SnapType:"app", Sequence:[]*snap.SideInfo{(*snap.SideInfo)(0xc4200c7180), (*snap.SideInfo)(0xc4200c7200), (*snap.SideInfo)(0xc4200c7280)}, Active:false, Current:snap.Revision{N:6492}, Channel:"edge", Flags:snapstate.Flags{DevMode:false, JailMode:false, Classic:false,
<zyga> TryMode:false, Revert:false, RemoveSnapPath:false, IgnoreValidation:false, Required:false, SkipConfigure:false, Unaliased:false, Amend:false}, Aliases:map[string]*snapstate.AliasTarget{"lxc":(*snapstate.AliasTarget)(0xc420322360)}, AutoAliasesDisabled:false, AliasesPending:true, UserID:0}
<zyga> with field names
<pedronis> zyga: I see two possible fixes,   either we do something like ProfileRevision in snapstate use that and Active and Current to decide which snaps to add to the repo. or we teach doLinkSnap  to AddSnap if it's not there yet but then it would need to load the missing connections as well
<pedronis> and it breaks the ifacestate/snapstate separation
 * zyga looks at doLinkSnap code
<pedronis> it's already big and in the wrong package
<pedronis> the appeal is not needing more state
<pedronis> zyga: there's no cheap way to look at disk and be sure if a snap has profiles and for which revision?
<pedronis> (anyway that's not our usual approach)
<zyga> pedronis: no, we'd have to be "creative" but it's terrible
<jdstrand> stgraber: I wonder if your issues are at all related to https://forum.snapcraft.io/t/snapped-lxd-has-stopped-working-aa-exec-permission-denied/2356/34
<zyga> jdstrand: btw: we understand that bug very well now
<zyga> it's unfortunate coincidence but easy to trigger
<zyga> not a new bug in any way
<jdstrand> zyga: you are saying that stgraber's issue is a different, new one?
<zyga> jdstrand: we understand issues with missing interfaces that cause lxd issue with aa-exec
<pedronis> jdstrand: there are probably 3 different bugs
<zyga> pedronis: 3?
<jdstrand> zyga: to be clear stgraber's was related to fresh install and seem to be hitting all of a sudden. mine was refresh.
<zyga> jdstrand: yes
<zyga> ah, that's another bug perhaps
<pedronis> counting this one as well:  https://forum.snapcraft.io/t/2-0-lxd-snap-fails-on-sytems-with-partial-apparmor-support/4707
<zyga> deb -> snap missing task #1st bug
<pedronis> that hits fresh installs
<zyga> core, lxd refresh -> #2nd bug
<zyga> core, lxd refresh (hook cannot talk to snapd) -> #3rd bug
<zyga> core, lxd refresh (missing interfaces on lxd) -> #2nd bug
<zyga> that's what we konw
<pedronis> ah, so 4  with something to do with aa-exec
<zyga> ah, the partial apparmor is another one
<zyga> man, fun day :)
<zyga> pedronis: reading doLinkSnap now
<jdstrand> zyga: this is the one I was referring to: https://forum.snapcraft.io/t/auto-connected-interfaces-missing-on-initial-snap-install/4850
<pedronis> we havea PR to fix #1
<zyga> jdstrand: that's #1
<jdstrand> ok
<jdstrand> I don't think we need to do anything about https://forum.snapcraft.io/t/2-0-lxd-snap-fails-on-sytems-with-partial-apparmor-support/4707 (I justify why in the topic)
<zyga> I kind of feel this is something we need to think with a fresh mind
<jdstrand> that isn't really a snapd thing. the snap can workaround it while the kernel fix makes its way out there
<pedronis> jdstrand: to be honest it seems we discovered #2 and #3 because there were snapd and lxd release close to each other
<zyga> jdstrand: since you are here: where's the non-abstract x11 socket normally?
<pedronis> they are both preexisting bugs
<zyga> yes, it's an old bug
<zyga> with very unlucky timing
<jdstrand> zyga: /tmp/.X11-unix/
<zyga> jdstrand: aha
<jdstrand> /tmp/.X11-unix/X0
<zyga> bummer
<jdstrand> indeed
<zyga> why not /run?
<zyga> man that's so sad :/
<jdstrand> hysterical raisins
<zyga> I wanted to refactor snap-update-ns to run pre pivot
<zyga> then we could save that socket
<zyga> can we bind mount the socket from hostfs?
<jdstrand> sure
<zyga> would that be okay-ish?
<jdstrand> that is the request
<zyga> so x11/desktop/whatever interfaces could add a mount profile
<jdstrand> x11 and unity7, yes
<jdstrand> note that x11 and unity7 are often declared together
<zyga> for /run/snapd/hostfs/tmp/.X11-unix/ -> /tmp/.X11-unix/
<zyga> aha, good point, we don't handle duplicates
<zyga> well
<zyga> we do
<zyga> but not how we want it here
<zyga> jdstrand: I understand the issue now
<zyga> jdstrand: how can I disable the abstract socket for testing?
<zyga> jdstrand: to know I fixed it
<zyga> jdstrand: it seems simple (1 day work)
<jdstrand> zyga: I think you mean /var/lib/snapd/hostfs/tmp/.X11-unix/, no?
<jdstrand> zyga: otoh, idk. you might ask the desktop team
<zyga> ah, yes :)
<zyga> sorry, just tired now
<zyga> greyback: do you know how to disable the x11 abstract socket on bionic, for testing?
<jdstrand> pedronis: yes, with 2 and 3 I suspected it had to do with the fact the lxd and core were updated within the same refresh cycle, which is why it has been sporadic
<jdstrand> that will be a nice bug to have fixed
<jdstrand> the 3 that is will be nice together :)
<jdstrand> meh
<jdstrand> all 3 fixed will be nice :)
<zyga> mvo: around?
<mvo> zyga: yes, was just reading backlog
<mvo> zyga: so the bug is that snapd restarts and we loose state about lxd we only had in memory?
<zyga> yes
<zyga> I'm summarizing this in a new thread
<mvo> zyga: if so, would it make sense to force core refreshes before everything else ?
<pstolowski> mvo: ok, I got +1 from pedronis on autoconnect fix, but travis failed on device-registration test.. restarted the tests
<mvo> pstolowski: thanks!
<zyga> mvo: yes but it's still ugly that we don't have the full state
<mvo> zyga: on disagreement, just thinking aloud what we can do short term
<mvo> zyga: s/on/no/
<mvo> zyga: sorry
<zyga> https://forum.snapcraft.io/t/summary-of-core-lxd-refresh-bugs-discovered-today/4869
<zyga> mvo: I think it's a viable fix
<pedronis> mvo: it's a bit unclear what does that mean
<zyga> pedronis: if core is refreshed:
<pedronis> force core before anything else
<zyga> pedronis: abort other refreshes
<pedronis> that doesn't make sense
<zyga> pedronis: schedule refresh of all snaps after reboot
<zyga> (restart)
<zyga> so "snap refresh core lxd" becomes "snap refresh core && snap refresh lxd"
<zyga> (internally)
<pedronis> but you can do snap refresh core
<pedronis> snap refresh lxd
<zyga> yes
<zyga> and lxd would say "changes in proress (core)"
<zyga> I'm saying for short term
<zyga> .4 fix
<zyga> not forever
<zyga> this would fix more than one bug
<pedronis> it's not a trivial fix
<zyga> (it would fix all of them actually)
<zyga> if it's not trivial then that's not a good solution
<mvo> so just to double check, the state we are loosing is generated when the tasks for the refresh(core,lxd) is generated? and then we restart and those bits are gone?
<zyga> but I think it could be easire than a proper fix for each one
<mvo> it would not help if we make all other tasks wait for core refresh tasks first?
<zyga> mvo: the state we lose is interface repo
<zyga> mvo: if snapd hadn't restarted it would be in correct condition
<zyga> mvo: not fully, (see the autoconnct task issue) but mostly
<pedronis> my point is that splitting up autorefresh to behave that way
<mvo> is it because lxd maybe inactive at this point? because if so if we ensure that all refresh tasks wait for core things would be ok as well, no?
<pedronis> is not that simple
<zyga> mvo: the low level issue is that when snapd starts and constructs the repo we don't know that we need to add some revision of lxd (inactive) to the repo
<dpb1> zyga: have we considred a rollback of the core snap?  it's broken all initial installs.
<mvo> zyga: so that is because the lxd refresh is half-done at this point, right?
<zyga> dpb1: can you provide more data please?
<zyga> mvo: yes
<zyga> dpb1: to answer your question, we considered rollback of core and try not to break it
<zyga> dpb1: how is it breaking initial installs?
<pedronis> IÂ think is saying because of bug #1
<mup> Bug #1: Microsoft has a majority market share <canonical> <iso-testing> <microsoft> <package-qa-testing> <Clubdistro:Confirmed> <Computer Science Ubuntu:Confirmed for compscibuntu-bugs> <LibreOffice:New> <dylan.NET.Reflection:Invalid> <dylan.NET:Invalid> <EasyPeasy Overview:Confirmed for ramvi>
<mup> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <LibreOffice:In Progress by bjoern-michaelsen> <Linux:New> <Linux Mint:Fix Released> <The Linux OS Project:In Progress> <Neobot:New> <Novabot:New> <OpenOffice:In Progress by lh-maviya> <ReactOS Core Operating System:Incomplete> <Tabuntu:Invalid by
<mup> tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:Invalid> <Ubuntu Malaysia LoCo Team:In Progress by apogee> <Wine:Confirmed> <Ubuntu:Fix Released> <Arch Linux:New>
<mup> <Baltix:Confirmed> <Debian:In Progress> <Fedora:Confirmed> <Fluxbuntu:Confirmed> <openSUSE:In Progress> <Tilix:New> <https://launchpad.net/bugs/1>
<pedronis> we should  rollback core
<pedronis> to 31.x
<pedronis> because all people trying snaps right now will it
<pedronis> hit it
<zyga> dpb1: ah
<zyga> dpb1: I understand your point now
<zyga> dpb1: yes, I think that's a viable solution
<zyga> mvo: ^
<zyga> jdstrand: ^
<mvo> cachio: can you test that a revert of core from 2.32.1 -> 2.31.2 works ok? and if so I think we need to move stable for core back to 2.31.2
<zyga> JamieBennett: ^
<mvo> zyga: ack, I think we need testing but once that is confirmed +1
<zyga> mvo: yes
<zyga> that's a very good outcome for 20:53
<mvo> zyga: also we need to ensure the store is prepared for this (same heads up as with a regular new stable)
<zyga> and we need .3 with a few more fixes
<mvo> zyga: indeed
<zyga> or even 2.31.x with some helper fix
<zyga> if needed
<zyga> and we could do a post mortem to learn from this
<JamieBennett> zyga: mvo: as long as we are sure the rollback is safe and will indeed fix the issue, I'm +1 although I believe we have a fix for #1 very close?
<cwayne> mvo: zyga: reverting core? Did we miss something?
<zyga> JamieBennett: FYI: issues numbered: https://forum.snapcraft.io/t/summary-of-core-lxd-refresh-bugs-discovered-today/4869
<zyga> cwayne: ^
<JamieBennett> zyga: yes, saw that, thanks
<mvo> JamieBennett: two out of three are almost done
<jdstrand> zyga: you asked my opinion. I'm not sure if it was meant for me. if it was, what do you want my opinion on?
<JamieBennett> mvo: so is it safer to rollback or push the fix?
<zyga> JamieBennett: we don't have a fix yet
<mvo> JamieBennett: I would (naturally) prefer the fix, but we have one open issue left and we don't know how widespread that is
<zyga> jdstrand: just FYI
<pedronis> mvo: zyga: the issue of waiting for core, is also  that is can happen in the other direction to,   snap  refresh lxd,  snap refresh core, it's unlikely but we would need to wait to deactivate core until there is no interesting pending task
 * jdstrand nods
<zyga> pedronis: yes, that's a good point
<zyga> pedronis: I would prefer a fix that tracks state correctly
<zyga> it feels conceptually easier to explain
<zyga> than the waiting workaround
<pedronis> basically it's doable but it escalates quickly a bit into a tangle of cross checks
<zyga> and also more correct technially
<zyga> yes
<zyga> I will look at tracking this in the state, I can iterate locally without pushing anything
<zyga> but I probably will bail soon, I need to think and rest
<mvo> zyga, pedronis can we have a quick HO to sync up on possible fixes? or is it too late?
<zyga> (no need to rebuild core to test)
<zyga> mvo: sure
<zyga> in 2 min in standup
<dpb1> stgraber: ^
<dpb1> stgraber: would be good to test out side on that too
<pedronis> mvo: yes
<dpb1> stgraber: *our side
<stgraber> dpb1: not sure how to test that, there's no flag to "snap install lxd" that I can pass to tell it to install a particular version of the core snap
<zyga> wtf https://www.irccloud.com/pastebin/BIrJMfkH/
<stgraber> zyga: ah yeah, we've seen that occasionally before, it's a weird one
<zyga> stgraber: we understand it now
<zyga> cachio: ping
<stgraber> zyga: oh, that explenation makes sense, I always thought it was our weird mntns setup that was causing that, but the socket not being reachable because of the restart makes sense
<ackk> stgraber, you can snap install core manually though
<jdstrand> stgraber: you may have noticed me talking about lxd yesterday. that is one of the 3 issues being discussed above
<stgraber> ackk: not for this bug, no
<stgraber> ackk: this bug specifically happens when the core snap is auto-installed when you install your first snap
<stgraber> ackk: installing core seperately avoids the issue :)
<ackk> oh :)
<stgraber> jdstrand: ah, glad that the different issues have been tracked down and untangled now :)
<jdstrand> stgraber: yes. 'lucky' you it is all happening with the lxd snap. the fixes will make things more robust for everyone :)
<stgraber> yeah, "lucky"... timing is kinda crap though as we're doing the social media round for LXD 3.0 tomorrow :)
<stgraber> for now I updated our install instructions in that post to "snap install core && snap install lxd" with a link to the snapd issue on the forum, that should save us from most bug reports :)
<jdstrand> nice
<cachio> zyga,  hey
<pstolowski> mvo: #4981 merged
<mup> PR #4981: ifacestate: inject autoconnect <Critical> <Squash-merge> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4981>
<mup> PR snapd#4981 closed: ifacestate: inject autoconnect <Critical> <Squash-merge> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4981>
<mup> PR snapcraft#2046 closed: lxd: specify arch in lxc image list command <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2046>
<mvo> pstolowski|afk: thanks!
<mup> PR snapd#4984 opened: ifacestate: inject autoconnect (#4981) <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4984>
<zyga> JamieBennett: I updated the thread with more details and links to PR that fix the issue
<zyga> cachio: did you see the question from mvo
<zyga> cachio: we need to test a rollback of core to 2.31.x
<zyga> JamieBennett: I don't think we have a rollback decision yet but it is a tempting choice, mvo will discuss with you when he's back
<cachio> zyga, sure, I'll do it now
<zyga> JamieBennett: and regardless of the rollback we will do 2.32.4 with fixes for all three issues 2 and 3
<zyga> and maybe for issue 1
<cachio> zyga, any version in specific?
<zyga> cachio: latest 2.31.x so I think 2.31.2
<JamieBennett> As above, Iâm +1 if we are confident that it will not cause issues
<zyga> JamieBennett: we discussed how to solve issue 2 just now and I'm working on it
<zyga> JamieBennett: right, mvo said we would only rollback afte cachio gives +1 from test POV
<mvo> cachio: 4205-4210 is the previous 2.31.2
 * JamieBennett nods
<zyga> JamieBennett: issue .1 is still a bit more complex but we have some ideas
<zyga> hey mvo
<mvo> zyga: hey
<cachio> mvo, from master, right?
<mvo> cachio: from current stable 4325..30 to 4205..10
<mvo> cachio: i.e. 2.32.1 back to 2.31.2
<cachio> mvo, ok
<mvo> zyga: the fix for "when old snapd starts the process (think: deb) and new one finishes the auto-connect task is missing" has landed in master now, I created a backport and create a new edge core with the fix so that this can be tested for real
<zyga> mvo: thank you
<pedronis> mvo: IÂ think we understood the  snapctl socket issue
<pedronis> it's related to the shudown logic on restart
<pedronis> IÂ don't know if there are other failure modes for running hooks while snapd is inactive though
<pedronis> zyga: mvo: afaict  snap-confine dies if base current is not set?
<zyga> pedronis: yes but it only does so if it needs to construct a new namespace
<zyga> pedronis: if the snap is around (like lxd would) it has a namespace to enter
<pedronis> ok, so there's an issue, but again infrequent (possibly)
<zyga> looking at the trace I attached it has one
<zyga> DEBUG: sending information about the state of the mount namespace (keep)
<zyga> this is critical
<zyga> it says that the namespace is in sync with what base snap we expect to use
<zyga> so we reuse it
<pedronis> well that code does:
<pedronis>         // Read the revision of the base snap by looking at the current symlink.
<pedronis>         sc_must_snprintf(fname, sizeof fname, "%s/%s/current",
<pedronis>                          SNAP_MOUNT_DIR, base_snap_name);
<pedronis>         if (readlink(fname, base_snap_rev, sizeof base_snap_rev) < 0) {
<pedronis> so IÂ suppose it would die if current is not htere
<zyga> yes, that's true
<zyga> if current is not there we die earlier
<zyga> because /dev and what not won't be there
<zyga> just unmount current and see
<pedronis> so we have a general problem about upgrading bases and their snaps at the same time
<pedronis> so this one would need conflicts and wait to be solved
<cachio> mvo, I ran it manually nad I did not see any issue, should I test it in any specific arch or system
<cachio> ?
<pedronis> mvo: zyga:Â I added a not about base current vs snap ops in that forum topic, it probably merits its own at some point but at least it will not get lost
<zyga> thanks
<cachio> mvo, https://paste.ubuntu.com/p/5DWzM6Dytf/
<cachio> 2.32.1 -> 2.32.2 -> 2.32.1 worked fine here
<mvo> cachio: great, do you think you could verify on a core device as well? might be tricky to get 2.31.2 there but you can publish the core snap so "snap refresh --revision=4205 core" should work
<cachio> mvo, sure, let me try it
<mvo> cachio: --revision=4206 if you are on amd64 - 4209 for pi2 :)
<cachio> ok, let me flash the image and I0'll try it
<zyga> pedronis: still there?
<zyga> I wonder if it is right still (security revision)
<zyga> writing the commit message for a WIP patch
<zyga> when we refresh r1 is setup
<zyga> but we want r2
<zyga> and r2 is not active yet
<zyga> we don't remove security of r1, just setup for r2
<zyga> so we want to store r2
<zyga> and reload r2
 * zyga actually thinks it is fine again
<zyga> just tired
<zyga> thank you f:)
<zyga> for listening
<pedronis> zyga: we need to store the revision of the thing we AddSnap
<zyga> pedronis: quick WIP patch https://github.com/zyga/snapd/commit/a98a927d1ae472f849ed47f6ad396cdf7d98c636
<zyga> untested
<zyga> I didn't move any code around to minimize the diff as it will have to use some private functions that need to become public first
<pedronis> zyga: we have an issue
<pedronis> zyga: when we install IÂ don't think SnapState exists in snaps until we do link
<zyga> hmm hmm
<pedronis> and storing it without all the info breaks invariants
<pedronis> zyga: I fear,  we need a separate security-profiles-revision map
<zyga> hmm hmm
<zyga> we setup profiles before we link
<pedronis> yea, that's the issue
<zyga> we have Candidate
<zyga> can we use that?
<pedronis> ?
<pedronis> that is on the task
<pedronis> no
<zyga> ah
<zyga> hmm
<zyga> but don't we have a deeper issue the
<zyga> setupAffectedSnaps has code like
<zyga> snapstet.Get9st, affectedSnapName, ...)
<pedronis> we don't connect to things that are not installed
<zyga> if I install a pair of snaps
<zyga> would they auto-connect to each other?
<zyga> or only after installation?
<zyga> *after linking
<pedronis> only after installation
<zyga> ok
<zyga> yeah, I see your point
<pedronis> unless they are default-providers
<zyga> oh
<pedronis> in which case we wait for some things
<zyga> we install the provider first?
<zyga> (fully)
<pedronis> not fully
<pedronis> but we don't do autoconnect
<zyga> but link it?
<zyga> aha
<zyga> well
<zyga> I see the problem
<mup> Issue snapcraft#1672 closed: Add pre-pull/pull/post-pull <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1672>
<mup> PR snapcraft#2045 closed: many: add override-pull scriptlet <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2045>
<zyga> thank you for the quick insight
<pedronis> until they have done setup-prfoiles
<pedronis> anyway, as I said, I think we need a separate map
<pedronis> it's really an issue of snapstate has some state,  and ifacestate needs some different state
<zyga> note that the error from that get is non-fatal
<zyga> as we had "mysterious issues'
<zyga> so maybe another layer of mud needs digging
<pedronis> but I see we find   autoconnect candidates based on the repo
<pedronis> so there might be stuff there
<pedronis> that doesn't exist in snaps yet
<zyga> but then we go and setup security and that may bite us
<zyga> since we get the snaps from the state
<zyga> because we had that bug and gustavo wanted us to always look at the state
<zyga> maybe that was not right
<zyga> and maybe refreshing the repo explicitly like we do is enough
<zyga> but all questions need thinking now
<pedronis> well there's a disagreement between snapstate and ifacestate/repo
<pedronis> about wha's active
<zyga> active is misleading
<zyga> but yes
<zyga> there's disagreement
<pedronis> some of it is just the nature
<pedronis> of splitting tasks between the two
<pedronis> some of it could be reconciled
<pedronis> zyga: anyway that Get skips if there's an error
<zyga> yes
<pedronis> so whatever the issue is not explosive
<zyga> but not sure if it should, I don't know when that may legally happen
<pedronis> and has been there since long
<zyga> yes, we made it non-explosive
<pedronis> zyga: IÂ don't think we can tackle that one now
<zyga> testing my WIP patch
<zyga> I security-revision is stored, now running the script
<zyga> it didn't work
<zyga> somewhere when we remove profiles
<zyga> we reset the revision
<zyga> and then restart must happen after that time
<zyga> kwi 04 22:38:00 t470 snapd[3451]: 2018/04/04 22:38:00.605460 snapstate.go:1714: DEBUG: skipping inactive snap lxd with snap state &snapstate.SnapState{SnapType:"app", Sequence:[]*snap.SideInfo{(*snap.SideInfo)(0xc4200b5100), (*snap.SideInfo)(0xc4200b5180), (*snap.SideInfo)(0xc4200b5200)}, Active:false, Current:snap.Revision{N:6492}, SecurityProfilesRevision:snap.Revision{N:0}, Channel:"edge", Flags:snapstate.Flags{DevMode:false,
<zyga> JailMode:false, Classic:false, TryMode:false, Revert:false, RemoveSnapPath:false, IgnoreValidation:false, Required:false, SkipConfigure:false, Unaliased:false, Amend:false}, Aliases:map[string]*snapstate.AliasTarget{"lxc":(*snapstate.AliasTarget)(0xc4204f5120)}, AutoAliasesDisabled:false, AliasesPending:true, UserID:0}
<zyga> SecurityProfilesRevision is zero
<pedronis> but then we will do setup-profiles
<pedronis> is setup-profiles not doing enough?
<zyga> not sure I understand
<pedronis> the theory was that we did setup-profiles but not link-snap
<pedronis> but here we didn't do setup-profiles
<pedronis> otherwise profile revision would be set
<zyga> we did, I refreshed lxd manually a few times and used jq to read the profile revision from the state
<zyga> I probably don't understand the refresh logic well enough
<zyga> and when we unlink the old snap we remove its profiles
<zyga> and that resets the revision
<zyga> and then if we restart we are in a bad state
<zyga> (maybe)
<zyga> that's just me guessing now
<pedronis> but that's always been like that
<pedronis> also afair we don't do that
<zyga> this is interesting
<zyga> https://www.irccloud.com/pastebin/t1zwTx1t/
<zyga> we setup profiles for lxd
<zyga> (probably don't finish)
<zyga> then core restarts
<pedronis> only  Remove  and Disable remove-profiles
<zyga> so we never set it
<zyga> ah, maybe my patch is wrong then
<zyga> I patched it so that doRemoveProfiles resets the revision to zero
<zyga> maybe it's called in other places
 * zyga looks
<zyga> actually, removeSnapSecurity
<zyga> which is only called from removeProfilesForSnap
<pedronis> you should do things close to where
<pedronis> we do AddSnap
<pedronis> and RemoveSnap from repo
<zyga> yeah
<zyga> tweaking
<pedronis> not that I see other places calling removeSnapSecurity
<zyga> quick diff
<zyga> https://github.com/snapcore/snapd/compare/master...zyga:fix/reload-repo-inactive-snaps?expand=1
<zyga> ah
<zyga> wrong, didn't push
<zyga> now it's correct
<zyga> well, up-to-date
<cachio> mvo, same in pi2
<cachio> it works fine
<Caelum> zyga: fantastic, so now we can say we have a fully working snapd for opensuse :D
<pedronis> zyga: it looks reasonable,  are we missing something obvious?
<zyga> Caelum: we need to add snapd to factory and package gnome-software extensions
<zyga> pedronis: testing it now
<pedronis> (apart that we cannot use SnapState but that's for install)
<zyga> yes
<zyga> fingers crossed
<Caelum> zyga: of course there is always more stuff to do
<zyga> hmm hmm hmm
<zyga> pedronis: it still didn't store the rev
<zyga> on refresh it gets reset to zero
<Caelum> zyga: the web page didn't get rebuilt yet btw, but I guess that happens in some cron job
<zyga> maybe the Get's I added just fail
<zyga> Caelum: if it's not refreshed tomorrow I will poke people for a rebuild
<Caelum> great
<Caelum> should I start playing with 42.1 in my branch to get ready for 42.2 ?
<pedronis> zyga: you should probably log from the places you are setting/resetting it
<zyga> yes, patching now
<Caelum> I mean 32.1
<Caelum> and you already released 32.2, that's the one you wanted to update to?
<zyga> Caelum: 32 is a troubled child :)
<cachio> mvo https://paste.ubuntu.com/p/fqBtRBsX33/
<zyga> Caelum: we have some issues to work through
<zyga> I think 2.32.4 will be good
<zyga> pedronis: nope
<zyga> whatever is happening I'm losing the securityt profiles revision
<zyga> I added logging
<zyga> is the state overwritten ever without loading?
<pedronis> we are setting it?
<zyga> ye
<zyga> yes, it's set
<pedronis> and not resetting it?
<zyga> also seen in jq
<zyga> we are not unsetting it
<zyga> unless I made a silly bug in the code
<mvo> cachio: looks like no issues there
<zyga> I get the state from the task
<zyga> then get, update and set the snap state
<pedronis> seen in jq?
<mup> PR snapd#4984 closed: ifacestate: inject autoconnect (#4981) <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4984>
<pedronis> seen in jq set?
<zyga> yes, I see both the revision (before running bug.sh) and unset in jq
<zyga> yes
<zyga> I snap refresh --edge lxd; then same to --stalbe
<zyga> stable
<zyga> and that sets it
<zyga> (using my hacked edge core)
<zyga> then refresh core, lxd to stable and back to edge
<zyga> and it is gone
<pedronis> well, stable will write is stuff
<pedronis> and lose that no?
<zyga> overwrite !
<zyga> oh
<zyga> drat
<zyga> so yeah
<zyga> we need a new map
<pedronis> ?
<zyga> but this is also scary
<pedronis> we cannot fix the bug in stable
<zyga> yes yes, my point is that old snapd overwrites and discards this data
<zyga> and it's not great
<pedronis> we need a map
<pedronis> anyway
<zyga> it's one to have a field and not use it
<pedronis> but in general we cannot fix the bug for stable
<zyga> and another to overwrite and remove a field
<zyga> sure, I just didn't expect stable to erase this
<zyga> but yeah
<zyga> ok
<zyga> I think I need to EOD now
<pedronis> stable will still not do the right thing
<zyga> too tired and too much hectic stuff at home
<zyga> I will use a new map tomorrow and test this
<zyga> if this is fine I will write proper tests for everything
<zyga> how shall we call it?
<zyga> repostate?
<pedronis> the question whether, we will need more bits?
<pedronis> IÂ mean should be start from day 0
<zyga> 8ball
<pedronis> with    name -> struct
<pedronis> or only name -> revision
<zyga> I'd go struct
<zyga> but with the problem of destructive updates
<zyga> it's probably irrelevant
<zyga> but I'd go with struct anyway
<zyga> easier to code and nicer
<zyga> repostate[snapName].Revision
<pedronis> security-profiles-state ?
<zyga> ifacestate? to tie this into the interface manager (iface-state)
<zyga> not sure
<zyga> we can rename it tomorrow :)
<zyga> mvo: I'm EODing
<zyga> let's regroup tomorrow
<zyga> thank you for the insight tonight pedronis, it was invaluable
<mvo> zyga: yeah
<mvo> zyga: I think we need the revert
<zyga> yes
<zyga> let's revert, my +1 goes there
<mvo> cachio: can you please run some more tests, ideally a "snap refresh --revision=4206 core" and some spread testing with such a setup? I think we need to revert tomorrow
<zyga> not sure if you want to do it tonight
<zyga> if we need to ack from store
<mvo> zyga, pstolowski|afk unless I did something wrong in my tests the inject-task is not fully working: https://paste.ubuntu.com/p/BxmxD3VFCD/
<mvo> zyga, pstolowski|afk "2018-04-04T23:11:59+02:00 INFO cannot auto-connect plug lxd:lxd-support to core:lxd-support: no state entry for key"
<mvo> zyga, pstolowski|afk lets talk more tomorrow
<zyga> no state entry for key :/
<zyga> ErrNoState
<zyga> sucks to be us today
<zyga> ttyl
<pedronis> mvo:Â I think it's probably inserted in the wrong place :/
<pedronis> mvo: pstolowski|afk:  yes,  for a snap that is not core, it needs to come after link-snap
<pedronis> not after setup-profiles
<pedronis> see doInstall code
<pstolowski|afk> oh my
<pstolowski|afk> mvo thanks for the test... it's a shame a spread test wasnt possible
<geekgonecrazy> Hey guys.. does anyone know if the nodejs part has been updated recently?
<geekgonecrazy> I've used the nodejs part for a while, and suddenly its started giving me this error:
<geekgonecrazy> Failed to run 'npm ls --global --json' for 'node': Exited with code 1. Verify that the part is using the correct parameters and try again.
<geekgonecrazy> even for builds that previously succeeded on launchpad
<kyrofa> geekgonecrazy, do you specify a node version?
<geekgonecrazy> kyrofa: yup, otherwise mass chaos in Rocket.Chat :D
<geekgonecrazy> unfortunately very tied to node.js versions at times
<geekgonecrazy> trying to locate the `npm ls --global --json` because I can't recall that ever being run when I do `npm install` locally
<geekgonecrazy> So my assumption was it was in the nodejs part somewhere maybe?
<kyrofa> geekgonecrazy, when was your most recent successful build?
<geekgonecrazy> last night.  Looking at the wiki page for the parts best I can tell last time it was updated was the 1st
<vidal72[m]> zyga: to disable abstract socket add "-nolisten local" to X server arguments. Most display managers already add "-nolisten tcp"
<zyga> thanks
<kyrofa> Huh, so it doesn't involve the snapcraft update from last week
<kyrofa> I'm not familiar with the nodejs part
<kyrofa> That could be it
<kyrofa> Maybe reach out to the maintainer?
<diddledan> well this is intriguing. I appear to have managed to get snapcraft into an infinite loop somewhere at "preparing to build desktop-gtk2" - it's sat there using 100% of a cpu core
<geekgonecrazy> kyrofa: any way via snapcraft command to see maintainer?  I might just manually install node.js as a less ideal workaround.
<kyrofa> geekgonecrazy, wait... I don't see a nodejs part :P
<kyrofa> diddledan, go away, my day was good
<diddledan> :-p
 * diddledan cuddles kyrofa 
<geekgonecrazy> kyrofa: I didn't see one via that page, but i'm some how using one :D
<kyrofa> geekgonecrazy, let me take a look at your yaml
<geekgonecrazy> kyrofa: don't judge too much :D https://github.com/RocketChat/Rocket.Chat/blob/develop/.snapcraft/snapcraft.yaml
<geekgonecrazy> oh duh.. plugin not part
<diddledan> oh ello. it finished
<diddledan> wasn't an infinite loop then, just a veeeery slow install
<diddledan> maybe it's my ISP - they've been battling a DDoS the past few days
<popey> ah yeah, desktop helpers can be a bit slow
<diddledan> this is on the building of the snap, rather than initial launch, popey , so I'm assuming my net connection was taking forever for snapcraft to fetch the needed bits to work out how to build
<popey> yes
<popey> building can be slow too
<diddledan> aah
<diddledan> ok
 * zyga will start later tomorrow
<zyga> I cannot even sleep now with all the snapd state in my head
<diddledan> you should share states with someone else ;-p
<diddledan> shared state is so much more reliable, right? :-D
<geekgonecrazy> kyrofa: btw its non-working with node-engine: 8.9.4 (which used to work) It might be something on our side.. Maybe I need to force a newer version of npm to be installed with that older version of node
<Chipaca> zyga: hey
<geekgonecrazy> kyrofa: looks like its: https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/nodejs.py#L250 that for some reason with node.js 8.9.4 isn't working.  Not sure why now.  Is there any way to use the nodejs plugin and keep it from doing the npm install? :D
<diddledan> omg!!!!!!! irccloud 0.6.0 lets you connect to slack channels!!! p.s. irccloud 0.6.0 works in a snap
 * diddledan pokenprod popey 
<diddledan> PR incoming!
<nacc> diddledan: iirc, slack is discontinuing the irc gateway
<nacc> pretty soon, at that
<popey> diddledan: srsly?
<popey> no more chmod nonsense?
<diddledan> nope, the new core fixes it by making it an EPERM rather than SIGKILL
<popey> Oh yes, time for a daily hug for jdstrand
<jdstrand> \o/
 * jdstrand hugs popey 
<diddledan> nacc: it works with a connector installed in slack. i.e. it does not use the IRC gateway
<popey> wow funky
<nacc> diddledan: oh interesting!
<diddledan> you need an admin of each slack workspace to enable the plugin tho
<nacc> diddledan: ah
<popey> looking forward to the pr :)
<kyrofa> geekgonecrazy, sorry, phone call
<kyrofa> geekgonecrazy, yeah, that hasn't changed for quite some time
<diddledan> well fooey.. my irccloud desktop repo isn't linked
<diddledan> popey: https://github.com/snapcrafters/irccloud-desktop/pull/6
<mup> PR snapcrafters/irccloud-desktop#6: update to irccloud 0.6.0 <Created by diddledan> <https://github.com/snapcrafters/irccloud-desktop/pull/6>
<diddledan> aah. the icon doesn't appear
<mup> PR snapcraft#2049 opened: many: add override-stage scriptlet <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2049>
<geekgonecrazy> kyrofa: thanks for taking a look.  Went ahead and just did the whole manual node.js install.  For what ever reason that step where it does npm ls --global --json in combination with one of our npm dependencies... just blows up
#snappy 2018-04-05
<mup> Bug #1761363 opened: Add interface to access to Zeitgeist <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1761363>
<mborzecki> morning
<mup> PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#22 closed: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<mup> PR core-build#26 closed: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
<mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#22 opened: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<mup> PR core-build#26 opened: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
<mup> PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#22 closed: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<mup> PR core-build#26 closed: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
<mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#22 opened: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<mup> PR core-build#26 opened: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
<mvo> good morning
<mborzecki> mvo: morning
<mvo> mborzecki: hey! how are you? anything interessting happend in the early morning?
<mborzecki> mvo: nope, casually browsing through reviews
<mborzecki> mvo: any leads on the mounting thing from yesterday?
<mvo> mborzecki: yes, the reason was eventually figured out by zyga and pedronis. there is some connection related state we only keep in memory and when snapd restarts this state is lost so we need to store more in the state
<mborzecki> nice
<zyga> Hey ho
<mvo> mborzecki: there are some complications apparently, I did not follow all the details
<zyga> Sorry for being late. I had to sleep longer
<mborzecki> zyga: hey
<mvo> mborzecki: I think we need to revert, cachio did a great deal of testing and we think its safe
<zyga> Well. Had to sleep
<mvo> zyga: no worries, same here
<zyga> Coffee, walk the dog, then coding
<zyga> We need new top-level structure in the state to fix the issue
<zyga> I can explain why when I am at my desk
<mup> PR snapd#4971 closed: errtracker: add more fields to aid debugging <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4971>
<mup> PR snapd#4985 opened: errtracker: add more fields to aid debugging <Created by mvo5> <https://github.com/snapcore/snapd/pull/4985>
<pedronis`> hi
<pstolowski> mornings
<pedronis> mvo: hi, don't know if you saw the logs but we have both a very specific issue with the snapctl socket, but also likely a general issue with all operations on a snap at the same time we operate on its base (if the op involves running things like hooks or starting services)
<kalikiana> buenos dias
<mborzecki> 2018-04-05 09:09:46 Preparing google:arch-64 (google:arch-64 (apr050907-716531))... yay!
<zyga> Hey Pedronis, good morning
<pstolowski> morning zyga
<mvo> pedronis: aha, no, I did miss this part of the conversation
<mvo> good morning pstolowski, did you see my test run from last night?
<pstolowski> mvo: yes, thank you
<pedronis> pstolowski: afaiu is because of the placement , being after setup-profiles is too early for those tasks
<mvo> pstolowski: I have the system still in this state, I can do another run to see if it consistent, but I wanted to keep it for now in case there is anything that might help understanding it
<pedronis> pstolowski: doInstall puts them after link-snap
<pstolowski> pedronis: mvo yep, i saw your comments on irc yesterday, investigating this
<pstolowski> pedronis, mvo is it possible to install lxd as the first snap and force core from edge?
<pedronis> pstolowski: not with the stable deb, not really, you could use the enterprise proxy locally, except that the stable deb doesn't support it
<pedronis> pstolowski: mvo: as I said, maybe we should add a envvar to control  the channel from which we get core (or any base), but that will only help this sort of testing going forward
<pedronis> mvo: should we do a HO in a bit to see where we are, we need a bit to decide which bugs needs fixing for 2.32.x and which can wait
<mvo> pedronis: sounds good
<mvo> pedronis: we need to wait for zyga too
<pstolowski> mvo: how exactly did you provoke the errnostate?
<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>
<pstolowski> HO sounds good
<zyga> and back now
<zyga> I can have a call
<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>
<mvo> pstolowski: so it seems the fix for the inject task is to put the auto-connect a bit later (after link-snap) - thats my naive view at least - or do you think there is more too it?
<pstolowski> mvo: just trying to trigger the problem with edge from core atm but unclear how
<mvo> pstolowski: what I did yesterday is essentially: 1. git checkout upstream/release/2.29 2. modify it so that defaultBaseSnapsChannel is "edge" 3. sudo systemctl stop snapd snapd.socket && go build && sudo ./snapd && sudo systemctl start snapd 4. snap install lxd
<mvo> pstolowski: with an empty state of course
<mvo> pstolowski: e.g. on 17.10 apt purge snapd first and then install it
 * zyga is in the standup HO
<mvo> pstolowski: https://paste.ubuntu.com/p/BxmxD3VFCD/ contians a rough outline of the above including the diff I used
<mvo> pstolowski: trouble is of course that you cannot test anything local wit hthat method, only testing after it landed in edge :(
<pstolowski> mvo: thanks (in HO too)
<Chipaca> moin moin
<mborzecki> sometimes i hate pacman -Syu vs -Sy when installing packages :/
<Chipaca> mborzecki: what's the difference?
<Chipaca> mvo: did you see the (fleeting) PR about dropping privileges, yesterday?
<mvo> Chipaca: I did but didn't look, sorry
<Chipaca> mvo: no worries, it didn't work :-)
<mvo> Chipaca: haha
<Chipaca> mvo: but, thing is, there's a bug that that pr was trying to fi
<Chipaca> fix*
<Chipaca> mvo: (FWIW the approach tehre would work from Go 1.10 on! so let's  go there someday)
<mborzecki> Chipaca: `-Syu foo` does a full system ugprade and installs foo, just doing `-Sy foo` will install foo but if its dependencies are already installed they will not get updated, which in turn may or may not hurt you badly
<Chipaca> mvo: https://bugs.launchpad.net/snapd/+bug/1761193
<mup> Bug #1761193: ~/.snap/ not available for root on some systems <snapd:New> <https://launchpad.net/bugs/1761193>
<mborzecki> still don't get why it's so hard to record versioned library dependencies
<Chipaca> mvo: so... I could change the code to use 'su' to touch that file, but it feels icky
<mvo> Chipaca: in a meeting right now, let me get back in a bit
<Chipaca> mvo: yeah no worries, i'll brain dump and you read and respond when you're able
<mvo> +1
<Chipaca> mvo: the ops we need to do on the file are read, write, and remove. 'su'ing to cat and rm works. The other approach is to use cgo, and do the setuid/setgid in a C thread we manage ourselves. I have tested neither of these approaches, and both seem rather unpalatable, so I think I'd go with the less sophisticated one =)
<Chipaca> mvo: <end dump> i think :-)
<Chipaca> or we could move to go 1.10 \o/
<Chipaca> mborzecki: that manpage looks terrifying =)
<mborzecki> Chipaca: pacman?
<Chipaca> yeah
<zyga> that was a nice case of internet counselling session
<Chipaca> zyga: ?
<Chipaca> zyga: BTW thank you once again for having your lab machines; last night I was able to help a customer thanks to that
<zyga> Chipaca: woot!
<zyga> Chipaca: that's awesome, let me know if I can expand it to be more useful in some way
<zyga> Chipaca: ask mvo about how we're doing :)
<Chipaca> zyga: oh, your counselling session was the same as mvo's meeting?
<zyga> yes :D
<mvo> Chipaca: reading now, thanks for tackling this issue!
<mvo> Chipaca: +1 for su - even though it feels fugly
<Chipaca> mvo: ok
<mvo> Chipaca: what exactly do we need to do to that file? we need to append (and create if needed) and remove?
<Chipaca> mvo: and read
<Chipaca> mvo: not append, i think -- just create, read and remove
<mvo> Chipaca: ok
<Chipaca> mvo: another approach would be to not report the error to the user, ie any error on reading the file gets ignored
<Chipaca> mvo: but that will make it hard to debug
<Chipaca> I'll take a stab at using su, let's see how it goes :-)
<mvo> Chipaca: thank you
<mvo> Chipaca: we could also have helper that does the things we need doing and we just spawn that with su. but yeah, I'm sure it is interessting
<Chipaca> mvo: that actually better than cat and rm, i'll do that
<Chipaca> mvo: (to be clear, it's better because the 'write' case is hard to do properly otherwise)
 * mvo nods
<jlorenzo> hi there!
<jlorenzo> I have a quick question about the snap store
<jlorenzo> is snapcraft 2.39.2 still supported by the store?
<jlorenzo> (I'm trying to push and release a snap with this version)
 * jlorenzo sees 2.40.x is still marked as pre-version https://github.com/snapcore/snapcraft/releases
<jlorenzo> is anybody aware of a server-side change that produces blank errors like this one https://tools.taskcluster.net/groups/GYT_nZNyQzGn7wjcwBTajw/tasks/fFIauoJaQQCFAYJVeQqheg/runs/0/logs/public%2Flogs%2Flive_backing.log#L892 ?
<zyga> kalikiana: ^
<popey> snap refresh foo --amend seems to have broken for me recently
<popey> I get error: cannot communicate with server: Post http://localhost/v2/snaps/mame: EOF
<popey> that kind of thing every time I try and refresh a local snap into the store
<popey> running snapd 2.32.2
<popey> pretty sure flexiondotorg also had the same issue
<flexiondotorg> Yes, I've seen that --amend isn't working yesterday.
<mvo> let me look
<mborzecki> am i missing something or is this check exactly the same as one below https://github.com/snapcore/snapd/blob/master/tests/main/manpages/task.yaml#L14 ?
<mvo> popey: I just tried with hte hello snap and snap refresh --amend worked for me, what snaps are you using?
<popey> I tried with a few, mame for example and signal-desktop, which I'd built locally then pushed to the store
<mup> PR snapd#4985 closed: errtracker: add more fields to aid debugging <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4985>
<mvo> popey: thanks, I will try harder then
<mvo> popey: aha! signal-desktop reproduces it
<popey> \o/
<mvo> popey: I think its because its not in stable, obviously a bug and I think I know what it is
<popey> ooh, interesting
<popey> (I did pass --beta) fwiw
<mvo> popey: yeah, this is not passed to the right place unfortunately
<mvo> popey: so two things to fix: not crash, pass channel
<popey> ok. thanks
<popey> shall i file a bug?
<kalikiana> jlorenzo: Hmmm haven't seen that before. Looking
<jlorenzo> kalikiana: thanks! Last time I saw the same error was when we were using snapcraft 2.25. Back then, Ken VanDine told me to upgrade to the latest version, which solved it
<mvo> popey: either way is fine, I have a fix locally, just need to write proper tests for it
<popey> https://bugs.launchpad.net/snapd/+bug/1761435
<mup> Bug #1761435: Can't refresh some local snaps to store snaps with --amend <snapd:New> <https://launchpad.net/bugs/1761435>
<popey> diddledan: I'm running irccloud-desktop from edge, yay! Thanks!
<popey> diddledan: I have fixed the icon (changed 512x512 to 256x256 should do it) and will check the next build when it comes out. If fixed we shoul push to stable, right?
<zyga> mvo: back to hacking hten
<mborzecki> got a weird problem with arch and spread tests that use dbus, when we install a snap eg test-snapd-network-status-provider, those will generate dbus policy files, then the test fails because the provider service is denied owning the name on the bus, the only way to fix it is to systemctl reload dbus.service
<mborzecki> now the questions are, why does it work elsewhere and should we reload the service automatically?
<mvo> mborzecki: hm, afaik the daemon does a inotify watch on the dirs where we drop files
<mvo> mborzecki: but maybe there is a config file in your case missing, let me double check
<mvo> mborzecki: what is the dir?
<mvo> mborzecki: no, there is no config file we use so it ought to work
<mborzecki> mvo: /etc/dbus-1/system.d
<mborzecki> mvo: weird, i see --enable-inotify passed explicitly to dbus configure
<mvo> mborzecki: this is on arch? or a more general problem? maybe its not monitoring that dir for some strange reason on arch
<mborzecki> mvo: it's on arch, there's a couple of tests failing because of this
<mborzecki> hmm similar issue reported for avahi https://bugs.archlinux.org/task/55738
<mup> PR snapd#4986 opened: snapstate: fix `snap refresh --amend` when the snap is not available in stable <Created by mvo5> <https://github.com/snapcore/snapd/pull/4986>
<pedronis> mvo: IÂ changed the code in this ^ one in my new api work
<mvo> pedronis: oh, cool, I can run my test on the new PR to see if it fully fixes it
<mvo> pedronis: or base a new fix on top of your new-api work
<mvo> pedronis: also - I need to finish that review :/ sorry for letting you wait for so long
<pedronis> mvo: I think it should be fixed, because there is not more snapNameToID
<mvo> pedronis: neato, I will run my updated test to double check. that test is useful in any case
<pedronis> mvo: in the new world amend is an install, not a refresh
<pedronis> talking to the store at least
<pedronis> pstolowski: how it's going?
<mvo> pedronis: thanks, test is running now, I will either debug or push a PR with the updated test (I think its good to excercise the != stable path)
<pstolowski> pedronis: almost there i think; i've added similiar inject code into doLinkSnap for snap!=core, restricted the one in doSetupProfiles to core snap-phase2 only. what's missing is restricting link-snap more
<pstolowski> adjusted the tests, all passing atm
<pedronis> thanks
<zyga> pedronis: I'm working on the state changes, I will have some skeleton to review soon
<mup> PR snapd#4987 opened:  tests: add test to ensure `snap refresh --amend` works with different channels <Created by mvo5> <https://github.com/snapcore/snapd/pull/4987>
<Chipaca> zyga: did you say yesterday that the userd unit test panics?
<zyga> yep
<Chipaca> zyga: did you resolve that?
<zyga> nope
<zyga> it's been that for months
<Chipaca> oh?
<Chipaca> it hasn't -- i've been running the full test suite and it passed
<zyga> https://www.irccloud.com/pastebin/qKbODxHV/
<zyga> no idea
<zyga> it happens for me for _some_ reason
<Chipaca> but maybe there's a missing dep that i had on my other machine that's missing here
<Chipaca> jamesh: you around?
<pedronis> mvo: so seems the new code deals better with --amend (it's more regular, not extra calls, so not unexpected)
<mborzecki> mvo: i think i know what's happening, there's no /etc/dbus-1/system.d on clean install because arch does not like empty dirs, so if dbus calls intify_add_watch(.., "/etc/dbus-1/system.d"..) it will fail and the error probably gets swallowed
<pedronis> mvo: but yes we need to decide what to do about 4900 and get it at least on master soon, if we need to prepare the cherry-pick for 2.32.4
<mborzecki> standup is at 3pm right?
<zyga> I think so
<pstolowski> mborzecki: yes
<mup> PR snapd#4988 opened: snapstate, ifacestate: inject auto-connect tasks try 2 <Created by stolowski> <https://github.com/snapcore/snapd/pull/4988>
<mborzecki> cachio: i'm close to having all of the tests passing on arch (all of those that can run ofc)
<pstolowski> pedronis, mvo https://github.com/snapcore/snapd/pull/4988
<mup> PR #4988: snapstate, ifacestate: inject auto-connect tasks try 2 <Created by stolowski> <https://github.com/snapcore/snapd/pull/4988>
<cachio> mborzecki, great news
<cachio> mborzecki, I am working on the script to update that image
<cachio> mborzecki, it should be ready today
<cachio> zyga, hey, should we unblock this one right? https://github.com/snapcore/snapd/pull/4832
<mup> PR #4832: tests: move fedora 27 to google backend <Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4832>
<zyga> cachio: please see comment from mborzecki there
<zyga> oh, not there perhaps
<zyga> we need 7 more days
<zyga> before the package propagates
<mborzecki> yup
<zyga> https://github.com/snapcore/snapd/pull/4980
<mup> PR #4980: Revert "spread.yaml: switch Fedora 27 tests to manual (#4962)" <Created by zyga> <https://github.com/snapcore/snapd/pull/4980>
<cachio> zyga, ah, ok
<zyga> so next week
<mborzecki> idk if voting speeds up the process
<zyga> I think so
<jlorenzo> kalikiana: do you want me to file a bug in https://bugs.launchpad.net/snapstore, in the meantime?
<kalikiana> jlorenzo: Yes, please. Sorry for my delayed response. I narrowed this down in the code but still need to confirm the actual cause.
<jlorenzo> np!
<pedronis> pstolowski: lgtm,   comment could say more about placement
<pedronis> left some notes
<pedronis> in the PR
<Chipaca> is the standup now, or later, today?
<pedronis> later
<Chipaca> ok :)
<mborzecki> off to pick up the kids from school, bb for standup
<jlorenzo> kalikiana: https://bugs.launchpad.net/snapstore/+bug/1761488
<mup> Bug #1761488: snapcraft 2.39.2 failed to release a snap: snapcraft.storeapi.errors.StoreReleaseError: <exception str() failed> <Snap Store:New> <https://launchpad.net/bugs/1761488>
<pstolowski> pedronis: thanks
 * zyga is super sleepy, needs coffee
<pedronis> zyga: btw I was thinking that the fix for the issue will have interactions with the double setup-profiles we do for core
<pedronis> zyga: we basically do  AddSnap twice for core  but it works because in the old world we restart in the middle
<zyga> mmm, but is that an issue, all we will record is the revision then
<pedronis> zyga: well you said we cannot do AddSnap twice
<pedronis> now we will do at restart and then again in the 2nd setup-profiles
<pedronis> which will fail?
<zyga> I don't think it will, setup profiles removes the snap and adds it again
<zyga> this essentially refreshes the state of the repo
<zyga> this is in helpers.go in ifacemgr
<zyga> one sec
<pedronis> ah, it does remove?
<zyga> yes
<pedronis> and that doesn't fail if the snap is not there?
<zyga> to have consistent view of that snap for setpu
<zyga> I don't know
<zyga> but I don't suppose so
<zyga> https://github.com/snapcore/snapd/blob/master/overlord/ifacestate/handlers.go#L175
<zyga> looking at remove snap now
<pedronis> remove never fails
<pedronis> that's good
<zyga> https://github.com/snapcore/snapd/blob/master/interfaces/repo.go
<zyga> it only fails if the thing is connected, which is shouldn't be
<zyga> so it's good
<zyga> we disconnect the snap as well
<zyga> https://github.com/snapcore/snapd/blob/master/overlord/ifacestate/handlers.go#L169
<zyga> just prior to calling remove snap
<zyga> I think we are good
 * zyga explores how the state access works and how the raw json messages behave
<pedronis> zyga:  mmh, maybe we don't new state
<zyga> ohhh?
<pedronis> zyga:  we always do setup-profiles -> link-snap  (this make sense because setup-profiles is the "activating" of the ifacestate world)
<zyga> pedronis: and?
<pedronis> zyga: so we are interested in all active snaps, and all snaps  with a pending (not ready) link-snap that is waiting on a done setup-profiles
<pedronis> the revision in the sna-setup of those tasks
<zyga> so we could look through the state and fish that
<pedronis> yes
<pedronis> it has it's pro and cons as usual
<zyga> but who would do this? the interface repo on startup
<zyga> or setup profiles?
<zyga> or snap manager
<zyga> feels cross-manager
 * zyga finds working with state to be hard
<zyga> the get/set marshal/unmarshal
<pedronis> just done as a replacement of ActiveInfos
<zyga> the raw messages
<pedronis> SnapsWithProfiles
<zyga> ah, that makes sense
<pedronis> it would break if we started putting stuff between setup-profiles and link-snap
<pedronis> but IÂ would question such a move
<zyga> I'll play with the state variant first
<zyga> but I think your solution is better for upgrades
<zyga> it would have 0 "borken" moments
 * kalikiana lunch
<zyga> *broken
<pedronis> yea, the state solution and revert worry me a bit
<pedronis> not because problems are likely but if they appear they will be very confusing
<zyga> yes, it feels like something that would warrant epoch
<zyga> and epochs and customers are another thing
<pedronis> when we are more tools and time we can explore the idea of a more generalized concept of readiness
<pedronis> and then we could use that instead of looking at changes
<pedronis> s/are more/have more/
<pedronis> but looking at changes seems attractive if a bit delicate, right now
<pedronis> zyga: I'm exploring a bit how that would look like
<jdstrand> popey: hey, do you know if the remmina developer hangs out here?
<jdstrand> popey: or where the remmina snap developer can be found?
<zyga> pedronis: standup?
<jdstrand> cjwatson: hi! curious when snapcraft 2.40 will be in LP builds (if it isn't already)?
<seb128> jdstrand, Trevinho submitted the snapcraft file upstream and seems to still care about it some maybe he can help you?
<mup> PR snapd#4989 opened: tests: add arch to CI <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4989>
<cjwatson> jdstrand: when it's in xenial-updates
<jdstrand> cjwatson: ok, it is in xenial-updates
<cjwatson> jdstrand: then builds will use it (unless oddly-configured)
<jdstrand> it seems remmina is not using LP
<mborzecki> cachio: 2018-04-05 14:32:39 Successful tasks: 225 ^^^
<jdstrand> I look forward to when we can see where a snap build comes from (and, if LP, the build log)
<popey> jdstrand: i do not off hand
<mup> Issue snapcraft#2031 closed: Inconsistent results when building, cleaning stage and rebuilding <bug> <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/2031>
<mup> PR snapcraft#2047 closed: pluginhandler: organize in build instead of stage <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2047>
<jdstrand> popey: I just filed an upstream bug
<popey> ok cool.
<popey> jdstrand: is there anything else needed on emoj - I am still getting rejection mails about the x11 desktop thing
<seb128> jdstrand, sorry, I dropped offline, I was saying that maybe Trevinh_o can help you
<Chipaca> zyga: found the cause of my userd panic and it was totally my code =)
<mvo> pstolowski: tests for 4988 failed again, this time because opensuse is out of diskspace. so feel free to push any further changes to this branch
<mborzecki> https://forum.snapcraft.io/t/cannot-create-directory-tmp-snap-rootfs-var-lib-snapd-lib-gl32-permission-denied/4868/4 has anyone seen it on their 16.04 systems?
<pstolowski> mvo: ok
<diddledan> popey, the irccloud icon is an electron icon, so I've forced it in PR https://github.com/snapcrafters/irccloud-desktop/pull/7
<mup> PR snapcrafters/irccloud-desktop#7: fix desktop icon <Created by diddledan> <https://github.com/snapcrafters/irccloud-desktop/pull/7>
<cjwatson> jdstrand: next launchpad-buildd and snapcraft releases combined should handle that
 * zyga enjoys self-made lunch
<cjwatson> jdstrand: actually not sure it even needs a new snapcraft release, just launchpad-buildd
<popey> diddledan: oh bum, sorry
<jdstrand> cjwatson: nice! :)
<diddledan> no probs :-)
<diddledan> I've just resolved the conflict so it's pushbutton mergable
 * popey pushes the button
<mup> PR snapd#4990 opened: many: implement a poor man's privileges drop, use for auth.json <Created by chipaca> <https://github.com/snapcore/snapd/pull/4990>
<diddledan> I originally fixed it the way you did, but that icon seems to be the electron stock icon rather than the irccloud icon, so I've bundled the proper icon now
<popey> you're right, i have the electron icon here now :)
<popey> if this works shall i push to stable?
<diddledan> defo!
<diddledan> OT: doom runs on everything these days: https://www.youtube.com/watch?v=VnmIXK3PYFw
<kyrofa> cprov... we need to talk about store errors
<kyrofa> We need some consistency
<cprov> kyrofa: sure, do you have an example ?
<kyrofa> cprov, sometimes we get an error_list, sometimes we get a message, and sometimes we get an error_message
<kyrofa> And the only time we know when is when someone reports a traceback :P
<kyrofa> Oh! And a release error gives us a detail, that's nice
<kyrofa> We need a more standard error response, ever API call seems to have its own way of doing things
<cprov> kyrofa: the new pattern is `error_list`, we should fix specific cases where it's not honoured
<kyrofa> cprov, and do the contents of error_list follow a standard pattern?
 * zyga wonders why all things evolve to resemble xml-rpc
<kyrofa> I've never seen a error_list with more than one item
<cprov> kyrofa: https://dashboard.snapcraft.io/docs/api/snap.html#errors
<kyrofa> cprov, ah, very good. And those codes won't change out from under us?
<kyrofa> cprov, haha, I see the "Important: Not all API endpoints are migrated yet to this new error format"
<cprov> kyrofa: yeah, most of the errors are single, but there are few with multiple item, push is an example I remember
<kyrofa> cprov, are you actively working to migrate all API endpoints to use that new error format?
<thresh> hey popey, how would I go about building in an lxd?
<cprov> kyrofa: the fact we didn't finished the migration is bad, I am more than happy to fix any remaining endpoints
<kyrofa> cprov, I guess what I'm asking is: do you know what the "remaining endpoints" are, or am I just going to hit them and need to report them?
<mup> PR snapd#4991 opened: ifacestate: add to the repo also snaps that are pending being activated but have a done setup-profiles <Created by pedronis> <https://github.com/snapcore/snapd/pull/4991>
<kyrofa> Because there's no way for us to know all the possible error responses coming from the store
<kyrofa> So that would be the status quo
<popey> thresh: hello!  do you have lxd installed?
<thresh> yep, creating a VM for that atm
<popey> thresh: "lxc launch ubuntu:16.04 vlctest" then "lxc shell vlctest" and you're in the container
<cprov> kyrofa: I don't know, but file a bug about what is what is blocking you and I will walk the whole API.
<thresh> popey, ah well, I was thinking there was some snapcraft command to do that for me etc :-)
<kyrofa> cprov, alright, I'll make a note to log a bug when we encounter API responses that don't follow that pattern, thank you
<cprov> kyrofa: thanks, do the same for any inconsistency to what is already documented
<pedronis> mvo: zyga: #4991, after thinking a bit this is good , but doesn't fix the same kind of problem on undo, for that we really need new state I fear, because the tasks are too ambiguous for that
<mup> PR #4991: ifacestate: add to the repo also snaps that are pending being activated but have a done setup-profiles <Created by pedronis> <https://github.com/snapcore/snapd/pull/4991>
<popey> thresh: ah, there is, for sure. But you'd end up with a clean 16.04 container, not including the neon bits
<kyrofa> cprov, another similar question. Let's say I'm releasing to a channel, but I don't have permission to do that
<kyrofa> cprov, I get an error_list containing {'code': 'macaroon-permission-required', 'message': 'Permission is required: channel'}
<kyrofa> But that doesn't actually give me enough info to give a helpful error message
<kyrofa> I have to reach outside of the error_list to the 'permission' attribute to see what the issue was, and there is also the 'channel' attribute
<kyrofa> But I never know when those will or will not be present
<kyrofa> So my error handling code turns into spaghetti
<kyrofa> You see what I mean?
<cprov> kyrofa: I do and we can work this out
<pstolowski> mvo: everything is terrible
<mup> PR snapd#4992 opened: tests/main/interfaces-opengl-nvidia: verify access to 32bit libraries <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4992>
<popey> diddledan: do you have any snaps in your dusty archive that are unblocked by 2.32? I had a few and I need to dust them off at the weekend.
<cprov> kyrofa:  the premise of using error-codes is that they should have specific handlers
<diddledan> I need to check wine
<pstolowski> https://github.com/snapcore/snapd/pull/4988 failed again because of opensuse and because of 502 when fetching "golang.org/x/net/context"
<mup> PR #4988: snapstate, ifacestate: inject auto-connect tasks try 2 <Created by stolowski> <https://github.com/snapcore/snapd/pull/4988>
<kyrofa> cprov, so if I get a 'macaroon-permission-required' I can assume that the 'permission' and 'channel' properties are present?
<kyrofa> Because that error code sounds kinda generic
<cprov> kyrofa: yes
<diddledan> this is my current checked-out or in-progress snaps: https://usercontent.irccloud-cdn.com/file/0ensUQkd/image.png
<popey> haha
<kyrofa> cprov, okay, I can work with that
<popey> ooh, you have snapcraft, that looks cool ;)
<diddledan> :-p
<popey> diddledan: revision 41 of irccloud still has broken icon. do i need to wait for the next build?
<diddledan> o_O
 * diddledan checks
<thresh> man I shouldve launched that VM on a ssd
<diddledan> revision 41 was the one built in response to the PR I think. perhaps it's still broke?
<zyga> jdstrand: hey
<diddledan> popey: it has the correct icon for me
<popey> Oh maybe font cache nonsense here maybe
<diddledan> I had to uninstall irccloud and reinstall though, because I'd installed 3 separate testing builds locally causing snapd to decide the snap no longer exists in the store
<diddledan> that's really ducked up
<diddledan> I get not installing store snaps over locally installed ones automatically. but I tried explicitly telling it which revision to install and it still said the snap doesn't exist in the store
<mvo> pstolowski: you mean because golang.org gives us 502 ?
<mvo> pstolowski: or terrible for different reasons?
<diddledan> htf are you supposed to switch between a test you built several times locally and the store snap?!
<mup> PR snapd#4993 opened: cmd/snap-confine: allow creating missing gl32, gl, vulkan dirs <Created by zyga> <https://github.com/snapcore/snapd/pull/4993>
<pstolowski> no, just 502
<popey> diddledan: you have to snap refresh foo --edge --amend
<diddledan> tried it
<popey> the --amend is important
<diddledan> didn't work
<popey> there is a bug with amend, which m vo is fixing
<popey> if the snap concerned isn't in stable
<diddledan> https://www.irccloud.com/pastebin/pTpa2npd/
<thresh> popey, hmm, I'm able to repro that appmenu issue; let me check why it works on my docker image
<popey> thresh: "great!"
<diddledan> also
<thresh> yeah, no
<thresh> :)
<diddledan> https://www.irccloud.com/pastebin/TAGOrUGZ/
<popey> maybe you need the channel too
<popey> as well as the revision
<zyga> pedronis: ack
<popey> diddledan: either way, wimpy tested so I'm gonna promote that to stable. Thank you!
<thresh> I wonder why this package is pulled in anyway
<diddledan> yey
<zyga> pedronis: nice work there
<zyga> pedronis: I think this is good enough for this issue for thie .3 release
<zyga> jdstrand: can you pleaes look at https://github.com/snapcore/snapd/pull/4993
<mup> PR #4993: cmd/snap-confine: allow creating missing gl32, gl, vulkan dirs <Created by zyga> <https://github.com/snapcore/snapd/pull/4993>
<zyga> am I right there?
<om26er> https://github.com/snapcrafters/sublime-text/pull/9
<mup> PR snapcrafters/sublime-text#9: ship gtk2 and fix desktop file shortcuts <Created by om26er> <https://github.com/snapcrafters/sublime-text/pull/9>
<om26er> popey: ^  and happy birthday :)
<zyga> ohhh
<zyga> once that's in edge I can test again :)
<jdstrand> zyga: you want to creat the dir and files in the dir?
<zyga> I really want s-t from a snap :)
<zyga> yes
<jdstrand> approved
<om26er> that makes the two of us.
<zyga> jdstrand: thank you!
<zyga> mborzecki: ^ FYI
<zyga> mborzecki: another 2.32.x backport needed I suspect
<om26er> also could anyone help with https://forum.snapcraft.io/t/right-click-menu-items-dont-work/4724 ?
<pstolowski> mvo, cachio i suppose the tests will keep failing unless we fix the problem of space on opensuse
<cachio> pstolowski, let me take a look
<zyga> om26er: oh, interesting
<zyga> om26er: I think our sanitization breaks the desktop file
<zyga> om26er: can you pastebin the generated destkop file in /var/lib/snapd/desktop/applications
<pstolowski> cachio: thanks!
<zyga> om26er: or better, a diff from the vanilla one
<zyga> om26er: I suspect we strip something and it's broken then
<cachio> pstolowski, do you have a link?
<cachio> I see most of them in green
<pstolowski> cachio: nah, not anymore, i kicked the tests again, sorry; let's see if it fails again on opensuse
<pstolowski> another bunch of 5xx from golang.org there :(
<mvo> pstolowski: right now tests are going strong
<mvo> pstolowski: fingers crossed (half done, no error yet)
<cachio> pstolowski, it is weird because we have a fixed image
<cachio> for opensuse 42.3
<cachio> but let's see
<zyga> cachio: hey
<pedronis> zyga: btw I think undo of Enable is also buggy
<zyga> about opensuse
<zyga> can you make sure our images don't run snapper
<zyga> it's a tool built into opensuse
<zyga> that takes snapshot of the system all the frelling time
<zyga> and it keeps them
<zyga> it makes 40GB VMs useless
<zyga> pedronis: in which way, looking at the code now
<pedronis> zyga: I think the undo  of setup-profiles   makes assumption that don't make sense for the undo of enable
<pedronis> it's again an issue of not enough info
<cachio> zyga, ah, ok, I'll take a look to that
<pedronis> zyga: afaict the undo of setup-profiles will put back profiles  as long as there's a current revision (active or not)
<cachio> perhaps the best option is to have our own opensuse 42.3 image
<pedronis> this is correct for the undos of refresh/install
<pedronis> but not enable
<cachio> so we can control what's inside
<zyga> pedronis: yes
<cachio> corrently we are using the one published by opensuse
<pedronis> not sure I care a lot atm
<pedronis> but is part of the messy picture of not enough state
<zyga> cachio: well, it'd be nice to be true to real opensuse images but perhaps they are not so suitable for cloud; can you ask in #opensuse-buildservice perhaps?
<cachio> zyga, ok
<pstolowski> mvo: it failed again, this time on 2 ubuntu systems on prepare :(
<pstolowski> https://api.travis-ci.org/v3/job/362640777/log.txt
<zyga> mmmm
<zyga> pedronis: so on undo we essentially setup security for the prior revision
<pstolowski> 502 from govendor syncs
<zyga> pedronis: (whatever it was)
<pedronis> yea, but disabled state
<pedronis> should have no profiles
<pedronis> disable does remove-profiles
<pedronis> anyway as I said, not super important right now, IÂ noticed because I was staring
<pedronis> at undo paths with setup-profiles link-snap in them
<pedronis> wondering if we can extend the fix to the undo case
<zyga> pedronis: I don't see it yet, sorry, i'm not that fast, is the issue with lack of state in setup-profiles or in how they are used to enable/disable
<zyga> ah
<zyga>     sideInfo := snapst.CurrentSideInfo()
<pedronis> it's lack of state IÂ think
<pedronis> active false
<pedronis> means disabled
<zyga> this will return nil when snap is inactive
<pedronis> but also I'm going through being refreshed
<pedronis> ?
<zyga> yeah, I see
<pedronis> no Current is always set
<pedronis> unless during installation
<zyga> the whole thing is just so complex now
<pedronis> irrespective of enabled or disabled
<zyga> ah, right
<zyga> pedronis: so in ifacestate/handlers.go on line 252 where we check if sideInfo is nil we should also check if it was active or not
<pedronis> that's not enough
<pedronis> I think
<pedronis> because of how we use active during refreshes
<zyga> I must say I'm very lost in how it's used
<pedronis> in both cases we enter
<pedronis> setup-profiles with active false
<pedronis> we really don't know
<pedronis> do I have profiles on disk or not
<pedronis> it's really related to the bug
<pedronis> and the idea of having a profiles-revision
<pedronis> in the state
<zyga> one thing to remember is that setup / remove will do the right thing for given input state
<zyga> they largely don't care about what is on disk
<pedronis> here they don't though
<zyga> the system there is designed to reach a stable state, given the desired stable state
<pedronis> we simply don't know enough
<zyga> if we tell the repo to setup security, we will
<zyga> it's juts that we don't know _what_ to say
<zyga> and that I understand is the issue
<pedronis> we don't know if there was a previous  set of profiles or disk or not
<zyga> I really honestly am lost in the state/task system now
<pedronis> we just assume that if current is set
<pedronis> that was the set
<pedronis> that's untrue when we undo enable
<zyga> and I think it warrants a whiteboard diagram that people discuss and collectively understand
<zyga> in this specific case the worse that can happen is that snap will have profiles that it doesn't need
<zyga> that's bad but harmless IMO
<pedronis> as I said I don't care about it as a bug that needs immediate fixing
<pedronis> it just points out we don't have enough state
<pedronis> from a similar/slightly different angle
<om26er> zyga: replied on snapcraft.io
<zyga> mborzecki: maybe you want to look at https://forum.snapcraft.io/t/right-click-menu-items-dont-work/4724/6
<zyga> you touched destkop files recently and it's related
<pedronis> zyga: as we said yesterday ifacestate is trying to "reuse" the state as kept by snapstate but there are matches/confusion
<pedronis> is not that the state is too complicated, is more that is slight out of phase/sync wrt what ifacestate does/needs
<pedronis> s/matches/mismatches/
<popey> om26er: zyga you guys clear with my proposal in the s-t pr?
<zyga> popey: https://github.com/snapcrafters/sublime-text/pull/9/files ?
<mup> PR snapcrafters/sublime-text#9: ship gtk2 and fix desktop file shortcuts <Created by om26er> <https://github.com/snapcrafters/sublime-text/pull/9>
<om26er> popey: We never released sublime to stable under sublime-text-3 name, so if we make an "announcement" of a type, I believe all those who have installed it currently will move to the new name.
<zyga> pedronis: I think the complexity in our design is derived from the delayed execution and state keeping and how the do/undo logic is structured
<thresh> :O
<zyga> pedronis: if ifacemgr gets to keep its own state
<zyga> pedronis: we can simplify some of it but only to the point where we need the interaction across managers
<pedronis> isn't the lesson instead that the best if the managers can ignore each other
<thresh> popey, I don't understand why this is happening: http://thre.sh/stuff/snapcraft-debug-docker.txt (docker image), appmenu-qt5 is marked to be fetched, but silently ignored
<zyga> pedronis: I think that's true but then again managers are all kind of "we manage snaps" in some way and the separation of interface manager is more of a "two people coded this" than deliberate design
 * thresh goes on comparing apt-conf dump
<pedronis> zyga: yes, in the sense that a solution to some extent would be to merge into doLinkSnap  both what it does and doSetupProfiles, then active would mean one thing, there are probably still issues though
<zyga> pedronis: yes, especially if it finishes half way and needs to clea nup
<zyga> on one hand side if every little thing is a task undo is easy
<zyga> on the other hand big tasks are easier to understand
<zyga> and regardless, making changes to task structure across snapd versions sucks
<zyga> we don't version them
<diddledan> popey: if you're looking for snap news, besides irccloud being updated today, I've just pushed openra 20180307 to stable
<diddledan> previous version was 20171014, and upstream have been doing a lot of work FWICT
<cachio> zyga, snapper is installed in opensuse
<diddledan> release notes from upstream: https://www.openra.net/news/release-20180307/
<cachio> zyga, who is running it?
<zyga> it's a systemd unit AFAIR
<zyga> removing it is a good idea
<zyga> it uses lots of disk space
<diddledan> popey: this is a choice quote from the release notes in the middle: "A fix for the AI cheating when it uses superweapons and support powers"
<diddledan> :-p
<diddledan> damned AIs. if they decide to murder us they'll cheat!
<cachio> zyga, all the snapper services are already disabled
<popey> diddledan: yay! :)
<zyga> cachio: cool, that's good then
<cachio> so, the problem is something else
<zyga> cachio: what's the partition layout
<cachio> I'll execute the test suite from here and debug it
<cachio> zyga, https://paste.ubuntu.com/p/Tmwbnj6X89/
<mvo> cachio: could you give me a quick heads up when the revert happend? I will write a note in the forum about it then
<zyga> nice, simple, good
<cachio> mvo, who is triggering the revert?
<cachio> I?
<cachio> or the store team?
<thresh> popey, welp, now I can reproduce the error with appmenu even on my docker image -- I had to upgrade snapcraft to 2.40 from 2.39.3+really2.35
<thresh> now that's something already
<mvo> cachio: its a change to the stable channel so if you could trigger it that would be great (once the store is ready)
<cachio> ok, just to release the previous versions to stable, right?
<cachio> 2.31.2
<mvo> cachio: yeah, correct 4205..4210 iirc, but let me quickly double check
<cachio> sure
<mvo> cachio: yeah, those are the versions
<cachio> nice
<cachio> pstolowski, hey you have a machine in google since yesterday
<cachio> is it ok
<cachio> can I kill it?
<pstolowski> cachio: ah yes, i forgot to free it. yes you can kill it
<cachio> pstolowski, thanks
<nacc> is the store still "sick" wrt. downloading the core snap?
<nacc> our CI is failing a bunch again
<nacc> (git-ubuntu)
<nacc> https://jenkins.ubuntu.com/server/job/git-ubuntu-ci/372/console e.g
<mvo> pstolowski: it is jinxed, the inject PR failed again
<mvo> nacc: we released a new core some minutes ago, maybe that is the problem?
<mvo> nacc: a bit of an overload
<mvo> zyga: do we need 4993 for 2.32?
<nacc> mvo: ok, i'll see
<zyga> checking
<zyga> yes, please take it
<zyga> it's a minor fix but people will like it
<mvo> zyga: sure, will do
<zyga> and it cannot regress
<zyga> it's adding permissions
<zyga> thank you
<mvo> zyga: ta
<zyga> thanks for checking :)
<mvo> jdstrand: hey, just wanted to (friendly) check if you will have time soon(ish) for a review of 4942?
<cachio> pstolowski, worked on opensuse
<cachio> no errorrs
<pstolowski> cachio: yes... but we have other failures again
<pedronis> mvo: don't know if you saw but I pushed #4991
<mup> PR #4991: ifacestate: add to the repo also snaps that are pending being activated but have a done setup-profiles <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4991>
<zyga> pedronis: +1 from me, just one question
<zyga> I will push the state on top
<jdstrand> mvo: my understanding is that is for 2.33, not for 2.32. I've been tasked with some 18.04 distro work and therefore put that review (and other non-2.32 snapd work) behind that work
<zyga> AFAIK we said all snap info loading would go through a helper in snapstate that loads from cache
<pedronis> there is no such helper
<pedronis> atm
<jdstrand> mvo: is this for 2.32?
<jdstrand> mvo: (it's already in our queue)
<zyga> ah, that's okay than
<pedronis> zyga: snapstate itself uses readInfo (you changed it recently), that's not public, not it is caching
<pedronis> s/not it/nor it/
<mvo> jdstrand: it was for 2.33 but its one of these things we really want and its relatively small and self-contained so we aim for it for 2.32. but of course time is in short supply so if you are busy you are busy :)
<jdstrand> mvo: I thought 2.32 was closed and bug fix only. you are saying that if I review this, you will put it in 2.32?
<jdstrand> mvo: if so, when does it need to be reviewed by? eod tomorrow? (I read 2.32 is now planned for next week)
<mup> PR snapcraft#2050 opened: storeapi: properly handle lacking permission for channel <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2050>
<mvo> jdstrand: we have 2.32 open right now because we are waiting for two critical fixes. so small/low risk/high gain can still go in. probably until tomorrow(ish). depends a bit on the pending fix(es)
<mup> PR snapd#4988 closed: snapstate, ifacestate: inject auto-connect tasks try 2 <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4988>
<mup> PR snapd#4993 closed: cmd/snap-confine: allow creating missing gl32, gl, vulkan dirs <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4993>
<zyga> thanks mvo
<mup> PR snapd#4994 opened: cmd/snap-confine: allow creating missing gl32, gl, vulkan dirs <Created by mvo5> <https://github.com/snapcore/snapd/pull/4994>
<mup> PR snapd#4995 opened: snapstate: inject autoconnect tasks in doLinkSnap for regular snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/4995>
<jdstrand> mvo: I should be able to get to it tomorrow. I may have some small policy updates to add to 2.32 too
<zyga> jdstrand: ping me for those, I will review them ASAP
<mvo> jdstrand: sounds good
<pstolowski> mvo: wow, you merged it; did it pass finally?
<mvo> pstolowski: yes, it finally did
<mvo> pstolowski: i'm trying to build the new core now
<pstolowski> mvo: great, thank you! let me know when it's available
<mvo> pstolowski: probably ~30min or so, just triggered the ppa build for the deb once that is done will do the core build
<jdstrand> oSoMoN: fyi: apparmor="DENIED" operation="chmod" profile="snap.chromium.chromium" name="/home/jamie/.config/ibus/bus/" pid=11621 comm="chromium-browse" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000
<jdstrand> oSoMoN: the dir exists and is already 0700. why is chromium trying to change that?
<zyga> pedronis: conflict on https://github.com/snapcore/snapd/pull/4991
<mup> PR #4991: ifacestate: add to the repo also snaps that are pending being activated but have a done setup-profiles <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4991>
<pedronis> zyga: btw, did you try it with reproducer?
<hyperreal> Hello all. Is there a way to just browse the snapcraft store? Like with categories or A-Z?
<zyga> pedronis: no, I'm about to try, just pushing my simple PR
<oSoMoN> jdstrand, that's probably caused by https://github.com/ubuntu/snapcraft-desktop-helpers/pull/104/files
<Chipaca> hyperreal: limitidly, yes
<mup> PR ubuntu/snapcraft-desktop-helpers#104: Add missing stage packages and copy ibus socket files to enable ibus for GTK3 applications out-of-the-box <Created by oSoMoN> <Merged by kenvandine> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/104>
<zyga> pedronis: https://github.com/snapcore/snapd/compare/master...zyga:fix/reload-repo-inactive-snaps?expand=1
<Chipaca> hyperreal: try "snap find --section"
<zyga> pedronis: not sure if correct, not super familiar with state handling
<hyperreal> Chipaca: thanks, I'll try that.
<jdstrand> oSoMoN: that would do it
<Chipaca> hyperreal: it needs more work on many fronts, but it's the beginning of the 'browse' journey
<oSoMoN> jdstrand, what would cause the chmod call? the call to ln ?
<jdstrand> oSoMoN: so, seems you could test -d $IBUS_CONFIG_PATH || mkdir $IBUS_CONFIG_PATH
<pedronis> zyga: I fixed the conflict
<zyga> thanks
<jdstrand> oSoMoN: well, wait a sec
<jdstrand> oSoMoN: XDG_CONFIG_HOME is in ~/snap at this point
<jdstrand> oSoMoN: I don't see where a chmod is happening
<popey> thresh: maybe follow up on that forum post and we can see if kyle can take another look.
<jdstrand> oSoMoN: perhaps there is an unconditional chmod in the ibus libs. I would argue that should be fixed to only chmod if it isn't what it expects. that would be something for SRU and then anything using the desktop launcher won't be affected by it
<thresh> popey, that's what I did, thanks!
<popey> oh great :D
<jdstrand> oSoMoN: as it stands, it sounds like if the lib is doing that, *every* snap that uses the part will trigger this denial, which will lead to confused users
<pedronis> zyga:Â it looks it's going in the right direction, but yes that would be more work to do around the undo code paths to consider/use that new state
<zyga> yes, that's how I re-purposed it after your idea
<pedronis> also thinking when it gets written to disk (state.Unlock)
<zyga> I think we want to store it for now
<zyga> and eventually switch over
<zyga> oh, good point
<pedronis> zyga:Â if you look at snapstate handlers, they tend to do Set almost always at the end
<pedronis> OTOH ifacestate stuff releases the lock more often (or did at some point)
<pedronis> so there's some thinking to do what we want,  what are the trade offs
<pedronis> it might not release the lock anymore though now that I think
<pedronis> we changed that
<pedronis> because it was actually making things slower
<zyga> I haven't looked yet but this is an important aspect of the correctness
<pedronis> mmh
<zyga> doSetupProfiles unlocks
<pedronis> no we still do unlock
<zyga> the stask state
<pedronis> before calling the backends
<zyga> is that the full state?
<pedronis> yes, there is nothing but the full state
<pedronis> we never write partial bits
<zyga> ok
<pedronis> so  one should always be careful
<pedronis> to have set something coherent into state
<pedronis> before Unlock is done or can happen
<zyga> so doSetupProfiles and doRemoveProfiles only unlocks at the end
<zyga> that feels correct for now
<pedronis> zyga: not really
<zyga> so each setup will unlock, giving us some idea of where we are
<zyga> no?
<pedronis> because they call setupSnapSecurity
<pedronis> does unlock in the middle
<zyga> ah, I see now
<zyga> because backends run processes
<zyga> and that's "slow"
<pedronis> yes, I think we wanted to remove those Unlock
<pedronis> especially the systemd backend was problematic
<pedronis> so we didn't in the end
<zyga> hmm I don't recall what the problems were
<Chipaca> Stop can take infinite time, for example
<zyga> interesting
<zyga> we call get/set (in my patch) just prior to that
<zyga> so we'd save the state then
<zyga> Chipaca: physicists tell me that if you got an infinitiy its a problem in your calculation ;)
<Chipaca> zyga: mumble "dirac's delta" at them and they'll shut up and bugger off
<oSoMoN> jdstrand, that denial is harmless though, isn't it?
<pedronis> zyga: we should call Set at the end as snapstate does
<jdstrand> oSoMoN: it doesn't seem to affect the snap no. however, there will be bug reports where people think it is causing trouble and people will have to constantly refute that it is an issue
<jdstrand> isn't*
<oSoMoN> true
<pedronis> zyga: when we are sure we are done
<zyga> pedronis: after setup succeeds
<zyga> yeah
<zyga> we should also remove but I haven't done that yet
<zyga> I could Set(st, snapName, nil) in the remove path but I didn't want to (since the struct can grow later)
<jdstrand> oSoMoN: traditionally we would add an explicit deny rule, but we don't like to do that since they override allow rules, and interfaces that use them will undo interfaces that are meant to allow it
<oSoMoN> jdstrand, it seems you are right:
<oSoMoN> osomon@bribon:/tmp/ibus-1.5.17$ grep -rn chmod
<oSoMoN> src/ibusregistry.c:475:        g_chmod (filename, 0644);
<oSoMoN> src/ibusbus.c:560:    g_chmod (path, 0700);
<jdstrand> oSoMoN: and by traditionally, I mean, outside of snapd
<jdstrand> there you go. a quick stat() check is all that is needed
<oSoMoN> jdstrand, I'll file a bug after dinner and will propose a fix
<jdstrand> oSoMoN: in this case, it is src/ibusbus.c:560
<jdstrand> oSoMoN: thanks!
<oSoMoN> yep
<oSoMoN> thanks for pointing it out!
<zyga> pedronis: I wonder if we should store revision if affected snaps failed
<zyga> I think yes, we should
<jdstrand> oSoMoN: thanks for working on a fix and even more thanks for getting ibus to work :)
<zyga> because that's really the truth
<pedronis> the truth in which sense?
<pedronis> we are interested in whether we need to AddSnap this snaps at that revision
<pedronis> if we should not do that, we shouldn't set it
<pedronis> if we should, we should set it
<zyga> pedronis: truth as in the profiles are on disk for that snap at that time
<zyga> https://github.com/snapcore/snapd/compare/master...zyga:fix/reload-repo-inactive-snaps?expand=1#diff-145e00c2f5e1d200010c00f39691a09cL200
<zyga> (please refresh, force pusheD)
<pedronis> should they be?
<pedronis> IÂ suppose this related to undo on error
<zyga> I think this is okay because even if affected snaps fail this snap is in the repo and it's meant to be reloaded
<pedronis> (which is not done by undo)
<zyga> yes, it certainly is, this is purely in the error path
<pedronis> IÂ mean, in snapstate tasks try to undo themselve if they error
<zyga> yes, and if they undo themselves correctly they will remove profiles (or setup another revision) which would update the state
<pedronis> does the code in ifacestate do that?
<zyga> probably not, let's see
<pedronis> I don't think it does
<zyga> I don't see any evidence of that, no
<pedronis> if setup profile of revion X fails,  we might have the profiles for revision X on disk
<pedronis> but the rest of the undo
<pedronis> will remove revision X
<pedronis> from the system otherwise
<zyga> we don't stash them
<zyga> and it's not just revision X
<zyga> it's also "whatever old snapd wrote"
<zyga> maybe we are busted
<zyga> so we'd have to rethink the logic around that for individual tasks to undo themselves mid-throgh-task
<pedronis> well in theory having profile-revision in state
<pedronis> should help knowing what is on disk
<pedronis> (except during the transition from not having it to having it)
<zyga> in some sense the undo task for setup profiles is the right undo for partially broken setup profiles
<zyga> we just don't use that
<zyga> undo unly runs if setup works all the wy
<zyga> *way
<pedronis> IÂ know
<pedronis> some things in snapstate do that
<pedronis> they basically call they undo* code
<pedronis> on error paths
<pedronis> not all of them
<pedronis> it depends
<zyga> yeah
<zyga> I think it would be nice to make that implicit
<zyga> (eventually)
<zyga> it is sane and nicer conceptually
<pedronis> it also true that most things snapstate (except aliases)
<pedronis> deal with the one snap
<pedronis> security touches more than one snap
<pedronis> the affected snap bit
<mvo> pstolowski: edge with inject-tasks v2 should be ready in 10min or so, core snap is building right now
<pstolowski> mvo: ack
<pedronis> zyga: basically there's a lot of things to think about in this area, if we start cleaning up
<zyga> pedronis: I agree
<zyga> pedronis: I opened a PR with this code as is
<zyga> it's not interacting with your fix yet
<zyga> not sure if that's something we can merge before gustavo is back
<mup> PR snapd#4996 opened: overlord/ifacestate: store and use revision with security profiles set <Created by zyga> <https://github.com/snapcore/snapd/pull/4996>
<pedronis> zyga: we should remove the state in discard-conns, no?  that's the task we use in ifacestate when a snap goes completely away?
<zyga> that's a good point
<zyga> yes, I'll do that
<zyga> force pushed one liner
<pedronis> pstolowski: mvo: there's a new core in edge it seems
<mvo> yes
<mvo> !
<cwayne> Beta expected today?
<pstolowski> mvo: pedronis ok, checking
<mvo> pstolowski: good luck, I'm running my own test here too
<mvo> pstolowski: looking good here
<mvo> zyga: I assume 4996 is for 2.32?
<zyga> Hey
<pedronis> mvo: maybe .4  but not .3
<zyga> We donât need it, it is not a fix
<pedronis> is just to start storing things
<zyga> Itâs long term
<pedronis> mvo: #4991 we need to decide if we want it for .3 or wait
<mup> PR #4991: ifacestate: add to the repo also snaps that are pending being activated but have a done setup-profiles <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4991>
<pstolowski> mvo: all looks fine here as well
<mvo> pstolowski: yay
<mvo> pstolowski: I have the backport ready
<pstolowski> mvo: lxd interfaces reported as connected (haven't tested lxd functionality though); no errors in snap change(s), and I see a series of connect task added there as expected
<pedronis> great
<pstolowski> mvo: awesome
<mvo> pstolowski: yeah, lxc (the command) runs
<mvo> pstolowski: and lxc info as well
<mup> PR snapcraft#2051 opened: elf: use snapped strip <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2051>
<pstolowski> great
<mup> PR snapd#4994 closed: cmd/snap-confine: allow creating missing gl32, gl, vulkan dirs <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4994>
<mvo> pedronis, zyga how safe do you consider the PR?
<pstolowski> eod, cu
<zyga> pedronis: which one?
<zyga> er
<zyga> mvo: which one?
<zyga> the one from pedronis?
<mvo> zyga: 4996 was the one I just looked at. but its different from what we discussed earlier, didn't we?
<zyga> ah, this one
<pedronis> mvo: 4996 is not a fix
<zyga> I think it's not critical
<zyga> it's not the fix, it's probably going to get renamed / changed
<pedronis> mvo: the fix (for the do path) is #4991
<mup> PR #4991: ifacestate: add to the repo also snaps that are pending being activated but have a done setup-profiles <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4991>
<zyga> what pedronis did is the real thing
<zyga> mvo: review and squash 4991
<mvo> zyga: ok, checking
<mvo> pedronis: oh, thank you
<mup> PR snapd#4991 closed: ifacestate: add to the repo also snaps that are pending being activated but have a done setup-profiles <Squash-merge> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4991>
<mup> PR snapd#4997 opened: ifacestate: add to the repo also snaps that are pending being activated but have a done setup-profiles <Created by mvo5> <https://github.com/snapcore/snapd/pull/4997>
<mup> PR snapd#4995 closed: snapstate: inject autoconnect tasks in doLinkSnap for regular snaps <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4995>
<pedronis> I have updated the forum topic with links to the PRs
<mvo> hrm, hrm, no travis slots
<zyga> pedronis: thank you
<zyga> mvo: bummer :/
<zyga> I'm waiting for kids to finally go to slepe
<zyga> *sleep
<mup> PR snapcraft#2052 opened: many: add override-prime scriptlet <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2052>
<zyga> mvo: can I help or shall we wrap and do it tomorrow
<mvo> zyga: looks like tomorrow, no slot from travis
<mvo> zyga: which is a bummer, its the last pending PR
<mvo> oh well
<mvo> zyga: I will get up early and continue with this
<cachio> mvo, any idea if travis is stuck?
<mvo> cachio: its probably just that we used to many travis slots today that they don't give us new ones right away
<zyga> well
<zyga> did it pass on master?
<zyga> run unit tests and merge it
<cachio> mvo, ah, ok
<zyga> it's not disto specific
<mvo> zyga: yeah, well, would love to have a full run
<mvo> zyga: but maybe you are right
<zyga> you could have done a full run by now :)
<zyga> it's 25~ for a full run
<zyga> not saying it's bad you didn't it's just not exclusive to travis
<cachio> mvo, do you know which travis machines have the google credentials?
<mup> PR snapd#4997 closed: ifacestate: add to the repo also snaps that are pending being activated but have a done setup-profiles (2.32) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4997>
<cachio> I think the trusty ones don't
<cachio> I updated all the spread branches but they fail because of lack of credentials on travis machine
<mup> PR snapd#4998 opened: release: 2.32.3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4998>
<mup> PR snapd#4999 opened: advisor: use json for package database <Created by mvo5> <https://github.com/snapcore/snapd/pull/4999>
<mup> PR snapd#5000 opened: errtracker: make TestJournalErrorSilentError work on gccgo <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5000>
<mvo> zyga: and the build failed on pwerpc :(
<zyga> uhhhh
<zyga> why?
<mvo> zyga: so we will need one more release for the deb
<zyga> mvo: can we retry?
<mvo> zyga: but thats ok, the core can still go to beta
<zyga> or is it really broken
<mvo> zyga: no, see PR above
<mvo> zyga: its a new test in errtracker that breaks
<zyga> ahhh
<mvo> zyga: in very silly ways
<zyga> s....t
<zyga> can we not build for ppc in the future or would that cause migration issues?
<mvo> zyga: we need to haggle with the distro about this
<mvo> zyga: I would love to stop doing that but so far keeping it alive was more cost effective (less time spend) than to argue this
<mvo> zyga: but maybe we are reaching the tipping point
<zyga> mvo: bionic is about to ship
<zyga> is bionic ppc-free?
<mvo> zyga: it is!!!
<mvo> zyga: happy days
<zyga> my poor ppc box ;(
<zyga> good :)
<mvo> zyga: xenial has 3 more years
<mvo> zyga: and there is always debian ;)
<mvo> zyga: lol@your comment
<mvo> zyga: I wish I could :heart: that
<zyga> https://github.com/snapcore/snapd/pull/4999/files#r179598750
<mup> PR #4999: advisor: use json for package database <Created by mvo5> <https://github.com/snapcore/snapd/pull/4999>
<mvo> zyga: thank you!
<mvo> zyga: hrm, hrm, I really hope the ppa build finishes soon, I want to sleep :)
<mvo> or :/
<mvo> or even :(
<zyga> my eyes are closing
<zyga> I'm closing my laptop now, sleep well and rest tomorrow
<zyga> all work and no play makes mvo a dull developer
<zyga> remember that ;)
<zyga> it ends bad in the movie
<oSoMoN> jdstrand, bug #1761585
<mup> Bug #1761585: ibus_bus_init does an unconditional call to chmod on $HOME/.config/ibus/bus <amd64> <apport-bug> <bionic> <ibus (Ubuntu):New> <https://launchpad.net/bugs/1761585>
<jdstrand> oSoMoN: thanks!
<mvo> cachio: just fyi (no rush) - 2.32.3 for amd64/i386 is in beta now. once arm/arm64 is ready I will publis hthat too
<cachio> mvo, nice, I'll start today
<cachio> so for tomorrow morning we have some results
<mvo> cachio: yay
<cachio> mvo, did you see my comment about travis?
<cachio> about in spread cron the jobs are failing because we dont have credentials
<mvo> cachio: let me read
<mvo> cachio: ohhh
<mvo> cachio: that makes sense. what can we do?
<cachio> could be happening because we are runing on trusty?
<cachio> I have removed the trusty config but I could not validate if it is the cause
<cachio> because we don't have more slots :(
<mvo> cachio: :(
<mvo> cachio: yeah, its really annoying
<cachio> tomorrow we will have more?
<mvo> cachio: yeah
<cachio> ok, I'll wait
<cachio> today I updated like 40 branches
<cachio> and all of them failed because of that :(
<cachio> parhaps it is my fault
<cachio> I mean the reason why we don't have more travis slots
<mvo> cachio: don't worry, but yeah, I think we get rate limited by travis at some point
<mvo> cachio: armhf is now ready too in beta, I will do arm64 in my morning
<Trevinho> question.. Is build.snapcraft.io now reading the yaml `base:` stanza to decide were to build the snap or will it use just core16 for everything?
<Caelum> zyga: it doesn't look like they're regenerating the website
#snappy 2018-04-06
<mup> PR snapd#5000 closed: errtracker: make TestJournalErrorSilentError work on gccgo <Critical> <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5000>
<zyga> Caelum: yeah, I'll ask for that now
<mborzecki> morning
<Caelum> zyga: ideally they'd have a nightly cron job or something
<zyga> I just asked, not sure how it is set up
<zyga> And we have another point release of snapd
<Caelum> nice
<zyga> I will prepare the build
<zyga> And maybe, just maybe, work on features again
<zyga> This week was tough
<zyga> Useful, fantastic bug fixes, but tough
<zyga> I have updated https://github.com/snapcore/snapd/releases/tag/2.32.3
<zyga> Caelum: do you want to update the package to 2.32.3?
<kalikiana> good morning
<Caelum> zyga: sure I'll give it a go
<zyga> thank you!
<mup> PR snapd#4998 closed: release: 2.32.3 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4998>
<pstolowski> mornings
<zyga> hey pawel
<Caelum> I figured out how to make my laptop not shutoff randomly so that should help
<mborzecki> zyga: i left one comment in #4996
<mup> PR #4996: overlord/ifacestate: store and use revision with security profiles set <Created by zyga> <https://github.com/snapcore/snapd/pull/4996>
<zyga> thanks
<mborzecki> otherwise looks sane to me
<zyga> fixed
<zyga> the formatting
<zyga> is the error really a problem?
<mborzecki> zyga: it is in if/then/else block, the thing is if Get() fails, the err will be swallowed up, don't know if that's intended (maybe it is?)
<zyga> which err is swallowed?
<zyga> the one from Get or the one from setup affected tasks
<mborzecki> zyga: one in line 206
<zyga> the Get one is deliberate
<zyga> yes
<mborzecki> aah ok then
<zyga> we don't want to err n that
<zyga> ah
<zyga> I misunderstood your comment then
<mborzecki> all clear now
<Caelum> zyga: do you know if we still even need the libtool patch?
<zyga> I suspect it is needed
<zyga> because there's some build flags that get injected in some odd way I don't understand
<zyga> we will simplify the C build system soon
<zyga> drop auto mess
<zyga> and remove more (all) conditionals
<Caelum> cool
<zyga> popey: I reverted irccloud-desktop on my system as the latest revision is not working
<zyga> revision 25 is ok
<zyga> 41 doesn't start
<popey> This is because you reverted snapd
<popey> 2.31 breaks irccloud
<popey> 2.32 fixes it.
<popey> When will 2.32 come back to stable? (You could get core from beta to work around)
<zyga> I see
<zyga> I think next week
<zyga> but I don't know for sure
<zyga> we just released a new beta
<tomwardill> i got core from beta due to the nvidia fixes, can confirm irccloud-desktop works
<tomwardill> also the font issue I had in irccloud-desktop with twitter previews appears to have gone away, so thanks whoever fixed that! :)
<popey> zyga: it broke other applications too, ones we were waiting for 2.32 for. Quite frustrating as I'm now being pinged everywhere that my applications are all broken
<zyga> do you know which feature missing in 2.31 is key?
<zyga> I hope we can update to 2.32.3
<popey> It's the new stuff from jd strand to turn kernel errors into warnings.
<popey> things that request process-control or try to chmod files break
<popey> so games break, nodejs applications break. we waited for 2.32 before releasing them and making a splash, now we have to go and clear up that mess
<Skuggen> I'm struggling a bit with updating an older snap (mysql). Paths for various library files and binaries are no longer loaded by default. Do I need to manually specify every path to LD_LIBRARY_PATH?
<Skuggen> (snapcraft 2.39.2)
<Chipaca> Skuggen: you're updating _the_ mysql snap?
<Chipaca> Skuggen: or a snap that uses mysql?
<pedronis> popey: 2.32 broke people doing snap install lxd though
<Skuggen> Chipaca: The mysql snap
<Chipaca> Skuggen: nice :-)
<popey> Sure. I understand there was an issue. But we got a "surprise, we broke your apps to fix someone elses"
<popey> I would like for there to be an incident report for this. Why was this not caught in QA?
<pedronis> because basically    snap install lxd  only exercise core once its in stable
<pedronis> we need to find a way to test that before
<Skuggen> Chipaca: We were blocked by various missing features (privilege dropping, setting file ownership, etc.) so haven't looked at it for a while. I'm working on getting it updated so we can see what might still be missing for us to properly support it
<Caelum> zyga: any new data files in .32 I should know about?
<Chipaca> Skuggen: daemons still only run as root, that hasn't changed
<Chipaca> fwiw
<pedronis> popey: about  an IR, that's fair,  mvo should look into that
<popey> Thanks
<Skuggen> Chipaca: Yeah, that is an issue. We could have some limited support of it even so, though. But first I need to actually get it working again :)
<Chipaca> :)
<Chipaca> Skuggen: just the other day somebody was asking about using mysql in a snap, fwiw (via embedding), and looked at the mysql snap as an example
<Chipaca> (and then looked away in haste)
<Chipaca> Skuggen: https://forum.snapcraft.io/t/mysql-server/4877
<Chipaca> just yesterday, in fact
<zyga> Caelum: no, it's all the same
<Caelum> awesome
<Caelum> I need to redo it at some point to do a make install on data
<Skuggen> Chipaca: Ah, can respond to that at least :)
<Chipaca> Skuggen: do you know what version of snapcraft you used to build the snap before?
<Skuggen> Hm, can you get that information from the snap itself?
<Chipaca> Skuggen: I don't think you can
 * Chipaca is not a snapcraft expert though
<Chipaca> kalikiana: snapcraft doesn't record its version in the snap in any way, does it?
<Skuggen> We used a xenial host, but don't know what version it had at the time
<Skuggen> Submission date
<Skuggen> 2017-01-27 08:18 - 1 year, 2 months ago
<Skuggen> Oold
<Skuggen> That's the one on the store
<Chipaca> Skuggen: and the one in the 'latest' track is even older, 2016-12-19
<Chipaca> that's latest/beta
<zyga> Caelum: and I heard the install instructions are now live
<Caelum> indeed they are, fantastic
<Chipaca> popey: do you know if there's a guide or knowledge base or sth to update a snap that was created using snapcraft in the pleistocene?
<Caelum> zyga: /usr/lib/udev/snappy-app-dev is gone, do we drop it or add it as a source
<popey> Chipaca: wat
<zyga> I think we want to copy snap-device-helper over as snappy-app-dev
<zyga> Caelum: I think that's what we do for now, as there are still some transition complexities
<kalikiana> Chipaca: Nope. Though you can use SNAPCRAFT_BUILD_INFO=1 to have it record manifest.yaml which contains Debian packages and snaps installed during the build.
<kalikiana> And therefore indirectly Snapcraft's versions or revision
<Caelum> zyga: got it
<Chipaca> kalikiana: popey: Skuggen here is tasked with updating the mysql snap, and the newest revision is over a year old, and the snapcraft.yaml no longer works, and they don't know what snapcraft it was built with
<Skuggen> Might be simplest to start over; It's not super complicated, but contains extra binaries and libraries that are accessed by shell scripts (to replicate some of the install logic of the regular deb packages so users don't need to manually initialize databases and such)
<Chipaca> Skuggen: possibly, snapcraft's changed a lot, although i'm surprised a snap stopped building entirely (i thought it had tests for that)
<Skuggen> e.g. I got it to build, but it has issues finding things like the libaio1.so we include
<popey> Ah, understood.
<kalikiana> Right. If the existing snap doesn't contain manifest.yaml I'm afraid that information won't be available.
<Chipaca> Skuggen: so, that's one thing to do: for your future self, make sure SNAPCRAFT_BUILD_INFO=1 is set in the build environment
<Chipaca> Skuggen: so you can answer 'what was this built with'
<popey> Skuggen: I'm a touch busy today, but I think if you pasted the yaml in the forum we could mobilise some people to look
<Chipaca> kalikiana: wait, can you drop SNAPCRAFT_BUILD_INFO into the snapcraft.yaml itself?
<Skuggen> popey: Can do that, sure. Thanks
<kalikiana> Chipaca: No, it's an envrionment variable.
<Chipaca> kalikiana: and the environment: section of snapcraft.yaml is passed through to the snap, not acted on?
<Chipaca> i thought it influenced the build
<kalikiana> Chipaca: Right, those don't actually affect what Snapcraft will look at
<Caelum> zyga: this test fails completely randomly on me, usually it passes but sometimes I get this: https://gist.github.com/rkitover/460ebe31c6bc3d7508ff584d505cdbce
<zyga> hmmm
<zyga> feels like a timing racy test
<pedronis> those tests use settle
<pedronis> so it's probably deeper
<pedronis> a bit hard to tell from that error though
<zyga> Caelum: has that happened before?
<zyga> I suspect it's not new to this release
<Chipaca> zyga: question about your lab
<zyga> yes sir?
<Chipaca> zyga: do you have an nfs mount in there
<zyga> no, I'm afraid I don't
<zyga> but it could be arranged
<zyga> the pi3-1 machine has a HDD and we could arrange for NFS export there
<zyga> do you want one on the ppc box or somewhere else? (client side)
<Chipaca> zyga: I don't mind the arch for this
<Chipaca> just need nfs
<zyga> sure,
<Chipaca> zyga: but if it's not set up i can probably do something at home instead
<zyga> Chipaca: I just installed nfs server on pi3-1
<zyga> can you ssh there?
<Chipaca> i can
<zyga> now it's just a matter of exporting something
<Chipaca> zyga: I can't sudo there though
<zyga> oh
<zyga> let me fix that
<Chipaca> zyga: because the password i have for the others doesn't work there
<zyga> Chipaca: reset your password to your username and gave you sudo
<zyga> feel free to export /home or something you want
<zyga> I can stick another device if you want really networked NFS
<zyga> I have a few more PIs and beagles
<Chipaca> zyga: thanks
<mborzecki> bash: line 3: cannot create temp file for here-document: No space left on device <--- 2018-04-06 11:42:41 Error preparing google:ubuntu-16.04-32:tests/main/
<zyga> who used all the space? :)
<Chipaca> hue hue hue
 * Chipaca laughs in brazilian
<pedronis> is resizing broken?
<Caelum> zyga: yes it happened with .31 too
<mup> PR snapd#4986 closed: snapstate: fix `snap refresh --amend` when the snap is not available in stable <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4986>
<pedronis> zyga:  blargh
<zyga> what's wrong?
<pedronis> we don't want that fix
<zyga> oh?!
<pedronis> because is going to conflict with the new code
<zyga> sorry, I can revert taht
<pedronis> that just works
<zyga> no worries, it's a revert away
<pedronis> I'm going to merge 4900 today, once it's green
<pedronis> it should have been marked blocked
<pedronis> but lots of stuff going on yesterday
<zyga> https://github.com/snapcore/snapd/pull/5001
<mup> PR #5001: Revert "snapstate: fix `snap refresh --amend` when the snap is not avâ¦ <Created by zyga> <https://github.com/snapcore/snapd/pull/5001>
<mup> PR snapd#5001 opened: Revert "snapstate: fix `snap refresh --amend` when the snap is not avâ¦ <Created by zyga> <https://github.com/snapcore/snapd/pull/5001>
<zyga> pedronis: can you do a review of https://github.com/snapcore/snapd/pull/4996
<mup> PR #4996: overlord/ifacestate: store and use revision with security profiles set <Created by zyga> <https://github.com/snapcore/snapd/pull/4996>
<zyga> and I guess we want to add gustavo to review list
<pedronis> not sure I get to it today, more likely monday
<Caelum> zyga: request sent
<zyga> thanks, looking
<zyga> i forgot the details but fair that symlink must be a real cop
<zyga> copy
<zyga> otherwise +1
<Caelum> sure, one moment
<Chipaca> mborzecki: setre[ug]id works \o/
<mborzecki> Chipaca: yay :)
<Chipaca> mborzecki: yes =)
<mup> PR snapcraft#2053 opened: meta: implement pass-through of properties to snap.yaml <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2053>
<mborzecki> Chipaca: nfs too?
<Chipaca> mborzecki: that's what i was testing =)
<mborzecki> Chipaca: great, so we can kill #4990 now
<mup> PR #4990: many: implement a poor man's privileges drop, use for auth.json <Created by chipaca> <https://github.com/snapcore/snapd/pull/4990>
<Chipaca> mborzecki: with extreme prejudice
<mborzecki> haha :)
<kalikiana> greyback: I reckon you might wanna take a peek at snapcraft#2053 as you expressed your interest in the forum
<mup> PR snapcraft#2053: meta: implement pass-through of properties to snap.yaml <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2053>
<Chipaca> mborzecki: I'll tweak the code to retry a couple of times on EAGAIN before panic'ing
<Chipaca> mborzecki: as we've learned that EAGAIN happens =)
<Chipaca> mborzecki: also might as well move Sete[ug]id to sys
<Chipaca> mborzecki: thank you again for reminding me about this =)
<mup> PR snapd#4990 closed: many: implement a poor man's privileges drop, use for auth.json <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4990>
<mup> PR snapd#4983 opened: osutil/sys, client: add sys.RunAsUidGid, use it for auth.json <Created by chipaca> <https://github.com/snapcore/snapd/pull/4983>
<Caelum> zyga: fixed
<zyga> thank you, looking
<zyga> and sorry I didn't mention this
<Caelum> you did say copy over
<zyga> yes but I wasn't clear it is important :)
<zyga> thank you for the work, it should be out soon :)
<Caelum> nice
<pstolowski> zyga: i've updated the tests of #4968 ; that got me thinking a bit about the old code of ubuntu-core -> core migration that's executed on startup; I remove stale connections *after* all the renaming in initialize. that's ok isn't it?
<mup> PR #4968: RFC: ifacemgr: remove stale connections on startup <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4968>
<zyga> interesting
 * zyga thinks
<pstolowski> zyga: question is if the core snap is alrady under new name, or is there a risk of considering the renamed connections "stale"
<pstolowski> it's hard to reason about this based on unit tests
<zyga> the transition is a task
<zyga> it's not instant
<pstolowski> zyga: right. but the renaming of conns happens on snapmgr init
<pstolowski> zyga: so it kicks inafter re-exec, so we have new snap at hand correct?
<zyga> yes
<zyga> well, remember the is a version of this code that runs on ubuntu-core
<zyga> that's not as up-to-date
<zyga> I think this is ok
<zyga> but more than happy we didn't do it earlier
<zyga> pedronis: can you please merge https://github.com/snapcore/snapd/pull/5001
<mup> PR #5001: Revert "snapstate: fix `snap refresh --amend` when the snap is not avâ¦ <Created by zyga> <https://github.com/snapcore/snapd/pull/5001>
<popey> I have reverted back to core stable and now I get this when launching snaps:- failed to create prefix path: /tmp/snap.rootfs_M8USmi/var/lib/snapd/lib/vulkan/icd.d: Permission denied
<zyga> popey: that's fixed in beta
<zyga> stable is stable but buggy
<popey> yeah, i am trying to use stable because that's what normal people use
<zyga> I think this will be fixed once beta promotes
<popey> we're lining up snaps to promote on the social media, but I can't tell what will and won't work for users
<zyga> it's a bad week
<zyga> we have nothing better
<popey> ok
<zyga> beta is most stable IMO
<zyga> (today)
<mup> PR snapd#5001 closed: Revert "snapstate: fix `snap refresh --amend` when the snap is not avâ¦ <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5001>
<pedronis> zyga: done, thanks
<zyga> thank you
<pedronis> trying to get #4900 to green again and then will merge it
<mup> PR #4900: many: use the new install/refresh API by switching snapstate to use store.SnapAction <Blocked> <Critical> <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4900>
<pedronis> and prepare the backport, but the backport  is probably to merge once .3 is in stable
<pedronis> and then we can do a .4 in beta
<zyga> the backport will be for 2.32.4?
<pedronis> yes
<pedronis> thats' what I discussed with mvo
<zyga> ack
<zyga> are we doing standup at 14:00 or 15:00?
<zyga> I need to leave in 40 minutes to go to school
<mborzecki> 3pm i presume
<mborzecki> heh, amazon linux 2 is 64bit only, they don't provide any *.i686 libs
<mborzecki> this makes one of our unit tests to fail https://paste.ubuntu.com/p/JyqX9Wh9Rw/
<pedronis> we should really add some sort of skip logic to that test
<pedronis> it also fails if you don't have the right deps
<pedronis> installed
<Chipaca> it also fails if you try to run it on a banana
<Chipaca> Â¯\_(ã)_/Â¯
 * Chipaca is full of Â¯\_(ã)_/Â¯ today
<pedronis> Chipaca: let put it this way, as written is not very friendly to porting to random other distro
<Chipaca> pedronis: tbh i'm surprised multilib works at all
<Chipaca> cross-distro i mean
<Chipaca> but, yes, agreed
<Chipaca> i'm being somewhat facetious
<zyga> I need to go AFK
<zyga> see you at the standup, from the phone
<mup> Bug #1761253 changed: Installing a network-bind snap along with core fails results in incorrect permissions <Snappy:Fix Released> <https://launchpad.net/bugs/1761253>
<zyga> Caelum: approved, it's out :)
<mup> PR snapd#4900 closed: many: use the new install/refresh API by switching snapstate to use store.SnapAction <Critical> <Squash-merge> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4900>
<Caelum> sweet!
 * cachio afk
<mup> PR snapd#5002 opened: many: use the new install/refresh API by switching snapstate to use store.SnapAction <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5002>
<Chipaca> mborzecki: #4983 is green and happy as a bean
<mup> PR #4983: osutil/sys, client: add sys.RunAsUidGid, use it for auth.json <Created by chipaca> <https://github.com/snapcore/snapd/pull/4983>
 * kalikiana lunch
<pstolowski> Chipaca: standup?
<Chipaca> pstolowski: yeah, was jiggering my camera
<mup> PR snapd#5003 opened: cmd/snap-seccomp: graceful handling of non-multilib host <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5003>
<eraserpencil> Hey guys! are snaps able to work with USB and serial devices well?
<Chipaca> eraserpencil: yes :)
<eraserpencil> thanks!
<Chipaca> eraserpencil: only issue might be if it's a new flavour of serial, as they're whitelisted
<Chipaca> ie if you start having /dev/ttyFunky0, it'll need a patch
<Chipaca> (although that one in particular might not =) )
<eraserpencil> nice
<eraserpencil> like erm communicate with multiple USB ports and one serial connection whilst having web servers and processing algorithms?
<eraserpencil> I'm looking at the ROS-Snap tutorial, not sure what the limits of snaps are
<Chipaca> eraserpencil: probably a kyrofa question
<pedronis> cachio: now I see, the issue is that secrets are encrypted per repository, you cannot reuse a snapd secret for snapd-cron
<cachio> ahh
<cachio> pedronis, that makes sense
<pedronis> cachio: I'm not sure how gustavo created the key for snapd, but  we need to rencrypt it for snapd-cron, or create a new one and encrypt
<pedronis> cachio: probably need to discuss with him
<cachio> pedronis, yes, I'll wait until next week
<zyga> pedronis, cachio: yes, I bumped into that as well
<kalikiana> re
<zyga> this prevents people from copy-pasting secrets around
<zyga> but if you know the decrypted secret you can easily re-encrypt it and add it via travis
<pedronis> yea, but we don't
<eraserpencil> Chipaca: whats a kyrofa question
<Chipaca> eraserpencil: 'multiple USB ports and one serial connection', in the context of ROS
<Chipaca> eraserpencil: I see ROS, I defer to the kyrofa
<Chipaca> :-)
<mborzecki> off to pick up the kids
<jdstrand> roadmr: hi! can you pull in r1018? (just a few more overrides)
<roadmr> jdstrand: absolutely. Here I go!
<jdstrand> roadmr: thanks! :)
<zyga> jdstrand: hey
<jdstrand> zyga: hi!
<jdstrand> roadmr: fyi, snapcraft 2.40 is now in stable and -updates everwhere. this is what we were waiting on for the resquash tests. in the coming weeks I'm going to request an isolated pull to turn on enforcement
<jdstrand> roadmr: we'll want to keep an eye on it though in case we want to back it out
<roadmr> jdstrand: ok. How do we turn it on? set an env var?
<jdstrand> roadmr: today, that is how. I'm going to flip the logic for that
<jdstrand> and request a pull
<roadmr> jdstrand: oh understood. Think we should put that behind a feature flag so we can have a panic switch in case it all goes awry?
<jdstrand> roadmr: how do you envision implementing that? I figured that was what the env var would do
<zyga> jdstrand: I'd like to deconflict and merge https://github.com/snapcore/snapd/pull/4868
<mup> PR #4868: cmd/snap-update-ns: add secure bind mount implementation for use with user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4868>
<zyga> it's already reviewed just FYI
<zyga> I picked up user mounts
<zyga> expect useful stuff on ~Tuesday
<jdstrand> zyga: well, it needs an additional comment
 * zyga -> cooking
<jdstrand> 4868
<jdstrand> I owe the PR a response. I plan to do that today
<zyga> aha
<zyga> I will look for your response then
<jdstrand> codewise it is fine. james and I disagreed on the phrasing of a comment
<jdstrand> (a comment I suggested, so it wasn't added)
<roadmr> jdstrand: yes but how do we set/unset the env var in the store? a feature switch is a thingy we can flip on/off in the django admin and that controls stuff in the code
<roadmr> jdstrand: so something like if is_set('the_flag'): os.environ['RESQUASH_CHECK'] = "true"
<roadmr> jdstrand: because otherwise, if we need to switch this on quickly, we'd need a redeploy or something
<roadmr> s/on/off/
<jdstrand> roadmr: ok, I wasn't sure where you wanted the feature
<roadmr> jdstrand: well no matter, let me ponder and we'll implement this if needed
<roadmr> jdstrand: I mean - it's fine that the tools themselves have a way to control this, but remember this lives on a production server where I have no direct access
<jdstrand> roadmr: I think it sounds like a nice idea. the worst that can happen is things end up in manual review. but, that could be a big number so being able to stop the bleeding quickly would be good
<roadmr> so I can't easily e.g. ssh in and set/unset that variable in /etc/environment
<roadmr> jdstrand: ok so I'll look into doing that then
<jdstrand> obviously tyhicks and I believe that things are all worked out, but, you never know :)
<jdstrand> zyga: I was confused. the comment I owe is in pr 4957
<mup> PR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957>
<zyga> ahh
<zyga> ok
 * Chipaca hears rumours of cake and goes forth
<jdstrand> also, the code in 4957 is also ok
<jdstrand> I'll add my response to that so you can consider it too
<jdstrand> zyga: what is the 'squash-merge' label?
<Chipaca> jdstrand: PRs that are to be cherry-picked should be squashed before merging
<Chipaca> jdstrand: so it's just the one cherry
<jdstrand> Chipaca: does that remove all the comments/etc/etc that are in github?
<Chipaca> jdstrand: not the comments on github, but it replaces all the commits with one (the default commit message is a summary of the commits it's squashing)
<jdstrand> Chipaca: eg, for a commit that ends up squashed? it would be a shame if there was a ton of discussion on a particular point, then we resquash and it goes *poof*
<jdstrand> I feel like this has happened in the past...
<Chipaca> jdstrand: it only affects the git history, not the github discussion
<jdstrand> interesting. since the git hub discussion is hidden based on certain commits
<jdstrand> ok, well, if it is not supposed to remove anything, cool
<Chipaca> jdstrand: do you have an example of a hidden discussion?
<Chipaca> (that is, i'll admit, a bit like asking "can you show me what was stolen")
<zyga> jdstrand: it's not really hiding it
<pedronis> it's not something that happens to the PR, it happens on master
<zyga> jdstrand: I merged master into 4868
<zyga> jdstrand: if you want to make some comment changes please go ahead
 * zyga is happy that latest core build is really just new snapd
<cwayne> Me too :)
<Chipaca> zyga: note #4999 is now green
<mup> PR #4999: advisor: use json for package database <Created by mvo5> <https://github.com/snapcore/snapd/pull/4999>
<zyga> thanks, looking
 * Chipaca off for a while
<Chipaca> have a good weekend all, if i don't see you before your eow
<jdstrand> popey: btw, that request for a review tools sync has the emoj override
<jdstrand> ^
<popey> thanks!
<popey> cjwatson: https://launchpadlibrarian.net/363464768/buildlog_snap_ubuntu_xenial_armhf_b69a088aa70edd446e36c2072b30e222-xenial_BUILDING.txt.gz
<popey> something odd going on with this build - it's looping over a couple of files
<popey> (giant log file, note)
<popey> Wondered if this was something broken at the launchpad end as the yaml seems fine to me.
<cjwatson> popey: is there any particular reason to believe it's a problem with LP rather than snapcraft?
<popey> fair point, I'd just never seen that happen before.
<cjwatson> popey: it would be pretty unusual for that to be caused by LP.
<popey> Hmph. Ok. will dig more.
<cjwatson> node-pre-gyp ERR! Tried to download(404): https://github.com/kelektiv/node.bcrypt.js/releases/download/v1.0.3/bcrypt_lib-v1.0.3-node-v57-linux-arm.tar.gz
<cjwatson> node-pre-gyp ERR! Pre-built binaries not found for bcrypt@1.0.3 and node@8.11.1 (node-v57 ABI) (falling back to source compile with node-gyp)
<cjwatson> so it's probably just failing to pass proxy parameters to some bit of the build.
<popey> ah that url is 404
<cjwatson> (unless it's a real 404, which it could be.  but there's an "undefined" error earlier.)
<cjwatson> and then it loses its mind for many thousands of lines.
<popey> ahh that project has no armhf builds.
<popey> sorry for the noise.
<mup> Issue snapcraft#1886 closed: Support for yarn --extra-args <bug> <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1886>
 * zyga -> shopping, ttyl
<mup> PR snapcraft#2054 opened: tests: extract sources suite from general suite <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2054>
<popey> jdstrand: will you have time today to sort the aliases for ruby please?
<mup> PR snapcraft#2055 opened: python: bring back support for older versions of pip <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2055>
 * kalikiana wrapping up for the week
<jdstrand> popey: I can, sure. 7 days haven't passed...
<mup> PR snapd#5004 opened: daemon,overlord/hookstate: stop/wait for running hooks before closing the snapctl socket <Created by pedronis> <https://github.com/snapcore/snapd/pull/5004>
<mup> PR snapd#5005 opened: interfaces/hostname-control: allow setting the hostname via syscall and systemd <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5005>
<mup> PR snapd#5006 opened: interfaces: misc updates for default, firewall-control, fuse-support and process-control <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5006>
<mup> PR snapd#5007 opened: interfaces/desktop-legacy: allow access to gnome-shell screenshot/screencast <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5007>
<mup> PR snapd#5007 closed: interfaces/desktop-legacy: allow access to gnome-shell screenshot/screencast <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/5007>
<mup> PR snapd#5008 opened: interfaces: misc updates for default, firewall-control, fuse-support and process-control - 2.32 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5008>
<mup> PR snapcraft#2054 closed: tests: extract sources suite from general suite <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2054>
<mup> PR snapcraft#2056 opened: Fix formatting of some store errors <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/2056>
<mup> Issue snapcraft#1673 closed: Add pre-stage/stage/post-stage <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1673>
<mup> PR snapcraft#2049 closed: many: add override-stage scriptlet <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2049>
#snappy 2018-04-07
<mup> PR snapcraft#2057 opened: tests: extract lifecycle suite from general suite <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2057>
<mup> PR snapcraft#2057 closed: tests: extract lifecycle suite from general suite <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2057>
<mup> PR snapd#5009 opened: overlord: test fix, address corner case <Created by pedronis> <https://github.com/snapcore/snapd/pull/5009>
<mup> PR snapd#5009 closed: overlord: test fix, address corner case <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5009>
<mup> PR snapd#5010 opened: overlord: test fix, address corner case (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/5010>
 * zyga wonders who is responsible for ubuntu-image
<zyga> it doesn't work on 18.04 at all, GLIBC_PRIVATE not defined
<mup> PR snapd#5010 closed: overlord: test fix, address corner case (2.32) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5010>
<pedronis> zyga: you mean the snap
<pedronis> it's a bit unclear to me if the snap is maintained  (is still in only in beta)
<pedronis> it would be foundations though
<zyga> yeah, the snap
<zyga> the deb seems to work but it's not very user friendly
<pedronis> probably bootable bases / core18 work will be a good time to revisit/improve some of that
<mup> Issue snapcraft#1674 closed: Add pre-prime/prime/post-prime <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1674>
<mup> PR snapcraft#2052 closed: many: add override-prime scriptlet <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2052>
<mup> PR snapcraft#2051 closed: elf: use snapped strip <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2051>
<mr_lou> Hello
<mr_lou> Can one Snap talk with another Snap? I.e. if someone makes a Snap of a Java Runtime - will other Snaps then be able to utilize that JVM, resulting in Snaps that depend on Java to run?
<mr_lou> Currently, there's a Snap of VLC 3.0.1. And normally VLC can play Blu-ray's with full Java menus. But the Snap version can't, because it (obviously) needs Java in order to do that.
<om26er> mr_lou: that should be possible, I think there are other snaps that do that already
<mr_lou> Neat! Then all we need is a Snap of a Java runtime....
<om26er> mr_lou: yeah, if we have one, we can try and reduce the size of Android Studio snap as well
<mr_lou> Ah
<mr_lou> Makes sense.
<mr_lou> Although I gotta admit, I kinda like packages where the JVM is embedded.
<mr_lou> Especially in the case of VLC.
<mr_lou> Well, I only learned about Snap recently. Will take a while for me to figure out how to create a Snap...  Anyone else up for it? :-)
<mr_lou> Obviously, the bit version of the JVM will have to match the bit version of VLC.
<doko> are snapd's autopkg test a bit flaky on i386? see http://autopkgtest.ubuntu.com/packages/s/snapd/bionic/i386
<vidal72[m]> would snapd gracefully handle situation when system shutdown is trigered during snap refresh?
<om26er> mr_lou: if you could start a conversation on forum.snapcraft.io then we can figure out if there are "genuine" use cases for it. I'll probably work on that if there is enough interest.
<mr_lou> There's a genuine use case. But probably not many genuine use cases.
<mr_lou> I still think an embedded JVM would be best, but I can't convince VLC devs of that.
<mr_lou> A JVM to run BD-J would be less than 2 mb.
<mr_lou> That's virtually nothing in this age.
<mr_lou> I did read that you prefer people to use the forum. Sorry, I won't be doing that. Too damn many accounts everywhere.
<mr_lou> om26er, You know you're gonna do it anyway eventually. I can tell. Might as well do it now. ;-)
<mr_lou> Ohai r04r :-)
<mr_lou> r04r, I do believe this is the channel you were looking for. ;-)
<r04r> looks like it
<r04r> wonder why i didnt find it with alis
<r04r> is it not registered with chanserv or something
<mr_lou> Good question. I just did a channel search for snap
<r04r> oh
<r04r> +n
<r04r> no derp i mean -s
<r04r> which makes it hidden
<mr_lou> It's hidden?
<mr_lou> x-chat had no problem finding it.
<mup> PR snapcraft#2050 closed: storeapi: properly handle lacking permission for channel <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2050>
#snappy 2018-04-08
<Caelum> zyga: looks like package didn't get updated: https://build.opensuse.org/project/show/system:snappy
<eraserpencil> hey guys, are snaps architecture specific?
<eraserpencil> for example, I made a snap with  a x86_64 libs. would that snap run on an ARM machine?
<mr_lou> Logically no.
<eraserpencil> So if i ded want a snap to run on an arm architecture, I have to build it using the arm specific lib and dependencies?
<eraserpencil> ok
<mr_lou> I would think so. But I only found out about Snap recently, so I'm a noob.
<zyga> Caelum: Ill check
<zyga> eraserpencil: each package declares which architecture it is for
<zyga> But sure enough it is easy to build a package for each supported architecture
<zyga> Eg using build.snapcraft.io
<eraserpencil> Hey guys, I have a software in development that I'm hoping to test on a client side. Snaps will protect my source code right?
<Caelum> zyga: we need to do an osc rebuild for TW because it failed for some reason
<Caelum> zyga: x86_64 failed, this is the log: https://build.opensuse.org/package/live_build_log/system:snappy/snapd/openSUSE_Tumbleweed/x86_64
#snappy 2019-04-01
<mborzecki> morning
<zyga> Hello
<dot-tobias> good morning (not sure if last one went through)
<zyga> Iâm not well today. I had fever yesterday and I seem to have some sort of inflammation that is killing my back
<zyga> I will work from bed, skip on video calls
<zyga> Unfortunately I donât have my laptop this week so Iâll work from one of the old thinkpad I have at home.
<mborzecki> zyga: hey
<zyga> Hi
<zyga> Fedora 30 is my host today
<mup> Bug #1822535 opened: Unable to install apps via snapweb <Snappy:New> <https://launchpad.net/bugs/1822535>
<zyga> snapweb?
<zyga> darn, no token near bed
<zyga> mborzecki: how are you doing?
<zyga> mborzecki: can you do a few reviews please
<mborzecki> zyga: heh, caught cold, had a runny nose all weekend :/
<zyga> mborzecki: I have https://github.com/snapcore/snapd/pull/6643 that is now non-embargoed
<mup> PR #6643: tests: deny ioctl - TIOCSTI with garbage in high bits <Created by zyga> <https://github.com/snapcore/snapd/pull/6643>
<zyga> mborzecki: same here, I was rinding the bike at night and ended up sick
<mborzecki> zyga: will do, now trying to figure out why google-cloud-sdk breaks the tests
<zyga> thanks!
<zyga> I need to fetch my google sdk token
<zyga> mborzecki: I left my macbook for servicing :/
<zyga> perfect timing
<mborzecki> zyga: must be something funny, i removed google-cloud-sdk early in spread.yaml and still prepare failed
<mborzecki> zyga: saw your tweet, the keyboard right?
<zyga> mborzecki: can I be your garden gnome
<zyga> mborzecki: what is breaking and how do you think it is related to the sdk?
<zyga> mborzecki: yes, the space bar but mostly keys started repeating themselves
<zyga> mborzecki: the spacebar got stuck
 * zyga logged into lp.net
<mup> Bug #1822535 changed: Unable to install apps via snapweb <Snappy:Won't Fix> <https://launchpad.net/bugs/1822535>
<zyga> mvo: hello
<mvo> hey zyga
<zyga> mborzecki: so about those failures
<zyga> mborzecki: what do you know?
<mborzecki> mvo: morning
<mvo> hey mborzecki
<mvo> more failures?
<mborzecki> zyga: it breaks right after cache_snaps
<zyga> mborzecki: I know little about this, can you tell me like you would to a garden gnome
<mborzecki> haha garden gnome :P
<mvo> haha
 * mvo hugs zyga
<zyga> haha :)
<zyga> I'm sick today, sorry
<zyga> I'll work from bed
<zyga> riding at night was a bit silly in hindsight
<zyga> I had fever all yesterday
<mup> PR snapd#6667 opened: tests: enable tests that write /etc/{hostname,timezone} on core18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6667>
<zyga> today I'm better but my back is killing me, I cannot stand up normally
<zyga> mvo: ^ reviewed
<mvo> zyga: thank you
<zyga> mvo: I need some reviews
<mborzecki> mvo: you did look into this on friday didn't you?
<zyga> https://github.com/snapcore/snapd/pull/6597
<zyga> https://github.com/snapcore/snapd/pull/6502
<mup> PR #6597: cmd/snap-update-ns: refactor of profile application (1/N) <Created by zyga> <https://github.com/snapcore/snapd/pull/6597>
<mup> PR #6502: dirs,overlord/snapstate: add Soft and Hard refresh checks <Created by zyga> <https://github.com/snapcore/snapd/pull/6502>
<zyga> those two are most pressing
<zyga> both need a 2nd review
<mvo> zyga: looking at 6597 now
<mvo> zyga: whish me luck that I don't get distracted
<zyga> thank you, any reviews you do will help me a lot
<mborzecki> hmm it breaks earlier than i thought
<zyga> mborzecki: tell me more
<zyga> mborzecki: today I might to classic mount namespace behind a feature flag
<zyga> mborzecki: feels like something I want to do
<mborzecki> zyga: that'd be great, ping if you want to chat about it
<zyga> mborzecki: I will do the simple stuff for now, let's sync closer to standup to know more
<mborzecki> ok
<zyga> mborzecki: darn, fedora with 2.38 is not usable for snapcraft yet
<zyga> mborzecki: 2.39 will be selinux ok?
<mborzecki> zyga: try with multipass
<mborzecki> you'll probably need setenforce 0 for now too
<zyga> mborzecki: I was trying to build core81
<zyga> it doesn't work with multipass yet
<mborzecki> zyga: even if you force snapcraft to use multipass?
<zyga> not sure I know how to
<zyga> that's fine, I'll work on this now
<mborzecki> zyga: SNAPCRAFT_BUILD_ENVIRONMENT=multipass
<zyga> mborzecki: maybe 2.38.1 with fedora fixes should be made?
<pstolowski> mornings
<mvo> hey pstolowski
<zyga> pstolowski: hello :)
<mvo> zyga: I reviewed 6597, one of my comments is hidden under something marked as resolved
<mvo> zyga: not sure we it wasn't "unresolved" by the comment but oh well
<zyga> mvo: can you link to it please?
<zyga> I think I see it
<zyga> mvo: the answer to both questions: I didn't want to reorder patches, just split the big chunk in half
<zyga> I wanted to limit the possibility of breaking what used to work to to
<mvo> zyga: ok, lets merge and see what the second part of the PR brings
<zyga> mvo:you can see the rest, it's already on github
<zyga> though it needs more work now that some of the things here changed the interface a little
<mvo> zyga: oh, ok
 * mvo nods
<zyga> https://github.com/zyga/snapd/commits/feature/user-mount-ns-20.9-split
<zyga> e.g. this is the locking function https://github.com/zyga/snapd/commit/6525b925e6c3d299e6ce77a1885932c0ef0f2bef
<mborzecki> hmm, idk, looks like when removing snapd package we don't remove state.json for some reason
<mborzecki> though postrm has rm -rf /var/lib/snapd
<zyga> mborzecki: that's on purge
<zyga> mborzecki: perhaps purge vs remove?
<mborzecki> zyga: apt log shows we're doing --purge
<mborzecki> zyga: fwiw the mount units are stopped and removed
<zyga> odd
<mborzecki> heh, and out prepare project does: distro_purge_package snapd || true we won't notice if that fails
<zyga> fun
<zyga> mvo: can we postpone our 1-2-1? I don't have chrome here and I don't believe firefox on fedora even works with google meet
<mvo> zyga: sure, no problem
<mborzecki> zyga: mvo: https://paste.ubuntu.com/p/Q7f6wtG4mr/ hmm that's project prepare
<zyga> looking
<zyga> output status 100?
<zyga> why is that
<mvo> rm: cannot remove '/var/cache/snapd/aux': Is a directory
<mvo> fun
<mborzecki> heh
<mborzecki> yeah
<zyga> aha
<zyga> aux
<mvo> mborzecki: the same bug from last week
<zyga> mborzecki: reexec creates aux
<zyga> mborzecki: snapd postrm doesn't know about it
<zyga> mborzecki: we discussed this
<zyga> either reexec must create better postrm
<zyga> or postrm must be more rm -rf
<mvo> mborzecki: on what system do you see this? fwiw I just saw two PRs failing on 18.04
<zyga> either way
<mvo> zyga: yeah, postrm is fixed iirc
<mborzecki> mvo: 18.04
<mvo> zyga: just not in the older version
<mvo> mborzecki: looking
<mborzecki> ok, so maybe extra rm -rf /var/lib/snapd/ right after purge will be fine
<mvo> mborzecki: I am pushing a PR
<mborzecki> mvo: ok
<mup> PR snapd#6668 opened: tests: add workaround for missing cache reset on older snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/6668>
<zyga> mborzecki: classic mount namespace is interesting, somewhat more work than I thought
<zyga> because we need to use snap-update-ns there as well
<zyga> and we need to preserve the mount namespace
<zyga> it's progressing well but just wanted to highlight that it's more than I thought initially
<mborzecki> mvo: should we push out an update to 2.37 that does rm -rf /var/cache/snapd/* ?
<mborzecki> ll
<mborzecki> wrong window
 * zyga spawned tests and tries to make a coffee
<pedronis> zyga: hi, sorry you are sick, weren't there bugs to look into?  instead of starting on classic mountspace
<zyga> pedronis: yes, there are bugs to look at
<zyga> pedronis: perhaps I should work on those hmmm
<zyga> I wasn't thinking much in the morning, just wanted to something
<mvo> mborzecki: the rm -rf was added in feb so I think 2.37 already has it
<mvo> mborzecki: ha! it does not apparently
<mvo> mborzecki: yeah, that is unfortunate
<mborzecki> mvo: the version that was installed is 2.37.4
<mvo> mborzecki: indeed
<dot-tobias> ogra / zyga or someone else who knows: Am I correct in the assumption that only option to set a NTP time server is by overwriting /etc/systemd/timesyncd.conf (like in ogra's ntpcontrol example snap https://github.com/ogra1/ntpcontrol/blob/be16c59cc24d473f22baa89f534f993d553aa6aa/ntpcontrol#L33), and that the timeserver-control interface allows access to this file (https://github.com/snapcore/snapd/blob/71bdfa33d159509164b614e69d59d0b244db3c62
<dot-tobias> /interfaces/builtin/timeserver_control.go#L43)? I checked the timedated DBus docs and it doesn't look like there's a method to set a time server: https://www.freedesktop.org/wiki/Software/systemd/timedated/
<mvo> mborzecki: :/ that is annoiny, would have been easy to include in .4 if we were aware
<mborzecki> #6637 is green, can we land it even before postrm workaround?
<mup> PR #6637: interfaces: deal with the snapd snap correctly for apparmor 2.13 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6637>
<mborzecki> the spread job ran successfuly 4 days ago for that PR
<mvo> is it just me or is running snapd from inside cmd/snapd and ./snapd broken rught now?
<mborzecki> mvo: it is, due to snap-seccomp
<mvo> mborzecki: yeah, I noticed
<mborzecki> mvo: can you build snap-seccomp there too?
<mvo> mborzecki: is there a "fix" pending?
<mvo> mborzecki: I can symlink it
<mup> PR snapd#6637 closed: interfaces: deal with the snapd snap correctly for apparmor 2.13 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6637>
<mvo> mborzecki: no super strong opinion, its just my workflow, I can change it if we decide it not worth supporting running out of a git checkout
<mborzecki> mvo: i can look into it, but the last time i tried, the solution was rather fugly
<mvo> mborzecki: *nod*
<mvo> mborzecki: don't worry for now
<pedronis> mvo: mborzecki: wouldn't 6602 make it work  (assuming the system one does have version-info) ?
<mvo> pedronis: yeah, I was wondering the same
<mborzecki> yeah, that's the fugly solution as far as i'm concerned
<mvo> mborzecki: heh
<mborzecki> mvo: fwiw, 6602 could use a 2nd review :)
<mvo> pstolowski: I'm looking at 6660 right now, what can I do to get nested timings? just want to see what the output looks like
<mvo> mborzecki: yeah, its on my list which keeps growing instead of shrinking
<mvo> mborzecki: but I hope to get to it this morning
<zyga> pedronis: I'm adding tests for core -> core18 migration
<pstolowski> mvo: at the moment we only collect the new timings in ifacemgr around setting up profiles - see the output in the description of the PR; also we filter out those that are fast
<mborzecki> mvo: #6668 failed, looking at the log
<mvo> pstolowski: thank you, I will play around a bit with the output
<mvo> mborzecki: /o\
<mup> PR #6668: tests: add workaround for missing cache reset on older snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/6668>
<mborzecki> ah, ok, purge may fail if snapd is not installed on some distros
<mborzecki> mvo: i can take over this if you don't mind
<mborzecki> fwiw, ubuntu is the only distro that comes with snapd preinstalled
<mvo> mborzecki: go for it
<mborzecki> mvo: ack
<mvo> mborzecki: I did not add a purge, did I? I mean, my only change was to rm -rf the aux dir, no?
<mvo> mborzecki: so I'm confused how this breaks things - but I will wait for your PR :)
<mborzecki> mvo: you dropped || true from purge
<mvo> (or your push to it)
<mvo> mborzecki: silly me
<mvo> mborzecki: well, makes sense to drop it in some way because it masked the earlier error
<mvo> mborzecki: but yeah, that explains things :)
<mborzecki> that's fine, we expect it to succeed on system where it 'does' things
<mborzecki> btw. #6602 pick up wrong path libexecdir path on amazon for some reason
<mup> PR #6602: cmd,interfaces: replace local helpers with cmd.InternalToolPath <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6602>
<pedronis> mborzecki: doesn't that come dirs?  is the code always been buggy and we didn't notice?
<pedronis> *come from dirs
<mborzecki> pedronis: yes, that's from dirs, and it should be ok, /etc/os-release should check out as 'fedora'
<zyga> pedronis: so, sanity check question
<zyga> pedronis: what should happen when a snap changes base
<zyga> pedronis: should we force all apps to down
<zyga> pedronis: should we discard namespaces?
<zyga> pedronis: should we refuse (like in refresh app awareness work)?
<pedronis> zyga: when we have implemented app awareness we will have that, no?  so the questio is what we can do quickly to deal with the bug?
<zyga> pedronis: yes, we will
<mborzecki> mvo: pushed
<zyga> pedronis: perhaps we should discard the namespace when bases change
<zyga> pedronis: this would at least be less broken
<zyga> pedronis: when we have enduring services we should perhaps also discard the namespace
<pedronis> zyga: that's my thinking as well
<zyga> pedronis: to esure that apps run on top of the base they designated
<zyga> *ensure
<zyga> pedronis: I will get to it, thanks!
<mborzecki> heh that InternalToolPath is tricky
<mup> PR snapd#6669 opened: overlord/corecfg: make expiration of automatic snapshots configurable (4/4) <Created by stolowski> <https://github.com/snapcore/snapd/pull/6669>
<mborzecki> #6668 is green
<mup> PR #6668: tests: add workaround for missing cache reset on older snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/6668>
<mborzecki> mvo: can you take a quick look at that last patch I pushed?
<mvo> mborzecki: sure, was in a meeting
<mvo> mborzecki: but free now
<mvo> mborzecki: its *green*
 * mvo hugs mborzecki 
<mborzecki> yeah
<mvo> mborzecki: merged, I did not even look at it
<mvo> mborzecki: (ok, the last part of not true ;)
<mborzecki> haha fine :)
<mup> PR snapd#6668 closed: tests: add workaround for missing cache reset on older snapd <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6668>
<mvo> mborzecki: thanks for it and your change looks fine
<mborzecki> mvo: great!
<mborzecki> need to push a little fix for InternalToolPath, libexecdir is a mess to handle
<pstolowski> mvo, Chipaca thanks for the review of snap debug timings; i'm happy to tweak the output, perhaps pedronis wants to comment on this?
<zyga> mborzecki: hey selinux question
<mvo> pstolowski: yeah, if we don't find anything that appeals to everyone we should probably have a HO or something
<zyga> mborzecki: how can I relabel a binary done in make hack
<zyga> mborzecki: shall I restorecon?
<mborzecki> zyga: yes
<mborzecki> zyga: try restorecon -V <path>
<zyga> is it recursive?
<mborzecki> -V should be verbose
<mborzecki> -R
<mborzecki> or -v was verbose
<mup> PR snapd#6664 closed: cmd/snap,client,daemon,store: layout and sanity tweaks for find/search options <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6664>
<mup> PR snapd#6597 closed: cmd/snap-update-ns: refactor of profile application (1/N) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6597>
<zyga> mvo: thank you, I will prepare the next batch
<alan_g> ogra_, obviously you sometimes use vt.handoff. So does this make sense for mir-kiosk? https://github.com/MirServer/mir-kiosk/pull/26
<mup> PR MirServer/mir-kiosk#26: Workaround for Mir not starting if the gadget snap sets 'vt.handoff' <Created by AlanGriffiths> <https://github.com/MirServer/mir-kiosk/pull/26>
<mvo> zyga: ta
<zyga> pedronis: I've implemented the discard, it works ok, I will add some missing unit tests for new C code and send the patches
<pedronis> zyga: thx
<mborzecki> no suitable *util package to put normalizeYamlValue in
<mborzecki> yamlutil?
<pedronis> mborzecki: is this because of making gadget a package?
<mborzecki> pedronis: yes
<mborzecki> pedronis: we have jsonutil, so yamlutil isn't that bad
<pedronis> mborzecki: yes, though jsontuil is already border line, it has two functions in it
<pedronis> mborzecki: also is the first time I notice netutil,  why was it not called nmutil ?
<mborzecki> pedronis: in case there are ways to get the metered status from other sources than nm
 * Chipaca wanders off in search of sustenance
<pedronis> mborzecki: I see, the problem is that current name make it sounds a companion to the go net package
<pedronis> mborzecki: anyway  I would prefer to call the new package  metautil,  with some description about utilities for working with snap metadata
<mborzecki> ack, metautil sounds ok
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6670
<mup> PR #6670: tweak: fix "make hack" on Fedora <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6670>
<mup> PR snapd#6670 opened: tweak: fix "make hack" on Fedora <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6670>
 * zyga runs one more test before proposing the fixes
<mup> PR snapd#6671 opened: cmd,tests: forcibly discard mount namespace when bases change <Created by zyga> <https://github.com/snapcore/snapd/pull/6671>
<mborzecki> off to pick up the kids
<zyga> ondra, Saviq: ^ one of the core16 -> core18 issues that affects you
<ondra> zyga yeah! o/
<zyga> please have a look at the spread test in the PR for details
<zyga> d'oh
<zyga> that's the stale test before the fix :D
 * zyga looks at git status
<zyga> mborzecki: ./spread-shellcheck:120: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
<pedronis> pstolowski: I left a high-level comment in #6660
<mup> PR #6660: [RFC] cmd/debug: integrate new task timings with "snap debug timings" <Created by stolowski> <https://github.com/snapcore/snapd/pull/6660>
<pstolowski> pedronis: yes i saw it, thanks!
 * zyga goes to the standup
<zyga> oh
<zyga> standup is in one hour
<zyga> :D
<zyga> time changed again
<mborzecki> hm?
<mborzecki> drat
<mborzecki> can we move that to 2pm or 3pm like it was before?
<zyga> I'd prefer that
<zyga> mvo: ^
<Chipaca> zyga: mborzecki: person to check with is cachio
<Chipaca> and cmatsuoka
<mvo> zyga: in a meeting
<mvo> mborzecki: what is missing on 6634 ? can this land?
<mborzecki> mvo: is it green now?
<mvo> zyga, mborzecki, Chipaca my plan was to discuss meeting time in the standup in 51 min :)
<mvo> mborzecki: I think it is
<mborzecki> ah, perfect, landing it
<mvo> mborzecki: \o/
<mup> PR snapd#6634 closed: snap: add validation of gadget.yaml <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6634>
<ogra> alan_g, well, i'm fine doing a kiosk specific gadget for that ... so dont worry about me
<Chipaca> zyga: https://i.imgur.com/98wirsn.jpg
<zyga> Chipaca: little blue men
<alan_g> ogra, I wasn't so much worrying about you, but wanting your opinion of avoiding the potential problem this way. (Before someone out there hits it and get confused.)
<sergiusens> mvo: hey there, can you comment on https://forum.snapcraft.io/t/snap-try-messaging-and-user-experience/10667 ?
<mvo> sergiusens: sure, looking
<mvo> sergiusens: I like the first part of your comment already :)
<mup> PR snapd#6670 closed: tweak: fix "make hack" on Fedora <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6670>
<sergiusens> mvo: thanks, will be looking forward to the feedback there :-)
<cmatsuoka> zyga, mborzecki: that's 3pm in what timezone?
<zyga> cmatsuoka: CET
<zyga> I suspect
<zyga> whoever created the event "carries" it with the timezone they inhabit
<cmatsuoka> so is it UTC+2 i believe?
<mvo> pstolowski: thanks for 6660 - <3
<cmatsuoka> I'm in UTC-3, so that would be... 10am here, one hour earlier than the regular 11am
<cmatsuoka> I would have to change one meeting, but that's feasible
<pstolowski> mvo: sure, thanks for the ideas
<mborzecki> cmatsuoka: hm isn't there a time change in your location too within the next 2 weeks or so?
<cmatsuoka> mborzecki: the last one was a few weeks ago with end of daylight saving time
<cmatsuoka> mborzecki: we went from UTC-2 to UTC-3
<cmatsuoka> I believe cachio is in UTC-4 now?
<cachio> cmatsuoka, I am in UTC-3
<cachio> but we don't change time
<mborzecki> wow, that sounds like uber mess :P
<mborzecki> afaik in 2021 we also stop changing tz
<mborzecki> well not tz, just time
<cmatsuoka> there are some talks about stopping it here as well
<ogra> alan_g, well, the vt_handoff simply hides the text (in case there is no boot splash) by forcing a tty switch to a definitely black tty
<ogra> if you havent seen any scrolling text and if mir did start fine, we're good i think
<alan_g> ogra, what happens today on RPi3 isn't fine: i.e. Mir doesn't start.
<alan_g> I know I've a PR up that will fix it (once the image updates) but it seems fragile.
<ogra> alan_g, you mean mir doesnt start even if you remove the vt.handoff ?
<ogra> i thought that was your issue
<alan_g> ogra, yes, removing it does avoid the problem (that's the PR).
<ogra> alan_g, right ... and if the splash still works fine and you dont all of a sudden see scrolling text then we're good
<alan_g> So you don think I should be concerned about someone adding vt.handoff (or using Mir on the current RPi image)?
<ogra> i was told by vorlon a while ago that vt.handoff= would be deprecated anyway in the main distro so i think its not a bad move to drop it if you pdont see regressions
<mup> PR snapd#6672 opened: metautil, snap: extract yaml value normalization to a helper package <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6672>
<__chip__> pstolowski: is #1802339 addressed as part of your timing work, or is that for later?
<mup> Bug #1802339: Tasks should carry separate timestamps for undo paths <snapd:Confirmed> <https://launchpad.net/bugs/1802339>
<pstolowski> __chip__: for later, it is something else and not directly useful for timings. we're interested in durations and we have them for do and undo already
 * zyga iterates on tricks that speed up local spread qemu runs
<Chipaca> degville: do you have the 'this is work in progress' block for docs somewhere handy?
<zyga> Chipaca: question for you sir, could we move /var/lib/snapd/cache to /var/cache/snapd/
<Chipaca> zyga: what for?
<niemeyer> Hello snappyers
<Chipaca> zyga: I think it'd be a bad idea :-)
<niemeyer> (see what I did there, Chipaca)
<Chipaca> niemeyer: hiya
<zyga> Chipaca: why?
<Chipaca> niemeyer: I did, I did
<Chipaca> niemeyer: I approve
<niemeyer> :)
<niemeyer> I'm pretty much done with go-yaml v3
<niemeyer> Are there any pet peeves that you'd like me to look into before I put it in the wild and need to hold compatibility
<niemeyer> ?
<Chipaca> niemeyer: lest I refer you to https://www.urbandictionary.com/define.php?term=snapper
<Chipaca> niemeyer: whitespace control!
<niemeyer> Chipaca: Indentation?  Is in
<Chipaca> niemeyer: hmm... will that let me align the values in a map output?
<niemeyer> Chipaca: Hmm.. probably not
<niemeyer> Chipaca: No it won't
<niemeyer> Chipaca: I think that'll need some extra fiddling
<Chipaca> niemeyer: can I tell it to use "\t" for indentation, and then have it write to a tabwriter?
<Chipaca> zyga: in particular I think it's a bad idea because we depend on being able to hardlink things from var/lib/snapd/cache to var/lib/snapd/snaps
<niemeyer> Chipaca: No, as that's the \t makes for invalid yaml.. :(
<Chipaca> zyga: if those are on different volumes we lose
<zyga> Chipaca: mmm
<niemeyer> Chipaca: I think the map alignment would be a nice stock feature
<zyga> Chipaca: it's not that the current directory prevents that from happening
<niemeyer> Chipaca: And *probably* not hard
<niemeyer> Chipaca: There's already good "what column am I in?" control in the encoder
<Chipaca> nice
<niemeyer> Chipaca: It's also easy to do in a compatible way, so not a blocker for v3
<niemeyer> Chipaca: The indentation piece is in
<Chipaca> niemeyer: ð
 * zyga lunch
<Chipaca> zyga: you misspelled "dinner"
<roadmr> use the common galactic spelling: omnomnom
<Chipaca> roadmr: is that a pokÃ©mon
<Chipaca> roadmr: i think it's one of these https://deathbulge.com/comics/343
<roadmr> hehe :) maybe!
<zyga> Chipaca: it's not dinner if I only had breakfast but ... yeah
 * cachio lunch
<mup> PR snapd#6663 closed: cmd: make fmt <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6663>
<mup> PR snapd#6671 closed: cmd,tests: forcibly discard mount namespace when bases change <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6671>
<zyga> heh
<zyga> I have a file that indent is not stable on
<zyga> you run indent, you get a change
<zyga> you run indent
<zyga> you get ... another change
<zyga> you run indent
<zyga> you are back to 1st change
<zyga> and so on
<mup> PR snapd#6673 opened: cmd,tests: forcibly discard mount namespace when bases change <Created by zyga> <https://github.com/snapcore/snapd/pull/6673>
 * zyga is preparing some timing data for before/after speed-up patches for spread
 * Chipaca EODs
<zyga> Chipaca: I still didn't have that lunch
<zyga> but I guess it should be dinner now
 * Chipaca EODs even harder
<Chipaca> zyga: I'm going to go make pascualina
<Chipaca> zyga: I could post you some
<zyga> I will probably look at what I can find in the kitchen
<zyga> Chipaca: about that cache directory, I know it's hard but I think we should rethink that, not urgent
<zyga> Chipaca: I have some ideas on how to make things faster and it is simpler with that
<Chipaca> zyga: tomorrow
<zyga> Chipaca: one last question
<Chipaca> because, EOD
<Chipaca> zyga: go on
<zyga> Chipaca: is there a query I can do to tell me snap name for a hash we keep in the cache?
<Chipaca> zyga: snap info
<zyga> snap info ... what?
<zyga> on the file?
<Chipaca> zyga: yes
<zyga> ah, super
<zyga> thanks!
<zyga> enjoy your evening :)
<Chipaca> zyga: sudo snap info because 0600
<Chipaca> but yes
<Chipaca> o/
<popey> jdstrand: hi. i have a snap which tries to access /dev/shm/ring-buffer-foo, which fails in strict confinement, and works in devmode. Is patching the upstream source the only option?
<jdstrand> popey: hey, snapcraft-preload might also work
 * popey tries snapcraft-preload
<popey> :)
<mup> PR snapcraft#2444 closed: snap: move to core18 <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2444>
<popey> jdstrand: snapcraft-preload breaks more than it fixes.
<popey>     command: snapcraft-preload  desktop-launch $SNAP/b2
<popey> wonder if I need desktop-launch before snapcraft-preload
<mup> PR snapcraft#2445 closed: Add core18 support to dotnet plugin <Created by ed10vi> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2445>
<mup> PR snapcraft#2504 closed: cli: validate plugin schema before provider <Created by cmatsuoka> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2504>
<jdstrand> popey: I think the ordering is important, yes. I think one of the two parts mentions which should be first
<mup> PR snapcraft#2463 closed: Pass --work-dir param for out-of-tree builds <Created by abitrolly> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2463>
<mup> PR snapcraft#1649 closed: add stage/usr/local/lib to cmake library path <Created by diddledan> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1649>
<mup> PR snapcraft#1875 closed: Remove deprecated 'snap' recommendation <Created by ted-gould> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1875>
<mup> PR snapcraft#2020 closed: elf: set no-default-lib for all elf files if patching <bug> <enhancement> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2020>
<mup> PR snapcraft#2493 closed: cli: specify default expiration for export-login <Created by felicianotech> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2493>
<popey> jdstrand: yes, changing order fixed the new problem, but doesn't sort the /dev/shm/ring-buffer issue :(
<zyga> mvo: https://github.com/snapcore/snapd/pull/6674 :)
<mup> PR #6674: tests: use apt via eatmydata <Created by zyga> <https://github.com/snapcore/snapd/pull/6674>
<mup> PR snapd#6674 opened: tests: use apt via eatmydata <Created by zyga> <https://github.com/snapcore/snapd/pull/6674>
<mup> PR snapcraft#2135 closed: Add gradle support for task other than just 'jar' <Created by bsutton> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2135>
<popey> jdstrand: worked around the issue by disabling some features in the upstream code
<zyga> jdstrand: ello
<mup> PR snapd#6675 opened: cmd/snap-confine: allow using tools from snapd snap <Created by zyga> <https://github.com/snapcore/snapd/pull/6675>
<zyga> jdstrand: could you please look quickly at https://github.com/snapcore/snapd/pull/6675
<mup> PR #6675: cmd/snap-confine: allow using tools from snapd snap <Created by zyga> <https://github.com/snapcore/snapd/pull/6675>
<zyga> jdstrand: it's a two line change to s-c apparmor profile
<zyga> jdstrand: I need it for another fix as a prerequisite
<jdstrand> zyga: hey, done
<zyga> jdstrand: thank you!
<zyga> jdstrand: how are you doing btw? :)
<jdstrand> zyga: I'm ok. I actually think I'm coming down with something. the daemon user work as progressed a bit. still a bit more to do
<jdstrand> zyga: how are you?
<zyga> jdstrand: I had a cold and fever yesterday; I kept pushing myself all last week doing biking after dark when it was getting too cold
<zyga> jdstrand: I'm better today though I will take this week slowly
<jdstrand> zyga: hope you feel all better soon
<zyga> jdstrand: I'm progressing on refresh app awareness
<jdstrand> nice
<zyga> jdstrand: though this week is mostly bugfixes fore core18 and mount related things
<zyga> jdstrand: I took a stab at classic confinement mount namespace and I have a better understanding of what is required, I will try to do that after the bugfix weke
<zyga> *week
<zyga> jdstrand: I'll be EODing soon, ttyl! :)
<zyga> thank you for the quick review!
<cachio> but we don't change time
<popey> jamesh: hello. should gtk2 themes work as expected in https://forum.snapcraft.io/t/improving-theme-support-for-gtk-2-apps/7693
<popey> https://usercontent.irccloud-cdn.com/file/Uu05iOmL/Screenshot_20190401_213955-2.png
<popey> Mine still looks like a gtk2 app from the past
<popey> https://paste.ubuntu.com/p/89rw9srv8H/ is my yaml
<popey> gtk-common-themes:gtk-2-themes gtk-common-themes:icon-themes gtk2-common-themes:gtk-2-engines are all connected
#snappy 2019-04-02
<jamesh> popey: the gtk-2-themes content interface should connect to the gtk-common-themes snap: not gtk2-common-themes
<mborzecki> morning
<mup> PR snapd#6602 closed: cmd,interfaces: replace local helpers with cmd.InternalToolPath <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6602>
<zyga> good morning
<zyga> mborzecki: I sent some goodie last night
<mborzecki> zyga: hey, morning
<zyga> obviously red
<zyga> eh
<zyga> https://github.com/snapcore/snapd/pull/6674
<mup> PR #6674: tests: use apt via eatmydata <Created by zyga> <https://github.com/snapcore/snapd/pull/6674>
<zyga> hmm, I will need to look
<zyga> I install eatmydata but ... somehow not?
<zyga> not sure
<zyga> mborzecki: offtopic, I need a review for https://github.com/snapcore/snapd/pull/6675 - 2 lines of changes in code
<mup> PR #6675: cmd/snap-confine: allow using tools from snapd snap <Created by zyga> <https://github.com/snapcore/snapd/pull/6675>
<mborzecki> wonder why it doesn't work on debian
<mborzecki> eatmydata should end up in $PATH, not sure why the tests are getting eatmydata: command not found
<mborzecki> meanwhile, one of selinux branches is hitting this: https://paste.ubuntu.com/p/kZkFvkGzyp/ somehow there's a file named 'foo' that ended up as unlabeled_t
<mborzecki> anyone https://github.com/snapcore/snapd/pull/6654 ?
<mup> PR #6654: packaging/fedora, tests/upgrade/basic: patch existing mount units with SELinux context on upgrade <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6654>
<zyga> I will review shortly
<zyga> doing now
<mup> PR snapd#6675 closed: cmd/snap-confine: allow using tools from snapd snap <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6675>
<mvo_> zyga: hey, good morning - nice job on the eatmydata branch
<zyga> hey
<zyga> it doesn't pass yet
<zyga> something wonky on debian
<mvo_> zyga: unrelated I suppose?
<zyga> I'm reviewing maciej's branch and will get back to it
<zyga> mvo_: related!, eatmydata is not on path somehow?
<zyga> I will debug shortly
<mvo_> oh, interessting
<zyga> mvo_: I used qemu all day yesterday, I have several more speed-up patches
<zyga> mvo_: but providing quantitative data takes time so it will be a while for the next round
<mvo_> zyga: ok
<zyga> mborzecki: reviewed
<zyga> mvo_: can you please look at https://github.com/snapcore/snapd/pull/6673
<mup> PR #6673: cmd,tests: forcibly discard mount namespace when bases change <Created by zyga> <https://github.com/snapcore/snapd/pull/6673>
<zyga> mvo_: mainly to decide if the algorithm makes sense
<zyga> mvo_: or if we should do something entirely different
<mvo_> zyga: yeah, I look in a wee bit, just looking at a bugreport about a potential mem leak
<zyga> ooo
<mborzecki> zyga: thanks
<mborzecki> mvo_: morning
<mvo_> hey mborzecki
<zyga> mvo_: https://github.com/snapcore/snapd/pull/6667 is +2 and green
<mup> PR #6667: tests: enable tests that write /etc/{hostname,timezone} on core18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6667>
<mvo_> zyga: I will comment, we probably want to wait with this until the sru is officially released
<pstolowski> mornings
<zyga> good morning pawel
<mvo_> pstolowski: hey, good morning
<zyga> https://travis-ci.org/snapcore/snapd/jobs/514525874
<zyga> WAT?
<zyga> ../../../golang.org/x/sys/unix/zsyscall_darwin_amd64.1_11.go:687:22: undefined: SYS_CLOCK_GETTIME
<zyga> that's a darwin build
<zyga> did go just broke on us?
<pstolowski> zyga: i hit something similiar with golang on Mac recently; some x/sys/unix stuff needed `go get`
<zyga> hmm?
<zyga> are you saying you had to update the version of something or ... ?
<zyga> can you rephrase please
<pstolowski> zyga: i had to manually pull some x/sys packages on mac as apparently they were not shipped with default installation of go; that was a few months ago though when i first installed go on mac, don't remember the details
<mborzecki> anyone up for a simple review https://github.com/snapcore/snapd/pull/6672 ?
<mup> PR #6672: metautil, snap: extract yaml value normalization to a helper package <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6672>
<mborzecki> pedronis: btw. ^^^ use metautil pacakge name you suggested
<pedronis> mborzecki: thx, will look in  aibt
<pedronis> *a bit
<mborzecki> pedronis: thanks!
 * zyga -> coffee, sorry still sleepy somehow
<mvo_> mborzecki: hey, if you have some spare cycles it would be great if you could have a look athttps://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1822738
<mup> Bug #1822738: memleak in 2.38+ ? <snapd (Ubuntu):New> <https://launchpad.net/bugs/1822738>
<mborzecki> ../../../golang.org/x/sys/unix/zsyscall_darwin_amd64.1_11.go:687:22: undefined: SYS_CLOCK_GETTIME heh, what zyga pasted before
<mborzecki> anything we can do about that?
<pedronis> mborzecki: stubbing usually, but what new code bring that in?
<mborzecki> pedronis: looks like it's from golang.org/x/sys/unix
<pedronis> but it's new?
<mborzecki> and comes up when go getting it
<mborzecki> we didn't see it yday
<pedronis> yea, so it's new
<pedronis> anyway Chipaca was the last one untangling that stuff
<pedronis> he might be able to help
 * pedronis quick errands
<mborzecki> hm govendor lists /x/sys/unix as external dep, we don't pin it to a specific revision
<mborzecki> haha the last commit there is titled: 'unix: add SysctlClockinfo on darwin'
<mvo_> :P
<mup> PR snapd#6676 opened: travis: use Go 1.11 os OSX <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6676>
<dot-tobias>  hello everyone
<mborzecki> let's see if 6676 helps
<zyga> mborzecki: there is no SYS_CLOCK_GETTIME on macos
<zyga> unless it is coming in a unreleased beta
<mborzecki> sounds like we should pin /x/sys/unix
<mborzecki> and it doesn't work
<mborzecki> zyga: that's the change in /x/sys/unix https://go-review.googlesource.com/c/sys/+/170297
<zyga> looking
<zyga> too bad it's not really explained
<zyga> there's no SYS_CLOCK_GETTIME on any file in my macos install
<zyga> (as spotlight can tell me in a fraction of a second)
<mborzecki> heh, the change landed just today morning
<zyga> I bet it must be coming from a test system with macos 10.15
<zyga> https://go-review.googlesource.com/c/sys/+/170297
<zyga> I left a comment
<Chipaca> mvo_: pedronis: http://paste.ubuntu.com/p/yZkPWJ3FmH/ â add this to snapd to test the memleak?
<mvo_> Chipaca: nice one
<Chipaca> er
<Chipaca> nil, not nul, but you get the idea
<mup> PR snapd#6677 opened: vendor: pin golang.org/x/sys/unix to a revision before SYS_CLOCK_GETTIME on OSX <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6677>
<mborzecki> ok, maybe 6677 will get us somewhere
<mup> PR snapd#6676 closed: travis: use Go 1.11 on OSX <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/6676>
<zyga> mborzecki: ha
<zyga> https://go-review.googlesource.com/c/sys/+/170297
<mborzecki> zyga: hm?
<zyga> mborzecki: ^
<zyga> ^_^
<mborzecki> nice
<zyga> I really like this about software
<zyga> this would take a week conf call to untangle otherwise
<zyga> https://go-review.googlesource.com/c/sys/+/170297
<zyga> https://go-review.googlesource.com/c/sys/+/170299/ sorry
<Chipaca> zyga: mborzecki: what broke that's needing the pin?
<Chipaca> ah
<mborzecki> Chipaca: golang.org/x/sys/unix ^^
<zyga> it's almost solved now
<Chipaca> somebody broke darwin i see :-)
<zyga> mborzecki: I approved the fix in go now
<zyga> perhaps it will land in a moment and we can just rebuild
<zyga> it's funny that ..
<zyga> you know
<zyga> there's no CI that failed on this before
<zyga> just saying
<zyga> snapd ci is better than go's apparently ;)
<mborzecki> maybe the don't care about darwin that much
<mborzecki> crowdsourcing the CI effectively
<Chipaca> before you get your hubris wound up, remember these interactions are tricky to get right
<zyga> hmm?
<zyga> go test on the tree picks this up
<Chipaca> on which tree?
<zyga> sys/unix
<zyga> it just doesn't compile now
<Chipaca> pedronis: what's a good message/code combo for 'hook present, did not fail, but did not call snapctl set-health'?
<pedronis> Chipaca: I'm not entirely sure we should set those
<Chipaca> pedronis: just leave it at "unknown"?
<pedronis> for a start
<ogra> ogra@anubis:~$ snap install freecad
<ogra> error: snap "freecad" not found
<ogra> HMMMM ...
 * ogra looks at https://snapcraft.io/freecad ... 
<ogra> (i can install other snaps ... why not this one ?)
<ogra> interestingly snap info freecad doesnt work either for me ...
<zyga> my laptop got fixed
<zyga> I will go and fetch it soon
<ogra> hmm, interesting ... doesnt work on my laptop either
<pedronis> Chipaca: the other option is to set the code to something like snapd-hook-run or snapd-hook-ran
<Chipaca> pedronis: snapd-hook-is-full-of-it
<Chipaca> pedronis: snapd-hook-was-silly-banana
<Chipaca> :-)
<Chipaca> pedronis: I'd rather set it to something so we can tell the cases apart, yes
<Chipaca> pedronis: but i'm not too bothered if you'd rather wait on that
<mup> PR snapd#6678 opened: cmd/snap, api: use DebugGet for timings <Created by stolowski> <https://github.com/snapcore/snapd/pull/6678>
<mborzecki> so if the host is short on memory to start with, snapd takes around snapd-binary-size + whatever runtime alloces, running 'snap foo' is making the situation even worse, because that'll load up another snap-binary-size blob into memory
<mborzecki> snapd is ~20M here, snap ~15M that's 35M+ to run snap refresh, not mentioning the runtime stuff
<pstolowski> Chipaca: addressed your suggestion from timings review in #6678
<mup> PR #6678: cmd/snap, api: use DebugGet for timings <Created by stolowski> <https://github.com/snapcore/snapd/pull/6678>
<Chipaca> pstolowski: why 24 commits in that?
<pstolowski> Chipaca: because it depends on the other PR
<pedronis> mborzecki: 6672 looks good, I would add a package doc comment though, made a suggestion.
<pstolowski> Chipaca: it's really this: https://github.com/snapcore/snapd/pull/6678/commits/ef29d5563f677e0943088369fe92ad8b73bad867
<mup> PR #6678: cmd/snap, api: use DebugGet for timings <Created by stolowski> <https://github.com/snapcore/snapd/pull/6678>
<mborzecki> pedronis: thanks
<Chipaca> pstolowski: my last comment was because you don't really need the url key to have the right name
<Chipaca> pstolowski: GET /v2/debug?aspect=change-timings&arg=<chg id> works just as well
<Chipaca> pstolowski: in fact I'm starting to prefer it to the other more magical one :-)
<mborzecki> Chipaca: do you happen to have the package size breakdown graph for 'snap' too?
<Chipaca> mborzecki: yes
<Chipaca> mborzecki: read the message again
<mborzecki> uhh ;) i'm getting blind
<Chipaca> mborzecki: 's ok, we'll get you a dog
<Chipaca> not a seeing eye dog, those are expensive
<pstolowski> Chipaca: ty, +1
<mborzecki> Chipaca: haha :)
<Chipaca> mborzecki: I'd like something like this but for the running thing
<Chipaca> not holding my breath for it though
<mborzecki> Chipaca: pprof maybe? though it'd be more live allocations
<mborzecki> had a PR that would expose a pprof endpoint over the api
<Chipaca> I just want to know how much RSS is added by just importing, say, godb
<mborzecki> ah, there was a thing for this
<Chipaca> s/godb/bolt/ i meant
 * Chipaca needs more coffee
 * zyga wonders why a particular test happens to behave in a particular way
<zyga> debugging galore
<mborzecki> Chipaca: https://paste.ubuntu.com/p/FFbYCRk68N/ though i had trouble with newer versions of go as they changed where *.a are placed and the naming, and the sizes don't add up correctly
<Chipaca> mborzecki: go clean -cache, and/or GODEBUG=gocacheverify=1 help with that?
<Chipaca> mborzecki: also the -a flag to go build
<mborzecki> Chipaca: i'd prefer to see a tool that's part of the go suite, which souds like an interesting little project itself
<mborzecki> Chipaca: there was a tool like this in busybox tree, but it used objdump and friends to analyze and produce a per symbol breakdown
<mborzecki> and it assumed one is using C obviously
<popey> jamesh: tried that, still get old school looking stuff. Is your forum post in need of updating. As it doesn'r work here.
<pedronis> mborzecki: Chipaca: put some notes of things you mentioned or I chatted about with mvo in the bug
<mborzecki> pedronis: i'm checking out some curl queries to put there
<pedronis> mborzecki: added one more obvious thing there
<uebera||> Hi. Should I just ignore #snappy, #snapframework or are they reserved for specific topics?
<uebera||> So, what's the easiest way (if any) to use /snap/core/current/usr/bin/gpg, presuming it's newer than the version shipped with Ubuntu Xenial?
<ogra> since the core snap is built from the ubuntu xenial archive, it wont be newer
<uebera||> ogra: I see. Thanks!
<pedronis> zyga: for clarity I commented on 6502 that keeping the two functions (Soft,Hard) matches how we discussed things and should be kept
<zyga> pedronis: I agree, thank you for clarifying that
<zyga> Apr 02 13:14:29 fyke kernel: snapcraftctl[7576]: segfault at 2d ip 00007fd0131e1681 sp 00007ffdc8e9fe20 error 4 in ld-2.28.so[7fd0131d8000+20000]
<zyga> Apr 02 13:14:29 fyke kernel: Code: 54 24 18 e8 71 72 00 00 4c 8b 54 24 18 85 c0 0f 85 d4 0a 00 00 0f 1f 40 00 48 83 c5 01 49 39 ea 0f 86 23 06 00 00 49 8b 04 ec <48> 8b 58 28 48 3b 9c 24 e8 00 00 00 74 e1 8b 34 24 85 f6 74 09 f6
<zyga> not my luckiest day
<Chipaca> wait, where has the morning gone
<Chipaca> staahp
<zyga> Chipaca: what? :)
<zyga> oh, making progress :)
<Chipaca> zyga: my morning vanished in a flurry of unproductive nonsense
<Chipaca> that's what :-/
<zyga> Chipaca: you didn't see my morning :)
<zyga> Chipaca: I'm stumbling blind around parts I'm clueless to
<zyga> trying to make some progress but slow at it
<mborzecki> damn, #6677 travis job failed, desktop-portal-filechooser
<mup> PR #6677: vendor: pin golang.org/x/sys/unix to a revision before SYS_CLOCK_GETTIME on OSX <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6677>
<pstolowski> can #6659 land?
<mup> PR #6659: snapcraft: build static fontconfig in the snapd snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/6659>
<pedronis> pstolowski: as such yes, but it needs work somewhere else, I'm not sure how mvo is tracking that
<pedronis> pstolowski: I would let mvo deal with it
<pstolowski> pedronis: ack.. i was trying to find something that can land.. our queue keeps growing
<mborzecki> revived my branch to expose pprof over snapd api
 * cmatsuoka wonders what "duplicate the fake tar sleeps" means
 * Chipaca reads the news and considers sending zyga a big box of harry potter books
<pedronis> mborzecki: commented in the bug that master has timings too, which 2.38 didn't have
<zyga> Chipaca: no need, I have plenty at home
<zyga> Chipaca: in both languages
<Chipaca> zyga: I'll send you an empty box (cheaper!), that says harry potter in big letters on the outside then
<zyga> Chipaca: it will be a magic box :)
<Chipaca> obvs
<zyga> Chipaca: it's a terrible world we live in but I think what happened is not representative of my broken country
<zyga> luckily
<Chipaca> zyga: I assumed as much
<Chipaca> zyga: if it were, it wouldn't be news i guess?
<Chipaca> smells like my lunch is ready, ttfn
<zyga> unfortunately wit the current government we cannot see a strong signal either
<zyga> I read that we should condemn that act, separate church and state more strongly and invite ms Rowing
<zyga> but alas, that's a dream in current days
<mborzecki> heap profile after running some install/remove cycles: https://gist.githubusercontent.com/bboozzoo/ea6dc44bae2816fbb07776aa9cd9f5fb/raw/616b1b7f888f4dfac1ab1c5c6953b2c9080865b4/pprof001.svg
<mborzecki> you'
<mborzecki> you'll probably need to open that with eog or sth similar
<mborzecki> idk why, but it doesn't load in ff as svg
<mborzecki> off to pick up the kids
<Chipaca> pprof001.svg:1930: parser error : Opening and ending tag mismatch: script line 7 and svg
<Chipaca> pprof001.svg:1930: parser error : Premature end of data in tag svg line 6
<Chipaca> mborzecki: ^
<Chipaca> mborzecki: that's from inkscape; google chrome says "error on line 1930 at column 12: Opening and ending tag mismatch: script line 0 and svg"
<Chipaca> mborzecki: (surprisingly similar errors â¦ :-) )
<Chipaca> mborzecki: emacs hates it and crahsed
<zyga> Chipaca: at least vim can open it and see text ;) (/me hides now)
<Chipaca> zyga: emacs is doing what all the cool people do, and brexiting
<zyga> hahahaha
<Chipaca> eog says
<Chipaca> (eog:22352): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
<Chipaca> This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
<Chipaca> The overwriting error message was: Error domain 1 code 76 on line 1930 column 12 of file:///tmp/pprof001.svg: Opening and ending tag mismatch: script line 0 and svg
<zyga> Chipaca: brexit the frog, waiting till the kettle boils
<mup> PR snapd#6679 opened: many: implement user removal <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/6679>
<jamesh> popey: sorry, was out earlier for an event.  Try the gtk2-demo snap from the store (edge channel): it is themed correctly for me, and relies on gtk-common-themes/gtk2-common-themes for the theme data and engines
<mup> PR snapcraft#2509 closed: build providers: initial support for LXD <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2509>
<mborzecki> Chipaca: hah, so the crash is reproducible then :)
<Chipaca> mborzecki: also, also, memory use is probably arch-dependent (esp wrt 32 vs 64 bits)
<Chipaca> gosh the ubuntu-core image from http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ is ancient
<Chipaca> mvo_: do you know what's up with that? ^
<Chipaca> mvo_: it comes with 2.33.1
<mvo_> Chipaca: probably best to check with foundations, iirc they have a different cadance now and only update core images on point releases of the distro. but given that these images are 8 month old maybe that is not a good policy anymore
<Chipaca> mvo_: also that site's a mess, there are images in the directory above 'current'
<mborzecki> hm should have dumped the svg directly from pprof
<mvo_> Chipaca: I put the update on the agenda for the meeting we have with foundations today
<Chipaca> ok
<mborzecki> Chipaca: idk if it's much better now https://gist.githubusercontent.com/bboozzoo/ea6dc44bae2816fbb07776aa9cd9f5fb/raw/c51c7ba5970dc25888832fea251178ab56dd2ba0/profile001.svg
<zyga> cmatsuoka: I reviewed https://github.com/snapcore/snapd/pull/6679
<mup> PR #6679: many: implement user removal <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/6679>
<Chipaca> mborzecki: much
<cmatsuoka> zyga: thanks, I'm reading it right now
<Chipaca> mborzecki: yeah the read state thing is yuge
<Chipaca> I could have some fun in there
<Chipaca> mvo_: I'm not seeing the OOMs on a i386 kvm with 256MB and no swap, fwiw
 * Chipaca tries to install nextcloud on it
<mvo_> Chipaca: oh, nice
<mvo_> mvo_: that is a great data point
<mvo_> Chipaca: -^
<Chipaca> nextcloud installed as well
<Chipaca> mvo_: i asked a few q's in the bug, about this
<Chipaca> now i need to go make tea before the standup
 * Chipaca runs
<zyga> uh
<zyga> so
<zyga> is there a video call URL today?
<zyga> I cannot seem to find one
<cmatsuoka> it seems that we don't have one
<degville> I can't find one either.
<zyga> let's use the one from last week
<zyga> https://hangouts.google.com/hangouts/_/canonical.com/snappy-devel
<degville> thanks zyga!
<diddledan> does that work for non canonicalites? just wondering whether sharing allows randoms to join your meeting :-p
<zyga> diddledan: it doesn't work, you need to be allowed to enter
<zyga> and we'd notice ;)
<diddledan> aha
<diddledan> teehee
 * diddledan covers the camera
<ogra> hmm, how do i use snap refresh ... --stable with a ansp using tracks ?
<ogra> *with a snap
<ogra> ogra@pocketbeagle:~$ snap list pc-kernel
<ogra> Name       Version       Rev  Tracking  Publisher   Notes
<ogra> pc-kernel  4.15.0-47.50  199  18/edge   canonicalâ  kernel
<ogra> ogra@pocketbeagle:~$ snap refresh pc-kernel --stable
<ogra> error: cannot refresh "pc-kernel": cannot switch from kernel track "18" as specified for the
<ogra>        (device) model to "stable"
<ogra> ogra@pocketbeagle:~$
<diddledan> "I'm typing all the right letters. not necessarily in the right order"
<ogra> yeah, i'm slowly becoming the king of dsylxeia :P
<diddledan> and yet, I read that correctly until I look closer
<ogra> haha
<diddledan> it's weird that you can often read words that are misspelt without thinking about it
<ogra> aand ... to answer myself ...
<ogra> snap switch pc-kernel --channel=18/stable && snap refresh pc-kernel
<diddledan> does `snap refresh --channel` work too?
<ogra> no idea, i refreshed to stable now ...
<ogra> bah ... and i notice i shouldnt have ... forgot that avahi has issues with that kernel
<ogra> ogra@pocketbeagle:~$ snap refresh --channel=18/edge pc-kernel
<ogra> Setup snap "pc-kernel" (199) security profiles
<ogra> seems to work
<__chip__> pedronis: would it be worth looking into always loading state on demand (as opposed to keeping it all in memory)? (all of it/ some of it (which?)/etc)
<__chip__> pedronis: we can use mmap + json stream decoding to bring down memory usage a lot for that, if we want
<__chip__> granted "a lot" is not going to be much bigger than state.json, but Â¯\_(ã)_/Â¯
<solkku> hello! I was wondering if there's a way to run a snap in the background on ubuntu server 18.04? now when I run it, it keeps giving me logs and I'm unable to use the terminal window for anything else
<mup> PR snapd#6680 opened: [RFC] daemon: expose pprof endpoints <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6680>
<mborzecki> mvo_: Chipaca: ^^ if you want to play with it
<mborzecki> i'll add some notes on how to set it up
<mborzecki> the pprof tools don't know about unix sockets, so a proxy is needed
<mvo_> mborzecki: nice one
<mborzecki> mvo_: fairly self contained, we could have it behind an env flag
<sil2100> Hey guys, I started noticing that the core18 CI started failing due to some snapd errors: https://travis-ci.org/snapcore/core18/jobs/512567447 <- for example here
<sil2100> "error: too early for operation, device not yet seeded or device model not acknowledged"
<sil2100> When travis is trying to do a snap install
<sil2100> We're using trusty for CI there, maybe I should try switching to xenial again?
<mvo_> sil2100: we might need to add an extra command to .travis.yml, something like "snap wait system seed.loaded"
<mvo_> sil2100: before snap install
<sil2100> mvo_: oh, sounds fancy
<sil2100> Will try that
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6677
<mup> PR #6677: vendor: pin golang.org/x/sys/unix to a revision before SYS_CLOCK_GETTIME on OSX <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6677>
<mvo_> sil2100: good luck
<mborzecki> zyga: hmm?
<mup> PR core18#124 opened: Switch travis CI to xenial, add a snap wait after installing snapd toâ¦ <Created by sil2100> <https://github.com/snapcore/core18/pull/124>
<zyga> mborzecki: the fix was merged upstream now
<zyga> mborzecki: I wanted to let you know
<mborzecki> ah, so maybe we can close it
<mborzecki> or keep it
<mborzecki> zyga: either way 6677 was timing out when running tests :/
<zyga> mborzecki: not our lucky day
<Chipaca> solkku: o/
<Chipaca> solkku: what do you mean?
<solkku> Chipaca: I'm trying to run the snap as a daemon/service, so it does it's thing in the background and I can use the terminal for other things. Also the snap only stays alive as long as the terminal window is open
<Chipaca> solkku: when you say 'the snap', you mean the app in the snap?
<Chipaca> solkku: what happens if you add 'daemon: simple' to your app in your snap?
<Chipaca> solkku: (with 'daemon: simple', it will be started automatically when you install the snap -- you can see it in 'snap services')
<solkku> Chipaca: I did "snap install sickgear", when I run it with "sudo sickgear" I get all kinds of logs: https://pastebin.com/61CgtWA9
<Chipaca> solkku: is sickgear your snap?
<mvo_> can we land 6660 btw? has two +1 afaict and everyone seems to be happy with the new UX
<Chipaca> solkku: or is it somebody else's?
<solkku> I can use "sudo sickgear &", but still get logs on screen once in a while :)
<solkku> Chipaca: it's a snap I found at snapcraft.io
<Chipaca> solkku: and is sickgear something that's meant to (a) run as root, and (b) run in the background ?
<mvo_> pedronis: was 6660 something you wanted to double check before it goes in? iirc yes but I'm not sure anymore
<Chipaca> solkku: looking at the website it seems to be a GUI app
<Chipaca> solkku: why would you run this as root? and why would you start it from the terminal?
<pedronis> mvo_: yes
<solkku> Chipaca: you can run it in the background if you install it the "old fashioned" way, but couldn't tell you about a or b
<pedronis> mvo_: I will get to those PRs by pstolowski today or tomorrow morning
<solkku> Chipaca: it starts a webserver and I access it via the web browser
<Chipaca> solkku: ohhh
<Chipaca> solkku: then maybe reach out to the sickgear people (file an issue?), tell them to make it a daemon
<Chipaca> solkku: if they need help, we're here (or forum.snapcraft.io)
<mup> PR core18#125 opened: hooks: create snapd directory skeleton <Created by zyga> <https://github.com/snapcore/core18/pull/125>
<mvo_> pstolowski: thanks, I added a tag
<solkku> I said to the maker of sickrage that I'm trying to run it as a daemon, but he just said that "no where in the documentation does it say to run like that" and "if you want to run like that, then you must take apart the /snap folder and reconstruct yourself".. so I guess I'm on my own and came here for help next :)
<zyga> solkku: you can create a systemd service that just runs the snap command
<solkku> Chipaca: when I try to run it as a daemon "sudo snap start --enable sickgear.daemon", I get: "error: snap "sickgear" has no service "daemon""
<zyga> solkku: you don't have to repackage the snap
<zyga> solkku: just install it and create a systemd unit that runs it as a service
<solkku> zyga: oh, is there a noob-friendly guide on this?
<zyga> not sure :) just systemd docs
<Chipaca> er
<Chipaca> solkku: yeah, if the developer doesn't think you should run it like that â¦ Â¯\_(ã)_/Â¯ maybe you shouldn't?
<solkku> Chipaca: maybe, but I'm going to try it my way first ;)
<MattJ> solkku, https://www.shellhacks.com/systemd-service-file-example/
<solkku> MattJ: thanks, seems to have worked!
<solkku> you learn something new every day
<cwayne> mvo_: sil2100: heya, should we setup a call re: beta gating for core18?
<mup> PR core18#124 closed: Switch travis CI to xenial, add a snap wait after installing snapd toâ¦ <Created by sil2100> <Merged by sil2100> <https://github.com/snapcore/core18/pull/124>
<zyga> sil2100: hi
<zyga> Could you please review https://github.com/snapcore/core18/pull/125
<mup> PR core18#125: hooks: create snapd directory skeleton <Created by zyga> <https://github.com/snapcore/core18/pull/125>
<sil2100> zyga: sure o/ It's a bit troublesome right now, since I can't do any test builds of the snap right now due to the archive slowness
<sil2100> zyga: so I guess it'll have to wait till tomorrow
 * sil2100 just tried building his own core18 snap but the archive was super slow and actually mismatching sizes
<sil2100> zyga: it's on my plate anyway o/
<zyga> sil2100: thank you
<mup> PR snapd#6681 opened: misc: support system-global-ids for 'daemon' user <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6681>
 * zyga EODs
<zyga> jdstrand: super nice, I will read in detail tomorrow
<zyga> jdstrand: there are some interactions with snap-confine changes I have in the pipe
<zyga> jdstrand: I will try to de-conflict it as things that are in progress are merged into master
<zyga> jdstrand: gentle ping about mointinfo fix https://github.com/snapcore/snapd/pull/6605
<mup> PR #6605: cmd/libsnap,osutil: fix parsing of mountinfo <Created by zyga> <https://github.com/snapcore/snapd/pull/6605>
<zyga> if you want I can merge as-is, you can always review post-factum later
<zyga> it has two reviews and is green already
<zyga> wow, today many things can get merged
<jdstrand> zyga: 6605 is on my list. now that the daemon user PR low-level technical details are worked through, I'm going through my inbox/todo/etc again, which that pr is in
 * jdstrand wonders if anyone uses the non-raw travis log in the snapd travis ci tests
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117
<mup> PR # closed: core18#43, core18#72, core18#90, core18#98, core18#120, core18#121, core18#122, core18#123, core18#125
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117
<mup> PR # opened: core18#43, core18#72, core18#90, core18#98, core18#120, core18#121, core18#122, core18#123, core18#125
#snappy 2019-04-03
<mborzecki> morning
<zyga> Hi
<mborzecki> zyga: hey
<zyga> How are you?
<mborzecki> zyga: are we goign to be equally unlucky today? i've restarted some travis jobs yesterday evening, and all are red :/
<zyga> Whaaat
<zyga> Why?
<zyga> What is failing?
<mborzecki> zyga: one failed with prepare image, another in go-build:s390x, the last one probably maanged to hit some mirror sync
<zyga> Eh
<zyga> Assorted bad luck
<mborzecki> zyga: prepare-image was probably some issue fetching snaps from the store
<zyga> Iâm with the dog, outside
<mborzecki> and the 4th job got 502 when pulling gopkg.in/yaml.v2 :P
<zyga> Is the store wonky today?
<mborzecki> feels like i should play some euro jackpot today
<zyga> Haha
<zyga> Nice
<zyga> Yesterday I learned that apple support should be split in two
<mborzecki> is #6667 waiting for something else?
<mup> PR #6667: tests: enable tests that write /etc/{hostname,timezone} on core18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6667>
<mborzecki> zyga: sup and port?
<zyga> 90% of the people came with a shattered phone
<zyga> That took forever
<zyga> Looking at 6667
<mborzecki> zyga: many people are clumsy then :)
<zyga> Hmm
<zyga> Maybe ok to land?
<mborzecki> #6659 can probably land too
<mup> PR #6659: snapcraft: build static fontconfig in the snapd snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/6659>
<zyga> Mvo will be around soon
<zyga> Yes
<zyga> +1 there
<mborzecki> there will be a followup but somewhere else in the code
<zyga> re
<zyga> back in the office
<mup> PR snapd#6502 closed: dirs,overlord/snapstate: add Soft and Hard refresh checks <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6502>
<zyga> eh, I feel even more sick than yesterday now
<zyga> mborzecki: can you please review https://github.com/snapcore/snapd/pull/6643
<mup> PR #6643: tests: deny ioctl - TIOCSTI with garbage in high bits <Created by zyga> <https://github.com/snapcore/snapd/pull/6643>
<zyga> it's something that should have landed weeks ago but was under embargo
<zyga> hello mvo
<mvo> zyga: good morning
<mborzecki> mvo: hey
<mvo> zyga: how are you? how is the testing situation?
<mvo> hey mborzecki
<mvo> mborzecki: anything on the suspected memleak?
<zyga> mvo: I have a running nose and something in my lungs :/ I probably will skip japanese classes today
<mborzecki> mvo: no, Chipaca asked some questions in the LP bug
<zyga> mvo: tests are grim, failing on assorted collection of random annoyances
<zyga> from network to more network to random stuff
<mvo> zyga: :(
<mvo> zyga: I saw that archive.u.c had some issues last evening
<mvo> mborzecki: cool, keen to learn what john figured out, I will check the bug
<mborzecki> zyga: mvo: do you use auditd and ausearch on ubuntu?
<zyga> no
<zyga> well
<zyga> auditd maybe
<zyga> but not ausearch
<mborzecki> ha
<mborzecki> ok
<mborzecki> so ausearch does not properly report denials from apparmor on arch, thought that ubuntu may carry some patches that fix that, but apparently not, doesn't work on ubuntu either
<mborzecki> so only uses has extra patches to fix that
<mborzecki> Malformed event skipped, rc=9. type=AVC msg=audit(1554271576.256:61): apparmor="DENIED" operation="open" profile="snap.hello-world.sh" name="/home/guest/" pid=13765 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
<mborzecki> that's what I see on ubuntu (and arch for that matter too) when runnig ausearch -m AVC --debug
<mborzecki> just ausearch -m AVC shows <no matches>
<mborzecki> i suggested name tweaks in #6656 but i'm not sure it's worth risking another travis run at this point, maybe we should just land it
<mup> PR #6656: tests: split travis spread execution in 2 jobs for ubuntu and non ubuntu systems <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6656>
<mup> PR snapd#6674 closed: tests: use apt via eatmydata <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6674>
<mborzecki> hm https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1117804
<mup> Bug #1117804: ausearch doesn't show AppArmor denial messages <apparmor> <AppArmor:Confirmed> <audit (Ubuntu):Confirmed> <linux (Ubuntu):Incomplete> <https://launchpad.net/bugs/1117804>
<zyga> 2014
<mborzecki> zyga: yeah, suse carries a patch that was submitted upstream, but then the discussion went to apparmor not using some common audit ids and thus being wrongly interpreted in userspace or sth
<mborzecki> zyga: oh, and suse patch just works aroudn that in the userspace parser :P
<zyga> kernel stuff is hard
<mup> PR snapd#6672 closed: metautil, snap: extract yaml value normalization to a helper package <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6672>
<mborzecki> ehh, opensuse this time: Some of the repositories have not been refreshed because of an error.
<mborzecki> mvo: zyga: what about #6677, do we want to keep golang.org/x/sys/unix pinned?
<mup> PR #6677: vendor: pin golang.org/x/sys/unix to a revision before SYS_CLOCK_GETTIME on OSX <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6677>
<mvo> mborzecki: now that things are fixed again upstream I would say we don't need to pin until the next issue like this? the risk of pinning is that stay behind forever and don't get e.g. security fixes
<zyga> mborzecki: I would unpin it
<mborzecki> mvo: zyga: ack, closed the PR
<zyga> because this gives us error visibility at the cost of ... well ... errors
<mup> PR snapd#6677 closed: vendor: pin golang.org/x/sys/unix to a revision before SYS_CLOCK_GETTIME on OSX <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/6677>
<mvo> thanks mborzecki
 * zyga prepares the next refresh app awareness batch
<zyga> not a big one, but functional one
<pedronis> mvo: hi,  need to decided what to do with #6659, follow up needs  to be tracked, and #6667 is green
<mup> PR #6659: snapcraft: build static fontconfig in the snapd snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/6659>
<mup> PR #6667: tests: enable tests that write /etc/{hostname,timezone} on core18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6667>
<pstolowski|afk> morning
<zyga> hey pedronis, hey pawel
<mborzecki> pstolowski: pedronis: hello guys
<pstolowski> pedronis: hey, #6665 has 2 +1s; would you like to take a look or can it land?
<mup> PR #6665: overlord/ifacestate: implement String() method of HotplugDeviceInfo for better logs/messages <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6665>
<pedronis> pstolowski: I need to take a look
<pstolowski> k
<pedronis> pstolowski: we don't use "<...>" style of representation anywhere so far
<pedronis> so I need to think a bit actually
<pstolowski> pedronis: ok; i think it'd make sense to somehow wrap this representation up as it's a bit long
<pedronis> pstolowski: yes, they are bit long; too long?
<pstolowski> pedronis: maybe; maybe vendor/model should be omitted
<pedronis> pstolowski: well model seems important,  are vendor usually that long?
<mup> PR core18#125 closed: hooks: create snapd directory skeleton <Created by zyga> <Merged by sil2100> <https://github.com/snapcore/core18/pull/125>
<pstolowski> pedronis: not really; but models can be long, three examples from my VM:
<pstolowski> ES1371/ES1373 / Creative Labs CT2518 (Audio PCI 64V/128/5200 / Creative CT4810/CT5803/CT5806 [Sound Blaster PCI])
<pstolowski> 82545EM Gigabit Ethernet Controller (Copper) (PRO/1000 MT Single Port Adapter)
<pstolowski> 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (LSI Logic Parallel SCSI Controller)
<pedronis> pstolowski: so model usually contains also the vendor name?
<pstolowski> pedronis: it seems so, we could get rid of vendor
<zyga> pedronis: usually the rules are: there are no rules :)
<pedronis> zyga: that's fine, we still need to do something reasonable and consistent with the rest of our code
<zyga> I totally agree
<pedronis> that PR is not there yet from my POV
<zyga> I think, while this may be odd, that a lookaside table (in the store perhaps) may be the best outcome
<zyga> for real usability
<pedronis> that is over ambitious considering were we are now :)
<zyga> is it? we can just reply with what is in the usb database already
<zyga> and we can fix ugly things one-by-one as encountered
<pedronis> zyga: ?
<zyga> I mean, it's not out of reach
<pedronis> zyga: what are you proposing?  (I'm missing something here, given that you mentioned the store)
<pedronis> zyga: I notice that you gave +1 to that PR without further comments
<zyga> pedronis: that using a simple solution now (no transformations) and planning to use the store for nice descriptions should be done
<pedronis> pstolowski: anyway the closest thing we have to this sort of display problem atm is this:  https://github.com/snapcore/snapd/blob/master/asserts/asserts.go#L196 (though assertions are much more structured than what we have here)
<pstolowski> zyga: #6605 has conflicts
<mup> PR #6605: cmd/libsnap,osutil: fix parsing of mountinfo <Created by zyga> <https://github.com/snapcore/snapd/pull/6605>
<pstolowski> pedronis: yes, in fact i was looking at assertions for inspiration ;)
<mborzecki> pstolowski: you could skip serial for sure
<mborzecki> devpath can be quite long usually since, but devname is preferred anyway
<zyga> pstolowski: I know, waiting for a review from Jamie though
<pedronis> he said he should be back reviewing things, now that he draft the daemon user stuff
<pedronis> *drafted
<mborzecki> heh fedora 30 beta released, fedora repos back to the usual not-responding-when-release mode
<pstolowski> :)
<mwhudson> we just get that when we release kernels
<mup> PR snapd#6682 opened: snap, gadget: move gadget read/validation into separate package, tweak naming <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6682>
<mborzecki> pedronis: mvo: gadget package split ^^
<mvo> mborzecki: nice, I have a look
<mborzecki> mvo: twekaed the naming too, so snap.GadgetSize is now gadget.Size and such
<mborzecki> aaand damn go 1.9 fmt
<mvo> mborzecki: nice
<mborzecki> hope this lands soon
<mvo> mborzecki: yeah, it will be a massive source of conflicts, right?
<mborzecki> mvo: yeah
<mborzecki> mvo: merging or rebasing changes on top is super annoying
<pedronis> pstolowski: some comments in 6665, happy to get feedback back on what I propose
<mup> PR core18#123 closed: hooks: remove /etc/apt/sources.list.d/proposed.list <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/123>
<pstolowski> pedronis: thanks
<zyga> mvo: now that https://github.com/snapcore/core18/pull/125 is merged, how soon can we get core18 build?
<mup> PR core18#125: hooks: create snapd directory skeleton <Created by zyga> <Merged by sil2100> <https://github.com/snapcore/core18/pull/125>
<pedronis> that reminds  me, is there a deep reason why we kept firstboot in snapd.dirs,  is not used anymore since long time
<mvo> zyga: let me see
<mvo> pedronis: that sound like an oversight (90% confident)
<mvo> zyga: I triggered a new core18 build, should be ready in ~30min or so (depending on the buildds)
<zyga> super, thanks!
<pedronis> mborzecki: assuming all the renames are relatively obvious I don't need to review 6682
<mup> PR snapd#6436 closed: interfaces: add system-backup interface <â Blocked> <Created by jdstrand> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6436>
<pedronis> mvo: I did another pass on some of the remodel PRs, the main one needs 2nd reviews
<mborzecki> pedronis: ack
<mborzecki> https://github.com/snapcore/snapd/pull/6656 is green, are we moving forward with the plan to split the travis jobs to ubuntu and non-ubuntu?
<mup> PR #6656: tests: split travis spread execution in 2 jobs for ubuntu and non ubuntu systems <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6656>
<pedronis> mborzecki: sounds best to re-discuss it quickly at today standup
<mborzecki> pedronis: ok
<pedronis> mvo: any reasons not to merge #6667 ?
<mup> PR #6667: tests: enable tests that write /etc/{hostname,timezone} on core18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6667>
<pstolowski> zyga: added a few comments to #6643
<mup> PR #6643: tests: deny ioctl - TIOCSTI with garbage in high bits <Created by zyga> <https://github.com/snapcore/snapd/pull/6643>
<mvo> pedronis: the SRU is not out yet officially, we just have the fixes in the ppa
<mup> PR snapd#6654 closed: packaging/fedora, tests/upgrade/basic: patch existing mount units with SELinux context on upgrade <SELinux> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6654>
<pedronis> mvo: so  verifications will fail in some cases?
<pedronis> mvo: should it be marked blocked then?
<mvo> pedronis: I think so, let me do that and add a small explaination
<pedronis> pstolowski: I reivewed #6660
<mup> PR #6660: cmd/debug: integrate new task timings with "snap debug timings" <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6660>
<mvo> sil2100: re 121 for core18 - I'm on it, I think I know what is going on
<Chipaca> hmm, hmm
<Chipaca> mborzecki: this maybeShellcheck has broken a lot of tests here
<Chipaca> grmbl grmbl
<pstolowski> pedronis: ty
<mborzecki> Chipaca: which tests?
<Chipaca> mborzecki: the unit tests
<mborzecki> Chipaca: master seems fine
<Chipaca> mborzecki: this is on master
<Chipaca> mborzecki: pastebinning in a bit
<mborzecki> Chipaca: hm all fine here
<Chipaca> mborzecki: is your shellcheck from the snap
<mborzecki> Chipaca: no, let me try that
<Chipaca> mborzecki: http://paste.ubuntu.com/p/9R5g6QFTtd/
<mborzecki> Chipaca: see the same here
<mborzecki> haha, it's /tmp
<Chipaca> you done fucked up, son
<Chipaca> :-)
<mborzecki> shellcheck from snap cannot access that probably
<mborzecki> because it gets a private tmp
<mborzecki> hmm hmm, not sure there's a workaround for that, unless shellcheck becomes classic
<mborzecki> or check uses a different tmp directory
<Chipaca> mborzecki: you've got the script
<Chipaca> mborzecki: why not just feed it to shellcheck
<mborzecki> Chipaca: ah right, that's another option all right
<mborzecki> Chipaca: fix coming up
<mup> PR snapd#6683 opened: testutil: make mocked command work with shellcheck from snaps <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6683>
<mborzecki> Chipaca: ^^ can you do the honors?
<Chipaca> mborzecki: for extra fun, go could be running from a snap as well :-)
<mborzecki> Chipaca: all on ubuntu core :P
<Chipaca> well, no, because go is classic
<mborzecki> ah, right
<pstolowski> pedronis: ok to drop serial in #6665 ?
<mup> PR #6665: overlord/ifacestate: implement String() method of HotplugDeviceInfo for better logs/messages <Hotplug ð> <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6665>
<mborzecki> Chipaca: could have made it more fancy, like os.Open(), io.Copy(), but meh
<Chipaca> mborzecki: i thought the same on reading it
<pedronis> pstolowski: is it useful or not?
<pedronis> pstolowski: how long do they tend to be?
<pstolowski> pedronis: only if you have more instances of same device i suppose, to somehow distinguish them
<pedronis> pstolowski: yea,  as I said we could truncate them
<pedronis> but I'm not sure how long they tend to be
<mborzecki> back to zyga's PR
<mvo> sergiusens: ideas about lp 1822988 would be great
<mvo> sil2100: -^
<pedronis> pstolowski: my current feeling it to leave it, not do truncating yet, and see how it works out in practice
<pedronis> pstolowski: we also need to deal with the fact that hotplug keys are long/unwieldy of their own
<pstolowski> pedronis: ok, will only truncate model/vendor
<pedronis> pstolowski: but as you said, it seems we should indeed swap SHORT and non-SHORT for serial, I mean prefer SHORT if it exists
<pedronis> for this use
<pstolowski> pedronis: yes
<mborzecki> pstolowski: can you take a look at #6682?
<mup> PR #6682: snap, gadget: move gadget read/validation into separate package, tweak naming <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6682>
<pstolowski> mborzecki: yes!
<mborzecki> pstolowski: thanks!
<pstolowski> pedronis: updated #6665
<mup> PR #6665: overlord/ifacestate: implement String() method of HotplugDeviceInfo for better logs/messages <Hotplug ð> <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6665>
<mvo> 6577 needs a second review
<mup> PR snapd#6683 closed: testutil: make mocked command work with shellcheck from snaps <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6683>
 * Chipaca â lunch
<zyga> Chipaca: I would love your review of 6684
<mup> PR snapd#6684 opened: overlord,tests: perform soft refresh check in doInstall <Created by zyga> <https://github.com/snapcore/snapd/pull/6684>
<Chipaca> zyga: ack
<zyga> it's deceptively short :)
<zyga> and works in spread
<vidal72[m]> is there a way to list snaps that use core18?
<Chipaca> zyga: +1, with a silly suggestion you can ignore
<Chipaca> vidal72[m]: installed ones?
<zyga> Chipaca: wow, that's quick :)
<jdstrand> mborzecki: re ausearch, I can't remember otoh, but either jjohansen1, ChrisCoulson or tyhicks would have more info on ausearch and apparmor
<zyga> so... I need a 2nd review :)
 * cachio afk
<jdstrand> mborzecki: ah yes, I see now in backscroll you found the bug and extra context
<vidal72[m]> Chipaca: no, those avalaible on store
<Chipaca> vidal72[m]: no
<vidal72[m]> :(
<jdstrand> zyga: if that 2nd review was for me, please remember I was asked to focus on something ahead of all others, a queue formed and I will get through it. I promise
<zyga> jdstrand: no no :)
<jdstrand> ok :)
<zyga> jdstrand: there are lots of people who can review that
<zyga> and it's not security oriented
<Chipaca> vidal72[m]: why do you care?
<jdstrand> I thought this was a 6605 reminder :)
<mborzecki> jdstrand: yeah, it seems the bug got deprioritized, which is ok, there's workarounds
<jdstrand> see, it is so much in the queue I typed that from memory :)
<jdstrand> I'm currently a bit stretched thin. joe is trying to help with that
<jdstrand> mborzecki: you could ask the priority in #apparmor on OFTC. ChrisCoulson was assigned that at one point, but, yes, it got deprioritzed for various reasons
<vidal72[m]> Chipaca: I don't want to install ones using older base
<Chipaca> vidal72[m]: why?
<mborzecki> zyga: nice review from opensuse again, pretty thorough
<mborzecki> anyone wants to take a look at #6661?
<mup> PR #6661: data/selinux, tests/main/selinux-clean: fine tune the policy, make sure that no denials are raised <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6661>
<vidal72[m]> Chipaca: they are built without additional compiler hardening
<mborzecki> hopefully that's the last one in the selinux series
<Chipaca> vidal72[m]: what?
<pstolowski> zyga: i raised one general question to #6643 ; my mistake for not adding that to review summary, it's kinda easy to miss and github makes it annoying to answer this kind of comments (no Reply underneath)
<mup> PR #6643: tests: deny ioctl - TIOCSTI with garbage in high bits <Created by zyga> <https://github.com/snapcore/snapd/pull/6643>
<zyga> mvo: I'm not feeling very well and I'd like to take the 2nd half of the day off
<zyga> mvo: my highlights for the day are https://github.com/snapcore/snapd/pull/6684 which gives us the first part of working refresh app awareness
<mup> PR #6684: overlord,tests: perform soft refresh check in doInstall <Created by zyga> <https://github.com/snapcore/snapd/pull/6684>
<zyga> mvo: and the suse review from https://bugzilla.suse.com/show_bug.cgi?id=1127366
<zyga> mvo: both will need more work as you can suspect
<vidal72[m]> Chipaca: https://wiki.ubuntu.com/Security/Features
<mborzecki> pstolowski: whdyt about https://github.com/snapcore/snapd/pull/6682#discussion_r271708445 ?
<mup> PR #6682: snap, gadget: move gadget read/validation into separate package, tweak naming <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6682>
<vidal72[m]> Chipaca: some mitigations are enabled only since bionic
<mborzecki> pstolowski: the catch is that we'll probably end up extracting snaps (instead of mounting them) like ubuntu-image does once we start to lear how to assemble an image
<vidal72[m]> Chipaca: https://forum.snapcraft.io/t/build-snaps-with-hardened-toolchain-by-default/5444
<Chipaca> vidal72[m]: gotcha
<Chipaca> vidal72[m]: 'snap info --verbose' will tell you the base of the most-stable channel of a snap
<Chipaca> for arbitrary value of most-stable (but it's usually what you want)
<vidal72[m]> ok, thx
<Chipaca> vidal72[m]: otherwise, e.g., curl -s -H Snap-Device-Series:16 'https://api.snapcraft.io/v2/snaps/info/gnome-calculator?fields=base' | jq -r '.["channel-map"][] | .channel.name + "/" + .channel.architecture + ": " + .base'
<pstolowski> mborzecki: works for me
<pstolowski> mborzecki: perhaps mvo can vote as well
<pedronis> zyga: what's the status of #6583 ?
<mup> PR #6583: cmd/snap-confine: move ubuntu-core fallback checks <Created by zyga> <https://github.com/snapcore/snapd/pull/6583>
<zyga> I think it needs a 2nd review and I just kicked tests that may acutally pass now
<zyga> mvo: ^ can you finish your review there please
 * zyga is skipping the standup and officially EODing now
<mvo> thanks for the update zyga, enjoy eod
<zyga> thanks (cough, literally)
<mvo> zyga: in this case, get well!
<mup> PR snapd#6656 closed: tests: split travis spread execution in 2 jobs for ubuntu and non ubuntu systems <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6656>
<sergiusens> mvo: let me take a look
<mvo> sergiusens: thank you!
<sergiusens> mvo: commented on bug and PR
<mvo> sergiusens: yay, thank you - I think scriptlet is what we will do \o/
<mvo> sergiusens: we really just need control over the ENV and that gives it
<mup> PR snapd#6682 closed: snap, gadget: move gadget read/validation into separate package, tweak naming <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6682>
<mborzecki> sil2100: do you prefer a force push to https://github.com/CanonicalLtd/ubuntu-image/pull/168 or another commit on top of the current one?
<mup> PR CanonicalLtd/ubuntu-image#168: ubuntu_image: parser improvements <Created by bboozzoo> <https://github.com/CanonicalLtd/ubuntu-image/pull/168>
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37
<sergiusens> mvo:  hey, here's more context on why I want the "second part" https://forum.snapcraft.io/t/snap-try-messaging-and-user-experience/10667/2
<kyrofa> I have a user tracking the stable channel, but is months out of date. `snap changes` shows nothing. Manual refreshes work. Does this ring any bells?
<pedronis> Chipaca: you should probably look at #6679 (at least the daemon bits), there are some questions for you there
<mup> PR #6679: many: implement user removal <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/6679>
<pedronis> cmatsuoka: I did a pass on ^ as well
<cmatsuoka> pedronis: thanks samuele, I'll provide a commit addressing those issues
<ijohnson> kyrofa: are they using a brand store, such as on a dell gateway for example?
<kyrofa> ijohnson, I don't believe so, no
<kyrofa> Otherwise refresh control, you're thinking?
<ijohnson> yeah I had a similar issue recently with a user trying to install a snap on a dell gateway and the snap was gated (because of refresh-control in the default dell brand store) and that particular snap update had not been verified yet
<pedronis> jdstrand: hi, I added one more snapd PR to your queue, I think you have 3 now, plus something landed I think where you were asked for a post-review today
 * cachio lunch
<jdstrand> pedronis: ack, yep. I'm going to go through various store requests, emails then circle back around to reviews
<cachio> mvo, https://travis-ci.org/snapcore/spread-cron/builds/515129348
<cachio> mvo, I saw that error on revert test
<cachio> mvo, perhaps the trace helps to understand
<cachio> mvo, https://travis-ci.org/snapcore/spread-cron/builds/515129348#L2201
<mvo> cachio: thanks, looking in a bit
<cachio> niemeyer, hey, when you have time could you please take a look to https://github.com/snapcore/spread/pull/75 ?
<cachio> thanks
<mup> PR spread#75: Make spread tests for spread project run on google backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/75>
<Wimpress> Snapcraft Live starts in a few minutes - https://twitter.com/snapcraftio/status/1113512766889963522
 * cachio afk
<mup> PR snapd#6685 opened: image: prefer local for snapd/core snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6685>
<Chipaca> zyga: gif is pronounced with the g as in gnat, the i as in suit, and the f as the second one in fifth
<zyga> Chipaca: isn't gif the endless topic of discussion on how to pronounce it? :-)
<Chipaca> zyga: yes :-)
<mup> PR snapd#6686 opened: testutil: fix MockCmd for shellcheck 0.5 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6686>
<niemeyer> cachio: Need to finish something else before coming back into it, but it's on my list for after that
<cachio> niemeyer, np
<cachio> niemeyer, thankd
<cachio> niemeyer, thanks
<mup> PR snapcraft#2520 opened: snap: set core as a base <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2520>
<mup> PR snapcraft#2521 opened: cli: cleanup environment detection <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2521>
#snappy 2019-04-04
<mborzecki> morning
<mup> PR snapd#6686 closed: testutil: fix MockCmd for shellcheck 0.5 <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6686>
<zyga> Hey Maciek
 * zyga is totally sick
<mborzecki> zyga: hey, take a day off, get some rest
<zyga> I will :/
<mborzecki> mvo: morning
<mvo> hey mborzecki
<mborzecki> mvo: i was poking the fixed in #6685, looks like the current code works by accident
<mup> PR #6685: image: prefer local for snapd/core snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6685>
<mvo> mborzecki: yeah, its a bit puzzling, when I wrote the test things were a bit strange
<mvo> mborzecki: I haven't looked deeper, it got a bit late
<mvo> mborzecki: aha, nice find
<mborzecki> mvo: kept wondering why i did not hit this problem before :P
<mvo> mborzecki: yeah, it looks like this code needs a closer look, maybe we can simplify and get rid of all the PreferLocal ones
<mborzecki> mvo: fwiw, noticed something yesterday, when i did 'snap set system refresh.hold=' on a ssytem that did not refresh yet at all (eg. pristing image) it triggered a refresh
<mborzecki> need to check that with the tests, maybe i did something wrong
<mvo> mborzecki: that can be ok, if the image is really old snapd will detect no refresh for more than 60 days and force a refresh
<mborzecki> mvo: right, want to double check that, we're using seed-time as reference
<zyga> Store being silly about the description. https://usercontent.irccloud-cdn.com/file/u2vd6WZ6/Screenshot%202019-04-04%20at%2008.56.56.png
<zyga> Store being silly about license duplicates https://usercontent.irccloud-cdn.com/file/uIzKQ0Zb/Screenshot%202019-04-04%20at%2008.59.36.png
<zyga>  Store being silly about case sensitive search for GPL https://usercontent.irccloud-cdn.com/file/EUWodfbQ/Screenshot%202019-04-04%20at%2009.00.13.png
<brlin> zyga: Known issue
<brlin> https://github.com/canonical-websites/snapcraft.io/issues/1329
<zyga> Store being silly when selecting the 2nd of the "identical" GPL v2 only licenses https://usercontent.irccloud-cdn.com/file/Mzh8Y4Q0/Screenshot%202019-04-04%20at%2009.01.41.png
<brlin> https://github.com/canonical-websites/snapcraft.io/issues/1585
<zyga> brlin: thank you!
<brlin> zyga: You're welcome!
<pstolowski> morning
<mvo> pstolowski: good morning
<mvo> mborzecki: not sure if seed time is the right reference, if you e.g. get the current stable image from cdimage.u.c it will be 8 month old already :/
<mborzecki> mvo: we set it ourselves once seeding is done
<mvo> mborzecki: right
<mvo> mborzecki: what I mean is we need to think, if the snaps are 8month old we probably want to update soon
<brlin> zyga > Store being silly about case sensitive search for GPL
<brlin> Not reproducible at my end though
<zyga> brlin: if you look for GPL instead of gpl, does it find anything?
<brlin> zyga: https://usercontent.irccloud-cdn.com/file/waciCfQn/Screenshot_20190404_150931.png
<zyga> fun
<zyga> then it is a client side search bug
<brlin> Firefox seems to be fine
<mvo> thanks sil2100 !
<mup> PR core18#121 closed: Make the version number date-based <Created by sil2100> <Merged by mvo5> <https://github.com/snapcore/core18/pull/121>
<zyga> mvo: https://github.com/snapcore/snapd/pull/6583 is an easy win
<mup> PR #6583: cmd/snap-confine: move ubuntu-core fallback checks <Created by zyga> <https://github.com/snapcore/snapd/pull/6583>
 * mvo looks
<mup> PR snapd#6583 closed: cmd/snap-confine: move ubuntu-core fallback checks <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6583>
<zyga> woot thank you!
<zyga> mvo: so now shall I add a core16 fallback?
<brlin> I wonder what technical difficulties are blocking the `core16` base?
<zyga> brlin: I think it is mainly time
<zyga> brlin: we want core16 to be different from core
<zyga> brlin: it should behave like core18
<zyga> brlin: but have the contents of core
<zyga> brlin: the plan is  to allow "core" to be used instead of core16
<zyga> (so no new traffic)
<zyga> but using core18 semantics
<zyga> where semantics is really about how it behaves on a system using "core" as boot base
<brlin> zyga: Thanks for the explaination
<pedronis> zyga: mvo: I think it should be possible to tweak mvo PR about that,  I alos still wonder whether we can compute the base root path early
<zyga> pedronis: ah, right, this all started with an initial PR
<pedronis> mvo: hi, I added a card about CommandFromCore
<zyga> pedronis: we can but it should not block the work right now, I will add a patch for that soon, just trying to wrap up some of the existing fixes
<pedronis> mvo: assigned to you but feel free to give it to somebody else if that works better
<pedronis> mborzecki: image has been refactored many times, it might be that some bits are not needed anymore, I wouldn't jump to conclusions to fast either tough, it's pretty delicate/subtle, though there are tests
<zyga> pedronis: just checking, did you see https://bugzilla.suse.com/show_bug.cgi?id=1127366#c14 ?
<pedronis> no
<zyga> there are some interesting bits there
<mborzecki> pedronis: sure, i was just trying to find out why i did not run into this before
 * zyga considers breakfast a good thing and goes
<mup> PR snapd#6687 opened: snap-confine: set rootfs_dir in sc_invocation struct <Created by mvo5> <https://github.com/snapcore/snapd/pull/6687>
<mvo> pedronis: I create a PR to calculate the base root path (cc zyga)
<mvo> pedronis: will look at comand-from-core, thanks for this
<mvo> zyga: I can tweak my PR about core->core16 fallback, should be easy now thanks to your work  on this :)
<pedronis> mborzecki: so I think it's correct that we don't mostly need the PreferLocal anymore,  the only things that goes wrong is the message Copying vs Fetching
<pedronis> which could be moved inside acquire itself
<pedronis> the ListContains is still not quite right though
<pedronis> it should use local.hasName
<pedronis> mvo: mborzecki: I'll pick up that PR myself today or tomorrow
<mvo> pedronis: thank you
<mvo> zyga, pedronis just fyi - I updated the old 6418 (core16->core fallback) to use the new place for this
<pedronis> mvo: it looks right to me, but I haven't relooked at the whole PR
<mvo> pedronis: no worries, I'm looking at adding one more test that zyga suggested
<zyga> drwxr-xr-x 6 root root 4096 Apr  4 07:46 /root
<zyga> why is root so weirdly open on core?
<zyga> it  does't seem to be open in real core
<zyga> just in our tests
<dot-tobias> Hi everyone
<zyga> perhaps /root is from writable somewhere
<zyga> but has wrong permissions
<Chipaca> zyga: wrong how?
<zyga> Chipaca: it's too open
<zyga> ls -ld /root
<zyga> and compare
<pedronis> ah, /root,  me was reading /root as / (the brain is funny)
<zyga> :D
<zyga> yes some overloaded meanings abound
<brlin> dot-tobias: Hello
 * zyga looks at a real core device
<mborzecki> zyga:  drwx------  4 root root 4096 Apr  4 07:04 root
<zyga> is that from core16?
<mborzecki> 18
<zyga> ok
<zyga> so real core devices are probably ok
<zyga> so our tests are broken somehow
<zyga> Found it
<zyga> fixing
<dot-tobias> Short question re: cloud.conf in gadget snaps: Reading https://forum.snapcraft.io/t/how-to-preconfigure-custom-image/4154/15 and https://forum.snapcraft.io/t/cloud-init-with-netplan/1301/5 , it seems to me this does not work (properly / yet). The docs for gadget snaps just mention âoptional cloud.confâ (https://docs.snapcraft.io/the-gadget-snap/696) Can someone confirm or point me to further resources? ping ogra ð
<zyga> hmmm
<zyga> it seems that we don't have some modules and ubuntu core cannot be used in vmware
<pedronis> it's quite possible
<pedronis> pstolowski: degville: hi,  I did a quick read over the hot plug docs, they look overall
<pedronis> *look good
<pedronis> I left a question/comment
<zyga> using IDE disk fixes this
<zyga> so that's good
<zyga> and I can boot core in vmware
<zyga> so useful :)
<pstolowski> pedronis: ty
<zyga> zyga@core16:~$ sudo snap refresh
<zyga> error: cannot refresh []: cannot refresh snap-declaration for "snapweb": parsing assertion headers: expected 4 chars nesting prefix after multiline introduction "plugs:": "  network:"
<zyga> how do we update from vanilla core systems again?
<zyga> (this is a freshly installed core system as obtained from cdimage)
<pedronis> zyga: there's a bug for that
<zyga> right, I recall this discussion
<zyga> that's not great :/ I thought the store had fixed the response
<pedronis> they haven't yet :/
<zyga> so we should regenerate our core images
<degville> pedronis: thanks for the review! I'll work on those two comments now.
<pedronis> https://bugs.launchpad.net/snapstore/+bug/1802773
<zyga> they are useless
<mup> Bug #1802773: Cannot refresh from ubuntu-core 2.15.2 on raspberry pi "ubuntu core 16" image - snap-declaration for "snapweb": parsing assertion headers: expected 4 chars nesting prefix after multiline introduction "plugs:": "  network:" <regression> <snapstore-deployment> <snapd:Confirmed> <Snap
<mup> Store:New for wgrant> <https://launchpad.net/bugs/1802773>
<zyga> pedronis: how can we escalate this?
<zyga> I will install a core18 system in the meantime
<zyga> but it feels like the image should be refreshed to current core16
<zyga> and we should remove snapweb
<degville> pstolowski: after I've made those edits, would you like me to move the Hotplug support doc over the forum, or would you prefer to do it?
<zyga> the qemu images are whooping 4GB
<zyga> they are not sparse
<zyga> compression "helps" but this looks like an oversight
<zyga> pedronis: who can I poke about that?
<pedronis> zyga: I think mvo needs to decide what he wants to do, I poked a couple of times already in the past
<zyga> mvo: ^
<pstolowski> degville: please do, thank you!
<degville> pstolowski: np!
<zyga> sil2100: we cannot set hostname on a core18 system
<zyga> zyga@localhost:~$ sudo hostnamectl set-hostname core18
<zyga> Could not set property: Failed to set static hostname: Read-only file system
<zyga> on core18 the system-shutdown helper is not working
<zyga> I just got a failure about that when rebooting
<zyga> Chipaca: ^
<Chipaca> zyga: yes we know
<Chipaca> oh
<Chipaca> not the last two
<Chipaca> zyga: what failure did you get? can i see?
<zyga> a flash on the vmware screen, I'm looking at logs now
<Chipaca> zyga: if you do halt instead of reboot you should see them
<zyga> I added persistent journal now
<Chipaca> zyga: some failures are expected (that's why the script exists)
<Chipaca> zyga: the interesting messages are post-journal
<Chipaca> i mean, systemd *execs* the system-shutdown helper
<zyga> ha
<zyga> tricky beast
<Chipaca> system-shutdown is pid 1
<zyga> yes
<Chipaca> :-)
 * Chipaca could tweak it a bit so it starts snapd and takes over the world from there
<sil2100> zyga: hm, I thought we had this before and fixed it
<zyga> sil2100: does the fix require a new core image
<zyga> sil2100: I just installed core18 from cdimage
<zyga> Chipaca: I have the logs now, let me try to go through them
<Chipaca> zyga: if you have logs they'll say they couldn't unmount writable
<zyga> https://pastebin.ubuntu.com/p/WmkCSTjgnD/
<zyga> Apr 04 09:10:48 localhost kernel: systemd-shutdow: 67 output lines suppressed due to ratelimiting
<zyga> hahah
<zyga> let me fix that
<Chipaca> zyga: that's not the helper
<Chipaca> zyga: that's systemd-shutdown
<Chipaca> zyga: to see the helper's logs, use halt
<Chipaca> and screenshot
<zyga> https://usercontent.irccloud-cdn.com/file/bcoUzJVf/Screenshot%202019-04-04%20at%2011.16.38.png
<zyga> the /dev/loop0 is interesting
<zyga> but apart from that it looks less bad
<zyga> just the failures are ugly to look at
<Chipaca> zyga: wrt /dev/loop0, new enough kernels auto-disassociate
<Chipaca> so it's fine
<Chipaca> zyga: that's a successful run of the helper
<zyga> mvo: core has 2.38 in stable but snapd is 2.37.4
<zyga> mvo: did we forget to push snapd snap to stable?
<pedronis> reminder that #6577 needs a 2nd review
<mup> PR #6577: many: make Remodel() download everything first before installing <Created by mvo5> <https://github.com/snapcore/snapd/pull/6577>
<zyga> pedronis: I will gladly look
<zyga> https://github.com/snapcore/snapd/pull/6642/commits/07cd4fa0911006f2bbcc6c6bebf8f1470e093765 <- this was breaking /root permissions
<mup> PR #6642: cmd/snap-confine: prevent cwd restore permission bypass <Created by zyga> <https://github.com/snapcore/snapd/pull/6642>
<zyga> mkdir on the following line
<pedronis> pstolowski: btw were my brief comment on #6660 understandable? what is my concern there?
<mup> PR #6660: cmd/debug: integrate new task timings with "snap debug timings" <Created by stolowski> <https://github.com/snapcore/snapd/pull/6660>
 * zyga goes to make coffee and goes back to do reviews 
<pstolowski> pedronis: yes; i played yesterday with timings.Get function & a filter predicate and not making *JSON public but couldn't find a good solution
<pedronis> pstolowski: do we need to chat ?
<pstolowski> pedronis: if you have time then yes, that would speed things up
<zyga> mborzecki: can you do a 2nd review for https://github.com/snapcore/snapd/pull/6642
<mup> PR #6642: cmd/snap-confine: prevent cwd restore permission bypass <Created by zyga> <https://github.com/snapcore/snapd/pull/6642>
<zyga> mborzecki: I will get a review from jamie as well
<mborzecki> zyga:  sura
<zyga> mborzecki: I will be working on fixing the core16 image permissions today, I will not merge before that lands
<zyga> mborzecki: FYI: core18 was fixed and merged (with tests) yesterday
<mborzecki> zyga: btw. can you take a look at https://github.com/snapcore/snapd/pull/6661 later on? it's the last one
<mup> PR #6661: data/selinux, tests/main/selinux-clean: fine tune the policy, make sure that no denials are raised <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6661>
<mvo> zyga: thats a question for cachio, we need to check where the validation stands
<zyga> mvo: is snapd.snap validated as a part of core18?
<zyga> mborzecki: sure
<mvo> zyga: re "I think mvo needs to decide what he wants to do, I poked a couple of times already in the past"> can you give me some more context? I read backlog but its not obvious, sorry
<mvo> zyga: yes
<mvo> zyga: see the trello card on releasing 2.38
<mvo> zyga: the usual flow is that QA validates core (uc16) and core18+snapd (uc18)
<zyga> mvo: stale core16 images
<zyga> mvo: our core16 images are 100% useless now
<zyga> mvo: because of a store bug that prevents old snapd from refreshing
<mvo> zyga: and if the core18 image is fine we promote that too
<zyga> mvo: we should regenerate them to have core instead of ubuntu-core and to have more recent snapd
<mvo> zyga: what is this bug? that sounds serious?
<zyga> mvo: we should also drop snapweb
<zyga> mvo: https://launchpad.net/bugs/1802773
<zyga> mvo: it's trivial to reproduce, I hit this a moment ago
<mup> Bug #1802773: Cannot refresh from ubuntu-core 2.15.2 on raspberry pi "ubuntu core 16" image - snap-declaration for "snapweb": parsing assertion headers: expected 4 chars nesting prefix after multiline introduction "plugs:": "  network:" <regression> <snapstore-deployment> <snapd:Confirmed> <Snap
<mup> Store:Confirmed for wgrant> <https://launchpad.net/bugs/1802773>
<mvo> zyga: fwiw, the core images are created by foundations, I raised the topic of stale images in the meeting with them on monday and they are on it (cc pedronis) - not sure what I need to make up my mind about but happy to do so (once I learn more :)
<mvo> zyga: "ubuntu-core" ?!?!
<mvo> zyga: we have an image that is still on ubuntu-core for download?
<zyga> mvo: yes
<zyga> that's the reference image we have
<zyga> that's great, right?
<mvo> zyga: that sounds incredible wrong
<zyga> indeed
<mvo> zyga: and that is not something I was aware of, we need to fix this. where is that image linked?
<zyga> mvo: http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/
<zyga> perhaps the whole directory should go
<zyga> I bet the remaining images are equally broken
<mvo> zyga: the site is a bit of a mess - the right link is "ubuntu-core" and that has more current images. but we need to remove this dir
<zyga> +1
<pedronis> mvo: there are two issues, one is the images, the other is that bug, old snapd still using the old assertions end point get assertion formats they cannot parse
<pedronis> pstolowski: can you caht now?  otherwise it needs to be this afternoon or tomorrow
<pstolowski> pedronis: now is fine
<pedronis> pstolowski: I'm in the standup
<mvo> pedronis: not disputing the bug :) was just curious what I need to make my mind about. also the fact that we have a "ubuntu-snappy" link on cdimage is highly confusing so that needs fixing too
<mvo> 6641 is ready for a re-review
<zyga> mvo: I will look, going through remodel first
<mvo> zyga: ta
<Chipaca> pedronis: https://forum.snapcraft.io/t/building-with-build-snaps-bottle-necking-on-fuse/10747 fwiw
<Chipaca> pedronis: fuse bottlenecks on lxd, because snapfuse is apparently single-threaded
<Chipaca> pedronis: setting the flag to unsquash on install doesn't work because fuse detection gets in the way
<Chipaca> pedronis: disabling fuse detection breaks the sanity check
<Chipaca> pedronis: :-(
<pedronis> Chipaca: is it urgent?
<Chipaca> pedronis: for who :-)
<pedronis> Chipaca: sorry, I'm asking why you raise it now instead of standup I suppose
<Chipaca> pedronis: ah, because i want to forget about it and get back to what i'm supposed to be doing :-)
<Chipaca> but i don't want to strand sitter with no response beyond "yeah sucks"
<pedronis> Chipaca: you should have poked me from in the forum
<pedronis> I think
<Chipaca> pedronis: ok, fair
<pedronis> for such a case
<Chipaca> pedronis: i was chatting with sitter in #snapcraft, dumping to the forum for posterity
<Chipaca> but yeah
<Chipaca> #snapcraft is not logged :-(
<pedronis> anyway I don't think we recommend a _TEST thing even if it worked for building
<pedronis> we would need to make that more first class
<pedronis> but how much unclear
<pedronis> (independetly that it chokes atm)
<Chipaca> pedronis: agreed
<Chipaca> pedronis: anyway, pinged you in the forum so it can carry on async'ly
<Chipaca> pedronis: ~3 months until they need it in production
 * Chipaca gets back to work^Wcoffee
<mup> PR snapd#6688 opened: gadget: add validation of cross structure overlap and offset writes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6688>
<mborzecki> mvo: ^^ if you have some time for reviews
<mborzecki> back to zyga's PR
<mvo> mborzecki: heh, this sounds complicated :)
<mup> PR core18#120 closed: Backport wpa_supplicant.service.d/snap.conf from core <Created by sil2100> <Merged by sil2100> <https://github.com/snapcore/core18/pull/120>
<Chipaca> stepping away for a bit, bbl
<mborzecki> zyga: quick questions about opensuse, snapd is there in a separate project atm right?
<zyga> yes
<zyga> pending inclusion after changes raised through the security review
<zyga> perhaps 2.39 actually ..
<zyga> if I'm fast enough
<mborzecki> zyga: wdyt about extending tests/upgrade/basic to add the repo and install the snapd package from there?
<zyga> yeah, it makes sense, thank you for raising it
<thresh> is there a way for snapcraft push to try a couple of times without shell scripts hacking around it?
<thresh> got a 500 this morning in the CI
<mborzecki> zyga: some comments under #6642
<mup> PR #6642: cmd/snap-confine: prevent cwd restore permission bypass <Created by zyga> <https://github.com/snapcore/snapd/pull/6642>
<zyga> mborzecki: thank you
<zyga> mvo: reviewed the remodelling branch
<zyga> mborzecki: replied
<mborzecki> zyga:  i think I"m missing something about O_PATH, https://paste.ubuntu.com/p/KNcd5RXDdw/
<mborzecki> zyga:  there's still permissions on the prefix that are needewd
<zyga> mborzecki: mmmm
 * zyga checks
<zyga> ah, indeed
<zyga> that's a nice catch
<zyga> about O_PATH: https://www.irccloud.com/pastebin/8TPWkUbn/
<zyga> I will adjust the code
<mborzecki> zyga: ok
<pedronis> pstolowski: I +1ed 6665 with a small comment
<pstolowski> ty
<zyga> mvo: https://github.com/snapcore/snapd/pull/6641#pullrequestreview-222712382
<mup> PR #6641: snap-gdb-shim: switch to the SUDO_UID when available <Created by mvo5> <https://github.com/snapcore/snapd/pull/6641>
<zyga> mborzecki: looking at https://github.com/snapcore/snapd/pull/6661/files now
<mup> PR #6661: data/selinux, tests/main/selinux-clean: fine tune the policy, make sure that no denials are raised <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6661>
<mborzecki> zyga: thanks!
<pedronis> zyga: I made a comment in #6673
<mup> PR #6673: cmd,tests: forcibly discard mount namespace when bases change <Created by zyga> <https://github.com/snapcore/snapd/pull/6673>
<zyga> pedronis: looking
<zyga> pedronis: that's a fair comment, for now using os-release should work but I agree ideally we'd know better. I will think about what to do best
<zyga> pedronis: we can actually use /run for that, it's always a tmpfs that we get for free
<zyga> pedronis: the only problem is that this doesn't tell us the name of the base in absence of that file, which may require a fallback to something else (or switch to probing)
<pedronis> zyga: that is always bound mount from the host, no?
<zyga> yes
<pedronis> is not sharing back though?
<zyga> I don't understand what you mean
<zyga> we don't need to mount anything, just leave a trace what we did
<zyga> like we write to /run/snapd/ns/
<zyga> we can also store meta-data file for each mount namespace there
<pedronis> zyga: I think I need to understand a bit more what you plan to use, we need to find the info that correspond to the namespace
<zyga> pedronis: we can either determine the base snap name without any lookaside storage
<zyga> pedronis: that may be possible
<zyga> pedronis: or we can simply write the name of the base
<zyga> pedronis: just like we do with mount profiles
<pedronis> zyga: sorry, we need the name of the base that the namespace was made with
<pedronis> not just the name of the current revision name
<zyga> pedronis: I know that, that's what I meant
<zyga> pedronis: we may be able to infer that from the mount namespace alone
<zyga> pedronis: but if that's hard or we cannot do that for whatever reason we can just write that down when we first create it
<pedronis> zyga: I agree,  I'm still not sure where you plan to write it down
<zyga> pedronis: if we write it down it can go to /run/snapd/ns/$SNAP_INSTANCE_NAME.info
<pedronis> zyga: and we remove it and rewrite when we discard the namespace ?
<zyga> yes
<zyga> pedronis: just like the mount profiles
<zyga> pedronis: we might even include it in the mount profile itself as a comment but I think that'd be a stretch
<pedronis> that's were I get lost, I though the mount profile is written by snapd
<zyga> pedronis: there are two files
<zyga> pedronis: snapd writes "what I want"
<zyga> pedronis: snap-update-ns writes "what I did"
<pedronis> ok, so a sibling to the latter
<zyga> pedronis: snap-confine could write "what I started with" until that logic migrates to snap-update-ns
<mborzecki> mvo: need to step out and skip the standup, i'll send a note in the forum
<zyga> (I'm working on moving most of the initialization to go but that's a slow process that I don't spend much time on)
<zyga> pedronis: but yes, a sibling to what the lower layers write
<pedronis> zyga: I think I got lost because for a while it sounded like our only option was to read something from inside the namespace
<pedronis> but that's not true
<pedronis> I don't think we need to be clever here, if blunt and simple works I'm all for it
<zyga> pedronis: that's correct, we can do both
<zyga> pedronis: reading something from inside the namespace has one advantage
<zyga> pedronis: migration is easier
<zyga> pedronis: no new data is required
<zyga> pedronis: I agree
<zyga> pedronis: less complexity is good
<Chipaca> pstolowski: your changes to #3/4 LGTM
<zyga> pedronis: perhaps base snaps could have one extra file
<zyga> pedronis: /meta/snap.info with simple key=value pairs :)
<pedronis> zyga: no, that is not simple
<zyga> pedronis: for things we wish we could get out of the yaml
<pedronis> is simple for us
<pedronis> but not overall
<Chipaca> pstolowski: there's still the bit where you have a day constant that i suspect isn't tested :-)
<zyga> pedronis: perhaps, I think it'd be nice though, it's not like it's a complex cost for anyone
<pedronis> zyga: we have meta/snap.yaml
<pedronis> it has a name too
<zyga> yes but parsing a simpler format with limited data would be beneficial
<pedronis> I understand but that just weird
<zyga> parsing yaml is pretty hard
<pstolowski> Chipaca: ty! did you notice the change to doForget?
<zyga> yeah, I'm not seriously proposing it for this use case
<pedronis> we can write the simple stuff ourselves
<pedronis> somewhere
<zyga> I think it'd be nice but it's not required for sure
<zyga> pedronis: that brings me back to one idea
<zyga> the key=value facts file
<zyga> we could stop trusting environment
<zyga> I would love if we did that
<pedronis> I don't think is nice to be clear
<pedronis> for the record
<Chipaca> pstolowski: I did! you could check it's auto before trying to remove it, no?
<zyga> it's a pending security hole if someone finds a way to abuse it by confusing snap-confine
<pedronis> zyga: confuse what?
<zyga> confuse snap-confine by setting variables we depend on and provide additional command line options
<pstolowski> Chipaca: yes, indeed! will add
<zyga> we could write information that a snap has classic confinement and not depend on --classic
<Chipaca> pstolowski: no biggie as it's a reasonably fast op
<Chipaca> pstolowski: but, Â¯\_(ã)_/Â¯
<zyga> we could write information about the base snap and not depend on --base-snap-name or whatever the argument is
<zyga> we could write snap instance name and not depend on the environment variable
<zyga> that would be much stronger guarantee than what we have now where all of this is untrusted input
<pedronis> that's sounds an ok plan, but sound still different than current
<zyga> that we need to carefully parse and cross check
<pedronis> problem
<zyga> yes
<pedronis> that's about current snap revision
<zyga> because it would be snapd writing that
<pedronis> not current actual namespace
<zyga> and here it would be snap-confine
<pstolowski> Chipaca: nb, i noticed that doForget test(s) don't set set-id on the test task, not sure it's a an issue or not, we probably are not testing doForget as througly as we could (but since all these bits are well tested separately, than maybe that's ok)
<zyga> but if we agree on some basic snap-confine provided "here is what I did" file in /run that helps me a lot
<zyga> because I will also immediately use it for nvidia migration later on
<zyga> e.g. I could write: base_snap_name=foo and nvidia_mode=legacy-mount
<Chipaca> pstolowski: patches welcome :-Ã¾
<zyga> (or legacy-symlinks)
<zyga> pedronis: so if you agree on storing simple meta-data like that I'm super happy to pursue that
<zyga> pedronis: in addition I can do one special optimization
<zyga> :)
<zyga> pedronis: if base snap name is "core" I will not write it
<zyga> then migration is free :)
<zyga> you can migrate from core to core18 and from core18 to core
<zyga> and from old snapd that didn't know about this to new snapd that does
<pstolowski> Chipaca: yep, i can re-visit this soonish, didn't touch it now as it's too easy to get side-tracked ;)
<Chipaca> pstolowski: *applause*
<pstolowski> i think doForget should error-out if set id is not provided, since client requires it afair
<mup> PR snapd#6665 closed: overlord/ifacestate: implement String() method of HotplugDeviceInfo for better logs/messages <Hotplug ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6665>
<ogra> dot-tobias, i dodnt touch cloud-init, specifically not on core ... but ondra has some experience with it
<dot-tobias> ogra Thanks, will ping him with a forum question
<ogra> he is here as well but might not watch IRC all the time
<zyga> mborzecki: can you have a quick look at https://github.com/snapcore/snapd/pull/6642 -- I fixed the issue with O_PATH
<mup> PR #6642: cmd/snap-confine: prevent cwd restore permission bypass <Created by zyga> <https://github.com/snapcore/snapd/pull/6642>
<Chipaca> mvo, pedronis, I'll be offline for a bit while I relocate back; this was a bad idea ;-)
<pedronis> Chipaca: ok
<Chipaca> cmatsuoka: I'll review the delete-user pr when i'm back
<zyga> mborzecki: I started going through the selinux change but it's not easy
<Chipaca> if that's ok
<Chipaca> (otherwise i could probably sneak it in now while t'internet still works here ...)
<zyga> it's hard to map a type to a comment with a path that justifies it
<mvo> Chipaca: no worries, see you
<cmatsuoka> Chipaca: no hurry, I'll work on that after finishing a snapcraft assignment that should take the entire afternoon
 * cmatsuoka vs patchelf
<mborzecki> re
<mborzecki> zyga:  thanks! ;)
<mborzecki> zyga: ping me if you have questions
<zyga> ack
<mup> PR snapcraft#2522 opened: build providers: add API for friendly instance type names <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2522>
<mup> PR snapcraft#2521 closed: cli: cleanup environment detection <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2521>
<zyga> https://github.com/snapcore/snapd/pull/6684 needs a 2nd review
<mup> PR #6684: overlord,tests: perform soft refresh check in doInstall <Created by zyga> <https://github.com/snapcore/snapd/pull/6684>
 * cachio lunch
<brlin> Strange warning in Solus 4 https://usercontent.irccloud-cdn.com/file/vnB4i37M/Screenshot_20190404_235706.png
<brlin> Is this normal?  I assume this is the problem that causes the `execv failed: No such file or directory` error when running core18 snaps. https://usercontent.irccloud-cdn.com/file/nxT13Vc8/Screenshot_20190405_000148.png
<zyga> re
<zyga> brlin: looking
<brlin> <3
<zyga> brlin: so I'm confused as to what you are referring to
<zyga> in the first image I see that sudo resets PATH
<brlin> Solus appears to not set /snap/bin as one of the PATHs in the sudoers policy
<zyga> brlin: run sudo env | grep PATH
<zyga> in the second case
<zyga> I don't see any errors at all, unless I'm missing something
<zyga> just regular debug output
<brlin> zyga: Is the "current mount profile (after applying changes)" line expected to be (none)?
<brlin> zyga: ```
<brlin> $ sudo env | grep PATH
<brlin> PATH=/usr/sbin:/usr/bin:/sbin:/bin
<brlin> ```
<zyga> yes, because user mount profiles are not preserved yet
<zyga> there's a long effort that is close to being do to change that
<zyga> brlin: in addition it is a special mount entry that we only apply if the source and destination exist
<zyga> brlin: it is a mount entry for the document portal
<brlin> Oh, that makes sense now, thanks for the help.
<zyga> brlin: thanks for checking, sorry that this is not documented more clearly
<zyga> perhaps we should log something when the error is ENOENT
<brlin> Well it is a debug output, I expect no more what it already is.
<zyga> I'm working on the next batch of refactoring for that area
<zyga> the whole interaction will be much easier to follow and extend
<zyga> I strongly want to finish that to allow me to open a new feature
<zyga> where the ~/snap directory is gone :)
<zyga> but ... complexity and layering
<zyga> mvo: wanna do a 2nd review for https://github.com/snapcore/snapd/pull/6684 ? :)
<mup> PR #6684: overlord,tests: perform soft refresh check in doInstall <Created by zyga> <https://github.com/snapcore/snapd/pull/6684>
<zyga> mvo: refresh app awareness awaits :)
<cachio> niemeyer, hey, I have another PR to review https://github.com/snapcore/spread/pull/70
<mup> PR spread#70: Close ssh connection when reboot is stuck <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/70>
<cachio> it is an old one which is still needed
<cachio> niemeyer, thanks
<brlin> It seems that Solus have solved the core18 snaps' launching problem: https://dev.getsol.us/R3609:5fd02a7c03eca0f53aa389a701385558cf7fd423
<zyga> mvo: if still around: https://github.com/snapcore/snapd/pull/6687/files#r272266095
<mup> PR #6687: snap-confine: set rootfs_dir in sc_invocation struct <Created by mvo5> <https://github.com/snapcore/snapd/pull/6687>
<mup> PR snapd#6667 closed: tests: enable tests that write /etc/{hostname,timezone} on core18 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6667>
<mvo> zyga: thanks ,I check it
<mvo> 6595 needs a review (should be easy)
<pedronis> mvo: cachio asked for the timeout to be 5m
<pedronis> that hasn't been applied afaics
<zyga> mvo: reviewed
<mvo> pedronis: uh, thanks, will fix
<zyga> ah, indeed
<zyga> mvo: wait
<zyga> I can change that in a suggestion
<zyga> and you can just click on "commit" :D
<zyga> mvo: look
<zyga> mvo: refresh and click on what you like :)
<zyga> jdstrand: hey
<zyga> jdstrand: gentle ping for https://github.com/snapcore/snapd/pull/6605
<mup> PR #6605: cmd/libsnap,osutil: fix parsing of mountinfo <Created by zyga> <https://github.com/snapcore/snapd/pull/6605>
<sil2100> zyga: re: the hostname problem (sorry for looking into it only now) - what image were you using?
<zyga> sil2100: hey
<zyga> sil2100: I got the image following the usual links from the ubuntu download website
<zyga> sil2100: I debugged it a little and it's curious
<zyga> it *gets* set
<zyga> but there is still an error displayed
<sil2100> zyga: ah, yeah, ok, so it's fixed in the current one, as I thought this was the thing we were fixing in systemd AFAIK
<zyga> let me show you
<zyga> current one?
<sil2100> zyga: so if you fetch the latest daily, it seems to work
<mup> PR snapd#6689 opened: tests: run create-user on core devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/6689>
<zyga> hmm
<zyga> daily image or daily snap?
<zyga> sorry, please be specific
<jdstrand> zyga: yes, I have that and 3 other PR reviews. Is this super-urgent and blocking a whole bunch of things? I'm still working through a rather large todo list and PR reviews are high on it. hoping to get to it today otherwise tomorrow
<sil2100> zyga: http://cdimage.ubuntu.com/ubuntu-core/18/20190404/ <- try using this one
<zyga> I just booted the vm and hostname is reset
<zyga> jdstrand: no, not urgent
<sil2100> zyga: and tell me if it's still busted there
<cachio> mvo, pedronis yes, we need 5 minutes of timeout because otherwise it fails on the boards
<zyga> sil2100: can I refresh to a different channel?
<sil2100> zyga: (since maybe my test-case is wrongish, it's been a long day)
<jdstrand> ok, then I will proceed with the priorities I outlined earlier in the week and will get to it
<zyga> jdstrand: +1, thank you
<zyga> sil2100: I can try a fresh vm tomorrow, since it is marginally more work,
<sil2100> zyga: guess you can try the core18 from edge/beta too
<sil2100> Since I suppose you reproduced it on the stable one, right?
<cachio> in the past we updated all the short timeout to 5 minutes because of that
<zyga> sil2100: or I can refresh to new channel to see
<zyga> I can try that
<zyga> correct
<zyga> sil2100: trying core18 from edge
<sil2100> Fingers crossed!
<cachio> mvo, I can make that change if you want
<zyga> sil2100: edge works
<zyga> sil2100: even after reboot
<zyga> sil2100: thanks!
<sil2100> zyga: thank mvo for that! He prepped the systemd changes to make it work o/
<zyga> mvo: thank you then :-)
<sil2100> zyga: but phew, for a moment thought the systemd changes weren't enough, and I just released those to -updates
<zyga> haha
<zyga> some cold sweat :)
<zyga> it's great, thanks
<zyga> hmmm
<zyga> are core18 builds going?
<mvo> cachio: thank you
<zyga> one of my tests failed two hours ago because core18 didn't have /var/lib/snapd/snap
<zyga> er
<zyga> I meant /var/lib/snapd/void
<cachio> mvo, change done, now waiting for tests results
<mvo> cachio: ta
<cachio> mvo, yaw
 * zyga EODs
<zyga> mvo: if you can review / approve 6684 I would love to end the day with that
<mvo> zyga: sure
<degville> pedronis: pstolowski|afk: those docs are now published - https://docs.snapcraft.io/developing-hotplug-interfaces and https://docs.snapcraft.io/hotplug-support. I still need to add some 'hardware interface' clarifications to the relevant interface docs.
<brlin> I wonder what's the usage of `/var/lib/snapd/void` ?
<sil2100> zyga: it should have, since we had a new core18 package yesterday, an hour ago and even a few minutes ago!
<pedronis> degville: thx
<brlin> zyga: Thanks for checking out the Solus issue!
<pedronis> degville: let me know if you need help to find out which ones those are
<degville> pedronis: thanks, will do!
<zyga> brlin: AFK
<zyga> brlin: literally holding my daughter and typing with one finger
<brlin> zyga: Take your time, then ;)
<zyga> drat
<zyga> ++ stat -c %a /var/lib/snapd/void
<zyga> stat: cannot stat '/var/lib/snapd/void': No such file or directory
<zyga> earlier in the log I see
<zyga> + rsync -av --delete /home/gopath/src/github.com/snapcore/snapd/tests/snapd-state/snapd-lib/snaps /var/lib/snapd
<zyga> I bet the state is corrupt somehow and something removes writable directories
<zyga> I'll run that test in isolation to see if it passes
<zyga> brlin: the void directory is a fallback location
<zyga> brlin: when snap-confine starts a program and cannot represent the original working directory inside the changed filesystem
<zyga> brlin: it uses /var/lib/snapd/void
<mup> PR snapd#6684 closed: overlord,tests: perform soft refresh check in doInstall <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6684>
<zyga> mvo: around?
<zyga> mvo: what writes /writable/system-data/?
<zyga> is that ubuntu-image?
<zyga> mvo: I just realised that all of the work to make core18 have skeleton tree was 100% useless
<pedronis> zyga: ?
<zyga> pedronis: /var/lib/snapd and /var/cache/snapd are bind-mount to system-data/
<zyga> and the content in the boot base is irrelevant
<zyga> the real change has to be done elsewhere
<pedronis> zyga: does it mean the opengl stuff also never worked on core?
<zyga> pedronis: yes, it was never supported on core to begin with
<zyga> pedronis: unless the snap ships all the stuff internally
<zyga> pedronis: I need to untangle this tomorrow
<zyga> it's too late today
<pedronis> zyga: anyway we need to discuss because making it ubuntu-image problem sounds kind of wrong
<zyga> pedronis: I think we need to start by saying what we want to have
<zyga> comparing it to what we have now across bases and history cruft
<zyga> I'm just puzzled by how this works
<zyga> this is also compounded by writable paths and general complexity associated with how that operates
<pedronis> it's fine, we can discuss tomorrow/next week
<zyga> and what is the configuration of the initial mount namespace on core devices
<zyga> yes, I'm just puzzled by how complex this turned out to be, it was supposed to be a bugfix for a low-priority CVE
<pedronis> I thought we were already using void
<pedronis> for some things
<zyga> yes, but nothing tested it on core18
<zyga> it doesn't work
<pedronis> otoh we know that core 16 mount setup with core !=  core 18 core18
<zyga> yes, exactly
<zyga> on core16 it does work
<zyga> because what the core snap carries does matter :)
<pedronis> that is still confusing to me
<pedronis> the host has still writable parts
<pedronis> that come from /writable
<pedronis> did we simplify writable path config too much on core18 ?
<zyga> pedronis: I don't know what the config for core18 is
<zyga> pedronis: we should sit down and discuss this for core20 context
<zyga> pedronis: at some point in the past I wanted to have a mini-version of snap-confine that does just the mount namespace setup for the initial mount namespace to replace the shell logic currently in the initrd
<pedronis> heh, sounds like a super tangent
<zyga> because keeping that in the core-xxx repo on the side not helping with understanding what is going in
<zyga> *on
<zyga> yes, to some extent yes
<zyga> but the point was to bring the magic closer to snapd repo
<zyga> so that we see what's the state on boot
<zyga> right now that is locked away in an untested shell script in an initrd somewhere
<zyga> it's not exactly transparent :)
<zyga> in some way it also relates to snapd.snap and bases
<zyga> it would be good to have snapd in the loop of the initial mount namespace construction
<zyga> right now we cannot evolve it easily
<zyga> pedronis: while I have you: how long should I allow running app to inhibit refresh?
<pedronis> I need to think a bit, we have a policy for servers, but not sure it applies here
<zyga> I will set one week as a strawman for now
<pedronis> zyga: so yes writable-path config for /var/lib/snapd for core 18 and core 16 is different
<zyga> I remember that mvo wanted to simplify it
<pedronis> we'll need to chat with him
<mvo> zyga, pedronis I'm sort of here but would like to EOD - anything urgent?
<mvo> I did simplify wirtable-path, does it mean anyhting is missing?
<mvo> also remember core18 is smaller than core so some things just did not made any sense anymore
<pedronis> mvo: yes,  /var/lib/snapd is missing stuff in core 18
<pedronis> apparently
<zyga> mvo: I think it's a conversation for tomorrow
<pedronis> but is not urgent
<zyga> mvo: we are untangling the layers of why things are broken :)
<pedronis> and will probably be complicated to untangle at this point
<pedronis> anyway
<mvo> pedronis, zyga right - its missing stuff because in core we installed snapd so all the right dirs were there
<mvo> in core18 we don't anymore
<mvo> zyga: oh, i see
<pedronis> maybe
<mvo> zyga: its /var/lib/snapd in writable-path, correct?
<pedronis> but the writable-path config is also different
<pedronis> it was synced , now is persistent
<mvo> pedronis: I think we can make it transition
<mvo> that should fix things
<mvo> this means whatever was there before will be surfaced but only once
<pedronis> anyway I need to learn what those things mean :)
<mvo> synced is a terrible setting
<pedronis> and is not a topic for tonight at this point
<mvo> we should not use this
<mvo> yeah, lets sync on this tomorrow
<zyga> mvo: I think the issue is that what we assumed was the case,  directories being present in core16 because of mount namespace layout, are not true in core18 because the real set is constructed by ubuntu-image
<mvo> zyga: setting it to transition is worth a shoot
<mvo> zyga: lets chat about this in the morning
<pedronis> mvo: it's already set to transition
<pedronis> anyway  it's likely actually that the answer is more stuff that the snapd snap needs to do on setup
<zyga> re, sorry, small accident
<zyga> heh
<zyga> so
<zyga> go time sucks
<zyga> time is not restored across serialization
<zyga> not perfectly
<zyga> this upsets our conflict checker
<mup> PR snapd#6690 opened: overlord/snapstate: inhibit refresh for up to a week <Created by zyga> <https://github.com/snapcore/snapd/pull/6690>
 * zyga EODs again, for real
#snappy 2019-04-05
<mborzecki> morning
<brlin> morning
<zyga> Hey hey
<mborzecki> today's gonna be interesting
<zyga> Why? :-)
<mborzecki> zyga: alleged memleak, or rather trying to find out if we are the memory hogs
<mborzecki> pulled down some random ubuntu core 16 image, came with snapd 2.32.5, can't refresh core because no updates available, wth?
<wgrant> mborzecki: core updates have been disabled for the last 14h due to the memory hog situation
<wgrant> But I'm minutes away from reenabling them
<mborzecki> wgrant: thanks for the info
<zyga> Interesting
<zyga> Certainly more likely than pushing a deb to a repo
<mborzecki> this is actually quite interesting 2.32.5 vs 2.38 vs 2.37.4/2.38 classic https://paste.ubuntu.com/p/Vs65Wyg8XW/
<wgrant> mborzecki: core should be refreshable now.
<zyga> s/likely/fun/
<zyga> Iâm with the dog outside
<zyga> Iâll check back in the office
<mborzecki> wgrant: thanks, updating :)
<zyga> mborzecki: I have an idea
<zyga> Is it hotplug?
<mborzecki> zyga: idk, we can't turn off the feature anyway
<mborzecki> zyga: fwiw, this doesn't look so bad
<pedronis> mborzecki: to be clear, we more looking at kernel memory, than process memory at this point
<zyga> Did we change compiler version?
<pedronis> zyga: of course, remember we went from go 1.6 to go 1.10/1.11
<mborzecki> pedronis: yeah, what i mean is that there doesn't seem to be an easily visible regression
<mborzecki> pedronis: 2.32.5 was surely go 1.6
<pedronis> yes
<pedronis> think so
<zyga> Mmmmm
<zyga> Go changed the memory model recently
<zyga> Well it maps much larger structures into memory without compression
<zyga> But the garbage collector also changed significantly
<pedronis> zyga: 6621 has two reviews,  and is now used, could just land, no?
<pedronis> zyga: the question is, does it make the kernel use more space
<pedronis> anyway I made a suggestion in email to test that to mborzecki
<mborzecki> zyga: also memory is given back gradually in background, so rss will decrease but only after a while, we could call https://golang.org/pkg/runtime/debug/#FreeOSMemory though if the memory is lost elsewhere all this is in vain
<zyga> pedronis: I think Chipaca wanted it to have an approved dependency first
<zyga> But I will look
<zyga> Still afk
<zyga> pedronis: to the best of my knowledge it does use more kernel memory but it is a static, compile time decided cost
<pedronis> we need to find out how much it is on arm 32
<zyga> It is pretty huge AFAIK, dominates binary size
<zyga> But
<zyga> It is not a growing number
<pedronis> we are probably talking past each other
<mborzecki> pmap on 2.35.2 and 2.38 https://paste.ubuntu.com/p/xdm4tFhDwz/
<mborzecki> hm .text grew, idk what's the r---- section of snapd, but it changed a bit, rw--- snapd is probably .bss, there's a change there, but rather insignificant
<pedronis> mborzecki: you have email
<pedronis> mborzecki: as I said, I don't think there is something obvious happening that relates only to user space mem
<pedronis> no mvo yet to sync
<mborzecki> pedronis: btw. rebuilding with 1.6 might be some effort, we made a transition to "context" and updated some http request context related things in the process
<mborzecki> pedronis: 1.7 is probably worth a try though
<pedronis> mborzecki: we can do the reverse
<pedronis> buld 2.37 with 1.10
<pedronis> if the issue is really only go runtime
<zyga> back in the office now
<pedronis> it might be apparent just that way
<mborzecki> pedronis: right, that too
<pedronis> (it might be a combination of a lot of things, then it's harder)
<zyga> mborzecki: good idea on 2.37 with 1.10
<pstolowski> mornings
<mborzecki> ok, got 1.11 set up, and it's quite funny, https://paste.ubuntu.com/p/YFTYBSTmPJ/
<mborzecki> going to try 1.10 next
<zyga> mborzecki: ha
<zyga> fun indeed
<pedronis> mborzecki: interesenstingly though vsz is somewhat larger for 2.38 (not a problem, unless it really cuts into kernel resources though). anyway reminder the devices are arm 32
<abeato> mvo, morning!
<abeato> mvo, which is the current status of the systemd daemon-reload race? is the fix already in stable?
<zyga> HOOOOLY MOLY
<zyga> pidfd!!!!!
<zyga> hahahaha
 * zyga is super happy
<mvo> abeato: the systemd fix went to the distro yesterday, it will be part of the next stable core
<mvo> abeato: if its import for the customer we can do a .1 with just these changes
<abeato> mvo, hm, when is the next stable core snap expected?
<mvo> abeato: 4-6 weeks if nothing else comes up
<mvo> abeato: because 19.04 is released soonish we may do a .1 if we find any bigger issues this is why its a bit up in the air right now
<mvo> abeato: we are debugging a customer issue that may require a .1 but its a bit unclear where we stand on this right now (i.e. if its a snapd, kernel, $unknown issue)
<abeato> mvo, ok, I do not think it is extremely urgent, will let you know if that changes - it depends mostly on when we release the GA image
<mborzecki> 2.37 & 2.38 with go 1.10 https://paste.ubuntu.com/p/Snt9mqK3m5/
<pedronis> ~0.5G more vmem
<mup> PR snapd#6629 closed: overlord/snapshotstate: helpers for snapshot expirations (automatic snapshots 2/4) <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6629>
 * zyga spends some time to manage paperwork and the endless list of open browser tabs
<mup> PR snapd#6595 closed: tests: add regression test for systemctl race fix <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6595>
<zyga> mvo: what shall we do about core18?
<mvo> zyga: aha, sorry, I forgot about this, let me look at this
<zyga> mvo: do you want to HO?
<zyga> might be easier
<mvo> zyga: let me quickly poke at this for some minutes to familiarize myself
<mup> PR snapcraft#2522 closed: build providers: add API for friendly instance type names <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2522>
<pedronis> zyga: mvo: I need to be in that HO
<pedronis> if/when we have one
 * pstolowski lunch
<Chipaca> ask me if my parents' wifi goes away when they use the microwave
<mvo> zyga: lets talk after the standup, I have lunch now and then I have a meeting, maybe if this meeting is shorter we can also talk before
<zyga> mvo: ping me when you are ready to talk
<mvo> zyga: but yeah, we need to decide, I think I hvae a slightly better idea now what is going on.
<mvo> zyga: thanks again for raising this!
<pedronis> mvo: zyga: ping me when you have it
<zyga> ack
 * Chipaca â lunch
<mup> PR snapd#6691 opened: Move extractkernelassets <Created by kubiko> <https://github.com/snapcore/snapd/pull/6691>
 * zyga break
<zyga> ondra: reworded that PR a little
<ondra> zyga yeah more fitting
<ondra> zyga thanks :)
 * zyga really break now
<pstolowski> re
<zyga> Son_Goku: hey, on F30 I cannot get snapd update because of some gnome-software dependency mismatch,
<zyga> Son_Goku: is that expected?
<Son_Goku> no?
<Son_Goku> what are you seeing?
<zyga> I don't have that machine with me but it was saying something that gnome-software depends on snapd-auth-provider or something to that vein
<zyga> and that was it, no 2.38
<Son_Goku> fuck
<Son_Goku> snapd-login-service dependency is still in gnome-software
<Son_Goku> damn it
<Son_Goku> I have to put it back now
<zyga> :D
<zyga> Son_Goku: so what just happened?
<Son_Goku> well, I decided to rip out an old Provides
<Son_Goku> when snapd-login-service was retired, I obsoleted it by snapd
<Son_Goku> but gnome-software-snap requires it still :(
<zyga> sorry I didn't vote on the update before, I noticed others did
<zyga> but those must have been headless machines
<zyga> my laptop complained
<mborzecki> zyga: yup i tried the update in a headless vm
<pstolowski> mborzecki: https://github.com/snapcore/snapd/pull/6661 has 3 +1s, can land?
<mup> PR #6661: data/selinux, tests/main/selinux-clean: fine tune the policy, make sure that no denials are raised <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6661>
<mborzecki> pstolowski: i'm pushing the fix for the test zyga suggested
<pstolowski> ack
<jdstrand> oSoMoN: hey, I'm still slogging through the chromium approvals. it is a large snap so it takes a while for the next revision to be reviewed after I approve one
<oSoMoN> jdstrand, thanks!
 * Chipaca shakes his fist at doLinkSnap
<mvo> zyga, pedronis I am free now if you want we can chat about /var/lib/snapd/void and friends
<pedronis> mvo: I can join standup
<mvo> pedronis: I'm there now, ready when you are
<mvo> zyga: -^
<zyga> mvo: same
<zyga> joining
<mup> PR snapcraft#2520 closed: snap: set core as a base <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2520>
<mup> PR snapd#6616 closed: boot: add flag file "meta/force-kernel-extraction" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6616>
<mup> Bug #1823343 opened: Getting Started Intro out of date <Snappy:New> <https://launchpad.net/bugs/1823343>
<mup> PR snapd#6692 opened: interfaces: cleanup internal tool lookup in system-key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6692>
<mup> PR snapd#6693 opened: cmd: tweak internal tool lookup to accept more possible locations <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6693>
<mup> PR snapcraft#2523 opened: ci: improve travis integration conditionals <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2523>
<Chipaca> pedronis: you can't have an alias for a snap name, right?
<noise][> Chipaca: correct, no such thing
<Chipaca> noise][: I meant, an alias in one snap that was the name of a different snap
<Chipaca> noise][: like, aliasing tree-classic to 'tree', which is the name of a snap
<noise][> nope
<pedronis> Chipaca: you can but is very much discouraged because you cannot then install conflicting snaps around it in any way at the same time
<pedronis> we don't let you override the commands of another snap
<Chipaca> so this tree-strict and nano-strict thing is not gonna fly
<noise][> oh, i think i misunderstood
<pedronis> Chipaca: it depends, it means you cannot install nano and nano-strict at the same time
<Chipaca> pedronis: right, but what happens if you try?
<noise][> but you wouldn't
<pedronis> you get an error
<pedronis> about namespace conflicts
<Chipaca> i mean i'd like to see that ux
<pedronis> when you install the 2nd
<Chipaca> â¦ but i have enough on my plate already
<noise][> but the existence of `tree`, not installed, does not preclude a snap tree-strict from aliasing 'tree' , right?
<pedronis> no
<pedronis> it's up to the alias reviewer in the store
<pedronis> we didn't implement strict checks there about this
<Chipaca> I should clarify in the forum then
<Chipaca> pedronis: what do you mean by 'strongly discouraged' btw
<Chipaca> because the people reviewing and approving aliases didn't even bring it up
<pedronis> that if the snaps  are unrelated
<pedronis> you will just bring confusion into the world
<pedronis> a snap owns its name
<pedronis> you are basically giving it away
<Chipaca> pedronis: that doesn't sound like 'strongly discouraged' beyond the abstract sense. I mean, what steps have been taken to discourage it?
<noise][> it seems perfectly reasonable to me to allow for 'foo' and 'foo-classic' snaps that are the same thing but one with classic confinement.
<pedronis> noise][: there yare related though, which is actually not a typical case at all
<noise][> for the case outlined with tree or jq or whatever where there's a desire to be able to use them on Core systems
<pedronis> at it wasn't a typical case when aliases were designed
<noise][> both from the same publisher
<noise][> or i mean that would be the preferred scenario
<pedronis> Chipaca: the guideline around aliases as always been to avoid clashes
<brlin> popey suggested using a separate `classic` track for the alternative classic confined versions, which may mitigate the problem
<pedronis> Chipaca: that included with other snap names, maybe is not splelt out but was in our mind
<brlin> For the alias problem if there's a popular fork the same name software, like `blender-some-popular-edition`, people might want to make alias of the original name
<Chipaca> brlin: o/
<Chipaca> now I just want to have a snap with an alias for another snap just to see how it explodes
<pedronis> Chipaca: I can point you at the errors
<noise][> classic confinement is at the snap level, can't be per-track
<pedronis> noise][: classic confinement just means you can have classic confinement in some revisions
<pedronis> whether we enforce more I don't know
<pedronis> Chipaca: to be clear we didn't design thinking that this would be a common case that we would need to guide people around
<noise][> right, i mean we don't have a way to selectively enforce
<Chipaca> brlin: updated both topics with a summary of the above. I don't think [revoked] is correct â¦ even if I were correct, i'm not a reviewer :-)
<brlin> noise][: Then I guess the separate name space and overriding alias is the only way to go :-/
<Chipaca> to be clear, _allowing_ classic is not per-track, but a snap being classic is per revision
<noise][> what Chipaca said :)
<Chipaca> so you _could_ have a channel be classic and a channel be strict, but you could ship a classic one in the strict track by accident
<noise][> this certainly could bear more discussion, but it's Friday afternoon
<noise][> yeah, so it's possible we could allow that route for some snaps and just have to trust the publisher not to break people on the strict track
<Chipaca> also bears don't like discussion
<noise][> and then at some point add guardrails, but i'd like to explore this more before recommending such an approach
<pedronis> Chipaca: errors are here  https://github.com/snapcore/snapd/blob/master/overlord/snapstate/aliasesv2.go#L339 and here https://github.com/snapcore/snapd/blob/master/overlord/snapstate/aliasesv2.go#L368
<brlin> The snap edit page on LaunchPad seemed to support this fashion AFAICT https://usercontent.irccloud-cdn.com/file/prUHOKkw/image.png
<brlin> FYI the users of the `nano` snap are currently blocked from auto-updates due to the confinement switch
<Chipaca> yeah, confinement switches are nasty
<Chipaca> they'll be getting warnings at some point
<noise][> that's why, e.g. with tree, that i suggest not messing with confinement of the existing snap
<Chipaca> that's #1811063 FWIW
<mup> Bug #1811063: "snap refresh" does not report failure to update because snap switched to classic confinement <snapd:In Progress by chipaca> <https://launchpad.net/bugs/1811063>
<noise][> anyway, i need to run, happy weekend!
<Chipaca> same here
<Chipaca> brlin: ttfn, have a good one
<pedronis> also to be clear you can install both snaps, but you need to manouver around, and the one with the actual name (vs the alias) needs to win
<pedronis> (you'll need to use snap unalias and/or install --unaliased)
<brlin> Chipaca: Bye!
<mup> PR snapcraft#2523 closed: ci: improve travis integration conditionals <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2523>
<cachio> mvo, hey
<cachio> mvo, I know which is the problem with the install --dangerous in core18
<zyga> cachio: tell us!
<cachio> zyga, so, the problem is in the tests
<cachio> basically when it is installing --dangerous is downloading the core snap as part of that process
<cachio> even when we have the core snap in /var/lib/snapd/snaps
<zyga> oh
<zyga> that's very curious
<zyga> cachio: thank you
<cachio> zyga, do you know if snapd is searching in the state to define if a snap could be in the cache?
<zyga> cachio: I don't know yet, we will check it out
<zyga> snapd uses the cache for sure
<zyga> but repackaged core has different cache
<zyga> so perhaps that's one issue
<zyga> s/cache/hash/
<cachio> zyga, https://paste.ubuntu.com/p/J3w8bxrqfm/
<cachio> in the first install it downloads the core snap, even when it is already in /var/lib/snapd/snaps/
<cachio> but second time it is not downloading it
<cachio> zyga, I don't know why
<zyga> cachio: what is in /var/cache/snapd?
<zyga> the one in /var/lib/snapd/snaps is, I think, irrelevant now
<zyga> the one in /var/lib/cache/snapd matters
<zyga> I mean, irrelevant only if not installed
<cachio> zyga, https://paste.ubuntu.com/p/qvj5QCgkwK/
<zyga> that's odd
<zyga> so some back story
<zyga> last week, for local testing in qemu
<zyga> I wrote some patches that let me seed /var/cache/snapd with heavy snaps
<zyga> then tests only fetch assertions online, speeding up testing tremendously
<zyga> the way I did this was by keeping /var/cache/snapd.tar.gz in the qemu image and unpacking it early in the test prepare
<zyga> it works for that purpose
<zyga> the files there are not .snap files but instead long file names based on some hash of the content
<zyga> snapd uses that cache as hardlink source AFAIK
<zyga> so I'm surprised to see none of that in the cache directory here?
<zyga> ah
<zyga> sorry
<zyga> I'm mistaken
<zyga> the path is different
<zyga> the correct path is /var/lib/snapd/cache
<zyga> that's the one
<zyga> I was arguing with chipaca to change it because it's odd that we have two cache directories
<zyga> anyway
<zyga> please look at /var/lib/snapd/cache
<zyga> before / after snap install --dangerous
<cachio> https://paste.ubuntu.com/p/RdbGtyc79c/
<cachio> zyga, seems to be there
<zyga> that's more like it
<zyga> what happens when you remove and install a snap?
<zyga> it should reuse that cache and do things "instantly"
<cachio> zyga, the core is not installed in my machine but it is in cache dir
<cachio> so, I think I know what I need to change to cache snaps in the tests
<zyga> I will check later (eating dinner now) but perhaps --dangerous implies some of the hash based logic doesn't get used
<cachio> what we are doing currently doesn't work
<zyga> cachio: cool
<zyga> cachio: looking forward to that patch :D
<cachio> zyga, --dangerous works well
<cachio> but basically we need to install/remove the snap to cache it before we save the state
<cachio> that should be enough
<zyga> yep
<cachio> currently we are copying to /var/lib/snapd/snaps the .snap file but it is not enough
<zyga> cachio: as a hint
<zyga> cachio: perhaps to speed things up more
<zyga> cachio: instead of creating a tarball of /var/lib/snapd/cache
<cachio> zyga, yes, could be, I'll make then change
<zyga> cachio: make a directory, say /var/lib/snapd-cache
<cachio> zyga, thanks for the help
<zyga> cachio: wait :)
<zyga> cachio: and hardlink the cache items there
<zyga> cachio: then instead of unpacking that tarball
<zyga> cachio: hardlink them back
<zyga> cachio: this will be instant
<zyga> cachio: and will work just like a tarball would
<cachio> zyga, perfect, I'll do that
<cachio> thanks for the info
<zyga> cachio: cp has some options, perhaps there are some that do hardlink copies
<zyga> cachio: good luck!
<cachio> zyga, thnanks
<cachio> enjoy your weekend
<zyga> likewise :)
<pedronis> --dangerous doesn't use the cache
<pedronis> (the cache is for downloads)
<zyga> pedronis: oh?
<pedronis> why would it
<pedronis> you are giving it a snap here
<zyga> pedronis: for dependencies
<zyga> pedronis: it downloads core over and over
<pedronis> that is stranger
<cachio> pedronis, I think install --dangerous is using the cache
<cachio> I just see that the core is not being downloaded it is correctly cached
<cachio> pedronis, the problem we have is that we are caching the snaps in the wrong way on our test suite
<cachio> so when I run on the boards and vms 5/6 in parallel in my home all the installs we do are downloading hte core
<cachio> and this is the bottleneck which is causing the install --dangerous is getting stuck
<mvo> 6687 needs a second review, should be simple
<mup> PR snapd#6689 closed: tests: run create-user on core devices <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6689>
<mup> PR snapd#6694 opened: tests: improve how snaps are cached <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6694>
 * cachio afk
<mup> PR snapcraft#2524 opened: Snapcraft try <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2524>
<jdstrand> pedronis: ok, I got through all the store review stuff and knocked out 5 PR reviews (well, one was asking for a different approach). I will do PR 6502 and PR 6605 on monday
<mup> PR #6502: dirs,overlord/snapstate: add Soft and Hard refresh checks <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6502>
<mup> PR #6605: cmd/libsnap,osutil: fix parsing of mountinfo <Created by zyga> <https://github.com/snapcore/snapd/pull/6605>
<jdstrand> zyga: fyi ^
<jdstrand> there is a small chance I'll look at those over the weekend, but let's say 'by my eod Monday'
<jdstrand> pedronis: I also responded to https://forum.snapcraft.io/t/phase-1-of-opt-in-per-snap-users-groups-aka-the-daemon-user/10624/15
<ijohnson> jdstrand: hey! the dockerd daemon now needs to use data inside $XDG_RUNTIME_DIR, which ends up being /run/user/0 for the daemon, but this dir isn't created... what's the eventual resolution to lp #1656340 do you think?
<mup> Bug #1656340: XDG_RUNTIME_DIR is not created on app startup <bionic> <cosmic> <eco-team> <xenial> <Snappy:Triaged by zyga> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1656340>
<ijohnson> for now I will just overwrite that to be $SNAP_COMMON/run and it works, but just curious as I seem to recall discussion around that bug recently on this channel
#snappy 2019-04-06
<mup> PR snapd#6695 opened: Interface to connect to jack server (either jack1 or jack2) <Created by ymauray> <https://github.com/snapcore/snapd/pull/6695>
<pedronis> jdstrand: thanks
<mup> PR snapd#6696 opened: image: simplify prefer local logic  and fixes <Created by pedronis> <https://github.com/snapcore/snapd/pull/6696>
<mup> PR snapd#6685 closed: image: prefer local for snapd/core snaps <â Blocked> <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6685>
<mup> PR snapd#6436 opened: interfaces: add system-backup interface <â Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6436>
<LinAGKar> zyga: Just letting you know, I currently have snaps working on Tumbleweed again.
#snappy 2020-03-30
<mup> PR snapd#8374 opened: .github: register a problem matcher to detect spread failures <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8374>
<mup> PR snapd#8375 opened: github: always run the "Discard spread workers" step, even if the job fails <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8375>
<mborzecki> morning
<mborzecki> hmm core20 hangs in spread tests again?
<mborzecki> looks like it's hitting job kill-timeout when rebooting during prepare
<mborzecki> hmm perhaps https://github.com/snapcore/snapd/pull/8373 fixes that
<mup> PR #8373: tests/lib/prepare.sh: use only initrd from the kernel snap <UC20> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8373>
<zyga> o/
<jamesh> morning zyga
<zyga> hey james
<jamesh> zyga: here's a simple PR for the github actions CI: https://github.com/snapcore/snapd/pull/8375
<mup> PR #8375: github: always run the "Discard spread workers" step, even if the job fails <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8375>
<jamesh> make the cleanup run even if the tests fail
<zyga> super nice
<zyga> thank you James
<zyga> I didn't know about the implicit if
<jamesh> I also had a go at adding a problem matcher: it adds the error to the annotation list, but doesn't jump to the log line as I thought it did: https://github.com/snapcore/snapd/pull/8374
<jamesh> (maybe I was misremembering how that worked)
<mup> PR #8374: .github: register a problem matcher to detect spread failures <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8374>
<zyga> I love this :)
<zyga> little by little but even this is so much better than what we had before
<zyga> that's fantastic
<zyga> I think we could move more stuff over this week
<zyga> let's see what we can get
<mborzecki> zyga: jamesh: hey
<jamesh> hi mborzecki
<mborzecki> wish the uc20 spread job actually worked
<mborzecki> mvo: hey
<zyga> hey mvo
 * zyga is pre breakfast still so will go away for a while 
<jamesh> zyga: Longer term, it might make sense to have Spread output error annotations when it thinks it is running under the Github runner
<jamesh> it could provide extra info like the task file name
<mborzecki> jamesh: hopefully the runner makes it easy to detect such scenario
<zyga> jamesh: yeah, I think that would be great, spread has specific travis features, it could have github features
<zyga> I think the goal should be to phase out travis
<zyga> so that nobody is stuck waiting
<zyga> then optimize
<mborzecki> otherwise it's ugnly job level  env vars again or somesuch :/
<jamesh> mborzecki: there are environment variables it is documented to set, similar to Travis
<jamesh> https://help.github.com/en/actions/configuring-and-managing-workflows/using-environment-variables says it will always set GITHUB_ACTIONS=true
<mborzecki> ha nice
<mvo> hey mborzecki and zyga !
<zyga> how are you doing? it's quite cold today
<zyga> yesterday was both +18 and -2 at night (and snow)
<mborzecki> zyga: it was ~13C before noon, then 2 with a snow/rain mix in the afternoon here
<mborzecki> felt like the afternoon was a completely different day
<zyga> breakfast time
<mup> PR snapd#8375 closed: github: always run the "Discard spread workers" step, even if the job fails <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8375>
<mup> PR snapd#8365 closed: seed: add Info() method for seed.Snap <Simple ð> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8365>
<pstolowski> morning
<mvo> hey pstolowski - good morning
<mvo> fwiw lxd tests are broken right now
<mvo> not sure why yet, but it seems pretty consistent
<mup> PR snapd#8374 closed: .github: register a problem matcher to detect spread failures <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8374>
<jamesh> mvo: thanks for doing the merges.  I think the problem matcher is about as good as it can get: further improvements would probably need to happen in Spread itself
<mvo> jamesh: yeah, I was thinking that we might need to modify spread
<mvo> jamesh: that's fine, thanks again for this, it's so much better than what we had before
<jamesh> mvo: e.g. it would be nice to tie the error to the task.yaml file, but the problem matcher can only use information present in the error message
<mborzecki> power outage :/ moved to my parent's
<mborzecki> travis job failed again in #8373
<mup> PR #8373: tests/lib/prepare.sh: use only initrd from the kernel snap <UC20> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8373>
<mvo> mborzecki: probably the lxd issue
<mvo> mborzecki: also, does it have two reviews?
<mborzecki> kill-timeout reached after mar300623-305765 (google:ubuntu-core-20-64:tests/regression/) reboot request
<mborzecki> mvo: all test suites failed on uc20
<mborzecki> (on prepare)
<mvo> mborzecki: uh, no that then :)
<mvo> mborzecki: right, because of the kernel/initramfs issue?
<mborzecki> wish the console was easily accessible
<mborzecki> mvo: yeah
<mvo> mborzecki: does it only fail in gce or also with qemu?
<mborzecki> mvo: haven't tried qemu yet, i'll try to obtain the image from gce
<zyga> re
<mvo> mborzecki: yeah, qemu should give a lot more visiblity into this, so we still don't know what is going on :( ?
<zyga> sorry, it's hard to organize kids still
<pedronis> mvo: hi, #8325 has a conflict now also as we know needs a bit more work
<mup> PR #8325: snap-bootstrap: copy auth data from real ubuntu-data in recovery mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8325>
<mvo> pedronis: thanks, look today (many meetings this morning unfortunately)
<mborzecki> any clue why it's no longer possible to connect via ssh to a spread node?
<mborzecki> spread can do it, but once i got the debug shell, i cannot establish any new ssh connections
<pedronis> mborzecki: hi, I made a comment in the stand up notes about a thing that landed Friday, also did review some of your open PRs
<mborzecki> pedronis: thanks!
<zyga> re
<mborzecki> pedronis: also wondering whether we should support GET on /v2/systems/{label}, but there does not seem to be any potential use cases atm
<pedronis> mborzecki: we can add it later, but yes would leave it alone for now
<mborzecki> ack
<mup> PR snapd#8376 opened: daemon: make POST /v2/systems/<label> root only <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8376>
<pedronis> degville: hi, could you look at this when you have a moment: https://github.com/snapcore/snapd/pull/8372#discussion_r400026498
<mup> PR #8372: [RFC] devicestate: generate warning if seeding fails <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8372>
<degville> pedronis: morning - looking now!
<mborzecki> sooo when i apt install openssh-server to pull in the update of sshd, i can log in over ssh again
<zyga> Brb
<mborzecki> i pulled the uc20 image built from master branch and it seems to work
<zyga> mborzecki: cgroup code I mentined yesterday is in 8377
<mborzecki> zyga: ack
<mup> PR snapd#8377 opened: sandbox/cgroup: add ProcessPathInTrackingCgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/8377>
<zyga> I'll get some mint
<zyga> brb
<mborzecki> moving back home
<zyga> shit, I forgot about the mint/tea
<zyga> brb
<zyga> really
<zyga> I'll push a fix for session-tool, sorry for annoying failures everyone
<mup> PR snapd#8378 opened: o/configcore: introduce core config handlers (3/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8378>
<mborzecki> and back
 * zyga stresses session-tool to see if the issue is gone
<pedronis> mvo: commented on #8325 also there is stil a conflict
<mup> PR #8325: snap-bootstrap: copy auth data from real ubuntu-data in recovery mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8325>
<mup> PR snapcraft#2997 opened: specifications: progressive delivery <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2997>
 * zyga is surpsised by the surge of snow outdoors!!!
<thresh> since https://snapcraft.io/docs/personal-files-interface says it requires snapd 2.37+, how can I check for snapd version in the wrapper script that launches my app?
<zyga> thresh: don't use assumes: [snapd2.37]
<zyga> https://snapcraft.io/docs/snapcraft-yaml-reference and search for "assumes"
<thresh> zyga, will that force user to upgrade to the needed version if they somehow fetch my snap on an older machine?
<zyga> thresh: it will prevent installation on an older snapd
<thresh> that is not something I would want, then
<zyga> thresh: but we're not seeing old snapd's in the wild
<zyga> thresh: why?
<zyga> thresh: snapd has a self-update mechanism
<thresh> OK
<zyga> thresh: virtually everyone runs the current stable version
<thresh> I mean, I assumed not everyone updates
<thresh> Thanks
<zyga> good luck :)
 * zyga cannot reproduce session-tool failure on ubuntu, I'll try some other distro and send a PR next
<mborzecki> well, there are those that use snapd from distro repositories
<mborzecki> but most major distros should be covered and have something quite recent available
<pedronis> mvo: this is fixed, right? https://bugs.launchpad.net/snapd/+bug/1867755
<mup> Bug #1867755: snapd fails to build in focal, unit test clientSuite.TestClientFindFromPathErrIsWrapped fails <snapd:New> <https://launchpad.net/bugs/1867755>
<mvo> pedronis: yes, let me close it
<ijohnson> morning folks
 * ijohnson is super tired today for some reason
<cwayne> ijohnson: same here, but i think just cause it's rainy and gloomy and monday
<ijohnson> cwayne: since this is happening to both of us I think it's totally fair to blame the CDG airport
<cwayne> way ahead of you
<ijohnson> (in addition to the mondayness of today)
<cwayne> it is pretty peak monday
<ijohnson> how's your treadmill working out
<cwayne> not too badly, averaging about ~4mi per day so far on it i think
<ijohnson> nice
<cwayne> everyone laughed at me for panic buying a treadmill, then they closed the gyms the next day and now i'm supposed to stay home so HA
 * ijohnson has gotten really bad at not exercising more with the lockdown and all
<cwayne> i've been exercising more since hte lockdown, but ive also eaten everything on planet earth.
<cwayne> like my wife keeps stockpiling food
<cwayne> and them im like OH SHIT FOOD
<cwayne> and then its gone.
<ijohnson> it's a good thing you're not in MN otherwise we both would have eaten all the food here, it'll probably take us a while to eat our way through the eastern US and new england before there's none left
<cwayne> christina goes "that should last us a week" and then im just like "lol sure watch this"
 * ijohnson imagines cwayne going "hold my treadmill"
<cwayne> total re-emergence of 2012 vintage fat cwayne
<cwayne> fun times
<mborzecki> cmatsuoka: cachio: standup is now ;) tz was switched over the weekend
<cachio> ah
<cachio> ok
<cmatsuoka> oh ouch
<mup> PR core20#22 closed: run-snapd-from-snap: don't try to load a snapd snap from the seed anymore <Created by anonymouse64> <Merged by xnox> <https://github.com/snapcore/core20/pull/22>
<zyga> brb, coffee
<zyga> amazing sun + snow experience toda
<ijohnson> mvo did you see that folks responded on the lxd bug ?
<ijohnson> zyga: ackk what's the special mount ns experimental setting I need to set to let the maas snap refresh ?
<ijohnson> `snap set system experimental.<something> true` ?
<ijohnson> nvm I see that it's `robust-mount-namespace-updates`
<zyga>  ijohnson snap set core experimental.robust-mount-namespace-updates=true
<ijohnson> yep that's it
<mvo> ijohnson: I did not, let me check
<zyga> wall of snow outdoors!
<roadmr> yay! I want snow, all we have had is 2 crappy days of rain (even indoors, stupid roof leak)
<cachio> mvo, I tested the lxd test installing lxd from edge and hte error is the same
<cachio> mvo, I still see + lxd.lxc exec my-nesting-ubuntu -- lxd.lxc exec my-inner-ubuntu -- echo from-the-INSIDE-inside
<cachio> Error: EOF
<mvo> cachio: nice, let's add this to the LP bugreport
<cachio> I already did ti
<cachio> it
<cachio> mvo, I forgot to ask about 2.44.1 to stable today
<cachio> it is ok to strart the pregressive release today?
<mvo> cachio: either today or tomorrow, if all looks good
<mvo> cachio: fine to start phasing today
<cachio> mvo, nice, thanks
<mborzecki> pedronis: we want /var/lib/snapd/seed RO, but /run/mnt/ubuntu-seed is TBD
<pedronis> yes
<mborzecki> ok, cool
<mup> PR pc-amd64-gadget#39 opened: Drop no longer used snap_kernel fallback <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/39>
<mup> PR snapd#8379 opened: many: comment or avoid cryptic snap-ids in tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/8379>
<alan_g> cachio, looks like the rawhide image needs refreshing: https://api.travis-ci.com/v3/job/308689304/log.txt
<cachio> alan_g, hui, fedora refresh is scheduled for today, it is gonna happen in few hours
<cachio> alan_g, I'll let you know when it is ready
<alan_g> :)
<mup> Issue core20#29 opened: core20 ubuntu-seed mount point should be read only <Created by xnox> <https://github.com/snapcore/core20/issue/29>
<mup> PR core20#30 opened: Make /var/lib/snapd/seed bind-mount ro <Created by xnox> <https://github.com/snapcore/core20/pull/30>
<zyga> brbb
<mup> Issue core20#29 closed: core20 ubuntu-seed mount point should be read only <Created by xnox> <Closed by xnox> <https://github.com/snapcore/core20/issue/29>
<mup> PR core20#30 closed: Make /var/lib/snapd/seed bind-mount ro <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core20/pull/30>
<mup> PR pc-amd64-gadget#39 closed: Drop no longer used snap_kernel fallback <Created by xnox> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/39>
<thresh> so I've been rereading the snapcraft.yaml syntax docs, and found out I didnt set license: and title:.  I did, but now I get "Issues while validating snapcraft.yaml: Additional properties are not allowed ('title', 'license' were unexpected)"
<thresh> yml is at https://code.videolan.org/thresh/vlc/-/blob/snap-fixes/extras/package/snap/snapcraft.yaml#L6
<thresh> it's on snapcraft, version 2.43.1+18.4
<thresh> and an unrelated question, do I need an avahi-observe interface if I already have network?
<zyga> re
<zyga> mborzecki: I've reduced the failing case and added logging to the tool itself
<zyga> mborzecki: now it doesn't fail, I wonder if that's because of (perhaps) synchronization due to logging and set -x
<zyga> thresh: I think license has a long-standing issue, as for title, I think it's gone (but I could be wrong)
 * zyga goes away to eat dinner
<zyga> re
<zyga> INFURIATING it keeps working
<zyga> mvo: as for debian snapd package, you didn't commit the change to vcs
<zyga> mvo: the salsa git repo seems out of date (2.37 vs 2.44.1)
<thresh> how do I set the license that is shown in snap info vlc then?
<thresh> now it's "unset"
<zyga> thresh: you can set it but I don't know if this will fly through the store,
<zyga> CC degville ^ do you know if licenses work?
<pedronis> it's meant to be set through the store atm
<thresh> It's set in the store: License GPL-2.0+
<thresh> as from https://snapcraft.io/vlc
<degville> zyga / thresh: yeah, it's in the store page for a snap (https://snapcraft.io/docs/using-the-snap-store)
<thresh> degville, thanks, I see it's set in the store: https://i.imgur.com/WKFIOLz.png, but I don't see it in "snap info vlc": https://i.imgur.com/uwIGcd8.png
<mup> PR snapd#8380 opened: tests: add LXD_CHANNEL environment <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8380>
<pedronis> thresh: snapd takes it from the snap
<pedronis> not all the dots are connected here
<thresh> that sounds like a mess :-)
<thresh> where do I file a bug to get it fixed?
<pedronis> thresh: well, snapcraft should let you set a license
<pedronis> the snapd side is this: https://bugs.launchpad.net/snappy/+bug/1853670
<mup> Bug #1853670: snap always shows license as 'unset' after install <Snappy:Triaged by pedronis> <https://launchpad.net/bugs/1853670>
<pedronis> there's a long forum thread as well
<pedronis> pointed by that bug
<thresh> snapcraft doesnt let me set one, I get "Additional properties are not allowed" when providing it
<thresh> so I guess the consensus moved to setting it on the store only
<mvo> zyga: I did commit to my repo I think
<mvo> zyga: and iirc there is a MP for my repo to the shared one
<zyga> ah, I see
<zyga> I guess that's why
<pedronis> thresh: there is no final consesus yet
<zyga> thresh: so I just checked
<zyga> thresh: I made a snap last weekend
<zyga> and I did set a license
<zyga> when I don't have it
<zyga> snap info ...
<zyga> doesn't show the license (it says unknown)
<zyga> when I install it
<zyga> I *do* see the license
<zyga> thresh: I set the top-level "license" field to a valid SPDX expression
<mup> PR snapd#8381 opened: tests: skip lxd test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8381>
<thresh> hmm
<thresh> thanks for your help
<ijohnson> thresh: also note that you may have an older version of snapcraft which doesn't understand new keys, are you using snapcraft from the deb or from the snap ?
<zyga> ok, 20K iterations of the tool, I suspect there's something I did that fixed this bug
<zyga> now let me think what I did
 * zyga checks diff
<thresh> ijohnson, I'm using the snapcraft version from Ubuntu bionic, 2.43.1+18.04
<thresh> from a .deb
<zyga> thresh: snap install snapcraft --classic
<mup> PR snapd#8382 opened: packaging: detect broken seed during focal and disable it <Created by mvo5> <https://github.com/snapcore/snapd/pull/8382>
<ijohnson> thresh: then your snapcraft is certainly out of date
<ijohnson> see zyga's comment
<thresh> not sure that's possible since my build environment is in a docker container
<thresh> but we'll see
<zyga> ah
<zyga> then probably not
<zyga> can you not use docker?
<thresh> not really, VLC CI uses it extensively
<zyga> hum
<zyga> thresh: please ask in #snapcraft
<zyga> I don't really know
<ijohnson> thresh: there are ways to use modern snapcraft inside a docker container
<zyga> I haven't tried docker in years
<zyga> and not following the set of current trends
<zyga> as to which fork to use
<zyga> thresh: note that there _is_ one thing that may help you
<zyga> thresh: snapcraft has a mode where it "destroys" the environment by installing deps directly onto the system
<thresh> I assume those ways are: setting up systemd inside, and dropping all security boundaries docker (might) provide
<zyga> thresh: but please ask in #snapcraft for details
<thresh> thank you zyga!
 * zyga reproduced the error and has more logs
<zyga> ha
<zyga> I see where it's failing in pam
<zyga> enabled debug in pam_systemd.so and should see the "warning" that makes it fail
<zyga> I'm so happy
<zyga> I know why it fails :)
<zyga> and better yet, I think I know how to fix it (or work around it at least)
<zyga> I'll make one last coffee of the daty
<zyga> *day
<zyga> brb, going for that coffee now
<ijohnson> thresh see https://snapcraft.io/docs/build-on-docker
<ijohnson> sorry bad internet connection right now, keeps cutting out on me
<thresh> ijohnson, thanks!  is that image already published somehwere on docker hub?
<zyga> mvo: reading now
<zyga> mvo: https://github.com/snapcore/snapd/pull/8382#pullrequestreview-384099150
<mup> PR #8382: packaging: detect broken seed during focal and disable it <Created by mvo5> <https://github.com/snapcore/snapd/pull/8382>
<mvo> zyga: looking
<zyga> ha
<zyga> I have the proof of what is failing
<zyga> https://pastebin.ubuntu.com/p/sGjFSkdMJh/
<zyga> session startup is cancelled
<zyga> because of session termination
<zyga> I've reduced my test case to simple session-tool -u test true # twice
<zyga> without synchronization it will fail
<zyga> adding synchronization fixes it
<zyga> but I need to think how to expose that to session-tool
<zyga> specifically since it is needed to run in the background for some tests
<zyga> one way of solving that would be to alter the shutdown time
<zyga> via logind configuration
<zyga> this way session-tool -u test foo; session-tool -u test bar; could run in one session
<zyga> uh, the relevant part was cut
<zyga> er-l:session): Failed to create session: Start job for unit user-12345.slice failed with 'canceled'
<mup> PR snapcraft#2997 closed: specifications: progressive delivery <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2997>
<ijohnson> alright I'm back from lunch and hopefully my internet is stable again
<mup> PR snapd#8270 closed: store: support for search API v2 <Needs Samuele review> <Squash-merge> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8270>
<mup> PR snapd#8381 closed: tests: skip lxd test <Simple ð> <Created by sergiocazzolato> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8381>
<mup> PR snapd#8383 opened: store: support for search API v2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8383>
<mup> PR snapd#8384 opened: tests: run "lxd" test again (reverts PR#8381) <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8384>
<mup> PR snapd#8380 closed: tests: add LXD_CHANNEL environment <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8380>
<mup> PR snapd#8379 closed: many: comment or avoid cryptic snap-ids in tests <Simple ð> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8379>
<cachio> zyga, hey, I see this in bionic https://paste.ubuntu.com/p/KfDCxsxTcS/
<zyga> checking
<cachio> this is the branch which tests the image weekly update
<zyga> (except it does not load)
<cachio> zyga, same errror for mount-ns:inherit
<zyga> hmm
<zyga> ok, now it loaded
<ijohnson> zyga: cachio: looks like there's a new mount for efivars, is this with a new / different image ?
<zyga> oh
<zyga> efivars
<zyga> you've booted a efi system
<cachio> it is a new image
<cachio> ijohnson, not sure if efi is enabled on that one
<ijohnson> hmm I wonder if we need a different set of expected mount ns data files for this new bionic image
<ijohnson> cachio: how is the bionic image different? is it just updated ?
<mup> PR snapcraft#2998 opened: CODE_STYLE: update to reflect latest conventions <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2998>
<cachio> I'll check because ubuntu cloud is enabling efi in many new images
<zyga> cachio: were we booting in legacy bios before?
<zyga> cachio: I'm pretty sure this is not specific to bionic
<zyga> it's been there forever (since 2004) if you used efi
<cachio> checking focal
<zyga> I could be wrong but just check you systems
<zyga> do you have that mounted?
<ijohnson> hmm yeah if that's the case it's easier to change the singular bionic image dataset, it would be annoying though if we get different images and have to have different datasets
<cachio> focal works well
<zyga> I'm happy to have a efi vs legacy bios dataset for specific releases assuming it's a one way trend
<ijohnson> I mean I have that mounted but I also use a UEFI system so I don't think that's representative
<zyga> cachio: can you run "bootctl"
<zyga> cachio: on that new image
<zyga> and tell me what it prints?
<ijohnson> cachio: is this happening on all bionic images now?
<cachio> I just saw that in the new one
<cachio> which I created to update the image
<cachio> ijohnson, let me check on travis
<zyga> cachio: can you please check bootctl
<zyga> cachio: are images somehow packaged with information on how to boot them
<zyga> ?
<cachio> in that image, I am creating it again
<cachio> zyga, I am starting the instance
<cachio> to run bootctl
<zyga> thanks
<zyga> cachio: when you start the instance, do you use GCE dashboard?
<zyga> cachio: I wonder if there's any information about how it boots there
<zyga> (I'm not familiar with GCE)
<cachio> I can check that
<zyga> that FS would for sure not be mounted on legacy boto
<zyga> *boot
<zyga> and since we've never seen it before it's the only explanation I can think of
<cachio> zyga, https://paste.ubuntu.com/p/yqqsVTRyPR/
<zyga> yeah
<zyga> this is botoed in efi mode
<zyga> can you boot the previous image?
<zyga> I mean, that's not bad, we can adjust the test to just expect this
<zyga> if you want to take it forward in EFI mode
<cachio> zyga, yes
<zyga> please just let me know if we know how this happened
<zyga> if this is something GCE changed
<zyga> or we (ubuntu publishing the images) changed
<zyga> or what?
<zyga> and let me know
<zyga> it's late so I won't touch this today
<zyga> but I can adjust this easily tomorrow
<cachio> ubuntu is publishing the images with that chagne
<cachio> I just install some dependencies on top of that
<zyga> can you ask the cloud team about this change
<cachio> and do some other configurations
<zyga> is this an accident
<zyga> or something they did on purpose
<cachio> zyga, this is the old one https://paste.ubuntu.com/p/nW94yvZKV6/
<zyga> hmmm
<zyga> so it's also booted with efi
<cachio> zyga, do you know who is the main contact for asking that?
<zyga> I don't know
<zyga> but it seems that there's more to it than that
<zyga> ah
<zyga> sorry
<zyga> I'm blind
<zyga> wrong tab
<zyga>     Not booted with EFI
<zyga> so the old image was legacy
<cachio> yes
<zyga> new image is EFI
<zyga> ask around in ubuntu-server maybe
<zyga> or check the directory for a contact person that will redirect you
<cachio> ok
<zyga> you can file a bug and assign it to me to fix the test to handle EFI
<zyga> just include that diff from the test
<zyga> and if you can, a way to run against the new image to confirm
<cachio> zyga, sure, thanks
<zyga> thank you for bringing this up :)
<mup> PR snapcraft#2998 closed: CODE_STYLE: update to reflect latest conventions <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2998>
 * zyga fires up final test and goes home
 * zyga waves
<zyga> see you tomorrow ijohnson, cachio and cmatsuoka
<ijohnson> have a good night zyga
<cmatsuoka> good night zyga
<cachio> zyga, see you
<cachio> zyga, lp:1869788
<cachio> thanks
 * cachio afk
<mup> PR snapcraft#2999 opened: requirements: uprev python-apt to 1.6.0 (bionic package) <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2999>
<mup> PR snapcraft#3000 opened: repo: use python-apt's fetch_binary implementation <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3000>
<mup> PR snapcraft#3001 opened: repo: type annotations and mypy fixes for base <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3001>
<mup> PR snapcraft#3002 opened: repo: use functools.lru_cache for dpkg -L queries <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3002>
<mup> PR snapcraft#3003 opened: repo: always use host source lists and remove those found in plugins <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3003>
#snappy 2020-03-31
<mup> PR snapcraft#3004 opened: storeapi: add channel-map endpoint <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3004>
<mup> PR snapcraft#3003 closed: repo: always use host source lists and remove those found in plugins <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3003>
<mup> PR snapcraft#3001 closed: repo: type annotations and mypy fixes for base <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3001>
<mup> PR snapcraft#3002 closed: repo: use functools.lru_cache for dpkg -L queries <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3002>
<mborzecki> morning
<mborzecki> finally some green in PRs, however the status from travis was not updated for somer PRs even though the actual job was successful
<mborzecki> mvo: hey
<mborzecki> mvo: the LXD PR is green
<mvo> mborzecki: nice
<mvo> mborzecki: hm, that's strange, I don't see an update
 * mvo is confused
<mborzecki> mvo: hm? try refreshing the page
<mup> PR snapcraft#3005 opened: Change dotnet runtime version from snapcraft.yaml <Created by amka> <https://github.com/snapcore/snapcraft/pull/3005>
<zyga> good morning
<zyga> man it's late today
<mborzecki> zyga: hey
<zyga> anything eventful
<zyga> I EOD and then worked more and EOD after midnight
<zyga> how are you mvo? did you sleep at all?
 * zyga sips coffee and wakes up
<zyga> -3 outside, no people
<mvo> zyga: hey, I'm good, thank you
<pstolowski> morning
<zyga> hey pawel
<zyga> pstolowski: do you walk your dog in the morning?
<zyga> was it all snowy as well?
<pstolowski> zyga: no, it's cold but sunny
<zyga> it was white outside here
<zyga> so weird
<zyga> mborzecki: hmmm, command foo should run foo without using built-in things, right?
<mborzecki> zyga: built in?
<zyga> built into shell
<zyga> echo vs /usr/bin/echo or /bin/echo or whatever
<zyga> command %q foo works in bash
<zyga> er
<zyga> command printf %q foo works in bash
<zyga>  /usr/bin/printf %q foo works in anything
<zyga> but command printf %q foo doesn't work in dash
 * zyga re-reads the man page
<mborzecki> oh dash, idk ;)
<zyga> it's going for the builtin anyway
<mborzecki> zyga: there's probably some footnote in posix spec that say why it should do that
<zyga> ah sorry
<zyga> command is not what I think it is
<zyga> it just skips functions
<zyga> brb
<zyga> it passes :DDDD
<zyga> I need to watch over Lucy for two hours
<zyga> I'll be back later
<zyga> sorry
<mup> PR snapd#8385 opened: tests/main/user-session-env: stop the user session before deleting the test-zsh user <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8385>
<jamesh> mborzecki: ^^^ I wouldn't mind a review of the above, since it is for a test you wrote
<mborzecki> jamesh: sure
<zyga> jamesh: reviewed
<jamesh> zyga: thanks
<mborzecki> heh, so i added the changes to do an immediate system reboot when install is complete, and the whole process feels much faster now :P
<zyga> mborzecki: nothing like reboot to speed up computers ;)
 * zyga has IRC but needs to pay attention to lucy until wife is back
<mup> PR snapd#8386 opened: many: support immediate reboot <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8386>
<mborzecki> rebooting to recovery feels nice too now
<mborzecki> it will also shave some time off the uc20 test prepare phase
<mborzecki> ehhh Mar 31 07:05:20 mar310653-786350 50-motd-news[3511]: /etc/update-motd.d/50-motd-news: 131: /etc/update-motd.d/50-motd-news: cannot create /var/cache/motd-news: Read-only file system
<mborzecki> that's why google:ubuntu-core-16-64:tests/main/degraded is failing
<mborzecki> why do we even have motd-news.service there?
<mborzecki> mvo: ^^ do you recall why it's included?
<mborzecki> oh and `HTTP/1.0 503 Service Unavailable` when POSTing to https://api.snapcraft.io/v2/snaps/refresh
<jamesh> pedronis: I think I've covered everything in https://github.com/snapcore/snapd/pull/5822 (user-daemons PR).  The intermittent failure was due to an existing test not properly cleaning up.
<mup> PR #5822: wrappers: allow user mode systemd daemons <:birthday:> <Needs Samuele review> <â Blocked> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5822>
<mvo> mborzecki: in a meeting right now
<zyga> re
<pedronis> jamesh: thansk, I will review it again tomorrow
<pedronis> *thanks
<jamesh> pedronis: thanks
<zyga> mborzecki: same bug we had in core18
<mborzecki> hmmm, let me see the fix there
<mup> PR snapd#8387 opened: store: search v2 tweaks <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8387>
<zyga> eh, fun
<zyga> core systems don't have writable /var/lib/systemd
<zyga> so they cannot get /var/lib/systemd/linger
<mvo> mborzecki: re motd-news.service> no idea, sounds wrong
<zyga> mvo: same bug we had in core16, core18 and now core20
<mvo> zyga: uh, what is linger ?
<zyga> mvo: it's something we just inherit from ubuntu
<mborzecki> mvo: it's removed in core20 and core18, but not core
<mvo> mborzecki: aha, sounds like an oversight then
<zyga> mvo: linger is a directory used by systemd to indicate that a user may have session services running while not being logged in
<mvo> zyga: I see, we can add it to the writable dirs if it's needed
<zyga> mvo: I need it to make test non-racy
<zyga> mvo: I think I can cope with test specific workaround but let's keep that option open
<mborzecki> actually the fix in core18 is weird, https://github.com/snapcore/core18/blob/master/hooks/014-set-motd.chroot#L27-L31
<mborzecki> it removes the services and then update is disabled?
<mborzecki> fwiw, the timers.target.wants/motd-news.timer symlink is left behind in 18 and 20
<zyga> mborzecki: nice
<zyga> let's fix it :)
<zyga> I think the services should have conditions
<zyga> instead of hooks remving them
<zyga> it would "scale" better
<zyga> and since it's a ubuntu thing IIRC, we should have no problems adding that
<mborzecki> duh
<mborzecki> so update-motd is hooked up to pam? wtf?
<zyga> whar?
<zyga> how?
<mborzecki> zyga: see pam_motd
<zyga> and we are struggling with PATH
<zyga> we should just add pam_snapd
<zyga> ;D
<zyga> more lucy time
<mup> PR core#111 opened: live-build/hooks/motd: disable dynamic motd, disable motd services <Created by bboozzoo> <https://github.com/snapcore/core/pull/111>
<mup> PR core18#149 opened: hooks/motd: cleanup dangling symlink, fix typo <Created by bboozzoo> <https://github.com/snapcore/core18/pull/149>
<mup> PR core20#31 opened: hooks/motd: disable dynamic motd, cleanup dangling symlink <Created by bboozzoo> <https://github.com/snapcore/core20/pull/31>
 * zyga spawns a test for core workaround and goes back to luck
<mup> PR snapd#8388 opened: cmd/snap,seed: validate full seeds (UC 16/18) <Created by pedronis> <https://github.com/snapcore/snapd/pull/8388>
<pedronis> mvo: ^
<mvo> pedronis: thanks
<zyga> ok, core systems now pass
<zyga> only centos-7 and amazonlinux with ancient printf
<zyga> let's reimplement %q
<popey> My laptop locked up last night, had to hard-reboot. Now no snaps will run
<popey> cannot change profile for the next exec call: No such file or directory
<popey> snap-update-ns failed with code 1: No such file or directory
<popey> Anyone seen that before?
<zyga> popey: I would help but check my Twitter
<popey> i would check your twitter but I can't open my browser
<zyga> Maybe nothing mounted
<zyga> Maybe partial dpkg update?
<zyga> can you get root
<popey> i can
<popey> no dpkg in flight, i see squashfs files mounted
<zyga> Can you dpkg âconfigure -a
<zyga> Can you snap list?
<popey> noting
<popey> *nothing
<popey> https://paste.ubuntu.com/p/MPDMzTvDNy/
<zyga> Snaps not broken ok
<zyga> Can you snap changes?
<zyga> Anything in flight?
<popey> https://paste.ubuntu.com/p/JNkKSHBGqn/
<popey> nope
<zyga> Can you snap run something?
<popey> cannot change profile for the next exec call: No such file or directory
<popey> snap-update-ns failed with code 1: File exists
<zyga> Can you systemctl status apparmor.service
<pedronis> pstolowski: some comments to #8387
<mup> PR #8387: store: search v2 tweaks <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8387>
<popey> https://paste.ubuntu.com/p/mTqRsQJMKY/
<pstolowski> pedronis: ty
<zyga> Can you as-status please?
<zyga> (Tying form memory, hope that is the one)
<popey> i dont think that's it
<mborzecki> hmm snapcraft segfault?
<zyga> mborzecki: help, afk, help popey list loaded aa profiles please
<mborzecki> popey: sudo aa-status
<popey> https://paste.ubuntu.com/p/7WD8FCFdRJ/
<zyga> popey: does the revision of core in that output match what the current points to on your system?
<zyga> And is the list of snaps the same as those you see in that output?
<popey> yes
<popey> that's not a long list of snaps
<zyga> Ok
<popey> snap list shows me 88 snaps
<zyga> Can you SNAP_CONFINE_DEBUG=yes snap run something please
<mup> PR snapd#8332 closed: gadget: SystemDefaults helper for FilesystemOnlyApply (2/N) <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8332>
<popey> https://paste.ubuntu.com/p/yJjr8NRzZM/
<zyga> Inspecting...
<zyga> So, snap-update-ns.null is absent
<zyga> Can you look at /var/lib/snapd/apparmor/profiles
<zyga> Is it there?
<popey> yes, lots in there
<zyga> And that list is larger than aa-status, right?
<popey> yes
<zyga> Can you look at journal log of apparmor.service
<zyga> I wonder if apparmor loaded stuff
<zyga> At the same time snapd rewrote profiles
<zyga> To fix tour machine please restart apparmor.service
 * popey tries that
<zyga> Sorry for the silly typos from phone correction
<popey> aa-status is much longer now
<zyga> Check if that makes null work
<popey> i can run snaps
<zyga> Look through timeline
<popey> give your baby a hug from me
<zyga> Of startup uf
<zyga> Apparmor servir
<zyga> Apparmor service
<zyga> And snapd service
<zyga> Maybe we are racing?
<zyga> If they overlap that is a bug
<zyga> And thank you for reporting
<popey> :D
<popey> a bug in snapd or apparmor?
<zyga> She is hugging me constantly now (sleeping)
<zyga> In our units
<zyga> We may need after=
<zyga> So please check the time stamps carefully
<zyga> Also
<pedronis> mborzecki: I started reviewing your immediate reboot PR but need to go have lunch first
<zyga> Time stamps on those files in /v/l/a/profiles
<mborzecki> pedronis: ok, enjoy your lunch :)
 * pstolowski lunch & errand
<mborzecki> ehh the core build process :/
<zyga> it passes on centos
<zyga> running final check on amazon
<zyga> liberated :)
<zyga> we should fix 20 images
<zyga> GDM is running
<zyga> I bet that's not free
<zyga> mvo: ^
<zyga> ubuntu-20.04-64 has GDM running
<mvo> zyga: uh, nice find
<mvo> zyga: let's talk to sergio about this
<zyga> we know about this
<zyga> just reminding because it affects a test
<zyga> it's pulled in by evolution-data-server
<zyga> mvo: I'll talk to him today
<pedronis> mborzecki: I did a pass
<mborzecki> pedronis: thanks, let me check the comments
<pedronis> mborzecki: it looks good, mostly comments on details
<ijohnson> hey folks
<pstolowski> hey ijohnson
<zyga> hey ian :)
<ijohnson> hey zyga pstolowski
<ijohnson> how's it going ?
<zyga> good
<zyga> making progress today
<ijohnson> nice, my internet kept cutting out for a couple minutes at a time yesterday, so I'm hoping today it's more stable
<mborzecki> pstolowski: please take another look at #8376
<mup> PR #8376: daemon: make POST /v2/systems/<label> root only <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8376>
<pstolowski> sure
<mborzecki> thanks!
<mup> PR snapd#8389 opened: tests: make session tool way more robust <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8389>
<pstolowski> +1
<jdstrand> e/win 5
<pedronis> pstolowski: I reviewed your PRs
<pstolowski> pedronis: thank you
<pstolowski> mborzecki: perhaps you could make 2nd review of #8343?
<mup> PR #8343: config, features: move and rename config.GetFeatureFlag helper to features.Flag <Created by stolowski> <https://github.com/snapcore/snapd/pull/8343>
<mborzecki> pstolowski: sure, will do
<pstolowski> ty
<zyga> mvo: I'll add my notes in a moment,
<zyga> I try to add them every day when I EOD
<mvo> zyga: no worries
<mvo> zyga: just makes it easier to catchup on details
<zyga> ack
<zyga> I can do them before the standup and at EOD next time
<zyga> my favourite APIs are FooEx
<zyga> they usually work better than Foo
<zyga> I wonder if this is how FedEx got the name :P
<diddledan> is it possible to export the launchpad authentication key for use in CI so I can trigger `snapcraft remote-build` from GitHub Actions?
<diddledan> my use case is I want more control over which channel I release builds into instead of always going into edge, so I thought to use remote-build in a GitHub Action to get all the architectures built and then in GitHub Actions release them appropriately to alternative channels than edge.
<diddledan> Github Actions itself is not good for building because it doesn't support ALL the architectures
<ackk> hi, is there a way for a snap to inspect which slot/plugs it has?
<ackk> I guess it can read meta/snap.yaml, is there a better way?
<cjp256> diddledan: i suppose you could if you constructed the correct credential file for launchpad `$HOME/.local/share/snapcraft/provider/launchpad/credentials` first
<diddledan> hmm
<zyga> I opened https://github.com/snapcore/snapd/pull/8389
<mup> PR #8389: tests: make session tool way more robust <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8389>
<zyga> with some luck tests will not fail on anything random in other tests
<diddledan> don't trust tests that don't fail!
<diddledan> mind you, you shouldn't trust failing tests, either ;-p
<diddledan> I _always_ end up having to fix my tests rather than fixing my code because I wrote the test wrong
<ijohnson> ackk: do you mean connected slots / plugs ?
<ijohnson> ackk: if so then yes use `snapctl is-connected <name>`
<ackk> ijohnson, no, I mean get the list of names
<ackk> ijohnson, it seems like looking in snap.yaml would do it, but I was wondering if there was a snapctl way
<ijohnson> yes, parsing snap.yaml is the best way to just get all the plugs and slots you have
<ackk> ijohnson, thanks
<ijohnson> you would have to be slightly careful because you can have for example global plugs in the snap.yaml that apply to every app, and you can have global plugs that are only used in certain places
<pedronis> mborzecki: did you see this comment https://github.com/snapcore/snapd/pull/8386#discussion_r400830653 ?
<mup> PR #8386: many: support immediate reboot <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8386>
<mup> PR snapd#8297 closed: tests: session-tool improvements <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8297>
<ackk> ijohnson, ah yeah, I was talking specifically about the global ones (like content interfaces)
<ackk> ijohnson, thanks
<ijohnson> yes global plugs are bit tricky to work with in figuring out which app/hook they end up applying to
<ackk> ijohnson, does "is-connected" work for app-specific plugs as well?
<mborzecki> pedronis: heh, missed it when fixing code
<ijohnson> ackk: yes `snapctl is-connected` does the right thing depending on which app/snap it was called from and which plugs that app/snap has
<mborzecki> pedronis: thanks for spotting this
<ijohnson> ackk: (unless there are bugs of course)
<ackk> ijohnson, cool, thanks
<pedronis> mborzecki: apart from that +1 with a suggestion for one of the local vars
<cjwatson> diddledan: snapcraft remote-build tokens currently expire after a week
<cjwatson> We might make this more flexible in future, but that's the way it is for now.  It was just enough to get going, without having to implement proper token persistence in order that users can revoke them
 * zyga takes a break to eat lunch
<mborzeck1> omg #8371 has 2 +1, is finally green but the status wasn't reported back to github
<mup> PR #8371: overlord/devicestate, daemon: record the seed current system was installed from <Needs Samuele review> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8371>
<mvo> mborzecki: I can take care of it
<mborzecki> mvo: i've restarted the cla check, maybe this will update the status
<mborzecki> mvo: ah you merged it, thanks!
<mup> PR snapd#8371 closed: overlord/devicestate, daemon: record the seed current system was installed from <Needs Samuele review> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8371>
<mvo> mborzecki: yeah, no need to run spread again and wait forever for silly issues like this, I can just override the failure
<mborzecki> mvo: travis getting out of sync with gh is so frustrating lately
<mborzecki> (hope it's not foul play on gh side to promote gh actions though)
<pedronis> mborzecki: it #8369 ready for re-review by me?
<mup> PR #8369: boot, overlord/devicestate, daemon:  implement requesting boot into a given recovery system <Needs Samuele review> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8369>
<mborzecki> pedronis: yes it should be
<mvo> mborzecki: yeah, we need to switch to gh actions all the way
<zyga> some store woes
<ijohnson> mborzecki: so I got serial console logs from cachio on a failed uc20 reboot from #8373
<mup> PR #8373: tests/lib/prepare.sh: use only initrd from the kernel snap <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8373>
<ijohnson> see
<zyga> and I didn't go to eat anything
 * zyga is gone
<ijohnson> https://www.irccloud.com/pastebin/a8UFlkQO/
<ijohnson> mborzecki: does this sound familiar?
<mborzecki> ijohnson: heh, yeah
<mborzecki> ijohnson: that's what i was talking about ;)
<ijohnson> so weird
<mborzecki> ijohnson: i had dumpes of find between the new skeleton and the extracted one, but was not able to conclude anything meaningful out of that
<ijohnson> so it looks like /main/init in the unpacked initrd skeleton is a symlink to usr/lib/systemd/systemd
<mborzecki> ijohnson: afaik it shuld be
<ijohnson> and that's the same in both the distro skeleton and the unpacked skeleton :-(
<mborzecki> ijohnson: notice that when extrating the initrd tar (?) complains about some symlinks
<mborzecki> perhaps they should all contain /
<ijohnson> mborzecki: hmm I don't see that complaint, when do you see that ?
<ackk> does snapcraft 3.11 support core20-based snaps?
<mborzecki> ijohnson: i saw it when extracting the initrd, tar was stripping / from symlinks
<ijohnson> mborzecki: you mean like from inside unmkinitramfs ?
<ijohnson> I don't see where we are using tar directly anywhere
<mborzecki> ijohnson: heh no longer there :/
<mup> PR snapd#8390 opened: state: add state.CopyState() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/8390>
<ijohnson> mborzecki: ah interesting there's:
<ijohnson> https://www.irccloud.com/pastebin/cmFL9aRT/
<ijohnson> but I don't see that when I run the same code on my focal desktop :-/
<mborzecki> ijohnson: yup, that's what i saw
<ijohnson> hmm
<mborzecki> and yeah, it's cpio not tar
<ijohnson> ah so there's a new version of initramfs-tools-core available that's not installed in the google images
<mborzecki> time to wrap it up for today
<mup> PR snapd#8391 opened: tests: fix cross buidl tests when installing dependencies <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8391>
<xnox> help snap command fails for me
<xnox> $ snap info --verbose --arch arm64 pi
<xnox> error: unknown flag `arch'
<xnox> how do i get the id of pi snap?
<pedronis> YbGa9O3dAXl88YLI6Y1bGG74pwBxZyKg
<ijohnson> ha! https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946267 is the source of this confusion I bet
 * ijohnson lunches
<xnox> pedronis:  right, i have now used obsolete snap-tool that was removed from livecd-rootfs which talks to the store to find that out.
<xnox> pedronis:  i wish either snapcraft or snap commands would support --arch --channel when calling like info or status, to get these things from the store.
<xnox> setting UBUNTU_STORE_ARCH=arm64 did not help, like it does with `download` command.
<pedronis> that's been request and is in the backlog but we haven't got to it yet
<xnox> ok!
<pstolowski> mvo: hey, what's the target date for 2.44.1?
<pedronis> pstolowski: you mean .2 ?
<pstolowski> pedronis: right, yes
<pedronis> because .1 is going stable now
<pstolowski> pedronis: yes i mean the next one, with search v2
<mvo> pstolowski: about a week from now, why?
<pstolowski> mvo: Tony was asking
<pstolowski> thanks
<mup> PR snapd#8392 opened: tests: remove google-tpm backend from spread.yaml <Simple ð> <Skip spread> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8392>
<mvo> pstolowski: aha, for searchv2?
<pstolowski> yes
<jdstrand> roadmr: hi! can you pull 20200330-2212UTC? note, this has changes that use statefulness for base snaps
<jdstrand> kenvandine: fyi, that is part of the work needed for the freedesktop base snap ^
<zyga> re
<kenvandine> jdstrand: great
<roadmr> jdstrand: interesting - yes, I'll queue it up :)
<jdstrand> roadmr: thanks!
<ijohnson> cachio: how can I get a debian package updated in the ubuntu-2004-64-virt-uefi-enabled image ?
<ijohnson> cachio: I need the cpio and initramfs-tools-core debian packages updated in the images
<cachio> ijohnson, Iwell ubuntu-2004-64-virt-enabled is updated
<ijohnson> cachio: but the cpio package on that image is out of date
<cachio> I am cleaning the uefi ones because those are by deault now
<ijohnson> I have just confirmed this now, it has 2.13+dfsg-1 but it needs 2.13+dfsg-2
<cachio> just update the spread.yaml with ubuntu-2004-64-virt-enabled
<cachio> I think this should work
<cachio> in that case give me 10 minuttes, I'll update that image
<ijohnson> cachio: see https://github.com/snapcore/snapd/pull/8373#issuecomment-606758867
<mup> PR #8373: tests/lib/prepare.sh: use only initrd from the kernel snap <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8373>
<ijohnson> cachio: so should I file a PR to change ubuntu-2004-64-virt-uefi-enabled to ubuntu-2004-64-virt-enabled ?
<cachio> just do it in the one which is failing
<cachio> to make it quickly
<ijohnson> cachio: ack will push that up to 8373
<cachio> ijohnson, so
<cachio> google:ubuntu-20.04-64-virt-enabled .../tasks/google/start-instance# apt-cache policy cpio
<cachio> cpio:
<cachio>   Installed: 2.13+dfsg-2
<cachio>   Candidate: 2.13+dfsg-2
<cachio> so ubuntu-20.04-64-virt-enabled is ok
<ijohnson> cachio: great
<ijohnson> cachio: I pushed up that change to the PR, let's see how it does in travis/spread
<cachio> ijohnson, nice
 * cachio lunch
<mup> PR snapd#8385 closed: tests/main/user-session-env: stop the user session before deleting the test-zsh user <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8385>
<zyga> snapd fails to restore  https://www.irccloud.com/pastebin/dPL09dsG/
<zyga> leftover LXD mount points https://www.irccloud.com/pastebin/s2YhSMhf/
<zyga> cachio: ^ FYI
<zyga> we should unmount those when we remove lxd
<zyga> as otherwise we crash in postrm
<zyga> mvo: ^ LXD mount points are breaking snapd dpkg postrm
<cachio> zyga, ok, is this caused because of the last change in the lxd snap?
<zyga> I suspect it's a race
<zyga> unless they just pushed something
<zyga> I just saw this for the first time
<zyga> and I've been running tests all day
<zyga> but our cleanup step needs to special case lxd
<zyga> and unmount anything it mounted
<zyga> which can change at any time
<cachio> mmmm
<cachio> ok, in case they change something we are gonna need to make another change
<cachio> I'll leave some checks to validate we cleaned all the moounts
<zyga> I'll grab a beer
<zyga> cachio: we need to fix our postrm sadly
<zyga> cachio: not only our test stack
 * zyga is a bit depressed after fighting bugs and compatibility across several releases of various distributions
<mvo> zyga: in the tests?
<zyga> yes
<zyga> I'm running tests with -repeat
<zyga> stressing the fixes I made
<zyga> and I find lots of funky bugs
<mvo> zyga: is it a real bug that happens when someone removes the lxd snap too?
<mvo> zyga: or just test internal?
<zyga> I suspect it depends on how you remove it
<cachio> zyga, mvo I never saw that in the travis logs
<zyga> but I suspect apt --purge snapd at the right time can cause that
<zyga> since we rely on rm -rf stuff
<zyga> and lxd does create mount points beyond our control
<pedronis> afaict it doesn't have a remove hook
<zyga> perhaps it should
<zyga> to clean up
<pedronis> anyway in theory we should run remove hooks when we are trying to remove snaps
<pedronis> wouldn't help here because there isn't one
<zyga> I agree
 * zyga EODs depressingly
<jdstrand> zyga: sorry you EOD'd depressingly. fyi, I will be doing PR reviews tomorrow, including yours
<zyga> jdstrand: no worries, it's just ... tough sometimes
<zyga> jdstrand: my thoughts on this are https://twitter.com/zygoon/status/1245062988358389767
<mup> PR snapd#8388 closed: cmd/snap,seed: validate full seeds (UC 16/18) <Squash-merge> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8388>
<mup> PR core20#31 closed: hooks/motd: disable dynamic motd, cleanup dangling symlink <Created by bboozzoo> <Merged by xnox> <https://github.com/snapcore/core20/pull/31>
<jdstrand> zyga: :\
<ijohnson> jdstrand: hey did you see my ping from a few months ago on https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1656340 ?
<mup> Bug #1656340: XDG_RUNTIME_DIR is not created on app startup <bionic> <cosmic> <eco-team> <xenial> <Snappy:Triaged by zyga> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1656340>
<mup> PR snapcraft#3005 closed: Change dotnet runtime version from snapcraft.yaml <Created by amka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3005>
<jdstrand> ijohnson: I did. opinions abound and there is no resolution atm. there was a discussion which I captured in trello where I am to sketch out my thought on how to implement things and why. it isn't roadmapped so it is under other things
<ijohnson> jdstrand: ack that's fair thanks for the heads-up
<zyga> https://github.com/snapcore/snapd/pull/8389 should go green
<zyga> hopefully
<mup> PR #8389: tests: make session tool way more robust <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8389>
<zyga> it's such a terrible thing, it's still imperfect
<zyga> but the error rate is lower
<zyga> and I don't know why it fails (not yet) perhaps just bugs in old systemd/logind
<zyga> I only saw failures on amazon linux 2 and debian 9
#snappy 2020-04-01
<mup> PR snapd#8373 closed: tests/lib/prepare.sh: use only initrd from the kernel snap <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8373>
<mborzecki> morning
<mborzecki> and back
<mup> PR snapd#8376 closed: daemon: make POST /v2/systems/<label> root only <Simple ð> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8376>
<mborzecki> yay
<jamesh> The travis jobs are precariously close to the 50 minute timeout
<mborzecki> jamesh: trying to squeeze every minute of that test runs ;)
<mborzecki> mvo: hey
<jamesh> mborzecki: I've had a few test runs that seem to have just been unlucky and were killed
<mborzecki> jamesh: yeah, the margin is just below 5 minutes now, if anything gets delayed (such as lxd test) we may easily hit the limit
<mvo> hey mborzecki
<mvo> mborzecki: this all sounds we really want to move to GH
<mvo> mborzecki: are tests failing a lot this morning?
<mborzecki> mvo: 2 of my prs had their travis jobs restarted (or they did not run since yday)
<jamesh> mvo: not particularly more than usual.  I was just commenting on one of my runs getting failed by Travis's 50 minute timeout
<jamesh> and that the usual successful runs aren't enormously shorter than that limit
<mvo> right :/
<jamesh> maybe we should stop adding new tests
<jamesh> :-)
<mvo> heh :) remove one exiting for each new test
<mvo> hm, looking at 8392, what does "shealding" mean? "This is because the cloud team is shealding by default all the ubuntu
<mvo> images on gce "?
 * mvo maybe just did not had enough tea
<mup> PR snapd#8391 closed: tests: fix cross build tests when installing dependencies <Simple ð> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8391>
<mup> PR snapd#8387 closed: store: search v2 tweaks <Simple ð> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8387>
<zyga> o/
<zyga> mvo: github-has-no-50-minute-limit (just saying)
<zyga> we could move all travis spread jobs over
<zyga> and leave some boring checks for next
<mvo> zyga: yeah
<jamesh> I don't know.  A "remove two tests for each new test added" policy sounds appealing
<jamesh> get rid of that regulation
<mvo> jamesh: if I want to report a bug on GH actions to support "fail-ignore" or something, what's the most appropriate place/component in their issues, do you have a suggestion?
<zyga> Their community thing
<zyga> But that is reported already
<jamesh> mvo: I've seen some general bugs filed against https://github.com/actions/toolkit/.  The forum is also worth looking at
<jamesh> mvo: given that each job shows up as a separate check suite, is it needed?
<mvo> jamesh: I would like to see the overall tickmark green or red
<mvo> jamesh: it's kind of annoying to have to go to the details, it's minor, agreed :)
<mvo> jamesh: we have a bunch of "unstable" systems that have frequent e.g. package manager mirror issues and it would be nice to not count those in the overall "is-green" assesment on the GH pull overview page
<mup> PR snapd#8386 closed: many: support immediate reboot <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8386>
<pstolowski> morning
<mvo> pstolowski: good morning - do you think you could have  a quick look at 8383 ? needs a review
<pstolowski> mvo: yes, of course
<mvo> jamesh: looks like 8289 is ready, it's just spread that's not quite there?
<mvo> jamesh: but it has two plus one etc? can I squash merge it?
<jamesh> mvo: yes.  This was the one that hit the 50 minute kill timeout on the travis jobs
<jamesh> mvo: I think it is good to go
<mvo> jamesh: thanks, merged
<mup> PR snapd#8289 closed: xdgopenproxy: forward requests to the desktop portal <Squash-merge> <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8289>
<mborzecki> yay!
<jamesh> yay!
<mborzecki> mvo: 44.2? :)
<mvo> mborzecki: there will be a .2 for the search-v2 :)
<mborzecki> mvo: cool, can we include the portal proxy as well?
<mvo> mborzecki: I just cherry picked it, I think we want it
<mvo> unless pedronis feels it's too much of a change to include the portal-proxy in 2.44.2
<pedronis> mvo: jamesh: what are the risks? it will not be tested much if it goes into .2
<jamesh> pedronis: that snaps calling /usr/bin/xdg-open will fail.  The PR's spread tests provide decent confidence for the systems it runs on.  It probably works on the older systems where the test fixture doesn't run.
<jamesh> pedronis: it should make no difference on systems that don't have xdg-desktop-portal installed at all
<pedronis> mvo: when are you cutting .2 ?
<jamesh> (the spread test runs against the system's real xdg-desktop-portal daemon)
<mborzecki> #8305 needs a 2nd review
<mup> PR #8305: cmd/snap-recovery-chooser: add recovery chooser <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8305>
<mvo> pedronis: soon, today ideally
<mvo> pedronis: I would like to go over the 2.44 marked PRs today, i.e. I'm trying to get the seed warning done
<mvo> pedronis: eh, seed-failed warning
<pedronis> mvo: there's a small risk of needing a .3 which would be annoying
<mvo> pedronis: yeah, I don't have super strong opinions, we could be conservative and punt the portal stuff to 2.45
 * zyga switches to reviews 
 * zyga reads 8305
<mvo> pedronis, degville I updated the warning text in 8372, I think we should move forward with the warning as a start
<degville> mvo: thanks, I'll take a look.
<zyga> times are interesting
<zyga> my kids are doing more video calls than I do
<zyga> mborzecki: what is the marker file for again, to trigger the whole workflow of selection?
<mborzecki> zyga: to indicate that we detected the trigger during boot
<zyga> and then run the chooser?
<mborzecki> yes
<mborzecki> the console conf integration bits only start the chooser iff the marker file is present already, but the extra sanity checks in the chooser do not harm
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8305#pullrequestreview-385359049
<mup> PR #8305: cmd/snap-recovery-chooser: add recovery chooser <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8305>
<zyga> mborzecki: I'll pick up another review but please ping me for more iteration on this, even if you just reply to my comments
<abeato> hey, I am trying to run the UC20 image from cdimage with kvm+tianocore, but kvm crashes on me when selecting install/recovery option, are there any instructions on how to test UC20?
<mvo> abeato: hm, kvm+uefi (OVMF) should work, did you enable virtio? without virtio on the disk grub is incredible slow in uefi mode
<abeato> mvo, I'm using this command line (no virtio, I'll try that): kvm -m 1024 -redir :8022::22 -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd -drive if=pflash,format=raw,file=OVMF_VARS.fd ubuntu-core-20-amd64.img
<zyga> actually
<zyga> do we have a single place that explains how to run core20
<zyga> I'd love to try it
<zyga> but it seems that at least for now it's a bit of black magic and goat sacrifice
<jamesh> zyga or mvo: could I trouble you to merge https://code.launchpad.net/~jamesh/snappy-hub/test-snapd-dbus-service/+merge/364742 ?  -- this is for a snap used by my dbus-activation branch.
<zyga> snappy-hub :)
<jamesh> (unfortunately it is probably a little more effort than just hitting a button though)
<zyga> sure
<jamesh> thanks
<zyga> do we need to rebuild the snap and publish it
<zyga> or just merge the branch
<zyga> oh, it's bzr
<jamesh> the snap needs rebuilding, but that might happen automatically
 * zyga checks if bzr is in focal
<jamesh> it is
<jamesh> well, brz is
<abeato> zyga, re: UC20, +1 on that :)
<mvo> jamesh: in a meeting right now, if zyga can help that would be great
<zyga> jamesh: it's merged
<zyga> mvo: done
<zyga> jamesh: let me know if the snap needs poking to build
<zyga> but https://code.launchpad.net/~mvo/+snap/test-snapd-dbus-service claims it's building automatically
<jamesh> I'll keep an eye on it to make sure it starts.  Thank you
<mborzecki> hmm has the pi kernel grown?
<zyga> cheers: )
<zyga> mborzecki: how big is it?
<mborzecki> 22M
<zyga> for pi 4?
<zyga> or pi 2-3?
<mborzecki> idk, pi-kernel
<mborzecki> whicheven tht supports
<mup> PR snapd#8369 closed: boot, overlord/devicestate, daemon:  implement requesting boot into a given recovery system <Needs Samuele review> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8369>
<zyga> mvo: https://github.com/snapcore/snapd/pull/8390#pullrequestreview-385400365
<mup> PR #8390: state: add state.CopyState() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/8390>
<zyga> mvo: https://github.com/snapcore/snapd/pull/8382#issuecomment-607148635
<mup> PR #8382: packaging: detect broken seed during focal and disable it <Created by mvo5> <https://github.com/snapcore/snapd/pull/8382>
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8378/files#diff-459c7505a1a8a6c804c8a0cf9032350eR82 is unused, is usage of opts coming later?
<mup> PR #8378: o/configcore: introduce core config handlers (3/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8378>
<pstolowski> zyga: it's needed because all methods must implement common interface now. but perhaps it can be unnamed there
<zyga> ah, I see
<pstolowski> not every method will use opts internally
<zyga> I'm mid-way through so perhaps it gets clear as I go down
<zyga> thanks
<zyga> I see
<zyga> just asking :)
<pstolowski> zyga: sure!
<mup> PR snapd#8393 opened: cmd/snap,seed: validate full seeds (UC 16/18) for 2.44 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8393>
<mvo> zyga: thanks, looking
<zyga> mvo: ping me for a follow-up of any kind please
<mvo> zyga: thanks
<mup> PR snapd#8383 closed: store: support for search API v2 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8383>
<mup> PR snapd#8394 opened: snap: add `snap debug state --is-seeded` helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/8394>
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8378#pullrequestreview-385430838
<mup> PR #8378: o/configcore: introduce core config handlers (3/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8378>
<zyga> mvo: https://github.com/snapcore/snapd/pull/8394#pullrequestreview-385450682
<mup> PR #8394: snap: add `snap debug state --is-seeded` helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/8394>
 * zyga breaks to take the dog out
<jamesh> mvo: when you're not busy, could you flip this snap build recipe over to building against Bionic? https://code.launchpad.net/~mvo/+snap/test-snapd-dbus-service
<pstolowski> zyga: thanks, replied. i'll check if opts can be left unnamed
<mvo> jamesh: do you have the link at hand? happy to do that
<mup> PR snapd#8343 closed: config, features: move and rename config.GetFeatureFlag helper to features.Flag <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8343>
<mvo> pedronis: when you have a moment, could you please have a look at 8372 ? hopefully very simple
<mvo> jamesh: nevermind, updated and triggered a rebuild
<mup> PR snapd#8395 opened: o/ifacestate: handle interface hooks when preseeding <Created by stolowski> <https://github.com/snapcore/snapd/pull/8395>
<pedronis> mvo: there some preexisting comments by zyga there that are not answered, also I think we can remove the XXX
<zyga> re
<zyga> back, sorry for the lag, $events at home
<pedronis> pstolowski: made some suggestions in 8378
<pstolowski> ty
<zyga> mborzecki: FYI https://wiki.archlinux.org/index.php/Talk:Snap
<pstolowski> pedronis: yep, sounds good
<mborzecki> zyga: yeah, it's a known thing, we have a forum topic about that too
<mborzecki> zyga: imo the 'workaround' doesn't make sens anymore, but we don't know what's wrong yet
<zyga> yeah, just wanted to let you know about the talk page
<mborzecki> zyga: mhm, i get email notifications about edits there :)
<zyga> ah, ok
 * zyga too :)
<mborzecki> but than's for poking me :)
<mborzecki> thanks ;)
<zyga> FYI https://bugs.launchpad.net/snapd/+bug/1870123
<mup> Bug #1870123: Panic: unlocking unlocked mutex in unit test <snapd:New> <https://launchpad.net/bugs/1870123>
<pstolowski> zyga: pushed the changes to #8378, per Samuele's suggestions
<mup> PR #8378: o/configcore: introduce core config handlers (3/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8378>
<zyga> looking
<cachio> mvo, debian sid is failing to update https://travis-ci.org/github/snapcore/spread-cron/builds/668599845
<cachio> I tried many things to correct that but the repo is not consistent
<pedronis> pstolowski: the validateOnly where not core only, no?
<cachio> mvo, any idea about a workaround?
<zyga>  clang : Depends: clang-9 (>= 9~) but it is not going to be installed
<pedronis> pstolowski: otherwise looks good
<zyga> hmm
<zyga> the debian image has weird repos:
<zyga> W: GPG error: http://dl.google.com/linux/chrome/deb stable Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 78BD65473CB3BD13
<zyga> why do we have a chrome PPA in a test image?
<pedronis> pstolowski: btw we the tests were passing, maybe we need to mock release.OnClassic a bit more carefully
<pedronis> that's old, not really related to the new code
<pstolowski> pedronis: yes, you're right, thanks for catching!
<mup> PR snapcraft#3006 opened: repo: always use host release and arch for Ubuntu <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3006>
<cachio> zyga, hi
<cachio> I saw that today
<cachio> + rm -rf /tmp/snap.rootfs_SwGmI3 /tmp/snap.test-snapd-sh /tmp/snap.test-snapd-simple-service
<cachio> rm: cannot remove '/tmp/snap.rootfs_SwGmI3': Device or resource busy
<cachio> is it similar to what you sent yesterday
<cachio> the issue in postrm
<cachio> ?
<mup> PR snapd#8372 closed: devicestate: generate warning if seeding fails <Needs Samuele review> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8372>
<zyga> cachio: no, that's not the same issue
<mup> PR snapcraft#3007 opened: go: support projects with multiple binaries when using go.mod <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3007>
<zyga> pedronis: I will review the user session daemons PRs
<zyga> so the pi 4 heatsink without fans for folks in .pl: https://botland.com.pl/pl/obudowy-do-raspberry-pi/15107-obudowa-do-raspberry-pi-4b-aluminiowa-czarna-lt-4b03.html
<zyga> and the version with fans https://botland.com.pl/pl/obudowy-do-raspberry-pi/15106-obudowa-do-raspberry-pi-4b-aluminiowa-z-dwoma-wentylatorami-czarna-lt-4b02.html
<zyga> I bought both and I think the fans are useful, the heatsink got pretty hot otherwise
<zyga> the same product can be obtained in other countries
<zyga> it's brand new so should be coming in stock
<ijohnson> abeato: just for the record are you also specifying the -bios option to ovmf ?
<abeato> ijohnson, I tried that later and it crashed too - maybe the daily had some problem
<ijohnson> mmm like you don't even get to the kernel ?
<abeato> ijohnson, no - but later I created a UC20 image myself with some help from lool and I could get it to run
 * zyga will grab some food and get back to reviews
<ijohnson> abeato: ok were you using the image from cdimage originally?
<abeato> I found other problems though - the network interface was not found by console-conf
<abeato> yes
<ijohnson> abeato: ok yeah I think there's something wrong with the images on cdimage, needs some investigation
<abeato> ok
<ijohnson> abeato: fwiw I just booted a fresh image I built with all edge or 20/edge snaps and it had a network connection fine, my qemu parameters are this:
<ijohnson> https://www.irccloud.com/pastebin/C5EmaXnz/
<abeato> ijohnson, thanks, will give that a try
<ijohnson> and I built from this model: https://github.com/snapcore/models/blob/master/ubuntu-core-20-amd64-edge.model with these snaps:
<ijohnson> https://www.irccloud.com/pastebin/nkoV2isM/
<abeato> cool!
<cachio> zyga, something insteresting
<cachio> in bionic and focal we install evolution-data-server pkg
<cachio> zyga, but https://paste.ubuntu.com/p/YSxvmGnSRK/
<zyga> mmm
<zyga> maybe do rdepends gdm3
<zyga> and see what's there
<zyga> something is pulling it in for sure
<cachio> yes
<cachio> 1 minutes, I am starting the instance
<lool> abeato: how did you resolve the network connection issue?
<zyga> cachio: rdepends you can check locally
<abeato> lool, I've not solved it yet :) - I was about to try ijohnson stuff
<lool>     -device virtio-net-pci,netdev=mynet0 \
<lool> let's see  :-)
<cachio> zyga, https://paste.ubuntu.com/p/BxZvWzWV99/
<zyga> cachio: try this command
<zyga> apt-cache rdepends gdm3 https://www.irccloud.com/pastebin/fVU2NVJt/
<zyga> cachio: we must have got one of those installed
<zyga> _or_ it's a recommends that is followed
<cachio> I'll try that
<mup> PR snapcraft#3004 closed: storeapi: add channel-map endpoint <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3004>
<ijohnson> abeato: any luck?
<cachio> zyga, none of them is installed https://paste.ubuntu.com/p/vHqV7gK2Tk/
<mborzecki> zyga: ijohnson: pstolowski: which of you would like to take a look at https://github.com/CanonicalLtd/subiquity/pull/655 ?
<mup> PR CanonicalLtd/subiquity#655: console_conf: implement UC20 recovery chooser <Created by bboozzoo> <https://github.com/CanonicalLtd/subiquity/pull/655>
<mborzecki> it might not match exactly our python formatting/naming rules, but tried to make it as close to what is already in subuiquity as i could
<ijohnson> mborzecki: I can take a look at it, but I'm far from a python expert so I'll really just be reviewing for logic and not style or pythonicness
<ijohnson> also wow that PR keeps growing :-)
<mborzecki> thanks!
<ijohnson> last I looked it was like 500 lines
<mborzecki> ijohnson: tests made it grow a lot
<mup> PR snapcraft#2995 closed: Add gcc to the build-packages for the gnome-3-34 extension <Created by hellsworth> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2995>
<cachio> zyga, I think âno-install-recommends should be used as you suggested
<cachio> y
<cachio> zyga, https://paste.ubuntu.com/p/bPVYwr9cgt/
<cachio> zyga, I'll create a new PR in snapd to address that, thanks
<pstolowski> mborzecki: i can take a look too, with same remark as Ian
<mborzecki> pstolowski: thanks!
<mvo> thanks zyga for help with this --no-intsall-recommends
<zyga> I can look soon
<mvo> zyga: I updated 8394
<zyga> cachio: yeah, that's great
 * zyga checks backlog
<mup> PR snapd#8396 opened: tests: install dependencies with apt using --no-intsall-recommends <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8396>
<zyga> mborzecki: as a meta-comment, it would be great to have some type annotations there
<abeato> ijohnson, I just see a "Create bond" option, is that expected?
<pstolowski> zyga: can you take another look at #8378?
<mup> PR #8378: o/configcore: introduce core config handlers (3/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8378>
<zyga> pstolowski: sure
<ijohnson> abeato: no :-/
<ijohnson> abeato: what version of qemu are you using ?
<zyga> we should snap qemu
<ijohnson> abeato: I have QEMU emulator version 4.2.0 (Debian 1:4.2-3ubuntu4)
<ijohnson> zyga: someone did I think? but it was not qemu directly it was one of the higher level things
<abeato> ijohnson, I wonder if it is OVMF_CODE.ms.fd, I do not have that
<abeato> ijohnson,  2.11.1(Debian 1:2.11+dfsg-1ubuntu7.23 - bionic, I guess I need to upgrade
<ijohnson> oh wow yeah I think you need a new qemu version, can you try with a focal machine qemu ?
<ijohnson> cmatsuoka: do you remember what the oldest version of qemu we have successfully booted uc20 with is? I seem to remember you had an old version for a while
<ijohnson> abeato: re: OVMF_CODE I don't think that's an issue you wouldn't have made it to booting kernel and such if that was the issue
<cmatsuoka> ijohnson: it was the stock bionic qemu I think
<abeato> ijohnson, will try newer qemu, thanks
<cmatsuoka> ijohnson: but with a newer ovmf
<cmatsuoka> from... eoan?
<ijohnson> ahhhh
<ijohnson> cmatsuoka: but again that wouldn't affect networking would it?
<cmatsuoka> never had problems with networking
<cmatsuoka> mm wait, I think in early images we did have some problems with network options in console-conf
<cmatsuoka> but it's already fixed
<ijohnson> cmatsuoka: yeah I've never had problems with no network save when I wasn't able to boot it at all, but the oldest version of qemu I used was disco
<ijohnson> (the version of qemu from disco)
<zyga> mvo: https://github.com/snapcore/snapd/pull/8394#discussion_r401697213
<mup> PR #8394: snap: add `snap debug state --is-seeded` helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/8394>
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8378#pullrequestreview-385691376 +1
<mup> PR #8378: o/configcore: introduce core config handlers (3/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8378>
<pstolowski> zyga: thanks!
<zyga> hmm
<zyga> latest lxd is not working on arm
<zyga> fresh install fails
<zyga> Error: Get "http://unix.socket/1.0": dial unix /var/snap/lxd/common/lxd/unix.socket: connect: permission denied
<zyga> ah, on core we're not adding the user to the lxd group
<zyga> bummer
<zyga> I'll resume reviews in an hour
<zyga> my family needs some help
<zyga> o/
<mvo> zyga: thanks, in meetings but looking now
 * ijohnson takes a break
<mvo> zyga: please reload 8394, looks ok to me, looks like the comment thing stale detection was not working
<zyga> mvo: I reloaded and it's still saying "Output if seeding was successful"
<zyga> is that expected?
<mvo> zyga: yeah, it's different from before
<zyga> oh
<mvo> zyga: do you think this should be different?
<zyga> I mean the word output is weird
<zyga> output what?
<mvo> zyga: "Output true/false if seeding was successful"?
<zyga> yeah but the help message just says "output if seeding was succesful"
<zyga> what you said above is better
<mvo> zyga: ok, will update
<zyga> it's ok
<zyga> I can send a follow up
<zyga> just wasn't sure if github is broken
<zyga> or if we are talking about separate things without knowing it
<zyga> mvo: LGTM and I'll send a patch
<zyga> +1
<mvo> zyga: updated
<zyga> thank you :)
<mvo> zyga: slightly changed but hopefully good
<mvo> zyga: let me know :)
<zyga> yeah, that's good :)
<zyga> thanks!
<mvo> zyga: thank you!
<mvo> zyga: this will unblock 2.44.2 :)
<mup> PR snapd#8394 closed: snap: add `snap debug state --is-seeded` helper <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8394>
<cachio> cmatsuoka, zyga reboot loop in digital ocean also happens
<cachio> same bahaviour
<cachio> so it is not related to gce
<mvo> zyga, ijohnson I updated 8382 to use the snap debug validate-seed to properly fix/disable this
<ijohnson> mvo: nice looking now
<mvo> ijohnson: indeed, I'm much happier with this than with what we had before
<ijohnson> yes this will hopefully make it a much better experience for users who run into this
<ijohnson> mvo thanks, approved
<mvo> \o/
<mvo> thank you!
<mup> PR snapd#8393 closed: cmd/snap,seed: validate full seeds (UC 16/18) for 2.44 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8393>
<mvo> cachio: do we need anything for 2.44.2, any test fixes or anything? if not I will most likely finalize it tonight/tomorrow morning
<cachio> mvo, no
<cachio> mvo, no so far
<mvo> cool
<mup> PR snapd#8384 closed: tests: run "lxd" test again (reverts PR#8381) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8384>
<zyga> mvo: looking
<mup> PR snapd#8370 closed: snap-bootstrap: fix disk layout sanity check <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8370>
<zyga> mvo: https://github.com/snapcore/snapd/pull/8382#pullrequestreview-385768438
<mup> PR #8382: packaging: detect/disable broken seed in the postinst <Created by mvo5> <https://github.com/snapcore/snapd/pull/8382>
<mvo> zyga: replied
<zyga> mvo: approved, thanks
<mvo> zyga: \o/
<jdstrand> mvo (cc ijohnson): I reviewed PR 8304 (and removed the blocked tag)
<mup> PR #8304: usersession/userd: add zoommtg url support <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8304>
<jdstrand> ijohnson: note, there is a non-blocking comment in there about zoomus://
<ijohnson> thanks jdstrand I haven't seen that before, have you ever seen zoomus:// ?
<jdstrand> ijohnson: no, just in that blog. it seems like it is just for iOS/android
<ijohnson> jdstrand: ack
<jdstrand> ijohnson: but I don't know for sure
<mup> PR snapd#8304 closed: usersession/userd: add zoommtg url support <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8304>
<ijohnson> mvo: do you want to cherry-pick 8304 on top of release/2.44  ?
<ogra> jdstrand, snap install zoom-client ;) (sadlyy i cant make it register a mime type to open zoomus:// urls yet)
<jdstrand> ogra: https://forum.snapcraft.io/t/allow-snaps-to-register-new-mime-types/6467/10
<jdstrand> ogra: I suggest Wimpress or someone raise this in stakeholders meetings to see if it can get roadmapped
<ogra> well, it isnt urgent and i know there are more pressing tasks on the TOD of the snapd team ... but yeah, i saw that
<ogra> *TODO
<ogra> iirc that thread is pretty old already
 * ogra checks again
<jdstrand> ogra: it is, but with new comments
<jdstrand> ish
<ogra> yeah
<cjp256> stgraber: came across an random failure `aa-exec: Permission denied` during `lxd waitready` following snap install: https://travis-ci.org/github/snapcore/snapcraft/jobs/666847835#L403  I'm not sure if it's an LXD issue or maybe a snapd issue?  Any idea?  Happy to submit a bug report, just wanted to send it to the right place :)
<stgraber> cjp256: sounds like the lxd-support interface wasn't properly connected or applied
<cjp256> stgraber: thanks!
<cjp256> stgraber: fwiw, reported at https://bugs.launchpad.net/snappy/+bug/1870201
<mup> Bug #1870201: lxd-support interface doesn't appear to get properly connected/ready <Snappy:New> <https://launchpad.net/bugs/1870201>
<mup> Bug #1870201 opened: lxd-support interface doesn't appear to get properly connected/ready <Snappy:New> <https://launchpad.net/bugs/1870201>
<interfect> Hey, what directories does snapd store state in?
<interfect> I'm trying to run snapd inside Docker, and I need to set up volumes wherever snapd writes files it expects to read later, so I can destroy and recreate the container and not lose installed snaps.
<interfect> Apparently preserving /var/run/snapd and /var/cache/snapd is not sufficient. Where else does snapd write to?
<ogra> /etc/systemd/system ....
<ogra> and /varLib/snapd
<ogra> */var/lib/snapd
<ogra> and if you have users also ~/snap and all the data therein
<interfect> Hm. It looks like it drops files in /etc/systemd/system which need to be preserved, next to a bunch of files from the base image that also need to be there. So you can't just mount an empty host directory there to hold snapd's files, because that would hide all the files from the base system.
<zyga> stgraber, cjp256 we've seen this randomly in tests as well
<zyga> but I'm skeptical it's on snapd side, we really don't run any commands before confinement is set up
<zyga> as for the case that an interface is not connected we would have to look
<zyga> stgraber: when does lxd use aa-exec? super early on?
<mup> PR snapd#8392 closed: tests: remove google-tpm backend from spread.yaml <Simple ð> <Skip spread> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8392>
<mup> PR snapd#8396 closed: tests: install dependencies with apt using --no-install-recommends <Simple ð> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8396>
<stgraber> zyga: in this case, cjp256 is running the "lxd" command from the snap which does use the a--exec wrapper logic
<zyga> cjp256: in the case when it failed, did it work just a moment later
<zyga> cjp256: or did you have to do something to fix it?
<cjp256> zyga: it was on google spread, i couldn't really do anything to test that unfortunately
<zyga> aha
<zyga> yeah, same as we saw :/
<zyga> it's rather infrequent, maybe once a week
<cjp256> but i expect that it worked fine on the next attempt
<cjp256> i imagine we can just write a simple script to loop the same steps and maybe repro
<interfect> OK I worked out how to get the volume to initialize from the container with https://github.com/MatchbookLab/local-persist but preserving /etc/systemd/system and /var/lib/snapd and /home isn't enough to make snapd keep its state across destruction and recreation of the container.
<interfect> Or rather it seems that the snap stays installed but the command it sets up on the PATH goes away
<interfect> Is /snap/bin bind-mounted over from somewhere else on the filesystem or something?
<ijohnson> interfect: unfortunately snapd inside docker does not really work, because snapd needs lots of permissions to run, so even if you can get all the files in place, snapd would probably not start successfully
<interfect> No I have it starting successfully, and I can even run snaps!
<interfect> It looks like mounting /snap as a Docker volume also solves the persistence problem.
<interfect> I'm working on top of https://github.com/ogra1/snapd-docker
<interfect> But I'm adding the bits I need to also grant X11 access
<interfect> It manages to turn off enough of Docker's confinement that snapd can run and do its confinement.
<interfect> The only problem I have left is that I need to start a snap as root before it runs properly as my user.
<interfect> Otherwise I get something like: cannot preserve mount namespace of process 875 as teatime.mnt: Permission denied
<interfect> The only Google result for that error is the snapd source code; can anyone explain why it needs to preserve a mount namespace and why it would only work if root is running the `snap` binary? `snapd` is running as root the whole time.
<ijohnson> interfect: ah well if you're using the bits from ogra's snapd-docker then you've already probably read the large security caveats there
<ijohnson> interfect: why can't you run snaps outside of docker anyways?
<ijohnson> interfect: I don't know exactly what you need to allow to make that mount namespace error go away, but it's quite likely that things have changed in snapd enough that ogra's project doesn't fully work there
<mup> PR snapcraft#3008 opened: cli: use the channel-map api for status <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3008>
<interfect> ijohnson: My home directory isn't under /home on my system, so I'm trying to work around the lack of any support in snapd for this: https://forum.snapcraft.io/t/support-for-non-home-homedirs/11209
<interfect> ijohnson: If I run snapd and all the snaps in a Docker container, I can mount my real home directory as /home/$USER in the container, and also provide a /etc/passwd that claims that that is my home directory.
<interfect> The recommended workaround of bind mounting your home directory into /home isn't sufficient, because it looks at /etc/passwd instead of $HOME for the user executing the snap to try and figure out where the home directory is.
<interfect> So in addition to doing the bind mount you would still have to actually change your home directory to /home/$USER, as far as I can tell.
<interfect> There must be a much lighter-weight way to trick snap/snapd into thinking your home directory is actually set to /home/$USER, but I haven't found one, and putting the whole thing in Docker seems to actually mostly work.
<interfect> IMHO if Snap apps just saw my home directory as /home/$USER wherever it *really* was, it would save me a lot of headaches. I'm not sure having a consistent view of file paths between snap apps and the rest of the system is really that important.
<mup> PR snapd#8397 opened: cmd/snap-confine/mount-support-nvidia.c: add libnvoptix as nvidia library <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8397>
<mup> PR snapd#8254 closed: usersession/userd: add "zoommtg" to the white list of URL schemes handled by xdg-open <â Blocked> <Created by troyready> <Closed by troyready> <https://github.com/snapcore/snapd/pull/8254>
#snappy 2020-04-02
<mup> PR snapd#8398 opened: usersession/userd: add "slack" to the white list of URL schemes handled by xdg-open <Created by troyready> <https://github.com/snapcore/snapd/pull/8398>
<mborzecki> morning
<mborzecki> mvo: hey
<mborzecki> mvo: the console_conf PR in subiquity has landed
<mborzecki> mvo: i'm assembling the image to try everything out
<mvo> hey mborzecki
<mvo> mborzecki: niiiiiiiiiiiice
<pstolowski> morning
<mvo> hey pstolowski
<mborzecki> pstolowski: hey
<mup> PR snapd#8397 closed: cmd/snap-confine/mount-support-nvidia.c: add libnvoptix as nvidia library <Simple ð> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8397>
<zyga> Hey
<zyga> Had a very fractured night
<zyga> Barely awake now
<zyga> Sorry, I will be late today
<zyga> I will not be at the desktop sync
<mup> PR snapd#8382 closed: packaging: detect/disable broken seed in the postinst <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8382>
<mvo> pedronis_, zyga, pstolowski, mborzecki I will release 2.44.2 this morning, please let me know if there is anything last-minute you want to have in it
<mup> PR snapd#8226 closed: interfaces/policy/policy_test.go: add more tests <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8226>
<zyga> ack
<zyga> mvo: I would really like to have https://github.com/snapcore/snapd/pull/8089
<mup> PR #8089: features: enable robust mount ns updates <Created by zyga> <https://github.com/snapcore/snapd/pull/8089>
<zyga> mvo: but it's up to you
<mvo> zyga: hm, it's not on master yet, we should at least get it there
<zyga> mvo: yeah but it's pending for a long time
<zyga> just shinging some light on it
<mvo> zyga: ta
<zyga> if it helps our customers enable it via gadget
<zyga> and it's well-known to improve
<zyga> er, cause improvements
 * zyga is trying to say awake
<mvo> zyga: I'm not against it, just saying it needs to land in master first and get reviews etc
<mvo> zyga: haha - did you had coffee already :) ?
<zyga> +3/-2 - let's review it :)
<zyga> mvo: yeah, my wife just brought me a cup
<zyga> 2-3 AM, 4AM, 6AM wake-ups (for me) last night, not great
<mborzecki> meh, when i repack cor20 snap the system no longer boots, it stops at initrd-switch-root and complains it cannot resolve /sbin/init even though /sysroot/sbin/init is there (though it points to /lib/systemd/systemd but it's there too)
<pstolowski> mvo: thanks, i don't have anything
<zyga> mborzecki: is there any write-up on how to try core20 locally?
<zyga> mborzecki: can you please review the tiny branch referenced above (8089)
<mborzecki> zyga: try or build?
<zyga> mborzecki: be able to run from source
<zyga> mborzecki: boot and see what happens, etc
<zyga> mborzecki: (in qemu)
<mborzecki> zyga: i don't think so, but it's the usual thing, grab the model, build image with u-i, run qemu but adding UEFI
<pstolowski> grr during the transition to new laptop i forgot to set git author initially and managed to commit with defaults to all my PRs, and have to fight with CLA checks (need rebasing to fix as it's for past commits, not just latest)
<zyga> mmm
<zyga> pstolowski: ouch, there's a way to rewrite the author and committer documented in git rebase
<zyga> pstolowski: you didn't migrate your HOME?
<pstolowski> zyga: i know of git commit --amend --reset-author which works for last commit; i'm not sure rebase has anything specific like that, but simply rebasing fixes this
<abeato> hm, CI fails on 'apt update'
<pstolowski> zyga: yeah i didn't migrate home, i wanted to have clean slate (instead of removing cruft after migration)
 * zyga nods
<mborzecki> aah
<mborzecki> w8, how's that even possible?
<zyga> mborzecki: 2 st phase of debugging
<zyga> 2st is a new number, between 1st and 2nd
 * zyga should sleep
 * mborzecki trying a differnt rsync incantation
<mborzecki> rsync --wingardium-leviosa --dwim
<zyga> it works on 2st try
<mborzecki> yup, much better now
<abeato> could somebody retrigger tests for https://github.com/snapcore/snapd/pull/8320 ?
<mup> PR #8320: interfaces: updates to login-session-observe, network-manager and modem-manager interfaces <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/8320>
<mup> PR snapd#8399 opened: interfaces/policy: fix comment in recent new test <Created by pedronis> <https://github.com/snapcore/snapd/pull/8399>
<mborzecki> btw. snap debug state is super slow when there's many tasks
<mup> PR snapd#8400 opened: osutil: make the TestWriter() test less racy <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8400>
<zyga> mvo: let's merge it but I left a kind of -1 comment
<mvo> zyga: tell me how to do it non-racy :)
<mvo> zyga: I thought aobut it but couldn't come up with an idea
<zyga> that's much more towards a solution than what we usually do :)
<zyga> mvo: no that I disagree it is hard
<mvo> zyga: I mean, we test that during the time until the deadline is triggered we get data
<mvo> zyga: *if* the system is that slow that there is just no thread scheduled during $time we lost
<zyga> mvo: but just doing 0.1 seconds * number_of_times_we_had_to_change_it really feels iffy
<zyga> mvo: I get that, but in general a test for more than one concurrent activity must not be based on wall clock time
<mvo> zyga: well, $time is a fundamental part of the test, so I don't really know how to do it non-racy, I'm open for ideas though
<zyga> mvo: here it seems that way but really what you want is to show a certain sequence of events happens in two threads
<zyga> mvo: not that it took this amount of time or that amount of time
<mvo> zyga: yes, in general I agree, but this test is precisely about testing wall-clock behavior
<zyga> mvo: anyway, I will look
<zyga> mvo: I think at some point the tipping point makes us research how to deal with sutuff
<zyga> *stuff
<zyga> mvo: I can only re-iterate that this is not about that wall clock time _at all_ but about the sequence
<zyga> mvo: in a way if we find a way to do this we will get correct *and* faster tests
<mvo> zyga: did you look at the test? it's about hitting a deadline and what happens until this deadline is hit
<zyga> as arbitrary sleep durations go away
<zyga> mvo: I did, perhaps my point is not expressed clearly enough though
<zyga> mvo: anyway, I will look
<mvo> zyga: don't get me wrong, I agree 100% in general, but I don't see how to do this for this specific case
<mborzecki> hmmm soo, the chooser run nicely in a local terminal, but is stul reading from stdin when running in a uc20 shell, same command line but different effect
<mborzecki> even simple echo '{}' | python3 -m console_conf.cmd.tui --recovery-chooser-mode is stuck
<mvo> mborzecki: oh no!
<pedronis> mvo: mmh
<zyga> mborzecki: can you debug log the mode of stdin/stdout
<zyga> mborzecki: are you in binary or text mode
<zyga> mborzecki: what's the encoding?
<mborzecki> ah w8, maybe that
<pedronis> mvo: those tests are really testing context.WithTimeout, not our code
<zyga> mborzecki: cheers :)
<pedronis> mvo: so a bit unclear if need all of them, or the cancel one is enough
<pedronis> or we just need our own base context
<mvo> pedronis: fair enough, we could remove it entirely
<mvo> pedronis: happy to update the PR to remove it, wdyt?
<pedronis> mvo: I think the Cancel one is enough, but maybe I'm missing something ?
<pedronis> we lose the happy case ?
<pedronis> maybe the happy case is just with a cancelable that we cancel after and not before
<mvo> pedronis: I guess so, I don't know more about this particular case then you :) it was a drive-by from my bug triage
<mup> PR snapd#8401 opened: snap: improve TestWaitRecovers test <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8401>
<zyga> mborzecki: the chooser was merged but I will continue with my review
<zyga> mborzecki: there are some things that probably ought to be followed upon
<mwhudson> can i make stage-packages: architecture dependent?
<mvo> mwhudson: iirc "- on amd64\n  - "pkg"" works
<mwhudson> mvo: just found a forum post with a syntax like that, yeah
<mwhudson> mvo: is it documented at all?
<mvo> mwhudson:
<mvo> mwhudson: https://forum.snapcraft.io/t/architectures/4972
<mvo> mwhudson: I thnk that might be the docs
<mvo> mwhudson: actually no
<mvo> mwhudson: it's just about the architecture :/
<mwhudson> like can i say - on amd64, arm64\n  - efibootmgr
<mborzecki> damn, it works over ssh, but not in a console
<mborzecki> zyga: ^^
<zyga> mborzecki: what do you get in the console
<mvo> mwhudson: yeah, this should work
<zyga> mborzecki: binary/text?
<zyga> mborzecki: and what encoding if text
<mborzecki> even though i added LANG, TERM and whatnot in the console
<zyga> mborzecki: did you add the debugging?
<mvo> mwhudson: I couldn't find docs for this, might be worthwhile to check with degville and/or the snapcraft guys if "stage-package:\n- on $arch:\n  - pkg1" is documented somewhere and just hard to find
<mwhudson> mvo: i shall whine on the forum!
<mvo> mwhudson: :) +1
<abeato> mvo, could you please retrigger tests for https://github.com/snapcore/snapd/pull/8320 and https://github.com/snapcore/snapd/pull/8220 ?
<mup> PR #8320: interfaces: updates to login-session-observe, network-manager and modem-manager interfaces <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/8320>
<mup> PR #8220: interfaces/seccomp: allow passing an address to setgroups <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/8220>
<mwhudson> mvo, degville: what's "try" about in this context?
<mvo> abeato: sure, looking
<mwhudson> aaah i found https://snapcraft.io/docs/snapcraft-advanced-grammar
<mup> PR snapd#8320 closed: interfaces: updates to login-session-observe, network-manager and modem-manager interfaces <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8320>
<pedronis> mborzecki: mvo: what's the status of #8253 ?
<mup> PR #8253: snap-bootstrap: expand data partition on install <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8253>
<pedronis> mvo: do we need it for beta?
<mborzecki> pedronis: thought i +1'ed it already, let me check
<mborzecki> pedronis: there's an open question about explicitly identifying expand/noexpand for partitions at the gadget yaml level, but i don't think we can resolve it now
<mvo> mborzecki: I would say let's always expand and if we have a use-case *not* to do that we can add an extension to the gadget.yml (cc pedronis) - irrc this is what I suggested in there too, no?
<pedronis> mvo: it sounded you suggested the reverse, to have an explicit way to expand
<mvo> pedronis: that was my first thinking but that's silly, it will be the common case I think, let me clarify
<mvo> pedronis: I updated the PR with my thinking, hope it makes sense
<mup> PR snapd#8378 closed: o/configcore: introduce core config handlers (3/N) <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8378>
<mup> PR snapd#8402 opened: o/configstate: add backlight option for core config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8402>
<mup> PR snapd#8160 closed: overlord/configstate: add backlight option <Created by EthanHsieh> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/8160>
<mup> PR snapd#8220 closed: interfaces/seccomp: allow passing an address to setgroups <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8220>
<mborzecki> mvo: soo it works :P
<mborzecki> mvo: need to patch subiquity though
<ijohnson> morning folks
<ijohnson> hey mborzecki seems I missed the deadline on your subiquity PR, but I still would like to do a review
<zyga> ijohnson: I'm doing a review as well
<mborzecki> ijohnson: hey, no problem
<zyga> I think that's good
<zyga> and yes, you should too
<mborzecki> btw. so with patched subiquity, it works, i can trigger the chooser, the UI runs and all, reboot is requested
<mborzecki> but then i get this: https://i.imgur.com/IYb0mgs.png
<mborzecki> it'd noble that it's trying fd0 but i doubt it's gonna succeed anytime soon
<zyga> fd0?
<zyga> whaat :)
<zyga> insert assertion in disk A and pres return to continue ;D ?
<zyga> *press
<mborzecki> haha right? :)
<ijohnson> haha wow
<zyga> mborzecki: https://github.com/CanonicalLtd/subiquity/pull/655#pullrequestreview-385648364
<mup> PR CanonicalLtd/subiquity#655: console_conf: implement UC20 recovery chooser <Created by bboozzoo> <Merged by xnox> <https://github.com/CanonicalLtd/subiquity/pull/655>
<pstolowski> pedronis: is this https://forum.snapcraft.io/t/how-to-install-and-enable-syslog/15012 the general idea wrt persistent storage config flag?
<zyga> post merge review for https://github.com/snapcore/snapd/pull/8370#pullrequestreview-385530483
<mup> PR #8370: snap-bootstrap: fix disk layout sanity check <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8370>
<pedronis> pstolowski: yes,  something like that, not sure the directory needs to be created or not
<pedronis> it needs to be created for auto
<pedronis> but not sure about persistent
<zyga> ijohnson: can you review https://github.com/snapcore/snapd/pull/8389 as well, it would help me make progress
<mup> PR #8389: tests: make session tool way more robust <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8389>
<ijohnson> sure I was meaning to look at it
<zyga> it's not the end of that road
<zyga> but it's a step along the way
<pstolowski> pedronis: ok. so we want to support actual systemd storage type as a config option (auto|persistent), and not simplify it/hide it behind e.g. persistent=true|false?
<pedronis> pstolowski: just persistent=true|false, I don't think auto makes a lot of sense for use on core
<pedronis> pstolowski: it might be that we implement false as auto
<pedronis> but not sure , we can discuss in the PR
<mborzecki> so should the auto-import udev rule have KERNEL!="fd*" as well?
<pstolowski> pedronis: ok, thanks
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8402#pullrequestreview-386327449
<mup> PR #8402: o/configstate: add backlight option for core config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8402>
<pstolowski> zyga: thanks
<ijohnson> zyga: approved with a question about busctl
<zyga> ijohnson: looking
<zyga> FYI, the contributor needs to go through the CLA process
<zyga> I didn't find any documentation on that in our HACKING
<zyga> should we have some?
<zyga> https://github.com/snapcore/snapd/pull/8398
<mup> PR #8398: usersession/userd: add "slack" to the white list of URL schemes handled by xdg-open <Created by troyready> <https://github.com/snapcore/snapd/pull/8398>
<zyga> ijohnson: replied
<ijohnson> thanks
<zyga> ijohnson: I added one more comment at the bottom of session-tool spread test
<zyga> ijohnson: I wanted to take a break from this monstrosity and look at other things for a while (reviews) but I need to address this in a follow-up
<zyga> ijohnson: if you are happy with my comments I will merge this now
<ijohnson> sure no problem
<ijohnson> go for it
<zyga> thank you!
<zyga> I'll include -- and the comments you mentioned in a follow up
<zyga> and now reality will verify my oh-so-alredy-regretful commit message
<zyga> "make session tool way more robust"
<mup> PR snapd#8389 closed: tests: make session tool way more robust <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8389>
<ijohnson> next PR: "make session tool way way way more robust for realz this time (I promise)"
<zyga> ijohnson: I will probably use "tests/session-tool: you cannot wait to see how this will break next"
<ijohnson> zyga: "tests/session-tool: this one weird trick makes old linux distros so mad"
<zyga> ijohnson: "tests/session-tool: mark as manual and move to tests/masochism"
<zyga> I'll go make coffee and return to prepare the big PR with things that have recently landed
<mvo> mborzecki: nice, is the patch complicated?
<mborzecki> mvo: no, it's quite trivial, got merged already
<zyga> ogra: https://github.com/snapcore/snapd/pull/8329#pullrequestreview-385876868
<mup> PR #8329: interfaces: allow raw access to USB printers <Created by ogra1> <https://github.com/snapcore/snapd/pull/8329>
<zyga> mborzecki: is your comment on https://github.com/snapcore/snapd/pull/8377 a +1?
<mup> PR #8377: sandbox/cgroup: add ProcessPathInTrackingCgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/8377>
<mup> PR snapd#8399 closed: interfaces/policy: fix comment in recent new test <Skip spread> <Created by pedronis> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8399>
<sdhd-sascha> hi, all :-)
<mup> PR snapd#8377 closed: sandbox/cgroup: add ProcessPathInTrackingCgroup <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8377>
<sdhd-sascha> I didn't write C++ yet. I read a lot about it, around 12 years ago. Now, i help a very very litle bit with the backend of #WirVsVirus. What DB layer is scalable, and NoSQL. What DB should is a choice for this task ?
<sdhd-sascha> Can anybody give a hint ?
<zyga> sdhd-sascha: don't use json with manual serialization
<sdhd-sascha> zyga: ?
<zyga> sdhd-sascha: we don't have experience with nosql beyond that I think
<sdhd-sascha> i found mongo, with this: https://github.com/datastax/cpp-driver
<sdhd-sascha> But, why use in 2020 a language where i have to free memory manually ?.... Oooh
<sdhd-sascha> Don't know why C++ was the choice... ;-)
<ogra> zyga, commented
<mup> PR snapd#8401 closed: snap: improve TestWaitRecovers test <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8401>
 * ogra curses ... why did nvidia *completely* change with the nvidia-4XX series .. 
<zyga> ogra: to punish us for not pushing ahead with nvidia-runtime snap
<ogra> yeah apparently ...
<zyga> mvo: master is over 50 minutes in travis now
<zyga> mvo: we're going to see failures soon
<ogra> sadly i have a snap where i need to force-preload the nvidia libs (it completely unsets LD_LIBRARY_PATH and is proprietary) ... works just fine with nvidia-3XX and before ... but with 440 ... i get
<ogra> ERROR: ld.so: object '/var/lib/snapd/lib/gl/libOpenGL.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
 * sdhd-sascha ogra: ooh, nvidia ;-)
<ogra> the lib is there with find and ls and the ldd dependencies dont seem to have changed vs 3XX either ... i dont get why i cant preload it
<zyga> ogra: it's classic?
<ogra> nope
<ogra> strict
<zyga> hmm
<ogra> zoom-client
<zyga> can we ldconfig to look at /var/lib/snapd/gl
<zyga> and drop that silly SNAP_LIBRARY_PATH thing?
<ogra> well, all these vars get unset by the zoom binary ... i cant make any use of them anyway
<zyga> ogra: hence >  can we ldconfig to look at /var/lib/snapd/gl
<zyga> ogra: so no variables at all but it _still looks_
<zyga> ogra: we could even be more ... say, creative
<zyga> and have a new mount point
<zyga>  /app
<ogra> hmm
<zyga> and mount current revision of the app there
<zyga> and have a fixed ldconfig
<ogra> does ldconfig actually load anything ? i thought it only resolves deps ...  i need them in ram before the app starts
<zyga> so we take libs from [/var/lib/snapd/lib/*, /app/lib/$triplet, regular locations]
<ogra> or do you mean combine ldconfig and LD_PRELOAD ?
<zyga> ogra: it finds them
<zyga> e.g. copy a .so to /usr/local/lib
<zyga> and run a binary that needs it
<zyga> then ldconfig
<zyga> then run it again
<zyga> we could essentially tell the linker, here they are
<ogra> yes, but zoom doesnt if it isnt loaded already
<zyga> ?
<zyga> this is entirely unrelated to zoom
<ogra> well, i can try ...
<zyga> it would be some work
<zyga> but as a spike to see if it works
<zyga> I think it could
<zyga> repackage core snap to have different ldconfig
<abeato> ijohnson, fyi I have UC20 running yesterday, the crash happened because I was greedy and was no giving enough memory to kvm - I've found I need at least 2GB.
<ijohnson> ah yes that's another thing I forgot to tell you :-)
<ogra> 2GB ... nobody thinks of the netbooks !
<abeato> ijohnson, and the problem with the eth was related to the image, the one I built locally had some problem, maybe I need edge ubuntu-image
<abeato> the cdimage one worked in the end
<ijohnson> abeato: ah that's great news
<abeato> ijohnson, yeah, really happy to start testing uc20 :) - thanks for your help
<zyga> https://github.com/google/thread-weaver
<ogra> moving snapd to java now ?
<zyga> core 22j
<ogra> hah
<zyga> we can finally support arm7tdmi
<ogra> yay, finally going for ARMv4 :)
 * ogra digs in the box for old nokia phones to run core on
<mup> PR snapd#8219 closed: interfaces: use udev backend if udev socket exists <Security-High> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8219>
<mup> PR snapd#7963 closed: xdgopenproxy: forward requests to the desktop portal <â Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7963>
<zyga> mborzecki: follow up https://github.com/snapcore/snapd/pull/8403
<mup> PR #8403: sandbox/cgroup: avoid making arrays we don't use <Simple ð> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8403>
<mup> PR snapd#8403 opened: sandbox/cgroup: avoid making arrays we don't use <Simple ð> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8403>
<ijohnson> hey I fixed the usb audio thing, yet again my usb hub seems to be causing problems :-/ plugging the device directly into my desktop makes it work fine
 * ijohnson is happy with high fidelity audio output now
<mup> PR snapd#8404 opened: client: increase timeout in client tests to 100ms <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8404>
<mvo> zyga: you will love this test failure https://paste.ubuntu.com/p/yKy6G2x59x/ (in a PPA)
<mup> PR snapd#8089 closed: features: enable robust mount ns updates <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8089>
<zyga> mvo: looking
<zyga> Mvo: heh
<mvo> zyga: I will look later
<mvo> zyga: in a meeting right now
 * zyga hugs mvo
<mvo> zyga: but yeah, lots of fun, the PPA is super slow right now
<zyga> Iâm sorry, I know we are in tough times
<zyga> back now
 * zyga took a walk
<zyga> I guess people are renting dogs to walk now
<zyga> I see more people with dogs than I ever did here
 * zyga stares at tig output
<zyga> time to rebase that WIP thing away
<zyga> hmmm
<zyga> import cycle
<zyga> perfect :)
<zyga> https://www.irccloud.com/pastebin/cBg4Sia0/
<zyga> client -> asserts -> release ->sandbox/cgroup -> naming -> snapdenv -> release
<zyga> "fun"
<zyga> I really dislike this part of go
<zyga> as theoretically nice it may be
 * zyga wonders what to do
<zyga> can snapdenv not import release?
<zyga> pedronis: how would you feel if I changed snapdenv.SetUserAgentFromVersion to take arguments instead of consuming release as a package?
<pedronis> zyga: to be honest I feel the proble here is more release -> sandbox/cgroup
<zyga> ok, let me check why that is there
<zyga> ForceDevMode wants to know
<zyga> pedronis: how about we move ForceDevMode to sandbox/ ?
<pedronis> yes, that would have been my proposal too
<pedronis> we can keep some tables or something in release if that make sense
<pedronis> or move them
<zyga> pedronis: the, funny enough, release will be about os-release again :D
<zyga> ok, let me try :)
<mup> PR snapd#8405 opened: boot: simplify modeenv mocking to always write a modeenv <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8405>
<zyga> fun
<zyga> so many cycles
<mvo> mborzecki: I merged 8305, there are some tweaks worth doing in a followup. looks great overall, thanks for pushing this!
<mup> PR snapd#8305 closed: cmd/snap-recovery-chooser: add recovery chooser <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8305>
<mborzecki> mvo: thanks for merging!
<zyga> hmm
<zyga> I think that user agent thing is really a problem
<zyga> but let me try something
<pedronis> zyga: doesn't moving ForceDevMode help?
<zyga> no, it's all interconnected :/
<pedronis> what is interconnected?
<pedronis> master is fine, what's the change?
<ijohnson> zyga: github actions debian dependencies failed again: https://pastebin.ubuntu.com/p/jkYFxdGjdK/
<zyga> https://www.irccloud.com/pastebin/WVqzY0tr/
<zyga> pedronis: I'm trying a few ideas
<ijohnson> zyga: seems like an issue  with the repos?
<zyga> ijohnson: I asked IS about this
<zyga> ijohnson: and it's a spike on a pipe that connects us to them
<pedronis> zyga: sorry, why is snapdenv importing sandbox
<zyga> ijohnson: it's really flaky in the sense that we run out of bandwidth
<ijohnson> zyga: :-/ oh well
<zyga> pedronis: snapdenv needs to know if it's in devmode for the user agent
<zyga> pedronis: ForcedDevMode thing
<zyga> ijohnson: it shows up as an alert on our side (we know it's saturated) and we drop connections
<pedronis> zyga: I see
<ijohnson> cool
<pedronis> I forgot that
<pedronis> let me think a bit
<zyga> pedronis: yeah, I'm looking at this for possibilities
<zyga> pedronis: I'll share what I have soon
<mup> PR snapd#8406 opened: usersession: extend timerange in TestExitOnIdle <Created by mvo5> <https://github.com/snapcore/snapd/pull/8406>
<mvo> woah, down to 52(!) prs
<mvo> yay
<zyga> mvo: yeah, that close button sure works well ;D
<zyga> (I'm in a silly humor mode)
<pedronis> zyga: progress? I think I have some ideas of what I would do
<mvo> zyga: uh  - I did not check how we got to this number :(
<zyga> yeah
<zyga> pedronis: yeah, let me open a PR
<zyga> mvo: by merging, i was just silly
<mup> PR snapd#8402 closed: o/configstate: add backlight option for core config <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8402>
<mup> PR snapd#8253 closed: snap-bootstrap: expand data partition on install <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8253>
<zyga> pedronis: ok
<zyga> pedronis: https://github.com/snapcore/snapd/pull/8407
<mup> PR #8407: many: move IsForcedDevMode to sandbox/misc, move UA to snapdenv/useraâ¦ <Created by zyga> <https://github.com/snapcore/snapd/pull/8407>
<mup> PR snapd#8407 opened: many: move IsForcedDevMode to sandbox/misc, move UA to snapdenv/useraâ¦ <Created by zyga> <https://github.com/snapcore/snapd/pull/8407>
<zyga> pedronis: I verified this really works for me to be able to import cgroup bits in cmd/run
<zyga> there are two patches here, squashed because I reset the tree for simplicity
<zyga> I think sandbox/misc can just become sandbox now though
<zyga> pedronis: I'll clean my other desk and wait for a ping, I'm just a meter away :)
<pedronis> zyga: thank you, I'll probably play a bit with it and push some slightly different org, at least you are unblocked
<zyga> pedronis: I need one to land so if you feel strongly about it please propose yours and lets land it
<zyga> otherwise I cannot merge master and make progress
<pedronis> ?
<zyga> pedronis: I need _any_ variant of this to land to progress
<zyga> (or I must bundle an unapproved variant in my branch temporarily)
<pedronis> that sounds fine
<pedronis> I'm not entirely sure what's the problem with that
<pedronis> anyway my goal here is to reduce the diff, reduce a bit need to add more packages
<zyga> my original problem was inability to import sandbox/cgroup from cmd/snap IIRC
<zyga> or maybe I'm forgetting bits, I'm tired a bit today (ENOSLEEP)
<pedronis> it's ok, I'm just not sure why you think proposing a PR with the intermediate solution is a problem
<pedronis> except for size
<zyga> no, it's not
<zyga> it's ok :)
<kenvandine> jdstrand: i think i need a minor tweak to the appstream-metadata interface
<kenvandine> https://github.com/snapcore/snapd/blob/master/interfaces/builtin/appstream_metadata.go#L49
<kenvandine> that allow read access to the contents of those dirs
<kenvandine> but not read on the dir itself
<kenvandine> jdstrand: right?
<kenvandine> jdstrand: snap-store is checking for read access on the dirs as it iterates them and fails
<jdstrand> kenvandine: are you saying that snap-store is trying to figure out what files are in /usr/share/metainfo and is failing to enumerate them?
<kenvandine> i think it's just checking if it can read the dir
<jdstrand> kenvandine: oh, were you asking what those rules do? yes, not a read on the dir, just everything under the dir
<jdstrand> kenvandine: sounds like you need:
<kenvandine> if i manually tweak the profile, how do i recompile it to test my theory?
<jdstrand> /usr/share/metainfo/{,**} r,
<kenvandine> yeah, i've tweaked the profile locally to test
<jdstrand> kenvandine: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.snap-store.snap-store (or whatever file you modified)
<kenvandine> bingo
<zyga> jdstrand: o/
<zyga> jdstrand: do you have 3minutes?
<jdstrand> kenvandine: I'm planning on doing a PR for some things in the next few days. if I slid this in there, would that be good enough for you?
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/8408 is verbatim from the refresh-app-awareness-v2 branch
<mup> PR #8408: snap/naming: add validator for snap security tag <Created by zyga> <https://github.com/snapcore/snapd/pull/8408>
<zyga> cherry picked to reduce the diff
<kenvandine>  /usr/share/metainfo/{,**} r,
<kenvandine>  /usr/share/appdata/{,**} r,
<kenvandine> jdstrand: that's what i need
<mup> PR snapd#8408 opened: snap/naming: add validator for snap security tag <Created by zyga> <https://github.com/snapcore/snapd/pull/8408>
<kenvandine> jdstrand: that's fine
<kenvandine> we need it in 20.04 ;)
<jdstrand> kenvandine: ack, trello'd
<jdstrand> "to trello: the act of adding or modifying a trello card"
<kenvandine> lol
<kenvandine> jdstrand: thanks!
<jdstrand> kenvandine: np
<zyga> hmm, we may need to discuss deps with IS
<zyga> and I need to check why we don't cache them
<zyga> (deps, repos)
<jdstrand> zyga: what do you need wrt PR 8408?
<mup> PR #8408: snap/naming: add validator for snap security tag <Created by zyga> <https://github.com/snapcore/snapd/pull/8408>
<jdstrand> zyga: a review now?
<jdstrand> zyga: or something else?
<zyga> jdstrand: please either look if you want to review it and if so enqueue it, or just defer the review to others
<jdstrand> zyga: enqueued, thanks!
<zyga> thanks!
 * zyga EODs and returns to cleaning stuff from the other desk
<jdstrand> bye zyga :)
<zyga> bye, have a good evening :)
<mup> PR snapd#8409 opened: snap-bootstrap: seal and unseal encryption key using tpm <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8409>
<mup> PR snapd#8095 closed: snap-bootstrap: add tpm support (draft) <UC20> <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/8095>
<mup> PR snapcraft#2999 closed: requirements: uprev python-apt to 1.6.0 (bionic package) <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2999>
<mup> PR snapd#8405 closed: boot: simplify modeenv mocking to always write a modeenv <Simple ð> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8405>
<mup> PR snapd#8410 opened: many: disentagle release and snapdenv from sandbox/* <Created by pedronis> <https://github.com/snapcore/snapd/pull/8410>
<mup> PR snapd#8407 closed: many: move IsForcedDevMode to sandbox/misc, move UA to snapdenv/useraâ¦ <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8407>
<mup> PR snapcraft#3007 closed: go: support projects with multiple binaries when using go.mod <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3007>
<mup> PR # closed: core#38, core#107, core#108, core#110, core#111
<mup> PR snapd#8411 opened: boot: cleanup more things, simplify code <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8411>
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#51, core-build#58
<mup> PR snapcraft#3000 closed: repo: use python-apt's fetch_binary implementation <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3000>
<mup> PR snapcraft#3009 opened: repo: use python-apt's fetch_binary implementation <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3009>
<mup> PR snapcraft#3008 closed: cli: use the channel-map api for status <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3008>
<zyga> snapd is blocked in debian
<zyga> dh_missing: warning: usr/bin/snap-preseed exists in debian/tmp but is not installed to anywhere
<mup> PR snapcraft#3009 closed: repo: use python-apt's fetch_binary implementation <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3009>
<mup> PR snapcraft#3010 opened: cli: add progressive releases support to the release command <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3010>
#snappy 2020-04-03
<mup> PR snapcraft#2916 closed: status: implement using the new channel-map endpoint <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2916>
<mup> PR snapcraft#2992 closed: [WIP] repo: ubuntu implementation refactoring with initial package-management <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2992>
<mup> PR snapcraft#3006 closed: repo: always use host release and arch for Ubuntu <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3006>
<mborzecki> morning
<mborzecki> mvo: hey
<mvo> mborzecki: good morning
<mup> PR snapd#8410 closed: many: disentagle release and snapdenv from sandbox/* <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8410>
<mup> PR snapd#8412 opened: httputil: increase httpclient timeout in TestRetryRequestTimeoutHandling <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8412>
<mup> PR snapd#8404 closed: client: increase timeout in client tests to 100ms <Simple ð> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8404>
<pstolowski> morning
<mvo> good morning pstolowski
<zyga> good morning
<zyga> hey mvo,
<zyga> mvo: I noticed we have a small problem in debian
<zyga> mvo: snapd doesn't build
<zyga> dh_missing: warning: usr/bin/snap-preseed exists in debian/tmp but is not installed to anywhere
<zyga> I think we have different ruleset there, and leftover binaries cause builds to fail
<zyga> I'll see if I can use my shiny metal rights and actually help
<jamesh> Had another CI run hit Travis's 50 minute limit: https://travis-ci.org/github/snapcore/snapd/builds/670392870
<zyga> jamesh: I'll move travis jobs to actions today
<zyga> I think it's time
<mvo> good morning zyga
<mvo> 8103 needs a second review, it's important for the encryption story and to unblock the TPM work
<mvo> jamesh: thanks for letting us know, once we are slightly less busy we move to gh actions to get rid of this
<mvo> jamesh: also thanks for your review on 8406, I really have no better idea unfortunately how to make this better, maybe we could increase the sleep to 100ms to have a bigger "window" of time to look at. yeah, over-committed CI systems are  very annyoing
<mvo> (fwiw 8103 is not very long, hopefully quick review)
<mup> PR snapd#8413 opened: interfaces: don't use the owner modifier for files shared via document portal <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8413>
<mvo> jamesh: if 8406 looks ok enough please approve, if you feel it makes the test useless I could close and we just need to live with the errors
<jamesh> mvo: I think the change looks good.  When run on an unloaded system, it should still verify that the timeout has been extended
<mvo> zyga: session-tool fails on master https://api.travis-ci.org/v3/job/670441262/log.txt - could you please ahve a look?
<zyga> Yes
<mup> PR snapd#8406 closed: usersession: extend timerange in TestExitOnIdle <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8406>
<jamesh> pedronis_: I think the extra spread test I added covers what you wanted in my user daemons PR
<pedronis> jamesh: thanks
<zyga> pedronis: thank you for the move yesterday!
<mup> PR snapd#8414 opened: o/configstate: core config handler for persistent journal <Created by stolowski> <https://github.com/snapcore/snapd/pull/8414>
<pstolowski> ogra: hi, this might be interesting for you ^ (feedback is welcome)
<ogra> nice !
<ogra> pstolowski, you are aware that etc/systemd/journald.conf.d/ is complete nonsense ?
<pstolowski> ogra: heh, not, why?
<ogra> pstolowski, all you need to do is to create the dir ...
<pstolowski> ogra: you mean /var/log/journal ?
<ogra> the builtin defaults are completely fine, if the dir exists journald writes the journal to disk ... if not it uses the ringbuffer ... there is no need to change the config
<ogra> yeah
<pstolowski> huh
<ogra> i'D just make the code call a mkdir and be done ;)
<pstolowski> mhm
<ogra> (and rmdir if the option is unset)
<pstolowski> ondra: is this consistent across systemd versions (core16, core18...)?
<pstolowski> sorry, ogra ^
<ogra> notsure what ondra thinks ... but it surely is for 16 and 18
<ogra> :)
<ogra> might be that 20 changed it though ... better test there .... for 16 and 18 it was always sufficient to just create the dir
 * ondra agrees with anything ogra says, as long as it's not about partitions!
<ogra> !
<pstolowski> ogra: ok, that's interesting, thank you!
<ogra> thank *you* for implementing it !!
<ogra> :D
<pstolowski> ogra: ah, i read the manualy again. so it appears that "auto" is the default behavior,  the existense of /var/log/journal controls the behavior
<ogra> yep :)
<pstolowski> ogra: thanks again for the enlightenment ;)
<zyga> pstolowski, ogra: related review https://github.com/snapcore/snapd/pull/8414#pullrequestreview-387089711
<mup> PR #8414: o/configstate: core config handler for persistent journal <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8414>
<pstolowski> zyga: thanks. we might not need the conf file at all, i'm going to verify this
<zyga> thanks
<zyga> ping me for a re-review please
<mup> PR snapd#8415 opened: cmd/snap-recovery-chooser: tweaks <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8415>
<pedronis> mborzecki: I nitpicked a bit in #8415
<mup> PR #8415: cmd/snap-recovery-chooser: tweaks <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8415>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8415#pullrequestreview-387112832
<mup> PR #8415: cmd/snap-recovery-chooser: tweaks <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8415>
<mborzecki> pedronis: zyga: thanks
<zyga> I'll be back shortly, it's quite cold in the office and ought to make some warm tea
<zyga> mborzecki: unit tests failed on that PR
<mborzecki> waat?
<zyga> https://www.irccloud.com/pastebin/NkNEOsNj/
<zyga> not yours but meh
<zyga> mvo: ^
<zyga> is that another thing to adjust?
<mborzecki> weird, that timeout is longer already
<mborzecki> maybe a bug in the test/code?
<mvo> zyga, mborzecki I thought I did push something there?
<zyga> ah, perhaps maciek's branch is simply older
<mvo> https://github.com/snapcore/snapd/pull/8412
<mup> PR #8412: httputil: increase httpclient timeout in TestRetryRequestTimeoutHandling <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8412>
<mborzecki> mvo: yes, https://github.com/snapcore/snapd/pull/8404 has landed already
<mup> PR #8404: client: increase timeout in client tests to 100ms <Simple ð> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8404>
<mvo> mborzecki: this one is different, no? that's what 8412 is for
<mvo> mborzecki: or am I misreading this?
<mborzecki> pstolowski: mvo: i think there's a problem with persistent logs, /etc/machine-id isn't mounted from writable (at least on core20) so after reboot you get a new machine-id and a new journal
<mborzecki> oh, w8, it is
<mborzecki> so why did i get a new machine-id again?
<pstolowski> mborzecki: works as expected on core18
<pstolowski> (i rebooted)
<mborzecki> hmmmm ââ/etc/machine-id  tmpfs[/machine-id]   tmpfs      ro,size=203112k,mode=75
<zyga> yeah
<mborzecki> pstolowski: mvo: ^^
<zyga> why do we have machine-id on a tmpfs
<zyga> mborzecki: we noticed this a while ago
<zyga> in the review of mount-ns data
<zyga> I guess we forgot to act
<mborzecki> pstolowski: do you hav a core18 vm? can you check `findmnt /etc/machine-id` ?
<pstolowski> mborzecki: yep, 1 sec
<zyga> mborzecki: I do
<zyga>  /etc/machine-id /dev/sda3[/system-data/etc/machine-id] ext4   rw,relatime,data=o
<zyga> so that's weird
<zyga> mborzecki: from pi4 /etc/machine-id /dev/mmcblk0p2[/system-data/etc/machine-id] ext4   rw,relatime
<zyga> mystery
<mborzecki> hm it's not listed in writable-paths, what sets it up?
<zyga> maybe that's our test specific setup
<mborzecki> zyga: anything in /etc/fstab or /run/image.fstab?
<pstolowski> zyga: i see  /etc/machine-id /dev/sda3[/system-data/etc/machine-id] ext4 as well
<zyga> what is /run/image.fstab?
<zyga> where are writable paths set up
<zyga> I mean
<zyga> the list
<pstolowski> zyga: and pi3 with core16 is the same as yours
<zyga> I checked pi4 with core18
<zyga> no clue
<mborzecki> zyga: iirc it's from our initrframfs hooks
<mvo> mborzecki: hm, this is all confusing, it looks like /etc/machine-id is not in the writable-path
<mborzecki> zyga: https://github.com/snapcore/core20/blob/master/static/etc/system-image/writable-paths
<zyga> hmm - +0:+0 /system-data/etc/machine-id /etc/machine-id rw,relatime shared:+1 - ext4 /dev/sda3 rw,data=ordered
<zyga> that's from our own test data
<zyga> wat?
<zyga> check this out
<zyga> https://www.irccloud.com/pastebin/0OxSdK9y/
<mvo> mborzecki: so I remember that /var/lib/dbus/machine-id was the persistent place and an /etc/machine-id would make systemd fallback to the /var/lib/dbus/machine-id, maybe that changed? or maybe I misremember?
<zyga> core 20
<zyga> it's good on core16 and core18
<zyga> mount-ns test is a bit like the os-release-zoo
<zyga> anyway
<zyga> brb
<zyga> I'm so cold today
<zyga> need to make that tea for real
<mborzecki> core20 has different initramfs tho?
<mvo> yeah
<mborzecki> so in core build i see this:
<mborzecki> 318:    mount -o bind "${rootmnt}/writable/system-data/etc/machine-id" "${rootmnt}/etc/machine-id"
<mvo> mborzecki: right, I think we need to add the machine-id to the writable-path, I wonder if that will work, i.e. if systemd will be able to commit when it can't write it atomitcally
<mborzecki> but it's not used in core20 world anymore right? it's only ubuntu-core-initramfs now?
<mvo> mborzecki: but the man-page for machine-id talks about bind-mounting it, so *hopefully* that will work
<mvo> mborzecki: I think that's right, sounds like we need to sync with dimitri with it. but maybe it's enough to just add it to the writble-path?
<zyga> back
<zyga> much better :)
<zyga> shall I report this just in case we don't fix it today?
<zyga> I need a 2nd review on https://github.com/snapcore/snapd/pull/8403 to make progress please
<mup> PR #8403: sandbox/cgroup: avoid making arrays we don't use <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8403>
<zyga> I will adjust the comment on the next pass, this is green now
<zyga> mborzecki: simple-session tool improvement https://github.com/snapcore/snapd/pull/8416
<mup> PR #8416: tests/session-tool: reset failed session-tool units <Created by zyga> <https://github.com/snapcore/snapd/pull/8416>
<zyga> this avoids the need to use property only available on future systemd versions
<zyga> and solves accumulation of leftovers
<mup> PR snapd#8416 opened: tests/session-tool: reset failed session-tool units <Created by zyga> <https://github.com/snapcore/snapd/pull/8416>
<xnox> mvo: Ubuntu strategy for machine-id is to be an empty file. Onboot, systemd maintains one in /run and eventually commits it to disk. So, yes it should be writable. And like Core20 snap must have it as an empty file.
<xnox> mvo: bug report please.
<zyga> xnox: on core20?
<xnox>  zyga i don't understand your question. the systemd behaviour has been like that since the dawn of time in the ubuntu timeline.
<zyga> xnox: "do you want me to report a bug on core20"
<xnox> zyga:  yes
<zyga> on it
<zyga> xnox: https://github.com/snapcore/core20/issues/32
<mup> Issue core20#32 opened: The machine-id file should be writable <Created by zyga> <https://github.com/snapcore/core20/issue/32>
<xnox> tah
<zyga> unit tests fail left and right, I guess travis containers are just as busy as launchpad lately
<mvo> xnox: I can give you a PR if you want? or are you already on it?
<xnox> mvo:  no, i'm not on anything. not serving interrupts, but doing things as they were queued up for me.
<mvo> ok
<mup> PR core20#33 opened: writable-path: make /etc/machine-id writable <Created by mvo5> <https://github.com/snapcore/core20/pull/33>
<mborzecki> mvo: let me try to build a core20 snap and see if it works as expected
<mvo> mborzecki: \o/
<mup> PR snapd#8412 closed: httputil: increase httpclient timeout in TestRetryRequestTimeoutHandling <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8412>
<mborzecki> hmm
<mborzecki> /etc/machine-id /dev/mapper/ubuntu-data[/system-data/etc/machine-id] ext4   rw,relatime
<mborzecki> /etc/machine-id tmpfs[/machine-id]                                   tmpfs  ro,size=203112k,mode=755
<mborzecki> why 2 mounts tho?
<zyga> mvo: I opened 7700 for a review
<zyga> mvo: can you please look at what we could do for the upcoming sprint to be in the green
<zyga> mvo: it's a RFC, not a final solution, I could use advise on where to go next
<mborzecki> ok, on the first boot i had 2 mounts, but now after another reboot there's just one
<zyga> oh, wait, I pushed without commiting
<zyga> anyway, it doesn't change much
<zyga> I've restarted the CLA check a few times and it's failing
<zyga> https://travis-ci.org/github/snapcore/snapd/builds/669948734
<mborzecki> yeah, looking good now
<mborzecki> pstolowski: the persistent journal works now too
<pstolowski> mborzecki: good, thanks. fwtw there is another issue with all this that I just described in my PR
<pstolowski> mvo: ^ (sorry, I revoked your review)
<mborzecki> pstolowski: hmm System Journal (/var/log/journal/bbac1383d2c640b3853c9f08d14e4116) is 32.0M, max 294.3M, 262.3M free, iirc he default is 10% of given block device size?
<pstolowski> mborzecki: right, seems to match https://gist.github.com/JPvRiel/b7c185833da32631fa6ce65b40836887
<zyga> I believe reviewing https://github.com/snapcore/snapd/pull/8416 helps, I cannot explain how though
<mup> PR #8416: tests/session-tool: reset failed session-tool units <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8416>
<zyga> apart from having fewer units after this test
<zyga> https://github.com/systemd/systemd/issues/8672 is related
<mvo> zyga: it looks reasonable
<zyga> mvo: what should we do to take next steps?
<mvo> pstolowski: what does that mean, should I review the pr again?
<mvo> zyga: what is needed, can we just open this PR as is? I think samuele had a question in there but otherwise I think I'm ok with this as a first step for the UI
<zyga> mvo: the PR is open, I addressed that question now
<mvo> zyga: cool
<zyga> mvo: ok, I'll pursue this a little more then
<mvo> zyga: has the prereq landed?
<mvo> zyga: if so we could target it for 2.45
<zyga> mvo: close to it, if I can grab jamie for a moment today
<zyga> mvo: I need to merge master after samuele's fixes again
<mvo> nice
<zyga> (the reorg)
<pstolowski> mvo: no, please see the comment
<pstolowski> mvo: we need to agree on what to do
<mvo> pstolowski: I see now, thank you
<mvo> pstolowski: this sounds to me like we want "yes/no/unset" and that maps to "persisent/disabled/auto", does that make sense?
<mvo> (we want this as the possible config options?)
<mvo> auto does not make that much sense on uc20 anymore though because something outside of the confinement would have to create it directly under /writable which is strange
<mvo> otoh it's nice on the other releases :)
<pstolowski> mvo: more less yes, maybe. but I fear this will be confusing. because if you say "unset" and it maps to "auto", that means that if it was "persisent" before it will still log into /var/log/journal (unless we or the user removes the dir).
<mvo> pstolowski: good point
<pstolowski> mvo: maybe we should simply override the default with persistent|none as soon as the option is ever set. but never remove /var/log/journal ?
 * pstolowski lunch
<pedronis> mvo: pstolowski: let's chat later
<mup> PR snapcraft#3010 closed: cli: add progressive releases support to the release command <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3010>
<zyga> mvo: this fixes the cron issue with session-tool https://github.com/snapcore/snapd/pull/8417
<mup> PR #8417: tests/session-tool: kill leaking closing session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8417>
<mup> PR snapd#8417 opened: tests/session-tool: kill leaking closing session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8417>
<zyga> mborzecki: is [ ! -e /proc/$pid ]; a good way to check if a process exists?
<mvo> thanks zyga
<mborzecki> zyga: in shell? hmm why not, kill -0 <pid> probably doesn't work
<mborzecki> kill 0 ofc
<zyga> I've seen this error a lot this week
<zyga> 2020-04-03 12:01:56 Error executing google:ubuntu-core-16-64:tests/core/reboot (apr031118-002068) : kill-timeout reached after apr031118-002068 (google:ubuntu-core-16-64:tests/core/reboot) reboot request
<zyga> reboot test fails
<zyga> I wonder if that's something else impacting or is that something broken for real
<pedronis> zyga: I re-reviewed #8123, not urgent by I left some questions and a remark there
<zyga> looking
<mup> PR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>
<zyga> pedronis: the hostfs change is not required because we reversed course on the ability to create directories that are absent on the host in response to interface connection
<zyga> pedronis: so we will not create /var/lib/dhcp via hostfs
<zyga> so no permissions or related cahnges
<pedronis> ah, makes sense
<zyga> I'll see for the comment in a moment
<zyga> wrapping up some branches and I'd like to break before the call
<zyga> thank you for the review, I think this will land soon :)
 * zyga afk for some time, see you at the standup
<cmatsuoka> cachio: I'm trying to run the encryption test on the nested backend, but got a git archive error, did you see this before?
<cmatsuoka> ijohnson: good morning
<cmatsuoka> ijohnson: I have a question about InitramfsUbuntuDataDir and friends
<cmatsuoka> ijohnson: I see you moved the definitions from dirs to boot, but I need to reference the mountpoints from the target system and not initramfs. They're using the same path but they could potentially be different, so my feeling is that I should define UbuntuDataDir in dirs again
<cmatsuoka> cachio: never mind, it was a local problem
<ijohnson> hey cmatsuoka
<ijohnson> cmatsuoka: for now it's probably fine to just use boot.InitramfsUbuntuDataDir from wherever you need it, even if it's not during the initramfs
<ijohnson> cmatsuoka: we had this same issue with pedronis and mborzecki for the code that reboots into a particular system for the chooser
<ijohnson> cmatsuoka: so the variable may get renamed eventually but for now it's fine to use it
<mborzecki> hm hm?
<cmatsuoka> ijohnson: right, that's how I implemented it so I'll leave it as is for now, thanks
<ijohnson> hey mborzecki
<mborzecki> ah right
<mborzecki> crazy idea, hm maybe we could have automount units for that?
<zyga> mborzecki: for what?
<mborzecki> /run/mnt/ubuntu-{seed,boot,data}
<pedronis> I am a bit missing how that would help?
<mborzecki> pedronis: the mounts wouldn't need to be present all the time, we wouldn't need to call mount if we decide to mount them on deman
<mvo> cmatsuoka: looks like 8103 is super close :) do you think you could  address the remaining comments from maciej and chris? I think then it's ready to land
<pedronis> mborzecki: well we need them during initrams
<pedronis> the question is what happens later
<mborzecki> pedronis: right, but we don't need them all the time later
<pedronis> mborzecki: who would write the units?
<cmatsuoka> mvo: sure, working on that!
<mborzecki> later == after switching the root
<pedronis> there's no main partition after a while
<pedronis> *after a while
<pedronis> for a while
<mborzecki> pedronis: iirc xnox had code that generates mount units for those in ubuntu-core-initramfs
<mvo> cmatsuoka: thanks!
<pedronis> mborzecki: there are issues, if they can come and go, any checks we do on them is problematic
<mborzecki> yeah, that's true as well
<pedronis> anyway at this point is all things to think about after beta
 * zyga breaks to stretch a little
<zyga> back hurts
<roadmr> ouch :(
<pedronis> ijohnson: I'm not sure I understand your comment about the switch
<pedronis> I'm missing something
<ijohnson> uh
<ijohnson> pedronis: how can the caller set something on bsmark? what I did just now is have the caller pass in bsmark to the select function
<ijohnson> here let me show you
<pedronis> ijohnson: we return bsmark
<pedronis> no?
<ijohnson> yes, so how would the caller set properties on bsmark before calling the function ?
<ijohnson> without passing in bsmark to the choose function ?
<ijohnson> pedronis: https://pastebin.ubuntu.com/p/pDTXqbBsc4/
<pedronis> it can set after
<pedronis> the info is not really used inside the function
<pedronis> afaict
<pedronis> it's used in commit later I suppose
<ijohnson> pedronis: the issue that all of this refactor is about is preventing us from loading bootenv multiple times i.e. calling ebl.Kernel() multiple times during a single instance of boot.MarkBootSuccessful
<ijohnson> we only want to call loadBootenv once for boot.MarkBootSuccessful
<pedronis> ijohnson: I understand, but maybe at this point is just easier for me to try what I have mind
<pedronis> and see if it works
<pedronis> I'm failing to explain myself it seems
<ijohnson> yes, sorry I don't understand your suggestion
<pedronis> it's very simple actually
<pedronis> but maybe doesn't work
<pedronis> let me see
<pedronis> ijohnson: it works afaict
<ijohnson> pedronis: can you show your code ?
<pedronis> at least the tests still pass
<pedronis> ijohnson: just this: https://paste.ubuntu.com/p/shzz4xgN3w/
<ijohnson> ah okay sure that works fine
<ijohnson> sorry I didn't understand that your suggestion was to do it after the choose* function
<pedronis> well, I said it on irc, but not in the comment, it's actually the only way to make it work simply
<pedronis> but as I commented the doc comment of the helper needs to clarify that it's possible/makes sense
<ijohnson> yes that's fine
<mup> PR snapd#8368 closed: github: goodbye travis <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8368>
<mup> PR snapd#8418 opened: github: move static checks and spread over <Created by zyga> <https://github.com/snapcore/snapd/pull/8418>
<pedronis> ijohnson: the problem with non managers_test.go  tests is that they don't check the logic triggered by ensureBootOk and the rest of the refresh undo
<pedronis> but maybe you have thoughts about that?
<ijohnson> pedronis: what other logic do we need to check in ensureBootOk ?
<pedronis> ijohnson: we trigger a revert that will do a SetNextBoot , same with the undo
<pedronis> that's where things intersect
<ijohnson> mmm
<ijohnson> this is slightly depressing that we need so many permutations of this kind of test now across 3 different packages :-/
<pedronis> ijohnson: I'm open to think this through just saying that the chain of boot state changes
<pedronis> ends with a SetNextBoot in the undo code
<ijohnson> yes you're right there are more cases like that
<pedronis> in some cases
<pedronis> that's I think why we thought some cases would take care by themselves
<pedronis> btw
<pedronis> this logic on the undo path
<pedronis> of a refresh
<ijohnson> yes
<pedronis> ijohnson: related to that the other important moving part is: snapstate.WaitRestart
<mup> PR core20#33 closed: writable-path: make /etc/machine-id writable <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core20/pull/33>
<ijohnson> mborzecki: I will push up what I have on writing grub.cfg on ubuntu-boot from snapd so you can pick it up on monday if you have time
<ijohnson> pedronis: yes indeed it's unclear where all we are currently covering the calls to boot from WaitRestart
<pedronis> ijohnson: some of the managers_test should reach that
<zyga> degville: [offtopic] did you finish the game?
<ijohnson> pedronis: yes but I don't know if we have enough coverage of it is my point
<mborzecki> ijohnson: going out now, please ping in the review
<ijohnson> mborzecki: ack
<ijohnson> have a nice weekend
<mborzecki> ijohnson: thanks, you too!
<degville> zyga: no, not yet. I've really been taking it slow, and playing it only on difficult, because I know it's not long.
<zyga> degville: I'm very curious what's at the end
<zyga> HL3 confirmed or what :D ?
<zyga> but don't tell me
<zyga> just tell me if it's worth that 1000 _once you know the ending_
<degville> zyga: yeah, I've tried to skip all discussions about it so I don't know either.
<pedronis> ijohnson: it's main API, is GetCurrentBoot so maybe related to looking more at state, what we need is all the state about this boot env state transitions to end up checking what that does return
<degville> [off topic, cont.] I don't think there's any way it can warrant 1000 on its own. Despite being very good, it's an experiment in immersion more than anything. Which I think is the best VR can offer at the moment. But it is seeing City 17 from your own eyes, and totally convincing.
<mup> PR snapd#8416 closed: tests/session-tool: reset failed session-tool units <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8416>
<mup> PR snapd#8419 opened: Add libnvidia-rtcore as Nvidia library <Created by joedborg> <https://github.com/snapcore/snapd/pull/8419>
<pedronis> ijohnson: the main chain  I think is always something like:  SetNextBoot -> bootloader cfg -> initramfs -> MarkBootSuccessful -> GetCurrentBoot (-> undo or revert SetNextBoot)
<pedronis> ijohnson: that should be coverable from boot mostly, with a few managers_test on top to check actual integration
<zyga> brb
<pedronis> ijohnson: so maybe the first step is actually to add checks for GetCurrentBoot results in the significant places in all the TestHappy in boot_test.go
<mup> PR snapd#8420 opened: httputil: increase testRetryStrategy max timelimit to 5s <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8420>
<zyga> re
<mvo> can someone do a second review for 8103 please?
<zyga> mvo: I'm on it
<zyga> mid way
<mvo> zyga: \o/
<mvo> zyga: thank you
<mup> PR snapd#8419 closed: Add libnvidia-rtcore as Nvidia library <Created by joedborg> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8419>
<mup> PR snapd#8329 closed: interfaces: allow raw access to USB printers <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8329>
<mup> PR snapcraft#2987 closed: spread tests: set appropriate default base in snapcraft.yamls <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2987>
<zyga> 7/9 files
<zyga> https://github.com/snapcore/snapd/pull/8103#pullrequestreview-387367998
<mup> PR #8103: snap-bootstrap: store encrypted partition recovery key <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8103>
<zyga> I can +1 if somone will follow up
<zyga> would +1 except for https://github.com/snapcore/snapd/pull/8103#discussion_r403103510
<zyga> mvo: ^
<ijohnson> pedronis: sorry was in meetings
<ijohnson> pedronis: how much of these additional tests do you want in the open PR?
<pedronis> ijohnson: should we have a quick HO?
<ijohnson> pedronis: sure
<ijohnson> SU?
<pedronis> yes
<ijohnson> cool I'm there
<cmatsuoka> zyga: addressing that
<zyga> thanks
<zyga> I can +1 if you do
<cmatsuoka> zyga: test "$(stat --printf='%u %a' /var/lib/snapd/device/fde/recovery-key)" = "0 600"
<zyga> on focal this is my path
<zyga>  /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin:/var/lib/snapd/snap/bin
<zyga> note the duplicate /snap/bin
<zyga> and the non-ubuntu /var/lib/snapd/snap/bin
<zyga> can anyone confirm?
<ijohnson> zyga: I have the same
<zyga> thanks
<zyga> probably one-too-many helpers
<ijohnson> to be clear, I have the duplicated /snap/bin and non-ubuntu /var/lib/snapd/snap/bin too
<zyga> ack
<pedronis> it's the same on bionic fwiw
<zyga> fun
<zyga> we must have done that earlier
<zyga> I'll look on Monday
<zyga> or maybe earlier
<zyga> in our job interviews we should only have one question
<zyga> How do you add one item to PATH
<zyga> that will filter out everyone, including us
<zyga> ;)
<ijohnson> hooray
<zyga> filed it just in case
<zyga> mvo, cmatsuoka: https://github.com/snapcore/snapd/pull/8103#pullrequestreview-387413837
<mup> PR #8103: snap-bootstrap: store encrypted partition recovery key <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8103>
<cmatsuoka> zyga: fixed as suggested, thanks
<zyga> https://github.com/snapcore/snapd/pull/8418/checks#step:8:9
<mup> PR #8418: github: move static checks and spread over <Created by zyga> <https://github.com/snapcore/snapd/pull/8418>
<zyga> govendor cannot build on go from xenial?
<zyga> mvo: do you remember why we depend on 1.9 and not 1.10?
<mvo> zyga: centos 7 iirc
<zyga> I see
<zyga> oh well
<zyga> I'll do something
<zyga> I solved the silly go in azure
<zyga> they pre populate GIGs of software into the image
<mvo> zyga: if we run a spread unittest task everywhere I think we are also good
<zyga> including go 1.11+
<zyga> I think we don't but I'll check
<mvo> zyga, cmatsuoka thanks for working on 8103, looks like it's ready to go once tests have run
<mvo> zyga: thanks!
<zyga> heh
<zyga> xenial cannot run our static checks
<zyga> it's like moving in a maze
<zyga> without lights
<zyga> and knowing there are turds everywhere
<mvo> zyga: xenial cannot run our static checks? why not?
<zyga> https://github.com/snapcore/snapd/pull/8418/checks#step:10:18
<mup> PR #8418: github: move static checks and spread over <Created by zyga> <https://github.com/snapcore/snapd/pull/8418>
<zyga> because shellcheck in xenial is too old
<zyga> we never noticed
<mvo> zyga: woah, interessting
<mvo> zyga: and sad
<mvo> zyga: I thought travis would run those in xenial too - apparently not
<zyga> everyone does custom shit
<zyga> at least
<zyga> and I really have to give them credit
<zyga> github has excellent docs on what they do
<zyga> and what's custom
 * mvo nods
<zyga> I wonder...
<zyga> (insert harry potter mystery music)
<zyga> mvo: check out https://github.com/snapcore/snapd/pull/8418/checks
<mup> PR #8418: github: move static checks and spread over <Created by zyga> <https://github.com/snapcore/snapd/pull/8418>
<zyga> wow :)
<mup> PR snapcraft#3011 opened: repo: introduce install_source() and install_gpg_key() to Ubuntu <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3011>
<zyga> mvo: snapd work in azure
<mvo> zyga: nice
<zyga> *snaps
<mvo> zyga: looking
<zyga> so shellcheck snap
<mvo> zyga: yay
<ijohnson> zyga: is it still a problem where "/" is owned by the vsts user or something
<zyga> ?
<zyga> vsts?
<zyga> test
<zyga> yes
<zyga> snap-confine will refuse to work
<ijohnson> :-(
<ijohnson> but I found someone to talk to about that on MS side
<zyga> can I help?
<ijohnson> I can CC you on my email
<ijohnson> the problem before was that we couldn't find anyone to talk to about who manages this on the github/microsoft side
<mvo> zyga: fun (not!) - the travis run for 8103 has not even started yet
<zyga> heh
<pedronis> I pushed a comment there,  might need formatting in a follow up
<zyga> it seems master is broken
<zyga> https://api.travis-ci.org/v3/job/670608294/log.txt
<zyga>     - google:ubuntu-core-20-64:tests/core/writablepaths
<pedronis> https://github.com/snapcore/snapd/pull/8103/files#diff-13724d8f1f88168c790f24aafb4d2d13R137
<mup> PR #8103: snap-bootstrap: store encrypted partition recovery key <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8103>
<zyga> https://www.irccloud.com/pastebin/5FyicYVN/
<mup> PR snapd#8421 opened: tests: enable unit tests on debian-sid again <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8421>
<zyga> cachio: could you please review https://github.com/snapcore/snapd/pull/8418
<mup> PR #8418: github: move static checks and spread over <Created by zyga> <https://github.com/snapcore/snapd/pull/8418>
<cachio> zyga, sure
<zyga> thanks!
<zyga> this will unlock more chance to improve things
<zyga> accelerate team-wide feedback
<zyga> and get rid of the 50 minute limit
<cachio> zyga, where are these going to run?
<cachio> your box?
<zyga> no
<zyga> those run in azure
<zyga> in the normal gh runners
<cachio> ahh
<zyga> btw, mvo: I got 16GB of ram into my box so we could easily run those 32 runners for extra overflow capacity
<zyga> there's some cruft to shed
<zyga> mainly to make it faster
<zyga> but that's all _after_ this one
<mup> PR snapcraft#3012 opened: plugins: install required apt sources and keys to system <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3012>
<cachio> zyga, left you some questions in the PR
<cachio> and closed it by mistake
<cachio> then I reopened it
<zyga> cachio: :D
<zyga> cachio: I replied
<zyga> cachio: remember that this is a long term game:
<zyga> cachio: we get instant responsiveness
<zyga> cachio: we get faster end-to-end
<zyga> cachio: we get lower costs
<zyga> cachio: if we cut rebuilds this is even faster
<zyga> cachio: essentially boot into a system and start away
<cachio> I think it is ok with this new workflow and if someone complains in the future we can revert to the run all the systems+ in parallel
<zyga> yeah
<zyga> I think this will be faster than old workflow already
<cachio> the good part is that if some system fails, we just restart this one
<zyga> we...
<zyga> not yet
<zyga> github has this but it's not released yet
<cachio> ahh
<cachio> well in the future well save that money too
<cachio> +1
<zyga> thanks!
<zyga> let's improve it together
<cachio> so far it worked very well
<cachio> that's really possitive
<mup> PR snapd#8422 opened: tests: skip "/etc/machine-id" in "writablepaths" test <Simple ð> <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8422>
<mvo> zyga: ^- this will unbreak master
<zyga> ta
<zyga> looking
<mup> PR snapd#8417 closed: tests/session-tool: kill leaking closing session <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8417>
<zyga> hmm
<zyga> core20 tests
<zyga> when do we run them
<zyga> in first boot?
<ijohnson> zyga: we run core20 tests during run mode after we reboot
<zyga> mvo: ^
<zyga> is this consistent with your patch?
<ijohnson> zyga: yes "first boot" for uc20 -> first boot run mode
<zyga> ahhh
<ijohnson> there's also install mode, which is technically the "first" boot, but we don't call it that
<ijohnson> install mode boot is more like the zeroth boot
<mvo> zyga: yes
<mvo> zyga: it's what maciej also saw, next reboot is fine for strange reasons
<mvo> zyga: I think it happens when the /etc/machine-id is empty, then systemd gets confused somehow
<zyga> systemd does have a first boot concept
<zyga> not confuse
<zyga> it's just a mode we never see in ubuntu
<zyga> it's been normally used in fedora for a while IIRC
<mvo> zyga: right, sorry, my wording was too strong
<zyga> well
<zyga> until now :)
<zyga> https://www.freedesktop.org/software/systemd/man/systemd-firstboot.html
<mvo> zyga: for 8418 I think we should try to also run go-latest unit tests in a GH runner and then remove the unit tests from travis entirely. but that is followup material it seems
<zyga> go-latest? snap?
<mvo> zyga: yes
<mvo> zyga: sorry for being cryptic
<zyga> sure thing
<zyga> please don't apologize for anything :)
<mvo> zyga: sorry
<zyga> haha :)
<mvo> :P
<mvo> couldn't resist :)
<zyga> After the machine ID is established, systemd(1) will attempt to save it to /etc/machine-id. If this fails, it will attempt to bind-mount a temporary file over /etc/machine-id. It is an error if the file system is read-only and does not contain a (possibly empty) /etc/machine-id file.
<zyga> systemd-machine-id-commit.service(8) will attempt to write the machine ID to the file system if /etc/machine-id or /etc are read-only during early boot but become writable later on.
<mvo> zyga: yeah, I think systemd is still a bit confused because it should be possible to save /etc/machine-id (unless it tries a save-and-atmoic-move
<zyga> it may try too early perhaps?
<zyga> I don't know
<mvo> zyga: it still procceeds to the bind-mount step it seems
<mvo> zyga: yeah, it's not clear from the docs, I am too lazy to look at the source
 * mvo should probably do that still :(
<zyga> maye not today
<zyga> I think it's okay to EOD at 9PM on Friday
<mvo> maybe, I still want a) master green b) recovery-key PR on master c) GH actions on master d) icecream!
<zyga> mvo: e) pony
<zyga> or pony ice cream, as you wish
<mvo> zyga: nay, I'm vegetarian
<zyga> it's like eating a very large lump of grass anyway
<mvo> zyga: hahaha
<zyga> I think gnome software is leaking
<zyga> it's using more memory than FF does
<zyga> the background service I don't even see
<mup> PR snapcraft#3011 closed: repo: introduce install_source() and install_gpg_key() to Ubuntu <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3011>
<mvo> zyga: I think travis defeated me for today, still no test run finished of my list of things I want so I will check back in my morning. have a good weekend
 * mvo waves
<zyga> o/
<mup> PR snapd#8420 closed: httputil: increase testRetryStrategy max timelimit to 5s <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8420>
<mup> PR snapd#8103 closed: snap-bootstrap: store encrypted partition recovery key <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8103>
<King_InuYasha> kyrofa: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/XNKHAJAKFEJKMO46HJBSHPGMSUQLCWU5/
<kyrofa> King_InuYasha, yeah I saw it. That's what I get for waiting to respond I suppose
<kyrofa> I actually resolved the needinfo ping before he sent that email, as you can see from the activity log he provided in the email :P
<kyrofa> King_InuYasha, I wasn't going to respond to the email though, unless I should
<King_InuYasha> kyrofa: you probably should, just be cordial and explain what's going on ;)
<kyrofa> So I need to respond in multiple places? Not the most efficient of processes
<King_InuYasha> kyrofa: nah, just respond in the main email and close out the bugs accordingly
<King_InuYasha> the main email is to let the rest of the community know you're alive :)
<mup> PR snapd#8423 opened: tests: uc20 nested suite part II <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8423>
<mup> PR snapd#8422 closed: tests: skip "/etc/machine-id" in "writablepaths" test <Simple ð> <â  Critical> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8422>
<mup> PR snapd#8424 opened: cmd/snap-bootstrap/initramfs-mounts: cross-check partitions when mounting <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8424>
#snappy 2020-04-04
<mup> PR snapcraft#3012 closed: plugins: install required apt sources and keys to system <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3012>
<mup> PR snapd#8418 closed: github: move static checks and spread over <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8418>
<zyga> jdstrand: thank you :)
<mup> PR snapd#8425 opened: github: disable fail-fast as spread cannot be interrupted <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8425>
<mup> Issue core20#34 opened: please provide dbus-launch <Created by zyga> <https://github.com/snapcore/core20/issue/34>
#snappy 2020-04-05
<mup> PR pc-amd64-gadget#40 opened: gadget.yaml: reduce data partition size to 1G <Created by cmatsuoka> <https://github.com/snapcore/pc-amd64-gadget/pull/40>
<mup> PR snapd#8426 opened: interfaces/docker-support: add overlayfs file access <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8426>
<mup> PR snapd#8427 opened: store: start splitting store.go and store_test.go into subtopic files <Created by pedronis> <https://github.com/snapcore/snapd/pull/8427>
<thresh> hello
<thresh> so I've moved VLC snap generation and upload to gitlab instead of jenkins we used before, and now it seems "releasing" fails (?), but push succeeds: https://code.videolan.org/videolan/vlc/-/jobs/377870#L1029
<thresh> I can see that exact version is available to be released via the Snap Store developer web UI, and I can manually release to edge there;  I wonder how can I debug why it's not happening in the CI?
<mup> PR snapd#8428 opened: tests/session-tool: stop cron/anacron from meddling <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8428>
<mup> PR snapd#8425 closed: github: disable fail-fast as spread cannot be interrupted <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8425>
<mup> PR snapcraft#3013 opened: plugins: use v1 import path for all plugins <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3013>
