#snappy 2015-08-10
<linuxuz3r> hey i just wanna say im a noob at programming arm oses
<linuxuz3r> how is snappy on pi 2 with gnome or xfce
<linuxuz3r> is it fast?
<fgimenez> good morning
<dholbach> good morning
<JamesTait> Good morning all; happy Monday, and happy Lion Day! ð
<ogra_> whee ! my RPi2 image made it on heise.de
<mterry> :)
<elopio> good morning.
<kyrofa> ogra_, I started playing with that image on Friday afternoon
<ogra_> cool
<ogra_> any issues yet ?
<kyrofa> ogra_, I extracted the overlay.tgz to get the devicetree for i2c, but in your email you mentioned it would require modifications to config.txt. I glanced there and it looked like i2c was enabled. I wasn't sure what other modifications I needed to make?
<ogra_> kyrofa, no, i2c is already enabled you dont need to do anynnthing for it
<ogra_> the overlays are for additional HW like "hats"
<kyrofa> ogra_, like the PiGlow?
<ogra_> to just use the i2c bug you can use it unmodified
<ogra_> elopio, had the piglow working with that image, yes
<ogra_> and afaik without any extra modification (except for having to build the piglow-tools for it)
<kyrofa> ogra_, perfect, thank you!
<kyrofa> elopio, ^^ did you build a snap with python-smbus contained within it, etc.?
<elopio> kyrofa: I compiled https://github.com/schoentoon/piglow
<elopio> I'm about to get my binary in a demo snap. Still figuring out some details here...
<kyrofa> elopio, ah, I hadn't seen that one! Thank you :
<kyrofa> :)
 * ogra_ wishes he had an orangebox ... then i would have made i2c work from the start 
<elopio> ogra_: http://shop.pimoroni.com/products/piglow expense it :)
<kyrofa> ogra_, if anyone needs one it's you, haha
<ogra_> kyrofa, tell that to niemeyer :P
<ogra_> (afaik ricardo asked for one for me and was denied)
<kyrofa> ogra_, huh, well that sucks
<longsleep> ogra_: heise.de missed to post a link to the download ..
<ogra_> true
<ogra_> but i guess people that want it will find their way around
<longsleep> yeah - i hope this gives some more coverage of snappy in Germany.
<svij> there's a talk about snappy at FrOSCon next week
 * ogra_ sighs ... so much mail spam when publlishing an app in the store
<longsleep> reminding me / still nobody passed my new OEM snap version :(
<ogra_> beuno, cant we cut that down a bit ? 4 mails for one upload feels really to much
<ogra_> longsleep, but sergio said he would ... he probably didnt get to it yet
<longsleep> ogra_: right - though its almost 2 weeks now - should this take so long?
<ogra_> well, it needs manual review by a reviewer
<longsleep> yes - well at least i can chat with you guys here :)
<longsleep> And the store seems to have gotten an update which fixed one of the problems i did see
<ogra_> yeah, the UI changed
<ogra_> longsleep, oh, note that there is a sprint this week, many of us wont be available as we usually are ... that might delay it
<longsleep> yay it just got reviewed!!!
<ogra_> yep, we just have our team meeting ;)
<longsleep> great thanks!
 * ogra_ could use the pointy stick ;)
<sergiusens> good morning
<longsleep> ogra_: yeah now one can at least grab the oem snap from the store when creating an image. Now is there new about getting the rest from the store as well?
<longsleep> sergiusens: Thanks for reviewing the ODROID-C1 snap !
<ogra_> longsleep, once we have the gadget snaps that will work, yes
<ogra_> oem is going away, it will become kernel and gadget
<longsleep> ogra_: and the gadget snap is also the one which could have dependencies right?
<ogra_> yeah
<longsleep> ok great - please let me know when something is available :)
<sergiusens> longsleep: some people are getting together this week to discuss exactly how to roll that out
<longsleep> sergiusens: cool then i will pay attention to IRC
<ogra_> longsleep, well, they get together in person ... usually IRC attandence is very low if that happens :)
<longsleep> ah
<longsleep> ogra_: do you have the rpi2 oem snap in the store as well?
<ogra_> nope, i wanted to get it proper first and i want lool to remove his
 * ogra_ also doesnt have a branch set up for it yet 
<longsleep> ah - well at least i can say that "--oem odroidc.longsleep" works just fine with ubuntu-device-flash which is essentially all i wanted to test
<ogra_> yeah
<ogra_> i dont find it that urgent as long as you still need the separate device part
<longsleep> right
#snappy 2015-08-11
<dholbach> good morning
<fgimenez> good morning dholbach and all
<dholbach> hey fgimenez
<JamesTait> Good morning all; happy Ingersoll Day! ð
<dholbach> ogra_, somebody in our shared office ordered a spreedbox :)
<ogra_> dholbach, wheee !
<ogra_> still ~2000â¬ missing ...
<elopio> fgimenez: https://github.com/elgris/check/commit/45ed7de654751f962e5c6d493a18933dcea604ec
<elopio> making an outputWriter interface seems like a good upstream step
<fgimenez> elopio, yep very good approach, in that case we would need to control the gocheck output, no skips on reboot
<ogra_> sergiusens, lol, i just noticed your trello comment ... do you think it makes sense to still split the card even when everything is implemented (uboot that is) ?
<sergiusens> ogra_: oh, well not everything is ticked
<ogra_> documentation mainly
<sergiusens> ogra_: if everything is ticked, just migrate it (tick it as well)
<sergiusens> ogra_: as a general practice, it's good to not keep the unknowns and knowns together, that's all ;-)
<ogra_> i commented
<john-mcaleely> ogra_, where do i look for details of how bluetooth might work on snappy systems today?
<john-mcaleely> I assume its not 'in the box'
<john-mcaleely> so I'm wondering if there are devices/projects which have chosen to add it yet?
<ogra_> heh, in someones dream compartment in his head i guess :)
<ogra_> we will need a BT framework that doesnt exist yet
<john-mcaleely> right
<john-mcaleely> so, in a one-snap-to-include-everything model, there's still work, right?
<ogra_> not sure how much lool has planned the architectural bits for this yet
<john-mcaleely> because apparmor confinement, etc
<john-mcaleely> mm
<ogra_> it wont be a one-snap-include-everything i suspect
<ogra_> it will be a one-snap-depend-on-bt-framework rather
<john-mcaleely> and inside that framework, there's still work?
<ogra_> so we first need that framework ...
<john-mcaleely> to accomodate snappy's confinement, ect
<john-mcaleely> ?
<ogra_> and that framweork would have a "snappy config" ability to adjust itzs settings and add HW access etc ... i imagine
<john-mcaleely> mmm
<ogra_> but thats just from my own "dream compartment" :)
<john-mcaleely> its a good start. thank you
<john-mcaleely> ogra_, is wifi different or the same?
<john-mcaleely> (I only have a beaglebone black here, so I don't see this for real)
<john-mcaleely> I'm guessing there would need to be config utilities 'added' to the core image
<john-mcaleely> ?
<ogra_> wifi is slightly different, we shhip all bits needed to set uip wifi in the core
<ogra_> but we dont have a configuration story for that yet ... and i'm not sure if it will be a framework itself or just a snappy config option to ubuntu-core
<john-mcaleely> ok, so there's some software there, but actually baking it in to work in a particular way is missing?
<ogra_> there is SW and there are modules ... but no config at all currently, you have to set it up manually
<john-mcaleely> that's clear
<john-mcaleely> cool
<john-mcaleely> similar, but different :-)
<ogra_> yeah :)
<ogra_> i doubt we'll pull the whole BT stack into the rootfs ... thats the main difference
<ogra_> so the Bt SW needs to come from a framework
<ogra_> perhaps wifi will do that too later
<john-mcaleely> yeah, there seem to be several viable BT stacks
<john-mcaleely> sadly
<ogra_> right
<ogra_> wifi is more clear ... wpa-supplicant and iw tools and you are done
<ogra_> which is why we simply included them for now
<john-mcaleely> simpler software tech. just does IP, I guess
<ogra_> yep
<ogra_> no special daemons, no daemons depending on these daemons etc
<john-mcaleely> right. ui requirements
<john-mcaleely> for 'pairing'
<john-mcaleely> or whatever
<ogra_> well, even commandline pairing requires special tools
<john-mcaleely> why am I not surprised?
<ogra_> for the IoT side we'll need a programmatic way to do it without UI ... or perhaps web UI
<john-mcaleely> indeed. or just use different radios
<ogra_> sadly the framework story is still very blurry ... there is a sprint this week in lex. ... i hope they do more than snapcraft there and we actually get some more fleshed out framework stories
<john-mcaleely> sure
<seshu> Hello there.  My current application/service that runs on Ubuntu has no gui, its written to be a daemon. The main libraries I use for my application/service uses json and mosquitto libraries.
<seshu> I'm trying to see if I can rebundle my application/service into snapp app.
<seshu> so can a snappy app be a daemon?
<beuno> seshu, yes, it can run as a service
<seshu> thanx beuno.
<beuno> seshu, see: https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/
<beuno> how to start it, etc
<seshu> Would I have to bundle the libraries along with the app?
<beuno> seshu, yes
<beuno> snaps are self-contained
<seshu> so looks like, if my application/service needs to incorporate functionality similar to webDM (such as triggering install,remove of other apps or trigger the upgrade of ubuntu core from remote), it should have to be a framework. Am I  correct?
<beuno> seshu, correct
<beuno> seshu, keep in mind, a framework like that would generally not be accepted into the snappy store
<beuno> given it would require to be unconfined
<beuno> so it depends on what your goal is for this snap
<beuno> if its for a fixed function device that doesn't need access to the general store
<beuno> or you're just trying to get a sense of how things work
<seshu> at the moment, I'm trying to understand how things work and how I may have to modify my application to be able to run on snappy.
<seshu> later, the idea is to see how I could use snappy for an IoT solution.
#snappy 2015-08-12
<dholbach> good morning
<fgimenez> good morning
<Mikaela> "However, you can still switch channels at a later point using command line tools." from https://developer.ubuntu.com/en/snappy/guides/channels/ - how does that happen and shouldn't that page tell it?
<ogra_> Mikaela, i'm not sure that is still true ... usually the channel is defined in /etc/system-image/client.ini (or some such, writing from the top of my head)
<Mikaela> having it only choosable during installation or image creation sounds a little difficult to me
<ogra_> it will definitely become easier to switch once we moved away from system-image ...
<Mikaela> I see
<ogra_> ubuntu-core will just become a normal snap package
<ogra_> currently we use a mix of the phone technology and snaps ... once we fully moved to snaps a switch is easier ...
<ogra_> on the phone you would run: system-image-cli --switch=your/target/channel ... i'm not sure this works on snappy
<ogra_> dholbach, do you knwo where that line comes from ? i guess we should either provide the command how to switch channels or we should remove the line til we can
<dholbach> ogra_, no idea
<ogra_> ok, on the RPi2 i have a hack that works apparently :)
<ogra_> sudo system-image-cli --switch=ubuntu-core/rolling/edge
<ogra_> sudo fw_setenv snappy_ab b
<ogra_> sudo reboot ...
<ogra_> that gets me into a rolling edge wily install
<ogra_> not sure how to manipulate the bootloader settings for grub to do the same on x86 though
<Mikaela> do I understand correctly that rolling/<alpha|beta|rc> don't exist yet? I find only edge at http://cloud-images.ubuntu.com/snappy/rolling/core/
<ogra_> rolling/alpha exists but has no images
<ogra_> http://system-image.ubuntu.com/ubuntu-core/rolling/
<Mikaela> ok
<Mikaela> http://cloud-images.ubuntu.com/snappy/rolling/core/edge/current/core-edge-amd64-vagrant.box doeesn't seem to be working at the moment or at least I don't get terminal with vagrant, it gives warnings about connection timeouting after telling ssh address, username and password
<ogra_> utlemming, ^^^ any idea ?
<Mikaela> https://paste.mikaela.info/view/d9157ee2 the warning repeats every few seconds
<sergiusens> ogra_: Mikaela on ubuntu core it would eventually be 'snappy set [snap] channel=blah'
<sergiusens> or something like that
<Mikaela> ok
<ogra_> sergiusens, right, until then we should either provide a hack in the doc or remove that sentence though
<ogra_> interesting, after i force-switched my RPi to rolling/edge running snappy rollback hangs
<sergiusens> ogra_: in theory, rolling/edge is not a channel
<sergiusens> ogra_: the channel is edge
<sergiusens> ogra_: and the release is rolling or 15.04
<sergiusens> ogra_: and switching between releases is not supported anymore
<sergiusens> we have diverged
<ogra_> yeah, seems like ...
<ogra_> top shows a hanging cp process
<ogra_> serthe above seems to work fine though
<ogra_> sudo system-image-cli --switch=ubuntu-core/rolling/edge; sudo fw_setenv snappy_ab b; reboot
<ogra_> and i bet i can update it tomorrow too
<ogra_> just rollback seems to hang ... i dont get what it copies around there though
<ogra_> OH !!!
<ogra_> it actually worked, it just took ages
 * ogra_ tries to reboot 
<pindonga> hi, trying to figure out why a service is not automatically starting when I install a snap package, when running systemctl start myservice I see: Failed to start myservice.service: The name org.freedesktop.PolicyKit1 was not provided by any .service files
<pindonga> any ideas where to look for the root cause?
<ogra_> well, does your package ship policykit and run it ?
<ogra_> there is definitely no such thing in the rootfs
<pindonga> ogra_, hi I didn't add it explicitely no, but I didn't think it'd need it
<pindonga> the binary itself runs fine, it's only when starting the systemd service that's provided by snappy that it fails
<pindonga> grepping for PolicyKit brings no hits anywhere
<ogra_> well, something tries to use a dbus service it seems ... policykit usually manages permissions for that
<pindonga> ogra_, nothing in the binary uses dbus
<pindonga> but the binary tries to access a device
<ogra_> no, but the systemd service most likely
<ogra_> ah
<pindonga>  /dev/lp0
<pindonga> actually, /dev/usb/lp0
<ogra_> did you enable that with hw-assign ?
<pindonga> but I shipped an apparmor policy with it, granting access to that file
<pindonga> mhh, no, but shouldn't the policy file be enough for that?
<ogra_> i dont think so
<ogra_> https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/
<ogra_> see that guide
<pindonga> ack, thx
<zyga> jdstrand: hey
<zyga> jdstrand: I'm wondering if something I have works okay by accident
<zyga> jdstrand: or by desing
<zyga> jdstrand: have a look at this strace please:
<zyga> jdstrand: http://paste.ubuntu.com/12061478/
<zyga> jdstrand: there's a netlink socket and a ioctl that are allowed in the default security template
<zyga> jdstrand: is that by desing?
<zyga> design
<Mikaela> If I understood askubuntu correctly, snappy has only one reporitory and you cannot add more. Will you be able to do that in the future? Thinking it more I also started wondering about mirrors, will everything always be downloaded from one server or will there be mirrors in every country like currently? Will snappy also have something to always decided the nearest mirror such as
<Mikaela> http://mirrors.ubuntu.com/mirrors.txt or http://httpredir.debian.org/
<dholbach> sergiusens, mterry: do you have links to the slides of your snappy talks?
<mterry> dholbach, https://docs.google.com/presentation/d/1qT2lrZkb7KA_CLyEGsKdE8U6AeGuhe_meakAeDHL2tQ/edit
<ogra_> Mikaela, as i understand it you will be able to have sub-stores in the main store, not sure what exactly the story is for local stores currently ... the prob here is that you cant really guarantee integrity if you allow decentralized stores ... the whole model revolves around the ability to do all security checks in a centra place
<ogra_> *central
<ogra_> what you can definitely do is have a central server that uses snappy-remote to push packages to all your systems in a LAN via scripts
<Mikaela> and sub-stores are mirrors or PPAs?
<ogra_> snaps are PPAs ;)
<ogra_> (kind of)
<ogra_> i would see sub-stores more like topic based things for a certain product ... i.e. i sell a home wlan router with a snappy base and that router only sees my sub-store so i cant offer very specific apps that are tailored for my device
<Mikaela> it doesn't sound like a good idea that you are only locked to Ubuntu's repositories to me, it reminds me a little of OS X and Windows. Will you still be able to install packages outside of repositories? And compiling is probably always surely possible?
<ogra_> yes to both of the latter :)
<Mikaela> ok
<ogra_> as i said, you can already set up a push server that installs your local snaps to all your machines
<ogra_> just by using snappy-remote and havin the ssh keys on that machine
<Mikaela> but I didn't get clear answer to the mirrors, do they still exist or is everything installed from (potentially) other side of the world?
<ogra_> no, i dont think there are store mirros pÃ¼lanned
<Mikaela> and mirrors.ubuntu.com and httpredir.debian.org what happens if I go abroad, will nearest mirror be automatically given to me?
<ogra_> beuno, might be able to elaborate
<ogra_> but my understanding is that there wont be any mirrors
<ogra_> note that the deb based ubuntu will never go away, the old infrastructure stays as is
<Mikaela> is there some other solution like p2p which was also introduced in Windows 10 from what I understood or how is the downloading handled? Some countries still have slow connectivity abroad and connection to another continent isn't like on the same continent.
<Mikaela> From what I understood there will be two editions at first, the deb-based and snappy, but later users are possibly tried to be migrated to snappy?
<ogra_> i doubt the deb based install goes away ... snappy is built from debs ... enterprise customers have installs that use debs etc etc
<dholbach> thanks mterry!
<Mikaela> so snappy is intented towards home users and debs to enterprises?
<ogra_> and there are the flavour distros (kubunt, xubuntu, edubuntu. lubuntu and whatnot) that all rely on debs ... we wont force anyone into snappy
<beuno> Mikaela, hi
<Mikaela> hi
<ogra_> Mikaela, no, i wouldnt say that :)
<beuno> we will, over time, add a CDN to distribute in many regions
<ogra_> enterprises will likely see the massive security advantage and maintainability of snappy ...
<ogra_> but we wont force them into it
<Mikaela> oh, I see
<Mikaela> more on those repositories, I can think of Virtualbox and WeeChat having their own repositories. How would those repositories work with snappy? Do they submit all new releases to the store and they appear to users some time (days?) after that? And when new software versions are released, will snappy get updates faster than the deb-based, I can think of ZNC which is very slow to be updated on Ubuntu
<Mikaela> repositories?
<ogra_> days ?
<ogra_> minutes rather ;)
<Mikaela> I am too used to the deb-system being a little slow, so I thought days might be more reasonable time than minutes, but sounds good :)
<ogra_> the nature of snaps is that their security policy makes store submissions and checks completely automatable
<ogra_> my snaps are usually available 10-20 mins after upload ... (same goes for my click packages on phones)
<ogra_> if you break the security and still insist your snap needs to go in, that might take time though
<ogra_> manual reviews and all
<ogra_> we are trying to design snappy in a way that all the issues we have seen with debs obver the last decare when having to deal with them get solved by design ;)
<ogra_> after all dpkg is 30 years old and shows its age :)
<ogra_> *decade
<Mikaela> will there still be packages packaged by Ubuntu Packagers and will they be made from the debs causing them to be as slow to update as currently?
<beuno> Mikaela, snappy doesn't ship with dpkg or apt
<ogra_> well, our rootfs is assembled from debs from the archive ... so that bit will stay
<ogra_> and it is up to the packager if he does want to use debs as input for his snap
<Mikaela> So snaps can be made separately and that is possibly even encouraged?
<ogra_> yes
<ogra_> you can even use plain upstream sources and compile them statically if you feel like
<Mikaela> ok. thanks, I think all my questions are answered now :)
<ogra_> snappy itself only applies some metadata to binaries ... how/where you get these binaries from is totalyl up to you
<ogra_> this is what i meant by snaps are PPAs btw ;)
<ogra_> if i want to provide a special libreoffice build today, i set up a PPA and build a binary with my patches
<Mikaela> oh, so if I install package outside of store it has information where to update itself when update is available?
<ogra_> in the snappy world i put all my binaries into one snap and push it to the store as libreoffice.ogra
<ogra_> so you as user can chose to install libreoffice.canonical or you can try my package just by installing libreoffice.ogra instead
<ogra_> no mangling of sources.list, gpg key shuffling etc ... my hacked package will just be available like any other to you
<ogra_> if you install a package via snappy install on cmdline or via snappy-remote there is no upgrade path if the package isnt in the store
<Mikaela> I see. So everyone can get their app to store easily?
<ogra_> yes
<ogra_> its five clicks in a webform :)
<Mikaela> sounds a lot more simple than how I imagine the deb-repos and PPAs
<ogra_> for the enduser it definitely is ... for the developer the build process is not as easy currently ... at least if your brain is still thinking deb-src :)
<ogra_> for the latter part we are working on tools to make your life super easy (there is just a sprint where people are designing the further development of the snapcraft tool that will enable you to easily turn anything into a snap
<Mikaela> oh, deb-src gives me another question, how will changelogs and getting build-depedencies work?
<ogra_> this is totally up to you as developer
<jdstrand> zyga: apparmor doesn't currently mediate ioctls. seccomp mediates the call but we have to allow it for shell scripts. however, you still need the capability and access to the device before you can use an ioctl
<ogra_> nor sure about changelog support in the store, you ave a field to provide one but i'm not sure how it will be presented in i.e. webdm to the user
<Mikaela> I mean from the user point of view. Currently there are "apt-get build-dep" and "apt-get changelog" which require deb-src lines in sources.list. Is that information stored as metadata directly
<ogra_> well, as a user you only see/get binaries
<jdstrand> zyga: we only have coarse-grained mediation for netlink, and you get that (cause you need it) when you specify a network-* cap
<ogra_> the develoer can and should provide a support contact and can also point to a website ... that should then have build instructions and/or links to source etc
<zyga> jdstrand: thanks!
<Mikaela> I see
<jdstrand> zyga: same thing applies though wrt capabilities. Ie, there are some netlink sockets that might require cap_net_admin
<ogra_> in the snappy works we rather provide the infrastructure ... the actual snaps are up to the developer
<ogra_> effectively as a developer i can have all my stuff on github and just point the urls in my snap there ...
<ogra_> uploads to the store are completely binary
<Mikaela> that makes me think of yet another thing, bug reporting, does it move to whereever the developer pointed or is apport/ubuntu-bug still there reporting to launchpad?
<ogra_> also up to the developer ... i'm not sure what our plans wrt apport are and if/how much we want ti to work with snaps
<ogra_> after all the source can live anywhere ... while in the deb based distro it has to live in some archive we control
<Mikaela> ok, thanks for all the explanation, now I think I undertand everything I was wondering
<ogra_> well, thaks for asking ... it is kind of hard trying to assemble a FAQ if nobody asks questions ;)
<ogra_> so just go on :)
<Mikaela> :)
<longsleep> ogra_: Question - is there some open source server implementation for the snappy store api or do i have to write this from scratch if i wanted my snappy installation load snaps from another place?
<longsleep> right now the URL to the store is hardcoded, so i think this has not been aked much yet :)
<ogra_> you'd have to write it from scratch i think
<longsleep> ok - should not be complicated - i just asked your sales guys what the plan is on that matter
<ogra_> ah, what did they tell you ?
<longsleep> ogra_: just wrote the mail - so no answer yet :)
 * ogra_ guesses "sub-store" :)
<sergiusens> dholbach: yeah, I tweeted them :-P
<dholbach> right
<longsleep> yes i guess that will be the answer - though for security devices it might not be good enough to get security updates from a entity governed by UK law
<dholbach> thanks, found
<dholbach> sergiusens, do you have some notes for them as well? :)
<ogra_> longsleep, werll, there beuno's mentioned CDN might come into play
<ogra_> not sure if he has taken local laws into account with the planning though :)
<longsleep> ogra_: well - the problem is that in certain countries companies or even people can be forced to insert backdoors into their code / distributions - even wore they are forced by law to not tell about it
<ogra_> yeah, i get you
<ogra_> just wondering if we take that into account with our store plans
<beuno> we likely won't be able to help those countries
<beuno> inserting backdoors into the distribution
<beuno> just like we don't today
<longsleep> well i am not sure about UK laws - but i think they could force you (Canonical) already
<ogra_> beuno, well, but if you have local laws that require encryption bits to come from local servers ....
<ogra_> i think thats a valid concern
<longsleep> well - i think people might want to have self controlled sources only for updates
<longsleep> i think that should be possible with snappy as well eventually
<sergiusens> dholbach: https://twitter.com/sergiusens/status/630061431317229568
<sergiusens> dholbach: https://twitter.com/sergiusens/status/630061036910084096
<dholbach> yep, found the slides
<beuno> ogra_, sure, and we'll serve content locally as time goes by
<dholbach> thanks
<sergiusens> dholbach: notes are in the notes section of the slides, but they are more of a memory catalyst than anything else (as in unintelligible to anyone but me)
<ogra_> beuno, right, i think thats the answer longsleep needed ;)
<dholbach> ok ok :)
<longsleep> ogra_, beuno well not really, if it is the same content then this does not help. Say the master for content is compromised, then all the children are as well when they are synced up no matter where the actuall download comes from.
<beuno> longsleep, yes. Just like Ubuntu works today
<beuno> (and every other distro)
<longsleep> beuno: no, with Ubuntu i have the choice to fetch and review all the stuff and have my machines only install and fetch stuff i previously reviewed.
<longsleep> beuno: with the store i get some binary blob. There is no way to verify that it has not been modified or was not modified after it was uploaded to the store as the store is essentially under control by Canonical.
<longsleep> It is fine to have it that way for most, but what i am saying is that there are users who want this level of control for themselves
<beuno> longsleep, you can know it hasn't been modified after upload, as it's signed with the Canonical key
<ogra_> longsleep, so why dont you host your stuff on a secure server and have code inside your snap to pull the secrets from there then
<beuno> today, you download binaries as well
<sergiusens> dholbach: we need youtube to auto translate my talk :-P
<ogra_> that woulld definitely give you full control
 * sergiusens wll be back in a bit
<beuno> so unless you re-compile everything, you're on the same boat
<longsleep> beuno: Canonical can modify at any time and sign it again
<beuno> longsleep, sure
<longsleep> beuno: yes today we do not recompile everything, but some things + platches
<longsleep> patches
<beuno> right
<beuno> so snappy doesn't allow you to do that
<beuno> OS updates need to be applied, unchanged
<beuno> and when I say snappy, I mean using the distribution as-is
<longsleep> ogra_: there is also the concern about privacy and tracking - there probably is some sort tracking in the store not everyone might be happy with either
<beuno> if you would like to take it, and manage it yourself
<beuno> compile it, etc
<longsleep> beuno: yes what what i am resarching - if and why and under what circumstances i need a system image server or eventually build own -core snap.
<longsleep> beuno: And then as a consequence also have own server providing the snap downloads.
<ogra_> system-image will go away
<ogra_> dont rely on it
<ogra_> the rootfs will be turned to snap eventually
<longsleep> ogra_: yes - i have a couple of weeks more on this matter - right now system image and rootfs is the same for me
<longsleep> ogra_: i wanted to ask you on this matter how u-d-f builds an image then there is no system image any more. I guess it will connect to the store somehow and download one snap and the device snap?
<longsleep> or gadged snap for that matter
<longsleep> ogra_, beuno: Another matter is the naming, is something which goes that far to provide own rootfs and snap server still Ubuntu Snappy or something else?
<ogra_> longsleep, thats a question for sergiuens
<ogra_> (who just left :P )
<longsleep> hehe
<longsleep> just giving you guys the idea what our enterprise customers ask me about
<ogra_> well, i dont think we want to allow self built rootfses
<longsleep> it goes even so far having no connection to the public internet
<ogra_> if there is something missing in customization options that should be fixed, but nobody should need to use a modified rootfs imho
<longsleep> ogra_: maybe not modified, but self compiled for sure
<beuno> longsleep, it can't be called Ubuntu, no
<beuno> longsleep, for enterprises, we will offer landscape
<beuno> as a way to manage updates to devices
<beuno> self-hosted landscape, that is
<beuno> but that doesn't let you override updates
<beuno> just control what gets updated and when
<longsleep> beuno: understood thanks
<beuno> there are no plans to allow people to change the rootfs in any way
<beuno> as that breaks confinement
<ogra_> longsleep, self compiled will surely work via ubuntu-device-flash ... but most likely only if you use --devloper-mode and such
<ogra_> so not really suitable for products
<ogra_> (but suitable for hacking)
<longsleep> ogra_: well one can also recompile ubuntu-device-flash, have their own keying and grab the stuff from own servers
<ogra_> indeed
<ogra_> but then you would have an insecure server
<ogra_> how would you ever make sure the same tests run ?
<ogra_> or guarantee the same quality in any way
<longsleep> i mean i am talking about specific use cases here - where Ubuntu snappy is used as open source software similar to what we do with normal ubuntu now. Modify it in any means thinkable and then provide services around it.
<longsleep> ogra_: true, that will be all different for sure. But it does not mean that it is worse. It just gives control.
<longsleep> including the power to fuck it up for sure
<longsleep> So essentially i might eventually need the transactional Ubuntu provided by snappy with the same level of freedom to create my own variant on top of it.
<ogra_> you can do that today (the on top of it part)
<longsleep> not when i want updates without public internet access or no third party connections
<longsleep> at the moment that requires patching rootfs config, patching snappy tool and patching u-d-f.
<ogra_> i suspect it will in the future as well
<longsleep> ogra_: yeah i am just starting on this - but i need to have the answers if we can use snappy or at least parts of it for our more secured environments as well
<longsleep> so at the moment for that i have to run my own system-image server and snap server, create own rootfs with patched tools and config and have patched u-d-f for image building.
<ogra_> well, i guess having a local upgrade from usb key (or SD card) upgrade abiliy mmight be a good thing for that usecase
<longsleep> ogra_: not if you have many devices
<ogra_> so you could give your customers an image they can just auto-flash by booting from it
<ogra_> or netbooting from it ;)
<ogra_> with a special boot mode
<longsleep> ogra_: well, netbooting would do it - but not all updates should force a reboot either
<longsleep> ogra_: right now customers have their own deb mirror for their specific variant on top of ubuntu
<ogra_> well, for that you can still have some push server scripted around snappy-remote
<longsleep> ogra_: mhm for that one central server needs to know all the servers and must have ssh access to them
<ogra_> yes, indeed
<longsleep> ogra_: very different from https access to a single ip from many locations
<longsleep> ogra_: so eventually we will have something - i would prefer to have a little changes to Snappy as possible for such use cases. I will keep you posted once ideas come up.
<ogra_> yeah, and dont forget, i'm only speculating as much as you ... the only one who can give authoritative answers about actual store implementation is beuno
<longsleep> sure - still it helps a lot to get some feedback from someone who is closer to source
<longsleep> eventually i might add some feature requests to the bug tracker if i am more clear on what we want to do how and then
<ogra_> +1
<longsleep> Other question, snappy yaml port negotiable option, is that implemented and how do i get the port it might have chosen instead?
<longsleep> docs say (there is no implementation for this yet)
<beuno> longsleep, it hasn't been implemented yet
<longsleep> still true i assume?
<ogra_> and i think the docs are right
<ogra_> yeah, i guess
<longsleep> ok thanks - so are there ideas how it will be implemented?
<longsleep> i want to add configuration to the spreed-webrtc snap and ports are one thing i want to have there
<ogra_> yeah
<elopio> fgimenez: I can't ssh into 10.55.33.0
<fgimenez> elopio, maybe it's down, let me check
<elopio> fgimenez: I just need the credentials. Maybe you can send them to me by mail, encrypted with my gpg key :)
<fgimenez> elopio, http://10.55.60.183:8080/ seems to be working, https://code.launchpad.net/~fgimenez/snappy-tests-job/test1/+merge/267831
<fgimenez> elopio, i've just added your ssh keys there
<elopio> fgimenez: cool, thanks.
<elopio> fgimenez: it expanded the URL, wtf
<fgimenez> elopio, you can try with MPs to snappy-jenkins-job
<fgimenez> snappy-tests-job, sorry
<fgimenez> elopio, all the config seems to be the same
<elopio> fgimenez: I wasted my day and was so happy to have found a solution in the end. I hate computers.
<fgimenez> elopio, let's see what's the difference, the user name and password for jenkins are the same as for the shared canonistack user
<fgimenez> elopio, here are the first changes for the test output https://code.launchpad.net/~fgimenez/snappy/parseable-test-output/+merge/267838, let me know what do you think
<seshu> hello there. Just checking to confirm, is WebDM written in "go programming language"?
<beuno> seshu, it is, yes
<seshu> Thanks! beuno.
 * Chipaca peeks in
<Chipaca> ogra_: you probably know these things: how's a "wan ethernet" different from a "lan ethernet"? is it just different broadcast domains? asking for http://igg.me/at/2ffEJUPWerU/x/4032581
<ted> Chipaca, I'm betting they're configured differently on the routing chip. So the LAN ports are all automatically switched without hitting the CPU.
<ogra_> Chipaca, the same thing as your "uplink" port on a switch ... it can probably speak MPLS (https://en.wikipedia.org/wiki/Multiprotocol_Label_Switching) and other shiny stuff
<Chipaca> shiny!
<ogra_> technically ethernet is ethernet though ... and normal lan ports can usually run MPLS as well ... i would expect there is some kind of optimization or so
<kyrofa> ogra_, you still around?
<kyrofa> elopio, how about you?
<kyrofa> ted, you still around?
<elopio> kyrofa: hello
#snappy 2015-08-13
<fgimenez> good morning
<dholbach> good morning
<Chipaca> o/ !
<Chipaca> good morning snappy'ers!
<longsleep> hey
<longsleep> question - do all installed snapps get passed all configs to the config hook?
<Chipaca> longsleep: hi! how's things
<longsleep> trying to understand snappy config :)
<Chipaca> longsleep: "all configs", as in configs for all apps?
<longsleep> err yes
<Chipaca> longsleep: err no :)
<Chipaca> there was an example somewhere
<longsleep> so how does webdm know the ports of all the apps?
<longsleep> snaps
<Chipaca> longsleep: webdm cheats (it has a handcrafted security policy)
<Chipaca> longsleep: it can call "snappy config" for every app
<longsleep> ah ok
<Chipaca> longsleep: and that would print out the config
<Chipaca> it doesn't *actually* exec out snappy config
<Chipaca> it links against snappy-the-library
<longsleep> got it - so then the problem is how i can share config between multiple snaps?
<Chipaca> tricky
<Chipaca> longsleep: can you explain a little of why you need it?
<longsleep> well i for example i have to share secrets between snaps - to make shared secret auth work
<Chipaca> ah
<Chipaca> longsleep: and there isn't a logical "owner" of the secrets?
<longsleep> and i might have to know what ports another snap is using to connect to the services there
<longsleep> Chipaca: well i assume someone could be made the logical owner, but how does the information get to the snaps which need it
<longsleep> i mean i could put it all into a single snap - thats what i would try to avoid though
<Chipaca> longsleep: make the owner a framework, so the others can depend on it, and give it a command that prints out the needed info?
<Chipaca> longsleep: i'm not sure that would work, but i think maybe we should make that work if it doesn't
<Chipaca> :)
<longsleep> yes i think that would work
<longsleep> at least for the configuration stuff where each snap is not the logical owner
<longsleep> ports are a different story
<Chipaca> wrt ports, you need a discovery mechanism, or making them non-negotiable
<longsleep> i want to make them configurable and negotiable
<Chipaca> the discovery mechanism can be a script as per above, or something like avahi
<longsleep> you mean a snap could provide a script that prints ot the information other snaps might want?
<longsleep> can i call stuff provided as binaries of snap-a from snap-b then?
<Chipaca> i should know that, but i'm rusty from my holidays. let me check.
<longsleep> heh :) these are good suggestions - i will try them for sure
<ogra_> Chipaca is back \o/
<longsleep> for now i just want to make the ports for spreed-webrtc a configuration
<Chipaca> ogra_: allegedly :)
<ogra_> :)
<Chipaca> we'll see for how long (!)
<ogra_> hey !
<Chipaca> ogra_: just before going away i was asked if i was willing and able to work on a zomg urgent thing
<Chipaca> ogra_: as per
<Chipaca> ogra_: so i don't know how it's played out yet :)
<longsleep> other question - the internal ports in package.yaml, these are the ports supposed to listen on local interface only or what is the meaning of internal in that context?
<Chipaca> eep! snappy update just got 'no space left on device'
<ogra_> as i understand it it is for "package intercommunication"
<longsleep> ogra_: thats good then - so i should probably add that as well
<longsleep> What about the ports in package.yaml if i make those configuration, would webdm know about it? I am still unsure what the ports section in package.yaml actually is doing
<ogra_> webdm uses the external port for the "open" link in the details page
<longsleep> yes the one marked external/ui - but what if that is a configuration ?
<longsleep> i mean i currently ship with port 8000 as webdm does not support https links. But now i want to add configuration so people can choose to expose this on port 80
<longsleep> then webdm would have to link there
<longsleep> and i want to have an option to disable all the external ports and only keep the internal one so a reverse proxy can take it over
<biezpal> hey! how cron works in Snappy? Tried to add crontab job - everything is read-only :(
<ogra_> it will use whatever systemd provides as cron replacement ...
<ogra_> not sure where we stand with that thouh
<biezpal> ogra_, thanks!
<Chipaca> i think we plan to expose timers
<Chipaca> but haven't done so yet
<Chipaca> timers as in systemd.timer(5)
<biezpal> Chipaca, but it's not implemented yet?
<biezpal> ok, got it, thx
<Chipaca> biezpal: ubuntu-core itself installs a timer, if you need an example (it's /lib/systemd/system/snappy-autopilot.timer; when we expose this, yours would be installed to a different directory, but would be the same thing) (it'd be exposed in a way that we generate the timer ourselves, so if for any reason we need to port snappy to a non-systemd system we could still do it)
<biezpal> Chipaca, thanks a lot
<longsleep> ah i just found a interesting line in the docs: Some key/value pairs in the configuration are fixed, for example all applications that listen to a port must support the "ports" config option.
<longsleep> is that the same ports as found in package.yaml?
<Rlyeh> I want remove docker, but since some apps are using docker, it will not remove
<Rlyeh> (BeagleBoneBlack)ubuntu@localhost:~$ sudo snappy remove docker
<Rlyeh> Removing docker
<Rlyeh> framework still in use by: owncloud
<Chipaca> Rlyeh: remove the dependencies first
<Chipaca> Rlyeh: sudo snappy remove owncloud docker
<Chipaca> Rlyeh: will work
<Rlyeh> I won't remove owncloud
<Rlyeh> I don't know owncloud service name to stop
<Chipaca> Rlyeh: sorry, i don't understand
<Chipaca> Rlyeh: why won't you remove owncloud?
<Rlyeh> I just want to reinstall docker
<Rlyeh> I think it will be remove if I stop owncloud service, right?
<Rlyeh> It seems docker doesn't work properly
<Chipaca> Rlyeh: still not understanding, here; sorry :-(
<Chipaca> Rlyeh: you want to reinstall docker because it's not working properly?
<Rlyeh> yes
<Rlyeh> I updated docker from 1.6.1 to 1.6.2 to day
<Rlyeh> After reboot, owncloud was not working
<Chipaca> Rlyeh: and how is it not working properly?
<Rlyeh> I checked and port 443 was close
<Chipaca> Rlyeh: and if you roll back docker does owncloud work again?
<Rlyeh> Rollbacks the docker, but still docker not working
<dholbach> hum.......
<Chipaca> dholbach: 'sup?
<Rlyeh> I don't know what happened but I have to fix this
<Rlyeh> Because of owncloud
<dholbach> Chipaca, have you seen something like this before? http://pastebin.ubuntu.com/12070190/
<Chipaca> dholbach: it's a pastebin link. I've seen many of those!
<Chipaca> :-p
<dholbach> riiiiiiiiiiight
<ogra_> dholbach, yeah., we require that you run snapcraft on your phone now for building so we check the system-image config :P
<Rlyeh> Do you know owncloud service name to stop ?
<ogra_> Rlyeh, systemctl|grep owncloud
<ogra_> then just use systemctl stop
<Rlyeh> Thank you ogra
<Chipaca> or snappy service owncloud stop
<Chipaca> in new enough snappys
<ogra_> dholbach, you get that error only by running add-apt-repo ? thats really odd
<dholbach> ogra_, it is
<Chipaca> dholbach: i hadn't seen it, but it seems you can ignore it
<Chipaca> it's probably aptsources.sourceslist or softwareproperties.ppa calling out to system-image-cli erroneously
<Chipaca> deffinitely a bug, but seems add-apt-repo is still doing the right thing
<Chipaca> aptsources
<Chipaca> dholbach: so
<Chipaca> dholbach: file a bug against aptsources
<Chipaca> dholbach: then continue with your day :)
<dholbach> ok cool, will do
<Chipaca> in fact i can probably provide a patch for you to include in your bug
<Chipaca> gimme a sec, then i'll give you a diff, if you could try that it'd be nice
<dholbach> Chipaca, https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1484470
<ubottu> Launchpad bug 1484470 in python-apt (Ubuntu) "aptsources.sourceslist or softwareproperties.ppa calling out to system-image-cli erroneously" [Undecided,New]
<Chipaca> dholbach: could you try http://pastebin.ubuntu.com/12070228/ ?
<Chipaca> wait, that's wrong
<Chipaca> dholbach: hold it
<Chipaca> dholbach: ETOORUSHED
<Chipaca> dholbach: http://pastebin.ubuntu.com/12070249/
<dholbach> Chipaca, fixed
<dholbach> at least there's no message now
<Chipaca> exactly :)
<dholbach> judging by "usage: system-image-cli  ......."
<dholbach> it might be that s-i-c is called with the wrong parameters?
<dholbach> h no
<dholbach> ah no
<dholbach> nevermind :)
<Chipaca> dholbach: config not found
<dholbach> yep
<Chipaca> dholbach: should i make this a merge against python-apt, or just include the diff in the bug and let somebody else handle it?
<dholbach> that's a question for mvo :)
<Chipaca> making an MP then
<Chipaca> eep
<Chipaca> never change gpg keys the week before your holidays
<dholbach> oops
<Chipaca> https://code.launchpad.net/~chipaca/python-apt/no-stderr-for-you-mister-system-image-cli/+merge/267935
<ogra_> hmm
<ogra_> was there a way to make ubuntu-core-launcher output verbose in syslog ?
<ogra_> Aug 13 11:40:24 localhost ubuntu-core-launcher[1761]: execv failed: Permission denied
<ogra_> not actually helpful ...
<Chipaca> ogra_: you probably got something in syslog about that
<ogra_> no, thats my issue :)
<ogra_> nothing beyond that and the .service then tellin me it exited 1
<Chipaca> ogra_: can you actually exec the thing you're trying to exec?
<ogra_> hard to tell ... my LD_LIBRARY_PATH is like 1000 pages long :P
 * ogra_ tries to get xfbdev to run on a rpi 
<ogra_> mainly as "lunch exercise"
<Chipaca> ogra_: ahhh
<Chipaca> ogra_: did you check the obvious, ie unix perms for executables and dynamic libraries?
<ogra_> sure, the tree loosk fine
<longsleep> so anyome has thoughts if the config hooks port yaml format is the same as of package.yaml - i did it that way now but does it make sense?
<ogra_> i think it is
<Chipaca> ah! i was going to check that, and got dragged into this python-apt madness
<Chipaca> longsleep: if you install webdm, what does 'snappy config webdm' spit out?
<Chipaca> longsleep: because it's got a port
<longsleep> that is broken
<longsleep> i thnk i have added a bug for this already
<longsleep> Cn
<longsleep> Chipaca: ah yes https://bugs.launchpad.net/webdm/+bug/1482720
<ubottu> Launchpad bug 1482720 in webdm "Webdm config seems to be broken / KeyError on snappy config webdm" [Undecided,New]
<ogra_> ARGH !
<Chipaca> WAT
 * ogra_ bangs head against wall 
<longsleep> Chipaca: but from the code at http://bazaar.launchpad.net/~snappy-dev/webdm/trunk/view/head:/pkg/meta/hooks/config it does nothing related to ports
 * Chipaca quickly slips pillow between ogra and wall
<ogra_> start-service.sh .... not executable ... sigh ... so silly
<Chipaca> ogra_: \o/
<Chipaca> ogra_: glad i asked the silly question first, then :)
<ogra_> yeah, thanks !
<Chipaca> longsleep: can you add a try/except around lines 64 and 65, just to see the output?
<Chipaca> longsleep: i can provide a patch if you don't python
<longsleep> Chipaca: i have many years python history - going for lunch now but will check in 20 minutes or so thanks!
<Chipaca> longsleep: excellent! and buen provecho :)
<Chipaca> I say "buen provecho", and dpm comes in
<Chipaca> i'm not a suspicious person, but ... :-p
<longsleep> Chipaca: i am back with lunch - config is empty as is expected from reading the hook code (it only exposes avahi-hostname)
<longsleep> Chipaca: if you are intersted, my hook now returns this yaml: http://paste.ubuntu.com/12070607/ - what do you say?
<Chipaca> longsleep: and assigning them works?
<Chipaca> sergiusens: longsleep is trying to make external ports configurable and negotiable
<longsleep> Chipaca: well, i am just writing that part but i would not see why not as this is all in my hook and just a matter of my applying them to the service config.
<sergiusens> longsleep: Chipaca we don't have the backend ready for that so doing it through config seems fine
<sergiusens> Chipaca: are you back at work? Or just leasure?
<Chipaca> sergiusens: back at work!
<Chipaca> sergiusens: already having two simultaneous meetings (if you don't count this)
<kyrofa> ogra_, I also can report piglow success using your rpi2 image :)
<ogra_> yippie !
<kyrofa> ogra_, but of course, when I package as a snap, I get apparmor denials. Are there any templates or caps I can use that will grant me access?
<kyrofa> (to the i2c device, I mean)
<ogra_> https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ take a look at the webcam example
<kyrofa> ogra_, ah, perfect, thank you :)
<kyrofa> ogra_, well, not quite. Is making an OEM snap the only way to provision hardware like that?
<ogra_> kyrofa, where does it say it is an oem snap ?
<ogra_> should be just a normal snap but you need to manually enable the hw access after install
<kyrofa> ogra_, oh okay. The first bit of the document talks about manually enabling hw access, but then it goes through the process of creating an OEM snap to do it automatically
<kyrofa> ogra_, so there's no way to request hw access from a regular snap?
<sergiusens> kyrofa: the manual process is the "trusted helper" or lack thereof ;-)
<kyrofa> sergiusens, ah, okay so that's the vision for how regular old snaps can get hw access?
<sergiusens> kyrofa: depends; on personal I guess it would be through the trusted helper system
<sergiusens> on custom devices, you would build your custom gadget
<kyrofa> sergiusens, gadget being another kind of snap? I've not gotten into that just yet
<sergiusens> kyrofa: it's what is the oem today
<kyrofa> sergiusens, gotcha
<kyrofa> sergiusens, I have a snap for arm that uses the piglow (via i2c). Knowing that it requires i2c support and requires explicit hw access granting, is that something I can submit to the store?
<sergiusens> kyrofa: yes you can
<sergiusens> kyrofa: users of it just need to explicitly allow the crazy things it would do with your hardware
<ogra_> now it would be really great if webdm would actually show the description for packages ... then youo could even tell the users what they need to do :P
<kyrofa> ogra_, no... that would be too much...
<ogra_> heh
<kyrofa> ogra_, the description should be in debian/control of the generated snap, right?
<kyrofa> ogra_, ah, nevermind. The manifest
<sergiusens> ogra_: in rolling that should all work; once we have snap uploads per release it can go into 15.04
<kyrofa> sergiusens, why is only the first two paragraphs of the meta/readme used? Makes it tough to format things decently
<kyrofa> sergiusens, just space concerns?
<sergiusens> kyrofa: don't get me started on how much I dislike that readme.md ;)
<kyrofa> sergiusens, ah, okay. As long as I'm not the only one ;)
<ogra_> hmm, why can i not set TMPDIR in my service start script ?
<ogra_> seems to still point to /tmp ... no matter what i do
<sergiusens> ogra_: I thought Chipaca worked on mounting tmp for snaps into a new namespace
<Chipaca> yep
<Chipaca> you get a private tmp
<Chipaca> and you like it
<sergiusens> so you need to define "see" ;-)
<ogra_> i do, xorg doesnt :P
<Chipaca> ogra_: what's xorg trying to do?
<ogra_> http://paste.ubuntu.com/12071355/
<ogra_> compiling a keymap in /tmp
<ogra_> trying to set TMPDIR doesnt make it pick up any different dir
<ogra_> and it also doesnt seem to pick up whatever is set by the launcher
<Chipaca> ogra_: could you list /tmp/ for me please?
<ogra_> oh, wait ...
<ogra_> did the tmpdir cange land in 15.04 ?
<Chipaca> ogra_: quisiÃ³! but maybe not
<Chipaca> ogra_: but looking at /tmp/ after a run will tell you
<elopio> fgimenez: my throat hurst a little. Lets talk here today.
<ogra_> Chipaca, hmm ... might be helpful if it also cleaned up after itself http://paste.ubuntu.com/12071402/
<ogra_> only 500 tmpdirs :P
<fgimenez> elopio, ok take care!
<elopio> fgimenez: I agree that parsing the writer output is the most simple thing to do now.
<fgimenez> elopio, ok, the outputWriter type is what we need, but now is difficult to use
<Chipaca> ogra_: that's the private tmp signature there
<Chipaca> ogra_: look inside those, at permissions
<elopio> fgimenez: yes, we need help from niemayer there.
<Chipaca> hopefully we haven't broken that (!!)
<ogra_> Chipaca, but why does itr leave them behind ?
<fgimenez> elopio, hopefully i'll push something today for the parsing approach, it's quite easy given the current output
<ogra_> (and inside which of them would i look now, so many choices !)
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ sudo ls -l /tmp/snap.0_xserver-fbdev.sideload_zoK1gY/
<ogra_> total 0
<ogra_> drwxrwxrwt 3 root root 60 Aug 13 14:04 tmp
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ sudo ls -l /tmp/snap.0_xserver-fbdev.sideload_zoK1gY/tmp/
<ogra_> total 0
<ogra_> permissions seem fine
<Chipaca> ogra_: i think the consensus was we wanted to clean them up with something like tmpreaper, not right after things stopped
<ogra_> hmm, k
<fgimenez> elopio, good news, we have a new docker framework version ready thanks to kickinz1 :)
<fgimenez> elopio, http://10.55.32.19:8080/job/daily-1504/
<elopio> plars: the ppa is updated. Here's the script: http://people.ubuntu.com/~elopio/spi_scripts/snappy-tests-job.sh
<ogra_> the prob is that if you develop and your service crashes in a loop you might end up with 500 dirs there :)
<elopio> fgimenez: cool. One failure in there in a restart, I haven't seen that one.
<Chipaca> ogra_: conversely, if your app crashes in a loop and we clean up tmp, and the crash was because of tmp wackiness, ...
<elopio> but it's nice, we can start collecting stats :)
<ogra_> Chipaca, well, anyway, xkb doesnt seem to see the TMPDIR at all according to the log
<ogra_> (II) XKB: generating xkmfile /tmp/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm
<fgimenez> elopio, yes :) that execution was strange, it got stuck in the first update for almost one hour, then it gave that error...
<ogra_> that doesnt look like it uses TMPDIR
<fgimenez> elopio, enyway, if you can put an instance to execute the tests it would be great to compare results
<fgimenez> *anyway
<Chipaca> ogra_: which is weird, because it doesn't have to
<elopio> fgimenez: ok, let me trigger one.
<Chipaca> ogra_: that is, you have a private /tmp/
<ogra_> Chipaca, ah, so /tmp should be transparent ?
<Chipaca> ogra_: you don't need to "see" TMPDIR or anything
<ogra_> ok
<Chipaca> ogra_: the env vars were left for backwards compat, but enough things ignore them that you have a whole /tmp just for you
<plars> elopio: cool, I'll check it out in just a bit
<Chipaca> that just happens to be a subdir of /tmp/ :)
<kickinz1> o/
<ogra_> right
<elopio> plars: you wget that script, and run it passing the ip. Let me know what happens..
<ogra_> probably thats a red herring
<plars> elopio: a lot of errors it looks like
<elopio> plars: paste please.
<plars> elopio: I'm working through them... it looks like the first was because I needed bzr, now it seems to want golang installed
<elopio> um, that's right, it will need debs.
<elopio> I didn't take thata into account... so not really that different from installing from the ppa.
<plars> elopio: will it also need autopkgtest?
<plars> I suspect it won't need some of those things
<plars> since I'm not using it for provisioning
<plars> I had hoped all the go build pieces could be skipped - I thought that was the point of providing the go binary
<plars> oh, it needs git also
<plars> elopio: ^ I didn't even see git mentioned in the control file
<elopio> plars: yes, autopkgtest from wily.
<plars> ok
<elopio> plars: that was my naive idea yesterday. Now I realize it makes no sense.
<plars> so it seems that one way or another, this is going to need a lot of customization on the host ahead of time
<elopio> we could reduce the set up needed by providing also a binary for snappy tests, but not much.
<elopio> plars: yes.
<plars> elopio: if we install from your ppa, does it automatically get the right version of autopkgtest?
<elopio> plars: only if the host is in wily.
<plars> elopio: I'm not opposed to setting it up on the test hosts, but I do worry it will cause you some pain in the future to do it this way. Having everything self-contained means you can make fewer assumptions about the test environment, and separates concerns about the tests vs. hardware much better
<plars> elopio: no, the host is on trusty here
<elopio> plars: even if we don't use autopkgtest for provisioning, we need it for reboots. So that's one dependency we can't easily work around.
<plars> elopio: so installing from the ppa wouldn't help us anyway
<elopio> plars: so install it as explained in _integration-tests/README.mf
<elopio> *md
<plars> elopio: how often do you think this package will change?
<elopio> plars: very often, but we won't need to update it every time.
<plars> https://www.irccloud.com/pastebin/IA0r1xOX/
<plars> elopio: ^
<ogra_> mterry to the rescue !
<mterry> ogra_, what's up?
<ogra_> mterry, you packaged some xorg snap once ... how did you havdle the keymap generation ?
<ogra_> *handle
 * ogra_ is stuck with that ... and i cant convince xorg to not try to use a kbd at all
<mterry> ogra_, I believe deb2snap has a hack for that.  In tools/fixes, it copies over /var/lib/xkb/*.xkm into the snap
<ogra_> oh, so you generate them in advance ?
<ogra_> i'll take a look
<mterry> ogra_, and then another hack that places them in $SNAP_APP_DATA_PATH (since that's where the ld-preload code looks for them
<mterry> ogra_, yeah, they are just sitting there on the system that runs deb2snap, so I figured we'd just use those
<ogra_> ah, i'm trying to get along without any preloading (works fine apart from that one thing)
<elopio> plars: sorry, I'm on the stand up. Let me try...
<plars> elopio: no rush
<elopio> plars: I don't get that error. fgimenez: any ideas? https://www.irccloud.com/pastebin/IA0r1xOX/
<fgimenez> elopio, never seen before, "Syntax error: Unterminated quoted string"
<kyrofa> sergiusens, does hw-assign not take effect on a running process? I always have to restart it in order for it to access the hw
 * ogra_ sends the terminator ovber
<elopio> fgimenez: this looks just fine: go run ./_integration-tests/main.go -ip 192.168.1.148. No idea what might be wrong in there.
<sergiusens> kyrofa: I am not sure, but I guess so since the apparmor profile is extended and needs to re run so it is reconfined
<sergiusens> not sure you can reconfine on the fly
<sergiusens> jdstrand: ? ^
<elopio> plars: can you set up your GOPATH, branch snappy and run the tests from there? That will give us a better clue of where's the problem.
<kyrofa> sergiusens, this gave me the impression it was possible: https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/
<kyrofa> Notice how it assigns the hw and voila, it works
<kyrofa> But mine doesn't work that way :P
<fgimenez> elopio, the testbed is amd64, right?
<elopio> fgimenez: yes according to plars.
<elopio> ah, wait, we are not building for arm.
<elopio> the host is amd64, the test bed is arm.
<jdstrand> hw-assign does more than apparmor-- it will setup the device cgroup and add the device to that cgroup. as such, I believe you much relaunch the process (unless there is a way to update the cgroups for a running process-- I don't know)
<elopio> fgimenez: in the end, we need snappy-test-job to receive all the flags that snappy integration tests receive. Is there a better way to do it instead of copying everything?
<jdstrand> possibly worth a bug for the core guys to look at
<plars> elopio: fgimenez: no, the testbed is bbb
<plars> elopio: fgimenez: I said the test host is amd64
<plars> the agent host that is
<elopio> plars: yes, my mistake.
<kyrofa> jdstrand, so the link above must have missed a step?
<plars> bbb, obviously, is not
<fgimenez> plars, elopio then we need an -arch flag too
<elopio> fgimenez: adding it...
<jdstrand> kyrofa: yes. that may have been written before mvo implemented the cgroup bits (things were landing hot at the time)
<kyrofa> jdstrand, ah, okay. Thank you!
<fgimenez> elopio, flag.Visit could be handy for passing the options around, but anyway the flags should be defined in the entrypoint, and we have two of them now...
<kyrofa> jdstrand, is the only way to do that via a reboot?
<kyrofa> jdstrand, or can I request a service restart via snappy?
<jdstrand> oh no, just restart the service
<ogra_> HEY ! everyone congratulate longsleep !!! seems we'll have the first snappy based commercial device on the market soon ;)
<jdstrand> congrats!
<jdstrand> kyrofa: give me a moment
<ogra_> secure videochat FTW !
<ogra_> screw these hangouts :)
<jdstrand> kyrofa: systemctl -a | grep <your service>
<jdstrand> kyrofa: then restart with:
<jdstrand> sudo systemctl stop <service name>
<jdstrand> sudo systemctl start <service name>
<kyrofa> jdstrand, alright, thanks!
<kyrofa> jdstrand, I saw some mailing list noise about auto-restart a while back. Was that ever implemented?
<jdstrand> I'm not sure. I think there was a branch. sergiusens ^
<jdstrand> kyrofa: I think that would still require you to kill the process
<jdstrand> (so it could restart)
<kyrofa> jdstrand, which is easy. If I'm denied access, die
<jdstrand> but maybe more was exposed
<jdstrand> yes, but then you will be auto restarted
<kyrofa> Which would solve this problem, wouldn't it?
<kyrofa> Or are you saying the parent process wouldn't let the confinement happen?
<jdstrand> so, I'll defer to the people who implemented/are implementing the feature to explain how it works :)
<jdstrand> kyrofa: I'm saying if you never ran hw-assign, it would loop until you did
<kyrofa> Ah right, agreed
<jdstrand> but ceratinly that was thought about
<sergiusens> jdstrand: that was for config changes and the idea was that services would HUP
<kyrofa> sergiusens, ah, so that won't help me eh?
<jdstrand> there are config changes, but there is also the bit about services autorestarting if they die
 * ogra_ remembers that too
<sergiusens> jdstrand: that should be in already
<jdstrand> https://bugs.launchpad.net/snappy/+bug/1461917
<ubottu> Launchpad bug 1461917 in Snappy "snappy app services should auto restart" [High,Fix committed]
<sergiusens> jdstrand: I have my services under dev dying and respawning all the time now
<ogra_> not released :)
<jdstrand> and for 15.04, it says it is fixed
<ogra_> oh, right
<jdstrand> kyrofa: so, maybe just kill your process and it will come up
<ogra_> well, my xserver snap here dies all the time and restarts in a loop ... so yes, seems to work :)
<kyrofa> jdstrand, trying
<jdstrand> sergiusens: hw-assign probably needs to HUP things
<kyrofa> jdstrand, no such luck. ogra_ think your i2c image included those changes?
<jdstrand> kyrofa: summary of backscroll-- kyrofa has a service that is denied access. he uses hw-assign. that does not take effect until the process is restarted. this is certainly because of the running process' cgroup and it not picking up the device cgroup change until the next invocation
<ogra_> kyrofa, i'm staring at a syslog where a broken snap gets permanently restarted in a loop, so yes, i thnk they are in
<jdstrand> err
<jdstrand> sergiusens: ^
<jdstrand> kyrofa: are you on 15.04?
<kyrofa> jdstrand, yeah. Let me see what happens if I just exit with a non-zero status...
<jdstrand> that may do it
<jdstrand> Restart=on-failure
<sergiusens> jdstrand: that's automatic now
<jdstrand> right, that is what I'm saying
<jdstrand> I'm looking at the diff and see that was added
<jdstrand> sergiusens: oh wait, what are you referring to, the on-failure or the cgroup?
<ogra_> http://paste.ubuntu.com/12071972/ on failure works fine ...
<kyrofa> jdstrand, interesting, it DOES work, but I get this after a few times: start request repeated too quickly
<ogra_> if the executable dies it gets auto respawned
<kyrofa> There seems to be some sort of rate limiting or something
<dholbach> mterry, if you have a quick look at bug 1484515 and bug 1484538 can you maybe tell me if I'm doing it wrong? :)
<ubottu> bug 1484515 in Snapcraft "File exists: '/home/daniel/dev/apps/xwax.snap/parts/xwax/build'" [Undecided,New] https://launchpad.net/bugs/1484515
<ubottu> bug 1484538 in Snapcraft "meta/package.yaml exists, but not found" [Undecided,New] https://launchpad.net/bugs/1484538
<jdstrand> kyrofa: yeah. so I see in http://www.freedesktop.org/software/systemd/man/systemd.service.html that on-failure ignores if the process is sent TERM (the default by kill)
<jdstrand> kyrofa: I bet if you do kill -9 it would work
<fgimenez> elopio, ping me if you need the ppa to be rebuilt
<elopio> fgimenez: https://code.launchpad.net/~elopio/snappy-tests-job/arch/+merge/267969
<kyrofa> jdstrand, that was with a non-zero exit status
<kyrofa> jdstrand, so if it dies quickly it will only do it a few times
<jdstrand> kyrofa: right. I'm saying, remove the non-zero exit status bit (it detected the loop I mentioned before), and simply send it kill -9
<jdstrand> I bet that will work
<jdstrand> I imagine the fix for this is that after hw-assign, have snappy simply restart the affected services. that probably makes most sense anyway cause if the sevice started without access to the device, it may not notice it all of a sudden has access
<kyrofa> jdstrand, you're right, that works
<jdstrand> cool
<kyrofa> jdstrand, yeah, that's the position I'm in now. I mean, it's impossible for it to notice that it all of a sudden has access since it's effectively still confined
<jdstrand> kyrofa: would you mind filing a bug on this? https://bugs.launchpad.net/snappy/+filebug
<kyrofa> jdstrand, definitey
<jdstrand> kyrofa: feel free to copy/paste from the irc backscroll
<elopio> fgimenez: thanks for the review. And yes, now I need a ppa rebuild.
<fgimenez> elopio, ok :) https://code.launchpad.net/~fgimenez/+recipe/snappy-tests-job-daily
<elopio> fgimenez: thanks! sorry for keeping you late.
<joc_> hi, could any members of Snappy Devs have a look at my snapcraft branch? i have attempted to add a new plugin and would appreciate any feedback before requesting a merge lp:~jocave/snapcraft/plainbox-provider-plugin
<fgimenez> elopio, np at all, how could we transfer the ppa to the team?
<elopio> fgimenez: I think these packages should go to the tools ppa.
<kyrofa> jdstrand, even with hw-assign restarting affected processes, I'm still not sure how I'm supposed to write a service that requires a hw resource
<fgimenez> elopio, ok, let me know if something is needed from my side o/
<kyrofa> jdstrand, if I die immediately I'll get restart throttled by systemd. If I retry constantly I know I'll never get access to it due to confinement not changing on a running process
<kyrofa> jdstrand, what's the best way to handle this?
<mterry> dholbach, heyo!  Saw your message.  I switched off the snappy team back to unity8.  Looks like you figured out the meta package one a bit more tho
<dholbach> wow, ok
<dholbach> all the best with unity8!
<mterry> dholbach, the file-exists one is weird, since we use exist_ok=True when making the directory
<dholbach> mterry, it's a link - that's probably why
<kyrofa> sergiusens, any opinion on how to best write a service that requires access to hw? ^^
<jdstrand> kyrofa: I suggest checking the return code of the open. if it fails, you can choose to die hard with exit 1 (perhaps logging to use hw-assign) or to fail gracefully and keep trying to access it
<jdstrand> kyrofa: the hw-assign restart should do a stop/start, so if you are already stopped (ie, you failed with non-zero) you should be ok
<elopio> plars: script updated.
<jdstrand> but really it is up to you as the app author
<plars> elopio: ack, thanks
<kyrofa> jdstrand, very good. I think the best solution there is probably to exit with a good log message then
<kyrofa> jdstrand, crap, except the nice log message gets eaten by systemd's "ack! it's restarting too fast" errors: http://pastebin.ubuntu.com/12072279/
<jdstrand> kyrofa: you could exit 0
<jdstrand> kyrofa: that won't trigger on-failure
<plars> elopio: this seems to be working a lot better so far
<kyrofa> Oh. Yeah, good idea
<plars> elopio: any thoughts on how you might get the results out?
<plars> elopio: that's something that could be added to the script
<elopio> plars: autopkgtest saves them in the output directory, which I think is set to /tmp/snappy-test
<elopio> let me confirm.
<plars> elopio: right, but that doesn't help you any
<plars> elopio: you'll want to upload them somewhere I assume?
<plars> elopio: get them back into a jenkins job, or something like that?
<elopio> plars: yes, I need the agent to send them back to me.
<elopio> plars: you can put them anywhere, and save the url in the result payload.
<plars> elopio: talk to ev to be sure, but I don't think there's any plans for SPI to do that.  The agent can pick up a json file with a limited amount of data in it, but probably not your full results that you care about
<plars> elopio: it's not really up to me - it's what ever you define in your script about where to put them. I'm just saying, saving them to /tmp is probably not going to help you here
<elopio> plars: so far, I just need a true or false in that json. Federico is working on saving the results as subunit, which we can translate to junit if you want. That's all we need.
<elopio> maybe for things like snapcraft we'll need other artifacts.
<kyrofa> jdstrand, should hw-assign start a service that has exited without error though?
<kyrofa> jdstrand, or is it a case of "Well, it's a snappy service. It should expect to always be running"
<plars> elopio: so for that, you'll want to have your script output something called 'spi_test_result.json' at the end
<jdstrand> I think it is the latter. it is an interesting discussion point
<elopio> plars: sure. But the agent should take care of the upload. Otherwise we'll have to pass the credentials in the script.
<plars> elopio: upload to where? I don't think they have plans to define where you store your results - at least that's what I've always heard, but you could ask
<kyrofa> jdstrand, I'll make a note of it on the bug
<kyrofa> jdstrand, thanks for all your help :)
<jdstrand> np
<elopio> plars: anywhere you want. This is not upload to spi, this is upload to any storage. What we pass to spi is only the url to that storage.
<plars> elopio: it's not up to me either
<plars> elopio: I am just providing the hardware
<elopio> when we talked to ev and noise][, I was thinking I was going to control the agent so I thought about uploading to swift.
<plars> elopio: as far as I care, you can put them in /tmp... they'll likely get lost there, but I'm not the one that needs to see them :)
<elopio> now that I don't control the agent, I can't control the upload either.
<plars> elopio: no, but you control your script - and that's where the upload happens from
<plars> elopio: all the agent can do is run the commands defined - which for this one gives you a list of commands to run
<elopio> plars: but I certainly shouldn't send my canonistack credentials on this script.
<plars> elopio: which is why I recommended putting it in a script like that
<plars> elopio: I don't have canonistack credentials here either, or any intention of using it
<plars> elopio: nor do I know where you want them, how long to retain data, whether the data is private...
<plars> elopio: only you can know what you want done with your results, or even which results you want to collect
<elopio> plars: just give me true of false for now.
<plars> elopio: otherwise, I'm either just guessing, or having to be way over-concerned with what each particular test wants and where they want it - rather than providing the hardware service
<plars> elopio: I can't even give you a true or false - I'm telling you what you need to do to get that though
<plars> elopio: you need to export that file mentioned earlier, and the spi agent itself (not anything I control) picks that up to provide a result back to SPI
<plars> elopio: afaik, it's arbitrary json up to some limit in size, so you can put whatever you want in it
<elopio> plars: you can tell me if the script I gave you exit with 0 or not. That's the only thing I need for now.
<plars> elopio: I can't do that in my stuff, because then it would override what anybody does
<plars> elopio: and I don't know how to interpret your results
<plars> elopio: is it not just as easy for you, and more beneficial, to add an echo at the end of your script?
<elopio> plars: ok, then we'll wait for the subunit change.
<plars> elopio: if that's all you need, then you could add a last line in your .sh file to do something like echo "{'result': '$?'}" > spi_test_result.json
<plars> elopio: and then later, you can have it actually save a url there, if you push it somewhere, or add an image #, or whatever you like
<elopio> plars: ok. is that the name you want?
<noise][> elopio: the agent will send test_status="PASSED" if the testcommand exits w/0
<plars> elopio: it's not what I want, it's the name defined in the documentation - I have no control over this part
<elopio> I can't upload anything to an URL, because I won't send the password to the SPI server. But I don't need that yet either, so no point on discussing about it.
<plars> elopio: but you can put whatever you like in there, up to 4000 bytes iirc? (noise][ is that right?)
<noise][> elopio: see the "Actors and Results" section at the very bottom of the docs
<noise][> plars: correct.
<plars> elopio: nor do I, but the spi server doesn't store stuff like that anyway
<ev> Yes, separation of concerns. SPI is not offering test artefact storage; that's something you need to give your tests the smarts to handle. Neither SPI nor the Lab should have any knowledge about how test results or result metadata is formatted.
<plars> elopio: you're results server does
<plars> elopio: for instance, cert team will almost certainly have the results from plainbox uploaded to the certification server
<plars> the tool they use to run tests has some sort of exporter module (not a checkbox dev, so I'm fuzzy on this) to push the results there
<plars> I think it can export other things too, but that's the one that would make sense, because it saves it off to a remote result server
<plars> but you wouldn't care to have that
<plars> or if you do, you can I guess, but you'd probably want to run your tests in a plainbox provider
<elopio> at this moment, I just care about true or false, and get subunit working.
<plars> but neither the agent, nor the provisioning kit know anything about that
<elopio> then I'll care about other things, and we'll figure out how to get them.
<ev> plars: I think a reasonable compromise might be that the credentials live on disk where they're used
<ev> Like how mojo specs are done
<plars> elopio: cool, these tests still seem to be running well, but they take a while. Any idea how long on bbb?
<ev> So the tests might know the path to creds, but they're stored on the agent's host
<ev> Reasonable, or are you worried this breaks separation of concerns?
<elopio> plars: with my new microsd that says something like hc1, around 30 minutes.
<elopio> with my old one, more close to 1 hour.
<plars> ev: it certainly breaks separation of concerns, but so does the local setup needed on the agent host so that his tests will run. It might be nicer if we could find some other way, but I'm happy to make it work for now as long as everyone understands the inherent fragility of doing it that way
<elopio> noise][: ok, I updated the script with set -e. That's good enough for me now.
<plars> ev: ^ tests > 1hour still a problem?
<plars> elopio: I don't think it automatically saves the output
<plars> elopio: oh, sorry I misread. nm :)
<plars> somehow I thought you said -x
<ev> plars, elopio: tests greater than an hour are a problem, yes
<elopio> the tests that take a lot of time are the failover tests, which are the useful ones.
<elopio> and currently we have only like 4.
<elopio> we could just run them on the cloud, but then the usefulness of the bbb lab is not that much.
<plars> ev: is there any way for the test spec to give it better hints about how long it should run?
<elopio> there are some things that will reduce the time, like caching the update download. But I'm not sure when we'll have that.
<ev> plars: not yet, but it's intended: https://trello.com/c/eJF6ngJs/110-story-document-intended-behaviour-of-long-running-tests-exceeding-the-timeout
<plars> elopio: I think, iiuc, it would work right now, but if it takes too long it could end up looping
<ev> (see Celso's comment in that card)
<ev> yeah, it'd loop
<elopio> another thing we have in mind is to deploy many cloud instances and run the tests in parallel. But with the current agent approach for bbbs, we have access to only one.
<ev> I'm going to book us a meeting to discuss the credentials thing and setupcommand/testcommand being pushed a bit more towards the tests
<plars> ev: is there some way to uniquely identify the agent? One big hint that could make this more efficient is if the agent requests a test opp, never acks, and requests one again
<elopio> ev: ok. If possible, please make it around this time.
<elopio> ev: even better if you can make it at 14:00 utc, so we have federico.
<plars> then we could be more permissive with the timeout, default it to 2 days or something crazy
<plars> should still be possible to override though I think, since there could be a test spec that wants to run some long stress test for a month
<ev> elopio, plars, noise][: invite sent
<ev> plars: I've added your thoughts to the card
<ev> and I've moved it up, as this is going to bite us quick it seems
<ev> elopio, plars: is that your assessment as well?
<plars> ev: I hope so, if it bites us soon then it means we're making great progress on fully getting these things running and doing something useful :)
<elopio> ev: yes, we want to add more tests, so the time will definitely increase even if we find a way to run the current tests faster.
<ev> thanks guys
<plars> https://www.irccloud.com/pastebin/rH0vRoXl/
<plars> elopio: some more errors after running for a little over an hour ^
<plars> elopio: I'm just running the script by hand for now
<elopio> plars: that script is for rolling
<elopio> your bbb is in 15.04. We need a different script, or to pass an argument to that script.
<plars> elopio: oh cool. Well that will be controlled by what image we tell it to install, so that's no problem then
<plars> cool
<elopio> plars: yes, I suppose it's better to make a different test image, different script.
<longsleep> Mhm snapp config docs say that the service will be restarted by snappy automatically. Does not seem to be true.
<plars> elopio: either would work fine. That would be in the spec to tell it which to call, and the spec is defined for a given image type
<plars> so it could call different scripts or pass different args, or whatever makes sense
<ogra_> longsleep, file it :)
<kyrofa> sergiusens, jdstrand Restart=on-failure is only put in the .service file for a sideloaded snap, not for one installed from the store. Is that on purpose?
 * jdstrand did not implement this feature, but this sounds like a bug
<kyrofa> jdstrand, alright, I'll log that one as well
<longsleep> ogra_: filed bug #1484641
<nothal> Bug #1484641: snappy config command does not restart service after setting the configuration <Snappy:New> <http://launchpad.net/bugs/1484641>
<ubottu> bug 1484641 in Snappy "snappy config command does not restart service after setting the configuration" [Undecided,New] https://launchpad.net/bugs/1484641
<longsleep> But i pushed a new Spreed WebRTC version with configuration hook to the store nethertheless. Works fine as long as you know how to get the systemd service named and to restart it.
<kyrofa> sergiusens, double-checking before I log a bug: https://bugs.launchpad.net/snappy/+bug/1461917 is fixed for `snap:qpy install` invocations (from the store or
<ubottu> Launchpad bug 1461917 in Snappy "snappy app services should auto restart" [High,Fix committed]
<kyrofa> Argh
<kyrofa> sergiusens, double-checking before I log a bug: https://bugs.launchpad.net/snappy/+bug/1461917 is fixed for `snappy install` invocations (from the store or sideloaded), but NOT for things installed via webdm
<kyrofa> sergiusens, I thought those followed the same execution path through the snappy lib
<sergiusens> kyrofa: right, but webdm would need to be rebuilt, so log a webdm bug ;)
<kyrofa> sergiusens, I just added webdm as an also-effects. Is that okay?
<sergiusens> yeah
<kyrofa> sergiusens, ooooooh right... static linking....
<kyrofa> sergiusens, man that takes a while to get your head around
<pcoca> Hi everyone, I'm using snapcraft and using the ubuntu pluging I got error about files in common
<pcoca> Is there any way to fix that problem?
<ted> pcoca, They're probably trying to install the same thing, so for instance if you were using a python3-project and installed python-dev they'd conflict.
<pcoca> ted: so, I should get rid of some of the packages
<pcoca> ted: thanks!
<pcoca> ted: Let's see if I can get the functionality getting rid of some packages :)
<ted> Heh, you don't need packages! ;-)
<pcoca> ted: Hi Ted, Still with the same issue, I'm not able to make a snapcraft out of a python script that requires opencv, I've tried several plugins python2-project, python3-project, ubuntu
<pcoca> ted: I'm almost thinking about converting the python script to a deb, and then deb2snap, instead of snapcraft :)
#snappy 2015-08-14
<Rlyeh> Hi
<Rlyeh> I replaced a fresh snappy on my BBB, updated ubuntu-core 3 to 4, installed docker and then owncloud
<Rlyeh> But owncloud is still not working on port 443! http://paste.ubuntu.com/12077510/
<Rlyeh> Did I missed something?
<Rlyeh> Anyone knows how to use owncloud?!
<Rlyeh> When I run owncloud, docker can't find owncloud locally and it download from docker repo! http://paste.ubuntu.com/12077534/
<Rlyeh> No idea for owncloud?
<tasdomas> hi
<tasdomas> is there a way for a snap to know which other snaps are installed on the system or are the snaps completely isolated from each other?
<fgimenez> good morning
<tasdomas> morning, fgimenez
<fgimenez> hey tasdomas
<dholbach> good morning
<tasdomas> are there any service discovery solutions for snappy? Both internally (snaps discovering other snaps) and externally (other wireless devices discovering services running on snappy
<ogra_> well, netstat is installed by default :)
<ogra_> (nothing hiher level yet, no)
<ogra_> *higher
<pcoca> Hi everyone, I'm not able to make a snap with snapcraft out of a python script that requires opencv, I've tried several plugins python2-project, python3-project, ubuntu, but it doesn't include the library.
<pcoca> has this something to do with the setup.py?
<longsleep> Question - what is the preferred way to load additional kernel modules in snappy?
<longsleep> in normal Ubuntu i just cat them at the end of /etc/modules ...
<ogra_> you ship them in your devce tarball
<ogra_> or gadget snap later ...
<longsleep> no way to do this from a snap? So stuff like that always needs oem?
<ogra_> yes
<ogra_> well, kernel/device
<ogra_> oem is bootloader only currently
<longsleep> right
<ogra_> for now i'd just ship system/etc/modules in the device tarball
<longsleep> yes i can do that
<longsleep> i read through the webcam example
<longsleep> it seems to expect that the driver for the webcam gets loaded automatically
<ogra_> yeah
<longsleep> so i was wondering if there is a way for manual driver loading for other stuff
<ogra_> i think we'll have that via snappy-config at some point ... i.e. you can ship multiple modules and define which ones are loaded through a config hook
<longsleep> yes that would make sense
<ogra_> once we have snappified the device tarball side
<ogra_> yay
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ df -h|grep oem
<ogra_> /dev/sda1                     15G  813M   14G   6% /oem
<ogra_> 16G writable space :)
<longsleep> yah!
<ogra_> on USB stick
<longsleep> so what did you do?
<longsleep> moved oem to usb stick?
<ogra_> just format it ext4, label it writable, copy the SD writable content over and re-label the SD writable to old-writable
<longsleep> right, so snappy auto mounts stuff?
<ogra_> well, on boot
<ogra_> i did the above on a PC :)
<ogra_> and then booted with USB and SD ...
<ogra_> we mouont by label ... so switching the writable bts to a bi 3TB USB disk is easy
<ogra_> i just needed to test it (i want to blog about it)
<longsleep> ah ok understand
<longsleep> any news on getting snappy to automatically expand the partition on boot?
<ogra_> working on it :)
<longsleep> cool
<ogra_> i hope ot have that landed next week in the rolling channel
 * ogra_ tries some fun stuff on the side with https://github.com/paimpozhil/DockerX2go/tree/master/xubuntu
<ogra_> :)
<longsleep> i guess i should switch to whatever becomes snappy 15.10 at some point
<ogra_> not sure there will be a snappy 15.10, currently we are backporting all backportable bits to 15.04
<longsleep> ogra_: ok - well i do not care about the version really so long as i am on the latest
<ogra_> could well be that we directly go to 16.04 then with the next iteration of the stable channel
 * ogra_ knows there are some release plans ... but i cant find them atm
<longsleep> ogra_: btw i ended up creating some unconfined snaps to handle some internal stuff - should i try hard to avoid unconfined stuff?
<ogra_> well, i would ... but i want my snaps in the store without delays :)
<longsleep> ogra_: things need to read all kinds of things from /proc for example
<longsleep> ogra_: and i am currently skipping the work to create custom profiles for this and just leave it unconfined
 * longsleep wonders if that is a problem
<ogra_> i think the planned sub-store setup together with the oem snap will help here
<ogra_> in such a sub store you can break out of confinement if you want afaik
<ogra_> since you make the rules for it
<ogra_> dont quote me on that though :D
<longsleep> ogra_: we will try it out for sure :)
<longsleep> ogra_: unconfined snaps cannot go into the store at all or is it a matter of review only?
<ogra_> completely unconfined cant i think ...
<ogra_> (well, technically they can ... thats indeed a policy thing)
<longsleep> not that i am going to submit those at the moment but eventually it might be nice to have
<ogra_> as i said, with your ownb sub-store it should be possible since i guess you make the rules abouot what goes in there
<longsleep> right
<ogra_> so if adjustment to the confinement policy is needed by your oem setup that should be possible
 * ogra_ hopes someone corrects him if he talks rubbish :)
<longsleep> well let me try to avoid unconfined for the next snap, though for this need to understand the assing block in the yaml
<longsleep> but first - lunch!
<ogra_> enjoy !
<longsleep> thanks
<ogra_> hmm
<ogra_> sergiusens, we need a way to ship sysctl settings in the kernel snap ...
 * ogra_ just notices that the RPi NIC exposes the typical smsc95xx where you need to adjust the vm.min_free_kbytes default to make it not drop frames
<longsleep> ogra_: yes - i need that - currently fusing them into initrd :/
<ogra_> such an old bug ... :/
<sergiusens> ogra_: I did sort of mentioned that to lool
<sergiusens> ogra_: I'm just waiting for the new snap formats to show up
<ogra_> cool
<ogra_> i guess it currentrly is possible via the device tarball
<ogra_> (shipping a file in system/etc/sysctl.d/ ....)
<longsleep> yes - that works though is too late for some settings
<longsleep> (thats why i currently have them all in initrd hook)
<ogra_> https://bugs.launchpad.net/linux-linaro/+bug/664477
<ubottu> Launchpad bug 664477 in Linaro Linux "System hangs due to cascade of smsc95xx errors " [Medium,Fix released]
<ogra_> 2011
<ogra_> oh, even reported in 2010
<longsleep> and that happens on rpi2 as well?
<ogra_> it is a hardware thing
<longsleep> ah they have the same nic
<ogra_> well, or a kernel defaults one ...
<ogra_> depends which way you look at it :)
 * ogra_ files bug 1484898
<ubottu> bug 1484898 in Snappy "device tarball needs to allow setting sysctl defaults" [Undecided,New] https://launchpad.net/bugs/1484898
<ogra_> bah
<ogra_> time="2015-08-14T11:12:17Z" level=fatal msg="Error response from daemon: Cannot start container 22626e0f94cf7ea90bd53faf37a8526676e2a572dc16b045a74e428e9d8d8b3b: [8] System error: exec format error"
<ogra_> (RaspberryPi2)ubuntu@localhost:~$
<ogra_> *sniff*
<Chipaca> dholbach: python-apt upstream now includes the verbosity fix
<longsleep> armf vs x86_64
<Chipaca> dholbach: dunno where to go from here -- resync?
<Chipaca> dholbach: that is: it's in the debian/sid branch of debian's git thing
<dholbach> Chipaca, let's wait for mvo to land it in ubuntu then
<dholbach> he knows which branch to merge and what to upload
<ogra_> longsleep, yeah
<Chipaca> dholbach: okie doke
<dholbach> :)
<longsleep> yay snappy has 'netcat-openbsd' available - is that intentional or accident?
<ogra_> neither :)
<ogra_> it is inherited from the ubuntu-core seeds
<longsleep> so should i use it from the system or rather have my own python netcat in each snap?
<ogra_> might be ripped out and become part of comfy ... dont rely on it being there
<longsleep> all right
<longsleep> its so handy to pipe stuff into sockets for testing ..
<ogra_> systemd, kernel and the snappy binary are the only guaranteed bits in the core :)
<ogra_> (and the glue necessary to make them work, but that glue can change at any time)
<longsleep> well i guess all the stuff from the default aa profile is pretty much solid
<longsleep> by the way, sideloading snaps with snappy-remote has a bug. Id does not wait for services to stop before replacing files leading to 'text file busy' issues
<ogra_> i thnk i have seen that with local sideloading too
<ogra_> might be a general race
<Chipaca> oh?
<ogra_> (just exposed stronger via remote)
<Chipaca> that sounds like a bug :)
<longsleep> it annoys me pretty hard at the moment :)
<ogra_> Chipaca, yes, i only noticed it yesterday when playin with my broken xorg stuff
<Chipaca> "stop" waits
<longsleep> http://paste.ubuntu.com/12078757/
<Chipaca> and i'm pretty sure "remove" calls stop
<ogra_> (where i had syslog tailed permanently in a separate window ... sometimes it didnt stop the running process in time and fell over)
<Chipaca> i mean, i wrote it that way :) but maybe we broke it?
<longsleep> if that happens one has to remote the snap two more times
<longsleep> first time after the error service gets not started
<ogra_> well, we stop the service ... but that service runs a wrapper that runs a shell script (in my case at least) which in turn runs a subcommand ...
<longsleep> third time everything works fine
<Chipaca> it sounds like that is unpacking into the current directory
<Chipaca> hmm
<ogra_> longsleep, thats exactly the same i have seen yesterday
<longsleep> Chipaca: syslog here: http://paste.ubuntu.com/12078774/
<longsleep> (it does not stop the service)
<Chipaca> lovely D:
<Chipaca> so
<Chipaca> sideloading is treated differently, in that the usual "is installed" check is skipped
<Chipaca> because otherwise it slows you down (you'd have to remove the package manually before re-sideloading it)
<Chipaca> however that does mean it's not really expecting this error
<Chipaca> longsleep: how reproducible is this?
<Chipaca> longsleep: if i'm understanding the error correctly, bumping the version would "fix" it
<Chipaca> longsleep: where i'd consider that a workaround more than a fix, but
<Chipaca> good enough to confirm that that is what's happening
<Chipaca> i think
<Chipaca> :)
<ogra_> i have seen it a lot yesterday
<ogra_> i would say about a third of my install attempts showed it
<Chipaca> yeah
<Chipaca> the unpack is done before the activate/deactivate
<Chipaca> and in fact it's done straight to the directory it'll work from
<Chipaca> which makes sense, as some of the checks then rely on that
<Chipaca> the checks done before activation
<ogra_> the directrory is gone after the failure though
<Chipaca> however when sideloading it's an issue
<ogra_> something seems to wipe it
<Chipaca> well, yes
<Chipaca> installation cleans up on failure
<Chipaca> and as it's not coping with reinstallation of the same version at all
<Chipaca> ... well, i don't need to spell it out :)
<ogra_> :)
<Chipaca> so, either we block sideloading of the same version
<Chipaca> or we cope with it properly
<Chipaca> the current situation is a recipe for heartache
<ogra_> it doesnt onyl happen with the same version (i need to bump the version when changing sccomp or apparmor profiles)
<Chipaca> ogra_: wat
<Chipaca> ogra_: i'd love to see the error when it's a different version!
<Chipaca> it surely can't be the same :)
<Chipaca> (if it is, something is seriously wrong, not just a cornercase bug)
<ogra_> i'd give you the log, but since the broken service was starting in a loop that wont be much helpful
<ogra_> (over like 4h or so)
<Chipaca> i'll write it down to you not having had lunch until i see logs :-p
<longsleep> Chipaca: it fails very time
<Chipaca> longsleep: and if you bump the version?
<longsleep> let me try
<Chipaca> ta
<longsleep> that should work i assume
<Chipaca> it failing in a different way would be interesting
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ sudo ls -lh /var/log/syslog
<ogra_> -rw-r----- 1 syslog adm 13M Aug 14 12:10 /var/log/syslog
<Chipaca> it failing in the *same* way would be *very interesting*
<ogra_> hmm, dont we have logrotate in place ?
<ogra_> (the log starts on the 7th)
<longsleep> Chipaca: did not fail but now it runs twice :)
<longsleep> Chipaca: the old version still runs
<Chipaca> longsleep: ok
<Chipaca> longsleep: where it says "ok", read it in a tone of voice that implies serious non-OKness
<longsleep> :D
<Chipaca> longsleep: how do you stop your service?
<longsleep> Chipaca: i let systemd take care of it
<longsleep> Chipaca: i assume it just kills it
<Chipaca> it should
<Chipaca> what's going on
<Chipaca> longsleep: what does systemctl status tell you?
<longsleep> degraded
<longsleep> http://paste.ubuntu.com/12078864/
<longsleep> from what i see in the logs, the old service never was stopped
<Chipaca> and 'systemctl stop dotstar-leds_dotstar_0.0.1-1.service' just works, yes?
<longsleep> yes
<Chipaca> dammit, i can't blame it on you :-)
<longsleep> heh
<Chipaca> i'll file a bug, in penance
<longsleep> thanks :)
<Chipaca> https://bugs.launchpad.net/snappy/+bug/1484922
<ubottu> Launchpad bug 1484922 in Snappy "Sideloading a snap with a service does not stop the service of the old version" [Undecided,New]
<Chipaca> now let's see if i can reproduce it
<longsleep> btw the reason my system is marged as degrated is none of my snaps but rather webdm because of bug 1466672
<ubottu> bug 1466672 in Snappy 15.04 "webdm failed to start / Failed to listen 224.0.0.251:5353" [Undecided,New] https://launchpad.net/bugs/1466672
<Chipaca> yep
<Chipaca> degraded means a unit failed
<Chipaca> sergiusens: you around?
<longsleep> btw i find it strange that there is a poststop but no poststart in package-metadata yaml for services.
 * longsleep would really like to run some things after the service started and without dash hackery
<sergiusens> Chipaca: yeah
<Chipaca> sergiusens: what's blocking https://code.launchpad.net/~chipaca/snappy/snappy-man/+merge/266203 do you know/remember?
<Chipaca> longsleep: so, i can't reproduce the issue with snappy from wily edge. you're on 15.04 stable?
<sergiusens> Chipaca: me
<sergiusens> :-)
 * Chipaca hugs sergiusens 
<longsleep> Chipaca: yes
<longsleep> Chipaca: version 4 from stable channel
<Chipaca> longsleep: 1.4?
<Chipaca> oh, wait
<Chipaca> this is not that
 * Chipaca starts another kvm
<longsleep> Chipaca: ubuntu-core   2015-07-29 4        ubuntu
<longsleep> Chipaca: channel: ubuntu-core/15.04/stable
<Chipaca> yep yep
<Chipaca> the 1504 i had was something else :)
<Chipaca> longsleep: also can't reproduce it with 15.04 rev 4
<Chipaca> longsleep: using the python xkcd webserver snap
<longsleep> Chipaca: do you have a service which is a binary file?
<Chipaca> no
<Chipaca> that's next
<longsleep> i think text files can always be replaced
<longsleep> but at least your service should run twice when you update to a new sideloaded version
<longsleep> (if that service can be run twice)
<Chipaca> longsleep: this is with a different version, so replacing file should not be an issue
<Chipaca> exactly, it's the running twice thing that i was trying for
<longsleep> ah
<longsleep> Chipaca: could be also related to snappy-remote - i am running 0.4-0ubuntu1build1 on trusty
<Chipaca> is snappy-remote anything other than something that ssh's in and runns snappy with all the given args?
<sergiusens> longsleep: Chipaca snappy-remote just uses the snappy binary on the host
<Chipaca> exactly
<Chipaca> i imagin it as a two-line shellscript
<sergiusens> the problem is in snappy itself
<sergiusens> Chipaca: dream all you want :-P
<Chipaca> :)
<Chipaca> sergiusens: :)
<Chipaca> sergiusens: see, if instead of having an option for the host you took it from environ, you could've made it a oneliner :-p
<Chipaca> ssh ${SNAPPY_REMOTE_HOST:?Set SNAPPY_REMOTE_HOST to what to ssh to} -- "$@"
<Chipaca> done \o/
<Chipaca> oh, add a "snappy" before the $@
 * Chipaca does not have enough :-P to sprinkle into that
<Chipaca> the go-example-webserver in snappy-examples is broken \o/
<Chipaca> ah, maybe i need to build it properly :-)
<Chipaca> picky, pikcy
<Chipaca> i wonder if this is something on arm only?
<longsleep> Chipaca: that example is also problematic as it will fail to run twice
<Chipaca> because on amd64 i can't get it to break
<longsleep> (becasue of port already in use)
<Chipaca> longsleep: ah!
 * longsleep has problems with the order of letters today
<Chipaca> maybe?
 * Chipaca adds a ports section
<longsleep> Chipaca: well with the go service you should get the text file busy problem
<Chipaca> longsleep: not with different versions
<Chipaca> it's two separate issues
<longsleep> right
<Chipaca> the text file busy one is due to how we (don't) handle sideloading of the same version
<longsleep> really? Why - if the service would stop there would be no text file busy problem
<Chipaca> the two services of different versions of the same app is really worrying
<Chipaca> longsleep: on install, first we unpack, then we do some checks, then we stop the old version and start the new one
<longsleep> Chipaca: ah ok
<Chipaca> longsleep: :)
<Chipaca> longsleep: so one workaround for that would be to, on sideload, stop before unpack
<Chipaca> longsleep: because sideload install is not going to happen automatically, so the downtime is more tolerable
<Chipaca> maybe also don't clean up on sideload install failure
<Chipaca> slightly uncomfortable about making the two so different though
<Chipaca> rsalveti: sergiusens: opinion about ^?
<elopio> good morning.
<sergiusens> Chipaca: I thought we wanted to kill the version on sideload installs and just create a hash
<Chipaca> we did? i have no memory of that
<Chipaca> but that does not mean we didn't :)
<sergiusens> Chipaca: maybe you weren't there :-P
<sergiusens> Chipaca: but the version is meaningless and this sort of solves people accidentally hardcoding stuff during development
<Chipaca> longsleep: can i have a pastebin of you doing the snappy remote of an updated version that resulted in two services running, please?
<longsleep> Chipaca: i do not know why, but now it did stop the old service when i installed a new version
<Chipaca> sigh
<Chipaca> longsleep: ok
<longsleep> Chipaca: it might be related to the failure before
<Chipaca> longsleep: so, how about this
<longsleep> let me try to reproduce
<Chipaca> longsleep: you tried to install the same thing
<Chipaca> longsleep: it aborted because of text file thing
<Chipaca> longsleep: but cleaned up -- removed files
<Chipaca> longsleep: service still running, because who cares the file was rm'
<Chipaca> ed
<longsleep> let me try - should be easy to replicate
<Chipaca> longsleep: installed, snappy did not find old thing, did not try to disable service
<Chipaca> so that would result in two services
<Chipaca> as a consecuence of the text file thing
<longsleep> most likely yes
<Chipaca> without it being a whole separate problem
<longsleep> i am on it
<Chipaca> thank you
<longsleep> starting from clean state now
<elopio> fgimenez: yesterday I was looking at the subunit tools. With what you have in that parser branch, it should be really easy to integrate with calls to subunit-output.
<longsleep> Chipaca: yes it just failed to install, removed the stuff and the service is still running
<longsleep> os i see the process and the file is gone
<Chipaca> that makes sense
<longsleep> Chipaca: yes reproduced - it only runs twice when the text file busy error happend
<elopio> fgimenez: let me know when you are done with the parsing and I can start piping the subunit output to a file.
<Chipaca> longsleep: that's a relief :) thank you!
<fgimenez> elopio: great, only the binary encoding is missing
<Chipaca> longsleep: it does make fixing the text file thing in stable more important
<Chipaca> sergiusens: do we want to do the version hash thing in stable? or just workaround this there?
<longsleep> Chipaca: yes - for development this can result in all kind of issues
<Chipaca> yep
<fgimenez> elopio: there's already a file step in the pipeline, we can remove it if needed
<Chipaca> longsleep: for the time being, can you include 'snappy-remote yadda yadda remove the thing' before a same-version install?
<longsleep> Chipaca: sure
<Chipaca> snappy-remote --url=ssh://10.1.7.161 remove dotstar-leds && snappy-remote --url=ssh://10.1.7.161 install dotstar-leds_0.0.1-1_armhf.snap
<Chipaca> or sth like that :)
<longsleep> yeah should do the trick
<longsleep> let me try
<longsleep> Unknown command `remove'. You should use the install command
<longsleep> :D
<Chipaca> sergiusens: wat ^
 * Chipaca no habla snappy-remote
<ogra_> lol
<ogra_> its just a two linne shellscript
<ogra_> :P
<Chipaca> that's my mental model of it!
<Chipaca> and if it were, that would've worked
<Chipaca> so my mental model needs updating :)
<elopio> fgimenez: oh, so what you have in parser.go is like the subunit v1 protocol, right?
<ogra_> or the shellscript needs a third line :)
<Chipaca> ogra_: tomeito, tomahto
<ogra_> :D
<fgimenez> elopio: yep, that should connect with the binary encoder in its next field
<Chipaca> snappy-remote *only* knows install
<Chipaca> longsleep: how about: ssh ubuntu@10.1.7.161 sudo snappy remove dotstar-leds && snappy-remote --url=ssh://10.1.7.161 install dotstar-leds_0.0.1-1_armhf.snap
<fgimenez> elopio: and the binary encoder with the file, or stdout, in the next field
 * Chipaca does not know if snappy-remote keeps keys in a nonstandard place, but maybe that'll work :)
<longsleep> Chipaca: sure
<longsleep> Chipaca: that works just fine
<longsleep> though i found another issue with that snap .. :/
<longsleep> problem is that SNAP_APP_TMPDIR=/tmp
<longsleep> where it should be export TMPDIR="/tmp/snaps/dotstar-leds.sideload/0.0.1-3/tmp"
<Chipaca> longsleep: are you sure?
<Chipaca> i thought stable already had the private tmp fix?
<fgimenez> elopio: not sure if the binary encoding step is a must
<longsleep> Chipaca: yeah try hello-world.env
<elopio> fgimenez: so I think that if we use subunit-output to generate the v2 stream, we can combine the parser.go and binary.go. Not sure if you'll like this idea though.
<Chipaca> longsleep: sure, let me check
<Chipaca> longsleep: stable already has the private /tmp fix
<Chipaca> longsleep: all of /tmp is yours
<Chipaca> longsleep: and /tmp will be actually a private mount of /tmp/snap.$UID_$APPID_$RANDOM
<Chipaca> /tmp
<longsleep> mhm i write stuff here SOCKET=$SNAP_APP_TMPDIR/dotstar_socket into the service
<Chipaca> longsleep: so if you look at /tmp you should see a bunch of "snap.0_somthing.sideload_Xyws/
<longsleep> from the service i mean
<longsleep> Chipaca: yes i see them
<Chipaca> longsleep: whereas the old tmpfile was /tmp/snaps/
<longsleep> writing them from the service works fine
<Chipaca> longsleep: so you'd see /tmp/snaps
<Chipaca> longsleep: now
<longsleep> but in the binary tmp points just to /tmp
<longsleep> which does find nothing
<Chipaca> longsleep: we do still set /tmp/snaps, for backwards compat, so that would be /tmp/snap.0_something.sideload_yadda/tmp/snaps/something.sideload/version/tmp
<Chipaca> longsleep: ah, you mean SNAP_APP_TMPDIR is different in the service and in the binary?
<Chipaca> that is entirely possible :-(
<longsleep> hold on i am trying clean setup
<Chipaca> longsleep: um
<Chipaca> longsleep: are you expecting to find the same things in tmp from both service and binary?
<Chipaca> because it'll be a _different_ tmpdir every time
<longsleep> Chipaca: yes
<longsleep> ah
<longsleep> well, then i got a problem :)
<Chipaca> longsleep: tell me more
<longsleep> Chipaca: service creates a unix socket file
<longsleep> Chipaca: i need that socket location from a binary
<Chipaca> longsleep: $SNAP_APP_DATA_PATH ?
<fgimenez> elopio: whatever works :), where can i read about subunit-output?
<longsleep> Chipaca: i would prefer if that file is not persistent
<elopio> fgimenez: sudo apt-get install subunit-output
<elopio> subunit-output -h
<longsleep> Chipaca: i thought there is a per snap temp folder
<elopio> fgimenez: it even allows to attach files to the results.
<Chipaca> longsleep: that's a very interesting use case, because i think ted was asking why we'd have SNAP_APP_DATA_PATH and SNAP_APP_USER_PATH at the same time, and that's one case where you'd want it (module persistence)
<longsleep> Chipaca: what is how i understood the name SNAP_APP_TMPDIR
<Chipaca> ted: ^^^ there you go, a use case :)
 * ted reads backlog for this "use case" ;-)
<ted> Yeah, for something like that you probably want something per-snap in /run
<longsleep> ted: yes - though that does not seem to exist
<Chipaca> ted: yes, for socket you want a XDG_RUNTIME_DIR thing
<Chipaca> ted: but you see my point about getting at the same data from service and binary?
<ted> Yes, so I think that you want USER for things running as a user. But that is still useless for services.
<Chipaca> sergiusens: you've been in more snappy sprints than I :) anything planned or thought on runtime dir?
<ted> It seems like, in general, we need a way for frameworks to export environment variables.
<ogra_> Chipaca, the prob is that one sprint usually overrides the other ... so only the last counts ;)
<Chipaca> longsleep: to unblock you right now, sadly, i don't have a better answer than (ab)using the data dir
<fgimenez> elopio: ok thx looks very good, we can pipe to a exec.Command easily
<Chipaca> ogra_: s/overrides/refines (sometimes with a big axe)/
<ogra_> :)
<longsleep> Chipaca: right, but could i not just write to /tmp or is that mounted to some local path all the time?
<elopio> fgimenez: yes. I found the source: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/subunit/wily/view/head:/python/subunit/_output.py
<Chipaca> longsleep: /tmp/ is per-process private mount of /tmp/snaps.$ID_etcetc
<longsleep> Chipaca: ok - well then i stick for the persistent location for now
<elopio> fgimenez: we could also call the c library from go, but it doesn't seem to have the file attach options. I think I prefer to just call this binary.
<Chipaca> would having a per-appid runtime dir be enough, or do we also need to make per-appid (no rand) tmps an option?
<longsleep> Chipaca: it should be similar to SNAP_APP_DATA_PATH but on tmp
<longsleep> Chipaca: or on run - does not really matter
<ogra_> yeah, you want run
<ogra_> being a tmpfs by default so you have guarantees that it is clean on boot etc
<ted> Generally per-appid isn't as useful as per-package
<ogra_> (and dont need to clean up etc)
<ted> You could have, for instance, multiple binaries that wanted access to the same data.
<Chipaca> ted: yes! i meant per package id
<Chipaca> in nearly all of the above :)
<Chipaca> I think the random bit was added to be careful about different forks
<Chipaca> but i think those are now not going to happen?
<Chipaca> in which case we could do away with it and this would just work
<Chipaca> ie it's not an incompatible change
<ted> I think that is an individual snap's responsibility, they own their own run/temp/etc. directories.
<ted> If they don't want binaries to share, they can do that.
<Chipaca> ted: yeap
<Chipaca> so, two bugs: XDG_RUNTIME_DIR, and derand tmp
<longsleep> Chipaca: works fine when i use SOCKET=$SNAP_APP_DATA_PATH/dotstar_socket
<Chipaca> longsleep: huzzah
<longsleep> Are there any thoughts on adding zram to snappy?
<Chipaca> longsleep: sounds like a per-gadget thing?
<longsleep> Chipaca: maybe yes - though i would consider it useful for everyone.
<elopio> Chipaca: could you comment on this bug what's the status and what's missing? https://bugs.launchpad.net/snappy/+bug/1473838
<ubottu> Launchpad bug 1473838 in Snappy "can't ssh into latest snappy rolling edge" [Undecided,New]
<Chipaca> elopio: the thing that should fix it got merged at r618
<Chipaca> elopio: it seems we are not shipping trunk?
<Chipaca> elopio: you should have a /lib/systemd/system/snappy-wait4network.service
<Chipaca> elopio: and it's not there yet
<elopio> Chipaca: hum, right, I don't have that file.
<elopio> where's sergio? ogra_: do you know why rolling doesn't have snappy from trunk?
<Chipaca> sergio's network seems to be having a bad day
<Chipaca> <elopio> where's sergio? ogra_: do you know why rolling doesn't have snappy from trunk?
<Chipaca> sergiusens: ^
<sergiusens> Chipaca: I haven't been to the last 2 sprints!
<Chipaca> sergiusens: but you do icky things, like talking with people
<sergiusens> elopio: Chipaca I'm here, and because is fails to build, mvo has a branch but didn't create an MP last I checked.
<sergiusens> Chipaca: not lately I don't
<sergiusens> Chipaca: I've just catched up with what snapcraft is, it's lifecycle and what not
<Chipaca> sergiusens: that's not going to get you out of being blamed for it all, you know that
<elopio> sergiusens: this one? http://bazaar.launchpad.net/~mvo/snappy/snappy-fix-ftbfs7/revision/629
 * Chipaca starts an indiegogo campaign to upgrade sergiusens's network stability to ogra's, and ogra's network speed to sergiusens'
<longsleep> no commas in service description?? services description field 'Description' contains illegal 'Small, powerful, scalable web/proxy server' (legal: '^[A-Za-z0-9/. _#:-]*$')
<Chipaca> longsleep: yeah
<Chipaca> longsleep: i'm not sure where the restriction comes form right now. Offhand i would've said "systemd requires it", but it doesn't
<lool> sergiusens: mentioned to lool: you mean how to set sysctl from kernel/platforn snaps?
<lool> sergiusens: to give a bit of context, I was contributing my experience of what I saw at a customer's site as to make sure these use cases got covered somehow; you added yours, that's great; we have NOT done any design of the kernel snap/platform snap right now, I guess the closest is just mapping device tarball / gadget snap to whatever we want
<lool> sergiusens: we did discuss updated boot layout, so that will influence the kernel/platform snaps
<lool> also, we are trying to get a bit away from bootloader
<lool> not sure how much we will manage, but a bit
<lool> longsleep, ogra_:this smc thing (this is why my rpi is dropping packets!): could we fix this in the kernel properly?
<lool> longsleep, ogra_: like a blacklist / hardware db in the kernel for that specific smc chip on this specific platform
<lool> longsleep, ogra_: if that's possible, then I think ppisati would help us deliver a working one
<lool> we could even hardcode it in a kernel specific to the rpi2 IMO, but that's not as nice as it would never go upstream
<Chipaca> longsleep: we're passing all of a service's strings through the same checker, hence that error. bug 1484982.
<ubottu> bug 1484982 in Snappy "service description whitelist unnecessarily strict" [Undecided,New] https://launchpad.net/bugs/1484982
<lool> ppisati: ^ see rpi smc discussion above  :-)
<longsleep> lool: well you can change things in the kernel only per driver right. But drivers might require different settings for a more exact hardware match while the driver might be a generic one
<lool> longsleep: yup; I just don't know whether the rpi2 smc chip can be told apart from the other ones
<lool> longsleep: like, it's a different device id somewhere, or it shows up with this or that registers set to this etc.
<sergiusens> lool: away from the bootloader, like using our own chainloaded one (like I did when experimenting) or away completely
<sergiusens> ?
<longsleep> lool: yes - while i do not know so much about this particular problem for rpi, i know that for the odroid once wants to set plenty of kernel variables. Those are specific to that exact platform and will be very hard to implement in the kernel as defaults or something.
<lool> sergiusens: more like chainloading and knowing as little as possible about the first one
<longsleep> lool: for example binding interrupts to CPU's and such stuff
<lool> longsleep: I see; we could shove these on the kernel cmdline though?
<longsleep> lool: here are some examples from the odroid: http://paste.ubuntu.com/12079772/
<sergiusens> lool: well, that's what I did ;-) (using grub to multiboot to grub)
<longsleep> lool: i do not know if this can be set on kernel cmdline
<lool> sergiusens: I was mainly interested in killing the ARM variability TBH
<lool> sergiusens: the x86 case is simlper
<sergiusens> lool: right, u-boot->grub ;-)
<lool> sergiusens: the main reason this came up again is with the boot layout updates and squashfs and how bootloaders vary between platforms
<lool> sergiusens: yup
<sergiusens> was next in the list of things to do
<lool> sergiusens: totally on the same page  :-)
<longsleep> lool: and there is even more general stuff like http://paste.ubuntu.com/12079784/ which cannot be changed as defaults in kernel
<longsleep> lool: i am pretty sure the rpi2 and other platforms require similar settings to get optimal performance
<lool> longsleep: so I'm not super hot on the odroid stuff; it seems to be work load specific tweaking rather than device enablement
<ogra_> lool, well, thats a question to ppisati
<longsleep> lool: yes and no - without these settings the device does not work properly - even dhcp might fail
<ogra_> you want the vm.min_free_kbytes have a bigger default
<lool> longsleep: this is very generic stuff; we need a way for end devices to set these for this or that use case, but it's not platform enablement
<longsleep> lool: yes technically it is not platform enablement, but some platforms require these settings to work properly
<ogra_> lool, blacklisting would mean you cant use the device indeed
<lool> it would fit an admin use case or a gadget / platform use case when building a specific product (like a media center) but not the rpi or odroid enablement
<lool> longsleep: ack; totally get what you mean; makes sense
<lool> longsleep: it's totally in line with the use cases I brought back from a customer
<lool> we need a facility for these
<longsleep> lool: ok great - right now i add all this stuff into initrd to have it as early as possible so there are no problems with DHCP
<ogra_> well, editing the initred is rather bad
<longsleep> lool: so please consider to make it possible to have per platform hooks in initrd.
<ogra_> sergiusens is working on having the modules outside of the initrd and loop mounted from an img file
<ogra_> i suppose we could provide something similar for platform hooks
<ogra_> without having to change the initrd binary
<lool> longsleep: yeah initrd is interesting; actually I was thinking of some early boot hook instead, but initrd might be needed for some stuff
<lool> it's kind of hard cause we deliver the initrd and we don't generate it on the fly
<ogra_> lool, that is fine, all the stuf sergio was working on the last weeks relates to this
<ogra_> ... single partition setup for all readonly bits, loop mounted modules ... potentially allwing other loop mounted bits etc
<ppisati> lool: ok, i see you pinging but i can't find the conversation
<ogra_> ppisati, the famous revival of bug 664477 on the rpi
<ubottu> bug 664477 in Linaro Linux "System hangs due to cascade of smsc95xx errors " [Medium,Fix released] https://launchpad.net/bugs/664477
<ogra_> ppisati, can we patch the default for vm.min_free_kbytes in your build ?
<ppisati> ogra_: k, i'll do
<ogra_> thx
<ppisati> ogra_: i'm ats the snappy sprint
<ogra_> yeah, i know :)
<ppisati> ogra_: as soon as i ends, i'll push a fix
 * ppisati sets a bookmark
<ogra_> not urgent
<ogra_> i'll only need it for the next stable release anyway ... thats still a few weeks away
<ppisati> ogra_: marked
<ogra_> :)
<ppisati> ogra_: and i'll probably do some more digging
<ppisati> ogra_: to find the root
<ogra_> well, it is the turbo mode of the HW
<ppisati> ogra_: after one week of yaml/schemas/stores/etc i NEED some kernel panics
<ogra_> iirc we dug into that ... you either disable that and it uses less ram or you keep it on and need to bump the minimal ram
<ogra_> heh, i can try to produce some for you
<ppisati> ogra_: i'll probably start to package a 4.2 kernel next week
<ppisati> ogra_: dunno, i cn push both so you can play with both
<ogra_> longsleep, is there a user limit in spreed-webrtc (and if so, is there a way to override that)
<longsleep> ogra_: there is no limit except your bandwidth and the clients performance
<longsleep> ogra_: well there is a conference size limit of 10000 hard coded in the server :)
 * longsleep just have found an issue with the way he uses snapcraft :/
<longsleep> problem is that i pull in armhf debs and run snapcraft on x86_64, snapcraft creates wrappers for stuff with x86_64-linux-gnu :(
<fgimenez> nice weekend everyone o/
<longsleep> if someone needs it, `DEB_BUILD_MULTIARCH=arm-linux-gnueabihf snapcraft ...` does the trick to create wrappers for armhf
<kyrofa> sergiusens, ping
<noise][> anyone here successful in getting onewire working w/the latest rpi2 image? I'm trying to follow the instructions from ogra_ about dtoverlay in the ML post from last week, but not having any luck.
<sergiusens> Chipaca: https://code.launchpad.net/~sergiusens/snapcraft/go-golang-go/+merge/268138
<ali1234> is it possible to buld my own snappy core image?
<beuno> ali1234, sure it is. You won't get updates, as they are applied through binary diffs
<ali1234> beuno: that's okay. how do i do it?
<ali1234> also, how do i generate my own binary diff updates?
<beuno> ali1234, I'd ask on the mailing list, I don't really know offhand
<ali1234> i don't need a step by step guide... i just need to know where to start
<ali1234> so i build a snappy image by pointing ubuntu-device-flash at a "channel"
<ali1234> how do i make a channel?
#snappy 2015-08-16
<guest___> owncloud will not work with docker 1.6.2
<guest___> should i pull owncloud from it's repository?
<Mikaela> Will there still be something like unattended-upgrades and apticron with snappy?
<ogra_> guest___, a fixed snap package is being worked on afaik
<ogra_> docker got updated a few days ago, but owncloud didnt yet
<ogra_> Mikaela, yes, indeed ... there is already something semi automatic in place (check snappy config ubuntu-core for the "autopilot" option)
<Mikaela> ok
<guest___> ogra_, oh man this is crazy. it was my cloud storage. i thought i can trust owncloud to always be online and access my data
<guest___> but seems i have to wait for fixing update
<shuduo> guys, i'm interested to reproduce the demo of tomcat-webapp-demo which show in https://insights.ubuntu.com/2015/08/03/java-on-snappy/. may I know where I can download the source code?
#snappy 2016-08-15
<mwhudson> er where can i get a good kernel snap from?
<mwhudson> ah i think maybe my gadget snap was old or something
<zyga> good morning
<mup> PR snapd#1662 closed: client, cmd, daemon, osutil: support --yaml and --sudoer flags for create-user <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1662>
<mup> PR snapd#1655 closed: integration-tests: look for ubuntu-device-flash on PATH before calling sudo <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1655>
<mup> PR snapd#1602 closed: interfaces: add kernel-module interface for module insertion <Reviewed> <Created by arges> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1602>
<ogra_> mvo, i was looking into classic on the weekend ... http://paste.ubuntu.com/23057787/ has  proposed change for classic.create, do you have  branch anywhere =
<ogra_> ?
<ogra_> (probably needs squashfs-tools and coreutils in stage-packages and adjusted paths)
<zyga> mwhudson: hey
<zyga> mwhudson: do you have access to snap-confine packaging on alioth?
<ogra_> mvo, oops, sorry http://paste.ubuntu.com/23057792/ . the first one wasnt the cleaned up version
<mvo> ogra_: thanks! let me create a git branch
<ogra_> the unsquashing takes about half the time vs cp ...
<ogra_> and brings a (despite very ugly) progressbar for free ;)
<mvo> ogra_: its on github as "classic-snap"
<ogra_> cool, i'll prepare a PR
<mvo> ogra_: thanks
<zyga> mwhudson: looking at the QA page it seems that you do, can you please add me to uploaders please
<mwhudson> zyga: sure
<mwhudson> zyga: are you a DM yet?
<zyga> mwhudson: I'd like to convert the package so that it is not a native package
<mwhudson> zyga: what email?
<zyga> mwhudson: no :/
<zyga> mwhudson: please try me@zygoon.pl
<zyga> mwhudson: all I need right now is to have write access to the git repo on alioth
<mwhudson> zyga: i can't grant that :/
<mwhudson> zyga: you need to be in collab-maint, and you need to be a DM for that
<zyga> hmmm
<mwhudson> zyga: however!
<mwhudson> zyga: if you push to github or something i can just merge --ff-only that
<zyga> I did edit some packages in collab-maint AFAIR but perhaps that's my memory being rusty
<mwhudson> zyga: also, it already isn't a native package
<mwhudson> oh
<zyga> mwhudson: that's perfect then
<zyga> mwhudson: oh? it seems to be in the master branch
<mwhudson> but i think i know what you mean
<mwhudson> zyga: master is just a mirror of github.com/snapcore/snap-confine
<zyga> aaaah
<zyga> cool
<mwhudson> zyga: the debian bits are in the 'debian' branch
<zyga> let me run a quick spread test
<zyga> :-)
<zyga> mwhudson: I pushed some updates to https://code.launchpad.net/~snappy-dev/snap-confine/+git/snap-confine/+ref/master
<mwhudson> the debian directory gets deleted in the upstream branch and then re-added in debian
<zyga> mwhudson: spread tests use that for constructing a package
<mwhudson> it would be a good deal less silly to not have the debian dir in master
<zyga> mwhudson: my branch will finally remove the debian directory from upstream packaging
<mwhudson> from my pov, other povs may differ
<zyga> mwhudson: I fully agree
 * mwhudson has not yet internalized how lp git urls work
<zyga> hehe, me neither
<mwhudson> ah, third time lucky
<zyga> if you look at https://git.launchpad.net/snap-confine/tree/debian
<zyga> you will see that there are no patches
<zyga> the debian directory doesn't have the apparmor profile anymore
<zyga> and there are some slight changes to rules
<zyga> but that's all
<zyga> if you could merge that into alioth then my spread tests would work for sid, xenial and yakkety :)
<mwhudson> oh, it's based on an import-dsc
<mwhudson> zyga: uh can you send email about this?
<zyga> mwhudson: sure
<mwhudson> zyga: life is happening here
<zyga> mwhudson: do you directory?
<zyga> :D
<zyga> directly*
<zyga> mwhudson: sent
<mup> PR snapd#1676 opened: interfaces: bluez: add missing mount security snippet case <Created by morphis> <https://github.com/snapcore/snapd/pull/1676>
<mwhudson> zyga: ta
<ogra_> cjwatson, just fYI i havent seen failed promotions anymore (there were some oops timeouts on the weekend though), seems to all work fine, i wonder why the first few days this didnt work
<cjwatson> ogra_: pass; perhaps a store problem of some kind
<cjwatson> ogra_: but good to know it works now, thanks
<ogra_> (but well, it works now, so all is fine)
<mup> PR snapd#1676 closed: interfaces: bluez: add missing mount security snippet case <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1676>
<mwhudson> zyga: i guess snapd will also not be a native package eventually :-)
<zyga> mwhudson: I'd like it not to be native package with the next debian upload
<zyga> mwhudson: if you can merge the changes from launchpad git branch that would be done too
<mwhudson> the debian packaging is in an odd state i think
<mwhudson> i need to poke slangasek some more to get that organized iirc
<zyga> mwhudson: in which way?
<zyga> mwhudson: ok
<zyga> mwhudson: I'm glad to help, I'll apply to be a DM today
<mwhudson> zyga: cool, there is a new process!
<mwhudson> zyga: https://nm.debian.org/wizard/
<zyga> new as in easier? :)
<zyga> ooooh
<mwhudson> hopefully
 * zyga does it right away
<mwhudson> zyga: do you know if there is any significant difference between the snap-confine packages in xenial and yakkety?
<mwhudson> i know some stuff got fixed as part of the SRU, but I *think* that got pushed into debian/yakkety too
<mup> PR snapd#1677 opened: interfaces: bluez: add a few more tests to verify interface connection works <Created by morphis> <Conflict> <https://github.com/snapcore/snapd/pull/1677>
<morphis> zyga: you were a bit too fast with merging that PR :-)
<morphis> was adding a few more tests for that
<zyga> mwhudson: mvo would know, I want to erase those differences
<zyga> mwhudson: I know mvo did cherry picks to ease the SRU process
<zyga> morphis: oh :)
<zyga> morphis: sorry then ;)
<zyga> morphis: merging the 2nd one too
<morphis> zyga: np, I didn't left a note so you couldn't know :-)
<zyga> morphis: reviwed, thank you :-)
<ogra_> mvo, hmm, did you foget to add the files to https://github.com/snapcore/classic-snap ? (i only see meta/snap.yaml)
<mvo> morphis: yeah, what zyga said, I cherry picked bit to make the sru easier for me, but once we use a common packaging I'm happy to drop this
<mvo> ogra_: let me check
<mvo> ogra_: please pull again
<morphis> mvo, zyga: thanks
<ogra_> better :)
<zyga> I'd love to get a quick review on https://github.com/snapcore/snap-confine/pull/102
<mup> PR snap-confine#102: Take upstream version from VERSION file <Created by zyga> <https://github.com/snapcore/snap-confine/pull/102>
<zyga> anyone? :)
<morphis> zyga: done
<zyga> morphis: thank you
<morphis> zyga: np
<zyga> mvo, mwhudson: https://github.com/snapcore/snap-confine/pull/103
<mup> PR snap-confine#103: Use downstream packaging in spread tests <Created by zyga> <https://github.com/snapcore/snap-confine/pull/103>
<zyga> and http://nm.debian.org/person/zyga
<morphis> sergiusens: can it be that the packaging logic in snapcraft doesn't include results of the organize statement?
<dragly> Is it possible to add use a ppa for a snap's packages?
<morphis> sergiusens: see https://paste.ubuntu.com/23058108/
<Sogator> I am not sure if this is the right place to ask but: Will the ubuntu store/snap store gain a functionality that shows if a snap package is made by the program's developer? Like, I wouldn't trust a "financial transaction" snap by "givemonies".
<zyga> Sogator: yes, I believe this is in the roadmap somewhere
<zyga> Sogator: there will be more details availble about particual developer
<jacekn> which part of the installation process is responsible for creating $SNAP_USER_DATA directory? I noticed that whem my snap tries to start /root/snap/<snap-name>/x5/ does not exist and it causes problems
<mvo> ogra_: need help with that PR? I can merge your pastebin directly if that helps
<zyga> jacekn: that'd be snap-confine in the current SRU in ubuntu, later on it will be snapd itself
<zyga> jacekn: I believe the problem you are reporting is fixed in proposed now
<ogra_> mvo, well, i'm heavily hit by the /dev/ptmx bug currently ... hard to test it that way
<morphis> mvo: I am wondering why I don't see my spread test executed in https://travis-ci.org/snapcore/snapd/jobs/152356995
<ogra_> mvo, so i'm currently poking around in bin/shell ... https://github.com/ogra1/classic-snap
<zyga> ogra_: is this fixed by https://github.com/snapcore/snap-confine/commit/6cdff0d4f5c1cdd0d09a0079e8b8381956eec364 ?
<ogra_> zyga, is that in any package yet ?
<mvo> ogra_: aha, ok. fwiw, I think its ok to use the coreutil and squashfs tools from the core not sure why we need those in stage packages
<mvo> morphis: looking
<ogra_> mvo, well, if we ever run confined ....
<zyga> ogra_: I don't know; mvo did you cherry pick that fix from master?
<mvo> zyga: what fix?
<ogra_> https://github.com/snapcore/snap-confine/commit/6cdff0d4f5c1cdd0d09a0079e8b8381956eec364
<ogra_> how do i apply that manually if it isnt landed yet ?
<mvo> ogra_: I don't think so
<mvo> ogra_: yeah, you will have to manually get it
<mvo> ogra_: hm, when we add the confinement profile we can just include unsquashfs in there, that seems to be ok, I don't see the benefit of adding the binary into the snap
<mvo> ogra_: if its critical I can prepare a new SRU with that (its another regression?)
<ogra_> mvo, well, i'lll remove the stage-packages again (i just found it cleaner to ship our own ... but in the end it might not make any difference)
<mvo> morphis: the file  tests/main/interfaces-bluez/spread.yaml  has to be  tests/main/interfaces-bluez/task.yaml
<morphis> mvo: ah
<mvo> ogra_: thanks, I think its fine to use the system ones, this is so low level there shouldn't be any practial difference
<ogra_> i'll revert the branch then
<mup> PR snapd#1678 opened: asserts: export DecodePublicKey <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1678>
<mvo> ogra_: thanks!
<ogra_> hmm, whats the apparmor_parser line i need to re-gen the snap-confine profiile ?
<zyga> timothy: hey, I've almost removed debian packaging of snap-confine
<ogra_> (i hope bind mounting works, i cant write to /etc/apparmor.d/
<ogra_> )
<zyga> ogra_: apparmor_parser -r /etc/apparmor.d/the-file-there
<ogra_> thx
<zyga> timothy: please have a look at this https://github.com/snapcore/snap-confine/pull/103
<mup> PR snap-confine#103: Use downstream packaging in spread tests <Created by zyga> <https://github.com/snapcore/snap-confine/pull/103>
<ogra_> (classic)ubuntu@pi2:~$ cat create
<ogra_> cat: standard output: Permission denied
<ogra_> (classic)ubuntu@pi2:~$ sudo ls
<ogra_> sudo: no tty present and no askpass program specified
<ogra_> (classic)ubuntu@pi2:~$
<ogra_> nope, no change
<zyga> timothy: one thing you can see there is that it combines upstream source tarball with downstram packaging
<zyga> ogra_: is /dev/pmtx mounted?
<ogra_> you mean /dev/pts :)
<zyga> timothy: can you please point me to the location of arch packaging for snap-confine; I recalled you said it was in SVN somewhere
<zyga> mmm, maybe, my tty subsystem know-how is rusty
 * zyga checks
<zyga> ogra_: how about /dev/pts/ptmx
<ogra_> (classic)ubuntu@pi2:~$ mount|grep pts
<ogra_> devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=666,ptmxmode=666)
<ogra_> (classic)ubuntu@pi2:~$ ls /dev/pts/
<ogra_> ptmx
<zyga> that's okay
<zyga> hmmmm
<ogra_> seems that systemd-run somehow removes /dev/pts/0
<zyga> I don't know
<zyga> removes?
<zyga> no, wait, each snap-confine started app gets private /dev/pts
<jacekn> zyga: ack, thanks
<zyga> perhaps that's the actual problem?
<ogra_> zyga, well, we are running in devmode for classic
<ogra_> does that still apply ?
<ogra_> (i would guess snap-confine is completely suppressed in devmode)
<zyga> ogra_: NO
<zyga> no :_)
<ogra_> aha, so it isnt confinement at all
<zyga> ogra_: in fact, snap confine doesn't care about devmode at all, snapd does
<zyga> ogra_: snap-confine does more than just confinement: http://www.zygoon.pl/2016/08/snap-execution-environment.html
<zyga> ogra_: one of the thing it does is sets up a private /dev/pts for your
<zyga> your application process
<zyga> perhaps for classic that is not desired
<ogra_> and that has been deeply tested in alll-snap envs i guess ? :P
<zyga> I think that now, with the mount profile support, we could have snapd *not* generate that for classic but do so for everyone else
<zyga> ogra_: yes
<zyga> ogra_: this code applies both on classic and in all snap
<jacekn> zyga: also: https://bugs.launchpad.net/snapcraft/+bug/1613268
<mup> Bug #1613268: SNAP_USER_DATA is not created automatically <Snapcraft:New> <https://launchpad.net/bugs/1613268>
<ogra_> how ? we didnt have images til last week :P
<ogra_> i recognize it applies to both, but should it behave the same on both is my question ... and has it been tested with a majorly readonly root
<ogra_> (and has t been tesetd with systemd-run ... which classic uses to spawn the chroot)
<ogra_> i have the feelling there are some bits clashing here
<zyga> ogra_: this code was unchanged for ages
<ogra_> zyga, but since when do we use snap-confine in all-snap images ?
<ogra_> i'm pretty sure we didnt use it with the last ones (which was about two months ago)
<ogra_> and new images only exist since end of last week
<jdstrand> ogra_: hey, so, pc-kernel, pi2-kernel and dragonboard-kernel?
<ogra_> jdstrand, yes please
<jdstrand> ogra_: any gadget snaps?
<ogra_> jdstrand, nah, they change so rarely, i dont think we need them right now ... mvo ?
<ogra_> ubuntu@dragonboard:~$ sudo ls -l /tmp/*classic* |wc -l
<ogra_> 115
<ogra_> URGH
<ogra_> !
<ogra_> it never cleans up ?
<zyga> ogra_: nope
<ogra_> (snap-confine that is)
<zyga> ogra_: it's a known issue
<zyga> ogra_: (since uubntu-core-launcher days)
<ogra_> ah, so it will ... at some point
<ogra_> that fine then
<zyga> ogra_: I'd like to fix it but it's not trvial (or I didn't find a trivial way to fix it yet)
<ogra_> yeah, i thought switching to snap-confine would fix that already
<zyga> ogra_: I have an idea with vfork but I didnt' explore it yet
<zyga> ogra_: the switch was just a rename
<zyga> ogra_: and evolutionary changes since
<ogra_> heh
<zyga> ogra_: it wasn't a rewrite of anything
<zyga> ogra_: the tmp directories you're seeing are all empty, correct/
<ogra_> yep
<ogra_> just wasting inodes
<ogra_> (just makes debugging really hard (i.e. finding the right one) since there are so many)
<mup> PR snapd#1677 closed: interfaces: bluez: add a few more tests to verify interface connection works <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1677>
<joc_> fgimenez: ping
<zyga> ogra_: that's good, I'll try my idea when snap-confine is out of SRU pipe
<ogra_> zyga, in any case the ptmx change doesnt seem to have any effect
<fgimenez> joc_, hey :)
<zyga> ogra_: can you rebuild snap-confine and change it in your test env easily?
<ogra_> i dont get a tty and no /dev/pts/0
<ogra_> no, not easily
<zyga> ogra_: I'd like to check something about the pts error you are seeing
<zyga> ogra_: gah, too bad
 * zyga would love a snapd.snap with just a handful of executables
<joc_> fgimenez: hi, i noticed you had a PR open for spread tests for serial-port interface
<ogra_> i'd have to build the package, push it to the snappy-image ppa, rebuild the image etc
<cjwatson> Are there any examples of CLI anywhere in snapd that use a subcommand pattern?  E.g. snap foo bar --options, snap foo baz --options, etc.
<mvo> ogra_: fwiw, I did a quick test with classic on amd64 and it seems to be working for me, what kind of failure do you see?
<ogra_> mvo, cat not working, sudo not works
<cjwatson> I guess you might call that subsubcommand
<ogra_> *working
<joc_> fgimenez: i have one open that adds extra functionality and changes the way it works a bit so can imagine they might break one another
<mvo> ogra_: works for me
<ogra_> mvo, on arm ?
<mvo> ogra_: not on arm, interessting that this is arm specific, I can try tthat in a bit
<ogra_> would be good ...
<fgimenez> joc_, great to know thanks! i can retarget it to your branch so that it lands with the test added (ideal case :) which is your branch?
<cjwatson> Like "lxc image ..."
<ogra_> let me re-set my pi2 and try with the classic from the store ...
<ogra_> cjwatson, like "snap install --devmore foobar" ?
<zyga> ogra_: so specifically sudo fails?
<joc_> fgimenez: sounds good although i think i still need some reviews, https://github.com/snapcore/snapd/pull/1669
<mup> PR snapd#1669: interface: add usb device support to serial-port <Created by jocave> <https://github.com/snapcore/snapd/pull/1669>
<ogra_> zyga, welll, there is no /dev/pts/0  ... so no tty ...
<cjwatson> ogra_: Not really, there are no subcommands of "snap install"
<zyga> ogra_: please report a bug on snap-confine on launchpad, I'll take care of it
<zyga> ogra_: I can reproduce that anywhere
<cjwatson> ogra_: I mean like "lxc image list" vs. "lxc list"
<cjwatson> ogra_: Where "lxc image" is itself a thing that dispatches to its own subcommands
<ogra_> cjwatson, ah, i dont think snappd has any "multi word" commands
<ogra_> i thought you meant options
<ogra_> only toplevel with options afaik
<zyga> ogra_: snapd doesn't care
<zyga> ogra_: snap for bzr should just fork
<zyga> :D
<fgimenez> joc_, cool thanks i'll propose it shortly, if it needs further changes after merging just ping me, we can work together to keep the test up to date with the functionallity
<jdstrand> roadmr: hi! the possible review tools update is a reality in r709 :)
<roadmr> jdstrand: cool! I'll put that in the pipeline
 * ogra_ sighs ... classic.create on the pi2 takes ages ...
<joc_> fgimenez: great :)
<cjwatson> ogra_: Looks like go-flags supports subcommands, so it looks not too hard to do at least
<ogra_> (using the classic from the store)
<jdstrand> roadmr: thank you :)
<ogra_> cjwatson, i think we use subcommands in ubuntu-device-flash (source is goget-ubuntu-touch)
<ogra_> multiple actually
<mup> PR snapd#1605 closed: asserts: introduce support for assertions with no authority, implement serial-request <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1605>
<jdstrand> ahoneybun: hey, you pinged me about pithos-- sorry I'm not familiar with pithos. it seems like 'self.player' somehow didn't get initialized correctly. Did you come to me because there was a security denial?
<cjwatson> ogra_: Just the top-level set of commands, I think, which is the same level of nesting as snap.  Never mind, I'll figure something out
<ogra_> mvo, ok, i verified again, broken on the pi2 and dragonboard  with the last classic from the store (so definitely not my hackery that broke it, which i feared)
<ogra_> mvo,  the symptoms are:
<ogra_> (classic)ubuntu@pi2:~$ sudo ls
<ogra_> sudo: no tty present and no askpass program specified
<ogra_> (classic)ubuntu@pi2:~$ cat .bashrc
<ogra_> cat: standard output: Permission denied
<zyga> re
<ogra_> and:
<ogra_> (classic)ubuntu@pi2:~$ ls /dev/pts/
<ogra_> ptmx
<ogra_> no /dev/pts/0
<ogra_> (so sudo isnt wrong when complaining about no tty)
<mvo> ogra_: thank you, booting my pi2 now
<ogra_> this is also interesting:
<ogra_> (classic)ubuntu@pi2:~$ ls /dev/std*
<ogra_> ls: cannot access '/dev/stderr': Permission denied
<ogra_> ls: cannot access '/dev/stdin': Permission denied
<ogra_> ls: cannot access '/dev/stdout': Permission denied
<zyga> ogra_: that's interesting
<zyga> ogra_: ls -ld /dev /dev/stderr
<ogra_> (classic)ubuntu@pi2:~$ ls -ld /dev/std*
<ogra_> lrwxrwxrwx 1 root root 15 Jan  1  1970 /dev/stderr -> /proc/self/fd/2
<ogra_> lrwxrwxrwx 1 root root 15 Jan  1  1970 /dev/stdin -> /proc/self/fd/0
<ogra_> lrwxrwxrwx 1 root root 15 Jan  1  1970 /dev/stdout -> /proc/self/fd/1
<ogra_> (classic)ubuntu@pi2:~$ ls -ld /proc/self/fd/*
<ogra_> ls: cannot access '/proc/self/fd/255': No such file or directory
<ogra_> ls: cannot access '/proc/self/fd/3': No such file or directory
<ogra_> lrwx------ 1 ubuntu ubuntu 64 Aug 15 13:40 /proc/self/fd/0 -> /dev/pts/0
<ogra_> lrwx------ 1 ubuntu ubuntu 64 Aug 15 13:40 /proc/self/fd/1 -> /dev/pts/0
<ogra_> lrwx------ 1 ubuntu ubuntu 64 Aug 15 13:40 /proc/self/fd/2 -> /dev/pts/0
<ogra_> (and /dev/pts/0 is missing, like i said above)
<zyga> aaaah
<zyga> it all makes sense
<zyga> ogra_: please report the bug as I said, I think I can at least come up with a hack to confirm my hypothesis, then a proper fix via snapd
<ogra_> ok
<zyga> ogra_: but I worry this might be something we have to ack with jdstrand first
<mvo> ogra_: on my pi2 (fresh image) http://paste.ubuntu.com/23058387/ - what do I need to do to trigger the issue
<zyga> jdstrand: later on when you have time
<ogra_> mvo, hmm
<ogra_> mvo, i upgraded my image to rev 249
<mvo> ogra_: I'm on r249 as well
<ogra_> weird
<mvo> ogra_: via a serial port though, how do you access it?
<ogra_> ssh
 * mvo looks
<ogra_> let me try serial
<jdstrand> ogra_: did you see what docker did to work around this?
<ogra_> mvo,  WOAH !
<ogra_> ubuntu@pi2:~$ sudo classic.shell
<ogra_> (classic)ubuntu@pi2:~$ sudo ls
<ogra_> [sudo] password for ubuntu:
<ogra_> so it is ssh induced somehow
<mvo> ogra_: aha, but I see the same issue with ssh
<mvo> ogra_: thanks, that was the missing piece
<ogra_> any idea what it actualyl is ?
<zyga> hmmm
<mvo> ogra_: yes, there is a open bug
<zyga> wkw
<zyga> lw
<zyga> wow, curious indeed
<jdstrand> you're talking about bug #1611493 correct?
<mup> Bug #1611493: No TTY in snaps. <landscape> <Snappy:Confirmed> <https://launchpad.net/bugs/1611493>
<mvo> jdstrand: yes
<mvo> jdstrand: thats the one
<jdstrand> "The work-around identified there (use "script -qc <cmd> /dev/null") works in snaps too."
<mvo> jdstrand: I wonder if there is something else we can do, I have not looked into this enough yet though to really have an opinion
<jdstrand> https://github.com/lxc/lxc/issues/554#issuecomment-238694912
<jdstrand> "This is a known bug in glibc and @hallyn has send a fix to glibc (https://sourceware.org/ml/libc-alpha/2016-08/msg00307.html). It just needs to be applied."
<zyga> mvo: the page talks about bind mountint /dev/console
<zyga> *mounting
<mvo> jdstrand: oh, sweet
<zyga> as a workaround
<ogra_> jdstrand, well, that nests ttys
<jdstrand> it's a workaround
<ogra_> extremely ugly
<mvo> jdstrand: we can check the fix in our image ppa
<jdstrand> the fix is in glibc aiui
<ogra_> and forces you in classic.shell to log out twice
 * ogra_ tried the script hack already and indeed it works ... 
<jdstrand> I suspect an openpty() would work
<mvo> yeah, I think we want the glibc fix
<jdstrand> but this is an area I'm not super versed in
<ogra_> i still dont get why ssh causes it though
<ogra_> but iit works fine oon native ttys
 * ogra_ has the slight feeling thats not the same as the above bug 
<mvo> ogra_: native are real ttys
<ogra_> oh, ok
<mvo> ogra_: if you look at stdout its pointing to /dev/ttyAMA0
<ogra_> yeah, got it
<mvo> jdstrand: how much will you hate me if I upload a glibc with the fix to our image ppa for testing the fix?
<ogra_> hah
<ogra_> mvo, how much will iinfinity hate you should be the question
<jdstrand> I wouldn't hate that-- it is 'just' the image ppa. might want to get tyhicks' thoughts on this (or another member of the security team who has more experience with ttys). tyhicks, for your reference, mvo wants to apply https://sourceware.org/ml/libc-alpha/2016-08/msg00249.html to glibc to test a fix for bug #1611493
<mup> Bug #1611493: No TTY in snaps. <landscape> <Snappy:Confirmed> <https://launchpad.net/bugs/1611493>
<ogra_> jdstrand, "just" ... the ubuntu-core that creates goes to LTS installs ;)
<ogra_> (once it moved to the stable channel)
<jdstrand> hence the quotes
<mvo> ogra_: the "once ... " caveat is kind of important here ;)
<ogra_> heh, yeah, indeed
<ogra_> well, long term stable should not use PPAs at alll
<ogra_> thats at least my plan
<mvo> happy to hold the horses for now, but I'm keen to get this fixed, we hit it in other contextes too
<ogra_> but there are still many SRUs in the way first
<mvo> +1
<ogra_> (nothing for RTM anyway ... but for GA)
<mvo> I think we are doing well so far and the goal is to push it into our packaging (or upstream) once we verified that it indeed fixes the issue
<jdstrand> tyhicks: if you need me to look at it, I'm happy to, just would need to push this ahead of the other stuff I'm working on
<ogra_> mvo, just go ahead then
<ogra_> mvo, also ... if snap-confine actually wraps classic.shell ... do we actually need any of the bind mounting for sys, proc, dev and devpts in the script ?
<ogra_> sounds like duplication
<ogra_> at least by what zyga said above
<jdstrand> tyhicks: note, this is only for testing in !stable-- it sounds like they would wait on the upstream fix to be applied before pushing to stable (and pursuing an SRU)
<mvo> ogra_: I think we still need it, but feel free to play around and if not, even better, I will be happy if we can drop it
<camako> Can I get more reviews on this one? https://github.com/ubuntu/snappy-playpen/pull/205
<mup> PR ubuntu/snappy-playpen#205: Mesa demos <Created by camako> <https://github.com/ubuntu/snappy-playpen/pull/205>
<mup> PR snapd#1678 closed: asserts: export DecodePublicKey <Created by cjwatson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1678>
<mup> PR snapd#1460 closed: interfaces: mpris updates (fix unconfined introspection, add name attribute) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1460>
 * ogra_ sighs ... i somehow messed up my github setup and cant make a PR 
<mup> PR snapd#1673 closed: partition: Revert "clear snap_try_{kernel,core} on success" <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1673>
 * ogra_ sighs, i'm going crazy ... 
<ogra_> mvo, i can not make github recognize the switch to unsquashfs :/ it is never shwing up in my PR
 * ogra_ wasted the last hour on that crap :/
<ogra_> ERR !
<ogra_> mvo, when did you merge that in ? i just notice that you seemingly already added my code ...
<ogra_> geez !
<mvo> ogra_: I did? let me check
<ogra_> mvo, yeah ... https://github.com/snapcore/classic-snap/blob/master/bin/create has all my code already
<mvo> ogra_: hm, that was a mistake, yeah, create has the unsquashfs bits in there already
<mvo> ogra_: hm, I can fix that, I would like to have a proper history
<ogra_> and i was thinking i'm going crazy
<mvo> ogra_: give me a minute
<ogra_> (or am to dumb for github (which i am probably anyway ... ))
<mvo> ogra_: embrace it, git is great
<mvo> ogra_: (its really not, bzr has a so much nicer UI, but the world has moved on)
<ogra_> mvo, well, if it does what i want it is okayish :)
<ogra_> but trying to create a PR for something that is already there is kind of not working ... :P
<mvo> ogra_: please try now
<ogra_> i can only view the former PR
<ogra_> i guess i need to delete my fork and re-fork
<ogra_> it whines about "snapcore:master and ogra1:master are entirely different commit histories. "
 * ogra_ starts over 
<mup> PR snapd#1679 opened: debian: add /snap/bin to the secure-path <Created by mvo5> <https://github.com/snapcore/snapd/pull/1679>
<ogra_> mvo, there you go https://github.com/snapcore/classic-snap/pull/2
<mup> PR classic-snap#2: switch to snapcraft.yaml (so we can eventually have launchpad builds for all arches), do not use cp -a but unsquashfs to speed up create <Created by ogra1> <https://github.com/snapcore/classic-snap/pull/2>
<zyga> ogra_: I would recommend using longer commit messages, with newlines, so that tig/git log is easier to parse
<ogra_> zyga, well, i would have used two PRs but i'm at a level of annoyance from github that i just want it gone now
<zyga> ogra_: you can still edit that, just give it a try
<zyga> ogra_: I know tools can be frustrating
<ogra_> zyga, i am wasting nearly 2h already for 5 lines of code, i wont touch that stuff anymore for today, really
<zyga> ogra_: just a friendly note, don't take it personally
<ogra_> LP never frustrated me like that
<ogra_> zyga, i do take it personally, i *know* there is code hidden  in github somwhere that has "if user = ogra1; do annoy()" ... there must be !
<zyga> ogra_: what did you try to do?
<ogra_> :)
<ogra_> zyga, i tried to do a PR of code that was accidentially already merged
<ogra_> and then messed up my branch completely a few times during the attempts
<dragly> zyga: Thanks for all the help earlier with getting qt-based apps working with snap-confine. I now have a heavy Qt application running after installing it with a snap package on a VirtualBox machine. Amazing!
<mup> PR snapd#1672 closed: tests: add serial-port interface spread test <Created by fgimenez> <Closed by fgimenez> <https://github.com/snapcore/snapd/pull/1672>
<zyga> dragly: woot, that's great
<zyga> dragly: what's the app?
<ogra_> zyga, mvo regarding https://github.com/snapcore/snapd/pull/1679 ... you are aware that you potentially enforce a PATH thet the sysadming changed in /etc/sudoers (also, do all distros use the same secure_path ? you might need per-distro files here for other distros)
<mup> PR snapd#1679: debian: add /snap/bin to the secure-path <Created by mvo5> <https://github.com/snapcore/snapd/pull/1679>
 * ogra_ thinks that should rather come from a postinst script that checks the existing secure_path in /etc/sudoers and assembles something from that for /etc/sudoers.d/snapd
<ogra_> (since you completely wipe whatever was in /etc/sudoers by default)
<mvo> ogra_: hm, that is a bit terrible indeed
<ogra_> yeah
<mvo> ogra_: fwiw, I don't postinst will help because the path may be modied in /etc/sudoers after snapd got installed and the assemble magic was run
<ogra_> jdstrand once explaied to me why it would be more terrible to allow /etc/sudoers.d/ snippets to extend secure_path randomly ... but i forgot
<ogra_> mvo, well, at least you would catch that on snapd updates ...
<mvo> ogra_: true
<ogra_> defintely no ideal either
<mvo> ogra_: if we put it low in the numbering, we could suggest that sysadmins use /etc/sudoers.d/99-local for all local overrides, but that is not ideal either (sudoders already has the suggestion to not edit this file)
<ogra_> mvo, yeah ... i guess it isnt very common to change it ... except for the hardcore "hardening" sysarmins that probably only aloow a certain dir in the path or so
<ogra_> *sysadmins
<ogra_> but these guys will whine ...
<dragly> zyga: A molecular dynamics visualization software named Atomify LAMMPS: https://github.com/ComputationalPhysics/atomify-lammps/releases/tag/2.0.2
<zyga> ogra_: I'm aware of per-distro secure path
<zyga> dragly: awesome!
<ogra_> ("i installed snapd and suddenly all my users can access /usr/local via sudo which i prevented !!!")
<zyga> ogra_: I think we have to do something more fine grained there, I didn't give it much though though
<ogra_> zyga, yeah ... the prob is that it isnt designed for fine grained :)
<ogra_> on putrpose apparently
<ogra_> -t
<mvo> ogra_: hm, I don't see much alternatives - either break PATH for everyone when using sudo (what we have now). or break a few people who use sudoers directly even if sudoers explains that this file should not be used like this
<ogra_> mvo, yeah ... go with a low number for now and lets see if anykone screames
<ogra_> -e
<ogra_> i assume we wont convince sudo upstream to make the path extensible/appendable
<mvo> ogra_: I guess the alternative is to make our sudo package include /snap/bin
<ogra_> probably there would be some complex way through pam though
<ogra_> mvo, yeah, thats the other option
<mvo> if we do that the mentioned problem goes away but we will also trigger a conffile prompt for anyone who has customized it. maybe the right punishment ;) for not using sudoers.d
<ogra_> haha
<ogra_> clever move :)
 * zyga mutters something about /usr/lib vs /etc
<mhall119> sergiusens: is there any way to make a cleanbuild lxc container persistent?
<jdstrand> mvo (cc tyhicks): you are adjusting sudo's secure_path via something in /etc/sudoers.d?
<mvo> jdstrand, tyhicks: not yet, but I pushed a PR for it https://github.com/snapcore/snapd/pull/1679
<mup> PR snapd#1679: debian: add /snap/bin to the secure-path <Created by mvo5> <https://github.com/snapcore/snapd/pull/1679>
<mvo> jdstrand, tyhicks: happy to hear alternative ideas how we can have /snap/bin in the PATH when sudo is used
<jdstrand> I don't think I like that
<mvo> jdstrand: having /snap/bin in the sudo path at all?
<mvo> jdstrand: or just this way of adding it?
<jdstrand> because for 12 years people know to look in /etc/sudoers to adjust secure_path if they need to. now they would adjust it only to have it overriden to what is in snapd. they two might go out of sync, etc
<jdstrand> for 15.04 we used ubuntu-core-config to adjust /etc/sudoers to include it last in the path
<jdstrand> the PR also doesn't consider that other distros may not set secure_path or that they may have a different one than Ubuntu
<jdstrand> mvo: as for setting it at all, I'm not thrilled about adding it to root's secure_path, no, but I'm not sure there is a choice. if we are doing it, I think I prefer /etc/sudoers is modified for Ubuntu
<jdstrand> tyhicks: thoughts? ^
<mvo> jdstrand: ok, fair enough, I will paste this into the PR and close it, I'm fine with modifying sudo
<jdstrand> tyhicks: (background, upstream doesn't have support for appending to secure_path)
<mup> PR snapd#1679 closed: debian: add /snap/bin to the secure-path <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1679>
<tyhicks> jdstrand: I agree - modifying /etc/sudoers at the distro level is the better solution since the PR isn't appropriate for other distros
<mhall119> zyga: ping, checking on the status of (A) setting runtime envvars for snaps and (B) the serial-port plug (needed by arduino IDE to run without -devmode)
<tyhicks> jdstrand, mvo: I've been looking at the tty patch for libc - upstream is still discussing the appropriate change and it seems to me that it is still a little early to apply one of the several patches that have been sent to the list
<jdstrand> tyhicks: thanks
<dragly> zyga: Is it possible to install snap-packages without sudo? Or will it be in the future?
<mhall119> dragly: if you use "snap login" you can then install without sudo
<jdstrand> tyhicks: oh, and thanks for that too :)
 * jdstrand wonders if there is an openpty() option that could be done
<dragly> mhall119: Cool! I'll try that.
<tyhicks> they're rapidly iterating on the correct change - I wouldn't be surprised if they settle on something this week
<jdstrand> ah, cool
<tyhicks> there are still open questions and no updated patch for https://sourceware.org/ml/libc-alpha/2016-08/msg00333.html
<dragly> mhall119: That worked flawlessly. Thanks!
<mhall119> happy to help :)
<dobey> snappy doesn't use debsig-verify right?
<kyrofa> dobey, indeed, that was 15.04
<ahoneybun> jdstrand: it's not a security thing I think
<ahoneybun> I added python-dbus to stage and still the same error
<ahoneybun> oh noes soee
<soee> ahoneybun: sup ? :)
<ahoneybun> mhall119: still hanging around?
<ahoneybun> http://pastebin.ubuntu.com/23059037/ | AttributeError: 'NoneType' object has no attribute 'get_bus'
<rtsisyk> hi
<rtsisyk> I'm trying to pack my daemon using snapcraft. I use git source and cmake as the build system. How to add `git describe --long --always` content to a file in the source tree before invoking cmake?
<rtsisyk> snapcraft strips .git folder from the source tree, so my cmake scripts fails to retrieve version for git
<rtsisyk> I need to put `git describe --long --always` result to the source directory in order to build package.
<rtsisyk> any ideas?
<rtsisyk> I failed to find a proper example in snappy-playground
<rtsisyk> is it possible to use existing Debian package to build snappy package?
<mhall119> ahoneybun: yup
<rtsisyk> ahh, there are no tags in clonned git repo! I need `git fetch --tags`.
<gc_snap> Hi! Is it possible to unregister a snap from the ubuntu store?
<mup> PR snapcraft#730 opened: Clarification of make plugin help text <Created by mikemccracken> <https://github.com/snapcore/snapcraft/pull/730>
<ahoneybun> mhall119: worked on any snap with python?
<rtsisyk> https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/sources.py#L164-L186 both cases don't work for me.
<mhall119> ahoneybun: yeah, hello-unity
<mup> PR snapd#1680 opened: overlord/assertstate,daemone: reorg how the assert manager exposes the assertion db and adding to it <Created by pedronis> <https://github.com/snapcore/snapd/pull/1680>
<ahoneybun> mhall119: http://pastebin.ubuntu.com/23059037/
<rtsisyk> I tried to put snapcraft.yml into the source directory of my app, but snapcraft still tries to copy sources to parts/myapp/src using git clone --depth 1
<ahoneybun> any thing from this?
<kyrofa> rtsisyk, I'm not quite sure what you're asking here
<kyrofa> Can I see your YAML?
<ahoneybun> sergiusens: thanks a lot for the telegram update
<rtsisyk> kyrofa: I'm sorry, I found problem in my cmake script, s/${GIT} describe --long HEAD/${GIT} -C ${CMAKE_SOURCE_DIR} describe --long/g.
<rtsisyk> now I can build my binary
<rtsisyk> what is about init scripts?
 * ahoneybun wonders if his issue is from all the "No libraries to exclude this release" lines
<kyrofa> rtsisyk, ah, okay
<kyrofa> ahoneybun, are you running on yak?
<rtsisyk> I have systemd .service file, is it useful for snappy?
<kyrofa> rtsisyk, no, snapd will generate those based on the information you give it
<ahoneybun> I am kyrofa
<kyrofa> ahoneybun, yeah, bad idea
<ahoneybun> well...
<kyrofa> ahoneybun, we recommend running snapcraft on the same distro you're targeting, or slightly older. Newer and you may very well run into libc issues, not to mention the one you're hitting now: there's no core snap based on y
<ahoneybun> well it installed ubuntu-core
<ahoneybun> snaps run fine here
<rtsisyk> @kyrofa: my service file have support for multi-instance and so on.
<nothal> rtsisyk: No such command!
<kyrofa> ahoneybun, sure, but I'm talking about building them
<ahoneybun> if anything I can throw the yaml on my laptop with xenial
<kyrofa> ahoneybun, snapd bundle a lot of dependencies but not all of them. Notably libc
<gc_snap> I'm sorry if this was answered earlier... is it possible to remove a snap from the store (provided I uploaded it, of course)
<mhall119> ahoneybun: are you using the desktop/gtk(2|3) part?
<ahoneybun> desktop/gtk3 after
<ahoneybun> added python3-dbus in stage and built
<ahoneybun> still there
<mhall119> ahoneybun: my guess is you're missing a gstreamer plugin
<mhall119> ahoneybun: see https://github.com/pithos/pithos/blob/master/pithos/pithos.py#L175
<ahoneybun> yaml : http://pastebin.ubuntu.com/23059200/
<mhall119> self.player is None on line 177, which means it's not being set properly on line 175
<ahoneybun> can't find that in packages.ubuntu.com
<mhall119> ahoneybun: try adding rygel-playbin to your stage-packages
<ahoneybun> where did you get that ?
<mhall119> apt-cache search "playbin"
<mhall119> also, apt-cache depends --recurse pithos |grep -i playbin
<ahoneybun> but why that package
<ahoneybun> I need to know
<rtsisyk> where I can find snapcraft.yml example for daemons?
<mhall119> hey, I only have edge and beta available as channels for my app in the store, how do I get stable?
<kyrofa> rtsisyk, please read through this: http://snapcraft.io/create/
<kyrofa> rtsisyk, it'll walk you through apps and daemons
<kyrofa> rtsisyk, but here's another example, one of the snapcraft demos: https://github.com/snapcore/snapcraft/blob/master/demos/shout/snapcraft.yaml
<ahoneybun> same thing
<ahoneybun> mhall119:
<rtsisyk> thanks. My daemon needs a config file provided by user to start...
<powersj> mhall119, does your app run in confinement mode strict?
<mhall119> ahoneybun: in that cause, it could be that gstreamer needs some setting to tell it where to find it
<powersj> or still require devmode? I believe if devmode is required you are limited to beta and edge
<mhall119> powersj: devmode, is that the cause?
<mhall119> something should tell the developer this, it's not obvious
<powersj> mhall119, yeah see 2nd paragraph under Developer mode here: http://snapcraft.io/docs/core/usage
<mhall119> I meant something in the sore
<mhall119> store
<renato__> guys, Hey I am creating a EDS snap it is working nice as normal app. But I changed the service to run as daemon and the apps are not staring
<renato__> this is the full log, http://paste.ubuntu.com/23059185/
<renato__> sergiusens, ^^^ any idea about that?
<mhall119> ok, it's on the upload form too, maybe I'm just being thick
<kyrofa> mhall119, yeah it does, right next the channel selection dialog
<kyrofa> Ah, yeah you saw that, sorry
<mhall119> kyrofa: it doesn't say it here though: https://myapps.developer.ubuntu.com/dev/click-apps/5719/upload/19776/edit/
<mhall119> which is where I was looking and thinking "where is stable?"
<kyrofa> mhall119, ah, then yes, I agree!
<kyrofa> mhall119, mention it to the store folks
<kyrofa> renato__, to make sure I understand, you were previously able to run these things as apps, but now that they're services, they don't work?
<kyrofa> renato__, were you running the apps with sudo, or as a normal user?
<wililupy> in my snapcraft.yaml, if I need a specific branch from a git, how would I do that?
<mhall119> kyrofa: who are the store folks these days?
<mhall119> it used to be I just complained to beuno a lot
<mhall119> :)
<kyrofa> mhall119, nessita is always my go-to. She knows all
<nessita> heh
<kyrofa> She can at least get you to where you need to go :)
<nessita> mhall119, hi! how can I help?
<nessita> kyrofa, and thanks for all those nice words!
<renato__> kyrofa, yes it was running nice as normal snaps  apps.
<mhall119> nessita: can we get the text about devmode limiting channels from the upload form added also to https://myapps.developer.ubuntu.com/dev/click-apps/5719/upload/19776/edit/
<renato__> kyrofa, yes I am runinng with root using my dev version of snap
<nessita> mhall119, would you please create a bug so we can track the request there?
<mhall119> nessita: lp:software-center-agent still?
<kyrofa> renato__, like, you `sudo su -` then run the apps?
<kyrofa> renato__, or you ran them as a normal, unprivileged user?
<nessita> mhall119, yes, thank you
<renato__> kyrofa, I run the app without sudo. But install it with sudo
<rtsisyk> can i use svg for "icon:"?
<kyrofa> Of course
<kyrofa> rtsisyk, you can! svg or png
<rtsisyk> great!
<rtsisyk> how to check icon for packaged snap file?
<kyrofa> renato__, okay. And it seems you're using SNAP_USER_DATA?
<kyrofa> rtsisyk, I don't quite understand what you're asking
<renato__> kyrofa, I am not sure what this SNAP_USER_DATA is :D
<kyrofa> renato__, ah, then just $HOME perhaps
<renato__> kyrofa, this is my snapcraft file: http://paste.ubuntu.com/23059245/
<kyrofa> renato__, a big difference between apps and services is that apps run as whoever ran them, and services run as root
<renato__> kyrofa, humm this can be the problem, I need the service running on user session
<kyrofa> Which means the user-specific data directory (SNAP_USER_DATA) is in /root/snap/<snap>/<revision>
<kyrofa> Ah indeed
<renato__> kyrofa, I need to connect with dbus session
<kyrofa> renato__, snapd doesn't currently have a concept of user services
<renato__> kyrofa, ok this is the problem then
<kyrofa> renato__, definitely
<rtsisyk> DEPRECATED: 'license' defined in snapcraft.yaml
<kyrofa> niemeyer, I seem to remember a conversation about user services. Did anything ever come of that conversation?
<mhall119> kyrofa: nessita: how can I publish both an amd64 and i386 snap?
<rtsisyk> https://myapps.developer.ubuntu.com/dev/click-apps/register-name-dispute/  This page does not exist. Well, obviously this page exists. But the page you requested does not exist. This page is just here to tell you that the page you requested does not exist.
<rtsisyk> I can't register proper name
<mup> PR snapd#1667 closed: many: implement snapctl command <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1667>
<mup> Bug #1613420 opened: no way to run daemons on user session  <Snappy:New> <https://launchpad.net/bugs/1613420>
<niemeyer> kyrofa: No, not much
<mup> PR snapcraft#731 opened: Factor parts config into snapcraft/internal/parts.py <Created by josepht> <https://github.com/snapcore/snapcraft/pull/731>
<dobey> what's the equivalent in snap, of "click info $package" ?
<kgunn> kyrofa: ping
<kyrofa> kgunn, pong, how are you?
<kgunn> kyrofa: good man how are you
<kyrofa> kgunn, I'm doing well!
<kgunn> kyrofa: hey i was wondering, if i wanna snap up some stuff (say..unity8) and i don't really need to build it...just pull what's in archive
<kgunn> can i just leave nil
<kgunn> (nil plugin)
<kyrofa> kgunn, just using stage-packages?
<kgunn> and then list all the pkgs in stage?
<kgunn> yeah..that's the thinking
<kyrofa> kgunn, sure, but there are limitations there, e.g. postinst scripts aren't run etc.
<kgunn> kyrofa: oh yeah...i know i'll have to add a wrapper scriptfor launch
<kyrofa> kgunn, packages in the archive may also be looking for files in e.g. /etc/ that are now in $SNAP/etc/, and so on
<kgunn> ah, but yeah, that's a good point
<kyrofa> kgunn, but yeah, as long as you're okay with those debs essentially being tar files (i.e. they're just unpacked into the snap), then you should be good
<kgunn> kyrofa: k i'll prolly just give it a go and deal with pathing weirdness as and when i hit it
<kyrofa> Yeah it's an easy path to try anyway as long as the packages don't make heavy use of postinst
<kyrofa> kgunn, e.g. don't even try doing apache
<kgunn> hehe
<kgunn> kyrofa: sounds like experience ?
<kyrofa> :P
<kyrofa> Yeah that was my initial foray into snapping. Should have started with something easier
<kgunn> lol
<kgunn> i figure u8 will be a mess
<kgunn> should be fun
<kyrofa> Yeah you'll be even more familiar with it than you are now!
<kgunn> kyrofa: thanks for the advice...dropping for a bit
<kyrofa> kgunn, any time, have a good one!
<mup> PR snapd#1681 opened: tests: test `snap run --hook` using in-tree snap-exec <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1681>
#snappy 2016-08-16
<mup> PR snapd#1682 opened: interfaces/hardware-observe.go: re-add /run/udev/data <Created by cwayne18> <https://github.com/snapcore/snapd/pull/1682>
<mup> PR snapd#1663 closed: osutil: fix create-user on classic systems <Created by jaymell> <Closed by jaymell> <https://github.com/snapcore/snapd/pull/1663>
<zyga> good morning
<ljp> so only the gadget or os snap is allowed to use gpio?
<pcoca> Hi everyone!
<pcoca> I am getting this Apparmor issue:
<pcoca> Aug 15 23:44:25 haswell16 kernel: [18612.885097] audit: type=1400 audit(1471329865.428:185): apparmor="DENIED" operation="create" profile="snap.sensortag.sensortag" pid=24904 comm="bluepy-helper" family="bluetooth" sock_type="seqpacket" protocol=0 requested_mask="create" denied_mask="create"
<pcoca> And I am using the  plugs: [bluez] on my snapcraft.yaml
<pcoca> https://github.com/pedrococa/sensortag/blob/master/snapcraft.yaml
<pcoca> Is there any additional interface that I should use?
<lpotter> looks like the mir interface can allow seqpacket
<pcoca> lpotter,  so plugs: [mir, bluez] would do the trick?
<pcoca> lpotter, I am afraid it is not working.
<zyga> lpotter: hey
<zyga> lpotter: let me check if seqpacket is allowed
<pcoca> zyga, lpotter, is used by a BTLE device
<pcoca> zyga, lpotter, otherwise I got the apparmor issue and the snap failed with an error of BTLE addresses.
<zyga> it seems not to be
<zyga> essentially the apparmor denail you got above said you cannot create a seqpacket socket, try network-bind as a quick workaround
<zyga> pstolowski: czeÅÄ :)
<pstolowski> zyga, czoÅem!
<zyga> pcoca: let me know if that workaround works for you
<pcoca> zyga, sure, snapping it up now :)
<zyga> :-)
<mup> PR snapd#1683 opened: osutil: fix create-user on classic <Created by jaymell> <https://github.com/snapcore/snapd/pull/1683>
<pcoca> zyga, It does not work :/
<pcoca> I still got the same error with Apparmor
<pcoca> using    plugs: [bluez, network-bind]
<zyga> pcoca: can you please report the bug and give some background on the library/system calls you are using
<zyga> pcoca: please report teh bug on launchpad.net/snappy with snapd-interface tag
<mup> PR snapd#1684 opened: many: drop ubuntu-core-snapd-units package, use release.OnClassic instead <Created by mvo5> <https://github.com/snapcore/snapd/pull/1684>
<pcoca> zyga, here is: https://bugs.launchpad.net/snappy/+bug/1613572
<mup> Bug #1613572:  apparmor denial with sock_type="seqpacket" using a BTLE device <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1613572>
<mup> Bug #1613572 opened:  apparmor denial with sock_type="seqpacket" using a BTLE device <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1613572>
<mup> PR snapd#1685 opened: snap-exec: Fix broken `snap run --shell` and add test <Created by mvo5> <https://github.com/snapcore/snapd/pull/1685>
<zyga> pcoca: I saw, thank you
<zyga> mwhudson: good morning
<zyga> mwhudson: I've applied to be a DM, if you'd like you can consider adding your advocacy for me: https://nm.debian.org/process/74/advocate
<mup> PR snapd#1686 opened: boot: add support for "devmode: {true,false}" in seed.yaml <Created by mvo5> <https://github.com/snapcore/snapd/pull/1686>
<mup> PR snapd#1687 opened: release: Remove "UBUNTU_CODENAME" from the test data <Created by mvo5> <https://github.com/snapcore/snapd/pull/1687>
<mup> Bug #1613609 opened: Can't register name for snap package <Snappy:New> <https://launchpad.net/bugs/1613609>
<rtsisyk> hi. I created my first snappy package: https://github.com/tarantool/tarantool/blob/snappy/snapcraft.yaml How I can register "tarantool" name for it?
<mup> Bug #1613609 changed: Can't register name for snap package <Snapcraft:New> <https://launchpad.net/bugs/1613609>
<ogra_> ogra@anubis:~/datengrab/images/snappy$ /snap/bin/vlc
<ogra_> multiple nvidia drivers detected, this is not supported
<ogra_> bah !
<ogra_> (it isnt really like i need the nvidia drivers for music playback )
<mvo> ogra_: fwiw, I'm testing the fix for the boot problem you noticed on friday right now
<mvo> ogra_: zyga maybe able to help with snap-confine
<ogra_> mvo, awesome, is it in the edge channel already ?
<ogra_> (i can manually update when setting snap_try_kernel)
<mvo> ogra_: not yet, I sideloaded for now to double check that I did not mess up uboot.env but if it boots I will upload
<ogra_> cool, ping me then, i'll do test upgrades without sideloading
<mvo> ogra_: pi2 is published now, please let me know how it goes, I'm updating the dragonboard now
<ogra_> hmpf ... i cant really find the code in vlc that prevents the starting with nvidia drivers ... this is really evil ...
<ogra_> didrocks, is that check in the launcher code ?
<mvo> ogra_: that is snap-confine that shows this message
<ogra_> bah
<didrocks> ogra_: no, it's not in the launcher
<ogra_> on what conditions ?
<ogra_> didrocks, yeah, seems snap-confine
<didrocks> yeah ;)
<ogra_> zyga, on what conditions does snap-confine block executions with nvidia drivers ...
<ogra_> seems it is rather overzealous
<mvo> ogra_: dragonboard is also uploaded, let me know if you notice any issues please
<mup> PR snapd#1687 closed: release: Remove "UBUNTU_CODENAME" from the test data <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1687>
<ogra_> mvo, oh
<ogra_> i got a new gadget too
<mvo> ogra_: the fix is entirely in there
<ogra_> oh
<mvo> ogra_: its also in bzr if you want to double check, once sec, I look for the diff
<ogra_> wow ... seems my pi2 auto upgraded to 254 already
<ogra_> (not rebooted though)
<ogra_> mvo, btw, we need some scriptery in the uboot.env to reboot when it cant load the files
<ogra_> that would have prevebted the hang
<ogra_> *prevented
<ogra_> ok, dragonboard is proper at v3 and ubuntu-core v253
<mvo> ogra_: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/revision/45 and 46
<mvo> ogra_: +1 for magic in uboot
<ogra_> and pi2 at 14 and 254 ...
<ogra_> but both had snap_try_kernel set
<ogra_> i guess i should trigger quickly another ubuntu-core to test without it set
<ogra_> build kicked ...
<ogra_> cjwatson, i see very often timeouts when triggering a snap buikld through the LP UI ... current one is OOPS-a9d5e8c47cb69641674e12dd57721fc9
<ogra_> *build
<ogra_> (the build gets triggered fine, just the reload after triggering does time out)
<cjwatson> ogra_: Thanks.  That one could be fixed with a bit of property caching; please file a bug with the OOPS ID.
<ogra_> against launchpad itself ?
<cjwatson> ogra_: yes
<ogra_> thx
<cjwatson> ogra_: regression in r18036, apparently
<ogra_> aha
<mvo> jaymell: hey, thank a bunch for your nice branch jaymell:createUserOnClassic, really cool that you are working on this! I got a bit carried away while reviewing and created a small tweaks commit https://github.com/mvo5/snappy/commit/52a572a90a3979b37eb7bcda73db1d61cef6b735 - would you mind reviewing and merging into your branch? it addresses the bits that zyga mentioned. I hope you like it and don't mind me doing this, but I was quite excited tha
<mvo> t create-user now works on classic :)
<ogra_> ** Unable to read file /kernel.img **
<ogra_> reading /dtbs/apq8016-sbc.dtb
<ogra_> ** Unable to read file /dtbs/apq8016-sbc.dtb **
<ogra_> reading /initrd.img
<ogra_> ** Unable to read file /initrd.img **
<ogra_> Bad Linux ARM64 Image magic!
<ogra_> =>
<ogra_> mvo, ^^^ :/
<ogra_> (after refresh to the new ubuntu-core that finished a few mins ago)
<mvo> ogra_: hm, dragonboard? if it is not a fresh flash you will need to manually copy uboot.env to /boot/uboot, its not happening automatically iirc (but please double check using md5sum, maybe I misremember)
<mup> PR snapd#1680 closed: overlord/assertstate,daemon: reorg how the assert manager exposes the assertion db and adding to it <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1680>
<dragly> is it possible to have snapcraft put the parts/prime/stage folders in a different place? I'm currently building a project that I have stored inside a Dropbox folder, and this appears to be a Bad Ideaâ¢
<Odd_Bloke> dragly: A temporary workaround might be to use `snapcraft cleanbuild`, which builds inside a lxd container (though this does mean that you can't easily examine each of the stages).
<dragly> Odd_Bloke: thanks, I'll try that out
<mup> PR snapd#1688 opened: interfaces: add fwupd interface <Created by timchen119> <https://github.com/snapcore/snapd/pull/1688>
<ogra_> mvo, well, md5 is moot after one boot attempt since it saves vars during boot ... but let me try
<mvo> ogra_: you could dump the entire text and patebinit and I check
<ogra_> mvo, yeah, the script line differs ...
<mvo> ogra_: meh, ok
 * ogra_ copies manually and transfers all the variables needed
<ogra_> ok, now it works again
<ogra_> same for rpi
<ogra_> so i guess the gadget needs some upgrade hook
<mvo> ogra_: yes, I guess short term I need to create new base images
<ogra_> that too
<ogra_> mvo, triggering a new ubuntu-core build to test with the new gadget in place now
<mvo> ogra_: ta
 * mvo considers lunch
<ogra_> cjwatson, Bug #1613652 (sorry, took a bit)
<mup> Bug #1613652: timeouts when triggering snap builds <Launchpad itself:New> <https://launchpad.net/bugs/1613652>
<cjwatson> ta
<zyga> Son_Goku: hey, I've updated snap-confine and I'll need another golang package before snapd 2.11
<zyga> Son_Goku: I've uploaded everything to people.fedoraproject.org, I'll start working on the paperwork for this
<ogra_> mvo, upgrade works now \o/ ... what i dont get though ... the image should have been built from the edge channel .. but snap refresh always tries to get ubuntu-core from stable, i have to explicitly call "sudo snap refresh ubuntu-core --edge" ... dont we store the default channel in the image config anywhere ?
<Son_Goku> zyga, have you made any progress on selinux support in snap-confine?
<zyga> Son_Goku: https://bugzilla.redhat.com/show_bug.cgi?id=1367407
<zyga> Son_Goku: some, I'm working on toy version of snap-confine that fiddles with libselinux
<Son_Goku> macaroons?!
<zyga> Son_Goku: upstream firefighting is over now, I'm just waiting for reviews and I'll do 1.0.40 release
<zyga> Son_Goku: I'm back to my regular tasks
<zyga> Son_Goku: yeah, part of snapd auth code
<zyga> Son_Goku: (I was surprised that macaroon is not "pasta" but instead is "fancy cookie"
<zyga> Son_Goku: the polish word for "pasta" is makaron
<Son_Goku> oh dear god
<Son_Goku> I feel stupid now
<zyga> Son_Goku: I'd like to make snap-confine apply selinux context/labels/thing to the mounted snaps
<zyga> Son_Goku: haha, why? Did you also think it is about pasta?
<Son_Goku> that, and apparently we should have never importing check
<Son_Goku> it already exists: http://koji.fedoraproject.org/koji/packageinfo?packageID=19283
<zyga> hmmm
<zyga> that's odd
<zyga> I did gofed checks
<zyga> that's good though
<zyga> Son_Goku: wait, that's gopkg.in/check.v1
<zyga> Son_Goku: so there are two packages for the same thing?
<Son_Goku> yep
<Son_Goku> you just added exactly the same package to Fedora
<Son_Goku> http://koji.fedoraproject.org/koji/buildinfo?buildID=785266
<zyga> Son_Goku: I'll email the maintainer, maybe those should be merged
<Son_Goku> yeah
<Son_Goku> it's clearly an accident
<zyga> Son_Goku: yeah, the provides for common name could be a way to find those
<zyga> Son_Goku: golang is still young and packaging guidelines are incomplete and weak, the package I added follows the more strict naming convention
<Son_Goku> yeah
<Son_Goku> well, the biggest problem is because golang is all statically done, there's no easy way to identify everything
<Son_Goku> and apparently the provides didn't even exist on that go-check package until Feb of this year
<Son_Goku> which shows how difficult golang can get
<zyga> yeah, I agree
<zyga> I think upstream import path/common name should be the only way to map packages
<zyga> everything else is wrong
<zyga> including github repo checks (like in this case)
<tdr> Hello, I'm trying to build a snap, but I'm getting this error: "Can't convert 'float' object to str implicitly" anyone know what that means?
<Son_Goku> what I'm surprised about is that gofed didn't catch this
<Son_Goku> or did you never run gofed on snapd itself?
<zyga> Son_Goku: I think I didn't run it on snapd
<zyga> Son_Goku: though at the time the common name import didn't exist
<zyga> Son_Goku: or .... perhaps I didn't use the common name then
<Son_Goku> you probably didn't use the common name
<zyga> Son_Goku: in any case, I'm writing to the maintainer now
<Son_Goku> cool
<Son_Goku> you might want to ask if his version is up to date, and if you can be comaintainer of the package, too
<Son_Goku> you can request the ACLs here: https://admin.fedoraproject.org/pkgdb/package/rpms/golang-gopkg-check/
<zyga> yep, good idea
<zyga> Son_Goku: how have you been?
<Son_Goku> I've been alright
<zyga> Son_Goku: for me the summer is over, it's cold and wet all week
<Son_Goku> haha
<Son_Goku> it's still hot here
<Son_Goku> it's a bit rainy at the moment, but still very hot
<zyga> Son_Goku: it was 10C in the morning today
<Son_Goku> it's 73F / 23C right now
<Son_Goku> the high will be 86F / 30C
<zyga> I really envy you, I sometimes question the logic of moving away from spain *for summer* so that we can spend it in a cold forest in the north
<Son_Goku> haha
<zyga> Son_Goku: sent!
<zyga> Son_Goku: you're on CC
<zyga> Son_Goku: I'll look at snapd 2.11, I need to fix something in systemd units (seems like upstream change)
<zyga> Son_Goku: oh, btw, I'm almost done removing snap-confine debian packaging from the upstream tree, I will be able to run end-to-end integration tests, made against fedora packaging, on each pull request soon
<Son_Goku> cool
<zyga> Son_Goku: https://github.com/snapcore/snap-confine/pull/103/files
<mup> PR snap-confine#103: Use downstream packaging in spread tests <Created by zyga> <https://github.com/snapcore/snap-confine/pull/103>
<Son_Goku> btw, if you wanted to set up some kind of thing to monitor snapd, snap-confine, and its deps in fedora, you can use this: https://apps.fedoraproject.org/mdapi
<zyga> Son_Goku: I support debian and ubuntu, fedora and arch are up next, I just need to land this first
<Son_Goku> it's a RESTful API that emits a JSON form of the RPM XML repodata
<mvo> ogra_: that sounds like a bug, it should store the channel, let me double check that
<zyga> Son_Goku: I have that bookmarked, I need to spend some time on that cross distro monitoring
<zyga> Son_Goku: I'm really glad most of snap-confine firefighting is over and I can pick up stuff form my backlog again
<Son_Goku> both the Debian guy and myself would really like to see the SELinux integration asap :)
<zyga> Son_Goku: it is capped by my capacity to learn selinux and spend time on it; if you know anyone who'd like to hack on this with me that would help a lot
<Son_Goku> did you learn anything from selinux guys at flock that could help?
<zyga> Son_Goku: yes, I asked a lot of questions over lunch
<zyga> Son_Goku: I also got the idea that everything I want to do is doable
<zyga> Son_Goku: but most importantly, we just had a good time and exchanged contacts
<Son_Goku> that's good
 * zyga away for 45 min
<sborovkov> niemeyer: Hi. I saw that you wrote that you published patched version for this bug in your ppa https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1606212 - is it possible to use your ppa?
<mup> Bug #1606212: getpwuid is failing on classic image <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1606212>
<ogra_> mvo, might be related to me manually tinkering with snap_try_kernel before (and according broken boot attempts alongside)
<mvo> ogra_: maybe, smeels like a bug, if you mail me (privately) /var/lib/snapd/state.json I can check if the DB is correct about it
<ogra_> will do
<mvo> ogra_: thanks
<mup> Bug #1613686 opened: Consider allowing access to @{PROC}/@{pid}/limits <Snappy:New> <https://launchpad.net/bugs/1613686>
<mup> PR snapd#1681 closed: tests: test `snap run --hook` using in-tree snap-exec <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapd/pull/1681>
<zyga> Son_Goku: snap-confine updated again
<zyga> Son_Goku: I'd love if you can set the reviewed bit now :)
<Son_Goku> haha
<zyga> Son_Goku: if you want, all the changes are kept in git for easier review too
<zyga> https://github.com/zyga/snapcore-fedora/commits/master
<Son_Goku> :)
<Son_Goku> package approved
<zyga> wooot
<zyga> thank you
<Son_Goku> macaroon is approved too
<Son_Goku> contingent on your fixes
<zyga> yep, I saw; I'm on a call now but I'll continue with this as the next thing
<zyga> Son_Goku: I'll push my selinux hacks today, maybe at least to get some feedback from others
<Son_Goku> cool
<Son_Goku> having something is better than nothing, imo
 * zyga requested snap-confine and the macaroon package in fedora
<zyga> next up: snapd :)
<awe> ogra_, who's responsible for the config of the rpi2-kernel snap?
<ogra_> awe, the config ?
<ogra_> you mean the build configuration ?
<awe> yup
<awe> looks like there aren't any audio devices configured by default
<ogra_> (the snap just uses the linux-raspi2 and linux-image-raspi2 packages from the archive)
<awe> which makes testing pulse rather difficult
<awe> ;D
<ogra_> pfft, excuses :P
<ogra_> ppisati_, ^^^ can we have audio devices on the pi's ?
 * ogra_ has no idea which config options we need though)
 * awe has never toyed with rpi audio before, but the doc says there are two output devices ( HDMI, and headphone out )
 * ppisati_ checks
<jdstrand> morphis: hi! can you look at https://bugs.launchpad.net/snappy/+bug/1613572/comments/2?
<mup> Bug #1613572:  apparmor denial with sock_type="seqpacket" using a BTLE device <snapd-interface> <Snappy:Confirmed> <https://launchpad.net/bugs/1613572>
<jdstrand> morphis: with the addition of bluetooth-control, I'm not sure where to put the fix
<mup> PR snapd#1682 closed: interfaces/hardware-observe.go: re-add /run/udev/data <Created by cwayne18> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1682>
<sborovkov> jamiebennett: ping
<jamiebennett> pong
<sborovkov> jamiebennett: question about this bug - https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1606212 So Manik asked us if we could use what's described in this bug to workaround our issue. From what I read it seems niemeyer has some kind of build with patch for this? Can we use that ppa with the built ubuntu-core? I checked out his user profile and ppa there has last update from 270 weeks ago )
<mup> Bug #1606212: getpwuid is failing on classic image <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1606212>
<jamiebennett> sborovkov: We keep the code on GitHub, let me see if I can find the branch
<jamiebennett> niemeyer: ^
<sborovkov> thanks
<niemeyer> sborovkov: I don't have anything other than what's described there
<niemeyer> sborovkov: The issue mentioned describes why the problem is likely happening, and what the fix is
<sborovkov> niemeyer: so should I write a similar patch for my app like the one you attached for plymouth
<niemeyer> sborovkov: Not clear if this needs to be in your app or in snapd itself
<niemeyer> sborovkov: It might be a file that we're not shipping in /etc that we could ship and would solve all similar issues
<sborovkov> Yes, that's why I asked. I though you patched snapd. And it would be in ubuntu-core
<niemeyer> sborovkov: Someone needs to dig down and test this theory out
<elopio> didrocks: do you want to hangout to get over with this docker hub thing?
<niemeyer> sborovkov: Can you give it a shot?
<sborovkov> niemeyer: but that patch should work, right? I checked /var/snap/ubuntu-core... and nsswitch.conf was present along with libnss files?
<niemeyer> sborovkov: Even if the fix is in ubuntu-core, having someone verify it would be useful
<pcoca> jdstrand, Hi Jamie! Just updated https://bugs.launchpad.net/snappy/+bug/1613572. Is the path different in the classic subsystem? I cannot do the workaround.
<mup> Bug #1613572:  apparmor denial with sock_type="seqpacket" using a BTLE device <snapd-interface> <Snappy:Confirmed> <https://launchpad.net/bugs/1613572>
<sborovkov> niemeyer: I'll test the patch on the side of my app then
<niemeyer> sborovkov: Thanks, please let me know how it goes
<sborovkov> sure
<jdstrand> pcoca: /var/lib/snapd/apparmor/profiles/snap.sensortag.sensortag
<jdstrand> pcoca: I left out 'snapd'
<pcoca> jdstrand,  after the line:
<pcoca> profile "snap.sensortag.sensortag" (attach_disconnected) {
<pcoca> ?
<jdstrand> pcoca: anywhere in between the {}. I typically add workarounds before the final '}'
<pcoca> jdstrand, OK
<jdstrand> Odd_Bloke: you bug 1607710 is not prioritized afaict. if you need it escalated, I suggest talking to jamiebennett
<mup> Bug #1607710: Home directories listed in /etc/passwd should be honoured <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1607710>
<jdstrand> your*
<pcoca> jdstrand, Done it. Thanks Jamie. I got now a different error :/ I just updated the bug info.
<morphis> jdstrand: will have a look
<Odd_Bloke> jamiebennett: Getting https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1607710 fixed would be super-cool, because then we could start snapping up tools we use in Jenkins. :)
<mup> Bug #1607710: Home directories listed in /etc/passwd should be honoured <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1607710>
<jamiebennett> Sounds like zyga may know more on this bug
<jdstrand> morphis: basically I wondering about the intent of the bluez interface-- is that only for talking to bluez now or should it give network bluetooth
<morphis> jdstrand: on the plug side it should only allow dbus api access for bluez
<morphis> all low level BT stuff should go into bluetooth-control
<jdstrand> morphis: ok, so we should add network bluetooth to bluetooth-control
<morphis> yeah
<jdstrand> gotcha, thanks!
<morphis> jdstrand: however its the question if we want to give any app access to that
<morphis> a new build app should definitely go with bluez rather than bluetooth-control
<jdstrand> pcoca: do you have time to iterate here?
<jdstrand> morphis: 'a new build app'?
<morphis> jdstrand: for those building new Apps especially for Ubuntu Core
<jdstrand> morphis: note that bluetooth-control is not auto-connected
<jdstrand> I see what you mean
<jdstrand> as it stands, both bluez and bluetooth-control do not autoconnect
<morphis> jdstrand: especially for bluetooth low energy a lot people tend to use the raw kernel APIs today because bluez had it api just experimental for a long time
<mup> PR snapcraft#715 closed: Add artifacts option to make plugin <Created by jhobbs> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/715>
<jdstrand> that seems to be the case with sensortag
<morphis> so this migh have the potential to conflict with a running bluez and also gets privileged access to the whole bluetooth subsystem
<jdstrand> this may need an architects discussion. we've not had a situation where one interface might conflict with a slot implementation
<mup> Bug #1610292 opened: Snap installed with --devmode can't use sudo <amd64> <apport-bug> <yakkety> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1610292>
<ppisati_> awe: append "dtparam=audio=on" to config.txt and reboot
<awe> thanks ppisati_!!!
<ppisati_> awe: i tested it rhtough the 3.5jack (and i had to disconnect the hdmi cable)
<ppisati_> or i didn't hear anything
<ppisati_> ubuntu@raspi3:~$ cat /proc/asound/cards
<ppisati_>  0 [ALSA           ]: bcm2835 - bcm2835 ALSA
<ppisati_>                       bcm2835 ALSA
<awe> right, in theory as long as both outputs are available
<ppisati_> after appending that line and rebooting
<awe> you can switch using amixer
<awe> cool
<ppisati_> awe: can you?
<ppisati_> no idea
<ppisati_> i found that, pulled out the hdmi cable, installed mpg123 and played an .mp3 file
<ppisati_> ogra_: FYI ^
<awe> https://www.raspberrypi.org/documentation/configuration/audio-config.md
<ppisati_> awe: :O
<ogra_> ppisati_, ah, cool ... is that true for both pi's ?
<ppisati_> ogra_: tested only on the pi3, but i betit works the same on pi2
<ogra_> yeah
<ogra_> so i guess we should ste that by default in our config.txt
<ppisati_> makes sense
<ogra_> jdstrand, do you have any idea about bug #1610292 (there is also  https://lists.ubuntu.com/archives/snapcraft/2016-August/000655.html discussing that)
<mup> Bug #1610292: Snap installed with --devmode can't use sudo <amd64> <apport-bug> <yakkety> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1610292>
<ogra_> i'm not sure we want snaps to randomly ship /etc/sudoers.d snippets
<jdstrand> ogra_: what do you mean be 'any idea'?
<ogra_> how to solve it in a secure way
<ogra_> in the ML discussion zyga proposed to have a service that runs as root that the user driven app can attach to instead of using sudo for example
<jdstrand> otoh it is really thorny
<jdstrand> that service would be attacked like crazy
<ogra_> i find the whole idea of a sudo interface a bit horrid TBH
<ogra_> would it ? if it only allows connections from within the snap ?
<jdstrand> yes
<ogra_> (so only the shiped user app can attach to it)
<jdstrand> "here, I'll run things for you as root"
<didrocks> elopio: I'm quite busy (focusing on finishing some things for a demo before going on holidays tomorrow), so maybe once I'm back?
<ogra_> well, but every service does that anyway
<jdstrand> what are you referring to?
<ogra_> daemons run as root ...
<jdstrand> what we allow in interfaces is talking to services that do certain things
<ogra_> if i ship a daemon that only allows a shipped enduser app from the same snap to attach to it, i effectively dont need sudo
<jdstrand> we don't have any services that run arbitrary commands as root
<jdstrand> you don't need sudo to talk to the service, but the service doesn't just do what you want
<jdstrand> this service is "connect to me and I'll do anything you ask"
<ogra_> well, in devmode it would
<elopio> didrocks: sure, ping me when you have the time.
<ogra_> the bug is about using sudo with devmode snaps (which currently doesnt work)
<jdstrand> is it though? as soon as devmode works people will want it for strict
<ogra_> hah
<jdstrand> I also don't see his response in my inbox...
<ogra_> so your opinion is "no sudo at all" ?
<ogra_> whose ? zyga's ?
<ogra_> that was from august 8th
<jdstrand> my opinion is that it is very thorny and it needs to be thought through extremely carefully
<ogra_> yeah, i'm not a fan of it at all
 * jdstrand notes that the subject is "Using sudo from within a snap" -- there is no mention of devmode in that snap. mark my words, people will immediately ask for it
<jdstrand> in strict mode
<jdstrand> let me read zyga's response'
<ogra_> especially since we will get into awful situations with the passwd db  and libnss-extrausers inside the core snap too
<ogra_> "Using sudo from within a snap" refers to two bugs ... one is the above one
<jdstrand> yes
<ogra_> the other is the secure_path fix that mvo landed yesterday
<jdstrand> I suppose something along the lines of gksudo that works more like pkexec could possibly work. ie, you have a service that can pop up a dialog. but how does that work with cli? it is very messy
<jdstrand> I see zyga's response on the 8th but I don't see where he is suggesting a sudo service
<jdstrand> oh, I think I see what you mean
<jdstrand> an app could ship a root daemon that the cli could talk to
<mvo> zyga: hm, bug #1607710 is interessting,
<mup> Bug #1607710: Home directories listed in /etc/passwd should be honoured <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1607710>
<jdstrand> that isn't sudo. sudo is 'let me run this outside of confinement'
<cwayne> jdstrand: ogra_ would using pkexec be preferable to sudo?
<jdstrand> pkexec isn't allowed either, so not at this time
<cwayne> the impetus for sending out that mail is that checkbox runs some tests as root, and its currently trying to just use sudo and failing
<jdstrand> this is a fundamental issue
<jdstrand> snaps are by definition tightly confined
<ogra_> yyeah
<jdstrand> allowing them to use sudo to break out of confinement as root doesn't really work
<cwayne> well its not necessarily trying to break out of confinement, some confined things need root (like bluez-tests)
<jdstrand> that is different
<jdstrand> snap commands should be able to talk to their daemons
<jdstrand> we shouldn't block that (but that is largely up to the snap daemon to set up things in a way for that to happen
<sborovkov> niemeyer: that plymouth patch works, thanks!
<jdstrand> )
<jdstrand> but the example in the bug is checkbox. checkbox wants to run things outside of itself
<jdstrand> it really wants to have an unconfined interface
<jdstrand> I suppose an argument could be made that devmode snaps should be able to use sudo. but the mailing doesn't say that
<jdstrand> mailing list*
<jdstrand> and reading the bug more closely-- it should work
<jdstrand> the problem in the bug is "Any call to sudo fails with the error "pkexec must be setuid root""
<jdstrand> why is sudo calling pkexec?
<jdstrand> the problem here is that pkexec is not installed in the core snap
<cwayne> https://www.irccloud.com/pastebin/8j0nZM46/
<ogra_> jdstrand, well, it seesm to be shipped with the checkbox snap ...
<cwayne> spineau: ^ for context
<ogra_> else it wouldnt print the error
<ogra_> (unless the sudo error is simply misleading)
<jdstrand> ogra_: yes, but as the bug said, the setuid bit is stripped
<ogra_> as always in snaps :)
<jdstrand> I guess what is happening is sudo pkexec ...
<ogra_> uuuh
<ogra_> kind of overzealous :)
<jdstrand> or sudo wrapper.that.calls.pkexec ...
<ogra_> cwayne, is pkexec inside your snap ?
<jdstrand> cause sudo itself won't call pkexec
 * jdstrand just grep the sudo source code
<jdstrand> grepped*
<ogra_> i wonder if they could just ship gksudo instead
<ogra_> iirc that only acts as frontend ... so wont need to be suid root
<spineau> cwayne: do you have the bug id jdstrand is referring to?
<ogra_>  Bug #1610292
<mup> Bug #1610292: Snap installed with --devmode can't use sudo <amd64> <apport-bug> <yakkety> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1610292>
<spineau> thx
<jdstrand> well, gksudo pkexec won't work either :)
<ogra_> note that most of the discussion around it was on the mailing list though
<ogra_> jdstrand, heh ... no, but gksudo /path/to/binary will
<ogra_> as long as it has access to sudo
<spineau> I know that plainbox as the deb package depends on pkexec/policykit but since we're now pulling it from pypi I'm wondering which parts pulls in pkexec into the snap
<jdstrand> I commented in the bug
 * jdstrand suspects that sudo /path/to/binary will too
<zyga> mvo: I saw that bug, it is the evolution of the jenkins-cannot-run-snaps-bug
<zyga> jdstrand: checkbox is a different thing
<zyga> jdstrand: it's not about running unconfined
<cwayne> ogra_: it seems to, not sure where its from though
<zyga> jdstrand: the idea is to precisely run confined because the tests will exercise the interface
<zyga> jdstrand: root or user is another angle, it's not the unconfined root that is needed
<jdstrand> zyga: the bug very clearly references 'checkbox-snappy'
<mup> Bug #1613775 opened: Symlinks in home directory doesn't work with snap home plugin <Snappy:New> <https://launchpad.net/bugs/1613775>
<zyga> jdstrand: checkbox also wants to do profile transitions so tha checkbox can run two tests, each with different plugs (for example) but this is another story
<jdstrand> I know
<zyga> jdstrand: I think we should let checkbox use sudo-to-be-confined-root
<jdstrand> I decided to focus on the devmode not working angle
<zyga> jdstrand: oh!
<zyga> jdstrand: that's the glibc bug, right?
<jdstrand> instead of trying to shove checkbox into a strict mode snap or to let arbitrary snaps run sudo
<jdstrand> no
<joc_> cwayne: https://git.launchpad.net/~checkbox-dev/checkbox/+git/checkbox-parts/tree/snapcraft.yaml#n22
<jdstrand> it is that pkexec is not in the core snap and that pkexec in the app snap gets its setuid bit stripped
<jdstrand> and something in the snap ends up calling pkexec
<zyga> jdstrand: ah, I see
<jdstrand> but the error makes it look like sudo is complaing
<zyga> yes
<zyga> I know, I wrote that code
<zyga> joc_, spineau: I know exactly what calls pkexec
<joc_> i have no doubt :)
<spineau> zyga: the warmup?
<zyga> there's a execution controller for pkexec and sudo, if sudo doesn't work we do use pkexed
<zyga> pkexec
<zyga> spineau: not even warmup, any tests that wants to run as root
<jdstrand> sudo not able to work right in devmode is something that can be worked through
<jdstrand> would just need more details (and to be assigned to look at it)
<cwayne> spineau: ^ would you be able to provide those details (as in what plainbox is actually trying to do when it gets denied)
<spineau> zyga: we have two controllers which should return a negative score then, RootViaPTL1ExecutionController and RootViaPkexecExecutionController
<spineau> if both return -1 then only sudo remains possible
<spineau> cwayne: I'd like first to remove pkexec from the problem to have plainbox running jobs as root only with sudo and see what breaks exactly
<spineau> cwayne: context here is devmode + sudo, not our second issue with sudo + confinement
<cwayne> right
<cwayne> we have so many issues :)
 * spineau should turn sentences is in a more positive way
<zyga> spineau: we have so many issues but we used to have more and we are healthy!
<spineau> cwayne: zyga: I can update plainbox to return -1 for the two controllers using pkexec as a backend. Once merged I can update plainbox on pypi so that future snap builds can just use sudo. From there we will be able to iterate.
<spineau> I don't want to bother our snappy experts with plainbox internals
<spineau> if we can make sure that we are no longer call pkexec internally it will help diagnosing the problem
<cwayne> +1
<mup> PR snapcraft#725 closed: Support having the snapcraft.yaml in a subdir <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/725>
<marcoceppi> I need help with Python2 plugin, getting this error
<marcoceppi> /usr/bin/env: 'python2': No such file or directory
<marcoceppi> when running python scripts from inside my snap
<kyrofa> marcoceppi, are you actually exporting the scripts using the `apps` in the YAML?
<marcoceppi> kyrofa: I guess so?
<kyrofa> marcoceppi, or are you calling them directly?
<marcoceppi> kyrofa: http://paste.ubuntu.com/23062172/
<marcoceppi> there's a golang tool that uses $PATH to find plugins
<marcoceppi> charm-tools, provides a suite of plugins in Python
<kyrofa> marcoceppi, hmm... and bin/charm seems to be provided by the go part, not python?
<marcoceppi> kyrofa: yes, and that works
<marcoceppi> but running any of the subcommands which are pythjon result in the aforementioned error
<kyrofa> marcoceppi, can you pastebin the contents of /snap/charm/current/charm.command (I think)?
<kyrofa> Or charm-command... something like that
<marcoceppi> kyrofa: /snap/charm/current/command-charm.wrapper: http://paste.ubuntu.com/23062186/
<kyrofa> marcoceppi, ohhhhhh
<kyrofa> I know what's happening
<marcoceppi> I am so ready for thsi
<kyrofa> marcoceppi, your use of the `snap` keyword on the charm-tools part is a whitelist
<kyrofa> marcoceppi, you're not actually including python :P
<kyrofa> marcoceppi, perhaps you want to turn it into a blacklist instead?
<marcoceppi> no, I want those included
<marcoceppi> they weren't being included before
<marcoceppi> well I want like EVERYTHING included
<marcoceppi> everything I need to make this work
<mup> PR snapcraft#732 opened: Remove store dispute logic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/732>
<marcoceppi> kyrofa: so I need to inlucde like $SNAP/usr/lib/python2.7/* in my whitelist?
<kyrofa> marcoceppi, hmm... it should include everything placed by the setup.py
<kyrofa> marcoceppi, in addition to python and other prereqs of the plugin
<marcoceppi> kyrofa: redherring, I found the issue
<mup> PR snapcraft#730 closed: Clarification of make plugin help text <Created by mikemccracken> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/730>
<kyrofa> marcoceppi, okay, good deal
<mup> PR snapcraft#658 closed: parser - Return non-zero code for wiki errors <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/658>
<stokachu> how can i make snap refresh keep the --devmode flag?
<marcoceppi> I'm an upstream developer, and my project name isn't available
<marcoceppi> no one has answered my dispute yet
<kyrofa> marcoceppi, talk to nessita
<nessita> marcoceppi, hi! what's your project name?
<marcoceppi> nessita: charm
<mup> PR snapd#1681 opened: tests: test `snap run --hook` using in-tree snap-exec <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1681>
<mup> PR snapd#1689 opened: spread: disable re-exec to always test development tree <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1689>
<balloons> jdstrand, did the new snap-confine restrict things further? I can't seem to use lxd with the juju snap anymore, despite --devmode
<jdstrand> balloons: it switched how bind mounts are applied, which might break devmode for you. can you file a bug against snap-confine? zyga, fyi ^
<balloons> jdstrand, I certainly can. I was just going a bit crazy feeling like I'd done something wrong. Good to know
<marcoceppi> nessita: is there anything else I need to do?
<balloons> zyga, jdstrand, file here https://github.com/snapcore/snap-confine/issues? Also as a side note, would we consider this a regression? I'm curious how long the package will be broken
<nessita> marcoceppi, checking the status
<nessita> marcoceppi, I only see charm-tools and not charm
<nessita> marcoceppi, and the comment you added sounds like is a temporary name? you still need it?
<marcoceppi> nessita: I see this:
<nessita> marcoceppi, hum, sorry, found charm in another queue
<jdstrand> balloons: https://bugs.launchpad.net/snap-confine/+filebug
<marcoceppi> nessita: charm Pending name dispute review
<nessita> marcoceppi, yeah, dispute review was a different queue, checking now
<marcoceppi> charm-tools was my attempt to register a name while waiting for charm to be reviewed
<jdstrand> balloons: as for a regression, probably, and I would expect it to be fixed reasonably soon
<jdstrand> balloons: but when would be up to zyga (he is preparing a new release now and may or may not want to include this fix in it)
<balloons> jdstrand, interesting.. small diff that broke things; https://launchpadlibrarian.net/276007118/snap-confine_1.0.38-0ubuntu0.16.04.3_1.0.38-0ubuntu0.16.04.4.diff.gz
<nessita> marcoceppi, see u1-internal please
<jdstrand> balloons: that's curious. 1.0.38-0ubuntu0.16.04.3 worked for you and 1.0.38-0ubuntu0.16.04.4 does not? Definitely worth mentioning in the bug
<bladernr> are there any docs or pointers floating around with info on how to get around "make install" needing root permissions when using the autotools plugin?
<bladernr> It is building successfully, but then tries to do a make install and fails changing permissions:  http://paste.ubuntu.com/23062496/
<stokachu> are there any snap examples where it tries to create it's own network bridge?
<kyrofa> bladernr, why does it need root:root there?
<stokachu> basically this https://lists.ubuntu.com/archives/snappy-app-devel/2015-November/000477.html
<kyrofa> That doesn't seem like a normal thing
<bladernr> kyrofa, no idea... (*I'm not a C guy, I can basically read makefiles, but am not an expert.  I see what you're talking about now, I didn't notice that before).
<bladernr> I have a feeling it's because on a regular system, its make install copies to /bin, which does need root permissions to copy into
<bladernr> thanks, I didn't notice that before though, I'll play with that some more
<zyga> balloons: do you have more details
<balloons> zyga, hey. I can play with the setup as much as you'd like right now. What are you curious about?
<zyga> balloons: what broke
<zyga> balloons: is there a bug report?
<balloons> zyga, basically as the bug says my old juju snaps don't bootstrap with LXD anymore. Essentially the socket isn't found I gues
<balloons> zyga, https://bugs.launchpad.net/snap-confine/+bug/1613845.
<mup> Bug #1613845: Juju snap can no longer interact with LXD in devmode <conjure> <Snappy Launcher:New> <https://launchpad.net/bugs/1613845>
<zyga> balloons: where is the lxd socket?
<balloons> zyga, I was starting to play with versions to try and pinpoint which exact version broke it. My initial description highlighted a version, but I'm not positive it was the first one to break
<balloons> zyga, /var/lib/lxd/unix.socket
<zyga> balloons: thank you
<zyga> balloons: /var/lib is not bind mounted so you get what you'd get in an all-snap system (read only content of the core snap)
<balloons> zyga, and this presumably has changed from before right?
<zyga> balloons: services should use /run or for sockets AFAIR (sadly we cannot support arbitrary locations)
<zyga> balloons: not directly, the change is the use of chroot, in the past we bind mounted a few directories from the core snap to the root fs
<zyga> balloons: now we chroot to the core snap and bind mount some things from there
<zyga> balloons: this is consistent with all-snap images and works on any distribution
<zyga> balloons: can lxd use another location for the socket?
<zyga> slangasek, mwhudson; https://github.com/snapcore/snap-confine/pull/108/files
<mup> PR snap-confine#108: Remove packaging <Created by zyga> <https://github.com/snapcore/snap-confine/pull/108>
<balloons> zyga, in theory yes. In practice, I've no real idea. But I can't imagine it would be a quick or even desirable change. LXD is stable now and the socket is where I told you it was
<zyga> balloons: looking at the core snap, I don't see /var/lib/lxd there, we'd have to bind-mount all of /var/lib
<zyga> balloons: but it cannot be there because that's a read only location for the core snap
<zyga> balloons: even in devmode
<stokachu> zyga: but it worked before
<zyga> balloons: while it may be stable snapd cannot support random locations that particular package can wish because there's no way to do that without adding all those locations to hte core snap
<stokachu> zyga: and since snap is GA this is considered a regression, no?
<zyga> stokachu: read what I said above, that didn't work on all snap images and the way we worked on classic was problematic for other reasons, there's no good change but I believe that this change is better as it is consistent in behavior across systems
<zyga> stokachu: I don't think so
<stokachu> zyga: except it breaks our ability to use lxd inside a snap
<stokachu> where we could before
<balloons> zyga, I think the is part of the crux of the matter. It kills the story if we can't fix it
<zyga> stokachu: it breaks lxd as a snap in all-snap systems, it would never work there :/
<zyga> balloons: it's all software, we can fix it
<zyga> balloons: the question is how
<stokachu> zyga: right but it *worked* before
<stokachu> juju could access lxd inside a snap
<zyga> stokachu: but other things did not
<balloons> zyga, right. I'm saying insomuch as stokachu points out, you've SRU'd this and broken existing snaps
<stokachu> right so you've introduced a regression
<balloons> so I don't think you can make this change until you've fixed it -- if that means in LXD or wherever
<zyga> balloons: I understand that; I'm saying that we cannot always keep things working, in this case lxd worked beause it relied on something that is not a feature
<zyga> balloons: if we revert the chroot we'll break every other distribution and a few things on ubuntu
<stokachu> zyga: uhm no
<balloons> zyga, right. And I feel like for xenial the right thing to do is let it stay the same. Is that not possible?
<zyga> balloons: no
<zyga> balloons: can we talk to stgraber to find a solution please
<stokachu> zyga: you can't just introduce a regression in a LTS release
<zyga> stokachu: even if something worked because it relied on a bug?
<stokachu> zyga: you introduced a regression in a LTS release
<stokachu> bottom line
<zyga> stokachu: lets not spin this this way, let's find a way for lxd ot work
<balloons> zyga, yes finding a more permanent solution with LXD is a good idea. However, I'm worried about other snaps that may be broken for similar reasons
<balloons> also thinking about https://bugs.launchpad.net/snappy/+bug/1604967
<mup> Bug #1604967: Apparmor denies bind to abstract unix sockets such as @/var/lib/juju/mutex-/store-lock <conjure> <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1604967>
<zyga> stokachu: fixing a bug regresses software that relied on the bug, we're making many changes to snapd, we're hoping to keep software compatible but it's not always possible
<stokachu> zyga: how can you call this GA then?
<stokachu> you give us no guarantee
<zyga> stokachu: does GA say "it is not changing ever"?
<stokachu> LTS does
<stokachu> dont introduce regressions in an LTS release
<zyga> this is not a constructive discussion, let's find a way to fix the problem
<zyga> not discuss acronyms
<zyga> stokachu:  is https://bugs.launchpad.net/snappy/+bug/1604967 a regression?
<mup> Bug #1604967: Apparmor denies bind to abstract unix sockets such as @/var/lib/juju/mutex-/store-lock <conjure> <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1604967>
<stokachu> that never worked in strict mode
<stokachu> so no.. it's not a regression
<zyga> stokachu: ok
<stokachu> you've broken things that run in --devmode
<zyga> stokachu: as for /var/lib/lxd, I need to investigate options
<balloons> zyga, that bug is talking about strict mode indeed. But the idea is, lxd is hardly the only bit of software to use an abstract socket. And they are not going to be in /run
<zyga> stokachu: the old way to run snaps was not sustainable, this was done many releases ago, it was never released via SRU becasue of other issues, I'm sorry that it broke lxd and I will look for solutions
<stokachu> zyga: thank you
<zyga> balloons: how would that snap work in all-snap device where that location is read only?
<zyga> (worse, that location doesn't exist)
<stokachu> zyga: you seem to be forgetting about people who needs to run snaps on servers
<balloons> zyga, the way I see it is that, that problem of everything running under strict mode and with a read-only core is something to work towards
<balloons> if you go down that path too early for --devmode, we can't begin adoption
<zyga> stokachu: I'm saying that yes, the snap was running in a particular distribution with a particual layout but would not work elsewhere, that's not hte promise of snaps, while I don't want to break anything the change was made to improve support in general
<stokachu> zyga: then break it in yakkety
<stokachu> not in xenial
<balloons> zyga, can we not differentiate breaking it under --strict mode, but not under --devmode?
<zyga> stokachu: that's not as simple as that, this is a fundamental way that in which snaps work
<zyga> balloons: snap-confine doesn't do anything differntly in devmode
<zyga> stokachu, balloons: FYI: http://www.zygoon.pl/2016/08/snap-execution-environment.html
<zyga> I know this change is somehing that you don't like because it broke the software you want to use but I'm saying that we had to make the change
<zyga> I'll stop arguing because it seems to lead nowhere
<zyga> I will look for solutions
<balloons> zyga, I'm asking for snap-confine to treat dev-mode differently. To allow it to make poor choices so that all the other good parts of snappy can be used. It's about keeping the initial adoption barrier as low as possible
<zyga> balloons: read my blog post first, what you are asking for is not something that can be done, if we go back to the old way of constructing the filesystem we will just break other things again
<zyga> balloons: let me discuss this with the team and get back to you with solutions
<balloons> zyga, ok. And presumably everything must change at the same time -- xenial cannot be treated differently?
<zyga> balloons: that's another story, we can explore that
<balloons> zyga, so it sounds like there may be solutions on your end. Good. It's worth thinking very carefully about raising the barrier for --devmode
<balloons> zyga, please do keep me in the loop -- I'm happy to talk about it
<zyga> balloons: note that before there were also read-only locations
<zyga> balloons: devmode never affected that
<zyga> stokachu: FYI, yakkety uses 'series 16' so it shares the same snap and snapd as xenial, in fact they are exactly the same and share the same core snap which contains snapd and snap-confine (so while we might want to do something special in xenial only the design of snap makes it really tricky). I'm looking at a solution that will fix it everywhere (including on all the other supported distributions)
<stokachu> k thanks
<zyga> ogra_: ping
<ogra_> zyga, moop
<bladernr> Ok... so I built a snap... put it in the store, and published.  How do I find it?
<bladernr> How do I install it?
<bladernr> snap find returns nothing, even after logging into the store
<qengho> bladernr: How did you upload?
<bladernr> uhhh... snapcraft upload <snap>
<bladernr> https://myapps.developer.ubuntu.com/dev/click-apps/
<bladernr> http://snapcraft.io/docs/build-snaps/publish following this
<bladernr> Oh wait... why is it listed as a click app?
<qengho> bladernr: So, at myapps, you see your app? If you click on a release, do you see "Status: Published" and "Channels: ...Stable" and "Supported releases: 16"?
<bladernr> https://myapps.developer.ubuntu.com/dev/click-apps/5728/rev/1/  or do both click apps and snaps go into the clic-apps dir
<zyga> bladernr: did you publish it into the stable channel
<bladernr> it is now
<bladernr> I thought I did that before, but its targeted to all
<bladernr> ahhh, ok.  there she be
<marcoceppi> so I have a snap in the edge channel, but when I got to install it
<marcoceppi> error: cannot perform the following tasks:
<marcoceppi> - Download snap "charm" (1) from channel "edge" (received an unexpected http response code (401) when trying to download https://public.apps.ubuntu.com/download-snap/2Rryoc2ylScfbFl4eQtpntHD9iuZuMvt_1.snap)
<marcoceppi> I get a 401? the item is public and published
<marcoceppi> had to log into the store, that error is super unhelpful
<qengho> 4nn is client-side error, asserted from the server. Doesn't sound like your package is the problem.
<qengho> marcoceppi: Oh, did it work then?
<marcoceppi> qengho: yes
<qengho> $ ubuntu-bug snapd   #file a bug report!
<zyga> stokachu: I talked to jdstrand and we have a plan for the fix that can be rolled out quickly; I'm working on the fix now
<zyga> balloons: ^^
<balloons> zyga, ty!
<marcoceppi> I've got a problem with temp directories in Python not being created? within a snap
<marcoceppi> http://paste.ubuntu.com/23062754/
<zyga> marcoceppi: can you report a bug with some more details (tracebacks, denials, etc)
<marcoceppi> I wonder if this is just an issue with git in snaps? has anyone had any problems with athat?
<zyga> marcoceppi: remmeber that /tmp is a fresh tmpfs when you start a snap application
<marcoceppi> zyga: where do aarmor messages pop up?
<marcoceppi> zyga: sure, which is fine(?) or should be for this
<zyga> marcoceppi: I think so
<zyga> marcoceppi: try journalctl -f
<zyga> marcoceppi: and run your app again
<zyga> marcoceppi: FYI: http://www.zygoon.pl/2016/08/snap-execution-environment.html (and grep for /tmp)
<zyga> marcoceppi: nothing new but perhaps you'll get an idea why it failed
<marcoceppi> zyga: so I'm getting a denial, but for /etc/apt/apt.conf.d which is for an apt look up, but it hsouldn't affect this git clone attempt
<zyga> I agree
<marcoceppi> zyga: per process? so if I run a command, /snap/bin/charm create, for example, which then has a few subprocess calls, one being git clone to /tmp - does that mean that subsequent subprocess calls or file operations during the execution of /snap/bin/charm would get fresh tmp? or is it per invocation of /snap/bin/charm ?
<zyga> marcoceppi: yes, per process
<zyga> marcoceppi: ah, not per per process
<zyga> marcoceppi: per top-level snap application
<marcoceppi> cool, so that should be fine
<zyga> (process)
<zyga> it is per invocation of /snap/bin/charm
<marcoceppi> so, maybe it's really git that's failing, it seems to complain about /usr/share/git-core/templates even though that's in the prime
<ali1234> when do they get cleaned up?
<zyga> marcoceppi: is it reading it from /snap/$SNAP_NAME/current/usr/share/git-core/templates or from /usr/share/git-core/templates
<zyga> marcoceppi: the prime directory is not the root filesystem
<zyga> marcoceppi: if it opens /usr/share/git-core/tempates those are not going to be there
<marcoceppi> zyga: well, considering aa hasn't yelled at me, I assume it's from $SNAP
<zyga> jdstrand: ^^ another thing we could actually map with the quirk code
<zyga> marcoceppi: I doubt it is from $SNAP
<zyga> marcoceppi: unless git is configured to do so in some way
<marcoceppi> zyga: well, isn't it all chrooted?
<marcoceppi> git is installed in my snap, etc
<marcoceppi> /snap/charm/current/usr/share/git-core/templates exists
<zyga> marcoceppi: no the way you think IMHO
<zyga> marcoceppi: please read my blog post (the one I linked to)
<mup> PR snapd#1322 closed: daemon, overlord/auth: refactor auth in preparation for other credential types <Reviewed> <Created by wgrant> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/1322>
<marcoceppi> okay
<marcoceppi> so how do I troubleshoot this
<marcoceppi> because aa isn't complaining, the software isn't working, and I'm left without a real clear way to poke things
<zyga> marcoceppi: I bet that what I said above is true, if git can be configured in some way then as a trick, use --prefix of /snap/$SNAP_NAME/current/usr and then use organize so that the prime directory has just the final /usr directory in the snap
<marcoceppi> so, the snap has the /usr directory it needs already in there, what you seem to suggest is that I will have to compile git from source to get this t work?
<mwhudson> zyga: i don't think i can advocate you as a DM
<zyga> mwhudson: that's okay, thanks
<zyga> marcoceppi: yes
<marcoceppi> well,that's really unfortuantely.
<marcoceppi> this seems ridiculous that I have to compile git to get it to work in my snap
<marcoceppi> I'm not a git expert, I just depend on the damn thing, and my stabs at getting it to compile have failed thus far
<jdstrand> zyga: interesting
<zyga> stokachu: i have a patch that fixes it locally (I didn't try with lxd yet but /var/lib/lxd is now writable in devmode and shows my real hostfs /var/lib/lxd)
<zyga> balloons, stokachu: https://bugs.launchpad.net/snap-confine/+bug/1613845 is now fixed
<mup> Bug #1613845: Juju snap can no longer interact with LXD in devmode <conjure> <Snappy Launcher:Fix Committed by zyga> <https://launchpad.net/bugs/1613845>
<zyga> I will work on the SRU process tomorrow
<zyga> good night :)
#snappy 2016-08-17
<mup> PR snapcraft#733 opened: Add the go-buildtags property to the go plugin <Created by elopio> <https://github.com/snapcore/snapcraft/pull/733>
<mup> PR snapcraft#724 closed: In travis, install the static checkers with pip <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/724>
<mup> PR snapcraft#729 closed: Dump plugin: Don't remove install directory <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/729>
<mup> PR snapcraft#732 closed: Remove store dispute logic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/732>
<lpotter> :( Service has Restart= setting other than no, which isn't allowed for Type=oneshot services. Refusing.
<liuxg> has anyone used "snapcraft cleanbuild" to build a snap project? I tried to build a simple project. However, I got many errors like http://paste.ubuntu.com/23063560/, what could be the root cause of it? Should I set up LXD seperately?
<wimzei> Hello are snappy avaliable for rpi3?
<liuxg> does anyone know how to invoke the "stop command" in a snap application? thanks
<liuxg> I have a daemon app in my snap, I can use the app's name to launch the app. I also define a "stop-command" to stop the daemon. The problem is what is the correct syntax to invoke the "stop-command" to stop the deamon. thanks
<didrocks> liuxg: you need to use systemctl for this
<didrocks> liuxg: I don't think snap reimplemented an easy way to start/stop command yet
<liuxg> didrocks, yes, that is currently what I am doing. still I want to try the stop command to get it working
<liuxg> didrocks, I think it is more direct from user point of view.
<didrocks> liuxg: on the cleanbuild issue, it seems to me that your lxd apt database didn't apt update recently. I thought snapcraft cleanbuild would do that on each build, sergiusens ^
<liuxg> didrocks, what is the correct syntax to invoke a stop command.
<didrocks> liuxg: use the "systemctl stop" command (as you are currently doing, right?)
<liuxg> didrocks, do you mean that "systemctrl stop" will invoke the "stop" command?
<didrocks> liuxg: hum, it seems you don't know this command, what did you mean with "that is currently what I am doing"?
<liuxg> didrocks, what I found was that I could use that to stop the daemon even if I did not specify the "stop-command". if that is the case, what is use of the definition of "stop-command"?
<didrocks> liuxg: it's to enable having systemd stopping your daemon using that command
<didrocks> instead of just killing it
<didrocks> liuxg: ok, so to use systemctl, you need to have the name of the generated .service file
<didrocks> for this, ls /etc/systemd/system/*<yoursnapname>*
<liuxg> didrocks, I could use the "systemctrl stop snap.xxxx.xxx" to stop a daemon app in any case without defining the "stop-command". I am wondering what is the purpose of "stop-command" defined in the snapcraft.yaml.
<didrocks> -> you will get a .service filename
<didrocks> then, systemctl stop <thisservicefilename>
<didrocks> right, so:
<didrocks> if you don't mention a stop-command, systemd will just kill your process
<didrocks> to "stop" it
<didrocks> sometimes, some services needs to do better cleanup
<didrocks> like closing a database and such
<didrocks> and they have a different command to stop itself
<didrocks> in that case, use stop-command to point to this command
<didrocks> and systemctl stop <â¦> will just invoke this command to stop the daemon
<liuxg> didrocks, my question is whether it will invoke my defined stop command "stop-command: bin/wrapperãstop" if I use "systemctrl stop xxx"
<didrocks> (and kill it after a timeout)
<didrocks> (if it didn't get kill)
<didrocks> liuxg: that's what I just answered above $
<liuxg> didrocks, OK. so, if we do not define a "stop command", the daemon will be forcefully shut down. if it is defined, it will just call "stop command" to gracefully shut down by using the command "systemctrl stop".
<didrocks> liuxg: exactly! However, in the second case, if the daemon isn't shutdown by the "stop" command your provided after a $timeout time, it will force-kill it
<didrocks> you*
<liuxg> didrocks, got it. thanks!
<didrocks> yw :)
<liuxg> didrocks, did you successfully build a snap project using "snapcraft cleanbuild" command? I did not succeed it.
<didrocks> liuxg: it works for me
<didrocks> liuxg: see my answer above about your issue
<liuxg> didrocks, I am wondering whether it works out of the box, or I need to set sth up first before to get it working.
<didrocks> liuxg: apart from lxd init, nothing, and the container starts for you, so it's not this
 * kalikiana <3 snapcraft cleanbuild
<kalikiana> btw cleanbuild is also good for cases where a build system is "smart" and pulls in dependencies you didn't expect, my nvim suprisingly doubles in size with a 'regular' build because it pulls in libxml which drags icu in - if anyone is wondering about that, it's worth considering that causality
<zyga> icu aka "I grok unicode"
<zyga> sadly the alternative is "I live in the 80s"
<kalikiana> it's not meaingful for the use case - universal-ctags is pulling it in and I'm pretty sure I don't require unicode there
<kalikiana> the "good old" exuberant ctags in the archives isn't using it either
<zyga> perhaps, my comment was generic, icu is just large but we have to live with it
<kalikiana> yeah, for cases where it is more or less the only option it's unfortunate
<ogra_> reading /kernel.img
<ogra_> ** Unable to read file /kernel.img **
<ogra_> reading /initrd.img
<ogra_> ** Unable to read file /initrd.img **
<ogra_> Bad Linux ARM zImage magic!
<ogra_> :(
 * zyga hugs ogra
<ogra_> no mvo :(
<ogra_> seems tonights auto-upgrade did completely unset snap_kernel in my bootloaders
<ogra_> zyga, do you know if he is off today ?
<zyga> ogra_: he's around, he's away for a few hours now
<stokachu> zyga: awesome thanks man
<zyga> stokachu: I talked to mvo about this and we're going to SRU this ASAP, we're also re-considering the chroot approach now, this is not a simple thing so don't expect a decision overnight (like the patch :)
<zyga> stokachu: I will do 1.0.40 release in a moment and work on the SRU with mvo
<stokachu> zyga: understood
<zyga> stokachu: if you want you can try to build it now and test that it fixes the issue
<zyga> stokachu: take master and packaging from https://code.launchpad.net/~snappy-dev/snap-confine/+git/snap-confine/+ref/16.04
<stokachu> zyga: ok, ill do a local build and give it a run
<zyga> (packaging will change a little when mvo is back, we want to integrate his packaging work that was never committed)
<zyga> I'll keep you posted :)
<mvo> zyga: hey
<stokachu> zyga: great, thanks!
<zyga> mvo: hey, welcome back :-)
<zyga> mvo: FYI, I've modelled packaging after fedora-scm a little, I think the approach is great (branch per distro series) and simple to work with, the content is entirely up to us
<ogra_> mvo, all my boards fell apart today with no snap_kernel set at all after reboot
 * zyga is working on fedora now
<ogra_> (seems they did their auto-upgrade ... when i rebooted them all _kernel vars were completely unset)
<ogra_> mvo, i suspect there is some quoting issue
<mvo> ogra_: yeah, same bug, I do new image
<mvo> s
<mvo> ogra_: let me do that rightnow
<zyga> mvo: ping me on telegram when you have a moment to help me with the SRU process for snap-confine
<zyga> (in private so that I get notified please)
<ogra_> mvo, seems when i change the script like: http://paste.ubuntu.com/23064119/ it doesnt fall over
<zyga> Son_Goku: hey, still no selinux support, spent last night fire-fighting, I'm doing package builds and uploads now
<ogra_> (using test -n and no quoting for teh vars, the hush shell in uboot is very picky about such stuff IIRC)
<zyga> Son_Goku: when I'm dong with snap-confine uploads I will try to integrate fedora into upstream CI
<ogra_> hmm, no, i take that back
<ogra_> it works exactly for one boot
<ogra_> so there is something else
<ogra_> (nontheless that script variant is cleaner :) )
 * zyga uploads snap-confine to rawhide :)
<mvo> ogra_: hm, ok
<mvo> ogra_: can you dump the environment when it fails?
<zyga> Son_Goku: I'd like to get a neutered version of snapd reviewed, without active systemd units
<ogra_> mvo, well, the change is that snap_kernel is completely nonexistant then
<zyga> Son_Goku: and initially just for f23 where systemd is not confined with selinux
<zyga> Son_Goku: then work on making initial selinux changes for snapd.socket
<mvo> ogra_: snap_kernel="" or not there at all?
<zyga> Son_Goku: that should unblock f24 and f25
<ogra_> not there at all
<zyga> Son_Goku: and then apply for the remaining permissions
<zyga> Son_Goku: let me know if this makes sense to you
<mvo> ogra_: interessting, let me check the code
<Son_Goku> zyga, you should apply for all of the branches anyway
<Son_Goku> keep in mind you can build for all of the targets without actually submitting something as an update
<zyga> Son_Goku: ack, I meant that initially just f23 will work
<zyga> oh, that's true!
<Son_Goku> those are two separate actions for a reason
<ogra_> mvo, if only one of snap_try_kernel or snap_try_core is set it seems the other one completely vanishes ... i just manually did set snap_mode try and snap_try_kernel and got:
<ogra_> ubuntu@dragonboard:~$ fw_printenv |grep ^snap_
<ogra_> snap_kernel=dragonboard-kernel_1.snap
<ogra_> ubuntu@dragonboard:~$
<Son_Goku> zyga, adding branches later requires you to go through re-reviews, which are annoying :P
<mvo> ogra_: meh, indeed, I think I found the issue
<Son_Goku> so just add them now, and once you're happy, you can submit an update for F24
<zyga> ok
<mvo> ogra_: I will work on a fix and see what can be done about automatic tests, we currently have no reboot spread test but maybe I can find something else
<ogra_> mvo, didnt leos setup have reboot tests ? perhaps we can use that for the moment
<Son_Goku> zyga, I would just submit to all branches and everything, and just not do fedpkg update until you're ready
<mvo> ogra_: yeah, I explore that a bit
<zyga> Son_Goku: yep, I'll do that, just doing the macaroon and snap-confine work now
<ogra_> seb128, hmmm ...
<seb128> ogra_, hey, issues with my livecd-rootfs upload?
<ogra_> seb128, only that they wont affect any ubuntu-core builds :) ... we a) only build xenial and b) the livecd-rootfs we use lives in a build PPA
<ogra_> (it is good that you land it in yakkety for completeness though)
<seb128> ogra_, well, trunk first ... but thanks for pointing it out, who do I bribe to get that ppa updated?
<ogra_> me or mvo
<ogra_> i'll take a look in a moment
<seb128> who wants beer in octobre? ;-)
<seb128> danke!
<ogra_> haha
<ogra_> seb128, hmm, i think your "no-apt" change is wrong (looking at http://launchpadlibrarian.net/279413400/livecd-rootfs_2.424_2.425.diff.gz)
<ogra_> seb128, if you remove the "cat <<EOF" then you need to at least add an echo or some such ...
<RoninDev_> Hello! Please, tell me, can I run script before autotools plugin run? e.g. ./bootstrap.sh?
<ogra_> ubuntu@dragonboard:~$ apt
<ogra_> Ubuntu Core does not use apt-get, see 'snappy --help'!
<ogra_> ubuntu@dragonboard:~$ cat /usr/local/bin/no-apt
<ogra_> #!/bin/sh
<ogra_> cat <<EOF
<ogra_> Ubuntu Core does not use apt-get, see 'snappy --help'!
<seb128> ogra_, that was a dupliucate EOF
<seb128> code now is
<seb128>  cat >$PREFIX/usr/local/bin/no-apt <<EOF
<seb128>  #!/bin/sh
<seb128>  Ubuntu Core does not use apt-get, see 'snappy --help'!
<seb128>  EOF
<seb128> oh
<ogra_> :)
<seb128> you are right
<seb128> shrug
<seb128> sorry about that ;-)
<seb128> if you want to fix it feel free
<ogra_> there is definitely a bug that the EOF is missing in the resulting script
<seb128> I can fix for trunk after lunch
<seb128> just add the echo
<ogra_> but apparnely cat doesnt really care at runtime :)
<ogra_> the xdg-open has a similar prob ... though there i dont understand the logic at all ... i wonder why it wants the cat in the script there
<seb128> the xdg one is fine
<seb128> the goal is to generate a file on disk
<seb128> cat >$PREFIX/usr/local/bin/xdg-open <<EOF
<seb128> #!/bin/sh
<seb128> dbus-send --print-reply --session --dest=com.canonical.SafeLauncher / com.canonical.SafeLauncher.OpenURL string:"\$1"
<seb128> EOF
<ogra_> right, i just wonder how it got like that
<seb128> if you sh that you get the 3 lines writen to $PREFIX/usr/local/bin/xdg-open
<ogra_> seems it was just a blind copy of the no-apt one
<seb128> right
<seb128> well the new version works I tested it
<seb128> dbus-send is a cmd
<seb128> but you are right about the other one missing the echo
<seb128> lunch now, bbiab
<Son_Goku> zyga, uhh what did you do?!
<Son_Goku> patches aren't supposed to be recorded in sources
<Son_Goku> they go into git itself
<Son_Goku> no one can read anything in the binary repo
<Son_Goku> zyga, did you approve my co-maintainer request for snap-confine?
<Son_Goku> https://admin.fedoraproject.org/pkgdb/package/rpms/snap-confine/
<zyga> oooh
<zyga> Son_Goku: I didn't see the request yet, looking now
<zyga> Son_Goku: how should I record the patch?
<Son_Goku> git add?
<zyga> Son_Goku: I see, let me correct that quickly
<zyga> done (commit access)
<Son_Goku> zyga, also, delete from "sources" the entry for the patch file
<Son_Goku> you don't want that there
<mup> PR snapd#1690 opened: partition: ensure that snap_{kernel,core} is not overriden with an empty value <Created by mvo5> <https://github.com/snapcore/snapd/pull/1690>
<Son_Goku> and you'll want to bump the changelog for the spec too
<Son_Goku> since you can't rebuild in koji without doing that
<zyga> Son_Goku: yep, should I bump the spec file for that?
<zyga> ah
<zyga> ok
<Son_Goku> oh, and in the changelog
<Son_Goku> do "%%license" instead of "%license"
<Son_Goku> because otherwise, it'll process it and weird things happen
<Son_Goku> like this: "- Use GPLv3 instead of %doc for COPYING"
<zyga> Fixed
<zyga> ooh
<zyga> %%license but %doc? why?
<zyga> Son_Goku: like this?
<zyga> -%license COPYING
<zyga> +%%license COPYING
<Son_Goku> yes
<Son_Goku> no
<zyga> :D
<Son_Goku> not in the actual %files list
<Son_Goku> in the changelog, it's actually processing the %license macro (which evaluates to the License field in the preamble)
<zyga> ahh
<Son_Goku> the files list is fine
<zyga> so the changelog entry can look like
<Son_Goku> but the changelog isn't
<zyga> - Use %%license instead of %%doc
<Son_Goku> yep
<zyga> k, thanks for spotting that!
<zyga> Son_Goku: pushed to master, let me know if this is good for fedpkg build
<Son_Goku> zyga, no prob
<Son_Goku> looks good to me
<Son_Goku> merge it into all your other branches and go forth and build :)
<mvo> ogra_: fwiw, branch pushed with fix for your bug
<zyga> yep, do I need to fedpkg update again?
<zyga> Son_Goku: I need a break, I'll do subsequent updates depending on your answer when I'm back from a walk
<Son_Goku> ok
<mup> PR snapd#1598 closed: interfaces: implement a fuse interface <Blocked> <Reviewed> <Created by stgraber> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1598>
<Son_Goku> zyga, I'm going to just modify your existing update to use snap-confine-1.0.30-2.fc23
<Son_Goku> zyga, you should submit snap-confine to F24 and F25 as updates, too
<Son_Goku> there's no reason not to
<kalikiana> Question: Is there a known fix for "/usr/bin/env bad interpreter: Permission denied"? I don't know if I should be changing my shebangs to work within confined snaps or file a bug
<kalikiana> Those same scripts work perfectly if I "sh foobar" them
<Chipaca> kalikiana, you want to change the interpreter
<Chipaca> i mean, the shebang
<Chipaca> jdstrand, is there a reason not to allow /usr/bin/env in the default profile?
<Chipaca> kalikiana, just for the record with very few exceptions you should be shipping the interpreter also
<Chipaca> kalikiana, the exceptions might begin and end with "sh"
<Chipaca> kalikiana, I do ship something that abuses things a little by using system's python3, but that's because I'm ok with it breaking
<kalikiana> In this instance I'm indeed using "!/usr/bin/env sh"
<kalikiana> python also appears to be functional - I haven't decided yet what to do with that wrt bundling, it would blow up the snap incredibly so I didn't upload a version with it enabled
<kalikiana> also optional modules - I'm thinking a way to pull in modules to $HOME would be nice, but there's no obvious way to do that
<kalikiana> by nature nvim is extensible so I have to ultimately find something that allows on demand installing
<Chipaca> kalikiana, using env (which isn't guarnateed to be in /usr/bin, in fact only debian-derived have it there afaik) to find something that is guaranteed to be in /bin is a little twisted, just ftr
<Chipaca> kalikiana, the question of why it isn't executable in the default apparmor profile is for jdstrand (i assume it's apparmor blocking this)
<Chipaca> kalikiana, optional modules sounds like something for the content interface
<kalikiana> Chipaca: fwiw "!/bin/sh" doesn't work either. I at one point got the impression that env would allow me to stop hard-coding executable paths - but then, if I don't know where env is, how can I possibly do that?
<Chipaca> kalikiana, wat
<Chipaca> kalikiana, #!, right?
<kalikiana> Yes, sorry, I typed it here by hand
<Chipaca> kalikiana, #!/bin/sh certainly should work
<kalikiana> It doesn't
<Chipaca> i mean, hello-world uses that
<kalikiana> lemme copy a script in there and try
<kalikiana> Hmmm it does indeed
<kalikiana> Is hello-world unconfined?
<kalikiana> Hmm no it's not according to "snap list"
<ogra_> kalikiana, any denials in syslog ?
<stokachu> jdstrand: re: the custom network bridge, normally I have a person install my debian package that sets up a systemd service with my bridge scripts, https://github.com/Ubuntu-Solutions-Engineering/openstack-deb, with the network-control interface am I able to do the same thing inside my snap?
<stokachu> minus the deb package of course
<kalikiana> ogra_: http://paste.ubuntu.com/23064305/ Several of the second one with different /proc/*/cmdline
<ogra_> mvo, do you mind if i switch it to "test -n" instead of '!= ""' ?
<arges> mvo: whats the status on verifying bug 1612362 ? I think the postrm purge issue was fixed in teh latest upload, but it just hasn't been verified yet?
<mup> Bug #1612362: [SRU] 2.12 <verification-needed> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1612362>
<kalikiana> ogra_: Chipaca Aha! It works if the script is in $SNAP_USER_DATA but not if it's in $HOME
<kalikiana> Despite having the 'home' interface
<ogra_> kalikiana, the first one tries to exec something outside of the snap without having an interface for it ... and for the second one there is an interface iirc
<ogra_> system-observe or some such
<ogra_> or process-observe ... i forgot the exact mname
<stokachu> is it possible to install a systemd service during snap install?
<ogra_> stokachu, snapd does that, based oon the info you give it in snapcraft.yaml
<ogra_> you cant randomly copy unit files in place though
<stokachu> ogra_: i basically want to convert https://github.com/Ubuntu-Solutions-Engineering/openstack-deb
<kalikiana> ogra_: the first one is 'home' isn't it? the same script can be opened and run by hand with "sh ./able"
<stokachu> ogra_: and have that bridge setup during install
<mvo> ogra_: sure, thats fine
<ogra_> stokachu, so creat bridge start and stop scripts and add app entries (with daemon line) into your snapcraft.yaml that points to them
<ogra_> kalikiana, home only allows file access ... not execution of random binaries ;)
<stokachu> ogra_: ok, will the bridge be uninstalled on snap remove?
<stokachu> as long as i have the stop app in there?
<mvo> arges: yeah, we just need to verify this one, the postrm changed got backed out again they will be properly fixed in the next upload
<mvo> arges: I will ask our QA team to do the verification
<kalikiana> ogra_: Hrm. Well, I could copy and run the same file - so I'm not sure I see the effective difference.
<ogra_> stokachu, not sure, thats a question for Chipaca i guess ... iirc we stop all services on removal though
<stokachu> ok
<ogra_> kalikiana, run ? how ?
<kalikiana> ogra_: As I said prepending "sh" or "python3" in case of Python works perfectly
<kalikiana> ogra_: Or copy and run as-is
<ogra_> that actually sounds like a slight security hole
<kalikiana> ogra_: How would executing the script only after copying it into $SNAP_USER_DATA be more secure?
<kalikiana> It certainly is inconsistent
<ogra_> well, the home interface only gives you access ... allowing the exec is a general thing when it happens inside the confined space
<ogra_> which home doesnt belong to
<kalikiana> I guess I should be symlinking my script folder into the snap?
<ogra_> i guess the home interface should block "sh $HOME/myscript.sh"
<ogra_> which is why i think there is a bug
<ogra_> jdstrand, ^^
<stokachu> how can i clear snapcrafts apt cache?
<ogra_> snapcraft clean
<stokachu> doesnt work :(
<ogra_> huh ?
<ogra_> that definitely wipes it
<stokachu> https://www.irccloud.com/pastebin/5eZy8hNO/
<stokachu> ogra_: ^
<zyga> Son_Goku: thanks for bumping bodhi tasks
<Son_Goku> zyga, you still need to make the updates for F24 and F25
<Son_Goku> I could do it, but I figured you'd want to
<Chipaca> stokachu, yes, systemd services are stopped on snap removal
<ogra_> stokachu, i see it running apt-get update there
<stokachu> Chipaca: cool thanks
<Chipaca> stokachu, asked to stop, then made to stop
<ogra_> stokachu, looks more like a server side issue
<stokachu> Chipaca: how will it know to run bridgestop on removal? https://www.irccloud.com/pastebin/saEdO7ro/
<ogra_> i.e. like the server is just regenerating its Packages file
<stokachu> ogra_: ok ill give it a few
<Son_Goku> zyga, by the way, you can change the positive karma number to be lower
<Son_Goku> I usually set positive karma to be "1" rather than "3" for new packages
<zyga> Son_Goku: ack, noted
<zyga> Son_Goku: I'll do that for subsequent updates
<ogra_> stokachu, i guess it will run both ... "bridge.start stop" and "bridge.stop stop"
<Chipaca> stokachu, stop-command and stop-timeout
<Son_Goku> zyga, you can edit the update in bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-2016-939c94b72e
<stokachu> Chipaca: do i need to set that somewhere?
<ogra_> stokachu, you should work it into a single script that understandds the systems start/stop events
<ogra_> *systemd's
<Son_Goku> zyga: https://bodhi.fedoraproject.org/updates/FEDORA-2016-c5556c3bef
<stokachu> ogra_: ah
<Son_Goku> there should be an edit button if you're logged in
<Chipaca> stokachu, without looking i don't remember; what happens if you try to stop without having that there?
<zyga> trying
<Chipaca> stokachu, in any case, you *can* set those, next to "command", you add "stop-command"
<Son_Goku> and you can modify the conditions of the update :)
<stokachu> Chipaca: actually haven't ran it yet :) waiting for apt packages to work again
<Son_Goku> as well as the update description and other things
<ogra_> Chipaca, well, he has one start service and one stop service ... and both will receive a stop event on uninstall
<Son_Goku> it's also possible to create updates from the bodhi web UI, which makes it easier to bundle a bunch of updates together in one update
<zyga> I see it, changed to stable karma: 1
<Chipaca> stokachu, having a stop service seems weird
<ogra_> Chipaca, so i guess he wants a single script that simply can handle start and stop so on uninstall only stop is called (and on install or reboot start is called)
<Chipaca> stokachu, i suspect it's not what you want
<ogra_> Chipaca, he wants the firewall settings the script applies system wide reverted on uninstall
<stokachu> Chipaca: ok, i was trying to port over https://github.com/Ubuntu-Solutions-Engineering/openstack-deb/blob/master/debian/openstack.service
<Chipaca> stokachu, that is, i suspect you want a single bridge: \n  command: bridge.start \n  stop-command: bridge.stop
<ogra_> yeah
<stokachu> ohhh
<zyga> Son_Goku: thanks :)
<Son_Goku> once you have snapd in Fedora, in the future when you update snapd and snap-confine at the same time, you can do it as a single update
<stokachu> Chipaca: this look correct? https://www.irccloud.com/pastebin/4PAbzoN3/
<zyga> Son_Goku: I'd like to merge those packages whenever we have a moment
<Chipaca> stokachu, maybe. Is "bridge.start" really a "simple", and not a "oneshot"?
<Chipaca> stokachu, if it does something and exits, and says it's a "simple", it'll get run again and again and again and again and again
<Chipaca> and again and again and
<stokachu> Chipaca: ah ok
<Son_Goku> zyga, so what do you need to get snapd in good shape?
<Chipaca> stokachu, and again :-op
<stokachu> Chipaca: :D
<zyga> Son_Goku: I need to figure out how to build against the macaroon before it ships in stable
<Son_Goku> build against rawhide for now
<zyga> Son_Goku: I'd like to simplify the package to strip the services that need permissions to be in fedora
<Son_Goku> everything is just there
<Son_Goku> when doing mock builds, just attach "-r fedora-rawhide-x86_64"
<Son_Goku> before the name of the SRPM
<zyga> Son_Goku: I need to fix systemd selinux as we talked about, that will eat most of my time I suspect
<zyga> Son_Goku: ok
<zyga> Son_Goku: thanks, I'll try that
<zyga> Son_Goku: I'll update COPR first so that I have a feeling for everything mostly working
<Son_Goku> once rawhide resyncs and the mirrors have your new builds, that should work
<zyga> Son_Goku: just having lunch now :) (mushrooms all week)
<Son_Goku> as for your copr, you can probably get away with deleting all the golang packages now
<Son_Goku> since they've all shipped to stable
<Son_Goku> so the only thing in your copr you'll need is the new golang package (macaroon), snap-confine, and snapd
<zyga> Son_Goku: yep, I was planning on doing that
<Son_Goku> though, if I give snap-confine karma, it'll just go through, probably :P
<zyga> Son_Goku: copr can stay for snap* packages but I doubt it will need much more
<zyga> heh :)
<zyga> (just do it ;)
<Son_Goku> technically, I need to wait for it to sync to updates-testing first
<Son_Goku> otherwise it won't get marked for stable when I give it karma
<stokachu> Chipaca, ogra_: this is the error im getting when attempting to install https://www.irccloud.com/pastebin/WbQ5M6Ke/
<Son_Goku> though, I think that might be fixed now...
<Son_Goku> I'll wait a few hours before doing it
<zyga> Son_Goku: sounds good
<zyga> Son_Goku: we can try the same for macaroon
<stokachu> Chipaca: do i need an actual systemd service file?
<Son_Goku> did you edit the macroon updates to require lower karma?
<zyga> mvo: quick question, are you busy now? I would like to do the snap-confine SRU with you to learn the process
<zyga> dSo	doing that now
<mvo> zyga: probably best we wait for the currently pending sru first, or we need to go back to the 7 day wait time
<zyga> Son_Goku: done
<zyga> mvo: noted
<mvo> zyga: but happy to do it once we have the next slot
<zyga> mvo: thank you!
<Chipaca> stokachu, no, you don't need a systemd service file
<stokachu> ok
<stokachu> i think i know whats wrong, i dont have /sbin/ip or /sbin/iptables in my snap
<ogra_> err
<ogra_> how would that work
<ogra_> you cant exec either of them
<Chipaca> stokachu, journalctl should tell you what to do
<Chipaca> stokachu, i mean, it should have a log
<Chipaca> stokachu, journalctl -u snap.conjure-up.bridge.service
<ogra_> stokachu, i assume thats the first install of the package ... where nnone of the interfaces are connected
<ogra_> so you cant have any access to /sbin/ip or /sbin/iptables
<ogra_> only after you connected the firewall interface that will work
<stokachu> Aug 17 12:40:21 riddick systemd[1]: snap.conjure-up.bridge.service: Service has Restart= setting other than no, which isn't allowed for Type=oneshot services. Refusing.
<ogra_> what you should do is to make the script exit gracefully here
<Chipaca> ahh, that also: if your services need interfaces to work, you need to make them handle not having the interface yet
<Chipaca> that is: if they need interfaces that don't auto-connect
<stokachu> yea im creating a custom bridge in the bridge.start script
<ogra_> (not sure if we allow snapd to show a message you can print from the script or some such)
<stokachu> so do i just need to add the firewall-control plug?
<zyga> stokachu: there's also network-control or something like that
<zyga> AFAIR
<stokachu> so far ive got network-control, network-bind, firewall-control
<ogra_> yeah, ip needs network-control, iptables needs firewall-control i guess
<ogra_> and i think neither of them is auto-connecting
<stokachu> do i still need to include those binaries directly?
<ogra_> i dont think so
<stokachu> and how do i handle the interfaces that aren't auto-connecting ?
<ogra_> but you need to use snap connect to connect them after install
<stokachu> is that left up to the user or can i do that in my snap installation?
<ogra_> and your script should check if it can exec the binaries and if not print a message and exit gracefuly
<ogra_> thats up to the user
<stokachu> so once the user does a 'snap connect' those oneshot scripts will be run again?
<ogra_> all dangerous interfaces are manual connect thingies
<ogra_> not sure, i think you might need to start it with systemctl
<stokachu> so this brings me back to is it possible to create and start a custom network bridge via snap install?
<ogra_> not without the user allowing access to the interfaces, no
<stokachu> ugh
<mup> PR snapd#1691 opened: many: add `snap download` command that downloads into /var/lib/snapd/download <Created by mvo5> <https://github.com/snapcore/snapd/pull/1691>
<ogra_> they need snap install ; snap connct ... and restart the services
<ogra_> *connect
<ogra_> s/restart/start/ ?
<ogra_> (not sure abot that one)
<stokachu> so that defeats my user experience
<stokachu> of just doing 'snap install conjure-up' and having everything work
<ogra_> yeah, not if you use interfaces that could potentially be harmful
<ogra_> we want the user to have full control here
<stokachu> but i define those plugs in my snapcraft.yaml
<ogra_> so such stuff will never auto apply
<stokachu> shouldnt that tell the user we want access to those interfaces?
<ogra_> sure, but they are not auto-connect interfaces
<ogra_> how would he know without looking at your source
<ogra_> i guess eventually there will be UI that asks
<ogra_> but thats not there atm
<stokachu> this is a huge blocker for me then
 * ogra_ imagines at some point snapd will do something like "the snap you install wants to access firewall control, do you want to allow it [Y/N]" during the install process
<ogra_> but thats further down the rodamap
<ogra_> so for now you need to tell your users to use snap connect to connect the interfaces
<stokachu> so where is this defined on the roadmap?
<stokachu> like when could i expect that to be implemented
<jdstrand> Chipaca: re env> no, in fact it is already allowed: /{,usr/}bin/env ixr,
<jdstrand> kalikiana: ^
<ogra_> stokachu, i'm pretty sure it isnt in the very near term roadmap ... there are to many other things to solve first
<stokachu> ogra_: can you reply to my email on snapcraft list then stating that?
<stokachu> b/c im going to be asked why i can't implement this software as a snap
<ogra_> stokachu, there is surely a way to ship your own apparmor profile and having your snap go through manual review for every upload though ...
<ogra_> for "trusted snaps" thats definitely a possibility
<stokachu> ogra_: but then im back to having to wait on someone else to approve it
<ogra_> yes
<stokachu> ogra_: might as well just do it the regular way
<ogra_> well, but the regular way is to tell your users to use snap connact $plug $interface
<stokachu> no the regular way i mean going through the debian process
<ogra_> and to restart the services that use them
<stokachu> one of the major points of doing a snap was so I didnt have to go through all those processing tasks
<stokachu> that's how it was told to us
<ogra_> well, the major point should still be that you are completely independent from the host system version :)
<stokachu> ogra_: that's fine but i dont remember you being at the sprint and hearing how it was told to us
<ogra_> well, i wasnt invited to the CDO sprint :)
<ogra_> perhaps you guys have worked out a way to allow "trusted snaps" to go through the store without manual approval
<ogra_> no idea about that one
<stokachu> ev ^
<jdstrand> stokachu: network-control allows you to set up the bridge. it does not allow you to add systemd units
<stokachu> is this something that you can flag so i don't have to go through a review process everytime?
<ogra_> i'm just telling you what every normal snap packager needs to go through ... there are surely special cases possible  for canonical maintained snaps
<jdstrand> stokachu: but, snappy gives you a systemd unit for every 'daemon: ...' command. so you can do that yourself
<ogra_> jdstrand, thats not the issue ... on first install the manual-connect interfaces wont be there
<stokachu> ogra_: right, well thats the issue of telling me im not a normal target case
<ev> stokachu: you can absolutely have a snap in devmode
<ogra_> so the systemd usints the snap creates wont run
<stokachu> ev: this doesn't work in devmode either
<stokachu> jdstrand: i responded to your email about where im at
<stokachu> jdstrand: there doesn't seem to be a way to allow a bridge to be started during a snap install
<morphis> jdstrand, zyga: I am wondering if we're doing anything to avoid apps in the same snap talking to each other over abstract unix sockets when I've installed the snap in devmode
<jdstrand> stokachu: (basically what ogra already said. /me is reading backscroll and just catching up)
<ogra_> jdstrand, stokachu is bothered about the manual connecting
<ogra_> (and having to manually start/restart the units then)
<zyga> morphis: no, in devmode apparmor won't be in the way
<zyga> morphis: do  you see anything odd?
<morphis> zyga: yes
<ogra_> i.e. there are two more steps after snap install
<morphis> zyga: but I am wondering if there is anything else but I saw snap-confine is just doing a clone(CLONE_NEWNS) and nothing else
<ogra_> stokachu, it doesnt work in devmode ? that would be a bug
<zyga> morphis: oh, interesting, i wonder if that affects abstract sockets
<stokachu> ogra_: no i still have to do those additional steps
<ogra_> in devmode interfaces shouldnt matter much
<morphis> zyga: I would say it doesn't as that is what CLONE_NEWIPC is for
<ogra_> right, file a bug about that
<zyga> morphis: that's good to know, thanks
<ogra_> devmode should make it behave not different from a deb in that regard
<jdstrand> kalikiana: 'home' interface gives you 'rwk', not 'i' (inherited exec) to non-hidden files in your home directory. this is by design
<morphis> zyga: if I am right CLONE_NEWNS is just the mount namespace
<zyga> morphis: and what do you observe in practice? no connection?
<jdstrand> kalikiana: but with an interpreted script, yes you get to run it, sure
<stokachu> ogra_: ok
<stokachu> ogra_: eventually i do need this to work in strict mode
<jdstrand> kalikiana: the home interface is transitional
<morphis> zyga: yes
<ogra_> stokachu, well, only after there is some UI then i guess
<morphis> zyga: https://paste.ubuntu.com/23064472/
<stokachu> ogra_: k thats fine, i can wait on that as long as devmode will work
<morphis> zyga: basically I am running an lxc container and trying to attach to it with lxc-attach
<ogra_> right ... you didnt talk about devmode above :)
<morphis> zyga: but the lxc_monitor process doesn't get connected to the abstract socket the container creates
<zyga> morphis: is that reproducible in a simpler test case?
<morphis> zyga: can create one
<stokachu> ogra_: i absolutely did talk about it, https://www.irccloud.com/pastebin/WbQ5M6Ke/
<zyga> morphis: if you can that would help, we could run in in snap-confine regression Ci
<morphis> zyga: sounds good
<jdstrand> morphis: we don't do CLONE_NEWIPC so abstract sockets should be ok
<morphis> jdstrand: good to know
<ogra_> stokachu, so the first one is clear there (the unit isnt there before installing so it can not be stopped) ... the second one says "invalid argument" ... perhaps an issue in the script ?
<stokachu> the error is from systemd unit
<kalikiana> jdstrand: Right, I see now how this works. In the long run I wouldn't even plan to use it, it was just the best I could think of - what I really need is the ability to execute other snaps that contain those scripts and toolchains
<stokachu> ogra_: Aug 17 12:40:21 riddick systemd[1]: snap.conjure-up.bridge.service: Service has Restart= setting other than no, which isn't allowed for Type=oneshot services. Refusing.
<stokachu> that is the error
<ogra_> stokachu, did you paste the "systemctl status snap.conjure-up.bridge.service" output above already ?
<morphis> jdstrand, zyga: maybe stgraber can help me, as they may ran into the same problem already with the lxd snap
<jdstrand> kalikiana: you might be interested in the content interface
<zyga> morphis: yep, try it
<seb128> ogra_, new livecd-rootfs uploaded to yakkety, I also changed the message to not recommend "snappy --help" but "snap --help" ;-)
<ogra_> stokachu, hmm, iirc that was a bug in old snapd ...
<stokachu> ogra_: https://www.irccloud.com/pastebin/PuwB6zeQ/
<ogra_> seb128, cool, sorry didnt get to push it to the PPA yet ... next on my list
<stokachu> ogra_: running snapd 2.0.10
<seb128> ogra_, no hurry, thanks!
<ogra_> stokachu, uuh
<ogra_> update :)
<jdstrand> morphis: I'd be interested in what you find out from stgraber
<morphis> jdstrand: will share with you :-)
<stokachu> ogra_: same error
<stokachu> running snapd 2.11+0.16.04
<stokachu> that service file is left behind do i need to manually remove it?
<ogra_> stokachu, well, it was fixed in 2.11
<ogra_>  - wrappers: map "never" restart condition to "no."
<kalikiana> jdstrand: Are there any docs I could check?
<ogra_> https://launchpad.net/ubuntu/+source/snapd/2.11+0.16.04
<stokachu> ogra_: so do i need to do anything special once upgrading snapd?
<ogra_> not that i know of
<morphis> stgraber: ping
<stokachu> ogra_: yea it's still failing
<jdstrand> kalikiana: all I know of it https://github.com/snapcore/snapd/blob/master/docs/interfaces.md, but you can also read tests/main/interfaces-content
<jdstrand> s/it/is/
<stokachu> ogra_ https://www.irccloud.com/pastebin/4KYGeCzl/
<jdstrand> kalikiana: basically one side exports a directory (or more) and the other side can import it if from the same publisher
<ogra_> stokachu, well, i dont know then
<ogra_> stokachu, perhaps Chipaca knows more ... (or someone else from the core team)
<stokachu> k
<stokachu> jdstrand: https://github.com/conjure-up/conjure-up/tree/patch-add-bridge-to-snap/snapcraft should this work in --devmode? or am I missing something?
<morphis> jdstrand, zyga: hm, looks like its not such a problem but more a relocation one
<mup> Bug #1610292 changed: Snap installed with --devmode can't use sudo <amd64> <apport-bug> <yakkety> <Snappy:Invalid> <snapd (Ubuntu):Invalid> <https://launchpad.net/bugs/1610292>
<jdstrand> stokachu: you need to use 'confinement: devmode' to install in devmode I think
<stokachu> jdstrand: even if i pass --devmode?
<jdstrand> ie, you need both sides-- the yaml to say it and to specify --devmode
<ogra_> jdstrand, if he uses --devmode on cmdline ?
<ogra_> i thought the commandline was mandatoory
<jdstrand> I thought that was what the design was. it wasn't always the case, but maybe it changed?
<jdstrand> the command line is mandatory
<jdstrand> what I'm saying is that I thought we changed to the yaml also being mandatory. maybe I'm misremembering
<jdstrand> stokachu: it is easy to see if you are in devmode. what does 'sudo aa-status' say about the apparmor profile? if in devmode, it should show the apparmor profile in complain mode
<stokachu> jdstrand https://www.irccloud.com/pastebin/nPRjExPU/
<jdstrand> stokachu: but to answer your question-- I would expect that yaml ('confinement' notwithstanding) to work once the snap is installed in devmode, yes
<stokachu> it's still giving me the same systemd error about Restart=
<jdstrand> so yes, you are in devmode
<stokachu> Aug 17 13:53:25 riddick systemd[1]: snap.conjure-up.bridge.service: Service has Restart= setting other than no, which isn't allowed for Type=oneshot services. Refusing
<stokachu> how can i see what that service file looks like?
<jdstrand> I don't know what that error is, but I'm also not the one who implemented the systemd part
<jdstrand> stokachu: /etc/systemd/system
<stokachu> https://www.irccloud.com/pastebin/kfc74oFx/
<stokachu> ogra_ ^
<jdstrand> stokachu: see my email to the list. I think you want to leverage the hooks work. aiui, that will restart the service after interface connect
<stokachu> jdstrand: ah ok
<jdstrand> I've not used it or even looked at it yet though
<jdstrand> let me see if I can fine the PR
<stokachu> the very least oneshot shouldn't have restart=on-failure i would think
<stokachu> should just run and fail or succeed
<jdstrand> it seems like there are many PRs in this area and that kyrofa is involved in many of them
 * kyrofa jerks awake
<jdstrand> stokachu: that sounds like a very reasonable request
<jdstrand> kyleN: context is stokachu has a systemd unit that he wants to run when interfaces are connected
<stokachu> https://github.com/snapcore/snapd/blob/da9fa3774fcf56464dc3d8446f47b2c1eb3943e0/tests/lib/snaps/data-writer/meta/snap.yaml can i set that restart-condition in snapcraft.yaml?
<jdstrand> and I thought that work has been done in this area
<kyrofa> jdstrand, stokachu ah interesting, we were just discussing interface hooks
<sergiusens> kyrofa indeed I am
 * zyga plays with snapd 2.11 on fedora :)
<jdstrand> stokachu: yes, see docs/meta.md. specifically: `restart-condition`: (optional) if specified, use the given restart condition. Can be one of `on-failure` (default), `never`, `on-success`, `on-abnormal`, `on-abort`, and `always`. See `systemd.service(5)` (search for `Restart=`) for details.
<ogra_> zyga, and who wins ?
<stokachu> jdstrand: lemme try that
<arges> zyga: bugs 1612120 1612291 1612684 : are these fixed in yakkety?
<mup> Bug #1612120: $SNAP_USER_DATA is no longer created by snap-confine but is not yet created by snapd <verification-done> <Snappy Launcher:Fix Committed by zyga> <snap-confine (Ubuntu):Confirmed> <snap-confine (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1612120>
<jdstrand> kyleN: sorry, that was for kyrofa
<kyleN> ack
<stokachu> jdstrand: so the interface hooks can be run after a snap connect?
<stokachu> kyrofa: ^
 * jdstrand defers to kyrofa 
<zyga> ogra_: everyone!
<zyga> arges: let me check
<ogra_> hah
<kyrofa> stokachu, that's the idea, but they're still in the design phase
<stokachu> ok
<jdstrand> kyrofa: curious if you might do 'restart-condition: on-interface-connect' which would (perhaps) set 'never' and then on connect something else (though people still might want to set what that something else is, so not this exactly)
<kyrofa> stokachu, all of the hook work so far has been the underlying machinery for hooks, not the hooks themselves
<zyga> arges: no, although all of them are fixed in master; I will release snap-confine soon and ask mwhudson and slangasek to upload that
<stokachu> so I got my snap to install now with restart-condition: never
<stokachu> what are the steps to manually bring up the bridge now?
<stokachu> snap connect conjure-up:firewall-control?
<jdstrand> snap connect conjure-up:firewall-control ubuntu-core:firewall-control
<ogra_> snap connect conjure-up:firewall-control ubuntu-core:firewall-control
<jdstrand> (do that for each manually connected interface
<ogra_> *snap*
<arges> zyga: ok great, once that's done we cna get that released then start processing the next snap-confine in teh queue
<ogra_> :)
<jdstrand> then restart the unit
<kyrofa> stokachu, can you explain your use-case a little? What is the service you want to fire up upon interface connection?
<ogra_> jdstrand, zyga, we should really not require the ubuntu-core: by default imho
<jdstrand> stokachu: some day simply: s/ubuntu-core:firewall-control/:firewall-control/
<jdstrand> it's know
<stokachu> kyrofa: https://github.com/conjure-up/conjure-up/tree/patch-add-bridge-to-snap/snapcraft
<jdstrand> known
<ogra_> "snap connect conjure-up:firewall-control firewall-control" should understand that i mean the system level interface
<stokachu> jdstrand: ok
<ogra_> ah
<stokachu> kyrofa: i have a custom lxd bridge i want to start when someone runs snap install conjure-up
<stokachu> or snap connect i guess in this case
<zyga> arges: yep, I'll release upstream in a moment
<kyrofa> stokachu, is that actually a long-running service though?
<zyga> arges: I just wanted to test it on fedora
<stokachu> kyrofa: nah it just a oneshot to setup the bridge
<kyrofa> Or just "something that needs to happen upon connection"
<jdstrand> ogra_: aiui, the design is :firewall-control such that if the snap is not specified, use an implied core snap interface
<stokachu> yea just on connection i think
<kyrofa> stokachu, ah, then we can ignore the systemd side completely and you can just implement a normal interface hook as soon as we have them
<arges> zyga: cool
<stokachu> kyrofa: ok cool, that still in design phase though?
<ogra_> jdstrand, fine as well i guess
<kyrofa> stokachu, just so you have it in the back of your mind: hooks go in meta/hooks/ (snapcraft will expose this soon). They are named according to their purpose, in your case, perhaps something like <interface>-connect and <interface>-disconnect
<jdstrand> ogra_: zyga may even have a branch floating around. I don't know if there is a bug
<kyrofa> stokachu, they'll be called by snapd just by being named correctly
<stokachu> kyrofa: ah nice
<jdstrand> kyrofa: curious, how does that work if you need two interfaces connected to work?
<kyrofa> stokachu, you can just put your scripts in there
<jdstrand> kyrofa: or does your script logic need to account for that
<jdstrand> ?
<kyrofa> jdstrand, the logic will likely have to account for that, interfaces aren't all connected up at one time anyway
<stokachu> would it also be possible to turn on ip forwarding in those scripts?
<stokachu> or is that left up to the user
<kyrofa> stokachu, if the scripts need plug, then you can declare them in the YAML requesting them
<kyrofa> stokachu, so assuming you have a plug that lets you do that
<stokachu> ok
<stokachu> kyrofa: is there a plug that will let me do that? :)
<kyrofa> stokachu, heh, I must bounce you back to the venerable jdstrand
<kyrofa> jdstrand, I'd like to hear about the use-case you had in mind about the multiple interfaces thing though
<jdstrand> kyrofa: I don't see documentation on these hooks in meta.md or anywhere else in docs/. Can we add that there? is this documented somewhere else?
<sergiusens> kyrofa can you quickly check my comment on snapcraft/733
<sergiusens> ?
<kyrofa> jdstrand, not yet-- everything that has landed so far is all machinery that is completely transparent to the end users
<jdstrand> kyrofa: well, it is actually stokachu's. he plugs both network-control and firewall-control. that would be common for a router too.
<kyrofa> jdstrand, and the same thing needs to happen upon connection/disconnection for both interfaces?
<jdstrand> stokachu: firewall-control lets you set ip forwarding
<jdstrand> kyrofa: well, it is more that "there is no point starting anything until both these things are connected" kind of thing
<stokachu> jdstrand: ok cool
<kyrofa> sergiusens, sure, if you'd learn to ref them right so I can click on a link: snapcraft#733 maybe
<mup> PR snapcraft#733: Add the go-buildtags property to the go plugin <Created by elopio> <https://github.com/snapcore/snapcraft/pull/733>
<kyrofa> jdstrand, stokachu so does a service need to be started as a result of the interface connection, then?
<kyrofa> I thought we determined no
<stokachu> for me its just a oneshot type of thing
<stokachu> runs a couple of commands to create a network bridge
<stokachu> then removes it on uninstall
<kyrofa> stokachu, no coordination needed between interfaces?
<jdstrand> kyrofa: I can imagine a scenario for this, yes
<stokachu> kyrofa: just as long as I have access to `ip` and `iptables` commands
<stokachu> so they can be connected in any order
<kyrofa> jdstrand, yeah, running a service based in hooks isn't something I had considered
<ogra_> seb128, livecd-rootfs uploaded ... i'll trigger a new ubuntu-core for the edge channel once it built
<seb128> ogra_, thanks!
<kyrofa> stokachu, good deal, you should be set as soon as this stuff lands. Keep an eye on pstolowski, he's starting to work on those
<stokachu> kyrofa: ok sweet!
<jdstrand> kyrofa: as implemented, how I would probably do thing is in the <interface>-connect commands I would create a config file. eg, foo-connect creates SNAP_DATA/config FOO_CONNECTED=yes. bar-connect add BAR_CONNECTED=yes. then my daemon: oneshot script looks at SNAP_DATA/config and chooses to run or not
<stokachu> kyrofa, jdstrand: this is how i would get this to work today https://www.irccloud.com/pastebin/XyWnLsQi/
<jdstrand> kyrofa: but that requires a lot of work on my end
<jdstrand> kyrofa: something in the yaml that say 'just don't run if all the interfaces aren't connected' would be great for this sort of thing
<kyrofa> jdstrand, right now the oneshot would run upon install, probably fail dramatically, and then your hooks would run when the interfaces were connected. We need some logic to ask the service to fire back up
<kyrofa> jdstrand, yeah that seems fair
<jdstrand> stokachu: fyi, network-bind is autoconnected
<kyrofa> jdstrand, and doable, I think. Even today, ignoring hooks
<stokachu> jdstrand: ah ok
<kyrofa> jdstrand, might be worth a bug or a ML thread about that, if we can get it designed in the YAML I don't think the implementation would be that difficult.
<jdstrand> I think setting ip forwarding also makes sense for network-control. /me adds a todo
<kyrofa> jdstrand, but I don't think it involves hooks
<jdstrand> if it was in the yaml, right-- wouldn't need an hooks
<jdstrand> the hooks is just a way to get there today
<kyrofa> jdstrand, snapd keeps internal track of what plugs are connected. It just needs to know to fire the service up if they're all green
<kyrofa> jdstrand, yeah, hooks are not there today I'm afraid
<kyrofa> jdstrand, lots of things have landed, as you noted, but they're not usable just yet
<jdstrand> kyrofa: oh, do you mean meta/hooks/firewall-control-connect doesn't work today?
<kyrofa> jdstrand, indeed
<jdstrand> I thought I heard you say it did
<jdstrand> ah
<jdstrand> ok
<kyrofa> jdstrand, ah, I'm sorry for misleading you! No: the machinery behind hooks is very nearly complete. But the hooks themselves are a different story
<kyrofa> jdstrand, it's like the machinery behind interfaces versus the interfaces themselves
<stokachu> ah i can't just run systemctl restart snap.conjure-up.bridge.service since those $snap vars aren't set
<stokachu> do i need to execute that with snap run?
<kyrofa> stokachu, hmm... they should be
<kyrofa> stokachu, check the unit file, they should all be defined right thre
<jdstrand> kyrofa: gotcha, no worries
<ogra_> yeah, in the environment
<stokachu> ah ok they are
<ogra_> (i think theyx had them in the paste you showed me)
<stokachu> ah ok it's just not configuring my interface
<kyrofa> stokachu, note that you should never need to use `snap run`. Soon it will be used instead of all that environment in the unit file, but it'll just be run by the unit (or by the files in /snap/bin)
<stokachu> i need to include both sbin/ip and sbin/iptables into my snap?
<stokachu> kyrofa: ack
<bergkatten_> Just read: "Your first snap" :)
<bergkatten_> Is there any way for a newby to create own snap repo on localhost?
<ogra_> bergkatten_, wekll you can just "snap install /path/to/snap"  ... why waste effort and time for a repo
<ogra_> (there are ways to run local snap stores, but that will lack features vs the real store (unless you implement them))
<ogra_> see https://uappexplorer.com/app/snapstore-example.noise for a snapstore snap :)
<bergkatten_> would like create an internal store with not so public inhouse packages
<mreed> nessita, ping
<ogra_> noise][, you should link a howto from the description ^^^ iirc there is an env var needed to make snapd use your store ?
<noise][> https://github.com/noise/snapstore
<nessita> mreed, hi
<ogra_> bergkatten_, ^^
<mreed> nessita, hi :-)  by chance can you review my snap? https://myapps.developer.ubuntu.com/dev/click-apps/5726/rev/1/
<zyga> Pharaoh_Atem: https://bugzilla.redhat.com/show_bug.cgi?id=1367825
<zyga> Pharaoh_Atem: feel free to request dropping of systemd units
<zyga> Pharaoh_Atem: or for the presets at least
<Pharaoh_Atem> the units are fine
<zyga> Pharaoh_Atem: I figured it is better to have you do a review first before I go around and strip everything
<Pharaoh_Atem> it's the presets that are an issue
<Pharaoh_Atem> one sec
<zyga> Pharaoh_Atem: sure, I'm happy to remove those
<nessita> mreed, looking. So your snap does not provide any binary at all?
<mreed> nessita, it should generate a dbench binary
<mreed> nessita, I am not sure if I have that set up correctly
<nessita> mreed, seems like is not? the review failed with
<nessita> Could not find compiled binaries for architecture 'amd64' lint-snap-v2_architecture_specified_needed (amd64)
<nessita> elopio, do we have any documentation on the above, or who would be the best person to assist mreed?
<kyrofa> nessita, I got it. mreed, can I see your YAML?
<mup> Bug #1613971 opened: using oneshot results in failed service <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1613971>
<mreed> kyrofa, sure
<bergkatten_> ogra_: tnx, testing it on my machine
<nessita> kyrofa, oh thank you! kyle to the rescue
<kyrofa> mreed, feel free to ping me directly if it's not public, by the way
<mup> Bug #1612909 changed: Unable to install snappy in Fedora <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1612909>
<mup> Bug #1614134 opened: need a way to start daemon only if all interfaces are connected <Snappy:New> <https://launchpad.net/bugs/1614134>
<ogra_> mvo, so wheer is that branch you talked about above (to not make snap_kernel/_core being unset if only one is upgraded) was that a snapd change ?
<ogra_> i dont see any change in snappy-hub
<ogra_> mvo, also, you probably want the fixes from seb128 for xdg-open and friends that i just pushed to the PPA in your promoted ubuntu-core
<ogra_> since they affect classic directly
<Pharaoh_Atem> zyga: I left a comment on the snapd review
 * ogra_ is waiting for the PPA publisher to actually release the change before triggering a new ubuntu-core
<zyga> Pharaoh_Atem: thanks, looking
<mvo> ogra_: its a snapd fix
<ogra_> ah, k
<mvo> ogra_: cool, yeah, once the other fix lands I can do new images
<ogra_> ok, publisher done, building a new ubuntu-core
<jdstrand> kyrofa: ok, fyi bug 1614134
<mup> Bug #1614134: optionally start daemon only if all interfaces are connected <Snappy:New> <https://launchpad.net/bugs/1614134>
<jdstrand> that took longer than I expected to capture
<kyrofa> jdstrand, that's lovely, thank you for taking the time!
<jdstrand> np
<jdstrand> mvo: hi! https://github.com/snapcore/snapd/pull/1598 should no longer have the Blocked tag. I think Reviewed should be reviewed too so a snappy team member can review it (I +1'd it)
<mup> PR snapd#1598: interfaces: implement a fuse interface <Reviewed> <Created by stgraber> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1598>
<jdstrand> mvo: oh
<jdstrand> nm
<mvo> jdstrand: :)
<jdstrand> mvo: but that actually brings up the question on these labels
<jdstrand> mvo: are how they are used by the team documented somewhere?
<jdstrand> mvo: (I can't change them, which is ok, but I don't know when to ask for them to be removed)
<mvo> jdstrand: not sure if they are documented. can you add/remove them? if so, feel free to adjust as needed, i.e. when you are done and its no longer blocked, jus trmeove it
<jdstrand> (or added)
<mvo> jdstrand: yeah, I think niemeyer needs to add you so that you can edit the labels, I think you should definitely be able to do that
<niemeyer> Huh.. I'd expect that to be the case already
<niemeyer> jdstrand: Try now..
<niemeyer> jdstrand: You were not in the committers team, which is an error on my end
<jdstrand> niemeyer: I have a gear icon now
<jdstrand> thanks!
<niemeyer> It's a bit funny that this is the case..
<niemeyer> Why would people need write access to the repository just to be able to change a label on an issue?
<jdstrand> yeah, those seem quite different things indeed
<niemeyer> jdstrand: I mean, you should have write access regardless, but I can see many other cases where simply having the person as part of the project should be enough
 * jdstrand nods
<jdstrand> I also find it curious that some things in the githug interface update without a reload, but others do not
<jdstrand> haha, githug
<jdstrand> github*
<jdstrand> eg, Open -> Merged. why does that need a reload?
 * jdstrand shrugs
<sergiusens> jdstrand I see your are now showing the love for git ;-)
<jdstrand> apparently :)
<jdstrand> seriously though-- I really like git's branching
 * zyga is stuck on %patch0
<zyga> Pharaoh_Atem: want to help me figure out why a patch (which works perfectly fine) doesn't apply with %patch0 -p1
<mup> PR snapd#1691 closed: many: add `snap download` command that downloads into /var/lib/snapd/download <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1691>
<Pharaoh_Atem> zyga: fuzz is zero by default
<Pharaoh_Atem> if you need a different fuzz value, you'll need to override it
<zyga> no, the patch should apply perfectly
<zyga> I have no idea why it behaves this way
<mup> PR snapcraft#718 closed: Fix bug lp:1586546 allowing setup.py to work on some projects <Created by blakerouse> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/718>
<zyga> I unpacked the tarabll, git added everyting
<zyga> tweaked one line and exported the commit
<zyga> the same tatics worked with snap-confine
<zyga> why does pastebin doesn't work on fedora
<bergkatten_> noise, I have snapstore on my localhost:5000 :) is there a builtin way to control who can access it?
<noise][> bergkatten_: nope!
<noise][> it's super dumb and simple :)
<noise][> no batteries included
<bergkatten_> true :)
<mup> PR snapcraft#682 closed: Extending the created yaml from `snapcraft init` <Created by wandrewkeech> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/682>
<mup> PR snapcraft#727 closed: Add a new build plugin 'shell' that runs arbitrary shell commands <Created by Magical-Chicken> <https://github.com/snapcore/snapcraft/pull/727>
<zyga> Pharaoh_Atem: http://paste.ubuntu.com/23064997/
<zyga> Pharaoh_Atem: the actual patch is http://paste.ubuntu.com/23065021/
<Pharaoh_Atem> you really should move those service files and stuff
<zyga> Pharaoh_Atem: snap-confine is done, snapd is next
<zyga> Pharaoh_Atem: perhaps I should just ship them separately for now
<zyga> Pharaoh_Atem: this is how the build fails http://paste.ubuntu.com/23065052/
<Pharaoh_Atem> what happens when you run patch with fuzz=0 by hand?
<Pharaoh_Atem> does it work?
<Pharaoh_Atem> it should fail
 * zyga checks
<zyga> it works okay
<zyga> I suspect there's something in how I run %setup that makes it broken
<zyga> but I cannot guess what, catting the file just before %patch showed expected content
<qengho> What's the state of snappy on a rasp pi 3 these days? I'd like to have snappy on classic, if possible.
<ogra_> not sure there are classic pi3 images beyond the mate ones (which arent really official)
<qengho> http://cdimage.ubuntu.com/ubuntu/releases/16.04/release/ubuntu-16.04-preinstalled-server-armhf+raspi2.img.xz
<ogra_> we have pi3 all-snap images in the works though ... just follow mvo's instructions from the ML and use the ubuntu-device-flash snap
<ogra_> qengho, i doubt that has a pi3 uboot
<ogra_> (kernel and rootfs should work though )
<zyga> Pharaoh_Atem: I'll ignore the patch, I have no idea why it fails
<zyga> Pharaoh_Atem: I'll just copy the service file into the package
<Pharaoh_Atem> yeah, you could have distro specific service files as extra sources and just copy them in that way
<zyga> Pharaoh_Atem: I'll use a patch for now (hopefully a patch to a new file will work ok)
<zyga> Pharaoh_Atem: I'll work on fixing this upstream next
<zyga> Pharaoh_Atem: and perhaps they will be required for selinux later on
<Pharaoh_Atem> yeah
<Pharaoh_Atem> by the way, if you want to shortcut on patch application, you can use %autopatch -p1
<Pharaoh_Atem> or use %autosetup -p1 in place of %setup
<Pharaoh_Atem> if you'd rather have git apply the patches, you can use -S git instead of "-p1" and add "BuildRequires: /usr/bin/git"
<zyga> yep, that worked
<zyga> yeah, I know about autosetup :-) I remember hrw blogging about it
<Pharaoh_Atem> %autosetup / %autopatch will apply the patches in the order listed in PatchXX
<Pharaoh_Atem> hrw blogged about it after I asked about because I didn't know about it :P
<zyga> my goal as both upstream and pacakger is to have less patches :)
 * zyga is so cold today
<zyga> it's raining *again*
<Pharaoh_Atem> it's 81F/27C here and partly cloudy with no rain
<zyga> it's probably around 10C now
<zyga> and windy
<zyga> *holidays* :D
<zyga> Pharaoh_Atem: one more fix and I will ask you for a re-review
<Pharaoh_Atem> okay
<Pharaoh_Atem> by the way, don't forget to file a bug against fedora-release: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=fedora-release
<zyga> yep, I'll do that shortly
<zyga> where should I upload patches that go along my spec files?
<Pharaoh_Atem> that's why you make SRPMs :)
<Pharaoh_Atem> so that people can download everything and look at it
<Odd_Bloke> I'm trying to switch from the copy plugin to the dump plugin, and I'm getting: "[Errno 39] Directory not empty: '/root/parts/git-deps/install'" just after Building starts.  What does this mean?
<zyga> Pharaoh_Atem: ah
<zyga> right :)
<zyga> uploading -5 srpm now
<Odd_Bloke> sergiusens: (Perhaps you can help with my above question?)
<Odd_Bloke> OK, I've shelved fixing that, now I'm just trying to release what I have.
<qengho> ogra_: What's with the "sudo" in every ubuntu-device-flash execution I've ever seen?
<Odd_Bloke> I've done a `snapcraft push --release edge <file>` but I'm now getting "- Download snap "git-deps" (1) from channel "edge" (received an unexpected http response code (401) when trying to download https://public.apps.ubuntu.com/download-snap/MlfzKnSBHbOsx7wuOxnTsflAEQEU3mjA_1.snap)" when I run `snap install --edge git-deps`.
<Odd_Bloke> Is there a step I'm missing to make this publicly available?
<Odd_Bloke> (And, also, I think I'm logged-in, so shouldn't I be able to install it regardless?)
<mup> PR snapcraft#695 closed: Add process-dependency-links option to Python plugins <Created by OddBloke> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/695>
<mup> PR snapcraft#734 opened: python plugins: add process-dependency-links option <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/734>
<mhall119> zyga: where are the docs for defining a plug using an interface with parameters?
<sergiusens> Odd_Bloke hey, speaking of the devil, was just refactoring to get your constraints stuff in
 * sergiusens reads
<sergiusens> Odd_Bloke means you want to wait for 2.15 (or use master) wrt dump/copy
<sergiusens> Odd_Bloke 401 probably means you need to `sudo snap install` or to login
<zyga> mhall119: I don't think there are any
<zyga> mhall119: I'm looking at updating the docs as we discussed but I didn't get around to do it yet
<dobey> how can i found if an installed snap package is removable or not?
<sergiusens> qengho sudo ubuntu-device-flash because kpartx
<dobey> err, s/found/find out/
<dobey> also, where does the value for "series" come from exactly?
<dobey> since it doesn't appear to match what's in /etc/lsb-release exactly
<mhall119> zyga: can you give me a quick example of how to define a plug for my arduino snap that passes a path to the "serial-port" interface?
<zyga> mhall119: serial port has no attribute on the plug side, only on the slot side
<zyga> mhall119: currently there is no way to use the serial-port on classic distributions
<zyga> mhall119: technicaly the syntax requires the extended form of slot definition, you can see how it looks like here:
<zyga> https://github.com/snapcore/snapd/blob/master/interfaces/builtin/serial_port_test.go#L53
<mhall119> zyga: ok, so I want to help fix serial-port on classic desktops, where does that work need to be done, in snapd or in ubuntu-core snap?
<zyga> mhall119: it's not broken, there's no definition on how it would work on classic today; that's definitely snapd but also udev and other parts, definitely would require major features to support
<zyga> mhall119: sorry :/
<zyga> mhall119: this is the dynamic slot problem, we have no solution for that, either in snapd or in a 3rd party snap today
<mhall119> so, not as simple as just adding /dev/ttyS* to a snap's apparmor profile?
<zyga> no
<zyga> that's not a solution, that's equivalent to --devmode
<zyga> just use devmode for now
<mhall119> but devmode makes it harder to get from the store
<sergiusens> dobey maybe this can help https://github.com/snapcore/snapd/blob/master/docs/rest.md#v2system-info
<mhall119> at least with an interface the user could just connect it manually after install
<zyga> mhall119: there's no such interface today
<mhall119> how is serial-port used today then? Only with gadget snaps?
<dobey> sergiusens: ah thanks. what about determining if a package is removable or not? getting the details for ubuntu-core doesn't seem to show any value which would relate to being removable
<zyga> mhall119: you could define a "all-serial-ports" interface or something but please discuss this with jdstrand, the problem is really dynamic plug/slot that has no support in snapd today, then you have to bridge this with monitoring hardware events (perhaps in snapd, perhaps in something that talks to it) and connect/disconnect, etc
<zyga> mhall119: nobody is using it today in classic
<zyga> mhall119: it was designed for all-snap systems
<zyga> mhall119: and there it only supports static devices
<mhall119> jdstrand: ping, see above, I'd like to help make serial ports available to confined snaps
<mhall119> popey: ^^ might be more complicated than we though
<zyga> mhall119: jdstrand won't change the facts I menitoned above, this is not even designed yet
<mhall119> s/might/definitely/
<zyga> mhall119: security side is easy (you got it right actually) but it's not the security that is the problem
<sergiusens> dobey that is a more complicated question; the only thing I can think of is checking the model assertion, I would delegate this question to mvo
<popey> aww
<mhall119> zyga: what specifically is the problem?
<sergiusens> dobey my plain gut reaction is, if type == app then it is removable (unless stated by the model that it shouldn't)
<sergiusens> popey why?
<zyga> mhall119: as i said above, snapd doesn't have any support for dynamic slots or plugs yet
<mhall119> zyga: btw, this is me dogfooding community contributions to interfaces, so please forgive all the questions
<zyga> mhall119: so nothing can monitor the hardware
<jdstrand> mhall119 (cc zyga): fyi, there is some work in this area with https://github.com/snapcore/snapd/pull/1669
<mup> PR snapd#1669: interface: add usb device support to serial-port <Created by jocave> <https://github.com/snapcore/snapd/pull/1669>
<zyga> mhall119: so nothing can react to serial port hardware being pulugged and unplugged
<zyga> mhall119: etc etc etc
<popey> sergiusens: my awww was @ mhall119
<jdstrand> I haven't reviewed it all yet and it hasn't gone through the interfaces team yet, so, just fyi
<jdstrand> I plan on looking that this afternoon
<sergiusens> popey ah :-)
<zyga> jdstrand: that's just a hack IMHO, I don't see any serious attempt at fixing this yet
<sergiusens> kyrofa or josepht mind looking at https://github.com/snapcore/snapcraft/pull/734 ?
<mup> PR snapcraft#734: python plugins: add process-dependency-links option <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/734>
<zyga> jdstrand: it is equivalent to just doing "gimme all /dev/ttyUSB* + a few others"
<zyga> jdstrand: at least IMHO, I always assumed snapd will do device discovery like udev
<sergiusens> kyrofa josepht the commit made by myself only if tight on time ;-)
<dobey> sergiusens: hmm, i'm looking for something approximately equal to the "_removable" field in the click manifest of an installed package
<mhall119> zyga: if it's not auto-connected, is it so bad?
<zyga> jdstrand: if snapd had an api for dynamic plugs and slots one could write a snap that exposes serial ports by looking at netlink
<jdstrand> zyga: re discovery, sure. when we hung out I said mentioned this shouldn't conflict with that
<jdstrand> but I've not looked at the implementation yet
<zyga> mhall119: I'm not sure this is related
<zyga> mhall119: what is needed is design decision
<zyga> mhall119: there are many ways to get it to "work"
<zyga> mhall119: depending on how you want to evolve snapd and how plugs and slots and interfaces are expected to work
 * jdstrand -> food
<dobey> sergiusens: hmm, should i file a bug maybe? it seems like for a fully snap based system we'll want to be able to flag certain snaps as not removable, beyond the base os snap, including some apps/scopes perhaps
<ogra_> i thought thats a feature of the seed.yaml
<ogra_> (though thats just an assumption)
<sergiusens> dobey yes, that would be controlled by the model assertion, but an api to query would be good
<dobey> ok
<mup> PR snapcraft#733 closed: Add the go-buildtags property to the go plugin <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/733>
<mup> Bug #1614212 opened: Invalid character in ubuntu-core mount name breaks etckeeper <Snappy:New> <https://launchpad.net/bugs/1614212>
<mhall119> zyga: jdstrand: if I'm reading this diff right, it will allow snap apps to connect to pre-defined paths like /dev/ttyS0 if the core snap provides a slot for it, or it lets the snap connect to a device by vendor/product id without it having to be defined in the core snap, both of which seem like good approaches to me at least, and would allow for my use case
<zyga> mhall119: the core snap will never provide this slot
<mhall119> zyga: then I can use the vendor/product id for arduino boards
<mhall119> which doesn't require a pre-defined slot, if I understand this patch
<sergiusens> josepht this needs updating https://github.com/snapcore/snapcraft/pull/705
<mup> PR snapcraft#705: parser - Remove namespacing and subparts <Created by josepht> <Conflict> <https://github.com/snapcore/snapcraft/pull/705>
<josepht> sergiusens: yeah, I'm working on improving the coverage, should be ready soon.
<sergiusens> josepht sounds good :-)
<mup> PR snapd#1692 opened: asserts: add serial-proof device assertion <Created by matiasb> <https://github.com/snapcore/snapd/pull/1692>
<dobey> elopio: are you "Leo Test" ?
<flyingHorde> Hey all
<flyingHorde> is there anyone here ?
<flyingHorde> I wanted to ask about deduplication
<flyingHorde> We can use hash algorithms for all binaries, store them in central folder with the hash as their file name and use hard link from that folder to the isolated folder of the application
<mup> PR snapcraft#664 closed: New plugin: Script (runs bash scripts) <Created by monsterjamp> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/664>
<ssweeny> zyga, you left a comment in my udisks PR that /media is bind-mounted with snap-confine. How can I be sure I'm using snap-confine with my snaps? I have ubuntu-core 16.-4.1 rev 230 on my raspberry pi right now and I'm still getting "read-only filesystem" errors
<stgraber> jdstrand: I posted a generic-ish response to the bug. Would be good to have him confirm that he's in devmode (so no blocked syscalls or sendmsg being denied by confinement) and ideally get an strace to confirm that he did manage to grab a handle to the right netns
<stgraber> jdstrand: in theory, so long as you can open /proc/PID/ns/net, you should be able to setns into the network namespace of the task (you need to be root or also attach to the user namespace first) and the netlink interface to move devices between network namespaces is supposed to use the same check in kernel
<stgraber> jdstrand: what typically gets in the way is: being able to actually see and open the handle, being allowed to call the right syscalls and having the right capabilities (at least net_admin but I suspect sys_admin too)
<zyga> ssweeny: do you have /usr/lib/snap-confine?
<zyga> ssweeny: snap-confine aka ubuntu-core-launcher is used by all snaps
<ssweeny> zyga, nope
<ssweeny> though I do have /usr/share/doc/snap-confine
<ssweeny> so some version of it should be installed
<zyga> ssweeny: I bet you have snap-confine or ubuntu-core-launcher (u-c-l is the old name)
<zyga> ssweeny: I don't know which version you have though, sorry
<ssweeny> zyga, is there some other way I can test with snap-confine?
<zyga> ssweeny: ion classic systems you can have reasonably up-to-date snap-confine
<zyga> ssweeny: the core snap is built automatically too but probably in the non-stable channel
<ssweeny> zyga, the core snap I'm using id from the edge channel
<zyga> ssweeny: on an all-snap system /media is always read only
<zyga> ssweeny: my remark was for classic
<qengho> What means "all-snap"?
<ssweeny> ah
<zyga> ssweeny: I'm sorry
<zyga> qengho: a distribution that is meade entirely from snaps
<ssweeny> zyga, is that a deliberate choice or just that no one's come up with a compelling reason to do otherwise yet? :)
<jdstrand> stgraber: thanks for the feedback. I'm going to play with it a bit and may have some other questions
<zyga> ssweeny: on an all-snap image everyting is comprised of snaps, there are very few writable "holes", /media is not one of them;
<sergiusens> elopio is this bad news https://github.com/snapcore/snapcraft/pull/734 ?
<mup> PR snapcraft#734: python plugins: add process-dependency-links option <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/734>
<sergiusens> elopio the immediate fail?
<ssweeny> zyga, fair enough
<sergiusens> kyrofa mind adding your resulting discussion to https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1607459 and mark the bug appropriately?
<mup> Bug #1607459: type:os should prevent adding "confinement" to the snap.yaml <Snapcraft:Triaged by kyrofa> <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1607459>
<ssweeny> zyga, related question: I recently noticed that trying to mount a directory (in /run/media/...) silently fails when doing so from inside a snap. No errors in any logs that I can see, and udisks seems to think that it worked but the "mounted" directory is empty and nothing shows up for it in /proc/mounts
<kyrofa> sergiusens, right yes of course, thanks for the reminder
<ssweeny> zyga, just running mount from the command line works
<ssweeny> but the snap is calling the system mount AFAICT. there's no mount command inside the snap
<zyga> ssweeny: because snaps run in a mount namespace
<ssweeny> ah, crap
<zyga> ssweeny: those mounts are visible only to the process that performed them
<zyga> ssweeny: you could use a specially designed bind mount to overcome this
<zyga> ssweeny: because of shared subtrees and a little bit of magic
<zyga> ssweeny: http://www.zygoon.pl/2016/08/snap-execution-environment.html
<ssweeny> zyga, thanks! I'll look into it
<jdstrand> sergiusens: how do I use the dump plugin to replace copy? I have something in ./bin, do I did:
<jdstrand> parts:
<jdstrand>   wrapper:
<jdstrand>     plugin: dump
<jdstrand>     source: bin/
<jdstrand> sergiusens: that didn't seem to work: [Errno 2] No such file or directory: '/home/jamie/bzr-pulls/snap-netns-test/prime/bin/sh'
<zyga> jdstrand: question, how would you feel if interfaces had a way to drop symlinks into hostfs (derived from what interface code says and $SNAP_NAME)
<zyga> jdstrand: use case is to have snaps integrate into classic distros
<jdstrand> zyga: can you give an example?
<jdstrand> sergiusens: I guess a tar file is the only way?
<sergiusens> jdstrand did the stuff in bin get dumped into the prime directory (sans bin)?
<zyga> jdstrand: dropping a symlink to an .xml file in /usr/share/gnome-something-something/ for wallpapers
<jdstrand> sergiusens: it did
<qengho> jdstrand: I've seen similar error when not snapping from scratch. I think the dependency tree is broken.
<jdstrand> I guess bin/bin?
<sergiusens> jdstrand yes, or maybe use organize as give it some miles :-)
<sergiusens> organize:\n    sh: bin/sh\n
<sergiusens> iirc that should work
<jdstrand> zyga: so /usr/share/gnome-something-something/snap.some.wallpaper -> /snap/some/current/wallpaper (or similar)?
<elopio> sergiusens: is this the same problem as the one in telegram?
<sergiusens> elopio yes
<jdstrand> sergiusens: ok, thanks!
<zyga> jdstrand: yes, (with .xml extension)
<sergiusens> elopio seems to be running now after enought retries
<zyga> jdstrand: (that would be in interface code)
<zyga> jdstrand: it would be something that the core snap would have a slot for on classic, the interface would auto-connect
<zyga> jdstrand: in all snap systems the interface could do something else that is still meaningful
<jdstrand> zyga: I'm not opposed to the concept. iirc relying on symlinks is somewhat frowned upon within snappy, but if niemeyer is signs off on it, that's fine. the only thing wrt security is that snaps are providing data that is being fed to unconfined processes
<jdstrand> zyga: and that can be scary. but that can be disussed on an interface by interface basis
<zyga> jdstrand: the interface here is wallpapers, I agree this is tricky
<zyga> jdstrand: symlinks because the location is hardcoded
<zyga> jdstrand: and because there's no apps there, just content
<jdstrand> this gets to the heart of the classic desktop is not designed for untrusted apps/data
<jdstrand> (from a security standpoint)
<zyga> jdstrand: yes but this is something that people do already, there's nothing new here
<jdstrand> I suspect wallpapers is 'ok'. if there are flaws in image libraries we would want to fix them in USNs
<jdstrand> zyga: sure but we want to be better not 'nothing new' :)
<zyga> jdstrand: get better by getting adoption, people already google for wallpapers and get them from random websites;
<jdstrand> I understand that. that is why I made my comment about USNs
<zyga> jdstrand: get them on snaps first :)
<zyga> jdstrand: USN is CVE for ubuntu?
<jdstrand> Ubuntu Security Notice. it is a *fix* for a CVE in Ubuntu
<zyga> ah, I see
<zyga> +1 on that :)
<jdstrand> if a snap provides a crafted file that does bad stuff, we want to fix that image library in a USN
<jdstrand> cause that bad stuff could happen in libreoffice, the browser, etc
<sergiusens> elopio or here, are you happy with https://github.com/snapcore/snapcraft/pull/734 ?
<mup> PR snapcraft#734: python plugins: add process-dependency-links option <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/734>
<elopio> sergiusens: yes
<sergiusens> thanks
<mup> PR snapcraft#734 closed: python plugins: add process-dependency-links option <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/734>
<mhall119> zyga: sergiusens: are we still waiting for snapd to support snaps defining runtime environment variables?
<zyga> mhall119: yes
<sergiusens> robert_ancell hi there, do you think you will have time to look into https://github.com/snapcore/snapcraft/pull/670
<mup> PR snapcraft#670: Remove .la files generated by autotools <Created by robert-ancell> <https://github.com/snapcore/snapcraft/pull/670>
<sergiusens> mhall119 I am glad zyga responded, I am waiting still but also have bigger plans for this
<robert_ancell> sergiusens, ok
<qengho> What's the bug tag to report a problem with seccomp filter? "snappy-interface"?
<kyrofa> qengho, snapd-interface, I believe
<mup> Bug #1614269 opened: tor package on ARMHF crashes on filtered syscall "personality" <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1614269>
<mup> PR snapd#1689 closed: spread: disable re-exec to always test development tree <Created by kyrofa> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1689>
<zyga> Pharaoh_Atem: done :)
<zyga> mhall119: though it is much closer now, I believe we can switch to snap-exec within the next release
<mup> PR snapcraft#735 opened: Load the remote parts only when needed <Created by elopio> <https://github.com/snapcore/snapcraft/pull/735>
<Pharaoh_Atem> zyga: btw, you probably should ship in /etc/sysconfig/snapd the environment config value to turn off the self-update/re-exec thing that snapd can do
<zyga> Pharaoh_Atem: is there something special I need to do with files in /etc?
<la_juyis`> anyone awake? :)
<zyga> Pharaoh_Atem: I can make that change easily, will that file be read by systemd and passed to snapd environment?
<zyga> la_juyis`: always
<Pharaoh_Atem> yes
<la_juyis`> zyga, yes!
<zyga> Pharaoh_Atem: let me try that :)
<Pharaoh_Atem> %config(noreplace) %{_sysconfdir}/sysconfig/snapd
<Pharaoh_Atem> that goes in %files
<zyga> Pharaoh_Atem: thanks!
<la_juyis`> anyone knows if there's problems with the snap store? Download snap "snappy-debug" (22) from channel "stable" (received an unexpected http response code (401) when trying to download https://public.apps.ubuntu.com/download-snap/DVAzG29Avl1Cn5s1nLXGzyQ0vi9v87Jw_22.snap)
<zyga> what does noreplace mean?
<Pharaoh_Atem> it means that the default behavior switches from backing up the existing config to .rpmsave files and writing a new one to installing the new config as .rpmnew
<stgraber> jdstrand: ok, so I think I figured out what's going on in https://bugs.launchpad.net/snappy/+bug/1611444
<mup> Bug #1611444: Cannot share a namespace between apps in a SNAP <Snappy:New> <https://launchpad.net/bugs/1611444>
<Pharaoh_Atem> then when someone runs a tool like rpmconf, it'll give people the option of handling it
<Pharaoh_Atem> this only matters if the user/admin modifies the config
<Pharaoh_Atem> otherwise, it works like any other file
<stgraber> jdstrand: it's the same issue we ran into with lxcfs & lxd, the separate mntns prevents openvswitch from seeing the other network namespaces as those are referenced through bind-mounts under /run/netns.
<stgraber> jdstrand: so the first app creates the path in /run/netns and sets up the bind-mount. Second app can see /run/netns/<name> but it sees it as an empty file rather than as the magic netns reference that should be mounted over it.
<zyga> Pharaoh_Atem: I see, thanks
<zyga> Pharaoh_Atem: modified locally, testing to see that it ends up where I expect
<mup> PR snapcraft#736 opened: Disable internet access during unit tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/736>
<zyga> Pharaoh_Atem: disabled
<Pharaoh_Atem> zyga: we're having an interesting argument about /snap on #fedora-devel
<Pharaoh_Atem> care to pop in?
<Pharaoh_Atem> the /snap path is a problem, and figuring out a resolution is tough
<zyga> Pharaoh_Atem: sure
<la_juyis`> zyga, care to take a look at http://pastebin.ubuntu.com/23065630/ and maybesuggest something?:)
<zyga> la_juyis`: in a moment
<la_juyis`> zyga, sure
<jdstrand> stgraber: interesting
<jdstrand> stgraber: how did you fix it with lxd and lxcfs?
<stgraber> jdstrand: instead of using multiple daemons, we just define one which is a long ugly shell script that starts everything
<jdstrand> hrmm
<stgraber> jdstrand: sucks in that we can't have proper monitoring and restart of the different bits we care about, but we could always solve that by bundling our own copy of systemd and spawning that from the wrapper script
<jdstrand> stgraber: another way to fix it would be to enter the same mount namespace
<jdstrand> (for snapd)
<stgraber> jdstrand: right, but you'll run into some problems then
<jdstrand> stgraber: talking about commands within the same snap
<jdstrand> stgraber: there was a request for that with a shared /tmp
<jdstrand> stgraber: what kind of problems?
<stgraber> jdstrand: my understanding was that interfaces could define bind-mounts and so that was why you wouldn't just have the launcher recycle the same mntns for all apps within the snap
 * jdstrand notes he never liked the private mount and preferred everyone set TMPDIR
<jdstrand> stgraber: we do have the content sharing interface. that makes it so one snap can export a dir read or rw and have it bind mounted into another snap's app-specific area (actually, rw is broken last I heard)
<jdstrand> we also do other bind mounts into the snap on classic
<jdstrand> but that is different
<jdstrand> stgraber: I'm not sure how I see the problem
<jdstrand> that was phrased weird
<jdstrand> stgraber: I still don't see what the problem is. can you elaborate?
<stgraber> so the problem is if you have multiple apps defined within your snap, some using such interfaces (leading to bind-mounts being setup by the launcher) and some which aren't
<stgraber> right now, they all get to see a view of the filesystem which matches what's declared. If they're using such an interface, the content is there, if they're not, then it's not
<stgraber> if you have the launcher share the mntns between all apps within a snap, you'll get the same result (as far as mount structure) as if all the apps were using all the interfaces
<jdstrand> if we got rid of the private mount they'd have access to the imported dir even if it didn't declare it
<jdstrand> right
<jdstrand> that's interesting, and may not be a big deal with 'content' but might be with others
<stgraber> oh yeah, I'm absolutely not advocating for removing the private mount
<stgraber> my initial thought was to allow for ns reuse in the launcher and setup some kind of ordering so I could say that lxd is to be started after lxcfs. In that case the launcher would re-use the lxcfs mount namespace, unshare it, undo anything that's specific to lxcfs and then apply the lxd-specific mounts. Allowing lxd to see the lxcfs mounts.
<stgraber> but that design wouldn't work for openvswitch since the daemons will keep creating mounts after startup
<stgraber> which then wouldn't be visible to the second daemon since you unshared
<stgraber> so in their case, they do need to use the exact same mount namespace for both (can't use a descendant). They can either do that by just running everything as one "app" or by having the launcher have some way to reuse existing mntns.
 * jdstrand nods
<jdstrand> stgraber: so I guess one option would be to add an argument to snapcraft.yaml to share the mmntns.
<jdstrand> stgraber: and then document what that means for the snap. perhaps conflicting with any interfaces that use .fstab mounts (eg, content)
<stgraber> jdstrand: yep, ideally with a way to tell it which should be using a shared mntns. No need for the client tool to be using the shared mntns, but the daemons should have a way to opt into that.
<jdstrand> stgraber: why wouldn't we extend that to non-daemon commands?
<stgraber> jdstrand: not saying that we should restrict it to daemons, but that if this is going to conflict with some interfaces, we shouldn't make it a snap level knob, but an app level one.
<jdstrand> oh I see what you're saying, yes, that makes sense
<stgraber> jdstrand: so I could say that daemon1, daemon2 and command1 in my snap are using a share mntns, but daemon3 and command2 aren't (meaning that I could then use .fstab mounts stuff for those two)
<jdstrand> stgraber: ok, I'll capture all this in the bug
<jdstrand> stgraber: thanks for your help on this
<stgraber> jdstrand: would be simple enough to even allow for things like: daemon1 and daemon2 use a shared mntns, daemon3 and command1 use a different shared mntns and daemon4 and command2 don't use shared mntns. But use cases for such a setup are likely not that common so a plain boolean knob may be enough :)
 * jdstrand nods
<zyga> la_juyis`: it seems that mono is not aware of where it is running and wants to load files from /usr/lib/mono, try configuring mono for a different prefix (say, /sanp/$SNAP_NAME/current/usr) or teach it about $SNAP (the location of the snap)
<zyga> la_juyis`: I'm sorry it's too late for me to give you more advice today
<la_juyis`> zyga, thanks! yeah, i'm going to sleep too :)
<qengho> On a all-snaps machine, there's no way to alter syslog rules, right?
<dannf> hey - i created a snap for a sprinkler control app i run on my beaglebone black, but i just realized there are no 16.04 bbb images. can i expect that snap to work on the 15.04 bbb image, or have things evolved too much since then?
<qengho> dannf: It won't work on 15.04. 15.everything isn't even supported any more, anywhere.
<qengho> dannf: I have the same trouble. I have a pandaboard.
<dannf> qengho: ah, ok. hm.. i wonder if should bother trying an elinux 16.04 image, installing snapd, and giving it a go
<qengho> dannf: Worth a try, but not worth a lot of effort. I think I could foresee that elinux kernel lacking some security facility that snap depends on to be safe.
<qengho> dannf: and, that rasp pi is pretty darned cheap.
<dannf> yep - agreed
<dannf> yeah, but i *have* the bbb + the control kit for it, and it works fine :) don't see throwing that out
<jdstrand> niemeyer: fyi, for tomorrow, can you take look at bug 1611444?
<mup> Bug #1611444: Cannot share a namespace between apps in a SNAP <Snappy:Confirmed> <https://launchpad.net/bugs/1611444>
<jdstrand> niemeyer: it is going to need architect input. Please see all the comments-- the reporter is requesting even more than the initial report and that detail might influence the design/implementation
<niemeyer> jdstrand: Heya
<niemeyer> jdstrand: Can you ping me about it tomorrow for us to discuss it, or schedule a call?
<jdstrand> ok
<qengho> dannf: There's a beagleblack package, I see. I bet your hardware is supported.
<niemeyer> jdstrand: Thanks.. the backlog is a bit wild at the moment, so that's the best chance of it not being delayed further
<qengho> dannf: It's not new. Has a weird version number and owner.
<dannf> qengho: cool, i'll take a look. right now i'm just trying a newer kernel/upgrade to xenial userspace to see if i can get it working in place
<niemeyer> jdstrand: btw,
<dannf> (which i hope means i can run snaps in devmode on ubuntu classic w/o the gadget layer)
<niemeyer> https://www.irccloud.com/pastebin/x1y6Nkq7/
<marcoceppi> trying to use the scons plugin
<mup> PR snapcraft#735 closed: Load the remote parts only when needed <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/735>
<marcoceppi> I've got everything building but nothing is going into stage or prime
<qengho> marcoceppi: Do you have any "stage" or "organize" sections in your YAML?
<marcoceppi> no
<marcoceppi> well, yes
<marcoceppi> I added a stage, to no avail
<marcoceppi> http://paste.ubuntu.com/23065874/
<qengho> marcoceppi: paste the output of building?
<marcoceppi> everything get's built into parts/fceux/build/usr/
<marcoceppi> it
<marcoceppi> it's pretty long, one second
<qengho> I mean the stdout.
<marcoceppi> qengho: running again to capture stdout
<qengho> marcoceppi: that "--prefix=usr" worries me.
<marcoceppi> qengho: without it, it tries to install to /usr/local
<marcoceppi> and the snapcraft command fails
<marcoceppi> so that puts allthe contents in usr under parts/fceux/build
<qengho> With it, does it try to install to the install dir?
<marcoceppi> qengho: http://paste.ubuntu.com/23065876/
<marcoceppi> qengho: nothing is in the install directory
<qengho> marcoceppi: I don't know exactly what to put there, but I suspect it will be something like  ../install
<marcoceppi> qengho: really? there isn't like a magic $SNAP or something I should use?
<qengho> marcoceppi: It's not magic, and I don't know scons.
<marcoceppi> apparently no on does, since there's not scons in playpen
<marcoceppi> I'm trying ../install
<qengho> marcoceppi: Where it puts it isn't where it will eventually access it. If the build makes the assumption that writing-location == access location at run time, then bad things will happen.
<marcoceppi> I'm guessing bad things will happen regardless at this point, butttt figured I would try
<marcoceppi> welp, I got a snap this time
<qengho> cool.
<marcoceppi> fonts aren't loading, butt I think most of ti worked
<qengho> Rock!
<marcoceppi> it's a gtk app, will that mess things up in a anspa?
<qengho> Nope. In fact, there may be a helper for fonts because of that.
<marcoceppi> haha, sweet, I can load roms
<marcoceppi> where would I find out about font helpers?
<marcoceppi> qengho: I found this, https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1584357 which is the error I got as well. I'll start there
<mup> Bug #1584357: Snappy GTK applications <snapcraft (Ubuntu):Confirmed> <https://launchpad.net/bugs/1584357>
<qengho> marcoceppi: In your YAML, in fceux: add a line   after: [ desktop/gtk ]
<qengho> marcoceppi: and change your command line to  command: desktop-launcher $SNAP/bin/fceux
<qengho> ...I think.
<marcoceppi> Issue detected while analyzing snapcraft.yaml: Cannot find definition for part 'desktop/gtk'. It may be a remote part, run `snapcraft update` to refresh the remote parts cache
<marcoceppi> after a refresh it still fails
<qengho> marcoceppi: Start fresh. snapcraft clean; sudo snap remove fceux-nes; ...
<marcoceppi> qengho: all snapcraft commands against the yaml fail
<marcoceppi> with the above error message
<qengho> Oh, I missed that.
<marcoceppi> is there a way to list parts?
<marcoceppi> maybe desktop/gtk2 ?
<nacc> marcoceppi: https://wiki.ubuntu.com/snapcraft/parts
<nacc> ?
<nacc> marcoceppi: looks to be gtk2, yeah
<marcoceppi> qengho nacc much success, thanks!
<qengho> marcoceppi: Awesome. Thanks for making a package!
<marcoceppi> qengho: sadly the upstream doesn't seem to interested in it atm, but I'll publish it regardless
<nacc> marcoceppi: nice!
<marcoceppi> logically, for snaps that ship GTK applications, how do I present a .desktop file for users?
#snappy 2016-08-18
<marcoceppi> do I just include setup/gui/fceux.desktop in the tree?
<wililupy> When building a kernel snap, I now have to create a symbolic link named kernel.img to vmlinuz in my parts/kernel/install directory before I ran snapcraft stage/prime/snap. Is this something new or should I just rename vmlinuz to kernel.img?
<sergiusens> marcoceppi gpsd uses scons (which that plugin was built for)
<sergiusens> doesn't have many miles/km on it yet
<marcoceppi> sergiusens: I didn't see anything in snappy playpen, which is where I searched for scons usage
<marcoceppi> sergiusens: where's the snapcraft yaml for gpsd?
<sergiusens> marcoceppi here's the part definition https://bugs.launchpad.net/snapcraft/+bug/1587289
<mup> Bug #1587289: Bad includes generated by snapcraft scons plugin <Snapcraft:Invalid by sergiusens> <https://launchpad.net/bugs/1587289>
<marcoceppi> sergiusens: well I got it working eventually, this is what the yaml looks like now
<marcoceppi> sergiusens: http://paste.ubuntu.com/23066003/
<marcoceppi> sergiusens: this line just feels weird to me
<marcoceppi>     scons-options:
<marcoceppi>       - --prefix=../install/usr
<sergiusens> marcoceppi so your SConstruct does not support using DESTDIR?
<marcoceppi> sergiusens: not mine, not sure
<sergiusens> does using that --prefix make any assumtions about runtime?
<sergiusens> you probably want --prefix=$SNAPCRAFT_PART_INSTALLDIR (not implemented yet)
<marcoceppi> sergiusens: so far, does not appear so
<marcoceppi> since it works
<marcoceppi> sergiusens: I'd love to use a variable like that ;)
<marcoceppi> sergiusens: here is there SConstruct file http://paste.ubuntu.com/23066005/
<mup> PR snapcraft#737 opened: Release changelog for 2.15 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/737>
<marcoceppi> prefix seems to be used only during the installation phase
<marcoceppi> (thankfully)
<sergiusens> marcoceppi usually code that builds on Windows has location independent code... usually
<sergiusens> good luck with that
<marcoceppi> sergiusens: well, that must be from when the win32 and SDL code was in the same repo, that's split a while ago but still seems to hold true
<marcoceppi> my only problem now is audio with strict confinement, but that seems to be a snappy isue
<sergiusens> robert_ancell hey, thanks for updating the PR, there is one minor issue in there still if you don't mind fixing (whitespace between method/function and ())
<robert_ancell> sergiusens, fixed, thanks
<mup> PR snapd#1693 opened: tests: add qemu to our spread.yaml and update README <Created by mvo5> <https://github.com/snapcore/snapd/pull/1693>
<zyga> o/
<zyga> Son_Goku: hey, didn't you menition that FHS standard is at 3.0 now
<Son_Goku> yes
<zyga> Son_Goku: I'm looking at http://www.pathname.com/fhs/ and I see 2.3 released in 2004
<Son_Goku> https://wiki.linuxfoundation.org/lsb/fhs-30
<Son_Goku> it moved to LF
<zyga> aha
<zyga> thanks
 * zyga hates dead pages like that
<Son_Goku> zyga: don't we all?
<ogra_> sigh
<ogra_> so my daily upgrade on 16.04 gets completely stuck in the apparmor postinst
<zyga> ogra_: what's up?
<zyga> ogra_: anything in syslog?
<ogra_> well, it looks for upstart
<Son_Goku> :/
<Son_Goku> there's so much sad right there
<zyga> ogra_: what do you mean specifically?
<ogra_> http://paste.ubuntu.com/23066846/
<zyga> well, there you have it update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
<ogra_> sure
<zyga> all postinst scripts are evil
<zyga> because they are never perfect
<ogra_> zyga, tell that to a million or two of our users who can not upgrade their LTS installs anymore
<ogra_> this is a normal 16.04 ... no PPAs or fancy hacks ... just using the daily update-manager run
<zyga> ogra_: aha, that's more severe then
<seb128> does it hang or just take time?
<ogra_> seb128, well, i killed update-manager after 20min the first run ...
<Son_Goku> ogra_ this must be what my colleague at work was grumbling about
<Son_Goku> it somehow magically worked after apt upgrade twice, the apt-get install -f, then install -f again
<seb128> no report of that issue so far, doesn't look like it impact everyone or we would have read more about it
<Son_Goku> which makes zero sense
<ogra_> (admittedly this machine was upgraded 12.04->14.04->16.04 ... so perhaps something on the way hasnt been cleaned up properly, ut this is my desktop, i dont do any os level changes or hackery on it )
<seb128> the box I'm using was upgraded all the way every cycle since 2011
<seb128> no such issue
<ogra_> every cycle != LTS->LTS
<seb128> right
<ogra_> so this might be related
<seb128> but it's usually enough to stack cruft as well
<ogra_> it gets more developer attention :)
<seb128> did you get a bt or details about the hanging process?
<seb128> seems worth a bug report in any case
<ogra_> yeah
 * ogra_ filed bug 1614459
<mup> Bug #1614459: daily upgrade on 16.04 hangs <apparmor (Ubuntu):New> <https://launchpad.net/bugs/1614459>
<ogra_> funnily i cant ctrl-C out of the hanging process
 * ogra_ comments the update-rc.d call in the postinst
<ogra_> hrm ... loooks like the upstart thing isnt actually the issue ... it still hangs ... just without any error now
<zyga> Son_Goku: https://bugzilla.redhat.com/show_bug.cgi?id=1367825#c11
<Son_Goku> zyga, did you run spectool -g on the specfile first?
<Son_Goku> it does work, but you have to download the tarball with the right name
<Son_Goku> spectool -g snapd.spec
<zyga> yes
<zyga> it doesn't work because that url is 404
<zyga> ther'es no such thing on github apparently
<zyga> Son_Goku: look at https://github.com/snapcore/snapd/releases/tag/2.11
<zyga> the tarball URL is https://github.com/snapcore/snapd/archive/2.11.tar.gz
<Son_Goku> I tried this: https://github.com/snapcore/snapd/archive/2.11/snapd-2.11.tar.gz
<Son_Goku> that worked
<zyga> odd, I just ran spectool
<zyga> let me check again
<zyga> Son_Goku: btw, about directory ownership, did you have something like this on your mind? http://paste.ubuntu.com/23066917/
<Son_Goku> yeah
<Son_Goku> it essentially mimics how libvirt is set up in /var/lib/libvirt
<Son_Goku> in this case, /var/lib/snapd/snaps is where the snaps go
<Son_Goku> as opposed to /snap
<zyga> Son_Goku: odd, now spectool downloads the file, ...., anyway, let me commit that
<zyga> Son_Goku: as for /snap that's a separate issue :-) I'm working on that
<zyga> Son_Goku: ok pushed again, have a look
<zyga> Son_Goku: essentially right now as of 2.11 that won't work without several major patches, I'm open to the conversation but you already know that :)
<zyga> Son_Goku: the %dir entries make rpmbuild choke, those things are only made at runtime, should I just mkdir them in install?
<Son_Goku> mkdir and install them
<Son_Goku> err, mkdir in %install
<zyga> right, tring
<zyga> trying*
<Son_Goku> as for the directories not working right now without patches, I'm not worried about that at the moment, as you *can* patch it
<zyga> Son_Goku: well, the patch'd better be something that upstream can support over time, it's a major change that has to be architected correctly
<Son_Goku> yes
<zyga> Son_Goku: I don't want to break existing snaps
<Son_Goku> but you're upstream :)
<Son_Goku> you can also make the legacy packaging migrate the data around as needed
<Son_Goku> s/legacy/debian/
<zyga> Son_Goku: yes but has to be planned and executed, I'm not a one-man team
<Son_Goku> yes
<Son_Goku> this was an issue that was brought up at the sprint
<zyga> Son_Goku: heh, github just broke
<zyga> remote: ruby-jemalloc: symbol lookup error: /data/github/current/vendor/gems/2.1.7/ruby/2.1.0/gems/json-1.8.3/lib/json/ext/generator.so: undefined symbol: rb_data_typed_object_alloc
<zyga> I get this on each push
<Son_Goku> O.o
<Son_Goku> that's...
<zyga> I'll just commit and scp to fedorapeople
<Son_Goku> yeah
<zyga> I guess github is not using snaps ;)
<zyga> and they pushed some partial updates
<Son_Goku> github does jenkins deploys
<Son_Goku> it's very ugly stuff
<Son_Goku> I've heard rumors that people describe the codebase as duct tape and silly string
<zyga> are they public about about the deploy process?
<zyga> I read some cool and nice things about them on their blog
<zyga> (~100 deploys a day)
<Son_Goku> not really
<Son_Goku> they've talked about it at a high level
<Son_Goku> but never in detail
<zyga> Son_Goku: I've updated snapd to 2.12, no change on /snap yet but I'll do all the things I can today
<zyga> (exception request and patches)
<Son_Goku> okay
<mup> Bug #1614212 changed: Invalid character in ubuntu-core mount name breaks etckeeper <Snappy:New> <https://launchpad.net/bugs/1614212>
<mup> PR snapcraft#738 opened: nodjs, gulp plugins: use http_proxy to connect npm registry <Created by m-shibata> <https://github.com/snapcore/snapcraft/pull/738>
<mrCyborg> hey! I am heaving a strange issue, when I run `snapcraft snap` I get the following error while it is at the building part: "[Errno 39] Directory not empty: '/home/cyborg/Code/webtorrent-desktop-snap/parts/webtorrent-desktop/install'". content of snapcraft.yaml: https://gist.github.com/nloomans/5d87feb430901a0d1130be9d32bffd9f
<mup> PR snapd#1694 opened: tests: adapt to new spread version <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1694>
<mup> PR snapd#1695 opened: tests: first iteration on all-snap image tests <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/1695>
<cjwatson> I'm struggling to build my local version of snapd.  Can somebody help?  The instructions in README.md appear to build the code downloaded from GitHub, not my local tree.
<cjwatson> Oh, never mind, symlink in the right place under $GOPATH seems to do the trick.
<mup> PR snapd#1696 opened: interfaces: add hidraw-device interface <Created by jocave> <https://github.com/snapcore/snapd/pull/1696>
<mrCyborg> I've figured out that the problem only exist when I use a stage-package... can anyone help?
<ogra_> GAH !
<ogra_> so my laptop hangs the same way when updating apparmor
<niemeyer> mrCyborg: sergiusens will be online in a short while and should be able to give you a hand
<mrCyborg> nieweyer: tnx, I will wait
<sergiusens> niemeyer mrCyborg I am online now :-)
<ogra_> sergiusens, hmm, how would the macaroon affect logging in ?
<sergiusens> oh, you have been hit by a bug
<ogra_> do we hack around in pam ?
<sergiusens> mrCyborg 2.15 should solve that
<sergiusens> ogra_ I totally missed the ubuntu:ubuntu thing!
<ogra_> :)
<ogra_> smells like image corruption or some such
<sergiusens> ogra_ there
<ogra_> (though i'm waiting for the version answer ... if thats 16.04 all-snaps it might simply be an experimental image )
<sergiusens> ogra_ what about the first user setup that is being put in place?
<ogra_> well, we put it in place at image build time ... then cloud-init mangles it on first boot
<sergiusens> mrCyborg it is currently making its way into the archives
<mrCyborg> <sergiusens>: good to know it's a bug, is there a beta I can test, or is the patch not jet written?
<sergiusens> mrCyborg it is being released; do you know how to run from sources?
<mrCyborg> yes
<sergiusens> mrCyborg or alternatively install the snapcraft deb from https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily/+build/10630457
<sergiusens> mrCyborg if sources is your cup of tee, just make sure master is up to date and run snapcraft from /<path to source>/bin/snapcraft
<mrCyborg> sergiusens: I will install the daily form launchpad
<jcastro> niemeyer: is the snapcraft list moderated? I fear my message might be stuck in a queue somewhere.
<sergiusens> jcastro when I posted with my wrong email I got a reply for it
<mrCyborg> sergiusens: It solved that issue, but now I'm getting a bunch of "unable to chown" errors... "unable to chown /home/cyborg/Code/webtorrent-desktop-snap.bak/prime/usr/lib/x86_64-linux-gnu/libXtst.so.6: [Errno 1] Operation not permitted: '/home/cyborg/Code/webtorrent-desktop-snap.bak/prime/usr/lib/x86_64-linux-gnu/libXtst.so.6'", any idea?
<sergiusens> mrCyborg does it fail the build or is it just printed out?
<mrCyborg> just a warn, the build doesn't fail
<sergiusens> mrCyborg great then; those are system imported libs but we do some _link_or_copy smarts to make things go faster
<sergiusens> I need to filter out those errors
<sergiusens> josepht mind taking care of what mrCyborg mentions?
<sergiusens> mrCyborg mind logging a bug against snapcraft against the launchpad project?
<mrCyborg> serguisens: About what? I thought this one was fixed? Still heaving some issues tho but I beleve the problem is on my side.
<sergiusens> mrCyborg about the messages :-)
<mrCyborg> serguisens: oh, sure
<mrCyborg> serguisens I think I just found another but tho, dumping an (online) zip doesn't seem to respect file permissions.
<josepht> sergiusens: sure, it's just a warning and is expected to fail unless snapcraft is run as root (i.e. for an os snap)
<jdstrand> ratliff, tyhicks: fyi, bug #1614459 (ogra saw an oops on two machines)
<mup> Bug #1614459: daily upgrade on 16.04 hangs <regression-update> <apparmor (Ubuntu):New> <https://launchpad.net/bugs/1614459>
<ogra_> jdstrand, i still have  the update-manager sitting here in hanging state in case anyone needs more info
<ratliff> ack jdstrand, thanks
<mrCyborg> serguisens: issue submitted!
<josepht> mrCyborg: thank you
<cwayne> sergiusens: how do i tell the dump plugin where to put the files?
<stokachu> cwayne: https://github.com/conjure-up/conjure-up/blob/master/snapcraft/snapcraft.yaml#L59
<cwayne> stokachu: thanks
<stokachu> np
<cwayne> stokachu: do you know if it accepts globs
<cwayne> like can i copy everything from launchers/ to bin/
<stokachu> cwayne: yea it should
<stokachu> filesets do accept globs so it should apply the same here as well
<mup> PR snapd#1557 closed: many: introduce an assertstate task handler to fetch snap assertions <Critical> <Reviewed> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1557>
<marcoceppi> so, USB inputs and stuff, what's the TL;DR on that?
<mup> PR snapcraft#737 closed: Release changelog for 2.15 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/737>
<tyhicks> jdstrand, ratliff: see #ubuntu-devel for my response
<jdstrand> yep, thanks
<jdstrand> tyhicks: I didn't realize you were pinged there. I only saw the reference here
<tyhicks> no problem
<mup> PR snapd#1697 opened: allow bind() in the network client interface <Created by tych0> <https://github.com/snapcore/snapd/pull/1697>
<mup> PR snapd#1695 closed: tests: first iteration on all-snap image tests <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1695>
<mup> PR snapcraft#670 closed: Remove .la files generated by autotools <Created by robert-ancell> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/670>
<mup> PR snapcraft#739 opened: Only show chown warnings with --debug <Created by josepht> <https://github.com/snapcore/snapcraft/pull/739>
<mup> PR snapd#1698 opened: tests: add all-snap spread image tests <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/1698>
<mrCyborg> hey! I was wondering why ~/snap is used for user data, instead of ~/.snap.
<mup> PR snapd#1690 closed: partition: ensure that snap_{kernel,core} is not overriden with an empty value <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1690>
<Pharaoh_Atem> mrCyborg: dot folders are evil
<Pharaoh_Atem> :P
<Pharaoh_Atem> zyga: golang(gopkg.in/macaroon.v1) will sync out to the repos as soon as the latest updates mash runs
<Pharaoh_Atem> as will snap-confine
<zyga> Pharaoh_Atem: I saw
<zyga> Pharaoh_Atem: I need to update the golang something mux package, it's slightly out of date it seems
<Pharaoh_Atem> gorilla/mux?
<Pharaoh_Atem> zyga: like most golang packages that are docker deps, it's maintained by jchaloup
<Pharaoh_Atem> you can ask him to update it and to become a comaintainer
<Pharaoh_Atem> it might even be a good idea to just ask to become a comaintainer for all snapd deps
<jdstrand> niemeyer: hey, would now be an ok time to discuss bug 1611444? I think it can be covered in a short hangout (probably less than 10 minutes)
<mup> Bug #1611444: Cannot share a namespace between apps in a SNAP <Snappy:Confirmed> <https://launchpad.net/bugs/1611444>
<jdstrand> niemeyer: if not, I can schedule something for later today
<zyga> Pharaoh_Atem: yep, that's my plan
<niemeyer> jdstrand: It's lunch time, so probably best to schedule it for the afternoon
<jdstrand> ah, sorry, sure thing
<popey> https://github.com/PowerShell/PowerShell who's up for snapping that :)
<marcoceppi> so, USB inputs and stuff, what's the TL;DR on that? does it work is there a plug for it?
<popey> marcoceppi: we discussed this here yesterday. it's not fully designed yet, so no, not implemented AIUI
<marcoceppi> ta, must have missed it
<mup> Bug #1614587 opened: unable to run snap on ubuntu 14.04 (ZOE error) <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1614587>
<arges> sergiusens: hi. When I type snapcraft. why does it not rebuild sources if any of the source files have been modified?
<arges> i've been working around this by snapcraft clean && snapcraft, but seems like it should detect changes in source (timestamps changed for local source, git commits for remote source)
<sergiusens> arges because we have not implemented those smarts yet
<sergiusens> it is in the queue
<sergiusens> but there are just too many things to do
<arges> sergiusens: ok that's cool. Yup understand! it was mostly a question if I should file a bug, or if you had already thought about it
<sergiusens> arges already in queue, so no need ;-)
<arges> awesome
<mup> PR snapd#1699 opened: introduce the "lxd" interface <Created by tych0> <https://github.com/snapcore/snapd/pull/1699>
<mup> PR snapd#1700 opened: add mir to implicit for running gui snaps on unity8 classic desktop <Created by kgunnfront> <https://github.com/snapcore/snapd/pull/1700>
<popey> mhall119: meeting time?
<elopio> kyrofa: do we have a desktop client snap for next cloud?
<kyrofa> elopio, only the owncloud one right now: https://software.opensuse.org/download/package?project=isv:ownCloud:desktop&package=owncloud-client
<sergiusens> kyrofa but you were working on a client, right?
<kyrofa> sergiusens, ohh, wow I need to read the complete question
<kyrofa> sergiusens, yeah I was working on it, but I put it on hold due to the indicator stuff
<mup> PR snapd#1697 opened: allow bind() in the network client interface <Created by tych0> <https://github.com/snapcore/snapd/pull/1697>
<mhall119> zyga: if you have a brain-dump for the content-sharing interface you can share with popey and I, we can get started with just that
<zyga> mhall119: I'll write my blog post today, just let me get off the call :)
<sergiusens> elopio 2.15 is in xenial-proposed; get your chain saw ready ;-)
<popey> zyga: thanks
<mhall119> thanks zyga
<qengho> On all-snaps images, how does that /writable partition work for things in "/etc" ?
<mrCyborg> hey! I'm trying to snap a gtk package, but I get the error `Gtk-Message: Failed to load module "overlay-scrollbar"` when trying to run it, to resolve the issue I tried adding `overlay-scrollbar` to `stage-packages`, but that didn't seem to help... any ideas?
<qengho> mrCyborg: I do not think that is fatal. Is it working anyway?
<mrCyborg> qengho: It is fatal, that wasn't the only package missing, it was just an example
<mrCyborg> qengho: It fails to load overlay-scrollbar, gail, atk-bridge, unity-gtk-module, and canberra-gtk-module.
<qengho> mrCyborg: what is your "command" in YAML?
<mrCyborg> qengho: gist: https://gist.github.com/nloomans/5d87feb430901a0d1130be9d32bffd9f
<mup> PR snapcraft#739 closed: Only show chown warnings with --debug <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/739>
<qengho> mrCyborg: Ah, thx. I think you should use the wrapper that sets up the environment for gtk2 apps. In parts, webtorrent-desktop, add  after: [ desktop/gtk2 ]  and change your command to  command: desktop-launcher $SNAP/WebTorrent
<mrCyborg> qengho: tnx for the help, but now I get the flowing error: "The specified command 'desktop-launcher' defined in the app 'webtorrent-desktop' does not exist or is not executable"
<qengho> Sorry. `desktop-launch`
<mvo> ogra_: hey, the fix for the upgrade problem has landed, let me create new images for you so that we can verify it
<qengho> Who's in charge of the parts yaml on the web?
<mrCyborg> qengho: Thanks a lot, that works now! I really should have asked for help earlier...
<qengho> mrCyborg: welcome!
<elopio> sergiusens: ack. I'll test after lunch.
<mup> PR snapcraft#740 opened: Allow debugging cleanbuild runs <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/740>
<ahoneybun> mm
<ahoneybun> 'no mobule 'gi'
<qengho> There's a lot wrong there.
<ahoneybun> XD
<om26er> Hi! I am not able to apt-get anything on all-snaps latest in classic mode, it gives me: cat: standard output: Permission denied
<om26er> actually sudo classic.create gives me:
<om26er> chroot: failed to run command â/var/lib/classic/enable.shâ: No such file or directory
<om26er> ogra_, ^
<qengho> The images are the big bad ignored part of snappy. There's no build system. There's no bug tracker. It's untethered to any kind of quality control.
<qengho> We should be saying "We have no images", instead of hoping these ad-hoc ones are good enough.
<mup> PR snapd#1681 closed: tests: test `snap run --hook` using in-tree snap-exec <Created by kyrofa> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1681>
<kyrofa> qengho, we aren't hoping that. The all-snap images aren't done yet, these are pre-releases
<kyrofa> qengho, also, they are indeed tethered to a QA process, but perhaps that could be more transparent
<qengho> kyrofa: I'm not saying they should be good enough for release. I'm saying they're not good enough for testing. I emailed my own "bug report" yesterday, into the void.
<kyrofa> Which void?
<qengho> I
<qengho> I'm not picking on him, but the owner of the personal file I used to flash.
<qengho> http://people.canonical.com/~mvo/all-snaps/16/all-snaps-pi2.img.xz
<kyrofa> Where was that announced as being available?
<qengho> I asked here, "What should I be installing on my rpi3"?
<qengho> kyrofa: if you know of daily builds and a bug tracker, I would be happy to know of it.
<mup> PR snapcraft#741 opened: Make it easy to setup a pre-commit hook <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/741>
<qengho> kyrofa: In any case, I'm not new to this. It's om2`6er of 45 minutes ago who has a new bug to report.
<qengho> I don't know where to send himher.
<kyrofa> qengho, mvo has made those just for testing purposes. They are unofficial. Until they are, all you can really do is talk to mvo (and maybe ogra_)
<mup> PR snapcraft#742 opened: Handle missing source type packages in the parser <Created by josepht> <https://github.com/snapcore/snapcraft/pull/742>
<mup> Bug #1614730 opened: dpkg: dependency problems prevent configuration of snapd -  snapd depends on ubuntu-core-launcher (>= 1.0.23) <oil> <Snappy:New> <https://launchpad.net/bugs/1614730>
#snappy 2016-08-19
<nacc> is there a trivial way to set an environment variable during the build of a part? Specifically, I'm finding I need to (with or without snapcraft) specify PKG_CONFIG for a tool's configure to find pkg-config (not sure why yet, debugging that separately).
<mup> PR snapd#1701 opened: Change snappy command to snap <Created by caldav> <https://github.com/snapcore/snapd/pull/1701>
<mup> PR snapd#1701 closed: docs/interfaces: change snappy command to snap <Created by caldav> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1701>
<mup> PR snapd#1702 opened: many: preparations for image code to fetch model prereqs <Created by pedronis> <https://github.com/snapcore/snapd/pull/1702>
<bull> snapcraft is still doing unexpected stuffs ,
<bull> i updated file under setup/gui/myapp.desktop and ran snapcraft , the resulting snap wont affected by the changes .
<mup> PR snapd#1703 opened: Feature/spread all snap ubuntu core upgrade <Created by mvo5> <https://github.com/snapcore/snapd/pull/1703>
<ahoneybun> popey: around for some snap help?
<JamesTait> A couple of quickies: I created a rpi2 image with the u-d-f snap last night - it works! But how do I set the kb layout to "gb"?  Also, I'm losing the left edge of the console - can I adjust overscan?
<bull> ahoneybun, i need help building snap of my app deskie its on github
<mvo> ogra_: I uploaded a new pi2/dragonboard image
<mvo> ogra_: that fixes the boot problem
<ogra_> mvo, with the upgrade fixes ?
<mvo> ogra_: yes
<ogra_> cool
 * ogra_ downloads
<ogra_> mvo, did you test kernel too ?
<mvo> ogra_: just core
<mvo> ogra_: should be ok, but feedback welcome
<ogra_> (we have a set of unapproved kernels in the store, should all be no-change rebuilds that only bump the revision)
<mvo> ogra_: ok, will accept that
<ogra_> cool
<mvo> ogra_: approved, once the caching of the store is expired it will be available
<mvo> (usually ~5min or so)
<ogra_> yeah, no hurry, sill downloading here :)
<bull> snaped application load veru slow why ???
<bull> what does this mean ??  snap/supercalc/x1/bin/desktop-launch: line 144: /home/bull/snap/supercalc/usr/bin/supercalc: No such file or directory
<popey> ahoneybun: for you, always
<bull> popey,  help :/
<ogra_> looks like you are using a wrong path
<bull> ogra_,  where should i fix that , i dont know which part of snap is calling my application
<bull> is it .desktop file or is it .yaml file command section??
<ogra_> dunno, where did you define desktop-launch ?
<ogra_> wherever you use that, you need to give it the right path to the application
<bull> http://paste.ubuntu.com/23069859/
<bull> ogra my yaml file
<bull> ogra_,  plz check it
<ogra_> looks like desktop launch cd's to $SNAP_USER_DATA so you want to tell it to use $SNAP/usr/bin....
<bull> ogra_, my desktop file inside setup/gui is here http://paste.ubuntu.com/23069863/
<popey> prefix $SNAP before usr  bull
<popey> in your yaml
<popey> desktop-launch $SNAP/usr/bin/supercalc
<bull> popey, let me check
<bull> thanks
<ppisati> uhm
<ppisati> 401 Client Error: UNAUTHORIZED for url: https://public.apps.ubuntu.com/download-snap/b8X2psL1ryVrPt5WEmpYiqfr5emixTd7_292.snap
<bull> okay what i have to do to rebuild the snap without redownloading everything ,
<ahoneybun> popey: http://pastebin.ubuntu.com/23068283/
<ppisati> any idea what is that?
<ahoneybun> I can't seem to get access to gi but I have python3-gi in the stage and build
<popey> bull: snapcraft prime
<popey> bull: you don't have to re-build, you can just re-run steps
<ppisati> bah
<bull> okay i will try ,
<ppisati> i had to login again
<popey> ahoneybun: looks like you're missing some stage-package? What you packaging? A GTK app?
<ahoneybun> I keep doing snapcraft clean for every new build
<ahoneybun> popey: yea Pithos, I also have desktop/gtk3 in after
<ahoneybun> every page says python3-gi would be it
<popey> ahoneybun: bug 1576291
<mup> Bug #1576291: gtk/gio integration not easy to enable <snap-desktop-issue> <Snapcraft:Confirmed> <snapcraft (Ubuntu):Confirmed> <https://launchpad.net/bugs/1576291>
<popey> maybe?
<ahoneybun> of course I hit a bug
<popey> seb128: do you still encounter ^ this issue that perhaps ahoneybun is having?
<popey> just a guess, no guarantee that's it :)
<popey> brb
<ahoneybun> it could be it
<mup> PR snapcraft#743 opened: make plugin: fix artifact collecting <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/743>
<bull> popey, copy plugin is depreciated  ?how to replace it with dump ?
<ahoneybun> sounds right popey, it is a gtk and gio issue
<bull> guys why they calling smplayer directly  in line no. 13   ?? https://github.com/ubuntu/snappy-playpen/blob/master/smplayer/snapcraft.yaml
<bull> it taking a lot of time to launch he app :O
<bull> after snapping and installing the app wont run , it hangs with http://paste.ubuntu.com/23069877/
<popey> bull: using the desktop-launch script, the first run takes a little while, second run is faster
<bull> and it wont run my app
<popey> you can still use the copy plugin for now
<popey> we'll get the docs updated for dump
<bull>  stucked on this message http://paste.ubuntu.com/23069877/
<bull> :(
<popey> what does your yaml look like at the moment?
<mvo> ogra_: yep, works, kernel,core upgrade independent works, if you can try them together (just do sudo snap refresh) that would be great
<ahoneybun> me popey?
<mvo> ogra_: fwiw, we have a spread upgrade test for amd64 soon too so at least the arch-indep issues (like the one we had recently) will be uncovered
<popey> ahoneybun: no
<bull> popey, http://paste.ubuntu.com/23069859/
<ahoneybun> k
<popey> bull: didn't you modify command: ?
<bull> modified
<bull> thats a older paste
<bull> wait let me show you new one
<bull> http://paste.ubuntu.com/23069888/
<popey> ahoneybun: I don't know how to fix your issue, sorry. I imagine there's a package you need to add, but I don't know without trial and error what it is, might be the one you mentioned, try it :)
<bull> popey, http://paste.ubuntu.com/23069888/
<popey> bull: what is supercalc written in?
<bull> popey, it was running without desktop launcher , but theming issues were there so i add launcher
<bull> qt4
<popey> and does it work if you use devmode?
<bull> wait let me check
<popey> ah, interesting
<ahoneybun> popey: I have python3-gi in build and stage so it might be that bug
<popey> also, another thing you can try.
<bull> popey, supercalc --devmode  ???  this ??
<popey> no
<popey> sudo snap remove supercalc
<bull> confinement ?
<bull> okay
<popey> sudo snap install supercalc... --devmode
<popey> ^ that
<bull> installing
<popey> also, a useful tool to install is snappy-debug
<popey> sudo snap install snappy-debug
<popey> then:-
<popey> sudo snap connect snappy-debug:log-observe ubuntu-core:log-observe
<popey> then:-
<bull> its running
<popey> sudo snappy-debug.security scanlog | grep supercalc
<bull> hurrrey
<popey> ^ do that, and it will tell you what your app is trying to access
<bull> popey, no theming issue
<bull> okay thanks man here is supercalc btw http://www.ktechpit.com/miscellaneous/supercalc-all-in-one-powerful-calculation-conversion-tool-for-linux/
<popey> run that in one terminal, and then run your app in another terminal
<popey> you need to fix this, because you can't upload devmode snaps to the stable store
<bull> yeah i will
<bull> popey,  one more thing that is weird here is , when i click on the website button which actually , opens up my website when user click on the menu entry , won't open up any browser
<popey> yeah, i have seen that issue.
<ogra_> a fix landed recently but is not published yet
<popey> ok
<bull> my app do that using qt's qdesktopservices library
<popey> ta
<bull> ogra_, you talking about my issue ??
<ogra_> (at least if the backend uses xdg-open at the bottom)
<bull> ogra_, yes qdesktopservices uses xdg-open i know that '
<bull> i gone through the lib source
<bull> on linux they call xdg-open
<bull> popey, ogra_ mouse cursor is not usual its not following system theme
<bull> 85mb snap vs 300kb deb :D :D
<bull> application icon in the dash not showing what i set inside .desktop file daem >/
<bull> my icon path inside .desktop file is like this -- Icon=${SNAP}/meta/gui/supercalc.png
<ogra_> mvo,
<ogra_> [FAILED] Failed to start Service for snap application snapweb.snapweb.
<ogra_> See 'systemctl status snap.snapweb.snapweb.service' for details.
<ogra_> seems that doesnt wait for ifup
<ogra_> (at least on the dragonboard wehere we use wlan ... seems the pi2 with wired works fine)
<ogra_> "sudo systemctl start snap.snapweb.snapweb.service" works
<bull> popey,  it says sudo: snappy-debug.security: command not found
<popey> bull: did you install it?
<bull> yeah
<popey> snap list snappy-debug
<popey> does it show up?
<bull> yeah
<bull> 0.23 version
<popey> hm
<bull> daem whats going wrong , command auto complete with tab key too
<popey> oh, you added a colon
<popey> sudo snappy-debug.security scanlog
<popey> no colon
<bull> okay wait
<bull> popey,  where is colon ??
<bull> no there is no colon in my command , it was the output
<ogra_> you need to use the full path with sudo
<ogra_> (fix for that is underway too)
<bull> ogra_, daem :D
<ogra_> just add /snap/bin
<bull> popey, you got it right bro ?
<bull> popey,  in devmode the qt session error wont show up that mean something is wrong there
<popey> right, it might mean there's a problem which the security debug command may list
<popey> so, close your app, start the sudo snappy-debug.security scanlog, run your command, then look at the scanlog
<bull> popey, i reinstalled the app without --devmode and  on other terminal ran  sudo snappy-debug.security scanlog | supercalc , then ran my application in other terminal
<ogra_> you pipe the output of scanlog into supercalc ? why is that ?
<bull> here is the output : - http://paste.ubuntu.com/23069967/
<popey> Stop.
<bull> ogra_,  am using grep
<popey> 1. install your app with devmode
<popey> 2. run the scanlog
<popey> 3. run your app
<bull> with devmode it working fine
<popey> 4. get the output from scanlog
<popey> yes. but scanlog will find the things it wants
<popey> trust me :)
<ogra_> teh app wants to open /etc/xdg/Trolltech.conf
<bull> haha okay :P
<popey> aha!
<ogra_> fix that so it reads it from your snap
<bull> ogra_,  how to get that permission
<ogra_> you wont get that permission
<ogra_> ship the file in your snap
<bull> daem
<ogra_> and make the app read it from that location
<bull> ogra_,  they are qt things how can i modify that path
<ogra_> no idea, not a qt guy ... but i guess there are environment variables for such stuff
<bull> i have to recompile my app :/
<bull> ogra_,  bro what path in env variable in qt i will pass then :D
<bull> at that time qt will unaware of the $SNAP/ :D
<ogra_> whereever your Trolltech.conf is
<bull> ogra_, any interface for that ??
<ogra_> ?
<bull> snap interface
<ogra_> why would your app be unaware where $SNAP is when you just started it from $SNAP
<ogra_> env vars here are a runtime thing, not compile time
<bull> ogra_, if i build it with qmake
<bull> am not comiling source with snapcraft
<ogra_> again, this has nothing to do with compiling
<bull> ogra_, you mean i have to set env variable in launcher file ?
<bull> my app is nothing special idk why it causing trouble :D
<ogra_> because it does not have the right environment for being used as a snap
<bull> am clueless :P
<bull> i will try to find out the solution :(
<bull> thanks
<lpotter> use after: [desktop/qt]
<lpotter> desktop/qt5
<bull> lpotter my app is qt4
<lpotter> ok, desktop/qt4
<bull> am having that
<bull> lpotter, http://paste.ubuntu.com/23070010/
<bull> lpotter, my snapcraft
<bull> well my new app uweather is ready to be snapped : https://s3.postimg.org/6vaj9uvxv/Screenshot_from_2016_08_19_16_38_15.png
<bull> lpotter, is it okay ?
<bull> ogra_, you there bro ?
<ogra_> bull, try https://www.google.de/search?client=ubuntu&channel=fs&q=XDG_CONFIG_HOME+XDG_CONFIG_DIRS+trolltech.conf&ie=utf-8&en=utf-8 and read up how Trolltech.conf can be used in other locations
<bull> ogra_,  i found that etc/xdg/Trolltech.conf in the snap of supercalc
<bull> why my app not reading that from there ?
<ogra_> because you didnt tell it to
<bull> okay :(
<ogra_> create a wrapper script that sets the right XDG var pointing to the dir
<bull> okay :|
<ogra_> and then do your desktop-launch from there
<bull> am trying hun
<ogra_> should be at most 10 lines
<bull> calling warp script right >
<ogra_> whatever you like
<bull> hehe
<ogra_> you have to put it in your snapcraft.yaml instead of the desktop.launc line
<bull> okay i will mess with it now
<bull> haha
<ogra_> https://github.com/ogra1/laidout is an example where i use a simple wrapper to just cd into the snap himedir of the user before running the app
<ogra_> *homedir
<ogra_> looks at the snapcraft.yaml and "wrapper" ... use something similar in yours but point the right XDG var to your $SNAP/etc/xdg
<mvo> ogra_: thanks for the report about snapweb - yeah, it sounds like that is the issue
<bull> ogra_,  thanks bro :*
<ogra_> s/looks/look/
<ogra_> mvo, upgrade on pi2 worked, could you approve one of the dragonboard kernels (seems jdstrand's kernel package approval still didnt land in the store )
 * ogra_ is just building another ubuntu-core to test armd64 upgrade too)
<mvo> ogra_: done, there is a dragonboard-kernel now
<ogra_> thx
<ogra_> witing for ubuntu-core now
<ogra_> hmm
<ogra_> or i could just do two upgrades
 * ogra_ does so
<bull> ogra_,
<mup> PR snapcraft#744 opened: testing: only run the ros demo on xenial <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/744>
<bull> ogra_, what this line mean - export XDG_CONFIG_DIRS=$SNAP/etc/xdg:$SNAP/usr/xdg:$XDG_CONFIG_DIRS
<bull> this is written already in desktop-launch
<mup> PR snapd#1704 opened: snap: Add key management commands <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1704>
<ogra_> mvo, dragonboard is fine, if you can give me the udf line for getting snapweb in, i'll roll a pi3 image too
<ogra_> (but first ... some lunch)
<seb128> popey, I didn't rely try for a while
<Son_Goku> zyga, morning
<Son_Goku> and happy birthday! :D
<bull> The 'build' step of 'glue' is out of date. Please clean that part's 'build' step in order to rebuild
<mvo> ogra_: just add --install snapweb to the commandline
<mvo> Son_Goku: oohhh, good morning-  and happy birthday to zyga
<bull> zyga,  happy birthday
<bull> mvo, is there a way to clean without deleting old downloaded cache
<ogra_> mvo, ok
<bull> ogra_, my warpper.sh http://paste.ubuntu.com/23070095/
<popey> seb128: ah okay
<bull> popey you know how to set env variable for qt app to launch from snap ??
<bull>  is there a way to clean  a part without deleting old downloaded cache
<stokachu> is it possible to keep the --devmode flag when manually running snap refresh?
<mup> PR snapd#1705 opened: overlord/snapstate: check changes to SnapState for conflicts also <Created by chipaca> <https://github.com/snapcore/snapd/pull/1705>
<ogra_> bull, look for the possible clean options in snapcraft --help
<bull> ogra_, it says Remove content - cleans downloads, builds or install artifacts. :D
<popey> bull: create a launcher and set variables in there
<bull> popey,  my warpper.sh http://paste.ubuntu.com/23070095/
<bull> is it fine
<popey> bull: like https://github.com/ubuntu/snappy-playpen/tree/master/jtiledownloader
<popey> as an example
<popey> thats not right
<popey> export $XDG_CONFIG_DIRS= $SNAP/etc/xdg/
<bull> ogra_,  gave me example i followed that
<bull> yeah i did the same :)
<popey> export XDG_CONFIG_DIRS=$SNAP/etc/xdg/
<popey> no dollar sign when setting the variable
<bull> popey i dont wana redownload dependencies again and again i just modified something in part and it will download all again :/
<bull> popey, thanks for pointing that out
<popey> you don't have to re-download
<ogra_> bull, just use the right option to clean
<ogra_> read the help again
<bull> ogra_, okay :P
<ogra_> there is more in it ;)
<bull> ogra_, snapcraft [options] clean [<part> ...] [--step <step>]   i wan clean glue part only
<bull> hehe
<popey> sooooo, you have the help right there
<bull> hehe am confused with this [--step <step>]
<bull> snapcraft clean glue  will enough ??
<ogra_> read more ;)
<bull> hehe okay
<bull> this is like rocket science :P
<popey> there's 5 steps, pull, build, stage, prime, snap. which are done in that order
<bull> oh
<bull> i got ot baiebeee
<bull> :D
<popey> http://snapcraft.io/create/ see the section on "build"
<bull> bui wan clean build of glue so am trying this - snapcraft clean glue build
<popey> you missed --step
<bull> yeah
<bull> popey,  can this whole be ported as gui app soon ??
<popey> what, a snapcraft GUI?
<bull> i mean for user's simplicity :D
<popey> sure, someone could do that
<bull> yeah
<bull> haha
<bull> it will make it easy
<bull> i would like to do that but i need learn about it first
<bull> and it should be in a stable stage :D
<bull> i developed my own app packaging tool which package apps for my own app store http://www.ktechpit.com/ubuntu/ubuntu-play-store-version-3-0-released-adds-paypal-integration/
<bull> popey, am talking about something like this https://www.youtube.com/watch?v=Be3vRVqPt58&feature=youtu.be&t=2272
<jdstrand> ogra_: it should've landed. can you point me at the store entry?
<bull> popey, after adding wrapper file  , snapcraft says- No such file or directory: '/home/bull/snap/supercalc/parts/glue/build/wrapper
<bull> am a biology student finding career in IT LOL
<bull> test
<mup> PR snapd#1705 closed: overlord/snapstate: check changes to SnapState for conflicts also <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1705>
<mup> PR snapd#1706 opened: add process-control interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1706>
<mup> PR snapcraft#745 opened: Actually return a non-zero error code on errors <Created by josepht> <https://github.com/snapcore/snapcraft/pull/745>
<bull> popey, i wana make gui of snapcraft , give me basic application design idea and i will present you working demo in within 2 days
<bull> mup, you are very informative :P
<mup> bull: I apologize, but I'm pretty strict about only responding to known commands.
<bull> what ? mup you are a bot ?
<bull> mup,  okay :D
<mup> bull: In-com-pre-hen-si-ble-ness.
<bull> mup, i want make gui for snapcraft
<mup> bull: Roses are red, violets are blue, and I don't understand what you just said.
<bull> lol
<bull> mup, you are a funny bot
<mup> bull: I apologize. I'm a program with a limited vocabulary.
<ogra_> jdstrand, https://myapps.developer.ubuntu.com/dev/click-apps/5697/
<ogra_> (the last one was manually approved though)
<bull> ogra_,  deb store is dead right ?
<mup> PR snapd#1685 closed: snap-exec: Fix broken `snap run --shell` and add test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1685>
<ogra_> ?
<bull> ubuntu deb store at developer.ubuntu.com
<jgdx> I'm getting a âexecv failed: No such file or directoryâ even though $ SNAP=prime ./prime/<wrapper> runs fine. What am I most likely doing wrong? :)
<jgdx> (getting that from running $ snap run <snap>)
<jgdx> does execv need absolute paths, is that it?
<bull> ogra_, i need a quick help brother
<bull> whenever i add a new file to my glue part in snapcraft.yaml do i need to start the process from begin ?? snapcraft automatically wont pull stage and prime the new file hence fails with file not found error
<bull> ogra_, i added trolltech.conf to copy in a location in  but it throws this error No such file or directory: '/home/bull/snap/supercalc/parts/glue/build/Trolltech.conf'
<bull> i cleaned the build --step too
<bull> it should probably be pulling file again, and stage and prime , so what am doing wrong !! while after a full clean command make it find the file
<bull> this could be bug
<popey> bull: you need to snapcraft clean glue
<bull> popey, i cleaned it all , now it is downloading what it cleaned :D , just to add a file which is already in my system
<bull> this is senseless
<bull> wasted my 400Mb data since i begin building supercalc , debian wont take a bit while building apps :D
<bull> snap is ready an checking it
<bull> popey it says permission denied again this time set wrapper to set custom env vars
<bull> this is irritating , am uploading the snap recipe in github along with the supercalc executable if some f you wana fix it please have a look
<jdstrand> ogra_: this kernel didn't autoapprove for a different reason: unknown entries in snap.yaml: 'dtbs,firmware,initrd,kernel,modules' lint-snap-v2_unknown_field
<jdstrand> ogra_: has the kernel yaml been finalized?
<ogra_> jdstrand, the build script and snapcraft yaml is identical for all kernels
<bull> popey, ogra_ https://github.com/keshavbhatt/supercalc   please fix this :(
<jdstrand> ogra_: ok... but is that finalized?
<jdstrand> :)
<ogra_> jdstrand, no idea ... but the other kernels dont have that error
<jdstrand> or is it going to change in the next 3 weeks?
<jdstrand> sergiusens: can you comment? ^
<ogra_> jdstrand, oh, i lied, they do
<popey> bull: will take a look
<ogra_> jdstrand, but why would a warning block promotion ?
<bull> popey, thanks :)
<jdstrand> ogra_: the review tools warn (and block) on things it doesn't know about. this is part of the whole 'fail closed, fail secure' philosophy of the tools
<jdstrand> ogra_: I'm adding a card to finish the kernel yaml checks assuming they are finalized
<ogra_> ok
<jdstrand> (last I checked I was told it was not so not to bother. that was a while ago though)
<ogra_> yeah, it was supposed to be finalized at the heidelberg sprint
<mup> PR snapd#1707 opened: tests: do not leave "squashfs-root" around <Created by mvo5> <https://github.com/snapcore/snapd/pull/1707>
<popey> bull: I have got it lanuching, but it's still trying to read from /etc http://paste.ubuntu.com/23070394/
<bull> popey, you testing it with --devmode ?
<popey> yes
<bull> its running with fine devmode
<bull> with devmode apparmor allowing it the access
<bull> when i scanlog without devmode it clearly says denied
<bull> popey,  ogra_,  told me to ship your own trolltech as it is not possible to get access to read that file in /etc/xdg/Trolltech.cofig so i wrote wrapper and exported my custom located trolltech.config with that but still it says permission denied
<morphis__> zyga: ok, I have prooved now that snap-confine breaks lxc's approach of attaching to a container which is running within another snap-confine session
<morphis__> makes totally sense that this is broken as snap-confine creates a slave mount for each executable it runs so this must break
<popey> bull: yeah, I don't know why it keeps looking at the one in /etc, I don't know enough about qt, sorry
<bull> popey, thanks for your time dear :)
<popey> bull: http://paste.ubuntu.com/23070410/ http://paste.ubuntu.com/23070412/  changes i made
<ogra_> sounds like your app simply doesnt respect the XDG_* values
<bull> popey, is it with my app only or other qt4 apps acting same
<popey> dunno, not packaged any qt4 things
<bull> ogra_, my app is normally build with qmake no modifications , nothing
<ogra_> and ?
<bull> it runs fines from ubuntu series 12.04 to 16.04
<ogra_> if the developer siimply doesnt respect the XDG stanndars
<ogra_> ...
<ogra_> and hardcodes /etc/xdg ...
<bull> ogra_, should i post the source code too ??
<ogra_> then you have no chance to solve it without patching the app
<bull> not its not like that
<ogra_> not to me, really
<bull> haha
<ogra_> talk to the upstream dev
 * ogra_ has no clue about qt4 apps
<bull> ogra_,  any idea how can we identify those hardcoded stuffs ??
<ogra_> nope
<ogra_> by reading the source i guess
<bull> i never did that actually so an clueless
<bull> daem
 * ogra_ goes back to actually get some work done before ending his day
<bull> i will try snapping my new weather app which is a qt5 app
<bull> popey,  have look at my first qml only music player using ubuntu sdk ui toolkit 1.0 :D i updated the code today on github and it is running fine on 16.04 too
<kyrofa> bull, I may have missed something, but from the YAML is doesn't seem you're using desktop-launch
<kyrofa> bull, have you tried that?
<bull> popey,  https://github.com/keshavbhatt/kmusicplay
<kyrofa> bull, oh nevermind, your wrapper is
<kyrofa> Ignore me :)
<bull> kyrofa, cause my app was not following theming
<bull> so i used desktop-launch
<bull> with desktop-launch it worked fine but only in --devmode install :/
<elopio> kyrofa: I have a qt4 snap complaining about xcb not found. Did we have an easy fix for that?
<ogra_> kyrofa, the app seems to have a lookup for /etc/xdg/Trolltech.conf hardcoded somewhere ... i tried to help bull to get a wrapper up that sets XDG_CONFIG_DIRS too point to $SNAP/etc/xdg/ but apparently the app simply ignores XDG standards
<kyrofa> elopio, do you have the stage packages from the qt4 demo?
<kyrofa> ogra_, does it just die as a result?
<jhodapp> ogra_, any idea why my snapd would seem to be dead on my 16.04 laptop installation? "$ snap find alsa-utils
<jhodapp> error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/find?q=alsa-utils: dial unix /run/snapd.socket: connect: connection refused"
<ogra_> kyrofa, no idea, ask bull :)
<elopio> kyrofa: yes, libqtgui4
<ogra_> jhodapp, nope, i havent seen that ... usually systmed cares for it to be u
<ogra_> p
<kyrofa> jhodapp, what does systemctl status snapd.service say?
<bull> kyrofa, it runs only with --devmode as apparmor allow to read $SNAP/etc/xdg/Trolltech.conf
<kyrofa> elopio, are you using the correct launcher?
<jhodapp> ogra_, this: http://pastebin.ubuntu.com/23070428/
<ogra_> hmm, no idea what is in line 52 of main.go :)
<Pharaoh_Atem> zyga: so if you can get snapd to use something other than /snap for the mount location, the last remaining blocker can be dealt with and snapd will be able to go into Fedora
<kyrofa> jhodapp, can I see some more of that error there? journalctl -u snapd.server maybe?
<Pharaoh_Atem> the presets for having snapd enabled and started automatically on installation of the snapd package have been provisionally approved as well
<om26er> Hi! which snappy image shall I use on raspberry pi2?
<Pharaoh_Atem> it's contingent on snapd being approved to go into Fedora
<jhodapp> kyrofa, I get "-- No entries --"
<kyrofa> jhodapp, so sorry, snapd.service, not server
<kyrofa> I've only had two cups of coffee so far
<bull> haha
<jhodapp> kyrofa, http://pastebin.ubuntu.com/23070435/
<jhodapp> lol
<om26er> I want to run a django service to remotely control some appliances, should I be using the 15.04 image or is there a newer stable image out there ?
<kyrofa> jhodapp, yikes
<jhodapp> kyrofa, that bad huh?
<kyrofa> jhodapp, first of all, you should log a bug. Second though, does systemctl start snapd.service actually bring it back up? Or does it error again?
 * ogra_ bets on the latter 
<jhodapp> kyrofa, it does not bring it up
<kyrofa> jhodapp, okay, definitely log a bug with that log. Have you been doing anything out of the ordinary with snaps? snap try, messing with mounts in /snap/, etc?
<jhodapp> kyrofa, is there any way to reset my snapd installation? I have been messing with custom snapd builds locally which is probably where this went wrong
<kyrofa> Ah ha!
<kyrofa> Yes, definitely
<kyrofa> jhodapp, perhaps not worth a bug, then
<ogra_> om26er, well, 15.04 will be EOL as soon as the series 16 images go stable ... we have experimental images at http://people.canonical.com/~mvo/all-snaps/16/
<jhodapp> that's what I was thinking, although it shouldn't be this brittle
<kyrofa> jhodapp, snapd writes a json state file that isn't always backward compatible
<jhodapp> ok
<kyrofa> jhodapp, please feel free to log the bug, I agree that it shouldn't blow up like that
<om26er> ogra_, when will 16 release ?
<kyrofa> jhodapp, are you okay losing the snaps you have installed?
<ogra_> om26er, when it is done (but surely within the next months)
<jhodapp> kyrofa, absolutely and I'd like to lose them all as it caused my main deb pkg installed pulseaudio to stop working right
<om26er> oh the `s` infront of month
 * ogra_ doesnt have the exact dates for RTM and GA releases at the top of his head, sorry
<kyrofa> jhodapp, haha, okay use this then: https://github.com/zyga/devtools/blob/master/reset-state
<timothy> hello, I have some errors on ./run-checks static
<timothy> http://paste.ubuntu.com/23070449/
<ogra_> after RTM (which is "soon") they should only stabilize ...
<om26er> ogra_, ok, I am having some issues with classic snap on latest all-snap
<timothy> is it a known problem with new go version (1.7)?
<ogra_> yeah, there are some bugs
<kyrofa> timothy, yeah, vet is more picky now :)
<ogra_> realted to virtual terminals
<ogra_> i'll try to tackle some of that next week
<kyrofa> timothy, surely worth a pull request if you're up for it!
<ogra_> but you can just use an ubuntu-base tarball instead of classic ... after all that is the same :)
<jhodapp> kyrofa, looks like it was successful except for one of them which a remount doesn't seem to help: "rm: cannot remove '/snap/pulseaudio/x4/usr/share/zsh/site-functions/_pulseaudio': Read-only file system"
<kyrofa> jhodapp, hmm...
<om26er> ogra_, sudo classic.create gives me: chroot: failed to run command â/var/lib/classic/enable.shâ: No such file or directory
<kyrofa> jhodapp, I'm not sure what to say about that one. ogra_, any clues?
<ogra_> om26er, smells like your ubuntu-core isnt up to date in the all-snaps image ... that script was only added a few weeks ago
<om26er> snap refresh is downloading something, lets see
<ogra_> kyrofa, nope, i dont use zsh ... no idea why that would be a mountpoint inside a snap
<ogra_> om26er, from when is that image ... if you are not on rthe very latest img the update will likely just make the img eat itself
<om26er> ogra_, downloaded from here: https://people.canonical.com/~mvo/all-snaps/16/
<om26er> yesterday
<jhodapp> kyrofa, ogra_ hmm ok...it got rid of all the others so that's progress
<jhodapp> let's see if snapd starts up now
<kyrofa> jhodapp, a reboot might help?
<jhodapp> it does start up!
<ogra_> om26er, well, better use todays ... mvo only fixed the update code this morning
<jhodapp> excellent
<kyrofa> Nice
<jhodapp> and snap find alsa works again
<jhodapp> thanks very much kyrofa
<kyrofa> jhodapp, of course, sorry for the breakage!
<jhodapp> no worries, lesson learned...don't try and install development snaps locally just quite yet...use a container :)
<ogra_> yyou mean snapd
<jhodapp> yeah that too
<jhodapp> :)
<ogra_> :)
<elopio> kyrofa: desktop-launch for desktop-qt4. Is there another?
<jhodapp> time for a reboot
<mup> PR snapd#1707 closed: tests: do not leave "squashfs-root" around <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1707>
<kyrofa> elopio, huh. No you should be good, but it's worth pointing out that the qt4 demo uses a different cloud part for the launcher
<kyrofa> elopio, I would be very surprised if that worked better though
<elopio> same here, but I'll try anyway.
<jhodapp> kyrofa, that fixed my pulseaudio issues as well...very good
<elopio> yes, fails earlier because it can't find libX11.
<mup> PR snapcraft#743 closed: make plugin: fix artifact collecting <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/743>
<mup> PR snapcraft#743 closed: make plugin: fix artifact collecting <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/743>
<kyrofa> elopio, odd... not sure what's going on there then :(
<kyrofa> elopio, I do know that qt4 was a little weird. I was never sure if it was using the qt4 on the system or in the snap
<kyrofa> Remember that conversation?
<bull> guys am having dinner :D keep snapping
<elopio> kyrofa: I more or less remember. And I'm sure the qt5 launcher solved that xcb problem for keepassx.
<elopio> I can wait for didier. This is a cool project I want to get working, but is the hardest I've tried so far.
<elopio> have you used synergy?
<nacc> Asked this late last night w/o response, but is there a trivial way to set an environment variable during the build of a part? Specifically, I'm finding I need to (with or without snapcraft) specify PKG_CONFIG for a tool's configure to find pkg-config (not sure why yet, debugging that separately).
<om26er> what does `snap refresh` do, is it to update the system ? I just installed the very lastest all-snap and snap refresh still downloaded some stuff
<ogra_> yes
<kyrofa> elopio, synergy the keyboard/mouse sharing thing?
<ogra_> it updtaes all updateable snaps
<ogra_> (unless you provide a snap name, then it only updates that one snap)
<elopio> yes. They have a crazy package generator. That part is ready, I'm getting back a snap with the required binaries. Maybe I can focus on the networking instead of the UI.
<jhobbs> is spand going to be backported to trusty?
<jhobbs> snapd*
<ogra_> jhobbs, i dont think anyone looked into that, but i saw a bug report pass by where sabdfl said he'd like that
<ogra_> (will definitely be non-trivial)
<jhobbs> yeah
<jhobbs> i would like it too :) we have some stuff that needs to run in both trusty and xenial and it would solve the dependency differences problem
<jhobbs> i thought i'd heard sabdfl mention it but haven't seen any hard evidence of it happening
<ogra_> it will definitely not happen in the very near future ...
<jhobbs> ok
<jhobbs> thanks ogra_
<ogra_> everyone is focused on getting towards images and get all the missing features in currently
<ogra_> i guess after the images are golden there is opportunity to work on this
<mup> Bug #1615030 opened: Ability to completely remove a snap from the snap store <Snappy:New> <https://launchpad.net/bugs/1615030>
<om26er> classic went bonkers for me while installing vim :( http://paste.ubuntu.com/23070754/
<om26er> seems it even broke my ubuntu-core installation as well, sudo says: sudo: unknown uid 1000: who are you?
<ogra_> om26er, why didnt you just use a ubuntu-base tarball like i suggested
<ogra_> classic is clearly still having bugs, as i said before
<om26er> ogra_, sorry I missed that message
<om26er> ogra_, shall I install the 16.04.1 server image on RPi2 ?
<ogra_> though this one looks like it might be snap-confine related
<om26er> http://cdimage.ubuntu.com/releases/16.04.1/release/ << this ?
<ogra_> om26er, no, just download an ubuuntu-base tarball, scp it to your pi, unpack in /home/ubuntu and use it as a chroot
<elopio> kyrofa: got the certifiacte, finally \o/
<om26er> ogra_, aah, ok, will my nginx work fine from it ?
<kyrofa> elopio, \o/
<ogra_> oh, you want it for running stuff ? not sure
<kyrofa> elopio, how was the workflow?
<ogra_> (note that things you run in classic will not survive a rebbot either)
<elopio> kyrofa: fine. I had to use canonistack because I couldn't get my modem to redirect port 80.
<ogra_> (by design)
<elopio> kyrofa: now what? I'm redirected from http to https but the URL is not serving anything.
<kyrofa> elopio, ... eh? That should be it! When you say it's not serving anything, what does that mean?
<kyrofa> elopio, a blank page?
<elopio> kyrofa: server not found. https://test.elopio.net
<kyrofa> elopio, can I see `systemctl status snap.nextcloud.apache.service`?
<elopio> kyrofa: https://paste.ubuntu.com/23070771/
<kyrofa> elopio, uh... hmm. Any chance you have the output of the setup-https run?
<elopio> kyrofa: https://paste.ubuntu.com/23070775/
<kyrofa> elopio, interesting. And I assume ps ax | grep httpd shows nothing?
<elopio> kyrofa: correct.
<kyrofa> elopio, does `sudo systemctl start snap.nextcloud.apache.service` fix things?
<elopio> kyrofa: yes.
<elopio> so it says apache was restarted, but that's a lie!
<kyrofa> elopio, huh. So my output masking is not helpful there :P
<kyrofa> elopio, the restart exited successfully! Not the scripts fault! :P
<kyrofa> elopio, hmm. I'm not really sure what happened there, or how to make it better
<kyrofa> elopio, mind blowing it away and trying again? Let's Encrypt will limit how many legitimate certs you can get in a week, so I suggest passing the -t flag to setup-https (i.e. `sudo /snap/bin/nextcloud.setup-https -t`)
<kyrofa> That will get a cert from the Let's Encrypt staging server instead, which the browser doesn't recognize as a CA, but isn't limited
<elopio> kyrofa: yes, let me retry.
<kyrofa> Gahh, I just pushed up an entire nextcloud snap, only to get a 502 after it got to 100%
<kyrofa> On 20k upload speeds
<ogra_> get a better gateway :P
<elopio> even better, fix this one: https://bugs.launchpad.net/snapcraft/+bug/1610776
<mup> Bug #1610776: "snapcraft push" without registering first should fail fast <Snapcraft:New> <Software Center Agent:New> <https://launchpad.net/bugs/1610776>
<kyrofa> elopio, maybe I should log "if the store is going to 502, do it before it accepts the entire snap" ?
<elopio> oh, right, that's a different error.
<elopio> well, you can always fix it for me :)
<kyrofa> elopio, :P
<kyrofa> When I get my house I've already selected a good-looking ISP. Though 100/100 fiber is going in like a block away :'(
<kyrofa> I've submitted a petition :P
<mup> PR snapd#1615 closed: overlord/snapstate, daemon: support for multi-snap refresh <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1615>
<mvo> om26er: hm, I just tested with the all snap image from today (I uploaded a new one some hours ago) and "sudo snap install --devmode --edge classic ; sudo classic.create" seems to be ok. this was on the pc image . did you have the issue on a different one?
<mup> PR snapcraft#745 closed: Actually return a non-zero error code on errors <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/745>
<om26er> mvo, I was able to enable classic mode once I reflashed the latest image on my RPi
<elopio> kyrofa: seems to have started okay this time.
<kyrofa> elopio, darnit
<mvo> om26er: \o/
<mvo> om26er: thanks
<mup> PR snapcraft#746 opened: Release changelog for 2.15.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/746>
<mup> PR snapd#1606 closed: debian: add extra checks when debian/snapd.postrm purge is run <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1606>
<mup> PR snapd#1708 opened: fix vet error <Created by teknoraver> <https://github.com/snapcore/snapd/pull/1708>
<mup> PR snapd#1709 opened: many: teach prepare-image to copy the model assertion (and prereqs) into the seed area of the image <Created by pedronis> <https://github.com/snapcore/snapd/pull/1709>
<mup> PR snapd#1710 opened: tests: add content-shareing binary test that excersises snap-confine <Created by mvo5> <https://github.com/snapcore/snapd/pull/1710>
<elopio> kyrofa: creating text files doesn't work. I wait for it to say "Saved!", but when I open it again is empty.
<rtsisyk> hi, I requested to register reserved name for my software, but it is still "Pending review"
<rtsisyk> name is "tarantool"
<rtsisyk> who can help me?
<kyrofa> rtsisyk, when did you request it?
<rtsisyk> couple days ago
<kyrofa> nessita, any chance you could help out with that? ^^
<mup> PR snapd#1702 closed: many: preparations for image code to fetch model prereqs <Created by pedronis> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1702>
<elopio> kyrofa: ah, the user has 0 quota. Then it's a bug in nextcloud because it doesn't say anything about it :)
<kyrofa> elopio, did you just create a new user, then?
<elopio> kyrofa: yes.
<kyrofa> elopio, or are you saying by default even the admin has 0 quota?
<elopio> no, admin has unlimited quota by default
<kyrofa> elopio, yeah, that does indeed sound like a nextcloud bug
<elopio> kyrofa: where do I report it?
<kyrofa> elopio, wait, I just tried
<kyrofa> elopio, works fine. On the far right, when you create the user, the quota is available. Any chance you accidentally scrolled or something there?
<kyrofa> elopio, because for me, the default is unlimited
<elopio> kyrofa: yes, the default is unlimited. I had set it to 0. The bug is that when there is no quota left, the text file editor still says: "Saved!"
<kyrofa> elopio, ah ha!
<kyrofa> elopio, I'm not sure if it's part of nextcloud core, or part of the files app
<kyrofa> elopio, but you can probably start with logging against the core: https://github.com/nextcloud/server
<sergiusens> hey ev can you look into ^ (rtsisyk's request for tarantool)
<sergiusens> kyrofa is this the nextcloud snap with letsencrypt all bundled in?
<kyrofa> sergiusens, yeah, on the beta channel
 * sergiusens will wait for stable
<kyrofa> sergiusens, yeah, things will change a little
<elopio> sergiusens: get it while it's hot. Works for me.
 * sergiusens is using too much beta software already ;-)
<nessita> kyrofa, checking
<nessita> kyrofa, approved tarantool but the user left, he will receive an email ne erthelesss
<kyrofa> Thank you nessita :)
<elopio> kyrofa: where does this leave the logs?
<kyrofa> elopio, which logs?
<elopio> the bug template is asking me for the apache and nextcloud logs.
<mup> PR snapd#1622 closed: client, cmd/snap: use the new multi-refresh endpoint <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1622>
<kyrofa> elopio, apache logs are in $SNAP_DATA/apache/logs, nextcloud logs are in $SNAP_COMMON/nextcloud... I think
<elopio> kyrofa: both of those should be in ~/snap/ right?
<elopio> just empty dirs there.
<elopio> oh, no, in /var, ok.
 * ahoneybun finds a inkscape snap
<ahoneybun> mhall119, who handles the snap store
<ahoneybun> ?
<mup> PR snapd#1708 closed: fix vet error <Created by teknoraver> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1708>
<ev> sergiusens: Iâve ferried it along (tarantool)
<qengho> ahoneybun: What are you wanting to do?
<mhall119> ahoneybun: depends on what you mean by "handles"
<ahoneybun> mhall119, launchpad seems to be hitting an 404 error when trying to upload inkscape to the store
<ahoneybun> https://launchpad.net/~inkscape-uploader/+snap/inkscape/+build/3131
<rtsisyk> sorry, I was disconnected
<rtsisyk> Your "tarantool" registration has been approved.
<rtsisyk> thanks a lot!
<mhall119> ahoneybun: ah, maybe cjwatson can see what's going on with that
<mhall119> also, yay inskscape snap!
<qengho> ahoneybun: Have you ever uploaded a snap package to there?
<qengho> $ snap find inkscape   #finds nothing
<ahoneybun> It's not me
<ahoneybun> qengho, ^
<ahoneybun> mhall119, it launches as well
<ahoneybun> and HUD works mhall119 !!!
<elopio> kyrofa: email with the php mode doesn't work.
<qengho> ahoneybun: I suspect you, plural, have to have registered a project to have launchpad upload a package for it first.
<ahoneybun> I did not
<qengho> ahoneybun: Okay. That's your problem, then. Do you know how to?
<ahoneybun> qengho, I don't have a snap to upload
<qengho> ahoneybun: Oh. Here's one. https://launchpad.net/~inkscape-uploader/+snap/inkscape/+build/3131
<ahoneybun> it's not my project to upload dude
<qengho> ahoneybun: Okay. What do you want us to do?
<mhall119> ahoneybun: awesome!
<ahoneybun> qengho, I just wanted to alert someone to the issue and not get a rude answer back
<mhall119> ahoneybun: with --devmode or no?
<ahoneybun> mhall119, standard
<ahoneybun> no --devmode
<mhall119> sweet!
<ahoneybun> it is awesome
<ahoneybun> just need kdenlive to have the software I need
<qengho> ahoneybun: It looks like it succeeds sometimes, yes?  https://launchpad.net/~inkscape-uploader/+snap/inkscape/+build/3134
<qengho> ahoneybun: I don't know what the first problem is.
<ahoneybun> qengho, you can't find it in the search if it is
<ahoneybun> well
<ahoneybun> it might be in the other channels
<ahoneybun> since it is only a devel version
<ahoneybun> never thought of that
<MrChrisDruif> Hey guys, where would you recommend I start reading up on how snaps works on a semi-technical level?
<MrChrisDruif> Because I know there is a snap for Nextcloud but afaik it uses the Apache server by default to run.
<qengho> ahoneybun: I don't know a way to "snap find" in other channels. :(
<ahoneybun> neither do I
<MrChrisDruif> And that is a bit needlessly killing resource on something like a Raspberry Pi 1 B+
<ahoneybun> that LP link has the snap though
<qengho> MrChrisDruif: We have some light docs, but there's nothing that will change the nextcloud snap into working that differently.
<qengho> MrChrisDruif: The kind of think you could do is make a new snap that does what you want.
<qengho> thing
<MrChrisDruif> qengho: So it doesn't look into running services?
<MrChrisDruif> Apache is just the web server part of the configuration
<MrChrisDruif> It doesn't check if one is already running one, like Nginx?
<ahoneybun> qengho, reading man snap shows a way to install from the other channels
<ahoneybun> mhall119, is there a place we can find snaps other then 'snap find'?
<mhall119> uappexplorer.com
<mhall119> Ubuntu Software
<sergiusens> MrChrisDruif it s all in the same snap
<mhall119> those all only find snaps in the stable channel though, so if you use confinement: devmode or only publish to edge/beta channels you won't see them
<sergiusens> MrChrisDruif think of it as a complete product; if you need a different product, it would be a different snap
<sergiusens> MrChrisDruif also, rpi 1 is armel, not supported by Ubuntu for some years now
<MrChrisDruif> sergiusens: thanks. It wasn't the answer I was hoping for, but at least it is an answer =)
<MrChrisDruif> sergiusens: true but isn't snappy "cross-platform"? ;-)
<ahoneybun> man my wifi is bad on 16.04
<sergiusens> MrChrisDruif yes, but that doesn't mean every piece of hardware on the planet ;-)
<sergiusens> MrChrisDruif it doesn't support MIPS either
<sergiusens> MrChrisDruif that said, even if it were on Ubuntu you'd need to convince the publisher for those apps to build for those esoteric devices
<mreed> nessita, ping
<MrChrisDruif> sergiusens: calling the RPi esoteric is overstating I think ;-)
<sergiusens> MrChrisDruif a real world example for that today is android on x86, the app selection there is much smaller
<sergiusens> MrChrisDruif an rpi 1 yes :-)
<sergiusens> and rpi in general, no
<mreed> nessita, can you review my snap?  https://myapps.developer.ubuntu.com/dev/click-apps/5749/rev/1/
<ahoneybun> any ideas about this: http://pastebin.ubuntu.com/23068283/
<sergiusens> we don't support the RPi Zero either MrChrisDruif
<ahoneybun> No module named 'gi'
<ahoneybun> but I have python3-gi in staged
<ahoneybun> the snap builds fine
<ahoneybun> Pithos is the project btw
<MrChrisDruif> sergiusens: I don't own one of those so I don't care ^_^
<MrChrisDruif> Yeah it sucks for the owners of Zero's but I don't care O=)
<ali1234> ARMv6 just refuses to die
<MrChrisDruif> ali1234: just like IPv4, 32-bit and that NSA forcefully crippled encryption level...
<ali1234> 32 bit x86 is dead
<MrChrisDruif> On it's dying breath but not completely dead...
<ahoneybun> mm I think I found the issue
<ahoneybun> the snap is looking the python3-gi libs in /usr/lib/python3/dist-packages
<ahoneybun> but it is not in there
<ahoneybun> looking at this :http://packages.ubuntu.com/xenial/amd64/python3-gi/filelist
<ahoneybun> any idea
<ahoneybun> mhall119, I see you got the new content sharing thing to work
<mhall119> ahoneybun: mostly working
<mhall119> I ran into this: https://bugs.launchpad.net/snap-confine/+bug/1615113
<mup> Bug #1615113: snap-confine prevented from mounting base directory through the "content" interface <Snappy Launcher:New> <https://launchpad.net/bugs/1615113>
<ahoneybun> it seems python3-gi is what I need but the lib are not going to the right place
<mhall119> jdstrand: if you're still around, can you take a look at the diff in the bug description in ^^ and comment on whether or not it's a bad idea
<ahoneybun> not even sure they are there
<mhall119> ahoneybun: do you have python3-gi in your stage-packages list?
<ahoneybun> yep
<ahoneybun> the snap is looking the python3-gi libs in /usr/lib/python3/dist-packages
<ahoneybun> which is right
<ahoneybun> looking at this :http://packages.ubuntu.com/xenial/amd64/python3-gi/filelist
<ahoneybun> but I don't see any of those files in there
<ahoneybun> it's even in the build-packages
<ahoneybun> as it is needed to build
<mhall119> ahoneybun: can you share your whole snapcraft.yaml?
<mhall119> the snap should look in ${SNAP}/usr/lib/ not /usr/lib/
<ahoneybun> I used a extra thing to change that
<ahoneybun> http://pastebin.ubuntu.com/23071449/
<ahoneybun> also error : http://pastebin.ubuntu.com/23068283/
<mhall119> ahoneybun: put python3-gi in your stage-packages, not just build-packages
<mhall119> build-packages are installed to your host, stage-packages are installed into the snap
<mhall119> so anything you need at runtime should be in stage-packages or otherwise installed by the plugin
<ahoneybun> it;s in both
<mhall119> and it looks like you could move your stage-packages section out of pithos-run and into the pithos part, then drop pithos-run altogether
<mhall119> ahoneybun: not in the pastebin you gave me
<mhall119> it's only on line 34
<ahoneybun> I removed it as it does nothing
<ahoneybun> did nothing
<mhall119> do you see it in ./prime/usr/lib/python3/dist-packages/
<mhall119> ?
<mup> Bug #1614177 opened: Can not connect cups-control interface  <snapd-interface> <Snappy:Incomplete> <https://launchpad.net/bugs/1614177>
<ahoneybun> no just a pkg_resource dir
<ahoneybun> but I have not rebuilt it with python3-gi in stage yet
<ahoneybun> you broke my yaml
<ahoneybun> Issue while loading plugin: properties failed to load for pithos: Additional properties are not allowed ('configflags', 'source' were unexpected)
<ahoneybun> since I took out pithos-run
<mup> Bug #1615124 opened: my snap apps should be able to run /usr/bin/* <Snappy:New> <https://launchpad.net/bugs/1615124>
<sabdfl> jhobbs, ogra_, actually i believe tvoss and others are looking into snapd on 14.04
<sabdfl> i haven't had an update recently but in leiden it was described as hackable
<ahoneybun> I swear snap errors are the worst
<ahoneybun> the word choices are just bad
<tvoss> sabdfl: yup, we are making good progress, a ppa with all required packages is here: https://launchpad.net/~thomas-voss/+archive/ubuntu/trusty, testing instructions are here: https://docs.google.com/document/d/1z64VCTX9kU43Xb2wSDQN7g6QHuFStFGZqEBoEQbI6oQ/edit
<tvoss> ogra_, jhobbs ^
<tvoss> I mostly focused on 14.04(.5) server images thus far
<jhobbs> sabdfl, tvoss: awesome, thanks, i'll have a look there
<ogra_> sabdfl, ooh
<ogra_> tvoss, +1 !
<mhall119> ahoneybun: pastebin your new snapcraft.yaml
<tvoss> jhobbs: let me know how it goes, you could also just leave comments on the doc
<sabdfl> phwoar tvoss that is awesome
<sabdfl> jhobbs, share your experience after testing please :
<sabdfl> :)
<tvoss> sabdfl: also credits to pitti for helping out with the systemd specifics
<sabdfl> this will be super useful for cloud bits
<sabdfl> thanks pitti :)
<jhobbs> tvoss, sabdfl, will do
<notadeveloper_> got an rpi3
<notadeveloper_> and snappy 1604
<notadeveloper_> how do i install audio drivers
<wililupy> Question: looking at trying to port flexswitch from deb to snap, but not quite sure where to start with this. It is built from a bunch of python scripts that download other git repositories and debian dependancies, and then builds it into a nice debian package, but not quite sure how to best approach this for snapcraft.
<mup> PR snapcraft#746 closed: Release changelog for 2.15.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/746>
<tvoss> okay, calling it a day
<tvoss> have a nice weekend everyone
<sabdfl> wililupy, hi
<sabdfl> things that are very easy to snap are things which can be built, installed and run in a developer home directory as a non-root user
<sabdfl> that's unlikely to cover flexswitch though, but it's useful to keep in mind that the main areas to look out for are:
<sabdfl>  - where you read and write files (the run-from-$HOME test is really about whether you need to write all over the root filesystem)
<sabdfl>  - how much you poke at kernel or other structures (in your case i suspect you are working with networking structures)
<sabdfl> in the first case, a snap by default gets versioned and unversioned data directories, for a user and for the system (so thing of it as a 2x2 grid)
<sabdfl> by versioned we mean "backed up automatically on upgrade"
<sabdfl> which is part of the transactionality
<sabdfl> say you are a game, you would not version the common data files (images) but you would version the saved game history etc
<sabdfl> in the flexswitch case i suspect you have relatively little local data so just version it all would be my recommendation
<sabdfl> but you'll need to be able to tell flexswitch to use $SNAP_DATA to write in
<cjwatson> ahoneybun,mhall119: looks very clearly like a software-center-agent bug - please file it as a bug against that
<cjwatson> [2016-08-19 01:31:38,129: DEBUG/Worker-3] "POST /unscanned-upload/ HTTP/1.1" 200 None
<cjwatson> [2016-08-19 01:31:38,324: DEBUG/Worker-3] "POST /dev/api/snap-push/ HTTP/1.1" 202 None
<cjwatson> [2016-08-19 01:31:38,622: DEBUG/Worker-3] "GET /dev/api/snaps/tIrcA87dMWthuDORCCRU0VpidK5SBVOc/builds/06ba2029-8c39-47ff-b862-cb4ca81a5db0/status HTTP/1.1" 404 None
<sabdfl> on the second front, there are what are known as "interfaces" which define security access profiles
<sabdfl> and there are probably already all the interfaces you need to snap up flexswitch
<cjwatson> so SCA returns a status URL that it then later claims doesn't exist, which is pretty bad form of it
<sabdfl> since quite a few networking snaps already exist
<cjwatson> qengho: ^- FYI - can't have been the thing you suggest about needing to register it first, because that would have failed much earlier in the process
<sabdfl> wililupy, make sense?
<sergiusens> cjwatson interesting, I was assured that we only got a response once the url existed
<cjwatson> sergiusens: that is definitely how it should be.  there's got to be a race somewhere here
<cjwatson> sergiusens: my first guess would be something to do with multiple appserver units but it'll take some trawling through logs
<cjwatson> (which I'm not going to try to track down after 11pm on a Friday, sorry!)
<wililupy> sabdfl that does. This application includes the modules for a specific kernel, which adds a "twist" to it, but I like a challenge.
<ahoneybun> mhall119, on a site note I have the gi dir in stage/usr/lib/python3/dist-packages/ now
<ahoneybun> mm same error though...
<ahoneybun> new yaml : http://pastebin.ubuntu.com/23071795/
<ahoneybun> might be a new pithos release by the time I get this to work lol
<sergiusens> cjwatson I am in no hurry at all ;-)
<mup> PR snapd#1692 closed: asserts: add serial-proof device assertion <Created by matiasb> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1692>
<ahoneybun> man this error is kicking my but
<ahoneybun> *butt
<ahoneybun> I made the a python file with the same import and it works with no error
<ahoneybun> so I might be missing a package, or the snap is looking in the wrong place
<nacc> ahoneybun: what's the error you are getting now?
<ahoneybun> same one
<ahoneybun> ImportError: No module named 'gi'
<ahoneybun> http://pastebin.ubuntu.com/23068283/
<ahoneybun> whole error
<ahoneybun> I can run a python file like that with no problems on the sustem
<ahoneybun> *system
<nacc> ahoneybun: in your snap's squashfs (unsquashfs -l might help list contents), is the gi module present? Is your app for some reason trying to use python2 rather than python3?
<ahoneybun> the depends are python3
<ahoneybun> I see something about gi in /usr/lib/python3/dist-packages in stage
<ahoneybun> yaml file: http://pastebin.ubuntu.com/23071837/
<ahoneybun> I'm following the deps of the package to build from source and what it needs from apt
<nacc> ahoneybun: ack, looking at it locally to see if i can help
<ahoneybun> thanks nacc
<nacc> taking a while to cleanbuild due to the number of deps, i think
<nacc>  / my home network being unreasonably slow
<ahoneybun> damn
<nacc> hrm, my build failed with http://paste.ubuntu.com/23071850/, which i've run into before due to locale sutff
<nacc> *stuff
<ahoneybun> looks like local issue
#snappy 2016-08-20
<sabdfl> wililupy, is there a switchdev version of your code?
<wililupy> sabdfl: no. This is all based on OpenNSL and OpenNetworkLinux.org kernel source.
<sabdfl> ok, if there are generally-useful modules we will carry them in the common kernel, otherwise making your own kernel snap is pretty easy
 * ahoneybun bangs head on desk
<sabdfl> ahoneybun, its very satisfying when you get to full confinement :)
<leftyfb> I'm just getting started with snappy. Can someone explain this to me? http://pastebin.com/yMDSMNZv
<ahoneybun> sabdfl, it's not past even opening up yet
<ahoneybun> no devmode is whole different beast
<sabdfl> leftyfb, what's in /snap/bin/ ?
<leftyfb> sabdfl: as, so there it is. I guess I have to add /snap/bin to $PATH?
<sabdfl> yes, i'm trying to figure out why i never had to do anything special for that
<ahoneybun> sabdfl, can't even find why it runs on my machine but not the snap
<sabdfl> basically, snapd parses the snap metadata (snap.yaml) and it creates things in /snap/bin/ so you get them on your $PATH
<nacc> leftyfb: where were you installing it? 16.04?
<leftyfb> nacc: yes
<leftyfb> nacc: recently upgraded from 14.04
<sabdfl> leftyfb, I have /snap/bin/ as the last item in $PATH but i'm not sure where that is set
<sabdfl> i know the recend sudo update added it for the sudo case
<leftyfb> sabdfl: usually ~/.bashrc and/or ~/.profile
<nacc> looks to be /etc/profile.d/apps-bin-path.sh
<nacc> from snapd package
<sabdfl> thanks nacc
<sabdfl> ahoneybun, as you can see you are better off with nacc's help than mine :)
<nacc> sabdfl: np, wondered the same thing myself :)
<ahoneybun> I think I throw nacc off too lol
<ahoneybun> the libs are there
<ahoneybun> no idea if the snap is looking in the wrong place or what
<nacc> leftyfb: odd that your profile isn't sourcing that, wonder if it's a quirk of the upgrade
<sabdfl> ahoneybun, what's the name of the snap?
<ahoneybun> Pithos
<ahoneybun> the pandora player client
<ahoneybun> trying to snap the new 1.2.1 build
<leftyfb> nacc: any idea where that should be sourced? Something in /etc/ * assume
<sabdfl> i think there is a way to get a shell with the same confinement.... 'snap run --shell pithos' perhaps?
<nacc> leftyfb: iirc, /etc/profile sources any .sh files
<sabdfl> leftyfb, what's your $SHELL?
<tsimonq2> ooh Pithos would be a great snap :)
<tsimonq2> I love it
<ahoneybun> tsimonq2, if I could get it to start at all
<leftyfb> sabdfl: bash
<sabdfl> leftyfb, oh well if you want to go using weird stuff like...
 * ahoneybun found a inkscape snap today
<tsimonq2> ahoneybun: let me know :)
<ahoneybun> know what?
<tsimonq2> when you get it working
<tsimonq2> o/ sabdfl, how are you? :)
<ahoneybun> that might be the 1.2.3.... or on release ll
<sabdfl> ahoneybun, can you stick a bin/bash in your snap? then the snap run --shell cmd will work iirc
<sabdfl> tsimonq2, good thanks, you?
<ahoneybun> what sabdfl ?
<tsimonq2> great sabdfl :)
<leftyfb> yeah, it's odd. It looks like I'm not sourcing /etc/profile.d/apps-bin-path.sh even when logging out and back in
<sabdfl> ahoneybun, are you the author of this snap, or just consuming it?
<ahoneybun> tsimonq2, I think gi.repository is a python thing
<ahoneybun> sabdfl, I did not write the app, just trying to make it a snap
<sabdfl> not in store so I assume you are making the snap?
<sabdfl> right
<sabdfl> you can add a command to the snap, which is a shell
<ahoneybun> but what help does that give me?
<sabdfl> i think you basically can just copy /bin/bash into your snap at bin/bash
<nacc> leftyfb: very strange, is this in your /etc/profile ? http://paste.ubuntu.com/23071877/
<sabdfl> i think it will let us debug things more easily
<sabdfl> aiui you have a problem with python not finding a lib
<nacc> ahoneybun: it would let you drop into the snap's env and then you can try to figure out what your snap's executable is seeing
<ahoneybun> I don't get the error on my machine so it must be missing a package
<leftyfb> nacc: yes
<nacc> ahoneybun: or in this , not seeing :)
<sabdfl> that will be easier to debug if we can pretend to be python and go looking for it
<ahoneybun> mm go on sabdfl ;)
<nacc> leftyfb: really strange!
<sabdfl> basically, each snap runs in its own little world where it sees glimpses of what other snaps provide
<ahoneybun> how do I add this?
<sabdfl> it sees a glimpse of the core snap ("ubuntu-core") and it sees its own files
<sabdfl> and it may see things from other snaps too (thats what plugs and slots do)
<sabdfl> those pieces are arranged so that the snap can get on and do what it does but not taint any other snap
<nacc> ahoneybun: you'd add another 'app', i think, say 'pithos-shell' which just runs bash, and add a part that copies your system's /bin/bash into the snap, i believe
<sabdfl> nacc, we should definitely make this a built-in thing so you don't need the boilerplate
<nacc> sabdfl: absolutely, esp. in devmode :)
<leftyfb> nacc: yep. I've noticed a few things with the upgrade. terminator crashes more often then I would like. Shutdown takes longer than it should. The notifications indicator doesn't always start on boot. And I have to restart NM in order for vpn item in NM to not be greyed out for me to click it.
<nacc> sabdfl: given one could assume you're developing then :)
<sabdfl> https://github.com/snapcore/snapcraft/blob/master/tour/00-SNAPCRAFT/02-parts/snapcraft.yaml
<sabdfl> that's a fairly blunt example (haven't tried it) which actually looks like it builds bash
<ahoneybun> I might be missing a full steps
<sabdfl> a simpler one would just COPY it in
<sabdfl> but the point is if you add that you can run pithos.bash
<sabdfl> and THEN you have a shell which sees the same slices of reality that your python app does
<sabdfl> i.e. the filesystems and kernel permissions etc are the same
<nacc> including in particular, in this case, if that gi modules is present
<sabdfl> then you can just poke around and more easily see what is really going on
<sabdfl> ahoneybun, pastebin your snapcraft.yaml
<sabdfl> or snap.yaml if you are doing things the heroic manual way
<ahoneybun> http://pastebin.ubuntu.com/23071882/
<ahoneybun> yea I just broke things trying that bash thing
<ahoneybun> tsimonq2, the inkscape snap has access to the HUD too
<ahoneybun> which is super cool
<nacc> ahoneybun: can you pastebin the output of `unsquashfs -l pithos_ahoneybun_1.2.0_amd64.snap`?
<nacc> err, pithos-ahoneybun, sorry
<ahoneybun> no such file or dir
<nacc> sorry, i was sort of guessing on the resulting snap's name; it'd be something.snap in the same directory you ran `snapcraft build` in
<ahoneybun> the .snap you mean?
<ahoneybun> let me build the snap again
<nacc> ahoneybun: yeah, the resulting .snap (which is just a squashfs fs)
<nacc> sabdfl: filed LP: #1615163
<mup> Bug #1615163: shell boilerplate could be automatically added when building in devmode <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1615163>
<ahoneybun> nacc, http://paste.ubuntu.com/23071892/
<ahoneybun> sorry about the wait
<ahoneybun> god I love pastebinit tsimonq2
<sabdfl> ahoneybun, try this part in your snapcraft.yaml:
<sabdfl>   bash:
<sabdfl>     plugin: copy
<sabdfl>     source: bin/
<sabdfl>     files:
<sabdfl>       bash: bin/bash
<sabdfl> erk sorry meant to pastebin that
<sabdfl> you will need to make a bin/ directory in your snap source tree and copy /bin/bash into that
<sabdfl> then add this to your apps: stanza in snapcraft.yaml
<sabdfl>   bash:
<sabdfl>     command: bin/bash
<sabdfl> I *think* that will get you a bin/bash in your snap
<nacc> ahoneybun: np, looking at it now
<ahoneybun> sabdfl, going to see what nacc and I can get from that other way first
<sabdfl> ok
<nacc> ahoneybun: for my own edification, is /snap/pithos-ahoneybun/x1/usr/bin/pithos a python script?
<sabdfl> i'm testing here on my own snap and it seems to work
<sabdfl> the net effect is I can then run snapname.bash
<nacc> sabdfl: yeah that should work, agreed (note that copy is deprecated in favor of dump :)
<sabdfl> and i am in the sandbox that the snap lives in
<sabdfl> nacc, yeah, i couldn't figure out the help text for dump :p
<nacc> ahoneybun: (note the x<#> may vary depending on if you've done more revisions since the paste)
<sabdfl> x# is code for "local revision #"
<nacc> sabdfl: :) i had the same issue, hence my bug report says i'm not entirely sure if it works as written :)
<ahoneybun> I don't see that file nacc
<sabdfl> ok, i'm retiring for the day, nice to meet you ahoneybun i look forward to trying your snap. yours too wililupy
<nacc> ahoneybun: when you run the app now, doesn't it say something like "File ..., line 8, in <module>" in the traceback?
<ahoneybun> it's in /bin now
<ahoneybun> need to go
<wililupy> have a great evening sabdfl
<nacc> ahoneybun: me too, will try and be around next week
<mup> PR snapd#1693 closed: tests: add qemu to our spread.yaml and update README <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1693>
<mup> PR snapd#1693 closed: tests: add qemu to our spread.yaml and update README <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1693>
<mup> PR snapd#1711 opened: tests: disable unity test <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1711>
<stgraber> c
<stgraber> oops :)
<mup> PR snapd#1711 closed: tests: disable unity test <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1711>
<mup> PR snapd#1706 closed: tests: add process-control interface spread test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1706>
<mhall119> ahoneybun: you around? I figured out your problem
<mhall119> ahoneybun: unfortunately it won't get you very far, pithos looks to be a mess of hardcoded paths
<ahoneybun> the file is in the right place
<ahoneybun> that's what's weird
<ahoneybun> ls prime/share/pithos/
<ahoneybun> pithos.gresource
<mhall119> ahoneybun: the problem is your #! line in ${SNAP}/bin/pithos is telling it to use the system python, not the snap's python
<mhall119> ahoneybun: change your snapcraft app command to this:
<mhall119> command: desktop-launch python3 ${SNAP}/bin/pithos
<mhall119> that will use the snap's python3, so it will find gi.repository
<ahoneybun> it found that now
<mhall119> but it will fail a little further down, when it's using more hardcoded paths to load files
<ahoneybun> that part
<ahoneybun> Ihttp://pastebin.ubuntu.com/23072018/
<ahoneybun> http://pastebin.ubuntu.com/23072018/
<ahoneybun> funny that the file is in the right place and name
<ahoneybun> so it gets to this part of bin/pithos resource = Gio.resource_load(os.path.join(pkgdatadir, 'pithos.gresource'))
<mhall119> and pkgdatadir is /share/pithos
<mhall119> which is not the right directory
<ahoneybun> it is
<ahoneybun> pithos-ahoneybun/x1/share/pithos/
<mhall119> which is not the same as /share/pithos
<ahoneybun> mm
<mhall119> your snap isn't a chroot
<mhall119> in a snap means / on your machine
<ahoneybun> I COULD change the pkgdatadir or something to ${SNAP} but it would brake with every release
<ahoneybun> or something similar
<mhall119> yeah, really upstream should be using XDG_DATA_DIRS or something like that, rather than hardcoded paths
<ahoneybun> so pointless snap idea then?
<mhall119> depends on how willing upstream is to take patches from you to improve it
<ahoneybun> no idea how to make it better
<ahoneybun> it's on github so it is possible to do requests
<mhall119> I know someone was workign on some runtime hack to redirect attempts to read from /usr/share/ to account for things like this, but I don't know how far along that is
<ahoneybun> I'd rather avoid hacks tbh
<ahoneybun> funny someone made a flatpak
<mhall119> flatpaks are chroots, or containers, or something more separate from the host machine than snaps are
<ahoneybun> mm
<ahoneybun> ack
<ahoneybun> snapcraft is so picky on spacing
<mhall119> spacing?
<ahoneybun> yea
<ahoneybun> found character '\t' that cannot start any token on
<ahoneybun> about to give up man
<ahoneybun> just keeps yelling about it
<tsimonq2> ahoneybun: don't give up, give up for the day, sure, but Pithos snap... :O
<ahoneybun> tsimonq2, that one is not going to work
<ahoneybun> atm I'm messing with Geary
<tsimonq2> oh
<ahoneybun> yep
<ahoneybun> can snap deal with deb files?
<mhall119> ahoneybun: that's probably yaml, not snapcraft
<ahoneybun> well
<ahoneybun> it handles .git fine
<ahoneybun> nice to know
<ahoneybun> trying to snap otter-browser atm
<ahoneybun> really rare to see you up mhall119
<ahoneybun> https://github.com/OtterBrowser/otter-browser
<mhall119> yeah, I've been trying to find a way to make pithos work without patching it.......spent too long on it
<ahoneybun> mhall119, sorry about that
<ahoneybun> don't worry about it
<ahoneybun> first time very rarely works on anything
<mhall119> not your fault, I just can't turn away from a challenge :)
<ahoneybun> I kinda can
<ahoneybun> hitting a xcb error atm
<ahoneybun> added libqt5gui5 but no dice
<ahoneybun> mhall119, trying to find *something* that I can snap right lol
<mup> PR snapd#1609 closed: overlord/devicestate: first pass at device registration logic <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1609>
<sabdfl> ahoneybun, mhall119, didya crack it?
<MrChrisDruif> So I've got quassel-core installed on my Raspberry Pi. Should make me a little more connected to IRC again.
<mup> PR snapd#1712 opened: asserts/sysdb: embed the new format official root/trusted assertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/1712>
<mup> PR snapd#1713 opened: tests: start teaching the fakestore about assertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/1713>
<eldarkg> \HELP
<eldarkg> Hello guys. How to do snap app to open URL retranslating to the system browser or the system application (like evince for PDF)?
<qengho_> eldarkg: I don't think it can. You can not expect any browser or PDF viewer to exist, unless it's provided by your snap.
<eldarkg> qengho_: What about xdg-open to open file if mime exist?
<eldarkg> qengho: What about this https://bugs.launchpad.net/snappy/+bug/1580740 ?
<mup> Bug #1580740: [SRU] Cannot open a browser link from a snap that provides a link <snap-desktop-issue> <verification-needed> <Snappy:Triaged> <snapd-xdg-open (Ubuntu):Confirmed> <snapd-xdg-open (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1580740>
<qengho> eldarkg: Yes? What about it?
<eldarkg> qengho: I failed
<mhall119> sabdfl: we fixed one problem, but pithos has so many hardcoded paths that it will take quite a bit of patching to make it work
<mhall119> eldarkg: it's being worked on, if not already working
<mhall119> the tl;dr is that your snap will need to call a special version of xdg-open that will pass the URI over to the real thing
<mhall119> using a trusted mediator that will let it open the webbrowser outside of your snap's confinement
<eldarkg> mhall119: Where I can to get information about how to configure my snap?
<eldarkg> mhall119: or example snap?
<mhall119> eldarkg: to open urls externally, or in general?
<mhall119> http://snapcraft.io is good for general info on snapping
<mhall119> judging by the bug report you posted above, I don't think the new snap-xdg-open stuff is landed yet
<eldarkg> mhall119: I snap kicad. Kicad have documentation in html format that opened from kicad that retranslated to web-browser.
<mhall119> so that's what this snap-xdg-open project is going to fix, it will pass the documentation file URI outside of your snap's environment so it can be opened in the system browser
<eldarkg> I thought may be exist another ways to solve this problem
<mhall119> you could possibly include xdg-open and a lightweight browser in your snap, but I'm not sure to tell xdg-open how to find the in-snap browser
<eldarkg> mhall119: Thank you. But I don't want to include browser in snap
<mhall119> eldarkg: that's going to be the best long-term anyway, check back here on Monday and see if attente or elopio are give you an ETA on when snap-xdg-open will be available
<eldarkg> mhall119: ok
<mup> Bug #1615248 opened: ubuntu-core-launcher nvidia driver detection is bogus <Snappy:New> <https://launchpad.net/bugs/1615248>
<sabdfl> mhall119, what's the best way to uncerstand wrapper commands?
<sabdfl> understand, even
<sabdfl> i'm snapping up something cloudy and snapcraft made me a command-foo.wrapper
<sabdfl> but i want to make a custom one, where to put it?
<ogra_> sabdfl, that wrapper is always there to set up the snap env ... just create a wrapper.sh (or omit the  .sh) that does what you want and define it as the executable in your apps entry
<ogra_> sabdfl, here is a very simple example https://github.com/ogra1/laidout
<sabdfl> thanks folks
<sabdfl> is $SNAP_COMMON the unversioned system directory?
<sabdfl> data directory
<ogra_> yep
<ogra_> ogra@anubis:~/datengrab/devel/branches/dragonboard-kernel-snap$ hello-world.env |grep COMMON
<ogra_> SNAP_USER_COMMON=/home/ogra/snap/hello-world/common
<ogra_> SNAP_COMMON=/var/snap/hello-world/common
<sabdfl> oh this is exciting
<sabdfl> ogra_, does it make sense to use $SNAP_COMMON if run as root, $SNAP_USER_DATA otherwise?
<sabdfl> and... how do I test if I am root in the wrapper?
<sabdfl> sergiusens, who do i need to ask about registering a name that i think is already reserved?
<ogra_> if [ "$(id -u)" = "0" ]; then
<ogra_>     echo "i'm root"
<ogra_> fi
<ogra_> sabdfl, i guess the $SNAP_USER_DATA vs $SNAP_COMMON is personal preference ... if it is some actual enduser tool i'd use $SNAP_USER_DATA though ... if it is something for i.e. system management/maintenance i'd pick a system dir like $SNAP_COMMON
<sabdfl> it's an interesting one
<sabdfl> it usually runs as a daemon as root
<sabdfl> which suggests to use the system writable dirs
<sabdfl> but you can also run it as a user
<sabdfl> in which case, in the classic world, it just writes wherever you are or where you tell it to
<sabdfl> which feels more like $SNAP_USER_DATA
<ogra_> yeah
<ogra_> so $SNAP_COMMON for system ... $SNAP_USER_DATA for non-root sounds logical
<sabdfl> is there a convenient interface for sending messages to the systemd journal?
<sabdfl> pitti, ^?
<Son_Goku> sabdfl, there's socket and dbus interfaces for it
<Son_Goku> and I believe go bindings as well, so you could craft a custom interface
<Son_Goku> https://github.com/coreos/go-systemd
<sabdfl> thanks Son_Goku
<sabdfl> the app i am snapping up may well be using that code
<Son_Goku> sabdfl, if I may ask, what are you snapping?
<sabdfl> Son_Goku, etcd
<Son_Goku> then it is very likely using that code
<sabdfl> i think i just need a tiny interface added to snapd
<sabdfl> :) yes
<sabdfl> small world huh
<Son_Goku> heh
<sabdfl> now i've got to dive into the make-a-smll-new-interface rabbit hole :)
<sabdfl> jdstrand,  could you look at https://bugs.launchpad.net/snappy/+bug/1615262 ?
<mup> Bug #1615262: Cannot send message to systemd-journald <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1615262>
<mup> Bug #1615262 opened: Cannot send message to systemd-journald <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1615262>
<sabdfl> Son_Goku, i have a test snap, want to try it out?
<sabdfl> 3.0.6-master
<Son_Goku> why not? :P
<Son_Goku> give me a tick to get my Linux machine
<sabdfl> pffst
<jaymell> I was curious if anyone has pointers on getting spread tests to work in linode. I've tried using the stock Ubuntu 16 image with custom kernel (ie, one that supports AppArmor), but have had no luck in running through the tests. Are there any additional customizations I would need to make to the image in order for tests to run successfully? Thx
<sabdfl> jaymell, niemeyer is a linode user and also mr spread, so a good person to ask
<Son_Goku> ....
<Son_Goku> I'm getting this error when trying to search for snaps: "error: cannot list snaps: net/http: Client Transport of type *store.LoggedTransport doesn't support CancelRequest; Timeout not supported"
<Son_Goku> oh, I'm so stupid
<sabdfl> Son_Goku, fwiw i have not uploaded to the store yet
<Son_Goku> I have to be root to do stuff with snap
<Son_Goku> sabdfl, so where do I get your snap?
<sabdfl> Son_Goku, you can 'snap login email@foo.com' using your Ubuntu SSO email address (LP email I think)
<sabdfl> then you can do stuff as your user iirc
<Son_Goku> ah
<Son_Goku> still broken
<sabdfl> Son_Goku, are you up to date?
<sabdfl> snap find working fine here
<Son_Goku> snapd-2.12
<Son_Goku> that's the latest release as of 9 days ago
<sabdfl> snap refresh ?
<sergiusens> sabdfl for reserved names either ev, noise][, nessita or cprov
<sergiusens> aka, store folk ;-)
<sabdfl> coolio thanks sergiusens
<niemeyer> jaymell: It just needs a custom image that has the upstream Ubuntu kernel rather than Linode's as you point out, and as documented in Linode
<sabdfl> Son_Goku, i can email it to you
<Son_Goku> sabdfl, okay, cool
<niemeyer> jaymell: You'll need to name the image as expected by the tests
<niemeyer> ubuntu-16.04-64-grub, for the 64bit one
<niemeyer> jaymell: That grub suffix is a hack that is already obsolete, and will be dropped next week.. spreads but those images with the GRUB 2 "kernel" of Linode.. now this is more explicit.. it will be just
<niemeyer> ubuntu-16.04-64:
<niemeyer>         kernel: GRUB 2
<sabdfl> niemeyer, does the go plugin to snapcraft handle setting up GOPATH nicely?
<niemeyer> sabdfl: Yeah, works out of the box.. ley me give you a link..
<niemeyer> sabdfl: https://github.com/niemeyer/snaps/blob/master/mup/mup-plugins/snapcraft.yaml
<jaymell> niemeyer: Thanks, I think I got all that working -- I'm just getting a lot of random errors in the tests themselves. It sounds like I'm on the right track, though, let me see if I need to go back and fix some of the hacking I did to spread.yaml
<niemeyer> jaymell: Ohh, wait..
<niemeyer> jaymell: When was your spread and snapd code last updated?
<jaymell> Should be latest as of last evening for both -- maybe I should be using a particular version of spread rather than the latest?
<niemeyer> jaymell: I released a new incompatible spread release overnight, and merged fixes on snapd itself at the same time
<niemeyer> jaymell: Sent a note to snapcraft@ ML about the fact this was coming, and pinged the thread once it was in
<jaymell> niemeye: Ok, just did a pull in both repos, do you think using the latest in both will likely resolve things?
<jaymell> niemeyer: In any case, I'll give things a try again later this evening. I was more worried that I was doing something fundamentally wrong, but it sounds like I just need to dig a bit more into the errors I'm getting. Thanks for the info!
<mup> PR snapd#1714 opened: many: hook in start of code to fetch/check assertions when installing snap from store <Created by pedronis> <https://github.com/snapcore/snapd/pull/1714>
<niemeyer> jaymell: Well, I hope so.. Travis is passing with master
<niemeyer> jaymell: If it doesn't , just ping me
<ev> sabdfl: can I trouble you to fill out https://myapps.developer.ubuntu.com/dev/click-apps/register-name/ ?
<sabdfl> ev sure, if you can tell me what a developer namespace is really for :)
<niemeyer> jaymell: This is tip of snapd, runs against Linode: https://travis-ci.org/snapcore/snapd/jobs/153754133
<ev> sabdfl: weâre moving that over to proper SSO usernames, but itâs further down in the backlog. I was never a fan, but other priorities win out.
<sabdfl> ev so i should say 'sabdfl' ?
<ev> yes please
<sabdfl> ev done, thanks for the pointer :)
<ev> anytime!
<ogra_> funny how everyone is around on a saturday :)
<sergiusens> ogra_ I am not, I just happen to be on and off ;-)
<sabdfl> sergiusens, if you are on again briefly, can you remind me how to make a custom plugin, or point me at one?
<sabdfl> iirc it's call it x-foo and stick it somewhere specific?
<ogra_> sergiusens, heh, same here i have "fix the heating while susie is away" weekend :) ... so i'm procastinating instead of cleaning the oli furnace ;)
<ogra_> *oil
<ogra_> :P
<ogra_> (not freudian ... promised)
<sabdfl> olli will be relieved :)
 * ogra_ spent most of his day with half his body in that thing ... scratching oil coal off the walls ... i look like a chimney sweep 
<tsimonq2> sabdfl: a custom plugin that's snap-specific?
<tsimonq2> sabdfl: or a global plugin to go into Snapcraft?
<sabdfl> tsimonq2, yes, i have an upstream that has a build command of its own (not a Makefile or anything standard)
<sabdfl> i just want to set an environment variable and run that command
<ogra_> well, worst case you can always cheat and just wrap a makefile around it
<tsimonq2> sabdfl: here's an example in the Snappy Playpen: https://github.com/ubuntu/snappy-playpen/tree/master/atom
<tsimonq2> Snappy Playpen to the rescue! \o/
<tsimonq2> sabdfl: or this is without a wrapper if it makes things easier to read :) https://github.com/ubuntu/snappy-playpen/tree/master/idea
<tsimonq2> sabdfl: what are you snapping? :)
<sabdfl> tsimonq2, etcd
<sabdfl> i use it for a project and xenial does not have 3.0
<tsimonq2> oh cool :)
<tvoss> o/
<ahoneybun> mhall119, is there anything stopping a browser from getting snapped?
<ahoneybun> can't find the xcb plugin: http://pastebin.ubuntu.com/23074103/
<ahoneybun> though it is in libqt5gui5
<sabdfl> ahoneybun, there are some test snaps of chrome and various electron bits floating around
<ahoneybun> there was an app called franz that tsimonq2 and I wanted to snap but not sure of the license
<ahoneybun> it's based on electron I think
<ahoneybun> sabdfl, there are dirs in /snap still around after 'snap remove'
<ahoneybun> I can remove the dir after taking the snap out
<ahoneybun> are they meant to stay there?
<sabdfl> ahoneybun, i think the intent is we preserve some data till it is either garbage-collected or purged
<ahoneybun> sounds sane
<ahoneybun> I'm working on this https://github.com/OtterBrowser/otter-browser
<ahoneybun> it can't find the xcb pluging for some reason
<ahoneybun> trying to use filesets to tell it
<ahoneybun> but 99% sure I'm wrong on how to use that lol
<ahoneybun> yep did nothing
<ali1234> desktop/qt5 sets up xcb for you
<ahoneybun> it does not for me
<ahoneybun> I have it in after
<ahoneybun> ali1234, want to look at my yaml?
<ali1234> okay
<ahoneybun> did not want to force it on you lol
<ahoneybun> http://pastebin.ubuntu.com/23074289/
<ali1234> you specify a list of plugs
<ahoneybun> libqt5gui5 has xcb does that mean I don't need it in stage?
<ali1234> it should not matter
<ali1234> what happens if oyu run it in devmode?
<ahoneybun> I've only tried dev mode
<ahoneybun> installed it with --devmode
<ali1234> okay
<ali1234> so it isn't about plugs
<ahoneybun> http://pastebin.ubuntu.com/23074103/
<ahoneybun> that happens
<ahoneybun> should after be under stage or before?
<ahoneybun> I know snapcraft is picky about spacing
<ali1234> i put it after
<ahoneybun> after after lol
<ahoneybun> after everything then?
<ali1234> yes
<ahoneybun> going to try that out
<ali1234> oh wait
<ali1234> it's the same problem as always
<ali1234>  command: desktop-launch otter-browser
<ahoneybun> mm?
<ali1234> you have to use the wrapper script or it wont work
<ahoneybun> oh
<ahoneybun> clean to build again?
<ahoneybun> *clear
<ali1234> no, no need
<ahoneybun> well I do
<ahoneybun> I snapcraft clean everytime
<ahoneybun> holy
<ahoneybun> ali1234, it launched
<ali1234> yes :)
<ahoneybun> mm any way for youtube to work in a snap?
<ahoneybun> since something are flash still
<ahoneybun> wow Google Play Music is still on Flash...
<ahoneybun> ali1234, could I just put the flash package into stage?
<ali1234> maybe
<ali1234> try it
<ahoneybun> will do
<ahoneybun> need to add a few more stage packages anyway
<ali1234> flash is a bit funny since the package is an installer
<ahoneybun> it shows in my dash and HUD
<ahoneybun> well since we can run parts
<ahoneybun> install flash then build the browser
<ahoneybun> mm "unity-gtk-module "?
<ahoneybun> nice to have a working snap though
<ahoneybun> thanks a ton ali1234
<ali1234> i think unity-gtk-module goes in because of Qt using the Gtk theme
<ali1234> (on Gtk desktops)
<ahoneybun> it still launches
<ahoneybun> just shots those errors
<ahoneybun> but still works
<ahoneybun> if I get a loss space error when in strict mode what does that mean?
#snappy 2016-08-21
<ahoneybun> mm hitting this: http://pastebin.ubuntu.com/23074440/
<ahoneybun> I added the home plug and still there
<ahoneybun> tsimonq2, otter-browser works
<mup> PR snapd#1712 closed: asserts/sysdb: embed the new format official root/trusted assertions <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1712>
<mup> PR snapd#1715 opened: asserts,overlord/devicestate: simplify private key/key pairs APIs, they just key ids <Created by pedronis> <https://github.com/snapcore/snapd/pull/1715>
<mup> PR snapd#1716 opened: tests. this seems to improve the situation regarding flaky stopping of fakestore <Created by pedronis> <https://github.com/snapcore/snapd/pull/1716>
<Birchy> is there any way to detect what interfaces my application uses? I'm having problems with confinement
<ogra> Birchy, snap interfaces should list all connected plugs and interfaces
<ogra> beyond that, you can look for DENIED messages in syslog
<ogra> if you suspect your app tries to use something that isnt connected
<Birchy> thank you, that's quite helpful, I didn't know syslog logged that
<mup> PR snapd#1716 closed: tests: this seems to improve the situation regarding flaky stopping of fakestore <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1716>
<ali1234> how exactly does the stage packages stuff work?
<Birchy> I've found something odd about SDL2 in Snappy, it fails with "Bad system call" because it tries to create a Unix socket but fails
<Birchy> Is this expected?
<Birchy> I had to add the permissions for network and network-bind for it to launch successfully
#snappy 2017-08-14
<mwhudson> series_16 = lp.snappy_serieses.getByName(name='16')
<mwhudson> series_16.preferred_distro_series is now None
<mwhudson> what changed there?
<mwhudson> i guess i should forum this, noone is going to be listening now :)
 * davidcalle back from hol, morning all o/
<Saviq> davidcalle: elo, should've disabled your IRC bouncer for when you were not around ;)
<davidcalle> Saviq: hehe :)
<Saviq> davidcalle: when you have time, please let us know if you need anything more from us on https://github.com/canonical-websites/developer.ubuntu.com/pull/305
<davidcalle> Saviq: I'm going to do a round of testing on this before merging, but hopefully today
<mwhudson> zyga-suse: o/
<mwhudson> zyga-suse: did you see https://forum.snapcraft.io/t/updating-snapd-in-debian/1645
<zyga-suse> hey hey
<zyga-suse> no, just waking up and checking things
<zyga-suse> agreed on all the exclusions
<zyga-suse> looking at pastebin
<zyga-suse> replied
<mwhudson> thanks
 * zyga-suse just edited the list to remove the obvious paste mistakes
<mwhudson> i think the fedora packaging ships some of those files in the snap-confine package, unless i'm missing something
<zyga-suse> that's legacy
<zyga-suse> they should be merged into one package
<mwhudson> zyga-suse: are we reasonably sure 2.27 fixes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872071 ?
<mwhudson> zyga-suse: that's the 'hang on configuring core snap' thing
<zyga-ubuntu> mwhudson: no, it doesn not
<mwhudson> zyga-suse: boo
<zyga-ubuntu> mwhudson: we have not identified the reason yet, I believe
<zyga-ubuntu> but chose not to block on it because it is an existing bug, not a regression
<mwhudson> zyga-suse: it looked like mvo had a favoured theory, did that not turn out to be it?
<zyga-ubuntu> mwhudson: not sure I know the theory
<mwhudson> zyga-suse: https://forum.snapcraft.io/t/debian-core-configure-hang-on-first-snap-install/1586/6?u=mwhudson
<zyga-ubuntu> mwhudson: i think he posted about it
<zyga-ubuntu> ah
 * zyga-ubuntu reads
<mwhudson> i guess i can add that to the changelog after i actually test the debs :)
<zyga-ubuntu> ah
<zyga-ubuntu> I hope it is asimple as that
<mwhudson> oh haha this debian vm called 'debian-stretch-amd64' is actually sid
<zyga-ubuntu> yes
<zyga-ubuntu> the qemu one is realyl stretch
<mwhudson> that saves a step
<zyga-ubuntu> the linode one is sid
<mwhudson> zyga-suse: no this is a local one
<zyga-ubuntu> ah, I see :)
<mwhudson> zyga-suse: i need to test https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851473 again too
<zyga-ubuntu> I think it will still be the same
<zyga-ubuntu> I don't think we took any action on it
<mwhudson> probably
<mwhudson> well it does this with 2.26.14 from the core snap:
<mwhudson> debian@debian:~$ hello.universe
<mwhudson> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
<zyga-ubuntu> that's a new bug, where snapd sees unpatched apparmor and choses not to enable the apparmor backend
<zyga-ubuntu> and thus snap-confine does not get its own profile
<zyga-ubuntu> but then snap-confine sees the kernel has apparmor enabled
<zyga-ubuntu> and it is setuid root
<zyga-ubuntu> but the profile is nowhere to be found, so it bails out
<zyga-ubuntu> US seems to be a troubled land recently :/
<mwhudson> zyga-suse: the hang on configure does indeed seem to be fixed \o/
<mwhudson> root@debian:~# hello.universe
<mwhudson> /usr/lib/snapd/snap-confine: error while loading shared libraries: libcap.so.2: cannot open shared object file: No such file or directory
<mwhudson> wtf!!
<zyga-suse> that is great news!!
<zyga-suse> the libcap one is interesting
<zyga-suse> is snap-confine linking libcap dynamically?
<mwhudson> whut
<zyga-suse> mwhudson: note that one way to test the hang reliably is to snap install hello while *not* having core
<mwhudson> oh
<mwhudson> no wait
<mwhudson> zyga-suse: http://paste.ubuntu.com/25311128/
<mwhudson> zyga-suse: could this be caused by the core that i just downloaded being older than the snapd i have installed?
<mwhudson> no
<mwhudson> open("/lib/x86_64-linux-gnu/libcap.so.2", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
<mwhudson> i guess this is apparmor being potty again
<mwhudson> yea
<mwhudson> Aug 14 20:56:57 debian kernel: [ 3608.590506] audit: type=1400 audit(1502701017.760:10): apparmor="DENIED" operation="open" profile="/usr/lib/snapd/snap-confine" name="/lib/x86_64-linux-gnu/libcap.so.2.25" pid=2365 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<mwhudson> lets turn apparmor off for now...
<zyga-suse> mwhudson: ah, I think this *is* apparmor
<zyga-suse> but wait, didn't you say you disabled apparmor?
<zyga-suse> ah, no you enabled it sorry
 * zyga-suse is really sleepy still
<zyga-suse> so, with older core you will not re-exec
<mwhudson> i've disabled it *now* and it works
<zyga-suse> and you will use snap-confine from debian
<zyga-suse> and you may see profile incompatibility
<mwhudson> ah yeah, i think i knew that once
<zyga-suse> since snap-confine profile is written for more recent apparmor behavior
<mwhudson> zyga-suse: any ideas for things i should test on this vm?
<zyga-suse> mwhudson: did you try the "I have no core and I snap install hello" use-case?
<mwhudson> zyga-suse: yes
<mwhudson> that was the first thing i tried :)
<zyga-suse> hmm, not sure then, just a random collection of snaps perhaps: ... one sec
<zyga-suse> https://github.com/snapcore/snapd/pull/3692
<mwhudson> zyga-suse: is there some easy way to run this on the vm?
<zyga-suse> not sure, I think if you can just hand install the top three it would be a good test
<mwhudson> heh heh good to see my only important snap on there :)
<zyga-ubuntu> which one is that?
<zyga-ubuntu> :)
<zyga-ubuntu> mvo: welcome back
<mvo> hey zyga-ubuntu
 * zyga-ubuntu needs 2nd coffee
<zyga-ubuntu> head.ache()
<mvo> zyga-ubuntu: I get a cup of tea now too - I looked briefly at backporting asic control to 2.27.1 but there are quite a few changes to common interfaces that would also need backporting, it seemed overly broad for the scope of a .1
<zyga-ubuntu> mvo: if you want I can make a simpler backport, with a custom interface type
<mvo> zyga-ubuntu: lets
<mvo> zyga-ubuntu: sorry, let see if we need a .2 and only do it if we do
<zyga-ubuntu> mvo: ok, when will we know?
<mwhudson> zyga-suse: go
<mvo> zyga-ubuntu: hopefully soon, I will ask cachio to do the 2.27.1 validation today
<zyga-ubuntu> ok
<zyga-ubuntu> I'll do some more reviews for garry and work on 2.27.1 packaging
<mvo> +1
<mwhudson> heh i appear to have rocketchat installed on debian sid
<zyga-ubuntu> the funny thing is it would also install on debian *stable*
<zyga-ubuntu> hmm, mup is not reporting PRs
<ikey> ok so github is seriously tripping right now
<ogra> oh, while you mention github ...
<ikey> zyga-ubuntu, https://ibin.co/3Wq1GWrSnkGi.png
<zyga-suse> hey
<zyga-suse> hmmm
<zyga-suse> I merged master into your branch
<zyga-suse> that should fix the fedora failures
<ikey> yeah but look where you pushed
<ikey> that shouldnt be possible
<ikey> thats the forked repo
<zyga-suse> yes
<zyga-suse> it is, that's a github feature
<ikey> then github is on crack
<ikey> because repo permissions
<ikey> lol
<zyga-suse> I pushed that *into* your branch because when there's an active PR contributors can do that
<zyga-suse> it's an opt-out feature for about 3 months
 * ikey calls crack
<zyga-suse> it does makes sense :)
<ikey> meth then
<ikey> :p
<zyga-suse> it's weird but when you think about it
<zyga-suse> people close the PR and reopen with more things
<zyga-suse> but that's just a time waste
<ikey> rebase/force push
<zyga-suse> why?
<ikey> i mean in response to "people close the PR"
<zyga-suse> ah
<mup> PR snapd#3724 opened: wrappers: symlink completion snippets when symlinking binaries <Created by chipaca> <https://github.com/snapcore/snapd/pull/3724>
<zyga-suse> no, I mean people close the PR because they cannot push to it
<ikey> oh others
<zyga-suse> contributor comes along and makes a PR but then looses interest
<ikey> ah
<zyga-suse> maintainers are willing to fix so they close and reopen with their fixes
<zyga-suse> this just cuts one step
<zyga-suse> not saying that it happens all the time
<zyga-suse> but even inside the core team we do that all the time
<zyga-suse> esp timezones
<zyga-suse> it helps
<zyga-suse> btw, I'm curious -- what was that UI that showed me doing this?
<zyga-suse> is that something I can use?
<mup> PR snapd#3702 closed: interfaces: add missing test for camera interface <Created by adglkh> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3702>
<ikey> zyga-suse, that was just on my github front page
<zyga-suse> aha
<zyga-suse> interesting theme :)
 * mwhudson uploads snapd_2.27.1-1_source.changes
<ikey> https://ibin.co/3Wq3LA9vK99y.png
<zyga-ubuntu> ikey: nice, is that a custom theme applied somehow or something I can toggle just on github?
<ikey> i use userstyles extension in chrome
<zyga-ubuntu> ah, right
<ikey> or stylish
<ikey> or h/e you call it .. lol
<ikey> "GitHub Dark"
<ikey> wth gdk-pixbuf
<ikey> what kind of a mad man statically links libtiff
 * zyga-suse ventures into /usr/lib/rpm 
<ikey> i feel i should say "It's dangerous to go alone!" and offer you a sword.
<zyga-ubuntu> I think I'm already out, I was looking at how /usr/lib64/go vs /usr/lib/go can be abstracted
<ikey> ah
<pedronis> mvo: hi,  snapd#3710 is the thing that needs a review for 2.28 btw
<mup> PR snapd#3710: many: allow and support serials signed by the 'generic' authority instead of the brand <Created by pedronis> <https://github.com/snapcore/snapd/pull/3710>
<mvo> pedronis: thanks, I have a look
<Chipaca> zyga-ubuntu: any luck with a branch to disable sync in tests?
<zyga-ubuntu> Chipaca: nope, I left it on a hanger last week
<zyga-ubuntu> Chipaca: let me refresh it
<Chipaca> zyga-ubuntu: no worries, just curious
<Chipaca> huh, the autopkgtests run without a core snap
<ogra> jospoortvliet, hey ho ... why does this section if the nextcloud install doc tell you to install debs alongside the snap ? https://docs.nextcloud.com/server/12/admin_manual/installation/source_installation.html#example-installation-on-ubuntu-16-04-lts-server
<jospoortvliet> ogra: it is meant to be a choice
<jospoortvliet> either install the snap
<jospoortvliet> or go the 2nd way: install things manually
<jospoortvliet> it isn't very clear
<jospoortvliet> not at all :D
<ogra> yeah :)
<jospoortvliet> ogra: I would suggest to have a header "option 1" and "option 2"
<jospoortvliet> if you want, you can propose the change: https://github.com/nextcloud/documentation/blob/master/admin_manual/installation/source_installation.rst
<jospoortvliet> edit the source of the documentation there
<ogra> jospoortvliet, FYI  https://lists.ubuntu.com/archives/ubuntu-users/2017-August/291222.html
<jospoortvliet> ogra: if you happen to be on that list, replying to explain the problem would be welcome, I'm not a member...
<jospoortvliet> and mention me ( @jospoortvliet ) if you make a pr for the documentation. Just use the web UI of github... or let me know if you can't figure out how to, I'd be happy to help!
 * zyga-suse focuses on suse package again
<jospoortvliet> +1 for that zyga-suse - I have moved to using the tarball but as openSUSE user I'd consider moving back to packages. Though then I can't help test RC's etc so easily. choices, choices... ;-)
<zyga-suse> hmm?
<zyga-suse> I mean suse package of snapd
<jospoortvliet> aaah zyga-suse that is also cool :D
<jospoortvliet> zyga-suse: esp on small devices that you don't want to maintain I think the snap is super useful
<jospoortvliet> so +1 on that, too :D
<ogra> jospoortvliet, https://github.com/nextcloud/documentation/pull/554
<mup> PR nextcloud/documentation#554: make clearer that it is either snap or deb in the example <Created by ogra1> <https://github.com/nextcloud/documentation/pull/554>
 * zyga-suse ponders 
<zyga-suse> https://paste.gnome.org/pasc7ndpu
 * zyga-ubuntu -> lunch
<ogra> zyga-ubuntu, thanks for merging the spi stuff in the pi3 gadget (i thought you said you wanted manual tests in your last comment on the PR, this is why i had not merged it yet)
<zyga-ubuntu> it looked ok
<ogra> yeah, and it goes to edge first anyway :)
<Chipaca> ok, time for me to take a break (run + lunch + etc
<Chipaca> )
 * zyga-ubuntu resumes hacking
<zyga-ubuntu> can someone please do a 2nd review for 3714
<mup> PR snapd#3705 closed: interfaces: convert lxd_support to common iface <Created by adglkh> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3705>
<ikey> i updated my PR to remove the mkversion changes
<ikey> (and rebased it on master to drop the 30 odd pull requests on top of it :P)
<zyga-ubuntu> ikey: ok,
<ikey> it seemed to be the main sticking point of the PR
<ikey> and it means changing all of 2 lines in my package.yml
<ikey> so its a silly thing to keep around
<ikey> actually no it just means adding one line, easier again
<zyga-ubuntu> Thank you!
<zyga-ubuntu> I asked jdstrand to review that PR
<ikey> s'all good dude
<ikey> i like streamlined :p
<pedronis> ikey: notice that we tend to frown upon rebases once a PRÂ has got comments
<pedronis> at least that's what IÂ always heard from niemeyer
 * ikey blinks
<ikey> i didnt exactly have a choice :p
<ikey> zyga-ubuntu pushed a merged master on top of it, and the only way to edit my own patch was to rebase it back on top of master
<zyga-ubuntu> that's fine
<ikey> i wasn't going to dig through 30 merged PRs for my patch and then reapply them lol
<niemeyer> ikey: You can just merge master in those cases, I believe
<ikey> it was already merged
<ikey> thats the problem
<ikey> i couldnt amend my commit
<niemeyer> ikey: You can just continue changing the content of the PR further.. no need to amend
<niemeyer> This way reviews continue to make sense on the timeline
<ikey> which means you would need to cherry-pick my commits and would lose my gpg signature
<niemeyer> Otherwise all previous references to commits are lost
<ikey> idk maybe we just git differently
<ikey> github shows when a comment is for an outdated diff
<pedronis> we have a slightly messy mainline
<pedronis> but we don't care it seems, so yes we make different git choices I think
<ikey> well, i know for future
<niemeyer> The mainline is pretty clean, mainly because we squash merges
<ikey> which then loses gpg signatures, etc
<pedronis> often but not always
<niemeyer> It does, yes
<ikey> debian has been pushing for signed commits for some time
<ikey> as well as signed tags
<niemeyer> Thanks for the changes, and good morning btw :)
<ikey> morning!
<ikey> at times github is enough to make me miss gerrit
<ikey> which is an awful thing to say
<niemeyer> GitHub is pretty reasonable these days in terms of code reviews.. it used to be unacceptable for anything non trivial
<ikey> yeah
<ikey> at least its no longer trying to hide all the things
<Son_Goku> beh
<Son_Goku> signed commits and tags cause issues
<ikey> update your git client?
<ikey> dont use gitkraken?
<ikey> etc. :p
<Son_Goku> if GitHub throws 500 errors, there's not a lot I can do
<ikey> github makes no attempt to verify signatures
<Son_Goku> it's a known issue with how GitHub's gpgverify works
<Son_Goku> yes it does
<ikey> only that the issue belongs to an account
<Son_Goku> it actually *does* attempt to verify them
<ikey> because you have to upload your gpg key to github for it to do so
<ikey> not to a keyserver
<Son_Goku> well, yeah, not to hkp
<Son_Goku> but it does actually attempt to verify them
<ikey> right so its not doing **normal** verification is what im saying :p
<Son_Goku> mvo, have you attempted to get this fixed yet? https://github.com/golang/go/issues/20556
<Son_Goku> woo, someone fixed mongodb ftbfs on s390x :D
<Son_Goku> that means I can finally build snapd on rawhide
<zyga-suse> someone *cares* :D
<zyga-suse> how is that related?
<Son_Goku> snapd -> go mongodb driver -> mongodb-libs -> mongodb
<Son_Goku> zyga-suse: it's really silly that snapd depends on mongodb transitively, but whatever
<Son_Goku> god, I hate arm: https://koji.fedoraproject.org/koji/taskinfo?taskID=21222949
<Son_Goku> it takes FOREVER...
<ikey> "god, I hate arm" - which one? :trollface:
 * ikey legs it
<zyga-suse> Son_Goku: how is that possible?
<zyga-suse> ah
<zyga-suse> Son_Goku: mongodb driver is a part of golang?
<Son_Goku> no, it's the mgo driver the niemeyer wrote
<ogra> "the niemeyer" ... <highlander voice> there can be only one, my friend </highlander voice>
<ogra> :)
<niemeyer> How would snapd depend on it transitively? It definitely doesn't in general
<Son_Goku> https://koji.fedoraproject.org/koji/rpminfo?rpmID=10629107
<Son_Goku> if this is an error, then tell me, so I can poke someone to fix it
<mvo> Son_Goku: thanks for the reminder, mwhudson offered to help me with pushing the patch from https://github.com/golang/go/issues/20556 to upstream, I had some problems with the account creation
<Chipaca> niemeyer: o/
<pedronis> niemeyer: we are using mgo.v2/bson  seems to bring in stuff on distros
<Son_Goku> mvo, well, I noticed it when I audited the source tree to update dependencies
<Son_Goku> when I see weird forks and stuff like that, I want to be sure I can avoid them :)
<Chipaca> Son_Goku: that's because you hate freedom
<Chipaca> oh wait no that was us
<Son_Goku> :)
<Chipaca> is spread on linode having a bad day?
<niemeyer> pedronis: I see.. that doesn't make a lot of sense, in quite a few ways
<niemeyer> First, it's a build dependency..
<niemeyer> Then, it's a driver.. building something with a driver shouldn't bring in a database
<Son_Goku> yeah, as a result, I can't build snapd
<niemeyer> Son_Goku: How come?
<Son_Goku> pulling that godep causes it to try to install mongo, and mongo wasn't rebuilt for new boost successfully because borkiness in test suite on s390x
<pedronis> niemeyer: yea, but it's a problem in the mgo packages , not in snapd afaiu
<Chipaca> I interrupt this fascinating documentary about how all packaging is broken all the time to bring you this bit of news: it's standup o'clock
<pedronis> Chipaca: :)
<Son_Goku> pedronis: yep
<niemeyer> Son_Goku: That makes no sense on itself, even despite anything else, right?
<Son_Goku> unless you expect to run the mgo unit tests in your build, I think it doesn't make sense to be a hard dep
<Son_Goku> after all, the server could exist somewhere else, in theory
<Son_Goku> unless the driver requires the mongodb C libs to build correctly
<ogra> mvo, did you see the discussion on https://forum.snapcraft.io/t/in-progress-snapd-2-27-1/572 ?
<ogra> (i guess we should pull the xdg fix into 2.27.1)
<zyga-ubuntu> morphis: hey
<zyga-ubuntu> morphis: around?
<morphis> zyga-ubuntu: hey!
<morphis> zyga-ubuntu: what's up?
<zyga-ubuntu> morphis: would you have a moment for a opensuse package review?
<morphis> sure
<zyga-suse> excellent, I'll put the sync request up soon
<zyga-suse> Chipaca: that's for you: https://github.com/snapcore/snapd/pull/3725
<mup> PR snapd#3725: osutil: honor SNAPD_UNSAFE_IO for testing <Created by zyga> <https://github.com/snapcore/snapd/pull/3725>
<mup> PR snapd#3725 opened: osutil: honor SNAPD_UNSAFE_IO for testing <Created by zyga> <https://github.com/snapcore/snapd/pull/3725>
<Chipaca> zyga-suse: https://people.canonical.com/~john/howmanyvmsdoesittake
<zyga-suse> hehe
<Chipaca> zyga-suse: (also it's curl-able)
<zyga-suse> Chipaca: oh, lovely, how did you do that?
<Chipaca> zyga-suse: apache is magic
<zyga-suse> ah, via apache
<Chipaca> :-)
<zyga-suse> I didn't know we can do that on p.c.c
<zyga-suse> mvo: ok, I'll do your backport now
 * zyga-ubuntu actually goes to eat something
<mvo> zyga-ubuntu: \o/
<Son_Goku> damn, I really should go to work now
<zyga-suse> Son_Goku: thank you for the updates!
<Son_Goku> np
<Son_Goku> I suspect I'm going to have 2.27.2 soon, aren't I?
<zyga-suse> yed
<zyga-suse> yes*
<zyga-suse> I need to backport one thing
<zyga-suse> and we need two cherry picks from master
<zyga-suse> sorry about that :(
 * Son_Goku shrugs
<Son_Goku> I'm only really annoyed when it's really close to making it into the repository
<Son_Goku> because each update resets the counter
<zyga-suse> we feel it the same way for ubuntu and elsewhere :/
<Son_Goku> and because no one ever tests the Fedora snapd updates, it's aggravating
<zyga-suse> I will start doing that again, sorry for letting you down there :/
<Son_Goku> because I have to wait the full five days, and then it has to be reset :/
<zyga-suse> what is the average rate of tests for a package?
 * Son_Goku shrugs
<zyga-suse> in bodhi I mean
<Son_Goku> the stats are in Bodhi itself
<Son_Goku> https://bodhi.fedoraproject.org/metrics
<Son_Goku> https://bodhi.fedoraproject.org/releases/F26
<niemeyer> mvo: Do we have a topic for the known issue with snapd reverts?
<niemeyer> mvo: core revert leaving snapd unrestarted, that is
<mvo> niemeyer: not yet, let me add it
<niemeyer> mvo: Thanks!
<zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/3726
<mup> PR snapd#3726: interfaces: backport broadcom-asic-control interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3726>
<zyga-ubuntu> morphis: ^^
<mup> PR snapd#3726 opened: interfaces: backport broadcom-asic-control interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3726>
<mvo_> niemeyer: https://forum.snapcraft.io/t/snapd-not-restarting-on-revert/
<mup> PR snapd#3727 opened: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>
<zyga-ubuntu> mvo_: anything else I can help with wrt 2.27?
<mup> PR snapd#3728 opened: tests: adding more debug information for the interfaces-cups-control test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3728>
<mup> PR snapd#3728 closed: tests: adding more debug information for the interfaces-cups-control test <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3728>
 * zyga-ubuntu reboots
<mup> PR snapd#3729 opened: store: do not resume a download when we already have the whole thing  (2.27) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3729>
<ikey> i think the arch nvidia code might be broken
<ikey> https://ibin.co/3WrQ0U7eu5Ao.png
<ikey> getting the undefined symbol issues .. which i shouldnt be getting
<ikey> unless its mercilessly copying across host side GL libs regardless of whether or not its nvidia
<mvo_> zyga-suse: I think we are good otherwise
<mup> PR snapd#3730 opened: tests: adding more debug information for the interfaces-cups-control â¦ <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3730>
<mup> PR snapd#3731 opened: interfaces: allow /usr/bin/xdg-open in unity7 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3731>
<mup> PR snapd#3732 opened: interfaces: allow /usr/bin/xdg-open in unity7 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3732>
<ikey> ah
<ikey> 	if (config->on_classic_distro) {
<ikey> 		sc_mount_nvidia_driver(scratch_dir);
<ikey> 	}
<ikey> its unconditional
<ikey> reality being it should only actually mount in the presence of the nvidia driver
<ikey> that came out wrong..
<ikey> we basically need this in mount-support-nvidia.c sc_mount_nvidia_driver:
<ikey> 	if (access(SC_NVIDIA_DRIVER_VERSION_FILE, F_OK) != 0) {
<ikey> 		return;
<ikey> 	}
<mvo_> zyga-suse: all 2.27 bits are now running tests, fingers crossed, once things are green I will work on 2.27.2
<ikey> and make the define global, not limited purely to ubuntu impl
<zyga-suse> mvo_: conflict on 3732
<zyga-suse> ikey: aha, indeed - a similar check exists for the more-tested ubuntu path
<zyga-suse> ikey: thank you for finding that
<ogra> mvo_, since you didnt answer my pings, pinging again ... did you see the xdg-open discussion on the 2.27.1 thread ?
<ikey> ill stick the patch into solus and build a VM with it zyga-suse
<zyga-suse> ogra: I think he did
<ikey> if that works ill submit the PR
<ogra> (just want o make sure it doesnt get missed)
<zyga-suse> ogra: that's why we are getting 2.27.2
<ogra> awesome
<zyga-suse> ikey: sounds good
<ikey> looks like this atm https://hastebin.com/afozimumuv.swift
<ogra> zyga-suse, i didnt want to be pushy ... just didnt know if he saw it
<zyga-suse> it's all good :)
<ogra> :)
<chad_young> anyone free to help with snapcraft.yaml file issues?
<zyga-ubuntu> chad_young: hey, what is the matteR?
<chad_young> I am trying to snap mosquitto and the clients into one snap but I cant seem to put everything in it place
<chad_young> I have a file on github - its the "clean" version
<mup> PR snapd#3691 closed: tests: installing snapd for nested test suite <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3691>
<chad_young> i.e. default
<chad_young> file is here: https://github.com/chadyoungdell/Ubuntu-Core/blob/master/IOT_Apps/Mosquitto/snapcraft.yaml
<chad_young> when I snap the "mosquitto" service does start but after I try adding the client file the snap complete
<tpatel> can I update my snap from my own snap, rather than waiting on auto refresh?
<niemeyer> "We went looking everywhere, but couldnât find those commits.
<niemeyer> Sometimes commits can disappear after a force-push. Head back to the latest changes here."
<niemeyer> That's why we don't force-push after reviews are up.. :/
<niemeyer> (aka "rebase")
<ogra> chad_young, why cant you use the existing snap package of mosquitto ?
<ogra> is that missing anything ?
<ogra> oh, sorry
<ogra> missed that you want to bundle clients
<chad_young> np :)
<niemeyer> Irony: I went to add 10 more machines to our Linode pool, and found all 70 machines down right now.
<niemeyer> As in, powered off..
<Son_Goku> :D
<niemeyer> I don't recall ever having seen all of them powered down at once :)
<zyga-ubuntu> niemeyer: maybe we should have a dynamic scaling thing
<zyga-ubuntu> niemeyer: at least 10, at most 150
<zyga-ubuntu> not sure what the pricing model is
<niemeyer> zyga-ubuntu: Right, that's the tricky bit
<zyga-ubuntu> if that is competetive maybe linode should just make that easy
<zyga-ubuntu> (it must be saving real stuff for them)
<zyga-ubuntu> I wish they had as "dormant" pricing for powered off machines
<niemeyer> zyga-ubuntu: They do make it easy, and they are also smart about it
<niemeyer> zyga-ubuntu: The cost of holding one of those machines for a month is $10, but the price per hour is .015.. do the math
<ogra> tpatel, yes you can by using a local snap file and the --dangerous flag for "snap install" but it wont auto-update anymore then
<zyga-ubuntu> aww :D
<zyga-ubuntu> niemeyer: that's both good and not good, I wish there was at least, say, 30% delta
<zyga-ubuntu> worth the money to make our side smarter
<niemeyer> zyga-ubuntu: In practice, it's cheap.. that level of machine is much more expensive on other providers
<zyga-ubuntu> niemeyer: 30% of 100 is still 30 :D but I see the point
<zyga-ubuntu> I wonder if we could marry spread and juju to be cross-cloud one day
<tpatel> orga: can I issue 'snap refresh' which should pull it from store and update it?
<niemeyer> zyga-ubuntu: spread is cross-cloud
<ogra> not sure about that ... but i dont think so
<niemeyer> zyga-ubuntu: and cross-your-disk too:)
<zyga-ubuntu> niemeyer: well, arguably the disk image is something that is tricky but this feels like a problem somehow must have solved
<niemeyer> zyga-ubuntu: But part of the point is having something that tends to work without us having to spend a lot of time on this
<ogra> (note that --dangerous is rather for developers when testing locally built snaps before uploading to the store)
<niemeyer> zyga-ubuntu: Your time has a cost, you know :)
<mvo_> ogra: sorry, must have missed the earlier ping. I noticed the issue with xdg-open, I pushed a PR that shouÃ¶d fix it
<ikey> yeah my gl patch works
<ogra> mvo_, yeah, i saw that now ... sorry for the noise (though there is a conflict)
<zyga-ubuntu> niemeyer: I know, hence me saying "worth the money to make our side smarter"
<mvo_> ogra: thanks, looking into this one now
<ikey> zyga-suse, should i add the new patch to my existing PR?
<mup> PR snapd#3732 closed: interfaces: allow /usr/bin/xdg-open in unity7 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3732>
<niemeyer> zyga-ubuntu: We now have 70 machines running (!).. how much would AWS charge for 70 machines running for 1h?  More than $3, and that's assuming no network, no local SSD, etc...
<zyga-suse> Chipaca: FYI, I applied the unsafe-io patch for tests to opensuse and it's a fantastic improvement
<mvo_> jdstrand: if you could do a quick sanity check of PR 3726, that would be great
<pstolowski> niemeyer, should the 'upcoming' stories that already landed be tagged with 'done' now? (sorry, I missed the conclusion about the tag)
<zyga-ubuntu> pstolowski: no, we should just drop the name and upcoming from the tags
<pstolowski> zyga-ubuntu, ok, thx
<mvo_> ogra: re pings> I had some network hickups today, my dsl provider seems to be unhappy, this is probably why I missed the pings
<ogra> ah, k
<niemeyer> 10 VMs added, please retry / let me know of issues
<niemeyer> Note that some tests running moments ago may have failed
 * niemeyer => lunch
<ikey> anyone? re: pushing patch to existing PR..
<jdstrand> mvo_: ok
<mvo_> jdstrand: thanks! should be super trivial I hope, straight backport from master just the old layout instead of the new commonInterfaces code
<mup> PR snapd#3729 closed: store: do not resume a download when we already have the whole thing  (2.27) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3729>
<ahasenack> hi guys, I'm having a problem installing a snap: http://pastebin.ubuntu.com/25312811/
<ahasenack> getting a 404
<ahasenack> was getting the same 404 a few moments ago for an older revision, 117
<ogra> ahasenack, https://forum.snapcraft.io/t/snap-install-refresh-fails-with-404/1676
<ogra> ??
<ahasenack> let me try re-login
<ahasenack> ogra: logout/login fixed it for me
<ogra> yeah, thought so
<mvo_> pedronis: thanks a lot for your feedback on the ensureCore PR!
<jdstrand> mvo_: done
 * mvo_ hugs jdstrand
 * jdstrand hugs mvo_ back :)
 * mvo_ hugs zyga-ubuntu for making the PR in the first place
 * zyga-ubuntu blushes :)
<mvo_> just one more to go for 2.27.2 :)
<pedronis> mvo_: np, I fear the move is a bit more complicated than we thought, also the code we had in api is okish for classic, but if we need to support based etc we will need to be more careful about failure modes
<pedronis> s/based/bases/
<zyga-suse> morphis: https://build.opensuse.org/request/show/516894
<mvo_> pedronis: indeed, I ponder some more how to make it more robust in the morning, its good feedback :)
<pedronis> niemeyer: we never tried but IÂ suppose we do support waiting for tasks across changes? at least we they are different lanes?
<pedronis> s/we they/if they/
<zyga-ubuntu> mvo_: hmm
<zyga-ubuntu> mvo_: the upgrade/basic test failed with "no registered handlers for hook "install"
<zyga-ubuntu> mvo_: what was the resolution for that?
<zyga-ubuntu> mvo_: was it just a silly test or do we need action?
<mvo_> zyga-ubuntu: iirc this has only happend when we went "upgraded" from master to 2.27, i.e. when the versions are out of sync, iirc I did a PR for the 2.27.1 changelog?
 * mvo_ looks
<mvo_> zyga-ubuntu: hm, edge should be ok, i.e. master - where do you see this error?
<mvo_> zyga-ubuntu: when pstolowski and I last looked at it we had this version issue but if you see it on a current branch then it might be something deeper
<zyga-ubuntu> mvo_: here, on ppc https://github.com/snapcore/snapd/pull/3726
<mup> PR snapd#3726: interfaces: backport broadcom-asic-control interface (2.27) <Created by zyga> <https://github.com/snapcore/snapd/pull/3726>
<zyga-ubuntu> mvo_: on the backport branch
<mvo_> zyga-ubuntu: aha, in autopkgtest
<mvo_> zyga-ubuntu: I need to look but the version in the log look a bit bogus
<mvo_> pedronis: InstallMany is a real problem, you are right
<Chipaca> hmm... the work i'm doing for package names / cnf could just as well apply to sections
<Chipaca> ogra: is /var/cache writable on core? (do you know without checking?)
<Chipaca> otherwise i can check myself :-D
<ogra> ogra@nanopi:~$ touch /var/cache/foo
<ogra> touch: cannot touch '/var/cache/foo': Read-only file system
<ogra> :P
<ogra> i can check faster :P
<ogra> Chipaca, /var/cache/apparmor is writable
<Chipaca> /var/lib/snapd/cache it is then :-D
<ogra> but nothing on the higher level
<ogra> well, you could have /var/cache/snapd
<ogra> if that feels cleaner
<ogra> it is trivial to add
<Chipaca> I'm not convinced it is better, but good to know -- i'll mention it in the PR
<chad_young> looking for help on the mosquitto snap (all inclusive- broker and pub/sub)
<chad_young> I have both parts working - just cant get the combined to work
<chad_young> that is broker in one snap and pub/sub in another
<Chipaca> chad_young: how is it not working? that is, what errors do you see?
<ogra> whats the exact issue ?
<ogra> the snapcraft.yaml you linked above looks okayish
<chad_young> usually when I add the client portion the snap create fails as it cant find a "config.mk" - which is there in the folder
<chad_young> there are two make files - one for the broker and one for the client - each using the same config.mk file
<ogra> just add another part ?
<chad_young> I did that but it still failed - I will update the yaml file on the github and comeback when its ready
<ogra> well, show us code and errors ... :)
<ogra> like Chipaca said
<chad_young> will do
<zyga-ubuntu> Chipaca: hey
<zyga-ubuntu> Chipaca: can you hand-hold me with tab completion issues again please
<zyga-ubuntu> Chipaca: on opensuse now, I'm shipping the various files
<zyga-ubuntu> Chipaca: (better yet, write a forum post)
<zyga-ubuntu> Chipaca: enough for "tab completion doesn't work, here's some debug data for you to understand"
<chad_young> ok @orga and Chipaca - here is the update
<chad_young> https://github.com/chadyoungdell/Ubuntu-Core/tree/master/IOT_Apps/mosquitto.snap/snap
<Chipaca> zyga-ubuntu: i'll hand-hold you, and if a pattern emerges, forum post
<zyga-ubuntu> Chipaca: probably packaged something incorrectly
<Chipaca> zyga-ubuntu: but â¦ what issues are you seeing
<chad_young> will post error in a sec
<zyga-ubuntu> Chipaca: http in beta, http -<tab> does nothing
<Chipaca> zyga-ubuntu: ok, so first of all, start a new terminal and tell me what you see for "complete -p -D"
<chad_young> here is the error https://pastebin.com/BjM6KHU7
<zyga-suse> zyga@faroe:~> complete -p -D
<zyga-suse> complete -F _completion_loader -D
<Chipaca> zyga-suse: ok, so you aren't sourcing complete.sh
<zyga-suse> Chipaca: what should be doing that?
<Chipaca> zyga-suse: you :-)
<zyga-suse> as in, my profile?
<Chipaca> zyga-suse: the need to add that to your .bashrc is addressed by snapd#3724
<mup> PR snapd#3724: wrappers: symlink completion snippets when symlinking binaries <Created by chipaca> <https://github.com/snapcore/snapd/pull/3724>
<Chipaca> zyga-suse: well, we tried to make it automagic but hit a wall
<Chipaca> so, in the snapd you have, you need to do this
<zyga-ubuntu> ...
 * zyga-ubuntu waits for what "this" is
<Chipaca> zyga-ubuntu: this == "source complete.sh"
<zyga-suse> aha
<zyga-suse> as in
<zyga-suse> zyga@faroe:~> . /usr/lib/snapd/complete.sh
<zyga-suse> did that
<Chipaca> zyga-suse: or . /snap/core/current/usr/lib/snapd/complete.sh
<zyga-suse> no effect
<zyga-suse> zyga@faroe:~> complete -p -D
<zyga-suse> complete -F _complete_from_snap_maybe -D
<Chipaca> ok, good
<Chipaca> now
<Chipaca> complete -p http
<zyga-suse> zyga@faroe:~> complete -p http
<zyga-suse> complete -F _minimal http
<Chipaca> right, so you did http -<tab> _before_ sourcing complete.sh
<Chipaca> so that loaded a completer for http
<Chipaca> you need to remove it: complete -r http
<Chipaca> and try again
<zyga-suse> zyga@faroe:~> complete -r http
<zyga-suse> zyga@faroe:~> complete -p http
<zyga-suse> bash: complete: http: brak definicji dla uzupeÅnienia
<Chipaca> zyga-suse: ok, http -<tab>?
<zyga-suse> yep
<zyga-suse> that worked!
<zyga-suse> ok
<Chipaca> ok
<zyga-suse> so what should I do in general
<zyga-suse> is it a default in opensuse
<zyga-suse> is it something I can tweak in packaging?
<Chipaca> zyga-suse: it depends on whether suse's shells always source /etc/profile or if it's only for login shells
<Chipaca> zyga-suse: on debian it's only login shells
<Chipaca> zyga-suse: on fedora it's all of 'em
<Chipaca> afaik
<zyga-suse> https://paste.gnome.org/pxh1jvxfw
<zyga-suse> this is /etc/profile
<Chipaca> zyga-suse: which is why in debian there's bash completion loaded twice, once in /etc/profile.d, once in .bashrc
<Chipaca> zyga-suse: what's in /etc/skel/.bashrc
<Chipaca> zyga-suse: bah
<Chipaca> zyga-suse: easy way of answering what's going on is to try it and see :-)
<zyga-suse> note, this is tumbleweed
<zyga-suse> as in "sid"
<Chipaca> zyga-suse: _but_, snapd#3724 would fix this
<mup> PR snapd#3724: wrappers: symlink completion snippets when symlinking binaries <Created by chipaca> <https://github.com/snapcore/snapd/pull/3724>
<zyga-suse> https://paste.gnome.org/phffmxefk
<zyga-suse> Chipaca: aha, I may just review it then :D
<Chipaca> zyga-suse: basically, in a default user on suse, in a default gnome terminal tab (say), is bash tab completion enabled? and if it is, is it via /etc/profile.d, and if it is, can we drop /etc/profile.d/zzz-sneaky-snapd-completion in there that overrides the default completer
<Chipaca> and then if a user has modified stuff it'll still break
<Chipaca> so that PR is really the best approach
<Chipaca> even though it'll require packaging tweaks (to remove snap completion snippets on purge)
<zyga-suse> mmm, no idea
<zyga-suse> note
<zyga-suse> we have a file in /etc/profile.d
<zyga-suse> snapd.sh is there
<zyga-suse> as is snapd-xdg.sh
<zyga-suse> (I will merge them actually)
<mup> PR snapd#3718 closed: tests: enable regression and completion suites for opensuse <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3718>
<cachio> mvo_, do you know who should I contact to get a connection to the machines where the autopkgtest for each build on travis?
<chad_young> @orga have you had a chance to look at my update
<nothal_> chad_young: No such command!
<cachio> mvo_, I need that to see why the refresh-all* tests are failing
<chad_young> orga: have you had a chance to look at my update
<chad_young> Chipaca: same Q to you
<Chipaca> chad_young: I'm afraid if it's a snapcraft problem I'm not the right person to help you
<Chipaca> chad_young: it looks like you're missing a configure step
<Chipaca> chad_young: if you run a "make" in the checkout of that git repository, does it work?
<chad_young> yes, if I run make/make install in each folder seperately they both build
<Chipaca> chad_young: what's 'each folder'?
<Chipaca> chad_young: i guess your problem is the last bit, the 'client' part, where you tell it to make using a source of ../client
<chad_young> looking at the github there is a make file in "src" folder for the broker and another make file in the "client" folder that makes the pub/sub client
<Chipaca> chad_young: that would pull just the client directory somewhere, and config.mk is in the parent directory which would not be where the make expects it?
<Chipaca> pure speculation on my part
<Chipaca> note what it's not finding is ../config.mk
<Chipaca> which is in the repository root
<chad_young> if I look at the github I see config.mk in the root folder
<Chipaca> yes
<Chipaca> but you're trying to build the client with just the "client" subdirectory, without the config.mk from the root folder
<chad_young> I am ?
<Chipaca> that's what "source: ../client" means, isn't it?
<chad_young> I thought that putting in "../client" was just telling make where the Makefile was
<chad_young> since I am starting the snapcraft from the folder "snap" I thought I would have to specify that the new make file (for the clients) is in the "../client" folder
<zyga-suse> Chipaca: re, sorry
<zyga-suse> Chipaca: I'm EOD, let's catch up tomorrow
<Chipaca> zyga-suse: k
<Chipaca> chad_young: you're going to have to find somebody who knows more snapcraft than myself, I'm afraid
<chad_young> Ok, Thank you
<Chipaca> ok, this works. tests are a thing for tomorrow.
 * Chipaca EODs
<niemeyer> ikey: Not sure if someone responded to you yet, but we try to split up patches as much as we can
<niemeyer> ikey: Within reason, of course.. but different ideas generally belong on different patches
<ikey> niemeyer, its still the same idea
<ikey> "Initial Solus support"
<ikey> but I had a feeling it *might* be one way or the other
<ikey> Which is why I asked ages ago
<niemeyer> ikey: Well, we can also say that "snapd" is an idea.. :P
<niemeyer> ikey: I really mean in terms of the logical change instead of the overall goal
<ikey> Ack
<niemeyer> ikey: Thanks for asking
<ikey> you can ignore the secondary commit and ill open a second PR for it
<ikey> likely wont be happening tonight as that came up during QA and we're prepping a solus release here
<ikey> so it was more "emergency patch"
<niemeyer> ikey: It ends up being much easier to review and consequently to get things merged
<ikey> aye
<niemeyer> ikey: otherwise a small controversy on a tiny part blocks the whole
<ikey> yeah thats why i blitzed the other yokey
<ikey> the mkversion thingy
 * ikey can't word
<tpatel> can i check within my snap if the interface is connected?
<tpatel> can i check within my snap if the interface is connected?
<mup> PR snapd#3731 closed: interfaces: allow /usr/bin/xdg-open in unity7 (2.27) <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3731>
<niemeyer> zyga-ubuntu, ikey, mvo: Folks, let's please stop supporting mkversion.sh to take the version as an argument..
<niemeyer> Actually, let me open a forum topic for that
<ikey> well im not gonna support dpkg-parsechangelog :p
<niemeyer> ikey: mkversion.sh encodes the version into the filesystem
<ikey> shouldn't the "if git" stuff be more relevant, with a well defined in-tree version?
<ikey> vs "i have a vendored tarball that should know what its own version is"
<niemeyer> ikey: There shouldn't be any need to support the changelog
<ikey> because mkversion is mostly about dirty trees
<ikey> from what i can tell.
<niemeyer> ikey: No, clean trees produce clean versions as well
<ikey> not in a vendor tarball :D
<niemeyer> Well, that's exactly the point.. it shouldn't ever be run in a tarball.. the tarball should contain the actual version instead
<ikey> right
<niemeyer> Topic in the forum..
<zyga-suse> niemeyer: sounds ok
 * zyga-suse returned from a long walk
<niemeyer> I should go out as well.. it's been a while since I've taken some proper sunlight..
 * niemeyer steps out for a while
<tpatel> Does brand store include all public snaps by default? If not, can I select the needed public snaps to be included in brand store?
<noise][> tpatel: it is possible to either include the entire contents of the default store or select individual snaps
<tpatel> noise: thanks. Will the selected public snaps when updated on the public store, gets auto update on the brand store as well?
<noise][> yes
<tpatel> noise: Can i control the public snap update to be updated on brand store? Make sure all the snap in my brand store are working without any issue with updated public snaps and then release them to stable.
<mup> PR snapcraft#1436 closed: cli: properly handle exceptions <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1436>
<mup> PR snapcraft#1486 opened: core: improve source caching logic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1486>
<mup> PR snapcraft#1487 opened: python plugin: record manifest <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1487>
<mwhudson> woop https://buildd.debian.org/status/package.php?p=snapd
<ahoneybun> anyone have example electron apps?
<ahoneybun> looking to see if we can snap riot.im
<Chipaca> ahoneybun: did you search the forum?
<mup> PR snapd#3733 opened: switch to canonical path for gopkg.in/cheggaaa/pb.v1 <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3733>
#snappy 2017-08-15
<mup> PR snapd#3734 opened: add packaging for debian-unstable <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3734>
<chad_young> I am looking for help with snapcraft (on a working snap), anyone here good at it?
<mwhudson> whoa the failure in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-snappy-dev-image/artful/amd64/s/snapd/20170815_034238_adfc1@/log.gz is funky
<mwhudson> (and surely not related to the change)
<mup> PR snapd#3727 closed: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3727>
<mup> PR snapd#3726 closed: interfaces: backport broadcom-asic-control interface (2.27) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3726>
<zyga-suse> mvo: hello
<zyga-suse> mvo: I see you are busy already :)
<zyga-suse> mvo: I'm off today, just preping the leave the house
<mvo> zyga-suse: good morning! yes :)
<mvo> zyga-suse: uploading a 2.27.2~rc1 to artful to get the "real" autopkgtest running on it
<mvo> zyga-suse: to validate the the i386 416 issue is really fixed
<zyga-suse> great
<zyga-suse> mvo: if you make a tarball and give me the URL I'd love to check suse later
<zyga-suse> re
<zyga-suse> sorry I got disconnected
<zyga-suse> what is the 416 issue?
<mvo> zyga-suse: no worries. there is an autopkgtest failure in artful (and other) on i386 where the server replies 416
<mvo> zyga-suse: turns out (apparently) we already have the full snap and send a GET anyway and the content-rage is data>size which the server cannot honor
<mvo> zyga-suse: welcome back, did you see anything I wrote before you disconnected?
<zyga-suse> ah, I see, I _found_ that problem :D
<zyga-suse> zyga-suse: to validate the the i386 416 issue is really fixed
<zyga-suse> this is the last message I saw
<zyga-suse> do you have the RC tarball already
<zyga-suse> and will you change it again to remove the rc wording?
<zyga-suse> mvo: to watch later, https://www.youtube.com/watch?v=SPr--u4n8Xo
<mvo> zyga-suse: I will change the rc wording hopefully this evening, unfortunately the publishing/autopkgtest runs takes a litte while :(
<mvo> zyga-suse: but it will be quicker than a 2.27.3 if this is not actuallly the issue :)
 * popey hugs diddledan 
 * zyga-suse merges big PR to help gary-wzl 
<zyga-suse> gary-wzl: can you please merge master into your udev branch now
<zyga-suse> gary-wzl: I think everything has landed so we should now see the interesting parts in that diff
<mup> PR snapd#3714 closed: interfaces: a bunch of interfaces test improvement <Created by adglkh> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3714>
<gary-wzl> zyga-suse: Oh nice. working on it now
<zyga-suse> thank you!
<gary-wzl> I just happened to ping you as there's only one(bit) PR left to merge. You did it
<gary-wzl> Thanks!
<zyga-suse> mvo: do watch that, it's interesting
<mvo> zyga-suse: you remember that error when snap/snapd versions got out of sync? iirc you had that at some point
<zyga-suse> yes
<mvo> zyga-suse: I wrote a testcase that tries to reproduce it but for me on core install undo things get restarted correctly :/ you don't happen to have more details/memory about the failure?
<zyga-suse> "crazy insecure lunacy of appimage"
<zyga-suse> oh boy, shots fired
<zyga-suse> mvo: mmm, is it the case where snapd is new and snap is old?
<mvo> zyga-suse: correct
<zyga-suse> while I may be missing the details I think one thing that is sufficient is a refresh failing so if you hack the script (like we did in one other test) to always fail (the configure script) I think you can then refresh to that snap
<zyga-suse> and then I think it will happen
<zyga-suse> I know we allow the configure to fail
<zyga-suse> but there must be a real way to make this happen as it runs in the wild
<mvo> zyga-suse: yeah, I did pretty much that and it restarts back to the right version for me
<zyga-suse> was it also related to changelog and stale version number?
<zyga-suse> oh? it restarts?
<mvo> zyga-suse: yeah, it restarts into the new version but on undo it also restarts into the old version - this is the puzzling part
<zyga-suse> mmm
<zyga-suse> indeed
<zyga-suse> is that also the case that gustavo hit?
<zyga-suse> I mean, for him it did _not_ restart
<mvo> zyga-suse: I will push the test soon, there must be something I am missing, as gustavo hit it too
<zyga-suse> what happened there?
<mvo> zyga-suse: correct
<mvo> zyga-suse: I don't know, I keep digging, for gustavo it was "out-of-diskspace", anyway, just wanted to check if there is anything you remember that might help me :)
<zyga-suse> I see, sorry I'm not much of a help
<mup> Bug #1627643 changed: oops on pi3 (seemingly wlan related) <Snappy:New> <linux-raspi2 (Ubuntu):Fix Committed by p-pisati> <https://launchpad.net/bugs/1627643>
<mup> Bug #1678076 changed: console-conf crashes with eth0 and wlan0 on Pi 3 <Snappy:New> <subiquity (Ubuntu):Fix Committed> <https://launchpad.net/bugs/1678076>
<mvo> zyga-suse: no worries, I keep digging
<mup> Bug #1627643 opened: oops on pi3 (seemingly wlan related) <Snappy:New> <linux-raspi2 (Ubuntu):Fix Committed by p-pisati> <https://launchpad.net/bugs/1627643>
 * zyga-suse goes to the park with his family
<zyga-suse> good luck mvo, please PM me on telegram with the 2.27.2 URL
<zyga-suse> I'll release suse then
<Chipaca> pedronis: aw! that PR was all green, and now i've got to push to it. You know it's not going to be all green next time :-(
<Chipaca> pedronis: ^^^ that's a joke by the way
 * Chipaca has had too little sleep
<ogra> oh. lovely !
<ogra> https://askubuntu.com/questions/938606/dwarf-fortress-starting-during-apt-get-upgrade
<ogra> (nearly as good as "libreoffice only prints on thursdays" )
<pedronis> Chipaca: heh
<pedronis> Chipaca: mmh, now that IÂ think, is this stuff tested by spread?  or only the global setup?
<Chipaca> pedronis: good point, i could add a spread test variant that doesn't source complete.sh
<Chipaca> pedronis: but
<Chipaca> pedronis: in both cases it'll now be testing the snippets :-)
<pedronis> Chipaca: so sourcing it and having the snippet at the same time doesn't confuse things?
<Chipaca> nope
<pedronis> good
<Chipaca> well
<Chipaca> no, but now that i think of it, if you source it it doesn't hit the snippets
<Chipaca> so we want that spread variant
<Chipaca> â¦ which is a lot more work than just adding a variant because it doesn't multiply on its own :-/
<Chipaca> eh. i could just try the snippets, and test the snippetless in one case
<Chipaca> anyway, i'll get back to it and add something
<Chipaca> right now i have panics to sort out :-)
<Chipaca> silly managers_test
<mvo> Chipaca, pedronis, zyga: have you ever seen something like this runtime: pointer 0x11673605 to unused region of span (http://paste.ubuntu.com/25318446/ ) - this is an autopkgtest failure in artful on i386 that is blocking us currently. I will write a forum topic too and investigate further just wanted to hear if you guys have seens this before
<mvo> (extra fun, the autopkgtest log is 20mb big and makes poor old firefox very unhappy)
<Chipaca> mvo: niiiice
<Chipaca> mvo: https://github.com/CanonicalLtd/dqlite/issues/7
<mvo> Chipaca: extra points because I can *not* reproduce it in my own autopkgtest setup when I run it inside qemu :(
<Chipaca> mvo: artful is 1.8?
<mvo> Chipaca: yes
<Chipaca> âIn Go 1.8 the garbage collector has changed so that when you change the value of a pointer field, the old pointer is "shaded". In this case the C code has modified that old pointer so that it is no longer a valid Go pointer, since Go pointers, unlike C pointers, are not permitted to point past the end of an object. The garbage collector is now detecting that fact, and is complaining.â
<Chipaca> mvo: i'm terrible at understanding what in that stacktrace is the code _doing_ that, however :-/
<mvo> Chipaca: hmmmmm, interessting. I would assume this only affect cgo and we have elimiated all that code, no?
<mvo> Chipaca: yeah, the trace is hard to read
<Chipaca> mvo: I'm pretty sure we have cgo again
<mvo> Chipaca: hm, maybe that was a bad idea then :)
<mvo> Chipaca: also funny, only happening on i386, not on amd64
<Chipaca> mvo: would I be shocked if it were a bug in os/user.a or net.a in go itself?
<Chipaca> mvo: your autopkgtest setup that you run in qemu, is it also artful?
<mvo> Chipaca: net.a sounds plausible indeed
<mvo> Chipaca: I will run again, maybe I used the wrong image, i did not sleep well last night :(
<Chipaca> mvo: my next question was whether your qemu was multi-cpu, and whether the "real" autopkgtest was also mutli-cpu
<mvo> Chipaca: aha, thats a good one, I need to check. If I can reproduce, I can try a cgo-less built and see if it goes away (if we can still do it)
<Chipaca> mvo: probably not, but maybe
<Chipaca> mvo: i _think_ there's a replacement pure-go user.Current() (which 1.6 didn't have, so it would panic)
<Chipaca> mvo: but i'm not 100%
<mvo> Chipaca: it looks like we still have the test for it
<Chipaca> mvo: yes, but it's a runtime panic, not a build failure
<mvo> Chipaca: tests/main/static
<mvo> Chipaca: sure, what I mean is it ought to still be possible to built it without cgo
<mvo> Chipaca: thanks a lot for your ideas so far, I will poke at it a bit harder
<Chipaca> mvo: yes! yes. What I meant is that with 1.6 you can build it but user.Current() throws an error
<mvo> Chipaca: aha, ok
<mvo> Chipaca: sorry, misunderstood.
<Chipaca> mvo: because os/user/lookup_stubs.go's Current(), which is the one that loads without cgo, just returns 'not implemented'
<Chipaca> but that's 1.6
<mvo> fun
<Chipaca> ah
<Chipaca> 1.8's stub is much smarter
<Chipaca> https://golang.org/src/os/user/lookup_stubs.go
<mvo> Chipaca: aha, nice
<mvo> Chipaca: I keep you updated, thanks again for your help
 * mvo gets lunch
<Chipaca> lunch! a radical concept
<Chipaca> niemeyer: i think this is because i had a slightly older spread, but: http://pastebin.ubuntu.com/25318689/
<niemeyer> Chipaca: Looks like a Linode issue ("something went wrong")
<niemeyer> Chipaca: I don't recall spread being broken in that way
<zyga-suse> mvo: any idea what that crash may be?
<zyga-suse> anything happening at that time
<Chipaca> zyga-suse: the one with the weird backtrace?
<zyga-suse> yes
<Chipaca> zyga-suse: cgo fighting with the garbage collector
<zyga-suse> with gc crashing
<zyga-suse> aha
<zyga-suse> cgo?
<Chipaca> cgo
<zyga-suse> because syscall?
<zyga-suse> or because of something else?
<Chipaca> zyga-suse: syscall <=!=> cgo
<zyga-suse> ok
<Chipaca> zyga-suse: probably net, but could be os/user
<Chipaca> only bits of cgo we have in snapd
<mvo> zyga-suse: I'm writing a forum post now, I can reproduce in an artful i386 vm
<Chipaca> huzzah!
<zyga-suse> luck in bad luck
<mvo> reproduce != fix :(
<mvo> but yeah, progress!
<zyga-suse> mvo: we are experts, we can do _anything_
<mvo> (looks thorny though)
<zyga-suse> including fixing compiler and GC bugs
 * mvo conjures up a unicorn and a cup of tea
<mvo> zyga-suse: indeed we can :)
 * zyga-suse was partially joking about 7 perpendicular lines
<pedronis> Chipaca: IÂ would hope net is more exercized than os/user
<pedronis> otoh 386 , might a be a size issue
<Chipaca> mvo: to be clear, if this is what we think it is, it's going to be a slow one to resolve
<Chipaca> as in, quickest involves a ticket with upstream go, and if they agree on our analysis, distropatching
<pedronis> also do we know if it fails with 18.3 ?  seems that's in artful proposed
<Chipaca> 1.8.3?
<pedronis> yes, sorry
<Chipaca> mvo: could you try with golang from artful proposed?
<mvo> Chipaca: yeah, trying some things now. I was not able to reproduce it with git master, maybe related to the packaging in some way
<Chipaca> mvo: ours, or theirs, git master?
<mvo> our git master
<mvo> of snapd
<mvo> (sorry)
<pedronis> that sounds weird
<Chipaca> apology accepted
 * Chipaca goes for mate
<pedronis> otoh not unhread of that moving stuff in memory
<pedronis> fixes this kind of stuff
<cachio> niemeyer, I-ll be few minutes late
<popey> ikey: just installed a snap locally on up to date solus, and it hasn't connected any of the interfaces automatically.
<popey> ikey: seen that before?
<ikey> don't know enough about them at this point
<ikey> i know the gnome ones do that
<ikey> but thats a known issue on the forums
<niemeyer> cachio: Ack, thanks for the note
<ikey> opengl/home/etc/ all work here
<popey> lemme try another one, maybe this snap at fault
<ikey> ok
<popey> none of them connected here, with a snap locally installed - not from the store
<ikey> oh locally
<ikey> ok that ive not tried
<popey> ok, worked with this second snap, so must be my snap at fault :S
<popey> sorry for the noise :)
<ikey> no np at all - i like that its getting testing from folks more qualified than me :))
<popey> Steady :)
<popey> I'm not _that_ qualified :)
<ikey> well im certainly not :p i mashed bits together until they fit
<ikey> lol
<ikey> solus in a nut shell really..
<ikey> xD
<popey> :)
<ikey> gotta ask ...
<ikey> which version of solus did you get?
<popey> oh my, I'm not sure I want to admit the level of fail I have made
<ikey> s/version/edition/
<popey> lsb_release says 3
<ikey> gnome/mate/budgie?
<popey> oh, i have all three :D
<ikey> oh wow ok lol
<popey> ALL THE VMS
<ikey> flexiondotorg casually ignores the others like they dont exist and only sees MATE :p
<popey> I'm currently in the budgie one because that's the OG one IMO
<ikey> hah ty
<flexiondotorg> mate mate mate mate mate
<ikey> XD
<popey> (I missed the word "plugs:" in my yaml)
 * ikey just sees the finding nemo seagulls
<zyga-suse> o/
<popey> This is surprisingly not detected by snapcraft!
 * zyga-suse sends regards from his free day 
<ikey> \o
 * ikey is playing it a bit fast and loose with version numbers lately
<ikey> Budgie 10.3.1 -> Budgie 10.4 = change basically everything
<ikey> this isnt how minor releases work..
<ikey> then solus 2017.04.18.0 -> 3
<ikey> XD
 * ikey will pretend that the versions were stored in mariadb with VARCHAR(1) hence the increment
<zyga-suse> jjohansen: hey
<zyga-suse> jjohansen: can you please tell me quickly what is missing in 4.14 wrt apparmor, AFAIR you said you will not get one patch in, can you shed some light on that?
<tyhicks> zyga-suse: it'll be a little while before he starts his day but I can help
<zyga-suse> tyhicks: oh, thank you, if you know about this I'm all ears
<tyhicks> zyga-suse: the mediation feature that won't make it in is UNIX domain socket mediation
<tyhicks> zyga-suse: that kernel feature translates to policy rules such as "unix (getattr, shutdown) addr=none,"
<tyhicks> zyga-suse: signals, mount, and AF_SOCKET mediation will make it in
<zyga-suse> tyhicks: thank you!
<tyhicks> zyga-suse: unfortunately, dbus mediation depends on the UNIX domain socket mediation so "unix" and "dbus" rules will be the only two remaining rules that aren't supported in 14.14
<tyhicks> s/14.14/4.14/
<zyga-suse> I was wondering if we could do a policy for 4.14 vanilla without this patch around
<zyga-suse> or if this patch is huge
 * zyga-suse looks at http://kernel.ubuntu.com/git/ubuntu/ubuntu-artful.git/log/security/apparmor
<zyga-suse> aha
<zyga-suse> tyhicks: do you know if this is still being discussed upstream or is it just because of merge window timings?
<tyhicks> zyga-suse: merge window timings - jj had some reworking to do on the UNIX mediation implementation that is taking a little longer than what will be possible to land in 4.14
<zyga-suse> ack
<sergiusens_> mvo: hey, are you going to be fixing the test errors on https://github.com/snapcore/snapcraft/pull/1419 ?
<mup> PR snapcraft#1419: meta: add `base` as a type and top level property <Created by mvo5> <https://github.com/snapcore/snapcraft/pull/1419>
<sergiusens_> or should I bump that to the next release? We are cutting it today
<pedronis> niemeyer: btw the first PR for repairs is this one: snapd#3560
<mup> PR snapd#3560: cmd/snap-repair: implement most logic to get the next repair to run/retry in a brand sequence <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3560>
<niemeyer> pedronis: Thanks!
<niemeyer> pedronis: Is the numeric order the best one to do reviews also?
<Chipaca> 8-|
<pedronis> mostly yes
<Chipaca> why is the managers_test hitting the actual real store
 * Chipaca takes a break before coming back to dig
<pedronis> Chipaca: it usually shouldn't, but maybe somethign has changed
<Chipaca> pedronis: well, I changed something :-D
<pedronis> Chipaca: it runs the real Ensure
<Chipaca> but â¦ bah. need to dig.
<pedronis> fwiw
<pedronis> so unless you are careful it will tend to talk to the real store
<Chipaca> pedronis: yeah but as there's a fake store in there i assumed it was hitting that
<pedronis> for some stuff
<pedronis> it depends exactly what you do
<pedronis> I know IÂ had to tweak again in one of my PRs for example
 * Chipaca goes to take that break
<Chipaca> pedronis: i'll come back with a shovel and a mug of tea
<pedronis> niemeyer: yes about number for repairs,  IÂ have some other PRs around about generic and stuff, of those only snapd#3710 would be nice to land sooner
<mup> PR snapd#3710: many: allow and support serials signed by the 'generic' authority instead of the brand <Created by pedronis> <https://github.com/snapcore/snapd/pull/3710>
<niemeyer> pedronis: Ok, I'll start from there then
<Chipaca> pedronis: my ensureMisc thing just needed to check CanAutoRefresh != nil :-D
 * Chipaca is Very Good With Names
<diddledan> popey, I've submitted the gradio PR: https://github.com/haecker-felix/gradio/pull/197
<mup> PR haecker-felix/gradio#197: add support for snap package building <Created by diddledan> <https://github.com/haecker-felix/gradio/pull/197>
<popey> diddledan: yay!
<popey> thanks diddledan
<pedronis> Chipaca: we don't set a Timeout on the client for downloads because if don't know how long it will take, but there's Transport.ResponseHeaderTimeout , do you think it would make sense to set that?
<pedronis> s/if don't/we don't/
<Chipaca> pedronis: what is it by default?
<Chipaca> and is it there in 1.6? i thought finer timeout control was post-1.6
<pedronis> it's in 1.6
<Chipaca> cool
<pedronis> and default is as usual, no timeout
<pedronis> IÂ mean also in DefaultTransport
<Chipaca> pedronis: no timeout means OS timeout means 30 seconds i think
<pedronis> so not worth for download
<pedronis> we just take that
<popey> sgclark: heya https://forum.snapcraft.io/t/change-owner-of-some-kde-apps/1682/2 - could you confirm the account to migrate to please? :)
<Chipaca> pedronis: i think so
<Chipaca> pedronis: for other things i'd love to make it much smaller, but people will get upset
<pedronis> ok, asked because IÂ need to twek httputil.ClientOpts to control some tls stuff
<Chipaca> pedronis: there were some notes by netflix (or was it backblaze?) about tweaking these timeouts for production, did you see that?
<Chipaca> it's about 6 months old i think
 * sgclark looks
<pedronis> don't remember
<Chipaca> ah, https://blog.cloudflare.com/the-complete-guide-to-golang-net-http-timeouts/
<Chipaca> pedronis: ^
<sgclark> popey: done :)
 * popey hugs sgclark 
<popey> thanks
<Chipaca> pedronis, niemeyer: if I write a single everything-panics fakeStore, should I put it in store/fake and call it Store?
<pedronis> Chipaca: we tend to put that sort of stuff in X/Xtest  like snap/snaptest   or asserts/assertstest
<niemeyer> Chipaca: It's a bit unclear what the use is for something that only panics... not sure if that deserves to be on its own package?
<Chipaca> storetest.FakeStore is at least 20% less cute than fake.Store though :-)
<Chipaca> niemeyer: we have 4 implementations of it already
<Chipaca> niemeyer: :-)
<niemeyer> Chipaca: I said it was unclear to me, not that that it wasn't being used :)
<Chipaca> niemeyer: :-)
<niemeyer> Chipaca: Why do we need those?
<Chipaca> niemeyer: everything that needs a fake store stubs out some of them, and implements the ones it cares about
<niemeyer> Chipaca: I see
<niemeyer> Chipaca: Yeah, what pedronis said then.. sounds like storetest
<Chipaca> niemeyer: overlord/devicestate/devicestate_test.go vs overlord/assertstate/assertstate_test.go vs daemon/api_test.go vs overlord/snapstate/backend_test.go
<pedronis> Chipaca: storetest.Mock  ?
<niemeyer> Chipaca: The issue with fake is that we cannot have fake.Assert, fake.Store, fake.Foo
<niemeyer> Chipaca: Because they all conflict
<Chipaca> niemeyer: unless we had testutil/fake/<stuff>
<niemeyer> Chipaca: Yeah, but then you have a massive package which . it.. you get
<niemeyer> *... you get it
<pedronis> Chipaca: this comes from the stdlib,    http/httptest etc
<Chipaca> ok
<ikey> TFW you dont make it into this week in snapcraft.. :p
<Chipaca> so what's the thing itself called?
 * Chipaca hugs ikey 
<ikey> xD
<pedronis> Chipaca: IÂ don't think we have uppercase Fake stuff
<pedronis> except in tests/lib/ maybe
<niemeyer> Chipaca: storetest.BrokenStore? :P
<Chipaca> PanicingStore
<Chipaca> storetest.LetsGoShopping
<niemeyer> storetest.Store seems fine :)
<Chipaca> okey doke
 * Chipaca runs with it
<mvo> sergiusens: i missed the errors, sorry, on it now
 * ogra sees https://forum.snapcraft.io/t/snap-dependencies/1699/1 and runs away screaming
<ikey> build + runtime dependencies..
<ikey> hm what else can do that..
<ogra> no, this is about actual snap dependencies (things you want pre-installed before a snap can run)
<ogra> pretty much going back to dpkg
<ogra> (instead of bundling)
<ikey> ya swhat i said :p
<ogra> heh, sorry ...
<ikey> oh don't be - i'm surprised ive gotten this far in life with anyone understanding me xD
<mup> PR snapd#3735 opened: many tests: move all panicing fake store methods to a common place <Created by chipaca> <https://github.com/snapcore/snapd/pull/3735>
<popey> sgclark: cprov has moved the snaps over, over to you! :D
<niemeyer> pedronis: #3710 just reviewed.. will have lunch and continue soon
<sgclark> popey: thanks so much for your help :)
<ogra> hey sgclark good to see you around :)
<sergiusens> sgclark: hey, are you also taking care of konversation (the snap is my current irc app)?
<sergiusens> popey:  does the lxd snap work on solus?
<sgclark> hi ogra! yeah I am happily on the neon team and we are snappifying kde apps
<ogra> yay
<sgclark> sergiusens: hi! yes we will be moving to snaps for all apps, in time
<sergiusens> oh, nice!
<sgclark> much work to be done :)
<popey> sergiusens: no
<ogra> oh ?
<ogra> why not ?
<popey> http://paste.ubuntu.com/25319481
<sergiusens> sgclark: great to hear, the contact info in the snap tells me to go to kde.org but I was wondering if there is a better place to report issues?
<sergiusens> my current one now is that opening links is quite slow and I have to choose the handler every time
<ogra> popey, hmm ... ouch ... sounds like LD_LIBRABRY_PATH bits missing ?
<sergiusens> popey: that's unfortunate, it would of made me switch for a while ;-)
<ogra> *LIBRARY
<sergiusens> ogra: but it works on ubuntu and fedora
<sgclark> sergiusens: doesn't look like we have konversation, let find out who did it
<sgclark> me*
<sergiusens> hah
<ogra> sergiusens, yeah, must be something missing in snap-configne for classic snaps on solus ... i bet liblxc.so.1 is somewhere undr /snap/lxd/current/
<ogra> *confine ...
<sergiusens> ogra: lxd is not classic
 * ogra cant type anymore 
<ogra> oh
<ogra> indeed
<ogra> lxd-support interface ?
<sergiusens> popey: does the client side work? `lxc list`
<sergiusens> yeah, maybe the interface is not connected, but it should
<ogra> (does solus have that yet)
<popey> it complains that lxd isnt setup
<ikey> solus doesn't have lxd, because, well, it wasn't really in demand..
<ikey> and we kinda have docker, etc..
<ogra> ikey, well, its a snap :) ... just needs the interface enabled
<sergiusens> ikey: there is a snap, just figuring out why it doesn't work
<ikey> could try LD_DEBUG=files in the environment before running lxc/lxd
<ikey> and find out where the linker is looking
<ikey> where it shouldnt
<ikey> tis possible the snap is making some multiarch assumption
<sgclark> sergiusens: ok looks like sitter did it under KDE infra, please report on bugs.kde.org
<sergiusens> ok, sounds good, but sgclark are you taking that under the neon umbrella soon?
<popey> http://paste.ubuntu.com/25319510
<sgclark> neon is under kde umbrella :) so will remain the same
<sgclark> sergiusens: ^
<sergiusens> got it
<sergiusens> popey: I guess I'll be installing solus and figuring it out unles I accidentally ping stgraber and he fixes it before I can blink ;-)
<popey> hehe
<pedronis> niemeyer: answered
<ogra> jdstrand, hmm http://paste.ubuntu.com/25319575/ ... shouldnt that suggest the kernel-module-control interface instead of talking about env vars ?
<ogra> ( i wonder what any of the vars would help here )
<niemeyer> pedronis: certified is such a strange name for this idea
<niemeyer> pedronis: Too late I guess
<niemeyer> It really means "verified"
<pedronis> yes
<pedronis> niemeyer: I think we use it so little that we could change it, but it's a bit of a separate issue
<niemeyer> Yeah
<jdstrand> ogra: yes, it should. note that snappy-debug doesn't have AI so it has to be taught this stuff ;)
<jdstrand> ogra: I'll take care of that
<ogra> thanks :)
<pedronis> niemeyer: anything else? as I wrote  the other changes around assertstest, NewStoreStack IÂ would prefer to do them in a follow up
<niemeyer> pedronis: No, per note there LGTM once you're happy
<niemeyer> pedronis: The core change is sensible
<pedronis> ok, I fixed the error now, then I'll merge, and rework NewStoreStack in a different PR
<diddledan> just waiting on the review to add this to the store: https://github.com/diddledan/gnome-twitch-snap
<mup> PR snapd#3568 closed: snapctl: add new `snapctl internal configure-core`  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3568>
<mup> PR snapd#3594 closed: corecfg: add proxy configuration via `snap set core proxy.{http,https,ftp}=...` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3594>
<diddledan> needs someone to approve my coopting of the name :-)
<diddledan> popey: flexiondotorg: I've just imported gimp into snapcrafters org and set the autobuilder running
<popey> diddledan: nice!
<diddledan> I don't believe I can change the ownership in the store, though, so I'll have to leave that up to one of you, popey
<mup> PR snapd#3710 closed: many: allow and support serials signed by the 'generic' authority instead of the brand <Reviewed> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3710>
<zyga-suse> re
 * zyga-suse is home
<ogra> shouldnt you then be zyga-home ?
<ogra> :P
<zyga-suse> :-)
<zyga-suse> I was in a tank today
<zyga-suse> I should have joined as `zyga-tank`
<popey> diddledan: who currently owns it?
<popey> diddledan: you can make a request in the store category and likely cprov will action it :)
<popey> (on the forum)
<diddledan> I own the name in the store. so it just needs moving to snapcrafters. the git repo is moved now as I do have access to do that bit :-)
<popey> kk, so yeah, make the request and it'll get done
<diddledan> new snap :-) https://forum.snapcraft.io/t/call-for-testing-gnome-twitch/1701
<popey> \o/
<popey> diddledan: need to add "snap install gnome-3-24" to your instructions
<diddledan> well caught. that's fixed now
<popey> ooh, the page just dynamically changed when you edited it
<diddledan> it's a cool forum!
<popey> gonna post on the snapcraft socials ;)
<diddledan> ok, I've hit a snag - it doesn't work strict with dbus issue.. let me see if I can fix that
<popey> ok, will delay the post, just let me know when you want me to release it
<diddledan> building now
 * diddledan twiddles thumbs while compilation churns
<popey> http://imgur.com/a/8gLad wanna embed that into your post to make it pretty? :)
<popey> if you download it and just drag it into the edit window for the post it should work
<diddledan> danke
<diddledan> done
<diddledan> the image is done, I mean
<popey> np
<diddledan> still building the fixed snap
<mup> PR snapcraft#1419 closed: meta: add `base` as a type and top level property <Created by mvo5> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1419>
 * diddledan sits patiently: â(-_-)ââ(-_-ï»¿)ââ(-_-)ââ(-_-)â
<popey> Throw some coal in the launchpad builders
<diddledan> https://imgs.xkcd.com/comics/compiling.png
<mup> PR snapd#3736 opened: apparmor: pass --quiet to parser on load unless SNAPD_DEBUG is set <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3736>
<jdstrand> stgraber: fyi ^
<zyga-suse> jdstrand: +1
<mvo> sergiusens: thank you so much
<diddledan> "human review required due to 'deny-connection' constraint for 'slot-attributes' from base declaration declaration-snap-v2_slots_deny-connection (dbus-gnome-twitch, dbus) "
<pedronis> Chipaca: I see, I thought a couple of times that snapstate.Store(), StorService etc should move to a something smaller, more specific under overlord  but never acted on it so farbut
<pedronis> Chipaca: all places you change import snapstate anyway
<cprov> diddledan, popey: gimp name transferred to snapcrafters.
<Chipaca> pedronis: yes, but what if snapstate wants to import it
<diddledan> thanks cprov
<pedronis> Chipaca: ?
<pedronis> Chipaca: snapstate_test you mean ?
<Chipaca> ah
<pedronis> it probably does but is not snapstate
<Chipaca> :-)
<Chipaca> fair 'nuf
<Chipaca> i'll fix it (later)
<Chipaca> right now i'm EODing with extreme prejudice
<Chipaca> :-)
<diddledan> just waiting on a manual review, popey. I've tested it locally and strict works, but it won't publish in the store until someone OKs the dbus socket
<jhobbs> can someone look at https://bugs.launchpad.net/snapd/+bug/1710933 please? it seems like 2.26.10 has a regression preventing snapd from working in lxd containers
<mup> Bug #1710933: 2.26.10: snapd doesn't start in a container <cdo-qa> <cdo-qa-blocker> <snapd:New> <https://launchpad.net/bugs/1710933>
<pedronis> mvo: fyi, my first 'generic' PR is in now, so nothing needs reverting for 2.28
<niemeyer> Going outside for a bit.. back soon
<mup> PR snapcraft#1483 closed: lxd: path cannot have extra forward slashes <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1483>
<popey> niemeyer: liked the presentation of your ideas as a video. Do you have a green screen? Seemed pretty professionally done!
<mup> PR snapcraft#1479 closed: rosdep: add support for multiple dependency types <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1479>
<popey> jdstrand: i just updated the slot definition for gnome-twitch for diddledan - could you verify I did the right thing? (Not done slots before)
<popey> jdstrand: https://dashboard.snapcraft.io/dev/snaps/8171/
<jjohansen> zyga-suse: the unix patch (in ubuntu) isn't small, but mostly self contained. However the version going upstream depends on the typesplitting work which is large.
<zyga-suse> hey :)
<zyga-suse> jjohansen: do you have any patches for refrence? I would like to encourage some distributions to ship that on top of 4.14
<zyga-suse> can you tell me more about typesplitting?
<jjohansen> zyga-suse: hey, sorry I just haven't been able to finish this stuff up
<jjohansen> zyga-suse: the patches are a wip atm, I am hoping to have something to RFC by next week, that way I can get the upstream discussion started early
<zyga-suse> jjohansen: no worries, I understand
<jjohansen> zyga-suse: we need to be caching the type on objects, not just the domain label
<zyga-suse> I see
<jjohansen> currently (in ubuntu) we get around this problem by caching the unix socket path (a second time, ugly hack) and revalidating
<jjohansen> that isn't going to work for other sockets, and isn't going to fly upstream
<jjohansen> it also has a few artifacts in some corner cases
<jjohansen> basically if you think of apparmor in terms of TE (selinux), we use the domain (task) label, and look up a set of conditionals (path, ...) to find permissions
<jjohansen> that set of conditionals can resolved down to a type (in selinux terms). And we can store that on the object so that when we hit a revalidation case, where some of our conditionals are no longer available we can find the correct permissions
<jjohansen> basically the LSM is more structured to selinux and we need to do somethings to make apparmor more amenable to that upstream structure
<zyga-suse> I see
<zyga-suse> interesting explanation, I don't know the kernel parts that well but I'm eager to lern
<zyga-suse> learn*
<niemeyer> popey: Thanks! I made a green screen at home for about 3USD :)
<popey> hah, excellent
<popey> OBS?
<niemeyer> popey: Three layers of nonwoven fabric on an old whiteboard frame
<niemeyer> popey: https://goo.gl/photos/RWEU7jCzBa7Cdnp78
<popey> nice
<popey> totally doing this
<diddledan> what are you two scheming?!
<popey> hiding the crap behind my head when doing videos :D
<niemeyer> :)
<niemeyer> Not only that, but putting more interesting crap there! :P
<popey> true
<jdstrand> popey: looking. note that for snap declarations I recommend you come to the security team. they can be tricky to get right (though the one you did isn't) and our reviewers tooling doesn't help you (yet)
<jdstrand> popey: it looks fine. at this point you should scroll to the bottom of review page, add a comment like "Granting use of the well-known dbus name 'com.vinszent.GnomeTwitch' to the snap", then click 'Run the automated review again"
<popey> thanks jdstrand
<popey> noted for next time :)
<jdstrand> popey: I didn't do the comment or button pushing for this one
<jdstrand> popey: I see a bunch of snaps that came in today. I'll take a look. I think the are all dbus related
<popey> excellent
<popey> i hit the button...
<jdstrand> cool
<diddledan> \o/
 * diddledan releases to beta
<diddledan> done
<popey> want me to release a social post?
<diddledan> ok, you can fire the social now :-)
<popey> \o/
 * popey gets the coal
<jdstrand> popey: I want to ask oSoMoN a question about chromium when he comes online, so am leaving that
<popey> kk
<popey> diddledan: sent
<diddledan> I see it
<ikey> adwaita
 * ikey shudders
<popey> You liked my choice of desktop to use in the screenshot? :)
<ikey> forgive me for saying but is that solus 3? :P
<popey> ya :)
<ikey> looks like solus 2017.04.18.0
<popey> fix ur version numbers
<ikey> or did you rejigger it?
<ikey> XD
<popey> #blamepopey
<ikey> but yeah nice use of budgie :]
<popey> no, it's whatever I instaleld and updated
<popey> This is one thing I love about posting on the snapcraft social stuff, we get to use whatever desktop is fun today :)
<ikey> Solus 3 https://solus-project.com/imgs/posts/2017/08/Budgie.jpg
<ikey> xD
<popey> odd
<popey> i only installed it last week or so
<popey> and updated as per the software doohdah
<ikey> yeah it was released around 4 this morning
<popey> hahah
<popey> oookay
<ikey> its ok you'll still be updated on "Solus 3"
<popey> gotcha
<ikey> we used a new branding pkg in that one
<ikey> plus this is cool because it means you're testing linux-lts (4.9.43)
<ikey> so we get both kernels tested now
<ikey> :]
<jdstrand> popey: fyi, I'm leaving https://dashboard.snapcraft.io/dev/snaps/8122/rev/8/ for the advocacy team
<jdstrand> I guess could leave a comment to ask to post something to the forum...
<popey> I'll add a card for it
<popey> will look in the morning
<popey> ikey: the downside is.. people expect it to be ubuntu... https://www.facebook.com/snapcraftio/photos/a.127475154349370.1073741828.106271556469730/350162465413970/?type=3&permPage=1
<popey> (hope that works) - person asking how you get the launcher in the top of the screen :)
<popey> oops
<popey> I'll throw them a solus link :)
<ikey> hah
<ikey> well it just so happens that budgie 10.4 was made to be backportable
<ikey> so i mean straight up its looking like it'll be in 17.10 anyway but could easily end up in older ones with PPAs
<ikey> supports 3.18 stack..
 * zyga-suse pulls in budgie desktop 
<zyga-suse> well, solus 3 that is
<zyga-suse> ikey: any useful link on "my first solus package" or "solus for developers"?
<ikey> erm
<ikey> context?
<ikey> like you need build tools right?
<ikey> i.e build-essential equivalent?
<zyga-suse> yes
<zyga-suse> and packaging primer
<ikey> sudo eopkg it -c system.devel
<ikey> https://solus-project.com/articles/packaging/
<ikey> note build tools are largely mutually exclusive of packaging
<ikey> as we mandate everyone builds packages using solbuild
<ikey> which is like basically if docker and schroot had a baby, and it wasn't an abomination
<JoshStrobl> Also: https://www.youtube.com/watch?v=rlPnHjUBpJ8 https://www.youtube.com/watch?v=xK-1726MWqQ https://www.youtube.com/watch?v=c_vIg3ep3YE
 * JoshStrobl goes back to watching Logan
<ikey> where did you com..
<ikey> logan is *win* btw, enjoy
<zyga-suse> :)
<ikey> this is the single most arch-linux-thing ive ever seen written https://twitter.com/fivelek/status/897544181165559813
<zyga-suse> thanks, let me look at those
<ikey> it served zero purpose other than telling everyone that they use arch linux xD
<zyga-suse> ikey: no, it served a purpose
<zyga-suse> ikey: I got to tell them snaps work on arch :D
<ikey> oh man he got reverse-preached
 * ikey approves
 * zyga-suse notices this channels has 284 people 
<pedronis> niemeyer: thanks for the repair review, I answered some things, I'll work through the feedback in my morning
<mwhudson> wth
<mwhudson> can someone tell me how to check if apparmor confinement is working?
<mwhudson> i thought it was broken in debian but actually it seems to be working now, very confused
<mwhudson> jdstrand: ^ -- is there maybe a test snap that tries to violate its confinement?
 * mwhudson forums
<tyhicks> mwhudson: #13 of https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor#Desktop_only would do
<iatrou> For snaps with classic confinement, like conjure-up, is there a workaround to make them work when $HOME is on NFS?
<mwhudson> iatrou: with classic confinement, no workaround should be needed...
<mwhudson> tyhicks: yeah, confinement is not working :(
<iatrou> mwhudson: and yet, running on snapd 2.25 conjure-up 2.2.2 it complaints: cannot create user data directory: /home/qz40qq/snap/conjure-up/549: Permission denied
<mwhudson> iatrou: huh :(
<zyga-suse> iatrou: any denials?
<zyga-suse> iatrou: I think classic confinement _still_ applies apparmor so there might be something missing
<zyga-suse> but ... what are the facts?
<iatrou> mwhudson: zyga-suse http://paste.ubuntu.com/25322186/
<zyga-suse> aha!
<zyga-suse> interesting
<zyga-suse> so yes
<zyga-suse> snap-confine itself is affected
<zyga-suse> interersting bug
<zyga-suse> iatrou: can you please open a forum topic on forum.snapcraft.io
<zyga-suse> I believe we can get that fixed
<iatrou> zyga-suse: sure thing, thank you!
<iatrou> mwhudson: zyga-suse https://forum.snapcraft.io/t/snaps-with-classic-confinement-and-nfs-home/1706
<zyga-suse> thank you
<mwhudson> zyga-suse: go to bed :)
<zyga-suse> I fell asleep earlier and now I cannot sleep
#snappy 2017-08-16
<PhoenixMage> hmmm, maybe today I will give samba dc another go *sigh*
<mwhudson> zyga-suse: maybe you can look at https://forum.snapcraft.io/t/snapd-vs-upstream-kernel-vs-apparmor/1704 then
<ikey|zzz> https://dev.solus-project.com/R2930:183f2e34c4e9fda0fe3eb06f170633c27d3a07f4
 * ikey|zzz walks out
<ikey|zzz> crap i typoed and meant solus 3
 * ikey|zzz walks out again
<willdeberry> hello all, anyone have a moment to assist with getting this snap i am building able to talk to dbus and bluetooth?
<willdeberry> i am currently getting the following: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied
<willdeberry> I have tried using the following plugs: network, network-manager, network-control and bluetooth-control
<willdeberry> do i have to switch to classic mode to get the support i am aiming for?
<willdeberry> repo link for reference: https://github.com/willdeberry/bjarkan
<chad_young> willdeberry: I am a novice so take my suggestions as such
<chad_young> I thought there was a bluez interface
<willdeberry> this is a non ubuntu core install so it doesn't show a bluez interface
<willdeberry> trying to use system's bluez/dbus
<chad_young> sorry - cant help - good luck
<willdeberry> :(
<willdeberry> i assume classic is the answer, but just want to exhaust all ideas before jumping to that
<chad_young> I really have a hard time believeing that "classic" is the only option
<willdeberry> agreed, which is why i am here :)
<chad_young> willdeberry - have you posted the same Q on https://rocket.ubuntu.com/home or the forums?
<chad_young> https://forum.snapcraft.io
<willdeberry> i have not. i can give rocketchat a try though
<PhoenixMage> Whats the correct way to restart a daemon inside a snap?
<PhoenixMage> Is there any way to prevent snapcraft from adding a copy of x86_64-linux-gnu/libpytalloc-util.so.2 when priming?
 * mvo hugs mwhudson
<mvo> mwhudson: about the panic in -buidmode=pie, where should I report this?
<mvo> mwhudson: reported against the debian golang-1.8 for now as 1711052
<zyga-ubuntu> good morning
<mvo> hey zyga-ubuntu!
<zyga-ubuntu> mvo: hey
<zyga-ubuntu> I see we know what the crash is caused by
<zyga-ubuntu> ish
<zyga-ubuntu> mwhudson: can you expand on the "it is a hack" comment
<mvo> zyga-ubuntu: yeah, very happy, testing a workaround (no pie for i386) and if that works we have 2.27.2 and a bottle of champagne (or maybe just a cup of tea)
<zyga-ubuntu> that works for me
<mup> PR snapd#3736 closed: apparmor: pass --quiet to parser on load unless SNAPD_DEBUG is set <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3736>
<zyga-ubuntu> brb
<mup> PR snapcraft#1488 opened: lxd: always remove existing device for project folder <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1488>
<mup> PR snapd#3737 opened: debian: do not build with -buildmode=pie on i386 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3737>
<mup> PR snapd#3738 opened: debian: do not build with -buildmode=pie on i386 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3738>
 * zyga-ubuntu wonders when launchpad will support markdown
<zyga-ubuntu> mvo: do we get build-id in non-pie mode?
<zyga-ubuntu> mwhudson: and do we need the same approach on armhf?
<zyga-ubuntu> mwhudson: what's the trigger, is it exactly i386 or is it all 32bit
<mvo> zyga-ubuntu: we still have a build-id
<zyga-ubuntu> mvo: when do you plan to release .2?
<mvo> zyga-ubuntu: as soon as I green light for the pie workaround
<mup> PR snapcraft#1474 closed: kbuild plugin: use ARCH from environment if set <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1474>
<zyga-ubuntu> mvo: it's green
<zyga-ubuntu> mvo: do you want to wait for adt?
<mvo> zyga-ubuntu: mostly interessted in feedback from mwhudson or Chipaca
<Chipaca> mvo: on what?
<Chipaca> aha
<PhoenixMage> zyga-ubuntu: Do you know if snapcraft puts a copy of libpytalloc-util.so.2 in x86_64-linux-gnu?
<zyga-ubuntu> PhoenixMage: if that library is referenced via DT_NEEDED
<zyga-ubuntu> PhoenixMage: snapcraft walks the built package and seeks shared libaries that are used
<zyga-ubuntu> PhoenixMage: it doesn't handle dlopen-style references though
<PhoenixMage> zyga-ubuntu: How would I stop it from doing that? It seems to be the wrong version and samba has one of its own. I get mportError: /snap/samba-dc/x1/usr/lib/x86_64-linux-gnu/libpytalloc-util.so.2: version `PYTALLOC_UTIL_2.1.9' not found (required by /snap/samba-dc/x1/usr/lib/samba/libsamba-python-samba4.so) when I run my program
<zyga-ubuntu> PhoenixMage: that I don't know, sorry, you need to ask a snapcraft developer for this
<PhoenixMage> ok thanks
<PhoenixMage> Anyone in channel a snapcraft dev? lol
<zyga-ubuntu> yes but typically in US timezones
<mvo> Chipaca: about disabling -buildmode=pie on i386 to workaround the panic, its 3738
<Chipaca> mvo: yes
<PhoenixMage> thats ok, I am usually up pretty late, my boss is in the US
<Chipaca> mvo: and spread fails with a weird error in the gccgo tests
<Chipaca> mvo: coincidence?
<mvo> Chipaca: probably
<mvo> Chipaca: buildflags is cleaned when gccgo is used
<mvo> Chipaca: so this should not affect anything, but let me look at the failure
<Chipaca> mvo: http://pastebin.ubuntu.com/25324369/
<Chipaca> save you the lookin'
<mvo> Chipaca: thanks! strange error
<Chipaca> mvo: that's what she said!
<Chipaca> :-)
<mvo> Chipaca: double fun, the 2.27 version is green
<Chipaca> mvo: hit that "AGAIN!" button and cross fingers
<zyga-ubuntu> mvo: xenial moved to 2.26.10
<mvo> zyga-ubuntu: yay
<zyga-ubuntu> mvo: "yay" but I'd make sure that update tests checked that version too
<mwhudson> zyga-ubuntu, mvo: no armhf should be ok
<mwhudson> zyga-ubuntu: and the "it's a hack" thing
<mwhudson> zyga-ubuntu: well you know you can't access the instruction pointer directly in i386 right?
<mwhudson> so whenever there is access to global data, which you want to do ip-relative
<mwhudson> the go compiler inserts a call to a function that copies the return address (i.e. the callers' ip) into bx and uses that
<mwhudson> the hack part is that it does this for _every_ access, there's no cleverness to avoid calling the stubs all the time
<mwhudson> so it should work, just with large and slow code
<mup> PR snapd#3733 closed: switch to canonical path for gopkg.in/cheggaaa/pb.v1 <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3733>
<mwhudson> the crash is unexpected :/
<mvo> most crashes are ;)
<mwhudson> mvo: this only happens in artful, not zesty etc?
<mvo> mwhudson: I have only observed it with go 1.8 but AIUI only 1.8 has the extra checks in the garbage collector
<mvo> mwhudson: that result in the panic
<mup> PR snapd#3730 closed: tests: adding more debug information for the interfaces-cups-control â¦ <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3730>
<mvo> mwhudson: so I would assume its also there in older versions, just undetected
<mwhudson> mmm
<mwhudson> no i think those checks have been there for a while
<mwhudson> i remember debugging them failing on ppc64 ages ago :)
<mwhudson> at least similar checks anyway
<mwhudson> ah hm no maybe you're right about this specific check is new
<zyga-ubuntu> gary-wzl: hey
<zyga-ubuntu> gary-wzl: comented on 3617
<zyga-ubuntu> mwhudson: yes, I know
<mwhudson> mvo: in any case if you have a smaller test case than "all of snapd" it makes sense to report it upstream and i'll try to fix it
<zyga-ubuntu> mwhudson: I see, so it's not a hack per se that it's all barely holding together,
<zyga-ubuntu> mwhudson: more of a creative coding on your part
<mvo> mwhudson: no smaller testcase yet unfortunately I can look some more for that. easy to reproduce with snapd though
<zyga-ubuntu> mwhudson: and the true cause of the bug is still a mystery
<mwhudson> zyga-ubuntu: yeah
<mwhudson> mvo: i tried and failed to reproduce it in an artful 32 bit lxd container i had lying around, but maybe i was doing something silly
<mwhudson> probably a vm is better
<mvo> mwhudson: if you could quickly ack/nack https://github.com/snapcore/snapd/pull/3737 that would be great
<mup> PR snapd#3737: debian: do not build with -buildmode=pie on i386 (2.27) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3737>
<mvo> mwhudson: the sequence appears to be important: "sudo dpkg --purge snapd; apt install snapd; sudo snap install --beta core" and watch syslog to see the crash
<mvo> mwhudson: for unknown reasons the system needs to be in a pristine state it seems
<mwhudson> mvo: dpkg --print-architecture isn't really right is it?
<mwhudson> mvo: surely you want dpkg-architecture -qDEB_TARGET_ARCH or something along those lines?
<mvo> mwhudson: I also got some cannot unmarshal json errors when run later but that might be fallout from the earlier panic
<mwhudson> ah i think i saw those ones
<mvo> mwhudson: indeed, let me fix that, I was too quick
<mwhudson> (the unmarshal json stuff)
<mvo> mwhudson: yeah, I suspect its fallout, but hard to tell
<mwhudson> mvo: commented on the PR
<mvo> mwhudson: thanks, fixed
<gary-wzl> zyga-ubuntu: Thanks!
<zyga-ubuntu> gary-wzl: what you did is fine (existing sprintf vs replace) -- I just made a remark because this is so close to being exactly the same everywhere I think it is worth to pursue this goal
<gary-wzl> zyga-ubuntu: I was thinking another PR would make more sense to isolate something unrelated to udev tagging rule.
<zyga-ubuntu> gary-wzl: if you can, please
<gary-wzl> zyga-ubuntu: yeah, working on that. We'll probably achieve a good results with smaller differ size on #3617 if I put it in that way
<gary-wzl> Thanks for your comments
<zyga-ubuntu> gary-wzl: thank you for the work so so much :)
 * zyga-ubuntu -> offline for 30 min
<Chipaca> mvo: don't you have the logic in the makefile backwards
<Chipaca> ah, no, +=
<Chipaca> ignore me :-)
<Chipaca> +1
<zyga-ubuntu> =
<zyga-ubuntu> }|}2~|"A
<zyga-ubuntu> }|A2~"
<zyga-ubuntu> adsf Â tr5fgr5tetfetfe45rf~~ju7777777777777777OH[24~
<pedronis> Chipaca: I nitpicked again, sorry
<ogra> zyga-ubuntu, got a new cat ?
<zyga-ubuntu> ogra: I was wiping dust off my keyboard
<zyga-ubuntu> ogra: :)
<ogra> :)
<Chipaca> pedronis: sigh
<Chipaca> pedronis: I think I'm going to move it in the followup pr
<Chipaca> otherwise i'm going to spend my day waiting for it
<pedronis> Chipaca: it's fine
<mup> PR snapd#3739 opened: Add read access to virtual disk hard drives in udisk2 interface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3739>
<pedronis> Chipaca: I mean, it's fine to do it in a follow up
<pedronis> Chipaca: btw, I'm not picky where after "type ..."
<Chipaca> mbuahaha
<Chipaca> i mean, ok
 * Chipaca puts it inside of Find
<pedronis> Chipaca: IÂ said not picky, not careless :)
<Chipaca> pedronis: aw :-D
<pedronis> Chipaca: IÂ mean  , either just after type or all the method defs, as you prefer
 * Chipaca nods
<Chipaca> pedronis: makes most sense to me to be right after type
<mvo> zyga-ubu1tu: geh, test failure in autopkgtest because cmd_interfaces_test.go fails with the following diff: http://paste.ubuntu.com/25324625/
<mvo> zyga-ubu1tu: do you mind if I simply this test?
<mvo> zyga-ubu1tu: something is doing line wrapping
<mup> PR snapd#3724 closed: wrappers: symlink completion snippets when symlinking binaries <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3724>
<Chipaca> mvo: the way i've addressed that kind of thing is by writing what I want so it's clearest, and then replacing all spaces with \s+
<pedronis> Chipaca: are you doing the spread tests tweak for the symlinks also in a follow up?  or you did it and I missed it
<Chipaca> or was it with [ \t\n]
 * Chipaca looks
<zyga-ubuntu> mvo: this is because go-flags changed
<Chipaca> pedronis: i did it and you missed it :-)
<zyga-ubuntu> mvo: do I mind if you simply _what_ this test?
<zyga-ubuntu> mvo: (+1 to kill it)
<ogra> cuddle
<ogra> :)
<mvo> zyga-ubuntu: heh, kill is one option :)
<mvo> zyga-ubuntu: I was thinking about just doing contains and only checking for a subset
<zyga-ubuntu> mvo: aha
<zyga-ubuntu> mvo: that's fine as well
<zyga-ubuntu> mvo: though I was actually hoping to kill it
<pedronis> Chipaca: thx
<zyga-ubuntu> the point of the test was to make sure it looks OK
<mvo> zyga-ubuntu: let me kill it then, even better
<zyga-ubuntu> and if we cannot eyeball it
<zyga-ubuntu> then lets kill it
<Chipaca> zyga-ubuntu: is there a commandline tool that looks at mountinfo?
<mup> PR snapd#3740 opened: tests: remove TestInterfacesHelp as it breaks when go-flags changes <Created by mvo5> <https://github.com/snapcore/snapd/pull/3740>
<mup> PR snapd#3741 opened: tests: remove TestInterfacesHelp as it breaks when go-flags changes <Created by mvo5> <https://github.com/snapcore/snapd/pull/3741>
<mvo> zyga-ubuntu: I only know cat for this :/
<zyga-ubuntu> Chipaca: maybe
<zyga-ubuntu> Chipaca: I know libmount handles stuff
<zyga-ubuntu> Chipaca: if it has any CLI tools then yes
<zyga-ubuntu> Chipaca: what do you neeD?
<zyga-ubuntu> Chipaca: I wrote a mountinfo -> json tool
<Chipaca> zyga-ubuntu: different question maybe: do you have nfs or autofs working anywhere?
<zyga-ubuntu> Chipaca: never published it
<zyga-ubuntu> Chipaca: no :/
<Chipaca> zyga-ubuntu: thinking about telling users "d'oh, your home is on the network, this ain't gonna fly"
<mvo> zyga-ubuntu: 3740 for you
<zyga-ubuntu> mvo: looking
<zyga-ubuntu> aah
<zyga-ubuntu> Chipaca: well, python is your friend, do you want this to be a standalone too
<zyga-ubuntu> Chipaca: or baked into snap?
<zyga-ubuntu> Chipaca: if latter I have all the libs ready
<Chipaca> zyga-ubuntu: i was just playing with the idea, but it'd be best to have it in snap itself
<Chipaca> e.g. make "snap run" print a warning
<Chipaca> OTOH, one could argue that if we detect this, we could auto-workaround it
<Chipaca> OTOÂ²H that seems Hard, so maybe just include an easy-to-use thing that sets it up, non-automatically, and detect and alert if it's not used
<zyga-ubuntu> Chipaca: mmmmmm
<zyga-ubuntu> Chipaca: we might
<Chipaca> yes
<zyga-ubuntu> Chipaca: but it's per user
<Chipaca> mmm indeeed
<zyga-ubuntu> Chipaca: and then it's too late-ish
<zyga-ubuntu> Chipaca: unless snap run would
<zyga-ubuntu> Chipaca: and would poke snapd
<Chipaca> zyga-ubuntu: yes, that's why in snap (as in, in snap run)
<Chipaca> zyga-ubuntu: and detecting it should be outside of snapd
<Chipaca> i mean, it's not snapd that needs to know this
<Chipaca> it's snap-confine
<Chipaca> right?
<zyga-ubuntu> Chipaca: it's both
<zyga-ubuntu> Chipaca: for home-on-nfs it requires at least three changes
<zyga-ubuntu> Chipaca: snap-confine, snapd for each app and apparmor defaults for home location
 * zyga-ubuntu -> coffee
<zyga-ubuntu> mvo: reviweed
 * zyga-ubuntu debugs something hairy
<Chipaca> zyga-ubuntu: not seeing the snapd one
<Chipaca> pedronis: you got the check move now because i'm a doofus :-)
<zyga-ubuntu> mvo: hey
<zyga-ubuntu> mvo: guess what
<zyga-ubuntu> mvo: I have a patch for 2.27
<zyga-ubuntu> 3 lines
<pedronis> Chipaca: because you had named params only in one place? or something else?
<Chipaca> pedronis: src/github.com/snapcore/snapd/store/storetest/storetest.go:33: undefined: storetest in storetest.Store
<pedronis> ah
<Chipaca> hasty, hasty, hasty
<pstolowski> mvo, hey, a comment to your testinterfaceshelp change
<pedronis> persons aren't great compilers but compilers are
<Chipaca> pedronis: I'm a great compiler
<Chipaca> of useless facts
<Chipaca> and dandruff
<mup> PR snapd#3737 closed: debian: do not build with -buildmode=pie on i386 (2.27) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3737>
<zyga-ubuntu> mvo: so please hold the line
<zyga-ubuntu> (release)
<mvo> zyga-ubuntu: ok
<mvo> pstolowski: yeah, I think its fine to look at this for master, for 2.27 I'm keen to get it out
<mvo> zyga-ubuntu: what is it about?
<zyga-ubuntu> mvo: pushing
<mup> PR snapd#3742 opened: interfaces: don't crash if content slot has no attributes <Created by zyga> <https://github.com/snapcore/snapd/pull/3742>
<zyga-ubuntu> mvo: backport up as well
<mup> PR snapd#3743 opened: interfaces: don't crash if content slot has no attributes (2.27) <Created by zyga> <https://github.com/snapcore/snapd/pull/3743>
<mvo> zyga-ubuntu: ta
<mvo> zyga-ubuntu: I was thinking, this diff rings a bell :)
<zyga-ubuntu> yes
<zyga-ubuntu> I feel so silly
<zyga-ubuntu> sorry for not doing it months ago
<mup> PR snapd#3743 closed: interfaces: don't crash if content slot has no attributes (2.27) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3743>
<mvo> zyga-ubuntu: no worries
<mvo> zyga-ubuntu: I run the criticial adt tests in artful/i386 now and when things are green will release 2.27.2
<zyga-ubuntu> ok
<zyga-ubuntu> mvo: I'm digging at one more issue related to content
<zyga-ubuntu> but no smoking gun yet
<zyga-ubuntu> so +1
<pstolowski> mvo, fair enough
<mvo> zyga-ubuntu: ok, adt will take a bit so that should be ok
<mvo> zyga-ubuntu: 3743 seems to be unhappy in the unit tests, can you please checkout the branch and run the unit tests?
<zyga-ubuntu> mvo: yes
<zyga-ubuntu> hmm
<mup> PR snapd#3740 closed: tests: remove TestInterfacesHelp as it breaks when go-flags changes (2.27) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3740>
<zyga-ubuntu> darn
<zyga-ubuntu> mvo: sorry
<zyga-ubuntu> bad backport!
 * Chipaca brb
<mvo> zyga-ubuntu: yeah, just do a followup I merged already as 2.27 is not blocked on spread and I did not notice :/
<zyga-ubuntu> ep
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/3744
<mup> PR snapd#3744: interfaces: correctly backport the patch <Created by zyga> <https://github.com/snapcore/snapd/pull/3744>
<mup> PR snapd#3744 opened: interfaces: correctly backport the patch <Created by zyga> <https://github.com/snapcore/snapd/pull/3744>
<zyga-ubuntu> seb128: hey
<zyga-ubuntu> seb128: can you please look at https://forum.snapcraft.io/t/content-interface-connection-issues/1585/21
<mup> PR snapd#3744 closed: interfaces: correctly backport the patch <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3744>
<seb128> zyga-ubuntu, what bit?
<zyga-ubuntu> seb128: I cannot reproduce the issue, can you check if my explanations makes sense
<zyga-ubuntu> seb128: not sure if the real issue is the lack of auto-connect
<zyga-ubuntu> seb128: or that at some time in the past the connection, even if made, did not really propagate
<zyga-ubuntu> s/propagate/result in things working/
<mup> PR snapd#3745 opened: interfaces: convert uhid to common interface and test cases improvement for time_control and opengl <Created by adglkh> <https://github.com/snapcore/snapd/pull/3745>
<seb128> zyga-ubuntu, btw the segfault seems a snap 2.27 regression
<zyga-ubuntu> seb128: aha, I see, I think this will be fixed with 2.27.2 then
<zyga-ubuntu> seb128: I'll try stable 2.26.14 now
<zyga-ubuntu> mvo: is 2.27.2 in candidate?
<seb128> zyga-ubuntu, did you see https://forum.snapcraft.io/t/content-interface-connection-issues/1585/20 ?
<seb128> or rather my reply to that
<seb128> "Where can I find 2.26.14? xenial-proposed only has 2.26.10.
<seb128> I tried 2.27.1 from artful-proposed but gnome-calculator abort on start with that version, that seems a different issue/a regression but it blocks me from verifying the fix."
<mvo> zyga-ubuntu: not even close :) its not even released yet, it will be in beta today
<zyga-ubuntu> seb128: if you install snapd on ubuntu it re-execs from core snap
<mvo> zyga-ubuntu: why?
<zyga-ubuntu> seb128: so you will just get the latest stable this way
<zyga-ubuntu> mvo: just wanted to check the regression is gone
<zyga-ubuntu> seb128: snap version
<seb128> zyga-ubuntu, then the issue was not fixed in current stable
<zyga-ubuntu> seb128: vs apt-cache policy snapd
<seb128> I confirmed the bug because uploading to 2.27
<zyga-ubuntu> seb128: ok, let me debug further
<seb128> zyga-ubuntu, the post I just gave had a testcase with gnome-calculator
<seb128> thanks
<seb128> zyga-ubuntu, is there any way to query snapd for the in-use version?
<seb128> snapd --version would be nice
<zyga-ubuntu> snap version
<zyga-ubuntu> that does both
<zyga-ubuntu> it tells you client and server version
<zyga-ubuntu> there's also a static file in /usr/lib/snapd/info
<zyga-ubuntu> and similar one in the core snap
<seb128> oh, k, easy
<seb128> I tried -v
<seb128> and --version
<zyga-ubuntu> ah, sorry about those
<zyga-ubuntu> wow, 2.26.14 indeed behaves oddly
<zyga-ubuntu> seb128: reproduced
<mvo> zyga-ubuntu: is 2.27 behaving correctly?
<zyga-ubuntu> mvo: so far yes, I wanted to check that thing where a syscall is denied (qt related)
<zyga-ubuntu> seb128: ok, I think I got one thing wrong
<zyga-ubuntu> 2.26.14 is still before the feature being enabled
<zyga-ubuntu> I must have analyzed this incorrectly before
<zyga-ubuntu> but running
<zyga-ubuntu> zyga@fyke:/run/snapd/ns$ sudo /snap/core/current/usr/lib/snapd/snap-update-ns gnome-calculator
<zyga-ubuntu> gives me
<zyga-ubuntu> cannot update snap namespace: not implemented
<zyga-ubuntu> which is before the feature went live
<zyga-ubuntu> I think the extended release cycle for 2.26 has caused me to assume it would contain things that really only are in master
<zyga-ubuntu> seb128: using 2.27.[12] shows this works
<Chipaca> pedronis: question about locking of SnapManager: should I worry about holding a lock while accessing its attributes?
<zyga-ubuntu> seb128: I updated the forum
<Chipaca> pedronis: afaict everything is holding the state's lock right now, but i don't know if that's needed or incidental
<zyga-ubuntu> gary-wzl: thanks, +1'd 3745
<zyga-ubuntu> mvo: when do we do 2.28?
<zyga-ubuntu> I'd like to release master soon with the udev tagging bug fixed
<zyga-ubuntu> as this is a major change
<zyga-ubuntu> and we may get regressions for a long time
<zyga-ubuntu> mvo: fedora hicckup again :/
<zyga-ubuntu> Error: Failed to synchronize cache for repo 'updates'
<zyga-ubuntu> ++ dnf -q -y --refresh install libtool
 * zyga-ubuntu got depressed at 13:13
<zyga-ubuntu> so meta
<zyga-ubuntu> on to reviews
<Son_Goku> zyga-ubuntu: no updates doesn't mean that it won't install
<Son_Goku> as long as fedora repodata was downloaded
<Son_Goku> but something is seriously messed up with the Linode network for that to happen so often
<zyga-ubuntu> Son_Goku: yeah, I was thinking the same thing
<zyga-ubuntu> Son_Goku: I wonder if they have a mirror
<zyga-ubuntu> I'll ssh-in and see
<Son_Goku> if Linode is an official mirror, they may have set in Fedora MirrorManager to direct all traffic from their own nodes to their own mirror
<jdstrand> mwhudson: hey/ re apparmor working> hello-world.evil (snap install hello-world) is a basic test
<Son_Goku> I've done the same for my workplace with our registered mirror
<jdstrand> mwhudson: hello-world.sh and poking around is another
<Son_Goku> this is Fedora MirrorManager, btw: https://admin.fedoraproject.org/mirrormanager/
<Son_Goku> zyga-ubuntu: for example, if there was a Fedora mirror for Canonical (private or public), you can register it with mirrormanager and indicate what IP blocks should always be directed to your mirror
<zyga-ubuntu> Son_Goku: well, I hope we don't need our own mirror :)
<zyga-ubuntu> Son_Goku: I just want the cloud bits to work
<Son_Goku> cloud never works :)
<zyga-ubuntu> Son_Goku: may be linode bug
<zyga-ubuntu> Son_Goku: may be something else, but it is too soon to tell
<Chipaca> pstolowski: i'm seeing a weird thing where retry carries on retrying things after it's gotten something
<Chipaca> pstolowski: have you seen that, or should I dig further?
<Chipaca> anyway, right now i'm off to run and lunch
<zyga-ubuntu> ... obtained time.Time = time.Time{sec:63638477897, nsec:23992430, loc:(*time.Location)(0x7d0500)} ("2017-08-16 10:58:17.02399243 +0000 UTC")
<zyga-ubuntu> ... expected time.Time = time.Time{sec:63638477897, nsec:27992384, loc:(*time.Location)(0x7d0500)} ("2017-08-16 10:58:17.027992384 +0000 UTC")
<zyga-ubuntu> mvo: did you notice this?
<zyga-ubuntu> I see it for the 2nd time today
<zyga-ubuntu> ... obtained time.Time = time.Time{sec:63638477897, nsec:23992430, loc:(*time.Location)(0x7d0500)} ("2017-08-16 10:58:17.02399243 +0000 UTC")
<zyga-ubuntu> ... obtained time.Time = time.Time{sec:63638477897, nsec:23992430, loc:(*time.Location)(0x7d0500)} ("2017-08-16 10:58:17.02399243 +0000 UTC")
<zyga-ubuntu> ... obtained time.Time = time.Time{sec:63638477897, nsec:23992430, loc:(*time.Location)(0x7d0500)} ("2017-08-16 10:58:17.02399243 +0000 UTC")
<zyga-ubuntu> FAIL: picfg_test.go:124: piCfgSuite.TestConfigurePiConfigNoChangeSet
 * zyga-ubuntu curses moronic copy-paste on linux
<zyga-ubuntu> anyway
<zyga-ubuntu> mvo: go test -check.f piCfgSuite.TestConfigurePiConfigNoChangeSet -count 1000
<zyga-ubuntu> mvo: this fails on master
<zyga-ubuntu> (reliably)
<zyga-ubuntu> and that test seems to find real bug
<zyga-ubuntu> mvo: I'll investigate
<zyga-ubuntu> mvo: yes, it's a bug
<zyga-ubuntu> mvo: around? I have a question
<zyga-ubuntu> mvo: or if you can, a call (whatever you prefer)
<zyga-ubuntu> mvo: I think the fix is trivial
<Son_Goku> mvo, so where's snapd 2.27.2?
<ogra> on vacation ...
<ogra> should come home later today though ....
<mvo> zyga-ubuntu: in a meeting right now
<mvo> Son_Goku: almost ready :)
<mvo> Son_Goku: after lunch (my lunch :)
<Son_Goku> so... in an hour or so, eh?
<pstolowski> Chipaca, no, I haven't seen this, do you have any logs?
<mvo> Son_Goku: yes
<mvo> Son_Goku: unless zyga-ubuntu comes along and finds yet another bug ;)
 * Son_Goku glares at zyga-ubuntu 
<ogra> you guys should really stop implementing all these bugs ...
<ogra> ... implement features instead :)
<pedronis> zyga-ubuntu: check.Equals and time are usually a bad idea, you need Time.Equal
<zyga-ubuntu> pedronis: thanks but that test is just broken
<zyga-ubuntu> pedronis: and we didn't notice because the comparison is flaky
<zyga-ubuntu> pedronis: the bug is in the real code
<zyga-ubuntu> (too)
<zyga-ubuntu> mvo:
<zyga-ubuntu> so, can you run zyga@fyke:~/go/src/github.com/snapcore/snapd/corecfg$ go test -count 1000
<zyga-ubuntu> not what happens
<zyga-ubuntu> -count 1000 breaks the test
<zyga-ubuntu> then I get
<zyga-ubuntu> ... error string = "cannot run snapctl: snapctl: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory"
<zyga-ubuntu> libpthread.so.0
<zyga-ubuntu> feels like another golang bug
<zyga-ubuntu> this is around exec
<zyga-ubuntu> Chipaca: ^
<zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/3746
<mup> PR snapd#3746: corecfg: handle unknown keys that are explicitly set <Created by zyga> <https://github.com/snapcore/snapd/pull/3746>
<zyga-ubuntu> I'll open a thread about the pthread bug
<zyga-ubuntu> (ha ha)
<mup> PR snapd#3746 opened: corecfg: handle unknown keys that are explicitly set <Created by zyga> <https://github.com/snapcore/snapd/pull/3746>
<zyga-ubuntu> Chipaca: https://forum.snapcraft.io/t/corecfg-tests-crash-with-weird-pthread-bug-when-invoked-with-count-1000/1712
 * zyga-ubuntu tries to reproduce that now
<zyga-ubuntu> fg
<Chipaca> zyga-ubuntu: kill $!
<Chipaca> zyga-ubuntu: i'll take a look at the pthread thing
<zyga-ubuntu> Chipaca: I'm looking too
<zyga-ubuntu> Chipaca: it's curious
<zyga-ubuntu> Chipaca: doesn't happen in a smaller test case yet
<Chipaca> zyga-ubuntu: which benchmarks were you expecting this to run btw?
<zyga-ubuntu> Chipaca: benchmarks?
<zyga-ubuntu> Chipaca: so I ran a small test case that just does systemctl --version with -count 1000
<zyga-ubuntu> and that works
<zyga-ubuntu> but the real test suite fails
<zyga-ubuntu> I added almost everything back
<zyga-ubuntu> and it still works
<Chipaca> zyga-ubuntu: i'm not seeing anything about pthreads
<Chipaca> ... error string = "cannot run snapctl: error: error running snapctl: invalid snap cookie requested"
<Chipaca> ^ that's what i'm getting
<zyga-ubuntu> yeah
<zyga-ubuntu> there's something else broken
<zyga-ubuntu> +       mockSnapctl := testutil.MockCommand(c, "snapctl", "")
<zyga-ubuntu> +       defer mockSnapctl.Restore()
<zyga-ubuntu> add this
<zyga-ubuntu> the code _may_ run snapctl if the version query goes through
<zyga-ubuntu> after adding it I see
<zyga-ubuntu> FAIL: corecfg_test.go:46: coreCfgSuite.TestConfigureErrorOnMissingCoreSupport
<zyga-ubuntu> corecfg_test.go:60:
<zyga-ubuntu>     c.Check(err, ErrorMatches, `(?m)cannot run systemctl - core-support interface seems disconnected: \[--version\] failed with exit status 1: simulate missing core-support`)
<zyga-ubuntu> ... value = nil
<zyga-ubuntu> ... regex string = "(?m)cannot run systemctl - core-support interface seems disconnected: \\[--version\\] failed with exit status 1: simulate missing core-support"
<Chipaca> also these:
<Chipaca> ... obtained time.Time = time.Time{sec:63638483255, nsec:193288244, loc:(*time.Location)(0x7d1520)} ("2017-08-16 13:27:35.193288244 +0100 BST")
<zyga-ubuntu> ... Error value is nil
<zyga-ubuntu> so, it's sitll racy and broken but
<zyga-ubuntu> Chipaca: this is fixed by
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/3746
<mup> PR snapd#3746: corecfg: handle unknown keys that are explicitly set <Created by zyga> <https://github.com/snapcore/snapd/pull/3746>
<zyga-ubuntu> so cherry pick that
<zyga-ubuntu> e9f0f9be1cc64a61607b42ebad2d483aa08d61ae
<Chipaca> zyga-ubuntu: what's this supposed to be testing, again?
<Chipaca> zyga-ubuntu: note that this thing doesn't do Exec, it does Fork
<zyga-ubuntu> Chipaca: which test case?
<zyga-ubuntu> it does os.exec/Exec
<Chipaca> zyga-ubuntu: there is no Exec in os.exec
<Chipaca> zyga-ubuntu: there's syscall.Exec, which calls clone(2) which is where the issues were
<zyga-ubuntu> ah, sorry, exec.Command
<zyga-ubuntu> +1
<Chipaca> zyga-ubuntu: and then there's os/exec's Command, which has a Start (and a Run, that calls Start), that call os.StartProcess, that call syscall.StartProcess, that calls forkExec, that does the necessary stuff
<zyga-ubuntu> https://github.com/zyga/snapd/tree/wtf/weird-bug
<zyga-ubuntu> Chipaca: inside that branch run
<zyga-ubuntu> zyga@fyke:~/go/src/github.com/snapcore/snapd/corecfg$ go test
<zyga-ubuntu> and compare that to
<zyga-ubuntu> zyga@fyke:~/go/src/github.com/snapcore/snapd/corecfg$ go test -count 1000
<zyga-ubuntu> that shows the issue
<zyga-ubuntu> AFAIK -count is not concurrent
<zyga-ubuntu> Chipaca: I updated the forum post
<Chipaca> zyga-ubuntu: ... error string = "cannot run snapctl: should never call snapctl"
<mup> PR snapd#3738 closed: debian: do not build with -buildmode=pie on i386 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3738>
<seb128> zyga-ubuntu, mvo, when are xenial users going to get 2.27?
<mvo> seb128: I just uploaded 2.27.2 to xenial-proposed. the 2.27 release had a regression for some Qt systems
<mup> PR snapd#3742 closed: interfaces: don't crash if content slot has no attributes <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3742>
<seb128> mvo, gnome-calculator segfaults on 2.27.1 btw
<seb128> and it doesn't use qt :p
<mvo> seb128: does edge also segfault?
<mvo> seb128: what do I need to do to reproduce?
<seb128> mvo, I think zyga said it should be fixed in .2 so don't waste time on it
<seb128> I can test and let you know
<mvo> seb128: I'm building 2.27.2 in the beta channel as we speak
<seb128> mvo, I'm too old school to understand you, just going to wait for the artful debs
<seb128> which is how I tested 2.27.1 :p
<mvo> seb128: *pffff* ;)
 * mvo hugs seb128
 * seb128 hugs mvo back
<mvo> seb128: artful debs are also uploaded, if you follow -proposed things should be available RSN
<seb128> mvo, I don't play with channel but I'm afraid to end up on a situation where I put myself on a beta channel for good when I just wanted to test a specific version and then go back to normal default behaviour
<seb128> good
<seb128> it's already confusing me enough that the snapd process version doesn't match the snapd deb I've installed :p
<Chipaca> zyga-ubuntu: what's the environment in which you were getting the pthread thing?
<zyga-ubuntu> re
<zyga-ubuntu> seb128, mvo: I didn't test .2
<zyga-ubuntu> Chipaca: xenial
<zyga-ubuntu> amd64
<seb128> zyga-ubuntu, you confirmed the issue in .1 and the fix in .2 then?
<zyga-ubuntu> seb128: I was focusing on the content issue
<zyga-ubuntu> seb128: and it looked unrelated
<Chipaca> zyga-ubuntu: are you reexec'ing?
<zyga-ubuntu> seb128: I can check .2
<zyga-ubuntu> Chipaca: in the test?
<Chipaca> zyga-ubuntu: yes
<ogra> seb128, try yourself ... switching to edge (and back) is so trivial and safe
<zyga-ubuntu> Chipaca: there's nothing to reexec there but I think I was
<Chipaca> zyga-ubuntu: doesn't snapctl try to reexec?
<zyga-ubuntu> seb128: and if not we'll airlift ogra to fix your machine
<seb128> ogra, is that documented somewhere?
<ogra> seb128, snap refersh --edge core ... test ... snap refresh --stable core
<ogra> there ... now it is :P
<seb128> ogra, you can't expect users to know that
<ogra> (modulo typos :P )
<seb128> so the question still stands
<Chipaca> ogra: that's in the wrong orange! let me file a bug
<Chipaca> seb128: you can't expect to tell users to try edge either
<ogra> Chipaca,  i only support peaches !
<Chipaca> edge _will_ ruin your holidays periodically
<seb128> Chipaca, well that's what I'm being asked to do because I've a snap that segfaults since the snapd update
<ogra> seb128, it is surely documented somewhere on snapcraft.io ...
<ogra> (but i use it for so long already that i dont know where)
<Chipaca> seb128: asking you to do it is not the same as expecting you to do it unprompted
<zyga-ubuntu> Chipaca: snapctl should *never* run in either case
<zyga-ubuntu> Chipaca: the code bails out earlier
<willdeberry> morning all. trying to solve a problem without being forced into a classic confinemet. I have a python bluetooth CLI tool and am getting the following when I try and run it from a snap: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Failed to connect to socket /var/run/dbus/system_bus_socket: Permission denied
<zyga-ubuntu> Chipaca: not sure if snapctl re-execs but I assume so
<seb128> anyway, not a argument I'm interested to have
<Chipaca> zyga-ubuntu: do you still get the pthread thing?
<willdeberry> I have tried the following plugs without any success: bluetooth-control, network, network-contorl, network-manager
<zyga-ubuntu> willdeberry: are they connected?
<seb128> I'm going to wait for the deb to be there to see if snapd stopped segfaulting my apps
<popey> hi willdeberry
<zyga-ubuntu> Chipaca: yes, I can show you during the call
<ogra> willdeberry, there is a dbus interface too ...
<zyga-ubuntu> let me order coffee & cake
<zyga-ubuntu> and I'll join
<willdeberry> zyga-ubuntu: i tried manually connecting them and had no change
<willdeberry> hello popey, thanks for the reply on twitter
<mvo> seb128: what do I need to do to verify the error?
<mvo> seb128: is snap install gnome-calulator enough?
<willdeberry> ogra: the docs for the dbus interface seem to point to only need if i am exposing dbus bus/methods though
<koza> willdeberry, what kind of bus your script is using? if OBEX then this is a known issue
<mvo> seb128: also, why does this comes up 1min *after* I tagged 2.27.2 :/
<mvo> seb128: (not your fault I know, just bad timing)
<willdeberry> koza: just using dbus to interact with the local bluetooth on the system
<seb128> mvo, because you don't read the forum?
<Chipaca> seb128: that's a bit harsh
<seb128> mvo, I mentioned it on https://forum.snapcraft.io/t/content-interface-connection-issues/1585 some days ago
<seb128> Chipaca, that's the reality though
<willdeberry> popey: I am still occastionally seeing the syntax error you opened an issue report on github about too. snapcraft will give me a working build and the very next will have the error again. even if nothing change in the master branch of code
<ogra> seb128, i do read the forum (like all day) and didnt know about it
<seb128> Chipaca, and I'm not even speaking about launchpad bugs
<koza> willdeberry, could you pastebin snapcraft.yaml, $ snap list <yoursnap>
<popey> willdeberry: huh, that's strange!
<seb128> ogra, well on that url ^
<seb128> "Where can I find 2.26.14? xenial-proposed only has 2.26.10.
<seb128> I tried 2.27.1 from artful-proposed but gnome-calculator abort on start with that version, that seems a different issue/a regression but it blocks me from verifying the fix."
<mvo> seb128: aha, so its not a 2.27 regression?
<mvo> seb128: oh, it is
<seb128> mvo, it is
<mvo> seb128: meh
<koza> willdeberry, i mean $ snap interfaces <yoursnap>
<ogra> seb128, if it is 2.27 specific i'D have expected a comment on https://forum.snapcraft.io/t/in-progress-snapd-2-27-1/572 where blockers are collected
<seb128> mvo, but basically
<seb128> $ snap install gnome-3-24
<seb128> $ snap install gnome-calculator
<seb128> $ snap connect gnome-calculator:gnome-3-24-platform gnome-3-24:gnome-3-24-platform
<seb128> $ snap run gnome-calculator
<seb128> mvo, that works in 2.26 and segfault in 2.27.1
<seb128> ogra, your workflow would have to be documented for people to know that
<willdeberry> koza: so had to install it on another machine to be able to test/work with yall while I am work. Reconnected all the interfaces on this new machine and noticed a slight variance in the AccessDenied message: An AppArmor policy prevents this sender from sending this message to this recipient
<seb128> ogra, or launchpad bugs to be look at
<ogra> seb128, it isnt *my workflow* (note i'm not in the snapd team ... it is simply what i grok from reading the forum as a non team member
<willdeberry> koza: https://pastebin.com/vqaxnDfe
<seb128> anyway I've no interest in arguing more
<ogra> if there is a thread about preparing a release, i dump my blockers in there ... or at least a link to the thread about my blockers ... thats more common sense than anything else
<popey> seb128:  interestingly that works in 2.27 on solus (I don't have 2.27.1 or .2 there)
<seb128> to me launchpad is the place to file bugs
<ogra> thats fine
<koza> willdeberry, try "Debugging Confined Apps" section from https://snapcraft.io/docs/build-snaps/debugging to get better understanding of how to fix it.
<ogra> just link them where the communication about the release happens ;)
<willdeberry> koza: I will go through that, ty. devmode definitely works, but honestly not surprised by that
<seb128> ogra, I don't know about that place or special workflow
<seb128> anyway enough arguing
<ogra> seb128, because you dont read the forum ?
<seb128> good afternoon to you snappy people :-)
 * ogra grins
 * seb128 goes back to do work
<seb128> ogra, indeed not, why would I? I file my bugs in launchpad, if that's the wrong place then bugfiling should be closed on the snapd component
<mvo> seb128: does not segfault for me
<mvo> seb128: with 2.27.2
<ogra> your bugs are fine in launchpad ... but if you see a blocker you consider urgent, trusting that someone sees your bug in time might not be the best way
<seb128> mvo,good then it's fixed, thanks for testing!
<seb128> ogra, well then we have an issue
<seb128> ogra, if the team wants to know about issue they should look at the bug tracker
<koza> willdeberry, don't you have bluez snap installed?
<ogra> well, if you look at the thread there are plenty of people reporting blockers ...
<ogra> sure, and that happens ...
<willdeberry> koza: no. i installed bluez via apt
<ogra> still, if you want quick attention for something you consider urgent, you obviously come to IRC to block the release ... you could as well go to the forum ...
<mvo> seb128: hopefully :)
<koza> willdeberry, also see in the logs (journalctl) what is the exact thing that you try to access that gets denied; will help in understanding what is your issue
<koza> willdeberry, oh, try snap :)
<willdeberry> i assume i should prune the system version before?
<ogra> ... this is totally independent from LP bugs
<jdstrand> mwhudson: I responded extensively in the forum (https://forum.snapcraft.io/t/snapd-vs-upstream-kernel-vs-apparmor/1704/2)
<koza> willdeberry, yes
<ikey> hm no tagged releases of snapd-xdg-open
<ogra> just use master
<ogra> i doubt it will change, given it is being replaced eventually
<ikey> so then why wouldnt it be tagged? :P
<ikey> come on basic sw dev here lol
<ogra> https://github.com/snapcore/snapd-xdg-open/blob/master/debian/changelog ...
<ogra> version is 0.0.0
<ogra> ;)
<ikey> so why am i being told to package it then?>
<ogra> ogra@styx:~$ dpkg -l |grep snapd-xdg-open
<ogra> ii  snapd-xdg-open                              0.0.0~16.04                                  amd64        Opens URLs via D-Bus
<ikey> i mean i get that snaps let you play it loose with basic software practices but for something that needs to be packaged ... and is in git ...
<ikey> should have tags and distcheck tarballs
<ikey> sorry to say it but git aint launchpad
<ogra> ikey, it is a hack that is going away and that was initially only released as source deb
<ogra> but if you want opening of links in snap to work right now, you want it installed on a desktop ...
<ikey> right so you know this limitation - thus snapd-xdg-open is currently needed, and should be tagged
<ikey> because its a runtime requirement
<ogra> (note we do not pre-install it in ubuntu either, but it is available  for users)
<ogra> (though due to apt bugs ... )
<ikey> heh
<ogra> or rather due to mis-behaviour of apt-get that is fixed in apt (without -get)
<ogra> sadly people on 16.04 still use the old apt-get typically
<Son_Goku> I'm super annoyed about snapd-xdg-open
<Son_Goku> ikey: I've been told repeatedly to *not* package it
<ogra> so speed up snapd userd
<Son_Goku> because they're going to break it real-soon-now
<ogra> we're not breaking it
<ogra> snapd will include something that replaces it eventually
<Son_Goku> morphis_: then we should just get snapd-xdg-open in asap: https://bugzilla.redhat.com/show_bug.cgi?id=1369560
<ogra> https://github.com/snapcore/snapd/pull/3260
<mup> PR snapd#3260: cmd/snap: implement userd command as replacement for snapd-xdg-open <Created by morphis> <https://github.com/snapcore/snapd/pull/3260>
<ogra> thats the PR
<Son_Goku> or you know, fuck it
<Son_Goku> I could just backport that
<willdeberry> koza: new error: https://pastebin.com/wGUb06R1, current interfaces: https://pastebin.com/scMJD25G
<popey> willdeberry: is it installed in -devmode?
<willdeberry> not currently. using latest edge
<willdeberry> popey: devmode worked right out of the box with the system based bluetooth stack
<willdeberry> i have a feeling classic would work too, but i hate jumping to that to just solve the problem until i know that is the only way
<popey> worth testing with your snap in devmode
<popey> best to test with devmode first
<ogra> the bluetooth stack in use shouldnt make any difference
<mvo> seb128: snapd 2.27.2 is now in artful-proposed
<mvo> seb128: according to LP anyway
<mup> PR snapd#3747 opened: Merge release 2.27.2 back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/3747>
<popey> mvo: will 2.27.2 be the one that goes to stable - so 16.04 users will get it at some point via core?
<zyga-ubuntu> re
<zyga-ubuntu> niemeyer: https://github.com/snapcore/snapd/pull/3621
<mup> PR snapd#3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
<zyga-ubuntu> irssi got stuck on the wifi here
<koza> willdeberry, there is no bluetooth interface connected
<mup> PR snapd#3520 closed: asserts: add store assertion type <Created by atomatt> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3520>
<oSoMoN> mvo, I've been talking to willcooke and kenvandine and it seems the agreement is to create a new "desktop team" shared account for the store for snaps officially supported by the desktop team
<oSoMoN> niemeyer wants this to be documented as a wiki doc on the forum (does that need to be owned by the wiki user btw?), let's work out the details of that shared account and create the doc then
<kenvandine> +1
<kenvandine> lets name it ubuntu-desktop
<willdeberry> koza: bjarkan (my snap) is connected to bluetooth-control interface. that's the only bluetooth interface i see
<oSoMoN> mvo, what would you need to create that shared account? can it be associated to ~canonical-desktop-team/~ubuntu-desktop ?
<ogra> oSoMoN, i think thats store territory (i doubt mvo can create it)
<ogra> iirc they created the shared canonical account too
<oSoMoN> ogra, who should I talk to?
<ogra> nessita, perhaps
<ogra> though this is likely not actually a "shared account" but simply the owner of the snaps ... actual sharing happens then via the "collaboration" setting in the sotre
<ogra> *store
<ogra> (where you simply add all the uploaders on a per-snap basis)
<koza> willdeberry, sorry I have meant "bluez" interface. You need it as bluetooth_control gives you only a control over kernel-side of BT stack and this is not what you want to use here. bluez snap will make it appear.
<ogra> koza, any idea why that isnt there ? on a classic install this should simply connect you to the deb based bluez stack
 * ogra notes he doesnt see bluez here either on his desktop 
<ogra> sounds like a bug
<oSoMoN> ok, so we still need an owner account for those snaps officially supported by the desktop team
<ogra> right
<oSoMoN> nessita, can you create such an account for us?
<ogra> and then yoou "collaborate" pre-snap with all the desktop people
<ogra> *per-snap
<koza> ogra, no idea
<koza> ogra, might be a good candidate for a bug report
<willdeberry> popey: devmode works, even without any interfaces connected
<willdeberry> koza: I even installed bluez snap package and the only interface that provides is bluez:service. I don't see :bluez listed as a slot
<koza> willdeberry, yes devmode will work obviously
<zyga-ubuntu> https://lwn.net/Articles/731121/
<zyga-ubuntu> Headline features include support for the Snap packaging format
<zyga-ubuntu> ^_^
<zyga-ubuntu> ikey: you hit lwn
<ogra> zyga-ubuntu, https://www.heise.de/newsticker/meldung/Linux-Distribution-Solus-3-bringt-Unterstuetzung-fuer-Snap-Pakete-3801856.html
<ogra> even made the german news ;)
<ikey> yeah cbmuser is ranting in the comment section
<ikey> because reddit made it clear they're sick of his crap
<ogra> (i must say thats really impressive for a one man show)
<ikey> its not a one man show
<koza> willdeberry, you on classic on core?
<nessita> oSoMoN, hi! could you summary what you need?
<willdeberry> koza: i agree, but popey wanted confirmation, so i just wanted to validate that again
<willdeberry> koza: i am on classic, 16.04
<ogra> ikey, well ... mostly ... no ?
<ikey> no
<ogra> ok :)
<kenvandine> oh, so we need to add individuals per snap, that's not ideal
<ikey> so core team is myself, JoshStrobl, datadrake (bryan), cybre (stefan), justin, sunnyflunk (peter)
<zyga-ubuntu> ogra: nice!
<ikey> community are also very much involved by way of patches too ogra https://dev.solus-project.com/differential/
<ikey> we have a very open development process
<oSoMoN> nessita, the desktop team needs a store account that will be used for snaps it officially supports
<ogra> oh, wow, i didnt know
<oSoMoN> nessita, through the collaboration feature, i.e. several people on the team will actually upload/maintain the snaps
<ogra> (about the team ... i see the dev process ... :) )
<ikey> the changelog lists a bunch of different names https://solus-project.com/2017/08/15/solus-3-released/
<ikey> and thats only gen'd for the budgie iso
<ikey> i.e. whats in the ISO, not the repos, or the gnome or mate isos
<ikey> bigger project than people think :)
<ikey> im most visible because im the first full time and the one with the biggest mouth
<ogra> heh
<nessita> oSoMoN, what username/visible name would this account have?
<nessita> oSoMoN, for example, the base shared account is "canonical", would this be "canonical-desktop" or something else?
<oSoMoN> nessita, kenvandine was suggesting ubuntu-desktop, which sounds good to me
<kenvandine> yeah
<kenvandine> ubuntu-desktop
<kenvandine> that's our usual
<popey> Hang on.
<popey> If I am installing chromium on solus, it's a desktop app surely?
<nessita> kenvandine, is the name available in LP?
 * nessita checks
<popey> Not an UBuntu Desktop app
<oSoMoN> true
<kenvandine> nessita, that already exists on LP
<ikey> It wont launch without being installed as --devmode, fwiw
<nessita> kenvandine, hum is a team so we can't use the name
<ikey> well. it launches. and locks forever
<kenvandine> bummer
<kenvandine> what we really want is a team for the store :)
<nessita> kenvandine, let me think, one sec
<koza> willdeberry, the bluez interface can be provided only by the app (the bluez snap in this case). it is not implicit on both core and classic which means you need to have the snap installed for it to appear. could you install it and list interfaces?
<nessita> kenvandine, yeah but we don't have teams in the store (this is intentional)
<kenvandine> yeah
<popey> be good not to have a name which confuses people who don't use ubuntu
<oSoMoN> popey, the idea was that owner reflects who maintains the snaps, in that case the ubuntu desktop team
<zyga-ubuntu> ikey: what doesn't work?
<oSoMoN> but I agree, it could cause confusion
<kenvandine> nessita, could the account we use collaborate with ~ubuntu-desktop in LP?
<ikey> zyga-ubuntu, chromium, was replying to popey
<kenvandine> to allow anyone in ~ubuntu-desktop to upload?
<zyga-ubuntu> ikey: aha
<nessita> kenvandine, no, there are no links to LP teams in the store
<zyga-ubuntu> ikey: any denials/seccomp things in syslog?
<kenvandine> ok
<popey> what's the rationale for it not being under the 'canonical' account?
<nessita> popey, I sort of agree with you but I think there is a forum post about this, let me check
<ikey> zyga-ubuntu, ya on the thread
<kenvandine> yeah
<kenvandine> there is
<oSoMoN> too generic I think, we want a clearer separation of what the team maintains
<popey> "we"?
<kenvandine> and we might allow community members of the ubuntu-desktop team to help
<ogra> well, so i cant install it on fedora because it comes from ubuntu-desktop ?
<nessita> oSoMoN, note that the concept of "team" does not apply in the store
<popey> thats what the collaboration feature is for, surely?
<ev> yeah, I'm also curious about why we wouldn't use 'canonical'
<ev> If Canonical is putting someone on maintaining a snap, surely they should show up as the vendor, no?
<nessita> kenvandine, do you have the forum post handy? I can't find it
<popey> Sorry to throw a spanner in the works here, it's just that a) naming things is hard, and b) I don't want us to name something that the store people are gonna have to rename later
<zyga-ubuntu> ev: I think niemeyer described this somewhere
<kenvandine> https://forum.snapcraft.io/t/which-snaps-should-be-supported-by-canonical
<willdeberry> koza: that's what this link was: https://pastebin.com/scMJD25G
<nessita> that one!
<oSoMoN> all very good points, now I'm not so sure any longer about that new account :)
<zyga-ubuntu> mvo: is a tarball up?
<mup> PR snapd#3735 closed: many tests: move all panicing fake store methods to a common place <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3735>
<zyga-ubuntu> mvo: or ... are you done with the release?
<mvo> zyga-ubuntu: tarball up, all done
<mvo> zyga-ubuntu: 2.27.2 is in beta now
<koza> willdeberry, do you have snapcraft.yamls as well?
<zyga-ubuntu> mvo: thank yu!
<willdeberry> koza: https://github.com/willdeberry/bjarkan/blob/master/snap/snapcraft.yaml
<mvo> zyga-ubuntu: thank you for all your help with it!
<nessita> kenvandine, oSoMoN the forum topic seems to be waiting for more answers from niemeyer, do you think you can continue the conversation there to reach an agreement?
<nessita> ev, popey do you agree? ^
<popey> I only see a suggestion to use Ubuntu, but no reason why?
<nessita> kenvandine, ie niemeyer is waiting from feedback from you :-)
<kenvandine> nessita, further up in the post i think there was some agreement to this and he asked for a wiki post to document our support
<ev> I got the opposite take. It sounds like Gustavo is okay with 'canonical' if and only if the "process surrounding the snap" is documented
<popey> I mean, internally it's nice to know who is responsible for a snap. But externally, users don't care, they just want the safety that Canonical are caring for these pacakges, not which team or developer, surely?
<nessita> ev, from https://forum.snapcraft.io/t/which-snaps-should-be-supported-by-canonical/1064/9 it feels like gustavo is not sure
<ev> what he seems to be rightly concerned about are snaps written by individuals inside Canonical, with no intention of providing full time support, being published under the canonical account
<kenvandine> ev, yeah, i think he basically agreed to a shared account like canonical if we documented it
<ev> nessita: I took that as "not sure about ubuntu vs canonical" for the name
<kenvandine> it just raised other ideas
<niemeyer> nessita, ev: I think you're both in agreement..
<nessita> ev, yeah me too
<ev> ha!
<nessita> :-)
<ev> hi Gustavo
<kenvandine> hey niemeyer!
<niemeyer> Heya :)
<nessita> kenvandine, I don't think the proposal is " a shared account like canonical", but "the canonical shared account", which is different :-)
<koza> willdeberry, as a reference check the "bluetoothctl" app from bluez snap which basically does exactly the same thing as the script you want to snap. https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/bluez/tree/snapcraft.yaml#n18
<kenvandine> i think the benefit of using ubuntu is we could give access to community members of the desktop team
<kenvandine> to some snaps, perhaps
<kenvandine> and it wouldn't feel wrong
<kenvandine> for example we have community members in ~ubuntu-desktop for LP, so similar concept
<niemeyer> All we need is that place describing what was mentioned in the forum message.. this can be a message in the forum even, which makes it visible and nice to maintain and comment on
<nessita> kenvandine, but is gedit from ubuntu supposed to be installable in fedora (as a snap)?
<kenvandine> the desktop team would be committed to maintenance, but we do have non-canonical members of the desktop team
<kenvandine> nessita, that's another whole thread :)
<oSoMoN> niemeyer, how do we make a forum post easily editable by several contributors (wiki-style)?
<popey> kenvandine: The store supports collaborators on snaps. You could invite individuals to help that way?
<koza> willdeberry, there is also not yet stable snap that packages a script which uses bluez interface. you can check it out too https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/bluez-tests/tree/snapcraft.yaml
<kenvandine> popey, yup
<nessita> kenvandine, my point being that if gedit (or whichever snap) is meant to be used in other distros, then having publisher ubuntu is not accurate I think
<niemeyer> oSoMoN: A moderator just needs to make it so.. I can easily do it once the post is up
<kenvandine> nessita, right
<kenvandine> maybe desktop?
<nessita> the publisher should be canonical
<nessita> kenvandine, the publisher is a vendor, an entity
<oSoMoN> niemeyer, ack, so Iâll start that post and we can iterate on it
<nessita> an insitution
<ev> yeah, I agree with nessita
<kenvandine> ok
<niemeyer> oSoMoN: Sounds great, just let me know when you want it "wikied" :)
<kenvandine> ev, nessita: that's a sound point
<niemeyer> oSoMoN: I also have a special user in the forum which I change the ownership to in some cases.. might make sense here to make it show up nicely.. see for instance: ...
<kenvandine> can we get someone on the desktop team with publishing permissions for canonical?  So we don't have to funnel everything through mvo?
<niemeyer> oSoMoN: https://forum.snapcraft.io/t/configuration-in-snaps/510
<ev> kenvandine: you can get added as collaborators on those snaps, once set up
<nessita> kenvandine, every initial setup for a new snap has to go thru mvo, once that's done, he can add collaborators and the collaborators can push and released independently of mvo
<oSoMoN> niemeyer, yes I had spotted that special "wiki" user, but I wasn't sure how it worked
<oSoMoN> no vacation for mvo, ever
<kenvandine> ev, nessita: yeah, that's what my concern was
<kenvandine> we're going to be adding quite a few snaps
<ogra> oSoMoN, the collaborators can also add other collaborators
<ogra> (at least if mvo allowed that)
<kenvandine> but the initial setup is limited to just mvo
<ogra> so it is only the initial setup you need him for
<niemeyer> oSoMoN: It's two independent things.. the wiki user is just a normal user I made up to make some collaborative posts more obvious
<nessita> kenvandine, yeah, right now there is no workaround for that
<kenvandine> ok
<ogra> kenvandine, well, i guess you dont add new packages on aa per-day basis :)
<ogra> -a
<kenvandine> i guess we can continue to upload new snaps as individuals then ask mvo to change owner?
<niemeyer> oSoMoN: The actual wiki functionality may be enabled for any top-level post, no matter who's the author
<nessita> kenvandine, so maybe create an initial revision for all the snaps and have him upload that, even if it's an empty snap (using plugin nil or something) -- of course never release such revisions
<kenvandine> ogra, close to right now
<kenvandine> we're trying to snap all of our desktop apps
<nessita> kenvandine, changing owner is something I do, so please email me for that
<ogra> sure, but only until you have your set in ...
<kenvandine> ogra, right
<ogra> you wont do it regulary after you have submitted your set of apps
<kenvandine> it'll be busy for a little while then tail off
<ogra> and mvo had vacation this year already ... so all is good :P
<nessita> lol
<kenvandine> but actually i like the idea of getting them in the store as individuals and then changing publisher
<kenvandine> at least we can get moving on testing, etc
<kenvandine> lol
<popey> it doesn't look so good from outside
<popey> snap install foo
<kenvandine> yeah
<popey> "installing foo from random developer I have never heard of"
<kenvandine> but we'll have some people of time in edge so we can get slightly broader testing
<ogra> nessita, hmm, if there are collaborators already and you change the owner, do the collaborators persist ? that would take mvo completely out
<kenvandine> i can then like once a week or so email a list to nessita to change
<ogra> they could just set that up in advance
<popey> how many are we talking about? can we not prep a list and just get them all registered en-masse via mvo in one hit?
<kenvandine> ah, that would be interesting
<popey> rather than drip feed
<kenvandine> can he do that in advance?
<kenvandine> we can put together the list
<nessita> ogra, yes, they persist (for now, until we migrate to new snap-developer assertions)
<kenvandine> assuming he can add the collaborators before the snap is uploaded
<ogra> nessita, then kenvandine should just register them, add someone else from the team as collaborator and you switch the owner ...
<nessita> popey, the thing is they also need an initial build for upload, is not enough to register the name
<popey> you can use the same yaml with one line changed to make the snaps
<ogra> then it is just between you two
<popey> for the first non-published rev, to do the collaboration part
<nessita> correct
<popey> snapcraft init, then replace my-snap-name with your app name, snapcraft, done :)
<popey> (20 times) :D
<ogra> write a ruby script :)
<ogra> (because ruby is modern :P )
<kenvandine> and they won't be installable right?
<popey> pffft, ruby is old school, it's all rust now baby
<kenvandine> sigh... ruby
<popey> kenvandine: not if not published
<ogra> rusty then :P
<popey> you can upload them and never publish
<kenvandine> so i can create a pile of empty snaps and send them to mvo
<popey> ya
<kenvandine> and for the ones we already have we can just email nessita a list
<popey> to re-home them? yes
<kenvandine> cool
<nessita> kenvandine, correct
<kenvandine> we should add our collaborators to the current ones first then :)
<popey> so you need a list of collaborators, list of snaps, and a pile of snap files.
<kenvandine> ok
<oSoMoN> niemeyer, kenvandine: here we go with a very rough draft, contributions welcome! https://forum.snapcraft.io/t/snaps-officially-supported-by-canonical/1719
<niemeyer> oSoMoN: Thanks! LGTM.. let me know I should make it a wiki and transfer ownership to the wiki user as well
<oSoMoN> niemeyer, please do, so that kenvandine and others can edit
<morphis_> oSoMoN: btw. there is a discussion ongoing what "officially supported" means in terms of Ubuntu / Canonical
<pedronis> niemeyer: in repair, if Runner.SaveState returns an  error but we also run it more frequently, should we report those errors  immediately over other errors, or just log them and continue/report the other errors?
<morphis_> oSoMoN: slangasek is the main contact here
<oSoMoN> morphis_, ha thatâs particularly relevant here
<morphis_> yeah
<kenvandine> it is
<morphis_> seb128 and willcooke are involved as well
 * zyga-ubuntu goes home
<zyga-ubuntu> ttyl
<Chipaca> zyga-ubuntu: i'm this >< close to giving up on this thing
<oSoMoN> great, so no need for us to be involved, thereâs enough of the team taking part already
<zyga-ubuntu> Chipaca: on the -count bug?
<Chipaca> yes
<morphis_> oSoMoN:  but good that his gets documented as we have a policy for quite some time what it means to publish certain snaps under "canonical" for our commercial offerings
<zyga-ubuntu> Chipaca: I'll have a fresh look tomorrow
<Chipaca> zyga-ubuntu: my best guess so far is that the lookup in path is not done in the same thread as the setenv
<niemeyer> oSoMoN: Changed it slightly.. I guess you'll get notifications there from now on
<oSoMoN> niemeyer, thanks
<niemeyer> pedronis: Good question.. hmm
<niemeyer> pedronis: I think not saving the state is not such a hard failure is it?
<pedronis> no
<niemeyer> In the sense that the repairs should be idempotent
<mup> PR snapd#3745 closed: interfaces: convert uhid to common interface and test cases improvement for time_control and opengl <Created by adglkh> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3745>
<pedronis> so we could just log
<niemeyer> pedronis: Yeah, I think we can log and let other errors take priority.. if there are no other errors, then we report the save state failure
<pedronis> our real problems will be more if we fail to write the bits needed to log/run the repair themselves
<niemeyer> Yeah
<niemeyer> pedronis: Let's please document these ideas in the code itself so we remember them later
<kenvandine> oSoMoN, although it was willcooke that told us to use ubuntu desktop team :)
<oSoMoN> yes, the rationale made sense, but the conclusions of this discussion make even more sense I think
<oSoMoN> nothing is set in stone so we can continue discussing this, the ownership of snaps in the store can easily be transferred apparently
<oSoMoN> the argument that those snaps are not ubuntu-specific is particularly important (although they will obviously get more testing on ubuntu)
<ogra> today perhaps :)
<popey> Actually, you mind find the opposite is true :)
<ogra> if you post your "please test..." stuff to the forum you usually get testing from all sides
<ogra> and that will rise
<davidcalle> ikey: ping
<ikey> davidcalle, pong
<oSoMoN> ogra, popey: right, I meant more testing on ubuntu from me, really
<popey> hehehe
<ogra> heh
<davidcalle> ikey: hey, I'm adding solus support to the snap doc, about the table at the bottom of https://snapcraft.io/docs/core/install, what can you tell me? How is snapd in solus in sync with releases, what are the supported features? (eg. do you support confined snaps or devmode only, do you support classic)
<ikey> support all modes, and intend to sync snapd on the same day (where feasible) into solus repos
<ikey> full confinement has some quirks we're still working out (like chromium)
<ikey> but the solus kernel uses the same apparmor as the ubuntu kernel
<davidcalle> Alright, that's great :)
<ikey> we're on 2.27 atm though because of the initial integration process
<ikey> getting the various bits of support in
<ikey> on the next solus repo sync all existing users will receive snapd upon update too
<davidcalle> Ok
<ogra> and then just enable re-exec ynd you dont have to care anymore ;)
<ikey> sure i will
<ikey> it'll reexec the ubuntu core snapd, not the solus one, right?
<ogra> it re-execs into the core snap
<ogra> so you get whatever is in there
<ikey> and snapd is patched for solus support
<ogra> oh
<ikey> whereas the core one would operate like an ubuntu one, no?
<ogra> yeah, that would not work i guess
<ogra> :(
<ikey> unless we could carry across the "im still a solus" flag to the internal snapd
<ikey> so it still does solus like things
<ikey> (when all patches are merged/finished)
<ogra> <trump voice>so sad</trump voice>
<ikey> lol
<ikey> there were fine snaps on both sides..
<ikey> >_>
<ogra> lol
<om26er> Hi! apart from experimenting and deploying snaps, whats the best way to contribute to the snappy ecosystem ?
<davidcalle> morphis_: speaking of the snapd support table on https://snapcraft.io/docs/core/install, I think we should drop the "version" col and just keep the "status" one in sync, can you help with the update?
 * ikey is thinking version syncing the doc is gonna be a pain.. :p
<morphis_> davidcalle: not really, filled with a lot of other things
<popey> om26er: https://forum.snapcraft.io/t/join-snapcrafters/1325  :D
<popey> ^ that would be awesome
<ikey> popey, apparently the Zoom people have shown interest in Snap
<ikey> popey, https://dev.solus-project.com/T6
<popey> Yay!
<ikey> specifically the comment from mcritchlow
<popey> (what's zoom?)
<ikey> XD
<ikey> https://zoom.us/
<ikey> video conferencing thinger
<popey> oooh
<ikey> closed source
<ogra> neat !
<ikey> but they have a linux tarball...
<ikey> so.. snappable
<popey> We can help here!
<palasso> Ohh here's all the snappy hippies hiding! btw just watched last LUP
<popey> hi palasso
<ikey> important bit:
<ikey> " I've messaged Zoom requesting that they package the app up as a snap. I really think it would make their lives much easier, and ours as end users. Couldn't hurt for others to bother them as well if you agree. The response I got was positive, and they've added it to their feature request list."
<palasso> hey!!!
 * ogra hands palasso a space cookie 
<ogra> peace dude !
<ogra> :)
 * ikey only got handed patches and bugs, quite jealous
<ikey> lol
<popey> ikey: we can reach out to them if you like?
 * ogra hands one to ikey too
<ikey> ta xD
<davidcalle> morphis_: ok, nevermind, I'll leave it for later
<popey> kk
<ikey> popey, i think thats likely the best strategy
 * popey adds to the to-do lane
<ikey> yknow, what with y'all being official n all
<popey> ya
<popey> XD
<ikey> and me being some hippy at the helm..
<ikey> hey i like that title
 * ikey uses it now
<popey> make it your linkedin profile or it doesn't count
<ikey> totally doing it now
<morphis_> davidcalle: thanks
<popey> bet that will email all your contacts and tell them too :)
<ikey> popey, https://www.linkedin.com/in/ikeydoherty/
<ikey> XD
<popey> haha, excellent
 * ikey changes it everywhere now
<om26er> popey: aha, cool. Thanks for the link. So the snaps with publisher "snapcrafters" are the one' that this team maintains ?
<ikey> popey, lol https://twitter.com/ehawk61/status/897833943885647874
<popey> om26er: yeah, exactly
<popey> :D
<ikey> davidcalle, oh and if you could just put solus above arch in the supported list with an emoji indicating "lol" that'd be great
<ikey> >_>
<ikey> <_<
 * ikey is mostly kidding
<pstolowski> niemeyer, can you take another look at https://github.com/snapcore/snapd/pull/3569 ? I think I addressed all your comments and the branch is rotting a little bit ;)
<mup> PR snapd#3569: snapd, snapctl: use json Decoder instead of Unmarshall <Created by stolowski> <https://github.com/snapcore/snapd/pull/3569>
<davidcalle> Well, in alphabetical order, so you'll still be above Ubuntu ;-)
 * Chipaca creates a spinoff called aaaabuntu
 * ikey changes names to Alpha Centauri Solus just to game the list
<davidcalle> ikey: you should have picked Abuntu instead of Solus
<davidcalle> Ahahaha
<ikey> good job the "buntu" suffixes stopped though really
<ikey> we had a very real risk of Bubuntu existing
<ikey> and thats just an unforgivable name
 * Chipaca is still toying with the idea of creating uubuntu
<davidcalle> Nothing beats the quirkyness of Google's Goobuntu
<ikey> yubuntu
<ikey> with that unity work
<ikey> *fork
<ikey> words.
<Chipaca> and then clearly, yabuntu
<Chipaca> mvo: might Christian Ehrhardt's comment about pie be related to our recent woes?
<willdeberry> koza: so updated to use uhid plug before resorting to swapping out bluez classic for snap. I am at least getting apparmor denials. Is there a snap way to add policies or would that have to be done manually outside the snap? https://pastebin.com/Df4qSxG6
<davidcalle> ikey: https://github.com/CanonicalLtd/snappy-docs/pull/92 works for you?
<mup> PR CanonicalLtd/snappy-docs#92: Add Solus install instructions <Created by caldav> <https://github.com/CanonicalLtd/snappy-docs/pull/92>
<ikey> davidcalle, looks legit
<ikey> idk if its worth mentioning solus 3 has it preinstalled or not
<davidcalle> Oh, I wasn't aware of that, yes, it should
<Chipaca> pedronis: did you see my question about SnapManager attributes and locking?
<pedronis> Chipaca: where?
<Chipaca> before the standup i think
<davidcalle> ikey: so, your user base is on Solus 2, progressively migrating to 3 which has it installed by default?
<Chipaca> let me search :-)
<ikey> davidcalle, Uhm little more complicated than that, Solus 2017.04.18.0 was the last release prior to this Solus 3 ...
<ikey> We changed versioning schemes
<davidcalle> Heh :D
<ikey> But all new Solus 3 ISOs have snapd included by default
<davidcalle> ikey: and Solus 3 is the default image to download?
<ikey> right
<ikey> as of yesterday
<davidcalle> Congrats!
<Chipaca> 2017-08-16 12:04:18 <Chipaca>	pedronis: question about locking of SnapManager: should I worry about holding a lock while accessing its attributes?
<Chipaca> 2017-08-16 12:05:05 <Chipaca>	pedronis: afaict everything is holding the state's lock right now, but i don't know if that's needed or incidental
<ikey> ty :D
<davidcalle> Alright, let me reword the PR
<pedronis> Chipaca: no, I missed it
<Chipaca> pedronis: no worries, i've been on detours until just now
<pedronis> Chipaca: there's no lock in managers usually
<pedronis> they just use the state lock
<pedronis> but maybe you have something particular in mind
<Chipaca> pedronis: so they need to use the state lock?
<Chipaca> i noticed that they sorta-kinda did, but it's not enforced and i wondered if it was just happenstance
<pedronis> Chipaca: any particular example?
<Chipaca> pedronis: SnapManager's nextRefresh
<Chipaca> pedronis: basicallly, the real question is
<pedronis> it's a bit of borderline that thing
<Chipaca> pedronis: given that i need to release the state lock before calling to the store
<pedronis> well NextRefresh is
<davidcalle> ikey: let's try again https://github.com/CanonicalLtd/snappy-docs/pull/92/files
<mup> PR CanonicalLtd/snappy-docs#92: Add Solus install instructions <Created by caldav> <https://github.com/CanonicalLtd/snappy-docs/pull/92>
<Chipaca> pedronis: if i wanted to update that _after_ calling the store, and had no other reason to grab the lock again, i still need to grab the lock again
<pedronis> Chipaca: yes, but that guy and his friend should probably say in their docs that you need to hold the state lock
<pedronis> which they don't
<pedronis> afaict
<ikey> davidcalle, perfick
<pedronis> Chipaca: they don't have docs at all, which is also bad
<Chipaca> pedronis: well, ensureRefreshes is the thing that actually accesses them
<pedronis> Chipaca: no, they are used in api as well
<Chipaca> ah
<pedronis> if it was only ensure
<pedronis> they wouldn't need to be exported
<pedronis> I think tests do too
<pedronis> but those could use export_test.go
<Chipaca> pedronis: ah, i thought it was just for the tests
<davidcalle> Saviq: deployed https://developer.ubuntu.com/core/examples/snaps-on-mir
<ogra> \o/
<Chipaca> (cross-package tests would need it in the main thing)
<ogra> that took a while :)
<pedronis> Chipaca: as I said probably time to give them some docs
<pedronis> Chipaca: anyway they are used in api.go sysInfo (with the lock)
<Chipaca> pedronis: a'ight, so bottom line is, grab the state lock before accessing the manager's attrs
<davidcalle> ogra: speaking of, you may want to wheigh in on the Raspip3 comment at the top of the doc
<davidcalle> Raspi3*
<davidcalle> ikey: there will be probably a design review on the logo addition to the front page, so it will only go live tomorrow
<ikey> ah yeah sure no rush :D
<ikey> not everyday someone tells you to stick a boat on your website anyway
<davidcalle> Hah
<ogra> davidcalle, hmm, where is the source for that ?
<davidcalle> ogra: https://github.com/canonical-websites/developer.ubuntu.com/blob/master/templates/pages/core/examples/snaps-on-mir.md
<ogra> ah, i was looking at CanonicalLDT
<ogra> **LTD
<ogra> (why is that separate ?)
<davidcalle> ogra: all websites are now under canonical-websites
<davidcalle> ogra: not sure about the rationale
<ogra> and  https://github.com/CanonicalLtd/snappy-docs isnt a web site ?
<davidcalle> ogra: sorry, the connection is breaking up :)
<ogra> LOL
<Chipaca> pedronis: added docs with // The caller should be holding the state lock.
<ogra> davidcalle, https://github.com/canonical-websites/developer.ubuntu.com/pull/309
<zyga-suse> ikey: hey, did you rebase on 2.27.2?
<davidcalle> ogra: ty!
<ikey> zyga-suse, didnt see the new vendor tarball
<willdeberry> is there a way to handle apparmor policies for snaps within the snap itself so I can interact with bluetooth/dbus properly?
<zyga-suse> ikey: should be .2 just as the last one
<zyga-suse> willdeberry: no, because that would totally disable all security sanity
<zyga-suse> willdeberry: as any malicious snap would just say "I want anything"
<Pharaoh_Atem> mvo: it seems your script for generating %changelog entries for the dates are doing the wrong days of the week
<Pharaoh_Atem> mvo: your entries for 2.27.1 and 2.27.2 have the wrong days of the week
<tpatel> I'm having issue with snap-v2.26.14 where on reboot, conect-socket-interface is connected but getting ECONNREFUSED error on socket connections. It was working on 2.26.9 version.
<tpatel> I'm having issue with snap-v2.26.14 where on reboot, content-socket-interface is connected but getting ECONNREFUSED error on socket connections. It was working on 2.26.9 version.
<pedronis> niemeyer: something like this: https://github.com/snapcore/snapd/pull/3560/commits/d5c5d933060ec32467c35fb0182a5a2702b9f87a ?
<mup> PR snapd#3560: cmd/snap-repair: implement most logic to get the next repair to run/retry in a brand sequence <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3560>
 * ogra wonders what "content-socket-interface" would be 
 * ikey punches multipath-tools with a spanner
<ikey> developed a full blown allergy to non-stateless software..
<Saviq> davidcalle: thanks!
<__chip__> huh, my computer just randomly shut down
<ogra> thats probably a subtle hint ...
<__chip__> crappy dell acting like it's old just because i've had it since i joined canonical
<__chip__> actually not even that, a year after joining i got it
<niemeyer> pedronis: Yeah, but I think it can be simplified slightly
<niemeyer> pedronis: Note that the three errors checked for above are the three errors checked for below
<niemeyer> pedronis: I think it can be something like err1 = makeRepair; err2 = SaveState; if err1 != nil && err1 != skip { return err1 }; if err2 != nil { return err2 }
<Pharaoh_Atem> mvo, niemeyer: snapd 2.27.2 updates have been proposed for Fedora 25 and Fedora 26
<Pharaoh_Atem> and it's also now built in Rawhide
<pedronis> mvo: did you see this: https://forum.snapcraft.io/t/failure-to-upgrade-to-2-27-1-and-2-27-2-with-lxd-installed/1713/2
<niemeyer> Pharaoh_Atem: Sweet!
<niemeyer> Pharaoh_Atem: Thank you
<Pharaoh_Atem> now I just wish people would test it so it doesn't sit in the queue for a week :(
<Pharaoh_Atem> https://forum.snapcraft.io/t/in-progress-snapd-2-27-2/572/42?u=conan_kudo
<oSoMoN> nessita, so following up our conversation earlier today, could you please transfer ownership of the chromium snap from my personal account to the shared canonical account?
<nessita> oSoMoN, yes, would you please send me an email with cc Bret Barker and mvo? (we try to keep an informal log of transfer requests)
<oSoMoN> sure, doing that now
<mvo> Chipaca: what posting from Christian Ehrhardt is that? do you have a url (sorry, was out and juts catching up)
<oSoMoN> nessita, you have mail
<nacc> mvo: ubuntu-devel
<nacc> mvo: https://lists.ubuntu.com/archives/ubuntu-devel/2017-August/039946.html3
<Chipaca> mvo: ubuntu-devel, https://lists.ubuntu.com/archives/ubuntu-devel/2017-August/039946.html
<nacc> err, s/3$//
<Chipaca> bingo :-)
<nacc> what Chipaca said :0
<mvo> Pharaoh_Atem: meh, I need to tweak my script :/ thanks for noticing
<nacc> christian did all the heavy lifting to debug it, related bug is LP: #1711092
<mup> Bug #1711092: gcc-7 toolchain triggers bug in build system causing non snmp drivers failing to be linked <nut (Ubuntu):New> <https://launchpad.net/bugs/1711092>
<mvo> Pharaoh_Atem: thanks for pushing the update to fedora.
<mvo> pedronis: checking the lxd issue now
<mvo> nacc, Chipaca: thanks a bunch
<mvo> Chipaca: I think mwhudson might be interessed in https://lists.ubuntu.com/archives/ubuntu-devel/2017-August/039946.html and if it might be the reason why -buildmode=pie in snapd is failing
<Chipaca> mvo: agreed
<Chipaca> ok, i've pushed my PR, I'm off
<mup> PR snapd#3748 opened: many: fetch & cache remote snaps and sections; complete from there <Created by chipaca> <https://github.com/snapcore/snapd/pull/3748>
<mvo> Chipaca: see you!
<Chipaca> see you all on here, Wednesday next week :-D
<mvo> Chipaca: enjoy !
<Chipaca> (I might reply to review comments ... with photos of me at the beach)
 * Chipaca isn't going to the beach
<Chipaca> o/
<pedronis> niemeyer:  https://github.com/snapcore/snapd/pull/3560/commits/011f4441d3198030f7b8a5473e0fa0435a5a5842 and added some tests
<mup> PR snapd#3560: cmd/snap-repair: implement most logic to get the next repair to run/retry in a brand sequence <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3560>
<niemeyer> pedronis: LGTM!
<jdstrand> willdeberry: can you either file a bug or post to the forum with what you are trying to do wrt dbus/bluetooth with a reproducer?
<pedronis> niemeyer: thanks, I think addressed all the feedback there
<pedronis> *I think IÂ addressed
<willdeberry> jdstrand: i sure can
<willdeberry> i will take care of that after work
<niemeyer> pedronis: please feel free to merge once you're happy about it.. there were not blockers on that one
<pedronis> mmh
<pedronis> seems master is broken
<niemeyer> :(
<pedronis> I think some test on matt branch isn't passing anymore with some change on master
<pedronis> IÂ mean the store assertion PR
<pedronis> found the issue
<pedronis> it's an interaction between one of my recent PRs and his, uncovering test code that was always a bit fragile
<mup> PR snapd#3749 opened: asserts/assertstest: fix master <Created by pedronis> <https://github.com/snapcore/snapd/pull/3749>
<mvo> pedronis: thanks for fixing msater
<mvo> master
<ikey> i think the chromium snap broke my host side GL ..
<ikey> couldnt launch steam and got libGL errors
<ikey> eh i think apparmor is breaking solus a lot.
<ikey> /bin/sh: /home/ufee1dead/.local/share/Steam/steamapps/common/ARK/ShooterGame/Binaries/Linux/ShooterGame: Text file busy
<pedronis> mvo: a new kind of fedora failure:  /var/tmp/rpm-tmp.QSCKfG: line 15: python: command not found
<pedronis> Warning: file /etc/mock/fedora-25-.cfg does not exists.
<pedronis>          unable to update /etc/mock/default.cfg
<mvo> pedronis: uff
<mvo> pedronis: that does not ring any bells :/
<pedronis> mvo: well, I'm tempted to put fedora to manual or something
<pedronis> I don't even know how to do that though
<cachio_> mvo, weird results for i386 : https://paste.ubuntu.com/25327320/
<cachio_> mvo, the rest seem to be ok
<mvo> pedronis: yeah, I think that is ok
<pedronis> mvo: trying that
<pedronis> mvo: seems manual should work also with systems
<mvo> cachio_: the errors look like its an older snapd in the image
<mvo> cachio_: can you ssh into it and see what "snap version" shows?
<mvo> pedronis: cool
<cachio_> mvo, yes
<cachio_> mvo, mmm, it is hte 2.26.14
<mvo> cachio_: what is the output of snap list?
<cachio_> mvo, I executed from 2.27.2
<mvo> cachio_: uh, strange
<cachio_> https://paste.ubuntu.com/25327614/
<pedronis> mvo: I did this:  https://github.com/snapcore/snapd/pull/3749/commits/8f640461859d56702cc8c7fe4e5fe1b63a92a9e5
<mvo> cachio_: I guess any traces *why* this has happend will be erased by the testsuite now ?
<mup> PR snapd#3749: asserts/assertstest: fix master <Created by pedronis> <https://github.com/snapcore/snapd/pull/3749>
<mvo> cachio_: maybe snap list --all ?
<mvo> cachio_: or snap changes has some info?
<mvo> pedronis: heh, nice
<pedronis> well, not nice, but I want to make master green again
<mvo> pedronis: yeah, we can easily re-enable it
<mvo> pedronis: and have a PR that validates the fixes then etc
<cachio_> mvo, I don't see nothing weird
<cachio_> https://paste.ubuntu.com/25327631/
<cachio_> mvo, I'll make the whole process again
<mvo> cachio_: thanks
<mvo> cachio_: can you pastebin the entire syslog
<mvo> cachio_: before you wipe the system please?
<mvo> cachio_: I wonder if we find clues in there
<jdstrand> ikey: re apparmor> the kernel patches or the policy? I would be quite surprised the policy would break GL on the system. the kernel could be missing some important patches I guess. I think it more likely that the mount namespace for the snap is propagating to the host
<ikey> jdstrand, i ran snap run chromium, it hard locked, ctrl+c'd it, ran steam, couldnt initialise GL
<ikey> not until i rebooted
<ikey> (and chromium is still pooched)
<ikey> yet cybre can run it without issue on solus
<ikey> v odd
<jdstrand> that could be gl errors. I know I sometimes get weird lockups with chrome
<ikey> should point out im using chrome host side
<jdstrand> did you have anything in the dmesg?
<ikey> nope
<ikey> and if i strace it the process exits
<ikey> because you have to be root to strace it
<ikey> and then sandbox throws a hissy fit
<ikey> (and gotta be root because setuid binaries)
<jdstrand> you need to run strace special
 * jdstrand gets link
<cachio_> mvo https://paste.ubuntu.com/25327666/
<jdstrand> also, if you ran it as root, it is possible ~/snap/chromium or a subdir is root-owned and could cause an issue
<jdstrand> ikey: https://forum.snapcraft.io/t/stracing-snap-commands/1433
<ikey> yeah i ran it as root *after* the failure
<ikey> to strace it
<cachio_> mvo, tell me if you need anything else
<jdstrand> ikey: you might run find to see if the perms are correct
<ikey> im not sure if you're getting what im saying jdstrand :p
<ikey> it was buggy from the getgo
<jdstrand> or just rm -rf ~/snap/chromium and start over
<ikey> it was locking, so i straced with root after
<jdstrand> I do get that
<ikey> i didnt start it initially as root
 * jdstrand understands
 * ikey blitz aforementioned dir
<ikey> nope
<jdstrand> I'm saying having run it as root might've messed things up differently so further debugging would be different
<pedronis> mvo:Â I want to land a couple of things and then I can propose one that undoes that
<pedronis> and we'll see if it's a fluke or something is broken more permanently
<ikey> i see audit calls but no denials
<jdstrand> anyway, if the dir is gone, you can stracec using the technique in the above forum post
<ikey> Aug 16 20:49:06 ironhide SGI_video_sync[13187]: <audit-1326> auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=13187 comm="SGI_video_sync" exe="/snap/chromium/1/usr/lib/chromium-browser/chromium-browser"
<ikey> etc
<jdstrand> I strongly suspect the mount namespace isn't being setup right if this is affecting the rest of the system
<jdstrand> that said, I tried in a vm with not a lot of ram and the kernel starting killing off a bunch of random stuff
<jdstrand> you would've seen something in dmesg though if it was that
<jdstrand> or a video driver issue
<jdstrand> (strongly based on what you said, not any personal observation)
<ikey> ya
<ikey> and now hastebin is dead -_-
<ikey> k so this is the tail 100 https://pastebin.com/sSwme915
<ikey> when I ctrl+c it: https://pastebin.com/LiPPVRar
<ikey> interestingly i dont get that output when im not stracing it
<jdstrand> ikey: I think you need oSoMoN to help at this point, unless you're still convinced about the gl issues and mount namespace, then perhaps zyga
<ikey> no im more interested atm in the black-screen-of-death-locks-forever bit
<ikey> do it tomorrow anyway, too late her now :p
<ikey> *here
<ikey> -_-
<jdstrand> ikey: re black screen of death. my theory had something to do with the host being affected by the chromium snap's mount namesapce. that shouldn't be terrible to verify. reboot, sha256sum (or similar) the contents of that dir from the host, launch chromium, then sha256sum the contents of that directory again from the host
<jdstrand> ikey: I'm not familiar with solus' setup of that dir, but my understanding is there is a tmpfs and some symlinks? just make sure the host isn't actually changed. then you could 'snap run --shell chromium' and see if the mount namespace ha all the gl stuff the snap should have
<jdstrand> then report in the forum and perhaps oSoMoN or zyga or someone else can help
<cachio_> mvo, I am running again and I see similar issue
<mvo> cachio_: what do I need to do to reproduce?
<niemeyer> cprov: Just finished recording the whiteboard session on epochs.. now just needs assembling..
<mvo> cachio_: just make a core from beta?
<niemeyer> Should have something later today or tomorrow
<cachio_> I created the beta image
<cachio_> with validator project
<mvo> cachio_: what is validator project?
<niemeyer> Going outside for a while now.. o/
<cachio_> https://github.com/fgimenez/validator.git
<cachio_> mvo,
<cachio_> mvo, then run ./create.sh beta pc-i386
<cachio_> mvo, this will get you the image
<cachio_> mvo, you need to install ubuntu-image snap
<cachio_> mvo, then
<cprov> niemeyer: cool! Looking forward to watch it. Thanks for working on that.
<cachio_> kvm -snapshot -smp 2 -m 1500 -redir tcp:8022::22 -nographic -serial mon:stdio <path_to_the_img>
<cachio_> mvo, export SPREAD_EXTERNAL_ADDRESS=localhost:8022
<cachio_> . ./tests/lib/external/prepare-ssh.sh localhost 8022
<cachio_> spread -v external:ubuntu-core-16-32
<mup> PR snapd#3749 closed: asserts/assertstest: fix master <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3749>
<mvo> cachio_: checking
<cachio_> mvo,  inthe meantime I am running the other stuff
<cachio_> the problem is that I go so slow with the pi2 and 3
<cachio_> I need new cards
<pedronis> mvo: merged, master should get back to green
<mvo> cachio_: working on it
<mvo> pedronis: thanks a bunch
<mvo> cachio_: thinks are "funny". core r2800 is indeed 2.26.14 but that is not what got uploaded, something is wrong with lp->store
<cachio_> mvo, mmm, ok
<cachio_> mvo, should I cancel the execution?
<mvo> cachio_: please give it another go, looks like a number mismatch
<mvo> cachio_: yes
<mvo> cachio_: cancel please but now you can create a new image, the right rev is now in the right place
<cachio_> mvo, ok
<mvo> cachio_: it was me messing up, sorry for that :(
<cachio_> mvo, I'll run again with the new image in that case
<cachio_> mvo, np
<mvo> cachio_: thank you
<mvo> cachio_: keep me updated, I call it a day :)
<cachio_> mvo, sure, tx
<mup> PR snapd#3750 opened:  snapstate: undo a daemon restart on classic if needed  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3750>
<tyhicks> jdstrand: I'm no longer sure when snapd is (re)generating the seccomp BPF filters
<tyhicks> jdstrand: is it possible for the BPF filter to be generated under one kernel and then the binary BPF filter loaded into a different kernel (after a reboot)
<tyhicks> (trying to think through libseccomp API design decisions)
<tyhicks> snap-confine.rst covers how the .bin files are generated but not when they're generated
<pedronis> do we have a fix for  piCfgSuite.TestConfigurePiConfigNoChangeSet yet ?
<pedronis> is it this: snapd#3746 ?
<mup> PR snapd#3746: corecfg: handle unknown keys that are explicitly set <Created by zyga> <https://github.com/snapcore/snapd/pull/3746>
<pedronis> I'm not familiar with that code
<mwhudson> jdstrand: thanks
<willdeberry> jdstrand: just poking you since you recommeneded, https://forum.snapcraft.io/t/accessdenied-when-running-my-packaged-snap-app/1724 . Hopefully this helps with reproducability for others.
<mup> PR snapd#3751 opened: interfaces/many: updates based on chromium and mrrescue denials <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3751>
<mwhudson> jdstrand: still here?
<jdstrand> mwhudson: I am just about to leave, but feel free to asking
<jdstrand> ask*
<mwhudson> jdstrand: i replied in the forum, if you have 2s to read and quickly reply that'd be great but it can wait till tomorrow too :)
<jdstrand> mwhudson: responded. heading out. I'll keep an eye on the forum and backscroll. have a nice rest of the day :)
<mwhudson> jdstrand: thanks, you too
 * mwhudson afk for a bit
<willdeberry> so aside from the plug issues I am having with bluetooh which is being addressed via the forums, I am occasionally running into the following error on random builds when no code is changing: /snap/bjarkan/50/usr/bin/python3: 1: /snap/bjarkan/50/usr/bin/python3: Syntax error: word unexpected (expecting ")")
#snappy 2017-08-17
<mup> Bug #1711249 opened: Why? <Snappy:New> <https://launchpad.net/bugs/1711249>
<PhoenixMage> Any snapcraft devs online?
#snappy 2017-08-19
<jdstrand> kyrofa: it is up to date enough. there is a pending rc10 with a few language changes, but the technical content is up to date
<jdstrand> davidcalle: ping re security whitepaper> there are some small pending changes that aren't reflected here: https://developer.ubuntu.com/core/documentation
<ogra_> jdstrand, https://dashboard.snapcraft.io/dev/snaps/5596/rev/22/ i guess the check tools need to learn about the new spi interface ...
<jdstrand> ogra_: if you request a manual review, I'll approve it
<ogra_> one sec
<ogra_> done
<mup> PR snapcraft#1496 opened: docs: fix typo in plugin help <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1496>
<mup> Bug #1711847 opened: "snap run" doesn't support not installed packages <snapd:New> <Snappy:New> <snapd (Ubuntu):Invalid> <https://launchpad.net/bugs/1711847>
<mup> PR snapd#3770 opened: Tests fix refresh2 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3770>
<mup> PR snapd#3771 opened: Tests fix refresh3 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3771>
<fireclawTheFox> Hi everyone, I'm quite new to snappy/snapcraft and am trying to develop a custom plugin. Now I'm having a problem and wanted to ask whether there is a way to get more debugging output or logging other than with snapcraft -d.
<fireclawTheFox> The error I get is "'dict' object is not callable" and I have no idea where it comes from.
<mup> PR snapcraft#1496 closed: docs: fix typo in plugin help <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1496>
<mup> PR snapcraft#1497 opened: ci: release snap to a branch for every PR <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1497>
#snappy 2017-08-20
<bub_> ryouma: ~10 years
<mup> PR snapd#3768 closed: tests: adding debug information for refresh-all tests <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3768>
<mup> PR snapd#3770 closed: Tests fix refresh2 <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3770>
<mup> PR snapd#3771 closed: Tests fix refresh3 <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3771>
<mup> PR snapd#3772 opened: tests: wait until the port is listening after start the fake store <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3772>
<brrr> hey guys, i downloaded the brave browser snap which should be running sandboxed, but it isn't how. how do i sandbox it? do i edit the yaml file?
<syntist> Hi
<syntist> i want to know, snap discord compared to flatpak talking so much space!! nearly 500 mb
<syntist> even more than windows
<mup> PR snapd#3639 closed: update to version of golang.org/x/crypto currently in Debian unstable <Created by mwhudson> <Closed by mwhudson> <https://github.com/snapcore/snapd/pull/3639>
#snappy 2018-08-13
<mborzecki> morning
<mborzecki> mvo: hi
<mvo> good morning mborzecki
<mvo> mborzecki: how are you? anything important that I missed in the morning so far :) ?
<mborzecki> mvo: no, not really, some forum posts but nothing super interesting either
<mvo> mborzecki: yeah, just looking over things, looks all pretty tame so far
<zyga> Good morning. I woke up but please give me some time to come to senses and prepare for work.
<mvo> zyga: good morning
<mvo> zyga: no fires, take your time
<mborzecki> zyga: hey
<zyga> Had my coffee, did some basic unpacking of work stuff, just taking Bit for a short walk to buy bread.
<zyga> I was home at around 11PM last night
<mborzecki> zyga: take a day off
<zyga> I plan to swap on Friday but I really want to write some reports before I forget
<zyga> I also want to share what I know with everyone
<pstolowski> Morning!
<mborzecki> pstolowski: hey
<zyga> ok
<zyga> I think I'm "back"
<zyga> now I have a huge pile of papers to go through
<zyga> from the last two events
<zyga> then email reporting and email catch-up
<zyga> lastly some reviews I'd like to do
<zyga> mvo: hey, any news from gustavo?
<zyga> is the standup going to move to an earlier slot?
<mvo> zyga: I have not heard from him yet
<zyga> good morning Chipaca
<Chipaca> zyga: greetings. You bring coffee?
<zyga> Chipaca: now I feel uncomfortable because yes I do bring coffee, but I have no way to share
<mvo> hey Chipaca ! good morning
<niemeyer> Goooooood morning!
<zyga> Chipaca: I'll bring you some next time we meet in person
<zyga> niemeyer: wooot :)
<mvo> hey niemeyer, welcome back!
<Chipaca> zyga: :-)
<zyga> niemeyer: hey, welcome, how was the hop across the pond?
<Chipaca> niemeyer: welcome back!
<niemeyer> Thanks! Very happy to be back
<Chipaca> and now to get some coffee
<zyga> niemeyer: do you plan to move the standup to an actual early morning stand up time? :-)
<niemeyer> zyga: That'd be quite nice, but it also means we'd lose Sergio
<zyga> indeed, that's not great :/
<mborzecki> we can move sergio
<zyga> mborzecki: haha :D
<zyga> we should ask him first though :)
<pedronis> morning
<mborzecki> pedronis: hey
<mborzecki> pstolowski: left some comments in https://github.com/snapcore/snapd/pull/5632
<pstolowski> mborzecki: thanks, looking
<niemeyer> pedronis: Morning!
<Chipaca> mvo, pedronis, mborzecki, good morning to you too
 * Chipaca now has coffee and all is well
<mborzecki> niemeyer: Chipaca: hey
<niemeyer> Yo
<pedronis> niemeyer: welcome back
<Chipaca> Given how chipper niemeyer is I can only assume he hasn't looked at his email yet (or he looked, selected all, and deleted)
<zyga> hahaha
<zyga> Chipaca: I have the same feeling
<zyga> looking at my inbox now
<zyga> hey pedronis, good morning :)
<pedronis> mvo: Chipaca: IÂ see some PRs asking my review or that seems I should review, how urgent are they?
<Chipaca> pedronis: if  it's tagged 2.35, it's urgent
<Chipaca> pedronis: if it isn't, probably not
<pedronis> Chipaca: mvo: can they wait the afternoon though or not?
 * Chipaca defers to mvo on that
<pedronis> they are all marked 2.35
<pedronis> ;)
<Chipaca> pedronis: dangit
<pedronis> Chipaca: proxy reg is the large one
<Chipaca> dangitÂ²
<mvo> pedronis: good morning, nice to have you back
<mvo> pedronis: its not super urgent we have a bit of time for 2.35 in beta
<mvo> pedronis: definitely can wait for the afternoon or tomorrow
<pedronis> ok, thank you, sounds reasonable
<Chipaca> mvo: these should all be squash-merges at this point, right?
<pedronis> I see there's a bunch of PR for 2.35
<pedronis> I mean, the ones waiting for me are not the only ones
<mvo> pedronis: yeah, some need some high level input from niemeyer like 5340 and 5569, i.e. if the names and high level operations are ok
<mvo> pedronis: the other ones are just work afaict
<niemeyer> Ack
<mvo> niemeyer: also not super urgent (just slightly urgent), I'm assuming you have tons of backlog from all directions
<niemeyer> mvo: Yeah, it's been one of the most disconnected holidays I've had, so it's all a swamp now :)
<pstolowski> niemeyer: hey o/ :)
<pstolowski> mborzecki: replied, let me know if it makes sense
<pstolowski> (re review comment)
<niemeyer> pstolowski: o/
<Chipaca> pedronis: #5617 really starts with #5613 fwiw (but the latter landed already)
<Chipaca> niemeyer: I can move the morning thing fwiw (even to the afternoon)
<niemeyer> Chipaca: Which morning thing?
<Chipaca> niemeyer: I saw you moving the standup around, and I've got an hour of my morning blocked off, but it's flexible
<pedronis> Chipaca: I see
<pedronis> I'll skim that too
<niemeyer> Chipaca: Ah, thanks
<niemeyer> Chipaca: I'm actually just trying to put our standup back into the usual time.. and having a hard time at it :)
<pedronis> Chipaca: I saw in the log you mentioned the autocontext,  I suppose you find out that is not needed in the managers,  it's mostly a thin wrapper for store around other helpers
<Chipaca> niemeyer: hehe. It's there now :-)
<Chipaca> pedronis: yeah, i chased it down until it disappeared :-)
<niemeyer> I couldn't manage to get our old event to recur properly.. but I did manage to preserve our hangout by just copy & pasting the link into the location field
<ogra> grrrr !!!
<ogra> so the current images auto-refresh core in the middle of running console-conf
<ogra> i thought we had a mechanism to prevent that
<ogra> also ... snapd hangs on shutdown after an auto-refresh (1:30 timeout) is that known ?
<niemeyer> ogra: We still have a mechanism to prevent that.. the mechanism is time-based, though
<niemeyer> If it stays up for too long (2h?) it will attempt to refresh
<ogra> well, it doesnt seem to use a very long timeout atm ... it happened a few mins after booting the VM
<ogra> (initial boot that is)
<niemeyer> ogra: it certainly not in the few minutes range
<niemeyer> So something else is going on there
<ogra> right, thats what i thought ...
<ogra> (this is an older edge image from the 7th, might be an edge-only thing)
 * ogra re-tries with the same image from scratch ... lets see if i can reproduce
<ogra> yep
<mvo> ogra: that is edge? stable?
<ogra> reboots after about 2min
<ogra> mvo, edge
<mvo> ogra: uc16/amd64? i.e.. I just need to create an image and wait to reproduce?
<ogra> mvo, see the other channel
<mvo> ogra: thank you. to test on an stock image, will uc16/amd64 be okay? just to see if its already failing in the base images
<mvo> ?
 * Chipaca hugs kyrofa 
 * niemeyer hugs Chipaca and kyrofa with no context and shares the love
<Chipaca> niemeyer: I -1'ed a PR of his
<Chipaca> with a WAT
<Chipaca> but he's still awesome
<niemeyer> Damn.. I've mistaken a potential fight for love
<ogra> love is full of fights, aint it ?
<Chipaca> niemeyer: my hug was to emphasize that my criticism was with his work, not with himself
<Chipaca> which is easy to forget
<pedronis> Chipaca: is command-chain supposed to support arguments at all ?
<niemeyer> Chipaca: Ah, I thought maybe you were hugging him as a matter of self-protection
<Chipaca> pedronis: well, in that implementation it does
<niemeyer> ;P
<Chipaca> niemeyer: I'm not scared of him, for two reasons
<pedronis> Chipaca: brokenly, though?
<Chipaca> niemeyer: one, he's on the other side of the world
<Chipaca> niemeyer: two, I can run longer
<pedronis> heh
<niemeyer> pedronis, Chipaca: No, it shouldn't support arguments.. at least until we understand why
<Chipaca> pedronis: if it's meant to replace a wrapper shell command, then it needs to be able to have spaces and stuff in it
<pedronis> niemeyer: that was my understanding as well
<pedronis> seems there is confusion around that though
<niemeyer> The idea is to have the command able to be called as "foo bar baz actual-command -its -args"
<niemeyer> If there are arguments, then we'll start to worry about ordering issues and whatnot
<pedronis> maybe is just a matter of missing validation
<pedronis> Chipaca I suppose knows more, he looked at the PR
<Chipaca> heh
<Chipaca> wait, if that _is_ what's wanted maybe the pr is ok
<Chipaca> it does exec 'chain1 chain2 chain3 actualcmd arg arg arg' (except chainN can have args but let's ignore that bit for now)
<Chipaca> given the feature is presented as a way to avoid having a wrapper, I thought this was not what was intended
<Chipaca> IOW I thought what was wanted was 'chain1; chain2; actualcmd arg arg arg'
<pedronis> no, the former
<Chipaca> because, you can _already_ have chain1 chain2 chain3 in cmd
<pedronis> but no args
<pedronis> Chipaca: yes, but then no --shell
<pedronis> etc
<Chipaca> can you give me an example of what chains are, then?
<Chipaca> I did read the forum post but it wasn't illuminating
<pedronis> Chipaca: first class (as in demarcated) wrappers
<pedronis> ?
<pedronis> niemeyer can probably say more
<niemeyer> Chipaca: Sure, sorry for the lack of context
<niemeyer> Chipaca: The idea is enabling wrappers to be dropped as they exist today
<niemeyer> Chipaca: snapcraft today has to inject some logic via its plugins
<niemeyer> Chipaca: The result is we get the messy shell script where "command" is just a line at the end of it
<Chipaca> niemeyer: so the wrappers would still exist, they'd just be modified to take args like sudo & etc?
<niemeyer> Chipaca: Instead, we want each plugin to generate its own content in its own script, and at the end call the rest of the chain
<niemeyer> Chipaca: This enables the script to generate its environment, and have the rest of the chain within it
<niemeyer> Chipaca: That also means it may be composed, seeing what's before and after it as a blackbox
<niemeyer> Chipaca: and means we can have /bin/bash as the command and get the shell inside the tip, or after any of the commands really (we haven't designed UI for that latter part)
<niemeyer> Chipaca: Right, they'd exist but be more isolated than they are today
<niemeyer> Chipaca: Adding a wrapper just means adding the command to the end of the chain
<niemeyer> This also makes templates work more easily
<Chipaca> niemeyer: ok
<Chipaca> niemeyer: I still fear tab completion might be too brittle to support this
<Chipaca> niemeyer: but I'll leave it to implementers to figure out :-)
<niemeyer> Chipaca: Not sure why?
<niemeyer> Chipaca: I mean, the end result is effectively the same
<niemeyer> Chipaca: I mean, today wrapped commands are already called inside a shell script, in a chain
<Chipaca> niemeyer: right, but the completer wasn't wrapped
<Chipaca> bah, as long as it all ends in an exec of what used to be exec'ed it'll be fine
<niemeyer> Chipaca: Right, that's what I imagined
<niemeyer> Chipaca: Or at least hoped.. :)
<Chipaca> niemeyer: :-)
<Son_Goku> niemeyer, mvo, JamieBennett, popey: so I'm back home from Flock
<Son_Goku> I can honestly say that the talk was a great success
<Son_Goku> people were really interested (some difficult questions about store stuff aside)
<Son_Goku> and there's definitely interest in plugging in snap delivery into the Fedora pipeline
<mvo> pstolowski: can we cherry-pick https://github.com/pilebones/go-udev/pull/14 into our tree without making later merges harder ? I'm not super familar with git subtree
<popey> Son_Goku: excellent, great to hear! Was it filmed?
<Son_Goku> yes, but probably poorly
<popey> hah
<Son_Goku> at least audio might be okay, but the hotel wanted to rip off the organizers on the A/V equipment, so last minute purchase of equipment happened
<Son_Goku> so you can guess it was kind of rickety
<Son_Goku> :/
<pstolowski> mvo: it should be fine, i did something similiar already (had local changes and later merged upstream, it just works out conflicts -if any- as you would expect from git, e.g. there'll be no conflicts unless you really touch same area)
<pstolowski> mvo: can we just sync with upstream again whe your fix lands? there shouldn't be many changes, if any
<mvo> pstolowski: yeah, no changes afaict, so that should be fine. I will propsoe the same pr against master now
<pstolowski> mvo: ok. either way is fine
<mvo> pstolowski: I did both now, pushed to upstream and also created one for us so we should be covered either way (ie. if upstream is slow)
<pstolowski> mvo: great, ty! was it causing failures?
<mvo> pstolowski: yes, build failure on powrpc
<pstolowski> mvo: hmm, curious why didn't it fail when it landed earlier?
<mvo> pstolowski: it probably did and it was lost in the noise
<pstolowski> i see
<pstolowski> ok, thanks for the fix!
<mvo> pstolowski: but maybe not, might be worth investigating
<mvo> pstolowski: do you remember when this landed? a while ago, right?
<pstolowski> mvo: yes, at least 4-5 weeks ago
<mvo> pstolowski: yeah, it looks like its failing since Jul 17 wich matches (roughly) the merge of go-udev stuff
<pstolowski> mvo: and it's autopackage tests right?
<mvo> pstolowski: yeah
<pstolowski> mvo: right.. that's why it went under the radar
<mvo> pstolowski: yeah, no biggie
<mvo> pstolowski: but those small arches are always extra work
<ogra> Son_Goku, a clever person would just have set up a mobile phone in each room to record videos ;)
<Son_Goku> you don't know how close you are to how the video was recorded
<ogra> :D
<Chipaca> ogra: dashcams are really cheap right now
 * niemeyer steps out for lunch
<ogra> Chipaca, +1
<Chipaca> jdstrand: did you get a chance to look at the hostnamectl denials?
<mborzecki> yay, so after the updates to s-c and default apparmor profiles, the basic remapping/file-access tests is passing on ubuntu too
<pedronis> mvo:  I reviewed #5611
<pedronis> we lost mup?
<mborzecki> pedronis: yes, it's been silent for the last 2+ weeks
<popey> Did mup go on holiday with niemeyer :)
<mvo> pedronis: thank you! looking
<mborzecki> pstolowski: pushed an update to https://github.com/snapcore/snapd/pull/5614
<pstolowski> mborzecki: thanks, will check in a moment
<pstolowski> +1
<mborzecki> pstolowski: thanks
<niemeyer> He broke down last Tuesday, apparently..
<niemeyer> mup: You okay now?
<niemeyer> mup: no?
<niemeyer> mup: echo foo
<niemeyer> mup: How about now?
<zyga> oh
<zyga> standup!
<niemeyer> Hmm.. I can't login
<niemeyer> Is it just me?
<Chipaca> niemeyer: we're all here
<Chipaca> niemeyer: we
<pedronis> Chipaca: I reviewed a bit #5617
<Chipaca> pedronis: thanks
<Chipaca> sparkiegeek: could you reply to pedronis' first comment on https://github.com/snapcore/snapd/pull/5617 ? (I could, but it'd be more authoritative from you)
<niemeyer> mup: ping
<pedronis> Chipaca: I checked myself and it seems to be true but not sure it was ever tested
<Chipaca> pedronis: i think it has unit tests, but i'm not sure that's what you mean :-)
<pedronis> Chipaca: I mean the proxying of registration
<pedronis> in the proxy
<Chipaca> pedronis: yes, that's what i mean
<Chipaca> pedronis: it didn't support custom serial vaults, but did support forwarding to the generic one
<Chipaca> pedronis: and i think there are unit tests to that effect
<mborzecki> pedronis: when you're done with higih priority stuff, I could use your one last look at https://github.com/snapcore/snapd/pull/5561 Chipaca and pstolowski went through it but as we know those changes may be a bit tricky
<mborzecki> btw. 15th is a public holiday here (cc zyga pstolowski)
<pstolowski> right, forgot about that
<pstolowski> cachio: hey, you did some work around journalctl cursor in the spread test right
<pstolowski> ?
<cachio> yes
<cachio> pstolowski, I implemented that in the tests
<cachio> why?
<pstolowski> cachio: good, so the problem i have is this - this is journalctl output I see when my test fails: https://paste.ubuntu.com/p/XH4ps65yQ3/
<pstolowski> cachio: note the " New test starts here " message
<pstolowski> cachio: this is when the test thinks cursor starts
<cachio> pstolowski, yes
<pstolowski> cachio: so get_journalctl_log doesn't return the early snapd start messages (and i need to match those)
<cachio> pstolowski, is there any problem there?
<pstolowski> cachio: i wonder if that is intended or not; we seem to be preparing snapd after journcal curstor initialization, so it's not clear why it's like this
<cachio> pstolowski, yes, it is intended
<cachio> pstolowski, if we move the cursor initialization back, then we get a lot of messages from the previous test
<cachio> pstolowski, and it was causing other issues
<pstolowski> hmm allright
<cachio> pstolowski, could you restart snapd as part of the test?
<cachio> and check this initialization?
<pstolowski> cachio: yes, that's what i was considering
<pstolowski> just wanted to make sure it's intended
<cachio> we are already doing that in one test
<pstolowski> cachio: thanks
<cachio> pstolowski, yaw
<niemeyer> mup: You ok now?
<cachio> pstolowski, check catalog-update teswt
<cachio> pstolowski, I think this a similar test
<niemeyer> mup: echo ok
<mup> niemeyer: ok
<niemeyer> Yep.. nickserv registration issues, related to the spam measures recently adopted
<niemeyer> popey: ^
<popey> \o/
<pedronis> mborzecki: yes, will look at parallel installs after I have unblocked other things
<mborzecki> pedronis: thanks
<popey> niemeyer: what's the plan to prevent snap (your QA systems?) from flooding https://errors.ubuntu.com/ ?
<mborzecki> popey: afaik snapd QA is not reporting errors back to errors.ubuntu.com
<niemeyer> popey: On a call
<niemeyer> popey: Will ping a moment
<niemeyer> in a
<cachio> zyga, hey
<cachio> I ran the fedora base test on core
<zyga> yes?
<cachio> and it is failing
<cachio> https://paste.ubuntu.com/p/cGs978ZWqy/
<zyga> yes, it's expected until master hits edge but let me look at the failure
<cachio> it is trying to get the snap.yaml from an incorrect path
<zyga> yeah, that's exactly that
<zyga> which version of snapd was that?
<cachio> beta core
<cachio> I am suing 2.34
<cachio> I am suing 2.35
<zyga> I will check if this is in master and in edge
<niemeyer> popey: To make sure we're on the same page, what's the exact issue there?  Do we have any open bugs or forum topics?
<cachio> zyga, if it has been addresses it is ok
<zyga> cachio: fetching now, I'll let you know in a moment
<mup> PR snapd#5638 opened: interfaces: basic spread test for udev monitor <Created by stolowski> <https://github.com/snapcore/snapd/pull/5638>
<zyga> cachio: but the same test I used passed when the branch was merged
<zyga> cachio: so I believe it is fixed now, just out of sync in that channel
<zyga> cachio: (we added a spread test for it)
<cachio> zyga, well, this spread test is failing
<cachio> Error executing external:ubuntu-core-16-64:tests/main/fedora-base-smoke
<zyga> cachio: it _passed_ when it was merged into master so either the external target is older than master (which is IMO likely) or something broke since
<zyga> one sec, almost done here
<popey> niemeyer: we discussed in one of the sprints months back. Basically errors.ubuntu.com seems to have a flood of crash reports from snap. They're coming from kvm based installs. I think m_vo and c_hipaca looked into it, and suggested it was from your build / testing systems
<popey> niemeyer: having the site flooded with snap crashes makes it less useful / usable.
<zyga> cachio: reproduced in edge, so I suspect edge is just out of date
<zyga> cachio: I will re-check with master
<niemeyer> popey: I recall a related conversation back then, and I recall we actually landed changes to reduce how much we logged
<niemeyer> popey: It'd be nice to have a proper forum topic so we can have more details about the problem and so people can follow through
<popey> niemeyer: I will start a new thread
<niemeyer> popey: Thank you
<kyrofa> Chipaca, I haven't looked at the review yet, but indeed, that chain args are intended (see the forum proposal as well as the enshrining spread test)
<cachio> zyga, are yoiu planning to upload the fedora snapd for arm and other architectures?
<cachio> zyga, it is failing on arm64
<cachio> zyga, or should I push the PR to skip it?
<zyga> skip it please
<zyga> it's hard to cross-build today
<zyga> it will auto build later when it's done inside the fedora infra
<cachio> zyga, sure, tx
<zyga> thank you
<Chipaca> kyrofa: psh, don't come here with your "facts"
<kyrofa> Chipaca, heh. Find to get rid of them, but they're 1) easy to support, 2) requested by someone, and 3) have no clear downside
<kyrofa> Fine*
<kyrofa> I suspect this is simply an "easier to add functionality than remove it" argument, which is of course reasonable
<Chipaca> kyrofa: you mean arguments in the chain?
<Chipaca> kyrofa: yeah
<kyrofa> Indeed
<mup> PR snapd#5639 opened: snapcraft: set version information for the snapd snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/5639>
<Chipaca> kyrofa: I hope the review ended up making sense though
<kyrofa> Chipaca, indeed. Does the functionality make sense, now?
<mvo> kyrofa: silly question, when is the snapcraft version script run? after the build by any chance?
<kyrofa> Chipaca, there are so many snaps out there where `snap run --shell` doesn't represent anything close to the real environment because of all these wrappers
<pedronis> mvo: +1 for #5611 with a nitpick
<mup> PR #5611: devicestate: only run device-hook when fully seeded <Created by mvo5> <https://github.com/snapcore/snapd/pull/5611>
<mvo> pedronis: thank you, checking
<kyrofa> mvo, during the prime step
<mvo> kyrofa: cool, thanks
<pedronis> Chipaca: added a question to #5617, IÂ think the answer is no, but making sure
<mup> PR #5617: overlord/devicestate: DTRT w/a snap proxy to reach a serial vault <Created by chipaca> <https://github.com/snapcore/snapd/pull/5617>
<mup> PR snapd#5640 opened: tests: skip unsupported architectures for fedora-base-smoke test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5640>
<pedronis> mvo: looked at #5631 as well, couple of comment/questions
<mup> PR #5631: snapstate: ensure normal snaps wait for the "snapd" snap on refresh <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5631>
<mup> PR core18#63 opened: [RFC] snapcraft.yaml: add current date to core18 rev <Created by mvo5> <https://github.com/snapcore/core18/pull/63>
<mvo> pedronis: thanks for your comments on 5583 too!
<pstolowski> mvo: since you reviewed some of my udev stuff last week, would you find a moment for https://github.com/snapcore/snapd/pull/5618 or https://github.com/snapcore/snapd/pull/5632 ?
<mup> PR #5618: overlord: instantiate UDevMonitor <Created by stolowski> <https://github.com/snapcore/snapd/pull/5618>
<mup> PR #5632: overlord: integrate device enumeration with udev monitor <Created by stolowski> <https://github.com/snapcore/snapd/pull/5632>
<cachio_> Chipaca, https://paste.ubuntu.com/p/FJVhj5H2H7/ see those permissions
<cachio_> I saw you changed install-sideload to check this
<cachio_> but in core it is failing
<sergiusens> mvo you should switch to snapcraftctl set-version $(whatever) (last section of https://snapdocs.labix.org/extracting-information-from-sources-in-snapcraft-parts/4642)
<Chipaca> cachio_: how are those files getting there?
<mup> PR snapcraft#2209 closed: tests: add spread suite for tar-content plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2209>
<cachio_> Chipaca, which ones??
<cachio_> all of them?
<cachio_> I think those are downloaded during test executions
<ogra> sergiusens, but set-version only works from an override or am i wrong ?
<ogra> (i use it all the time btw, it is awesome ... but if you dont have overrides it is kind of forcing adding one on you)
<sergiusens> ogra: so? snapcraftctl <step> makes what you would otherwise override actually run
<kyrofa> cachio_, spread from master can't seem to run with snapd's spread.yaml: preserve-size is an invalid size string?
<kyrofa> Know anything about that?
<cachio_> kyrofa, you need to update spread
<kyrofa> cachio_, I did
<cachio_> mmm
<cachio_> did you download a spread again?
<kyrofa> I ran `go get`
<cachio_> curl -s -O https://niemeyer.s3.amazonaws.com/spread-amd64.tar.gz && tar xzvf spread-amd64.tar.gz
<cachio_> try that
<niemeyer> kyrofa: zyga mentioned that yesterday.. I need to update, sorry
<kyrofa> Isn't that this? https://github.com/snapcore/spread/pull/66
<mup> PR spread#66: Define storage at system level <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/66>
<kyrofa> The one in aws contains stuff that hasn't been merged?
<niemeyer> kyrofa: Sorry, I thought you were talking about the snap
<niemeyer> kyrofa: I have no local changes
<cachio_> niemeyer, I pushed this last week https://github.com/snapcore/spread/pull/66
<mup> PR spread#66: Define storage at system level <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/66>
<cachio_> niemeyer, could you take a look when you have a time?
<niemeyer> Yeah, but that's not kyrofa's point I assume
<niemeyer> If it's not merged it can't be used by snapd's spread.yaml
<niemeyer> and the tarball from S3 can't help either
<kyrofa> Chipaca, https://github.com/snapcore/snapd/pull/5569 has been updated
<mup> PR #5569: snap,snap-exec: support command-chain for app <Created by kyrofa> <https://github.com/snapcore/snapd/pull/5569>
<kyrofa> niemeyer, cachio_ false alarm, I just don't know how to use go apparently :)
<kyrofa> niemeyer, yeah, I don't use the snap as I use lxc
<Chipaca> kyrofa: dude
<Chipaca> kyrofa: that's so much nicer, as a diff
<Chipaca> kyrofa: +1'ed with a long-winded comment :-)
<kyrofa> Chipaca, oh darn, good catch on the env, yes, we need that
<kyrofa> Which means I'm missing a test, too
<kyrofa> Wait, no, I'm being silly
<kyrofa> I'll respond on the PR
 * cachio_ afk
<zyga> is Graham on IRC?
<sergiusens> zyga: I can ask him
<zyga> sergiusens: I'm just curious, I never thought about his IRC handle
<pedronis> zyga: he is on holiday this week and the next afaik
<zyga> ah, I see
<zyga> thanks
<sergiusens> zyga: should be seen as degville
<jdstrand> Chipaca: which hostnamectl issue are you referring to?
<jdstrand> Chipaca: and hi!
<zyga> jdstrand: hey :)
<jdstrand> hey zyga :)
<mup> PR snapcraft#2191 closed: Improve pr template and tools ignored files <Created by touilleMan> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2191>
<mup> PR snapd#5641 opened: interfaces: miscellaneous policy updates <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5641>
<mup> PR snapd#5642 opened: interfaces: miscellaneous policy updates - 2.35 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5642>
<tomreyn> hi. i'm wondering how to tell apart snap packages (and developers) to trust and those not to trust. surely oyu can't decide this for me, but i notice a lot of packages are submitted by a developer named 'Snapcrafters', and wonder whether you can tell me more about this (generic sounding) developer.
 * kyrofa points tomreyn to popey
 * tomreyn throws spinach towards popey
<popey> I am afk
<popey> But. Look on GitHub for snapcrafters
<popey> It's a repo full of snaps, that are maintained by canonical and the wider community
<tomreyn> thanks
<mup> PR snapd#5569 closed: snap,snap-exec: support command-chain for app <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/5569>
<mup> PR snapd#5643 opened: interfaces/builtin: addtl network-manager resolved DBus fix <Created by tonyespy> <https://github.com/snapcore/snapd/pull/5643>
<Chipaca> jdstrand: hi!
<mup> PR snapd#5644 opened: interfaces: add audio-playback/audio-record and make pulseaudio manually connect <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5644>
<jdstrand> eexit
<mup> PR snapcraft#2211 closed: tests: add spread suite for ament plugin <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2211>
#snappy 2018-08-14
<mup> PR snapcraft#2212 closed: tests: add spread suite for ruby plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2212>
<mup> PR snapcraft#2213 opened: Revert "ci: disable osx tests until a new pyyaml is released" <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2213>
<mup> PR snapd#5645 opened: tests: new test for udisks2 interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5645>
<mup> PR snapd#5341 closed: cmd/libsnap-confine-private: intoduce helpers for validating snap instance name and instance key <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5341>
<mborzecki> morning
<mup> PR snapd#5646 opened: cmd/snap-confine: extend security tag validation to cover instance names <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5646>
<mborzecki> mvo: hey
<mvo> mborzecki: hey hey
<mborzecki> mvo: simple review for you #5646 :)
<mup> PR #5646: cmd/snap-confine: extend security tag validation to cover instance names <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5646>
<mvo> mborzecki: on it
<mborzecki> mvo: thanks
<mvo> mborzecki: funny, we allow a regexp here - is this run without privs?
<mborzecki> mvo: iirc it's run after the initial snap name validation, but with privs
<mborzecki> mvo: no, it's without privs at this point
<mvo> mborzecki: aha, ok
<mvo> mborzecki: makes sense
<mborzecki> mvo: heh, only gid is dropped, uid is still 0
<mvo> hm, hm
<ChaiTRex> Is there a way to create a snap that installs in jailmode by default (without needing "snap install --jailmode name")?
<mvo> mborzecki: I wonder if we can merge the shellcheck PR with just a single review. this time around it looks very straightforward.
<mborzecki> mvo: yeah, i suppose we can
<mvo> mborzecki: we are over 50 again
<mvo> mborzecki: thanks! can't wait for the next part of the shellcheck saga
<mvo> mborzecki: how many are left? i.e. how many more to come?
<mup> PR snapd#5630 closed: tests: shellchecks part 6 <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5630>
<mborzecki> mvo: 126 files to go
<mborzecki> mvo: i can put more in the next batch, say 30?
<mvo> mborzecki: sounds good
<mup> PR snapd#5629 closed: debian: add tzdata to build-dep to ensure snapd builds correctly <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5629>
<zyga> good morning!
<zyga> I will be with you all shortly, just need to take the dog out for a moment
<mborzecki> zyga: hey, great report
<mborzecki> mvo: next batch coming up in a minute, looks uncontroversial too
<zyga> Thank you
<mvo> mborzecki: good stuff
<mvo> zyga: yeah, enjoyed reading it
<mvo> zyga: even though I'm fully done yet :/
<mup> PR snapd#5647 opened: tests: shellchecks part 7 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5647>
<zyga> Did he hook fragment in the mail made you read the rest?
<mvo> running our tests on armhf in cosmic is incredible slow, I wonder what is going on there, jsut the compile takes forever (not even finished yet)
<mborzecki> zyga: heh, that runtimes part indeed sounds complicated, but coming from yocto background, building an sdk and giving people a stable rootfs to use is something i did more than once :)
<mborzecki> zyga: actually the odd thing is that it's for the same arch, normally i did that for other arches, you'd build an sdk for some crazy ass arm/mips target, hand the sdk + runtime to people to work with
<zyga> mborzecki: yeah, the distribution should be the sdk because that what developers are familiar with
<mvo> review for 5641 should be an easy win
<mup> PR snapd#5641 closed: interfaces: miscellaneous policy updates <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5641>
<mup> PR snapd#5642 closed: interfaces: miscellaneous policy updates - 2.35 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5642>
<pstolowski> zyga: just finished reading your report, great read and good job indeed!
<zyga> thank you :)
<mvo> fun, it looks like 69692a broke the armhf(!) tests, the hookManagerSuite.TestHookTaskCanKillHook hangs forever with it
 * mvo scratches head
<zyga> mvo: what is 69692a?
<mvo> zyga: a git change we landed a while ago
<zyga> ah, that's a git commit id
 * zyga looks
<mvo> zyga: and it seems like its breaking things in bionic/armhf
<mup> PR snapd#5637 closed: udev: skip TestParseUdevEvent on ppc  <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5637>
<mborzecki> hmm I suspect that snap-update-ns is not built as a static library on opensuse with our current packaging
<mborzecki> i'm hitting the same segfault bug i saw on friday in parallel-install tests on opensuse
<mborzecki> aand it is wrong indeed
<mborzecki> zyga: have you synced opensuse obs packaging with our in-tree one?
<niemeyer> Mornings
<mvo> hey niemeyer, good morning!
<niemeyer> mvo: Heya! Beautiful indeed
<niemeyer> ... and warm
<mborzecki> niemeyer: hey
<zyga> hey hey :)
<zyga> mborzecki: yes I did
<zyga> mborzecki: but perhaps some bugs just crept in
<zyga> mborzecki: I can look after I'm done with travel paperwork
<zyga> mborzecki: (50% done now, whee)
<zyga> niemeyer: hey :)
<mborzecki> zyga: yeah, i'll fix the spec
<zyga> niemeyer: I recommend you to read the report I sent
<mborzecki> zyga: we should probably plan to add leap to our test suite
<mborzecki> uh leap 15
<zyga> mborzecki: yeah
 * zyga scans the second pile of paper now
<niemeyer> zyga: Thanks, will definitely read
<Chipaca> jdstrand: we've been missing each other (aww), so I wrote out what I see as a problem with our hostname-control interface over on the pr that's failing because of it: https://github.com/snapcore/snapd/pull/5593#issuecomment-412812808
<mup> PR #5593: tests: new test for hostname-control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5593>
<Chipaca> jdstrand: I don't know if the failure is specific to 18.04, or if it's just more likely in 18.04: I've seen failures in 14.04 that look similar but haven't been able to reproduce consistently enough to get a shell and poke around
<mup> PR snapd#5648 opened: hookstate: simplify some hook tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/5648>
<mvo> pedronis: ^- thats probably something for you, I wonder if we need to do more than just fixing the test
<pedronis> mvo: seems you wrote those tests like that with goroutines, do you remember why?
<mvo> pedronis: the problematic CanKillHook is quite old, unless I misread git blame it was written by kyle in 2016
<pedronis> mvo: anyway I don't have a quick answer, I need to carefully re-read them
<mvo> pedronis: yeah, the other two are mine, probably silly cargo culting :(
<mvo> pedronis: yeah, the tests are not so much the issue, its more that potentially we can deadlock when calling StateEngine.Wait() at the wrong moment, then StateEngine.Ensure never gets a chance to run
<mvo> pedronis: I can reproduce this reliable on an armhf system here fwiw
<pedronis> mvo: I'm not sure IÂ understand the explanation,  we do release the lock around each  tomb.Wait
<pedronis> which lock are we talking about
<mvo> pedronis: StateEngine.mgrLock is acquired in StateEngine.Wait() but only relased when all se.managers finish their Wait()
<mvo> pedronis: that seems to be the high level issue
<pedronis> ah
<mvo> pedronis: that this does not finish until Ensure() was run
<pedronis> mvo: ok, now I see how it's related to my single taskrunner changes
<mvo> pedronis: great, keen to hear your ideas if/what we need to do beside fixing the test
<pedronis> mvo: so a couple didn't need the 2nd Ensure either?
<zyga> 100% of expenses done, now some more paperwork
<pedronis> mvo: the fix seems alright now that I understand, still not sure why it was using a goroutine,   Wait doesn't trigger anything on its own, it just waits
 * pedronis lunch
<mvo> pedronis: yeah, the other two I think simply took the TestHookTaskCanKillHook and removed the s.change.Abort()
<mvo> pedronis: so the whole ensure,lock,unlock,ensure dance is cargo cult it seems
<mvo> pedronis: enjoy lunch, ttfn
<pstolowski> 2018/08/14 12:31:51.850100 hotplug.go:66: DEBUG: HotplugDeviceAdded: /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/ttyUSB0/tty/ttyUSB0 (default key: "0403:6001:AH06W0EQ", devname /dev/ttyUSB0, subsystem: tty)
<pstolowski> 2018/08/14 12:31:51.850905 hotplug.go:132: Added hotplug slot "serial-port-4527" (serial-port) for device key "0403:6001:AH06W0EQ"
<pstolowski> :)
<zyga> wooot :)
<ogra> crazy !
<zyga> that's so cool pawel :)
 * zyga hugs pstolowski 
<pstolowski> zyga: still many holes, but..
<ogra> pfft ... holes ... just ship some buckets along
<pstolowski> $ snap interfaces ...
<pstolowski> :serial-port-4527                  -
<mborzecki> nice
<zyga> snap interface serial-port -a
<zyga> show me the attributes :)
<mvo> pstolowski: nice job!
<pstolowski> zyga: $ snap interface serial-port --attrs
<pstolowski> name:    serial-port
<pstolowski> summary: allows accessing a specific serial port
<pstolowski> slots:
<pstolowski>   - system:serial-port-4527:
<pstolowski>       path: /dev/ttyUSB0
<pstolowski> pawel@mordor ~/gocode/src/github.com/snapcore/snapd/osutil/udev (hotplug-ifacemgr*) $
<zyga> pstolowski: so nice :)
<zyga> pstolowski: do you think we could start using label?
<zyga> pstolowski: I mean, if the hot plug code can provide any form of useful label
<zyga> pstolowski: (label doesn't have to be unique)
<zyga> label would be displayed there
<zyga> can you think of any udev data that could be a good fit?
<pstolowski> zyga: we can use any name as long as it can be derived from the data (i.e. udev event attributes)
<zyga> pstolowski: is there anything that has a useful value for your device?
<pstolowski> https://www.irccloud.com/pastebin/MYiAtyU7/
<pstolowski> zyga: so there is some room for creativity.. e.g. derive it from cleaned-up vendor name etc
<pstolowski> zyga: with fallbacks of course, as any of that may be missing for clones i guess
 * zyga has completed all of the paperwork now
<pstolowski> zyga: if you in the mood for reviews, i've 3 udev-related PRs that would be nice to land to unblock more interesing stuff
<mup> PR snapd#5649 opened: packaging/opensuse: fix static build of snap-update-ns and snap-exec <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5649>
<mborzecki> zyga: ^^
<zyga> mborzecki: looking
<zyga> mborzecki: I should be able to, I will look at reviews now
<zyga> (well, after a small snack)
<zyga> mborzecki: that's neat
<zyga> mborzecki: where did you try it?
<zyga> mborzecki: I recall now that it didn't work (compile) on some versions of suse
<mborzecki> zyga: opensuse debug shell ;)
<zyga> mborzecki: I will grab some food and then ensure it builds on the oldest supported leap (42.x)
<zyga> mborzecki: if it builds then that's great :)
<pedronis> mvo: btw we don't use Wait anywhere but tests, and daemon use Stop on overlord wich waits first for the loop, so I don't think any similar issue affects prod code
<mborzecki> zyga: they have a quite byzantine rpm go integration, there's a script /usr/lib/rpm/golang.sh which wraps all go commands
<zyga> yeah I know, before that it used to be ruby
<zyga> a golang SIG was formed at flock and suse is supposedly going to join as well
<mborzecki> heh, so maybe someone thought that shell is less arcane :P
<zyga> because packaging across the two is totally different
<mborzecki> it'd be nice to see some consistency
<mborzecki> aand parallel install tests work now on opensuse once again
<mborzecki> zyga: if you could https://github.com/snapcore/snapd/pull/5646
<mup> PR #5646: cmd/snap-confine: extend security tag validation to cover instance names <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5646>
<zyga> mvo: when is 2.35.0? is that now already?
<mborzecki> hmmm there appears to be no real input validation when installing many snaps, so  `snap install '' bar` has funny side effect
<mborzecki> error: cannot install "", "bar": internal error: action without instance name
<mborzecki> so it went down to store.SnapAction() and stopped there :)
<pedronis> mborzecki: I think there are various bugs about error handling in multi-install, apparently is not a very used feature, so we mostly find them by playing on our own
<pedronis> mborzecki: also not sure it's relevant to what you are doing but we should change it to be like UpdateMany and do a single store request at the start
<niemeyer> pedronis: I hope the change in task conflict you're working on will make this tend to work well more often
<mborzecki> pedronis: i found it by accident with shellchecks, incorrectly added quoting of flags, those when empty ended up being a '' positional argument
<pedronis> niemeyer: not sure this is related to conflicts
<pedronis> otoh that change to make it more like UpdateMany would help conflict/concurrency work
<pedronis> it's on my todo list, I know it would fix some of error handling issues as well
<pedronis> not this one, or not sure about this one though
<niemeyer> Lunch, biab
<cachio> Chipaca, hey, do you remember the permissions error that I sent you yesterday
<cachio> it is happening in the refresh scenatio
<cachio> scenario
<cachio> when we start from the factory release image and we refresh the core from beta
<zyga> cachio: hey. I checked the thing you asked about yesterday. With current master there is no error. I believe this situation is just because edge is currently not really edge but a release candidate build
<cachio> zyga, hey
<cachio> I am testing beta
<zyga> cachio: so all should be fine once edge starts tracking master again
<cachio> zyga, do you mean some PRs were not included as part of this beta?
<cachio> so we should wait for 2.36 for the fix?
<zyga> cachio: I think it's a version problem more than branch problem; the PR that included the test and the fix _passed_
<zyga> I think 2.35.1
<zyga> mvo: are we still in a situation where when we do a ~pre1 release for 35 we will have disabled reexec for people who track edge?
<cachio> zyga, ok
<zyga> mvo: I'm trying to understand why exactly edge is breaking while master rebuild works ok
<mvo> zyga: I'm not sure I understand the question, we are that 2.35~pre1
<zyga> mvo: do you know if the fix for fedora29 was included in 2.35
<zyga> mvo: ok, another way, which branch contains 2.35~pre1?
<mvo> zyga: I don't know but I can check, release/2.35
 * zyga checks
<zyga> mvo: thanks, let me look
<mvo> zyga: thats the branch that contains the 2.35~pre1 - I can/will do a ~pre2 or ~rc1 RSN
<Chipaca> cachio: fake store, or actual store?
<zyga> ah, I see
<zyga> so 2.35 release branch has the fix
<zyga> but yet the build in edge doesn't work
<zyga> hmm?
<mvo> pedronis: yeah, its just test code that uses stop
<cachio> Chipaca, the actual one
 * zyga is confused now
<zyga> but the build from master works (and it has the same fix)
<mvo> zyga: maybe edge is behind
<zyga> mvo: edge is at ~pre1
<mvo> zyga: and the snapd-vendor git tree is broken
<mvo> zyga: *grumpf*
<zyga> not sure, I don't understand yet
<zyga> I could build a dpkg from release/2.35
<mvo> zyga: there is a bug
<zyga> and see what's the output
<cachio> zyga, we here we are using a core image created using ubuntu-image, and in google we build it manually from ubuntu 16.04-64, could that affect in some way?
<zyga> cachio: it depends, is the package updated inside those environments?
<zyga> cachio: as in, is snapd really up to date?
<mvo> zyga: snapd-vendor-daily ppa builds are broken, I'm looking into this now
<zyga> mvo: ahh
<zyga> thank you!
<zyga> cachio: perhaps that explains it
<mvo> zyga: I triggered a rebuild, lets see
<zyga> mvo: thank you
<cachio> mvo, I see snapd-vendor-sync in green
<cachio> mvo, ahh, the ppa builder
<Chipaca> cachio: do you have the pastebin (from the permissions error) handy?
<cachio> Chipaca, https://paste.ubuntu.com/p/FJVhj5H2H7/
<cachio> Chipaca, the snaps which are before the core is updated are with wrong permissions
<Chipaca> cachio: were those snaps put there by hand?
<cachio> Chipaca, no
<Chipaca> cachio: by what then?
<cachio> I just refreshed the core
<cachio> and then ran the snapd test suite
<Chipaca> cachio: right
<Chipaca> cachio: but the snaps in seed/
<Chipaca> cachio: have the wrong permissions
<cachio> Chipaca, yes
<Chipaca> wait, and the refreshed ones do as well?
<cachio> Chipaca, those are the ones that come with the factory release
<Chipaca> cachio: I mean pc-kernel_126.snap and pc-kernel_45.snap both have the wrong permissions
<cachio> Chipaca, yes
<Chipaca> cachio: they're both in the factory release?
<cachio> Chipaca, pc, pc-kernel and core have wrong permissions
<cachio> Chipaca, I think so
<cachio> and the refreshed snapd also have wrong permission
<cachio> Chipaca, I don't know if the core snap shol fix that, or it is ok?
 * Chipaca sings "everything is awesome" but with more realistic lyrics
<Chipaca> cachio: it sounds like a regression to me
<Chipaca> cachio: but also maybe a bug in ubuntu-image
<cachio> Chipaca, ok
<Chipaca> cachio: where can I get this image from?
 * Chipaca thinks prepositions are dandy things to end sentences with
<cachio> Chipaca, cheching
<cachio> Chipaca, http://cdimage.ubuntu.com/ubuntu-core/16/stable/20170323/ubuntu-core-16-amd64.img.xz
<cachio> Chipaca, I think this is the one I used
<cachio> Chipaca, it is an old one
<Chipaca> getting
<Chipaca> ah
<mvo> zyga: and all builds are failing, oh well
<Chipaca> cachio: how old?
<mvo> zyga: anyway, on it
<Chipaca> cachio: that explains it
<zyga> thank you
<zyga> I'm slowly getting back into production mode
<Chipaca> cachio: that, on its own i mean, could explain it
<zyga> I managed to clean a pile of paper from my desk
<Chipaca> cachio: this permissions thing is not old
<cachio> Chipaca, ah, so I sholud skiip this test on the refresh sncenario?
<cachio> Chipaca, when I am using this image?
<Chipaca> cachio: the commit that made downloads be 0600 is from Jul 10
<cachio> Chipaca, ok
<Chipaca> cachio: not sure what release it landed it, this one might be the first with this check
<Chipaca> cachio: so, yeah
<cachio> Chipaca, ok, I'll skip it
<cachio> Chipaca, thanks
<Chipaca> cachio: everything after snapd restarted is 0600 so all is well
<mvo> zyga: fun! fb730e1 broke snap building, the tests fail to run now when no snapd is running, I'm looking into the details, just a heads up.
<zyga> mvo: thanks, I found a small bug in snap-confine, patches soon, just fixing tests
<mup> PR snapd#5650 opened: snap: fix mocking of systemkey in snap-run tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/5650>
<mborzecki> hm in some daemon tests we call postSnap directly, passing it a newly built http.Request, but inside it calls mux.Vars() which then tries to use the request's context to obtain the list of registeres uris, which is obviously empty at this point, so any attempts to recover vars from urls are useless
<Chipaca> mborzecki: that's why some tests mysteriously do .daemon()
<pedronis> daemon test would need love, there's  a bunch of style and cargo cultinting there
<pedronis> *styles
<pedronis> but is never on top of anybody's list
<mborzecki> Chipaca: this one does too, but unless the request is enriched with the context (or goes through gorilla's handler) mux.Vars won't work as expected
<Chipaca> mborzecki: set .vars?
<Chipaca> mborzecki: 	d := s.daemon(c)
<Chipaca> 	s.vars = map[string]string{"name": "foo"}
<Chipaca> etc etc
<mborzecki> pfff
 * mborzecki facepalms
<mborzecki> need more coffee clearly
<Chipaca> mborzecki: and then
<Chipaca> 	req, err := http.NewRequest("GET", "/v2/snaps/foo", nil)
<Chipaca> works
<Chipaca> mborzecki: it's all mocks, all the way down
<mborzecki> yeah. s.vars is what's missing
<pedronis> and tons of lines of tests
<pedronis> some do what you want
<pedronis> just a matter of finding them :(
<pstolowski> niemeyer: we need to agree on a the better name for "disconnect-interfaces" task in #4767 ; that's the only point that i haven't addressed in the PR
<mup> PR #4767: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>
<niemeyer> pstolowski: Cool, let's talk on the stand up
<pstolowski> great
 * zyga coffee break
<mup> PR snapd#5651 opened: cmd/libsnap: unify detection of core/classic with go <Created by zyga> <https://github.com/snapcore/snapd/pull/5651>
<cachio> mvo, https://paste.ubuntu.com/p/sDRd5txDsd/
<cachio> I saw this error on an amazon linux instance
<cachio> on google
<cachio> mvo, could be related to the other issue in the forum?
<mvo> cachio: maybe but the error looks different, the stuff in the forum is more about excessively slow machines (at least it looks like this from the outside)
<mup> PR snapd#5652 opened: cmd/snap, daemon: error out if trying to install a snap using empty name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5652>
<mborzecki> Chipaca: ^^
<Chipaca> mborzecki: is the client also erroring out?
<mborzecki> Chipaca: yeah, both sides do the checking now
<Chipaca> mborzecki: I'll look in a bit, need caffeine (but sounds good)
<popey> Where does snapd get the host OS name from? neon shows in the store as "neon", but that's neon 16.04. With neon 18.04 coming, it will still only show "neon" which doesn't help differentiate the two releases.
<popey> (other OS's show the version)
<mborzecki> 2018-08-14 12:47:57 Cannot allocate google:ubuntu-16.04-64: cannot perform Google request: Get https://www.googleapis.com/compute/v1/projects/computeengine/zones: oauth2: cannot fetch token: Post https://accounts.google.com/o/oauth2/token: net/http: TLS handshake timeout
<Chipaca> popey: /etc/os-release
<pedronis> we send both the ID and VersionID
<pedronis> so it's more of a question how they are used
<popey> the stats page don't show the versionid bit
<mvo> 5648 is an easy win (and will fix armhf builds!)
<mvo> cachio: 5635 is probably interessting for you
<popey> ID=neon
<popey> VERSION_ID="16.04"
<popey> but store just shows "neon". is this a bug in snapd or the store?
<pedronis> popey: I'm saying snapd sends it, so it's a matter of store side processing here
<pedronis> afaiu
<cachio> mvo, nice
<zyga> mborzecki: one question on 5652
<pedronis> unless something else is breaking down
<Chipaca> popey: sorry, are you talking about the user-agent?
<popey> i am talking about pages where we look at stats for installs of snaps
<pedronis> afaik that's the only place we send that info through
<popey> hover your mouse over the metrics and hit gives you blobs with version name/number
<Chipaca> popey: do you have a neon to poke at?
<popey> linux mint shows as "linuxmint" and zorin is "zorin", but Ubuntu is "ubuntu 16.04" or "ubuntu 18.04"
<popey> i am sat at neon now
<pedronis> I wonder what's different
<popey> https://snapcraft.io/account/snaps/<snapname>/metrics?active-devices=os  is the graph I am talking about
<pedronis> seeing the User-Agent might help
<pedronis> I don't see code that would treat ubuntu specially
<popey> https://usercontent.irccloud-cdn.com/file/XnIsCGMj/This%20graph
<pedronis> or it might be some store postprocessing
<pedronis> popey: asking under a store topic in the forum might be best
<Chipaca> popey: what does 'snap version' show?
<popey> https://pastebin.com/AFtMrKAN
<popey> Ok, I'll ask on the forum.
<Chipaca> popey: when you start snapd, what's the "started snapd/<blah blah>" log line?
<popey> uhm
<popey> when *I* start snapd?
<Chipaca> popey: journalctl -u snapd | grep started
<popey> Aug 12 13:37:22 KinkPad-K450 snapd[4018]: daemon.go:343: started snapd/2.35~pre1 (series 16; classic) neon/16.04 (amd64) linux/4.15.0-30-generic.
<Chipaca> popey: that's the user agent we're sending
<popey> Ok, thanks :)
<popey> I'll include that.
<Chipaca> popey: ubuntu's is: 2018/08/14 14:10:23.065715 daemon.go:343: started snapd/2.34+git209.g9c5287393.dirty (series 16; classic; testing) ubuntu/16.04 (amd64) linux/4.4.0-131-generic.
<Chipaca> well, not the dirty testing bit
<Chipaca> 2018/08/14 14:11:11.274478 daemon.go:343: started snapd/2.34.3 (series 16; classic) ubuntu/16.04 (amd64) linux/4.4.0-131-generic.
<pedronis> yea, os should be parsed by the store as 'neon/16.04'  so there should be some postprocessing
<pedronis> aggregating
<popey> https://forum.snapcraft.io/t/why-does-neon-16-04-show-as-neon-in-the-store/6868
<mup> PR snapd#5643 closed: interfaces/builtin: addtl network-manager resolved DBus fix <Created by tonyespy> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/5643>
<mup> PR snapd#5649 closed: packaging/opensuse: fix static build of snap-update-ns and snap-exec <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5649>
<mup> PR snapd#5650 closed: snap: fix mocking of systemkey in snap-run tests <Critical> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5650>
<mup> PR snapd#5646 closed: cmd/snap-confine: extend security tag validation to cover instance names <Parallel installs> <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5646>
<mup> PR snapd#5648 closed: hookstate: simplify some hook tests <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5648>
<mup> PR snapd#5652 closed: cmd/snap, daemon: error out if trying to install a snap using empty name <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5652>
<mup> PR snapd#5647 closed: tests: shellchecks part 7 <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5647>
<mup> PR snapd#5639 closed: snapcraft: set version information for the snapd snap <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5639>
<ogra> mvo, no unified pi gadget then ? *snoff*
<ogra> *sniff* even
 * ogra had high hopes
<ogra> (reading your core18 models proposal)
<mvo> ogra: the unified vs non-unified pi was discussed with niemeyer  and the conclusion was that if we ever need to "unbunble" them again we will be in a world of pain
<ogra> why would *we* unbundle them for the reference image ...
<ogra> customers would likely build single-pi ones
<ogra> doing QA on 4 images vs 1 is definitely a massive cost factor
<ogra> but well ... niemeyers decision then :/
<niemeyer> ogra: Because until a few days ago we needed different images.. they did a change that allows having a single image.. tomorrow they can do a change that requires different images again
<niemeyer> ogra: When that happens, we're in deep trouble, because the systems will update to the merged snaps regardless
<niemeyer> ogra: These devices are very unlike each other.. doesn't seem wise
<ogra> niemeyer, my proposal is a month old (admittedly only added to the forum 2 weeks ago) ... the name could be simply "pi" and if you want separate images you'd still ahve pi2, pi3, cm3 (and soon pi3b+)
<niemeyer> ogra: The age of the proposal is not in general something we account for :)
<ogra> niemeyer, this proposal was spoecifically for core18 only and the devices are identical on the SoC level, use the same kernel and will only differ by peripherials
<ogra> core18 only -> new installs
<ogra> niemeyer, that age comment was about your "until few days ago" :)
<niemeyer> ogra: I also don't understand your point.. it sounds like this is what we debated, and replied to above?
<niemeyer> ogra: it doesn't matter if it was 10 days ago or 10 months ago.. the exact same point holds
<ogra> a system installed with the pi2 snap will not upgrade to a new "pi" (without 2) gadget
<ogra> so this would only affect new installs of core 18
<niemeyer> ogra: Exactly, which is why this is all a bad idea
<niemeyer> ogra: We don't want a pi3 using a pi2 snap
<niemeyer> ogra: We need a way to upgrade the pi3 to a pi3-specific snap
<ogra> and we could phase out the old separate gadgets once core 16 goes out of support
<ogra> which we cant do if we keep that schema
<ogra> there is really no reason to have separate gadgets at all for mostly identical HW
<niemeyer> ogra: This is *not* mostly identical hardware.. the pi3 and pi2 have completely different chips
<ogra> upstream specifically offers the separation in the config to account for the different peripherials and we should be good downstreams and simply follw their guide here
<ogra> but whateverm, the decision has happened and i have a meeting ... i just tried to be a good citizen towards downstream, save us money and maintenance work and have a future plan for post 18 times ... anyway, i'll live with it
<niemeyer> ogra: It's not an arbitrary decision.. I've explained exactly why this is necessary, and pointed out that the devices are not the same
<niemeyer> ogra:  THis is not "whatever".. this is a decision we are taking because there's a reason
<niemeyer> ogra: When you run out of bad arguments, please just be understanding
<ogra> niemeyer, just note that upstream offers a unified bootloader for all pi's from the same binary ... it was us that added an artificial separation here that i tried to overcome ...
<niemeyer> ogra: Instead of dismissive
<niemeyer> ogra: Thank you
<ogra> niemeyer, well, the decision is made, why should i still argue ...
<mup> PR snapd#5653 opened: release: 2.35~pre3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5653>
<mvo> zyga: just fyi, edge core is back
<mup> PR snapd#5617 closed: overlord/devicestate: DTRT w/a snap proxy to reach a serial vault <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5617>
<pedronis> mborzecki: hi, sorry, had a bit of an afternoon of meetings, I will look again at your parallel installs PR in the morning
<mborzecki> sure, thanks,, just fyi i'm off tomorrow so will do the fixes on thursday
<mborzecki> pedronis: ^^
<pedronis> mborzecki: np, I remember correctly it was quite close
<pedronis> *if I remember
<mborzecki> pedronis: i've pushe some fixes based on comments form pstolowski and Chipaca
<pedronis> ok
<mup> PR snapd#5654 opened: cmd/snap-confine: establish snap directory mappings for parallel instances <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5654>
<mborzecki> zyga: jdstrand: something for you guys ^^ :)
<mborzecki> ok, back to fixing the flow heater
<rbasak> I've registered my GitHub repository against build.snapcraft.io to automatically build my certbot snap. It's building it now. I have some tests I want to run against the installed snap. Is there any infrastructure that will help me with this (eg. Travis), or do I need to set something up myself? The key thing is that I want to CI the snap itself, rather than the code in the upstream repos (since they
<rbasak> already do that).
<ogra> rbasak, despite being old (and IIRC also unfinished) https://forum.snapcraft.io/t/new-tutorial-ready-for-review-continuous-delivery-with-travis-ci/135 might help
<ogra> (or at least give some ideas)
<rbasak> Thanks!
<rbasak> Looks like those instructions will allow me to do exactly what build.snapcraft.io is doing for me, but in Travis.
<rbasak> I might be able to extend them though to further actually test the snap once built, which I don't think I can do on build.snapcraft.io currently.
<rbasak> There's quite some crossover here with https://forum.snapcraft.io/t/launchpad-post-build-pre-upload-testing/5545/3
<rbasak> AFAICT, nobody has thought about how to actually CI snaps themselves?
<rbasak> Separately, I can't seem to find a way to get build.snapcraft.io to build on a timer :-/
<rbasak> This is problematic since I'm not actually upstream so my webhook won't ever really fire (unless I change snapcraft.yaml)
<cachio> Chipaca, hey, what do yuou suggest to do with #5593
<mup> PR #5593: tests: new test for hostname-control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5593>
<cachio> with the errors you found there?
<om26er> Hello! is there a way to have latest Qt with desktop-qt5 part ?
<om26er> We are snapping a PySide2 app and it requires Qt 5.11
<ogra> just clone it and make your own ?
<om26er> Where does it live ?
<ogra> https://wiki.ubuntu.com/snapcraft/parts is wheer snapcraft pulls the info from ...
<ogra> mvo, this 1:30 snapd timeout on shutdown gets really annoying, did you manage to find where it comes from ?
<ogra> (after auto-refreshes of core)
<mup> PR snapd#5655 opened: snap,snap-exec: support command-chain for hooks <Created by kyrofa> <https://github.com/snapcore/snapd/pull/5655>
<kyrofa> Chipaca, if you have a few, that ^ should look very familiar
<mup> PR snapd#5653 closed: release: 2.35~pre3 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5653>
<mvo> ogra: hm, I have not. could you please remind me tomorrow morning and we can dig into it
<ogra> vmo, sure
<ogra> bah
<om26er> I am building a snap in Ubuntu 18.04 container, but it complains https://paste.ubuntu.com/p/H74sHhGkgH/
<om26er> is there a way around that (instead of shipping libc6)
<mcphail> om26er: Won't you need core18 to avoid that?
<om26er> mcphail: is that possible ?
<mup> PR snapd#5656 opened: debian: add missing breaks on comisc <Created by mvo5> <https://github.com/snapcore/snapd/pull/5656>
<sergiusens> mvo there might be a small issue here https://paste.ubuntu.com/p/VmvrgGmNhC/
<mup> PR snapcraft#2214 opened: sentry: support disabling error reporting <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2214>
<mup> PR snapd#5657 opened: interfaces: add cpu-control for setting CPU tunables <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5657>
<mup> PR snapd#5658 opened: interfaces: add cpu-control for setting CPU tunables <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5658>
<jdstrand> zyga: hey, would you mind taking a look at ^. this is part of our L1TF response and would be nice to have in 2.35
<mcphail> om26er: yes, although i don't think the store is ready for snaps requiring core18 yet
<om26er> mcphail: in my case, I'll probably end up building Qt 5.9 myself to fix that above issue.
<om26er> Though still not there yet.
<mcphail> om26er: i think it is safe to say core18 is eagerly anticipated
<ogra> jdstrand, shiny !! what about access to the thermal, cpufreq and cpuidle nodes ?
<jdstrand> ogra: not opposed to adding those with specific use cases
<ogra> (or would these go into separate interfaces)
<jdstrand> thermal maybe separate?
<ogra> yeah
<jdstrand> cpufreq and idle probably in cpu-control
<ogra> yeah, i think that makes sense
<ogra> (i dont really have a use case yer apart from someone packaging up cpufreq-utils in a snap or some such )
<ogra> s/yer/yet/
<ogra> but i think being able to access them through such an interface makes a lot of sense
<mup> PR snapcraft#2189 closed: project_loader: add basic template support <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2189>
<om26er> ogra: who maintains for desktop-qt5 cloud part ?
<mup> PR snapd#5609 closed: tests: new test for juju client observe interface <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5609>
<ogra> om26er, sould be noted in the wiki entry
<ogra> *should
<ogra> (there is surely a GH link there from wher the code is pulled)
<om26er> right, it links to https://github.com/ubuntu/snapcraft-desktop-helpers
<om26er> and the qt directory was last touched over a year ago, though the snapcraft.yaml there doesn't really make much sense ;-)
<om26er> apparently kde-frameworks-5 snap have a slot kde-frameworks-5-45-qt-5-9-ubuntu-1604 maybe I could try "plugging" into it, before going for a custom Qt build.
<jdstrand> popey: hey, can you add https://forum.snapcraft.io/t/tio-request-for-classic-confinement/6209/15 to your list?
<jdstrand> popey: hey, this one too if you don't mind: https://forum.snapcraft.io/t/classic-confinement-for-minizinc/6529/4
<mup> PR snapcraft#2196 closed: build providers: better injection logic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2196>
#snappy 2018-08-15
<mup> PR snapd#5659 opened: tests: remove manual from openvswitch test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5659>
<mup> PR snapd#5601 closed: seccomp: conditionally add socketcall() based on system and base <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5601>
<mup> PR snapd#5633 closed: seccomp: conditionally add socketcall() based on system and base - 2.35 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5633>
<palasso> Hello, I'm wondering why there's multiple "core" snaps (core, core16, core18) instead of one core snap with tracks
<mvo> palasso: its mostly because we need to install core18 and core in parallel. i.e. you can have a ubuntu core 16 device and install snaps that require core18. otherwise it would be nice and elegant to just use tracks
<palasso> mvo: Thank you for the response. I didn't know it's not possible to install different versions from tracks in parallel. Is there a reason it's not possible?
<mvo> palasso: its not implmented yet, we will support this in RSN
<palasso> Ah that's good news
<mvo> palasso: https://github.com/snapcore/snapd/pull/5596
<mup> PR #5596: (WIP) parallel installs integration <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5596>
<palasso> After it's implemented could this mean that the "core" snaps would utilize tracks?
<mvo> palasso: this is the PR that tracks the work, I would estimate ~3-4 weeks until its available in some beta
<palasso> mvo: tyvm for your response :)
<mvo> palasso: this will also allow stuff like "snap install go_1.6 --channel=1.6"
<mvo> palasso: which I personally look forward to :)
<palasso> So then  instead of a go_1.6 it'd be go? and it'd be snap install go --channel=1.6?
<palasso> Actually there's already a "go" with tracks as such
<mvo> palasso: it would be go_1.6 and I could have go_1.10 at the same time installed
<mvo> palasso: or the same snap (database_test, database_prod) even
<mvo> palasso: its a cool feature
<pedronis> mvo: I answered one of your comments on pawel PR
 * pedronis reboot
<mvo> pedronis: thank you!
<mvo> pedronis: hm, I don't see the reply, is GH slow or is it somehow pending?
<pedronis> mvo: it's there, but some comments are collapsed, or you mean you didn't get an email?  anyway https://github.com/snapcore/snapd/pull/4767#discussion_r210202153
<mup> PR #4767: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>
<mvo> pedronis: oh, ok
<mvo> pedronis: yeah, I missed this one - thanks for pointing this out
<pedronis> mvo: anyway I still hope long term we will not need these functions/checks
<pedronis> well medium term
<mvo> pedronis: right - that would be neat
<pedronis> hopefully
<mvo> pedronis: do you have an opinion about https://github.com/snapcore/snapd/pull/5618#discussion_r210186520 btw?
<mup> PR #5618: overlord: instantiate UDevMonitor <Created by stolowski> <https://github.com/snapcore/snapd/pull/5618>
 * mvo hugs Chipaca for his wise word on 5656
<Chipaca> mvo: I blame you for making me be aware of that quote
<pedronis> mvo: it sorts of feel like it would be nice if the monitor was embedded in a manager
<pedronis> that woudln't solve exactly the problem you mention though
<mvo> pedronis: oh, thats an interessting idea, could it become its own manager?
<mvo> pedronis: and we pass ifmanager into it or something
<pedronis> maybe but it doesn't help avoiding the mocking
<pedronis> for places that really use the full overlord
<pedronis> which seems your worry
<pedronis> but it avoids some ad hoc code
<pedronis> otoh afaik that code started that way
<mvo> pedronis: oh, ok
<mvo> pedronis: and gustavo was in favor of moving it?
<pedronis> and then it came to this
<pedronis> IÂ don't remember
<mvo> pedronis: "there is nothing new under the sun" :)
<pedronis> I think one issue is that managers have Stop
<pedronis> but not Start
<pedronis> but in the new world where some of this thing are optional
<mvo> pedronis: indeed
<pedronis> it would be possible to add that
<pedronis> without needing to touch everything
 * mvo nods
<mvo> pedronis: I can play around a bit, but yeah, my concern is that we need to mock a lot of place now and it looks like we did not even caught all the places yet
<mvo> pedronis: anyway, I will create a PR based on pawels with my idea and see what it looks like - if its bogus I will just discard
<pedronis> mvo: ok
<pedronis> mvo: btw  I commented on your seed sorting PR, I fear we need to do the thing at first boot (as well)
<mvo> pedronis: yeah, I saw it, also your comment about proper topsort, makes me wonder if I should just close it and we go all the way or if its still worth having as an intermediate step
<pedronis> mvo: I don't think the intermediate step is useful as is, as I said it doesn't fix the actually reported case
<mvo> pedronis: yeah, good point.
<pedronis> mvo: I have mixed feelings about the all thing to be honest, our waiting for content providers is a bit for strange reasons, auto connect itself is symmetrical
<pedronis> mvo: the problematic code is here:  https://github.com/snapcore/snapd/blob/master/overlord/ifacestate/handlers.go#L591
<pedronis> mvo: in theory we could also fix the default-provider problem there, with code like the one pawel had at some point, then the sorting would only need to be about bases which is simpler
<pedronis> and at some point we probably could remove most of the special code there
<pedronis> mvo: we can have chat about this if you want at some point
<ogra> mvo, thanks for the answer in the model assertions thread, i added a comment and will stay quiet on the topic now :)
<pedronis> mvo: let me know
<mvo> pedronis: talking about this sounds great, I am still playing with the overlord/udevmon but maybe this afternoon?
<mvo> ogra: thanks
<pedronis> mvo: ok
<pedronis> mvo: anyway this afternoon or tomorrow might be better for me, I have other things to look into
<pedronis> as well
<pedronis> mvo: tomorrow is probably better tbh
<mvo> pedronis: ok, then tomorrow it is
<sparkiegeek> hmm, the email gateway for forum.snapcraft.io appears to be broken? is that known?
<sparkiegeek> https://paste.ubuntu.com/p/vNpx2n3znq/
<sparkiegeek> when replying to a notification
<mup> PR snapd#5611 closed: devicestate: only run device-hook when fully seeded <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5611>
<Chipaca> sparkiegeek: I don't think that's known
<Chipaca> sparkiegeek: in fact it worked, before
<sparkiegeek> Chipaca: ok, I wasn't sure because I never used it before. Have only tried it recently (i.e. post the move of owners) and both times it broke,
<Chipaca> sparkiegeek: are you  going to go pester the new owners now?
<Chipaca> :-)
<sparkiegeek> Chipaca: I could do :) would be nice if I could get confirmation that it's not Just Meâ¢ for which it fails
<sparkiegeek> *whom
<Chipaca> sparkiegeek: this is when replying to an email notification?
<sparkiegeek> Chipaca: correct
<ogra> mvo, so how do we tackle that auto-update issue with edge where snapd hangs on shutdown
<ogra> (what should i capture next time it happens ... sadly it is only reproducable when auto-updating so hard to tell in advance when it happens)
<mvo> ogra: do you have any logs? that is a "normal" uc16 system?
<mvo> ogra: oh, only auto-update - thats interessting
<mvo> ogra: and annoying of course :/
<Saviq> hey all, is it on purpose that core18 does not have /etc/ssl/certs ?
<ogra> mvo, no logs yet since i always only notice it when the system is already rebooting ...
<ogra> mvo, and yes, core 16 edge in qemu
<ogra> i can set up my VMs to captuer stuff constantly, i just need to know what ;)
<Chipaca> sparkiegeek: confirmed, i got the same posting error email (well, not the *same* one, but)
<Chipaca> sparkiegeek: [snapcraft.io] Email issue -- Posting error
<sparkiegeek> Chipaca: mine was titled 'Unknown To: Address'
<Chipaca> oh wait
<Chipaca> sparkiegeek: this might actually mean my email worked
<Chipaca> sparkiegeek: if I actually _read_ the email, it says the body was too short
<sparkiegeek> Chipaca: ah..
<mvo> ogra: the journalctl output when it shuts down would be great
<Chipaca> sparkiegeek: I'll try again :-)
<sparkiegeek> Chipaca: thanks, I'll prepare the aforementioned pester but hold off on sending
<ogra> mvo, ok, i'll simply enable persistent journald by default in my VMs ... lets see what i can get there
<ogra> will ping once i have something
<Chipaca> sparkiegeek: https://forum.snapcraft.io/t/error-cannot-install-hello-world-post/6849/7?u=chipaca
<sparkiegeek> Chipaca: ho hum
<mvo> ogra: thank you
<pedronis> ogra: what do you mean with hangs on shutdown?
<pedronis> it's designed to wait on shutdown
<ogra> pedronis, i get a systemd unit timeout (the typical 1:30 thingie with countdown in red)
<ogra> i dont get that in normal reboots, only when there was an auto-upgrade and the system reboots out of the blue
<pedronis> mvo: did we add watchdog stuff? does it interfere with the way we do shutdowns?
<ogra> (note that i'm working with kiosk stuff, so i'm usually not logged in on console when that happens to see the shutdown warning)
<pedronis> anyway logs  or  sending a SIGQUIT to the "hanging" snapd and logs would be useful
<pedronis> I see we added watchdog stuff in main.go, otoh the reboot sleep should be 1m
<pedronis> not 1:30
<ogra> yeah, logs are fine ... i cant sent any signals when not logged in via ssh though
<ogra> the 1:30 is a systemd thing it adds when a process doesnt respond ... so perhaps thats even expected behaviour in the end
<ogra> (the red in the shutdown just caught my attention, and i dont see it on normal reboots)
<pedronis> ogra: well we stop the main loop and close sockets but setup a 1m  shutdown and sleep for 10 minutes
<pedronis> but now we have watchdog stuff
<pedronis> that might get upset about that
<pedronis> or we might hang before that (that would be a more serious issue)
<pedronis> anyway the log should tell us that
<pedronis> ogra: if the logs contains "Waiting for system reboot"   is just  some annoying behavior (we should still fix), if they don't it might be a more serious issue
<ogra> we'll see ... i have a VM set up with persistent logging now and will leave it idling in bg until it auto-reboots
<Chipaca> ogra: persistent logging and SNAPD_DEBUG?
<Chipaca> ogra: https://forum.snapcraft.io/t/extremely-slow-snap-downloads/4668/2?u=chipaca
<ogra> Chipaca, ah, not yet, do i set that in the systemd unit or is /etc</environment enough ?
<Saviq> mvo: hey, where can I find / file bugs for the core18 snap?
<pedronis> Chipaca: Waiting for system reboot is a Noticef
<Chipaca> ogra: if you don't mind seeing a lot of debug even from 'snap', setting SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=7 in /etc/environment would work also
<ogra> yeah, thats fine, i'll leave the VM idle anyway so there shouldnt be anything from snap commands
<Chipaca> pedronis: a'ight (but debug would tell us more, presumably)
<pedronis> Chipaca: yes
<pedronis> espcially if it's not there
<pedronis> though in the worst case not a lot,  then we would need to dump goroutines ideally
<ogra> Chipaca, another thing ... https://forum.snapcraft.io/t/snapd-is-now-doing-a-little-sanity-check-on-install/3566 ... could the technology behind this that rolls back or removes the snaps be hooked into install hooks somehow ? (tony will ask you about this later today i guess)
<ogra> so one could test for certain conditions via the install hook that prevent a snap to be installed at all on a system
<Chipaca> ogra: can't the install hook fail and abort the installation?
<ogra> Chipaca, that seems to not work as tony expects it ... i'll leave the core of the request to him, just wanted to trigger your brain to think about it ;)
<ogra> i just remembered that feature and was thinking that code is already there and could perhaps be wired up differently
<Chipaca> ogra: "exit 1" in the install hook causes the installation to abort
<Chipaca> just tried it
<Chipaca> ogra: I'll wait for tony before thinking much more about this :-)
<ogra> heh, ok
<ogra> diddledan, !!!! tvheadend !!!!
<ogra> (/me work on https://snapcraft.io/vdr-kiosk (still not done yet though, but i got it building with vc libs for the pi)
<ogra> diddledan, do you include oscam in the snap ?
<pedronis> mvo: should we close 5612 for now?
<mvo> pedronis: yeah, lets do that
<mvo> pedronis: fwiw, thiw bug hit CE, they added "core" but it was sorted too late
<mvo> pedronis: this happend while you were on vac
<mup> PR snapd#5612 closed: [RFC] image: do simple seed.yaml snap sorting <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5612>
<mvo> pedronis: this is why we added the following special case https://github.com/snapcore/snapd/pull/5610
<mup> PR #5610: image: ensure "core" is ordered early if base: and core is used <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5610>
<pedronis> mvo: as I said IÂ think we need to fix for bases like this, IÂ don't think we want to fix it like this for content providers, anyway we can chat tomorrow
<pedronis> but the fix needs to start in first boot code
<mvo> pedronis: yeah, lets talk tomorrow
<mvo> pedronis: ok
<pedronis> mvo: sorry, I just want to make sure we do something consistent and possibly simple (and also easy to remove if some bit is not needed anymore)
<mvo> pedronis: all good, we are in agreement :)
 * mvo dives back into understanding why autopkgtest on cosmic fails
<mup> PR snapcraft#2213 closed: Revert "ci: disable osx tests until a new pyyaml is released" <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2213>
<om26er> sitter: ping ?
<diddledan> ogra: I've not got oscam in there yet
<mup> PR snapcraft#2215 opened: provider changes <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2215>
<Voziv> Hi all, I'm getting "snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks" whenever I try tro run htop, slack, spotify, or PHPStorm snaps. This started happening after a reboot
<mup> PR snapd#5656 closed: debian: add missing breaks on cosmic <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5656>
<Voziv> I'm running on Ubuntu 18.04.1 and I noticed that my apparmor profiles lists "docker-default (enforce)", not sure if this is related
<mup> PR snapd#5660 opened: wayland: add extra sockets that are used by older toolkits (e.g. gtk3) <Created by gerboland> <https://github.com/snapcore/snapd/pull/5660>
<om26er> can I make a snap read/write for debugging ?
<diddledan> om26er: only if you keep the build locally, use `snap try` instead of `snap install foo_amd64.snap`
<mvo> ogra: did you say the pi2 dtbs from the bionic kernel are backward compatible. do I remember this right? so we could update the pi gadget with the latest dtbs without the world falling appart?
<mvo> ogra: or do I misremember that?
<Voziv> If I run "snap run slack" from my command line I also get "snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks"
<pedronis> mvo: did we have a fix for this ^ ?Â  or it needs z-yga ?
<mvo> pedronis: its a precaution - Voziv where do you see this error? what distro are you using and what does "snap version" output?
<mvo> niemeyer: it looks like I don't have repo access to "github.com/cm3-gadget" could you please add me so that I can write there?
<niemeyer> mvo: On it
<mvo> niemeyer: thank you
<Voziv> I see it after a reboot when trying to launch slack, phpstorm, or spotify. They simply don't launch. I see the error message when I either run it from the CLI (snap run slack), or in my syslog. I'm on Ubuntu 18.04.1
<Voziv> my snap version is 2.34.3 series 16, kernel 4.15.0-32-generic
<Voziv> I just did a "sudo systemctl restart apparmor" and now slack has launched successfully. Going to reboot my machine and see what happens again
<niemeyer> mvo: Done, hopefully
<mvo> niemeyer: \o/ works. thank you
<niemeyer> np, not sure why we have a separate team for those gadgets.. we should probably unify at some point
<mvo> niemeyer: +1
<ogra> mvo, i think you mis-remember ... i dont think 4.4 will bot with 4.15 dtb's
<ogra> *boot
<mvo> ogra: ok, thats fine as well
<mvo> ogra: a bit sad
<mvo> ogra: but fine
<ogra> mvo, well, try it .. but generally dtb's are not compatible between main version bumps (we had that issue initially when switching from 4.2 to 4.4 already ...) though the most reliable source here is indeed paolo (who isnt around)
<ogra> mvo, also the cm3-gadget source is at https://github.com/snapcore/cm3-gadget
<ogra> not sure what github.com/cm3-gadget is but surely not what we used
<jdstrand> Voziv: it sounds like the snap-confine profile didn't get loaded. there are forum topics on this and this is also something zyga has looked at
<ogra> niemeyer, ^^^ (teh gadget sources should all be owned by snapcore)
<Voziv> mvo, jdstrand: Post reboot results: https://gist.github.com/Voziv/9e9db4bd952f61b73f11267cd160627e
<niemeyer> There's no "snapcore" team
<ogra> oh, i thought the subdir there translates to a team ... LP spoiled me :P
<Voziv> I have no clue why restarting the app armor results in a different set of profiles being loaded
<Voziv> jdstrand: I did find several threads, but nothing really helped out with solving the problem, I kept getting the error, though now I have a reproducable way to get them working
<Voziv> I'll make a forum post with the gist results
<jdstrand> Voziv: so, that gist indicates that the apparmor unit isn't running on your system. docker will load its own profile, which is why it is showing up
<jdstrand> Voziv: you might look at 'sudo systemctl status apparmor' and 'sudo journalctl --unit=apparmor.service' after a reboot
<jdstrand> Voziv: otherwise look at journalctl for clues
<Voziv> hmm, you're right. It's disabled
<Chipaca> jdstrand: o/
<jdstrand> Chipaca: hey
<Chipaca> jdstrand: I'm not sure if you read about the hostname-control issue in 18.04
<Chipaca> jdstrand: I added what info I had to the PR that's failing
<mup> PR snapd#5661 opened: tests: normalize tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5661>
<Chipaca> jdstrand: that's #5593
<mup> PR #5593: tests: new test for hostname-control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5593>
<jdstrand> Chipaca: I saw you mentioned it yesterday and took a note to look at it (wanted to yesterday)
<Chipaca> jdstrand: ah ok
<Chipaca> jdstrand: that's all i ask :-)
<jdstrand> Chipaca: it is one of just a handful of things I need to look at before I get back to pedronis. really hoping for today Samuele! :)
<mvo> ogra: do you happen to know if the dragonboard also need firmware upgrades to work with the 4.15 kernels?
<ogra> mvo, i dont think so ... the dragonboard FW should be independent from the kernel
<mvo> ogra: excellent
<ogra> mvo, the pi FW is fully backwards compatible though (unlike the dtbs that must come from the kernel deb)
<mvo> ogra: what about the dtbs from the dragonboard? does it need one? does that needs updating?
<ogra> so just make sure your git pull is new enough for that
<ogra> mvo, dtbs on dragonboard are coming from the kernel snap
<ogra> only the pi ships them in gadget
<ogra> (and it is the only system that does that to my knowledge)
<ogra> (due to the fact that the binary blob needs to read them from vfat directly)
<mvo> ogra: great
<mvo> ogra: so no issues there hopefully
<ogra> yeah, only pi is painful
<ogra> mvo, hmm, any reason why you grep for linux-modules instead of linux-image in your change ?
<mvo> ogra: yeah, the dtbs moved
<ogra> rae the dtb's in bionic not shipped in linux-image anymore ?
<ogra> urg
<diddledan> this is a fun one https://github.com/canonical-websites/snapcraft.io/issues/1021
<ogra> so if i would install without using modules i wouldnt get a bootable install ?
<ogra> thats a weird decision
<ogra> but well :)
<mvo> ogra: I have no insight in this, but when I tried to build the snap I noticed it (that was a couple of days ago when I updated the universal pi snap)
<ogra> mvo, yeah, will only harm people that create their rootfs manually .... it just feels weird that you can install linux-image (the kernel) without -modules and then end up without any dtbs
<ogra> mvo, looked over all pi gadget changes and approved them ...not sure if you want to wait for additional ondra approval too
<ogra> they look all fine to me
<pedronis> jdstrand: was about to ping actually :)
 * jdstrand nods
<mvo> ogra: I need to wait for the channel creation on the store side anyway
<mvo> ogra: so no problem
<ogra> well, the have ondra take a look too, 4 eyes etc ;)
<ogra> *then
 * cachio lunch
<Chipaca> mvo: question about core in the beta channel: does 5275 (from 17:51z today) include the proxy+vault fix?
<Chipaca> oh wait no
<Chipaca> it's from 17:51z yesterday
<Chipaca> so, no it doesn't
<Chipaca> kthx
<diddledan> glad I could help, Chipaca
<Chipaca> diddledan: I'm just happy to be in such capable hands
<diddledan> :-D
<mup> PR snapd#5662 opened: tests: avoid using the journalctl cursor when it has not been created yet <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5662>
 * Chipaca going afk for a while
<Chipaca> cachio: does 5662 mean you found the problem with the cursors?
<Chipaca> haven't looked yet, will look when i get back
<Chipaca> but, woo
<cachio> Chipaca, it is a problem
<cachio> Chipaca, it is not "the problem"
<cachio> I am still researching a problem with some info not found in the journal
<mup> PR snapcraft#2216 opened: spread tests: keep sources local <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2216>
<cachio> Chipaca, are you looking this test which is failing? TestFullDeviceRegistrationHappyWithHookAndNewProxy
<cachio> mvo, do you?
<pedronis> cachio: where? on master?
<cachio> yes
<cachio> pedronis, https://api.travis-ci.org/v3/job/416382933/log.txt
<pedronis> yes, this is from a recent branch from Chipaca
<pedronis> it might just be a combination with the change mvo did
<pedronis> on a different branch
<cachio> pedronis, yes, all the branches are failing now because of this test
<pedronis> yea
<pedronis> I see
<pedronis> it's mvo code vs Chipaca tests
<pedronis> fix is easy
<pedronis> one sec
<cachio> pedronis, great, thanks
<mup> PR snapd#5663 opened: overlord/devicestate: fix tests, set seeded in registration through proxy tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/5663>
<pedronis> cachio: fix ^
<pedronis> I suspect it also needs backporting to 2.35
<cachio> pedronis, tx
<mvo> Chipaca: do you need a core with the fix? I can build you one
<mvo> pedronis: \o/ thanks for the fix
<Chipaca> mvo: we already have one AFAIK: edge was built after this landed in master
<Chipaca> mvo: unless by 'this fix' you mean 5663 (in which case no, because it's just tests that change)
<Chipaca> mvo: if you mean a 2.35 with the fix, I think they just want to be sure that 2.35 includes it, not that they need it for testing at this time
<Chipaca> cachio: I wasn't because I wasn't here :-)
<Chipaca> and I'm about to not be here again (went for a run, now going to the supermarket)
<Chipaca> (dog is hopeful supermarket includes a walk)
<Chipaca> (dog is right to be hopeful)
<mvo> Chipaca: yeah, was wondeirng if you need a build to test this
<mvo> Chipaca: but it sounds like no
<mvo> Chipaca: iirc I cherry picked it already into 2.35
<Chipaca> mvo: yes, you did
<Chipaca> mvo: it's just not built yet
<mvo> Chipaca: ok
<Chipaca> mvo: the people waiting have been informed as much
<mvo> Chipaca: they should just use edge, thats a fine channel anyway :)
<Chipaca> yep yep
<cachio> niemeyer, hey, some machines in gce are being created on us-west1-b	
<cachio> niemeyer, ug131404-380926 and aug131603-777502		
<cachio> created by travis?
<cachio> are you aware of this?
<cachio> I think are vms of snapcraft
<cachio> the problem is that our garbage collection is not gonna clean them
<cachio> because of the different zone
 * cachio afk
<niemeyer> cachio: We don't limit, so people might be firing on other regions.. it doesnt make much sense if it's for Travis though
<niemeyer> cachio: We'll need to cover other regions on cleanup either way
<Chipaca> oh, fun
<Chipaca> mvo: #1787254 in case you weren't aware
<mup> Bug #1787254: Possibly demote fwupdate to universe? <fwupdate (Ubuntu):New> <fwupdate-signed (Ubuntu):New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1787254>
<cachio> niemeyer, ok
<jdstrand> tyhicks: hey, would you mind taking a look at my comments here: https://github.com/snapcore/snapd/pull/5593#issuecomment-413333946
<mup> PR #5593: tests: new test for hostname-control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5593>
<tyhicks> jdstrand: hey - can't right now - getting pulled into a regression fix bug
<jdstrand> tyhicks: it has to do with AssumedAppArmorLabel= and dbus activated services
<jdstrand> ok
<tyhicks> jdstrand: I got the email notification and will look as soon as I can
<jdstrand> tyhicks: thanks
<Caelum> zyga: hey you're back, I want to help fix the gentoo overlay
<Caelum> zyga: I'll help get the opensuse stuff finished too at some point
<mup> PR snapd#5664 opened: interfaces: workaround for activated services and newer DBus <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5664>
<mup> PR snapcraft#2217 opened: Travis test <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2217>
<mup> PR snapcraft#2216 closed: spread tests: keep sources local <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2216>
#snappy 2018-08-16
<mup> PR snapcraft#2214 closed: sentry: support disabling error reporting <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2214>
<mup> PR snapcraft#2215 closed: provider changes <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2215>
<mup> PR snapd#5665 opened: tests: set ubuntu-core-18 as manual <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5665>
<mup> PR snapd#5663 closed: overlord/devicestate: fix tests, set seeded in registration through proxy tests <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5663>
<mborzecki> morning
<mvo> hey mborzecki, good morning
<mborzecki> mvo: hey, you're up early
<mvo> mborzecki: yeah, a one-off
<mborzecki> mvo: did i miss anything interesting yday?
<mvo> mborzecki: not that much, a bit of thinking about what the best place for the udevmonitor is in the code, but that is more something for pawel. master is broken right now, thats not good (core18 seems to be not booting)
<mvo> mborzecki: but other than that it was relatively tame
<mborzecki> mvo: master broken, how so?
<mvo> mborzecki: yesterday two PRs got merged that had subtle interrelatiations
<mvo> mborzecki: which broke unit tests
<mborzecki> mvo: is the fix on review already? anyting i can help with?
<mvo> mborzecki: tests are fine again, samuele fixed those last night
<mvo> mborzecki: but spread is unhappy
<mvo> mborzecki: because of core18
<mvo> mborzecki: no idea why yet, there was a new kernel yesterday and of course a new snapd
<mvo> mborzecki: so maybe one of those broke things
<mborzecki> mvo: aah interesting
<mvo> nice (ish) - "error: invalid xz chunk" in early boot
<mborzecki> mvo: initramfs is xz compresses?
<mvo> mborzecki: yes and the kernel itself too iirc
<mborzecki> mvo: uboot then? or is it amd64?
<mvo> mborzecki: amd64
<mborzecki> mvo: https://github.com/kdave/grub/blob/master/grub-core/fs/squash4.c#L348
<mvo> mborzecki: the initrd seems to be the issue https://paste.ubuntu.com/p/zYBWc8rkZT/
<mvo> mborzecki: the kernel itself is gzip compressed
<mborzecki> mvo: i guess decompressing it locally works right?
<mvo> mborzecki: yes
<mvo> mborzecki: but that is with xz/unxz
<mvo> not the grub code
<zyga> Good morning!
<zyga> New backdrop, day one :-)
<mvo> zyga: good morning
<zyga> :-)
<zyga> First day of real work after returning
<zyga> Is anything on fire?
<mvo> zyga: core18 is not booting but the kernel was just reverted so hopefully it will be RSN
<zyga> In GCE or everywhere?
<mborzecki> zyga: hey
<mborzecki> mvo: there are some PRs that could land
<mvo> mborzecki: which ones
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/5657
<mup> PR #5657: interfaces: add cpu-control for setting CPU tunables <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5657>
<mvo> mborzecki: cool
<mborzecki> mvo: this is real simple one https://github.com/snapcore/snapd/pull/5640
<mup> PR #5640: tests: skip unsupported architectures for fedora-base-smoke test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5640>
<mborzecki> mvo: this one too https://github.com/snapcore/snapd/pull/5651
<mup> PR #5651: cmd/libsnap: unify detection of core/classic with go <Created by zyga> <https://github.com/snapcore/snapd/pull/5651>
<zyga> I will begin the day with code reviews
<mborzecki> https://github.com/snapcore/snapd/pull/5662 i'll restart the build in this one
<mup> PR snapd#5657 closed: interfaces: add cpu-control for setting CPU tunables <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5657>
<mup> PR snapd#5658 closed: interfaces: add cpu-control for setting CPU tunables (2.35) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5658>
<mup> PR #5662: tests: avoid using the journalctl cursor when it has not been created yet <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5662>
<mborzecki> mvo: fwiw this one can land too https://github.com/snapcore/snapd/pull/5645
<mup> PR #5645: tests: new test for udisks2 interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5645>
<mup> PR snapd#5645 closed: tests: new test for udisks2 interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5645>
<mup> PR snapd#5665 closed: tests: set ubuntu-core-18 as manual <Created by sergiocazzolato> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5665>
<mvo> mborzecki: 5635 should be an easy win
<mup> PR snapd#5631 closed: snapstate: ensure normal snaps wait for the "snapd" snap on refresh <Core18> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5631>
<mup> PR snapd#5635 closed: tests: enable lxd again everywhere <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5635>
<mborzecki> coffee time
<pstolowski> heyas
<zyga> good morning pawel :)
<mvo> hey pstolowski
<pstolowski> mvo: hey! thanks for the feedback on udev mon!
<mborzecki> pstolowski: hey
<pedronis> mvo: hi,  how are things?  let me know when you think we can chat
<mvo> pedronis: just dealing with some autopkgtest failures, after that should be fine, so maybe in ~1h ?
<pedronis> ok, great
<mup> PR snapd#5666 opened: tests: fix autopkgtest failures in cosmic <Created by mvo5> <https://github.com/snapcore/snapd/pull/5666>
<zyga> good morning pedronis :)
<Chipaca> mvo: morning
<mvo> Chipaca: good morning
<Chipaca> mvo: who amongst us knows of our use of fwupdate? you, ogra, ...?
<mvo> Chipaca: I don't, but probably field engineering
<mvo> Chipaca: iirc its just in some of their devices
<Chipaca> mvo: asking because people are asking to drop it from main, replacing it wiht fwupd
<zyga> hey Chipaca
<zyga> Chipaca: interesting
<zyga> we used one vs the other a while ago because of a customer request
<Chipaca> zyga: on core itself, or in images for that customer?
<Chipaca> core itself doesn't ship it
<zyga> I think it's an image with extra tooling
<Chipaca> that is, http://cdimage.ubuntu.com/ubuntu-core/16/ doesn't have it :-)
<zyga> but my memory is rusty now
<Chipaca> zyga: mvo: https://bugs.launchpad.net/ubuntu/+source/fwupdate/+bug/1787254/comments/7
<mborzecki> zyga: hah, so you've rewritten your memory in Rust?
<Chipaca> mborzecki: I think he meant 'rustig'
<zyga> mborzecki: I cannot remember since you hold onto that idea now
<mborzecki> zyga: it's outlived by other memories
<mborzecki> Chipaca: i'm sure this one would interest you too https://github.com/snapcore/snapd/pull/5667
<Chipaca> DENIED
 * Chipaca marks everything CHANGES REQUESTED today
<mborzecki> Chipaca: may i offer you some cookies? :)
<Chipaca> NO
<Chipaca> yes
<mborzecki> denied :)
 * Chipaca goes to make his own cookies, with blackjack and â¦ hooks? chocolate jack daniels hook cookies?
<mborzecki> so go 1.11 changes gofmt slightly?
<Chipaca> mborzecki: why the change to the instancekey?
<zyga> mborzecki: oh, that would be fun
<niemeyer> mup is back.. I still need to fix its identifying logic with nickserv so that he can speak here when he logs back in
<niemeyer> mup: You ok, right?
<mup> niemeyer: I apologize, but I'm pretty strict about only responding to known commands.
<niemeyer> mborzecki: That happened in other releases of gofmt as wlel
<mborzecki> niemeyer: this one is quite subtle https://talks.godoc.org/github.com/mvdan/talks/2018/go1.11.slide#6
<Chipaca> mborzecki: no more winxp support /o\ !!!
<niemeyer> mborzecki: Weird.. I don't recall seeing the first case I think
<niemeyer> Ah, maybe because I already split out the long names anyway so it's visually nicer
<niemeyer> I've fired a new review board:
<niemeyer> https://forum.snapcraft.io/t/review-sprint-6/6901
<Chipaca> what does "Last release where godoc has a command-line interface" mean? 'godoc' is going away?
<ogra> Chipaca, try cyphermox ... not sure who in field has any knowledge here, probably tony and alfonso
<niemeyer> I know some of you are already on a review sprint somewhat, so just keep going :)
<Chipaca> ogra: I'll chat with tony later, i think
<ogra> +1
<niemeyer> Chipaca: godoc vs. go doc
<Chipaca> niemeyer: but 'go doc' sucks :-/
<Chipaca> bah
<Chipaca> maybe in .11 'go doc' grows an http server mode and all is well
<mup> PR snapd#5662 closed: tests: avoid using the journalctl cursor when it has not been created yet <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5662>
<niemeyer> Chipaca: I doubt.. that's the opposite of what happened
<niemeyer> Chipaca: It used to have an http server
<niemeyer> Right now it's a CLI, which isn't going away as I understand it
<niemeyer> While godoc remains the web server
<niemeyer> Doesn't seem bad..?
<Chipaca> niemeyer: right, but 1.11 is the "last release where godoc has a command-line interface"
<niemeyer> Chipaca: Yeah, that's the subject.. :)
<Chipaca> niemeyer: a command-line interface is how I launch the http server
<niemeyer> Chipaca: go doc will still have the CLI.. godoc will still have the web UI
<Chipaca> niemeyer: if it doesn't have a command-line interface, it's just a library (or a gui app?)
<niemeyer> Chipaca: Ah, one of us misunderstands.. I think what's going away is the text output
<Chipaca> I'm fine with that. I hope it's that.
<niemeyer> Chipaca: Of godoc.. it remains a web server
<niemeyer> Chipaca: https://tip.golang.org/doc/go1.11 =>
<Chipaca> OTOH, we won't be using .11 until NEVER
<niemeyer> "Go 1.11 will be the last release to support godoc's command-line interface. In future releases, godoc will only be a web server. Users should use go doc for command-line help output instead. "
<mvo> Chipaca: sorry was in a meeting, I have a look at 1787254
<Chipaca> niemeyer: phew
<Chipaca> niemeyer: also! also! The godoc web server now shows which version of Go introduced new API features. <3
<niemeyer> Chipaca: Oh, sweet!  Is there standard syntax we can use to tag our APIs?
<Chipaca> niemeyer: I just read that bit, no idea :-)
<Chipaca> niemeyer: it doesn't seem to be done with synta
<Chipaca> x
<niemeyer> Aww
<mborzecki> https://github.com/snapcore/snapd/pull/5640 is an easy win
<mup> PR #5640: tests: skip unsupported architectures for fedora-base-smoke test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5640>
<mup> PR snapd#5640 closed: tests: skip unsupported architectures for fedora-base-smoke test <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5640>
<mup> PR snapd#4951 closed: interfaces: add screencast-legacy for video and audio recording <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4951>
<ogra> Chipaca, pedronis https://pastebin.canonical.com/p/fZ29ck4wfG/ (sorry for the secured pastebin, not sure there is confidential info in the logs)
<ogra> this is from this mornings auto-refresh ... sadly i cant tell if the 1:30 timeout happened there since i was sleepig when it happened
<pedronis> I see,  the logs looks regular there's as many "Waiting for system reboot" as there are "Requested system restart"
<ogra> yeah, and the timestamps indicate that there was no 1:30 timeout
<pedronis> so at leasr from snapd own point of view, is shutting down as expected
<ogra> right ...
<ogra> i guess i'll have to wait for another one where it actually happens :(
<ogra> this is annoying, i have seeen it a lot and on all my VMs for days ... typically if the core update happens right after booting up though
<mup> PR snapd#5667 closed: store: backward compatible instance-key handling for non-instance snaps <Parallel installs> <Squash-merge> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5667>
<ogra> i'll make sure to leave one VM off tonight so it does the refresh immediately after boot tomorrow
<mup> PR snapd#5668 opened: store: backward compatible instance-key handling for non-instance snaps (2.35) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5668>
<mborzecki> mvo: ^^ a backport of 5667 for 2.35
<mvo> mborzecki: thank you
<niemeyer> pstolowski: #4767 has reviews
<mup> PR #4767: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>
<pstolowski> niemeyer: yes, thanks, i've almost finished addressing the new comments
<niemeyer> pstolowski: Sorry, I meant to say I just had new ones too
<pstolowski> niemeyer: ah, ok, i saw mvo's comments only, allright
<mup> PR snapcraft#2218 opened: many: replace yaml.safe_load() with CSafeLoader <Created by chipaca> <https://github.com/snapcore/snapcraft/pull/2218>
<mup> PR snapd#5668 closed: store: backward compatible instance-key handling for non-instance snaps (2.35) <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5668>
<niemeyer> zyga: #5307 reviewed
<mup> PR #5307: cmd,interfaces,tests: add mnt interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5307>
<zyga> thanks
<mup> PR snapd#5659 closed: tests: remove manual from openvswitch test <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5659>
<zyga> niemeyer: thank you, I'm going through another review now but I'll address this one today
<niemeyer> zyga: Thanks!
<mup> PR snapd#5561 closed: overlord/snapstate: parallel snap install <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5561>
<mup> PR snapd#5669 opened: asserts,image: support gaget tracks in the model assertion <Created by mvo5> <https://github.com/snapcore/snapd/pull/5669>
<mvo> mborzecki: btw, does 5596 have spread tests for parallel installs already? would be cool to add there to see itin action
<cachio> mvo, hey
<cachio> what did you do to fix core-18 builds?
<mvo> cachio: I asked the kernel team to revert to r137 of the pc-kernel snap
<mvo> cachio: the r140 version breaks
<mvo> cachio: its not clear yet why sadly
<cachio> mvo, ahhh, nice
<mvo> cachio: but I was able to reproduce locally and I saw the grub failure in my qemu run
<mvo> cachio: I ran with SPREAD_QEMU_GUI=1 which made it easier (I think serial port would probably also have worked, but not sure)
<cachio> mvo, I though it was a problem with the image
<cachio> with a dependency
<cachio> but didn't realize it was the kernel snap
<cachio> nice catch
 * niemeyer lunches
<mvo> cachio: yeah, it was very non-obvious what triggered it :/ I looked at the recent changes and noctied the kernel snap update from a couple of hours ago
<mborzecki> mvo: the spread tests require a bit most stuff in the master branch
<mborzecki> mvo: i'll be opening another bit after we're done with the review sprint
<mvo> mborzecki: oh, we are in a review sprint?
<mborzecki> mvo: shh, dont' tell anyone :P https://forum.snapcraft.io/t/review-sprint-6/6901
<mvo> mborzecki: hm, 2h ago? now I don't feel so bad anymore for not reading the memo in time
<mvo> ogra: fwiw, I also updated the pi* builds to use the bionic chroots (to be consistent with the whole ubuntu 18 idea :)
<ogra> mvo, makes sense for core 18 indeed
<mvo> ogra: lets hope no subtle issues come up
<ogra> mvo, well, you need to solve the update issues with dtb''s and firmware files in the gadget
<mvo> ogra: you mean for upgrades? yeah, that is going to be "fun"
<ogra> mvo, but IIRC you and niemeyer worked out plas for that with ondra, so i guess we're fine (are we ?)
<ogra> yeah
<ogra> 16 to 18 gadget upgrades
<ogra> s/plas/plans/
<mborzecki> zyga: could you take a look at https://github.com/snapcore/snapd/pull/5654 later on?
<mup> PR #5654: cmd/snap-confine: establish snap directory mappings for parallel instances <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5654>
<mup> PR pc-amd64-gadget#8 opened: snapcraft.yaml: bump version number <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/8>
<zyga> mborzecki: yes, added to my queue :)
<mborzecki> zyga: great, thanks
<mup> PR pc-i386-gadget#6 opened: snapcraft.yaml: bump version number <Created by mvo5> <https://github.com/snapcore/pc-i386-gadget/pull/6>
<mup> PR pc-i386-gadget#6 closed: snapcraft.yaml: bump version number <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/pc-i386-gadget/pull/6>
<mup> PR pc-amd64-gadget#8 closed: snapcraft.yaml: bump version number <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/8>
<ogra> niemeyer, since you were asking for non-dismissive arguments regarding the unified pi gadgets, i'd appreciate if you could read https://forum.snapcraft.io/t/model-assertions-for-core18/6870/6 (if you did not read it yet) ... note that i do not expect an answer or change of the decision and i will let the topic rest, but i'd at least like that the decision making parties know all the technical backgrounds
<mup> PR snapd#5670 opened: daemon, overlord/snapstate: set instance name when installing from snap file <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5670>
<pstolowski|lunch> mvo: would you like to have another look at https://github.com/snapcore/snapd/pull/4767 or can i land?
<mup> PR #4767: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>
<mup> PR snapd#5636 closed: snap: fix advice json <Squash-merge> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5636>
<zyga> pstolowski|lunch: updated https://github.com/snapcore/snapd/pull/5651
<mup> PR #5651: cmd/libsnap: unify detection of core/classic with go <Created by zyga> <https://github.com/snapcore/snapd/pull/5651>
<mup> PR snapd#5666 closed: tests: fix autopkgtest failures in cosmic <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5666>
<mvo> pstolowski|lunch: sure, I check the disconnect hooks PR now
<mvo> nice, down to 39 prs
<niemeyer> Go go! :)
 * Chipaca goes
<pstolowski> zyga: thanks
<mvo> niemeyer: I have a conflicting meeting today, I will see if I can leave it early and may join later
<mvo> niemeyer: one important piece for the standup is that we need to figure out why r140 of the pc-kernel snap does not boot
<mup> PR snapd#5651 closed: cmd/libsnap: unify detection of core/classic with go <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5651>
<zyga> jdstrand: I have some questions about the changes to dbus wrt apparmor, when would be a good time to ask you some of those?
<jdstrand> zyga: hey, ask away
<zyga> jdstrand: thanks, I'll write my questions down and paste after the standup
<Chipaca> mvo: https://www.amazon.co.uk/dp/B003U4NO7Y
<mvo> Chipaca: heh, the moto of my life
 * zyga runs for lunch
<Chipaca> niemeyer: https://forum.snapcraft.io/t/defer-snapd-refresh-on-wake-from-suspend/4943?u=chipaca
<niemeyer> Thanks
<mup> PR snapd#5671 opened: tests: basic test for parlalel installs from the store <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5671>
<Chipaca> mborzecki: for what installs?
<Chipaca> :-)
<mborzecki> Chipaca: plaplapel
<mborzecki> :)
<mborzecki> niemeyer: https://github.com/snapcore/spread/pull/67 that's the MATCH fix
<mup> PR spread#67: spread: run MATCH in a subshell <Created by mvo5> <https://github.com/snapcore/spread/pull/67>
<niemeyer> mborzecki: Thanks! Let me merge that and release it
<niemeyer> mborzecki: Please give it a shot
<mvo> pstolowski: could you please check https://github.com/snapcore/snapd/pull/4767#discussion_r210180691 - I wonder if the name of the test still matches what is done given that its now a (retry) error
<mup> PR #4767: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>
<pstolowski> mvo: i'm sorry, i think i missed it, checking
<mvo> pstolowski: thanks! one more https://github.com/snapcore/snapd/pull/4767/files#r195361520 - i think GH was hidding those from you :) I had to manually expand
<mup> PR #4767: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>
<mvo> pstolowski: if you need to do code change give me a shout and I send a diff to you, but only then, its not super important but if it does a full test run anyway I might as well propose my diff
<pedronis> mborzecki: in your task/todo sequencing when are you thinking of attacking alias code and other places that assume snap-id <-> 1 snap
<pedronis> ?
<mup> PR snapcraft#2219 opened: Release changelog for 2.43 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2219>
<niemeyer> Taking a break here
<pstolowski> mvo: grr, indeed, thanks. i'm not sure why i missed them, i'm pretty sure i looked at the 'files' tab, not 'conversation'
<pstolowski> mvo: pushed
<mvo> pstolowski: no worries
<mvo> pstolowski: thank you
<pstolowski> i hope travis is still in good and cooperative mood today ;)
 * pstolowski is knocking the wood
<pedronis> mvo: btw some of the tasks/todo we discussed this morning were mentioned here:  https://forum.snapcraft.io/t/seeding-snaps-that-plug-the-content-interface/5579/3
<cachio__> niemeyer, about the secrets for the spread cron project
<cachio__> niemeyer, what can I do for that?
<mborzecki> pedronis: up next is adding mkdir of for snap name in handlers code when instance one is installed and cleanup, then i plan to look into aliases and the store hash stuff after that
<mborzecki> pedronis: that's paralell to stuff being landed which happens at it's own pace
<pedronis> mborzecki: ok, there might be more code that has similar issues as aliases, we can discuss when you get to alias stuff
<mborzecki> pedronis: ack
<mborzecki> pedronis: off the top of your head do you recall what that might be?
<pedronis> mborzecki: refreshing assertions and relatedly refresh-control/validation code
<pedronis> in some cases might just be that we do things too many times (instead of once), other they might be bug
<pedronis> mborzecki: as I said, its code that is sort of assuming that  one snap id <->  1 snap so far
<mvo> pedronis: nice, thank you
<pedronis> mborzecki: also Update code might have that problem
<Chipaca> niemeyer: I went through all your feedback on the snapshotstate pr and replied (but I didn't have any argument with any of it, it's all "yep, done")
<pedronis> or maybe you fixed that already
<mborzecki> pedronis: as in snapstate.Update?
<pedronis> UpdateMany
<pedronis> mborzecki: this kind of code:   snapst := stateByID[update.SnapID]
<pedronis> seems to still be there
<mborzecki> pedronis: yeah, see that, ok, so that piece is up next then
<pedronis> mborzecki: so there is various code like that
<pedronis> in the places IÂ mentioned
<pedronis> most of it I think is close/around Update/UpdateMany
<mborzecki> pedronis: thanks, noted that down
<pedronis> mborzecki: it mostly lives in snapstate and assertsstate I think
<mborzecki> wish i had a tool to integrate org-mode notes with the forum :) hopefully's niemeyer will fill that gap
 * cachio__ lunch
<mup> PR snapd#5672 opened: tests: make nfs test available for more systems <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5672>
<mvo> jdstrand: if you have a moment, a comment on https://github.com/snapcore/snapd/pull/5615#discussion_r210516258 would be great, not sure if its worth persuing or if I should land as is and just iterate if the people using it have problems (i.e. if those are symlinks for them as well)
<mup> PR #5615: interfaces: add new "sysfs-name" to i2c interfaces code <Created by mvo5> <https://github.com/snapcore/snapd/pull/5615>
<mup> PR snapd#4767 closed: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4767>
<jdstrand> mvo: commented
<mvo> jdstrand: ta!
<pstolowski> woot, yay \o/
<mup> PR snapd#5673 opened: ifstate: extra common code into checkAutoConflicts() <Created by mvo5> <https://github.com/snapcore/snapd/pull/5673>
<mvo> pstolowski: yeah, good stuff!
<jdstrand> zyga: you mentioned something about a list of questions after a meeting?
<zyga> jdstrand: re, yeah sorry I just got carried away by things I was doing locally
<zyga> jdstrand: so I was looking at that PR that reacts to dbus changes
<zyga> jdstrand: and I wasn't quite sure how some of the actual differences made by the patches fit into labelling and activation
<zyga> jdstrand: let me pull up an example
<mup> PR snapd#5615 closed: interfaces: add new "sysfs-name" to i2c interfaces code <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5615>
<jdstrand> zyga: it might help if I mention that clients don't have to do anything to activate a service, they just start using it. how they start is client dependent
<jdstrand> zyga: hostnamectl does via a GetAll(). I know others do Introspect()
<zyga> right, I see
<jdstrand> zyga: so I just focused on those rather than discarding the label check entirely
<zyga> jdstrand: as a quick patch in the branch let's look at https://github.com/snapcore/snapd/pull/5664/commits/64ea1623b9b383cd649da48d315e54bc56d37822 - I was expecting to see removal of peer=(label=unconfined), instead there is some more logic
<jdstrand> zyga: figuring if we get a bug, we would address it
<mup> PR #5664: interfaces: workaround for activated services and newer DBus <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5664>
<jdstrand> zyga: I added Get and GetAll proactively
<zyga> I also don't understand why some have send and some both send and receive
<zyga> aha
<jdstrand> zyga: they should be send
<jdstrand> I can fix that
<zyga> so I can expect various patches to add Introspect and Get, GetAll
<zyga> like this one https://github.com/snapcore/snapd/pull/5664/commits/06f8e5b7f0e33c454b2ea8516958d61cca39761a
<mup> PR #5664: interfaces: workaround for activated services and newer DBus <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5664>
<jdstrand> zyga: well, each interface is slightly different. I noticed in that interface there was only the Inhibit rule, no Get, GetAll or Introspect, so I updated it
<zyga> jdstrand: ok, with the send vs receive resolved and with your explanation on new methods I think I understand what this is doing
<zyga> thanks, I will approve it now
<jdstrand> zyga: I'll check for receive/send and make sure it is correct. it is likely just in a couple of places where I copied a broad send/receive rule to a particular path and forgot to remove the receive
<t1mp> hello
<zyga> hey t1mp
<t1mp> question: why is snapcraft trying to pull my package wheel file from PyPI, if I built that in a previous part with the python plugin?
<zyga> kyrofa, sergiusens: ^
<t1mp> hmm, let me check something, maybe I have that explicitly defined somewhere :)
<ogra> because you didnt feed enough cake to snapcrafts AI ?
<niemeyer> Chipaca: Thanks!
 * Chipaca checks his pockets
<t1mp> ogra: yeah, probably something like that :)
<ogra> :)
<Chipaca> niemeyer: you're welcome!
<sergiusens> t1mp: maybe it is not on the expected path.
<t1mp> I didn't want to build the python wheel file in snapcraft actually because I did that in a previous stage on jenkins. But I don't see a way to use a local .whl instead of pulling it from PyPI, except building it in an earlier stage
<jdstrand> mvo: oh, I was surprised you merged PR 5615...
<mup> PR #5615: interfaces: add new "sysfs-name" to i2c interfaces code <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5615>
<sergiusens> t1mp: pip has some rules that if you download the wheel to specific locations would satisfy the dependency
<sergiusens> but I will need to forward you to a search engine to find that path.
<jdstrand> mvo: I commented here https://github.com/snapcore/snapd/pull/5615#discussion_r210643334 - that is what I meant before. sorry if I was unclear
<t1mp> sergiusens: ah ok, that might be useful. I think that is something to put in the pip config file, which I could just copy into the snap
<t1mp> thanks :)
<mvo> jdstrand: I replied via mail, apparently someone looked at this and considered it okay
<jdstrand> ah. I'm still slogging through email
<mvo> jdstrand: I'm not sure it is but even if it is not I will have to add one extra commit
 * jdstrand nods
<mvo> jdstrand: so if I add the commit now or later seems to be the same, testing it as is leaves the (small) chance it may actually be not symlinks in the kernel they use
<mvo> jdstrand: but if its symlinks and its not stable we have a problem :(
<jdstrand> mvo: it might not be so bad. depends on what the target is
<mvo> jdstrand: aha, if its always the same range you mean? yeah, then it will be okay
<jdstrand> mvo: eg, maybe /sys/devices/**/i2c/<name>/** or something
 * mvo nods
<jdstrand> the /sys/devices/**/ would be the non-deterministic part, but we could glob that away
<jdstrand> at least, that is my hope :)
<mvo> jdstrand: yeah, it appears to be like this on amd64 at least so I should probably do the followup in any case to make this useful on amd64
<mvo> jdstrand: but dinner first :) thanks for your input, thats good stuff
<jdstrand> mvo: enjoy! :)
<mvo> jdstrand: I added a comment and will work on it later/tomorrow.
<mvo> ttfn
<jdstrand> mvo: thanks! :)
<pedronis> Chipaca: not sure exactly what you are struggle on, but gave one of the examples I had in mind
<pedronis> *struggling on
<Chipaca> pedronis: thank you
<Chipaca> pedronis: I probably just need a break
<Chipaca> pedronis: :-)
<Chipaca> also i need to stop context-switching like a deranged chipmunk
<Chipaca> pedronis: as for you, go away :-) let's talk tomorrow if I'm still stuck.
<om26er> alan_g: Hello!
<alan_g> om26er, hellp
<om26er> alan_g: This tutorial is useful https://tutorials.ubuntu.com/tutorial/graphical-snaps#0 but is there a more "complete" one that actually launches a Qt/Gtk based app on UbuntuCore system ?
<om26er> we have a snap that works fine on wayland desktop and are looking to make that a kiosk-mode app.
<alan_g> om26er, not yet. But there's an example: https://forum.snapcraft.io/t/shipping-later-qt-with-snap/6873
<om26er> alan_g: how far along is Mir/Wayland on UbuntuCore being "production" ready ?
<om26er> for now we are doing a demo but I believe if this goes well, we'll be doing a full-blown product, so wanted to know.
 * zyga -> walk
<alan_g> om26er, Basically, it works now. There's one thing we want to iron out, but that shouldn't worry you: https://community.ubuntu.com/t/snaps-and-sharing-mirs-wayland-socket/7539/1
<alan_g> greyback, is working on that, and will update and extend the tutorials "real soon now".
<greyback> om26er: hey, I'll share something like that when I've all theekinks ironed out
<om26er> also the "layouts" feature is also experimental, though I hope it'll graduate some time soon ?
<om26er> greyback: that'd be helpful. I am currently trying to run a PySide2 (Qt for Python) app on a UbuntuCore based system. namely Siemen's SIMATIC ipc327e.
<om26er> it runs on my wayland session (desktop) (fully confined)
<greyback> om26er: ack. What version of Qt are you using?
<om26er> greyback: Qt 5.11, its shipped with PySide's .whl
<om26er> source https://download.qt.io/snapshots/ci/pyside/5.11/latest/pyside2/?C=M;O=D
<greyback> om26er: ok, good, it's nice and new. That shouldn't have any issues with Mir
<Chipaca> pedronis: I was not adding the taskset to a change. Can I have a dunce emoji?
<alan_g> om26er, BYW if you need to test with a Mir based Wayland session there's https://snapcraft.io/egmde
<pedronis> Chipaca: ah, couple of methods of state don't return tasks unless they are attached to a change
<om26er> cool my snap PySide2 snap works in egmde session.
<om26er> s/snap//
<cachio> kyrofa, hey
<niemeyer> cachio: We can see the spead-cron issue soon if you'll be around
<cachio> niemeyer, yes
<cachio> just ping me
<niemeyer> Cool
<kyrofa> Hey there cachio
<cachio> kyrofa, hey, quick question, are you setting travis for snapcraft on gce west zone?
<cachio> I saw some instances on us-west1-b yesterday
<kyrofa> cachio, indeed I am, west1-b
<kyrofa> Yep, probably us
<cachio> kyrofa, ahh, could you please use the us-east1-b for travis?
<cachio> so machines with more than 2 hours will be automatically removed
<kyrofa> Ah, we only garbage collect that region eh? Sure, we can switch
<cachio> yes, it is by region
<cachio> thanks
<Chipaca> niemeyer: snapshotstate is ready for a look
<mborzecki> cachio: you around? left a note for you https://github.com/snapcore/snapd/pull/5624#discussion_r210707985
<mup> PR #5624: tests: get the linux-image-extra available for the current kernel <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5624>
<cachio> mborzecki, sure
<mborzecki> cachio: there was a typo in the code i suggested :P i missed a space
<cachio> mborzecki, let me test it with the new kernels
<cachio> mborzecki, I see a difference between your function and the one I did, and it is that what we return when the first option does not match
<niemeyer> Chipaca: Danke!
<niemeyer> cachio: Alright.. do you have a build log for the failure?
<Chipaca> niemeyer: nichts zu danken
<cachio> niemeyer, yes, 1 min please
<cachio> niemeyer, https://travis-ci.org/snapcore/spread-cron/builds/416898556#L548
<niemeyer> Chipaca: danke fÃ¼r deine Freundlichkeit
<niemeyer> (hope Google Translate did a good job there... ;P)
<cachio> niemeyer, Chipaca Jeder spricht Deutsch mit Google Translate
<niemeyer> cachio: Hmmm.. that's a strange log
<niemeyer> cachio: I hope it's just auth, because it doesn't really look like it
<cachio> niemeyer, we can try generating the secrets for this project and see
 * niemeyer installs travis client from some guy named kyrofa 
<mborzecki> cachio: hm with this change you'll install the package matching your kernel (probably something we want?)
<cachio> mborzecki, yes
<cachio> I tested that with the problematic kernel and worked
<cachio> mborzecki, I'll push the change
<cachio> mborzecki, lets see how it goes
<niemeyer> kyrofa: It's not working :(
<niemeyer> % travis encrypt foo
<niemeyer> Outdated CLI version, run `gem install travis`.
<niemeyer> No such file or directory - git
<niemeyer> for a full error report, run travis report
<kyrofa> What.
<kyrofa> I didn't realize it did a version check
<cachio> mborzecki, if you give the +1 I can merge it wwhen the tests are in green
<cachio> mborzecki, so I can update the ubuntu xenial 64 images
<niemeyer> kyrofa: Most things I run seem to result in that error
<niemeyer> --help works tho
<mborzecki> cachio: +1'ed :)
<kyrofa> niemeyer, yeah it must check it server-side. I'll update it
<cachio> mborzecki, thanks
<kyrofa> What the heck. They tagged it four hours ago
<niemeyer> cachio: Can you please put an "env" call just above the spread call so I can have a vague idea of what's the context there?
<cachio> niemeyer, sure
<cachio> niemeyer, https://travis-ci.org/snapcore/spread-cron/builds/416972345
<sergiusens> niemeyer cachio another option is to setup the encrypted keys from https://travis-ci.org/snapcore/spread-cron/settings
<sergiusens> I cannot see that url fwiw as I am not in a relevant team for that
<sergiusens> I don't know what key is used there though
<cachio> sergiusens, well, not sure which is the problem itself
<cachio> niemeyer, is it not fixed by doing the same you did for snapd project?
<niemeyer> cachio: SHould be, but I'll need to find a working travis tool.. will need to get dinner before that
<cachio> niemeyer, sure
<mup> PR snapd#5624 closed: tests: get the linux-image-extra available for the current kernel <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5624>
<mup> PR snapd#5674 opened: tests: add the original function to fix the errors on new kernels <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5674>
<jdstrand_> zyga: wrt fedora base, I forgot about this: https://forum.snapcraft.io/t/process-for-reviewing-base-snaps/3040
<niemeyer> cachio: I've sent the data for travis.yaml in spread-cron privately
<niemeyer> cachio: Please add it and give it a shot
<niemeyer> And with that success I call it a night and end on the right foot.
<niemeyer> See you all tomorrow.. same time, same place
<kyrofa> niemeyer, travis snap should be better now
<cachio> niemeyer, see you, thanks for this help
#snappy 2018-08-17
<solrac> hello
<mborzecki> morning
<mup> PR snapd#5664 closed: interfaces: workaround for activated services and newer DBus <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5664>
<mborzecki> mvo: morning
<mvo> hey mborzecki
<mborzecki> mvo: regarding experimental.<flag>= we seem to have a problem there
<mvo> mborzecki: uh, ok, tell me more
<mborzecki> mvo: it's actually quite silly https://paste.ubuntu.com/p/tVGVZjstcm/
<mvo> mborzecki: ohhh, i see
<mvo> mborzecki: its because of the bool i guess
<mborzecki> mvo: yeah, should be a quick fix
<mvo> mborzecki: funny, so it accepts null as false
<mvo> mborzecki: but not ""
<mvo> mborzecki: thanks
<mborzecki> mvo: null == nothing to unmarshal, so a bool stays in its default value
<mvo> mborzecki: aha, nice
<mvo> mborzecki: wasn't aware of this
<mborzecki> mvo: even funnier, the corecfg code unmarshals to a string and allows ""
<mup> PR snapd#5675 opened: overlord/snapstate: improve feature flag validation <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5675>
<mborzecki> mvo: ^^
<mborzecki> mvo: updated #5671 too
<mup> PR #5671: tests: basic test for parallel installs from the store <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5671>
<mvo> mborzecki: yay, thank you
<zyga> good morning
<zyga> I'm not really here, just checking which office to go to handle the car paperwork
<mvo> zyga: good morning
<mborzecki> mvo: that initialiazation is for the case when there is nothing to unmarshal or null (cause json, null is untyped :))
<mvo> mborzecki: aha, ok
<mborzecki> zyga: hey, so you're off-really-off today or just regular off?
<zyga> mborzecki: I'm swapping for the weekend
<mborzecki> zyga: if the former we can chat about s-c on monday
<zyga> mborzecki: but after I handle the paperwork I will return
<zyga> mborzecki: and we can chat
<zyga> or we can chat straight away now since I'm here
<mborzecki> haha so the 'regular off' ;)
<zyga> haha, so that's what you meant by "regular off" :D
<zyga> I guess that's only fair :D
<mborzecki> off-but-not-off
<pstolowski> morning
<mborzecki> pstolowski: heyah
<Chipaca> moin moin
<Chipaca> is the lxd snap busted?
<mborzecki> google:ubuntu-16.04-32:tests/main/lxd seems to be failing
<Chipaca> yeah
<Chipaca> same here
<mborzecki> Chipaca: pedronis: hellos
<Chipaca> mborzecki: hi
<mvo> hey pstolowski and Chipaca
<Chipaca> mvo: o/
<mvo> Chipaca: I added some comments to the dump-db PR, I think a slightly more generic format for the output would be nice. I'm thinking about the field spearator, \ff is used right now
<Chipaca> mvo: yep, and wotsisname said it'd be fine
<mvo> Chipaca: do you think ":" is reasonable? or shall we go with something else?
<Chipaca> mvo: an emoji would be frouned on, i  guess
<Chipaca> : is reasonable
<mvo> Chipaca: heh, ok
<pedronis> mvo: I'm looking again at the changes in  device_asserts.go and now I'm very confused
<mvo> pedronis: can I help fix that somehow?
<pedronis> mvo: this should go away no:   https://github.com/snapcore/snapd/blob/master/asserts/device_asserts.go#L248 ?
<mvo> pedronis: yes, sorry, that was a oversight, let me kill it (with fire)
<pedronis> mvo: why is this here and not one level up:  https://github.com/snapcore/snapd/blob/master/asserts/device_asserts.go#L163 ?
<pedronis> mvo:  the new branch needs a similar check for gadget, no?
<pedronis> mvo: checkModel means check the "model"Â header
<mvo> pedronis: indeed, let me fix that too
<mvo> pedronis: plus some gadget track error tests are missing (which of course would have found the issue)
<pedronis> mvo: yea,  I found these because I had the nagging feeling that something was missing in the new PR, it was too short :)
<pedronis> and so I went back to see what we did for kernel
<mvo> pedronis: thanks for noticing! I will generalize it a bit, I get the feeling that this will come again
<mvo> pedronis: should I split the PR up?
<pedronis> mvo: as your prefer
<mvo> pedronis: ok, I think I do that then
<mvo> pedronis: do you have an opinion about "Gagdget() SnapWithTrack" vs "Gadget() string and GadgetTrack() string" ?
<pedronis> mvo: I think IÂ prefer the latter until we can do something outside of asserts
<mup> PR snapd#5669 closed: asserts,image: support gadget tracks in the model assertion <Core18> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5669>
<mvo> pedronis: ok, thats fine, its easy enough to fix later especially if/when we get support for this in snap install
<mup> PR snapd#5676 opened: asserts: add support for gadget tracks in the model assertion <Created by mvo5> <https://github.com/snapcore/snapd/pull/5676>
<mvo> pedronis: the first part -^
<pedronis> mvo: reviewed
<mvo> pedronis: yay, thank you
<mup> PR snapd#5654 closed: cmd/snap-confine: establish snap directory mappings for parallel instances <Parallel installs> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/5654>
<mup> PR snapd#5677 opened:  image: add support for "gadget=track" <Created by mvo5> <https://github.com/snapcore/snapd/pull/5677>
<mup> PR snapd#5678 opened: snapstate: add support for gadget tracks in model assertion <Created by mvo5> <https://github.com/snapcore/snapd/pull/5678>
<pedronis> mvo: this is are all for 2.35, right?
<mvo> pedronis: correct
<mvo> pedronis: I added tags now
<Chipaca> so
<Chipaca> selftest is failing in lxd in 16.04-32
<mvo> Chipaca: uh, what is the error?
<mvo> Chipaca: I mean, what part of the selftest fails?
<Chipaca> error: cannot start snapd: cannot mount squashfs image using "squashfs": mount: /tmp/selftest-mountpoint-487148902: mount failed: Unknown error -1
<Chipaca> lxd fails to start the first time with an error, and it restarts and doesn't print the logs leading up to the error either, which is suspicious
<Chipaca> Aug 17 09:12:18 autopkgtest lxd.daemon[18103]: ==> Setting up persistent shmounts path
<Chipaca> Aug 17 09:12:18 autopkgtest lxd.daemon[18103]: ====> Making LXD shmounts use the persistent path
<Chipaca> Aug 17 09:12:18 autopkgtest lxd.daemon[18103]: ln: failed to create symbolic link '/var/snap/lxd/common/lxd/shmounts': No such file or directory
<zyga> ohhh drat, I need to remove the lxd quirk in 18
<zyga> or maybe I did
<zyga> the lxd quirk is applied on all classic systems
<zyga> _hmmm_
 * Chipaca goes for more coffee
<mborzecki> Chipaca: root@my-ubuntu:~# systemd-detect-virt --help
<mborzecki> bash: /usr/bin/systemd-detect-virt: Numerical result out of range
<mborzecki> Chipaca: that's inside lxc container
<Chipaca> mborzecki: why does that start with bash:?
<Chipaca> mborzecki: i mean, that's a bash error?
<mborzecki> Chipaca: heh, beats me, no clu
<Chipaca> yes
<Chipaca> mborzecki: it's an error from bash
<Chipaca> because
<Chipaca> *EXECVE RETURNED THAT*
<mborzecki> Chipaca: root@my-ubuntu:~# /usr/bin/systemd-detect-virt --container
<mborzecki> bash: /usr/bin/systemd-detect-virt: Numerical result out of range
<mborzecki> omg
<Chipaca> execve("/usr/bin/systemd-detect-virt", ["/usr/bin/systemd-detect-virt"], [/* 12 vars */]) = -1 ERANGE (Numerical result out of range)
<mborzecki> Chipaca: so if that fails, useFuse() => false, mount is done with -t squashfs which fails
<mborzecki> root@my-ubuntu:~# mount -t squashfs $PWD/data.squashfs /mnt/
<mborzecki> mount: /mnt/: mount failed: Unknown error -1
<mborzecki> Chipaca: like this ^^
<ogra> do you have squashfuse installed ?
<Chipaca> mborzecki: it gets more interesting
<Chipaca> mborzecki: do a getcap of systemd-detect-virt
<mborzecki> Chipaca: Failed to get capabilities of file `/usr/bin/systemd-detect-virt' (Numerical result out of range) ?
<Chipaca> mborzecki: yes
<Chipaca> stgraber: in 16.04 i386 (only), installing lxd from stable and launching an unprivileged container results in weirdness: /usr/bin/systemd-detect-virt fails to execve, returning ERANGE
<Chipaca> sparkieg`: is that a typo for a german war on spas
<sparkiegeek> Chipaca: heh, glitch in the matrix, combined with a non-friendly unique-naming scheme in my IRC client :)
<Chipaca> sparkiegeek: you could've gone with 'yes'
<mborzecki> guys, how abou we disable tests/main/lxd on *-32 until this is resolved?
<pedronis> Chipaca: ah, interesting, I was wondering if systemd-detect-virt coul fail when ways that weren't just I'm not a container
<pedronis> s/when/in/
<pedronis> Chipaca: I might have even asked mvo at some point to put more defensive code around it
<Chipaca> pedronis: I doubt it's systemd-detect-virt itself
<Chipaca> pedronis: it never gets to have a say in the matter
<Chipaca> pedronis: (the execve call fails)
<pedronis> Chipaca: ok, but our code anyway assumes it means we are not virtualized ?
<Chipaca> yes, yes it does
<pedronis> that was more my point
<pedronis> anyway
<Chipaca> we should probably bail there instead of assuming tbf
<mborzecki> maybe we should bubble the error up
<mborzecki> otherwise it's rather cryptic while anything fails at this stage
<Chipaca> mborzecki: dunno, stgraber is often up really early
<mborzecki> Chipaca: i can open a PR and we can close it if a solution is found soon(ish)
<Chipaca> what's VGAuthService
<Chipaca> nm
<Chipaca> mborzecki: sure
<mborzecki> damn, that test has a whitelist of systems
<Chipaca> fun fact: byobu-config will lock up the whole everything
<mup> PR snapd#5679 opened: tests/main/lxd: run ubuntu-16.04 only on 64 bit variant <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5679>
 * Chipaca was looking to see if any other binaries failed to exec in the same way
<mborzecki> Chipaca: anything else failed?
<Chipaca> mborzecki: my patience
<mborzecki> heh ;)
<Chipaca> I should probably step away from the forum for a bit
<mborzecki> anyone feels like looking at https://github.com/snapcore/snapd/pull/5614 ?
<mup> PR #5614: interfaces: parallel instances support, extend unit tests <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5614>
<mup> PR snapd#5680 opened: [RFC] hotplug: handling of simple add/remove scenario <Blocked> <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5680>
<pstolowski> uh, what
<pstolowski> (about byobu-config)
<Chipaca> pstolowski: inside a snapped lxd, inside kvm, inside spread, running 'byoby-config --help </dev/null >/dev/null' locks the whole thing up
<Chipaca> byobu*
<pstolowski> finny
<pstolowski> *funny
<Chipaca> viry finny. hilirius, ivin
<pstolowski> just checked the dictionary in case the word finny exists and means something. not in my dict ;)
<Chipaca> pstolowski: 'abounding in fishes', fwiw
<Chipaca> pstolowski: http://www.dict.org/bin/Dict?Form=Dict1&Query=finny&Strategy=*&Database=*&submit=Submit+
<pstolowski> aha
<Chipaca> sergiusens: poing
<Chipaca> why do people sell things they call "Ubuntu" with just random crap running as the kernel
<Chipaca> >:-(
<ogra> well, its a massive improvement ... the last openvz servers i saw (when deugging something similar together with zyga) was 2.x or early 3.x
<ogra> surprisingly openvz finally supports 4.x kernels :)
<Chipaca> ogra: that's why snapd ships a test squashfs :-)
<Chipaca> ogra: https://github.com/snapcore/snapd/blob/master/selftest/squashfs.go#L55
<niemeyer> Chipaca: So looking at snapshotstate, the last missing point is the last id name
<niemeyer> Chipaca: "last-snapshot-set-id"?  It's a mouthful, but has precedence in other options
<Chipaca> niemeyer: what do you mean?
<niemeyer> Chipaca: The "snapshots.last-id" thing, and the comment from me and pedronis in the PR
<Chipaca> ah
<Chipaca> snapshots.last-set-id is what it is now
<Chipaca> which seems alright to me, if we need to add more info about snapshots it won't be out of place in there
<Chipaca> dunno
<Chipaca> niemeyer: I think both approaches are fine (I mean: snapshots.last-set-id is fine, and a toplevel last-snapshot-set-id is fine; anything more structured and I'm going to call YAGNI on it)
<Chipaca> exactly which names are best, I don't know
<niemeyer> Chipaca: I think pedronis had a point about "snapshots" generally being a map of actual snapshots per other cases
<niemeyer> Chipaca: And we indeed have the last-foo-bar-id case already in other places
<niemeyer> last-refresh, last-refresh-hints, last-change-id, last-task-id
<niemeyer> "ubuntu-core-transition-last-retry-time"
<niemeyer> /o\
<mvo> did we figure out more about the lxd issue btw?
<Chipaca> mvo: <Chipaca> stgraber: in 16.04 i386 (only), installing lxd from stable and launching an unprivileged container results in weirdness: /usr/bin/systemd-detect-virt fails to execve, returning ERANGE
<mvo> Chipaca: heh, woah, ERANGE
<Chipaca> mvo: getcap of the file _also_ fails with ERANGE
<Chipaca> mvo: so we're about to learn something about _something_
<mvo> Chipaca: what a surprising error
<mvo> Chipaca: yeah, its amazing
<niemeyer> Chipaca: I've +1d assuming that's tuned per agreement.. someone else needs a final +1 too
<niemeyer> pedronis ^
<Chipaca> man, i'm shaking
<Chipaca> whoa
<Chipaca> ok
<Chipaca> niemeyer: thanks
<pedronis> Chipaca: mvo: yes, ERANGEÂ usually makes me think of math libraries
<Chipaca> I didn't expect the emotional response from myself Â¯\_(ã)_/Â¯ good thing i'm going on holidays next wednesday :-)
<mvo> Chipaca: uhhhh, snapshot going in?
<Chipaca> mvo: got a +1 from niemeyer
<mvo> pedronis: heh, exactly
<Chipaca> ooooh, somebody's jealous :-p
<ogra> Chipaca, dmesg -H means he needs to understand that he is in a pager ... i'd have suppressed the -H
<Chipaca> ogra: maybe TERM isn't set or something stoopid
<ogra> or that, yeah
<pedronis> mvo: sorry for being annoying about context,  but is really mostly meant to have  a place talk back to itself or connected places talk between unrelated or user layers
<pedronis> I mean it's Value feature
<pedronis> niemeyer: yes either me or mvo need to do a 2nd pass of snapshotstate
<pedronis> any consistent reason why all newish PR seems to be red ?
<Chipaca> pedronis: lxd
<Chipaca> pedronis: 16.04-32 lxd errors
<pedronis> the ERANGE issue ?
<Chipaca> pedronis: yes
<Chipaca> EDERANGED
<pedronis> fun :(
<Chipaca> ERANGE is not even listed as a return value for execve
<Chipaca> :-)
<Chipaca> (but it's probably something to do with the xattrs)
<Chipaca> if I had to guess, I'd guess that
<Chipaca> because systemd-detect-virt is one of the very few files in 16.04 that uses caps (via xattrs)
<Chipaca> in fact, i should look at the other ones, d'oh
 * Chipaca does that
<Chipaca> pedronis: dunno if you noticed but mvo wasn't online when you were apologising to him
<pedronis> no
<Chipaca> pedronis: maybe you just wanted to get it off your chest :-D
<mborzecki> https://github.com/snapcore/snapd/pull/5679 shall we pull the trigger?
<pedronis> maybe I didn't complete his nick
<mup> PR #5679: tests/main/lxd: run ubuntu-16.04 only on 64 bit variant <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5679>
<ogra> "The linux beginners course with ogra and Chipaca"
<ogra> session 1 ...
<ogra> :)
<Chipaca> ogra: "If you survive with both your kidneys, [...]"
<ogra> lol
<Chipaca> ogra: as an aside, what on earth have they done to that poor "Ubuntu" that dmesg doesn't work
<ogra> good question
<ogra> lol
<ogra> "no entries"
<ogra> probably he run no kernel at all !!!!
<Chipaca> ogra: it's secretly just running WSL
<Chipaca> YESS
<Chipaca> it's the capabilities
<Chipaca> mtr fails in the exact same way
<Chipaca> as does traceroute6.iputils
<sergiusens> Chipaca: what's up?
<mvo> Chipaca: should I merge 5679 or is the solution so close that its not worth adding the workaround?
<Chipaca> mvo: NFI about the solution -- merge away
<Chipaca> sergiusens: WHY DIDN'T I GIVE MYSELF MORE CONTEXT WITH THE PING :-(
<Chipaca> sergiusens: now I have _no_ idea what it was about
<Chipaca> it was, like, six context switches ago
<mup> PR snapd#5679 closed: tests/main/lxd: run ubuntu-16.04 only on 64 bit variant <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5679>
<Chipaca> sergiusens: I hope I'll remember and ping you again
<Chipaca> oh!
<Chipaca> sergiusens: i remembered :-D
<Chipaca> sergiusens: were you aware of 'snap watch --last=auto-refresh?'
<Chipaca> sergiusens: coming in 2.35
<sergiusens> Chipaca: yes we are https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/build_providers/_snap.py#L263
<sergiusens> but I think I might want to disable refreshes for a lot longer to not get killed mid build :-)
<Chipaca> sergiusens: no no
<Chipaca> sergiusens: the question mark at the end of the change type
<Chipaca> sergiusens: means "no error if none found"
<Chipaca> sergiusens: or from --help, âA question mark at the end of the type means to do nothing (instead of returning an error) if no change of the given type is found.â
<sergiusens> Chipaca: oh, then I can get rid of the suppress. I must say though that that syntax is hard to spot given you phrased the sentence as a question :-)
<Chipaca> sergiusens: mbuahaha
<Chipaca> sergiusens: (sorry)
<sergiusens> and I did an improper quote match
<Chipaca> tut tut
 * sergiusens needs to put his glasses on
<Chipaca> sergiusens: anyway, 2.35+, so you probably can't use it yet
<sergiusens> Chipaca: still good to know!
<Chipaca> sergiusens: but, with our conversation abour --check-skeleton  from the other day i thought i'd call it out to you
<sergiusens> all is good :-)
<Chipaca> ogra: wasn't there a file in proc to tweak the kernel log level? we could ask this person to try that
<ogra> Chipaca, not sure if in /proc ... there is a sysctl setting you can apply though
<ogra> mvo, this is an interesting one https://forum.snapcraft.io/t/set-system-proxy-from-custom-snap-service/6926
<Chipaca> ogra: sysctl is just writing to /proc/sys/<thing>
<Chipaca> ogra: :-)
<ogra> ah, indeed
<ogra> so yeah, there is one, i just dont know the node then ;)
<Chipaca> ogra: but yes better to present it with sysctl
<ogra> should be something about log_level
<Chipaca> ogra: sys.kernel.printk ?
<ogra> Chipaca, /proc/sys/kernel/printk
<ogra> yeah
<Chipaca> heh
<ogra> $ cat /proc/sys/kernel/printk
<ogra> 4	4	1	7
<Chipaca> ogra: I did not point them to https://i.imgur.com/Pfr9dj0.jpg !  I think I deserve a cookie.
 * ogra hands Chipaca a well deserved cookie :D
<ogra> i wonder if he paid for that carp ...
<Chipaca> ogra: at lunch time? are you mad?!?
<ogra> *crap
<Chipaca> :-)
<ogra> hahaha
<Chipaca> ogra: 8GB of ram? you betcha it was paid for
<Chipaca> although given they said it was Ubuntu and it wasn't, maybe it's "8GB" of "RAM"
<Chipaca> (actually just a big swap file on a 1GB netbook)
<ogra> haha
<mborzecki> zyga: snap-update-ns is looking good, did a change, it's actually surprisingly simple
<zyga> woot, that's great
<mborzecki> zyga: you know, i might have screwed something up there too :P
<zyga> I'll check next week :)
<jdstrand> zyga: hey, fyi, responded to https://github.com/snapcore/snapd/pull/5644
<mup> PR #5644: interfaces: add audio-playback/audio-record and make pulseaudio manually connect <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5644>
<zyga> jdstrand: thank you
<zyga> jdstrand: I'm swapping today, doing office move and legal paperwork
<mborzecki> zyga: https://paste.ubuntu.com/p/YZ7w7RKw5d/ mountinfo (does not include $SNAP_USER_DATA yet)
<jdstrand> zyga: np. I suspect you'll just agree with me and ack
<zyga> I'll look quickly now :)
<jdstrand> zyga: but by all means, exercise your day off :)
<mup> PR snapd#5675 closed: overlord/snapstate: improve feature flag validation <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5675>
<jdstrand> Chipaca: fyi, I think that hostnamectl issue will be resolved if the PR merges from trunk
<jdstrand> Chipaca: and hi :)
<Chipaca> jdstrand: I was assuming as much :-) hi
<Chipaca> jdstrand: excitement now is about lxd on 16.04-32 being unable to execve files that use capabilities
 * Chipaca ~> lunch
<ogra> pedronis, Chipaca https://imgur.com/a/ZFNu5pV ... finally able to reproduce ... capturing logs now
<zyga> jdstrand: +1
<jdstrand> zyga: thanks :)
<zyga> marked as such on the PR
<mvo> ogra: aha, you reproduced the shutdown hang?
<mborzecki> damn, the trackpoint left click in my x220 is starting to fail :(
<ogra> mvo, yeah
<ogra> mvo, pedronis Chipaca https://pastebin.canonical.com/p/DGKBDMzQ2r/ logs (filtered out binder and anbox audit messages since they ake it unreadable)
<ogra> *make
<pedronis> internal shutdown seems correct
<pedronis> so it would some handshake with systemd problem
<pedronis> seems we get a sigterm but don't do the right thing:  snapd.service: State 'stop-sigterm' timed out. Killing.
 * mvo wonders if anything has chnaged here
<pedronis> mvo: well it might have been like since a while
<pedronis> mvo: it's related to the waiting we do on reboot and signal unhandling
<ogra> note this is all edge plus a devmode daemon (anbox) though i see the daemon being killed several lines before the snapd timeout shows up
<ogra> (also not sure if a misbehaving snap could actually make snapd not stop)
<pedronis> mvo: we also added the watchdog
<mvo> pedronis: aha, thats a good one
<mborzecki> pedronis: Aug 17 12:19:55 localhost.localdomain snapd[1005]: daemon.go:577: Waiting for system reboot ?
<pedronis> mborzecki: ?
<mborzecki> isn't snapd waiting in a long sleep here?
<pedronis> yes
<pedronis> as I said signal handling is not quite right over shutdown
<mborzecki> so any signals are not really handled
<pedronis> yes
<pedronis> what I'm trying to say
<pedronis> not sure it's related to the timeout though
<pedronis> if it's really much later
<pedronis> mvo: we need to call Reset or Stop for the signal handling we setup in main.go, not sure exactly where
<ogra> if you want to repro: create a qemu VM with an image from edge ... leave it off over night so there is a new core ... make sure to start it only after core has updated in the store... boot it and watch it to do an auto-refresh with that hang
<ogra> i have never seen it when doing a manual refresh
<mborzecki> pedronis: i'd assume it's related, then things start to make sense, term get queued, if systemd gets a request to restart the process it would make sense to ignore it since the system is going down anyway, systemd timeouts waiting for snapd to exit, snapd would timout waiting for reset :)
<pedronis> well, not from the logs  it seems systemd then kills snapd
<pedronis> so snapd doesn't timeout
<mvo> yeah, I'm puzzled
<pedronis> ogra timeout is systemd saying something about snapd again
<pedronis> but maybe I'm confused
<mvo> if snapd does not handle sigterm correct I should be able to simulate this by simply kill -TERM $(pidof snapd)
<mvo> and that exist normally
<pedronis> mvo: this is about reboot mode
<pedronis> not normal running snapd
<ogra> pedronis, i'm seeing exactly whats in the imgur png
<pedronis> we are inside daemon Stop at that point
<pedronis> mvo ^
<mvo> pedronis: ok
<pedronis> I mean,  I know what we need to do about sigterm (except exactly how to place it)
<pedronis> not sure it fixes what ogra sees
<mvo> pedronis: that makes sense, we are in stop at this, so yeah
<pedronis> ah, it says A Stop Job so yes, it's related
<Chipaca> pedronis: sorry to sidetrack you, but did you see Gustavo's comment about last-snapshot-set-id?
<pedronis> yes
<Chipaca> pedronis: +1?
<pedronis> I agree with that
<Chipaca> pedronis: k
<pedronis> mvo: something like this perhaps (untested):  https://pastebin.ubuntu.com/p/rYWJ8PR5HH/
<mvo> pedronis: yeah, that looks sensible
<mup> PR snapd#5318 closed: interfaces/builtin: add new cuda-support interface <Created by anonymouse64> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/5318>
<pedronis> mvo: I can try to cut a PR from that pastebin on monday I suppose unless you want to
<mvo> pedronis: I can look at this while waiting for travis to biuld my gadget-track PRs
<pedronis> ok
<mvo> pedronis: this mostly needs tests, right? the feature itself looks reasonalbe
<pedronis> yes, some kind of tests (not sure it's easy to test)
<mvo> pedronis: yeah, it looks tricky, maybe I can manage some sort of integration test at least, I will poke a bit at it
<pedronis> a 2nd review for #5676 would be great
<mup> PR #5676: asserts: add support for gadget tracks in the model assertion <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5676>
<mvo> yeah, was about to ask for this - should be straightforward (now)
<Chipaca> stgraber: ping?
<stgraber> Chipaca: pong
<Chipaca> stgraber: I don't know if you saw that we're having issues with lxd since the release yesterday?
<stgraber> Chipaca: I just read your comment about systemd-detect-virt on i386, will take a look
<Chipaca> stgraber: it's any executable that uses capabilities
<Chipaca> stgraber: systemd-detect-virt, mtr, and traceroute6.iputils
<Chipaca> stgraber: but, on 64 bits, snapcraft is also having trouble with snapd dying, that goes away with switching to 3.0
<stgraber> Chipaca: what kernel are you on?
<Chipaca> stgraber: e.g., on travis, Â«apt install snapd; snap install snapcraft --classic; snap install lxd; mkdir project; cd project; snapcraft init; snapcraft cleanbuildÂ» fails
<Chipaca> not sure what travis is using
<Chipaca> I'm on 4.4.0-131-generic; mborzecki is on something newer I think
<Chipaca> and the spread runs on 16.04-32 are on fresh cloud images, whatever's shipped there
<Chipaca> (I can track it down if it's important)
<mborzecki> i was on whatever we used in spread instances
<Chipaca> oh wait my machine is 4.4.0-131-generic but the test was run in kvm
<Chipaca> I'd have to check what was there :-)
 * Chipaca checks
<mborzecki> i'll start the test and check what's used in gce
<Chipaca> stgraber: 4.4.0-133-generic
<Chipaca> running on a 4.4.0-131-generic
<stgraber> Chipaca: reproduced the issue
<Chipaca> stgraber: should we be installing lxd from candidate in our integration suite, to catch this family of errors before they hit stable?
<stgraber> Chipaca: that may be useful, yeah, this is definitely related to fscaps in this case so our own tests didn't trip on that
<Chipaca> stgraber: also mborzecki noticed that a privileged container didn't have this issue
<stgraber> yeah, that part would be expected
<Chipaca> ok
<Chipaca> stgraber: does it only failing on 32 bit intel make sense to you?
<Chipaca> (this particular failure i mean -- the snapcraft one i am yet to dig into)
<stgraber> Chipaca: no, got it failing the same way on amd64
<Chipaca> that's very strange
<mborzecki> that's good news, right?
<Chipaca> mborzecki: how are our tests working on amd64?
<mborzecki> Chipaca: they are 'passing'
<Chipaca> mborzecki: that's my point: if the bug is there, they shouldn't
<Chipaca> mborzecki: I'll dig
<mborzecki> stgraber: Chipaca: got a debug shell on i386, do you want to check anything?
<stgraber> tracked it down and working on a fix now
<mborzecki> stgraber: what's the issue?
<stgraber> tl&dr is your kernel doesn't support unprivileged file capabilities, yet it lets us write an xattr that uses that new v3 fscap format
<stgraber> but then blows up when reading the file
<mborzecki> stgraber: heh, nice
<Chipaca> stgraber: so it's a bug in the image itself?
<Chipaca> s/bug/regression caused by a change/
<stgraber> Chipaca: it's a combination of things, LXD 3.4 introduced logic to remap file caps rather than just strip them and unsquashfs-tools was fixed yesterday to not drop xattrs in 16.04
<stgraber> Chipaca: so even in our candidate and edge channels, everything was good until the last snap rebuild yesterday which picked up the fixed unsquashfs
<stgraber> and most of our manual testing is done on 4.15 kernels which do support the v3 caps or on 4.4 systems with -proposed enabled that again do support v3 caps (next kernel SRU has a backport of the feature)
<Chipaca> ï¼­ï¼¡ï¼§ï¼©ï¼£
<Chipaca> sigh
<Chipaca> I'll push a pr that adds --candidate to the lxd integration test
<stgraber> and even though we do have snap tests that use the broken kernels, our test image doesn't use file caps (it's just a tiny busybox image)
<Chipaca> stgraber: we woudln't've caught it if we hadn't just happened to be using one of the three binaries that have caps in xenial
<stgraber> Chipaca: yeah, I expect that detect-virt is what's going to break most users so trying to rush a fix now
<Chipaca> stgraber: as soon as the fix is in candidate let me know, and I'll push a pr that turns the test back on and fetches lxd from candidate
<Chipaca> mborzecki: I'm guessing amd64 just happened to get a newer kernel or something
<Chipaca> dunno
<mborzecki> Chipaca: ubuntu-16.04-32 uses 4.4.0-131-generic
<Chipaca> mborzecki: I got 133 here, but ok
<Chipaca> and indeed if I rebooted I'd have 133 as well
<Chipaca> mborzecki: mirror sync
<mborzecki> Chipaca: ubuntu-16.04-64 image users different kernel indeed, it's 4.13.0-1019-gcp
<Chipaca> haha, hehe. Ha ha ha ha, he he he he
<Chipaca> mborzecki: ok
<pedronis> big difference
<Chipaca> so there was a little tiny window of hitting the bug, and we *nailed* it
<Chipaca> :-)
<mborzecki> flawless victory
<Chipaca> next question: should we make sure -32 and -64 are running similarish kernels?
<mborzecki> heh :)
<mborzecki> cachio__: ^^ ?
<cachio__> mborzecki, yes
<cachio__> mborzecki, I think the problem with the function
<cachio__> is that "if apt-cache policy "linux-image-extra-$(uname -r)" >/dev/null 2>&1; then" is going always through the then
<cachio__> with match or without
<mborzecki> cachio__: yeah, something to figure out
<mborzecki>  the current pr will effectively switch the kernel to something else
<mborzecki> cachio__: i have 4.13.0-1019-gcp and the proposed code wants to install linux-image-extra-4.13.0-31-generic, this will pull in the non-gcp kernel
<cachio__> mborzecki, yes, but that linux-image-extra-4.13.0-31-generic works well with the current kernel
<cachio__> mborzecki, at least the tests pass
<cachio__> so, what should we use when there is no linux-image-extra pkg for the current kernel?
<mborzecki> cachio__: i see that there's linux-module-extra for the newer kernels, and linux-image-extra seems to be gone
<mborzecki> cachio__: the real issue is that apt-cache policy <nonexistent-package> returns 0 :(
<cachio__> mborzecki, yes
<mborzecki> damn, and so does apt list
<cachio__> let me try installing linux-modules-extra-4.15.0-1017-gcp and running the tests
<pedronis> need to look at output it seems
<mborzecki> cachio__: can you replace apt-cache policy with apt-cache show?
<cachio__> mborzecki, that works
<mborzecki> cachio__: something like this perhaps https://paste.ubuntu.com/p/QVSbPQcqWC/
<cachio__> mborzecki, yes, makes sense
<Chipaca> niemeyer: in spread, is there a reason why I can't say âsystems: [ubuntu-*, -ubuntu-14*]â?
<cachio__> mborzecki, I pushed that
<cachio__> I'll test this with the new gce images to see if it works
<mup> PR snapd#5681 opened: overlord: handle sigterm during shutdown better <Created by mvo5> <https://github.com/snapcore/snapd/pull/5681>
<mvo> pedronis: ^- this is your earlier pastebin with tests, hope the tests make (some) sense, its a bit tricky
<mvo> ogra: ^- this should hopefully fix the reboot timeout
<mvo> ogra: I mean the wait
<mvo> a second review for 5676 and 5677 would be great, should be easy
<ogra> mvo, awesome, will happily test once it landed
<t1mp> is there a way to speed up snap building if I already have all the .deb dependencies installed in the system?
<ogra> mvo, btw, kyle told me it is likly he had the SD mounted when dd'ing to it ... (yay, nautilus) ... you really need to promote godd more ;)
<t1mp> I have a full pipeline on Jenkins now, which runs inside a Docker image that has all the dependencies. Still, the snapcraft step takes a long time because it is re-downloading all the deb files
<mup> PR snapd#5676 closed: asserts: add support for gadget tracks in the model assertion <Core18> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5676>
<pedronis> mvo: #5678 has conflicts now, merging master into it would be nice either way
<mup> PR #5678: snapstate: add support for gadget tracks in model assertion <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5678>
<mvo> pedronis: yeah, I updated it
<mvo> pedronis: and also the snapstate one
<mvo> pedronis: when you say "before adding the close probably it would have worked anyway" in the review of 5681 - do you mean that without the close the test I added would behave the same? or am I misunderstanding?
<mvo> pedronis: I will add the nil checks, I like that
<pedronis> mvo: no, IÂ mean the code would not have explode passing nil in, but with the close it does
<mvo> pedronis: aha, got it - will fix it
<niemeyer> Chipaca: The logic is simpler.. you start with the fixed list for the file at hand, and can either add or drop.. it's not sequential
<mvo> pedronis: I just need the close for my test, I could do it differently but this looked most natural (next to sending sigkill itself in the test which does not work)
<pedronis> mvo: the close is ok, but IÂ think making sigCh optional is also natural
<niemeyer> Chipaca: At least from my vague memories.. it's been a while
<mvo> pedronis: yeah, we are in agreement :)
<mvo> pedronis: updated, thanks for the feedback
<pedronis> mvo: I would have put the if around the whole bit using sigCh,  Stop supporting nil works but is not super clear from the docs why it should
<mvo> pedronis: indeed
<Chipaca> mvo: any idea what failing to reset devices.list means?
<mvo> Chipaca: do you have more context
<pedronis> what is devices.list
<mvo> Chipaca: is that an lxc error? related to the lxd devices cgroup?
<mvo> Chipaca: or to our deivices cgroup?
<mup> PR snapd#5660 closed: wayland: add extra sockets that are used by older toolkits (e.g. gtk3) <Created by gerboland> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5660>
<plars> sergiusens: how often do you normally do a release to stable of the snapcraft snap? Do you spend any time in beta/candidate? it looks like the current set of snaps is stable==candidate==beta, so I'm guessing you just do testing in edge?
<plars> sergiusens: the reason I ask, is we'd like to do some testing of our snaps with upcoming releases of snapcraft, trying to figure out which channel would be the best to pull from
<sergiusens> plars: when we tag, we put the snap in beta once it passes all our automated tests, then we do internal testing and if it all works we move it to candidate and make an ANN for a call for testing
<plars> sergiusens: ok cool, how long do you normally give it in candidate? sounds like that's where we should aim for
<Chipaca> mvo: I'm afraid we moved on, but yes related to lxd (not sure if it's lxd or snapd printing that)
<Chipaca> pedronis: are you around?
<noise][> he EOW'd a bit ago
<Chipaca> ah well
<Chipaca> pedronis: it was to avoid having to reflash a device to undo a serial assertion, but it'd only save us ~5 minutes :-)
<Chipaca> noise][: thanks
<t1mp> is there a way to cache a snapcraft pull when I run it in fresh docker images on Jenkins?
<t1mp> that stage always takes 10 minutes of installing new deb packages
<t1mp> :%s/fresh docker images/fresh docker containers/
<sergiusens> plars: 3 days, but we can negotiate on that with something reasonable (like a week)
<sergiusens> s/reasonable/expectable/
<kyrofa> t1mp, two thoughts: 1) If we're talking build-packages, generate a docker image with them already installed and use that, should speed things up. 2) if we're talking stage-packages, snapcraft caches them in ~/.cache/snapcraft/, you can preserve that between runs
<kyrofa> Consider that each of those steps makes the build less "clean"
<pedronis> Chipaca: having dinner
<t1mp> kyrofa: thanks. That's useful info. I'm snapping a python app, so I don't really need to build anything.
<t1mp> kyrofa: maybe it would be nice to have a 'snapcraft create-cache' command that downloads the .debs. I can include that in my Dockerfile since it doesn't change often.
<t1mp> basically I only need the 'dump' plugin to copy some files that are already generated in previous steps (using PyInstaller)
<t1mp> but setting up the stage takes 20 minutes :(
<kyrofa> t1mp, I don't quite understand. If you're only using the dump plugin, why is snapcraft fetching a bunch of stuff?
<plars> sergiusens: I don't have any concerns about that. 3 days sounds reasonable. I don't expect we would normally have any problem
<t1mp> kyrofa: it has dependencies, see https://pastebin.ubuntu.com/p/tbvGycDvvt/
<kyrofa> Ah, the remote part is probably taking a chunk of time
<t1mp> yes, and it is repeating every time I make a small change somewhere
<t1mp> I really only need to build the snap before publishing a new version, but for now I'm building it for each commit to make sure I don't break it. And to test that the snap building works properly
<kyrofa> t1mp, every time you make a small change you fire up a clean docker container?
<kyrofa> Ah, commits, okay that's fair
<t1mp> yes, Jenkins does
<t1mp> for each push
<kyrofa> t1mp, if you run `snapcraft define desktop-gtk3` you'll see that it's mostly stage-packages as well
<kyrofa> t1mp, stage-packages are not installed on the host, which means creating a new docker image with them installed won't help you
<kyrofa> t1mp, but you can try preserving that cache between runs (point (2)) so they don't need to be fetched again
<sergiusens> kyrofa, t1mp: you can mount the cache directory into the container
<kyrofa> sergiusens, you're stealing my thunder
<sergiusens> exactly that
<t1mp> I realized that :) I meant to have an image that includes ~/.cache/snapcraft. That would be kind of ugly though. Probably better to mount it.
<kyrofa> Indeed
<sergiusens> yeah, that (thunder) too :-)
<kyrofa> :D
<t1mp> sergiusens, kyrofa: right :)
<t1mp> that caches only the deb files right? They still need to be installed
<kyrofa> t1mp, they're just unpacked into the snap, yeah
<kyrofa> Should be quick compared to fetching them
<t1mp> yeah pull takes 3 minutes now https://pastebin.ubuntu.com/p/PJqfM6ndQW/
<t1mp> (the total time went down from 20 to 5.. I think the server was overloaded before)
<t1mp> err.. to 8 min, not 5. :)
<t1mp> I'll look into keeping the cache. On Monday :)
<kyrofa> t1mp, we'll be here!
<t1mp> great, thanks :)
<kyrofa> Have a lovely weekend
<t1mp> you too
<stgraber> Chipaca, sergiusens: we have a fix (https://github.com/lxc/lxd/pull/4943), should land upstream in ~30min, then in snap another 30min or so later
<mup> PR lxc/lxd#4943: shared/idmap: test fcaps support <Created by stgraber> <https://github.com/lxc/lxd/pull/4943>
<sergiusens> thanks for the update
<Chipaca> stgraber: so I could push the PR about now?
<stgraber> Chipaca: yeah, we should have the fix in candidate in the next 10min or so
<stgraber> Chipaca: once Jenkins is happy on our side, I'll promote to stable
<Chipaca> stgraber: the pr I'd push would bring it back for i386, but also pull from candidate
<Chipaca> stgraber: (is candidate the right place to pull from?)
<stgraber> Chipaca: the issue isn't arch-specific though so you shouldn't make anything specific to i386
<stgraber> yeah, we only use edge, candidate and stable
<Chipaca> stgraber: the difference is our i386 images have 4.4.x, whereas amd64 has 4.13.x
<Chipaca> stgraber: so the issue only manifested on i386
<stgraber> Chipaca: looks like we're seconds away from having the fix in candidate now
<stgraber> that snap takes so long to build...
<stgraber> 52min for that build
<Chipaca> stgraber: via snapcraft?
<stgraber> Chipaca: yeah on LP, but it's not a simple snap :)
<mup> PR snapd#5682 opened: tests/main/lxd: pull lxd from candidate; reÃ«nable i386 <Created by chipaca> <https://github.com/snapcore/snapd/pull/5682>
<Chipaca> stgraber: tadaa
<stgraber> sergiusens, Chipaca: promoting to stable now
<Chipaca> woop
<kyrofa> Thank you, stgraber
#snappy 2018-08-18
<popeycore> ogra: got any suggestions for getting an ubuntu core machine inline when it's behind a captive portal?
<popeycore> I have installed the links snap and tried to visit the portal but it 404's (dunno if it's a js issue or something else odd)
<popeycore> tried doing mad things like installing chromium mir kiosk, but that looks broken (interface names have changed it seems).
<ogra> popeycore, i think you need the right combo from edge and beta for chromum and mir-kiosk atm
<popeycore> yeah, i tried
<popeycore> but the guide thats on discourse doesn't work. interface names changed etc
<ogra> though i need to talk to the guys, they cant just remove existing interfaces ... (unless there are zero users which i doubt)
<popeycore> yeah, i filed a card on my to-do to pounce on them next week :D
<ogra> yeah they are moving away from the content sharing towards a real wayland interface
<ogra> but i guess they still need to keep the old oe
<ogra> *one
<ogra> chromium-mir-kiosk is the only idea i'd have for your prob though
<popeycore> ok, good. we tried some other ludicrous options :)
<ogra> 8you can actually turn off kiosk mode in it and just use it as browser via a snap set option)
<ogra> you could perhaps install classic any try it through that ... not sure if you could get an xserver to start in there though
<popeycore> huh, didnt think of that
<ogra> well, no idea if it works ... its a chroot after all
<ogra> but probably worth a try
<ogra> geez ... the community theme snap is actually called communitheme ?!?
<ogra> (took me quite some searching to find there is on y in it ...)
<popey> https://usercontent.irccloud-cdn.com/file/EAthFK7R/IMG_20180818_120845.jpg
<popey> @ogra: success!
<popey> Had to install Ubuntu desktop in classic. Ran Firefox as root. Managed to get through the portal. Thanks
<ogra> hah
<ogra> see, no effort at all
<ogra> :P
#snappy 2018-08-19
<ogra> popey, http://people.canonical.com/~ogra/snappy/wmx.png ... using http://people.canonical.com/~ogra/snappy/wmx_8_amd64.snap (needs --devmode and the stable mir-kiosk ... and snap connect wmx:wayland-socket-dir mir-kiosk:wayland-socket-dir as well as snap connect wmx:x11-plug wmx:x11)
<ogra> in case you are interested ;) ... thanks to devmode you can actually use snap run
<ogra> (inside the xterm that is)
<popey> Oh nice!
<CustosLimen> hi
<CustosLimen> spotify snap stopped working on fedora
#snappy 2019-08-12
<mborzecki> morning
<mborzecki> new kernel, brb
<mvo> hey mborzecki ! good morning
<mborzecki> mvo: hey, morning
<mborzecki> mvo: how was your vacation?
<mvo> mborzecki: very nice, thank you
<mvo> mborzecki: also good to be back :) anything I should look at right away, i.e. anything blocking one of you?
<mborzecki> mvo: lots of things were red last week
<mvo> mborzecki: yeah, protocol_error is something I saw
<mborzecki> mvo: i briefly joined standup on friday and we were still tracking PROTOCOL_ERROR popping up in http client
<mvo> mborzecki: and one of the tests failed to remove a dir
<mvo> mborzecki: thanks for this, I will check it out - how was flock?
<mborzecki> mvo: it was good, really interesting
<mborzecki> mvo: got some notes, need to compile a report out of that :)
<mvo> mborzecki: cool, looking forward to that :)
<mvo> silly question - 7208 looks green and ready but is not merged yet - any reason for this? can I just merge it or is there something I am missing?
<zyga> Good morning
<zyga> I donât have my laptop anymore
<zyga> Nor am I home
<zyga> mvo: would it be terrible if I skipped our 1:1 today? Iâm planning on how to get home today
<zyga> We can try to sync on telegram audio
<mvo> hey zyga ! good mooooorning
<mvo> zyga: its fine, we can reschedule. out of curiosity, where are you :) ?
<mborzecki> zyga:h hey
<zyga> mvo: Iâm in OstrÃ³da
<zyga> Trains are full of people returning from seaside
<zyga> And I was unable to get a ticket for anything yesterday
<mvo> zyga: ok
<zyga> Iâll get coffee and breakfast, I should be home in the afternoon
<mvo> zyga: ok
<pstolowski> mornings!
<pstolowski> mvo: welcome back!
<mvo> hey pstolowski ! thank you
<mvo> pstolowski: feels good to be back - anything you need from me where I could unblock/help you?
<mborzecki> pstolowski: hey
<mborzecki> quick errand, back in 30
<zyga> mvo: tests are in a sad state
<zyga> Store/CDN protocol error
<zyga> Unit tests sometimes fail on context cancelled
<mvo> zyga: yeah, I noticed :/
<mvo> zyga: looking at some of them right now
<zyga> Protocol error is a mystery, unclear if anything we changed or if something far side
<zyga> Tests are clearly our side, some of the recent changes to daemon code
<pstolowski> mvo: Sergio was in touch with store re protocol error but they didn't find anything :(
<pstolowski> mvo: sorry, missed your earlier question - you can look at my latest PRs concerning firstboot, and also https://forum.snapcraft.io/t/firstboot-seeding-failure-scenario-possible-fixes-and-boot-process-confusion-question/12698
<mvo> pstolowski: great, will do
<pstolowski> ty
<mborzecki> re
<pstolowski> mvo: do you remember the details of be4fc4d117c255cadd697a93f9f94e49c708f2c3 ?
<mvo> pstolowski: yes :)
<mvo> pstolowski: it was needed because we used a version of mux from 2015
<mvo> pstolowski: that pre-dated context.Context
<mvo> pstolowski: which caused issues when trying to use context.Context in our http code
<mvo> pstolowski: iirc it was breaking passing MuxVars
<mvo> pstolowski: why do you ask? is it causing issues?
<Chipaca> moin moin
<pstolowski> mvo: the reason i'm asking is I hit a weird situation ~2 weeks ago, where my custom build of snapd & snap would refuse to talk to each other at runtime (i didn't know vendor needed refreshing), the passing of args via api seemed broken (api would not receive snap names with snap ops for example). interestingly, everything built just fine. i thought i messed up my VM and eventually refreshed vendor and everything worked.
<pstolowski> but last Firday ijohnson hit the same issue, and this is when I understood it was vendor change.
<pstolowski> mvo: so we were scratching our heads last Friday; why evertyhing builds correctly without vendor refresh but fails only at runtime
<pstolowski> mvo: and also if we didn't accidentaly break api compatibility with this change?
<mvo> pstolowski: oh, interessting - that is worth exploring, let me try to reproduce
<pstolowski> mvo: now that i think of it, most likely the semantics of context api changed and without vendor refresh it wouldn't work correctly with current master, but our api is not affected
<mvo> pstolowski: yeah, I think it won't break api but confuses our code so I think we need some sort of version check
<mvo> pstolowski: i.e. make the build fail if current snapd master is used with an older gorilla
<mvo> pstolowski: either via an explicit version check or by using something new from the gorilla code as a test to see that things are current enough
<pstolowski> mvo: nice idea, i can take a look at this
<mvo> pstolowski: that would be great!
<mvo> pstolowski: thank you!
<pstolowski> np
<mvo> Chipaca: hey, good morning! hope you are well, anything I can help you with to unblock you?
<mvo> Chipaca: (if needed :)
<Chipaca> mvo: nothing particular! i succumbed to curiosity and caught up with some bits of the forum over the weekend so it's not a terrible backlog today :)
<Chipaca> but i am going to need extra coffee
<Chipaca> mvo: aren't you also just back?
<mvo> Chipaca: great to hear. yes, just returned
<mvo> Chipaca: and coffee sounds like a great idea (s/coffee/tea for me but the idea is the same :-D
<Chipaca> yeah
<Chipaca> mvo: similarly then, holler if i can do anything for you
<mvo> Chipaca: thanks!
<Chipaca> pedronis: wb!
<mborzecki> mvo: added your comments about the http2 problem to the forum topic https://forum.snapcraft.io/t/snap-download-failures-with-protocol-error/12677
<mborzecki> looks like the whole team is back :)
<mvo> mborzecki: thank you! I'm looking into some sort of unit test right now but it appears tricky
<mvo> hey pedronis, welcome back!
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/7232
<pedronis> Chipaca: mvo: hi
<mvo> mborzecki: that looks similar like the one that sergio did some days ago?
<mvo> mborzecki: also I suspect this affects real users too, not just tests :/
<mborzecki> mvo: yeah, i'm surpised fastly does not log details when error like this appear
<mvo> mborzecki: I suspect the http2 spec if not super great at providing extra information
<mvo> mborzecki: its also unclear if its their fault or go fault, it might be something that go does wrong and the reply is "protcol_error" (i.e. they tell us "you do something silly")
<mvo> mborzecki: but don't take my word for it (yet) :) still trying to get into this issue
<mborzecki> mvo: we need log_martians for http2
<mvo> mborzecki: haha
<pstolowski> pedronis: hi, welcome back!
<pstolowski> mborzecki: hey, how was flock?
<pedronis> pstolowski: hello
<mborzecki> pedronis: Chipaca: hey
<mborzecki> pstolowski: intersting, i can tell you more about it in the standup
<pstolowski> mborzecki: sounds good!
<pstolowski> mborzecki: i suppose it's too early for recordings from flock?
<mborzecki> pstolowski: yeah
<mvo> 7190 needs a second review, should be easy
<pstolowski> mvo: re #7234 i'm not sure if there is a better way, but fwtw it did the job in my tests
<mborzecki> audio-{playback,record} will replace pulseaudio interface?
<pedronis> mborzecki: yes
<mvo> pstolowski: thanks, this looks good
<mvo> fwiw, I added a tweak to 7231 to disable the interfaces-calendar-service test so that this gets green
<mvo> I got two errors in this test in a row
<mvo> but no protocol_errors anymore, seems the retry helps short term
<pstolowski> +1
<Chipaca> api.snapcraft.io struggling, expect tests to flake
<mborzecki> quick errand, back in 30
 * Chipaca lunches, probably
<mborzecki> re
<jdstrand> mvo: hi! hope you had a nice holiday :)
<jdstrand> mvo: so, I committed the audio-playback/audio-record PR on friday, but only after reverting the pulseaudio changes. I squashed and merged, but didn't update the first line, which said I made pulseaudio changes
<jdstrand> mvo: so I went to commit --amend, but couldn't commit it since it is protected
<jdstrand> mvo: so I created pr 7229 with no code changes (which I see now you approved), and all weekend I've tried to get the thing to pass tests, but it won't ever pass
<jdstrand> mvo: (different failures each time. probably tried 10+ 'restart builds' for the individual integration tests
<jdstrand> mvo: is there something else I should be doing?
<mvo> jdstrand: yeah, its a bit annoying right now, we are working on this currently to fix the test situation - sorry for this
 * jdstrand can keep mashing restart build
<jdstrand> mvo: ok. I guess from your approval, I did the right thing with an errata commit?
<jdstrand> mvo: after doing the wrong thing by not changing the first line of course :)
<mvo> jdstrand: just to make sure I understand> the commit that needs an errata is already on master, yes?
<abeato> jdstrand, morning! I added a couple of comments in https://github.com/snapcore/snapd/pull/7173 , could you please take another look?
<Chipaca> gah, just as i settle in to the hangout, 2fa
<Chipaca> and it's at the other end of the house
 * Chipaca untangles himself and goes get
<zyga> I am not coming today
<zyga> Just FYI
<pedronis> mvo: standup?
<Chipaca> zyga: why tho?
<mborzecki> mvo: pulseaudio -k and restart chromium?
<pstolowski> ijohnson: wdyt: https://github.com/snapcore/snapd/pull/7234 ?
<jdstrand> mvo: yes. I commited to master. the code is correct. all of the commit messages is correct except the first line. I would've done a commit --amend but couldn't due to protected branch, so have the empty errata commit instead
<jdstrand> abeato: yes, planning on going through PRs today/tomorrow
<abeato> jdstrand, ok, thanks
<zyga> Chipaca: on a train
<zyga> No laptop
<Chipaca> zyga: is it a CI train
<mvo> Chipaca: lol
<tomwardill> any idea why a core refresh will cause my HDD that's in standby to wake up?
<popey_> tomwardill: yeah, the whole re-mount the world does that for me too, always has
<tomwardill> minorly irritating, as that drive is the noisiest thing in my PC
<zyga> tomwardill: probably udev trigger / settle
<Chipaca> popey_: quick question about your mysterious numbers-don't-appear thing: do you have the noto font(s) installed? does the issue go away if you remove 'em?
<Chipaca> whoa, suddenly very dark here
<diddledan> did you unleash the end of days, again?
<Chipaca> le ciel va nous tomber sur la tÃªte!
<diddledan> tuesday
<Chipaca> all I did was eÌ½ÌÍÍÌÍÌÍÌºÍÌ¦Ì¦Ì¬Ì©Ì Ì·mÌÌ½ÌÍÌÍ ÍÌÌÌ³Ì¡Ì»Ì»Ì©ÍÌ¼eÌÍÌÍÍÌÌÌÌÍÍÍÍÌ«ÍÌ®ÍrÌ¿ÍÌ¾ÌÌ¾Ì¥Ì¯Ì»Ì£Ì­Ì¡Ì¥ÍÍÌ©gÌÌÌÌÍÌÌÌÌÌÌºÌÌÍÌ­Ì eÌÍÌÌÍÌÌÌ­ÌÍÌÌ¦Ì¤ÌºÌ¶ sÍÍÌÌ¿ÍÌÍ¡ÌÌÍÍÌ»Ì°Ì°ÍÌÌ£Ì»Ì¶kÍÍÌÍÌÌÌÌÌÌ¯ÌÌ²ÍÍÌÌ¹yÍÌÌÌÍÌÌÌ¤ÌÌ²ÌÌ
<diddledan> that looks decidedly like the spell to raise the dead
<marcustomlinson> woah
<diddledan> related query, you're running Gentoo?! :-o
<Chipaca> no, of course not
<diddledan> phew
<Chipaca> obviously it's sabayon
<diddledan> :-p
<popey_> Chipaca: lemme try
<popey_> Chipaca: you win a cookie
<Chipaca> popey_: I'm already 300kcal over my budget, but thanks
<cachio> Chipaca, hey, any idea how to skip catalog update?
<cachio> https://paste.ubuntu.com/p/bQ7cSX4Dss/
<cachio> on our tests to prevent this error?
<mvo> Chipaca: can we merge 7208 (green and plenty +1)?
<Chipaca> mvo: if that is tab completion, i wanted to add a check that zyga asked about
<Chipaca> cachio: we should be able to, gimme a mo'
<cachio> Chipaca, tx
<mvo> Chipaca: ok
<Chipaca> cachio: touch /var/cache/snapd/sections before starting snapd should be enough to not refresh
<Chipaca> cachio: OTOH, we should totally catch that 429, now that it's there
<cachio> Chipaca, that's true
<Chipaca> I'll look into that
<Chipaca> cachio: do you have a bit more context around that error output?
<cachio> Chipaca, https://travis-ci.org/snapcore/snapd/jobs/570795886#L2314
<cachio> this it the error
<cachio> I talked to store team
<cachio> and they say we should avoid refreshing so much to prevent this error
<cachio> the is not other way
 * cachio afk
 * cachio lunch
<Chipaca> ok, i'm off to do gym stuff. I'll sneak in a 429 PR this evening, after closing one of my open ones.
<ijohnson> hey folks I asked in the PR description for my netplan-apply PR, but is it standard practice to include the source of a complicated snap that needs to be built with snapcraft inside the snapd git tree? I see a number of snapcraft.yaml's there so it seems the answer is yes?
<ijohnson> I see some tests also have the snap source inside the ~snappy-dev project, so is that a better place to put snapcraft.yaml sources for test-snapd-* snaps?
<mborzecki> ijohnson: i'd say that keeping the sources with snapcraft.yaml in tests/lib/snaps makes most sense
<ijohnson> mborzecki: ack I'll add my snapcraft.yaml for the test-snapd-netplan-apply snap to the PR then
<ijohnson> thanks
<ijohnson> also who should own the test-snapd-* snaps?
<mborzecki> ijohnson: hah, great question :P
<mborzecki> ijohnson: the owner should be canonical, but you have to transfer the snap
<mborzecki> ijohnson: let me look it up, there was some email you need to send to the store ml
<ijohnson> got it, thanks mborzecki
 * ijohnson lunches
<Chipaca> popey_: ok, went to the gym, now where's my cookies at
<popey_> Chipaca: i would give you an unicode cookie, but....
<Chipaca> popey_: too late, now i'm all fancy and only accept macaroons
<Chipaca> also it's tea time so pulled pork and veg is already in prep
 * Chipaca might be salivating in preparation
<mvo> I just merged 7231 so with a bit of luck master is green again
<ek926m> hey, I have a question, why my snapd service failed?
<ek926m> snapd.service: Triggering OnFailure= dependencies.
<ek926m> Failed to start Snappy daemon.
<ek926m> â snapd.service - Snappy daemon
<ek926m>  systemd[1]: snapd.service: Service RestartSec=100ms expired, scheduling restart.
<ek926m> pd.service: Failed with result 'signal'.
<ek926m> is there a way to find out, what caused this failure?
 * ijohnson relocates to a coffee shop
<diddledan> who maintains the docker snap? it's listed as canonical with an obsolete email address (snappy-devel@lists.ubuntu.com)
<roadmr> diddledan: talk to ijohnson
 * ijohnson hides
<ijohnson> what's up?
<roadmr> ð
<diddledan> ello. was wondering if we're gonna get any version bumps any time in the next year? ;-p
<ijohnson> for what?
<diddledan> </sarcasm>
<diddledan> docker
<ijohnson> ah okay, so actually the maintenance of the docker snap now falls on tianon
<diddledan> the contact info is out of date on it, too
<ijohnson> I know that there was some updates to the docker-support interface needed for 18.09 I think
<diddledan> aha
<ijohnson> those should have landed today in the stable channel though
<ijohnson> so hopefully tianon will be able to release
<diddledan> we're on 19.03 upstream now IIRC
<ijohnson> I will make sure the contact info is updated though
<diddledan> \o/ danke
 * diddledan hopes for new shiny features :-po
<diddledan> all the features!
<diddledan> something odd here:
<diddledan> https://www.irccloud.com/pastebin/QNEGGvGW/odd.txt
<ijohnson> diddledan: where did that come from?
<diddledan> I was running `snap install mycroft_19.2.14_amd64.snap --dangerous1
<diddledan> --1
<diddledan> bad typo :-p
<diddledan> `snap install mycroft_19.2.14_amd64.snap --dangerous`
<diddledan> my layouts are:
<ijohnson> diddledan: what's `snap tasks --last=install` show?
<diddledan> https://www.irccloud.com/pastebin/qUSq5vIT/layouts.yaml
<ijohnson> ah you have layouts
 * cachio afk
#snappy 2019-08-13
<mborzecki> morning
<zyga> good morning
<zyga> hey mborzecki :)
<zyga> how was flock?
<mborzecki> zyga: hey
<mborzecki> zyga: flock was nice an interesting
<mborzecki> zyga: i'm slowly finishing the report, should send it out soon
<zyga> cool, looking forward to it
<zyga> mborzecki: how was yesterday with regards to master stability?
<mborzecki> zyga: still haunted by http2 protocol_error
<zyga> what about sbuild?
<zyga> is that magically better or fixed?
<mborzecki> zyga: afaik it occasionally hits timeouts
<mborzecki> zyga: also, mvo added a pr that retries when there's a http2 protocol error, it ought to be better now
<zyga> oh, that's good
<mborzecki> zyga: renewed my rhel developer subscription ;)
<zyga> mborzecki: cannog go wrong with buying IBM ;-)
<mborzecki> zyga: btw. need to investigate but snapd doesn't build on rhel8
<zyga> deps or tests?
<mborzecki> zyga: it looks like the go rpm macros are a problem
<zyga> of course :)
<zyga> https://github.com/snapcore/spread gives me 504
<zyga> is that just me?
<mborzecki> zyga: things like %gobuild_static are not expanded
<mborzecki> 504 Not Worthy ;)
<zyga> that's typical when the macro does not exist
<mborzecki> zyga: same here
<zyga> mborzecki: did you post the spread bugfix?
<mborzecki> zyga: not yet
<zyga> OK
<pstolowski> morning
<zyga> hey Pawel
<pstolowski> zyga: hey, what's the plan with the per-user-mount-ns PRs?
<zyga> pstolowski: it's all sad, I'm stuck behind layers of other bugs
<zyga> pstolowski: I will try to re-enable the mount measurement test now
<pstolowski> zyga: uhm i see :(
<zyga> pstolowski: at least on ubuntu where I think, it no longer fails
<zyga> we need spread fixes
<zyga> we need little test fixes (still quite a few)
<zyga> hmm
<zyga> sbuild test uses fastly
<zyga> I: Updating chroot.
<zyga> Hit:1 http://cdn-fastly.deb.debian.org/debian sid InRelease
<zyga> maybe it's all connected? :)
<zyga> brb
 * zyga fights more broken tests
<zyga> eh
 * zyga does reviews while tests churn
<zyga> spread output is unreadable
<zyga> there, I said it
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/7234
<pstolowski> zyga: huh
<jpe> Wondering where I can find info about how the isolation in snappy actually works? Google isn't really being helpful.
<zyga> jpe: hey
<zyga> jpe: I don't have any good one point of information
<zyga> jpe: if you want to look at the code I can give you pointers
<zyga> jpe: if you want to know the high-level picture I can tell you about that as well
<jpe> Well the code is a lot
<jpe> I see it uses apparmour somehow
<jpe> *armor
<jpe> It uses system image overlays similar to docker. So when you install an application you get the overlay for that application which sits on top of the core image. Then access to the system is controlled via apparmour?
<zyga> jpe: we're not using image overlays (not sure what that is), we use mount namespaces
<zyga> jpe: we use cgroups for device (block/char) control
<zyga> jpe: we use apparmor for file level control as well as some misc things, most notably dbus method access
<zyga> jpe: we use seccomp for syscall control
<zyga> jpe: the mount namespaces are used for reliablity mostly, they are not a method of control
<zyga> (much)
<jpe> I see so it's a combination of those three tings
<zyga> yes
<mborzecki> ok, report sent
<zyga> mborzecki: cool
<mborzecki> back to normal work
<zyga> mborzecki: I'm chasing flaky tests
<jpe> by image overlays I meant that you have an imutable 'disk image' like file which is mounted under the mountpoint namespaces.
<mborzecki> zyga: which ones?
<zyga> jpe: yes but in our case it's much different from what docker does
<zyga> mborzecki: how many fingers do you have :)
<zyga> mborzecki: I lost track, chasing one by one
<zyga> everything loves to leave mount points behind (in our test suite)
<zyga> mborzecki: then the usual random suspects
<zyga> mborzecki: protocol error on http2, sbuild, random timing sensitive test
<jpe> zyga: thanks i guess thats enough to get me started
<mborzecki> zyga: heh, the usual fun :)
<pstolowski> pedronis: hey, can I land https://github.com/snapcore/snapd/pull/7209 (it has 2 reviews) or would you like to take a look?
<pedronis> pstolowski: I would like to look at it quickly, wil do so today
<pstolowski> pedronis: great, thanks. i've also re-requested your re-reviews or some other PRs but i'm sure you have a lot to catch up with this week
<pstolowski> s/or/on/
<mborzecki> pedronis: hi, will you be able to take a look at https://github.com/snapcore/snapd/pull/7087 ? this is the last one
<pedronis> mborzecki: yes, but need to see in which order, my main task today is to go over PRs
<mborzecki> pedronis: sure, thank you!
 * zyga looks at sbuild test
<zyga> it's so annoying that it fails with no useful output
<zyga> sometimes it doesn't fail with "kill timeout reached" but just, sbuild failed, without any extra detail attached
<mborzecki> zyga: ha, yeah, so there's a way to extend the debug section and tail -<some-lines> of the log file
<mborzecki> zyga: if you have a shell, once the build completes, there's a log file in the test directory
<zyga> ah, thanks
<zyga> I'll check that out and include it
<pedronis> yes, we do need that, I remember once chasing a real failure there and being very confused
<pedronis> had to run it manually and stare at that log
<pedronis> (which is confusing in its own, so big)
<Chipaca> IDEA: close non-essential PRs until we get our PR count down
<Chipaca> also: close stale PRs
<Chipaca> also also: close all the PRs
<popey_> mark them WIP?
<zyga> Chipaca: idea, also holidays for everyone ;)
<Chipaca> zyga: yay
<Chipaca> popey_: nah, that doesn't help, they're all WIP one way or another
<Chipaca> popey_: we've got 85 WIP PRs
<popey_> merge them all then :)
<zyga> Chipaca: I would like to see a way to switch master into "emergency" mode where other PRs don't even get tested
<zyga> Chipaca: but yeah, I share the sentiment
<Chipaca> zyga: per-user mount namespace work
<Chipaca> zyga: from januhary
<Chipaca> januhairy
<zyga> Chipaca: I can close it, it's not going anywhere sadly,
<Chipaca> zyga: they're all our children, killing them might hurt a little bit
 * Chipaca eyes his children
<Chipaca> it would make things â¦ simpler
<zyga> done
<Chipaca> zyga: what's the status of #6714 ?
<Chipaca> zyga: do we need to request a re-review from j[d]strand?
<zyga> I think I need to implement a fallback case
<Chipaca> zyga: ah, i see he responded to my prior query there
<zyga> I didn't want to but there was a disagreement between people and that's what it is at
<Chipaca> zyga:  i mean, https://github.com/snapcore/snapd/pull/6714#issuecomment-495302513
<zyga> though I think this will break more things
<zyga> I need to return there without firefighter mode
<Chipaca> zyga: and #6891?
<Chipaca> (yes i'm going up PRs per person, backwards, meaning you got to go first)
<zyga> Chipaca: blocked by bugs elsewhere
<zyga> Chipaca: mainly tests leaking random cruft
<Chipaca> zyga: aren't those now fixed?
<zyga> Chipaca: snaps, system changes, et
<zyga> nope, we've found more and we learned about lxd more at the last sprint
<zyga> (we need to reboot after lxd test)
<Chipaca> zyga: ah, and that one was proving tricky?
<zyga> yeah, needs a patch to spread that mborzecki has
 * zyga finds aborting spread test broken
<zyga> how do I do that again?
<zyga> ctrl-c?
<zyga> ctrl-d
<zyga> killall -9 spread
<Chipaca> zyga: ^C will eventually shut it down
<Chipaca> it waits for the current test to finish iirc
<Chipaca> zyga: re #7205, should you tag who you want to comment?
<Chipaca> zyga: re #7225 can we close until the number of PRs is under control again?
<zyga> Chipaca: it runs more tests, I want to abort a test reliably, there seems to be no command to do so
<zyga> Chipaca: 7225 is in response to a PR from sergio, which I think makes our problems worse,
<zyga> Chipaca: number of PRs is not the problem
<zyga> inability to land them effectively is
<zyga> Chipaca: 7205 is something I want to discuss with pedronis and mvo tomorrow
<mborzecki> zyga: c-\
<Chipaca> zyga: 7225, why isn't that info in the PR?
<mborzecki> zyga: aka ^\
<zyga> Chipaca: because it was made at a sprint and I didn't include it, it's a draft, I don't think those need to be reviewed
<Chipaca> zyga: 7225 is not a draft
<Chipaca> zyga: ah, you mean 7205
<zyga> Chipaca: I was responding about 7205
<zyga> 7225 references the other PR
<Chipaca> zyga: just throwing a PR up when they're this many is not enough, you need to actively chase people
<zyga> yeah
<zyga> Chipaca: actively chasing people is not always possible (holidays/timezone), I agree but not sure what the outcome is
<zyga> close all the things does not help really
<Chipaca> zyga: 7225, yes but then it's set to blocked after a meeting, because it's not going to be merged for a while (when?), so... why leave it open at all
<zyga> if we want to review only stuff that helps with the stabilization effort let's say so, let's make a tag or project or whatever
<zyga> agree not to restart other PRs
<Chipaca> zyga: I don't want us to only review one flavour of stuff, I want us to review all the stuff
<zyga> Chipaca: IMO review is not the problem
<zyga> Chipaca: why cannot we land a typo fix?
<zyga> Chipaca: not because of reviews
<zyga> Chipaca: I think we fundamentally have issue with testing in the project
<Chipaca> zyga: the number of open PRs without two reviews disagrees with you
<zyga> Chipaca: high number is not a problem
<zyga> Chipaca: it's like saying we need to close bugs because we have two pages
<zyga> Chipaca: acting on them is what matters
<zyga> Chipaca: if we cannot act because everything takes forever to iterate we get into this kind of situation
<zyga> Chipaca: I don't disagree we need to focus reviews
<zyga> but I think open PRs is not the real problem
<Chipaca> zyga: let's just add more PRs then
<zyga> Chipaca: I think we both want the same thing, effective progress
<zyga> if you want we can HO and discuss
<zyga> Chipaca: can
<zyga>  you look at -- https://github.com/snapcore/snapd/pull/7242  -- it might help us to see what fails in sbuild
<pedronis> zyga: too many PRs is a problem, it indicates in most cases a lack of focus, both on the opening of, and reviewing side of them
<zyga> pedronis: do you think this is our actual problem now?
<pedronis> at some point is also a issue of being able to keep state on the open PRs at a personal/mental level
<pedronis> zyga: yes, more on the reviewing side of this equation but yes
<mborzeck1> quick errand, back in 30
<pedronis> zyga: the problem also with saying open as many PRs as you like, is no pressure on the authors on chasing reviews/conclusion on them
<zyga> I think it depends on how we approach reviews; IMO putting specific barriers in place just discourages contribution
<pedronis> zyga: barrier on what?
<zyga> on opening a PR
<pedronis> zyga: we are not blocking other people
<zyga> I meant ourselves
<pedronis> zyga: I don't really know were you are trying to go here
<zyga> pedronis: I was explaining my POV to chipaca about how I feel about the project
<pedronis> zyga: my main very rough suggestions stay the same, people on the team should try not to have more than 5 PRs open at a time, they should probably also not work on more than 2 main topics at a time
<zyga> pedronis: I have opened 4 PRs today, apart from drafts I have 6 other PRs that are mainly blocked by failing tests or by something else being broken preventing them from going in
<pedronis> zyga: if tests are failing then the team should fix the failing tests
<pedronis> not open PRs
<zyga> while I could close the other PRs (and the conversations there) until situation improves I think this is not really a meaningful improvement to our situation
<zyga> pedronis: that's what I am doing
<pedronis> zyga: to be honest I didn't suggest to close random PRs
<pedronis> that came from Chipaca
<zyga> pedronis: how do you suppose we fix anything without opening PR?
<Chipaca> that was all me :)
<pedronis> zyga: you are being silly now
<Chipaca> zyga: every PR open uses up the team's finite resources of attention and review ability. While right now we have issues with test, at least half of our open PRs predate that
<zyga> we do tend to get more revies for the stuff up top so that helps
<zyga> pedronis: that was a joke, but I'm not sure your comment was spot on, we are doing that I think
<pedronis> zyga: sorry, not really for joke, as long you believe that opening PRs is always good, we have a problem here
<zyga> pedronis: not always good, but should be a lightweight process because they land fast too
<zyga> I think that's the real issue
<pedronis> zyga: sorry, you just closed some month old PRs, they weren't being stuck by tests problems
<zyga> yes but I'm not disputing those
<zyga> cachio, Chipaca: https://github.com/snapcore/snapd/pull/7243
<zyga> another small test usability improvement
<zyga> mborzeck1: can you propose your fix to spread please?
<Chipaca> zyga: why do you say we don't remove base:core18 snaps? i recall no such logic
<zyga> Chipaca: on core systems we routinely don't remove snaps
<zyga> Chipaca: I was looking from the point of view of mounted filesystems, runs on ubuntu-core-16-64 left over pretty much all the snaps that had base:core18
<Chipaca> zyga: that's a bug in our reset.sh then I suspect, because we do reset the state afaik
<zyga> amazon has systemd 219, hmm
<Chipaca> zyga: so the way to fix that is in reset.sh's reset_all_snap, imho
<zyga> Chipaca: ah, indeed
<zyga> Chipaca: and I think I see the bug now
<Chipaca> zyga: unless the ones you're seeing are test-snapd-rsync or test-snapd-rsync-core18
<zyga> Chipaca: hold on
 * Chipaca onholds
<zyga> https://www.irccloud.com/pastebin/yd7O7ve9/
<mborzecki> zyga: opening a PR in a bit, doing some final testing
<zyga> mborzecki: thanks!
<zyga> Chipaca: we never removed them correctly
<diddledan> document.getElementById('chipaca').addEventListener('hold', e => 'firm grasp!');
<diddledan> :-)
<diddledan> javascript for the evil!
 * Chipaca rejects outright any rumours about being evil, and casts the defamatory individuals into the Pit
<diddledan> dangit, not again
<zyga> cachio, Chipaca https://github.com/snapcore/snapd/pull/7244
 * Chipaca remembers to remove diddledan's rope ladder this time
<Chipaca> zyga: I'd refactor that to use an array, but maybe not today
<zyga> Chipaca: yeah, one at a time :)
<diddledan> I can reliably reproduce layouts breaking with my mycroft snap but can't seem to build a simple testcase that is as reliable https://www.irccloud.com/pastebin/AhbwBUUa/
<pedronis> does that mean we can close 7241 ?
<mborzecki> zyga: https://github.com/snapcore/spread/pull/85 enjoy
<zyga> pedronis: yeah, I just commented there
<zyga> closed now
<pedronis> zyga: how are you tracking to reopen 6714 ?
<pedronis> is there a trello card? or something else?
<mborzecki> Chipaca: pinged you in the spread PR too :)
<Chipaca> saw it
<zyga> pedronis: there's still a bug for it, I will check if there's a card
<mborzecki> hmmm, spread PR queue has grown
<pedronis> in general I'm not a fan about closing PRs that are not just nice to have, just for the sake of PR count
<cachio> zyga, checking
<Chipaca> zyga, pedronis, FWIW is:closed is:unmerged is:pr author:zyga helps
<pedronis> Chipaca: except it's very large
<ogra> jamesh, hah, you rock, how did you manager to get the idea he looks for ant-media-server ? that would have never striked me ...
<diddledan> here we go - reproducer: https://github.com/diddlesnaps/layout-fail
<diddledan> oh, it looks like I've already filed it: https://bugs.launchpad.net/snapd/+bug/1808821
<diddledan> assigned to zyga :-)
<zyga> diddledan: how does it fail?
<diddledan> zyga: I've updated the bug
<zyga> diddledan: I see now
<zyga> hmmm
<zyga> sbuild failed again
<pedronis> flaky unit test?
<pedronis> or something else
<zyga> tests/main/spread, kill timeout
<zyga> no further information :/
<pedronis> we should ask cachio to debug, whether is just taking long to start with
<pedronis> or some unit test blocks sometimes?
 * diddledan rocks out to popeycore music
<diddledan> "music"
<cachio> pedronis, zyga I am working with sbuild right now
<Chipaca> diddledan: no, popeycore is a dress style, like dadcore but more extreme
 * Chipaca goes to have lunch before he gets himself in trouble
<diddledan> :-p
<cachio> zyga, pedronis still not possible to reproduce the error running here
<diddledan> Chipaca: you're as bad as me. and I'm worse :-p
<popey_> popeycore is a core laptop, no sound :)
<mborzecki> pstolowski: really simple selinux fix https://github.com/snapcore/snapd/pull/7245
<diddledan> aah, art nouveau music, popey_ ?
<popey_> hmm, are there any command line (curses) music creation apps?
<mborzecki> diddledan: speaking of art nouveau, couple years back, you could listen to your hard disks by running dd if=/dev/hda of=/dev/dsp
<pstolowski> mborzecki: +1
<diddledan> :-o
<mborzecki> pstolowski: thanks!
<mborzecki> pstolowski: i'll force push that little tweak
<mborzecki> pstolowski: or not, there's more places that could use a similar format change
<pstolowski> is there? Ok, nvm then
<popey_> https://github.com/danfrz/PLEBTracker  oooh
<pedronis> #6950 needs a 2nd review
<cmatsuoka> Chipaca: I see in master that create-user is still using the v2/create-user api, how should user removal be handled now?
<cmatsuoka> Chipaca: is there a new api that covers all user creation/removal operations?
<Chipaca> cmatsuoka: last I heard we were blocked waiting for field input
<cmatsuoka> Chipaca: ah ok, so I'll wait as well, thanks
<Chipaca> cmatsuoka: mvo might know more
<popey_> What exactly needs to happen (beyond editing a seed file) for tmux (which is in main) to be added to ubuntu core images?
<zyga> diddledan: debugged now
<Chipaca> popey_: you need to make the case that it's worth it, i guess?
<Chipaca> popey_: one place to start would be with ogra, wrt size impact
<ogra> me ?
<ogra> i doubt i still have a say :)
<ogra> i'd vote for screen instead of tmux though
<popey_> I spoke to jdstrand about it at the summit, he "voted" for tmux over screen
<popey_> (upstream screen is dead AIUI)
<ogra> he never uses serial terminals :P
<popey_> that's a different use case
<popey_> I'm talking about a terminal multiplexor here, not a serial console
<ogra> well, it is a usecase that screen includes
<Chipaca> ogra: how does 'cu' compare to screen?
<ogra> (and i use serial terminals from core to talk to attached devices...)
<popey_> what do you use now?
<ogra> dunno, i think i only have used cu once in my life several years ago
<ogra> popey_, screen from a chroot, classic snap or lxd
<jdstrand> I did advocate for tmux, yes for a multiplexer. a multiplexer does seem like something that should be in core. if screen addresses other use cases, I would not be opposed to screen
<popey_> Ok, I personally dont care too much either way. However we have had this conversation multiple times over 2 years.
<popey_> I wondered who I have to nail down to get it
<jdstrand> we even had verbal agreement it should be in core :)
<Chipaca> ooh
<Chipaca> maybe it's just a PR in core then?
<jdstrand> iirc, mvo liked the idea, but this was before core18 was heavily pruned, and I wasn't part of those coversations
 * jdstrand notes that screen is and will continue to be in main for the foreseeable future
<popey_> despite not having a release for 2 years?
<jdstrand> oh yes
<jdstrand> inertia
<ogra> it is "stable" !
<ogra> (though i recently had actual issues with it ... new rockchip boards use hilarious serial speeds that screen doesnt support OOTB)
<ogra> (1,500,000 baud by default)
<jdstrand> I mean, I strongly prefer tmux for maintenance, but it is hard to imagine screen going away. if screen is meeting real world use cases for core that tmux does not, I'm just saying it can be there from an Ubuntu maintenance perspective
<ogra> well, i'm probably a special case ... but it helps to debug stuff attached via serial to core
<jdstrand> that said, popey_ and I are talking about a good multiplexer that a lot of users have asked for and something a snap cannot ship. ogra is talking about serial consoles-- perhaps that continues to be a chroot/lxd/classic snap thing
<ogra> not sure many people would do it that way
 * jdstrand doesn't know
<popey_> I'm currenly using screen on my core laptop, which I copied out of the deb into ~/bin which is messy
<popey_> well, if screen is still maintained, size-comparable and can hit two birds with one stone, I don't see why not?
<ogra> using it is messy ? or the way you got it running ?
<ogra> (does it work correctly just copying the bin ?)
<jdstrand> it would feel slightly weird to put something so ancient as screen into core, but then, it isn't like glibc is that fresh (it is very well maintained though)
<ogra> well, flip a coin :) i'm not pushing that hard for it, it just would make more sense imho
<jdstrand> it is true that tmux does not support serial console. it would seem to me an unusual use for a core device to need a serial console program since I would expect one to use such a program to connect to the serial console of the device instead of the other way around
<jdstrand> both screen and tmux are part of ubuntu-server, but no where else
<popey_> ogra: it works like that, yes
<jdstrand> tmux is a modern multiplexer with healthy upstream whereas as screen is a very mature application
<popey_> that was my main reason for choosing tmux
<jdstrand> I very strongly advocate for a multiplexer in core. if I had to vote, I would vote tmux
<popey_> do a pr against the seed and we poke people until it lands ? :)
<jdstrand> is it just a seed? I mean, I could just do it...
<jdstrand> but no, I won't do that without mvo or pedronis saying it is ok :)
<jdstrand> oh, and I have used cu in the past with mixed results as a serial console. screen has always worked better. I'm not sure if that is a pebkak thing, a docs thing or a software thing
<ogra> just dont forget that 90% of core installs are headless/userless anyway
<ogra> we are some special breed being developers that log in to it
<popey_> Sure, but it's also useful during development
<jdstrand> the problem is that it can't be a snap
<popey_> When migrating from ubuntu server to ubuntu core
<pedronis> it seems a case where one would install the classic snap and use it from there?
<ogra> note also that nearly all relevant developer tools were dropped on the switch to core18
<popey_> you can't install classic snaps on core pedronis
<jdstrand> pedronis: that is what people do, but that doesn't work well to use it as part of your regular workflow
<ogra> so i'm not sure what adding a multiplexer means while you cant even touch the bootloader config anymore and such
<pedronis> popey_: I mean the classic snap,
<pedronis> not classic snaps
<ogra> heh
<popey_> NAMING!
<ogra> we really need a new name at some point
<jdstrand> the classic snap (or an lxd container) puts you in a box, not on the host
<ogra> right
<popey_> it's additional overhead too
<jdstrand> and people want a multiplexer for working on the host
<ogra> sure, buit given all the removals in core18 we dont really encourage development on the host anymore anyway
<jdstrand> tmux is 500k
<ogra> thats not actually small
<ogra> (not really big either though)
 * jdstrand wasn't using it as justification
<ogra> screen is 425k it seems
<ogra> so not much difference here
<jdstrand> but it has supporting files
<popey_> they'll also be compressed
<jdstrand> idk how much they are needed
<ogra> well, popey_ said he got along with only copying /usr/bin/screen
<ogra> not sure if thats also true for tmux
<jdstrand> the tmux package has no supporting files. I didn't look at deps
<jdstrand> tmux could be a snap if we created the (gasp) classic *interface*
<popey_> well, it was a case of installing classic, jumping into classic, installing screen and finding the binary and copying it out
<popey_> not just copying /usr/bin/screen
<jdstrand> which has been discussed from time to time
<ogra> does it really need full classic access ? not just some files that would justify a "tmux-core" interface or so ?
<popey_> it needs to launch arbitrary binaries
<ogra> oh, right
<jdstrand> it needs to be able to run anything on the system. plus there is a setuid component
<ogra> not just shells
<ogra> yeah, i fogot that the shell you start indeed runs inside tmux
<jdstrand> so, if we wanted a tmux-support interface, I could *perhaps* make it work without modifying tmux
<jdstrand> it would need an installation constraint. the idea would be that I let it do what it needs to do, then use a 'ux' rule to the shell
<jdstrand> this is hand-wavy
<jdstrand> I still maintain that a multiplexer should be in core. tmux isn't only for development. admins use it and we provide ssh for admins
<ogra> anyway, i think the decision process is somewhere between pedronis and foundations ... though if we add it, the question is, shopuldnt we also add keymaps, locales etc etc ... since we turn it into an actual developer image
<ogra> ... where do we draw the line
<popey_> I don't see that we're making it a developer image
<popey_> it's just a useful tool
<jdstrand> as mentioned, not for devel, for admins. devs get a nice tool in the process as a side effect
<pedronis> jdstrand: is #6767 on your list?
<jdstrand> that's right, it is setgidness (utemper)
<Chipaca> brb, need to reboot
<ogra> jdstrand, what admins ?
<ogra> you usually control core from some central mgmt tool via snapd-control
<ogra> and dont usually even have an account on actual products
<jdstrand> ogra: there are more than devs connecting to ubuntu core via ssh. those people
<ogra> well, talking from a product/sales perspective here ...
<jdstrand> sure, but that doesn't mean that others don't create that user. we know of customers that demanded certain user features
<jdstrand> and they even had a management snap
<jdstrand> some want ssh as an escape hatch
<ogra> i havent seen a single sale in the recent months where it was actualy not requested to *avoid* logins
<jdstrand> I am not saying it is a primary use case, I'm agreeing with popey_ that it is a useful tool
<ogra> but indeed, brand-store owners can sping own images and add system users at will
<ogra> *spin
<ogra> jdstrand, but so is nano for many people ...
<ogra> shoudl we add it too
<ogra> ... and typing on a non-us keyboard
<jdstrand> ogra: but there is no multiplexer in core. there is an editor
<popey_> (I have nano in ~/bin too :( )
<ogra> hahaha
<ijohnson> popey_: snap install nano --devmode
 * ijohnson hides
<ogra> yeah
<jdstrand> yours is an argument to have tmux and screen when there is only tmux. mine is pick something :)
<ogra> well, my question is if we need it urgent enough to add it :)
<ijohnson> fwiw I would love to have tmux just for terminal multiplexing
<ogra> (either of them)
<jdstrand> pedronis: re 6767, that and whole bunch of others
<pedronis> jdstrand: ok, just double checking, it's a target for 2.41
<ogra> but as i said, not really my decision anymore anyway
<jdstrand> pedronis: I'll take a looked at the milestoned 2.41 PRs and do them first
<jdstrand> look*
<ogra> i'd personally take screen is what i said ... thats all ... for multiplexing on logout we have nohup installed
<pedronis> jdstrand: thx
<ogra> for multiplexing sessions there is indeed nothing
<jdstrand> pedronis: I'm going to do a push to get through as much as I can today/tomorrow, then get back to k8s/pulse
<pedronis> jdstrand: I was back from holiday yesterday, I will go over your deamon user PRs in the next couple of days
<ogra> (though i bet you can use nohup as session multiplexer when doing some scriptery)
<ogra> but that would most likely become tmux re-implemented in shell :)
<jdstrand> pedronis: thanks. fyi, while not terribly urgent, I redid PR 6436 some time ago based on your feedback. it is ready to re-review
<jdstrand> (system-backup)
<jdstrand> popey_: I took 30 minutes to explore a tmux-support interface. I think it is possible: set seccomp to unrestricted, opt out of the devide cgroup, apparmor allows transitioning/transitions to unconfined, ship utmpter as setgid root. this gives everything except the hosts /tmp
 * cachio afk
<jdstrand> popey_: actually, no, it doesn't allow running snap commands
<jdstrand> this is seriously, really best as a part of core
 * zyga breaks
 * ogra looks for the glue
<abeato> jdstrand, afaik one thing that screen does and tmux not is access to serial devices (/dev/ttyUSB* and the like), which is incredibly useful if you are connected to a serial console or something like accepts AT commands
<ogra> yeah, on-device GSM modems and such
<abeato> or bluetooth devices too
<ogra> ah, indeed
<abeato> zigbee, etc.
<ogra> that sounds like another point for screen over tmux
<pedronis> ijohnson: Chipaca: I did another pass over #7149, there is a bit of confusion about how error kinds work there, Chipaca can also help in that area
<ijohnson> thanks pedronis I'll take a look now
<pstolowski> ijohnson: hey, a small hint re hotplug wrt to the forum topic about serial port
<pstolowski> ijohnson: i think you looked at serial_port - HotplugDeviceMethod and concluded id vendor/model are the required attributes; this aspect may be confusing - you should be looking at hotplug.go - defaultDeviceKey() and attrGroups list. there are 4 groups of attributes we look into, and we require >=2 attributes from those groups to be present
<ogra> pstolowski, interesting ... how would you actually do GPIO via hotplug ... they dont exists until you "echo $gpionum  >/sys/class/gpio/export" which is what only the gpio interface does today once you connect to it actively ... (so the device doesnt show up until the interface gets connected, no udev  stuff going on afaik)
<ogra> (i'd love if we could do them more dynamic ... but the concept doesnt sound like it could work)
<ogra> (referring to your forum answer ... i dont want to bloat the thread with offtopic chatter)
<pstolowski> ogra: ok, maybe i said something silly.. i think i remember zyga suggesting gpio discovery like this, but that was long time ago in early days of hotplug, maybe i misremembered it
<ijohnson> pstolowski: thanks for the pointer, I had missed that part
<ogra> well, i'd love if we could find a way to use hotplug for them ...
<ogra> but i dont thing tieing it to hotplug will work for this... that might need a new mechanism
<ogra> s/hotplug/udev/ (sorry)
<ijohnson> pstolowski, what if in the HotplugDeviceDetected method for the serial-port interface we also checked to see if ID_BUS was "pci", that would probably work for this specific device they have
<ogra> pstolowski, something like reading from the devicetree (via /sys/firmware/devicetree/base/) could work for them though ...
<ogra> yeah ... that would likely work: https://paste.ubuntu.com/p/bwxppNgtp6/
<ogra> (would need some filtering to find gpio-only interfaces, i.e. not spi or i2c)
<pstolowski> ijohnson: yes, absolutely, although we should look at device key compuitation and possibly make pci path a part of the key for such cases (based on ID_BUS?). every hotplug interface can define HotplugKey method to override how unique key is computed
<ijohnson> pstolowski, for this specific case, it already would qualify with ID_VENDOR_ID=0x8086 and ID_VENDOR_FROM_DATABASE=Intel Corporation for the vendor attr group
<ijohnson> so I think all that would be needed to unblock this specifically is that check that the ID_BUS matches usb
<zyga> cachio: can you disable sbuild test until we know what's wrong
<zyga> cachio: it's blocking all activity
<pstolowski> ijohnson: it needs 2 attributes from different groups, so vendor + model from the other group. yes. i'd extend this with path though for static devies to make sure we handle multiple devices with same vendor+model (in the absence of serial#). and yes we have a problem there afaict if serial is not present
<pstolowski> in that multiple instances of same device with no serial will not be distinguished
<pedronis> pstolowski: I made a comment in 7209, my plan is much more complicated though :/, let me know what you think
<pstolowski> looking
<ijohnson> pstolowski, oh I see what you're saying sorry I misunderstood you before I thought it needed 2 from the same group
<ijohnson> pstolowski: when you say extend it with path for static devices, do you mean DEVPATH which in the code is di.DeviceName()? that's already set in the proposed slot attributes returned from HotplugDeviceDetected method for serial-port interface
<ijohnson> err wait I read wrong - currently the code uses DEVNAME as di.DeviceName(), are you saying it should be extended to instead use "path" attribute in the proposed slot as the value of DEVPATH
<ijohnson> i.e. `"path": di.Attribute("DEVPATH")` or thereabouts
<pstolowski> ijohnson: yep, it should use whatever attribute makes that static device unique in the system (DEVPATH looks ok); it only makes sense for static devices. it must be made part of the hotplug-key which is crucial for hotplug logic and tracking of devices
<ijohnson> pstolowski: so is the hotplug-key determined from the attributes which are returned from HotplugDeviceDetected in the hotplug.ProposedSlot?
<pstolowski> ijohnson: and note it's strictly about hotplug key which is internal to snapd, it is not about what we expose as attributes of a slot to the user
<pstolowski> ijohnson: no. it's computed by defaultDeviceKey() method in hotplug.go from the predefined groups of attributes - OR - by optional HotplugKey(..) method of the interface, if defined.
<ijohnson> ahh I see that HotplugKey isn't defined for the serial-port interface so that's why I didn't see it
<pstolowski> ijohnson: so if we know a specific interface needs specific logic for some devices - such as serial port & static ports with pci bus, we can override key logic just for serial port
<pstolowski> ijohnson: so far have just serial port interface and no such use cases, so it's a bit hard to follow ;)
<pstolowski> *we have
<ijohnson> pstolowski: so can an implementation decide in the HotplugKey method to instead use the defaults instead of always providing it's own?
<ijohnson> then for serial-port we could have a check, if it's pci then the interface will provide it's own including DEVPATH which will be unique, if it's usb then just use the default from defaultDeviceKey()
<ijohnson> it looks like if HotplugKey returns deviceKey as "", then it will fall through and use the default one
<pstolowski> ijohnson: yes. serial-port can implement HotplugKey method and return an empty key, in which case we fall back to default computation - see https://pastebin.ubuntu.com/p/zPzqVM5xDX/
<ijohnson> so I think that would work
<ijohnson> yeah haha I just found that function
<ijohnson> good that I'm on the right path
<pstolowski> ijohnson: what's a bit undefined and missing in the enitre story is versioning of hotplug keys in case they are returned by HotplugKey of an interface. we will need to address this at some point
<pstolowski> ijohnson: versioning may be needed in case we need to change how keys are computed (e.g. new attributes added, affecting how key looks for existing devices)
<ijohnson> hmm yes that does look complicated
<ijohnson> pstolowski, pedronis: do you think versioning keys from the HotplugKey method of a hotplug implementation would block adjusting serial-port to work for this pci case?
<pstolowski> ijohnson: imho no, i don't think so - on the basis that this is still experimental
<ijohnson> okay, cool I'll give it a try and push something up to try and unblock this person's use case
<pstolowski> ijohnson: we should probably use 0 as version, like we do with default keys for now
<ijohnson> that sounds good
<pstolowski> ijohnson: fyi we have a nested vm test for hotplug & serial-port
<pstolowski> pedronis: commented on #7209
<ijohnson> right I'll try to look at that as well
<pstolowski> ijohnson: i don't think you'll be able to extend this for new use case, but at least it can prove no regressions
<pstolowski> ijohnson: i think pedronis or mvo should ack this change, so we don't commit to providing something we need to remove later (although it looks relatively uncontroversial to me)
<ijohnson> yes I was going to request reviews from them as well
<pstolowski> cool
<cachio> zyga, #7246
<cachio> plase approve :)
<ijohnson> cachio: if it's any help I approved that too
<cachio> ijohnson, sure, thanks!!
 * cachio afk
<ijohnson> jdstrand: did you see my question in the PR description of #7214?
<ijohnson> (thanks for the review BTW)
<jdstrand> ijohnson: oh, I didn't, let me look
#snappy 2019-08-14
<mborzecki> morning
<mvo> hey mborzecki ! good morning
<mborzecki> mvo: hey
<mborzecki> mvo: can you also cherry pick https://github.com/snapcore/snapd/pull/7188 ?
<mvo> mborzecki: sure thing
<mborzecki> mvo: thanks
<mvo> mborzecki: thank *you* and done
<mborzecki> mvo: oh, and a PR to spread with workarounds for bash 4.3 is open https://github.com/snapcore/spread/pull/85
<mborzecki> this will unblock https://github.com/snapcore/snapd/pull/7198
<mvo> zyga: does 7194 look good now?
<mvo> mborzecki: nice, let me have a look
<mvo> mborzecki: do you have more background on 7192, i.e. why not just use curl in bin/download-file? or was this discussed already?
<mborzecki> mvo: nope
<mvo> mborzecki: thats fine, I asked in the PR
<mvo> mborzecki: did you see the question of samuele in 7087?
<mvo> mborzecki: this is super close otherwise it seems
<mborzecki> mvo: yes, i'll be adding a unit test there
<mborzecki> snapd on rhel8 https://paste.ubuntu.com/p/Qdd9btRB6m/ :)
<zyga> good morning
<mborzecki> zyga: hey
 * zyga is waking up
<mborzecki> and lxd from snaps works on rhel8 too
<mvo> mborzecki: nice
<zyga> simple one https://github.com/snapcore/snapd/pull/7247
<zyga> simple but not as trivial https://github.com/snapcore/snapd/pull/7248
<zyga> mvo: I'd like to discuss this idea with you and Samuele today https://github.com/snapcore/snapd/pull/7205
<zyga> ERROR: Conflicting profiles for /usr/lib/snapd/snap-confine defined in two files:
<zyga> - /etc/apparmor.d/usr.lib.snapd.snap-confine
<zyga> - /etc/apparmor.d/usr.lib.snapd.snap-confine.real
<zyga> something is leaking .real vs plain profile
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/7249 asked neal for a review too
<zyga> +1
<mvo> zyga: the conflicting profiles one I did see before
<mvo> zyga: it seems random? or conistent?
<zyga> I think it is deterministic if a pair of tests run in the right order
<zyga> Iâll try to track it down
<mvo> zyga: let me have a quick look, I have an idea
<mvo> zyga: do you have a link to the log wit hthe conflicting profile? or remember on what distro release this happend?
<pstolowski> morning
<pedronis> hello
<mvo> hey pstolowski and pedronis !
<zyga> mvo: in a moment
<mborzecki> pedronis: pstolowski: hey guys
<mvo> 7250 will unbreak master
<ondra> zyga ping
<mvo> zyga: I have a theory about the snap-confine profile duplications, digging deeper right now
<pedronis> mvo: zyga: either of you should do a pass over #7111 as well
<ondra> zyga remember that update error we looked at, it seems to be persistent over reboots and pulling in PR #7248 did not change this
<zyga> mvo: re, sorry, I had an interrupt at home
<zyga> https://www.irccloud.com/pastebin/dU2IZcA2/
<zyga> pedronis: looking at 7111 now
<zyga> ondra: which one?
<mvo> zyga: thanks! I am testing a possible fix right now
<mvo> pedronis: thanks, will look at this
<zyga> pstolowski: huh, I just saw this failure in unit tests
<zyga> https://www.irccloud.com/pastebin/4BaGpA43/
<pedronis> pstolowski: #7250 is probably something you can +1 quickly
<pedronis> zyga: mvo has a PR for that
<pstolowski> pedronis: looking
<pedronis> mvo: I did  a pass on most 2.41 things, quite a few of them now need work from the authors though
<pedronis> couple are from me and need more reviews
<mvo> zyga: 7251 should fix the snap-confine duplicated profiles error (it seems this one was real :(
<mborzecki> GpioControlInterfaceSuite.TestSanitizeSlot unit test failing locally here, does that happen for anybody else too?
<mvo> mborzecki: there is a PR to fix this
<mvo> mborzecki: 7250
<mborzecki> mvo: thx
<mvo> sry, too much got merged in a short time
<ondra> zyga or is that wrong PR I used?
<ondra> zyga was it #7205?
<pedronis> mvo: 7251 is a bit :(
<mvo> pedronis: yes, its pretty terrible
<mvo> pedronis: this is a bug for ages :(
<pedronis> looks like we fix this many times but never tested properly?
<pedronis> or am I missing something
<ondra> zyga sorry I tested with #7205
<mborzecki> duh, spread tests failed in 7250 :/
<mvo> pedronis: yes, it looks like this was lacking a proper test
<mborzecki> and restarted now
<ondra> zyga here is the error https://paste.ubuntu.com/p/ZMBh53Tqdp/
<ondra> zyga sorry I had to scramble snap names
<jamesh> there's something to be said for having a bot perform the actual merges to master
<jamesh> to avoid these race conditions
<zyga> ondra: ah, I remember now, I'm debugging it already
<zyga> ondra: it was re-reported yesterday in the public
<ondra> zyga ah cool
<ondra> zyga anything more I can provide?
<zyga> ondra: track https://bugs.launchpad.net/snapd/+bug/1808821 for updates
<pstolowski> mborzecki: what failed with 7250?
<zyga> mvo: *nice*
<zyga> mvo: so the maintainer script was always buggy?!
<mborzecki> pstolowski: timeout accessing the store api
<pstolowski> mborzecki: right..
<mvo> zyga: yes, it looks like it :(
<zyga> mvo: amazing
<zyga> thank you for finding it
<mvo> zyga: thanks, I was a bit depressed when I discovered it
<zyga> in other news, debian packaging is easy
<mvo> haha
 * zyga resumes system-usernames review
<pstolowski> zyga: lol
<pstolowski> @debian packaging
<mborzecki> Eighth_Doctor: updated the rhel8 PR
<pstolowski> fingers crossed for 7250
<Eighth_Doctor> uhh, yeah, no, debian packaging sucks
<Eighth_Doctor> the thing that makes it "easy" is that there's only a single distribution to worry about
<Eighth_Doctor> but the actual packaging mechanism? holy crap, someone should burn it with fire
<zyga> Eighth_Doctor: that's what I meant :D
<zyga> Eighth_Doctor: it's not easy at all
<mborzecki> Eighth_Doctor: slackware packaging is obviously superior :)
<Eighth_Doctor> ...
<zyga> I miss those days
<zyga> when you had floppy disks
<zyga> with nice graphical installers
<Eighth_Doctor> I think we can all agree that scripts suck
<zyga> that copied the three files in a few minutes
<Eighth_Doctor> haha
<zyga> or those floppies that still had dozen programs on them
<zyga> but those days are gone
<Eighth_Doctor> yep... Red Hat Linux days where you could find about 1/10 of the distro on a single floppy
<Eighth_Doctor> that's pretty much gone :(
<Eighth_Doctor> I haven't seen a package in a while that would fit on a floppy
<zyga> Eighth_Doctor: but on the upside, 8bit/16bit programming is re-surging in its own niche
<zyga> not just in artwork style but in actual 64K programs
<Eighth_Doctor> well, I had fun doing stuff like that when I was part of the Sonic scene
<mborzecki> Eighth_Doctor: 3.5'' floppies could fit a bit, 5.25 were more fun
<zyga> as things one can do in limited environment are on equal footing with everyone else
<zyga> Eighth_Doctor: I have a *box* of unopened floppies on a shelf here
<zyga> I had a USB 3.5 floppy drive but I think it was tossed a few years back
<zyga> it did work though :)
<Eighth_Doctor> I still have the USB floppy drive
<zyga> I would love to find it
<zyga> go with my 15"MBP to a cafeteria
<zyga> and use floppy disks, while looking after my beard ;D
<zyga> ok, back to reviews
<Eighth_Doctor> and I had to open the box of floppies I had for a thing... https://twitter.com/austinmcchord/status/646113834198003712
<Eighth_Doctor> hooking up that old 386 laptop to the internet was an... interesting experience
<pedronis> pstolowski: does the new suggestion in #7209 make sense?
<Chipaca> is master broken right now? I'm getting a unit test failure in master: FAIL: gpio_control_test.go:67: GpioControlInterfaceSuite.TestSanitizeSlot
<pstolowski> pedronis: yes, i like that (not that i didn't like the first suggestion)
<Chipaca> or is it a govendor thing
<pstolowski> Chipaca: yes, 7250 fixes it
<Chipaca> ah
<mborzecki> pstolowski: left some comments under https://github.com/snapcore/snapd/pull/7005
<pstolowski> mborzecki: yep just looking, thanks
<mborzecki> pstolowski: unit tests in that PR are failing on travis
<mborzecki> pstolowski: ah, because of the gpio unit test, ok, that's fine then
<zyga> https://github.com/snapcore/snapd/pull/7250 is yellow
<zyga> pedronis: I reviewed jamie's branch, resuming work on bugfixes from yesterday
<pedronis> zyga: thank you
<Chipaca> hmm, 7250 at 45' already
<Chipaca> t'internets are extra slow?
<zyga> hmmmm
 * zyga debugged and needs to think about how to solve it
<zyga> I think it's time for coffee to think
<zyga> brb
<zyga> if this was an office I'd offer you some
<zyga> you can always come and visit tho :)
<pstolowski> ..aaaand 7250 failed
<zyga> mvo: can you use your superpowers
<zyga> and merge it?
<zyga> I think we're just wasting time now
<pstolowski> +1
<mborzecki> heh, so i'm looking at the log
<mborzecki> it failed early, preparing ubuntu-16.04-32 host, but it ran the other tests anyway
<zyga> why did xenial 32bit fail?
<mborzecki> zyga: kill timeout, last log was +gdebi --quiet --apt-line ./debian/control
<pstolowski> we should really make spread fail asap
<mborzecki> pstolowski: i guess it depends on the phase, eg. failing early in project prepare sounds ok, but aborting the whole run when a task prepare fails is not useful
<zyga> mborzecki: I think it is
<zyga> it's not useful anyway
<zyga> you can run spread all you like locally
<zyga> but in travis, it's just wasting the time shared across the team
<mvo> zyga: sure, will do
<mvo> merged
<zyga> thanks!
<pedronis> pstolowski: mvo: I mentioned in https://forum.snapcraft.io/t/behavior-change-risk-only-channel-specifications-will-not-switch-track/11769/3 that it has landed for 2.41 , it should probably be linked from the roadmap
<pstolowski> pedronis: ah, i need to prepare a followup for snap info to report latest/.., it needs to land too
<cachio> mvo, hey
 * pstolowski lunch
<zyga> mborzecki: what was that magic randomness thing you used in the past?
<zyga> that package to get
<mborzecki> zyga: haveged?
<zyga> yep, thanks
<zyga> yesss
<zyga> two layout bugs fixed
<zyga> that's neat :)
 * zyga is happy today
<zyga> ondra: I think this includes a bug you reported now
<zyga> fired spread, writing proper docs and more unit tests
<zyga> brb
<Chipaca> zyga: is that two layout bugs that diddledan caused?
<diddledan> hello :-)
<diddledan> I should stop breaking things :-p
<zyga> Chipaca: yeah, those :)
<zyga> diddledan: the snap you reported, two bugs working in tandem :)
<diddledan> nice
<zyga> though either one is crippling
<diddledan> obscure, but nice
<diddledan> well done for getting them fixed :-)
<diddledan> I presume the fixed code will land in 2.41
<Chipaca> diddledan: hahahaha! landing. Ha.
<diddledan> I want 2.41 already for other reasons, too :-) (makemkv should finally be able to be strictly confined in 2.41)
<pedronis> #7130 needs a 2nd review, #7131 should also be reviewable now
<cmatsuoka> ondra: do you know if one can chainboot grub from littlekernel?
<ondra> cmatsuoka yes and no, in theory you can chain load grub from lk, but that would assume there is grub supported on that hw, and if that would be the case, one would use grub instead
<ondra> zyga good times! if you give me PRs I can test this right aways, as we are still using custom snapd anyway
<zyga> ondra: in 5 minutes, adding last unit test
<ondra> zyga sure thing :)
<Chipaca> pedronis: does we never have a model on classic?
<pedronis> Chipaca: we do
<Chipaca> hmm
<pedronis> always actually these days
<ijohnson> morning folks
<pedronis> because we carry a fallback
<pedronis> Chipaca: is that about your work? or one of my PRs?
<Chipaca> pedronis: 7130
<pedronis> we do have models on classic if we first boot at all
<pedronis> yes
<zyga> ondra: opening now
<Chipaca> pedronis: commented there
<pedronis> Chipaca: classic: true and base != "" is prohibitied
<Chipaca> ahhhhh
<pedronis> that at the level of assertions
<ondra> zyga nice!
<Chipaca> pedronis: how likely is that to change?
<pedronis> very unlikely if it's up to me
<pedronis> base: means a root fs base
<pedronis> there is no such thing on classic
<pedronis> the root fs comes from the host
<Chipaca> right
<zyga> ondra: https://github.com/snapcore/snapd/pull/7254
<zyga> diddledan: ^
<zyga> ondra: I'd love to know if this really does help you out
<zyga> ondra: so if you test this against your systems please let me know (either way)
<ondra> zyga yeah I will do it right now and let you know
<cmatsuoka> ondra: so to run core20 on e.g. the speaker all the dual-bootloader strategy would have to be bypassed and run LK instead, is that correct?
<ondra> cmatsuoka yep, with lk we can only use bootloader->kernel path
<ondra> cmatsuoka I know u-boot can chain boot, but I have not done it before
<ondra> cmatsuoka also be aware of some systems like Pi3, where pre u-boot bootloader constructs dtb, which does limit what you can do within u-boot
<ondra> cmatsuoka you are essentially committing to kernel version before u-boot is even loaded
<ogra> chainloading uboot from uboot is gambling .... it only works if both binaries come from identical source etc
<ondra> cmatsuoka example, you current kernel version is 4.15, chain loading into recovery system with 4.4 kernel will not boot, as early stage broadcom bootloader already constructed DTB for 4.15 kernel
<ondra> ondra and on Pi3, pre u-boot constructed DTB adds additional complication
<ondra> ogra hope you still have highlight on ondra, to make communication easier :P
<ogra> note that you *can* actually just load a different dtb from u-boot even on the Pi ... but you lose some bits that might be important for users (like the serial number that is used for paid mp2 codecs on that HW)
<ogra> ondra, ping :P
<ogra> yeah, still works :P
<ondra> ogra lol
<zyga> ondra: tell me if it works please, I'm hyped to know
<ondra> ogra yeah you can overide it of course
<ondra> zyga building :)
<ogra> right ... but the proprietary BL seeds some bits artificially into the devicetree in ram ... you can even read them out and then re-inject them into the new loaded dtb
<ogra> but thats a hell lot of scriptery
<ogra> and likely very error prone in the end
<joeubuntu> This week jdstrand is on the Ubuntu Security Podcast talking about snap security if you want to give it a listen: https://ubuntusecuritypodcast.org/episode-42/
<jdstrand> hope it's good!
<ondra> ogra remember I do have solution for this as well :)
<ogra> hacks hacks hacks :)
<ondra> ogra but you know how that story ended :P
<ogra> yeah
<ondra> ogra you call me hacker??????? Careful :P
<ogra> lol
<jdstrand> mvo: fyi, seeing that the snapd-master snap is failing review due to external symlink
<ondra> zyga still 20mins to build :(
<jdstrand> mvo: hi btw :)
<zyga> ondra: 20 minutes? ok
<roadmr> you hax0r you
<ondra> but will test as soon as built
<zyga> jdstrand: external symlink?
<ondra> zyga yeah building in lp
<ogra> jdstrand, btw, did you see abeato's comment wrt screen/tmux yesterday ... seems he actually has a pressing use-case for picking screen (bluetooth initialization and debugging as well as GSM modems)
<jdstrand> ogra: I did. thought bluetooth initialization suggests a snap trying to use it. maybe that would be in the gadget... another reason to have it in core
<jdstrand> s/thought/though/
<ondra> zyga trying local build on my arm now as well, but not sure if it will build as I have snapcraft from snap
<popey_> joeubuntu: ooh! I'll share it on our social channels
<joeubuntu> Thanks popey_ !
<ogra> jdstrand, yeah, i think it was more about debugging BT stuff via AT commands (which you need to do via "virtual" serial device)
<ogra> i guess alfonso can explain it better ...
<jdstrand> popey_: perhaps listen to it first? ;)
<popey_> lets say i did
<roadmr> AT commands!!!!
<ogra> the predecessor of everything internet !
<mvo> jdstrand: hi! oh? I need to check that
<mvo> jdstrand: thanks for letting me know
<jdstrand> np
<abeato> jdstrand, ogra well, I was just pointing out that I do use screen for that sort of stuff quite often. If I had to choose between tmux and screen I would prefer the former because of that additional funcionality
<abeato> but I also understand is not such a usual use case :)
<ogra> like mine ... (talking to addon boards via serial during development/debugging ... yet i think it is a usual use-case for embedded stuff)
<ogra> oh ah uh !
<ogra> there is a tool from the rpi foundation that loows loading overlays from userspace now !!
<ogra> https://github.com/raspberrypi/userland/tree/master/host_applications/linux/apps/dtoverlay
<ogra> *allows
<ondra> zyga yep with snap from snapcraft it fails with missing '/etc/apt/trusted.gpg'
<ondra> zyga so 10 minutes to go in lp
<jdstrand> zyga: yes, snap squashfs aren't allowed to have dangling symlinks pointing outside of the snap areas
<zyga> jdstrand: ahh
<abeato> s/former/later/
 * zyga broke for quick lunch
<Saviq> zyga: hey, when back, is it now safe to go core16 â core18 in a snap?
<diddledan> it wasn't before?
<zyga> Saviq: in 2.40, yes
<zyga> Saviq: some small issues remain but nothing major
<Saviq> w00t
<pstolowski> mborzecki, zyga: since you commented on #7081 some time ago, can you take another look at it?
<zyga> pstolowski: sure
<mborzecki> pstolowski: at, the MarkEdge bit
<pstolowski> mborzecki: what about it?
<mborzecki> pstolowski: 7081
<ondra> zyga hmmmm
<ondra> zyga did not fix it
<ondra> zyga rebooting to double check
<pstolowski> mborzecki: ? any problem there?
<ondra> zyga ha, after reboot it worked
<cachio> mvo, hey
<cachio> I see this error -> iptables: match "tcp" has version "libxtables.so.11", but "libxtables.so.12" is required
<cachio> I have libxtables.so.12 in the snap lib
<cachio> but it iptables snap is using the lib from the core snap
<cachio> I suppose that a dependency in the core is using this lib
<mvo> cachio: that is core or core18?
<cachio> mvo, core
<cachio> not tested on core18 yet
<cachio> mvo, should I?
<mvo> cachio: ok - does fiddling with LD_LIBRARY_PATH help?
<mvo> cachio: i.e. making sure that the snap path is before the system lib path?
<cachio> mvo, is not by default?
<cachio> ok
<cachio> I'll try tht
<cachio> :)
<diddledan> snapd doesn't set LD_LIBRARY_PATH by default
<diddledan> IIRC
<diddledan> if you have libraries you need to set them :-)
<diddledan> it might actually to $SNAP/usr/lib thinking about it but subfolders need to be added manually
<cachio> diddledan, ok, yes the rest of the libs are being used from the snap
<diddledan> do*
<cachio> but I think in this case it is getting the core ones because the caller is the core
<pedronis> jdstrand: I did a pass on the snap_daemon first couple of PRs (cc mvo)
<mborzecki> pstolowski: btw. i'm thinking, the edge markings can be done always, can't they?
<cachio> diddledan, I see the wrapper with export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$SNAP/lib:$SNAP/usr/lib:$SNAP/lib/x86_64-linux-gnu:$SNAP/usr/lib/x86_64-linux-gnu"
<cachio> I think the problem with this lib is that is also included in the core snap
<diddledan> that should cover it then
<cachio> the others dont
<pstolowski> mborzecki: yeah.. but what do you mean?
<cachio> mvo, diddledan thanks for your replies
<cachio> it should be easy to fix
<abeato> zyga, hey, could you retrigger the tests for https://github.com/snapcore/snapd/pull/7173 ? - that one should be ready for merging once they pass :)
<zyga> sure
 * cachio lunch
<pstolowski> Chipaca: wrt to what i brought up in the standup, it seems to be this is the only change needed: https://paste.ubuntu.com/p/63DP8hmsSM/ , then http://localhost/v2/find?name=lxd gives channels such as https://paste.ubuntu.com/p/SVBdrKw9p3/
<pstolowski> Chipaca: and here is what store gives us, for reference https://paste.ubuntu.com/p/rNSvgcw8pN/
<pstolowski> Chipaca: so it's the store giving short channel name if track is "latest"
<pstolowski> Chipaca: i see no explicit chopping on our side - except for our client side in cmd_info which special-cases "latest"
<pstolowski> Chipaca: makes sense?
<Chipaca> pstolowski: it does, I'd go hunting for something with branches to see how that is shown if at all
<Chipaca> pstolowski: (after the standup i took a quick look and agree with your findings)
<Chipaca> pstolowski: actually, nm about branches
<Chipaca> pstolowski: it's already the key of the map
<Chipaca> pstolowski: so just build it the once, and use it for both things :)
<Chipaca> pstolowski: ie chName := ch.Track+"/"+ch.Risk, then info.Channels[chName] = &snap.ChannelSnapInfo{ â¦,  Channel: chName, â¦ }
<Chipaca> pstolowski: makes sense?
<pedronis> Chipaca: seems you didn't address this comment https://github.com/snapcore/snapd/pull/7185/files#r310180105
<Chipaca> ah
<Chipaca> pedronis: missed it wrt the embedding
<pstolowski> Chipaca: yep. thanks for checking
<pedronis> Chipaca: left a couple nitpicks more
<Chipaca> pedronis: got it, thanks
<jdstrand> pedronis: ack, thanks
<pedronis> jdstrand: we are trying to cut 2.41 this week (cc mvo)
<jdstrand> roadmr: fyi, store still giving 504
<jdstrand> pedronis: ok, I had the bigger PR 6258 (dbus activation) and cgroupv2 PR I was going to do today, but I'll respond to the feedback in my PRs I got today/yesterday first
<jdstrand> pedronis: those two aren't 2.41 milestoned, so that should be ok
<jdstrand> pedronis: I did the other 2.41 milestoned reviews and quite a few others yesterday. I *think* it is just those two that are on outstanding for me to review
<cachio> pedronis, hey, google:ubuntu-14.04-64:tests/main/auto-refresh-private failed after "support seeding a classic system with ..." was merged
<cachio> pedronis, did it fail the test before?
<pedronis> cachio: no
<cachio> ok, I'll take a look in that case
<cachio> tx
<sergiusens> Hi there, question, is this error `- Download snap "u1test-snap-with-tracks" (5) from channel "test-track-1/beta" (stream error: stream ID 1; PROTOCOL_ERROR)` something you see often?
<cachio> sergiusens, there is a fix for this already merged on master
<cmatsuoka> sergiusens: I see it in tests
<sergiusens> great, that is where I am seeing it too
<cachio> cmatsuoka, mvo made a fix for that
<cachio> sergiusens, ~
<sergiusens> thanks for the quick response :-)
<jdstrand> pedronis: I responded to your comments in PR #7111
<jdstrand> pedronis: I need some clarification (https://github.com/snapcore/snapd/pull/7111)
<jdstrand> is the bot not around? I don't seem to be able to get it to spit out urls lately...
<mvo> jdstrand: thank you for prioritzing 2.41 - let us know if we can help, we could do trivial changes for you in our mornings if you are ok with that
<mvo> jdstrand: mup is quiet for some time
<mvo> jdstrand: I talked to gustavo he wants to tweak some code first iirc, its related to the spam attacks that happend on freenode a while ago and now unregistered users are muted by default and (iirc) that code needs tweaks
<jdstrand> mvo: ok, cool. I thought maybe I forgot the handshake
<mvo> jdstrand: hhaha
<niemeyer> Yeah, sorry about that
<niemeyer> The issue is mup doesn't have code to self-identify to nickserv
<niemeyer> If I do that manually it works
<niemeyer> But I need to automate it so it happens on reconnection
<niemeyer> mup: Right?
<mup> niemeyer: I apologize, but I'm pretty strict about only responding to known commands.
<mvo> niemeyer: thanks! no worries, a clear case of soo-much-to-do-so-little-time :/
<niemeyer> Yeah, it just sucks that it's taking that long to get to it
 * mvo hugs niemeyer 
 * mvo noticed there weren't many hugs since dholbach stopped joining this channel, a shame!
<mvo> btw tests are a bit on the red side still, any particular culprits? if not I will investigate in my morning
<jdstrand> niemeyer: hello :)
<niemeyer> jdstrand: o/
<pedronis> jdstrand: I tried to answer, but likely one of us is confused
<pedronis> jdstrand: it seems you have the order of things happening in snapstate vs snap/info.go wrong
<pedronis> snap/info.go stuff happens first
<pedronis> or I'm misreading you
<jdstrand> pedronis: for the first comment about key, I understand your point and will fix. for the other, yes, I understood the order to be the other way. I can adjust and move it
<pedronis> jdstrand: there you have a bit of a choice whether to do it always, or do it under Validate
<pedronis> it seems we tend to do that kind of checks in Validate
<pedronis> like for slot/plug names etc
<pedronis> but not so late as in check_snap.go
<jdstrand> I would lean towards that I think too
<jdstrand> thanks
<jdstrand> I think the comment somewhere made me think check_snap.go was sooner than later, but not a problem
<jdstrand> s/the comment/a comment/
<pedronis> we need to parse the yaml before acting on it
<pedronis> so one of the Read is always in the path
<jdstrand> sure. the parse check I thought was different from a value check, but again, not a problem to move
 * cachio afk
<pedronis> jdstrand: I clarified my comments in 7112, two things are probably follow up material, need more thinking to decide what to do, but one point still is relevant
<mup> PR snapcraft#2661 closed: deltas: code cleanup <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2661>
<zyga> degville: https://twitter.com/zygoon/status/1161720375962681344
<jdstrand> pedronis: ok, with PR 7111, I moved only IsValidUsername() to info_snap_yaml.go: https://github.com/snapcore/snapd/pull/7111/commits/0cc9ac7c514a48ac409a04d5b27393a96cec456e
<mup> PR #7111: many: support system-usernames for 'snap_daemon' user <â Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7111>
<jdstrand> pedronis: which is what you said in the PR and that is all fine. when discussing here, I thought you meant all of the supportedSystemUsernames checks, but you didn't mean that, correct? Ie, I think I'd like to keep the supportedSystemUsernames in overlord since eventually we'll get the map from the store, not hardcoded in snapd, so hardcoding it for now in where it is feels better than in
<jdstrand> info_snap_yaml.go
<jdstrand> pedronis: beyond that, I think I addressed all comments for 7111
<jdstrand> erf... unit tests failing with "Could not obtain seccomp compiler information: fork/exec /tmp/check-3892727285590088690/593/usr/lib/snapd/snap-seccomp: no such file or directory"
<mup> PR snapcraft#2663 opened: elf: handle invalid elf files <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2663>
<cmatsuoka> cachio: are you experiencing repeated fedora-30-64 test failures?
<cachio> cmatsuoka, mmm
<cachio> which errors?
<cmatsuoka> cachio: mostly in preparation, I just restarted my tests because they seemed random but if they happen again I'll get the full log
<cachio> cmatsuoka, do you have a log?
<cachio> I just finished a fix for interfaces-contacts-service
<cmatsuoka> cachio: I'll get it in the next run
<cachio> cmatsuoka, nice, thanks}
<jdstrand> oh, I found the issue I saw in the testsuite (my fault)
<cachio> cmatsuoka, I am leaving now, please, leave here the link, I'll take a look when I am back
<mup> PR snapd#7256 opened: tests: adding retry command and use it to delete $XDG directory <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7256>
<cmatsuoka> cachio: the ubuntu tests failed too, but the cause seems to be pretty random as well: Cannot allocate google:ubuntu-18.10-64: cannot allocate new Google server for ubuntu-18.10-64: the resource 'projects/ubuntu-os-cloud/global/images/family/ubuntu-1810' was not found
<cmatsuoka> I'll repeat it to see if it's deterministic
<cmatsuoka> cachio: ok, now the fedora systems are provisioned, but they're failing when looking for vendored dependencies during rpm package build
#snappy 2019-08-15
<sarnold> is this the right channel for someone who's having trouble getting skype to work?
<cjp256> sarnold: what is the problem you are having?
<sarnold> cjp256: another user in #ubuntu was having trouble getting skype to work via the snap; he had to run /snap/bin/skype explicitly, and once he did that he had problems with some authentication step within skype
<sarnold> cjp256: I asked if this was a good place for user help when he was having trouble figuring out how to even run skype, but another #ubuntu user aimed him towards /snap/bin/skype, which appeared to work
<sarnold> I wanted to make sure this was the right place to send him, before sending him here, since it'd exceeded my knowledge ;) but he got far enough to find out that he wasn't going to be able to use the skype snap in the end
<sarnold> is this the right place to send people who are having trouble with snap?
<cjp256> it depends, naturally :)  but I've been working with the skype snap a lot lately and figured I'd ask.  It can't hurt to ask the question and see where fate takes it... :D
<mup> PR snapd#7249 closed: packaging/fedora: build on RHEL8 <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7249>
<mup> PR snapd#7248 closed: interfaces/mount: discard mount ns on backend Remove <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7248>
<pedronis> mvo: hi, so jdstrand first two PRs are in better shape, but they are split a bit strangely so that the first will turn on the feature in a broken state, a full reorg of the PRs is probably too much at this point, my idea is to tweak the first to use a temporary global flag, to keep the feature off while we work through them one by one
<pedronis> mvo: sounds reasonable?
<mvo> pedronis: yes
<mvo> pedronis: thanks, once I finish some org stuff I will jump to the reviews for those
<pedronis> mvo: the first one has already 2 +1 I'm tweaking it as we speak though
<mvo> pedronis: first one is 7111 ?
<pedronis> yes
<pedronis> I'll ask you to check my tweaks once pushed
<mvo> ta
<jamesh> mvo: thanks for calling me up on that lock issue with the session agent PR.  Getting rid of the need not to use defer to release the lock ended up making the code simpler.
<mvo> jamesh: nice! thats great to hear. thanks for this. I will have another look in some minutes then :)
<pedronis> mmh
<pedronis> mvo: can you look at my own commits to 7111
<pedronis> that I just pushed
<mvo> pedronis: yes
<mup> PR snapd#7257 opened: packaging: fix symlink for snapd.session-agent.socket <Created by mvo5> <https://github.com/snapcore/snapd/pull/7257>
<mvo> welcome back mup !
 * mvo hugs niemeyer 
<pedronis> mvo: I'll look again at 6404 in a little bit
<mvo> pedronis: thanks! I noticed small issues with 7111 (not in your new code, that part looks fine). review should be ready soon
<mvo> pedronis: deriveContent is missing a test and also never changes firstRun
<Chipaca> hah, i was just about to ask about 6404
<Chipaca> i wish github had 'private' tags
<Chipaca> ie that i could tag things without everybody seeing them as tagged
<Chipaca> jamesh: what's the status of #5822 ?
<mup> PR #5822: wrappers: allow user mode systemd daemons <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5822>
<jamesh> Chipaca: blocked on being able to control user daemons over snap install/upgrade/removal
<Chipaca> hmmm
<jamesh> Chipaca: this is what the user session agent branches I've been working on are intended to solve
<Chipaca> zyga: what happened to refresh control? (is that what we were calling it)
<pedronis> Chipaca: what's the context for that question?
<pedronis> also z-yga is supposed to be off today
<Chipaca> pedronis: context of the question was that I thought we'd made progress on it, and that if we had that then refresh of things with user daemons would be a'ight ? dunno
<Chipaca> was trying to figure out if/how those two fit together really
<pedronis> Chipaca: that is not refresh control,  that's refresh awarere/prevent refreshes while running
<Chipaca> yeah that
<pedronis> heh, awareness
<pedronis> Chipaca: but, there was progress, but daemon have they own rules
<Chipaca> too late, it's awarere now
<pedronis> their
<pedronis> also we cannot really expect the user to be on top of daemons (vs gui apps)
<pedronis> so it's related but also orthogonal
<pedronis> to the issue of user session services
<Chipaca> to me they are separate issues
<Chipaca> one is preventing the refresh
<mvo> pedronis: I will do the tiny fix in interfaces/seccomp/backend in 7111 because the current running tests are failing (network again it seems) so it seems to be fine to push this small fix (removing firstRun)
<Chipaca> the other is notifying the user or the snap about the refresh
<pedronis> yes, we know that
<Chipaca> there is a rather strong demand from good snap authors for them to be in the pipeline of this
<Chipaca> that is
<Chipaca> the snap wants to be told there is a refresh there
<Chipaca> and for user-mode daemons, same thing could apply? again dunno, but, don't see why we can't start there
<Chipaca> anyhow
<Chipaca> moving on up the queue
<pedronis> Chipaca: that work is discussed, tracked here: https://forum.snapcraft.io/t/wip-refresh-app-awareness/10736/13
<pedronis> fwiw
<pedronis> though that needs an update from a couple discussions in toronto
<Chipaca> pro tip: don't start on the third page of PRs unless you're immune to getting into a funk
 * Chipaca is not immune and needs a break now
<pedronis> Chipaca: to be fair atm we should just concetrate on 2.41 marked ones
 * ogra plays some jazz to get Chipaca out of the funk
<mvo> pedronis: I pushed a tiny patch to 7111, double checking would be appreicated
<Aavar> I have (as you may have seen earlier) a problem with launching graphical snaps. I have zyga helping me, but we have not figured it out. If anyone else has something to add it would be appriciated:) https://paste.ubuntu.com/p/MjhDYjt8GR/
<Chipaca> Aavar: I did not see. What's the output of 'snap version'?
<pedronis> mvo: I'll look in a bit
<Aavar> Chipaca, https://paste.ubuntu.com/p/Xv3zqPQCcC/
<Chipaca> Aavar: what's special about your installation?
<Aavar> Chipaca, hmm... Nothing more than that I have messed with it for about a year... THe last thing I did yesterday was to try to reinstall all the apt-packages on my system.
<Aavar> brb, lunch.
<Chipaca> Aavar: are you running X?
<pedronis> mvo: I was reviewing #7254
<mup> PR #7254: cmd/snap-update-ns: fix pair of bugs affecting refresh of snap with layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/7254>
<pedronis> mvo: you have a change to templage.go that looks wrong
 * Chipaca takes a break
<Chipaca> hmm, it looks like core 18 is broken?
<Chipaca> lots of core18 spread tests failing
<Aavar> Chipaca, I am running X yes.
<mvo> pedronis: yeah, fixed. silly me
<Chipaca> Aavar: can you snap install xbill-xaw?
<Aavar> Chipaca, yes, and then run it?
<Chipaca> Aavar: yes please, run just 'xbill-xaw'
<Aavar> Chipaca, "Error: Can't open display: :0"
<Aavar> Chipaca, only that.
<diddledan> that's an odd one if you're not in Wayland
<Chipaca> Aavar: can you 'snap run -strace xbill-xaw' please
<diddledan> --strace, no?
<Chipaca> yes
<Chipaca> probably
<diddledan> double that dash!
<Aavar> Chipaca, Got a bunch of errors. Let me paste that.
<Aavar> Chipaca, diddledan: https://paste.ubuntu.com/p/zHvtXYcmms/
<diddledan> looks like the socket was EACCESS
<diddledan> i.e. permission denied for some reason
<Chipaca> Aavar: dmesg | grep DENIED ?
<ogra> what kind of desktop env and display manager is running there ?
<diddledan> random Windows folder name oddity for your bemusement :-) https://usercontent.irccloud-cdn.com/file/8lZTm56c/image.png
<Aavar> Chipaca, https://paste.ubuntu.com/p/XpDd8tTJKW/
<Chipaca> Aavar: I'm now suspicious of your apparmor
<Aavar> Chipaca, are there some way to completely shut down apparmor for testing?
<Chipaca> Aavar: when you tried to reinstall all the apt-packages, did you reinstall apparmor?
<Chipaca> (it's an apt package with that name)
<Aavar> Chipaca, I am not sure, but I guess so. I ran this script that is supposed to reinstall all packages. https://ubuntuforums.org/showthread.php?t=735693
<diddledan> and what commands did you use to reinstall all the apt packages - might be you got your system in a wonky state by doing that
<Chipaca> 2008
<Chipaca> yeah
<Aavar> (I know it's a bad idea run scripts from the internett, but I figured it was worth a try as I am stuck anyway...)
<Chipaca> Aavar: didn't the "this has been tested on 7.10" alert you to anything?
<pedronis> mvo: frequent red, landing things will be hard
<Chipaca> diddledan: for pkg in `dpkg --get-selections | awk '{print $1}' | egrep -v '(dpkg|apt|mysql|mythtv)'` ; do apt-get -y --force-yes install --reinstall $pkg ; done
<ogra> i wonder what that is supposed to ahieve
<ogra> *achieve
<Chipaca> ogra: from the forum post above
<Aavar> Chipaca, I did read that, and figured that I would reinstall if it broke my system. To be fair, the script seemed to run fine and I am in the same spot now that I was before.
<mvo> pedronis: yeah, the next red I will go berzerk and just disable tests
<ogra> yes
<ogra> i saw that
<Chipaca> Aavar: do you have any data in ~/snap that you care about
<Aavar> Chipaca, nope.
<ogra> still wondering ... it will only replace existing binaries and leave the configs alone
<Chipaca> mvo: core 18 seems broken tho
<Chipaca> Aavar: sudo apt purge snapd
<Chipaca> Aavar: and then sudo apt install snapd
<Aavar> Chipaca, btw, I did try to add a new user and it gave me the same result.
<Chipaca> Aavar: and then reboot
<Aavar> Chipaca, will do. brb
<ogra> unlikely to change anything over what has been there ... unless someone actively rm'ed something from the rootfs
<mvo> Chipaca: oh no? what exactly
<diddledan> mvo: "everything" :-p
<diddledan> I troll
 * mvo hugs diddledan 
<ogra> !
<diddledan> \o/ huggies!
<Chipaca> mvo: https://api.travis-ci.org/v3/job/571891969/log.txt
<Chipaca> mvo: i'm trying to figure out what exactly
<Chipaca> mvo: bunch of apparently different errors, everything failed to prepare/restore and nothing succeeded afaict
<mvo> Chipaca: :( I wonder if an core18 upload borke it
<Chipaca> waiting for a debug run of spread to get me a shell now
<Chipaca> so i can get more info
<Chipaca> but, thought i'd mention it :)
<Chipaca> diddledan: wrt that screenshot, if I saw that folder I'd assume it was malware and nuke the installation
<diddledan> it looks like the issue in that spread log might be related to coming back online after the reboot?
<diddledan> specifically there's several of these: `error: cannot communicate with server: Get http://localhost/v2/connections?select=all: read unix @->/run/snapd.socket: read: connection reset by peer`
<diddledan> maybe not after reboot - but after reboot or restart of core after the refresh
<Aavar> Chipaca, After reinstall I get this error: https://paste.ubuntu.com/p/S69zyQg8yM/ Do I need to start the daemon?
<diddledan> you will need to reinstall the snaps
<Chipaca> Aavar: what's 'snap version' now?
<diddledan> oh I see you were
<diddledan> the daemon should automatically start IIRC
<Chipaca> Aavar: maybe snapd was just taking a bit of time starting? what's the output of systemctl status snapd?
<diddledan> it's prolly refreshing itself?
<Chipaca> either that, or we should send thoughts & prayers
<Chipaca> mvo: no debug shell :-(
<Chipaca> mvo: EOF of death
<Aavar> Chipaca, diddledan: https://paste.ubuntu.com/p/pzcjRqFVZm/ looks like the service is not running properly.
<Chipaca> Aavar: yeah gonna need that status thing
 * Chipaca prepares a wreath
<Aavar> Chipaca, sorry. https://paste.ubuntu.com/p/ZT8dQ35G7Y/
<Chipaca> Aavar: you've apparently changed things so services aren't started automatically on install?
<Chipaca> Aavar: try sudo systemctl enable --now snapd.\*
<Aavar> Chipaca, not on purpose...
<Chipaca> i don't remember if * worked for 'enable'
<Chipaca> Aavar: I purposely did not say you did it intentionally
<Chipaca> :)
<Aavar> Chipaca, * didn't work but I'll run it for all the services.
<Chipaca> Aavar: k. some won't like being enabled but that's probably ok
<Chipaca> (some of them are only for weird systems)
<Chipaca> snap.service and snapd.socket should both be enabled
<Chipaca> snapd.service*
 * Chipaca struggling to type
<Aavar> Chipaca, ok, Now i'm installing xbill-xaw again.
<Aavar> Chipaca, or should I do something else?
<Chipaca> Aavar: hold on
<Chipaca> Aavar: what's the status of apparmor.service ?
<Aavar> Chipaca, Enabled and running it seems. https://paste.ubuntu.com/p/STBbmj24zN/
<Chipaca> Aavar: ok, try xbill again please
<Aavar> Chipaca, same :(
<Chipaca> Aavar: if you want to figure out why, maybe jdstrand can shed some light on it (later in the day, it's early for him to be around)
<Chipaca> Aavar: but at this point I'd say your system is fubar
<Chipaca> mvo: do you know why core18 still does not include bash completion? i filed the bug ages ago :-(
<Aavar> Chipaca, Ok, I will try jdstrand. But I think you are right the system is destroyed. I mostly tried to fix this to learn, but a reinstall is possible too :)
<Aavar> Chipaca, thank you for your help :)
<mup> Bug #1840244 opened: docker snap cannot bind mount ssh sockets correctly <Snappy:New> <https://launchpad.net/bugs/1840244>
<Chipaca> mvo: I can't reproduce the weird issues in actual core18, fwiw
<popey_> Can someone on the snappy team please update https://launchpad.net/snappy
<popey_> (the home page link is broken)
<popey_> the first link points to https://launchpad.net/snapd which tells you to go to https://github.com/snapcore/snapd
<ijohnson> morning folks
<ijohnson> Chipaca: when you get time could you give another pass at my `snap model` PR (#7149) ?
<Chipaca> ijohnson: yep
<mup> PR #7149: cmd: add snap model command; daemon: add /v2/model, /v2/model/serial REST APIs <Remodel :train:> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7149>
<ijohnson> thanks
<popey_> niemeyer: ^ I don't have access to modify those pages, would be good to make them less messy
<Chipaca> I think I can change those
<Chipaca> popey_: better?
<diddledan> it's still a click followed by another click to get to the snapd github - seems silly to say "go here for snapd" and then on that page it says "go HERE for snapd"
<Chipaca> diddledan: only code is on github
<Chipaca> diddledan: bugs are on launchpad
<Chipaca> for snapd
<popey_> <3 Chipaca thanks
<Chipaca> ijohnson: what's the status of #6697 btw?
<mup> PR #6697: interfaces/daemon_notify: add {net,sys}_admin capabilities, update spread test <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6697>
<Chipaca> popey_: that was a quick drive-by but maybe degville can look into making it better at some point :)
 * diddledan earworms you all: https://www.youtube.com/watch?v=O5HQ1sZseKg&t=93
 * Chipaca steps away quickly
<diddledan> I've been earwormed by that too hard
<ijohnson> Chipaca: it would be good to get zyga's response, but really I'm waiting for jdstrand to comment as apparently there are some problems with my PR that hitherto have been too numerous to comment about
<cachio> mvo, hey, about the go-build test, do you know if any change done lastly could affect it to take more time?
<pedronis> mvo: re-reviewed #6403, needs a little bit more work I think
<pedronis> sorry #6404
<mup> PR #6403: many: cleanup golang.org/x/net/context <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6403>
<mup> PR #6404: snapstate: auto transition on experimental.snapd-snap=true <Created by mvo5> <https://github.com/snapcore/snapd/pull/6404>
<pedronis> cachio: we are timing out very often now? do we need more workers?
<pedronis> or something else
<cachio> pedronis, the time outs are realted to the gobuild test
<cachio> at least the last timeouts
<cachio> pedronis, I am debugging the test to see the time it takes
<cachio> pedronis, based on the logs the problem is related to 18.04, I think it should have the same number of workers than 16.04
<cachio> pedronis, https://paste.ubuntu.com/p/V7BqpSvVz4/
<pedronis> btw it needs tweaking because now we have a couple of libraries in there
<mvo> cachio: I think the archive is slower currently for whatever reason so fetching the debs for the building takes a long time
<mvo> pedronis: thanks, thats fine, I move it to 2.42 then
<cachio> mvo, pedronis based on logs the last system finishing always is ubuntu 18.04
<mup> PR snapd#7258 opened: tests: adding more spread workers for ubuntu-18.04-64 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7258>
<mvo> cachio: I wonder if we can try to use a in-cloud apt mirror (if there is such a thing)
<cachio> mvo, pedronis #7258
<mup> PR #7258: tests: adding more spread workers for ubuntu-18.04-64 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7258>
<mvo> cachio: aha, ok. I probably need to look again then
<mvo> cachio: more works is definitely a good idea
<cachio> cachio, it is necesary based on the number of tests we are running on that system
<pedronis> cachio: don't think it affects time but  we should replace -name \*.go  with -name main.go in that test
<pedronis> it's building lib packages atm
<pedronis> for no good reason
<cachio> pedronis, ah, ok
<cachio> let me make that change
<cachio> and measure the test time
<pedronis> we should make the change either way
<pedronis> it's the conceptual correct thing
<pedronis> we are just trying to build our commands
<pedronis> which are the entrypoints to everything else
<cachio> pedronis, makes sense
<cachio> pedronis, thanks
<pedronis> mvo: #7131 and #7133 need your reviews, the rest is a bit blocked on the red at this point
<mup> PR #7131: overlord/devicestate: detect clashing concurrent (ongoing, just finished) remodels or changes <Remodel :train:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7131>
<mup> PR #7133: overlord,daemon: adjust startup timeout via EXTEND_TIMEOUT_USEC using an estimate <Created by pedronis> <https://github.com/snapcore/snapd/pull/7133>
<mup> PR snapd#7209 closed: firstboot: queue service commands before mark-seeded <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7209>
<pedronis> mvo: do we need #7257 for 2.41 ?
<mup> PR #7257: packaging: fix symlink for snapd.session-agent.socket <Created by mvo5> <https://github.com/snapcore/snapd/pull/7257>
<mup> PR snapd#7111 closed: many: support system-usernames for 'snap_daemon' user <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7111>
<pedronis> mvo: ^ landed, I have now merged master into and tweaked #7112
<mup> PR #7112: many: allow 'system-usernames' with libseccomp > 2.4 and golang-seccomp > 0.9.0 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7112>
<mup> PR snapd#7259 opened: tests: just build snapd commands on go-build test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7259>
<mvo> pedronis: we need 7257 yes
<pedronis> mvo: ok
<mvo> pedronis: thanks, looking at 7112 now
<pedronis> jdstrand: hi, we landed 7111 after some more work,  I reworked a bit 7112 further now
<pedronis> jdstrand: one issue to keep in mind for the future was error message style
<pedronis> mvo: I marked it for 2.41 (7257)
<mvo> pedronis: thanks
<pedronis> jdstrand: btw, we need a review for #7254
<mup> PR #7254: cmd/snap-update-ns: fix pair of bugs affecting refresh of snap with layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/7254>
<pedronis> it's a bug fix that could go in 2.41
<jdstrand> pedronis: ack, I'm fixing up PR 7124 for the recent merge and fixups and will move to that after looking at ijohnson's questions
<mup> PR #7124: many: create system-usernames user/group if both don't exist <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7124>
<mup> PR snapcraft#2663 closed: elf: handle invalid elf files <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2663>
<mup> PR snapd#7258 closed: tests: adding more spread workers for ubuntu-18.04-64 <Simple ð> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7258>
<pedronis> mvo: I marked the gadget update ones for 2.41, but let you do the honor of merging it
<mvo> pedronis: thank you!
<mup> PR snapcraft#2664 opened: cli/clean: handle exception when cleaning a part with a fresh project <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2664>
<mup> PR snapd#7253 closed: interfaces: remove BeforePrepareSlot from commonInterface <Simple ð> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7253>
<ijohnson> thanks jdstrand
<mup> PR snapd#7174 closed: overlord/configstate/configcore: allow setting start_x=1 to enable CSI camera on RPi <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7174>
<ijohnson> jdstrand: I re-added that attr for docker-support test so I think that's good to merge
<ijohnson> mvo, pedronis, if tests are green can I merge #7010 too? or would you rather wait til after 2.41 is cut and put that for 2.42
<mup> PR #7010: interfaces/docker-support: add controls-device-cgroup <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7010>
<mvo> ijohnson: yes, it has 2 +1
<mvo> ijohnson: I can do a final check if you want
<ijohnson> mvo: no need, I'm sure you have more important things to look at right now :-)
<ijohnson> (unless you want to of course)
<pedronis> ijohnson: seems the summary and the description will need updating though? it was using an attribute and doesn't anymore?
<jdstrand> ijohnson: oh, daemon notify is not on my plate for today (not 2.41), but will look at netplan apply and docker-support
<jdstrand> I netplan apply isn't 2.41 either, but still
<pedronis> jdstrand: the spread tests in 7124 will need tweaks because of the changes to the error messages
<pedronis> in the previous PRs
<jdstrand> pedronis: ack
<mvo> what was the in-cloud GCE mirror for apt again? I think someone mentioned it but I misplaced the reference :/
<Chipaca> mvo: it depends where in gce you are
<Chipaca> e.g. europe-west1.gce.archive.ubuntu.com or us-central1.gce.archive.ubuntu.com
<Chipaca> etc
<jdstrand> ijohnson: fyi, I responded to your feedback in PR 7214
<mup> PR #7214: interfaces/network-setup-control: allow dbus netplan apply messages <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7214>
<Chipaca> mvo: maybe gce.clouds.archive.ubuntu.com figures it out? (dunno)
<ijohnson> jdstrand that's fine no need to review the daemon notify anytime soon
<mvo> Chipaca: thanks, that sounds right
<ijohnson> thanks for the docker-support and the netplan apply comment
<ijohnson> mvo, it looks like we will need to get one more change to upstream netplan apply D-Bus service file
<cyphermox> oh?
<mvo> ijtthe AssumeAppArmorLabel=unconfined ?
<mvo> ijohnson: -^
<ijohnson> oh hey cyphermox didn't realize you were here too
<ijohnson> mvo yes
<mvo> ijohnson: yeah, I think this is why I'm a bit annoyed, IMNSHO this should be the default
<cyphermox> ijohnson: asap please, I'm trying to cut a release atm
<jdstrand> mvo: you are not the only one
<ijohnson> okay, filing PR right now, it's just a single line change
 * jdstrand shakes fist at dbus upstream
<jdstrand> cyphermox: fyi, https://github.com/snapcore/snapd/pull/7214#discussion_r314333683
<mup> PR #7214: interfaces/network-setup-control: allow dbus netplan apply messages <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7214>
<pedronis> jdstrand: I did a first pass at 7124 (haven't looked at the spread tests tough)
<pedronis> *though
<mvo> jdstrand: heh :) can you point me to a bugreport/PR? at least then I can voice my opinion
<jdstrand> pedronis: I'm adjusting spread now
<ijohnson> alright verified the fix, cyphermox PR is here: https://github.com/CanonicalLtd/netplan/pull/101
<mup> PR CanonicalLtd/netplan#101: io.netplan.Netplan.service.in: add assumed apparmor label <Created by anonymouse64> <https://github.com/CanonicalLtd/netplan/pull/101>
<cyphermox> cool
<ijohnson> cyphermox: oh sorry my local master was out-of-date do you want me to rebase?
<pedronis> jdstrand: let me know if you have questions on my comments
<cyphermox> ijohnson: no it's all good
<ijohnson> cyphermox ack thanks, sorry for the last minute rush
<pedronis> mvo: you added --extra-users support to userdel ?
<pedronis> what't the status of that
<ijohnson> pedronis: I updated the PR title/description on #7010, lmk if you think it needs to be adjusted more
<mup> PR #7010: interfaces/docker-support: set controls-device-cgroup spec <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7010>
<mvo> pedronis: I did
<pedronis> mvo: ubuntu only though?
<mvo> pedronis: its available in both bionic and xenial:https://launchpad.net/ubuntu/+source/shadow/1:4.5-1ubuntu2  andhttps://launchpad.net/ubuntu/+source/shadow/1:4.2-3.1ubuntu5.4
<mvo> pedronis: yes, its only useful on core anyway
<pedronis> ah, yes
<pedronis> jdstrand: ^
<mvo> pedronis: 7112 LGTM - do you wanto to do the second review or do we need to find someone else?
<mvo> (its also green which is a big plus :)
<pedronis> I think  if Chipaca gave it a look it would be better
<pedronis> given that I tweaked it quite a bit
<Chipaca> i can do that
<Chipaca> mvo: so
<Chipaca> mvo: us-east1.gce.archive.ubuntu.com
<Chipaca> mvo: has a ping of .5ms
<Chipaca> mvo: from our spread machines
<Chipaca> mvo: that's probably the one we want
<pedronis> ijohnson: looks alright, 7010 description. I changed the summary a bit again
<mup> PR snapd#7087 closed: overlord/devicestate, tests: use gadget.Update() proper, spread test <Gadget update> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7087>
<Chipaca> mvo: gce.cloud.a.u.c is ~24ms away so whatever it is, it isn't the one we want
<Chipaca> mvo: (that's worse than a.u.c itself)
<jdstrand> pedronis: https://github.com/snapcore/snapd/pull/7124#discussion_r314360718
<mup> PR #7124: many: create system-usernames user/group if both don't exist <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7124>
<mvo> Chipaca: nice!
<mvo> Chipaca: thanks for figuring this out
<mvo> Chipaca: I think this will help a lot if we can update our tests to use the gce mirror when inside gce
<ijohnson> pedronis: looks good thanks
<jdstrand> pedronis: ack that userdel now supports --extrausers (it didn't when I wrote the initial PR 6681 :)
<pedronis> jdstrand: thx, that would be ideal
<mup> PR #6681: many: support system-users for 'daemon' user <Complex> <â Blocked> <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/6681>
<pedronis> also much cleaner
<Chipaca> mvo: also, cloud-id -l | cut -f2 â us-east1
<pedronis> jdstrand: also note my comment about user.Lookup* returning Unknown* vs other errors
<jdstrand> mvo: does groupdel suppoer --extrausers?
<jdstrand> support*
<jdstrand> $ groupdel --extrausers foo
<jdstrand> groupdel: unrecognized option '--extrausers'
<jdstrand> I need groupdel since we necessarily must use groupadd then useradd since useradd with --user-group chooses something from the range in login.defs
<jdstrand> pedronis, mvo: ^
<jdstrand> but that could be in a followup PR. I can clean up on classic and add a comment for core
<diddledan> I still haven't worked out which I should use to add and remove users - adduser or useradd
<diddledan> they're not the same...
<jdstrand> diddledan: on a Debian-derived system, adduser
<jdstrand> it has a nicer interface
<pedronis> jdstrand: yes, can leave a TODO, much easier either way if this is encapsulated, vs in snapstate
<jdstrand> but isn't portable
<jdstrand> pedronis: I understand
<jdstrand> diddledan: if you just want it to always work everywhere all the time, useradd, but you have to be careful with it
<mvo> jdstrand: uh, oh. ok - it seems like there is some work to do there then :/
<mvo> jdstrand: (groupdel --extrausers)
 * jdstrand nods
<mvo> jdstrand: this is a blocker, yes?
<diddledan> gotcha
<jdstrand> mvo: no
<jdstrand> mvo: I can cleanup on classic, add a todo for core to cleanup when groupdel --extrausers is available
<jdstrand> (see Samuele's comment above ^)
<Chipaca> mvo, pedronis, #7112 GTG FWIW
<mup> PR #7112: many: allow 'system-usernames' with libseccomp > 2.4 and golang-seccomp > 0.9.0 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7112>
<mvo> Chipaca: please merge
<Chipaca> too late, pedronis did already :)
<pedronis> jdstrand: ^
<mup> PR snapd#7112 closed: many: allow 'system-usernames' with libseccomp > 2.4 and golang-seccomp > 0.9.0 <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7112>
<jdstrand> \o/
<ijohnson> yay
<mup> PR snapcraft#2665 opened: Plugin catkin: disable parallel option <Created by artivis> <https://github.com/snapcore/snapcraft/pull/2665>
 * cachio lunch
<juliank> Is there a way for me to workaround apparmor denials?
<juliank> I'm trying to build a blog post, but the hugo snap confinement is borken
<ogra> juliank, what kind of denials ...
<juliank> ogra: simply /etc/gitconfig https://github.com/gohugoio/hugo/issues/6226
<juliank> I switched it to devmode to be able to proceed, but that's suboptimal :D
<ogra> juliank, there is a system-files interface that allows read access to such locations, but you need to file a request on the forum for it
<ogra> (if you cant just ship git inside your snap and point the app to the in-snap config which would be the usual way to do this without interfaces)
<juliank> I don't think it really needs the gitconfig
<juliank> it's like doing git describe HEAD or something
<juliank> But I was looking for a more confined local workaround than devmode-ing it
<ogra> well, you could hack around it by shipping a git binary that simply links to $SNAP/bin/true or some such ...
<ogra> if /etc/gitconfig is unavoidable the system-files interfact is the way to go though
<ogra> https://forum.snapcraft.io/t/the-system-files-interface/9358
<juliank> I was just hoping to hack in /etc/gitconfig into the local apparmor profile I have running while upstream figures out what to do :)
<ogra> oh, you could probably also use a layout
<ogra> https://forum.snapcraft.io/t/snap-layouts/7207
<ogra> i dont think hacking apparmor profiles is an option out of using an interface
<juliank> That's all useful for the people doing the snap
<ogra> (you can surely do that locally for yourself but would denied store uploads with that)
<juliank> But I'm just using it and want to workaround it :)
<ogra> ah, then hacking the profile is indeed an option ... i'll hand you over to jdstrand for that one ;)
<ogra> the profile shuld be in /var/lib/snapd/apparmor/profiles/
<ogra> but i dont know the runes for re-geneating it properly from the top of my head
<juliank> ah I can hack that in and then apparmor_parser -r it
<juliank> not a permanent solution, but ok
<ogra> yeah, as i said, layouts or system-files or shipping your own gitconfig in the snap and pointing the app to it are the ways
<ogra> (i'm actually curious what /etc/gitconfig would be ... i have never seen it on an ubuntu system)
<ogra> juliank, btw, you can tell the guys to simply set GIT_CONFIG_NOSYSTEM=true in their app launcher in snapcraft.yaml ;)
<ogra> that will avoid looking for a (likely non-existent) systemwide git configuration
<mup> PR snapd#7255 closed: store: use track/risk for "channel" name when parsing store details <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7255>
<juliank> ogra: good idea
<mup> PR snapd#7251 closed: packaging: fix removal of old apparmor profile <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7251>
<juliank> ogra: I just did
<jdstrand> juliank: if you want to modify a profile locally, you can edit the profile for the command in /var/lib/snapd/apparmor/profiles/snap.... then do: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap....
<jdstrand> juliank: not that snapd while undo your change at various times (after reboot, refresh, etc)
<juliank> jdstrand: yes thanks, just the path to the profile was enough already :)
<jdstrand> note*
<juliank> also *will
<juliank> but yes
<jdstrand> heh, yes, will* :)
<juliank> But as ogra pointed out GIT_CONFIG_NOSYSTEM=true, just setting that when launching hugo works just fine too :)
<mup> PR snapd#7260 opened: tests: add a runtime scripts generation to generate scripts to call functions <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7260>
<mup> PR snapcraft#2666 opened: tests: move meta testing to its own package <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2666>
<mup> PR snapcraft#2667 opened: yaml utils: move OctInt from meta <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2667>
 * ijohnson reboots
<mup> PR snapd#7261 opened: [WIP] interfaces/serial-port: support pci bus serial-port with Hotpluâ¦ <Hotplug ð> <Precious Logs> <â Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7261>
<mup> PR snapd#7262 opened: tests: use a different archive based on the spread backend on go-build test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7262>
<mup> PR snapcraft#2668 opened: Restore cmake artifacts <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2668>
<lifeless> morningish :)
<lifeless> so I filed https://bugs.launchpad.net/snappy/+bug/1840244 last night, and I'd like to know how to fix it locally
<mup> Bug #1840244: docker snap cannot bind mount ssh sockets correctly <Snappy:New> <https://launchpad.net/bugs/1840244>
<lifeless> where fix means 'run those components with the global /tmp rather than their own namespace' - as doing a deep integration seems like a snappy long term project goal, and this ia a regression to be fixed vs upstreams regular delivered packaging as a deb or whatever
<lifeless> mwhudson: ^
<mwhudson> lifeless: pretty sure all snap things run with private /tmp, not there's a quick fix for that
<lifeless> ah; theres some reference to a docker-privilege command, but it doesn't seem to exist, and there's no link to the packaging source anywhere that I can see
<lifeless> (on https://snapcraft.io/docker )
<lifeless> I guess I'll have to bind mount /tmp to /tmp2 or some such
<lifeless> how do you disable automatic snapshots on uininstall
<lifeless> I don't want an archive of GBs of docker images
<mwhudson> there were some forum posts about that sort of thing, i don't remember the details though
<lifeless> found it https://snapcraft.io/docs/snapshots
<lifeless> To disable automatic snapshots, set the retention time to no:
<lifeless> $ snap set system snapshots.automatic.retention=no
<mwhudson> i don't think mounting /tmp at /tmp2 will help, will it? needs to be something that gets propagated into the docker snap's mount namespace (and i don't know what that is off the top of my head)
<lifeless> I can make /tmp for everyone else be /tmp2 bind mounted to /tmp if I have to
<lifeless> but my current plan is to just stop using snappy
#snappy 2019-08-16
<mup> PR snapd#7010 closed: interfaces/docker-support: declare controls-device-cgroup <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7010>
<mup> PR snapd#7131 closed: overlord/devicestate: detect clashing concurrent (ongoing, just finished) remodels or changes <Remodel :train:> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7131>
<mvo> pedronis: hey, good morning! I'm about uneasy about the missing return code checks (the exec.ExitError), I will look into this and push something unless you are already on it or thing its not needed
<pedronis> mvo: it's needed I think but also there are open questions there
<pedronis> so we can push a couple of things to it
<pedronis> but we'll need jamie around before landing
<pedronis> mvo: anyway, I'm not working on that PR atm
<pedronis> I'm trying to address jamie comments in zygmunt's one
<mvo> pedronis: ok, according to gettenv exit 2 means "not found in db" so I will make a very targeted change just for this
<mvo> pedronis: cool, thanks! zyga is probably around today (right zyga?)
 * mvo actually looks in the right place to be sure
<mvo> pedronis: I was also wondering if we should have "osutil.FindUid(name, flags)" and flags something like "LocalOnly,Getenv" (better names) instead of two functions, wdyt?
<pedronis> mvo: does it ever make sense not to do both?
<pedronis> anyway as I wrote in the PR, I'm a bit confused because snap-seccomp itself uses those functions
<pedronis> but was not changed
<pedronis> so not sure how things work at all atm
<pedronis> :)
<mvo> pedronis: aha, ok. I'm not that far yet I think :) I will not touch these then
<mvo> pedronis: I pushed two trivial changes and will now add a test for malformated entries in getent()
<mvo> pedronis: and then continue, I'm at below 10% of the PR so far :(
<mvo> pedronis: but I think regardless of what happens we will need the tweaks I added/will add :)
<pedronis> mvo: I pushed something to 7254, in the end I decided that having both CurrentBase and CurrentCleanBase was just confusing
<mvo> pedronis: thanks, I have a look
<pedronis> Chipaca: hi, given you looked 7124, I think we shouldn't have separate FindU/Gid and FindU/GidGetent ?
<Chipaca> pedronis: but we don't
<Chipaca> pedronis: that pr drops FindUid (makes it private)
<pedronis> did mvo change that just now
<Chipaca> oh wait
<Chipaca> pedronis: it exports them via a var
<Chipaca> :-|
<Chipaca> hmm
<pedronis> that is weird btw
<pedronis> not nice docs for you
<pedronis> anyway I don't think we should have both
<pedronis> unless you think we should
<pedronis> you are time that spent most thinking in that area
<mvo> pedronis: I don't think I did, let me double check
<pedronis> s/time/the one/
<Chipaca> mvo: no, no, i just missed the exporting var
<mvo> Chipaca, pedronis I posted my initial set of comments if you guys are looking anyway you can check and tell me what makes sense and what does not
<Chipaca> pedronis: not reaching out over the network to look up a user that is either local or non-existent has value i think
<pedronis> Chipaca: but we were missing extrausers with the previous code anyway
<pedronis> so essentially unless we are looking up root
<pedronis> we have to try
<pedronis> also we are looking at passwd, not netgroup
<mvo> Chipaca: when you did the review, did you double checked my commits? just curious as I would love to have someone double checking those
<Chipaca> mvo: I think I did, let me double check I didn't miss anything
<mvo> Chipaca: ta!
<pedronis> ah, snap-seccomp works because anyway is built with cgo
<pedronis> blargh
<pedronis> I don't really like how confusing the state is with the functions as thy are
<pedronis> Chipaca: do I understand correctly that if built with cgo we get the right behavior even from user.Lookup* but if not built with cgo we don't get extrausers support?
<pedronis> out of the box
<pedronis> but snapd itself is built without cgo usually
<Chipaca> pedronis: well, no-ish
<Chipaca> pedronis: snapd is not built without cgo
<Chipaca> pedronis: godbus and seccomp both require it afaik
<mvo> Chipaca: but those are not imported into the snapd binary or am I misremembering?
<jamesh> snapd definitely links with godbus
<jamesh> that's how it does polkit checks
<Chipaca> as jamesh says
<mvo> aha, of course
<mvo> silly me
<pedronis> Chipaca: so we don't need getent stuff?
<mvo> Chipaca:more silly questions - godbus/dbus is a native dbus, so why is it using cgo?
<Chipaca> actually maybe it isn't, in linux
<pedronis> anyway until I'm deconfused that PR cannot land
<Chipaca> just noticed that the ones that import C in there are freebsd and dragonfly
<Chipaca> pedronis: thank you for stepping back like this, I got carried away with it :)
<jamesh> hmm.  It looks like godbus will build without os/user for static_build
<pedronis> Chipaca: I was suprised you gave it a +1 without any comments btw
<jamesh> so it won't necessarily force cgo
<Chipaca> pedronis: i didn't think it was nitpicking time and i didn't spot anything major
<pedronis> but FindGid FindGidGetent is not a sane state of things
<jamesh> see vendor/github.com/godbus/dbus/homedir_dynamic.go and homedir_static.go
<pedronis> also we have the issue that we have functions that behave very differently
<pedronis> depending how they are compiled
<pedronis> me don't like
<Chipaca> I can confirm we don't require CGO for snapd today
<jamesh> godbus wants to know the home directory for the DBUS_COOKIE_SHA1 auth scheme noone uses
<Chipaca> (we've even got a test that checks for this)
<Chipaca> also, snapctl and snap-exec both are forced cgo-less
<pedronis> Chipaca: mvo: how painful would be to write unit tests that involve extrausers for reals?
<Chipaca> pedronis: _unit_ tests?
<pedronis> yes, unit tests (ideally)
<Chipaca> pedronis: 'for reals' as in via nss?
<Chipaca> not doable
<Chipaca> unless we added a known user to all our extrausers
<Chipaca> including in spread
<Chipaca> pedronis: should be doable in spread though
<pedronis> Chipaca: we could have tests that are skipped if libnss-extrausers is not there?
<pedronis> and install it in some cases also in spread
<Chipaca> pedronis: what would the unit tests test?
<jamesh> you could unshare the mount namespace, and put a socket at /var/run/nscd/socket
<jamesh> have that feed user info into libc
<pedronis> Chipaca: had a chat with mvo, we have  a plan I think
<Chipaca> pedronis: â¦ tell me more :)
<mvo> pedronis: I hope to have a PR up in ~30min or so, it will be only about osutil.Find{Uid,Gid} and then we can merge it back into 7124
<mvo> Chipaca: -^
<mvo> Chipaca: the idea is to have only a single FindUid() that detect if cgo or not
<mup> PR snapd#7263 opened: snap: cleanup some tests, clarify some errors <Created by pedronis> <https://github.com/snapcore/snapd/pull/7263>
<pedronis> small follow up to what was already laded for system usernames ^
<mvo> pedronis, Chipaca https://github.com/snapcore/snapd/compare/master...mvo5:find-uid-getent?expand=1 here is the refactor for osutil.Find{Uid,Gid} we talked about, I'm adding more tests now (spread and some more unit tests). let me know if thats not what we captured
<pedronis> mvo: seems in the right direction and what we discussed
<mvo> pedronis: cool, I hope I have more tests and spread ready in a bit
<cachio> Chipaca, hey
<cachio> Chipaca, about the error: catalog: got unexpected HTTP status code 429
<Chipaca> cachio: yes
<cachio> do you know how to make the catalog refresh just while we prepare the suite right?
<Chipaca> cachio: say again?
<cachio> Chipaca, does  it work if we saved the catalog in the snapd state
<mup> PR snapd#7264 opened: packaging/fedora: build on RHEL8 (2.40) <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7264>
<cachio> and then we restore it?
<Chipaca> cachio: it should, yes; then just touch the files
<Chipaca> cachio: restore, and touch the files
<Chipaca> so the timestamp is fresh
<cachio> Chipaca, which files?
<Chipaca> cachio: /var/cache/snapd/*
<Chipaca> cachio: there's a "sections" file and a "names" file, as well as a commands.db
<Chipaca> cachio: just touching sections would be enough, but * makes it more future-proof :)
<Chipaca> cachio: OTOH, if you explicitly touch sections, then even if it's not in the saved state it might still work (i'd have to check)
<cachio> Chipaca, ok, I'll implement that
<cachio> Chipaca, I'll ping you in case it doesn't work :)
<cachio> thanks!!
<Chipaca> cachio: there is a spread test for the catalog thing though
<Chipaca> cachio: which will fail if the catalog refresh doesn't actually work
<cachio> Chipaca, perfect
 * mvo has finished the spread test for findUid and will continue after lunch
<mup> PR snapd#7265 opened: osutil: add osutil.Find{Uid,Gid} <Created by mvo5> <https://github.com/snapcore/snapd/pull/7265>
<jdstrand> pedronis, mvo: hey, I'm here and ready to work on the 3rd snap_daemon PR. perhaps we could have a quick chat (5 minutes)?
<jdstrand> pedronis, mvo: I could also attend your standup if the timing works better
<mvo> jdstrand: I'm at lunch, I pushed 7265 with some small tweaks to the osutil.Find{Uid,Gid}. to chat standup or 10min before the standup (or right after) would work best
<jdstrand> mvo: that is one of the things I wanted to discuss (whether we need the fallback at all)
<jdstrand> mvo: I'll plan on 10 minutes before. care to invite me?
<jdstrand> mvo: reading 7265, I like it and is inline with what I was thinking but implemented better than I was thinking :)
<pedronis> jdstrand: I made some changes to #7254 after your comments there
<mup> PR #7254: cmd/snap-update-ns: fix pair of bugs affecting refresh of snap with layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/7254>
<jdstrand> pedronis: ack thanks. can you invite me to the standup today?
<mvo> jdstrand: we are in the standup channel
<jdstrand> coming
<pedronis> jdstrand: I added some more comments to the PR
<jdstrand> pedronis: ack
<mvo> jdstrand: I pushed some tweaks to the 7265 osutil.FindUid pr, thanks for your feedback! the spread test should also pass now
<cachio> mvo, Chipaca coudl you please take a look to #7262
<jdstrand> mvo: \o/
<jdstrand> mvo: it's getting close! :)
<jdstrand> this has been a looooooonnngggg time coming :)
<mvo> cachio: merged - and we should totally look into using this for our default sources.list :)
<mvo> jdstrand: yeah, thanks for all your hard work on this one, we are getting close (did it merge without conflicts?)
<cachio> mvo, sure, I'll try that today
<mvo> cachio: thanks! no rush, but it feels like a cool improvement
<mvo> cachio: (what I want to say is that I'm a bit excited about this I guess :)
<cachio> mvo, nice :)
<cachio> I want to go step by step with this
<cachio> if go-build test doesn't fail today
<cachio> we can go with the bigger change
<mvo> cachio: sounds good
<cachio> but I would like to make sure first this archive works well
<cachio> in the meantime I'll create a pr to see how it works
<cachio> mvo, thanks for the support
<pedronis> mvo: let me know when I should do a proper review pass on 7625
<pedronis> heh, 7265
<mvo> pedronis: yes please I think its ready
<pedronis> ok
<mvo> Chipaca: if you could have a quick look at 7257 that would be great, hopefully easy
<Chipaca> mvo: LGTM
<niemeyer> mup: Hi
<mup> niemeyer: In-com-pre-hen-si-ble-ness.
<niemeyer> Brilliant..
<niemeyer> Alright folks, mup can now self-identify and even steal-back its own nick through nickserv
<niemeyer> So this should be the end of its regular silenece
<niemeyer> silence
 * cachio lunch
<mvo> niemeyer: \o/
<mvo> niemeyer: thank you!
<niemeyer> np, sorry for how long it took
<niemeyer> Please do let me know if it gets stuck from now on..
<jdstrand> mvo: the initial one did not, no, but I massaged it
<pedronis> mvo: +1 with some comments
<jdstrand> mvo: re tests: fix user-libnss test> hehe
<mvo> jdstrand: that was "fun" (not!)
<mvo> pedronis: thanks, working through them now
<jdstrand> mvo: :)
<pedronis> mvo: sorry, I nitpicked a bit on the spread tests comments
<mvo> pedronis: thanks, appreciated the careful review
 * ijohnson takes a break
<mvo> jdstrand: sorry, one more commit to the spread test for user-libnss
<mvo> jdstrand: with that it should really pass now
<jdstrand> hehe, np
<jdstrand> I know how spread testing goes :)
<jdstrand> (merged)
<mvo> jdstrand: meh, its still not always passing, I think there is some kind of race, I'm looking
<mup> PR snapcraft#2665 closed: Plugin catkin: disable parallel option <Created by artivis> <Closed by artivis> <https://github.com/snapcore/snapcraft/pull/2665>
<mup> PR snapcraft#2669 opened: Plugin catkin: forward parallel build count <Created by artivis> <https://github.com/snapcore/snapcraft/pull/2669>
 * Chipaca sets spread on fire and walks away
<roadmr> ð¥
<cachio> Chipaca, question
<cachio> we restart snapd during reset for each test
<cachio> is that triggering a catalog refresh?
<cachio> right?
 * cachio afk
<pedronis> jdstrand: not sure we understand yet the failures of that new test, it seems something is not picking up the new configuration
<jdstrand> pedronis: I theorized in the 7265 PR it might be the systemd entry in nsswitch.conf
<pedronis> the failure right now is silly though
 * jdstrand takes a closer look
<pedronis> anyway we should try to make it work with getent itself
<pedronis> before trying with our lib
<jdstrand> oh heh
<jdstrand> pedronis: well, the if ./findid uid extratest can never pass cause we didn't go build anything, no?
<mup> PR snapd#7267 opened: many: simpler access to snap-seccomp version-info <Created by pedronis> <https://github.com/snapcore/snapd/pull/7267>
<pedronis> we are just trying though
<pedronis> the code right now is silly
<pedronis> not sure what it did before the current hackish state
<pedronis> though
<diddledan> hacky code > nocode :-p
<diddledan> for a proper hacky code you want some epletive-ridden comments
<diddledan> expletive*
<diddledan> and a few comments of the form "I have no idea why this works" and "what was this supposed to do anyway?"
<pedronis> jdstrand: so playing in the debug shell after it fails things work
<mup> PR snapcraft#2670 opened: Plugin colcon: forward parallel build count <Created by artivis> <https://github.com/snapcore/snapcraft/pull/2670>
<pedronis> jdstrand: I think the failure is just silly
<pedronis> it's because of println I think
<pedronis> testing the fix
<pedronis> jdstrand: pushed the fix I think
<mup> PR snapd#7268 opened: tests: add /var/cache/snapd to the snapd state to prevent error on the store <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7268>
<jdstrand> pedronis: I also see that the println was problematic and fixed that here and it passed
<jdstrand> pedronis: note, restore is not cleaning up extratest. it should: userdel --extrausers extratest
<jdstrand> pedronis: I added two comments to the PR and merged/pushed to 7214
<jdstrand> pedronis: thanks for looking at that. println to stderr... indeed, silly bug :)
 * cachio afk
<mup> PR snapd#7269 opened: tests: add test for services disabled during refresh hook <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7269>
<mup> PR snapd#7270 opened: [RFC] overlord: save disabled snap svcs on unlink snap tasks <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7270>
#snappy 2019-08-17
<mup> PR snapd#7265 closed: osutil: add osutil.Find{Uid,Gid} <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7265>
#snappy 2019-08-18
<mup> PR snapd#7271 opened: many: generalize assertstate.Batch to asserts.Batch, have assertstate.AddBatch <Created by pedronis> <https://github.com/snapcore/snapd/pull/7271>
<mup> Issue core18#137 opened: [Suggestion] Make the motd writable <Created by Dragon8oy> <https://github.com/snapcore/core18/issue/137>
#snappy 2020-08-10
<javatexan> I am trying to get to dashboard from another computer since Ubuntu core doesnât  have GUI
<zyga> good morning
<zyga> wow, I'm early
<mborzecki> morning
<zyga> mborzecki: hey
<zyga> mborzecki: I think today is get-master-to-work day
<zyga> I left some notes on https://github.com/snapcore/snapd/pull/9121
<mup> PR #9121: github: remove Ubuntu 19.10 from actions workflow <Simple ð> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9121>
<mborzecki> zyga: hey
<zyga> but there are other bugs that essentially make master red - I restarted that branch all the time over weekend
<zyga> mborzecki: something is killing/stopping systemd --user for root
<zyga> which takes down dbus for root
<zyga> and makes snapd fail on installing anything with user services
<zyga> so those tests almost always fail
<mborzecki> zyga: which systems are affected?
<zyga> this is in addition to the regular set of random failures
<zyga> I'm running fedora-32 as that's what I was debugging on Friday
<zyga> but it affects ubuntu 20.04 as well
<zyga> I think it's more of a luck factor (some systems managed to pass) or a specific-test factor (test only on some system that breaks the world for the rest)
<zyga> unsure
<zyga> I set workers to one and will have some more info
<zyga> from Friday:
<zyga> <zyga-x240> 2020-08-07T15:54:53.3788099Z     - google:fedora-32-64:tests/main/snap-user-service
<zyga> <zyga-x240> 2020-08-07T15:54:53.3788764Z     - google:fedora-32-64:tests/main/snap-user-service-socket-activation
<zyga> <zyga-x240> 2020-08-07T15:54:53.3797466Z     - google:fedora-32-64:tests/main/snap-user-service-start-on-install
<zyga> <zyga-x240> 2020-08-07T15:54:53.3798599Z     - google:fedora-32-64:tests/main/snap-user-service-upgrade-failure
<zyga> those failed but pass in isolation
<mborzecki> mhm
<zyga> <zyga-x240> google:fedora-32-64 .../tests/main/snap-mgmt# ls -ld /run/user/0/snapd-session-agent.socket
<zyga> <zyga-x240> srw-rw-rw-. 1 root root 0 Aug  7 19:46 /run/user/0/snapd-session-agent.socket
<zyga> <zyga-x240> google:fedora-32-64 .../tests/main/snap-mgmt# systemctl --user status snapd-session-agent.socket
<zyga> <zyga-x240> Failed to connect to bus: Connection refused
<zyga> <zyga-x240> wat?
<zyga> <zyga-x240> google:fedora-32-64 .../tests/main/snap-mgmt# ls /run/user/0/bus -l
<zyga> <zyga-x240> srw-rw-rw-. 1 root root 0 Aug  7 19:46 /run/user/0/bus
<zyga> in addition:
<zyga> <zyga-x240> root       45646  0.0  0.2  27040  9888 ?        Ss   19:47   0:00 /usr/bin/python3 /snap/test-snapd-service/x1/bin/start-stop-mode sighup
<zyga> there's a test that installs malfunctioning services
<zyga> and those clearly leak and just stay behind
<zyga> we should fix that as well though it seems harmless
<zyga> some more debugging:
<zyga> <zyga-x240> connect(3, {sa_family=AF_UNIX, sun_path="/run/user/0/bus"}, 18) = -1 ECONNREFUSED (Connection refused)
<zyga> strace from systemctl --user status ...
<zyga> lastly:
<zyga> <zyga-x240> this is the test sequence: google:fedora-32-64:tests/main/degraded google:fedora-32-64:tests/main/interfaces-broadcom-asic-control google:fedora-32-64:tests/main/login google:fedora-32-64:tests/main/snapshot-cross-revno google:fedora-32-64:tests/main/interfaces-content-mimic google:fedora-32-64:tests/main/refresh-undo google:fedora-32-64:tests/main/media-sharing google:fedora-32-64:tests/main/snap-switch google:fedora-32-64:tests/main/try-snap-g
<zyga> oes-awa
<zyga> <zyga-x240> y:test_snapd_service google:fedora-32-64:tests/main/security-seccomp google:fedora-32-64:tests/main/core18-with-hooks google:fedora-32-64:tests/main/security-dev-input-event-denied google:fedora-32-64:tests/main/snap-run google:fedora-32-64:tests/main/interfaces-content-mkdir-writable:snap google:fedora-32-64:tests/main/retryable-error google:fedora-32-64:tests/main/snap-handle-link google:fedora-32-64:tests/main/interfaces-location-control
<zyga> <zyga-x240> google:fedora-32-64:tests/main/interfaces-netlink-audit google:fedora-32-64:tests/main/snap-mgmt google:fedora-32-64 .../tests/runtime-state#
<zyga> that's all I know
<zyga> I forgot the seed value :/
<zyga> sorry
<zyga> oh, and master is still broken due to 19.10 removal
<zyga> so perhaps fixes should go to https://github.com/snapcore/snapd/pull/9121
<mup> PR #9121: github: remove Ubuntu 19.10 from actions workflow <Simple ð> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9121>
<zyga> or mvo could merge that and we could target fixes to individual branches
<zyga> mborzecki: I wonder if my fixes didn't break master: I added this to some tests: systemctl --user stop dbus.service
<zyga> perhaps that's wrong and after getting dbus activated over the socket, it's impossible to reliably stop it
<zyga> note that this was specifically used to stop root's dbus
<mborzecki> zyga: as if once it becomes part of the session, it goes down with a session?
<zyga> perhaps
<zyga> I really don't know
<zyga> we normally have systemd --user
<zyga> but not dbus.service (--user for root)
<zyga> at least that's what I think,
<zyga> need to find the reproducing seed first
<zyga> mvo: good morning
<zyga> mvo: we need your help
<mvo> zyga: good morning
<mvo> zyga: how can I help?
<zyga> mvo: please merge https://github.com/snapcore/snapd/pull/9121
<mup> PR #9121: github: remove Ubuntu 19.10 from actions workflow <Simple ð> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9121>
<zyga> mvo: we have several problems breaking master
<zyga> that branch was restarted many times over weekend
<zyga> mvo: I updated mborzecki on the issue as much as I know
<mborzecki> mvo: hey
<zyga> mvo: the short summary is that something is causing systemd --user for root to shut down, breaking all tests that install snaps with user services
<zyga> mvo: I'm working on debugging that now
<mvo> zyga: ok
<mvo> mborzecki: good morning
<mvo> zyga: merged
<mvo> zyga: is 9119 ready? it looks ok to me and has 2 +1 but is in draft so can't be merged
<mup> PR snapd#9121 closed: github: remove Ubuntu 19.10 from actions workflow <Simple ð> <â  Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9121>
<mup> PR snapd#9123 closed: vendor: update secboot to support dual signed EFI binaries <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9123>
<zyga> re, back from breakfast
<zyga> mvo: yeah, it was ready
<zyga> thank you for merging, I hope we can fix the remaining issues quickly
<zyga> mvo: merging https://github.com/snapcore/snapd/pull/9112 would help as well, somehow I keep hitting that in my debug runs
<mup> PR #9112: tests: run as hightest via tests.session <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9112>
<zyga> oh
<zyga> haha, nice
<mvo> zyga: I mark 9119 as ready then
<zyga> thanks
<zyga> I wanted to get a clean pass but I think that's less practical now
<mup> PR snapd#9109 closed: github: run CLA checks on self-hosted workers <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9109>
<mup> PR snapd#9112 closed: tests: run as hightest via tests.session <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9112>
<mup> PR snapd#9113 closed: tests: port regression-home-snap-root-owned to tests.session <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9113>
<zyga> I started early today as I have physio at 18;00
<pstolowski> morning
<zyga> good morning Pawel
<mborzecki> pstolowski: hey
<mvo> good morning pstolowski
<mup> PR snapd#9104 closed: tests: fix for timing issues on journal-state test <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9104>
<mup> PR snapd#9119 closed: many: remove usage and creation of hijacked pid cgroup <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9119>
<zyga> brb,
<zyga> rebased on master, no luck with fixes yet
<zyga> back in 20
<zyga> reproduced
<zyga> master
<zyga> spread -seed=1597043051 -debug -v google:fedora-32-64:tests/main/
<zyga> this fails on - Make snap "test-snapd-user-service" (unset) available to the system (Post "http://0/v1/service-control": dial unix /run/user/0/snapd-session-agent.socket: connect: connection refused)
<zyga> inside 2020-08-10 09:32:24 Error executing google:fedora-32-64:tests/main/snap-user-service (aug100704-587445) :
<zyga> I'll try to understand what causes this now
<zyga> prior tests on this machine:
<zyga> google:fedora-32-64:tests/main/degraded google:fedora-32-64:tests/main/interfaces-broadcom-asic-control google:fedora-32-64:tests/main/try-snap-goes-away:test_snapd_tools google:fedora-32-64:tests/main/services-stop-timeout google:fedora-32-64:tests/main/interfaces-fuse-support:parallel google:fedora-32-64:tests/main/install-refresh-remove-hooks:regular google:fedora-32-64:tests/main/interfaces-home google:fedora-32-64:tests/main/snap-interface
<zyga> google:fedora-32-64:tests/main/debug-sandbox google:fedora-32-64:tests/main/auto-refresh-retry google:fedora-32-64:tests/main/change-errors google:fedora-32-64:tests/main/umask google:fedora-32-64:tests/main/user-session-env google:fedora-32-64:tests/main/security-apparmor google:fedora-32-64:tests/main/parallel-install-services google:fedora-32-64:tests/main/abort google:fedora-32-64:tests/main/interfaces-appstream-metadata google:fedora-32-64:tests/main/r
<zyga> etry-network google:fedora-32-64:tests/main/interfaces-network-control-ip-netns google:fedora-32-64:tests/main/snapctl-is-connected google:fedora-32-64:tests/main/cgroup-tracking:root google:fedora-32-64:tests/main/services-disabled-kept-unhappy google:fedora-32-64:tests/main/op-remove-retry google:fedora-32-64:tests/main/revert-devmode:remote google:fedora-32-64:tests/main/base-snaps google:fedora-32-64:tests/main/interfaces-shutdown-introspection
<zyga> google:fedora-32-64:tests/main/snapd-notify google:fedora-32-64:tests/main/install-sideload-epochs:reexec1 google:fedora-32-64:tests/main/auto-aliases google:fedora-32-64:tests/main/snap-remove-not-mounted google:fedora-32-64:tests/main/interfaces-netlink-connector google:fedora-32-64:tests/main/debug-confinement google:fedora-32-64:tests/main/services-stop-mode google:fedora-32-64:tests/main/known google:fedora-32-64:tests/main/user-data-handling
<zyga> google:fedora-32-64:tests/main/interfaces-framebuffer google:fedora-32-64:tests/main/base-policy google:fedora-32-64:tests/main/chattr google:fedora-32-64:tests/main/interfaces-system-observe google:fedora-32-64:tests/main/searching google:fedora-32-64:tests/main/interfaces-desktop-host-fonts google:fedora-32-64:tests/main/interfaces-hardware-random-observe google:fedora-32-64:tests/main/snap-user-service + echo '# free space'
<zyga> (sorry for pasting most of the log directly)
<mborzecki> is pedronis around today?
<zyga> I don't recall
<zyga> heh, cats fighting outside
<zyga> funny noises
<zyga> interesting that user@0.service is stopped normally
<zyga> Aug 10 07:25:30 aug100704-587445 systemd[912]: Reached target Exit the Session.
<zyga> 7:25:30
<mborzecki> zyga:linger?
<zyga> we should log tests
<zyga> as in log the start / stop of a test to journal
<zyga> this will make it evident what's going on
<zyga> possibly
<mborzecki> we had some changes in how linger is enabled
<mborzecki> probably like ~month ago
<zyga> worth a try
<mborzecki> heh, 9 files changed, 577 insertions(+), 137 deletions(-), can't really make the content update observer smaller
<mborzecki> tests inflate it a lot
<zyga> mborzecki: yeah
<zyga> tests.session -u root stops
<zyga> stops user@0.service
<zyga> hmm
<zyga> maybe restore for root
<zyga> should remember if we had really started that
<zyga> and re-start it
<zyga> that would give us working dbus
<zyga> ok, I have an idea, let's try to write a patch
<zyga> mborzecki: I also wonder what amplified this problem
<zyga> was it something we did or was it the dependencies changing
<mborzecki> zyga: afaiu it's observable on stable distros now?
<mborzecki> so i'd bet on something in the tests
<zyga> mborzecki: on 20.04
<zyga> so presumably that's us
<zyga> mborzecki: but this is so weird
<zyga> we disable root linger
<zyga> but not stop anything
<zyga> maybe the recent changes I did for systemd-logind caused this
<mborzecki> pedronis: hi, i've opened #9124, it's mounted fs updater & gadget.Update(), still the diffstat is +579 â137
<mup> PR #9124: gadget: introduce content update observer <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9124>
<mup> PR snapd#9124 opened: gadget: introduce content update observer <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9124>
<pedronis> mborzecki: thx
<mborzecki> hmm An error occurred with the instance when trying to launch with 'LXD': Unable to fetch https://cloud-images.ubuntu.com/buildd/daily/xenial/20200728/xenial-server-cloudimg-amd64-lxd_combined.tar.gz: 404 Not Found.
<mborzecki> at least it does return 404
<zyga> the date is very precise, do we use a fixed image URL?
<zyga> perhaps we need to "lxd something" for lxd to find the proper images
<mborzecki> https://cloud-images.ubuntu.com/buildd/daily/xenial/20200728/xenial-server-cloudimg-amd64-lxd_combined.tar.gz does not 404
<amurray> mborzecki zyga: this is a known issue - https://forum.snapcraft.io/t/snapcraft-with-lxd-pulling-an-outdated-lxc-image/19324/3 - well not sure if the right cpc folks who could fix it know about it but is due to out of date simplestreams metadata
<zyga> ah, thanks for sharing that
<zyga> I found the problem
<zyga> eh
<zyga> systemd bugs :/
<zyga> restarting logind is just not a good idea
<zyga> I think we need to do two things
<zyga> move the workaround for an older systemd bug into the system global prepare
<zyga> then combine that with the upgrade of systemd
<zyga> and REBOOT
<zyga> mborzecki: the problem seems to be that logind doesn't remember sessions
<zyga> and when we disable linger
<zyga> it forgets it had a root session that was made by spread
<zyga> so the recent fix for sid has amplified the problem
<zyga> lennart replied to our bug: https://github.com/systemd/systemd/issues/16685#issuecomment-670166505
<zyga> systemd maintainers are sure responsive, that's really nice
<zyga> eh
<zyga> yeah, confirmed
<zyga> restarting logind does lose state
<zyga> at least in 245
<zyga> mborzecki: https://github.com/systemd/systemd/issues/16685#issuecomment-671239737
<zyga> mvo: I will try to fix master, at least make it better, in the next hour, sorry for the mess
<zyga> it's the fallout from the sid fix indeed
 * zyga tests a fix now
<zyga> mborzecki: yet-untested draft of the fix: https://github.com/snapcore/snapd/pull/9125
<mup> PR #9125: tests: fix issues related to restarting systemd-logind.service <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9125>
<zyga> locally tests are in flight, I'll report back when I get some results
<mup> PR snapd#9125 opened: tests: fix issues related to restarting systemd-logind.service <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9125>
<zyga> can we do something about the issue with lxd images?
<zyga> mborzecki: eh, can we REBOOT from project prepare in general?
<zyga> I recall arch does
<zyga> but it has modern bash
<zyga> are we still affected by the bash bug with exit code propagation?
<mborzecki> zyga: iirc REBOOT works in prepare, there were problems in restore
<zyga> ah, I see
<zyga> oh man
<zyga> catch 22
<zyga> core workaround
<zyga> and linger workaround
<zyga> core16 is a big problem now :/
<zyga> but first, let me go downstairs, I really don't know where to work today
<zyga> bedroom is an oven, office a frying pan
<pedronis> mborzecki: mvo: #9095 needs a 2nd review
<mup> PR #9095: boot/bootstate20: unify commit method impls, rm bootState20MarkSuccessful <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9095>
<mborzecki> pedronis: it's in my queue
<zyga> mborzecki: hmm, it seems we cannot REBOOT from project prepare though
<zyga> https://pipelines.actions.githubusercontent.com/xS8oSnypZkPEQZqiZgDaRp2kdvQJKbOY08TesHp7E8vn7g4hYR/_apis/pipelines/1/runs/10735/signedlogcontent/75?urlExpires=2020-08-10T10%3A26%3A15.6985947Z&urlSigningMethod=HMACV1&urlSignature=KBzWVhJfo58j12Er5gL0cjRFu7LXUhaRJ52TCxy8R%2B4%3D
<zyga> 2020-08-10T09:39:43.8002986Z <REBOOT>
<zyga> or am I reading that wrong
<zyga> after REBOOT the test fails
<mborzecki> hm
<mborzecki> maybe it's not producing the same exit status as REBOOT?
<zyga> but this is weird
<zyga> we only have one REBOOT
<zyga> the one provided by spread is unset immediately after cloning it
<zyga> and this is long after
<zyga> but this is still weird, I mean, I'm testing this locally
<mborzecki> zyga: can you try with this https://github.com/snapcore/spread/pull/85 ?
<mup> PR spread#85: spread/client: workaround bash 4.3 subshell errexit issues <Created by bboozzoo> <https://github.com/snapcore/spread/pull/85>
<zyga> and I surely don't get failures (I was only testing Fedora)
<zyga> oh
<zyga> so this didn't land!?
<zyga> mborzecki: I can but it works for me (I'm using the same spread as our workers do)
<zyga> something doesn't make sense here
<zyga> hm, fedora 32 failed after 24 minutes
<zyga> so perhaps it does work on fedora
<zyga> but it fails in a different way
<zyga> 2020-08-10T10:01:49.7316727Z ##[error]2020-08-10 10:01:49 Error preparing google:fedora-32-64 (aug100938-989118) : rebooted on aug100938-989118 (google:fedora-32-64) more than 10 times
<zyga> like a reboot loop
<zyga> yet my local run is at 3/4 of completion without an issue
<zyga> I think my code is naive
<zyga> I need to have a condition for REBOOT
<mup> PR snapd#9126 opened: boot: introduce current_boot_assets and current_recovery_boot_assets to modeenv <Simple ð> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9126>
<mborzecki> pedronis: hopefully this is a trvial one ^^
<zyga> how do I check the running version of systemd-logind
<zyga> ok I think I have an idea
<zyga> mborzecki: how does https://paste.ubuntu.com/p/vj7B5DNf3d/
<zyga>  look like
<zyga> ouch
<zyga> sorry
<zyga> back pain
<zyga> I tried to work sitting
<zyga> mborzecki: we can detect if systemd was updated across 245-246 line
<zyga> uh back to bed for now
<zyga> ouch
<zyga> easier said
<mborzecki> zyga: so when we're running < 246 and update pulls in 246+ we restart?
<mborzecki> zyga: does it happen anywhere outside of arch/tw/sid?
<zyga> mborzecki: yeah, that's the idea
<zyga> we also restart if we had to reconfigure systemd
<zyga> er, logind
<zyga> so the actual upgrade happens on sid for now
<zyga> but the other condition also happens on many systems
<zyga> it's just less frequent
<zyga> the bottom line is that restarting logind is just unsafe
<zyga> I have no idea how to solve this on 16.04
<zyga> where we need to make mount changes to make logind fixable
<zyga> fix it
<zyga> restart it to apply the fix
<zyga> (that's already wrong then)
<jamesh> zyga: I think I've addressed all the feedback on #9043 either with code changes or responses to comments.
<mup> PR #9043: daemon: replace access control flags on commands with access checkers <Needs security review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/9043>
<zyga> ack
<zyga> I'll look after current master woes
<jamesh> zyga: as far as naming of the access checkers, I think there is value in keeping the naming consistent with the documentation
<zyga> jamesh: perhaps, but only if the name is accurate
<jamesh> zyga: sure.  I'm not saying the docs are immutable
<zyga> brb
<zyga> got a clean run on fedora 32
<zyga> thinking about core16 options
<zyga> mborzecki: yeah, so REBOOT is busted
<zyga> https://github.com/snapcore/snapd/pull/9125/checks?check_run_id=966349834
<mup> PR #9125: tests: fix issues related to restarting systemd-logind.service <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9125>
<zyga> I'm certain we need some kind of workaround for that bash issue
<mborzecki> zyga: have you tried with the spread branch?
<zyga> I'll try merging it locally to see if that helps
<zyga> not yet
<zyga> I will
<zyga> if it helps we need to get that reviewed
<zyga> I wonder what to do now
<zyga> should we revert the restart "fix" for sid
<zyga> disable sid for now
<zyga> do something else
<zyga> mvo: ^ advice welcome
<mup> PR snapd#9127 opened: bootloader: introduce TrustedAssetsBootloader, implement for grub <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9127>
<mborzecki> pedronis: trusted assets bootloader thingy ^^
<mborzecki> time to do some reviews
<mborzecki> hm we haven't landed any bits for debug that call uname -a or somesuch?
<zyga> mborzecki: we have a PR from cachio
<mborzecki> mhm, just +1'ed it
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/9116/checks?check_run_id=965583423
<mup> PR #9116: tests: add system information and image information when debug info is displayed <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9116>
<mborzecki> 2020-08-10T07:31:53.5421376Z Linux aug100702-249153 4.15.0-1080-gcp #90~16.04.1-Ubuntu SMP Fri Jul 10 19:11:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
<mup> PR #90: Default to SocketMode=0660 if no socket mode option is given <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/90>
<mborzecki> and we have cgroup2fs under /sys/fs/cgroup
<mborzecki> on xenial
<zyga> mborzecki: that's ... just wrong?
<zyga> how can we get that?!
<zyga> is it overmounted
<zyga> as in shadowing the tmpfs normally there
<mborzecki> zyga: hm i misread, it's tmpfs, we check whether /sys/fs/cgroup/unified exists, but it does not?
<zyga> mborzecki: hmmmm
<zyga> that's possible
<zyga> though I don't remember what the conditions are
<zyga> maybe our check is wrong?
<pedronis> mborzecki: I reviewed #9124, looks good but couple of questions
<mup> PR #9124: gadget: introduce content update observer <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9124>
<mborzecki> pedronis: thanks
<mup> PR snapd#9128 opened: tests/main/cgroup-tracking: try to collect some information about cgroups <Simple ð> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9128>
<mborzecki> zyga: ^^ some more info
<zyga> nice
<zyga> let's see what that shows
<zyga> today is not a very good day, is it?
<zyga> I'm making progress, will try a core 16 idea nonw
<zyga> *now
<pedronis> mborzecki: question(s) in #9127
<mup> PR #9127: bootloader: introduce TrustedAssetsBootloader, implement for grub <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9127>
<mborzecki> pedronis: right, that's for the case if one gets a bootloader without NoSlashBoot in options, it should probably be internal error as you indicated, it's not a reasonable use case
<mborzecki> pedronis: current_trusted_recovery_boot_assets?
<pedronis> mborzecki: ok, let's have the error and see how it goes
<mborzecki> instead of current_recovery_trusted_boot_assets
<pedronis> that probably reads better
<zyga> amazing
<zyga> what am I missing
 * zyga checks spread source
<zyga> nah, I am running master
<zyga> ok, lets see if main passes
<zyga> core16 did not crash and burn for me locally
<ijohnson> morning folks
<pedronis> ijohnson: hello
<ijohnson> hi pedronis
<ijohnson> pedronis: thoughts on moving envRefExtractedKernelBootloaderKernelState and extractedRunKernelImageBootloaderKernelState to a different file, maybe boot/bootstate20_kernelstate.go ?
<ijohnson> that would make the bootstate20 file a little bit easier to navigate I think
<ijohnson> of course not for my current PR, but a followup
<zyga> hey ijohnson :)
<ijohnson> hey zyga
<pedronis> ijohnson: sounds ok
<ijohnson> pedronis: cool I'll try to do that after we land the current PR
<zyga> mvo: I've added https://github.com/snapcore/snapd/pull/9129 for 2.46
<mup> PR #9129: sandbox/cgroup: remove temporary workaround for multiple cgroup writers <Created by zyga> <https://github.com/snapcore/snapd/pull/9129>
<mup> PR snapd#9129 opened: sandbox/cgroup: remove temporary workaround for multiple cgroup writers <Created by zyga> <https://github.com/snapcore/snapd/pull/9129>
<zyga> mvo: what would it take to make /var/lib/systemd/ writable on core16 (it is writable on 18 and 20 already) - I'm specifically after /var/lib/systemd/linger so we could have a subset of the directory (just linger) available to help
<ijohnson> zyga: just for our tests or IRL too ?
<zyga> ijohnson: it's just for out tests but we seem to have done this on core18+ so I guess that's for a reason
<zyga> and IRL is a weird way to describe that :)
<zyga> brb, small break
<pedronis> in general it's easier to have the 3 consistent when there's no strong reason for not
<ijohnson> zyga: yeah in that case we should just do it IRL for core snap
<zyga> I agree
<zyga> consistency
<zyga> and less special cases
<ijohnson> indeed
<zyga> I will break for lunch and an errand and then go for physio
<zyga> I will do my best to work when I'm back to prepare the fixes for logind
<cachio> pstolowski, ijohnson thanks for the review fo #8942, I already answer the question about the variable
<mup> PR #8942: tests: support different images on nested execution <Run nested> <Squash-merge> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8942>
<ijohnson> thanks cachio
<cachio> ijohnson, sorry for the delay, didn't see that on friday
<ijohnson> no worries
<pstolowski> cachio: thanks
<pedronis> mvo: cachio: are we releasing .3.1 today?
<cachio> pedronis, I am waiting confirmation from store team
<pedronis> thx
<cachio> pedronis, they asked me to wait
<cachio> pedronis, progressive release for core snap started
<cachio> mvo, ~
<mvo> cachio: nice, thanks
<pedronis> thx
<pedronis> mvo: it would probably good to land #9086 but it needs a 2nd review (it's a cleanup)
<mup> PR #9086: many: reorg cmd/snapinfo.go into snap and new client/clientutil <Cleanup :broom:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9086>
<mvo> pedronis: looking
<pedronis> mvo: I moved my assertions PR to 2.47
<mvo> pedronis: thank you
<zyga> made some more progress on core16, should have a green pass soon
<zyga> but now physio
<zyga> see you in a few hours
 * cachio lunch
<ijohnson> mborzecki: have you seen the triggerwatch unit test  triggerwatchSuite.TestNoDevsWaitKey fail before?
<ijohnson> FAIL: triggerwatch_test.go:80: triggerwatchSuite.TestNoDevsWaitKey
<ijohnson> triggerwatch_test.go:87:
<ijohnson>     c.Assert(err, IsNil)
<ijohnson> ... value *errors.errorString = &errors.errorString{s:"trigger not detected"} ("trigger not detected")
<ijohnson> OOPS: 4 passed, 1 FAILED
<pedronis> mvo: I forgot to mention last week, did you see this: https://github.com/snapcore/core18/pull/155 ?  (same for the parallel PRs), the name of the dir is wrong
<mup> PR core18#155: hooks: fix broken symlink /etc/sysctl.conf.d/99-sysctl.conf <Created by mvo5> <https://github.com/snapcore/core18/pull/155>
<mvo> pedronis: oh, missed that, sorry
<ijohnson> interestingly a model assertion unit test panic'd on riscv64, seems to be timing related somehow https://pastebin.ubuntu.com/p/7ppt8pTbdz/
<ijohnson> cachio: do you need to delete some images on gce again? I see `2020-08-10 14:33:27 Cannot allocate google:opensuse-tumbleweed-64: cannot allocate new Google server google:opensuse-tumbleweed-64 (aug101430-988733): cannot find ready marker in console output for google:opensuse-tumbleweed-64 (aug101430-988733)` in spread runs now
<mborzecki> ijohnson: heh, probably a timing issue
<mborzecki> was outside for a bit, +35C
<mvo> pedronis: I reviewed 9086 now
<kenvandine> mvo: what's the status of lzo support?  Is that ready to be used?  What snapd version first supported it?
<mvo> kenvandine: for snapd on install it's actually transparent, so any snapd version will work
<kenvandine> but not at runtime.  We're talking about injecting an "assumes" in there
<mvo> kenvandine: not at runtime? what issue/error do you see with older snapd versions?
<mvo> kenvandine: "snap pack --compression=lzo" is more recent
<kenvandine> wait... when you launch the snap on an old version of snapd
<mvo> kenvandine: but the ability to run lzo snaps should be transparent to snapd
<kenvandine> that would work?
<mvo> kenvandine: yes
<mvo> kenvandine: I don't see why it would not :) maybe I'm missing something
<kenvandine> ok, i thought there was talk about needing specific versions
<kenvandine> i guess i misunderstood :)
<kenvandine> mvo: and no known issues on other distros?  centos, fedora, etc?
<mvo> kenvandine: same, as long as they have a kernel that supports lzo for squashfs (which they all do) then this will be fine
<kenvandine> ok
<kenvandine> mvo: thanks, we're going to start testing it :)
<kenvandine> with real snaps
<mvo> kenvandine: \o/ nice!
<mvo> kenvandine: AIUI chromium is already whitelisted in the reviewtools to allow lzo
<kenvandine> ok
<kenvandine> Wimpress was suggesting we try a few snapcrafter snaps first, so we'll work that out
<kenvandine> and maybe experiment with the gnome platform snap too
<cachio> ijohnson,  done
<Aavar> How would I go about building a snap of deluge 1.3 for 20.04? Or better yet, would anyone be interested in creating such a snap?
<ijohnson> thanks cachio
<oerheks> Aavar, there is 2.0.3 already
<oerheks> https://snapcraft.io/deluge-lukewh
 * zyga-mbp is back from physio but not working ye
<zyga-mbp> *yet
<mup> PR snapd#9130 opened: [RFC] Support for gadget.yaml "$kernel:" style references <Created by mvo5> <https://github.com/snapcore/snapd/pull/9130>
<ijohnson> cachio: I
<ijohnson> I'm still seeing that ready marker error in spread with tumbleweed
<ijohnson> `2020-08-10 17:21:32 Cannot allocate google:opensuse-tumbleweed-64: cannot allocate new Google server google:opensuse-tumbleweed-64 (aug101718-511919): cannot find ready marker in console output for google:opensuse-tumbleweed-64 (aug101718-511919)`
<ijohnson> does it take a while for that to deploy ?
<cachio> ijohnson, ah, ok, in that case this is another error
<cachio> let me cehck again
<ijohnson> ok
<cachio> ijohnson, fixed
<ijohnson> thanks I'll try again
<cachio> I'll need to re create a new image for tumbleweed
<zyga> back from physio
<zyga> how are things?
<zyga> I will get back to 16.04 part of the problem in a moment, let me review public tests first
<cachio> zyga, I could reproduce the error in the cgroup-tracking
<zyga> cachio: tell me more!
<cachio> but still couldn't find which test is producing it
<zyga> cachio: I reproduced it a few times
<zyga> cachio: but I didn't focus on debugging it yet, I'll try tomorrow - assuming the current issues are fixed
<zyga> cachio: we added some detectors to invariant checker and it's not the kernel - it is clearly some other factor
<cachio> zyga, what I found is that there is another test which if it executed before the  cgroup-tracking test fail
<zyga> cachio: when it happened it was running the 4.15 gce kernel
<zyga> yeah, I think that must be the case
<zyga> we could find an intersection of sets after a few runs
<zyga> I'm sure we'll find it
<cachio> zyga, yes
<cachio> let me find that
<cachio> I'll send you what I find
<cachio> zyga, I think in hours I can have that info
<zyga> cool, drop me a line or go and fix it if you find the broken test
<zyga> I'm no longer always on IRC so mattermost is best for a message box style
<cachio> zyga, sure
<cachio> I'll let you know
<cachio> enjoy your evening
<zyga> thank you :)
<mup> PR core#116 opened: extra-files/writable-paths: make all /var/lib/systemd writable <Created by anonymouse64> <https://github.com/snapcore/core/pull/116>
<cachio> ijohnson, hey
<cachio> I see this is uc20 https://paste.ubuntu.com/p/rhzB3sRQyV/
<ijohnson> hey cachio
<ijohnson> cachio: ah yes that was fixed recently
<ijohnson> --purge only works on a single snap
<ijohnson> you need to do `snap remove --purge jq` `snap remove --purge jq-core18` etc.
<cachio> ijohnson, ah, ok, I'll fix my scripts in that case
<cachio> thanks
<mup> PR snapcraft#3242 opened: tests: remove expected failure case from legacy integration test <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3242>
#snappy 2020-08-11
<mup> PR snapcraft#3243 opened: Add skip-keys to catkin plugin <Created by Levi-Armstrong> <https://github.com/snapcore/snapcraft/pull/3243>
<mborzecki> morning
<mvo> mborzecki: good morning - should I merge 9128 or is it not meant to be on master?
<mborzecki> mvo: hey, hm it's probably ok to merge it, it's only adding some debug output to the test
<mup> PR snapd#9126 closed: boot: introduce current_boot_assets and current_recovery_boot_assets to modeenv <Simple ð> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9126>
<mup> PR snapd#9128 closed: tests/main/cgroup-tracking: try to collect some information about cgroups <Simple ð> <Test Robustness> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9128>
<zyga> good morning
<pstolowski> morning
<mborzecki> zyga: pstolowski: hey
<mborzecki> zyga: left some comments under https://github.com/snapcore/snapd/pull/9128
<mup> PR #9128: tests/main/cgroup-tracking: try to collect some information about cgroups <Simple ð> <Test Robustness> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9128>
<mborzecki> zyga: some weird thing happening on 16.04 and  cgroups
<mvo> good morning zyga
<mvo> hm, so
<mvo> 2020-08-11T07:31:29.8774856Z     - google:ubuntu-20.04-64:tests/main/cgroup-tracking-failure
<mvo> 2020-08-11T07:31:29.8775399Z     - google:ubuntu-20.04-64:tests/main/snap-user-service
<mvo> that is known, right?
<pedronis> mvo: I fear you'll need zyga to undersand the state of that, there's a PR open but I don't know if it's the final story on this
<mvo> pedronis: that's fine, just wanted to double check
<mvo> pedronis: also it was a bit of a general question, not directly targeted to you :)
<mvo> pedronis: did you had a chance to think about the name for the kernel-crypto-api interface? or is the name good already?
<pedronis> I didn't interpret it as targeted to me, but nobody was saying anything :)
<pedronis> mvo: no, I haven't seriously thought about that PR since Friday
<mvo> pedronis: heh :) thanks!
<mborzecki> pedronis: hey, s/TrustedAssetsChain/TrustedAssets/?
<mborzecki> pedronis: tbh i assumed that we'll glue that higher up the call stack, somewhere in boot when (re)sealing
<pedronis> mborzecki: yes, as I said, I think the content matches the doc comment, but the name confused Ian
<mborzecki> ok
<pedronis> or so I think
<pedronis> the glueing is a bit messy because it is across recovery and run bootloaders
<pedronis> but we will deal
<mborzecki> yeah, otoh i'm not sure one bootloader (eg. run) should know that it's being loaded by the recovery one
<mup> PR snapd#9111 closed: releases: release 2.46~pre1 to groovy <Simple ð> <Skip spread> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/9111>
<pedronis> mborzecki: I don't think that's the main problem
<pedronis> mostly for the final glueing we reall need the maps from modeenv
<mup> PR snapd#9131 opened: debian: release 2.46~pre2 <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9131>
<zyga> re
<zyga> sorry, I had a small unexpected errand
<zyga> back now
<zyga> mborzecki: 0 is always the ID of unified cgroup
<zyga> mborzecki: cachio suggested that lxd test is responsible
<zyga> maybe lxd mounts the unified hierarchy somehow
<mborzecki> zyga: ha, as it mounts the hierarchy and it's left behind?
<zyga> mborzecki: I will try that in a moment
<zyga> perhaps
<zyga> that would explain it
<mborzecki> zyga: and sys from the host is bind mounted to the container?
<zyga> and fortunately we have a cleanup script for it
<zyga> I don't fully know, there are some approaches, more than one
<mborzecki> duh, how about systemd container protocol then? :)
<zyga> there's a special fake cgfs as well
<zyga> mborzecki: I think that's beyond my confidence zone
<zyga> but we have a clue
<zyga> I spent a bit too long last night trying to fix core 16
<mborzecki> if it is lxd, then stgraber will probably know more
<zyga> made progress but I EOD past midnight and I was a bit tired in the morning]
<zyga> mborzecki: yeah but it's quick and easy to verify this with -shell-after
<zyga> I'll try that now
<zyga> hey mvo, sorry for starting late
<zyga> mborzecki: actually, first priority is to fix master
<zyga> so give me a moment to wrap up that issue first
<mborzecki> errand, back in 30 or so
<zyga> ok
<mvo> zyga: no worries
<mborzecki> re
 * zyga tries to sit in the office today
<zyga> yesterday that didn't go very well
<mvo> mborzecki: any highlevel concerns/feedback about #9130? especially aobut the plan to make the mountedfilesystemwriter use the ResolvedSource (i.e. an absolute path) and stop passing in the gadget root there?
<mup> PR #9130: [RFC] Support for gadget.yaml "$kernel:" style references <Created by mvo5> <https://github.com/snapcore/snapd/pull/9130>
<mborzecki> mvo: haven't looked yet, i'll do it today
<mvo> mborzecki: it will cause some churn so I want to somewhat be certain it's not in vain :)
<mvo> mborzecki: ok, no worries
<mup> PR snapd#9132 opened: o/hookstate/ctlcmd: add optional --pid argument to "snapctl is-connected" <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/9132>
<mup> PR snapd#9133 opened: osutil: add CommitAs to atomic file <Simple ð> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9133>
<mborzecki> hopefully a trivla PR ^^
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/9133#pullrequestreview-464902323
<mup> PR #9133: osutil: add CommitAs to atomic file <Simple ð> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9133>
<zyga> yes, but with a typo :)
<mborzecki> haha
<mborzecki> ok, let me force push, not worth another patch
<zyga> yeah
<zyga> and cancel current run
<zyga> save $$$
 * zyga tries another iteration of core16 fix
<mborzecki> btw. gh actions still does not support canceling a workflow when a branch is pushed to?
<mborzecki> canceling a running workflow i mean
<zyga> I don't know
<zyga> what else is broken in master
<zyga> we have systemd-logind failing often
<zyga> but there was one more thing IIRC
<mborzecki> zyga: cgroups on xenial
<zyga> ah right
<zyga> thanks
<mborzecki> zyga: and unit tests using gpg fail occasionally
<zyga> thanks :)
<zyga> yeah
<zyga> about that
<zyga> it fails in azure
<mborzecki> snap sign tests iirc
<zyga> not in our gce tests
<zyga> azure VM has all kinds of modifications that are well documented
<mborzecki> but gpg?
<mup> PR snapd#9095 closed: boot/bootstate20: unify commit method impls, rm bootState20MarkSuccessful <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9095>
<mup> PR snapd#9116 closed: tests: add system information and image information when debug info is displayed <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9116>
<zyga> mborzecki: they update lots of things to more recent versions
<zyga> I mean, really anything that people use
<zyga> and pre-install a load of things
<zyga> maybe some interaction there leaks
<mup> PR snapd#9001 closed: o/snapshotstate: helpers for calculating disk space needed for an automatic snapshot (2/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9001>
<mup> PR snapd#9079 closed: gadget/install: retrieve command lines from bootloader <Simple ð> <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9079>
<pedronis> mborzecki: should we just merge #9127 ? we can change again when it's used, if we discover we really need it to be different
<mup> PR #9127: bootloader: introduce TrustedAssetsBootloader, implement for grub <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9127>
<mborzecki> pedronis: i think we should land it and tweak later on
<mborzecki> pedronis: this will probably be clearer when i start opening more bits
<pstolowski> zyga: what's the status of https://bugs.launchpad.net/snapd/+bug/1867193 ? the test PR referenced there was merged long time ago, not a bug once "robust-mount-namespace-updates" are enabled?
<mup> Bug #1867193: failure refreshing snap with content interface <snapd:In Progress by zyga> <https://launchpad.net/bugs/1867193>
<pedronis> mborzecki: I'm adding this comment to the merge:  Notice that this in practice splits across the divide of recovery vs run mode bootloaders, the complete chains for sealing will need to bridge that. We might use a different helper to produce that.
<zyga> I'd mark it as fix released
<zyga> the last comment may be a different bug
<mborzecki> pedronis: sounds good
<mup> PR snapd#9124 closed: gadget: introduce content update observer <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9124>
<mup> PR snapd#9127 closed: bootloader: introduce TrustedAssetsBootloader, implement for grub <UC20> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9127>
<mborzecki> yay
 * mvo hugs mborzecki 
<mvo> sil2100: snapd is in beta now so we can re-enable beta image builds to pending. let me know if you prefer a mail
<zyga> core16 tests are running
<zyga> maybe no more typos
<zyga> fingers crossed
<mvo> zyga: what pr is that?
<zyga> mvo: still local
<zyga> there's a PR but it's only missing core16
<mvo> ok
<zyga> PR number is
<zyga> 9125
<zyga> if it passes then master will be better
<zyga> well, locally, then I push and open the draft for review
<pstolowski> pedronis: #9084 is ready for review (prereq PR landed)
<mup> PR #9084: o/snapstate: check disk space before creating automatic snapshot on remove (3/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9084>
<zyga> tests are running, I need to stop sitting now
<zyga> man standing desk is a godsend
<zyga> I wish I knew that years ago
<sil2100> mvo: thanks! On it!
<mup> PR snapd#9134 opened: boot, o/devicestate: TrustedAssetUpdateObserver stubs, hook up to gadget updates <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9134>
<zyga> one more tweak and I think it will be good
<pstolowski> pedronis: also, do you have a moment today to talk about disk space check & multi snap install/refresh?
<mborzecki> mvo: can you merge https://github.com/snapcore/snapd/pull/9133 ? the test failure are unrelated
<mup> PR #9133: osutil: add CommitAs to atomic file <Simple ð> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9133>
<mvo> mborzecki: sure, done - could you please check 9131 ?
<mborzecki> 2020-08-11T08:38:45.2793033Z 2020-08-11 08:38:45 Cannot allocate google:ubuntu-core-20-64: google: read JWT from JSON credentials: 'type' field is "authorized_user" (expected "service_account")
<mborzecki> wow
<zyga> hmm?
<zyga> JWT?
<mup> PR snapd#9133 closed: osutil: add CommitAs to atomic file <Simple ð> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9133>
<zyga> javascript web token
<zyga> (just making stuff up)
<mborzecki> zyga: close ;)
<zyga> so hot
<zyga> I was outside for a sec
<zyga> to move walk around the block
<mborzecki> mvo: have you added skip spread tag after opening 9131?
<mvo> mborzecki: yes, just now
<mvo> mborzecki: actually silly that I require spread for this
<mborzecki> mvo: i've closed and reopened it, the tag should be picked up now
<mvo> mborzecki: aha, nice
<sil2100> mvo: dailies for beta should now be enabled! You want a new build kicked now?
<mvo> sil2100: yes please
<pedronis> pstolowski: we can chat after the standup if that works for you?
<pedronis> pstolowski: thanks for merging master into #9084
<mup> PR #9084: o/snapstate: check disk space before creating automatic snapshot on remove (3/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9084>
<mup> PR snapd#9131 closed: debian: release 2.46~pre2 <Simple ð> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9131>
<zyga> I think it works now
<zyga> single test passes
<zyga> let me push
 * mvo crosses finger for zygas pr
<zyga> yeah, I want this to be over
<zyga> I'll take a quick shower and I'll start working on the other bug
<zyga> (cgroups)
<pstolowski> pedronis: yes, after standup is fine
<zyga> looking into the cgroup + lxd thing
<zyga> core16 is almost done testing, no failures
<pedronis> mborzecki: some questions/comments in #9134 ?
<mup> PR #9134: boot, o/devicestate: TrustedAssetUpdateObserver stubs, hook up to gadget updates <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9134>
<mborzecki> pedronis: thanks for the reviews (and mvo too)
<zyga> core16 is green
<zyga> let's see if everything else passes now
<zyga> I'm focusing on the lxd thing now
<zyga> first I need to see it
<zyga> the fix should not be complicated
<zyga> mborzecki: yeah, that's really happening
<zyga> I wonder how
<mborzecki> zyga: lxd mounting a unified hierachy?
<zyga> yep
<mborzecki> zyga: or maybe systemd in lxd doing that
<zyga> clear as day
<zyga> I will run again and see which part of the test causes that
<zyga> I will push a quick fix so that we're okay
<mup> PR snapd#9019 closed: tests/nested/manual/minimal-smoke: run core smoke tests in a VM meeting minimal requirements <Run nested> <Created by bboozzoo> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9019>
<zyga> oh man
<zyga> mborzecki: I understand now
<zyga> mborzecki: that cgroupv2 is not mounted inside
<pstolowski> pedronis, mvo thanks for feedback on disk space awareness
<zyga> it was mounted in the container
<zyga> but those are global
<zyga> all processes see all cgroups
<zyga> now where the hell is it mounted?
<zyga> and I think this is more than tests
<zyga> we need to adjust snapd code as well
<zyga> mborzecki: I'm still unclear where this thing is mounted
<zyga> it's not inside the container
<zyga> it's not mounted in the inner container either
<zyga> but the inner container is bionic
<zyga> maybe it's just systemd?
<zyga> hmmm
<zyga> ok I'll bisect
<zyga-mbp> I'll go for lunch now, ttyl
 * cachio lunch
<zyga-mbp> re
<mup> PR snapd#9087 closed: o/snapstate: check available disk space before downloading a snap on install (4/N) <Disk space awareness> <Needs Samuele review> <â Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/9087>
<mup> PR snapd#9135 opened: boot: move bootloaderKernelState20 impls to separate file <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9135>
<mup> PR snapd#9064 closed: .github/workflows: move snap building to test.yaml as separate cached job <Simple ð> <Skip spread> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9064>
 * zyga explores a fix for the cgroup2 thing
<zyga> it's a kernel bu
<zyga> *big
<zyga> *bug
<zyga> or feature
<zyga> depending on how you look
<zyga> we can only work around it
<jdstrand> kenvandine: that's weird. on focal I seem to have gnome-software installed as a deb (fine). I have the review-tools latest/stable installed so I wanted to show someone the permissions dialog, but gnome-software showed that the review-tools were not installed. I pressed the Install button and they install latest/edge
<ijohnson> zyga: the unified cgroup mount after lxd container started ?
<zyga> it's not just thta
<zyga> just mount cgroupv2
<zyga> and unmount it
<zyga> done
<zyga> no containers required
<jdstrand> kenvandine: I wonder if it is because I haven't done 'snap login'? (ie, polkit promted me)
<ijohnson> zyga: ah interesting, maybe we just mount cgroupv2 all the time unconditionally in project prepare and deal with the consequences ?
<zyga> ijohnson: nah, that's unnatural
<zyga> I've adjusted both snapd and the test that's sensitive to it
<zyga> just making final touches
<mup> PR snapd#9136 opened: bootstate20: rm bootState20Modeenv, pass around modeenv directly <Cleanup :broom:> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9136>
<ijohnson> zyga: The dark side of cgroups is a pathway to many abilities some consider ... unnatural
<zyga> haha, is that a star wars quote?
<ijohnson> yes haha
 * ijohnson goes away now and does real things
 * ijohnson well tries too anyways
<zyga> ijohnson: I pushed more fixes to https://github.com/snapcore/snapd/pull/9125
<mup> PR #9125: tests: fix issues related to restarting systemd-logind.service <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9125>
<ijohnson> zyga: nice let me take a look, would be nice to land that
<zyga> I will observe if it passes and we can then either review the ensemble or review in split branches
<zyga> it's still a draft but please have a look for early impression
<ijohnson> zyga: yeah I was just gonna say looking at this and the title it's not obvious how much you had to change, but yes +1 to splitting off the actual Go code changes
<ijohnson> I'll still submit a review for you though
<zyga> ok
<zyga> the go code changes are optional
<zyga> we were lucky
<zyga> this is just for completeness
<ijohnson> ah ok, I thought the Go code was necessary to fix the test
<zyga> I thought so too but again, we were lucky :)
<ijohnson> :-)
<zyga> look at https://github.com/snapcore/snapd/pull/9125/commits/4b3bf6cbb08302b1878a9452e8ddcf9190ab8617
<mup> PR #9125: tests: fix issues related to restarting systemd-logind.service <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9125>
<ijohnson> zyga: so does this present only on 4.15 kernel or is it 4.15+ ?
<zyga> it's any version really
<zyga> just that xenial's systemd does not mount v2 at all
<zyga> so we noticed
<ijohnson> ah right that makes sense
<ijohnson> I just left a review
<zyga> thanks!
<zyga> replied
<zyga> and looking at kernel docs first
<pedronis> ijohnson: I'm not entirely sure whether #9136 is or isn't on the path I described in the previous, to be clear I'm not sure the path is an improvement, we would have to try, it has the propery of making boostate20, closer to bootstate16
<mup> PR #9136: bootstate20: rm bootState20Modeenv, pass around modeenv directly <Cleanup :broom:> <â Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9136>
<ijohnson> pedronis: mmm sorry I didn't see that you want the modeenv in the structs to go away entirely, I thought you just wanted the modeenv struct to go away
<pedronis> ijohnson: yes, my plan was to have it go away completely, that's why I was suprised that not touching initramfs bits was not a problem
<zyga> ijohnson: it seems to be a kernel bug
<zyga> I'll report it and add the reference to the code
<zyga> ijohnson: I guess no bug report
<zyga> ijohnson: quote from #lxcontainers
<zyga> > <zyga> do you have a reference? I will link to that next to our workaround
<zyga> <stgraber> nope, that kind of upstream discussion is all private IRC and telegram ;)
<zyga> I don't mind, I guess that's enough for now
<zyga> tests on https://github.com/snapcore/snapd/pull/9125 are in progress
<mup> PR #9125: tests: fix issues related to restarting systemd-logind.service <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9125>
<zyga> I'll review the services PR and EOD
<stgraber> debating whether it's an issue or not, it's unlikely to be security relevant (as no controllers are auto-loaded on cgroup2) but still  trying to argue that it could confuse badly written software on the host
<zyga> stgraber: yeah, I think it's more surprising than dangerous
 * zyga is tired
<zyga> maybe that review needs to wait
<zyga> it's 8PM
 * zyga EODs, more reviews tomorrow
<zyga> have a good rest of your day friends!
<ijohnson> pedronis: ok, then in this case let's just abandon this PR and do it post uc20 1.0, I really don't know how we could get rid of modeenv entirely without changing a bunch of function/interface signatures and you're about to go on holiday, so not much point to trying to hash it out now I think
<ijohnson> zyga: nice find thanks for looking into it more
<stgraber> zyga: consensus seems to be that it's been that way since 2016, nobody is supposed to assume that because something is listed in /proc/self/cgroup that it's mounted, you need to look at mount table too (as controllers never go away)
<zyga> ack
<zyga> I always found that surprising btw,
<zyga> that there are those nice CG identifier numbers
<zyga> that are dangling and unrelated to the filesystem
<zyga> and that you need to match on the controllers and mountinfo
<zyga> it's probably uninteresting as future has cgroup2 only
<zyga> but v1 was somewhat messy from this point of view
<pedronis> ijohnson: yes, I expected we'll need to change some signatures
<ijohnson> yeah I guess I totally missed that point sorry
<ijohnson> I don't think it's worth it right now to try and simplify that at all, seems quite complex
<ijohnson> IMHO this PR is still a win because it's less structs and less abstractions, but I suppose it is more type casting and slightly duplicative code, so I could see it not as a win too
<ijohnson> if you don't think it's worth it I will just close it and we can revisit the refactor $SOME_DAY+2 now
<pedronis> ijohnson: in light of the fact that we want to do something larger it doesn't feel like a win because of your point two about the extra duplication
<cachio> zyga, hey
<cachio> did you fix the test tests/core/uc20-recovery at some point right?
<pedronis> ijohnson: can you explain me this change though: https://github.com/snapcore/snapd/pull/9136/files#diff-bff1ced30ed4581302ca81b7b53908f9L727  is that needed for that case?
<cachio> ijohnson, or you did it?
<mup> PR #9136: bootstate20: rm bootState20Modeenv, pass around modeenv directly <Cleanup :broom:> <â Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9136>
<pedronis> ijohnson: isn't that needed
<pedronis> ijohnson: ah, it's done lazily by revisions in the new code?
 * cachio afk
<ijohnson> sorry was at lunch
<ijohnson> pedronis: it actually was never needed
<ijohnson> pedronis: we already setup the modeenv when we create the bootState20Base in initramfs.go
<ijohnson> cachio: I think I looked at it and I thought we fixed something there
<pedronis> ijohnson: ah
<ijohnson> cachio: is it failing again now ?
<pedronis> I forgot about that
<ijohnson> yeah that's kinda why I disliked how InitramfsRunModeSelectSnapsToMount is working where it just creates the objects and calls a method on them and kinda forgoes all the rest of the stuff in that file
<ijohnson> but meh
<stgraber> zyga: I'm adding a tweak to our apparmor policy to prevent mounting cgroup2 if host doesn't have it, so we'll avoid that kind of issue for now
<pedronis> ijohnson: now I'm very tempted to try to see if what I have in mind is smaller or not overall (it might not be, which again would make it a bit meh)
<ijohnson> pedronis: I mean hey go for it if you want, feels a bit superfluous right now but it is fun to try and write simple elegant code sometimes :-D
<pedronis> ijohnson: are you blocked on something from me?
<ijohnson> pedronis: if you wanted to review the last commit on my cross check PR that is a draft that would be nice, but that is blocked on systemd-mount PR, which is then blocked on x n o x
<ijohnson> pedronis: that would be https://github.com/snapcore/snapd/pull/9081/commits/147e3058ed55ff88e2c3aae0b598b346b6af5576
<mup> PR #9081:  secboot,cmd/snap-bootstrap: cross-check partitions before unlocking, mounting <UC20> <â Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9081>
<pedronis> ijohnson: that last commit says it's +1711 ?
<ijohnson> pedronis: no github is silly, that diff line is for the whole PR I'm pretty sure
<ijohnson> which contains all the systemd-mount PR
<ijohnson> pedronis: git says ` 7 files changed, 424 insertions(+), 96 deletions(-)`
<pedronis> yea, that seems more reasonable
<mup> PR snapd#9135 closed: boot: move bootloaderKernelState20 impls to separate file <Simple ð> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9135>
<ijohnson> thanks
<pedronis> ijohnson: I did a quick pass there, some comments/questions
<ijohnson> thanks
<pedronis> ijohnson: so I tried, it gains 30 lines, not sure it's clearer or not, the cost is a new interface. There's probably a bit more that can be tried in initramfs.go
<ijohnson> pedronis: mmm interesting, but yes there's a lot more that can be done in initramfs.go
<ijohnson> I need to go to the bank
 * ijohnson afk for hour or two
<mup> PR snapd#9137 opened: boot: refactor such that bootStateUpdate20 mainly carries Modeenv <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9137>
<cmatsuoka> ijohnson: do you see a reason for uc20 installation to be failing on sd (on the nuc, not pi)?
<ijohnson> cmatsuoka: by "sd" do you mean like /dev/sda or like an actual SD card
<cmatsuoka> ijohnson: I always installed to internal storage on real pc hardware, it never occured to me to boot the image and install on external media
<cmatsuoka> ijohnson: sd card
<cmatsuoka> ijohnson: like a giant raspberry pi
<ijohnson> Hypothetically it should work
<ijohnson> Did you find an issue with that setup?
<cmatsuoka> yes, I think it should too, but that's the scenario that doesn't work for galem
<mup> PR snapd#9138 opened: many: refactor tpm seal parameter setting <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9138>
<mup> PR snapcraft#3244 opened: file utils: introduce get_host_tool_path() to find commands on host <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3244>
#snappy 2020-08-12
<mup> PR snapd#9139 opened: interfaces/many: miscellaneous updates for strict microk8s <Created by jdstrand> <https://github.com/snapcore/snapd/pull/9139>
<mup> PR snapd#9140 opened: vendor: update github.com/kr/pretty to fix diffs of values with pointer cycles <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/9140>
<mborzecki> morning
<mborzecki> mvo: hey
<mvo> good morning mborzecki
<mborzecki> hm the forum gained a canonical branded bar at the top of the page
<oerheks> and a roll down 'products' button, nice
 * mvo hugs jamesh for pr9140
<jamesh> :-) Having tests that don't hang when they fail is nice
<mvo> jamesh: +100 for that
<mup> PR snapd#9140 closed: vendor: update github.com/kr/pretty to fix diffs of values with pointer cycles <Simple ð> <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9140>
<pstolowski> morning
<mvo> good morning pstolowski
<mvo> pstolowski: great news, the PR for kr/pretty that prevents circular data structure hangs got merged upstream and james did a PR to update our vendor.json
<pstolowski> mvo: whaaaaat? unbelievable
<pstolowski> that's great
<mvo> pstolowski: yeah :)
<mvo> pstolowski: https://github.com/kr/pretty/pull/64
<mup> PR kr/pretty#64: diff: detect cycles in the values being compared <Created by jhenstridge> <Merged by kr> <https://github.com/kr/pretty/pull/64>
<pstolowski> kinda annoying my PR was hanging that for 1,5y with no traction, oh well
<jamesh> pstolowski: I hadn't seen yours when I wrote mine
<pstolowski> jamesh: no worries, good it's fixed
<jamesh> I noticed the maintainer had merged something at end of July, so pinged him in my PR and got lucky.
<mvo> slightly sad that we had to duplicate some work but the outcome is really good, this bug was super annoying in the past. I'm very happy
<pstolowski> yes
<jamesh> my version also detects if you have different structure to the cycles in the two values being compared too
<jamesh> e.g. A->A compares different to A->B->A
<pstolowski> jamesh: ah, nice
<zyga> good morning
<zyga> mvo could you please advise on https://github.com/snapcore/snapd/pull/9125
<mup> PR #9125: tests: fix issues related to restarting systemd-logind.service <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9125>
<zyga> it makes master much more gree
<zyga> *green
<zyga> and it is green itself
<zyga> there are two separate fixes there
<zyga> I can open two new PRs that won't be green but we can review separately and force-merge
<zyga> or I can do something else, up to you
<mvo> zyga: new ones are fine
<zyga> mvo ack, I'll make that happen
<zyga-mbp> the first fix is https://github.com/snapcore/snapd/pull/9141
<mup> PR #9141: tests: cope with ghost cgroupv2 <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9141>
<zyga-mbp> mborzecki ^ mvo ^ (it will require force merging)
<zyga-mbp> this is a low-priority fix https://github.com/snapcore/snapd/pull/9142
<mup> PR #9142: sandbox/cgroup: detect dangling v2 cgroup <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/9142>
<mup> PR snapd#9141 opened: tests: cope with ghost cgroupv2 <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9141>
<mup> PR snapd#9142 opened: sandbox/cgroup: detect dangling v2 cgroup <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/9142>
<mvo> zyga-mbp: looking now
<mvo> zyga-mbp: 9125 is still marked as draft, should that get promoted
<zyga-mbp> not yet, I'm removing those commits and adding one more there
<zyga-mbp> I'll open it in a moment
<zyga-mbp> mvo https://github.com/snapcore/snapd/pull/9125 is now force-pushed to remove the commits split out to the two new branches
<mup> PR #9125: tests: fix issues related to restarting systemd-logind.service <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9125>
<zyga-mbp> and is now open
<mvo> zyga-mbp: one comment, thanks for this one
<mvo> zyga-mbp: also remarkable complicated :(
<mvo> zyga-mbp: again, thanks for diving so deep
<zyga-mbp> looking
<zyga-mbp> mvo which comment should I look like?
<zyga-mbp> look at
<zyga-mbp> sorry
<zyga-mbp> I EODd late last night, should make 2nd coffee
<zyga-mbp> I will make coffee and review https://github.com/snapcore/snapd/pull/8960
<mup> PR #8960: o/snapstate,servicestate: use service-control task for service actions (9/9) <Needs Samuele review> <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8960>
<zyga-mbp> back with freshly ground coffee :)
<zyga-mbp> and into the review from pawel
<shuduo> hi, i'm working on to package a cmake-based project to snap format. I refer mosquitto since they are similar since need both daemon and utils. mosquitto works well. but mine does not. I see snapcraft do not put file cmake built to stage and prime. I guess the CMakeLists.txt are something non-standard style. but I wonder if there is a way to workaround. thanks.
<zyga> shuduo I'd ask this question in #snapcraft in a few hours
<shuduo> zyga, or i ask there?
<zyga> yeah, ask there but wait for a few hours till the developers are all there
<shuduo> OK
<shuduo> thanks
<pedronis> zyga: do we still need #9125 with #9141 ? or do we need both?
<mup> PR #9125: tests: fix issues related to restarting systemd-logind.service <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9125>
<mup> PR #9141: tests: cope with ghost cgroupv2 <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9141>
<zyga> pedronis we need both, I separated them for review per mvo's advice
<pedronis> zyga: I'm not talking about #9142
<mup> PR #9142: sandbox/cgroup: detect dangling v2 cgroup <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/9142>
<zyga> yes, we should get all three but 9142 is less important - we are immune by lucky coincidence
<mup> PR snapd#9136 closed: bootstate20: rm bootState20Modeenv, pass around modeenv directly <Cleanup :broom:> <â Blocked> <Created by anonymouse64> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/9136>
<zyga> so 9142 can land later
<pedronis> ok
<mup> PR snapd#9134 closed: boot, o/devicestate: TrustedAssetUpdateObserver stubs, hook up to gadget updates <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9134>
<zyga> https://github.com/snapcore/snapd/pull/9141 needs a 2nd review and force-merge
<mup> PR #9141: tests: cope with ghost cgroupv2 <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9141>
<zyga> so does https://github.com/snapcore/snapd/pull/9125
<mup> PR #9125: tests: fix issues related to restarting systemd-logind.service <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9125>
<zyga> mborzecki, pstolowski: ^ if you have a moment
<ijohnson> morning folks
<pedronis> mvo: a remark about "snap recovery", it seems to produce errors like this:  error: cannot list recovery systems: cannot list recovery systems: access denied
<pedronis> we should find out what's the nesting cause, and remove it
<mvo> pedronis: uh, I will add a test, thanks for noticing
<pedronis> I don't know if one comes from snapd and one from the client or something else
<zyga> brb
<mvo> zyga: hey, with your systemd experience, how do you feel about changing our written mount units to have "[Install]\nWantedBy=local-fs.target" ?
<zyga> hmmmm, I don't know yet
<zyga> let me think and check and get back to you
<mvo> no worries
<pedronis> mvo: also a comment about "snap reboot" and related: https://github.com/snapcore/snapd/pull/9021#issuecomment-672783319
<mup> PR #9021: snap: implement new `snap reboot` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/9021>
<mvo> pedronis: thanks
<mup> PR snapd#9143 opened: snap: fix repeated "cannot list recovery system" and add test <Created by mvo5> <https://github.com/snapcore/snapd/pull/9143>
<pedronis> mvo: should we close #9110 ?
<mup> PR #9110: preseed: cherry-pick #8704, #8709, #9088 (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/9110>
<mvo> pedronis: yes, let me do that
<mup> PR snapd#9110 closed: preseed: cherry-pick #8704, #8709, #9088 (2.45) <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/9110>
<ijohnson> zyga: did you take a look at the arch failure on #9125 ? very odd
<mup> PR #9125: tests: fix issues related to restarting systemd-logind.service <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9125>
<zyga> ijohnson I did not yet
<zyga> looking
<ijohnson> but I just re+1'd that PR for you
<ijohnson> would be great to sudo land that
<zyga> yeah
<zyga> checking log now
<ijohnson> I saved it here anyways https://pastebin.ubuntu.com/p/QZBFr9QshT/
<ijohnson> I can't reproduce on ubuntu, but I've also never seen this test fail before
<zyga> hmm
<zyga> my first hunch was enoent -> it didn't mount
<zyga> it's not the dynamic linker for sure
<zyga> but it's mounted
<zyga> there are a few other things we run that would fail this way
<zyga> too bad it doesn't say _which_ exec fail
<zyga> *failed
<zyga> let me look at the source quickly
<zyga> god this 16" is so much better than the x240
<zyga> almost comfortable in bed
<zyga> damn, that's snap-exec
<zyga> snap-confine failed to execute snap-exec
<ijohnson> oh weird
<ijohnson> how could that happen
<zyga> no idea yet
<zyga> actually
<zyga> all snaps are mounted
<zyga> so no, no idea
<zyga> mvo could you please force-merge https://github.com/snapcore/snapd/pull/9125
<mup> PR #9125: tests: fix issues related to restarting systemd-logind.service <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9125>
<zyga> https://github.com/snapcore/snapd/pull/9141 needs a 2nd review
<mup> PR #9141: tests: cope with ghost cgroupv2 <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9141>
<mvo> zyga: sure
<zyga> and we should be back on our feet
<zyga> thank you
<mup> PR snapd#9125 closed: tests: fix issues related to restarting systemd-logind.service <Test Robustness> <â  Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9125>
<cachio> zyga, hi
<zyga> hey
<mup> PR snapcraft#3245 opened: specifications: minor cleanup for package-repositories <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3245>
<cachio> zyga, did you see the message I left in the standaup doc=
<zyga> yes, but I did not investigate yet
<cachio> nice, thnaks
<cachio> I'll investigate a bit now
<zyga> cachio it may go away with the fixes that are incoming
<zyga> the one that just landed
<zyga> I don't have spread2 around, can you pull master and see if it happens now?
<cachio> zyga, sure
<zyga> thank you
<zyga> I need a moment, back in 30
<cachio> zyga, it passed now
<mup> PR snapd#9144 opened: bootloader: add helper for creating a bootloader based on gadget <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9144>
<mborzecki> pedronis: ^^
<zyga> cachio I think the fix for linger affected it
<zyga> as that test - the failure cgroup one, otherwise nuked systemd --user for root
<cachio> zyga, good to know, thanks for that!!
<ijohnson> cachio: sorry I don't think I followed up but do we have a problem with the uc20-recovery test ?
<cachio> ijohnson, sorry, yes, it failed yesterday on the  pi3 when I did beta validation for 2.46
<ijohnson> cachio: do you have logs?
<cachio> and then the debug is showing the same problem than before
<cachio> ijohnson, yes, 1 sec
<ijohnson> thanks
<zyga> mvo could you please merge https://github.com/snapcore/snapd/pull/9141
<mup> PR #9141: tests: cope with ghost cgroupv2 <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9141>
<zyga> we should be good now
<ijohnson> nice good work zyga!
<zyga> we can start restarting tests, just a few at first, to see where we are
<zyga> nothing like bad red master to spoil monday
<zyga> it's Wed so let's just keep pushing now
<pedronis> mborzecki: reviewed #9144
<mup> PR #9144: bootloader: add helper for creating a bootloader based on gadget <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9144>
<mup> PR snapcraft#3242 closed: tests: migrate legacy classic patchelf tests to spread <enhancement> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3242>
<cachio> ijohnson, https://paste.ubuntu.com/p/kXWV6tQDcN/
<ijohnson> thanks cachio I'll have a look
<cachio> tx
<mborzecki> pedronis: btw. if you want to look, i've made the changes for install boot config right here: https://github.com/bboozzoo/snapd/commit/9b684dfadba34afd7199891ba8bfe0d6ec56b1d6 mostly works, there's one case for uboot that ijohnson probably knows more about
 * ijohnson goes to go hide from uboot bootloader details
<ijohnson> cachio: ah very interesting
<ijohnson> cachio: so part of what happened is that we failed to finish seeding in recover mode there
<ijohnson> cachio: then we hit that rather weird/interesting bug with the recursive bind mount output from findmnt which broke cwayne's server
<pedronis> mborzecki: if I remember that should be fine, is some test failing?
<pedronis> the logic checks for .conf in any case, there is just differen behavior if .conf is empty
<pedronis> vs not
<pedronis> for uboot
<cachio> ijohnson, yes
<cachio> ijohnson, I think it is not breaking the server anymore
<ijohnson> that's nice
<cachio> because now I see that the output at some point is cut
<cachio> so they implemented something in their side for that
<mup> PR snapd#9141 closed: tests: cope with ghost cgroupv2 <Test Robustness> <â  Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9141>
<zyga> thank you
<mup> PR snapcraft#3246 opened: plugins v2: quote python packages argument for pip <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3246>
<mup> PR snapcraft#3245 closed: specifications: minor cleanup for package-repositories <specification> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3245>
<zyga> hmm
<zyga> + test-snapd-busybox-static.busybox-static echo hello
<zyga> execv failed: No such file or directory
<zyga> grep error: pattern not found, got:
<zyga> this failed again
<zyga> mborzecki does test-snapd-busybox-static work for you on arch?
<mborzecki> zyga: i have a fix, just a sec
<zyga> oh even better
<zyga> thanks
<ijohnson> ah so that is a real issue
<mup> PR snapd#9145 opened: boot: track trusted assets during initial install, assets cache  <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9145>
<mup> PR snapd#9146 opened: packaging/arch: use external linker when building statically <Simple ð> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9146>
<ijohnson> mborzecki: ^ is needed to make master all green again right ?
<ijohnson> arch is required and that test is always failing right ?
<mborzecki> ijohnson: yes
<zyga> thanks
<mborzecki> got to go for now
<zyga> not fun
<zyga> thank you
<pedronis> pstolowski: some comments in #9084
<mup> PR #9084: o/snapstate: check disk space before creating automatic snapshot on remove (3/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9084>
<pstolowski> pedronis: ty
 * cachio lunch
<ijohnson> cachio: does that uc20-recovery issue happen reliably such that I could reproduce it with a live rpi3 ?
<mup> PR core#117 opened: extrafiles/writable-paths: make /etc/default/crda writable <Created by anonymouse64> <https://github.com/snapcore/core/pull/117>
<mup> PR snapd#9146 closed: packaging/arch: use external linker when building statically <Simple ð> <Test Robustness> <â  Critical> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9146>
<ijohnson> pedronis: so I'm looking right now at transitioning from recover to run automatically via any reboot, and we currently detect in devicestate Manager that we are in recover mode via the modeenv, but regardless of how we set that up, at a minimum we need to set bootenv, but we will also need to set the modeenv too
<ijohnson> the issue is that we use the modeenv to determine what mode we are in from devicestate
<ijohnson> so I'm thinking that a pre-req to this is to have devicestate decide what mode it is in by 1) just presence of a modeenv file, and 2) decide what mode via kernel command line
<pedronis> ijohnson: why that? for ephemeral mode the modeenv is ephemeral
<ijohnson> oh wait
<pedronis> I'm probably missing something
<pedronis> the run mode modeenv has always run in it
<pedronis> if that's not the case we have a bug
<ijohnson> ok, but even if it's ephemeral/tmpfs modeenv, we still write it as "mode=recover" from the initramfs there
<ijohnson> ah but nevermind the modeenv doesn't matter
<ijohnson> nvm me the bootenv is all we care about
<pedronis> yes, but those modeenv go away each time
<ijohnson> yes yes yes I had just confused myself
<ijohnson> all makes sense now
<pedronis> it's ok, I was worried we had a bug
<ijohnson> well fear not we do have a bug ... points at bugs.launchpad.net/snapd :-D
<ijohnson> just not in this particular area
<cachio> ijohnson, I could reproduce it twice
<ijohnson> cachio: ack I will try to reproduce it myself with a debug shell I can poke around with
<cachio> not sure if 100% of the times
<cachio> nice
<cachio> ijohnson, this is theimage
<cachio> ijohnson, https://storage.googleapis.com/spread-snapd-tests/images/pi3-20-beta/pi.img.xz
<ijohnson> cachio: nice thanks, do you use tf or do you flash it to your local pi3 ?
<cachio> ijohnson, sudo dd if=<PAT_TO_IMG> of=/dev/mmcblk0 bs=4M oflag=sync status=noxfer
<ijohnson> thanks cachio
<cachio> ijohnson, yaw
<pedronis> ijohnson: you should try to look #9145 if possible, I looked at it, I think it's mostly good, but there are some implicit assumptions that I find a bit confusing (especially they way they might or not affect the update case)
<mup> PR #9145: boot: track trusted assets during initial install, assets cache  <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9145>
<ijohnson> pedronis: sure
<pedronis> thx
<ijohnson> pedronis: have you seen https://forum.snapcraft.io/t/module-blacklisting-interface/19171 or is it on your queue ?
<pedronis> I can put it on my queue, but I will not get to it for a while
<ijohnson> pedronis: that's fine, just wondering if you had it on your queue already
<mup> PR core18#155 closed: hooks: fix broken symlink /etc/sysctl.conf.d/99-sysctl.conf <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/155>
<mup> PR snapcraft#3240 closed: cli: only issue warning when checking for usage of sudo  <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3240>
<mup> PR snapd#9086 closed: many: reorg cmd/snapinfo.go into snap and new client/clientutil <Cleanup :broom:> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9086>
<zyga> re
 * zyga jumps into customer bug analysis
<mvo> mountedfilesystemwriter tests are happy with the new resolvedSrc stuff I'm working on, yay
<zyga> mvo I won't make the morning desktop call tomorrow, I had to move my rehab from Friday to Thursday 9:00 AM
<mup> PR snapcraft#3232 closed: build providers: install apt-transport-https <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3232>
<mvo> zyga: ok
<mvo> zyga: I think you mean physio?
<zyga> I really don't know how it is translated
<zyga> :D
<zyga> I think 'rehabilitation' is also valid but I could be wrong
<zyga> it's not the kind of rehab where rich people try not to kill themselves with alcohol and drugs
<mvo> zyga: I'm probably wrong (no native speaker etc) but when I hear rehab I usually think of alcohl or something like this
<mvo> zyga: maybe some native speaker can enlighten us :)
<mvo> zyga: anyway I know what you mean
<zyga> it's the kind where they teach you to slowly make progress and get back to shape
<zyga> plus a lot of the time is actually spent on the scar itself, weird but supposedly important so that it doesn't hurt later
<zyga> aaaanyw
<zyga> I can show you my scar but it's in the same spot like before, just colored differently, guess that's a poor luck in body scar trophy ;)
<zyga> hmm
<zyga> Aug 12 14:32:53 localhost snapd[1507]: udevmon.go:149: udev event error: Unable to parse uevent, err: cannot parse libudev event: invalid env data
<zyga> we may need to update our udev go code
<zyga> and improve error handling so that we can at least get a dump of the event in hex
<zyga> ijohnson ^ how would you describe what we were talking about above?
<zyga> (which word would you use?)
<mup> PR snapd#9147 opened: [RFC] Support for gadget.yaml "$kernel:" style references (2/N) <Created by mvo5> <https://github.com/snapcore/snapd/pull/9147>
<ijohnson> zyga: sorry I lost some context
<zyga> ijohnson no worries, not important, just wondering how to say something in english
<ijohnson> Oh you mean the appointment you have?
<zyga> is "rehabilitation" understood as more than avoiding booze/drugs?
<zyga> yes
<zyga> like special exercises to get back to basic mobility
<ijohnson> In th US we would call it "physical therapy" or just PT
<zyga> aaah
<zyga> thanks,
<zyga> PT it is
<zyga> though I'm sure Graham would call it something else ;-)
<ijohnson> But that's just for recovering back to where you were if it's like something from birth or a long standing thing you do for a really long time then we call it "occupational therapy"
<ijohnson> zyga haha yeah that's why I prefaced with "in the US"
<zyga> ah, more terms I never used before
<zyga> I wonder how brits call that actually
<zyga> it's such a cool aspect of our work that we have all those people from different places in one team :)
<mvo> zyga: we call it physio
<mvo> ijohnson: I was wondering if "going to rehab" would be somethign that is more about drugs or more about physio
<mvo> ijohnson: this is how this started
<mvo> ijohnson: anyway, not *really* important :)
<zyga> back to musl
<ijohnson> mvo yeah rehab usually has that connotation in casual usage but I've heard it used in medical setting as well but it's less common than calling it physical therapy
<mvo> thanks!
 * mvo feels smarter now :)
<ijohnson> np I agree with zyga it's really interesting to see how these things are called around the world
<mvo> ijohnson: totally!
<mvo> I think I call it a day, one more small victor on kernel-dtb, now I quickly need to call it a day before I see spread failures
 * mvo waves
<zyga> o/
 * cachio -> kinesiologist
<ijohnson> cachio: aroud ?
<ijohnson> *around
<cachio> ijohnson, yes
<ijohnson> cachio: what is the command to setup an external system so I can use it with spread ?
<ijohnson> something from nested.sh I seem to remember...
<cachio> you need to create the users?
<cachio> or the env var to set ?
<ijohnson> I have a rpi3 I want to run the external uc20 recovery test with
<cachio> ok, in that case
<cachio> you need
<ijohnson> (and I have a locally created user)
<cachio> ./tests/lib/external/prepare-ssh.sh <ip> 22 <your-lp-user>
<cachio> this will create the users
<cachio> then
<cachio> export SPREAD_EXTERNAL_ADDRESS=<IP>
<ijohnson> awesome thanks
<cachio> then spread external:ubuntu-core-20-arm-32:tests/core/uc20-recovery
<cachio> ijohnson, yaw
<ijohnson> cachio: btw whatever happened to the tf backend for spread ?
<ijohnson> was that completed but never merged ?
<cachio> ijohnson, needs reviews
<cachio> and approval
<ijohnson> cachio: I see, would be good if we could get that in sometime soon
<cachio> I already asked for reviewes and approval
<mup> PR snapcraft#3246 closed: plugins v2: quote python packages argument for pip <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3246>
<ijohnson> cachio: I reproduced the failure with the rpi3 I am using, investigating now
<ijohnson> interestingly, our new `snap debug seeding` returns `seed-completion:  3195h26m10.26s` on this system hehe
<cachio> ijohnson, nice
<cachio> hehe
<cachio> the customers wont be happy waiting that time
<ijohnson> haha no I don't think so
<ijohnson> I think I have an idea what's going on here
<ijohnson> this happens specifically on the pi where we don't have a real time clock
<cachio> ijohnson, in pi4 didn't fail
<ijohnson> cachio: right because pi3 runs slower than pi4
<cachio> is it the same case?
<cachio> ijohnson, ahh
<ijohnson> cachio: no, pi4 is faster
<cachio> makes sense
<mup> PR snapd#8942 closed: tests: support different images on nested execution <Run nested> <Squash-merge> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8942>
<cachio> vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv88888888888888888
#snappy 2020-08-13
<Elladan> I installed a snap named "arduino" on Mint 19.3, and when I start it it just crashes with: "java.lang.UnsatisfiedLinkError: /snap/arduino/41/usr/lib/jvm/java-11-openjdk-amd64/lib/libsplashscreen.so: libX11.so.6: cannot open shared object file: No such file or directory"
<Elladan> Another snap I have installed using X11 works fine.
<jamesh> Elladan: The "snap info" output for that snap suggests reporting problems at https://github.com/snapcrafters/arduino/issues
<jamesh> I haven't used that snap, so don't have much more to suggest.
<oerheks> howcome you could install snaps on mint?
<oerheks> they blocked that in a funny way
<jamesh> oerheks: they replaced some "deb to snap" transition packages in their archive overlay.  I don't think they've done anything to actively break snap support if you install it
<jamesh> unless there's something else new.
<oerheks> They introduced this etc/apt/preferences.d/nosnap.pref file
<jamesh> Ah.  I missed that.
<jamesh> Presumably if the user managed to install a snap, then they would have got past that setting though.
<oerheks> first remove that blob, then you could install snapd,
<mborzecki> morning
<mup> PR snapd#9144 closed: bootloader: add helper for creating a bootloader based on gadget <Squash-merge> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9144>
<mborzecki> mvo: hey
<mborzecki> omg, forgot about squash merge label i added myself
<mvo> mborzecki: good morning
<mborzecki> mvo: we're not doing $kernel after all?
<mup> PR snapd#9130 closed: [RFC] Support for gadget.yaml "$kernel:" style references (1/N) <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/9130>
<mup> PR snapd#9142 closed: sandbox/cgroup: detect dangling v2 cgroup <Bug> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9142>
<mup> PR snapd#9147 closed: [RFC] Support for gadget.yaml "$kernel:" style references (2/N) <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/9147>
<mup> PR snapd#9148 opened: gadget: add new Kernel{Info,Asset} struct and helpers <Created by mvo5> <https://github.com/snapcore/snapd/pull/9148>
<mborzecki> pstolowski: hey
<mvo> good morning pstolowski
<pstolowski> morning o/
<mborzecki> pedronis: hey, thanks for the feedback
<mborzecki> pedronis: i've updated #9145
<mup> PR #9145: boot: track trusted assets during initial install, assets cache  <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9145>
<pedronis> mborzecki: thx, I will look in a little bit (was in meetings)
<mborzecki> pedronis: sure, let me know if we should have a chat as well
 * mborzecki goes looking for a copy-tree helper
<mborzecki> zyga is coming back and should be online in a bit
<zyga-mbp> what a day
<zyga-mbp> mvo I will file half day off,
<zyga-mbp> there was a leak at my parent's flat, someone upstairs from them had a broken pipe or something
<zyga-mbp> I need to spend a moment to file the insurance claim
<zyga-mbp> I'll be back around noon
<mvo> zyga-mbp: ok
<zyga-mbp> how is master? are we green?
<mborzecki> zyga-mbp: yeah, the PRs i restarted today were green
<mborzecki> (as in all green)
<zyga-mbp> super-green :)
<mup> PR snapd#9129 closed: sandbox/cgroup: remove temporary workaround for multiple cgroup writers <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/9129>
<mborzecki> zyga-mbp: #28a745 green
<mup> PR #28: Updated import path, closes #27 <Created by fgimenez> <Merged by elopio> <https://github.com/snapcore/snapd/pull/28>
<zyga-mbp> "super green" is a quote, from, I think, the 5th element
<mborzecki> hm now that you reminded me, i'd love to watch it again
<zyga-mbp> ok , paperwork ready
<zyga-mbp> eh
<zyga-mbp> let's focus on work now
<mup> PR snapd#9118 closed: tests: detect unexpected xenial kernels <Test Robustness> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/9118>
<pedronis> mborzecki: do we need to discuss something?
<mborzecki> pedronis: idk, do you want to go over the PR maybe?
<mborzecki> pedronis: otherwise we're good i suppose
<mborzecki> pedronis: btw. we haven't discussed it, but we should probably add boot.SealWithModeenv() or similar at some point
<pedronis> mborzecki: I'm sure I have mentioned it many times
<pedronis> without a name yet
<mup> PR snapd#9149 opened: [RFC] gadget: provide new gadget.ResolveContentPaths() (2/N) <Created by mvo5> <https://github.com/snapcore/snapd/pull/9149>
<pedronis> Isaid we need functions that seal/reseal based on a modeenv (or at least to start a function that takes a modeenv and produces sealing params)
<mborzecki> pedronis: ok, i'll add a stub when i open the bits with content update observer
<pedronis> mborzecki: please coord with Claudio on this
<mborzecki> pedronis: yup, will do
<pedronis> mborzecki: a few more comments
<mvo> mborzecki, pedronis I'm moving kernel.yaml reading into the kernel package now, but one open question is the edition, it's private to gadget right now, so I would either need to copy or extract it
<mvo> mborzecki, pedronis (the edition datastructure) - any recommendations for this?
<pedronis> mvo: gadget will to import kernel, right?
<mvo> pedronis: yes
<pedronis> *will have to
<pedronis> mvo: it's annoying, but I recommend making a tiny gadget/edition package
<pedronis> with edition.Number
<mvo> pedronis: works for me, thanks
<mborzecki> or maybe we could move editionNumber to snap?
<pedronis> not unless we use for a 3rd thing
<mborzecki> fair enough
<pedronis> I see the appeal, but snap is already full of things
<pedronis> and snap/edition is not better than gadget/edition
<mborzecki> missing a kitchen sink ;)
<zyga-mbp> mborzecki snap/mime and we're close to sending email
<mup> PR snapd#9148 closed: gadget: add new Kernel{Info,Asset} struct and helpers <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/9148>
<mvo> pedronis, mborzecki updated the kernel yaml stuff in 9150, sorry I got confused by GH
<mup> PR snapd#9150 opened: gadget,kernel: add new kernel.{Info,Asset} struct and helpers <Created by mvo5> <https://github.com/snapcore/snapd/pull/9150>
<zyga> brb
<mborzecki> pedronis: hm, i think we've forgotten to support a forced bootloader in ForGadget, anyways we can remedy that later
<pedronis> mborzecki: I'm sure it will be obvious when you need it :)
<zyga> most tests are red, are we in another wave of problems or are those just old?
<pedronis> I don't know if people merged master in their PR, some of michael stuff has vet/fmt problems
<pedronis> it seems some uc20 prepare are timing out
<pedronis> mborzecki: uc20 prepare is timing out here: https://github.com/snapcore/snapd/pull/9145, real problem?
<mup> PR #9145: boot: track trusted assets during initial install, assets cache  <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9145>
<mborzecki> hmmm
<mborzecki> interesting, let me check locally in a vm
<pedronis> zyga: can you point to an interesting bit of history in 7285 that you think we don't have in master atm
<zyga> pedronis: I think I can but it will take me a moment, there's a lot of discussion there and resulting patches
<pedronis> zyga: well the discussion is in the PR, not the commits
<pedronis> there's a lot of back and forth that has no footprint in master
<pedronis> at this point
<zyga> yes but the comments contain responses in code commits
<pedronis> but I'm not sure that's a bug
<mborzecki> pedronis: well, pushed mocking of for gadget bootloader too to 9145
<mborzecki> hm the core-20 spread tests don't use a tpm & secboot, do they?
<pedronis> mborzecki: not those ones
<pedronis> zyga: I found only https://github.com/snapcore/snapd/pull/7825#discussion_r411269504
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Needs security review> <Security-High> <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<mborzecki> wierd, anyways snap prepare-image is downlaoding all snaps, we'll know what's wrong in a bit
 * zyga debugs something as well
<mborzecki> pedronis: hm looks like Observe is called with a nil structure
<pedronis> interesting
<pedronis> seems some preexisting bug in gadget though?
<mup> PR snapd#9151 opened: vendor: update secboot to fix key data validation <Simple ð> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9151>
<mborzecki> pedronis: unclear, gadget unit tests assert that structure is non-nil
<pedronis> some weird case of := vs =
<pedronis> that's a way to get nil where you don't expect one staring at the code
<cmatsuoka> mborzecki: did an impossible situation happen in tests?
<pedronis> mborzecki: the other option is something wrapping a nil into an interface, and the thing going past != nil
<mborzecki> hm actually it's more intersting
<mborzecki> observer is nil
<pedronis> ah
<mborzecki> func (o *TrustedAssetsInstallObserver) Observe(op gadget.ContentOperation, affectedStruct *gadget.LaidOutStructure, root, realSource, relativeTarget string) (bool, error) <- so o is nil
<mborzecki> but it's called from a place where it's not nil
<pedronis> well, see my comment about wrapping nils into interfaces
<pedronis> that might be one reason
<pedronis> mborzecki: ah, yes
<pedronis> fun
<ijohnson> morning folks
<cmatsuoka> hey ijohnson
<mborzecki> ijohnson: hey
<ijohnson> hey cmatsuoka mborzecki
<pedronis> mborzecki: the issue is probably the signature of TrustedAssetsInstallObserverForModel
<pedronis> you probably take that and cast implicitly to an interface
<pedronis> that doesn't give you a nil for the interface
<pedronis> mborzecki: does this make sense?
<ijohnson> pedronis: regarding making recover -> run mode automatic via a reboot, I got the initramfs method working easily ... if I base the changes on top of my other 2 initramfs PR's (systemd-mount and cross-check) the test diff is small, otherwise there are a number of conflicts I'd rather not resolve (but could if needed)
<pedronis> ijohnson: yes, I saw your notes, let's chat at the standup
<ijohnson> pedronis: I am going to take a quick stab at the ensure devicemgr method we discussed now to see how much work that is
<ijohnson> pedronis: ack
<mborzecki> pedronis: yes, most likely, https://play.golang.org/p/UWyducWpRj7
<mborzecki> missing test case in handlers_install too
<pedronis> yes
<pedronis> function returning nil for structs are dangerous
<pedronis> mborzecki: I'm happy to chat about how to clean this up, I think both me and mvo made some comments about those functions originally
<mborzecki> pedronis: and the unit tests check for NotNil with an interface
<zyga> huh
<mborzecki> pedronis: i'm open to suggestions, a chat?
<pedronis> mborzecki: yes
<mup> PR snapd#9152 opened: cmd/snapd-generator: generate drop-in to use fuse in container <Needs Samuele review> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9152>
<cachio> zyga, to reproduce the error you can use this image https://storage.googleapis.com/spread-snapd-tests/images/pc-amd64-16-beta/pc.img.xz
<zyga-mbp> cachio sorry, which error?
<cachio> zyga-mbp, the reloading with --user
<zyga-mbp> I see
<zyga-mbp> do you know which commit corresponds to that?
<zyga-mbp> I don't need to look at the image, more at the history
<zyga-mbp> we can look at the image once we know where it is anchored
<cachio> I am running eith the branch for beta
<cachio> 2.46
<zyga-mbp> ok, I'll check
<zyga-mbp> it probably doesn't have the fixes then
<zyga-mbp> so unlucky fork
 * pstolowski lunch
<pedronis> zyga-mbp: if you can update the description of #7825 with something that hints at the journey and then ping me
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Needs security review> <Security-High> <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> pedronis: sure
<ijohnson> zyga: so what I was trying to say in the SU is that I don't think the extra info from mount helps because if the fsck fails or the mount fails, it shows up the same to us when we run `systemd-mount`
<zyga> pedronis: I need to prepare for another call so likely in the evening or tomorrow
<zyga> ijohnson: I see
<ijohnson> i.e. systemd-mount doesn't tell us how things fail it just says that the unit failed
<ijohnson> and then we have to go on digging to find out what failed
<mborzecki> ijohnson: what if we start the fsck unit ourselves?
<ijohnson> mborzecki: yes we could do this
<mborzecki> pedronis: https://github.com/snapcore/snapd/pull/9153
<mup> PR #9153: overlord/devicestate: workaround non-nil interface with nil struct <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9153>
<mup> PR snapd#9153 opened: overlord/devicestate: workaround non-nil interface with nil struct <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9153>
 * zyga breaks for lunch
<mborzecki> hmm should have skipped spread there
 * zyga waits for food to heat so https://github.com/snapcore/snapd/pull/9154
<mup> PR #9154: tests: unmount FUSE file-systems from XDG runtime dir <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/9154>
<mup> PR snapd#9154 opened: tests: unmount FUSE file-systems from XDG runtime dir <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/9154>
<mborzecki> ijohnson: can you take a look at https://github.com/snapcore/snapd/pull/9153 ?
<mup> PR #9153: overlord/devicestate: workaround non-nil interface with nil struct <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9153>
<ijohnson> mborzecki: yes
<mborzecki> ijohnson: thanks!
<mvo> ijohnson: I just did
<mvo> mborzecki: just had a look
<mborzecki> mvo: ijohnson: thanks!
<mvo> mborzecki: I will merge once spread is done
<mborzecki> cmatsuoka: thanks too!
<ijohnson> haha wow 3 reviews in under a minute
<mborzecki> haha
<ijohnson> mborzecki's code is real popular
<mvo> woah
<cmatsuoka> :)
<mvo> what a shinny PR :)
<ijohnson> #8931 could use a review too and is a test-only fully green 31 line change :-)
<mup> PR #8931: tests/main/install-fontconfig-cache-gen: enhance test by verifying, add fonts to test <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8931>
<mvo> ijohnson: sure, looking
<mvo> ijohnson: sorry, somehow missed this one (or rather missed that I can review it again)
<ijohnson> no worries
 * cachio lunch
<ijohnson> thanks mvo
<mborzecki> hmm all jobs are queued?
<mborzecki> nothing in progress here https://github.com/snapcore/snapd/actions?query=is%3Ain_progress
<zyga-mbp> mborzecki looking
<zyga-mbp> mborzecki we're executing 32 spread runs now
<zyga-mbp> it's a message queue, perhaps under load and out of date
<zyga-mbp> we're definitely not idle
<mborzecki> hm maybe
<zyga-mbp> actually some more as I run 4 more locally for extra safety in case one node goes down
<zyga-mbp> oh
<zyga-mbp> cmatsuoka I found that doc about actions
<cmatsuoka> zyga-mbp: ah nice, please share if you can
<zyga-mbp> done
<cmatsuoka> thanks!
<zyga-mbp> I'm happy to talk if you want to set it up
<mup> PR snapd#9017 closed: o/snapstate: disk space check in Ensure (5/N) <Disk space awareness> <Needs Samuele review> <â Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/9017>
<zyga> Err:125 http://us-east1.gce.archive.ubuntu.com/ubuntu groovy/main amd64 libio-pty-perl amd64 1:1.12-1
<zyga>   Temporary failure resolving 'us-east1.gce.archive.ubuntu.com'
<mup> PR snapcraft#3247 opened: spread tests: fix classic patchelf linker regex to match all arches <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3247>
<mvo> zyga: if you could look at 9152 too that would be great, I think system() is fine here but I would love someone that is not me to come to the same conclusion :)
<zyga> sure
<zyga> looking
<mvo> pstolowski: some interssting points in the generator PR from dimitri
<mvo> zyga: thank you!
<pstolowski> mvo: yes, just looking
<mvo> pstolowski: \o/
<mborzecki> meh, i'll grow more grey hair waiting for 9153 spread jobs to finish
<mborzecki> it's looking good though, so bbiab
<zyga> reviewed https://github.com/snapcore/snapd/pull/9152#pullrequestreview-466913663
<mup> PR #9152: cmd/snapd-generator: generate drop-in to use fuse in container <Bug> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9152>
<mup> PR snapd#9153 closed: overlord/devicestate: workaround non-nil interface with nil struct <UC20> <Created by bboozzoo> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9153>
<mup> PR snapd#9154 closed: tests: unmount FUSE file-systems from XDG runtime dir <Test Robustness> <Created by zyga> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9154>
<mborzecki> yay, cmatsuoka thanks!
<ijohnson> ughhhhhh I spent like all week trying to understand why the user wasn't added to this core-initrd nested spread test, turns out the code was expecting the user1 user, but I was creating the ubuntu user
<ijohnson> ð¤¦
<mborzecki> #9145 is now unblocked
<mup> PR #9145: boot: track trusted assets during initial install, assets cache  <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9145>
<mborzecki> ijohnson: uhh, kind of reminds me of snapstate tests, fakestore and assumptions about snap names that aren't obvious
<ijohnson> mborzecki: yeah lots of copying and surgical extraction of code which has assumptions that aren't obvious makes simple things more frustrating, just glad I finally figured it out
<pedronis> ijohnson: thanks for the review, no I think adding bootState in that interface is fine
<ijohnson> pedronis: ack I can push that change up for you and add that comment
<pedronis> ijohnson: thx, that would be nice
<ijohnson> sounds good
<ijohnson> pedronis: need anything else from me before you EOD/EOW ?
<pedronis> don't think so, I'm trying to wrap (as I said) the next PR for validation sets
<ijohnson> I chatted with mvo and we will work on landing the open uc20 PR's I have then I will work on cloud-init for uc20 after those have landed as my next big uc20 thing
<pedronis> ijohnson: ok, do you need to rediscuss quickly what's the plan for that?
<ijohnson> that's not a bad idea, give me a minute to look at the doc/matrix again to refresh my memory
<pedronis> yea, I'm not sure it completely reflects what we agreed after we started fixing the bug
 * cachio afk
<ijohnson> pedronis: ok, ready when you are I can join the SU HO
<pedronis> let me join it
<mup> PR snapd#9155 opened: asserts/snapasserts: introduce ValidationSets <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9155>
<mup> PR snapd#9151 closed: vendor: update secboot to fix key data validation <Simple ð> <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9151>
<mup> PR snapcraft#3247 closed: spread tests: fix classic patchelf linker regex to match all arches <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3247>
<mup> Bug #1891564 opened: Fonts are not displayed correctly <Snappy:New> <https://launchpad.net/bugs/1891564>
<mup> Bug #1891564 changed: Fonts are not displayed correctly <Snappy:New> <https://launchpad.net/bugs/1891564>
<mup> Bug #1891564 opened: Fonts are not displayed correctly <Snappy:New> <https://launchpad.net/bugs/1891564>
<mup> PR snapcraft#3244 closed: file utils: introduce get_host_tool_path() to find commands on host <enhancement> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3244>
#snappy 2020-08-14
<mup> PR snapd#9145 closed: boot: track trusted assets during initial install, assets cache  <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9145>
<mborzecki> morning
<mborzecki> zyga: hey
<zyga> hey :)
<zyga> I both wake up at around 6:30
<zyga> and am sleepy because I cannot get to bed earlier than 1AM
<mborzecki> mvo: hey
<mvo> good morning mborzecki
<mup> PR snapd#9139 closed: interfaces/many: miscellaneous updates for strict microk8s <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9139>
<mup> PR snapd#9143 closed: snap: fix repeated "cannot list recovery system" and add test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9143>
<mvo> mborzecki: is 9137 something you are looking at or shall I do that?
<mup> PR snapd#9122 closed: mkversion.sh: disallow changelog versions that have git in it, if we also have git version <Simple ð> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9122>
<mborzecki> mvo: i'm looking at it
<mvo> ta
<mvo> mborzecki: I had it open so just wanted to make sure we don't duplicate work :)
 * mvo looks at fuse instead
<pstolowski> morning
<zyga> now all under control
<zyga> back to bugfixing
<mvo> good morning pstolowski and zyga
<zyga> good morning :)
<pstolowski> o/
<zyga> hey Pawel :)
<mborzecki> pstolowski: hey
<mborzecki> have you seen https://news.ycombinator.com/item?id=24129208 ?
<mborzecki> and https://www.reddit.com/r/linux/comments/i7yk1i/why_is_there_only_one_snap_store/ ?
<zyga> mborzecki the amount of crap there really makes me wonder if having a walk is an order of magnitude more productive way to spend time
<zyga> no amount of facts will help with the infinite pool of opinion
<mborzecki> zyga: haha, i appraise galgalesh's effort to explain the state of things, but at the same time if feels it's all futile
<mborzecki> hm there's no tool in core to calculate sha3-384?
<mvo> mborzecki: we should probably have a snap debug for this :/
<mvo> pstolowski: sorry that the generator PR is such a bikeseed :/
<mborzecki> mvo: i'll try with python's hashlib first, don't recall if sha3 is supported there or not
<mvo> ok
<pstolowski> mvo: don't think there is bikeshed, it's fine
<pstolowski> thanks for review and suggestions
<pstolowski> mvo: the /run/systemd/container tip is excellent
<zyga> yeah, that's really cool
<zyga> error: cannot install snap file: snap "test-snapd-app" has running apps (pause)
<zyga> heh, I guess that's dogfooding allright
<pstolowski> zyga: re #9152 and system("which.."), do you suggest splitting+looping over PATH and "manual" checks?
<mup> PR #9152: cmd/snapd-generator: generate drop-in to use fuse in container <Bug> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9152>
<zyga> yes
<zyga> strtok_r or something like
<zyga> stat or access(X_OK)
<pstolowski> yep
<pstolowski> zyga: do you think it should be a helper in libprivate..?
<zyga> only if you want to - we don't need that in snap-confine today
<seb128> is there a way to stop 'snap watch <id>'?
<seb128> ctrl-C, q, aren't working
<seb128> neither is esc
<zyga> hmm?
<zyga> that's weird
<zyga> what's the state of the process?
<seb128> what process?
<seb128> there is something weird
<seb128> TÃ©lÃ©charger un paquet Snap "ubuntu-bug-triage" (205) Ã  partir du canal "lâ¦  56% 3.75MB/s 731ms
<seb128> the snap is 19M
<seb128>   latest/stable:    2020.08.13+git2e8c31d 2020-08-13 (205) 19MB -
<seb128> and it's doing that 56% for some minutes
<seb128> so I think something is stuck
<seb128> also according to gnome-system-monitor there is no activity, so the snap watch info is lying
<seb128> zyga, any idea? can I get any more debug info before I kill snapd?
<zyga> seb128 snapd or snap wait?
<seb128> I'm going to kill snapd since it seems stuck
<zyga> hmm
<zyga> can you abort the change
<zyga> and try again
<seb128> I've killed snap wait a bunch of times already
<seb128> I should have to do that though
<zyga> yeah
<zyga> but I want to see if snapd is responsive
<zyga> what's the state of snapd.service?
<seb128> zyga, https://people.canonical.com/~seb128/snapd.png
<seb128> zyga, https://people.canonical.com/~seb128/snapdstatus.txt
<zyga> aoÃÂ»t 14 09:00:03 sebxps snapd[1336]: 2020/08/14 09:00:03 Unsolicited response received on idle HTTP channel starting with "HTTP/1.0 408 Request Time-out\r\nCache-Control: no-cache\r\nConnection: close\r\nContent-Type: text/html\r\n\r\n<html><body><h1>408 Request Time-out</h1>\nYour browser didn't send a complete request in time.\n</body></html>\n"; err=<nil>
<zyga> ha
<zyga> that's interesting
<zyga> I guess that's what failed
<zyga> if you "snap abort" the refresh change it will fix itself
<zyga> and we should fix our side to handle this error better
<seb128> should I open a bug on launchpad?
<seb128> do you need more info before I abort?
<zyga> yeah, I think it will help, I'm not super familiar with out store stack
<zyga> pstolowski ^
<seb128> which I guess is going to loose the state
<zyga> can you have a look please and advise seb128
<seb128> zyga, thanks for the replies!
<zyga> always :)
<pstolowski> seb128: yes, please open a bug. i don't have immediate answer to that, seems error handling is missing somewhere, needs investigating
<seb128> pstolowski, I still have the state, I didn't abort yet, do you need any more info before I press the trigger?
<pstolowski> seb128: just in case - 'snap changes' and 'snap change <the refresh change>' if snapd is responding; if not, then 'snap debug state /var/lib/snapd/state.json --changes' and 'snap debug state /var/lib/snapd/state.json --change=..'
<mvo> 408 are kind of a known issue, a combination of store and snapd
<seb128> pstolowski, snapd is responding
<seb128> 315          Doing  today at 08:59 CEST      -                        Actualiser automatiquement les paquets Snap "openstackclients", "ubuntu-bug-triage", "snapcraft"
<pstolowski> seb128: ok, also snap change 315, please attach to bug report (@mvo: do we already have a bug for that?)
<seb128> pstolowski, https://people.canonical.com/~seb128/snapchange.txt
<seb128> k, I will open a bug with those info
<seb128> thanks
<pstolowski> seb128: thank you
<zyga> re
<zyga> I'm making progress in my recovery
<zyga> but man is that annoying
<zyga> my ass hurts from sitting
<zyga> just not used to it
<zyga> I need to take breaks every 15 minutes or so
<seb128> pstolowski, zyga, mvo, k, reported as https://bugs.launchpad.net/snapd/+bug/1891618 now
<mup> Bug #1891618: Snapd stucked after a request timeout error <snapd:New> <https://launchpad.net/bugs/1891618>
<pstolowski> seb128: ty
<seb128> bah
<seb128> so I did snap abort 315
<mup> PR core18#43 closed: Remove manpages and other documentation, cleanup empty doc dirs <Created by sil2100> <Closed by mvo5> <https://github.com/snapcore/core18/pull/43>
<mup> PR core18#72 closed: writable-path: enable persistent journal <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core18/pull/72>
<seb128> $ snap changes
<seb128> ...
<pstolowski> seb128: could you please attach full https://people.canonical.com/~seb128/snapchange.txt there?
<seb128> 315          Abort  today at 08:59 CEST      -                        Actualiser automatiquement les paquets Snap "openstackclients", "ubuntu-bug-triage", "snapcraft"
<seb128> but
<seb128> $ sudo snap refresh ubuntu-bug-triage
<seb128> erreurÂ : snap "ubuntu-bug-triage" has "auto-refresh" change in progress
<seb128>  
<seb128> I still can't refresh my snap?
<seb128> pstolowski, I'm trying but launchpad timeouts when I try to add a file :/
<pstolowski> mhm
<seb128> ah, worked now
<pstolowski> what worked? refresh or adding attachment?
<seb128> addind attachment
<seb128> I guess I need to kill snapd
<seb128> or to reboot but I've work open and I don't want to loose the context
<pstolowski> seb128: give it a few moments, i think it needs to abort and undo things
<seb128> pstolowski, it has been 5 minutes on a modern config and I see no sign of new activity in snap changes
<seb128> I think it's not going to recover or unstuck itself
<seb128> I can wait a bit longer though
<mup> PR core18#90 closed: Placeholder files <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core18/pull/90>
<mup> PR core18#126 closed: hooks: reduce snapd skeleton directories <Created by zyga> <Merged by sil2100> <https://github.com/snapcore/core18/pull/126>
<pstolowski> maybe it's stuck inside this task, give it a minute then yes, snapd restart
<mup> PR core18#134 closed: hooks: add apt/apt-get/apt-cache warning (based on mvo's branch) <Created by sil2100> <Merged by mvo5> <https://github.com/snapcore/core18/pull/134>
<pstolowski> we will look into it
<mup> PR core18#166 closed: hooks/900-cleanup-etc-var.chroot: rm cloud-init config file which we don't want <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/core18/pull/166>
<seb128> pstolowski, it has been 10 minutes, I don't think it makes sense to keep waiting, I restart snapd
<pstolowski> seb128: yes
<seb128> what, systemctl restart snapd is also blocking
<mup> PR core20#11 closed: Add arm64 architecture <Created by xnox> <Closed by mvo5> <https://github.com/snapcore/core20/pull/11>
 * seb128 does shotgun snapd
<seb128> hum
<seb128> ~$ ps aux | grep snapd
<seb128> root       11537  0.0  0.0 477372  6116 ?        Ssl  11:19   0:00 /usr/lib/snapd/snap-failure snapd
<seb128> what is snap-failure?
<seb128> (no manpage)
<zyga> seb128 it's a program we invoke after snapd fails
<mborzecki> seb128: reverts snapd to a previous revision
<zyga> IIRC it should only run on core systmems
<zyga> and yes, we should write manual pages
<mup> PR core20#54 closed: static: switch /etc/cloud from synced to persistent <question> <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core20/pull/54>
 * zyga happily will
<seb128> well, there process is there on my classic desktop
<seb128> and not going away
<seb128> I guess I do need to restart the machine :(
<zyga> hmmm
<zyga> mvo ^
<zyga> this is probably very not intentional
<seb128> that's annoying, I really don't want to reboot now
<seb128> but I need to refresh some snaps to work on things
 * seb128 tries to kill snap-failure, who knows
<pstolowski> i'm setting this to critical
<seb128> ah, I got a working snapd back
<seb128> pstolowski, zyga, thanks for the help
<seb128> pstolowski, well, if it's rare enough that only me have been hitting it that's probably not critical
<mborzecki> zyga: it runs on classic too, otherwise nothing would revert snapd if it fails to start
<pstolowski> seb128: sure, sorry for the inconvienience, we will look into it
<zyga> mborzecki hmmmmm
<seb128> np, thanks for the help!
<mborzecki> seb128: can you post journalctl -u snapd somewhere?
<mborzecki> zyga: maybe you meant snap-repair?
<zyga> no
<zyga> hmm
<zyga> so what is going on
<zyga> why is it running?
<mup> PR snapd#9156 opened: boot: copy boot assets cache to new root <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9156>
<mborzecki> zyga: snapd crashed & failed probably
<seb128> mborzecki, https://people.canonical.com/~seb128/snapjournal.txt
<zyga> yes but is snapd-failure finished
<zyga> or stuck
<mup> Issue core20#66 closed: Use focal base in travis <Created by xnox> <Closed by sil2100> <https://github.com/snapcore/core20/issues/66>
<mup> PR # closed: core20#58, core20#73, core20#74, core20#77, core20#78
<mborzecki> seb128: thanks, can you include all of journal between 11:06 and 11:26?
<seb128> mborzecki, https://people.canonical.com/~seb128/journal.txt
<mborzecki> seb128: thanks!
<seb128> mborzecki, 11:19 is when I ended up doing a kill -9 snapd
<seb128> mborzecki, and :26 when I killed snap-failure
<seb128> or :25 rather
<mborzecki> mvo: ^^ some weird interaction, snapd failed, `snap-failure snapd` got started and launched snapd, which then worked as if nothing happened, because original failure was not related to snapd task
<mvo> mborzecki: oh, why did the original snapd fail? also that sounds like we need snap-failure more clever and just do nothing but restart snapd if it's unrelated to refreshes
<mup> PR snapd#9137 closed: boot: refactor such that bootStateUpdate20 mainly carries Modeenv <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9137>
<mborzecki> seb128: i see you tried to referesh ubuntu-bug-triage snap and abort a change 315, what was the change about?
<mvo> do we know why snapd failed? nil pointer or something?
<mborzecki> seb128: was there a prompt from gtk polkit asking for a password maybe?
<mborzecki> mvo: looks like snapd was not responding, seb128 tried to restart it, but snapd did not exit so got killed by systemd and triggered snap-failure
<seb128> mborzecki, no, but I was on xubuntu session for trying something and polkit prompting seems to not work there
<seb128> so maybe it did try and fail
<mborzecki> mvo: i'm speculating, but what would happen if you have a polkit prompt (or snapd goes to ask polkit) and you try to restart the snapd service?
<mvo> mborzecki: no idea, but that sounds plausible
<mvo> that it would hang then
<mborzecki> mvo: heh, systemctl restart snapd is hanging, snapd is clearly waiting for polkit to answer
<mborzecki> mvo: well, but it was stuck on api activity, so eventually closed
<mborzecki> mvo: so prpbably something else then
<mvo> mborzecki: looking at snap-failure I think it is indeed a bit too naive and not considering non-upgrade cases properly
<mup> PR snapd#9157 opened: o/devicestate: wrap asset update observer error <Simple ð> <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9157>
<mborzecki> mvo: we don't look at the state at all, it feels like snapd should do it when it's launched by snap-failure
<mvo> mborzecki: yeah
<mborzecki> mvo: perhaps we need snap failure to indicate it's in some sort of failure handling mode and the previous snapd would act accordingly (eg. in this case exit nicely and do nothing?)
 * zyga heads upstairs
<zyga> mvo I have a fix for the bug
<zyga> mvo I will have a patch with a regression test ready by the standup
<zyga> it's something we can easily cherry pick into any release
<mvo> mborzecki: yes, I think so
<mvo> zyga: for which bug?
<zyga> mvo the priority bug from field https://bugs.launchpad.net/snapd/+bug/1891371
<mup> Bug #1891371: mount namespace issues <snapd:In Progress by zyga> <https://launchpad.net/bugs/1891371>
<zyga> just working on better testing
<zyga> and explanations
<mvo> zyga: nice!
<mup> PR snapcraft#3203 closed: experimental ros2 extension & colcon v2 plugin <enhancement> <specification> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3203>
<pstolowski> mvo: updated #9152, spread test passed now locally, i had a silly bug (C is full of traps)
<mup> PR #9152: cmd/snapd-generator: generate drop-in to use fuse in container <Bug> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9152>
<mvo> pstolowski: nice
<zyga> pstolowski I'll re-review after standup
<pstolowski> ty
 * pstolowski lunch
<mvo> looks like we have a bug with "service.console-conf.disable: true" during seeidng of core20, instigating right now
<zyga>  /me learned something new justn ow
<mup> PR snapcraft#3248 opened: specifications: fix typo in package-repositories <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3248>
<mup> PR snapcraft#3249 opened: Tiny typo fix <Created by igorljubuncic> <https://github.com/snapcore/snapcraft/pull/3249>
<mup> PR snapd#9158 opened: logger: add support for setting snapd.debug=1 on kernel cmdline <Created by mvo5> <https://github.com/snapcore/snapd/pull/9158>
<pstolowski> oh wow, GitLens for ms visual code is nice
<zyga> E: Failed to fetch http://us-east1.gce.archive.ubuntu.com/ubuntu/pool/main/a/apparmor/libapparmor-dev_2.13.3-7ubuntu6_amd64.deb  Temporary failure resolving 'us-east1.gce.archive.ubuntu.com'
<zyga> anyone seen this?
<mup> PR snapd#9159 opened: cmd/snap-update-ns: detach all bind-mounted file <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/9159>
<zyga> mborzecki /proc/pid/fdinfo/FD shows the mount id of the filesystem that contains the open file
<zyga> TIL
<mup> PR snapcraft#3248 closed: specifications: fix typo in package-repositories <Created by cjp256> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3248>
 * zyga coffee and then more bugs
<mup> PR snapcraft#3249 closed: Tiny typo fix <specification> <Created by igorljubuncic> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3249>
<mvo> xnox: do you think you could have a look at https://bugs.launchpad.net/snapd/+bug/1891644 ? what should we do with console-conf when it's disabled
<mup> Bug #1891644: uc20 seeding fails with "service.console-conf.disable: true" <uc20> <snapd:Triaged> <https://launchpad.net/bugs/1891644>
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/9152#pullrequestreview-467530317
<mup> PR #9152: cmd/snapd-generator: generate drop-in to use fuse in container <Bug> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9152>
<mup> PR snapd#9157 closed: o/devicestate: wrap asset update observer error <Simple ð> <Skip spread> <UC20> <Created by bboozzoo> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9157>
<pstolowski> zyga-mbp: thanks
<zyga-mbp> afk, see you at the standup
<mup> PR snapd#9160 opened: boot, o/devicestate: observe existing recovery bootloader trusted boot assets <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9160>
<zyga> I'll grab lunch now if I can
<mborzecki> i need to wrap it up for now and attend to some errands, bbl
<mup> PR snapd#9161 opened: kernel: add kernel.Validate() <Created by mvo5> <https://github.com/snapcore/snapd/pull/9161>
<cachio> pstolowski, hey
<cachio> I see this https://paste.ubuntu.com/p/V2hF7TJzjB/
<cachio> any idea which could be the root cause'
<cachio> ?
<pstolowski> cachio: is this master?
<cachio> pstolowski, it is my nested branch
<pstolowski> cachio: this test is hacking stuff around snapd inside the preseeded system. it is senstive about what version of snapd runs with snap-preseed, and what version of snapd is used when the preseeded system boots
<cachio> pstolowski, ok, I'll try to see if it is caused because any change in the PR
<pstolowski> cachio: it is also injecting snapd into seeds of the preseeded system
<pstolowski> cachio: also, do you have all changes from master in your branch?
<cachio> pstolowski, no latest ones
 * cachio lunch
<zyga-mbp> I have a fix for networkd
<zyga-mbp> will send and EOD
<mup> PR snapd#9162 opened: gadget: change mountedfilesystemwriter to use resolvedSource (3/N) <Created by mvo5> <https://github.com/snapcore/snapd/pull/9162>
<mup> PR snapd#8931 closed: tests/main/install-fontconfig-cache-gen: enhance test by verifying, add fonts to test <Simple ð> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8931>
 * zyga-mbp goes to exercise
<mup> PR snapd#9163 opened: tests: work around broken update of systemd-networkd <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/9163>
<zyga-mbp> cachio ^ plz merge when green
<cachio> zyga-mbp, sure
<cachio> enjoy the exercises
<mup> PR snapd#9165 opened: interfaces: add kernel-crypto-api interface - 2.46 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/9165>
<mup> PR snapd#9166 opened: interfaces/many: miscellaneous updates for strict microk8s - 2.46 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/9166>
<mup> PR snapd#9167 opened: many: correctly calculate the desktop file prefix everywhere <Created by jdstrand> <https://github.com/snapcore/snapd/pull/9167>
<mup> PR snapd#9163 closed: tests: work around broken update of systemd-networkd <Test Robustness> <Created by zyga> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9163>
<mup> PR snapcraft#3250 opened: cli: implement list-tracks <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3250>
#snappy 2020-08-15
<az> hello, I've installed a dictionary software that it need the command line to run "espeak" command. Snap version doesn't allow the command to run. How to fix that?
<az> tested on apt version and it works
