#snappy 2015-11-16
<fgimenez> good morning
<mvo> hey fgimenez, good morning
<fgimenez> hi mvo :)
<dholbach> good morning
<mvo> hey dholbach, good morning
<dholbach> hey mvo
<davidcalle> Good morning
<JamesTait> Good morning all; happy Monday, and happy Button Day! ð
<dholbach> mvo, from which ppa would I get the most up-to-date ubuntu-snappy-cli for devel and 15.04 respectively?
<mvo> dholbach: generally ppa:snappy-dev/tools is a good one, what do you need it for? we also have daily build ppas
<sergiusens> ogra_, dholbach how do I update https://developer.ubuntu.com/en/snappy/guides/porting/ ?
<ogra_> sergiusens, didnt someone give you write access to that ?
<davidcalle> sergiusens, login with http://developer.ubuntu.com/openid/login
<sergiusens> ogra_, yes, but not sure if there is a markdown source synced from it
<davidcalle> sergiusens, ah, no md source
<sergiusens> davidcalle, grat, I'll take the bullet tonight, wasn't easy to edit from the web for me :-P
<dholbach> mvo, the question came up if we could automatically import a snappy manpage (I found out that 'snappy man' creates one)
<davidcalle> sergiusens, if you struggle with the editor, ping me or dholbach anytime :)
<sergiusens> I'll ping mhall as you guys might be sleeping when I decide to edit this ;-)
<dholbach> mvo, maybe during the build one could be generated? :)
<sergiusens> dholbach, if you can, Chipaca and myself failed to hook it up correclty in debian/rules
<dholbach> sergiusens, ok, I'll take a look
<davidcalle> sergiusens, naah, I'll just give you dholbach phone number, he is awake all night! :p
<Chipaca> um
<Chipaca> sergiusens: I have "man snappy"
<Chipaca> sergiusens: from debian/rules
<sergiusens> davidcalle, oh, I have him on telegram, I can wake him up :-P
<sergiusens> Chipaca, oh, then it was already done and I forgot
<Chipaca> sergiusens: don't you?
<Chipaca> $ dpkg -S snappy.1
<Chipaca> ubuntu-snappy-cli: /usr/share/man/man1/snappy.1.gz
<sergiusens> Chipaca, yes
<dholbach> Chipaca, you're right, thanks O:-)
<Chipaca> sergiusens: i did this when i added 'snappy man' :)
<sergiusens> let me rephrase, **I had a hard time** and then you created a working branch ;-)
<sergiusens> dholbach, there is no man in ubuntu core though
<dholbach> sergiusens, no worries - this would be for importing into the dev site
<Chipaca> dholbach: note the manpage also lists internal commands, as it's a zero-effort automatic thing generated from the thing that does commandline parsing
<dholbach> Chipaca, that's good to know
<Chipaca> dholbach: ideally those internal ones would be pruned (but upstream isn't amenable to patches)
<dholbach> mvo, the last ubuntu-snappy-cli uploads to that ppa are from july
<mvo> Chipaca: for some unexplained reason that has changed recently and the patch to hide stuff is in. at the same time the drop-priv stuff will soon vanish
<Chipaca> mvo: seriously? woo! we should merge that in
<mvo> dholbach: hm, then you will need the daily one from ppa:snappy-dev/image
<mvo> Chipaca: yeah, no explanation just the github message "merged #XY"
<dholbach> mvo, great - thanks
<Chipaca> mvo: there's 5 internal commands, not just drop-priv. And some more that could probably do with being reclassified as internal.
<Chipaca> mvo: e.g. booted is internal, but firstboot isn't?
<Chipaca> ah, wait, first_boot is
 * Chipaca learns to read
<ogra_> hmpf
<ogra_> sergiusens, Chipaca, do we have some kind of "inetd plugin"  in snapcraft ? i wonder how to snap up a service that relies on it
<Chipaca> ogra_: we do not
<ogra_> ah sad
<Chipaca> ogra_: we'd have to expose one more service flag for that
<Chipaca> which is totally doable, but needs doing :-)
<ogra_> well, not sure if thats very common
<ogra_> (people packaging inetd depending services)
<Chipaca> ogra_: OTOH, all you need to turn an inetd plugin into a regular service is netcat
<ogra_> yeash
<ogra_> thats my fallback idea
 * Chipaca oversimplifying complex engineering problems since 1976
<ogra_> i'm just wondering if it is a common task ... in which case a snapcraft option would make sense
<Chipaca> ogra_: file a bug, see how many people me-too it?
<ogra_> yeah, will do
<Chipaca> ogra_: don't forget to say Â«don't comment with âme tooâÂ», so people comment with âme tooâ
<ogra_> +1
<ogra_> :D
<ogra_> geez
<ogra_> so i tried to snap up approx (which caused the above question) ... and just noticed the resulting snap is 74MB !!
<ogra_> thats half an OS !
<ogra_> (or even a full one)
<sergiusens> ogra_, build it from source!
<ogra_> heh
<ogra_> crazy talk !
<Chipaca> ogra_: https://gist.github.com/chipaca/58552b58a1a75cd1607b
 * Chipaca hugs rsalveti 
<ogra_> Chipaca, dude ! why is that not snapped !
<Chipaca> ogra_: because i'd need to change it for small memory systems
<Chipaca> ogra_: or clean it up
<Chipaca> ogra_: maybe even merge in whatever's gone on with TinyHTTPProxy in the 3+ years since I did this to it
 * rsalveti hugs Chipaca
<rtg> lool, hey, can you have a look at git://kernel.ubuntu.com/rtg/kernel-snap.git and tell me why my snapcraft.yaml doesn't copy files into the snap from staging ?
<ogra_> rtg, did you find a way to generate the initrd yet ?
<rtg> ogra: I ruthlessly butchered rootstock to do so
<ogra_> lol
<ogra_> you should really take the livecd-rootfs snippet for that :)
<ogra_> rootstock adds a massive overhead
<rtg> ogra_, the first thing I did was to only go one level deep. I didn't need to do nested qemu. hence the major surgery, but I did extract the concepts I needed.
<ogra_> well, you need the nested qemu chroot if you are actually buildin for another arch
<ogra_> but only then
<ogra_> beyond that a simple "debootstrap --variant=minbase" should be fine
<rtg> for now I'm just trying to get amd64 working
<ogra_> debootstrap --variant=minbase + PPA setups for the different special kernels + the snappy specific packages needed in the initrd
<ogra_> that should be all you need
<ogra_> then just install your meta and pull out the files from the tree you need
<rtg> ogra_, what snappy specific packages do I need in the initrd ?
<ogra_> initramfs-tools-ubuntu-core at least ... i have to chekc livecd-rootfs
<rtg> ogra_, that sounds familiar
<ogra_> (there are a few more)
<sergiusens> rtg, how about building the kernel instead of using the deb?
<sergiusens> for people building alternate trees
<rtg> sergiusens, that is the next example I'm gonna work on
<sergiusens> great
<sergiusens> rtg, after we have this I guess I'll start using your stuff to create a proper plugin that wraps all this in
<rtg> sergiusens, I thought I'd do a snap for each reference kernel, plus one as an example for building from source
<lool> rtg: you need to make install to DESTDIR
<rtg> lool, in the Makefile plugin ?
<lool> rtg: in the Makefile itself, yup
<lool> rtg: snapcraft sets DESTDIR to the right di
<lool> dir
<rtg> lool, cool, now I see that in the examoples
<fgimenez> elopio_, the jenkins instance is ready to go, you have access to the canonistack dashboard as the ues-snappy-integration-tests user, right?
<elopio_> fgimenez: yes.
<mvo> fgimenez: is it possible to run the new integration test machinery against the branch https://github.com/mvo5/snappy/tree/feature/native-security-policygen-regen ? or is that not possilbe (yet?)
<fgimenez> elopio, ok, it's created for that user, there's also a floating ip assigned to it, the webhook should point to it
<fgimenez> elopio, sure, the -src flag is the branch and the new repo flag the repo location, like https://github.com/user/snappy
<fgimenez> elopio, in that case -src native-security-policygen-regen -repo https://github.com/mvo5/snappy
<fgimenez> mvo, ^ :)
<elopio> mvo: ^
<elopio> mvo, fgimenez, but we can't yet generate an image with taking the snappy deb from the branch, right? We can just overwrite the snappy binary for now.
<fgimenez> elopio, yes, snappy and snapd binaries
<mvo> elopio: that should be ok, I'm curious if the integration test shows any regressions. if its a lot of work for you I can just merge and see the results from the normal integration test run. this needs to go in, but of course the less disruption the better :)
<fgimenez> mvo, whenever you make a PR or add commits to an existing one the job is triggered anyway, once the webhook is in place
<mvo> fgimenez: ok, is it worth waiting for the webhook, i.e. is this happening really soon? no problem if not, I'm ponering if I merge now or wait a little bit, but I'm more on the merge-now side currently
<fgimenez> mvo you can set it up right now :) this is the url http://162.213.34.171:8081/ghprbhook/, the events ticked should be "Pull request" and "Issue comment"
<fgimenez> mvo, it is in the "Settings -> Webhooks & services" section of the repo
<mvo> fgimenez: aha, nice. let me try that
<fgimenez> mvo, the jenkins instance is at http://162.213.34.171:8080, only accessible from the vpn
<elopio> fgimenez: I'm not sure where I got the idea that uboot was not changing snappy_ab on update. Maybe it was a bug, or maybe it came from the voices in my head.
<fgimenez> elopio, :) iirc i've seen it not being changed, anyway now the code is a lot cleaner
<ogra_> rtg, http://paste.ubuntu.com/13299329/ try turning that snippet into a script and you should get something that is identical to the device tarballs that livecd-rootfs creates today ... without all the rootstock overhead
<ogra_> (there are some live-build specifics in there you need to replace but thats minor)
<rtg> ogra_, I thought the goal was to build a snap, not a device tarball
<ogra_> rtg, you want the same contents in both
<ogra_> they should be absolutely identical except that one is a squashfs img and the other is a tarball
<rtg> ogra_, even the YAML file ?
<ogra_> thats something mvo needs to answer ... :)
<ogra_> you definitely want the same initrd and you want the right PPA used for the right suabarch
<ogra_> and afaik mvo used the existing device tarballs during the all snaps development as input
<rtg> ok. I am close to being able to build the snap. I have some permissions issues. then I'll look at this.
<asac> would personally be awesome if we could make the kernel plugin capable of cross compiling
<asac> rtg: ogra_ sergiusens: ^
<asac> just as input
<rtg> asac, when built from source it certainly will be.
<sergiusens> asac, I'm fine with per plugin x-compile
<ogra_> asac, trivial ...
<ogra_> (but needs qemu-user-static for the initrd chroot ... that will limit us)
<asac> rtg: are we doing the "built from debs in archive" variant first?
<asac> guess yeah, then its later
<rtg> asac, yup, that is what I'm working on
<asac> sergiusens: isnt x- something we used for something else?
<ogra_> asac, rtg, the initrd generation will always have to be deb based FWIW
<ogra_> we dont have a way to "just generate" one without that
<rtg> ogra_, fortunately the kernel makefile has a deb target
<asac> i thoguht we do generic initrd that is in the OS
<asac> so we dont need that in kernel
<ogra_> we *could* do the same we do for touch and actually geneare the initrd inside a package build ... but then you need to be sure to never need modules for booting
<asac> mvo: ?
<sergiusens> asac, x as in cross
<sergiusens> not sure what else you speak of ;-)
<mvo> asac: sorry in a meeting
<asac> sergiusens: yeah, thought we used x- for another implicit meaning... like local plugins, but think we moved away from that
<asac> all fine
<ogra_> asac, we cant ... specifically with the new requirement for squashfs
<ogra_> you need the modules
<asac> ogra_: i think its the spec to have initd in OS snap
<sergiusens> asac, we have that still (x for extension)
<asac> and just say kernel folks have to built in what they need
<ogra_> thats not possible
<ogra_> you need to find the rootfs from the initrd
<asac> well, it technically would get copied
<ogra_> which means you need to support the disk type, controller, filesystem
<asac> to the boot paertition from the OS
<asac> but the one and only initrd is in the OS snap ... so we dont need to build it turning kernel buil;d
<ogra_> asac, that still wont have the right contents
<asac> thats how i understand at least one of the proopsals
<ogra_> you need the kernel modules inside the initrd
<asac> ogra_: we can say you cant put them there\
<asac> like what you suggested for long time :)
<ogra_> then you cant boot
<mvo> asac: generic initrd is on the roadmap *but* right now we need the squashfs and nls modules (iso8859) so we can't have a module-less iniitrd
<sergiusens> ogra_, asac rtg can't we make initrd mount the modules from the kernel?
<ogra_> asac,  if we can have it module less, we can do the same as for touch
<ogra_> sergiusens, you still need to find them
<asac> so you need modules only in the initd if you need them to mount the rootfs afaik
<asac> so thats disk drivers, filesystem types etc.
<ogra_> sergiusens, so all needed modules for that need to be there
<ogra_> asac, right
<rtg> sergiusens, yeah, what ogra_ said
<asac> once you have rootfs (or a partition that hosts the modules) you can go and load modules
<sergiusens> ogra_, then it is a no brainer to just include it in the kernel
<ogra_> asac, network cards for things like remote keys for encrypted rootfs
<asac> hmm
<sergiusens> it is not really a generic kernel, is it?
<asac> well, so there is still stuff that is rather a configuration etc.
<ogra_> sergiusens, if we actually want saushfs inside all kernels, sure ;)
<ogra_> sergiusens, it is -generic
<ogra_> thats the prob :)
<asac> dont think the factory keys would go into the initrd ... at least i never anticipated that
<sergiusens> ogra_, it always going to be loaded for core
<ogra_> asac, no, the keys live on a remote server
<ogra_> asac, but you need to obtain them via network
<ogra_> at least in one specific arch we support today
<ogra_> sergiusens, from where ?
<sergiusens> ogra_, from the kernel itself
<ogra_> note that i would love nothing more than to use the same setup we have for the touch initrd in core
<ogra_> but as long as we hard depend on modules we cant
<rtg> sergiusens, how do you inspect a snap ? seems like there was a dpkg option that I read about somewhere
<ogra_> rtg, dpkg-deb -x /part/to.snap
<ogra_> that will unpack it
<sergiusens> rtg, -c should work to just list
<ogra_> or that :P
<rtg> alrighty, looks like my snap has stuff in it. would y'all care to clone git://kernel.ubuntu.com/rtg/kernel-snap.git and tell me if I'm on crack ?
<ogra_> rtg, you definitely want the snappy-image ppa in your chroot ...
<ogra_> that often contains a newer initramfs-tools-ubuntu-core
<ogra_> beyond that the rootstock bit looks good
<ogra_> err
<rtg> ogra_, do you intend to use the PPA for production as well ?
<ogra_> rtg, why $BOOTLOADER ?
<ogra_> the bootloader has to go into the oem (or in the future "gadget") snap
<ogra_> rtg, yes
<rtg> ograthe bootloader only has an impact when installing the kernel in the chroot. it is otherwise unsued
<ogra_> the PPA is used during distro freezes etc
<ogra_> rtg, we dont use any of the distro setup for bootloaders anyway
<rtg> ogra_, ok, I'll get that PPA logic added.
<ogra_> (no update-grub in grub setups, no flash-kernel for uboot)
<ogra_> in fact you would break stuff using them
<ogra_> the rootfs should have all you need bootloader wise (binaries) ... the oem/gadget snap should have all confguration for bootloader setups
<rtg> ogra_, but there is no grub logic in the kernel snap, right ?
<ogra_> right
<ogra_> neither grub binaries nor config
<rtg> ogra_, so run snapcraft on this project and inspect the snap. I think it is right
<rtg> aside from needing the PPA
<ogra_> rtg, oh, and you want linux-image-signed on all amd64 installs
<rtg> ogra_, easy enough
<ogra_> and preferably even a higher meta
<ogra_> like linux-signed
<rtg> what do you need the headers for in the chroot ?
<ogra_> so you get linux-firmware ... and where wanted linux-image-extra installed
<ogra_> you dont need the headers ... but then you simply dont copy them before the squashing
<rtg> ogra_, I'll check, but I think those meta package pull in the right bits
<ogra_> but you need firmware
<rtg> ogra_, I think the kernel depends on linux-firmware
<ogra_> ok
<ogra_> on -extra too ?
<rtg> ogra_, yup
<rtg> ogra_, I think what we want installed is linux-signed-image-generic.
<ogra_> then it should indeed be fine
<ogra_> yeah
<rtg> ogra_, this PPA ? ppa:snappy-dev/image
<ogra_> rtg, yeah
<rtg> sergiusens, ogra_: I've got a kernel snap which appears to install OK in a KVM, but I can't figure out where all the /lib or /boot bits have gone, nor does the new kernel get booted. Any thoughts ?
<ogra_> rtg, well, it needs to land in /boot/grub/a|b somehow currently ... not sure if it still needs to in the all snaps case
<ogra_> mvo_ is your man here
<rtg> ogra_, is there a way to specify which a|b ?
<ogra_> the one thats not in use usually
<rtg> that is what I thought. perhaps I'll dump my troubles on the snappy mailing list
<ogra_> but all that stuff has completely changed in all-snaps so i cant tell if it is still the case for such a setup
<sergiusens> rtg, the only person who really knows the details here is mvo_
<rtg> sergiusens,  any idea how you force an a|b switch ?
<sergiusens> rtg, an install should make the switch, it is all managed by grub, so grubenv away (look at grub.cfg for the exact vars) or just edit grub.cfg
<rtg> hmm, hacking grubenv was fatal
<mkarliner> newbie question. I've made a snap on AMD64 , how do I create a version for  RPi?
<tedg> mkarliner: Probably easiest way is to just build it on the RPi itself.
<mkarliner> But all the instructions are for using snapcraft
<mkarliner> That is, all the 'create a snap' tutorials start with apt-get install etc, etc.
<tedg> mkarliner: Yes, you probably want to setup snapcraft in an LXD or Docker container and then run it.
<tedg> mkarliner: We do realize this is non-ideal right now, working on better solutions.
<mkarliner> I've done that, what I'm trying to understand is how to make the cross platform target, or is there a native way
<tedg> No, we don't really have a way to cross-compile
<mkarliner> OK, so is there a tutorial on how to create a snap on a RpI?
<tedg> There's one in progress, but I don't think it is completed yet.
<mkarliner> Can you give me any clues?
<dwaite> is it possible to grab (or self-build) a newer release of docker on snappy?
<dwaite> unlike apt, it doesn't seem I can just add an external source to get this, and I don't see anything in the tools to enable me to build a framework, just apps
<dwaite> is this a limitation of snappy?
<tedg> mkarliner: You need to install lxd or docker on your RPi and then you can build with snapcraft. That's the tutorial in a nutshell.
<mkarliner> Thanks, I'll give it a go
<tedg> dwaite: I think they're all built by hand right now. Generally, most things don't need to be frameworks though.
<serg_> Hi
<serg_> how can i try my snappy app before deploying into ubuntu store?
<kyrofa> serg_, you've created the .snap?
<serg_> yes
<kyrofa> serg_, do you actually have Ubuntu Core installed anywhere? On a device or a VM?
<serg_> virtualbox
<kyrofa> serg_, just sideload it there
<serg_> sorry, can you explain it step-by-step?
<kyrofa> serg_, sure! First, get your .snap into the VM
<kyrofa> serg_, then you can install it with `snappy install <my_snap>.snap`
<dwaite> Snappy looks interesting, but limiting the infrastructure I can actually use to older "supported" versions just won't work for my environment. I need the new networking features in recent docker releases.
<kyrofa> serg_, assuming you have SSH access to the VM, just use scp to get the .snap on there
<dwaite> the autopilot updates are really nice, but not if it limits what I can actually run
<serg_> thank you, but now i have other problem
<serg_> No signature, or no origin signature
<serg_> which is this?
<serg_> how can i bypass this verification?
<rtg> serg_, sudo snappy install --allow-unauthenticated
<serg_> too much thanks
<rtg> sergiusens, so where do I find a 16.04 KVM image ?
<sergiusens> rtg, mvo has one in his people.c.c, let me see.
<sergiusens> rtg, http://people.canonical.com/~mvo/all-snaps/
<sergiusens> rtg, there's a u-d-f there that should work too
<rtg> sergiusens, hmm, that image isn't exactly network capable AFAICT
<sergiusens> rtg, I am not sure, haven't tested it
<sergiusens> rtg, you can try and u-d-f with what is there and using your snap
<rtg> sergiusens, well, I'll have to get back to it tomorrow. I'm EOD
#snappy 2015-11-17
<dholbach> good morning
<mvo_> hey dholbach, gooooood monring
<dholbach> hey hey :)
<fgimenez> good morning
<zyga> hey :)
<mvo_> hey fgimenez, good morning
<mvo_> and hey zyga
<mvo_> fgimenez: any luck with my integration test :) ?
<fgimenez> hi mvo_ :) the job didn't get triggered, i'll try to dig into it right now
<mvo_> fgimenez: ok, let me know if I can help in any way, happy to re-trigger it
<fgimenez> mvo_, great thanks, i'll reconfigure it to listen to the repo on which i've been doing the development, where things work well, and try to figure out what are the differences, i've just checked the logs from the last payloads received from github and all seems to be ok
<fgimenez> mvo_, the jobs are properly triggered from https://github.com/fgimenez/snappy-github-plugin, both on pull request and comments on them, see http://162.213.34.171:8080/job/github-snappy-integration-tests-cloud/2/console
<fgimenez> mvo_, the first error in the log is because there's no bot user configured (the status in the PR won't be updated), but the job is triggered properly
<fgimenez> mvo_, it's the same jenkins instance that failed with ubuntu-core/snappy, just modified the job to point to fgimenez/snappy-github-plugin, maybe some config is different in the github side
<fgimenez> mvo_, this is how the webhook config looks like in the test repo http://postimg.org/image/486b11ewj/
<mvo_> fgimenez: aha, mine was set to json instead of urlencoded
<mvo> fgimenez: I changed to urlencoded and triggered the event again, anything interessting in the logs?
<fgimenez> mvo_, mmm nope still http://paste.ubuntu.com/13310045/
<fgimenez> mvo if you are redelivery maybe the payload is the same as before, i think that the urlencoded is the correct format, we can wait for a new PR
<fgimenez> mvo, btw, the jenkins instance project is at https://github.com/ubuntu-core/snappy-jenkins, the readme has info about how it is configured
<mvo> fgimenez: ok, I pushed a new branch
<mvo> fgimenez: anything in the logs or same message?
<fgimenez> mvo, still the same... what are the headers of the last event?
<fgimenez> mvo, when it works they look like http://paste.ubuntu.com/13310136/
<mvo> fgimenez: its funny, the heade says content-type: application/x-www-form-urlencoded
<mvo> fgimenez: but the payload looks like its still json for some reason
<mvo> fgimenez:
<mvo> 2015-11-17 09:53:26
<mvo>  looks valid
<mvo> fgimenez: hm, recreated it, still no luck. I get a 200 response though
<fgimenez> mvo, yes, with urlencoded content-type the payload can have any string, json also, it's like if you paste that json in a textarea and submit the form, if the server is aware of it then it can be decoded
<fgimenez> mvo, ok, i'll try to reproduce it with the test repo, first i'll get the full logs from jenkins to see whats really going on
<fgimenez> mvo, could you please paste the header and payload of the latest event? i've seen here https://github.com/janinko/ghprb/blob/master/src/main/java/org/jenkinsci/plugins/ghprb/GhprbRootAction.java#L137 that the message from jenkins comes from an unrecognized event
<mvo> fgimenez: I send you a /msg with the details
<ara> zyga, I like very much how you are explaining every step of the way to implement capabilities in the mailing list
<ara> *kuds*
<ara> *kudos*, even
<zyga> ara: hey
<zyga> ara: :D
<zyga> ara: thank you, :-)
<mvo> fgimenez: thanks so much for your help, now that I configured it right it works like a charm
<fgimenez> mvo, np :) thank you
<JamesTait> Good morning all; happy Tuesday, and happy Home-Made Bread Day! ð
<mvo> fgimenez: how long do the tests usually run?
<mvo> fgimenez: the github-snappy-integration-tests-cloud jobs I mean
<fgimenez> mvo, yes, it depends on the cloud load and the network response for updates, an usual run can take about 25min, sometimes longer (up to 1h) or shorter (16 min or so)
<mvo> fgimenez: thanks
<soffokl> Hey, I trying to disable snappy-autopilot.timer, but after reboot it active again. Is there any way to disable it permanently?
<soffokl> (amd64)ubuntu@localhost:~$ sudo systemctl disable snappy-autopilot.timer
<soffokl> Removed symlink /etc/systemd/system/multi-user.target.wants/snappy-autopilot.timer.
<soffokl> (amd64)ubuntu@localhost:~$ sudo reboot
<soffokl> $ ssh 172.16.194.210
<soffokl> (amd64)ubuntu@localhost:~$ sudo systemctl list-timers snappy-autopilot.timer
<soffokl> NEXT                         LEFT       LAST PASSED UNIT                   ACTIVATES
<soffokl> Tue 2015-11-17 11:00:00 UTC  50min left n/a  n/a    snappy-autopilot.timer snappy-autopilot.service
<fgimenez> mvo, there are a couple of things we can do in the test runner to make it quicker, we can save about 3min for every run in the initial steps, i'll try to prepare a branch shortly
<fgimenez> mvo, and we can of course run the suite in parallel, this could give us great time savings
<mvo> fgimenez: yay, test finished, one error that may well be a real issue! is there a way for me to see what base image version was used for the test? I wonder if it has the latest apparmor
<fgimenez> mvo, sure, at the beginning of the log, look for "Launching instance for Snappy image ubuntu-core/custom/..." the version number is right before "-disk1.img"
<mvo> fgimenez: thanks again
<fgimenez> mvo, np, btw the tests are running now against the latest available rolling/edge amd64 image, with elopio's work we can trigger them to against bbb in spi, and we could define other jobs for executing in amd64 15.04, for example
<fgimenez> mvo, when we will have the snappy-cloud-image in place we will be able to upload new images to the cloud as soon as they are published in system-image, now this process is still manual, let me know if you need a more recent rolling/edge image
<longsleep> sergiusens: Hey, i think i just found a bug in u-d-f, it seams that it applies tarballs from the system-image server in random order / tarballs are extracted into basemount in the order that they finished downloading
<Chipaca> sergiusens: ^?
<sergiusens> longsleep, hmm, you may be right; I'd need to look
 * sergiusens was having breakfast
 * Chipaca approves
<longsleep> sergiusens: i can add a bug with pointers to the code if you like
<sergiusens> longsleep, that would be good, thanks
<longsleep> sergiusens: done, see bug 1517009
<ubottu> bug 1517009 in goget-ubuntu-touch (Ubuntu) "ubuntu-device-flash applies system image tarballs in random order" [Undecided,New] https://launchpad.net/bugs/1517009
<mvo> elopio: when you have a chance, could you update the ubuntu-core xenial base image for the docker integration tests
<elopio> mvo: I can, but I'm not sure I'm understanding what you want.
<mvo> elopio: sorry, I probably did not express myself well. so â¦ I enabled the webhook to trigger the integration tests on each pull request, fgimenez hold my hand for that :) now I'm very exicted that they run. my understanding is that the base image used needs manual updates(?) and we need the latest xenial image with the latest apparmor for one of the branches
<mvo> elopio: the feature/native-security-policy-regen branch
<mvo> elopio: does that make more sense now?
<elopio> mvo: more or less :) they always run against the latest daily rolling edge, atm #235. So there's nothing to update to.
<mvo> elopio: oh, I have 247 here right now?
<elopio> mvo: do you mean that you need something that will be in the daily not yet generated?
<elopio> mvo: ah, #235 is the bbb I'm testing now.
<mvo> elopio: aha, ok. if its always using the latest image I need to ponder why the one test is failing. I was assuming apparmor on the image is out-of-date, it needs the version from ~2-3 days ago
<elopio> mvo: do you have a link to the results?
<fgimenez> mvo, elopio i think that the latest image uploaded is 229, we still are not able to upload automatically the latest ones, elopio, you can upload it with snappy-cloud-image, having the canonistack instances for the shared user loaded
<elopio> fgimenez: ahh.
<fgimenez> elopio, i can do it this time and document it somewhere (the snappy-cloud-image readme sounds like a good place :), it will be soon automated
<elopio> yes, please.
<elopio> sorry mvo for confusing it more.
<sergiusens> lool, do you have a minute to discuss plugins, build `drivers` and build tools?
<lool> sergiusens: I'm in hangouts for next 90 mn, but then free
<mvo> elopio, fgimenez: no worries and thanks for your hard work on this, its a wonderful feature and its great to see it progressing so nicely
<sergiusens> lool, great, its about the divide between openjdk, oracle jdk, former bea jdk, ibm's jdk with the combination of make, ant, maven, etc
<fgimenez> mvo, elopio ok, 247 is ready, the tests will use it from now on
<fgimenez> elopio, with snappy-cloud-image installed from ppa:fgimenez/snappy-cloud-image, just executing snappy-cloud-image -release rolling -channel edge (with the shared user credentials loaded) is enough
<fgimenez> elopio, it's takes less time to upload the image if you execute that from a cloud instance
<mvo> fgimenez: \o/ I triggered a re-test
<mvo> fgimenez: this is real magic, I'm really exicted
<fgimenez> mvo, great! :)
<zyga> tedg: thank you for the questions
<mvo> just fyi (jdstrand will also send a mail about it). the native-security-policygen-regen branch landed that means we no longer use aa-clickhook to generate the security profiles. this *might* introduce bugs but its a really nice cleanup step
<elopio> plars: the bbb tests stopped working without any changes to the scripts. Could it be timing out?
<plars> elopio: when did they last work?
<elopio> plars: tuesday.
<elopio> then I fixed some bugs on the tests, and no results_payload anymore.
<plars> elopio: did you get any output from them? I don't see a whole except that it successfully booted into the test image, ran some tests, and got a 255 rc
<plars> elopio: ah, hang on, maybe more to it... let me dig a little
<elopio> what's a 255 rc?
<elopio> no output received. results_payload empty.
<plars> elopio: it looks like it couldn't connect to the test image after all
<plars> elopio: the bbb seems fine, the default image running on emmc works
<elopio> plars: should I do something in my script to notice this?
<plars> elopio: I'm not sure that you can - I think it should fail before it even gets to your script. Is it possible the image is just busted? Have you tried this locally on a bbb?
<elopio> plars: yes, daily.
<elopio> it works.
<plars> elopio: you say it last worked on tuesday, the 10th?
<elopio> plars: yes.
<lentzi90> Is there some simple way of getting the IP addres of a beaglebone running snappy ubuntu? I can't find my micro HDMI adapter... and I can't access the router to check it that way.
<beuno> lentzi90, it might be on the network as webdm.local
<beuno> try pinging that
<lentzi90> ok thanks!
<jdstrand_> kyrofa: fyi, see mov's comment on the security regen branch landing
<kyrofa> mvo excellent news! Thanks for the heads up jdstrand_
<plars> elopio: so a couple of things...
<plars> elopio: 1. I'm trying a test job on both bbb's we have, to see if one of them is bad or something
<plars> elopio: 2. the way I'm trying to detect whether we're in the emmc image, or the test image that we just flashed, or if we didn't manage to get to any image at all isn't great.  Pretty much anything I can do to detect if it's in the snappy image we flashed is bound to be fragile, and what that means for right now, on bbb, we are not properly detecting that it
<plars> can't reach the bbb after flashing
<plars> elopio: what *should* happen is that the provisioning step should fail, and it wouldn't even try to run your test, so there would definitely be no test results in that case, but I think SPI would mark the test failed
<plars> elopio: I'll get a fix in for the case where it doesn't detect boot failure to the test image properly, but I'm more concerned with why it's not seeing the test image. I'll let you know what I find out
<elopio> plars: thank you.
<plars> elopio: I need to look at the x86 hosts also, I couldn't get any of them working last I tried, and I'm concerned that maybe some change to the image broke them. Any thoughts on that? I heard there were going to be some changes but haven't had a chance to check them out yet
<elopio> plars: no. I'm basically ignoring the x86 hosts because we can't reboot them.
<elopio> that's the useful part of this suite.
<plars> elopio: yeah, I have a story in our backlog to explore other options for automating x86... I think we may have to break down and just netboot them
<plars> elopio: I was hoping to use some feature of grub that supposedly lets you read a file over http, and use that to give a hint which mode to boot into, but I can't seem to get networking up on grub unless I pxeboot the system
<plars> elopio: so it may make more sense to just have it netboot an initrd image, and do everything from there. I think ogra_ was working on something like that for rpi2, and perhaps it would make sense to just do the same for x86
<mvo> elopio: I triggered a new xenial image with the new security policy generation code, if you want to play around a bit later and poke at it
<plars> elopio: hmm, the first bbb has booted and seems to be running my test. I can connect to it and snappy seems to be running, so I think it *can* work
<elopio> plars: I'll launch a new one.
<plars> elopio: what are the options you are passing to udf on it?
<elopio> mvo: great, thank you!
<mvo> elopio, fgimenez: there is also a new initramfs-tools-ubuntu-core with all-snap support it should be fully backward compatible but if you see boot issues in the tests alter me please
<elopio> plars: core rolling --channel edge --oem beagleblack --developer-mode
<plars> elopio: both of mine ran just fine
<elopio> mvo: is it good enough to check for boot problems with systemctl --failed --all }
<elopio> ?
<plars> elopio: that's the same as mine, just in a different order
<fgimenez> mvo, elopio is it included in the latest image?
<elopio> plars: same thing, no payload http://10.55.32.109:8080/job/snappy-daily-rolling-bbb/120/console
<plars> elopio: ok, so it looks like the flash went just fine, and I can even reach the image. If you are sure about that image id though, there should definitely be something there
<plars> elopio: the test failed, but spi should still fill in something
<plars> elopio: that id looks completely empty to me - as if it doesn't even exist
<plars> elopio: is that what you're seeing?
<plars> elopio: give me a bit to grab some lunch and I'll take a closer look
<elopio> plars: do you mean "87fd5a8b-c9be-4a92-86ac-c3b6f0496f8d" ?
<plars> elopio: yes
 * elopio afk too.
<mvo> elopio: I think nothing should break
<elopio> plars: no, for that id I see 'test_status': 'FAILED', but 'result_payload': {}
<plars> elopio: weird, I see nothing, but maybe that's because of my credentials?
<plars> elopio: well, the reason you see nothing in the payload then would be because your script didn't put anything there
<elopio> plars: can be. Take a look at that jenkins output, it pings until the results appear, after like 44 minutes.
<plars> the failed status would probably come from spi itself
<plars> I'll try to reproduce the steps by hand and see if I can spot something
<elopio> plars: right, what I'm wondering is why it was putting stuff last tuesday, but then after no changes it's now empty. My first suspicion was a timeout.
<plars> let me grab food first though
<plars> elopio: ok, I found the problem
<plars> results=cat: restuls/output/artifacts/results.subunit: No such file or directory
<plars> elopio: also, would you mind cleaning up the tmpdirs you create? since they are not in the SPI generated path, they won't get automatically cleaned up
<plars> elopio: an easy way you can do it (which would also facilitate easier debugging) is to do a static path, and just rm it before starting
<plars> elopio: ex: rm -rf /tmp/elopio && mkdir /tmp/elopio
<elopio> plars: I do this: results=$(cat restuls/output/artifacts/results.subunit 2>&1)
<elopio> so if the file doesn't exist, it will assign the error to results.
<elopio> it should end in the json anyway.
<elopio> I added a trap and corrected the typo. Lets see what happens now.
<plars> elopio: hmm, I think you'll hit problems when writing the json, because ${results} doesn't have anything
<plars> elopio: anyway, I spotted another problem, you're json is missing a comma, so I think it's going to choke on that also
<plars> elopio: on the summary line
<elopio> gagh, I hate json.
<elopio> comma added.
<elopio> I have no idea how it worked on tuesday then. must have changed it by mistake.
<elopio> plars: so, for dumb people like me, the output of this script is vital
<elopio> I can't trust myself to write a script that collect all its own errors.
<plars> elopio: there was no output from your script that helped me either, I only got that far by running it by hand and adding set -x
<elopio> plars: that's the output I want, the one from -x.
<plars> elopio: I am capturing what the script exposes as best I can in logstash, but that's not always reliable, and spi doesn't seem to gather anything on its own
<elopio> I removed it because I could not access it.
<plars> elopio: sadly, that system where I run logstash/kibana is not something you can get to through the vpn right now, I've already got a ticket in with IS to resolve that, so we'll see how it goes.
<plars> elopio: if they can get us hooked up to do that, then I'll be able to get you pretty easy access to the logs coming out of it, but it wouldn't have been helpful here I think
<elopio> plars: that would be nice so I stop bothering you.
<ksuttle> Hey there. Where can I report bugs for apt-get?
<ksuttle> https://bugs.launchpad.net/ubuntu ?
<genii> ksuttle: ubuntu-bug apt
<ksuttle> Thanks
<jdstrand_> niemeyer1: hey, you still around?
<jdstrand> niemeyer1: wondering if you could fast track https://github.com/ubuntu-core/snappy/pull/112
<jdstrand> niemeyer1: it is just a doc change. I was writing the announcement of the policy generation branch and noticed that the docs weren't quite right
<niemeyer1> jdstrand: Will check it out
<jdstrand> thanks
<plars> Has there been any change to how you write an image to the hard disk if you want to boot from there? (x86)
<plars> I used to be able to dd it, but that doesn't seem to work now
<plars> elopio: do you know? ^
<elopio> plars: not that I know.
#snappy 2015-11-18
<sergiusens> balloons, hey, do you know how to edit in d.c.c, I'm supposed to have edit rights, but I am failing to find the edit button
<dholbach> good morning
<fgimenez> good morning
<mvo> hey fgimenez and dholbach, good morning :)
<dholbach> hey mvo
<fgimenez> hey mvo and dholbach :)
<dholbach> hola fgimenez
<fgimenez> hola dholbach! :) guten Morgen
<dholbach> :-)
<JamesTait> Good morning all; happy Wednesday, and happy Education Support Professionals Day! ð
<fgimenez> mvo, these errors have begun to show up in the suite execution this morning http://162.213.34.171:8080/job/github-snappy-integration-tests-cloud/53/
<fgimenez> mvo, here's the console output http://162.213.34.171:8080/job/github-snappy-integration-tests-cloud/53/consoleFull, search for "FAIL:"
<mvo> fgimenez: yeah, I noticed them too
<fgimenez> mvo hello-world failed to install: unpack /tmp/hello-world730293314 to /apps/hello-world.canonical/1.0.18 failed with exit status 1
<fgimenez> i'll try to reproduce locally in kvm
<mvo> fgimenez: thanks
<mvo> fgimenez: my kvm did not have network this morning
<fgimenez> mvo, same here, 249 is throwing me into emergency mode
<mvo> fgimenez: uh, emegerncy mode? fresh install or upgrade?
<fgimenez> mvo, i've just generated it with udf
<mvo> fgimenez: for me 241->249 works, but I have not tried a fresh one, let me do this now
<sergiusens> mvo, ogra_ dpm I took a stance of updating the porting guide, the only thing a bit wonky is all the uEnv.txt comments which were replaced https://gist.github.com/sergiusens/fa40a344ad4b395a99ed
<sergiusens> anyone care to look a bit
<sergiusens> dpm, I didn't update the guide directly as I couldn't find the `edit` button
<dpm> dholbach ^
<dpm> sergiusens, we're working in getting the documents directly imported from markdown. But for now, you can also edit the page on the developer site directly: https://developer.ubuntu.com/openid/login/
<sergiusens> dpm, ah, so clicking on login last night did nothing, I only had the option to go to myapps in the combo
<sergiusens> :)
<sergiusens> dpm, feel free to use my markdown as a base ;-)
<mvo> fgimenez: fwiw, it seems like there is one bug in the systemd.enable code that I fixed, there is also a issue with systemd-tmpfiles-setup.service that shows as failing
<fgimenez> mvo, ok thanks
<dpm> sergiusens, hm, what does "did nothing" mean? I see you're a member of https://launchpad.net/~ubuntudeveloperportal-editors, so assuming you had the box ticked in the SSO login, that should get you into the site with edit rights (i.e. you should see the edit toolbar at the top of the browser)
<sergiusens> dpm, I had no way to login, the direct link you gave me, logged me in ;-)
<dpm> sergiusens, did you have the ubuntudeveloperportal-editors checkbox ticked? SSO always asks for team permissions
<sergiusens> dpm, the scopes don't always show up
<sergiusens> to be clear, on the top bar I had a 'Log in' button that did nothing, only showd a combo box that took you to 'My Apps'
<dpm> sergiusens, not sure we're talking about the same thing. Which scopes?
<sergiusens> after I clicked on the link you gave me, (and I suspect the magical openid/login/ at the end helped), I had that 'Log in' turned into 'Sergio'
<sergiusens> dpm, by scopes I mean oauth scopes (the checkbox you asked if I had clicked)
<sergiusens> and no, I didn't have to click on anything
<sergiusens> dpm, to be even more clear and obvious, go into private mode in your browser, then go here http://developer.ubuntu.com/en and try to login ;-)
<dpm> sergiusens, my point is that this is the url that should be used for login https://developer.ubuntu.com/openid/login/ , the combo box has no other function that tell you you're logged in (and to log out). I think what might have happened is that you logged in the first time without checking the boxes. So you might need to log out and log in again
<dpm> I've just tried it on a private browser to make sure the site is not broken, seems to work
<sergiusens> dpm, right, with your magical link I can log in just fine, the problem is, I had no idea that was the only way to login
<sergiusens> dpm, I was saying, try to login without going straight to https://developer.ubuntu.com/openid/login/ and try to reach that from the main site ;-)
<dpm> sergiusens, did you get a copy of the editor guide? Let me just send it to you
<dholbach> sergiusens, taking a look
<dholbach> davidcalle, I just tried to help sergiusens and update https://developer.ubuntu.com/en/snappy/guides/porting/ but I got all confused with the eight-col / twelve-col bits
<dholbach> can you help me?
<dholbach> and can we maybe make this easier somehow?
<dholbach> I feel really bad about asking you every time :)
<sergiusens> dholbach, davidcalle wait, I need some reviews for that from ogra_ or mvo ;-)
<dholbach> ok...
<davidcalle> sergiusens, eight-col is text, twelve-col is code, that's the Ubuntu web guidelines, can't do much about it. Also, if you have any suggestions on how to ease the editing process, I'm all ears :)
<sergiusens> davidcalle, heh, that was for dholbach I guess.
<davidcalle> sergiusens, hah :)
<davidcalle> sergiusens, still, I'm open to suggestions :p
<sergiusens> davidcalle, my only suggestion is autogenerated d.u.c ;-)
<sergiusens> davidcalle, I would like it to use pandoc which supports the github """extensions"""
<davidcalle> sergiusens, well, all docs can't be autogenerated, but we could see how to add a markdown editor, that would help for some large docs.
<sergiusens> davidcalle, certainly; that is also a great idea
<dholbach> davidcalle, once we have the new djangocms landed we can check into adding new modules :)
<davidcalle> dholbach :)
<mvo> fgimenez: I think I found and fixed the issue, lets see if the next image is better
<fgimenez> mvo, great! we haven't yet in place the automated process for creating the images used by jenkins, ping me when ready to upload it
<plars> fgimenez: mvo: I'm seeing that issue too with 249, is there a new one building now?
<plars> or will it be tomorrow?
<mvo> plars: now, should be ready in ~30min
<plars> mvo: woo! thanks :)
<mvo> plars: well, bbb will be a bit slower and I only tested by live-patching the initrd so it may take another iteration (but I hope not)
<plars> mvo: understand, thanks
<plars> mvo: looks like it worked :)
<mvo> plars: yay, I'm still downloading :/
<jdstrand> mvo: hi!
<jdstrand> mvo: so, I did snappy update yesterday and rolling edge amd64 r248 didn't have policygen
<jdstrand> mvo: so then I upgraded this morning to r249 and it went into emergency mode. looks like plymouht failed?
<jdstrand> mvo: is this known?
<mvo> jdstrand: r250 from ~5min ago fixes it
<mvo> jdstrand: yes, know, plymouth is a red-herring, it was me breaking the initramfs in an unfortunate way
<jdstrand> ah
<mvo> jdstrand: if you run the update again it should be good
<jdstrand> well, I couldn't seem to get a shell that would allow me to do that
<jdstrand> that's ok though-- I use kvm snapshots
 * jdstrand is getting 250 now
<jdstrand> mvo: hmm, so, r250 doesn't seem to have policygen either
<jdstrand> mvo: is that known?
<jdstrand> mvo: basically, yesterday I was in the process of writing the email to the list about it and then I wanted to wait until it was on the image
<mvo> jdstrand: uh, that sucks, looks like unfortunate timing between daily build and git importer :/
<mvo> jdstrand: give me a sec to check
<mvip> hey ricmm_. Thanks for coming out to the BBVA event on Monday.
<jdstrand> mvo: ok-- I don't want you to go out of your way for this. I just wanted to make sure things were working as planned
<mvo> jdstrand: could you approve my https://myapps.developer.ubuntu.com/dev/click-apps/3966/ ? its the first squashfs based snap for the store
<mvo> jdstrand: I'm very thankful that you brought it up
<mvo> jdstrand: I triggered a build of snappy and will soon make a new image with it
<jdstrand> mvo: can you request a manul review? if I do, then I can't approve it I don't think
<mvo> jdstrand: its a bit unfortunate that the turnaround time is close to 24h in the worst case, I merged last afternoon thats something the snappy team needs to discuss/improve :)
<mvo> jdstrand: I think I did that now
<jdstrand> mvo: that is good timing-- I have a branch that I've been working on to handle squashfs snaps
<jdstrand> (for the review tools)
<mvo> jdstrand: nice
<jdstrand> mvo: so, if you are uploading to the store, that means that snappy has enough implemented to install it?
<jdstrand> mvo: I guess when this new image comes out?
<mvo> jdstrand: yes, it has enough implementation for this now and it will be useful as a regression test
<mvo> jdstrand: its rolling only so should not affect anyone who is not up for the ride
<jdstrand> mvo: well, this needs the policygen branch, no?
<mvo> jdstrand: the current code will just unpack it, the next image (once I get review) will properly mount it for that the policygen is required
<jdstrand> I see
<mvo> jdstrand: are you concerned that it might break? I could use something different or a different name
<jdstrand> I'll accept and now I have a snap to work with
<mvo> jdstrand: great, thanks
<elopio> fgimenez: ogra_: I gave up with this when xz was killed because it was consuming too much RAM.
<elopio> https://github.com/ubuntu-core/snappy/pull/122
<mvo> fgimenez, elopio: could you update the base image to r250 for the integration tests?
<mvo> please :)
<fgimenez> mvo, elopio i was trying the new jenkins job for automating this and i think it's already done, let me check
<mvo> fgimenez: \o/
<fgimenez> elopio, ok np, when automated the initramfs resize test could be filtered/annotated like the gadget snap ones, so that we can keep all them together and reuse the helpers
<fgimenez> elopio, i've pinned some of the build reports in the jenkins executions for you to have a look, most of the errors will be probably because of the canonistack instances http://162.213.34.171:8080/job/github-snappy-integration-tests-cloud/
<elopio> fgimenez: /me looks.
<elopio> fgimenez: this looks wrong: Error: unable to create /boot/grub/grub.cfg/grub.cfg: open /boot/grub/grub.cfg/grub.cfg: not a directory
<elopio> but I was debugging it yesterday and the test started passing.
<elopio> now without the init going crazy I hope it will be easier to debug.
<fgimenez> elopio, i'm looking into it right now too :) it's present in the latest 3 executions
<fgimenez> elopio, i've tried the fake update manually and it works fine, not sure where does this come from
<elopio> fgimenez: my last try last night seemed to be caused by initramfs test being killed and leaving a weird state. I don't see that in this log.
<elopio> but let me run dozens today again, and I'll tell you what's going on.
<fgimenez> elopio, yes, initramfs hasn't been executed yet, this happens for the three failover test, and it seems that up to this point https://github.com/ubuntu-core/snappy/blob/master/integration-tests/tests/failover_test.go#L57 all goes fine
<elopio> I ran only the three failover tests, and couldn't reproduce that. But only a couple of times. I'm not yet sure if it's caused by the full suite.
<elopio> moar runs!
<fgimenez> elopio, :) it may be related to the slow instances too
<fgimenez> but didn't happen before yesterday afaik
<fgimenez> leaving, have a nice day o/
<mvo> jdstrand: I have more interessting stuff for you :) https://myapps.developer.ubuntu.com/dev/click-apps/3753/
<mvo> jdstrand: and the os snap in https://myapps.developer.ubuntu.com/dev/click-apps/3752/
<mvo> jdstrand: if those could get in that would be very nice indeed
<jdstrand> mvo: re https://myapps.developer.ubuntu.com/dev/click-apps/3753, can you request a manual review?
<jdstrand> mvo: same with https://myapps.developer.ubuntu.com/dev/click-apps/3752
<jdstrand> man, you are going to keep me busy with the review tools
<mvo> jdstrand: ups, I thought I did request that already, sorry. requested it now :)
<jdstrand> mvo: done
<mvo> jdstrand: \o/
<jdstrand> mvo: I think once I teach the tools not to just die on non-click snaps (in progress), these tests will simply see if it is a kernel or os and then flag for manual review. nothing more. if someone wants to add more tests for the review tools for those once things have settled, that would be great
<mvo> jdstrand: I think thats totally fine
<mvo> jdstrand: hey, fwiw I found and fixed the issue that held the policygen stuff back its now ready but for some reason the import imports are disabled in cron. I asked sil2100 about it but no feedback yet. I will wait until my morning and if its not there by then I will manually import the image
<jdstrand> mvip_: ack, thanks
<jdstrand> mvip_: sorry
<jdstrand> mvo left and you got tab completed :)
#snappy 2015-11-19
<jdstrand> ogra_: fyi, snappy install ufw.jdstrand. enjoy :)
<sergiusens> jdstrand, btw, I can't do $SNAP_APP_DATA_PATH in a `start` for a service
<sergiusens> jdstrand, mind approving this later https://myapps.developer.ubuntu.com/dev/click-apps/3989/seq/1/ ?
<sergiusens> and that also relates to the question about using $SNAP_APP_DATA_PATH
<Sam_> : )
<dholbach> good morning
<fgimenez> good morning
<pandatrone> what is this https://uappexplorer.com/app/ubuntu-kernel.mvo ???
<mvo> pandatrone: its the next step on the road to 16.04, kernel and os snaps
<pandatrone> mvo, awesome! i like it
<mvo> pandatrone: yeah, I'm quite excited about it too, it will open up a lot of new possibilities :)
<pandatrone> you snappy people are great
<pandatrone> and mir people :D
<mvo> heh, thanks :-D
<pandatrone> i get 10-50% more fps in glmark2 in OTA8 compared to OTA5 on mx4
<pandatrone> unity people are a little confused buy they'll catch up
<pandatrone> *but
<fgimenez> hi mvo good morning
<mvo> hey fgimenez
<mvo> fgimenez: sorry for the slow reply
<fgimenez> mvo, np :) i was getting some errors from udf but now it seems to be working again
<fgimenez> mvo, 254 is available already in jenkins
<mvo> fgimenez: nice!
<JamesTait> Good morning all; happy Thursday, and happy Use Less Stuff Day! ð
<shouting-sergius> sergiusens hello
<shouting-sergius> balloons hello
<sergiusens> dpm, mind approving https://myapps.developer.ubuntu.com/dev/click-apps/3989/seq/2/ ?  the failure there is due to an outdated reviewer tool being used
<dpm> sergiusens, I haven't reviewed an app in quite a long time, so I'm not sure I'm the right person, but I'm sure dholbach or popey can help
<popey> sure thing!
<dpm> cool, thanks!
<popey> sergiusens, done
<sergiusens> popey, thanks, now balloons can use a snap instead for irc ;-)
<livcd> so i'd like to use snappy as a base image with vagrant on mac  to run docker containers. Would it work for my use case ?
<sergiusens> livcd, it should, there is a docker snap already, there are some gotchas, but I don't run docker myself to remember those
<sergiusens> livcd, if you run into trouble, just ask (on askubuntu would be even better to keep some history and help others seeing the same you would)
<shout-user69> popey thanks for approving me into existence :-)
<popey> haha
<popey> what have I done!!
<livcd> sergiusens: not yet familiar with what a snap is :-)
 * shout-user69 twiddles fingers
<sergiusens> livcd, oh; a snap is a package
<sergiusens> livcd, maybe go over the tutorials?
<livcd> reading them atm
<sergiusens> livcd, https://developer.ubuntu.com/en/snappy/start/#vagrant
<sergiusens> you can read and play at the same time ;-)
<livcd> sergiusens: i'd like to build an img myself with packer
<sergiusens> livcd, I can't help you there; if you drop your question on askubuntu maybe someone can help out
<Chipaca> what's packer?
<jdstrand> sergiusens: can you request a manual review?
<jdstrand> beuno, pindonga: hey, can somone pull in the review tools? there are are fixes for sergiusens' failure and two others for clicks that popey and dholbach saw. This is not the branch for non-click/all snaps (that is in progress)
<pindonga> jdstrand, what revno?
<jdstrand> the latest is fine
<jdstrand> r550
<pindonga> we'll need to do some QA on staging before we can roll  it out (to verify all pending changes are good to go) but I'll plan for the rollout asap
<jdstrand> thanks
<sergiusens> Chipaca, I think packer is a vagrant thing
<sergiusens> Chipaca, https://www.packer.io/intro/getting-started/vagrant.html
<sergiusens> Chipaca, elopio mind looking at https://github.com/ubuntu-core/snapcraft/pull/102 ?
<elopio> sergiusens: oh good, I'll try to play with the nodejs bbb package again.
<elopio> you have a copy&paste error: GoPluginTestCase
<sergiusens> elopio, ah, interesting :-)
<sergiusens> elopio, fixed, still not pushed, but 100% coverage is what I had to share with you :-P
<sergiusens> dholbach, is the wiki completely dead?
<dholbach> sergiusens, this morning I got a 500 internal server error, pinged IS and it came back again
<sergiusens> dholbach, works now, thanks
<sergiusens> mvo, ^^
<jdstrand> sergiusens: hey, can you request a manual review for https://myapps.developer.ubuntu.com/dev/click-apps/3989/seq/1/?
<jdstrand> mvo: hey, I'm going to remove click-apparmor from the system-image seed on xenial
<sergiusens> jdstrand, what for, seq/2 is already approved
<sergiusens> ?
<jdstrand> ok, there is a 0.0.1
<jdstrand> I'll reject that
<mvo> jdstrand: thanks!
<jdstrand> mvo: I'm also updating ubuntu-core-security to remove sc-filtergen and not pull in easyprof
<mvo> jdstrand: nice, very very nice
<faenil> hello
<faenil> I'm trying to port snappy to a new board, but the image ubuntu-device-flash outputs has a partition table which is not recognized by either uboot or "Disks" app on Ubuntu
<faenil> fdisk -l reports fat + 3 ext4 partitions
<faenil> while "Disks" and uboot only see a huge fat partition, thus failing to access the data in any of the partitions
<faenil> any advice
<faenil> ?
<faenil> ogra_: ^ maybe :)
<sergiusens> faenil, what does parted say?
<faenil> sergiusens: parted shows the partitions
<faenil> gparted doesn't
<faenil> "Disks" software doesn't
<faenil> uboot doesn't
<faenil> fdisk -l shows the partitions
<sergiusens> faenil, does your u-boot support ext4?
<faenil> sergiusens: I rebuilt it to add ext4 commands
<faenil> sergiusens: still, gparted and Disks on desktop only show a big fat partition, like uboot
<sergiusens> faenil, can you run `kpartx -avs <image.img>` ?
<sergiusens> someone who can help with u-boot itself is lool
<faenil> sergiusens: http://pastebin.ubuntu.com/13348638/ kpartx
<faenil> sergiusens: I can loop mount the img on desktop, but not the sdcard (but I guess that's expected). I can still mount the fat partition from the sdcard using "-o offset"
<sergiusens> faenil, has your 'dd' finished correcly (ins and outs match and all that)
<sergiusens> sorry for asking a possibly dumb question
<faenil> sergiusens: yeah
<faenil> sergiusens: I tried multiple times, and with 2 different sdcards
<faenil> 2925000000 bytes (2.9 GB) copied, 162.81 s, 18.0 MB/s
<faenil> (that's the size of the img)
<sergiusens> faenil, parted against the sdcard is also fine?
<faenil> sergiusens: what do you mean?
<faenil> yes, "print" shows 4 partitions on the sdcard
<faenil> gparted instead shows 1 partition as big as the sdcard, with "Unknown filesystem"
<faenil> and lba flags
<sergiusens> faenil, could this be a gpt problem?
<faenil> sergiusens: I guess it could...
<faenil> sergiusens: even though parted says "Partition Table: msdos
<sergiusens> faenil, are you sure you are booting your u-boot and not whatever is on the board?
<faenil> sergiusens: yes, 100%
<faenil> the versions tells it
<faenil> and I have ext4 commands available, which the original uboot for this board don't have
<faenil> sergiusens: I defined
<faenil> #define CONFIG_CMD_EXT4
<faenil> #define CONFIG_CMD_EXT4_WRITE
<faenil> is there anything else needed for ext4 support? that seems all it's needed, I had a look at README.ext4 in uboot's docs
<longsleep> faenil: what u-boot version are you based on?
<faenil> longsleep: 2015.4
<longsleep> faenil: sounds good
<faenil> should be, yeah :)
<longsleep> faenil: i am stuck at 2011.3 :/
<faenil> yeah, I guess most of the people are not that lucku
<longsleep> faenil: not sure if it helps, but https://github.com/longsleep/u-boot-odroidc/commits/master is my u-boot tree to make the upstream u-boot work with snappy
<faenil> sergiusens: the img was created using --oem beagleblack (because there doesn't seem to be any generic-armhf package and that's what the Porting guide recommends), using edge channel
<faenil> but that shouldn't make a difference on the partition table, should it
<faenil> longsleep: cheers
<sergiusens> faenil, well if your board is exactly the same wrt to boot setup, then there you go
<sergiusens> faenil, fwiw, I took a stance at updating the porting guide
<sergiusens> faenil, https://gist.github.com/sergiusens/fa40a344ad4b395a99ed
<sergiusens> still needs a review from ogra_ but he is off this week on leave
<faenil> sergiusens: isn't there a list of oem snaps?
<longsleep> faenil: in general, if u-boot fails its best to figure it out in u-boot shell, maybe your oem snap did overwrite some stuff of the partition table
<faenil> longsleep: I wish there were a generic armhf oem snap :/
<sergiusens> faenil, well you can search the store with `type: oem`
<sergiusens> faenil, I always forget how to query the store though and we never baked that into u-d-f
<faenil> sergiusens: hehe
<faenil> anyway, there's no generic armhf oem snap :)
<longsleep> faenil: mhm well, how can there be a generic one if all devices need other bootcode?
<sergiusens> faenil, there is no such thing as a generic bootloader for arm ;)
<sergiusens> u-boot is the closest you can get, but they all boot at different offsets
<faenil> ok, sorry, I don't know what the oem snap contains so I'm just blind guessing ;)
<longsleep> faenil: Look at https://github.com/longsleep/snappy-odroidc - that puts all the gear together to build u-boot, kernel, oem snap and device tarball for the ODROID-C platform
<faenil> longsleep: ok, I'll have a look thanks
<longsleep> sergiusens: Your porting guide looks good - i think that will help people a lot when its ready
<sergiusens> thanks, still a bit to update wrt to uEnv.txt and others
<faenil> sergiusens: longsleep beagleblack doesn't touch the partition table afact http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files/head:/beagleblack/
<longsleep> sergiusens: maybe you can add a section on how the initrd can be optained
<longsleep> faenil: no, but it wites stuff raw at the beginning of the disk, see the boot-assets in the meta/package.yaml
<faenil> longsleep: I see...is that snappy yaml syntax to do that?
<longsleep> faenil: yes, when ubuntu-device-flash assembles the image, it writes the stuff under raw-files 'raw' at the specified disk offset
<longsleep> faenil: what these offsets are actually depens where your arm device expects its bootcode to be
<faenil> longsleep: sure
<faenil> my question now is more generic :)
<faenil> is that what happens when you "install" that snap?
<faenil> I guess it's not something specific to device-flash
<longsleep> faenil: nope, when you install a snap it essentially just downloads a special kind of deb package and extracts it to a well known location
<longsleep> faenil: the special kind of snap with type oem, is used by u-d-f when you create a image for that platform
<faenil> longsleep: so that raw stuff is a special direction that only udf will use?
<faenil> ok
<longsleep> faenil: yes, for now the boot-assets stuff is only used by u-d-f afaik
<faenil> ok, thanks
<faenil> longsleep: I guess my next step is to have a look at what you I guess, then :)
<faenil> since the porting guide doesn't cover this part at all :)
<faenil> I also read ogr a's post, but it doesn't mention what to do when, for instance, your board doesn't come with initrd support by default
<faenil> which is all stuff we should really take care of, in a porting guide :)
<faenil> sergiusens: ^
<faenil> or when your uboot doesn't read any env file, for instance
<longsleep> faenil: mhm, initrd should be unrelated to the board, its related to the kernel and the distribution
<longsleep> faenil: well, every u-boot has variables, just make it read one
<faenil> longsleep: that's not the right attitude for a guide, imho :D
<faenil> if we want to attract more people, we have to make it easier
<longsleep> faenil: sure, but i fear porting to whatever arm platform is not so easy, and i am not sure if a snappy porting guide should explain u-boot so much
<longsleep> faenil: there could be a u-boot guide though :(
<faenil> yeah, initrd is unrelated, but not all distro/kernel that you get with a board come with initrd...while the guide assumes that you have one and that you can adapt it
<longsleep> faenil: ah ok, i get what you mean. I think you should turn the initrd question around, Snappy has one and you should adapt it to mach your kernel. That is how i did it
<longsleep> faenil: essentially i use the exact initrd from snappy upstream, see https://github.com/longsleep/snappy-odroidc/blob/master/device.mk#L59
<faenil> longsleep: I see, ok.
<faenil> yeah I believe we just have to be a bit more detailed :)
<faenil> and I have almost 0 experience with dev boards, so I'm just giving feedback on how we could improve the guide :)
<longsleep> faenil: yeah, i had little u-boot experience when i started porting to snappy, but with lots of help from ogra_ i managed to get it done without very much issues. I have written about it a bit https://www.stdin.xyz/2015/06/14/snappy-ubuntu-core-for-odroid-c1/ if you want to get some ideas what problems i found
<faenil> longsleep: awesome, thanks
<faenil> longsleep: it is important that we don't let those post stay post (I'm probably going to write one as well), but we collect all the issues we had and update the official guide accordingly :)
<faenil> we don't let those posts remain posts on a blog*, I meant
<longsleep> faenil: yes, it would be awesome to have good guides, for now i think the best answer is go to #snappy IRC and ask - the guys here are awesome.
<faenil> :)
#snappy 2015-11-20
<liuxg> how to disable autopilot. my raspberry pi display the message like "snappy autopilot triggered a reboot to boot into an up to date system -- temprorarily disable the reboot by running 'sudo shutdown -c'" from time to time.
<fgimenez> good morning
<JamesTait> Good morning all; happy Friday, and happy Ubuntu Community Appreciation Day! ð
<happyaron> hey, I wonder which image is the latest snappy image, where can I find it?
<olli> gm
<kyrofa> happyaron, for which device or arch?
<happyaron> kyrofa: for amd64, preferrable for VM. I'm not running the vivid image on edge channel, but I'm curious about whether that's latest, or there is a wily based or even x-series based one?
<happyaron> s/not running/now running/g
<kyrofa> happyaron, ah, so you've seen https://developer.ubuntu.com/en/snappy/start/#snappy-local then
<happyaron> yep\
<kyrofa> happyaron, I'm not sure about the x-based question-- hang out and someone more qualified will come by :)
<happyaron> I tried to install ubuntu-snappy on an x-series chroot, but it appears missing many configurations (and the layout is not real snappy, of course)
<happyaron> okay, :)
<kyrofa> happyaron, but do note that you can create your own image via ubuntu-device-flash
<happyaron> ah let me look into that, ty!
<kyrofa> happyaron, any time!
<mvo> jdstrand: if you have a moment, it would be great if you could approve my pending kernel/os/oem snaps, this should allow a full all-snap image to be assembled
<mvo> jdstrand: they are pending review in the store, the update was needed to push some fixes in
<jdstrand> mvo: hello, sure
<jdstrand> mvo: fyi, I have a branch that can handle all these, but there will still be a manual review for these types
<jdstrand> mvo: it'll look much like the oem feedback
<jdstrand> mvo: done
<asac> stgraber: i am kind off failing with something basic wrt lxd... all i want is to mount some dir in my home into the container and while the homedir: ... entry in config seems to work and mounts the dir i conifgured to /extra ... i cant seem to find a reasonable way to make that writable by the lxc uid etc.
<jdstrand> mvo: I imagine there needs to be some conversation on this wrt to review tools. ie, imo you shouldn't be inhibited by the tools for these, but others should. eg, a sort of 'core-dev' group rights thing in the store
<asac> and the id_map things i tried in config didnt work at all
<asac> stgraber: think i ended up trying to do something https://github.com/lxc/lxd/issues/579 ... but not sure if thats the right way to just conveniently get a directory int he container that i can use ther
<mvo> jdstrand: \o/
<jdstrand> mvo: actually, I imagine it has nothing to do with the tools themselves. the store would simply ignore this one check if it came from this privileged group
<mvo> jdstrand: yeah, it would be nice if there would be some sort of whitelist
<jdstrand> like we do with brand stores
<mvo> jdstrand: so ./ubuntu-device-flash --verbose core rolling -o amd64-all-snap.img --channel edge --oem generic-amd64.mvo --developer-mode --kernel ubuntu-kernel.mvo --os ubuntu-core.mvo works now
<mvo> jdstrand: well, with me updated u-d-f, so thanks for allwoing it into the store
<jdstrand> nice!
<elopio> pitti: on adt-run, why is the source tree copied with owner ubuntu:root instead of ubuntu:ubuntu ?
<pitti> elopio: err, I don't know, is it? which backend?
<elopio> pitti: snappy.
<pitti> so, ssh runner?
<elopio> pitti: yes.
<pitti> ah, I think copying files in doesn't drop privileges, it just keeps root
<kgunn> hey so i'm building mir in a container, targetting xenial....got to the point of snapcraft assemble....all was going well, but then suddenly bailed
<kgunn> https://pastebin.canonical.com/144531/
<kgunn> wondering if this is a known issue?
<kgunn> gonna try again...
<kgunn> oops nvmd...i was updating in the background, i think lxd was configuring
<elopio> yes, that main.go had me puzzled.
<mvo> jdstrand: if you could approve https://myapps.developer.ubuntu.com/dev/click-apps/3752/review/seq/4/ that would be awsome, bugfixes plus allows upgrade testing
<kgunn> hey there, if i do
<kgunn> ubuntu-device-flash core rolling --oem=generic-amd64 --channel edge
<kgunn> is that xenial ?
<kgunn> would assume so...
<Chipaca> kgunn: yes
<Chipaca> kgunn: you probably want --developer-mode also
<kgunn> yep i do
<kgunn> thanks
<kgunn> Chipaca: any plans to add a query option for core images ?
<Chipaca> kgunn: "query option"?
<kgunn> Chipaca: so u-d-f query can be used to list channels and images for devices
<Chipaca> ah
<kgunn> would've thot there'd be the same for core
<kgunn> as there is in touch
<kgunn> consistency and all....
<Chipaca> kgunn: you might want to chat with sergiusens
<Chipaca> kgunn: i think i might be working on this tool soonish
<sergiusens> kgunn, we are retiring ubuntu-device-flash for something that targets the snappy architecture better
<kgunn> ack
<jdstrand> mvo: done
<mvo> jdstrand: \o/
<sergiusens> kgunn, also, only 16.04 and all snaps support (no system image)
<Chipaca> sergiusens: hyphens are important
<Chipaca> :)
<sergiusens> Chipaca, funnily or not,  I removed the hyphen there before pressing enter :-)
<Chipaca> sergiusens: the one in all-snaps, or in system-image? :-)
<sergiusens> Chipaca, system-image, although, all-snaps should have one too ;-)
<Chipaca> sergiusens: (you could also use quotes or caps for the same purpose, ie "all snaps", System Image)
<Chipaca> sergiusens: namely, making clear that "all snaps" and "system image" are proper nouns
<jerryG> Chipaca: can u answer a quick question?
<jerryG> plz
<jerryG> :}
<jerryG> :{
#snappy 2015-11-22
<faenil> success \o/
<faenil> snappy ported to a new board :)
<sergiusens> faenil, nice!
<faenil> :)
<sergiusens> faenil, so what was your issue?
<sergiusens> I would like to have it documented somewhere (maybe askubuntu)
<faenil> sergiusens: what was the issue I asked about, here? (sorry, don't remember)
<sergiusens> faenil, your partitions were seen as one big blob
<sergiusens> in u-boot and some other tools
<faenil> sergiusens: ah, right, that was embarassing, I think I just had a type and was dd'ing to sdb1 instead of sdb....
<faenil> typo*
<sergiusens> faenil, ah; right, that is indeed a common issue :-)
<faenil> :)
<sergiusens> but its hard to think of it when asked
<faenil> sure ;)
<sergiusens> faenil, well I am glad you got it working!
<faenil> but at that point I still had beagleblack oem snap etc
<faenil> now I have all properly setup, except I think my board can't start uboot from sd
<faenil> so I think uboot in the oem snap is not needed at all
<faenil> I sent an email to customer support of the board to ask for confirmation, but their wiki says that loading uboot from sd is only supported on another module, not mine
<sergiusens> faenil, oh, that is a bummer, can you update the bootloader on the board directly?
<faenil> sergiusens: yep, by putting it on the sd and running a couple of commands
<faenil> that's what I've done :)
<sergiusens> yeah, as long as there is a way to do it
#snappy 2016-11-21
<liuxg> has anyone ever used --jailmode to install an snap? I just reported a bug at https://bugs.launchpad.net/snappy/+bug/1643419. I am not sure whether it is a valid bug report. However, it does not show the correct result. thanks
<mup> Bug #1643419: jailmode is not wroking properly <Snappy:New> <https://launchpad.net/bugs/1643419>
<mup> Bug #1643418 opened: jailmode is not wroking properly <Snappy:New> <https://launchpad.net/bugs/1643418>
<mup> Bug #1643419 opened: jailmode is not wroking properly <Snappy:New> <https://launchpad.net/bugs/1643419>
<foxmask> bonjello
<dholbach> good morning
<mup> Bug #1643418 changed: jailmode is not wroking properly <Snappy:New> <https://launchpad.net/bugs/1643418>
<mup> Bug #1643419 changed: jailmode is not wroking properly <Snappy:New> <https://launchpad.net/bugs/1643419>
<didrocks> hey dholbach, foxmask
<zyga> o/
<foxmask> didrocks: hi
<dholbach> salut didrocks
<jamespage> jdstrand, morning
<jamespage> jdstrand, re the openvswitch interface I'm working on - what's you're preferred name? openvswitch or openvswitch-support
<jamespage> looking at the 'libvirt' interface, that allows a snap access to libvirt on the host os (in classic server installs)
<jamespage> so I wondered about following a similar pattern - openvswitch-support allow OVS to run from a snap, vs openvswitch allowing a snap to access openvswitch on the host
<jamespage> I'll need to look a libvirt in a snap next anyway :)
<xnox> Hello, I'm running $ sudo snap find -> and for various queries a bunch of snaps are returned.
<xnox> however, when trying to install them, all of them are error not found.
<xnox> I am on s390x architecture, and the snap find results do not appear to be filter to display snaps that are applicable to my architecture.
<xnox> How can I search for snaps that are available for my machine type?
<jamespage> any plans to publish snapcraft on pypi? it would make it easily consumable in openstack gate tasks
<timp> renato__: so if you add "ubuntu-telephony-phonenumber" to your snap, it pulls in the qt dependencies even though that is in the platform snap?
<timp> renato__: but only at build time? Or is it put in the final snap too?
<renato__> sergiusens, Hey I have some problems with the way that snapcraft works. As timp said adding any qml modules bring the hole qt stak and all dependencies into the package.
<renato__> sergiusens, I know that we can remove the files with " -<file-name>" but this is a huge work when the package has a lot of dependencies.
<renato__> sergiusens, do we have a way similar to "debian" packages where you specify only the files that you want in the package?
<timp> I think I am running into the same issue now. I'm making a snap with stage-packages: - ubuntu-ui-toolkit-examples
<timp> all the dependencies are in the platform snap, but when creating the snap, they are still all downloaded.
<zyga> jdstrand: hey, you may want to look at this: https://github.com/snapcore/snapd/pull/2310
<mup> PR snapd#2310: many: fix handling of jail mode in security setup <Created by zyga> <https://github.com/snapcore/snapd/pull/2310>
<zyga> jdstrand: it's related to --jailmode being effectively a no-op
<zyga> jdstrand: there's a bug referenced from there
<zyga> jdstrand: and a branch adding a small function EffectiveSecurity() that you may want to read
<zyga> jdstrand: I added a spread test as well
<zyga> jdstrand: (and some simple unit tests)
<zyga> jdstrand: none of the current tests caught this because they weren't measuring applied security, just what was being claimed
<mup> Bug #1635413 changed: newgrp doesn't work on classic <Snappy:New> <https://launchpad.net/bugs/1635413>
<sergiusens> renato__ use a positive filtes (without the `-`)
<sergiusens> renato__ stage-packages are to stage into the snap; if you only need it for building use build-packages
<renato__> sergiusens, if fact I need it to execute the app. But I do not need these dependencies
<renato__> sergiusens, if I use a positive filter it will overwrite the default behavior of adding everything?
<sergiusens> renato__ yes for that last comment
<renato__> sergiusens, great, thanks
<renato__> timp, could you try that on your examples ^^^
<renato__> didrocks, what do you think about this bug? https://bugs.launchpad.net/ubuntu-app-platform/+bug/1643220
<mup> Bug #1643220: ubuntu terminal app (edge) Unrecognized OpenGL version <Snappy:Incomplete> <Ubuntu App Platform:New> <Ubuntu Terminal App:New> <https://launchpad.net/bugs/1643220>
<didrocks> renato__: is it in SNAP_LIBRARY_PATH?
<didrocks> if so, I think snapd should then export it in LD_LIBRARY_PATH rather than having every single snap having to reexport this in a wrapper
<renato__> didrocks, this is what zyga said.
<renato__> didrocks, sould we add it on dekstop launcher?
<didrocks> if you have a nvidia device, please try :)
<didrocks> see my answer
<didrocks> 14:11:47   didrocks | if so, I think snapd should then export it in LD_LIBRARY_PATH rather than having every single snap having to
<didrocks>                     | reexport this in a wrapper
<didrocks> launcher is really a fallback for things snapd should support
<renato__> didrocks, I do not have a nvidia
<didrocks> (or snap-confine in that case)
<mup> Bug #1624322 changed: console-conf wlan race on pi3 <Snappy:Invalid> <subiquity (Ubuntu):Fix Released> <https://launchpad.net/bugs/1624322>
<mup> Bug #1638661 changed: Undo on failed refresh doesn't keep the previous snap intact <Snappy:Invalid> <https://launchpad.net/bugs/1638661>
<zyga> didrocks: snap-confine or snapd won't set it but the wrappers from snapcraft use it and merge it into LD_LIBRARY_PATH
<didrocks> zyga: thanks for the answer, so renato__, it means you should already have it exported ^
<renato__> didrocks, I do not see the desktop-launcher using it. There is another wrapper above it?
<didrocks> renato__: there is one created by snapcraft, indeed
<didrocks> and from what zyga told, this one is supposed to do this override
<didrocks> you can see it, it's at the root of your snap
<didrocks> and has a .wrapper suffix
<renato__> didrocks, ok got it. And it contains the SNAP_LIBRARY_PATH
<didrocks> renato__: seems then your bug is different that this not being exported
<zyga> renato__, didrocks: look at LD_LIBRARY_PATH at runtime and see what you have
<zyga> renato__: perhaps the issue is that nvidia support is broken in some interesting way, I'd love to help you out to fix it
<zyga> renato__: we don't have real CI for nvidia support at this time
<zyga> renato__: only to parts of it, but not really to see that it works
<zyga> renato__: also, GL has different APIs and some of those might not work (the tests may be too simplisic)
<renato__> zyga, I do not have a nvidia too. I was just trying to help and fix the problem
<zyga> renato__: so thank you for pushing the border
<zyga> renato__: I can try it on my hardware, tomorrow most likely as today I'm wrapping up last week actions and working on top-priority issues
<renato__> zyga, ok thanks. this is not a priority
<mup> Bug #1470661 changed: Tilde allowed in version but systemd hates it <Snappy:Invalid> <Snappy 15.04:Won't Fix> <Snappy trunk:Invalid> <https://launchpad.net/bugs/1470661>
<jdstrand> jamespage: hey, not sure if you realize, but glance can be published by pushing the 'publish' button. I just noticed it and thought I'd mention it. ignore me if you already knew this
<renato__> zyga, I got my snap on this state: http://paste.ubuntu.com/23511705/
<renato__> zyga, I can not install any other snap
<timp> renato__, sergiusens: actually in my case it pulls the dependencies of a deb package that I need. I guess there is no way around that?
<renato__> timp, ok but it pack the deps? Or it only packs the files that you specified?
<sergiusens> timp nope, you will have to change the dep in the deb to be a recommends and SRU or propose it
<renato__> sergiusens, the deps are necessary they must be real deps. But we do not need it on the snap since the platform will provide it
<timp> sergiusens: the runtime dependencies in the deb are correct, but they are in the platform snap already.
<renato__> I do not mind it pulling the deps. I just do not want it in the package
<jdstrand> tedg: I didn't see that ping before, but I see this one
<liuxg> kyrofa, ping
<tedg> jdstrand: heh, okay.
<tedg> jdstrand: can haz undefined interfaces?  ð
<zyga> jdstrand: in go switch/case has an implicit break
<zyga> jdstrand: classic confinement doesn't fall through and go to devmode confinement
<zyga> jdstrand: or did I misunderstand your comment there
<jamespage> jdstrand, yup I think that's done for the edge channel
<liuxg> currently, I follow the link at http://docs.ubuntu.com/core/en/guides/build-device/config-hooks, if I use "snap set <snapname> username=foo pass_word=bar", I cannot get the "pass_word" in credential file due to the "_" in the "pass_word". this is a bug?
<jdstrand> zyga: I think you misunderstood. look at case.StrictConfinement
<zyga> jdstrand: I think I see what you mean now
<jdstrand> zyga: if f.JailMode
<zyga> jdstrand: I just replied
<jdstrand> zyga: then you have a comment talking about devmode
<zyga> jdstrand: yes, because the comment refers to the check for devmode *flag* below
<zyga> jdstrand: if both flags are set I pick jailmode
<jdstrand> zyga: but, we are in snap.StrictConfinement
<jdstrand> I'll read your comment
<zyga> jdstrand: but even in that confinement we can have either or both of the flags set
<jdstrand> I added a new comment
<zyga> jdstrand: sure, I'll do that; thanks
<zyga> jdstrand: if you can also review https://github.com/snapcore/snapd/pull/2315 I could land it, it's a big mechanical change to how devmode is conveyed
<mup> PR snapd#2315: many: use snap.ConfinementType rather than bool devmode <Created by zyga> <https://github.com/snapcore/snapd/pull/2315>
<jdstrand> zyga: I reviewed that with a cursory review and it looked fine, but an in depth review will have to wait a bit. I'm trying to get the dbus interface up in a PR today so there is a chance of it landing before I go on holiday on wed
 * zyga nod
<topi`> is there a channel for Ubuntu Snappy?
<topi`> I guess I mean Ubuntu Core
<jdstrand> seb128, mhall119: hey, are there workking devmode snaps that are blocked on bug #1590679?
<mup> Bug #1590679: Apps can't own session bus names (unity7 interface) <snap-desktop-issue> <snapd-interface> <Snappy:In Progress by jdstrand> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1590679>
<jdstrand> seb128, mhall119: I've been told they should be available, but I don't know where to find them
 * jdstrand is trying to get gnome-mahjongg into runnable state atm since that is all I have to work with atm and it fails to launch with my dbus changes
<seb128> jdstrand, robert_ancell had a stack of GNOME ones he was working on that he didn't publish/that are blocked on that
<seb128> what error do you get?
<jdstrand> seb128: it segfaults. seems he stopped cause of the apparmor denial. I think it just needs the gtk desktop part
<jdstrand> seb128: but I'm looking for a working devmode snap. did he upload any of those?
<seb128> jdstrand, the one I pointed out in comment #18 should work
<jdstrand> cause, you can publish to edge with devmode fine
<seb128> right, I don't know if he did that
<seb128> I would assume not
<jdstrand> let me try the gnome-logs one
<jdstrand> seb128: there is a gnome-logs in the store in strict mode. is that this?
<seb128> I don't remember if I uploaded that by then
<seb128> but it's probably it yes
<jdstrand> oh it didn't pass review
<seb128> there was some dangling symlinks or something iirc?
<seb128> it has been a while, I don't remember the details
<jdstrand> yes
<jdstrand> that's fine
<jdstrand> I think I can move forward with it
<seb128> great
<seb128> let me know if I can help in any way
<mup> Bug #1642669 opened: Can't connect to SnapdLoginService from a snap <snapd-glib:Confirmed> <Snappy:New> <https://launchpad.net/bugs/1642669>
<lazyPower> didrocks: hey there. I made some progress but as we suspected i'm blocked on loading the plugins (despite the .so files being assembled and packed in the snap)  https://github.com/chuckbutler/snap-weechat/blob/master/snapcraft.yaml
<lazyPower> didrocks: If you have any ideas on that one, i'm keen to experiment
<jdstrand> seb128: ok, it is working
<seb128> jdstrand, great!
<didrocks> lazyPower: is there any way to point weechat to the directory where the .so files are?
<didrocks> lazyPower: I guess the only way is to dive into the code and see if that can set or patchs to be configurable :)
<didrocks> I guess -DCMAKE_INSTALL_PREFIX=/usr is what influences it
<lazyPower> yeah, i was surprised just defining the customopts flag forced me to set that, as it seems to be set inherently when using the flag in snapcraft.yaml (for the cmake builder)
<didrocks> yeah, I guess we are back in the issue on projects which forces to set prefix and we don't know the prefix in advance
<lazyPower> i'm sure there's a viable path forward here, i'm just nto familiar enough with the code base to make that call yet
<didrocks> a workaround is to set it to /snap/<yoursnapname>/current/ but then, you will have /snap/<yoursnapname>/current/snap/<yoursnapname>/current/ directory when installed
<didrocks> and so, you will need to move it back on that
<lazyPower> hmm interesting
<didrocks> seb128: I don't remember, we raised this with Gustavo, right? did we get any feedback?
<didrocks> lazyPower: I would say experiment first that way, to see if this is coming from this, but there is big chance that's the issue
<seb128> didrocks, right, I think that's still an unresolved one...
<elopio> pitti: ping. To quickly solve the sudo errors on autopkgtest armhf I added needs-root to the tests. But Sergio tells me we can add a sudoer user without a password, and that confused me. How can we modify /etc/sudoers before the tests run?
<didrocks> lazyPower: so, if that works, I would suggest that you send an email to the ML and CC Gustavo (you can tell I denounced him :p), knowing that it was already discussed
<pitti> elopio: the test has root, so it can do anything to the testbed, including adding to /etc/sudoers.d
<elopio> pitti: that is if the test has needs-root. I would like to run the tests as a normal user, but be able to install debs. So should I do "su normal-user" after adding normal-user to sudoers?
<pitti> elopio: you can do that, or have a first "prepare" pseudo-test that runs as root and sets up sudoers, then the actual test can run as normal user
<Chipaca> alex-abreu: you're welcome! :-D
<pitti> whichever seems more appropriate
<lazyPower> sounds reasonable didrocks. will do
<didrocks> lazyPower: keep us posted!
<elopio> pitti: ok, I like the pseudo-test, I will try that. And last question (for now :), to try to understand. Why do we have passwordless sudo in the amd64 runners but not on this lxc armhf ones?
<pitti> elopio: apparently cloud-init sets up password less sudo, but lxc images don't by default
<pitti> s/cloud-init/cloud images/
<topi`> is there a good FAQ about the differences between Snaps and regular deb packages?
<topi`> I know there is some kind of container involved so that the Snap only sees a part of the filesystem
<elopio> pitti: got it. Thanks.
<topi`> If I look at developer.ubuntu.com/snappy/start, it seems there is a bunch of "supported HW" like DragonBoard or RPi or Intel NUC, however, if I have another board like the ODROID-C2, can it be supported as well?
<topi`> I guess what I want to ask, what's so special about these few boards?
<mup> Bug #1473218 changed: TMPDIRs are not cleaned out/are not correctly preserved across app invocations <Snappy:Fix Released> <https://launchpad.net/bugs/1473218>
<alex-abreu> Chipaca, mvo I updated the PR, I am not sure about the landing of this since the sections & empty find bits are still in staging AFAIK
<Chipaca> alex-abreu: what's staging do with empty find?
<alex-abreu> Chipaca, it changes a bit the semantics of it, it returns a list is 'featured' snaps
<Chipaca> alex-abreu: ah, that's done already? nice
<alex-abreu> Chipaca, yes
<Chipaca> alex-abreu: when does it get rolled out?
<alex-abreu> Chipaca, this is what I am trying to find out
<alex-abreu> Chipaca, mvo ok nessita just confirmed me that all those bits are in prob already
<alex-abreu> Chipaca, mvo I will test it now with the branch
<alex-abreu> & add a comment
<mvo> alex-abreu: aha, nice. so an empty find returns now the featured ones? thats great
<Chipaca> alecu: I can confirm prod just responded as I would expect to a snap/sections query
<alex-abreu> mvo, yes
<mvo> \o/
<alex-abreu> Chipaca, nice !
<nessita> \o/
<mvo> out of curiosity, what makes a snap featured?
<plars> I'm trying to add a .desktop and icon for a snap that I have, as apparently that's required by the review now? I've looked at some of the playpen snaps that do it and it looks like all they do is add a gui/setup dir in the project dir with those files in it. I've done that, and the snap seems to contain the files when I'm done, but I don't see an entry for
<plars> it when I search in unity. Should I?
<zyga> plars: depends on what's in the desktop file
<zyga> plars: look at /var/lib/snapd/destkop
<zyga> plars: we rewrite those desktop files after sanitization, if the rewritten one doesn't have an Exec line you won't find it
<plars> zyga: *sigh* apparently all I had to do was ask, because now it shows up and works perfectly, but it didn't a few minutes after I installed the snap
<zyga> plars: ah, that might be unity then
<plars> zyga: I'm guessing something needed to update
<plars> yeah
<alex-abreu> mvo, I am not sure, ...
<plars> zyga: thanks :)
<plars> zyga: what other sanitization do you do? All I did was add ${SNAP} to the path for the Exec and Icon lines.
<zyga> plars: I don't recall but we effectively rewrite the file, only allowing certain keys to show up
<mvo> alex-abreu: thanks, thats fine, just curiosity on my side
<zyga> plars: and we're extra careful with keys that have sensitive meaning
<Chipaca> alex-abreu: mvo: nessita: an empty search returns all
<plars> zyga: not sure what you mean, most of the one that is normally installed is translations of the name, otherwise just the exec, Icon, etc
<Chipaca> alex-abreu: can you make your branch keep the check for empty? then we can land the rest of it
<Chipaca> alex-abreu: or!
<Chipaca> hold on
<mvo> Chipaca: aha, that is what I saw earlier today, I got e.g. test-snapd-xkcd-webserver. I assumed this was just bad timming on my part
<Chipaca> how was this
<mvo> (and exactly 100 results)
<zyga> plars: there's whole zoo of keys, I don't think we allow translation yet, we mostly validate the exec line
<mvo> so it looked very much like before
<Chipaca> so what we want is:
<Chipaca> empty -> list sections
<Chipaca> no?
<plars> zyga: ok, I'll try it and see if review chokes on the translations. If so, I can always remove those
<Chipaca> that is, 'snap find' on its own list sections?
<Chipaca> then 'snap find --section' does the necessary thing
<alex-abreu> Chipaca, well no afaik, ...
<alex-abreu> Chipaca, (sorry otp now)
<Chipaca> hmm
<Chipaca> oh alright
<Chipaca> mvo: there's a "featured" section
<Chipaca> maybe empty find implies featured?
<mvo> Chipaca: yeah, that is what I would think
<alex-abreu> Chipaca, that's the idea I think
<mvo> snap find
<mvo> cool stuff
<Chipaca> mvo: http https://search.apps.ubuntu.com/api/v1/snaps/search X-Ubuntu-Release:16 Accept:"application/hal+json" X-Ubuntu-Architecture:amd64 X-Ubuntu-Wire-Protocol:1 section==featured | jq '..|.name?//empty'
<Chipaca> alex-abreu: ok, if your branch can do one of those two then we'd be sorted
<mvo> nice
<Chipaca> alecu: one of those two == revert to blocking empty, or search featured on empty
<Chipaca> alex-abreu: ^ you, sorry
<Chipaca> alecu: you're awesome, but i didn't mean to distract you with this
<alex-abreu> Chipaca, ... I'd have to reread all that, I'll do it when not otp
<Chipaca> alex-abreu: we're signing you up for cat facts while you're distracted. Just sign here: [ ]
<alex-abreu> Chipaca, I need to read the small prints
<alecu> Chipaca: am I?
 * alecu blushes...
<zyga> lool, jdstrand: https://github.com/snapcore/snap-confine/pull/185
<mup> PR snap-confine#185: Detach the hostfs version of /dev <Created by zyga> <https://github.com/snapcore/snap-confine/pull/185>
<cjwatson> icey: network access during build> don't have an exact timeline but we're agreed that we're going to do it and it will be soonish
<cjwatson> flexiondotorg: ^- FYI
 * cjwatson hadn't quite noticed how far backlogged he was
<kyrofa> cjwatson, excellent news :)
<alex-abreu> Chipaca, ok so I checked the store & PR for the empty find stuff, and it does seem to work as intended and defaults to the featured snaps list ...
<alex-abreu> Chipaca, for me, ... could you test again? or maybe I misunderstood your comments
<jamespage> jdstrand, hey any thoughts on my openvswitch-{support} naming question from earlier today?
<jdstrand> jamespage: sorry, I missed it. I'm looking at it. I'm wondering if this needs a separate interface. '/{,usr/}{,s}bin/nice ixr,' should be added to process-control and then you plugs: process-control. you could also plugs: network-control for sys_admin and netlink
<jdstrand> jamespage: run-parts is possibly part of the default template
<jdstrand> . jamespage that leaves sys_resource and @{PROC}/@{pid}/comm
<jdstrand> and maybe a syscall or two to investigate
<jdstrand> jamespage: I think you would then 'plugs: [ process-control, network-bind, network-control ]'
<Chipaca> alex-abreu: sorry, didn't see this. What do you want me to look at?
<Chipaca> alex-abreu: ah! just noticed the search without an empty q but also with an empty section returns featured
<alex-abreu> Chipaca, when doing a snap find, I do indeed default to a featured snap find ... which ends up sending a store request like search?q=&section= that the store interprets as 'return the list of featured snaps'
<alex-abreu> yes
<jdstrand> jamespage: capability sys_resource could go to process-control for setting rlimits
<Chipaca> i wish the api didn't do that, because it's very non-intuitive, but it does that, so i guess it's alright
<alex-abreu> which is not the same as search?q=
<alex-abreu> Chipaca, sort of agree, I talked to them about that and they seem to have specific backward compat reasons
<Chipaca> yeah, i am aware
<Chipaca> whine whine moan moan <-- me
<jdstrand> jamespage: '@{PROC}/@{pid}/comm r,' goes to default apparmor template
<zyga> jdstrand: one more https://github.com/snapcore/snap-confine/pull/186
<mup> PR snap-confine#186: Detach the hostfs version of /proc <Created by zyga> <https://github.com/snapcore/snap-confine/pull/186>
<jdstrand> jamespage: (use 'owner @{PROC}/@{pid}/comm r,' and put it under @{PROC}/@{pid}/cmdline)
<jdstrand> jamespage: yes, run-parts to default template
<jdstrand> jamespage: I think that will give you everything without needed a new interface
<flexiondotorg> cjwatson, Thanks for confirming.
<jdstrand> jamespage: I commented in the PR
<mup> Bug #1643220 changed: ubuntu terminal app (edge) Unrecognized OpenGL version <Snappy:Incomplete> <Ubuntu App Platform:New> <Ubuntu Terminal App:New> <https://launchpad.net/bugs/1643220>
<icey> cjwatson: cool! worked around it already but good news ;-)
<alex-abreu> Chipaca, thx for the +1, not sure I understand the spread failure though ... seems to be an infra failure?
<Chipaca> alex-abreu: yeah; restarted it
<alex-abreu> thx
<alex-abreu> Chipaca, does it auto lands when the PR is +1d ?
<jdstrand> niemeyer, mhall119, seb128: fyi, https://github.com/snapcore/snapd/pull/1613 is now ready for review
<mup> PR snapd#1613: interfaces/builtin: add dbus interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
<davmor2> Chipaca: hey dude I installed the terminal app from edge and it told me to install ubuntu-app-platform did that connected them and it still throws up the same error to install the platform and connect them is there anything I can do to check the issue?
<davmor2> hmm snap interfaces shows the connection so now I'm confused
<ssweeny> wasn't there some bug where if you ran an app without a content interface connected you had to reinstall the app before it would work?
<jdstrand> tyhicks: hey, do you have 5 minutes to discuss something? if not or discussing later is totally fine
<tyhicks> jdstrand: hey, sure
<jdstrand> let me get you a paste
<jdstrand> tyhicks: the context is https://github.com/snapcore/snapd/pull/1613
<mup> PR snapd#1613: interfaces/builtin: add dbus interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
<jdstrand> tyhicks: http://paste.ubuntu.com/23513083/
<jdstrand> tyhicks: it'll be easier to look at the resulting policy
<tyhicks> ok
<jdstrand> tyhicks: what this paste contains is the (relevant portions of the) dbus rules for the dbus app interface
<jdstrand> tyhicks: the context is gnome-logs slots this interface so it can bind to a well-known name. there are some classic rules and then d-feet rules which plugs the gnome-logs slot
<jdstrand> tyhicks: the first 3 rules are what one would expect
<jdstrand> tyhicks: the 4th is slightly interesting with this path: path="{/,/org,/org/gnome,/org/gnome/Logs}"
<jdstrand> tyhicks: well, the 4th is a classic rule, it gets more interessting with the slot rules
<jdstrand> tyhicks: go to line 40
<jdstrand> tyhicks: that path has path="{/,/org,/org/gnome,/org/gnome/Logs}"
 * tyhicks nods
<lof_mt> Hi there. I am trying to get a gtk3 app packaged as snap. It compiles and builds the package. But when i start the snap the application complains about gsettings schemes not being installed.
<jdstrand> tyhicks: this is a slight info leak if /org or /org/gnome had things to introspect, but it is only a leak on what the gnome-logs service might be setting up
<jdstrand> tyhicks: ie, if gnome-logs had things to introspect on /org or /org/gnome, then d-feet could see it. it isn't a big deal. just wanted to mention it
<lof_mt> Here the last-1 version of the snapcraft file. I added the gtk part recommended in the answer to the issue: https://github.com/jangernert/FeedReader/issues/268
<jdstrand> tyhicks: what I really wanted you to see was the last two rules
<tyhicks> jdstrand: I'm not too worried about the rule at line 40
<jdstrand> tyhicks: note that one has an interface= but no path= and the other a path= but no interface=
<jdstrand> tyhicks: yeah, me either-- it is just slightly imperfect-- a plugging client could plugs all of the gnome-logs api so it isn't a big deal
<tyhicks> ok, thinking about those last two..
<jdstrand> tyhicks: I don't think these last two are problematic either-- everything is bound to labels, etc, it is just a bit different that most rules
<jdstrand> tyhicks: there reason why I did that is that apps use the org.freedesktop.* interface but with paths at /org/gnome/Logs
<seb128> jdstrand, thanks for working on that! I'm done for today but I'm going to have a try tomorrow
<jdstrand> tyhicks: but then I've seen a lot of apps that use '/' as the path with their foo.bar.blah interfaces
<jdstrand> seb128: thanks!
<jdstrand> seb128: I can promise that gnome-logs works ;)
<seb128> :-)
<jdstrand> tyhicks: so I was trying to allow both things in a way that still limited by well-known name
<jdstrand> tyhicks: hence the slightly unconventional rules
<tyhicks> jdstrand: like you said, the peer label is the most important thing
<jdstrand> tyhicks: in other words, if I did 'interface="org.gnome.Logs{,.*}" path="/org/gnome/Logs{,/**}"' in the same rule, I was confident we'd hit stuff that would break
<tyhicks> right
<jdstrand> tyhicks: yes, and also, this is only a snippet from the slot implementation. the plugging side has peer labels to snap.gnome-logs-udt.gnome-logs-udt
<jdstrand> tyhicks: so it is very tightly bound to these two snaps, but hopefully flexible enough to allow some compatibility
<tyhicks> jdstrand: so you don't feel like you can foresee all of the possible paths that might be used?
<jdstrand> tyhicks: oh gosh no. this interface is about "let the snap talk to that other snap's entire DBus api via that well-known name"
<jdstrand> tyhicks: but trying to have enough rules to say 'the command can access this org.foo.bar api and this command that org.foo.baz api"
<jdstrand> tyhicks: I think it achieves it and it is safe, but wanted to run it by you since it is slightly unconventional
<jdstrand> the one with just the path rule is nice cause you can get and set properties but only to /org/gnome/Logs (and deeper)
<tyhicks> jdstrand: I don't see a problem. We're just trying to restrict communication between two known endpoints and those rules do just that.
<jdstrand> tyhicks: cool-- me either but second pair of eyes is nice :)
<jdstrand> tyhicks: thanks!
<tyhicks> jdstrand: thanks for running it by me
<jdstrand> tyhicks: that might've been closer to 10 minutes, sorry :)
<tyhicks> no worries :)
<lof_mt> ping, flexiondotorg: https://paste.ubuntu.com/23513341/ this builds on 16.10 but lacks gsettings schemas. How do i get them in there?
<_markfeatherston> How does an ubuntu core device get automatically updated with the latest snaps?  Does this need something like a cron job to kick off updates, or is it handled automatically some other way?
<Chipaca> _markfeatherston: right now it's "something like a cron job"
<Chipaca> _markfeatherston: serious, curious question: why do you care?
<Chipaca> (asking because it might change)
<_markfeatherston> I just added support for our TS-4900/TS-7970/TS-TPC-7990 devices.
<_markfeatherston> I'm going to have customers asking me how this would work
<Chipaca> _markfeatherston: systemd has timers, which is like cronjobs but rather more expressive
<_markfeatherston> We have  few real application use cases too, as long as there is some way to control when or how often it happens that would be enough
<Chipaca> _markfeatherston: we use that
<_markfeatherston> Ahh, ok
<nacc> https://developer.ubuntu.com/en/snappy/guides/autoupdate/, maybe helps?
<nacc> not sure if that is current, but it seems like it might be for this case
<Chipaca> nacc: that's for 15.04
<nacc> Chipaca: ah ok
<Chipaca> interestingly I wouldn't know that just from the url
<nacc> right :)
<_markfeatherston> another more basic question, after I go through the device configuration and connect through ssh is that the only way to connect to the device?
<_markfeatherston> The serial port starts getty which has a login prompt, but I'm not sure what if any accounts allow login like that
<_markfeatherston> I understand I can likely add my own users, I'm just trying to understand what happens by default
<mup> PR snapcraft#922 opened: On gradle unit tests, unset the proxies <Created by elopio> <https://github.com/snapcore/snapcraft/pull/922>
<kyrofa> _markfeatherston, man your nick is hard with the leading underscore :P
<kyrofa> _markfeatherston, indeed, initially the only way to connect is via the SSH keys
<kyrofa> _markfeatherston, this is to prevent marai ;)
<_markfeatherston> lol, i'll have to look into fixing that.
<_markfeatherston> thanks
<_markfeatherston> Last one for now, are there any plans to facilitate remote connections behind NAT or anything to manage remote units?
<kyrofa> _markfeatherston, I suspect this is (or will be) integrated into Landscape somehow
<_markfeatherston> that would be useful
<Chipaca> _markfeatherston: once you ssh in you can use 'passwd' to then use the gettys, fwiw
<icey> how does one get the namespace (snap-package.app) removed, so that it's run at just the app name?
<kyrofa> icey, if app name == snap name, you can just use snap name
<kyrofa> icey, but that's the only way
<kyrofa> icey, otherwise there's no way to prevent conflicts
<icey> ah, so make the name the same?
<kyrofa> icey, indeed, if snap name = foo and app name = bar, then you need to use foo.bar. But if app name = foo, then you can just use foo
<icey> great, thanks!
<icey> separate question, any chance for a review on https://github.com/snapcore/snapcraft/pull/908 now that tests are passing?
<mup> PR snapcraft#908: Let Rust plugin fetch dependencies in pull <Created by ChrisMacNaughton> <https://github.com/snapcore/snapcraft/pull/908>
#snappy 2016-11-22
<mup> PR snapcraft#922 closed: On gradle unit tests, unset the proxies <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/922>
<tsimonq2> cwayne: Quick, propose that your snap be merged: https://github.com/atom/atom/pull/13293
<mup> PR atom/atom#13293: Add Flatpak support <needs-review> <Created by mattdangerw> <https://github.com/atom/atom/pull/13293>
<tsimonq2> :P
<hades007> how to put an apparmor profile in complain mode with ubuntu core 15.04 ? sudo  "apparmor_parser -rC /var/lib/apparmor/profiles/click_lxd_lxc_2.0.5-1" doesn't to work
<foxmask> bonjello
<dholbach> hey hey
<mup> Bug #1643816 opened: improve systemd configuration support <Snappy:New> <https://launchpad.net/bugs/1643816>
<markusfluer> Good morning,
<markusfluer> How would I set the prefixes for nginx in a snap?
<markusfluer> Or should they be just untouched and let autotools manage them
<zyga> markusfluer: hey, you can try to set the prefix to /snap/nginx/current/ and use organize to strip that path from installation
<zyga> markusfluer: as snapd will ensure that at runtime the content of your snap is visible from that location
<markusfluer> zyga: Thank you very much.
<zyga> markusfluer: I don't remember how to use organize to do this though,
<zyga> markusfluer: experiment on hello world or something that builds quickly
<zyga> markusfluer: and when you do, please share
<markusfluer> zyga: I will try it out and comment it in the snapcraft.yaml.
<markusfluer> I will publish it on github anyway
<zyga> thanks
<didrocks> zyga: I thought we shouldn't hardcode /snap though?
<didrocks> this is what niemeyer told multiple times
<didrocks> (but we don't have any other answer AFAIK)
<zyga> didrocks: well, once we get a better answer people can adapt
<zyga> didrocks: walk, run, fly :)
<mup> PR snapcraft#923 opened: WIP pluginhandler: source management moved to the core <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/923>
<jon___> hi I've just followed the ubuntu core setup steps, all ok until it now asks for a login and password, any ideas what this is for an initial boot?
<mup> Bug #1643885 opened: ubuntu core image has different content between archs <Snappy:New> <https://launchpad.net/bugs/1643885>
<mup> Bug #1643888 opened: first snap try doesn't install core snap <Snappy:New> <https://launchpad.net/bugs/1643888>
<jdstrand> tedg: hey, if I wanted to file a bug against the results of locking snaps to the unity7 launcher, where would I file it?
<tsdgeos> maybe someone should try to approach Valve since they seem to be leaning to trying flatpack https://forums.xamarin.com/discussion/comment/232301/#Comment_232301 maybe they can be convinced to use snappy
<mup> Bug #1643893 opened: snapd doesn't handle well flaky network <Snappy:New> <https://launchpad.net/bugs/1643893>
<jdstrand> JamieBennett, dholbach: fyi tsdgeos comment ^
<Trevinho> jdstrand: what's the bug?
<Trevinho> jdstrand: anyway... unity project I guess, but it depends...
<jdstrand> Trevinho: I'm trying to find a simple reproducer
<Trevinho> jdstrand: ok, ping me once you've it
<jdstrand> Trevinho: basically what I see happen sometimes is that when I lock to the launcher, /snap/<name>/path/to/exe is used instead of /snap/bin/name
<jdstrand> Trevinho: which is a pretty serious security bug because /snap/<name>/path/to/exe runs outside of confinement
<Trevinho> jdstrand: I guess that's because the app didn't match properly to something, right?
<Trevinho> jdstrand: howver, that's BAMF..
<Trevinho> jdstrand: like you're running a snap from a shell, then you try to lock it, right?
<seb128> tsdgeos, that's probably something worth mentioning on the snappy mailing list, IRC backlog info is likely to get lost
<jdstrand> Trevinho: I guess?? tbh I've never, ever, ever understood how that matching was supposed to work, no matter how hard I tried
<jdstrand> Trevinho: that is one scenario. I've also launched from the dash and seen the same thing
<jdstrand> Trevinho: but not everything. eg, vlc is working fine
<Trevinho> jdstrand: so..... I asked multiple times to include inside the wrapper script a BAMF env variable that points to the actual desktop file when possible...
<mup> Bug #1642900 changed: libgcc_s.so.1 not found by app using ubuntu-app-platform content snap <Ubuntu App Platform:New> <https://launchpad.net/bugs/1642900>
<Trevinho> jdstrand: so, in case that there's no other way to match the app, then we try to undestand what binary launched it... Thus the problem you mentioned. This actually worked well in non snap-world. But I guess we've to tune it too
<Trevinho> jdstrand: have a look to this though: https://github.com/snapcore/snapd/pull/1580#issuecomment-234546220
<mup> PR snapd#1580: wrappers: set BAMF_DESKTOP_FILE_HINT for unity <Created by mvo5> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/1580>
<Trevinho> jdstrand: if that was done in the wrapper script, then it would fix also the issue you're talking about
<Trevinho> indeed we've to cover also the case where a desktop file is not provided, and avoid doing what you mentioned, but this would b already a good point
<jdstrand> Trevinho: maybe I will file a bug against snapd then
<jdstrand> Trevinho: then point you at it for comment?
<Trevinho> jdstrand: ok
<JamieBennett> Trevinho, jdstrand, After a quick search I see no confirmation of Valve using flatpak atm, just a bunch of very vocal non-Valve people talking about flatpak and discounting snaps for no apparent reason than it comes from Canonical (which is try but is also wrong as the snap format is governed outside of Canonical). ev_, dholbach, or popey may have more context though.
<Trevinho> jdstrand: here there's more context https://trello.com/c/xP1hN3BF/152-improve-desktop-file-support-by-adding-a-new-bamf-desktop-file-hint-environment-hint
<dholbach> I don't have much info on valve's use of snaps.
<popey> me either
<tsdgeos> seb128: i'm not on that list i think
<tsdgeos> seb128: what's the list name/address/mailman/thing?
<seb128> tsdgeos, seems JamieBennett is on the topic since he just mentioned it so I guess you can consider it as something the snappy team is aware of and probably no need to email the list
<tsdgeos> ok :)
<jdstrand> JamieBennett, dholbach: I think tsdgeos point was that perhaps we should be proactive rather the reactive, but I'll leave it in your hands
<JamieBennett> jdstrand, understood
<mup> Bug #1643910 opened: BAMF_DESKTOP_FILE_HINT not set in correct place for unity7 <Snappy:New> <https://launchpad.net/bugs/1643910>
<jdstrand> Trevinho: ^
<Trevinho> ack
<jdstrand> mvo: fyi, I think bug #1643910 needs attention sooner than later. it can result in snaps running unconfined under certain circumstances under unity7
<mup> Bug #1643910: BAMF_DESKTOP_FILE_HINT not set in correct place for unity7 <Snappy:New> <https://launchpad.net/bugs/1643910>
<mhall119> jdstrand: panteon-mail needs #1590679, and so do most (or all?) KDE apps.
<mup> Bug #1590679: Apps can't own session bus names (unity7 interface) <snap-desktop-issue> <snapd-interface> <Snappy:In Progress by jdstrand> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1590679>
<mhall119> sitter has said that it's the only blocker for most of his KDE snaps
<mhall119> some of them have other blockers, but the simple ones just need that
<jdstrand> mhall119: are there devmode apps for these things?
<jdstrand> mhall119: I guess panteon-mail is devmode? are there any KDE apps that want to talk to each other?
<jdstrand> sitter: ^
<mhall119> jdstrand: I think they use dbus to talk to themselves (to prevent multiple instances) or with the plasma shell, but sitter can give better info
<mhall119> jdstrand: http://distribute.kde.org/snappy-testing/ has all their CI builds of snaps
<jdstrand> sitter: do any two snaps in http://distribute.kde.org/snappy-testing/ want to talk to each other?
<ppisati> ogra_: have you ever happened to build a kernel snap from -proposed?
<ogra_> ppisati, sure, all the time (for rpi) ... but it indeed only works if meta and the kernel are in sync (i'm on vacation btw ;) )
<ppisati> ogra_: ah. stay in vcation then
<ogra_> heh
<ppisati> ogra_: because even if i ticked 'use proposed for the build' it picked only stuff from -updates
<ppisati> ogra_: when you are back?
<ogra_> next monday ... you need to add proposed in the tree too iirc
<ogra_> ppisati, there is code to copy the sources.list from the outer build root to the inner one http://bazaar.launchpad.net/~snappy-dev/kernel-snap-makefile/trunk/view/head:/Makefile#L19 ... so you need to make sure our outer chroot has proposed
<ppisati> ogra_: "cp /etc/apt/sources.list chroot/etc/apt/sources.list" - yeah, i saw that, and my build was against -proposed
<ppisati> ogra_: so i expected it to be enabled
<ppisati> Pocket for automatic builds:
<ppisati>     Proposed
<ppisati> ogra_: anyhow, you are on vacation so i won't bother anymore
<ogra_> but the PPA isnt ... (whiczh you need additionally)
<ogra_> here is some other code ... http://bazaar.launchpad.net/~ogra/+junk/kernel-snap-makefile-proposed/view/head:/Makefile
<ogra_> (see line 24/25)
<ppisati> ogra_: i see
<ogra_> you coudl add a config file to the outer branch (the one with snapcraft.yaml) and then read a flag to make that dynamically switchable
<gerry_> hi, i have succesfully uploaded my app to the snap store, what is the best way to edit its entry in "Software" ?
<didrocks> gerry_: hey! I would say try to go to myapps.ubuntu.com and edit entries there (not sure you can edit them all those)
<mvo> jdstrand: let me read the bug again
<jdstrand> Trevinho: I think there may be a unity7 component to that. please see my comments and add the tasks if you feel it is appropriate
 * Trevinho checks
<Trevinho> jdstrand: ah, since I wanted to try your new interfaces... I tried to compile snapd but it seems it failed here... So, isn't there a daily ppa or something?
<gerry_> didrocks:  thanks for your help its just at the moment all I have got is "version unknown, source unknown and nonfree!
<didrocks> gerry_: oh right, you should edit them thus! :)
<jdstrand> Trevinho: I think so, I don't know where it is
<jdstrand> mvo: ^
<jdstrand> Trevinho: refresh to see comment #5 as well
<jdstrand> I feel like there are multiple things happening
<jdstrand> like, maybe if things match (eg, vlc and gnome-easytag) things work, but if they don't, items are created in ~/.local/share/applications
<mvo> Trevinho: please make sure you ran ./get-deps.sh to ensure your stuff is up-to-date
<elopio> vila: ping. Have you seen this? bzr: ERROR: Connection error: while sending POST
<jdstrand> Trevinho: ok, and comment #6
<jdstrand> ah, you're notified, so I'll stop pinging you here
<vila> elopio: that single line rings no bell, more context ?
<mup> PR snapcraft#924 opened: New plugin: jhbuild <Created by attente> <https://github.com/snapcore/snapcraft/pull/924>
<mup> PR snapcraft#812 closed: New plugin: jhbuild <Created by attente> <Closed by attente> <https://github.com/snapcore/snapcraft/pull/812>
<elopio> vila: http://paste.ubuntu.com/23517256/ All our bzr test in arm are failing in a similar way.
<vila> elopio: bzr: ERROR: Connection error: while sending POST /~joetalbott/%2Bjunk/testpart/.bzr/smart: [Errno 110] Connection timed out
<vila> elopio: firewall issue ?
<jdstrand> willcooke, JamieBennett: fyi, bug #1643910. both mvo and Trevinho are aware of it so fyi only. this is a pretty significant usability and security bug when it hits. Please see my comments as well as the description
<mup> Bug #1643910: BAMF_DESKTOP_FILE_HINT not set in correct place for unity7 <Snappy:Triaged> <bamf (Ubuntu):Triaged by 3v1n0> <https://launchpad.net/bugs/1643910>
<jdstrand> ratliff, tyhicks: also, fyi ^
<jdstrand> willcooke, JamieBennett: not saying anything needs to be done more than what they are already working on, but wanted you guys to be aware of the unpredictable behavior and security implications
<jdstrand> so that the bug doesn't get deprioritized
<jdstrand> ok, is done with that bug for now :)
<lof_mt> hi flexiondotorg can you spare some minutes right now?
<jdstrand> mhall119: fyi, panteon-mail is not in the store
<flexiondotorg> lof_mt, In a meeting. Give me 30mins...
<jdstrand> mhall119: do you know which of the snaps in http://distribute.kde.org/snappy-testing/ work? kmahjongg for example does not
<mhall119> jdstrand: try kblocks
<mhall119> or ktuberling
<jdstrand> neither does ktuberling
<jdstrand> $ ktuberling
<jdstrand> /snap/ktuberling/x1/bin/qt5-launch: line 75: /snap/ktuberling/x1/usr/games/ktuberling: No such file or directory
<jdstrand> ok, I'll try kblocks
<elopio> vila: perhaps. But in theory, the rules should be the same for all these machines, and it doesn't happen in amd64. I will ask IS anyway.
<elopio> thanks!
<mhall119> jdstrand: kblocks and ktuberling are both also in the edge channel of the store
<jdstrand> mhall119: kblocks fails
<mhall119> ok, maybe it's an issue with those builds
<jdstrand> kalgebra launched
<jdstrand> mhall119: what is the name of the platform snap again?
<jdstrand> mhall119: for kde. ktuberling is 5M and is complaining about not finding kde libs
<jdstrand> snap find is not helping
<Elleo> jdstrand: heya, would you mind giving this a review when you have a chance? https://github.com/snapcore/snapd/pull/2328
<mup> PR snapd#2328: Add download manager interface <Created by Elleo> <https://github.com/snapcore/snapd/pull/2328>
<jdstrand> kde-frameworks-5?
 * jdstrand tries
<jdstrand> Elleo: ok, I'll add it to the list
<Elleo> jdstrand: thanks :)
<mhall119> jdstrand: yes, from --edge
<mhall119> snap find won't help,  because they're not in stable
 * jdstrand nods
<jdstrand> seems like kde-frameworks-5 could've been in stable...
<gerry_> I have filled in all the forms at myapp.ubuntu but for some reason it does not appear in my entry in "software" do I have to change how its listed in my yaml somehow?
<mhall119> jdstrand: maybe, but without stable app snaps there wouldn't be much point
<jdstrand> mhall119: fyi, installing that and making the interface connection results in the same issue
<jdstrand> mhall119: I have to /usr/lib/snapd/snap-discard-ns ktuberling for it to work
<gerry_> or do I have to find a way to re-publish my app?
<kalikiana_> gerry_: doesn't appear meaning what? it's not listed at all?
<kalikiana_> how did you upload it?
<kalikiana_> can you see it in myapps in the list?
<icey> how long does stuff usually take to get from master on github to Launchpad builders?
<kyrofa> icey, you mean with git-to-git imports?
<icey> kyrofa: I mean: once a patch to snapcraft lands, how long does it usually take before the patch is in the launchpad snappy builders?
<kyrofa> icey, ah ha
<kyrofa> icey, well, the release process of snapcraft involves an SRU. Are you familiar with that?
<kyrofa> icey, long story short, about a week or so
<icey> kyrofa: yea
<icey> kyrofa: that's a nice timeline ;-) any chance for a review on my PR? https://github.com/snapcore/snapcraft/pull/908
<mup> PR snapcraft#908: Let Rust plugin fetch dependencies in pull <Created by ChrisMacNaughton> <https://github.com/snapcore/snapcraft/pull/908>
<kyrofa> icey, snapcraft releases weekly, with a little slosh for SRU
<kyrofa> icey, don't worry, we'll go back through it!
<icey> heh kyrofa, it should have everything asked for now, and it's passing tests :)
<kyrofa> Excellent
<icey> I'm hoping to get it in soonish, since I wrote about it and started talking about it to the Rust community :)
<icey> kyrofa: and apparently people are interested: https://www.reddit.com/r/rust/comments/5e754t/making_rust_packages_for_linux_with_snappy/
<kyrofa> icey, good to hear!
<lof_mt> ping flexiondotorg
<flexiondotorg> lof_mt, Hi there :-)
<flexiondotorg> What's up?
<lof_mt> do you have a bit of time to help me with the gsettings problem?
<gerry_> kalikana: sorry phone call
<flexiondotorg> lof_mt, I can try.
<flexiondotorg> What is the issue?
<lof_mt> flexiondotorg: This is the current snapcraft file: https://paste.ubuntu.com/23513341/
<lof_mt> builds well under 16.10 (maybe on 16.04 too not sure about gtk).
<mvo> jdstrand, Trevinho: I was a bit busy before but now I looked at the BAMF_DESKTOP_FILE_HINT issue. I'm not sure how what the behavior should be, what if the snap installs multiple desktop files that launch the same binary (say libreoffice with libreoffice --writer). trying to match what desktop file to pick sounds fragile. I think I could support the easy case but it seems far from ideal
<lof_mt> But the application crashes when run, because it lacks gsettings schemas. And i could not find documentation about how to include it.
<didrocks> lof_mt: you are using the desktop-gtk3 cloud parts
<flexiondotorg> lof_mt, The first thing I notice is that you don't have any stage packages.
<gerry_> it is listed there is just no summary or details all it has is "version unknown source unknown"
<didrocks> lof_mt: all doc is on snapcraft define desktop-gtk3
<mvo> jdstrand, Trevinho: e.g. "Exec=libreoffice --writer " and the user uses "libreoffice ~/some/doc --writer" , the parser would have to understand about reordering of args,  etc and probably stll get it wrong because for some apps reodering is legal for some its not etc
<didrocks> basically you need:
<didrocks> - the home plug for gsettings
<didrocks> - and prepend your command with desktop-launcher
<didrocks> desktop-launch*
<didrocks> flexiondotorg: he doesn't need all stage-packages, the desktop part provides most of them (but yeah, maybe more will be needed)
<flexiondotorg> Yep.
<lof_mt> didrocks: What do you mean with "the home plug for gsettings"? I have both the home plug and the gsettings plug for the application.
<didrocks> lof_mt: oh sorry, as they were not in ascii ordered, I missed it, yeah, you are good for that one :)
<didrocks> you only miss desktop-launch prepending thus
<flexiondotorg> lof_mt, I tried to build in lxd. You're missing dependencies.
<flexiondotorg> Check the Cmake output.
<lof_mt> Do you use the cloud or container image? I only checked with desktop and server.
<mvo> jdstrand, Trevinho: followed up in the bug, happy to implement naive matching in snap run if that helps but see the bugreport for my questions
<kyrofa> zyga, ping
<flexiondotorg> lof_mt, I used 'snapcraft cleanbuild' which requires you have lxd installed.
<flexiondotorg> It provisions a temporary lxc container to build the snap in.
<lof_mt> will test that
<lof_mt> When can you omit the bin/ in command:? I saw it in the leafpad example. https://github.com/ubuntu/snappy-playpen/blob/master/leafpad/snapcraft.yaml
<rvr> ogra_: fgimenez: Are you aware of any problem with edge and pi2/pi3? I can't boot any image (Waiting for ethernet connection... unable to connect)
<fgimenez> rvr, i haven't worked with it in a while, i'll give it a try and let you know how it goes
<mhall119> jdstrand: I'm afraid you'll have to get sitter or sgclark to help you here, they know the apps better than I do
<willcooke> jdstrand, ack re: #1643910.  thanks
<mup> Bug #1643910: BAMF_DESKTOP_FILE_HINT not set in correct place for unity7 <Snappy:Triaged> <bamf (Ubuntu):Triaged by 3v1n0> <https://launchpad.net/bugs/1643910>
<lof_mt> the lacking dependency was "gettext".
<dslul> Hello, may I ask you, is the raspberry pi3 core16 image still 32bit only?
<ogra_> dslul, yes
<ogra_> (the 64bit one eats a lot more ram and you might be missing driver support for binary stuff ... there will be a 64bit image at some point, but thats rather low prio)
<mattyw> cprov, ping?
<cprov> mattyw: hi there
<jdstrand> niemeyer: no rush, just fyi that I responded to your question in the pr
<jdstrand> niemeyer: (and hi! :)
<niemeyer> jdstrand: Heya
<niemeyer> jdstrand: Looking
<niemeyer> jdstrand: Your idea of allowing the alternation seems like the best option
<niemeyer> jdstrand: So we have name: org.foo.bar, and it only matches against another org.foo.bar, but it's okay to use an interface with (-[0-9]*)?
<niemeyer> actually, (-[0-9]+)?
<stgraber> jdstrand: heya, sorry to nag but have you heard back from the store deploy (or whatever was needed) to have the "lxd" slot work on the lxd snap? had a few people ask about that interface lately as it was mentioned in some recent blog post...
<plars> elopio: is there a built-in kill timeout on spread? I seem to be hitting that while it's still installing packages on dragonboard, so it can't even get to the first tests because it kills it too soon
<lof_mt> Is there something built in to deploy gsettings schemas? Or do i need to add it to the launcher like in the plank example? â https://github.com/ubuntu/snappy-playpen/blob/af7154cc9cac61d55b17c4aa9517c4d7c003a1a0/plank/launcher
<icey> kyrofa: I'm working on cutting out build-essential from the Rust plugin now
<icey> kyrofa: looks like it's generally suggested to do build-essential though: https://users.rust-lang.org/t/installation-problem-on-debian-cc-linker/6192
<jdstrand> niemeyer: yes. I committed some changes to show how it works
<jdstrand> roadmr: hey, what revision is the store at now?
<icey> kyrofa: pushed change without build-essential; does t he build environment for Snapcraft's CI look like the Launchpad builders?
<jdstrand> roadmr: nm
<jdstrand> stgraber: it looks like the store now has r798 of the review tools, so I'll update the lxd snap declaration.
<jdstrand> stgraber: ok done. feel free to upload
<stgraber> jdstrand: thanks
<kkimdev> Q: is there a way to install a snappy package without root?
<niemeyer> jdstrand: This looks super verbose: +    name=###DBUS_NAME###-{[1-9],[1-9][0-9],[1-9][0-9][0-9],[1-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9][0-9]},
<niemeyer> jdstrand: Is that the best we can have with apparmor?
<niemeyer> jdstrand: What's the actually supported syntax there?
<jdstrand> niemeyer: it is very precise to match pids. the aare is not normal regex
<jdstrand> niemeyer: so, yes, that is the best
<jdstrand> niemeyer: I mean, we could be less precise, but since we are trying to support pids, I went with very precise
<niemeyer> jdstrand: That's good. The question was really if there wasn't richer syntax we could (ab)use
<jdstrand> niemeyer: unfortunately, no. the aare is quite flexible but it has its rough spots
<niemeyer> jdstrand: Can we nest {}?
<niemeyer> Actually, we don't even have to
<niemeyer> jdstrand: -[1-9]{,[0-9]}{,[0-9]}{,[0-9]}{,[0-9]}{,[0-9]}
<jdstrand> I don't think that is going to eveluate right. note that I stole this from the apparmor upstream tunable for @{pid}
<jdstrand> yes, that won't evaluate right
<jdstrand> well, maybe
 * jdstrand thinks
<jdstrand> actually, it looks like it would. let me test something
<jdstrand> yeah, that's fine
 * jdstrand adjusts
<niemeyer> Nice, thanks
<niemeyer> jdstrand: Why the deny-connection in the base-declaration?
<mup> Bug #1618095 changed: [SRU] 2.14.2 <verification-done> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1618095>
<dslul> hello, I installed ubuntu core 16 on my raspberry pi3, is it possible to configure it only via ssh? what are the login credentials?
<roadmr> jdstrand: ... yes, 798.
<roadmr> jdstrand: are you now using snap-declaration plugs/slots for lxd? \o/ Let me know how it works :)
<roadmr> jdstrand: I used it for a test snap from the checkbox folks, seems to be working nicely
<jdstrand> roadmr: yes, I just added a snap declaration for the lxd snap
<roadmr> awesome :)
<jdstrand> well, for the slots side. it already had the plugs side
<niemeyer> jdstrand: Sent a review
<dslul> Is it possible to do the initial configuration of Ubuntu Core using ssh and not with a usb keyboard and a screen?
<dslul> I see that the ssh daemon is running, but I don't know the credentials
<stgraber> jdstrand: lxd snap updated in all channels for the new slot
<jdstrand> stgraber: nice! :)
<dslul> nobody knows the answer?
<mwhudson> dslul: no,  it is not
<mwhudson> dslul: you can do it using serial as well
<dslul> how can I do it using serial?
<dslul> I mean, I know how to connect to a serial, but what then?
<mwhudson> dslul: press enter when connected and it should work the same way as a the tty
<dslul> ok thank you very much, I'll try this
<kyrofa> icey, sorry for the delay, I was finally getting my couches delivered after nearly three months!
<kyrofa> icey, I wouldn't rely on the snapcraft test infra being as vanilla as the LP builders-- you might want to double check there. But honestly, just make a clean lxc or run cleanbuild
<kyrofa> And you should be able to determine if you've satisfied dependencies
<wililupy> Question: Is there a specific reason why in the grub.cfg we use net.ifname=0?
#snappy 2016-11-23
<mup> Bug #1644058 opened: Different behaviour in MPRIS interface with local install vs store install <Snappy:New> <https://launchpad.net/bugs/1644058>
<icey> kyrofa: I just pushed the plugin (as a custom plugin) to my launchpad build and it worked :)
<alesage> n00b question but what am I missing whilst trying to install this snap in a KVM http://paste.ubuntu.com/23519901/
<nacc> alesage: hrm, sudo?
<nacc> alesage: not sure, though
<alesage> nacc let me get another paste thx
<alesage> nacc appears the same FWIW http://paste.ubuntu.com/23519955/ (except for using sudo)
<nacc> alesage: sorry, dunno, hopefully somoene else can help out
<alesage> nacc thanks regardless :)
<liuxg> I have a sample project using content sharing. It is a Qt project at https://github.com/liu-xiao-guo/rssreader_platform. After I run the project, i get the error like "This application failed to start because it could not find or load the Qt platform plugin "xcb". Does anyone know what is missing there? thanks
<mup> Bug #1644074 opened: auto connect none auto-connect interfaces of snaps in gadget snap <Snappy:New> <https://launchpad.net/bugs/1644074>
<zyga> kyrofa: hey
<zyga> good morning
<dholbach> hey, good morning
<foxmask> bonjello
<didrocks> hey foxmask
<foxmask> didrocks: o/
<vigo> fgimenez, morning :)
<fgimenez> hey vigo :)
<vigo> fgimenez, do we need buildging our own images? or have you a link to download the images for this release?
<fgimenez> vigo, no download link yet, we should use images built from edge
<vigo> fgimenez, ack
<jibel> fgimenez, when I build a pc-amd64 image I get this http://paste.ubuntu.com/23521249/
<jibel> fgimenez, do you know what this error is?
<jibel> on zesty with ubuntu-image from edge
<fgimenez> jibel, iirc the right ubuntu-image is on beta, works fine here
<fgimenez> jibel, from snap list "ubuntu-image      0.10+real1  25   canonical  devmode"
<jibel> okay, I'll try this version
<fgimenez> jibel, ok it's working fine here for all platforms with snaps from edge
<jibel> fgimenez, with 0.10 from beta http://paste.ubuntu.com/23521264/
<jibel> ah, it works after working around the permission issue
<jibel> fgimenez, do you want a bug for the error with 0.12?
<fgimenez> jibel, ah nice, haven't seen that error before
<fgimenez> jibel, not sure about the error on 0.12, if it's not already reported, yes please :)
<jibel> I filed bug 1644131
<mup> Bug #1644131: ubuntu-image fails with: mkfs.ext4 - Invalid filesystem option set: has_journal,extent,huge_file,flex_bg,metadata_csum,64bit,dir_nlink,extra_isize <Ubuntu Image:New> <https://launchpad.net/bugs/1644131>
<gerry_> hi I uploaded my program yesterday how long until it appears in gnome-software?
<jamespage> morning all
<jamespage> what's the current story with snaps creating/using user/groups  other than root?
<jamespage> I'd like to not have to run openstack daemons that don't need to be root as root
<didrocks> jamespage: nothing really changed on that regard AFAIK
<didrocks> I guess you can link that to create user + override systemd unit files
<jamespage> didrocks, I can deal with the downgrade of privs in the wrapper stuff we have
<didrocks> good idea, indeed
<jamespage> didrocks, but I guess that means user/group have to be created outside of the snap right?
<didrocks> but creating a system user is possible, but manually though
<didrocks> yep
<jamespage> hmm
<gerry_> hi I uploaded my app yesterday and wondered how long it takes until it appears in software?
<didrocks> gerry_: normally, if software isn't broken, as soon as snap list lists it
<didrocks> there is no cache, snapd gives the results to it
<didrocks> snap find* sorry
<gerry_> oh I am getting no snaps  found at the moment is that normal for one day?
<didrocks> gerry_: no, but I heard software is broken for snaps unless ran as root
<gerry_> didrocks : sorry you have lost me are you saying my app is broken because.......?
<didrocks> gerry_: not your
<didrocks> "software"
<didrocks> yours*
<didrocks> so, just try:
<didrocks> sudo ubuntu-software
<gerry_> didrocks: oh I see my app will not run when trying to run it as root
<gerry_> thank you very much for your help it says it can't connect to x11 window server?
<didrocks> gerry_: did you try it in devmode first?
<didrocks> before figuring out confinement and such
<jamespage> this might seem like an odd question, but is there a good reason why the install_requires for snapcraft is not a complete set of runtime depends?
<jamespage> I'd like to use snapcraft from virtualenvs for check/gate in openstack infra but currently an install from git misses most of the requirements.txt file
<caribou> Hello, is this proper practice to create a snap with multiple apps sections ?
<caribou> if I do that, each supplementary apps has its command prefixed with the first apps command
<caribou> i.e. if I have a gtimelog snap with gtimelog as its first app, then rep_tl (a script) as the second app, the second will be named gtimelog.rep_tl
<seb128> caribou, yes that's normal
<seb128> the prefix is the snap name, not the first command name I think
<seb128> you only get away with cmdname = snapname if you want to avoid the prefix
<caribou> seb128: so basically multiple apps in the same snap are useless as each one will always be prefixed with the snap name
<seb128> it's a problem but stating that makes them useless is going a bit far
<seb128> users don't care much the name of the command especially if there is a desktop entry in the unity dash to start it
<caribou> seb128: yes, maybe, but if one wants more than one command inside a snap, there should be a way to alias it
<caribou> seb128: given that the snap is to be used on a desktop, that's a different story on a server
<seb128> caribou, I think the issue they have is to make sure you don't claim over a known name which is not yours
<seb128> like you could make your caribou_hack_ubuntu_users snap provide "firefox"
<seb128> which wouldn't be the real thing but your custom steal password version
<caribou> seb128: I understand, but if the snap name is the same as the deb based one (vlc comes to mind), then the problem persists
<seb128> what do you mean?
<seb128> if you have "vlc" snap it can have the "vlc" binary name/command
<caribou> installing the VLC snap will override the debianized version of VLC
<seb128> right
<caribou> ok, I should be able to hack around this; thanks!
<seb128> there is a way to register names though and random devs can't steal a known brand
<seb128> anyway, known issue
<caribou> seb128: yep, I know, I 'own' sosreport :-)
<seb128> :-)
<seb128> I think I saw the command name topic discussed in some of the recent mailing list discussions
<seb128> but can't find it now
<seb128> and I don't remember if they had a plan to address it and if so which one
<seb128> so maybe somebody else can help you a bit more
<seb128> but I think for now you have to deal with not having the name you might want
<dslul> on rpi3 and core 16, I am following this guide: https://developer.ubuntu.com/en/snappy/guides/mir-snaps, however ubuntu core cannot find the snap mir-libs...is it still available?
<gerry_> hi I my java app runs without problem until I try to run it as root then it crashes with this exception : "No protocol specified Exception in thread "main" java.awt.AWTError:  Can't connect to X11 window server"
<gerry_> my yaml is here http://pastebin.com/6E1VZAVG
<vigo> fgimenez, hey! 2 tasks failed running spread on i386
<vigo> They're probably known already
<vigo> https://pastebin.canonical.com/171576/
<vigo> but please check and let me know to be sure
<gerry_> hi when I try to run my java app as root it crashes with No protocol specified Exception in thread "main" java.awt.AWTError: Can't connect to X11 window server. Can anybody give me a tip on where to look thanks
<gerry_> here is a copy of my yaml : http://pastebin.com/6E1VZAVG
<fgimenez> vigo, looking, revert:production can be due to timeouts from the store, not sure about ubuntu-core-reboot
<vigo> fgimenez, spread -v -reuse -debug external:ubuntu-core-16-arm-64:tests/main/ubuntu-core-reboot could helpÂ¿ :)
<fgimenez> vigo, sure :) but, are you using the ubuntu-core-16-arm-64 system for i386? it should be ubuntu-core-16-64
<vigo> fgimenez, I'm running i386 image and ubuntu-core-16-64 for spread
<vigo> I just took it as example :)
<fgimenez> vigo, ah ok :) (we should even use a ubuntu-core-16-32 system specific for i386, but now the tests for amd64 and i386 are the same)
<vigo> fgimenez, I getting this when trying to debug the ubuntu-core-reboot https://pastebin.canonical.com/171577/
<fgimenez> vigo, it seems that it's not able to connect to the testbed, can you ssh to localhost:8022 as the "test" user?
<vigo> fgimenez, I've got an ssh session open
<fgimenez> vigo, did you run spread with reuse the first time?
<vigo> fgimenez, yes I did
<gerry_> hi I have got the x11 plug in the apps section of my yaml but I am getting the following exception when I try to run it as root :No protocol specified Exception in thread "main" java.awt.AWTError: Can't connect to X11 window server
<gerry_> any help gratefully received oh a copy of my yaml is: http://pastebin.com/6E1VZAVG
<fgimenez> vigo, mm imo you should try to reconnect with ssh as the test user to localhost:8022, that's what the error in the log you sent was about. you can also run spread with the -vv flag to see what's actually going on
<vigo> fgimenez, ack
<gerry_> it is like the x11 plug needs a part but I can not find out what part?
<mup> Bug #1644226 opened: SNAP_DATA and SNAP_USER_DATA don't point to current <Snappy:New> <https://launchpad.net/bugs/1644226>
<alex-abreu> mvo, ping
<mvo> alex-abreu: pong
<alex-abreu> mvo, just saw the branch, not sure I understand you discarded mine? ... I did some changes yesterday not sure if you picked them up, I was just missing the retry changes
<mvo> alex-abreu: not discarding it at all, just trying to help it land for 2.18 (which is happening soon). I will close mine and you can cherry pick the new bits
<mvo> alex-abreu: the idea was to add the (small) missing bit while you sleep and have it all landed but now that you are back we can continue with the other one
<mvo> alex-abreu: I re-targeted it, please have a look
<alex-abreu> mvo, oh, we can continue on your branch if it is easier to land
<mvo> alex-abreu: either way is fine, but lets keep yours as thats the one that contains 95% of the commits
<mvo> alex-abreu: I targetd my branch to yours os that should be easy
<mvo> alex-abreu: sorry if that was misleading, we do pickup branches that just need trivial changes sometimes to make things move quicker (especially when timezones are involved). not discarding anything in any way :)
<alex-abreu> mvo, np really, I was just wondering :)
<mvo> alex-abreu: ok, great. just wanted to ensure I do not send the wrong message with that :)
<alex-abreu> mvo, I should have read better in the comment you left :)
<gerry_> hi, how do I install snapd_2.0.3 ?
<alex-abreu> mvo, quick question, so you removed the retry?
<mvo> alex-abreu: its still there
<mvo> alex-abreu: just slightly different
<mvo> alex-abreu: a new branch landed the other day that simplied the retry into a single "retryOperation()" call
<zyga> jdstrand: hey, can you please have a look at snap-confine 188
<alex-abreu> ah I missed it
<mvo> alex-abreu: this is what the code is now using (or should be using unless I did something wrong)
<mvo> alex-abreu: its the same as before just consolidated into that single helper
<gerry_> I have downloaded snapd_2.0.3 from launchpad and I can not find how to install it any help gratefully appreciated
<mvo> gerry_: please try "sudo apt install snapd"
<alex-abreu> mvo, ah yes ok
<mvo> gerry_: the download from launchpad is not required, apt can find and install it by itsel. apt will also pick a more version
<mvo> gerry_: more recent version
<alex-abreu> mvo, I add a small comment to your branch
<alex-abreu> added
<mvo> alex-abreu: cool, thanks, I have a look
<gerry_> it says that snapd is already the newest version (2.16ubuntu3) but I have a problem with my java app that an answer on ask ubuntu says is put right in snapd-2.0.3
<gerry_> oh sorry<blushes> just realised my mistake just this problem driving me nuts
<mvo> gerry_: ok, so you found the solution? thats good to hear
<gerry_> I am trying to upload my java app. It works fine when I run it without root. but when I run it as root I get this exception No protocol specified Exception in thread "main" java.awt.AWTError: Can't connect to X11 window server
<gerry_> is it because I use java swing in my app?
<mvo> gerry_: yes, I think that is it, your root user can not connect to the x server socket. sounds ok if you don't need to be root
<gerry_> mvo : thanks, any tips on what to do I am about out of ideas ?
<mcphail> gerry_: does it work if you specify the DISPLAY variable in the command? Is DISPLAY passed to snap apps?
<gerry_> sorry you mean like this  "sudo $DISPLAY highlighterpdf" ?
<mcphail> gerry_: something like "DISPLAY=:0 highlighterpdf". Of course, sudo'ing graphical apps is dangerous at the best of times
 * mcphail hasn't tried to run a graphical snap as root yet
<gerry_> oh the next line after the exception is "using ':0' as the value of the DISPLAY variable."
<mcphail> gerry_: :(
<mcphail> gerry_: I don't have any bright ideas, but would be interested to see how you get this fixed
<gerry_> mcphail : is it that bad?
<mcphail> gerry_: it tells you my suggestion was spurious
<mup> PR snapcraft#925 opened: Use the connectivity check page to test the downloader snap <Created by elopio> <https://github.com/snapcore/snapcraft/pull/925>
<alex-abreu> mvo, ok merged, thx a lot, I am 100% sure about the hardcoded 'featured' bit but I guess that it is ok for now
<alex-abreu> mvo, can we merge https://github.com/snapcore/snapd/pull/2288 then ?
<mup> PR snapd#2288: Add new store endpoints & snap find support for sections handling <Created by AlexandreAbreu> <https://github.com/snapcore/snapd/pull/2288>
<edje> Might be a bit of a noob question, only just getting into snapping. Is/will hardware video decoding going to be supported?
<mvo> alex-abreu: hm, for some reason github is not updating that PR, it still shows the commit from yesterday as the last commit
<alex-abreu> mvo, maybe I did something wrong with the merge ...
<mvo> alex-abreu: git pull && git push maybe? but sounds more like github is acting strange
<alex-abreu> mvo, yes ... I'll update it manually
<mvo> thank you!
<alex-abreu> mvo, when is the snapd release?
<mvo> alex-abreu: tomorrow (my) morning (in ~13h)
<alex-abreu> mvo, ok, I understand the rush then :) github still playing tricks, otp atm but will get back to it in a few mns
<mvo> alex-abreu: oh, it ended up in your master
<mvo> alex-abreu: that seems to be the problem
<mvo> alex-abreu: let me redo the PR
<alex-abreu> mvo, ah !
<zyga> jdstrand: hey
<mvo> alex-abreu: I send a new PR, sorry for the confusion
<zyga> jdstrand: can you please have a look at https://github.com/snapcore/snap-confine/pull/188
<mup> PR snap-confine#188: Add apparmor support module <Created by zyga> <https://github.com/snapcore/snap-confine/pull/188>
<alex-abreu> mvo, np ...
<tyhicks> zyga: he's off for the remainder of the week
<alex-abreu> mvo, mvo ok merged
<alex-abreu> mvo, looks better
<alex-abreu> mvo, btw I was wondering about the config schema feature in snapd, is someone having a look at it? ...
<zyga> tyhicks: ah, thanks for letting me know
<zyga> tyhicks: would you mind reviwieng that 118 above? it's rather simple
<tyhicks> zyga: I wouldn't mind but can't right now as I'm working through a security update, then I've got a block of meetings, and then I need to get back to the apparmor SRU bug for snaps on 14.04
<tyhicks> zyga: I doubt I'll be able to get to it before I go on holiday starting tomorrow
<tyhicks> zyga: I'll let you know if that changes and I'm able to take a look
 * zyga nods
<zyga> tyhicks: thanks, good luck with the SRUs
<alex-abreu> sergiusens, ping
<kyrofa> alex-abreu, sergiusens seems away at the moment. Can I help you?
<alex-abreu> kyrofa, ah sure, just a simple request, to get the admin rights on https://launchpad.net/snapweb
<kyrofa> alex-abreu, ah, he's only an admin on snapcraft. You'll need to talk to niemeyer I think
<kyrofa> Oh so sory
<kyrofa> I was thinking github
<kyrofa> Yeah, he can probably help you with that
<alex-abreu> kyrofa, ok thx
<kyrofa> alex-abreu, sorry, alas I cannot ;)
<kyrofa> alex-abreu, he's around today though
<Geo_> hello guts i have a HP Compaq Presario C300 Solo 1.66GHZ 1Gb RAM 80Gb HDD. im completely new to linux. i have tried 3 different distros but i always get a black screen. i have tried the nomodeset command to no avail. is the laptop not powerful enough?
<Geo_> lol guts! should be guys
<Geo_> by black screen i mean i can install it onto the usb but cant get throught the startup to get to the desktop.
<Geo_> ok bye guys not even sure if you read this
<kyrofa> Geo_, I doubt it's a problem with power, but you might get more help asking in #ubuntu
<Geo_> #ubuntu
<geo__> #ubuntu
<k1l_> hi, i read on some news that 18.04 will ship with unity8 and snaps as standard package system. Will this mean there is a .deb iso and a snap iso? or will this be full siwtch to snap only?
<sergiusens> alex-abreu kyrofa I gave rights to dbarth a while back
<alex-abreu> sergiusens, can you give them to me too?
<mup> PR snapcraft#925 closed: Use the connectivity check page to test the downloader snap <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/925>
<wililupy> I can't seem to remember, where is there an example of a gadget snap?
<cprov> sergiusens: you mean '.snapcraft/snapcraft.cfg' in PR#901, right ?
<mup> PR snapcraft#926 opened: Sources: add current dir to ignore list if we're iterating on parent <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/926>
<flexiondotorg> sergiusens, I'm talking to an upstream.
<flexiondotorg> Sounds like they might be a Fedora user.
<flexiondotorg> What is the current status of using rpms with snapcraft?
<mup> PR snapd#2345 opened: many: tweak devmode and jailmode capitalisation <Created by zyga> <https://github.com/snapcore/snapd/pull/2345>
<zyga> flexiondotorg: it's not done yet, neither is fedora base snap support nor fedora confinement support; we welcome any pair of hands that would help, I can work and guide all contributors
<flexiondotorg> Yeah, just read to source.
<flexiondotorg> Thanks.
<zyga> flexiondotorg: if you want to help the main blocker today is selinux snapd confinement that is mandatory on f25
<zyga> flexiondotorg: and unexplained mount denial even with relevant capabilities that only goes away when running as root (that affects snap-confine)
<zyga> flexiondotorg: when those are away snaps are useful on fedora
<flexiondotorg> OK. Understood.
<flexiondotorg> The developer in question is not so much concenred about running Snap on Fedora, although I expect that will be his next question.
<zyga> flexiondotorg: the next steps can be done in parallel, support base snaps in snappy (so e.g. ubuntu base and fedora base snaps, support base snaps in meta/snap.yaml so that snaps can say which base they wish to run against and lastly snapcraft support for that so that such snaps can be built in ways other than manually, hand-crafted ones
<flexiondotorg> But build snaps on Fedora.
<flexiondotorg> *building
<zyga> flexiondotorg: until those are done building snaps on fedora can be achieved with lxd/qemu so that snapcraft is available (snapcraft relies on apt and apt was too old / removed in fedora AFAIR (but I don't remember fully))
<flexiondotorg> zyga, Are alternate base snaps being worked on?
<zyga> flexiondotorg: it's scheduled, we're making progress toward that, yes
<flexiondotorg> Thanks.
<zyga> flexiondotorg: it won't be ready till (magic ball) 2.22 though
<zyga> flexiondotorg: early next year I'd say
<flexiondotorg> Cool.
<flexiondotorg> Thanks for the answers.
<flexiondotorg> Good info.
<zyga> flexiondotorg: there's just more work required around the stack as this is a very low level thing that spans the whole system
<flexiondotorg> Indeed.
<zyga> flexiondotorg: if you want to help with fedora support we would gladly welcome you on the team :)
<flexiondotorg> Well, let's see.
<flexiondotorg> Like everyone, my plate is quite full right now :-)
<mup> PR snapd#2344 closed: overlord/ifacestate: don't setup jailmode snaps with devmode confinement <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2344>
<sergiusens> cprov yes, I mean exactly that, but not sure about .snapcraft/snapcraf.cfg and maybe snapcraft.cfg should be called credentials.cfg
<sergiusens> alex-abreu no, dbarth owns it all now, he will have to create a team and set the team as admin
<alex-abreu> sergiusens, ack
<cprov> sergiusens: maybe, but that file is loaded exactly as ~/.config/snapcraft/snapcraft.cfg would be, it really depends on what you have in mind for that file (currently a host->creds map)
<sergiusens> cprov your call then; if we piggy back things in there like storeid and such maybe it is a good idea to keep the name
<cprov> sergiusens: yes, makes sense. Do we need passing autopkgtest tests before merging ? I don't know what is going on there.
<gui_> hello,
<gui_> I want to configure a static IP for my ubuntu core server,
<gui_> but I can't edit the /etc/network/interface file
<gui_> any idea ?
<sergiusens> cprov let me check
<sergiusens> cprov all green is not good enough for you? :-) snapcraft#901
<mup> PR snapcraft#901: Basic 'enable-ci' implementation <Created by cprov> <https://github.com/snapcore/snapcraft/pull/901>
<sergiusens> cprov is there a bug report for this?
<cprov> sergiusens: wow, autopkgtest magically passed in the last hour. No, there is not bug report.
<mup> PR snapd#2341 closed: many: unify boolean env var handling <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2341>
<mup> PR snapd#2304 closed: snap: add `snap list -a` to show all snaps (even inactive ones) <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2304>
<sergiusens> cprov I updated your branch to include what fixed the problem 3 hours ago or so
<cprov> sergiusens: nice! thank you
<mup> PR snapcraft#901 closed: Basic 'enable-ci' implementation <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/901>
#snappy 2016-11-24
<mup> Bug #1631270 opened: running a command for a snap in try mode fails on trusty <Snappy Launcher:Invalid> <Snappy:In Progress by thomas-voss> <snap-confine (Ubuntu):Invalid> <https://launchpad.net/bugs/1631270>
<mup> PR snapcraft#927 opened: Add a test script to build external snaps <Created by elopio> <https://github.com/snapcore/snapcraft/pull/927>
<foxmask> bonjello
<didrocks> hey foxmask
<foxmask> didrocks: o/
<dholbach> hey hey
<didrocks> hey dholbach
<dholbach> salut didrocks
<mup> PR snapd#2262 closed: tests: disable autorefresh for the external backend <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2262>
<vigo> fgimenez, was snapd 2.18 already released? should we build new images or have you a link?
<fgimenez> vigo, no 2.18 nor download link yet, we should use images built from the current edge
<vigo> fgimenez, ack thanks
<bull> ssue while loading plugin: properties failed to load for 2048-qt-snap: Additional properties are not allowed ('source' was unexpected)
<bull> my craft file - http://paste.ubuntu.com/23526294/
<bull> ny1 on ?
<mup> PR snapd#2309 closed: daemon: show what will change in the "refresh-all" changes <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2309>
<bull>  Additional properties are not allowed ('source' was unexpected)
<bull>  my craft file - http://paste.ubuntu.com/23526294/
<mup> PR snapd#2346 opened: Misc libvirt fixes <Created by javacruft> <https://github.com/snapcore/snapd/pull/2346>
<mup> PR snapd#2334 closed: snap: try doesn't require snap-dir when run in snap's directory <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2334>
<mup> PR snapd#2335 closed: store: retry downloads using retry loop <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2335>
<didrocks> bull: I don't think the nil plugin is taking any source directory
<didrocks> bull: if you want to ship the content of src, you need to use the dump plugin
<bull> didrocks, now its working
<bull> with plugin qmak
<bull> qmake
<didrocks> yeah, if you are using qmake in src :)
<didrocks> great to hear!
<bull> ty
<bull> security tag snap.2048-qt-snap.2048-qt-snap not allowed
<bull> any idea why ?
<gerry_> hi I have an app written in java I have used a wrapper and a jar when I try to run it, it has an error: "Error: Could not find or load main class" my main class is not called main the line that I think I need to change is: "$JAVA_HOME/jre/bin/java -jar $SNAP/highlighterpdf.jar " but I don't know how to access the main class from here?
<gerry_> hi what do I add to this line to access the main class (which is not called main) "$JAVA_HOME/jre/bin/java -jar $SNAP/highlighterpdf.jar "?
<mup> PR snapd#2296 closed: snap: add `snap watch <change-id>` to attach to a running change <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2296>
<gerry_> everything runs fine when I install my java package but when I run it as root it crashes with this exception "No protocol specified Exception in thread "main" java.awt.AWTError: Can't connect to X11 window server"
<mup> PR snapd#2347 opened: overlord: flag required-snaps from model as required and prevent removing them <Created by pedronis> <https://github.com/snapcore/snapd/pull/2347>
<mup> PR snapd#2292 closed: snap: do exit 0 on install/remove if that snap is already installed or already removed <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2292>
<zyga> tvoss: btw, the failures in spread after removing my hack with /etc/mtab make me think that it's not ready
<zyga> tvoss: it looks like systemd and mount and libmount disagree on what's mounted
<zyga> pitti: ^^
<mup> PR snapd#2347 closed: overlord: flag required-snaps from model as required and prevent removing them <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/2347>
<tvoss> Zyga, that's not happening locally in a qemu
<gerry_> hi when I run my java app without root it works fine but when I try to run it as root it gives me an exception?
<gerry_> from the research I have done it seems like root user does not have permission to use x11 but that is as far as I got I do not know how to give the root user the permission it needs
<zyga> tvoss: interesting, hmm
<zyga> tvoss: can you try it on a 14.04 server VM
<zyga> tvoss: and see how it behaves?
<tvoss> Yup
<zyga> lool: wanna review something tiny for me: https://github.com/snapcore/snap-confine/pull/194
<mup> PR snap-confine#194: Make messages from die() nicer <Created by zyga> <https://github.com/snapcore/snap-confine/pull/194>
<gerry_> hi my java app runs fine but when I try and run it with sudo it crashes?
<zyga> gerry_: can you show me how it crashes?
<gerry_> yes it crashes with this exception:  No protocol specified Exception in thread "main" java.awt.AWTError: Can't connect to X11 window server
<didrocks> kyrofa, jdstrand: hey! I have some questions on configure hooks and apparmor/seccomp
<didrocks> kyrofa: jdstrand: on ubuntu core (so snapd 2.17), here is my simple configure hook in the snap: https://github.com/ubuntu/snow-on-me-snap/blob/master/meta/hooks/configure
<didrocks> kyrofa: jdstrand: I just put it in meta/hooks/ for now, no special permission as you can see
<didrocks> however, when the file doesn't exist, despite snapctl get giving me the correct values, I'm getting quite some apparmor denials: https://github.com/ubuntu/snow-on-me-snap/blob/master/meta/hooks/configure
<zyga> gerry_: looks like it doesn't have X access, can you run journalctl | grep DENIED
<didrocks> the second is the "sed" path (when the config file exists), which is hitting a seccomp issue
<zyga> didrocks: AFAIK jdstrand is off today
<didrocks> oh
<zyga> didrocks: can you show me the denials please?
<didrocks> zyga: yeah, look at the pastebin above ^
<didrocks> http://paste.ubuntu.com/23527021/
<didrocks> (grrr middle click :p)
<didrocks> I guess the denial is snapctl trying to connect to snapd
<zyga> didrocks: I understand now thank you
<zyga> didrocks: I believe this is the bug https://bugs.launchpad.net/snap-confine/+bug/1644439
<mup> Bug #1644439: snap-confine doesn't work from per-snap namespaces it creates <Snappy Launcher:In Progress by zyga> <https://launchpad.net/bugs/1644439>
<zyga> didrocks: but I never considered it for hooks
<zyga> hmmm
<zyga> didrocks: do you run your own hooks from your apps?
<didrocks> zyga: no, I don't
<gerry_> zyga : a great big long list of "DENIED" this is the first one on the list: Nov 24 11:51:26 gerry-desktop audit[13341]: AVC apparmor="DENIED" operation="create" profile="snap.highlighterpdf.highlighterpdf" pid=13341 comm="java" family="inet6" sock_type="stream" protocol=0 requested_mask="create" denied_mask="create"
<zyga> didrocks: ah, no wait
<didrocks> zyga: here are results from snap install, running the hook first or just snap set <foo>, running the hook
<zyga> didrocks: my mistake, does your hook use any plugs?
<didrocks> zyga: no, and I don't think it needs any, correct?
<didrocks> I expect snapctl is something seen as "internal" and natural for using in the hook without plugs?
<zyga> gerry_: can you do "dmesg -c >/dev/null" roun your app with sudo and do: dmesg | grep DENIED | pastebinit
<zyga> didrocks: well, it apparently tries to use TCP sockets
<didrocks> the puzzling part is that I still get the correct value from snapctl
<zyga> didrocks: is it a go app?
<didrocks> zyga: look at my configure hook above: https://github.com/ubuntu/snow-on-me-snap/blob/master/meta/hooks/configure
<didrocks> no rocket science, no network involved :)
<zyga> didrocks: ah, it actually uses snapctl so it is a go app indirectly
<zyga> didrocks: for now add a [network, network-bind] plugs
<didrocks> zyga: I guess most of the hooks would do, right?
<zyga> didrocks: please report a bug that says snapctl causes hooks to attempt to open ip/ipv6 tcp connection due to go network startup probing code
<zyga> didrocks: thank you
<zyga> didrocks: (and this is denied by the profile)
<zyga> didrocks: effectively every hook using snapctl will require the two plugs
<didrocks> zyga: it's just because of the way the code is structured internally? We could avoid that in the future by talking to a file/datastream socket, right?
<didrocks> and next step, I'll look at sed :p
<zyga> didrocks: somewhat
<zyga> didrocks: it's because snapctl use go and go has some peculiar code in the standar library that makes it bind to ip / ipv6 sockets to check if ipv6 is supported
<zyga> *standard
<gerry_> zyga: not sure I have done this right its empty
<zyga> gerry_: run journalctl -f
<zyga> gerry_: and run your app the way that made it crash
<zyga> gerry_: and look at the output of the first command
<didrocks> zyga: oh, I didn't know that, interesting
<didrocks> thanks for the explanation! I'll hack that in between
<gerry_> zyga : I have put the output here: http://pastebin.com/APSnrgCz
<zyga> gerry_: this error
<zyga> Nov 24 13:50:48 gerry-desktop audit[19767]: AVC apparmor="DENIED" operation="capable" profile="snap.highlighterpdf.highlighterpdf" pid=19767 comm="java" capability=1  capname="dac_override"
<zyga> gerry_: says that you get a regular permission error, the app tried to open something that it doesn't have access to and since it doesn't have DAC_OVERRIDE capability then it cannot do it
<zyga> gerry_: I don't know any more
<gerry_> zyga: thank you very much for your help
<mup> PR snapd#2340 closed: client, cmd/snap: introducing "snap info" <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2340>
<mup> Bug #1644546 opened: [console-conf] Network screen continues to account setup with failing configuration <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1644546>
<rvr> Anyone has seen this error before? error: cannot install "classic": cannot get nonce from store: Post https://myapps.developer.ubuntu.com/identity/api/v1/nonces: dial tcp: lookup myapps.developer.ubuntu.com on [::1]:53: read udp [::1]:43793->[::1]:53: read: connection refused
<zyga> rvr: can you report it
<zyga> rvr: and can you show any apparmor denials (dmesg | grep DENIED)
<rvr> zyga: Ok
<zyga> rvr: looks like ipv6 related bug
<rvr> dmesg | grep DENIED shows nothing
<zyga> rvr: is that something that happens all the time or just randomly?
<zyga> rvr: could be a regular dns failure
<alex-abreu> mvo, the sections PR still is on  the list for landing right?
<mvo> alex-abreu: yes, its the last remaining one
<mvo> alex-abreu: needs a second review, I'm on it to find someone
<alex-abreu> mvo, it has conflicts I am updating it now
<mvo> alex-abreu: thank you
<alex-abreu> mvo, cant you review it yourself? Chipaca did already
<rvr> zyga: I think it is related to a network misconfiguration
<rvr> zyga: Re-run console-conf and problem is gone
<mvo> alex-abreu: I could but gustavo requested changes so ideally he is the one reviewing that his requests are satisfied. if that won't happen I will just do it, but given his timezone I will give him a  little bit more time
<alex-abreu> mvo, yes makes sesne
<tsdgeos> is there a way for me to modify files in the snappying process? i.e. they get installed from a .deb and before being put in the .snap i want to chagne some text files, how do i do that?
<tsdgeos> think i found how
<zyga> rvr: thanks, if you see this again please report a bug
<rvr> zyga: I'll do
<rvr> fgimenez: Error executing external:ubuntu-core-16-arm-32:tests/main/op-remove http://paste.ubuntu.com/23527385/
<niemeyer> alex-abreu: Submitted the follow up review.. there's one test missing, but LGTM other than that.. it's okay to add the test after the release if mvo wants to merge it earlier to move on with the release, but let's please have it
<niemeyer> alex-abreu: Thanks for all the changes
<fgimenez> rvr, looking
<niemeyer> alex-abreu: As one suggestion for the future, it's useful to provide feedback to every comment on the reviews.. in some cases just "Done" is enough.. in other cases, there were questions that went unanswered, or points that were not clear whether they were addressed or not without digging into reviews and code all over again
<alex-abreu> niemeyer, yes you are right ... my default is 'done' unless I comment on it, but yes
<alex-abreu> niemeyer, mvo , btw I was wondering about the config schema feature in snapd, is someone having a look at it or is schedule to? ...
<mup> PR snapd#2348 opened: debian/rules: build with -buildoptions=pie <Created by chipaca> <https://github.com/snapcore/snapd/pull/2348>
<Chipaca> jdstrand, ^ :-)
<mvo> alex-abreu: I will add the test real quick and then it can land AFAICT
<rvr> fgimenez: Another one Error executing external:ubuntu-core-16-arm-32:tests/main/refresh:production http://paste.ubuntu.com/23527442/
<mvo> alex-abreu: and its there
<alex-abreu> mvo, thx
<mvo> alex-abreu: will land as soon as tests are green, thanks again!
<zyga> tyhicks: hey
<zyga> tyhicks: do you have some time for a few code reviews today
<zyga> tyhicks: I need to land a fix to snap-confine's master for the XDG_RUNTIME_DIR
<zyga> tyhicks: the fix is almost done (testing) but it would be nicer to land it on top of a few other branches that help out
<zyga> tyhicks: this one is totally unrelated but tiny and something I'd like to land for the release: https://github.com/snapcore/snap-confine/pull/194
<mup> PR snap-confine#194: Make messages from die() nicer <Created by zyga> <https://github.com/snapcore/snap-confine/pull/194>
<zyga> tyhicks: this is the important prerequisite for the fix: https://github.com/snapcore/snap-confine/pull/193
<mup> PR snap-confine#193: Replace mkpath with sc_nonfatal_mkpath <Created by zyga> <https://github.com/snapcore/snap-confine/pull/193>
<alex-abreu> mvo, thx !
<mvo> alex-abreu: your welcome and thank you for the feature
<fgimenez> rvr, thanks i'll try to reproduce, btw have you tried today with dragonboard from edge?
<rvr> fgimenez: Nope, rebuilt the image for the Raspberry Pi 3 and reporting issues that I see along the way
<fgimenez> rvr, ok i'm seeing some issues on db and wanted to confirm, do you know if anyone is trying it today?
<mup> Bug #1644573 opened: snapctl causes hooks to attempt to open ip/ipv6 tcp connection <Snappy:New> <https://launchpad.net/bugs/1644573>
<rvr> fgimenez: Nope
<alex-abreu> mvo, np, did you see my comment about the schema thing?
<gerry_> my java app will only run with sudo in devmode if I run sudo in dangerous mode it crashes can anyone help?
<sil2100> Hello! How can I search for/get information about snaps from the edge channel?
<didrocks> sil2100: I don't think it's possible
<didrocks> sil2100: no public API AFAIK
<gerry_> I keep thinking I am missing a dependancy in my yaml (maybe for java swing) ?
<gerry_> or maybe x11 but I have the plug and a stage package "x11-apps" ?
<jamespage> gah - just tripped over bug 1624497
<mup> Bug #1624497: complain mode blocks access to nsfs (/proc/self/ns/*) without exec rule <aa-kernel> <openstack-snap> <AppArmor:Confirmed> <https://launchpad.net/bugs/1624497>
<jamespage> soooo close to having running instances on an openstack cloud deployed with snaps in strict mode
<tvoss> zyga: okay, just passed the test suite on a server image
<Trevinho> sergiusens: hey, can a remote part depend on another remote?
<gerry_> when I use it as root installed dangerous mode it comes up with this exception Can't connect to X11 window server
<sergiusens> Trevinho it should more so after some refactoring I did, if it doesn't it should
<Trevinho> sergiusens: with didrocks we had this issue....
<popey> didrocks: thanks for fixing remote parts...
<didrocks> popey: unsure if it's fixed yet
<didrocks> is it?
<Trevinho> sergiusens: I listed a remote part as after of the desktop helpers, but once generated the parts fiele was missing the desktop-* things
 * didrocks tries to update
<didrocks> popey: and how did you see it? :)
<didrocks> popey: we need to importer to run to confirm it :p
<Trevinho> sergiusens: I was wondering if... it could be because the wiki listed my remote parts after the desktop-* ones, so maybe it didn't parse them yet... or I don't know...
<Trevinho> sergiusens: to be clear, it was related to this https://github.com/ubuntu/snapcraft-desktop-helpers/pull/26 which broke the destkop-* parts, by not making them show up in https://parts.snapcraft.io/v1/parts.yaml
<mup> PR ubuntu/snapcraft-desktop-helpers#26: snapcraft.yaml: add dependency on remote indicator parts <Created by 3v1n0> <Merged by didrocks> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/26>
<popey> didrocks: github email
<didrocks> popey: power! :-)
<popey> didrocks: was just testing when your reply came in
<didrocks> ahah
<popey> but no, its not fixed yet, as my snapcraft can't find it
<popey> this is very fragile
<mup> PR snapd#2288 closed: Add new store endpoints & snap find support for sections handling <Created by AlexandreAbreu> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2288>
<didrocks> yeah
<sergiusens> Trevinho ah, so the generator is broken more so than snapcraft's project loader?
<sergiusens> Trevinho if so log a bug and ping josepht on Monday, he's out for thanksgiving
<Trevinho> sergiusens: still on snapcraft project?
<sergiusens> Trevinho yeah, it is all shared code
<didrocks> sergiusens: can you check the API endpoint?
<sergiusens> Trevinho just detail the problem so we can go over it
<sergiusens> didrocks what API endpoint?
<didrocks> sergiusens: to ensure it's not listing the part and you are out of it
<didrocks> sergiusens: just what you get from the importer
<sergiusens> diddledan out of what?
<Trevinho> sergiusens: what is the server code in github?
<sergiusens> didrocks
<didrocks> all snapcraft pats
 * sergiusens senses diddledan will get many incorrect mentions
<diddledan> :-p
<didrocks> (or is it a straight download and you don't post-process?)
<diddledan> keeps me on my toes :-D
<sergiusens> didrocks straight download and yaml.load
<didrocks> sergiusens: ok, so obviously importer
<sergiusens> didrocks Trevinho so it doesn't show up here? https://parts.snapcraft.io/v1/parts.yaml
<Trevinho> sergiusens: nope
<sergiusens> Trevinho didrocks sorry but I am having trouble following your statements :-)
<sergiusens> ok, so no show, means importer
<didrocks> sergiusens: no desktop- apart from desktop-ubuntu-app-platform:
<didrocks> which was the only one to not have a part relying on another part
<didrocks> yeah, importer, what's project should Trevinho file a bug against?
<sergiusens> roadmr where is the status page for snapcraft-parser again?
<roadmr> sergiusens: is it misbehaving? :(
<didrocks> will be great if we can rerun it straight away
<roadmr> sergiusens: https://parts.snapcraft.io/v1/status
<sergiusens> roadmr thank you
<roadmr> sergiusens: looks happy and last run was like 2 minutes ago. I can force a run if you need me to
<didrocks> roadmr: could you retry a run, yeah?
<didrocks> I just refreshed the list
<didrocks> and it's still not here
<didrocks> depends on how long it's taking to run
<sergiusens> didrocks you can run locally if you want
<sergiusens> didrocks apt install snapcraft-parser
<didrocks> I will appreciate if we can get it fixed ASAP though
<sergiusens> roadmr I suspect a missing feature
<gerry_> I have a java app packaged. when I run it normally or sudo in devmode it works but when I run it as sudo in dangerous mode it crashes?
<didrocks> people start to complain because of this
<roadmr> didrocks, sergiusens : running now
<didrocks>  /status doesn't have logs though that the parts have been discared
<roadmr> didrocks: which part is this?
<sergiusens> didrocks everyone wants everything ASAP so you all get into the same queue in the end ;-)
<roadmr> run finished...
<sergiusens> didrocks it should, which is strange
<didrocks> sergiusens: I still find that breaking production is priority #0
<didrocks> roadmr: https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/snapcraft.yaml, all "desktop-"
<sergiusens> didrocks did it ever work though?
<didrocks> apart from desktop-ubuntu-app-platform
<roadmr> didrocks: I see this
<roadmr> DEPRECATED: Found a "/" in the name of the 'desktop/gtk2' part
<roadmr> DEPRECATED: Found a "/" in the name of the 'desktop/gtk3' part
<roadmr> DEPRECATED: Found a "/" in the name of the 'desktop/qt4' part
<didrocks> sergiusens: for 5 months, yes, the parts were published
<roadmr> DEPRECATED: Found a "/" in the name of the 'desktop/qt5' part
<roadmr> DEPRECATED: Found a "/" in the name of the 'desktop/glib-only' part
<didrocks> roadmr: and the one with -?
<didrocks> yeah, I see them!
<didrocks> great
<didrocks> sergiusens: it's maybe the most popular parts btw :)
<didrocks> so, it seems that parts depending on parts are beaking the importer, Trevinho, mind filing a bug? (roadmr, do you know which LP project?)
<didrocks> thanks roadmr for rerunning it btw :)
<roadmr> didrocks: no problem, let me know if you need anything else. The parser lives in snapcraft, so unless sergiusens says otherwise, that's where you should file it
<sergiusens> log against snapcraft assign to josepht
<roadmr> (a heads-up though, Joe is off until Monday)
<roadmr> and probably (will be) enjoying a delicious turkey :)
<didrocks> yeah, that's why we went to bother sergiusens (and I reverted the change to get it fixed for people to use it) :)
<didrocks> thanks guys!
<didrocks> Trevinho: mind filing the bug? ^
<Trevinho> didrocks: sure
 * Trevinho does some researches before
<roadmr> ok :)
<Trevinho> didrocks: so, for tests... snapcraft-parser --index https://wiki.ubuntu.com/snapcraft/parts?action=raw
<Trevinho> is what you want
<Trevinho> or a local file instead
<didrocks> Trevinho: you can probably try it yourself and fork the repo
<Trevinho> didrocks: yep
<mup> PR snapd#2349 opened: tests: skip pty tests on ppc64el and powerpc <Created by mvo5> <https://github.com/snapcore/snapd/pull/2349>
<renato__> didrocks, hey, could you add this to the desktop-laucher? export GST_PLUGIN_SYSTEM_PATH=$SNAP/ubuntu-app-platform/usr/lib/$ARCH/gstreamer-1.0
<renato__> Kaleo, found that is missing
<popey> ogra_: https://www.pine64.org/?page_id=3707 next ac100 :)
<gerry_> hi I have packaged a java app when I run it as sudo in devmode it works fine but when I install it as dangerous it crashes?
<rvr> fgimenez: I don't know what happened, but the Raspi 3 doesn't boot correctly now. Some more failures: https://pastebin.canonical.com/171760/
<rvr> fgimenez: Not it is stuck in the boot screen with an initramfs prompt
<popey> gerry_: can you strace it, or dmesg output, or snappy-debug.security scanlog
<popey> gerry_: dmesg and snappy-debug.security scanlog, are probably first port of call
<mup> Bug #1628914 changed: ubuntu-core edge image switched to stable channel unpredictably and became unusable <Snappy:Fix Released by chipaca> <https://launchpad.net/bugs/1628914>
<gerry_> popey : here is the output from dmesg : http://paste.ubuntu.com/23527739/
<popey> gerry_: what interfaces are you using? Looks like you need network and maybe network-bind?
<gerry_> popey : here is my yaml http://pastebin.com/28ZDTTic
<Trevinho> didrocks: at least isn't an ordering issue :-)
<popey> gerry_: on the phone at the moment, will take a look in a sec
<ogra_> popey, oooh, nice !
<gerry_> no problem :)
<popey> gerry_: add network and network-bind to line 11
<gerry_> ok
<popey> (I think)
<popey> but after the call I'll test more
<gerry_> its still the same but take your time with your call
<dodik> hi all
<dodik> i need some help. I'm install nextcloud snap
<popey> gerry_: where do i find highlighterpdf-0.1.2.tar.gz ?
<didrocks> Trevinho: oki! :)
<didrocks> renato__: it's a private lib, is it Qt or anything looking into this private dirs?
<didrocks> renato__: I'm reluctant (as said on other bug reports) to add private libs by default until we know exactly what's looking into them
<didrocks> Trevinho: good! filed the bug report? :)
<dodik> my server has 2 ip. When apache staring, it bind on both IPs.  How i can set use only One ip
<renato__> didrocks, I do not think this is private libraries it is just gst plugins.
<Trevinho> didrocks: in the process of fixing it instead :-P
<renato__> Kaleo, right ^^^
<didrocks> Trevinho: still good to have a bug report
<dodik> httpd.conf - r/o.  Maybe i can set network-bind  interface ?
<Trevinho> sure
<gerry_> popey: I only have it here local but the jar is on sourceforge highlighterpdf
<didrocks> dodik: your snaps need to have some configure hook to be able to parameterize the port they are listening on
<popey> gerry_: ah okay
<didrocks> dodik: documentation alongside the snaps (if any) should provide those info
<dodik> didrocks: https://github.com/nextcloud/nextcloud-snap/blob/master/snapcraft.yaml
<gerry_> popey : here is the link https://sourceforge.net/projects/highlighterpdf/?source=directory
<dodik> this file doesn't have hooks
<didrocks> dodik: yeah, that's a feature request you should open to them
<fgimenez> rvr, mmm haven't seen that problem before sorry, it seems to be working fine here. btw what power supply are you using for the pi3? i had some issues today (random reboots) and they were caused by a faulty power supply
<rvr> fgimenez: 2A power source
<rvr> It's the first time that I see this
<davmor2> I got a separate power block I use for powering the devices http://www.ebay.co.uk/itm/like/172403905875?lpid=122&chn=ps&adgroupid=27378760866&rlsatarget=pla-181484319186&adtype=pla&poi=&googleloc=1007011&device=c&campaignid=620865095&crdt=0
<davmor2> http://www.quesh.co.uk/products/?product_id=415 for a better overview that seems to give me reliable power for rpi3
<mup> PR snapd#2349 closed: tests: skip pty tests on ppc64el and powerpc <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2349>
<gerry_> popey: was that a problem only having the jar?
<mup> PR snapd#2350 opened: tests: include /boot in saved state (including bootenv and any kernels) <Created by mvo5> <https://github.com/snapcore/snapd/pull/2350>
<popey> gerry_: yeah, sorry, couldn't figure out how to make that work
<mup> PR snapcraft#928 opened: Add missing dependencies to install_requires <Created by javacruft> <https://github.com/snapcore/snapcraft/pull/928>
<gerry_> popey: thanks for trying just for you info the package runs off the jar rather than the tar but thank you anyway
<rvr> davmor2: I have one of those power supplies, maybe not so fancy :)
<davmor2> rvr: nothing fancy to it it just meant I could charge 4 phones and tablet and now acts as a nice way to charge devices and boards :)
<davmor2> rvr: I picked it up from our local shop for like Â£6 or something and thought oh that'll be nice :)
<rvr> davmor2: Mine has 4 ports, 2A x 2 and 1A x 2
<renato__> timp, sergiusens. I have a crazy idea. Is that possible that a part share variables with the main snapcraft? Would be nice if the ubuntu-app-platform share the files that it contains. This way I could exclude that from may package. Something like that: " ... snap: - $ubuntu-app-platform-files ..."
<sergiusens> renato__ we have a bug for that, parts to provide environment for runtime and build
<sergiusens> just way far ahead
<renato__> timp, sergiusens, this way If I add a package that contains dependency that is already present on ubutu-platform I do not need to care about removing it
<gerry_> hi I have a java package when I install  id devmode and use sudo it works but not when I install it in dangerous mode?
<sergiusens> oh, you mean filesets, that is not ways ahead, but not implemented either
<sergiusens> gerry_ (a before I leave message) have you checked snappy-debug?
<renato__> sergiusens, yes I would like to remove any file that is present on my package that is already part of ubuntu-app-platform, instead of doing something like I did for address-book-app: https://code.launchpad.net/~renatofilho/address-book-app/ubuntu-app-platform/+merge/311351
<rvr> fgimenez: I can't get the dragonboard edge image to boot, but don't know whether it is my problem or an issue with the image
<gerry_> sergiusens : what is snappy debug a website?
<renato__> sergiusens, any bug that I can track?
<fgimenez> rvr, with today's image me either, i'm getting this on each boot http://paste.ubuntu.com/23526443/
<rvr> fgimenez: In my case, it doesn't even start, black screen
<mup> PR snapd#2351 opened: tests: add set -e to the prepare ssh script <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2351>
<mup> PR snapd#2352 opened: tests: save/restore /snap/core/current symlink <Created by mvo5> <https://github.com/snapcore/snapd/pull/2352>
<sergiusens> renato__ we dscussed that at the sprint, should be a planned feature
<mup> PR snapd#2353 opened: store: retry on io.EOF <Created by stolowski> <https://github.com/snapcore/snapd/pull/2353>
<timp> renato__: perhaps it would be enough to sort the snapcraft.yaml for the platform and app snaps and detect which of the same packages are installed
<timp> only sort the stage-packages, not the full yaml
<mup> PR snapd#2353 closed: store: retry on io.EOF <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2353>
<cheyc> hi guys
<cheyc> anyway theres an irc snap
<cheyc> ?
<flexiondotorg> sergiusens, Is there a particular reason you can't have_ in snap name: ?
<flexiondotorg> *have underscores _
<sergiusens> flexiondotorg related to udev matching
<flexiondotorg> Ah, OK.
<flexiondotorg> Just found an upstream whose project specifically has _ in it.
<sergiusens> security team would know best but they might be feasting atm
<flexiondotorg> Yes, it's turkey bird season.
<sergiusens> yeah, it is an interesting one; I hope they are not too tied up to the branding of that
<flexiondotorg> Having an answer is a good start :-)
<flexiondotorg> Thanks.
<nic> hi
<nWL_> HI
<nWL_> Getting errors on Creating User Failed from Setup
<mup> PR snapd#2354 opened: release: releasing package snapd version 2.18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2354>
<nWL_> Client.Timeout exceeded while awaiting headers
<zyga> jdstrand: thanks for the mini review
<zyga> jdstrand: are you around tomorrow?
<tobytailor> hi everyone. I have some questions re portion snappy to a new embedded platform. anyone can help?
<zyga> tobytailor: if nobody here is around now you can always ask on the mailing list
<zyga> it's getting late and I was just going to go but I'll try to answer a quick question
<tobytailor> in generell I'm just super confused what the current way to go is. ubuntu-flash-device seems to be outdated, ubuntu-image the way to go. I see oem snaps and hardware.yaml used in examples, but that seemed to be related with gadget snaps...
<tobytailor> with the current gadget spec I don't see how I could write custom boot bins
<tobytailor> since mbr structures can only be 446 bytes of size...
<zyga> tobytailor: you want to get started with this: https://github.com/snapcore/snapd/wiki/Gadget-snap
<zyga> tobytailor: as you learn stuff please contribute some documentation there, it's a wiki
<zyga> tobytailor: to make a image for a device you need a "model assertion" that describes which kernel and gadget snap to use and a few other things
<zyga> tobytailor: you can use existing gadget snaps as a way to find your way around the ideas
<zyga> tobytailor: and I hear its' quite easy to make a kernel snap, if you can reuse an existing kernel snap though, it's much easier and faster
<zyga> tobytailor: the way to build images is to use ubuntu-image, it is available as a snap on the edge channel in devmode
<zyga> tobytailor: for more you want to ask our image gurus on the mailing list
<tobytailor> thanks for the help. all that was already known. still, I see no way how to create the image with a custom build uboot. everything I've found out there, including the examples in the official ubuntu docs, don't seem to work anymore
<zyga> tobytailor: yeah, we are trying to re-organize documentation so that it doesn't get out of date
<tobytailor> e.g. https://github.com/kubiko/roseapple-pi-ubuntuCore-build/blob/master/builder/gadget/meta/gadget.yaml
<tobytailor> there is no way this actually works anymore
<tobytailor> since mbr structures can't be bigger than 446 bytes
<tobytailor> so you can't actually write bootloader.bin or boot-assets/u-boot.bin
<tobytailor> don't get how boot was ever written into the image
<tobytailor> s/boot/u-boot/
<zyga> tobytailor: come back tomorrow around europe mid-day
<zyga> tobytailor: I'm too tired to be here today
<tobytailor> ait, thanks!
<tobytailor> have a good night. happy thanksgiving ;)
<zyga> that doesn't work where I live but thank you anyway, likewise :)
<mup> Bug #1592901 opened: gvfs confinement issues <snapd-interface> <verification-done> <Snappy:Confirmed for jdstrand> <https://launchpad.net/bugs/1592901>
<mup> PR snapd#2355 opened: cmd/snap: don't append to a list that's already the right size <Created by chipaca> <https://github.com/snapcore/snapd/pull/2355>
#snappy 2016-11-25
<flexiondotorg> nessita, I'm talking with the HexChat upstream lead dev.
<flexiondotorg> They are working on a snap.
<flexiondotorg> They should be filing a name dispute form anytime now, can you keep an eye out for it please?
<flexiondotorg> It will be filed by https://launchpad.net/~tingping
<Chris___> Question, I am stuck booting ubuntu core 16 the screen says  core 16 on ip number
<Chris___> Then it asks for local host login but nothing works
<foxmask> bonjello
<zyga> o/
<nullx9> morning
<sil2100> Hey guys! Where can I get info about snappy store packages from the edge channel?
<mvo> sil2100: snapd 2.18 from last night has the groundwork for this, there is a new snap info command
<mvo> sil2100: what info do you need?
<mvo> sil2100: is this for a dev project? I can give you rest api if that helps
<sil2100> mvo: sometimes it's nice to be able to search for those, and then check for instance what versions are available (or what's the latest one) - and/or for what archs the snap is available
<sil2100> For instance, I would now need to know those things about the mir-libs snap
<mvo> sil2100: snap find won't search in edge, but I think the use case of "snap info --edge mir-libs" sounds sensible. chipaca is working on snap info currently
<sil2100> mvo: can I somehow make that API call directly?
<sil2100> In the meantime?
<mvo> sil2100: `http --pretty=format --print b https://search.apps.ubuntu.com/api/v1/snaps/details/mir-libs X-Ubuntu-Series:16 channel==edge` should work
<mvo> sil2100: or http --pretty=format --print b https://search.apps.ubuntu.com/api/v1/snaps/details/mir-libs X-Ubuntu-Architecture:i386 X-Ubuntu-Series:16 channel==edge if you want different arches
<sil2100> mvo: thanks
<mvo> yw
<flexiondotorg> Morning
<mup> PR snapd#2356 opened: cmd/snap: have some completers <Created by chipaca> <https://github.com/snapcore/snapd/pull/2356>
<davidcalle> zyga: hi, I've noticed I have both ubuntu-core and core installed (snapd on 16.10), is that supposed to happen?
<zyga> davidcalle: no, I don't think that's supposed to happen
<zyga> mvo: ^^
<mvo> davidcalle: what version of snapd do you have installed?
<mvo> davidcalle: apt list snapd
<davidcalle> 2.16+16.10ubuntu1.2
<davidcalle> mvo ^
<davidcalle> (yakkety-updates)
<mvo> davidcalle: hmm, anything in "snap changes" that looks like it might brought in core?
<davidcalle> mvo: I installed it manually, but is it not supposed to replace ubuntu-core?
<mvo> davidcalle: not yet, thats still something we need to make happen
<mup> PR snapd#2357 opened: cmd/snap: document 'snap list --all' <Created by zyga> <https://github.com/snapcore/snapd/pull/2357>
<timp> mvo: hello
<timp> mvo: there is a new ubuntu-app-platform candidate. How do we promote that to stable?
<mvo> timp: iirc timo has fully access to myapps.ubuntu.com and he has delegate access furth and also select channels. or am I misunderstanding?
<timp> mvo: I am trying to do it without Timo now, he is on parental leave. I am trying to do it by clicking "Manage this package in the store" on https://code.launchpad.net/~timo-jyrinki/+snap/ubuntu-app-platform/+build/11369 but then I get Access Forbidden.
<timp> maybe I am trying to manage it in the wrong place, or I don't have the permissions
<mvo> timp: https://myapps.developer.ubuntu.com/dev/click-apps/6271/ is the right place
<mvo> timp: but it looks like you don't have permission
<timp> indeed
<mvo> timp: lets talk about it
<mup> PR snapd#2358 opened: tests: decrease the number of expected featured apps <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2358>
<mup> PR snapcraft#929 opened: WIP: Snap snapcraft (based on pylxd branch) <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/929>
<nessita> flexiondotorg, ack! is still not there, but will keep an eye on it
<flexiondotorg> nessita, Thanks.
<tptr> hi, I am trying to disable the automatic snap refresh happening daily but have not found a docu on his so far. Any hint?
<rvr> fgimenez: With candidate channel, dragonboard boots fine
<gerry_> hi when I run snappy-debug I get this suggestion "* adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON" I also get one for write, any suggestions on how I can deal with this?
<flexiondotorg> mvo I was experimenting with snap a memory usage reporting utility last night.
<flexiondotorg> In order to confine it the system-observe interface needs some new rules.
<flexiondotorg> I'd like to prepare a pull-request but want to make sure I'm approaching this the correctly.
<zyga> flexiondotorg: do it, file a bug with the snapd-interface tag and we'll reviwe it
<zyga> review it*
<flexiondotorg> OK.
<mup> PR snapd#2357 closed: cmd/snap: document 'snap list --all' <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2357>
<mup> PR snapd#2355 closed: cmd/snap: add tests for section completion; fix bugs <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2355>
<fgimenez> rvr, yes, the suite is passing here with this patch https://github.com/snapcore/snapd/pull/2358/files
<mup> PR snapd#2358: tests: decrease the number of expected featured apps <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2358>
<fgimenez> rvr, what about pi3, did you try it with candidate?
<tvoss> mvo: ping
<gerry_> hi when I run snappy-debug I get this suggestions: http://pastebin.com/ds8g1jSk how do I cure them?
<rvr> fgimenez: I only have one external monitor :) Still waiting for dragonboard test results.
<zyga> gerry_: try connecting the home plug to your apps
<zyga> gerry_: this will give you (partial) access to home
<zyga> gerry_: except for dot files, so it won't help in this particular case I'm afraid
<mup> Bug #1644810 opened: snapd system-observe interface is missing rules to allow memory usage analysis <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1644810>
<gerry_> zyga : yes I have the home plug already but thank you for looking
<fgimenez> rvr, ok thx! :)
<timp> mvo: is there a policy which snaps should be published under the canonical account?
<timp> I'm thinking where to publish an ubuntu-ui-toolkit-examples snap. I cannot register that with my own account ('tim'), I guess snaps starting with "ubuntu" are special.
<zyga> timp: ownership can be changed later
<timp> zyga: right, but I tried to register 'ubuntu-ui-toolkit-examples' and it is currently pending review. I was asked to use either a special Ubuntu SDK Team account (which we don't have), or the canonical account
<zyga> timp: in that case someone from the store needs to sort this out for you
<timp> I talked with them, and I was asked to figure out if it should go on the canonical account. If not, we should create an SDK team account
<mup> PR snapd#2359 opened: spread: add boilerplate for Linode delta uploads <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2359>
<gerry_> hi I get these two suggestion when I run snappy-debug not sure how to write the lines that I think my wrapper script needs?
<gerry_> sorry these two suggestions: http://pastebin.com/gjnFMS98
<gerry_> my program runs fine with these suggestions but I thought it might be an answer to my real problem which is it crashes when I run it with sudo in dangerous install
<rvr> fgimenez: http://paste.ubuntu.com/23532177/
<gerry_> hi when I run snappy debug I get these suggestions http://pastebin.com/gjnFMS98 it works fine but when I install it as dangerous and try to run it with sudo it crashes ?
<sergiusens> zyga ^
<zyga> sergiusens: I looked yesterday, no idea
<sergiusens> zyga feels like a conlict with $HOME
<zyga> sergiusens: well, $HOME is redefined so whatever is going on, the app looks at the real home explicitly
<qengho> gerry_: I see "java" in that name. Java constructs its idea of user home from things other than the HOME environment variable. Does your wrapper set the java.home variable (or whatever it's named)?
<gerry_> gengho: here is a copy of my wrapper : http://pastebin.com/k69QiwnD
<mup> PR snapd#2360 opened: Fix prefix search query; Fix empty query search; Find doc <Created by AlexandreAbreu> <https://github.com/snapcore/snapd/pull/2360>
<qengho> gerry_: You probably need to be setting the user.home Java property at startup.
<gerry_> gengho: ok sorry I am very newb how would I do that?
<qengho> gerry_: $  man java    Then search for "property", see -Dproperty=value, add the parameter to your wrapper where you run java.
<gerry_> gengho: ok I will try thank you for your help
<alex-abreu> mvo, ping
<Chipaca> alex-abreu: o/
<Chipaca> alex-abreu: did you actually test the change you're proposing in #2360 IRL?
<alex-abreu> Chipaca, yes ... why?
<Chipaca> alex-abreu: because it won't work as described?
<alex-abreu> Chipaca, did I miss something? I checked with the store guys yesterday and made sure that I got the semantics right
<alex-abreu> Chipaca, what do you mean?
<alex-abreu> Chipaca, it doesn't work?
<Chipaca> alex-abreu: but you're not changing the client of the store, you're changing the client of snapd
<alex-abreu> Chipaca, yes I know
<Chipaca> which is why i ask, did you test the change
<Chipaca> because snapd treates name=foo as a request for an exact match
<alex-abreu> Chipaca, so the answer is yes, ...
<Chipaca> that is, name=foo on snapd hits the store details endpoint, not the search endpoint
<Chipaca> name=foo* gets the * removed and hits the search endpoint with name=foo
<alex-abreu> Chipaca, ah I see what you mean, ... sorry yes, I missed the findOne bit, I'll update the PR
<alex-abreu> Chipaca, one thing that I want to do is cleanup the snapd client API, ... the semantics is not clear, it overloads a bit the store search options
<alex-abreu> Chipaca, from the store's perspective, all searches are "prefix searches", ... but you can control if the search is limited on the snap names  or on all the fields, this is not reflected on the snapd client api side, which overloads the Prefix term
<alex-abreu> Chipaca, if you see what I mean
<Chipaca> alex-abreu: I think I do
<Chipaca> alecu: but let's discuss changes before you implement them please
<Chipaca> alex-abreu: ^
<Chipaca> alecu: you too :-p
<alex-abreu> Chipaca, sure
<alex-abreu> :)
<alex-abreu> Chipaca, let's use the branch as a basis for discussion :)
<alex-abreu> Chipaca, do you want to have a quick ho chat for that?
<Chipaca> alex-abreu: there's also a lot of duplication in client that could and should be dropped now that the role and separation of things is clearer
<Chipaca> alex-abreu: I'd rather discuss here tbh
<alex-abreu> Chipaca, agree, this is what triggered my PR
<alex-abreu> Chipaca, np
<mvo> alex-abreu: pong (or did Chipaca already take of everything?)
<alex-abreu> mvo, no I wanted to talk to you about a separate thing :)
<mvo> alex-abreu: aha, ok
<alex-abreu> mvo, what did you have in mind to improve the sections discoverability from the snap cmd's perspective? something like "snap find sections"
 * Chipaca feels a little guilty now
<mvo> alex-abreu: I was thinking about it but did not came up with a nice cli interface yet
<mvo> alex-abreu: snap find --sections without an argument could list them all maybe
<Chipaca> alex-abreu: OS had a google doc about the sections UX; have you seen it?
<mvo> alex-abreu: or `snap find --section` could return "no section specified, please select one of "a,b,c""
<alex-abreu> Chipaca, so basically I want to kind of keep the store's semantics clear, in that ALL the searches are prefix searches, and that you can control the extent of the fields searches (name or all), ...
<Chipaca> nessita might even have a url somewhere
<mvo> Chipaca: aha, great, so the cli was already speced? brilliant
<alex-abreu> Chipaca, did you have something specific in mind when you talked about the cleanups necessary?
<Chipaca> mvo: I don't remember if this aspect of it was
<Chipaca> mvo: because I am not a good repository of urls :-)
<alex-abreu> Chipaca, ah  the Friday guilty feeling :)
<nessita> Chipaca, how can I help?
<Chipaca> alex-abreu: my cleanups seem to be orthogonal to yours
<Chipaca> nessita: do you remember the sections ux doc?
<Chipaca> alex-abreu: but I wonder what exactly you mean about all searches being prefix searches
<nessita> Chipaca, yes, one sec
<alex-abreu> Chipaca, mvo https://docs.google.com/document/d/19HJFQo1Zpz_LgYFzcdBfbRJk3OX3DsjhHyGgkfKNkzY/edit#heading=h.vhukcea9ynk1
<alex-abreu> mvo, Chipaca but there is nothing about sections discoverability the only thing that I could find and implemented is the tab completion
<Chipaca> nessita: ^
<Chipaca> nessita: thanks
<alex-abreu> this is why I did it this way
<Chipaca> agh, 2fa
<alex-abreu> there is a piece missing
<Chipaca> hmm, there might be another doc?
<nessita> Chipaca, pasting on a private channel
<Chipaca> or this one has evolved a lot since i saw it
<Chipaca> thanks
<alex-abreu> Chipaca, what i mean is that there is no way to have an exact search as of now in the store, ... either through the name= or q= fields, ... there is no exact search
<nessita> alex-abreu, that is intentional given the defined semantics for snap find
<alex-abreu> Chipaca, nessita maybe there is another doc indeed
<Chipaca> nessita: alex-abreu: seems it's about the same; just tabs
<alex-abreu> nessita, sure I am not saying that it isn't ... just decribing the situation :)
<Chipaca> so one approach would be to list sections at the bottom of the empty snap find output
<Chipaca> alex-abreu: but if I search q=foo, it'll search for foo all over the place, not just as a prefix
<alex-abreu> Chipaca, the issue is that it overloads a bit the cmd, ... instead of hitting the right endpoint from the store
<Chipaca> alex-abreu: there you lost me
<mup> PR snapd#2347 opened: overlord: flag required-snaps from model as required and prevent removing them <Created by pedronis> <https://github.com/snapcore/snapd/pull/2347>
<alex-abreu> Chipaca, yes, maybe we dont have the same understanding of the word prefix :) ... what I mean is when I search foo it will return snaps 'foobar', 'foofoo', 'foo' etc. and that you can restrict the search to only names or all fields through name= or q=
<Chipaca> alex-abreu: that's not true
<Chipaca> I mean
<Chipaca> alex-abreu: if you search q=hello it'll look for hello anywhere in certain fields
<alex-abreu> Chipaca, well this is what the store guys told me yesterday, and what I could see from the command line
<Chipaca> it might give prefixes more weight, but it can occur anywhere
<alex-abreu> Chipaca, yes this is what I was saying
<nessita> Chipaca, alex-abreu so is prefix anywhere in a given set of fiels
<alex-abreu> :)
<nessita> this means that a search for "foo"
<nessita> will return hits for snaps with descriptions:
<Chipaca> alex-abreu: no, you're saying "prefix", which means it starts with that
<nessita> this amazing fooontastic snap
<nessita> is prefix on words
<Chipaca> oh! i didn't know that
<Chipaca> that sucks, but ok
<alex-abreu> Chipaca, well this is what seems to happen, curl 'https://search.apps.ubuntu.com/api/v1/snaps/search?name=a' -H 'X-Ubuntu-Series: 16' | jq .
<Chipaca> alex-abreu: nessita: can we at least agree that the general search only searching for prefixes is an implementation detail of CPI, and it shouldn't really leak?
<alex-abreu> Chipaca, yes
<alex-abreu> so all is a prefix search
<alex-abreu> you can only restrict the fields being searched
<mup> PR snapd#2351 closed: tests: add set -e to the prepare ssh script <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2351>
<alex-abreu> Chipaca, CPI?
<Chipaca> (nessita: thank you; don't feel you need to carry on being part of the discussion unless you want to)
<Chipaca> alex-abreu: search.apps.ubuntu.com
<alex-abreu> Chipaca, ah, well ... it something that the user might care, and have a broader search so the distinction matters imo
<Chipaca> alex-abreu: have a broader search?
<alex-abreu> it might not be reflected atm in the 'snap' cmd
<alex-abreu> Chipaca, yes, like search on names or search on description, ... the snap names might be very confusing sometimes, I dont know
<alex-abreu> mvo, Chipaca (sorry for the crossed discussions) about the sections discoverability, ... I was thignking about a specific snap find --sections (as mvo said) that would specifically hit the appropriate store end point
<Chipaca> --sections instead of --section to list them all?
<Chipaca> that goes against using tab completion to discover them, fwiw
<Chipaca> not sure how bad that is though
<Chipaca> snap find --sec<tab><space><tab> isn't that much worse than snap find --sec<tab><tab>
<Chipaca> on the other hand maybe it's worth having "snap sections"
<Chipaca> I don't know
<Chipaca> going back to find, if what you're proposing is that snapd know about, and the client api expose, all the search options that CPI provides, I'd say no
<giminni> installed snappy ubuntu core for raspi3 still cannot login using a SSO account with dsa key
<Chipaca> not without a clear use case
<Chipaca> the more api we offer, the less we can adapt
<Chipaca> giminni: is network working?
<giminni> yes
<giminni> it is reproducable
<Chipaca> giminni: maybe we've disabled dsa keys? (i don't remember if that was a thing?)
<alex-abreu> Chipaca, (sections) yes I am not sure how bad things are atm, ... and if people would complain, we might leave it for later
<Chipaca> alex-abreu: right now in 2.18 things aren't good, but 2.19 should improve on it :-)
<Chipaca> we were a little hasty in taking the completion thing as it stood
<giminni> @chipaca: this is the only way to login, as explained in the first boot section
<nothal> giminni: No such command!
<alex-abreu> Chipaca, (find) the gist of what I am saying is that the snapd client api is a bit misleading, the prefix is ... knowing that all the searches are prefix based, ...
<Chipaca> giminni: do you tried a key that isn't dsa?
<Chipaca> alex-abreu: so renaming that option would be fine
<Chipaca> alecu: or reworking the find options struct to make more sense also
<alex-abreu> Chipaca, (find) I sam saying that from a consumer's perspective from snapweb, ... atm I can either use the Prefix and then I end up with a findone, of have a very broad (q=) based prefix search
<Chipaca> gaah! stupid xchat completing whatever it wants to! sorry alecu
<alex-abreu> ahah :)
<alex-abreu> Chipaca, alecu gets more attention
<Chipaca> alex-abreu: search is not very good, and it needs to get better, yes
<nessita> Chipaca, ak, currently in the bi-weekly call so a little spotty
<giminni> @chipaca: no I'll try an rsa key, atm I hack extrausers/etc/shadow and put a password for the user :-(
<nothal> giminni: No such command!
<not-alex-abreu> Chipaca: does that help?
 * Chipaca hugs not-alex-abreu 
<alex-abreu> not-alex-abreu, ahah !
 * not-alex-abreu hugs Chipaca back
<Chipaca> of course now it wants me to talk to alesage
<alex-abreu> ahah ...
<alex-abreu> Chipaca, prefix searches again !! :)
 * alesage is not as handsome as alex-abreu 
<Chipaca> alex-abreu: what I mean is: if the search results are bad for snapweb it's because the search results are bad
<Chipaca> alex-abreu: that needs fixing on the server
<Chipaca> alex-abreu: it most certainly does *not* want fixing on the client
<Chipaca> and doubly-especially not on just one of the clients
<alex-abreu> Chipaca, what I want is have a clear exposure to the 3 bits: prefix snap name search, prefix snap information (broad) search, exact search (through findOne atm)
<Chipaca> alex-abreu: the only reason foo* ends up doing a search with name=foo is to support tab completion
<alex-abreu> I have access to 2 atm, and Prefix is misleading as a name
<alex-abreu> alesage, :))
 * __chip__ is also "special"
<__chip__> giminni: please report back on how it went
<alex-abreu> Chipaca, from snapweb the searches are bad because we cannot search by snap name (which is what I think the snapweb search is about)
<__chip__> you totally can search by snap name
<alex-abreu> __chip__, yes but I mean by snap name *only*
<__chip__> alex-abreu: I don't understand. In what sense can't you?
<__chip__> that is explicitly supported
<giminni> @chipaca: BTW ubuntu one explanation is for dsa AND rsa key anyway...
<nothal> giminni: No such command!
<alex-abreu> since in find (from snapd client) Prefix=false means q= search (which searches all over the place not only in the snap names) and Prefix=true searches for the exact snap name (special semantics of snapd)
<__chip__> alex-abreu: yeah, I think it should work, but I don't know (and the people i'd ask are on holiday today)
<alex-abreu> __chip__, ^
<__chip__> alex-abreu: Prefix=true does *not* search for exact name
<__chip__> alex-abreu: except with your branch, which breaks the feature
<alex-abreu> __chip__, argh yes ... sorry wrong way to put it, ...
<__chip__> alex-abreu: I'm a patient person. I'll wait.
<__chip__> giminni: yeah, I think it should work, but I don't know (and the people i'd ask are on holiday today)
<__chip__> alex-abreu: (if you read that as addressed to you and were confused, my apologies)
<__chip__> I've gotten out of practice of tracking multiple threads on irc. Bad chipaca.
<alex-abreu> Chipaca, the patient thing ?
<Chipaca> alex-abreu: no, the "i think it should work" which was about dsa keys
<alex-abreu> Chipaca, ah :)
<Chipaca> alex-abreu: the "patient" was because you made an incorrect statement, which I corrected, and then you said it was the "wrong way to put it", meaning that you hadn't been wrong in your statement but expressed your still-correct idea in a suboptimal way. So I'm waiting for you to restate it.
<Chipaca> but I have already spent an hour on this. Just sayin'
<alex-abreu> Chipaca, not sure what you mean by that, am I wasting your time?
<Chipaca> alex-abreu: spent, not wasted. I hope it's not wasted!
<alex-abreu> Chipaca, I can send an email it would ease up the load ...
<alex-abreu> Chipaca, I dont think so  but lets stop there since I think that the conversation is starting to be on the wasted side, I'll send an email
<Chipaca> alex-abreu: rather: now that i have some idea of what you're thinking, maybe iterate on that branch?
<Chipaca> otherwise, sure, email works
<alex-abreu> yes a better way to keep a happy tone
<giminni> @chipaca: with rsa it work! please correct https://login.ubuntu.com/ssh-keys text "Import new SSH key  Insert the contents of your public key (usually ~/.ssh/id_dsa.pub or ~/.ssh/id_rsa.pub)."
<nothal> giminni: No such command!
<Chipaca> jjohansen: do you know if logging in to core with dsa keys disabled for some reason?
 * Chipaca remembered we have a non-US security person in the channel
<kyrofa> didrocks, national holiday yesterday, so both jdstrand and myself were off. Did you manage to sort the configure hook issue?
<didrocks> kyrofa: yeah! Well, there is a bug report on the denial creating by snapctl :)
<didrocks> kyrofa: but at least, it's not blocking setting/getting the values
<didrocks> thanks for checking back though :)
<didrocks> if interesting, the bug is https://bugs.launchpad.net/bugs/1644573
<mup> Bug #1644573: snapctl causes hooks to attempt to open ip/ipv6 tcp connection <Snappy:New for zyga> <https://launchpad.net/bugs/1644573>
<kyrofa> didrocks, ah, interesting. But no adverse effects of the denial?
<giminni> @chipaca:better change doc temporarily at https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/ with "2. Import an SSH Key into your Ubuntu SSO account on this page"
<nothal> giminni: No such command!
<didrocks> kyrofa: no, the values are gettable (I didn't use set in the hook, but I don't think that would be different)
<Chipaca> giminni: first I want to find out if this is supposed to happen, or if it's a bug we're all having, or if you're an especially unlucky snowflake
<giminni> @chipaca: yes of course.
<nothal> giminni: No such command!
<Chipaca> giminni: but it does look like we won't know until next week. Hopefully using a rsa key works for you until then.
<giminni> chipaca: FYI: I installed the latest rpi3 file from 3rd november and tried dsa-key login repeatedly. For now rsa works, thx for pointing to the right direction.
<alex-abreu> Chipaca, email sent :)
<mup> PR snapd#2361 opened: snap: fix try command when daemon linie is added <Created by stolowski> <https://github.com/snapcore/snapd/pull/2361>
<fandango> hi all.
<fandango> I have server with 2 ip adresses. Apache (snap, nextcloud) bind server on both IP. How i can set only one IP for snap ?
<fandango> plz help me )
<zyga> fandango: hey, I don't think you can do that just yet but we're working on something that will let you do this with network namespaces
<zyga> fandango: let me look if there's a bug tracking that
<zyga> fandango: please keep track of https://bugs.launchpad.net/snappy/+bug/1624675
<mup> Bug #1624675: Please add network-namespace interface <snapd-interface> <Snappy:Triaged> <https://launchpad.net/bugs/1624675>
<zyga> fandango: with this feature you will be able to create arbitrary network settings for each snap
<fandango> ok, thanks
<fandango> Can i unpack snap stored in /var/lib/snapd/snaps  - modify file, and pack  :) ?
<zyga> fandango: yes
<zyga> fandango: though they will no longer validate and match your assertions
<zyga> fandango: you will have to install a modified snap with --dangerous
#snappy 2016-11-26
<dhaker> help
<mup> Bug #1591142 changed: snapd leaks files in /tmp <Snappy:Expired> <https://launchpad.net/bugs/1591142>
<mup> Bug #1604356 changed: symlink creation over and over on install, creates file too long situation <Snappy:Expired> <https://launchpad.net/bugs/1604356>
<lifeless> whats the right place to report bugs on images? specifically the generic amd64 image doesn't boot under hyper0v
<mup> PR snapd#2358 closed: tests: decrease the number of expected featured apps <Created by fgimenez> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2358>
<eekfonky> I have just taken the plunge to install snappy on my Pi3. How do I make Docker start at boot and where can I edit the fstab to mount my external HD?
<Chipaca> lifeless: i think that's lp:snappy still
<Chipaca> eekfonky: docker should start on boot automatically
<Chipaca> eekfonky: i'm not sure about mounting. Probably easiest is to drop a .mount unit in /etc/systemd/system
<Chipaca> eekfonky: if this were a device you were building, i think it's the kind of thing that goes in the gadget.yaml
<eekfonky> Cool, So Docker is sorted (although I have to use sudo and cannot do a usermod -aG) As for mounting I think it goes in the /writable section, but I don't want to tamper with it in case I break it
<eekfonky> Do I need to add another fstab in /writable? or make a soft link? Is there a procedure for this? I am not sure how to write a .mount for the /etc/systemd/system. I know how to add a service like NZBget but mounting a drive...any advice?
#snappy 2016-11-27
<longsleep> Anyone knows why 'snapcraft register-key' fails with 'Key registration failed: The account-key-request assertion is not valid.' for me?
<Rillian_> hello
#snappy 2017-11-20
<mborzecki> morning guys
<zyga-ubuntu> good morning
<zyga-ubuntu> it's snowing!!!
<zyga-ubuntu> man, I haven't seen snow in years
<mborzecki> zyga-ubuntu: hey
<mborzecki> yeah, splendid weather
<zyga-ubuntu> mborzecki: just like I remember it my whole childhood :)
<zyga-ubuntu> mborzecki: it will be white by the time my kids go to school today
<mborzecki> zyga-ubuntu: https://forum.snapcraft.io/t/core-snap-fails-auto-review-in-the-store-since-friday/2897
<zyga-ubuntu> mborzecki: yep, I know :/
<zyga-ubuntu> though, let me read about new developments
<zyga-ubuntu> mborzecki: the store review code diff was one character
<zyga-ubuntu> mborzecki, ogra_: commented
<zyga-ubuntu> man it's whiter every second
<zyga-ubuntu> the roof is now fully white
<zyga-ubuntu> and my wife's car too (poor her!)
<zyga-ubuntu> I only wish it was colder so the snow would not melt away so quickly
<zyga-ubuntu> so, today, I have a few branches to iterate on
<zyga-ubuntu> but I'd like to fix the other LXD issue once and for all
<zyga-ubuntu> to have that boulder off my back
<mborzecki> well, it's raining right here, there's still some spots of snow that apparently fell over the night, but it's ugly as hell (i.e. typical november)
<zyga-ubuntu> mvo: hello
<zyga-ubuntu> mvo: SNOW! :D
<zyga-ubuntu> mvo: some unhappy store news
<zyga-ubuntu> mvo: new review tools not deployed yet (it seems), jdstrand sent us email over weekend
<zyga-ubuntu> mvo: not sure if there are things he said we could do
<mvo> hey zyga-ubuntu ! good morning
<mvo> zyga-ubuntu: looking at my mail now. any other unhappy news?
<mvo> zyga-ubuntu: snow is nice
<zyga-ubuntu> mvo: no, nothing other than that
<zyga-ubuntu> mvo: but I haven't checked much yet
<zyga-ubuntu> mvo: waking kids up now
<mborzecki> mvo: morning
<mvo> hey mborzecki - good morning
<zyga-ubuntu> (I don't like when they don't go to school at 8AM)
<stgraber> zyga-ubuntu: FYI, https://bugs.launchpad.net/snapd/+bug/1733211
<mup> Bug #1733211: lxd snap fails to install w/apparmor "permission denied" error <snapd:New> <https://launchpad.net/bugs/1733211>
<stgraber> zyga-ubuntu: going to bed now, but I expect we'll have more people run into this one as we've pushed a deprecation warning to all our PPA users on Friday telling them to move to the snap or backports
<zyga-ubuntu> stgraber: thank you for the note, reading
<zyga-ubuntu> stgraber: that looks like a new bug right?
<zyga-ubuntu> stgraber: or a regression technically
<zyga-ubuntu> but this is weird, we have the rule to read that:
<zyga-ubuntu>         @{PROC}/@{pid}/cmdline r,
<zyga-ubuntu> stgraber: if this is about privileged containers that don't stack apparmor then this is ECANNOTFIX
<zyga-ubuntu> stgraber: I sincerely hope it's not, let me read the bug carefully
<stgraber> zyga-ubuntu: no, I hit this outside of a container
<stgraber> zyga-ubuntu: usually on machines that are already running other snaps
<zyga-ubuntu> stgraber: aha!
<zyga-ubuntu> stgraber: thank you, I'll investigate
<zyga-ubuntu> since you said that rebooting helped it smells like apparmor cache bug we ran into before
<stgraber> zyga-ubuntu: the fact that rebooting the system fixes the issue is somewhat puzzling
<zyga-ubuntu> I'll try to reproduce now
<stgraber> oh, yeah, could be the apparmor cache
<stgraber> not sure why I didn't think of that, I could have dumped the content of the cache and profile before rebooting the system (though to be fair, they were broken production systems, so didn't have much time for debugging :))
<stgraber> which makes me wonder, I have that backup host that may actually have the same issue and would let me check this quickly without risk
<stgraber> and nope, no such luck, that system installs the lxd snap without any problem...
 * stgraber tries a few other random systems in his basement real quick
<zyga-ubuntu> stgraber: no worries, enjoy your evening and let us investigate
<jibel> good morning
<jibel> there is a recent increase of this problem on errors.u.c https://errors.ubuntu.com/problem/cf07c2fa3f39a98f0b52aaf20ff82faab7969129
<zyga-ubuntu> jibel: good morning
<jibel> it started around Nov. 14th
<zyga-ubuntu> jibel: thank you for the notice
<stgraber> that sounds surprisingly similar to that issue we were just discussing, also permission denied, also for a path that should be allowed and also in the configure hook
<zyga-ubuntu> jibel: oh, interesting, this is a yet another issue
<zyga-ubuntu> stgraber: yes, we ran into this one a while ago ~1 month
<zyga-ubuntu> stgraber: it was a bug in apparmor then
<zyga-ubuntu> stgraber: and we included a workaround for that
<zyga-ubuntu> something we need to look into, apparently
<jibel> zyga-ubuntu, yeah other crash are with specific snaps, but this one is with the core snap
<jibel> on 17.10 and 18.04
<zyga-ubuntu> mvo: so we have more "news" apparently
<zyga-ubuntu> 2.29.3 is very worrying, it should have been fixed before
<mvo> zyga-ubuntu: the configure script error is probably not 2.29.3 itself, just the fact that we have an update, no?
<mvo> zyga-ubuntu: I mean, the mass update of core triggered this I presume? triggered the apparmor bug
<mvo> zyga-ubuntu: do you remember the details for the previous workaround? that was part of 2.28.X, right?
<mvo> zyga-ubuntu: I don't see a mail from jamie about the script in my inbox, maybe it just went to you?
<zyga-ubuntu> mvo: let me check
<mup> PR snapd#4249 opened: release: snapd 2.29.4 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4249>
<zyga-ubuntu> mvo: the previous bug we did something (AFAIR you did after talking to tyhicks) that casuses cache to be purged on core updates on core
<zyga-ubuntu> mvo: ok, I should eat something before jumping into the fray
<zyga-ubuntu> mvo: I see that we have three issues: LXD + remove bug (close to being fixed, oldest), bug reported by stgraber above (mysteriously fixes itself on reboot) and the bug form errors.u.c from 14th Nov
<zyga-ubuntu> mvo: the other two may be related but not sure if they are yet
<zyga-ubuntu> mvo: let's split work in 20 minutes, I need to eat something
<mvo> zyga-ubuntu: sure, eat
<mvo> zyga-ubuntu: ssee you then
<mborzecki> zyga-ubuntu mvo anything I can help with?
<zyga-ubuntu> mvo: ok properly back now
 * zyga-ubuntu made _warm_ breakfast for a change
<zyga-ubuntu> mborzecki: definitely!
<mvo> zyga-ubuntu, mborzecki I created http://pad.ubuntu.com/Wkp2bPRAnI so that we have a scratchpad, please add all you know there for now and once we have a bit more we can make that three forum topics
<mvo> zyga-ubuntu: I'm especially interessted in "lxd-+remove bug", is that the one you were chasing for some time ?
<mvo> zyga-ubuntu: i.e. the one where the rshared is not set correctly on /snap ?
<zyga-ubuntu> mvo: yes
<zyga-ubuntu> mvo: yes
<mvo> zyga-ubuntu: and if it is this one, why is it on the list? its not something new in 2.29.4, or is it?
<mborzecki> mvo: can you paste the bug report from errors.ubuntu.com in the pad? I've only requested access there
<zyga-ubuntu> mvo: no, nothin new
<mvo> zyga-ubuntu: ok, if its nothing new, lets move it down the priorites just for now to figure out if 2 and 3 are regressions and what we can do about them (?)
<zyga-ubuntu> mvo: +1
<zyga-ubuntu> done
<mvo> mborzecki: I added some more data, unfortunately its not much, I guess we need a reproducer, might be as simple as going from an old core to the new core on 17.10, but then I do that all the time and have not seen it :/
<zyga-ubuntu> I added some ideas on what might happen
<mvo> zyga-ubuntu: ta
<zyga-ubuntu> mvo: is issue 2 (renumbered) affecting those as LXD guest or host?
<zyga-ubuntu> mvo: (those releases)
<mvo> zyga-ubuntu: yeah, I wonder the same, I just tried it on a normal system in 17.10 and did not see the error
<zyga-ubuntu> mvo: I don't see 2.29.3 in the archive
<zyga-ubuntu> on 17.10
<mborzecki> it's 2.28.5 iirc
<zyga-ubuntu> yes, that's what I see
<mvo> zyga-ubuntu: not even in -proposed?
<zyga-ubuntu> mvo: ah, I didn't look there (not a default setup)
<zyga-ubuntu> do you think people affected by 2nd bug used proposed?
<mvo> zyga-ubuntu: maybe but its strange
<mvo> zyga-ubuntu: because I can't reproduce it on a regular system
<mvo> zyga-ubuntu: with 2.29.3 from the debs on 17.10
<mvo> zyga-ubuntu: but maybe I need to try harder
<zyga-ubuntu> mvo: same result with stable debs + core
<mvo> thanks jibel btw for raising this issue!
<mvo> zyga-ubuntu: worth exploring if its happening inside lxd only, but then - the amount of users(17.10) & users(lxd) & users(snapd) are producing a relative high number of errror reports
<jibel> mvo, yw
<kalikiana> o/
<mup> PR snapd#4250 opened: packaging: fix typo <Created by mvo5> <https://github.com/snapcore/snapd/pull/4250>
<zyga-ubuntu> brb
<zyga-ubuntu> re
<zyga-ubuntu> mvo: do we retry core configure failures/
<mvo> zyga-ubuntu: no, I we just ignore failures on them
<zyga-ubuntu> mvo: that's curious
<zyga-ubuntu> mvo: look at those:
<zyga-ubuntu> https://errors.ubuntu.com/oops/c8ec99fe-cdd2-11e7-919f-fa163ef911dc
<zyga-ubuntu> https://errors.ubuntu.com/oops/7fecbe46-cdd2-11e7-9435-fa163ebeb28a
<zyga-ubuntu> mvo: that's one system
<zyga-ubuntu> right?
<mvo> zyga-ubuntu: yeah, thats strange indeed
<mvo> zyga-ubuntu: it looks almost like the install fails and it is retrying
<zyga-ubuntu> mvo: could it be a fresh install?
<zyga-ubuntu> mvo: after restarting into new snapd
<zyga-ubuntu> mvo: maybe another LXD cluster with privileged containers for that cloud certification?
<mvo> zyga-ubuntu: it has DidRexec set to 0
<zyga-ubuntu> mvo: ah, I see
<zyga-ubuntu> puzzlin
<mvo> zyga-ubuntu: yeah
<zyga-ubuntu> mvo: so ... proposed testing?
<zyga-ubuntu> mvo: maybe this is some adt machine?
<zyga-ubuntu> mvo: running off proposed?
<mvo> zyga-ubuntu: that sounds like a good theory
<mvo> zyga-ubuntu: and its a 16.04 one
<zyga-ubuntu> did you have any luck in reproducing this?
<mup> PR snapd#4251 opened: timeutil: include test input in error message in TestParseSchedule() <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4251>
<Shibe> guys is there any nightly for snappy?
<Shibe> for ubuntu
<zyga-ubuntu> Shibe: we have the edge channel which is just like that
<Shibe> zyga-ubuntu: how do I enable it on ubuntu?
<zyga-ubuntu> Shibe: install snapd, install core snap (if you don't have one already) and snap refresh core --edge
<zyga-ubuntu> mvo: no idea how to reproduce this, I tried in various containers with and without proposed
<mvo> zyga-ubuntu: yeah, I am also clueless so far, I think we need to move it to the forum and see if we can find someone who actually hits this or can give us other clues
<zyga-ubuntu> hmm
<zyga-ubuntu> http://pad.ubuntu.com/ep/pad/reconnect - forbidden
<zyga-ubuntu> how i "love" etherpad
<mvo> zyga-ubuntu: http://pad.ubuntu.com/Wkp2bPRAnI ?
<mvo> zyga-ubuntu: and yeah, its very annoying
<zyga-ubuntu> mvo: connected back, thanks
<mvo> yw
<zyga-ubuntu> pull requests are kind of red
<zyga-ubuntu> + snap refresh
<zyga-ubuntu> error: cannot refresh []: cannot query the store for updates: got unexpected
<zyga-ubuntu>        HTTP status code 500 via POST to
<zyga-ubuntu>        "http://localhost:11028/api/v1/snaps/metadata"
<mvo> zyga-ubuntu: yeah, I have a look in a tiny bit. but this sounds much like a problem for our friends in #snapstore :)
<zyga-ubuntu> that's interesting, why are we refreshing a list of no snaps?
<zyga-ubuntu> man
<zyga-ubuntu> I *HATE* travis moronic log output behavior
<zyga-ubuntu> why does clicking on any line closes the fold?
<zyga-ubuntu> Nov 20 09:09:04 li157-129 snapd[31385]: 2017/11/20 09:09:04.824015 logger.go:76: DEBUG: < "HTTP/1.1 500 Internal Server Error\r\nContent-Length: 111\r\nContent-Type: text/plain; charset=utf-8\r\nDate: Mon, 20 Nov 2017 09:09:04 GMT\r\nX-Content-Type-Options: nosniff\r\n\r\ninternal error collecting snaps: open /tmp/read-file456639681/unpack/meta/snap.yaml: no such file or directory\n"
<zyga-ubuntu> mvo: is that us or the store is sending that?
<zyga-ubuntu> ah, that's fakestore
<pedronis> zyga-ubuntu: that's our fakestore
<mvo> zyga-ubuntu: uhhh, which PR is thisÃ
<mvo> ?
<mup> PR snapd#4252 opened: store: fix download caching and add integration test <Created by mvo5> <https://github.com/snapcore/snapd/pull/4252>
<zyga-ubuntu> this was 4242 but I just hit restart
<zyga-ubuntu> it looks like timing / race in fakestore
<mvo> zyga-ubuntu: ok, no worries, I try to reproduce
<mup> PR snapd#4251 closed: timeutil: include test input in error message in TestParseSchedule() <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4251>
<mvo> zyga-ubuntu: hm, not all is terrible, 4251 was green for example. there is a silver lining :)
<mup> PR snapd#4250 closed: packaging: fix typo <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4250>
<mup> PR snapd#4247 closed: interfaces: allow /bin/chown and fchownat to root:root <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4247>
<mvo> if someone could do a second review on 4242 that would be great, looks like an easy win
<zyga-ubuntu> mvo: that 4247 one had a question
<mvo> zyga-ubuntu: yes, I'm 99% sure the answer is "its fine", let me write that in the PR
<zyga-ubuntu> mvo: done
<mvo> zyga-ubuntu: ha! even better, thank you :)
<zyga-ubuntu> mvo: I mean 4242 :)
<mup> PR snapd#4235 closed: cmd: pretend we're running on Ubuntu in TestExecInCoreSnapUnsetsDidReâ¦ <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4235>
<mvo> zyga-ubuntu: let me check
<mvo> zyga-ubuntu: aha, sorry, async communication is hard ;)
<mvo> zyga-ubuntu: comment and I also looked at the source and my confidence is at 99.9 now
<zyga-ubuntu> mvo: thank you, I shared that but wanted to check just in case
<zyga-ubuntu> mvo: the BPF code just ingores those arguments
<mvo> zyga-ubuntu: yeah
<mvo> zyga-ubuntu: some PRs in flight, once there tests are green we can merge and will be below 25 again :)
<mup> PR snapd#4253 opened: task tunner: extended task runner test <Created by stolowski> <https://github.com/snapcore/snapd/pull/4253>
<zyga-ubuntu> mvo: yeah I'll merge them as soon as we can, I restarted a few random failures today
<zyga-ubuntu> though way too more for my liking
<mvo> zyga-ubuntu: yeah, its too fragile currently
<mvo> zyga-ubuntu: the did-rexec in the error reports is a red-herring :/ the problem is that we unset SNAP_DID_REEXEC to not confuse classic confinement snaps. and that is the env that the err tracker picks up
<zyga-ubuntu> mvo: are you saying that we should set a new flag SNAPD_WE_ACTUALLY_DID=reexec
<zyga-ubuntu> pstolowski: hey, do you have a moment for 2nd look on https://github.com/snapcore/snapd/pull/4224
<mup> PR #4224: cmd/snap-update-ns: teach update logic to handle synthetic changes <Created by zyga> <https://github.com/snapcore/snapd/pull/4224>
<zyga-ubuntu> pstolowski: I changed the approach slightly after your comment
<mvo> zyga-ubuntu: maybe, I look into this right now
<zyga-ubuntu> mvo: I kind of feel that the set of constraints is lost
<zyga-ubuntu> mvo: we have some super ancient versions of snapd that put them
<zyga-ubuntu> mvo: but they have now escaped me
<zyga-ubuntu> mvo: maybe you could write this down in some reegex.go extented comment?
<zyga-ubuntu> ha, and I said "regeexec" instead of reexec :)
<mup> PR snapd#4242 closed: asserts/sysdb: panic early if pointed to staging but staging keys are not compiled-in <Created by pedronis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4242>
<pstolowski> zyga-ubuntu, will do in a few moments
<niemeyer> Hello hello
<zyga-ubuntu> niemeyer: hello
<mborzecki> niemeyer: hi there
<niemeyer> o/
<mvo> hey niemeyer ! welcome back
<mborzecki> is there a way to have check do a pretty print of unequal values like spew does?
<niemeyer> mvo: Thanks!
<niemeyer> mborzecki: Not a pretty print, yet at least
<mariogrip> jdstrand: ok got ubports-installer to work pretty nice in devmode now :) now the confined part, how do i handle the usb-raw part? post-install connect thing?
<mup> PR snapd#4254 opened: cmd, errtracker: get rid of SNAP_DID_REEXEC environment <Created by mvo5> <https://github.com/snapcore/snapd/pull/4254>
<zyga-ubuntu> mvo: ^ you have a conflict there
<mup> PR snapd#4245 closed: interfaces/screen-inhibit-control: handle ScreenSaver/Screensaver in DBus API <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/4245>
<zyga-ubuntu> fg
<ogra_> full grin ?
<ogra_> :P
<mup> PR snapd#4255 opened: interfaces/screen-inhibit-control: fix case in screen inhibit control <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4255>
<kalikiana> yikes,  my /var/lib/snapd/hostfs is empty!?
<kalikiana> no wonder I'm getting strange failures
<ogra_> you mean from inside a "snap run --shell" ?
<kalikiana> no, from outside as well
<jdstrand> kalikiana: just passing by, but note it is only populated inside the snap
<jdstrand> it is supposed to be empty on the host
<ogra_> kalikiana, thats normal,
<ogra_> only snap-confine mounts sumething there at runtime
<kalikiana> hmmm so it's "only" an issue in the snap
<kalikiana> I got a file not found error
<kalikiana> I can't "--shell" since this is a classic snap... (snapcraft)
<kalikiana> I'm pretty sure the relevant code hasn't changed
<niemeyer> Is it me or hangouts just broke?
<zyga-ubuntu> niemeyer: you
<niemeyer> "There is a problem connecting to this video call. Try again in a few minutes."
<zyga-ubuntu> niemeyer: you froze after "guys"
<kalikiana> oh, actually --shell does something, but it looks like my real shell
<mvo> niemeyer: some more investigation (quite raw) http://pad.ubuntu.com/Wkp2bPRAnI
<kalikiana> jdstrand: ogra_ : so hostfs is empty within `snapcraft run --shell snapcraft` as well
<kalikiana> feels like snapd changed something here
<jdstrand> kalikiana: is snapcraft classic?
<kalikiana> jdstrand: yes
<jdstrand> iirc, is is only populated for non-classic
<zyga-ubuntu> jdstrand: correct
<zyga-ubuntu> hostfs on classic is /
<zyga-ubuntu> so we don't do anything
<zyga-ubuntu> perhaps we could use a trick
<zyga-ubuntu> so in classic distros hostfs is a symlink to /
<zyga-ubuntu> and for confined apps it is a directory and we pivot root there as we do
<kalikiana> jdstrand, zyga-ubuntu: the code in snapcraft hasn't changed, though...
<kalikiana> hrm, lemme debug this a bit
<kalikiana> it's weird actually the fact that hosts even shows up as a path here. the code isn't doing that..
<kalikiana> hrmpf, now it works again, no change...
<diddledan> https://forum.snapcraft.io/t/corebird-1-7-3-release-with-added-emoji/2906
<diddledan> \o/
<mup> PR snapd#4256 opened: snap-confine: add workaround for snap-confine on 4.13/upstream <Created by mvo5> <https://github.com/snapcore/snapd/pull/4256>
<zyga-ubuntu> mvo: +1
<zyga-ubuntu> jdstrand: ^^
<mvo> zyga-ubuntu: I'm running the test in my manual created sid spread image now, will take a little bit
<zyga-ubuntu> mvo: mvo thank you
<zyga-ubuntu> mvo: my fix didn't work, I probably broke something just a moment ago as it was in a better shape last fix, digging
<mvo> zyga-ubuntu: thank *you*, you came up with the right apparmor line
<zyga-ubuntu> mvo: no, that was jdstrand :)
<mvo> zyga-ubuntu: oh? the fix for the lxd remove? or a different fix that does not work?
<zyga-ubuntu> mvo: for the remove
<mvo> zyga-ubuntu: aha, ok. still, I think you put it in the forum, I'm sure there is plenty of reason to thank you :)
<zyga-ubuntu> :D
 * jdstrand reviewed 4256
 * zyga-ubuntu tries -shell-before to see what's wrong
<mvo> zyga-ubuntu: testing on debian-sid shows some other issues, I will expand this pr a little bit, just fyi
<zyga-ubuntu> mvo: ack
<jdstrand> roadmr: hi! hope you had a nice weekend. not sure you read email yet, but can you update the review tools for r945?
<jdstrand> popey: hey, do you have a moment to talk about snapcrafters?
<roadmr> jdstrand: hey!
<roadmr> jdstrand: I hadn't, but I'll get the ball rolling
<kalikiana> sergiusens: just to double-check, we have our weekly tomorrow/ Tuesday again?
<jdstrand> roadmr: thanks!
<roadmr> jdstrand: I was aware of the situation on Friday but there was not much we could do then :(
<kalikiana> sergiusens: I see it in the calendar, just at the back of my head someone said it would be Monday again
<jdstrand> roadmr: yeah. r944 and r945 came in at an unfortunate time
<mborzecki> need to finish for today, enjoy the rest of the day guys, cu
<zyga-ubuntu> mvo: hey, I _think_ found the issue now (removed one line of apparmor by vim mistake probably)
<zyga-ubuntu> mvo: running again to see
<zyga-ubuntu> mvo: how are your stuff?
<zyga-ubuntu> (debian)
 * kalikiana going out for lunch shortly, will be back in ~hour or so
<mvo> zyga-ubuntu: debian is running, a bit slow but running. it was net-tools missing that broke it earlier, I added it to the PR
<mvo> zyga-ubuntu: looking forward for the removal fix PR :)
<kalikiana> zyga-ubuntu: hrm, seems I'm still seeing the weird hostfs issue, it only went away since I tried straight from git, not from the snap... it seems the lxd snap/ lxc command is receiving a path starting with /var/lib/snapd/hostfs/ and that's what I see in the error
<zyga-ubuntu> mvo: once this run goes green I'll drop the unrelated changes and test again
<zyga-ubuntu> mvo: and publush
<zyga-ubuntu> *publish
<zyga-ubuntu> kalikiana: can you please refresh my memory?
<kalikiana> zyga-ubuntu: what I just described above
<kalikiana> zyga-ubuntu: error: open /var/lib/snapd/hostfs/home/cris/snap/lxd/common/snapcrafts3h6q44p/core_3440.assert: no such file or directory from subprocess.CalledProcessError: Command '['lxc', 'file', 'push', '/home/cris/snap/lxd/common/snapcrafts3h6q44p/core_3440.assert', 'helga:snapcraft-oman/run/core_3440.assert']' returned non-zero exit status 1.
<kalikiana> when the file exists in the folder
<kalikiana> on the host
<kalikiana> zyga-ubuntu: Wondering what could cause this... the path from snapcraft is the real one
<mup> PR snapd#4257 opened: interfaces/opengl: also allow read on 'revision' in /sys/devices/pci <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4257>
<mup> PR snapd#4249 closed: release: snapd 2.29.4 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4249>
<zyga-ubuntu> re
<zyga-ubuntu> kalikiana: sorry, no (immediate) idea, trying to wrap up one issue, then will switch context to this if you need help
<kalikiana> zyga-ubuntu: aye, will have my lunch break first, no rush
<kalikiana> well, late lunch haha
<mvo> jdstrand: silly question, I get an apparmor denial in snap-confine/debina-sid http://paste.ubuntu.com/26005784/ but the rule looks valid to me, how can I check how @multiarch is expanded?
 * jdstrand looks
<mvo> jdstrand: I have the VM in front of me if you need more info, its slightly puzzling
<jdstrand> mvo: the rule looks right
<jdstrand> mvo: is this a reexec situation?
<jdstrand> (or lack thereof)
<mvo> jdstrand: no, re-exec is disabled on debian-sid right now
<mvo> jdstrand: its also happening when I directly run snap-confine in the shell
<jdstrand> mvo: so /etc/apparmor.d/usr.lib.snapd.snap-confine.real has the rule you pasted?
 * jdstrand isn't sure .real is used in Debian...
<mvo> jdstrand: *cough* the file is 0 bytes long
<jdstrand> ah
<mvo> jdstrand: so something is fishy here
<jdstrand> well, that might have a consequence or two
<jdstrand> sounds like the cache file is being used
<mvo> jdstrand: indeed, looks like the debian packaging is broken :/ the deb is also zero bytes
<jdstrand> yikes
<zyga-ubuntu> deb is zero byts?!
<zyga-ubuntu> hmmm
<zyga-ubuntu> something fishy here:
<zyga-ubuntu> umount: /snap/core/3495 unmounted
<zyga-ubuntu> + unsquashfs '/var/lib/snapd/snaps/core_3495.snap
<zyga-ubuntu> /var/lib/snapd/snaps/core_3495.snap'
<zyga-ubuntu> Could not open /var/lib/snapd/snaps/core_3495.snap
<zyga-ubuntu> /var/lib/snapd/snaps/core_3495.snap, because No such file or directory
<zyga-ubuntu> there's a newline in that filename
<mvo> zyga-ubuntu: the snap-confine.real in the deb is zero byte
<zyga-ubuntu> mvo: I dropped junk from my branch, trying again
<zyga-ubuntu> mvo: it passed :D
<zyga-ubuntu> mvo: man, I just had to throw the garbage out
<mvo> zyga-ubuntu: yay
<zyga-ubuntu> mvo: I'll run a bit more of main to see one more test that broke on me earlier
<zyga-ubuntu> mvo: any luck with that @multiarch thing?
<mvo> zyga-ubuntu: zero size snap-confine.real apparmor in the package in debina
<mvo> zyga-ubuntu: thats the culprit, I still try to understand why
<zyga-ubuntu> mvo: kk
<stgraber> zyga-ubuntu: did you find the source of that permission denied thing?
<zyga-ubuntu> stgraber: yes, it was regular permission in the end
<zyga-ubuntu> stgraber: that issue is fixed now snap-confine is now setgid root
<zyga-ubuntu> stgraber: thank you :)
<zyga-ubuntu> stgraber: also chasing (and almost fixed) the bug where snaps don't get removed in LXD
<stgraber> zyga-ubuntu: oh, any idea why rebooting would solve it?
<zyga-ubuntu> stgraber: ah, no, not that one
<zyga-ubuntu> stgraber: sorry, no idea what caused that
<zyga-ubuntu> stgraber: we tried to reproduce it in the morning without much luck, there's an etherpad with some details: http://pad.ubuntu.com/Wkp2bPRAnI
<zyga-ubuntu> mvo: tentative, probably something I need to discuss with jdstrand https://github.com/snapcore/snapd/compare/master...zyga:fix/lxd-remove-bug?expand=1
<zyga-ubuntu> actually
<zyga-ubuntu> the commit message is stale, one sec
<mvo> zyga-ubuntu: so I think the problem is that we disable apparmor in debian, this leads to the zero byte file. do you think we should unconditionally enable apparor in debian now? or just install the apparmor profile for snapd and leave the rest as is? (cc jdstrand )
<stgraber> zyga-ubuntu: left a comment in the pad about setup but yeah, it's certainly not trivial to reproduce as I tried a dozen other systems here and none of them are affected despite all of them also being 16.04 with live patch
<jdstrand> mvo: I think the idea was that we would enable 'partial' support in Debian, which would mean all the policy is in place. zyga-ubuntu was working towards that
<mvo> jdstrand: ok, I will go with that then
<jdstrand> zyga-ubuntu: this is a short week for me. I have 4170 and 4109 on my list for reviews this week. is there anything else pressing?
<jdstrand> (reviews for you that is)
<jdstrand> zyga-ubuntu: are both of those ready for me to review?
<zyga-ubuntu> mvo: yes, we should enable apparmor in debian now
<zyga-ubuntu> stgraber: thank you, I'll check in a moment
<zyga-ubuntu> jdstrand: yes, I think we can use partial policy
<zyga-ubuntu> jdstrand: 4170 is good, as is 4224
<zyga-ubuntu> jdstrand: 4109 is optional, we can close it if you want; I can just take a small refactoring patch and propose it separately
<zyga-ubuntu> *separately
<zyga-ubuntu> jdstrand: if we focus on this we could do most or all of layouts this week, if we get to a quick feedback cycle for PRs each dayt
<zyga-ubuntu> *day
<zyga-ubuntu> jdstrand: we are just a few PRs short of this now, most of the code is in, just some glue is left
<zyga-ubuntu> jdstrand: all my PRs are ready to review, except for the one that's marked as "blocked"
<jdstrand> zyga-ubuntu: so, 4170 and 4224 require reviews from me (and optionally 4109). correct?
<zyga-ubuntu> jdstrand: yes
 * jdstrand adds 4224
<jdstrand> thanks
<flexiondotorg> elopio: Hi
<flexiondotorg> I'm working on (just about finished) a language guide for creating snaps of Rust apps.
<flexiondotorg> I've use Parity as the example yaml.
<flexiondotorg> elopio: Can you explain why you are staging libc in the upstream parity yaml?
<kyrofa> elopio, I'm seeing a number of adt test failures that only include the autoremove output in the error string: https://pastebin.ubuntu.com/26006225/
<kyrofa> So they fail, but it doesn't say why
<kennyloggins> popey 's off today - hope all is cool with him & his cat Sky.
<kyrofa> Hey zyga-ubuntu, any progress on that other lxd issue?
<zyga-ubuntu> kyrofa: which one? (we have >> 1 now)
<zyga-ubuntu> kyrofa: the oldest remove bug?
<kyrofa> zyga-ubuntu, indeed
<zyga-ubuntu> kyrofa: yes, running main tests now, I'll work with mvo and jdstrand on reviewing this quickly
<kyrofa> zyga-ubuntu, wonderful, thank you!
<elopio> kyrofa: that's executing the command. We need something that will capture stderr for all those executions, and puts it in the test details.
<elopio> maybe an assertCommandOutput, or something.
<kalikiana> kyrofa: that looks like the binary couldn't be run - although I could be mistaken
<magicaltrout> anyone tried jdbc connections with that mysql snap part from nextcloud?
<mup> PR snapd#4255 closed: interfaces/screen-inhibit-control: fix case in screen inhibit control <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4255>
<kyrofa> elopio, ah, okay
<elopio> I upgraded to bionic and you will never guess what happened next...
<elopio> no wifi disconnections the whole morning!
<kyrofa> elopio, ah! Amazing!
<kyrofa> elopio, so I see you haven't learned your lesson :P
<kalikiana> elopio: I would've recommended trying from a USB stick first... which is funny because our risk aversity is reversed in non-digital life, like cross streets
<elopio> I haven't been trained for non-digital life.
<zyga-ubuntu> kyrofa: https://github.com/snapcore/snapd/pull/4258
<mup> PR #4258: cmd/snap-confine,tests: fix unmounting on systems without rshared / <Created by zyga> <https://github.com/snapcore/snapd/pull/4258>
<mup> PR snapd#4258 opened: cmd/snap-confine,tests: fix unmounting on systems without rshared / <Created by zyga> <https://github.com/snapcore/snapd/pull/4258>
<zyga-ubuntu> jdstrand: please look at that PR briefly to see if it's on the right track
<kyrofa> Nice work zyga-ubuntu, thanks for hacking on that
<kalikiana> elopio: your parents raised you through a webcam?
<elopio> kalikiana: no, but that's not a bad idea. Maybe I can take some coursera classes to learn how to deal with the city :)
<zyga-ubuntu> hmm
<zyga-ubuntu> snapd fails on 4.14
<zyga-ubuntu> in bionic
<niemeyer> Weird.. I thought we had discussed and agreed not to release the progress bar making use of ASCII background color
<niemeyer> But stable apparently has it
<gsilvapt> hello all
<gsilvapt> Anyone with experience writing tests for snapcraft?
<pstolowski> niemeyer, ok, i've found the problem with taskrunner
<niemeyer> pstolowski: Oh! Tell us!
<zyga-ubuntu> pstolowski: I'm curious now
<gsilvapt> kyrofa, maybe you could help finish this issue :p
<gsilvapt> Maybe I'm using click framework poorly but I am not 100% sure
<pstolowski> niemeyer, zyga-ubuntu so my hunch about run-hook not having undo handler was correct, but I missed the fact that fixing this in hookmgr doesn't affect the tests (because test register own handler with undo=nil). so yes, when taskrunner sees undo handler == nil, it immediately transitions from UndoStatus -> DoneStatus, disregarding any other tasks. so if the hook task was a prerequistite of some other task, that other task gets unblocked immediately
<pstolowski> so the culprit is in the block of code marked with // Cannot undo. Revert to done status.
<kalikiana> gsilvapt: what're you up to? I have more experience with tests than I ever asked for :-P
<gsilvapt> kalikiana, basically I'm implementing a method to retrieve snapcraft's version by calling a command snapcraft version
<gsilvapt> Using click, I think I have properly defined this implementation.
<kalikiana> ah, nice
<niemeyer> pstolowski: I still don't see how that's a problem
<gsilvapt> But, when I wrote the test, I can see the exit_code = 2, which I cannot find in that definition so I have no idea what that means and/or if the method is implemented properly
<gsilvapt> the method = mine
<niemeyer> pstolowski: In particular, your last statement about unblocking immediately sounds like exactly what we want
<kalikiana> gsilvapt: is the code you're talking about in a branch? I think I need some more context to be helpful
<gsilvapt> kalikiana, well, I created my own branch to write my own code but I can send you a pastebin or something
<pstolowski> niemeyer, the hook task is part of the chain where every task waits for the next one; so suddenly a task in the middle of the chain is considered Done, regardless of the tasks following it
<kalikiana> gsilvapt: sure, pastebin is fine, whichever is convenient
<niemeyer> pstolowski: Again, that's exactly what we want
<niemeyer> pstolowski: Tasks *following* it will *follow* it
<gsilvapt> kalikiana, https://gist.github.com/anonymous/4064b69dbd96ac9fcea88747fc0d178d
<niemeyer> pstolowski: Which doesn't mean you are wrong.. I just don't see what the actual issue is yet
<pstolowski> niemeyer, adding non-nil undo handler (that does nothing) to run-hook in the test immediately fixes the out-of-order tasks. this cannot be right
<gsilvapt> kalikiana, if you need some help reading my code, let me know. I'm new around and only started learning how to code properly in September or so - please be patient :D
<niemeyer> pstolowski: Which out of order tasks?
<niemeyer> pstolowski: Again.. it all sounds quite vague
<magicaltrout> so..... is there a size limit on snaps?
<kyrofa> gsilvapt, that looks good, but does not look complete
<niemeyer> pstolowski: If a task B has A ordered before it, and A is done, B is immediately unblocked
<niemeyer> That's what we want
<kyrofa> gsilvapt, you need to actually _use_ it in cli/__init__.y
<gsilvapt> Hum, can you say what is missing in abstract terms? Maybe I can think of something to complete it
<pstolowski> niemeyer, http://pastebin.ubuntu.com/26006783/
<niemeyer> pstolowski: Ok, what should I look at there?
<gsilvapt> kyrofa, so I need to change the @click.version() bit?
<pstolowski> niemeyer, HO?
<kyrofa> gsilvapt, go into the cli directory, and grep around for "help"
<niemeyer> pstolowski: Sure
<kyrofa> gsilvapt, no, you need to actually hook your new subcommand into snapcraft
<kyrofa> gsilvapt, look for how the help command is done
<niemeyer> pstolowski: Waiting in the standup
<kyrofa> You can grep for "helpcli" as well
<kalikiana> gsilvapt: one thing I notice is the except ImportError - maybe not the issue you were asking about, but I'd say if you are running this code, snapcraft is installed... so you shouldn't need that at all
<gsilvapt> kalikiana, what if the user does not have snapcraft installed?
<gsilvapt> kyrofa, thank you, I'll look at the example and see if I can figure this out
<kalikiana> gsilvapt: think about it. the code is part of snapcraft
<kalikiana> unless I misunderstood what you're trying to do
<kyrofa> gsilvapt, sure. Sorry for letting you pound your head on this, but it really is the best way to learn things sometimes! Let me know if you need another hint
<gsilvapt> kyrofa, please do not apologise for that! This helps me understand what is going on and learn how to do stuff so yes, this is actually better!
<gsilvapt> kalikiana, all packages will return no package found 'package-name' so I think this command should return the exception it could not find snapcraft installed in the system
<gsilvapt> Perhaps the Exception is poorly designed and thus is confusing you but maybe we can work it out too
<kalikiana> gsilvapt: just to be clear: will this code be part of snapcraft?
<kalikiana> or another tool?
 * kalikiana needs to change location, will be back in a few minutes
<gsilvapt> kalikiana, I did not follow entirely
<kalikiana> gsilvapt: will version.py be part of snapcraft or a different project?
<gsilvapt> kyrofa, it worked.Thank you!
<kyrofa> Awesome!
<gsilvapt> part of snapcraft, under cli
<gsilvapt> Did not know we had to import things and tell cli which to consider. Makes sense though!
<kennyloggins> elopio: What channel is this on, again in #freenode ? https://twitter.com/d3fc0n3/status/932649813090369536
<magicaltrout> kyrofa: niemeyer whats the snap upload limit?
<kyrofa> magicaltrout, I don't know that there is one
<magicaltrout> well i get internal server error and proxy error on snap push
<magicaltrout> which is reminicent of the juju resource upload issue
<magicaltrout> https://gist.github.com/buggtb/2a5ebbb7f779a1e35a6329306c85c18c
<elopio> kennyloggins: there are many ubuntu channels, it depends on who you want to thank :)
<gsilvapt> kalikiana, any suggestion? I want to understand your point before submitting the push and the consequent PR
<kennyloggins> elopio, I just thought it was an ubuntu - with a rallying point, my mistake (again).
<kennyloggins> **ubuntu-day
<elopio> kennyloggins: the rallying point is the hub, https://ubu.one/ucaday
<kalikiana> gsilvapt: Right. So what I'm saying is, the code will only be executed if snapcraft is installed, or you run it from git - so you don't need to handle the case where the import fails, because other code makes sure it works
<gsilvapt> kalikiana, so I should remove the try and except bit and just leave the command?
<kalikiana> gsilvapt: Yup
<gsilvapt> Ok, I will submit the push + PR now
<gsilvapt> Thank you, kalikiana and kyrofa
<niemeyer> magicaltrout: That's a pretty big snap indeed.. I suggest asking in the forum about what the limit is
<niemeyer> magicaltrout: #store category
<magicaltrout> thanks
<gsilvapt> Well, now comes the tricky part. I also included a test but should I run something else aside from this, kyrofa?
<kyrofa> gsilvapt, I suppose that depends on the test you wrote. Can I see it?
<gsilvapt> Basically, it is a repetition of the one already there for --version. As mentioned in LP it should return the same.
<gsilvapt> But, here's a gist: https://gist.github.com/gsilvapt/41de75a1a920e0ec93163091f1960a05
<kyrofa> elopio, can I get a review on snapraft#1743 when you're able?
<kyrofa> Uh. snapcraft#1743
<mup> PR snapcraft#1743: catkin plugin: support building entire workspace <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1743>
<kyrofa> gsilvapt, no need to print. That seems fine to me
<kyrofa> gsilvapt, propose it!
<gsilvapt> Thank you!
<kyrofa> gsilvapt, you'll get more feedback in the pull request
<gsilvapt> Yes, I'm expecting that. Hopefully nothing too diminishing, hehe :-)
<gsilvapt> Is there a way to check if I've signed the CLA? I'm pretty sure I did but I want to check first
<kyrofa> gsilvapt, make sure the commit message looks like this: https://pastebin.ubuntu.com/26007003/
<kyrofa> gsilvapt, make a PR and it'll check to ensure you've signed
<kyrofa> Assuming the email address under which you're committing is also in your LP account
<pstolowski> niemeyer, ha, so the fix we discussed is correct and we have 2 test checks in snapstate_test built around wrong assumption ;). PR is coming
<gsilvapt> Right, thank you remembering that kyrofa
<mup> PR snapcraft#1746 opened: Implemented method to get snapcraft version <Created by gsilvapt> <https://github.com/snapcore/snapcraft/pull/1746>
<kalikiana> gsilvapt: I added a comment on the test - instead of the print I think it'd be better to compare the value to the expected version with Equals or Contains
<gsilvapt> Bah, I'm an idiot. That was not suppose to be there -.-
<gsilvapt> Thank you for letting me know. Lets see if I don't screw this up while trying to squash commits
<zyga-ubuntu> drat
<mup> PR snapd#4259 opened: snapd: fix handling of undo in the taskrunner <Created by stolowski> <https://github.com/snapcore/snapd/pull/4259>
<pstolowski> niemeyer, ^
<gsilvapt> kalikiana, you prefer your method instead of just assertThat()?
<gsilvapt> The print statement is obviously a mistake. On Saturday night I was working on this and the exit_code = 2 was driving me nuts. This was a desperate attempt to try to see what value the method was returning
<gsilvapt> how do you squash commits though? Rebase?
 * zyga-ubuntu considers EODing
<mup> PR snapd#4258 closed: cmd/snap-confine,tests: fix unmounting on systems without rshared / <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4258>
<zyga-ubuntu> jdstrand: I closed 4258 as it doesn't seem to work in linode, I need to look at that (doing so now) but it's not worth reviewing until I do
<kyrofa> zyga-ubuntu, how sad
<kyrofa> gsilvapt, yeah, run `git fetch` and then run `git rebase -i origin/master`
<kyrofa> Assuming `origin` is the remote name for upstream
<gsilvapt> kyrofa, so do changes, add/commit, fetch, rebase and force push to my repo?
<gsilvapt> I think I have to do force push after rebase, not sure
<kyrofa> gsilvapt, assuming you've already pushed, yes, you'll need to force
<gsilvapt> What do you mean assuming I have pushed?
<kyrofa> gsilvapt, if you haven't pushed, then you don't need to force in order to push
<kyrofa> (since there's nothing up there for it to conflict with
<gsilvapt> Ok, let me give that a try
<kyrofa> )
<gsilvapt> kyrofa, I think I have to force because it now says by branch is behind its remote counterpart
<kyrofa> gsilvapt, which means you pushed it
<kyrofa> So yes, you need to force
<gsilvapt> No, I was holding for instructions
<gsilvapt> I pushed before when I wanted to submit the PR, not after
<gsilvapt> Well, it worked I think
<jdstrand> zyga-ubuntu: I provided some feedback
<zyga-ubuntu> jdstrand: thank you
<gsilvapt> kyrofa, one question: Can you help me understand this? https://travis-ci.org/snapcore/snapcraft/builds/304902240?utm_source=github_status&utm_medium=notification
<gsilvapt> I know what CI is but I never worked with it more closely
<zyga-ubuntu> jdstrand: I replied on some of the feedback, thank you for looking
<zyga-ubuntu> jdstrand: the problem is that snapd is too late and cannot be the one fixing this, it must be genuinely something in the distro package
<zyga-ubuntu> jdstrand: (or snapd before reexec, perhaps)
<zyga-ubuntu> jdstrand: but really it must happen before apps start running
<kyrofa> gsilvapt, yeah, you need to run ./runtests.sh static
<gsilvapt> but I did :o
<zyga-ubuntu> jdstrand: I tried several other approaches, including a .mount unit (so that systemd would do it) but systmed is insufficient
<kyrofa> gsilvapt, take a look: https://travis-ci.org/snapcore/snapcraft/jobs/304902243#L1094
<gsilvapt> Hum, weird. Lets give that another look
<zyga-ubuntu> jdstrand: ideas (any, I will gladly investigate their viabilty are welcome)
<gsilvapt> Thanks kyrofa
<kyrofa> elopio, where is the bot?
<kyrofa> elopio, I can't run adt
<gsilvapt> kyrofa, is it possible to run Travis for every commit pushed to a given repo? This is not entirely related with Travis but a personal curiosity
<kyrofa> gsilvapt, yes
<gsilvapt> Without needing PRs, I meant
<kyrofa> gsilvapt, right, still yes :)
<gsilvapt> Ok, thank you :)
<jdstrand> zyga-ubuntu: I gave several ideas to look into with: https://github.com/snapcore/snapd/pull/4258#pullrequestreview-77885255
<mup> PR #4258: cmd/snap-confine,tests: fix unmounting on systems without rshared / <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4258>
<jdstrand> zyga-ubuntu: the thrust of each idea is that snapd in lxd can detect if it is running in a container and do something. what that something is needs investigating. maybe it creates different .mount files for the snaps. maybe different .service files. maybe it performs an operation on /, maybe something else
<elopio> kyrofa: ^
<zyga-ubuntu> jdstrand: if we can start from clean slate then we might do something else
<zyga-ubuntu> jdstrand: iff we can have control before snap units are mounted, we can do one operation (bind mount /snap over)
<zyga-ubuntu> jdstrand: I did succeed in doing that with a mount unit but it was _not_ rshared at that stage
<zyga-ubuntu> jdstrand: but systemd cannot both bind mount and rshare
<zyga-ubuntu> jdstrand: perhaps my earlier approach, with a /snap mount unit (just bind mount) and snap-confine that just does equivalent of mount --make-rshared /snap will do
<zyga-ubuntu> jdstrand: the key is that we must do this before 1st snap runs and unshares a mount namespace
<zyga-ubuntu> jdstrand: think about this and let me know, I'll iterate tomorrow
<jdstrand> zyga-ubuntu: that is what I was thinking. this is all within lxd, no? if so, you have to run the snap command to install anything, therefore, you have an opportunity to do what you need. rather than make systemd do bind mount with rshared, just have a teensy tiny helper that does that, put that in a service file that you conditionally use if in a container
<zyga-ubuntu> jdstrand: this also affects 14.04
<jdstrand> the helper could be in the upstart job or whatever too
<zyga-ubuntu> jdstrand: we have that helper but it's not working
<zyga-ubuntu> jdstrand: because it runs after snap units are mounted
<zyga-ubuntu> jdstrand: and then there are two entries
<zyga-ubuntu> jdstrand: and that causes the bug
<zyga-ubuntu> jdstrand: one before bind+rshare, one after
<zyga-ubuntu> jdstrand: this also confuses systemd so stopping mount units doesn't work
<zyga-ubuntu> (it hangs)
<jdstrand> I don't claim to have all the details, but in my head: sudo snap install foo -> am I in a container? -> yes, add unit file with helper to bind/rshared /snap -> start unit -> proceed with install
<zyga-ubuntu> jdstrand: but I think the approach can be made to work with a combination of mount units (those have dependencies so we could get correct ordering) and a bit of code in snap-confine (easy guarantee to run before we construct snap namespace)
<jdstrand> there are certainly details to be worked through
<zyga-ubuntu> jdstrand: that won't work after reboot
<jdstrand> you can make it work
<zyga-ubuntu> jdstrand: again, the order of mount operations (either via systemd or helpers) is crucial
<zyga-ubuntu> jdstrand: but yes, the /snap mount unit is a trick we should use here
<jdstrand> make that service file a noop for the default case and all mount units start after it. if in container, then tweak the unit to run the helper
<zyga-ubuntu> jdstrand: then we need to tweak all mount units to have before/after stanazas to order themselves
<jdstrand> or similar
<zyga-ubuntu> jdstrand: I think it's all solvable
<jdstrand> we are the ones writing the mount units, no?
<jdstrand> I see, yes
<jdstrand> you were saying what needs to be done, not objecting
<zyga-ubuntu> jdstrand: yes but curretly snapd has no facility to correct the mount units (we have another bug pending on tihs)
<zyga-ubuntu> jdstrand: again, I agree, it's just steps to get there
<jdstrand> 2 bug fixes for the price of one! :)
<zyga-ubuntu> jdstrand: and some bugs in systemd that cause this to be harder than it has ot
<zyga-ubuntu> *to
<zyga-ubuntu> jdstrand: (the other bug is 14.04 mount ordering)
<zyga-ubuntu> jdstrand: offtopic, did you have a chance to look at the two PRs for snap-update-ns?
<jdstrand> zyga-ubuntu: I'm looking at 4170 now. I already gave a quick comment you may want to consider
<zyga-ubuntu> looking
<zyga-ubuntu> man, that PR will never land
<zyga-ubuntu> I restarted tests >> 20 times on it
<zyga-ubuntu> something always fails
<zyga-ubuntu> store hicckup, some racy test here or there ://
<jdstrand> zyga-ubuntu: the good thing is that when it does, no other PR will land :P
<jdstrand> *sigh*
<jdstrand> I had a racy test that had a similar issue
<jdstrand> so I feel your pain
<zyga-ubuntu> jdstrand: master is super super unreliable recently
 * jdstrand nods
<zyga-ubuntu> jdstrand: and we are playing the game of "flip a coin N times, ensuring it's heads each time" while incrementing N
<zyga-ubuntu> jdstrand: so I maybe agree if your proposal is undo-safe
<zyga-ubuntu> jdstrand: note that we may be asked to completely undo any of this
<zyga-ubuntu> jdstrand: and that the typical situation, nothing is hidden under the tmpfs mount
<gsilvapt> kyrofa, I saw your comment. I'll try to see what can I do. I already did a test that checks if both commands' outputs are the same. Now I have to see what you meant with duplicating click's template
<zyga-ubuntu> jdstrand: (apart from a fragment of a squashfs mount)
<zyga-ubuntu> jdstrand: the simple approach I took guarantees (I hope, prove me wrong please) that I can always undo
<zyga-ubuntu> jdstrand: and create another layout
<jdstrand> zyga-ubuntu: that might be a case for needing the contents of the mounted over directory
<kyrofa> gsilvapt, just run `snapcraft --version` and compare the output to `snapcraft version` and you'll see what I mean
<kyrofa> gsilvapt, what timezone are you in, by the way?
<zyga-ubuntu> jdstrand: I also toyed with one more ideqa
<zyga-ubuntu> *idea
<zyga-ubuntu> jdstrand: iff it's a good assumption that we can look at hostfs, we can fish the snap mounts there
<zyga-ubuntu> jdstrand: but it's not generic as the same code should be useful for poking holes in various places that are not just /snap
<zyga-ubuntu> jdstrand: and while it's possible to find the same place in hostfs it may have been changed by the hardcoded mount commands in snap-confine
<gsilvapt> kyrofa, GMT
<gsilvapt> kyrofa, I have to learn how to setup a testing environment for this. The last time I tried I ended up deleting most stuff andsuch
<gsilvapt> I understand the outputs are different, the test is being rejected currently. I just am not too comfortable with Click yet :P
<kyrofa> gsilvapt, yeah you don't need to change click, just `click.echo` something that makes the `version` command echo the same thing as what you see `--version` doing
<gsilvapt> kyrofa, this might take too much time. I'm having issues with python and pip again...
<kyrofa> gsilvapt, what's up?
<gsilvapt> I can't use pip3 and I only want to use python3
<gsilvapt> Every command I run using pip3 gives a common _NameSpace Attribute Error which was previously solved by updating setuptools, wheel and/or pip. None of those work
<kyrofa> Ouch
<gsilvapt> I messed this up badly. And this is something I can't just uninstall and reinstall
<zyga-ubu1tu> jdstrand: I was thinking about the writable aspect of the mimic, perhaps we should actually bind mount without "ro"
<zyga-ubu1tu> if the substrate is read only, it doesn't change anything
<zyga-ubu1tu> if for whatever reason it is not, we should mount as writable
<zyga-ubu1tu> as for rbind vs bind, if we rbind we must understand what we did or we cannot undo this
<zyga-ubu1tu> so that feels like "bind now, rbind and be smarter about undo later"
<jdstrand> zyga-ubu1tu: that works for me (both)
<jdstrand> just update the comment on rbind to not be a question and be either a TODO or Note
<jdstrand> zyga-ubu1tu: if you make non-comment changes, happy to review tomorrow
<zyga-ubu1tu> yes, I'll make all the changes and iterate, thank you for the insight!
<jdstrand> thanks for the PR :)
<zyga-ubu1tu> jdstrand: btw, one more thing to think about -- once we do full layouts I only expect to tweak confinement (allow more things) and add blacklists (to prevent known unsafe ops), I hope nothing else has to change (in a major way)
<jdstrand> that's going to be the tricky part
<zyga-ubu1tu> jdstrand: I think the trick (ha) is the tmp bind mount
<jdstrand> making sure we don't accidentally allow /etc/shadow into the app's area
<gsilvapt> kyrofa, regarding the feature, could you tell me some pointers I could look at? While this thing updates and reinstalls stuff, I'm trying to figure out a solution but I confess I am not seeing where the return string is built
<jdstrand> I'm not sure a blacklist is the way to go, but also don't know what you are thinking about. we can discuss that in the PR
<zyga-ubu1tu> jdstrand: yes, we need deny rules in the profile, deny mounts for /etc and /{run/}media, for special places /{proc,sys,dev}
<kyrofa> gsilvapt, did you run `snapcraft --version`?
<zyga-ubu1tu> jdstrand: ok
<gsilvapt> yes
<kyrofa> gsilvapt, what was its output?
<gsilvapt> snapcraft, version ***
<gsilvapt> in this case, 2.35
<kyrofa> gsilvapt, and `snapcraft version` prints what?
<gsilvapt> 2.35
<mup> PR snapd#4260 opened: Stop various JSON field from being sent with null values <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/4260>
<mup> PR snapd#4257 closed: interfaces/opengl: also allow read on 'revision' in /sys/devices/pci <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4257>
<kyrofa> gsilvapt, so instead of making `snapcraft version` print just the number, make it print "snapcraft, version 2.35"
<gsilvapt> kyrofa, guide me on this one: How do I compile snapcraft 2.35?
<gsilvapt> I'm going around in circles here. I've tried branching to 2.35 and then running the requirement install phase but always get this Can't install 'snapcraft'. No files were found to uninstall. error
<gsilvapt> Note: pip, wheels, setuptools and virtualenv are up-to-date
<gsilvapt> kyrofa, it seems that running pip install wheel and python setup.py bdist-wheel has solved the issue
<gsilvapt> Or not. Can't compile Snapcraft: https://pastebin.com/HgjMwDSx
#snappy 2017-11-21
<gsilvapt> I don't know what I did but it worked. Ok, lets get this done
<gsilvapt> kyrofa, I don't want to do this by hardcoding the string before returning the version number. Besides, it is not testable because the click method will return "run, version xxx \n" and it is not comparable. Any alternative I'm not thinking of?
<gsilvapt> return in the tests
<mup> PR snapd#4261 opened: test: ignore /snap/README <Created by mvo5> <https://github.com/snapcore/snapd/pull/4261>
<mborzecki> morning everyone
<mborzecki> mvo: https://addons.mozilla.org/en-US/firefox/addon/noscript/versions/
<mvo> hey mborzecki ! yeah, I have it installed already :-D I'm (mostly) a happy puppy again
<mborzecki> hahaha ;)
<mup> PR snapd#4261 closed: test: ignore /snap/README <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4261>
<mborzecki> uhh travis killed a job because the log is > 4MB
<mborzecki> https://s3.amazonaws.com/archive.travis-ci.org/jobs/305083520/log.txt?X-Amz-Expires=30&X-Amz-Date=20171121T063527Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJRYRXRSVGNKPKO5A/20171121/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=baac296620d373b75ce53d3ec299699b38b4620d3b9af63ba054c9a679db6d27
<zyga-ubuntu> mvo: thank you for the README branch
<zyga-ubuntu> mvo: how did you run into that issue?
<mvo> zyga-ubuntu: I saw it in travis
<zyga-ubuntu> mvo: do you think it was a random failure? I never saw something like that
<zyga-ubuntu> mvo: shall I merge 4239?
<mvo> zyga-ubuntu: 4239> yeah, please do
<mvo> zyga-ubuntu: I think it was order dependent, yes, i.e. in what order things got run
<mup> PR snapd#4239 closed: tests: more debug info for classic-ubuntu-core-transition <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4239>
<mvo> zyga-ubuntu: ta
<mborzecki> can you take a look at https://travis-ci.org/snapcore/snapd/builds/304678796 ? doesn't make much sense to me
<zyga-ubuntu> looking
<mborzecki> rm -rf /var/lib/snapd fails with : cannot remove /var/lib/snapd: Directory not empty
<zyga-ubuntu> hmm
<zyga-ubuntu> right
<zyga-ubuntu> no idea, I wish we had debug
<mvo> mborzecki: definitely strange, I suspect something is writing to the dir, so the rm(all_files_in_$dir), rmdir($dir) step fails because something sneaked files in but that is just a guess. indicates something was not stopped properly
<mborzecki> and it's rm -rf, that really stops for nothing
<zyga-ubuntu> mborzecki: yeah
<mborzecki> i'll restart the build
<mvo> pedronis: slightly crazy question - do you think we should have a "overlord/refreshstate", i.e. move all the refresh related bits out of snapstate into their own manager?
<mvo> pedronis: I'm slightly unhappy about the mixing we have in snapstate currently and wonder about the best way to untangle
<mvo> mborzecki: thanks
<mvo> mborzecki: http://paste.ubuntu.com/26010609/ will (sometimes) produce the same error: write(2, ": Directory not empty", 21: Directory not empty)   = 21
<mvo> mborzecki: so maybe/probably racy but the interessting question is of course what is left running and writes to that dir :/
<mborzecki> yeah, something must have been created between opendir() & listing and before rmdir()
<zyga-ubuntu> very curious
<zyga-ubuntu> mvo: actually
<zyga-ubuntu> mvo: the & is sufficient
<zyga-ubuntu> mvo: no wonder this fails
 * zyga-ubuntu didn't see it on initial read
<mvo> zyga-ubuntu: you mean http://paste.ubuntu.com/26010628/ is the easier to read version? yes, I think you are right
<mvo> zyga-ubuntu: also fails more reliable :)
<zyga-ubuntu> yes, it's the same deal
<zyga-ubuntu> mvo: rm -rf is userspace, so we open and unlink elements recursively
<mvo> zyga-ubuntu: *nod*
<mvo> zyga-ubuntu: indeed
<zyga-ubuntu> mvo: but there is a concurrent writer that adds new entries
<mvo> zyga-ubuntu: yes, I really wonder what we kept running
<zyga-ubuntu> probably snapd
<mvo> zyga-ubuntu: hm, if we don't stop that that would be bad indeed, I have not looked yet but that sounds like something to dig into
<mborzecki> the test that failed was linode:ubuntu-14.04-64:tests/main/refresh:strict_fake and i think it failed in prepare step
<zyga-ubuntu> mborzecki: the problem is often the order of execution
<zyga-ubuntu> mborzecki: one test that ran 100 steps earlier may have failed to clean up
 * mvo is depressed about this
<zyga-ubuntu> mvo: I once patched spread to collect system info after each test
<mborzecki> how does spread 'soread' the tests? is it node per test or a bunch of tests per node?
<zyga-ubuntu> mvo: and before first test
<mvo> wonder if we should look into doing crazy stuff like runing things inside a systemd-run context that we can fully clean again
<zyga-ubuntu> mborzecki: it's N/constant where constant is number of machines of given type
<mvo> zyga-ubuntu: aha, yeah, that would be useful
<zyga-ubuntu> mvo: I think we cannot afford do that
<zyga-ubuntu> mvo: but I also think we cannot afford do not do something
<mvo> zyga-ubuntu: heh
<zyga-ubuntu> mvo: tests are just failing 90% of the time
<mvo> mborzecki: spread uses a work-steal model, not sure if that was the question though
<mvo> zyga-ubuntu: yeah, currently tests are really in a bad shape, its very annoying
<mborzecki> mvo: ta
<mborzecki> as for the state of the tests,  travis failing the job because the log > 4MB is also quite hilarious :)
<zyga-ubuntu> hmm
<zyga-ubuntu> mvo: do you remember my qemu snapshot code
<zyga-ubuntu> mborzecki: yes
<zyga-ubuntu> mborzecki: and the silly and very very slow javascript code that displays it
<zyga-ubuntu> mborzecki: the "full log" link should be at the top, not at the endless bottom
<mborzecki> hahah, yeah, all the parallelism work on ff and travis ui is still quite a challenge
<zyga-ubuntu> mvo: the LXD approach didn't work (yet), after discussing with jdstrand he suggested a hybrid of an earlier approach with some code in snap-confine (current approach was effectively unconfining s-c)
<mborzecki> zyga-ubuntu: there's raw log button on the right
<zyga-ubuntu> mborzecki: oh, I didn't see one
<mvo> zyga-ubuntu: hm, interessting (and also slightly sad). but at least there is a way forward
<pedronis> mvo: if you think  that it helps clarity it's worth a try
<mvo> pedronis: thank you, I think I give it a shoot and see what it looks like (as an experiment)
<pedronis> #4158 needs a 2nd review btw
<mup> PR #4158: snapctl: don't error out on start/stop/restart from configure hook during install or refresh <Created by stolowski> <https://github.com/snapcore/snapd/pull/4158>
<kalikiana> hrmpf, what a great start in the day, ecrypts bug corrupted my filesystem, now hopefully back to normal
<ikey> ow
<mup> PR snapd#4262 opened: store: do not log the http body for catalog updates <Created by mvo5> <https://github.com/snapcore/snapd/pull/4262>
<zyga-ubuntu> mvo: I'm looking into test failures, I'm patching spread and working with our test suites
<mborzecki> really wish the check package had subtests like `testing.T.Run()`
<zyga-ubuntu> mborzecki: yeah, agreed
<zyga-ubuntu> mborzecki: gustavo maintains check so ... probably we can patch it
<mborzecki> i suppose
<mvo> mborzecki: pardon my ignorance but could you expand on the subtests a bit, a link or something?
<mborzecki> mvo: https://godoc.org/testing#T.Run
 * mvo looks
<mborzecki> let me find a snippet
<mvo> mborzecki: aha, interessting. I think I get the idea
<mborzecki> the nice thing is that go test -run  will match agains subtest names
<mborzecki> mvo: https://github.com/mendersoftware/deviceauth/blob/master/api/http/api_devauth_test.go#L868 for instance this function will appear as TestApiDevAuthGetLimit/0, TestApiDevAuthGetLimit/1, TestApiDevAuthGetLimit/2..
<mvo> mborzecki: you can run a subset of the tests with check via "go test -check.f names"
<mvo> mborzecki: but of course not as powerful as I think what subtests are doing
<mvo> mborzecki: aha, nice
<mborzecki> -check.f is not helpful if there's a list of test cases and you loop over them
<mvo> mborzecki: yes :/
<mborzecki> FYI, I patched the check package to display diffs when values fail Equals, DeepEquals checks, the output looks like this: https://paste.ubuntu.com/26011308/
<zyga-ubuntu> ooh, shin
<zyga-ubuntu> shiny :)
<zyga-ubuntu> I wasted hours diffing manually over the years
<mborzecki> it's obviously nicer if there's a couple of fields: https://paste.ubuntu.com/26011319/
<mborzecki> i'm using github.com/davecgh/go-spew/spew and github.com/pmezard/go-difflib/difflib
<mvo> mborzecki: very nice
<Chipaca> mborzecki: while you're in there, can you make the output of pointers to structs show the structs and not just the pointers?
<zyga-ubuntu> oh, yes, that one is bugging me too
<Chipaca> mborzecki: "hahahaha lol no" is a valid answer fwiw
<mup> Issue snapcraft#1443 closed: new ament plugin (ros2) <designed> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1443>
<mup> PR snapcraft#1583 closed: ament plugin: new plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1583>
<mborzecki> Chipaca: https://paste.ubuntu.com/26011426/ like this?
<Chipaca> mborzecki: :-D
<Chipaca> mborzecki: that'll do
<mborzecki> pushed the changes to: https://github.com/bboozzoo/check/commits/bboozzoo/pretty-equals-not-equals
<mborzecki> note that it pulls in some extra dependencies, and the check package has none at this moment, I'd guess niemeyer would prefer it this way
<mborzecki> FWIW i think we could override Equals and DeepEquals checkers with our own, just assign them in some init() code in the tests
 * Chipaca <- drowning in a cascade of changes due to golang#22739
<mup> PR snapd#4263 opened: overlord/devicestate:  best effort to go to early full retries for registration on the like of DNS no host <Created by pedronis> <https://github.com/snapcore/snapd/pull/4263>
<Chipaca> zyga-ubuntu: remind me, where was it that you called â¦ was it mkdirat? in a loop, you had to open directories in a loop and keep a stack of file descriptors around
<pedronis> Chipaca:   cmd/snap-update-ns/utils.go  ?
<zyga-ubuntu> Chipaca: yes
<zyga-ubuntu> Chipaca: what are you thinking about?
<Chipaca> siiiigh
<Chipaca> zyga-ubuntu: yes
<Chipaca> zyga-ubuntu: so, i have good news, and bad news for yoou
<zyga-ubuntu> yes?
<zyga-ubuntu> I want bad news
<Chipaca> zyga-ubuntu: everywhere you see "uid int" or "gid int", it's wrong
<zyga-ubuntu> Chipaca: pff, ;-)
<zyga-ubuntu> Chipaca: we only use 0
<zyga-ubuntu> ;D
<zyga-ubuntu> Chipaca: what should I have used?
<Chipaca> func secureMkDir(fd int, segments []string, i int, perm os.FileMode, uid, gid int) (int, error) {
<Chipaca> ^ that signature is wrong in particular
<Chipaca> uint32
<zyga-ubuntu> but,...
<zyga-ubuntu> -1 is valid value
<zyga-ubuntu> so?
 * zyga-ubuntu is confused
<Chipaca> zyga-ubuntu: it's only valid because C doesn't give a fuck
<Chipaca> it's actually 0xf...f
<zyga-ubuntu> Chipaca: world is brutal
<Chipaca> but, in go on 32 bits, it breaks
<Chipaca> zyga-ubuntu: the good news is you probably don't need to change it in a hurry :-)
<Chipaca> i'm doing the cascade of changes in snapd and snap, i'll get to the ones in other places later
<Chipaca> zyga-ubuntu: am i right in thinking snap-update-ns shouldn't use osutil?
<Chipaca> oh you do already
<Chipaca> zyga-ubuntu: excellent :-)
<zyga-ubuntu> Chipaca: well
<zyga-ubuntu> Chipaca: apply restraint ;)
<Chipaca> zyga-ubuntu: there'll be drop-in replacements with the right signature in osutil/user
<Chipaca> replacements for chown, fchown, and chownat
<zyga-ubuntu> Chipaca: thank you!
<Chipaca> *fchownat
<brunosfer> Hi guys, does anyone knows a beginner tutorial on how to develop interfaces (slot - plug) between snaps?
<zyga-ubuntu> brunosfer: hey
<zyga-ubuntu> brunosfer: it's both easy and complicated, it's easy because it's not very hard but complicated but the way to do it changes over time as code evolves
<zyga-ubuntu> brunosfer: the best way to do it would be to post a topic on the fourm and look at how interfaces are implemented (look at the source tree in interfaces/builtin/)
<zyga-ubuntu> brunosfer: and try to implement a new one while talking to us
<zyga-ubuntu> mvo: I have a working and useful tool to measure damage to the test system
<brunosfer> zyga-ubuntu: Hey Ziga, I saw your tutorial and also you video with Kyle and Sergio, but it was a bit too much advanced since I'm not comfortable with golang.
<brunosfer> I'll follow your advice. Thanks
<zyga-ubuntu> brunosfer: then I don't think you are in a position to implement one, I'd suggest asking on the forum, we routinely implement new interfaces on request
<mup> Issue snapcraft#1713 closed: catkin plugin: support for building all packages in a given workspace <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1713>
<mup> PR snapcraft#1743 closed: catkin plugin: support building entire workspace <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1743>
<cachio> mvo, hey, running beta validation for 29.4
<brunosfer> zyga-ubuntu: Ok, thanks.
<cachio> so far no issues
<zyga-ubuntu> mvo: what's the best way to list apt packages?  dpkg --get-selections?
<niemeyer> Hellos
<zyga-ubuntu> niemeyer: o/
<zyga-ubuntu> mvo: I'm now running main to detect problems in the test suite
<zyga-ubuntu> mvo: I also pushed two branches for spread
<zyga-ubuntu> mvo: one is trivial fix, the other is this feature
<zyga-ubuntu> niemeyer: https://github.com/snapcore/spread/pull/46
<mup> PR spread#46: Don't crash if suite is empty <Created by zyga> <https://github.com/snapcore/spread/pull/46>
<zyga-ubuntu> (the bugfix)
<zyga-ubuntu> I'll propose the measurement after I get some more data about how it feels to use
<zyga-ubuntu> the actual diff is here if you want to see https://github.com/snapcore/spread/compare/master...zyga:measure-each?expand=1
<gsilva> kyrofa: you around?
<niemeyer> zyga-ubuntu: That's in
<kalikiana> gsilva: he's probably sleeping ;-) maybe I can help you?
<zyga-ubuntu> niemeyer: thank you
<mborzecki> niemeyer: i think there's something wrong with proposed day-in-week timer syntax and it's making the parser unnecessarily complicated, eg. mon1-wed3 - is that monday in first week until wednesday in 3rd week?
<mborzecki> niemeyer: then wed3-mon1 is that wed, 3rd week until monday 1st week, wrap around a month?
<niemeyer> mborzecki: We can forbid this syntax for now, so we can decide later how we want to interpret it, if at all
<niemeyer> In other words, N must be >= M on <weekday>N-<weekday>M
<niemeyer> Erm, the opposite
<niemeyer> In other words, N must be <= M on <weekday>N-<weekday>M
<mvo> cachio: thanks, keep me updated on the validate results
<mvo> zyga-ubuntu: `apt list --installed` maybe? depends what exactly you need
<mvo> zyga-ubuntu: spread> nice!
<zyga-ubuntu> mvo: yeah, I have something useful now
<Chipaca> zomg, http://git.savannah.nongnu.org/cgit/man-db.git/commit/src/man.c?id=002a6339b1fe8f83f4808022a17e1aa379756d99
<Chipaca> :-)
<niemeyer> cachio: Coming?
<mup> PR snapcraft#1747 opened: static tests: enable type checking by use of mypy <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1747>
<mup> PR snapcraft#1748 opened: kernel plugin: don't assume /lib/firmware is present if !kernel-with-firmware <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1748>
<zyga-ubuntu> sergiusens: woot, thank you for using mypy!
<zyga-ubuntu> sergiusens: I wonder if it found any issues in the code so far
<cpaelzer> in recent bionic proposed I see
<cpaelzer> ERROR: Syntax Error: Unknown line found in file /etc/apparmor.d/usr.lib.snapd.snap-confine.real line 15:
<cpaelzer>     include "/var/lib/snapd/apparmor/snap-confine.d"   /etc/ld.so.cache r
<zyga-ubuntu> cpaelzer: interesting, is there a bug?
<cpaelzer> I think the include has to start with a # right?
<zyga-ubuntu> cpaelzer: AFAIK no, it's just wonk
<cpaelzer> zyga-ubuntu: well I just happened to see it - no bug yet that I filed at least
<zyga-ubuntu> wonky
<cpaelzer> when I add a # to include I get things to work
<zyga-ubuntu> cpaelzer: can you pastebin that file?
<cpaelzer> sure
<zyga-ubuntu> cpaelzer: maybe something changed, odd
<cpaelzer> http://paste.ubuntu.com/26012174/
<zyga-ubuntu> cpaelzer: I'm in a call, I'll check it out in a moment (~20 minutes)
<cpaelzer> I actually wanted to set something else with aa-complain, but that reloads all profiles and the issue shows up
<cpaelzer> yeah let me know if I can help further, but I think a bionic container with proposed enabled and setting anything via aa-complain should trigger
<jdstrand> zyga-ubuntu: there needs to be a '#' in front of 'include'
<jdstrand> zyga-ubuntu: oh nm, I think the paste is probably wrong
<jdstrand> zyga-ubuntu: there is a missing trailing comma
<jdstrand> '/etc/ld.so.cache r' should be '/etc/ld.so.cache r,'
<jdstrand> meh
<jdstrand> it was the '#'
<jdstrand> irc hard
<jdstrand> yes, this: 'include "/var/lib/snapd/apparmor/snap-confine.d"' needs to be '#include "/var/lib/snapd/apparmor/snap-confine.d"'
 * jdstrand wonders how that made it through review let alone spread testing
 * jdstrand guesses the cache file was used
<zyga-ubuntu> jdstrand: does it? I read the spec somewhere and # was optional
<zyga-ubuntu> jdstrand: and it passes plenty of tests
<zyga-ubuntu> jdstrand: including one where that file (the included one) is not empty
<jdstrand> zyga-ubuntu: maybe it is optional in newer parsers? I didn't know it was optional
<zyga-ubuntu> jdstrand: anyway, something is broken, I'm just unsure what
<zyga-ubuntu> jdstrand: aha, that's very likely
<jdstrand> now that you mention it, I recall a discussion with upstream where they didn't care for the preprocessor-like syntax. I guess it was fixed
<jdstrand> curious that this is on bionic...
<jdstrand> anyway, add the '#' and it will all work. might be worth an apparmor bug for the inconsistency
<ppisati> sergiusens: how do i prepare a branch for an hotfix?
<zyga-ubuntu> jdstrand: agreed
<ppisati> elopio: kalikiana ^
<zyga-ubuntu> jdstrand: hey :)
<jdstrand> zyga-ubuntu: hello :)
<zyga-ubuntu> jdstrand: I'm not working on features today, I was so fed up with tests not passing I've patched spread and I'm chasing the test suite to find the leaking tests
<zyga-ubuntu> jdstrand: hopefully more green in the end
<jdstrand> that sounds wonderful
<zyga-ubuntu> jdstrand: in comparison to constant retries, yes
<jdstrand> zyga-ubuntu: and in case you feel that is a thankless job. thank *you* :)
<ppisati> oh, and btw, unit tests appear to be broken:
<ppisati> http://pastebin.ubuntu.com/26012262/
<ppisati> ...
<ppisati> ImportError: Start directory is not importable: 'unit'
<ppisati> that is unrelated from the above hot fix request, it's just that i can't unit test my patch on master due to this failure
<kalikiana> ppisati: what do you mean by "for a hot fix"? other than just creating a PR as usual...
<kalikiana> ppisati: regarding the tests, it should be `./runtests.sh snapcraft/tests/unit` now
 * kalikiana lunch
<pedronis> niemeyer: I'm taking a walk break, should be back in ~1.5h , likely a bit before
<niemeyer> pedronis: Sounds great
<mvo> is it just me or is "fedora-25" quite unhappy right now in our spread tests? I get "Error Failed to synchronize cache for repo 'update'"
<zyga-ubuntu> mvo: which is odd since the repo sync should be a NOP for almost EOLed distro
<zyga-ubuntu> mvo: this is something we should raise with linode on that other IRC network
<mvo> zyga-ubuntu: it is pretty consitently failing in my 4256 pr at least, I'm inclined to set to manual but we probably should look into updating to fedora-26 instead
<sergiusens> ppisati I don't understand the question
<zyga-ubuntu> mvo: +1 to set to manual, I will look at it as a part of the reliability focus
<sergiusens> zyga-ubuntu some mypy issues are just because the graph it creates cannot handle code in __init__.py so there are some workarounds; but it didn't really find anything major (which means us the snapcraft team can pat ourselves in the back)
<zyga-ubuntu> sergiusens: it's also incremental, I cannot wait to see how it plays in the long term on a large codebase
<zyga-ubuntu> sergiusens: and by incremental I mean that as you add annotations the results get more precise
<sergiusens> zyga-ubuntu yes, right now I am running it as the python plugin for vscode runs it but for the package `mypy --ignore-missing-imports --follow-imports=silent -p snapcraft`
<sergiusens> getting rid of missing imports is a bit of a pain to setup as MYPY needs its own PYTHONPATH equivalent, and following imports triggers a bunch of errors on code we do not control :-)
<jdstrand> niemeyer: hey, when you have a moment could you take a look at https://forum.snapcraft.io/t/mir-kiosk-mir-libs-auto-connection/2452/8
<jdstrand> niemeyer: hey, here is one that needs an architect: https://forum.snapcraft.io/t/manual-review-of-base-snaps/2839/3
<jdstrand> elopio: fyi, https://dashboard.snapcraft.io/dev/snaps/8294/ (ipfs-cluster) has a ton of passing revisions that aren't released
<niemeyer> jdstrand: Thanks for the pings
<jdstrand> elopio: oh, nm. that snap was revoked
 * jdstrand looks at the other one
<jdstrand> niemeyer: np
<elopio> jdstrand: yes, it's now upstream :))
<mvo> Chipaca: hm, I poked a bit at the idea using context but go 1.6 does not have http.Request.Context so this is all a bit cumbersome. or do we know how to workaround this already?
<Chipaca> mvo: we're using x/net/context aren't we?
<jdstrand> elopio: it was confusing because the alias request didn't include the url to the store, the request came from you, but your snap was revoked
<jdstrand> I got there eventually
<jdstrand> (though always including the store url is preferred ;)
<pedronis> Chipaca: but that cheats and doesn't redefine Request to have Contxt
<pedronis> me is confused
<pedronis> Chipaca: ah, no, I'm right, on pre 1.7 it cannot do anything withÂ Request itself
 * pedronis was looking at the wrong source file
<mvo> Chipaca: we do, seems just a bit cumbersome compared to go1.7 which has http.Request.{,With}Context()
<mvo> Chipaca: it seems for the approach that mborzecki suggested (check for the context log body flags) in the RoundTrip we need access to a context associcated with the http.request
<Chipaca> mvo: how so? aren't we creating the context ourselves by hand?
<Chipaca> and passing it by hand
<mborzecki> iirc there's httpctx package
<pedronis> Chipaca: it doesn't reach where we need to consult it
<mvo> Chipaca: yeah, what pedronis said
<Chipaca> time to bump to 1.7! \o/
<mvo> heh, yeah
<pedronis> yes
<Chipaca> mborzecki: httpctx is about responses, not requests :-/
<ppisati> sergiusens: at same point, while working on another patch, someone mentioned that the patch could be eligible as an 'hot fix', something like 2.35.1 instead of waiting for 2.36 entirely
<Chipaca> mvo: in any case, it's a rather large refactor, even if we had 1.7
<mvo> Chipaca: yeah, was mostly curious what it would look like
<Chipaca> ah
<mvo> Chipaca: I stop doing that now
<Chipaca> mvo: then try it with 1.7 :-)
<kalikiana> elopio: are you going to update the beta PR? I was going to check the results but it's behind master now
<Chipaca> or 1.10 even
<mvo> Chipaca: I did but when I wanted to spread test it things got a bit unhappy
<mvo> Chipaca: anyways, I think I poked at it enough, time to get back to $stuff
<sergiusens> ppisati who said that?
<ppisati> sergiusens: it was in a comment, during the review of a patch
<elopio> kalikiana: no, I'm going to propose an alternative.
<kyrofa> gsilva, I am now
<pedronis> niemeyer: I'm back btw
<niemeyer> pedronis: Cool.. give me 5 and I'll be with you
<mup> PR snapcraft#1748 closed: kernel plugin: don't assume /lib/firmware is present if !kernel-with-firmware <Created by piso77> <Closed by piso77> <https://github.com/snapcore/snapcraft/pull/1748>
<kalikiana> elopio: did I miss a discussion there? I recall you kind of hate that beta exists but the only alternative iirc was PRs with no commits pushed by hand
<elopio> kalikiana: https://github.com/snapcore/snapcraft/pull/1749/commits/a9c189064a3368c8712408d9bbaf48fe8915e195
<mup> PR snapcraft#1749:  tests: add a script to run autopkgtests in the ppa  <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1749>
<mup> PR snapcraft#1749 opened:  tests: add a script to run autopkgtests in the ppa  <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1749>
<mup> PR snapcraft#1750 opened: kernel plugin: don't assume /lib/firmware is present if !kernel-with-firmware <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1750>
<pedronis> niemeyer: I'm in snappy-devel
<gsilva> kyrofa: I replied in the PR my question but I am around if you want to discuss the issue here
<kalikiana> elopio: aaaaahhhh memory is returning, we did talk about the ppa
<ppisati> kyrofa: i replied to your comment
<jamesbenson> chipaca: ping....
<Chipaca> jamesbenson: hi
<jamesbenson> hey!
<jamesbenson> did you want to try to debug the snap issue?
<Chipaca> jamesbenson: sure
<Chipaca> jamesbenson: does it happen every time?
<jamesbenson> I'm not the best with network capturing stuff...
<jamesbenson> yes
<jamesbenson> hence the real time desire
<Chipaca> jamesbenson: you get an error which includes the url, yes?
<jamesbenson> the error was what was detailed in the forum.
<jamesbenson> it seems I can do everything but snap stuff.
<Chipaca> jamesbenson: and can wget fetch that url?
<Chipaca> or curl, if you don't have wget
<jamesbenson> https://paste.ubuntu.com/26013102/
<mvo> pedronis: re refactor of the autorefresh to make it easier to follow, how do you feel about something like https://github.com/snapcore/snapd/pull/4161/commits/36b10fc142a9558a1e0db8b543d7d591e6c9feb4 ?if that looks sensible I can do a followup that uses this pattern for catalogRefresh and autoRefresh, that will also make testing this in isolation a bit easier
<mup> PR #4161: snapstate: add support for refresh.schedule=managed <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4161>
<cachio> niemeyer, tell me when you are ready to work on the images
<niemeyer> cachio: Just trying to spike something quick and will be with you next
<cachio> niemeyer, sure
<jamesbenson> chipaca: ^^
<Chipaca> jamesbenson: does it download?
<Chipaca> jamesbenson: i can't tell from that pastebin
<Chipaca> oh
<Chipaca> jamesbenson: quote the url
<Chipaca> jamesbenson: it has &s in it, that are confusing the shell
<pedronis> mvo: looks reasonable, I think the Ensure call though should go in the main SnapManager ensure, no?
<pedronis> mvo: also it's always passing true to managed which doesn't seem right
<pedronis> I mean: &store.RefreshOptions{RefreshManaged: true} doesn't look right
<mvo> pedronis: great, thank you. I will work on fixing this and adding proper tests then. should I include it in this PR or do a followup (for easier review)?
<pedronis> mvo: IÂ don't know
<pedronis> mvo: my preference would be as prereqs, not as follow ups  (though that might get tricky merge wise)
<mvo> pedronis: sure, that sounds reasonable, let me do this
<mvo> pedronis: I will deal with the fallout, no worries, whatever is easiest for you to review
<pedronis> mvo: I think  doing this without worrying about managed and doing autorefresh and then reworking current branch would be best for me
<mvo> pedronis: ok
<pedronis> mvo: basically small new feature and refactor first,  new intersting feature on top
<mvo> pedronis: +1
<jamesbenson> Chipaca: connects, but just sitting there.  I think it'll time out.
<Chipaca> ah
<Chipaca> jamesbenson: i thought i'd lost you so i wrote it up in the forum
<Chipaca> jamesbenson: so if that hangs, you've got some sort of network issue
<Chipaca> jamesbenson: are you going through a proxy of some sort? (should you?)
<jamesbenson> so the snap url wget doesn't work...
<jamesbenson> the link you mentioned gowget, I can wget
<Chipaca> jamesbenson: right, so on the one hand, this isn't the weird RST issue we saw before
<Chipaca> jamesbenson: it looks more like a routing problem of some sort
<jamesbenson> chipaca: okay
<Chipaca> noise][: are you around?
<Chipaca> jamesbenson: given this, i'd hand it off to noise][ (or whoever he recommends) to figure out this aspect of it
<jamesbenson> okay, thanks a bunch chipaca.  Have a good night, I know it's getting close to closing time ;-)
<Chipaca> jamesbenson: it's either your routing is wrong, or internap's
<Chipaca> nah, still got an hour, but i'm taking a break and then going to be mobile (=> iffy network)
<jamesbenson> I think everything is good on this side.  ALl of the networking seems to work besides snap stuff...
<Chipaca> :-(
<jamesbenson> noise][: ping
<noise][> hi
<jamesbenson> chipaca: yeah, I agree...
<jamesbenson> hi noise][ , wondering if you could follow me down the rabbit hole and help try to get this fixed ^_^
<jamesbenson> noise][: here's the main link: https://forum.snapcraft.io/t/snap-install-fails-in-a-lxd-container-on-an-openstack-vm/2870/8
<noise][> so if that wget is failing, i'd guess it's something with the NAT setup for lxd
<jamesbenson> essentially, I can install snap conjure-up, and try to deploy kubernetes, but it hangs on a supposed TLS issue... from what it seems, all networking is fine with everything else, except for snap
<Shibe> hey guys I heard that vulkan support was going to be added to snappy is there any status on that?
<Shibe> or is the pr still not merged?
<Chipaca> noise][: he was able to wget from people.c.c just fine though
<jamesbenson> yeah, I can wget everything except for snap stuff.
 * Chipaca afk
<jamesbenson> noise][:  just did this: http://paste.ubuntu.com/26013236/
<mup> Issue snapcraft#1751 opened: the go plugin doesn't use go build-snaps <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1751>
<mup> Issue snapcraft#1752 opened: export the arch triplet variable during build time <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1752>
<jamesbenson> noise][: this is what the status has been for a while wget'ing that new url: http://paste.ubuntu.com/26013260/
<mup> Issue snapcraft#1753 opened: catkin plugin: support needed for both python2 and python3 <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1753>
<noise][> jamesbenson: for kicks, try: wget 'https://api.snapcraft.io/api/v1/snaps/download/op76VXJUbTyfe4hHtC3apVYfnvN1FdIA_2.snap?cdn=local'
<jamesbenson> noise][:  just canceled the other wget (still sitting the same as the paste) issued the one above, works.
<noise][> ok, so something about the lxc NAT not playing nicely with internap
<jamesbenson> and this is all within my etcd/0 lxd container.
<noise][> i assume from outside the container the internap URL works ok?
<jamesbenson> yes, snap works fine outside
<jamesbenson> snap/internap url
<jamesbenson> noise][ : ^^
<noise][> jamesbenson: i'm unable to repro - if you could get a tcpdump of a failing attempt that might help us debug it
<jamesbenson> okay, can you tell me the commands... I don't do dumps/networking stuff like this much at all.
<jamesbenson> noise][: tcpdump -A -vvv host url
<noise][> 1s, let me crack up a sample - I don't do this terribly frequently
<niemeyer> Argh.. can of worms
<noise][> niemeyer: ?
<noise][> jamesbenson: something like:  sudo tcpdump -X -w /tmp/cdn_hang.pcap host 068ed04f23.site.internapcdn.net
<niemeyer> Sorry.. ECONTEXT.. I'm trying something out, and it's turning out to be a can of worms
<noise][> never fun.. time for a walk maybe :)
<jamesbenson> noise][: pastebin it?
<noise][> jamesbenson: it's a binary, so that's not too workable - can you file a bug at https://bugs.launchpad.net/snapstore and attach the pcap?
<jamesbenson> noise][: sure, when should I stop the dump?
<noise][> a few seconds even after hanging should be enough
<jamesbenson> noise][: it's only 24 bytes...
<jamesbenson> 262144 bytes
<Shibe> where is repository for snappy located?
<Shibe> is it on github?
<noise][> Shibe: https://github.com/snapcore/snapd
<kyrofa> sergiusens, can you take another pass on snapcraft#1725? We'd like to get that in, but you seemed uncertain about it
<mup> PR snapcraft#1725: tests: share the cache in ros tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1725>
<mup> PR snapd#4264 opened: tests: force delete when tests are restore to avoid suite failure <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4264>
<jamesbenson> noise][: https://bugs.launchpad.net/snapstore/+bug/1733660
<mup> Bug #1733660: Snap install fails in a lxd container on an openstack VM <Snap Store:New> <https://launchpad.net/bugs/1733660>
<noise][> uh, that's weird - 24 bytes
<noise][> jamesbenson: did you do the tcpdump from within the container also?
<jamesbenson> yeah, that was inside the container
<jamesbenson> Agreed, no real data...
<jamesbenson> you wanted this url though: 068ed04f23.site.internapcdn.net
<jamesbenson> ?
<noise][> maybe capturing on the wrong interface - what do you have for networks in that container?
<cachio> mvo, https://travis-ci.org/snapcore/snapd/builds/304678796#L3996
<cachio> the job canceled problem again
<noise][> jamesbenson: i'm away for a bit, if you can manage to get a non-empty capture i'll take a look a bit later
<jamesbenson> okay
 * kalikiana time for a break - will be around for a bit longer tonight, investigating the bugs I was fighting with this week, and available for pings if needed
<niemeyer> cachio: Alright, do you have some time for us to finish these images now?
<cachio> niemeyer, yes
<niemeyer> cachio: Okay, looking into sid first
<jamesbenson> noise][ Chipaca: are you sure, 068ed04f23.site.internapcdn.net is a valid url for the tcp dump?   no packets are captured in anything I do....
<niemeyer> cachio: It's still 200MB over the original image.. I'm going ahead with that, but it'd be nice to figure out why these images are growing so much
<cachio> niemeyer, I am not sure all the packages that zyga install in that image to upgrade that, I am adding this reasearch in my todo list
<niemeyer> cachio: In theory the update should preserve the image vaguely around the same size
<cachio> niemeyer, yes, I already cleaned up apt to delete unused packages
<niemeyer> cachio: Okay, debian-sid-64 is up and testable
<sergiusens> kyrofa get the mypy one in first
<cachio> niemeyer, running the suite now, in case it works I can change the name in the snapd/spread.yaml
<sergiusens> kyrofa then rebase ... that has too many things in __init__.py
<cachio> niemeyer, I'm creating a PR for that
<niemeyer> cachio: Thanks! Looking into debian-9 now
<gsilva> kyrofa: I'll talk to you soon about how we can use this method to get the same output. I'm not 100% sure yet and I'll bother you again pretty soon :-P
<niemeyer> cachio: debian-9-64 is up as well
<niemeyer> cachio: Please double check that latter one.. the disk name in Linode said "unstable".. perhaps it was just mislabeled, but worth confirming at least
<cachio> niemeyer, we used unstable as base to create it
<cachio> niemeyer, that could be the reason
<niemeyer> cachio: Yeah, that name reflects the label name used indeed
<cachio> niemeyer, should I add debian-9 to the regular snapd execution?
<cachio> niemeyer, or just sid
<niemeyer> cachio: Sounds worth having the stable revision too
<cachio> ok
<cachio> niemeyer, perhaps we will need to add extra linode machines to the exec
<cachio> otherwise we will out of machines
<niemeyer> cachio: Maybe.. but those usually run for a smaller amount of time
<niemeyer> cachio: In the sense that we don't run every single test there
<cachio> niemeyer, I'll push the change and see how those new images work
<niemeyer> cachio: Either way, it's a good point.. let's keep an eye on it
<niemeyer> Then let's please look again into Fedora
<cachio> niemeyer, #4265
<mup> PR #4265: New debian-sid-64 and debian-9-64 images for testing <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4265>
<cachio> let's see how it goes
<mup> PR snapd#4265 opened: New debian-sid-64 and debian-9-64 images for testing <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4265>
<niemeyer> cachio: Looking into Spread-46 for fedora-26-64
<niemeyer> cachio: That image has *4GB*
<niemeyer> cachio: Our current fedora-25-64 has 1.4GB.. that can't be right
<zyga-ubuntu> hmmm
<cachio> niemeyer, is there any way to access to it?
<zyga-ubuntu> https://alt.fedoraproject.org/cloud/
<zyga-ubuntu> base image is 134MB
<niemeyer> cachio: Yeah, I'm booting it back up
<niemeyer> cachio: Do you still have the reuse data?
<niemeyer> zyga-ubuntu: That's probably too little (no gcc, etc), but still..
<cachio> niemeyer, no, but I have the credentials
<cachio> niemeyer, let me check which are them
<zyga-ubuntu> niemeyer: they are xz compressed
<zyga-ubuntu> niemeyer: but around the right size for a cloud image I think
<cachio> niemeyer, do you have the ip?
<niemeyer> zyga-ubuntu: Yeah.. it can be more than that.. just 4GB sounds over the top.. we need to aim at around 1GB tops for a complete test image
<niemeyer> (with gcc, etc)
<zyga-ubuntu> sure, I just wanted to counteweight the 4GB one, that's like a desktop install
<niemeyer> zyga-ubuntu: That's like a desktop install with pirated movies
<zyga-ubuntu> niemeyer: haha
<zyga-ubuntu> :D
<cachio> :)
<zyga-ubuntu> niemeyer: wget http::/fedora.org/spins/xmen-2017-xvid.iso ;)
<zyga-ubuntu> (or whatever the xmas blockbuster is now)
<brunosfer> zyga-ubuntu: Is it possible to create an interface (slot) in a snap and a (plug) on another snap so they can communicate between each other without the need to access the interfaces on snapd?
<cachio> niemeyer, did you restore that backup image?
<brunosfer> zyga-ubuntu: Is it possible to create an interface (slot) in a snap and a (plug) on another snap so they can communicate between each other without the need to access the interfaces on snapd?
<pedronis> brunosfer: no, plug and slot are of an interface and those are all defined in snapd, so they need to be one of the preexisting interfaces or a new one added to snapd
<niemeyer> cachio: Hmm?
<niemeyer> cachio: The system is back up (Spread-46)
<niemeyer> cachio: Not sure if that's what you were asking?
<cachio> niemeyer, I need the ip to ssh it
<niemeyer> cachio: Still the same: 45.33.35.30
<cachio> niemeyer, tx
<cachio> niemeyer, it is weird because the vm is using 2.5GB of disk
<cachio> so I don't see how the image is of 4GB
<niemeyer> Fragmentation, maybe
<niemeyer> The image size is block-level.. it doesn't matter what the actual file sizes are
<niemeyer> Still, it's a surprising amount of fragmentation togo from 2.5 to 4
<cachio> niemeyer, it is weird
<cachio> because the kernel 4.12 s installed but that image is using the 4.9
<cachio> so, not sure if the changes were applied properly
<niemeyer> cachio: Yeah, that sounds bogus
<niemeyer> cachio: That image was just booted
<cachio> niemeyer, Neal made that change, I'll ping him once he is online
<zyga-ubuntu> niemeyer: maybe dd if=/dev/zero of=/zero; rm -f /zero
<niemeyer> cachio: So if there is more than one kernel, one of them can go
<zyga-ubuntu> niemeyer: should clean unused space
<cachio> niemeyer, but which shoul be the kernel to use?
<niemeyer> zyga-ubuntu: Huh?
<cachio> 4.9 or 4.12
<niemeyer> cachio: I would guess the latest
<zyga-ubuntu> niemeyer: that's what I do before snapshotting a VM image
<niemeyer> zyga-ubuntu: Okay, but why? :)
<zyga-ubuntu> niemeyer: it frees lots of blocks that are unused but not full of zeros
<zyga-ubuntu> niemeyer: makes the image sparse properly again
<zyga-ubuntu> niemeyer: shrinking it to the actually used space
<niemeyer> zyga-ubuntu: Hmm... I'd be slightly surprised if a tool meant to create an image wouldn't be doing that in a less crazy way :)
<zyga-ubuntu> niemeyer: it's like trim or thin provisioning the "cheap" way
<zyga-ubuntu> niemeyer: oh, you'd be surprised ^_^
<niemeyer> zyga-ubuntu: But, sure.. we should try it
 * zyga-ubuntu keeps fingers crossed :)
<cachio> zyga-ubuntu, I can clean the old kernel and try that
<niemeyer> cachio: +1
<cachio> zyga-ubuntu,
<cachio> -bash-4.4# rpm -q kernel
<cachio> kernel-4.9.3-200.fc25.x86_64
<cachio> kernel-4.12.14-300.fc26.x86_64
<cachio> those are the kernels
<cachio> installed
<cachio> the 4.12 seems to be for fedora 26
<cachio> niemeyer, I am gonna delete the 4.12 in this case
<niemeyer> Hmm
<niemeyer> cachio: I'm a bit confused.. isn't this supposed to be fedora 26?
<cachio> niemeyer, yes
<cachio> sorry
<zyga-ubuntu> cat /usr/lib/os-release
<niemeyer> cachio: Ok, so you want 4.12.. 4.9 is from 25 which is the older image we had.. it's all as expected, except for the fact we still have the old kernel around
<cachio> niemeyer, yess, we have the old kernel running
<gsilvapt> How does one write a custom message to use with Click? Using click.command(message='%s test' %s var) returns invalid format
<niemeyer> cachio: Running?
<cachio> -bash-4.4# uname -a
<cachio> Linux li985-30 4.9.50-x86_64-linode86 #1 SMP Thu Sep 14 19:28:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
<gsilvapt> I'm trying to simplify the example here but I think I have the print statement properly done
<niemeyer> cachio: That's awkward.. it means the right  kernel wasn't properly installed yet
<niemeyer> cachio: Oh, wait
<niemeyer> cachio: SO that's the bug
<cachio> niemeyer, yes
<niemeyer> cachio: That's *neither* of those versions
<cachio> seems to be missing the change in grub
<niemeyer> cachio: 4.9.50 != 4.9.3
<niemeyer> cachio: No
<niemeyer> cachio: That's a kernel from *Linode*
<niemeyer> cachio: The system in Spread wasn't set up to boot from grub
<cachio> niemeyer, ok
<niemeyer> cachio: Let me reboot to see if that image works at all
<cachio> nisure
<cachio> niemeyer, sure
<niemeyer> cachio: I will change on the server end, but we need to tweak in spread.yaml too
<niemeyer> Rebooting
<niemeyer> gsilvapt: Click?  Wow.. :)
<gsilvapt> niemeyer, the framework used in snapcraft
<gsilvapt> actually my command is click.echo not click.command
<niemeyer> gsilvapt: Ah, sorry, I didn't know that was a thing
<niemeyer> gsilvapt: Clearly I'm not the right person to answer this question :)
<niemeyer> sergiusens: ^
<gsilvapt> haha, no worries. Thanks anyway, niemeyer :)
<niemeyer> cachio: Should have booted by now
<niemeyer> gsilvapt: np, Sergio should be able to help you
<cachio> niemeyer, which is the name of the image?
<niemeyer> elopio too
<niemeyer> cachio: Which image?
<cachio> fedora-26-64
<niemeyer> cachio: Are you responding to yourself?  :)
<cachio> niemeyer, did you create an image to test fedora-26?
<niemeyer> cachio: I meant the machine should have rebooted..
<niemeyer> cachio: The machine you were using
<niemeyer> cachio: Which had the wrong kernel
<niemeyer> cachio: I've rebooted it using grub
<cachio> ah, ok
<niemeyer> cachio: Besides making sure it boots, we still need to clear the old kernel, and to try zyga's suggestion
<gsilvapt> Thank you for pointing it out. kyrofa will help me because he knows what I'm trying to fix here :-)
<cachio> niemeyer, yes
<kyrofa> gsilvapt, haha, great question, I was actually wondering that myself
<gsilvapt> kyrofa, my main issue is this: version_options does two things: Get version number and package name.
<gsilvapt> That's why when running the tests it prints run, version xxxx
<kyrofa> Right, give me a sec, let me see
<gsilvapt> I have the duplicate the method either way, otherwise it will return different things and there is no way we can ensure both methods return the same thing
<kyrofa> gsilvapt, it's a format string
<kyrofa> gsilvapt, try just passing this: %(prog)s, version %(version)s
<kyrofa> Which is exactly the default
<gsilvapt> kyrofa, click.echo() with that just turns the exact string
<kyrofa> (it's a python2-compatible format string)
<kyrofa> gsilvapt, oh I thought you were talking about the message param to click
<gsilvapt> Wait, when I tested it returned another issue. Lets quickly try that
<gsilvapt> kyrofa, no, I want to wrap up the 'version' command
<kyrofa> gsilvapt, for click.echo, just do `click.echo('snapcraft, version {}'.format(snapcraft.__version__))
<gsilvapt> kyrofa, but then that's hard-coding the string and if they change the default in Click, the commands will return different things, no?
<kyrofa> gsilvapt, which is why I suggest you also hard-code the string for Click
<gsilvapt> AH, ok
<gsilvapt> I understood it the other way around
<gsilvapt> lol
<kyrofa> gsilvapt, you're not going to be able to get away without hardcoding something
<gsilvapt> kyrofa, That's why I got stuck :-)
<kyrofa> gsilvapt, so yeah, hardcode the --version message='%(prog)s, version %(version)' then you can rest assured it won't change
<kyrofa> Err, message='%(prog)s, version %(version)s' rather
<gsilvapt> kyrofa, the --version command then should be message= that and version = the command it was already there, right?
<kyrofa> gsilvapt, I'm afraid I'm not sure what you're saying, can you rephrase?
<cachio> niemeyer, ready
<cachio> could you try again
<cachio> let's see if the zyga's magic works
<zyga-ubuntu> niemeyer: any luck with the size?
<niemeyer> Checking
<kyrofa> sergiusens, elopio snapcraft#1750 needs one more +1
<mup> PR snapcraft#1750: kernel plugin: don't assume /lib/firmware is present if !kernel-with-firmware <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1750>
<zyga-ubuntu> darn gnome-shell
<niemeyer> cachio, zyga-ubuntu: 1.8GB
<zyga-ubuntu> niemeyer: before or after?
<niemeyer> After
<zyga-ubuntu> and before?
<cachio> zyga-ubuntu, I aplied your magic
<niemeyer> cachio: That's still 400MB more than the last image
<niemeyer> zyga-ubuntu: 4GB
<zyga-ubuntu> hoho :D
<niemeyer> zyga-ubuntu: So yeah, it works
<zyga-ubuntu> cachio: it would be good to compare du from inside the image in the old/new system
<niemeyer> cachio: Can you check where the extra space went into?
<zyga-ubuntu> niemeyer: you can then use e4defrag to maybe save some minor amount of space
<zyga-ubuntu> and zero-free again
<zyga-ubuntu> but I'm happy the old trick still works :)
<zyga-ubuntu> you can also use qemu-img if you have access to the raw image
<niemeyer> cachio: We don't have any other image with more than 1.4GB.. I'm a bit concerned with the trend of larger and larger images every time
<cachio> zyga-ubuntu, I also deleted the old kernel
<zyga-ubuntu> cachio: posting the list of packages could help
<zyga-ubuntu> cachio: and then cross-checking with du (or ncdu if interactively)
<zyga-ubuntu> so, I'm working from virtual terminals now, I have oodles of ram and it doesn't grow as I type more
<niemeyer> Yeah, should be easy to compare the two images
<niemeyer> cachio: I've booted it back up
<cachio> niemeyer, zyga-ubuntu also instead of update we could install based on a clean image
<zyga-ubuntu> gnome-shell used ~700 rss for one gnome-terminal buffer + background
<zyga-ubuntu> and I'm a bit fed up with that now
<niemeyer> cachio: Sure, but we can also just remove the unnecessary packages
<zyga-ubuntu> cachio: yes, start with that cloud image I posted
<zyga-ubuntu> or compare them
<niemeyer> cachio: In our Ubuntu images, I listed packages by size, and killed things which were obviously unnecessary
<zyga-ubuntu> ncdu is useful for finding hot spots
<niemeyer> cachio: That's why our Ubuntu images are pretty small
<sergiusens> kyrofa I've answered your question on the mypy one
<cachio> niemeyer, ok, just give me the new ip
<niemeyer> cachio: It's still the same
<niemeyer> Stepping out to pick up son at school.. biab
<zyga-ubuntu> cachio: I wonder how much space we can save on the debian images
<cachio> niemeyer, I got the packages installed in the new fedora 26
<cachio> with the new kernel
<cachio> which is in 45.33.35.30
<cachio> i'll check now the old image
<cachio> do you know the size of the fedora 25?
<jamesbenson> wgrant: anything I can do to help with 1733660?
<noise][> fyi, he's in AU, won't be online for a couple more hrs
<noise][> but getting a good pcap would be the best help
<cachio> zyga-ubuntu, niemeyer this is the diff https://paste.ubuntu.com/26014698/
<cachio> zyga-ubuntu, niemeyer not sure if that diff explains the change in the iamge size
<niemeyer> cachio: Was there no development files at all before?
<niemeyer> gcc, glibc-devel, kernel-headers..
<cachio> yes, this is just the diff
<niemeyer> cachio: Either way, a quick way to get some space back would be to list packages and order by size
<niemeyer> Same about disk content
<cachio> niemeyer, both images have similar space used in the disk
<niemeyer> There's usually some very expensive things, and then a long tail
<zyga-ubuntu> cachio: sorry, not sure how to open that in text mode,
<niemeyer> Killing a few expensive things may be done quickly
<cachio> niemeyer, what I said is not true}}
<niemeyer> And much more easily than figuring the long tail out
<cachio> in fedora 25 we are using 1GB and in 26 1.5GB
<niemeyer> Ok, yeah, so suggestions above hold
<cachio> zyga-ubuntu, https://paste.ubuntu.com/26014698/plain/
<cachio> does it work for you?
<zyga-ubuntu> cachio: I mean, I cannot click on anything, I'm running irssi in plain text console
<zyga-ubuntu> cachio: no wayland
<zyga-ubuntu> no X
<zyga-ubuntu> no mir
<cachio> just download this url
<cachio> that is plain text
<jamesbenson> noise][, unable to get a good tcpdump
<zyga-ubuntu> cachio: no copy-paste either )
<cachio> zyga-ubuntu, :(
<zyga-ubuntu> cachio: and our pastebin is notoriously 2fa annoying
<noise][> jamesbenson - what does `ifconfig` show for interfaces in your container? and what interface does tcpdump say it is capturing from?
<noise][> seems really odd to get _nothIng_ otherwise
<jamesbenson> noise][ I tried lxdbr0 and also all interfaces, nothing changes...
<jamesbenson> also tried tcpdump --list-interfaces
<jamesbenson> noise][ that's why I was wondering about the link
<noise][> hmm. how about `host 068ed04f23.site.internapcdn.net` and then try to `telnet <whatever IP> 443`
<noise][> seems like you are not even establishing a conn
<jamesbenson> yeah
<jamesbenson> I'll try.
<roadmr> jdstrand: tools r945 are now in prod!
<jamesbenson> noise][, even outside of my lxd container, tcpdump isn't gathering any packets.
<ikey> use hastebin.com + haste-it CLI tool
<ikey> save farting around with 2FA and browsers
<jamesbenson> noise][, I get a _whole_ 7 packets received by the filter, 0 packets captured though.
<jdstrand> roadmr: \o/
<jdstrand> roadmr: thanks :)
<jamesbenson> noise][ tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
<cachio> niemeyer, debian-9 did not work
<cachio> and 4 tests failed for debian-sid
<wgrant> jamesbenson: Hey
<jamesbenson> hey wgrant
<wgrant> jamesbenson: Just getting up to speed on your issue. Can you confirm that it happens only inside the container, not on the host system?
<jamesbenson> wgrant: correct, all tests that fail in the lxd, work on the host VM
<jamesbenson> wgrant, do you have a tcpdump that is ::guaranteed:: to work should everything else work?
<wgrant> jamesbenson: Cool. Can you grab the output of "ip l" both from the host and from a container?
<jamesbenson> host: http://paste.ubuntu.com/26015018/
<jamesbenson> lxd: http://paste.ubuntu.com/26015019/
<jamesbenson> wgrant ^^
<wgrant> Alright, that's probably the problem.
<jamesbenson> ??
<wgrant> jamesbenson: Your OpenStack instances have a smaller MTU than the standard Ethernet 1500 (see ens3's "mtu 1450"). This is pretty common when the cloud is running on a network substrate that doesn't support jumbo frames. But LXD's default lxdbr0 uses the default Ethernet MTU of 1500, so the container is sending a 1500-byte packet that then can't be sent out ens3. The packet gets dropped, and the connection
<wgrant> stalls.
<wgrant> jamesbenson: Try "ip set lxdbr0 mtu 1450" and see if that fixes it
<wgrant> er
<wgrant> "ip l set lxdbr0 mtu 1450"
<jamesbenson> wgrant: but my ens3 is internal, my lxdbr0 is my public IP
<jamesbenson> try that on my lxd?
<wgrant> On the host.
<wgrant> Are you sure lxdbr0 has your public IP? ens3 isn't part of the bridge.
<jamesbenson> wgrant: fyi: http://paste.ubuntu.com/26015062/. you can see a ton of traffic going through lxdbr0
<wgrant> jamesbenson: Yep, the traffic will go through lxdbr0, but then be dropped when the kernel tries to forward it to the outside world on ens3.
<jamesbenson> wgrant: 192.168.111.x is openstack internal IP.  10.245.x is floating IP.
<jamesbenson> hmm... okay
<wgrant> jamesbenson: The instance never sees the floating IP.
<wgrant> the cloud does all the NAT for you
<wgrant> The lxdbr0 10.211.50.1 is a subnet that LXD chose for your local containers.
<jamesbenson> yeah
<jamesbenson> 10.211 is lxd network..
<jamesbenson> Do I need to kill the lxd containers and redeploy or anything afterwards?
<wgrant> jamesbenson: You'll likely need to restart the containers, or also change the MTU on all the veths
<roadmr> jdstrand: hey! that snap you uploaded that triggered a runtime error - could you please do another upload? I want to see if it's what caused an error report I'm seeing
<jdstrand> roadmr: I just filed a bug
<roadmr> jdstrand: thanks!
<jdstrand> https://bugs.launchpad.net/snapstore/+bug/1733699
<mup> Bug #1733699: invalid snaps that trigger 'runtime-errors' json output are not correctly processed by the store <Snap Store:New> <https://launchpad.net/bugs/1733699>
<jdstrand> roadmr: note that the urgency is not critical at least from my pov
<jdstrand> roadmr: because it correctly doesn't auto-approve it.
<roadmr> jdstrand: aha... yes, that matches the error I'm seeing
<jdstrand> roadmr: I'm happy to upload another one
<roadmr> jdstrand: no need, I think this is clear
<roadmr> jdstrand: you did 3 uploads, right?
<jdstrand> roadmr: yes. two for test-bad-plugs and one for test-bad-desktop-file
<niemeyer> cachio: What happened there?
<niemeyer> In Debian 9, that is
<roadmr> jdstrand: ok! I was just afraid something was broken... let me see what the store expects and how we can make both parts happy :)
<jamesbenson> http://paste.ubuntu.com/26015114/
<cachio> niemeyer, not sure, It could not connect to it
<jamesbenson> wgrant ^^ done
<cachio> I am gonna debug it
<jamesbenson> I changed the MTU on all veths.. didn't restart them though
<jamesbenson> wgrant:  ^_^ export VETH=`ifconfig -s | grep veth | awk '{print $1}'`; for i in $VETH; do sudo ip l set $i mtu 1450;done;
<wgrant> jamesbenson: AFAIK that should change the other end of the veth too, so it should hopefully work now!
<jdstrand> roadmr: sounds good. note I'm almost eow til next monday. I could tweak json output if needed, but ping me on privmsg if you need that before monday
<roadmr> jdstrand: will do
<mup> PR snapcraft#1747 closed: static tests: enable type checking by use of mypy <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1747>
<jamesbenson> wgrant: in the lxd lxdbr0 is still set to 1500
<wgrant> jamesbenson: That's the lxdbr0 for the LXD inside the LXD; you can ignore it
<jamesbenson> wgrant: updated it to 1450 and still times out on `sudo snap install core`
<wgrant> Unless you are deliberately using nested containers :)
<wgrant> Interesting.
<wgrant> "ip l" both inside the container and out again?
<jamesbenson> just changed it back to 1500 to check, but seems like it's timingout still....
<jamesbenson> host: http://paste.ubuntu.com/26015146/
<jamesbenson> lxd: http://paste.ubuntu.com/26015151/
<wgrant> Oh
<sergiusens> elopio kyrofa now that snapcraft#1747 is in you can update the branch locally and run the static tests for the ros cache thing (or do it from github if feeling lazy ;-) )
<mup> PR snapcraft#1747: static tests: enable type checking by use of mypy <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1747>
<wgrant> Maybe changing one end of an existing veth doesn't change the other
<wgrant> jamesbenson: Inside the container, set the eth0@if13 MTU
<wgrant> Ah yeah, confirmed, you need to do both ends (or restart the container)
<jamesbenson> Cannot find device "eth0@if13"
<niemeyer> cachio: Strange. Might be the kernel vs. grub
<jamesbenson> whats the command to restart them?
<niemeyer> That is, Linode kernel vs. GRUB 2 setup that boots the native kernel
<niemeyer> cachio: In theory the image is exactly the same we snalshotted and that was working
<wgrant> jamesbenson: Er yeah, the real name is just "eth0" inside the container, sorry
<cachio> niemeyer, well, I removed the var GRUB and it started, so that's the problem
<wgrant> jamesbenson: "lxc restart $CONTAINER" from the host, or just sudo reboot from each container
<jamesbenson> wgrant: hey! it works!
<niemeyer> cachio: Ok, so it probably doesn't have a real Debian kernel in the image itself
<noise][> \o/
<noise][> if it's not DNS it's MTUâ¦ should have known :/
<jamesbenson> wgrant: next big q....
<wgrant> jamesbenson: Great! So the underlying issue here is that LXD should probably try to MTU-match the bridge it creates. You'd have noticed this on any TLS traffic, not just snappy-related stuff.
<jamesbenson> wgrant: If I want to repeat this (not the bug, but the fix) automatically.  i.e. deploying vm and setting all of this up.  How do I tell conjure-up k8s to use the correct MTU by default
<jamesbenson> ?
<stokachu> jamesbenson: conjure-up doesn't create your bridges
<stokachu> jamesbenson: you'd have to do that via lxc network create
<jamesbenson> ah yeah, and from there it should all work, correct?
<wgrant> jamesbenson: All you need to do on a fresh instance is set the MTU on lxdbr0 before any containers are started
<wgrant> Everything will inherit from that.
<cachio> niemeyer, this is the kernel "Linux debian 4.9.50-x86_64-linode86 #1 SMP Thu Sep 14 19:28:20 UTC 2017 x86_64 GNU/Linux"
<niemeyer> cachio: It needs the full grub setup
<niemeyer> cachio: Wait.. that's not a Debian kernel
<niemeyer> cachio: It needs the full grub setup *and* a kernel :)
<cachio> niemeyer, hehe
<cachio> ok
<niemeyer> cachio: Otherwise we're not really testing Debian proper
<cachio> niemeyer, do you know which kernel should we use?
<niemeyer> cachio: The latest one available for the particular distro version
<niemeyer> cachio: Always
<cachio> niemeyer, ok
<niemeyer> cachio: That means CI is close to where users ought to be
<cachio> niemeyer, makes sense
<cachio> ok, and about grub, do you need to do anything?
<cachio> or it is just to configure it in the vm
<niemeyer> cachio: It's just normal setup in the VM
<cachio> niemeyer, ok
<niemeyer> cachio: The GRUB 2 "kernel" in Linode is really just handing off into the grub that is in the image's MBR
<niemeyer> cachio: So it will be a typical boot otherwise
<cachio> niemeyer, ah, ok
<cachio> I am configuring this right now
<jamesbenson> wgrant: is this command possible then?:   lxc network create lxdbr0 ipv4.address=auto ipv4.nat=true ipv6.address=none ipv6.nat=false mtu=1450
<wgrant> jamesbenson: I think it's bridge.mtu=1450
<wgrant> But let me test
<wgrant> jamesbenson: Yeah, "lxc network set lxdbr0 bridge.mtu 1450" works
<jamesbenson> cool
<roadmr> jdstrand: still around or did you EOD?
<roadmr> jdstrand: anyway - I updated the bug with info on how to fix, we just need an extra dict level :)
<elopio> cjwatson: ping. I think this bug is important because it's breaking the heroku builds: https://bugs.launchpad.net/launchpad-buildd/+bug/1733718
<mup> Bug #1733718: truffle fails to build: ENOTFOUND registry.yarnpkg.com registry.yarnpkg.com:443 <launchpad-buildd:New> <https://launchpad.net/bugs/1733718>
<cjwatson> elopio: it's also eight minutes to midnight.  will look tomorrow
<elopio> cjwatson: oh, sorry. Have a good night.
#snappy 2017-11-22
<gsilvapt> kyrofa, about the command, the only way I can make them match is if I explicitly set the string to be "snapcraft, version xxx" in both commands. Is that okay?
<kyrofa> gsilvapt, I'd leave the Click one `prog`
<gsilvapt> kyrofa, sounds okay to me but the problem is that when you run the tests it does not print snapcraft. Instead it prints run, version xxx
<gsilvapt> Maybe that is related with the tests, I do not know
<kyrofa> gsilvapt, oh that's unfortunate indeed
<kyrofa> gsilvapt, yeah, hardcode it then
<gsilvapt> Ok, I will do that, verify again the tests and submit the changes
<gsilvapt> kyrofa, thank you!
<mup> Issue snapcraft#1666 closed: Refactor to support elf patching <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1666>
<mup> PR snapcraft#1744 closed: elf: conversion from libraries <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1744>
<mup> PR snapcraft#1725 closed: tests: share the cache in ros tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1725>
<mborzecki> morning guys
<mup> PR snapd#4264 closed: tests: force delete when tests are restore to avoid suite failure <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4264>
<mup> PR snapd#4240 closed: spread.yaml: increase workers for opensuse to 3 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4240>
<mup> PR snapd#4266 opened: snapstate: add new refresh-hints helper and use it <Created by mvo5> <https://github.com/snapcore/snapd/pull/4266>
<zyga-ubuntu> good morning
<mvo> hey zyga-ubuntu , good morning
<zyga-ubuntu> :-)
<zyga-ubuntu> I'm still in non-{wayland,x} text mode
<zyga-ubuntu> using another computer for code reviews
<zyga-ubuntu> this is particularly refreshin
<zyga-ubuntu> lots of free memory and full-screen, single focus applications
<mvo> zyga-ubuntu: haha, nice
<zyga-ubuntu> I spent some time yesterday trying to untangle our prepare/restore code
<zyga-ubuntu> if not permanantly then at least enough to get good measurements of what is changing
<zyga-ubuntu> and I must say that code is complex and confusing
<zyga-ubuntu> not just in the actions taken but in their placement and justification
<zyga-ubuntu> (or lack or thereof)
<mvo> zyga-ubuntu: yeah, its all over the place
<zyga-ubuntu> I'll keep at it as it needs to be in proper shape to detect tests that change too much
<mup> PR snapd#4267 opened: snapstate: move catalogRefresh into its own helper  <Created by mvo5> <https://github.com/snapcore/snapd/pull/4267>
 * kalikiana o/
<zyga-ubuntu> mvo: review on 4266
<mvo> zyga-ubuntu: ta
<zyga-ubuntu> I marked it as changes requested but just midlly so, we can merge this quickly
<mvo> zyga-ubuntu: thanks, the can-auto-refresh question is interessting as it raises a bigger questions
<mvo> pedronis: do you think the new refresh-hints code should also consult "CanAutoRefresh", or should we do the refresh-hints even if the device is still bootstraping? I guess we want to honor CanAutoRefresh but I want to double check. I also think you are right about RefreshOptions:RefreshNop, I think we want this, I will followup on this
<mvo> zyga-ubuntu: thanks again for the quick review :)
<zyga-ubuntu> :-)
<pedronis> mvo: yes, IÂ think we want to consult CanAutoRefresh  (otherwise will just consider partial information or don't have a device session yet)
<mvo> pedronis: +1 - thank you
 * zyga-ubuntu tries something mergable instead
<zyga-ubuntu> mvo: trivial merge on 4268
<mup> PR snapd#4268 opened: spread.yaml: move prepare-each closer to restore-each <Created by zyga> <https://github.com/snapcore/snapd/pull/4268>
<mup> PR snapd#4269 opened: timeutil: new refresh timer parser <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4269>
<mup> PR snapd#4270 opened: timeutil: remove support to parse weekday schedules <Created by mvo5> <https://github.com/snapcore/snapd/pull/4270>
<mvo> mborzecki: heh, looks like we need to solve conflicts here ;) either way is fine with me, I can wait for your merge or you can review mine and merge into yours (or wait until master is in)
<mvo> mborzecki: should be very simple in any case
<mborzecki> mvo: yup, i'm wiring a comment on gh
<mborzecki> i'm actually using some of the pieces that you remove :)
<mvo> mborzecki: yeah, happy to revert those bits
<mvo> mborzecki: the key of the PR (I can make it smaller) is that the weekday parsing in v1 is not supported in snapstate so its dead code and caused one confusion in the validation already
<mborzecki> hmm ok, i mean it's not a big problem, if it gets merged before 4269, i'll just bring back the missing pieces
<mvo> mborzecki: no worries, I can do that now to make your life easier, its the weekday part of the struct and the weekdayMap that you need, right?
<mborzecki> but i'm guessing 4269 will be a longer review, so I wouldn't want to block you
<mvo> mborzecki: yeah, let me rework my PR (was not aware of yours) so that the impact for you is minimal
<mborzecki> mvo: only if you have time for this, otherwise i can fix this myself in my PR
<mborzecki> mvo: would appreciate you taking a look at 4269 BTW :)
<mvo> mborzecki: re-added the weekday/weekday map now. I check the other one out once I finished my current PR. I glanced over it and it looked good from a very brief look
<mborzecki> mvo: thanks
<zyga-ubuntu> hmm
<zyga-ubuntu> so, what does ${GOPATH%%:*} expand to?
<zyga-ubuntu> because as far as I can see, to nothing at all
<zyga-ubuntu> %% will strip the longest suffix of "*" which is everything
<jamesh> it'll strip the suffix of ":*" -- not "*"
<jamesh> so effectively remove everything including and after the first colon
<zyga-ubuntu> are you sure?
<zyga-ubuntu> ah
<zyga-ubuntu> right, I made a typo in my tests
<zyga-ubuntu> thanks!
<zyga-ubuntu> :-)
<zyga-ubuntu> mvo: can you please force-merge 4268
<zyga-ubuntu> I could try again and waste an hour but I think the situation is riddiculus enough not to do that
<zyga-ubuntu> and the error is clearly some store flue on refresh deltas
<mup> PR snapd#4268 closed: spread.yaml: move prepare-each closer to restore-each <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4268>
<zyga-ubuntu> thanks!
<zyga-ubuntu> mvo: another quick PR to look at 4271
<mvo> yw
<mup> PR snapd#4271 opened: spread.yaml: fix shellcheck issues and trivial refactor <Created by zyga> <https://github.com/snapcore/snapd/pull/4271>
<zyga-ubuntu> mborzecki: errors in your schedule PR
<zyga-ubuntu> mborzecki: real unit tests failures in overlord/snapstate
<mborzecki> zyga-ubuntu: thx, on it
<zyga-ubuntu> mvo: btw, I'm on FF57 now (actually on nightly so 59) and I can use umatrix
<zyga-ubuntu> mvo: try again, maybe your extension was fixed now
<zyga-ubuntu> mvo: ff 59 with umatrix is the fastest browser on any system I used
<zyga-ubuntu> (umatrix cutting the number of crap javascript from ads and tracking)
<mvo> zyga-ubuntu: I have a bunch that I missed, but things are mostly good again. umatrix, cookie auto-delete, noscript are my essential ones, I also have a custom one that I need to port in time (based on the passhash extension)
<mborzecki> mvo: things are fast again!
<mup> PR snapd#4272 opened: snapstate: ensure RefreshSchedule() gives accurate results <Created by mvo5> <https://github.com/snapcore/snapd/pull/4272>
<pedronis> mvo: ^  the description  there has "git push ..." in the middle, could you fix it
<mvo> pedronis: autsch, sorry for that
<pedronis> not sure if it lost bits or just need the bit removed
<mvo> pedronis: apparently a wrongly focused window, the original commit message is correct
<mvo> pedronis: most of the PRs this morning are based on what we talked about yesterday, I they capture your suggestions, they should make 4161 simpler
<zyga-ubuntu> mvo: review on 4272
<zyga-ubuntu> mborzecki: do you think 4269 can be split?
<zyga-ubuntu> mborzecki: I'm often doing small reviews while waiting for local spread run to finish but 1K PR is not in that class
<mborzecki> for sure i can put the first 2 patches in a separate pr
<zyga-ubuntu> mborzecki: thank you, I'll gadly review that
<mup> PR snapd#4273 opened: timeutil: introduce helpers for weekdays and TimeOfDay <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4273>
<mborzecki> zyga-ubuntu: ^^
<zyga-ubuntu> thanks
<Chipaca> mborzecki: doesn't that TimeOfDay Add method mess up on DST change?
<Chipaca> 11pm + 6h isn't always 5am
<zyga-ubuntu> Chipaca: I commented on a similar aspect
<zyga-ubuntu> mborzecki: commented
<mborzecki> hmm not sure you can do anythign about this TimeOfDay as it's not aware of actual date
<zyga-ubuntu> mborzecki: yeah, it depends on how it is used
<Chipaca> zyga-ubuntu: i think we can ignore leap seconds though -- we're explicitly not supporting them as a valid time
<zyga-ubuntu> Chipaca: +1
<mup> PR snapd#4271 closed: spread.yaml: fix shellcheck issues and trivial refactor <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4271>
<mborzecki> imo, it's the same way as time.Time.Add() is not aware of DST only until you do presentation
<Chipaca> mborzecki: it all depends on how this is then used, though
<zyga-ubuntu> Chipaca: trivial 4274
<mup> PR snapd#4274 opened: spread.yaml: bump delta ref to 2.29 <Created by zyga> <https://github.com/snapcore/snapd/pull/4274>
<Chipaca> that's a review size i can _do_
 * Chipaca in pain and on pain meds -- not a good combo
<pedronis> Chipaca: :(
<Chipaca> pedronis: Â¯\_(ã)_/Â¯
<mup> PR snapd#4275 opened: spread.yaml,tests: move most of project-wide prepare/restore to separate file <Created by zyga> <https://github.com/snapcore/snapd/pull/4275>
<zyga-ubuntu> Chipaca: take care, I'm sorry for your pain :|
<zyga-ubuntu> another small refactor for spread.yaml ^
<zyga-ubuntu> 10% executed locally so I assume it's okay, rest will show up in real testing
<Chipaca> zyga-ubuntu: this one is to work with your changes to spread?
<zyga-ubuntu> Chipaca: this is all preparation work, I made so many changes trying to untangle and understand this it was impossible to review
<zyga-ubuntu> Chipaca: I can propose the spread PR for reference
<zyga-ubuntu> Chipaca: the problem is we don't really prepare/restore cleanly
<zyga-ubuntu> Chipaca: and I will hopefully changed that by EOD, without introducing any extre time costs
<zyga-ubuntu> Chipaca: have a look at spread#47 please
<mup> PR spread#47: Add support for project-wide measure-each stanza <Created by zyga> <https://github.com/snapcore/spread/pull/47>
<kalikiana> zyga-ubuntu: I'm getting this again :-( ` open /var/lib/snapd/hostfs/home/cris/snap/lxd/common/snapcraft9xy6a3v1/core_3440.assert: no such file or directory [...] subprocess.CalledProcessError: Command '['lxc', 'file', 'push', '/home/cris/snap/lxd/common/snapcraft9clif0ke/snapcraft_x1.snap', 'helga:snapcraft-multipass/run/snapcraft_x1.snap']' returned non-zero exit status 1.`
<zyga-ubuntu> kalikiana: which of the files is missing? any denials?
<zyga-ubuntu> Chipaca: in my approach the measure-each code ensures that files on / (and just that filesystem) and outside of /tmp don't change, mount table doesn't change, packages don't change and sysctl doesn't change
<zyga-ubuntu> Chipaca: but it changes all the time as prepare/restore is a bit wonky and I need to clean it up before addressing some real problems
<mup> PR snapd#4253 closed: task tunner: extended task runner test <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/4253>
<kalikiana> zyga-ubuntu: not that I can see...
<kalikiana> I'm trying again with `snappy-debug scanlog` open
<kalikiana> zyga-ubuntu: this is btw snapcraft as a snap, with lxd from apt
<zyga-ubuntu> mvo: approved 4272
<mvo> zyga-ubuntu: ta
<zyga-ubuntu> kalikiana: too many errors recently
<zyga-ubuntu> kalikiana: I have LXD issues to address b
<zyga-ubuntu> kalikiana: but our integration test suite is so unreliable I took a dive into it
<mvo> zyga-ubuntu: thanks again for this review, that made things a lot better (checkRefreshSchedle was pretty terrible)
<kalikiana> zyga-ubuntu: is there anything that changed in lxd recently? I'm quite sure snapcraft changed nothing
<zyga-ubuntu> kalikiana: I don't know, sorry :/
<mvo> kalikiana: there was a new stable lxd recently I think, but that is really all I know
<mvo> stable channel lxd snap to be precise
<mup> PR snapcraft#1750 closed: kernel plugin: don't assume /lib/firmware is present if !kernel-with-firmware <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1750>
<mvo> kalikiana: yesterday to be precise. and also a new cnadidate a bit later
<kalikiana> mvo: I guess I'll try if the snap suffers from the same issue - what I find super puzzling is that hostfs is in the path at all, and considering it's empty in the host that would easily explain why lxd can't access it
<mup> PR snapcraft#1643 closed: tests: run daily autopkgtest in travis <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1643>
<zyga-ubuntu> mborzecki: approved 4273
<mborzecki> ta
<mup> PR snapd#4267 closed: snapstate: move catalogRefresh into its own helper  <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4267>
<zyga-ubuntu> mvo: trivial comment on 4266 (from pedronis, not me), +2 otherwise and ready to land
<zyga-ubuntu> mvo: thank you for updating 4262 :)
<zyga-ubuntu> Chipaca: do you feel like reviewing 4254 from mvo (it's about SNAP_DID_REEXEC)
<zyga-ubuntu> ?
<mup> PR snapd#4256 closed: snap-confine: add workaround for snap-confine on 4.13/upstream <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4256>
<mup> PR snapd#4262 closed: store: do not log the http body for catalog updates <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4262>
 * Chipaca looks
<zyga-ubuntu> mvo: we still ship a configure hook in core, is the plan to remove that entirely and switch to internally-handled configuration?
<pedronis> zyga-ubuntu: the plan is to remove it, we still have more work to do to fix 2.30 to make that possible
<pedronis> though
<zyga-ubuntu> pedronis: I see
<pedronis> https://forum.snapcraft.io/t/new-configure-snapd-task-and-reverting/2774
<zyga-ubuntu> pedronis: I just noticed we do something odd in prepare code
<zyga-ubuntu> we enable refresh on external spread backends
<zyga-ubuntu> but only if the configure hook exists
<kalikiana> zyga-ubuntu: concerning denials: none, I'm only seeing unrelated ones eg. Telegram now
<kalikiana> which makes sense if all it does is read an empty folder
<zyga-ubuntu> kalikiana: is this locally or in some CI system?
<zyga-ubuntu> kalikiana: do you have any changes on the system that is affected?
<kalikiana> zyga-ubuntu: all local, xenial with backports
<zyga-ubuntu> mborzecki: is 4270 safe to merge now?
<mborzecki> zyga-ubuntu: yes
<zyga-ubuntu> mvo: trivial comment on 4252
<zyga-ubuntu> mvo: and more comments on 4272
<mup> PR snapd#4270 closed: timeutil: remove support to parse weekday schedules <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4270>
<zyga-ubuntu> 4263 needs a 2nd review
<mup> PR snapd#4254 closed: cmd, errtracker: get rid of SNAP_DID_REEXEC environment <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4254>
<zyga-ubuntu> mborzecki: can you finish your review o 4109, it's small and has been lingering for too long
<mup> PR snapd#4171 closed: tests: adding test to test physical memory observe interface <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4171>
<zyga-ubuntu> mborzecki: conflicts in 4273
<pstolowski> mborzecki, .. and in 4269
<niemeyer> cjwatson: Aww.. no more gimme?
<niemeyer> Hellos!
<cjwatson> niemeyer: thank you for the music
<jamesh> zyga-ubuntu: hi.  I was wondering if you have any ideas about how to write a spread test for my user-mounts PR.  I haven't included any interface that add user mounts at this stage, so I'm not sure where to start
<mborzecki> pushed an update to 4273, 4269 will be fixed later as currently it will conflict with 4273
<zyga-ubuntu> jamesh: I think it should be a part of the desktop interface (right?)
<zyga-ubuntu> jamesh: alternatively just use a test snap, install it, hack the profile and run update-ns
<zyga-ubuntu> jamesh: (and, more importantly, hack the profile, discard the ns and run snap-confine again so that it sets up things)
<jamesh> zyga-ubuntu: the desktop innnterface will use it for portals eventually, but that isn't part of the PR
<zyga-ubuntu> jamesh: look at the advanced content interface test for inspiration
<jamesh> zyga-ubuntu: also, what's the most convenient way to run a single spread test locally?
<zyga-ubuntu> jamesh: look at tests/main/interfaces-content-mkdir-writable
<zyga-ubuntu> jamesh: the qemu backend, you can iterate very quickly (ish)
<zyga-ubuntu> jamesh: I'm running it all the time
<zyga-ubuntu> jamesh: I pushed images to spread.zygoon.pl/images
<zyga-ubuntu> jamesh: so pick one and look at spread docs on how to use
<zyga-ubuntu> jamesh: (just put to ~/spread/qemu)
<jamesh> thanks
<zyga-ubuntu> jamesh: then SPREAD_DEBUG_EACH=0 spread qemu:ubuntu-16.04-64:tests/main/
<zyga-ubuntu> jamesh: then SPREAD_DEBUG_EACH=0 spread -debug -v -reuse qemu:ubuntu-16.04-64:tests/main/
<zyga-ubuntu> (2nd line is better)
<zyga-ubuntu> jamesh: the desire for the spread test is to see that this really really works with confinment and what not
<zyga-ubuntu> jamesh: and weird kernels and other unexpected stuff
<zyga-ubuntu> mvo: small typo in 4266
<zyga-ubuntu> mvo: small tweak needed in 4252
 * zyga-ubuntu is trying to get the PR page list down to one 
<pedronis> #4158 needs a 2nd review
<mup> PR #4158: snapctl: don't error out on start/stop/restart from configure hook during install or refresh <Created by stolowski> <https://github.com/snapcore/snapd/pull/4158>
<zyga-ubuntu> looking
<jamesh> zyga-ubuntu: okay.  fwiw, the unit tests in the PR are all passing now: it looks like the run yesterday hit some problem trying to talk to the VMs
<zyga-ubuntu> jamesh: yeah, our perpetual problem of not having a batch system
<cachio> mvo, hey
<cachio> mvo, looking at the issue with "Job for snapd.service canceled"
<cachio> mvo, any idea how to deal with it?
<cachio> mvo, retrying in case of error could be a solution?
<zyga-ubuntu> pstolowski: review on 4158
<zyga-ubuntu> hmm, so MATCH is in the top-level spread context, this is a problem if we want to use it in scripts :/
<mup> PR snapd#4274 closed: spread.yaml: bump delta ref to 2.29 <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4274>
<zyga-ubuntu> hello niemeyer :)
<zyga-ubuntu> thank!
<zyga-ubuntu> thanks* :)
<niemeyer> zyga-ubuntu: Hey!
<niemeyer> zyga-ubuntu: Man, I found your brother last night
<niemeyer> zyga-ubuntu: https://www.youtube.com/watch?v=cHjf-YmIBCs
<zyga-ubuntu> niemeyer: oh?
<zyga-ubuntu> hahaha
<zyga-ubuntu> yeah, actually he even sounds similar in some way
<zyga-ubuntu> I hit the case where spread tarball changes while we are making it, hmmm,
<pedronis> that is a fun one :(
<zyga-ubuntu> maybe once I'm done with refactoring/untangling it will become evident
<zyga-ubuntu> I bet something is not done right somewhere
<zyga-ubuntu> service lingers or something like that
<niemeyer> zyga-ubuntu: Yeah, the voice tone, the looks, and even the shirt!
<zyga-ubuntu> niemeyer: surreal a bit :)
<niemeyer> :P
<zyga-ubuntu> niemeyer: my accent is better though (haha, maybe)
<niemeyer> zyga-ubuntu: Well, not better, but less german :-)
<niemeyer> (I don't see accents as bad in general.. just means we speak another language too)
<Son_Goku> accents don't necessarily imply another language
<zyga-ubuntu> oh god yes
<zyga-ubuntu> I watched a review of a game recently
<zyga-ubuntu> and geez
<zyga-ubuntu> this guy was unberable
<Son_Goku> IMO, they tell a story of the person's origin and history
<zyga-ubuntu> somewhere from US presumably but _MAN_
<Son_Goku> I've intentionally smoothed out the accent and speech style I grew up with, because it can confuse people
<Son_Goku> and even then, I don't have all of it out of my speech
<zyga-ubuntu> ok, I'm done watching my weird mirror :)
<kalikiana> Son_Goku: you're like Jack Barrowman :-D
<kalikiana> although arguably his original accent is worse
<Son_Goku> well, I'm not *quite* so flamboyant
<Son_Goku> but yes
<kalikiana> haha, yeah
<Son_Goku> well, for the first half of my childhood was spent in Indiana (US Midwest) and the second half was in Mississippi (US South), so I have bits of both in my speech
<zyga-ubuntu> afk, see you at the call
<mvo> zyga-ubuntu: the plan is to not ship the configure hook in core, yes
<mvo> cachio: hey, thanks for chasing the "job canceled" issue, I have no good answer, a retry is certainly not a bad idea, maybe this gives us even a better idea what exactly is causing this
<mvo> zyga-ubuntu: thanks also for the reviews, I chase the open points now :)
<cachio> mvo, I'll try it
<zyga-ubuntu> mvo: thank you! :)
 * kalikiana coffee break
<Chipaca> mvo: should we ask systemd peeps about that?
<zyga-ubuntu> I'll be late 2 min
<zyga-ubuntu> hmm
<zyga-ubuntu> some issues joining
<zyga-ubuntu> hmm :/
<mvo> Chipaca: its only on 14.04 and on our crufty backport
<Chipaca> mwhudson: is the plan to have go 1.10 in B?
<zyga-ubuntu> Chipaca: are you rejoining?
<zyga-ubuntu> ok, I'll break for lunch and I'll push forward in a moment :)
<Chipaca> zyga-ubuntu: question for you i think: why do osutil.Find[UG]id return a uint64?
<zyga-ubuntu> Chipaca: I believe that is what the golang 1.9 code we borrowed did do
<zyga-ubuntu> Chipaca: and we just ran along
<Chipaca> hmm
 * Chipaca looks
<zyga-ubuntu> offtopic, 3C and rain, I really don't envy commuters
<Chipaca> zyga-ubuntu: golang uses strings for uids and gids
<Chipaca> zyga-ubuntu: in the os/user package
<Chipaca> elsewhere it uses uint32's
<Chipaca> (hilariously)
<zyga-ubuntu> Chipaca: then I don't remember, I think there were two layers of this?
<zyga-ubuntu> Chipaca: or maybe as simple and naive as what parseint returns
<zyga-ubuntu> *uint
<Chipaca> zyga-ubuntu: also: those functions return a 0 on error, which can be bad
<Chipaca> but i don't know if i want to fix the in this pr
<Chipaca> hmm
<cachio> ogra_, hey
<cachio> ogra_, https://paste.ubuntu.com/26020272/
<cachio> the timexone in ubuntu core is n/a by defaulty
<cachio> ogra_, is it a known issue?
<Chipaca> zyga-ubuntu, mvo: in snap-seccomp/main.go's findGid we check a regexp, and then call osutil.FindGid which checks a regexp
<Chipaca> zyga-ubuntu, mvo: those regexps differ
<Chipaca> zyga-ubuntu, mvo: quoth the raven, "WAT"
<Chipaca> zyga-ubuntu, mvo: ignore me, i got that wrong
<ogra_> cachio, not that i'm aware ... file it ...
<cachio> ogra_, ok tx
<ogra_> cachio, is that x86 or arm ?
<ogra_> (on arm the fixrtc script checks for n/a and sets it properly, on x86 we do not use the fixrtc script afaik)
<zyga-ubuntu> mvo: the one with weirder features is probably correct
<zyga-ubuntu> er
<zyga-ubuntu> Chipaca: ^
<zyga-ubuntu> Chipaca: can you paste them here please?
<cachio> ogra_, all of them
<cachio> ogra_, in the pi3 also
<Chipaca> zyga-ubuntu: sorry, i got confused, but let me show you how
<ogra_> cachio, ah, well ... we should set it to UTC as default at build time i guess
<Chipaca> zyga-ubuntu: in snap-seccomp main: group must match "^[a-z][-a-z0-9_]*$"
<zyga-ubuntu> that is probably incorrect (just too restrictive)
<Chipaca> zyga-ubuntu: in snap-update-ns entry: x-snapd.gid must match "(^[0-9]+$)|(^[a-z_][a-z0-9_-]*[$]?$)"
<zyga-ubuntu> this one is correct but also matches numbers (as just direct group i)
<zyga-ubuntu> so if you want to take one, take the latter one and remove the number part
<zyga-ubuntu> Chipaca: the 2nd one is correct, I looked at the spec and, weirdly enough, that's what valid names are
<Chipaca> zyga-ubuntu: group names can end in $ but otherwise have no $ in them?
<Chipaca> what does that $ mean? (i presume it's special somehow)
<Chipaca> (i'm not changing that regexp in this round)
<Chipaca> (next one? sure)
<cachio> ogra_, it is set to UTC but the description is n/a
<zyga-ubuntu> yes
<cachio> Time zone: n/a (UTC, +0000)
<zyga-ubuntu> Chipaca: it's special, it means
<zyga-ubuntu> ...
<zyga-ubuntu> man I should have commented that somewhere
<ogra_> cachio, yes, i see that ... but if you set it manually the description says UTC as well
<ogra_> Time zone: UTC (UTC, +0000)
<Chipaca> zyga-ubuntu: yeah :-) a "where does this regexp come from" would be good
<cachio> ogra_, yes
<zyga-ubuntu> Chipaca: it should be in the git log
 * zyga-ubuntu looks
<ogra_> so we need to find how to set it like this during build and apply that
<ogra_> cachio, can you check if /etc/timezone says n/a on an image that exposes the issue ?
<zyga-ubuntu> Chipaca: man, I suck :/
<ogra_> (i missed to check it before setting it ... )
<zyga-ubuntu> Chipaca: probably in the PR then
<zyga-ubuntu> Chipaca: I remember an URL with all the things explained
<cachio> ogra_, Etc/UTC
<ogra_> interesting
<ogra_> it doesnt say Etc here
<ogra_> ogra@pi3:~$ cat /etc/timezone
<ogra_> UTC
<cachio> I have an old image
<cachio> let me check in a new one
<ogra_> cachio, aha... setting it to Etc/UTC results in:
<ogra_> Time zone: n/a (UTC, +0000)
<ogra_> dropping the Etc/ fixes it
<cachio> hehe
<cachio> ogra_, checking in a new image for pi3
<cachio> 1 minute
<kalikiana> kyrofa: ping
<mup> PR snapcraft#1754 opened: nodejs plugin: pass proxy configuration to yarn <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/1754>
<Chipaca> cachio: ogra_: Etc/ is a directory in tzdata
<ogra_> Chipaca, tell that to systemd-timedated
<ogra_> :)
<ogra_> seems it expects not a path but a TZ name in /etc/timezone
<ogra_> hmm, or not
<ogra_> ogra@pi3:~$ cat /etc/timezone
<ogra_> Europe/Berlin
<ogra_> that works correctly
<ogra_> only Etc/ doesnt
<ogra_> i mean ... it shows the correct TZ (UTC) in brackets ...
<ogra_> but n/a as description
<Chipaca> ogra_: what does list-timezones give you?
<ogra_> though ... perhaps the test should not use the description at all
<ogra_> and instead look inside the brackets where the actual TZ name sits
<Chipaca> ogra_: timedatectl list-timezones | grep -i etc
<ogra_> nothing
<ogra_> ogra@pi3:~$ sudo timedatectl list-timezones|grep -i utc
<ogra_> UTC
<Chipaca> so there you go
<ogra_> ogra@pi3:~$ sudo timedatectl list-timezones|grep -i etc
<ogra_> ogra@pi3:~$
<ogra_> well, but thats technically correct
<Chipaca> ogra_: and what happens if you try to set the timezone to something known-bad, e.g. "potato"
<kalikiana> sergiusens: ping
<mup> Bug #1733881 opened: timezone set to n/a on ubuntu core <Snappy:New> <https://launchpad.net/bugs/1733881>
<ogra_> ogra@pi3:~$ sudo timedatectl |grep Time
<ogra_>        Time zone: n/a (UTC, +0000)
<ogra_> ogra@pi3:~$ cat /etc/timezone
<ogra_> Etc/UTC
<sergiusens> kalikiana just speak up
<ogra_> Chipaca, it complains
<Chipaca> ogra_: where did the Etc/UTC come from?
<ogra_> Chipaca, my theor is that the test should really look inside the brackets
<ogra_> Chipaca, a default
<ppisati> $ ./runtests.sh static
<ppisati> ./runtests.sh: line 49: mypy: command not found
<ppisati> sergiusens: ^
<ppisati> elopio: ^
<ppisati> kyrofa: ^
<ogra_> Chipaca, i think thats the default tzdata ships
<ppisati> from origin/master at the time of this writing
<sergiusens> ppisati pip install -r requirements-devel.txt
<Chipaca> ogra_: maybe tzdata and timedatectl conflict?
<ogra_> might be
<ogra_> but there is no way to omit tzdata
<ogra_> it is super essential
<ppisati> sergiusens: ta
<ogra_> we'd have to completely change debootstrap and the archive setup for the package (not making it essential)
<kalikiana> sergiusens: do you know this code? I'm getting a failure in https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/sources/_local.py#L51 which uses https://github.com/snapcore/snapcraft/blob/master/snapcraft/file_utils.py#L86
<Chipaca> ogra_: are you writing /etc/timezone, or /etc/localtime?
<niemeyer> cachio: Getting an error on master while trying to run the snap-info spread test:
<ogra_> Chipaca, only timezone ...
<niemeyer> + apt install -y '/home/gopath/snapd_*.deb'
<Chipaca> ogra_: might be relevant: #1554806
<mup> Bug #1554806: Change of behavior: "dpkg-reconfigure -f noninteractive" unconditionally overwrites /etc/timezone now <tzdata (Ubuntu):Confirmed> <https://launchpad.net/bugs/1554806>
<niemeyer> cachio: That's bogus indeed.. the quoting kills the wildcard
<kalikiana> sergiusens: For some reason in the context of LXD on a remote machine and sshfs+sftp, it's not resolving symlinks
<niemeyer> cachio: Curious that it's not being an issue?
<sergiusens> kalikiana most likely related to the underlying filesystem, you might need to quirk it
<cachio> niemeyer, mmmm, I'll fix it
<ogra_> Chipaca, well ... more an issue with writable symlinking ...
<ogra_> ogra@pi3:~$ ls -l /etc/localtime
<ogra_> lrwxrwxrwx 1 root root 23 Nov 22 05:24 /etc/localtime -> /etc/writable/localtime
<ogra_> ogra@pi3:~$ ls -l /etc/writable/localtime
<ogra_> lrwxrwxrwx 1 root root 33 Nov 22 15:39 /etc/writable/localtime -> /usr/share/zoneinfo/Europe/Berlin
<ogra_> ogra@pi3:~$
<kalikiana> sergiusens: I noticed link_or_copy.follow_symlinks defaults to False, but shutil copytree is called with symlinks=True - that struck me as odd, but I also don't really know the code
<cachio> niemeyer, just 1 min after I finish the fedora 27
<ogra_> we have this multi staged symlinks there that always caused some issues
<niemeyer> cachio: Thanks.. I really wonder how that's not affecting other runs
<ogra_> to fix atomic writing ...
<kalikiana> sergiusens: I exhausted sshfs' options more or less... it has 3 link-related options, none of which make that code path work
<kalikiana> sergiusens: where I just want to understand why it breaks in the first place
<kalikiana> if I manually poke the files in the container, all is fine
<sergiusens> kalikiana we've had symlink issues when the underlying fs was hfs, what does, 'poke the files in the container' mean? Through python APIs?
<Chipaca> ogra_: timedatectl will always print UTC when timezone is unset / unknown / bogus
<ogra_> Chipaca, well, it works correct if the "Etc/" is dropped from /etc/timezone
<ogra_> i.e. if the tz entry matches what list-timezones provides
<ogra_> the easiest would simply be to put UTC into /etc/timezone at build time
<kalikiana> sergiusens: I mean doing `ls -la` or `cat` on the files that give me "[Errno 2] No such file or directory" in Python
<ogra_> but OTOH i still think the test is wrong to match the description and not the TZ
<sergiusens> kalikiana broken symlinks do that in python
<ogra_> it should look between the brackets, not at the descriptive name
<ogra_> i.e.
<ogra_> Time zone: Europe/Berlin (CET, +0100)
<ogra_> you want to match CET here, not "Europe/Berlin"
<ogra_> (since this will also be what date uses for example ... the rest is just nice to have but not technically relevant)
<kalikiana> sergiusens: right, except I can access the very same files from the container through sshfs via ls and cat
<kalikiana> I might be overlooking something here
<kalikiana> sergiusens: if it's relevant, it's all relative links
<sergiusens> kalikiana break the code in pieces by writing small implementations or activate the debugger (pdb)
<kalikiana> yeah, that's what I'll do now, just wanted to query if there were any obvious gotcha's with the current code
<kalikiana> thanks
<niemeyer> I honestly don't understand.. it consistently fails every single time for me.. how come we don't have broken tests in travis
<Chipaca> niemeyer: what fails for you?
<niemeyer> Chipaca: + apt install -y '/home/gopath/snapd_*.deb'
<niemeyer> Chipaca: This can't possibly work.. the quoting kills the wildcard
<cjwatson> It probably turns into a regex interpreted by apt, so might work if it's actually called snapd.deb?
<cjwatson> https://travis-ci.org/snapcore/snapcraft/jobs/305836865 doesn't obviously seem to be my problem (this is for https://github.com/snapcore/snapcraft/pull/1754, which doesn't change anything in that area) - known breakage?
<mup> PR snapcraft#1754: nodejs plugin: pass proxy configuration to yarn <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/1754>
<Chipaca> niemeyer: where is that command coming from?
<Chipaca> niemeyer: (grep doesn't find it here)
<mvo> Chipaca: what command?
<Chipaca> mvo: the apt install -y '...'
<cjwatson> so set -x output is a bit misleading here
<cg_> hey everyone. i'm new to snapcraft and trying to wrap my head around what are probably some simple concepts. right now, the issue is that i have two dependencies, currently defined as parts, and one needs to know the path of the other, or at least a path to some files that need to be shared so it can build.
<cjwatson> tests/lib/prepare.sh:        distro_install_local_package "$GOHOME"/snapd_*.deb
<cg_> could anyone help me figure this out?
<niemeyer> Chipaca: Must be distro_install_build_snapd
<cjwatson> it then gets quoted when distro_install_local_package calls   apt install $flags "$@"
<Chipaca> cjwatson: niemeyer: but distro_install_local_package "$GOHOME"/snapd_*.deb <- the * isn't quoted
<cjwatson> and set -x renders that as single-quotes, but that doesn't mean it was called that way
<Chipaca> ah
<cjwatson> the problem is that snapd_*.deb didn't exist so the glob didn't expand
<cjwatson> and something didn't pick that up as a failure earlier when it would have been 90% less confusing
<cjwatson> (or, yes, possibly from distro_install_build_snapd as the caller; same either way)
<niemeyer> cjwatson: Yeah, that must be it
<niemeyer> Either it's failing, or the prepare is just bogus and is not doing what it should
<niemeyer> The only thing I'm doing special here is to try to run a single test instead of the whole suite
<niemeyer> linode:ubuntu-16.04-64:tests/main/snap-info
<mup> PR snapcraft#1749 closed:  tests: add a script to run autopkgtests in the ppa  <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1749>
 * zyga-ubuntu is done with the kids and returns to work
<mvo> zyga-ubuntu: hm, the debian-sid tests are slightly strange, it fails with "snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks", I think I try to ssh into one
<zyga-ubuntu> mvo: looks like snap-confine is built without apparmor
<zyga-ubuntu> mvo: we may need to change the dpkg vendor test (remove it) in debian/rules
<zyga-ubuntu> mvo: hmmm, actually
<zyga-ubuntu> mvo: that probably makes no sense
<mvo> zyga-ubuntu: I thought I had done that already
<zyga-ubuntu> mvo: yeah, worth looking into for sure
 * zyga-ubuntu listens to "not your kind people" today
<mup> PR snapd#4263 closed: overlord/devicestate:  best effort to go to early full retries for registration on the like of DNS no host <Created by pedronis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4263>
<gsilva> kyrofa:  have you seen the PR? It failed for some reason but I can't tell why
<gsilva> Hello all, by the way
<mup> PR snapd#4109 closed: cmd/libsnap: fix parsing of empty mountinfo fields <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4109>
<zyga-ubuntu> pedronis: posted question on 4260
<cg_> Anyone available to help with what I'm gonna guess are some pretty basic questions?
<zyga-ubuntu> cg_: just ask your questions please, we'll do our best
<cg_> Yeah, tried that before but didn't want to just keep spamming...
<cg_> Alright, so I'm building a ROS project. It has two dependencies that I've been installing outside of ROS: our ethercat kernel modules and a library that provides an interface to ethercat.
<pedronis> zyga-ubuntu: that's auto-import, not the store,  not sure what those files are though
<pedronis> left overs?
<zyga-ubuntu> cg_: are you working on a classic or a core device? (classic = with typical package manager + snapd on the side; core = with just snapd)
<pedronis> I would need to dig more
<zyga-ubuntu> pedronis: aha
<zyga-ubuntu> pedronis: my measurement code can capture that
<zyga-ubuntu> pedronis: thanks for looking
<zyga-ubuntu> pedronis: I'll untangle the restore code and will be able to find those (hopefully) quickly
<zyga-ubuntu> cg_: btw, kyrofa here is a ros expert
<zyga-ubuntu> cg_: for kernel modules on core device you will need your own kernel + gadget snap
<kyrofa> kalikiana, pong
<cg_> zyga-ubuntu: i'm working with classic right now, hoping to move to core
<zyga-ubuntu> cg_: we may need a snapd interface for the ethercat but I don't know what this, just speculating so far
<zyga-ubuntu> cg_: ok
<zyga-ubuntu> cg_: that's fine, it's a well-defined move for this kind of thing
<cg_> zyga-ubuntu: so before i even start dealing with the kernel nonsense, i'm trying to get my head around what feels like some real Snapcraft 101 crap. I need to provide the paths to different dependencies so they can install correctly. The interface that helps us communicate with our ethercat driver needs to know the path to the ethercat library, and then ROS needs to know the path to the interface.
<kalikiana> kyrofa: Hey. Was wondering about file_utils.py / _local.py if you happend to know about its custom handling of symlinks. I'm doing some testing atm why the code would say "file not found" when ls and friends are happy with the files
<cg_> zyga-ubuntu: In my manual install world, I'd just clone my repos into ~/, build from there, point to ~/EtherCAT_Master or whatever
<zyga-ubuntu> cg_: path as in runtime path or build time?
<kyrofa> kalikiana, I am familiar with it, could you give me more details?
<zyga-ubuntu> cg_: suggestion: unless you absolutely must, try to snap hello world code first to see what you get and how it is built
<cg_> zyga-ubuntu: I'm gonna need both. Totally hung up at build time right now.
<zyga-ubuntu> cg_: and then how it operates (both are differnt)
<zyga-ubuntu> cg_: I know ... little about ros (/me looks at ROS topic mug from roscon) but build time should be handled by snapcraft
<cg_> zyga-ubuntu: these aren't ROS dependencies, as far as it is concerned. they're just C libraries that we reference, ROS has no idea what to do with them.
<zyga-ubuntu> cg_: if not kyrofa or sergiusens can help you and make fixes to snapcraft; you can also ask on the forum (forum.snapcraft.io) or talk in rocket.ubuntu.com (snapcrafters hang out there routinely)
<zyga-ubuntu> cg_: I'm mostly focused on runtime side of snapd
<cg_> zyga-ubuntu: The ROS aspect of this really doesn't matter. If I install these dependencies manually, my ROS part builds happily, everything works great. I'm just trying to cut out the manual steps.
<cg_> zyga-ubuntu: But yeah, right now, I'm hung up on building
<zyga-ubuntu> cg_: are those things packaged in some way?
<zyga-ubuntu> cg_: snapcraft has a concept of "build packages"
<zyga-ubuntu> cg_: (with the usual meaning)
<cg_> zyga-ubuntu: They are, but it feels sorta... hacky. Ignoring what they're actually called, Dependency 2 has the path to Dependency 1 hard-coded. I can feed it a path, I'm just lost RE: what that path should be in snapcraft world. Make sense?
<mvo> Chipaca: hm, hm, all the except tests are failing in debian-sid. I have a look in a bit
<Chipaca> mvo: expect*?
<cg_> zyga-ubuntu: Normally, I can just point it at the repo that I've cloned to my home folder. With snapcraft handling it and each dependency broken into separate parts, I'm unsure of how to tell Dependency 2 how to find Dependency 1. It doesn't feel like a healthy practice but I'm unsure of how Snapcraft would prefer me to approach it.
<kyrofa> Hey there cg_, are we talking about https://forum.snapcraft.io/t/part-referencing-other-part/2929/3 ?
<mvo> Chipaca: eh, yes
<Chipaca> mvo: :)
<cg_> kyrofa: Hello! Yessir
<mvo> Chipaca: anyway, just wanted to let you know, I need to take a break now
<Chipaca> mvo: np
<kalikiana> kyrofa: so this is with a LXD container and files served via sshfs/sftp, which means smylinks might work differently; the error I'm getting is at https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/sources/_local.py#L51 which uses https://github.com/snapcore/snapcraft/blob/master/snapcraft/file_utils.py#L86  -- it's giving me a shutil.Error with a list of files and [Errno 2] No such file or directory in the end
<kalikiana> - all the given symlinks resolve  fine with ls or cat in a shell in the container, just the specific snapcraft code doesn't work
<kyrofa> cg_, I asked a question there for you
<cg_> kyrofa: Thanks, on it
<zyga-ubuntu> 2PRs short of one page
<zyga-ubuntu> some just wait for tests
<zyga-ubuntu> mvo: can you please look at 4140
<zyga-ubuntu> mvo: it's green and has +1 from me
<zyga-ubuntu> mvo: with a quick look we can get down to 26 PRs
<mup> PR snapd#4184 closed: tests: adding new test for uhid interface <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4184>
<pedronis> Chipaca: anyway firt pass at that issue is probably remembering who did what,  unless the store apis change radically
<Chipaca> pedronis: â¦ which issue?
 * Chipaca is lost
<pedronis> Chipaca: us sending no auth with auto refreshes
<Chipaca> pedronis: ah
<zyga-ubuntu> pstolowski: 4218 needs a 2nd look from you
<pstolowski> zyga-ubuntu, ok, looking
<pedronis> mvo: do we run autopkgtest daily?
<pstolowski> cachio, I think you forgot to push your changes to #4218
<mup> PR #4218: tests: adding tests for time*-control interfaces <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4218>
<cachio> pstolowski, almost pushed
<cachio> 1 min please
<pstolowski> cachio, sure, np
<zyga-ubuntu> cachio: comment son 4078
<cachio> pstolowski, push donedone
<pstolowski> ok
<cachio> zyga-ubuntu, done
<cachio> zyga-ubuntu, wait
<cachio> zyga-ubuntu, now :)
<mup> PR snapd#4273 closed: timeutil: introduce helpers for weekdays and TimeOfDay <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4273>
<zyga-ubuntu> cachio: thank you!
<zyga-ubuntu> cachio: I'm really curious what that about
<cachio> zyga-ubuntu, yaw
<cachio> zyga-ubuntu, yes, it is really weird, but I could reproduce it even manually
<zyga-ubuntu> cachio: do you know if any snaps were installed after reboto?
<zyga-ubuntu> *reboot
<cachio> no, I just reproduces the test but manually
<cachio> just to make sure the test was working properlyu
<zyga-ubuntu> interesting
<zyga-ubuntu> well, we'll keep digging
 * ikey grins in advance of teaching niemeyer that rolling can be stable
<mup> PR snapd#4275 closed: spread.yaml,tests: move most of project-wide prepare/restore to separate file <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4275>
<pstolowski> niemeyer, pedronis updated 4259 with new test
<zyga-ubuntu> Chipaca: if around, could you do 4276
<mup> PR snapd#4276 opened: tests: document and slightly refactor prepare/restore code <Created by zyga> <https://github.com/snapcore/snapd/pull/4276>
<zyga-ubuntu> cachio: can you also look please, there's one XXX thre I don't fully understand and I suspect you know
<Chipaca> zyga-ubuntu: â¯
<sergiusens> zyga-ubuntu we do not use rocket anymore
<zyga-ubuntu> Chipaca: emoji don't show up in linux console
<zyga-ubuntu> sergiusens: oh, I didn't know thanks for sharing that
<zyga-ubuntu> I wish forum and rocket could merge shomehow
<zyga-ubuntu> but IRC is just so darn immortal
<niemeyer> ikey: I literally said "anyone publishing such snaps needs to understand and agree to preserve a stable API", to which you responded "thatâs not gonna happen"
<Chipaca> zyga-ubuntu: ð©
<niemeyer> ikey: I never even touched the word "rolling"
<ikey> woah woah
<ikey> back up a bit there sham
<ikey> im poking fun
<ikey> didnt realise there was a bear on the end of it
<ikey> the way you worded it was "frozen forever"
<ikey> and thats not gonna happen
<ikey> stable yes, locked, no
<ikey> distinction. :]
<niemeyer> ikey: I also didn't say "locked" either :-)
<niemeyer> ikey: Or "frozen"
<ikey> sure - i was replying to my interpretation based on the facts provided to me by you. notice i still agreed to a call as it was clear not all facts are present on both sides ;)
<niemeyer> ikey: We just need it stable.. which means existing functionality cannot be removed or broken
<zyga-ubuntu> ikey: where there's honey, there's bear ;-)
<niemeyer> Including both APIs and ABIs
 * zyga-ubuntu just makes up proverbs
<ikey> ABIs *can* be changed
<ikey> This is rolling, by design they need to
<ikey> And this isn't a derivable snap, it exists purely to satisfy LSI :P
<niemeyer> Sure.. then it can't be a base snap
<ikey> well then ill fuck off and build a flatpak
<ikey> cya
<niemeyer> ikey: That's why a hangout is probably better :)
<ikey> at this point niemeyer you insult me after having kept me waiting over a week with this tiresome review only to tell me what can and cant be in a base snap
<ikey> without understanding the fundamentals of the situation
<ikey> seriously i dont need snaps as much as snaps need external verification and technical acceptance
<ikey> i dont need the politics and stress of it
<kalikiana> sergiusens: did you see my email?
<niemeyer> ikey: I'd still prefer to have this conversation on a hangout.. the few sentences I wrote aren't really personal at all.. I'm politely trying to explain the issues we're trying to address, and looking for help
<ikey> as am - i cant word too good because im trying to stick a boot on at the same time
<ikey> laces are hard
<ikey> and fwiw im not personally insulted - there are levels :p
<ikey> but im not against a phone call
<niemeyer> ikey: https://hangouts.google.com/call/PwzjjN4oHDxFeAyGDiJ_AAEE
<ikey> yeah gizza sec genuinely fighting with a boot here
<sergiusens> kalikiana the one I replied to?
<niemeyer> Will grab a cuppa coffee meanwhile... HO still open
<mup> PR snapd#4266 closed: snapstate: add new refresh-hints helper and use it <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4266>
<niemeyer> If anyone else closely involved with base snaps wants to join, that's welcome too
<niemeyer> mvo, jdstrand ^
<kalikiana> sergiusens: I don't see a reply... not on my phone either, in case this was tb being broken
<zyga-ubuntu> cachio: you have comments on 4227
<zyga-ubuntu> cachio: looks like super simple ones
<cachio> zyga-ubuntu, ok, finishing fedora resizing
<zyga-ubuntu> cachio: thank you
<sergiusens> kalikiana check your spam and filters (look in AllMail)
<kalikiana> sergiusens: I don't have any spam filters, this is good old canonical imap
<ikey> o-o
<ikey> call closed
<zyga-ubuntu> ikey: what happened?
<ikey> fixed ^^
<sergiusens> kyrofa elopio can you join me on a hangout right now?
<kyrofa> sergiusens, sure
<sergiusens> kyrofa use the weekly
<kyrofa> sergiusens, I'm there
<elopio> sergiusens: on my way
<zyga-ubuntu> 14.04 has something very very wrong
<zyga-ubuntu> snapd starts randomly when it is supposed to be down
<zyga-ubuntu> cannot wait to find the culprit
<pedronis> that is interesting
<cachio> niemeyer, I dont see dsingle cuotes use to install any package
<cachio> niemeyer, while I try to see why the snap-info test failedf
<cachio> niemeyer, do you have any log?
 * zyga-ubuntu breaks for some rest, will return to push more branches 
<zyga-ubuntu> so, why is main never failing
<zyga-ubuntu> I'm running main all the time, almost, for the past two days
<zyga-ubuntu> could it be that one of the "lesserly interesting" tests in other suites is messing things up
<zyga-ubuntu> mvo: question, could we get a different entry in travis, one for running main and one for running all the things but main
<zyga-ubuntu> mvo: we'd use more machines but they would also run much more quickly
<zyga-ubuntu> mvo: and I suspect a pattern would emerge
<zyga-ubuntu> mvo: (maybe even run suites independently from each other)
<zyga-ubuntu> mvo: (like one status per suite)
<zyga-ubuntu> mvo: this could have 3 advantages: restarts would be per suite, we'd get data about relative rate of random errors in each suite
<zyga-ubuntu> mvo: and we could perhaps lower the number of workers
<zyga-ubuntu> (or keep workers and get super-fast results)
<zyga-ubuntu> if main is working on my "consumer" home network it should not fail any less on the fancy datacenter speedy network and CPUs
<zyga-ubuntu> and meanwhile, I'll see what I get if I run other suites
<zyga-ubuntu> I'd be really upset if it was like upgrade/basic killing our time by leaving junk
<mup> PR snapd#4272 closed: snapstate: ensure RefreshSchedule() gives accurate results <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4272>
<mup> PR snapd#4277 opened: osutil/user: replace our uses of os/user and filepath.Glob("/home/*") <Created by chipaca> <https://github.com/snapcore/snapd/pull/4277>
<Chipaca> 12 37 files changed, 741 insertions(+), 309 deletions(-)
<Chipaca> s/^12//
<Chipaca> :-/
<Chipaca> anyway, EOD for me
<zyga-ubuntu> Chipaca: hohoho
<zyga-ubuntu> Chipaca: oooh
<zyga-ubuntu> Chipaca: please please please
<Chipaca> zyga-ubuntu: wut
<zyga-ubuntu> Chipaca: 4276
<zyga-ubuntu> Chipaca: just a look
 * Chipaca justs a look
<zyga-ubuntu> Chipaca: per commit diff is easier to read
<Chipaca> zyga-ubuntu: nice
<Chipaca> zyga-ubuntu: http://gph.is/QUEGv3
 * zyga-ubuntu types the URL on another computer
<zyga-ubuntu> LOL
<zyga-ubuntu> Chipaca: thanks, enjoy your evening
<zyga-ubuntu> Chipaca: should we retry 504s from the store?
<zyga-ubuntu> snap install --channel=beta core
<zyga-ubuntu> that just failed with received an unexpected http response code (504)
<ikey> zyga-ubuntu, qemu-static arm64 for /bin/sh - go!
<ikey> definitely the most evil idea ive had all year.
<zyga-ubuntu> ikey: heh, that might actually work pretty well
<zyga-ubuntu> *for some definition
<ikey> XD
<zyga-ubuntu> single threaded
<zyga-ubuntu> and ... static
<ikey> lol
<zyga-ubuntu> (insert meme with dog and "LOL", "so static", "enterprise", "runs on RHEL6"
<ikey> yeah but if its not running on btrfs..
<zyga-ubuntu> oh, why?
<ikey> idk you said lol and enterprise
<ikey> felt relevant
<zyga-ubuntu> ikey: RHEL defines enterprise as RHEL and they define btrfs as xfs (or something)
<zyga-ubuntu> ;-)
<zyga-ubuntu> I like the "runs on RHEL6" as a meme thing
<ikey> lol
 * ikey used to live by reiserfs
<ikey> emphasis on used to
<niemeyer> cachio_afk: There's some other bug
<niemeyer> cachio_afk: You should be able to reproduce it by just running spread to run this one task: linode:ubuntu-16.04-64:tests/main/snap-info
<niemeyer> cachio_afk: The bogus command line, as cjwatson mentioned, is just a side effect of snapd not being properly built
<niemeyer> cachio_afk: The question is why it wasn't properly built
<niemeyer> Taking a break.. back later to finish the images
<zyga-ubuntu> niemeyer: o/
<zyga-ubuntu> niemeyer: we're on one page now ^_^
<ikey> https://github.com/solus-project/runtime-snaps/commit/f91097d47fc1fce231110c87c2469a3f74df0a37 <- better.
 * zyga-ubuntu -> shopping
<zyga-ubuntu> jdstrand: hey
<zyga-ubuntu> jdstrand: not much updates today, I'm getting tea and I'll iterate on both interesting PRs
<zyga-ubuntu> jdstrand: I'm pushing towards finding why test suite is so unreliable
<niemeyer> cachio: We've got multiple issues in our suite apparently
<niemeyer> cachio: One of them is prepare-project.sh seems to be missing set -e, which means it's not stopping on errors
<cachio> niemeyer, let me see
<niemeyer> The build procedure is also for some reason not building _build/snap, which is depended upon for building the man pages
<niemeyer> That's the error that makes the snapd_*.deb not be generated
<niemeyer> cachio: I got this sort of error by just trying to run the task mentioned above
<niemeyer> cachio: Possibly means I have a dirty tree.. I'll try again with a clean tree, but we should at least ensure all our scripts have -e so they fail on problems
<cachio> niemeyer, ok, I jast reviewed the log and "set -e" was not removed from prepare-project
<cachio> niemeyer, at least during the last 6 months
<niemeyer> cachio: Well, does that matter? :)
<cachio> niemeyer, we should add it
<niemeyer> Yeah
<niemeyer> cachio: We can also take the chance to grep quickly and see if there are others missing
<cachio> niemeyer, doing that
<cachio> niemeyer, most of the scripts on tests/lib dont have "set -e"
<niemeyer> cachio: Some of them are used as libraries, so that's less of an issue I *think*
<niemeyer> cachio: Won't hurt to have it, though
<cachio> niemeyer, agree
<cachio> I'll create a PR with that
<niemeyer> cachio: Thanks
<cachio> niemeyer, by the way, snapd-vendor is being sync
<niemeyer> cachio: Looking into Spread-46 now
<cachio> niemeyer, ok, I am testing debian-9
<cachio> I'll push the changes once there are not errors anymore
<niemeyer> cachio: Spread-46 has *grown* since we last tried
<niemeyer> cachio: It's now at 2.2GB
<cachio> I removed about 200 MB
<niemeyer> Did you try the zero trick?
<cachio> yes
<niemeyer> (after that)
<cachio> yes
<cachio> the last think I did
<cachio> let me check again
<niemeyer> Well.. something curious is happening.. it's now larger
<niemeyer> cachio: I'm booting it back up.. should take a few seconds
<cachio> niemeyer, I could remove some locales that are using more than 100MB
<cachio> niemeyer, not sure if it could affect anything
<niemeyer> cachio: It's certainly less wasted space in the image
<niemeyer> cachio: But it still doesn't explain why removing data made the image larger
<niemeyer> cachio: Something else must have happened there
<niemeyer> cachio: Does it have auto-update on, maybe?
<cachio> niemeyer, it just updates repo metadata
<cachio> I could disable it but not sure if then it could cause any issue
<cachio> niemeyer, well it is alreasy disabled
<cachio> niemeyer, could you try again to build the image?
<niemeyer> cachio: Sure, trying it now
<cachio> niemeyer, the only thing that it missing is to remove the locales
<niemeyer> cachio: It's back at 1.7GB
<niemeyer> cachio: 1.76, to be more precise
<niemeyer> cachio: What did you do there?
<cachio> cleaned up again dnf and removed 1 pkg and the zyga magic
<zyga-ubuntu> try e4defrag
<zyga-ubuntu> that may clear extra blocks for zero
<zyga-ubuntu> (zero after)
<cachio> ok
<cachio> niemeyer, could you please start the vm?
<niemeyer> It's coming up
<cachio> niemeyer, could you please try againdf
<niemeyer> cachio: On it
<cachio> 1gb of data used
<cachio> locales removed
<niemeyer> cachio: 1.6G image
<cachio> niemeyer, how do you create the image? it is a linode api?
<niemeyer> cachio: Using the console.. I don't think there's an API yet
<niemeyer> cachio: copy the disk, shutdown the machine, attempt to shrink the disk
<niemeyer> cachio: trash it, start over
<cachio> the shrink is not so powerfull :)
<niemeyer> cachio: It's just resize2fs
<niemeyer> cachio: We can try e4defrag
<cachio> I already did in the vm
<cachio> niemeyer, not sure if you can do it from the console
<niemeyer> cachio: Oh
<niemeyer> cachio: Ok.. so really have no idea about why it's not getting down to more reasonable sizes
<cachio> disk usage is less than 1.1 GB
<cachio> niemeyer, I checked that at the end
<niemeyer> cachio: Well, that's logical size
<niemeyer> cachio: Image is block size
<niemeyer> cachio: A 1 byte file still takes one block
<niemeyer> Sort of.. file system pages vs. blocks..
<gsilvapt> kyrofa, since you are around, could you please have a look PR 1746? The build failed but I don't think it is entirely related with poor software quality
<mup> PR #1746: many: have AuthContext expose device store-id, serial and serial-proof signing to the store <Critical> <Reviewed> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1746>
<niemeyer> cachio: Can we take more data out of it?
<kyrofa> gsilvapt, will do, working on something else at the moment but I'll take a look when I can
<gsilvapt> kyrofa, of course, take your time! :-)
<cachio> niemeyer, if you want I could create a new image from scratch
<cachio> install deps and see the size
<niemeyer> cachio: Sounds good.. another approach would be doing what I suggested yesterday, listing packages ordered by size and taking low hanging fruits out
<niemeyer> cachio: Whatever you prefer
<cachio> niemeyer, I already did that
<cachio> I cleand 200MB doing this
<cachio> cleaned
<niemeyer> cachio: Yeah, so more of it? :)
<cachio> niemeyer, well, the problem is that the bigger ones seem to be needed, I can make another try
<cachio> and remove more pkgs
<niemeyer> cachio: That's what I did when I got our images down to 600MB, but again any approach you prefer is fine by me
<cachio> niemeyer, ok, I'll try it tomorrow morning
<niemeyer> cachio: Thanks again
<cachio> zyga-ubuntu, https://travis-ci.org/snapcore/snapd/builds/305892636#L1473
<cachio> zyga-ubuntu, there it is the info for the "no interfaces found" issue
<zyga-ubuntu> cachio: I'll check it out tomorrow, I'm sleeping here almost :)
<cachio> zyga-ubuntu, sure, just I wanted to leave you a message for tomorrow
<cachio> zyga-ubuntu, enjoy your dreams :)
<sergiusens> kyrofa elopio kalikiana https://insights.ubuntu.com/2017/11/22/announcing-snapcraft-2-35/
#snappy 2017-11-23
<mup> PR snapd#4276 closed: tests: document and slightly refactor prepare/restore code <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4276>
<mborzecki> morning everyone
<ikey> weird question, but why does "snap find solus" list clementine and nextcloudclient? :D
 * ikey is truly baffled
<zyga-solus> good morning
<ikey> morning
<zyga-solus> ikey: hey
 * zyga-solus needs to take tomorrow off, too many days off, a bit tired
<ikey> :/
<mborzecki> zyga-solus: morning
<zyga-solus> hey :-)
<mborzecki> zyga-solus: found an old patch that i missed whel opening all the arch related PRs
<zyga-solus> mborzecki: oh, nice, what does it do?
<mborzecki> you remember that we had an assumption that daemon user is uid 1?
<zyga-solus> yes
<mup> PR snapd#4278 opened: cmd/snap-seccomp: fix uid/gid restrictions tests on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4278>
<mborzecki> well the patch fixes the assumption :) or rather gets rid of if
<zyga-solus> nice, looking
<zyga-solus> mborzecki: short and simple, thanks!
<mborzecki> yw
<mborzecki> had nigthmares about the refresh timer parser? :)
<mvo> zyga-solus, mborzecki good morning
<zyga-solus> haha
<mborzecki> mvo: hey
<zyga-solus> no, but I did dream of not working tomorrow ;D
<zyga-solus> and I think I'll just do it
<mvo> zyga-solus: we had a strange wildcard error in some tests last night, do you know if this is fixed
<zyga-solus> mvo: no, I read that sergio and gustavo were discussing it
<zyga-solus> mvo: do you have a reference
<zyga-solus> mvo: I'm not sure if that is the same thign
<zyga-solus> *thing
<mvo> zyga-solus: no worries, I have a look, was just wondering if I'm chasing windmills or dragons ;)
<zyga-solus> mvo: it's always dragons here :D
<zyga-solus> mvo: (sometimes dragons sit on top of windmills)
<mvo> lol
 * mvo hugs zyga-solus 
<kyrofa> zyga-solus, what happened with https://github.com/snapcore/snapd/pull/4258 ?
<mup> PR #4258: cmd/snap-confine,tests: fix unmounting on systems without rshared / <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4258>
<zyga-solus> kyrofa: I discussed it with jdstrand, we need to tweak it slightly in order not to make snap-confine too powerful,
<zyga-solus> kyrofa: I'll get back to it
<zyga-solus> kyrofa: I'm looking at why master breaks so often as this clamps our velocity a lot
<kyrofa> Ah okay, very good. Still a path forward, though?
<zyga-solus> yes, totally
<kyrofa> Alright, night guys. Note that I'm off tomorrow
<zyga-solus> kyrofa: lovely, enjoy!
<mborzecki> some of the tests in my PR failed with 504 gateway timeout coming from the store, this is some bad luck
<zyga-solus> mborzecki: store had some issues yesterady
<zyga-solus> also, not sure if real or fluke due do damaged tests, I saw a lot of EOF errors on assertions
<zyga-solus> so, if you are using qemu for testing I will have one simple and sweet improvement
<zyga-solus> currently running 8 workers locally, seeing almost no network traffic
<zyga-solus> still some polish to do but the patch is a few lines long and simple to use
<zyga-solus> I realized that a single run burned about 2GB of data
<zyga-solus> and my mobile quota is high but not infinite
<zyga-solus> so this will not only be faster but also more economic ^_^
<zyga-solus> and there's far less waiting for IO
<zyga-solus> obligatory pic: https://twitter.com/zygoon/status/933591581206237184
<zyga-solus> ^_^
<mborzecki> nice
<zyga-solus> mvo: I ran main, regression and completion suites yesterday in a loop
<zyga-solus> mvo: none of those failed with one of those weird random errors
<zyga-solus> mvo: I'll extend that to the full suite to see if I see any pattern
<mvo> zyga-solus: interessting and good to know
<paulliu> hi. I'm running Debian testing and I cannot run "snap run hello-world". http://paste.ubuntu.com/26025879/
<paulliu> How do I debug?
<zyga-solus> paulliu: hey, we are aware of the issue, sorry for the bad experience
<paulliu> zyga-solus: got it. thanks. :)
<zyga-solus> paulliu: we made some patches but it seems it's not enough, we are looking into the issue with the help of our kernel developers
<zyga-solus> paulliu: it's likely the next release will have a fix or workaround
<zyga-solus> paulliu: for now you can try booting with apparmor=0
<zyga-solus> paulliu: that _might_ fix it
<paulliu> zyga-solus: thanks for the info. I just thought it was me that makes something wrong on my system. Thanks a lot. :)
 * zyga-solus sees some wasted traffic, adds snaps to cache 
<mup> PR snapcraft#1755 opened: WIP:  tests: collect the autopkgtest results and save them in git  <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1755>
<mup> PR snapd#4278 closed: cmd/snap-seccomp: fix uid/gid restrictions tests on Arch <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4278>
<mup> PR snapd#4277 closed: osutil/user: replace our uses of os/user and filepath.Glob("/home/*") <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4277>
<zyga-ubuntu> man, what's going on with EOFs on assertions
<Chipaca> zyga-ubuntu: where?
<zyga-ubuntu> Chipaca: on random PRs, look at failures, it's a common pattern
<mvo> Chipaca, zyga-ubuntu also randomly failing: http://paste.ubuntu.com/26026114/
<zyga-solus> mvo: hmmm
<Chipaca> mvo: gustavo was seeing that one yesterday
<zyga-solus> mvo: do you have dpkg build logs on that debug shell?
<mvo> zyga-solus: maybe - it happend just now
 * kalikiana coffee
<mvo> zyga-solus: funny (sort of) - looks like no log at all
<Chipaca> mvo: well the error is because there is nothing matching snapd_*.snap
<zyga-solus> mvo: hmm
<Chipaca> so of all funny things, this one at least makes sense
<zyga-solus> yes
<mborzecki> 4252 fails the same way
<mvo> Chipaca: right, there is nothing there, the interessting question is why and why did it not fail earlier
<mvo> Chipaca: I don't see anything in /home/gopath/ except the subdirs
<Chipaca> mvo: incompatible bit-registration operators
<mborzecki> + dnf -q -y install '/home/gopath/snap-confine*.rpm' '/home/gopath/snapd*.rpm'
<Chipaca> mvo: (bofh excuse generator time!)
<Chipaca> zyga-solus: did your changes to prepare etc land?
<zyga-solus> Chipaca: would it be hard for snap download to be a no-op if there's a file in place that's just right?
<zyga-solus> Chipaca: yes, but i have many more to make before we get the benefits
<mvo> Chipaca: lol
<Chipaca> zyga-solus: my question was because i wonder if that's why we no longer have .debs
<zyga-solus> Chipaca: well
<mvo> zyga-solus: it would be trivial, we did this a long time ago in apt
<zyga-solus> Chipaca: I doubt it's that
<mborzecki> the build fails https://paste.ubuntu.com/26026137/
<mborzecki> man the logs are not the easiest to browse
<zyga-solus> man that's one looooong line
<zyga-solus> exit code 2, that's helpful
<Chipaca> zyga-solus: "download be a no-op" <- didn't we already do that
<zyga-solus> Chipaca: nope
<zyga-solus> Chipaca: we pull and pull and pull and overwrite
<zyga-solus> mborzecki: what's the error there?
<mborzecki> ha no clue, dh failed, go install returned -2
<mvo> zyga-solus: any idea about https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734038 ? it looks strange and does not error for me
<mup> Bug #1734038: Potential regression found with apparmor test on Xenial/Zesty <apport-bug> <package-from-proposed> <regression-proposed> <s390x> <xenial> <zesty> <linux (Ubuntu):Incomplete> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1734038>
<zyga-solus> mvo: yes, you need to be on bionic
<zyga-solus> mvo: #include is now mandatory, apparmor broke syntax
<mvo> zyga-solus: wuut? you need to be on bionic for #include?
<mvo> zyga-solus: you are saying 2.29.4 in -proposed is broken everywhere?
<pedronis> fwiw even on xenial   man apparmor.d  doesn't mention include without #
<zyga-solus> mvo: bionic has new apparmor that stopped supporting bare include and now requires #include
<zyga-solus> pedronis: it was documented on apparmor documentation website
<zyga-solus> jdstrand was surprised too :)
<mvo> zyga-solus: the bugreport is about xenial/zesty
<zyga-solus> mvo: maybe we got a backport/update?
<zyga-solus> mvo: it was in bionic last week
<mvo> zyga-solus: ok, so its a simple matter of s/include/#include/ ?
<zyga-solus> yes
<mvo> zyga-solus: and we may need a .5 :(
<zyga-solus> but I suspect upstream will be fixed later on
<zyga-solus> mvo: well, I honestly feel this is not our bug
<zyga-solus> mvo: we can work around but this is broken apparmor parser
 * mvo sits in a corner and sobs
<mvo> zyga-solus: ok
<zyga-solus> mvo: also, it's a conffile
<zyga-solus> mvo: people can forever stay on the "broken" version
<pedronis> me is a bit sceptical that they will "fix" it
<mvo> zyga-solus, Chipaca so I think mborzecki found the issue, if the tests/build fails for whatever reason the script does not fail and we keep going until the error with the missing debs happens. slightly strange what regressed here
<zyga-solus> mvo: so we carry on even if build fails, sweet
<zyga-solus> mvo: do you think that's something I broke?
<mborzecki> set -e ?
<mvo> zyga-solus: git log indiciates that you touched it last ;) so there is a chance for this. but no worries
<zyga-solus> mborzecki: I have a suspicion
<zyga-solus> spread sets -e
<mvo> mborzecki: yeah, recent refacors probably
<zyga-solus> and this is not carried into scripts that are not sourced
<zyga-solus> (I hate this sourcing that is going on, everything is sourced and has side effects apart from functions
<zyga-solus> anyway, let me fix this
<pedronis> ?
<pedronis> do we source things with side effects?
<zyga-solus> sure we do
<zyga-solus> most scripts have a bunch of functions and then happy execution down below
<mborzecki> hm looking at fedora log I see there's snapd package, but there there should be snap-confine as well right?
<zyga-solus> and we source them to get MATCH and stuff
<zyga-solus> mborzecki: no, we don't want to have separate snap-confine
<zyga-solus> mborzecki: it's just historic
<pedronis> mvo:  http://wiki.apparmor.net/index.php/AppArmor_Core_Policy_Reference#Include_statements  otoh it's a wiki
<zyga-solus> pedronis: thank you for finding that!
<zyga-solus> pedronis: it's an upstream bug
<pedronis> it's a bizarre "bug"
<mborzecki> hm fedora rpm spec is still building 2 packages from what i can see
<Chipaca> sigh
<pedronis> I mean it should have been conscious
<zyga-solus> mborzecki: it's something that needs to be fixed, but it takes time
<Chipaca> mvo: zyga-solus: so the bug is right there
<pedronis> it's kind of hard to randomly change your syntax
<pedronis> unless your parser is horrible
<Chipaca> mvo: zyga-solus: prepare-restore.sh does not set -e
<zyga-solus> yes, that's what I just fixed
<Chipaca> mvo: zyga-solus: and it's executed, not sourced
<zyga-solus> while I loath -e, it's the lesser evil
<zyga-solus> yep, I reached the same conclusion
<zyga-solus> PR coming up
<Chipaca> zyga-solus: -e -u and pipefail are the only sane way to have these set up imo
<mborzecki> zyga-solus: the error on fedora is: https://paste.ubuntu.com/26026198/ looks like snapd was built, but snap-confine was not, maybe that's a hint
<zyga-solus> Chipaca: !shell is saner :)
<zyga-solus> Chipaca: remind me why -o pipefail is useful?
<zyga-solus> Chipaca: (I'm writing a comment)
<Chipaca> zyga-solus: the exit status of âfoo | barâ is the exit status of bar, without it
<mborzecki> btw. do you guys see a number of can interfaces popping up after running seccomp test suite?
<zyga-solus> mborzecki: nope?
<zyga-solus> mvo: btw, sergio found a very worrying thing
<mborzecki> they are nr0-nr3 and rose0-rose9
<zyga-solus> mvo: on reboot the interfaces are lost
<zyga-solus> mvo: reliably
<zyga-solus> mvo: his PR has all the details, I didn't dig into it
<zyga-solus> Chipaca: 4279
<zyga-solus> and sorry about that folks
<mup> PR snapd#4279 opened: tests: set -e, -o pipefail in prepare-restore.sh <Created by zyga> <https://github.com/snapcore/snapd/pull/4279>
<mvo> zyga-solus: looking
<mvo> zyga-solus: so we have more scripts that need set -eu etc?
<zyga-solus> mvo: I think just this one as it's a new script
<mvo> zyga-solus: ok
<zyga-solus> mvo: I'll add -u shortly, just looking at some problem
<mvo> ta
<zyga-solus> Chipaca: can you please look at 4280
<mup> PR snapd#4280 opened: tests: remove obsolete workaround <Created by zyga> <https://github.com/snapcore/snapd/pull/4280>
<Chipaca> zyga-solus: why not ln instead of cp?
<Chipaca> zyga-solus: even better, cp -l (so it falls back to a plain cp if it can't ln)
<zyga-solus> Chipaca: interesting, I had some reasons but I'm re-examining now
<zyga-solus> Chipaca: there's some extra stuff coming but I think symlinks could be fine, I just hate the syntax :)
<Chipaca> zyga-solus: reflink doesn't work on the filesystems we're running tests on afaik, fwiw
<Chipaca> zyga-solus: ln, not ln -s
<zyga-solus> Chipaca: yes, only on xfs AFAIK
<Chipaca> zyga-solus: that is, hard links
<Chipaca> zyga-solus: (cp -l does hard links)
<zyga-solus> does cp -l handle xdev?
<Chipaca> zyga-solus: yes
<Chipaca> zyga-solus: it falls back to a regular cp
<zyga-solus> sounds good then, I'll adjust that
<zyga-solus> Chipaca: do you know if the store proxy thing is working now?
<Chipaca> zyga-solus: --link instead of -l if you want it to self-document a little more
<zyga-solus> Chipaca: oh, for sure
<mvo> zyga-solus: I pushed a fix for the debian-sid failure that cachio had into his branch (just fyi)
<zyga-solus> mvo: what was the problem?
<mvo> zyga-solus: https://github.com/snapcore/snapd/pull/4265/commits/9f534e22dabd022f72e9376bf6f84913461e85a1
<mup> PR #4265: New debian-sid-64 and debian-9-64 images for testing <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4265>
<mvo> zyga-solus: i.e. snap-confine needs a profile
<zyga-solus> ohh
<zyga-solus> thank you, great find
<mvo> zyga-solus: yw
<mup> PR snapd#4279 closed: tests: set -e, -o pipefail in prepare-restore.sh <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4279>
<zyga-solus> thanks!
<Chipaca> my question isn't why user-data-handling failed in #4277; it's how it doesn't fail before it
<mup> PR #4277: osutil/user: replace our uses of os/user and filepath.Glob("/home/*") <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4277>
 * Chipaca digs
<mup> PR snapd#4281 opened: snapstate: support for pre-refresh hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/4281>
<mvo> zyga-solus: http://paste.ubuntu.com/26026470/ is what you wnated for snap download, rightÃ
<zyga-solus> yes!
<zyga-solus> please :D
<zyga-solus> it will help with caching
<mvo> zyga-solus: once I wrote a test I will push a PR
<mvo> zyga-solus: slightly sad, we apparently have no test for DownloadSnap, so a good time to write one :)
<zyga-solus> :-)
<zyga-solus> mvo: download is totally client-side, right?
<mvo> zyga-solus: yes
<zyga-solus> ok, now way to reuse the cache but that's not too terrible
<Chipaca> zyga-solus: mvo: download should try to chat with snapd though
<pstolowski> zyga-solus, tiny suggestion to 4280
<Chipaca> zyga-solus: mvo: ideally it'd try (but gracefully handle failing) to ask snapd for things like what creds to use, and what cache to use if any? maybe more stuff
<zyga-solus> Chipaca: yes, that would be perfect
<zyga-solus> pstolowski: looking
<Chipaca> zyga-solus: mvo: note it could even get a filehandle back from snapd
<Chipaca> (we don't currently do that but it's possible)
<zyga-solus> very good idea pstolowski
<zyga-solus> Chipaca: yeah, I was thinking about that :)
<zyga-solus> Chipaca: streaming doesn't seem too terrible though, no real difference here
<Chipaca> OTOH as soon as we get into passing filehandles the idea of exposing snapd to the network transparently goes away
<Chipaca> OTOÂ²H we're already there with crednet
<Chipaca> so, fun time
<zyga-solus> pstolowski: updated
<Chipaca> we have a test that only passes because of how we were looking at homes
<Chipaca> :-)
<Chipaca> it does: mkdir -p /home/*/snap/test-snapd-tools/$rev/
<zyga-solus> * ?
<Chipaca> which creates a directory in /home/ called "*"
<zyga-solus> LOL
<Chipaca> hi-fucking-larious
<pedronis> Chipaca: well, that's tests
<zyga-solus> Chipaca: did you see my measurement PR for spread, maybe you can use it sooner for something useful?
 * Chipaca wonders how badly he messed up that spelling
<magicaltrout> hello folks, is there any issues with the snap review queue?
<Chipaca> magicaltrout: there shouldn't be one, why?
<Chipaca> magicaltrout: AFAIK there isn't a queue; either review passes, or you need to open a topic in the forum explaining why you're special :-)
 * Chipaca might be oversimplifying things
<magicaltrout> hehe
<magicaltrout> i pushed a snap 30 minutes ago
<magicaltrout> it says failed
<magicaltrout> but the cli is hanging
<Chipaca> magicaltrout: which cli?
<magicaltrout> snapcraft push
<Chipaca> ah
<magicaltrout> and on the dashboard is says 2 fails
<magicaltrout> but there's no content in the + button
<Chipaca> who was our EU-timeone snapcrafter?
<pstolowski> zyga-solus, thanks, +1
<magicaltrout> https://imagebin.ca/v/3iGoz2K7NShK
<zyga-solus> thank you :)
<magicaltrout> sad times
<Chipaca> kalikiana: ^ magicaltrout might benefit from your expertise
<magicaltrout> that worked yesterday
<magicaltrout> do i kill it and restart the push?
<Chipaca> magicaltrout: wait for kalikiana please, he'll know better than i do
<pedronis> mvo: do you have password for  snappy-stagingstore in staging ? I suppose not
<mvo> pedronis: no
<mvo> pedronis: sorry
<pedronis> mvo: that's used for the private snaps tests, we probably need to setup something shared and also transfer the snaps
 * mvo nods
<mup> PR snapd#4282 opened: tests: cache snaps to $TESTSLIB/cache <Created by zyga> <https://github.com/snapcore/snapd/pull/4282>
<zyga-solus> mvo: ^
 * zyga-solus looks for ethernet cable
<mup> PR snapd#4277 opened: osutil/user: replace our uses of os/user and filepath.Glob("/home/*") <Created by chipaca> <https://github.com/snapcore/snapd/pull/4277>
<pstolowski> mvo, hey, there is question to you from zyga-solus in 4158 comments
<mup> PR snapd#4283 opened: snap: use existing files in `snap download` if digest/size matches <Created by mvo5> <https://github.com/snapcore/snapd/pull/4283>
<mvo> pstolowski: thanks, looking
<zyga-solus> pstolowski: reviewed 4281
<zyga-solus> pstolowski: and a kind request to squash this
<zyga-solus> mvo: thank you, reviewed
<zyga-solus> mvo: can you look at 4282, it's related
<kalikiana> magicaltrout: reading the backlog...
<mborzecki> some weird things about running arch on linode
<mborzecki> the vm starts with linode kernel but when you pacman -Syu the kernel can be upgraded to the latest avaialble in the repos, i'd assume that they prepped the images somehow to avoid this
<zyga-solus> mborzecki: probably typical $cloud ops, they use custom kernels
<zyga-solus> mborzecki: same was true for ubuntu but then we changed to use grub in our image
<magicaltrout> kalikiana: i've killed the review and stuff and i'm pushing a new one because the only change i made between working and broken was remove the home plug
<zyga-solus> mborzecki: you probably need to work with niemeyer and cachio to get a better image in
<magicaltrout> but as the dashboard hung I think the automated review process got sad at some point
<mborzecki> zyga-solus: yeah, probably
<kalikiana> magicaltrout: so did the dashboard get stuck or the local command?
<mborzecki> i'm working with the default image anyway, got it to a point that it's about to start building the package
<magicaltrout> kalikiana: both
<kalikiana> oh
<magicaltrout> and then i pressed the stop review button and the cli released
<magicaltrout> and the dashboard just switched to allow a manual review
<pstolowski> mvo, zyga-solus thanks
<pedronis> mvo: zyga-solus: prereq are put in their own lane (not the default lane)
<pedronis> that's already like that in master
<zyga-solus> pedronis: I think we were worried that we don't end up with something installed while its prepreq is missing
<pedronis> zyga-solus: that's not really related, it's more that if we install core as a prereq we don't remove it , if what fails is the install of snap itself
<zyga-solus> ah, that should be good then
<pedronis> yes, there's nothing to do afaik
<mvo> pedronis: thanks for double checking
<zyga-solus> hmm
<zyga-solus> mvo: so what's up with quiet
<zyga-solus> I just added quiet and ... man things break!
<mvo> zyga-solus: a good question, in what way do things break?
<zyga-solus> mvo: my blazingly fast cache is idle, cpu is idle, network is idle
<zyga-solus> mvo: but it's running apt install cups
<zyga-solus> woah, it's running now
<zyga-solus> but it was just sitting there for a long itme
<zyga-solus> hmmm
<zyga-solus> (as in idle)
<zyga-solus> I watch htop/dstat all the time
<mvo> zyga-solus: this might be interessting https://travis-ci.org/snapcore/snapd/builds/306221204#L2268 (+ test-snapd-tools.echo Hello
<mvo> cannot bind-mount the mount namespace file /proc/7579/ns/mnt -> test-snapd-tools.mnt: Permission denied
<mvo> support process for mount namespace capture exited abnormally)
<zyga-solus> mvo: debian?
<zyga-solus> mvo: do you have denials?
<mvo> zyga-solus: yeah, debian-sid
<zyga-solus> mvo: I think we really want jjohansen to look and say
<zyga-solus> mvo: it looks like a bug
<mvo> zyga-solus: http://paste.ubuntu.com/26026737/
<mvo> zyga-solus: oh, interessting, that is the rule we aded, no?
<zyga-solus> mvo: there are rules exactly for that
<zyga-solus> right?
<zyga-solus> yes
<mvo> zyga-solus: I guess I need to check if the rule is really on disk
<zyga-solus> man, 4260 fails for like the 10th time
<mvo> zyga-solus: also interessting, only failing in upgrade-basic, so maybe
<mvo> zyga-solus: yeah, harmless "sanity check install" ;)
<mvo> zyga-solus: of course the previous install won't work on debian-sid
<zyga-solus> and more of those canot unrmarshal EOF erorrs
<zyga-solus> mvo: are machine disks recycled?
<zyga-solus> mvo: when we deploy, say, xenial, do we wipe the disk?
<zyga-solus> mvo: it looks that that run keeps happening on machine that has some junk assertions
 * ikey likes zyga advertising solus for him so he doesn't have to :p
<zyga-solus> but this makes little sense
<zyga-solus> ikey: hehe :)
<zyga-solus> hmm, the LXD test could be more cache friendly
<zyga-solus> I wonder if apt-cacher-ng can cache lxd images if we push the proxy config down
 * ikey goes and writes a hashmap
<ikey> again
<zyga-solus> ikey: waat?
<zyga-solus> ikey: in which language and why?
<ikey> C
<zyga-solus> ikey: how come there's no libikey
<ikey> there is
<zyga-solus> soo?
<ikey> https://github.com/intel/libnica
<ikey> im replacing it
<zyga-solus> oh, nice
<ikey> the original lost sight and got vendored into a buttload of projects
<ikey> but there was no ABI promise and it makes lots of naive decisions
<zyga-solus> ikey: makes sense
<ikey> f.e: NcHashmapEntry *row = &(buckets[hash % (unsigned)n_buckets]);
<ikey> vs say, &buckets[hash & n_bucket_mask]
<ikey> where n_bucket_mask = n_buckets - 1 and a power of 2
<zyga-solus> ikey: I'd love to talk about that topic one day
<zyga-solus> ikey: I'm building a pet project with similar needs
<zyga-solus> well
<zyga-solus> ish
<ikey> oh?
<ikey> btw .s comparison of the two methods: https://hastebin.com/ekomafajoj.pl
<ikey> i know which one i want :p
<ikey> divq is hella spensive
<zyga-solus> ikey: a small home grown C library for that is designed for correctness and error handling
<zyga-solus> ikey: just I want mine to build on ... heaven forbid, windows
<ikey> ooo ok
<zyga-solus> (in addition to normal environment)
<ikey> portability is good
<ikey> my new design constraint is to not be glibc specific
<zyga-solus> yeah, I'm impressed by the toolchains there
<ikey> found myself fixing up some projects that explicitly #include <linux/limits.h>
<zyga-solus> fun fact: windows implementation of virtual terminals and unix consoles of the olden days is probably the most comprehensive and accessible documentation of how it is specced to work
<ikey> wow
<zyga-solus> ikey: msdn has some fantastic things there on the console APIs and unix compatibility and VTs and such
<zyga-solus> (very recent)
<mcphail> I'm asking in genuine ignorance here - is glib deprecated for these things?
<ikey> huh ok ill need to poke around it
<ikey> mcphail, which?
<ikey> glibc or glib2?
<mcphail> glib2
<ikey> if glibc, its unportable antiunix hell
<ikey> and glib2 has an enormous arse
<ikey> you can't trust it truly for long running processes
<magicaltrout> yeah kalikiana the new push worked first time, the automated queue must have got sad on my previous attempt
<ikey> due to its internal memory management and want to leak
<mcphail> aah ok
<ikey> for clearlinux i ported clr-debug-info, a simple FUSE fs daemon that runs all the time, from glib2 to nica
<ikey> and switched from pthreads to C11 atomics
<ikey> i cut the memory usage in half and removed any leaks
<ikey> and it could be trusted to not grow over time
<ikey> another example is when you execv{p,}e a process without forking
<ikey> you're just asking to page fault the child into oblivion
<zyga-solus> IMO glib has totally broken error handling
<zyga-solus> well
<ikey> abort()
<ikey> g_assert(i dont know what im doing anymore)
<zyga-solus> ish, but not what I want to aim for
<zyga-solus> yeah
<zyga-solus> it was NULL but that's fine, let's carry on
<ikey> g_critical(but yet im still running)
<mcphail> hmm. Interesting. I've only ever played with it a bit. I just dabble in coding
<zyga-solus> I think it's a fair question
<ikey> also the vtable design of glib2 leads to far higher memory usage
<zyga-solus> part of my motivation os to re-invent the wheel in a different way (maybe dead end) and to learn in the process
<ikey> it relies on embedded structs in the malloc'd struct
<ikey> imagine now your vtable is simply a single pointer to a static vtable
<ikey> you greatly reduce the memory usage for these "objects"
<zyga-solus> mvo: one more step towards nicer prepare world needs one more review in 4284
<ikey> which is pretty much how the kernel does it (ops tables)
<ikey> also with op table redirection you can get rid of a whole slew of "if (!self)" checks
<mup> PR snapd#4284 opened: tests: merge pepare-project.sh into prepare-restore.sh <Created by zyga> <https://github.com/snapcore/snapd/pull/4284>
<ikey> (though arguably you should use the builtin likely/unlikely functions there)
<zyga-solus> and we are hit with another case of mysterious failure
<pedronis> pstolowski: zyga-solus questions on #4158 made me think that it probably needs a couple more code comments, added PR comments about this
<mup> PR #4158: snapctl: don't error out on start/stop/restart from configure hook during install or refresh <Created by stolowski> <https://github.com/snapcore/snapd/pull/4158>
<zyga-solus> pstolowski: aww, cannot create hard link in cp --link
<zyga-solus> er, that's Chipaca perhaps
<zyga-solus> I guess it's back to good old cp then
<pstolowski> pedronis, thanks, i'm in the process of adressing that
<mcphail> ikey: but, for hobby projects like the stuff I do, you wouldn't warn me off glib2 altogether? I'm a bit lazy to implement my own hash tables etc
<zyga-solus> pedronis: thank you
<ikey> for standard "do a thing and exit within some predicted timeslot" theres no real reason to avoid it
<zyga-solus> mcphail: depends on what you want:
<zyga-solus> mcphail: make hash tables or make stuff on top :)
<zyga-solus> both are fun
<ikey> if its "im a piece of plumbing" or "i run forever" then its worth considering the options
<ikey> and yeah tbh, implementing ADT is a great exercise
<zyga-solus> ikey: +1000 on plubming layer
<ikey> learning how this stuff works internally just increases understanding
<mcphail> cool. Cheers guys. Sorry for straying o/t
<zyga-solus> also one more comment
<ikey> my fault on that one, sorry :D
<zyga-solus> there's plenty of research
<ikey> yeah
<ikey> incorporate the best and distil into awesome :D
<zyga-solus> and plenty of "good old hash table that has $magic performance so let's not re-implement"
<zyga-solus> where reality is that it's junk but nobody wants to touch it
<ikey> chained buckets are typically easiest
<zyga-solus> and it was optimized on Sun Sparc V or something
 * ikey is gonna attempt a robin this time
<Chipaca> zyga-solus: why can't create hard link?
<zyga-solus> Chipaca: fedora has tmpfs on /tmp
<zyga-solus> Chipaca: I dropped --link
<zyga-solus> Chipaca: in retrospective, well, sucks
<zyga-solus> Chipaca: can 4277 be split in any way?
<zyga-solus> Chipaca: perhaps add the new functions in one PR
<zyga-solus> Chipaca: and convert things in another
<zyga-solus> Chipaca: to kill the old ones in last
<kalikiana> magicaltrout: hmmm so it was a temporary hickup I guess. But something to keep an eye on me thinks, snapcraft should never freeze like that...
<zyga-solus> Chipaca: it's just too daunting to look IMO
<mup> PR snapd#4282 closed: tests: cache snaps to $TESTSLIB/cache <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4282>
<zyga-solus> does anyone know of a commad like "time" that says "transferred so-and-so many bytes"
<Chipaca> zyga-solus: why does tmpfs on /tmp break --link? (i tested exactly that and it works here)
<Chipaca> zyga-solus: there are dd-alikes with progress bars
<zyga-solus> Chipaca: because it copies from /tmp to /var and _does not_ handle xdev
<Chipaca> 4277 can be split, probably. i'll give it a go.
<zyga-solus> Chipaca: (well, hardlinks)
<Chipaca> uh
<Chipaca> zyga-solus: my /tmp is no longer tmpfs? what
<zyga-solus> Chipaca: it is tmpfs on fedora
<zyga-solus> Chipaca: note that it didn't fail everywhere :)
<Chipaca> i thought it was tmpfs here
<zyga-solus> nope
<mborzecki> hmm go unit tests do not really need a package, but we build it anyway in prepare :/
<zyga-solus> mborzecki: in the unit suite?
<zyga-solus> whee
<mborzecki> yes
<Chipaca> zyga-solus: too many laptops; it's a tmpfs on my other one
<zyga-solus> I'm using measure-each for the 1st time now
<Chipaca> zyga-solus: ln || cp?
<zyga-solus> Chipaca: nah, it's just temporary, next patch will restore --link
<zyga-solus> Chipaca: :-)
<Chipaca> ok
<Chipaca> it's interesting that it doesn't have --link=auto
<Chipaca> Â¯\_(ã)_/Â¯
<mborzecki> zyga-solus: i'm running linode:arch-2017.07.01:tests/unit/go and it goes through prepare-project where the package is built unconditionally (?)
<zyga-solus> Chipaca: TEH BLEADING EDGE ;-)
<zyga-solus> mborzecki: yeah, that's weird / silly
<zyga-solus> mborzecki: but, so is much of our preapre code :)
<zyga-solus> mborzecki: I'll clean it up to be easier to understand what's going on
<cachio> zyga-solus, the test interfaces-network-control-tuntap still failing in the new debian-sid https://travis-ci.org/snapcore/snapd/builds/306221204#L4707
<zyga-solus> mborzecki: suite prepares are in -f
<zyga-solus> -e is ready for review now :")
<cachio> zyga-solus, not sure if it is the same error that we used to see
<zyga-solus> looking now
<zyga-solus> cachio: yes, I think so
<zyga-solus> mvo: actually, do you remember that tuntap failure? was it errno 13 or errno 1? -- the error from test cachio just linked to is errno 1 and I don't recall seeing _that_
<zyga-solus> mborzecki: can you please look at 4284
<mborzecki> looking now
<mborzecki> hmm will need to update arch integration, but that's not a big deal
<niemeyer> Hello world
<zyga-solus> o/
<niemeyer> Thanks!
<niemeyer> Thank you all!
<niemeyer> You are all great to work and interact with.
<zyga-solus> woot, you are in a good mood today :)
<niemeyer> I've heard today we're supposed to give thanks according to some conventions. Sounds like a good idea.
<kalikiana> And no turkeys have to die this way :-P I like it
<mup> PR snapd#4277 closed: osutil/user: replace our uses of os/user and filepath.Glob("/home/*") <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4277>
<ikey> **ohhh*
<ikey> its thanksgiving
 * ikey finally gets it
<zyga-solus> ah
<ikey> that took me longer than i care to admit
 * zyga-solus thanks ikey for making something fresh from distro POV
<ikey> oh, ty :D
<mborzecki> zyga-solus: i'll open an early pr with spread support for arch, so that we can better track the conflicts between this and your refactor
 * ikey thanks you lot for caring about users and doing something about it :]
<zyga-solus> ok
<zyga-solus> mborzecki: thanks, I'll try to help with conflicts
<magicaltrout> can you install a local charm to test in jail mode so I can see if the confinement makes it bomb
<mup> PR snapd#4285 opened: tests, spread: add Arch Linux to CI systems <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4285>
<magicaltrout> without bothering to push files to the store?
<zyga-solus> magicaltrout: probably --dangerous --jail
<magicaltrout> ooh bloody dangerous
<zyga-solus> magicaltrout: but I don't remember trying that
<magicaltrout> i always forget that one
<zyga-solus> mborzecki: general comment, I think we want separate snapd package for eventual inclusion into arch (again)
<zyga-solus> mborzecki: or perhaps aupdate
<zyga-solus> mborzecki: and that would resolve some of the complexity and the TODO in build_pkg
<zyga-solus> mborzecki: reviewed
<mborzecki> zyga-solus: thanks
<zyga-solus> mborzecki: and please rebase/merge
<zyga-solus> mborzecki: (sorr for the conflict there)
<mup> PR snapd#4284 closed: tests: merge pepare-project.sh into prepare-restore.sh <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4284>
<mborzecki> np
<zyga-solus> pstolowski: approved 4158 though I think mvo wanted to move part out to a different PR
<pstolowski> zyga-solus, yes, I know and responded (will move to separate PR)
 * pstolowski lunch
<zyga-solus> pstolowski: thanks, perfect
<zyga-solus> mvo: the change to apparmor backend you made in 4265 is important enough to be pulled out and proposed/merged faster, would you mind if I do that?
<zyga-solus> I used ~20GB of bandwidth on tests today
<zyga-solus> (cached)
<zyga-solus> I actually get to use CPUs now, not just wait for IO
<mvo> zyga-solus: I was thinking the same, have a pr open but did not press the ok button :)
<zyga-solus> mvo: thanks! please do
<mup> PR snapd#4286 opened: apparmor: generate the snap-confine re-exec profile for AppArmor{Partial,Full} <Created by mvo5> <https://github.com/snapcore/snapd/pull/4286>
<mup> PR snapd#4283 closed: snap: use existing files in `snap download` if digest/size matches <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4283>
<mborzecki> is there a way to poke spread so that it'll kill remote command and clean up?
<zyga-solus> mborzecki: ctrl-c
<zyga-solus> mborzecki: other than that kill it and then discard the machines with -discard
<mborzecki> yay, -discard does magic
<mborzecki> thanks
<zyga-solus> oh
<zyga-solus> standup time
<zyga-ubuntu> jamesh: thanks for the spread test~!
<jamesh> zyga-ubuntu: it's a bit of a pain writing those tests: a successful run of a single test seems to take about 10 minutes, even with it reusing the VM
<zyga-ubuntu> jamesh: I've pushed a few useful caching patches, I recommend using SPREAD_HTTP_PROXY=... (your local apt-cacher-ng) and with one more PR you should be able to cache most of the snaps so that tests are not bandwidth heavy
 * jamesh is still waiting for the NBN to roll out in his suburb
<zyga-ubuntu> sorry guys my desktop froze again :/
<zyga-ubuntu> rebooted hard way and will be back soon
<kalikiana> zyga-ubuntu: graphics drivers?
<mup> PR snapd#4280 closed: tests: remove obsolete workaround <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4280>
<zyga-ubuntu> kalikiana: maybe
<mup> Issue snapcraft#1661 closed: Walk the prime directory for elf files (in lifecycle) <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1661>
<mup> PR snapd#4286 closed: apparmor: generate the snap-confine re-exec profile for AppArmor{Partial,Full} <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4286>
<zyga-ubuntu> jdstrand: hey, thank you for your feedback so far; I'm back to working on this so expect some more PRs
<zyga-ubuntu> jdstrand: but I write for another issue actually, do you think you can look at 4100, it's close to landing but has unanswered questions
<mborzecki> "Using GOPATH as if it were a single entry and not a list:"  <--- does this check in run-checks --static fail for anyone?
<pedronis> mvo: this is the bug: https://bugs.launchpad.net/snapd/+bug/1733910
<mup> Bug #1733910: snapd should track what user installed what, and use the appropriate macaroon in auto-refresh <snapd:Confirmed> <https://launchpad.net/bugs/1733910>
<mborzecki> you actually have to have shellcheck installed to even hit that branch in run-checks
<Chipaca> we still don't have shellcheck on the spread images? :-(
<pedronis> we don't
<Chipaca> niemeyer: i thought you were going to install it?
<niemeyer> Chipaca: Hm?
<mborzecki> hmm i've installed it on arch and hit this
<mup> PR snapd#4287 opened: tests/lib: fix shellcheck errors <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4287>
<mborzecki> trivial review ^^
<zyga-ubuntu> done
<mborzecki> zyga-ubuntu: thanks
<zyga-ubuntu> I wonder why 4260 fails consistently
<zyga-ubuntu> it seems like this is not a fluke
<zyga-ubuntu> but actual consequence of the changes
<cybrNaut> i think i found a snap pack that will not install on Debian -- which, if I understand corretly, defeats the purpose of snapcraft
<sergiusens> popey elopio from the conversation yesterday, I am already on codein and accepted everything. I just had the impression there was grouping for shared tasks or is it to each their own?
<cybrNaut> aren't "snap" packages supposed to be something that "just works"?
<sergiusens> cybrNaut which package? it might be that it doesn't work anywhere
<cybrNaut> i go to https://anbox.io/, and find a snap pack that has an embedded dependancy on PPAs
<cybrNaut> PPAs are Ubuntu-specific
<cybrNaut> i also found this thread, which seems to confirm that it won't work on debian https://discourse.anbox.io/t/anbox-modules-dkms-port-for-debian/33/6
<cybrNaut> even though "snapd" is offically available on debian
<ogra_> cybrNaut, anbox-installer is definitely 100% ubuntu specific (using dkms to build modules etc)
<ogra_> cybrNaut, rge anbox snap itself is generic though ...
<ogra_> *the anbox
<cybrNaut> ogra_: your phrasing kind of made it clear.. i'm not installing anbox... i'm installing an installer
<ogra_> right
<cybrNaut> so i suppose there would be no problem using the snap to install an installer.. but then the installer is useless
<ogra_> and the installed uses PPAs etc ... and in the end installs the anbox snap
<mborzecki> zyga-ubuntu: hm fails on snap ack <..whatever>
<sergiusens> you can talk to the upstream for anbox, but they went classic, which means the snap part of it is relegated to just a payload and up to the upstream to support it well everywhere
<ogra_> once it did set up the modules as needed etc
<ogra_> sergiusens, anbox isnt classic, only the installer IIRC
<sergiusens> right, or the case of an "installter"
<sergiusens> which essentially makes it classic
<ogra_> cybrNaut, there should be instructions somewhere to do all the setup in debian i think
<ogra_> sadly morphis is not around atm
<ogra_> he is the one who could point you to the instructions (if theer are any)
<mborzecki> zyga-ubuntu: aiui 'Nov 23 10:16:29 li563-82 snapd[28522]: 2017/11/23 10:16:29.793688 daemon.go:233: DEBUG: pid=28517;uid=0;@ POST /v2/assertions 8.452359ms 200' the post requests end with 200 OK unless marshalling at snapd or unmarshalling at snap is broken
<cybrNaut> ogra_: i suspect it'll involve cloning the github project and building that
<ogra_> cybrNaut, not sure ... you will need the dkms modules, so i guess using the deb source package from the PPA and such are involved
<cybrNaut> ogra_: i see a manual install process here https://github.com/anbox/anbox which looks reasonable
<cybrNaut> thanks for the help.  i'll try the manual process since i'd rather not mess with PPAs
<zyga-ubuntu> pstolowski: commented on 4108
<zyga-ubuntu> 4281 is green and needs a 2nd review
<zyga-ubuntu> niemeyer: perhaps ^
<pstolowski> zyga-ubuntu, thanks!
<ogra_> morphis, meet cybrNaut ... he is trying to get anbox to run on debian ... do wer have any HOWTO (regarding the dkms modules on debian etc) ?
<pedronis> mborzecki: something is definitely off with that branch, but unclear what
<Chipaca> bloodearnest: regarding https://forum.snapcraft.io/t/should-snapctl-set-in-apps-trigger-the-configure-hook/2032 i think that's a question for gustavo or pstolowski
<Chipaca> bloodearnest: i haven't much to say wrt snapctl
<mup> PR snapd#4288 opened: Adding "set -e" to test lib scripts <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4288>
<mup> PR snapd#4288 closed: Adding "set -e" to test lib scripts <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4288>
<pedronis> mborzecki: it would seem something there broke client parsing of server responses
<pstolowski> Chipaca, yes, I've been invited to this topic today already, just didn't get to respond yet
<niemeyer> zyga-ubuntu, pstolowski: Looking
<niemeyer> Chipaca, pstolowski: Responded there
<cybrNaut> looks like the manual process would fail, as aptitude on debian says => Couldn't find any package whose name or description matched "libdbus-cpp-dev"
<pstolowski> thanks niemeyer
<Saviq> popey: this something you guys aware of? https://imgur.com/a/QiDAY
<popey> Saviq: depends, where'd you get that?
<cachio> niemeyer, do you know which are the base packages that you installed in the ubuntu images on linode?
<cachio> those needed to make spread run the snapd suite
<niemeyer> cachio: Figuring out which packages are necessary for the suite and isolating them in a reusable way was literally the work you did
<niemeyer> cachio: The images weren't changed much other than making sure they would boot
<cachio> niemeyer, ok
<niemeyer> cachio: and *removing* stuff to make them lighter
<zyga-ubuntu> the measurement stuff I did can also detect that and keep it up to date
<cachio> niemeyer, do you  have the list of images available on linode?
<niemeyer> cachio: Our images or their images?
<cachio> niemeyer, their
<niemeyer> pstolowski: Reviewed
<mup> PR snapd#4287 closed: tests/lib: fix shellcheck errors <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4287>
<niemeyer> cachio: You can use the API for a complete list.. this is the interesting stuff: https://www.linode.com/distributions
<cachio> niemeyer,  tx
<niemeyer> cachio: np
<zyga-ubuntu> mborzecki: 4285 fails now
<mborzecki> zyga-ubuntu: i know, it's the -Syu thing
<mborzecki> zyga-ubuntu: more details here if you're interested: https://forum.snapcraft.io/t/integrate-arch-linux-into-ci-pipeline/2904/3
<zyga-ubuntu> thanks, looking
<mborzecki> i think i'll just make all the installation commands -Syu for now
<mborzecki> then we can reiterate and maybe use some custom images that are rebuilt daily or sth
 * zyga-solus managed to get to 5/196 without failures now, nice :)
<zyga-solus> 8/196, another run
<pstolowski> niemeyer, thanks, updated
<mborzecki> zyga-solus: pushed 2 more patches, let's see how far it gets this time
<pstolowski> niemeyer, btw, can you cast your eye on #4259 again too?
<mup> PR #4259: snapd: fix handling of undo in the taskrunner <Created by stolowski> <https://github.com/snapcore/snapd/pull/4259>
<pedronis> pstolowski: we need that code for normalizing int and float afaiu
<pedronis> or we need ot change the rules
<niemeyer> Yeah, the original suggestion was to move it into SetAttr time
<niemeyer> pedronis: Would that not work?
<pstolowski> pedronis, because interfaces themselves can set values
<elopio> damn, I lost a " in travis. Sooo close.
<pedronis> pstolowski: and because JSON pcakage has slightly different rules
<pedronis> itself
<pstolowski> pedronis, okay, i'll make a separate normalize() helper for this
<mborzecki> niemeyer, and if you still feel fresh enough for reviews, would you mind taking a look at #4269?
<mup> PR #4269: timeutil: new refresh timer parser <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4269>
<niemeyer> Sure thing
<mborzecki> thanks
<pedronis> niemeyer: well right now pstolowski just removed it (if I read correctly), IÂ don't care too much about the details
<pedronis> but we need it and it needs to be recursive afaict
<Faults> I have a quick question. Why most Snaps looks ugly... like Windows NT 4.0. I suppose Snaps not support theming from OS?
<niemeyer> pedronis: My original point is that we don't want that on copying
<niemeyer> pedronis: Does that make sense?
<pedronis> niemeyer: yes, but the code will be similar (a kind of copy)
<pedronis> I suppose we need normalize and copyAttributes
<niemeyer> Faults: There's on going work to make snaps automatically use a theme that matches the system
<niemeyer> Faults: Some details here https://forum.snapcraft.io/t/use-the-system-gtk-theme/496/27?u=jamesh
<niemeyer> Faults: They look ugly in some cases because that's not finished yet
<Faults> Oh lovely! Thanks from quick reply niemeyer :)
<niemeyer> My pleasure
<Faults> Idea of Snap (and flatpak) is pure gold!
<niemeyer> pedronis, pstolowski: Right, we do want the types to be strict. My point is that this was being done incorrectly.. we don't want to be strict when reading values. We want to be strict when changing them.
<pstolowski> niemeyer, ok, so i wasn't doing that on reading anymore. the copyRecursive method was left intact, but it was instead used when NewConnectedSlot/Plug was constructed - just once
<pstolowski> niemeyer, and yes, it was copy+normalize in one method
<niemeyer> pstolowski: Still bogus.. the static values you get from the snap are guaranteed to be correct because the reading logic fixed them
<niemeyer> pstolowski: It's the modifications thereafter that need to be accounted for
<pstolowski> niemeyer, ok, i get this, i'm adding a separate normalize method just for setting dynamic attributes. copy will be made for static ones
<niemeyer> pstolowski: Brilliant, thanks!
<pstolowski> and copy will assume correct types are used already, no normalization
 * zyga-solus got up to 9/196
<zyga-solus> (and had dinner)
 * kalikiana configured mypy in syntastic, not super fast but very comfortable to work with
<mup> PR snapd#4289 opened: snapstate: move autorefresh code into autoRefresh helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/4289>
<zyga-ubuntu> mvo: can that not be based on 4161?
<zyga-ubuntu> mvo: it's a bit hard to see what's new
<pedronis> I would have expected the changes in the reverse order, first refactor, then new feature
<pedronis> with this  we need to land #4161
<mup> PR #4161: snapstate: add support for refresh.schedule=managed <Created by mvo5> <https://github.com/snapcore/snapd/pull/4161>
<pedronis> first
<zyga-solus> yes, I agree
<cachio> niemeyer, spread 46 ready again
<niemeyer> cachio: There we go
<cachio> I removed a set of packages
<mvo> pedronis, zyga-ubuntu ups, sorry, happy to revert the order again
<mup> PR core#58 closed: use `snapctl internal configure-core` to configure core <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core/pull/58>
<mup> PR snapd#4289 closed: snapstate: move autorefresh code into autoRefresh helper <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4289>
 * kalikiana wrapping up for the day
<pedronis> mvo: thanks, unless you think the refactoring will be very controversial, in which case the other order could also work
<niemeyer> cachio: 1.3G \o/
<mup> PR snapd#4290 opened: snapstate: move autorefresh code into autoRefresh helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/4290>
<mvo> pedronis: yw, I think your suggestion is the right onw, new PR up, let me know if I should split even further (one PR that just moves stuff, one that adds baby-step feature)
<pedronis> mvo: I think it should be fine, it doesn't look super big
<cachio> niemeyer, :)
<cachio> niemeyer, let's see if that works properly now
<niemeyer> cachio: Ok, should I bake it?
<cachio> yes
<cachio> niemeyer, ~
<niemeyer> cachio: on it
<zyga-ubuntu> mvo: +1 on 4290
<mvo> zyga-ubuntu: thanks, just fixed one tiny issue (force push to keep history cleanish)
<zyga-solus> oh, what was it?
<mvo> zyga-solus: forgot to add the snapManager.LastRefresh() accessors
<mvo> zyga-solus: unit tests failed, so obvious
<mvo> zyga-solus: actually a merge artifact but anyway, tiny and obvious
<zyga-solus> mvo: can you please have a quick look at 4227
<zyga-solus> mvo: it's green and has one review
<mvo> sure
<mup> PR snapd#4227 closed: tests: add test for frame buffer interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4227>
<zyga-solus> great, back on 25 :D
<zyga-solus> cachio: do you have the patch that is missing in 426?
<zyga-solus> 4265
<cachio> zyga-solus, I am working on the tests that fail sporadically related to gpg
<cachio> I'll try to push today
<zyga-solus> cachio: is this for that particular PR?
<cachio> zyga-solus, yes
<cachio> it is failing on debian-9
<cachio> zyga-solus, in the last execution failed https://travis-ci.org/snapcore/snapd/builds/306221204#L3888
<om26er> How much time before snapcraft 2.35 moves from xenial-proposed to -updates ?
<cachio> zyga-solus, debuging I saw that gpg was failing to create/delete keys
<cachio> it was trying to create some dirs in /root/....
 * om26er knows it was accepted to -proposed only an hour ago.
<cachio> zyga-solus, I am running the full suite
<cachio> zyga-solus, it can not be reproduced if you just run this test
<zyga-solus> cachio: what is the error that you saw?
<zyga-solus> cachio: typically gpg breaks on lack of entropy
<cachio> zyga-solus, the entropy was ok
<cachio> like 2500
<zyga-solus> cachio: debian may use differnt source of randomness from other distros (perhaps)
<zyga-solus> cachio: aha
<cachio> zyga-solus, I can share the vm once it failes
<cachio> fails
<zyga-solus> cachio: I'd like to see the error message
<zyga-solus> cachio: I'll probably break soon, my back is giving me signals it's enough for today
<cachio> zyga-solus, np, I'll leave more info in the PR
<niemeyer> cachio: fedora-26-64 is ready
<cachio> niemeyer, great, testing it
<Son_Goku> cachio, is fedora-27-64 and fedora-rawhide-64 synced up to the latest?
<zyga-solus> pedronis: can you please look at http://paste.ubuntu.com/26029227
<Son_Goku> aka "dnf --refresh distro-sync"?
<zyga-solus> pedronis: is that a sane assertion (syntax wise)
<cachio> Son_Goku, no yet
<Son_Goku> ok
<zyga-solus> pedronis: this is what we fail on that EOF bug
<cachio> Son_Goku, I'll do that after 26
<Son_Goku> cool
<pedronis> zyga-solus: it looks like one, I don't the problem is assertion
<pedronis> zyga-solus: my guess would be the change in response,  but I'm not sure why it would trigger problems
<pedronis> zyga-solus: easiest would be to get the branch, try one of the failing tests, try to undo that change, see if it changes something, then figure out what's happening
<zyga-solus> pedronis: right, I'm looking at the diff again but nothing stands out
<zyga-solus> pedronis: the only new thing is Tracks
<zyga-solus> pedronis: it didn't have any annotation before
<pedronis> but that struct is not involved with ack at all
<pedronis> as I said afaict the only logical candidate
<zyga-solus> hmm
<pedronis> is the change in response.go
<pedronis> it would be good to verify that theory
<zyga-solus> pedronis: sure, that's easy
<zyga-solus> thank you
<zyga-solus> pedronis: so, it's not that
<zyga-solus> pedronis: rebuilt snap, snapd, reinstalled, restarted snapd
<pedronis> zyga-solus: actually I'm quite sure it is
<zyga-solus> pedronis: ok, let me re-check
<pedronis> I mean IÂ see the now the code
<pedronis> why that would matter
<pedronis> we do things like this in client:   err := jsonutil.DecodeWithNumber(bytes.NewReader(rsp.Result), v)
<pedronis> json.Unmarshal(rsp.Result, &resultErr)
<zyga-solus> ok
<mup> PR snapd#4291 opened: osutil/sys: reimplement getuid and chown with the right int type <Created by chipaca> <https://github.com/snapcore/snapd/pull/4291>
<zyga-solus> I definitely removed that change
<pedronis> and this is the field in the client:          Result     json.RawMessage `json:"result"`
<zyga-solus> and rebuilt
 * zyga-solus wonders
<pedronis> so if the field is not there (instead of null), I suspect those to break with EOF
<Chipaca> zyga-solus: 4291 is the syscall bits alone
<zyga-solus> and restarted
<zyga-solus> Chipaca: woot, thank you!
<zyga-solus> pedronis: could it be a combination, I'm sure I removed this aspect of the patch
<zyga-solus> pedronis: and new snapd is runing
<zyga-solus> *running
<zyga-solus> ah
<zyga-solus> sorry, obviously
<zyga-solus> reexec
<pedronis> heh
<zyga-solus> thank you
<zyga-solus> :)
<pedronis> now we need to decide whether we want to fix client or we consider this an incompatible change
<pedronis> maybe Chipaca or niemeyer have opinions on that
<zyga-solus> yes, confirmed
<zyga-solus> funny outcome
<pedronis> with how client is written we cannot omit result
<pedronis> atm
<niemeyer> I'm out of context.. can someone summarize?
<pedronis> niemeyer:    is this change:  https://github.com/snapcore/snapd/pull/4260/files#diff-e1016939c627280d9f6c53bdab0530bf
<mup> PR #4260: Stop various JSON field from being sent with null values <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/4260>
<zyga-solus> niemeyer: 4260 introduced a change that broke tests, it added "omitempty" to daemon response
<zyga-solus> niemeyer: this broke client that assumes there's something there
<pedronis> even if just "null"
<niemeyer> zyga-solus: What's the field?
<zyga-solus> https://github.com/snapcore/snapd/pull/4260#discussion-diff-152852846R82
<zyga-solus> "result"
<pedronis> in respJSON
<pedronis> our response wrapper type
<niemeyer> I can see the argument both ways..
<niemeyer> It's pretty silly for us to be sending null when it's not present
<niemeyer> It also seems somewhat silly to change that at this point
<zyga-solus> shall I undo that aspect?
<zyga-solus> I have it checked out
<zyga-solus> (then the rest can presumably land)
<niemeyer> zyga-solus: Yeah, I don't really see much of a benefit on the change, other than being more aesthetically pleasing
<mup> PR snapcraft#1756 opened: tests: add the missing quote on autopkgtest run <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1756>
<zyga-solus> I'll push this with a small test
<cachio> niemeyer, could you please start the spread-46 again, I need to install a pckg
<cachio> a dependency seems to be missing, I see this error "fw_printenv: command not found"
<niemeyer> cachio: Done.. up in a few
<cachio> niemeyer, tx
<Chipaca> pedronis: what's the context?
<Chipaca> (way too much backlog)
<Chipaca> pedronis: ah! just saw you tell gustavo :-)
<Chipaca> reading
<zyga-solus> pushed, it should pass now
<cachio> niemeyer, done
<cachio> niemeyer, it was failing to prepare the suite
<zyga-solus> Chipaca: much shorter and nice to review
<zyga-solus> Chipaca: just thinking aloud
<zyga-solus> Chipaca: let's introduce uid_t, gid_t
<zyga-solus> instead of everyone and their $pet remembering to use uint32
<Chipaca> zyga-solus: well... uid_t is the reason we have this mess in the first place
<Chipaca> it's way too obscure what exact integer type a given _t is
<Chipaca> so, not a fan here, today
<zyga-solus> Chipaca: but that's in C where nothing checks
<zyga-solus> Chipaca: in go we'd, at least, get checks
<Chipaca> (granted all it would've taken is compiling a little C program on all the architectures they were interested in, but still)
<Chipaca> (also they get it right in the stat_t struct :-)
<Chipaca> zyga-solus: what would you call the type?
<zyga-solus> Chipaca: UserID, GroupID perhaps
<zyga-solus> mouthful but to the point
<Chipaca> that's a type name?
<Chipaca> zyga-solus: tempted to say call it ID, as in user.ID
<zyga-solus> Chipaca: and Group.ID
<Chipaca> zyga-solus: yep
<zyga-solus> Chipaca: and have a cho.Own() calls? :D
<Chipaca> zyga-solus: no
<Chipaca> zyga-solus: clearly it'd be ch.Own()
<pedronis> heh
<Chipaca> zyga-solus: and ch.Sh()! it's perfect
<Chipaca> i mean, seriously user.UserID is nasty
<zyga-solus> Chipaca: unix.UserID ?
<zyga-solus> Chipaca: ^_^
<zyga-solus> \\o
<zyga-solus> o//
<zyga-solus> \o/
<Chipaca> could be
<Chipaca> although that does clash with the new syscall
<Chipaca> but not bothered about that tbh
<zyga-solus> send partial review
<zyga-solus> so again, to ensure everyone knows, I'm off tomorrow
<zyga-solus> gotta go and see what's outside the thing called door
<pedronis> I never noticed that go uses marker methods sometimes
<Chipaca> zyga-solus: chaos and anarchi
<zyga-solus> pedronis: marker methods?
<pedronis> os.Signal.Signal
<pedronis> is what I noticed
<zyga-solus> interesting
<cachio> zyga-solus, https://paste.ubuntu.com/26029507/
<Chipaca> eep
<Chipaca> just noticed "Tracks" in the json output
<Chipaca> when/how did that happen
<cachio> zyga-solus, if you need access just ask
<zyga-solus> Chipaca: that's a new thing
<zyga-solus> Chipaca: it's in that PR
<zyga-solus> cachio: interesting
<zyga-solus> cachio: perhaps something we can find in the source code of gpg
<zyga-solus> but a long shot
<zyga-solus> not sure what's wrong
<mup> PR snapcraft#1757 opened: Saving snap-build assertion as '.build' <Created by cprov> <https://github.com/snapcore/snapcraft/pull/1757>
<pedronis> zyga-solus: cachio: it might be gpg2 vs gpg1  (in principle we support both but afaik we test mostly gpg1)
<cachio> zyga-solus, not sure
<zyga-solus> mvo: hey
<cachio> pedronis, zyga-solus using gpg I can create keys
<zyga-solus> mvo: if around 4290 has some comments from pedronis but is good to merge otherwise
<zyga-solus> cachio: which version is in sid?
<mvo> zyga-solus: checking
<zyga-solus> thanks!
<cachio> zyga-solus, 2.1.18
<cachio> sorry
<cachio> this is not sid
<cachio> this si debian-9
<cachio> it is working properly on sid
<pedronis> so unstable works, but current version doesn't ?
<cachio> pedronis, yes
<pedronis> (that sounds interesting, I would have expected neither or the reverse)
<pedronis> I wonder what's different
<pedronis> cachio: what gpg version to they have each ?
<pedronis> s/to/do/
<cachio> checking on sid
<cachio> pedronis, it will take few minutes
<mup> PR snapcraft#1758 opened: tests: move the ppa test trigger to lxd <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1758>
<cachio> niemeyer, any news about the fedora-26?
<niemeyer> cachio: It's back at 1.6G :)
<cachio> niemeyer, I just install 450KB
<cachio> heeeh
<niemeyer> cachio: Clearly there's quite a bit more that is happening on the image every time we boot
<niemeyer> cachio: No matter how terrible the algorithm of resize2fs is, it's probably deterministic
<niemeyer> cachio: If we figure what that thing is, we can learn to disable it, or at least clean it back up
<cachio> niemeyer, I could disable the timer
<cachio> service
<cachio> niemeyer, I'll take a look and research a bit more
<niemeyer> cachio: Thanks
<cachio> is it up?
<niemeyer> Yeah
<niemeyer> No, sorry
<niemeyer> Booting it back up now
<cachio> pedronis, gpg (GnuPG) 2.2.2
<cachio> on sid
<cachio> it is almost the same
<mup> PR snapd#4292 opened: snapstate: store userID in snapstate <Created by mvo5> <https://github.com/snapcore/snapd/pull/4292>
<mup> PR snapd#4170 closed: cmd/snap-update-ns: add planWritableMimic <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4170>
<cachio> niemeyer, please try again with the 46
<cachio> I disabled the service which triggers the automatic updates
<niemeyer> cachio: Image is ready
<cachio> size?
<cachio> niemeyer, it was beter?
<sergiusens> elopio 2.35 is in -proposed
<cachio> better
<elopio> sergiusens do you want me to test it instead of fixing my 2 bugs tomorrow?
<sergiusens> elopio I am more interested in you fixing the error stuff first, then the SRU testing and last the bugs
<elopio> Ack
<mup> PR snapcraft#1754 closed: nodejs plugin: pass proxy configuration to yarn <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1754>
<mup> PR snapcraft#1756 closed: tests: add the missing quote on autopkgtest run <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1756>
<niemeyer> cachio: Yeah, back to 1.3
<cachio> niemeyer, nice
<mup> PR snapd#4158 closed: snapctl: don't error out on start/stop/restart from configure hook during install or refresh <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4158>
<sergiusens> elopio mind reviewing snapcraft#1759 before you EOD?
<mup> PR snapcraft#1759: many: ensure classic confined binaries use the correct interpreter <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1759>
<mup> PR snapcraft#1759 opened: many: ensure classic confined binaries use the correct interpreter <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1759>
<cachio> niemeyer, sadly I'll need the spred 46
<cachio> I found the problem in the setup
<cachio> is it missing a grub pkg
<niemeyer> cachio: I can't fire it right now, but you can reuse the image and fire a new machine
<cachio> ok
<mup> PR snapd#4260 closed: Stop various JSON field from being sent with null values <Created by robert-ancell> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4260>
<niemeyer> cachio: Alternatively, you can generally also start the machine via the API, but this one time I realized the root by mistake, so it needs to be expanded back to 10G first
<mup> Bug #1734213 opened: Python scripts named pip* filtered out of snaps <Snappy:New> <https://launchpad.net/bugs/1734213>
<niemeyer> resized the root
<robert_ancell> zyga-ubuntu: thanks!
<zyga-ubuntu> :-)
<zyga-ubuntu> my pleasure
<cachio> niemeyer, Spread-50 is the vm
<cachio> I fixed the problems and it is ready to run snapd tests
<cachio> niemeyer, coudl you please remove it from the pool?
#snappy 2017-11-24
<mup> PR snapcraft#1760 opened: tests: move the catkin integration tests to a separate suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1760>
<mborzecki> good morning
<mborzecki> it's not possible to REBOOT in prepare in spread?
<zyga-ubuntu> good morning
<mborzecki> zyga-ubuntu: hey
<zyga-ubuntu> I'm not working today, just doing some tax follow up
<zyga-ubuntu> REBOOT is defined in spread as a bit of shell, I haven't tried it in prepare
<mborzecki> i'm trying to upgrade arch in prepare && REBOOT, but got REBOOT: command not found instead
<zyga-ubuntu> mborzecki: then it probably isnt
<zyga-ubuntu> look at spread source code, it probably does something in sync with the host
<mborzecki> zyga-ubuntu: thanks
<mborzecki> omg i know, it's the refactor :) sorry zyga-ubuntu
<kalikiana> o/
<zyga-ubuntu> mvo: do you know what might make snapd-notify and the classic-ubuntu-core-transition both fail
<zyga-ubuntu> mvo: on my system snapd-notify fails reliably
<niemeyer> Morning all
<mvo> hey zyga-ubuntu
<mvo> zyga-ubuntu: I'm not sure why this fails, can you pastebin the error
<mvo> hey niemeyer ! good morning
<pstolowski> morning!
<mup> PR snapd#4290 closed: snapstate: move autorefresh code into autoRefresh helper <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4290>
<niemeyer> Yos
<niemeyer> I could swear it was Thursday.. I lost a day this week
<zyga> mvo: http://pastebin.ubuntu.com/26032995/
<mborzecki> niemeyer: morning
<mborzecki> you're up early
<mvo> zyga: hm, strange. can you get into a debug shell?
<zyga-ubuntu> I'm in one
<mvo> zyga-ubuntu: xcould you please pastebin "journalctl -u snapd"
<mvo> zyga-ubuntu: is this a regular ubuntu system?
<zyga-ubuntu> mvo: yes, 16.04
<zyga-ubuntu> mvo: the pastebin above has the entire journal, there's nothing more
<mvo> zyga-ubuntu: aha, no SNAPD_DEBUG=1 maybe?
<zyga-ubuntu> no, but I can add that and re-run
<mvo> zyga-ubuntu: that is the culprit, the message is only printed on debug
<mvo> zyga-ubuntu: probably the smae for the other test
<zyga-ubuntu> hmm, how to inject snapd debug
<mborzecki> /etc/environment ?
<mborzecki> or whatever you use in ubuntu
<zyga-ubuntu> right but in this test we just look at syslog
<zyga-ubuntu> and I don't want to inject it everywhere
 * ikey just kills snapd and manually invokes it these days
<ikey>  sudo SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=3 SNAP_CONFINE_DEBUG=1 /usr/lib64/snapd/snapd   does the job for me
<mvo> zyga-ubuntu: you could add a file to /etc/systemd/system/snapd.service.d/debug.conf or something
<mvo> zyga-ubuntu: just for this test, the restart. but why do you not want global debug enabled? its often very useful when inspecting why tests fail, no?
<Guest13703> hello all will my dell edge gateway support any sim
 * ikey blinks
<zyga-ubuntu> yeah, actualy
<mborzecki> zyga-ubuntu: btw. weren't you supposed to be taking a day off today? :)
<zyga-ubuntu> yes, just waiting for the traffic to go away :)
<zyga-ubuntu> I was eating breakfast and doing some taxes
<ikey> man knows how to start the day
<ikey> xD
<zyga-ubuntu> but you know, that debug machine is so tempting
 * mvo hugs zyga-ubuntu
<mvo>  /nick zyga-ubuntu -> zyga-debugger
 * ikey gets back to staring at prime numbers with contempt
<mup> PR snapd#4252 closed: store: fix download caching and add integration test <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4252>
<mborzecki> uhh i have a feeling that linode boots arch images with their kernel regarless of what's int the image
<mup> PR snapd#4259 closed: snapd: fix handling of undo in the taskrunner <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4259>
<mvo> hey pedronis, good morning. I'm just looking at 4292 and wonder if you think the right behavior is that the UserID is whoever installed it (and we keep it to that user) or whoever "touched it last"?
<pedronis> mvo: the latter has a better chance of making sure we are using workin creds, the former feels nice
<pedronis> another approach is to use for refresh the creds of the installer, not the refresher, which then would make no difference
<mvo> pedronis: yeah, I currently went with the former but I'm sitting on the fence
<pedronis> IÂ mean doing that even if the refresh is manual
<mvo> pedronis: oh, interessting
<pedronis> we would still take the refresher though if UserID is currently 0
<mvo> right
<mvo> pedronis: I think that sounds good, so it would be a) keep userID of installer b) on refresh, take userID from snapstate (regardless of who refreshes)?
<pedronis> yes, except if UserID is currently 0
<pedronis> so that we have a way out of the current situation
<mvo> pedronis: indeed, I like that
<pedronis> in practice for a system with one user it should create too many confusing situations
<pedronis> *it shouldn't
<mvo> pedronis: :)
<mvo> pedronis: yeah, I will go with this, I update the PR with the snapstate recording and then will look into configure task handlign first, then into auto-refresh with auth
<mvo> pedronis: thanks (as always) for your input!
<pedronis> np
<pedronis> mvo: btw given  that we are working in this area, it might make sense to capture somehow that a snap is paid (like we capture it's private atm)
<zyga-ubuntu> mvo: so, I actuall _had_ SNAPD_DEBUG=1 set, that's what local.conf does
<zyga-ubuntu> mvo: yet the logs are exactly the same as before
<zyga-ubuntu> anyway, that's for next week
<zyga-ubuntu> ttyl
<Guest13703> hi can i use any sim module in ubuntu
<Guest13703> And where can i get the settings
<Guest13703> I am trying to install it on dell edge gateway
<mborzecki> mvo: are we particularly tied to calling adduser in osutil/user.go?
<mvo> mborzecki: I think not, what do you need to use for arch?
<mborzecki> useradd ..
<mvo> ok
<ikey> think i broke snap
<mvo> mborzecki: i think thats fine, however please note that the user adding stuff is mostly for core systems
<mvo> mborzecki: which are ubuntu currently so it should not be urgent to change this (or do you have a different use case?)
<mborzecki> mvo: great point, i'll disable the test then :)
<ikey> https://hastebin.com/xibuyorobu.pl <- even after unsetting them all as reviewable i cant make the newest one reviewable..
<ikey> on the plus side my snapcraft segfault is gone
<ikey> `Ready to release!
<ikey> Revision 7 of 'linux-steam-integration' created.
<ikey> `
<mborzecki> mvo: btw. the unit tests are only ran on debian and ubuntu, is this intentional?
<mvo> ikey: autsch, sorry for that, that probably needs jdstrand but he is iirc not around today
<ikey> yeah no worries
<mvo> mborzecki: not intentional, I vaguely remember I enabled them everywhere at some point :/
<ikey> just managed to make the dashboard fart so i thought id headsup y'all
<mvo> ikey: maybe the store people can help
<ikey> ta
<ikey> hm, found some missing libs with abireport
<ikey> *fixes*
<ikey> niemeyer, this is what i meant about the abireport stuff btw, highlighted missing libraries from the root: https://github.com/solus-project/runtime-snaps/blob/master/abi/abi_used_libs
 * ikey is fixing ^^
<ikey> and the abi_symbols file is 5.23MB :p
<mvo> ikey: hm, I don't see anything in the review queue, so it does look like somehting in the store is wonky, nessita can probably help with your https://hastebin.com/xibuyorobu.pl store issue, but she is in a .ar timezone
<ikey> ok - gonna get another image uploaded first before i chase it further tbh
<ikey> stabilise the ABI
<niemeyer> ikey: Nice, that's exactly what we need I think
<niemeyer> ikey: For the base-reviewing tasks
<ikey> yeah
<niemeyer> ikey: Probably also binaries that were removed, for similar reasons
<ikey> warning 5MB: https://github.com/solus-project/runtime-snaps/blob/master/abi/abi_symbols
<ikey> yeah ive just done the same, and ripped some systemd binaries out of the rootfs
<ikey> it doesnt do c++filt mutations - they wouldn't let you know that ABI changed
<ikey> just API really
<ikey> besides nobody really cares *what* the symbols are as such, just that "oh crap I lost 4000 symbols on this change"
<niemeyer> ikey: Right, spot on
<ikey> fwiw we do this at the packaging level too, its great for an early warning that somethings amiss or pain is due ^^
<jamesh> ikey: if you want more certainty about ABI changes, check out Abigail: https://sourceware.org/libabigail/
<ikey> seen it, overkill :D
<ikey> tis why i built abireport in the first place
<ikey> its a high level overview basically
<ikey> https://github.com/clearlinux/abireport
<ikey> we can quickly track changes like so: https://dev.solus-project.com/R545:81e86e35ad503ce3df7387a3b9b6f17671a06b1a
<ikey> all part of the build process
<jamesh> on a previous project we used abi-compliance-checker, but it is slow and hard to configure
<jamesh> ikey: there's so many ABI changes that won't show up in the symbol table though
<ikey> sure - but it requires being a sensible distro dev
<ikey> the vast majority of ABI-you-should-care-about will show up
<ikey> sonames, linker versions and actual symbols
<ikey> its more similar to nm -g --dynamic --defined-only
<ikey> saved my backside more times than i care to count
<ikey> the abi_used_libs{,32} files come from DT_NEEDED cruft
<ikey> as solus forces -as-needed at the toolchain level (via binutils)
<ikey> i.e. not via cflags
<jamesh> so does Ubuntu, IIRC
<ikey> ah handy
<ikey> it causes some problems for janky build systems that have link order incorrect
<ikey> but we can unset LD_AS_NEEDED in environment to workaround it
<ikey> btw nice work on the startup times for desktop snaps :D
<jamesh> well, the package build infrastructure.  It doesn't change the behaviour of the tools you install on Ubuntu
<ikey> right, our build  stuff (ypkg) sets LD_AS_NEEDED in the environment
<ikey> which triggers the change in binutils to force the behaviour
<ikey> default user environment doesnt trigger it
<ikey> so in the package.yml we'd just do: unset LD_AS_NEEDED
<ikey> example: https://github.com/solus-project/runtime-snaps/blob/master/support_packages/mesa/package.yml#L48
<mborzecki> pstolowski: thanks for the review :)
<mup> PR snapd#4293 opened: snapstate: store if a snap is a payed snap in the sideinfo <Created by mvo5> <https://github.com/snapcore/snapd/pull/4293>
<ikey> surely we mean Paid?
<ikey> >_>
<Chipaca> ikey: yes
<Chipaca> ikey: English is hard
<ikey> cool - i just didnt know if i was misreading :p
<Chipaca> ikey: maybe it's a typo and we're working on snaps reaching plaid speed
<ikey> aha
<pedronis> mvo: thanks, I can pick up that PR after lunch, there's also a couple of places in store that can use that flag IÂ think
<pstolowski> mborzecki, np, still reviewing
<mborzecki> any idea what might be the reason for 'stateengine.go:98: state ensure error: devicemgr: cannot find account (testrootorg)' ?
 * sergiusens waves good morning
<mvo> pedronis: sounds good, thank you
<mvo> mborzecki: this error indicates the testrootorg account was not added in some test. where do you see that?
<mborzecki> mvo: when running linode:arch-2017.07.01:tests/main/classic-custom-device-reg
<mvo> mborzecki: is this snapd compiled with the "testkeys" option?
<mvo> mborzecki: build tag for go is: "withtestkeys"
<mborzecki> hmm that would explain it, the package is built without any additional tags passed to go
<mvo> mborzecki: yeah, but I think you still found a bug :)
<mvo> mborzecki: usually we ahve a if [ trusted keys ] guard for tests that need it
<mborzecki> can't tell, i'm randomly jumping around asserts/database.go and overlord/assertstate :)
<mvo> mborzecki: it seems like our code could be smarter that sets TRUST_TEST_KEYS
<mvo> mborzecki: anyway, the error itself should go away if you build it with this flag
<nessita> mvo, ikey checking
<mborzecki> mvo: i think it's on me, the package that's built for arch does not have this tag set
<mvo> mborzecki: (obviously this is only for testing)
<mborzecki> i see now that the rpm built during tests sets this
<ikey> checking what on the who now
<mvo> mborzecki: cool, good luck
<ikey> *squirrel*
<nessita> mvo, ikey I moved revision 6 to manual review and then as reviewer I ran the automated checks agains, there is one failure
<nessita> "
<nessita> (NEEDS REVIEW) type 'base' not allowed lint-snap-v2_snap_type_redflag
<nessita> "
<ikey> yeah that one i know about :D
<Chipaca> ikey: mborzecki: fyi the static checks caught the payed vs paid thing
<nessita> the revision 7 review should start soon
<ikey> i wouldnt bother nessita honestly
<pedronis> Chipaca: I'm taking up that PR
<ikey> im building revision 8
<ikey> to fix one last issue with the runtime
<ikey> then that'll be my final runtime for jdstrand to sign off on
<Chipaca> "one last issue" <- lol
<ikey> lol
<ikey> it was missing libkmod
<nessita> ikey, well but until revision 7 is reviewed, revision 8 will not be -- you can reject revision 7 yourself
<ikey> sure but none of them will pass review right now anyway :D
<ikey> they're all base
<ikey> autoreject
<nessita> ikey, kk
<ikey> thanks though - i just wanted to unclog whatever it was i busted earlier xD
<ikey> well im also compiling mesa + glibc again so it might take a small while before this snap is done.. >_>
 * ikey adds weekend TODO about having caching for this process
<mborzecki> we're setting LANG=C.UTF-8 in environment for the tests, would switching to LANG=C and probably LC_ALL=C be a big issue?
<mup> PR snapd#4294 opened: Mount with x-gdu.hide option <Created by azzar1> <https://github.com/snapcore/snapd/pull/4294>
<mup> PR snapcraft#1761 opened: lxd: ContainerConnectionError on failed launch/ start <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1761>
<Chipaca> mborzecki: in what distro?
<Chipaca> afaik c.utf-8 is a debianism
<Chipaca> althouh i think redhat picked that up as well; not sure
<mvo> mborzecki: we mostly use C.UTF-8 to avoid python3 exploding all over the place if it is not in a utf-8 locale (at least iirc)
<pedronis> mvo: Chipaca: IÂ updated the paid PR
<mvo> pedronis: \o/
<mborzecki> hm arch
<mborzecki> yeah, it doesn't like C.UTF-8 at all
<ikey> C.UTF-8 is non-standard
<mborzecki> i've added an override LC_ALL=C in the test to workaround this
<mborzecki> this will have to do probably :)
<ikey> failing that, en_US.utf8
<cjwatson> while C.UTF-8 is non-standard, it might be worth generating it with localedef if it isn't there, because there's no standard way to get a UTF-8 locale and the tests probably do need one
<mup> PR snapd#4295 opened: tests/main/manpages: set LC_ALL=C as man may complain if the locale is unset or unsupported <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4295>
<cjwatson> I forget the exact invocation of localedef you need but it's not hard
<Chipaca> there's an example at the end of locale(1) that'll probably get you most of the way there
<ikey> hm snapcraft is being rather communicative
<ogra_> it likes you !
<ikey> https://ibin.co/3iOpZnKAHMIs.png <- is there an expectation that i have xdelta installed?
<ogra_> if oyu want to save bandwith you want xdelta
<ogra_> well xdelta3
<ikey> sure but im wondering if this needs to be in the snapcraft snap
<ikey> because there are a lot of xdeltas
<ogra_> sounds reasonable that it ships it, yeah
<ikey> i mean im happy to install ofc - just wondering about the intricacies of it
<ikey> i like that i get the feedback in the terminal now
<ikey> and i will reluctantly admit that its handy to select revisions for promotion from the cli
<cjwatson> Chipaca: that's close to what I was thinking of, yes.  In fact the specific invocation for C.UTF-8 should be in the Debian glibc packaging
<cjwatson> debian/rules.d/build.mk:108:        I18NPATH=$(CURDIR)/localedata GCONV_PATH=$(DEB_BUILDDIR)/iconvdata localedef --quiet -c -f UTF-8 -i C $(CURDIR)/build-tree/C.UTF-8 ; \
<cjwatson> should be able to drop I18NPATH and GCONV_PATH from that
<cjwatson> right, so looks like localedef --quiet -c -f UTF-8 -i C ./C.UTF-8 would work, and then point LOCPATH to that
<mborzecki> cjwatson: thanks for the tips, that's something that could probably be applied to arch at disto level
<cjwatson> Could just be done globally - no reason for that to be distro-specific I think
<cjwatson> I mean, Debian-derived distros have a C.UTF-8, but you can generate another local version of it harmlessly
<cachio> pedronis, the issue about gpg is that the dir "/root/.snap/gnupg/private-keys-v1.d" is missing
<pedronis> cachio: mmh
<pedronis> cachio: I need to dig, IÂ have seen that dir sometimes, but IÂ don't know why it's there/created
<cachio> pedronis, I created this and the snap create-key started working
<pedronis> it's probably a really bug
<pedronis> *real bug
<pedronis> not a serious one but annoying
<cachio> pedronis, but, the first time it works
<cachio> I execute snap-create-key test alone and it pass
<cachio> but if I use -repeat 2 the secont execution fails
<pedronis> mmh, no, I was confused
<pedronis> this is from gpg itself
<pedronis> or something else
<pedronis> I'm confused
<cachio> pedronis, I am gonna run again and see it this fir exists the first time
<pedronis> cachio: there's some explanation about that dir here:  https://www.gnupg.org/faq/whats-new-in-2.1.html  , see  Removal of the secret keyring
<pedronis> cachio: do we cleanup  ~/.snap/gnupg  between tests?
<cachio> pedronis, I think so
<cachio> pedronis, checking
<pedronis> in reset_classic we do:  rm -rf /root/.snap/gnupg
<cachio> yes
<cprov> elopio: would you be familiar with the test failures in https://travis-ci.org/snapcore/snapcraft/jobs/306445933 ?  locally it is passing, would you know how to reproduce it in xenial ?
<mup> PR snapd#4296 opened: packaging/arch: pre-create snapd directories when packaging <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4296>
<mup> PR snapd#4108 closed: repo: ConnectedPlug and ConnectedSlot types <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4108>
<niemeyer> Lunch, biab
<cachio> pedronis, I pushed the fix
<cachio> pedronis, thanks for helping
<pedronis> cachio: ah
<sergiusens> ikey it is in the snapcraft snap (xdelta3), you just found a bug that's all :-)
<ikey> ah gotcha
<pedronis> cachio: wondering if we shouldn't stop/restart the agent instead ?
 * kalikiana food
<cachio> pedronis, testing that
<cachio> pedronis, the change works
<cachio> pedronis, In sid the agent is creating that dir in case it does not exist any more
<cachio> pedronis, I supose they fixed after v 2.1.18
<cachio> pedronis, I'll take a look to che changelog
<cachio> niemeyer, fedora 26 passed
<niemeyer> cachio: \o/
<cachio> niemeyer, should I add this as manual execution?
<niemeyer> cachio: Any reason not to do automatic, other than the extra worker?
<cachio> niemeyer, no, just the workers needed
<niemeyer> Son_Goku: Any ideas here?
<cachio> niemeyer, then we will have fedora 27
<Son_Goku> niemeyer: eh?
<cachio> and rawhide
<Son_Goku> ideas for what?
<niemeyer> Son_Goku: Value of running tests on Fedora 26 at all times.. we'll be working on 27 and rawhide next
<Son_Goku> well, 26 is a currently supported stable release for a year
<Son_Goku> but if you'd rather only support 27 and rawhide, that's fine
<Son_Goku> let's just not be in a position where we're stuck on an old version for too long
<niemeyer> Son_Goku: Any stats on user base?  Do we have a significant percentage of users there still?
<Son_Goku> no idea
<Son_Goku> Fedora doesn't collect stats
<niemeyer> Son_Goku: Well, I'm sure file servers have logs
<Son_Goku> in the mirror network, probably
<Son_Goku> but the best way to figure this out would be the store side logs
<niemeyer> Son_Goku: Good point
<Son_Goku> each snapd version is encoded with their package release version
<Son_Goku> which has the .fcXX suffix encoded
<niemeyer> cachio: Ok, I suggest enabling 27 and rawhide first, and let's talk to the store team to see if we can figure out any hints of demand
<Son_Goku> so snapd 2.29.4 from Fedora 26 will say its version is 2.29.4-2.fc26
<niemeyer> cachio: We can keep manual meanwhile
<cachio> niemeyer, sure
<niemeyer> Son_Goku: Thanks for the details
<Son_Goku> np
<cachio> niemeyer, I'll continue with fedora 27
<ikey> got at least 12 solus users with snapd
<Son_Goku> incidentally, I encode this data in the snapd version because from time to time, I do patches/backports that differ from you guys
<Son_Goku> makes it easier to identify where a breakage might happen (if it ever does)
<niemeyer> ikey: It's a good start! :)
<ikey> :D
<Son_Goku> there's *probably* more than 12 Fedora users :P
<ikey> nah
<ikey> never heard of it
<ikey> >_>
<mborzecki> Son_Goku: idk I stopped using it ~3 months ago :)
<Son_Goku> ...
<ikey> :O
<ikey> niemeyer, happy: https://github.com/solus-project/runtime-snaps/blob/master/abi/abi_used_libs
<ikey> is empty ^_^
 * Son_Goku collapses in glum agony
<mborzecki> yeah, got lazy at some point, didn't want to go through another upgrade and installed tumbleweed just for the lulz
<ikey> when i move to implementing apparmor confinement (post snapd stable release and store inclusion of both edges) - then ill need to move stuff like theme assets from runtime to the lsi snap itself
<ikey> mborzecki, they still got their sysvinit-on-top-of-systemd thing going on?
<Son_Goku> ikey: btw, are there any changes of yours left that aren't part of snapd 2.29.4?
<ikey> that i dont know
<Son_Goku> I may want to cherry-pick those into Fedora snapd
<mborzecki> maybe, can't tell, it was awkward, everything seemed broken, spent the last 3 months or so fighting with policykit as it kept asking me for root (yeah root) password to authorize any operation
<ikey> i dont think i have pending PRs
<Son_Goku> mborzecki: with snapd?
<Son_Goku> on Fedora?
<ikey> mborzecki, ah that reminds me i need to upstream my polkit patches this weekend..
<ikey> in solus we removed JS from polkit
<ikey> >_>
<Son_Goku> mborzecki: I literally just fixed that last week
<niemeyer> cachio: I'm seeing errors being reported about fedora-25 in travis
<niemeyer> cachio: In unrelated PRs
<niemeyer>   Status code: 502 for https://mirrors.fedoraproject.org/metalink?repo=fedora-25&arch=x86_64
<ikey> this is our polkit policy definition :P https://dev.solus-project.com/source/gvfs/browse/master/files/org.gtk.vfs.file-operations.keyrules
<niemeyer> cachio: Known?
<niemeyer> Son_Goku: ^
<Son_Goku> niemeyer: that's the Linode mirror being broken
<mborzecki> Son_Goku: if it's any consolation, my wife, who's got nothing to do with IT whatsoever is runnig the latest fedora on her laptop  and prefers it to any other distro i had installed her before
<ikey> Son_Goku, i dont see any open PRs from me on github
<niemeyer> Son_Goku: ;(
<ikey> so my nvidia work is in
<Son_Goku> I believe Linode has a mirror override for their IP block (Fedora MirrorManager lets you register private and public mirrors in that manner) and their mirror is awful
<ikey> we might want to flesh out desktop-helpers to support the new system though?
<Son_Goku> niemeyer: I have a similar override in place for my workplace for its local mirror
<ikey> for vulkan + biarch nvidia..
<Son_Goku> ikey: right
<Son_Goku> but RADV and Intel Vulkan should work, right?
<ikey> wait i just said 'we'
<ikey> y'all done stockholmed me
<Son_Goku> :P
<ikey> Son_Goku, as long as they're present
<ikey> and accessible in some fashion
<ikey> f.e. solus-runtime-gaming ships a full weight mesa with the vulkan drivers
<Son_Goku> hmm
<ikey> and can use the "host" vulkan for nvidia support
<ikey> but it requires the icd loader inside the snap runtime or snap itself
<ikey> i.e. libvulkan.so.1
<ikey> i suspect we've got some apparmor confinement nightmares to work out there
<ikey> but lsi is a good place to debug that
<ikey> as its a meaty runtime
<Son_Goku> uh oh
<Son_Goku> I fucked up
<ikey> onoes
<Son_Goku> oh wait
<Son_Goku> panic averted
<Son_Goku> snapd-selinux is there
<ikey> yeah tell that to golang
<ikey> >_>
<Son_Goku> hahah
<ikey> and now im making programming jokes
<Son_Goku> for a minute there, I thought I might have accidentally not built it
 * ikey is taking himself out tonight
<ikey> like, out to a pub
<ikey> not gonna mobhit myself as i have dinner
<Son_Goku> haha
<ikey> can't even begin to work out the logistics for having myself still surprised by the event *and* having meaningful last words..
<Son_Goku> haha
<Son_Goku> be drunk when you order your hit?
<ikey> ah that could do it
<ikey> so taking myself out will actually take me out
<ikey> i do love the beauty of that
<cachio> niemeyer, taking a look
<mup> PR snapd#4297 opened: Adding fedora-26 image to snapd spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4297>
<Chipaca> ikey: is that some sort of extrovert kalsarikÃ¤nnit?
 * ikey googles this word
<ikey> oh
<ikey> hm
<ikey> lol. i guess?
<ikey> just.. with the pants
<ikey> well i mean i cant make promises on that count but its the intent anyway
<kalikiana> apparently there's even an emoji for that
<elopio> kyrofa: hey, we can remove the shared ros demo now, right? I see we have almost the same code in snapcraft/tests/integration/snaps/catkin-shared-ros
<elopio> the thing we are missing seems to be a test that installs and executes that snap.
<niemeyer> cachio_lunch: Sorry, I forgot we had fedora *25* tests running automatically.. I suggest moving those to manual, and running 26 instead
<sergiusens> kalikiana hey, did you see the bug I logged yesterday? It is quite critical to a good experience
<kalikiana> sergiusens: You mean bug 1734145? I haven't checked it yet. But I'm going to take a look in a moment and see what's going on there
<mup> Bug #1734145: snapcraft clean <part-name> destroys everything when using containers <Snapcraft:Triaged by kalikiana> <https://launchpad.net/bugs/1734145>
<mborzecki> ok guys, i'm done for today, enjoy your weekend
<zyga-ubuntu> hey guys
<zyga-ubuntu> not working feels refreshing for a change
<zyga-ubuntu> mid day I was no longer thinking about solving work problems
<zyga-ubuntu> I hope you all had a fantastic day and I will happily see you next week :)
<Son_Goku> bye :)
<zyga-ubuntu> hey Son_Goku
<Son_Goku> zyga-ubuntu: hey
<zyga-ubuntu> enjoy your weekend :)
<Son_Goku> I will!
<Son_Goku> zyga-ubuntu: test the fedora snapd packages :)
<zyga-ubuntu> I bought a pair of gloves today
<zyga-ubuntu> poland is so cold so quickly
<zyga-ubuntu> it's not even sub-zero yet
<Son_Goku> heh
<zyga-ubuntu> Son_Goku: ok, I recently installed F27
<Son_Goku> it's already getting to subzero here
<zyga-ubuntu> Son_Goku: here too but it's not like that daily and all the time (yet)
<Son_Goku> also, if you want to have some fun, we have mir packages in Fedora 26 and 27 testing
<Son_Goku> zyga-ubuntu: every day after 6pm, it's subzero
<zyga-ubuntu> ok so poland is still warmer
<zyga-ubuntu> man, I'm complaining too much :D
<mup> PR snapd#4295 closed: tests/main/manpages: set LC_ALL=C as man may complain if the locale is unset or unsupported <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4295>
<niemeyer> Good news: compression on spread works
<niemeyer> Bad news: it doesn't seem to improve timing much
<niemeyer> https://travis-ci.org/snapcore/snapd/builds/306754148
<niemeyer> This one was run entirely with compression on with server=>client
<sergiusens> kyrofa mind looking at my latest PR?
<kalikiana> sergiusens: I confirmed the bug. I need to investigate why the unit test didn't fail.
<kalikiana> elopio: maybe you could help me here find out what is wrong?
<kalikiana> the checks *look* right...
<elopio> kalikiana: which bug?
<kalikiana> elopio: bug 1734145 - https://github.com/snapcore/snapcraft/blob/master/snapcraft/tests/unit/commands/test_clean.py#L178
<mup> Bug #1734145: snapcraft clean <part-name> destroys everything when using containers <Snapcraft:In Progress by kalikiana> <https://launchpad.net/bugs/1734145>
<kalikiana> elopio: I have an idea what's wrong with the code. But the test passing puzzles me
<elopio> kalikiana: to check what's in the call args, just change it to assertEqual and give it a try.
<cachio> niemeyer, sure
<kalikiana> elopio: nothing is in the call args
<kalikiana> elopio: which *would* mean all is fine, no bug
<elopio> that would be a better check, instead of NotEquals, check that there are no calls.
<kalikiana> I'm saying there are none
<elopio> but why it is passing despite the bug, I don't know. The mock might be wrong.
<kalikiana> oh.... I just realized why
<kalikiana> the test doesn't set fake_lxd.status
<kalikiana> so fake_lxd has no container which would be deleted...
<mup> PR snapd#4298 opened: many: remove configure-snapd task again and handle internally <Created by mvo5> <https://github.com/snapcore/snapd/pull/4298>
<mup> PR snapd#4296 closed: packaging/arch: pre-create snapd directories when packaging <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4296>
<kalikiana> elopio: if you see the test, can you tell me what you expected it to do? without looking at the fixture source
<mvo> pedronis: not urgent but early sniff test on 4298 would be appreciated
<elopio> kalikiana: to check that the container was not deleted when a part is passed as an argument.
<mup> PR snapd#4265 closed: New debian-sid-64 and debian-9-64 images for testing <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4265>
<zyga-ubuntu> we have < 25 PRs, that's very refreshing
<mup> PR snapd#4293 closed: snapstate,store: store if a snap is a paid snap in the sideinfo <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4293>
<kyrofa> sergiusens, yeah, making it through a few older ones, on my way up
<kyrofa> sergiusens, could use your thoughts on snapcraft#1746
<mup> PR snapcraft#1746: cli: add version command <Created by gsilvapt> <https://github.com/snapcore/snapcraft/pull/1746>
<kalikiana> elopio: that is correct. I'm thinking if it's also clear what fake_lxd provides - without .status - 'Stopped' it doesn't do what you expect. Maybe a method like .creater_container('foo')? I think the property assignments aren't good enough
<kalikiana> Neither of us saw that it was wrong
<elopio> kalikiana it's clear when you call status. It's not clear when you forget it. The joy of mocks...
 * elopio relocates
 * zyga-ubuntu wonders why snap-run-link performs reset.sh in its prepare state?
<zyga-ubuntu> prepare *step*
<zyga-ubuntu> then installs core from beta
<zyga-ubuntu> feels totally bogus
<zyga-ubuntu> there, patched locally not to do this
<zyga-ubuntu> let's see what's next
<kalikiana> elopio: Yeah.... it's difficult to avoid that kind of thing...
<mup> PR snapcraft#1762 opened: lxd: delete container only if parts is empty <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1762>
<kalikiana> sergiusens: the tmp_dir fix is here snapcraft#1742
<mup> PR snapcraft#1742: lxd: always remove tmp_dir after execution <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1742>
<Son_Goku> cachio: we can probably drop fedora-25 entirely
<Son_Goku> as it's EOL is in December
<Son_Goku> I certainly don't plan to make new updates for Fedora 25 past 2.29.x
<ikey> heads up, brave browser lacks japanese font support: https://dev.solus-project.com/T5080
<ikey> we're gonna have them forward to snapcraft forum
<ikey> fully confined snap, nothing we can do our side
<elopio> kalikiana you could make the fake smarter. If lxc start is called, update the internal status.
<zyga-ubuntu> ikey: you can!
<zyga-ubuntu> ikey: we have host font support now
<zyga-ubuntu> ikey: fonts from /usr/share/fonts are ahred
<zyga-ubuntu> *shared
<ikey> ah gdi
<ikey> lol
<ikey> literally just closed it xD
<kalikiana> elopio: that's what it already does! the properties are only used to eg. fake an existing container
<ikey> is this upcoming or in release?
<ikey> and if its in git i can backport to solus snapd for this guy
<cachio> Son_Goku, ok
<zyga-ubuntu> ikey: I think it's released now, it's a part of one of the interfaces
<zyga-ubuntu> ikey: I forgot, look for "fonts" in interfaces/builtin
<zyga-ubuntu> ikey: it should just work now
<cachio> Son_Goku, It is gonna be manual after 26 is added
<Son_Goku> cool
<ikey> nothing in 'snap interfaces' listing here
<zyga-ubuntu> ikey: no no, I mean "grep the code luke"
<ikey> oh XD
<zyga-ubuntu> btw
<zyga-ubuntu> do you know anything that shows network usage
<zyga-ubuntu> akin to "time"
<ikey> ehm not off the top of me head
<ikey> netstat is a bit meh
<zyga-ubuntu> I read about the new BPF based tools on LWN
<zyga-ubuntu> I need to try those
<ikey> vnstat but i dont think it has the granularity
<ikey> its more system wide
<ikey> vs this thingy is using that much
<zyga-ubuntu> there was something that tracks TCP
<mup> PR snapd#4297 closed: Adding fedora-26 image to snapd spread.yaml <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4297>
<elopio> kalikiana then maybe don't fake an existing container, always set up the fake from scratch.
 * kalikiana hopping on a tram now
<kalikiana> elopio: I'm not sure what you mean. I am setting up the fake here
<kalikiana> I guess we should brainstorm the fakes at some point and see if we can improve it
<cachio> niemeyer, fedora 27 ready in the 45.56.91.42
<kyrofa> Dude, patchelf is kind of awesome
<niemeyer> cachio: Sweet
<niemeyer> cachio: Which spread is that?
<niemeyer> Which machine is that, I mean
<cachio> niemeyer, dont know which spread
<cachio> it is the fedora-27-x86_64
<niemeyer> cachio: I need to know the machine number..
<niemeyer> Spread-N
<cachio> I don'thave it
<cachio> I just saved the ips long time ago
<cachio> let me check in the irc logs
<niemeyer> cachio: Your own messages say this is Spread45
<niemeyer> cachio: Your own messages say this is Spread-45
<niemeyer> Looking into it
<niemeyer> cachio: ... and I'm being silly, sorry. The main machine table does list the public IP address. I just never used/noticed it there.
<cachio> niemeyer, :)
<Chipaca> zyga-ubuntu: i didn't understand your comment about x-snapd
<niemeyer> I always go to the configuration tab, and it woudn't be fun to scan 80 machines for the IP address.. that's why I was asking for it
<zyga-ubuntu> Chipaca: look at entry.go
<zyga-ubuntu> Chipaca: there are functions there
<Chipaca> zyga-ubuntu: yes
<zyga-ubuntu> Chipaca: I was referring to the fact you made that const, I wonder why
<Chipaca> zyga-ubuntu: the things i made consts aren't used as variables afaict
<zyga-ubuntu> yeo
<zyga-ubuntu> yep
<zyga-ubuntu> Chipaca: anyway, that's fine :)
<zyga-ubuntu> I was just curious
<Chipaca> zyga-ubuntu: the reason i made the change is laziness
<Chipaca> that's all
<Chipaca> zyga-ubuntu: otherwise i'dd have to import sys and make uid and gid be sys.UserID(0) and sys.GroupID(0)
<Chipaca> zyga-ubuntu: "but Chipaca", you say, "being lazy isn't a good reason for doing that"
<Chipaca> zyga-ubuntu: and you might be right :-)
<ikey> id say laziness makes the world go round, but ideally the world would keep itself turning and report issues to itself
<zyga-ubuntu> haha,  no, it's fine :)
<zyga-ubuntu> YAGNI
<zyga-ubuntu> if I need it, I'll change it
<Chipaca> zyga-ubuntu: TBH i was very close to just inlining the constants
<Chipaca> ikey: with you on that
<ikey> ^^
<Chipaca> also: it's 1807 on a friday
<ikey> in the US? :P
<ikey> or we talking hours
 * ikey runs
<Chipaca> i'm off to bathe smelly boys and make smelly pizza
<Chipaca> o/
<ikey> \o
 * ikey contemplates The Going Out
<Chipaca> ikey: The Great Goingoutening of 2017
<ikey> mm
<niemeyer> cachio: You've got an image.. machine is back up in case you need it
<cachio> niemeyer, great, I'll test it
<niemeyer> and I'm taking a break
<cachio> sure, in 20 minutes fedora 28 will be ready
<niemeyer> A good weekend for those reaching their EOD
<mup> Bug #1734213 changed: Python scripts named pip* filtered out of snaps <Snapcraft:New> <https://launchpad.net/bugs/1734213>
<mup> PR snapcraft#1763 opened: Make the pip filtering in the Python plugin more fine-grained <Created by OddBloke> <https://github.com/snapcore/snapcraft/pull/1763>
<cachio> niemeyer, fedora 28 ready on 45.79.183.239
<cachio> fedora-rawhide-64
<zyga-ubuntu> cachio: note that rawhide is not 28
<zyga-ubuntu> cachio: it will stay as rawhide forever
<zyga-ubuntu> cachio: f28 didn't branch yet
<cachio> zyga-ubuntu, ah, ok
<sergiusens> kyrofa elopio thanks for the reviews, question, does that failing test pass for you guys when running locally?
<zyga-ubuntu> 30 / 166
<zyga-ubuntu> slow but predictable progress
<kyrofa> sergiusens, I didn't run that particular test locally, but I tested with binaries from the archive and it worked
<kyrofa> I'll run it in a minute
<sergiusens> kyrofa right, that is what I did; I am considering there to be an issue with the testbed
<kyrofa> sergiusens, wonder if it's not properly changing to classic
<sergiusens> kyrofa it works fine locally, so I assume it does
<kyrofa> Weird. I don't know what it could be, then
<elopio> sergiusens: I can try in an hour, after the ubuntu on air.
<elopio> kyrofa and anybody else who wants to join: https://hangouts.google.com/hangouts/_/urbvfds645aehgjqxmbuxjpuzme
<zyga-ubuntu> 41 tests passed and counting :)
<sergiusens> elopio kyrofa having SNAPCRAFT_CONTAINER_BUILDS set and running the tests has very weird hidden side effects
<elopio> zyga-ubuntu: we are doing a thing live ^ I know  you like thouse :)
<elopio> sergiusens: oh, maybe we should clean all the env vars on setup.
<zyga-ubuntu> elopio: I'm in my pyjama already and kind of scruffy looking
<zyga-ubuntu> elopio: is it weekly as before
<zyga-ubuntu> elopio: I can join next week, today I'm not in shape
<elopio> zyga-ubuntu: it's monthly for now. You can always wear a mask
<kyrofa> zyga-ubuntu, dang, don't join, you sound like an open-source hacker. We don't want those
<zyga-ubuntu> kyrofa: achievement unlocked :D
<kyrofa> :P
<zyga-ubuntu> kyrofa: I'm in my undies, running tests, playing a game and chatting on 3 computers
<kyrofa> You only get the achievement if you're also eating something
<zyga-ubuntu> well
<kyrofa> Hot pockets, preferably
<zyga-ubuntu> unlocked :D
<zyga-ubuntu> "serek waniliowy"
<zyga-ubuntu> google if you want to see
<zyga-ubuntu> but
<zyga-ubuntu> drinking pure water out of my "rostopic pub 2016" glass
<niemeyer> cachio: fedora-28-64 is ready
<cachio> niemeyer, the name is fedora-rawhide-64
<cachio> could you please rename the image?
<elopio> relocating again...
<sergiusens> elopio kyrofa my branch is ready for another look
<sergiusens> elopio I would appreciate if you could look into that test failure
<mup> PR snapcraft#1764 opened: snapcraft.yaml: use gcc to detect triplet <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1764>
<kyrofa> sergiusens, that one is pretty critical ^, and easy to review
<sergiusens> kyrofa sure, I'll trade you ;-)
<kyrofa> So not equivalent :P
<kyrofa> But okay
<kyrofa> sergiusens, question. Why did you decide on using a sitecustomize.py versus .pth files?
<kyrofa> sergiusens, few doc suggestions left, but it looks quite nice
<sergiusens> kyrofa I'll fix those docs
<sergiusens> kyrofa .pth are not dynamic between part's install, stage and the actual snap
<kyrofa> sergiusens, excellent, that's what I was hoping
<sergiusens> kyrofa why are you asking I wonder :-)
<Son_Goku> woo
#snappy 2017-11-25
<mup> PR snapd#4299 opened: osutil/user: replace our uses of os/user and filepath.Glob("/home/*") <Created by chipaca> <https://github.com/snapcore/snapd/pull/4299>
<zyga-ubuntu> john, it's Saturday!
<sergiusens> says the one who noticed ;-)
<zyga-ubuntu> well
<zyga-ubuntu> haha, isn't it a bit early for you too? :)
<zyga-ubuntu>                                                                                                                                                                                                                                                                                                                                                                                                                      
<zyga-ubuntu>                                                                                                                                                                                                                                                                                                                                                                                                                      
<zyga-ubuntu>                                                                                                                                                                                                                                                                                                                                                                                                                      
<zyga-ubuntu>                                                                                                                                                                                                                                                                                                                                                                                                                      
<zyga-ubuntu>                                                                                                                                                                                                                                                                                                                                                                                                                      
<zyga-ubuntu>                                                                                                                                                                                                                                                                                                                                                                                                                      
<zyga-ubuntu>                                                                                                                                                                                                                                                                                                                                      
<lundmar> Hi. I'm creating a snap that includes some man pages but I can't find any documentation how to enables the man pages in snapcraft.yaml?
<lundmar> enable*
<zyga-ubuntu> lundmar: that is not supported yet
<lundmar> darn :/
<zyga-ubuntu> as a poor man's workaround embed man and your manual pages as a "man" command in your snap
<zyga-ubuntu> it's not perfect, we will get to properly integrated man pages, it's just not on the immediate roadmap
<lundmar> the man package is quite an unwnanted dependency sizewise :)
<zyga-ubuntu> lundmar: how big is "/usr/bin/man" itself?
<zyga-ubuntu> but sure, I get it
<zyga-ubuntu> just letting you know
<lundmar> well, I assume the binary itself is not big but it comes with other files/dependencies I guess I would have to swing my rake at.
<lundmar> also, your man command would override the systems man command which I think would be unfortunate and maybe cause other issues.
<lundmar> supporting man pages via a snapcraft plug interface would be really useful. This is kind of the last step to get to first class support for commandline tools.
<lundmar> how about support for completion scripts? I reported it as an issue long ago and it seems it has been fixed since snap v2.28 but I just tested and it does not automatically pick up on the completion scripts. Do I need to add anything to snapcraft.yaml?
<lundmar> zyga-ubuntu: Can snaps update a users environment variables? In other words, can I create a snap that adds my man page path to the users MANPATH variable?
<lundmar> or is it fully isolated so that can't be done
<zyga-ubuntu> lundmar: no, that would be extremely dangerous in genral
<zyga-ubuntu> lundmar: we have a plan on how manual pages can be integrated
<zyga-ubuntu> lundmar: but it's not something that will happen overnight
<zyga-ubuntu> lundmar: there's confinement coming to man itself, so that it can process untrusted input
<zyga-ubuntu> lundmar: and there's a plan to pre-process the manual pages from snaps before they are exported to unconfined world
<zyga-ubuntu> lundmar: but both are still unscheduled (I think the man work is upstream)
<zyga-ubuntu> I'm going AFK, if you leave me messages I'll check them out late r:)
<lundmar> ok thanks for the info. Glad to know a solution is on its way.
<lundmar> Now, I need to figure out how this completion support works
<lundmar> My snap package 'tio' (a serial TYY too) is running in to all the hard snapcraft issues. First it could not access serial ports (fixed now by serial-port plug), then no completion script feature, and now the man page feature he he
<lundmar> tool*
<lundmar> If anyone can provide me an example snapcraft.yaml on how to enable autocompletion scripts that would be helpful. thanks.
<zyga-ubuntu> lundmar: there are some in snapcraft and snapd source code
<zyga-ubuntu> lundmar: you need a complete: or something similar key
<zyga-ubuntu> lundmar: grep for that in tests/ in snapd tree
<zyga-ubuntu> lundmar: there are examples in snapcraft that are more educational but I'm on the snapd side
<lundmar> zyga-ubuntu: yeah, I finally found that via google. I'm looking at it now. thanks.
<lundmar> I found it referenced by this guy: http://chipaca.com/post/160369439977/in-snap-tab-completion
<lundmar> hmm, it seems to use the new "completer:" key I have to make a copy of my completion script and put it in some "prime" directory to make it succesfully build my snap. Seems a bit silly to make a copy when it actually gets installed. Is there a way I can reference the installed script instead?
<zyga-ubuntu> lundmar: yeah, chipaca implemeted it all :)
<zyga-ubuntu> lundmar: probably, I don't know
<lundmar> hehe, the prime directory gets cleaned out by snapcraft clean so that is definitely not the place to put it
<lundmar> I'm not liking all the temp directories that snapcraft creates. You guys should consider putting all of them in a single top "build" directory
<lundmar> Also, it seems odd to me that snapcraft init create snap/snapcraft.yaml. I think it would be better if it simply creates snapcraft.yaml in the current directory or a directory specified by the user, for example: snapcraft init tio would create tio/snapcraft.yaml
<lundmar> it gets even worse when you then start adding stuff like snap/snap/gui/icon.png
<lundmar> I'm missing structure guys :)
<zyga-ubuntu> lundmar: snapcraft needs to know the root directory
<zyga-ubuntu> lundmar: and snapcraft integration needs to be automatic (for build systems)
<zyga-ubuntu> lundmar: so we pick either top-level/snapcraft.yaml or snap/snapcraft.yaml
<zyga-ubuntu> lundmar: for simplicity and consistency
<zyga-ubuntu> lundmar: as for the swarm of helper directories, yes, I agree and I _think_ this is something that's under control now, I'm just not sure how (again, mostly working under the hood in snapd)
<zyga-ubuntu> lundmar: kyrofa, sergiusens or kalikiana can help you
<kalikiana> lundmar: the preferred location these days is snap/snapcraft.yaml for the reason you mentioned, things like gui/icon.png also go in there and you don't need to scatter them all over your source tree
 * zyga-ubuntu makes some tea and returns to debugging snapd integration tets
<zyga-ubuntu> *tests
<kalikiana> lundmar: regarding prime: you don't have to copy anything in there, it gets created during the build, so you can just reference in the yaml
<lundmar> I guess my point os to make snapcraft init work more like git init which is a bit more intuitive.
<lundmar> is*
<kalikiana> lundmar: more intuitive in what respect?
<lundmar> kalikiana: mkdir tio; cd tio; snapcraft init
<lundmar> kalikiana: or simply snapcraft init tio; cd tio
<kalikiana> ah
<kalikiana> never noticed that
<kalikiana> but you're right
<lundmar> currently: snapcraft init; mv snap tio; cd tio
<lundmar> its a bit messy imho
<kalikiana> I guess I don't have a strong preference personally for that sort of detail
<lundmar> I'm sorry, I'm a stickler for details :)
<zyga-ubuntu> lundmar: maybe I don't understand your point fully but I always thought about snapcraft init as creating the debian/ directory
<zyga-ubuntu> packaging stays "there"
<lundmar> Imagine you start out by creating multiple snaps with different names, you will see my point ;)
<zyga-ubuntu> lundmar: I don't get it, can you explain please?
<zyga-ubuntu> mkdir foo; cd foo ; snapcraft init; # repeat for bar, etc
<zyga-ubuntu> is that what you mean?
<lundmar> or even simpler: snapcraft init tio; snapcraft init firefox; snapcraft init nano
 * zyga-ubuntu tries
<lundmar> currently: snapcraft init; mv snap tio; snapcraft init firefox; mv snap firefox; snapcraft init; mv snap nano
<lundmar> the way I suggest is more flexible with fewer commands
<zyga-ubuntu> lundmar: snapcraft init tio doesn't work on 2.34 for me
<zyga-ubuntu> (probably out of date)
<lundmar> zyga-ubuntu: thats exactly my point ;)
<lundmar> it is not supported
<zyga-ubuntu> I see your point then :)
<lundmar> hehe
<zyga-ubuntu> kalikiana: is that something that fits your design?
<lundmar> if one is a git user the current way snapcraft init works catches your eye immediately :)
<zyga-ubuntu> well, I'm a git user but I rarely git init
<zyga-ubuntu> but I see your point
<lundmar> I'm a big fan of structure so I would love it snapcraft worked something like this example: snapcraft init tio; cd tio; snapcraft; snapcraft build (the latter creates a build directory containing all the temp build dirs: stage, prime, parts, etc.)
<lundmar> if*
<kalikiana> lundmar: I'd suggest you propose it in the forum (https://forum.snapcraft.io/) and we can see what other people think
<lundmar> kalikiana: i'll do that
<lundmar> hmm, can't I use my Ubuntu one SSO credentials to login to that forum?
<zyga-ubuntu> no, it's long overdue
<zyga-ubuntu> sorry
<lundmar> ok, it seems I can't
<lundmar> oh well, I'll create yet another account hehe
<lundmar> kalikiana: on another note, do you know where I should put the completion script file referenced by the new "completer:" key?
<lundmar> because I can't seem to find the right place, nor in any examples.
<lundmar> there is an example here: https://github.com/snapcore/snapd/blob/master/tests/lib/snaps/test-snapd-complexion/meta/snap.yaml
<lundmar> but it does not work for me
<kalikiana> lundmar: use `stage:\n - my-script-name` where the script is relative to the source of the part
<lundmar> ahh, thanks
<kalikiana> meta is assembled by snapcraft for you, so I'd recommend you consider it an implementation detail
<lundmar> kalikiana: would you happen to have an example anywhre using stage: ?
<lundmar> none of the snapd tests uses it
<kalikiana> lundmar: snapcraft itself uses it
 * lundmar is grepping snapd and snapcraft gits
<lundmar> no matches :/
<kalikiana> lundmar: https://github.com/snapcore/snapcraft/blob/master/snap/snapcraft.yaml#L26
<lundmar> does the apps completer key reference a part?
<lundmar> so I have to create a part which include stage: to my completion script file
<kalikiana> yes
<lundmar> hmm, there must be a way to avaoid creating two staging areas. I mean, my snap is already staging all my source files including my autocompletion script. I just need to find a way to reference what is already created
<lundmar> I tried this but it fails : https://gist.github.com/lundmar/ce6e3a654f9df61fb92f27e2c47c6682
<lundmar> I really want to avoid extracting the completion script from my .tar.xz and putting it somewhere else for snap to use. It would be redundanct
<lundmar> redundant*
<kalikiana> lundmar: where's the file located? you should be able to use the part relative to the part's extracted source
<kalikiana> the *script
<lundmar> kalikiana: it's parts/tio/build/src/bash-completion/tio
<lundmar> no, sorry, I meant  parts/tio/install/share/bash-completion/completions/tio
<lundmar> I assume parts/tio is the staging area
<kalikiana> hold on, I'll try it here
<kalikiana> lundmar: remove the leading "install" from the completer path
<lundmar> kalikiana: darn, I almost had it right then hehe. Thanks!
<lundmar> I guess I'm one of the first actually using this new completion feature
<lundmar> kalikiana: https://forum.snapcraft.io/t/suggestion-lets-improve-snapcraft-init-command
<kalikiana> Awesome. Thanks for starting the conversion
<lundmar> no problem, I have another incoming regarding consolidating the temporory build directories
<lundmar> temporary*
<Syntist_> Any update on theme issue?
<lundmar> kalikiana: https://forum.snapcraft.io/t/suggestion-lets-consolidated-temporary-build-directories-under-one-directory-build
#snappy 2017-11-26
<lundmar> Hi, I'm trying to create a snap for lxi-tools. See https://github.com/lxi/lxi-tools.snapcraft/blob/master/snap/snapcraft.yaml . It works fine except the "lxi" app command becomes lxi-tools.lxi on the commandline - is this intended behaviour or am I'm missing something?
<lundmar> Similarily I'm using this snap for tio https://github.com/tio/tio.snapcraft/blob/master/snap/snapcraft.yaml which works just fine. On the commandline it is 'tio' not 'tio.tio'. As far as I can tell I'm doing pretty much the same in both cases.
<lundmar> I mean, I need it to simply become 'lxi' on the commandline.
<Free_internet> Hi?
<lundmar> Hello free internet
<Free_internet> oh hi
<Free_internet> I am very terrified by the situation of the neutral net
<Free_internet> what can we do?
<lundmar> Free_internet: While I agree I don't think this is the channel to discuss this issue. This is a channel for discussing snap stuff.
<lundmar> Ahh guys, why didn't you tell me about aliases ^^
<lundmar> so, aliases: is deprecated? Replaced with what?
<lundmar> declarations?
#snappy 2018-11-19
<mborzecki> morning
<zyga> Good morning
<zyga> Libc never ceases to surprise
<mborzecki> zyga: hey
<mborzecki> zyga: what happened?
<zyga> I sent a small PR for a bug that was reported after recent TW update
<zyga> https://github.com/snapcore/snapd/pull/6167
<zyga> apparently? libmount is libc now?
<zyga> we end up linking to it
<mborzecki> hm, why haven't i seen it on arch?
<zyga> not sure
<zyga> ldd snap-confine
<mborzecki> zyga: what's the version of glibc you have there?
<zyga> what do you see?
<zyga> one sec
<mborzecki> lib{mount,uuid,blkid} are not part of glibc package on arch
<zyga> 2.27-6.1
<zyga> perhaps I'm wrong
<mborzecki> i'm on 2.28
<zyga> and this is via libudev?
<zyga> I should read changelogs
<mborzecki> zyga: nope, libudev seems to pull in libc only
<zyga> magic :)
<zyga> checking those changelogs
<mborzecki> zyga: does ldd snap-confine show anything interesting?
<zyga> https://www.irccloud.com/pastebin/dSCqaDe2/
<mborzecki> woo
<zyga> that we really link to those guys
<mborzecki> https://paste.fedoraproject.org/paste/a4oL699BiGrowxA0ATuRzA/raw
<zyga> now how do I get changelogs on suse....
<mborzecki> zyga: missing --as-needed?
<mborzecki> rpm -q --changelog?
<zyga> it's odd that this broke after recent update
<zyga> the -1 package was OK
<zyga> then TW synced
<zyga> then it was broken
<zyga> linking didn't change
<mborzecki> zyga: was that a new tw snapshot?
<zyga> yes
<mborzecki> zyga: if you're using tumbleweed-cli you could switch to the previous one
<mborzecki> zyga: heh there's even libpcre in the ldd output you posted :)
<zyga> yep
<zyga> but that was not new
 * zyga wonders how to resolve bug like boo#1113188#c1 to a link
<zyga> suse bugzilla?
<zyga> https://bugzilla.opensuse.org/show_bug.cgi?id=1113188#c1
<zyga> unrelated but explains /run/run bug
<mborzecki> zyga: found anything interesting?
<zyga> nope
<zyga> it's low priority, I think this is fine for now
<zyga> I'm working on more mount bits
<zyga> over weekend I experimented with transactional security setup
<zyga> it looks super promising
<zyga> but to measure I would love to add some helper for checking how long stuff takes
<zyga> need to think about that
<zyga> having said that, I need to get more bits merged
<zyga> super simple review: https://github.com/snapcore/snapd/pull/6150
<mvo> 6153 needs a second review (if somone has a bit of time)
<zyga> sure
<zyga> good morning mvo :)
<mvo> and good morning zyga - you looked at this already
<zyga> uh, I already did
<zyga> :D
<mvo> zyga: :)
<zyga> mvo: can you look at https://github.com/snapcore/snapd/pull/6150/files
<zyga> samuele suggested a different option name
<zyga> consistency vs explicitness
<zyga> either  way I just want to merge it and move on, it's an internal option
<mvo> zyga: no opinion on the option, if it grows what it means your approach is better, if not samuele is cleaner. given that its internal I don't worry much
<pstolowski> morning
<mborzecki> mvo: pstolowski: morning guys
<mborzecki> samuele is at the sprint right?
<mvo> hey mborzecki and pstolowski !
<mvo> mborzecki: correct, he is at a sprint
<mborzecki> mvo: does #6164 replace #6156?
<mvo> mborzecki: its build on top
<mvo> mborzecki: its just one more step to cleanup things
<mborzecki> mvo: ok
<zyga> hey pawel
<mborzecki> zyga: left some comments under 6150
<zyga> looking
<mvo> sergiusens: hey, can you give me a hint about how I can resolve "Failed to pull source: unable to determine source type of './snap/patches'." ? I see this in https://github.com/snapcore/core/pull/99 and when I try to put my patches under snap/patches
<zyga> mborzecki, mvo: pushed better parsing
<mvo> zyga: to what PR?
<zyga> https://github.com/snapcore/snapd/pull/6150
<zyga> jdstrand_: hey, could you please have a look at tiny fix at https://github.com/snapcore/snapd/pull/6167
 * zyga didn't have  breakfast
<mvo> zyga: updated the review, please don't hate me :)
<mborzecki> zyga: mvo: need advice, for rhel/centos we'll need to drop a file to /etc/sysctl.d, do you think it should live in our sources somewhere under data/ or rather under packaging/fedora/ ?
<mvo> mborzecki: what does it contain?
<mborzecki> mvo: `fs.may_detach_mounts=1`, that's all
<mvo> mborzecki: do you think that is something we will reuse at some point? if so data/ sounds right if exclusive to RHEL I think the packaging is right
<mvo> mborzecki: if in doubt, data/ I think - with a comment in the file maybe?
<mborzecki> mvo: no it's RHEL kernels specific
<Chipaca> mborzecki: also plz a comment line saying why it's needed
<mborzecki> Chipaca: ack
<Chipaca> mborzecki: a couple of years from now you'll be director of our globular nano-satellites division and nobody'll remember why rhel 9 carries the file, but _you_ put it there so it stays
<mborzecki> hahah
<mborzecki> btw. let me quickly spin rhel 8 beta to check if the option is still there, otherwise it'll fail miserably
<mvo> Chipaca: heh - and good morning!
<Chipaca> mvo: :-)
<mborzecki> and it's not htere
<zyga> mvo: looking
<zyga> mborzecki: in our sources IMO
<mborzecki> zyga: right, but more like data/rhel/99-ugly-tweak.conf or packaging/fedora/99-ugly-tweak-conf?
<zyga> mborzecki: can we just have it unconditionally?
<zyga> I mean, does it hurt?
<zyga> mvo: apt-hooks test times out
<zyga> 2018-11-19 09:51:32 Error executing google:ubuntu-18.04-64:tests/main/apt-hooks :
<zyga> lots of sleep 1
<zyga> then killed
<vidal72[m]> arch uses Wl,--as-needed to minimize libs linking maybe suse does not
<mvo> mborzecki: thanks for your review for 6164 - the xdg-mime comment makes sense, what is your suggestion? leave the name as is? just filter out some chars? or always sort the globs?
<mborzecki> mvo: i think i'm leaning towards replacing + with _ in he original name and leaving them unchanged otherwise
<mvo> mborzecki: sounds good, will update the PR
<vidal72[m]> I just found that snaps are unusable when someone uses aa-notify :(
<mborzecki> vidal72[m]: isn't that an issue with audit[d] not being set up on the machine?
<mvo> vidal72[m]: do you get too many denials? or why unusalble?
<vidal72[m]> yes, too many denials
<mborzecki> vidal72[m]: which snap is causing this?
<vidal72[m]> I tested it with chromium but I think it's similar with all profiles
<vidal72[m]> snap profiles would have to 'deny' everything not alowed
<vidal72[m]> when I open files dialog I have denials for every dotfile
<zyga> mvo, mborzecki: about the parser, I was thinking how this should be and the initial short version while not perfect was short and worked, the longer version is handling various cases and also works, the medium-length proposals are ... okay, I guess but they handle less standard syntax and are not super short either. I would rather do one of the extremes (short and simple but not super smart OR one that's reasonably correct,
<zyga> simple and maintainlable, even if longer)
<zyga> I would rather do the regular parser like in snap-confine, with tests, than a not-fully-baked one you both proposed
<zyga> mvo: please pick the direction, I will do as you wish
<zyga> mvo: I also said in the PR that with a fully baked parser we could share some code with snap-confine as well
<zyga> though that is not a priority now
<mvo> zyga: I think as short as possible unless we need more, everything else feels like yagni. once we need more we can do a full solution
<mvo> zyga: in the "medium" one, what is too much? cut it down as much as needed and I think its fine
<zyga> it's almost the same length as what is in the PR now
<zyga> and I'd argue that the longer code is easier to understand and extend
<mvo> zyga: is it? i counted ~40 lines vs 15 or so, did I misread?
<zyga> both are screen-size
<zyga> not a saving
<zyga> compared to the 3 lines that the initial version that was simplistic had
<mvo> zyga: just subscribe samuele and let him decide, I think we just have different opinions on what is easier to read. I will respect whatever he decides
<zyga> mvo: can we not do this
<zyga> this will waste more time
<zyga> I'll do as you suggested
<mvo> zyga: right, I think the simplistic one is fine I would just add an extra check that not too many args are passed, iirc that was what was missing, no?
<mvo> zyga: i.e. just https://github.com/snapcore/snapd/pull/6150/commits/efef054dbe657b86e611405c36d593bec6f70c71#r234522318
<zyga> it was checking argc so not sure
<zyga> https://github.com/snapcore/snapd/pull/6150/commits/efef054dbe657b86e611405c36d593bec6f70c71#diff-dd2649824008f9aa9cd0f650906c71bfR44
<mvo> zyga: oh, sorry, let me look at the original again, iirc there was something that mborzecki  pointed out missing
<zyga> I reverted
<mvo> zyga: thanks, I prefer this over the other one for sure. if you don't want to add the check for invalid options that fine, it will still fail if snap-discard-ns --invalid-option snapName is used so no harm here (plus its internal)
<zyga> yeah
<mvo> mborzecki, pstolowski if you have a moment a second review for 6153 would be nice
<zyga> that's fine, I just want to land this and iterate
<mvo> zyga: yeah, I will approve, I don't feel super strong about this particular check
<pstolowski> looking
<zyga> I can add a check but not sure if it changes the flow now, if we pass two args and argv[1] is not --from-snap-confine it will just treat is as a snap name and fail
<mvo> zyga: yes
<mvo> zyga: (I approved based on that it will fail with an incorrect option)
<zyga> pushed
<zyga> https://github.com/snapcore/snapd/pull/6150/commits/cccc3543069dbd35fa75aa2632d99dddda15193b
<zyga> I think this capture the essence of the original review
<mvo> zyga: thank you!
<zyga> thank you both! :)
<mvo> zyga: yeah, totally fine
<pstolowski> mvo: +1, one question there
<mvo> 6156 also needs a second review :)
<zyga> mmm
<zyga> ah, interesting!
<zyga> mvo: nice idea with +
<zyga> snap+ foo
<zyga> snap+foo_bar
<mvo> zyga: yeah, this way we keep being backward compatible
<zyga> indeed
<zyga> I didn't read the diff but we should note that + is a reserved character for this purpose next to snap validation functions
<zyga> in case we forget and decide to package g++ ;)
<mvo> zyga: good point
<zyga> I think right now we only reserve what.
<zyga> dot, dash, underscore and plus?
<zyga> . for snap.app.foo separation
<zyga> dash for ... not sure
<zyga> underscore for instances and udev
<zyga> and plus for desktop and instances
<zyga> I guess dash is not reserved
 * mvo nods
<mborzecki> opening centos spread in a bit
<mborzecki> one last thing to figure out, bash 4.2.46 doesn't have 'watch -n' so cgroup-freezer test fails, need to find a workaround as it'd be nice to have this test running there
<zyga> mmm
<ogra> ppisati, i have one of the new pi3 A+ here ... had to update the firmware and u-boot in the gadget to make it work ... it works fine, BUT ... enabling the kms dtb overlay gets me a black screen (zero output) and an OOPS in dmesg ... https://paste.ubuntu.com/p/6R9zrtBkN2/
<zyga> mborzecki: you mean wait -n, right?
<ogra> ppisati, with core16 ... 4.4 kernel (1101 build)
<zyga> mborzecki: can we just wait on the PIDs?
<zyga>  mborzecki just: wait "$pid1"
<mborzecki> worth trying
<mborzecki> i'll push self checks for rhel in a separate pr
<mborzecki> or more like self check for kernel < 3.18
<ppisati> ogra: uhm, where did you get the dtb?
<ppisati> ogra: btw, i just got one
<zyga> tests are not happy today
<zyga> apt-hooks are failing more than ususual
<zyga> I'll finish one branch and look at why they fail
<mborzecki> shellchecks failing on tests? https://paste.fedoraproject.org/paste/Fwd6Maa3xgGP9w3sAjZ79w/raw
<zyga> uh
<zyga> \n strikes again
<zyga> mvo: ^
<zyga> gpio
<mborzecki> https://github.com/snapcore/snapd/pull/6168
<mborzecki> hm mup is silent again :)
<mborzecki> mvo: are you looking into the shellcheck or should i open a quick pr?
<zyga> darn, bad keypress
<mborzecki> https://github.com/snapcore/snapd/pull/6169 - shellchecks
<zyga> suspended vm
<ogra> ppisati, from the gadget as usual ... the same Sd boots just fine on a normal b+ (which should theoretically be identical ... though obviously it isnt)
<ogra> ppisati, it seems to use bcm2710-rpi-3-b-plus.dtb
<ogra> hmm, though cpuinfo shows a BCM2709
<zyga> mvo, mborzecki: I believe you reviewed the original https://github.com/snapcore/snapd/pull/6170/files
<zyga> s/facts/features/
<zyga> pushed a small test cleanup there as well
<zyga> mvo: I'll break for lunch now and then look at that apt-hooks test failure
<mborzecki> off to pick up the kids
<zyga> off for lunch
<jdstrand_> zyga: hey, done
<zyga> Hey :-)
<zyga> Thank you
<mvo> zyga: ta
<mvo> mborzecki: I look for the shellcheck now
<mvo> mborzecki: aha, you did already, thank you
<Son_Goku> zyga, did you make any progress on mkosi based base snap building?
<pedronis> mvo: zyga: hi, in the lunch break here, I saw you were discussing whether I have opinions on something, please do mark PRs either as review requests for me, or ping me from them if needed, I'll try to do a quick PR pass each day at some point if it doesn't get too deep
<zyga> Son_Goku: it's ready, I think the branch got merged upstream
<zyga> pedronis: it's done, we found a simpler solution that wasn't controversial
<zyga> obviously apt hooks don't fail when I want them to
<pedronis> zyga: ah, ok
<zyga> I'll keep trying while working on more features
<zyga> pedronis: thank you, how is the sprint going?
<pedronis> good, mostly in the intro phase still
<Chipaca> pedronis: do you want to review the epochs followup pr?
<mvo> zyga: same for me :( I ran tests for apt hooks in qemu and its fine
<pedronis> Chipaca: ah, the follow up, is it up?
<pedronis> not stricly
<Chipaca> pedronis: writing its description right now
<zyga> mvo: yeah, I will look at changing the test to fail faster and have debugging in case it happens
<mvo> hey, can anyone give me a hint about how I can resolve "Failed to pull source: unable to determine source type of './snap/patches'." ? I see this in https://github.com/snapcore/core/pull/99 and when I try to put my patches under snap/patches
<pedronis> Chipaca: shouldn't block on me, I can skim it tough, I suppose is relatively small
<mvo> zyga: I wonder if its related to a new apt
<pedronis> zyga: mvo: I wrote somethin again about that command option btw
<zyga> mvo: new apt in bionic?
<zyga> pedronis: thank you, looking
<mvo> zyga: not really that new so probably not it
<mvo> pedronis: thank you
<Chipaca> pedronis: it's 6172 fwiw
<zyga> mvo: is there any command that would ensure that commands.db is fetched?
<zyga> I don't see one in postDebug
<Chipaca> linkedin says i've been at canonical for 10 years
<Chipaca> :-)
<Chipaca> zyga: easy one is to start snapd
<zyga> mvo: would you feel OK if I add something like "snap debug ensure-commands-db" or similar?
<Chipaca> zyga: it's done every startup
<zyga> Chipaca: woot, congratulations! :)
<Chipaca> zyga: I'd be +1 to 'snap debug xyzzy' looking for snap-debug-xyzzy in PATH
<Chipaca> but also this one should be simple
<zyga> Chipaca: mmmm that sounds fine but how does that help?
<Chipaca> it doesn't
<Chipaca> :-)
<zyga> I would just like to add a debug api handler for that name
 * Chipaca is being super "helpful"
<zyga> ah :-)
 * zyga hugs Chipaca 
<Chipaca> but
<zyga> I would like to add "snap tool snap-discard-ns"
<Chipaca> zyga: don't call it ensure-commands-db
<Chipaca> zyga: and don't call ensure from it
<zyga> k
<Chipaca> zyga: call refreshCatalogs
<Chipaca> zyga: otherwise you get the timer check :-)
<zyga> thanks!
<zyga> I'll do that
<Chipaca> zyga: and you could call it refresh-catalogs :-)
<zyga> yeah, sounds great
<pedronis> Chipaca: +1 but one question
<Chipaca> anyway, i forgot to have lunch
<zyga> Chipaca: oh
 * Chipaca goes to heat up leftovers
<zyga> 6 minutes
<pedronis> Chipaca: which is not I think about code that was changed
<roadmr> hey folks! Where do ubuntu-core bugs go? something like failure to create user on device: "error: while creating user: cannot create user for "E-MAIL-ADDRESS": no ssh keys found" ?
<roadmr> mvo: do you know this by any chance? ^^
<roadmr> Wimpress: hi, are you a good person to poke on the forum re: transfers to snapcrafters?
<mvo> roadmr: in a meeting right now. does the user have ssh keys attached to the account?
<roadmr> mvo: probably not. I can wait until you're finished, no rush :)
<Wimpress> roadmr: Probably. What do you need?
<mvo> roadmr: yeah, happy to talk more then, but in general we need some keys or adding the login is not helpful (no way to login for this user)
<roadmr> Wimpress: two snap transfers *to* snapcrafters, just need ack from the team and I can process them. If you're OK with it, I'll poke you in the relevant threads
<Wimpress> Which Snaps out of interest?
<roadmr> mvo: sure thing, let me know when done and we can see
<Wimpress> I've been OOTO
<roadmr> Wimpress: mr robOOTO? :P
<roadmr> Wimpress: qxmledit is one of them, I'll find the other one
<Wimpress> popey: Do you know anything about this?
<popey> hm?
<roadmr> Wimpress: ah, the other is none other than hello-snapcrafters :D
<roadmr> a @snapcrafters forum team would be nice (like @reviewers) but that might be spammy to you folks :/
<popey> Not a bad idea actually
<roadmr> \o/
<roadmr> popey: tangent, is ev on holiday or otherwise off this week?
<popey> Yes
<roadmr> oh! bummer for me, but good for him :)
<roadmr> popey: we had a question about a small refinement for  the snap name registration form, we were hoping to get advocacy team feedback. Who else might help us with this?
<popey> snap-advocacy@canonical.com :)
<roadmr> fantastic \o/ (sorry, guess I should have known about that)
<mvo> roadmr: I'm back now - so this error - can you or someone from the store check if the user has ssh keys on the account? or is the actual issue that the error message is too cryptic?
<roadmr> mvo: thanks for getting back to me! here's the bug as filed
<roadmr> https://bugs.launchpad.net/canonical-identity-provider/+bug/1803875
<roadmr> mvo: the basic problem is that he indeed has no SSH keys: https://launchpad.net/~grayslash
<roadmr> mvo: it's definitely not a canonical-identity-provider bug, I need to move it to the appropriate project but not sure which one that would be. Maybe console-conf, which should tell users to create their account and add SSH keys before trying to register the account on the device?
<mvo> roadmr: yeah, that sounds good
<mvo> roadmr: console-conf sounds like a good choice for the bug
 * roadmr now tries to find the LP project for console-conf :D
<mvo> roadmr: try subiquity
<roadmr> yay!
<roadmr> thanks mvo, moved. I guess I could have done all this without troubling you :/ heh
<mvo> roadmr: no worries
<Chipaca> #1804006 is interesting
<zyga> hooks are still underused, thank you for finding that
<ijohnson> do y'all think that's a snapd bug or a snapcraft bug?
<zyga> it is a snapcraft bug
<zyga> snapd doesn't have this bug
<zyga> snapd needs to know about hooks to introduce plugs and slots to them
<zyga> once declared we properly attach all interfaces, as to apps
<zyga> one could argue that the bug was to allow undeclared hooks
<zyga> that feels IMO like the thing that caused the complexity to arise
<ijohnson> okay, so it sounds like by design the root level `plugs` in snap.yaml is not supposed to affect hooks?
<Chipaca> stokachu: hey. If snapd can't connect to localhost port 53, that's *probably* not a "snap store issue" you should dismiss a user's bug over
<zyga> on snapcraft side the code to always declare hooks would be simple
<zyga> but as the system stands today it's too late to do that
<zyga> ijohnson: that's incorrect
<zyga> ijohnson: top level plugs and slots affect declared hooks
<stokachu> Chipaca: what?
<zyga> but if you don't declare a hook in snap.yaml then there's nothing magically guessing that
<zyga> we *do* run discovered but undeclared hooks
<zyga> and then they don't run with any interfaces
<Chipaca> stokachu: aren't you battlemidget on https://github.com/conjure-up/conjure-up/issues/1542
<stokachu> all day
<ijohnson> I see what you mean that makes sense
<zyga> perhaps that is a snapd bug after all but it's complex to untangle now
<Chipaca> stokachu: so, yeah, that
<zyga> pstolowski: do you think we should discover hooks every time we load snap.yaml?
<Chipaca> stokachu: lookup api.snapcraft.io on [::1]:53: read udp [::1]:47619->[::1]:53: read: connection refused
<zyga> so that we can properly add slots and plugs to hooks that are not declared
<Chipaca> stokachu: that's not a snap store issue
<stokachu> yep
<Chipaca> k
 * Chipaca goes for tea
<roadmr> Teapaca?
<zyga> chai :)
<roadmr> chaipaca? :)
<roadmr> zyga: I'm curious about what the blob of molten plastic was in the end
<zyga> roadmr: it didn't fail this time
<zyga> roadmr: but I had it fail to print sometimes
<zyga> the object would detach from the heatbed
<roadmr> ouch
<zyga> the hot end would grab a hold of it by accident
<zyga> it would melt and "stick" to the extruder
<pstolowski> zyga: don't we do already? see info.go - ReadInfoFromSnapFile -> addImplicitHooksFromContainer
<zyga> the extruder kept oozing stuff
<roadmr> sounds messy
<zyga> roadmr: yes :-)
<stokachu> Chipaca: we good?
<zyga> pstolowski: https://bugs.launchpad.net/snapcraft/+bug/1804006
<zyga> Chipaca: btw, we do add interfaces to hooks
<zyga> pstolowski: perhaps it's out of sync
<zyga> pstolowski: we load yaml, attach plugs and slots to hooks
<zyga> then we notice more hooks on disk
<zyga> and we don't do anything else to connect the dots
<Chipaca> stokachu: dunno. Bug's still closed at your end, but I don't know what the issue is about
<Chipaca> stokachu: just know it's not in the realm of things that we can help with
 * zyga needs to catch a bus now
<Chipaca> zyga: take the XL butterfly net
<stokachu> Chipaca: then nothing for you to continue to worry about then, we good
<Chipaca> stokachu: k
<mborzecki> https://github.com/snapcore/snapd/pull/6173 - sanity checks for centos/rhel
<mvo> zyga: the apt-hook error is a 403 from the api
<pstolowski> zyga: ah, i see now, i had to read a little bit of the backlog, and look into the code. indeed.
<pstolowski> seems to be the case
<ppisati> sergiusens: is there a way to avoid building in a VM? e.g. --no-multipass or something? i'm already running my snapcraft tests inside a vm FWIW
<roadmr> ppisati: if you're using snapcraft 3.0, use snapcraft build --destructive-mode
<ppisati> roadmr: it still tries to launch a VM
<roadmr> ppisati: sounds like a bug to me, as that's the description for --destructive-mode :(
<ppisati> :(
<ogra> just switch back to 2.0 ;)
<ppisati> roadmr: nm, i got it working
<ppisati> ogra: too late :)
<ppisati> *to work
<Chipaca> what
<Chipaca> 's going on with the apt-hooks test?
 * zyga is stuck in traffic
<zyga> mvo: is that something we retry?
<Chipaca> ah, store 403ing
<zyga> mvo: is that something we retry?
<zyga> mvo: is that something we retry?
<Chipaca> zyga: did you purposely send that three times, or is your client not only breaking tcp by doing out of order but also by repeating messages?
<mvo> zyga: haha
<mvo> zyga: I don't know, I was looking and then got side-tracked
<mvo> Chipaca: I suspect its a demonstration of the issue (or a funny coincidence ;)
<Chipaca> mvo: yeah i was wonderingering
<mvo> zyga: in any case, we need to retry but if the store is really unhappy not much we can do :/
<mvo> Chipaca, zyga probably worthwhile to ping the store about the catalog update 403 (just in case). I will be off now for a bit to play hockey though :)
<Chipaca> mvo: on it
<Chipaca> mvo: (half an hour ago)
<Chipaca> mvo: happy hockeying
<zyga> back home
<zyga> mvo: ack
<zyga> Chipaca: re
<zyga> Chipaca: so what's the state of catalog refresh issue
<zyga> should I finish the debug command? I guess it doesn't hurt to have
<Chipaca> zyga: sorry, what issue? i saw you talking about the debug command but not why you were looking into that
<zyga> Chipaca: yes, I'm writing a debug command
<zyga> I'm asking if that helps in this particular issue or if you know more about the store 403
<Chipaca> zyga: the issue here is clear
<Chipaca> zyga: 'got unexpected HTTP status code 403 via GET to "https://api.snapcraft.io/api/v1/snaps/names'
<zyga> aha
<roadmr> yes, totally the store's fault :( sorry :( I'm looking into it
<ahasenack> is subiquity the ubuntu core installer as well?
<ahasenack> just checking if this is assigned to the right project: https://bugs.launchpad.net/subiquity/+bug/1803875
<roadmr> ahasenack: I moved that there; I believe console-conf is what handles that part of the process and a package search pointed to subiquity as the source
<ahasenack> ok
<ahasenack> I only know subiquity as being the server installer, that's why I asked
<roadmr> indeed, it also seemed odd to me
<roadmr> ahasenack: https://packages.ubuntu.com/bionic/console-conf
<mikedld> Chipaca: got you message here https://forum.snapcraft.io/t/sharing-files-via-tmp/1613/23 but would still like to know of any (acceptable given my description there) alternatives...
<zyga> mikedld: hey, snapd aims to coordinate application interdependencies, such as sharing files or sockets via /tmp
<zyga> mikedld: this is so that it can ensure that there is no hidden dependency between one snap and another
<ogra> mikedld, sadly what you want isnt there atm
<zyga> mikedld: if you tell us more about the kind of use case you are after we will be able to help you better
<zyga> mikedld: perhaps you just need an interface
<zyga> mikedld: perhaps this is not supported by design and we just need to be clear about that
<ogra> snaps can write to their private /tmp, to the users ~/snap or to /var/snap/<snapname> ... none of these is easily shareable among multiple users
<ogra> zyga, an interfaces wouldnt help
<ogra> *interface
<ogra> the question was initially about sharig data among multiple users IIRC
<ogra> *sharing
<mikedld> zyga: well, what I want is to be able to tell, in two different programs (and thus two different processes) whether they are running on the same machine. given that one program connects to the other via TCP socket, what I'm doing now is passing some ID via the socket and then checking whether the same ID exists in the form of a file in /tmp
<ogra> we'd need another dir like /home/snap/<snapname> where all users have access or some such
<zyga> mikedld: does /etc/machine-id help?
<zyga> you can ask dbus about it
<ogra> do we bind that into the core snap ?
<zyga> https://www.freedesktop.org/software/systemd/man/machine-id.html
<ogra> (would he see the host one ?)
<mikedld> on Linux (or even a specific flavor of it), maybe, but the code is cross-platform
<zyga> it is the host one
<ogra> ah, cool
 * ogra only knows how it works on UC ... 
<zyga> https://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-peer
<zyga> mikedld: as things stand today /tmp is private for each snap application
<zyga> so two users running one snap will see the same /tmp
<zyga> but one user running two snaps will "see" separate empty /tmp's
<mikedld> it's not highly critical but being unable to tell if they're on the same machine will affect UX in that the program will e.g. not display a button to show file selection dialog next to (or instead of) the path input field
<zyga> mikedld: is it the case that multiple separate snaps need to interoperate?
<mikedld> yes, putting everything into a single snap is not a good option. and as I mentioned, one of two programs may not even be snapped if one builds it from source or whatever
<zyga> if you use a different path (not /tmp) and you use an interface this could be solved (we can implement the interface)
<mikedld> if it will be the same path for all the users then this would be okay if it's not /tmp
<zyga> yep
<mikedld> I'm even okay with being required to specify a filename mask if necessary
<mikedld> so what do you need from me for this to gain traction?
<zyga> Chipaca: around>?
<zyga> https://www.irccloud.com/pastebin/uOgifp6z/
<zyga> I'm super slow but does this look sensible?
<zyga> Chipaca: code in https://github.com/snapcore/snapd/pull/6174
<mikedld> zyga: I have no idea what's going on there but there's a typo in the new file on line 31 :)
<zyga> mikedld: oh, looking
<zyga> thanks, fixing :)
<mikedld> it passes my review now, feel free to merge :-P
<mwhudson> i am confused by filesets/organize/stage :(
<zyga> mwhudson: not the only one
<zyga> but I think degville is working on documenting those
#snappy 2018-11-20
<mborzecki> morning
<mborzecki> mvo: hey
<zyga> Hey
<mvo> hey mborzecki and zyga
<zyga> mvo: I sent a small tweak to the apt hook test
<mborzecki> zyga: hey
<mborzecki> plenty of reviews, unfortunately all are blocked by the tests :/
<zyga> Yeah
<mvo> zyga: yeah, I approved it already
<mvo> zyga: nice one
<mvo> zyga: I think we still need a test that checks if we update the catalog on startup
<mvo> zyga: but this one is nice as it adds clarity (and clean messages)
<mvo> mborzecki: yeah, tests are very unhappy
<mvo> zyga, mborzecki did anyone talk to the store last evening about the 403?
<zyga> Yes
<zyga> Daniel is on this
<mborzecki> great
<zyga> I was thinking that perhaps we should ask for a bug report to track
<mvo> great
<zyga> Even if only the bug is public
<zyga> I need to take Bit out
<zyga> Brrr
<zyga> See you soon
<mwhudson> is running hello-world.evil as root supposed to hit the permission denied error?
<mvo> mwhudson: yes
<mwhudson> because i get the permission denied as a regular user on debian
<mwhudson> but not as root
<mwhudson> (debian testing)
<mvo> mwhudson: looking
<mwhudson> mvo: tbh i'm surprised i get it at all on debian :)
<mwhudson> i didn't think the kernel had all the apparmor snapd needed
<mvo> mwhudson: this is what I see on ubuntu https://paste.ubuntu.com/p/Xy8BKNYwkT/
<mvo> mwhudson: [509022.132463] audit: type=1400 audit(1542697004.011:11343): apparmor="DENIED" operation="mknod" profile="snap.hello-world.evil" name="/var/tmp/myevil.txt" pid=29003 comm="evil" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
<mborzecki> mwhudson: can you post the output of `snap debug sandbox-features` somewhere?
<mwhudson> mborzecki: http://paste.debian.net/1052415/
<mvo> mwhudson: hm, those apparmor options looks good, and yet hello-world.evil is not giving you an error? anything interessting in dmesg (I guess not) when you run this?
<zyga> mwhudson: as a user, do you get a denial?
<zyga> AFAIK we didn't enable the feature outside of arch and tumblweed
<mwhudson> no, nothing in dmesg
<mwhudson> for either user or root
<zyga> right
<zyga> maybe the non-root case is just failing on regular permissions?
<zyga> mvo: are things still failing on the store?
<mwhudson> zyga: hah yes, it failed as a user because i'd run it as root first...
<zyga> \o/
<zyga> mwhudson: having said that I  think we could enable apparmor on debian now
<mwhudson> zyga: i though the plan was to interrogate the kernel and decide on that, not based on distro
<mvo> zyga: we had one successful run
<mwhudson> zyga: but yes
<zyga> yes but it's not just the kernel
<zyga> we check the kernel
<zyga> but we also check the distribution
<zyga> because apparmor userspace also matters and that was a simpler check
<mborzecki> zyga: hm another sysctl tweak needed for rhel, max_user_namespaces is 0 by default :/
<mwhudson> ah
 * zyga wonders if 4.20 will have everything
<zyga> user namespaces?
<zyga> can you tell me more about that
<zyga> we don't use that
<zyga> mwhudson, mborzecki: I'd love some eyes on https://github.com/snapcore/snapd/pull/6111
<zyga> I know it's probably most distant to being useful for debian at this stage
<zyga> but that's the eventual goal, cut packaging cruft by using packaging/snapd.m
<zyga> snapd.mk
<mwhudson> zyga: "Fortunately the makefile world is much saner" i feel sorry for you!
<zyga> haha, because of RPM of because thinking Makefile is saner :) ?
<zyga> I mainly cannot understand how RPM macros can be this crippled
<zyga> they are an oozing mess IMO
<mborzecki> zyga: we don't but there's a test to check whether snaps can do, see tests/regression/lp-1618683
 * zyga looks
<mborzecki> zyga: otoh, it's probably ok if users enable it themselves when needed
<zyga> hah
<zyga> that's a very specific test :-)
<zyga> mborzecki: the test can also toggle that IMO
<zyga> mborzecki: it will also self-document
<mborzecki> fair enough :)
<zyga> I think this is a test where we used to break LXD
<pstolowski> morning
<pstolowski> zyga: i'm going to work on the yesterday's implicit hooks+interfaces issue, ok?
<zyga> pstolowski: sure, thank you
<zyga> I can close that tab :)
<pedronis> zyga: hi, I saw you are looking into catalogs, afaik  /names was not working in the store last night and fixed just this morning
<zyga> hey
<zyga> yep, I know, I talked to daniel about it
<zyga> I improved the test to fail faster with a clear error message
<zyga> now back to ongoing tasks, trying to land stuff that's pending
<pedronis> zyga: ok, np, just making sure it was on the store side
<pedronis> wasn't sure if people pinged
<zyga> yep
<mborzecki> zyga: can you look at https://github.com/snapcore/snapd/pull/6168 later on?
<zyga> mborzecki: sure
<zyga> oh
<zyga> I did, I have pending review comments
<mborzecki> heh :) post'em
<mborzecki> zyga: i reverted the snap-mgmt piece
<mborzecki> btw. i installed kde on my laptop yday, the theming is off too, i have it set up to use the breeze theme for gtk apps and it's clearly using a different theme as well as font size
<zyga> mborzecki: done
<zyga> pedronis: I'll land 6150 with --from-snap-confine and do a small PR on top to rename that to --inherit-lock so that we don't lose a test slot
<zyga> I need a 2nde review on https://github.com/snapcore/snapd/pull/6148
<zyga> mvo did one
<zyga> +0, -7 branch
<zyga> mborzecki: could you look at https://github.com/snapcore/snapd/pull/6111
<zyga> mborzecki: if not for centos, I'd love to have this for the next suse release
<mborzecki> https://github.com/snapcore/snapd/pull/6168 - centos & spread is green :)
<mvo> mborzecki: nice!
<mborzecki> mvo: and needs a 2nd review
<mvo> mborzecki: yeah, neck-deep in fontconfig again right now :(
<mborzecki> mvo: np, i'll poke pstolowski
<mborzecki> pstolowski: would you like to review 6168?
<pstolowski> mborzecki: sure
<mborzecki> pstolowski: ta
<zyga> brb coffee
<zyga> and re
<zyga> hey Chipaca, cachio
<zyga> SIGILL during go build https://www.irccloud.com/pastebin/n7OW8M6x/
<zyga> mvo: ^
<zyga> first time I saw this
<zyga> 18.10
<cachio> zyga, running a test?
<cachio> hey
<zyga> not even that, just building
<zyga> not a test, building snap-seccomp
<Chipaca> mvo: tinyproxy is growing up ð
<mvo> Chipaca: heh, yeah
<mvo> Chipaca: maybe we need to rename it to lesstinyproxy
<Chipaca> mediumproxy
<Chipaca> midproxy?
<mvo> lol
<cachio> zyga, I'll try to reproduce it
<zyga> Chipaca: dwarf proxy ;)
<Chipaca> zyga: yeah... no, not that
<zyga> right? :)
<mvo> cachio: good morning! are things good for promotion of 2.36.1 to stable?
<mvo> did we loose mup again?
<mvo> mup: hello
<zyga> Chipaca: https://github.com/minimaxir/big-list-of-naughty-strings :D
<cachio> mvo, hi
<Chipaca> zyga: yeah :-)
<Chipaca> zyga: try setting that as the description of your snap
<cachio> mvo, everything is ready
<cachio> mvo, let me check with store team
<mvo> cachio: awesome, thank you
<cachio> mvo, np
<zyga> mborzecki: remember this bug? https://github.com/snapcore/snapd/pull/6159 :D
<zyga> it's green
<mborzecki> heh, let me review that
<zyga> it's not that short as I made more changes to tests and merged two functions together for simplicity
<zyga> but the spread test is nice and much better than before
<zyga> thanks!
<zyga> one more to the done lane :)
<zyga> Chipaca: hey, can you look at https://github.com/snapcore/snapd/pull/6174 - I'm not sure if this is done right wrt layering in the daemon
<Chipaca> zyga: in 5
<zyga> mainly about how to get to refresh catalogs from api.go
<zyga> sure, thanks!
<diddledan> who can I talk to about a missing repo in my build service dashboard?
<diddledan> specifically it's one that I've previously added that has disappeared
<zyga> diddledan: not sure, anyone from the store I presume but not sure who's online now
<diddledan> I need to trigger a build so I went looking for it, but can't find it
<diddledan> the snap is still in my store dashboard, so I figured the store is correct
<diddledan> it's only the build service that's missing it
<diddledan> I tried to re-add it and it just sits there doing nothing
<diddledan> just sits there with the spinner spinning: https://usercontent.irccloud-cdn.com/file/LDUEyS53/image.png
<mborzecki> opened a forum topic about theming under kde: https://forum.snapcraft.io/t/gtk-app-themes-under-kde/8597 (cc popey)
<popey> diddledan: I'd file a bug https://github.com/canonical-websites/build.snapcraft.io/issues
<diddledan> popey: interesting that you've filed a bug with a similar console log from the browser from when I try to re-add the repo to build: https://github.com/canonical-websites/build.snapcraft.io/issues/1155
<popey> :)
<popey> Lukewh: ^
<Lukewh> ð
<diddledan> here's my bug: https://github.com/canonical-websites/build.snapcraft.io/issues/1175
<cachio> mvo, 2.36.1 is stable
<mvo> cachio: \o/
<cachio> mvo, wiki updated too :)
<Chipaca> mvo: do you remember the user request that caused us to look at `snap list --format=....`?
<Chipaca> mvo: found it
<mvo> Chipaca: ok
 * zyga considers lunch
<zyga> mvo: did you see https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1804186
<mvo> zyga: yes, I think this will be fixed with 6156
 * zyga goes for lunch 
<zyga> yeah, I just wanted to have this on your radar
<zyga> heh
<zyga> I found some nice piece of garbage
<cachio> mvo, hey, apt-hooks test failing because /var/cache/snapd/commands.db does not exist on ubuntu 18.04
<Chipaca> mvo: are the 2.36 and 2.37 lanes 'done' lanes, or 'doing' lanes?
<Chipaca> and what's the relation between 19.04 done and 'done' done
 * Chipaca is lost in a maze of lanes, all alike
<cachio> mvo, I see this error https://paste.ubuntu.com/p/SxD8Jr2XJb/
<Chipaca> cachio: store names endpoint 403'ed well into last night
<Chipaca> or timed out, yes
<zyga> Chipaca: they are done lane
<cachio> Chipaca, this is happening now too
<zyga> but scoped to release version
<cachio> I just reproduced that
<Chipaca> cachio: really? seems to be working here :-(
<cachio> Chipaca, it is happening sporadically in master
<Chipaca> cachio: 'timeout reading body', or 403?
<cachio> I just executed that on ubuntu-18.04-64 with -repeat 50
<cachio> Chipaca, the timeout
<Chipaca> cachio: locally, or google cloud?
<cachio> Chipaca, https://paste.ubuntu.com/p/2xsHgkgyNs/
<Chipaca> i'm seeing 8s, which is very close to the 10s timeout we have
<cachio> on google cloud
<cachio> running the test apt-hooks
<Chipaca> ok
<Chipaca> zyga: I've renamed them to say Done, then
<zyga> Chipaca: I see now, nice
<zyga> clearer
<Chipaca> cachio: it's still a store issue though; not much we can do from our code
<zyga> btw
<Chipaca> zyga: i'm not really sure the 2.36 and 2.37 were done vs doing
<zyga> this 5K monitor really pays for itself when you use our trello board :-)
<Chipaca> zyga: but titling them will make it clearer if they weren't (somebody'll shout)
<zyga> Chipaca: those were done
<zyga> yep
<cachio> Chipaca, nice, thanks
<Chipaca> cachio: when exactly were those tests run?
<Chipaca> wgrant wants to know :-)
<cachio> Chipaca, I saw that error on travis
<Chipaca> cachio: that's not an answer :-)
<wgrant> There wree 403s until I woke up about four hours ago. There were two brief periods of timeouts about an hour ago as fallout from the core release.
<cachio> wgrant, it failed few ours ago on travis
<cachio> Chipaca,
<wgrant> It's a criminal offense in most jurisdictions to report store problems without specific error messages and times.
<Chipaca> 'about an hour ago' matches that fallout window
<cachio> wgrant, Chipaca then I rexecuted that failed test from my machine few minutes ago
<zyga> lol
<zyga> this should go to quotes :)
<cachio> and I could reproduce it
<Chipaca> cachio: what's your ping to api.snapcraft.io?
<cachio> Chipaca, wgrant I reproduced the error running from my machine the srpead test 30 minutes ago
<cachio> Chipaca, the test was executed on a gce instance btw
<Chipaca> ah
<Chipaca> controlled locally, but run on gce, got it
<cachio> yes
<mborzecki> off to pick up the kids
<cachio> Chipaca, spread -debug -repeat 50 google:ubuntu-18.04-64:tests/main/apt-hooks
<cachio> I reproduced that by running that test
<cachio> on master
<cachio> mborzecki, centos in
<mvo> Chipaca: 2.36,7 is done
<ahasenack> hi, is snap supposed to honor the https_proxy env var?
<ahasenack> I'm exporting it just before a snap install, but it's being ignored
<ahasenack> (no sudo, I'm root already)
<mvo> sergiusens, kyrofa hey, can someone help me with "Failed to pull source: unable to determine source type of 'fc/'." ? context is https://github.com/snapcore/core/pull/99 - what is puzzling is that this works in https://code.launchpad.net/~mvo/+git/fontconfig-multi-cache
<ahasenack> https://pastebin.ubuntu.com/p/j7pwP4brsS/
<mvo> ahasenack: its complicated - snapd will honor it but the snap command will not pick it up and transfer it to snapd (if that makes sense)
<mvo> ahasenack: so "http_proxy=... /usr/lib/snapd/snapd & ; sudo snap install foo" would work (in theory)
<ahasenack> I see, it's the daemon
<mvo> ahasenack: we could make this work by simply reading http_proxy in snap (the cli) and when talking to the daemon setting it for these requests
<ahasenack> installing lxd suddenly became harder
<mvo> ahasenack: this would require a bit of code and a design discussion. I think its what most users expect though
<ahasenack> looks like I can add it to /etc/environment
<ahasenack> and restart snapd
<ahasenack> EnvironmentFile=-/etc/environment <-- because of that in its service file
<mvo> ahasenack: yes, or "snap set core https.proxy=..."
<mborzecki> cachio: pstolowski: thanks!
<Chipaca> mvo: and was I right in thinking that the bare "Done" was "Done on master"?
<mvo> Chipaca: done for things that cannot be associated with a release
<niemeyer> Heya
<niemeyer> I'm updating the blender snap during intervals here at the sprint
<niemeyer> I just found what seems like another minor bug on the handling of installation flags:
<niemeyer> % sudo snap install blender_2.79b_amd64.snap --dangerous
<niemeyer> error: cannot perform the following tasks:
<niemeyer> - Mount snap "blender" (unset) (snap "blender" requires classic confinement)
<niemeyer> Looks like classic was ignored until too late
<niemeyer> Chipaca: ^
<Chipaca> niemeyer: yes, i noticed that as well. it's just how we handle the error, fwiw
<Chipaca> installPath doesn't do the handholding install does
<Chipaca> and the blurb is slightly off for installPath
<Chipaca> but it needs to do something
<Chipaca> i'll get to it
<Chipaca> currently on the warnings-as-yaml thing
<niemeyer> Thanks!
 * Chipaca lags
<niemeyer> sergiusens: snapcraft is doing something curious with multi-line strings
<niemeyer>   \ compositing and motion tracking, even video editing and game\ncreation.\n\nBlender\
<niemeyer>   \ is a public project, made by hundreds of people from around the\nworld; by studios\
<niemeyer> sergiusens: That's ending up in meta/snap.yaml
<mvo> cachio: do you happen to know the status of the 2.35.5 SRU? is all the validation done from our side?
<cachio> mvo, checking
<cachio> mvo, last sru done is for 2.35.4
<cachio> I can make 2.35.5 today
<mvo> cachio: great, thanks
<mvo> cachio: lets try to get it out of the door, I pushed 2.36 into the sru queue but it can sit there
<cachio> mvo, sure, I'll complete it todya
<mvo> cachio: thank you
<niemeyer> jdstrand: Heya
<jdstrand> niemeyer: hi :)
<niemeyer> jdstrand: Apparently the store reviews are blocking  the title field:
<niemeyer> "  - unknown entries in snap.yaml: 'title'"
<niemeyer> sergiusens: This is an issue as well for snapcraft ^
<niemeyer> Both license and title are being blocked
<jdstrand> niemeyer: oh, huh. when was that added?
<niemeyer> jdstrand: Curiously, it's been a while
<jdstrand> that is curious
<niemeyer> jdstrand: I think we didn't really notice because most people are either setting it in the store UI directly, or don't care
<jdstrand> niemeyer: is this something where snap.yaml doesn't know about it but snapcraft is passing it through cause it is in snapcraft.yaml? of is it legitimate for snap.yaml?
<jdstrand> s/of is/or is/
<niemeyer> jdstrand: It's been legitimate in snap.yaml for long now
<jdstrand> huh
 * jdstrand shrugs
<jdstrand> I'll fix it
<niemeyer> jdstrand: Again, I think it's just that most people that care about the title has been editing the whole metadata directly in the web UI
<niemeyer> jdstrand: So bypassing the review
<niemeyer> jdstrand: It gets down to snapd on install
 * jdstrand nods
<jdstrand> I see it in info_snap_yaml.go
<jdstrand> I'll double check is anything else is missing while I'm at it
<jdstrand> everything else is there
<mborzecki> mvo: https://paste.ubuntu.com/p/vbJPDwH5YF/
<cachio> mvo, http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#snapd
<cachio> not tests executed on bionic for 2.35.5
<niemeyer> jdstrand: Thanks! Can we get it through as well please
<niemeyer> jdstrand: I also have 2.80 behind it
<cachio> mvo, Not touching package due to block request by freeze (contact #ubuntu-release if update is needed)
<jdstrand> niemeyer: yes, I'll review the queue
<niemeyer> jdstrand: Danke!
<sergiusens> niemeyer: thanks. I am off today but will work on title tomorrow (license should work without passthrough in 3.0). I will look at the code or ask Chipaca about rules for title since he has been doing the snap pack validation work
<sergiusens> niemeyer the line breaks might be related to the use of | for description, we recently switched it to >. Thanks to sparkiegeek
<niemeyer> sergiusens: | is what we want in general I believe
<niemeyer> sergiusens: In either case, that looks like a longstanding issue.. I have pretty old snaps that have the description mangled like that
<jdstrand> roadmr: hi! can you pull r1156 of the review tools?
<roadmr> jdstrand: howdy! totally, will do
<jdstrand> thanks
<sergiusens> jdstrand: I was not aware title made it in. But do tell me when you start allowing it so we do not block new users when using it. Passthrough should work in the meantime.
<jdstrand> niemeyer: both are approvied
<jdstrand> sergiusens: my ping to roadmr is for that
 * sergiusens goes back to being off
<jdstrand> sergiusens: so feel free to commit at your convenience. and enjoy your day off :)
<mborzecki> zyga: can you try this in a vm? https://gist.github.com/bboozzoo/d4b142229b1915ef7cc0cf8593599ad9 i can reproduce the mount problem quite reliably (you need to have bc installed)
<mborzecki> just systemd and mount units
<kyrofa> mvo, I just pulled that core PR #99, and those parts pull fine for me
<kyrofa> Did you sort it out?
<niemeyer> sergiusens: Let's please catch up when you are back. Using ">" is probably a bug too, but likely not it. I'll report a bug.
<mvo> kyrofa: it fails in LP
<mvo> kyrofa: it works locally
<mvo> kyrofa: I'm very confused, it also works in a very similar setup (https://code.launchpad.net/~mvo/+snap/fontconfig-multi-cache) where it works
<mvo> kyrofa: slightly desperate as it blocks some important work
<kyrofa> Yeah I think I know what work that is :)
<niemeyer> https://bugs.launchpad.net/snapcraft/+bug/1804258 https://bugs.launchpad.net/snapcraft/+bug/1804256
<niemeyer> mup: Are you okay?
<niemeyer> Hmm.. freenode seems to be still blocking
<kyrofa> mvo, can I see a LP log of the failure?
<niemeyer> mup: Now?
<niemeyer> mup: Now?
<mup> niemeyer: I really wish I understood what you're trying to do.
<niemeyer> Yeah.. :/
<niemeyer> Need to improve mup to identify itself automatically to nickserv
<mvo> kyrofa: https://travis-ci.org/snapcore/core/builds/457417770?utm_source=github_status&utm_medium=notification
<mvo> kyrofa: and https://github.com/snapcore/core/blob/master/.travis.yml is the build script
<mvo> kyrofa: maybe some outdated version of snapcraft or something?
<kyrofa> mvo, https://github.com/snapcore/core/blob/master/.travis.yml#L22
<kyrofa> Do you intend to copy the fc dir there?
<mvo> kyrofa: !!!
<mvo> kyrofa: it looks like this script needs some serious love
<mvo> kyrofa: thats exactly it, thank you so much
<kyrofa> Haha, no problem
<kyrofa> mvo, that error is a bit misleading, please do log a bug when able
 * cachio lunch
<zyga> mborzecki: re
<zyga> mborzecki: trying
<zyga> mborzecki: does it brick the system? :)
<zyga> mborzecki: running on 16.04
<zyga> mborzecki: no luck yet
<zyga> I can add more cores
<zyga> (or less cores, need to check what's the key)
<zyga> currently running with 4 cores
<zyga> mborzecki: no luck, restored snapshot
<zyga> going to 1 core
<zyga> mborzecki: I got "3: disk-16 missing"
<cachio> mvo, no 2.35.5 on proposed/bionic
<cachio> mvo, is it agreed?
<zyga> mborzecki: running for a longer while I see more "disk missing" errors
<mborzecki> zyga: try 18.10 or fedora or arch
<zyga> mborzecki: I'll jump into this tomorrow, I'm deep in something else now
<zyga> mborzecki: but it failed on 16.04 too
<zyga> when I went to one core it was failing faster
<mborzecki> zyga: takes one run to reproduce on 18.10 :)
<zyga> mborzecki: good
<zyga> mborzecki: I think it's not systemd
<zyga> I can show you where the lock is missing
<zyga> but we can hack that tomorrow
<zyga> I _suspect_ it's a security bug
<zyga> so either fix quickly or be considerate
<mup> PR snapd#6177 opened: interfaces: draft of LimeSDR hotplug interface <Hotplug ð> <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6177>
<roadmr> hi jdstrand ! hey is it possible to make a plug in one snap automagically connect to another snap's slot? I know the IDs of both snaps.
<mup> Bug #1804281 opened: Cannot refresh snaps if home is in NFS with root_squash <Snappy:New> <https://launchpad.net/bugs/1804281>
<niemeyer> jdstrand: Thanks for the approvals
<niemeyer> jdstrand: Looking into it now.. I might have a new revision soon
<Chipaca> dpkg-shlibdeps: error: no dependency information found for /lib/x86_64-linux-gnu/libpthread.so.0 (used by debian/snapd/usr/lib/snapd/snap-failure)
<Chipaca> WAT
 * cachio afk
<mvo> kyrofa: https://bugs.launchpad.net/snapcraft/+bug/1763394 is a bug about this, I will amend it
<mup> Bug #1763394: cleanbuild gets confused with directory source type <Snapcraft:Triaged by sergiusens> <https://launchpad.net/bugs/1763394>
<jdstrand> pstolowski|afk: fyi, I saw and am still digesting your hotplug/autoconnect forum post
<mwhudson> is there a snapd api i can hit to answer the question "will snap refresh --channel=$foo $bar do anything"?
<mwhudson> there's /v2/find?select=refresh but that won't be correct if the snap is not tracking $foo already
<mwhudson> another question!
<mwhudson> if a snap revision is in two channels $foo and $bar and currently tracking $foo, will snap refresh --channel=$bar restart services from the snap?
<mwhudson> i guess not
<Chipaca> mwhudson: o/
<Chipaca> mwhudson: no there isn't a "dry run"
<Chipaca> mwhudson: there is 'snap refresh --list' which is something almost completely but not entirely different
<Chipaca> why is there a --list and not a --dry-run?
<Chipaca> probably "we r dum"
<Chipaca> but also probably hysterical reasons
<Chipaca> anyhow, came here to close the window because dmesg is spamming me about nvidia dropping off the bus and every character takes 2 seconds to appear
<Chipaca> that was fun to write
<Chipaca> bbiab reboot
#snappy 2018-11-21
<mup> PR snapd#6176 closed: snap: check max description length in validate <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6176>
<mvo> zyga: hey, 5845 is ready for a re-review (you commented some days ago there)
<mborzecki> morning
<mvo> hey mborzecki
<mborzecki> mvo: how are the tests looking today? still mostly red?
<mvo> mborzecki: I saw a green one
<mvo> mborzecki: 5845 which also needs a second review
<mvo> mborzecki: but also some reds :(
<mvo> mborzecki: I just retriggered 6156, that should tell us about the testing weather today
<mborzecki> heh :)
<zyga> o/
<zyga> mvo: looking
<zyga> 1K wow
<mvo> zyga: 1k?
<zyga> about 1K of diff
<zyga> but no worries, reading
<mup> PR snapd#6178 opened: snap,snap-exec: add SNAP_DEBUG_START_TIME environment <Created by mvo5> <https://github.com/snapcore/snapd/pull/6178>
<mvo> zyga: heh, things look pretty good with snap_debug_start_time set, it seems we take only ~0.1sec for brave to setup our stuff
<zyga> nice
<zyga> so what is slow?
<mvo> zyga: I think the wrappers, I'm on it, not sure conclusively yet
<zyga> super
<mvo> zyga: slowly working my way up :)
<zyga> I will finish this review, garden my branches and work more on perf monitoring
<zyga> while not immediately helpful to your cause it will allow us to do this more or less automatically down the line
<mborzecki> mvo: wonder if something like snap run --strace='--raw -e execve -r' <snap.app> would work
<mvo> mborzecki: hm, good idea, maybe no need for a special tool.
<mborzecki> looks a bit noisy for gnome-calculator
<mvo> mborzecki: heh, its even worse with brave :)
<mvo> mborzecki: forkstat is what I'm currently using
<mborzecki> mvo: well, with gnome calc, there's clearly lots of stuff happening
<mvo> mborzecki: yeah, tons
<mvo> mborzecki: including update-mime-database which is ~2s here
<mborzecki> mvo: gnome-calcualtor https://paste.fedoraproject.org/paste/rCbAYtyL02YLJ9xm~-pTZg/raw
<mborzecki> heh, funny how not using absolute path makes multiple execve() calls
<zyga> mvo: reviewed
<mborzecki> hm xdg-user-dirs update takes less time than head -c0 calls
<mvo> zyga: ta
<zyga> mvo: I'm sorry that it is not a +1 yet
<zyga> let me know if you want to talk about any of this
<mvo> zyga: no worries, thanks for the review, the comments look really useful
<mborzecki> mvo: on my machine, each call to mkdir/ln/ls/head/date takes 15ms+ (~90 calls), glib-compile-schemas ~100ms, gdk-query-pixbus-loaders ~700ms, update-icon-caches is called twice ~30ms total
<mborzecki> mvo: that's for gnome-calculator
<zyga> mborzecki: that's all in shell, right?
<mborzecki> mvo: yes
<zyga> a shell program making those calls?
<mvo> mborzecki: whats the total overhead for you?
<mborzecki> mvo: ~2s
<mborzecki> mvo: but that's ssd, multi core and so on :P
<mborzecki> mvo: i'll try with dropped caches
<pstolowski> mornings
<zyga> (mac chime)
<zyga> hey pawel
<pstolowski> :)
<pstolowski> can anyone make a quick test and confirm if this trivial change https://pastebin.ubuntu.com/p/zSbp4VKkgq/  causes massive mem leak and oom with go test inside snap/ dir (make sure you're ready to stop it before your desktop gets unresponsive)
<mvo> mborzecki: ta, I see ~2s here as well (also multi-core, ssd etc)
<mvo> pstolowski: good morning!
<zyga> yep, checking
<mborzecki> mvo: hm dropped caches, removed $SNAP_USER_DATA and so on, g-c takes visibly longer to start, but it's not reflected in desktop helpers, the change there is minimal
<zyga> So what is the slow part?
<mborzecki> mvo: https://paste.fedoraproject.org/paste/w-X6E2U7OKjM9n0210BGTA see line 644, there's a bunch of processes started, but they don't exec
<zyga> Apart from fonts
<mborzecki> mvo: some glib/gtk thing?
<zyga> To compute 2+2 you need to fork 100 times
<mborzecki> g_async_*
<mborzecki> maybe is spawning gjs under the hood :)
<mvo> mborzecki: looking
<mvo> mborzecki: why does a pastebin require 7 script to work - oh well
<mvo> mborzecki: hard to say but I would not be surprised if that was some sort of gjs
<pstolowski> zyga: any findings?
<pstolowski> mborzecki: you landed some improvements for diffing on failing go tests some time ago; what's the approximate location of this diffing code?
<mborzecki> pstolowski: that'd be in check.v1
<mborzecki> pstolowski: checkers.go, there's formatUnequal()
<pstolowski> mborzecki: got it, thanks!
<pstolowski> mborzecki: heh, it seems it's related to the leak i'm seeing
<pstolowski> mborzecki: i removed that entire logic
<pstolowski> mborzecki: getting just a few test failures now (expected)
<mborzecki> pstolowski: is that in interfaces?
<mborzecki> i recall getting oom when something went awry there
<pstolowski> it in snap/ , yaml parsing tests
<pstolowski> mborzecki: it eats mem pretty quickly with the diff i pasted earlier
<mborzecki> pstolowski: iirc it didn't like when structs were pointing to each other
<pstolowski> mborzecki: yep, i saw something suspicious yesterday with more complex changes (it would output "CYCLIC REFERENCE"). but in this simple case i created it's actually less references (i'm not creating slot <-> hook references)
<pstolowski> mborzecki: in other words i deliberately broke code not to create references, and it causes oom :/
<mborzecki> zyga: mvo: i think g-c is actually pulling some exchange rate data from the network
<mvo> mborzecki: I wrote a small script to gather the strace datahttps://paste.ubuntu.com/p/vD2rsyXHJr/
<mvo>  
<mvo> mborzecki: https://paste.ubuntu.com/p/vD2rsyXHJr/
<mvo> mborzecki: this is from brave, I will post the script in a sec
<pstolowski> mborzecki: i suppose the problem is actually in pretty?
<mborzecki> mvo: nice
<mborzecki> pstolowski: yes, that's quite possible
<zyga> pstolowski: re, sorry for the lag - some house stuff
<zyga> pstolowski: looking again
<pstolowski> np
<zyga> pstolowski: ah so check.v1 bug?
<pstolowski> zyga: it seems so
<pstolowski> zyga: or rather - it's dependency that's doing the diffing
<mborzecki> pstolowski: keep in mind that the print only happens if the values are not equal in the tests
<pstolowski> mborzecki: sure
<pstolowski> mborzecki: only it's impossible to find out what's failing ;)
<pstolowski> mborzecki: for now i just disabled this pretty printing
<mborzecki> pstolowski: i can relate :) this was super annoying when working on interfaces
<mup> PR snapd#6172 closed: Send epochs followup <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6172>
<mborzecki> mvo: my breakdown for brave, 7.6s from s-c to exec'ing brave, top 3 are update-mime-database (2.9s), gtk-update-icon-cache (1.1s), snap-update-ns (~700ms apparently)
<mborzecki> suprising how far one can go solely with emacs :)
<zyga> mborzecki: I think I should measure snap-update-ns
<zyga> can you please tell me what is the mount profile there
<zyga> both system and user
<mvo> mborzecki: aha, ok
<mvo> mborzecki: http://paste.ubuntu.com/p/Gn95x59tqT/ <- this is what I used
<mborzecki> zyga: http://paste.ubuntu.com/p/tg5VcSyJw8/
<mvo> mborzecki: I will include it in my bench script to make reproducing this easier
<mborzecki> mvo: great
<zyga> thanks
<zyga> mborzecki: is that all?
<zyga> that's the system profile, is there a user profile too?
<zyga> maybe there's a bug but I don't see why this should take 700ms
<zyga> well
<zyga> something to check
<mborzecki> zyga: https://paste.ubuntu.com/p/wG63T4jQjd/
<zyga> ah
<zyga> so yes
<zyga> portals
<zyga> I bet a beer it is portal startup check
<zyga> though
 * zyga thinks
<zyga> perhaps not
<zyga> that was added to snap-run IIRC
<zyga> mborzecki: when you measured, 700 was for which of the two executions of snap-update-ns?
<mborzecki> zyga: regular one, let me grab that part of strace
<zyga> with roughly 30 mount calls there that's ~~ 20 ms per entry
<zyga> (aka looooooots)
<mborzecki> zyga: https://paste.ubuntu.com/p/mR7vpYFRgS/
<mborzecki> zyga: hm, it'd be easier if snap-update-ns printed it's pid :)
<zyga> is that [pid 20700]      0.674152 [????????????????] +++ exited with 0 +++
<zyga> 0.67 is the duration?
<mborzecki> zyga: yes, that's my guess
<mvo> mborzecki: I started using "-ttt" to get more reliable timing
<mup> PR snapd#6179 opened: snap: epoch lists must contain no duplicate entries <Created by chipaca> <https://github.com/snapcore/snapd/pull/6179>
<mborzecki> mvo: yeah, seems to give quite different results when tracking many syscalls
<mborzecki> zyga: with -ttt s-u-n seems to take ~100+ ms for snap fstab and ~10ms for user mounts https://paste.ubuntu.com/p/cp7cs6jvFC/
<zyga> what is -ttt?
<zyga> given that this x7 difference is the remaining allocation accurate?
<zyga> (to other programs in the chain)
<kjackal> Hi snappy people, is there a way to clean a channel so that it shows nothing is published there? I want to have nothing released for microk8s 1.10/edge
<mborzecki> zyga: -t is wall clock, -r is relative time between syscalls (supposedly using montonic clock)
<mborzecki> zyga: also, from the point where sc_fork_helper is called to where sigchld is received it's ~650ms
<zyga> that's ok
<zyga> sc_fork_helper lives for the duration of both s-u-n calls
<zyga> in between we do our business and call sun twice
<mborzecki> hm actually intersting, between calling sc_fork_helper and sc_populate_mount_ns there's 500ms difference, not that it matters much
<zyga> mmmmmmm
<zyga> that's interesting
<zyga> note
<zyga> which version is this
<zyga> that code changed recently
<zyga> is this master?
<mborzecki> i've built s-u-n from master btw
<zyga> ah sorry
<zyga> master is "old"
<zyga> I was thinking about my recent changes
<zyga> so
<zyga> hmmm
<zyga> maybe the slow part is aa change hat?
<mborzecki> zyga: lines 8 and 15 in that last paste
<zyga> can you do an experiment
<zyga> comment that out
<zyga> and see what happens
<zyga> you may need to splice the helper hat profile into the main profile to avoid denials
<zyga> it'd be fun if that small operation took this long
 * zyga is happy snap-confine is in C an can be timed reliably with symbols
<mup> PR snapcraft#2409 closed: python plugin: process deps before and separately from setup.py <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2409>
<zyga> brb
<mup> PR snapd#6156 closed: wrappers: remove all desktop files from a snap on removal <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6156>
<mup> PR snapd#6180 opened: snap/info: bind global plugs/slots to implicit hooks <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6180>
 * pstolowski lunch
<mborzecki> mvo: updated https://gist.github.com/bboozzoo/d4b142229b1915ef7cc0cf8593599ad9 added content verification and variants with systemd units loaded before start/stop, with systemd-mount and just simple mount
<mborzecki> mvo: systemd-mount is flaky, so it fails early when stopping, mounts are so so, updating the state of loopback devices seem to take a while; loading mount units before reload makes the problem disappear
<mborzecki> mvo: so the only path where it fails reliably is when reload interleaves with start (and maybe stop)
<mborzecki> Chipaca: have you seen https://forum.snapcraft.io/t/display-non-autoconnect-interfaces-at-install/8609 ? sounds like a nice ux improvement
<mvo> mborzecki: nice findings"!
<mvo> mborzecki: this also means we can serialize daemon reload and the problem hopefully goes away?
<mvo> GRL (GLOBAL RELOAD LOCK)
<mup> PR snapcraft#2412 opened: schema: add support for title <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2412>
<cachio> zyga, https://paste.ubuntu.com/p/j7BdJ6jhJJ/
<cachio> any idea what could cause that?
<cachio> it is using core from edge
<cachio> mvo, ~
<zyga> yes
<zyga> but no idea why
<zyga> what distribution and kernel is this?
<cachio> bionic
<cachio> 4.15.0-36-generic
<zyga> mborzecki: ^
<zyga> is the calc open now?
<mborzecki> hah, intersting
<mborzecki> zyga: does edge have the fixes you landed recently?
<zyga> mborzecki: yes
<cachio> no
<zyga> well
<zyga> I suspect so
<mborzecki> yes/no/maybe :)
<zyga> but in either case those are not related
<zyga> none affect discarding
<mborzecki> maybe gnome-calculator is still working?
<cachio> it is not working now
<cachio> no process running at least
<zyga> can you look at
<zyga> cd /sys/fs/cgroup/freezer
<cachio> I tried another snap
<cachio> supercalc-snap                                   1     stable    keshavnrj   disabled,broken
<cachio> and also failed
<zyga> then cd to snap.gnome-calculator
<zyga> and look at cgroup.procs
<zyga> check what processes are there
<cachio> zyga, I dont see calculator
<zyga> what do you see
<cachio> zyga, other gnome snapd
<cachio> snaps
<zyga> can you run
<cachio> logs, characters
<zyga> sudo SNAPD_DEBUG=1 /usr/lib/snapd/snap-discard-ns gnome-calculator
<cachio> zyga, what I see
<cachio> is that if I remove from command line a snap
<cachio> it works
<cachio> if I remove from ubuntu-software the snap fails to be removed
<cachio> zyga, https://paste.ubuntu.com/p/cNHpvdCqMM/
<zyga> that's the one from the distro, can you run the one from core
<zyga> that will be representative of what snapd runs
<zyga> it has more stuff going on
<zyga> sorry, I didn't think about this
<cachio> zyga, I already tried removing from core and it works
<zyga> ?
<zyga> I mean
<zyga> can you try running snap-discard-ns like you did but use /snap/core/current/usr/lib/snapd/snap-discard-ns instead
<cachio> yes
<zyga> and capturing the log if that
<zyga> when it fails
<cachio> https://paste.ubuntu.com/p/9Ng8pfysj9/
<cachio> fails
<zyga> aha
<zyga> I suspect I know what the problem is
<zyga> this is fixed (I suspect) by ...
<zyga> https://github.com/snapcore/snapd/pull/6159
<mup> PR #6159: cmd/snap-confine: handle mounted shared /run/snapd/ns <Created by zyga> <https://github.com/snapcore/snapd/pull/6159>
<zyga> cachio: can you post your host's mountinfo table
<zyga> what I don't know is how that can happen
<zyga> seems like another bug
<Chipaca> mborzecki: yes i saw that
<Chipaca> mborzecki: and yes i agree
<mborzecki> Chipaca: we should have a papercuts lane in trello
<Chipaca> mborzecki: my plate is full but i've got my eyes on it in case nobody picks it up before i finish the smallest pea
<Chipaca> mborzecki: +23
<zyga> note how we never unmounted the file
 * Chipaca accidentally burned through all his +1 reserves
<zyga> just unliked it
<zyga> that is because it's a tmpfs
<zyga> because we re-mounted /run/snapd/ns over itself
<zyga> hiding mounts inside
<zyga> not sure why
<cachio> zyga, https://paste.ubuntu.com/p/H5sCQkVWkm/
<zyga> can you get the mountinfo table instead
<zyga> mounts shows partial data
<zyga> but yeah, I suspect that's the case
<zyga> tmpfs /run/snapd/ns tmpfs rw,nosuid,noexec,relatime,size=1222540k,mode=755 0 0
<zyga> tmpfs /run/snapd/ns tmpfs rw,nosuid,noexec,relatime,size=1222540k,mode=755 0 0
<cachio> zyga, sorry, this is what you need https://paste.ubuntu.com/p/YrDVdcNyQV/?
<cachio> zyga, sorry, this is what you need https://paste.ubuntu.com/p/YrDVdcNyQV/ ?
<zyga> no
<zyga> please cat /proc/self/mountinfo
<zyga> brb, lunch
<zyga> (not urgent)
<zyga> cachio: I think the bug is fixed in that PR I linked to
<cachio> zyga, https://paste.ubuntu.com/p/Fhb8GrpJnM/
<zyga> thanks, I'll check soon]
<cachio> zyga, ok, but why if I do snap remove foo
<cachio> works
<cachio> and if I remove from ubuntu software it fails?
<Chipaca> mborzecki: trello says it isn't for papercut kind of thing
<Chipaca> mborzecki: so, https://forum.snapcraft.io/tags/papercut
<Chipaca> mborzecki: (in "about the snapd team board", no backlog and no quick tasks)
<mborzecki> Chipaca: ah, fair enough
<mborzecki> zyga: https://github.com/systemd/systemd/issues/10872
<zyga> mborzecki: nice
<zyga> mborzecki: I'm not 100% sure it's systemd but let's see
<mborzecki> zyga: couldn't reproduce it any other way
<zyga> cachio: it depends on the order in the info table
<zyga> mborzecki: I will look again later
<zyga> mborzecki: need to wrap up and wrap up and do more tasks
<cachio> zyga, ahh, ok
<zyga> mvo: I now have collection of performance events from snap-update-ns
<zyga> detailed actions as well
<zyga> now looking at C
<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
 * Chipaca hugs mup
<Chipaca> some days are like that
<mvo> mborzecki: super nice
<mvo> zyga: cool, thanks. what times are we talking about?
<mvo> zyga: I mean, how much time does snap-update-ns take on a typical snap?
<mborzecki> mvo: zyga: it'd be nice to have a baseline reference, eg. hello-world and then the snap with all the interfaces
<zyga> nice idea
<zyga> mvo: hold on
<mvo> mborzecki: indeed
<zyga> mvo: note that I'm measuring inside the process
<zyga> but now I see 0ms on trivial apps
<zyga> let me try brave
<zyga> 0ms rounded to ms
<zyga> in snap-confine I will measure the whole chunk
<zyga> ho issues
<zyga> I seem to be stuck at the joining screen
<zyga> 2fa
<mborzecki> mvo: perf trace https://paste.ubuntu.com/p/kpNMpxj5jm/
<mvo> mborzecki: thanks!
<mborzecki> mvo: mksquashfs options -noI -noD -noF
<mvo> mborzecki: thank you
<mborzecki> mvo: mount thing reproduces on 18.04  too
 * cachio lunch
<mborzecki> mvo: what do you think about cherry-picking centos support to 2.36?
<mvo> mborzecki: +1
<mvo> mborzecki: how big is the diff?
<mup> PR snapd#6173 closed: sanity: extend the kernel version check to cover CentOS/RHEL kernels <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6173>
<mborzecki> mvo: most of it are tests, a little of packaging, i'd pick the sanity check too
<mborzecki> mvo: i can open a PR
<mvo> mborzecki: please do
<mborzecki> mvo: running under spread now
<zyga> mvo, mborzecki: I need to land https://github.com/snapcore/snapd/pull/6170
<mup> PR #6170: overlord,tests: expose enabled features to /var/lib/snapd/features <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6170>
<zyga> mvo: I'm preparing to send feature PRs
<mvo> pedronis: I guess 6170 is uncontroversial, right? a look at the description is enough, we can do the in-depth review
<zyga> mvo: then I need this https://github.com/snapcore/snapd/pull/6181
<mup> PR snapd#6181 opened: features: add feature test methods <Per-user mount ns  ð> <Performance ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6181>
<mup> PR #6181: features: add feature test methods <Per-user mount ns  ð> <Performance ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6181>
<mup> PR snapd#6182 opened: Revert "cmd/snap-confine: don't allow mapping lib{uuid,blkid}" <Created by zyga> <https://github.com/snapcore/snapd/pull/6182>
<mup> PR snapd#6183 opened: sanity, spread, tests: add CentOS (2.36) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6183>
<mborzecki> mvo: ^^
<mvo> mborzecki: ta
<zyga> mvo: prepping remaining branches
<mvo> zyga: thank you!
<zyga> adding missing tests etc
<pedronis> mvo: yes, about 6170 seems fine, we could bike shed about the name features, but I know other cases where it has been used fairly generically
<mup> PR snapcraft#2413 opened: kernel plugin: introduce a _get_kernel_version() helper <Created by piso77> <https://github.com/snapcore/snapcraft/pull/2413>
<mvo> pedronis: great, thanks. yeah, lets not bike shed too much :)
<pedronis> mvo: what is #6178 about, startup performance of snaps?
<mup> PR #6178: snap,snap-exec: add SNAP_DEBUG_START_TIME environment <Created by mvo5> <https://github.com/snapcore/snapd/pull/6178>
<mvo> pedronis: yeah, the brave discussion on the mailinglist
 * roadmr prefers cowardly discussion :P
<mvo> pedronis: happy to give you more context if you want, we can have a quick HO or something (or tomorrow or later, whatever works for you)
<zyga> mvo: https://github.com/snapcore/snapd/pull/6184
<mup> PR #6184: perf: add performance helpers <Performance ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6184>
<mup> PR snapd#6184 opened: perf: add performance helpers <Performance ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6184>
<zyga> mvo: the next part is the perf manager but I need to make tea now
<zyga> I'm starting to feel sick
<mvo> zyga: yeah, lets get pedronis a chance to look at this too
<mvo> zyga: uh, get well!
<mvo> zyga: don't get sick - we need you :)
<zyga> mvo: sure, I will open all the PRs so we can see the ful set
<mvo> ok
<zyga> mvo: I hope to be okay but I think this autumn morning was not my best
<pedronis> mvo: that's ok, but if perf of startup is a focus, can we have a card ?
<zyga> pedronis: I made a card recently
<pedronis> zyga: mmh, it's only for you,  mvo is not on it
<mvo> pedronis: I think they are slightly different
<mvo> pedronis: and will converge
<zyga> yes
<pedronis> zyga: mvo: anyway if it really involves adding a new manager, yes I should be in discussion
<zyga> mvo's work will improve perf startu
<mvo> pedronis: zyga was working on internal perfoamnce, e.g. seccomp setup
<zyga> my work will allow us to mearure it better
<mvo> pedronis: I am working on snap run -> app overhead
<pedronis> mvo: yes, so please make a different card
<mvo> pedronis: will do
<pedronis> thx
<pedronis> mvo: I imagine it will take a bit of time, not just a quick thing
<mvo> pedronis: yeah, eating all day so far but good results
<pedronis> mvo: :)
<pedronis> zyga: it's a bit unclear to me how #6184 would interact with things that restart snapd
<mup> PR #6184: perf: add performance helpers <Performance ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6184>
<zyga> pedronis: the perf manager can save its state if the perf monitoring feature is enabled
<zyga> pedronis: perf manager is in the next branch, just adding missing tests and making sure it's all tidy
<zyga> pedronis: where state is just the set of samples
<zyga> pedronis: this is not the regular state
<zyga> pedronis: it is not persisted in normal cases
<pedronis> zyga: how do you make it a noop? or is the plan to use it only when needed?
<zyga> pedronis: you have to enable it
<zyga> pedronis: there's a feature flag
<pedronis> zyga: anyway sounds we need to discuss it more
<pedronis> zyga: a feature flag?
<pedronis> where?
<zyga> pedronis: it's all coming up in subsequent branches I'm chopping from what I implemnted today
<pedronis> a config ?
<zyga> pedronis: if you set a core config experimental.performance-measurements the manager stops being a no-op
<pedronis> zyga: we didn't discuss the plan, did you discuss it with mvo?
<zyga> otherwise the ring bufer is set to nil and nothing happens
<zyga> pedronis: just during the call today, all of this code was made today
<pedronis> zyga: thagt's great, but it wil take a while to revirw
<zyga> pedronis: the short version is that perf manager doesn't do anything unless enabled
<pedronis> zyga: it's a bit unclear where it fits overall
<pedronis> as well
<zyga> pedronis: not sure what you mean
<pedronis> zyga: is it about first boot perf? about something else?
<zyga> pedronis: the idea was to store samples in memory in snapd and expose it for debugging
<pedronis> zyga: you understand that the code need not to crash normal snapd
<pedronis> usage
<zyga> pedronis: about figuring out what is slow in couple of things we are experiencing
<zyga> yes
<zyga> in normal code it's a nop
<zyga> s/normal code/normal mode when feature is not active/
<pedronis> zyga: just saying that the fact that it was quick to write, doesn't mean it can be quick to land
<zyga> yes, I understand that
<zyga> I don't even have to land it, really it was made to debug ongoing issues
<zyga> we can land it slowly
<zyga> but we can use the collective branch for experiments
<zyga> e.g. we now know that seccomp setup is slower than apparmor
<pedronis> ok
<zyga> and we have precise timing data on snap-update-ns
<zyga> (we can collect snap-{run,confine,exec} timing this way too
<zyga> if the manager is enabled all that happens is we store samples in a ring buffer
<pedronis> zyga: the code is go, no?
<zyga> pedronis: yes
<pedronis> how does it relate to snap-confine?
<pedronis> you need a c variant?
<zyga> pedronis: processes that are not in snapd can also collect samples
<zyga> pedronis: really just start/end/summary
<zyga> pedronis: snapd collects that
<zyga> pedronis: and exposes everything via "snap debug speed"
<zyga> pedronis: again, only if the feature is enabled
<zyga> pedronis: such samples are saved in /runs/snapd/perf/*.json and are loaded by the perf manager
<zyga> pedronis: either in ensure or when "snap debug speed" is used
<pedronis> zyga: that sounds delicate
<zyga> pedronis: that last command just shows collected samples and shows us data
<pedronis> because Ensure is in the hot path as well
<zyga> er, duration and meta-data
<zyga> it doesn't really need to be in ensure because it's collected on demand in the API debug call
<pedronis> except if you restart
<zyga> if the manager is stopped is saves the samples to /run/snapd/perf/
<zyga> so on restart it can pick it up
<zyga> I haven't used that much though because for local testing with several snaps it wasn't the interesting case
<pedronis> zyga: I marked it as blocked, not because it not useful, I'm just worried about landing it in prod snapd for a while
<zyga> pedronis: sure
<zyga> pedronis: I will propose all the branches and collect them all in a evaluation branch for ongoing debugging
<pedronis> zyga: what's the state of per-user mounts?
<zyga> pedronis: under review, one branch needs my activity but master was wonky so I didn't push it forward yet
<pedronis> ok
<zyga> pedronis: I will fix that branch because the issue is small, just sequencing of other PRs
<zyga> pedronis: I really want to end that work :)
 * zyga -> break for tea
<mup> PR snapd#6185 opened: snap: add new `snap run --perf` call <Performance ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6185>
<zyga> mvo: hey
<zyga> if you are still working I would love to review and land https://github.com/snapcore/snapd/pull/6181
<mup> PR #6181: features: add feature test methods <Per-user mount ns  ð> <Performance ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6181>
<zyga> as well as https://github.com/snapcore/snapd/pull/6170
<mup> PR #6170: overlord,tests: expose enabled features to /var/lib/snapd/features <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6170>
<zyga> I'm blocked by those two
<mup> PR snapcraft#2414 opened: yaml_utils: allow unicode while encoding <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2414>
<zyga> jdstrand: can you please look at 6182
<ijohnson> zyga: I think jdstrand is out today
<zyga> bummer
<mup> PR snapd#6105 closed: NOT REVIEW: New task to force error on degraded test <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6105>
<mup> PR snapd#6148 closed: cmd/snap-confine: remove unneeded unshare <Per-user mount ns  ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6148>
#snappy 2018-11-22
<mup> PR snapd#6186 opened: interfaces/avahi_observe: Fix typo in comment <Created by Lin-Buo-Ren> <https://github.com/snapcore/snapd/pull/6186>
<mborzecki> morning
<mup> PR snapd#6187 opened: packaging/fedora: use %_sysctldir macro <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6187>
<mborzecki> mvo: hey, we'll have some trouble with github.com/coreos/go-systemd/activation package, the changed the API of activation.Listeners(bool) to activation.Listeners() and the default is different now
<mborzecki> mvo: any clue why we didn'g want to have go-systemd unset LISTEN_FDS, LISTEN_PID and LISTEN_FDNAMES ?
<mvo> mborzecki: I don't know, maybe chipaca remembers
<mborzecki> mvo: hm, from the looks of it, we could drop the activation package, our use case is super simple and could be easily done ourselves without external dep
<mborzecki> mvo: and fedora has bumped their pacakge version in f29 and rawhide, soe snapd will not build there anymore without a patch
<mvo> mborzecki: right
<mborzecki> i'll prep a pr to unblock this
<mvo> mborzecki: I'm inclined to just to our own implementation or is there another packaged option out there with a more stable api?
<mvo> mborzecki: thank you
<pstolowski> mornings
<mvo> hey pstolowski - good morning
<mborzecki> pstolowski: hey
<zyga> Hey
<zyga> Will start late, Iâm stuck in traffic
<mvo> zyga: good morning
<zyga> Had a late night :/
<mvo> zyga: I have a bit of a conundrum, maybe you have an idea. strace -f snap run test-snapd-tools.echo does not show snap-update-ns in my log, I wonder why
<zyga> Please review my PRs if possible
<mvo> zyga: yeah, I noticed some reviews were late. what happend, did you got carried away?
<mvo> zyga: yeah, will do
<zyga> Mvo: is the mount namespace ready? We only call s-u-n once
<zyga> Combination of factors, I stopped after 3AM
<zyga> Mvo: I merged one branch that had one review and was hanging for days
<zyga> The one removing useless unshare
<zyga> You asked it
<zyga> Acknowledged it
<mvo> zyga: I remember this one, iirc I reviewed it
<zyga> Still in traffic
<zyga> Yep
<mvo> zyga: no worries
<zyga> Just wanted to make sure you know
<mborzecki> mvo: maybe it's because s-u-n goes through fexecve, you can actually see clone() and with -k you see which s-c function is calling it but not much more
<mvo> mborzecki: yeah, its slightly annoying, I though internally this all goes through execve into the kernel but apparently not :/
<mvo> mborzecki: aha, apparently I can get execveat
 * mvo reviews first
 * mvo must resist temptation
<mborzecki> mvo: hmm looking at glibc, there's a path for execvat and a separate one for that calls execve("/proc/self/fd/<num>",..) where num is the fd
<mvo> zyga: 6170 and 6181 were the critical ones?
<mvo> mborzecki: interessting
<mvo> mborzecki: what I see (just from experimenting) here on 18.10 is execveat
<mvo> mborzecki: but maybe it depends on kernel or something?
<mborzecki> mvo: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/fexecve.c;h=3560b711ca2c6d1a61330d91099a3fc2201c583e;hb=HEAD
<mborzecki> mvo: yes, kernel and glibc
<mvo> mborzecki: nice, thnak you
<mborzecki> fedora is the only distro where deps aren't bundled, right?
<mvo> mborzecki: debian too
<mborzecki> ah
<zyga> mvo: in 10 min
<mborzecki> mvo: ok, so buster is a problem too then
<mvo> mborzecki: the systemd stuff?
<mvo> mborzecki: well, breaking api is not nice
<mvo> bad people
<mborzecki> mvo: yes, buster has v17 version which has the API change
<mborzecki> mvo: coreos, move fast, break things, get bought :)
<mup> PR snapd#6188 opened: daemon, vendor: bump github.com/coreos/go-systemd/activation, handle API changes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6188>
<zyga> mvo: sorry, now installed and ready for work
<zyga> mvo: let me read the backlog now
<zyga> mvo: so https://github.com/snapcore/snapd/pull/6170 is the snapd side part of features
<mup> PR #6170: overlord,tests: expose enabled features to /var/lib/snapd/features <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6170>
<zyga> I think it's not controversial
<Chipaca> ðð¬ð¬ð¡ ðð¬ð¯ð«ð¦ð«ð¤
<zyga> it's the design gustavo wanted
<zyga> holly smokes
<zyga> now you must tell me, dir sir Chipaca, how that works
<Chipaca> ð¬ð§ðð© ð¢ð§ð¬ð­ðð¥ð¥ ð®ð§ð¢ðð¨ð§ð­ðð«
<mborzecki> wow
<Chipaca> ððð ðððð ðð ðððð¢
<zyga> Chipaca: but technically
<zyga> are those just unicode glyphs that have a specific look?
<Chipaca> yes
<Chipaca> ðð½â¯ðâ¯ â¯ðâ¯ð ð¾ð â´ðâ¯ ðð¾ðâ¯ ðð½ð¾ð
<zyga> mvo: https://github.com/snapcore/snapd/pull/6181 is the second part of that for Go programs
<zyga> I wasn't sure where to put it
<mup> PR #6181: features: add feature test methods <Per-user mount ns  ð> <Performance ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6181>
<zyga> As in, which package
<Chipaca> zyga: in gucharmap, search for 'fraktur' to get to the majority of them
<zyga> ahhh
<zyga> fraktur, I love it
<zyga> thank you :)
<Chipaca> usage: unifonter [-h] [-i INPUT] [-o OUTPUT]
<Chipaca>                  [-k {b,bc,bf,bi,c,d,f,i,m,s,sb,sbi,si,w}]
<Chipaca>                  [text [text ...]]
<Chipaca> unifonter: error: argument -k: invalid choice: 'k' (choose from 'b', 'bc', 'bf', 'bi', 'c', 'd', 'f', 'i', 'm', 's', 'sb', 'sbi', 'si', 'w')
<Chipaca> augh
<zyga> mvo: after writing the features/ PR I wanted to combine the two so that there's a canonical definition of features
<Chipaca> (ð±ð¥ð¦ð° ð¦ð° ð£ð¯ðð¨ð±ð²ð¯)
<zyga> so that coreconfig references the same names, I will do that as a follow-up
<Chipaca> (ðððð ðð *ðððð* ððððððð)
 * Chipaca stops having fun and has coffee instead
<mvo> zyga: ok, I just finished the first going to the second now
<zyga> thank you, looking
<zyga> mvo: I will kindly ask you to do more reviews after that - I really want to land this thing
<zyga> mborzecki: can you do a quick check on https://github.com/snapcore/snapd/pull/6182
<mup> PR #6182: Revert "cmd/snap-confine: don't allow mapping lib{uuid,blkid}" <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6182>
<zyga> this may fix the TW testing PR
<mup> PR snapd#6187 closed: packaging/fedora: use %_sysctldir macro <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6187>
<zyga> do we need CLA for a typo?
<zyga> I guess not
<zyga> I'm looking at https://github.com/snapcore/snapd/pull/6186
<mup> PR #6186: interfaces/avahi_observe: Fix typo in comment <Simple ð> <Created by Lin-Buo-Ren> <https://github.com/snapcore/snapd/pull/6186>
<mup> PR snapd#6182 closed: Revert "cmd/snap-confine: don't allow mapping lib{uuid,blkid}" <â  Critical> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6182>
<zyga> mvo: replied to https://github.com/snapcore/snapd/pull/6170
<zyga> let me know if the suggested comment is ok
<mup> PR #6170: overlord,tests: expose enabled features to /var/lib/snapd/features <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6170>
<zyga> I will update it quickly :)
<mvo> zyga: ok, I am at the other one right now
<zyga> mvo: if you still have a moment for reviews then please look at https://github.com/snapcore/snapd/pull/6147 next
<mup> PR #6147: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6147>
<zyga> I will work on the feedback
<mvo> zyga: thanks, replied and added feedback for 6181
<zyga> thanks!
<mvo> zyga: thanks for your patience
<mborzecki> zyga: left some comments in #6170, sorry for the delay, had it opened in a tab a while now, buried among a bunch of other tabs
<mup> PR #6170: overlord,tests: expose enabled features to /var/lib/snapd/features <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6170>
<mborzecki> wish ff had a way to label/mark tabs, like TODO and so on
<zyga> mvo: about the two feature PRs
<zyga> shall I merge them together
<zyga> or do you want to see a 3rd PR on top
<zyga> mvo: I just saw your comment in the PR, I will do a follow up
<vidal72[m]> is core snap needed when all installed snaps use core 18?
<zyga> so quick pass over the simple feedback and then merge the two and continue
<zyga> vidal72[m]: no but some bugs in stable mean that yes
<zyga> vidal72[m]: in master this is (I believe) all fixed now
<vidal72[m]> zyga: is there a way to remove core snap?
<zyga> not at present
<vidal72[m]> :(
<mvo> https://github.com/snapcore/core/pull/99 <- needs a review from someone from the snapd team
<mup> PR core#99: snapcraft: add fc-cache-{6,7} <Created by mvo5> <https://github.com/snapcore/core/pull/99>
<zyga> mvo: I had a look last night
<zyga> but after midnight I didn't want to comment
<zyga> vidal72[m]: is there an issue with that?
<zyga> vidal72[m]: eventually the core snap will be phased out
<zyga> vidal72[m]: snapd will install and remove required base snaps automatically
<zyga> mvo: updated https://github.com/snapcore/snapd/pull/6181 - I think it's good to do now
<mup> PR #6181: features: add feature test methods <Per-user mount ns  ð> <Performance ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6181>
<zyga> mvo: if this lands I can merge it into the other PR (snapd side) and remove the duplication there
<zyga> why is the core configuration package called configcore and not coreconfig?
<mvo> zyga: iirc gustavo liked the name better
<mvo> zyga: re 6181> please push the followup once its ready I'm keen to see it playing together and I would love to also land it together
<zyga> sure
<zyga> uh
<zyga> pedronis: replied to your comment on 6181
<zyga> pedronis: please let me know if you want to discuss this
<Chipaca> mvo: wrt core#99, how's the insecure access thing going to be addressed?
<mup> PR core#99: snapcraft: add fc-cache-{6,7} <Created by mvo5> <https://github.com/snapcore/core/pull/99>
<mvo> Chipaca: I thought I pushed the fix for this, let me double check
<zyga> pedronis: so, can you help me understand please
<mvo> Chipaca: uh, silly me
<Chipaca> :-)
<mvo> Chipaca: now the fix is pushed *cough*
<zyga> pedronis: shall I merge 6170 into 6181
 * Chipaca sends mvo a 4x-strength green tea
<mvo> Chipaca: actually - silly git and silly me to equal parts
<zyga> pedronis: and have configcore use the features in one PR
<zyga> pedronis: is that what you want?
<mvo> Chipaca: heh, great! I need it, didn't sleep well
<Chipaca> same
<Chipaca> I tweaked my back yesterday again :-(
<mvo> Chipaca: :(
<Chipaca> mvo: is armhf security also on ports?
<mvo> Chipaca: I am pretty sure it is, let me double check
<Chipaca> k
<mvo> Chipaca: http://ports.ubuntu.com/ubuntu-ports/dists/bionic-security/main/binary-armhf/
<Chipaca> \o/
 * zyga is unsure what to do about features now
<zyga> eh
<mvo> zyga: just make a combined PR with 6170, 6181 and the followup that uses features in configcore
<zyga> mvo: and the package?
<mvo> zyga: I think that the easiest way forward, then we can see the bigger picture
<zyga> pedronis didn't want to add a new package but didn't respond to how to structure it
<mvo> zyga: not sure, maybe it could be a sub-package of something?
<zyga> like?
<mvo> zyga: heh, you ask hard questions :)
<mvo> zyga: let me look and think
<mvo> zyga: I am not sure maybe a sub package of configstate ? otoh it has nothing to do with overlord. but then it fits the oconfig schema. its a bit of an import otoh :/ "overlord/configstate/features"
<zyga> mvo: then we need to import that from snap-update-ns
<zyga> mvo: I didn't want to do that
<mvo> zyga: fair enough, but maybe we can move forward and do the other bits (using feature in corecfg etc) and address this package name/locaiton as the last step?
<mvo> zyga: (assuming samuele is ok with this but I guess he will be)
<zyga> mvo: yes, I'm working on that now
<mvo> zyga: great, thank you
<zyga> well, adding test that maciej requested firts
<mvo> zyga: +1
<mup> PR snapd#6188 closed: daemon, vendor: bump github.com/coreos/go-systemd/activation, handle API changes <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6188>
<mborzecki> mvo: left some comments under #6185, really like it
<mup> PR #6185: snap: add new `snap run --perf` call <Performance ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6185>
<mvo> mborzecki: thanks, I'm working on tests now
<mvo> mborzecki: more
<mup> PR snapcraft#2415 opened: tools: pull in imporved cla_check.py from snapd <Created by chipaca> <https://github.com/snapcore/snapcraft/pull/2415>
<Chipaca> 'imporved'
<Chipaca> ð¤¦
 * Chipaca leaves it
<zyga> mvo: I addressed all comments in https://github.com/snapcore/snapd/pull/6170
<mup> PR #6170: overlord,tests: expose enabled features to /var/lib/snapd/features <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6170>
<zyga> mvo: shall I close https://github.com/snapcore/snapd/pull/6181 now and merge it into 6170?
<mup> PR #6181: features: add feature test methods <Per-user mount ns  ð> <Performance ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6181>
<mup> PR snapd#6171 closed: tests: add SPREAD_JOB to the description of systemd_create_and_start_unit <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6171>
<zyga> mvo: ?
<mvo> zyga: sorry, looking
<zyga> thanks
<mvo> zyga: how about just creating a new branch that combines 6181 and 6170 and build on top of that?
<mvo> zyga: we can have a HO if you feel this is all a bit unclear
<zyga> no, that's fine
<zyga> let me make one
<zyga> and the two branches can be closed,
<mvo> zyga: yeah or just keep them for reference as they have useful comments and we close once the final one is in - but no strong preferences, if you just refer to them in the new PR thats fine as well of curse
<mvo> course
<mup> PR snapd#6170 closed: overlord,tests: expose enabled features to /var/lib/snapd/features <Per-user mount ns  ð> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6170>
<mup> PR snapd#6181 closed: features: add feature test methods <Per-user mount ns  ð> <Performance ð> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6181>
<zyga> uh :)
<zyga> too late
<mup> PR snapd#6189 opened: daemon, vendor: bump github.com/coreos/go-systemd/activation, handle API changes (2.36) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6189>
<Chipaca> zyga: when you want a break from easy things, #6034 is ready for another look :-p
<mup> PR #6034: many: save media info when installing, show it when listing <Created by chipaca> <https://github.com/snapcore/snapd/pull/6034>
<zyga> Chipaca: I'll do that after the combination PR
<Chipaca> zyga: :-) ok. No rush anyway, but didn't know if you'd seen that I'd pushed it.
<mup> PR snapd#6190 opened: overlord/configstate,features: expose features to snapd tools <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
<zyga> mvo: https://github.com/snapcore/snapd/pull/6190
<zyga> this is the combination without the duplication
<mup> PR #6190: overlord/configstate,features: expose features to snapd tools <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
<pstolowski> mvo: i've proposed a fix for kr/pretty https://github.com/kr/pretty/pull/58 , but the list of PRs there from the period of 2014-2017 is not encouraging :/
<mup> PR kr/pretty#58: Fix infinite recursion when diffing structs with cycles <Created by stolowski> <https://github.com/kr/pretty/pull/58>
<zyga> Chipaca: looking now
<zyga> I re-read my comments to remind myself about that work
<mvo> pstolowski: thank you! we can always use a fork if we have to (but it would suck)
<pstolowski> mvo: yeah, i'm not sure the fix is 100% correct, the stuff is a bit tricky. for sure it fixes the case i hit in our tests, but i wonder if there are edge cases
<pstolowski> mvo: so feedback from the author would be good
<zyga> Chipaca: reviewed
<Chipaca> zyga: thanks
<zyga> mvo: about the features branch, all of the new code is here https://github.com/snapcore/snapd/pull/6190/commits/dddc6d68ee0f492a45b48e61431fa6d9f55e66b3
<mup> PR #6190: overlord/configstate,features: expose features to snapd tools <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
<mup> PR snapd#6186 closed: interfaces/avahi_observe: Fix typo in comment <Simple ð> <Created by Lin-Buo-Ren> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6186>
<zyga> mborzecki: ping about https://github.com/snapcore/snapd/pull/6111
<mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<zyga> mvo: I don't know if this is the case for sure but perhaps 6110 is failing for the same general reason fedora29 does
<zyga> mvo: we never addressed that issue in the end
<zyga> mborzecki: I ran ubuntu-core-16-64:tests/regression/lp-1803542 alone and it obviously passed
<zyga> I hate our test suite
<zyga> it's a constant source of misery
<zyga> eh
<mup> PR snapcraft#2414 closed: yaml_utils: allow unicode while encoding <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2414>
<mup> PR snapd#6179 closed: snap: epoch lists must contain no duplicate entries <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6179>
<zyga> mvo: snapd update in suse shows some errors
<zyga> syntax error in /var/lib/snapd/desktop/applications/test-snapd-policy-app-consumer_test-desktop.desktop, line 1
<zyga> the destkop file has no [Foo] section
<zyga> is that something we mangle or is that a broken test def? (the snap is from the test suite)
<mvo> zyga: no [Foo] section or no [Desktop] section?
<zyga> no [Desktop] section
<zyga> I will check if the original file has one
<mvo> hm, the test snap has one
<mvo> so that is odd
<zyga> yes
<zyga> it has one
<zyga> something is borken
<mvo> :(
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6147#discussion_r235696283
<zyga> what did you mean there?
<mup> PR #6147: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6147>
<mup> PR snapcraft#2416 opened: yaml_utils: allow unicode while encoding (#2414) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2416>
<mborzecki> zyga: whether it'd be possible to roll sc_setup_mount_profiles and that call into something generic that runs s-u-n
<mborzecki> zyga: or s-d-n
<mborzecki> in that case
<zyga> one bigger function?
<zyga> I'm sorry, I don't follow
<mborzecki> zyga: yeah, like run_this_helper_for_snap(fd, snap_name, aa)
<zyga> yeah perhaps
<zyga> the fork / exec /wait part could be shared
<mborzecki> mhm
<zyga> the arg handling could stay in each dedicated function
<mborzecki> idk, soemthing to think about
<mborzecki> although that doesn't strictly follow the rule of 3s :)
<zyga> 3s?
<mborzecki> zyga: https://erikbern.com/2017/08/29/the-software-engineering-rule-of-3.html
<mborzecki> zyga: fwiw there's even a wikipedia page https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) :)
<zyga> ah, cool
<zyga> see :)
<pedronis> zyga: mvo: to be clear my point was more that it needs to do more, be more the one source of truth/authorative place to merit a top level package, and also that having two authorative places about the different bits of the same things is confusing
<mborzecki> selinux makes my head hurt :/
<zyga> pedronis: the top-level package was just a quick idea since it has to be imported from snap-update-ns and I didn't want to drag all of configcore with it. I'm open to suggestions on where to place it
<zyga> pedronis: the duplication aspect is addressed now
<zyga> pedronis: though we don't have one element yet, the default if absent value (what does it mean for that value to be unset)
<zyga> but this problem is only specific to snapd internals
<zyga> the outside-of-snapd API is unambiguous
<niemeyer> Hello there
<zyga> hey!
<niemeyer> FOlks, we need to rollback or improve that change of "snap info" that is highlighting a channel
<zyga> is it breaking parsing of the input?
<niemeyer> I would suggest just rolling it back for the time being
<niemeyer> At least until we can discuss in more detail the design aspects involved
<niemeyer> zyga: Not for me, at least, but it's very misleading
<niemeyer> Here is an example from my terminal just now:
<niemeyer> channels:
<niemeyer>   stable:    2.79b            (20) 129MB classic <
<niemeyer>   candidate: â
<niemeyer>   beta:      â
<niemeyer>   edge:      2.80-f021536babb (19) 106MB classic
<niemeyer> installed:   2.80-f021536babb (19) 106MB classic
<niemeyer> That "stable" line stands out from everything else in the output, for no good reason
<niemeyer> This is not even my installed version
<zyga> mmm, I see - I didn't notice that before
<niemeyer> We have the fields tracking, installed, and channel map.. each with different meaning
<pedronis> I don't know what that landed, I don't remember that changed being discussed, or reviewing it
<pedronis> Chipaca: ^ is that something you did? or somebody else? when did it land?
<pstolowski> related to this: https://bugs.launchpad.net/snapd/+bug/1795840
<zyga> 40e299154324315957d31eb89823c5267c0d9e85
<mup> Bug #1795840: `snap info` highlights the wrong version as installed when `snap try`ing <snapd:New> <https://launchpad.net/bugs/1795840>
<zyga> https://github.com/snapcore/snapd/commit/40e299154324315957d31eb89823c5267c0d9e85
<Chipaca> pedronis: that's something I did yes
<Chipaca> it highlights the current channel
<pedronis> Chipaca: mvo: it's 2.36 ?
<pedronis> Chipaca: current as in tracking?
<Chipaca> yes
<pedronis> but not always ?
<pedronis> niemeyer said is highlighting not his installed version?
<pedronis> or is that because of a switch?
<pedronis> anyway is not very self explanatory
<Chipaca> there was a request (somewhere) about highlighting current channel and current revision  differently when they differend, i think
<niemeyer> Right, it highlights the channel map, although this version is not the current one
<Chipaca> either a switch, or an update not run
<pedronis> we are trying to pack too much stuff there
<pedronis> it's cute
<pedronis> but not sure learnable
<Chipaca> if you're on core edge, 'snap info core' is the most likely to show a difference between highlighted and current revision
<niemeyer> Which doesn't make much sense in that case it seems.. the "arrowing" and highlighting makes it standout more than anything else, even though that channel map entry is not current
<pedronis> Chipaca: so it's trying to pack snap refresh --list information into snap info?
<Chipaca> no
<pedronis> but doesn't really tell?
<Chipaca> what
<Chipaca> no
<pedronis> then I'm very confused
<pedronis> that's not good :)
<Chipaca> it just highlights the channel you are tracking
<Chipaca> that's it
<pedronis> wich bit ?
<pedronis> the bold and the <
<niemeyer> Chipaca: No, it highlights the content of the channel that you are tracking
<pedronis> they point at the same thing? or not?
<Chipaca> bold and < are always the same right now yes
<zyga> niemeyer: ah, so perhaps we could highlight the channel name alone
<Chipaca> niemeyer: what
<niemeyer> Chipaca: Strawman: how about dropping that arrow and making the highlighting on the channel *name* only
<zyga> ha
<niemeyer> zyga: ! :)
 * zyga is happy to get something aligned for a change
<pedronis> niemeyer: Chipaca: yes, that would seem better, it's still a bit unclear how understanble it is
<Chipaca> what's the "content of the channel that you are tracking" that isn't "the channel you are tracking"?
<niemeyer> Chipaca: and then maybe also highlight the *value* of "installed"
<pedronis> maybe
<pedronis> I start to think we need to step back
<niemeyer> Chipaca: I'm tracking stable, my version is not the one on stable..
<pedronis> and pack less in there :)
<zyga> name: foo \n installed: v123 from stable but tracking edge
<niemeyer> Chipaca: The channel map shows the version that is in stable, not the one I have
<niemeyer> Chipaca: Just confusing
 * Chipaca was happy for a month
<niemeyer> :)
<Chipaca> niemeyer: just because you haven't refreshed lately, that does not change the channel map
<pedronis> Chipaca: well we are all confused what it means, that's the reality
<pedronis> that shows maybe we shouldn't do it
<zyga> while on second though I agree it is confusing I must also say I like how it looks like
<zyga> the output is long so visual cues like that help to find things
<zyga> we just need to make it precise
<Chipaca> maybe change the < to <- tracking
<Chipaca> ?
<zyga> ð¤
<Chipaca> zyga: that's undistinguishable from a ð© at least on xenial terminals
<Chipaca> well, maybe not ð© -- they got that one nice and distinctive
<zyga> mvo: http://smackerelofopinion.blogspot.com/2018/11/high-level-tracing-with-bpftrace.html
<zyga> mvo: I wanted to read this because, hey, tracing
<zyga> maybe useful for snaps
<zyga> look at what it says :D
<pstolowski> mvo: i'm going to do some bug triaging, hope i'm not getting into your way again (anyone else doing this?)
<Chipaca> zyga: :-D
<Chipaca> zyga: well, that is cking's blog
<mborzecki> off to pick up the kids
<pstolowski> zyga: do you know if that exec call error reached any conclusion - https://bugs.launchpad.net/snapd/+bug/1705988 ? i think you were investigating this error at some point but maybe i'm wrong
<mup> Bug #1705988: snap install --classic juju fails <canonical-is> <juju:Incomplete> <snapd:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1705988>
<zyga> pstolowski: no
<zyga> pstolowski: I mean, no conclusion
<pstolowski> zyga: k thanks
<pstolowski> pedronis: related to the snap info, there is also an old enhancement request from Mark https://bugs.launchpad.net/snapd/+bug/1758288
<mup> Bug #1758288: 'snap info' should show date of release into channel <snapd:New> <https://launchpad.net/bugs/1758288>
<zyga> I see store errors in tests
<zyga> timeouts
<zyga> break / walk before the call
<mvo> zyga: thanks for the ebpf pointer, this looks pretty cool
<mvo> pstolowski: no bug triage right now on my side, go wild, and thank you!
<mup> PR snapd#6191 opened: cmd/snap: fix missing newline in "snap keys" error message <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6191>
<mvo> pstolowski: bug triage already successful :)
<pstolowski> :)
<mup> PR core#99 closed: snapcraft: add fc-cache-{6,7} <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/99>
<mup> PR snapd#6192 opened: overlord/snapstate: on refresh, check new rev can read current <Created by chipaca> <https://github.com/snapcore/snapd/pull/6192>
<Chipaca> zyga: links to logs for the store timeouts?
<zyga> Er, gonsky
 * cachio lunch
<zyga> ha
<zyga> reproduced
<zyga> something buggy in test cleanup
<zyga> mvo: hangous still buggy
<zyga> I clicked join
<zyga> see my camera
<zyga> and nothing else happens
<zyga> trying to join from regular account
<zyga> same
<zyga> eh
<zyga> mvo: restarted browser, logged out
<zyga> no change
<zyga> how do I join from the phone?
<niemeyer> Chipaca: Re. "niemeyer: just because you haven't refreshed lately, that does not change the channel map".. exactly.. the point is that the *channel map* is now highlighting a *version* and other details like "classic", etc, and it's very unclear why. It certainly doesn't feel like the reason why is "because you are tracking that channel and will eventually get that version, probably".
<mup> PR snapd#6178 closed: snap,snap-exec: add SNAP_DEBUG_START_TIME environment <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6178>
<zyga> pstolowski: oh, that missing newline
<zyga> it was in the TW branch
<zyga> forgot to push it separately
<zyga> thanks for doing that!
<mup> PR snapd#6193 opened: spread: drop Fedora 27, add Fedora 29 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6193>
<sergiusens> niemeyer: hi there, I would appreciate your opinion on https://forum.snapcraft.io/t/title-length-in-snapcraft-yaml-snap-yaml/8625 given that it seems we have no well defined length for the "title" field.
<sergiusens> I think the Gnome Software screenshots there could be used as a guideline on what we want that value to be
<niemeyer> sergiusens: Will discuss here and provide some feedback there, thanks for the pointer
<sergiusens> thanks!
<zyga> https://github.com/snapcore/snapd/pull/6190 is green :)
<mup> PR #6190: overlord/configstate,features: expose features to snapd tools <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
<zyga> pstolowski: found a bug :)
<zyga> 942 127 0:3 mnt:[4026532154] /run/snapd/ns/failing-config-hooks.mnt rw - nsfs nsfs rw
<zyga> I bet that when the config hook fails
<zyga> we don't cleanup after the snap :)
<zyga> I'll look at fixing that
<pstolowski> zyga: great, this is with relation to what?
<Son_Goku> zyga, https://forum.snapcraft.io/t/issue-with-repackaged-core-and-testing/8394/9
<Son_Goku> niemeyer, mborzecki, mvo: golang is moving back to Fedora EPEL
<zyga> pstolowski: the bug I just mentioned in the call
<zyga> Son_Goku: hey
<zyga> Son_Goku: do you have a sec for a call?
<zyga> Son_Goku: not urgent, just want to explain what that issue is about
<Son_Goku> sure
<pstolowski> zyga: ah, that one about finding leftovers
<Son_Goku> I do now
<mborzecki> Son_Goku: do you know if there's any immediate action needed for 7.6?
<Son_Goku> niemeyer, mborzecki, mvo: https://pagure.io/releng/issue/7919
<Son_Goku> mborzecki, not yet
<zyga> Son_Goku: https://meet.google.com/exu-zttk-ynz?authuser=0
<pstolowski> zyga: can you ack https://github.com/snapcore/snapd/pull/6191 ?
<mup> PR #6191: cmd/snap: fix missing newline in "snap keys" error message <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6191>
<niemeyer> Son_Goku: Nice!
<niemeyer> sergiusens: Responded
<Chipaca> FTR: diff-highlight rocks
<zyga> pstolowski: looking
<pstolowski> zyga: go +2, thanks
<pstolowski> *got
<pedronis> zyga: I asked some question in the features PR
<pedronis> questions
<pedronis> I am a bit confused
<pedronis> about things that are not experimental anymore
<pedronis> and how the various bits should work for them
<pedronis> they don't seem consistent atm
 * cachio lunch
<roadmr> if a snap uses a tar.gz as its source, and I want it to build via build.snapcraft.io, can I create a github repo with just the snap/snapcraft.yaml file whose source: points to the tar.gz upstream?
<Chipaca> roadmr: aren't most of them that?
<Chipaca> bah
<Chipaca> change 'tar.gz' to 'github repo' and it's the majority of snapcrafters, afaik
<Chipaca> roadmr: e.g. https://github.com/snapcrafters/offlineimap
<Chipaca> (first one i clicked on)
<roadmr> Chipaca: but that's the thing - I don't want to change 'tar.gz' to 'github repo'
<roadmr> I specifically want to use the tar.gz because that lets me use the make plugin; the github repo requires some auto* evil I don't have time to wrestle right now
<zyga> pedronis: thanks, I'll look
<zyga> pedronis: we kept the experimental prefix for layouts for example
<zyga> pedronis: but open to suggestions
<Chipaca> roadmr: AIUI source: <url to tar.gz> should work (maybe needs source-type:)
<Chipaca> roadmr: source-type: tar
<roadmr> Chipaca: right; that looks like it'll work. I can fiddle with things from here :) thanks
<Chipaca> roadmr: https://github.com/snapcrafters/postman does that
<roadmr> thanks for tracking down an example, Chipaca !
<Chipaca> np
<mup> PR snapd#6194 opened: snap: make description maximum in runes, not bytes <Created by chipaca> <https://github.com/snapcore/snapd/pull/6194>
<zyga> Network issues
<pedronis> zyga: I think the code doesn't behave correctly where things that were experimental but now default to on
<zyga> Mvo, pedronis Iâm trying to answer from my laptop
<zyga> I agree, I will fix that
<pedronis> zyga: maybe we should have a quick HO today or tomorrow on thhis
<Chipaca> giggle
<pedronis> zyga: it seems we need files that mean negative for those, or we need run that Ensure were early in snapd, but we can't assume snapd will run before snaps
<niemeyer> Chipaca: That reflects very well the state of my brain right now :)
<zyga> re
<zyga> reconnected
<zyga> pedronis: gladly
<zyga> pedronis: hopefully my network will behave
<zyga> I have plenty of data left, just fiddled with the modem box
<pedronis> zyga: we can chat now
<zyga> HO or here on IRC?
<zyga> maybe meet, ho didn't work for me
<pedronis> meet is ok, but let me see if I can find a room for me here
<pedronis> zyga: I found a room (hopefully)
<Saviq> cachio: do you have 1910 images available for spread yet?
<mup> PR snapd#6195 opened: snapstate: update fontconfig caches on install <Created by mvo5> <https://github.com/snapcore/snapd/pull/6195>
<mvo> pedronis: ^- is probaly something you want to look at, its very simplistic right now, your input would be welcome what direction to take
<mvo> pedronis: but no rush
<pedronis> mvo: thx, I'll try to look at it today or tomorrow
<mup> PR snapd#6196 opened: Validate title <Created by chipaca> <https://github.com/snapcore/snapd/pull/6196>
<Chipaca> sergiusens: ^ title validation as per forum topic
<Chipaca> fwiw, fyi, tanstaaomb, etc
<sergiusens> ð
<sergiusens> adding tests here as well
<zyga> Heading home
<mup> PR snapcraft#2415 closed: tools: pull in imporved cla_check.py from snapd <Created by chipaca> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2415>
<sergiusens> Chipaca: https://github.com/snapcore/snapcraft/pull/2412
<mup> PR snapcraft#2412: schema: add support for title <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2412>
<mup> PR snapd#6197 opened: tests/lib: sync cla check back from snapcraft <Created by chipaca> <https://github.com/snapcore/snapd/pull/6197>
<mup> PR snapd#6198 opened: Revert "cmd/snap, tests/main/snap-info: highlight the current channel" <Created by chipaca> <https://github.com/snapcore/snapd/pull/6198>
<mup> PR snapd#6199 opened: Revert "cmd/snap, tests/main/snap-info: highlight the current channel" (2.36) <Created by chipaca> <https://github.com/snapcore/snapd/pull/6199>
<Chipaca> mvo: is that's what needed for 2.36 ^?
<mup> PR snapd#6191 closed: cmd/snap: fix missing newline in "snap keys" error message <Simple ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6191>
<zyga> re
<zyga> arrived home
<mvo> Chipaca: I think so
<zyga> hey mvo
<zyga> how's stuff?
<mvo> zyga: good, good - how are you?
<zyga> mvo: how's the experiment
<mvo> zyga: the fc-cache work? a super simple version is up for review
<zyga> oh
<zyga> looking
<zyga> just unpacking
<zyga> found it
<zyga> mvo: is that all?
<zyga> feels like a file is missing
<zyga> ah, link.go
<mvo> zyga: well, its the most simple approach I could think of
<mvo> zyga: and that means something ;)
<zyga> review sent
<mvo> ta
<zyga> Zzzz
<mwhudson> how do snapd tests test refresh?
<mwhudson> do you have a fake store or something?
<mwhudson> s/tests/integration tests/
<cachio> mwhudson, hi, there are many tests for refreshes
<cachio> some of them use the fake store
<cachio> others no
<cachio> we test core refresh and snaps refreshes
<cachio> mwhudson, what do you need?
<mwhudson> cachio: well i'm just wondering how you arrange for snap refresh to do something
<mwhudson> cachio: as that requires the store to have a new revision of a snap
<mwhudson> in my understanding anyway
<cachio> mwhudson, for that we use the fake store
<mwhudson> (context here is that i am working on a subiquity feature to offer an upgrade to a new version)
<mwhudson> cachio: is the fake store something i could run locally?
<cachio> mwhudson, yes
<mwhudson> cachio: is it documented? :)
<cachio> there are some tests on snapd which show that
<mwhudson> or at least, can you tell me where to find it
<mwhudson> is it in the snapd tree?
<cachio> tests/main/refresh/task.yaml
<cachio> in the snapd project
<mwhudson> ok
<mwhudson> i can start from there thanks :)
<cachio> basically it sets up a fake store which is configured with the snaps to refresh
<cachio> mwhudson, perhaps you should see first the refresh-all test
<cachio> tests/main/refresh-all/task.yaml
<cachio> it is much simpler
<mwhudson> is fakestore in test-snapd-tools ?
<mup> PR snapcraft#2416 closed: yaml_utils: allow unicode while encoding (#2414) <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2416>
<mwhudson> ah no
<cachio> no
<mwhudson> its in the snapd tree i see
<mwhudson> oops gotta run for a call
<cachio> test-snapd-tools is the snap to refresh
<mwhudson> cachio: thanks for the pointers so far
<cachio> mwhudson, np
<cachio> yaw
<mup> PR snapd#6200 opened: tests: fix for tests test-*-cgroup <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6200>
#snappy 2018-11-23
<AuroraAvenue> Hello Can someon tell me what the snap is called for this snap ? https://uappexplorer.com/snap/ubuntu/tor
<AuroraAvenue> Or how I get on tor on Solus OS ?
<AuroraAvenue> And why is sabdfl on this channel tonite? Is he usually here ?
<AuroraAvenue> robert_ancell ping
<robert_ancell> AuroraAvenue, hello
<AuroraAvenue> Hiya - hows the far-east these days ? Anyway I waned to ask how to gt this on my Solus OS i.e. what is the snap called ? https://uappexplorer.com/snap/ubuntu/tor
<robert_ancell> AuroraAvenue, I think it's just called 'tor' (https://snapcraft.io/tor)
<AuroraAvenue> is that the client or what ?
<robert_ancell> I don't know any more than what it says in the description
<AuroraAvenue> because it says 'client' on that wesite.
<AuroraAvenue> robert_ancell, I need help - who do I ask here ? Who knows snaps thats in the US ?
<robert_ancell> Not sure who's online now
<AuroraAvenue> Well hows NZ anyways ?
<robert_ancell> Nice any sunny today
<robert_ancell> and
<AuroraAvenue> cool stuff - sorry to bother you.
<robert_ancell> np
<AuroraAvenue> elopio, ping (maybe)
<AuroraAvenue> oh wait - it is that one. https://paste.ubuntu.com/p/8xCc8SDYmV/
<AuroraAvenue> Wit x2 there is no client
<AuroraAvenue> **Wait
<AuroraAvenue> damn it.
<AuroraAvenue> http://pasteall.org/pic/aa8ff4298c2c6315886afe1e236c8662
<AuroraAvenue> there is no client.
<AuroraAvenue> no Tor client anyway - no GUI !
<AuroraAvenue> feel lied to by Ubuntu again.
<AuroraAvenue> grumbles.
<mborzecki> morning
<dot-tobias> morning
<pstolowski> mornings
<mborzecki> pstolowski: mvo: Chipaca: morning guys
<mvo> hey pstolowski and mborzecki and zyga
<mvo> Chipaca: and good morning to you as well
<dot-tobias> morning everyone
<mborzecki> anyone objects to moving sanity check mount point to /run/snapd instead of /tmp?
<mborzecki> eg. /run/snapd/sanity-<num>
<mvo> mborzecki: that sounds fine
<mborzecki> mvo: from selinux perspective it'd probably be cleaner if we had a helper to check the mounts :/
<mborzecki> otherwise we're handing out permissions to snapd, and they don't feel enough fine grained
<zyga> hey mvo
<zyga> sorry for starting late, I needed to catch up sleep after the night before
<zyga> but all set
<zyga> mvo: I had a call with pedronis yesterday, we discussed all that's needed to get feature's exported
<zyga> I'll attack that now :)
<mvo> zyga: awesome
<mvo> zyga: I'm ready for reviews for those
<zyga> mvo: I summarized that on the PR - though in abbreviated form
<zyga> let me know if you want to know more
<zyga> but I think this is a very good design and we will be able to learn from that
<zyga> in case we need to export more stuff like I wanted with facts originally
<zyga> (facts will have the same properties)
<mvo> cool
<zyga> I think I found the cause of the bug I saw last night
<zyga> tl;dr; broken cleanup
<mborzecki> zyga: on fedora https://paste.ubuntu.com/p/8nYxtc2nHh/
<zyga> mmm, mount unit with selinux context?
<mborzecki> yes
<mborzecki> zyga: it gets more interesting https://paste.ubuntu.com/p/bRk8qdcrpM/
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6201
<mup> PR snapd#6201 opened: tests: remove test-snapd-with-configure on restore <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6201>
<mup> PR #6201: tests: remove test-snapd-with-configure on restore <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6201>
<zyga> I need a 2nd review on https://github.com/snapcore/snapd/pull/6159
<mborzecki> zyga: discarding ns in snap-mgmt would fix that too i think
<mup> PR #6159: cmd/snap-confine: handle mounted shared /run/snapd/ns <Created by zyga> <https://github.com/snapcore/snapd/pull/6159>
<zyga> we do that but the test breaks the assumptions
<zyga> it removes the snap "by hand"
<zyga> I really think we should go over all tests
<zyga> and over the prep/restore logic for all system
<zyga> and get rid of hacks
<zyga> time saved in one test is lost by time wasted debugging lots of random failures
<mvo> zyga: could we discard all namespaces in restore?
<zyga> mvo: do you know my position on prepare/restore?
<zyga> it's all broken and backwards
<zyga> pre restore in prepare
<zyga> and do nothing in restore
<zyga> we don't discard namespaces on core, looking at the maze that our restore logic is
<zyga> s/pre restore/we restore/
<zyga> restore_suite_each is { true }
<zyga> prepare_suite_each is calling reset.sh with a --reuse-core
<zyga> mvo: if you are asking if we could do this better then the answer is yes
<mborzecki> zyga: #6201 should probably go to 2.36
<mup> PR #6201: tests: remove test-snapd-with-configure on restore <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6201>
<zyga> mborzecki: as in for stable update? won't hurt I suppose
<mborzecki> zyga: can you take a look at the build log in https://github.com/snapcore/snapd/pull/6189 ?
<mup> PR #6189: daemon, vendor: bump github.com/coreos/go-systemd/activation, handle API changes (2.36) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6189>
<zyga> mvo: I'm happy to make parepare/restore measureably better at some point
<zyga> mborzecki: sure
<zyga> build log or task failures?
<mvo> zyga: ok
<mborzecki> task failure
<zyga> mborzecki: I saw that myself once
<zyga> mborzecki: not 100% sure but I suspect it's a bug in how we prepare against the snapd in edge
<zyga> is this branch based on older master?
<zyga> mborzecki: after we removed quirks
<mborzecki> it's 2.36 + a backport of some commits unrelated to what's failing
<zyga> this bug started to show up on branches
<zyga> that were using old master (before quirk removal)
<zyga> mborzecki: it looks like we are taking snap-confine apparmor profile
<zyga> from edge
<zyga> where it has fewer permissions
<zyga> I didn't debug it further though
<zyga> perhaps after the repackaging magic
<zyga> after snapd has ran and loaded the per-core-rev snap-confine profile
<zyga> it doesn't do that again
<zyga> and we run with profile from edge with code from master
<zyga> er
<zyga> not from master, from the branch being tested
<zyga> and the branch being tested needs more permissions
<zyga> I suspect if you run this with debug
<zyga> and inspect the on disk per-revision profile
<mborzecki> zyga: funny thing is, there's nothing in dmesg about denials, idk if it's surpressed or sth
<zyga> you will not see the quirks permissions anymore
<zyga> but that branch surely needs them since it is 2.36
<zyga> mborzecki: yes, they are supressed
<zyga> they easily get rate limited-lost
<mborzecki> maybe we should use audit instead
<mborzecki> configure auditd with a reasoanble buffer
<zyga> dunno
<zyga> I use audit on suse because dmesg doesn't have denial messages
<mborzecki> (actually have a change like this for fedora/centos)
<mborzecki> yeah, afaik once auditd is urnning denials go there
<zyga> mborzecki: if you debug this I'd love to know where the mistake is
<zyga> is it in snapd
<zyga> or is it in the repackaging magic
<zyga> mvo: I double checked, we remove each snap in prepare
<zyga> mvo: except bases
<zyga> mvo: which we collect and remove at the end
<zyga> mborzecki: https://botland.com.pl/pl/raspberry-pi-hat-komunikacja/10602-pi-top-laptop-modulowy-raspberry-pi-3-model-b-v2.html
<zyga> :D
<zyga> pi3 laptop for 446zÅ net
<zyga> maybe ;D
<zyga> would be nice for debugging pi issues without having to worry about screen/keyboard as always?
<mborzecki> heh :)
<mborzecki> zyga: i'm more into this https://botland.com.pl/pl/microbit-zestawy-edukacyjne/8574-microbit-go-bbc-modul-edukacyjny-cortex-m0-akcelerometr-bluetooth-led-5x5-akcesoria.html
<zyga> 95zÅ!
<zyga> not sure
<zyga> what for, for kids?
<mborzecki> yeah
<mborzecki> have various stm32f{0,1,3} boards around but too complicated to give those to the kids
<zyga> yeah
<zyga> well
<zyga> either your kids speak englisb
<zyga> or the bbc micro has nice localized material to follow
<zyga> not sure if worth the money TBH
<pstolowski> ic Chipaca off today?
<zyga> not sure
<zyga> haven't seen him though
<zyga> pstolowski: ^ what do you think about pi-top deal above?
<pstolowski> zyga: oh wow, interesting! but i'd rather pick regular rpi3
<zyga> pstolowski: pi is inside :)
<zyga> it's just a hat on top a regular pi
<zyga> (you can also upgrade the pi eventually though given what the foundation has said I think pi3 is the end of the current line)
<pstolowski> zyga: i know i know, but pi3 will be 3x cheaper (although, the price for this thing is very good - if that's what you want)
<zyga> yeah :-)
<zyga> convenience for having pi with screen/keyboard/power and less cables and fuss to worry about
<Chipaca> pstolowski: not away, but not 100% here yet
<mup> PR snapd#6202 opened: tests: restore in restore, not in prepare <Created by zyga> <https://github.com/snapcore/snapd/pull/6202>
<zyga> brb, cold, making hot tea
<mup> PR snapd#6201 closed: tests: remove test-snapd-with-configure on restore <Simple ð> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6201>
<Chipaca> snap run test-snapd-xdg-autostart.foo
<Chipaca> cannot create temporary directory for /var/lib/snapd mount point: Permission denied
<Chipaca> zyga: ^ is that interesting to you?
<zyga> nah, why would it be :)
<zyga> Chipaca: this is the same as mborzecki noticed earlier today
<pstolowski> mborzecki: didn't you look at https://bugs.launchpad.net/snapd/+bug/1775340 ?
<zyga> let me find that
<mup> Bug #1775340: Make snapd zsh aware <snapd:Triaged> <https://launchpad.net/bugs/1775340>
<zyga> Chipaca: https://pastebin.ubuntu.com/p/rmcTXPjYfx/
<zyga> Chipaca: it's a bug in our prepare restore as far as I know
<zyga> Chipaca: but not 100% sure as I didn't debug further
<pstolowski> Chipaca: did https://bugs.launchpad.net/snapd/+bug/1801955 land in 2.36.1 already?
<mup> Bug #1801955: snapshot fails if unknown user in /home <snapd:In Progress by chipaca> <https://launchpad.net/bugs/1801955>
<zyga> Chipaca: is this also on 2.36 -based branch?
 * Chipaca hugs pstolowski for doing this bug thing
<Chipaca> zyga: yes
<zyga> Chipaca: so very likely the same issue
<pstolowski> Chipaca: you will hate me by eod ;)
<zyga> Chipaca: if you cannot fix it in 30 mintues I can look, just trying to wrap up this thing that spawned into a chain of other things
<Chipaca> pstolowski: nope
 * Chipaca EODs
<zyga> Chipaca: (pawel will assign all open bugs to you ;)
<zyga> ha
<zyga> hahaha
<zyga> :D
<pstolowski> lol
<pstolowski> Chipaca: also, any conclusion re that macaroon thing?
<Chipaca> pstolowski: $ git tag --contains d062f3f2d2a529b0d329df7f0f2c2713d0927af9
<Chipaca> pstolowski: nothing
<Chipaca> pstolowski: so, no, not in 2.36.1
<pstolowski> Chipaca: k, thanks
<Chipaca> pstolowski: re that macaroon, IIRC (but it was long ago so), we couldn't reproduce it back then either
<zyga> have I mentioned that shell sucks today?
<zyga> message of the day: shell sucks
<zyga> there
<zyga> now I feel better
<zyga> for n in *.dupa; do echo $n; done
<Chipaca> zyga: echo "shell sucks." > ~/.motd
<zyga> why the hell did people did this
<zyga> why why why
<zyga> it's so insane
<Chipaca> zyga: ?
<pstolowski> Chipaca: ok, interesting :). closing then
<zyga> Chipaca: run that
<zyga> did you expect *.dupa
<zyga> (sorry about the name)
<Chipaca> yes
 * zyga hugs chipaca
<Chipaca> Â¯\_(ã)_/Â¯
<zyga> I know this happens but every time I write some more code and hit this I hate myself
<Chipaca> zyga: stop writing that sort of code then
<Chipaca> zyga: find -name \*.dupa ftw
<zyga> that's not the same meaning :)
<zyga> but yeah
<Chipaca> zyga: -maxdepth 1
<zyga> shell is suuuucky
<zyga> see
<Chipaca> zyga: -also-i-don't-want-dotfiles
<Chipaca> zyga: -dwim
<Chipaca> zyga: -dwimnwis
<Chipaca> zyga: -just-work-already
 * Chipaca stops
<zyga> Chipaca: git grep -E 'for [[:alpha:]]+ in .+[*].*'
<mvo> Chipaca: heh
<zyga> we are all guilty of that :)
 * mvo hugs zyga and Chipaca 
 * zyga goes to fix it
<zyga> eh
<mvo> Chipaca: I remember a long time ago when I was teaching people unix and find - oh boy
<mvo> find is really not that easy to explain at least to beginners
<Chipaca> find: warning: you have specified the -maxdepth option after a non-option argument -name, but options are not positional (-maxdepth affects tests specified before it as well as those specified after it). Please specify options before other arguments.
<Chipaca> that's the point where you duck, as your students hurl their computers at you
<zyga> Chipaca: this is like python range(0) returning ["range(0)"] because FU that's why
<zyga> and people coding around it with isinstance(int)
<zyga> eh :)
 * zyga feels better by removing this from the tree
<Chipaca> well
<Chipaca> what
<Chipaca> no it doesn't
<mvo> Chipaca: haha - yes
<zyga> right?
<zyga> because it's sane
<zyga> and shell is insane
<Chipaca> zyga: no really range(0) does not return ["range(0)"]
<Chipaca> and, in python, range objects have len, so if you need to know before looping you can
<zyga> Chipaca: I know, I meant that this is equally crazy to a hypothetical python behavior where range(0) returning ["range(0)"]
<Chipaca> ah
<Chipaca> oh
<Chipaca> wait i have a gif for this
<Chipaca> http://i.imgur.com/NU3KE.gif
<tomwardill> that is a good gif
<pstolowski> Chipaca: I suppose this is fixed in snapd? https://bugs.launchpad.net/snapd/+bug/1751447
<mup> Bug #1751447: snapstore and review-tools use the wrong regexp for snap names <Canonical Click Reviewers tools:Fix Released by chipaca> <review-tools:Fix
<mup> Released by jdstrand> <Snapcraft:Fix Released by chipaca> <snapd:In Progress by chipaca> <Snap Store:Fix Released> <https://launchpad.net/bugs/1751447>
<zyga> Chipaca: shellcheck doesn't like loops over for
<zyga> recommends while read loop
<zyga> *sigh*
<zyga> https://github.com/koalaman/shellcheck/wiki/SC2044
<zyga> and the solution doesn't works in sh
<zyga> heh
 * zyga just stops
<Chipaca> zyga: what
<Chipaca> pstolowski: yes, that's fixed
<Chipaca> fix-released even
<pstolowski> Chipaca yep, thanks
<Chipaca> zyga: which is the for loop it doesn't like?
<pstolowski> zyga: can you quickly assess https://bugs.launchpad.net/snapd/+bug/1803210 ?
<mup> Bug #1803210: snap's device cgroup is not discarded upon uninstall <snapd:New> <https://launchpad.net/bugs/1803210>
<zyga> pstolowski: true
<zyga> pstolowski: ancient
<zyga> Chipaca: I converted one for loop to find and ran shellcheck
<pstolowski> zyga: hm, it's from 2 weeks ago?
<zyga> pstolowski: the behavior is true since snapd v1
<zyga> we never ever did anything about those
<pstolowski> zyga: ah, in that sense
<pstolowski> zyga: confirm+low?
<zyga> no idea what the priority is
<zyga> but confirmed
<pstolowski> fair enough
<pstolowski> thx
<pstolowski> if it's since forever and nothing exploded, it looks low/medium to me
<zyga> yeah
<Chipaca> zyga: can you show me?
<zyga> https://www.irccloud.com/pastebin/YtRQUGYI/
<zyga> Chipaca: patch in https://github.com/snapcore/snapd/pull/6203
<mup> PR #6203: tests: discard mount namespaces in reset.sh <Created by zyga> <https://github.com/snapcore/snapd/pull/6203>
<zyga> Chipaca: at this rate I'm closer to saying that perl is better
<Chipaca> zyga: that 'cannot create temporary directory for /var/lib/snapd mount' thing, is it expected to just go away or do i need to do something?
<Chipaca> getting it repeatedly
<mup> PR snapd#6203 opened: tests: discard mount namespaces in reset.sh <Created by zyga> <https://github.com/snapcore/snapd/pull/6203>
<zyga> Chipaca: you need to do something
<zyga> it's a bug in our test code or in snapd
<zyga> snap-confine profile in edge is more restrictive
<Chipaca> zyga: so it isn't that it doesn't like for loops, it doesn't like for loops over find
<Chipaca> i agree with it on this :-)
<Chipaca> zyga: what's the body of the loop?
<zyga> repackaging for tests and all the other jazz we do should make the profile from the branch (more permissive) active
<zyga> but it seems we missed something and it's not working for real
<zyga> snap-confine profile changes that remove permissions are rare so we didn't observe this before
<zyga> Chipaca: loop is https://github.com/snapcore/snapd/pull/6203/commits/0e13a3077f4318091e05f90005c8f970461087c3
<mup> PR #6203: tests: discard mount namespaces in reset.sh <Created by zyga> <https://github.com/snapcore/snapd/pull/6203>
<zyga> I know about -exec and stuff
<zyga> just feels like I shouldn't have to
<Chipaca> zyga: try find .... | while read
<Chipaca> see what shellcheck thinks of that
<zyga> the wiki has a comprehensive list of solutions
<zyga> look at that please
<zyga> they all turn a one liner into a body of code
<mup> PR snapd#6204 opened: daemon: remove enableInternalInterfaceActions <Created by zyga> <https://github.com/snapcore/snapd/pull/6204>
<zyga> pstolowski: ^
<pstolowski> zyga: wow, interesting, i've never stumbled on it
<Chipaca> zyga: wrt while, the read solution is correct, but while read < <( find ) is a bashism; find | while read would work everywhere
<Chipaca> zyga: wrt enableInternalInterestingInsects, maybe it's time to run 'unused' again
<zyga> Chipaca: mmm
<zyga> +1
<Chipaca> it says makeHttpClient is unused
<Chipaca> etc etc
<zyga> burn with fire
<zyga> Chipaca: also, would you be ok with splitting api.go
<zyga> api_debug.go api_interfaces.go
<Chipaca> zyga: i already have
<zyga> ...
<zyga> oh, perfect
<Chipaca> zyga: api_snapshots
<zyga> so can be done on a drive-throuh basis?
<zyga> cool, didn't notice
<zyga> api.go makes vim unhappy :)
<Chipaca> i don't agree with vim a lot, but i'm with it on this
<Chipaca> or as it would put it, beep beep angry flash beep delete half the text
 * zyga loves the look of https://github.com/pkg/errors
<zyga> mvo: ^
<zyga> back to crufty stuff
<zyga> eh
<zyga> obviously
<zyga> I ran a test that failed in https://github.com/snapcore/snapd/pull/6202 and it passed
<mup> PR #6202: tests: restore in restore, not in prepare <Created by zyga> <https://github.com/snapcore/snapd/pull/6202>
<zyga> because some other test broke the state
<zyga> gosh I hate this test suite today
 * pstolowski lunches
<Chipaca> whoa, ineffective break statement
<mvo> zyga: interessting, I read that after lunch
<mup> PR snapd#6205 opened: many: staticcheck fixes <Created by chipaca> <https://github.com/snapcore/snapd/pull/6205>
<Chipaca> ^ a couple of serious ones in there
<Chipaca> (most are arguably innocuous)
<zyga> Chipaca: in similar vein https://github.com/snapcore/snapd/pull/6206
<mup> PR #6206: many: fix composite literals with unkeyed fields <Created by zyga> <https://github.com/snapcore/snapd/pull/6206>
<zyga> Chipaca: many vet fixes
<zyga> Chipaca: oh, I see you fixed the same bug :)
<Chipaca> zyga: https://github.com/dominikh/go-tools/tree/master/cmd/keyify
<mup> PR snapd#6206 opened: many: fix composite literals with unkeyed fields <Created by zyga> <https://github.com/snapcore/snapd/pull/6206>
<mup> PR snapd#6207 opened: mkversion: use "test -n" rather than "! test -z" <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6207>
<mup> PR snapd#6208 opened: run-checks: assorted fixes <Created by zyga> <https://github.com/snapcore/snapd/pull/6208>
<zyga> mmm
<zyga> nice
<zyga> I wish I'd known :)
<mup> PR snapd#6209 opened: run-checks: discard test good/bad banner <Created by zyga> <https://github.com/snapcore/snapd/pull/6209>
<zyga> sorry for the noise
<zyga> slowly unwinding the stack of stuff
<mup> PR snapd#6210 opened: many: run go fmt ./ <Created by zyga> <https://github.com/snapcore/snapd/pull/6210>
<Chipaca> of course a freshly pulled staticcheck breaks with 1.6 :-(
<Chipaca> BOO
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/6205/commits/02af5cde6a8fdb86c1ee08979ca195c8fa37c367
<zyga> should all of those have a type?
<mup> PR #6205: many: staticcheck fixes <Created by chipaca> <https://github.com/snapcore/snapd/pull/6205>
<mup> PR snapd#6202 closed: tests: restore in restore, not in prepare <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6202>
<Chipaca> zyga: i tried, but then it kinda explodes
<Chipaca> (give it a try locally you'll see what i mean)
<zyga> mhm
<Chipaca> all those foo == opBAR checks would need an operator(foo) == opBAR
<Chipaca> which seems silly
<Chipaca> there's no real type safety to be had
<zyga> mvo, Chipaca: can you eyeball https://github.com/snapcore/snapd/pull/6203
<zyga> this is the blocker for my unwind stack
<mup> PR #6203: tests: discard mount namespaces in reset.sh <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6203>
<zyga> and standup time
<Chipaca> zyga: no sorry i have a meeting with these guys
<zyga> and chrome still sucks
<zyga> man
<Chipaca> pedronis: we're assuming you can't make it today
<pstolowski> mborzecki: didn't you look at https://bugs.launchpad.net/snapd/+bug/1775340 ?
<mup> Bug #1775340: Make snapd zsh aware <snapd:Triaged> <https://launchpad.net/bugs/1775340>
<mborzecki> pstolowski: briefly, the problem is still there
<pstolowski> mborzecki: k, thanks
<mborzecki> pstolowski: (at least on ubuntu)
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/6210 makes me sad, means that we cannot go fmt and expect to land things
<mup> PR #6210: many: run go fmt ./ <Created by zyga> <https://github.com/snapcore/snapd/pull/6210>
<Chipaca> zyga: stop using 1.11 :-)
<zyga> Chipaca: I'll take that 2.36 bug now
<Chipaca> zyga: you are made of rocks
<zyga> mborzecki: still hoping for that https://github.com/snapcore/snapd/pull/6111 :D
<mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<zyga> trying to close cards if I can
<mborzecki> on it
<zyga> thanks
<zyga> consider it agreed that the rpm logic will move back to spec file
<zyga> and snapd.mk will include a control file that has variable defs
<zyga> Chipaca, pstolowski: can you please review https://github.com/snapcore/snapd/pull/6203
<mup> PR #6203: tests: discard mount namespaces in reset.sh <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6203>
<zyga> it's simple and blocks other fixes from landing
<Chipaca> zyga: doesn't that have the "for foo in *.blah" problem?
<zyga> it does
<Chipaca> i guess the || true and the f on the rm fixes those
<zyga> it doesn't explode though
<zyga> || is for unmount being not needed
<zyga> it's not strictly for the *.shit
<zyga> I'm happy to do a pass specifically to use a less broken idiom
<zyga> but I need to pop the stack to get to 0 at some point
<Chipaca> zyga: monday
<zyga> question is wich Monday ;)
<Chipaca> zyga: one that ends in a k
<zyga> pstolowski: trivial fix in https://github.com/snapcore/snapd/pull/6177
<mup> PR #6177: interfaces: draft of LimeSDR hotplug interface <Hotplug ð> <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6177>
<zyga> now really fixing 2.36
<pstolowski> zyga: uh oh, thanks.
<pstolowski> zyga: +1 to reset ns PR, with 1 suggestion
<zyga> thanks looking
<zyga> Chipaca: can you make sense of this:
<zyga> https://www.irccloud.com/pastebin/JyNfmgcG/
<zyga> is it because version has no "git" in it?
<zyga> nah, git is optional
<zyga> tracking edge vs stable!
<zyga> eh :/
<zyga> but .. why?
<zyga> another prepare/restore woe
<Chipaca> zyga: isn't that what you're changing? edge to stable for 2.36?
 * Chipaca doesn't know
<zyga> Chipaca: no, it was a random failure
<Chipaca> lel
<Chipaca> zyga: look for a store error in logs?
<zyga> thanks
<mvo> zyga: I have a look, in a meeting right now
<Chipaca> ok peeps, i'm wrapping up for the day. Mostly. Will be back online once I'm at the mothership.
<Chipaca> have a lovely weekend if I don't see you before you EOW, and see you Monday!
<pstolowski> mvo: do we want a dedicated client error type of dns errors (would affect gnome software i suppose)?
<pstolowski> s/of/for/
<zyga> re
<zyga> back from walk and dinner
<zyga> man it's so cold and dark already
<zyga> it's barely 5PM
<roadmr> zyga: northern winter heh
<zyga> it's not even winter yet
<zyga> I got a new pair of gloves that should work for cold days
<zyga> old gloves were thin and light but not much warm
<zyga> man, I don't miss winter :?
<zyga> :/
<roadmr> zyga: crappy gloves are better than no gloves heh
<mvo> pstolowski: I think we want this, for the impact of a decidcated client error for dns error on gnome-software robert-ancil will know
<mvo> zyga: back, anything I miseed? had a bunch of meetings
<zyga> trying to reproduce the 2.36 branch issue
<zyga> no success
<pstolowski> mvo: ack, thanks
<zyga> so it's not only a bug but also a test affecting it
<zyga> somehow the test suite hates me and throws logs everywhere I go, it seems :)
<zyga> mvo: does this ring any bells? https://www.irccloud.com/pastebin/H8FyPMX5/
<mvo> zyga: it does not
<zyga> hmm, thanks
<mvo> zyga: config leftover maybe?
<zyga> mvo: given that prepare/restore landed
<mvo> zyga: maybe the timer test ran before the schedule test or something
<zyga> I can start attacking test cleanup issues
<cachio> zyga, I can contribute testing this change
<zyga> cachio: thank you!
<zyga> cachio: I think we will find things misbehaving but now, with restore being done, we can start to put code that checks pre-prepare and post-restore state
<zyga> last time I looked we leaked processes, packages and some files (though I bet we fixed many of those over time)
<cachio> perfect
<cachio> zyga, I'll start now
<cachio> I'll send you what I found
<zyga> thank you!
<cachio> also I want to test that change on dvices
<zyga> mvo: still no luck with 2.36 issue, cannot reproduce it
<zyga> cachio: https://github.com/snapcore/snapd/pull/6208 needs a second review, perhaps you could have a look
<mup> PR #6208: run-checks: assorted fixes <Created by zyga> <https://github.com/snapcore/snapd/pull/6208>
<zyga> oh
<zyga> mvo just posted one :)
<zyga> but still useful
<cachio> zyga, sura
<cachio> sure
<zyga> mvo: if you are on a spree: https://github.com/snapcore/snapd/pull/6207
<mup> PR #6207: mkversion: use "test -n" rather than "! test -z" <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6207>
<zyga> haha
<zyga> you did
<zyga> man I should just shut up and look :)
<mup> PR snapd#6207 closed: mkversion: use "test -n" rather than "! test -z" <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6207>
<mup> PR snapd#6208 closed: run-checks: assorted fixes <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6208>
<cachio> zyga, it is merged :)
<mvo> zyga: heh, yeah, was looking at reviews
<mvo> zyga: nice stuff
<zyga> the completion tests are failing more than usual
<mup> PR snapd#6204 closed: daemon: remove enableInternalInterfaceActions <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6204>
<zyga> mvo: can you please review https://github.com/snapcore/snapd/pull/6159
<mup> PR #6159: cmd/snap-confine: handle mounted shared /run/snapd/ns <Created by zyga> <https://github.com/snapcore/snapd/pull/6159>
<zyga> once the fix for the stray mount namespace is merged this can also go in
<zyga> and unblock features
<mup> PR snapd#6198 closed: Revert "cmd/snap, tests/main/snap-info: highlight the current channel" <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6198>
<mup> PR snapd#6197 closed: tests/lib: sync cla check back from snapcraft <Created by chipaca> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6197>
<mup> PR snapd#6210 closed: many: run go fmt ./ <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6210>
<zyga> mvo: https://github.com/snapcore/snapd/pull/6196#discussion_r235994155
<mup> PR #6196: many: validate title <Created by chipaca> <https://github.com/snapcore/snapd/pull/6196>
<mup> PR snapd#6203 closed: tests: discard mount namespaces in reset.sh <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6203>
 * cachio afk
 * zyga fights spread
<zyga> though I should EOD
<zyga> let's :)
 * zyga EODs
<cachio> zyga, good weekend
<cachio> I'm over the completion errors now
<zyga> :-)
<zyga> thank you
#snappy 2018-11-24
<Xceed> hi, i issue a .. snapcraftctl set-grade "$GRADE" ... within `override-pull` in yaml. However, after the stage `override-prime` i see output .. 'grade' property not specified: defaulting to 'stable' .. anyone know how to make global a correctly set $GRADE value from a scriptlet ?
<Xceed> ^ answer.. "adopt: my-part" is a requirement.
<Xceed> i have two repos on my snappy web account, how do i delete one, the delete button keeps saying there is an issue doing the request
#snappy 2018-11-25
<Xceed> ^ JamieBennett, ogra
<popey> Xceed: sounds like a bug, there's a link to file a bug at the bottom of the page
<Xceed> popey can i pm you ?
<popey> sure, but I'm playing rust right now so might not be super responsive ;)
<Xceed> heh, fair enough
#snappy 2019-11-18
<mup> PR snapd#7745 opened: snap-bootstrap: add go-flags cmdline parsing and tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/7745>
<mborzecki> morning
<zyga> Hey
<mborzecki> zyga: hey
<mvo> hey zyga
<mborzecki> zyga: taking swap days?
<zyga> Need to decide when first
<zyga> mvo: how is your jet lag today?
<mvo> zyga: horrendous
<zyga> I feel I can only sleep for two or three hours at a time
<mvo> zyga: couldn't sleep most of the night
<zyga> Barely slept last night
<mvo> zyga: same here, super nasty
<zyga> I had dinner at 4am
<zyga> I need to sort out my stuff and pick up the laptop from service
<zyga> I will do H-BS-R training today if you donât mind
<mvo> zyga: lol@training
<mvo> zyga: sure, go for it
<mvo> zyga: I try to start with some simple uc20 things, like the initramfs mount helper stuff we talked about with xnox, I hope to have an initial PR up today
<mborzecki> zyga: want to talk about the mount thing from last week later today? (i'm sitting at mcdonald's right now, car in the shop)
<zyga> mborzecki: yeah
<zyga> I have a 121 at 10:00
<zyga> When would be a good time?
<mborzecki> zyga: 12?
<zyga> Sounds good
<mborzecki> zyga: i should be back home around 1030 hopefully
<zyga> I need a moment before I start work today
<zyga> Maybe an hour of sleep
<mborzecki> hmm wonder whther cachio managed to update the arch images on friday
<mup> PR snapd#7739 closed: tests: moving arch linux to unstable <Created by sergiocazzolato> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7739>
<mborzecki> duh, our spread images of debian sid have fwupd-refresh.service enabled :/
<mvo> mborzecki: there are prs for this
<mvo> mborzecki: 7742 fixes debian to be less unstable
<mborzecki> mvo: right, though, we don't really need fwupd running :P
<mvo> mborzecki: yeah, it seems to be running on a lot of the images
<mvo> mborzecki: but yeah, I'm all for killing it :)
<mvo> mborzecki: arch works currently btw, the degraded test is disabled there. but yeah, revreting this would be nice
<mvo> mborzecki: fwiw, 7745 is green (fresh from this morning) and should be a super simple review *nudge* :)
<mborzecki> mvo: already got it opened in a tab
<mborzecki> mvo: going trough ian's PR first
<mvo> mborzecki: sure, there is no hurry for mine, the followup will be more interessting hopefully
<mborzecki> mvo: think we can land #7742 ?
<mup> PR #7742: tests: reset failing "fwupd-refresh.service" if needed <Created by mvo5> <https://github.com/snapcore/snapd/pull/7742>
<mvo> mborzecki: yeah, lets unblock the world and then fix it
<mvo> mborzecki: I think sergio can just remove the package from the images hopefully
<mup> PR snapd#7742 closed: tests: reset failing "fwupd-refresh.service" if needed <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7742>
<mborzecki> mvo: yeah, not much use for fwupd in the cloud, though there might be a spread test that checks fwupd, so just disabling/masking fwupd-refresh should be enough
<mvo> mborzecki: +1
<mvo> mborzecki: ok
<mborzecki> mvo: https://paste.ubuntu.com/p/8f2MyCMSdr/ duh
<mvo> mborzecki: fun
<mvo> mborzecki: I think there was a recent merge for some motd-fixes, looks like the fix does not work. tests ftw!
<pstolowski> morning
<mborzecki> pstolowski: hey
<pstolowski> hey mborzecki
<pstolowski> mvo: welcome back!
<mvo> hey pstolowski - good morning!
<pstolowski> oh wow, i really love my flight option to frankfurt, and it is cheap
<mborzecki> pstolowski: heh, wish they didn't kill all flights to/from LCJ
<mborzecki> off to pick up the car and driving back home
<mup> PR snapd#7737 closed: overlord: mock device serial in gadget remodel unit tests <Simple ð> <Test Robustness> <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7737>
<mborzecki> re
<mvo> welcome back mborzecki
<mborzecki> still wondering why people would have both docker.io and docker snap installed on a single host
<ogra> mvo, zyga, i see some very weird system-files interface behaviour here ... i tried locally building an app using system-files giving access to a file in /etc/systemd ... connected the interface wrote the file ... purged the snap ... then i changed the snap to use a layout instead and dropped the interface completely ... the layout worked and didnt complain
<ogra> mvo, zyga, trying teh same snap on another machine rightly complains that layouts in /etc/systemd affect the host ... yet there is no system-files interface to be seen anywhere
<mborzecki> interesting question in the forum: https://forum.snapcraft.io/t/ubuntu-core-vs-yocto-and-resinos/5266/13
<ogra> i.e. the interface doesnt seem to have been disconnected when i purged the package on the original machine
<ogra> and snap conenctions does not show it anymore
<mup> PR snapd#7746 opened: snap-bootstrap: implement "snap-bootstrap initramfs-mounts" <Created by mvo5> <https://github.com/snapcore/snapd/pull/7746>
<ogra> ... but i can still fully access the file on this machine
<mvo> xnox: hey, are you around today?
<mvo> ogra: uh, that sounds like a interessting question - maybe pstolowski can have a look, I'm way too jetlagged today. or I can dig later this weeek
<pstolowski> mvo, ogra sure, i can take a look. ogra, can you grab state.json and apparmor profile of that snap from the original machine? can you share the snap so i can try it?
<mborzecki> pstolowski: some comments under #7686
<mup> PR #7686: systemd: handle preseed mode <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7686>
<pstolowski> mborzecki: ty
<mup> PR snapd#7730 closed: spread: fix typo in spread suite <Created by sparkiegeek> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7730>
<ogra> pstolowski, https://github.com/slimjim777/logsync/pull/1 i first added the top three commits ... the issue occured with the fourth commit of this PR (when i found i can use a layout (which wasnt really true))
<mup> PR slimjim777/logsync#1: some fixes  <Created by ogra1> <https://github.com/slimjim777/logsync/pull/1>
<pstolowski> ogra: ack
<mup> PR pc-amd64-gadget#24 opened: gadget.yaml: do not use CamelCase for names <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/24>
<ogra> pstolowski, https://people.canonical.com/~ogra/snappy/state.json
<pstolowski> ogra: uh, that reveals your macaroon, better take it down
<ogra> oops
<mborzecki> or logout
<pstolowski> yeah, and logout
<ogra> cjwatson, i know there was a bug for this but i can not find it (though it might be a new issue) ... https://forum.snapcraft.io/t/getaddrinfo-enotfound-github-com-builds-failing-on-snapcraft-io-due-to-network-problems/14164
<ogra> (seems npm doesnt pick up the proxy settings on the lp builders)
<cjwatson> ogra: That just means some bit of their build system is ignoring the configured proxy
<ogra> ah, so its an electron-packager bug then
<cjwatson> Not specifically npm - you can see that registry.npmjs.org requests are working just fine and getting 200 responses
<ogra> k
<cjwatson> It'll be some random node module's postinstall script probably
<cjwatson> Maybe electron-packager, I'm not sure
<cjwatson> I'll respond on the forum
<ogra> thanks !
<popey> mbriza: hiya.
<mbriza> popey: hi! i'm getting the 'system does not fully support snapd: cannot mount squashfs image using "squashfs": mount' error
<popey> What OS?
<mbriza> but i can't find the reason it's failing actually, there's just about 5 different possible reasons listed in the error message
<mbriza> fedora 31
<mbriza> is there a verbose mode or something
<popey> there is SNAPD_DEBUG=1 and SNAPD_DEBUG_HTTP=7 for debugging store conversations.
<popey> systemd.setenv=SNAPD_DEBUG=1  might do it?
<ogra> well ... does that kernel actually have squashfs support ? (grep squash /proc/filesystems)
<mbriza> ogra: yes, i googled it for a bit and i made sure squashfs and loop devices are available
<ogra> also, does it support loop devices ... (ls /dev/loop-control ... or ls /dev/loop*)
<ogra> ah, snap :)
<mbriza> popey: https://paste.centos.org/view/0919773d this is the output when running install with SNAPD_DEBUG=1
<mbriza> i also added it to the snapd service and restarted it but there doesn't seem to be anything very interesting in the journal
<popey> ok, so you can ignore the reexec issue
<mbriza> i'm also running with selinux in permissive mode to be sure
<popey> are you able to manually mount a random squashfs file? (like your own home-created snap)?
<ogra> did you try to manually mount a snap ?
<ogra> haha
<popey> you type too slow :)
 * ogra shuts up now
<mbriza> yes, i can
<popey> which instructions are you using to install snapd?
<mbriza> https://snapcraft.io/docs/installing-snap-on-fedora
<popey> oh, also `snap version`?
<mbriza> snap    2.42.1-1.fc31
<popey> ok, installing fedora 31 on my big machine to test
<mbriza> i had a completely different set of issues on my f31 machine on friday though... i was at least able to install snaps :D
<mbriza> this is a different machine
<popey> yeah, very odd
<popey> well, virtualbox is broken for me on 19.10, so that stops that. Bah
<ogra> i thought you said you'D install on your BIG computer ! https://pl.wikipedia.org/wiki/Cray_X-MP#/media/Plik:EPFL_CRAY-I_1.jpg
<popey> mbriza: what version of snapcraft built the snap you're having trouble with?
<popey> not that big, but it's heavy :)
<mbriza> popey: i can't install any snap
<popey> ok
<popey> not even "snap install hello-world"
<mbriza> yup
<popey> https://www.entroware.com/store/athena  - big machine :D
<popey> ok, this is more serious. Do you have a funky kernel, or a stock Fedora supplied one?
<ogra> popey, yeah, but it has a keyboard on the seat !
<mbriza> nothing funky, not even closed source graphics drivers or anything
<mbriza> i just updated the machine this morning
<popey> hmmm
<ogra> do you know what exactly got updated ?
<ogra> (and did it work at any point in time on that machine)
<mbriza> basically everything, i was gone for almost 3 weeks :) i didn't have snap installed for quite some months but i remember it working at some point in the past
<mbriza> i think i removed it either because of a package conflict between upgrades (i upgrade rather soon in the fedora devel cycle) or disk space
<popey> Looks like I need virtualbox test build to get this working on linux 5.3. On that then installing fedora 31 and updates to see what happens here. Will take a while. Sorry.
<mbriza> np, i'll just lurk here or on the forums to work this out
<popey> actually, i can install clean on my x220. will do that from a usb key.
<mbriza> anyway, there's nothing too funky about neither of my systems, i think i'm fairly capable of keeping the system in a workable state
<mbriza> are there any conflicts with virtual machines or something like that?
<mbriza> i'm running something in qemu-kvm most of the time
<popey> no, I run in all manner of distros in vm's all the time
<Chipaca> mbriza: I'm sorry if you already answered this: can you mount a snap by hand?
<mbriza> Chipaca: i can
<Chipaca> mbriza: what does dmesg say when you do?
<mbriza> Chipaca: [ 2973.344224] SELinux: security_context_str_to_sid(system_u:object_r:snappy_snap_t:s0) failed for (dev loop1, type squashfs) errno=-22
<mbriza> but i'm in permissive mode
<mbriza> the error message from snap itself is extremely vague, listing like 5 different possible reasons why it could be failing... pretty hard to debug from my side
<Chipaca> mbriza: mount is very vague with its errors
<popey> (I'm inclined to agree with that. The error about re-exec not working should be informational, but it doesn't make that clear)
<Chipaca> mbriza: which is why that check exists in the first place (getting that vague an error during install is even worse0
<Chipaca> mbriza: are you also able to mount a snap by hand if you put that snap in /tmp ?
<Chipaca> popey: which error about re-exec not working?
<popey> https://paste.centos.org/view/0919773d
<mbriza> Chipaca: yes
<popey> that's mbriza's output
<popey> (I am still confused why you're getting a _multi_ snap)
<Chipaca> ah
<popey> it should be amd64 for your machine. Must be erroneous binaries in there somehow
<Chipaca> popey: you get multi when you have architectures: [amd64,i386], don't you
<mbriza> i can fetch the other one but both of them worked on the laptop
<mbriza> and both of the machines are amd64
<Chipaca> popey: and you'd have that architectures when it was i386 binaries for example
<mbriza> and then again, this is failing even when i try to install hello-snap from the store
<Chipaca> mbriza: that error you get is not about the snap
<Chipaca> mbriza: that error is from a sanity check performed before any operation is attempted
<Chipaca> mbriza: did you go into permissive mode after starting snapd?
<mbriza> i restarted snapd multiple times in the meantime
<Chipaca> mbriza: as I say, that error comes from a sanity check, and what it's trying to do is just a 'mount -t squashfs /tmp/<a temp squashfs>'
<Chipaca> mbriza: and that is failing, with the error from mount as reported to you
<Chipaca> oh, oh
<Chipaca> also maybe in selinux systems there's a context= appended?
<Chipaca> mbriza: I don't know selinux enough to know what context that is
<Chipaca> maybe mborzecki knows
<mbriza> it's trying to access a file called 'snap-failure'
<popey> How ironic :)
<mbriza> which is i guess an error reporter?
<Chipaca> that's a thing you don't need to worry about :-)
<Chipaca> it's an auto-reverter for snapd
<Chipaca> for (core, or) systems with reexec
<ogra> is setting permissive mode a runtime thing (not an selinux user here) ... i.e. did you reboot after setting it to make sure the kernel picked it up ?
<mbriza> there are 3 selinux alerts for the time of attempting to install a snap and all 3 point to this so i guess that's not relevant
<mbriza> ogra: permissive mode is a runtime thing, selinux won't block anything in this mode but it will report detected... uhh, breaches? don't know how to call it
<Chipaca> mbriza: at a guess, we're adding a context=<something> to mount, because selinux.ProbedLevel() isn't "unsupported", and that is getting into trouble because of it being permissive
<ogra> ok
<Chipaca> mbriza: but I know nothing about selinux :) so it's a question for mborzecki
<mbriza> Chipaca: i can run in enforcing if that's a problem
<mbriza> still the same error
<Chipaca> mbriza: if you add -o context=<gibberish> to the mount of the .snap, does it still work?
<Chipaca> that was really quick for enabling enforcing + restarting snapd + trying to install something
<mbriza> Chipaca: the daemon is not really running, it's systemd socket-activated
<mbriza> anyway, with gibberish in the mount command i'm getting the same error as above
<mborzecki> mbriza: hm what about selinux?
<pstolowski> ogra: hmm i cannot reproduce the issue you saw. on same host i got "cannot update snap namespace: cannot write to "/etc/systemd/journal-upload.conf" because it would affect the host in "/etc/systemd" when trying your snap with layouts, after installing and then removing the one with system-files interface
<pstolowski> ogra: i'm on 19.10
<mbriza> mborzecki: to be honest i'm not sure what the issue is - there's a lot of repetitive information but the gist is i'm not able to install any snap on fedora 31 because `mount` fails
<mbriza> not even sure if it's related to systemd, it fails regardless of running in permissive/enforcing mode
<pstolowski> ogra: i suspect something got stale on your box but it's unclear how. your state.json looks sane, it doesn't have system-files connection
<mbriza> err i mean selinux
<mborzecki> mbriza: reading backlog, looks like snappy_snap_t isn't defined? that'd be weird it's part of the policy shipped with the pacakge
<pstolowski> ogra: is your first box still in this state (e.g. the snap with layout succesfully installed)?
<mborzecki> mbriza: that's 31 right?
<mbriza> mborzecki: yes
<mborzecki> mbriza: ok, let me check rawhide first
<ogra> pstolowski, i'm on 16.04 here and i think the machine is still in that state ...
<pstolowski> ogra: good. could you get me /var/lib/snapd/apparmor/profiles/snap.logsync-james.upload profile?
<mbriza> mborzecki: just reinstalled the snap packages and rebooted to be extra sure everything is up to date but install is still failing
<mborzecki> mbriza: same thing in dmesg as you posted before?
<mbriza> yes
<ogra> pstolowski, just to prove it still works ... https://paste.ubuntu.com/p/7vtsXM3Kvm/ ...  one sec, getting the file
<ogra> pstolowski, and the apparmor profile ... http://paste.ubuntu.com/p/gz5DfScfQ7/
<pstolowski> ogra: did you use --devmode or try at any point?
<ogra> only in the very first run i think ... then i removed the snap, re-built, re-installed and connected system-files ... then dropped system-files for layout, removed/purged the snap and installed with the layout
<pstolowski> ogra: ok, so the profile has /etc/systemd/journal-upload.conf mrwklix, from the layout; but it doesn't have sytem-files interface anymore in the profile
<mup> PR snapd#7738 closed: overlord/state: panic in MarkEdge() if task is nil <Simple ð> <Created by stolowski> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7738>
<pstolowski> it's weird it didn't complain
<ogra> right ...
<ogra> it complains if i copy the snap to another machine (also 16.04)
<pstolowski> ogra: yep, got it. interesting. ok, i think i need to look at different place in the code now.. thanks
<ogra> should oh also ...
<ogra> ogra@anubis:~/datengrab/logsync:master$ sudo snap remove --purge logsync-james
<ogra> logsync-james removed
<ogra> ogra@anubis:~/datengrab/logsync:master$ cat /etc/systemd/journal-upload.conf
<ogra> [Upload]
<ogra> URL=http://www.example.com:19532
<ogra> -should
<ogra> shouldnt the file be removed whan the snap gets purged ?
<mborzecki> mbriza: installing core snap
<pstolowski> ogra: --purge is only for avoiding automatic snapshots, nothing else
<ogra> well, yeah ... but remove should remove the file, or not ?
<mborzecki> mbriza: and it installed fine, ok, so we need to debug your system
<mborzecki> mbriza: anything useful ausearch -m AVC ?
<ogra> i.e. i dnot think a layouted file should stay behind when removing the snap that used the layout
<ogra> that will result in all kinds of cruft after a while
<ogra> (at least in the case where the layout actually created the file from scratch)
<pstolowski> ogra: yes i think you're right, i'm not sure why layout isn't cleaning after itself
<mborzecki> mbriza: while at it, does seinfo -t |grep snappy_snap_t list anything?
<pstolowski> ogra: something for zyga (maybe there was a reason it's like that)
<mbriza> mborzecki: ausearch doesn't report anything new when running sudo snap install hello-world
<mbriza> mborzecki: snappy_snap_t is not present in the output of seinfo .-t
<mbriza> -t
<pstolowski> ogra: one more question.. on the misbehaving box, is snapd at the current stable version?
<ogra> checking
<pstolowski> ogra: same version of snapd on both boxes?
<mborzecki> mbriza: rpm -q snapd-selinux show anything?
<ogra> ogra@anubis:~/datengrab/logsync:master$ snap version
<ogra> snap    2.42.1
<ogra> snapd   2.42.1
<ogra> series  16
<ogra> ubuntu  16.04
<ogra> kernel  4.4.0-141-generic
<ogra> kernel is a bit behind ... but the rest should be recent
<ogra> the other box uses the hwe kernel but beyond this the same versions
<mbriza> mborzecki: snapd-selinux-2.42.1-1.fc31.noarch
<mbriza> mborzecki: there's this line in the journal though
<mbriza> mborzecki: Nov 18 13:37:27 localhost.localdomain kernel: SELinux:  Context unconfined_u:object_r:snappy_home_t:s0 is not valid (left unmapped).
<mborzecki> mbriza: seinfo -t snappy_home_t ?
<mbriza> mborzecki: Types: 0
<ogra> pstolowski, the main difference is that the system-files interface was never connected on the box that behaves correct
<pstolowski> uhm
<ogra> (well, i also have never used --devmode with this snap on the behaving machine)
<mbriza> mborzecki: https://paste.centos.org/view/e51f0cc4 this is in the journal too
<popey> fwiw, i just installed f31, and updated it to latest, and can install and run snaps fine
<mborzeck1> wow, my really sucks today
<mbriza> mborzeck1: https://paste.centos.org/view/e51f0cc4 this is in the journal too
<mbriza> mborzeck1: also as for the output for seinfo-t snappy_home_t, it was Types: 0
<mborzeck1> mbriza: right, so looks like the policy wasn't loaded for some reason
<mborzeck1> mbriza: ok, can you try dnf history list snapd-selinux and then dnf history info <id> ?
<mbriza> mborzecki: there's this little line in there, yes:
<mbriza> mborzecki:   16 /usr/sbin/semodule:  Failed on /usr/share/selinux/packages/snappy.pp.bz2!
<mbriza> mborzecki: and i get the same error when trying to reinstall the package
<mborzecki> mbriza: yeah, i suppose if you do semodule -l |grep snappy there'll be nothing listed there
<mbriza> mborzecki: semodule -l doesn't even start
<mbriza> libsemanage.semanage_direct_get_module_info: Unable to read flatpak module lang ext file. (No such file or directory).
<mbriza> now this is not related to snappy at all
<mborzecki> mbriza: hm, did you upgrade 30 -> 31?
<mbriza> yeah
<mbriza> dnf reinstall *selinux*
<mborzecki> mbriza: did you do distro-sync afterwards?
<mbriza> mborzecki: i'm distro-syncing all the time
<pstolowski> ogra: ok, i know what's going on and why it didn't work on second box
<mborzecki> mbriza: tried with --allowerasing?
<ogra> \o/
<mborzecki> mbriza: btw. you need to use sudo/su to run semodule
<mbriza> yeah, of course... seems there's something wrong about my selinux policies though
<pstolowski> ogra: it only succeeds with layout-based snap if you already have /etc/systemd/journal-upload.conf in place (leftover from previous snap). trespassing-detection code is then happy. otherwise it complains. i'll pass it to zyga to decide what to do with iy
<pstolowski> *it
<ogra> yay, thanks
<mborzecki> mbriza: can you post the output of sestatus somewhere?
<ogra> so let me remoe that file ... to prove it ;)
<mbriza> mborzecki: https://paste.centos.org/view/2e2c930d
<ogra> ogra@anubis:~/datengrab/logsync:master$ sudo snap install --dangerous logsync-james_0.2_amd64.snap
<ogra> error: cannot perform the following tasks:
<ogra> - Run configure hook of "logsync-james" snap if present (run hook "configure":
<ogra> -----
<ogra> cannot update snap namespace: cannot write to "/etc/systemd/journal-upload.conf" because it would affect the host in "/etc/systemd"
<ogra> snap-update-ns failed with code 1: File exists
<ogra> -----)
<ogra> yay !
<ogra> yup ... touching the file before snap install then makes it work again
<mborzecki> mbriza: doesn't feel like it's related to snapd policy in particular
<mbriza> mborzecki: yeah, definitely somewhere else, thank you for helping me debug this
<mbriza> and to the rest of the channel, too :)
<mborzecki> mbriza: last thing, can you try installing flatpak-selinux, and see if it works?
<mborzecki> mbriza: they also ship the policy in a separate module
<mbriza> mborzecki: i have it but it (and mysql, too) complains
<pstolowski> ogra: good, thanks for confirming
<mbriza> ... even after reinstalling
<zyga> ogra: it is a bug
<zyga> Trespassing should never surface as an error
<mborzecki> mbriza: yeah, i'd try checking in #fedora-devel, and maybe trying .autorelabel too
<zyga> It is a duplicate of another bug on launchpad already
<ogra> zyga, yeah, after two days cuddling with it i guessed that much :)
<zyga> Give us some time, we have a plan that fixes a large class of those issues
<ogra> yeah, no worries, i'm surely not in a hurry ... just ran into it and found it weird
<ogra> pstolowski, one other (unrelated) thing ... should "listen-stream:" still be supported ? i was trying it yesterday and snapcraft complains about things like "listen-stream: 8080" not "being an object"
<ogra> (iirc you initially implemented it)
<Chipaca> ogra: listen-stream: <the path to a socket>
<ogra> Chipaca, uhm, so network sockets got removed ?
<ogra> https://snapcraft.io/docs/snapcraft-yaml-reference thinks <port> is a valid thing
<mbriza> mborzecki: ha, after deleting the lang files in /var/lib/selinux/targeted/active/modules/200 and reinstalling the packages, i'm able to install snaps again
<mbriza> thank you!
<mborzecki> mbriza: does it still work when you reboot?
<mbriza> i just reinstalled everything with 'selinux' in its name and there were no errors so i assume it'll be fine
<mbriza> also my app actually starts on this machine when installed from snap
<pstolowski> ogra: i quickly grepped the code and we have tests for listen-stream: <an integer>; should work. not sure why snapcraft rejects it
<b_b> hi
<mborzecki> mbriza: hah, that's a good sign ;)
<b_b> is there a problem with latest stable base core18 ?
<ogra> pstolowski, hmm, well, then it is most likely a snapcraft bug with the yaml parser ...
<b_b> i'm getting error about this one since yesterday
<b_b> error: unable to contact snap store
<b_b> An error occurred when trying to execute 'sudo -i env SNAPCRAFT_HAS_TTY=True snap install --channel stable core18' with 'multipass': returned exit code 1.
<ogra> $ SNAPCRAFT_BUILD_ENVIRONMENT=host snapcraft
<ogra> Issues while validating snapcraft.yaml: The 'apps/remote/sockets/listen-stream' property does not match the required schema: 19532 is not of type 'object'
<ogra> thats what i guess
<pstolowski> zyga: re trespassing, shouldn't it behave consistently whether /etc/systemd/journal-upload.conf (that with bind via layout: bind-file: $SNAP_DATA/journal-upload.conf) exists or not? at the moment it is happy if it exists and you only get trespassing error if doesn't
<ogra> *s/guess/get/
<b_b> i've tried to clean all mutipass vms, and launched a clean snapcraft, no luck
<ogra> aha ... https://bugs.launchpad.net/snapd/+bug/1612440
<mup> Bug #1612440: Full systemd socket activation support <lxd> <Snapcraft:New> <snapd:Fix Released> <https://launchpad.net/bugs/1612440>
<ogra> looks like the snapd task is fix-released but the snapcaft one is still new
<mborzecki> cachio is off today, isn't he?
<zyga> hey hey
<zyga> pstolowski: it's a bug, it's actually diagnosed already AFAIK
<zyga> pstolowski: yes but $COMPLEXITY
<zyga> pstolowski: it's not what it seems at first
<zyga> ogra: did you report a bug for this?
<zyga> ogra: it would help with tracking
<ogra> zyga, nope, not yet
<zyga> ogra: no rush as I'm a zombie today
<zyga> but please do later on
<ogra> (it isnt only complex to splve, but also complex to explain :P )
<zyga> yeah
<ogra> *solve
<ogra> ok, will do
<zyga> thank you
<zyga> I feel terrible today
<ogra> must be the maple syrup withdrawal :)
<mvo> zyga: yeah, its not a great day
<zyga> mvo: I was sleeping between 8 and 1PM
<mvo> zyga: uh, woah
<mvo> I had a "short" nap in the morning of 2h, but I was already working at 4:30 or so (yay jetlag)
<Chipaca> mborzecki: next week
<b_b> weird, i can't get rid of this mutlipass error
<b_b> sudo -i env SNAPCRAFT_HAS_TTY=True snap install --channel stable core18' with 'multipass': returned exit code 1
<b_b> snap info core18 shows me than the stable channel have a different date than the others
<oSoMoN> ijohnson, it looks like https://github.com/snapcore/snapd/pull/7731 is good to go now (tests passed), can it be merged?
<mup> PR #7731: usersession/userd: add "apt" to the white list of URL schemes handled by xdg-open (LP: #1776873) <Created by oSoMoN> <https://github.com/snapcore/snapd/pull/7731>
<b_b> see u ++
<pstolowski> https://github.com/snapcore/snapd/pull/7727 needs 2nd review
<mup> PR #7727: tests: improve TestDoPrereqRetryWhenBaseInFlight to fix occasional flakiness <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7727>
<mup> PR snapcraft#2804 opened: conda plugin: simplify source url/checksum handling <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2804>
<zyga> gosh, "ethics and code of conduct" is a long one
<mup> PR pc-amd64-gadget#24 closed: gadget.yaml: do not use CamelCase for names <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/24>
<mup> PR snapd#7747 opened: gadget: skip fakeroot if not needed <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7747>
<Chipaca> zyga: looooooong
<Chipaca> zyga: nominally 30-60mins but took me just under 2h
<Chipaca> although it wasn't interruption-free
<zyga> Chipaca: lol, "Resisting taking vacation time â fraud is often discovered while an employee is gone"
<zyga> Chipaca: I wonder when people will start to incorporate remote workers into generic training material
<zyga> I feel like a woman may have felt a few decades ago
<mup> PR snapcraft#2805 opened: plugins: address type errors for mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2805>
<mup> PR snapcraft#2806 opened: cli: address type errors for mypy uprev  <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2806>
<mup> PR snapd#7748 opened: overlord: fix the get command help message <Simple ð> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7748>
<jkridner> ogra: I see you made an mjpg-streamer snap. have you thought about making one that includes the opencv filter features?
<jkridner> hmmm... https://github.com/ogra1/mjpg-streamer/blob/master/snap/snapcraft.yaml#L36 seems to indicate you are pulling the sources with the opencv plugin.
<jkridner> ah, https://github.com/ogra1/mjpg-streamer/blob/master/snap/snapcraft.yaml#L12
<mup> PR snapcraft#2807 opened: meta: address errors from mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2807>
<mup> PR snapcraft#2808 opened: repo: fix fetch_binary()'s return type for deb repo <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2808>
#snappy 2019-11-19
<mborzecki> morning
<mborzeck2> damn isp
<mup> PR snapd#7747 closed: gadget: skip fakeroot if not needed <Simple ð> <Created by cmatsuoka> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7747>
<zyga> hey
<mborzecki> zyga: hey
<zyga> mborzecki: check out "Sourcetrail"
<zyga> it's FOSS just now
<zyga> pretty neat IMO
<mborzecki> zyga: hmmm 'something went wrong'
<zyga> mborzecki: did you finish all of the HR training?
<mborzecki> zyga: yup
<zyga> https://github.com/CoatiSoftware/Sourcetrail
<zyga> did you have any issues?
<mborzecki> zyga: with the hr training?
<zyga> I had to re-do one from scratch because the in progress version was stuck on last page without ability to "sign" the result
<zyga> yes
<zyga> I finished everything but more like at 1-2AM
<mborzecki> zyga: so sourcetrail is like a better gnu global web mode?
<zyga> I have no idea what that is
<zyga> hey mvo
<zyga> how did you sleep?
<mvo> hey zyga ! much better. did stay up longer and had a relatively good sleep
<mvo> zyga: and you?
<mborzecki> mvo: hey
<zyga> mvo: I managed to sleep at 2:30 - 3:00 AM
<zyga> better than yesterday for sure
<zyga> mvo: I shared this with Maciek earlier: https://github.com/CoatiSoftware/Sourcetrail
<zyga> it's neat, I played with it a little
<zyga> their website is slashdotted now
<zyga> but should recover eventually
<mvo> zyga: 2:30am - 3:00 am ? that is still not great :/
<mvo> hey mborzecki
<mvo> zyga: oh, nice
<pstolowski> morning
<mvo> hey pstolowski ! good morning
<zyga> good morning pawel
<mborzecki> pstolowski:  hey
<zyga> mvo: I think I should take a swap day today
<zyga> mvo: yesterday was okay to "burn" the day on HR and some random reviews
<zyga> but today I feel so tired and sleepy, in the morning, that I really think I need to just take it easy and sleep/rest all day
<zyga> and not pretend to work effectively
<mvo> zyga: sure, thats fine
<Mirv> if there's someone who is not really badly sleep deprived and has access to openSUSE Tumbleweed, please update to 20191116 and check if you can reproduce what I have bug #1853110
<mup> Bug #1853110: On up-to-date openSUSE Tumbleweed all snaps show "broken" <snapd:New> <https://launchpad.net/bugs/1853110>
<zyga> j,,
<zyga> hmm
<pstolowski> Mirv: hey! yes i'm actually looking at it right now
<zyga> pstolowski: thank you
<pstolowski> (it's my bug triaging day today)
<Mirv> zyga: you are not counted into that someone according to log above :D take care.
<Mirv> pstolowski: ok, thanks!
<zyga> thank you so much guys
 * zyga returns to cleaning the office 
<Mirv> apparmor was updated but not sure what was changed https://lists.opensuse.org/opensuse-factory/2019-11/msg00264.html - that said, disabling apparmor does not seem to help me
<pstolowski> Mirv: i'm installing tumbleweed atm as i don't have it handy
<zyga> pstolowski: it eats gobs of space
<zyga> pstolowski: using btrfs and snapshots
<zyga> not very vm friendly
<zyga> you may want to disable snapper (snapshot thing)
<Mirv> ..or just select ext4 for everything in advanced setup instead of btrfs
<pstolowski> zyga, Mirv good to know, thanks, yeah, too late to change fs, will look at disabling later
<mvo> a second review for 7745 would be great
<mvo> should be simple and will unblock 7746
<zyga> mvo: let me do it
<Mirv> pstolowski: so for example I've rocketchat-desktop installed, and with sudo mount /var/lib/snapd/snaps/rocketchat-desktop_97.snap /mnt I get: mount: /mnt: mount failed: Operation not permitted.
<Mirv> I wish there was something meaningful in some log, but I can't find any
<zyga> Mirv: look at audit log
<zyga> Mirv: /var/log/audit/audit.log
<Mirv> I tried, but I did not find other than "ype=AVC msg=audit(1574157270.914:590): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap.signal-desktop.signal-desktop" pid=7789 comm="apparmor_parser"" type of messages
<zyga> that's odd
<pstolowski> Mirv, zyga: i cannot reproduce the exact mount issue, but something is definately broken. all snaps get mounted, also after reboots. but i can get a snap to run only after i install it, and until reboot. after reboot i get "cannot change profile for the next exec call: No such file or directory
<pstolowski> snap-update-ns failed with code 1: File exists" for all snaps
<zyga> pstolowski: did you enable snapd.apparmor.service?
<pstolowski> profiles seem to be in place, snaps mounted
<zyga> it's part of the install docs
<pstolowski> ah, i missed that
<zyga> mvo: https://github.com/snapcore/snapd/pull/7745#pullrequestreview-318910411 + 1
<mup> PR #7745: snap-bootstrap: add go-flags cmdline parsing and tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/7745>
<mup> PR snapd#7745 closed: snap-bootstrap: add go-flags cmdline parsing and tests <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7745>
<mvo> zyga: thank you!
<pstolowski> zyga: right that was it
<mvo> also 7712 needs a second review (a bit more work but really important to move forward with uc20)
<pstolowski> Mirv: ok, cannot reproduce on fresh install, wonder what when wrong on your box. do you have everything updated, no held dependencies etc?
<Mirv> I do see "missing file /snap/.../meta/snap.yaml" type of messages but that's obvious since nothing is mounted, it's just annoying that regarding the "Operation not permitted" I'm not finding anything, and sudo systemctl stop apparmor + sudo systemctl stop snapd.apparmor do not help so it does not seem to be apparmor that's denying the permission (also as nothing is in audit.log)
<pstolowski> Mirv: the fact you cannot even mount .snap manually is a key, that's pretty weird
<Mirv> pstolowski: :( everything is updated, nothing seems to be held
<Mirv> pstolowski: yes it is
<Mirv> squashfs is installed, that's one thing that I thought about
<pstolowski> Mirv: that's not even a snapd issue but something more fundamental
<pstolowski> Mirv: is it a standard suse kernel?
<Mirv> pstolowski: standard yes. but I have another TW laptop at 20191112, I'll update that one too and see if it gets broken or not
<pstolowski> Mirv: also, can you try mount -v /var/lib/snapd/snaps/rocketchat-desktop_97.snap /mnt (-v for verbose)
<Mirv> pstolowski: not anymore verbose with that
<Mirv> pstolowski: ah, it's loop devices broken, somehow.. I can't mount an iso either
<Mirv> but yes this is not snapd anymore
<mup> Bug #1853122 opened: Facing requires classic confinement error <Snappy:New> <https://launchpad.net/bugs/1853122>
<zyga> Mirv: losetup -a?
<zyga> maybe you ran out of loopback devices
<Mirv> zyga: empty
<zyga> can you try:
<zyga> Mirv: losetup -f /path/to/a/squashfs/file/
<zyga> (as root)
<zyga> perhaps also with -r for --read-only
<Mirv> hmm, losetup: cannot find an unused loop device
<zyga> so that's the problem
<zyga> can you strace it?
<Mirv> yep, and from there I can see that there's nothing ls /dev/loop*
<zyga> do you have loop-control?
<Mirv> not even that
<zyga> I don't know what makes it
<zyga> on my system that is 10:237
<pstolowski> Mirv: thanks for updating the bug report!
<Mirv> pstolowski: sorry for taking your time :( it very effectively seemed like "snapd broken" for a long time..
<Mirv> so currently I've filed openSUSE bug report, but then again my other laptop did not break. mknod /dev/loop-control c 10 237 helps. I'll follow up on the more relevant channels, maybe of course snapd current report a bit more if loop devices are broken.
<mup> Bug #1853122 changed: Facing requires classic confinement error <snapd:New> <https://launchpad.net/bugs/1853122>
<zyga> pstolowski: consider adding a check that /dev/loop-control exits and has major/mior
<zyga> sanity check, that is
<pstolowski> zyga: exactly
<pstolowski> Mirv: no worries. we do some sanity checks, and i think this problem highlights one other potential problem that we may want to check
<xnox> Chipaca:  mvo: https://raw.githubusercontent.com/snapcore/pc-amd64-gadget/20/grub.cfg-recovery  note improvements 1) variables select the default entry by id 2) all recovery systems are enumerated 3) entries are created per-mode / per-system 4) no idea what duplicate hotkeys will do 5) added menuentry to go back to UEFI setup, as my VM is too quick
<xnox> it's kind of evolution of previous globgging, with type entries.
<xnox> and the cmdline is now correct.
<xnox> i was thinking that load_env --file /systems/$snapd_recovery/grubenv could e.g. declare the modes that are supported, and then generate entries for modes that a given recovery system can do?
<Chipaca> xnox: I too was thinking of an env per system
<mvo> xnox: sounds good! should we handle this stuff via PRs or do you prefer to commit directly to master?
<xnox> it was a rewrite, thus i just pushed it to master
<Chipaca> xnox: i'm not sure the logic for default= is sane there though
<Chipaca> xnox: shouldn't that be set after the loop?
<xnox> Chipaca:  mvo: we were meant to have design for the boot menu right....? because it matters what order things are shown, what the text / hotkeys are, what they do, how they are grouped.
<xnox> Chipaca:  it is set if there is a default provided in the global env (i.e. boot that next); otherwise it is set each time a new better system is found.
<xnox> mvo:  Chipaca: and we need to like search for ubuntu-boot and add entry to chainload "normal mode" grub right?
 * xnox also dislikes run/recover. I would prefer "normal/recover/install" such that hotkeys are unique: n r i
<mvo> xnox: I pushed https://github.com/snapcore/core20/pull/13 with a very first draft of the separation of writable-path from initramfs. its the old code almost untouched. I will look to add tests and then we can start refactoring I think
<mup> PR core20#13: handle-writable-paths: extract the writable-path handling <Created by mvo5> <https://github.com/snapcore/core20/pull/13>
<mvo> xnox: but its what you had in mind, rightÃ
<mvo> ?
<mvo> niemeyer: it would be great if https://github.com/snapcore/core20/ pull requests could be added to mup
 * mvo needs to step out for ~10min
<niemeyer> mvo: Heya
<niemeyer> mvo: Sure, will do
<xnox> mvo:  yes, that is the right approach, and a good starting point. It shouldn't live in /etc though, and can always iterate that once we create it as an entry point.
<pstolowski> Chipaca: hey, why was this assigned to some other team? https://bugs.launchpad.net/snapd/+bug/1851480
<mup> Bug #1851480: Hooks are not included in slot/plug label expressions <snapd:Confirmed for glancr> <https://launchpad.net/bugs/1851480>
<zyga> pstolowski: community
<pstolowski> zyga: someone specific is going to fix it?
<mvo> xnox: yeah, do you prefer /usr/lib/something/handle-writable-path?
<Chipaca> pstolowski: that's dot-tobias
<pstolowski> Chipaca: ah, ok
<xnox> mvo:  /usr/lib/core/handle-writable-paths yeah
<Chipaca> pstolowski: they said on 2019-11-07 they'd get to it "next week", and that they'd report progress
<Chipaca> pstolowski: so maybe it's time to jiggle the plug
<mvo> xnox: cool, will move it over
<zyga> pstolowski: yes, though please reassign if you want to fix it sooner
<mup> PR snapd#7749 opened: tests: restart the snapd service in the snapd-failover test <Created by mvo5> <https://github.com/snapcore/snapd/pull/7749>
<cachio>  mvo hey
<cachio> #7749 is to fix the issue I raised about that test on pi3?
<mup> PR #7749: tests: restart the snapd service in the snapd-failover test <Created by mvo5> <https://github.com/snapcore/snapd/pull/7749>
<mvo> cachio: it *could* be related but it was the outcome of a discussion with mborzecki about the snapd failover robustness and we wanted to make sure our tests are complete (i.e. testing that we didn't just restart into the right snapd but also ensuring that its stable accross the restart)
<mvo> cachio: you need to remind me about this pi3 issue, I don't recall :/
<cachio> mvo, sure
<cachio> I see this error https://paste.ubuntu.com/p/xBhPYrjfVf/
<mup> PR snapd#7750 opened: sanity: check /dev/loop-control device as part of sanity checks <Created by stolowski> <https://github.com/snapcore/snapd/pull/7750>
<cachio> mvo, It happens after we install the broken snapd
<mup> PR snapd#7712 closed: seed: support in Core 20 seeds local unasserted snaps for model snaps <Priority ð> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7712>
<mvo> cachio: thanks, thats interessting. is this happening all the time or just sometimes?
<cachio> mvo, all the time
<mvo> cachio: do you know when this started to happen?
<mvo> cachio: or is it happening since forever?
<mvo> cachio: also I assume this happens on all the Pis, not just pi3, pi2 as well?
<cachio> mvo, checking logs
<mvo> cachio: thank you, no rush, I get lunch now but that is interessting, I wonder if there is a race with that path
<cachio> mvo, 2.42 execution
<cachio> first time I saw that
<cachio> I raised the issue at that moment
<cachio> and then I did a manual execution to get more info
<cachio> last week
<cachio> mvo, I mostly reproduced that on pi3
<cachio> on pi2 not sure
<cachio> just once on pi2, it was during 2.42.1
<cachio> mvo, it is not happening all the time on pi3
<cachio> mvo, this is an execution during last week https://trello-attachments.s3.amazonaws.com/5da8bc830df86851446e9d4e/5dcf78cb5984618fb21cd5d7/1a9b05bfb0491c8faad045fc9f6143d3/snapd_2.42.1%2Bgit1140.g9173632_(5459)_pi3-refresh-18_arm32.log
<cachio> this is all stable + snapd from edge
<cachio> and it works well
<pstolowski> cachio: is this still the case https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1852635 ?
<mup> Bug #1852635: mount-ns test failing with latest bionic updates <snapd (Ubuntu):New> <https://launchpad.net/bugs/1852635>
<cachio> pstolowski, yes
<cachio> pstolowski, this is the last log https://travis-ci.org/snapcore/spread-cron/builds/613333438
<cachio> from yesterday
<pstolowski> cachio: ok, thanks, will investigate
<cachio> pstolowski, thanks
<mvo> cachio: thank you! interessting find, I wonder what is going on there, our code did not change in a while, maybe systemd did change somehow
<mborzecki> pstolowski: https://devfest.withgoogle.com/#devfest-map try poland
<pstolowski> mborzecki: thanks
<mup> PR snapd#7748 closed: overlord: fix the get command help message <Simple ð> <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/7748>
<pstolowski> cachio: fwtw i run spread -debug google:ubuntu-18.04-64:tests/main/mount-ns and it didn't fail
<mborzecki> cachio: pstolowski: do you have the log?
<pstolowski> mborzecki: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1852635
<mup> Bug #1852635: mount-ns test failing with latest bionic updates <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1852635>
<mup> PR snapd#7751 opened: cmd: fix the get command help message <Simple ð> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7751>
<cmatsuoka> mborzecki: did it over in the right message: https://github.com/snapcore/snapd/pull/7751
<mup> PR #7751: cmd: fix the get command help message <Simple ð> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7751>
<cachio> pstolowski, are yo uusing the image test-bionic-1 ?=
<cachio> mborzecki, this is the last error https://travis-ci.org/snapcore/spread-cron/builds/613333438#L1850
<mborzecki> cmatsuoka: thanks, will take a look
<pstolowski> cachio: no, how do you mean?
<cmatsuoka> mborzecki: thanks for noticing that, I grepped for the faulty message and I think I didn't expect more than one instance
<pstolowski> cachio: ah, you mentioned it in the beginning of output in the bug report
<pstolowski> cachio: how do i get it?
<ijohnson> mborzecki: regarding epochs on #7431, I don't think we should do anything for that, AFAICT it should just work with epochs, my gut feeling is that if there is something special that should happen with disabled services and epochs the "transitioning" snap between epochs should take care of that in post-refresh, pre-refresh hooks IMHO
<mup> PR #7431: overlord/snapstate: don't re-enable and start disabled services on refresh, etc <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7431>
<ijohnson> anyways do you think I'm ok to land that PR now since it's green? (CC mvo)
<ijohnson> mvo: also should we get a +1 from jdstrand on #7731 before merging?
<mup> PR #7731: usersession/userd: add "apt" to the white list of URL schemes handled by xdg-open (LP: #1776873) <Created by oSoMoN> <https://github.com/snapcore/snapd/pull/7731>
<mvo> ijohnson: yeah, a review for 7731 from jdstrand would be great, should be fine but best to double check with him
<ijohnson> ack
<mvo> ijohnson: let's merge 7431, it got two +1 and conceptually samuele had looked at it so AFAIK we should not block on him
<cachio> pstolowski, I created it by updating and upgrading bionic and then rebooting it
<ijohnson> \o/ I'm on it
<mvo> ijohnson: great, thanks for this one!
<mup> PR snapd#7431 closed: overlord/snapstate: don't re-enable and start disabled services on refresh, etc <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7431>
 * ijohnson can't wait for pstolowski to rewrite all of that code for preseeding and review it all again
<mup> PR snapcraft#2809 opened: project-loader: address errors from mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2809>
<pstolowski> ijohnson: yay
<ijohnson> pstolowski: I'm not quite done going through my backlog of forum/email/github notifications, did you submit a PR adding 'k' to the serial-port apparmor rules? If not I can do that
<ijohnson> looks like jdstrand gave a +1 to adding 'k' to the rule
<ijohnson> https://forum.snapcraft.io/t/not-able-to-start-configure-custom-built-ubuntu-core/14142/23?u=ijohnson
<pstolowski> ijohnson: he did, but he also said he was going to do it afaiu
<ijohnson> ah I see his other comment now, nvm :)
 * cachio lunch
<mup> PR snapd#7752 opened: tests: enable degraded test on arch linux after latest image updates <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7752>
<mborzecki> ijohnson: yeah, i was wondering about the snap service naming, it's totally up to whoever builds the snap, so you can have a service named A, then the user disables it, the publisher renames A to B, the user proceeds to disable B, then A returns as something completely new and gets disabled because we carry the history of the disabled service names, but it a corner case so meh ;)
<ijohnson> well the question I would have is when you say "A returns as something completely new", how do you qualify something completely new? :-) it has the same name, so the publisher probably intended some kind of connection between the first service and it's reincarnation
<ijohnson> but yes that is a corner case
<mup> PR snapcraft#2810 opened: build-providers: address errors from mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2810>
<ijohnson> Chipaca: I think the snapd REST API wiki docs need an update, see https://forum.snapcraft.io/t/facing-requires-classic-confinement-error/14163
<Chipaca> hmm
 * Chipaca looks
<Chipaca> ijohnson: oh, doc seems to be wrong, not outdated
<ijohnson> wrong == outdated ?
<Chipaca> ijohnson: /v2/snaps never took options
<ijohnson> right got it
<Chipaca> so all those options descriptions should be on /v2/snaps/<snap>
<Chipaca> augh
 * Chipaca takes a break
<ijohnson> degville, when you get a chance can you take a look at making the docs changes for https://bugs.launchpad.net/snapd/+bug/1612440 ?
<mup> Bug #1612440: Full systemd socket activation support <lxd> <Snapcraft:New> <snapd:Fix Released> <https://launchpad.net/bugs/1612440>
<degville> ijohnson: will do, thanks for letting me know.
<ijohnson> thanks!
<jk0ne> Hello!  I am beginning an upgrade of the snapcraft forums.  The forum will be in read-only mode until this is completed.  ETA: less than one hour.
<Chipaca> EOD for me it is
<Chipaca> ð
<jk0ne> forum.snapcraft.io has been upgraded. Maintenance is complete.
<mup> PR snapcraft#2811 opened: extractors: address errors from mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2811>
<degville> thanks jk0ne!
<ogra> hmm
<ogra> jk0ne, not sure if that was your intent ... https://imgur.com/a/es4hRK9
<ogra> (has anyone else lost all CSS from the forum ?)
<ogra> bah ... ok, now it is back but i'm hard logged out ...
<ec0> looks OK here
<ogra> (and cant remember my credentials since the silly forum doesnt use SSO)
<jk0ne> ogra: I think you might have hit it during the actual reload.  Let me know if you are seeing issues still.
<ogra> jk0ne, nope, seems ok now
<jk0ne> glad to hear
<mup> PR snapcraft#2812 opened: store: address errors from mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2812>
<mup> PR snapcraft#2813 opened: pluginhandler: address errors from mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2813>
#snappy 2019-11-20
<mborzecki> morning
<mborzecki> wow, forum got updated?
<mvo> hey mborzecki
<mborzecki> mvo: hey
<mup> PR snapd#7752 closed: tests: enable degraded test on arch linux after latest image updates <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7752>
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/7751 simple one, could land easily
<mup> PR #7751: cmd: fix the get command help message <Simple ð> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7751>
<mvo> mborzecki: sure
<mup> PR snapd#7751 closed: cmd: fix the get command help message <Simple ð> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7751>
<mup> PR snapd#7753 opened: po: sync translations from launchpad <Created by mvo5> <https://github.com/snapcore/snapd/pull/7753>
<mup> PR snapd#7754 opened: release: 2.42.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7754>
<pstolowski> morning
<mborzecki> pstolowski: hey
<pstolowski> o/
<mup> PR snapd#7755 opened: cmd/snap-failure: fallback to snap from core, extend tests <Remodel ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7755>
<mborzecki> mvo: ^^
<mvo> mborzecki: nice
<mvo> can someone please sanity check 7754, should be super simple
<mvo> single review for this is enough
<mup> PR snapd#7713 closed:  seed: Core 20 seeds channel overrides support for grade dangerous <Priority ð> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7713>
<mup> PR snapd#7754 closed: release: 2.42.2 <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7754>
<mborzecki> zyga: when you're around https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1852635 looks to me like the default mount options changed for the virtual filesystems, maybe some systemd updated triggered that?
<mup> Bug #1852635: mount-ns test failing with latest bionic updates <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1852635>
<pstolowski> mborzecki, zyga : i'm on it
<pstolowski> 2 hrs in, almost finished
<pstolowski> a couple of changes affecting it
<pstolowski> zyga: btw, i'd drop the debug section (for fname in ./*.deterministic.txt...) from this test.. it produces walls of text which is not helping. actual diff that failed is most useful to understand what changes
<pstolowski> *changed
<zyga> good morning
<zyga> sorry for starting late, I still cannot sleep at night
<zyga> mborzecki: looking
<zyga> pstolowski: that debug section is useful when there are larger changes and the diff is not something you want to work with
<zyga> pstolowski: perhaps put it behind an environment variable test?
<pstolowski> zyga: good idea
<zyga> pstolowski: I released 2.42.1 to tw yesterday, did you update to it?
<pstolowski> zyga: yes, i'm on it
<pstolowski> why?
<zyga> good, just wanted to know if you see anything wrong
<zyga> it worked ok for me
<Chipaca> zyga: silly question, where can i see the apparmor profile that is actually loaded? e.g. the profile in /var says 'include abstractions/foo', where can i see the pre-processed(?) one?
<zyga> Chipaca: those are in /etc/apparmor.d
<Chipaca> zyga: I know, which /etc tho
<Chipaca> zyga: :)
<Chipaca> i have four of 'em
<Chipaca> outer /etc, core /etc (twice), and core18 /etc
<Chipaca> and they're different in important ways :)
<zyga> Chipaca: in the one seen when you log in
<zyga> Chipaca: if you are talking about core that's the /etc from the boot base snap
<zyga> Chipaca: on classic that's the classic /etc
<zyga> Chipaca: sorry, I didn't understand your question initially
<zyga> mvo: do you sleep normally now?
<Chipaca> so, say,  a core18 snap will use abstractions/python from the host?
<zyga> yes
<zyga> Chipaca: that's correct
<Chipaca> that's bad and wrong
<zyga> Chipaca: as in, that's what happens, your understanding is correct
<zyga> indeed, it can cause syntax from apparmor 3 to interfere, for example
<Chipaca> or, we need to retro-tweak it :)
<zyga> Chipaca: what are you seeing?
<Chipaca> it means a core18-based python snap on 1604 might not work
<Chipaca> zyga: i'm not, but somebody else is seeing an issue
<Chipaca> where it doesn't load a .so
<Chipaca> https://forum.snapcraft.io/t/ubuntu-16-04-host-denies-core18-snap-python-3-6-library-import/14247
<Chipaca> now, i'm on 1604 and i can load that .so without issue, but my system might be "special"
<Chipaca> so i dunno
<cachio> mvo, hey
<cachio> mvo, sru almost ready but 1 test failing on bionic
<cachio> https://paste.ubuntu.com/p/dKrJRZb7Jb/
<zyga> Chipaca: one more reason why sharing /etc was a mistake
<zyga> and we need to work towards undoing that
<cachio> mvo, the test is snap-seccomp-syscalls
<cachio> mvo, I remmeber we fixed it weeks ago but not sure if it is something we need to address
<mvo> cachio: yeah, this is fixed in 2.42.2 I think its fine to ignore this failure
<cachio> mvo, perfect
<mvo> cachio: 2.42.2 will not need a sru I think, the re-exec is fine, this is only important for lxd-support
<mup> PR snapd#7749 closed: tests: restart the snapd service in the snapd-failover test <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7749>
<cachio> mvo, ok
<cachio> makes sense
<mup> PR snapd#7756 opened: tests: update mount-ns test for bionic image changes <Created by stolowski> <https://github.com/snapcore/snapd/pull/7756>
<pstolowski> cachio, zyga ^
<zyga> ack
<cachio> pstolowski, nice, I'll take a look
<zyga> pstolowski: what is the test-bionic image? is that the image we are going to upgrade to?
<mborzecki> pstolowski: do we know which packages are responsible for those changes?
<zyga> reading the diff I would love for the .expected.txt files to use delta encoding, so all numbers would be like +1 instead of 12 (even after renumbering)
<zyga> it would remove most of the diff
<zyga> pstolowski: I agree with mborzecki that we should know what's the origin of the change
<zyga> but other than that +1
<pstolowski> zyga. mborzecki i don't know what package is the origin of them
<pstolowski> zyga: the image name will probably change, i will update once cachio has it
<zyga> cachio: is there a manifest of changes to the bionic image?
<cachio> zyga, I attached that to the bug
<cachio> let me see
<zyga> thanks, let me find it
<jdstrand_> Chipaca: hey, fyi, apparmor_parser -p /path/to/profile will show the profile with all the includes in it
<zyga> 237-3ubuntu10.31 -> 237-3ubuntu10.29 ?
<zyga> cachio: can you attach an unified diff before/after
<zyga> it looks like the diff is after -> before now
<cachio> zyga, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1852635/+attachment/5305454/+files/bionic-diff.txt
<mup> Bug #1852635: mount-ns test failing with latest bionic updates <snapd (Ubuntu):Confirmed for stolowski> <https://launchpad.net/bugs/1852635>
<mborzecki> does https://packages.ubuntu.com/ 500 for you too?
<cachio> zyga, sure, on sec
<zyga> thanks
<zyga> mborzecki: no
<cachio> zyga, https://launchpadlibrarian.net/452319755/bionic-diff2.txt
<zyga> unified :)
<zyga> but ok
<zyga> unified diffs are easier to read
<cachio> zyga, ahh, ok ,one sec
<cachio> zyga, https://launchpadlibrarian.net/452319957/bionic-diff-unified.txt
<zyga> pstolowski: ^ given this can you check if the systemd changelog explains what we are seeing please?
<zyga> pstolowski: in addition, can you please add a "Fixes: <URL>" line to the commit message,
<zyga> it helps with tracking things
<pstolowski> zyga: sure
<zyga> reviewed now
<Chipaca> jdstrand: dunno if you saw that forum topic, do we need to tweak /etc/apparmor.d/abstractions/python so people can use core18-based python snaps?
<Chipaca> jdstrand: using the python from the base i mean
<pedronis> mvo: I left some initial comments and a question in 7746
<jdstrand> Chipaca: I haven't yet, but hope to start my misc policy updates today and can add that to the list of investigations
<Chipaca> jdstrand: k
<jdstrand> Chipaca: thanks!
<pstolowski> zyga: systemd changes looks completely innocent and unrelated, must be something else
<pstolowski> i looked at debian changelog and patches listed there
<zyga> pstolowski: would you mind looking at what the cause may be for some more time? I would like to at least know that it's not a mistake that the changes exist
<pstolowski> yeah i will
<zyga> pstolowski: perhaps ask foundations for ideas
<zyga> pstolowski: xnox may know something about this
<xnox> can i please have context summary? also possibly you want rbalint
<pstolowski> xnox: sure. we have a pedantic test that checks mount tables and namespaces. it picked changes after latest bionic upgrade, and we'd like to understand if the changes are legit
<pstolowski> xnox: https://github.com/snapcore/snapd/pull/7756 - see PR description for summary of the changes
<mup> PR #7756: tests: update mount-ns test for bionic image changes <Created by stolowski> <https://github.com/snapcore/snapd/pull/7756>
<xnox> it looks harmless, yet it odd
<xnox> it looks harmless, yet it is odd
<xnox> there might be CPC image changes too (as in the base image itself, rather than an sru of something)
<pstolowski> aha
<pstolowski> cachio: do you know what versions of images we should be comparing?
<zyga> brb
<Eighth_Doctor> degville: hey, your CentOS 8 instructions for installing EPEL are can be simplified to just `dnf install epel-release`
<Eighth_Doctor> for this page, I mean: https://snapcraft.io/docs/installing-snap-on-centos
<Eighth_Doctor> `epel-release` is in the default repos for CentOS 8
<degville> Eighth_Doctor: ah, thank you! I'll update them!
<cachio> pstolowski, those images are using the same base image
<pstolowski> uhm
<cachio> fir older one was created by updating and upgrading one month ago
<cachio> the newer it was created following the same procedure 1 week ago
<mborzecki> cachio: pstolowski: zyga: nothing obvious in https://changelogs.ubuntu.com/changelogs/pool/main/s/systemd/systemd_237-3ubuntu10.31/changelog
<pstolowski> xnox: we also have the list of packages that got updated - https://launchpadlibrarian.net/452319957/bionic-diff-unified.txt - anything worth checking?
<pstolowski> mborzecki: yes, i checked that too, plus patches in the source package
<pstolowski> mborzecki: as long as changelos is thruthful about what patches were applied, they look innocent
<zyga> if it is the cloud images
<zyga> could it be something that is not a package that is changed there
<pstolowski> cachio says the base image is the same. that means changes can only come from updated packages afaiu?
<zyga> that's weird
<zyga> I don't mean to block you, perhaps ask mvo for advice
<pstolowski> let's check on standup. if anything, it's blocking bionic update for our tests
<mvo> zyga: what is this about?
<zyga> mvo: standup
<zyga> let's chat there?
<mvo> zyga: 1min, need to prepare a cup of tea
<mborzecki> zyga: ijohnson: irc or meet?
<zyga> ijohnson: so I have an idea where we could optimize away snap-update-ns for _some_ snaps
<zyga> let's do it here
<zyga> my network is busy today
<ijohnson> sure works for me
<zyga> part of the work will involve snap-update-ns working on slightly different basis
<zyga> and if we can statically detect from snapd that the fstab profile to apply doesn't need sophistication (more on what that means in a moment)
<zyga> we could implement that in snap-confine like before
<zyga> sophistication is specifically needing to create mimics
<zyga> without mimics input profile is the output profile
<zyga> and we can just execute mounts in order and be done with it
<zyga> we could detect if mimics are needed with a simulation approach, that plans what it would take to apply a mount profile we generate for a snap
<zyga> right now we don't know until runtime
<zyga> last week I was experimenting a little, extending the Assumptions struct with knowledge about the base snap
<zyga> so that we could simulate application and know if mimic is needed or not
<zyga> it's a bit hand wave-y at the moment *but* we could optimize away snap-update-ns in many cases, I believe
<ijohnson> related question: when we preserve a mount ns, does that persist across boots, or is it just valid for the current boot? I think it's not persistent since it's in /run, correct?
<zyga> ijohnson: no, it's just a memory construct
<ijohnson> right
<zyga> it's only in kernel memory
<zyga> ijohnson: even outside of /run
<ijohnson> oh right cause it's just a fd got it
<zyga> it's a nsfs filesystem object we are saving
<ijohnson> do we create mimics for content interfaces as well as layouts? I think yes?
<zyga> ijohnson: yes
<zyga> ijohnson: there's no difference between them
<ijohnson> hmm I guess I'm not quite following which information we're missing when snap-confine runs that currently we have to wait until runtime for
<zyga> ijohnson: let's have a call :")
<zyga> it could be faster than me typing
<ijohnson> haha ok
<ijohnson> mborzecki did you want to join as well?
<zyga> https://meet.google.com/nbn-avuw-zwh?authuser=1
 * zyga breaks for lunch
 * cachio lunch
<ogra> ijohnson, FYI ... https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/mangling.py#L28
<ijohnson> ... of course
<ogra> not sure that is still used though ... but it used to re-write all python shebangs in all python scripts during snap build
<ogra> (that is why i suggested the change in the forum)
<ijohnson> well I suggest snapcraft not do that in the name of performance, but perhaps there's a good reason why snapcraft used to do that
<ogra> yes, because you cant be sure core/core18 has the same interpreter as the snap
<ogra> (someone might pull python 3.9 from a PPA r whatnot)
<ogra> but yeah, the performance impact is quite significant ... i noticed that with my little robot arm when i tried to snap some movement scripts (shell wrappers that then call a python script ... the moves got seriously slower)
<ogra> less than half the speed in the end ...
<ijohnson> ogra: but even if you pull python 3.9 from a PPA into your snap, you would know that you want your python script to use python 3.9, so you would set that up?
<ijohnson> i.e. $SNAP/usr/bin/python3.9 or some such
<ogra> sure, if i only have one .py script and have full control over the upstream source ...
<ijohnson> do any of your python scripts need to load C libraries?
<ogra> if you pull in multiple scripts from external parts/sources it gets more tricky
<ijohnson> err just dynamic libraries in general ?
<ogra> it might make sense to keep this shebang rewrite but make it configurable ...
<ijohnson> sure I could see making it configurable
<ogra> so you can actually give the target shebang in a snapcraft.yaml option
<ogra> and let it default to /usr/bin/env ...
<ogra> but thats for the snapcraft team
<ijohnson> why is the forum so slow now, I know it was updated but it feels like it takes much longer to load just small pages
<ogra> i use an electron app for the frum ... and noticed wiping all the app cache gets it back to being normally responsive
<ogra> perhaps try wiping the cache for snapcraft.io in your browser ?
<ijohnson> hmm good idea
<mborzecki> ijohnson: missed that, went for lunch
<ijohnson> mborzecki: np main conclusion was that I was going to do some profiling of snap-update-ns and zyga had some ideas on how to make it quicker
<zyga> indeed
<zyga> mborzecki: you didn't miss anything new
<zyga> mborzecki: we can have another chat about the details that relate to robustness later next week
<mborzecki> ijohnson: cool, there's a bunch of operations triggered by the themes, wonder if skipping themes snap would show a significant change
<ijohnson> yeah there is a lot from the themes snap, so that's an interesting thing to try as well
<ijohnson> though with themes that's only gonna get worse as we get greedy plugs :-(
<mborzecki> ijohnson: discarding the mount ns and disconnecting the contnt interface should be enough
<ijohnson> well it's a bit more tricky since the theme interface auto-connects and I'm testing first launch, so there's a bit of caching that the desktop-launch helper does as well that's a bit tedious to cleanup
<ijohnson> but just removing the plug from snap.yaml is probably sufficient
<mborzecki> ijohnson: rm -rf ~/snap/gnome-calculator make it pretty much like the first run
 * pstolowski lunch
<zyga> mborzecki: for the purpose of helpers, yes
<ijohnson> yes but I still think it's a more accurate representation to remove the whole snap and try
<zyga> ijohnson: you can rm snap user data and discard
<zyga> ijohnson: it's really a good performance reset method, especially if you drop disk caches
<zyga> ijohnson: otherwise installation may mask some of that
<ijohnson> yes I know about all of this, my scripts will delete all of $SNAP_USER_DATA, remove the snap, discard the ns, drop all caches then reinstall and measure performance
<ijohnson> I just think it's easier to just remove the snap to measure performance data
<zyga> ijohnson: that's okay but keep the fact that installation absorbs some of first run cost
<zyga> ijohnson: so you may masking part of the measurement
<ijohnson> that's my whole point
<zyga> ijohnson: yes but it's not representative
<zyga> ijohnson: it depends of what the snap is looking
<ijohnson> it is representative of a user who runs the software
<zyga> er
<zyga> doing
<zyga> ijohnson: not quite, it's only representative of that snap alone
<zyga> ijohnson: e.g. presence of install or configure hook will skew results
<ijohnson> this is why I am doing these tests across multiple different kinds of snaps
<zyga> ijohnson: this is why I emphasize it matters what happens during installation
<zyga> ijohnson: to get realistic results neuter install and configure hooks (remove them entirely)
<ijohnson> yes I understand all of what you're saying and it's all being taken into account, I am taking these things into account
<zyga> great
<zyga> ijohnson: looking forward to what you find, let's talk about it tomorrow
<mborzecki> zyga: ijohnson: looking at both snaps, connecting gnome-platform shouldn't generate many 'actions' in snap-update-ns, so it's just themes really
<zyga> mborzecki: one thing worth of note
<mborzecki> and wonder if that's a dynamic cost incurred by actual layout ops, or a static cost due to just forking & running snap-update-ns
<zyga> mborzecki: is the mimic cost
<zyga> mborzecki: I think it's both
<zyga> mborzecki: static cost is fixed and should be good to compare huge layout/content vs empty one that is there so that we fork anyway
<mup> PR snapd#7757 opened: devicestate: rename ensureSeedYaml -> ensureSeeded <Created by mvo5> <https://github.com/snapcore/snapd/pull/7757>
<zyga> mborzecki: dynamic cost largely depends on where we mount stuff, as mimic cost varies hugely
<mborzecki> yeah, we might need to rebind lots of stuff if it hits at the wrong place :/
<zyga> yes
<ijohnson> zyga, mborzecki: just with the measurements I already have, if I run `sudo snap run --shell gnome-calculator -c "echo"` (note the sudo so we are just setting up the per-snap ns and not the per-user ns), then when I run `snap run gnome-calculator`, the time for the first launch of snap-update-ns is 406ms vs 9ms so I really don't think that just forking/execing a go binary is adding that much
<zyga> ijohnson: hmm?
<zyga> ijohnson: I could be misunderstanding things
<zyga> but the first invocation, as root, cached everything
<zyga> ijohnson: and the second one reused that
<ijohnson> well the second one had to still do the per-user ns
<ijohnson> it still ran snap-update-ns
<zyga> ijohnson: yes but it's running a binary that was just invoked
<zyga> ijohnson: not saying it's wrong
<zyga> ijohnson: it would be good to get the SNAP_CONFINE_DEBUG=yes timings
<ijohnson> I drop all caches between these two runs
<ijohnson> yes will provide that later, still catching up on some things this morning
<zyga> ijohnson: that will show us how long it takes to mount everything
<zyga> ok
<mborzecki> btw. thinking we could strace it ;) just the mounts
<mup> PR snapd#7758 opened: devicestate: add reading of modeenv to uc20 firstboot code <Created by mvo5> <https://github.com/snapcore/snapd/pull/7758>
<mborzecki> ijohnson: zyga: totally unscientific: https://paste.ubuntu.com/p/txq2Z3Zj59/
<zyga> that's realistic, cost of crafting a large mimic
<mborzecki> zyga: ijohnson: https://paste.ubuntu.com/p/STzxjc9htm/ wait4 is really high, is that the deskotp helpers?
<zyga> dunno
<zyga> could that be snap-confine waiting for snap-update-ns?
<zyga> or desktop helpers and their shelly nature
<mborzecki> zyga: ijohnson: /snap/gnome-calculator/544/snap/command-chain/desktop-launch is at the top when running with --trace-exec, so meh
<zyga> so that's that
<zyga> not doing a gazillion mounts would be a good optimization
<ijohnson> Unclear, the go runtime does do lots of wait4 for it's threads and such
<zyga> kernel work upstream to get apparmor and overlayfs to talk to each other would remove the need for virtually all of those
<ijohnson> But also the shell desktop helpers are really slow too
 * ijohnson has no unread emails, will commence investigations after some toast 
 * ogra sets up his spam filter to re-direct some of the mails to ijohnson so he doesnt run out of mails to read
<mup> PR snapd#7758 closed: devicestate: add reading of modeenv to uc20 firstboot code <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7758>
<mup> PR snapd#7759 opened: devicestate: add reading of modeenv to uc20 firstboot code  <Created by mvo5> <https://github.com/snapcore/snapd/pull/7759>
<mup> PR snapcraft#2814 opened: Remove gsettings from comment in kde extension <Created by hellsworth> <https://github.com/snapcore/snapcraft/pull/2814>
<mup> PR snapd#7760 opened: snap-bootstrap: write /run/mnt/ubuntu-data/var/lib/snapd/modeenv <Created by mvo5> <https://github.com/snapcore/snapd/pull/7760>
<jdstrand> zyga: well, 'yes' but we also need the gagillion mounts cause overlayfs in the form needed to play well with LSMs is not in supported kernel versions either
<jdstrand> (assuming it and apparmor did play well together, which they eventually will)
<zyga> jdstrand: totally, just as an optimization
<zyga> (eventually)
<jdstrand> it will be nice to have that, yes
<mup> PR snapd#7761 opened: devicestate: make /var/lib/snapd/seed available in install mode <Created by mvo5> <https://github.com/snapcore/snapd/pull/7761>
<mvo> xnox: I would love to talk about pr #7744 tomorrow, essentially just double checking if the approach works for you etc. maybe we can chat tomorrow morning about this?
<mup> PR #7744: snap-bootstrap: set expected filesystem labels <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7744>
<xnox> ok
<zyga> I'll grab some drinks and be back soon
<pstolowski> mvo, zyga: i asked cachio to run updated bionic against old 4.15 kernel, and the mount-ns test passed. so it means it's 5.0 kernel indeed
<pstolowski> xnox: ^ also fyi
<mvo> pstolowski: thank you!
<pstolowski> mvo: credit goes to Sergio!
<pstolowski> mvo: and thanks for hinting at the kernel!
<zyga> pstolowski|afk: thank you
<cmatsuoka> mvo: what would be a good place to add a kernel cmdline parser? osutil maybe?
<zyga> cmatsuoka: osutil is becoming dense, perhaps a sub-package? though I believe pedronis has an opinion on that too
<mvo> cmatsuoka: I think we may not need one actually - please check https://github.com/snapcore/snapd/pull/7760
<mup> PR #7760: snap-bootstrap: write /run/mnt/ubuntu-data/var/lib/snapd/modeenv <Created by mvo5> <https://github.com/snapcore/snapd/pull/7760>
<mvo> cmatsuoka: this will add the "mode=install" to /var/lib/snapd/modenv
<mvo> cmatsuoka: AIUI you use the cmdline to get the snapd_recovery_mode?
<mvo> cmatsuoka: or for something else? if for snapd_recovery_mode modeenv is probably the easiest way
<cmatsuoka> mvo: yes, it was for snapd_recovery_mode
<cmatsuoka> mvo: I'll check #7760
<mup> PR #7760: snap-bootstrap: write /run/mnt/ubuntu-data/var/lib/snapd/modeenv <Created by mvo5> <https://github.com/snapcore/snapd/pull/7760>
<mvo> cmatsuoka: https://github.com/snapcore/snapd/pull/7759 is probably slightly simpler
<mvo> cmatsuoka: it contains just the reading part
<mup> PR #7759: devicestate: add reading of modeenv to uc20 firstboot code  <Created by mvo5> <https://github.com/snapcore/snapd/pull/7759>
<mvo> cmatsuoka: not yet pedronis approved so be warned :)
<mvo> cmatsuoka: I added a question in the https://docs.google.com/document/d/1UZm-Eis2p9owBpskuwxPjMqKYHq9zm2hUGP_VD0w9Rw/edit#
<mvo> cmatsuoka: hopefully this does not block you?
<cmatsuoka> mvo: don't worry, it doesn't
<mvo> excellent
<cmatsuoka> mvo: is there a more direct way to get a gadget MountDir() than getting the snap name and then getting the info from snapstate.CurrentInfo()?
<mvo> cmatsuoka: I think that's the quickest way currently
<cmatsuoka> mvo: ok, thanks
 * cmatsuoka still a bit confused with the data structures
<zyga> I've implemented the new systemd thing and it seems to be okay
<zyga> I'll try to propose it tomorrow, there are a few details I want to get nicer before I open it so nothing tonight
<zyga> I'll call it a day
<zyga> see you all tomorrow
<ijohnson> have a good evening zyga!
<mup> PR snapd#7702 closed: tests: adding fedora 31 <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7702>
<mup> PR snapcraft#2815 opened: minor developer env/doc updates <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2815>
<ijohnson> hey kenvandine, are you a good person to ask about gnome snaps such as gnome-calculator?
<kenvandine> ijohnson: yes
<kenvandine> however i'm not really here today :)
<kenvandine> i'm off and about to run out to pick up kids
<ijohnson> ah ok, is there someone who is really here who might know more?
<kenvandine> hellsworth maybe
<kenvandine> or marcustomlinson in #ubuntu-desktop
<kenvandine> ijohnson: or i can help tomorrow
<ijohnson> ack I'll see if anybody in ubuntu-desktop can help, otherwise I'll catch you tomorrow
<ijohnson> thanks!
<marcustomlinson> I'm barely here
<marcustomlinson> :P
<kenvandine> marcustomlinson: oh... tab complete didn't find you :)
<kenvandine> thanks
 * kenvandine runs out
<ijohnson> haha, well I'll just throw out my question in ubuntu-desktop anyways
<hellsworth> ijohnson: what's your question
<hellsworth> i can try to help
<hellsworth> either here or in ubuntu-desktop
<hellsworth> actually, ubuntu-desktop is prob best
<kyrofa> zyga, I know you're probably out but maybe I can catch you in the morning: do you have any clues about this? https://bugs.launchpad.net/snapd/+bug/1847673
<mup> Bug #1847673: Nextcloud snap auto-updated a few days ago. Since then, I've had 100% CPU use by snapfuse. <snapd:Invalid> <https://launchpad.net/bugs/1847673>
<kyrofa> I'm getting more reports of it for Nextcloud, and I'm the one who told them to file against snapd. snapfuse is just uncompressing the snap, right? Why should it be eating so much CPU? Is there something the snap could be doing to cause it?
<mup> PR snapd#7762 opened: Core 20 install mode handling <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7762>
#snappy 2019-11-21
<mborzecki> morning
<pstolowski> mornings
<mborzecki> pstolowski: hey
<pstolowski> pedronis: hey, i just noticed you created a 20.4 card for snapctl but there is already one in Doing, and more detailed
<pedronis> pstolowski: ?
<pedronis> pstolowski: I just moved the theme card
<pedronis> which doesn't go into doing
<pstolowski> pedronis: ah, sorry, got confused
<mborzecki> pedronis: morning
<pedronis> mvo: hi, what's the status of https://trello.com/c/AGmzhqA7/288-make-netplan-apply-work ? only one item is unchecked
<mvo> pedronis: looking
<mvo> pedronis: I think this is done now, let me double check
<mvo> pedronis: I double check and move to done if all good?
<pedronis> sounds good
<mup> PR snapd#7757 closed: devicestate: rename ensureSeedYaml -> ensureSeeded <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7757>
<mborzecki> btw. standup is at 4pm today?
<mvo> mborzecki: on my calendar it's at the regular time
<mborzecki> hm maybe evolution is just confused, it's showing 4pm
<mborzecki> oh and gnome-calendar is showing 3pm
<mvo> xnox: please holler when you are around, would love to move forward with the snap-bootstrap intramfs-mounts and wanted to double check if you are happy with the PR 7746
<mup> PR #7746: snap-bootstrap: implement "snap-bootstrap initramfs-mounts" <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7746>
<xnox> mvo:  sure. and the matching core20 build i guess.
<xnox> mvo:  do you want to chat in a hangout, or simply for me to review the snap-bootstrap tool?
<xnox> imho i'm not sure how to "include" it into the initrd right now =)
<mvo> xnox: either way is fine, HO, irc or just looking at it. HO might be easiest, give me 2min (we may want to pull in pedronis  is he wants to join)
<xnox> let's hangout
<mup> PR snapd#7763 opened: [RFC] boot,bootloader: make MakeBootable() uc20 aware <Created by mvo5> <https://github.com/snapcore/snapd/pull/7763>
<xnox> your git repo has too many branches!
<mvo> xnox: yes :(
<mvo> xnox: but all my stuff is proposed for merging so shouldn't be super terrible
<pedronis> mvo: something is strange about needing a recovery grub
<pedronis> they are both grub
<Chipaca> super interesting use case: https://forum.snapcraft.io/t/offline-update-of-multiple-snaps/14258
<mvo> pedronis: yes, I can try to simply make it a config option
<mvo> pedronis: happy to explore this
<pedronis> also we have options that we pass to Find now, that might help as well
<mvo> pedronis: I will explore using the same a bit and push that as well
<pedronis> mvo: as I suspected adding snapd type in asserts is not enough, there are bugs, trying to write tests in seed/ and fix them
<pstolowski> mvo: can you take a look at https://github.com/snapcore/snapd/pull/7727 when you have a moment?
<mup> PR #7727: tests: improve TestDoPrereqRetryWhenBaseInFlight to fix occasional flakiness <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7727>
<zyga> good morning :/
<zyga> 5AM managed to sleep
<zyga> 11AM wake-up
<zyga> mvo: do you remember when the improved snapfuse binary was shipped?
<zyga> hey mborzecki
<mborzecki> zyga: hey
<mup> PR snapd#7764 opened: many: test various kinds of overriding for the snapd snap in Core 20 <Created by pedronis> <https://github.com/snapcore/snapd/pull/7764>
<pedronis> mvo: ^
<mup> Bug #1560942 changed: Support swap <snapd:Invalid> <Snappy:Fix Released> <ubuntu-core-config (Ubuntu):Fix Released> <https://launchpad.net/bugs/1560942>
<Chipaca> sil2100: hiya. Are you the person to ask about details of the rpi gadget?
<sdhd-sascha> sil2100: what is it about?
<Chipaca> sdhd-sascha: ?
<sdhd-sascha> chipaca: sorry, i want you to ask about what question it is?
<Chipaca> sdhd-sascha: about the pi3-gadget, https://github.com/snapcore/pi3-gadget
<Chipaca> sdhd-sascha: why?
<Chipaca> because I _think_ #1500164 is fix-released, but I'm not the expert
<mup> Bug #1500164: console= cmdline options on the RPi2 should be moved from uboot.env to cmdline.txt <Snappy:In Progress> <https://launchpad.net/bugs/1500164>
<ogra> Chipaca, it is
<Chipaca> ogra: you said you thought so, but that we should check with foundations :)
<Chipaca> ogra: so here i am trying to do that
<ogra> well, i cheked the code but yeah, a re-assurance from foundations would be bad ... though you can always re-open the bug anyway :P
<ogra> *woudlnt
<ogra> bah
 * ogra subscribes to a typing course 
<Chipaca> ogra: in my experience subtle bugs like this very rarely get re-opened
<Chipaca> we're lucky they get filed in the first place :D
<ogra> i'm pretty sure it is fix-released (90%+)
<Chipaca> ogra: OTOH the reporter of this bug in particular is a crotchety ol' guy that'll open it again without a doubt
<ogra> haha
<Chipaca> and, that's all the triage i'll be doing today, methinks
<Chipaca> now to attempt a run
 * Chipaca goes
<zyga> mvo: do you have a moment
<zyga> mvo: can we chat about the thing from yesterday
<mvo> pstolowski: hey, sure thing!
<zyga> mvo: we've discussed the technical side with maciek just now and wanted to give you some options
<zyga> mvo: we're in https://meet.google.com/nst-hqvw-bhb?authuser=1
<mvo> zyga: uh, nasty jetlag this time :(
<mup> Bug #1500164 changed: console= cmdline options on the RPi2 should be moved from uboot.env to cmdline.txt <Snappy:Fix Released> <https://launchpad.net/bugs/1500164>
<zyga> mvo: tell me about it ;D
<mvo> zyga: the improved snapdfuse is in 2.41+ but I think you need to install the deb to get the benefits. I *might* be wrong though
<mvo> zyga: improved deb is in -proposed
<cmatsuoka> mvo: thanks for the review. I'm addressing the issues and will push again soon
<mvo> cmatsuoka: \o/
<zyga> tests running
<mup> PR snapd#7765 opened: boot,bootloader: make MakeBootable() uc20 aware <Created by mvo5> <https://github.com/snapcore/snapd/pull/7765>
<mup> PR snapd#7763 closed: [RFC] boot,bootloader: make MakeBootable() uc20 aware <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7763>
<ogra> mvo, what happened to http proxy settings in core18 ? (/etc/environment is not writable anymore ?!?)
<ogra> ogra@pi4:~$ snap set system proxy.http="http://my.proxy.com:8080"
<ogra> ogra@pi4:~$ grep my.proxy /etc/environment
<ogra> ogra@pi4:~$ sudo touch /etc/environment
<ogra> touch: cannot touch '/etc/environment': Read-only file system
<ogra> ogra@pi4:~$
<ogra> or zyga ^^^
<zyga> ogra: I'm sorry, I'm not very reactive today
<ogra> well, you cant set a http/https proxy in core18 at all it seems ... dont we have tests for that ? or did the implementation change
<ogra> looking at https://github.com/snapcore/snapd/blob/master/overlord/configstate/configcore/proxy.go it still writes /etc/environment ... but i dont get any error when running snap set
<ogra> ogra@pi4:~$ snap change 1384
<ogra> Status  Spawn               Ready               Summary
<ogra> Done    today at 13:43 UTC  today at 13:43 UTC  Run configure hook of "core" snap
<ogra> not really telling me about the fact that it didnt set the proxy
<zyga> I don't know
<ogra> nothing in the journal either
<ogra> ogra@pi4:~$ sudo journalctl|grep proxy
<ogra> ogra@pi4:~$
<zyga> sorry
<ogra> well, thats pretty gross we have a few customers relying on that working as documented
<zyga> is /etc/environment a squash
<zyga> sorry, I'm not feeling very well
<ogra> it wasnt in core16 it seems to be in core18
<zyga> then it's a bug
<ogra> yes
<zyga> needs to be addressed, regression tests etc
<ogra> just wondering how that can happen
<zyga> perhaps existing test can be reused if there is onew
<zyga> we don't run many tests on core18
<mvo> ogra: let me have a look (but we have a meeting in 3min so I maybe a bit slow)
<ogra> k
<mvo> zyga: I beg to differ, we run almost all tests on core18
<ogra> zyga, just leave it to michael :)
<zyga> mvo: if that's the case I'm sorry, I wasn't aware of that
<zyga> mvo: what I meant is that may of our tests don't use base: core18
<zyga> though for this problem it should not matter
<mvo> zyga: aha, I see
<mvo> zyga: yeah, that's true. but I think ogra issues is on a core18 based core system, yes?
<ogra> mvo, i think so ... i'll ask the customer that complained, they only provided snap list which indeed shows core and core18 installed
<mvo> ogra: I found the relevant test, running this now on core18
<ogra> but i think they run on core18 (it also works fine on core16, i just checked)
<ogra> seems the internal snapd setting of the proxy to contact the store is fine ... but not the global change to /etc/environment
<ogra> (simply because it got dropped from writable-paths i guess)
<ogra> ogra@stream:~$ snap set system proxy.http="http://my.proxy:8080"
<ogra> ogra@stream:~$ sudo grep proxy /etc/environment
<ogra> http_proxy=http://my.proxy:8080
<ogra> core16 works fine
<mvo> ogra: yeah, it's anyoing, we have a spread test that tests the internal setting on core18 but I think not the other one
<ogra> mvo, well, if the config hook would at least spill an error it would have been easier to catch :)
<ogra> but even that goes quietly through
<mup> PR snapd#7756 closed: tests: update mount-ns test for bionic image changes <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/7756>
<mvo> ogra: yeah, no discussion that this is bad(tm)
<ogra> (unless i'm seriously missing something and we dont set systemwide proxy settings in /etc/environment anymore)
<mvo> ogra: running tests now (and in a meeting) - I extended the proxy test and then I should be able to say more
<Chipaca> meet kicked me out and refuses to connect, now
<roadmr> it does that a lot :/
 * Chipaca curses the google goblins
<pedronis> Chipaca: oopsy, we wanted to stay a bit and sort out confusion with mvo, anyway we can chat on Monday
<ijohnson> Chipaca: to answer your question from the HO chat, no I have not tested any of this on spinning disk systems
<Chipaca> pedronis: i can't access any bit of google right now
<ijohnson> Chipaca: do you think I should?
<Chipaca> ijohnson: I think it's a lot more painful there, and might be painful in different ways
<pedronis> Chipaca: oops, that seems bad/strange
<Chipaca> ijohnson: is that something that's easy for you to do?
<Chipaca> pedronis: now it's back, fwiw
<ijohnson> Chipaca: ok I can try to, I have empty spinning disks I could use but I don't have an OS installed on them, so I would have to install a system there
<Chipaca> ijohnson: I've got 19.10 on a spinning-disk laptop, if that's any use
<Chipaca> pedronis: https://forum.snapcraft.io/t/offline-update-of-multiple-snaps/14258 is the topic i mentioned in the standup
<ijohnson> hmm, not sure if 19.10 vs 19.04 is important, I'm still on disco and when I first started all of this mvo, pedronis and I decided I shouldn't upgrade to 19.10 to run more tests because it could be radically different for graphics and things
<Chipaca> ijohnson: 1904, or 1804?
<ijohnson> Chipaca: don't worry about it, I can handle it, you should prepare for your conference :-) (and have fun too)
<ijohnson> 1904
<Chipaca> ijohnson: you typoed "panic"
<ijohnson> :-)
 * zyga breaks for coffee
<zyga> brb
<Chipaca> ijohnson: thanks!
<Chipaca> anyway, i'm off
<Chipaca> ttfn!
<mvo> ogra: https://github.com/snapcore/core18/pull/143
<mup> PR core18#143: static: add /etc/environment to writable-paths <Created by mvo5> <https://github.com/snapcore/core18/pull/143>
<mup> PR core18#143 opened: static: add /etc/environment to writable-paths <Created by mvo5> <https://github.com/snapcore/core18/pull/143>
<mvo> ogra: also test missing on our side, working on this too
<mborzecki> hmm snapd calling systemctl stop snapd.failure.service when snapd.failure.service actually stated snapd in recovery mode :/
 * ogra hugs mvo
<mvo> ogra: was working on this and then another fire came - but I certainly will come back to it. also a silly bug in our code that did not report this as an error as it should have :(
<mvo> ogra: with the fix the configure hook fails and says "/etc/environment: read-only fs"
<mvo> ogra: but yeah, there should be a PR (or two) for this by my eod
<ogra> mvo, thanks a lot !
<ogra> ijohnson, was it you who complained about slow forum ? i see it now too ... i have seen more of the spiner than of the content today
<ogra> *spinner
<ijohnson> ogra: yes and others were discussing the issue in our standup today too
<ijohnson> seems a global problem
<zyga> Dinner
<ogra> yeah
<ogra> i have some feeling it is related to the avatars ... i often see the page but the avatars only load a lot later ... same goes for quotes, that often shows "Loading ..." (i actually didnt know it could do that !!)
<mvo> ogra: 7766 and 7767 address your issue, thanks for reporting
<mup> PR snapd#7767 opened: tests: run snap-set-core-config on all core devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/7767>
 * cachio lunch
 * ogra hugs mvo  once more
<zyga> mvo: hey
<zyga> remember your recent PRs?
<zyga> error: cannot perform the following tasks:
<zyga> - Run configure hook of "core" snap (run hook "configure": open /etc/environment: read-only file system)
<zyga> mvo: this requires the new core18 release, right?
<zyga> sil2100: https://github.com/snapcore/core18/pull/143 an you please do a 2nd review?
<mup> PR core18#143: static: add /etc/environment to writable-paths <Created by mvo5> <https://github.com/snapcore/core18/pull/143>
<sil2100> zyga: o/
<zyga> hey
<zyga> good evening
<zyga> sorry to poke you so late
<zyga> not urgent but would help to unblock this for tomorrow
<zyga> thanks a lot :)
<zyga> enjoy your evening
<mup> PR core18#143 closed: static: add /etc/environment to writable-paths <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/143>
<zyga> sil2100: I cannot find the build recipe for core18, can you please trigger a build?
<sil2100> zyga: sure o/ Will need to sync the mirror first
<sil2100> I mean
<sil2100> The builds auto-trigger on new code
<zyga> sure, anything it takes to release new core18 to edge
<sil2100> (and other stuff)
<mvo> zyga: yes, that requires the latest core18
<mvo> zyga: I thought I did mention it in the PR but maybe I forgot
<mup> PR snapcraft#2816 opened: assorted: address errors from mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2816>
<zyga> mvo: it's all right :)
<zyga> mvo: I made solution B work, I think, it's not terrible actually
<zyga> mvo: I'll grab a coffee (heh) and sit tight
<zyga> mvo: I'll prepare a few PRs for tomorrow for maciek
<zyga> brb
<zyga> mvo: lol
<zyga> mvo: check out this snippet
<zyga> (backstory: iOS 13 was more buggy than older releases)
<zyga> Software chief Craig Federighi and lieutenants including Stacey Lysik announced the changes at a recent internal "kickoff" meeting with the company's software developers. The new approach calls for Apple's development teams to ensure that test versions, known as "daily builds," of future software updates disable unfinished or buggy features by default. Testers will then have the option to selectively enable those features,
<zyga> via a new internal process and settings menu dubbed Flags, allowing them to isolate the impact of each individual addition on the system. When the company's iOS 13 was released alongside the iPhone 11 in September, iPhone owners and app developers were confronted with a litany of software glitches.
<zyga> feature flags FTW :)
<mvo> zyga: thanks! let's see if we can get something into beta tomorrow
<mvo> zyga: haha, yes
 * ogra is impressed by kyrofa's accent free russian !
<kyrofa> ogra, right?!
<kyrofa> You don't KNOW my skills
<ogra> :D
<kyrofa> I miss you buddy. You gonna be in Frankfurt I hope?
<ogra> yeah, i actually will !!!!
<kyrofa> Awesome
<ogra> looking forward to it
<zyga> meh, there are still 11 unit tests to adjust
<zyga> and god knows how many comments
<zyga> but it passes all regression tests
<zyga> that's good
<mup> PR snapd#7766 closed: configcore: fix missing error propagation <Created by mvo5> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7766>
 * cachio afk
<mup> PR snapd#7768 opened: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768>
<jdstrand> ondra: fyi, ^
<setuid> Does anyone know the snap analogue to something like 'virsh -c qemu:///system version --daemon'? Basically to query the libs and versions used inside snap core overlay itself?
<ogra> you mean the libs in the core snap ? just take a look in /snap/core/current (or respectively in the core18 dir for snaps using a core18 base)
 * zyga does midnight supper
#snappy 2019-11-22
<mborzecki> morning
<mup> PR snapd#7755 closed: cmd/snap-failure: fallback to snapd from core, extend tests <Remodel ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7755>
<mup> PR snapd#7769 opened: cmd/snap-failure: passthrough snapd logs, add informational logging <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7769>
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> pstolowski: pekkari: can you take a look at https://github.com/snapcore/snapd/pull/7769 ? super simple
<mborzecki> pedronis: ^^
<mup> PR #7769: cmd/snap-failure: passthrough snapd logs, add informational logging <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7769>
<pedronis> a 2nd review of #7764 would be great, it's largely new tests
<mup> PR #7764: many: test various kinds of overriding for the snapd snap in Core 20 <Created by pedronis> <https://github.com/snapcore/snapd/pull/7764>
<mborzecki> pedronis: sure, will do
<zyga> hello
<zyga> mborzecki: I have something that I wanted to show you
<mborzecki> zyga: meet?
<zyga> sure, hold on a moment
<pedronis> mborzecki: I have a question for you in 7762
<zyga> mborzecki: https://github.com/zyga/snapd/commits/wip/dont-reuse-mounts and https://github.com/zyga/snapd/commits/fix/lp-1852361 are the branches of interest
<mborzecki> pedronis: we have some code that looks up devices based on structure definition, but it might not be exported atm, need to double check
<pedronis> mborzecki: ok, thx
<zyga> mborzecki: can you join the standup meet please
<zyga> https://www.irccloud.com/pastebin/Bc19KaR2/
<zyga> mborzecki: google:ubuntu-18.04-64:tests/regression/lp-1852361
<mup> PR snapd#7770 opened: testutil, many: make MockCommand() create prefix of absolute paths <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7770>
<joc> i have a amd64 device running a UC18 image on which i'm trying to install the docker snap, however if fails with:
<joc> error: cannot perform the following tasks:
<joc> - Mount snap "docker" (423) (snap "docker" assumes unsupported features: snapd2.40 (try to refresh the core snap))
<ogra> did you try to refresh the core snap yet ?
<joc> according to snap list these are installed:
<joc> core           16-2.42.1     8039  stable    canonicalâ  core
<joc> core18         20191030      1265  stable    canonicalâ  base
<ogra> and what does "snap version" output (all lines please) ?
<joc> hmm
<joc> $ snap version
<joc> snap    2.36.3
<joc> snapd   2.36.3
<joc> series  16
<joc> kernel  4.15.0-70-generic
<ogra> hmm, very interesting
<mup> PR snapd#7771 opened: o/hookstate/ctlcmd: snapctl is-connected command <Created by stolowski> <https://github.com/snapcore/snapd/pull/7771>
<ogra> if you are on core18 snapd comes from the snapd snap ... try refreshing that
<ogra> (though it should totally auto-refresh... not sure how it can be so behind while the core snaps seem to be nicely up to date)
<zyga> mborzecki: I pushed the comment changes again
<zyga> mborzecki: to both branches
<mborzecki> zyga: ok
<zyga> mborzecki: I tg'd mvo to know about the situation
<zyga> mborzecki: the most important comment is https://github.com/snapcore/snapd/compare/master...zyga:wip/dont-reuse-mounts?expand=1#diff-6cdce42a784f927f710f0f5241a8c68dR418
<zyga> mborzecki: I also adjusted https://github.com/snapcore/snapd/compare/master...zyga:wip/dont-reuse-mounts?expand=1#diff-6cdce42a784f927f710f0f5241a8c68dR493 as mentioned during the call
<zyga> I'm wrapping up for today
<zyga> good luck guys!
<mborzecki> zyga: cool, thanks
<mborzecki> running spread with both regression tests
<joc> snapd did indeed update, thanks for that hint - now indeed i wonder how it managed to be behind given a `sudo snap refresh` was run before
<zyga> ondra: ^^^
<zyga> ondra: this is the stuff that fixes things blocking you
<zyga> ondra: if you take the diff from https://github.com/snapcore/snapd/compare/master...zyga:fix/lp-1852361?expand=1
<zyga> ondra: and build snapd with it
<zyga> ondra: and confirm it works on your devices
<zyga> ondra: that would be a useful data point
<zyga> ondra: we need to discuss and properly package that for release (package as in do more code changes where this can safely land behind a feature flag)
<zyga> ondra: but the essence is the same
<mup> PR snapd#7772 opened: wrappers: write and undo snapd services on core <Remodel ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7772>
<ondra> zyga on it :)
 * pstolowski lunch
<mup> PR snapd#7773 opened: cmd/snap-update-ns: fix overlapping, nested writable mimic handling <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7773>
<mborzecki> zyga: pedronis: ^^ opened the branch, added some description to explain the problem, both spread tests are passing, i've looked the mount ns after the tests and things seemed fine
<mup> PR snapcraft#2817 opened: snapcraft/plugins: Add gomod plugin <Created by mhilton> <https://github.com/snapcore/snapcraft/pull/2817>
<mup> PR snapd#7769 closed: cmd/snap-failure: passthrough snapd logs, add informational logging <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7769>
<mborzecki> pedronis: do you want to have a quick chat about 7769?
<pedronis> mborzecki: you mean 7773 ?
<mborzecki> pedronis: right, 7773
<pedronis> mborzecki: let's have a chat
<pedronis> mborzecki: I'm in the standup
<ackk> hi, with snappy-debug I see the following message from the sna maas snap: https://paste.ubuntu.com/p/X7pKKCqRCc/ is there a way to tell what's that mknod about?
<mup> PR snapcraft#2814 closed: Remove gsettings from comment in kde extension <Created by hellsworth> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2814>
<mup> PR snapcraft#2802 closed: uprev devel python package requirements <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2802>
<mup> PR snapcraft#2804 closed: conda plugin: simplify source url/checksum handling <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2804>
<mup> PR snapcraft#2808 closed: repo: fix fetch_binary()'s return type for deb repo <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2808>
<mborzecki> ondra: did you manage to run zyga's branch?
<ondra> mborzecki yep, just did it
<ondra> mborzecki still failing
<mborzecki> ondra: duh, logs? :)
<mborzecki> ondra: are you sure you're using the right snapd?
<ondra> mborzecki https://pastebin.canonical.com/p/TBgSJ8QPcN/
<ondra> mborzecki this is build I'm using https://code.launchpad.net/~ondrak/+snap/snapd-fix-lp-1852361
<mborzecki> ondra: ha, that's a new thing then, before it failed with EBUSY when trying to roll back some mount changes
<mborzecki> zyga: ^^
<ondra> mborzecki yep, error is different
<ondra> mborzecki and i can confirm snap    2.42.2+git1279.g9c608d9
<ondra> mborzecki which is commit from that branch I used for build
<mup> PR snapcraft#2806 closed: cli: address type errors for mypy uprev  <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2806>
<ondra> mborzecki happy to test more fixes :)
<mborzecki> ondra: can you set SNAPD_DEBUG in snapd, restart snapd and try to install the snap again?
<ondra> mborzecki you mean refresh?
<mborzecki> ondra: yes
<mborzecki> ondra: you can drop an ovverride in /etc/systemd/system/snap.service.d/local.conf with [Service]\nEnvironment=SNAPD_DEBUG=1\n
<ondra> mborzecki it's fine I updated snapd.service file
<ondra> mborzecki https://pastebin.canonical.com/p/YKKKKjV32G/
<mup> PR snapd#7764 closed: many: test various kinds of overriding for the snapd snap in Core 20 <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7764>
<mup> PR snapcraft#2807 closed: meta: address errors from mypy uprev <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2807>
<mborzecki> ondra: interesting, is this the same device that failed the refresh before? was it restarted since then?
<ondra> mborzecki yeah same devce
<ondra> device
<ondra> mborzecki before test I first tested with stable snapd to make sure it's still broken
<ondra> mborzecki BTW when I manually stop services I was able to refresh ( without need to reboot)
<mborzecki> ondra: ok, can you try this, stop whatever service is there, /usr/lib/snapd/snap-discard-ns <snap-name>; start the service, refresh the snap
<mborzecki> ondra: services from that snap ofc
<ondra> mborzecki I cannot restart services they are failing with "cannot update snap namespace: permission denied"
<mborzecki> ondra: you should be able to stop them
<mborzecki> ondra: as in snap stop <snap> or via systemctl
<ondra> mborzecki I stopped them and discarded ns
<ondra> but I cannot restart them anymore
<ondra> mborzecki and I know refresh worked before when services are stopped
<ondra> so running refresh with stopped services will not not help much
<mborzecki> ondra: i suspected that the previous version of snap-update-ns left the mount ns in some half assed state, so the new one would fail but differently
<mborzecki> ondra: can you add SNAPD_DEBUG=1 to the service environment in the unit file? (or via an override)
 * cachio lunch
<mup> PR snapd#7774 opened: seed: proper support for optional snaps for Core 20 models <Created by pedronis> <https://github.com/snapcore/snapd/pull/7774>
 * zyga acks the results from ondra, asked follow up questions in private and resumes off-work activity 
<mup> PR snapcraft#2818 opened: project: pivot `info` from ProjectInfo to Snap <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2818>
<ackk> hi, does anyone know if it's possible to run sshd in a confined snap?
<ackk> I get this error when trying to ssh in: "fatal: permanently_set_uid: was able to restore old [e]gid [preauth]"
<ogra> ackk, during build ?
<ackk> ogra, no, when I try to ssh
<ogra> ah, sorry ... i'm blinf
<ogra> *blind
<ackk> ogra, I have ssh running (with some LD_PRELOAD) but I can't log in
<ogra> i think your prob isnt ssh but login/pam
<ogra> when trying to spawn a terminal for you
<ogra> have you tried something like "ssh <host> uptime" (that doesnt spawn a shell but directly execs the command)
<ogra> theoretically all you shoudl need for snapping ssh is network and network-bind plugs ... but there is more to a full login than just ssh ...
<cjwatson> Not sure you can coherently say that the problem is login/pam when the error message above comes from sshd
<cjwatson> Probably need to LD_PRELOAD somewhat harder to do a better job of mimicking the uid swap (i.e. it needs to be impossible to swap back)
<mup> PR snapd#7775 opened: seed: support extra snaps on top of Core 20 dangerous models <Created by pedronis> <https://github.com/snapcore/snapd/pull/7775>
<mup> PR snapcraft#2805 closed: plugins: address type errors for mypy uprev <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2805>
<mup> PR snapcraft#2811 closed: extractors: address errors from mypy uprev <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2811>
<mup> PR snapcraft#2812 closed: store: address errors from mypy uprev <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2812>
<diddledan> cjwatson: LD_PRELOAD hard. no harder!
 * cachio afk
<ackk> ogra, yeah I tried a non-interactive command, same error
<ackk> cjwatson, ah, I see
<ackk> cjwatson, although, why does it try to change uid if I try to login as root?
<mup> PR snapd#7776 opened: interfaces: add login-session-observe for who, {fail,last}log and loginctl <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7776>
<mup> PR snapcraft#2819 opened: isort: automatic formatting/sorting of imports <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2819>
 * ijohnson unbroke all his snaps (including irccloud) yay
<mup> PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <Merged by vorlonofportland> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mup> PR snapcraft#2813 closed: pluginhandler: address errors from mypy uprev <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2813>
<mup> PR snapd#7777 opened: snap-confine: suppress noisy classic snap file_inherit denials <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7777>
<mup> PR snapcraft#2810 closed: build-providers: address errors from mypy uprev <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2810>
<mup> PR snapd#7778 opened: seccomp: also allow 'chown snap_daemon:root' <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7778>
<jdstrand> ogra: hey, I have a note to add this: /sys/firmware/devicetree/base/system/linux,revision and /sys/firmware/devicetree/base/soc/ranges read access to hardware-observe (needs investigating; these are binary)
<jdstrand> ogra: but reads on /sys/firmware/** is already allowed via hardware-observe back in 78505e088b79e5ee68e01f23ba5d954dac97c520 (2016). do you recall what this is about?
<mup> PR snapd#7779 opened: interfaces: misc updates for u2f-devices, browser-support, hardware-observe, et al <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7779>
<mup> PR snapcraft#2816 closed: assorted: address errors from mypy uprev <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2816>
<mup> PR snapcraft#2809 closed: project-loader: address errors from mypy uprev <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2809>
<mup> PR snapcraft#2820 opened: uprev mypy to 0.740! (and address remaining errors) <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2820>
<ogra> jdstrand, various adafruit libs that are shipped with HW sensors try to access it for whatever reason
#snappy 2019-11-23
<mup> PR snapcraft#2820 closed: uprev mypy to 0.740! (and address remaining errors) <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2820>
<mup> Bug #1853670 opened: snap always shows license as 'unset' after install <Snappy:New> <https://launchpad.net/bugs/1853670>
<cjwatson> ackk: sshd runs a non-root process to do its pre-authentication network communication, so that any preauth bugs are limited in scope rather than being an instant root compromise
<cjwatson> (non-root and also sandboxed with seccomp)
<ogra> jdstrand, seems one of the calls comes from https://github.com/adafruit/Adafruit_Python_DHT/blob/master/source/Raspberry_Pi_2/pi_2_mmio.c
<sdhd-sascha> Is there a way to apply patches inside of snapcraft.yaml build process ? e.g. if dlopen path is hardcoded
<sdhd-sascha> or, only with override-build ?
<sdhd-sascha> or override-pull...
<mup> PR snapd#7780 opened: tests: cleanup most test snaps icons, they were anyway in the wrong place <Created by pedronis> <https://github.com/snapcore/snapd/pull/7780>
<mup> PR snapd#7781 opened: seed: fix confusing pre snapd dates in tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/7781>
<jdstrand> ogra: ack, so is the ask about not having it in hardware-observe?
<ogra> jdstrand, no, it seems HW observe doesnt allow this particular path
 * jdstrand looks at the path again
<ogra> https://paste.ubuntu.com/p/Z7PDBTCjkb/ was with connected hardware-observe
<ogra> probably dues to being binary ? does that get handled differently in some way ?
<ogra> *due
<jdstrand> it does not
<ogra> weird
<jdstrand> ogra: I just checked on a rp2 that has both of those binary paths and hardware-observe worked fine
<jdstrand> ogra: perhaps the interface wasn't connected? at this point, I need more info
<ogra> hmm, i'll dig a bit more what happened there ... the snap has multiple daemons, it might be that the particular one using the sensor didnt have hardware-observe in plugs
<ogra> (would be really helpful if snap connections could show the consumers of a plug
<ogra> )
<jdstrand> ah, maybe that is it
<zyga> hey
<zyga> jdstrand, ogra: working on Saturday?
<ogra> naaah ... nevar !
<ogra> :)
 * zyga is upgrading his printer
<zyga> messy business, especially the hot-end
<ogra> (fixing my kodi setup (some new tv stations etc)
<ogra> my printer recently ate a belt ... will need also a day of attention ... next month though
<ogra> (the disadvantage of a delta printer)
#snappy 2019-11-24
<sdhd-sascha> ogra: hope it was not too late yesterday.
<sdhd-sascha> ogra: did you use iptv with kode ?
<sdhd-sascha> kodi
