[05:28] <bso> Does anybody know how to upgrade snapd on Ubuntu Core 16.04.1?
[05:29] <bso> I just installed Ubuntu Core 16.04.1, and it installed snapd 2.16.
[05:29] <bso> I think the latest version of snapd is 2.25, but I don't know how to upgrade snapd on the Ubuntu Core system.
[05:45] <stub> bso: The latest version of snapcraft is 2.25. Latest snapd is 2.20
[05:46] <bso> @stub, oops, yes you are right. the latest snapd is 2.20.
[05:46] <nothal> bso: No such command!
[05:47] <bso> But, is there any way I can update snapd version on Ubuntu Core?
[05:47] <bso> On Ubuntu desktop, I can do "sudo apt install snapd".
[05:47] <bso> snapd itself is a part of core?
[05:48] <bso> The core version is already 16.04.1
[05:48] <stub> bso: snapd 2.20 is in xenial-updates, so you might need to enable that
[05:48] <stub> I'm not sure about Core - I'm working with desktop stuff
[05:50] <bso> @stub, could you elaborate how to enable xenial-updates?
[05:50] <nothal> bso: No such command!
[05:52] <stub> If you are running Ubuntu Desktop, top right icon and select 'system settings'.  Then 'Software and Updates'. Then the 'Updates' tab, which has a tick box for 'recommended updates'
[05:52] <bso> I am on Ubuntu Core, not Ubuntu Desktop.
[05:53] <stub> Yeah, I don't know Ubuntu Core sorry. Maybe editing /etc/apt/sources.list and following embedded comments, but I'm just guessing here.
[05:54] <stub> You might need to wait for more of Europe to come online before you get an answer
[05:54] <bso> @stub, Yup, I will wait for others to help me with Ubunto Core. Thanks.
[05:54] <nothal> bso: No such command!
[05:56] <nhaines> bso: we don't prefix nicknames with signs like @ or anything else in IRC.  That's more of a Twitter thing.
[05:56] <nhaines> Of course, most bots don't use @ as a command prefix, either.  Usually ! or sometimes #.
[05:57] <bso> nhaines, thanks for your advice. I am used to the @prefix habit. Sorry about that.
[05:58] <nhaines> bso: no worries.  Not a problem at all except for the bit where it keeps setting off the bot.  ;)
[07:49] <zyga> good morning
[08:02] <longsleep> mcphail: Afaik the Nextcloud snap contains a web server which has the configuration to transparently proxy requests to the spreedme snap.
[08:19] <mcphail> Hi longsleep. Unfortunately, I don't think it does. The only way I can see to get this working is to edit and recompile the nextcloud snap
[08:20] <mcphail> I've got an idea for a patch to allow the admin to switch it on and off, though
[09:24] <stub> I have a classic snap in the store that is published in stable and public, but not listed by 'snap find' and cannot be installed 'snap install --classic'. Name is 'wal-e', or wal-e.stub. What have I forgotten?
[09:25] <Chipaca> stub: to update snapd?
[09:25] <stub> I've got 2.20, and the machine was restarted fresh this morning
[09:25] <stub> And I can install the snaps from a local .snap, just not from the store
[09:26] <stub> Oh... juju-act is the same. Would the hypen be a problem?
[09:26] <Chipaca> stub: installing classic from the store is a 2.21 feature
[09:27] <stub> ok, that explains it then :)
[09:27] <Chipaca> :-)
[09:27] <Chipaca> stub: it's in -proposed afaik (but don't quote me on that :-) )
[09:28] <stub> I need to wait for 2.21 in xenial (and hopefully trusty), since this is for charms
[09:28]  * stub wonders if the snap-layer should be pulling in snapd from -proposed or a ppa
[10:31] <__chip__> mwhudson, o/
[10:32] <__chip__> mwhudson, is the go race detector expected to work in 1.7?
[11:06] <aisrael> Is it possible to install snappy on centos7?
[11:06] <ogra_> aisrael, https://github.com/snapcore/snapd/wiki/Distributions
[11:07] <ogra_> only fedora currently
[11:07] <aisrael> Thanks, ogra_!
[11:23] <blu2> So, what happens if I installed too many snaps and have a small SDD? Any way to put snaps on another disk?
[11:24] <__chip__> blu2, are you on classic, or is this a core system?
[11:26] <blu2> this was just a thought I had on core
[11:26] <blu2> because I'm 100% certain this will be a question in the future
[11:32] <ToeiRei> Hi guys.
[11:45] <__chip__> blu2, on core, there isn't currently a way of doing that
[11:45] <__chip__> ToeiRei, o/
[11:46] <blu2> __chip__: eventually?
[11:46] <__chip__> blu2, it isn't planned, but should be straightforward if the need arises
[11:46] <__chip__> there's nothing "special" about where snaps are stored
[11:47] <ToeiRei> is there a way to work with core in a headless way?
[11:48] <ToeiRei> because I'm in a bit of a dilemma
[11:48] <__chip__> ToeiRei, depends what you mean by headless
[11:49] <ToeiRei> __chip__, headless in terms of "no keyboard, no mouse, no screen"
[11:49] <ogra_> ToeiRei, currently a console is a requirement for the initial setup of the installed image (network data, user account)
[11:49] <__chip__> ToeiRei, serial?
[11:49] <ogra_> can be serial though
[11:49] <ToeiRei> I'm on a raspi 3 here with a remote user... who's tech skills are as good as the ones of a lipstick.
[11:52] <__chip__> ToeiRei, I'm not sure where to begin to help you with that
[11:52] <__chip__> ToeiRei, how did you get yourself into such a predicament?
[11:52] <ToeiRei> my spouse spilled coffee...
[11:53] <ToeiRei> so he went off for a new raspi and a new card and I'm sitting a few miles away
[11:55] <ToeiRei> now I got ssh onto my trusty ol' laptop...
[11:55] <ToeiRei> a card reader and some 'remote hands' with a *very* limited technical understanding
[11:57] <ToeiRei> __chip__, does that help?
[11:57] <ogra_> you either need a serial cable or a monitor/tv and keyboard ...
[11:57] <__chip__> ToeiRei, I'm not familiar enough with the pi to know: is it like the bbb where you plug it in and you have serial-over-usb, or do you need to jtag?
[11:58] <ToeiRei> wait a minute... you're about to tell me that I need to hook up a console to that thing for core?!?!?
[11:58] <ogra_> __chip__, you need an ftdi cable
[11:58] <__chip__> aww :-(
[11:58] <__chip__> ToeiRei, only if you need to set up a user and the network
[11:59] <ToeiRei> I mean... raspbian says 'do an empty file named ssh on /boot'
[11:59] <ogra_> (like you do on the BBB in case you want to access the bootloader)
[11:59] <__chip__> which is probably a 'yes' unless you're creating your own image
[12:00] <__chip__> ToeiRei, well, the alternative is to ship a default user and then have botnets take down the world
[12:00] <ToeiRei> __chip__, I like the 'ssh file' way of raspbian. Something like a bootloader param would have done the trick
[12:00] <ogra_> ... and none of the current reference images does that ...
[12:00] <ToeiRei> at least something
[12:01] <ogra_> ToeiRei, how would that help if the device is not configured for the network
[12:01] <ogra_> nor has any user account that could be used with ssh
[12:01] <ogra_> ssh is on by default on ubuntu-core
[12:01] <ToeiRei> dhcp does the trick
[12:01] <ogra_> just doesnt help without IP
[12:01] <ogra_> (or user)
[12:03] <ToeiRei> ogra_, I have a dhcpd running.
[12:03] <ToeiRei> in theory the sshd is running
[12:03] <ToeiRei> and I can read its key
[12:04] <ogra_> ToeiRei, well, that wont help you ... the image is set up in a way that you need to run a first boot setup wizard
[12:05] <ToeiRei> that's so braindamaged for embedded.
[12:06] <ogra_> you could create your own gadget snap and image to have a pre-created network config and user setup through cloud-init
[12:06] <ToeiRei> nothing to be done remotely I suspect
[12:07] <ogra_> the existing developer images have the firstboot setup as a req. simply because they are developer images :)
[12:08] <ogra_> on an actual embedded image that runs i.e. some kiosk app or just some datas collection you would likely not even have a user at all and have your data logging or kiosk app included
[12:08] <ogra_> (and manage themselves via browser or whatnot)
[12:08] <ToeiRei> I know why I usually do not run any flavor of ubuntu in my environment. once more confirmed.
[12:08] <ToeiRei> thanks
[12:09] <ogra_> regarding developer images we simply expect developers tp work with them
[12:09] <ogra_> *to
[12:09] <ogra_> which requires a login ...
[12:09] <ToeiRei> I don't even have spare monitors around due to laptops
[12:10] <ogra_> a TV will do ;)
[12:10] <ToeiRei> could you bring one over?
[12:10] <ogra_> heh
[12:11] <ToeiRei> I do not have any kind of an external monitor around
[12:11] <ToeiRei> not even a f* tv set
[12:11] <ogra_> well, then your only option is serial i fear ... which i'd expect an embedded developer to have around like i expect a carpenter to own a hammer
[12:12] <ogra_> (probably to high expectations)
[12:12] <ToeiRei> I just have no idea how to explain to my bf how to plug that in.
[12:12] <ogra_> http://elinux.org/RPi_Serial_Connection perhaps ?
[12:12] <ToeiRei> you need a pi hat for a serial connection afaik
[12:13] <ogra_> no
[12:13] <ogra_> you plug your FTDI serial cable directly into the headers on the board
[12:13] <ToeiRei> usually I use raspi boards as remote cpus for networking tasks... so I usually do not need serial cables at all.
[12:54] <om26er> elopio: Hello! around ?
[14:04] <larryprice> i have a snap (libertine.canonical) pending manual review in upload because it's using the 'desktop' property... can this be worked around, or alternatively can the upload be canceled so i can revert the 'desktop' change?
[14:13] <nickaww> Hi there, I'm trying to snap a game and I'm using the make plugin and artifacts keyword to copy all the files to the stage, but apparently wildcards are not supported on artifacts. How can I copy all the files without declaring every file and directory one by one?
[14:14] <ogra_> look at the dump or copy plugins
[14:15] <nickaww> yeah, I tried that, but dump/copy plugin can't access other parts
[14:15] <ogra_> does your makefile have an install target ?
[14:15] <ogra_> iirc that should just be used automagically
[14:16] <nickaww> It does. But it doesn't install as conventions and I need all the files from the project
[14:17] <ogra_> could you just add additional install lines ? like https://github.com/ogra1/nethack/blob/master/Makefile ?
[14:20] <nickaww> Do you mean add new install entries for every file in the project?
[14:21] <ogra_> no, for the whiole dirs
[14:21] <ogra_> see the "doc" line in the above makefile
[14:22] <ogra_> that puts the whole doc subdir into $DESTDIR
[14:29] <kalikiana> ogra_: Is there a particular reason the makefile does the downloading? As opposed to letting snapcraft do it?
[14:31] <nickaww> Well, I tried what you said about install directories. This is supposed to work, bot I will need to edit the Makefile every time I pull
[14:37] <elopio> om26er: hello. I am around now.
[14:37] <elopio> pachulo: pong. Where you looking for me? I was on vacations last week.
[14:38] <om26er> elopio: Hey! can you tell which script is responsible for upload of snapweb to edge channel once a change is merged into master ?
[14:39] <om26er> elopio: we need to run some tests every time a snapweb snap is published in edge.
[14:40] <elopio> om26er: https://github.com/snapcore/snapweb/blob/master/.travis.yml#L50
[14:42] <elopio> om26er: but if you have tests that need the edge package, my recommendation would be to just run them daily.
[14:49] <ogra_> kalikiana, you mean the wget ?
[14:50] <ogra_> kalikiana, a) that makefile predates the ability in snapcraft to do downloads itself ... b) if i would use a source: stanza it would try to use the upstream makefile and i couldnt do the patching or run the setup.sh script
[14:51] <ogra_> kalikiana, in this case the makefile is rather a better shellscript though
[14:57] <larryprice> jdstrand, thanks for taking a look at my mp friday evening - my snap is currently stuck pending manual review (due to the desktop property)... can that be worked around? i'll happily get a new version uploaded using the old setup/gui/*.desktop if you just want to cancel my pending uploads
[15:01] <jdstrand> larryprice: I can approve it. the upcoming snapcraft 2.26 will keep that out of the snap.yaml so eventually this won't be an issue
[15:01] <jdstrand> larryprice: I don't see it though. what is the snap name?
[15:02] <larryprice> jdstrand, libertine (libertine.canonical)
[15:02] <jdstrand> ah, ok. I've got it
[15:04] <jdstrand> larryprice: done
[15:04] <larryprice> jdstrand, thanks! we're also hoping to auto-alias the libertine-launch alias... not sure what the process is there
[15:05] <jdstrand> larryprice: can you paste your snapcraft.yaml?
[15:05] <jdstrand> larryprice: I can do it
[15:06] <larryprice> jdstrand, https://paste.ubuntu.com/23852309/
[15:07] <jdstrand> larryprice: updated the store:
[15:07] <jdstrand> [
[15:07] <jdstrand>   "libertine-launch",
[15:07] <jdstrand>   "libertine-container-manager",
[15:07] <jdstrand>   "libertine-manager-app"
[15:07] <jdstrand> ]
[15:08] <jdstrand> larryprice: note that r47 and r48 are approved but you need to release them
[15:09] <larryprice> jdstrand, ok cool - should i switch back to old-style desktop files in my uploads until 2.26 is released?
[15:10] <pachulo> welcome back elopio ! Yes, I wanted to talk with you about the help you offered me for writing tests for this: https://github.com/snapcore/snapcraft/pull/980
[15:10] <elopio> oh, that's you. Sorry for the late reply...
[15:11] <elopio> pachulo: a good way to start would be with some simple tests for the sources that don't support checksum
[15:11] <jdstrand> larryprice: probably best if you don't want to ping a store reviewer, yes. aiui, serguisens was planning a 2.26 update sooner than later. he doesn't seem to be here atm
[15:11] <jdstrand> kyrofa: do you know if 2.26 is coming out soon? ^
[15:11] <elopio> oh, but I see you already added those, nice!
[15:15] <rvr> zyga: ping
[15:16] <elopio> pachulo: next, I would write a few tests for "invalid checksum format". But I need to catch up with a few things before helping you write that code.
[15:19] <elopio> pachulo: I think those tests can live in snapcraft/tests/sources/test_checksum.py, because it's the same function you will be calling for all the different sources.
[15:22] <pachulo> ok elopio , I write down your tips and will try to implement the simplest ones
[15:23] <elopio> pachulo: and there are a few possible options. You can write a test that calls directly the verify_checksum function, with an invalid source_checksum paramter. Or you could fabricate a sources object, like you do on the tests for sources that can't have checksum like you did last week.
[15:24] <elopio> pachulo: I think I would prefer the second option, because it tests the verify function in a bigger context. But the other one is not wrong, also good.
[15:26] <elopio> pachulo: take a look at snapcraft/tests/test_tar.py, for example. From there you can get an idea of how to make a tar source object. Add an invalid checksum in there that will throw and exception, and you already know how to expect that exception in a test.
[15:26] <elopio> ping me in case of doubt.
[15:26] <elopio> oh, thanks a lot for working on this!
[15:27] <rvr> zyga: I'm trying to execute spread tests in Debian, and found some issues along the way. fgimenez tells me you have done it, is that correct?
[15:31] <pachulo> you're welcome elopio ! Just giving some of my time after years of sucking from FOSS!!
[15:36] <elopio> :D
[16:39] <rvr> Just opened an install issue with classic and Debian here https://github.com/snapcore/classic-snap/issues/7
[16:46] <kyrofa> mcphail, yeah, `occ upgrade` always disables them. I have no idea why
[16:47] <mcphail> kyrofa: yeah - spotted the bug on the tracker.
[16:48] <kyrofa> jdstrand, I know he was planning on releasing soon, but he's out sick today I'm afraid
[16:48] <mcphail> kyrofa: do you have plans for setting up apache config for spreed.me? I posted a bug about it
[16:53] <kyrofa> mcphail, I wasn't really planning on it. I'd have to test to make sure it continued working every release
[16:53] <kyrofa> And your proposal, while better than just having a proxy in there all the time, sounds a bit fragile
[16:55] <kyrofa> mcphail, I think I'd rather support it more like this: https://github.com/nextcloud/nextcloud-snap/issues/172
[16:57] <mcphail> Yes, a more robust method would be better. Not sure when one is going to arrive, though
[16:58] <zyga> jdstrand: hello
[16:59] <kyrofa> mcphail, indeed, which is why such things are in a bit of a holding pattern for the time being
[16:59] <zyga> jdstrand: when would be a good time to sit together and look at snap-alter-ns
[17:01] <kyrofa> mcphail, the challenge is that snaps can currently update from any revision to any other revision. Which means any temporary solution we come up with will have to have a migration path, and we'll have to maintain it forever
[17:02] <zyga> jdstrand: doesn't have to be today
[17:08] <stokachu> so i need a little help getting my systemd script to start
[17:09] <stokachu> http://paste.ubuntu.com/23852922/
[17:10] <stokachu> if i run the exec command directly then it all loads
[17:10] <stokachu> actually no it doesnt
[17:10] <stokachu> this command fails /usr/bin/snap run conjure-up.bridge
[17:10] <jdstrand> zyga: not today, but a) is the kernel issue addressed and b) what do we need to look at together?
[17:11] <stokachu> the ultimate goal is to just have the network interface and iptables rules persist through a reboot
[17:11] <stokachu> here my snap files https://github.com/conjure-up/conjure-up-snap
[17:12] <jdstrand> zyga: (not today cause I have a bunch of PR reviews to do that come in over the weekend/today
[17:12] <jdstrand> )
[17:12] <stokachu> the bridge file is pretty straight forward https://github.com/conjure-up/conjure-up-snap/blob/master/snapcraft/wrappers/bridge.start
[17:14] <stokachu> though im not sure what snap run conjure-up.bridge file is being run? is that the command-bridge.wrapper?
[17:17] <zyga> jdstrand: a) \o/ (great!) b) I think a hangout where I walk you through it and show what's missing would be more constructive
[17:17] <zyga> jdstrand: I wrote lots of unit tests but I still have some blank spots
[17:17] <zyga> jdstrand: and I need to write spread tests to actually see it work
[17:17] <jdstrand> zyga: re 'a', that was a question-- is it addressed?
[17:17] <zyga> jdstrand: ahhh
[17:17] <zyga> jdstrand: too bad :(
[17:18] <jdstrand> I mean, jjohansen may have found something, idk otoh, hence the question :)
[17:18] <zyga> jdstrand: no, no change there (I need to sped more time to investigate as what I'm seeing made no sense)
[17:18] <jdstrand> I think we should understand what is happening with the kernel as that may block the implementation
[17:18] <zyga> jdstrand: but I don't think it affects us in alter-ns as alter itself is not confined
[17:19] <zyga> jdstrand: I agree it would be good to get to the bottom of this
[17:19] <zyga> jdstrand: I was coding all day to get to the point where the bulk of the code is in place and not scary
[17:19] <zyga> jdstrand: I'll spend tomorrow landing bits upstream and checking what may be going on in the kernel
[17:19] <zyga> (and I still have to write snapd changes)
[17:22] <jdstrand> zyga: I was comfortable with the spec. if you want to do a PR and have me review, then I can decide if a hangout is needed
[17:24] <zyga> jdstrand: I made a tiny change compared to the spec (and left a todo entry to update the wiki so that it stands out)
[17:24] <zyga> jdstrand: it's not an error if a file is empty
[17:24] <zyga> jdstrand: (the fstab-like file)
[17:24] <zyga> jdstrand: we just carry on as if it were empty
[17:24] <zyga> jdstrand: otherwise the design checks out
[17:25] <zyga> er
[17:25] <zyga> jdstrand: it's not an error fi the fstab-like file is *not present*, we just treat it as if it were *empty*
[17:25] <zyga> (that's better)
[17:26] <Guest55973> can anyone help with ubuntu snaoppoy
[17:26] <Guest55973> ubuntu snappy
[17:26] <ogra_> depends :)
[17:27] <zyga> Guest55973: I think it's better to just ask your question :)
[17:27] <Guest55973> what is the default pswrd for first boot ssh connection
[17:27] <ogra_> there is none
[17:27] <ogra_> it uses your ssh key that you uploaded for your ubuntu one account
[17:27] <Guest55973> it said wrong passwrd
[17:28] <ogra_> yes, because there is no password, it is locked down ... only key authentication is allowed by default
[17:28] <Guest55973> i am putting ubuntu sso account username as both log in and pasword
[17:29] <ogra_> well, that wont work
[17:29] <ogra_> you need to have the secret ssh key for the public one that you uploaded to the SSO account on your local machine
[17:30] <ogra_> then you will not even be asked for a password
[17:32] <Guest55973> where do i have to enter that public key , ssh client or host? ?
[17:32] <Guest55973> host isn't responding to any command
[17:32] <ogra_> you dont have to enter it ... it gets downloaded from login.ubuntu.com when you run through the firstboot wizard
[17:33] <ogra_> i.e. the thing you get on fist boot after the "please press enter" message ...
[17:34] <ogra_> after setting up the network there it asks for your SSO account ... then it downloads the key from the SSO server and puts it in place on the machine
[17:34] <Guest55973> didn't get it, so first i'll enter my host ip then log in as sso user and for pssword ... blank?
[17:35] <ogra_> whats the hardware you are working on ?
[17:35] <Guest55973> rasp 3
[17:35] <ogra_> and what image did you use ? do you have the url you used for downloading it ?
[17:36] <Guest55973> ubuntu core pi 3
[17:36] <ogra_> from where ?  :)
[17:36]  * ogra_ wants to make sure you have the correct image before we move on
[17:36] <Guest55973> from the ubuntu.com
[17:37] <ogra_> http://releases.ubuntu.com/ubuntu-core/16/
[17:37] <ogra_> from there ?
[17:37] <Guest55973> yes that is correct
[17:37] <ogra_> ok
[17:37] <ogra_> so this image runs a first-boot wizard you need to complete first
[17:38] <ogra_> either via serial console or with a monitor and keyboard attached to the pi
[17:39] <Guest55973> i have successfully installed the to raspberry i had no problem until that login and password thing came up
[17:39] <ogra_> so you finished the wizard ?
[17:39] <Guest55973> yes
[17:39] <ogra_> it usually gives exact instructions for the ssh login
[17:40] <ogra_> there is no password and if everything worked you should also not be asked for one when you ssh in
[17:41] <Guest55973> as username@ipadress?
[17:41] <ogra_> well, whatever was written on your screen (it shoudl still be there if you attach a monitor)
[17:41] <ogra_> it prints the exact ssh command there
[17:41] <Guest55973> what about client ? i am using putty for remote access
[17:41] <ogra_> oh
[17:42] <ogra_> i'm not sure how you add your secret key in putty ...
[17:42] <ogra_> (the last time i used putty was 15y ago or so ... sorry )
[17:43] <ogra_> (i didnt mean to scare him away though :P )
[17:47] <zyga> ogra_: it's actually very very very hard :)
[17:47] <zyga> ogra_: because putty uses some odd format for the key
[17:47] <zyga> ogra_: so you need to convert them on command line with some unholly openssl command
[17:48] <zyga> ogra_: then once you have the key in both formats it's not that hard, just double-click on the key file (it has to have some extension specific to putty)
[17:48] <zyga> ogra_: then you get putty agent in the windows tray
[17:48] <zyga> ogra_: but I didn't do that for a long time either
[17:48] <zyga> ogra_: in case someone asks we should have an answer on the wiki (I bet lots of windows devs will come)
[17:48] <zyga> jamiebennett: ^^
[17:49] <ogra_> yeah, we need docs for this
[17:50] <zyga> mhall119: ^^ where could we put this
[17:51] <ogra_> https://help.ubuntu.com/community/SSH/OpenSSH/ConnectingTo
[17:52] <ogra_> sadly that doesnt have any info about that key thing you mentioned
[17:52] <larryprice> question about the d-bus interface... is it possible to connect to a snapped dbus interface from non-snap world, like just using dbus-send from the command line?
[17:53] <ogra_> oh my
[17:53] <ogra_> http://the.earth.li/~sgtatham/putty/0.60/htmldoc/Chapter8.html
[17:54] <ogra_> thats like a whole book !
[17:55] <ogra_> bah, and it doesnt talk about windows at all
[17:57] <zyga> larryprice: yes
[17:57] <zyga> larryprice: well, in theory :)
[17:57] <zyga> larryprice: I didn't check if you can actually do that (if the rules allow unconfined processes to have access)
[17:58] <zyga> larryprice: can you please find out and edit the wiki page at https://github.com/snapcore/snapd/wiki/Interfaces
[17:58] <larryprice> zyga, in that case, it may be that my daemon isn't started automatically (a different issue)
[17:58] <larryprice> zyga, sure - i'll pioneer this
[18:01] <ogra_> __chip__, are you incognito recently ?
[18:01] <__chip__> ogra_, i forgot to log off on the computer downstairs
[18:01] <ogra_> ah
[18:08] <zyga> larryprice: thank you
[18:08] <zyga> larryprice: feel free to create a sub-page (look at the content interface)
[18:08] <zyga> larryprice: thank you!
[18:49] <kyrofa> jdstrand, two questions: 1) do you see anything wrong with the logic in bug #1658774, and 2) would you update the review tools as a result, or does it not matter?
[18:50] <jdstrand> kyrofa: I have to step out right this second but will get back to you after I'm back
[18:50] <kyrofa> jdstrand, no rush, thank you :)
[18:54] <bso> Hi, does anybody know how to update snapd versions on Ubuntu Core?
[18:55] <bso> I installed Ubuntu Core 16.04.1 and it came with snapd 2.16, but I would like to update it to the latest version.
[18:59] <zyga> bso: it should happen automatically
[18:59] <zyga> bso: try "sudo snap refresh"
[19:00] <bso> zyga, it seems snapd is not a snap. I tried "sudo snap refresh", but it says everything is up to date.
[19:00] <bso> "snap list" does not list snapd as one of the snaps.
[19:01] <zyga> bso: that's correct, snapd is in the core snap
[19:01] <zyga> bso: hmm
[19:01] <zyga> bso: are you running snapd on classic ubuntu?
[19:01] <bso> My core snap version is 16.04.1
[19:01] <zyga> bso: or on ubuntu core image
[19:01] <bso> No Ubuntu Core 16.04.1
[19:02] <zyga> bso: can you tell me the output of "snap version" please
[19:02] <bso> 2.16
[19:03] <zyga> bso: is that the whole output?
[19:03] <zyga> bso: how id you get your image?
[19:04] <bso> Actually it has +<some additional string> after that. It is running an IoT device which is away from me at this moment.
[19:05] <larryprice> zyga, good news - it seems that i can easily access the dbus apps from the rest of an unconfined system
[19:06] <larryprice> zyga, however i'm having some trouble getting my simple daemon to auto-start on install... is there a good way to debug this?
[19:07] <zyga> larryprice: not sure, what are yo seeing?
[19:07] <zyga> *you
[19:07] <zyga> bso: can you please pastebin the whole output
[19:07] <zyga> bso: how did you obtain this image?
[19:08] <zyga> Chipaca: ^^ (2.16 doesn't update, maybe side-loaded, maybe something else?)
[19:09] <bso> zyga, I got it from https://developer.ubuntu.com/core/get-started/intel-joule
[19:09] <bso> There is link to the image on that page.
[19:09] <zyga> I see
[19:09] <zyga> jamiebennett: ^^
[19:10] <zyga> bso: so the core should update on its own, having said that 2.16 feels old (we are at 2.21 now) and I wonder if there is anything that would cause this to fail
[19:10] <zyga> bso: if you run "snap list" what does it say about the core snap?
[19:10] <zyga> bso: (or at that age, ubuntu-core)
[19:11] <bso> core is 16.04.1
[19:11] <larryprice> zyga, oho - looks like all the logs are going to syslog, i can visibly see the issue now
[19:11] <zyga> does it mention anything in the notes?
[19:11] <bso> I tried snap refresh core, but it says it is already up to date.
[19:12] <bso> I will have to get the Joule board to read that again, but it is away from me at this moment. sorry.
[19:13] <zyga> bso: thank you for reporting this, would you mind opening a bug on launchpad.net/snappy please?
[19:13] <bso> I would like to update it to 2.21, but it seems I can't find a way.
[19:14] <bso> zyga, sure I can do that soon. By the way, what is the usual way to update snapd on Ubuntu Core. Is it currently impossible?
[19:15] <bso> "sudo apt install snapd" does not work on Ubuntu Core.
[19:15] <zyga> bso: on core snapd updates automatically without human intervention
[19:16] <zyga> bso: as soon as you boot the system it will update itself
[19:16] <zyga> bso: (and everything else)
[19:16] <bso> I see. Then, something is broken since snapd is not updated automatically somehow.
[19:16] <bso> I will file a bug.
[19:17] <zyga> bso: thank you
[19:17] <zyga> ogra_: ^ do we generate up-to-date images for joule?
[19:21] <jamiebennett> zyga: these images are coming from tuchuck it seems
[19:21] <jamiebennett> Ideally we need them on cdimage
[19:23] <jamiebennett> zyga: I think we need to talk to the people who are producing them for an update i.e. CE
[19:23] <ogra_> jamiebennett, i have fresh ones from JohnAgosta ready ... gimme a bit
[19:24] <jamiebennett> ogra_: that is fine but we need a regular cadence for these not one-shots
[19:24] <ogra_> images that are built in a non standard way manually cant go on cdimage
[19:24]  * zyga agrees with jamiebennett 
[19:24] <ogra_> they usually go to http://people.canonical.com/~platform/snappy/
[19:24] <ogra_> jamiebennett, well, they are one shots ... they have a lot of manual changes
[19:25] <jamiebennett> ogra_: right but I would hate for them to go stale if we can help it
[19:25] <ogra_> and dont use the standard build systems
[19:25] <zyga> ogra_: what changes?
[19:25] <ogra_> zyga, talk to the CE team
[19:25] <jamiebennett> ogra_: can you kick off an internal mail to John and others to discuss Joule/Artik/NUC/... image production?
[19:25] <ogra_> for nuc we could merge them and they know we take their changes happily if they are includeable
[19:26] <ogra_> (i.e. for nuc you should noowadays take the generic amd64 images)
[19:26] <ogra_> jamiebennett, will do ... for now i'll release the jule image though :)
[19:26] <jamiebennett> ok
[19:29] <mhall119> zyga: what "this" do you want to put somewhere?
[19:30] <ogra_> bso, http://people.canonical.com/~platform/snappy/tuchuck/uc16-beta4/
[19:30] <ogra_> there is a new joule image
[19:30] <ogra_> *jule
[19:30] <bso> orga_, thanks for the link
[19:32] <zyga> mhall119: instruction on how to connect to a core device from windows using putty
[19:32] <zyga> mhall119: with putty agent, keys and what not
[19:32] <zyga> mhall119: it's not trivial
[19:33] <JohnAgosta> ogra_, thnaks
[19:33] <ogra_> np
[19:35] <JohnAgosta> jamiebennett, we got behind in posting updates for Joule.  This is now a refresh...the image does require a new BIOS flash to v174
[19:36] <ogra_> to late
[19:36] <ogra_> (he just dropped off)
[19:36] <JohnAgosta> ogra_, jamie is now offline but ^^ -- I am asking the marketing team to update the details on the website now
[19:37] <JohnAgosta> ogra_, for the NUC, it now uses the standard x86 images as we moved all requirements directly into the standard image
[19:39] <ogra_> JohnAgosta, yep, i know (i added a good bunch of the missing stuff that was missing) ;)
[19:39] <JohnAgosta> :)
[19:39] <stokachu> do we know when snapd 2.21 will make it out of proposed?
[19:39] <ogra_> we should look if we can do the same for the other arches
[19:39] <stokachu> need it for the --classic snap install
[19:39] <ogra_> i'll start a ML thread tomorrow morning and we can discuss
[19:44] <zyga> stokachu: soon (tm), not sure though
[19:44] <stokachu> zyga, also if the snap is in the store as classic do i still need to pass --classic during snap install?
[19:44] <stokachu> right now i do sudo snap install conjure-up --classic --edge
[19:44] <zyga> stokachu: yes
[19:44] <stokachu> ok
[19:44] <zyga> stokachu: you always need to pass --classic as this informs the user that all of confinement is off
[19:44] <stokachu> gotcha, makes sense
[19:53] <larryprice> zyga, any experience launching snapped d-bus services as daemons? currently i just get complaints in syslog about no DISPLAY being set...
[19:53] <mhall119> zyga: is connecting to Ubuntu Core different from connecting to classic Ubuntu?
[19:55] <mhall119> or is it just pubkey auth rather that password auth that makes it difficult?
[20:19] <zyga> larryprice: DISPLAY not set does not smell like a dbus service
[20:20] <zyga> larryprice: are you using the session or system bus?
[20:20] <zyga> larryprice: currently snappy doesn't support session services
[20:20] <larryprice> zyga, right i was just reading up on that (we've been using session bus)
[20:20] <zyga> mhall119: it is, because there's no password at all and you must use key auth
[20:20] <zyga> mhall119: unless you know exactly how to do that in putty on windows it's not easy to do
[20:21] <larryprice> zyga, the current alternative is to use system bus? or force users to launch the service manually in the bg for now, and switch over the daemon when the session stuff is ready
[20:23] <zyga> larryprice: no, that's not an alternative, if you *must* be on the session bus the system bus is useless
[20:23] <zyga> what are you trying to snap?
[20:23]  * zyga should EOD
[20:23] <zyga> it's late
[20:23] <larryprice> zyga, currently snapping libertine and its tools, i have full control of the source
[20:24] <larryprice> zyga, feel free to call it a day - thanks for all your help
[20:25] <zyga> yeah, I should rest
[20:25] <zyga> (in case anyone is interested) snap-alter-ns -- the thing that lets you alter a namespace as snaps execute (e.g. you can connect a content interface element to a running app) is here: https://github.com/snapcore/snapd/compare/master...zyga:snap-alter-ns-part1?expand=1
[20:26] <zyga> the commit message there lists remaining issues
[20:26] <zyga> but nothing major :)
[20:26] <zyga> jdstrand, tyhicks: ^^
[20:27] <zyga> (I'll make that a PR when a prerequisite is merged)
[20:28] <stokachu> when can we ditch telling people to use 'sudo snap install..' rather than just 'snap install'?
[20:28] <stokachu> to not use*
[20:29] <zyga> stokachu: you can sudo snap login
[20:29] <zyga> stokachu: then you can snap install AFAIK
[20:29] <stokachu> zyga, ah ok
[21:05] <azubieta> hello folks! I would like to implement an Snap Store! I was reading that it is a simple restful server, but which are the methods that i must implement in order to make it compatible with snapd?
[21:23] <jdstrand> zyga: ack, I'll add it to my list. there are quite a few other reviews that are queued before it so not today. likely tomorrow
[21:37] <jdstrand> kyrofa: I don't see anything wrong with your logic. there is no reason to include the symlinks since the libc libraries are already available to the snap
[21:38] <kyrofa> jdstrand, excellent, thanks for taking a look! Want me to apply it to the review tools as well so you can remove that special case? Or should we keep that in place?
[21:45] <jdstrand> kyrofa: I'll subscribe the bug and remove the special casing when it is released
[21:51] <kyrofa> jdstrand, alright
[22:09] <kyrofa> jdstrand, how do you keep track of all the bugs to which you're subscribed?
[22:10] <kyrofa> I can barely keep up with snapd and snapcraft-- you must have far more than that
[22:10] <kyrofa> I feel like I'm missing a trick
[22:11] <jdstrand> kyrofa: I have procmail rules that make directly subscribed bugs hit my inbox
[22:12] <jdstrand> and I know the feeling on that. I have a pretty big email queue to go through every day
[22:12] <kyrofa> jdstrand, and ones you get because you're a member of some group?
[22:12] <jdstrand> but them's the breaks on a busy project
[22:13] <jdstrand> kyrofa: depends on the group. all snappy bugs happen to also hit my inbox
[22:13] <jdstrand> that's a lot of bugs :)
[22:13] <kyrofa> No kidding
[22:14] <jdstrand> but I can't really see any other way to catch stuff
[22:14] <kyrofa> Indeed. So really your response is "I put on my boots and wade through it" ? :P
[22:14] <jdstrand> I obviously don't read every bug, but if it has something to do with the sandbox, interfaces, policy, review tools, etc, I read them
[22:15] <kyrofa> Fair enough. I just need to factor that into my day a bit more, then
[22:15] <jdstrand> eg, I don't read snapcraft bugs very closely, unless it has something to do with new yaml or something I'm personally interested in
[22:16] <jdstrand> ie, I read all the subjects
[22:16] <jdstrand> then decide
[22:17] <jdstrand> it's not terrible to wade through
[22:39] <kyrofa> mwhudson, any chance you could take a look at https://askubuntu.com/questions/875429/network-configuration-timed-out-in-ubuntu-core-16 ?
[23:01] <mcphail> kyrofa: got the optional switch for apache working in the nexcloud snap, but have found spreedme's config too opaque to be useful! Think I might abandon this plan for now ;)
[23:01] <kyrofa> mcphail, hahaha!
[23:01] <kyrofa> Well, thanks for taking a crack at it :)
[23:02] <mcphail> :)