#snappy 2015-12-07
<liuxg> ping woodrowshen
<pitti> Good morning
<pitti> Chipaca: I am now
<renat> Hi all. It's renat from Screenly. I have a question about snapcraft tool. I want to specify $SNAP_APP_DATA_PATH but
<renat> But I get this error: "services description field 'Start' contains illegal 'usr/bin/screenly-playlist.wrapper -c '$SNAP_APP_DATA_PATH/config.yaml'' (legal: '^[A-Za-z0-9/. _#:-]*$')
<renat> "
<deenlee> eww
<renat> Does this mean that I shouldn't use environment variables in a start command, or it's a bug?
<dholbach> good morning
<liuxg> dholbach, ping
<dholbach> hi liuxg
<liuxg> dholbach, I created a python project using requirements.txt at https://github.com/liu-xiao-guo/restapi
<dholbach> liuxg, I never played around with pip and snapcraft
<liuxg> dholbach, however, there is a problem with the project. It works well on the desktop. When I deploy it onto KVM, it does not work. I see a symbolic link in the snap file http://paste.ubuntu.com/13780578/
<liuxg> dholbach, would you please help me to confirm whether it is a bug or not.
<dholbach> let me see
<liuxg> dholbach, thanks a lot. the django stuff seems not packaged into the snap though they are pulled down.
<ricmm_> renat: it means the path is just a path, not a command line
<ricmm_> you should put this -c ARG into the wrapper itself
<dholbach> liuxg, why don't you use django from the Ubuntu archive? didn't that work? or do you strictly need django 1.9?
<dholbach> liuxg, for me django is contained in the snap
<dholbach> it's in ./usr/lib/python2.7/dist-packages/django
<dholbach> (run dpkg -c mysnap.snap | less)
<liuxg> dholbach, in fact, anything should work. I just tried to see whether it works or not. if I want to use it from the ubuntu archive, I should use the "stage-packages", right?
<dholbach> yep
<liuxg> dholbach, after I deploy it, it is a little strange, in the KVM, it is a symbolic link there though the file is in the "snap" directory.
<liuxg> dholbach, this is what is seen in my place http://paste.ubuntu.com/13780734/
<dholbach> yes, it's a broken symlink
<dholbach> so yes, I can confirm the issue
<liuxg> dholbach, is this a bug in the tool?
<liuxg> dholbach, maybe I need to report a bug for it?
<dholbach> yes, as far as I can tell, there shouldn't be symlinks going to locations which just exist in your home-directory when snapping
<dholbach> yes
<dholbach> your case is very good for testing
<liuxg> dholbach, it took me quite a while to debug this problem
<renat> ricmm_, thanks. I was thinking about it. I can't do it from a snapcraft. So I decided to create a bug in the launchpad.
<ricmm> renat: I dont understand, why cant you do it with snapcraft?
<dholbach> liuxg, maybe we can, as a safety measure, get the reviewers tools to give a warning if the symlinks are going to be broken
<dholbach> liuxg, let me know once you've filed the bug
<ricmm> you are using a wrapper script, so those arguments are better suited inside of the wrapper
<liuxg> dholbach, sure, I am reporting a bug for it.
<dholbach> thanks liuxg
<liuxg> dholbach, i have reported the bug at https://bugs.launchpad.net/snapcraft/+bug/1523384. please take a look at it. I hope it can fixed soon!
<ubottu> Launchpad bug 1523384 in Snapcraft "broken symlinks when snapping a python project using requirements.txt" [Undecided,New]
<dholbach> brilliant - thanks
<dholbach> I'll add a task for the reviewers tools as well
<liuxg> dholbach, thanks for your confirmation. I think this is a serious bug for it :)
<renat> ricmm, that wrapper script is created by snapcraft tool. So I want it  to include my command line options.
<ricmm> ahh I understand, yes
<ricmm> renat: you can modify the .wrapper in snap/ and manually build, or make your own and put it in the right location with a copy plugin
<mvo> ogra_: any concerns about http://paste.ubuntu.com/13782938/ ? we currently rely on /etc/sudoers.d/90-cloud-init-users for sudo but it seems a group makes more sense
<ogra_> mvo, no objections at all ... but doesnt that also need a change in could-init then ?
<ogra_> (it creates some stuff in /etc/sudoers.d IIRC)
<mvo> ogra_: it won't hurt (the cloudinit stuff). its just *if* we use a system without cloud init (a os snap) then things still work with sudo, right now they don't without cloud init
<mvo> ogra_: I will upload then, thanks for the sanity check
<ogra_> ah, cool, yeah, if it is preventive thats fine indeed :)
<mvo> ogra_: looks like bzr and archive are out of sync *grrr*
<ogra_> oh ?
<ogra_> and sil2100's last commit misses a changelog entry
<mvo> ogra_: indeed it does
<ogra_> wow, what a mess
<mvo> choas!
<mvo> ogra_: I will untangle the mess (unless you are already on it)
<ogra_> no, i only checked, didnt start anything yet
<mvo> ogra_: ok, should be fixed in some minutes
<Chipaca> pitti: it seems systemd's journal loses messages during shutdown
<Chipaca> pitti: is this expected?
<Chipaca> pitti: or are we doing something wrong?
<Chipaca> pitti: as in: 'stop' action prints some messages that normally appear in journal, but they're nowhere to be seen on shutdown, but stop action can be seen to be working by tee'ing the messages to a file under its control
<renat> ricmm, seems it's really possible to use shell variables. You may see here that "args" argument is not used in _wrap_exe. https://github.com/ubuntu-core/snapcraft/blob/a06a75e70bcbc76f02f4cbeacee11010f3f24440/snapcraft/meta.py#L256
<renat> ricmm, thanks for help. I want to experiment with snapcraft and see what I can improve.
<Guest9543> stevebiscuit: hello
<stevebiscuit> beowulf: 'ello
<beowulf> mvo: Chipaca: stevebiscuit is the "Steve" for webdm now
<stevebiscuit> there can be only one
<mvo> stevebiscuit: welcome!
<stevebiscuit> mvo: cheers :)
<rsalveti> ogra_: ricmm: so, what are the kernel plans for dragonboard?
<rsalveti> I want to make sure we're aligned in there somehow
<rsalveti> and avoid yet another kernel tree
<ogra_> rsalveti, no idea, waiting for ppisati ...
<ogra_> i just want his deb ;)
<ogra_> <- lazy
<rsalveti> got it :-)
<rsalveti> tell him to ping me later
<ogra_> he is out today i was just told
<ogra_> so probably rather tomorrow
<rsalveti> yeah, no worries :-)
<rsalveti> ogra_: next ubuntu release is going to use 4.4, right?
<ogra_> do you know if i need all of the 8 boot partitions ?
<ogra_> i.e. the blob stuff
<rsalveti> didn't yet try booting without them, so not so sure
<ogra_> ok, then i'll do trial and error as usual :)
 * ogra_ is still pondering how to reflect that partition mess in the oem snap 
<ogra_> hmm, tha dragonboard u-boot tree or the booti command dont understand CONFOG_RAW_IN'ITRD
<ogra_> even with the option set i need to use an uInitrd
<rsalveti> just ping the maintainer, he can easily find out why
<rsalveti> hallor at #96boards
<ogra_> ah i *knew* there was a board channel :P
<pitti> Chipaca: are these messages from very late shutdown, perhaps after journal already stopped?
<pitti> Chipaca: also, I thought snappy uses ephemeral journal only (i. e. not in /var/log)?
<ogra_> pitti, no, it uses both
<ogra_> we have rsyslog installed and running
<pitti> Chipaca: oh, you mean you are not seeing late messages in /var/log/syslog? that's rsyslog, not journal
<pitti> rsyslog gets stopped earlier indeed; but still a bit blurry about what kind of messages are missing
<liuxg> Chipaca, ping
<kyrofa> elopio, don't merge yet
<elopio> kyrofa: ahhhh
<kyrofa> Haha, that's okay
<kyrofa> elopio, not important
<elopio> kyrofa: I'm on the hangout.
<kyrofa> elopio, getting on now
<kyrofa> dholbach, so you've been adding some documentation for the snapcraft plugins?
<dholbach> kyrofa, yep, I've been going through the app developer manual and checking where we could reintegrate some of the bits from there
<kyrofa> dholbach, I'd like to help with documenting the ROS Catkin plugin
<dholbach> kyrofa, it would probably make sense to make it a separate article, right?
<dholbach> a tutorial with an example on how to use the plugin maybe?
<kyrofa> dholbach, yeah probably
<dholbach> kyrofa, probably easiest to just add it to snapcraft trunk and we import it from there :-)
<kyrofa> dholbach, okay. You're pulling from 1.x, right?
<kyrofa> elopio, how do you feel about cherry-picking the ROS plugin updates into 1.x?
<dholbach> kyrofa, right now yes, but soon from both
<kyrofa> dholbach, oh good to know
<dholbach> kyrofa, right now it's still manual, but we're working on the automatic imports
<kyrofa> dholbach, do you have a favorite article who's format I can follow?
<elopio> kyrofa: I would prefer not to touch the other branch if we don't have to. Maybe once you finished doing all the changse and are totally happy with the plugins, we can just replace them.
<kyrofa> elopio, good deal
<dholbach> kyrofa, no, not really - maybe just make it a walkthrough how to turn an existing ROS project into something which works with snapcraft?
<kyrofa> dholbach, right, I guess that was more of a "where exactly should I put it and how do I make it look similar" question
<dholbach> kyrofa, if you just place it as a .md file in snapcraft's ./docs that should be good enough
<kyrofa> dholbach, alright. Would it be worth creating a "plugins" subdir there so that directory doesn't just balloon as we add plugin docs?
<dholbach> I don't know
<kyrofa> dholbach, not important I suppose. I'll just add to the root for now and we can move stuff around if necessary
<dholbach> yep, let's do that
<plars> elopio: joining?
<elopio> plars: uf, sorry.
<sergiusens> kyrofa, elopio, in case you are feeling bored https://github.com/ubuntu-core/snapcraft/pull/160
<kyrofa> Hey sergiusens, how is brazil?
<sergiusens> kyrofa, great, going out for dinner now; but the sprint conversation was great, covered many things, all snaps and capabilities more than anything else
<sergiusens> tomorrow it will be assertions
<kyrofa> sergiusens, awesome :)
<genii> blount
#snappy 2015-12-08
<liuxg> has anyone successfully deployed a python project with installed packages like django? I have a little problem here. thanks
<liuxg> sergiusens, ping
<genii> meh
<Chipaca> jdstrand: tyhicks: so it turns out the perl locale warnings of config are because it uses aa-exec, which is perl. I misremembered about it being deeper in the stack :-)
<Chipaca> i'm wondering if there's any situation where we want to run config with the user's locale, and coming up with "maybe?" :-(
<liuxg> Chipaca, have you tried to install a python project onto snappy system?
<Chipaca> liuxg: yes
<Chipaca> liuxg: I put it into a snap
<liuxg> Chipaca, I've got a problem https://bugs.launchpad.net/snapcraft/+bug/1523384. could you please help to confirm it is a bug?
<ubottu> Launchpad bug 1523384 in Canonical Click Reviewers tools "broken symlinks when snapping a python project using requirements.txt" [Undecided,In progress]
<liuxg> Chipaca, basically, I want to install some extra packages into the snap.
<Chipaca> liuxg: looks like dholbach already confirmed it's a bug
<liuxg> Chipaca, is there any alternative way to do it?
<Chipaca> liuxg: well, I don't know why you end up with a symlink there
<Chipaca> that seems wrong, for starters, but I don't know
<liuxg> Chipaca, i do not know it either. I just simply use the tool to do it. In fact, it seems that dholbach also got the same problem for another project inside one of the examples of snapcraft.
<liuxg> Chipaca, anyway, thanks for helping.
<Chipaca> liuxg: normally i'd be able to look into this, but i'm only getting 5kB/s so can't realistically pull snapcraft i'm afraid
<dholbach> good morning
<mvo_> ogra_: is there anything with rpi2 rolling that I should be aware of? I created an image the other day and it does not boot. but might be a issue with pretty much anything (bad u-d-f, bad sd card). I will try again
<JamesTait> Good morning all; happy Tuesday, and happy Pretend To Be A Time Traveler Day! ð
<ogra_> mvo_, not that i know of, mine works here and has autoupdate turned on
<mvo_> ogra_: could you paste the commandline you used? maybe I did something wrong there
<ogra_> ugh, that was a month ago or so :)
 * ogra_ tries to get it together again :)
<ogra_> sudo ubuntu-device-flash core rolling --channel edge --oem pi2.canonical/stable --enable-ssh --device raspi2_armhf --output raspi2-rolling.img
<ogra_> (i didnt have to use /stable back then though)
<mvo_> ogra_: works now, thank! the --device was missing
<ogra_> ah, cool
<kyrofa> dholbach, when you're able would you mind looking this over? https://github.com/ubuntu-core/snapcraft/pull/159
<dholbach> kyrofa, sure
<kyrofa> dholbach, it's a bit of a book I'm afraid, but I tried to make it relevant
<dholbach> so far it reads just fine :)
<kyrofa> dholbach, crap, I've never used snappy-remote. Does that just sideload via ssh?
<dholbach> yes
<dholbach> kyrofa, nice work - I didn't go through the example myself yet, but the text is just fine - I just added two small comments
<kyrofa> dholbach, good ones, I'm fixing the snapcraft.yaml brief now, thank you! I'd like to be consistent with other docs regarding how snaps are sideloaded-- snappy install or snappy-remote, you tell me
<dholbach> kyrofa, I just thought that snappy-remote might be easier
<kyrofa> dholbach, alright I'll update that as well :)
<renat> Hi all! It's renat from screenly. I have a question. Here: https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ documented that application should create /home/user/apps/<app-name>/<version>/ directory itself. But I'm getting permission denied when trying to create it from the application. How that directory should be created?
<davidcalle> mvo_, ogra_ , do you happen to know? ^
<mvo_> renat: sorry for this mistake in the docs, the dir is created automatically by the generated wrapper and is available via the SNAP_APP_USER_DATA_PATH environment variable
<kyrofa> renat, checkout the /apps/bin/<your_executable_wrapper> and you'll see it created
<davidcalle> mvo_: I've just fixed it in the doc, but can you check the other fields of this table?
<renat> Thanks. Now I can see it in the wrapper script. But /home/user/apps directory is not created.
<renat> Ahh... Now I can see it.
<renat> In /home/bubntu/
<kyrofa> renat, right, it uses $HOME so it's whatever user is running it
<renat> kyrofa, thanks. Is it possible to extend /apps/bin/<executable_wrapper> script to create other directories too?
<kyrofa> renat, such as?
<kyrofa> renat, remember the security policies are pretty tight-- it creates pretty much everything you can access
<kyrofa> renat, but the actual answer to your question is no. You'd have to either do it in the binary itself or create a wrapper script that creates the directories and then calls your binary
<renat> kyrofa, We need to share very heavy files downloaded from the internet between 2 snaps. So I need to create a directory, for example /home/assets. I've already modified security-override file. But I still cannot create that directory from the application itself.
<kyrofa> renat, getting apparmor denials?
<renat> kyrofa, yes.
<kyrofa> renat, can you paste in the denials as well as the generated profile?
<kyrofa> renat, (pastebin, heh)
<renat> kyrofa, Sure. Understood. 2 min
<plars> elopio: so I was able to get a test binary built I think, with go test -c integration-tests/tests - but it's not clear what I could do with it
 * ogra_ would also sugest to have someone from the security team to take a look at your role changes to make sure they are safe
<plars> elopio: it doesn't seem to take any args on its own, or anything like that
<plars> elopio: not even the ones we talked about yesterday
<renat> kyrofa, sorry for disturbing you. Now I can see that files created after I used "bruteforce" security config. I will try to revert everything back and if I will get any issue - ask a question again.
<elopio> plars: it does, pass -h to it.
<elopio> it receives things like check.f, to filter.
<kyrofa> renat, no need to apologize, you're why we're here!
<plars> elopio: no, it just tries to run no matter what I pass to it
<elopio> plars: ah, tries to run the init. That's the news I have for you.
<elopio> plars: yesterday I found a command check.list to list the tests. That's the good news.
<plars> elopio: oh? where does that init get defined?
<elopio> the bad news is that we are wrapping the gocheck runner because it doesn't allow to change the results reporter.
<plars> argh
<elopio> so I can give you a quick fix today. Or a correct fix in a couple of weeks, because we need upstream changes.
<kyrofa> renat, do note, though-- it sounds like you're trying to use Snappy in a way it was not intended (sharing dependencies between .snaps). If you could share some more information about what exactly you're trying to achieve there may be a better way
<elopio> plars: also I need to revert this init change: https://github.com/ubuntu-core/snappy/blob/master/integration-tests/tests/base_test.go#L37
<elopio> that one is easy, I'm starting with that now.
<plars> elopio: ah, right. That looks like what it's trying to do
<elopio> plars: it will accept check.f though, and run the tests that match after the init.
<ogra_> mvo_, hmm, your sudo change seems to have broken the world
<kyrofa> dholbach, I've updated that PR to address the points you raised
<davmor2> ogra_: Don't try blaming mvo_ for your inability to use sudo correctly, you know it's your fault ;)
<ogra_> mvo_, hmm, seems --ingroup can a) only be used once (only the first one is respected) and b) makes the specified group the default group for that user which c) omits creation of the "ubuntu" group
<ogra_> mvo_, i'll split that into multiple adduser lines instead ...
<mvo_> ogra_: thanks and *urgh*
<mvo_> ogra_: sorry for that, I was not aware that adduser has these limitations, a bit disappointing
<ogra_> its written in the manpage (i didnt know you can only use it once thouh)
<ogra_> mvo_, oh, and btw, this group assignment is happening in the real /etc/group in the readonly fs so "ubuntu" is hardcoded there ... we might need to look if we can move the adm and sudo groups over to /var/lib/extrausers
<ogra_> (i.e. if sudo and rsyslog actually get along with this)
<elopio> kyrofa: build-packages installs them in the host, doesn't pull them into the snap.
<kyrofa> elopio, thank you! Funny, I was just experimenting with that :)
<elopio> I added a build-package, a stage-package and a node-package to my yaml. I'm getting a different error now, not sure if that's progress :)
<kyrofa> elopio, hahaha
<kyrofa> elopio, let's say I have a source tree that can build several things, and I want to create different .snaps out of it. How would I do that is the `snapcraft.yaml` needs to be at the root?
<kyrofa> Just rename them as necessary?
<elopio> kyrofa: yes, you can't currently.
<elopio> I think we need to allow snapcraft.yamls in subdirectories, I send an email to the mailing list but didn't got many replies as I expected.
<kyrofa> elopio, perhaps that comes back to your yaml-not-in-root question from ealier
<kyrofa> Yeah
<kyrofa> elopio,  I'll respond with that question, then ;)
<elopio> maybe also supporting different yaml files in the same dir, but then the parts and install dirs need to be handled differently too.
<kyrofa> Even something like make, use `snapcraft -f subdir/snapcraft.yaml`
<elopio> kyrofa: yes, that's what I want.
<elopio> the question would be where to put the part and step dirs. But well, those are details. We just need people to agree that's a good use case to support.
<deenlee> this channel
<kyrofa> elopio, agreed
<camako> I have added the snappy ppa and did "apt-get update/upgrade", but I'm getting
<camako> E: Unable to locate package snappy-tools
<camako> when I do 'sudo apt-get install snappy-tools'
<ogra_> what would "snappy-tools" be ?
<camako> I'm on xenial (desktop). Anyone know what might be wrong?
<ogra_> on xenial you dont need the PPA
<ogra_> what do you want to do ?
<camako> I'm assuming tools for snappy?
<camako> I'm following a doc created by kgunn
<ogra_> snappy-tools is a PPA name, not a package name
<camako> ah ok.. he probably has it wrong in the doc
<ogra_> anyway, what do you plan to do ?
<camako> the end goal is to help him with bring up a mir server on snappy
<camako> he was getting me started with snappy with some instructions
<ogra_> well, install snapcraft ... that should get you everything you need installed
<ogra_> (and technically snaps should nowadays only be built using it)
<camako> further down in the instructions I see 'snapcraft assemble' so I guess you're right
<kyrofa> elopio, I have two options: shell out to a binary, or try using past.translation to use python2 lib in python3. I don't like either. Thoughts?
<elopio> kyrofa: can you start with why you need a python2 lib?
<kyrofa> elopio, rosdep is a python2 binary, but it also has a python2 API
<elopio> kyrofa: I think I'd go with the binary.
<kyrofa> elopio, alright, thank you :)
#snappy 2015-12-09
<dholbach> good morning
<mvo> fgimenez: good morning! I will preare another stable release of 15.04 today, anything looking risky here?
<JamesTait> Good morning all; happy Wednesday, and happy International Anti-Corruption Day! ð
<fgimenez> hey mvo! not AFAIK, moreover once the image is published a new cloud image would be generated and the suite will be executed in http://162.213.35.179:8080/
<mvo> fgimenez: awsome
<fgimenez> mvo, i'm off this week, anyway if you need anything from my side don't hesitate to ping me, i'll be available from 14:00 CET onwards
<mvo> ogra_, ricmm: fwiw, I triggered a new 15.04 build preparing a new stable
<mvo> fgimenez: uh, if you are off then enjoy your time off :) I will bother elopio
<fgimenez> mvo, thx, anyway i'm not very afk, so if you need a hand just ping me :)
<mvo> fgimenez: thanks! much appreciated
<liuxg> dholbach, ping
<dholbach> liuxg, pong
<liuxg> dholbach, for python package installation, can we put the packages into the setup.py like the way for webcam?
<liuxg> dholbach, this is the example https://github.com/ubuntu-core/snapcraft/blob/master/examples/webcam-webui/setup.py
<dholbach> liuxg, I don't understand
<dholbach> which packages do you want to install? which do you want to add to setup.py?
<liuxg> dholbach, for example, we can put the django packages into the "install_requires" field in the file if the package is needed for the app. Currently, it is suggested using the requirements.txt file to do it.
<dholbach> IIRC "install_requires" will make the build/installation fail if the package is not available
<dholbach> requirements.txt is a mechanism to obtain and install the package
<dholbach> (I personally would still go for using the archive unless you need a specific version which is not available in the archive, it should be the easiest)
<dholbach> but maybe zyga, sergiusens and others have an opinion on that too
<liuxg> dholbach, the problem with the archive one is that we need to use the fileset stuff to choose the files and then combine them into a snap. it is a little more complex in this sense.
<dholbach> why do you need the filesets? to make the package smaller?
<dholbach> ... I mean to limit the number of installed files?
<dholbach> I'll be right back... I need to take care of something else for a few minutes
<liuxg> dholbach, yeah, that could be the purpose for it.
<liuxg> dholbach, sure, it is OK:ï¼
<dholbach> strictly speaking for this example you either don't need the filesets or you would use it as well for the other methods of installing django
<dholbach> all of them are likely going to install a lot of files you don't strictly need
<liuxg> dholbach, do you mean if I just simply put " stage-packages: -Django", it will install all of the files for django?
<dholbach> liuxg, the package name in Ubuntu is python-django, but yes
<dholbach> and without the '-'
<liuxg> dholbach, thanks. I will try it later on.
<dholbach> great
<Sweet5hark> Hi there! So Im looking at snappy and wonder how I get to tell snappy on how to order the builds and stages for the parts of a package ...
<Sweet5hark> any hints?
<livcd> does anyone have an experience with snappy vagrant box ?
<mvo> elopio: I pushed candidates to alpha, could you trigger the automatic snappy update test when you are online?
<mvo> elopio: there is a new released planned :)
<livcd> i get ssh timeout with snappy on vagrant. Does anyone experience the same issue ?
<livcd> oh ok that happens only when i try to set a private network
<livcd> what are the default credentials ?
<stevebiscuit> livcd: ubuntu:ubuntu I believe
<livcd> sheesh this is annoying
<Sweet5hark> so, I try to build something with snapcraft that depends on libxml2. The ./configure is all happy about it, build gcc doesnt find headers like libxml/xpath.h when compiling. libxml2-dev is install on the host system and is listed in the snapcraft.yaml as "build-packages: [... ,"libxml2-dev", ...]". What am I doing wrong?
<Sweet5hark> so ... whats the difference  between "snap-packages" and "build-packages" in a snapcraft.yaml?
<elopio> mvo: yes!
<elopio> mvo: what's the trick now to flash this? --oem generic-amd64/alpha doesn't seem to work.
<kyrofa> Sweet5hark, where are you getting `snap-packages`? I don't believe such a key exists in the snapcraft.yaml
<elopio> Sweet5hark: the build-packages will be installed in the host. You require them to perform the build step and generate the files that will be installed.
<livcd> does anyone know how to set a private_network with snappy's vagrant box ?
<livcd> it won't let me login
<elopio> Sweet5hark: to define the order in which the parts are built, use the after keyword.
<kyrofa> Sweet5hark, in case we're misreading that question, snap packages are what are generated by snapcraft, and build-packages are the .deb dependencies required on the host to build the snap packages
<elopio> livcd: I haven't tried vagrant in a long time, sorry. I'll give it a try when I have some free time today.
<Chipaca> elopio: "alpha" isn't a channel
<Chipaca> elopio: generic-amd64/stable should work
<livcd> elopio: thanks. :-/ default settings work fine but I want to use nfs and for that i need private network :/
<elopio> Chipaca: ah, I see.
<Chipaca> livcd: what's the name of the ethernet device when in private_network?
<livcd> Chipaca: i do not specify that
<Chipaca> livcd: i didn't say you did
<livcd> all i do is config.vm.network :private_network, ip: "10.1.0.10"
<Chipaca> livcd: and when you do that, and boot, and log in, what interface name do you find?
<livcd> vagrant up shows adapter 1: nat, adapter 2: hostonly
<livcd> Chipaca: can't log in
<Chipaca> livcd: you don't even have a serial console?
<livcd> nope
<Chipaca> so how do you debug boot issues, for example?
<livcd> mmnt i'll run it with debug mode
<Chipaca> livcd: alternatively boot something else with private_network and check the interface names there
<Chipaca> livcd: I'm taking a wild guess that it's naming the interface something non-standard that snappy firstboot doesn't recognise as an ethernet device
<livcd> thanks for input
<livcd> i'll try that
<Chipaca> so to use private_network you'd need to write an oem snap that specified an interface file, or that installed network-manager
<Chipaca> livcd: but maybe vagrant lets you name interfaces something more standard :-)
<Chipaca> livcd: alternatively it's possible that you're not setting up dhcp on the private network
<Chipaca> in fact, pretty sure that's what you're doing
<Chipaca> as you seem to be specifying a static ip
<Chipaca> to vagrant
<Chipaca> but not to snappy
<Chipaca> so that won't work :-)
<Chipaca> livcd: ^
<Chipaca> livcd: if you absolutely need a static ip, you can probably: boot snappy with dhcp, so you can log in, then overwrite the interfaces file from the booted system
<Chipaca> livcd: then shutdown, change the vagrant config, and boot again
<Chipaca> livcd: this is assuming you don't want to write an oem snap, which would be the 'right' way to do this
<livcd> Chipaca: i am just trying snappy
<livcd> Chipaca: ok i'll try dhcp first and report
<Chipaca> livcd: yep, it sounded like you were just tinkering, hence my tinker-y suggestion
<Chipaca> livcd: specifying all this in a snap is the more scalable/robust/production way :-)
<livcd> first of all i need to know more about snap :-). I was planning to use snappy as a bare image for docker and orchestrate with terraform
<livcd> ok specifying dhcp has the same effect
<Chipaca> livcd: same effect == no network?
<elopio> mvo: flashed 19, updated to 20, rolled back, updated to 20 again, and the full suite is running now on that image for kvm amd64.
<elopio> mvo: can you push the rpi alpha to try there too?
<livcd> Chipaca: yeah
<Chipaca> livcd: and does it work without private_network?
<livcd> with the default settings that work there's lo and eth0
<livcd> yeah
<livcd> i am somehow dissappointed :/
<mvo> elopio: many thanks, rip2 is also copied
<mvo> elopio: eh, not quite
<mvo> elopio: but soon
<mvo> elopio: now
<elopio> I see it, thanks mvo.
<livcd> i am out of options...not sure what else should i try
<elopio> mvo: should we document the need of /stable when flashing before the new release? Or is that going to be fixed before we release?
<mariogrip> when i try to reboot my raspberry pi, it seem like it doesn't reboot correctly. is this known issue?
<dholbach> ogra_: jcastro made something for you: http://i.imgur.com/CcwkgN7.jpg :-)
<elopio> :D
<ogra_> dholbach, hah ! cool !
<ogra_> thats a really nice pic, i have never seen it
<livcd> Chipaca: the private_network setting has lo,eth0 and eth1 adapters
<elopio> ogra_: I get choppy output on the serial console of the rpi. Does it have a different rate? I'm using 115200
<ogra_> elopio, nope, 115200 is correct
<ogra_> works fine here
<elopio> ogra_: it's not garbage, it's just misaligned.
<elopio> maybe the cable.
<ogra_> what terminal program do you use ?
<elopio> ogra_: screen
<ogra_> hmm, me too
<ogra_> so yeah, probably the cable
<xnox> what is ubuntu-core-meta and should i care?
<elopio> mvo: On rpi, flashed 3, updated to 4, rolled back, updated to 4 again, and the full suite is starting.
<mariogrip> reboot -f does not work either
<elopio> mvo: is there something special you would like me to check or explore?
<elopio> mvo: is there something special you would like me to check or explore?
<ogra_> xnox, good question, i didnt think there exists a meta for -core
<elopio> sorry, hiccup.
<ogra_> xnox, -core only uses tasks, we do not have a meta
<ogra_> s/have/need/
<ogra_> xnox, perhaps that meta is from infinitys "ubuntu-core" (not snappy) ?
<xnox> probably
<mariogrip> how do i switch channel on the rpi? (stable -> rolling/edge )
<elopio> mariogrip: there is no supported way yet. You can edit /etc/system-image/channel.ini, but for that you have to make the partition writable, and we don't guarantee success
<mariogrip> thanks, I'll give it a try
<mariogrip> but do you know if there is any known issue with reboot on the rpi?
<mariogrip> on version 3
<mariogrip> sorry i mean version 2
<elopio> mariogrip: not that I know of. Please report a bug if you see something weird.
<mvo> elopio: nothing in particular 15.04 has not changed much so we should be mostly fine
<elopio> mvo: things look good from here. I'll go and have lunch and can run the tests on bbb.
<mvo> elopio: thanks
<kyrofa> elopio, I want to make a helper class for my plugin. How should I organize that? Clutter up the plugin file with another class, or is there a sensible place to extract it?
<mvo> elopio: amd64/armhf/rpi2 released to stable
<sergiusens> kyrofa, elopio just a tiny hello :-)
<kyrofa> sergiusens, hey, been a while!
<kyrofa> sergiusens, how's it going?
<sergiusens> kyrofa, fine, 7PM and still discussing things here... talking is tiresome :-P
<kyrofa> sergiusens, yeah... exhausting
<sergiusens> kyrofa, how's it going with you?
<kyrofa> sergiusens, I hope you're sleeping alright
<kyrofa> sergiusens, things are going well! Still adding some ROS features, figuring out snapcraft, whining about the lack of a clean build, etc
<sergiusens> kyrofa, yeah, more than ever, but having to follow conversations for 9 hours straight and then do the same during dinner gets you really tired
<kyrofa> sergiusens, definitely
<sergiusens> kyrofa, hah, clean build I can implement on the way back :-)
<kyrofa> sergiusens, :D
<kyrofa> sergiusens, you should relax on the way back though
<sergiusens> kyrofa, I really want to land the new-cli branch into master ASAP, but I haven't had a chance to fix the integration tests
<kyrofa> sergiusens, ah, yeah that'll be nice
<sergiusens> and it has been a laptops closed meeting
<kyrofa> Oh man... so you REALLY have to pay attention
<sergiusens> yeah
<kyrofa> sergiusens, don't worry man, we'll get there. You can slow down a little :)
<sergiusens> hah
<sergiusens> kyrofa, I am suffering from depravation
<sergiusens> ;-)
<kyrofa> I can't get to Universe. Anyone else?
<kyrofa> Rather, I'm getting a hash mismatch of some kind
<kyrofa> Ah, looks like it's working now
<Sweet5hark> sooo, I have libxml2-dev installed on the host system and have "stage-packages: - libxml2-dev" in my snapcraft.yaml. I see my configure using getting a .../snap/usr/include/stage/usr/include/libxml2 from pkg-config. However that dir does not exist ....
<Sweet5hark> shouldnt "stage-packages" ummm  ... stage packages?
<Sweet5hark> ... so that they are actually found where pkg-config claims them to be in the snapcraft env?
<elopio> kyrofa: if the helpers are only used in your .py, put them in there with _ in front.
<elopio> then if we need them in other module, we can discuss if removing the _, or putting them in a different .py, or both.
#snappy 2015-12-10
<kyrofa> elopio, alright thanks :)
<liuxg> how is "organize" in snapcraft.yaml is used? thanks
<liuxg> dholbach, ping
<dholbach> liuxg: pong
<liuxg> dholbach, do you know what the following sentence means in the snapcraft.yaml?  http://paste.ubuntu.com/13886619/ the organize part
<dholbach> liuxg: no, I'm afraid not - best to ask sergiusens or kyrofa when they are back online
<liuxg> dholbach, ok. I will do that. the explanation in the document is very weak. https://docs.google.com/document/d/1Rj9nVBttx62BvGlbnkmKOzAlAIEWuLNr1QaSGe3gQDA/edit#heading=h.bx30erj03sx1
<dholbach> ah ok, look at this:
<dholbach>    * `organize` (yaml subsection)
<dholbach>      A dictionary exposing replacements, the key is the internal name whilst
<dholbach>      the value the exposed name, filesets will refer to the exposed named
<dholbach>      applied after organization is applied.
<dholbach> ah, yes - that's the same
<liuxg> dholbach, what does it exactly mean in the context?
<dholbach> I don't know - I didn't write it
<dholbach> I would need to read the code to understand
<dholbach> are files renamed with the patterns mentioned there?
<liuxg> dholbach, I am going to have a snapcraft training for some of the people in one week. I am trying to understand more about it.
<dholbach> I see
<liuxg> dholbach, it sounds like that the files inside opt/bin will be put into the bin directory?
<dholbach> I don't know
<dholbach> have you tried it?
<liuxg> dholbach, I have tried the code snippet there, and it does not work at all. http://paste.ubuntu.com/13886619/, it seems there is some error for it.
<dholbach> if it errors out, that's a bug :/
<dholbach> or the example needs to be updated
<liuxg> dholbach, the line does not work at all    - *.h
<dholbach> can you file a bug about it?
<liuxg> dholbach, i will, the "type" null means a null plugin, right?
<dholbach> yes
<liuxg> dholbach, there are a few bugs with the code there.
<dholbach> yes, it needs to be updated
<liuxg> dholbach, so, it is against snapcraft?
<dholbach> maybe the example needs to be updated and then it works?
<dholbach> there were some changes in the early versions of snapcraft, like type â plugin
<liuxg> dholbach, that seems the only document we can refer to. we need a complete tutorial on snapcraft. will anyone push for that?
<dholbach> liuxg: the document needs to be updated if the example doesn't work
<dholbach> ricmm: ^
<dholbach> in general I think it does a good job though
<liuxg> dholbach, this is the project https://github.com/liu-xiao-guo/null
<liuxg> dholbach, would you please have a try in your place?
<dholbach> I can't
<dholbach> I have to go to the dentist now
<liuxg> dholbach, ok. if you are free, you can do it at your convenience later on.
<dholbach> but there are a lot of other folks in here, maybe somebody else can help
<JamesTait> Good morning all; happy Thursday, and happy Nobel Prize Day! ð
<liuxg> zyga, ping
<zyga> liuxg: hey
<liuxg> zyga, last time, you told me to try the requirements.txt, I have tried it, and there is a problem for it. I have reported a bug for it at https://bugs.launchpad.net/snapcraft/+bug/1523384
<ubottu> Launchpad bug 1523384 in Canonical Click Reviewers tools "broken symlinks when snapping a python project using requirements.txt" [Undecided,In progress]
<zyga> liuxg: thanks for reporting the bug
<liuxg> zyga, it is ok. by the way, today, I tried another project at https://github.com/liu-xiao-guo/null, I also failed. I did it according to the document "Snappy Ubuntu Core - Application Developer Manual 15.04". I do not where I was wrong for it.
<liuxg> zyga, I also reported a but for it at https://bugs.launchpad.net/snapcraft/+bug/1524663.
<ubottu> Launchpad bug 1524663 in Snapcraft "Issues while validating snapcraft.yaml: None is not of type 'string'" [Undecided,New]
<dholbach> liuxg: I sent a pull request for your example -it should work now
<dholbach> but still I feel it's a valid bug because the error messages of snapcraft didn't actually reveal any of the issues
<dholbach> maybe you could change the bug description to that
<liuxg> dholbach, do you mean the null example?
<dholbach> yes
<dholbach> https://github.com/liu-xiao-guo/null/pull/1
<liuxg> dholbach,  did you do any change?
<dholbach> see the pull request
<dholbach> there were a number of issues with the example (I updated the doc already)
<liuxg> dholbach, OK. many thanks, I think document should be updated :). yes, we need to make the example working. the document is accessed by many people.
<dholbach> liuxg: I already updated the doc
<liuxg> dholbach, that is cool! by the way, have you figured out "organize" ?
<dholbach> yes, it's basically a rename
<dholbach> just check the contents of the snap in your example and the files in the parts/ directories
<liuxg> dholbach, do you mean rename the "opt/bin" to "bin"?
<dholbach> yep
<dholbach> or in the working example   usr/bin  â  bin/
<liuxg> dholbach, in my example, it is  opt/bin: bin, so, we change it to "usr/bin to  "bin"?
<dholbach> https://github.com/liu-xiao-guo/null/pull/1/files
<dholbach> check the diff
<dholbach> that's what makes the example actually work
<liuxg> dholbach, yes, I see it. thanks a lot.
<dholbach> ok, cool :)
<liuxg> dholbach, you are marvelous!
<dholbach> thanks a lot - this was a useful exercise for me as well :-)
<liuxg> dholbach, so all of the files in the /usr/bin are gone. the final snap is like http://paste.ubuntu.com/13893283/. the gnupg files are not there.
<dholbach> hum, that's weird - try:   snapcraft all --force
<dholbach> for me it looks like this: http://paste.ubuntu.com/13893318/
<liuxg> dholbach, I have merged your changes already, now the project is like https://github.com/liu-xiao-guo/null/blob/master/snapcraft.yaml. I pulled everything there
<dholbach> I'm using xenial, but I'm not sure if that makes a difference
<liuxg> dholbach, I just used your command "  snapcraft all --force", it seems to be right. I am now doing it again with a normal "snapcraft"
<dholbach> ok
<dholbach> "all --force" will go through all phases of snapcraft again and through away old results
<dholbach> that's useful if previous runs downloaded something else or moved files around or whatever
<dholbach> Sergio said that in version 2.0 snapcraft is going to be cleverer
<dholbach> but until then we will have to bear that trick in mind
<kyrofa> dholbach, an even more handy trick is to alter your part's `state` file and set its contents to "pull," then run snapcraft again
<kyrofa> That way it will rebuild the part without repulling .debs etc.
<kyrofa> I find that to be the longest part, depending on the project of course
<liuxg> dholbach, If I simply use "snapcraft", the result is the same as what I showed you. However, if i use "--force" option is the like yours. I am still confused. Do I need to use "--force" option all the time?
<dholbach> no
<dholbach> you shouldn't have to
<dholbach> I need to run again... see you later
<liuxg> dholbach, ok. thanks. I will let you know the result. it is a little strange to me anyway
<kyrofa> liuxg, the snapcraft behavior is very unintuitive right now regarding how the steps are run after they've already been run once. --force is backwards, and it's all very confusing
<dholbach> kyrofa can probably help
<kyrofa> liuxg, we're working on changing that right now :)
<kyrofa> liuxg, so rest assured, we feel your pain
<liuxg> kyrofa, thanks for your explanation. so in the future, we will just use snapcraft, right?
<elopio> kyrofa: today I need to take my motorcycle to the mechanic. I might be late for the stand up, because buses are unpredictable.
<elopio> I'll ping you when I'm back.
<kyrofa> elopio, no problem, thanks for the heads up :)
<kyrofa> liuxg, first of all, before I try to explain anything you're gonna have to take what I say with a grain of salt-- I only started on snapcraft recently :)
<liuxg> kyrofa, alright, thanks
<kyrofa> However, my understanding is that the snapcraft steps (pull, build, stage, snap, assemble) will remain the same
<kyrofa> liuxg, I believe running `snapcraft` will continue to run through all steps, but it won't re-run any steps it has already run unless you force it
<kyrofa> liuxg, similarly, say I run `snapcraft` once and it makes a .snap. If I run `snapcraft pull` again, it won't re-pull because it knows it's already done that. So I'd have to run `snapcraft pull --force`
<kyrofa> sergiusens will know all the details here, so hopefully I'm not leading you astray with where things are going
<liuxg> kyrofa, I got you. If I run a "snapcraft clean" first, after that, I run "snapcraft", will it run through all of the steps?
<kyrofa> liuxg, that sounds about right
<liuxg> kyrofa, in my places, it a little bit not so right. I have my test project at https://github.com/liu-xiao-guo/null. it seems to give me different results when i run it.
<kyrofa> liuxg, you mean `snapcraft clean` followed by `snapcraft`?
<liuxg> kyrofa, yes, that is what I did here. I did not see all of the directories before I did another "snapcraft"
<kyrofa> liuxg, give me a minute, let me pull the project
<kyrofa> liuxg, I get this after a `snapcraft` run. Same as you? http://pastebin.ubuntu.com/13894019/
<liuxg> kyrofa, what is the content inside the snap?
<kyrofa> liuxg, bin/{wget,gpg-zip,gpgsplit,gpg}
<liuxg> kyrofa, in my case, http://paste.ubuntu.com/13893962/
<kyrofa> liuxg, alright let me try a clean and another snapcraft
<liuxg> kyrofa, this is another try with "--force" option http://paste.ubuntu.com/13894098/
<kyrofa> liuxg, interesting, you're right-- after I've cleaned and run again, I have the same as you
<kyrofa> liuxg, let me look into this
<kyrofa> liuxg, hang around, I'll ping you when I learn something
<liuxg> kyrofa, it is a very confusing to me. running different command gets different results :)
<kyrofa> liuxg, agreed
<kyrofa> liuxg, confusing to me too :)
<liuxg> kyrofa, sounds like a bug somewhere :) next time, I have to use to methods to try them. Still maybe I do not know which one is right.
<liuxg> kyrofa, daniel seems to have a different result than us http://paste.ubuntu.com/13893318/
<kyrofa> liuxg, haha, no kidding. I didn't have the lspgpot in there
<kyrofa> liuxg, I suspect something is weird in the filtering
<liuxg> kyrofa, I do not have it too :)
<liuxg> kyrofa, I am using daniel's repository, which is the same as mine. I got different results for the two builds http://paste.ubuntu.com/13894397/
<liuxg> kyrofa, I have created a bug report for it at https://bugs.launchpad.net/snapcraft/+bug/1524846. if you have any updates about it, could you please update it there? thanks a lot for your helping!
<ubottu> Launchpad bug 1524846 in Snapcraft "Different results obtained when building the same project" [Undecided,New]
<kyrofa> liuxg, no problem :)
<kyrofa> sergiusens, I ran into a terrible problem yesterday
<kyrofa> sergiusens, if the `source` option for a plugin is ".", it causes ./parts/foo/src to be symlinked to ., which results in a circular link. Which makes any automatic src parsing useless
<kyrofa> elopio, ^^ too
<tasdomas> hi
<tasdomas> how do I disable the automatic snappy update installation
<ogra_> tasdomas, the easiest is probably:
<ogra_> snappy config ubuntu-core >core-config.yaml
<ogra_> then edit the value of autoupdate from true to false ...
<ogra_> and run:
<ogra_> sudo snappy config ubuntu-core core-config.yaml
<ogra_> that will set the new value
<tasdomas> ogra_, thanks
<elopio> kyrofa: that happened to me, but when the yaml was not in the root.
<elopio> in theory we have a condition check that prevents the parts dir to be copied.
<kyrofa> elopio, but it's a symlink, not a copy
<kyrofa> elopio, note that I'm talking about the sourcedir, not the builddir
<elopio> kyrofa: right, the condition is on build, where we copy.
<kyrofa> elopio, and that makes sense
<kyrofa> elopio, so perhaps this is only really a problem where we need to interrogate the sourcedir in order to complete the pull()
<kyrofa> elopio, e.g. the catkin plugin
<kyrofa> elopio, so I'm simply making the source and source-subdir checks a bit stricter for that plugin
<kyrofa> elopio, but definitely a dangerous thing to keep in mind, at least
<elopio> I couldn't add the condition to pull, because of the symlink. So maybe it would be good to copy in pull too.
<kyrofa> elopio, took me forever to figure out why it was taking so darn long to run
<rOger___> Hi all
<kyrofa> elopio, interesting idea, but a bit heavy depending on the project
<elopio> kyrofa: right, same here. Until it failed because it was copying a path too long.
<kyrofa> elopio, that may be the best/cleanest solution
<elopio> rOger___: Hello!
<rOger___> I'm checking ubuntu snappy as a base system for embedded appliances
<rOger___> for our requirements we should be able to replace several parts of the boot scripts with a different init "system"
<rOger___> is there an official way to accomplish this?
<ogra_> why do you need to replace the init system ?
<elopio> rOger___: not yet. But the devs are working on splitting the image into snaps. And one of the things they are discussing is where is the bootloader defined, and how to replace it.
<rOger___> We want to use our python based init scripts where we have more influence on some parts of the system config (like networking)
<ogra_> well, thats not really how snappy works
<morphis_> sergiusens, ricmm: does the snappy store group snaps per core image version?
<morphis_> or do I publish a snap for everything?
<ogra_> you have a very locked down core (readonly etc) ... that does the system boot ... and ten you have snaps ... a snap can ship services and binaries ... so you can have your application in a snap nad have the service started on boot ...
<rOger___> @ogra_: so if you call a "firewall" an application; It will be called too late in the boot process; the network interfaces will be setup before the application will be started so during a short time I have a router instead of a firewall
<nothal> rOger___: No such command!
<rOger___> \ogra_: so if you call a "firewall" an application; It will be called too late in the boot process; the network interfaces will be setup before the application will be started so during a short time I have a router instead of a firewall
<ogra_> things like networking are part of the core component though
<ogra_> snappy offers an interface to configure it etc but you wouldnt easily be able to replace parts in the core
<ogra_> (your snap could also ship its own network handling and tell snappy to turn off its own handling though ... )
<ogra_> no, as i said, you can tell snappy to not take over networking
<morphis_> ogra_: you know that?
<ogra_> morphis_, well, in 16.04 you will be :)
<ogra_> not sure Chipaca landed that yet but i know it was discussed :)
<ogra_> rOger___, jdstrand recently created a ufw snap ... though that integrates with the existing core
<morphis_> ogra_: so what is the current store targetting?
<rOger___> ogra_: that sounds interesting; i will check it out
<ogra_> morphis_, depends ... you can pick when you upload ... most packages should target stable
<ogra_> but you can pick "edge" as well
<ogra_> (which would target the rolling release by default)
<morphis_> ogra_: ah
<morphis_> ogra_: stable is 15.10?
<morphis_> ogra_: and that changes with 16.04?
<ogra_> not sure how it will chane then .... stable is 15.04
<ogra_> *change
<morphis_> ok
<morphis_> ogra_: so I can publish two versions?
<morphis_> on for edge and stable?
<ogra_> you should be able to ... havent tried it myself
<morphis_> ogra_: thanks!
<ogra_> np ... ask beuno for more details :)
<kyrofa> elopio, ah! I finally understand this stupid mock library
<beuno> mwenning, yes you can
<beuno> er
<beuno> morphis_, ^
<morphis_> beuno: great
<sergiusens> tyhicks, is there a security reason for this https://bugs.launchpad.net/snappy/+bug/1523372 ?
<ubottu> Launchpad bug 1523372 in Snappy "Can't specify environment variable in a service start command" [Undecided,New]
<sergiusens> kyrofa, hey, do you have a sec?
<kyrofa> sergiusens, for you, always
<sergiusens> kyrofa, hah, let me give you a hangout link :-)
<tyhicks> kyrofa: check the privmsg from me
<wililupy> Hello, I'm trying to build a snap of LISPmob, but it requires some system changes to snappy, like a configuration file in /etc and some changes to the /etc/sysctl file. How do I go about this in my snapcraft.yaml file?
#snappy 2015-12-11
<liuxg> has anyone done django on snappy ubuntu? I have a little problem in getting it to work. it seems that the urls is not working though it works well on the desktop environment. thanks
<liuxg> does anyone know what "build-packages: [libssl-dev]" means in the snapcraft.yaml syntax?
<dholbach> good morning
<svij> morning dholbach
<dholbach> hi svij
<liuxg> dholbach, ping
<dholbach> liuxg: pong
<liuxg> dholbach, I just found the example snapcraft.yaml at the link https://github.com/ubuntu-core/snapcraft/blob/master/examples/downloader-with-wiki-parts/snapcraft.yaml, what is the use of the "build-package"?
<liuxg> dholbach, it looks like that it installs the package for the project. However, if I remove it, the project still can be successfully compiled
<dholbach> liuxg: it's there, so somebody who tries to use your snapcraft.yaml locally has the required packages installed for the build
<liuxg> dholbach, oh right, it is used use to install to the host computer, right? then can we do the same for "curl" in the example?
<dholbach> yes, it should work for everything
<liuxg> dholbach, you are right. I previously installed the package for "libssl-dev", so now I do not need it, and I can still successfully compile it.
<dholbach> :)
<liuxg> dholbach, by the way, I have used your stage-packages method to install the django stuff, and I successfully compiled them into the project. However, the project does not run in the KVM. the project works well on desktop.
<dholbach> liuxg: did you find out why?
<dholbach> it would be really nice if you could write up your story and send it to snappy-app-devel@lists.u.c
<dholbach> others could start helping with your project
<dholbach> and learn from it
<dholbach> there is a lot to be learnt from your experience
<liuxg> dholbach, I do not know why it happens to be like that. the app is started, but the ulrs are not routed, so still something is wrong about it..
<dholbach> ah... do you redirect the ports when using kvm?
<liuxg> dholbach, yes, I will do that for sure. yes, I redirect it to the port 8090
<dholbach> ok
<liuxg> dholbach, this is a little bit frustrating since the debugging on snappy is limited, and sometimes is not so easy to spot the problems
<liuxg> dholbach, I have never received emails from snappy-app-devel@lists.u.c?
<dholbach> liuxg: are you signed up for it? https://lists.ubuntu.com/mailman/listinfo/snappy-app-devel
<liuxg> dholbach, where to subscribe the mailing listï¼I only receive emails from snappy-app-devel-request@lists.ubuntu.com, are they the same?
<dholbach> snappy-app-devel-request is no mailing list - it's just the email you interact with to (un)subscribe
<liuxg> dholbach, ok. I got it. sorry for the confusion!
<dholbach> no worries
<JamesTait> Good morning all; happy Friday, and happy birthday to UNICEF! ð
<liuxg> dholbach, I am now trying to use snappy-app-devel@lists.u.c, but it complains that it it not recognized.
<dholbach> did you expand u.c to ubuntu.com?
<dholbach> sorry, I was just using a shortened version
<liuxg> dholbach, No, I did not, sorry
<liuxg> dholbach, I just sent one email for it.
<dholbach> ok cool
<liuxg> dholbach, yesterday, I sent one email, but I used the wrong email address :) I sent it to snappy-app-devel-request@lists.ubuntu.com
<dholbach> I'm glad we fixed this issue now too :-D
<liuxg> dholbach, yeah, it is true. I am going to have my dinner. Have a great weekend!
<dholbach> you too! have a good one! :)
<liuxg> dholbach, thanks! :)
<ogra_> GRRRR
<ogra_> why has apt suddenly a system user ?
<xnox> "security"
 * ogra_ goes and fixes livecd-rootfs to respect that ... 
<MikeB> QUESTION: How do I apply patches to pull'ed code before it is built?
<cyphermox> hi. is there a snap for unity? If I wanted to install snappy on my laptop but still have a graphical interface?
<kyrofa> cyphermox, not yet. We're still working on the graphical snap pieces
<cyphermox> kyrofa: ok, thanks
<MikeB> In snapcraft, how does one apply local patches to pull'ed code before building?
<ogra_> MikeB, i dont think there is a way yet despite pushing your while modiied tree to github or so
<ogra_> *whole
<MikeB> ogra_, thanks. I'm surprised there's no such way to do that.
<ogra_> i think it is planned ... sergiuens could tell, but he isnt around
<Chipaca> ogra_: yes, the don't-take-over-networking is landed
<Chipaca> ogra_: all the way to 15.04 even
<Chipaca> it's an oem snap option
<ogra_> ah, i'll tell morphis (next week i guess)
<Chipaca> ogra_: something ridonculous like please-dont-use-networking-because-you-suck-ok: false
<Chipaca> ogra_: skip-ifup-provisioning
<ogra_> neat
<Chipaca> under oem in the oem snap yaml
<ogra_> k
<elopio> kyrofa: I almost made it with mailpile, but got stuck on apparmor denials...
<elopio> http://pastebin.ubuntu.com/13935183/
<kyrofa> elopio, those are just the stupid .pyc ones though
<kyrofa> elopio, I think you can ignore those
<elopio> kyrofa: well, the server is not starting. I thought it was because of this.
<kyrofa> elopio, I doubt it. Sure there isn't a more meaningful denial in there?
<kyrofa> elopio, have you run it with snappy-debug?
<elopio> that's the only thing I see on dmesg, and on the service log it says it all went fine.
<elopio> I haven't tried snappy-debug before. /me tries.
<kyrofa> elopio, yeah snappy install snappy-debug, then sudo snappy-debug scanlog (IIRC)
<elopio> kyrofa: yes, just unlink and mknod on pyc files. Lots and lots of them.
<kyrofa> elopio, huh... I thought that wasn't a fatal python error?
<kyrofa> elopio, I just figure it's unable to save the compiled version so it has to do it everytime. Too bad
<kyrofa> elopio, maybe barry knows better?
<kyrofa> I wonder if there's a way to redirect where python tries to put those
<elopio> kyrofa: well, I'm not sure this is the cause. It's just the only output I get.
<kyrofa> elopio, good point. It may be the thing simply malfunctioning, external to apparmor all together
<elopio> or me doing something stupid. That's always an option :)
<elopio> anyway, context swtich now.
<barry> kyrofa: sorry, what's the issue?
<kyrofa> barry, when making a python .snap, we always see denials trying to create .pyc files
<barry> kyrofa: "denials"?  write errors?
<kyrofa> barry, 1: Can that ever be a fatal error? 2: Is there any way to redirect where python tries to put those files? 3: Is there a big benefit to putting them somewhere else?
<kyrofa> barry, apparmor denials, although even if apparmor didn't get it the .snap's directory is read-only
<barry> kyrofa: technically, pyc files are just a cache of the compilation step.  they aren't *required* but they are a very good idea if you want it to be fast.  -B/PYTHONDONTWRITEBYTECODE=1 can be used to disable writing pyc files, but you can't really put the pyc files in a different place by default (you could in py3 if you wrote a custom import hook).  i don't think there's much benefit to the added complexity of putting them somewhere
<barry> else.  this is also somewhat different between py2 and py3 (with the latter using __pycache__ directories next to the .py files)
<kyrofa> barry, ah, exactly the information I was looking for, thank you!
<kyrofa> elopio, perhaps you could try the above to reduce apparmor noise and see if you have any other errors you're missing?
<barry> np!
<elopio> kyrofa: I'll try that. Also it seems that the command line argument they give to just run the server doesn't work.
<elopio> and if I don't pass it, the service is not left running either, something kills it.
<wililupy> Does anyone know of any documentation on what all options can go in the snapcraft.yaml file?
<kyrofa> elopio, https://github.com/ubuntu-core/snapcraft/pull/163 when you're able
<kyrofa> wililupy, sorry, I just saw your question
<kyrofa> wililupy, a PR is sitting to add just that-- you can likely learn from it if you like: https://github.com/ubuntu-core/snapcraft/pull/146
<wililupy> kyrofa: excellent thank you. I'll look it over. My snap is "partially working" now, but I keep having permission issues for packet capturing, which I'm hopeing is something I can just add to the binaries: or services: section
<kyrofa> wililupy, alright, well come back if you continue to have troubles :)
<kyrofa> jdstrand, have we made any more progress on bug #1466234 ?
<ubottu> bug 1466234 in ubuntu-snappy (Ubuntu) "Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root" [Critical,Triaged] https://launchpad.net/bugs/1466234
<kyrofa> ogra_, I'm looking for some documentation on port negotiation
<kyrofa> ogra_, any pointers?
<ogra_> negotziation ? no
<ogra_> probably Chipaca has an idea
<kyrofa> ogra_, oh... the docs say "there is no implementation for this yet" :P
<ogra_> heh, i have never needed it
<kyrofa> ogra_, yeah, I was trying to pave the way to having multiple ROS snaps installed
 * ogra_ has the ports in his snaps configurble via snappy config ;)
<ogra_> +a
<kyrofa> ogra_, how does that work?
<kyrofa> ogra_, perhaps I could make a workaround for now
<kyrofa> ogra_, https://developer.ubuntu.com/en/snappy/guides/config-command/ ?
<ogra_> well, i'm pretty non-std and prefer to use shell for such stuff :) but have a look http://bazaar.launchpad.net/~ogra/+junk/packageproxy/files
<ogra_> snapcraft.yaml defines config.sh ... config.sh writes a yaml file as well as the actual confi for the app/service
<ogra_> your config tool can indeed be a python script, go or C ...
<kyrofa> ogra_, nice, okay thanks!
#snappy 2015-12-12
<wililupy> Has anyone here had luck/expirience setting capabilities (setcap) for networking?
<rew> what is the difference between snappy and ubuntu?
<rew> what is the difference between transactional updates versus the normal ubuntu updates?
#snappy 2015-12-13
<Mikman> Hey guys I'm doing a blog about ubuntu and one of the projects I have chosen to speak about is snappy.  Can anyone tell me or link me to a place that can tell me like an explanation or summary of the project and why it's important.
<tsimonq2> Mikman: https://developer.ubuntu.com/en/snappy/
<tsimonq2> Mikman: http://www.ubuntu.com/cloud/snappy
<tsimonq2> Mikman: https://developer.ubuntu.com/en/snappy/start/
<tsimonq2> Mikman: http://www.ubuntu.com/internet-of-things
<Mikman> These are really helpful for my snappy explanation
<tsimonq2> Mikman: aaaaand https://developer.ubuntu.com/en/snappy/start/using-snappy/
<tsimonq2> Mikman: lastly https://developer.ubuntu.com/en/snappy/build-apps/
#snappy 2016-12-12
<mup> PR snapd#2443 opened: removing circular dependency between snapstate and hookstate <Created by cyberb> <https://github.com/snapcore/snapd/pull/2443>
<liuxg> has anyone successfully compiled the mosquitto sample in the snapcraft demos at https://github.com/snapcore/snapcraft/tree/master/demos/mosquitto? I get some errors like http://paste.ubuntu.com/23617381/
<mup> PR snapd#2445 closed: cmd/snap,tests: alias support in snap run <Critical> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2445>
<dholbach> hey hey
<didrocks> hey dholbach!
<dholbach> salut didrocks
<seb128> hey dholbach!
<dholbach> salut seb128
<simon_b> How can I set environment variables in a snap? I am trying to use gstreamer, but it can't find its plugins in there it seems.
<simon_b> this is what I get from gstreamer: GStreamer-WARNING **: External plugin loader failed. This most likely means that the plugin loader helper binary was not found or could not be run. You might need to set the GST_PLUGIN_SCANNER environment variable if your setup is unusual. This should normally not be required though.
<mup> PR snapd#2451 opened: tests: add check to ensure that we get the version number <Created by mvo5> <https://github.com/snapcore/snapd/pull/2451>
<kalikiana_> simon_b: Are you using any of the desktop- parts mentioned here? https://wiki.ubuntu.com/snapcraft/parts
<kalikiana_> Those would set the gstreamer path for you
<simon_b> kalikiana_: I am actually using "desktop/gtk3"
<simon_b> kalikiana_: I opened up the snap out of curiosity and took at look at desktop-launch
<simon_b> kalikiana_: In there is a line "export GST_PLUGIN_SYSTEM_PATH=$SNAP/usr/lib/$ARCH/gstreamer-1.0"
<simon_b> I don't understand what the issue is, the plugins are there in the snap but gstreamer can't locate them
<didrocks> ogra_: so, I restarted my pi2, I don't have an i2c interface.
<didrocks> ogra_: pi2                   16.04-0.17    29   canonical  -
<didrocks> ogra_: and then, I can't upgrade it due to the network issue we discussed longely here and on the ML
<didrocks> did you enable it in a later gadget snap?
<mup> PR snapd#2447 closed: many: fixes cherry-picked for the 2.19.1 release <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2447>
<mup> PR snapd#2452 opened: Fix AppArmor rules <Created by bergotorino> <https://github.com/snapcore/snapd/pull/2452>
<mup> PR snapd#2083 closed: cmd/snap: generate account-key revocation requests <Created by cjwatson> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2083>
<mup> PR snapd#2453 opened: store: retry user info request <Created by stolowski> <https://github.com/snapcore/snapd/pull/2453>
<kalikiana_> Hmmm installing a devmode snap without --devmode seems to wrongly suggest it doesn't exist
<mup> Bug #1649237 opened: snap install without devmode claims it doesn't exist <Snappy:New> <https://launchpad.net/bugs/1649237>
<mup> PR snapd#2440 closed: release: 2.19 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2440>
<mup> PR snapd#2420 closed: overlord/snapstate: setup/remove aliases as we link/unlink snaps <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2420>
<mup> PR snapd#2454 opened: client: only allow Dangerous option in InstallPath <Created by chipaca> <https://github.com/snapcore/snapd/pull/2454>
<om26er> Is there an "official" daily image of Ubuntu Core for kvm ?
<ogra_> ogra@pi3:~$ grep i2c /boot/uboot/config.txt
<ogra_> dtparam=i2c_arm=on
<ogra_> dtparam=i2c_vc=on
<ogra_> ogra@pi3:~$ ls /dev/i2c-*
<ogra_> /dev/i2c-0  //dev/i2c-1
<ogra_> ogra@pi3:~$
<ogra_> didrocks, ^^^^
<ogra_> (i'm on vacation btw)
<ogra_> the pi2 should be identical
<ogra_> didrocks, if the pi2 is different please note so in a bug and assign to me
<ogra_> om26er, http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ is as official as it gets atm, if you wait for actual cdimage builds, foundations is supposed to set them up, ask infinity where that stands
<om26er> ogra_: ok, good to know.
<om26er> ogra_: can you tell who is the console-conf person of contact ?
<renato__> mvo, jdstrand, could you approve ubuntu-docviewr-app ?
<renato__> mvo, jdstrand, looks like something has landed in the store. Now the package is not rejected anymore but it still need manual approval
<mup> PR snapd#2451 closed: cmd: fix mkversion.sh and add regression test <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2451>
<didrocks> ogra_: the parameters are there, but snap interfaces shows no i2c interface
<didrocks> ogra_: so, it's between the gadget snap or snapd
<didrocks> (crazy that nobody even try a snap interfaces to ensure things are working)
<didrocks> on a bug report for this, I opened one a month ago and referenced it on the feedback email
<mup> PR snapd#2455 opened: many: implement alias command <Created by pedronis> <https://github.com/snapcore/snapd/pull/2455>
<mup> PR snapd#2456 opened: WIP: Implement 'shadow' interface for mounting snap folders <Created by kalikiana> <https://github.com/snapcore/snapd/pull/2456>
<mup> PR snapd#2444 closed: debian: depend on snap-confine at least 2.19 <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2444>
<mup> PR snapd#2457 opened: cmd/snap: reject "snap disconnect foo" <Created by zyga> <https://github.com/snapcore/snapd/pull/2457>
<abeato> ogra_, ping
<mup> PR snapd#2456 closed: WIP: Implement 'overmount' interface for mounting snap folders <Created by kalikiana> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2456>
<mup> PR snapd#2441 closed: debian: add split ubuntu-core-launcher and snap-confine packages <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2441>
<mup> PR snapd#2458 opened: release: 2.19.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2458>
<mup> PR snapd#2459 opened: interfaces/builtin: add iio interface <Created by morphis> <https://github.com/snapcore/snapd/pull/2459>
<mup> PR snapd#2457 closed: cmd/snap: reject "snap disconnect foo" <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2457>
<mup> PR snapcraft#954 opened: pluginhandler: convert to package <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/954>
<jdstrand> renato__: you need a desktop file
<jdstrand> renato__: it looks like revisions 2 and 3 have it. you just need to press the 'release' button
<renato__> jdstrand, yes this is on the rev 2 e 3
<renato__> jdstrand, thanks
<renato__> jdstrand, I did not find a way to cancel the review
<jdstrand> roadmr: hi! I asked a little while ago about a store pull for r809. it seems we are still at r798. is this still queued up?
<roadmr> jdstrand: let me check
<jdstrand> renato__: fyi, ubuntu-calculator approved
<renato__> thnaks
<roadmr> jdstrand: 809 should have been deployed last week; sorry, it was a bit hectic so I didn't tell you about it :(
<jdstrand> hmm
<jdstrand> ok
<jdstrand> that calculator one was older
<jdstrand> roadmr: thanks!
<roadmr> \o/ :)
<jdstrand> mvo: hi! fyi I took care of ubuntu-docviewr-app
<mup> PR snapd#2460 opened: tests: remove snap-confine/ubuntu-core-launcher after the tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/2460>
<mup> PR snapd#2423 closed: overlord,overlord/snapstate: implement snapstate.Alias <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2423>
<mup> PR snapd#2461 opened: tests: check if snap-confine --version is unknown <Created by zyga> <https://github.com/snapcore/snapd/pull/2461>
<ondra> ogra_ hi
<roadmr> jdstrand: hey a question about classic, if you have a sec to help us clarify
<mvo> jdstrand: thanks a bunch
<mup> PR snapd#2462 opened: cmd/snap-confine: allow content interface mounts <Created by zyga> <https://github.com/snapcore/snapd/pull/2462>
<mup> PR snapd#2460 closed: tests: remove snap-confine/ubuntu-core-launcher after the tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2460>
<mup> PR snapd#2463 opened: tests: remove ppa:snappy-dev/image again <Created by mvo5> <https://github.com/snapcore/snapd/pull/2463>
<mup> Bug #1649331 opened: Disconnecting ubuntu-app-platform doesn't really work until a reboot <Snappy:New> <https://launchpad.net/bugs/1649331>
<niemeyer> jdstrand: Hey, can you please have a second look on #2413 when you have a moment?
<niemeyer> jdstrand: We discussed a few changes which are hopefully fine with you as well
<jdstrand> niemeyer: yes, plan to do that in a few minutes. discussing the content sharing rw issue with zyga atm
<mup> PR snapcraft#953 closed: sources: refactor base sources into new package <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/953>
<mup> PR snapcraft#955 opened: sources: convert to package <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/955>
<mup> PR snapd#2464 opened: cmd/snap: mock terminal.ReadPassword instead of using /dev/ptmx <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2464>
<julio__> hi there, could anyone tell me what is the easiest way to execute a startup script in Ubuntu Core 16?
<kyrofa> julio__, package what you want to run as a snap, and you can declare the script in question to be a service which snapd will run
<julio__> huh, will I be able to set the system time using hwclock?
<jdstrand> niemeyer, z: fyi, 2413 reviewed
<jdstrand> tab-complate fail
<jdstrand> complete*
<kyrofa> julio__, I suspect you can as long as you utilize the time-control interface
<julio__> kyrofa, thank you.
<julio__> kyrofa, next question: how could I override the /etc/issue file since the system is readonly? I notice that some of the files in the /writable partition are copied over but what process determines which files get copied over?
<jdstrand> niemeyer: hey, so on https://github.com/snapcore/snapd/pull/1613 I *think* you gave a +1 since you gave a LGTM earlier with some questions, which I answered, which you responded to today as ok/let's not block.
<mup> PR snapd#1613: interfaces/builtin: add dbus interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
<jdstrand> niemeyer: I'm going to merge from trunk and then resubmit and see how the tests do
<jdstrand> niemeyer: is there anything more you need from this?
<jdstrand> niemeyer: note that I'd like to answer sabdfl's question on the status of this in the most positive way possible since it has been dragging (for various understandable reasons)
<jdstrand> niemeyer: also, there is an open question for you in https://github.com/snapcore/snapd/pull/2450
<mup> PR snapd#2450: interfaces: add network-namespace-control (LP: #1624675) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2450>
<mup> PR snapd#2413 closed: interfaces/apparmor: allow access to core snap <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2413>
<hol> Hi guys, noob question here. I just installed the ubuntu core on my raspberry, no monitor, no keyboard available. Can I log on via ssh? what is the user/password?
<niemeyer> jdstrand: Yeah, I'm hoping we can get this in tomorrow
<niemeyer> jdstrand: No blockers from me.. invited pedronis for a quick look today
<kgunn> yo, i've just installed an img for Rpi3, i have a keyboard and monitor...is it expected to see "a start job is running for Raise network interfaces (time/5min)
<hol> well, it's running now for 1,5h and still: ssh ubuntu@192.168.178.54 ubuntu@192.168.178.54's password: Permission denied, please try again.
<hol> password: ubuntu
<jdstrand> niemeyer: fantastic!
<jdstrand> niemeyer: it be great to get the network-namespace-control one in too (already has a +1 from zyga). that one has the open question on if that should be its own interface or not
<davmor2> hol: you login with the user key you set up in console-conf on first boot of the device not ubuntu
<mup> PR snapcraft#956 opened: tests: idempotent store installs <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/956>
<niemeyer> jdstrand: Sounds good, will try to have a look later today still
<jdstrand> niemeyer: awesome. if it works better for you tomorrow morning, that's fine with me (I'm here all week)
<mup> PR snapd#2463 closed: tests: remove ppa:snappy-dev/image again <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2463>
<mup> Bug #1649399 opened: 'daemon: dbus' is incomplete <Snappy:New> <https://launchpad.net/bugs/1649399>
<popey> how does one install core over ubuntu-core?
<popey> http://paste.ubuntu.com/23620875/
<kyrofa> popey, blow away snapd :P
<popey> how?
<popey> and is that serious, given the smiley?
<kyrofa> popey, unfortunatey, yes, I'm serious
<popey> wait, lose every snap I have installed?
<popey> alan@gort:~$ snap list | wc -l
<popey> 64
<kyrofa> popey, that's the only way *I* know of anyway. You can wait for the snapd folks to respond though
<popey> ok
<popey> ( following your blog post and stuck at the "Also verify that you have the core snap installed, not ubuntu-core:" step
<kyrofa> popey, indeed, I had to blow everything away to get core
<kyrofa> niemeyer, is there any way around that?
<kyrofa> Some nifty way to convince snapd to remove ubuntu-core and install core instead?
<niemeyer> popey, kyrofa: Let's please not say that
<niemeyer> kyrofa: Yes, there is.. we need to develop the migration between one and the other
<mup> PR snapd#2462 closed: cmd/snap-confine: allow content interface mounts <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2462>
<niemeyer> kyrofa: If you know somebody with knowledge of snapd internals that could be motivated enough to tackled that sooner rather than later, please let me know! ;-)
<kyrofa> niemeyer, automatic is one thing. Is there no way to do it manually?
<niemeyer> kyrofa: No.. we need to update ubuntu-core.. that's the proper way to do that sooner rather than later.. hopefully this week
<kyrofa> Alrighty
<mup> PR snapd#2458 closed: release: 2.19.1 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2458>
<mup> PR snapd#2461 closed: tests: check if snap-confine --version is unknown <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2461>
<niemeyer> kyrofa: The update is really not that hard.. the problem is everything else
<kyrofa> Yeah if they were updated in tandem no one would even notice
<niemeyer> kyrofa: That was the plan.. but reality loves surprises
<popey> niemeyer: kyrofa so the short answer is "wait"?
<kyrofa> popey, for switching from ubuntu-core to core, yeah sounds like it. Core is used on new installs though
<popey> ok
<jdstrand> fwiw, I installed core, then disabled ubuntu-core, then uninstalled ubuntu-core. however, I don't claim that will dtrt with already installed apps. I only had a couple installed so I uninstalled them and reinstalled
<jdstrand> so, ymmv
<kyrofa> jdstrand, did you have to disable ubuntu-core first?
<kyrofa> jdstrand, popey's paste showed an error when initially installing core
<jdstrand> "then disabled ubuntu-core"
<jdstrand> yes
<kyrofa> jdstrand, to clarify: you said you installed core, then disabled ubuntu-core. However, popey's paste indicated that installing core in the first place would fail
<jdstrand> I was told that wasn't technically supposed to work, but at the time I did, it did
<kyrofa> jdstrand, so did you actually need to do those steps the other way around?
<kyrofa> Ah
<jdstrand> snap install core ; snap disable ubuntu-core ; snap remove ubuntu-core
<jdstrand> that is what I did ^
<kyrofa> Indeed, that appears to no longer work
<popey> okerror: cannot disable "ubuntu-core": snap "ubuntu-core" cannot be disabled
<jdstrand> I make no claims that that will dtrt with your interface connections or policy. I suspect it will not
<niemeyer> popey: Yes, let's please not recommend anything else.. it'll be unnecessary churn.. we'll fix this soon enough
<popey> ok
<jdstrand> well, there you go. wait :)
<cholcombe> i'm getting permissions denied on my strict enforced snap with the [home] plug.  I'm telling it to access my home directory .config file and it's failing.  Are . files not allowed?
<kyrofa> cholcombe, indeed, last I heard, dot files directly in $HOME weren't allowed (to prevent, say, SSH keys from being stolen), but dot files elsewhere are okay
<cholcombe> kyrofa, Alright is there an interface that allows me to give it access to /etc say?
<kyrofa> cholcombe, I don't believe so. Snaps are supposed to be self-contained. If they have configuration files, they're contained within it somewhere
<cholcombe> that won't work.  the configuration files i need are generated at runtime by a charm that connects to other services
<kyrofa> cholcombe, can you explain what you're trying to accomplish?
<cholcombe> kyrofa, https://github.com/cholcombe973/preserve is the app i'm building.  It connects to several different backends, Ceph, Gluster, Amazon, etc.  It won't know that config information until the preserve charm makes a config file for it
<kyrofa> cholcombe, do you have any control over where the charm places the config?
<cholcombe> yup
<cholcombe> total control
<cholcombe> from what i've found i can't actually write into the snap
<kyrofa> cholcombe, indeed, snaps are squashfs images (by definition read-only)
<kyrofa> cholcombe, however, there are some well-defined places they can read/write
<cholcombe> kyrofa, do tell :)
<kyrofa> cholcombe, this might be faster: https://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data
<cholcombe> ah there we go.  /var/snap
<kyrofa> cholcombe, note that /var/snap is the root for all snaps. You're looking for /var/snap/<snapname>/current, probably
<cholcombe> kyrofa, yeah
<kyrofa> cholcombe, soon you'll be able to just have the charm configure the snap directly (using `snap set key=value`)
<kyrofa> Assuming that's something in which you're interested
<cholcombe> kyrofa, that'll be sweet
<cholcombe> so it'll just the config info from env data?
<kyrofa> cholcombe, no, calling `snap set` would run a hook contained within your snap, which could then act upon those values
<cholcombe> oh i see. yeah that might be fine also
<kyrofa> cholcombe, like this: https://github.com/snapcore/snapd/wiki/hooks#configure
<cholcombe> kyrofa, yeah i think that would be ok
<kyrofa> cholcombe, anyway, hopefully you have a way forward?
<cholcombe> kyrofa, yeah i think i can work it out from here.  thanks !
<kyrofa> Excellent, any time :)
<mup> PR snapcraft#955 closed: sources: convert to package <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/955>
<mup> PR snapcraft#957 opened: sources: refactor base sources into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/957>
<cholcombe> kyrofa, crap i just realized something.  for this application to do backups it's going to need to be able to read the entire filesystem potentially.  It also needs write access to potentially anywhere so that it can do a backup restore
<kyrofa> cholcombe, I'm not sure we have an interface that would cover such a use-case. jdstrand might know more
<cholcombe> kyrofa, so i'll have to stick to dev mode for now then
<kyrofa> cholcombe, indeed. Your snap is not the only one that needs such things-- shells, for example, are limited without that ability as well
<cholcombe> yeah
<jdstrand> cholcombe, kyrofa: there is no interface for that. that'll need to use either devmode or classic
<cholcombe> jdstrand, ok i'll stick to devmode for awhile
<jdstrand> niemeyer: fyi, https://github.com/snapcore/snapd/pull/1613 still has you requesting changes. I think that should be 'approved' now based on our earlier conversation. then just need pedronis
<mup> PR snapd#1613: interfaces/builtin: add dbus interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
#snappy 2016-12-13
<luk3yx> Does anyone know if I can publish an unofficial MT snap based on the snapcraft.yaml in the snappy playpen?
<luk3yx> (By MT I meant Minetest)
<luk3yx> I have a question about the snappy playpen licensing.
<mup> PR snapcraft#954 closed: pluginhandler: convert to package <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/954>
<mup> PR snapcraft#956 closed: tests: idempotent store installs <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/956>
<liuxg> can anyone tell me what are really there in the Ubuntu Core OS? a Ubuntu core OS has kernel, Ubuntu Core OS, Gadget and snaps. thanks
<dholbach> hey hey
<didrocks> good morning dholbach!
<dholbach> salut didrocks
<mup> PR snapd#2465 opened: snap: show apps in `snap info` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2465>
<venkat_> JOIN
<venkat_> I tried to create a kernel snap for dragonboard
<venkat_> using snapcraft.yaml
<venkat_> It is created by snapcraft command
<venkat_> then I tried to create a gadget snap for my board
<venkat_> by using gadget.yaml and snap.yaml
<venkat_> here also created a gadget snap
<venkat_> but when try to create a ubuntu image it is showing the error like
<venkat_> error: cannot decode model assertion eragon.model: assertion content/signature separator not found
<venkat_> I just created a .json file for my board and used $ cat eragon-model.json | snap sign -k default &> eragon.model command
<venkat_> It asked me to enter password, entered then succeed
<mup> PR snapd#2466 opened: debian: fix Pre-Depends on dpkg <Created by mvo5> <https://github.com/snapcore/snapd/pull/2466>
<venkat_> But When I use $ sudo /snap/bin/ubuntu-image -c devmode -o eragon410-SDtest.img eragon.model command for image creation, it fails and showing above error
<venkat_> Do you the reason Why?
<venkat_> Please  update if knows
<eyelash> is it not possible for a snap in devmode to access programs outside the snap?
<didrocks> eyelash: hum, there are some tricky way to do, but you can't execute other snaps though (there is a bug for that)
<eyelash> didrocks: but if it's installed as a deb it should be possible?
<didrocks> eyelash: yeah, if you add the correct LD_LIBRARY_PATH yourself (as the hostfs is in /var/lib/snapd/hostfs/)
<eyelash> I was trying to create a snap package for the Meson build system and it obviously needs to access the compilers that are installed on the system
<didrocks> yeah, I guess some people asked for a compiler interface though
<didrocks> that will be great to have that, I'm pretty sure a bug was filed, but if you want to double check (and +1 on this)
<eyelash> didrocks: oh nice
<eyelash> I could not find anything with the keyword 'compiler'
<eyelash> seems to be this bug: https://bugs.launchpad.net/snappy/+bug/1618004
<mup> Bug #1618004: Need a classic-bin interface to see classic binaries <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1618004>
<mup> PR snapd#2467 opened: many: improve support for trusty <Created by mvo5> <https://github.com/snapcore/snapd/pull/2467>
<mup> PR snapcraft#958 opened: Add source name to error message <Created by tsdgeos> <https://github.com/snapcore/snapcraft/pull/958>
<tsdgeos> i think i need to adapt tests for this one
<mup> PR snapd#2466 closed: debian: fix Pre-Depends on dpkg <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2466>
<tsdgeos> btw could someone press the "merge" button for https://github.com/snapcore/snapcraft/pull/951 ?
<mup> PR snapcraft#951: snapcraft plugins -> snapcraft list-plugins <Created by tsdgeos> <https://github.com/snapcore/snapcraft/pull/951>
<mup> PR snapd#2468 opened: tests: add debug output to see why autopkgtests are failing <Created by mvo5> <https://github.com/snapcore/snapd/pull/2468>
<mup> PR snapd#2374 closed: snap: tweak snap install output as designed by Mark <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2374>
<grome55> hi
<grome55> hi i request your help to guide me to install snap on debian
<mup> PR snapd#2469 opened: interfaces: upower-observe: refactor to allow snaps to provide a slot <Created by morphis> <https://github.com/snapcore/snapd/pull/2469>
<mup> PR snapd#2455 closed: many: implement alias command <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2455>
<tsdgeos> sergiusens: i don't understand what you mean with "Please also remember to affect the bug this fixes"
<mardy> t1mp: hi! The ubuntu-app-platform snap, in which distro should it be built? xenial?
<kalikiana_> mardy: xenial with overlay
<kalikiana_> See also https://developer.ubuntu.com/en/blog/2016/11/16/snapping-qt-apps/
<mardy> kalikiana_: thanks!
<sergiusens> tsdgeos all PRs are required to have a bug on launchpad per https://github.com/snapcore/snapcraft/blob/master/CONTRIBUTING.md
<tsdgeos> sergiusens: nice way to make me not fix small issues like this :D
<tsdgeos> aaaaaaaaaand we live in the 1960
<tsdgeos>  E501 line too long (84 > 79 characters)
<tsdgeos> oh noes it won't fit in my 800x600 screen
<mup> PR snapd#2467 closed: many: improve support for trusty <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2467>
<mup> Bug #1649569 opened: Make plugin/source error reporting a bit more useful <Snappy:New> <https://launchpad.net/bugs/1649569>
<tsdgeos> sergiusens: d1ad166365dfc2b934d2f28bebe31a99b1dd332f didn't have a LP bug linked :o
<mardy> tsdgeos: revert it! ;-)
<mup> PR snapd#2470 opened: notifications, daemon: kill the unsupported events endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/2470>
<mardy> I'm getting this error after running snapcraft to build ubuntu-app-platform: E:Unable to correct problems, you have held broken packages.
<mardy> any idea on how to debug this?
<mardy> I don't have any held packages in my system
<Chipaca> maybe "you have held broken packages" means snapcraft refuses to work with anybody that has ever handled a broken package
<Chipaca> :-)
<mardy> Chipaca: still, this is a rather clean installation...
<Chipaca> mardy, I'll let people that know snapcraft give you serious answers now
<mardy> Chipaca: thanks :-)
<Chipaca> anybody know what http://autopkgtest.ubuntu.com/ is running?
<mup> PR snapd#2415 closed: overlord/ifacestate: no interface checks if no snap id <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2415>
<abeato> ogra_, hi, where could I find the sources for uboot used for rpi3?
<ogra_> abeato, they are the upstream sources with the patch thats in the gadget tree
<abeato> ogra_, is that lp:~snappy-dev/snappy-hub/snappy-systems ?
<ogra_> abeato, the gadgets moved to https://github.com/snapcore
<ogra_> https://github.com/snapcore/pi3-gadget actually
<abeato> ogra_, oh, ok
<abeato> ogra_, I am trying to do boot from USB
<abeato> ogra_, the issue I see is that uboot is not finding the right enviroment and it tries to use the default
<ogra_> note that the ROM change you have to do for that is irreversible ... afaik you wont be able to switch your Pi back to Sd onyl in case you care
<abeato> ogra_, it apparently cannot load uboot.env
 * abeato does not core :)
<abeato> *care
<ogra_> right, that is the patch ....
<ogra_> in the prebuilt subdir in above tree
<ogra_> you need to tell the config to use uboot.env instead of uEnv.txt
<abeato> ogra_, ok... how do you build uboot btw?
<ogra_> uff... i havent done it in ages ... make config-rpi3 or some such and then just make ... with the armhf cross compiler installed
<abeato> ogra_, will give that a try, thanks!
<ogra_> (i would have to look up the exact lines upstream as well ... )
<abeato> nv
<ogra_> ppisati can surely help you too ...
 * ogra_ goes back into vacation mode :)
<madprops> besides games, are there other kinds of applications that would benefit from delta updates?
<abeato> enjoy, sorry :)
<ogra_> why sorry, i dont need to answer :)
<abeato> that's true too ;)
<ogra_> madprops, why would only games benefit ? everything benefits from tiny downloads ;)
<madprops> you should be drinking a pina colada and ignoring me :(
<ogra_> haha
<madprops> but yeah i think video games are the biggest forms of this
<madprops> and this is handled by systems like steam
<ogra_> well, if you have a system that is competely built from snaps and upgrade 50 of them it sums up :)
<ogra_> and there are browsers ... office suites ... theme packs ... language packs ... the yall are huge by default
<ogra_> *they all
<madprops> well not really when 50 of  those download the same libs
<madprops> just saying
<ogra_> they wont ...
<ogra_> (becaue they hopefully use the content sharing interface for the libs ;) )
<ogra_> *because
<madprops> of you're going to do that
<madprops> why not just have a good unviersal package manager
<ogra_> erm ... that is what snap is
<ogra_> just a lot more secure
<madprops> hmm
<ogra_> (securer enough that you wont have to worry that your webcam that runs snappy becomes part of a botnet ;) )
<ogra_> *secure
<madprops> well language packs and stuff are already their own packages
<madprops> i don't know about the security, except for the isolation, but i think it's biggest plus is it's convenience
<madprops> to developers
<ogra_> debs give every package maintainer 100% root on your box
<madprops> well and users (except for bigger download sizes)
<ogra_> there isnt much security in them beyond the fact that you should use a trusted archive
<ogra_> as soon as you use a package from a PPA or one you download from a website, the person owning that package has full root access to your system
<ogra_> snaps fix this
<madprops> hmm
<madprops> but
<madprops> what if it's an application designed to make system changes
<madprops> how is it going to do them without root access
<ogra_> then it uses a snappy interface to talk to the system side ...
<ogra_> which will require your authorization for critical bits
<ogra_> by design a snap can not do any harm unless you as the system owner explicitly allow it to
<madprops> "snappy interface" this is sounding like it's going to control the system a lot ala systemd
<ogra_> well, a snap runs in a sandbox ... an interface is the outside connection to other snaps or the system for your snap
<madprops> but if i don't run a normal application with sudo .. how does it have sudo powers?
<madprops> root powers
<ogra_> say you have a music player app you snap ... it wouldnt be able to play any sound without you allowitn to access the interface the pulseaudio snap provides
<mup> PR snapcraft#892 closed: Catch PermissionError when attempting to replace contents in a readonly file. (LP: #1640305) <Created by larryprice> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/892>
<madprops> that sounds terrible
<madprops> like every application that controls sound has to ask for permission first
<ogra_> and why is that terrible ?
<madprops> something as basic as playing sound
<ogra_> (you only allow it once at package install time indeed)
<madprops> ok so the permission is implied by installing it
<madprops> a la android permissions
<ogra_> more like IOS
<ogra_> but yeah, similar concept
<bossie__> Hi! Any tips on where I can get info on the different Snap "types" -> type: app | core | gadget | kernel ?
<bossie__> Either I'm blind or the docs arern't that clear on it
<ogra_> https://docs.ubuntu.com/core/en/
<sergiusens> ogra_ I think android moved to this model too since 5.0
<mup> PR snapcraft#958 closed: Add source name to error message <Created by tsdgeos> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/958>
<mup> Bug #1649569 changed: Make plugin/source error reporting a bit more useful <Snapcraft:Fix Committed by aacid> <https://launchpad.net/bugs/1649569>
<ogra_> bossie__, under "build a device"
<ogra_> and very specific https://docs.ubuntu.com/core/en/guides/build-device/board-enablement
<ogra_> sergiusens, ah ... havent used android for so long :P
<bossie__> ogra, thanks! I've been searching under the snapcraft.io docs.... :/
<tsdgeos> sergiusens: what do you think about https://github.com/snapcore/snapcraft/pull/951 ?
<mup> PR snapcraft#951: snapcraft plugins -> snapcraft list-plugins <Created by tsdgeos> <https://github.com/snapcore/snapcraft/pull/951>
<sergiusens> tsdgeos let me comment there
<tsdgeos> stupid github should send comments to the address i made the commit with and not to my main github address
<tsdgeos> meh
<mup> PR snapd#2454 closed: client: only allow Dangerous option in InstallPath <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2454>
<mup> PR snapd#2470 closed: notifications, daemon: kill the unsupported events endpoint <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2470>
<pbek> tsdgeos: I guess they can't because they haven't confirmed that you own that email address ;)
<tsdgeos> pbek: they have
<tsdgeos> since it's one of my confirmed email addresses in github
<tsdgeos> just not the main one
<pbek> tsdgeos: didn't know that they were able to do that... maybe you should open a feature request...
<mup> PR snapd#2464 closed: cmd/snap: mock terminal.ReadPassword instead of using /dev/ptmx <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2464>
<tsdgeos> pbek: do they accept feature requests?
<pbek> tsdgeos: I've no idea to be frank...
<pbek> GitLab does...
<sergiusens> tsdgeos they do; I have made many and at least received replies (some are implemented).
<sergiusens> tsdgeos you can configure email per project under your personal settings
<tsdgeos> sergiusens: Notifications -> Custom routing ?
<bossie__> Anyone know of a snap or mechanism which will allow my snap to access a USB drive plugged into my device? - Ubuntu Core Pi 2 environment
<mup> PR snapcraft#951 closed: snapcraft plugins -> snapcraft list-plugins <Created by tsdgeos> <Closed by tsdgeos> <https://github.com/snapcore/snapcraft/pull/951>
<sergiusens> tsdgeos I think that's the one; Chipaca gave me the wisdom, he might recall better
<tsdgeos> sergiusens: that looks like what i'd like, but i only have one organization there, (which is not canonical or ubuntu) so doesn't seem to be per project sadly :/
<Chipaca> I did nothing of the sort!
 * Chipaca reads about it
<Chipaca> ah! I don't remember it being called custom routing, let me check
<Chipaca> yep, that's the one
<Chipaca> tsdgeos, AFAIK you need to be a member of the organization
<Chipaca> i.e. it's per org
<tsdgeos> meh
<Chipaca> which makes sense to me
<Chipaca> I'd say something about free software web services, but i'd sound bitter
<mup> PR snapcraft#959 opened: Make plugins be an alias of list-plugins <Created by tsdgeos> <https://github.com/snapcore/snapcraft/pull/959>
<kyrofa> bossie__, the snap in question needs to use the removable-media plug
<kyrofa> madprops, ogra_ FYI android nowadays prompts the first time the app requests said feature instead of at install time
<madprops> kyrofa, that could be annoying maybe
<kyrofa> I quite like it. As a side effect, I can deny it
<kyrofa> So now I can use an app minus a few features if I don't want to grant the permissions
<kyrofa> madprops, note that it doesn't prompt every time, just the first time
<madprops> yeah denying certain features is cool
<bossie__> thanks kyrofa I'll check it out
<mup> PR snapd#2471 opened: interfaces: add new boot-config interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/2471>
<mup> PR snapd#2472 opened: tests: update custom core snap with the freshly build snap-confine <Created by mvo5> <https://github.com/snapcore/snapd/pull/2472>
<mup> Bug #1625805 changed: dragonboard: history daemon dereferences a rogue pointer <Canonical System Image:Fix Committed> <history-service (Ubuntu):Fix Committed by boiko> <linux (Ubuntu):Invalid by p-pisati> <https://launchpad.net/bugs/1625805>
<Riotela> I am on Arch Linux and wondering if I am supposed to see http://sprunge.us/ePQQ (snapd.refresh.service fails, Dec 13 19:07:28 sedric snap[3541]: - Download snap "ubuntu-core" (423) from channel "stable" (cannot authenticate to snap store: Provided email/password is not correct.))
<mup> PR snapcraft#947 closed: Add 'aliases' support to 'apps' <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/947>
<mup> PR snapd#2473 opened: overlord,overlord/snapstate: implement snapstate.Unalias by generalizing the "alias" task <Created by pedronis> <https://github.com/snapcore/snapd/pull/2473>
<Seblai> hi everyone. I would like to know if anyone has a link to share, tutorial, or reference on to how to develop a snap for rpi.GPIO. Basically, how to import the plugin.. thanks!!!
<kyrofa> Seblai, no example that I know of, but there is a gpio interface described here: https://github.com/snapcore/snapd/wiki/Interfaces#gpio
<cachio> I am trying to access to dbus from a python script in my snap
<cachio> and I am getting -> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Failed to connect to socket /var/run/dbus/system_bus_socket: Permission denied when I do bus = dbus.SystemBus(mainloop=DBusGMainLoop())
<cachio> any idea how to fix it?
<mup> PR snapd#2378 closed: interfaces: misc openstack snap enablement <Created by javacruft> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2378>
<jdstrand> pedronis: hey, wondering if you'll have a chance to review https://github.com/snapcore/snapd/pull/1613 ? (I'm told that it needs one more review and you were asked to do it. please correct me if I'm wrong)
<mup> PR snapd#1613: interfaces/builtin: add dbus interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
<jdstrand> niemeyer: hi! friendly reminder about my open question to you on https://github.com/snapcore/snapd/pull/2450
<mup> PR snapd#2450: interfaces: add network-namespace-control (LP: #1624675) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2450>
<niemeyer> jdstrand: Thanks for the reminder
<pedronis> jdstrand: I was told to look a it
<pedronis> at
<jdstrand> pedronis: ack, I'll leave you to it then
<jdstrand> niemeyer: note, the flurry of activity surrounding the testsuite failure in 2450 was mvo and I discovering a test infrastructure issue with the recent snap-confine merge (changes to snap-confine from PRs isn't getting properly applied to all snaps images)
<jdstrand> niemeyer: he's working on that
<popey> is there a store problem right now? I am trying to setup a device (pi2) and it's just sat at "Contacting store..." after I enter my email address.
<jdstrand> niemeyer: also, I just referenced you in a couple (few?) reviews requesting your input on the name of the interface
<jdstrand> niemeyer: (just within the last couple hours)
<popey> wow, finally finished... that console setup takes an _age_
<niemeyer> jdstrand: Thanks for the poke
<niemeyer> jdstrand: I'm not sure it makes much sense to have network-namespace-control separated, as you point out there
<niemeyer> jdstrand: The question is this: what are we protecting against?
<niemeyer> jdstrand: Can someone with network-control re-reoute traffic from other parties inside the system?
<niemeyer> jdstrand: If so, we're just adding complexity for little gain.. network-control already allows abuse regardless, and network-namespace-control wouldn't work on its own
<niemeyer> jdstrand: If network-namespace-control could work on its own, without network-control, then there might be some gain
<niemeyer> jdstrand: In other words, if we could give some the ability to _just_ create a namespace, without being able to touch the network otherwise, then that might be justifiable
<niemeyer> jdstrand: Off for some exercising.. back later
<jdstrand> niemeyer: we can create _just_ the namespace, but then we can't configure it without network-control
<jdstrand> niemeyer: based on your comments, I'm going to put it in network-control and circle back. if I need to undo it, that's fine. I prefer it in network-control after working with it for a bit
<jdstrand> niemeyer: thanks for the feedback! :)
<pedronis> jdstrand: does that dbus branch has a +1 from tyler?
<jdstrand> pedronis: not formally. I know he looked at it at one point
<pedronis> jdstrand: did somebody review the snippets? I was asked to look at it, but IÂ generally don't/cannot review those
 * pedronis is a bit confused
<jdstrand> pedronis: Gustavo and Zygmunt looked at them. I'll ask tyhicks to look at the security policy. I think Gustavo just wanted to make sure it made sense code wise
<jdstrand> tyhicks: can you look at the security policy in https://github.com/snapcore/snapd/pull/1613 ?
<mup> PR snapd#1613: interfaces/builtin: add dbus interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
<jdstrand> tyhicks: actually, nm, I forgot you looked at that once
<jdstrand> tyhicks: meh, I forgot, you looked at the proposal, not the implemented code.
<jdstrand> tyhicks: so, can you mind again and take a quick peek at the security policy? we can chat on irc about the policy if you have questions
<mup> PR snapd#2471 closed: interfaces: add new boot-config interface <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2471>
<tyhicks> jdstrand: what do you mean by "snapd does not allow ###DBUS_NAME### to end with '-[0-9]+', so this is ok."?
<pihole> New to snapcraft: How do you get a simple daemon to start automatically?
<tyhicks> jdstrand: if snapd doesn't allow it, what good is allowing it in the policy?
<kyrofa> pihole, all you have to do is declare it as a daemon in the YAML
<kyrofa> pihole, do you have a snapcraft.yaml you could share?
<pihole> Sure hang on
<pihole> help
<pihole> OK, not sure how to format the code in here
<pihole> d
<tyhicks> jdstrand: on line 83, the comment says "allow unconfined clients talk to ###DBUS_NAME### on classic" but the rule doesn't contain ###DBUS_NAME###
<pihole> kyrofa: apps: dnsmasq: command: bin/dnsmasq daemon: simple plugs: - network - network-bind - network-control
<kyrofa> pihole, yeah, use pastebin.ubuntu.com
<tyhicks> jdstrand: same with the comment/rule on line 125
<tyhicks> (that one is less worrisome because the rule specifies the peer label)
<pihole> kyrofa: http://pastebin.ubuntu.com/23625639/
<kyrofa> pihole, yeah that looks fine-- the `daemon: simple` tells snapd to run it as a daemon
<kyrofa> pihole, are you not seeing that behavior? Is the daemons perhaps erroring out?
<pihole> kyrofa: I checked journalctl -u and it shows it starts, but then stops shortly after.  Also tried it without the custom config file.  Load up fine either way when done manually
<jdstrand> tyhicks: re '-[0-9]+', see the regex at line 218
<pedronis> jdstrand: added some comments
<jdstrand> tyhicks: what is happening is that a snap developer can request org.foo. snapd will create rules for org.foo and org.foo-[1-9]...
<jdstrand> tyhicks: therefore we do not allow a developer to request org.foo-1
<tyhicks> jdstrand: got it, thanks
<jdstrand> tyhicks: line 83 needs to be updated
<jdstrand> tyhicks: well, really the comment is correct from a certain perspective, but I'll make it clear
<jdstrand> pedronis: thanks!
<kyrofa> pihole, perhaps it's not a simple daemon?
<kyrofa> pihole, does it fork?
<pihole> kyrofa: good point.  Maybe I'll just try that.
<pihole> kyrofa: thank you very much
<kyrofa> pihole, of course
<mup> PR snapcraft#957 closed: sources: refactor base sources into module <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/957>
<Mritunjai> Hi All
<tyhicks> jdstrand: thanks for clarifying the comments
<tyhicks> jdstrand: my final concern is that the rules on lines 86 and 94 essentially allow the snap to communicate with any unconfined application
<mup> PR snapcraft#960 opened: pluginhandler: install scriptlet support <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/960>
<Mritunjai> I am very new to snappy. My requirement is that i have one app already working for x86 and arm. Now what i want to do is to have the stripped version of my exisitng app and make a snap of it and distribut it to the vendors so that they can play with it. Can anyone please gudie me how to start with the same?
<jdstrand> tyhicks: it can only do it via that interface or path
<jdstrand> tyhicks: the idea is to let this work within a traditional desktop environment (ie, classic)
<jdstrand> tyhicks: so, say have some application that is a deb but knows about rhythmbox. I have a rhythmbox snap installed
<jdstrand> tyhicks: the snap can use either the dbus interface that matches or the dbus path that matches. I was thinking that would make the other side not work so well, but thinking at last about the path one, maybe that should be a rec
<jdstrand> receive
<mup> PR snapcraft#961 opened: sources: refactor local source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/961>
<mup> PR snapd#2473 closed: overlord,overlord/snapstate: implement snapstate.Unalias by generalizing the "alias" task <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2473>
<mup> PR snapcraft#962 opened: sources: refactor bazaar source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/962>
<mup> PR snapcraft#963 opened: sources: refactor deb source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/963>
<jdstrand> tyhicks: did you see my response?
<jdstrand> tyhicks: in case not:
<jdstrand> tyhicks: it can only do it via that interface or path
<jdstrand> tyhicks: the idea is to let this work within a traditional desktop environment (ie, classic)
<jdstrand> tyhicks: so, say have some application that is a deb but knows about rhythmbox. I have a rhythmbox snap installed
<jdstrand> tyhicks: the snap can use either the dbus interface that matches or the dbus path that matches. I was thinking that would make the other side not work so well, but thinking at last about the path one, maybe that should be a receive
<jdstrand> least*
<tyhicks> I didn't see it (I apparently disconnected for a moment)
<jdstrand> tyhicks: I could remove send from those two rules
<jdstrand> I wonder how much it is needed for the interface rule though
<tyhicks> I mean it just depends if the snap is going to be only replying to messages or if it needs to actually send a method_call or signal message
<pedronis> jdstrand: how does things fail if bus or name don't match? you get an connection but it doesn't work?
<jdstrand> tyhicks: we don't know. this is a generic interface. let's think of this in terms of say, talking to download manager
<jdstrand> pedronis: you get too many things matching. see the test for this here: https://github.com/snapcore/snapd/pull/1613/files#diff-c5f8555bf0fa0810f5d9dbd039036112R530
<mup> PR snapd#1613: interfaces/builtin: add dbus interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
<mup> PR snapcraft#964 opened: sources: refactor git source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/964>
<jdstrand> pedronis: in that, the slot offers two well-known names but the plug only plugs one
<jdstrand> pedronis: we want to connect the right ones. that little bit does that
<pedronis> jdstrand: IÂ don't understand what you are saying at all
<pedronis> :)
<jdstrand> pedronis: look at the test
<jdstrand> pedronis: the slotYaml has 'this' and 'that'
<pedronis> the test calls ConnectedPlugSnippet
<pedronis> and gets what you told it to do
<jdstrand> pedronis: look at the plugYaml, it only plugs 'that'
<tyhicks> jdstrand: yeah, I appreciate that it is generic - I just wanted to point out that the rules with send perms grant a lot more than intended and it'd be nice if we could remove the send perms
<jdstrand> pedronis: without this code, things go wrong
<tyhicks> jdstrand: IMO, there's no use in removing the send perms on the interface related rule but not the path related rule
<pedronis> jdstrand: sorry, I don't understand, that tests proves that the code does what you told it to do
<jdstrand> tyhicks: I was thinking the other way around
<pedronis> I don't understand how it relates to the higher levels
<jdstrand> pedronis: ok, let me look at this again. two conversations at once is difficult
<jdstrand> tyhicks: consider the snap has both rules
<jdstrand> tyhicks: then it tries to talk to the session ubuntu-download-manager (udm) that is unconfined
<jdstrand> tyhicks: so, the interface rule allows it to talk to the well-known name (name=udm) using the snap's interface (eg, org.foo)
<jdstrand> tyhicks: wouldn't dbus just reject that rule cause udm doesn't have the org.foo interface?
<barry> hey snappy folks, i'm seeing recent failures autopkgtests of ubuntu-image (both locally and via gh pull request) when trying to build the pc-i386-model.assertion here: https://github.com/CanonicalLtd/ubuntu-image/blob/master/debian/tests/models/pc-i386-model.assertion
<barry> here is a log for example: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-canonical-foundations-ubuntu-image/yakkety/amd64/u/ubuntu-image/20161213_220817_0caf6@/log.gz
<barry> scroll to the bottom.  snap prepare-image can't find the pc-kernel snap on the beta channel
<tyhicks> jdstrand: no, the message will be delivered and it is up to the receiving connection to reject that rule based on the invalid interface
<jdstrand> tyhicks: the path rule is similar. the snap can talk to udm using path=/org/foo. I feel like that is maybe problematic and perhaps it should have the receive rule
<barry> afaict, pi2, pi3, dragonboard, and pc-amd64 all all fine
<barry> just the pc-i386 one is failing.  has something changed here recently?
<tyhicks> jdstrand: many dbus libraries will reject the message but the message is still delivered
<jdstrand> tyhicks: ok, well, then the question becomes if on *classic* that is acceptable
<barry> like, the i386 arch of pc-kernel went away?
<tyhicks> jdstrand: yeah, I agree that's the question
<jdstrand> tyhicks: this is an environment with x11
 * tyhicks nods
<jdstrand> though, this also support system
<jdstrand> how about I remove 'send' and we see how it goes? if it needs to integrate with unity7 then the unity7 interface could gain whatever it needed
<tyhicks> I would prefer that but can't say whether or not 'send' will just have to be added shortly after to make the interface useful in a classic environment
<elfgoh> Can i double confirm that I can't login to the Ubuntu core via password?
<tyhicks> I just haven't profiled enough dbus services to know for sure :/
<elfgoh> i.e., if i connect a monitor, i can't login. I can login via ssh tough
<elfgoh> *though
<jdstrand> tyhicks: we don't have concrete examples for this part of the ruleset
<jdstrand> so, let's remove send and see what happens
<tyhicks> tyhicks: I like the sound of that - it definitely improves the security properties of the policy so I think it is worth waiting and seeing
<mup> PR snapcraft#965 opened: sources: refactor mercurial source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/965>
<pedronis> barry: it's on snapd side, calling the api directly it seems there's no i386 beta kernel anymore in the store
<pedronis> barry: it's *not* on the snapd side
<tyhicks> jdstrand: fyi, this was the crux of the kdbus authors' argument against our fine-grained dbus mediation
<barry> pedronis: that's what i suspected.  do you know if that's intentional?  who owns/owned the i386 kernel snap?
<pedronis> I don't know
<barry> ogra_: perhaps?
<pedronis> it might also be a store bug (wrong channel inheritance)
<jdstrand> tyhicks: hmm?
<tyhicks> jdstrand: they claimed that if a dbus client could send *any* message to a dbus service, that service must be smart enough to reject invalid/unexpected paths, interfaces, and method names
<pedronis> barry: afaict as I get from the api,  there's a kernel in edge, and the same in stable and candidate, but nothing in beta
<pedronis> for i386
<tyhicks> jdstrand: and that filtering out certain values of paths, interfaces, and/or method names in security policy was not worthwhile
<jdstrand> tyhicks: I see. well, obviously we disagree
<tyhicks> yeah
<jdstrand> tyhicks: the same could be said of seccomp
<barry> pedronis: so there is one in stable?  maybe i should just switch the tests over to that.  i suppose at one point they were only available in beta which is why the tests used that.  /me tries
<tyhicks> jdstrand: good point
<jdstrand> it is reducing attack surface
<tyhicks> jdstrand: ok, that was mostly useless knowledge - I'll let you get back to the PR
<tyhicks> :)
<pedronis> barry: yes,  stable and candidate have 44, edge has 48
<pedronis> no beta
<barry> pedronis: if it's in stable, you'd expect it to be in beta too then right?
<pedronis> well it's in candidate
<pedronis> but yes
<pedronis> so as I said might be store issue
<pedronis> worth poking store people
<barry> pedronis: ok, thanks
<pedronis> anyway amd64 has something explicit in beta fwiw
<elfgoh> Is it possible for me to modify the scheduled rebootreboot scheduled to update the system - temporarily cancel with 'sudo shutdown -c'
<elfgoh> "reboot scheduled to update the system - temporarily cancel with 'sudo shutdown -c'"
<cachio> jdstrand, hi, I am creating a tests where I am creating some methods in dbus and I call them from python calls in my snap
<cachio> jdstrand, is it needed for that to create a new interface?
<cachio> jdstrand, the process is the following, first I add policies in /etc/dbus-1/system.d, then register a method to be called
<cachio> then I call this methods with some parameters and this method will spam signals depending on the parameters used.
<cachio> I am doing this to measure dbus performance
<cachio> jdstrand, but I am still getting this error > dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NameHasNoOwner: Could not get owner of name 'com.canonical.kpi.signal': no such name
<cachio> any guess?
<mup> PR snapcraft#966 opened: sources: refactor rpm source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/966>
<pedronis> barry: IÂ poked, seems indeed a glitch, there should be something there
<jdstrand> pedronis: well, it seems something higher is doing the right thing. if I comment out that 'ensure' area and then install a snap with two slots and a slot with one plug, I get the right policy
<barry> pedronis: thanks
<jdstrand> pedronis: I thought I observed different behavior before which is what prompted the test, but I don't recall specifically
<pedronis> jdstrand: nothing higher level consider that method
<pedronis> jdstrand: afaik it will either find too many, or if you are explicit enough
<jdstrand> pedronis: I just mean if I try to snap connect the wrong slot, it doesn't
<pedronis> it connect but things will not work
<pedronis> jdstrand: with what kind of error?
<jdstrand> no error
<pedronis> ?
<pedronis> so the connection is there?
<pedronis> but doesn't work
<jdstrand> pedronis: consider
<jdstrand> snap interfaces
<jdstrand> foo:bar
<jdstrand> meh
<jdstrand> foo: bar  -
<jdstrand> meh
<jdstrand> foo:bar  -
<jdstrand> foo:baz  -
<jdstrand> -         norf:bar
<jdstrand> sudo snap connect norf:bar foo:bar
<jdstrand> that works fine (expected)
<jdstrand> sudo snap connect norf:bar foo:baz
<jdstrand> no error, no issues
<jdstrand> (policy is correct
<jdstrand> )
<pedronis> ??
<pedronis> but snap interfaces
<pedronis> will say they are connect no?
<jdstrand> tpedsnap interfaces show it as connected
<pedronis> so you can connect things that will do nothing
<jdstrand> yes
<pedronis> maybe it's the best we can get
<pedronis> but is not that great
<jdstrand> well, I could error there
<jdstrand> in the 'ensure' section
<jdstrand> this is with that code commented out
<pedronis> but then it's too late
<pedronis> IÂ think
<jdstrand> if I put it back, I think it will work correctly since we return nil, nil
<jdstrand> let me check
<pedronis> as far as IÂ know
<pedronis> nothing checks that first nil
<pedronis> it just get ignored
<jdstrand> ok, putting it back it is the same behavior. snap interfaces shows it as connected, but the policy doesn't have it
<jdstrand> let me error in there
<jdstrand> return nil, err
<jdstrand> pedronis: yes, if I put an err there then snap connect shows the message, but snap interfaces still shows it as connected
<pedronis> jdstrand: the problem with the error is that if there's a 2nd interface that should work it will get in a strange state possibly
<jdstrand> pedronis: I don't know what to do at this point
<pedronis> there's not place atm for that check afaict
<pedronis> so the nil, nil
<pedronis> is the best we can do
<jdstrand> ok, so what I had
<pedronis> (also error handling in there is not very graceful)
<cachio> jdstrand, any suggestion about the comment I did before?
<jdstrand> cachio: you are going to need to have security policy that handles that. currently there is none
<jdstrand> cachio: I suggest devmode for the time being
<jdstrand> cachio: then finish your snap and then I can take a look at it
<cachio> I am getting this error
<cachio> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NameHasNoOwner: Could not get owner of name 'com.canonical.kpi.signal': no such name
<jdstrand> cachio: there is likely an apparmor denial in syslog
<cachio> jdstrand, I just see apparmor="ALLOWED"
<cachio> jdstrand, is it ok to copy the dbus config file to /etc/dbus-1/system.d ?
<jdstrand> cachio: ah, it is in devmode
<cachio> jdstrand, yes in devmode
<jdstrand> cachio: right, so devmode isn't going to cover dbus bus policy, just seccomp, device cgroups, apparmor, etc
<jdstrand> cachio: so you are going to need to put something in there. as it happens, the dbus interface I am working on would give you a bus policy that would work with devmode
<jdstrand> cachio: see https://github.com/snapcore/snapd/pull/1613/files#diff-715ebbcbcd440b44a1e536f154ca6138R108
<mup> PR snapd#1613: interfaces/builtin: add dbus interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
<jdstrand> cachio: eg, $ cat /etc/dbus-1/system.d/snap.test-hello-dbus.test-hello-dbusd-system.conf
<jdstrand> <!DOCTYPE busconfig PUBLIC
<jdstrand>  "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
<jdstrand>  "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<jdstrand> <!-- This file was automatically generated by snappy -->
<jdstrand> <busconfig>
<jdstrand> <policy user="root">
<jdstrand>     <allow own="com.canonical.HelloDBus"/>
<jdstrand>     <allow send_destination="com.canonical.HelloDBus"/>
<jdstrand> </policy>
<jdstrand> <policy context="default">
<jdstrand>     <allow send_destination="com.canonical.HelloDBus"/>
<jdstrand> </policy>
<jdstrand> </busconfig>
<jdstrand> cachio: create a bus policy like that ^ (adjust for your well-known name and interface of course) and that will allow any one to talk to your service
<jdstrand> well
<jdstrand> any unconfined process
<jdstrand> (or devmode)
<cachio> jdstrand, nice, but it would work when your change is landed, right?
<pedronis> jdstrand: it's late here, if you get a +1 from tyler it's mergeable IÂ think
<jdstrand> cachio: for devmode, yes. in strict might need some adjustments
<jdstrand> it may work
<cachio> jdstrand, good, so I'll need to wait
 * pedronis => rest
<cachio> jdstrand, any guess about when it is gonna be landed?
<jdstrand> pedronis: thanks so much!
<cachio> aprox
<jdstrand> cachio: it is what I've been talking about with people in this channel today
<cachio> jdstrand, we are talking about days, weeks?
<jdstrand> cachio: it is targeted for 2.20. it will hopefully land tomorrow
<jdstrand> 2.20 is for thursday I think
<cachio> jdstrand, awesome
<pedronis> it will get in candidate thu or fri
<cachio> jdstrand, it works for me if it is on this week
<pedronis> (stable is in January though)
<jdstrand> cachio: note pedronis' comment
<jdstrand> cachio: if you need something sooner, you are going to need to hack up your bus policy manually
<cachio> jdstrand, it is ok, I am using daily builds for testing
<cachio> jdstrand, so I'll test it as soon as possible once it is landed
<pedronis> barry: there should be again something in beta (for pc-kernel i386)
<cachio> jdstrand, thanks for the support
<jdstrand> cachio: np! :)
<jdstrand> tyhicks: thanks for your review! :)
<mup> PR snapcraft#967 opened: sources: refactor script source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/967>
<tyhicks> jdstrand: no problem!
#snappy 2016-12-14
<mup> PR snapcraft#968 opened: sources: refactor subversion source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/968>
<mup> PR snapcraft#969 opened: sources: refactor tar source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/969>
<mup> PR snapcraft#970 opened: sources: refactor zip source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/970>
<mup> PR snapd#2274 closed: interfaces: use sysd.{Disable,Stop} instead of sysd.DisableNow() <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2274>
<mup> PR snapd#2345 closed: many: tweak devmode and jailmode capitalisation <Created by zyga> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2345>
<barry> pedronis: thanks
<mup> PR snapcraft#962 closed: sources: refactor bazaar source into module <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/962>
<mup> PR snapcraft#963 closed: sources: refactor deb source into module <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/963>
<luk3yx> Is this the best place to ask a snappy playpen question?
<mup> PR snapcraft#971 opened: Fix integration tests in armhf <Created by elopio> <https://github.com/snapcore/snapcraft/pull/971>
<mup> PR snapd#2472 closed: tests: update custom core snap with the freshly build snap-confine <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2472>
<mup> PR snapd#2459 closed: interfaces/builtin: add iio interface <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2459>
<mup> PR snapd#2452 closed: interfaces/builtin: fix pulseaudio apparmor rules <Created by bergotorino> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2452>
<mup> PR snapd#2474 opened: Revert "interfaces: add new boot-config interface" <Created by mvo5> <https://github.com/snapcore/snapd/pull/2474>
<dholbach> hey hey
<kalikiana_> sliff
<mup> PR snapd#2468 closed: tests: add debug output to see why autopkgtests are failing <Blocked> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2468>
<mup> PR snapd#2475 opened: tests: nested image testing <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2475>
<mup> Bug #1649837 opened: Can remove required-snaps <Snappy:New> <https://launchpad.net/bugs/1649837>
<mup> PR snapd#2450 closed: interfaces: support network namespaces via 'ip netns' in network-control (LP: #1624675) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2450>
<mup> Bug #1649839 opened: unknown snap and snapd version when image created via ubuntu-image <Snappy:New> <https://launchpad.net/bugs/1649839>
<mup> Bug #1649840 opened: unknown keys in model assertion are silently ignored <Snappy:New> <Ubuntu Image:New> <https://launchpad.net/bugs/1649840>
<mup> PR snapd#2438 closed: release: 2.18.1 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2438>
<mup> PR snapd#2476 opened: overlord/snapstate: fixing the placement/grouping of some functions <Created by pedronis> <https://github.com/snapcore/snapd/pull/2476>
<mup> PR snapcraft#961 closed: sources: refactor local source into module <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/961>
<mup> Bug #1488887 changed: porting documentation needs adjustment for new uboot.env setup <snap-docs> <Snappy:Invalid by ogra> <https://launchpad.net/bugs/1488887>
<mup> Bug #1595581 changed: Snappy meta guide issues <snap-docs> <Ubuntu Developer Portal:Fix Released> <Snappy:Invalid> <https://launchpad.net/bugs/1595581>
<mup> Bug #1611639 changed: docs/package-names.md is out of sync with the rest of the project <snap-docs> <Snappy:Invalid> <https://launchpad.net/bugs/1611639>
<mup> Bug #1637093 changed: docs/config.md needs an update <snap-docs> <Snappy:Invalid> <https://launchpad.net/bugs/1637093>
<mup> PR snapd#2476 closed: overlord/snapstate: fixing the placement/grouping of some functions <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2476>
<ondra> ogra_ ping
<ogra_> ondra, yo
<ondra> ogra_ hey, are we hosting uboot somewhere or we are using https://github.com/hallor/u-boot directly with our patch on top?
<ogra_> ondra, nope ...
<ondra> ogra_ ha, nope to which part? :P
<ondra> ogra_ say I want to compile u-boot for pi3 myself, where do I get code?
<ogra_> ondra, from upstream and then you add the patch from the gadget tree
<ondra> ogra_ and upstream is where?
<ogra_> i just noticed we are missing said patch for the dragonboard in our tree
<ogra_> ondra, denx.de
<ogra_> upstream uboot
<ogra_> for dragonboard we indeed used the above tree (since it has never been submitted upstream)
<ogra_> http://paste.ubuntu.com/23628425/ is the patch
<ogra_> the pi's and beaglebone just use the upstream tree
<ondra> ogra_ cool
<ondra> ogra_ yeah I have here dragonboard, and was not sure if we use same tree there or not
<ondra> ogra_ so http://git.denx.de/ + patch from gadget for pi3 it is
<ogra_> we might be a commit behind or so on the db ... (the binary worked and we had no bugs so it wasnt further updated)
<ogra_> ondra, yeah
<ondra> ogra_ thank you mister :)
<ogra_> np :)
* jamiebennett changed the topic of #snappy to: Package any app for any Linux desktop, server, cloud or device. Read how on http://www.snapcraft.io | File a bug: https://bugs.launchpad.net/snappy/+filebug, join the snapcraft discussion https://rocket.ubuntu.com/channel/snapcraft
<Chipaca> ogra_, I think https://bugs.launchpad.net/snappy/+bug/1620559 is fix released; can you confirm?
<mup> Bug #1620559: /etc/resolv.conf is empty on snappy <hw-specific> <verification-done> <Snappy:New> <systemd (Ubuntu):Fix Released> <systemd (Ubuntu Xenial):Fix Released by pitti> <https://launchpad.net/bugs/1620559>
<mup> PR snapcraft#972 opened: Add a checklist in the pull request template <Created by elopio> <https://github.com/snapcore/snapcraft/pull/972>
<niemeyer> jdstrand: ping
<mup> PR snapd#2477 opened: interfaces/builtin/repowerd: First cut at repowerd interface <Created by afrantzis> <https://github.com/snapcore/snapd/pull/2477>
<mup> PR snapcraft#964 closed: sources: refactor git source into module <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/964>
<jdstrand> niemeyer: hi!
<jdstrand> niemeyer: if you are asking about James' feedback, I incorporated GetConnectionCredentials and responded to the other comments
<jdstrand> niemeyer: (James' comments in https://github.com/snapcore/snapd/pull/1613 that is)
<mup> PR snapd#1613: interfaces/builtin: add dbus interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
<r2geo> question on ubuntu core: is there a way to run "lsusb" in bash? -bash: lsusb: command not found
<niemeyer> jdstrand: Hey
<niemeyer> jdstrand: Yeah, James feedback
<niemeyer> jdstrand: What do you think of making "path" explicit?
<niemeyer> jdstrand: Any reason not to?
<jdstrand> niemeyer: I'd prefer not to keep adding to this. it has been lingering for so long. I mean, I can, but there is so much more that is needed for supporting complex services
<jdstrand> niemeyer: he as asking for multiple paths and interfaces pur well-known name as well. we don't even have session services yet
<jdstrand> pur?
<jdstrand> per*
<jdstrand> niemeyer: not sure if you read my response
<jdstrand> (in the PR to James)
<ogra_> Chipaca, bug updated ...
<ogra_> (thanks for the pointer)
<Chipaca> ogra_, incompletely fix released \o/
<Chipaca> :-)
<ogra_> haha
<mup> Bug #1620559 changed: /etc/resolv.conf is empty on snappy <hw-specific> <verification-done> <Snappy:Fix Released> <systemd (Ubuntu):Fix Released> <systemd (Ubuntu Xenial):Fix Released by pitti> <https://launchpad.net/bugs/1620559>
<roadmr> hello folks, is there a version of snapd that works on trusty? even if it's from a PPA, that would fit my needs
<ogra_> tvoss, ^^^^
<niemeyer> jdstrand: I didn't.. will get back in this after lunch
<tvoss> roadmr: yup, let me hand you instructions
<roadmr> tvoss: great, thanks! (yes, perfectly happy to read up existing material)
<mup> Issue snapd#2478 opened: Just testing <Created by zyga> <https://github.com/snapcore/snapd/issue/2478>
<jdstrand> niemeyer: ok, note I have an appt in 45 minutes for a couple of hours and then will be back
<elfgoh> ogra_: how are you testing your BBB image?
<ogra_> elfgoh, i install it on an SD, install htop to test snap interfaces and install the classic snap to test the classic functionallity usually
<elfgoh> I see. So you test on an actual device?
<ogra_> yes
<elfgoh> If I wanna do it as a vm or something, instead of a physical device is it possible?
<ogra_> not sure, does qemu support booting a plain img file ?
<ogra_> iirc you need to have kernel and initrd separate for qemu system mode
<ogra_> which would break
<ogra_> (snappy kind of relies on the partitioning and certain files in certain places ... and it needs to interact with the bootloader)
<elfgoh> I see
<ogra_> if you can use qemu for BBB arches like kvm that would work, but only then
<ogra_> (i.e. just point to the img file and have that boot)
<elfgoh> So if I use KVM, it will work? Even though the host OS will not be arm?
<ogra_> i dont think so ... kvm cant boot arm images afaik
<ogra_> (though perhaps i'm not up to date)
<ogra_> i meant above is "if you can use qemu *like* kvm" ... which meant just pointing to the img ... but i dont think thats possible)
<elfgoh> ogra_, I think you are probably right
<elfgoh> ogra_, then in the development of snaps for BBB, i am guessing it is best to build it on the BBB itself, instead of on say a linux vm running amd64?
<ogra_> you can use a qemu-user-static chroot or an lxd container i suppose ...
<ogra_> i.e. not a full BBB emulation ... but only the armhf userspace
<ogra_> note that wont work for everything (i.e. i dont think you can compile mono apps) but for most
<mup> PR snapd#2479 opened: many: implement snap unalias using snapstate.Unalias <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2479>
<niemeyer> jdstrand: Read your response.. I'm concerned with ignoring jamesh's feedback on it
<niemeyer> @jdstrand Yes, we want to unblock people to use that interface, and yes it's fine to implement the solution partially and evolve it over time.. but jamesh's feedback points out precisely that there may be cases for those very applications that are not being correctly handled, and I don't see the path forward yet
<nothal> niemeyer: No such command!
<niemeyer> jdstrand: He points out that the same interface may be published under several different well known names, and he also points out that GetProperty is in a separate interface.. we didn't discuss any of those cases yet
<niemeyer> GetProperty is a pretty concerning problem, for example, because it lives in its own separate interface.. how can we confine it properly?
<mup> PR snapd#2480 opened: many: prepare landing on trusty <Created by vosst> <https://github.com/snapcore/snapd/pull/2480>
<mup> Bug #1649934 opened: USB Auto-mount for assertion import fails <Snappy:New> <https://launchpad.net/bugs/1649934>
<mup> PR snapd#2481 opened: osutil: fix unit tests to pass on OS X <Created by zyga> <https://github.com/snapcore/snapd/pull/2481>
<mup> Issue snapd#2478 closed: Just testing <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/issue/2478>
<mup> PR snapd#2481 closed: osutil: fix unit tests to pass on OS X <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2481>
<mup> PR snapcraft#965 closed: sources: refactor mercurial source into module <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/965>
<mup> PR snapd#2482 opened: store: retry auth-related requests <Created by stolowski> <https://github.com/snapcore/snapd/pull/2482>
<mup> PR snapd#2483 opened: store: use mocked retry strategy to make store tests faster <Created by stolowski> <https://github.com/snapcore/snapd/pull/2483>
<mup> Issue snapd#2484 opened: Support removing all unused revisions <Created by niemeyer> <https://github.com/snapcore/snapd/issue/2484>
<mup> Bug #1555217 changed: snappy leaks loop devices <snapd:Unknown> <https://launchpad.net/bugs/1555217>
<mup> PR snapcraft#973 opened: Check the license agreement on Travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/973>
<mup> PR snapcraft#974 opened: Updated maven plugin to use get_build_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/974>
<mup> PR snapcraft#975 opened: Updated the gradle.py plugin to use the get_build_properties() method instead of modifying the schema <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/975>
<jdstrand> niemeyer: did you see my response for Properties.Get()? it is covered for GNOME and KDE apps which this iteration is trying to unblock
<ogra_> elopio, hmpf, not sure what you wanted to fool me with in rocket ... but it showed me that i cant log in at all anymore to rocket.ubuntu.com
<ogra_> :
<ogra_> :(
<jdstrand> niemeyer: also, GNOME and KDE apps don't do the different interfaces, they use consistent interfaces that work with this PR
<jdstrand> niemeyer: he is wanting a super-general interface that can work with any service. that isn't this PR. this PR is GNOME and KDE leaf-style applications [C[C[C[C[C[C[C[C[C
<jdstrand> niemeyer: there is going to need to be considerable investigation, thought and design to try to support services generally. some services will work with just this, and that's fine, but we don't even support session services or dbus policy, etc, etc so blocking this PR to support services that won't work anyway seems odd
<jdstrand> s/dbus policy/dbus bus policy generally/
<mup> PR snapd#2479 closed: many: implement snap unalias using snapstate.Unalias <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2479>
<niemeyer> jdstrand: My concern is not even understanding what James is talking about..  I hear you saying we don't need to support everything, but when I see James saying we won't support the very thing he's working on, I get concerned we don't even understand which tradeoffs we're making
<jdstrand> niemeyer: I'm concerned about scope creep for this PR. This will allow GNOME and KDE leaf-style applications to be able to be in stable. it is intended to also have them integrate into the desktop session and to have different leaf-style applications to talk to each other via snap connections. that's it. it lays the groundwork for services in general, but doesn't attempt to implement that yet
<jdstrand> niemeyer: he is not trying to snap a GNOME application
<jdstrand> niemeyer: he is trying to write a dbus session service
<jdstrand> niemeyer: we don't support that in at least two other ways beyond this PR
<jdstrand> this PR works for Properties.Get() for leaf-style applications. He did not notice the rule I mentioned covered his concern
<niemeyer> I don't get that distinction.. gnome applications are just software like any other.. they can use dbus as they see fit
<jdstrand> niemeyer: in addition, he is not blocked on this. he can write an interface for storage service just like everyone else has for bluez, network-manager, locationd, etc
<jdstrand> niemeyer: gnome and kde applications use toolkit libraries that use dbus in a very specific way
<jdstrand> niemeyer: eg, GApplication
<jdstrand> this is why no GNOME application works today. GApplication binds to the well-known name
<niemeyer> Do you know what James means when he talks about multiple well known names?
<jdstrand> the toolkit takes that well-known name and actually creates dbus paths and interfaces very regularly
<jdstrand> precisely in the way that this PR addresses
<jdstrand> niemeyer: he was saying several things
<niemeyer> I'm asking about one specific thing
<jdstrand> niemeyer: 1. a single well-known name, eg, org.foo might have interfaces for org.foo and org.bar. 2. a single well-known name like org.foo might use different paths, like /org/foo and /org/bar and 3. a single service might bind to multiple well-known names
<jdstrand> niemeyer: this PR handles '3'
<jdstrand> '1' and '2' it does not. and we specifically decided before that it should not in *this* iteration
<jdstrand> a future iteration would consider these other use cases and we would design for that
<jdstrand> this PR is written in a manner that we can build upon for the future use cases
<niemeyer> How do we handle 1 in the future? That'd what James was talking about
<jdstrand> add 'interface' attribute
<niemeyer> When referring to multiple well known names
<jdstrand> and '2' is add 'path' attribute
<niemeyer> Doesnt work.. interface is something else
<jdstrand> ok, 'dbus-interface'
<niemeyer> What is name then?
<jdstrand> interface is an overloaded term
<niemeyer> I thought that was interface
<jdstrand> it means one thing in dbus and another in snappy
<niemeyer> Yes, we're talking about dbus
<niemeyer> What is the name attribute referring to? I thought it was the dbus interface name?
<mup> PR snapcraft#966 closed: sources: refactor rpm source into module <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/966>
<jdstrand> niemeyer: in dbus, you have a well-known name for a service (org.foo). that service may offer any number of dbus interfaces (eg, org.fo.bar, org.foo.baz, org.norf) and then dbus also has a path
<jdstrand> niemeyer: the 'name' attribute is the well-known dbus connection name
<jdstrand> org.gnome.Logs
<jdstrand> org.gnome.Rhythmbox
<jdstrand> GNOME and KDE toolkits are very regular with how the well-known name corresponds to dbus interface and dbus paths
<jdstrand> which is why this PR does what it is doing now
<jdstrand> what we are doing now would be the defaults we would always offer I imagine, and then additional attributes for 'dbus-interface' or 'dbus-path' would add additional security policy
<niemeyer> So do we support any interface on the well known name?
<jdstrand> we did discuss this before, but, look at https://github.com/snapcore/snapd/pull/1613/files#diff-715ebbcbcd440b44a1e536f154ca6138R149
<mup> PR snapd#1613: interfaces/builtin: add dbus interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
<jdstrand> we allow a connected snap to introspect our dbus api
<jdstrand> we allow a connected snap to use any dbus interface and any dbus path if they are connecting to the well-known name
<jdstrand> if they are using a non-well-known name, we allow connecting to any dbus path if the dbus interface is regular according to our well-known name
<niemeyer> Okay, that sounds reasonable
<niemeyer> Thanks for the long explanation
<jdstrand> if they are using a non-well-known name, we allow connecting with any dbus interface if the dbus path is regular accoriding to our well-known name
<niemeyer> Happy to go forward with it
<jdstrand> \o/
<niemeyer> Is the PR blocked on anything else at this point?
<jdstrand> niemeyer: no. tyhicks reviewed the security policy. pedronis reviewed the code. I incorporated all applicable feedback from everywhere
<niemeyer> So let's get it in
<jdstrand> thanks!
<niemeyer> Thank you!
<jdstrand> niemeyer: so with that, I plan to work with the personal folks on designing their interfaces (eg, storage framework) and will be reviewing tvoss' work for session services and will be thinking about how all of this relates to this interface, improvements we can make to this interface, etc and when I have coherent thoughts on it, will present phase ii, phase iii, etc, etc iterations to you
<elopio> morphis__: looking at your homeassitant reply, it's not really necessary to have the snapcraft.yaml in the root
<elopio> https://github.com/blockstack/blockstack-core/pull/264/files#diff-a4a8be59175f107f2ba1ce86da0c8286R28
<mup> PR blockstack/blockstack-core#264: Add the packaging metadata to build the blockstack-core snap <Created by elopio> <https://github.com/blockstack/blockstack-core/pull/264>
<elopio> it looks better, that's true. And sometimes using the relative path might cause a mess. But it should work.
<jdstrand> niemeyer: ok, I reviewed the testsuite issues-- all are unrelated to this PR (I left a comment). I also captured the tail end of the above IRC discussion in a comment so people understand what is allowed by the policy
<jdstrand> niemeyer: since your previous 'requested changes' is still in effect, I'll leave this to you to pres the merge button?
<jdstrand> press*
<morphis__> elopio: interesting
<mup> PR snapd#2485 opened: overlord: apply auto-aliases information from the snap-declaration on install or refresh <Created by pedronis> <https://github.com/snapcore/snapd/pull/2485>
 * ahoneybun slides some money to someone who can snap this: https://github.com/wereturtle/ghostwriter
<kyrofa> ahoneybun, did you run into problems with it?
<ahoneybun> kyrofa: tbh I've not even tried
<ahoneybun> I've only gotten 1 snap to work
<ahoneybun> well half work as it needed flash for some content
<kissiel> my network problems are gone, lesson learned: KEEP AWAY FROM NETGEAR
<kyrofa> kissiel, yikes, was it compromised?
<kissiel> not that bad; 9/10 snap commands timed out
<kissiel> reason being bad DNS via ipv6 handling
<kissiel> and causing a mess/timeouts
<kyrofa> kissiel, if it makes you feel better, I think my asus is dying on me, too
<kissiel> kyrofa: which one is it, cause from today on I got two :D
<kyrofa> kissiel, RT-N66U, but it's pretty old nowadays
<kyrofa> kissiel, and it might also be my modem. Or ISP :P
<kyrofa> Tough to debug problems like that
<kissiel> kyrofa: oh man; oh yeah
<kissiel> kyrofa: my wget -4 apps.ubuntu.com took 0.2s, while without `-4` it took 15s+
<mhall119> jdstrand: if a snap uses the removable-media interface, where will the snap environment see that media?
<jdstrand> mhall119: /media on classic. an all snaps system with udisks2 snap installed, /run/media
<mhall119> jdstrand: thanks, does it only make it visible when you try to access it?
<jdstrand> mhall119: I'm not sure I understand the question. lsdir on / is blocked and /media is blocked without removable-media, so snaps can't see anything in there until snap connect. there is nothing special about the interface other than allowing access to the directory
<mhall119> jdstrand: I snap-connected krita to removable-media, but the open dialog didn't show /media/ until I entered it manually, and then it wouldn't show /media/mhall/ until I undered that manually too, etc
<mhall119> trying to determine if this is a snapd thing, or a krita thing
<jdstrand> mhall119: you will definitely have to enter /media/. tab complete and things won't work and you can't navigate from say /home/mhall, /home, /, /media, cause all those directories are not readable
<jdstrand> mhall119: let me check the exact rule for under /media
<jdstrand> mhall119: right, cause mounts are done in /media/<user>/, you have to also enter /media/mhall/. after that you can tab complete and go to /media/mhall/subdir/subdir/... via the file dialog
<jdstrand> these are the rules:
<jdstrand> # Mount points could be in /run/media/<user>/* or /media/<user>/*
<jdstrand> /{,run/}media/*/ r,
<jdstrand> /{,run/}media/*/** rw,
<mhall119> that's kind of hard to discover, is there any way we can make this better?
<jdstrand> mhall119: the security policy is correct. snaps shouldn't be able to lsdir() all over the place. it can be improved, but it should be at the toolkit level. eg, the file dialog should not be run in-process, it should be out-of-process, like with content-hub
<jdstrand> mhall119: that way the application doesn'
<jdstrand> t have to care about snappy. the user drives the interaction, and the out of process trusted helper mediates the access
<jdstrand> there is a bug on this and that is what was outlined
<mhall119> jdstrand: ideally yes, and that's likely to come in the future, but doesn't help yet
<mhall119> strangly, the open dialog can see /home and /snap when I point it to /
<jdstrand> that is indeed strage
<jdstrand> I mean, we *could* allow '/home/ r, / r, /media/ r,'. that would allow enumerating users. It wouldn't be the worst thing, especially on classic
<jdstrand> there is a problematic directory though: ~/snap/. I was expressly asked to not allow lsdir access to it cause that would allow snaps to enumerate installed apps
<jdstrand> and because HOME is set to /home/user/snap/$SNAP/$REVISION/, apps start down there. there is a bug on that too
<jdstrand> (so, /home/user/snap/$SNAP/$REVISION is fine, /home/user/snap/$SNAP is fine, /home/user/snap is not, /home/user is fine with 'home', then get to /home, etc
<jdstrand> )
<mup> PR snapcraft#976 opened: demos: do not force arch for the tomcat demo <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/976>
<knight__> Hello. I'm trying to use Ubuntu Core for the first time on a Raspberry Pi 3. First boot it needs config, so I setup the Wifi but it will not connect. It times out. I tried 3 different wifi networks available to me (one of which is less than 4 meters away). Any thoughts?
<kyrofa> ogra_, ^^ if you're still around
<ogra_> knight__, you need to do the initial setup wired ... later you can ssh into the board and re run "sudo console-conf" to disable wired and enable wireless
<ogra_> (there is a bug with the pi33 driver on first boot setup, but it works fine later)
<ogra_> **pi3
<knight__> ogra_ why hasn't the bug been fixed? Is it a hardware issue? Or is there a problem with the kernel?
<ogra_> its a driver issue, fix is in the works but not there
<knight__> gotcha, ok thanks. Is there a way to preconfigure Ubuntu Core? I'm very Ubuntu familiar, but this is first time I'm using core.
<knight__> For example, let's say I am building a custom firmware.
<ogra_> there is a way through loading an assertion file from USB on first boot, but i dont know exacctly how or where thats documented, sorry
<knight__> ogra_ but isn't the purpose of Ubuntu Core to be the basis of custom IoT firmwares?
<ogra_> yes
<knight__> So how are people customizing Ubuntu Core to be self-contained custom firmwares for their devices?
<ogra_> they rll their own images based on a custom gadget snap
<knight__> Oh I see. So not using the "intro" image
<knight__> The image available on the Ubuntu Core page is really just to get running a vanilla core on a preferred supported device easy. Not as the start for a custom build.
<knight__> Is that right?
<ogra_> right, the gadget can ship default configs and such ... an when you build your own image using ubuntu-image you can easily add additional snap packages to get extra features
<knight__> Ahh beautiful, ok.
<ogra_> well, to get a custom build you would start from there
<ogra_> install the official core image, add your additional snaps and configure them etc
<ogra_> also for many applications the official image is sufficient ...
<knight__> Are you aware of any native support for creating things like restore partitions and custom firmware updates?
<ogra_> i.e. the nextcloud box ...
<ogra_> you dont really need a local user for it ... you create and manage the nextcloud users via the nextcloud UI
<knight__> Such as if two pins on the RPI3 GPIO are activated (button held down), can initiate a rollback to "stock" on the restore image
<ogra_> (same would go for a kodi image, you wouldnt really need any users on it to watvh TV)
<ogra_> such fanc stuff is further down the roadmap ... but yeah, things like recovery mode and factory reset are on the roadmap
<ogra_> **fancy
<knight__> oh nice
<knight__> so not avail yet, but on the roadmap
<ogra_> yep
<ogra_> there is also a so called "model creator" planned, that should make it trivial to build your own custom images
<knight__> oh wild
<knight__> ok, all that right there just made me excited for Core
<knight__> so, can i skip setting up wired networking altogether, then re-run console-conf on first boot? or must it establish a wired connection no matter what?
<knight__> Seems like there's no way to skip networking.
<ogra_> well, since you need an ubuntu SSO account to create the local user from ... network is kind of needed
<ogra_> (core grabs your ssh key from the SSO account and sets up a local ssh key login for you)
<knight__> Ahh right
<knight__> OK.
<knight__> Bummer, I don't have screen near network drop.
<ogra_> serial console is enabled by default in case that helps ...
<ogra_> (for console-conf)
<mup> PR snapd#2486 opened: tests: fix tests on 17.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2486>
<mup> PR snapd#2487 opened: overlord/snapstate: implement snapstate.ResetAlias <Created by pedronis> <https://github.com/snapcore/snapd/pull/2487>
 * ogra_ goes afk
<knight__> ogra_ ... does that mean you don't have to get network up and logged in first?
<mup> PR snapcraft#967 closed: sources: refactor script source into module <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/967>
#snappy 2016-12-15
<mup> PR snapcraft#968 closed: sources: refactor subversion source into module <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/968>
<mup> PR snapcraft#977 opened: Prefer in-snap libraries to system libraries <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/977>
<mup> PR snapcraft#978 opened: Updated cmake uplugin to use get_build_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/978>
<mup> PR snapcraft#979 opened: Updated waf plugin to use get_build_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/979>
<mup> Bug #1650091 opened: console-conf and getty hang if password is not set and press many enters <Snappy:New> <https://launchpad.net/bugs/1650091>
<mup> Bug #1650096 opened: 'snap list' does not show devmode property after disable and re-enable a snap <Snappy:New> <https://launchpad.net/bugs/1650096>
<mup> PR snapd#2480 closed: many: prepare landing on trusty <Created by vosst> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2480>
<mup> PR snapd#2474 closed: Revert "interfaces: add new boot-config interface" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2474>
<dholbach> hey hey
<mup> PR snapd#2488 opened: interaces: add new boot-config interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/2488>
<stub> Can I hand back a snap store name I was granted? Someone else is handling the snap.
<stub> Or maybe I can just ignore it, since it will be obvious since I've pushed nothing to that namespace
<mup> Issue snapd#2489 opened: Can't run binary installed via a snap package <Created by mlcdf> <https://github.com/snapcore/snapd/issue/2489>
<kalikiana_> mup: Why did you announce that bug? It's a dead link...
<mup> kalikiana_: In-com-pre-hen-si-ble-ness.
<kalikiana_> mup: Bug link is broken
<mup> kalikiana_: Roses are red, violets are blue, and I don't understand what you just said.
<kalikiana_> Pffffft
<mup> Bug #1650187 opened: Can't run any snap application on Mint 18 <Snappy:New> <https://launchpad.net/bugs/1650187>
<mup> Issue snapd#2489 closed: Can't run any snap application <Created by mlcdf> <Closed by mlcdf> <https://github.com/snapcore/snapd/issue/2489>
<mup> PR snapd#2485 closed: overlord: apply auto-aliases information from the snap-declaration on install or refresh <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2485>
<stub> Looks like charms using the Snap layer need to be rebuilt for Snappy 2.17, due to the backwards incompatible change of 'ubuntu-core:slotname' to just ':slotname'
<stub> What time frame are we looking at for backports to trusty?
<kalikiana_> stub: Shouldn't both be valid? Or is it documented to be breaking?
<stub> I don't know if it is documented. ubuntu-core:foo is no longer valid. I don't know when :foo started being valid.
<kalikiana_> The test cases in snapd still use ubuntu-core:
<stub> Huh. That isn't what I'm seeing here.
<stub> root@ip-172-31-3-170:/var/log/juju# snap connect rocketchat-server:network ubuntu-core:network
<stub> error: cannot perform the following tasks:
<stub> - Connect rocketchat-server:network to ubuntu-core:network (snap "ubuntu-core" has no slot named "network")
<stub> root@ip-172-31-3-170:/var/log/juju# snap connect rocketchat-server:network :network
<stub> (the last works) Or is there a typo in there I can't see?
<seb128> hey there
<seb128> does anyone know if remote parts can point to a branch
<seb128> git repo one
<kalikiana_> stub: Normally network autoconnects... are you sure you need to do that at all?
<stub> seb128: yes, I think you specify the branch name in a separate yaml field
<stub> kalikiana_: This is just my test case. I know it is not actually needed.
<stub> (I need a smaller test snap in my test charm)
<seb128> stub, like "origin-branch:  something"?
<seb128> stub, on https://wiki.ubuntu.com/snapcraft/parts
<stub> seb128: yes, but I don't recall exactly what it is or where it is documented
<seb128> stub, k, thanks anyway, I'm going to try to figure it out
<stub> seb128: snapcraft/internal/sources.py
<stub> source-type: git
<stub> source-branch: <name>
<kalikiana_> stub: For me, using another snap as an example, both of these work: "snap connect arangodb3:network ubuntu-core:network" and "snap connect arangodb3:network :network"
<stub> kalikiana_: Can you confirm you have 2.17 ?
<stub> Maybe it is fixed in 2.18
<seb128> stub, that's what is used in snapcraft.yaml but doesn't match the syntax used on https://wiki.ubuntu.com/snapcraft/parts which uses e.g "origin" or "origin-type"
<kalikiana_> stub: I just updated to the latest master and it still works fine
<stub> kalikiana_: ok, I'll assume user error or fixed after 2.17 for now. There are not enough charms using the layer yet to be a major problem.
<kalikiana_> stub: What if you used core: instead of ubuntu-core:?
<kalikiana_> As the snap was renamed at one point, that could explain the error
<kalikiana_> If that's the case it might make sense to explicitly handle that case in the code - currently it doesn't
<mup> PR snapd#2490 opened: many: implement  "snap un/alias --auto" using snapstate.ResetAliases <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2490>
<mup> PR snapd#2410 closed: store: retry resumed downloads on sha3 error <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2410>
<mup> PR snapd#2483 closed: store: use mocked retry strategy to make store tests faster <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2483>
<stub> kalikiana_: Oh, you are correct. core:network works
<mup> Bug #1650207 opened: original lsb-release file should be preserved for classic mode <Snappy:New> <https://launchpad.net/bugs/1650207>
<stub> kalikiana_: At least under 2.17. core: fails under 2.16 :)
<kalikiana_> stub: Yeah. As I said, the snap was renamed. You can see it in "snap list"
<kalikiana_> If you don't use a name, snap connect will pick one
<kalikiana_> So if this affects several existing setups, it may make sense to alias ubuntu-core to core
<mup> PR snapd#2486 closed: tests: fix tests on 17.04 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2486>
<kalikiana_> Or, if updating all existing cases is good enough, use :foo everywhere and it'll just work
<stub> I could detect the snappy version and rewrite ubuntu-core to core as appropriate (or vice versa)
<kalikiana_> stub: It's literally about which snap is installed, the version of the tooling is irrelevant
<stub> :foo doesn't work under 2.16
<stub> I would need to detect the version, using ubuntu-core:foo under 2.16 or earlier or :foo under 2.17 or later. Or just wait for 2.17 to get backported to trusty.
<kalikiana_> Hmm I can't find it in the changelog unfortunately
<stub> I'm going to ignore it for now. I don't think it affects anything live, and a minor glitch to stuff in development (which is targetted at Xenial, so 2.17), and the only thing I'm aware of that will need to support both doesn't use slots (canonical-livepatch)
<stub> well, doesn't need to specify its slots since they autoconnect
<jacekn> ISTR there is a way to get shell inside snap confinement for troubleshooting purposes but I can't find any docs. Anybody knowns how to do it?
<tsdgeos> jacekn: run --shell Â¿
<tsdgeos> i.e. snap run --shell mySnap
<jacekn> tsdgeos: aha that's it!
<tsdgeos> glad to be of service :)
<jacekn> right so next question will be how to bump number of open files, it's tricky because my snap is a deaemon so it uses autogenerated systemd unit file
<bull> hi guys i need help building snap package of my application which i wrote using qt57 installed in my /opt/qt57 now i dont wana use qt57 part cause it download whole qt57 source and then compile it and then fail at middle
<bull> my question is , can i use the system's (/opt/qt57) qmake to build source and build snap package
<bull> launchpad also gives up with my project cause it through errors while compiling qt code :D
<mup> PR snapcraft#980 opened: Add optional "source-checksum" property <Created by pachulo> <https://github.com/snapcore/snapcraft/pull/980>
<bull> i used qt5.7 cause it has a working qwebengine api :D
<stub> kalikiana_: There is no syntax that works with both 2.16 and 2.17. If I use core instead of ubuntu-core: it fails under 2.16
<mup> PR snapcraft#959 closed: cli: make plugins be an alias of list-plugins <Created by tsdgeos> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/959>
<mup> PR snapcraft#970 closed: sources: refactor zip source into module <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/970>
<stub> kalikiana_: (whoops.... backscroll fail)
<mup> PR snapcraft#976 closed: demos: do not force arch for the tomcat demo <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/976>
<mup_> PR snapd#2491 opened: debian: use a packaging branch for 14.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2491>
<mup> PR snapd#2492 opened: cmd/snap: remove currency switch following UX review <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2492>
<mup> PR snapcraft#981 opened: Support download and validate on branded stores <Created by cprov> <https://github.com/snapcore/snapcraft/pull/981>
<seb128> kyrofa, hey, do you know if remote parts can specify a git branch to use?
<seb128> sergiusens, ^
<ogra_> ppisati, i need an updated kernel snap in edge to have it pick up some initrd changes, what was your exact naming scheme you use for the beta/candidate builds so i can make the edge bzr branch match that ?
<ogra_> err
<ogra_> s/naming scheme/versioning scheme/ (indeed)
<madprops> ok here's another question i have
<madprops> regarding autoupdates
<madprops> if my internet is not very good and im in the middle of an online game or downloading something important
<madprops> i wouldn't like some program updates hindering my bandwidth
<madprops> i would rather update when I want
<madprops> i even disabled auto updates in my android phone
<ogra_> madprops, it is managed by a systemd time that you can turn off but you should really not forget to update regulary then :) especially if you use snaps from the edge channel that can change frequently
<ogra_> snapd.refresh.timer is the system unity
<abeato> ogra_, quick question, I understand that whenever a new core/kernel gets installed, uboot.env gets rebuilt with the right values for snap_core and snap_kernel, correct?
<ogra_> not re-build, jzust these vars get updated
<abeato> ogra_, well, modified :)
<ogra_> yeah
<ogra_> abeato, snapd does that through uboot.go, you can check the values with fw_printenv
<abeato> ogra_, ah, good to know, thanks
<bull> hi guys i need help building snap package of my application which i wrote using qt57 installed in my /opt/qt57 now i dont wana use qt57 part cause it download whole qt57 source and then compile it and then fail at middle
<bull> my question is , can i use the system's (/opt/qt57) qmake to build source and build snap package
<bull>  launchpad also gives up with my project cause it through errors while compiling qt code :D
<bull> ogra_,
<ogra_> bull, you can probably create a snapcraft part for it and use this during the build of your app ...
<ogra_> or perhaps you could use ubuntu-app-platform ... i'm not actually sure which Qt version that ships
<bull> ogra_, that does not include qt57
<bull> ogra_, can i use my system's qt57 ??
<ogra_> ah, well, then you likely need to create a part
<bull> ogra_, i have no idea how to do that , i have installed qt57 from ppa
<ogra_> well yopu would have to include it in your snap
<bull> i want its qmake build my source in snapcraft and turn my code to snap :(
<ogra_> or create a part that pulls it from the PPA and instalkls it in the snapcraft build env
<bull> ogra i can include everything by staging but idk how to call opt/qt57/bin/qmake
<ogra_> heh, i dont know either ... perhaps with a make plugin as wrapper or some such ...
<bull> ogra_, i dont know how o do it man :( i been struggling from 3 days :(
<ogra_> you shoudl ask someone with some more Qt experience ... i did never really get past QML
<bull> i used remote qt57 which downloaded more then 2gb of qt src and chromium src dataand failed twice as it cant build correctly
<ogra_> perhaps the guys in #ubuntu-app-devel could be of help
<bull> ogra_, let me ask them thanks man
<ogra_> bull, also https://github.com/snapcore/snapcraft/pull/566 seems to be the snapcraft qmake plugin .. you might need to use it and override some bits to make your bzuild use a custom qmake (not sure about that though)
<mup> PR snapcraft#566: Add qmake plugin <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/566>
<bull> i uploaded my other application to store check them here https://uappexplorer.com/apps?q=author%3Akeshavbhatt&type=all_types&sort=-points
<bull> ogra_, am looking into it thanks
<pihole> kyrofa: thanks for your help the other day; I got it working.  Now I'm stuck trying to get a config file deployed for the DNS server, which I have traditionally used a shell script to modify some of the values.  Is there any way to do this via a custom plugin?
<jdstrand> niemeyer: hi! https://github.com/snapcore/snapd/pull/1613 still has you as 'requesting changes' in github so no one can merge it. would you mind 'approving changes' and merging it?
<mup> PR snapd#1613: interfaces/builtin: add dbus interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
<liuxg> sergiusens, recently I found a bug on dragonboard. could you please help to take a look at it? thanks. the bug link is at https://bugs.launchpad.net/snapcraft/+bug/1649181
<mup> Bug #1649181: 'ascii' codec can't encode character '\u29f8' in position 49: ordinal not in range(128) on ARM 64 platform like dragon board <Snapcraft:New> <https://launchpad.net/bugs/1649181>
<mup> PR snapd#2493 opened: overlord/snapstate,daemon: implement GET /v2/aliases handling <Created by pedronis> <https://github.com/snapcore/snapd/pull/2493>
<mup> PR snapd#1613 closed: interfaces/builtin: add dbus interface <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1613>
<kalikiana_> yay, dbus
<ogra_> liuxg, wow, something must be really outdated on your side, that has been fixed ages ago iirc
<ogra_> liuxg, popey's bug ... bug 1607015
<mup> Bug #1607015: 'ascii' codec can't encode character '\u29f8' in position 19: ordinal not in range(128) <Snapcraft:Won't Fix> <https://launchpad.net/bugs/1607015>
<liuxg> ogra_, but it happened now on my board.. I tried to use classic to build a project, and it happened to be like that
<liuxg> ogra_, it seems that it happens on the arm64 architecture, on 32bit architecture, it does not happen.
<ogra_> well, read the bug ... fixed long ago if you use the proper component
<ogra_> i'm pretty sure that char isnt usedd anywhere anymore
<liuxg> ogra_, the same project can be compiled on pi devices.
<ogra_> well, no idea then, but i know that the slashes were dropped from all components (or was the char a backslash ? )
<ogra_> when we dropped support for the old desktop-* things
<liuxg> ogra_, let me try again. it is very consistent.
<ogra_> and your snapcraft yaml uses desktop-*, not desktop/* ?
<ogra_> (the latter causes the bug and the parts using a slash in the name were all dropped long ago)
<sergiusens> ogra_ well they are not dropped, just deprecated ;-)
<ogra_> sergiusens, dropped from support ;)
<ogra_> nobody touched them since
<sergiusens> and for this very reaon
<ogra_> yeah
<sergiusens> right, that is true
<ogra_> if you see it with the dash version, there might indeed be a bug though
<liuxg> ogra_, sergiusens, this is the result http://paste.ubuntu.com/23633817/
<ogra_> ... somewhere ...
<ogra_> now thats a different char
<ogra_> '\xae'
<liuxg> ogra_,  sergiusens yeah, yes, they both are reported in the bug
<ogra_> liuxg, and you are sure you are not using a part with a slash in the name in your snapcraft yaml ?
<liuxg> ogra_, I have changed to use "mqtt-paho-python3" instead, but it is the same.
<ogra_> you still get complaints about '\u29f8' ? even though you dont have any names with a slash in your snapcraft yaml and have completely cleaned your tree before calling snapcraft ?
<liuxg> ogra_, I am now trying it again. I remember I did that before.
<mup> PR snapcraft#982 opened: parser - Use the same version method as 'snapcraft' <Created by josepht> <https://github.com/snapcore/snapcraft/pull/982>
<liuxg> ogra_, you are right. after changing to "-", it is OK. I remember I changed that last time.
<tsdgeos_> what processes the files in /var/lib/snapd/mount ?
<tsdgeos_> is it snap-confine ?
<jdstrand> roadmr: hi! can you do a store sync for r810. that is just a data update, no code changes
<roadmr> jdstrand: sure!
<jdstrand> roadmr: thanks!
<mup> PR snapcraft#983 opened: Updated scons plugin to use get_build_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/983>
<shuduo> when i try to register a key for sign a model assertion with "snapcraft register-key" i got error and the msg is "Key registration failed: Failed to save account-key-request assertion for account_id XXXXXX invalid revision: could not add assertion (revision 0 is already the current revision)"
<shuduo> mvo: any idea ^?
<mvo> shuduo: I am not sure, sergiusens may know better but it sounds like the key is already registered maybe?
<ZenHarbinger> Quick question about snapcraft development.  I have put forth some PRs, but the autopkgtest is failing for xenial- and yakkety- amd64.  Is there a reason why these 2 might fail and the rest pass?
<bull> guys how can we use local part from / part/plugins dir ??
<shuduo> mvo, sergiusens, it failed at first time with msg "Key registration failed: Failed to create account-key assertion for account_id XXXXX  assertion refused: could not add assertion (account-key assertion for YYYYY has the same name "default" as existing ID ZZZZ.
<bull> i mean what we have to put in snapcraft.yaml file to so that snapcraft can recognize that plugin
<shuduo> but how i can find exist keys from launchpad to manage them?
<bull> sergiusens, help me please am lost since three days :(
<bull> popey, hi
<alex-abreu> mvo, snapd 2.20 is for this week or next week ?
<abeato> ondra, I have this for the rpi3 gadget: https://github.com/snapcore/pi3-gadget/pull/4
<mup> PR pi3-gadget#4: Add support to boot from USB <Created by alfonsosanchezbeato> <https://github.com/snapcore/pi3-gadget/pull/4>
<abeato> ups
<abeato> ogra_, ^^
<ogra_> abeato, wont work
<mvo> alex-abreu: today
<ogra_> that needs a specific firmware so we need a separate new gadget
<abeato> ogra_, well, it does (if you enable first USB booting from raspbian)
<abeato> ogra_, the firmware works for both cases
<abeato> I tested that
<ogra_> abeato, the prob is really that it is irreversible ... on the pi ... so we need more HW
<ogra_> one to test U(SB, one to test SD where we never switch the rom
<abeato> ogra_, well, give it a try in yours :)
<ogra_> i surely wont
<alex-abreu> mvo, thank you, ... also quickly do you have the rights to give me the commit rights in snapweb github?
<ogra_> since i need to still be able to test SD
<abeato> ogra_, both SD and USB work for me :)
<mvo> alex-abreu: let me check, I think I don't have the needed privs, only gustavo has. but I will double check
<alex-abreu> mvo, ok
<ogra_> abeato, you mean you can turn it back into an SD obnly device ?
<ogra_> afaik thats not possible
<ogra_> if you switch to the other path for the ROM there is no way back
<mvo> alex-abreu: actually jamiebennett and elopio  have admin
<jamieben_> mvo: that is not enough
<mvo> oh, ok
<jamieben_> mvo: you need to be an organisational admin apparently
<mvo> alex-abreu: -^
<jamieben_> mvo: the add user stuff if greyed out for me
<alex-abreu> mvo, oh ...
<alex-abreu> jamieben_, so who can add users?
<JamieBennett> I know niemeyer can
<abeato> ogra_, don't know, but the PR will not break your rpi, to enable USB you need to do something else
<alex-abreu> niemeyer, ^ when you see this, ... adding me as committer to snapweb
<ogra_> abeato, not the PR, but to test it we need additional HW
<ogra_> abeato, we still need to be able to test the default setup without the ROM switcvh
<abeato> ogra_, you can do that :) I tested with the switch, you can test without it
<ogra_> abeato, ah, i see you didnt add the config.txt bit by default
<abeato> ogra_, correct
<paperManu> hello there
<ogra_> abeato, oh, CONFIG_PREBOOT is clever !
<mup> PR snapd#2494 opened: store: send an explicit X-Ubuntu-Classic header to the store <Created by pedronis> <https://github.com/snapcore/snapd/pull/2494>
<ogra_> abeato, why is the "enable_uart=1" needed ? isnt that initialized by default anyway ?
<abeato> ogra_, not with latest firmware, and that caused *lots* of problem until I found the right solution
<ogra_> ah
<abeato> ogra_, https://github.com/RPi-Distro/repo/issues/22
<ogra_> yeah, we're a bit behind with the firmware files ... better safe than sorry :P
<abeato> indeed lol
<ogra_> ppisati, would you mind taking a look at https://github.com/snapcore/pi3-gadget/pull/4 as well ?
<mup> PR pi3-gadget#4: Add support to boot from USB <Created by alfonsosanchezbeato> <https://github.com/snapcore/pi3-gadget/pull/4>
<ogra_> ppisati, looks all fine from my POV ... but i'd like a second pair of eyes
<bull> help me anyone know how to use local parts/plugin in snapcraft ??
<bull> ogra_,  :(
<shuduo> sergiusens, ping
 * ogra_ wonders if ppisati ignores #snappy today :P
<ppisati> ogra_: nope, just juggling some stuff
<ogra_> ah, k, you were so quiet :)
<ppisati> ogra_: the days before PTO are always the best...
<ogra_> go on juggling then ;)
<mup> PR snapcraft#984 opened: parser - Make output better <Created by josepht> <https://github.com/snapcore/snapcraft/pull/984>
<ppisati> ogra_: looks good too
<ogra_> ppisati, thx ... also see my former ping about the edge kernel
<ogra_> (no hurry though ... but i'd like it in edge before the weekend ... tomorrow is fione too)
<ppisati> ogra_: this is the tip of the snapcraft.yaml ATM
<ppisati> ogra_: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-snap/+git/xenial/tree/snapcraft.yaml?h=pc
<ppisati> ogra_: kernelversion-abi-uploadnum
<ogra_> ppisati, ah, so not different from what we have now
<ogra_> good, thanks
<mup> PR snapcraft#890 closed: cli: implementing '[list-]registered' command <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/890>
<ogra_> slangasek, hmm, wheer are the actual snap builds for the gadgets now ? i merged some code for pi3 but no snap shows up in the store ... i find https://launchpad.net/snap-pi3 but there seems to be no related snap buuild anywhere
<ogra_> bah
<slangasek> ogra_: we discussed that this was moving to github; where are you merging this code to?
<ogra_> and after 20min searching /me finds the "show snap packages" link at the very bottom of the page above
<ogra_> slangasek, on github :)
<slangasek> so e.g. https://github.com/snapcore/pi3-gadget
<ogra_> right
<ogra_> it just didnt get picked up by any auto-build yet
<slangasek> ok
<ogra_> and https://code.launchpad.net/~canonical-foundations/snap-pi3/+git/github-mirror/+ref/master doesnt seem to have the last merge
<ogra_> oh
<slangasek> ogra_: so you have merged an update that takes a *different* set of undocumented blobs into the pi3 snap? where is the source for the build that's being used?
<ogra_> https://code.launchpad.net/~canonical-foundations/snap-pi3/+git/github-mirror ... only runs every 5h
<ogra_> slangasek, theer is no source for the blobs obviously ... for the uboot side this merge adds instructions with pointers to the source in the README.md
<seb128> is it possible to connect a locally built snap to the content interface from a snap from another provider (canonical) coming from the store?
<seb128> kyrofa, ^ hey, do you know?
<kyrofa> seb128, I _think_ so
<kyrofa> seb128, but that stuff changes fast
<ogra_> slangasek, we can indeed note that the blobs come from https://github.com/raspberrypi/firmware but we still wont get the source
<slangasek> ogra_: pointers> ok
<kyrofa> seb128, last I heard, it won't automatically connect since they aren't from the same publisher but you can still connect them
<slangasek> ogra_: sure; I meant specifically the uboot blob here :P
<kyrofa> seb128, unless the base assertion denies it, that should work
<seb128> kyrofa, I wonder if I'm doing something stupid or using the wrong syntax, it gives me a "(cannot connect plug to slot "gnome318-runtime" from snap "gnome318-udt", no such slot)"
<kyrofa> seb128, pastebin snap interfaces for me?
<ogra_> slangasek, switching to plain-from-soource builds for uboot is on my TODO for early jan. the current blob comes from abeato's disk following the README instructions
<slangasek> ogra_: er, we should discuss this; as I've said before the uboot builds should come from the archive
<pihole> I `dump` some config files with my snap, but I need to modify some values in those files. I typically do this via a shell script running some `sed` commands. Is there a way to run a script after the snap is installed, or do I need to make a custom plugin to do something like this.
<slangasek> ogra_: so that we can use the same uboot source for classic and snappy images via ubuntu-image
<ogra_> slangasek, that was my plan (discussing it first with you and ppisati)
<slangasek> ok
<ogra_> we need an extra patch and thus extra binaries
<ogra_> but you know that already :)
<ondra> abeato did you talk to penk? he's been also trying to boot from USB
<kgunn> JamieBennett: is this still the most "up to date" img for downloading?
<kgunn> http://releases.ubuntu.com/ubuntu-core/16/
<ogra_> ondra, should work with the next gadget from edge
<kgunn> ....i know the proposed channel is being updated...just wondering if someone is just starting fresh...is that the most recent img to get
<JamieBennett> kgunn: yes, no new images yet
<kgunn> thanks
<ondra> ogra_ one you blow USB boot fuse, you can still boot from sdcard
<ogra_> ondra, yes, but you use differenmt ROM code ...
<ogra_> ondra, rto test the original path you still need a pi that hasnt been changed
<abeato> ondra, I saw his post, was a nice way to get started :). But we wanted to remove completely the SD card, with the merges you changed that is possible now
<abeato> *you merged
<abeato> changes you merged
<abeato> lol
<ondra> abeato cool
<mup> PR snapcraft#985 opened: Better message for missing snapcraft.yaml in origins <Created by josepht> <https://github.com/snapcore/snapcraft/pull/985>
<kyrofa> kgunn, got a sec?
<mup> PR snapcraft#960 closed: pluginhandler: install scriptlet support <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/960>
<mup> PR snapcraft#977 closed: Prefer in-snap libraries to system libraries <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/977>
<kgunn> kyrofa: whats up
<kyrofa> kgunn, bug #1639831 . You're saying that on the prime step, those libs are being sucked from the system. Is that right?
<mup> Bug #1639831: filter unwanted pkgs in snap creation when relying on content interface <Snapcraft:Incomplete> <https://launchpad.net/bugs/1639831>
<niemeyer> alex-abreu: What's your GH nick?
<alex-abreu> niemeyer, AlexandreAbreu
<niemeyer> alex-abreu: Cheers
<kyrofa> kgunn, i.e. what elopio recommended there isn't a solution?
<niemeyer> JamieBennett: Yeah, not to the add to the team, but the problem is that most people are not even in the organization of course
<niemeyer> Their model works best when the whole org is part of GH, which doesn't sound so typical actually
<niemeyer> alex-abreu: You've been invited into the team
<alex-abreu> niemeyer, thx
<kgunn> kyrofa: right, so when AlbertA was verifying mir-kiosk work, we noticed the GL drivers still being sucked in....which can be misleading/confusing
<kgunn> i think AlbertA did manually verify he was using the GL from the system....
<kyrofa> kgunn, because that stuff should be coming from content sharing, indeed
<stub> I need to transfer a snap name to upstream. Do I revoke my own access, or does someone here need to handle it?
<kgunn> kyrofa: well in the case of GL drivers...it's actually a core i/f
<kgunn> iirc
<kyrofa> kgunn, so snapcraft, in the prime step, craws the prime dir pulling in libraries that resolve on the system
<kyrofa> In the case of content sharing, you specifically don't want to do that (at least for the libs within the shared snap)
<kyrofa> kgunn, unfortunately we don't really have a way of knowing what's contained within the shared snap
<kyrofa> kgunn, would you favor the ability to disable that crawling completely?
<kgunn> thinking
<mup> PR snapcraft#986 opened: Clean up snapcraft-parser help <Created by josepht> <https://github.com/snapcore/snapcraft/pull/986>
<mup> PR snapd#2487 closed: overlord/snapstate: implement snapstate.ResetAliases <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2487>
<kgunn> kyrofa: i wouldn't think disabling crawling completely would be good...
<kgunn> but not sure what the right answer would be
<kyrofa> kgunn, yeah it's not ideal, but I'm not sure there's a better option
<kgunn> wonder if it's as easy as listing someplace what you want excluded
<kgunn> and if you exclude it, it prevents any deps below it from being satisfied
<kyrofa> kgunn, that's doable, but would be a pain to maintain. Hmm
<kyrofa> kgunn, okay, I'll bring it up at standup today, see if there are some better ideas
<kyrofa> kgunn, but consider that bug un-incompleted
<kgunn> yeah...i mean in our case, we just kept tripping over the gl driver being there...so it was a very specific thing
<kgunn> i just figure it will likely trip up others as things get broken into multiple snaps (system wise) more and more
<kyrofa> Definitely
<stub> I'm going to revoke my access to the name with a comment. Hopefully that is the right thing to do, and upstream can then claim it.
<mup> PR snapd#2494 closed: store: send an explicit X-Ubuntu-Classic header to the store <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2494>
<mup> PR snapcraft#987 opened: pluginhandler: prepare scriptlet support <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/987>
<sergiusens> kyrofa kgunn ideally the SDK for whatever content sharing thing would come from a tarball you can use as a part, then snapcraft is smart enough to know what not to crawl in
<sergiusens> the fact that you have a content shared snap you want to use but provide the "SDK" from some other means allows for skewing and also ties you to building on a certain release
<sergiusens> given that the mechanism now is `build-packages` for everything
<sergiusens> since the content interface is loosly coupled we cannot do much about this
<kyrofa> sergiusens, yeah that would work, it wouldn't pull libs that were staged
<sergiusens> personally I believe the strategy for the SDK to use a "platform snap" needs some tuning
<kyrofa> sergiusens, how would you approach that?
<sergiusens> kyrofa create a snap with just -dev stage-packages maybe
<sergiusens> not sure, need to sit down and experiment I guess
<kyrofa> i.e. less of a platform, more of just an SDK?
<seb128> kyrofa, sergiusens, you shouldn't rely only on the smart behaviour, while playing with my demo snap I used a trivial snapcraft.yaml with the dump plugin copying a binary from my system
<seb128> that should be possible for hackers to do
<seb128> without having to pull in a sdk just to trick snapcraft in doing what the user wants
<kyrofa> seb128, yeah, we're just talking through how content sharing would best be done in snapcraft, while still being able to take advantage of snapcraft's smarts. An option to disable the crawling is still something we're talking about
<seb128> good
<kyrofa> Because just an all-or-nothing isn't ideal, either
<seb128> right, it's not ideal
<seb128> but it gives a way to get things to work
<seb128> where there is none today
<kyrofa> Indeed, it gives power users power
<kyrofa> And that's not exactly true-- if you could stage a tarball of shared content, snapcraft wouldn't pull those libs from elsewhere
<kyrofa> seb128, how do you "build against" a shared snap?
<seb128> currently for gtk I'm using the xenial debs for building the framework snap
<kyrofa> And then when building clients for it, using the xenial debs again?
<seb128> so "use xenial desktop" is the recommendation for building
<seb128> like use snapcraft on a xenial install
<seb128> but the plan for next step is probably to pull the -dev packages
<seb128> and exclude them from the snap
<seb128> but create a tar from the stage
<seb128> and upload that as a remote part somewhere
<kyrofa> Yeah, then build against that
<seb128> right
<kyrofa> That's what we were thinking, too. And snapcraft wouldn't pull those libs from the system, in that case
<seb128> right
<kyrofa> (snapcraft would work with that today)
<kyrofa> And that wouldn't be tricking snapcraft into doing what the user wants, it would be the user doing things the right way (building against what's contained in the snap)
<seb128> indeed
<mup> PR snapcraft#977 opened: Prefer in-snap libraries to system libraries <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/977>
<cachio> jdstrand, I saw the dbus branch has been merged
<jdstrand> cachio: it has :)
<cachio> jdstrand, is it gonna to be ready in edge tomorrow?
<jdstrand> cachio: it is in master slated for 2.20. I don't know the status of when 2.20 will be available. JamieBennett, can you answer?
<jdstrand> JamieBennett: and hi! :)
<JamieBennett> jdstrand: cachio: We are hoping to release tonight, last minute changes but in the next few hours, fingers-crossed
<cachio> JamieBennett, jdstrand nice, I'll try tomorrow in that case
<niemeyer> jdstrand: Do you happen to know what the status of snapd#2417 is?  You've reviewed it a couple of days ago, and some changes got applied, but it's not clear if it's ready or not
<mup> PR snapd#2417: interfaces/builtin: add uhid interface <Created by bergotorino> <https://github.com/snapcore/snapd/pull/2417>
<jdstrand> niemeyer: it is on my list to re-re-review today :)
<jdstrand> there's three. this, unity-pim and download manager
<mup> PR snapd#2465 closed: snap: show apps in `snap info` <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2465>
<niemeyer> jdstrand: Ack, thanks
<mup> PR snapd#2495 opened: Add Priced status to go client definitions <Created by AlexandreAbreu> <https://github.com/snapcore/snapd/pull/2495>
<mup> PR snapd#2419 closed: store: retry downloads on io.Copy errors and sha3 checksum errors <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2419>
<mup> PR snapd#2491 closed: debian: use a packaging branch for 14.04 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2491>
<elfgoh_> Anybody knows the roadmap for BBB support?
<mup> PR snapd#2490 closed: many: implement  "snap alias --reset" using snapstate.ResetAliases <Critical> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2490>
<mup> PR snapcraft#988 opened: pluginhandler: build scriptlet support <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/988>
<tsutsu> is there a way to avoid a hard restart of a daemon during a snap update? for example, to get nginx's SIGUSR2 graceful upgrade semantics, or erlang's hot-code-upgrade relup semantics?
<kyrofa> tsutsu, have you played with the stop-command for the daemons?
<kyrofa> I'm not sure how it's implemented, but may be a path to explore
<mup> PR snapd#2496 opened: release: version 2.20 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2496>
<mfeatherston> I have just ubuntu core installed on an arm system and I'm trying to make it run any graphical demo.  What provides X11 in this case?
<kyrofa> mfeatherston, you probably want the mir server stuff kgunn has been working on
<mfeatherston> I'd be up for trying that, but is X11 still possible for now?  I have a resistive touchscreen, I'm not sure how/if mir supports the calibration for that.
<kyrofa> mfeatherston, not that I know of anyway
<kgunn> mfeatherston: what resistive touchscreen do you have?
<kgunn> as for calibration.... we should ask camako
<mfeatherston> I ported support for our board here:
<mfeatherston> https://www.embeddedarm.com/products/TS-TPC-8390-4900
<kgunn> who might point to someone else on the mir team
<mfeatherston> This is a ads7846 touch controller
<mfeatherston> Worst case if it can read the ABS stuff I can hardcode the calibration in the kernel for a demo
<kgunn> yeah, mfeatherston, would love for you to give the mir-snaps stuff a shot
<mfeatherston> how can I install that?
<kgunn> you've got a link to the wiki?
<kgunn> oh...lemme get it
<kgunn> https://developer.ubuntu.com/en/snappy/guides/mir-snaps/
<kgunn> mfeatherston: assuming you're kinda familiar and have your core up and running...just follow the "Quick Start" bits
<mfeatherston> Cool, I'll give this a try.  Thanks!
<kgunn> mfeatherston: and definitely ping me if you run into issues...
<kgunn> mfeatherston: if you hit issues you think are purely gfx/input...feel free to ping  in #ubuntu-mir
<kgunn> and others in there can be helpful
<mup> Bug #1650389 opened: Installing snapd on 14.04.5 desktop downgrades xorg et al. <14.04> <Snappy:New> <https://launchpad.net/bugs/1650389>
<mfeatherston> kgunn: after installing mir-kiosk it failed with "cannot bind-mount the mount namespace file /proc/2422/ns/mnt -> mir-kiosk.mnt. errmsg: Permission denied".  It's possible I missed a kernel config option this would need, but namespace support is present
<mfeatherston> ahh, he just left
<flexiondotorg> kyrofa, Do you remember that issue I mentioned last week regarding source-type:deb not correctly creating symlinks in debs?
<kyrofa> flexiondotorg, indeed, and I have a fix for it, but ran into packaging issues from pip
<flexiondotorg> Ooh.
<kyrofa> flexiondotorg, it's a known issue in python3-apt, but python3-deb (which works better) has some installation issues when using pip. I need to investigate
<flexiondotorg> I'm talking to a popular music streaming service tomorrow.
<flexiondotorg> I've got a snap
<flexiondotorg> kyrofa, Do you have a branch with those changes?
<kyrofa> flexiondotorg, if you're willing to run out of a branch, I've got a fix for you
<kyrofa> Yep, one sec
<flexiondotorg> I'm prepared to take a look now :-)
<flexiondotorg> I've got two significant ISVs where this would be good to fix.
<kyrofa> flexiondotorg, thanks for the reminder. I'll see if I can't dig into this a bit tonight
<flexiondotorg> Well, I've got sometime now.
<flexiondotorg> To take a peek.
<kyrofa> flexiondotorg, here's the PR with branch attached: https://github.com/snapcore/snapcraft/pull/941
<mup> PR snapcraft#941: Support symlinks within deb sources <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/941>
<kyrofa> If you take a look at the tests you'll see what I mean
<mup> PR snapcraft#989 opened: Add support for disabling system library migration <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/989>
#snappy 2016-12-16
<flexiondotorg> kyrofa, I notice there is a newer Debian package of python-debian that upstream tarball
<flexiondotorg> https://packages.debian.org/sid/python-debian
<flexiondotorg> https://pypi.python.org/pypi/python-debian
<flexiondotorg> Nothing significant.
<flexiondotorg> kyrofa, Could it be you just need python3-chardet?
<flexiondotorg> https://pypi.python.org/pypi/chardet
<flexiondotorg> https://travis-ci.org/snapcore/snapcraft/jobs/180859624#L1178
<flexiondotorg> Hmm, that should be pulled in.
<flexiondotorg> pip install python-debian into a clean virtual env doesn't pull in chardet.
<flexiondotorg> By the python3-debian deb does list python3-chardet as Depends:
<flexiondotorg> kyrofa, Might worth putting 'chardet' in one of the requirements files.
<flexiondotorg> https://github.com/romlok/python-debian/blob/master/lib/debian/deb822.py#L35
<mup> PR snapcraft#987 closed: pluginhandler: prepare scriptlet support <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/987>
<mup> PR snapcraft#988 closed: pluginhandler: build scriptlet support <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/988>
<mup> PR snapcraft#981 closed: Support download and validate on branded stores <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/981>
<mup> PR snapcraft#982 closed: parser - Use the same version method as 'snapcraft' <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/982>
<mup> PR snapcraft#974 closed: Updated maven plugin to use get_build_properties() <Created by ZenHarbinger> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/974>
<mup> PR snapcraft#975 closed: Updated gradle plugin to use get_build_properties()  <Created by ZenHarbinger> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/975>
<mup> PR snapcraft#978 closed: Updated cmake plugin to use get_build_properties() <Created by ZenHarbinger> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/978>
<mup> PR snapcraft#979 closed: Updated waf plugin to use get_build_properties() <Created by ZenHarbinger> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/979>
<mup> PR snapcraft#983 closed: Updated scons plugin to use get_build_properties() <Created by ZenHarbinger> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/983>
<mup> PR snapcraft#990 opened: Fix snaps tests in armhf <Created by elopio> <https://github.com/snapcore/snapcraft/pull/990>
<shuduo> hello, is there a way like web interface to manage the keys I created and registered?
<mup> Bug #1641631 opened: Raspberry Pi images do not support boot from USB <Snappy:Fix Committed by alfonsosanchezbeato> <https://launchpad.net/bugs/1641631>
<kalikiana_> Hrm. Isn't "stable" supposed to imply snaps in there were tested? I discovered "tmx" by chance, installed it and find myself unable to run it. It quits with "Error opening terminal: " regardless of what my TERM is. I kind of want a "snap report-broken tmx" command.
<kalikiana_> The name 'caozhen' shown in "snap list" doesn't help me either
<mcphail> kalikiana_: "stable" just means it was uploaded to that part of the store and passed some automatic security checks. There's no guarantee the snap actually works
<shuduo> ogra_: hi, may i know if audio including micphone recording and playback working on any reference board with latest UC16?
<ogra_> shuduo, i must admit., i dont know ... i know there is pulseaudio support (so playback should be fine) but i dont kbnow about recording
<ogra_> perhaps morphis can tell :)
<shuduo> ogra_: good to know playback works. morphis, hello, may i know what status audio function on UC16 now?
<kalikiana_> mcphail: Well, I can see that much. Doesn't make it a good experience, though
<kalikiana_> Considering stable has requirements like 'no devmode' it seems futile if "in working condition" isn't part of those
<kalikiana_> Or, as I said, if I could at least manually intervene. For all I know the developer is able to run the snap on their machine. But I can't ask them
<marrek22> hi i try to install ubuntu core on my pi but it says no ssh key to my account
<ogra_> did you upload one on login.ubuntu.com ?
<marrek22> no where can I find the key
<ogra_> https://help.ubuntu.com/community/SSH/OpenSSH/Keys
<marrek22> but how can I generate a key when I can't login to the pi
<ogra_> generate one ... upload the public part to login.u.c and make sure the machine you try to log in from later has the private bit
<ogra_> (this is all between your PC and login.ubuntu.com ... the pi only comes into play later)
<longsleep> ogra_: hey do you know if the snap-confine changes related to aa confinment have landed in snapd and if those are available now through edge channel? It was this https://github.com/snapcore/snap-confine/tree/use-aa-support tree but its no longer there :/
<ogra_> longsleep, if they landed in 2.20 they are most likely not in edge yet (2.20 only landed and there was no auto-build of the edge core snap since i think)
<ogra_> ICBW though ... and mvo did a re-spin
<longsleep> ogra_: ok, how does one check what actually is in edge channel?
<ogra_> hmm, not sure if uappexplorer shows the version
<ogra_> ah, well, it wouldnt show edge anyway
<ogra_> one sec
<ogra_> longsleep, http://people.canonical.com/~ogra/core-builds/ has logs and versions of the auto-builds (but no manual ones so it could be there is something newer if someone did a manual build via LP)
<longsleep> ogra_: ok cool, let me see if i can actually find the change
<ogra_> oh
<ogra_> and i see snapd 2.20 in the manifest !
<longsleep> ogra_: in the last build it logs snapd	2.20~ppa2
<ogra_> yeah
<ogra_> so if that fis is in 2.20 you should have it in edge then
<longsleep> ogra_: yeah - so that would be good if the aa change has actually been merged
<ogra_> right
<longsleep> ogra_: zyga is on holidays already? Would be easiest if i could just ask him :P
<ogra_> i think he is, yeah
<ara> is there a way for "snap list" to return the channel as well?
<ogra_> probably in snap info
<ogra_> yeah
<ogra_> ogra@pi3:~$ snap info htop |grep tracking
<ogra_> tracking:    stable
<ogra_> ogra@pi3:~$
<mup> Bug #1650520 opened: Qt's bearer needs access to NetworkManager APIs <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1650520>
<kalikiana_> ara: It's always stable if you can see it in "snap list"
<ara> kalikiana_, I guess you are saying "can't"?
<ara> kalikiana_, thanks!
<ogra_> ara, well, you could grab the list and loop over it with snap info (see above)
<kalikiana_> Oh, maybe I misunderstood. I thought this was looking for installable snaps - obviously the ones already on the system can be from any source
<ogra_> kalikiana_, my install tracks edge completely ... with that theory i wouldntz see anything in snap list ;)
<ara> ogra_, ah, ok :) I guess we could file a UX bug :)
<kalikiana_> ogra_: I tend to mixup snap list/find because they're so similar
<ogra_> ah, yeah, find only shows stable
<mup> PR snapd#2497 opened: Clean mount namespace when mount changes <Created by tsdgeos> <https://github.com/snapcore/snapd/pull/2497>
<rvr> fgimenez: Hi
<rvr> fgimenez: Did anything change to run spread tests?
<rvr> fgimenez: I get this: error: $(HOST: ./generate-packaging-dir ubuntu 14.04) in project environment returned error: ./generate-packaging-dir: 12: ./generate-packaging-dir: git: not found; ./generate-packaging-dir: 13: ./generate-packaging-dir: git: not found
<mup> PR snapd#2497 closed: Clean mount namespace when mount changes <Created by tsdgeos> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2497>
<fgimenez> hey rvr, looking
<rvr> fgimenez: I commented this line
<rvr>     # slight abuse
<rvr>     # GENERATE_14_04: "$(HOST: ./generate-packaging-dir ubuntu 14.04)"
<rvr> fgimenez: in spread.yaml
<fgimenez> rvr, yes, that should be enough, it seems that failed because git is not available on your host, is that the case?
<rvr> fgimenez: Nope, it is available
<rvr> fgimenez: I am running the tests on the git-cloned directory
<fgimenez> rvr, mm the error you pasted is pretty clear "./generate-packaging-dir: 13: ./generate-packaging-dir: git: not found" maybe it is not available in $PATH during the script execution, what is the output of "which git"?
<rvr> fgimenez: /usr/bin/git :P
<fgimenez> rvr, or better, git remote | grep upstream
<fgimenez> rvr, and git remote add upstream https://github.com/snapcore/snapd
<rvr> $ git remote | grep upstream --> No output
<rvr> fgimenez: What is that expected?
<rvr> Sorry, why
<fgimenez> rvr, that is the command that seems to fail for you in generate-packaging-dir
<rvr> I mean, why is git needed to run the tests?
<cachio> jdstrand, hey?
<cachio> jdstrand, is the dbus interface in http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/?
<fgimenez> rvr, not sure, it seems that some test needs that packaging dir in place
<ogra_> cachio, if you know the deb versions you need http://people.canonical.com/~ogra/core-builds/ has links to the manifest files for the core snaps
<cachio> ogra_, nice, thanks
<jdstrand> cachio: I don't know. 2.20~ppa2 has it according to https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages
<jdstrand> cachio: https://launchpadlibrarian.net/288335774/core_16.04.1_amd64.manifest has 2.16
<jdstrand> oh, hold on
<jdstrand> https://launchpadlibrarian.net/298419516/core_16.04.1_amd64.manifest shows 2.20, so yes, it should have it
<ogra_> 2.20 is in the last core ...
<ogra_> but i'm not 100% sure the last core is also in the last image yet, you might need to snap refresh it
<ogra_> will definitely be in tomorrows daily
<cachio> ogra_, ok, I'll update the core in that case
<ogra_> just check with snap list first :)
<cachio> ogra_, sure, tx
<mup> PR snapcraft#991 opened: Updated ant plugin to use get_build_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/991>
<mup> PR snapcraft#992 opened: Updated make plugin to use get_build_properties()  <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/992>
<rvr> fginther: Three failures in the candidate image (custom built) http://paste.ubuntu.com/23638197/
<rvr> Oops
<rvr> fgimenez: ^
<fgimenez> rvr, it seems that you are using an outdated version of spread, that should explain the two errors about "/bin/bash: line 54: MATCH: command not found"
<fgimenez> rvr, you had before the tests/main/ubuntu-core-reboot error, the service doesn't comes up on time after reboot, i haven't been able to reproduce
<rvr> fgimenez: I did a git pull just before running the tests
<fgimenez> rvr, the tests/main/interfaces-mount-observe error is strange, an EOF in the middle of a test can be caused by an unexpected reboot or a lost of connection
<fgimenez> rvr, i mean the spread executable
<rvr> fgimenez: Oh, I see
<rvr> Ok, upgraded
<rvr> fgimenez: Yes, seems the connection was lost
<rvr> fgimenez: System is in initramfs prompt :P
<mup> PR snapcraft#993 opened: Updated qmake to use get_build_properties and get_pull_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/993>
<rvr> I remember we had this problem before
<fgimenez> rvr, this is executed on a dragonboard, right?
<rvr> fgimenez: Right
<fgimenez> rvr, we had problems before with the tests/main/ubuntu-core-upgrade test, it seems that some state is left behind after the cycle of checks and the system believes that it needs to reboot to finish an upgrade, because the core snap version that is supposed to be upgraded to is not actually there, the system crashes
<fgimenez> rvr, that would explain the EOF you had too
<rvr> fgimenez: Yes, because it cannot connect to the system anymore
<rvr> But it also breaks it completely, that's ugly :(
<fgimenez> rvr, this test problem should be already fixed, we need to verify, anyway, could you please execute the suite again removing tests/main/ubuntu-core-upgrade folder from snapd's tree? you should need to reflash the image too
<rvr> fgimenez: Sure, and will use the available images
<fgimenez> rvr, great, thanks!
<cachio> jdstrand, to use that interface, should I do something special?
<cachio> jdstrand, I rat the tests and those are still getting the same erroro
<cachio> jdstrand,  dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NameHasNoOwner: Could not get owner of name 'com.canonical.kpi.signal': no such name
<mup> PR snapd#2499 opened: tests: add super simple classic confinement test <Created by mvo5> <https://github.com/snapcore/snapd/pull/2499>
<cachio> jdstrand, this is the config file that I am using http://paste.ubuntu.com/23638496/
<jdstrand> cachio: yes, you need to declare what you are going to use
<jdstrand> https://github.com/snapcore/snapd/wiki/Interfaces#dbus has the details
<jdstrand> cachio: but essentially add this to your yaml:
<jdstrand> slots:
<mup> Bug #1650520 changed: Qt's bearer needs access to NetworkManager APIs <snapd-interface> <Snappy:Invalid> <https://launchpad.net/bugs/1650520>
<jdstrand>   kpi-dbus:
<jdstrand>     interface: dbus
<jdstrand>     bus: system
<jdstrand>     name: com.canonical.kpi.signal
<cachio> jdstrand, ok, make sense
<jdstrand> cachio: that should give you a bus policy very similar to what you pasted
<jdstrand> cachio: similar, becuase 'default' doesn't allow 'own'
<cachio> ok, so i dont need to copy the config file anymore, right?
<jdstrand> no
<jdstrand> cachio: depending on how your snap is written, it may even work in strict mode
<jdstrand> cachio: but if you have a complicated dbus api, you might still need to use devmode
<cachio> ok, I'll try with this new conf, thanks!!
<jdstrand> (see the documentation for what I mean by that)
<mup> PR snapcraft#994 opened: Updated kbuild plugin to use get_build_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/994>
<mup> PR snapcraft#995 opened: Updated kernel plugin to use get_build_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/995>
<mup> PR snapd#2500 opened: tests: run snap confine tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/2500>
<mup> PR snapcraft#996 opened: Updated nodejs plugin to use get_build_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/996>
<mup> PR snapcraft#997 opened: Updated gulp plugin to use get_build_properties() and get_pull_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/997>
<mup> PR snapcraft#998 opened: Updated gulp plugin to use get_build_properties() and get_pull_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/998>
<rvr> fgimenez: spread -v -reuse external:ubuntu-core-16-arm-64 doesn't work as command line now
<rvr> error: invalid project name: ""
<rvr> And --help doesn't help X-)
<mup> PR snapcraft#999 opened: Updated autotools plugin to use get_build_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/999>
<rvr> This error is familiar to me
<rvr> It used to happen before, and we were force to use another version of spread
<rvr> Is it not solved yet?
<fgimenez> rvr, iirc that was happening before because spread wasn't installed with the --devmode option
<rvr> fgimenez: Hmmm
<rvr> fgimenez: I did a refresh
<rvr> Hmmm
<rvr> Does it keep the --devmode?
<fgimenez> rvr you can check with snap list
<rvr> fgimenez: Thanks, you were right. I reinstalled with --devmode and it works now.
<fgimenez> rvr, np :) good to know
<kyrofa> flexiondotorg, yeah that would probably work, but doesn't that mean that python-debian doesn't specify all of ITS dependencies?
<kyrofa> flexiondotorg, by the way, the debian package python3-debian works fine. But in our baby steps toward snapping it, we're trying to make sure it works from pip as much as possible
<kyrofa> barry, you know all there is to know about python-debian, right? ;)
<barry> kyrofa: oh sure ;)
<barry> kyrofa: what's up?
<kyrofa> barry, any idea why the debian package depends upon chardet, but pip doesn't (and fails as a result)?
<mup> PR snapd#2501 opened: tests: enable the ppc64el tests again <Created by mvo5> <https://github.com/snapcore/snapd/pull/2501>
<barry> kyrofa: it all has to do with vendorizing (long explanation follows)
<barry> upstream pip "vendors" several packages, meaning it comes with its own private copies of things.  other packages do this, e.g. requests
<kyrofa> Ah, but you can't do that in debian packages
<barry> this violates debian policy because say there were a security vulnerability in chardet, fixing python-chardet wouldn't fix pip's use of it
<barry> so we devendorize, meaning adjust those packages to use system versions intsead of their private copies.  which is easier for some packages and harder for others
<barry> pip upstream is friendly to our needs, so pip is rather easy to devendorize
<barry> and when we build pip we "rewheel" a bunch of packages, meaning we turn their debian layout back into a wheel, and then arrange for the wheel to be used by pip.  we label these with Built-Using in pip's d/control
<barry> chardet is one of the rewheel'd packages
<barry> kyrofa: exactly
<kyrofa> barry, okay, that makes perfect sense
<kyrofa> barry, though it doesn't explain the failure I'm seeing: https://travis-ci.org/snapcore/snapcraft/jobs/180859624
<kyrofa> (scroll to the bottom)
<kyrofa> I added python-debian to the requirements.txt, and that's the result
<barry> let me check something
<barry> kyrofa: that's interesting because python3-debian definitely Depends explicitly on python3-chardet
<barry> (at least in unstable)
<kyrofa> barry, that failure isn't installing the deb though-- that one is using the requirements.txt to install it
<longsleep> I still fail to register my key with snapcraft, 'account-key-request' assertion failed - anyone here to help now?
<kyrofa> barry, it's worth noting that, if I use python3-debian instead of the pip package for all tests, everything works fine
<kyrofa> barry, this is the PR corresponding to that test run, by the way: https://github.com/snapcore/snapcraft/pull/941/files#diff-b4ef698db8ca845e5845c4618278f29aR19
<mup> PR snapcraft#941: Support symlinks within deb sources <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/941>
<barry> so that would get it through pypi, which looks relatively up-to-date (it's a version behind the unstable version)
<barry> kyrofa: so i think the problem is that pypi's python-debian 0.1.28 doesn't have an install_requires on chardet, and chardet isn't in your requirements.txt, so pip never thinks it needs to install it.  that sounds like a bug in the upstream package setup.py
<kyrofa> barry, indeed, my thoughts as well
<kyrofa> barry, shall I report that?
<barry> kyrofa: no need :) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838695
<kyrofa> Ha!
 * barry sees if he can commit the fix to $vcs
<kyrofa> barry, so adding chardet to my requirements.txt is a satisfactory workaround? Just use the latest version?
<barry> kyrofa: yep, that should work
<kyrofa> barry, okay thank you, and thanks for taking a look at that bug!
<barry> kyrofa: np!  that's what i'm here for :)
<barry> yep, nope, i can't push to its repo, so i'll just follow up on the bug
<mup> PR snapcraft#1000 opened: Updated godeps plugin to use get_pull_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/1000>
<mup> PR snapcraft#977 closed: Prefer in-snap libraries to system libraries <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/977>
<mup> PR snapcraft#1001 opened: Updated catkin plugin to use get_pull_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/1001>
<mup> PR snapcraft#1002 opened: Updated python plugin to support get_pull_properties <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/1002>
<mup> PR snapcraft#1003 opened: Release changelog for 2.24 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1003>
<mfeatherston> I'm working on an ubuntu core image and I need to include some system firwmare.  Is there some way for me to overlay files in /lib/firwmare?
<ogra_> mfeatherston, in the gadget snap
<mfeatherston> This is what I was trying: https://paste.ee/p/zMQFX
<ogra_> (or alternatively you can roll your own kernel snap and ship them there)
<mfeatherston> I'm also doing that, but I didn't see a way to pack the firmware in the kernel
<ogra_> if /lib/firmware is in there it gets used
<mfeatherston> /lib/firmware is missing from the filesystem as far as I can tell, but they show up in /writable/system-data/snap/tsimx6-gadget/x1/firmware/ and /snap/tsimx6-gadget/x1/firmware/
<mfeatherston> well, I should rephrase that, the contents in /lib/firwmare I expect are missing
<mfeatherston> the standard /lib/firwmare is there
<kyrofa> flexiondotorg, I've updated bugfix/1634813/support_debs_containing_symlinks bringing it up to date with master and also adding chardet to the requirements. This should pass tests as soon as I propose it, though I'm waiting to do that so I don't steal adt resources from release
<flexiondotorg> kyrofa, Thanks for the update :-)
<rvr> fgimenez: http://paste.ubuntu.com/23639009/
<mfeatherston> ogra_, thanks packing it in the kernel will work for me.  I see others from my build present there.
<fgimenez> rvr, seems that the connection was lost again, but without EOF this time, i'll try to reproduce
<robertkowalski> hi
<robertkowalski> i'm on the apache couchdb project
<robertkowalski> and want to register the snap "couchdb"
<robertkowalski> it says the name is registered
<robertkowalski> and the text mentiones one can request the name, but i don't find instructions where to go for that anywhere
<robertkowalski> i found it out, the button changes to "request resverd name"
<kyrofa> robertkowalski, does it say it's already registered, or that it's reserved?
<kyrofa> nessita, can you help with the couchdb name? ^^
<mup> PR snapcraft#994 closed: Updated kbuild plugin to use get_build_properties() <Created by ZenHarbinger> <Closed by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/994>
<flexiondotorg> robertkowalski, If you scroll down the page, you;ll notice the button text has changed.
<flexiondotorg> robertkowalski, I was working with another project and they had the same issue.
<flexiondotorg> They didn't notice that the 'Register and proceed to upload' button had also changed to 'Submit name dispute' because that button is rendered off-screen even on a 1080p display.
<flexiondotorg> So add a comment to support you name claim and click Submit name dispute :-)
<kyrofa> flexiondotorg, I bet it's rendered offscreen on my 4k screen too due to the scaling I have to apply to see anything :P
<flexiondotorg> It is. I have that issue. First world problems ;-)
<kyrofa> Hahaha
<flexiondotorg> Night snappers, time for the pub :-)
<robertkowalski> thank you!
<robertkowalski> solved!
<robertkowalski> yes the button was hard to find
<kyrofa> Night flexiondotorg, have a good weekend!
<mup> PR snapcraft#941 opened: Support symlinks within deb sources <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/941>
<mup> PR snapcraft#1004 opened: Add aliases integration test <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1004>
<kyrofa> seb128, if you're interested: https://github.com/snapcore/snapcraft/pull/989
<mup> PR snapcraft#989: Add support for disabling system library migration <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/989>
<knight__> So with Ubuntu Core there's no deb package support, correct?
<mup> PR snapcraft#1003 closed: Release changelog for 2.24 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1003>
<madhatter05> hello i am trying to set up ssh keys for my Ubuntu core. the website just has a box on where to import the key.
<madhatter05> how do i gen one on windows
<mfeatherston> knight__, correct
<knight__> So if I want to install something that does not yet have a snap, I have to either 1) install compilers and any required libs, then compile the app, or 2) step #1 and make a snap... is that right?
<mfeatherston> what target are you looking to build for?
<mfeatherston> I think in most cases you need to end up actually building a snap to run an application on ubuntu core
<knight__> target is raspberry pi 3
<knight__> (arm)
<mfeatherston> You'll probably be cross compiling everything you need from a host pc.  It's not really set up to do development on the unit.
<knight__> Ok. Are there docker or Parallels images that can do the snap development?
<mfeatherston> I don't know if there are any premade vm images but you could just put Ubuntu in a VM for development
<nacc> you can do `snapcraft cleanbuild` as well using lxd
<ssweeny> knight__: you can use the classic snap to essentially create a classic ubuntu container
<ssweeny> from there you can install debs and go nuts
<knight__> ssweeny, but you don't recommend that for core on embedded right? that's just for a dev environment
<ssweeny> knight__: I use it to build arm snaps
<knight__> gotcha, right, because the environment more closely matches
<knight__> nacc, snapcraft cleanbuild?
<ssweeny> cleanbuild creates a lxc container on the fly and does the build from scratch
<ssweeny> it's good for ensuring that you didn't miss any dependencies (like build-packages) because they were already on your host
<knight__> ah ha
<Mritunjai> Hi All
<mup> Bug #1650671 opened: Content sharing from snap common is broken <Snappy:New> <https://launchpad.net/bugs/1650671>
<jdstrand> roadmr, nessita: hey, fyi, there are several snaps in the review queue that seem stuck between upload and being reviews. 'task state unknown', 'Automated review for version 0.1: invalid'
<roadmr> jdstrand: nessita is off today and I'm almost EOD :( which ones? :(
<roadmr> jdstrand: recent uploads?
<jdstrand> https://myapps.developer.ubuntu.com/dev/click-apps/6525/rev/1/
<jdstrand> https://myapps.developer.ubuntu.com/dev/click-apps/5243/rev/12/
<roadmr> jdstrand: do you know if this uses classic confinement?
<jdstrand> roadmr: they are both clicks
<roadmr> jdstrand: so not classic :)
<jdstrand> no :)
<knight__> Is there a way to define some command line steps that have to take place before the plugin (make in this case) kicks in?
<roadmr> jdstrand: ok... yes, we had an issue with clicks trying to check the package_declaration (not there for clicks!) for classic allowance. We fixed one, didn't know about these two, but the timing seems about right.
<roadmr> jdstrand: I think they need manual fixing :( I'll see what I can do but it may need to wait for Monday :(
<jdstrand> roadmr: well, I don't know your procedures for that, but I just wanted to make sure you guys knew about them
<roadmr> jdstrand: I don't think we did, or we would have fixed them yesterday :( thanks for the heads-up
<jdstrand> roadmr: well, you know now :)
<roadmr> many thanks :)
<jdstrand> lool: hey, so you have 26 revisions of elasticsearch-smb all with the same error: package contains external symlinks: usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts lint-snap-v2_external_symlinks
<jdstrand> lool: I'm pretty sure that is going to make the snap's ssl connections fail. can you remove/withdraw r1-r26 and then upload an r27 with that fixed?
<knight__> A part I am trying to build requires a directory to be made before the make is run, and I can't quite figure out how to run arbitrary commands before the make plugin builds the source.
<roadmr> jdstrand: the queue looks quite clean, so I'm going to venture saying there weren't any other packages in that "invalid" state? (I'm working on fixing these two, wanted to check if there are more I can process at the same time)
<knight__> Can you specify commands that need to run in a snapcraft.yaml?
<jdstrand> robertkowalski: just those two
<jdstrand> robertkowalski: sorry, nm
<lool> jdstrand: elasticsearch-smb: yup, actually rmescandon has sent a fix, I told him to push it to master for LP to pick it up; the snap is owned by me but LP pushes the builds; note that this is probably an issue for all snaps with default-jre-headless
<jdstrand> lool: it used to always be (that is how I know that the ssl doesn't work), but a recent package I did had snapcraft fixing it up. please file a bug
<jdstrand> I know sergiusens is aware of this issue
<lool> jdstrand: is that a fix in a jre package in z or a fix in snapcraft?
<lool> rmescandon pushed a workaround in the snap, but didn't merge i
<lool> it
<jdstrand> lool: snapcraft afaik
<jdstrand> there is a symlink in the jre package that gets created and snapcraft I think attempts to clean it up
<lool> yeah, it's supposed to
<lool> I see some fairly old commits around this in the snapcraft history
<lool> I'll file a new bug against snapcraft
<lool> jdstrand: https://bugs.launchpad.net/snapcraft/+bug/1650686
<mup> Bug #1650686: Some symlinks not properly fixed up <Snapcraft:New> <https://launchpad.net/bugs/1650686>
<lool> jdstrand: thanks for attempting a review and have a good WE
<jdstrand> lool: it's weird. it worked for my minecraft snap. I stage-packages both openjdk-8-jre-headless and ca-certificates-java
<lool> jdstrand: ah maybe I need ca-certificates-java
<lool> jdstrand: BTW we should arrange for this lint checks to be run in local snapcraft runs somehow
<jdstrand> I imagine when both are snaps that will be more feasible
<lool> yeah
<mup> Bug #1650688 opened: timedatectl set-timezone fails on UC16 <Snappy:New> <https://launchpad.net/bugs/1650688>
<mup> Bug #1650689 opened: snap refresh with a channel arg should offer a way to switch the channel w/out a snap update being available <Snappy:New> <https://launchpad.net/bugs/1650689>
#snappy 2016-12-17
<knight__> I'm making good progress on my first snap recipe. Problem is I need to execute a mkdir before the make occurs, since that's in the instructions and it has problems.
<knight__> How do I do that in the snapcraft.yaml?
<nacc> knight__: what do you need to mkdir? aiui, that's not relly something that's generically supported (or wasn't last time i used snapcraft). You would have to write your own (trivial) plugin that did the mkdir first
<kyrofa> knight__, doing such things without writing a plugin is supported in 2.24
<kyrofa> (in proposed)
<kyrofa> nacc, ^^
<mup> PR snapcraft#1006 opened: Replace `snap` filter with `prime` filter <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1006>
<knight__> so it's proposed, but not yet implemented?
<knight__> nacc: the build instructions require a dir to be made before the make starts... the make fails without the dir made... it's stupid i know, but it's out of my control...
<knight__> http://wiki.gridcoin.us/Linux_guide  needs the obj/zerocoin dir made first.
<sergiusens> lool jdstrand https://github.com/snapcore/snapcraft/pull/761 if either of you +1 in there we will merge.
<mup> PR snapcraft#761: Remove dangling symlink from JDK plugin <Created by gnuoy> <https://github.com/snapcore/snapcraft/pull/761>
 * tsimonq2 waves to elopio 
<tsimonq2> I test things sometimes. I'll poke around with Snapcraft. :P
<tsimonq2> I guess I'll have to finish up tomorrow morning. o/
<mup> Bug #1650738 opened: Scan network failure error after first reboot <Snappy:New> <https://launchpad.net/bugs/1650738>
<knight__> Ok folks, so how can I run a mkdir in a snapcraft.yaml?
#snappy 2016-12-18
<mwhudson> er
<mwhudson> why does d/changelog in master have version 2.19?
<mwhudson> oh, there is a release branch
<arm1e> Hi, I have been testing snap package manager on otgher distros but get errors. Can anyone help
<arm1e> http://hastebin.com/ahadeleboc.sql
<OerHeks> arm1e, try with sudo?
<arm1e> tried, but still nothing
<arm1e> same error
<arm1e> Any other ideas?
#snappy 2017-12-11
<mup> Bug #1625279 changed: cmd_run.go:179: WARNING: cannot create user data directory: cannot create "/home/$USER/snap/$SNAP/$VERSION": mkdir /home/$USER/snap/$SNAP: permission-denied <Snappy:Expired> <https://launchpad.net/bugs/1625279>
<haisheng-from-ch> who knows how to do the os.snap?
<mborzecki> morning
<mborzecki> starting late again today
<mborzecki> mvo: morning
<mvo> hey mborzecki - good morning!
<mborzecki> mvo: i played with /dev/random patchset over the weekend, had mixed success rate
<mvo> mborzecki: oh, why? is gpg too smart? or does it not really help?
<mborzecki> one thing that bugs me is that if gpg-agent starts reading /dev/random (the real one) and that out of entropy, simple SIGTERM to gpg-agent has no effect, I actually had to SIGKILL it
<mborzecki> and the highest success rate was when i juggled /dev/random in task's prepare/restore rather than on the project level
<mvo> mborzecki: woah, that is interessting, I would not have expected this
<mup> PR snapd#4385 closed: interfaces/desktop,unity7: allow status/activate/lock of screensavers for 2.30 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4385>
<mup> PR snapd#4384 closed: interfaces/desktop,unity7: allow status/activate/lock of screensavers <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4384>
<mup> PR snapd#4378 closed: tests: do not disable refresh timer on external backend <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4378>
<mup> PR snapd#4379 closed: client: send all snap related bool json fields <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4379>
<mup> PR snapd#4375 closed: interfaces: interfaces: also add an app/hook-specific udev RUN rule for hotplugging for 2.30 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4375>
<mup> PR snapd#4376 closed: tests: fix external backend for tests that need DEBUG output <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4376>
<kalikiana> good morning!
<mvo> hey kalikiana, good morning
<mwhudson> mvo: hey, i've just switched over to golang 1.9 being the default in bionic
<mwhudson> mvo: snapd seems to build fine with it, just wanted you to know
<mvo> mwhudson: great, thank you
<mvo> mwhudson: any discussion on having a golang-1.9 in xenial-updates (just like we have 1.6  for trusty) ?
<mwhudson> mvo: no
<mwhudson> mvo: the latest juju in xenial-updates is a multi-orig bundling go 1.8.3 ...
<mvo> mwhudson: right, I guess we could do the same
<mwhudson> mvo: i /think/ the security team prefer this because it means that we don't end up with golang 1.8 and then 1.9 and then 1.10 all arriving in main and being there until EOL
<mwhudson> mvo: but you should check that with them :)
<mvo> mwhudson: right, it makes (some) sense
<haisheng-from-ch> good morning! I have a question. I've not find any info about it. and also i ask the question on forum.snapcraft.io, but nobody reply it.
<haisheng-from-ch> https://forum.snapcraft.io/t/how-to-make-the-os-snap/3127
<haisheng-from-ch> the question is Ubuntu core has three snaps at least : a Core snap, a Kernel snap, a Gadget snap . And now i have a ubuntu minimal system. how to snapcraft the system to a core snap? anyone can help me? thanks very much.
<mup> PR core-build#24 closed: ubuntu-core-rootfs: mount os/kernel snaps RO <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/24>
<haisheng-from-ch> thanks very much
<mvo> hey haisheng-from-ch - there is now way today now to replace the core snap. however we are working on a new feature called "base" snaps that will allow you to have your own core (it will be called differently) from your own set of binaries.
<mup> PR snapd#4374 closed: interfaces: interfaces: also add an app/hook-specific udev RUN rule for hotplugging <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4374>
<haisheng-from-ch> mvo, mup.thanks. But i don't understand it very well.
<kalikiana> mwhudson: FYI I updated snapcraft#pull/1771 now based on the review conversation
<kalikiana> snapcraft#1771 even
<mup> PR snapcraft#1771: lxd: suppress traceback when lxc launch / init fails <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1771>
 * kalikiana going for a coffee break
<mup> PR snapd#4386 opened: release: 2.30.rc3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4386>
<mvo> cachio: hey, good morning. today is release to stable day. lets notify the store and aim for a release after the standup, ok?
<cachio> mvo, yes
<cachio> mvo, good afternon
<mvo> cachio: thank you! not quite afternoon yet, shortly before lunchtime :)
<mvo> cachio: feels like afternoon already though ;) (kidding)
<cachio> mvo, >(
<cachio> :)
<mborzecki> any PRs needign a second review?
<mvo> pstolowski: 4221 looks good to me now, do you want to have a final look at it and then merge ?
<cachio> mvo, rc3 is ready for beta validation?
<mvo> cachio: correct
<cachio> mvo, great
<mvo> mborzecki: not sure, if I see one I send it your way. 4221 might be one (given that zyga is out)
<pstolowski> mvo, yes, looking
<mvo> mborzecki: if pstolowski is already looking I think thats enough though :)
<mvo> pstolowski: thank you
<mborzecki> ok
<mvo> mborzecki: 4354 has conflicts now
<mborzecki> ok, let me merge master there real quick
<mvo> mborzecki: ta
<mborzecki> mvo: done
<mborzecki> i'm surprised there's no command line switch or a config that you can pass to gpg gen-key to tell it to use some particular device
<mborzecki> although there's a switch when calling gpg --get-random, you can specify the quality of the random source, anything below 2 seems to pick /dev/urandom
<pstolowski> mvo, +1
<mvo> pstolowski: thank you
<mup> PR snapd#4221 closed: tests: new test for interface network status <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4221>
<pstolowski> np
<mborzecki> mvo: project prepare is run once before all the tests that execute on given worker right?
<mborzecki> that's weird, https://paste.ubuntu.com/26163192/ it's like the code that switches /dev/random did not execute at all, a restore was run before the task started or the machine was rebooted
<jdstrand> mvo: hey, I think I can get rid of the write on ~/.gnupg/random_seed with '--no-random-seed-file'. We would just need to document that
<jdstrand> mvo: shall I test and submit a PR?
<jdstrand> mvo: (talking about with the new gpg-keys interface)
<jdstrand> mvo: you know what, I'll submit it and then people can discuss
<mvo> mborzecki: hm, strange. is that your arch PR? I ca nhave a look
<mvo> jdstrand: +1
<mborzecki> it's the fake random thing
<mvo> mborzecki: ta
<mborzecki> #4354
<mup> PR #4354: tests/lib: introduce helpers for setting up /dev/random using /dev/urandom in project prepare <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4354>
<mvo> mborzecki: standup?
<mborzecki> joining, chrome got stuck
 * kalikiana going to leave for lunch in a few minutes
<mup> PR snapd#4387 opened: interfaces/gpg-keys: force use of '--no-random-seed-file' via explicit deny <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4387>
<jdstrand> mvo: https://github.com/snapcore/snapd/pull/4387. this addresses Gustavo's remaining concern and the more I think about it, the more I think it is the correct choice (see my full description)
<mup> PR #4387: interfaces/gpg-keys: force use of '--no-random-seed-file' via explicit deny <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4387>
<jdstrand> mvo: if you agree, I can submit a PR for 2.30 too
<mvo> jdstrand: looking
<brunosfer> Iâm trying to run SDP server on bluetooth using my snap with sdptool, however I get the error âFailed to connect to SDP server on FF:FF:FF:00:00:00: No such file or directoryâ do you know how can I solve this problem in ubuntu snappy core?
<mvo> jdstrand: I replied in the PR, thanks for looking into this
<jdstrand> mvo: I did too, which is why I mentioned both sides of it :)
<mborzecki> mvo: pushed a trivial fix to your #4334 PR
<mvo> jdstrand: heh, I leave that for gustavo to do the final decision
<mup> PR #4334: tests: ensure snap-confine apparmor profile is parsable <Created by mvo5> <https://github.com/snapcore/snapd/pull/4334>
 * jdstrand nods
<mvo> mborzecki: nice, thank you
<mvo> mborzecki: heh, thanks, just read the diff
<brunosfer> Iâm trying to run SDP server on bluetooth using my snap with sdptool, however I get the error âFailed to connect to SDP server on FF:FF:FF:00:00:00: No such file or directoryâ do you know how can I solve this problem in ubuntu snappy core?
<pedronis> mvo: IÂ found a fun bug, if auto refresh refreshes exactly 2 snaps, we get no summary :)
<pedronis> because C and Go switch don't work the same
<kalikiana> re
<mvo> pedronis: ha! fun
<mborzecki> mvo: can you do a second pass on #4354?
<mup> PR #4354: tests/lib: introduce helpers for setting up /dev/random using /dev/urandom in project prepare <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4354>
<elopio> I know you will all hate me, but I'm freezing. 14C, this is not nice.
<elopio> I need to run to the beach, can't feel my hands :(
<mvo> mborzecki: sure
 * genii throws a long-sleeve shirt on to go out and have a smoke in the -6C Toronto weather
<mvo> mborzecki: woah, its *green* :)
<elopio> genii: I cry for you.
<genii> heh
<mborzecki> mvo: yeah, I know :)
<mborzecki> mvo: thanks
<mup> PR snapd#4354 closed: tests/lib: introduce helpers for setting up /dev/random using /dev/urandom in project prepare <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4354>
<kalikiana> elopio: hey
<kalikiana> when you're around, can I ask you something about codespell results?
<elopio> kalikiana: of course, shoot. But that was done by a gci student while I was on holidays, so I might have ignorant answers :)
<kalikiana> elopio: ah, right
<mup> PR snapd#4388 opened: overlord/snapstate: fix auto-refresh summary for 2 snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/4388>
<pedronis> mvo: ^    , IÂ didn't find any preexisting tests for that code
<kalikiana> elopio: so my question might be a request for enhancement of sorts. Was wondering what to expect when running it locally. I'm getting a ton of "WARNING: Binary file" and it seems to search .git files as well and complaining about errors from other branches.
<mvo> pedronis: looking, thank you
<kalikiana> elopio: So my main issue is that it's very noisy.... although I've managed to identify the real complaints from noise so far
<mvo> pedronis: I can look into the test, a welcome change from wrestling with the default-provider tests :)
<mvo> mborzecki: you had a gocheck that does pretty-print for struct diffs, right? where can I find that?
<mborzecki> mvo: https://github.com/bboozzoo/check branch bboozzoo/pretty-equals-not-equals
<mvo> mborzecki: ta
<mborzecki> you will need to do go get the dependencies
<mvo> mborzecki: I think you should submit that to check (if you haven't already). iirc gustavo asked to change the difflib to the other pretty print thing (kr/pretty iirc)
<mborzecki> i'll change the pretty printer before submitting
<mborzecki> i also started working on subtests a bit
<mvo> mborzecki: neat
<mvo> mborzecki: makes my life already easier, thanks for this!
<mborzecki> yw
<mup> PR snapd#4389 opened: overlord/snapstate: override Snapstate.UserID in refresh if the installing user is gone <Created by pedronis> <https://github.com/snapcore/snapd/pull/4389>
<pedronis> mvo: ^ this deals with the other issue IÂ mentioned in the standup,  not the only option to handle it though
<mvo> pedronis: looking
<mborzecki> ok, i'm done for today, need to get back to preparing something for the meetup
<mborzecki> enjoy the rest of the day guys
<zyga-ubuntu> o/
<zyga-ubuntu> how are things
<popey> sergiusens:
<popey> oops
<popey> sergiusens: the phrase SNAPCRAFT_SETUP_CORE=1 appears in search results in bug reports and PRs, but I see no mention in documentation. What does it do?
<popey> (also, should I file a bug about missing documentation)?
<kyrofa> popey, if set, snapcraft will download and unpack the core snap in order to build classic snaps
<popey> yeah, found that in one of the many bug reports, but couldn't find any official docs about it
<kyrofa> popey, if memory serves correctly, it was added so classic snaps could be build on the LP builders back when they were only chroots that couldn't run snaps
<kyrofa> It was a workaround easter egg, not really a feature
<popey> seems other people are using it, like microsoft in vscode and others
<popey> haha
<kyrofa> Huh
<kyrofa> Typically it's expected that one has the core snap installed (or installs it) in order to build classic snaps
<kyrofa> That wasn't an option on LP before they started using lxd
<popey> These are building on docker
<kyrofa> Ahhhh, same problem then
 * kalikiana waves at kyrofa o/
<kyrofa> Hey there kalikiana
 * kalikiana about to wrap up for the day
<kyrofa> I've got some reviews heading your way
 * Son_Goku hates compiler bugs...
<kalikiana> kyrofa: sure. feel free to drop me an email and I'll check them in the morning
 * kalikiana out
<sergiusens> popey no, we do not want to be documenting that, we want to detect we are in a docker container instead
<sergiusens> kyrofa elopio why is lxd from edge installed for our tests?
<sergiusens> that could explain some of the randomness seen
<kyrofa> Good question, no idea
<sergiusens> also, I changed the approach in snapcraft#1798 to be quirk based instead of plugin driven
<mup> PR snapcraft#1798: go plugin: strip sections that patchelf does not handle <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1798>
<elopio> sergiusens: there was a weird combination of lxd stable and snappy stable that didn't work. We can try to get back to having both on stable.
<sergiusens> elopio I think, that that should work these days, well I hope at least, and if not, let's log bugs
<elopio> kalikiana: sorry, I missed the thing about codespell. You can run it with ./runtests.sh static. That's not noisy for me.
<sergiusens> elopio I don't think we are running from the snapcraft snap anymore -> https://github.com/snapcore/snapcraft/pull/1798
<mup> PR snapcraft#1798: elf: strip the .note.go.buildid to make room for patching elf <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1798>
<mwhudson> kalikiana: thanks
<mwhudson> kalikiana: at some point it's just easier for the reviewer to make the change that beat the concept through the dense skull of the submitter :)
<mup> PR snapcraft#1771 closed: lxd: suppress traceback when lxc launch / init fails <Created by mwhudson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1771>
<sergiusens> kyrofa popey snapcraft#1801
<mup> PR snapcraft#1801: ci: detect docker to auto setup core <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1801>
<mup> PR snapcraft#1801 opened: lifecycle: detect docker to auto setup core <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1801>
<kyrofa> elopio, you simply must buy one of these kits
<cachio> elopio, hey
<cachio> elopio, I see some snapcraft errors running sru validation for snapd 2.29.4.2
<cachio> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/s/snapcraft/20171201_043445_970ee@/log.gz
<cachio> elopio, any idea what could be causing that?
<kyrofa> cachio, I see at least one yarn timeout
<kyrofa> Yeah, looks like a few timeouts
<cachio> kyrofa, ok, thanks, I'll run it again tomorrow in that case
<cachio> kyrofa, it is weird because it also failed in the other systems
<cachio> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/i386/s/snapcraft/20171201_020201_0a045@/log.gz
<cachio> this is for 32 bits
<cachio> snaps_tests.CommandError: Error running command 'snapcraft snap' in '/tmp/tmpg4dwm24g/webchat'. Expected output 'Snapped .*\\.snap' not found.
<cachio> same error
<kyrofa> cachio, yeah, same "unexpected error occurred: "https://registry.yarnpkg.com/express: ETIMEDOUT""
<kyrofa> Sounds like yarn generally hiccuped for a few minutes
<kyrofa> Or the adt infra had network issues
<cachio> kyrofa, yes
<cachio> makes sense
<cachio> I'll run it again
<cachio> kyrofa, thanks
<kyrofa> Any time :)
<kyrofa> I know how hard those are to parse
<cachio> :)
<wililupy> Hello, I have one specific task that I would like to run on a single processor core of my machine, and have nothing else interrupt that core. This seems to be impossible on full desktop Ubuntu, but is it possible on Ubuntu Core?
#snappy 2017-12-12
<SamYaple> wililupy: you can do that at the kernel level
<wililupy> SamYaple: You have a link to a document/howto to configure this?
<SamYaple> ta
<SamYaple> moment
<SamYaple> wililupy: http://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/re46.html
<wililupy> SamYaple: Thanks. I'll research this and see if it works.
<SamYaple> i use it to isolate cores for dpdk myself, but its there to basically block the default scheduling unless you specifically set the process to run on that core
<mup> PR snapcraft#1802 opened: metadata: extract metadata from appstream <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1802>
<bencc> is it possible to reload instead of restart when upgrading a snap package?
<bencc> for example when the package is nginx web server
<mborzecki> morning
<bshah> Hello, I am trying to build the 1.31 target on top of xenial base and I am hitting following error : /usr/bin/ld: cannot find -lsnapd-qt
<bshah> (snapd-glib)
<bshah> https://paste.kde.org/p9aqhbib5 is relevant part
<kalikiana> snappy morning, folks
<mvo> hey kalikiana, good morning!
<SamYaple> bencc: /win 7
<SamYaple> oops sorry, ignore
 * kalikiana coffee
<ackk> sergiusens, hi, can https://github.com/snapcore/snapcraft/pull/1617 be merged now that the snapd change is in 2.30?
<mup> PR snapcraft#1617: Add options to configure applications socket activation <Created by albertodonato> <https://github.com/snapcore/snapcraft/pull/1617>
<mup> PR snapd#4390 opened: tests: change interfaces-fuse_support to be debug friendly <Created by mvo5> <https://github.com/snapcore/snapd/pull/4390>
<mborzecki> mvo: there's a conflict in #4103
<mup> PR #4103: snapstate: auto install default-providers for content snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/4103>
<mvo> mborzecki: thanks, I fix it
<mborzecki> btw. our tests could be used as a source of entropy for /dev/random
<mborzecki> https://paste.ubuntu.com/26168835/, tar: /var/lib/snapd: file changed as we read it
<mborzecki> pstolowski mvo, would you fancy reviewing #4373 ?
<mup> PR #4373: snap: app startup after/before validation <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4373>
<mvo> mborzecki: where do you see that tar issue?
<mvo> mborzecki: we need to figure out what is causing this, it happens very sporadically. is this 14.04? or a different release/distro?
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/4285#partial-pull-merging
<mup> PR #4285: tests, spread: add Arch Linux to CI systems <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4285>
<mborzecki> mvo: i think we need to add some logging to spread
<mborzecki> specifically, log the label of the node that the task is running on
<pstolowski> mborzecki, sure
<popey> diddledan: seen https://github.com/snapcrafters/corebird/issues/20 ? Suspect it might be wayland issue?
<mborzecki> mvo: do you know if we require CONFIG_USER_NS ?
<sborovkov> Hi. Is there some snaps api that allows me to restart my snaps? Same with systemctl restart...
<mborzecki> sborovkov: snap restart <service-name>
<mborzecki> sborovkov: systemctl restart snap.<snapname>.<app> should do the trick as well, eg. systemctl restart snap.lxd.daemon
<sborovkov> yeah but I meant with permissions. Something I can call from my own python code.
<sborovkov> inside the snap
<sborovkov> I want to be able to restart some of my own services if some health check failed for instance
<pstolowski> sborovkov, yes, it's coming with new snapd release. snaps can call snapctl start/stop/restart ... for own services
<sborovkov> nice
<sborovkov> thanks
<pstolowski> sborovkov, this should become available at any moment now with 2.30.x
<pedronis> mvo: do spread tests pass sometimes?Â   I'm getting timeouts all the time
<Chipaca> pedronis: linode, or the tests themselves?
<pedronis> Chipaca: travis timeouts, tests taking 49mins+
<Chipaca> aw :-(
<kalikiana> pedronis: for snapcraft we had to restructure and split the test suite more than once to get around those timeouts
<kalikiana> it'd be impossible to run in one go
<mvo> pedronis: they do pass sometimes but things are not going well currently
<kalikiana> Although I'd like to think it has one benefit, which is that we can retry individual steps, it is somewhat forced
<mvo> pedronis: let me check if I can see anything
<mvo> mborzecki: I don't know about CONFIG_USER_NS, sorry
<kalikiana> (where we really means elopio)
<mborzecki> mvo: we could split travis into subjobs
<kalikiana> mvo: this is what we've got now https://github.com/snapcore/snapcraft/blob/master/.travis.yml
<mvo> mborzecki: yeah, that might help
<mvo> kalikiana: aha, interessting
<mborzecki> mvo: pack each distro into a separate job
 * mvo looks at the logs why things are so slow
<mborzecki> mvo: i can look into splitig travis jobs if you're busy
<pedronis> we had more jobs at some point but Gustavo argued against that, so far we have just usually thrown more machines at the problem
<sergiusens> kalikiana morning. Mind dedicating some time to review snapcraft#1793 ?
<mup> PR snapcraft#1793: project: refactor storeapi <Created by daniellim2000> <https://github.com/snapcore/snapcraft/pull/1793>
<sergiusens> pedronis mvo you could also rearchitecture spread so it calls back to github through a webhook with pass/fail and keep travis as the triggering mechanism only
<sergiusens> or even trigger it through a webhook
<sergiusens> if you do that, we will migrate to spread completely :-)
<sergiusens> more machines when you can only run 5 instances at a time is not really going to scale
<sergiusens> popey not sure you saw, but snapcraft#1801 would solve the docker problem
<mup> PR snapcraft#1801: lifecycle: detect docker to auto setup core <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1801>
<popey> sergiusens: it was less that the issue exists, and more that we have hidden magic environment variables that are undocumented that concerned me
<kalikiana> sergiusens: morning! I'm in the middle of a branch merge. Will check it in a few minutes when that's sorted
<mup> PR snapd#4391 opened: travis, run-checks: split travis job into build matrix <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4391>
<mborzecki> little experiment ^^
<mup> PR snapd#4392 opened: many: refresh with appropriate creds <Created by pedronis> <https://github.com/snapcore/snapd/pull/4392>
<mvo> mborzecki: heh :)
<mvo> mborzecki: the unit test job takes a long time, the other ones are really fast
<mvo> mborzecki: but I would like to understand better why we are so slow
<mvo> mborzecki: definitely an interessting PR
<mborzecki> mvo: the upside is that if one distro fails whatever reason, you don't have to restart everything
<mborzecki> and we tend to fail on the little things like this one https://paste.ubuntu.com/26169351/
<mvo> mborzecki: the other upside is that we know exactly what distro caused the timeout
<mvo> mborzecki: I like it
<mvo> mborzecki: *if* we move to this model, we need to adjust the number of parallel travis runs we allow. currently it is limited to three runs because we need so many machines. if we go matrix we can increase this limit quite a bit
 * kalikiana short coffee break
<mborzecki> mvo: 14.04 pushing it to 46 minutes with 13 tests still left
<mborzecki> mvo: ideally, if unit tests are taking too long, we could split them into a separate job
<mvo> mborzecki: yeah, the unit tests are interessting, they take ~10min but we want to run them in spread so that we validate the unit tests on each arch/release
<mvo> mborzecki: also interessting to get the pre-distro/release breakout of the times
<mborzecki> mvo: what i meant is that tests/unit could be put on a job run by spread, separately from other tests under tests/main or tests/regressions
<mvo> mborzecki: before that was difficult to get
<mvo> mborzecki: yeah, worth a shot for sure
<mvo> mborzecki: do you think you could do a separate PR so that we can see the results?
<mborzecki> sure
<mvo> mborzecki: thank you
<mvo> mborzecki: also the output is much easier to read (i.e. failures easier to find). I like this more and more :)
<cachio> mvo, hey, I'll be 5 minutes late today
<mvo> cachio: no worries
<mborzecki> mvo: is there a way to exclude tests in spread command line?
<Chipaca> mborzecki: not afaik, but imho there should be
<Chipaca> mborzecki: you need to list them all ( spread $( spread list linode: | grep -v yadda ) )
<Chipaca> -list, not list
<mborzecki> i'd like to run all jobs for linode:ubunt-16.04-64 but exclude tests/unit, ideally something like `spread linode:ubuntu-16.04-64 -tests/unit`
 * Chipaca nods
<Chipaca> mborzecki: but, if it's that level, you could iterate one level down
<Chipaca> mborzecki: i mean, there's three things at that level
<Chipaca> oh, maybe some more
<Chipaca> mborzecki:  linode:ubuntu-16.04-64:tests/{main,completion,upgrade,regression}/... should do it
<mborzecki> Chipaca: thanks
<Chipaca> Â¯\_(ã)_/Â¯
<Chipaca> mborzecki: i charge in reviews of gnarly code with obfuscated names
<ackk> sergiusens, hi, did you see my message above?
<sergiusens> ackk yeah, is 2.30 widespread already?
<ackk> sergiusens, IDK that
<sergiusens> ackk according to this, it seems to have only been tagged, https://forum.snapcraft.io/t/2-30-release-cycle-started/2997
<ackk> sergiusens, I see. although until that feature lands in snapcraft it's hardly going to be testable in pre-releases
<sergiusens> ackk it should be by building from the branch; this is what I am worried about and it has already happened... if during testing something proves need changes and we release a snapcraft.yaml with what is now considered broken we need to keep that feature forever
<ackk> I see
<sergiusens> I understand that testing the feature using some build system might be a bit more complex, but it is not untestable entirely
<mup> PR snapd#4393 opened: travis: separate unit tests into separate build matrix jobs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4393>
<greyback> Can I get a hand with running snapd's unit tests? Under artful, running ./run-checks --unit fails (this issue: https://forum.snapcraft.io/t/snap-seccomp-fails-tests-on-artful-is-it/2263/4)
<mborzecki> mvo: #4393 should be running with unit tests in a separate job
<mup> PR #4393: travis: separate unit tests into separate build matrix jobs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4393>
<mvo> mborzecki: cool, looking
<greyback> If I run tests in a xenial chroot, I fail with a different error: http://pastebin.ubuntu.com/26169908/
<greyback> how are people running these tests?
<mvo> greyback: usually just ./run-check - that should pull in things, let me look at the poastine
<mvo> greyback: and we have a meeting now, so we will be a bit slow replying
<mborzecki> greyback: make sure you have these dependencies installed https://github.com/snapcore/snapd/blob/master/tests/lib/pkgdb.sh#L347
<greyback> mvo: ack. I've always used ./run-check first, that does grab dependencies. But fails at same place in the unit tests
<jdstrand> greyback: guessing here: did you 'sudo apt-get build-dep snapd'?
<greyback> jdstrand: yep
<jdstrand> greyback: do you have libc6-dev-i386 installed?
<jdstrand> $ dpkg -S /usr/include/sys/cdefs.h
<jdstrand> libc6-dev-i386: /usr/include/sys/cdefs.h
<greyback> jdstrand: no, just the amd64 version. I'll try the i386 but will be mystified if it works
<jdstrand> greyback: I installed gcc-multilib and it pulled in a few things
<jdstrand> greyback: ./packaging/ubuntu-16.04/changelog:    - snap-seccomp: run secondary-arch tests via gcc-multilib
<greyback> jdstrand: aha ok. The dependency grabber will need updating to reflect that
<jdstrand> greyback: if 'apt-get build-dep snapd' isn't getting you there, look in packaging/ubuntu-<your version>/debian/control and see if there are missing build deps that you need to install
<jdstrand> greyback: I think the dep grabber is mostly about go deps. I'll let mvo comment further on all of this, but hopefully you are unblocked
<greyback> jdstrand: I think I am, tests have progressed beyond the usual error point
<greyback> thanks for that
<jdstrand> cool
<jdstrand> greyback: so, apt-get build-dep is quite handy and can usually get you there, the problem is it doesn't know about new changes to debian/control that might not be reflected in the archive for the deb-src lines you have configured
<greyback> jdstrand: sure, I know that, I just trusted the run-checks script to pull in its dependencies
<Chipaca> jdstrand: greyback âapt build-dep ./â works
<jdstrand> oh, that's handy
<greyback> Chipaca: oh taht's handy
<jdstrand> Chipaca: hehe
 * mvo wrote that some years ago :-D
<Chipaca> jdstrand: greyback: hug mvo for that one
 * greyback hat-tips mvo
 * jdstrand hugs mvo for that one
<jdstrand> :)
 * mvo hugs greyback and jdstrand 
<jdstrand> greyback: re run-checks> yeah, it doesn't do that I suspect because it doesn't use sudo for things
<jdstrand> greyback: run-checks could certainly be made friendlier though
<jdstrand> or the README could say: be sure to have all the distro dependencies installed. For example, on Ubuntu run 'sudo apt-get build-dep ./' :)
<mvo> jdstrand: +1
<jdstrand> mvo: actually, that brings up a question I have. I had trouble building trusty the other day. I moved debian/ aside and copied packaging/ubuntu-14.04 to debian/, but it still didn't work. what should I do?
<jdstrand> mvo: now that I say that, I didn't do 'apt-get build-dep ./' in the chroot
<jdstrand> just the dpkg-buildpackage
 * jdstrand tries
<jdstrand> I see it is a symlink
<jdstrand> anyway, I'll play and reask
<mvo> jdstrand: thanks, let me know how it goes
<jdstrand> hmm, trusty's apt-get doesn't seem to like that
<mvo> jdstrand: yeah, its old and crufty. try gdebi ./debian/control
<sergiusens> elopio did you see my comment from yesterday about the integration tests not running from the snapcraft snap?
<roadmr> sergiusens: good morning! hey is there still time to fix bugs for snapcraft 2.37 before it goes out to stable?
<sergiusens> roadmr what is the problem?
<sergiusens> roadmr 2.37 is already released, if there is a blocker it will just not go to stable and to stay in beta/candidate instead
<sergiusens> that said, there is still time to make it into 2.38 :-)
<roadmr> sergiusens: interesting... https://bugs.launchpad.net/snapcraft/+bug/1737571 is the problem (I want a poop emoji in my description dammit!)
<mup> Bug #1737571: stack trace when description or summary contain non-ascii characters <Snapcraft:New> <https://launchpad.net/bugs/1737571>
<sergiusens> interesting that popey has not discovered that ;-)
<roadmr> sergiusens: I bet he uses only snoflake emojis, which mysteriously work fine
 * kalikiana time for lunch! hopefully including a massive salad
<Chipaca> hmmmmmmmm
 * Chipaca needs to open a snap in a context where it's not been validated yet
<Chipaca> but! but, i don't need to do anything dangerous with it -- it's only open in the sense that i call snap.Open() on it -- i then just need to look at its contents, a la listdir
<mvo> Chipaca: hm, will you call unsquashfs -ls on it?
<Chipaca> mvo: yes, or (*os.File).Readdir if it's a snapdir
<mvo> Chipaca: *nod*
<Chipaca> mvo: should I add knowledge of what's safe and what's unsafe to snap containers?
<mvo> Chipaca: my gut feeling is yes
<Chipaca> mine as well
<Chipaca> but it does feel like a separate branch
<jdstrand> mvo: I'm in an up to date trusty schroot. I ran gdebi ./debian/control then DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage and it fails. it seems like GOPATH/etc isn't setup right, but I would've expected debian/rules to do that...
<Chipaca> jdstrand: did you ./generate-packaging-dir?
<mvo> Chipaca: I am also a tiny bit uneasy about unsquashfs on untrusted content as its C and the snap comes from a user and snapd will validate it as root. or will we do the validation enitrely in snap itself at first?
<jdstrand> Chipaca: no, I updated the symlink manually
<jdstrand> let me try that
<Chipaca> mvo: gnome-software would have to do it separately if it were client-side
<jdstrand> same thing
<Chipaca> jdstrand: yeah all that does is update the symlink
<Chipaca> :-/
<Chipaca> jdstrand: did you add proposed and the ppa?
<jdstrand> no
 * jdstrand does that
<Chipaca> jdstrand: look in tests/lib/prepare-restore.sh, if you look for ppa you'll find yourself in a 14.04 bloock
<mvo> Chipaca: indeed, good point
<Chipaca> mvo: but, agreed
<Chipaca> mvo: in which case i can only do this check rather late (post validation)
<mvo> Chipaca: tricky, I wonder if we could confine it?
<mvo> Chipaca: \o/
<mvo> Chipaca: thats fine then
<Chipaca> mvo: OTOH I can do it earlier for local files
<Chipaca> so that should get rid of the most egregious whoopsies
<mvo> Chipaca: sounds good
<Chipaca> k
<Chipaca> jdstrand: I don't know how much of that is necessary (i'm sure it was at some point), but i know that with all that it builds
<Chipaca> (as i was going over that repeatedly last week)
<mvo> jdstrand: re trusty> one slightly tricky thing is that you need the go-deps in vendor/ to build the package and for that you need the GOPATH so that govendor can update your vendor/ subdir
<mvo> jdstrand: does that make sense?
<mvo> jdstrand: this makes building a deb from git slightly harder as it expects to be in a valid GOPAHT
<pedronis> Chipaca: where do you need to open a snap?Â we are very careful about where we do that or not?
<Chipaca> pedronis: yes, we are
<pedronis> Chipaca: I don't see the win or opening an unvalidated snap to check if the exec bits are right
<pedronis> we should assume the store the did job no? so if we are late it's wrong well too bad (it should be rare)
<Chipaca> pedronis: it's late enough that it ends up in errors.u.c
<Chipaca> pedronis: but, i can run it earlier for local snaps
<pedronis> Chipaca: do we really send to errors.u.c  for local snap?
<pedronis> maybe that is the problem
<Chipaca> pedronis: so that's good enough (that's what i concluded from the discussion with mvo)
<Chipaca> pedronis: yes we do
<pedronis> seems wrong
<pedronis> we should stop to do that
<Chipaca> pedronis: perhaps :-)
<Chipaca> i'm trying to not branch this branch any further though :-)
<Chipaca> i'll look into that next, then
<mup> PR snapd#4386 closed: release: 2.30.rc3 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4386>
<Chipaca> popey: is there a snap in the store you know of with the wrong permissions bug?
<popey> no, it's a private snap
<mup> PR snapd#4394 opened: snap: give the snap.Container interface a Walk method <Created by chipaca> <https://github.com/snapcore/snapd/pull/4394>
<Chipaca> ok i split the checker into the walker (^^) and the snapstate thing that uses this. Still adding tests to the latter, and it splits cleanly.
<Chipaca> popey: ah well, nm
<jdstrand> Chipaca, mvo: ok, so the issue seemed to be that I didn't have the trusty build directory down in GOPATH and I needed to run 'govendor sync'. I was surprised that I needed to do that-- I was thinking it would act like 'apt-get source snapd ; cd snapd-* ; dpkg-buildpackage"
<mvo> jdstrand: unfortunately not from a git checkout as we do not store all the vendor/ deps in git
<jdstrand> ah
<Chipaca> jdstrand: the go devs are aware how nasty it is that go needs this faffing around and intend to fix it someday
<Chipaca> they haven't said if that comes before or after generics :-)
<jdstrand> mvo: so the fact that I ran govendor sync within a trusty chroot (but shared HOME), is that going to mess with my normal xenial schroot builds (that uses the same GOPATH in HOME)?
<jdstrand> I think I'll just make a note to rm -rf $GOPATH/pkg and govendor sync after to be 100% sure
<om26er> @popey Hey! mind taking a look at https://github.com/snapcrafters/android-studio/pull/9 ?
<mup> PR snapcrafters/android-studio#9: Ship packages required to run emulator <Created by om26er> <https://github.com/snapcrafters/android-studio/pull/9>
<mvo> jdstrand: it should not mess up your pkgdir because it should only install into ./vendor
<jdstrand> mvo: ah, good to know
<Chipaca> jdstrand: ps GOPATH is a path... "${GOPATH%%:*}/pkg" if you're putting that in a script
<jdstrand> Chipaca: ack
<kalikiana> re
<sergiusens> popey flexiondotorg where is the repo for vscode?
<sergiusens> or the snapcraft.yaml that makes the vscode of today a thing
<flexiondotorg> https://code.launchpad.net/~flexiondotorg/+junk/snap-vscode
<flexiondotorg> New version pushed to edge yesterday,
<mup> PR snapd#4395 opened: update HACKING.md for distro build dependencies <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4395>
<jdstrand> mvo, greyback: fyi, ^
<popey> om26er: looking
<jdstrand> I didn't do anything for trusty there
<jdstrand> just the apt-get build-dep ./ bit
<Chipaca> jdstrand: apt-get doesn't have build-dep ./
<Chipaca> jdstrand: that's apt
<jdstrand> it worked here
<Chipaca> â¦ oh
 * Chipaca looks
<jdstrand> I just tested it in a xenial chroot
 * jdstrand tries again
<Chipaca> dang
<Chipaca> yes, it works with apt-get
<Chipaca> wichcraft
<jdstrand> heh
<mvo> jdstrand: thanks for this
<jdstrand> mvo: fyi, I passed along 'apt-get build-dep ./'. that is super cool :)
<jdstrand> it's the little things in life...
<sergiusens> flexiondotorg oh, launchpad, that's why I couldn't find it :-)
<sergiusens> flexiondotorg I want to test getting rid of your LD_LIBRARY_PATHS in there
<sergiusens> with the latest snapcraft in beta
<mvo> jdstrand: thanks!
<flexiondotorg> OK, So if I push the current edge to stable we cam play in edge?
<flexiondotorg> We'll also need to feed this back up to the ISVs creating classic snaps, right?
<elopio> sergiusens: I think we lost somewhere the SNAPCRAFT_FROM_INSTALLED=1 env var. Do you want to add it in your PR, or should I do one just for that?
<sergiusens> elopio might have been lost since that refactor, please create a PR, also remove the installation of requirements.txt and all the apt dependencies
<sergiusens> unless they are needed to satisfy requirements-devel for the test runner
<elopio> sergiusens: ah, no, not true. It's just hardcoded a little deep: https://github.com/snapcore/snapcraft/blob/master/tools/travis/run_lxd_container.sh#L56
<elopio> sergiusens: from the log of your execution: snapcraft 2.37+git5.65eb587 installed. That's the right commit. And the call that fails is ['snapcraft', '-d', 'prime']
<elopio> we are not installing the sources anytime. And the container doesn't have the snapcraft deb preinstalled.
<elopio> are you sure the only way this could fail is if snapcraft is not being run from the snap built from the pr?
<mvo> jdstrand: if you have a moment for 4381 that would be great. its hopefully super trivial to review
<jdstrand> mvo: done
<mvo> jdstrand: ta
<mup> PR snapd#4381 closed: interfaces: add /proc/partitions to system-observe <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4381>
<sergiusens> elopio http://pastebin.ubuntu.com/26170868/, I will add that to the debug line, if it False, we are certainly not running from the snap
<mup> Bug #1636540 changed: please support creating pipes via mknod <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1636540>
<mup> Bug #1617275 changed: the home interface doesn't allow access to $HOME/snap-confine <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1617275>
<mup> Bug #1725208 changed: missing interface to exec cc <snapd-interface> <Snappy:Won't Fix> <https://launchpad.net/bugs/1725208>
<mup> Bug #1612759 changed: fchown system call is blocked by seccomp under confinement <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1612759>
<mup> Bug #1636229 changed: getpwnam() and parsing /etc/passwd gives wrong value for HOME to snaps <snapd-interface> <Snappy:Invalid> <https://launchpad.net/bugs/1636229>
<pstolowski> oh my, just fixed all the ifacestate tests for autoconnect changes hoping that's mostly it, but snapstate tests have 10x more failures :/. fun
<Saviq> hmm is there known outage of the store services? my `snapcraft push` times out after trying to process the delta for 60s)
 * Saviq clears cache to force a full upload
<daniellimws> hi
<Chipaca> daniellimws: hi
<elopio> roadmr: hey, I'm looking at bug #1737571.  Sergio said you might be working on it, is that true? I don't want to duplicate your work :)
<mup> Bug #1737571: stack trace when description or summary contain non-ascii characters <Snapcraft:New> <https://launchpad.net/bugs/1737571>
<kyrofa> Hey there daniellimws, thanks for joining!
<daniellimws> thanks for inviting :)
<kyrofa> sergiusens, elopio there's your man ^
<roadmr> elopio: oh no :) I just filed it
<roadmr> elopio: I filed it because we found it while tinkering with metadata but I think it's something unrelated, because it happens when building a snap with weird chars in the snapcraft.yaml
<roadmr> elopio: there was also a unicode-related bug in the store (https://bugs.launchpad.net/snapstore/+bug/1737566) but we have a fix for that
<roadmr> elopio: so tl;dr not really working on it, sorry :( if you could that'd be swell
<elopio> roadmr: I will try to fix it this week.
<roadmr> thanks elopio!
<elopio> daniellimws: hey, I am wondering if you are ready for a new task, I have one that might interest you
<daniellimws> yea i think my current one should be done soon
<Chipaca> snapd#4394 is green, if anybody is looking for something to poke at
<mup> PR #4394: snap: give the snap.Container interface a Walk method <Created by chipaca> <https://github.com/snapcore/snapd/pull/4394>
<elopio> the problem is that it's abandoned, and I don't know how to recover it. kyrofa do you know?
<daniellimws> running the test cases now
<daniellimws> *running them locally
<kyrofa> elopio, huh. Let me look
<elopio> kyrofa: https://codein.withgoogle.com/dashboard/task-instances/6180198217154560/
<cachio> mvo, we have 2.30 in candidate
<daniellimws> ah i wanted to work on this but couldnt find it
<elopio> well, actually it's better that it's blocked. That way nobody can take it while we review your current PR
<kyrofa> Dangit this codein site is so annoying... it keeps taking my primary account, and doesn't support switching. sergiusens I think that's why google has been broken for us lately
<daniellimws> elopio: haha that's great. and I still have a beginner task to spare
<elopio> daniellimws: here's the description: http://paste.ubuntu.com/26171261/ Please let me know if it sounds fun to you
<elopio> sergiusens: who's our travel authorizer? Mark?
<daniellimws> elopio: i recall there was also a task about snapcraft stats, but its not there now. Has anyone done it?
<elopio> daniellimws: yes, the one about stats is done: https://github.com/elopio/random-scripts/pull/1
<mup> PR elopio/random-scripts#1: Add gathering data from github <Created by DeniskaMazur> <https://github.com/elopio/random-scripts/pull/1>
<kyrofa> elopio, we can add another instance easily
<kyrofa> elopio, but you're right, let's wait until daniellimws is ready
<kalikiana> kyrofa: sergiusens: elopio: shared the minutes. I decided to go for fairly verbose in a couple of sections, which I hope you find useful, though if you think it's too much detail just let me know what you'd prefer
<kalikiana> hey daniellimws!
<kalikiana> I see you already saw my comments on #1793 - I'm wrapping up for the day, but I'll give it another look in the morning (for me it's dinner time)
<mup> PR #1793: asserts: initial support to generate/sign snap-build assertions <Created by caio1982> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1793>
<kalikiana> bah
<kalikiana> I meant snapcraft#1793
<mup> PR snapcraft#1793: project: refactor storeapi <Created by daniellim2000> <https://github.com/snapcore/snapcraft/pull/1793>
<daniellimws> kalikiana alright thanks. I'll push soon once I fix all the test errors.
<kalikiana> daniellimws: Awesome!
 * kalikiana out for today, o/
<mvo> cachio: yay! thank you
<cachio> mvo, yaw
<sergiusens> elopio https://travis-ci.org/snapcore/snapcraft/jobs/315458083 -> "snapcraft from snap: False; so patchelf set to 'patchelf'"
<sergiusens> elopio kyrofa the fact that the 'snapcraft-parser' tests work at all is telling me that it is running from the venv
<elopio> sergiusens: the things is to find where is that venv being set up
<elopio> sergiusens: can you add which snapcraft to that debug execution?
<sergiusens> elopio it is horrible
<sergiusens> I just pushed a fix
<sergiusens> to make this deterministic
<sergiusens> kyrofa will be there in a bit
<kyrofa> Okay
<mup> PR snapcraft#1803 opened: ci: correctly run from snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1803>
<wililupy> If I want to add isolcpus=2,3 to the grub CMDLINE value "the correct way" how do I do that?
<wililupy> I modified the /boot/grub/grub.cfg and added the line in the set cmdline variable and it works, but I fear that if there is an update to the device it will revert back to original settings and would like this permanent across grub-update(s).
<mvo> wililupy: you can test this via "snap refresh --candidate core" for example, currently grub.cfg should be safe iirc. I think longer term we want to add support for grub.cfg settings via the "snap set core " configuraton options
<wililupy> mvo. I"ll give that a test, but that sounds amazing!
<mvo> wililupy: if things look good you can "snap refresh --stable core" to get back to the stable core
<mvo> wililupy: you could also try to update the gadget and the kernel just to be on the safe side
<wililupy> mvo: cool I'll give it a shot and see. I'll keep you posted.
<mvo> thanks
<wililupy> mvo so updating core snap keeps the grub config, so that good. Testing kernel and gadget next.
<mvo> wililupy: yeah, iirc it should work until we implement gadget assert updates but then we will also implement a core config options for that I think. feel free to open a topic on forum.snapcraft.io about your use-case, then we can discuss how to best implement grub.cfg manipulation via snap set
<wililupy> mvo cool. I will take it to the forum :)
<kyrofa> Is it just me, or does my rpi2 take a LOT longer to boot and start running services if it's not connected to a network?
<kyrofa> Does it have a 60 second IP address timeout or something?
<cachio> mvo, I am working in a test for system-trace interface, I was wondering if it is ok to use the bcc snap for that or it should be better to create a test one
<cachio> mvo, what do you think?
<mvo> cachio: I think its ok to use bcc, we nowdays send a header to the store when a snap is under testing
<cachio> mvo, great
<cachio> tx
<mvo> cachio: I need to double check if that is also true for e.g. external: tests that where we don't build snapd ourself, but even then we can probably do something. and worst case we just fork bcc
<mvo> cachio: could you talk to apw tomorrow/in the next days about snapd 2.29.4.2 for -updates? afaict all remaing autopkgtest issues are some network hickups or similar
<cachio> mvo, sure
<cachio> I'll see that tomorrow
<mvo> cachio: thank you! yeah, thats fine
<cachio> mvo, anjoy your vacations
<cachio> enjoy
<mvo> cachio: thank you, appreciated! I will be a around a little bit longer, I want to finish my current task but then I do look forward to take a break :)
<kyrofa> cachio, have you noticed Core taking longer to come up without network?
<cachio> kyrofa, the one in candidate?
<cachio> kyrofa, I'll check that, where sis you see that?
<kyrofa> No, I guess I'm using stable these days
<cachio> kyrofa, ok, I'll check it
<kyrofa> cachio, I'm running a rpi2 based on the edge image, but refreshed core to stable after an update got hung up
<cachio> kyrofa, ok, I don't use edge image, I'll try to reproduce it
<cachio> kyrofa, the hung was after the reboot? or before?
<kyrofa> cachio, I wrote about the hung update here (although this was a while ago, I doubt it's related to the fact that the boot seems to take longer when it has no network): https://forum.snapcraft.io/t/raspberry-pi-2-edge-core-snap-seems-broken/3061/4
<cachio> kyrofa, in this change -> Setup snap "core" (3443) security profiles (phase 2)
<cachio> it usually takes like 5~10 minutes
<cachio> kyrofa, how long did it take when you raised that issue? do you remember that?
<kyrofa> Really? Ouch, I probably didn't give it enough time then. I needed my interface connected!
<kyrofa> 5-10 minutes of downtime for an automatic refresh that prevents me from doing anything is too much
<bencc> is it possible to reload a snap on upgrade instead of restart
<bencc> useful for nginx web server in a snap to keep connections
<Chipaca> bencc: i presume nginx is smart about that sort of thing? but sadly no, that would imply one revision of a snap doing ipc with another revision of the same snap
<cachio> kyrofa, agree, it is too much
<cachio> kyrofa, you can manually reboot it as workaround
<kyrofa> cachio, which, as it happens, is exactly what I did! Haha
<cachio> kyrofa, hehe, I do the same
<kyrofa> cachio, how can a reboot make 5-10 minutes of work not necessary?
<kyrofa> What's happening there?
<cachio> kyrofa, the reboot is scheduled for 10 minutes after the refresh is done
<cachio> kyrofa, during that time the setup is done
<mup> PR snapcraft#1804 opened: meta: split the meta module <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1804>
#snappy 2017-12-13
<mup> PR snapcraft#1805 opened: lifecycle: use the -no-fragments mksquashfs option <Created by tyhicks> <https://github.com/snapcore/snapcraft/pull/1805>
<mup> PR snapd#4396 opened: snap: use the -no-fragments mksquashfs option <Created by tyhicks> <https://github.com/snapcore/snapd/pull/4396>
<mborzecki> morning
<mup> PR snapd#4395 closed: update HACKING.md for distro build dependencies <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4395>
<kalikiana> good morning
<mborzecki> kalikiana: morning
<Chipaca> mborzecki: o/
<mborzecki> Chipaca: hey
<Chipaca> mborzecki: would now be a good time to rant about the insanity of signed st_size
<mborzecki> hahaha :) that's the ParseInt() thing?
<Chipaca> mborzecki: yeah
<Chipaca> mborzecki: stat64's st_size is a long long
<Chipaca> mborzecki: stat's st_size is unsigned long (not unsigned long long)
<Chipaca> (it's just an unsigned int on 64 bits, in fact; it's unsigned long on i386)
<mborzecki> Chipaca: fair enough
<Chipaca> mborzecki: and golang's os.FileInfo's Size() returns an int64
<Chipaca> mborzecki: and i it bothers me _every_ _time_
<Chipaca> like, who's this person going around creating negative-sized files
<Chipaca> i'd like a word
<pedronis> Chipaca: is there some call that returns size_t directly, usually the reason is to mark errors as -1
<mborzecki> Chipaca: can you add a comment there in the code? just in case someone stubles on it in the future
<Chipaca> pedronis: getuid reutrns unsigned ints, and uses -1 as a flag value
<Chipaca> mborzecki: psh. comments. what's next, *tests*?
<Chipaca> pedronis: but, yeah, probably
<mborzecki> Chipaca: nah, tests you can skip
<Chipaca> pedronis: and I guess the feeling is if reaching the limit of 63 bits is close, 64 bits is just as close
<Chipaca> mborzecki: :-D
<Chipaca> mborzecki: i'm quoting you on that one
 * Chipaca looks forward to having 20EB sd cards
<pedronis> Chipaca: also defining off_t would be hard
<mborzecki> Chipaca: i'm doing a meetup on go at my local group today, will reference both golang bugs that you found (geteuid and syscalls that must fail, even if they don't)
<Chipaca> mborzecki: heh
<Chipaca> mborzecki: those are mundane compared to the threading one :-) but ok!
<mborzecki> i'll be showing the actual bits of go's asm that are responsible
<Chipaca> pedronis: are you reviewing that PR? just asking to know if i should wait before pushing the changes
<pedronis> Chipaca: no, IÂ don't even know what PR you are talking about, IÂ need a belated breakfast actually :)
<Chipaca> pedronis: breakfast >> reviews
 * kalikiana coffee break
<JamieBennett> Any idea why none of my snaps can save settings? Happening with Corebird and Mailspring. I'll change settings, they will be reflected in the UI but not saved. When I go back to the settings of the app the old values are still there.
<pstolowski> JamieBennett, any denials in the logs?
<sergiusens> JamieBennett check ownership of files/dirs in ~/snap
<JamieBennett> pstolowski: Only denial I see is this but it looks unrelated: Dec 13 09:37:00 ubik kernel: [ 1876.976847] audit: type=1107 audit(1513157820.788:1187): pid=1834 uid=106 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/" interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" mask="send" name="org.bluez" pid=10850
<JamieBennett> label="snap.mailspring.mailspring" peer_pid=1820 peer_label="unconfined"
<pstolowski> right, seems unrelated
<JamieBennett> sergiusens: permissions looks OK too
<JamieBennett> It's strange
<pstolowski> JamieBennett, also, does it create any (possibly hidden) files in ~/snap/.. as you modify & save settings? 'find ~/snap` before and after might give a clue
<mborzecki> hmm corebird seems to work just fine here, the settings are preserved and i can actually see then on d-conf
<JamieBennett> Seems I am getting quite a few denied messages for dbus
<JamieBennett> http://paste.ubuntu.com/26175781/
<mborzecki> JamieBennett: anything with ca.desrt.dconf ?
<JamieBennett> Even stranger, if I change settings then close Corebird and reopen, the new settings are there.
<mborzecki> JamieBennett: stat `dconf watch /org/baedert/corebird/` and run corebird, change some settings, you should see dconf watch listing updaated keys
<Chipaca>  if [ ! -e $(ls -1 /var/lib/snapd/snaps/ubuntu-core_*.snap | tail -1) ]; then exit 1; fi
 * Chipaca wonders
<JamieBennett> mborzecki: nothing
<JamieBennett> Chipaca: ls: cannot access '/var/lib/snapd/snaps/ubuntu-core_*.snap': No such file or directory
<Chipaca> ogra_: you're my favourite sh expert: does the above make any sense to you? as opposed to just [ -e /var/lib/snapd/snaps/ubuntu-core_*.snap ] ?
<Chipaca> JamieBennett: uh, sorry, this's unrelated to your woes
<JamieBennett> lol
<pedronis> Chipaca: I think you get an error from -e  if there is more than one argument
<Chipaca> hm, probably
<Chipaca> just the ls, then :-)
<pedronis> but yes, it's a weird way to check
<JamieBennett> mborzecki: do external links in tweets work for you?
<JamieBennett> (in Corebird)
<Chipaca> JamieBennett: are the corebird interfaces connected?
<JamieBennett> Chipaca: yes, gsettings, home, network, ...
<mborzecki> JamieBennett: yes (note, i'm running latest snapd master)
<Chipaca> JamieBennett: dbus?
 * JamieBennett cannot see a dbus interface
<pedronis> have we got any green runs in the last days?   all the recent PRs seem red
<JamieBennett> what is the exact name? Should it be dbus?
<Chipaca> pedronis: my pr was green yesterday
<Chipaca> pedronis: first try, too
<pedronis> impressive
<Chipaca> pedronis: and finishing at ~5pm which is peak SF
<JamieBennett> Chipaca: https://pastebin.ubuntu.com/26175847/
<mborzecki> pedronis: and timing out
<Chipaca> JamieBennett: 'snap interfaces corebird' would've been nicer :-D
<Chipaca> JamieBennett: corebird:dbus-corebird           -
<JamieBennett> Chipaca: well, I'm having issues with snaps all round so pasted them all
<Chipaca> JamieBennett: output of 'snap version'?
<JamieBennett> https://www.irccloud.com/pastebin/I1GemYmg/
 * mborzecki restarting master branch travis job for the 4th time
<Chipaca> JamieBennett: so, about corebird, if you even get a window you're ahead of me
<JamieBennett> Mailspring was the other that is not saving settings for me
<Chipaca> oh it took ages but finally popped up
<Chipaca> it tried to download and bunzip an h264 decoder (wat)
<Chipaca> JamieBennett: but, the link on "Create one" worked, so that works
<JamieBennett> Chipaca: What I tried to do was turn autoscroll on in settings, close the settings window, then go back and see if it is still enabled
<Chipaca> JamieBennett: in corebird?
<JamieBennett> yes
<Chipaca> JamieBennett: how do i get to settings?
<JamieBennett> The cog in the titlebar
<Chipaca> JamieBennett: i have no cog in my titlebar
<JamieBennett> next to minimise?
<Chipaca> JamieBennett: https://i.imgur.com/tXRVd4A.png
<JamieBennett> Ah, you have a different theme too, everything is on the left, I'm on 17.10 and everything is on the right
<Chipaca> JamieBennett: this is sparta^W16.04
<JamieBennett> https://usercontent.irccloud-cdn.com/file/F4QDY6Gw/Screenshot%20from%202017-12-13%2010-32-40.png
<JamieBennett> Chipaca: I think there is a more general problem as no snaps seem to be able to save settings, external links in snaps do not work e.t.c.
 * JamieBennett keeps digging
<Chipaca> JamieBennett: it does sound like something is broken
<Chipaca> JamieBennett: have you tried seeing if running core from stable fixes things?
<JamieBennett> no, lets try that
<JamieBennett> Chipaca: nope, that wasn't it
<Chipaca> JamieBennett: I don't have many ideas. I'd normally point you at zyga...
<JamieBennett> np, just debugging dbus at the moment, it definitely looks like something is wonky there
<pedronis> Chipaca: we will have to turn off some suites or something until we decide what to do, I really would like to merge a couple small PRs before leaving
<pedronis> for the holidays
<sergiusens> JamieBennet Chipaca snap run --shell corebird ... then touch $SNAP_USER_COMMON/stub and verify that works
 * sergiusens is on his phone warming up on a static bike to get started with physiotherapy 
<Chipaca> pedronis: i'm trying something that might make a difference (maybe too small to be noticeable though, will see if it works at all first)
<Chipaca> pedronis: the biggest issue seems to be i/o timeouts from linode :-/
<Chipaca> the second issue seems to be that the images haven't been refreshed in too long (or could use some love to be quicker)
<Chipaca> (locally in my qemu images i cut down the time by ~15 minutes for 14.04 just by doing all the setup faff beforehand
<Chipaca> )
<pedronis> I'm sure, I'm looking for a remedy for the next 3 days that doesn't need Gustavo though
<Chipaca> yeah
 * pedronis lunch
<Chipaca> pedronis: that's what i'm trying out: i have a branch that does a single apt-get for distro_install_package instead of one per package
<Chipaca> pedronis: and replaces all -comp xz with -comp gzip in ~5 mksquashfs calls we have in tests
<Chipaca> between them it might shave 10 minutes or more, depending
<Chipaca> testing it now
<mborzecki> Chipaca: are msquashfs calls done in prepare?
<Chipaca> mborzecki: in core, yes, one
<Chipaca> mborzecki: and in the prepare of cmd/snap-confine/spread-tests/regression/lp-1599608/task.yaml
<Chipaca> mborzecki: and tests/main/ubuntu-core-custom-device-reg-extras/task.yaml
<Chipaca> mborzecki: and tests/main/confinement-classic/test-snapd-hello-classic/Makefile
<Chipaca> mborzecki: and tests/main/ubuntu-core-custom-device-reg/task.yaml
<Chipaca> mborzecki: and tests/main/ubuntu-core-gadget-config-defaults/task.yaml
<mborzecki> ah, right, the ones that were in the pr
<Chipaca> mborzecki: </ul>
<Chipaca> :)
<mborzecki> one thing I observed while browsing logs today: https://paste.ubuntu.com/26176245/
<mborzecki> this is right before the timeout
<mborzecki> tests/main/lxd task
<Chipaca> mborzecki: yeah
<mborzecki> any idea what's the size of this rootfs?
<Chipaca> mborzecki: it should be possible to do that beforehand also :-/
<mborzecki> 10+ minutses of project prepare, blazing fast download and we're pushing the job timeout limit
<Chipaca> ummm
<Chipaca> i just got green on my pr again
<Chipaca> dunnno what y'awl are moanin' about
<Chipaca> :-p
 * Chipaca is sure to be run over by a bus after this amount of good luck
<pedronis> Chipaca: this 2 lines PR takes regularly 49+Â mins:  https://github.com/snapcore/snapd/pull/4388
<mup> PR #4388: overlord/snapstate: fix auto-refresh summary for 2 snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/4388>
<mup> PR snapd#4397 opened: tests/main/lxd: temporarily switch to manual <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4397>
<mborzecki> another experiment, trying to see if this is the culprit
<Chipaca> my test run is dying a death of a thousand "no powered off servers in Linode account exceed halt-timeout" :-/
<Chipaca> still seeing ~10 min prepares though
<mup> PR snapd#4398 opened: overlord/auth,daemon: introduce an explicit auth.ErrInvalidUser <Created by pedronis> <https://github.com/snapcore/snapd/pull/4398>
<pedronis> Chipaca: mborzecki: simple PR (split out from my larger one) ^
 * Chipaca ~> lunch
<Vamsi> Hello, is it possible for me to license snaps that I build? Is there an online documentation where I can read more on this?
<Chipaca> Vamsi: license in what sense?
<jdstrand> JamieBennett (cc pstolowski): that is definitely unrelated
<Chipaca> pedronis: standup?
<jdstrand> JamieBennett (cc pstolowski): (bluez)
<JamieBennett> jdstrand: thanks for confirming
<Vamsi> Chipaca: such that I can make my snap a paid snap without falling into trouble.
<Chipaca> Vamsi: support for for-pay snaps isn't there yet -- JamieBennett or noise][ might have more detail
<jdstrand> JamieBennett: you should connect screen-inhibit-control for irccloud
<Vamsi> So no snap crurrently is a paid snap? All are free?
<jdstrand> JamieBennett: there are a couple also unrelated denials in there that I'll investigate
<JamieBennett> Vamsi: that is correct, the service has not been launched yet
<Vamsi> okay. thanks :)
<pstolowski> jdstrand, thanks for checking
<mborzecki> hm looking at some logs from ubuntu-14.04 and analyzing them with mvo's script, there's 13 minutes of prepare time, then the top tests take ~7 minutes, leaving us with 29 minutes for ~237 tests
<mborzecki> that's 120ms per test :)
<Chipaca> mborzecki: https://github.com/snapcore/snapd/compare/master...chipaca:dumb-spread-tweaks
<Chipaca> mborzecki: that's why we have multiple workers (and why prepare time is so crucial)
<pedronis> most systems have 4 workers
<mborzecki> Chipaca: pushed your commit to #4393 and #4391
<mup> PR #4393: travis: separate unit tests into separate build matrix jobs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4393>
<mup> PR #4391: travis, run-checks: split travis job into build matrix <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4391>
 * kalikiana time for lunch!
<pedronis> Chipaca: also afaiu  we run 3 travis jobs and have 80 machines,  atm all workers for a job =Â 27 (6*4+3),  27*3 = 81, so we are a tiny bit overallocated as well
<Chipaca> pedronis: ooh, that'll be biting at least 1/3 of our jobs when we're busy :-(
<Chipaca> can that be dropped to 2, or does that also need gustavo?
<mup> PR snapd#4398 closed: overlord/auth,daemon: introduce an explicit auth.ErrInvalidUser <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4398>
<pedronis> Chipaca: that can be changed in travies IÂ think
<Chipaca> ah yes
<Chipaca> should I?
<pedronis> Chipaca: we can do that, or disable one of the distros
<pedronis> temporarely  (though suse has been disabled temporarly for a long time now)
<Chipaca> pedronis: i've set it to 2 for now
<Chipaca> pedronis: let's see with mborzecki's matrix how things look
<mborzecki> pedronis: i suppose you can find a time scale where 'long time' feels temporary :)
<Chipaca> mborzecki: is 9.5 minutes prepare for 14.04 an improvement?
<mborzecki> yup
<mborzecki> Chipaca: 14.04 finished in 34 minutes
<Chipaca> mborzecki: so not necessarily better, but not necessarily worse
<mborzecki> in previous run of #4393, ubuntu-14.04 finished in 24 minutes
<mup> PR #4393: travis: separate unit tests into separate build matrix jobs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4393>
<Chipaca> mborzecki: but also timed out at 49+?
<mborzecki> 16.04 hit a timeout in that build
<pedronis> well if we were overallocated, each run might have depended on when it got the last worker (unless it simply died unable to get it at all within allowed time)
<pedronis> I don't know how retrying spread does to get machines
<pedronis> *how much
<jdstrand> kyrofa: hey, I think zyga was looking at the lxc snaps not updating with priority last week. I believe he has vacation to burn and is not around a lot atm
<kalikiana> ^^ zyga eoy'ed already
<kalikiana> re
<anddam> hello
<Chipaca> anddam: hello
<daniellimws> hi how can I run the scripts in tools/travis locally?
<kalikiana> daniellimws: you'll probably want to have a chat with elopio about that
<daniellimws> ok it is regarding this task http://paste.ubuntu.com/26171261/
<daniellimws> from the conversation above, I probably should not send this to travis untested, to avoid eating up resources right?
<kalikiana> daniellimws: yes and no... I believe there was another task to make it possible to run it locally as you're asking, but it's not possible right now
<daniellimws> kalikiana: Well I suppose I'll just commit it then, since there's nothing running now it seems. If it's faulty it will die very quickly.
<kalikiana> daniellimws: Yeah. I'd say go ahead. And otherwise leo should be around soon
<anddam> is snappy a Canonical's project?
<mup> PR snapcraft#1806 opened: ci: transfer generated snapcraft snap to transfer.sh <Created by daniellim2000> <https://github.com/snapcore/snapcraft/pull/1806>
<pedronis> mborzecki: what's the difference between #4391 and #4393  ?  given that John reduced the travis jobs they will eat even more travis chances
<mup> PR #4391: travis, run-checks: split travis job into build matrix <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4391>
<mup> PR #4393: travis: separate unit tests into separate build matrix jobs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4393>
<pedronis> can one be closed?
<mborzecki> pedronis: 4393 has unit tests as a separate job
<mborzecki> afaiu, travis is gating job execution already, so those should not eat up all the nodes
<pedronis> they don't eat nodes, they eat travis jobs
<pedronis> exactly
<pedronis> to be clear I'm not against the experiment, I'm against having the experiment twice
<pedronis> given our current constraints
<mborzecki> also, unit tests were supposedly taking quite long, so the idea was to see whether moving those to separate jobs has a positive effect on the build time
<mborzecki> hm i guess, i can cancel 4393 job for now, and i'll restart it in the evening
<pedronis> Chipaca reduced travis jobs to 2 thinking about other stuff, that approach would need more jobs (if possible) instead :/
<mborzecki> and i've canceled the jobs that were not started yet in 4391
<mborzecki> pedronis: yeah, we need to find a sweet spot, or write a spread job runner :P
<mup> PR snapcraft#1793 closed: project: refactor storeapi <Created by daniellim2000> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1793>
<pedronis> yea, except that one of the motivation of spread was indeed not to be on task of running a permanent service :/
<pedronis> trade-offs
<Chipaca> anddam: what do you mean?
<Chipaca> pedronis: how are your jobs faring with the new limit? any further luck?
<Chipaca> should we make snapcraft or the store discourage people from calling something "foo-snap"?
<Chipaca> sergiusens: ^ wdyt?
<niemeyer> Hey folks
<niemeyer> I'm in NY and headed to the hotel
<niemeyer> A bit tired but can probably try to help moving a few things forward when I get a room
<niemeyer> cc pedronis Chipaca
<Chipaca> niemeyer: ack
<Chipaca> niemeyer: tests are unhappy (lots of timeouts/errors/out-of-machines with linode cascading into timeouts in travis)
<niemeyer> If there are any fires, please drop me a note about them in the forum so I start there
<Chipaca> niemeyer: ratcheted travis down to 2 runs max
<Chipaca> niemeyer: not sure whether it's helped
<niemeyer> Ack
<niemeyer> It should help
<Chipaca> niemeyer: mborzecki has a couple of PRs to play with splitting spread runs into N, per arch, which might make things easier
<niemeyer> I'm planning a revamp of our runs so we allocate systems dynamically
<niemeyer> That might help making it cheaper and faster at the same time
<niemeyer> Saviq needs this too
<Chipaca> niemeyer: but when possible there's a bunch of tweaks we should probably do to the images to make them prepare quicker (and some tests hit the network less)
<Chipaca> niemeyer: but, worst case, we'll sort it out in the new year :-)
<niemeyer> Agreed
<niemeyer> And agreed :)
 * Chipaca ~> bbl
<kalikiana> elopio: hey. could we chat about the yaml for integration tests in snapcraft#1639?
<mup> PR snapcraft#1639: grammar: to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1639>
<elopio> kalikiana: sure.
<elopio> kalikiana: this is the closest I got to what I would like to see, but still not 100% happy: https://github.com/snapcore/snapcraft/blob/master/snapcraft/tests/fixture_setup.py#L939
<kalikiana> elopio: mind joining me in the weekly?
<sborovkov_> how can I enable core dump generation on ubuntu core?
<elopio> kalikiana: sure, give me a second.
<kalikiana> Aye
<hurricanehrndz> what kernel modules are required for the build tests to pass?
<hurricanehrndz> I keep seeing issues with the seccomp test when testing setuid
<hurricanehrndz> specifically can: request_module (can-proto-0)
<pedronis> Chipaca: I got again a timeout (49+ mins)
<pedronis> Chipaca: https://travis-ci.org/snapcore/snapd/builds/315911230?utm_source=github_status&utm_medium=notification
<kalikiana> elopio: sent you my notes. it's probably easiest if I update my branch first, and you can look into removing update_part later since I'll be adding the parts arguments anyway
<kalikiana> now time to head out, for drinks and dinner
<mup> PR snapcraft#1805 closed: lifecycle: use the -no-fragments mksquashfs option <Created by tyhicks> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1805>
<brunosfer> Hi guys, is it possible to specify the architecture of a snap when downloading it? e.g. sudo snap download <snap name> --armhf
<pedronis> brunosfer: not super official but UBUNTU_STORE_ARCH=armhf snap download   ... should work
<gsilvapt> elopio, you around?
<Chipaca> hurricanehrndz: which test suite?
<hurricanehrndz> Chipaca: One sec, I think I might have figured it out. I'm going to run one more test, and I'llreport back
<Chipaca> hurricanehrndz: ok (but also report which test suite you're talking about -- there're several, and who knows to help varies)
<hurricanehrndz> Chipaca: sounds good
<pedronis> Chipaca: it's about to fail again with a timeout :/
<brunosfer> pedronis: Thank you. It works, however when I do in a amd64 system the UBUNTU_STORE_ARCH=amd64 sudo snap download <snap name> it downloads a different version of the snap then it does in an amrhf with the exact same command.
<brunosfer> pedronis: Do you have any idea why this happens?
<pedronis> brunosfer: not sure,  best to try to pass a channel --stable or something explicitly
<brunosfer> pedronis: I will give it a shot. Thankx
<hurricanehrndz> Chipaca: yup, figured out the seccomp test, it had already been fixed in master
<Chipaca> brunosfer: er, you mean UBUNTU_STORE_ARCH=armhf right?
<brunosfer> pedronis: Doesn't work with the --stable flag. I could try to specify the version, however my intention is to get the latest version regardless of the architecture downloading the snap
<brunosfer> Chipaca: I mean UBUNTU_STORE_ARCH=amd64
<Chipaca> brunosfer: but that's telling it to download the amd64 snap, don't you want the armhf one?
<brunosfer> Chipaca: but could also be armhf, I just want consistency on the version I download regardless of the architecture downloading the snap
<Chipaca> brunosfer: that sounds like a strange requirement to me, could you explain further?
<pedronis> notice that different arch different revision
<Chipaca> pedronis: let _me_ press the 'restart' button this time; it likes me :-p
<brunosfer> Chipaca: I want to make the download of the snap to send it oflfline to another device that has a different architecture.
<pedronis> for the version you need to look at snap info *.snap
<brunosfer> pedronis: You mean that the snap I'm trying to download might have different versions for different architectures...
<Chipaca> brunosfer: I understand that, but then you compare what you download with âUBUNTU_STORE_ARCH=amd64 snap download thesnapâ with what you install on an armhf system with âsnap install thesnapâ; those are different things
<Chipaca> brunosfer: revisions, not versions
<pedronis> Chipaca: I already did :/
<brunosfer> Chipaca: in this case, I'm downloading the nmap (because it's small) for testing purposes, but the version is in the name of the snap when I download the file right?
<pedronis> no
<pedronis> that's the revision
<pedronis> the files produced by snap download have the revision in them
<pedronis> I mean the file names of the files
<brunosfer> pedronis: Ok, thankx, my mistake then, I will install them and check the version. They should be the same then :)
<Chipaca> brunosfer: in "snap info nmap" (on amd64), the (29) is the revision; 7.12SVN-0.6 is the version
<Chipaca> awww they're still using svn
<Chipaca> :-)
<pedronis> brunosfer: snap info  <snapfile>  can give you the version without installing first
<brunosfer> Chipaca: Thanks for the help ;)
<brunosfer> pedronis: Thanks for the help ;)
<pedronis> in case
<brunosfer> pedronis: Yes, but I was being mislead by the name of the snap. Thanks for the help ;)
<sergiusens> elopio kyrofa snapcraft#1801 has no reviews yet, being pretty simple it should go fast
<mup> PR snapcraft#1801: lifecycle: detect docker to auto setup core <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1801>
<Saviq> is it possible to limit the architectures the snap is built for on build.snapcraft.io ?
<sergiusens> Saviq not today, not yet
<Saviq> ok, let's see what happens then
<mup> PR snapcraft#1806 closed: ci: transfer generated snapcraft snap to transfer.sh <Created by daniellim2000> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1806>
<Wulong> How do I install a snapshot in a custom directory? its size exceed /
<mup> PR snapcraft#1801 closed: lifecycle: detect docker to auto setup core <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1801>
<mup> PR snapd#4388 closed: overlord/snapstate: fix auto-refresh summary for 2 snaps <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4388>
<Chipaca> Wulong: pardon?
<tyhicks> jdstrand: what's your advice on the test errors in https://github.com/snapcore/snapd/pull/4396 ?
<mup> PR #4396: snap: use the -no-fragments mksquashfs option <Created by tyhicks> <https://github.com/snapcore/snapd/pull/4396>
<tyhicks> jdstrand: they're due to http requests with the store timing out
<tyhicks> (unrelated to my changes0
<Wulong> Chipaca: how can I install a snap to a custom dir. Eg. snap install vlc --store-to-some-custom-path=/some/custom/path
<tyhicks> it doesn't look like I have the ability to restart the tests
<Chipaca> Wulong: currently you can't, but if you have a single location that could hold all the snaps you need, you can mount that
<Chipaca> Wulong: what sizes are we talking?
<Wulong> 30 GB
<Chipaca> Wulong: the .snap is 30GB?
<Wulong> Not sure if its the snap or its data.
<Wulong> Probably the latter.
<Chipaca> Wulong: the snap is heavily compressed, so it might be significantly smaller
<Chipaca> Wulong: and, it's mounted compressed; you don't need space for more than just the snap
<Chipaca> Wulong: but if you do need more space, /var/lib/snapd/snaps/ is where you need to put the space (but you need to mount it before installing any snaps...)
<Wulong> Ok, I'll give it another shot. Must have been application error or config issue.
<Wulong> Yea I know, but I don't have a free partition :|
<Chipaca> Wulong: then where were you going to put the snap?
<Wulong> Thanks for the help Chipaca
<Wulong> In /home
<Chipaca> Wulong: mount --bind is your friend
<Wulong> Ah, of course. Forgot abotu that one.
<Wulong> Linux has become too easy. Makes me lazy
<Chipaca> Wulong: :-)
<jdstrand> tyhicks: let me look
<Chipaca> tyhicks: jdstrand: we're having issues with spread and linode and travis
<jdstrand> Chipaca (cc tyhicks): whoops too late. I clicked 'restart build'
<jdstrand> tyhicks: if this build fails, I would comment in the PR that the test failures are unrelated
<Chipaca> jdstrand: ð
<tyhicks> ack, thanks
<pedronis> Chipaca: IÂ managed to merge some stuff, but maybe master is red for all IÂ know
<Chipaca> pedronis: when is it you're off?
<sergiusens> elopio look at this error, wrong snapcraft is being called https://travis-ci.org/snapcore/snapcraft/jobs/316053900
<sergiusens> ohh nvm
<lundmar> hmm, isn't --devmode and --classic supposed to disable confinement? I have a tool that still gets permission denied when writing on NFS shares despite being installed with --devmode and --classic.
<lundmar> I'm running 2.29.4.2
<kyrofa> lundmar, yes, although you still may be hitting traditional permissions
<mup> PR snapd#4399 opened: rewrite snappy-app-dev <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4399>
<pedronis> Chipaca: Friday is eoy for me
<Chipaca> pedronis: ah ok, same here
#snappy 2017-12-14
<mborzecki> morning
<kalikiana> good morning o/
<mborzecki> any idea why cassandra is no longer listed in `snap find --section=database` ?
<mborzecki> pstolowski: hey
<pstolowski> morning!
<mborzecki> pstolowski: what do you know about cassandra snap?
<pstolowski> mborzecki, zero
<mborzecki> linode:debian-9-64:tests/main/searching is failing because cassandra is no longer listed in the output of `snap find --section=database`
<mborzecki> judging by the comments, it's amd64 only, and the test, if running on amd64, will try to look it up in the store
<mborzecki> pstolowski: any ideas why it might be gone now?
<pstolowski> mborzecki, oh, i see. i guess it doesn't really matter, we should just change the test to search something else
<pstolowski> mborzecki, mongo33 looks like a good candidate
<mborzecki> pstolowski: is it also amd64 only?
<pstolowski> mborzecki, yes
<mup> PR snapd#4400 opened: tests/main/searching: handle changes in featured snaps list <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4400>
<mborzecki> pstolowski: can you take a look ^^
<pstolowski> looking
<Chipaca> morning peeps. How's things today?
<pstolowski> Chipaca, hey! mind taking a look at https://github.com/snapcore/snapd/pull/4400, tat should unblock tests
<mup> PR #4400: tests/main/searching: handle changes in featured snaps list <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4400>
<kalikiana> d'oh was looking a while for a "missing" property, only to notice later self wasn't the right object
 * kalikiana coffee break
<zyga-ubuntu> pstolowski: good morning
<pstolowski> hey zyga-ubuntu !
<pedronis> Chipaca: hi, master is also red with overall timeout atm
<zyga-ubuntu> how are you doing?
 * zyga-ubuntu looks at the snowstorm outside
<zyga-ubuntu> I'm not doing my usual outdoor stuff today
<zyga-ubuntu> decided to hop in to see how you are all doing
<pstolowski> zyga-ubuntu, i'm good, thanks! how are your holidays?
<pedronis> Chipaca: so reducing to two jobs didn't help (much),   start to suspect some network ops that are slow most of the times,  but not always?
<zyga-ubuntu> pstolowski: good :-) I feel much more at ease than before
<Chipaca> pedronis: should i bump it back up then?
<zyga-ubuntu> and catching up on loads of things I put off at home :)
<Chipaca> zyga-ubuntu: dude, if you pop in, we're just going to tell you about things that are broken :-)
<zyga-ubuntu> Chipaca: haha
<zyga-ubuntu> Chipaca: what's broken? :)
<Chipaca> zyga-ubuntu: JamieBennett
<zyga-ubuntu> Chipaca: believe me, usually I'm outside by now but it's snowing so badly I'm not doing that now
<Chipaca> zyga-ubuntu: we broke the boss
<zyga-ubuntu> ??
<pedronis> Chipaca: I don't know
<zyga-ubuntu> is jamie allright?
<koza> zyga-ubuntu, hey, snowing. cmon nice sun here
<pedronis> Chipaca: we need to understand what is slow
<Chipaca> zyga-ubuntu: all his snaps are stateless
<zyga-ubuntu> koza: WAT, where are you?
<Chipaca> zyga-ubuntu: bah
<Chipaca> zyga-ubuntu: it looks like all his snaps can't talk to dbus
<zyga-ubuntu> Chipaca: rm -rf ~/snap ?
<JamieBennett> zyga-ubuntu: I'm fine but yesterday was a day of finding a tonne of bugs it seems
<mborzecki> zyga-ubuntu: hey, too bored vacationing? :)
<zyga-ubuntu> Chipaca: apparmor denials?
<Chipaca> zyga-ubuntu: no obvious unexpected denials
<zyga-ubuntu> mborzecki: hehe, just stuck at home for the day
<zyga-ubuntu> Chipaca: any missing dbus rules?
<koza> zyga-ubuntu, LDZ
<zyga-ubuntu> (not apparmor, dbus)
<Chipaca> zyga-ubuntu: even things like opening a url didn't work i think
<JamieBennett> zyga-ubuntu: everywhere from individual snaps to firmware issues with fwupdmgr, to USB C/Thunderbolt bugs
<Chipaca> (and things worked here)
<zyga-ubuntu> mmmmm
<JamieBennett> Chipaca: that was a bug with unity -> Gnome Shell
<Chipaca> JamieBennett: did you get a priest in
<zyga-ubuntu> JamieBennett: what happens when you run snap run --shell in hello-world and then run xdg-open http://example.org
<JamieBennett> Chipaca: on upgrade the .desktop file for Chrome when it is pinned to the dock does not contain %u so no urls were working when passed in
<Chipaca> JamieBennett: chrome, not chromium?
<JamieBennett> zyga-ubuntu: the url thing was a Chrome issue
<JamieBennett> Chipaca: Chrome, yes
 * JamieBennett should switch to Chromium
<mborzecki> or firefox :)
 * zyga-ubuntu has one more AP to update and install at home 
<Chipaca> JamieBennett: that's a really old bug: https://askubuntu.com/a/729555/711
<JamieBennett> mborzecki: I'd love to but HO's dont work for me and all my passwords are in Chrome so it would take some time to migrate
<zyga-ubuntu> and then the backup disks for everything at home
<JamieBennett> Chipaca: good find, I was barking up the wrong tree thinking it was a snap issue and debugging that
 * zyga-ubuntu hugs everyone for using snaps and finding issues we will fix for everyone 
<Chipaca> JamieBennett: not so much a find as a memory
<Chipaca> JamieBennett: :-)
<JamieBennett> Chipaca: I now have the pleasure of tracking down this bug - https://pastebin.canonical.com/205517/
 * Chipaca steps slowly away from the JamieBennett 
<JamieBennett> lol
<zyga-ubuntu> on the other hand
<zyga-ubuntu> star wars was fun
<zyga-ubuntu> go and see it
<JamieBennett> zyga-ubuntu: Booked for Christmas Eve, looking forward to it.
<zyga-ubuntu> I'll look around for non-dubbed version, maybe without those distracting subtitles next
<JamieBennett> I hear Yoda's back, some presenter on UK TV let it slip by accident
<zyga-ubuntu> JamieBennett: I have no comment on the matter
<JamieBennett> Well, its all over the UK news sites so hard to miss :(
 * JamieBennett stops reading the news
<zyga-ubuntu> JamieBennett: in my only comment I will say that the movie is better than I was expecting
<zyga-ubuntu> JamieBennett: not sure if that says my expectations were low
<JamieBennett> zyga-ubuntu: was it better than the last one?
<zyga-ubuntu> JamieBennett: yes
<JamieBennett> nice
<zyga-ubuntu> JamieBennett: I think it ranks higher than some of IV-VI episodes
<mborzeck1> last one as in 'rouge one' or 'the force awakens' ?
<zyga-ubuntu> mborzeck1: FA, R1 is somewhat outside
<zyga-ubuntu> at least for my comment above
<mup> PR snapcraft#1755 closed: tests: collect the autopkgtest results and save them in git  <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1755>
<gsilvapt> hello all
<gsilvapt> I'm trying to run the static tests and I'm getting an error: ./runtests.sh: line 58: codespell: command not found
<gsilvapt> Any suggestions?
<kalikiana> gsilvapt: you'll want to `sudo apt install codespell`
<gsilvapt> thank you, kalikiana. I may have forgotten to install the dependencies required. I'll try again now
<daniellimws> I think it should be pip instead of apt
<daniellimws> or both should work
<gsilvapt> daniellimws, yes, both work. I thought it was strange to have only apt working
<cachio> pedronis, hey, is there any url to get the version of the core snap in edge, or beta?
<Chipaca> so... why on earth is tests/main/interfacs-many taking 5 inutes?
<cachio> pedronis, whithout using any header
<Chipaca> cachio: you need to set some headers
<Chipaca> cachio: why?
<Chipaca> cachio: you need to at least set X-Ubuntu-Series
<cachio> Chipaca, it is because I need to setup the trigger in jenkins and it just allow to add a url
<cachio> Chipaca, is it possible to pass the series as part of the url?
<Chipaca> cachio: i don't think so, no
<Chipaca> cachio: but, give me a bit
<mup> PR snapd#4401 opened: [WIP] snapstate/ifacestate: autoconnect tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/4401>
<pedronis> no, all apis we have rely on headers
 * pedronis lunch
 * jamesh wishes the travis-ci logs weren't quite so verbose
<Chipaca> cachio: do you need it for both edge and beta?
<cachio> Chipaca, yes, but most important is edge
<Chipaca> cachio: https://people.canonical.com/~john/core_edge.json
<cachio> Chipaca, I dont have permiossions to see that
<Chipaca> cachio: try again
<cachio> great
<cachio> Chipaca, where are yo creating this?
<Chipaca> cachio: people.c.c
<Chipaca> cachio: crontab :-)
<Chipaca> cachio: how often should it check?
<cachio> Chipaca, every 10 minutes
<cachio> Chipaca, thanks, I'll add this to the jenkins jobs
<Chipaca> cachio: any otoher data you need in that json?
<cachio> not sure yet, but I think with that info we are ok
<cachio> is it for amd64, right?
<cachio> because I need for arm64 and armhf
<cachio> Chipaca, I'll be back for the standup
<cachio> Chipaca, I need these triggrers to run the edge validation on cm3 and dragonboard
<Chipaca> cachio: i can easily change it to be per arch as well
<Chipaca> cachio: different urls though; i'll tell you where when it's done
<cachio> Chipaca, :)
<cachio> Chipaca, great, thansks
<cachio> Chipaca, I'll be back for daily
<Chipaca> cachio: i'll probably be late for the daily
 * cachio afk
<Chipaca> cachio: https://people.canonical.com/~john/core/
<anddam> Chipaca: I was trying to figure about Snappy and Ubuntu Core, I wasn't sure if it was a single project, two Canonical's projects working togheter with Core relying on Snappy, or a third party project that's just being used by Core
<anddam> I got curious about "containerized" apps in a desktop system, so Ubuntu Core came out
<mup> PR snapd#4397 closed: tests/main/lxd: temporarily switch to manual <Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4397>
<Chipaca> anddam: ubuntu core is a thing from before snappy
<Chipaca> anddam: snappy ubuntu core is ubuntu core based on snappy
<Chipaca> anddam: in snappy there is a special snap that is called 'core', jsut to keep people on their toes
<Chipaca> (in seriousness, the snap called 'core' is or was when we started a lot like what used to be ubuntu core)
<Chipaca> anddam: but note snaps aren't containerised as i understand that terminology; they're confined
<Chipaca> mborzeck1: you mentioned a mvo script that analysed spread output, do you have that somewhere?
<mborzeck1> Chipaca: https://gist.github.com/mvo5/06a206e991b0ae5a53606821dded4bdf
<anddam> Chipaca: ah thanks for the info. What's the difference between being containerised and confined there?
<Chipaca> mborzeck1: i was about to dig into interfaces-many's suspicious 5 minute test runs, but thught i should check all of them first
<Chipaca> and, i need to run to the school -- will bbl
<anddam> also does snappy aim to be a full system package manager, like can it be seen replacing apt on an ubuntu system at some point in future/
<Chipaca> anddam: snaps get a restricted view of the actual system (possibly with a different filesystem)
<anddam> s,/$,?
 * Chipaca -> afk
<anddam> k
 * pstolowski lunch
<mup> Bug #1738197 opened: Daemons do not have an /run/user/* dir created <Snappy:New> <https://launchpad.net/bugs/1738197>
<ackk> hi, I'm getting this error when trying to install a snap with "try": http://paste.ubuntu.com/26182870/ am I doing something wrong?
<mborzeck1> pstolowski: standup
<pstolowski> mborzeck1, coming
<mborzeck1> cachio: standup
<Chipaca> ackk: that's strange, let me test something locally
<ackk> Chipaca, I think I found the issue, it seems I can't install the snap anymore in an LXD unless it's privileged
<jdstrand> Chipaca: fyi, I helped him with opening urls, it was a local issue. it's sorted
<ackk> (because of a systemd issue)
<Chipaca> ackk: :-(
<jdstrand> Chipaca: ah, I see you know that already :)
 * jdstrand goes back to reading backscroll and commenting on things that no longer need discussion
 * Chipaca hugs jdstrand 
<jdstrand> Chipaca: the syscall denial in https://pastebin.canonical.com/205517/ is for listen. that is not in the dbus interface (interesting)
<jdstrand> JamieBennett: hey, would you mind trying something?
 * jdstrand hugs Chipaca 
<jdstrand> oh, the new one better than force awakens? wow. /me tries to temper expectations
<jdstrand> (I like force awakens a lot)
<niemeyer> Hello!
<jdstrand> hey niemeyer :)
 * kalikiana going to lunch in ~10
<kalikiana> niemeyer: o/ what's up
<kalikiana> niemeyer: actually, would you have time for a quick chat? can be later today. there's something I wanted to ask you
<kalikiana> (about architectures)
<JamieBennett> hey jdstrand, sure
<jdstrand> JamieBennett: hey. let me try to summarize the problem as I understand it
<jdstrand> JamieBennett: the corebird snap isn't able to communicate on dbus and dies/stops working/doesn't work correctly
<jdstrand> JamieBennett: is that accurate?
<JamieBennett> jdstrand: Actually after more debugging I don't think it is a dbus issue
<JamieBennett> I used dbus-monitor to see that the settings in Corebird were actually being set
<jdstrand> JamieBennett: I saw a seccomp denial for 'listen'
<niemeyer> kalikiana: Today and tomorrow will be somewhat tight as we're having a two-days meeting, but I will be around next week if we don't find a time slot
<jdstrand> JamieBennett: so this would've caused some grief
<JamieBennett> jdstrand: Corebird does not reflect the new settings in the UI
<JamieBennett> jdstrand: happy to continue debugging though to see what the real issue is
<jdstrand> JamieBennett: ok, the listen denial probably isn't the cause of that, but it is a bug in the dbus interface regardless
<JamieBennett> ok
<jdstrand> JamieBennett: but, if you wouldn't mind added this to /var/lib/snapd/seccomp/bpf/snap.corebird.corebird.src:
<kalikiana> niemeyer: Alright. I'd say if there's time today that'd nice grand, but it's not an emergency so we can do it next week
<jdstrand> listen
<jdstrand> accept
<jdstrand> accept4
<jdstrand> JamieBennett: then running /snap/core/current/usr/lib/snapd/snap-seccomp compile /var/lib/snapd/seccomp/bpf/snap.corebird.corebird.src /var/lib/snapd/seccomp/bpf/snap.corebird.corebird.bin
<jdstrand> JamieBennett: and then trying again, that would be great
<JamieBennett> jdstrand: OK
<mborzecki> i'm off to the 'christmas thing' at my son's kidergarten, bbl
<jdstrand> I'm already preparing a PR for this regardless if it fixes your config issue
<jdstrand> mborzecki: have fun!
 * kalikiana going for lunch now
<cachio> Chipaca, do you have the files for armhf and arm64?
<Chipaca> cachio: https://people.canonical.com/~john/core/
<niemeyer> cachio: I got the time wrong.. I need to head over to the meeting now, but will investigate this issue over the day and ping you when I have something
<cachio> Chipaca, thanks a lot
<cachio> niemeyer, sure, thanks
<cachio> niemeyer, this is a good example https://travis-ci.org/snapcore/snapd/builds/316056668
<Chipaca> so, interfaces-many legitimately takes 5 minuntes, because it does a 65 connects at an average of just over 4 seconds per connect
<Chipaca> why does a connect take 4 seconds?
<Chipaca> python3 -c $'import yaml;y=yaml.load(open("task.yaml"));\nfor i in ("execute","prepare","restore"):\n if i in y: open(i+".sh", "w").write(y[i])'
<Chipaca> oops
<sergiusens> elopio kalikiana can you enlighten me on why these cleanbuild/container builds fail https://travis-ci.org/snapcore/snapcraft/jobs/316397431
<cachio> Chipaca, could you please dhance the version in the file https://people.canonical.com/~john/core/arm64_edge.json
<cachio> I need to test if the trigger is workping properly
<kalikiana> re
<kalikiana> sergiusens: Looking
<sergiusens> kalikiana if you find the reason, fix it up in a follow up PR to that one; I've skipped and logged a bug for that for now
<sergiusens> running the actual tests is more important the having things green running against the wrong things
<cachio> Chipaca, there?
<mup> Issue snapcraft#1767 closed: stage-packages does not respect architectures <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1767>
<mup> PR snapcraft#1788 closed: repo: error for packages with broken dependencies <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1788>
<mup> PR snapcraft#1447 closed: add support for the "contact" field in snapcraft <Created by mvo5> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1447>
<mup> PR snapcraft#1579 closed: Make it possible to use the cmake ninja generator <Created by aleixpol> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1579>
<mup> PR snapcraft#1726 closed: schema: sources should not have defaults <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1726>
<mup> Bug #1738222 opened: FAIL: main_test.go:769: snapSeccompSuite.TestCompatArchWorks <Snappy:New> <https://launchpad.net/bugs/1738222>
<mup> PR snapd#4400 closed: tests/main/searching: handle changes in featured snaps list <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4400>
<mborzecki> yay, at least one fire is put out
<mborzecki> guys, if you have PRs open and they fail in tests/main/searching, then you pull the changes from master
<mup> PR snapcraft#1807 opened: tests: run test_cleanbuild in LXD on Travis <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1807>
<Chipaca> cachio: sorry was afk. can i still help?
<Chipaca> (was at physio)
<cachio> Chipaca, it is ok, I already validated the triggers
<Chipaca> cachio: ok
<Chipaca> cachio: now, what was the thing about images?
<Chipaca> cachio: I can put .png files on p.c.c, but I don't think that's what you meant :-p
<cachio> Chipaca, seems to be working well
<cachio> Chipaca, tomorrow I'll check it again to see if the whole thing is working
<cachio> Chipaca, hehe, no it is ok
<cachio> Chipaca, I need to build the image that I use for cm3 on beta validation
<cachio> so, when there is a new core snap in beta (armhf) I need to generate a new image to test the cm3
<cachio> Chipaca, but, first I prefer to make the edge validation work properly and then go to beta
<Chipaca> cachio: ok, fair enough
<Chipaca> cachio: I don't know if p.c.c has any sort of a SLA though; if this is going to block work if it goes down, we should look into moving it somwehre more solid (my main aim was to unblock you today)
<cachio> Chipaca, ok, in that case I can setup a service on prodstack
<cachio> Chipaca, it was the original idea
<Chipaca> cachio: right, that's a better solution long term
<cachio> Chipaca, agree
<cachio> Chipaca, thanks for the json files :)
<Chipaca> cachio: i can share the super high tech software that's behind them if you want :-p
<cachio> Chipaca, hehehe, yes please
<cachio> I am imaging the for
<Chipaca> cachio: https://people.canonical.com/~john/core/get-core
<kalikiana> kyrofa: would you have time for a chat in a bit? about garmmar stuff
<cachio> Chipaca, awesome
<kalikiana> kyrofa: elopio: sergiusens  Also heads-up I'll be off tomorrow and back on Monday
<mup> PR snapcraft#1803 closed: ci: correctly run from snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1803>
<kyrofa> kalikiana, sure, let me know
<kalikiana> kyrofa: in say 5 minutes? just got out of another meeting and getting a coffee
<hurricanehrndz> Who helps pack the fedora rpm, I'm trying to update suse and I'm just trying to understand the differences and fix some of the issues
<kyrofa> hurricanehrndz, that's Son_Goku
<kyrofa> kalikiana, sure
<hurricanehrndz> oh yeah that's right
<Son_Goku> hurricanehrndz: hi
<Son_Goku> what's up?
<hurricanehrndz> Son_Goku: I'm just trying to understand some of the linker flags used in the spec file for fedora
<hurricanehrndz> Son_Goku: I have suse build working, but I'm not ending up with static binaries for snap-exec and snap-update-ns, which I understand is required for base snaps
<Son_Goku> yeah
<Son_Goku> it's a tricky mess
<hurricanehrndz> Son_Goku: Yup, I gather that much
<Son_Goku> I had been trying to do the suse one myself, but the golang toolchain is screwy :(
<hurricanehrndz> Son_Goku: Well, I'm almost there https://build.opensuse.org/package/show/home:hurricanehernandez:branches:system:snappy/snapd
<hurricanehrndz> Son_Goku: I'm just updating it.
<hurricanehrndz> Son_Goku: the go macros are especially troublesome and I see how you handle it on fedora, but I'm confused about the linker flags you use in your gobuild macro
<hurricanehrndz> Could you please walk me through them, specifically the '-B' flag, which I thought was for static and dynamic linking but the spec file uses a random hex or is the hex the builduuid
<Son_Goku> sure,
<kalikiana> kyrofa: I'm in the weekly now
<Son_Goku> hurricanehrndz, also, `gpg2` is not correct
<hurricanehrndz> Son_Goku: Thanks. I started with the spec that was on github within snapcore, go figure
<hurricanehrndz> Son_Goku: ah.. I see you are going through my spec
<Son_Goku> it has to be gpg1
<Son_Goku> unfortunately, upstream snapd has not fixed their stuff to use gpg2 instead of gpg1
<Son_Goku> I don't know why you're pulling in the 32-bit libs, though
<Son_Goku> apparmor needs to be disabled on %suse_version < 1500
<Son_Goku> hurricanehrndz: I guess you are going to only use vendored tarball?
<kyrofa> kalikiana, sorry, hopping in now
<Son_Goku> hurricanehrndz: also... bundling appears to still be outright banned in openSUSE: https://en.opensuse.org/openSUSE:Packaging_guidelines#Bundling_of_multiple_projects
<hurricanehrndz> Son_Goku: Son_Goku: yes
<kalikiana> No worries, I used the time to update some notes from today
<kalikiana> Tedious but useful :-P
<hurricanehrndz> Son_Goku: Hmm Yeah, I will see about unbundling later, I'm using zyga's work as a staring point
<Son_Goku> hurricanehrndz: I'd suggest starting from my packaging and start from scratch
<Son_Goku> I've made some effort to make the spec relatively portable
<Son_Goku> the main thing that'll need to change is dropping the mandatory requires for snapd-selinux on snapd, since openSUSE supports either SELinux or AppArmor
<hurricanehrndz> Son_Goku: Okay, I'm guess this is yours: https://github.com/snapcore/snapd/blob/master/packaging/fedora/snapd.spec
<Son_Goku> https://src.fedoraproject.org/rpms/snapd/blob/master/f/snapd.spec
<Son_Goku> but yes
<Son_Goku> the canonical source tree is always in src.fedoraproject.org
<Son_Goku> I don't release from snapcore/snapd
<hurricanehrndz> Son_Goku:Okay I will start there
<hurricanehrndz> Can you explain to me the ldflags on line 52
<Son_Goku> sure
<Son_Goku> in Fedora, we put a great deal of effort to make Go generate useful debug symbols
<Son_Goku> the ldflags there enable that
<Son_Goku> iirc, SUSE doesn't quite care as much about making useful debuginfo as Fedora does
<hurricanehrndz> Cool, what's '-B' flag do?
<hurricanehrndz> I tried reading the linker's man page but could find info on the hex following the flag
<Son_Goku> it's a weird go thing
<Son_Goku> it basically forces a build-id to be injected into the binaries
<Son_Goku> because rpm uses that for debuginfo splitting and packaging
<hurricanehrndz> Son_Goku: Thought so... had a feeling but couldn't find documentation
<hurricanehrndz> should have looked up go linker
<hurricanehrndz> ha ha
<Son_Goku> https://fedoraproject.org/wiki/PackagingDrafts/Go#Debuginfo
<jdstrand> Chipaca: fyi, I'm looking into the corebird issue from JamieBennett. we may hand off to the desktop team if I can't reproduce
<hurricanehrndz> Son_Goku: Thank you, love find documentation...
<jdstrand> Chipaca: it seems unrelated to snapd
<hurricanehrndz> Son_Goku: Awesome, you've been a great help, thanks everything you have done so far
<Son_Goku> np
<jdstrand> Chipaca: not 100% sure yet since I can't reproduce, but it doesn't look like it
<hurricanehrndz> Son_Goku: One more question, the vendor json specifies the exact versions of the supporting golibraries
<Son_Goku> I ignore them
<Son_Goku> aside from a few, they're mostly irrelevant
<Son_Goku> the latest stuff that matches those library references work
<hurricanehrndz> Son_Goku: Cool
<Chipaca> jdstrand: ack
<Chipaca> jdstrand: thank you!
<kalikiana> sergiusens: FYI I couldn't find a way to reproduce the failing cleanbuild test locally, so I pushed snapcraft##1807  to expose the failure in Travis (which eats the errors by the looks of it) and will investigate this more on Monday - unless elopio beats me to figuring it out
<mup> PR #1807: interfaces/builtin: allow /dev/vhci on bluetooth-control <Created by cwayne18> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1807>
 * kalikiana hugs mup very affectionately
<kalikiana> ^^ snapcraft#1807
<mup> PR snapcraft#1807: tests: run test_cleanbuild in LXD on Travis <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1807>
 * kalikiana wrapping up for today/ this week
<elopio> snappy-m-o: let me introduce you to daniellimws.
<snappy-m-o> Command ":" / ": let" not found.
<elopio> no manners...
<daniellimws> haha
 * kalikiana hugs snappy-m-o 
<flexiondotorg> kyrofa: Is SNAPCRAFT_SETUP_CORE still necessary for building classic snaps inside docker containers?
<kyrofa> flexiondotorg, if snapd can't run, it's necessary
<flexiondotorg> Thanks
<kyrofa> flexiondotorg, without some jiggery, docker falls into that category
<kyrofa> Sure thing!
<kalikiana> flexiondotorg: kyrofa it's becoming automatic as of snapcraft#1801 which will be in the next release
<mup> PR snapcraft#1801: lifecycle: detect docker to auto setup core <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1801>
 * Chipaca EODish
<brunosfer> Hi guys, does anyone know how can I replicate the GET requests to the snapcraft API ? e.g. sudo snap info <snap name>
<brunosfer> Is there any public API documentation?
<diddledan> flexiondotorg: can I pm a sec?
<Pharaoh_Atem> hurricanehrndz: everything going well with suse packaging of snapd?
<hurricanehrndz> Pharaoh_Atem: Well I just started tackling, I got all the info I need.. just time is required...
<Pharaoh_Atem> cool
<hurricanehrndz> Pharaoh_Atem: are you on suse?
<Pharaoh_Atem> hurricanehrndz: I'm on Fedora, openSUSE, and Mageia :)
<hurricanehrndz> Pharaoh_Atem: Cool, I'll send you a msg once it's ready for testing
<diddledan> flexiondotorg: tis ok, I got ahold of popey
<mborzecki> brunosfer: try running snapd with SNAPD_DEBUG=1
<mborzecki> brunosfer: example curl based on what's in the logs: https://paste.ubuntu.com/26184762/
<brunosfer> mborzecki: I stopped the service snapd, but now I can't find the path to the snapd binary file...
<mup> Bug #1738295 opened: snap auto-refresh re-installs removed snaps <Snappy:New> <https://launchpad.net/bugs/1738295>
#snappy 2017-12-15
<mup> PR snapd#4402 opened: tests: save the snapd-state without compression <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4402>
<mborzecki> morning
<pstolowski> mornings
<mborzecki> pstolowski: hey
<pstolowski> o/
<mborzecki> i've pushed some tools to analyze travis logs right here: https://github.com/bboozzoo/snapd-tools
<Chipaca> *yawn*
<Chipaca> gmornin'
<pstolowski> morning Chipaca!
<mborzecki> Chipaca: o/
<mborzecki> Chipaca: have you found anything interesting in interfaces-many test?
<Chipaca> mborzecki: just that connect takes 4s+, and it does 65 of 'em
<Chipaca> mborzecki: i'm wondering about digging into why it takes that long per connect
<Chipaca> pstolowski: how long does a hook take to execute?
<mborzecki> Chipaca: are there any hooks used in this test?
<Chipaca> mborzecki: I don't think so, but run-hook is still run and still seems to take time
<Chipaca> that's why i'm asking: what's the minimum time run-hook takes, if there is no hook
<Chipaca> this is run-hook that's part of connect-snap
<Chipaca> reporting its ReadyTime - SpawnTime to be an average of 4s also
<pstolowski> well, hooks in the tests are very simple, hookmgr just executes hook script and grabs the output, that's as fast as it can be. unless the hook misbehaves, in which case we can get stuck waiting on 10min timeout
<Chipaca> (ie most of the time is there)
<Chipaca> pstolowski: so that's my question, how fast is "as fast as it can be"
<Chipaca> because if that's 4s then something is wrong
<pstolowski> Chipaca, if there is no hook script present then there is nothing to do.. it's a no-op
<Chipaca> and if it's _not_ 4s, then something else is wrong :-)
<pstolowski> Chipaca, is this about interfaces-many test?
<Chipaca> pstolowski: there are no hook scripts in any of tests/lib/snaps/test-snapd-policy-app-*/
<Chipaca> pstolowski: and it's taking 4s per hook
<pstolowski> Chipaca, indeed
<Chipaca> pstolowski: so, there's a bug in there somewhere
<Chipaca> when I say "it's taking 4s per hook", what I should say is "it's reporting 4s per hook"
<Chipaca> because the bug could also be in the reported time :-)
<pstolowski> interesting. how do you measure it, do you have a modified code?
<Chipaca> pstolowski: http://paste.ubuntu.com/26187733/
<Chipaca> pstolowski: just looking at changes
<Chipaca> that is, /v2/changes?select=all, and then print and sort
<Chipaca> to be clear, i am suspecting the times are somehow wrong
<pstolowski> Chipaca, what is the number in parentheses?
<Chipaca> pstolowski: id
<pstolowski> k
<Chipaca> but it doesn't make sense for them to be like this, so it's probably counting spawn time from the change and not the task spawn, or something
<Chipaca> meaning i might need to accumulate time along a change
<Chipaca> hm
<Chipaca> i'll give it a try
<pstolowski> Chipaca, I was going to say exactly that. the times on the left looks like accumulated times from the start
<Chipaca> pstolowski: http://paste.ubuntu.com/26187774/
<Chipaca> accumulated, now
<Chipaca> that makes more sense
<Chipaca> but it does mean the time is all in connect itself
<Chipaca> i'm going to have to profile this aren't i :-/
 * Chipaca sighs and gets onto it
<pstolowski> Chipaca, big gap between 8.209555 install-snap(2)/run-hook(14) and 17.577298 install-snap(8)/setup-profiles(54) ?
<Chipaca> pstolowski: are you still looking at the non-deaccummuated one?
<pstolowski> Chipaca, ah gosh, right, I confused the tabs in my browser
<Chipaca> :-)
 * pstolowski closes the old tab to be safe ;)
<Chipaca> pedronis: shouldn't SpawnTime of a change be the time it was run, not the time it was created?
<Chipaca> pedronis: ditto task
<Chipaca> oh wait that's "AtTime"
<Chipaca> which isn't in the client >:-(
<pstolowski> Chipaca, one thing I can say for sure wrt to this test is
<mup> PR snapd#4403 opened: asserts/signtool: support for building tools on top that fill-in/compute some headers <Created by pedronis> <https://github.com/snapcore/snapd/pull/4403>
<pstolowski> Chipaca, in the past we had Connect doing multiple connections at once. that was changed to create one task for every connection which in reality adds even more tasks because of hooks
<pedronis> Chipaca: Gustavo defined it that way, but basically it's creating time, not start of running time, notice that a task can start running many times (because of retry)
<Chipaca> quick, how many definitons of a 'change' struct do we have in our codebase?
<Chipaca> answer: no less than 4 (i wouldn't swear it wasn't more)
<Chipaca> overlord/state has two, client has one, daemon has one
<Chipaca> :-( no wonder theyre out of sync
<Chipaca> pedronis: it makes knowing how long a task took to run quite hard
<pedronis> it is hard though essentialy
<pedronis> Chipaca: AtTime is used by retry with a specific time
<Chipaca> pedronis: sorry, i said hard but i meant impossible, strictly
<Chipaca> it is hard, yes
<Chipaca> but with the data exposed we can only guess at it
<Chipaca> gah
<Chipaca> EOY-day should be more puppies and less cockroaches
<pstolowski> :)
<pedronis> we could have a cumulative run time
<pedronis> also we have do and undo
<pedronis> a task is not one-time function
<mup> Issue snapcraft#1695 closed: Refactor meta into package <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1695>
<mup> PR snapcraft#1804 closed: meta: refactor into a package <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1804>
<pedronis> Chipaca: you need to measure stuff from TaskRunnun.run basically
<pedronis> *TaskRunner
<Chipaca> pedronis: i think i'll open a forum topic
<Chipaca> otherwise it'll bug me
<jamesh> yay.  green ticks next to my PRs again.
<Chipaca> jamesh: oh no you jinxed it
<Chipaca> pedronis: https://forum.snapcraft.io/t/task-accounting/3201 fwiw
<jamesh> Chipaca: apart from the tests/main/searching bug that was recently fixed, a few times it seems the tests just take too long to run for travis
<Chipaca> jamesh: yeah, we're looking into that -- they shouldn't
<Chipaca> jamesh: there are some things we can do, but we'll wait for the new year as they require a concerted effort
<Chipaca> jamesh: (this is, basically, updating the images to spend less time waiting on the network)
<Chipaca> jamesh: but then, there're still tests that are inexplicably slow; looking into that as well
<mborzecki> or randomly failing
<jamesh> Chipaca: it'd also be  nice if the test output was less verbose: when there is a failure, it takes a while to locate the error message
<Chipaca> jamesh: yeah, gustavo was going to turn off a lot of the output
<sergiusens> kyrofa elopio you both added non actionable comments to https://github.com/snapcore/snapcraft/pull/1786 please address that
<mup> PR snapcraft#1786: lxd: always install squashfuse <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1786>
<pedronis> Chipaca: I added to backlog at least otherwise it will get forgotten, Doing the simplest possible thing shouldn't be too hard, it might be too simple though.
<Chipaca> unless i'm reading this profile wrong, 2/3 of the (cpu) time is spent doing json encoding
<pedronis> Chipaca: there might be some kind of   for loop Locking/Unlocking  state somewhere in there
<jamesh> any chance of getting https://github.com/snapcore/snapd/pull/4140 merged?
<mup> PR #4140: interfaces: add an interface for gnome-online-accounts D-Bus service <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4140>
<pedronis> jamesh: if the interface don't work 14.04 should it not be exported there?
<pedronis> *doesn't work in
<pedronis> jamesh: I'm a bit unfraid that without clarity on that it can't be merged
<jamesh> pedronis: I think the D-Bus API changed between those GNOME versions, but haven't really investigated because we didn't install gnome-online-accounts by default back then (I don't think it is installed in 16.04 either)
<pedronis> jamesh: where is it installed by default?
<jamesh> pedronis: 17.10 definitely.  We had a different online accounts system in unity7
<pedronis> I'm not even sure we have a policy around interfaces that aren't there by default?
<jamesh> it'd be installed on Ubuntu-GNOME for those older releases though.
<pedronis> what happens  if one installs a snap needing this but the service is not there? does the interface auto-connect?
<pedronis> ok, it doesn't
<jamesh> pedronis: if you connected the interface but goa-daemon wasn't present, then the confined app would get a D-Bus error when it tried to contact the service
<pstolowski> pedronis, i've been looking at https://forum.snapcraft.io/t/new-configure-snapd-task-and-reverting/2774/2 in the light of 'auto-connect' task. aborting will make revert fail, no? or do I miss something?
<pedronis> pstolowski: you miss something,  as I said we would need some special casing
<pedronis> otherwise it doesn't help
<pstolowski> pedronis, indeed. somthing like a 'ignore-me' flag on the task?
<pedronis> yes
<pedronis> I thought we discussed that
<pedronis> given that your case you are splitting the bahavior of a preexisting task it would be ok
<pedronis> though setup-profiles is complicated
<pstolowski> pedronis, yes, we discussed many aspects of that but i'm sure i missed some of that because of limited understanding of entire picture and edge cases; i'm sure reviews will prove that
<mborzecki> am i the only one getting i/o timeouts all the time when trying to run anything on linode through spread?
<koza> everyone has a superpower ;-)
<mborzecki> yeah, i speak polish, what's your superpower koza.. oh wait :)
<Chipaca> pedronis: spot on. Dropping the unlock/lock in a loop in a loop (in a loop?) drops execution time to nearly nothing
<Chipaca> this is in ifacestate/helpers.go: setupSnapSecurity
<Chipaca> basically it means doing backend.Setup() with the lock held
<Chipaca> is that bad?
<Chipaca> in numbers, the test drops from over 5 minutes to under 1 minute
<pstolowski> impressive
 * cachio afk
<pedronis> Chipaca: I think over time we are moving away from freeing the lock if all we are doing is disk ops,  otoh some backend do systemd stuff I think
<Chipaca> I need to go to the boys school now (and might not make it back for the standup), but i'll look into it when i return
<sergiusens> elopio something is wrong with the nightly, trying to commit to the uncommitable https://travis-ci.org/snapcore/snapcraft/jobs/316767537
<mup> PR snapcraft#1795 closed: lifecycle: do not include source tarballs from previous runs <Created by ted-gould> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1795>
 * Chipaca returns
<Chipaca> i wonder if gofmt can find me all the instances of a for loop with a lock/unlock inside it
<pedronis> Chipaca: IÂ don't think we have a ton of those, we had some in snapstate but IÂ think we removed them
<elopio> sergiusens checking the commit...
<pedronis> Chipaca: we have about 51 Unlock of state/contexts  without a defer
<pedronis> Chipaca: or were you thinking of adding something to run-checks ?
<Chipaca> pedronis: no, was just going to look at current state
<pedronis> Chipaca: you can probably just look at each of them
<sergiusens> elopio and testing from master fails as transfer.sh is blocked
<Chipaca> pedronis: heh, wrote a thing using parser and ast
<Chipaca> found 10 locks inside loops
<Chipaca> 6 of them not in tests
<Chipaca> one is overlord.Loop, one (two actually) is overlord.Settle, one is TaskRunner.wait, one is devicestate.fetchKeys
<Chipaca> and one in daemon.finishShutdown
<Chipaca> all very boring
 * Chipaca throws the ast away and goes for grep
<pedronis> Settle is also test only
<pedronis> Chipaca: notice also that they are much more problematic if the code invoked might change the state
<pedronis> we shouldn't serialize if there's no write
<pedronis> serialize as in JSON encode
<sergiusens> elopio mind updating snapcraft#1802 ?
<mup> PR snapcraft#1802: metadata: extract metadata from appstream <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1802>
<sergiusens> elopio actually, if you have time, let's meet
<elopio> sergiusens: on the weekly?
<sergiusens> elopio one sec
<pedronis> Chipaca: will you propose a PR today?
<Chipaca> pedronis: I fear not: the systemd backend does indeed do weird stuff that can take 10s+
<pedronis> what I feared
<Chipaca> pedronis: so i think i need to talk with zyga about it, and there might be a bigger refactor
 * elopio is back
<mup> PR snapd#4404 opened: data/selinux: allow messages from policykit <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4404>
<Chipaca> also the systemd code is suspicious
<pedronis> Chipaca: given some control to backends, but we cannot pass state there, we  would need an interface
<Chipaca> pedronis: maybe define them as getting a sync.Locker
<Chipaca> not sure
<Chipaca> maybe Setup needs to return a callback to be called without the lock, so it's only frobbed once
<mborzecki> i'm done for today, enjoy your weekend guys
<Chipaca> mborzecki: see you next year!
<mborzecki> Chipaca: oh, you're not here next week?
<Chipaca> mborzecki: nor the one after that :-D
<mborzecki> haha :)
<Chipaca> mborzecki: i should be back on tuesday the twooth of january
<mborzecki> well, then merry christmas and happy new year :)
<Chipaca> mborzecki: likewise!
<Chipaca> pedronis: or maybe we move to an actual database and this whole thing goes away?
<pedronis> maybe
<pedronis> not sure it's the best time to do that (too much other feature work/bugs)
 * Chipaca nods
 * pedronis calls it a year
<pedronis> happy holidays!
<mup> PR snapd#4405 opened: taskrunner/many: KnownTaskKinds helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/4405>
<Chipaca> pedronis: have a good one! see you in 2018
<pstolowski> happy holidays pedronis!
<elopio> enjoy pedronis !
<kyrofa> ogra_, I can't remember: will removing the classic snap reset the unpacked chroot as well?
<kyrofa> Reset by removing it as well, I guess
<kyrofa> Or is there a special command I need to do that?
<kyrofa> Chipaca, perhaps you know?
<Chipaca> kyrofa: AFAIK removing the snap will remove the chroot
<Chipaca> kyrofa: because AFAIK the classic snap isn't special
<kyrofa> Chipaca, well, it's a devmode snap, so I figure it can put that anywhere it wants
<kyrofa> Removing and crossing my fingers...
<Chipaca> kyrofa: i can check for you if you want :-)
<kyrofa> Chipaca, nah, testing now
 * Chipaca was curious and kicked it off to test
<kyrofa> Chipaca, you were right
<kyrofa> It's "creating classic environment" now. Excellent
<Chipaca> kyrofa: sorry
<elopio> sergiusens: we don't yet have any results from the PPA. We are at the bottom of all queues. I think that collecting daily would be alright. We won't necessary get the results of what was triggered the previous day, but we will get the results of the most recent execution.
<elopio> there is already one execution for 20171215, so on tonights execution, the results should be collected. I'll keep an eye.
<Chipaca> ok boys and girls, I think I'm done.
<Chipaca> ttfn, and see you next year!
<brunosfer> Hi guys, does anyone know how can I start the snapd with the DEBUG MODE using the binary instead of the service?
<cjwatson> brunosfer: There are instructions for that in HACKING.md
<cjwatson> search for DEBUG
<brunosfer> cjwatson: Thanks
<mup> PR snapcraft#1808 opened: ci: don't fail if the snap transfer fails <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1808>
<elopio> nessita: cprov ^ That's to unblock you.
<mup> PR snapcraft#1809 opened: formatting_utils: add type hints <Created by konrad11901> <https://github.com/snapcore/snapcraft/pull/1809>
<nessita> elopio, thanks!
 * kyrofa is shooting, responses may be delayed
<elopio> snappy-m-o autopkgtest xenial:armhf 1807
<snappy-m-o> Computer says nooo. See logs for details:
<snappy-m-o>  Command '['/tmp/tmpcxggf713/retry_autopkgtest.sh', 'xenial:armhf', '1807']' returned non-zero exit status 1
<elopio> snappy-m-o autopkgtest 1807 xenial:armhf
<snappy-m-o> elopio: I've just triggered your test.
<elopio> sergiusens: subscribe to that one ^
<elopio> no need to make a new pr, that one is up-to-date with master, and will run what you are looking for.
<sergiusens> elopio 07 because no one will touch it for a while? :-)
<elopio> yup, and it's almost a noop change.
<kyrofa> Uhh... nessita cprov this seems like a problem: https://pastebin.ubuntu.com/26190126/
<kyrofa> It's working now. Maybe only some endpoints?
<nessita> checking
<cprov> kyrofa: does it continue to fail ? my systems are not complaining and we haven't changed certs recently, let me dig more
<kyrofa> cprov, it happened twice. Third time it successfully downloaded/installed
<nessita> kyrofa, is working for me: curl -s -H 'X-Ubuntu-Store: ubuntu' -H 'X-Ubuntu-Series: 16' -H 'X-Ubuntu-Architecture: amd64' 'https://api.snapcraft.io/api/v1/snaps/details/edukit-bot-kyrofa?channel=edge'
<sergiusens> kyrofa is this an arm device? Check the date
<cprov> kyrofa: we have some haproxy "SSL handshake failure", but it's too frequent to not have being noticed before
<kyrofa> Fair enough, just wanted to raise it in case it was an issue. If it happens again I'll let you know
<cprov> kyrofa: ah sergiusens is right, your system clock might not be current, https://lists.ubuntu.com/archives/snappy-devel/2015-March/000416.html
<cachio> niemeyer, I was researching the connection issue and there is not way to connect to the machines after the connection error
<cachio> niemeyer, so, it seems to be a problem in the machine allocation/start process
<cachio> niemeyer, today seem to be working better than the previous days, that could be because there is less traffic
<cachio> less people creating PRs
<mup> PR snapd#4406 opened: interfaces/dbus: adjust slot policy for listen, accept and accept4 syscalls <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4406>
<mup> PR snapcraft#1808 closed: ci: don't fail if the snap transfer fails <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1808>
<sergiusens> elopio this is my endgame, snapcraft#1798
<mup> PR snapcraft#1798: elf: strip the .note.go.buildid to make room for patching elf <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1798>
<popey> sergiusens: is it possible to get 'dump' plugin to _just_ dump the file at the url specified by 'source' and put it in the snap? I don't want to unpack. Just dump the file in?
<popey> think i might have to use nil, and wget in install step
#snappy 2017-12-16
<elopio> snappy-m-o autopkgtest 1807 xenial:armhf
<snappy-m-o> elopio: I've just triggered your test.
<mup> PR snapcraft#1798 closed: elf: strip the .note.go.buildid to make room for patching elf <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1798>
<mcphail> Are "install" hooks called before or after the new $SNAP_USER_DATA directory is created? Is there aby way to reference the previous $SNAP_USER_DATA directory after a snap has updated?
<mup> PR snapcraft#1810 opened: [WIP] i18n support <Created by m4sk1n> <https://github.com/snapcore/snapcraft/pull/1810>
<elopio> snappy-m-o autopkgtest 1807 xenial:armhf
<snappy-m-o> elopio: I've just triggered your test.
<mup> PR snapcraft#1811 opened: Add type hints for some modules <Created by m4sk1n> <https://github.com/snapcore/snapcraft/pull/1811>
#snappy 2017-12-17
<mup> PR snapcraft#1812 opened: Add typings to some modules <Created by IvanFon> <https://github.com/snapcore/snapcraft/pull/1812>
<mup> PR snapcraft#1813 opened: tests: add more unit tests for formatting_utils <Created by konrad11901> <https://github.com/snapcore/snapcraft/pull/1813>
#snappy 2018-12-10
<mborzecki> morning
<mup> PR snapd#6274 closed: cmd, dirs, interfaces/apparmor: update distro identification to support ID="archlinux" (2.36) <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6274>
<mup> PR snapd#6277 opened: centos: enable SELinux support on CentOS 7 (2.36) <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6277>
<pstolowski> morning!
<mborzecki> pstolowski: hey
<mborzecki> mvo: welcome back!
<mvo> hey pstolowski and mborzecki ! thanks, glad to be back :)
<mup> PR snapd#6272 closed: overlord/snapstate: run 'remove' hook before 'auto-disconnect' <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6272>
<pstolowski> hey mvo o/, not resting today after travel?
<mvo> pstolowski: I pushed that to the end of the week, I feel I need to take care of things first and see what happend while we were away and all that
<mvo> zyga: also good morning to you :)
<zyga> Good morning :-)
<jamesh> mvo: hi.  I tried pushing an update to test-snapd-dbus-service last week that seems to have got stuck.  Launchpad built it okay, but it never published.  Is it waiting for "request manual review" by any chance?
<zyga> mvo: how are you feeling? I though you planned on taking a swap day today
<mborzecki> zyga: hey
<zyga> o/
<mvo> jamesh: good morning (evening in your case I guess) - let me check what is going on there
<mvo> zyga: I feel better, I will swap end-of-week-ish I want to see what I missed and if there is anything I can help unblocking today
<jamesh> mvo: by the way, your original PR was very helpful in putting together mine
<mvo> jamesh: \o/ happy to hear that
<mvo> jamesh: thanks for working on this feature!
<jamesh> mvo: although I've been running into some problems with my current design for activating system services not through systemd units
<zyga> what kind of problems?
<jamesh> zyga: when doing non-systemd activation, the dbus-daemon-launch-helper program is spawned to start the daemon
<jamesh> zyga: it uses a simplified version of the config file parser that ignores the <include> directive.  That means it doesn't know about the extra servicedir I configure
<jamesh> everything works fine for session services and systemd activated services (both system and session)
<jamesh> in particular, this is a problem for 14.04 where we can't do systemd activated system services
<mvo> jamesh: can you give me the url to the snap that was build but is not published please? I will investigate, I don't see anything in the need-review queue right now
<jamesh> mvo: the builds were done with this recipe: https://launchpad.net/~mvo/+snap/test-snapd-dbus-service
<jamesh> which says it should publish to edge
<mvo> jamesh: thank you
<jamesh> zyga: one option would be to refactor the branch to comingle the service files in /usr/share/dbus-1/system-services with the rest of the ones from the system -- that might be a bit messier on core systems though
<zyga> mborzecki: shall we merge https://github.com/snapcore/snapd/pull/6111 ?
<zyga> neal didn't comment further
<mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<zyga> mvo: proposal, could we do a 2.36.3 or 2.37 end of this week
<mborzecki> zyga: works for me, you can try and ping him one last time today
<zyga> it could go to non-stable snap channel and non-ubuntu distributions
<zyga> mborzecki: I'm really happy to iterate on top, just not feel like postpoing helps
<mborzecki> zyga: ok, so let's land it
<mborzecki> zyga: maybe ask pstolowski to take a look too
<zyga> that works :)
<zyga> pstolowski: would you mind having a look at the PR above, last one before landing, it refactors the build system around opensuse
<zyga> and adds a shared element that can be easily reused for arch and fedora
<mvo> jamesh: might be something silly like a expired macaroon that prevents the published, the last upload of this snap was >1y ago. anyway, I re-authed and triggered a new build that should do an upload then
<pstolowski> zyga: sure
<mvo> jamesh: I keep you updated
<mvo> zyga: yeah, 2.37++
<mvo> zyga: thanks for raising it
<zyga> mvo: it would be lower risk
<mvo> zyga: unless master is for some reason unfit for this
<zyga> since not stable
<zyga> mvo: yeah
<zyga> mvo: but we could get some casual testing over xmas period
<zyga> mvo: and a better feel of what 2.37.1 might look like
<jamesh> mvo: awesome.  I've been running spread tests locally modified to use a local copy of the package, but that's only covering a couple of distros.  It'll be good to see results on the others.
<mvo> zyga: yeah, having 2.37 in candidate for christmas would be great
<mvo> jamesh: yeah
<mvo> jamesh: you can always mail/tg me btw in such case, I was at a sprint last week so couldn't be on irc
<jamesh> mvo: do you know how important 14.04 compatibility is for new features?
<zyga> (on topic): mvo we should ask JamieBennett  or other stakeholders if 14.04 support extends over the extended paid support period
<mvo> jamesh: "Store upload failed:
<mvo>     Cannot upload new revisions for name=test-snapd-dbus-service
<mvo> " (<- not very helpful, I will ask in the store channel)
<mvo> jamesh: 14.04 we still need to support until it is EOL if we want support certain desktopish things that is unfortunate but not too terrible, our 14.04 work was always more server/cloud oriented
<mvo> zyga: yeah, we were talking about ESM for snapd
<jamesh> mvo: on the desktop side, my branch is fine.  However I thought it would be worth generalising it to system services too, and that's where the problems are
<jamesh> so that's something that might be interesting to server/cloud
<mvo> zyga: its not clear yet, I am personally not a huge fan because of the support burden (I think if we do it we need another push at systemd and update it to at least 205 there). I think it comes down to how many esm users are interessted in snaps
<mvo> jamesh: oh, ok
<zyga> mvo: I'm in agreement
<mvo> jamesh: thats interessting, what is 14.04 missing here? is systemd too old or something else?
<jamesh> but at the same time it is a new feature: it's not going to break any existing snaps
<mvo> jamesh: thats good
<jamesh> mvo: as my branch is currently designed, services directly activated by the system bus fail due to not being able to find the .service files
<jamesh> mvo: on 14.04 systems, this means "all system services"
<jamesh> on other distros where the system bus is launched by systemd, we could just tell people to make the service a daemon and be done with it
<mvo> jamesh: aha, I see. so on 14.04 it is a fundamental problem because the system dbus is launched via upstart?
<jamesh> mvo: yes.
 * mvo nods
<jamesh> mvo: the other option is to refactor the branch to put service files in /usr/share/dbus-1
<jamesh> that means we can't assume the directory is entirely under our control
<jamesh> and I'm not sure whether that's desirable on an ubuntu core system
<mvo> jamesh: yeah, /usr is not writable on ubuntu-core systems
<mvo> jamesh: does dbus look at any other dirs for this? /etc or /run ?
<jamesh> mvo: the man page seems to indicate <standard_system_servicedirs/> will include /usr/local/share/dbus-1/system-services and /lib/dbus-1/system-services too
<jamesh> although both of those could contain other files
<mvo> jamesh: the other files I'm less concerned about but all of those will be read-only on core :/
<jamesh> mvo: my current approach was to configure an extra <servicedir> through a config file in /usr/share/dbus-1/system.d, but the simplified config parser dbus-daemon-launch-helper uses ignores the include directive so doesn't see it
<jamesh> mvo: we're fine for systemd activated services because they don't use launch-helper
<mborzecki> anyone up for a 2nd review on https://github.com/snapcore/snapd/pull/6277 ? it's a backport to 2.36
<mup> PR #6277: centos: enable SELinux support on CentOS 7 (2.36) <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6277>
<zyga> perhaps mvo?
<zyga> since it's a stable backport
<mborzecki> mvo: ^^ pretty please
<mvo> jamesh: aha, I see. hm, I need to look at the PR I think, I don't have enough state loaded right now about the details
<mvo> zyga: yeah, will do, let me open it
<mvo> jamesh: i386/amd64 of the snap should be available now
<jamesh> mvo: thanks.
<mup> PR snapd#6277 closed: centos: enable SELinux support on CentOS 7 (2.36) <SELinux> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6277>
<Chipaca> moin moin moin
<zyga> hello sir
<Chipaca> how tings?
<zyga> splendid
<Chipaca> woo!
 * Chipaca runs to the bank with that
<mvo> hey Chipaca ! great to "see" you :)
<Chipaca> mvo: I'd say the same, except you shouldn't be here :-)
<mvo> Chipaca: nah, its fine, I will bugger off at the end of this week instead :)
<zyga> Chipaca: idea, on a small terminal, snap list doesn't show revision and doesn't wrap
<zyga> revision is really least useful part we show
<Chipaca> zyga: I had adaptive output for things and it got -1'ed
<zyga> boooo
<zyga> I'm making a quick PR to look at
<zyga> very dumb
<zyga> but maybe enough :)
<Chipaca> zyga: I tried to write it up in the forum, to explore finding a way out of it
<cachio> mvo, hey
<mvo> cachio: hey, great to see you - how are things?
<cachio> 2.36.2 is ready to stable
<mvo> cachio: \o/ if all is green and the store is happy I would say: lets do it :)
<mvo> cachio: did we get some feedback from the desktop team, did they had a chance to try it as well?
<cachio> mvo, nice, I'll ping store people
<mvo> cachio: I know we got some +1 from advocay
<mup> PR snapd#6278 opened: cmd/snap: modularize snap list processing <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6278>
<cachio> mvo, I didn't get any feedback
<mvo> cachio: ok, thanks, should be fine, they should run beta anyway :)
<mvo> zyga: do you think you could look at 5845 again? iirc I addressed a lot (most?) of your comments
<cachio> mvo, I was trying to reproduce the error installing the failing.snap in the failover test
<cachio> mvo, https://paste.ubuntu.com/p/RF3SSzgNG8/
<cachio> mvo, it is failing and the test exits
<mvo> cachio: thanks, looking
<cachio> mvo, no extra info, then the system reboots
<mvo> cachio: hm, this is interessting: "Dec 08 23:42:33 dec082230-921432 snapd[1773]: daemon.go:670: Waiting for system reboot" and then "Dec 08 23:45:07 dec082230-921432 systemd[1]: snapd.service: Watchdog timeout (limit 5min)!"
<mvo> cachio: what is the name of the test again? and does it always fail or is this sometihng new?
<cachio> failover
<cachio> mvo, it was failing since some weeks
<cachio> sporadically
<mup> PR snapd#6279 opened: interfaces: tweak deny-auto-connect policy tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/6279>
<cachio> mvo, 2.36.2 is stable
<cachio> running smoke test now
<pstolowski> mvo: hey, will you find some time for review 1 or 2 of my hotplug PRs?
<mvo> pstolowski: I hope so
<mvo> pstolowski: there is some more going on (some core18 work and prepareing 2.37) but I will put this on my list
<pstolowski> mvo: thanks
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37
<zyga> brb
<pstolowski> mvo: fyi, it's #6100 and #6114
<mup> PR #6100: overlord/ifacestate: hotplug-remove-slot task handler <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6100>
<mup> PR #6114: overlord/ifacestate: handler for hotplug-disconnect task <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6114>
<zyga> mvo: https://github.com/snapcore/snapd/pull/6279/files is broken
<mup> PR #6279: interfaces: tweak deny-auto-connect policy tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/6279>
<mvo> zyga: uh, sorry, looking
<zyga> does it pass for you locally
<zyga> unit tests
<Wimpress> mvo Chipaca We had an adhoc update from zyga last week about the status of the fontconfg cache fixes. What is the ETA for that landing in stable?
<mvo> zyga: silly me, I will fix the issue
<mvo> Wimpress: all validations are done and core is ready, cachio  will do the release once he gets green light from the store
<cachio> mvo, I already did the release
<mvo> cachio: \o/
<mvo> Wimpress: ^- here is your answer :)
<popey> did 2.36.2 *just* hit stable?
<cachio> popey, yes
<popey> ok, I was confused. just updated and looked at wikipedia which said it was released last week
<zyga> mvo: ah, FYI we learned that the fixes don't work on fedora
<zyga> mvo: mborzecki has the details
<cachio> 12:48, 29 November 2018â Herakleitoszefesu (talk | contribs)â m . . (6,865 bytes) +316â . . (Version 2.36.2; infobox formatting improvement) (undo | thank) Tag: 2017 wikitext editor
<cachio> popey, I updated the release 2.36.1, then on 11/29 there was another update
<popey> \o/ I love me some fresh updates
<cachio> popey, I don't know who did it
<popey> I usually do, glad someone else is :)
<mvo> zyga: uh, that is sad
<mvo> mborzecki: can you fill me in with the details what is missing on fedora?
<zyga> mvo: fedora has cache in /usr/share/something
<zyga> but I'll let you draw your own conclusions
<mborzecki> mvo: aah yes, fedora has fc cache in different location, /usr/lib/fontconfig/cache iirc
<mvo> mborzecki: woah, that is a strange location for a cache. very unfortunate as well :(
<mborzecki> mvo: heh :P
<zyga> mvo: note that the impact on strict and classic snaps is different
<zyga> and some classic snaps also differ in impact
<zyga> depending on how they are made
<mborzecki> mvo: yeah, it's unfortunate, afaik it's only fedora (and rhel probably), arch uses /var/cache, zyga can tell something aboue opensuse, but iirc it's /var/cache too
<zyga> tnere
<zyga> there's no /usr/lib/fontconfig on opensuse for sure
<zyga> pstolowski: replied to your questions on opensuse PR
<pstolowski> thx
<zyga> pstolowski: with the binary options we can also estimate the number of configurations that we need to support
<mvo> zyga, mborzecki: I wonder what we can do, could we play tricks in snap-confine  ? i guess that won't help with clasic confned snaps
<zyga> mvo: my opinion is as follows:
<mvo> zyga, mborzecki or will a relocatable format v7+uuid help?
<zyga> mvo: the issue affects graphical snaps made on top of fedora29 base, our fc cache work doesn't help there
<zyga> mvo: strict snaps based on core and core18 are not affected
<mvo> zyga: aha, good point
<zyga> mvo: but our extra cache may be seen as undesired, we could look at hiding it
<zyga> mvo: the issue also affects some classic snaps
<zyga> mvo: classic snaps that link with host fontconfig will not be affected by negative performance as cache will be populated by the host mechanism, they will also use the right cache, wherever that might may be
<zyga> mvo: we MAY consider a system where where the native package with snapd has the equivalent of your cache mechanism
<zyga> that always links to the native libraries
<zyga> for the purpose of triggering that cache refresh
<zyga> mvo: classic snaps that link to core snap will remain affected
<zyga> mvo: but they will benefit from your mechanism
<zyga> mvo: to make sure we fully improve the situation I would do the following:
<zyga> (some of which are probably optional)
<zyga> mvo: 1) we should run different cache mechanism for classic snaps and different for strict snaps
<zyga> mvo: 2) for classic snaps we should run the host provided cache and the snapd provided cache
<zyga> mvo: 3) the snapd provided cache *should* move to the base snap instead
<zyga> mvo: and we should run the one matching the base snap of the classic snap being operated on
<zyga> mvo: this would fix all the issues
<zyga> mvo: let me know what you think
<mvo> zyga: yeah, that sounds sensible
<mborzecki> zyga: sgtm
<zyga> I especially think 3 is important
<zyga> since it means we can deprecate old cache and grow new ones
<zyga> and solve the hypothetical f29 based apps in the same go
<zyga> I would say that we may make it generic enough that snapd doesn't know it's fonts
<zyga> maybe /meta/hooks/snap-installed
<zyga> and then that does whatever is needed
<zyga> it would be special because base snap hooks may run unconfined
<zyga> but base snaps are privileged already
<zyga> so I think this is reasonable, it is the same mechanism you implemented but associated with the correct entity
<mup> PR snapd#6280 opened: cmd/snap: make 'snap warnings' output yamlish <Created by chipaca> <https://github.com/snapcore/snapd/pull/6280>
<Son_Goku> zyga, I felt like garbage all weekend (and Simon Peter did not help...) but I did manage to look over your yak-shaving PR
<zyga> and?
<zyga> hmm
<zyga> prepare error on opensuse https://www.irccloud.com/pastebin/crnFHL37/
<zyga> some SNAFU
<mup> PR core18#94 closed: hooks: add cloud-init <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/94>
<mborzecki> ehh import cycles
<mborzecki> refactoring selinux package, got a cycle snap -> dirs -> release -> selinux -> osutil -> dirs
<mborzecki> off to pick up the kids
<Son_Goku> zyga, I left feedback
<zyga> thanks, I will chec
<zyga> check*
<Son_Goku> zyga, also, wtf is up with the opensuse golang compiler?
<zyga> no idea
<Son_Goku> isn't -std a normal flag?
<zyga> not broken on opensuse
<zyga> er
<zyga> on tumbleweed
<zyga> at least since I updated this morning
<mup> PR snapcraft#2419 closed: project: state file path change <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2419>
<ackk> hi, I'm having an issue with multipass on xenial: https://paste.ubuntu.com/p/7HrZTvBh3k/
<ackk> it mentions incompatible openssl version
<sergiusens> ackk: I pinged someone who can help you with that
<sergiusens> mvo: we need to discuss the `.snapcraft` thing. Can you add the reasons for needing it to https://bugs.launchpad.net/snapcraft/+bug/1805219 ?
<mup> Bug #1805219: .snapcraft <19.04> <19.04-external> <Snapcraft:Triaged> <https://launchpad.net/bugs/1805219>
<sergiusens> mvo: I think I want to go with `snapcraft.yaml` at the root of the project and allowing a `.snapcraft` as the root for assets likes hooks, gui and such
<ackk> sergiusens, thanks
<Saviq> ackk: hey, while our snap is confined "classic" we might stumble upon such problems, but we're moving towards strict confinement very soon so those should go away
<ackk> Saviq, does multipass currently only work on bionic?
<ackk> (this is a xenial host)
<Saviq> ackk: in any case, it should work on xenial, can you please file an issue here https://github.com/CanonicalLtd/multipass/issues/new and we'll try and fix asap
<ackk> Saviq, https://github.com/CanonicalLtd/multipass/issues/518
<Saviq> ackk: thank you!
<ackk> Saviq, np
<mvo> sergiusens: in a meeting, I opened the bug and have a look
<dot-tobias> Hi alan_g , short question concerning mir-Kiosk: Iâm running the chromium-mir-Kiosk snap on mir-Kiosk. After mir-Kiosk gets refreshed, the browser snap does not get restarted automatically. This leaves my device (meant to be always-on) with a black screen until I manually restart the chromium snap. Is this a problem specific to the chromium snap (Xwayland) or in general? And can I do something abo
<dot-tobias> ut it? Thanks!
 * zyga -> quick context switch for taxes and dinner
<ackk> Saviq, does multipass currently pick proxy options from the hosts' /etc/environment ?
<ackk> Saviq, from the log I see it can't access cdimage.ubuntu.com, and this host has a proxy set
<Saviq> ackk: it's a systemd service, so no, it doesn't see that environment, you have to `snap set multipass proxy.http â¦` and similarly for https
<ackk> Saviq, ah I see, thanks
<alan_g> dot-tobias, I'd imagine that's a problem with the chromium-mir-kiosk example. You do realise that's an example to work from, not a stable, supported snap?
<ackk> Saviq, ah, so setting the proxy the daemon runs, but those opensssl errors are stil three
<Saviq> ackk: yeah it won't be able to access any https resources most likely
<ackk> Saviq, fwiw I have the same errors on my cosmic machine
<dot-tobias> alan_g : Yes, I read that in the Ubuntu forums. Sorry to keep pestering you about that, itâs just I do not have a lot of understanding about the graphics stack and thus not the faintest idea where to start improving / integrating this into my snap â¦ and regarding my question today, wanted to make sure itâs not a known issue with mir-Kiosk before I start sinking hours into debugging the chromium sn
<dot-tobias> ap ð again, sorry to keep bothering you.
<ackk> Saviq, multipass seems to be working though
<Saviq> ackk: as long as it (multipass itself) doesn't need to access any https resources, it should work indeed
<mup> PR snapd#6281 opened: interfaces/builtin: add Multipass interfaces <Created by gerboland> <https://github.com/snapcore/snapd/pull/6281>
 * Chipaca loves that unplugging the headset now disables the trackpad
 * Chipaca does not actually love it
 * Chipaca needs to reboot
<cachio> mvo, hey, is it any way to set the StartLimitInterval for a snap service?
<okamis> Hello, I installed slack and ran it as root by mistake, how do I purge the configuration files?
<Saviq> okamis: /root/snap/slack should be everything it saved
<Saviq> or, if ran through sudo, it might be /home/your_user/snap/slack - sudo doesn't change $HOME normally
<cachio> mborzecki, do you kbiw if it is any way to set the StartLimitInterval for a snap service?
<Saviq> cachio: not according to https://docs.snapcraft.io/snapcraft-app-and-service-metadata/8335
<mvo> cachio: I think not :/
<mborzecki> cachio: afaik there's no way currently
<cachio> mvo, ok, so I need to make it manually
<cachio> mvo, i SEE https://paste.ubuntu.com/p/NdFRpYHHzP/
<cachio> on boards
<cachio> at least on pi3
<mvo> cachio: what does journalctl -u  test-snapd-daemon-notify.notify say?
<mborzecki> cachio: the service shouldn't fail, provided the interface is connected at this stage
<cachio> mvo, I am executing it again
<cachio> mborzecki, not sure if when it fails the interface is connected
<cachio> because part of this test is with the interface diconnected
<mup> PR snapcraft#2422 closed: clean: user friendly message when cleaning <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2422>
<mborzecki> cachio: yup, there should be an echo before, or maybe extend debug to show snap interfaces?
<cachio> when the test fails the interface is disconnected
<cachio> I already check that
<cachio> mborzecki, could that be affecting?
<sergiusens> joc: hey, what does this mean? https://www.irccloud.com/pastebin/Nh31ajqw/
<mborzecki> cachio: maybe, do you have a log from spread?
<cachio> I have a debug session here
<cachio> mborzecki, I just created it
<cachio> mborzecki, what info could help?
<cachio> mborzecki, this is the spread log
<cachio> https://paste.ubuntu.com/p/dq7JgX7RmF/
<cachio> mvo, external:ubuntu-core-16-arm-32 .../tests/main/interfaces-daemon-notify#  journalctl -u  test-snapd-daemon-notify.notify
<cachio> -- No entries --
<cachio> mvo, this could help
<cachio> https://paste.ubuntu.com/p/CcmqqPsx34/
<cachio> mvo, this shows the start-limit-hit
<Chipaca> cachio: if a test is breaking a service and such, and it doesn't do reset-failed, it'll sometimes not start
<Chipaca> not sure if that's what you're seeing though
<Chipaca> cachio: but that's what i had to do with the nfs-support test
<cachio> Chipaca, the test is disconnecting the interface and trying to start the service
<cachio> and checking the log contains denials
<cachio> but those denials don't appear so the test fail
<cachio> Chipaca, and the problem is that we are hitting the start limit
<Chipaca> cachio: right
<cachio> and it is just happenning on core for arm
<cachio> Chipaca, what do you mean with "breaking a service"?
<Chipaca> cachio: what's stopping the service, in this case?
<mborzecki> cachio: about that fedora 29 bug, i think we'll have to remote the kernels manually
<cachio> mborzecki, ok
<cachio> I'll do that
<mborzecki> cachio: something like this:  `dnf autoremove -y $(rpm -qa kernel-core | sort -r | tail -1)`
<cachio> Chipaca, the test stops the service
<cachio> disconect -> stop -> loop with start
<cachio> we check that snap logs contains denials
<Chipaca> cachio: but
<Chipaca> cachio: it seems the service is exiting with error after getting the permission denied
<Chipaca> ah
<Chipaca> cachio: the snap is buggy
<Chipaca> cachio: the daemon says it's "simple", but it's not a daemon at all
<cachio> Chipaca, this is the snap.yaml https://paste.ubuntu.com/p/NxtnkdYVjy/
<Chipaca> yes i'm looking at it here
<cachio> Chipaca, why it is not a daemon?
<Chipaca> it says "daemon: simple"
<Chipaca> cachio: because it just runs a command and exits?
<cachio> Chipaca, ahh, ok
<Chipaca> cachio: and
<Chipaca> cachio: a shell script exits with the exit status of the last command it executed
<Chipaca> cachio: which means that this thing exits with error
<Chipaca> so systemd tries to restart it a few times, and then gives up
<Chipaca> so the test is a race between systemd restating the thing, and spread running the test
<Chipaca> cachio: easiest fix, probably, is to add a "true" after the systemd-notify call in the script :-), and (optionally? but probably best) set "daemon: oneshot"
<cachio> Chipaca, so we should make sure we exit 0
<cachio> I'll try with oneshot
<Chipaca> k
<cachio> Chipaca, thanks
<Chipaca> cachio: let me know how it goes
<cachio> Chipaca, one shot does not work
<cachio> I think I made it work
<cachio> oneshot fails to start
<cachio> because the interface is not connected
<cachio> so it exits with status 1
<Chipaca> cachio: you made the script not exit with error first?
<cachio> Chipaca, no
<Chipaca> cachio: you did the optional thing, and not the non-optional thing
<Chipaca> :-)
<cachio> I just installed and connected to the interface
<cachio> together
<cachio> because between the snap is installed in prepare and the interface is connected during the execution
<cachio> systemd is retrying the service
<cachio> Chipaca, what do you suggest'
<cachio> ?
<Chipaca> cachio: add an '|| true' to the systemd-notify call, or a 'exit 0' after it or something
<cachio> Chipaca, 0
<cachio> ok
 * Chipaca 1
<cachio> Chipaca, well this also works well
<cachio> I'll create the PR
<roadmr> sergiusens or kyleN : what's the expected Ubuntu version to host snapcraft development? (kind of a trick question - I tried bionic but some of the deps don't exist as noted in the docs, so I went down to xenial) Is it xenial?
<mup> PR snapd#6282 opened: tests: force test-snapd-daemon-notify exit 0 when the interface is not connected <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6282>
<sergiusens> roadmr: it is xenial, given away by the debian/changelog still there and the lack of a base in snapcraft.yaml ð
<roadmr> sergiusens: nice - so how do you guys get black (which requires python 3.6) to run on xenial (which has python 3.5)?
<roadmr> I disabled the black portion of ./runtests.sh for now, am just curious, this is not blocking me or anyting
<sergiusens> roadmr: `snap install black --edge --devmode`
<roadmr> sergiusens: ah, perfect :) thanks!
<roadmr> having two ways to install stuff is confusing. Hopefully soon there'l be only one :D
<sergiusens> I intend to make all our devtools a single snap to bootstrap faster, but haven't gotten around to it yet
<roadmr> sergiusens: it didn't take me a long time to bootstrap in any case, just black was baffling me
<sergiusens> roadmr: yeah, but imagine not needing to ask me which dev environment is the expected one and have a snap with the interpreter, the required dependencies and tools ð
<roadmr> sergiusens: \o/ I like that future heh
<mup> PR snapcraft#2423 opened: Do not use `bash` package name in staging <Created by jdahlin> <https://github.com/snapcore/snapcraft/pull/2423>
<jdahlin> ^ we found some issues related to the `bash` package name already being registered on staging
#snappy 2018-12-11
<mup> PR snapcraft#2423 closed: Do not use `bash` package name in staging <Created by jdahlin> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2423>
<mup> PR snapcraft#2289 closed: local source: only filter out snapcraft artifacts <do-not-merge-yet> <Created by kyrofa> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2289>
<brlin> https://github.com/ubuntu-core/hello-snapcraftio/pull/3
<mup> PR ubuntu-core/hello-snapcraftio#3: Fix I18N <Created by Lin-Buo-Ren> <https://github.com/ubuntu-core/hello-snapcraftio/pull/3>
<mborzecki> morning
<brlin> G. afternoon
<mup> PR snapd#6283 opened: osutil: do not import dirs <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6283>
<mup> PR snapd#6284 opened: spread: make opensuse-42.3 manual <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6284>
<pedronis> mvo: hi,  do you have time for a chat?
<pstolowski> morning
<mvo> pstolowski: good morning
<mvo> pedronis: yeah, in 2min, just poking at the core18 image
<pedronis> mvo: I'm in the standup
<mup> PR snapd#6285 opened: selinux: package to query SELinux status and verify/restore file contexts <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6285>
<mborzecki> pstolowski: mvo: pedronis: morning guys
<zyga> Hello
<pedronis> mborzecki: zyga: hi
<mborzecki> have you seen https://forum.snapcraft.io/t/snap-interface-to-run-smartctl/8929 ?
<zyga> Interesting. I wonder what is the best approach: expose smartctl or provide a replacement that talks to snapd or other trusted helper
<mborzecki> zyga: wonder what's the actual interface used by smartctl and hdparm, i'd say hdparm does ioctls, but smartctl?
<mborzecki> zyga: hdparm: ioctl(3, SG_IO, {interface_id='S', dxfer_direction=SG_DXFER_NONE, cmd_len=16, cmdp="\x85\x06\x20\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x40\xe3\x00", mx_sb_len=32, iovec_count=0, dxfer_len=0, timeout=15000, flags=0, status=0x2, masked_status=0x1, msg_status=0, sb_len_wr=22, sbp="\x72\x01\x00\x1d\x00\x00\x00\x0e\x09\x0c\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x40\x50", host_status=0,
<mborzecki> driver_status=0x8, resid=0, duration=3914, info=SG_INFO_CHECK}) = 0
<Chipaca> some of us wish you all a good morning
<zyga> mborzecki: more ioctls :)
<mborzecki> zyga: same for smartctl ioctl(3, SG_IO, {interface_id='S', dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=16, cmdp="\x85\x08\x0e\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\xec\x00", mx_sb_len=32, iovec_count=0, dxfer_len=512, timeout=60000, flags=0, dxferp="\x40\x00\xff\x3f\x37\xc8\x10\x00\x56\x88\x2a\x02\x3f\x00\x00\x00\x00\x00\x00\x00\x31\x53\x41\x37\x39\x4a\x53\x44\x30\
<zyga> mborzecki: sandboxing ioctls with seccomp is not great
<mborzecki> x36\x35\x34"..., status=0, masked_status=0, msg_status=0, sb_len_wr=0, sbp="", host_status=0, driver_status=0, resid=0, duration=7, info=0}) = 0
<zyga> SG_IO, the rest is in the struct
<mborzecki> Chipaca: morning!
<zyga> mborzecki: I'd vote for a trusted helper
 * Chipaca would vote too, but then zyga might decide not to have the vote at the last minute
<zyga> lol
<zyga> Chipaca: last week I was impressed by the manner the MPs conduct themselves
<zyga> Chipaca: guess this week reminds me all too much of home
<mborzecki> haha
<mborzecki> zyga: i suppose apparmor doesn't do much about ioctls either?
<zyga> I don't think it does
<zyga> apparmor can do only as much as the LSM layer allows
<zyga> and even if, it must be implemented in the kernel
<zyga> and even if, it must be implemented in the userspace
<zyga> a trusted helper looks 10x more workable
<Chipaca> zyga: https://www.youtube.com/watch?v=Tjp5OmoDYQM
<mborzecki> and then it must reach distros
<mborzecki> ehh
<zyga> Chipaca: I saw that, shared that yesterday, brilliant work
<Chipaca> zyga: :-)
<Chipaca> but also, :-/
<Chipaca> too close
<zyga> Chipaca: my "radio" recently is https://parliamentlive.tv/Event/Index/d1114342-3529-43e7-86fa-2263df3271f2
<zyga> Chipaca: at least it means the brits didn't lose their sense of humour :)
<mborzecki> zyga: the struct is in /usr/include/scsi/sg.h insteresting read
<zyga> mborzecki: fun fact, installing golang on fedora pulls in subversion and mercurial
<zyga> what a blast from the past :)
<mborzecki> hahaha
<mborzecki> rich dependencies
<mborzecki> zyga: another fun fact, installing snapd builddeps on fedora pulls in mongodb
<zyga> why on eart?
<zyga> earth?
<mborzecki> zyga: hah, probably because we're pulling in bson
<zyga> oh, right
<zyga> ls
<mborzecki> and the travis job in  https://github.com/snapcore/snapd/pull/6284 failed :/
<mup> PR #6284: spread: make opensuse-42.3 manual <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6284>
<mup> PR snapd#6279 closed: interfaces: tweak deny-auto-connect policy tests <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6279>
<mvo> a review for 5845 would be great
<zyga> doing that now
<Chipaca> zyga: #5845 still has a changes-requested from you on it
<Chipaca> ah ok
 * Chipaca leaves you to it
<mup> PR #5845: interface: add new `{personal,system}-files`  interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/5845>
<pedronis> zyga: I answered/added a couple more comments to the features PR, is there anything we need to discuss on my comments?
<zyga> pedronis: I think I need to take some action now, I'll do that soon
<pedronis> ok, thx
<zyga> thank you!
 * zyga has sudden urge to refactor one bug in interface design
<mborzecki> zyga: left a note under the topic
<zyga> smartctl?
<mborzecki> zyga: yup
<zyga> k
<mborzecki> zyga: btw. https://github.com/snapcore/snapd/pull/6283 iirc you've stumbled upon some issues importing osutil too
<mup> PR #6283: osutil: do not import dirs <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6283>
<zyga> mborzecki: yes, I had an idea when you left a comment yesterday
<zyga> done
<zyga> is master still broken?
<mborzecki> zyga: yeah, i've opened a PR to disable openssue for now, but the travis job failed, couldn't fetch the log and everything is broken :/
<zyga> heh, must be Tuesday
<zyga> thank you
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/6284
<mup> PR #6284: spread: make opensuse-42.3 manual <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6284>
<zyga> mvo: done
<mvo> zyga: thank you!
<pstolowski> mvo: thanks for commenting on that gpio attrs bug, i was (fruitlessly) trying to understand what went wrong...
<pstolowski> mvo: i completly forgot it was limited to beta
<mvo> pstolowski: yeah, the trouble is really that this runs with the broken code so refreshing out of it is hard
<mvo> pstolowski: so lets see if that is good enough for them, if not we need to think harder :)
<zyga> brb, quick coffee
<zyga> mvo: as a "simple" workaround
<zyga> disabling the snap should be enough
<zyga> then you can refresh ok
<zyga> and re-enable it
<mvo> zyga: its the gadget - will that also work?
<zyga> oh,
<zyga> I don't know
<zyga> I didn't anticipate it was the gadget itself
<zyga> one thing one can do is to disconnect that interface
<mvo> zyga: aha, nice idea
<mborzecki> #6284 is green, yay!
<mup> PR #6284: spread: make opensuse-42.3 manual <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6284>
<mvo> zyga: feel free to commment in the bug (if you haven't already)
<zyga> I haven't let me try
<mvo> ta
<zyga> re
<Chipaca> Dec 10 08:44:04 milesdavenport snapd[3255]: error: EOF
<Chipaca> hmmm
<Chipaca> :-)
<zyga> ls
<Chipaca> no such file or directory
<mvo> Chipaca: heh, thats a useful error
<mup> PR snapd#6284 closed: spread: make opensuse-42.3 manual <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6284>
<pedronis> pstolowski: I made some comment in #6180
<mup> PR #6180: snap/info: bind global plugs/slots to implicit hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6180>
<pstolowski> pedronis: ty
<zyga> some progress :)
<mup> PR snapd#6286 opened: release: support probing SELinux state <SELinux> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6286>
<pstolowski> pedronis: wrt to retry vs running tasks problem, i wonder if we shouldn't set task back from Doing to Do status on Retry error with After>0
<pedronis> pstolowski: I haven't looked in the issue at all so far
<pedronis> you'll need to tell me more
<pedronis> but almost lunch here
<pstolowski> pedronis: sure, enjoy, let me know when you're back and we can discuss
<cachio> mvo, hey
<cachio> about the entropy on ubuntu core 18
<cachio> any idea how to deal with this?
<Chipaca> cachio: y u hate mvo
<mvo> cachio: its hard, if you use spread you can use SPREAD_QEMU_GUI=1 in the environment and then type some keys when the qemu window comes up, keystrokes in the terminal are feed to the entropy
<mvo> cachio: there is also a way in qemu to use the entropy of the host, however I don't think spread is exposing this :/
<mvo> cachio: i.e. this would need a spread change
<cachio> mvo, ok, I'll research a bit more
<Chipaca> mvo: cachio: spread looks up kvm in PATH; I have a ~/bin/kvm that adds -smp 4
<Chipaca> so if you know what options to pass kvm for it to pick up the host's entropy, you can do this
<mvo> cachio, Chipaca thanks! please try "-device virtio-rng-pci"
<Chipaca> https://pastebin.ubuntu.com/p/yg69DwrqTM/
<Chipaca> ^ that's my ~/bin/kvm
<Chipaca> but it doesn't need to be this fancy :-)
<Chipaca> mvo: cachio: e.g., https://pastebin.ubuntu.com/p/jfw8GqVNV3/
<mup> PR snapd#6287 opened: httputil: retry on temporary net errors <Created by mvo5> <https://github.com/snapcore/snapd/pull/6287>
<cachio> it is hanging with -device virtio-rng-pci
<cachio> Chipaca, if I don use -nographic
<cachio> I can add manually entropy by moving the mouse and with keystroke
<cachio> s
<cachio> but not sure if it will work the whole run
<mvo> cachio: once it provided it should work
<mborzecki> cachio: try using -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0
<mvo> cachio: I mean, on subsequent reboots it should reuse things
<cachio> mborzecki, running this
<cachio> mborzecki, hanging
<cachio> mvo, trying without -nographic
<cachio> mvo, https://paste.ubuntu.com/p/x96XCC69wv/
<cachio> snapd.seeded.service failed
<mvo> cachio: what is the output of "journalctl -u snapd.seeded.service" ?
<cachio> mvo, https://paste.ubuntu.com/p/MjP8mMWGdB/
<zyga> I have a good grasp of how to implement refreshes during app downtime now
<zyga> need to write down my thoughts
<cachio> mvo, tests already running on core 18
<mvo> sergiusens: the seeded failure is curious, I'm looking at it now
<cachio> I'll let you know the results
<sergiusens> mvo: not related to me I hope ð
<cachio> mvo, wrong sergio I think
<mvo> sergiusens: *cough* sorry
<mvo> cachio: yeah
<cachio> i am gonna create a new vm to see if I can reproduce it
<mvo> cachio: I think I have an idea
<mvo> cachio: about this failure, working on a possible fix
<cachio> mvo, yes same error
<mvo> cachio: slightly strange that we don't see this all the time in our spread runs :/
<cachio> mvo, yes, but the image is not created exactly the same
<cachio> and the hypervisor is not the same as well
<cachio> mvo, this is the snapd log https://paste.ubuntu.com/p/X465Jd8Vbs/
<cachio> I see some errors
<cachio> not sure if they are important
<mvo> cachio: can you give me the matching journalctl -u snapd.seeded.service?
<mvo> cachio: so that I can compare timestamps?
<cachio> https://paste.ubuntu.com/p/R5Hg2DBX4f/
<cachio> mvo, I had both
<mvo> cachio: thanks, looking
<mvo> cachio: I can also get the global journal log please?
<mvo> cachio: it looks like something is killing snapd
<mvo> cachio: and I wonder what
<cachio> sure
<cachio> mvo, https://paste.ubuntu.com/p/QGvrtRSThX/
<cachio> systemctl restart snapd.socket
<cachio> I see this
<cachio> snapd[998]: main.go:147: Exiting on terminated signal.
<cachio> Dec 11 11:59:23 localhost systemd[1]: Stopping Snappy daemon...
<mvo> cachio: so the socket got restarted it seems
<cachio> mvo, yes
<mvo> cachio: thanks! so this is a freshly generated image, right? we did not modified it as part of some test setup except for adding the user to run the tests?
<mvo> cachio: I think I can reproduce this, let me dig some more
<sergiusens> mvo: since you have my attention, may I ask if you had time to look at the .snapcraft bug task I had?
<cachio> mvo, fresh fresh
<cachio> I genereted it with ubuntu-image yesterday
<mvo> sergiusens: yes, I replied there - is there something missing?
<mvo> cachio: I can reproduce now, I take it from here, still not clear yet about the why but it seems to be a bug in the firstboot setup
<sergiusens> mvo: nah, I am just getting started and haven't looked yet but took the opportunity to ask as we started established a link
<cachio> mvo, good, nice to find it now :)
<mvo> cachio: yeah, I wonder if this is new or if we had it in the previous image as well
<cachio> I just tried the stable one and I saw the same error
<cachio> last stable published
<cachio> mvo, so I think it is not new
<cachio> :s
<mvo> cachio: :/ at least we found it now
<mvo> cachio: good, thanks for double checking
<cachio> mvo, np
<cachio> mvo, I'll be afk 15 minutes
<cachio> need to take my son to the kinder garden
<cachio> mvo, tests are running on that image
<mvo> cachio: no worries, I don't need anything at this point, thanks
<mvo> cachio: annoying - its a race, I just tried again and it worked .(
<cachio> mvo, yes, do you what the line I use to start the image?
<cachio> I don't know if that could help
<mvo> cachio: its fine, I can reproduce in ~30% of the runs it seems
<cachio> mvo, nice
<cachio> I'll be bak in 15 minutes
 * cachio afk
<zyga> pedronis: I wrote https://forum.snapcraft.io/t/bug-saves-are-blocked-to-snap-user-data-if-snap-updates-when-it-is-already-running/3226/19?u=zyga - I feel comfortable having a discussion about the feature when you have the time
<zyga> pedronis: I will now resume work on my branches
<zyga> mborzecki: small leftover I didn't notice: https://github.com/snapcore/snapd/pull/6288
<mup> PR #6288: cmd/snap-confine: refactor call to snap-update-ns --user-mounts <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6288>
<mup> PR snapd#6282 closed: tests: force test-snapd-daemon-notify exit 0 when the interface is not connected <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6282>
<mup> PR snapd#6288 opened: cmd/snap-confine: refactor call to snap-update-ns --user-mounts <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6288>
<pedronis> zyga: thx
<zyga> pedronis: I will ask chipaca and jdstrand to review the draft
<pedronis> ok
<sergiusens> mvo: if my reply to that bug is good, then I will implement like that
<mvo> sergiusens: what was the bugnumber again?
<sergiusens> mvo: https://bugs.launchpad.net/snapcraft/+bug/1805219
<mup> Bug #1805219: .snapcraft <19.04> <19.04-external> <Snapcraft:Triaged> <https://launchpad.net/bugs/1805219>
<pedronis> pstolowski: I'm looking at the taskrunner, and I'm not sure I understand how the bug happens actually, running is not based on status, is based on whether there's go routine/tomb
<pstolowski> pedronis: yes i know, i realized that afterwards, but the idea was part of a "bigger" plan to prevent two tasks from ending up in "Doing" state in case of snapd restart. but at end i'm back at square one and no longer sure about proper fix atm tbh
<pstolowski> pedronis: i can explain some more things in a HO
<pedronis> pstolowski: I have a meeting very soon, we can chat after the standup? about this and a bit about hotplug status?
<ackk> Saviq, hi, is there a way to allow a user to use multipass without sudo-ing it?
<pstolowski> pedronis: sure
<pedronis> thx
<zyga> Chipaca: hey
<zyga> do you have 10 minutes to discuss something?
<zyga> mborzecki: replied on https://github.com/snapcore/snapd/pull/6288
<mup> PR #6288: cmd/snap-confine: refactor call to snap-update-ns --user-mounts <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6288>
<Saviq> ackk: we normally use the `sudo` group, so if you add the user to that group (and potentially create that group if not there), it will work
<Saviq> ackk: we're fixing that to try 'adm' https://github.com/CanonicalLtd/multipass/pull/513, too - but ultimately it will be world-writable as security on it will be on a higher level (RPC encryption certificates)
<mup> PR CanonicalLtd/multipass#513: Fix daemon missing group <Created by townsend2010> <https://github.com/CanonicalLtd/multipass/pull/513>
<ackk> Saviq, so if I create a "multipass" group and chgrp'd the unix socket to it that would work for users in that group. right?
<ackk> Saviq, I'm trying not to sudo our jenkins user
<Saviq> ackk: no, "multipass" is not a group we use
<Saviq> ackk: in the current builds, "sudo" is the only group we can do - with the above PR, "adm" will also work
<ackk> Saviq, ah I see
<Saviq> ackk: you could add a post-start command in the multipassd service
<Saviq> to change the owner/mode of the socket
<mborzecki> huh, our centos images have selinux in enforcing mode by default
<mborzecki> off to pick up the kids
<Saviq> ackk: `systemctl edit snap.multipass.multipassd` and add a chown you like https://www.freedesktop.org/software/systemd/man/systemd.service.html#ExecStartPre=
<Saviq> ackk: the socket is /run/multipass_socket
<ackk> Saviq, won't the systemd service be regenerated on snap updates?
<zyga> ackk: not today
<ackk> ah cool
<ackk> Saviq, is it correct that I get an empty file when editing the service?
<mup> PR snapd#6289 opened: cmd/snap-confine: remove SC_NS_MNT_FILE <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6289>
<Saviq> ackk: yes
<Saviq> ackk: systemctl lets you edit an override file
<Saviq> ackk: you can `systemctl cat snap.multipass.multipassd` afterwards to see the results
<mup> PR snapd#6290 opened: cmd/snap-confine: fix typo "a pipe" <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6290>
<ackk> Saviq, ah I see thanks
<Chipaca> zyga: I do have 10 minutes to discuss somehting
<zyga> hey
<zyga> great
<zyga> do you prefer HO or here?
<Chipaca> zyga: here
<zyga> ok
<zyga> I wrote some notes on the forum
<zyga> https://forum.snapcraft.io/t/bug-saves-are-blocked-to-snap-user-data-if-snap-updates-when-it-is-already-running/3226/19?u=zyga
<zyga> could you please read that and tell me when we can discuss
<zyga> I'm interested in your opinion on snap refresh task set design
<zyga> if you think the proposal is sound or if you have better ideas
<Chipaca> ok, let me check, i think i already read it
<jdstrand> mborzecki, zyga: if you're talking about ioctls for smartctl, that is something I need to look into. zyga is right. ioctls are a nightmare to deal with
<zyga> jdstrand: hello
<jdstrand> mborzecki, zyga: or was it btrfs-- that's the other one I need to look at
<zyga> jdstrand: I agree and I don't believe we should attempt to expose the real smartctl
<jdstrand> anyway. nightmare, yes
<zyga> yes
<zyga> nightmare(2) - alias for ioctl(2)
<zyga> jdstrand: I will have a question for you if you have a moment as well
<zyga> jdstrand: not sure if this is the best time
<jdstrand> there is stuff we could do with apparmor. its long, long been on the apparmor roadmap to handle those, but we don't (beyond mediating caps) at this time. the language would probably make it easier to work with as a policy author than what we have now with seccomp, but still would not be great
<jdstrand> zyga: snap restarts? I saw the thread. I haven't read email yet today
<jdstrand> zyga: regardless, ask away
<zyga> jdstrand: I was surprised that snap-seccomp profile compilation is very slow, do you think we should consider introducing caching
<zyga> jdstrand: where snap-seccomp would sort the system calls, discard comments, and use that as cache key
<zyga> (regardless of snap name, so various snaps may end up using the same binary cache)
<zyga> jdstrand: unlike apparmor the cache would be our responsibilty to maintain
<jdstrand> zyga: how slow are we talking?
<jdstrand> zyga: but even without answering that, I think the biggest bang for the buck is only compiling once per set of interface connections. like what I maintain is the best thing to do with apparmor
<zyga> I measured quarter second compilation for nearly every profile on coffee lake i9, interestingly apparmor parser was significantly faster even when a profile was compiled
<zyga> I agree with that, I started some early prototyping but put it on hold now
<jdstrand> zyga: that's a great improvement with or without caching
<zyga> but I'd love to get to that
<zyga> though caching seems like an order of magnitude easier to implement for _some_ improvement
<Chipaca> zyga: how reliable is the release-agent protocol?
<zyga> Chipaca: the protocol is that the kernel clones a userspace task with an argument and... that's that
<zyga> (nothing else happens)
<jdstrand> quarter second is not terrible, but if you have 100 profiles, that's 25 seconds. but, if you have 10 profiles with 10 interfaces (eg a typical desktop app), that is also 100 seconds
<zyga> jdstrand: I believe seccomp is likely to have cache hits
<zyga> since unlike apparmor it has no paths to spoil the cache
<jdstrand> zyga: this isn't an either/or
<Chipaca> zyga: it looks like we'll need a lock, either global or per /run/snapd/runctl/snap.$SNAP_INSTANCE_NAME
<jdstrand> yes, I think caching could benefit
<jdstrand> even would benefit
<zyga> Chipaca: we have locks at every level, can you be specific when you think a lock should be acquired
<Chipaca> zyga: there's one step which is "After populating the freezer cgroup write /run/snapd/runctl/snap.$SNAP_INSTANCE_NAME.running"
<zyga> ah
<zyga> yes, we hold a lock at that phase
<Chipaca> zyga: there's one step which is "if /run/snapd/runctl/snap.$SNAP_INSTANCE_NAME.running is present, postpones the [refresh]"
<zyga> the per-instance lock
<Chipaca> zyga: if the second one is run while the first one is populating the freezer, things might be interesting
<zyga> I see, so you are after looking for the refresh racing
<zyga> that's a good pioint
<zyga> yes, we should grab the lock before manipulating such files
<jdstrand> but if you took that delayed compilation off the back burner onto the front, you should be able to get two birds with one stone (seccomp *and* apparmor) and likely help the common case faster (ie, you could work on caching second). really, for caching I think you want this, otherwise you are going to be maintaining a forest of caches for all the intermediate steps of going from template to 10 interface
<jdstrand> connections
<zyga> jdstrand: I don't disagree about that
<zyga> jdstrand: I would like to work on that after the refresh work
<zyga> likely january
<zyga> jdstrand: I wrote a prototype showing how significant the improvements were
<zyga> jdstrand: I also came to a realisation that we made a mistake in interface design
<jdstrand> the problem with caching is increased complexity. there is an opportunity to load the wrong cache. those would be fun and confusing bugs for people
<zyga> jdstrand: that we can rectify to have cleaner and faster code still
<zyga> jdstrand: yes, though I'm a fan of content-based caches
<zyga> jdstrand: which are easier to work with
<zyga> and it would especially be suitable to reuse that we are likely to see with seccomp
<zyga> jdstrand: as for that mistake in interfaces, I will make a PR if I can today, definitely something in the next few days because it's bugging me more and more, seeing the amount of code we devote to working around it
<jdstrand> zyga: so, the bottom line for me is that I'm not opposed to caching but I'm way more in favor of adding delayed compilation that would help both apparmor and seccomp. I worry that if we add caches, we'll put of the delayed compilation further and further (we've known about this a long time)
<jdstrand> off*
<jdstrand> that's why I'm harping on it. while I believe we'll have bigger overall gains with delayed compilation (which then caching could be added in the fullness of time) that isn't my decision though.
<jdstrand> zyga: while it isn't strictly required for the caching work, one thing that has been on the non-official roadmap is organizing seccomp calls by frequency of use, since that will speed up snaps at runtime
<jdstrand> zyga: if we grouped (even some of) that into this work, we could avoid a potentially painful recompilation flag day down the line
<zyga> jdstrand: right, I'm happy to get the general perf improvements in place at the earliest opportunity
<jdstrand> zyga: eg, open, read, write are all *highly* used, but an alphabetical sorting puts tham after, say, capget
<zyga> (standup time)
<jdstrand> zyga: I don't think this has to be terribly accurate. eg, strace like 10 popular snaps (5 desktop and server/iot) and get some stats and put the top 5 first (sorted to each other), the next top 20 perhaps alphabetically relative to each other and then the rest alphabetical
<jdstrand> zyga: this is within the binary cache, not the src of course
<jdstrand> zyga: something like that. we can fine tune more later, but just something like that would give nice perf gains
<jdstrand> zyga: if you were to do the caching work and incorporate that, I would probably stop harping on delayed compilation
<jdstrand> zyga: well, I won't promise that... I won't do it as much ;)
<jdstrand> zyga: of course, if we are 'good enough' with this (eg, include postgres, nginx/apache, mysql, spotify, chromium, etc) then there may be no point to revisit down the line
<jdstrand> zyga: it would be interesting to profile snap-seccomp to understand where the cost is. perhaps there are gains simply in making the code more efficient
<zyga> yeah, that's true
<zyga> we should measure that
<jdstrand> zyga: overt the years we (and be we I mean jj) have cut apparmor profile times by something like 80%+
<jdstrand> over*
<jdstrand> maybe even more
<mborzecki> cachio: can you rebuild centos images with selinux set to permissive mode?
<cachio> mborzecki, sure
<mborzecki> cachio: thanks!
<cachio> mborzecki, test-centos-1
<cachio> it is ready
<mborzecki> cachio: thanks, checking now
<cachio> mborzecki, should we use this one instead of the current one?
<greyback> @zyga on no seccomp profile for multipass - I'll work on it. But I've a question - is there a way multipassd can create a child process with a different seccomp to itself?
<zyga> greyback: only a subset (more restrictive profile)
<zyga> greyback: my point is that I'd be happier with a really rich profile over a profile that is 100% open
<zyga> greyback: I doubt running kvm requires that much
<zyga> (that is, unbound set)
<greyback> zyga: have we an example of that subset profile anywhere? I'm happy to give it a go
<zyga> I mean
<zyga> you can confine it more than it was before
<zyga> just apply another seccomp profiles as usual
<zyga> they stack in the kernel
<zyga> (all profiles will run, most restrictive outcome is selected)
<greyback> oh ok. This example seccomp for qemu looked pretty big to me: https://github.com/qemu/qemu/blob/cf9dc9e4807464a9d0b3d7368b818323e14921eb/qemu-seccomp.c#L34 but true, it still does limit it
<mborzecki> cachio: the image looks ok to me, can you replace the current one?
<cachio> mborzecki, sure, I'll make a run first
<mborzecki> cachio: ta
<jdstrand> greyback: yes, what zyga said. I suggest comparing the above link to what is in the default template, then add the missing calls to the multipass-support interface. then we can go from there in the PR review
<greyback> jdstrand: ack, thanks
<jdstrand> greyback: btw, do I still owe you an email?
<greyback> jdstrand: nope, I've figured out qn 1 myself and implemented it in that PR. Qn 2, I think I also know the answer (but might run it by you as a sanity check, when the time comes)
<greyback> mostly hoping not to be too security paranoid
<jdstrand> greyback: feel free to run stuff by me, yes. with the holidays and sprints, etc, if I haven't answered you, feel free to ping me :)
<greyback> jdstrand: thanks
<mborzecki> mvo: zyga: funny failure in restoring google:ubuntu-18.04-64:tests/main/degraded https://paste.ubuntu.com/p/ypgPkCp4P6/ probably related to KillMode=process
<mvo> mborzecki: hm, I thought we now do KillMode=process, so fc-cache should survive this now :/
<zyga> mmm
<zyga> yes
<zyga> I have the same feeling]
<mborzecki> mvo: zyga: hm i merged master to this branch earlier today
<ackk> Saviq, is there a way to debug why snapcraft is failing to use multipass? All I get is "launch failed: Connect Failed" but I acn't see why it is failing
<mborzecki> zyga: mvo: and I can see it in the source code
<Saviq> ackk: we're now trying to improve the error messaging around it
<Saviq> ackk: `ls -l /run/multipass_socket`?
<zyga> brb for dinner
<ackk> Saviq, ah, it's back to root:sudo
<ackk> Saviq, I have ExecStartPost=chgrp multipass /run/multipass_socket in the override file but it doesn't seem to be working
<Saviq> ackk: you can check in journal if that command results in an error
<ackk> Saviq, I don't see anything related
<Saviq> ackk: `systemctl status snap.multipass.multipassd` would also show whether it ran that command - maybe it did too early?
<ackk> Saviq, https://paste.ubuntu.com/p/xv5trtZpZX/
<jdstrand> greyback: ok, well, you coaxed an email out of me :)
<Saviq> ackk: might be it ran too early
<Saviq> ackk: http://paste.ubuntu.com/p/hn78NJw7CW/ worked for me
<ackk> Saviq, ok I'll try that
<ackk> thanks
<jdstrand> greyback: it was very cunning how you said you didn't need it and then got me to do it. well played ;)
<jdstrand> greyback: seriously though, hopefully it helps some
<greyback> jdstrand: hah! reverse physchology works ever time :)
<jdstrand> :)
<mup> PR snapcraft#2424 opened: nodejs plugin: fail gracefully when a package.json is missing <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2424>
<ackk> Saviq, sigh, set to sleep 5, group is it still sudo
<Saviq> ackk: did you restart?
<ackk> yes
<Saviq> ackk: if you apply my change verbatim, does it work?
<ackk> (snap restart multipass)
<ackk> Saviq, yes
<Saviq> ackk: then something's wrong with your chgrp
<mup> PR core18#96 opened: run-snapd-from-core: fix race when restarting snapd.socket <Created by mvo5> <https://github.com/snapcore/core18/pull/96>
<ackk> Saviq, https://paste.ubuntu.com/p/gx66QysThT/
<Saviq> ackk: in `systemctl status ...` there's a "Process: â¦" line that says what command was executed for ExecStartPost and its success state
<ackk> Saviq, I don't see that
<mvo> cachio: https://github.com/snapcore/core18/pull/96 <- this fixed it for me
<mup> PR core18#96: run-snapd-from-core: fix race when restarting snapd.socket <Created by mvo5> <https://github.com/snapcore/core18/pull/96>
<mvo> mborzecki: still slightly strange
<ackk> Saviq, ah, foudn the issue. I didn't have the ExecStartPost in a [Service] section
<cachio> nice
<cachio> mborzecki, centos-7 image ready
<cachio> mvo, is it any way to test it?
<cachio> are you creating a new beta core?
 * cachio lunch
<ackk> Saviq, sorry, one more question. how does multipass pick the VM network?
<ackk> (and how do I know which one it is)
<Saviq> ackk: it's a random subnet from the private space, checked for conflicts
<ackk> Saviq, is there a command to get which one it is?
<mvo> cachio: you can "sudo snapcraft" from this branch - this will create a custom core18. then you can run "ubuntu-image ubuntu-core-18-amd64.model --channel=edge --extra-snaps /path/to/core18_....snap"
<mvo> cachio: thats what I did - if it works for you, please comment in the bug
<Saviq> ackk: there's a file in /var/snap/multipass/common - it has "subnet" in its name
<ackk> Saviq, thanks
<ackk> Saviq, ah, so the proxy set in multuipass is not pushed to VMs, is it?
<Saviq> ackk: hmm indeed we're not
<ackk> Saviq, any way I can inject it?
<Saviq> ackk: can you please file an issue in https://github.com/CanonicalLtd/multipass/issues/new
<Saviq> sergiusens: is there a way to pass a cloud-init file to multipass on launch?
<mborzecki> cachio: thanks, i've restarted the affected PRs
<ackk> Saviq, https://github.com/CanonicalLtd/multipass/issues/522
<Saviq> ackk: thanks, the only thing I can think of is if you monkey-patch snapcraft/internal/build_providers/_base_provider.py to include proxy settings
<ackk> Saviq, yeah but I can't do it in the snap, can I?
<Saviq> ackk: right, you can't, TBH I think this is also a snapcraft issue - that's what should ensure that proxy settings are passed into the build environment
<Saviq> like, you shouldn't even need to know multipass is in the mix
<ackk> right. ideally if snapd has a proxy set (or knows of one from /etc/environment) , all snaps should use it without extra needs of configs for each one
<Saviq> yeah probably
<ackk> sergiusens, is there currently a way to do that in snapcraft ? ^ should I file a bug about it?
<sergiusens> ackk: a bug would be fine
 * zyga sees jdstrand typing on the forum and cannot wait to see what's coming 
<mup> PR snapd#6266 closed: tests: make security-device-cgroups-{devmode,jailmode} work on arm devices <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6266>
<mvo> Chipaca: the CLA checker is acting up: https://api.travis-ci.org/v3/job/466575606/log.txt
<mvo> Chipaca: KeyError: 'canonical'
<Chipaca> ?
 * Chipaca looks
<zyga> mvo: I saw that and I wonder if the issue is related to travis-side caching
<zyga> if it asked and never bothered to ask again
<mvo> Chipaca: this is in https://github.com/snapcore/snapd/pull/6252
<mvo> zyga: no worries
<mup> PR #6252: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6252>
<mvo> Chipaca: ideas welcome :)
<Chipaca> mvo: https://launchpad.net/~canonical
<Chipaca> mvo: that's a private team
<pedronis> always has been
<Chipaca> so that check won't work ever
<zyga> ah
<zyga> my bad
<pedronis> how was it working before?
<Chipaca> kenvandine: what have you done :-)
<zyga> I merge the PR adding that feature
<zyga> I understand now, it works if you are a member
<zyga> so works locally for testing
<kenvandine> it passed in CI though
<Chipaca> pedronis: it wasn't: https://github.com/snapcore/snapd/pull/6253
<mup> PR #6253: Members of canonical LP group should pass CLA check <Created by kenvandine> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6253>
<kenvandine> i thought it did anyway
 * Chipaca looks
<Chipaca> kenvandine: https://travis-ci.org/snapcore/snapd/jobs/461925801 agrees with you
<Chipaca> strange
<Chipaca> I don't think it should work, with it being private, but now i don't know
<Chipaca> i can confirm it returns a 404 here
<Chipaca> maybe there was a bug or sth
<Chipaca> in any case
<Chipaca> kenvandine: mvo: if this is for 6252, merging master should let it pass
<Chipaca> actually, it should already work
 * Chipaca looks
<mvo> Chipaca: I thought I just did merge master into the PR from ken
 * Chipaca debugs
<ijohnson> do we have a table/webpage somewhere that lists across distros snapd security confinement supported? I.e. Ubuntu supports everything, Arch supports apparmor, Debian doesn't support apparmor, XYZ supports seccomp, etc.?
<zyga> ijohnson: we have snap debug sandbox-features
<zyga> we don't have what you are asking for but I can tell you that only the ubuntu kernel has all the apparmor features
<zyga> we're close but not there yet
<ijohnson> ok, so is the story still basically "only ubuntu (classic and core)" support _all_ security confinement features?
<mup> PR snapd#6290 closed: cmd/snap-confine: fix typo "a pipe" <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6290>
<zyga> ijohnson: correct
<ijohnson> zyga: ack, thanks
<zyga> jdstrand: apologies for the edited responses, the UX on the forum is not great for some of those interactions.
<zyga> I'm still editing the post to complete my replies
<zyga> jdstrand: some of your response has broken formatting
 * Chipaca takes a break
<mup> PR snapd#6291 opened: Revert "Members of canonical LP group should pass CLA check" <Created by chipaca> <https://github.com/snapcore/snapd/pull/6291>
<zyga> jdstrand: I believe I've answered your questions now, I will go and amend the post fix the inaccuracy with regards to refresh-pending hook and refresh-pending attribute
<Chipaca> mvo: i know why the cla check is failing; i need to fix it
<Chipaca> but first i need to take a break, will bbl
<cachio> mvo, at least firt attempt I could not reproduce it
<zyga> jdstrand: done, thank you for contributing to that thread
<zyga> jdstrand: note that this will be an experimental feature and it will not be on by default when first shipping
<zyga> jdstrand: we may even consider enabling it per-snap
<mup> PR snapd#6283 closed: osutil: do not import dirs <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6283>
<cachio> with the image which I build on edge I dont have lack of entropy
<cachio> mvo, ~
<zyga> Chipaca: small go test woe with locale and snapshots https://www.irccloud.com/pastebin/GPrTt5Sg/
<zyga> pedronis: pushed some changes to 6190
<zyga> I'll push some more tests but I think this is capturing most of what was discussed now
<pedronis> zyga: will probably look at it later today or early tomorrow
<mvo> cachio: oh, interessting - I wonder if the kernel fixes this
<zyga> super, thank you
<mvo> cachio: did you had a chance to test my core18 fix?
 * pedronis breaks for dinner but will work a bit more after
<blackboxsw> Saviq: sorry for the response out of left field it it's not helpful, but multipass accepts cloud-init #cloud-config per something like Josh Powers wrote up https://powersj.github.io/post/cloud-init-multipass/
<blackboxsw> ^ if needed
 * blackboxsw highlights on cloud-init :/
<Saviq> blackboxsw: yeah, I know, we wrote it ;)
<Saviq> the question is whether snapcraft allows passing it through to multipass, which it doesn't
<blackboxsw> heh :/ sorry reading out of context  without the coffee to start up my brain
<mvo> cachio: aha, thanks - I see you commented in the PR
<mup> PR core18#96 closed: run-snapd-from-core: fix race when restarting snapd.socket <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/96>
<mvo> cachio: I triggered a new core18 build
<mvo> cachio: so soon we should have a new core18 snap in beta
<cwayne> plars: ^ ready for some core18 runs? :)
<plars> cwayne: definitely - our core18 runs are all happening on remote with dragonboard, rpi3, and cm3
<cwayne> :D
<cwayne> The rpi3 b right
<cwayne> i.e. not +
<plars> cwayne: I think so - it's the one you brought, which I believe was a regular b
<plars> v1.2 or 1.3 probably
<cwayne> Cool beans
<cachio> mvo, nice
<mvo> cwayne, plars \o/ thanks!
<Chipaca> mvo: kenvandine wrt #6252 I fuxed a pish
<mup> PR #6252: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6252>
<Chipaca> but at some point we might need to add a whitelist feature
<Chipaca> or, maybe, add creds so the cla check isn't anonymous
<mvo> Chipaca: \o/
<Chipaca> it works for ken because he's already got things on master (just, not in the last 50 commits)
<kyrofa> zyga, jdstrand how does confinement affect connection to abstract unix sockets? If you have the network plug, can you connect to any?
<jdstrand> kyrofa: af_unix is mediated, yes. abstract sockets need to match a certain path
<jdstrand> kyrofa: by default, snaps are allowed to use a snap-specific abstract socket: @snap.@{SNAP_INSTANCE_NAME}.**
<jdstrand> kyrofa: beyond that, it is interface specifc (look for 'unix' in interfaces/builtin/*.go
<jdstrand> )
<Chipaca> jdstrand: this reminds me that in deeplin (a debian derivative) confined x11 apps don't work
<Chipaca> jdstrand: the socket there is different but i don't know enough to know why/how/wat
<Chipaca> jdstrand: Deepin*
<jdstrand> Chipaca: it is probably a named socket in /tmp
<jdstrand> Chipaca: as opposed to an abstract socket. therefore the mount namespace is the issue
<jdstrand> Chipaca: I'm guessing
<Chipaca> jdstrand: i need to go make dinner, etc
<Chipaca> jdstrand: but i've got a deepin image i can test with later, if you have the time to handhold :-)
<Chipaca> otherwise i'll just do the old "here's a nickel, kid" thing
<jdstrand> Chipaca: well, there is either an apparmor denial  if deepin supports strict mode snaps, or the mount namespace is getting in the way
<jdstrand> but feel free to circle back
<Chipaca> ok
<Chipaca> i wonder if you can bind mount sockets
<Chipaca> :-)
 * Chipaca runs off to make dinner
<jdstrand> Chipaca: you can
<kyrofa> jdstrand, ah ha, very good thanks
<kyrofa> jdstrand, so for snaps to connect to another snap's socket, it can't be abstract
<kyrofa> And then content sharing can be used
<jdstrand> kyrofa: or an interface can be created for the slot side
<jdstrand> kyrofa: there are plenty of examples of slot side abstract sockets in the interfaces. with a named socket, it is (currently) just grouped in with file rules, so the content interface works there
<jdstrand> (there are also plenty of examples of slot policy for named sockets in the interfaces too, but I digress)
<kyrofa> Ah interesting, okay
<mup> PR snapd#6291 closed: Revert "Members of canonical LP group should pass CLA check" <Created by chipaca> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6291>
 * pedronis calls it a day
 * zyga returns to see PRs
<zyga> cachio: snap command not found :/ https://www.irccloud.com/pastebin/U9QtFWAV/
#snappy 2018-12-12
<brlin> Any chance SNAPCRAFT_BUILD_ENVIRONMENT=lxd get re-implemented in snapcraft?
<mborzecki> morning
<mborzecki> mvo: morning
<mvo> mborzecki: hey, good morning
<mborzecki> mvo: left a comment in your dns retry pr
<mborzecki> i think it's a bit tricky, especially when there are 2 resolves that could run
<mvo> mborzecki: yeah, its nasty
<pstolowski> morning
<mup> PR snapd#6292 opened: spread: record each tests/upgrade job <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6292>
<mborzecki> super simple PR ^^
<mborzecki> pstolowski: hey
<pstolowski> mborzecki: question there
<jamesh> mvo: I got my dbus activation tests working on everything except ubuntu-14.04-64 and ubuntu-core-18-64 now -- I think the ubuntu-core-18-64 failure would be best solved by adding some extra symlinks to the core18 snap
<mvo> jamesh: ok, we can do that - could you add details what is needed into the PR?
<mvo> jamesh: then I can prepare a PR for core18 :) you are welcome of course to do the pr too if you don't mind digging into the (not very complicated) core18 build (github.com/snapcore/core18)
<mborzecki> pstolowski: left a note, we're not running prepare-restore.sh --prepare-suite-each there, idk why, maybe because it'd need some changes internally as it seems to assume snapd is installed
<pstolowski> k
<mborzecki> pstolowski: and i don't want to go into the process of debugging the whole suite now, just need this little piece to figure out why #6270 fails, i belive it's because the upgrade test runs and since it had the old policy /run/snapd is incorrectly labeled, but the test it's not logged  :/
<mup> PR #6270: data/selinux, tests: refactor SELinux policy, add minimal tests <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6270>
<pstolowski> mborzecki: sure, replied
<pedronis> zyga: hi, I did another pass on #6190
<mup> PR #6190: overlord/configstate,features: expose features to snapd tools <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
<zyga> Thank you, looking
<pedronis> mvo: morning, we have a meeting overlapping the standup today :/
<zyga> Iâll add the remaining test and tweak the things you pointed out
<mvo> pedronis: yeah, I noticed as well
<mvo> pedronis: unfortunate
<pedronis> zyga: thx
<mborzecki> need to go out for a bit, back in an hour or so
<pedronis> mvo: can we have a chat (hopefully short) about state of various things in a bit?
<pstolowski> pedronis: hello, updated #6268
<mup> PR #6268: overlord/ifacestate: helpers for serializing hotplug changes <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6268>
<mvo> pedronis: yes, just wrestling with core18 and cloud-init and ordering right now but I think I'm almost done
<pedronis> ok
<pedronis> pstolowski: I'll look
<pedronis> thx
<mup> PR snapd#6209 closed: run-checks: discard test good/bad banner <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6209>
<mup> PR core18#97 opened: hooks: add hook to ensure cloud-config runs in the right order <Created by mvo5> <https://github.com/snapcore/core18/pull/97>
<zyga> master is still broken?
<pedronis> apparently  https://api.travis-ci.org/v3/job/466661285/log.txt
<pedronis> still issues with seeded and core18
<pedronis> mvo: ^
<mvo> pedronis: looking
<mvo> pedronis: this is different from what sergio reported: Dec 11 19:49:27 dec111939-540068 systemd[1]: snapd.seeded.service: Main process exited, code=killed, status=15/TERM
<mup> PR core18#98 opened: hooks: add symlinks for snapd's D-Bus configuration files <Created by jhenstridge> <https://github.com/snapcore/core18/pull/98>
<jamesh> mvo: I think this should fix dbus activation for core18.  I haven't tested it yet though: https://github.com/snapcore/core18/pull/98
<mup> PR core18#98: hooks: add symlinks for snapd's D-Bus configuration files <Created by jhenstridge> <https://github.com/snapcore/core18/pull/98>
<mvo> jamesh: nice, thank you
<pedronis> mvo: this is the degraded test, not sure I know what it does
<pedronis> mvo: maybe you other fix, makes this one flaky?
<mvo> pedronis: yeah, what I mean is that the error looks different, I will poke at it
<mvo> pedronis: could be fallout from the previous change of course :/
<pedronis> mvo: I'm slightly worried about the hacks and counter hacks that seeded as is and the snapd being a snap are creating in core18
<pedronis> seeded = the service
<mvo> pedronis: yeah, I'm unhappy too, what shall we do? I can write up what is happening and we can discuss what the best option is?
<mvo> pedronis: i.e. I write down the details and we have a HO once you had a chance to look at it?
<zyga> Im happy to help as we
<zyga> well
<mvo> zyga: sounds great
<zyga> nothing brings the mood down as the eternal red cross
<pedronis> mvo: also will not the bug about the snapd socket changing affect also other operations, not just the seeded service?
<mvo> pedronis: maybe, this happens very early, I'm writing down the sequence then hopefully things are clearer
<zyga> mborzecki: updated https://github.com/snapcore/snapd/pull/6288
<mup> PR #6288: cmd/snap-confine: refactor call to snap-update-ns --user-mounts <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6288>
<pedronis> pstolowski: done
<pstolowski> thx
<pedronis> thank you
<mvo> pedronis, zyga here is the overview, I will write the problems with snapd.seeding next
<mvo> snapd.seeded
<mvo> pedronis, zyga https://gist.github.com/mvo5/12632c729f07c3b02fa3d0e7383439d5/edit
<zyga> looking
<zyga> mvo: point 5, typo, I think you mean "then snapd exits"
<mvo> zyga: indeed, sorry
<zyga> mvo: point 8, I'm always confused by various systemd features, specifically those that relate to ordering and dependencies, is After the one that says something when starting together, runs after, or is it the one that says that it has a hard dependency on something (here core18.start-snapd) and it will not run unless that other unit is started
<mvo> zyga: its the "start-after", it does not have any dependency implications
<zyga> mvo: question about core81.start-snapd: when does it become ready in sysytemd terms?
<mvo> zyga: i.e. it will happily run if the after=nonexisting
<mvo> zyga: after seeding is done
<zyga> is it using sd-notify?
<mvo> zyga: snap watch --last=seed :)
<mvo> zyga: should I add it to the gist?
<zyga> is it a type oneshot service?
<mvo> zyga: correct
<mvo> zyga: with remainafter=true
<zyga>            Behavior of oneshot is similar to simple; however, it is expected that the process has to exit before systemd starts follow-up units.  RemainAfterExit= is particularly
<zyga>            useful for this type of service. This is the implied default if neither Type= nor ExecStart= are specified.
<zyga> ^ from the man page
<zyga> so that seems all is good
<zyga> thank you mvo
<mvo> zyga: yeah, I'm writing the problematic parts down now, the first part is mostly to give a good understanding how things work
<zyga> thank you for that, it is very useful
<zyga> I would love to have a man page for each unit we have
<zyga> and what you pasted above could live there
<zyga> in that good old unix tradition
<pedronis> mvo: read it, I was not aware of this, it seems problematic in many ways tbh
<pedronis> I mean fully aware of this
<mvo> pedronis: ok, writing down some more, lets talk in a HO then
<pedronis> mvo: I have another meeting in 20 but let's see what we can do
<popey> What's the minimum allowed length of a snap name?
<mvo> pedronis: https://gist.github.com/mvo5/12632c729f07c3b02fa3d0e7383439d5
<mvo> pedronis: I can jump in HO now, we can try to make it quick
<mvo> pedronis: I'm in the standup channel now
<mvo> pedronis: ready when you are
<niemeyer> Heya
<niemeyer> I've created a team for the base snaps (core18 and 16)
<mup> PR core18#97 closed: hooks: add hook to ensure cloud-config runs in the right order <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core18/pull/97>
<niemeyer> So all the right people have access to both
<mborzecki> re
<zyga> thank you niemeyer!
<popey> zyga: do you know if there's code somewhere that constrains the length of a snap?
<zyga> length of what exactly?
<zyga> the file size?
<popey> the snap name
<zyga> ah
<zyga> yes
<zyga> it is limited
<popey> a, aa, aaa
<zyga> in snapcraft, snapd and the store
<popey> what's the limit?
<zyga> let me look
<zyga> AFAIK 40
<popey> thanks
<zyga> but looking
<popey> what's the minimum?
<zyga> 2
<zyga> max is 40 as I said
<zyga> https://github.com/snapcore/snapd/blob/master/snap/validate.go#L94
<zyga> this is the logic in snapd
<popey> is there a reason why 2 was selected?
<zyga> I'm sure there was
<zyga> I think a one character command name is pretty unexpected
<zyga> and would be filled with spam
<popey> "filled" - there's not a lot of single characters available ;)
<popey> around 26 or so in English
<zyga> snapcraft register a
<zyga> ;-)
<zyga> anyway, that's that
<popey> Ok. I am not sure what to do as I have found a project which I have snapped, but it's one letter long
<popey> Am I expected to tell an upstream to rename their project?
<zyga> what's the project name?
<popey> s
<zyga> wow
<zyga> what is it?
<popey> https://github.com/zquestz/s
<popey> open a web search from the command line
<popey> so you'd want it to be short
<zyga> popey: I suggest that you escalate this to niemeyer
<zyga> popey: it could be called the-s
<zyga> with an alias perhaps
<niemeyer> popey: There's a long culture in Debian of fixing upstream names when they are unfit for purpose
<niemeyer> popey: This seems no different
<popey> This seems very different. Part of the selling point of snaps is there's not someone in the middle between them and users.
<niemeyer> I suffered from that myself.. my old school "smart" project, as in Smart Package Manager, wasn't accepted as "smart"
<niemeyer> It was too general
<niemeyer> Ended up as "smartpm" in Debian
<niemeyer> I can't imagine they'd take "s" :)
<popey> Ok
<niemeyer> popey: Our infrastructure is a middle man.. we need to balance the voices of publishers with the voice of users
<niemeyer> and manufacturers etc
<popey> I'll offer a suggestion to them.
<niemeyer> popey: Thanks
<zyga> niemeyer, popey: do you think the alias idea is workable?
<niemeyer> zyga: I don't know to be honest.. it depends a bit more on the context
<mborzecki> zyga: can you take a look at https://github.com/snapcore/snapd/pull/6292 it's your favourite topic :)
<mup> PR #6292: spread: record each tests/upgrade job <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6292>
<zyga> mmm
<zyga> gaaah
<zyga> you want me to look even older
<zyga> the reason for upgrade not using that
<zyga> is that they setup is quite different
 * zyga is sad
<zyga> done
<mborzecki> zyga: heh, i was tracking a problem in one of the selinux prs, and the only explanation was that the upgrade test ran, turn out those weren't logged like the rest
<pedronis> mvo: could you also follow up on that email to foundation you sent, or should I?
<mvo> pedronis: I will do that, thank you
<mvo> pedronis: just finishing my work on the unit, then I will follow up
<pedronis> mvo: thx, also I'm out of the meeting, so we can HO a bit more when you have time
<zyga> mborzecki: upgrade tests are very much distinct
<zyga> mborzecki: I wonder if it would make sense to run them on a speparate pass
<zyga> mborzecki: until we are sure they are not leaving garbage behind
<zyga> or vice versa
<mborzecki> zyga: committed your suggestion
<zyga> thank youu
<mborzecki> zyga: i hope that the PR confirms my suspicions as to why https://github.com/snapcore/snapd/pull/6265 fails
<mup> PR #6265: cmd/snap: attempt to restore SELinux context of snap user directories <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6265>
<mvo> pedronis: I think I found a good solution, will push in a bit and then we can HO again
<pedronis> pstolowski: any new findings on the slow remove bug? are you blocked on hot plug stuff? missing 2nd reviews?
<pedronis> mvo: https://forum.snapcraft.io/t/auto-import-doesnt-work-with-uc18/8960
<pstolowski> pedronis: no news yet, investigating. i need 2nd reviews from mvo, yes
<mvo> pstolowski: sorry!
<pstolowski> pedronis: i'll land hotplug seq soon once travis is green, that one got enough reviews
<mvo> pedronis: uh, not more bugs :(
<pstolowski> mvo: don't be, i know you have lots of more important stuff atm, np
<mvo> pedronis: yeah, the udev auto-import it is, looking at it next
<pedronis> mvo: let's chat first tough
<pedronis> I mean before you start on something next ...
<mup> PR core18#99 opened: static: add snapd.seeded.service to core18 <Created by mvo5> <https://github.com/snapcore/core18/pull/99>
<mvo> pedronis: HO?
<pedronis> yes
<mup> PR core18#100 opened: static: add missing /lib/udev/rules.d/66-snapd-autoimport.rules <Created by mvo5> <https://github.com/snapcore/core18/pull/100>
<mborzecki> zyga: added the renames you suggested
<mborzecki> anyone interested in doing a 2nd review of #6285 ?
<mup> PR #6285: selinux: package to query SELinux status and verify/restore file contexts <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6285>
<zyga> mborzecki: thank you :)
<mborzecki> zyga: can you take a look at the release bits in #6286 too?
<mup> PR #6286: release: support probing SELinux state <SELinux> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6286>
<zyga> emmm
<zyga> sure
<zyga> mborzecki: question about package layout
<zyga> mborzecki: or tree layout perhaps
<zyga> mborzecki: pkg/selinux, pkg/apparmor, pkg/foo
<zyga> instead of top-levels
<zyga> ?
<mborzecki> zyga: hm that discussion would need to involve the whole team probably
<zyga> yes
<mborzecki> zyga: can you bring it up during the standup maybe?
<zyga> today is not the best moment because pedronis will be off
<zyga> and mvo's last day this year
<zyga> but next year sure
<zyga> nothing urgent
<mborzecki> januarny then :) new year resolution
<zyga> mborzecki: +1 with the request to make selinux probe lazy
<zyga> haha, sounds good :)
<zyga> I'd love to shuffle the apparmor package around
<zyga> have one pkg/apparmor
<zyga> and use it from release and interfaces/apparmor
<zyga> brb
 * pstolowski lunch
<mup> PR core18#100 closed: static: add missing /lib/udev/rules.d/66-snapd-autoimport.rules <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/100>
<zyga> re
<ackk> hi, I'm trying to build a snap in jenkins, when I run "snapcraft --destructive-mode" it fails with no output at all. tried --debug as well, still no output. how can I debug further? if I access the jenkins slave and run the comand as the same user it works
<mup> PR core18#99 closed: static: add snapd.seeded.service to core18 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/99>
<zyga> pedronis: updated https://github.com/snapcore/snapd/pull/6190
<mup> PR #6190: overlord/configstate,features: expose features to snapd tools <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
<zyga> mvo: is this useful for you or can I re-trigger? https://www.irccloud.com/pastebin/WSgr3x1G/
<mvo> zyga: kill it, I think this is understood now, the next core18 should have a fix
<zyga> thank you
<zyga> mborzecki: another small cleanup from my pile https://github.com/snapcore/snapd/pull/6293
<mup> PR #6293: cmd/snap-confine: remove unused sc_discard_preserved_mount_ns <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6293>
<zyga> removing dead code
<zyga> mborzecki: and if you have a sec, this is green too :-) https://github.com/snapcore/snapd/pull/6278
<mup> PR snapd#6293 opened: cmd/snap-confine: remove unused sc_discard_preserved_mount_ns <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6293>
<mup> PR #6278: cmd/snap: modularize snap list processing <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6278>
<zyga> Chipaca: ^ if you ack this I'll feel better asking for it to be merged
<Chipaca> zyga: I looked at that yesterday, I wanted to talk with you about it
<Chipaca> or was it Monday i looked at it
<zyga> sure
<Chipaca> anyway
<Chipaca> zyga: how is that "modularised"?
<zyga> it's easier to make changes without editing those pesky long lines :)"
<Chipaca> zyga: +1 for doing that to the header
<Chipaca> zyga: the rows, I'm not sure it's a win vs what's there
<zyga> Chipaca: or maybe going full in
<zyga> and having a struct column {  name string, value func(...) }
<pedronis> zyga: I +1ed  6190 with a comment, it needs a 2nd review as well
<zyga> pedronis: thank you, I can remove the snap name from that patch set to avoid any controversy and let it move on
<zyga> who do you think should perform the 2nd review?
<pedronis> no strong preference on that
<Chipaca> zyga: as it stands, i'm -1 on that pr, fwiw
<mborzecki> Chipaca: zyga: fwiw i'd prefer to use the template engine there
<Chipaca> zyga: but I'll admit I might be missing the point
<Chipaca> mborzecki: does the template engine handle alignment?
<zyga> Chipaca: if you think that's not the way forward, let's then close it
<mborzecki> idk, needs checking
<zyga> it was a small thing I wanted to explore
<Chipaca> mborzecki: I think it doesn't :-)
<pedronis> mborzecki: we had a PR about that
<zyga> as you know :)
<zyga> but not essential
<pedronis> and it went in circles
<mborzecki> ah
<mborzecki> haha
<pedronis> I have an ongoing discussion with Chipaca about what to do with our output more in general
<pedronis> but next year stuff at this point
<Chipaca> pedronis: which reminds me, was that topic post all you hoped for, or did I miss the point?
<pedronis> Chipaca: it touches the right things, I don't agree 100% with the conclusion, as I just said, I plan to get back to it
<pedronis> is not top priority right now
<pedronis> (because so many things)
<Chipaca> agreed about so-many-things
<pedronis> Chipaca: I tought I mentioned this already with you
<Chipaca> but yeah, not completely happy with it myself
<pedronis> but maybe I didn't
<Chipaca> pedronis: maybe you did, i'm dropping packets myself
<zyga> Chipaca, mborzecki: I need a 2nd review on https://github.com/snapcore/snapd/pull/6190
<mup> PR #6190: overlord/configstate,features: expose features to snapd tools <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
<pedronis> I think Chipaca is off today, no?
<Chipaca> I am
<zyga> Chipaca: oh, sorry then
<Chipaca> no worries
<zyga> Chipaca: what are you doing here dear sir?
<Chipaca> happy to chat
<Chipaca> zyga: chatting with friends?
<Chipaca> but maybe also having lunch
<zyga> Chipaca: btw, watching parliament TV is interesting
<Chipaca> hah, today it might be yes
<zyga> Chipaca: fair enough, I do that myself more often than not :)
<zyga> Chipaca: 8PM is it?
<Chipaca> although they behave like badly-mannered school children
<zyga> I beg to differ, they behave like well taught, kindly speaking, badly mannered school children
<Chipaca> you forgot pompous, pretentious, and pedantic
<Chipaca> and probably other things that start with P
<zyga> "my right and honourable friend the douchebag"
<zyga> ;-)
<zyga> still
<zyga> that sentence is far better than typical time-squandering insults I hear from the benches in our own government
<pedronis> zyga: I closed that PR btw
<mup> PR snapd#6278 closed: cmd/snap: modularize snap list processing <Simple ð> <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6278>
<pedronis> with comment
<zyga> +1
<pedronis> mborzecki: are you exploding and cleaning up6238 in smaller PRs, is that right?
<pedronis> #6238
<mup> PR #6238: [WIP] many: add minimal SELinux support, refactor the policy <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6238>
<mborzecki> pedronis: yes, all the PRs tagged with selinux label are about that
<zyga> some more test woes
<zyga> https://www.irccloud.com/pastebin/z2HoQxdq/
<zyga> https://api.travis-ci.org/v3/job/466903966/log.txt is full of that
<zyga> not sure what to make of this
<zyga> away, I was meaning to take a break for coffee / dog
<zyga> cachio: if you are around, could you have a look?
<cachio> zyga, hey
<cachio> sure
<cachio> zyga, nice error
<zyga> perhaps that's the same issue that mvo is fighting
<zyga> with seeding
<cachio> zyga, is it happening on master?
<zyga> I don't know, I've seen this error today before but perhaps on this branch as well
<mborzecki> i have a feeling that the spread jobs only succeed by acccident, and the default state of things is to fail
<pedronis> pstolowski: I +1ed #6180 with some final comments
<mborzecki> ever seen a failure like this? https://api.travis-ci.org/v3/job/466929872/log.txt
<mup> PR #6180: snap/info: bind global plugs/slots to implicit hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6180>
<cachio> zyga, last error on master for core18 on degraded test is the same than mvo is working I think
<zyga> thank you
<cachio> zyga, snapd.seeded service failed to start
<pstolowski> pedronis: thanks
<cachio> zyga, I'll try to reproduce this one
<pedronis> zyga: the gpio enable/disable fix we did only for 2.37 in the end, right?
<ackk> does anyone run snapcraft in jenkins?
<thresh> ackk, I do for VLC, why
<ackk> it seems snapcraft doesn't handle well non-interactive shells
<ackk> I'm running it on a slave via ssh
<thresh> it does show quite a bit of output
<ackk> I had to snapcraft | cat, otherwise I don't get any output
<ackk> but it seems now the yarn plugin fails, I suspect because it doesnt' use --non-interactive when calling yarn
<thresh> oh?
<thresh> I definitely do not do it :)
<thresh> ah, "Allocate a pseudo-TTY" is checked for that particular docker container I use to build VLC snap in
<thresh> so probably that's hwy
<ackk> mhm I wonder if I can do something like that
<pedronis> mborzecki: did a pass on #6285
<ackk> thresh, do you use a custom image to build with snapcraft in docker?
<thresh> ackk, yeah
<mup> PR #6285: selinux: package to query SELinux status and verify/restore file contexts <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6285>
<mborzecki> pedronis: thanks!
<thresh> ackk, https://code.videolan.org/videolan/docker-images/blob/master/vlc-ubuntu-xenial/Dockerfile and https://code.videolan.org/videolan/docker-images/blob/master/videolan-base-xenial/Dockerfile
<ackk> thresh, ah yeah we can't use docker like that since we're using jenkins-job-builder and you can't really pass a dockerfile that way
<thresh> surely you can pass the image
<thresh> but I doubt vlc's one will be handy
<zyga> Yes pedronis
<pedronis> thx
<pedronis> mvo: have you seen that core18 is also red?
<pedronis> mvo: I mean,  https://github.com/snapcore/core18/commits/master
<pedronis> sorry
<ackk> thresh, yeah we currently have a (container) slave dedicated to it, but because of this issue it's failing to build
<mvo> pedronis: yes :(
<mvo> cachio, degville zyga, mborzecki, pstolowski I can't join the standup today, have a conflicting meeting
<thresh> ackk, do you have templates defined in your docker jenkins plugin?  or it works some other way?
<cachio> mvo, np
<ackk> thresh, no we're not using docker at the moment. but I didn't know you could do that
<ackk> thresh, where we use docker, we have a pipeline with a Dockerfile in the repo, which is used by the corrsponding Jenkinsfile
<thresh> I wouldnt recommend my way :)
<thresh> I'm slowly migrating all that crap to gitlab ci atm
<mup> PR core18#101 opened: static: add missing systemd symlinks <Created by mvo5> <https://github.com/snapcore/core18/pull/101>
 * cachio afk
<mup> PR core18#101 closed: static: add missing systemd symlinks <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core18/pull/101>
<mup> PR snapd#6292 closed: spread: record each tests/upgrade job <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6292>
<mborzecki> zyga: pushed a smarter way of relabeling to https://github.com/snapcore/snapd/pull/6265
<mup> PR #6265: cmd/snap: attempt to restore SELinux context of snap user directories <SELinux> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6265>
<mborzecki> zyga: the relevant changes are in cmd/snap/cmd_run*
<zyga> Ack
 * cachio lunch
<mup> PR snapd#6289 closed: cmd/snap-confine: remove SC_NS_MNT_FILE <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6289>
<zyga> mborzecki: hey
<zyga> mborzecki: quick review request for -55,+0 in 6293
<pstolowski> pedronis: do you have a moment for HO? i've some observations & interesting log about task runner
<ackk> sergiusens, I see that the multipass provider passes user-data.yaml to multipass when building, is there a way to inject cloud-init configs in there?
<kyrofa> noise][, can I use a brand store in classic Ubuntu?
<sergiusens> ackk there is not
<ackk> sergiusens, I see, thanks
<noise][> kyrofa, yes that can be done
<kyrofa> noise][, how?
<noise][> same as with core basically, you need a model
<kyrofa> You can have a model assertion on classic? How is that setup?
<pedronis> pstolowski: was having a break, now back but it's a bit late, we should talk tomorrow morning I suppose
<pstolowski> pedronis: ok, makes sense
<noise][> kyrofa, yes - e.g. do `snap known model` on your classic system. Not sure if we have good docs for setting that up, maybe pedronis would know
<pedronis> you can but is fixed unless you make your own image (which there is no simple tooling for for that case), until we introduce remodeling
<pedronis> and decide what is possible
<kyrofa> Interesting, okay, thanks
<pedronis> pstolowski: I answered your question in 6180
<pstolowski> pedronis: aha!
<pstolowski> thx
<zyga> pedronis: FYI https://github.com/snapcore/snapd/pull/6294 is super special experiment, let's see if it passes
<mup> PR #6294: packaging/ubuntu: build with golang 1.10 <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/6294>
<mup> PR snapd#6294 opened: packaging/ubuntu: build with golang 1.10 <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/6294>
<mup> PR snapcraft#2424 closed: nodejs plugin: fail gracefully when a package.json is missing <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2424>
<pedronis> zyga: are blocked?
<pedronis> *are you blocked?
<zyga> pedronis: no, not at the moment :)
<zyga> pedronis: only by master being flaky
<pedronis> zyga: we just discussed that indeed we want to switch to 1.9 or 1.10
<pedronis> but for 2.38
<pedronis> I mean with mvo
<zyga> pedronis: this is an experiment to see if this could help with core 18 issue that I discussed with mvo
<zyga> to see if there's a long term better way to do something
<mup> PR core18#102 opened: static: run snapd for the first time with systemd-run <Created by mvo5> <https://github.com/snapcore/core18/pull/102>
 * cachio afk
 * zyga afk
<mup> PR core18#102 closed: static: run snapd for the first time with systemd-run <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/102>
<mup> PR snapd#6103 closed: tests: split nested vm suite on core and classic and new snapshots test <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6103>
<mup> PR snapd#6295 opened: systemd: start snapd.autoimport.service in --no-block mode <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6295>
<mup> PR snapd#5714 closed: tests: new test for cifs-mount interface <â Blocked> <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5714>
<cachio> zyga, I was reviewing upgrade test suite and I think it is important to run in every PR
<zyga> cachio: I didn't want to change that
<mup> PR core18#103 opened: static: add missing systemd symlinks <Created by mvo5> <https://github.com/snapcore/core18/pull/103>
<zyga> cachio: I wanted it to run on separate VMs
<zyga> by starting spread with update suite separately
<zyga> mvo: hey
<zyga> back?
<mvo> zyga: yes
<cachio> zyga, ahh, ok, so run that suite first in the vm?
<zyga> cachio: no
<cachio> just run that suite on the vm?
<zyga> really, just spread -v foo:tests/upgrade
<mvo> zyga: I think the open PRs things should be good again, but I'm trying now
<zyga> and spread -v tests:/everything-but-upgrade
<zyga> separate invocations of spread
<zyga> what are the symlinks for mvo?
<zyga> ah
<zyga> wanted!
<zyga> mvo: so we need new snapd release?
<cachio> zyga, ok, so first everything-but-upgrade and then upgrade is ok?
<zyga> cachio: you can even run them in parallel
<zyga> spread foo &
<zyga> spread bar &
<zyga> wait
<mvo> zyga: yes
<cachio> zyga, sorry, I don't see how that helps
<zyga> cachio: it makes it faster
<zyga> cachio: separately invoked spread will not reuse any vms
<pedronis> mvo: I'm working on the retry PR btw
<zyga> and foo and bar above were selectors needed to run the update suite vs other stuff
<cachio> zyga, adding more workers shouldn't help to make that faster?
<zyga> cachio: not really
<zyga> cachio: starting parallel work in parallel will
<mvo> pedronis: \o/
<zyga> cachio: do you understand what I'm trying to achieve?
<cachio> because if we have 1 maniche which has to prepare the suite, build snapd and then run just 2 tests, then the instance spending to much time preparing compare with running tests
<cachio> zyga, not really
<cachio> zyga, well you said "run faster"
<zyga> cachio: running update suite separately will prevent intermixing it with other suites, we have plenty of issues as is so this is a simple low cost solution to avoiding some
<Son_Goku> zyga, what distros do we have left that offer golang < 1.10?
<zyga> cachio: running spread twice will need to wait for the first run to finish before starting the first run
<zyga> cachio: so the suggestion was to run spread foo &; spread bar &; wait;
<zyga> cachio: to start two runs in parallel on two sets of machines
<zyga> cachio: does that make sense?
<zyga> Son_Goku: nothing, this is just about building with newer golang in ubuntu
<cachio> zyga, what will happen with the logging?
<cachio> zyga, it could be very confusing
<zyga> cachio: it will be sent to stdout, you can obviously redirect it and cat both logs in the end
<zyga> cachio: it could also be very sensible :) it depends on how it is done
<zyga> cachio: master being broken because of things we don't understand every day is worse than confusing
<mup> PR core18#104 opened: static: snapd.seeded.service needs the right After= dependency <Created by mvo5> <https://github.com/snapcore/core18/pull/104>
<mvo> zyga: ^- one more trivial one
<zyga> yeah, makes sense
<mvo> ta!
<cachio> zyga, ok, I get the idea but I am not sure running in parallel is the best solution, I'll see if there is another way to force the upgrade suite to run in a separeta vm
<cachio> zyga, perhaps to add a new backend attached to the suite
<cachio> something like
<cachio> spread google: google-upgrade:
<cachio> so we have a single spread run
<cachio> and single spread logs
<cachio> zyga, does it make sense?
<mup> PR snapcraft#2425 opened: snap: re-add pyc files for snapcraft <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2425>
<pedronis> mvo: pushed
<mup> PR core18#104 closed: static: snapd.seeded.service needs the right After= dependency <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/104>
<mvo> cachio: we need one more commit, building now
<cachio> mvo, good
<zyga> cachio: yes it does
<pedronis> #6287 needs 2nd reviews, now it also code by me
<mup> PR #6287: httputil: retry on temporary net errors <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6287>
<zyga> mvo: we need one more patch for 2.36
<pedronis> core18 CI failures look a bit messy:  https://api.travis-ci.org/v3/job/467148384/log.txt
<mup> PR snapd#6296 opened: tests: new backend used to run upgrade test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6296>
<pedronis> zyga: ?
<zyga> pedronis: we broke fedora, one sec
<mvo> zyga: which one?
<zyga> mvo: maciej is making the patch
<mborzecki> evenin
<zyga> https://bugzilla.redhat.com/show_bug.cgi?id=1658152
<zyga> hey
<zyga> it seems that we need one ' to fix it
<zyga> ideal for 2.36
<cachio> zyga, #6296
<mup> PR #6296: tests: new backend used to run upgrade test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6296>
<cachio> let's see
<zyga> super, thanks
<zyga> let's see how this behaves
<mborzecki> zyga: Pharaoh_Atem: https://github.com/snapcore/snapd/pull/6297
<mup> PR #6297: data/selinux: fix syntax error in definition of snappy_admin interface <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6297>
<cachio> mvo, core18 rev 491 is the one I should test?
<cachio> it is on beta now
<mup> PR snapd#6297 opened: data/selinux: fix syntax error in definition of snappy_admin interface <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6297>
<mborzecki> zyga: ^^
<zyga> mborzecki: are the whitespace changes deliberate?
<mborzecki> zyga: not necessary, but made it look like the rest of the code there which is using tabs for indentation
<zyga> +1
<mvo> cachio: I think this will be a step forward
<mvo> but there is one more thing I'm looking at :(
<zyga> mvo:  ^ can we cherry pick that into 2.36
<mvo> zyga: yes, please mark it
<zyga> it's marked
<zyga> thank you
<zyga> hmm, I log into FAS and yet bugzilla thinks I'm not logged in
<zyga> eh
<cachio> mvo, last core18 from beta work much better
<cachio> could not reproduce the error anymore
<mvo> cachio: that sounds very encouraging
<zyga> degville: it's almost time
<mvo> fwiw, I updated 6243 while waiting for tests but not urgent
<pedronis> cachio: mvo: encouraging/good
<cachio> pedronis, mvo tests are going well so far
<mvo> cachio: cool
<degville> thanks for the reminder zyga :) I reckon she'll make it through to the next level.
<pedronis> mvo: that change in 6243 seems in the right direction, but copying mutexes by value is not supported afaik and go vet should be unhappy, it will need tweaking
<pedronis> (go vet was unhappy here when I tried something like that)
<pedronis> cachio: another run dying without actually starting tests: https://api.travis-ci.org/v3/job/467159346/log.txt
<pedronis> this was the selinux PR
<pedronis> for 2.36
<cachio> pedronis, taking a look
<cachio> pedronis, this failed on 1 test
<cachio> google:ubuntu-core-16-64:tests/main/ubuntu-core-upgrade
<pedronis> it didn't reboot?
<cachio> pedronis, mmmm, I think it lost connection on reboot
<cachio> pedronis, ot os weord
<cachio> weird
<mvo> pedronis: oh, I thought I did pointers, maybe I was dreaming
<cachio> pedronis, perhaps it is related to the error on spread rebooting machines
<cachio> pedronis, it is not returning from the reboot
<cachio> I'll try  to reproduce it
<mvo> pedronis: aha, I see what you mean now. do we actually copy this backend around? I thought we only had a single one, let me look at the code
<mvo> pedronis: (maybe I'm just tired :)
<pedronis> mvo: the methods on it are by value, so yes, in principle is copied
<pedronis> before it was an empty struct so didn't matter
<pedronis> much either way
<cwayne> mvo: cachio core18 498/497 looks good from our end
<cachio> cwayne, nice
<pedronis> mvo: so retry logic is not working on arch
<pedronis> even newer go?
<mvo> pedronis: indeed, I was a bit blind, updated it
<mvo> cwayne: thanks, great to hear
<mvo> pedronis: oh, I have no idea, let me look at arch
<cachio> cwayne, mvo I see 494 on beta
<pedronis> mvo: https://api.travis-ci.org/v3/job/467160635/log.txt  also the setup of the test doesn't work on core
<cwayne> cachio: armhf/arm64
<mvo> cwayne: \o/
<cachio> ahh, ok
<mvo> pedronis: aha, yes, I think its ok to blacklist core for this test
<cwayne> cachio: dont have an x86 device for core18 yet
<cachio> cwayne, nice
<cachio> mvo, do we need to cover all the architectures for core18?
<pedronis> mvo: mv: cannot move '/etc/resolv.conf' to '/etc/resolv.conf.save': Read-only file system
<mvo> cachio: yes, eventually, not tonight though
<mvo> pedronis: exactly
<pedronis> mvo: we can move the file it points to no?
<cachio> mvo, ok
<mvo> pedronis: yes
<pedronis> maybe
<pedronis> it just feels strange to skip on core if possible
<mvo> pedronis: I think on arch we get "Temporary failure in name resolution" :(
<pedronis> but IsTemporary is not set?
<mvo> pedronis: it looks like it is not which is ironic given the error text
<pedronis> what go does it have?
<mvo> pedronis: I try to figure that out now but I don't see it in the output, I may need to run spread with it
 * mvo runs in google to find out
<pedronis> mvo: seems it might be a cgo error actually
<pedronis> so maybe maciej was right, and it's used sometimes
<zyga> re
<zyga> it seems it's not EOD, or EOY yet
<mvo> pedronis: yeah, will you add code to detect it or shall I?
<mvo> zyga: not quite
<mvo> pedronis: anyway,I can check tomorrow in my morning, I think I need some sleep :) thanks for all your help (and to you zyga,cachio and cwayne as well!)
<pedronis> mvo: yes, it's a bit late to try to fix this
<pedronis> I'm also not sure how stable/where that message exactly comes from
<pedronis> go runtime code? resolver code?
<mvo> pedronis: arch has go1.11.2 fwiw
<mvo> pedronis: I suspect resolver but we can dig into it tomorrow (grep -r glibc- :)
<pedronis> I suspect the same
<pedronis> also calling it a day
<mvo> pedronis: ttfn!
<zyga> mvo: gai error
<zyga> Iâm on the phone now
<cachio> mvo, good sleep
<cachio> mvo, see you tomorrow
<mvo> cachio: see you
<mvo> zyga: gai?
<pedronis> anyway seems indeed from libc
<zyga> pedronis: yes, the error is from https://linux.die.net/man/3/gai_strerror
<mup> PR snapd#6180 closed: snap/info: bind global plugs/slots to implicit hooks <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6180>
#snappy 2018-12-13
<mup> PR snapcraft#2426 opened: tests: use fixed version for idna in plainbox <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2426>
<brlin> Good afternoon, from UTC+8
<brlin> I noticed that `snapcraft init` adds a recipe that asserts `base: core18`, is that indicate that it is now recommended to use core18 as the base instead of core16?
<mborzecki> morning
<mvo> mborzecki: hey
<mborzecki> mvo: can you take a look at https://github.com/snapcore/snapd/pull/6297 ?
<mup> PR #6297: data/selinux: fix syntax error in definition of snappy_admin interface <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6297>
<mvo> sure
<mborzecki> mvo: we'll need to cherry pick that patch to 2.36
<mvo> mborzecki: ok - should we run sepolgen-ifgen as part of the tests?
<mborzecki> mvo: yes, that's a good idea, i'll add it to the selinux PRs
<mvo> mborzecki: I merged this one now
<mborzecki> mvo: thanks
<mvo> and cherry-picked, so all good
<mvo> thank you!
<mborzecki> mvo: great, thanks!
<mup> PR snapd#6297 closed: data/selinux: fix syntax error in definition of snappy_admin interface <SELinux> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6297>
<mborzecki> and added a card :)
<mborzecki> another trivial PR https://github.com/snapcore/snapd/pull/6298
<mup> PR #6298: packaging/{fedora,opensuse}: own /var/lib/snapd/cookie <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6298>
<mup> PR snapd#6298 opened: packaging/{fedora,opensuse}: own /var/lib/snapd/cookie <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6298>
<zyga> Good morning
<mborzecki> zyga: hey
<mvo> hey zyga
<zyga> :-)
<zyga> sorry, a bit sleepy still
<zyga> I stayed up late and fixed my TV
<zyga> mborzecki: trivial removal of dead code: https://github.com/snapcore/snapd/pull/6293
<mup> PR #6293: cmd/snap-confine: remove unused sc_discard_preserved_mount_ns <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6293>
<mborzecki> looking
<mup> PR snapd#6295 closed: systemd: start snapd.autoimport.service in --no-block mode <â  Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6295>
<zyga> mvo: what's the state of the release?
<zyga> ah
<zyga> the gai_strerror thing
<mvo> zyga: working on it
<mvo> zyga: some bits have landed, but more bits needed
<mborzecki> damn, ls -Zd has different output on centos and fedora
<zyga> cannot allocate memory in dnf makecache? https://www.irccloud.com/pastebin/2TrCykuR/
<zyga> mborzecki: what's the difference?
<mborzecki> zyga: centos drwxr-xr-x. niemeyer google-sudoers unconfined_u:object_r:home_root_t:s0 .
<mborzecki> fedora unconfined_u:object_r:user_home_t:s0 .
<mvo> sil2100: hey, good morning! one final core18 pr (hopefully the last) https://github.com/snapcore/core18/pull/103
<mup> PR core18#103: static: add missing systemd symlinks <Created by mvo5> <https://github.com/snapcore/core18/pull/103>
<zyga> mvo: did you see the test failure there?
<zyga> is that expected?
<mvo> zyga: well, yes, I have not had time to look into it :( but tests are unhappy there
<zyga> it doesn't seem related to the nature of the change in the pull request
<mvo> zyga: exactly, looks like something innternal
<mvo> zyga: so snapcraftctl iirc
<pstolowski> hey
<sil2100> mvo: morning! Looking in a minute
<mvo> sil2100: thank you
<zyga> hello Pawel
<mup> PR snapd#6299 opened: travis: short cicruit failures in static and unit tests suites task <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6299>
<mborzecki> zyga: ^^
<zyga> looking
<pedronis> mvo: morning, sorry I'm a bit late,  what's the status of things?
<zyga> thank you!
<zyga> mborzecki: yes yes yes :)
<pedronis> mvo: I saw some of the PR are landed now
<mvo> pedronis: yeah, progress
<mvo> pedronis: some things still pending though
<mborzecki> heh, the code formatted with new gofmt is incorrectly formatted with the 1.6 one
<zyga> mborzecki: yeah
<zyga> I opened a PR to highlight that before
<zyga> sucks :/
<mborzecki> i'm thinking, maybe we could go get gofmt (the tool) with 1.6 instead
<pedronis> mvo: are you waiting for me to look at #6243 ?
<mup> PR #6243: systemd: allow only a single daemon-reload at the same time <Created by mvo5> <https://github.com/snapcore/snapd/pull/6243>
<zyga> mborzecki: hmm?
<mborzecki> zyga: go get github.com/golang/go/src/cmd/gofmt, this would pull the latest one
<zyga> aha
<zyga> I see
<zyga> as long as people on older releases are happy to integrate this with their workflow, yeah
<mvo> pedronis: its a bit of a target of opportunity - if you think its too much we can just leave it for later
<mvo> pedronis: it seemed its now relatively clean and the win is relatively high
<pedronis> mvo: my main comment there, thinking a bit further, is that the description is misleading, we do daemon-reload in other places?
<pedronis> mvo: if to fix it we really need to serialize daemon-reload then that is not enough, no?
<mvo> pedronis: let me see, I think you are right
<pedronis> so it would need more work, and doesn't feel a .3 thing
<mvo> pedronis: hm, in the overlord we really only do the daemon reload there afaict - but yeah, lets push it out
<pedronis> let me double check
<pedronis> mvo: we do reloads in wrappers which is used indirectly by overload for example
<pedronis> sorry, overlord
<mvo> pedronis: aha, its the only explicit place. indeed
<pedronis> also interfaces systemd backend does it
<pedronis> let me put this chat in the PR
<mvo> pedronis: thank you, yeah - we need to investiagte, serializing all daemon reloads would be a bit painful but I'm not into the bug enough to know
<pedronis> mvo: done, thanks for marking as blocked, yea, needs more thinking I fear
<pedronis> mborzecki: so you were right and it seems on arch we end up with a snapd that uses the cgo resolver,  I thought we had reasons for not wanting cgo at all, do you know if can stop arch using that? not an immediate thing
<pedronis> mvo: ^
<zyga> cross distribution work is fun
<zyga> you get to see *all* the buys
<zyga> bugs
<pedronis> mvo: so we are left with 6287
<mvo> pedronis: there is one more that I'm working on
<mvo> pedronis: we have snapd.seeded.service now on core18 at startup. this has a "Requires=snapd.socket" which means that when "snapd.socket" gets stopped (even if its not active) snapd.seeded.service is also stopped
<mvo> pedronis: during the seeding the code so far naively restarts things (including snapd.socket) now it needs to be smart and only restart when snapd.socket is actually active
<pedronis> mvo: I'm not following
<mvo> pedronis: sorry, let me be less terse :)
<pedronis> what breaks? :)
<mborzecki> pedronis: hm maybe there's a build tag we could use, other than that we can use GODEBUG= switch
<sil2100> mvo: approved if anything!
<mvo> pedronis: we have the snapd.seeded.service. it has a "Requires=snapd.socket". this means in systemd terms that the when snapd.seeded starts snapd.socket is started by snapd. the converse is also true - systemctl stop snapd.socket will also stop snapd.seeded even if snapd.socket was not active before
<mvo> pedronis: what breaks is that during the seeding boot snapd.seeded stops and that will (AIUI) make systemd start units with the after=snapd.seeded ordering
<sil2100> mvo: will you guys perform some validation testing on the core18 snap now?
<mborzecki> pedronis: hm i think we could also do that in the code, set a preferred resolved on a dialer
<mvo> pedronis: but at this point its too early, the seeding is not done yet, we just got our snapd.socket unit and that is started now (via a restart which is the problem)
<mvo> sil2100: yeah, once all the pieces are in cachio will run tests
<sil2100> (still no merge-powers sadly)
<mvo> sil2100: we also get tests from cert (cwayne team)
<sil2100> mvo: yeah, I know the automation from certification, but I also saw some tests coming from cachio last time
<pedronis> mvo: there is no snapd.socket in core18 itself?
<pedronis> we write it from snapd?
<zyga> pedronis: correct
<mvo> pedronis: correct
<pedronis> mvo: so we should know what to do, no? we are just being naive?
<pedronis> I'm still missing if there's a deep problem or a shallow one
<pedronis> (I suppose that's what systemd does to you)
<zyga> pedronis: I think we could look at the way snapd stats up a little so that the relevant code is in our primary repository and so that core18 just consumes that
<mvo> pedronis: we are just naive
<zyga> pedronis: and to spend some more time on making things more robust and better tested
<zyga> pedronis: but in general things feel okay
<pedronis> zyga: ?
<pedronis> it's already mostly the case
<pedronis> there is little code in core18
<pedronis> about this
<zyga> pedronis: yes but it in core18 repo, it will need to be in core20 repo and in other repos eventually, we could just have core18 and core16 eventually consume a deb that is built out of snapd source package
<pedronis> it's mostly the baggage of systemd unit keywords (they often do a bit more or less than one would exactly like)
<pedronis> zyga: sounds like a code org issue
<pedronis> not a what the code does issue
<zyga> yes
<zyga> I said we're mostly okay
<pedronis> anyway it seems very premature before we got our v0 working
<mup> PR snapd#6300 opened: travis: use more recent version of gofmt <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6300>
<mup> PR snapd#6298 closed: packaging/{fedora,opensuse}: own /var/lib/snapd/cookie <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6298>
<mup> PR snapd#6301 opened: wrappers: only restart service in core18 when they are active <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6301>
<mvo> mborzecki: quick question for you - the systemd mount unit bug - we were wondering if the workaround must serialize all daemon-reloads. or if its enough to ensure that there is only a single mount unit started (and we wait until that start is finished) at the same time. i.e. however many daemon-reloads are ok as long as there is just a single mountunit starting. this question affects the nature of the workaround. if its just a single mountunit at
<mvo>  the same time the workaround I pushed is probably sufficient. if we need to serialize all dameon-reload things are more complicated. do you have more insight into this?
<mvo> (uh, that was long, sorry!)
<mborzecki> mvo: i don't have more insight, i think i'd play it safe and serialize reloads & mounts
<mvo> pedronis: fwiw 6301 is up and has the bits I mentioned
<mvo> mborzecki: ok, so when we do the mountunit generation / daemon-reload /start nothing no other daemon-reloads?
<mvo> mborzecki: that will be interessting code-wise :)
<mup> PR snapd#6268 closed: overlord/ifacestate: helpers for serializing hotplug changes <Hotplug ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6268>
<mborzecki> mvo: yes, that'd the the super safe variant
<mborzecki> mvo: otoh, your pr only serialized the mounts and seemed to work fine
<mvo> mborzecki: yeah, this is why I was wondering
<mborzecki> mvo: so we could start small, it's unlinkely we'd introduce a regression
<mvo> mborzecki: if your script could be extended to springle random daemon-reloads but only a single mount at the same time and it is fine we might get away with the simpler version
<mvo> mborzecki: fair point, feel free to report in the bug
<mvo> mborzecki: eh, PR
<mborzecki> mvo: i'll update the script and let you know
<mvo> mborzecki: \o/
<pedronis> mvo: so stopping something that is not running does something ?
<pedronis> that's probably the bit I don't understand
<zyga> pedronis: yes, stops related stuff AFAIK
<mvo> pedronis: coreect
<pedronis> mvo: I'm working on 6287
<pedronis> btw
<mvo> pedronis: ta
<mup> PR snapd#6300 closed: travis: use more recent version of gofmt <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/6300>
<mborzecki> mvo: bad news, single mount & many reloads fails the same way
<mvo> mborzecki: thanks, there was hope for a moment :)
<mvo> mborzecki: its fine, makes things more complicated but at least we know now. thanks for checking
<mborzecki> mvo: i've updated the script https://gist.github.com/bboozzoo/d4b142229b1915ef7cc0cf8593599ad9 in case yout want to double check the code
<pedronis> ok, so that PR is indeed not enough
<mvo> mborzecki: my brain is too mushy today :)
<mvo> pedronis: yeah, slightly sad
<mvo> mborzecki: but thanks for adding it, will probably be helpful in the future
<zyga> mborzecki: nice work
<mborzecki> mvo: fwiw, it's harder to reproduce now
<mborzecki> mvo: i think i'd start with a simpler fix
<mvo> mborzecki: thanks, yeah, it won't hurt and make things a bit better. we just need to make sure to document that its not the full fix
<mborzecki> mhm
<pstolowski> pedronis: do you have some time for a HO today?
<pedronis> pstolowski: yes
<pstolowski> pedronis: standup ho?
<pedronis> pstolowski: yea, but I need 5 mins
<pstolowski> pedronis: ok
<mup> PR snapd#6301 closed: wrappers: only restart service in core18 when they are active <â  Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6301>
<mup> PR snapd#6302 opened: wrapprs: address review feedback from #6301 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6302>
<mup> PR core18#103 closed: static: add missing systemd symlinks <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/103>
<pedronis> pstolowski: now works
<pstolowski> ok
<pedronis> mvo: I pushed changes/fixes to #6287
<mup> PR snapd#6303 opened: cmd: add tests for lintArg and lintDesc <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6303>
<mup> PR #6287: httputil: retry on temporary net errors <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6287>
<zyga> pstolowski: trivial PR with some unit tests for internal functions https://github.com/snapcore/snapd/pull/6303/files
<mup> PR #6303: cmd: add tests for lintArg and lintDesc <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6303>
<pedronis> zyga: mborzecki: 6287 needs 2nd reviews btw
<pstolowski> zyga: ok
<Chipaca> morning peeps, sorry i'm late
<pedronis> Chipaca: hello
<mborzecki> pedronis: mvo: btw. do we take any steps to use go resolver on ubuntu?
<Chipaca> zyga: wrt 6303, what were the l10n issues?
<zyga> pedronis: ack
<zyga> Chipaca: https://bugs.launchpad.net/snapd/+bug/1806761
<mup> Bug #1806761: Trash output for LANG=ru_RU.UTF-8 (probably all non-ASCII languages) <snapd:In Progress by zyga> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1806761>
<mvo> mborzecki: iirc we use CGO_ENABLED=0 during the build
<zyga> Chipaca: I think someone misunderstood the translator comment
<mvo> mborzecki: aha, no, wait - just for selected bits like snap-exec
<zyga> and added <foo>s with the s at the end :)
<zyga> Chipaca: so my idea is
<Chipaca> zyga: brb, need to order a bigger palm on amazon, for the facepalm i need to do
<zyga> Chipaca: if the format is "<.*>s", cut the s and not log anything
<zyga> Chipaca: right? :D
<zyga> Chipaca: and fix the translator suggestions to make sure we say "don't add the frelling s"
<mborzecki> mvo: pedronis: looking at net/conf.go, i think go gets confused with 'mymachines' listed as one of the hosts sources on arch
<mvo> mborzecki: aha, it inspects nsswitch.conf ?
<mborzecki> mvo: yes
<mvo> mborzecki: smart!
<mborzecki> mvo: it's parsing both nsswitch.cofn and resolv.conf, whenever it finds an option/source that's unknown it'll default to libc resolver first
 * mvo nods
<Chipaca> zyga: argument %q's %q should begin with < and end with >
<Chipaca> zyga: ?
<mborzecki> mvo: there's libnss_mymachines.so.2 in my system, owned by libsystemd pacakge
<mborzecki> mvo: on a system which uses resolved it'll probably default to libc resolver too
<zyga> Chipaca: sounds good
<zyga> Chipaca: are you still off today?
<Chipaca> no
<zyga> mborzecki: yes
<zyga> Chipaca: ah, splendid
<zyga> Chipaca: shall we land https://github.com/snapcore/snapd/pull/6303?
<mup> PR #6303: cmd: add tests for lintArg and lintDesc <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6303>
<Chipaca> but i didn't need to take the boys to school today so i turned off my 6am alarm â¦ and then it was suddenly 10:15
<Chipaca> zyga: not without a second review, I'm still smarting from a few others we slipped in too quickly
<zyga> mvo: some comments on https://github.com/snapcore/snapd/pull/6287
<mup> PR #6287: httputil: retry on temporary net errors <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6287>
<mvo> zyga: thanks
<mborzecki> Chipaca: maybe something simple to start with https://github.com/snapcore/snapd/pull/6299 ?
<mup> PR #6299: travis: short cicruit failures in static and unit tests suites task <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6299>
<Chipaca> mborzecki: can I suggest an alternative implementation?
<mborzecki> Chipaca: sure, go ahead
<Chipaca> mborzecki: start "script" with "set -e" :-)
<mborzecki> Chipaca: hm does travis lump all the pieces into one large script?
<Chipaca> mborzecki: apparently
<mborzecki> Chipaca: When one of the build commands returns a non-zero exit code, the Travis CI build runs the subsequent commands as well, and accumulates the build result. taken from https://docs.travis-ci.com/user/job-lifecycle/#customizing-the-build-phase
<Chipaca> mborzecki: https://github.com/travis-ci/travis-ci/issues/1066
<Chipaca> mborzecki: if it works, the advantage of having them in separate lines is we get separate timings for them
<Chipaca> mborzecki: and I like having those timings
<mborzecki> Chipaca: mhm
<mborzecki> but damn travis
<Chipaca> is this an instance of "old man yells at cloud"?
<mborzecki> haha
<mborzecki> Chipaca: ok, pushed set -e, we'll se if it fails for real
<mup> PR snapd#6304 opened: wrappers: use new systemd.IsActive in core18 early boot <Created by mvo5> <https://github.com/snapcore/snapd/pull/6304>
<pedronis> mborzecki: mvo: I missed this,  https://github.com/snapcore/snapd/pull/6277/files  it's a bit of odd change for a .x release
<mborzecki> Chipaca: seems to work
<mup> PR #6277: centos: enable SELinux support on CentOS 7 (2.36) <SELinux> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6277>
<pedronis> mborzecki: why the backport to 2.36 ?
<mborzecki> pedronis: it's not really a functional change, neal could have enabled it any time without that PR
<pedronis> mborzecki: how is not functional?
<pedronis> it might break things, no?
<mvo> he would have done it anyway, right? I mean, he would have distro-patched with this, yes? I think that was the rational, it would have been added anyway. but if its a right we can back it out
<mborzecki> pedronis: the package that's in epel is already built this way
<pedronis> ok
<pedronis> sorry for picking on this, but feature changes in late .x releases are a bit wrong
<pedronis> to me
<mvo> pedronis: its a bit of a rathole - 6304 needs to go in too, systemd.Status() in our code is too picky to be usable at early boot
<mvo> pedronis: no worries, your comment is correct
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/6305
<mup> PR #6305: cmd: automatically fix localized <option>s to <option> <Created by zyga> <https://github.com/snapcore/snapd/pull/6305>
<mup> PR snapd#6305 opened: cmd: automatically fix localized <option>s to <option> <Created by zyga> <https://github.com/snapcore/snapd/pull/6305>
<Chipaca> what's 19.04 called again?
<cachio> mvo, hey
<cachio> I see a new core18
<Chipaca> and why does https://translations.launchpad.net/ubuntu/+source/snapd take you to the cosmic translations? isn't 19.04 open?
<pedronis> Chipaca: disco
<cachio> is this the final one?
<zyga> Chipaca: about translations
<zyga> are we importing them?
 * pedronis lunch
<zyga> are we building them in our packages?
<Chipaca> zyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1806761/comments/9
<zyga> apparently not in opensuse
<mup> Bug #1806761: Trash output for LANG=ru_RU.UTF-8 (probably all non-ASCII languages) <snapd:In Progress by zyga> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1806761>
<zyga> I should fix that
<Chipaca> zyga: we sync them manually
<Chipaca> mvo: syncing translations is still manual, yes?
<zyga> mvo: kind request to sync 2.37 translations
<Chipaca> also seriously why aren't disco translations there yet
<zyga> Chipaca: nice, thank you for that comment
<Chipaca> zyga: i'll push a small change to your pr in a bit
<zyga> sure, thanks
<mvo> cachio: hey, we have one open pR (6403) and then I think we are (finally!) good
<mvo> reviews for 6403 would be great, maybe Chipaca ?
<mup> PR snapd#6293 closed: cmd/snap-confine: remove unused sc_discard_preserved_mount_ns <Per-user mount ns  ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6293>
<mvo> cachio: sorry, it dragged on a bit but things should be under control now once this PR is in
<cachio> mvo, nice
<cachio> I'll wait for that
 * mvo also lunch but will check tg
<mvo> cachio: yes, no point in testing before this is in
<zyga> yeah, lunch sounds good
<Chipaca> zyga: pushed; wdyt
<Chipaca> mvo: 6403?
<Chipaca> mvo: going to assume you meant 6304
<mvo> *cough* yes
<mvo> ta
<zyga> Chipaca: Iâll check soon
<mup> PR snapcraft#2426 closed: tests: use fixed version for idna in plainbox <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2426>
<pstolowski> pedronis: ok, i think what's wrong with the taskrunner
<pstolowski> *i think i know
<zyga> pstolowski: anything for 2.36?
<pstolowski> zyga: no
<zyga> Chipaca: looking now
<zyga> Chipaca: in https://github.com/snapcore/snapd/pull/6305/commits/195523c129c7ede53f3969da2e9913bfa18c3159
<mup> PR #6305: cmd: automatically fix localized <option>s to <option> <Created by zyga> <https://github.com/snapcore/snapd/pull/6305>
<mborzecki> zyga: quick question about release/apparmor.go, shouldn't the code in assessAppArmor or the public functions be wrapped with a mutex?
<zyga> did you mean to use has suffix or has prefix?
<zyga> mborzecki: mmm, perhaps
<Chipaca> zyga: a clear case of id10t
<zyga> mborzecki: +1 :)
<Chipaca> zyga: if only we had tets!
<Chipaca> zyga: or tests!
<pstolowski> pedronis: i think i see a problem around scheduling of next ensure; after Retry we do EnsureBefore(0), yes; but after ConsiderTask loop we also call EnsureBefore with nextTaskTime (if non-zero - it happens to be taken from the auto-disconnect task; it's the only task with non-zero AtTime()); so the call to EnsureBefore after the big loop resets EnsureTime to +5s from now. The ensureBefore() code in overlord has a condition
<pstolowski> to prevent this I think, but it looks suspicious, I think it's incorrect
<zyga> Chipaca: yes, tests are coming in via another PR
<Chipaca> zyga: IKR
<zyga> hehe
<Chipaca> zyga: we could stack this one on that one
<zyga> nah
<zyga> nobody reviews things that are long
<Chipaca> zyga: i mean, we need a test for the >s pruning
<zyga> and it requires writing another message
<mborzecki> zyga: seccomp piece too
<zyga> Chipaca: one more on top :)
<zyga> or land the 1st and then let's rebase
<Chipaca> zyga: I mean, land the tests one, andd let's rebase
<Chipaca> zyga: ding ding ding
<zyga> ++
<Chipaca> zyga: maybe we can convince mborzecki to do a review of the tests one
<Chipaca> zyga: I hear he's into that
<mborzecki> Chipaca: which pr is that?
<zyga> mborzecki: you're into https://github.com/snapcore/snapd/pull/6303
<zyga> oh
<zyga> it has +2
<mup> PR #6303: cmd: add tests for lintArg and lintDesc <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6303>
<Chipaca> mborzecki: 0118 999 881 999 119 725 3
<mborzecki> Chipaca: your IBAN? :)
<Chipaca> duude
<zyga> whaaaat :)
<Chipaca> mborzecki: https://www.youtube.com/watch?v=ab8GtuPdrUQ
<mborzecki> aaa hahah
<pedronis> pstolowski: ah, so it's some kind of EnsureBefore bug?
<pstolowski> pedronis: i think so
<pstolowski> pedronis: 	if next.Before(o.ensureNext) || o.ensureNext.Before(now) {
<pstolowski> 		o.ensureTimer.Reset(d)
<pstolowski> 		o.ensureNext = next
<zyga> Chipaca: loool
<pstolowski> pedronis: the 2nd part of conditional looks wrong to me
<pedronis> pstolowski: there is something there related to coming back from sleep
<zyga> I read that as EnsureBug bug
<pedronis> we'll need to remember/dig
<pstolowski> pedronis: maybe, but we check existing ensureNext against now(), and then reset to a future next, which I think is the problem in this case
<pedronis> mvo: zyga: I'm going to merge #6287
<mup> PR #6287: httputil: retry on temporary net errors <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6287>
<pstolowski> pedronis: i suppose after sleep we have ensureNext in the past, so we should just make sure to simply ensure *now* ?
<zyga> +1
<pedronis> pstolowski: yea, something like that, we'll need to consider various cases
<pedronis> pstolowski: probably needs a bit more attention that I have right now
<pedronis> but good we are getting closer
<mvo> pedronis: ta, please squash and I will cherry pick
<pstolowski> pedronis: ack
<mup> PR snapd#6287 closed: httputil: retry on temporary net errors <Squash-merge> <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6287>
<pedronis> mvo: done
<zyga> mvo: in https://github.com/snapcore/snapd/pull/6304/files is the root directory significant or just carried over from other systemd methods?
<mup> PR #6304: wrappers: use new systemd.IsActive in core18 early boot <Created by mvo5> <https://github.com/snapcore/snapd/pull/6304>
<pedronis> pstolowski: you should go back to Hotplug and we look at this again when I can look at the picture a bit more, thank you for the digging
<pstolowski> pedronis: k, thanks
<zyga> pstolowski: just write down anything you know somewhere :)
<pstolowski> zyga: good idea. i'm sure after christmas break i won't remember a thing of that ;)
<zyga> pstolowski: perhaps a bug report on snapd
<pstolowski> (unless we manage to discuss and tackle it before xmas)
<pstolowski> zyga: yeah, already reported, just need to write down the details
<zyga> sounds good
<mvo> zyga: just carried over, makes testing easier
<zyga> mvo: https://github.com/snapcore/snapd/pull/6302#pullrequestreview-184634621
<mup> PR #6302: wrappers: address review feedback from #6301 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6302>
<zyga> mvo: +1
<pedronis> pstolowski: thx
<mvo> zyga: ta, no travis tests right now all busy, I get lunch and check back after that
<zyga> mborzecki: we should ship translations in snapd packages
<zyga> mborzecki: I'll look at doing that in 2.36.3
<pedronis> zyga: that sounds something for 2.37
<pedronis> no .3
<pedronis> not .3
<zyga> why so? we ship that on ubuntu
<pedronis> which snapd packages?
<mborzecki> zyga: are you saying other distrons don't ship the translations?
<mborzecki> (arch doesn't)
<pedronis> as formulated it sounded like all packages
<zyga> mborzecki: suse doesn't
<zyga> pedronis: we only ship for sure on ubuntu
<zyga> because the translations are going in via a different mechanism
<mborzecki> ah, so something for me to fix on arch
<mup> PR snapd#6306 opened: release: use locking around lazy intialized state <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6306>
<zyga> mborzecki: reviewed
<mborzecki> zyga: assessAppArmor calls the AppArmor*Features() functions, that's why a separate mutex
<zyga> Ah, I see
<mborzecki> zyga: blindly used just one in the beginnig and go test got stuck :P
<zyga> can you add a quick one line comment to document that
<zyga> it's correct but non obvious :)
<zyga> (at least to me :)
<pedronis> mborzecki: made a comment
<mborzecki> pedronis: thanks, good point!
<zyga> I think it will mess up tests
<zyga> but do try
<pedronis> we can mock/replace them as anything else
<pedronis> anyway we have higher level mocking
<pedronis> already
<pstolowski> pedronis: updated https://bugs.launchpad.net/snapd/+bug/1806447
<mup> Bug #1806447: Sophisticated snap remove retries a lot and becomes very slow <snapd:Confirmed for stolowski> <https://launchpad.net/bugs/1806447>
<pedronis> pstolowski: thx
<pstolowski> pedronis: i'm moving the "investigate.." card to done and will create a new one when we agree on a fix (if it's not trivial and needs a card)
<pedronis> thx
<mborzecki> off to pick up the kids
<mup> PR snapd#6303 closed: cmd: add tests for lintArg and lintDesc <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6303>
<pedronis> mvo: last bit we are waiting on is 6304 ?
<zyga> Chipaca: hmm
<zyga> Chipaca: the extra noticef is not desired
<zyga> it will mean people still get spammed
<zyga> ah, wait
<zyga> what am I saying
<zyga> I mean the order of fixup and lint
<Chipaca> zyga: after mixing up suffix and prefix, i can't deride you for this
<zyga> Chipaca: I don't think we should be teaching users about the translator's mistake
<Chipaca> zyga: can you explain?
<zyga> Chipaca: do I read your patch right that we lint, then fixup
<Chipaca> zyga: correct
<zyga> so you will see a bunch of noticef
<zyga> (that mean nothing to the end users)
<Chipaca> zyga: no
<Chipaca> zyga: because i taught the lint about >s also
<zyga> ah
<zyga> that's ... confusing then
<zyga> ok
<zyga> +1
<zyga> should we always lint, then fixup
<zyga> in both cases?
<Chipaca> zyga: which is the other case?
<zyga> look for calls to lintArg
<zyga> we do it in two places
<zyga> I swapped both in my local tree now
<Chipaca> ah, right
<zyga> I think it's good
<zyga> shall I push?
<Chipaca> zyga: yes
<Chipaca> zyga: have you added tests? :-)
<zyga> Chipaca: tests for the whole init sequence?
<zyga> no
<zyga> I've rebased on the tests PR
<Chipaca> zyga: the order means if arg is "foo>s" the user will see the notice with "foo>s" and not "foo>" (which would be extra confusing)
<Chipaca> zyga: at the same time i wonder if it shouldn't do something like print the first one and " (and NN more similar warnings)"?
<zyga> Chipaca: YAGNI :)
<zyga> Chipaca: I think the has suffix is still wrong
<zyga> I'll fix it (after adding a test)
<Chipaca> zyga: wrt YAGNI, this comes up again and again, I'm half tempted to abandon the whole notion
<Chipaca> the bad thing is there's nothing the user can do, and translators don't get to see the errors because of how removed translations are from the code
<Chipaca> moving this whole thing into a test would accomplish the same as the current panic code
<zyga> Chipaca: interesting
<zyga> Chipaca: but tests don't run with l10n
<zyga> and then we cannot fix it
<zyga> I strongly doubt translators know how to build and run tests
<zyga> especially since our tree has zero code for building localization
<zyga> Chipaca: I pushed
<Chipaca> zyga: tests/main/i18n/
<zyga> Chipaca: and when it fails?
<zyga> what next?
<zyga> fix all i18n?
<zyga> and wait until next import breaks them
<zyga> in some way I agree
<zyga> but I'd separate this
<zyga> the patch now could go into stable
<zyga> to unannoy users
<Chipaca> zyga: your change makes "foo>s" pass lint
<zyga> yes
<zyga> because we cannot do anything about it, that's the point :)
<Chipaca> no
<Chipaca> zyga: "<foo>s" should pass lint
<Chipaca> zyga: "foo>s" should not
<zyga> ah
<zyga> I see your point now
<zyga> sorry, I will correct that
<Chipaca> and, arg is known to be non-"", fwiw
<Chipaca> but that doesn't hurt
<zyga> tests really help :)
<pedronis> zyga: last travis tests on #6190 failed but apparently github didn't notice
<mup> PR #6190: overlord/configstate,features: expose features to snapd tools <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
<cachio> mvo, do you have models for core18?
<cachio> I am getting errors to build images for rpi and dragonboard using ubuntuimage
<zyga> thanks, I'll check
<zyga> Chipaca: done
<Chipaca> hmmm
<zyga> https://travis-ci.org/snapcore/snapd/jobs/466961767 <- does this make any sense?
<zyga> what failed?
<Chipaca> zyga:  github.com/snapcore/snapd/overlord/configstate
<Chipaca> overlord/configstate/configmgr.go:31: undefined: configcore.Conf
<zyga> ah, thank you!
<zyga> that output is terrible
<zyga> but one thing at a time
<mvo> cachio: what kind of error do you get?
<cachio> mvo, https://paste.ubuntu.com/p/Z62mXTs6bH/
<zyga> random unit test failure https://www.irccloud.com/pastebin/JLOllQuX/
<zyga> chipaca: that's a small one for you :) https://www.irccloud.com/pastebin/DONZWn2s/
<cachio> pedronis, mvo I need to take my daughter to the doctor
<cachio> I'll try to be back asap
<pedronis> cachio: ok
<pedronis> hope nothing too serious
<cachio> pedronis, a strong pain in the ear
 * cachio afk
<zyga> brb, start the standup without me
<zyga> I'll join in 5 minutes
<sdeziel> hello, looks like my snap setup is somehow busted
<sdeziel> $ sudo snap stop lxd.daemon
<sdeziel> error: snap "lxd" has "seed" change in progress
<sdeziel> the seeding in question never seem to finish
<sdeziel> I'd been a while that my system has issues related to snapd seeding (whatever that is)
<sdeziel> my boot never completes as systemd keeps saying that snapd.seeded.service is still running
<zyga> sdeziel: hey
<zyga> sdeziel: I think we are onto this bug
<zyga> sdeziel: mvo can work with you if you stick around for a moment, we're in a meeting now
<sdeziel> zyga: great! I'll stick around
<sdeziel> I already reported this seed bug in LP: #1806070
<mup> Bug #1806070: snapd.seeded.service never completes preventing full boot to default target <amd64> <apport-bug> <bionic> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1806070>
<mup> PR snapd#6304 closed: wrappers: use new systemd.IsActive in core18 early boot <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6304>
<sergiusens> mvo: hey, you never got back to me on https://bugs.launchpad.net/snapcraft/+bug/1805219
<mup> Bug #1805219: .snapcraft <19.04> <19.04-external> <Snapcraft:Triaged> <https://launchpad.net/bugs/1805219>
<mvo> sergiusens: ineed, sorry for this, I try to reply today but need to ru nnow
<zyga> Chipaca: can you please review https://github.com/snapcore/snapd/pull/6190
<zyga> I know it's long
<zyga> but I badly need a 2nd review
<mup> PR #6190: overlord/configstate,features: expose features to snapd tools <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
<zyga> Chipaca: once landed it will unlock things I need to work on
<pedronis> mborzecki: I requested reviews from you for a couple of pstolowski PRs needing 2nd reviews
<mborzecki> pstolowski: sure
<pedronis> thx
<mup> PR snapcraft#2427 opened: lifecycle: query for multipass install on darwin <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2427>
<mup> PR snapd#6285 closed: selinux: package to query SELinux status and verify/restore file contexts <SELinux> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6285>
<Chipaca> zyga: on it
<zyga> thank you!
<mup> PR snapcraft#2421 closed: tests: remove obsolete snap and external tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2421>
<mup> PR snapcraft#2425 closed: snap: re-add pyc files for snapcraft <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2425>
<mup> PR snapcraft#2428 opened: tests: increase test timeout for plainbox <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2428>
<mborzecki> using sync.Once in release is tricky
<Chipaca> zyga: +1
<zyga> thank you!
<zyga> woooot
<noise][> ohsaycanyousay
<noise][> wow
<noise][> burned that hacky pass
<sergiusens> to ALL your accounts?
<noise][> heh
<noise][> just all my banks :)
<zyga> sdeziel: mvo is not around anymore, perhaps you want to open a bug report to make sure this is not lost
<sergiusens> those are impossible to log in to at times, so no worries
<zyga> with the features PR we can finally evolve anything we want
<zyga> with a feature flag controlling it
<zyga> this is a major milestone :)
 * noise][ needs a new throwaway pass for sites that don't matter
<sdeziel> zyga: I've already open LP: #1806070, if another is needed please tell me where
<mup> Bug #1806070: snapd.seeded.service never completes preventing full boot to default target <amd64> <apport-bug> <bionic> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1806070>
<zyga> thank you, that will be sufficient
<sdeziel> zyga: OK, thanks. I'll stick around today and tomorrow as this issue is important for me as it prevents all my snaps from updating/refreshing :(
<zyga> pedronis: ^
<sdeziel> I'm stuck with lxd 3.2 while the stable version is 3.7
<zyga> sdeziel: can you please save your state file /var/lib/snapd/state.json
<zyga> sdeziel: if you had authenticated please don't send it to the bug report (snap login)
<zyga> sdeziel: but if you did not it might help us debug
<sdeziel> zyga: could you refresh my memory to check if I had logged in?
<sdeziel> I vaguely remember something like that for the livepatch snap but not sure
<zyga> sdeziel: snap whoami
<sdeziel> email: -
<zyga> I think you should be good
<sdeziel> great, I'll attach this to the LP bug
<zyga> sdeziel: you have some questions on the bug report as well
<sdeziel> zyga: thanks, I hadn't receive the notifications emails
<zyga> you can just refresh the bug report page
<sdeziel> yeah, I know but that was my explanation for the delay in response ;)
<zyga> ah, sure :)
<sdeziel> pedronis: for faster turn around on bug 1806070, don't hesitate to ping me in here
<mup> Bug #1806070: snapd.seeded.service never completes preventing full boot to default target <amd64> <apport-bug> <bionic> <snapd:Triaged> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1806070>
<pedronis> zyga: that machine is really in curious state core requested a snapd restar but it never happened afaict
<sil2100> Oh, no mvo?
<pstolowski> sil2100: he had an errand to run; he might show up later but not sure. if not, then he started his holidays...
<zyga> back from freezing outdoors
<zyga> pedronis: didn't the reporter said that the machine rebooted
<zyga> sil2100: no, what's up?
<pedronis> zyga: it's in a very odd state overall
<zyga> pedronis: no disagreement
<zyga> pedronis: shall we aks the reporter to restart snapd?
<pedronis> also one snap is broken
<zyga> pedronis: it might be useful to also ask for uptime
<pedronis> and the dates are strange
<zyga> pedronis: remember when I reported a bug when snapd starts _before_ any snaps were mounted
<zyga> pedronis: I think that's still the case
<pedronis> zyga: reported in which sense? is the a LP bug?
<zyga> yes
<zyga> one sec
<pedronis> there
<zyga> https://bugs.launchpad.net/snapd/+bug/1805866
<mup> Bug #1805866: On core18 system core18 snap was mounted after snapd had started <snapd:New> <https://launchpad.net/bugs/1805866>
<zyga> Chipaca: what's your stance on https://github.com/snapcore/snapd/pull/6305
<mup> PR #6305: cmd: automatically fix localized <option>s to <option> <Created by zyga> <https://github.com/snapcore/snapd/pull/6305>
<mup> PR snapd#6190 closed: overlord/configstate,features: expose features to snapd tools <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6190>
<sdeziel> pedronis: the gnome calc snap doesn't work so I tried to remove it a while ago without success. I've rebooted many time and the snapd.seeded service never finishes
<zyga> sdeziel: interesting
<zyga> sdeziel: hold on please, let me check something
<zyga> sdeziel: what was your "snap version" again?
<zyga> I'm sorry if you said that before
<pedronis> 2.34.2
<sdeziel> zyga: https://paste.ubuntu.com/p/q9qbc7HyT9/
<zyga> ok, classic
<pedronis> it never fully initialized
<pedronis> so also never refreshed
<pedronis> afaict
<zyga> sdeziel: can you run journalctl -u snapd
<zyga> and paste that?
<sdeziel> zyga: http://paste.ubuntu.com/p/zmTKzSXjtD/
<zyga> hmmm
<sdeziel> not sure if that's related but I noticed many apparmor denials related to the livepatch snap
<zyga> probably a consequence
<zyga> Dec 07 08:56:49 simon-lemur snapd[1823]: 2018/12/07 08:56:49.470388 stateengine.go:101: state ensure error: Get https://api.snapcraft.io/api/v1/snaps/sections: dial tcp: lookup api.snapcraft.io on 127.0.0.1:53: read udp 127.0.0.1:53515->127.0.0.1:53: read: connection refused
<zyga> this is curious
<zyga> how is your system networking configured?
<sdeziel> Network Manager drives it and the resolver is a local unbound listening on that socket
<sdeziel> it is possible that unbound get started after snapd
<zyga> mhm
<zyga> can you "systemctl restart snapd.service"
<zyga> let's see what happens then
<sil2100> zyga, cachio: so I wanted to touch base on how the current edge/beta core18 snap tests are going
<zyga> sil2100: I don't know
<cachio> sil2100, hey
<sil2100> cachio: o/
<cachio> Just startin a new test cycle
<sil2100> cachio: thanks ;)
<cachio> I hope today beta validation can be finished
<zyga> sdeziel: once it is restarted please paste "snap changes"
<sdeziel> zyga: restart worked https://paste.ubuntu.com/p/vkvhdJhk8X/
<sdeziel> zyga: snap changes: https://paste.ubuntu.com/p/x5YW9DC9HQ/
<sil2100> cachio: since I see that the cert team automated tests are already running for core18 but I'd like to know if we're good to promote it to stable tomorrow and spin new core18 images
<cachio> sil2100, once snapd and core18 snaps are validated, I'll ping you
<sil2100> cachio: thank you!
<zyga> sdeziel: nice, how about "snap tasks 31"
<cachio> well, first if everything goes well we can go to candidate today
<cachio> and then see when is more convenient to go to stable
<cachio> perhaps on monday
<sdeziel> zyga: snap tasks 31: https://paste.ubuntu.com/p/hRyDBKFYj8/
<zyga> Doing   2 days ago, at 09:31 EST  -                         Automatically connect eligible plugs and slots of snap "gnome-calculator"
<zyga> pstolowski: does 2.34.2 have the autoconnect deadlock bug?
<zyga> sdeziel: can you snap abort 31
<sdeziel> done
<pstolowski> zyga: that's possible, i'd need to diff to know for sure
<zyga> pstolowski: can you try to find the fix for that
<zyga> at least we would know where we are
<sdeziel> snap changes: 31   Undoing  2 days ago, at 09:31 EST  -      Initialize system state
<pstolowski> zyga: you mean find the PR?
<zyga> pstolowski: or the patch
<pstolowski> zyga: sure, digging
<sdeziel> some progress, snap changes: https://paste.ubuntu.com/p/k94DMXKBSY/
<zyga> look at tasks inside please
<zyga> sdeziel: one thing you might do is update snapd the package on your system
<zyga> did you install system updates?
<sdeziel> zyga: I pull everything that apt-get feeds me ;)
<zyga> apt-cache policy snapd
<sdeziel> https://paste.ubuntu.com/p/pRQMYdkSBP/
<pedronis> zyga: we haven't SRU snapd in a while
<pedronis> it seems
<zyga> ahhh
<zyga> mmm
<zyga> sdeziel: thank you
<pedronis> not sure what happened there
<sdeziel> snap tasks 32: https://paste.ubuntu.com/p/pM2bBdqH5w/
<pstolowski> zyga:  https://github.com/snapcore/snapd/pull/5827 or https://github.com/snapcore/snapd/pull/6027
<mup> PR #5827: ifacestate/autoconnect: do not self-conflict on setup-profiles if core-phase-2 <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5827>
<mup> PR #6027: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <Squash-merge> <â  Critical> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6027>
<zyga> yep
<zyga> same thing
<pedronis> or we have I think but is not quite through
<zyga> pstolowski: based on the output in the last pastebin, do you think this is the same issue?
<sdeziel> 2.35.5+18.04 is in -proposed, I could give it a try
<zyga> pedronis: I have a feeling snapd seeding should become: install core/snapd (restart); refresh core/snapd; install everything else
<zyga> pedronis: or we'll be in a world of hurt
<sdeziel> zyga: I have to run for now but will be back in ~2h. Thanks for everything to all of you
<zyga> sdeziel: thank you
<pedronis> zyga: unlikely we can do that
<pedronis> also why?
<sdeziel> zyga: I'll hold off on the upgrade to the -proposed version just in case some more investigation is required
<zyga> thank you
<zyga> pedronis: why unlikely?
<zyga> pedronis: priorty: ensure snapd can install its own updates
<zyga> pedronis: right now we are observing a situation where it cannot
<pedronis> we might not have network
<zyga> sure
<pedronis> we need a gadget to do many things
<pedronis> the design is that the image should know is good to go
<pedronis> and then we can refresh it
<zyga> that doesn't fit classic world at all
<pedronis> seeding was not designed for classic
<zyga> unless we assume classic always refreshes snapd via classic packages in case of disaster
<zyga> pedronis: in that case we should rethink seeding on classic
<zyga> it's clearly not working as designed now
<pedronis> ?
<zyga> (and if we say that classic may need to update via classic package we need to SRU each release)
<zyga> pedronis: none of the mechanisms we have implemented solve the problem of the reporter
<zyga> pedronis: my suggestion was to rethink that to allow snapd to at least be able to refresh itself on classic
<pedronis> zyga: it might help or bring other bugs
<zyga> pedronis: it may bring other bugs but currently lack of something like that keeps old bugs (fixed bugs) around
<pedronis> either way I'm still not sure
<pedronis> what is the reporter issue
<pedronis> is not like all bionic images didn't seed
<zyga> I'll try bionic
<pstolowski> zyga: it's very likely it's that bug. 2.34.2 is from July, bug was fixed in September.
<zyga> thank you for checking Pawel
<pedronis> zyga: we need a solid seeding process for core, if it's solid should also work for classic
<pstolowski> zyga: can i help somehow?
<zyga> I agree 100%
<zyga> pstolowski: not that I think so, I think we need to see what happens with a proposed package after the reporter is back
<pstolowski> ok
<pstolowski> zyga: is 2.35.4 confirmed to have the fix?
<pstolowski> zyga: sorry, 2.35.5
<zyga> I don't know, we don't tag bugs or fixes and milestones together
<pstolowski> zyga: ok, if date is any indication, then 2.35.5 in xenial is from 15 Oct (the fix was in master on 13 Sep)
<zyga> the reporter is on bionic and has 2.34.x
<zyga> latest is 2.34.2
<pstolowski> yes, that version definately has the bug, just trying to estimate if the fix made it into 2.35.5 from proposed
<pstolowski> unfortunately #6027 is not fixed in 2.35.5 afaict
<mup> PR #6027: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <Squash-merge> <â  Critical> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6027>
<zyga> I did a fresh install of 18.04.1 with the same version of snapd
<zyga> it was not affected
<zyga> perhaps just lucky
<pstolowski> zyga: there were specific conditions to be met to hit this (i described them in the PR)
<zyga> mount issue when refreshing core https://www.irccloud.com/pastebin/OYlOfBlU/
<zyga> funny
<kyrofa> Ooo, a pretty snapd panic: https://forum.snapcraft.io/t/raspberry-pi-3-install-broken/8957/3
<zyga> hmm, too bad we don't log the error with state checkpoint
<pedronis> zyga: yes, that bug pawel mentioned is fairly complicated
<pedronis> you basically need to install with --dangerous as first thing on a new system
<kyrofa> zyga, regarding your comment there, isn't that exactly what he just posted?
<pedronis> or possibly do the same while seeding is still going on
<pedronis> maybe
<zyga> oh, I thought there would be more :/
<kyrofa> zyga, you can try -n 100 :P
<pedronis> zyga: we do log the error
<pedronis> those logs are cut
<pedronis> logger.Panicf("cannot checkpoint even after %v of retries every %v: %v", unlockCheckpointRetryMaxTime, unlockCheckpointRetryInterval, err)
<zyga> I mean when we say "panic" we could recall the error then
<pedronis> ?
<zyga> Dec 12 03:12:36 localhost.localdomain snapd[992]: panic: cannot checkpoint even after 5m0s of retries every 3s: write
<zyga> "write" is the error?
<zyga> or was it just cut in the terminal output?
<pedronis> as I said those logs look cut to me
<pedronis> so hard to tell
<pedronis> but the Panicf should include the error
<pedronis> anyway at the end of the day
<pedronis> checkpoint is just
<pedronis> osutil.AtomicWriteFile(osb.path, data, 0600, 0)
<zyga> right
<pedronis> so yes, I would expect some kind of i/o error
<zyga> I wonder if it is ENOSPC
<zyga> or something else
 * pedronis mostly calls it a day
<pedronis> ttfn!
<zyga> ttyl!
<zyga> have a good evening :)
<ovrh> Hello! I've been sent here from #ubuntu with my question, which I'm copy-pasting next: I have some weird stuff I'd like to show you guys. https://i.imgur.com/SHwXcsR.png This is the System Monitor on my laptop... what's going on? I'm assuming that can't be right, on my previous installation I had just the partitions that actually existed (swap, /home, /, and the windows partition of the dual boot), but this is... a first for me o.o
<zyga> hey
<ovrh> Also, here's the output from `mount`: https://paste.ubuntu.com/p/T4ZKz99CdK/
<zyga> can you please provide "snap version"
<zyga> I know what this is but it should not have happened, normally those mounts only exist in a separate mount namespace
<zyga> not in your main mount namespace
<zyga> if you open a new terminal
<zyga> and type "cat /proc/self/mountinfo"
<zyga> what do you get?
<ovrh> zyga, Here's snap --version and the other command's output: https://paste.ubuntu.com/p/3wvsFmnygw/
<zyga> ha
<zyga> I understand now
<zyga> so
<zyga> everything is all right
<zyga> when you run gnome-system-monitor as a snap it doesn't execute in the same mount namespace as your other applications
<zyga> instead it executes in a special mount namespace that is crafted and only visible for that specific snap application
<ovrh> So my gnome-system-monitor comes from snap? o.o I would have bet I installed it through aptitude
<zyga> the "file systems" tab shows that gnome-system-monitor is unable to understand what is going on so it displays every mount point as a separate thing
<zyga> it appears so
<zyga> which gnome-system-monitor
<zyga> anyway, mystery solved :)
<ovrh> Dammit, I would have totally lost my bet
<ovrh>  /snap/bin/gnome-system-monitor
<zyga> ovrh: please report a bug with the help of people in #ubuntu-desktop
<zyga> the application should be smarter
<ovrh> So.. the solution is `snap remove gnome-system-monitor && sudo apt install gnome-system-monitor`?
<zyga> ovrh: well, for a quick solution yes. but please do report this bug
<zyga> it should be fixed to operate properly
<ovrh> zyga, Agree about that. I'll prepare the bug report
<zyga> thank you!
<ovrh> No, thank you for your help :)
<Chipaca> ovrh: zyga: the non-snapped system monitor will still show all the squashfs mounts though
<Chipaca> it's unclear to me if ovrh objects to the half-screen of /dev/loop3 bind mounts, or the screen-and-a-half of /dev/loopX squashfs'es
<ovrh> Chipaca, Just removed the snap and reinstalled it from aptitude, I only have 3 entries in the GUI tool now
<zyga> I would argue that it should show neither :)
<zyga> ovrh: no squashfses?
<ovrh>  /, /boot/efi, /home, nothing else
<zyga> Chipaca: I suspect it filters out things based on /run/mtab
<zyga> ovrh: what is in your /run/mtab?
<ovrh> zyga, Not sure what you mean
<zyga> ovrh: can you look at the file /run/mount/utab
<zyga> (sorry, I got the path wrong)
<zyga> can tell us what is inside please
<Chipaca> zyga: or maybe x-gdu.hide
<zyga> yeah
<zyga> I bet it is that
<Chipaca> that's what we started adding it for at least :-)
<Chipaca> strange that the snapped one doesn't pick up on it though
<zyga> Chipaca: yeah
<zyga> inside a snap you probably don't see that
<Chipaca> I blame â¦
<zyga> apparmor
<Chipaca> The salesman drove over the CPU board.
<ovrh> https://paste.ubuntu.com/p/tJwqjDW6T6/
<Chipaca> hm, not a good match, let's try again
<Chipaca> _Rosin_ core solder? But...
<zyga> ovrh: thank you
<zyga> please include this in your bug report
<zyga> I'm sure it will help
<Chipaca> zyga: out of curiosity i looked at /run/mount/utab here, and it's empty?
<ovrh> Where's the x-gdu.hide file? Should I still look there?
<zyga> Chipaca: 16.04
<Chipaca> zyga: ye
<Chipaca> zyga: ok
<zyga> ovrh: no, that's not a file, it's just a marker
<Chipaca> ovrh: it's a mount option (look in that utab you pastebinned)
<Chipaca> ovrh: all those mount entries that don't appear in the gui, because of it
<ovrh> Oh, that's what it means
<Chipaca> yeh
<Chipaca> zyga: is that same file visible "inside", and would those options be there?
<Chipaca> zyga: or is this recreated for the benefit of the thing inside?
<zyga> yes but I doubt it is allowed via apparmor
<zyga> no, no easy way to do that
<zyga> we'd need to mount a special fuse filesystem over to do that
<zyga> (one that does not exist(
<sil2100> cachio: could you send me an e-mail once the core18 testing is done? Thanks!
<sil2100> o/
<zyga> cachio: to me as well please
<cachio> zyga, sure
<cachio> zyga, I think it will be ready tonight
<cachio> it is going slow
<mup> PR snapcraft#2428 closed: tests: increase test timeout for plainbox <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2428>
<mup> PR snapd#6305 closed: cmd: automatically fix localized <option>s to <option> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6305>
<sdeziel> zyga: thanks the snapd version from bionic-proposed fixed it for me, thanks a lot for your help!
<ovrh> zyga, Chipaca, I submitted the bug report. Here's it if you want to give it a look: https://bugs.launchpad.net/ubuntu/+source/gnome-system-monitor/+bug/1808420 Also, let me know if it's the wrong form or something. (I also wrongly assumed markdown would be supported, my mistake)
<mup> Bug #1808420: gnome-system-monitor from Snap does not hide /dev/loop* mounts <gnome-system-monitor (Ubuntu):New> <https://launchpad.net/bugs/1808420>
#snappy 2018-12-14
<mwhudson> uh why are my uploads to the store from launchpad failing?
<mwhudson> eg. https://code.launchpad.net/~mwhudson/+snap/go110/+build/405061
<mup> PR snapcraft#2427 closed: lifecycle: query for multipass install on darwin <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2427>
<mborzecki> morning
<mup> PR snapd#6299 closed: travis: short circuit failures in static and unit tests travis job <Simple ð> <Squash-merge> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6299>
<mup> PR snapd#6307 opened: systemd/systemd.go: add missing tests for systemd.IsActive <Created by mvo5> <https://github.com/snapcore/snapd/pull/6307>
<mup> PR snapd#6308 opened: release: 2.36.3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6308>
<mvo> zyga: 6308 has some interessting bits, would love to understand where the code diff came from
<zyga> Hello
<zyga> This is because of different approach to fix a bug in master and in the release branch
<zyga> I will review it carefully, the master version should be used most likely
<mborzecki> zyga: mvo: hi
<pstolowski> morning
<mvo> zyga: ok, just push to the PR if you are happy
<mvo> zyga: I remember now I think :)
<mvo> mborzecki: hey, good morning
<pstolowski> mvo: oh, still working today?
<mvo> pstolowski: fire is not fully over :(
<mvo> pstolowski: cloud-init on pi and dragon is acting up, i.e. it runs when it should not run and console-conf does not work correctly too
<mvo> pstolowski: hopefully sil2100 (and foundations) can help with these issues
<pstolowski> mvo: :(
<mvo> pstolowski: it is what it is, I will just take 2 days off in jan
<sil2100> Yeah, looking into that as much as I can
<mvo> sil2100: \o/
<mvo> sil2100: all the details are in the mail I send out ~2h ago or so (I hope, if anything is missing, please do let me know)
<zyga> Good morning
<mvo> zyga good morning :)
<zyga> Some patches required
<sil2100> mvo: as per my e-mail, could you attach ds-identify.log from the cloud-init logs?
<sil2100> mvo: anyway, I'm building an image for my pi3 now and I'll test it here as well
<mvo> sil2100: will do, mail goes out in 2min
<pedronis> mvo: hello
<mvo> sil2100: you have mail
<mvo> sil2100: the pi has booted now so things should be quicker now
<mvo> pedronis: good morning
<pedronis> mvo: so  cloud-init on arm devices thinks to be on a cloud, that is annyoing/strange, strange because it wasn't doing that with 16
<pedronis> otoh is probably a newer cloud-init
<mvo> pedronis: yeah, different version and +100 for annoying
<mvo> pedronis: also console-conf is acting up and the IP keeps changing for me so not a great experience
<mvo> ogra: hey, do you happen to know why the pi3 with 4.15 might switch IP addresses on reboot? (context is UC18 image)
<pedronis> mvo: so it think maybe it's an OpenStack
<mvo> pedronis: can you elaborate? what makes it think that? is that in the ds-identify log?
<pedronis> yes
<mvo> pedronis: heh, I see
<mvo> pedronis: it does not have more details about the why it seems
<pedronis> yea, we need to stare at the code
<mvo> pedronis: I just did and had a heart attack
<mvo> pedronis: let me find a link
<mvo> pedronis: it looks like we get the maybe because https://github.com/number5/cloud-init/blob/master/tools/ds-identify#L960
<pedronis> wonderful
<sil2100> check for 'OpenStack' returned maybe
<sil2100> Oh yeah
<mvo> yes, just verfied that code path is taken
<mvo> so I guess cloud init does not run much on non-x86 ;)
 * mvo weeps a bit in the corner
<sil2100> mvo: but we had the same thing in core16, right?
<sil2100> Is cloud-init in xenial different?
<mvo> ppisati:  hey, do you happen to know why the pi3 with 4.15 might switch IP addresses on reboot? (context is UC18 image)
<mvo> no set -e in ds-identify, thats an interessting choice
<mvo> anyway
<pedronis> mvo: sil2100:  does ubuntu-image write some cloud-init conf
<pedronis> ?
<sil2100> pedronis: not if it's not asked to, you can explicitly add one if you need to though
<pedronis> mvo: sil2000: it seems quickest fix not touching cloud-init would be to configure ds-identify with maybe=none if arch is not x86
<mvo> pedronis: yeah, forcing cloud-init to be disabled via ubuntu-image is probably the quickest path forward. iirc --cloud-init can already be passed to u-i so we just need to craft a no-cloud config for it
<pedronis> mvo: not disabled
<mvo> pedronis: aha, just maybe=none ? ok
<pedronis> ds-identify
<pedronis> has a different config
<pedronis> yes, maybe=none
<pedronis> either everywhere or only arm
<mvo> ta, I was not aware of this
<mborzecki> zyga: can you do another pass on https://github.com/snapcore/snapd/pull/6265 ?
<mup> PR #6265: cmd/snap: attempt to restore SELinux context of snap user directories <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6265>
<pedronis> mvo: there's some doc at the top of it, it mentions /etc/cloud/ds-identify.cfg and the kernel cmdline
<mvo> pedronis: thanks, playing with this now
<mvo> pedronis: I also added a trello card UC18 release
<mvo> pedronis: that lists the bugs
<mvo> pedronis: or open issues
<pedronis> thx
<mvo> $ cat /etc/cloud/ds-identify.cfg
<mvo> policy: search,found=all,maybe=none,notfound=disabled
<mvo> pedronis, sil2100 ^- this has helped and no cloud-init anymore
<mvo> pedronis, sil2100 with that I also have a stable IP it seems
<pstolowski> mborzecki: hey, if you get to reviewing hotplug PRs, then #6100 and #6114 would be the first to look at; thanks in advance!
<mup> PR #6100: overlord/ifacestate: hotplug-remove-slot task handler <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6100>
<mup> PR #6114: overlord/ifacestate: handler for hotplug-disconnect task <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6114>
<mborzecki> pstolowski: ack
<pstolowski> and i've just de-conflicted them
<mborzecki> i'm doing 6114 now
<pstolowski> thanks
<mborzecki> hm need to grab some coffee
<mwhudson> mvo: do you have cloud-init logs from when it was causing problems?
<sil2100> mvo: btw. from the failed run you had, could you upload the cloud-init log tarball somewhere?
<mvo> mwhudson: cloud init logs for the console-conf setup? or just where it thinks its in a cloud?
<mwhudson> mvo: one where set-name ended up in places it shouldn't
<mvo> mwhudson: I can probably do that but need to rewrite the sd card and start from scratch, this is also tricky because cloud-init keeps the logs in /run but I cannot login with the broken network
<mwhudson> mvo: ugh
<sil2100> mwhudson: so far I can share with you mvo's cloud-init-generator and ds-identify logs
<mwhudson> debug shell time?
<mvo> mwhudson: yes, just annoying to add in uboot, I struggle with this everytime because I never remember how to do it correctly :(
<mwhudson> everyone loves uboot
<mvo> mwhudson: but I give it a poke in some minutes, just trying to debug another failure on this pi
<mvo> mwhudson: hahaha
<mwhudson> ok
<mwhudson> mvo: basically cloud-init does have code that will write netplan with set-name in it
<zyga> mborzecki: reviewed
<mwhudson> i don't at all understand how it could be triggered in this context
<mwhudson> but i also have no other ideas how else it could get there
<mwhudson> wait
<mwhudson> "cloud-init keeps the logs in /run"
<mwhudson> is that a core specific thing?
<mwhudson> break in the initramfs and mount /run as a real partition? :)
<mwhudson> (systemd might get angry if you do that i guess)
<mvo> mwhudson: to break I need to add a kernel comandline and then I might as well add a debug shell. oh well, I think I will do that
<mwhudson> oh yeah
<mvo> mwhudson: maybe its in /var/log as well, I will check
<mwhudson> it certainly is in classic
<mvo> mwhudson: pretty sure that the generator log is only in /run but I guess thats not relevant for you, right?
<mwhudson> yeah no i want cloud-init.log and cloud-init-output.log
<sil2100> Didn't see anything in /var/log
<mvo> mwhudson: cool, if thats the case then I can help sooner
<sil2100> I had to do a cloud-init collect-logs previously
<sil2100> /var/log/cloud-init.log is empty for me
<mborzecki> damn gnome-shell crashing on each unlock
<mwhudson> sil2100: hmm
<mwhudson> sil2100: syslog?
<mborzecki> zyga: thanks for the review, i didn't think about adding a selinux backend, but maybe we should once the cleanups are in
<sil2100> mwhudson: no syslog + eek, persistent journal not enabled by default
<mwhudson> sil2100: i am not surprised :/
<mwhudson> (persistent journal vs sd cards?)
<sil2100> Let me re-flash and enable persistent journal
<zyga> mvo: I pushed to https://github.com/snapcore/snapd/pull/6308
<mup> PR #6308: release: 2.36.3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6308>
<zyga> the diff isn't 0 but it is as close as it should
<zyga> yes, the release branch had one more patch that was in the chain of fixing system key issue
<zyga> it was because my initial branch got closed and reshuffled and I lost track of that
<zyga> anyone interested in 2nd review on https://github.com/snapcore/snapd/pull/6288 ?
<mup> PR #6288: cmd/snap-confine: refactor call to snap-update-ns --user-mounts <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6288>
<zyga> mvo: do you know what is the status of SRUs into bionic?
<zyga> 2.35.5 is in proposed
<zyga> 2.34.2 is in main/updates
<mvo> zyga I think there were issues with autopkgtest
<zyga> aha
<zyga> real or just noise?
<mvo> zyga: I did not dig into them, iirc autopkgtest killed our tests because they ran too long
<zyga> uhhh
<zyga> anyway, it's probably not super urgent but it would be good to update the classic package
<mvo> zyga I'm not sure what the latest status is though
<zyga> and as soon as 2.36.x is out, do that as well
<mvo> zyga absolutely
<zyga> mvo: no worries, one thing at a time
<zyga> mvo: :)
<mvo> zyga its a mess - I think we need to disable adt again, its just not working in our cloud :(
<zyga> for context, I'm asking because of this bug last evening: https://bugs.launchpad.net/snapd/+bug/1806070
<mup> Bug #1806070: snapd.seeded.service never completes preventing full boot to default target <amd64> <apport-bug> <bionic> <snapd:Fix Released> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1806070>
<zyga> the package in the archive is preventing snapd seeding and refreshing in some cases
<mvo> zyga thanks! I remember we talked about this
 * zyga looks at the snow outside
<zyga> brr
<zyga> I miss my old computer
<zyga> the one that doubled as room heater
<ppisati> mvo: does the ethernet mac change?
<sil2100> ppisati: it's just the IP, I guess it's all good from the kernel side, it's more like a cloud-init thing
<mvo> ppisati: yeah, sorry for the noise, it stopped for me AFAICT once I disabled cloud-init
<mvo> ppisati: which should not have run in the first place but that is a different story.
<ppisati> ack
<mwhudson> mvo: i think i have more or less convinced myself that the set-name comes from cloud-init
<mwhudson> mvo: and now i am going to bed
 * mwhudson zzzz
<sil2100> Indeed, mwhudson thanks!
<mvo> mwhudson: sleep well
<mvo> mwhudson: and thank you!
<pedronis> mvo: we should be careful with the notfound value in that config, it was enabled I think in your original log, not sure where that comes from
<mvo> pedronis: I don't know what enabled it originally, iirc /etc/cloud is empty
<pedronis> mvo: I mean, I'm not sure what happens if it's set to disabled and there's cloud init config
<pedronis> or somebody attaches a disk some of that
<pedronis> it was working on 16
<mvo> pedronis: oh, ok. I suspect that 16 has a different ds-identify
<sil2100> Ugh, indeed
<sil2100> ds-identify-behavior-xenial.patch
<mvo> sil2100: oh, interessting - can you pastebin that one?
<sil2100> Wait, one moment, this doesn't look right
<pedronis> mvo: 16 had also this:  https://github.com/snapcore/core/blob/master/live-build/hooks/40-cloud-init-run-after-networkd-wait-online.chroot
<pedronis> probably not relevant given that in 18 networkd is used in all server images?
<mvo> sil2100: one more interessting observation - even when I run console-conf I get a prompt to run it again instead of the usual "here is the machine IP and how you log in". but could be an artifcat
<mvo> pedronis: that is the default now unless I very much misremember
<mvo> pedronis: I remember looking at this patch and if we still need it
<mvo> (I might be wrong though and can double check in a wee bit)
<zyga>  mborzecki https://bugzilla.redhat.com/show_bug.cgi?id=1648733
<mborzecki> heh
<pedronis> mvo: I read dsidentify, nocloud is a kind of cloud,  either the things ubuntu-image writes or a properly labeled fs shoild make dsidentify detect that
<pedronis> so that's not a notfound case afaict
<mvo> pedronis: hm, ok
<pedronis> see dscheck_NoCloud
<zyga> Chipaca: heh, this is fun https://bugs.launchpad.net/snapd/+bug/1808450
<pedronis> still wondering where the notfound=enabled comes from
<zyga> Chipaca: %q needs to be localised :)
<pedronis> shouldn't be the default
<mup> Bug #1808450: Strings with placeholders donât include quotation marks so they canât be changed per locale <snapd:Triaged> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1808450>
<Chipaca> zyga: hrm?
<mvo> pedronis: interessting
<Chipaca> zyga: yeah, no
<Chipaca> zyga: somebody's being very ornery there
<zyga> well, I kind of agree
<sil2100> pedronis: I think it is the default, when you check ds-identify's DI_DEFAULT_POLICY_NO_DMI I guess?
<zyga> snapd would not get a passing grade from my polish tearcher
<zyga> teacher
<pedronis> sil2100: ah
<mborzecki> pedronis: left some benchmarks in https://github.com/snapcore/snapd/pull/6265#discussion_r241703113 it's a vm running as a snapshot, though i took care to drop the caches each time, i'll see if i can get some measurements where the are actual writes to a spin drive
<mup> PR #6265: cmd/snap: attempt to restore SELinux context of snap user directories <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6265>
<mborzecki> fwiw the numbers aren't terrible, 27s for 600k small files, better than fontconfig
<pedronis> mborzecki: this sound like we don't want to do it inconditionally, no?
<pedronis> mvo: anyway afaik  we can just set  maybe=none and the parsing will use the defaults for the rest
<pedronis> s/afaik/afaict/
<mvo> pedronis: cool, I can try in a bit but right now I am running the testsuite
<mborzecki> pedronis: the pr was already updated to do it only when the ~/snap (the dir) is not using the default label
<mvo> pedronis: it looks like all the issues cachio had with running the arm tests are from cloud-init being enabled, so far I ran the core18 specific tests and all green, main is running now as well
<pedronis> good
<mvo> pedronis: I'm sure sil2100 will find a good config and a way to get it into the system and then this fire is hopefully also done
<Chipaca> zyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1808450/comments/1
<mup> Bug #1808450: Strings with placeholders donât include quotation marks so they canât be changed per locale <snapd:Triaged> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1808450>
<pedronis> mvo: sil2100: we can have that file in core18 itself?
<pedronis> that file = ds-identify.cfg
<Chipaca> zyga: I mean, I agree, except in Spanish guillemots are very much optional / recommended-but-not-required
<zyga> I agree about the low priority
<Chipaca> zyga: and the 2nd preferred quote symbols are â¦ ââ
<sil2100> pedronis: so I see that in core 16 we had /etc/cloud/ds-identify.cfg
<sil2100> With policy: search,found=first,maybe=none,notfound=disabled
<Chipaca> zyga: to which " is a close enough approximation for now
<sil2100> Trying to figure out where this file is coming from
 * zyga is happy that he can at least read loads of spanish 
<mvo> sil2100: where did this come from? did u-i put it there ?
<sil2100> mvo: that's a good question, trying to figure it out - u-i doesn't really have mechanisms for arbitrary files in /etc
<mborzecki> spread jobs hitting travis timeouts?
<sil2100> mvo: huh
<sil2100> mvo: it's in the core snap
<sil2100> mvo: not sure what's adding it, but if you unsquashfs core you can see the file there - I didn't see it created in any hooks so far, cloud-init itself also doesn't seem to ship it (at least as a file, maybe through maintainer scripts?)
<mvo> sil2100: oh, run
<mvo> sil2100: eh, fun
<pedronis> mvo: sil2100: fascinating
<mvo> sil2100: ok, we can put it back if that fixes all the issues
<pedronis> anyway means doing the same for 18 wouldn't be too crazy :)
<mvo> pedronis: :)
<sil2100> Yeah, sounds like the best way ;) I'll try to figure out where it's created out of curiosity anyway
<sil2100> But this would fix "all the issues"
<mvo> sil2100: I think ubuntu-core-config created this
<mvo> sil2100: give me a sec
<sil2100> mvo: oh, that's something new!
<sil2100> I saw it in the image PPA once but didn't know it was used
<sil2100> Sweet
<mvo> sil2100: we no longer use it
<mvo> sil2100: its a pain
<pedronis> core build is so byzantine
<mvo> sil2100: I mean, the configs are split between gits
<mvo> sil2100: so we fixed this in the core18 build but sometimes (like now) we still suffer
<mvo> pedronis: indeed
<mvo> sil2100: fwiw https://github.com/snapcore/core-build/tree/master/config/etc/cloud
<pedronis> ah
<pedronis> we have two core related repos?
<mvo> pedronis: yes, sadly - core-build and core
<sil2100> At least it's all known now \o/
<mup> PR core18#105 opened: static: add ds-identify.cfg back <Created by mvo5> <https://github.com/snapcore/core18/pull/105>
<pedronis> mborzecki: when you a little bit of time could you look at https://github.com/snapcore/snapd/pull/5712 , it's long lived but now I finally got to make it green, had to adjust for parallel installs changes
<mup> PR #5712: overlord: make InstallMany work like UpdateMany, issuing a single request to get candidates <Created by pedronis> <https://github.com/snapcore/snapd/pull/5712>
<mborzecki> pedronis: ack
<pedronis> mvo: that config tree seems a bit in the wrong repo to me
<mvo> pedronis: you mean core-build?
<pedronis> yea
<pedronis> if it's basically content of the thing
<mvo> pedronis: this is why I created https://github.com/snapcore/core/pull/83
<pedronis> it should go into core somehow
<mup> PR core#83: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<pedronis> ah
<mvo> pedronis: and then it did not get merged /o\
<sil2100> eeek
 * mvo weeps harder in the corner
<pedronis> it seems definitely a good idea
<mvo> pedronis: I added a card for myself
<sil2100> mvo: SHIP IT!
<pedronis> mvo: sil2100: there's some other bits of cloud/ that might be relevant there btw
<pedronis> I suppose the resize bit is done differently now though
<pedronis> or is that done for clouds?
<pedronis> and we need it?
<mvo> pedronis: we ship https://github.com/snapcore/core18/blob/master/static/etc/cloud/cloud.cfg.d/10_snappy.cfg (ironically)
<pedronis> very
<mvo> pedronis: which is iirc the same as in uc16 - or am I misunderstanding
<pedronis> yes
<pedronis> it's ironic indeed because without cloud-init it would have done nothing
<mvo> pedronis: :(
<mvo> pedronis: so this is why the maybe become a yes?
<pedronis> ?
<mvo> pedronis: what I meant its ironic that we only had half the config. but you indicate that if we had no config at all cloud-init would not have bothered to run?
<pedronis> mvo: sil2100: so it seems we need to port more bits from 16 to static/etc/cloud
<mvo> pedronis: what else is missing?
<pedronis> there's a bit about azure it seems
<mvo> pedronis: pretty sure that is obsolete but worth checking with someone from the cloud team
<pedronis> https://github.com/snapcore/core-build/blob/master/config/etc/cloud/cloud.cfg.d/99-snappy-azure.cfg
<pedronis> sil2100: can you check if we need this ^ or not anymore ?
<pedronis> mvo: ok, probably easiest for sil2100 to do that
<mup> PR core18#105 closed: static: add ds-identify.cfg back <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/105>
<mvo> building a new core18 with the right ds-identify.cfg now
 * mvo also builds 2.36.3 for regular core beta
<mup> PR snapd#6296 closed: tests: new backend used to run upgrade test suite <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6296>
<pedronis> sil2100: are you looking into why core18 CI is red? seems related to the checks for package removal
<zyga> mvo: is new snapd okay but we need changes to core18 or will you do another snapd release to fix the cloud issues?
<pedronis> zyga: the last changes are all just in core18 afaiu
<zyga> great
<mvo> 2.36.3 is now in beta core everything but arm64
<mvo> (the later is still building)
<sil2100> pedronis: I didn't get to fixing them, but I confirmed that they're not real issues - the test env needs fixing, it's on my plate for ASAP
<mup> PR snapd#6309 opened: overlord/ifacestate: addHotplugSeqWaitTask helper <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6309>
<pstolowski> zyga: ^ if you have a moment
<zyga> yep saw it
<zyga> +1
<pstolowski> zyga: +1 on 6288, but plese see the comment
<zyga> pstolowski: applied!
<pstolowski> ty
 * pstolowski lunch
<zyga> mborzecki: something to garden https://bugzilla.redhat.com/buglist.cgi?component=snapd&product=Fedora
<zyga> make sure to select *all* bugs
<mup> PR snapd#6310 opened: interfaces: return security setup errors <Created by zyga> <https://github.com/snapcore/snapd/pull/6310>
<zyga> mvo: found the patch that didn't make it into master https://github.com/snapcore/snapd/pull/6310
<mup> PR #6310: interfaces: return security setup errors <Created by zyga> <https://github.com/snapcore/snapd/pull/6310>
<mvo> zyga: ta
<Chipaca> I need to go to the boys' school for 2pm, meaning I'm not going to be here for the standup (although I should be back by 2.30 so I might see y'all if it extends a bit) (but, traffic, so dunno)
<Chipaca> I'm still working on the epochs rerefresh thing
<zyga> k
<pedronis> Chipaca: ok,  let me know if you have questions or something
<Chipaca> pedronis: another?
 * Chipaca looks
<pedronis> Chipaca: ?
<Chipaca> pedronis: I split one out from Epochs yesterday
<pedronis> Chipaca: forgot to assign it to you?
<Chipaca> pedronis: " make sure to check and trigger new refreshes if there are further transitions available"
<Chipaca> ah, drat, yes
<Chipaca> pedronis: thanks
<pedronis> removing mine, and tweaking yours
<Chipaca> thanks
<Chipaca> and I didn't notice but replied in public to a private message
<Chipaca> hope nobody's too confused :-D
<Chipaca> or at most as confused as i clearly was
<Chipaca> I'm going to have lunch and see if that makes things better :-)
<cachio> mvo, 509 and 510 are the right versions?
<cachio> for arm devices
<mborzecki> pedronis: left one suggestion under https://github.com/snapcore/snapd/pull/5712 otherwise lgtm
<mup> PR #5712: overlord: make InstallMany work like UpdateMany, issuing a single request to get candidates <Created by pedronis> <https://github.com/snapcore/snapd/pull/5712>
<pedronis> mborzecki: thx
 * cachio afk
<zyga> coffee
<mborzecki> wtf is going on with fedora repos?
<zyga> mborzecki: they have holidays too?
<mborzecki> heh
<zyga> I need to go run an errand, brb in 30 minutes
<Son_Goku> oh god, I'm so happy
<Son_Goku> this is my last day of work for 2018
<zyga> I wished :)
<zyga> Son_Goku: I'm iterating on https://github.com/snapcore/snapd/pull/6111
<mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<Son_Goku> zyga, I didn't take much vacation this year, since I only had the one trip for Flock
<zyga> I need to run that errand but the last part is the with/bcond work
<zyga> and then I need to figure out why go is broken in leap again :)
<zyga> afk :)
 * Son_Goku waves
<mborzecki> zyga: the problem with refreshing fedora repos seem to happen only in gcp
<mborzecki> i can refresh just fine here
<zyga> cloudscale problem ;)
<zyga> mborzecki: idea
<zyga> mborzecki: spin up our own mirror
<zyga> try against that
<mborzecki> zyga: heh, hardly sounds like the thing we ought to be focusing on :)
<mvo> cachio: hey, yeah, 508,9 should be the right ones
<mvo> cachio: I will be afk for a bit but looking at tg
<cachio> mvo, good
<zyga> re
<zyga> this took forever, sorry
<zyga> is it just me or is travis stuck?
<pedronis> zyga: we might have hit some limit
<cachio> zyga, hey
<zyga> yes?
<cachio> fedora 29 is taking more time than other systems
<cachio> I saw it is taking time to build snapd
<zyga> any idea why? download speed? more updates than usual?
<cachio> could tha because because it is using go 11?
<zyga> did go 11 got introduced?
<zyga> as otherwise I don't see how go version is a factor
<cachio> not sure when I was introduced
<cachio> but after last update it is taking more time to run fedora29
<zyga> after last update of what?
<cachio> fedora 29
<zyga> of the image?
<cachio> there was a kernel update
<cachio> zyga, yes
<zyga> can you diff the package manifest in the old and the new image?
<zyga> I don't know what changed
<pedronis> zyga: is the description of 6310 up-to-date? didn't we learn that the SIGTERM was coming from systemctl stop snapd ?
<zyga> I also don't have an suspicion what could be a factor
<cachio> zyga, sure
<zyga> pedronis: it's the original patch that got lost in various changes, this is to match the release merge PR that mvo noticed has some delta
<pedronis> zyga: this for master though, right?  so an up-to-date description would be best
<zyga> yes, it is the same patch as before, just proposed in a branch that got closed
<zyga> I can edit the description, sure
<pedronis> thank you
<cachio> pedronis, I'll join in 2 minutes
<thresh> how many snaps in the store are already using core18?
<mvo> cachio: core18 is still not good, it looks like /etc/cloud is not populated (cc sil2100)
<pstolowski> mborzecki: updated #6114
<mup> PR #6114: overlord/ifacestate: handler for hotplug-disconnect task <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6114>
<pstolowski> mborzecki: could you also take a look at the #6309 (simple)
<pstolowski> ?
<mup> PR #6309: overlord/ifacestate: addHotplugSeqWaitTask helper <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6309>
<mborzecki> mhm
<pstolowski> thanks
<cachio> mvo, ouch
<cachio> bad news
<cachio> mvo, I'll run beta validation for 2.36.3
<cachio> until core18 is ready
<sil2100> mvo: huh? Something wipes out the /etc/cloud contents?
<sil2100> mvo: hm, looking into core18 snap's squashfs I see /etc/cloud/ds-identify.cfg
<sil2100> mvo: you don't have it?
<sil2100> mvo: are you sure you're testing the right image/core18 snap?
<sil2100> Let me build a test image and check on my pi3
<mvo> sil2100: if you boot your VM, do you see a populated /etc/cloud ?
<mvo> sil2100: x86 should be enough
<sil2100> Building
<sil2100> mvo: ah, I see what's happening, /etc/cloud is in writable-paths
<sil2100> hmmm
<mvo> sil2100: I have a theory
<sil2100> But it should work
<mup> PR core18#106 opened: static,hooks: make /etc/cloud a "synced" dir for now <Created by mvo5> <https://github.com/snapcore/core18/pull/106>
<sil2100> AH
<sil2100> Holy moly
<mvo> sil2100: the rabbit hole is deeper
<mvo> sil2100: I just added another paragraph
<mvo> sil2100: anyway, I think this is the best we can do for now but we may need to deprecate ubuntu-images --cloud-config option
<mvo> sil2100: or push it into cloud.cfg.d or something
<mvo> sil2100: but even that has config :/
<mvo> sil2100: well, actually I think we need to simply support cloud.cfg and ds-identify.cfg in the gadget
<mvo> sil2100: anyway, the above PR will unblock the world
<zyga> mvo: fun friday, it seems
<sil2100> mvo: ok, this looks good, I'm just wondering - what is creating the empty /etc/cloud directory? Is it part of snap prepare?
<sil2100> Since I don't remember we have anything in ubuntu-image that does that explicitly
<zyga> https://github.com/snapcore/core18/search?q=%2Fetc%2Fcloud&unscoped_q=%2Fetc%2Fcloud
<zyga> sil2100: it is 020-extra-files.chroot
<mup> PR snapd#6311 opened: image: do not write empty etc/cloud <Created by mvo5> <https://github.com/snapcore/snapd/pull/6311>
<mvo> sil2100: yeah, see 6311 (coming in a sec if mup is attentive)
<sil2100> mvo: so maybe it'd be just better to remove that one?
<sil2100> I mean, synced is fine I guess, but maybe we don't have to do it, all we need is to not create that empty dir?
<mvo> sil2100: we could remove it its a good question, removing requires building the images with a snap command build with 6311
<sil2100> ubuntu-image also won't put any files there, the only cloud-init stuff it puts in is the user-data
<sil2100> hm
<mvo> sil2100: snap prepare-image creaets the dir even if its empty
<mvo> sil2100: thats a bug and then u-i puts the empty dir into the writable dir
<mvo> sil2100: of course if we can teach u-i to not copy the empty dir that would be even nicer
<sil2100> Ah, ok
<mvo> sil2100: if you are comfortable with chaning u-i that works for me as well, slightly preferable
<sil2100> mvo: ok, I guess it's just safest to go with synced then, since I see there's multiple places where the dir can pop up
<mvo> sil2100: we still have a problem with gadgets that ship a cloud.conf because we no longer "merge" the configs but I think this is a feature :)
<sil2100> mvo: since as per what zyga pasted we also create the empty /etc/cloud dir in core18 itself
<mvo> sil2100: its fine if its in the core18 snap
<mvo> sil2100: the problem is really that its also in /writable
<mvo> sil2100: and snap prepare-image creates it and then u-i puts it there
<sil2100> Ah, right!
<sil2100> Stupid me
<mvo> sil2100: I can poke a u-i to see if there is a single place to check
<mvo> sil2100: no worries a) its friday b) its complicated
<mvo> sil2100: (not necessarily in this order ;)
<sil2100> mvo: it's certainly possible to do in u-i, no problem
<sil2100> Problem is in releasing u-i again ;p
<sil2100> i.e. not something to be done on Friday
<mvo> sil2100: heh
 * zyga hugs sil2100 and mvo
<mvo> sil2100: as long as cachio can create correct images we can release monday ;)
 * mvo hugs zyga
<mvo> zyga: yeah, fun week so far
 * sil2100 hugs zyga back
<sil2100> mvo: ok, for now I approved the synced MP
<sil2100> I'll prepare a hack for u-i in the meantime
<mvo> sil2100: does the u-i snap embedd the snap command it uses?
<mup> PR core18#106 closed: static,hooks: make /etc/cloud a "synced" dir for now <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/106>
<zyga> so leap 42.3 *does* have new go 1.10
<mvo> sil2100: I take it for now to unblock sergio - if we have something better we can revert without any harm
<zyga> update from 1.9
<sil2100> mvo: I don't think the u-i snap ships snap, I think it uses the system one
<sil2100> I'll double check
<mvo> sil2100: can I become part of the people who can trigger a build in https://code.launchpad.net/~ubuntu-core-service/+snap/core18 ?
<mvo> sil2100: aha, nevermind - autobuild started
<sil2100> mvo: of course you can o/
<mvo> sil2100: fwiw, with an image generated with #6311 cloud-init is disabled so this part is fine
<mup> PR #6311: image: do not write empty etc/cloud <Created by mvo5> <https://github.com/snapcore/snapd/pull/6311>
<mvo> cachio: new coew18 is ready in beta
<cachio> mvo, nice
<cachio> I'll start after lunch
<cachio> still without iternet at home
<cachio> I think I'll need to go to another place
<mvo> cachio: uh, good luck
<sil2100> mvo: ok I have the u-i hack + tests in place, let me give it a spin in a moment
<mvo> sil2100: cool
<mvo> sil2100: \o/
<mvo> sil2100: the "synced" change also works, tests are running on my pi3 and all the stragness is gone (noe more property set-name error in netplan etc)
<sil2100> mvo: it's best to have more options to choose from I suppose ;) And I also think it'd be easier to fast-track ubuntu-image to release pockets than for instance snapd, since our livefs builders use archive packages for building the images
<zyga> cachio: I solved the problem with opensuse leap
<zyga> cachio: I will push a small update soon
<zyga> cachio: but it might be best to refresh all opensuse images
<zyga> though let's do this only after my fix is merged
<cachio> zyga, sure
<cachio> zyga, thanks for that fix
<mvo> sil2100: yeah, I like the idea of doing it in u-i
 * cachio lunch
<cyphermox> mvo: property error for set-name in netplan?
<sil2100> cyphermox: yeah, due to cloud-init meddling with the netplan config in some cases the netplan config ends up with a set-name: without a match:
<sil2100> Like, it's injecting set-name when it shouldn't
<cyphermox> yeah, ok
<cyphermox> sil2100: to me "when it shouldn't" for set-name is pretty much always
<cyphermox> I feel strongly like it's something that should be avoided at all costs, and kind of sad that it got in, because it's often a cause for confusion :(
<sil2100> mvo: https://github.com/CanonicalLtd/ubuntu-image/pull/167 <- seems to work
<mup> PR CanonicalLtd/ubuntu-image#167: Do not copy-over /etc/cloud to the rootfs if it's empty <Created by sil2100> <https://github.com/CanonicalLtd/ubuntu-image/pull/167>
<sil2100> mvo: I'd like to wait for the autopkgtests to run for those
<sil2100> s/those/this PR
<mvo> sil2100: nice one
<mvo> sil2100: btw, can you commit to https://github.com/snapcore/core18 now? if not we need to ask niemeyer  to give you commit access
<mvo> sil2100: I slightly prefer your u-i workaround, if thats ok with you and if we can give cachio a way to create the images I'm +1 on this one and we can revert the core18 commit that uses a synced dir
<niemeyer> mvo: sil2100 should have access, as long as he accepted the invitation to join the team
<mvo> sil2100: but no super strong opinion, synced is also easy to change later it won't do any harm
<sil2100> mvo: so I'd still keep the synced writable-path for now until I push out a new ubuntu-image - I guess it might be enough for us to have it in disco, then I guess it should go relatively fast
<sil2100> mvo: not sure if we built core18 images before on disco
<sil2100> (like, on the disco livefs)
<mvo> sil2100: ok
<mvo> sil2100: I leave this to you then
<mvo> sil2100: thanks, fwiw, tests on the pi look good now still
<sil2100> \o/
<zyga> cachio: on second thought
<zyga> cachio: please run "zypper refresh && zypper update" on all suse images
<zyga> cachio: the fix is really equivalent to doing that and rebooting :/
<zyga> so we may just as well do that
<kyrofa> Hey zyga, did you have any other thoughts on https://forum.snapcraft.io/t/raspberry-pi-3-install-broken/8957/5 ?
<zyga> kyrofa: I bet a beer that it's either ENOSPC or EROFS after ext4 corruption on flaky sd card
<kyrofa> zyga, want me to suggest trying another SD card?
<zyga> We should first get full logs from systemd
<zyga> I don't think we got an answer since yesterday
<kyrofa> Indeed, we have not
<kyrofa> I'll go ping him on another forum :P
 * zyga EODs
<zyga> I'll check my PRs later
<zyga> I love how this page looks like for communicating features to users https://github.com/github/VisualStudio/issues/1878
<sil2100> mvo: ok, autopkgtests were happy with the branch, let me push it out to the archive
<sil2100> mvo: I'll make it an interim release, e.g. not 1.6 per-se
<sil2100> Actually hmm, I anyway need to get those changes out
<sil2100> mvo: ubuntu-image 1.6 pushed to disco, SRUs to other series will follow
<diddledan> can I specify something in snap.yaml (using snapcraft's passthrough) that will match the arch-triplet of the current system so that I can move $SNAP/usr/lib/$ARCH_TRIPLET/webkit2gtk-4.0 to /usr/lib via bind mount without adding every arch separately?
<zyga> not using passthrough
<diddledan> I obviously mean bindmounting it to /usr/lib/$ARCH_TRIPLET/webkit2gtk-4.0
<diddledan> and I'm referring to using layouts
<zyga> snapd doesn't support arch triplet because it's distro specific
<zyga> we tried to and abandoned that
<zyga> only snapcraft does
<diddledan> so how do I do this?
<zyga> manually
<zyga> not sure
<zyga> using snapcraft?
<zyga> why are you using passthrough?
<diddledan> for layouts
<zyga> you can use layouts now without that
<diddledan> layout isn't supported by snapcraft yet
<zyga> it is
<diddledan> nope
<zyga> yep
<zyga> since 3.0
<zyga> but
<zyga> for unknown reason you need to start using "base: core18"
<zyga> while technically not required
<zyga> it's a snapcraft bait and switch
<diddledan> well that's silly
<diddledan> :-p
<zyga> I don't disagree :)
<zyga> it would not be silly if we had shipped core16
<zyga> and you could just say "base: core16"
<zyga> "layouts: ..."
<zyga> now it is silly
<zyga> mvo: if you are working by any chance
<zyga> could we ship core16 base snap alongside core18?
<diddledan> hah: "You need multipass installed to build snaps which use the base keyword" <-- I've already got it!
<diddledan> oh!
<diddledan> it's trying to install multipass inside a multipass vm because I accidentally left SNAPCRAFT_BUILD_ENVIRONMENT=multipass in the environment
<diddledan> turtles all the way down
<pedronis> zyga: we really don't want to push core16 much yet
<zyga> pedronis: then we should not marry core18 with layouts in snapcraft IMO
<pedronis> zyga: did I say we should
<zyga> we do :)
<zyga> or did
<pedronis> also for clarity: core16 is not stable yet
<diddledan> well blow me down with a feather! you're right, using base:core18 does indeed enable layout: to work
<pedronis> fedora tests are a mess atm
<diddledan> yey?
<zyga> pedronis: shall I disable it?
<pedronis> zyga: maybe, it's causing a lot of red atm
<zyga> on it
<cachio> sil2100, hey, still don't have internet at home
<cachio> sil2100, I'll make the validation over the weekend and I'll send the results
<zyga> pedronis: done
<cachio> so we can continue to stable
<mup> PR snapd#6312 opened: spread: disable fedora-29-64 <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6312>
<pedronis> cachio: if you are sending out mails about the results, please cc also me
<pedronis> thank you
<pedronis> zyga: thx, let's see if that one gets green
<cachio> pedronis, sure
<cachio> I think I'll send the results tomorrow
<cachio> pedronis, today I am using my phone internet and it goes so slow
<sil2100> cachio: thanks!
<cachio> zyga, opensuse update failed
<cachio> zyga, https://paste.ubuntu.com/p/pC9bphSTgr/
<cachio> using master
<zyga> cachio: this error shows up when you update and not reboot
<mvo> zyga: we talked about this, ideally we would just make core an alias for core16 in snapd
<mvo> zyga: so that snapd understands that it just needs core for this
<zyga> mmm
<zyga> mvo: anyway, not urgent
<zyga> mvo: I'm trying to land https://github.com/snapcore/snapd/pull/6312
<zyga> if you want to look
<zyga> it should help
<mup> PR #6312: spread: disable fedora-29-64 <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6312>
<mvo> zyga: sure
<zyga> ha
<zyga> you were faster
<mup> PR snapd#6312 closed: spread: disable fedora-29-64 <â  Critical> <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6312>
<pedronis> it's merged
<zyga> thank you :)
<zyga> I restarted a few PRs
<zyga> let's see
<zyga> mvo: I left a few comments on https://github.com/snapcore/snapd/pull/5845
<mup> PR #5845: interface: add new `{personal,system}-files`  interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/5845>
<zyga> not sure if you want to do anything about it
<zyga> or just merge it
<zyga> it's green
<roadmr> ohai zyga
<zyga> hey :)
<roadmr> how's it going? is the glue trick keeping you safe from spaghetti?
<zyga> haha
<zyga> yes!
<zyga> it's a miracle
<zyga> printing on 1st go
<zyga> I'm shocked
<roadmr> great! how do you unglue the piece from the bed when it's done?
<zyga> should have learned this months ago
<zyga> the bed comes off and you just bend it slightly
<zyga> things pop off without any issues
<roadmr> zyga: how'd you find out about this?
<zyga> about the glue?
<zyga> read that it helps
<zyga> found some information on the internet by chance
<roadmr> interesting, sounds like it'd be a very well-known fact, as I think it's a common problem
<roadmr> glad it's working well now :)
<roadmr> zyga: hey a snapd-related question - you may know and save me hours of dredging through the code base
<zyga> it may be well known, I'm happy I know it too :)
<zyga> how can I help?
<roadmr> zyga: do you remember at some point, snap deltas were disabled for armhf devices because $REASONS?
<zyga> because CPU uber slow
<roadmr> zyga: hm, and were they enabled at some point? or are armhf devices still delta-less?
<zyga> I don't know that
<zyga> I don't know how the delta was disabled
<roadmr> zyga: ok.. I found something about enabling deltas for core devices, back in February, but that seems to be arch-agnostic
<roadmr> zyga: ok, no problem - thanks! maybe I'll ask ogra whom I remember talked about this at some point
<ogra> roadmr, they were in fact not enabled in the beginning because nobody had measured the performance for single core arm, but Chipaca did some research at some point, i thought they were enabled later on
<roadmr> hi ogra ! yes, sorry, as I'm here grilling you guys I'm also analyzing download logs and it looks like they were enabled at some point; I'm trying to determine when (basically which version of snapd did that). For instance, I see some armhf devices with  2.35 getting deltas, while others with 2.32 seem to not get deltas
<roadmr> ogra, zyga : if I can pinpoint the version that enabled this, I can tell the guy using that old 2.32 to upgrade to 2.3x so they can benefit from awesome bandwidth savings for free
<roadmr> if Chipaca is the one who did it, I can ask him on Monday; I'm in no rush :)
<mup> Bug #1808593 opened: AppArmor denies ptrace for ufw snap in lxc after purging ufw <Snappy:New> <https://launchpad.net/bugs/1808593>
<mup> Bug #1808593 changed: AppArmor denies ptrace for ufw snap in lxc after purging ufw <snapd:New> <https://launchpad.net/bugs/1808593>
<mvo> zyga: I want to address the comments but not today :) thanks for those!
<pedronis> roadmr: it was done in february, not by John
<roadmr> pedronis: https://github.com/snapcore/snapd/pull/4639 ?
<mup> PR #4639: store: enable deltas for core devices too <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4639>
<pedronis> yes
<roadmr> pedronis: and that went out in snapd 2.33.1?
<thiras> I'm getting "ENOENT: no such file or directory, lstat '/snap/code'"
<thiras> at the vscode
<thiras> any idea what is this?
<pedronis> roadmr: 2.33 already if I believe the changelog
<roadmr> pedronis: yay thanks
<pedronis> roadmr: yes, 2.33
<roadmr> pedronis: great! thanks for helping confirm.
<roadmr> this matches what I see in logs, btw
<roadmr> thanks for the help folks, I appreciate it, I know it's late for you
<mup> PR snapd#6288 closed: cmd/snap-confine: refactor call to snap-update-ns --user-mounts <Per-user mount ns  ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6288>
<mup> PR snapd#6307 closed: systemd/systemd.go: add missing tests for systemd.IsActive <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6307>
<mup> PR snapd#6309 closed: overlord/ifacestate: addHotplugSeqWaitTask helper <Hotplug ð> <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6309>
<mup> PR snapd#6263 closed: Retrieving all pages for 'find' command, not only one <Created by WiseRaccoon> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6263>
<thiras> is there a way to check if a local snap file (not downloaded from Canonical) has right to access to disk?
#snappy 2018-12-15
<diddledan> eh? cannot update snap namespace: cannot write to "/usr/lib/i386-linux-gnu/alsa-lib" because it would affect the host in "/usr/lib/i386-linux-gnu"
<diddledan> the whole point of using a layout is to not affect the host, damn you snapd
<diddledan> thiras: mount it and look in $mountpoint/meta/snap.yaml
<thiras> diddledan, i've found --jailmode
<mup> PR snapd#5712 closed: overlord: make InstallMany work like UpdateMany, issuing a single request to get candidates <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5712>
<mup> PR snapd#6308 closed: release: 2.36.3 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6308>
<mup> PR snapd#6310 closed: interfaces: return security setup errors <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6310>
<zyga> diddledan: hey
<zyga> diddledan: can you show me your layout definition?
<zyga> diddledan: the error looks fishy
<diddledan> zyga: https://www.irccloud.com/pastebin/eNRyBgLX/
<diddledan> installation from a clean slate works fine. as does a second installation (x2). it only fails on the third time (x3)
<diddledan> zyga: running /usr/lib/snapd/snap-discard-ns allows the third try to succeed, but obviously that's less than desirable
<zyga> diddledan: thank you, looking
<mup> PR snapd#6217 closed: tests: reset snapd state on tests restore <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6217>
<mup> PR snapd#6071 closed: ifacestate/hotplug: updateDevice helper <Hotplug ð> <Simple ð> <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6071>
<mup> PR snapd#6114 closed: overlord/ifacestate: handler for hotplug-disconnect task <Hotplug ð> <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6114>
<zyga> diddledan: please report a bug on snapd. I will attack this on Monday. Do include snap version and the pastebin please
#snappy 2018-12-16
<mup> PR snapd#6313 opened: WIP: tests: add a test for xdg-desktop-portal filechooser integration <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6313>
#snappy 2019-12-09
<mborzecki> morning
<zyga> mborzecki: hey :)
<mborzecki> zyga: hey hey
<zyga> how was your weekend?
<zyga> mborzecki: easy landing https://github.com/snapcore/snapd/pull/7867
<mup> PR #7867: tests: fix fwupd version regular expression <Simple ð> <â  Critical> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7867>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7864 needs love
<mup> PR #7864: cmd/snap-mgmt, packaging/postrm: stop and remove socket units when purging <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7864>
<mup> PR snapd#7867 closed: tests: fix fwupd version regular expression <Simple ð> <â  Critical> <Created by cmatsuoka> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7867>
<mborzecki> zyga: do you know the backstory of https://github.com/snapcore/snapd/pull/7865 ?
<mup> PR #7865: travis-ci: add go import path <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7865>
<zyga> mborzecki: no idea but probably allows one to travis a fork
<mborzecki> zyga: https://golang.org/cmd/go/#hdr-Remote_import_paths
<mborzecki> hm, why didn't that fail on < 19.04
<mup> PR snapd#7854 closed: snap-confine: raise egid before calling setup_private_mount() <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7854>
<sdhd-sascha> hello :-)
<zyga> hey sdhd-sascha
<mup> PR snapd#7840 closed: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 2 <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7840>
<sdhd-sascha> zyga: I'm not sure if it made sense to split the travis jobs. Maybe they were summarized because of the total build-time. And it is difficult to get a free build slot on the online travis-platform...
<zyga> sdhd-sascha: yeah, it's a weird limitation; I don't know if your PR should be merged or not yet. I think sergio should review it
<zyga> mborzecki: can you please review https://github.com/snapcore/snapd/pull/7129
<mup> PR #7129: userd: allow setting default-url-scheme-handler <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129>
<sdhd-sascha> zyga: but the gopath import would be nice. Because with it, it's possible to build on own github/travis account, before PR
<zyga> it's pretty old and I think nobody looks at it
<zyga> mborzecki: thinking about https://github.com/snapcore/snapd/pull/7205
<mup> PR #7205: rfc: introduce confinement options failsafe flag <Created by zyga> <https://github.com/snapcore/snapd/pull/7205>
<zyga> what can we do to make it landable?
<mborzecki> zyga: hmm so the snap-mgm test fails bc there's lxd socket unit, turns out the socket units are there base image
<zyga> ok, let's filter those out then
<pstolowski> morning
<zyga> hey :)
<mup> PR snapd#7866 closed: travis-ci: split integration tests into parts (>4MB log limit) <Created by sd-hd> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7866>
<mup> PR snapd#7868 opened: Revert "travis-ci: split integration tests into parts (>4MB log limit)" <Created by mvo5> <https://github.com/snapcore/snapd/pull/7868>
<mborzecki> pstolowski: mvo: hey
<mvo> hey mborzecki
<mup> PR snapd#7868 closed: Revert "travis-ci: split integration tests into parts (>4MB log limit)" <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7868>
<mup> PR snapd#7862 closed: release: 2.42.5 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7862>
<mborzecki> zyga: heh, updated #7864
<zyga> mmm, looking
<mup> PR #7864: cmd/snap-mgmt, packaging/postrm: stop and remove socket units when purging <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7864>
<zyga> aha
<zyga> smart
<zyga> nice
<pstolowski> mborzecki: going to review your seccomp branch this morning
<mborzecki> pstolowski: cool, thank you!
<zyga> pstolowski: can you do a pass over https://github.com/snapcore/snapd/pull/7863
<mup> PR #7863: interfaces/builtin: add uio interface <Created by zyga> <https://github.com/snapcore/snapd/pull/7863>
<pstolowski> zyga: yes, sure
<mvo> sdhd-sascha: hey, re 7866 - I accidently merged it but it was not reviewed yet so I reverted it again. please just reopen (or I can reopen). sorry for this! fwiw, we only hit the 4mb limit under certain circumstances of failing tests. not sure we want to split generally - the downside of a general split is that we only have a fixed amount of travis slots aiui so it may slow things down
<mborzecki> ha, wireguard has landed in mainline
<zyga> coffee and 1-2-1 prep
<zyga> ttyl
<sdhd-sascha> mvo: no problem.
<mvo> sdhd-sascha: thank you!
<sdhd-sascha> mvo: could you test the PR with the go import path? with them it was possible to build snapd on my own repo and travis
<mvo> sdhd-sascha: could you please merge it on master or rebase it on master - there was a bug in master that caused the integration tests to fail which got fixed this morning. this should make the test green.
<sdhd-sascha> mvo: so anybody can test building before any PR.
<mvo> sdhd-sascha: also could you please elaborate a little bit on this works? it sounds very cool!
<sdhd-sascha> mvo: what should i merge?
<mvo> sdhd-sascha: just fetch the lastest upstream from snapd and merge master into your PR. I'm happy to do this for you if you prefer
<sdhd-sascha> mvo: sure, but i'm also new on travis ;-) i'm just googling for a solution ...
<mvo> sdhd-sascha: I see :)
<sdhd-sascha> mvo: ok
<mvo> sdhd-sascha: so with 7865, what would I have to do to run my forked branch? what steps to follow etc :) ? (does my question make sense?)
<mborzecki> mvo: as i understand, you'll be able to run the travis job on your private fork
<sdhd-sascha> mvo: with 7865. just add the go_import_path, and add your repo under "MyRepositories" on travis. Then manually build on travis or wait on the next git push
<sdhd-sascha> mborzecki: right
<zyga> re
<sdhd-sascha> I will now merge master on my pull-request. Can somebody please cancel my travis-jobs ? I wait until it works my private repo first.
<zyga> sdhd-sascha: jobs auto-cancel on push
<sdhd-sascha> ...on my private repo
<sdhd-sascha> zyga: ?
<zyga> no, on your private repo you can cancel them
<zyga> I was talking about the snapd repo
<sdhd-sascha> zyga: I'm too. I won't waste your build time
<sdhd-sascha> don't want
<Eighth_Doctor> mborzecki, zyga : do either of you know what's going on here? https://bugzilla.redhat.com/show_bug.cgi?id=1780712
<Eighth_Doctor> it seems like snapd doesn't know how to read the path properly...
<mborzecki> Eighth_Doctor:  it's sudo dropping env
<zyga> Eighth_Doctor: the keyword is sudo
<Eighth_Doctor> blech
<Eighth_Doctor> I was afraid of that
<zyga> try sudo env
<zyga> I need to jump to a meeting
<mborzecki> Eighth_Doctor: https://forum.snapcraft.io/t/centos-7-error-system-does-not-fully-support-snapd-cannot-read-the-value-of-fs-may-detach-mounts-kernel-parameter/14392/5
<sdhd-sascha> would "sudo -E" help ?
<sdhd-sascha> """-E, --preserve-env            preserve user environment when running command"""
<mborzecki> sdhd-sascha: iirc the security policy will still drop your current $PATH
<mborzecki> sudo -i should work though
<sdhd-sascha> mvo: is there a reopen button on github for 7866, or should i opened a new pr
<zyga> re
<mvo> sdhd-sascha: I think you need to open a new PR
<mvo> sdhd-sascha, mborzecki thanks for explaining how 7865 works
<zyga> Eighth_Doctor: do you think the proposed solution in https://bugzilla.redhat.com/show_bug.cgi?id=1691996 is workable?
<zyga> Eighth_Doctor: btw, I need to thank you for excellent maintenance of snapd in Fedora. I've been using Fedora for a few weeks on my daily driver and it's nothing short of excellent
<zyga> Eighth_Doctor: it really helps me to develop cgroupv2 features
<mup> PR snapd#7869 opened: travis-ci: split integration tests into parts (>4MB log limit) <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7869>
<sdhd-sascha> mvo: i had to reapply the commit, because of the revert
<mvo> sdhd-sascha: yeah, again, sorry for the trouble :( won't happen again
<mup> PR snapd#7853 closed: [RFC] boot,bootloader: setup the snapd_recovery_kernel grubenv <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7853>
<mborzecki> zyga: will you be pushing fixes to 7129?
<zyga> checking
<zyga> what kind of fixes?
<mborzecki> zyga: just added a bunch of comments, but i can push the fixes too if you're busy with somehting else
<zyga> mborzecki: you forgot to click send
<zyga> there are no new comments
<mborzecki> zyga: try refreshing
<zyga> mborzecki: did
<zyga> again
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/7129#pullrequestreview-328794160
<mup> PR #7129: userd: allow setting default-url-scheme-handler <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129>
<zyga> wow, now I see them
<mborzecki> haha ;)
<zyga> man, eventually consistent my ass
<zyga> yeah, go for it
<zyga> thank you for looking
<mborzecki> ok
<mborzecki> trivials anyway ;)
<zyga> feels like something close
<zyga> I'll jump back into https://github.com/snapcore/snapd/pull/7625
<zyga> to get it unblocked
<mup> PR #7625: cmd/snap-confine: stop being setgid root <Created by zyga> <https://github.com/snapcore/snapd/pull/7625>
<mborzecki> but really, the desktop stuff is like duct tape and glue all the way
<pedronis> mborzecki: notice that 7129 is blocked on jdstrand review
<zyga> mborzecki: yeah
<mborzecki> pedronis: right, i can ping jdstrand_ in case he missed it (though i'm sure it's in his queue)
<pedronis> it's in his queue
<mup> PR snapd#7768 closed: interfaces: add raw-volume interface for access to partitions <â Blocked> <Created by jdstrand> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7768>
<mup> PR snapd#7768 opened: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768>
<ijohnson> morning folks
<zyga> hey ijohnson
<ijohnson> hey zyga
<mvo> hey ijohnson
<ijohnson> mvo: did you see my comment on the SU doc? I didn't make it very far in updating the grub.cfg.normal for the UC20 pc gadget, also I had it in my notes that grub.cfg.recovery was the ubuntu-seed partition but reading through it, I think grub.cfg.recovery is for ubuntu-boot no?
<ijohnson> reading the grub.cfg specifically
<pedronis> ijohnson: recovery goes to ubuntu-seed and *not* recovery goes to ubuntu-boot
<ijohnson> pedronis: Hmm that's not how it's written now though, the grub.cfg.recovery is currently doing the chainloading to the recovery system grub IIUC
<pedronis> ijohnson: sorry, we are talking different things
<ijohnson> sure, it is like 4 am here so not surprised I have something confused :-)
<pedronis> ijohnson: that should happen only for mode != run
<pedronis> not saying that is what happens right now, neither are definitive
<pedronis> or close to that
<mvo> ijohnson: I have not yet, will look at it next, sorry!
<pedronis> which is part of the problem
<pedronis> ijohnson: I mean in run mode we should chain from ubuntu-seed recovery grub into ubuntu-boot grub
<ijohnson> mvo: no problem just wanted to make sure you were aware if you needed someone else to work on this before Wednesday
<mvo> ijohnson: yeah, that's fine, I figured :)
<pedronis> the recovery systems should really play a role only if mode != run
<mvo> ijohnson: hope the trip was fine?
<ijohnson> pedronis: yes I understand that part, I'm just a bit confused which grub file in the repo corresponds to which partition
<pedronis> ijohnson: recovery should correspond to seed, and the other to boot
<pedronis> if it's the other way around right, things are more messed up than I thought
<ijohnson> mvo: actually I found a flight this morning so I'm at the airport waiting for my flight (hence being up at 4 am)... Hopefully the trip is fine it's currently snowing and we're supposed to get like 10 cm+ of snow this morning
<mvo> ijohnson: uh! good luck!
<ijohnson> pedronis: it's possible I am wrong about what it's currently doing but the recovery grub seems to be doing the logic to look for a recovery system to boot into
<mvo> ijohnson: also - 4am sounds brual
<mvo> ijohnson: brutal :)
<mvo> ijohnson: was wonder about the early time :)
<pedronis> ijohnson: that's exactly what I would expect for seed
<pedronis> seed == recovery
<ijohnson> pedronis: right that's why I was confused as well
<ijohnson> Err wait sorry I misread
<pedronis> it looks correct, maybe there is no run mode logic there yet
<pedronis> I don't know
<pedronis> it's all part of the problem
<mvo> I think there is no run mode logic in the recovery grub yet
<ijohnson> pedronis: why would the seed recovery system grub need to look for all the other recovery systems? Is that by design that you can switch between recovery systems using grub? I guess that kinda makes sense now thinking about it
<ijohnson> mvo: yeah it's a _bit_ early :-)
<pedronis> mvo: ah
<mvo> pedronis: it's something to discuss with xnox today
<zyga> brb, cold, going to make tea
<mborzecki> pstolowski: thanks for the comments, updated #7821
<mup> PR #7821: interfaces/seccomp: parallelize seccomp backend setup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7821>
<mup> PR snapd#7864 closed: cmd/snap-mgmt, packaging/postrm: stop and remove socket units when purging <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7864>
<pstolowski> yw, thanks for the PR!
<zyga> re
<mup> PR snapd#7870 opened: boot,bootlaoder: setup the snap recovery system bootenv <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7870>
<zyga> pstolowski: good catch, mborzecki https://github.com/snapcore/snapd/pull/7821#discussion_r355405488
<mup> PR #7821: interfaces/seccomp: parallelize seccomp backend setup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7821>
<zyga> sdhd-sascha: https://github.com/snapcore/snapd/pull/7865#pullrequestreview-328870384
<mup> PR #7865: travis-ci: add go import path <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7865>
<mborzecki> zyga: already been addressed
<zyga> mborzecki: thanks
<pstolowski> zyga, pedronis did you want jdstrand_ 's review on https://github.com/snapcore/snapd/pull/7830 or can it land?
<mup> PR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830>
<zyga> not really but I think it's short and would be good to keep him in the loop
<pstolowski> zyga: sure
<sdhd-sascha> zyga: just started a new build on my repo
<zyga> sdhd-sascha: you don't need to use repo builds you know
<sdhd-sascha> zyga: could you see, this build from me ? : https://travis-ci.org/sd-hd/snapd/builds/621989511
<zyga> there are faster ways to iterate
<zyga> you can just use spread on a local system
<sdhd-sascha> zyga: kitchen was on my plan
<sdhd-sascha> zyga: kitchen is local travis
<sdhd-sascha> zyga: the build above, from weekend. has this patch and only debian sid is failed. all others are green
<mup> PR snapd#7850 closed: apparmor: allow 'r' /sys/kernel/mm/transparent_hugepage/hpage_pmd_size <Simple ð> <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7850>
<pedronis> zyga: any blockers to merge #7228 ?
<mup> PR #7228: interfaces: add audio-playback/record and pulseaudio spread tests <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7228>
<zyga> pedronis: checking
<sdhd-sascha> zyga: i do more tests, i will report
<zyga> pedronis: I think it's good
<mup> PR snapd#7871 opened: tests: add spread test for hook permissions <Created by stolowski> <https://github.com/snapcore/snapd/pull/7871>
<mup> PR snapd#7228 closed: interfaces: add audio-playback/record and pulseaudio spread tests <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7228>
<vidal72[m]> zyga: this possibly will be in linux 5.6 https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git/commit/?h=work.openat2&id=b767b87044c4b15c4f222daf6948a7a43f802f7e
<zyga> yeah, I noticed on twitter yesterday
<zyga> along with the new mount APIs it's great to see those
<zyga> I don't have a clear vision of how to adopt such new APIs in snapd
<zyga> as we will likely support the old APIs for foreseeable future
<pedronis> zyga: I pushed something to #7768, let me know whether it is what you expected
<mup> PR #7768: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768>
<zyga> looking
<zyga> pedronis: looks great, thanks
<pedronis> zyga: I am a bit confused by https://github.com/snapcore/snapd/pull/7768/files#r355413333, that's a go regexp, not something we feed apparmor
<mup> PR #7768: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768>
<zyga> oh, did I misunderstand that
<zyga> uff
<zyga> sorry
<zyga> I didn't notice that
<zyga> I just noticed composition and was worried
<zyga> commented
<pedronis> given that hotplug is for follow up (and we don't have an immediate use case), I think it can land if it gets green
<zyga> I agree
<zyga> hotplug is should be more careful, it's not as easy as uio as it is fairly dynamic in nature
<zyga> and covers a wide variety of cases
<zyga> but I think it's a natural case to attempt
 * zyga small break
 * Chipaca lunch
<mup> PR snapd#7872 opened: doc: HACKING.md change autopkgtest-trusty-amd64.img name <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7872>
<sdhd-sascha> Can anybody stop my Travis-Build for modifying "HACKING.md" ?
<pedronis> pstolowski: what's the status of this: https://bugs.launchpad.net/snapd/+bug/1849564
<mup> Bug #1849564: snap connections doesn't work as expected when interface attributes change <snapd:Confirmed for stolowski> <https://launchpad.net/bugs/1849564>
<pedronis> mvo: zyga: I think we have finally fixed this: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1814141 ?
<mup> Bug #1814141: fail to run any snap after snapd refresh, reinstalling snapd from the archive is a temporary fix <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1814141>
<pedronis> mvo: I suppose this should be closed somehow at this point: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1739494
<mup> Bug #1739494: snapd 2.29.4.2 is not installable on powerpc <regression-update> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1739494>
<mvo> pedronis: totally
<pstolowski> pedronis: it's probably another case of  https://bugs.launchpad.net/bugs/1848516 (as suggested in the report) but i'd need to double check if it's fixed too. note that in the bug report the plug name was changed, that's why it's the same problem (i think). if it was just attributes change, then i think we would hit the (known) problem of stale attributes on refresh that we only fixed for content interface
<mup> Bug #1848516: snap connections/interfaces shows dropped interfaces as connected after refresh <snapd:Fix Committed by stolowski> <https://launchpad.net/bugs/1848516>
<mup> PR snapd#7873 opened: image: set recovery system label when creating the image <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7873>
<pedronis> mvo: is it won't fix or fix released?
<stgraber> mvo: how are things going with getting 2.42.5 rolled out?
<mvo> stgraber: looking good, we are waiting for the cert team right now to give us a +1 for moving to candidate, cachio  has the details on where we stand here
<jdstrand_> pedronis: please don't land 7768 yet. some of the changes that went in I want to change
<pedronis> jdstrand: you'll have to tell me more
<pedronis> jdstrand: which of the changes?
<pedronis> jdstrand: the test changes or the path changes
<jdstrand> pedronis: in ijohnson's comment, there needed to be a change, but not to rip out the mmc and vda1
<pedronis> jdstrand: they aren't used
<jdstrand> pedronis: I know. that is what needed to change, to use them, not to remove them
<pedronis> jdstrand: the code doesn't care where the slot come from
<pedronis> so not sure what difference it would make
<pedronis> jdstrand: I mean, I follow up sounds ok, I don't think anything fondumental is untested at this point
<jdstrand> I picked those 3 paths specifically so make sure it worked in the normal case, the requested mmc case and the i2o case
<jdstrand> the tests aren't done yet so I'd like to add it back
<jdstrand> plus, I don't understand the s#vda1#vda1/# change
<jdstrand> I only am just looking at it, but I want to understand why that was changed before committing
<pedronis> jdstrand: that tests the Clean
<pedronis> it wasn't tested
<pedronis> and zyga asked about it
<pedronis> we are actually likely missing tests about that for other interfaces that also have a Clean fwiw
<pedronis> jdstrand: anyway I don't see any fundamental blockers, but of course more testing is alway appreciated
<jdstrand> pedronis: now I'm rethinking that clean is there at all. the regex is very precise
<jdstrand> that clean should be there*
<pedronis> jdstrand: as I said to zyga all the other interfaces like this one do that
<pedronis> the Clean
<pedronis> so it would be incosistent not to have it at this point
<pedronis> jdstrand: see serial-port or spi
<pedronis> etc
<pedronis> I don't know what it was decided to do it that way
<pedronis> s/what/why/
<jdstrand> pedronis: yeah, but maybe that is wrong. why would we allow /dev/././././vda1////////
<pedronis> jdstrand: we cannot simply change it, you would need to start with warning in review-tools
<pedronis> for the old ones
<jdstrand> pedronis: well, I'm talking about this one
<pedronis> it's a well defined process, clean and then check
<pedronis> and consistency is important
<jdstrand> but consitently wrong?
<pedronis> I didn't make the initial decision
<jdstrand> it is not a bad pattern in general
<jdstrand> just conceptually
<jdstrand> but seeing /dev/vda1/ - that is not what we want to allow
<pedronis> jdstrand: but we do allow it
<jdstrand> there are things, like i2o, that are a subdir
<jdstrand> /dev/i2o/
<pedronis> that's the code you wrote
<pedronis> I just refactored it
<jdstrand> pedronis: yes, and I am rethinking that after seeing the test for /dev/vda1/
<pedronis> jdstrand: ok, but then you need to give a list of other interfaces you think we ideally should remove the Clean
<jdstrand> of course, /dev/i2o/ going to /dev/i2o doesn't match the regex, but still
<pedronis> because is everywhere atm
<pedronis> which is probably why you also put it in the first place
<jdstrand> it is, I copied an existing over as a template
<Chipaca> nice 500s from the forum
<pedronis> jdstrand: what I'm saying, you either convince me it's exactly a problem only for the new one, or which it is, and  a path forward
<jdstrand> pedronis: we should've been doing if path != filepath.Clean(path) err
<pedronis> just changing it for this one feels arbitrary
<jdstrand> well, bugs happen. sometimes you only notice after a while
<jdstrand> I just noticed this
<jdstrand> I'm not sure consistency is a reason to add another one
<pedronis> that's ok, but we still need a path forward for everything
<pedronis> also because otherwise we'll get there again
<pedronis> jdstrand: 1 thing doing it one way, and 5 another is not a pattern
<jdstrand> pedronis: I'm not saying that none of them can or can't change, but my point of 5 historical and everything else going forward as correct is a pattern. the 5 historical can be documented in the code
<Chipaca> what's the problem with 'path != filepath.Clean(path)'?
<pedronis> Chipaca: that all the previous interfaces don't do that
<jdstrand> Chipaca: the potential issue is that we might break existing snaps
<Chipaca> ah
<Chipaca> k
<jdstrand> (if we change the existing ones)
<pedronis> Chipaca: we cannot just change it for old interfaces
<pedronis> without going to some review-tools long warning phase
<pedronis> or something
<jdstrand> fyi, common files uses if p != np {
<jdstrand> so does content
<jdstrand> bool does not
<zyga> re
<jdstrand> neither does hidraw, i2c, iio, serial-port or spi
<pedronis> to be clear this has path, so the closest are the ones useing a path attribute
<zyga> jdstrand: did snapd solve p != np?
<zyga> ;D
<zyga> I'll grab lunch and be back
<zyga> do I need to read the backlog?
<jdstrand> so, content, personal-files and system-files use !=, and bool, hidraw, i2c, iip, serial-port and spi just feed the cleaned path through the regex
<pedronis> jdstrand: as I said from attribute used (path), this belong to the latter set
<jdstrand> the first three don't have an attribute named 'path'
<pedronis> jdstrand: which 3 ?
<jdstrand> pedronis: now that I've seen it. I'm uncomfortable adding this to raw-volume. I disagree we should for consistency. I see your point about content, personal-files and system-files (ie, the first three) not having a "path" attribute, but they are effectively the same an imo should be considered
<jdstrand> pedronis: I don't see how to move existing over in a very acceptable manner. it is your prerogative to say no to me
<jdstrand> pedronis: what I could do is fix raw-volume and then add to all the others a code comment explaining that the pattern is historical
<jdstrand> pedronis: that is probably the best I can do barring a long drawn out migration
<pedronis> jdstrand: ok, we probably want to think how to change those but is not trivial
<pedronis> they have been like that since a long time
<jdstrand> yeah
<jdstrand> pedronis: I'm not sure where we stand. I think you said fix raw-volume to use != (and while you didn't say it, I'll do a followup pr to add a code comment to the others and a test verifying the current behavior). if that isn't what you meant, please let me know what you want
<pedronis> jdstrand: what I would prefer is also that we make the path function a helper in utils, so there's a chance that we can use it again for similar new cases
<pedronis> jdstrand: also probably all the comments in the old code needs to point to raw-volume and or this helper
<jdstrand> pedronis: something like where the api is pathHelper(path, regex) (name tbd)?
<pedronis> well it can take the slot etc
<pedronis> but whatever works
<pedronis> jdstrand: look at the helper as it exist now
<jdstrand> pedronis: gotcha. ok, I'll do that in a followup PR
 * zyga -> afk
<ijohnson> pedronis: jdstrand: could you do the store check thing to see a full listing of all the paths that folks are using for these slots? If nobody's using a non-clean path then you could make the change more safely
<jdstrand> ijohnson: that is true
<jdstrand> ijohnson: btw, did you solve the rofs issue?
<ijohnson> Well haven't tested solving it yet, but the first thing I did was patch containerd to always put containers under a specified label if an env var is set
<jdstrand> pedronis: btw, when 2.43 goes to candidate, we need to do the final round of pulseaudio grandfathering. we could do a round now(ish) to get a jump start on it
<ijohnson> jdstrand: But I also got strace of the mounts that containerd does and the mount ns of the containerd and I can't see why the rootfs would be ro
<jdstrand> pedronis: what you gave me last time is sufficient for my needs
<pedronis> jdstrand: ok
<jdstrand> ijohnson: weird. it occurred to me that perhaps temporarily an overlayfs could be used to workaround it. that wouldn't be a long term fix of course
<sborovkov> Hey guys, I am trying to build snap with QtWebEngine for rpi eglfs. So it builds fine. Qt apps work. But when trying to run apps that actually use webengine I am getting a crash in webengine process (failed to execvp...). When running with LD_DEBUG I get this - /snap/screenly-client/x40/bin/screenly-client: error: symbol lookup error: undefined symbol: nspr_use_zone_allocator (fatal)
<sborovkov> any idea what that can be realted with? I am building latest Qt, using system libs as dependencies
<jdstrand> pedronis: just whenever you have a chance. if you don't have a chance until candidate, that is ok too
<pedronis> jdstrand: yea, we'll see, I'm also not sure when we'll branch 2.43
<ijohnson> jdstrand: If you have a little bit of time maybe you could look at https://pastebin.canonical.com/p/yh8M7G6qpk/ and https://www.irccloud.com/pastebin/IhtxTEjG/
<ijohnson> I can't see anything obvious there about why the rootfs in the container would be read-only
<ijohnson> Note that in the strace log, there are multiple containers being created and we really only care about the last one
 * cachio lunch
<jdstrand> ijohnson: sorry, someone asked me something. line 369 of https://pastebin.canonical.com/p/yh8M7G6qpk/
 * zyga back from lunch, hacking more
<jdstrand> ijohnson: that is doing what I thought it might be. it isn't necessarily an issue, but a pivot_root did happen before
<ijohnson> jdstrand: no worries, so that mount call is making "/" which at this point is an overlayfs mount, a slave mount, but that shouldn't make it read-only right?
<ijohnson> jdstrand: yeah I don't think pivot_root is as big of a deal as I thought it was
<ijohnson> Because apparently our dockerd patches don't even prevent docker from doing pivot_root anymore and it still works because it runs inside a different apparmor label
<mborzecki> sdhd-sascha: left a comment https://github.com/snapcore/snapd/pull/7845#issuecomment-563306248 imo there's an opportunity to fix in in systemd upstream too
<mup> PR #7845: cmd: add prefix to SYSTEMD_SYSTEM_GENERATOR_DIR <Simple ð> <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7845>
<ijohnson> s/it runs/the container runs/
<jdstrand> ijohnson: no, but doesn't line 285 look weird? what is going on with lowerdir?
<ijohnson> jdstrand: what's weird about that overlayfs lowerdir? It just has multiple lower dirs which last I checked is perfectly valid and well supported
<zyga> ijohnson, jdstrand: what are you chasing?
<ijohnson> zyga: the dream
<zyga> don't we all? :)
<ijohnson> (of kubernetes as a snap working nicely)
<ijohnson> :-)
<ijohnson> Maybe zyga you could take a look at the links I posted a bit above in the backlog, essentially the issue is that a container is started and it has "/" as read-only which is weird because it should have its own "/" built from overlayfs mounts
<zyga> looking
<sdhd-sascha> mborzecki: is there a bug in systemd too ?
<ijohnson> zyga: note to only look at the last set of mounts, etc. Because the first few are unrelated containers
<mborzecki> sdhd-sascha: hm not a bug really, they don't have that path in sytemd.pc
<cmatsuoka> cachio: is this something you're aware of? https://api.travis-ci.org/v3/job/622591349/log.txt
<sdhd-sascha> mborzecki: ah, ok. i could do that ?
<jdstrand> ijohnson: ok, I haven't seen that before but see in https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt that it is supported.
<zyga> ijohnson: stat -f /var/snap/kubernetes-worker/common/containerd/var/lib/io.containerd.snapshotter.v1.overlayfs/snapshots/91/fs
<zyga> jdstrand: yeah, that's the thing I mentioned in Vancouver :/
<zyga> just many lowerdirs
<ijohnson> zyga: issue is that this is an ephemeral container that is launched immediately and dies before we can really do anything
<zyga> ok
<zyga> ijohnson: so what's the symptom, that / is read-only?
<ijohnson> zyga: yes / is read-only is the symptom
<zyga> ijohnson: how is this determined?
<zyga> ijohnson: can I reproduce this?
<cachio> cmatsuoka, thanks for the report, I'll ake a look
<ijohnson> well not easily reproducible locally due to many levels of $CONTAINER_TECHNOLOGIES and $CLOUD_TECHNOLOGIES
<cachio> cmatsuoka, this test has been updated recently
<zyga> ijohnson: I don't see why it would be read only otherwise
<ijohnson> zyga: the container in it's entry point tries to create `/host/dir`
<zyga> aha
<zyga> and you get EROFS?
<ijohnson> Yes
<zyga> do you get a write error or a specific errno?
<ijohnson> Uhh I don't have the specific error in front of me
<zyga> ijohnson: I can help but I would love to get my hands on this
<ijohnson> joedborg: are you around? Do you have the specific error when you get that read only issue?
<zyga> ijohnson: otherwise it looks like it's not true, something is read only for real
<zyga> the mountinfo dump, where is that from
<zyga> from the container?
<joedborg> ijohnson: i'm here
<zyga> can we get a shell at the moment that mountinfo was collected?
<joedborg> ijohnson: which did you want?
<ijohnson> joedborg: can you pastebin the error you see when launching the container with the AWS script?
<joedborg> ijohnson: sure
<ijohnson> zyga: kinda it's tough because the container pops up for very short amount of time then exits
<jdstrand> what is going on with line 173: [pid  3012] mount("/", "/", 0xc0001c60a0, MS_RDONLY|MS_REMOUNT|MS_BIND|MS_REC, NULL) = 0
<zyga> ijohnson: how do you get that shell trace then?
<ijohnson> zyga: so to get that mountinfo we had an `nsenter -all -t $(until pgrep install-aws.sh)`
<zyga> ijohnson: looks like it makes the bind mount read only without remounting the filesystem
<zyga> er
<zyga> jdstrand: ^
<ijohnson> (sorry can only type so fast on a plane from my phone :-) )
<zyga> and recursively so, though I'm not quite sure that is really respected in the kernel
<zyga> ijohnson: oh
<zyga> ijohnson: man, you're good :D
<jdstrand> zyga: I more meant, hey, ijohnson, does this look like it is doing the right thing?
<zyga> I see
 * ijohnson thinks 
<zyga> jdstrand: but note that the 1st line of mountinfo shows it is writable, both the filesystem and the mount point - you can see "rw" there twice
<ijohnson> jdstrand: I saw that too I think it's a red herring
<ijohnson> There are multiple containers run and the first one is just a bug checking container for the kernel I think
<jdstrand> ijohnson: so, I bet you could get some of the info zyga wants by using a container that works (ie, one that doesn't try to create /host/..., run a shell, and then try to touch /host/foo or something to see if you get the same error
<ijohnson> I think containerd creates a dummy container on startup to see if it has to work around kernel bugs or not
<zyga> jdstrand: that's a good idea
<ijohnson> well yes that would be good but is complicated due to $CLOUD_TECHNOLOGIES and $CONTAINER_TECHNOLOGIES
<ijohnson> Essentially we don't know the full config of the container being created so we could reproduce
<joedborg> https://www.irccloud.com/pastebin/dna5cAMu/
<joedborg> ijohnson: zyga: ^
<ijohnson> If we did yes it would be easy to reproduce but for example a simple container created with the cli tool ctr for containerd doesn't use anywhere near the same config as this cloud provider does
<jdstrand> ijohnson: well, I know that joedborg was able to get some containers to run with what is available today. I'm just saying, maybe shell into one of those pods and see if the /host issue exists there too. if it does, perhaps it is the same issue was are seeing with eks
<zyga> joedborg: that's EROFS allright
<zyga> joedborg: how hard would it be to run some custom shell script instead?
<jdstrand> ijohnson: that would at least rule in if it is eks only or if it is a generic issue
<joedborg> zyga: itâs pretty easy to open a shell, just not within that container as that comes straight from Amazon.  Can it be a new container and be useful?
<zyga> yeah
<zyga> anything that is similar enough to reproduce the problem
<zyga> I'm mainly interested in:
<jdstrand> joedborg: that is the question. it is probably useful if we can reproduce the same rofs error in that container
<zyga> joedborg: /proc/self/mountinfo from the point of view of the failure
<jdstrand> s/same/same type of/
<zyga> joedborg: stat -f /
<zyga> joedborg: along with any logs from the host that may contain relevant stuff
<zyga> jdstrand: it would be quite evil to craft a seccomp profile that returns EROFS instead of EPERM ;)
<ijohnson> I'm about to land so I'll be AFK for a bit but yeah if we can get a similarly configured container shell that would be helpful
<zyga> ijohnson: safe travel
<jdstrand> hah, it would
<zyga> I'll be around for a while
<zyga> if I'm gone just leave me a message please
<joedborg> now working on getting a shell
<zyga> thank you
<joedborg> the issue is, because it's the networking pod that's failing, interacting with the cluster is a pain
<zyga> joedborg: are you racing with the container failure?
<zyga> joedborg: is this .... (winks) pod racing? :D
<joedborg> zyga: hahahaha, there are as many crashes
<ijohnson> Hahaha yes this is exactly pod racing, this demo is just like Anakin's racer :-)
<ogra> two thin strings holding it all together ?
<mup> PR snapcraft#2825 closed: remote-build: remove need to specify user <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2825>
<joedborg> zyga: ijohnson: jdstrand: just wondering if any of you could take a look over this https://pastebin.canonical.com/p/yxh2bnq6ms/, can anyone see if the URI specified at the end is inside a pivot root?  I don't think it is, but I think the Permission Denied is related to what we're seeing
<zyga> looking
<zyga> joedborg: is this from snap run --strace?
<zyga> joedborg: if so _all_ of is it after snap-induced pivot
<joedborg> zyga: thanks!  yep, i'm running ctr within the snap
<joedborg> zyga: when i say within, i mean via
<zyga> how do you mean?
 * ijohnson looks 
<zyga> pivot affects everything in the mount namespace
<zyga> all paths are affected
<zyga> I see some permission failures on epoll
<joedborg> zyga: from what i understand, this socket is meant to be opened to transport the tty, but it's failing to so I can't get a shell
<ijohnson> zyga, epoll EPERM is expected I think IIRC
<zyga> joedborg: on the host do you see any denials?
<zyga> joedborg: to answer your question, yes this is "inside" a pivot root
<ijohnson> joedborg: do you have all interfaces connected
<zyga> the permission denial needs to be overcome first
<zyga> there are ways to do that
<zyga> connect existing interfaces
<zyga> or switch the entire profile to complain mode
<joedborg> ijohnson: yeah i do this time :)
<joedborg> zyga: there aren't any denails
<joedborg> *denials
<zyga> are you running this as root? perhaps those are DAC failures
<joedborg> zyga: i am yeah
<jdstrand> 'abstract unix socket'
<zyga> dog
<zyga> doh
<jdstrand> that won't be affected by pivot_root, assuming the error is accurate
<zyga> I didn't notice that
<zyga> yeah
<joedborg> jdstrand: yeah it is /not/ documented well
<zyga> jdstrand: sharp eyes!
<joedborg> so i have no idea where it's meant to be written
<mup> PR snapd#7874 opened: seed: support ModeSnaps(mode) for mode != "run" <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7874>
<joedborg> jdstrand: zyga: ijohnson: I've got to run to an appointment, i'll have patchy comms, but will try to answer anything
<jdstrand> joedborg: the policy doesn't allow that path
<jdstrand> we have:
<jdstrand> unix (bind,listen) type=stream addr="@/containerd-shim/moby/*/shim.sock\x00",
<jdstrand> unix (bind,listen) type=stream addr="@/containerd-shim/k8s.io/*/shim.sock\x00",
<jdstrand> we need unix (bind,listen) type=stream addr="@/containerd-shim/default/*/shim.sock\x00",
<zyga> jdstrand: it's interesting that joedborg said there are no denials on the host
<joedborg> jdstrand: i think it used to be the case, but now has changed
<jdstrand> joedborg: did you disable kernel rate limiting?
<joedborg> zyga: that might be because i have a custom snapd
<joedborg> jdstrand: yeah
<jdstrand> joedborg: I suggest while trying to get this up and running to stay on a particular tag/commit/something for containerd
<joedborg> jdstrand: ah i meant between when that policy was written for docker and now, i have always stayed on 1 commiut
<jdstrand> joedborg: can you add to /var/lib/snapd/apparmor/profiles/snap.kubernetes-worker.containerd the above rule?
<jdstrand> joedborg: and reload the policy with apparmor_parser -r /var/lib/... and then restart containerd and see if you get farther?
<joedborg> jdstrand: ah that works for getting a containerd shell
<joedborg> thanks
<jdstrand> cool
<jdstrand> joedborg: i've made a note of that
<joedborg> jdstrand: thanks!
 * zyga EODs
<joedborg> okay, so this shell allows me to mkdir /host and write to it, so it's either an issue specifically via k8s or the aws container image
<joedborg> thanks for your help zyga
<zyga> good luck
<ijohnson> joedborg: so with that rule you still have issues with the eks container image?
<jdstrand> joedborg: that is useful. you said "it's either an issue specifically via k8s or the aws container image". is the shell you just used not via k8s (ie, the MVP from last cycle)?
<joedborg> jdstrand: no so i can't get a shell via k8s atm because this aws container that won't start controlls the netwroking in and out of the node
<joedborg> jdstrand: with out own control plane, it works fine
<jdstrand> joedborg: is this a regression from the mvp, this never worked or this wasn't tested before?
<joedborg> jdstrand: it's an aws specific thing
<jdstrand> joedborg: ok, so we've seen it work with OTHER_CONTROL_PLANE_TECHNOLOGY
<jdstrand> ijohnson: ;)
<zyga> haha
<joedborg> jdstrand: we have, but this issue will surface with any workload that doesn't conform with standard unix root directories
<joedborg> jdstrand: i agree they shouldn't do this, but people like to use /myapp when in containers
<ijohnson> jdstrand: :-) if only we weren't going to try and demo this with $SPECIFIC_CONTROL_PLANE vendor
<zyga> we can whitelist any number of /myapp variants ;)
<jdstrand> joedborg: sure, I'm just trying to understand if this is a regression or not
<zyga> maybe they get bored eventualyl
 * zyga really EODs
<zyga> good luck
<joedborg> guys, really sorry, i have to run for this appointment (normally i wouldn't, but it's not rescheduable)
<jdstrand> ijohnson: you are interested in understanding if the added unix rule allows for a shell with aws?
<ijohnson> joedborg: no problem
<jdstrand> joedborg: np. I'll give you a deb with the unix rule
<ijohnson> jdstrand: sorry don't quite follow the question, yes I am interested in getting AWS eks to work with the snap
<jdstrand> ijohnson: you asked "joedborg: so with that rule you still have issues with the eks container image?" - I was just making sure that question wasn't lost
<joedborg> jdstrand: thanks, maybe where it says âdefaultâ, âk8s.ioâ should probably be generic
<ijohnson> Oh right yes I did
<joedborg> Because thatâs just the namespace sep by the container
<jdstrand> joedborg: I already did that
<jdstrand> joedborg: thinkikng the same thing
<joedborg> Awesome thanks
<jdstrand> joedborg: ok, uploaded a new deb
<cmatsuoka> cachio: got this one too:
<cmatsuoka> rsync: write failed on "/mnt/user-data/gopath/src/github.com/snapcore/snapd/share/locale/mnw/LC_MESSAGES/snappy.mo": No space left on device (28)
<cachio> cmatsuoka, about the previous one I could reproduce the issue, the problem is in another test which is leaving the environment corrupted
<cmatsuoka> cachio: ah interesting
<cmatsuoka> cachio: do you know how to fix it?
<cachio> so you know in which system is happening hte "no space error"?
<cmatsuoka> cachio: ubuntu-core-18-64
<cmatsuoka> on snap-set-core-config
<cachio> cmatsuoka, not yet because for some reason the snap test-snapd-service-watchdog is leaving garbage after it is deleted
<cachio> cmatsuoka, I left some links in the stanup doc
<cachio> cmatsuoka, https://paste.ubuntu.com/p/FgV9nr9rDg/
<cachio> so then when we run the test snap-set-core-config it fails
<cachio> but is it because systemd is degraded
<cachio> cmatsuoka, and if I run the snap-set-core-config in a loop it works perfect
<cachio> so I presume there is some test which is executed before and it is causing this
<cachio> cmatsuoka, I am now trying to see which is that test
<mup> PR snapd#7875 opened: interfaces: refactor path() from raw-volume into utils with comments for old <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7875>
<mup> PR snapd#7876 opened: seed: fix seed location of local but asserted snaps <:birthday:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7876>
 * cachio afk
<mup> PR snapd#7848 closed: cmd/snap-bootstrap: mount ubuntu-data tmpfs, in one go with kernel & base <UC20> <Created by xnox> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7848>
<cmatsuoka> cachio: that test is passing now, did you do anything?
<cachio> cmatsuoka, no, it dependes on the tests order
<cachio> the problem is on the test ubuntu-core-gadget-config-defaults
<cachio> it is leaving a wrong systemd state
<cachio> I am testing a fix for this
<cmatsuoka> cachio: ah nice, thank you
<cachio> cmatsuoka, thanks for showing me the issue
#snappy 2019-12-10
<mup> PR snapcraft#2838 opened: add support for system-usernames <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2838>
<cjp256> mup: well done! you are quite responsive today! :D
<mup> cjp256: In-com-pre-hen-si-ble-ness.
<mup> PR snapd#7877 opened: tests: avoid mask rsyslog service in case is not enabled on the system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7877>
<mborzecki> morning
<sdhd-sascha> good morning
<zyga> Good morning
<zyga> I will start late today
<zyga> Kids have no regular school and nobody woke up early
<mborzecki> zyga: no school today? have i missed something?
<mup> PR snapd#7821 closed: interfaces/seccomp: parallelize seccomp backend setup <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7821>
<pstolowski> morning
<mup> PR snapd#7872 closed: doc: HACKING.md change autopkgtest-trusty-amd64.img name <Created by sd-hd> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7872>
<mup> PR snapd#7876 closed: seed: fix seed location of local but asserted snaps <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7876>
<mvo> mborzecki: do you think you could have a look at 7870?
<mborzecki> mvo: sure
<mvo> mborzecki: thank you!
<mup> PR snapd#7874 closed: seed: support ModeSnaps(mode) for mode != "run" <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7874>
<zyga> mborzecki: no, theatre and medical examination for Iza and Jan respectively
<zyga> Nothing makes the morning lively as a broken jar of jam on the carpet
<zyga>  But on the upside the carpet was not this clean in weeks
<zyga> And I also cleaned the dust filter in Izaâs PC
<zyga> Now I only need breakfast and shower an I can get to work
<zyga> re
<zyga> finally
<zyga> everyone's gone and I can work
<zyga> I'm on bug triage duty today
<mup> PR snapd#7870 closed: boot,bootloader: setup the snap recovery system bootenv <UC20> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7870>
<mup> PR snapd#7817 closed: boot,bootloader: make MakeBootable() uc20 aware <UC20> <Created by mvo5> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7817>
<mup> PR snapd#7878 opened: cmd/snapd-generator: fix unit name for non /snap mount locations <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7878>
<mborzecki> zyga: mvo: ^^ trivial fix
<pedronis> pstolowski: we can try to have our chat about services after the standup today?
<pstolowski> pedronis: great. i'll need a 10 minute break right after the standup for a very quick errand
<pedronis> pstolowski: that's fine with me
<pedronis> mvo: suggested comment for one of your follow ups as discussed:  https://paste.ubuntu.com/p/PTFrKZGgz5/
<Chipaca> whoops, forgot to turn on irc today for some reason
<Chipaca> only realised because i thought to share: i need to measure, but the impression i get is that interacting with snapd perceptibly slows down as the number of changes grows
<Chipaca> now this might just mean i get more impatient as the test i'm working on progresses :)
<Chipaca> so i need to measure, but, that
<pedronis> Chipaca: it's not impossible we do quite a few things that in the order of #changes
<Chipaca> pedronis: yup
<Chipaca> pedronis: it shouldn't be perceptible though :)
<Chipaca> in the sense that if it is we might want to fix it
<Chipaca> so i'll be measuring that at some point
<pedronis> Chipaca: yes, but please channels first
<mvo> pedronis: thanks, in a meeting
<pedronis> mborzecki: mvo: #7873 needs a master merge now I think
<mup> PR #7873: image: set recovery system label when creating the image <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7873>
<zyga> mborzecki: looking
<Chipaca> pedronis: that's the test i'm working on that i saw this in
<mborzecki> just yesterday I read an article about O(n^2) in WMI, maybe we're hitting a similar sweet-spot with changes
<Chipaca> channels i mean
<mborzecki> pedronis: already updated
<pedronis> mborzecki: thx, just saw that
<mvo> pedronis: will do after my meeting, thank you!
<pedronis> mborzecki did it already
<pedronis> I also +1ed
<pedronis> it
<mvo> pedronis: \o/
<mvo> pedronis, mborzecki thank you so much!
<mup> PR snapd#7878 closed: cmd/snapd-generator: fix unit name for non /snap mount locations <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7878>
<mup> PR snapd#7873 closed: image: set recovery system label when creating the image <UC20> <Created by mvo5> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7873>
<mup> PR snapd#7879 opened: [RFC] devicestate: use httputil.ShouldRetryError() in prepareSerialRequest <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7879>
<mup> PR snapd#7880 opened: snapstate: add support for UC20 gadget in {Config,Gadget}Defaults <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7880>
<cachio> mvo, hey
<cachio> mborzecki, hey
<cachio> https://paste.ubuntu.com/p/KbBGqQNC2R/
<cachio> after we run some tests the rsyslog remains masked
<cachio> an example is ubuntu-core-config-defaults-once
<cachio> it happens on ubuntu core 18
<cachio> where the rsyslog is not part of the system
<cachio> seems to be a bug
<cachio> zyga, ~
<cachio> someone could confirm if it is working as design or it is something to fix?
<mvo> hey cachio ! thanks for this report
<cachio> mvo, yaw
<mborzecki> cachio: snap-set-core-config needs a fix, but that other test does not, my comment was about the other test
<cachio> mborzecki, my question is about the problem seems to be in snapd itself because it leaves the rsyslog as masked in case hte service does not exist in the system
<cachio> I mean, in case rsyslog does not exist, when we restore everyting in the test the rsyslog service should not appear any more in systemd right?
<zyga> cachio: are you saying test restore should undo the masking
<zyga> cachio: or snapd should undo the masking under some condition?
<cachio> zyga, snapd should do it if possible
<zyga> cachio: ok, what is the condition when snapd should unmask rsyslog?
<cachio> but if not, I'll change the test ot do it in the test
<cachio> zyga, in core18 rsyslog is not installed by default
<cachio> so we mask it but it not installed
<zyga> cachio: do we ever ask snapd to unmask it?
<cachio> no
<cachio> zyga, but perhaps we should no mask a service which does not exist
<zyga> so the fact it is not installed is not relevant
<zyga> if it was installed the bug would be back
<zyga> we either need to ask snapd to unmask it
<zyga> or know about this in global test restore and undo it
<cachio> zyga, I can unmask the service in the test
<cachio> it is easy
<zyga> consider doing that globally as well
<zyga> since it is part of the "state" we undo
<cachio> zyga, ok
<cachio> I am working in another PR to make a set of validations during hte restore
<cachio> I'll include that on this one
<zyga> sure, as you wish
<pstolowski> pedronis: i'm in, can you hear me?
<pedronis> pstolowski: sorry, one sec
 * cachio afk 10 mins
<ijohnson> hey folks, quick question how can I create cohorts for a demo of how they work? (maybe pedronis can point me in the right direction?)
<jdstrand> pedronis: hey, can you take a look at https://forum.snapcraft.io/t/synchrorep-need-classic-confinement/13347/8 (and https://forum.snapcraft.io/t/synchrorep-need-classic-confinement/13347/9). no need to say anything unless you want to overrule me
<zyga> ijohnson: hey
<ijohnson> zyga hey
<zyga> ijohnson: you need to set a cohort key via snap set AFAIK
<zyga> ijohnson: any number of machines can set the same key
<ijohnson> but how do I create a cohort key
<ijohnson> ?
<zyga> ijohnson: and then they will see the same view of revisions
<zyga> ijohnson: it's just a string
<zyga> AFAIK
<zyga> but I can be wrong
<zyga> Chipaca: ^ quick help please
<ijohnson> hmm
 * cachio lunch
<pedronis> ijohnson: snap create-cohort snap-names
<zyga> thank you pedronis!
<ijohnson> perfect thanks!
<pedronis> ijohnson: you can one key per snap
<pedronis> that you care about
<jdstrand> pedronis, mvo: fyi, I'm going through store reviews today and then moving to PR reviews https://github.com/snapcore/snapd/pulls/review-requested/jdstrand (jeez, a ton came in since the sprint)
<Chipaca> zyga: in a meeting sorry
<zyga> Chipaca: no worries, pedronis already gave the answer
<jdstrand> pedronis, mvo: I am going to start with 7238, then 5822 and 7490 (the priority that pedronis gave me in Vancouver)
<Chipaca> ijohnson: snap create-cohort
<jdstrand> pedronis, mvo: fyi, I had a huge pile of stuff that accumulated due to sprint prep, sprint immediate asks, postsprint catchup, then holidays
<pedronis> jdstrand: yes, that's why we setup a meeting later in the week to try to prioritize those a bit, and reunderstand the very old ones
<Chipaca> ijohnson: gives you a yaml that you then ship everywhere that wants to use the cohort
<jdstrand> pedronis, mvo: which is why I am behind. we can meet on thur as requested, but honestly, I'd prefer an email with the PRs in the priority you'd like them reviewed. then I can work that list and give updates until it is done
<jdstrand> pedronis, mvo: ok, well, that's fine. I'm just going off what you want, but we can have the meeting
<jdstrand> hopefully the list will be a little shorter by then
<Chipaca> pedronis: mvo: as a conclusion I don't think we need to block cutting the next release, but we do need to not actually release it without the TBD fixes
<Chipaca> pedronis: mvo: so maybe a -pre would be more honest :)
<sdhd-sascha> zyga: hope it was ok to write you per mail directly?
<zyga> sdhd-sascha: that's ok, I haven't seen your mail yet though
<zyga> I don't really follow email that well (>>>1000 email unread)
<sdhd-sascha> oh
<pedronis> mvo_: seems lot of Core 20 bits were not in 2.42 but after
<mvo_> pedronis yeah, that sounds plausible
<mvo_> pedronis 2.42 is pretty "old" :/
<mvo_> pedronis why is it a concern? is anyone using stable for uc20?
<Chipaca> zyga: what was the name of the forum thing where we document some missing things in snapd, like homes needing to be there all the time?
<Chipaca> ah, limitations in snapd, got it
<zyga> Chipaca: ah, let me find it
<zyga> ah you found it :D
<zyga> sorry
<Chipaca> zyga: context is https://forum.snapcraft.io/t/updates-delete-user-application-data/14568 fwiw
<sdhd-sascha> zyga: just want to say that you can also give me some  tasks.
<zyga> sdhd-sascha: if you want to get into development my best advice would be follow code reviews
<zyga> we have lots of things going on
<zyga> and we have a specific style of interaction that may not be common in other projects
<zyga> most churn goes into RPs at the top of the list
<zyga> older PRs tend to "sink" to the bottom where they see less activity
<zyga> reviewing code has two benefits: you get to familiarize yourself with what's going on and where
<zyga> and you get to see how the review process looks like
<zyga> note, I have not read your mail yet
<mvo> jdstrand: thanks for your feedback earlier, I will think about it
<mup> PR snapd#7768 closed: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7768>
<pedronis> jdstrand: I merged ^ , now 7875 has some conflicts
<jdstrand> pedronis: thanks and ack (weird, I branched off my last commit to raw-volume, but I'll fix)
<pedronis> jdstrand: it's likely because I squased 7768 because there was too much back and forth in its history
<mvo> hm, 7830 has two +1 and is green - can I merge it?
<pedronis> mvo: it would be ok for me
<mvo> ta
<mup> PR snapd#7830 closed: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7830>
<sdhd-sascha> jdstrand: hi. If i understand it right, then classic will be in future only supported in a few cases. For me it's ok if you write into the forum, that it want be supported and there will be soon other ways to launch other applications. E.g. "app-launch". Then i can close my issue on github and point to the forum. I personally want to concentrate on the strict wayland snap.
<blackboxsw> hi folks, are people seeing issues where snapd.seeded never completes on lxc (disco && eoan) https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1806070?
<mup> Bug #1806070: snapd.seeded.service never completes preventing full boot to default target <amd64> <apport-bug> <bionic> <snapd:Fix Released> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1806070>
<jdstrand> degville: hey, fyi, took a stab at https://forum.snapcraft.io/t/the-raw-volume-interface/14578
<degville> jdstrand: brilliant, thanks you!
<ogra> blackboxsw, given that bug was fixed a year ago, you should really better open a fresh one ... (your error also does look different, snapd isnt stuck in the "Doing" state for the initialization but actually errored)
<blackboxsw> ogra: will do. Thanks, I'll try grabbing more details about the symptoms I'm seeing and file fresh
<blackboxsw> worth opening a bug or snapcraft forum discussion?
<ogra> (you probably want to include the output of "snap tasks 1" as well)
 * blackboxsw reads : https://forum.snapcraft.io/t/when-to-use-forum-vs-irc/38 
<blackboxsw> thx will do
<ogra> i'd open a bug ... but thats really up to you, the snapd guys look at both, launchapd as well as the forum
<blackboxsw> ok thanks
 * cachio eod
<sdhd-sascha> zyga: it's not urgent. but maybe, you have a hint for me. I want to allow access to /run/systemd/sessions/<id> . No i found that commonFilesInterface doesn't allow apparmor wildcards... Is there another where, instead of using "system-files" ?
<sdhd-sascha> zyga: sorry... "login-session-observe"
<sdhd-sascha> i found it
<mup> PR pc-amd64-gadget#25 opened: Fix kernel path in recovery grub.cfg <Created by cmatsuoka> <https://github.com/snapcore/pc-amd64-gadget/pull/25>
<jdstrand> degville: fyi, one more for you: https://forum.snapcraft.io/t/the-login-session-observe-interface/14580
<zyga> sdhd-sascha: I think /run is special cased to be off-limits by some of the special interfaces
<zyga> sdhd-sascha: ping me tomorrow please
<sdhd-sascha> zyga: login_session_observe from jdstrand, 18 days ago seems to work
<zyga> sdhd-sascha: that's cool, I meant that the generic "gimme a path" interfaces may not work
<sdhd-sascha> zyga: i have found a missing apparmor method in login-session-control
<sdhd-sascha> i will push it later
<zyga> obviously a precise interface can open any location
<zyga> ok
<sdhd-sascha> but i didn't found a interface for policykit ...
<sdhd-sascha> but let's talk tomorrow
<sdhd-sascha> "gimme a path" ?
<sdhd-sascha> zyga: good night
<mup> PR pc-amd64-gadget#25 closed: Fix kernel path in recovery grub.cfg <Created by cmatsuoka> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/25>
<degville> jdstrand: looks good - thanks for letting me know!
<jdstrand> np
<mup> PR snapd#7881 opened: login-session-control - added missing dbus commands <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7881>
<jdstrand> rbasak: fyi, I haven't forgotten about certbot. it is first up tomorrow
#snappy 2019-12-11
<zyga> good morning
<zyga> os upgrade, brb
<sdhd-sascha> Hello
<zyga> re again
 * zyga looks at his inbox
<zyga> eh, first mail is to pay taxes
<zyga> oh well
<zyga> sdhd-sascha: found your mail
<zyga> sdhd-sascha: do you mind if I answer here
<zyga> I prefer IRC over email any day of the week
<sdhd-sascha> zyga: no - but some task i already have done yesterday
<zyga> sdhd-sascha: about snap run test - I is up to you, perhaps the snap run test is overcrowded and deserves to be split into run, run + strace, run + gdb and run + ltrace
<zyga> about wayland, yay!
<zyga> as for /etc/debian_version, I think it's more complex because 1) we want to stop sharing /etc with the host 2) if it is a symlink that points to /usr it will be useless (like os-release on some systems) 3) usually reading os information is not really necessary, apart from "vanity" reasons like "you are running $foo" screens - what's the motivation behind reading /etc/debian_releae?
<zyga> *release
<zyga> sdhd-sascha: as for spread, that's easy, just build it from github and run with locally made images
<zyga> sdhd-sascha: you can fetch some of my older images from spread.zygoon.pl
<zyga> sdhd-sascha: those images are made with autopkgtest create image tools but really, any tool that spits out a machine with password auth is okay (for simplicity)
<sdhd-sascha> zyga: i run: ~/work/src/github.com/snapcore/snapd$ spread -v qemu:ubuntu-18.04-64
<sdhd-sascha> And then i currently get only no connection
<zyga> sdhd-sascha: your mileage will vary in some cases as we tweak our images more than not for certain aspects that are murky but you should have a good start that will let you iterate x10 locally before pushing a PR and having to wait for travis + spread in gce
<zyga> how did you make the image?
<sdhd-sascha> I build spread by myself - will look how the best way to connect to the serial of qemu...
<zyga> sdhd-sascha: no no
<zyga> the image
<zyga> remark about adding more snap-types, most likely you won't get that because it involves snap architects and store changes to implement
<zyga> as for /run/systemd/sessions, grep through interfaces, if nothing sensible is there discuss a new interface design on the forum
<zyga> the actual implementation is the easiest chunk
<zyga> sdhd-sascha: so how did you get the ubuntu 18.04-64 image?
<sdhd-sascha> zyga: i use autpkgtest like in Hacking.md
<zyga> hmmm
<zyga> do you get anything if you run spread with -vv ?
<sdhd-sascha> zyga: /run/systemd/sessions works with #7881
<mup> PR #7881: intreface: login-session-control - added missing dbus commands <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7881>
<zyga> sdhd-sascha: and lastly, reviews are always awesome
<zyga> sdhd-sascha: those will help you get up to speed the most IMO
<sdhd-sascha> zyga: thank you :-)
<sdhd-sascha> zyga: today spread do something. don't know why, but it's fine
<zyga> sdhd-sascha: local spread runs are 10x heavier on network than CPU
<zyga> sdhd-sascha: I recommend exploring proxy options for apt, at least
<zyga> sdhd-sascha: there are some more savings to be had after you get thorough this
<zyga> sdhd-sascha: read spread.yaml for ideas on what the host environment is used (tip, grep for host:)
<sdhd-sascha> zyga: yes - i have to take a look, why the MAAS proxy doesn't work here
<zyga> sdhd-sascha: I'm not familiar with maas proxy
<sdhd-sascha> it's simple a mod' in /etc/apt/apt.conf.d/XX-proxy after deployment - no magic
<zyga> sdhd-sascha: aha, spread.yaml requires explicit opt-in
<zyga> you need to set some environment variables that get passed down the the virtual machine / container that is started by spread
<pstolowski> morning
<zyga> hey pawel
<zyga> I'll work from the kitchen until the office warms up
<zyga> pstolowski: it was -4 this morning
<zyga> phone
<mup> PR snapd#7882 opened: devicestate: only run ensureBootOk() in "run" mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7882>
<zyga> and back now
<zyga> mvo: do you urgently need reviews or can I focus on branch iteration?
<mvo> zyga: branch iteration is fine, 7880 is a blocker right now, I need to poke around this area a bit, the PR is not ready :(
<zyga> ok
<zyga> mvo: good luck and feel free to drag me into this :)
<pstolowski> zyga: uhm... here https://i.paste.pics/f06e76ec6b4420a5e8cc5c006bbdcca4.png
<zyga> wooow
<zyga> that's just like real winter :)
<zyga> hmm are we in a split
<zyga> has anyone seen maciek today?
<pstolowski> zyga: according to hr calendar he is off today
<pedronis> he said so in the standup yesterday
<zyga> ah
<zyga> ok
<pedronis> he'll be back tomorrow
<zyga> thanks, I must have missed that
<pedronis> mvo: hi, bare was fixed, I looked at what is needed to land #7594 but got confused by the revisions of test-snapd-busybox-static, we can chat about it in the standup
<mup> PR #7594: tests: replace "test-snapd-base-bare" with real "bare" base snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/7594>
<mvo> pedronis: ok
<mvo> has anyone checked why we have red tests right now?
<zyga> mvo: nope, let me look
<zyga> mvo: I'm running spread in qemu locally and trying to fix something but didn't notice red
<zyga> mvo: interfaces-audio-playback-record is failing on 16.04
<zyga> looking at why
<zyga> hmm
<zyga> it fails in a suspicious way
<zyga> https://www.irccloud.com/pastebin/5GYgmfK1/
<zyga> looking at the next PR
<zyga> mvo: there's a typo in your PR https://github.com/snapcore/snapd/pull/7880/files#r356529968
<mup> PR #7880: snapstate: add support for UC20 gadget in {Config,Gadget}Defaults <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7880>
<zyga> mvo: next PR has name upsetting commit checker (from sdhd-sascha)
<zyga> mvo: next PR has apt-hooks failure with no useful failure
<zyga> s/failure/error messages/
<zyga> mvo: next PR has gofmt issues (from jamie)
<zyga> mvo: seems to be nothing specific but the audio recording failure is worrying
<zyga> mvo: feels like it could break the relase
<zyga> mvo: do you want me to pursue this further?
<mvo> zyga: that's fine, I'm in a meeting right now though
<zyga> pstolowski: just a random though, in snap is-connected we could say something super basic if stdout is a tty
<mvo> just fyi - I branched 2.43 now
<mup> PR snapd#7883 opened: snapstate: relax gadget constraints in ConfigDefaults Et al <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7883>
<mvo> still open for selected cherry picks
<pstolowski> zyga: we could yes, although when the pr was reviewed we opted for removing any verbosity that i initially had. fwtw snapctl is meant ot be used by scripts/apps, so i'm not sure if output is that useful
<zyga> pstolowski: snapctl yes
<zyga> I meant "snap"
<zyga> pstolowski: note that the verbosity would obviously not be there in a "if snap is-connected foo bar; then" scenario
<zyga> mvo: sounds great
<mup> PR snapd#7880 closed: snapstate: add support for UC20 gadget in {Config,Gadget}Defaults <UC20> <â Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7880>
<pstolowski> zyga: sorry, i thought you misstyped. i don't remember we ever considered snap is-connected
<zyga> pstolowski: ah, I see
<zyga> do we plan to have it for consistency?
<pstolowski> i see how this could be handy as a shortcut over of snap interfaces / snap connections. at the same time it was meant to address the deficiency on snapctl side (which doesn't exist on snap side). i don't know, guess it's a question to pedronis_
<zyga> brb
 * cachio afk
<sdhd-sascha> zyga: i will be back in at the evening. (the PR name i have changed)
<mup> PR core18#144 opened: Add efibootmgr to the extra packages <Created by sil2100> <https://github.com/snapcore/core18/pull/144>
<zyga> sdhd-sascha: sounds good
<sdhd-sascha> zyga: is offtopic - but did you use raspberry-pi4 ? i got a response from request to the maintainers, that they work on the network support for u-boot. I need this, because rpi4 can only network boot the kernel, but not the initrd ... And with u-boot, it would then possible to boot ubuntu-core over network, e.g. with MAAS :-)
<zyga> sdhd-sascha: I have a rpi4 but I didn't try the new ubuntu images yet, AFAIK there's no ubuntu-core image for it yet
<zyga> sdhd-sascha: as for netboot, I don't know how it boots enough to answer
<sdhd-sascha> zyga: currently it needs beta-firmware for network-boot. I already boot a kernel and nfs as root-filesystem.
<sdhd-sascha> And about ubuntu-core for rpi4. We can use the default image for arm64 the kernel and modules are always the same
<mup> PR snapd#7884 opened: snapstate: check gadget model constraints in checkSnap <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7884>
<zyga> sdhd-sascha: I'm not pursuing that today if you are interested in it I would suggest asking sil2100 or ogra for pointers
<mvo> pedronis_: a review for 7883 would be great, this should unblock the seeding in install mode
<pedronis> mvo: about #7879, I'm fine merging it for edge once we have cut 2.43,  if it works then, we can cherry pick it, it seems it's localized enough for that
<mup> PR #7879: devicestate: use httputil.ShouldRetryError() in prepareSerialRequest <Created by mvo5> <https://github.com/snapcore/snapd/pull/7879>
<pedronis> mvo: ok, resting a bit after my doc appt/lunch, will looke in a bit
<mvo> pedronis: thanks
<zyga> hmm
<ogra> zyga, sdhd-sascha https://people.canonical.com/~ogra/snappy/raspberrypi4/core18/
<ogra> not using our kernel though ...
<sdhd-sascha> ogra: :-) yes, i forgot where it was
<pedronis> mvo: lots of PRs are red though ? general master problem? (I havent looked)
<sdhd-sascha> pedronis, mvo: maybe something with debian-sid
<zyga> pedronis: I loked earlier today and it didn't seem like a single problem
<zyga> pedronis: each PR was red for a distinct reason
<pedronis> fun, not. ok
<zyga> pedronis: though one was worrisome
<zyga> pedronis: audio-record seems broken for real now
<zyga> pedronis: perhaps our images got some changes / packages got rolled back or worse, updated with patches dropped
<pedronis> ok, we need to rope in jdstrand on that
<zyga> jdstrand: the log is https://api.travis-ci.org/v3/job/623567687/log.txt
<zyga> jdstrand: the job is https://travis-ci.org/snapcore/snapd/builds/623567683
<zyga> jdstrand: ^ it looks serious
<pstolowski> hmm i just saw it on my PR
<cmatsuoka> cachio: good morning. a question about our GCE hosts, do they support nested VMs?
<pedronis> mvo: I did a pass of reviews
<jdstrand> zyga (cc pedronis): it isn't serious, the mediation patches went through SRU today: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1781428
<mup> Bug #1781428: please enable snap mediation support <patch> <verification-done> <verification-done-bionic> <verification-done-xenial> <pulseaudio (Ubuntu):Fix Released
<mup> by jamesh> <pulseaudio (Ubuntu Xenial):Fix Released by jamesh> <pulseaudio (Ubuntu Bionic):Fix Released by jamesh> <https://launchpad.net/bugs/1781428>
<jdstrand> I'll submit a PR to flip on xenial and bionic
<zyga> jdstrand: I'm confused, how did this test pass before?
<zyga> ah
<zyga> I get it now
<zyga> I misread the failure message I guess
<zyga> thank you, that's great news
<jdstrand> zyga: because yesterday the patches weren't in -updates but today they are
 * zyga nods
<mup> PR snapd#7885 opened: tests: 16.04 and 18.04 now have mediating pulseaudio <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7885>
<jdstrand> zyga: there you go ^
<zyga> looking
<zyga> jdstrand: was this in 2.43? if so mvo needs to cherry-pick it
<jdstrand> zyga: yes and I just milestoned it
<jdstrand> well, let me triple check that
<jdstrand> yes, it was
<cachio> cmatsuoka, hey, sorry for the delay
<cachio> cmatsuoka, yes, they do but not any instance
<cachio> cmatsuoka, just the instances that we use for nightly execution do
<mup> PR snapd#7886 opened: tests: 16.04 and 18.04 now have mediating pulseaudio - 2.43 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7886>
<zyga> jdstrand: thank you!
<jdstrand> I created that ^ for 2.43 to make it quick
<cmatsuoka> cachio: the question is because for testing core20 installation we may need a nested VM (so we can enable secure boot and software tpm)
<jdstrand> not excellent timing on the SRU approval, would've been nice to have had it done before the commit, but good we have the mediation now
<cachio> cmatsuoka, it can be done
<cmatsuoka> cachio: can I run a test on one of those instances? how do I access one of them?
<cachio> cmatsuoka, yes
<cachio> cmatsuoka, use google-nested backend
<cachio> it is in the spread.yaml of snapd project
<cmatsuoka> cachio: ah ok, thanks!
<cachio> yaw
<cachio> please ping me if you need any help on this
<cachio> cmatsuoka, ~
<cmatsuoka> cachio: testing here, thanks!
<cmatsuoka> cachio: is there any stability difference between the xenial and bionic systems? and how's the stability overall, is it working perfectly or do we have crashes from time to time?
<cachio> cmatsuoka, those are stable
<ijohnson> morning folks
<cachio> didn't see any error on those
<cmatsuoka> cachio: great, thanks!
<mup> PR snapd#7887 opened: [RFC] seed,devicestate: check gadget model constraints when seeding <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7887>
<stgraber> mvo: I see 2.42.5 made it to candidate yesterday, any idea when this will hit stable?
<mvo> stgraber: it's getting phased to stable after our standup which is now
<zyga> stgraber: talk about nice customer service, you ask for it and you get it :)
<mvo> stgraber: so the first couple of percent will go out in ~30min or so and then it will ramp up over the next hours, the details of the phasing cachio  knows
<mvo> stgraber: and sorry again for the trouble
<stgraber> sounds good, thanks
<zyga> niemeyer: hello
<zyga> niemeyer: I made a small PR for spread for your consideration https://github.com/snapcore/spread/pull/94
<mup> PR spread#94: qemu: invoke qemu in a portable way <Created by zyga> <https://github.com/snapcore/spread/pull/94>
<zyga> niemeyer: it's literally a one liner but not sure about the architecture portability aspect
<zyga> niemeyer: I'm happy to iterate, just need something that operates outside of Debian
<niemeyer> zyga: I'm in a meeting at the office today.. can you please ping me by Friday so we can look at it together?
<zyga> niemeyer: sure, is Friday okay?
<niemeyer> Yeah, I should be back late tonight
<zyga> cheers, see you then!
<niemeyer> Thanks!
<mup> PR snapd#7885 closed: tests: 16.04 and 18.04 now have mediating pulseaudio <â  Critical> <Created by jdstrand> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7885>
<cachio> stgraber, hey, progressive release for 2.42.5 started
<cachio> 25% of the devices are receiving the update now
<cachio> the percentage will grow during the day
<stgraber> Thanks
<jdstrand> pedronis: hey, can you give https://forum.snapcraft.io/t/certbot-request-for-classic-snap-approval/6240/19 a look (you'll need to read from https://forum.snapcraft.io/t/certbot-request-for-classic-snap-approval/6240/7 and lower (my, rbasak's and upstream comments on the approach, not the side conversation on use of the interface)
<jdstrand> rbasak: also, fyi, https://forum.snapcraft.io/t/certbot-request-for-classic-snap-approval/6240/17
<jdstrand> pedronis: feel free to discuss in the topic. (I'm stepping away to an appt)
<pedronis> jdstrand: likely I'll look at it in my morning tomorrow
<pedronis> I have other things today
<rbasak> jdstrand: thanks! Assuming that output from a connection hook will end up in the console, are you saying that (yet to be confirmed by others) printing a warning from the hook and later at runtime will be sufficient?
<rbasak> jdstrand: and separately, do you know what the store will do in terms of autoconnection for plugins published by the same publisher as the certbot snap itself, and am I right in thinking this would be acceptable (since same publisher)?
<jdstrand> rbasak: I'm not sure it will go to the console. you might need to use it to manage something that the certbot command might have to consult. not ddictating implementation. be tasteful, etc, but something needs to come up somewhere imo
<jdstrand> rbasak: the store will auto-connect from the same publisher, but we can override that
<jdstrand> if desired
<pedronis> hook output doesn't go the console, so far we don't have mechanism to do that
<jdstrand> I don't think it is though, since collectively it is all 'upstream'
<pedronis> in general we don't expect them to be running always with somebody watching
<pedronis> (I haven't read the thread yet as I said)
<jdstrand> right, that is what I though. but it can manage something (eg, a file) for something else to look at
<jdstrand> thought*
<jdstrand> gotta run (appt)
<cachio> pedronis, hi, do you know if there was any change in snapd that could produce we are calling more times to the store service /names ?
<rbasak> jdstrand: OK, so in that case the warning can be at runtime of certbot only, right? And that might be automated (eg. via the systemd timer that certbot installs). Normally the first time the user would run certbot by hand to set it up, but I can imagine an adversarial scenario where someone convinces a user to add and connect the plugin after initial setup. In this case, the systemd timer will run the
<rbasak> third party code without the user ever seeing the message.
<rbasak> jdstrand: is that acceptable to you?
<pedronis> cachio: no, if anything we reduced it but you probably want to discuss with Chipaca when he's around
<rbasak> jdstrand: if not, I'm not sure how to achieve what you want with the current snapd.
<cachio> pedronis, because it is producing that the store is sending an error to snapd like this https://paste.ubuntu.com/p/JY69dz4vwP/
<cachio> pedronis, ah, ok
<cachio> I'll talk to jhon in that case
<pedronis> mvo: did a pass on #7887, nothing that haven't already mentioned
<mup> PR #7887: [RFC] seed,devicestate: check gadget model constraints when seeding <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7887>
<ijohnson> jdstrand: pedronis: it's a bit silly but you could have a connection hook that always fails with a message explaining the ramifications of connecting that interface unless there's a config set like `snap set $SNAP_NAME <other-snap-name>=ok`
<ijohnson> here I think the connection hook could introspect what the name of the other snap that is being connected to to determine what config item to check, but I would need to check how that works
 * zyga looks after lucy for an biur
<zyga> Hour
<mvo> pedronis: thanks!
<mup> PR snapd#7888 opened: tests: disable apt-hooks test until it can be properly fixed <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7888>
 * cachio lunch
<mup> PR snapd#7889 opened: overlord,o/snapstate: make sure we never leave config behind <Created by pedronis> <https://github.com/snapcore/snapd/pull/7889>
<pedronis> mvo: anything I should review?
<ijohnson> pedronis: jdstrand: I put an example into the certbot forum topic for certbot
<pedronis> ijohnson: yes, it's by design that we don't tell snap detail of the other side
<mvo> pedronis: I updated 7884 - I will look into converting constraints -> model now
<ijohnson> yeah that's what I thought from looking at it
<pedronis> mvo: +1
<ogra> jdstrand, ijohnson reading that certbot discussion i wonder if i'm missing anything here ... afaik classic snaps can provide interfaces but not consume them ... did that policy change recently ?
<ijohnson> ogra: I don't think in this case certbot is consuming anything from the interface at all, it's just using the connection hooks and the existence of that connection to do something in the classic snap
<ijohnson> ogra: the classic snap directly executes "snap connections" to see what connections are connected
<ogra> well, and the "snap connect .." (to exec the interface hook) was the bit i thought was denied
<mvo> cachio: 7888 has failed :/
<mvo> cachio: some strange error I have no seen yet
<ogra> (beyond a store upload block for such snaps, but thats indeed just an override)
<cachio> mvo, checkign
<mvo> cachio: thank you
<cachio> mvo, there is a PR for fixing this error #7877
<mup> PR #7877: tests: avoid mask rsyslog service in case is not enabled on the system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7877>
<cachio> I'll restart the job
<cachio> mvo, thanks for hte heads up
<ijohnson> ogra: not sure about the store denial, but the example snap I have locally works fine if the snap is classic, the interface hooks are still run under confinement
<ogra> aha ... well, i thought in the past the snap connect command used to cause an error
<ogra> if thats not the case anymore then i'm just behind on knowledge
<mvo> cachio: thank you!
<cachio> mvo, yaw
<pedronis> cachio: do we need #7888 to be back to green?
<mup> PR #7888: tests: disable apt-hooks test until it can be properly fixed <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7888>
<cachio> pedronis, I restarted the failed job
<cachio> pedronis, it should finish in 10 minutes
<cachio> pedronis, merged
<mup> PR snapd#7888 closed: tests: disable apt-hooks test until it can be properly fixed <Simple ð> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7888>
<jdstrand> ogra, ijohnson: there would need to be a review-tools override. this novel use of the content interface has been used once elsewhere. it is open for everyone since the snapd team might want to design something a bit better
<jdstrand> err
<jdstrand> ogra, ijohnson: it isn't*
<ijohnson> right
 * cachio afk 10mins
 * zyga resumes working
<ogra> jdstrand, yeah
<mup> PR snapd#7890 opened: tests/many: quiet lxc launching, file pushing <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7890>
<mup> PR snapd#7891 opened: devicestate: use correct model constraints in remodel/gadget updates <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7891>
<mup> PR snapd#7887 closed: [RFC] seed,devicestate: check gadget model constraints when seeding <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7887>
<jdstrand> rbasak: exploring ijohnson's idea would probably be best, but if it turns into a timer/journald thing, that is maybe ok. the other thing that could be done is to use a 'snap set' on the certbot snap to allow 3rd party plugins at all
<jdstrand> rbasak: that in and of itself doesn't help much due to cut and paste, but if the option was like: snap set certbot allow-3rd-party-plugins-for-admin=true
<jdstrand> rbasak: or something scary and eye catching. again, just an idea
<jdstrand> roadmr: hi! can you pull 20191211-1947UTC?
<jdstrand> roadmr: since the last request, it is all overrides and updates for the new 2.43 interfaces
<mup> PR snapd#7886 closed: tests: 16.04 and 18.04 now have mediating pulseaudio - 2.43 <â  Critical> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7886>
<mup> PR snapd#7890 closed: tests/many: quiet lxc launching, file pushing <Simple ð> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7890>
<roadmr> jdstrand: sure thing, we're still stuck deploying the last one I pulled but I'll put this in the queue :)
<jdstrand> roadmr: if it would make it any easier, using this one instead of the last would be fine. up to you
<roadmr> jdstrand: well it's a sort of pipeline, the other one is in the pipeline regardless
 * cachio afk
<jdstrand> ok
<mup> PR snapd#7882 closed: devicestate: only run ensureBootOk() in "run" mode <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7882>
<sdhd-sascha> ijohnson: hi, commented the PR
<sdhd-sascha> is it possible, that there is some race-conditions on the tests ? Maybe they share some common resource, so if they run parallel on two or more repos, that they crash ? I'm new to snapd, so i didn't read the full source of the integration tests yet
<sdhd-sascha> cachio: I see you also commented on 7865.
<mup> PR snapd#7883 closed: snapstate: relax gadget constraints in ConfigDefaults Et al <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7883>
<roadmr> jdstrand: wow, this review-tools change broke 12 tests in the dashboard test suite :/
<pedronis> roadmr: I suppose it's snap_declaration tests?  we added quite a few interfaces
<roadmr> pedronis: yes, looks like it
<pedronis> roadmr: let me know if I can help or something isn't clear
<roadmr> pedronis: sure, I'll probably need a review on the MP that adjusts the tests
<roadmr> audio-playback was added, pulseaudio was removed?
<pedronis> roadmr: ok, np doing that
<pedronis> roadmr: pulseaudio wasn't removed but it's property changed
<pedronis> its
<pedronis> so it belong to different categories
<pedronis> now
<pedronis> roadmr: so I expect in those tests it will disapper from some sets and appear in others
<roadmr> pedronis: right I have pulseaudio in EXPECTED_NOT_PRIVILEGED_INTERFACES, where should it be now?
<roadmr> is it privileged now?
<pedronis> roadmr: yes
<pedronis> but I don't remember exactly the name of the vars and sets
<pedronis> I would need to look
<roadmr> pedronis: thanks, no problem, I just moved it to EXPECTED_PRIVILEGED_INTERFACES and that one test passes now
<roadmr> 11 more to go :) (Maybe this will fix some others too)
<pedronis> roadmr: some tests have used it explicitly those will be more fun
<roadmr> pedronis: I'm all for fun :)
<pedronis> roadmr: for the tests that use it explicitly maybe s/pulseauio/audo-playback/ is the easiest
<pedronis> fix
<roadmr> pedronis: sure, I can try that
<pedronis> ah, maybe not
<pedronis> need to think
<pedronis> roadmr: maybe they are fine as they are if they don't fail, it seems about the slot side
<pedronis> roadmr: where are the failures? mostly test_base ?
<roadmr> pedronis: https://pastebin.canonical.com/p/sqY2K8K6V6/
<pedronis> roadmr: ok, I can't look at that immediately and it's quite late here, can we continue tomorrow?
<roadmr> pedronis: totally, not a problem
<roadmr> pedronis: thanks!
<mup> PR snapd#7892 opened: many: pass a Model to the gadget info reading functions <Created by pedronis> <https://github.com/snapcore/snapd/pull/7892>
<roadmr> pedronis, jdstrand : (for tomorrow) wip on fixing these tests https://code.launchpad.net/~roadmr/software-center-agent/+git/software-center-agent/+merge/376657
<pokk> noob question. Is there any example of how to get a timer/service running? All I can find is people talking about how it should be used. Looking at the timers /etc/systemd/system is useful. But where should I be placing my own, user created, timer?
<pokk> I'll just go with my home dir I guess.
#snappy 2019-12-12
<mup> PR snapcraft#2835 closed: colcon plugin: support ROS 2 Eloquent <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2835>
<kyrofa> \o/
<mup> PR snapd#7893 opened: Remove screenshot deprecation notice <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/7893>
<mup> PR snapd#7892 closed: many: pass a Model to the gadget info reading functions <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7892>
<mup> PR snapd#7884 closed: snapstate: check gadget model constraints in checkSnap <UC20> <â Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7884>
<mup> PR snapd#7891 closed: devicestate: use correct model constraints in remodel/gadget updates <UC20> <â Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7891>
<mborzecki> morning
<mvo> mborzecki: good morning!
<mborzecki> mvo: hey
<mborzecki> and it's bug triage duty for me today
<mborzecki> quick errand
<zyga> good morning
<mvo> hey zyga
 * zyga needs to spend time debugging a few spread tests that show signs of more complexity than just the reboot
<zyga> hey pedronis
<zyga> I'll grab a quick breakfast while checking email
<mborzecki> re
<pstolowski> morning
<mvo> hey pstolowski
<mborzecki> pstolowski: hey
<zyga> pstolowski: hey hey :)
<mup> PR snapd#7594 closed: tests: replace "test-snapd-base-bare" with real "bare" base snap <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7594>
<zyga> degville: good luck on this historic day
<degville> zyga: thank you! I'm not too hopeful tbh, but we'll see.
<pstolowski> pedronis: hey, what do you mean by the comment to #7830: "Maybe you are thinking a snap with plugs and slots of interfaces that needs this?" ?
<mup> PR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7830>
<pedronis> pstolowski: that's a question of jdstrand
<mup> PR snapd#7894 opened: tests/main/parallel-install-remove-after: spread test <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7894>
<mborzecki> zyga: ^^
<zyga> yup
<pedronis> zyga: I'm probably confused about something,  does a layout bind-file  /etc/foo.conf -> $SNAP_DATA/etc/foo.conf also grant read access to /etc/foo.conf ?
<zyga> pedronis: AFAIK yes, for a weird way the kernel handles sockets
<zyga> let me double check
<pedronis> sockets ?
<zyga> give me a moment please
<pedronis> zyga: np, I don't think it's bad, but I'm trying to use something like this and want to understand if the layout is enough
<zyga> pedronis: I misread your question, the real layout would be $SNAP_DATA/etc/foo.conf -> /etc/foo.conf
<zyga> pedronis: so yes, we do add the permission for /etc/foo.conf as well
<pedronis> ok
<pedronis> thx
<zyga> pedronis: that's on apparmor/spec.go:357
<zyga> pedronis: the thing I mentioned about sockets is unique to content interface
<zyga> pedronis: where because of apparmor/lsm weirdness we grant additional permission to connect to a socket at the location it was bound to
<zyga> so if two snaps want to share an unix socket
<zyga> and snap one makes it in /var/snap/foo/common/socket
<zyga> then snap two gets it via content in /var/snap/bar/common/foo.socket
<zyga> it gets permission to connect to "/var/snap/foo/common/socket" as well, because otherwise connect doesn't work
<zyga> that's in content.go:226
<zyga> with a comment describing it above
<mup> PR snapd#7895 opened: many: add DeviceCtx.OperatingMode() <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7895>
<pedronis> zyga: where is the layout blacklist ? is /etc/systemd restricted ? (it doesn't seem to be in my testing)
<zyga> pedronis: it is in snap/validate.go AFAIR, I don't believe /etc/systemd is restricted, it won't affect the host
<zyga> pedronis: it may only affect systemd running inside your snap
<pedronis> zyga: thanks
<zyga> brb, power brick
<zyga> I think I will need to think about a "winter office" :/ in the kitchen
<zyga> as soon as real winter kicks in the office will become a fridge
<zyga> re
<mvo> sil2100: I uplloaded 2.43~pre1 to focal, so hopefully you have all you need there once its build
<zyga> brb
<zyga> at least working from the kitchen means tea is made quickly :)
<sil2100> mvo: \o/
 * sil2100 hugs mvo 
<zyga> re
<mup> PR snapd#7879 closed: devicestate: use httputil.ShouldRetryError() in prepareSerialRequest <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7879>
<mborzecki> pstolowski: is https://github.com/snapcore/snapd/pull/7658 next for landing in the preseed series?
<mup> PR #7658: cmd/snap-preseed: add snap-preseed executable <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7658>
<pstolowski> mborzecki: yes
<mborzecki> pstolowski: ok
<sdhd-sascha> Hey, will 18.04 get the next snapd version ?
<ogra> snapd is a rolling release ... everyone always gets the latest everywhere ;)
<sdhd-sascha> ogra: good to know. Then lesser trouble with lxd and snap-confine
<mborzecki> ogra: rolling release where it reexecs ;)
<jamesh> sdhd-sascha: if you want to test the new version with your snap, try running "snap refresh --beta core"
<jamesh> sdhd-sascha: you can switch back by refreshing to --stable
<ogra> mborzecki, well, other distros usually update too, just a bit later
<pokk> cachio: Hi, did you get your fix for rsync updated? Looking at https://snapcraft.io/rsync it seems like it's not been updated?
<mborzecki> do google:ubuntu-{16,18}.04-64:tests/main/interfaces-audio-playback-record fail for anyone else?
<zyga> mborzecki: pull master
<zyga> mborzecki: it's been fixed yesterday
<zyga> brb, let's use that tea and have a short break
<mborzecki> zyga: heh, ok, need to merge master to my branch then :/
<cachio> pokk, I'll update it, I didn't try
<sdhd-sascha> jamesh: thank you. i only run "snap refresh --candidate snapd" and the apparmor DENIED is gone
<sdhd-sascha> Have now updated the core too
<mup> PR snapd#7896 opened: interfaces/wayland: Add access to Xwayland's shm files <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/7896>
<sdhd-sascha> alan_g: +1 for 7896
<alan_g> sdhd-sascha, I don't think voting here helps. ;^)
<mborzecki> zyga: heh, inside lxd container with 18.04 on 18.04 host: Dec 12 12:11:31 my systemd[1]: system.slice: Failed to reset devices.list: Operation not permitted
<zyga> mborzecki: that's expected
<zyga> is this causing any failures?
<mborzecki> zyga: for a second there i thought it does, but looks like just a log in the systemd source code
<zyga> yep
<zyga> I remember reading that
<pstolowski> kjackal: hello, question under your old report: https://forum.snapcraft.io/t/restarting-services-from-configure-hook-race-condition/2513/13
<mborzecki> btw. jdstrand's fix for deny unix also fixed journal logging?
<zyga> 15 minute break
<zyga> mborzecki: how so?
<kjackal> pstolowski: looking
<mborzecki> zyga: i'm seeing [  698.940015] audit: type=1400 audit(1576153071.478:187): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-my_<var-snap-lxd-common-lxd>" profile="/snap/core/8213/usr/lib/snapd/snap-confine" name="/run/systemd/journal/stdout" pid=7017 comm="snap-confine" requested_mask="wr" denied_mask="wr" fsuid=1000000 ouid=1000 without the fix
<jdstrand> mborzecki: are you referring to my comment later in the bug or something else?
<jdstrand> mborzecki: yes, it does
<jdstrand> mborzecki: that is a named unix socket
<jdstrand> mborzecki: (even though it is mediated by 'file', that provides an additional clue on the bug since it is unix in the kernel
<jdstrand> )
<jdstrand> mborzecki: https://bugs.launchpad.net/apparmor/+bug/1855355/comments/3
<mup> Bug #1855355: Nested LXD install fails with snapd 2.42.4 (current stable core snap) <AppArmor:New> <snapd:Fix Committed> <https://launchpad.net/bugs/1855355>
<jdstrand> mborzecki: 2.42.5 should fix it
<mborzecki> jdstrand: looks like i was to eager to mark https://bugs.launchpad.net/snapd/+bug/1856057 as fix released instead of committed
<mup> Bug #1856057: Missing daemon service logs in LXD containers <snapd:Fix Released> <https://launchpad.net/bugs/1856057>
<mborzecki> pstolowski: zyga: can you check whether paintsupreme-3d snap does not segfault for you?
<pstolowski> mborzecki: checking
<zyga> checking
<pstolowski> mborzecki: yep, segfault
<pstolowski> Illegal instruction (core dumped)
<zyga> same here
<zyga>  /snap/paintsupreme-3d/2/bin/desktop-launch: line 204: 348665 Segmentation fault      (core dumped) $RUNTIME/usr/lib/$ARCH/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders > $GDK_PIXBUF_MODULE_FILE
<zyga> BÅÄdna instrukcja (zrzut pamiÄci)
<pstolowski> yep, same error from desktop-launch
<mborzecki> heh
<mborzecki> looking at the backtrace it fails somewhere in libnode
<zyga> it's always libnode ;)
<zyga> ok, I'll really take that break I was planning to before
<mborzecki> https://bugs.launchpad.net/snapd/+bug/1855969/comments/1 if you're interested in the backtrace
<mup> Bug #1855969: paintsupreme-3d does not run on Ubuntu 18.04 <18.04> <paintsupreme-3d> <snapd:Invalid> <https://launchpad.net/bugs/1855969>
<sdhd-sascha> zyga: i already seen an segmentation fault on sway snap with gdk-pixbuf before...
<sdhd-sascha> i think it's gone with gnome-extension in snapcraft.yaml or the right env's
<ogra> pedronis, see my last comment of the logsync thread ... i got it working, but not the way you suggested ... is it a bug that layouts fail for non-existing files ?
<pedronis> it should create them
<pedronis> ogra: maybe zyga can help
<ogra> well, it definitely doesnt, i tested on 16.04, core16 and core18
<zyga> ogra: can you describe what you mean
<ogra> the current solution works for me though
<zyga> ogra: what you did
<zyga> ogra: what you expected
<zyga> ogra: what you got
<ogra> zyga, see https://forum.snapcraft.io/t/manual-review-of-logsync-snap/14059/26
<ogra> the last few entries
<zyga> ogra: I _think_ this is a known bug, let me find it
<zyga> ogra: does this sound familiar https://bugs.launchpad.net/snapd/+bug/1843423
<mup> Bug #1843423: snap-update-ns fails to construct a layout in /etc/test-snapd/foo when /etc/test-snapd exists <snapd:Confirmed> <https://launchpad.net/bugs/1843423>
<ogra> thats a weird bug description but yeah, seems similar
<ogra> i didnt use a tmpfs indeeed
<ogra> (but bind mount)
<zyga> ogra: tmpfs is just a way to trigger it, the mechanics of the bug is the say
<zyga> *same
<ogra> yeah, tought so
<ogra> ayway, bind-mounting the whole dir seems to be a valid workaround
<zyga> afk for 15 minutes
<ogra> (funnily the dir is get in the 2snp run --shell" setup is completely empty ... but i can create the file i need and the app sees it in the right place)
<ogra> *snap run
<mup> PR snapd#7897 opened: overlord/snapstate: tweak assumes error hint <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7897>
<mborzecki> hah https://bugs.launchpad.net/snapd/+bug/1855155 is nice
<mup> Bug #1855155: snap install hangs if internet is disconnected exactly right after err upload starts <snapd:New> <https://launchpad.net/bugs/1855155>
<mborzecki> zyga: google:ubuntu-{16,18}.04-64:tests/main/interfaces-audio-playback-record keeps failing on #7894 with the latest master merged
<mup> PR #7894: tests/main/parallel-install-remove-after: parallel installs should not break removal <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7894>
<zyga> mborzecki: how does it fail?
<mborzecki> zyga: https://api.travis-ci.org/v3/job/624112055/log.txt
<mborzecki> weird
<zyga> hmmm
<zyga> is that reproducible?
<zyga> or just on a PR?
<zyga> (as in is that reproducible as a single run on master)
<mborzecki> zyga: heh, got a debug shell with master branch
<pstolowski> jdstrand: hey! thanks for taking a look at https://github.com/snapcore/snapd/pull/7830 (and sorry it landed without your review, was an oversight, i marked you as reviewer but probably should marked it Blocked as well). does it make sense what i wrote in the reply to your comment?
<mup> PR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7830>
<pstolowski> bbiab
<mborzecki> hmm pulseaudio mediates recording access itself?
<mborzecki> ok, so
<mborzecki> module-snappy-policy is not being loaded by pulseaudio in 18.04 and 16.04 images
<mborzecki> anyone know why?
<mborzecki> jdstrand: quick question, do you know if module-snappy-policy is still needed in pulseaudio?
<zyga> mborzecki: yes
<zyga> mborzecki: that's super weird because this test passed yesterday
<mborzecki> it passed in the morning too
<zyga> mborzecki: literally because it was failing in the opposite way
<zyga> mborzecki: so wtf
<zyga> s/f/h
<mborzecki> zyga: according to travis logs, it was still passing like 3h ago
<mborzecki> nothing in the package changelog
<ijohnson> morning folks
<ijohnson> mborzecki: always happy to find such interesting and fun bugs
<mup> PR snapcraft#2839 opened: plugs: add passthrough; check plug_dict is not empty <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2839>
<mborzecki> bwt. the standup doc is becoming really slow for me in FF
<ijohnson> degville: I looked over your glossary doc and it looks really good! I think it would also be a good idea to add "snappy" there and explain that can mean multiple things, i.e. snapd, ubuntu core, etc. and that AFAIK the term should be kinda deprecated now
<mup> PR snapcraft#2839 closed: plugs: add passthrough; check plug_dict is not empty <Created by sd-hd> <Closed by sd-hd> <https://github.com/snapcore/snapcraft/pull/2839>
<degville> ijohnson: thanks, and great idea about snappy. It's most definitely in a preliminary state, but I just wanted to get something up so we/I can iterate over it a little.
<ijohnson> degville: yes, understood, but I think it's looking great so far :-)
<Wouter0100> Hmmm, I've send a request for a Brand Store a week ago, but haven't received anything back. Is that normal? And, for my information, is a Brand Store paid? I haven't read much about this on the forums, but I could imagine it's paid due the way its requested (through sales :-P). This because I need to ship a package with access to `snapd-control`
<Wouter0100> for managing the snaps on the device.
<ogra> yes, brand stores are commercial things and need to be paid ... sales should reply to you soon
<Wouter0100> Ah, okay. Thanks, than let's have a look if we're able to make some deal work with you guys for my customer :).
<jdstrand> mvo (cc mborzecki): sigh, seb128 emergency reverted the pulseaudio SRU since there was a snapd-glib issue that was affected users so now we need to revert the PRs to mediating pulseaudio
<jdstrand> s/to mediating/for mediating/
<mborzecki> jdstrand: whole PR or just disabling the tests until things are fixed again?
<jdstrand> mvo (cc mborzecki): ie, just the testsuite update from yesterday
<jdstrand> or was it tuesday
<jdstrand> |R 7885 and PR 7886
<jdstrand> erf PR 7885 and PR 7886
<mup> PR #7886: tests: 16.04 and 18.04 now have mediating pulseaudio - 2.43 <â  Critical> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7886>
<mup> PR #7885: tests: 16.04 and 18.04 now have mediating pulseaudio <â  Critical> <Created by jdstrand> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7885>
<mvo> jdstrand: ok, thanks
<jdstrand> mvo (cc mborzecki): they are working to fix that, so the tests will break again when it goes through
<mvo> I think I will directly revert on master without  a PR
<jdstrand> mborzecki: you said something elsewhere about making them manual?
<mvo> mborzecki:  I think I will directly revert on master without  a PR> WDYT?
<mborzecki> jdstrand: yeah, we can skip that test on 16.04 and 18.04 specifically (mvo?)
<mborzecki> jdstrand: manual would make the whole test non-runnable on travis
<jdstrand> we at least know the test works: it caught that the mediation patches were dropped
<jdstrand> (and added)
<jdstrand> so, 'yay'?
<jdstrand> :)
<mvo> mborzecki: manual on 16/18 works for me too, no strong opinion
<mvo> mborzecki: if we switch it to manual we just need a card that reminds us to re-enable it agian once the dust settled
<mborzecki> mvo: reverting 0552bf0ad62dfad0a92db01350774e77aa82f428 will save 2 spread runs (or more if we need to restart)
<jdstrand> mborzecki: well, I would prefer a revert and reapply after the new SRU since they are working as designed and it is just a one line change. unless you foresee a back and forth and don't want them to break up over and over until the dust settles
<jdstrand> which is a fair stance
 * jdstrand has no strong opinion
<mvo> mborzecki: ok, I will revert on master
<mvo> both reverted
<mvo> well, the patch is reverted on both master and release/2.43
<mborzecki> mvo: cool, thank you!
<mup> PR snapcraft#2840 opened: plugs: plugs can have no element <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2840>
<jdstrand> mvo: thanks
<mvo> yw
<mup> PR snapcraft#2841 opened: plugs: add passthrough <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2841>
<jdstrand> mvo: I'm trying to get info in #ubuntu-release on the timing of the update to add it back again
<jdstrand> mvo: it would be a shame if the sru landed late next week or during the break
<jdstrand> I guess it would be easy enough to revert the revert, but still
 * cachio lunch
<jdstrand> mvo: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1781428/comments/21
<mup> Bug #1781428: please enable snap mediation support <patch> <verification-failed> <verification-failed-bionic> <verification-failed-xenial> <pulseaudio (Ubuntu):Fix
<mup> Released by jamesh> <pulseaudio (Ubuntu Xenial):Fix Committed by jamesh> <pulseaudio (Ubuntu Bionic):Fix Committed by jamesh> <https://launchpad.net/bugs/1781428>
<mvo> jdstrand: thanks, reading this now
<jdstrand> mvo: trying to have your back :)
<mvo> jdstrand: yeah, thanks for that!
<jdstrand> :)
<sdhd-sascha> zyga: just have a discussion on snapcraft. Is it possible to add "wayland" to the global plugs and then it's for all apps ? I thought you wrote this to me on the first days
<zyga> sdhd-sascha: yes, please open a topic abou tit
<zyga> *about it
<sdhd-sascha> i opened a PR on snapcraft... ok, i wait
<zyga> no no
<zyga> not a pr on snapcraft
<zyga> please open a thread on the forum
 * zyga goes for another meeting
<sdhd-sascha> zyga: done. But until i got answer. I have to work with my patched version.
<sdhd-sascha> the PR was, because snapcraft 3.9.x crash. So something have to be done there
<ijohnson> degville: it occured to me I forgot to type up a little blurb for you about how global plugs and explicitly delcared plugs interact, but I responded to sdhd-sascha on the forum about how this works here: https://forum.snapcraft.io/t/plugs-in-global-position-in-snapcraft-yaml/14618/2
<ijohnson> hope that helps in writing up a doc on how to do this properly
<degville> ijohnson: great, thank you! looks good.
<sdhd-sascha> degville: ijohnson: thanks. my snapcraft is know 60 line longer :-(
<sdhd-sascha> *now
<ijohnson> sdhd-sascha: can't you just declare them globally once and not declare any plugs for apps/hooks ?
<sdhd-sascha> oh, wait
<sdhd-sascha> sorry
<ijohnson> sdhd-sascha: the thing you want to avoid is having both the global plugs and the per-app / per-hook plugs
<sdhd-sascha> the global case crashes in 3.9.x if the plug is empty
<ijohnson> oh well that's unfortunate
<sdhd-sascha> it's since interface is in snapcraft/internal/meta/plugs.py
<sdhd-sascha> https://github.com/snapcore/snapcraft/pull/2840/commits/0dc7ab09f4b7e0f7744a7606b8b7a80553c89dac
<mup> PR snapcraft#2840: plugs: plugs can have no element <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2840>
<sdhd-sascha> ijohnson: just overwrite None
<sdhd-sascha> above
<sdhd-sascha> but, then another validation fails... :-(
<sdhd-sascha> afk
<sdhd-sascha> the error with my patch: "failed to validate plug=hardware-observe: plug has no defined interface"
<sdhd-sascha> now, afk
<ijohnson> sdhd-sascha: not sure about why snapcraft fails that way, I'd recommended asking about why snapcraft dies like that over in #snapcraft
<mborzecki> meh, multipass lanch failed, apaprently qemu-img grashed or sth, and there's a denial in the logs:
<mborzecki> apparmor="DENIED" operation="file_mmap" profile="multipass.qemu-img" name="/var/lib/snapd/snap/multipass/1425/usr/bin/qemu-img" pid=649663 comm="qemu-img" requested_mask="rm" denied_mask="rm"
<pokk> ok, next stupid question. Should rsync over ssh not work on ubuntu core? Doing `rsync me@1.2.3.4:/path` I get "rsync: Failed to exec ssh: Permission denied (13)" followed by "rsync error: error in IPC code (code 14) at pipe.c(85) [sender=3.1.1]"
<mborzecki> hmm, but multipass is classi, wth
<ijohnson> mborzecki: that doesn't look like a snap profile? `profile="multipass.qemu-img"` ?
<ijohnson> mborzecki: also what's the status of https://github.com/snapcore/snapd/pull/7570 shall I review that?
<mup> PR #7570: [RFC] snap-mount-dir: add mount unit for snap-mount-dir <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7570>
<mborzecki> ijohnson: yeah, looks like something internal to multipass
<mborzecki> ijohnson: it's on hold now, we found a problem that we don't know how to address in a clean way yet
<ijohnson> mborzecki: ack I added the blocked label to show this
<mborzecki> ijohnson: cool thanks
<pokk> cachio: would you happen to know why ssh isn't allowed to be used with rsync as well? I'm guessing it's some kind of permission problem as well, but I know way to little about it to debug it
<cachio> pokk, do you see any denial when you do journalctl -u snapd?
<ogra> pokk, how did you get rsync installed in the first place ?
<ogra> (i dont think it is in the core snap (definitely not in core18)
<ogra> )
<pokk> ogra: using https://snapcraft.io/rsync but the test version of it
<ogra> pokk, well, i doubt that has access to your credentials on the host
<pokk> ogra: No I would buy that, but wouldn't that give me a different error?
<ogra> well, it tells you permission to access credentials are denied :) doesnt it ?
<pokk> well that highlight didn't really work, cachio https://pastebin.com/K4XTRt7U
<pokk> I don't see any errors
<ogra> well, in fact it tells you it cant exec ssh
<ogra> so thats even before checking credentials
<ogra> the rsync snap would have to ship its own openssh copy i guess (so the binary is there) and then would need allowance to access your credentials
<pokk> ogra: right, that's the part that I'm very new to how it works.
<pokk> and having a hard time googling
<pokk> I guessed it was something along those lines tho :/
<ogra> well, snap applications run under confinement ... they can not see most of the os by default
<pokk> right, but for me it would make sense to have rsync be able to access at least ssh. Given it's wide use together
<ogra> typically a snap should ship all binaries it needs inside the snap
<jdstrand> mborzecki: notice the profile name is multipass.qemu-img
<ogra> for the credentials there are two interfaces ssh-keys and ssh-public-keys ... but for the binary itself there is nothing i think
<jdstrand> mborzecki: multipass loads a profile to launch vms under
<pokk> ogra: right, but how would one know what is shiped? Looking at https://snapcraft.io/rsync or https://snapcraft.io/rsync-leftyfb there's very little information abut that
<jdstrand> mborzecki: it is that profile that would need adjusting
<ogra> pokk, you'd have to either look at the snapcraft.yaml inside the snap (if it ships one, not all of them do) or ask the packager
<ogra> technically you can indeed just snap download any snap and run unsquashfs on it to inspect the content
<ogra> mvo, setting/unsetting a proxy does not restart snapd ? (so the change isnt picked up on core until i reboot) ... is that wanted ?
<mvo> ogra (in a meeting, so a bit slow). snapd should pick this up dynamically, i.e. not look at the environment but instead at the config
<mvo> ogra is it not working for you?
<ogra> mvo, i had a non-existent proxy set for a demo ... did a snap unset on it and snapd still tried to use the proxy url until i ran  sudo systemctl restart snapd
<ogra> probably the unset itself is the issue ... i dont think i had to restart it when i used the set command
<ogra> hmm, no, snap set has the same issue ...
<ogra> mvo, https://paste.ubuntu.com/p/KrmBQjyMZp/
<ogra> smells like a bug then
<mborzecki> jdstrand: filed a bug, looks like it's being generated on the fly? aa-status doesn't list it, can't really switch it to complain mode
<mvo> ogra: yeah, that sounds like a bug, that's a bit depressing
<ogra> i'll file it before EODing
<mvo> ogra thank you
<jdstrand> mborzecki: I don't know if it is stored on disk, but:
<jdstrand> $ sudo aa-status|grep multipass
<jdstrand> ...
<cachio> pokk, sorry, I was in a meeting
<jdstrand>    multipass.snapcraft-znc-cs.qemu-system-x86_64
 * zyga goes for another meeting
<cachio> so, what you can't do with rsync?
 * zyga should not alt-tab up-enter
<zyga> eh
<zyga> heh
<jdstrand> mborzecki: you can aa-exec -p multipass.snapcraft-znc-cs.qemu-system-x86_64 -- your command
<jdstrand> mborzecki: of course, that is for a non-failed stopped vm
<mborzecki> jdstrand: aa-status |grep multipass only lists the profiles generated by snapd :/
<cachio> mborzecki, hey, when you have time, could you please take a look to this one? https://bugs.launchpad.net/snapd/+bug/1856073
<mup> Bug #1856073: Snap services not being removed correctly after snap removal <snapd:New> <https://launchpad.net/bugs/1856073>
<mborzecki> guess, i'll just use my qemu wrapper instead
<jdstrand> mborzecki: I'm still on beta. maybe it is a difference between 0.9 and 0.10
<marcustomlinson> ijohnson: hey, on the topic of snap startup performance: https://forum.snapcraft.io/t/an-investigation-into-snap-startup-speed/14619
<ijohnson> hi marcustomlinson thanks, I will try to take a look at that today
<marcustomlinson> cool :)
<pokk> cachio: no worries :) As ogra suggested I'm guessing it's a permission error due to rsync not having access to ssh?
<cachio> rsync does not an interface for ssh
<pokk> ogra, cachio I'm not sure if I'm abusing what Core is intended for. To me it seemed like a really good fit. I just want a minimal install with simple updates to keep it safe. For a super small remote backup service. Something that will ssh into my NAS and rsync over a backup.
<pokk> it seems like an ideal use of Core. But maybe not
<cachio> pokk, this is the definition of the rsync snap https://bazaar.launchpad.net/~snappy-dev/snappy-hub/rsync/view/head:/snapcraft.yaml
<ijohnson> mvo: is there maybe an issue with the changelog script? https://github.com/snapcore/snapd/commit/d5d937e2f4c2f90de564beaff78a1742e7e5bd2c#diff-72a2d7a5614a41a35eaf22c94697dbf0R374
<pokk> cachio: right, so just the removeable-media that we disussed last time around :)
<cachio> pokk, yes
<cachio> pokk, could you try the ssh which is not working and then execute "dmesg | grep DENIED"
<cachio> and show the output
<cachio> so I can see which interfaces are needed
<mvo> ijohnson: uh, yes - nice catch
<mvo> ijohnson: thanks, let me fix that, sometimes it gets confused, it's not super high-tech
<ijohnson> np, just thought I'd make you aware :-)
<mvo> ijohnson: thanks! and fixed in 2.43
<Saviq> mborzecki: hey, re: https://github.com/CanonicalLtd/multipass/issues/1223 - if you can suggest a fix to the profile, we'd love to know!
<cachio> pokk, I'll be afk 20 minutes, please leave the info you get and I'll read it once I am back
<mborzecki> Saviq: sure, i need to take a look where the profiles come from first ;)
<Saviq> mborzecki: https://github.com/CanonicalLtd/multipass/blob/master/src/platform/backends/shared/linux/qemuimg_process_spec.cpp#L39
<mborzecki> Saviq: thanks!
 * cachio afk
<ogra> pokk, core should be great for that but you probably need to create your own application snap for the backup solution you want
 * zyga -> supper 
<pokk> ogra: I sort of assumed rsync would already be doing all I needed. But yeah, I can try and figure out how to create my own rsync snap
<ogra> i fear that rsync can simply do rsync and nothing more :)
<pokk> cachio: not sure what more info you need? If needed I can try and create my own snap for it. If you don't think it's reasonable to add ssh to rsync
<pokk> rsync without ssh seems a bit limited imho, but it might be due to how I've always been using it
<ogra> me too ... but i havent had any need to use it on core yet ...
 * zyga went to explain browser security basics to his 10yo daughter
<zyga> prompted by "cat following the browser" icon at school
 * ogra files https://bugs.launchpad.net/snapd/+bug/1856212
<mup> Bug #1856212: setting/unsetting proxy requires snapd restart on core18 <snapd:New> <https://launchpad.net/bugs/1856212>
 * ijohnson has managed to break installing the most basic of test snaps on his machine
<mup> PR snapd#7898 opened: overlord: replace DeviceContext.OldModel with GroundContext  <Created by pedronis> <https://github.com/snapcore/snapd/pull/7898>
<mup> PR snapd#7899 opened: many: pass consistently boot.Device state to boot methods <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7899>
<cachio> pokk, I think in this case initially you could copy the snapcraft.yaml and add the ssh
<cachio> and use it, I'll talk tomorrow to the team to see which is the best way to cover all the alternatives for rsync and I'll add a new snap version
<pedronis> mvo: proposed #7898 following up on #7895, and then #7899
<mup> PR #7898: overlord: replace DeviceContext.OldModel with GroundContext  <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7898>
<mup> PR #7895: many: add DeviceCtx.OperatingMode() <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7895>
<mup> PR #7899: many: pass consistently boot.Device state to boot methods <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7899>
 * zyga -> coffee
 * genii 's ears perk up momentarily at the mention of coffee, then he wanders back to work
<mvo> pedronis: cool, I started with 7898
<mvo> pedronis: and will see how far I get
<mup> PR snapcraft#2842 opened: rust: add support for workspaces <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2842>
<pokk> cachio: cool, I'll play around with it. Haven't done any snaps before
<cachio> pokk, just copy that file and run snapcraft command
<cachio> it  will create the snap
<cachio> then you can add the interface you want and try to create the snap again
<cachio> pokk, just ping me if you need any help
<mup> PR snapcraft#2841 closed: plugs: add passthrough <Created by sd-hd> <Closed by sd-hd> <https://github.com/snapcore/snapcraft/pull/2841>
<mup> PR snapd#7895 closed: many: add DeviceCtx.OperatingMode() <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7895>
<mup> PR snapd#7898 closed: overlord: replace DeviceContext.OldModel with GroundContext  <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7898>
<mup> PR snapd#7897 closed: overlord/snapstate: tweak assumes error hint <Simple ð> <Created by bboozzoo> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7897>
<mup> PR snapd#7894 closed: tests/main/parallel-install-remove-after: parallel installs should not break removal <Simple ð> <Created by bboozzoo> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7894>
<mup> PR snapcraft#2843 opened: snap: only ship .pyc files, strip shared objects <Created by om26er> <https://github.com/snapcore/snapcraft/pull/2843>
#snappy 2019-12-13
<mup> PR snapd#7900 opened: tests: do reset of tests during restore and add checks to validate the fs <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7900>
<mup> PR snapd#7901 opened: run-checks: check multiline string blocks in restore/prepare/execute sections of spread tests <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7901>
<mborzecki> morning
<zyga> mborzecki: hello
<mborzecki> zyga: hey
<mborzecki> zyga: #7901 trivial PR
<mup> PR #7901: run-checks: check multiline string blocks in restore/prepare/execute sections of spread tests <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7901>
<zyga> mborzecki: thank you and done :-)
<mborzecki> zyga: yay :) thx
<pstolowski> good morning
<mborzecki> pstolowski: hey
<mvo> hey pstolowski and mborzecki
<mborzecki> mvo:  hey
<mvo> sdhd-sascha: 7881 looks like it can land. did you sign the CLA already?
<sdhd-sascha> Good morning
<sdhd-sascha> mvo: i think i have signed it on launchpad and on some homepage. Not sure if it was the same
<mvo> sdhd-sascha: cool, thank you
<mup> PR snapd#7881 closed: intrefaces: login-session-control - added missing dbus commands <Created by sd-hd> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7881>
<mvo> 7858 looks like an easy win, just needs a second review
<mup> PR snapd#7901 closed: run-checks: check multiline string blocks in restore/prepare/execute sections of spread tests <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7901>
<zyga> hey mvo
<mvo> hey zyga
<zyga> sorry for starting late, I had some things at home that needed my time
<mvo> thanks mborzecki for the 7899 review!
<zyga> I need to work a little over weekend
<zyga> and catch up
<mborzecki> mvo: np, did't want to commit that whitespace change since travis is already running, we can clean it up when doing some later changes
<mvo> mborzecki: yeah, I would prefer to land and fix in one of the followups
<mborzecki> mvo: maybe you have permissions to push to https://github.com/snapcore/snapd/pull/7896
<mup> PR #7896: interfaces/wayland: Add access to Xwayland's shm files <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/7896>
<mvo> mborzecki: I have the same issue, look like only Alan can do this :/
<mup> PR snapcraft#2797 closed: meson plugin: add support for core20 <Created by sd-hd> <Closed by sd-hd> <https://github.com/snapcore/snapcraft/pull/2797>
<mborzecki> oh, well, we'll just have to wait then
<mup> PR snapd#7899 closed: many: pass consistently boot.Device state to boot methods <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7899>
<Saviq> mborzecki: hey, re: the qemu-img AppArmor denial, does this change look sane https://paste.ubuntu.com/p/k8Shd4WyCP/ (where %3â¦%4 is the full path to qemu-img) ?
<Saviq> should we have "m" for all the executables we want to run?
<Saviq> (and why isn't this required on Ubuntu Â¿?)
<mborzecki> Saviq: does it work on debian with apparmor?
<zyga> mborzecki: we don't use apparmor on debian
<mborzecki> Saviq: or opensuse for that matter
<mborzecki> zyga: it's multipass, and it's classic, from what i can tell, it'll try to use aapparmor when aa_is_enabled returns it's on
<zyga> ah
<zyga> that's interesting
<zyga> more confined than snaps :)
<zyga> Saviq: on debian all file rules work the same
<mborzecki> zyga: this is what I got on arch yday: https://github.com/CanonicalLtd/multipass/issues/1223
<mborzecki> zyga: unclear why it's trying to map qemu-img for reading when there's supposed to be ixr permissions
<zyga> looking
<zyga> after some kernel version "m" became required as well
<pedronis> mvo: thanks for landing my PRs, hope they weren't too confusing ...
<mup> PR snapd#7889 closed: overlord,o/snapstate: make sure we never leave config behind <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7889>
<pstolowski> pedronis: hi, #7658 is ready for you re-review if you have a moment
<mup> PR #7658: cmd/snap-preseed: add snap-preseed executable <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7658>
<pedronis> pstolowski: thx, saw that
<mvo> pedronis: no, great stuff, I'm in the weeds of uc20 right now
<mborzecki> Saviq: ok, got something that works https://paste.ubuntu.com/p/mV9fR5M3hf/
<mborzecki> Saviq: and looks like stderr may not be redirected when you're running qemu-img
<mborzecki> Saviq: /snap is a symlink on arch & fedora
<mborzecki> Saviq: ok, added a note too
<pedronis> I created the Done 2.44 lane
<Saviq> mborzecki: thanks!
<mup> PR core20#16 opened: bootstrap from locally build snapd snaps too <Created by mvo5> <https://github.com/snapcore/core20/pull/16>
<mup> PR snapd#7893 closed: daemon,snap: remove screenshot deprecation notice <Created by robert-ancell> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7893>
<sdhd-sascha> Why does the x11 interface has no support to access: @/tmp/.X11-unix/X[0-9]*
<sdhd-sascha> In the plug-case
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/7658#pullrequestreview-331769593
<zyga> sdhd-sascha: looking
<mup> PR #7658: cmd/snap-preseed: add snap-preseed executable <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7658>
<sdhd-sascha> zyga: i see, there is access to Xauthority. But sway's source want to access the socket.
<zyga> sdhd-sascha: did you look at abstractions/X?
<pstolowski> zyga: thanks!
<sdhd-sascha> zyga: wait
<zyga> sdhd-sascha: there are include rules in that snippet
<zyga> sdhd-sascha: those go to /etc/apparmor.d/abstractions/X
<zyga> I suspect it is handled there
<zyga> pstolowski: description of https://github.com/snapcore/snapd/pull/7658 seems out of date, it sets SNAPD_PRESEED, not SNAPD_PREBAKE_IMAGE
<mup> PR #7658: cmd/snap-preseed: add snap-preseed executable <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7658>
<pedronis> pstolowski: I made a countercomment to zyga comment about the help.
<zyga> pedronis: the long description will never capture everything that is done by the implementation, nor should it, it should just be comprehensible
<zyga> there are better places to capture details, like man pages for example
<zyga> pedronis: but that's a minor point, I didn't block or intend to block over that
<pedronis> I made a middle ground suggestion
<mborzecki> pedronis: this could use your input too https://bugs.launchpad.net/snapd/+bug/1856063
<mup> Bug #1856063: snap set refresh.hold immediately triggers a refresh when set <snapd:Confirmed> <https://launchpad.net/bugs/1856063>
<mborzecki> pedronis: perhaps we should also set up automatic 2h refresh.hold for core devices too
<pedronis> mborzecki: no but open to other options
<pedronis> mborzecki: it's by design that core images try to refresh as soon as possible
<pedronis> mborzecki: multipass images are a bit of a odd case, because of how they tend to be used
<mborzecki> pedronis: maybe something we could do from cloud-init level?
<pedronis> maybe
<pedronis> mborzecki: anyway I put some guardrails comment in the bug
<mborzecki> pedronis: cool, thanks!
<pedronis> me just noticed a different papercut
<sdhd-sascha> zyga: ah, and there it is again.
<sdhd-sascha> Before i start to hack 'snapd', a RFC could be nice. I need to split X11 into a X11-provider and a X11-consumer. To make things work.
<zyga> sdhd-sascha: why?
<zyga> sdhd-sascha: provider is the slot, consumer is the plug
<zyga> sdhd-sascha: they have separate properties
<sdhd-sascha> zyga: sway can run under X11, then the abstraction/X is enough
<sdhd-sascha> but currently it creates a X11 socket...
<sdhd-sascha> so i need the slot permissions, too
<zyga> sdhd-sascha: if it creates an x11 socket in a common path it needs to have an x11 slot
<zyga> sdhd-sascha: but is it a generic x11 server?
<sdhd-sascha> yes, but both didn't work
<sdhd-sascha> it's Xwayland inside X
<zyga> sdhd-sascha: should it make sense to connect an app to sway instead of to the system x11 slot?
<sdhd-sascha> inside sway
<sdhd-sascha> i run on a system, without any gui
<sdhd-sascha> i have no system x11 slot there
<sdhd-sascha> sway snap is the only desktop
<zyga> sdhd-sascha: I don't know the answers to my questions but I just want to highlight that splitting any interface into a -provide and -consumer is bad idea because it is already part of the existing design
<zyga> sdhd-sascha: then you just should have an x11 slot IMO
<ogra> you should probably talk to the guys in #mir-server ;)
<ogra> (the mir-kiosk snap supports XWayland (in fact all apps use i3wm by default for fullscreen)
<sdhd-sascha> Well, i can look if the slot permission are good enough to work as plug too
<ogra> )
<mup> PR snapd#7902 opened: o/hookstate/ctlcmd: fix command name in snapctl -h <Simple ð> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7902>
<pedronis> that's the papercut fix
<sdhd-sascha> Hey, if the slot permission is not enough. Then i could change to allow same names of slot and plug. E.g. allow X11 as slot and X11 as plug in the same snap. Or ?
<sdhd-sascha> ogra: thanks, i joined to #mir-server
<pedronis> pstolowski: thx for the review, I just noticed this randomly
<mborzecki> https://bugs.launchpad.net/snapd/+bug/1856073 is interesting, systemd records the state of failed service unit and keeps it around even after the unit is gone, imo it's kind of useful, and don't think we should do anything about that
<pstolowski> yw
<mup> Bug #1856073: Failed service state recorded by systemd even after snap removal <snapd:Confirmed> <https://launchpad.net/bugs/1856073>
<pedronis> mborzecki: when does it forget though? next boot? never?  or are we missing a daemon-reload?
<mborzecki> pedronis: when one runs reset-failed or next boot (maybe reexec too)
<pedronis> ok
<pedronis> mborzecki: yea, I agree we shouldn't go to out of our ways to change this, unless it creates problems if you reinstall the snapd or if it was a missing daemon-reload
<pedronis> s/snapd/snap/
<zyga> mborzecki: it is useful, we can look at why snap install failed because services failed to start :)
<zyga> pedronis: there's a command to explicitly forget
<zyga> pedronis: otherwise it forgets on reboot, it's only in memory
<Saviq> zyga: is /var/lib/snapd stable across distros?
<Saviq> (for the /snap symlink)
<zyga> Saviq: yes
<zyga> Saviq: (thank god :D
<Saviq> indeed
<zyga> Saviq: not sure how it relates to /snap symlink, do you mean the /var/lib/snapd/snap symlink?
<zyga> (the one that points there)
<mborzecki> zyga: we haven't checked hannah montana linux though ;)
<zyga> Saviq: then indeed that is stable :)
<Saviq> zyga: I mean /snap â /var/lib/snapd/snap, yes
<zyga> Saviq: that's 100% stable
<zyga> mborzecki: :-)
<zyga> mborzecki: cannot wait for a distro /apps and /system
<mborzecki> zyga: don't you have one right now? :P
<mborzecki> not exacly linux though
<zyga> mborzecki: no, it's /Applications ;-) and it can be localized
<zyga> (but without changing the filesystem)
<zyga> jdstrand: (just FYI) https://github.com/snapcore/snapd/pull/7875#discussion_r357611665
<mup> PR #7875: interfaces: refactor path() from raw-volume into utils with comments for old <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7875>
<zyga> degville: I don't know if you ever worked with i18n in software, if you did it's old news, if you didn't you may find that interesting
<degville> zyga: thanks for the link - I did, briefly, when I was writing my own stuff, never from a real docs perspective.
<degville> and that was with Qt, which had a very set way of doing things.
<zyga> brb, need to get coffee and warm up
<zyga> I'm so cold this week :/
<pokk> zyga: it's been around 0 and raining here for a month, not to mention that the sun barely comes up at all :| I hate this time a year
<ogra> zyga, you should move to spain !
<zyga> pokk: indoors? :) ?
<zyga> pokk: my office is not insulated very well so it's ... very fresh in the morning
<pokk> zyga: nah, we're used to cold weather so indoors it's decently warm. I'd much prefer -20 over this to be honest
<zyga> pokk: where are you based if I may ask?
<zyga> pokk: here it's around 3-7C during daytime and -1-ish at night
<pokk> zyga: Sweden
<zyga> pokk: ah, I guess you don't build uninsulated anything, unlike us here
<mup> PR snapd#7903 opened: overlord,boot: follow ups to #7889 and #7899 <Simple ð> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7903>
<mup> PR snapd#7902 closed: o/hookstate/ctlcmd: fix command name in snapctl -h <Simple ð> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7902>
<pstolowski> pedronis: hey, i may need to discuss with you some aspects of services once again, it shouldn't take long. do you have a moment today?
<zyga> pedronis: that follow-up is just extra test, right?
<zyga> pedronis: looks good, just wanted to make sure I understand it
<pedronis> zyga: yes, just doing the thing people ask to improve the test
<zyga> understood
<zyga> thanks
<pedronis> pstolowski: maybe just after standup
<pstolowski> pedronis: great
<pedronis> mborzecki: 7903 is probably for you when you have a moment (it's not urgent and it's small)
<pokk> zyga: no, not really. Especially not the more newly built houses. We can take -30C without much problem here
<pedronis> degville: how should I submit comments for the glossary ?
<degville> pedronis: would it help if I paste it into a gdoc? or you can make the edits yourself, or leave a comment on the posts. Whichever is easiest for you.
<pedronis> degville: I just skimmed for now, I'll know more when I have done a good read through, I'll let you know (probably actually not today)
<pedronis> degville: thanks for it btw
<degville> pedronis: no problem, thanks!
<degville> I'm still adding things.
<pedronis> degville: a quick thing though, I think you go the description of core and core16 reversed, core is the one that includes snapd
<pedronis> s/you go/you got/
<degville> pedronis: oops, thanks!! I'll fix that now.
<pedronis> core16 doesn't carry it and is not stable/done yet, that part is correct
<zyga> brb
<om26er> Hi! Is sergiusens off today (or is it the timezone difference he is not online ?)
<om26er> I need to talk about https://github.com/snapcore/snapcraft/pull/2843 and know if that change is acceptable in principle
<mup> PR snapcraft#2843: snap: only ship .pyc files, strip shared objects <Created by om26er> <https://github.com/snapcore/snapcraft/pull/2843>
<zyga> re
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/7875 is close and needs a small amount of iteration from you to land
<mup> PR #7875: interfaces: refactor path() from raw-volume into utils with comments for old <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7875>
<pedronis> om26er: he is off until next year, maybe cjp256 can help
<cjp256> om26er: it's an interesting one! it was in my queue to look at more closely today, but it's something sergiusens will certainly be opinionated about.  :D
<mup> PR snapd#7896 closed: interfaces/wayland: Add access to Xwayland's shm files <Created by AlanGriffiths> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7896>
<om26er> cjp256 cool, we could have something similar for the python plugin as well, that will likely reduce the size of python based snaps
<ogra> om26er, while that is really cool, it should be handled via a snapcraft.yaml option though
<om26er> ogra I was writing a message to you to get your opinion as you had wrote on the forum about a similar topic
<om26er> ;-)
<ogra> i love the approach ... but as i said, it shuld be configurable ...
<om26er> ogra the above proposed change is only for Snapcraft package itself. I will investigate into the python plugin and figure out how to do that for it, so other snaps could use that feature as well
<ogra> (you might want to build an "arch all" python snap that only ships .py files by default ... i.e. the exact opposite)
<ogra> ah,  thought it was for the plugin actually
<ogra> *I thought
<cjp256> i agree
<cjp256> ogra: i would have guessed the pyc was platform independent?  is that not the case?
<ogra> dunno, can you run a pyc file compiled on armhf on an amd64 machine ? i never tried
<ogra> specially if it comes to HW related stuff like talking to sensors etc i suspect there are many arch specifics in the backend
<ogra> *especially
<om26er> pyc are platform independent...
<ogra> k
 * om26er is working on a story on how he reduced a snap size by more than 60%
<om26er> stripped shared objects, only shipped pyc files and by using Python 3.6 from core18
<cjp256> i left my comments in the PR, but generalized stripping should be a flag soon enough (it's on my todo list).  and I think it would be interesting to provide a flag for the *.py code, under circumstances we know it'd be OK
<om26er> for the last it was only a matter of adding /snap/core18/current/usr/bin to PATH.
<om26er> wonder if snaps are mounted at a different mount point on other distros ?
<cjp256> what was core18 added to path for?
<om26er> thanks cjp256, I will take a look
<om26er> cjp256 to reuse python3 from there instead of shipping a copy with my snap (saves 7mbs)
<cjp256> ah, well that's where I think you might run into problems if shipping only pyc
<cjp256> if core18 updates with a patched python that's somehow incompatible with the separately shipped pyc?
<ogra> om26er, other distros might use some dir under /var/lib instead of /snap ...
<ogra> /snap is very ubuntu specific
<mup> PR snapd#7904 opened: snapcraft.yaml: add type, build-base and adopt-info, rm builddeb plugin <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7904>
<om26er> will figure out a solution for that, likely by looking at $SNAP and finding core18 directory relative to that
<om26er> @cjp256 that's indeed a challenge but I am hoping python in core won't have any API breaking changes, though I need to read a bit more into this to get an idea of how probably a failure is
<Saviq> mborzecki: would you please try https://github.com/CanonicalLtd/multipass/pull/1228#issuecomment-565418688 out when you have a moment?
<mup> PR CanonicalLtd/multipass#1228: [utils] resolve symlinks to snap directories (Fixes #1223) <Created by Saviq> <https://github.com/CanonicalLtd/multipass/pull/1228>
<Saviq> zyga, if you have something like Debian or Fedora on hand, that would be great, too â
<mborzecki> Saviq: nice, you collect the build artifacts!
<Saviq> mborzecki: yeah, it was just too tiring to have to rebuild locally all the time :)
<Saviq> you're welcome to some code https://github.com/CanonicalLtd/multipass/blob/master/tools/report_build.py :)
<Saviq> pretty simple to use, too https://github.com/CanonicalLtd/multipass/blob/master/.travis.yml#L139
<mup> PR snapd#7903 closed: overlord,boot: follow ups to #7889 and #7899 <Simple ð> <Created by pedronis> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7903>
<ijohnson> pstolowski: do you want me to just push to your snapcraft.yaml branch then? I think the only thing my branch has that yours doesn't is removal of the x-builddeb plugin
<pstolowski> ijohnson: nope, it's fine, go ahead with yours (minus type:)
<ijohnson> pstolowski: ack thanks, I think I might take a few of your changes to the tests though that I missed when writing it yesterday
<ijohnson> thanks!
<pstolowski> ijohnson: fyi, my branch incorporated some old changes from cmatsuoka, so it's really a team effort ;)
<ijohnson> :-)
<ijohnson> I will credit both of you in my commit message
<ijohnson> sil2100: hey I was wondering about the UC images we have on cdimage, I'm wondering specifically what's the difference between http://cdimage.ubuntu.com/ubuntu-core/18/current/ and http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/ ? the former seems regularly updated, but the latter hasn't been updated since august
<ijohnson> (also let me know if you're the wrong person to ask about this)
 * cachio lunch
<mborzecki> Saviq: looking good, i was able to launch an instance
<Saviq> mborzecki: cool, can you try a mount, too, please?
<mborzecki> Saviq: mount failed: Error enabling mount support in 'lasting-mara' but nothing in dmesg, so probably not AA related
<mborzecki> Saviq: any way to get some info why it failed?
<Saviq> mborzecki: journal for snap.multipass*
<Saviq> It try again with -vvv
<Saviq> *Or
<mborzecki> Saviq: https://paste.ubuntu.com/p/5M9QQsCZyQ/
<mborzecki> oh, and i need sshfs?
<sil2100> ijohnson: hey, so the ones in the main directory are dailies built against edge, while all the others are built per given channel
<Saviq> mborzecki: in the instance, that is installed automagically, and also it should have continue regardless of the profile failing to load, since we skip AA on thatâ¦
<Saviq> so fix is incomplete
<mborzecki> Saviq: what follows is: gru 13 15:58:45 galeon multipassd[897299]: Failed to install 'sshfs', error message: ''
 * Saviq just got a fedora VM so should be able to repro
<sil2100> ijohnson: so the stable/ ones are built with stable snaps, and we currently only build those before every point-release actually
<Saviq> mborzecki: ah, so that's the real problemâ¦ wonder why, can you try `sudo apt install sshfs` inside the instance?
<sil2100> ijohnson: we have daily images built against edge (so the ones in /) and against beta (so the ones in /beta)
<mborzecki> Saviq: ah, i've launched ubuntu core, let me try the regular distro
<Saviq> mborzecki: right, that would be it, oof
<Saviq> (we're working on a static sshfs snap to work on Core, too)
<Saviq> https://snapcraft.io/install/multipass/fedora this is so awesome :D
<mborzecki> Saviq: hmm some trouble when stopping the vm https://paste.ubuntu.com/p/ktdPWR7XCX/
<Saviq> mborzecki: it stopped, didn't it? ;P
 * Saviq will try to stop Core
<mborzecki> Saviq: you want  /{,var/lib/snapd/}snap/core18/*/{,usr/}lib/@{multiarch}/{,**/}*.so* rm, in those profiles instead of {,/var/lib/snapd/}/snap
<mborzecki> Saviq: otherwise the parser complains
<Saviq> mborzecki: aha, /me fixes
<Saviq> probably why it failed to load
<Saviq> error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:
<Saviq>        /tmp/sanity-mountpoint-875787176: unknown filesystem type 'squashfs'.
<Saviq> hrmf
<mborzecki> Saviq: multipass mount $PWD/spread-mini saving-chamois:~/foo kind of worked (despite apparmor), but I got an unexpected path in the vm, basically $HOME/~/foo :)
<Saviq> mborzecki: well, it did what you asked it to do ;P
<mborzecki> Saviq: heh, right, presumptions about rsync/ssh like path handling
<Saviq> mborzecki: please file an issue if you can (I can, too), we should fix
<mborzecki> Saviq: there you go: https://github.com/CanonicalLtd/multipass/issues/1230
<Saviq> mborzecki: ð
<Saviq> not trivial since we'll need to resolve this inside the instance
<mvo> sil2100: do you think you could look at https://github.com/snapcore/core20/pull/16 ?
<mup> PR core20#16: bootstrap from locally build snapd snaps too <Created by mvo5> <https://github.com/snapcore/core20/pull/16>
<mvo> sil2100: this would unblock uc20 image creation
<mup> PR snapd#7905 opened: snap-bootstrap: actually parse snapd_recovery label <Created by xnox> <https://github.com/snapcore/snapd/pull/7905>
<mup> PR core20#17 opened: Drop encoding digits in units and code paths.  <Created by xnox> <https://github.com/snapcore/core20/pull/17>
<ijohnson> sil2100: would it be a lot of work to build the current/stable images everytime there's a stable updated to any of the included snaps for core images? i.e. for UC18, rebuild on core18, snapd, (and pc or pc-kernel on the 18/stable tracks) ?
<sil2100> mvo: looking!
<sil2100> mvo: btw. uc20 dailies are now up
<sil2100> http://cdimage.ubuntu.com/ubuntu-core/20/
<mvo> sil2100: thank you!
<mvo> sil2100: nice
<sil2100> ijohnson: hmm, well, we don't have such automation right now, we did plan on adding something like that at one point, but nothing available yet
<sil2100> ijohnson: it's certainly possible
<sil2100> Just needs cycle for someone to sit down on it
<mup> PR pc-amd64-gadget#26 opened: Use the correct name for the recovery_system label <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/26>
<pstolowski> zyga, pedronis updated #7658
<mup> PR #7658: cmd/snap-preseed: add snap-preseed executable <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7658>
<pedronis> pstolowski: thx
<cachio> ijohnson, hey, you already commented on this one https://bugs.launchpad.net/snapd/+bug/1855155
<mup> Bug #1855155: snap install hangs if internet is disconnected exactly right after err upload starts <snapd:New> <https://launchpad.net/bugs/1855155>
<cachio> ijohnson, any priority to set?
<ijohnson> cachio: sure I'll set the priority, it's low I think
<cachio> nice,
<cachio> I'll update it in that case
<ijohnson> sil2100: it's not critical by any means, just would be nice to have since that's what multipass uses to boot images from and they are always out of date so you boot a new UC VM and it immediately needs to reboot twice for snap updates
<mup> PR snapcraft#2844 opened: Add punctuation rule for comments <Created by hellsworth> <https://github.com/snapcore/snapcraft/pull/2844>
<zyga> pstolowski: ack, looking
<zyga> cachio: hey
<zyga> cachio: wanted to share a sneak peak
<zyga> https://www.irccloud.com/pastebin/Km7d1ouy/
<cachio> zyga, looking
<cachio> zyga, what is that?
<zyga> https://www.irccloud.com/pastebin/KfXWwBsb/
<zyga> cachio: iteration on the leak detector, generalized
<cachio> zyga, nice
<cachio> zyga, is there a PR with it?
<zyga> cachio: the tool doesn't know anything about mountinfo, it has pluggable invariant helpers that can check anything
<zyga> cachio: not yet, I'll make one soon but the tool grew a little since I started and I have some more tests to write
<zyga> cachio: I may start a new mini-project for it so that it is easier to iterate separately from snapd
<zyga> cachio: (snapd can have a snapshot that we are happy with)
<cachio> zyga, nice
<zyga> cachio: it's also nice interactively, show-event can invoke the pager automatically, there's tab completion, it's robust in case of corrupt data, etc
<zyga> cachio: event log is really cool, just give me a sec to collect one from snapd run
<cachio> zyga, which project is that?
<zyga> cachio: I haven't made one yet
<cachio> a personal is gonna be?
<zyga> cachio: it's essentially on my laptop for the past two days
<cachio> ahh
<zyga> cachio: I think so, it's easier this way
<cachio> zyga, when you have something to share just ping me, I'd like to use it
<cachio> at least to play a bit
<zyga> cachio: I'd love to plug your package leak detector
<zyga> cachio: yeah, I'll make sure to push whatever I have by EOD today
<cachio> zyga, great, thanks!!
<zyga> :)
<cachio> mvo, if you have 5 minutes, could you take a look to this one? 7851
<cachio> so we can merge it within 2.43
<zyga> cachio: event log from a partial run
<zyga> https://www.irccloud.com/pastebin/0jxLFhu1/
<zyga> the -- messages show changing attributes
<cachio> zyga, nice
<cachio> this + -show-output you have the whole picture
<zyga> show-output?
<zyga> as in output from the test?
<cachio> no
<cachio> this is something that spread2 provides
<zyga> aha
<zyga> cool
<zyga> what does it do?
<cachio> with all the details of hte execution in the remote host
<cachio> the output got from ssh
<cachio> displayed on real time
<zyga> I see, that's cool
<cachio> I use it a lot for debug
<zyga> https://www.irccloud.com/pastebin/YnJQbOAR/
<zyga> cachio: ^
<zyga> events from this failed run https://www.irccloud.com/pastebin/TnEbAUhC/
<cachio> zyga, nice, same outoput than the pr
<cachio> some tests failing
<cachio> zyga, did you test is in a board?
<zyga> cachio: no, not yet
<zyga> cachio: I'm testing it in a side project with spread
<zyga> cachio: and in snapd
<zyga> cachio: though on a board it would be even more cool as the test history accumulates and you can see what past test may have done more clearly
<cachio> zyga, how do you set the invariants to validate?
<zyga> cachio: there are several ways, the image can ship them in a few locations (/usr, /usr/local, /run)
<zyga> cachio: there's also awareness of $SPREAD_PATH so the project can ship some more
<zyga> cachio: in particular $SPREAD_PATH/tests/lib/testbed-invariants is looked at as well
<zyga> cachio: any executable file there is used
<cachio> zyga, nice
<zyga> cachio: there's a priority where /run overrides, project which overrides os system
<zyga> cachio: there's a simple protocol where a tool is invoked with an option that points it where to store data
<cachio> cool
<zyga> cachio: and a few commands to implement (status, set-baseline, has-baseline, compare) and expected behaviuor (either return a status code or print something to stdout)
<zyga> cachio: earlier I wrote a few such tools but all in one monster shell script and I abandoned that
<zyga> cachio: now each can be written in any language
<cachio> zyga, hehehe
<zyga> cachio: and testbed-tool itself is in python
<zyga> cachio: the one used here, mountinfo, is a small shell wrapper around mountinfo-tool
<cachio> zyga, would be nice to integrate it on our tests in some way
<zyga> cachio: I integrated it with our spread startup logic in a branch of snapd
<zyga> cachio: it hooks into the right spots
<zyga> cachio: tests are entirely unaffected
<zyga> cachio: tests _can_ hook into this as well, if there's a particular reason
<zyga> cachio: e.g. a test may want to say it will do something "persistent" like re-package the core snap or modify the disk image or whatever
<cachio> zyga, nice, well it is an easy way to check invariants
<zyga> cachio: you might have noticed that the test log is carried over the re-imaging we do in ubuntu-core-* targets
<zyga> cachio: so you see what happened in ubuntu-classic and what happened after booting into the core image
<cachio> nice
<cachio> that's really useful
<cachio> now that we are going to create uc20
<cachio> tests
<zyga> yeah
<zyga> :)
<zyga> not ready for prime time yet but it's close
<cachio> zyga, hehehe
<zyga> cachio: the log format is also human readable but supports fancy features like timestamps, custom key=value attributes and more
<zyga> cachio: and in emergency you can even echo >> to it
<zyga> cachio: and the log viewer handles that
<cachio> wow
<cachio> the fact it shows the timestamp is really nice
<zyga> cachio: I only format the hours/minutes but since we have everything we can detect time rollback, huge jumps and adjust the display accordingly
<mup> PR snapd#7092 closed: packaging: use snapd type and snapcraft 3.x <â Blocked> <Created by stolowski> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/7092>
<mvo> cachio: re 7851> sorry, didn't managed to review thta yet
<cachio> mvo, np
<cachio> next monday
<cachio> enjoy your weelend
<mvo> cachio: yeah, thank you! you too
<mup> PR pc-amd64-gadget#26 closed: Use the correct name for the recovery_system label <Created by xnox> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/26>
 * zyga EODs
#snappy 2019-12-14
<mup> PR snapd#7849 closed: osutil: cmd: add ltrace <Created by sd-hd> <Closed by sd-hd> <https://github.com/snapcore/snapd/pull/7849>
<mup> PR snapd#7906 opened: o/devicestate,o/snapstate: move the gadget.yaml check <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7906>
<pokk> Trying to build https://bazaar.launchpad.net/~snappy-dev/snappy-hub/rsync/view/head:/snapcraft.yaml but getting https://pastebin.com/XYxxJ5UC
<pokk> Using docker to run it doing  docker run --rm -v `pwd`:/build -w /build snapcore/snapcraft:stable snapcraft
<pokk> any ideas on what this might cause it?
#snappy 2019-12-15
<mup> Bug #1741463 changed: Failure to install maas snap in a container on a host using nvidia drivers <Snappy:Expired> <https://launchpad.net/bugs/1741463>
<mup> Bug #1828374 changed: Unable to install qabro <Snappy:Expired> <https://launchpad.net/bugs/1828374>
<mup> Bug #1836054 changed: It's not possible to set theme of qt apps <Snappy:Expired> <https://launchpad.net/bugs/1836054>
<mup> PR snapd#7907 opened: snap-bootstrap: append new partitions <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7907>
<mup> PR snapd#7908 opened: [RFC] boot,devicestate: update modenv and extract kernel <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7908>
