[00:29] <mup> PR snapd#2054 closed: client,daemon,cmd/snap: improve create-user APIs <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2054>
[03:42] <mwhudson> is it possible to get snapd to forget about an assertion?
[06:54] <zyga> hey
[06:54] <zyga> mwhudson: I think only with a new assertion
[06:54] <zyga> mwhudson: (or with rm -f)
[07:25] <mup> PR snapd#2056 opened: interfaces: add Plug/Slot/Connection reference helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2056>
[07:40] <mwhudson> morning
[08:03] <mup> PR snapd#2056 closed: interfaces: add Plug/Slot/Connection reference helpers <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2056>
[08:16] <mup> PR snapd#2057 opened: docs: remove references to removed buying features <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2057>
[08:17] <mup> PR snapd#2058 opened: interfaces: add ofono interface <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/2058>
[08:21] <hikiko> hello :)
[08:21] <hikiko> I need some help with an error message during dist-upgrade on X
[08:21] <hikiko> http://pastebin.com/HUcC3wWg
[08:22] <hikiko> the initial problem I was trying to solve was this:
[08:25] <hikiko> I have 2 graphics cards intel and nvidia, but I work on the intel, the nvidia is there for testing features and during the last dist-upgrades the nvidia drivers and several other packages were automatically installed and messed up my xorg configuration so I couldn't use any of the cards. everytime I remove the nvidia drivers and the other packages they are reinstalled as a dependency of libcuda1-361 and every time I try to remove
[08:25] <hikiko> it I receive that error message...
[08:25] <hikiko> any ideas? :)
[08:32] <mup> PR snapd#2059 opened: interfaces: add repo.ResolveConnect that handles name resolution <Created by zyga> <https://github.com/snapcore/snapd/pull/2059>
[08:34] <didrocks> hikiko: no package I can see contain this file, I guess it's snapd creating it dynamically for system mount point. It's a question for mvo or zyga ^
[08:39] <hikiko> thanks didrocks :)
[09:28] <mup> PR snapd#2060 opened: many: change Connect to take ConnRef instead of strings <Created by zyga> <https://github.com/snapcore/snapd/pull/2060>
[09:52] <mup> PR snapd#2061 opened: interfaces: add dummy implementation of ResolveConnect <Created by zyga> <https://github.com/snapcore/snapd/pull/2061>
[09:55] <didrocks> zyga: hey! It seems that if a service fails to start at installation time, the snap is removed
[09:55] <didrocks> zyga: that makes it hard for debugging, any tip about it?
[09:55] <didrocks> davidcalle: FYI (on the doc)
[10:30] <zyga> didrocks: hey
[10:30] <zyga> hikiko: looking
[10:31] <zyga> hikiko: that's something that was only available in -proposed
[10:32] <zyga> hikiko: this is something that has to be fixed in the nvidia packaging but I believe it was removed already
[10:32] <zyga> hikiko: can you check if you can downgrade to the non-proposed package and see if the problem goes away
[10:32] <zyga> didrocks: I wasn't aware of it
[10:32] <zyga> didrocks: I don't know what is the plan about this, sorry
[10:33] <hikiko> zyga, how can I downgrade it?
[10:39] <zyga> hikiko: I think you can try to install it with "apt install package=version"
[10:40] <zyga> hikiko: alternatively edit the dpkg maintainer script on your disk not to touch that mount unit
[10:40] <zyga> hikiko: but really, I don't fully know what is required; you probably want to ask alberto milone or mvo (try alberto first please)
[10:40] <hikiko> zyga, and where can I find the version to which I have to downgrade?
[10:40] <zyga> hikiko: try apt-cache policy package
[10:41] <zyga> this will show you available versions
[10:41] <hikiko> thanks zyga :) I'll try
[10:41] <zyga> (the package in question is the one that fails because of the maintianer script)
[10:41] <zyga> *maintainer
[10:51] <mup> PR snapd#2062 opened: interfaces/policy: introduce InstallCandidate and its checks <Created by pedronis> <https://github.com/snapcore/snapd/pull/2062>
[11:46] <mup> PR snapd#2063 opened: interfaces,docs: allow sharing SNAP{,_DATA,_COMMON} via content iface <Created by zyga> <https://github.com/snapcore/snapd/pull/2063>
[11:47] <zyga> jdstrand: hey, you may want to review this one ^6
[12:04] <didrocks> zyga: hikiko|ln: btw, easier for downgrading, you can do apt install package/<distropocket> (like package/yakkety for instance)
[12:05] <hikiko|ln> didrocks, if I try to do that the proposed are selected
[12:06] <didrocks> no
[12:06] <didrocks> if you don't set yakkety-proposed, and only yakkety, it will select yakkety
[12:06] <didrocks> (with -f to force a downgrade ofc)
[12:07] <hikiko|ln> # apt install libcuda1-361/xenial -f
[12:07] <hikiko|ln> Get:1 http://archive.ubuntu.com/ubuntu xenial-proposed/restricted amd64 nvidia-367 amd64 367.44-0ubuntu0.16.04.2 [69,6 MB]
[12:08] <didrocks> this is the nvidia package
[12:08] <didrocks> not libcuda1-361
[12:08] <hikiko|ln> yup it's a dependency
[12:08] <didrocks> so ofc, the other packages follow the general scheme
[12:08] <hikiko|ln> oh ok :)
[12:08] <didrocks> so, you need to list it
[12:08] <didrocks> # apt install libcuda1-361/xenial nvidia-367/xenial -f
[12:08] <didrocks> and so on… :)
[12:09] <hikiko|ln> I need to remove the dependencies and libcuda didrocks
[12:09] <hikiko|ln> should I first downgrade then remove?
[12:09] <didrocks> I would say yeah, first downgrade everything to remove -proposed components
[12:09] <didrocks> and then remove
[12:09] <didrocks> (get in a consistent state first)
[12:10] <hikiko|ln> ~# apt install libcuda1-361/xenial  nvidia-367/xenial nvidia-opencl-icd-367/xenial nvidia-prime/xenial nvidia-settings/xenial -f
[12:10] <hikiko|ln> Get:1 http://archive.ubuntu.com/ubuntu xenial-proposed/restricted amd64 nvidia-367 amd64 367.44-0ubuntu0.16.04.2 [69,6 MB]
[12:11] <hikiko|ln> it seems to ignore my setting
[12:11] <didrocks> hum… that's weird
[12:11] <didrocks> what if you only do apt install nvidia-367/xenial -f only?
[12:12] <hikiko|ln> https://paste.ubuntu.com/23269943/ didrocks
[12:16] <didrocks> hikiko|ln: I think you have another package that forces you to get that version
[12:17] <hikiko|ln> I've purged nvidia* didrocks
[12:17] <hikiko|ln> can I see which package it is somehow?
[12:17] <didrocks> and here we go
[12:17] <didrocks> https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-367
[12:17] <didrocks> -367 is only available in -proposed
[12:17] <didrocks> that's why he didn't follow your guidance to prefer the /xenial one :p
[12:17] <hikiko|ln> and I didn't have it installed
[12:18] <hikiko|ln> so what should I do?
[12:18] <didrocks> I'm pretty sur eyou have something like libcuda1-367 or anything depending on it
[12:18] <didrocks> well, you did purge it, right?
[12:18] <hikiko|ln> the initial problem is to remove libcuda1-361
[12:18] <hikiko|ln> yup
[12:18] <didrocks> apt-cache rdepends nvidia-367
[12:18] <didrocks> anything there? ^
[12:18] <hikiko|ln> Reverse Depends:
[12:18] <hikiko|ln>   libcuda1-367
[12:18] <hikiko|ln>   nvidia-opencl-icd-367
[12:18] <hikiko|ln>   nvidia-367-dev
[12:18] <hikiko|ln>   nvidia-361
[12:18] <didrocks> yeah, so you need to remove any of those installed
[12:19] <didrocks> just purge them
[12:21] <hikiko|ln> 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
[12:21] <hikiko|ln> they seem purged
[12:21] <didrocks> good :)
[12:21] <hikiko|ln> maybe rdepends libcuda1-361?
[12:21] <didrocks> you was able to delete it as well?
[12:21] <didrocks> now, try to remove it
[12:21] <didrocks> as it's what you wanted IIRC
[12:22] <hikiko|ln> same
[12:22] <hikiko|ln> E: Sub-process /usr/bin/dpkg returned an error code (1)
[12:23] <didrocks> maybe zyga telling to downgrade nvidia on the proposed didn't indicate the right package
[12:23] <didrocks> (I didn't follow closely)
[12:23] <didrocks> ensure you don't have snapd from proposed from what I understand
[12:24] <hikiko|ln> mmm how?
[12:24] <didrocks> apt-cache policy snapd
[12:24] <didrocks> do you have the proposed version installed?
[12:24] <hikiko|ln> yes
[12:24] <didrocks> so, same
[12:24] <didrocks> revert to the one on xenial
[12:25] <hikiko|ln> same :/
[12:25] <hikiko|ln> if I purge snapd
[12:26] <hikiko|ln> remove the package and reinstall it?
[12:27] <hikiko> still :p just tried that
[12:31] <lool> ogra_: Hey, around?
[12:31] <lool> ogra_: were you the one implementing the dragonboard boot support?  :-)
[12:33] <ara> zyga, ping
[12:40] <mup> PR snapd#2064 opened: Adding new AutopilotIntrospectionInterface <Created by heber013> <https://github.com/snapcore/snapd/pull/2064>
[13:02] <zyga> ara: hey
[13:02] <zyga> ara: how can I help you
[13:02] <ara> zyga, hey! I was wondering how the snap-confine SRU to xenial was going
[13:02] <ara> zyga, any news?
[13:03] <ara> zyga, (what's the bug report to track it?)
[13:18] <zyga> ara: the status is that we landed one SRU last week but we need to go through all the bugs and verify those
[13:18] <zyga> ara: I won't have time for this today as we're freezing now and I need to finish features first
[13:19] <ara> zyga, where is the bug that tracks the SRU?
[13:19] <zyga> ara: if you can help by asking anyone to go through all the SRU bugs on launchpad for snap-confine, we can do this faster
[13:19] <zyga> ara: there's no one bug, each bug has SRU data now
[13:19] <ara> zyga, perfect, I will check on the report page
[13:19] <zyga> ara: look at milestones .40, .41 an.42
[13:19] <zyga> ara: .42 has two bugs that don't have SRU data but I can add that quickly; this was a tiny release
[13:20] <zyga> ara: if you can get me someone to work on validation I will save a lot of time
[13:20] <ara> zyga, are you sure that the SRU landed in -proposed? I don't see it in the http://people.canonical.com/~ubuntu-archive/pending-sru.html
[13:20] <zyga> ara: no, ah, sorry, too many facts lately, .41 was in -proposed but we removed it and someone should upload .42 now
[13:21] <zyga> ara: (there's .42.1 but it doens't have to be released now)
[13:21] <ara> zyga, can you organize uploading it, please? I can help verifying it
[13:22] <zyga> ara: yes, I can
[13:22] <zyga> ara: thank you :)
[13:22] <ara> zyga, thanks you!
[13:22] <ara> zyga, *thank
[13:33] <zyga> joc: ok, branch comig up, just a simple unit test to tie it together
[13:33] <zyga> joc: I will need you to add this udev rule manually to your device and see if it does the right thing
[13:34] <zyga> joc: (no need to build/alter snapd)
[13:40] <ogra_> lool, http://bazaar.launchpad.net/~ogra/+junk/dragonboard/files ... there is a README ... gadget code is at http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files/head:/dragonboard/
[13:41]  * ogra_ goes back to uniting :)
[13:41] <joc> zyga: ack
[13:45] <zyga> joc: ok, pull request is up, mup will share the link in a sec
[13:45] <mup> PR snapd#2065 opened: interfaces/builtin: use udev to export GPIOs to userspace <Created by zyga> <https://github.com/snapcore/snapd/pull/2065>
[13:46] <zyga> joc: look at tests, get the rule there and stick it into /lib/udev/rules.d/foo.rules
[13:47] <zyga> joc: look at journal and run:
[13:47] <zyga> joc: udevadm control --reload-rules
[13:47] <zyga> joc: udevadm trigger
[13:47] <zyga> joc: the first one should not be required but it's safe to run anyway
[13:47] <zyga> joc: if I got this right it will export one GPIO to userspace
[13:47] <zyga> joc: if not, well, iterate :)
[13:48] <joc> zyga: got it, i'll just tidy up some testing i've been doing of netplan then get right on it
[13:50] <oparoz> Hello, is there a solution in the works to upgrade from one Snap to another?
[13:50] <zyga> joc: thanks, ping me when you got something
[13:50] <zyga> oparoz: ?
[13:50] <zyga> oparoz: can you explain what you mean by this
[13:50] <oparoz> zyga myappv1 to myappv2
[13:51] <zyga> oparoz: and what are myappv1 and myappv2?
[13:51] <zyga> oparoz: snap names, snap versions, something else?
[13:51] <oparoz> zyga, we can't force people to upgrade to v2, so we need a new snap, but then how do people migrate for v1 to v2?
[13:51] <zyga> oparoz: why do you need a new snap?
[13:51] <zyga> oparoz: and what do you mean by "we cannot force people to upgrade"
[13:52] <oparoz> zyga, let's say I offer 3 years support for v1 and every time I release a new version
[13:52] <zyga> oparoz: ah I see what you mean now
[13:52] <oparoz> I mean every year, I release a new version
[13:53] <zyga> oparoz: right now you'd have to indeed offer a second snap if you want to have a different snap that can be concurrently updated (or not)
[13:53] <oparoz> zyga, so some users will want to stay on v1 for a long time and we can't just push v2 to the current dsnap
[13:53] <zyga> oparoz: using the content interface you could offer data migration
[13:53] <zyga> oparoz: I actually added support for this just now: https://github.com/snapcore/snapd/pull/2063
[13:53] <mup> PR snapd#2063: interfaces,docs: allow sharing SNAP{,_DATA,_COMMON} via content iface <Created by zyga> <https://github.com/snapcore/snapd/pull/2063>
[13:53] <oparoz> zyga, ah interesting, I'll look into that
[13:54] <oparoz> Thanks
[13:54] <Mirv> stupid questions again, if I extend make plugin, with eg. command.extend("INCLUDEPATH ..., why do I get "make I N C L U D E P A T H + = " / h " type of output? ...
[13:54] <cjwatson> Because you probably meant command.append
[13:54] <cjwatson> command.extend takes a sequence
[13:55] <zyga> yep
[13:55] <cjwatson> So either command.append("...") or command.extend(["...", "...", ...])
[13:55] <Mirv> ah, thank you, I'm happy someone endures me :)
[14:16] <niemeyer> jdstrand: ping
[14:16] <jdstrand> niemeyer: hey
[14:17] <niemeyer> jdstrand: Heya
[14:17] <niemeyer> jdstrand: Today it's a bit of a critical day for us.. we want to get all the PRs to the freeze in place by the EOD
[14:17] <niemeyer> jdstrand: How're things looking on your end?
[14:18] <niemeyer> jdstrand: Would you be able to prioritize work that is freeze-related today?
[14:18] <jdstrand> niemeyer: those PRs pedronis mentioned already are prioritized. is there anything beyond that?
[14:19] <pedronis> jdstrand: I should get a couple more
[14:19] <pedronis> but nothing atm
[14:19] <niemeyer> jdstrand: These are the top ones
[14:20] <niemeyer> e.g. #2053 might be a good starting point
[14:20] <niemeyer> snapd#2053
[14:20] <mup> PR snapd#2053: interfaces/policy: implement snap-id/publisher-id checks <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2053>
[14:21] <jdstrand> niemeyer: that is next on the list
[14:21] <niemeyer> jdstrand: Thanks!
[14:22] <mup> PR snapd#2061 closed: interfaces: add dummy implementation of ResolveConnect <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2061>
[14:31] <zyga> joc: any updates
[14:35] <joc> zyga: done with netplan switching over now
[14:35] <mup> PR snapcraft#846 closed: Release changelog for 2.19 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/846>
[14:35] <zyga> joc: thanks!
[15:04] <elopio> kyrofa: can you help me understand when to use SNAP_USER_DATA and when to use SNAP_USER_COMMON?
[15:04] <kyrofa> Hey elopio! I'd be happy to
[15:05] <kyrofa> What kind of app are we talking, here?
[15:05] <kyrofa> Or just generic?
[15:06] <elopio> kyrofa: I have two. syncthing, which is peer to peer file synchronization. And the mysql database of nylas sync-engine, which is an imap thing.
[15:08] <kyrofa> elopio, so obviously since snaps are often made up of many components, you often find yourself with a few different datasets that need to be saved
[15:08] <kyrofa> elopio, for each one, think about what should happen to it when an upgrade occurs
[15:08] <kyrofa> You want to make sure the stuff you save won't get in the way of upgrades or rollbacks
[15:09] <kyrofa> For example: does my dataset need to be mutated in some way for a few version?
[15:09] <kyrofa> Or is it just raw data that isn't really modified?
[15:10] <kyrofa> If new versions need to modify it, it's possible that the modifications aren't backward-compatible. Such datasets should probably go into SNAP_USER_DATA instead of COMMON, since each version has its own copy of that data
[15:10] <kyrofa> And rollbacks will work, even if you mutate the data in newer versions
[15:11] <elopio> it's hard, because I think the distinction is not designed in the tools. For example, syncthing has a home folder, where it stores the files to sync, and metadata.
[15:11] <kyrofa> elopio, another aspect to consider is how much space is taken by the dataset. Is it massive? Does it make sense to copy it for every upgrade?
[15:11] <elopio> I think the files to sync should be in common, the metadata in user_data, but I can't split them.
[15:12] <kyrofa> elopio, indeed
[15:12] <kyrofa> elopio, is it like the owncloud client? Where you add directories to a gui client?
[15:13] <elopio> kyrofa: yes.
[15:13] <kyrofa> elopio, or does it have only one directory?
[15:13] <elopio> you have one default directory, which probably should be in SNAP_USER_COMMON/Sync, and then you can add additional
[15:14] <kyrofa> And it saves metadata specific to that folder within each folder being synced?
[15:14] <kyrofa> It doesn't have any sort of central database?
[15:15] <elopio> kyrofa: it has a central config xml, and some certificates.
[15:16] <kyrofa> elopio, where does that central config go?
[15:16] <elopio> kyrofa: you start the server with synchting --home=$DIR.
[15:16] <elopio> the config ends in that dir.
[15:17] <kyrofa> elopio, could that not be SNAP_USER_DATA, then?
[15:19] <elopio> yes, but then the default SYNC dir would also end up in ~/snap/syncthing/rev/.
[15:19] <elopio> kyrofa: maybe you can comment here: https://github.com/syncthing/syncthing/pull/3636#discussion_r81488374
[15:19] <mup> PR syncthing/syncthing#3636: Add the packaging metadata to build the syncthing snap <Created by elopio> <https://github.com/syncthing/syncthing/pull/3636>
[15:19] <elopio> I'm sure you can explain it better than me.
[15:21] <kyrofa> elopio, hmm... yeah, you probably don't want files accumulating there
[15:21] <kyrofa> elopio, it's too bad they're so tightly coupled!
[15:22] <elopio> kyrofa: the guy is really nice, I thing. So if we explain the thing, probably he can add a separate flag for default sync dir.
[15:23] <kyrofa> elopio, this looks like an old diff. What is SNAP_USER_DIR?
[15:23] <elopio> but as I understand, the answer to his question is: the config should be in SNAP_USER_DATA, just like it's currently doing.
[15:23] <elopio> kyrofa: a mistake. I just removed it.
[15:23] <kyrofa> Ah, now there's no flags
[15:23] <elopio> if you don't pass -home, it will use $HOME.
[15:24] <kyrofa> Okay, I'll make a comment here
[15:24] <elopio> thank you.
[15:26] <kyrofa> Argh, firefox! I had a comment all written out...
[15:27] <kyrofa> Oh it saved it. Nice
[15:30] <sergiusens> elopio hint, snapcraft/xenial-proposed ;-)
[15:31] <elopio> sergiusens: \o/
[15:31] <elopio> ah, I don't have the tests prepared this time.
[15:34] <mup> PR snapd#2063 closed: interfaces,docs: allow sharing SNAP{,_DATA,_COMMON} via content iface <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2063>
[15:47] <Croepha> hi, in core 16, can you disable nplan and use the older /etc/network/interfaces.d/... files?
[15:51] <kyrofa> Croepha, probably a question for ogra_
[15:55] <mup> PR snapd#2057 closed: docs: remove references to removed buying features <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2057>
[15:55] <Croepha> on core is /etc/passwd supposed to be writeable ?
[15:58] <Croepha> kyrofa, thanks, but I think i figured out the nplan thing, it seems that if you just delete the nplan config, it will use the old config
[15:59] <Croepha> now im having a dfferent issue, on reboot, I cant login or change passwd, debug console works though, so I got a root terminal of sorts
[16:06] <mup> PR snapd#2041 closed: daemon: add `snap create-user --force-managed` support <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2041>
[16:18] <joc> zyga: it doesnt look like the command is being run
[16:19] <joc> zyga: it may be because there isnt an "add" event
[16:19] <joc> i don't see one if i use udevadm monitor
[16:25] <mup> PR snapd#2047 closed: snap: auto mount block devices and import assertions <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2047>
[16:25] <Croepha> ok, so after digging, it looks like core now uses pam_extrausers, so setting root passwd isn't going to be possible under this plan, and adding a user is adduser --extrausers ...
[16:34] <mup> PR snapd#2060 closed: many: change Connect to take ConnRef instead of strings <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2060>
[16:51] <modprobe__> What plug should I use to get access to /dev/{,u}random?
[17:08] <mup> PR snapcraft#824 closed: Add `snapcraft create-key` <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/824>
[17:18] <elopio> ogra_: are you around? There's a new snapcraft release in proposed.
[17:23] <sergiusens> marcoceppi or here if rocket is not possible :-)
[17:24] <zyga> pitti: hey
[17:25] <zyga> pitti: I'm trying to write an udev rule that will export a gpio by writing to /sys/class/gpio/export
[17:25] <zyga> pitti: the constraint is that after that I call "udevadm trigger"
[17:25] <zyga> pitti: is there anything sensible I can put into my rule to tie it into an event?
[17:26] <zyga> pitti: it should work both immediatly after "udevadm trigger" returns and on boot
[17:26] <zyga> joc: ^^
[17:26] <kyrofa> jdstrand, it doesn't look lik /dev/random (and similar) are contained in the default profiles. Are they not safe for access?
[17:26] <zyga> kyrofa: you can easily consume all entropy
[17:26] <kyrofa> jdstrand, though getrandom is available
[17:26] <zyga> kyrofa: and DOS other programs
[17:27] <kyrofa> zyga, ah, sure. Do we have an interface for such things, then?
[17:27] <jdstrand> kyrofa: they are safe and available in all profiles via the base abstraction
[17:27] <kyrofa> jdstrand, ah ha, okay
[17:27] <zyga> kyrofa: ah, jdstrand knows better :)
[17:27] <jdstrand> kyrofa: you may want to look at 'apparmor_parser -p /path/to/profile' to see all the policy with the abstractions
[17:27]  * kyrofa needs to read the base abstraction
[17:27] <zyga> jdstrand: so I _can_ write a heatdeathoftheuniverse snap?
[17:27] <kyrofa> Or that! Thanks jdstrand :)
[17:33] <mup> PR snapd#2053 closed: interfaces/policy: implement snap-id/publisher-id checks <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2053>
[17:34] <mup> PR snapd#2051 closed: many: setup snapd macaroon for local users <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2051>
[17:39] <joc> zyga: yep that is the question i was trying to ask, bad English on my part!
[17:39] <joc> zyga: i just tried by removeing the ACTION= altogether
[17:40] <joc> (can't spell now either)
[17:40] <joc> zyga: it made sure the gpio was always exported, but you couldnt unexport as the rule was always matched
[17:43] <zyga> jdstrand: hey, can you please upload .42 from yakkety to xenial, ara's team will do the valiation and work on SRU
[17:44] <zyga> jdstrand: the lack of "undo" is fine for now
[17:44] <jdstrand> ok
[17:45] <zyga> jdstrand: thanks
[17:47] <mup> PR snapd#2066 opened: many: abbreviated forms of disconnect <Created by zyga> <Conflict> <https://github.com/snapcore/snapd/pull/2066>
[17:54] <mup> PR snapd#2067 opened: cmd/snap: trivial auto-import and download tweaks <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2067>
[18:07] <elopio> kyrofa: sorry, you told me to test. I have this for you:
[18:07] <elopio> https://bugs.launchpad.net/snapcraft/+bug/1629955
[18:07] <elopio> https://bugs.launchpad.net/snapcraft/+bug/1629957
[18:07] <mup> Bug #1629955: rosdistro is not documented in the catkin plugin help <Snapcraft:Triaged> <https://launchpad.net/bugs/1629955>
[18:07] <mup> Bug #1629957: When I try to build a snap with the wrong catkin rosdistro, there is no good error <Snapcraft:Triaged> <https://launchpad.net/bugs/1629957>
[18:08] <kyrofa> elopio, ah, very good!
[18:08] <kyrofa> elopio, this is why I ask you to test ;)
[18:08] <kyrofa> Man, rosdistro has been around forever, I didn't even check the docs assuming they were good :P
[18:08] <kyrofa> elopio, blocking, you think? Or no?
[18:09] <elopio> sometimes I get depressed. No piece of software ever works for me on the first try. /o\
[18:09] <kyrofa> (I don't think these are new bugs)
[18:09] <elopio> kyrofa: no, medium and low. To fix when you have some time.
[18:09] <kyrofa> elopio, well good find, thank you!
[18:10] <kyrofa> elopio, you're QA. Finding bugs should make your day!
[18:10] <elopio> that's ok when I try to break it on purpose. Not so nice when I'm just trying to use things.
[18:12] <mup> PR snapd#1970 closed: interface/builtin: add ptrace support to system-trace <Created by niedbalski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1970>
[18:14] <mup> PR snapd#1945 closed: debian, tests: add trusty tests <Reviewed> <Created by vosst> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1945>
[18:29] <modprobe__> jdstrand, kyrofa: Does that mean /dev/urandom is available by default? It appears not to be working, though I don't know of an easy way to pop a shell in the sandbox to find out for sure.
[18:31] <modprobe__> As to consuming all available entropy, random has that issue, but not urandom, and I understand that urandom is regarded as every bit as good of a CSPRNG as random (better, since it should always work)
[18:35] <mup> PR snapd#2055 closed: interfaces/policy,overlord: check connection requests against the declarations in ifacestate <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2055>
[18:35] <mup> PR snapd#2062 closed: interfaces/policy: introduce InstallCandidate and its checks <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2062>
[18:39] <kyrofa> modprobe__, indeed, it should work
[18:42] <mup> PR snapd#2044 closed: snap: auto-import assertions from block devices <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2044>
[18:45] <modprobe__> kyrofa: Hmm... Well my program indicates pretty clearly that it doesn't. Botan throws an exception saying "System_RNG failed to open RNG device" and looking at its source, the only way that exception gets thrown is if opening /dev/urandom fails.
[18:47] <kyrofa> modprobe__, I'm not claiming you aren't running into issues, I'm just saying confinement shouldn't be causing it :) . Do you see apparmor denials in syslog (or from snappy-debug)?
[18:54] <modprobe__> kyrofa: Ahh yes, I see this in dmesg: audit: type=1400 audit(1475513126.687:37): apparmor="DENIED" operation="open" profile="snap.stakeweightedvoting.app" name="/dev/urandom" pid=6341 comm="VotingApp" requested_mask="w" denied_mask="w" fsuid=1000 ouid=0
[18:54] <kyrofa> modprobe__, it's trying to _write_ to it?
[18:54] <kyrofa> Indeed, the profile is only r
[18:55] <modprobe__> https://botan.randombit.net/doxygen/system__rng_8cpp_source.html (line 77) apparently, it is...
[18:55] <kyrofa> modprobe__, I can't imagine why... ?
[18:56] <modprobe__> Looks like a bug in botan.
[18:56] <kyrofa> Agreed
[19:05] <modprobe__> I'm reporting it to them. In the meantime, can you think of any workaround I can use until they release a fix?
[19:06] <kyrofa> modprobe__, would it be an easy patch?
[19:06] <modprobe__> Yeah, I could just use a custom build of botan...
[19:06] <kyrofa> modprobe__, yeah, that's what I'd recommend
[19:06] <modprobe__> Should literally just be changing that one line.
[19:06] <kyrofa> modprobe__, as a plus, you can propose it back upstream ;)
[19:09] <modprobe__> Yeah, I just made an issue on their github repo and I'll follow it up with a pull request soon, assuming it passes the smoke test. :)
[19:12] <elopio> cprov: I don't quite understand the sign-build --local. It always replies that "A signed build assertion for this snap already exists."
[19:14] <elopio> ah, I think that a previous command left the -build file. But it was empty.
[19:14] <elopio> I'll try to reproduce that.
[19:16] <sergiusens> elopio you only sign once per build
[19:19] <elopio> sergiusens: cprov: https://bugs.launchpad.net/snapcraft/+bug/1629984
[19:19] <mup> Bug #1629984: trying to sign-build without keys leaves a -build file, empty <Snapcraft:Triaged> <https://launchpad.net/bugs/1629984>
[19:21] <modprobe__> kyrofa: Apparently writing to random or urandom is a way to add entropy to the kernel pool. Maybe the AppArmor profile should be updated?
[19:21] <kyrofa> modprobe__, hmm interesting, jdstrand is the guy to consider that. Not sure what the ramifications would be
[19:22] <jdstrand> we'd need a new interface for that
[19:23] <jdstrand> I think. please file a bug
[19:24] <kyrofa> modprobe__, regardless, the fact that the thing dies if it can't add entropy still seems like a bug
[19:25] <mup> PR snapd#2059 closed: interfaces: add repo.ResolveConnect that handles name resolution <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2059>
[19:25] <modprobe__> kyrofa: Very true.
[19:25] <elopio> cprov: now without a body, I get: "no assertion found in request body". Tried on staging and production with a test user.
[19:26] <elopio> is that because my user is not allowed, or something?
[19:28] <modprobe__> jdstrand: Is that a bug on snapd?
[19:31] <kyrofa> modprobe__, indeed
[19:33] <modprobe__> Alright, I'll file that soon
[19:48] <cprov> elopio: thanks for filing the bug, the stray/empty -build should not be there.
[19:49] <elopio> np
[19:49] <elopio> ralsina: I'm getting this:
[19:49] <elopio> $ snapcraft validate u1test20161003 ubuntu-core=1
[19:49] <elopio> Getting details for u1test20161003
[19:49] <elopio> Snap 'u1test20161003' was not found in the 'stable' channel.
[19:49] <elopio> But I've just released the snap to stable on staging. Am I doing something wrong herE?
[19:51] <elopio> sergiusens: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1629472/comments/3
[19:51] <mup> Bug #1629472: [SRU] New stable micro release 2.19 <verification-needed> <snapcraft (Ubuntu):Fix Released> <snapcraft (Ubuntu Xenial):Fix Committed> <snapcraft (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1629472>
[19:51] <elopio> I'm going for lunch. I'm just missing the happy paths of gated and validate.
[19:52] <marcoceppi> sergiusens: o/
[19:53] <marcoceppi> sergiusens: I'm technically not working today, so I haven't been around my computer as much
[19:53] <cprov> elopio: ralsina is off today, can you run `snapcraft gated u1test20161003` ?
[19:54] <elopio> cprov: $ snapcraft gated u1test20161003
[19:54] <elopio> Name    Approved
[19:54] <elopio> prints nothing. I reported a bug about that, too.
[19:54] <elopio> https://bugs.launchpad.net/snapcraft/+bug/1629991
[19:54] <mup> Bug #1629991: snapcraft gated prints no message when there are no gated snaps <Snapcraft:New> <https://launchpad.net/bugs/1629991>
[19:59] <cprov> elopio: I can see your rev. 1 in stable, curl -s -H 'X-Ubuntu-Series: 16' https://search.apps.staging.ubuntu.com/api/v1/snaps/details/u1test20161003?channel=stable | jq-cprov.jq '.revision'
[20:00] <elopio> cprov: yes. But the message says it's not found.
[20:00] <cprov> elopio: can you try `snapcraft validate u1test20161003 ubuntu-core=1` again, so we can confirm it was hitting bad-caching in staging CPI
[20:00] <elopio> cprov: done. Same error.
[20:02] <cprov> elopio: okay, it will need some code changes as well, I've mentioned multiple time in the review that gating snap-id would be better resolved via the SCA account-info, somehow it slip and the code in trunk is using CPI. I will get into this asap
[20:02] <cprov> elopio: is it blocking snapcraft release ?
[20:03] <elopio> cprov: thanks. And I don't know if it should block it. It's ugly to release a command that doesn't work, but sergiusens can just not mention it in the release notes.
[20:03] <elopio> sergiusens: your call.
[20:04] <mup> PR snapd#2046 closed: cmd, disconnect: abbreviated forms of disconnect <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2046>
[20:06] <modprobe__> kyrofa, jdstrand: Bug report filed at https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1629996
[20:06] <mup> Bug #1629996: Cannot open /dev/random and /dev/urandom for write <snapd (Ubuntu):New> <https://launchpad.net/bugs/1629996>
[20:06] <sergiusens> cprov yeah, big branches can cause that ;-)
[20:06] <mup> PR snapd#1874 closed: snap: support assertion references in `snap prepare-image` <Reviewed> <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1874>
[20:06] <cprov> sergiusens: good point
[20:07] <mup> PR snapd#1767 closed: overlord, daemon: add collect attribute hooks <Reviewed> <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1767>
[20:09] <mup> PR snapd#1613 closed: interfaces/builtin: add dbus-app interface <Blocked> <Reviewed> <Created by jdstrand> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1613>
[20:10] <mup> PR snapd#2067 closed: cmd/snap: trivial auto-import and download tweaks <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2067>
[20:11] <lool> ogra_: thanks, description of the boot files is pretty slick
[20:11] <jgdx> what's the status on Ubuntu Core on RP3? Google returns a AskUbuntu link which is not super up to date
[20:11] <jgdx> ogra_, you know? ^
[20:12] <lool> ogra_: I was actually pinging because of the upcoming dragonboard 600 that you might have seen announced recently
[20:12] <lool> jgdx: pi ?
[20:12] <lool> jgdx: there's a beta image for rpi3 like for the other supported platforms: http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/
[20:14] <jgdx> lool, cool, thank you
[20:16] <mup> PR snapd#2068 opened: many: preparations for switching most of autoconnect to use the declarations <Created by pedronis> <Conflict> <https://github.com/snapcore/snapd/pull/2068>
[20:17] <lool> ogra_: the 600 doesn't have an u-boot port, so we can't follow the same path
[20:17] <lool> ogra_: and there's worth, there might be boards requiring UFS too; at which point we will need a much more complete u-boot
[20:17] <lool> *worse
[20:20] <elopio> cprov: sergiusens: also branches without staging integration tests ;)
[20:22] <cprov> elopio: yeah, it will definitely serve a lesson.
[20:53] <mup> PR snapd#2069 opened: overlord/auth: update CheckMacaroon to verify local snapd macaroons <Created by matiasb> <https://github.com/snapcore/snapd/pull/2069>
[20:56] <sergiusens> elopio cprov from the point of view of the project, it is already released, so not much we can do as soon as it lands on master
[20:57] <sergiusens> elopio I propose to you to do this testing now for history and status ;-)
[20:58] <jgdx> pi3 using that beta image gives me four berries, but nothing more
[21:18] <cprov> elopio: you have to set a new env var for staging UBUNTU_STORE_SEARCH_ROOT_URL='https://search.apps.staging.ubuntu.com/' to make validation work :-/
[21:19] <cprov> elopio: that's why you gating snap was not found.
[21:27] <mup> PR snapd#2069 closed: overlord/auth: update CheckMacaroon to verify local snapd macaroons <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2069>
[21:36] <mwhudson> niemeyer: hey, am i right to think that console-conf should not run if the device is managed?
[21:37] <mwhudson> niemeyer: there is a potential hole where if you use a autoload.assert file to add a user that only has ssh keys and no password and the default network config doesn't work for whatever reason you'll be stuck
[21:38] <mwhudson> the alternative is that console-conf still runs but only presents the network config screen, not the "please enter email" screen
[21:47] <mup> PR snapd#2070 opened: all: move from ubuntu-core to core by default, but still support ubuntu-core as core <Created by chipaca> <https://github.com/snapcore/snapd/pull/2070>
[21:50] <mup> PR snapcraft#847 opened: Implementing channel-closing <Created by cprov> <https://github.com/snapcore/snapcraft/pull/847>
[21:56] <kgunn> kyrofa: you about?
[21:56] <kyrofa> kgunn, I am, what's up?
[21:56] <kgunn> kyrofa: curious, what is the philosophy behind something becoming an official snapcraft part ?
[21:57] <kgunn> https://wiki.ubuntu.com/snapcraft/parts
[21:57] <kgunn> i had someone ask about qtmir and mirclient libs becoming "snapcraft parts"
[21:57] <kgunn> but unsure it makes sense
[21:57] <kgunn> as these are something that are currently in the archive and can easily be listed as a part
[21:58] <kgunn> in the yaml
[21:58] <kgunn> under a nil plugin
[21:58] <kyrofa> kgunn, anything that seems generally useful. If building qtmir for snappy takes a lot of weird config flags, for example, you could make it a part so other people could just say "build qtmir" instead of "ack, how do I build qtmir"
[21:58] <kgunn> kyrofa: hmm, yeah i don't think there's anything special there...
[21:59] <kgunn> definitely not weird
[21:59] <kyrofa> Yeah, if they can just use the archive packages then it's less useful. Still potentially useful from the point of view that it's less typing, but it's of limited usefulness, certainly
[21:59] <kyrofa> kgunn, nothing wrong with adding it, but don't feel obligated
[22:00] <kyrofa> kgunn, now, if you find yourself constantly asking "how do I get mir in a snap," then you could save yourself some time
[22:00] <kyrofa> Not asking, answering
[22:01] <sergiusens> cprov elopio fwiw, it is in the instructions and I was succesful gating and validating a bunch of snaps (even private ones iirc)
[22:01] <Pharaoh_Atem> zyga: this could be quite interesting for fedora's snappy stuff: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FUWLJQYQJAGNGSSFTCA3ZEHAX43LJ7UU/
[22:02] <kgunn> kyrofa: so it can be used as a template aswell ?
[22:02] <kgunn> i mean the mir-client snap is a template of sorts...but the qtmir and libmirclient are just pkg listings under parts
[22:03] <kgunn> the only thing of interest is the helper file
[22:03] <kgunn> that sets environ flags
[22:04] <kgunn> like  http://bazaar.launchpad.net/~mir-team/+junk/snapcraft-mir-client/view/head:/client-start
[22:09] <mwhudson> wheee funtimes https://github.com/snapcore/snapd/pull/2044#issuecomment-251241964
[22:09] <mup> PR snapd#2044: snap: auto-import assertions from block devices <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2044>
[22:43] <mup> Bug #1630036 opened: auto import of assertions fails for devices present at boot <Snappy:New> <https://launchpad.net/bugs/1630036>
[23:11] <jdstrand> zyga: fyi, filed bug #1630040
[23:11] <mup> Bug #1630040: [SRU] update to 1.0.42 <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):In Progress by zyga> <snap-confine (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1630040>
[23:12] <jdstrand> zyga: will upload in a bit