[00:00] <sergiusens> nessita darn, I went into fixing our python3 plugin and was trying with ill results until I noticed this was python2 :-P
[03:14] <mup> PR snapcraft#771 opened: Python plugin improvements <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/771>
[05:06] <tasdomas> is there an interface that rants an application permissions to read files in /etc (hosts, resolv.conf)?
[05:06] <tasdomas> s/rants/grants
[05:12] <pbek> kyrofa: strange, when I call `qownnotes` directly in the desktop file I get a: `404 Client Error: Not Found`
[05:45] <pbek> kyrofa: using `desktop-launch $SNAP/usr/bin/QOwnNotes --snap` didn't work neither, but it now seems `qownnotes` worked 3 out of 4 times. I only got the error  `404 Client Error: Not Found` once, so I will stick with that. Thanks a lot!
[05:58] <mup> PR snapd#1798 closed: firstboot: change location of netplan config <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1798>
[05:59] <mup> PR snapd#1796 closed: interfaces: add screen-inhibit-control interface (LP: #1604880) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1796>
[06:00] <mup> PR snapd#1795 closed: camera interface improvements <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1795>
[06:03] <mup> PR snapd#1792 closed: asserts: introduce device-session-request <Critical> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1792>
[06:08] <mup> PR snapd#1800 opened: tests: fix firstboot-assertions to actually work on clasic again <Created by mvo5> <https://github.com/snapcore/snapd/pull/1800>
[06:35] <dholbach> hey hey
[06:38] <tvoss> o/
[07:04] <mup> PR snapd#1800 closed: tests: fix firstboot-assertions to actually be runnable on classic again <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1800>
[07:21] <mup> PR snapd#1801 opened: snap: make snap download also download the assertions for the snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/1801>
[07:44] <mwhudson> mvo: thanks for merging that
[07:54] <zyga> o/
[07:56] <tasdomas> is there a way to let a snappy application access system files (e.g. /etc/hosts)?
[08:14] <mvo> mwhudson: yw
[08:14] <mvo> mwhudson: thanks for working on it in the first place :)
[08:25] <zyga> tsimonq2: yes, using interfaces
[08:26] <zyga> tsimonq2: that file should be in the default permission set
[08:26]  * zyga checks
[08:33] <ysionneau> morning!
[08:33] <ysionneau> any idea how to tell the new u-d-f to use my own gadget snap?
[08:34] <mzanetti> hey, anyone has an idea what's wrong if I hit this from ubuntu-device-flash?
[08:34] <mzanetti> cannot bind mount /dev to /tmp/snap.rootfs_k6mTS3/dev. errmsg: No such file or directory
[08:34] <zyga> tsimonq2: that file is not allowed currently
[08:34] <mzanetti> I've the u-d-f version from the snappy store
[08:34] <zyga> tsimonq2: please open a bug and tag it with 'snapd-interfaces' on launchpad.net/snappy
[08:35] <zyga> mzanetti: this is a message from snap-confine, does your system have /dev?
[08:35] <mzanetti> I have no idea
[08:35] <zyga> ysionneau: no idea, sorry
[08:35] <zyga> mzanetti: ls -ld /dev ?
[08:35] <mzanetti> zyga, ah, you mean the folder, yes it does :D
[08:35] <mzanetti> I thought "dev mode enabled" or something :D
[08:35] <zyga> mzanetti: how about: ls -ld /snap/ubuntu-core/current/dev
[08:36] <mzanetti> nope that's missing
[08:36] <zyga> mzanetti: can you try: export SNAP_CONFINE_DEBUG=1
[08:36] <zyga> mzanetti: oh? how about snap list
[08:36] <zyga> mzanetti: snap list
[08:36] <zyga> mzanetti: tell me if you have the core snap installed (ubuntu-core)
[08:36] <zyga> mzanetti: and if so, which revision that is
[08:36] <mzanetti> I do, but it says "broken" in the Notes
[08:36] <mzanetti> rev 48
[08:37] <zyga> mzanetti: interesting, any idea how you managed to do that?
[08:37] <zyga> mvo: ^^
[08:37] <mzanetti> no
[08:37] <zyga> mzanetti: (this is why you cannot run snaps)
[08:37] <mzanetti> right, makes sense
[08:37] <zyga> mzanetti: if you look in /var/lib/snapd/snap can you see the corresponding .snap file?
[08:37] <zyga> (for ubuntu core)
[08:38] <mzanetti> I'm on xenial (+stable-phone-overlay) and I installed the ubuntu-calculator-app via snap some months ago, didn't really touch it since... now it's broken
[08:38] <mzanetti> yes, the ubuntu-core.snap is there
[08:39] <zyga> mzanetti: curious, can you report a bug, attach your /var/lib/snapd/state.json file (please make the bug private)
[08:39] <zyga> mzanetti: which version of snapd are you on now>?
[08:39] <mzanetti> 2.13
[08:58] <mwhudson> mzanetti: fwiw i had that happen to me and rebooting fixed it
[08:58] <mwhudson> i think
[08:59] <mwhudson> random flailing around, including rebooting, fixed it
[09:01] <ogra_> mwhudson, will the new console-conf skip network device config if it finds an existing one (did you guys test with a configured wlan device yet) ?
[09:02] <mwhudson> ogra_: it won't skip, but just pressing ok should work fine
[09:02] <ogra_> what got me in the loop was the inability to cancel or skip that bit iirc
[09:02] <ogra_> ok
[09:02] <mwhudson> ogra_: i haven't tested it myself (not sure where i put my dragonboard!)
[09:03] <ogra_> a pi3 would even be better ... since it has eth and wlan ;) (and i fear a typical usecase is to not use the eth)
[09:04] <mwhudson> my linaro days left me with a profound dislike of all developer boards :)
[09:04] <ogra_> lol
[09:05] <ogra_> see, that is why i never went there ;)
[09:05] <mwhudson> probably sane
[09:05] <ogra_> it leaves its marks to work for a company that sounds like a sanitary pad ;)
[09:06] <mwhudson> hmm do rpis actually have proper MAC addresses?
[09:06] <mwhudson> sounds like an improvement over some things...
[09:06] <ogra_> yep ... on our images they do ;)
[09:07] <mwhudson> like e.g. the dragonboard iirc
[09:07] <ogra_> the dragonboard images have fixed MACs as well
[09:47] <mthaddon> hi folks - I'm trying to snap codetree (lp.net/codetree) and I'm most of the way there, but I'd expect it'll need to be able to use bazaar and git credentials for a user. Are there some docs that would explain how to do that?
[10:04] <zyga> mthaddon: I don't believe you can do that today, there are existing interfaces that aim to allow a snap to use certain "dot" directories
[10:04] <zyga> mthaddon: sorry, I meant, bugs and pull requests
[10:04] <mthaddon> zyga: ack, thx
[10:05] <zyga> mthaddon: the $HOME directory is not the real home, that's a separate issue
[10:05] <mthaddon> it's non-hidden home, right?
[10:05] <zyga> mthaddon: so I'd say that you need to look at solving two separate problems
[10:05] <zyga> mthaddon: 1) knowing where real home is (e.g. through a new SNAP_REAL_HOME variable)
[10:06] <zyga> mthaddon: teaching your snap to construct symlinks to $SNAP_REAL_HOME/.ssh .bzr and .git and what not in $HOME
[10:06] <zyga> mthaddon: and using an interface to gain read/write access there (you can start with devmode)
[10:06] <zyga> mthaddon: given that $LOGNAME exists you can work around the first problem by just faking it with /home/$LOGNAME
[10:06] <zyga> mwhudson: give that a try!
[10:06] <zyga> Son_Goku: hey!
[10:06] <zyga> Son_Goku: just the person I was looking for
[10:07] <zyga> Son_Goku: what are the common names for locale packages?
[10:07] <mthaddon> thx
[10:07] <zyga> Son_Goku: I was working on an update to golang gettext bindings when I noticed tests don't work anymore, the test code was tweaked to use setlocale(LC_ALL, "") and I suspect I need to add appropriate locale packages to the mock environment as build-deps
[10:10] <Son_Goku> zyga, dnf repoquery --whatprovides "glibc-langpack" will give you a list of them
[10:10] <Son_Goku> the C and C.utf-8 locales are provided by glibc-minimal-langpack
[10:11] <Son_Goku> you probably want glibc-all-langpacks for gettext
[10:11] <Odd_Bloke> Upstream of what I'm trying to snap up don't provide source, and ship only a zip file.  Scripts in this zip file aren't executable, but they do expect one another to be.  Is there a good way for me to run "chmod +x .../*" as part of my snapcraft build?
[10:12] <Odd_Bloke> (I'm currently just using the dump plugin.)
[10:16] <zyga> Son_Goku: thanks!
[10:16] <zyga> Odd_Bloke: I'm old so I love make, just use make :)
[10:16] <Son_Goku> zyga, prior to fedora 24, all langpacks were installed by default since they weren't split out in glibc
[10:16] <Son_Goku> so none of this existing pre-f24
[10:17] <Son_Goku> all the base locale stuff was installed by default in f23 and older
[10:17] <Odd_Bloke> zyga: How do I use upstream zip as a source but get my own Makefile integrated in?
[10:17] <zyga> it might be that or something else, I'm investigating
[10:17] <zyga> could be that the test fails because of the current working directory
[10:17] <zyga> Odd_Bloke: just unpack it as a part of the make target
[10:17] <zyga> Odd_Bloke: keep the makefile in your tree
[10:18] <Odd_Bloke> zyga: And also fetch it as part of the make target?
[10:18] <zyga> Odd_Bloke: get the zip using snapcraft
[10:18] <Odd_Bloke> Oh, just don't tell it it's a zip file?
[10:18] <zyga> Odd_Bloke: yep, just switch to the make plugin and point to the separate makefile
[10:31] <stub> how are people handling log rotation inside their snaps?
[10:37] <zyga> Son_Goku: anything I can pass to fedpkg mockbuild to get an interactive shell at a particular point?
[10:38] <mup> PR snapd#1802 opened: image,overlord/boot,snap: metadata from asserts for image snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/1802>
[10:40] <mthaddon> zyga: would I expect to see a PR for allowing access to specific dot directories on https://github.com/snapcore/snapcraft/pulls ? Would like to track the issue if there is one
[10:42] <mthaddon> also don't see a bug matching "dot" or "hidden" on https://bugs.launchpad.net/snapcraft
[10:47] <zyga> mthaddon: there's a bug about this, not sure if there's a PR for it too
[10:47] <zyga> try launchpad.net/snappy
[10:48]  * zyga would like a snapcore project group
[10:48] <zyga> and snapd, snapcraft, ... projects insid
[10:48] <zyga> e
[10:48] <mthaddon> cool, https://bugs.launchpad.net/snappy/+bug/1607067 - thx
[10:48] <mup> Bug #1607067: Add a dotfiles / hidden files interface <snapd-interface> <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1607067>
[10:48] <ogra_> zyga, that group is called snappy-dev on LP ;)
[10:49] <zyga> ogra_: not group, project group
[10:49] <zyga> ogra_: that's nice to use to search bugs amongs snappy related projects
[10:49] <zyga> ogra_: coordinate milestones and find the relevant projects in one spot
[10:50] <ogra_> https://bugs.launchpad.net/~snappy-dev ... we just need tio sunscribe the team to the right packages and branches
[10:50] <ogra_> *sub
[10:51] <zyga> ogra_: that doesn't help people when bugs are spread amongs projects and they are not a member of the -dev group to know about it in the first place
[10:51] <ogra_> (no idea why nobody did that yet ... we definitely use the team for everything else... like automation, branch and PPA ownerships)
[10:51] <ogra_> huh ? why wouldnt it
[10:51] <ogra_> everyone can see the buglist
[10:52] <zyga> ogra_: do you know what a launchpad project group is?
[10:52] <zyga> ogra_: e.g. https://launchpad.net/checkbox-project
[10:53] <ogra_> https://bugs.launchpad.net/snappy ?
[10:53] <zyga> ogra_: that doesn't show bugs in snapcraft or in snap-confine
[10:53] <zyga> that is exactly my point
[10:53] <ogra_> so we can add these
[10:54] <zyga> ogra_: ?
[10:54] <zyga> ogra_: add them where?
[10:55] <mup> PR snapd#1803 opened: spread: enable halt-timeout, tweak image selection <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1803>
[10:55] <ogra_> cant you add additional bug monitoring to the project by subscribing it to other projects ?
[10:55] <ogra_> iirc  thats possible
[10:56] <zyga> ogra_: I don't know anything about that, sorry
[10:56] <ogra_> https://launchpad.net/snappy/+sharing
[10:56] <ogra_> the snapcraft team would have to share them with usa
[10:56] <ogra_> *us+
[10:56] <ogra_> bah
[10:56] <ogra_> then they will show up in the snappy buglist
[10:57] <zyga> ogra_: in the end, will I see all the bugs in bugs.launchpad.net/snappy?
[10:57] <ogra_> right
[10:57] <ogra_> lets talk about it in the meeting
[10:57] <zyga> ogra_: interesting, I wonder what's the desire with the project group feature overlap
[10:57] <zyga> ogra_: I think the issue is social, people recall snapcraft as the "brand" because that is what the mailing lists and the website is called
[10:58] <ogra_> right
[10:58] <zyga> ogra_: we talked about setting up a project group a while ago but it never materialized
[11:02] <zyga> Pharaoh_Atem: hey, I have a question, is it ok to commit non-working packaging to master
[11:02] <zyga> Pharaoh_Atem: I'd like to have a second pair of eyes on the problem I was facing
[11:26] <morphis> ogra_: 9 M snap size and 0.9% memory usage on my pi3, does that sound better for you for the network-manager snap? :-)
[11:28] <ogra_> morphis, definitely an improvement, but indeed still more then 0MB :)
[11:28] <ogra_> *than
[11:30] <ogra_> i think NM preseeded is absolutely fine on PC class installs like the dell gateways, but i still think we shouldnt pre-seed it on embedded (rpi, dragonboard) and use the existing alternative there
[11:31] <Son_Goku> why?
[11:31] <Son_Goku> latest NM is quite small and lightweight
[11:31] <Son_Goku> and it's super easy to configure
[11:32] <ogra_> Son_Goku, because it is still bigger than zero ;)
[11:32] <ogra_> it just doesnt make sense ot have something like NM on the embedded board of your lawnmower
[11:32] <Son_Goku> it really doesn't make sense for your lawn mower to be internet connected
[11:32] <ogra_> where you most likely have pretty hard requirements regarding disk and ram size
[11:32] <ogra_> huh ?
[11:33] <Son_Goku> I'd say in that case it should have nothing
[11:33] <ogra_> how else would i install additional autopilot snaps ;)
[11:33] <Son_Goku> not even the legacy networking
[11:33] <ogra_> or steer it via that mobile app
[11:33] <Son_Goku> ....
[11:33] <Son_Goku> you have problems
[11:34] <ogra_> well, snappy was initially designed for IoT ... and we'll go there again after that little detour to make it a generic package format
[11:36] <morphis> ogra_: yeah I agree
[11:36] <morphis> by default we give netplan/ifupdown which is enough and then someone can pick
[11:37] <ogra_> well, we should have a default image with NM as well ... just not for the low level devices
[11:37] <morphis> sure, but that is then for the implementor to pick
[11:38] <morphis> as long as the snap is in the store, tested and ready to use you can put it in images, install on demand, whatever you want
[11:38] <ogra_> yeah
[11:39]  * ogra_ trickles launchpad 
[11:39] <ogra_> come on publisher ... you knwo you can do it
[11:39] <morphis> btw. I lied, amd64 is 7.9 M and armhf is 5.9 now
[11:39] <ogra_> how about arm64 ?
[11:39] <ogra_> i suspect thats the biggest
[11:39] <morphis> need to check
[11:41] <Son_Goku> morphis, why not use networkd
[11:41] <ogra_> we do
[11:41] <ogra_> when NM isnt installed
[11:41] <Son_Goku> good
[11:41] <morphis> Son_Goku: networkd does give you some advance features in certain situation
[11:41] <Son_Goku> it's quite nice
[11:42] <Son_Goku> and it isn't ifupdown :)
[11:42] <Son_Goku> which means no sysv scripts
[11:42]  * ogra_ doesnt get all the hate for ifupdown ... 
[11:42] <morphis> ogra_: https://launchpad.net/~morphis/+snap/network-manager-reduced-footprint
[11:43] <Son_Goku> my server stalls for more than 5 minutes at work while trying to bring up networking
[11:43] <Son_Goku> swapping that out for NetworkManager completely eliminated the bottleneck
[11:43] <ogra_> wow, that sounds like a buggy setup then
[11:45]  * tvoss hugs the poor little publisher
[11:48] <ogra_> hmm
[11:48] <ogra_> my current upgrade wants to uninstall unity8-desktop-session
[11:48] <ogra_> that doesnt sound right
[11:51]  * ogra_ triggers an ubuntu-core edge build with console-conf included ... lets see how it behaves now 
[11:57] <mvo> pitti: quick (silly) question, what kind of network restrictions do we have inside adt? I would love to run our spread tests inside adt but need some access, notable github and the snappy store. I guess the later is no problem, what about the former?
[12:08] <Son_Goku> ogra_ uhh no
[12:08] <Son_Goku> my setup is damn simple
[12:08] <Son_Goku> it's just bringing up the interface with dhcp
[12:09] <Son_Goku> ifupdown is just brittle as hell
[12:09] <ogra_> well, except that it isnt normal to take 5min :)
[12:10] <ogra_> not even with ifupdown
[12:10]  * Son_Goku shrugs
[12:10] <Son_Goku> moving to networkd or NetworkManager fixes it
[12:10]  * ogra_ doesnt have such probs with any of his machines ... so i never felt the need to move
[12:10] <mup> PR snapd#1804 opened: tests: use the spread tests with the adhoc interface inside autopkgtest <Created by mvo5> <https://github.com/snapcore/snapd/pull/1804>
[12:12] <ogra_> hmm, it would be really nice if the store wouldnt spam me with a 504 error mail for each ubuntu-core snap build
[12:13] <ogra_> (especially since its a lie)
[12:16] <pitti> mvo: you can use that, as long as you respect the proxy vars
[12:18] <pitti> mvo: we routinely run tests which clone stuff from github, works fine
[12:19] <mvo> pitti: cool, thank you
[12:19] <mvo> ogra_: hm, we have a "test" user in our image?
[12:20] <mvo> ogra_: do you know anything about this? uid 1001
[12:22] <ogra_> mvo, nope
[12:22] <mup> PR snapd#1803 closed: spread: enable halt-timeout, tweak image selection <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1803>
[12:23] <ogra_> mvo, which ubuntu-core revision is that ? i just did a test build with console-conf re-added
[12:23] <mvo> ogra_: this is the one I got I think
[12:23] <ogra_> then it might come from there
[12:24] <mvo> pitti: and one more silly question, what is the best way to test if autopkgtest works in the real environment we use? I guess a yakkety upload? or is there some better way?
[12:24] <mvo> ogra_: so console-conf might add a test user?
[12:24] <ogra_> i dont know what else would
[12:24] <ogra_> definitely not livecd-rootfs
[12:25] <ogra_> and i havent seen any cloud-init changes either
[12:25] <pitti> mvo: if it works locally with qemu it should mostly likely work on teh infra too
[12:25] <pitti> mvo: you can try it on canonistack too if you want
[12:29] <mvo> pitti: ok, that is good enough for me (qemu), I will double check in there then and hope for the best :)
[12:29] <ogra_> mvo, looking at the subiquity diff i dont see anything that would add a test user
[12:31] <pitti> mvo: note that github has a great CI functionality too -- we can run the autopkgtests on PRs on xenial and yakkety
[12:32] <pitti> which is a much better way to do it than waiting for an upload and then trying to find out what broke stuff
[12:36] <cyphermox> morning
[12:38] <mvo> pitti: you mean via travis?
[12:38] <mvo> pitti: this is close to what we are doing, except that we use spread instead of autopkgtest. I'm trying to brige these worlds right now
[12:38] <pitti> mvo: no, you can configure a web hook to request an autopkgtest on our infra, and ask it to build and test a PR branch
[12:39] <pitti> we've done this for systemd for a long time now, and didrocks once set it up for ubuntu-make
[12:39] <pitti> mvo: this just needs an hour of sitting down, exchanging some shared secrets and configuring the snappy gh project
[12:41] <mvo> pitti: indeed, we had the webhook setup too, we had some trouble with the infrastructure though, federico knows the details and eventually moved to spread
[12:43] <ogra_> mvo, oh, FYI .. http://people.canonical.com/~ogra/ubuntu-core-builds/ ... ( that is only pparsing the log from the auto-builder though, so manual builds are ignored)
[12:43] <mup> PR snapd#1788 closed: snapstate: use umount --lazy when removing the mount units <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1788>
[12:43] <ogra_> (but helpful if you need the mapping between LP and the store revisions)
[12:44] <mvo> neat
[12:45] <ogra_> changelogs (manifest diffs) and manifests will show up there too... once we have them
[12:46] <mup> PR snapd#1805 opened: use beta u-d-f in test by default  <Created by mvo5> <https://github.com/snapcore/snapd/pull/1805>
[12:53] <sergiusens> pitti mvo if it helps snapcraft runs adt on every PR; but mvo just recall that is what you sort of moved away from (I think)
[12:54] <pstolowski> jdstrand, hello!
[12:54] <sergiusens> the canonistack/prodstack side of it
[12:57] <mvo> sergiusens: yeah, the canonistack was the part we had trouble with hence spread. but I hope I can cross the worlds again
[12:57] <ppisati> sergiusens: how do i unstuck this?
[12:57] <ppisati> sergiusens: https://github.com/snapcore/snapcraft/pull/748#issuecomment-241420986
[12:57] <mup> PR snapcraft#748: kernel plugin: vmlinuz -> kernel.img hard link <Created by piso77> <https://github.com/snapcore/snapcraft/pull/748>
[12:58] <mup> PR snapd#1806 opened: overlord/devicestate: set device registration URLs <Blocked> <Created by matiasb> <https://github.com/snapcore/snapd/pull/1806>
[13:00] <sergiusens> ppisati can you address the comment in here https://github.com/snapcore/snapcraft/pull/748/files ?
[13:00] <mup> PR snapcraft#748: kernel plugin: vmlinuz -> kernel.img hard link <Created by piso77> <https://github.com/snapcore/snapcraft/pull/748>
[13:00] <sergiusens> ppisati in some sense I am asking to just remove that os.link call and the comment above if they aren't needed anymore
[13:02] <ppisati> sergiusens: oh ok
[13:06] <sergiusens> ppisati if we sort that out today I will wait for it for the 2.16 release being tagged today
[13:06] <ppisati> sergiusens: would a symlink be good for you?
[13:06] <sergiusens> ppisati os.link is fine, I am just wondering if we need the vmlinuz one
[13:06] <ppisati> sergiusens: the bootloader should only look for kernel.img
[13:06] <jdstrand> sergiusens: re 'grade'> no
[13:06] <ppisati> so we can remopve that vmlinuz completely
[13:06] <jdstrand> pstolowski: hi
[13:06] <ppisati> k
[13:07] <sergiusens> ppisati great, so yeah, `dd` (in vi) on the line `os.link(src, os.path.join(self.installdir, 'vmlinuz'))` and the one above is my specific quetion :-)
[13:07] <sergiusens> jdstrand I've affected the project on the bug.
[13:07] <pstolowski> jdstrand, hi! i've hit https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1618737 today, and took the liberty of assigning it to you
[13:07] <mup> Bug #1618737: firewall-control doesn't grant all the required permissions for ufw to work <snapd (Ubuntu):New for jdstrand> <https://launchpad.net/bugs/1618737>
[13:09] <ppisati> sergiusens: you forgot the unit tests :)
[13:10] <jdstrand> pstolowski: that is bug #1583514
[13:10] <mup> Bug #1583514: firewall-control and ip[6]table_filter module loading <snapd-interface> <Snappy:Triaged> <https://launchpad.net/bugs/1583514>
[13:10] <pstolowski> jdstrand, ah! ok, thanks!
[13:10] <jdstrand> pstolowski: what is needed is a kernel module backend. that is also needed by docker, ppp and other interfaces
[13:12] <jdstrand> jamiebennett, lool: can someone get bug #1583514 assigned? ^
[13:12] <mup> Bug #1583514: firewall-control and ip[6]table_filter module loading <snapd-interface> <Snappy:Triaged> <https://launchpad.net/bugs/1583514>
[13:14] <mup> PR snapd#1807 opened: interfaces/builtin/bluetooth_control.go: Add access to /dev/vhci <Created by cwayne18> <https://github.com/snapcore/snapd/pull/1807>
[13:22] <jamiebennett> pstolowski is doing some bug triage atm
[13:22] <jamiebennett> pstolowski: can you take a look to see what is required?
[13:25] <pstolowski> jamiebennett, sure, will do
[13:25] <jdstrand> pstolowski: fyi, comment #1 in the bug lays out the high-level idea which was approved by niemeyer and zyga. I can point you at other converstaions for lower level details. give me a minute
[13:31] <mup> PR snapd#1736 closed: tests: port integration tests to spread <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1736>
[13:31] <ogra_> cyphermox, hmm, i seeded console-conf again and upgraded ubuntu-core ... i end up with no console-conf UI but also with no serial console now
[13:31] <cyphermox> hit enter
[13:32] <ogra_> nothing
[13:32] <ogra_> oh, now i get some messed up stuff at the top
[13:33]  * ogra_ seed eth0 unconfigured ... sit0 too and wlan0 with an IP ... 
[13:33]  * ogra_ hits "done"
[13:33] <ogra_> hey, this gfot me further than last time
[13:34] <ogra_> whee !
[13:34] <sergiusens> ppisati can you also click `Update branch`/merge/rebase the branch?
[13:34] <sergiusens> ppisati indeed I forgot the units :-)
[13:35] <ogra_> cyphermox, apart from the visual glitches uit technically seems to work ... i guess just adding a "clear" at the top of your code would greatly improve the UI
[13:36] <cyphermox> no chance you took a screenshot of what you saw garbled?
[13:36] <cyphermox> it looks fine to me, and clears as much as one would expect on serial
[13:36] <ogra_> cyphermox, it someply has all the boot output ... and then starts the U(I in the top left (i dont have the terminal at 80x24 here)
[13:37] <mup> PR snapd#1808 opened: many: add snap set and snap get commands <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1808>
[13:37] <ogra_> just clearing the terminal should be enough
[13:37] <cyphermox> not for that, but that sounds like what I'm seeing here
[13:38] <ogra_> i guess if my terminal hade been at 80x24 i wouldnt have noticed
[13:38] <ogra_> *had
[13:38] <cyphermox> well, mine isn't either
[13:38] <cyphermox> I have no idea why it picks that, could be some weirdness in urwid
[13:39] <jdstrand> pstolowski: for docker: https://github.com/snapcore/snapd/pull/1619/#issuecomment-239678941 (not much detail) and https://github.com/snapcore/snapd/pull/1226#discussion_r64953106 for ppp ((3rd bullet). I can't seem to find where the clear explanation is, so I'll give it to you
[13:39] <mup> PR snapd#1619: interfaces/builtin: add initial docker interface <Blocked> <Created by tianon> <https://github.com/snapcore/snapd/pull/1619>
[13:39] <mup> PR snapd#1226: Interface for modem manager <Reviewed> <Created by alfonsosanchezbeato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1226>
[13:39] <ogra_> cyphermox, http://people.canonical.com/~ogra/serial-shot.png
[13:40] <ogra_> this is what i see now
[13:40] <cyphermox> yep, looks good
[13:40] <ogra_> heh
[13:40] <cyphermox> well, as good as it can when limited to 80x24 ;)
[13:40] <jdstrand> pstolowski: snapd grows a new backend, eg, KernelModule. interfaces add what modules to explicitly load via this backend. Eg, firewall-control would tell KernelModule to load iptable_filter and ip6table_filter
[13:41] <ogra_> i'm sure there is a way to clear the tty before you fire up your UI
[13:41] <cyphermox> the problem is not the clearing though
[13:41] <cyphermox> it's the size
[13:41] <cyphermox> and size can't exactly be guessed from serial
[13:41] <jdstrand> pstolowski: then this backend creates file(s?) in /etc/modules-load.d to simply list the modules
[13:41] <ogra_> also there was no note at all that i need to press enter
[13:42] <ogra_> it just sat there at the end of the boot messages
[13:42] <cyphermox> ogra_: ok, I'll look into that
[13:42]  * ogra_ tries the dragonboard
[13:42] <cyphermox> I think we can keep this in the image now though?
[13:43] <jdstrand> pstolowski: so, firewall-control lists those two modules, on interface connect of firewall-control, snapd splats out /etc/modules-load.d/snap.modules.conf with each of those, one per line
[13:43] <mup> PR snapd#1807 closed: interfaces/builtin: allow /dev/vhci on bluetooth-control <Created by cwayne18> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1807>
[13:43] <ogra_> cyphermox, thats my current screen on the dragonboard before hitting enter http://paste.ubuntu.com/23116099/
[13:44] <cyphermox> ta
[13:44] <cyphermox> yep, looks like agetty is still not complying
[13:44] <jdstrand> pstolowski: there is some question as to whether there should be one big file that is managed or one per interface. that is an implementation detail. I believe zyga said he understood how to do all this, but not sure if there is any code or anything. this functionality is not difficult
[13:47] <ogra_> cyphermox, now the million dollar question ... on debvices that have tty1 and a serial tty ... could we show the UI on both (and have it stop when on one of the ttys the config was done)
[13:47] <ppisati> sergiusens: yep
[13:47] <ppisati> sergiusens: i just built an image for test
[13:48] <cyphermox> ogra_: what do you mean?
[13:48] <ppisati> sergiusens: let me finish to flash it and i'll update the branch
[13:48] <cyphermox> ogra_: you want on boot that tty1 and ttyS* show the UI?
[13:48] <cyphermox> (rather than wiating for input?)
[13:48] <ogra_> cyphermox, systemd automatically configures tty1 ... so on systems with console=blahblaS0 ... you end up with both, tty1 and blahblahS0 login prompts
[13:49] <cyphermox> tty1 will currently show "Hit enter to configure." or something like that
[13:49] <ogra_> it would make sense to have both show the UI ...
[13:49] <pstolowski> jdstrand, sorry, i was in the meeting. reading
[13:49] <cyphermox> there's a wrapper around the binary to deal with your memory issue
[13:50] <mup> PR snapd#1254 closed: snap: use symlink in /snap/bin instead of wrappers <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1254>
[13:50] <ogra_> cyphermox, well, i dont care about memory, i care about raspberry pi users that have no serial cable ;)
[13:50] <cyphermox> ogra_: in fact, not just tty1 but tty1-6 should show that, and wait for a key to start the UI
[13:50] <cyphermox> that behaves correctly AFAICT
[13:51] <ogra_> so wheerever the keypress comes from will run the UI ?
[13:51] <cyphermox> the problem is that you can't use the exact same options in agetty on ttyn than on ttySn, because serial behaves differently than screen
[13:51] <cyphermox> yup
[13:51] <cyphermox> wherever the keypress comes it will run the UI
[13:51] <cyphermox> the intent is to show the message, which works on VTs, but apparently not on serial
[13:52] <ogra_> ok, i'll try my way through :)
[13:53] <cyphermox> re-flashing my card so I can start fresh, I'll bring up my pi2 with HDMI attached this time, but I tested it last night before sending you the email
[13:53] <cyphermox> "last night" for varying definitions of night.
[13:55] <sergiusens> ppisati ah, you may be a good candidate for adding a test for the kernel plugin here https://github.com/snapcore/snapcraft/blob/master/manual-tests.md
[13:56] <jacekn> I am trying to build snap using LP. I have 2 branches, each one with slighly different snapcraft.yaml (stable vs edge). One of them build fine and I can publish to the store. But when I try to set up 2nd branch to build snaps I am getting "here is already a snap package owned by Jacek Nykis with this name". How can I work around it?
[13:57] <ogra_> jacekn, name the branch differently ?
[13:58] <ogra_> (or the snap rather i guess)
[13:58] <kyrofa> ogra_, it's perfectly fine to name the snaps differently in LP
[13:58] <kyrofa> ogra_, sorry, jacekn
[13:58] <kyrofa> jacekn, as long as the snapcraft.yaml indicates the correct name, the generated snap will have that name
[13:59] <kyrofa> jacekn, think of the snap name in LP as the LP ID for that snap instead of its actual name
[14:00] <ppisati> the img that i just created doesn't boot...
[14:00] <jacekn> kyrofa: ack, thanks I'll try that
[14:00] <chihchun> Is there a easy way to add new apparmor rules without rebuild snapd? seems edit /var/lib/snapd/apparmor/profiles/*profile* and snap refresh did not do the trick
[14:00] <kyrofa> jacekn, I have a snap that automatically deploys to different channels on LP. When I merge to develop, I want it published on the beta channel. When I merge to master, I want it published to all channels. I do that by creating two different snaps, "my-snap" and "my-snap-beta" associated with those branches
[14:00] <ogra_> ppisati, using the latesst u-d-f snap ?
[14:00] <ppisati> yep
[14:01] <ppisati> sudo ubuntu-device-flash core 16 --channel edge --kernel pi2 --gadget pi2 --os ubuntu-core
[14:01] <ogra_> (revision 9 or so)
[14:01] <ppisati> -o pi2.img
[14:01] <mup> PR snapd#1809 opened: interfaces/bluetooth_control: needs /dev/vhci to be writable <Created by cwayne18> <https://github.com/snapcore/snapd/pull/1809>
[14:01] <ogra_> ppisati, --kernel pi2-kernel i hope :)
[14:01] <ppisati> err no
[14:01] <ogra_> else you installed a gadget as kernel
[14:01] <ogra_> ;)
[14:01] <ppisati> ubuntu-device-flash  3          3    canonical  devmode
[14:02] <ogra_> interesting that we dont refuse that
[14:02] <ogra_> oh, better update that
[14:02] <ogra_> ogra@anubis:~$ snap list ubuntu-device-flash
[14:02] <ogra_> Name                 Version  Rev  Developer  Notes
[14:02] <ogra_> ubuntu-device-flash  10       9    canonical  devmode
[14:05] <cwayne> sorry for the double PR, had been too quick to post before checking if rw was needed!
[14:05] <pstolowski> jdstrand, ok, so fixing this bug includes: 1) implementation of the new snapd backend which loads kernel modules and 2) make firewall-control interface drop a file there to have the modules loaded, correct?
[14:05] <jdstrand> chihchun: you can add the rules to /var/lib/snapd/apparmor/profiles/*profile* then do 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/*profile*
[14:06] <jdstrand> chihchun: a snap refresh will actual remove those changes though (as will an install, remove/install, etc)
[14:06] <chihchun> jdstrand: and it will overwrite the cache in /var/cache/apparmor, correct?
[14:06] <ogra_> cyphermox, what happens on disconnected devices regarding the user ?
[14:07] <cyphermox> ogra_: I need to clarify that. Currently, to configure a device with console-conf you'd need Ubuntu SSO credentials, or you'd have to login with the ubuntu user via SSH and add a user manually
[14:07] <jdstrand> pstolowski: '2' is not for firewall-control to drop a file, but simply adding those to modules to a list for the backend to add to a file it will drop there
[14:07] <jdstrand> s/to modules/two modules/
[14:08] <ogra_> cyphermox, that would have been my next question :) can i drop the ubuntu user creation from livecd-rootfs :)
[14:08] <ogra_> but seems i cant yet
[14:08] <jdstrand> pstolowski: ie, the backend does the dropping. the interfaces just tell the backend what to put there
[14:08] <cyphermox> ogra_: originally we expected that was what would happen once console-conf was in, but looks like we need further policy discussion on that matter
[14:09] <ogra_> i know sabdfl__ is eager to get rid of being mr. "ubuntu" on the devices ;)
[14:09] <cyphermox> that transpired during my night too :)
[14:09] <cyphermox> I won't blame him, it's a big wart on the devices, tbh
[14:09] <ogra_> it is
[14:09] <ogra_> well, i'll leave the user in for now til we have clearified that ... let me know once it can go
[14:09] <cyphermox> one of my top priorities today is to sort out what to do with the users
[14:09] <ogra_> big step !
[14:09] <cyphermox> yep
[14:09] <ogra_> awesome work !!
[14:10] <cyphermox> thanks. I'll convey your feedback to mwhudson too!
[14:10] <ogra_> and to slangasek ;)
[14:10] <cyphermox> yep
[14:14] <pstolowski> jdstrand, ok, i see. i'm afarid i cannot commit to work on this atm, i'm in the middle of something else
[14:26] <jdstrand> chihchun: that won't overrite the cache, no, but on reboot the apparmor init will notice the profile is newer and update the cache
[14:27] <chihchun> jdstrand: thanks for the tips, it works for me. I found an issue on the rules for input method, will file a pull request
[14:28] <jdstrand> chihchun: cool, thanks
[14:28] <jdstrand> pstolowski: ack
[14:28] <jdstrand> pstolowski: for posterity:
[14:29] <jdstrand> pstolowski: one other thing is that on interface connect, the backend should load the modules (in addition to adding them to /etc/load-modules.d)
[14:32] <mhall119> zyga: jamiebennett: are you available for the snappy community sync call?
[14:32] <jamiebennett> mhall119: Sorry, have a snappy team call
[14:32] <mhall119> well we can just join that :)
[14:35] <ogra_> mhall119, wasnt that commun8ity sync dead since ages ?
[14:40] <jdstrand> mvo: hey, ok, now that I have the rights to merge stuff, what is the policy if I propose a PR and someone else +1s it? Should I merge it or wait for someone else?
[14:40] <jdstrand> mvo: related, how many +1s are needed for me to do the merge for a PR someone else submitted?
[14:41] <pstolowski> jdstrand, thanks, I added all your explanations to the bug report as this is a good summary
[14:41] <jdstrand> pstolowski: oh heh, I already did :)
[14:41] <ppisati> ogra_: http://pastebin.ubuntu.com/23116284/
[14:41] <ppisati> ogra_: do you have any idea how can i debug this?
[14:42] <pstolowski> jdstrand, oh lol.. i haven't refreshed for several minutes so didn't see it..
[14:42] <ppisati> so, starting with a fresh rpi2 image, i can't install a new kernel because
[14:42] <ppisati> it coudln't connect to the store
[14:42] <jdstrand> pstolowski: yeah, that happens from time to time too :)
[14:42] <ppisati> while if i roll a custom image with a fresh kernel built using snapcraft kernel pluging, i get this
[14:43] <mhall119> ogra_: zyga and I had kept it going
[14:44] <jdstrand> happens to me*
[14:46] <sergiusens> ppisati can you click on "Update branch" please?
[14:46] <ppisati> sergiusens: dpne
[14:46] <sergiusens> ppisati thanks
[14:57] <jdstrand> jamiebennett: fyi, https://bugs.launchpad.net/snappy/+bug/1583514/comments/7
[14:57] <mup> Bug #1583514: firewall-control and ip[6]table_filter module loading <snapd-interface> <Snappy:Triaged> <https://launchpad.net/bugs/1583514>
[15:10] <mup> PR snapd#1810 opened: interfaces/builtin/unity7.go: fix fcitx support <Created by chihchun> <https://github.com/snapcore/snapd/pull/1810>
[15:10] <zyga> mhall119: perhaps next week, this week is RTM work sprint
[15:15] <sergiusens> ppisati but does it work? :-)
[15:17] <ogra_> ppisati, sorry, in a meeeting ... mount the first partition and check if ubuntu-raspi2-kernel_x1.snap/ exists as dir in there ...
[15:18] <ogra_> (or do fatls from the uboot prompt)
[15:18] <mhall119> zyga: can you review my blog post today? I'd like to publish it tomorrow
[15:18] <zyga> mhall119: yes, I'll review it after this batch of meetings, I had a look early in the morning but I didn't read it in detail to say +1/-1 yet
[15:18] <mhall119> thanks zyga
[15:22] <ppisati> ogra_: you mean the partition containing the bootloader files?
[15:22] <ppisati> ogra_: but there's no 'ubuntu-raspi2-kernel_x1.snap' dir there
[15:23] <ogra_> thats your issue then
[15:24] <ppisati> sudo ubuntu-device-flash core 16 --channel edge --kernel ../linux/ubuntu-raspi2-kernel_4.8.0_armhf.snap --gadget pi2 --os
[15:24] <ppisati>  ubuntu-core -o ...
[15:25] <ppisati> i as trying to roll an image from a fresh kernel built using the snapcraft plugin
[15:25] <ppisati> usually i used snappy image for the target
[15:25] <ppisati> and then i installed the new kernel over it
[15:25] <ppisati> but this time i couldn't install a new kernel (couldn't connect to the store or something)
[15:26] <ogra_> well, did you update your u-d-f snap to the latest yet ?
[15:30] <ogra_> ppisati, https://docs.google.com/document/d/1jZqJ92g0ox9xUk8Nge3ess89dQChdMzKXrNwwgloEbc/edit#heading=h.mey6uws9k5sy is the master setup now (kernel.yaml was dropped after it was written)
[15:30] <sergiusens> ppisati that is why I asked you to update the branch ^
[15:31] <sergiusens> ogra_ there is no kernel.yaml implementation in snapcraft
[15:31] <ogra_> sergiusens, yeah, its gone as i said
[15:34] <ogra_> the only bits that count now are the fs structure inside the snap and "type: kernel" ... and indeed the version string needs to match the name of the modules dir
[15:38] <morphis> ogra_: btw. why are we not using something like https://github.com/snapcore/snapcraft/blob/master/demos/96boards-kernel/snapcraft.yaml for the pi kernel snaps?
[15:39] <ogra_> morphis, because our official kernels contain a ton more than just a kernel ... and we need to use the signed kernel binaries from the archive for secureboot
[15:39] <morphis> ogra_: I see
[15:39] <ogra_> (there are also postinst script tasks we need from the linux-image-*foo packages
[15:39] <ogra_> )
[15:40] <ogra_> s/ our official kernels/ our official kernel snaps/
[15:42] <ogra_> morphis, http://bazaar.launchpad.net/~snappy-dev/kernel-snap-makefile/trunk/view/head:/Makefile is our actual build script ... referencesd from the different snap builds like http://bazaar.launchpad.net/~snappy-dev/pi2-kernel-snap/trunk/view/head:/snapcraft.yaml
[15:42] <ogra_> *referenced
[15:43] <ogra_> (yes, i know it could use some cleanup, the Makefile takes nearly every possible kernel snap variant we ever had into account :) )
[15:44] <morphis> ogra_: thanks
[15:44] <om26er> Hi! Is there a way I can add wifi credentials in my RPi running snappy without ethernet or a screen ?
[15:44] <ppisati> sergiusens: i'm rebuilding with the up to date branch
[15:45] <ppisati> ogra_: there's no version 9 of u-d-f in xenial, or am i wrong?
[15:45] <ogra_> ppisati, sudo snap refresh ubuntu-device-flash --edge --devmode
[15:46] <ogra_> that should get you the very latest
[15:47] <ppisati> --devmode made a difference
[15:47] <ogra_> yeah
[15:47] <ppisati> withoput it, it would say "no updates ..."
[15:47] <ogra_> right, because it isnt in stable
[15:47] <ogra_> no options = only look in stable
[15:47] <ogra_> confinement: devmode = cant release to stable
[15:48] <ppisati> even if you say --channel=edge?
[15:48] <ogra_> yes
[15:48] <ppisati> ...
[15:59] <pbek> Hi folks, lately when I run my `qownnotes` snap I get the error message `multiple nvidia drivers detected, this is not supported`. Although I can run the QOwnNotes binary directly from the snap directory... Any ideas?
[15:59] <pbek> that's the yml: https://git.launchpad.net/~pbek/qownnotes-snap/tree/snapcraft.yaml
[16:00] <pbek> maybe kyrofa can help again?
[16:00] <mup> PR snapd#1811 opened: interfaces: serial-port: udev slot definition <Created by jocave> <https://github.com/snapcore/snapd/pull/1811>
[16:08] <ogra_> pbek, Bug 1615248 ... has a workaround too
[16:08] <mup> Bug #1615248: ubuntu-core-launcher nvidia driver detection is bogus <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1615248>
[16:08] <pbek> ogra_: I will check that, thanks a lot!
[16:13] <mup> PR snapd#1812 opened:  image,overlord/boot,snap: metadata from asserts for image snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/1812>
[16:15] <sergiusens> nessita looked at your problem re-did all of the python plugins last night (still experimenting) but your project does not work with a plain `pip install .` either
[16:15] <sergiusens> nessita from what I saw it is distutils use instead of setuptools
[16:16] <sergiusens> given the complexity of your project not sure how easy it is going to be
[16:16] <nessita> sergiusens, yeah, I blame dobey :-P
[16:16] <nessita> sergiusens, so first I need to make it work with "pip install ."?
[16:16] <sergiusens> nessita if it works with pip install it should work
[16:16] <nessita> sergiusens, I was hoping to avoid that since running it is just "PYTHONPATH=. ./bin/ubuntuone-syncdaemon"
[16:17] <sergiusens> nessita well a custom plugin could work or just installing the deps and using the dump plugin for everything else
[16:17] <nessita> sergiusens, that was my next question :-) where can I read on custom plugins?
[16:18] <sergiusens> nessita http://snapcraft.io/docs/build-snaps/plugins
[16:18] <nessita> sergiusens, thanks!
[16:20] <dobey> do what
[16:21] <dobey> oh crikey you're trying to make a snap of ubuntuone-client?
[16:23] <dobey> well ubuntuone-client isn't installable with pip install because we never uploaded/registered it there
[16:32] <niemeyer> morphis: snapd#1674 is ready for some love
[16:32] <mup> PR snapd#1674: interfaces/builtin: add udisks2 and pluggable-storage interfaces <Blocked> <Critical> <Reviewed> <Created by ssweeny> <https://github.com/snapcore/snapd/pull/1674>
[16:33] <morphis> niemeyer: thanks
[16:33] <niemeyer> jdstrand, morphis: Should we rename pluggable-storage to "media"?  That's almost the same, and in practice it gives access to /media, so rings a nice bell
[16:33] <morphis> ssweeny, jdstrand: can you comment on niemeyer's points on those?
[16:33] <morphis> niemeyer: media also rings other bells like hardware media encoding/decoding etc.
[16:34] <morphis> I still like plugable-storage more as that really describes what should only end up in /media
[16:34] <ssweeny> well it's a subset of removable media I guess
[16:34] <morphis> where /media is just the name being there for history reasons
[16:35] <niemeyer> morphis: Yeah, that's true..
[16:35] <niemeyer> morphis: "pluggable" is such an ugly term, though.. hmmm
[16:36] <morphis> a bit, yeah
[16:36] <morphis> niemeyer: I think for the access to /dev/sd* and /dev/mmcblk* we agreed with jdstrand that we allow this but explicitly put this into the udisks2 interface where we can ensure from the store side that just a single snap owned by canonical can use this
[16:36] <morphis> and nothing else
[16:37] <morphis> we maybe should enforce this in the sanitizeslot function
[16:37] <morphis> like we do for the lxd interface
[16:37] <sborovkov> Hello, does anyone know where I can download snapd 2.11 package for armhf?
[16:38] <niemeyer> morphis: I wouldn't like to make that the norm
[16:38] <morphis> niemeyer: yeah, but its a compromise until we have hotplug :-)
[16:39] <niemeyer> morphis: That's unrelated to hotplug
[16:40] <morphis> usb devices are hotpluged, so we get /dev/sd* /dev/mmcblk* device dynamically
[16:40] <niemeyer> morphis: That's still unrelated to hotplug
[16:40] <niemeyer> morphis: The problem is not the dynamic device.. it's the fixed one that contains the operating system
[16:41] <morphis> if you think it that way, yes, true
[16:41] <morphis> niemeyer: so short term for RTM, what are we doing?
[16:41] <niemeyer> morphis: What is the snap the holds the slot side of this?
[16:41] <morphis> udisks2
[16:41] <morphis> https://code.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/udisks/+ref/master
[16:42] <ppisati> sergiusens: it works, ship it!
[16:42] <ppisati> ogra_: ^
[16:42] <niemeyer> morphis: Okay, let's follow your advice and constrain it to udisks2/canonical until we have the snap declaration in place
[16:42] <niemeyer> morphis: So same as lxd-support
[16:42] <morphis> niemeyer: aye, thanks
[16:42] <morphis> ssweeny: ok with that?
[16:42] <niemeyer> morphis: Thank you
[16:43] <ssweeny> morphis, sure
[16:43] <morphis> niemeyer: want to get this solved :-)
[16:43] <morphis> "solved" to be honest
[16:43] <niemeyer> morphis: For the iface name, external-storage, dynamic-storage, <other idea>?
[16:43] <morphis> external-storage if we want to exclude system partitions
[16:44] <morphis> ssweeny: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/lxd_support.go#L95
[16:44] <morphis> ssweeny: but in our case that would be in SanitizeSlot
[16:44] <ssweeny> morphis, ack
[16:45] <morphis> niemeyer: but can't think of anything else
[16:45] <morphis> niemeyer: but will see if I get something better overnight
[16:45] <niemeyer> morphis: This is about /media to be clear
[16:45] <morphis> right
[16:45] <niemeyer> morphis: So it's not just about excluding system partitions
[16:46] <morphis> just asking to make this clear
[16:49] <morphis> niemeyer: if you don't like plugable-storage I would be then for external-storage
[16:49] <morphis> niemeyer: or removable-media according to http://www.pathname.com/fhs/pub/fhs-2.3.html#MEDIAMOUNTPOINT
[16:49] <niemeyer> morphis: You just made a typo on it. Yes, I really don't like it. :)
[16:50] <morphis> "3.11. /media : Mount point for removable media"
[16:50] <morphis> "This directory contains subdirectories which are used as mount points for removable media such as floppy
[16:50] <morphis> disks, cdroms and zip disks."
[16:51] <niemeyer> morphis: removable-media is nice
[16:51] <morphis> it doesn't mention usb, but same story
[16:51] <niemeyer> morphis: external-storage might mean S3/etc
[16:51] <morphis> yeah
[16:51] <morphis> so removable-storage it is
[16:51] <niemeyer> morphis: removable-media keeps the association with /media, so very nice
[16:51] <morphis> ssweeny, jdstrand: you're ok with that too?
[16:52] <niemeyer> morphis: media!
[16:52] <niemeyer> :)
[16:52] <morphis> sorry ..
[16:52] <morphis> too late
[16:52] <morphis> removable-storage
[16:52] <niemeyer> removable-media
[16:52] <morphis> ah sorry
[16:52] <morphis> niemeyer: can you comment that on the PR?
[16:52] <morphis> need to leave now
[16:52] <niemeyer> morphis: Yeah
[16:52] <niemeyer> morphis: Thanks o/
[16:52] <morphis> thanks
[16:53] <ssweeny> ok so we settled on removable-media?
[17:01] <mup> PR snapd#1809 closed: interfaces/builtin: allow writing on /dev/vhci in bluetooth-control <Created by cwayne18> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1809>
[17:09] <ev> sergiusens: do you care about "Coverage decreased (-0.03%) to 97.871%”? Should I pad that out with another test case?
[17:13] <niemeyer> ssweeny: Yeah
[17:13] <ssweeny> ack
[17:15] <ssweeny> niemeyer, when you say "the slot (not the interface) can only be used by udisks2" you just mean error on snap != udisks2 and dev != canonical in SanitizeSlot rather than SanitizePlug, right?
[17:15] <niemeyer> ssweeny: Right.. otherwise we'd only allow the snap to connect to itself
[17:15] <ssweeny> niemeyer, ok cool. Just making sure I understand
[17:15] <niemeyer> ssweeny: lxd-support is different because the slot is constrained to the core
[17:16] <niemeyer> ssweeny: It's the consumer that gets wider access
[17:16] <ssweeny> right
[17:16] <niemeyer> ssweeny: I think we'll eventually want to constrain the consumer of udisks2 as well, but we can probably wait until snap-declarations can do that
[17:17] <mup> PR snapcraft#748 closed: kernel plugin: vmlinuz -> kernel.img hard link <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/748>
[17:17] <ssweeny> that makes sense
[17:21] <sborovkov> jamiebennett: Hello. Who can I ask about store issue I have? For some reason can't install from our snap again though everything seems correct on my side. Evan Dandrea does not seem to appear on IRC for last couple of days (I wanted to ask him)
[17:25] <sergiusens> ev I thought that covering the schema in a unit test would bring the coverage back up for you
[17:25] <sergiusens> ev that is what I got from looking at coveralls
[17:25] <mup> PR snapd#1805 closed: tests: use beta u-d-f in test by default  <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1805>
[17:35] <jdstrand> niemeyer: I'm fine with media
[17:36]  * jdstrand but also continue to be fine with pluggable-storage
[17:39] <jdstrand> removable-media is nice
[17:39] <jdstrand> now that I've read backscroll :)
[17:40] <jdstrand> niemeyer, morphis: ^ +1 on removable-media
[17:45] <jdstrand> mvo: ping regarding merge questions
[17:45] <niemeyer> jdstrand: Ack, thanks
[17:48] <mvo> jdstrand: pong
[17:48] <jdstrand> mvo: hey, did you see my questions from earlier?
[17:48] <jdstrand> mvo: if not, that's fine
[17:48] <mvo> jdstrand: no, sorry
[17:49] <mvo> jdstrand: aha, policy
[17:49] <mvo> jdstrand: with two +1 you can merge
[17:50] <jdstrand> mvo: am I allowed to merge my own with two +1s or just others?
[17:51] <jdstrand> jamiebennett: btw, thank you for commenting in bug #1583514
[17:51] <mup> Bug #1583514: firewall-control and ip[6]table_filter module loading <snapd-interface> <Snappy:Triaged> <https://launchpad.net/bugs/1583514>
[18:02] <mvo> jdstrand: we have no rules here, but you can also merge other if you feel they are ok, I think you will have good judgement on this
[18:04] <jdstrand> mvo: ack, yes. just wanted to make sure I was following any commit policy. we talked about this before, but from the perspective of a non-committer. I jotted down what you said. Thanks!
[18:04] <mvo> jdstrand: sure, enjoy
[18:04] <jdstrand> mvo: oh, one last clarification-- the +1 must be froma core committer, yes?
[18:05]  * jdstrand is assuming two +1s from https://github.com/orgs/snapcore/people
[18:06] <mvo> jdstrand: yes, but we are sometimes leaniant about this, e.g. interfaces reviews can go in with a single +1 from a core commiter and an additonal one from a trusted community person
[18:06] <jdstrand> ok, then I think upower-observe fits that
[18:06] <mup> PR snapd#1813 opened: debian: umount --lazy before rm on snapd.postrm <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1813>
[18:07] <jdstrand> but the policy updates https://github.com/snapcore/snapd/pull/1779 does not
[18:07] <mup> PR snapd#1779: miscellaneous policy updates: default policy, browser-support, and x11 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1779>
[18:08] <mup> PR snapd#1797 closed: interfaces: add upower-observe interface (LP: #1595813) <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/1797>
[18:12] <dobey> error: cannot read snap file: cmd: "unsquashfs -i -d /tmp/read-file081779118/unpack /tmp/snapd-sideload-pkg-621916875 meta/snap.yaml" failed: exit status 1 ("Filesystem on /tmp/snapd-sideload-pkg-621916875 is (49135:701), which is a later filesystem version than I support!\n")
[18:14] <dobey> ^^ i get this when trying to install sl-moon127
[18:16] <dobey> also with tree.snap
[18:16] <dobey> err, tree from psivaa
[18:28] <mup> PR snapd#1790 closed: store: set initial device session <Critical> <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1790>
[18:32] <mup> PR snapd#1784 closed: Add an interface to access the usb drives <Created by axelebas> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1784>
[18:33] <tianon> lool: can you give me slightly higher privs on https://github.com/docker-snap ? :)  (wanting to rename the repo I just transferred there)
[18:34] <mup> PR snapd#1779 closed: interfaces: updates to default policy, browser-support, and x11 <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1779>
[18:39] <dobey> i guess mup is the only living thing in here really
[18:47] <jdstrand> roadmr: hey, cprov said he was going to ensure that the 'grade' commits to the review tools are pulled. can you guys just make that r736?
[18:48] <jdstrand> roadmr (cc cprov): that's* r736 has a nicer message for a desktop file error
[18:49] <cprov> jdstrand: np, will bump SCA
[18:50] <lool> tianon: hey
[18:50] <ogra_> hmpf ...  i cant access the uploads histrory of ubuntu-core in the store anymore ... i get a permanent gateway timeout
[18:50] <lool> tianon: sure
[18:50] <ogra_> nessita, are you able to open this page ?  https://myapps.developer.ubuntu.com/dev/click-apps/4142/configurations/
[18:50] <lool> tianon: done, you're owner too now
[18:50] <ogra_> looks like the store timeouts start to get more serious
[18:50] <lool> tianon: I dont think I could adjust this earlier, it was pending your acceptance of the invitation
[18:52] <jdstrand> cprov: thanks!
[18:54] <nessita> ogra_, checking
[18:55] <ogra_> (this is the uploads summary page of ubuntu-core ... which is admittedly a long list (but far from where we will be at in ... say 6 months))
[18:56] <nessita> ogra_, no, too slow
[18:56] <nessita> ogra_, let me check
[18:57] <ogra_> nessita, there are 6 uploads a day happening (6 arches, automated daily build for edge) ... so this will explode even more in the future
[18:58] <nessita> ogra_, right, it shouldn't, could you please file a bug?
[18:58] <ogra_> will do
[18:58] <ogra_> i guess i hit a threshold today ... yesterday it still worked :)
[18:58] <nessita> ogra_, yeah, it needs fixing for sure
[18:59] <nessita> ogra_, I have oopses with the sql timeline, so we can debug from there, but the bug will help us track this
[18:59] <ogra_> oki
[19:02] <ogra_> nessita, bug 1619018
[19:02] <mup> Bug #1619018: timeouts when trying to look at the uploads summary of ubuntu-core <Software Center Agent:New> <https://launchpad.net/bugs/1619018>
[19:04] <nessita> ogra_, thanks!
[19:04] <ogra_> np, thanks for looking :)
[19:21] <lool> tianon: I wonder whether this proposed change could be related https://github.com/snapcore/snap-confine/pull/122/files
[19:21] <mup> PR snap-confine#122: Replace pivot_root implementation by LXC's <Created by stgraber> <https://github.com/snapcore/snap-confine/pull/122>
[19:21] <mup> PR snapd#1813 closed: debian: umount --lazy before rm on snapd.postrm <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1813>
[19:25] <lool> tianon: and that might explain the difference between a classic and a core system: there would be other mounted filesystems
[19:29] <mup> PR snapd#1777 closed: osutil: tweak the createUserTests a bit and extract common code <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1777>
[19:42] <tedg> Snapd is failing for me: "internal error: could not unmarshal state entry "snaps": json: cannot"
[19:43] <tianon> lool: thanks :)
[19:43] <tianon> lool: nice find!  that does look like it could be related!
[19:43] <tedg> Ah, got the rest: "cannot unmarshal string into Go value of type int"
[19:47] <mup> PR snapd#1814 opened: client,cmd/snap: display os-release data only on classic <Created by zyga> <https://github.com/snapcore/snapd/pull/1814>
[19:47] <lool> tianon: actually they get an "operation not permitted" on unshare
[19:47] <mup> PR snapcraft#772 opened: Set GOBIN in go plugin build environment <Created by tasdomas> <https://github.com/snapcore/snapcraft/pull/772>
[19:48] <tianon> lool: interesting, although could definitely still be related!
[19:48] <tianon> lool: rootfs issues always come in spades, in my experience...
[19:48] <tianon> as evidenced by Docker 1.11 and 1.12 getting entirely different errors :)
[19:49] <lool> tianon: a quick grep on the source doesn't yeild very interesting usages of unshare in docker, but could still be the same issue yeah
[19:49] <zyga> jdstrand: not high priority but I'd love to know +/-1 on https://github.com/snapcore/snap-confine/pull/121
[19:49] <mup> PR snap-confine#121: Allow the use of capabilities over setuid bit <Created by zyga> <https://github.com/snapcore/snap-confine/pull/121>
[19:49] <tasdomas> is there a way to allow a snap application access to system files (e.g. /etc/hosts) ?
[19:49] <lool> tianon: if you're tempted to rebuild snapd with that pull request and try that, that might prove the point or not
[19:49] <tianon> yeah, definitely tempting
[19:49] <tianon> had been pondering whether it was worth trying, but I think it likely is
[19:50] <lool> tianon: I have to disappear for a bit to hug the family and I'm not feeling too well so I probably wont last long
[19:50] <lool> I'll check back in a few
[19:50] <tianon> lool: ok, no worries!  thanks for the extra eyes, and take care of yourself :)
[19:52] <sborovkov> Hello, any way I can make snapcraft ignore such errors? '/home/kami/build/snaps/full/parts/ping-wrapper/build/rootfs/var/lib/avahi-autoipd' is a broken symlink pointing outside the snap
[19:57] <tedg> So it looks like my state.json is somehow invalid, is there a way to rebuild it?
[20:04] <jdstrand> ogra_: hey, we used to have http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/current/. where has that gone?
[20:06] <jdstrand> ogra_: well, my real question is where do a find a linux-generic kernel for armhf? (I'm updating some docs)
[20:09] <jdstrand> ogra_: also, http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/current/ had manifests. where did those go? I feel like you told me that once before.... this time I am documenting it :)
[20:09] <jdstrand> :wq
[20:09] <jdstrand> meh
[20:11] <magicaltrout> not even irrsi supports :wq
[20:12] <mup> PR snapd#1815 opened: Auto connect interfaces for special name/developer combinations <Created by arges> <https://github.com/snapcore/snapd/pull/1815>
[20:12] <magicaltrout> so lazyPower  now the crazyiness is coming to an end, i should have some cycles over the next few weeks to tidy up a bunch of DC/OS stuff and add some proper relations etc
[20:13] <lazyPower> nice
[20:13] <magicaltrout> one thing people did like today was the fact you could leverage stuff deployed in DC/OS againsts normal charms
[20:13] <magicaltrout> assuming the hooks provided enough metadata
[20:14] <nessita> ogra_, hey, are you blocked by this store timeout in the configurations page?
[20:36] <ev> sergiusens: oh yes, I forgot you had requested that. On it
[20:54] <mup> PR snapd#1816 opened: libvirt interface to allow snaps to access libvirtd on a classic host <Created by cmars> <https://github.com/snapcore/snapd/pull/1816>
[21:08] <mup> PR snapd#1817 opened: Wrapper: create $SNAP_USER_COMMON (LP:#1611063) <Created by brunonova> <https://github.com/snapcore/snapd/pull/1817>
[21:17] <mup> PR snapd#1789 closed: many: when installing snap file derive metadata from assertions unless --force-dangerous <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1789>
[21:31] <lool> tianon: I'm headed to bed, did you find anything?
[21:32] <tianon> lool: I tried several times to just dpkg-divert snap-confine's binary and copy in my manually-built binary, but couldn't get it working (and hadn't decided to just grab the direct .deb src to apply the patch and build a whole new .deb yet)
[21:32] <kyrofa> tianon, you're trying to run your own snap-confine?
[21:32] <tianon> yeah
[21:32] <tianon> kyrofa: trying to test https://github.com/snapcore/snap-confine/pull/122, specifically
[21:32] <mup> PR snap-confine#122: Replace pivot_root implementation by LXC's <Created by stgraber> <https://github.com/snapcore/snap-confine/pull/122>
[21:33] <tianon> because we think it might be a potential fix for the issues we're seeing with Docker in Classic too
[21:33] <lool> tianon: note that snapd reexecs itself from the ubuntu core snap; I dont know about snap-confine though
[21:33] <tianon> ah
[21:33] <kyrofa> tianon, lool indeed, which makes it very difficult to test some things
[21:34] <tianon> :)
[21:34] <lool> tianon: set SNAP_REEXEC=0
[21:34] <kyrofa> tianon, lool if re-exec is enabled, it's probably using the snap-confine from within the core snap
[21:34] <lool> in the env
[21:34] <lool> tianon: snapd env should be enough, via an override file would work; or set it in /etc/environment
[21:34] <tianon> I get permission errors when I replace my host env's snap-confine, so I think that is being used at least in some capacity
[21:35] <lool> tianon: oh quite probably indeed
[21:35] <lool> tianon: is it +x?
[21:35] <tianon> yes
[21:35] <tianon> and u+s
[21:35] <tianon> just like the original
[21:35] <tianon> it executes fine, but has other errors, so I'm not convinced I'm compiling correctly
[21:35] <tianon> hence why I was going to try re-building a new .deb
[21:35] <stgraber> tianon: you may want to unload the snap-confine apparmor profile
[21:35] <lool> yeah, makes sense
[21:36] <kyrofa> tianon, you can always overlayfs the new binary on top of the one in the core snap too
[21:36] <stgraber> tianon: the new snap-confine does a bunch of new things which the old profile doesn't allow, so you either want to update your local profile or just disable it (I did the later while working on that branch)
[21:36] <kyrofa> But yeah... profiles
[21:36] <tianon> stgraber: ah, exciting -- I even tried building straight from the tag of my host version
[21:37] <tianon> stgraber: can't we just make everything unconfined and call it a day? O:)
[21:37] <lool> tianon: probably wouldn't help since there were no denials
[21:37] <tianon> lol I know, just joking around
[21:37] <tianon> permissions are hard, let's go ride bikes
[21:38] <lool> :)
[21:41] <mup> PR snapcraft#763 closed: Include /sbin and usr/sbin in wrappers <Created by lool> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/763>
[21:48] <cmars> your CI log banners are awesome
[21:50] <mup> PR snapcraft#510 closed: Use the in ubuntu-core python3 <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/510>
[22:32] <ogra_> jdstrand, you mean a linux-generic snap ? we dont build that atm ... and the cdimage images had to be removed "on request"... our ubuntu-image created ones will go there after RTM
[22:33] <ogra_> regarding manifests ... we'll soon get them for the ubuntu-core snap builds .. i'll then link them from http://people.canonical.com/~ogra/ubuntu-core-builds/
[22:35] <ogra_> jdstrand, if you want to roll your own kernel snap ... fork https://code.launchpad.net/~snappy-dev/pi2-kernel-snap/trunk ... and https://code.launchpad.net/~snappy-dev/kernel-snap-makefile/trunk ... then edit the armhf target in the Makefile, make your snapcraft.yaml from your pi2-kernel-snap use your Makefile and just let LP build the snap for you
[22:35] <ogra_> s/from/for/
[22:35] <ogra_> err
[22:36] <ogra_> (if needed i can set that up for you, but not tonight anymore :) )
[22:38] <ogra_> nessita, well, it is the only way to see which revision was released to stable currently ... if you have another way to get the channel info then the page isnt that important
[22:40] <slangasek> ogra_: so, u-d-f's implementation of pi2 support says 'bcm2836-rpi-2-b'... which is not the name of a file anywhere in the resulting boot partition.  Is this the wrong dtb name?
[22:46] <slangasek> ogra_: I see in uboot.env that we have fdtfile=bcm2709-rpi-2-b.dtb; that's a file that exists in the gadget snap boot-assets dir and is published without modification or name change to the boot partition.  So the 'device-tree'/'platform' declaration seems to not do anything useful here
[22:58] <ogra_> slangasek, yeah, not on the pi2 (as i explained, the SBL loads it ... )
[22:59] <ogra_> but bcm2709-rpi-2-b.dtb should be the correct name
[23:00] <ogra_> s/SBL/SPL/
[23:01] <ogra_> we should definitely ship it in case we find a way to use uboot for loading the dtb and overlays one day
[23:01] <ogra_> so try to treat it as if it would be used :)
[23:10] <slangasek> ogra_: ok; I think the pi2 gadget is ready for a release, I don't think I've been given access to upload that one
[23:11] <ogra_> slangasek, well, we need someone to approve even if i upload it for you ... did you merge your changed in the snappy-systems branch ? i dont see any changes
[23:11] <ogra_> (i just did all the file moves to clean up boot-assets)
[23:12] <slangasek> ogra_: erm, where are you pushing these changes?  I'm using lp:~snappy-dev/snappy-hub/snappy-systems which is the only branch I've ever been told about
[23:12] <ogra_> http://paste.ubuntu.com/23118082/
[23:12] <ogra_> i see commits in the bzr log but i see no actual files there
[23:13] <ogra_> oh, i' blind
[23:13] <ogra_> *i'm
[23:13] <ogra_> sorry ...
[23:13] <slangasek> ok :)
[23:14] <wililupy> Does anyone know of an easy way to implement a udev rule file so that it doesn't have to be created after installation manually?
[23:14] <ogra_> slangasek, change pushed
[23:14] <wililupy> maybe in cloud init after snappy starts up?
[23:14] <ogra_> i can upload the gadget, but i think we need someone like jdstrand to approve it
[23:15] <lool> tianon: I'm headed to bed, good night
[23:15] <tianon> lool: good night!
[23:15] <wililupy> Dang lool, burning the midnight oil? Get some rest
[23:16] <ogra_> slangasek, btw, versions are shallow in snaps  :) all that counts is the revision the store assigns
[23:16] <slangasek> ogra_: yes; that doesn't mean they're not a useful convention
[23:17] <slangasek> ogra_: I don't see your boot-asset change pushed?
[23:17] <ogra_> well, you end up with two ... next to each other in snap list ... which adds confusion ... but yeah
[23:18] <ogra_> gah
[23:18] <ogra_> seems we clashed mid air
[23:20] <ogra_> oh, wow
[23:20] <ogra_> i can actually publish it in the store
[23:20] <ogra_> done :)
[23:20] <ogra_> and branch pushed as well
[23:22] <ogra_> slangasek, you got mail ;)
[23:23] <ogra_> argh, crap
[23:23] <ogra_> i forgot to generate uboot.env
[23:23]  * ogra_ fixes
[23:26] <ogra_> slangasek, 16.04-0.10 revision 17 is what you want
[23:26] <ogra_> uploaded and published
[23:26] <slangasek> cool
[23:26] <ogra_> and you have upload access too now
[23:26] <ogra_> (once you accept the invite :) )
[23:27] <slangasek> \o/
[23:27] <slangasek> ogra_: you want to add me to dragonboard too while you're at it?
[23:27] <ogra_> sure
[23:28] <ogra_> added you to pi3 as well :)
[23:37]  * ogra_ vanishes back into the night... :)
[23:43] <slangasek> ogra_: ok, well that broke snap prepare-image; iterating