[03:57] <waters33637_> how do i change the sshd port on snappy core?
[07:43] <Vamsi> Hi, is it possible to write snaps in a language other than python? I mean already read a page where the snaps can be written in Go. But is it possible to write in other languages?
[07:47] <kyrofa> Vamsi, oh certainly-- anything, really!
[07:48] <kyrofa> Vamsi, snapcraft has a number of plugins included by default, including cmake, autotools, and yes, python, go, and so on
[07:48] <kyrofa> Vamsi, run snapcraft list-plugins for more info
[07:50] <Vamsi> kyrofa: Thank you very much.
[07:53] <kyrofa> Vamsi, even if you want to do something that current plugins don't support, snapcraft supports using plugins in your actual tree as well. And you can always upstream them back to snapcraft, we're nice ;)
[07:55] <Vamsi> kyrofa: That's awesome. Just another question. Is it possible to work with snapcraft on an IDE for noobs like me who find it easier to write code there? :|
[08:08] <kyrofa> Vamsi, ugh, I lost my connection, sorry
[08:08] <kyrofa> Vamsi, not sure if my previous messages got through
 Vamsi, yes, although snapcraft is a bit of a meta build system, which doesn't make that fit quite perfect
 i.e. your snap could be made up of multiple parts
[08:40] <Vamsi> kyrofa: So when you say parts, does it mean that I develop it as a regular app on an IDE and then convert it to a snap?
[08:41] <renat> Hi guys! It's Renat from Screenly.
[08:41] <kyrofa> Hey renat, welcome!
[08:41] <kyrofa> It's been a while!
[08:41] <renat> Yup=)
[08:41] <kyrofa> How have you been?
[08:42] <renat> Fine, thanks=)
[08:42] <renat> I have a question about timezone control snap=)
[08:43] <renat> Hm. No. timezone control interface.
[08:44] <renat> Is it possible to include timezone control interface fix to 2.26.4 release? I investigated the timezone_control.go file on GitHub, but the fix is still not released in 2.26.4=(
[08:45] <renat> We need that fix desperately=)
[08:45] <kyrofa> renat, does time-control cover that?
[08:46] <renat> kyrofa, no, unfortunately.
[08:47] <kyrofa> renat, we'll need to talk to zyga and/or jdstrand, then
[08:48] <renat> kyrofa, thanks! I will write them, I think.
[08:48] <kyrofa> Alright. jdstrand will probably be around in a few hours, too
[09:54] <koza> ogra_, hey, fyi, fuses blown, can boot core now
[10:18] <mup> PR snapd#3521 closed: snap-seccomp: make sure snap-seccomp writes the bpf file atomically <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3521>
[11:09] <ogra_> kyrofa, https://forum.snapcraft.io/t/building-u-boot-gadget-snaps-a-series-of-blog-posts/821
[11:48] <Ulf> Hey there
[12:57] <mpt> Where should I report a bug on the results of “snap find”?
[13:04] <mup> PR snapd#3526 opened: hooks: support for refresh hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/3526>
[13:05] <mup> PR snapd#3527 opened: hooks: support for revert hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/3527>
[14:21] <xnox> How do i search for packages in the edge channel?
[14:21] <xnox> e.g. $ snap find --edge hello does not work
[14:22] <xnox> $ sudo snap find --edge hello
[14:22] <xnox> error: unknown flag `edge'
[14:22] <seb128> you don't
[14:26] <mup> PR snapd#3507 closed: many: backport of seccomp-bpf branch (#3431) to the 2.26 release <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3507>
[14:33] <Chipaca> xnox: find explicitly only searches published, stable snaps
[14:34] <kyrofa> pstolowski, done reviewing install/remove hooks, asked a few questions
[14:34] <xnox> seb128, Chipaca: so how does one discover edge channel packages?!
[14:34] <xnox> why does install accept --channel flag and find does not?
[14:34] <pstolowski> kyrofa, thanks!
[14:34] <kyrofa> xnox, by having admin store access and searching
[14:35] <Chipaca> xnox: non-stable snaps, you learn about them from the developer directly (or word of mouth)
[14:35] <xnox> o_O
[14:35] <Chipaca> xnox: or, if you already know about a snap and would like to try its beta (or edge), snap info will tell you
[14:36] <xnox> i find it weird, that i can call info on something, and install, which find does not find.
[14:37] <Chipaca> xnox: I'm ok with you finding it weird
[14:37] <Chipaca> xnox: :-D
[14:37] <xnox> it feels like not having +r permission on ones home directory
[14:38] <seb128> xnox, it's not only you don't worry :-)
[14:38] <Chipaca> xnox: it's more like apt not telling you about things from debian experimental
[14:38] <seb128> it does
[14:38] <Chipaca> seb128: not unless you do a lot of work for it to do so
[14:38] <seb128> if you added the corresponding source
[14:38] <xnox> Chipaca, they are findable with apt search, but not installed by default with apt install unless e.g. /experimental is given.
[14:38] <seb128> lot of work?
[14:38] <Chipaca> when i did it last at least, yes
[14:39] <xnox> Chipaca, e.g. on ubuntu backports are enabled by default; are searchable; do show up in the results; are not installed by default unless e.g. /xenial-backports is specified.
[14:39] <xnox> Chipaca, and that seems normal to me. What was your bug with apt?
[14:39] <seb128> xnox, that seems what one would expect as a behaviour :-)
[14:40] <Chipaca> xnox: I never said I had a bug with apt?
[14:41] <xnox> Chipaca, "xnox: it's more like apt not telling you about things from debian experimental" but it does...
[14:41] <Chipaca> xnox: it doesn't unless you do more work, was more my point
[14:41] <Chipaca> xnox: in any case I think you understand what I mean and are just being argumentative at this point
[14:42] <Chipaca> if on the other hand you didn't understand what I meant, I'll try harder
[14:43] <xnox> commented on https://bugs.launchpad.net/snappy/+bug/1662962 and marked myself as affected.
[14:43] <mup> Bug #1662962: 'snap find' does not allow channel specification <Snappy:New> <https://launchpad.net/bugs/1662962>
[14:44] <xnox> Chipaca, on ubuntu, with apt, we have repositories that can be enabled/disabled and can be installable by default, or not.
[14:44] <Chipaca> xnox: yes, snapd does not support that
[14:45] <Chipaca> xnox: i'd forgotten about that bug, where the current behaviour is explained or rationalised rather well
[14:45] <xnox> Chipaca, on ubuntu we enable by default: security, updates, and backports. However, we by default only install from security and updates. backports are visible in ~= info / find, and work with install with extra flags.
[14:45] <xnox> Very similar to snapd channels, which are possible to use with flags, for channels, for commands info/install, but not find.
[14:46] <xnox> Chipaca, the last comment says that if there are more people affected the --channels/--beta/et.al. should be supported in the find command.
[14:46] <xnox> (from mark that is)
[14:47] <Chipaca> s/should/could/
[14:48] <Chipaca> xnox: if you can "snap install --edge --devmode foo", would you expect "snap find --edge --devmode" to find foo?
[14:49] <ogra_> slangasek, i noticed you started building daily ubuntu-core images on cdimage, i'd like to shut down my builds, but can you please fix the naming of the dargonboard ones ? theere are different versions of dragonboards and we only support the 410c, linaro/96boards asked me to make that clear in our images when i started building the ones in http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ ... would be great if the ones on
[14:49] <ogra_> cdimage could use the same naming scheme
[14:51] <xnox> Chipaca, yes. Not sure what "--devmode" does. For me there is a package one can install with --edge, and query with info, but not possible to "snap find --edge foo"
[14:51] <Chipaca> xnox: devmode snaps are not confined
[14:51] <xnox> because --channel= --beta --edge --candidate --stable flags do not exist on the find subcommand.
[14:52] <xnox> Chipaca, ok so --devmode does not affect channel selection (e.g. devmode is not a subchannel of edge)
[14:52] <xnox> so should be irrelevant here.
[14:53] <Chipaca> xnox: as i see it, it hinges on that if the developer hasn't put it in stable, it means they don't think it's suitable for general use
[14:54] <xnox> Chipaca, then why is there install --edge and why does info show it by default?
[14:54] <xnox> Chipaca, imho all command should default to show info from stable channel only.
[14:55] <xnox> And all commands should be able to show other channels. If there is need to operate on other channels for the `info` and `install` so should also `find`
[14:56] <Chipaca> xnox: i think the difference is that find is about promoting/suggesting you use stuff, as opposed to info which is about telling you all we know about stuff
[14:56] <xnox> Chipaca, please tell me this is not an ACL / security feature
[14:56] <xnox> that one cannot "find" edge channel data....
[14:57] <Chipaca> xnox: exactly how stupid do you think we are? :-/
[14:58] <xnox> given lack of --channel= flag on find command, my bar is set low =))))))))))))))))
[14:58] <Chipaca> xnox: so you disagree with some design decisions, you immediately assume we're incompetent?
[14:58] <xnox> Chipaca, please note i'm fairly new to using snap on regular basis. I have built a snap, and do use it. But I'm fairly unfamiliar with all the ins and outs.
[15:00] <xnox> Chipaca, artificially limiting user's ability to view _information_, imho, is censorship =) and nothing else. Especially since viewing the information should be harmless.
[15:01] <xnox> I would understand ACLs were e.g. publisher alone can find packages, which are authenticated search results, before a package is made public.
[15:01] <xnox> but not able to find packages, in all channels, is still perplexing to me.
[15:02] <Chipaca> xnox: snap find --private is the only-find-private-packages bit
[15:03] <kyrofa> xnox, I think the idea is that there could potentially be all sorts of crap in edge etc. that could be totally useless and not ready for use. Showing such results when searching for a snap to use could be considered noise
[15:03] <Chipaca> xnox: and the lack of channel flags rationale is, I _think_ (but haven't checked) is from before sections support, so maybe it's time to rehash the discussion
[15:03] <Chipaca> there _is_ all sorts of crap in edge
[15:03] <Chipaca> :-)
[15:03] <xnox> sure, there is crap, i'm not asking for it to be show by default
[15:03] <kyrofa> Totally useless and not ready for use == my redundancy of the day
[15:04] <kyrofa> Ah, right, you just want find --channel
[15:04] <xnox> kyrofa, snap find crap -> should return nothing; snap find --edge crap => should return all the crap =)
[15:04] <kyrofa> Sure, gotcha. I agree, that would be useful
[15:04] <xnox> kyrofa, please mark yourself as affected on https://bugs.launchpad.net/snappy/+bug/1662962
[15:04] <mup> Bug #1662962: 'snap find' does not allow channel specification <Snappy:New> <https://launchpad.net/bugs/1662962>
[15:06] <kyrofa> I've embarrassingly forgotten the names of my own snaps in non-stable channels. Had to login to the dashboard to jog my memory
[15:06] <Chipaca> kyrofa: snapcraft list-registered
[15:06] <Chipaca> :-D
[15:07] <kyrofa> Chipaca, you know about features in my own project that I didn't know about. This is a bad situation
[15:07] <kyrofa> But that still seems like a workaround
[15:07] <Chipaca> dude, i'm not the one that needs convincing
[15:07] <kyrofa> Haha, I know!
[15:09] <mup> PR snapd#3528 opened: Use RFC3339 time format for refresh times <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/3528>
[15:11] <mup> Bug #1651597 opened: no bug reporting method <Snappy:Confirmed> <https://launchpad.net/bugs/1651597>
[15:16] <kyrofa> JamieBennett, https://forum.snapcraft.io/t/dropping-grade-from-the-template-produced-by-snapcraft-init/783 FYI
[15:19] <Chipaca> Pharaoh_Atem: https://en.wikipedia.org/wiki/Rocca_Calascio
[15:37] <cjwatson> mpt: https://bugs.launchpad.net/snapstore
[15:41] <mup> Bug #1651597 changed: no bug reporting method <Snappy:Fix Released> <https://launchpad.net/bugs/1651597>
[15:41] <mup> Bug #1700560 opened: “snap find” returns confusing results <Snappy:New> <Snap Store:New> <https://launchpad.net/bugs/1700560>
[15:52] <Chipaca> I want to publicly thank kyrofa for offering to work without complaining on all the random snapcraft work we're throwing at him
[15:52]  * Chipaca waits for kyrofa to follow his "always accept praise" rule
[15:52] <kyrofa> Chipaca, haha, so far none of the tasks I've agreed to are assigned to me!
[15:53]  * kyrofa accepts praise
[15:53] <Chipaca> kyrofa: this can be fixed
[15:57] <Chipaca> robert_ancell: should i be waiting for another commit on snapd#3528?
[15:57] <mup> PR snapd#3528: Use RFC3339 time format for refresh times <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/3528>
[15:57] <robert_ancell> Chipaca, Was called into a discussion, still working on it
[15:57] <Chipaca> robert_ancell: tsk tsk
[15:58] <mup> PR snapd#3529 opened: interfaces: allow snaps to use the timedatectl utility  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3529>
[16:18] <slangasek> ogra_: can you file a bug (or do a merge) against ubuntu-cdimage for the dragonboard rename so there's a paper trail?
[16:18] <ogra_> slangasek, will do
[16:32] <mup> PR snapd#3530 opened: cmd/snap: include snap type in notes <Created by chipaca> <https://github.com/snapcore/snapd/pull/3530>
[16:34] <seb128> hum, my test vm crashed while I was installing libreoffice snap
[16:34] <seb128> I rebooted and now it says "snap libreoffice has changes in progress"
[16:35] <seb128> what does that mean and how can I get out of it?
[16:35] <seb128> remove says it's not installed
[16:35] <seb128> installed gives that message I don't understandf
[16:38] <pstolowski> seb128, what does 'snap changes' say? try 'snap abort <changeid>; any errors reported by journalctl
[16:38] <pstolowski> ?
[16:40] <seb128> pstolowski, seems it's installed now
[16:40] <seb128> so I guess it resumed installing it in bg
[16:40] <seb128> and "changes in progress" is a way to say that which was just not undertandable to me
[16:41] <kyrofa> seb128, welcome to transactional package operations!
[16:42] <kyrofa> Not the not-understandable part, but the fact that it didn't end up in a weird state. Nice huh?
[16:42] <seb128> yeah, would be nice if it as telling you what it's doing
[16:42] <seb128> rather than throwing a weird error that make you want to nuke the install
[16:42] <seb128> :-)
[16:43] <seb128> I was close from trashing the vm and redoing a fresh ubuntu install
[16:43] <seb128> since I had no clue how to get out of the situation
[16:45] <pstolowski> perhaps the message should give a hint about 'snap changes'
[16:57] <coreycb> hi all, the keystone snap was blocked on upload to the snap store due to an interface issue which i've since been able to drop. but i think it's still blocked.  can someone take a look?
[16:59] <coreycb> also the nova snap appears to have the same issue.
[17:06] <seb128> give an hint about snap changes would be one option
[17:06] <seb128> another would be to explain what's going on
[17:06] <seb128> like that it's being installed and that waiting is enough
[17:45] <neozero> hi. first time snap user on Ubuntu 16.04. '$ sudo snap install wekan' went fine, but '$ wekan.help => cannot mount /snap/wekan/2/$SNAP_DATA/share at /snap/wekan/2/$SNAP_DATA/shared with options bind. errmsg: No such file or directory
[19:29] <mup> PR snapd#3531 opened: interfaces: updates default, mir, optical-observe, system-observe, screen-inhibit-control and unity7 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3531>
[20:36] <jdstrand> roadmr: hi! would you mind updating the tools to r887?
[20:36] <jdstrand> ogra_: fyi, that has your new kernel and two gadgets ^ (prevous revisions had the other one)
[20:53] <roadmr> jdstrand: sure thing, coming up
[20:55] <neozero> anything I should be looking at for this simple case of Ubuntu 16.04 $ snap install wekan => $ wekan.help => cannot mount /snap/wekan/2/$SNAP_DATA/share at /snap/wekan/2/$SNAP_DATA/shared with options bind. errmsg: No such file or directory
[21:29] <jdstrand> roadmr: thanks. I forgot to mention no rush
[21:32] <roadmr> jdstrand: np, I'll need to hold the merge until tomorrow but should deploy shortly after
[21:32] <roadmr> (but it's already prepared - just waiting for me to pull the trigger)
[22:05] <jdstrand> roadmr: cool, thanks