[06:13] <Tcab> Can i package a wxpython based app as a snap?
[06:27] <mup> PR snapd#2635 closed: SNAPD_DEBUG is a boolean (we use GetenvBool() for it) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2635>
[07:12] <mup> PR snapd#2397 closed: interfaces: add iio <Created by lpotter> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2397>
[07:15] <mup> PR snapd#2529 closed: interfaces: mm: permissions for protocol proxies <Created by alfonsosanchezbeato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2529>
[08:03] <zyga> tyhicks: woot, I just read the thead about complain mode for seccomp
[08:03] <zyga> nice :)
[08:08] <Tcab> Can i package a wxpython based app using snap?
[08:16] <zyga> Tcab: hey
[08:16] <zyga> Tcab: it should be doable, just enough massaging to fit all of the bits in /snap
[08:18] <eduardas_m> hello, is this an appropriate place to write feedback on Ubuntu Core tutorials that are on ubuntu.com?
[08:27] <zyga> eduardas_m: I would also recommend https://rocket.ubuntu.com/channel/snapcraft or the snapcraft mailing list
[08:29] <eduardas_m> zyga, I do not know if this is appropriate, but I filed my minor gripe with documentation here: https://github.com/ubuntu/codelabs/issues/17
[08:29] <eduardas_m> Because that is where the "Did you find a mistake? Please file a bug." link directs me to from the tutorials page
[08:32] <zyga> AlbertA: hey, I'd like to discuss https://github.com/snapcore/snapd/pull/2256/files
[08:32] <zyga> AlbertA: can you please ping me when you have the chance
[08:37] <Tcab> Ok thanks
[08:39] <Tcab> Would be great if there  was a simple examp,e / template for a wxpython app.  It could thenbe used by many others
[08:40] <Tcab> Wxpthon probably means compiling wxpython ? As part of the build process?
[08:47] <mup> PR snapd#2648 closed: cmd/snap-confine: use flags rather than magic bool constants <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2648>
[09:09] <mup> PR snapd#2650 opened: also include system-shutdown helper in snapd.install <Created by chipaca> <https://github.com/snapcore/snapd/pull/2650>
[09:51] <mup> PR snapd#2600 closed: tests: remove the snapd dirs last (should fix random test errors) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2600>
[10:27] <Person1> Join
[10:38] <mup> PR snapd#2651 opened: interfaces,overlord/ifacestate: small refactor around reference methods <Created by zyga> <https://github.com/snapcore/snapd/pull/2651>
[11:26] <tito_> Hi all
[11:26] <tito_> pedronis: thanks for the yesterday's link to the integration tests
[11:27] <tito_> man. that was a trip...
[11:27] <tito_> I used systemctl edit snapd.service to inject http_proxy for snapd daemon
[11:28] <tito_> it occured that this file, has to contain Service section before the Environment declarations
[11:28] <tito_> I've lost some time on it :) maybe it is worth to mention in a official documentations?
[11:29] <tito_> anyway, here is how /etc/systemd/system/snapd.service.d/override.conf should look like:
[11:30] <tito_> cat /etc/systemd/system/snapd.service.d/override.conf
[11:30] <tito_> [Service]
[11:30] <tito_> Environment=HTTPS_PROXY=bla:port
[11:30] <tito_> Environment=HTTP_PROXY=bla:port
[11:30] <tito_> Environment=http_proxy=bla:port
[11:30] <tito_> Environment=https_proxy=bla:port
[11:31] <tito_> without the [Service] section , does not work.
[11:35] <mup> PR snapd#2256 closed: overlord/ifacestate: fix missing security setup for connected slot <Created by albaguirre> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2256>
[12:11] <mup> PR snapd#2651 closed: interfaces,overlord/ifacestate: small refactor around reference methods <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2651>
[12:14] <mup> PR snapd#2328 closed: Add download manager interface <Created by Elleo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2328>
[12:14] <mup> PR snapd#2652 opened: overlord/ifacestate: setup security of snaps affected by auto-connection <Created by zyga> <https://github.com/snapcore/snapd/pull/2652>
[12:16] <mup> PR snapd#2653 opened: tests: skip i18n test when no "snappy.mo" file is available <Created by mvo5> <https://github.com/snapcore/snapd/pull/2653>
[12:21] <morphis> ogra_: where is the right location of our reference gadget snaps these days? I see https://docs.ubuntu.com/core/en/reference/gadget#examples-of-production-ready-gagdet-snaps pointing to launchpad but I also see them on github.com/snapcore
[12:24] <ogra_> morphis, https://github.com/snapcore/pi3-gadget and https://github.com/snapcore/pi2-gadget
[12:24] <ogra_> updating the latter atm)
[12:24] <morphis> ogra_: then documentation really needs to be updated
[12:24] <ogra_> yeah
[12:24] <morphis> otherwise we're pointing people to old stuff :-)
[12:25] <ogra_> who owns that nowadays ?
[12:25] <ogra_> davidcalle, ^^^ is that still your area ?
[12:27] <morphis> ogra_: I guess you can just do a PR against https://github.com/CanonicalLtd/ubuntu-core-docs or file a bug there
[12:33] <davidcalle> @ogra_  yes, PR is fine :)
[12:33] <nothal> davidcalle: No such command!
[12:34] <davidcalle> ogra_: please have a look at other links you find in the gadget area, in case there is more to update
[12:34] <ogra_> will do
[12:34] <davidcalle> Thanks
[12:51] <eduardas_m> hello, is the image ubuntu-core-16-amd64.img outdated when it comes to snapcraft tutorials in any way?
[12:51] <morphis> eduardas_m: where do you have it from?
[12:52] <eduardas_m> morphis, http://releases.ubuntu.com/ubuntu-core/16/ubuntu-core-16-amd64.img.xz
[12:52] <eduardas_m> I believe I am using this one
[12:53] <morphis> eduardas_m: should be ok
[12:54] <morphis> eduardas_m: worth running $ snap refresh inside to get the latest updates
[12:55] <eduardas_m> the thing is I am trying to follow the snapcraft tutorials word by word... and I found something that works differently
[12:56] <morphis> eduardas_m: what is it?
[12:56] <eduardas_m> this might be nitpicking, but I do not get the snap build failure described in https://tutorials.ubuntu.com/tutorial/create-first-snap#3
[12:56] <eduardas_m> bash installs on first go without adding configflags: ["--infodir=/var/bash/info"]
[12:57] <eduardas_m> so I thought either the tutorials are outdated or the image is
[12:58] <eduardas_m> checked the sources of both GNU hello and bash
[12:58] <eduardas_m> both use the same directory for infodir
[12:58] <eduardas_m> but no conflict described in tutorial
[13:00] <longsleep> Quick snapcraft question, which package sources are used for stage-packages - is it the /etc/apt/sources.list.. from the system where snapcraft is run?
[13:02] <zyga> jdstrand: comments changed as requested, thank you for the capabilities angle, I didn't consider this https://github.com/snapcore/snapd/pull/2630
[13:02] <mup> PR snapd#2630: many: detect potentially insecure use of snap-confine <Created by zyga> <https://github.com/snapcore/snapd/pull/2630>
[13:03] <mup> PR snapd#2654 opened: i18n: look into core snaps when checking for translations <Created by mvo5> <https://github.com/snapcore/snapd/pull/2654>
[13:05] <eduardas_m> if possible, I would like an explanation: Ubuntu Core is for headless systems only or a GUI on a TFT LCD can be added for handheld device?
[13:06] <eduardas_m> are there pre-build snaps that enable X server + desktop on Ubuntu Core or somehing similar?
[13:11] <stokachu> longsleep, yea its from your hosts sources.list
[13:11] <longsleep> stokachu: ok great thanks!
[13:12] <stokachu> i'd prefer it had its own sources though so i could stage packages from zesty et
[13:12] <stokachu> etc*
[13:12] <stokachu> longsleep, np
[13:14] <mup> Bug #1616629 changed: could not unmarshal state entry "snap-type" <Snappy:Invalid> <https://launchpad.net/bugs/1616629>
[13:14] <mup> PR snapd#2230 opened: Add an interface that allows clients to use media-hub over dbus <Decaying> <Created by jhodapp> <https://github.com/snapcore/snapd/pull/2230>
[13:48] <mup> PR snapd#2448 closed: interfaces,snap: account for trusty-specifics in interfaces <Created by vosst> <Closed by vosst> <https://github.com/snapcore/snapd/pull/2448>
[14:05] <mup> PR snapd#2653 closed: tests: skip i18n test when no "snappy.mo" file is available <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2653>
[14:09] <mup> PR snapd#2575 closed: cmd: move snap-discard-ns to dedicated directory <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2575>
[14:11] <mup> Bug #1649934 changed: USB Auto-mount for assertion import fails <Snappy:Invalid by awe> <https://launchpad.net/bugs/1649934>
[14:20] <tyhicks> zyga: I should be done with version 2 of the seccomp patches this week so everything is still looking good
[14:25] <zyga> tyhicks: will you also work on snap-confine changes?
[14:25] <zyga> tyhicks: do you know if those patches will find their way back to the xenial kernel?
[14:25] <tyhicks> zyga: yeah, I should be able to do the snap-confine changes
[14:25] <tyhicks> zyga: I'll be backporting the kernel and libseccomp changes all the way back to xenial
[14:26] <zyga> tyhicks: and trusty I assume
[14:26] <tyhicks> zyga: ah, right... libseccomp changes will go back to trusty
[14:36] <mup> PR snapd#2542 closed: many: use snap-confine to save cost of repackaging core snap for testing <Created by zyga> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2542>
[14:38] <mup> PR snapd#2528 closed: tests: speed up update_core_snap_with_snap_exec_snapctl <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2528>
[14:45] <mhall119> jdstrand: is the new 'dbus' interface in snapd 2.20?
[14:46] <mhall119> and is it provided by ubuntu-core, or only core?
[14:46] <jdstrand> mhall119: yes: https://github.com/snapcore/snapd/wiki/Interfaces#dbus
[14:47] <jdstrand> mhall119: I don't know the status of ubuntu-core vs core. it is in snapd 2.20. snap --version on an ubuntu-core system should tell you what it has
[14:47] <jdstrand> I think they are in sync again, but I don't know when that happened
[14:47] <mhall119> jdstrand: I have 2.20.1ubuntu1, but "snap interfaces" doesn't show dbus
[14:48] <jdstrand> mhall119: no, it won't because it isn't an implicit slot. it is for providing snaps to use
[14:48] <mhall119> popey: can you run "snap interfaces" and see if you have "dbus"? IIRC you switched from ubuntu-core to core
[14:48] <mhall119> oh, nvm popey
[14:48] <jdstrand> it won't be there
[14:49] <jdstrand> install corebird-diddledan or ktuberling
[14:49] <mhall119> I have ktuberling
[14:49] <mhall119> ktuberling
[14:49] <mhall119> Qt: Session management error: None of the authentication protocols specified are supported
[14:49] <mhall119> "Couldn't register name 'org.kde.ktuberling-19990' with DBUS - another process owns it already!"
[14:49] <jdstrand> mhall119: refresh it
[14:49] <mhall119> it's brand new from upstream
[14:49] <jdstrand> mhall119: this morning it was approved
[14:50] <jdstrand> mhall119: like, less than 1 hour ago
[14:50] <mhall119> jdstrand: I got it from KDE's build servers directly
[14:50] <jdstrand> I have no idea what they have. I can tell you that what is in the store is implementing the dbus interface
[14:51] <mhall119> jdstrand: which store channel?
[14:51] <jdstrand> edge r5
[14:51]  * diddledan pricks his ears up
[14:52] <jdstrand> mhall119: also, 'another process owns it already' suggests that you have multiple ktuberlings running that are allowed to use the interface
[14:52] <jdstrand> so I think it is working as expected
[14:53] <mhall119> I don't have other instances of ktuberling running
[14:53] <mhall119> I suspect it takes a failure to secure the dbus service name as an indication of another being there
[14:53] <jdstrand> I don't know why it would say what it is saying then
[14:53] <jdstrand> perhaps something in the backgoround>? </guess.
[14:53] <jdstrand> >
[14:53] <mhall119> is there a way to list dbus session services?
[14:54] <jdstrand> install d-feet
[14:54] <jdstrand> there are other commands, but I don't know the invocation otoh
[14:55] <jdstrand> regardless, if you install r5 from the store then do 'snap interfaces' you should see an interface called ktuberling:session-dbus-interface
[14:57] <mhall119> jdstrand: yup, and I can confirm that the versions in the store do in fact work and it secures the dbus name, so it's something wrong with the new builds, sorry to bother you
[14:57] <jdstrand> np
[14:57] <Chipaca> youtube believes this is relevant to my interests: https://www.youtube.com/watch?v=vPBM0g9usMs
[14:57] <Chipaca> (it isn't *wrong*, per se)
[14:57] <jdstrand> mhall119: what is the name of the content snap?
[14:58] <mhall119> kde-frameworks-5
[14:58] <jdstrand> mhall119: it doesn't seem to be installed when I do 'snap install ktuberling --edge' fwiw
[14:58] <jdstrand> ah, in --edge
[14:58] <mhall119> IIRC, snapd doesn't auto-install needed content snaps yet
[15:00] <jdstrand> mhall119: ok, after installing, connecting the content snap and doing 'sudo /usr/lib/snapd/snap-discard-ns ktuberling' I can confirm that 2.20.1ubuntu1 works as advertised
[15:01] <jdstrand> that isn't surprising; ktuberling was one of the test snaps for the interface :)
[15:01] <mhall119> jdstrand: right, I just unpacked the one from their build server and it doesn't have the dbus session interface in snap.yaml, I'll work with them to fix it
[15:02] <jdstrand> cool
[15:04] <AlbertA> zyga: ping
[15:08] <ogra_> tedg_ or mterry, coudl one of you trigger a rebuild of the unity8-session snap ? theer were mir fixes in the overlay PPA that should make it work on the pi, i'd like to try them
[15:08] <mterry> ogra_: you got it
[15:16] <Kaleo> sergiusens, not sure if I'm asking the right person but here it goes: what's the difference between the ubuntu-core snap and the core snap?
[15:16] <mup> PR snapd#2639 closed: snap: add {Plug,Slot}Info.SecurityTags <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2639>
[15:16] <ogra_> Kaleo, one has ubuntu- in the name
[15:16] <Kaleo> sergiusens, installing a local snap with classic confinement if you don't have the core snap installed (but the ubuntu-core snap instead): should it work?
[15:16] <Kaleo> ogra_, :)
[15:16] <sergiusens> Kaleo, ubuntu-core is deprecated and the snapd team is working on a migration path away from it
[15:16] <ogra_> (they are identical )
[15:17] <Kaleo> ogra_, ah ok
[15:17] <ogra_> but snapcraft requires the core one for classic builds i think
[15:17] <Kaleo> sergiusens, oh sweet, so will people eventually get core installed automatically?
[15:17] <ogra_> (it checks for the name)
[15:17] <ogra_> thats the plan
[15:17] <sergiusens> Kaleo, new installs already do, people with older installs will transition
[15:18] <Kaleo> sergiusens, sweet; I guess I'll follow https://bugs.launchpad.net/snappy/+bug/1655599
[15:18] <mup> Bug #1655599: No migration of ubuntu-core to core <Snappy:New> <https://launchpad.net/bugs/1655599>
[15:19] <Kaleo> sergiusens, ok and so, installing a local snap with classic confinement if you don't have the core snap installed (but the ubuntu-core snap instead): should it work?
[15:20] <sergiusens> Kaleo, it won't
[15:20] <sergiusens> Kaleo, if you are not invested in snaps yet apt remove --purge snapd
[15:20] <sergiusens> if not, wait
[15:23] <mup> PR snapd#2655 opened: cmd: switch to non-recursive make <Created by zyga> <https://github.com/snapcore/snapd/pull/2655>
[15:25] <Kaleo> sergiusens, I did not understand what you meant with being invested
[15:25] <Kaleo> sergiusens, thanks for the answers
[15:25] <sergiusens> Kaleo, using snaps a lot, as puring snapd makes you lose all your snap data
[15:25] <Kaleo> sergiusens, ah yes
[15:25] <Kaleo> sergiusens, ok
[15:31] <ogra_> mterry, doesnt feel like it ... i just end up with a black screen (mir-kiosk at least gives me a cursor and turned on backlight on black screen, unity8 doesnt, backlight of the monitor goes off, no cursor)
[15:33] <ogra_> http://paste.ubuntu.com/23822572/ is the unity8 log
[15:34] <ogra_> looks like it misses the gallium driver
[15:35] <ogra_> sadly i need to re-flash the SD so i cant test further ...
[15:46] <mterry> ogra_: well all I did was rebuild it after you mentioned -- does https://launchpad.net/~unity-team/+snap/unity8-session-silo/+build/17398 have the versions of packages that you expect?
[15:49] <ogra_> mterry, i guess it does ... but i think we are missing a mesa driver that kgunn provides in his mir-kiosk snap
[15:50] <ogra_> i cant imagine mesa-kms or mesa-x11 to work on a pi
[15:51] <mterry> hmm, if you know of a package we ought to include, I can add it.  But drivers seem low-level for the unity8 snap, long term.  Maybe we're including them now as a stop-gap tho
[15:55] <ogra_> mterry, well, i'm not sure what mir-kiosk includes that you dont ... else i'D simply tell you :)
[15:55] <mterry> ogra_: sure  :)   I'll make a note to ask kgunn for his snapcraft.yaml
[16:25] <ogra_> mterry, hmm, it might actually be something different, i see the snap ships its own cgmanager service and tried to start it ... which clashes with the system cgmanager that is already running
[16:26] <mterry> ogra_: oh is that provided by a different snap now?
[16:26]  * ogra_ sees complaints in the logs
[16:26] <mterry> that was just to get us going
[16:26] <ogra_> mterry, it is provided by the OS on the ubuntu-core pi2/3 images
[16:27] <ogra_> though that shouldnt be any different to the ubuntu-core kvm images ...
[16:27] <ogra_> perhaps its a red herring
[16:27] <ogra_> i only noticed it complaining in the logs
[16:27] <mterry> sure, but that's a good bit of cleanup we can do regardless
[16:28] <ogra_> not sure if snaps actually have access to it though ... when not running in --devmode
[16:28] <mterry> ah no interface yet
[16:28] <ogra_> yep
[16:28] <mup> PR snapd#2545 closed: overlord: allow max 500 changes in "ready" state to avoid growing changes for 24h <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2545>
[16:49] <mup> PR snapd#2656 opened: spread: refresh apt cache before first install <Created by zyga> <https://github.com/snapcore/snapd/pull/2656>
[16:50] <mup> PR snapd#2657 opened: snapmgr, ifacemr: add automatic ubuntu-core -> core transition <Created by mvo5> <https://github.com/snapcore/snapd/pull/2657>
[17:14] <roadmr> hello folks. I want to build a classic-confinement snap. How do I set the "core_dynamic_linker"?
[17:18] <kyrofa> roadmr, you need the core snap
[17:18] <roadmr> kyrofa: AH
[17:18] <roadmr> kyrofa: thanks :)
[17:18] <kyrofa> roadmr, dreadfully unhelpful error, we know-- it's fixed in the next release
[17:19] <roadmr> kyrofa: yes, I just found it by grepping around on snapcraft's source :) installing core now... yay
[17:22] <mup> PR snapd#2656 closed: spread: refresh apt cache before first install <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2656>
[17:24] <roadmr> kyrofa: can't install core while ubuntu-core is installed, but can't remove ubuntu-core :(
[17:25] <kyrofa> roadmr, indeed-- you have to purge remove snapd I'm afraid. The snapd team are working on a migration to make that bette
[17:25] <kyrofa> r
[17:26] <zyga> kyrofa: mvo just proposed a pull request for this
[17:26] <kyrofa> zyga, nice!
[17:26] <zyga> kyrofa: it will be likely fixed next week
[17:26] <zyga> (next release)
[17:26] <kyrofa> zyga, thanks for the heads up
[17:27] <roadmr> kyrofa: /o\ not ideal :) but it'll do. Purging!
[17:32] <roadmr> kyrofa: my shiny classic snap is ready :) thanks!
[17:37] <kyrofa> roadmr, any time, sorry for the inconvenience!
[17:45] <kalikiana> ogra_: Thanks for your comment on bug 1576282. Could you perhaps try to summarize exactly how data behaves? I might not have my details right. My assumption was, that snaps are compressed, but at one point they will be uncompressed in memory or possibly swap space - so eventually 3.5M becoming 35M, or 5M becoming 125M if we wanted more locales, would still weigh down on the system
[17:45] <mup> Bug #1576282: Snaps built from deb can't be gettext translated <personal> <snap-desktop-issue> <Canonical System Image:In Progress by kalikiana> <Snapcraft:New>
[17:45] <mup> <Ubuntu App Platform:In Progress by tpeeters> <snapcraft (Ubuntu):Confirmed for sergiusens> <unity8 (Ubuntu):Confirmed> <https://launchpad.net/bugs/1576282>
[17:46] <ogra_> kalikiana, they are just loop mounted as-is ... run "mount" on your pc ;)
[17:46] <kyrofa> zyga, this question could use you: https://askubuntu.com/questions/872991/trying-to-install-via-snap?noredirect=1#comment1355694_872991
[17:47] <kalikiana> ogra_: Well, surely apps have to access them uncompressed since they're not aware of the filesystem details?
[17:47] <ogra_> kalikiana, indeed if you copy anything out of the snap into a common dir or the user dir it gets uncompressed
[17:47] <zyga> kyrofa: looking
[17:47] <kalikiana> Maybe I'm just thinking about it the wrong way
[17:48] <ogra_> kalikiana, they are uncompressed on the fly when accessed ... any only the bits that go into ram
[17:48] <ogra_> by the kernels squashfs driver
[17:48] <ogra_> that is how we fit a 2GB filesystem onto a 600MB CD since years already ;)
[17:48] <kalikiana> ogra_: Hmmmm so maybe I should look at the data, locales in the particular case, that the app actively uses, to see what memory it will require?
[17:49] <ogra_> there is a loop mount and the inodes are exposed (so you have file references) on access data is decompressed on the fly
[17:49] <kalikiana> Right, I know the disc can be smaller, but those CDs usually require a lot of memory
[17:50] <ogra_> well, but not 2GB ... it is really only what is actively open that occupies RAM
[17:50] <ogra_> for your locales only the files in use will be in ram
[17:50] <ogra_> but they wont need any diskspace or have to be uncompressed anywhere
[17:50] <ogra_> thats the beauty of squashfs
[17:52] <ogra_> you can safley measure a snaps size by its actual size ... only if you have any scripts that unpack stuff to a userdata dir or into the common dir your snap will occupy more
[17:52] <kalikiana> I guess I'm used to thinking worst case. But indeed the memory of a single locale would be small if all strings were loaded
[17:52] <ogra_> yeah
[17:52] <ogra_> and the unudes locales just sit in the compressed snap
[17:53] <ogra_> if adding locales adds 3.5MB thats about it ... it wont grow in any way
[17:54] <ogra_> this is why the ubuntu-core image effectively only occupies ~150MB for everything even though it would be closer to 500 if you actually unpacked all the files
[17:54] <kalikiana> Maybe we can get all locales in then - I was making a snap with only the subset used on the phone as the original data is quite big
[17:57] <ogra_> ogra@localhost:~$ sudo du -hcs /snap/core/922
[17:57] <ogra_> 186M	/snap/core/922
[17:57] <ogra_> 186M	total
[17:57] <ogra_> ogra@localhost:~$ df -h | grep core/922
[17:57] <ogra_> that might give you an impression ;)
[17:57] <ogra_> err
[17:58] <ogra_> ogra@localhost:~$ df -h | grep core/922
[17:58] <ogra_> /dev/loop3       65M   65M     0 100% /snap/core/922
[17:58] <ogra_> better :)
[17:58] <ogra_> effectively it only occupies 65M ... even though the content is actually 3x the size
[17:58] <popey> Anyone seen a snap fail to run with accessing /run/user/1000/snap.<snapname>  ?
[17:58] <popey> http://paste.ubuntu.com/23823245/  getting that, maybe jdstrand knows? :)
[17:58] <popey> it's installed in devmode
[17:59] <jdstrand> popey: "No such file or directory"
[17:59] <jdstrand> popey: mkdir -p /run/user/1000/snap.servo
[17:59] <jdstrand> there is a bug on that. let me find it
[18:00] <popey> make the dir as part of the launcher?
[18:00] <jdstrand> as a workaround for the bug, yes
[18:00] <popey> that'll do for now, thanks
[18:00] <popey> I guess I should parameterise it? $UID or whatever for 1000 ?
[18:01] <kalikiana> ogra_: Impressive indeed. Thanks for enlightening me
[18:02] <jdstrand> popey: https://bugs.launchpad.net/snappy/+bug/1656340
[18:02] <mup> Bug #1656340: XDG_RUNTIME_DIR is not created on app startup <Snappy:Confirmed for zyga> <https://launchpad.net/bugs/1656340>
[18:03] <jdstrand> popey: no, XDG_RUNTIME_DIR is correctly set. just do 'mkdir $XDG_RUNTIME_DIR'
[18:03] <popey> jdstrand: thanks
[18:04] <jdstrand> popey: there is an alternative way to do it in comment #1
[18:04] <popey> will subscribe to bug and workaround for now.
[18:09] <kyleN> Ihow do I determine the key associated with my "brand", where I created my sso account a long time account. (myapps.developer.ubuntu.com lists my Account-Id but I am not sure which (if any) key that is associated with.
[18:10] <kyleN> a long time AGO (I meant)
[18:13] <kyleN> none of my local snap keys (snapcraft list-keys) have the same fingerprint as the Account_id listed in the store.
[18:16] <Chipaca> pedronis, is the relation between account id and keys documented anywhere?
[18:28] <mup> Bug #1657552 opened: [spread] install-sideload:reexec0 failure <Snappy:New> <https://launchpad.net/bugs/1657552>
[18:34] <pedronis> kyleN: are you logged in as that SSO account ?
[18:42] <zyga> jjohansen: hey, in case you are around, I had a look at the new kernel and I've collected some data (attached to the bug) but perhaps it would be better if you had a look and told me what to look for
[18:42] <zyga> jjohansen: it seems that the failure I get is different than before
[18:42] <zyga> jjohansen: (before == stock kernel)
[18:42] <zyga> jjohansen: in any case, I will be around for a few more moments, please ping me with instructions if you can
[18:43] <jjohansen> zyga: yep, just getting in, I will have a look at it
[18:43] <zyga> oh hi :)
[18:43] <zyga> great
[18:43] <kyleN> pedronis, yes
[18:46] <pedronis> kyleN: snapcraft can get for the store enabled keys that are not local, but doesn't have a way to print them afaik atm
[18:46] <pedronis> s/for the store/from the store/
[18:47] <kyleN> pedronis, ok. I'll keep looking around. thanks
[18:49] <mup> PR snapcraft#1024 closed: gradle plugin: update gradle plugin to support both gradle and gradlew <Created by ZenHarbinger> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1024>
[18:56] <pedronis> kyleN: this might print relevant info:  python3 -c "import snapcraft.storeapi; print(snapcraft.storeapi.StoreClient().get_account_information().get('account_keys'))"
[19:00] <sergiusens> stgraber, have you seen LP: #1657252 ?
[19:00] <mup> Bug #1657252: lxd no longer works with 2.21 <snapd:New for zyga> <https://launchpad.net/bugs/1657252>
[19:01] <stgraber> sergiusens: I believe I commented in it
[19:01] <sergiusens> ah, sorry, you have
[19:01] <sergiusens> I didn't refresh!
[19:04] <kyrofa> jdstrand, just so I'm clear, the serial port interface attributes you mentioned here does not currently exist? https://bugs.launchpad.net/snappy/+bug/1645445/comments/2
[19:04] <mup> Bug #1645445: Turtlebot needs /dev/kobuki <snapd-interface> <Snappy:Confirmed> <https://launchpad.net/bugs/1645445>
[19:14] <sergiusens> jdstrand, is there a way to manually connect?
[19:27] <mup> PR snapd#2652 closed: overlord/ifacestate: setup security of snaps affected by auto-connection <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2652>
[19:35] <jdstrand> sergiusens: is snap connect not working for you?
[19:36] <jdstrand> kyrofa: they all exist. see https://github.com/snapcore/snapd/wiki/Interfaces#serial-port. note this is slot side in the gadget snap
[19:41] <kyrofa> jdstrand, ah excellent, I misunderstood then
[19:52] <mup> PR snapcraft#1055 opened: store: proper error colors for login failures <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1055>
[19:52] <jdstrand> sergiusens: I responded in the bug
[20:05] <mup> PR snapd#2655 closed: cmd: switch to non-recursive make <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2655>
[20:15] <mup> PR snapd#2658 opened: cmd: add mount / unmount helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2658>
[20:17] <zyga> jdstrand: ^^ I'd like to use those helpers for snap-alter-ns
[20:17] <zyga> jdstrand: essentially mount/umount with loggin
[20:17] <zyga> logging*
[20:17] <mup> PR snapd#2659 opened: tests: fix path used when debugging <Created by zyga> <https://github.com/snapcore/snapd/pull/2659>
[20:18] <pedronis> jdstrand: about the lxd bug, it seems not even network is autoconnected, that is weird
[20:18] <zyga> jdstrand: https://github.com/snapcore/snapd/pull/2643/files is the stub snap-alter-ns (does nothing), I'd like to land it to focus subsequent reviews on what matters
[20:18] <mup> PR snapd#2643: many: add stub implementation of snap-alter-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/2643>
[20:18] <zyga> pedronis: could it be a locally built lxd without assertions?
[20:19] <pedronis> zyga: no, from the store, also as I said, seems even network is not autoconnected
[20:19] <jdstrand> zyga: I'm focused on several other things atm. I will add this to my list. won't be today
[20:19] <pedronis> zyga: there's more new info in the bug
[20:20] <zyga> jdstrand: ack
[20:20] <zyga> pedronis: checking
[20:21] <zyga> hmm
[20:22] <zyga> we have real tests for auto-connection, I wonder if they are not that real or is there something else at play
[20:23]  * zyga needs a break
[20:23] <zyga> ttyl
[20:30] <jdstrand> pedronis: it is weird indeed
[20:49] <mup> PR snapcraft#1056 opened: schema: print allowed length for length failures <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1056>
[21:25] <stokachu> im having some issues getting a systemd script to start, hitting this error, http://paste.ubuntu.com/23824282/, my snapcraft is setting up a oneshot service so that some iptables rules get set on reboot/boot https://github.com/conjure-up/conjure-up-snap/blob/master/snapcraft.yaml
[21:25] <stokachu> this is a classic snap and these start/stop scripts are used in our debian packaging without an issue
[21:27] <stokachu> if i run the commands that are generated in the systemd file they work
[21:28] <stokachu> how do i force install the snap even though the start snap "conjure-up" services fail?
[21:28] <stokachu> i also dont see the generated systemd file inside my prime directory
[21:30] <kyrofa> stokachu, yeah, snapd does the systemd bits, not snapcraft
[21:31] <kyrofa> stokachu, I'd refer you to one of them, but they're all EOD by now
[21:31] <stokachu> so the service file is like ExecStart=/usr/bin/snap run conjure-up.service
[21:31] <stokachu> if you run that directly it works
[21:31] <stokachu> ah ok
[21:32] <kyrofa> stokachu, when you install the snap, snapd interrocates the meta/snap.yaml file to determine what services it contains, as well as their properties, then generates systemd unit files for them
[21:33] <stokachu> ah i see the snap.yaml
[21:33] <stokachu> kyrofa, so can i add some debugging to these command wrappers that are generated in the prime directory and rebuild?
[21:34] <kyrofa> stokachu, of course
[21:34] <stokachu> ok cool lemme dig into those files
[21:34] <kyrofa> stokachu, though if you mess with snapcraft's auto-generated stuff, don't just run `snapcraft` again (as it'll regenerate those files over the top of your changes)
[21:34] <stokachu> ah
[21:34] <kyrofa> stokachu, instead you can run `snapcraft snap prime` to just tell snapcraft "make a snap out of this directory"
[21:35] <stokachu> kyrofa, gotcha, thanks
[21:45] <stokachu> so another issue i noticed is my aliases doesn't seem to be working
[21:45] <stokachu> where i have 'conjure-up.juju' i wouldn't thought that aliases would've given me just 'juju' as the executable
[21:45] <stokachu> would've*
[21:45] <pedronis> stokachu: did you enable them?
[21:46] <stokachu> pedronis, if it's a setting then no i didnt
[21:46] <pedronis> stokachu: they are just an hint, the admin needs to use "snap alias" to enable them
[21:47] <stokachu> pedronis, how can i automate that?
[21:47] <pedronis> later there will be ways to ask for them to auto enabled them but it's a shared namespace so not everything foes
[21:47] <stokachu> ah ok
[21:47] <pedronis> s/foes/goes
[21:47] <stokachu> makes sense
[21:47] <sergiusens> pedronis, it already works, lxd is using it
[21:47] <stokachu> that's where i got the example from
[21:47] <sergiusens> the problem with juju is the colision with the actual juju snap
[21:47] <stokachu> i assume that's enabled on the backend
[21:47] <sergiusens> yes
[21:47] <sergiusens> someone like jdstrand would do it
[21:47] <stokachu> so i can just leave it at conjure-up.juju
[21:48] <stokachu> no biggie and it makes sense as im not the upstream of juju
[21:48] <pedronis> sergiusens: yes, the tech bits are there, the processes aren't
[21:48] <sergiusens> but for juju it seems it might be a bit more complicated. Why do you nee juju aliased instead of just calling juju; the juju in your snap should have precedence to anything external
[21:48] <pedronis> stokachu: yes, the idea here is that usually aliases will got to upstreams (afaiu)
[21:48] <stokachu> it is called juju but it ends up being conjure-up.juju
[21:49] <stokachu> pedronis, ack
[21:49] <stokachu> sergiusens, fwiw i dont need it aliased
[21:49] <stokachu> i just saw it in lxd and wanted to be like the cool kids
[21:49] <stokachu> sergiusens, now if i could just get my systemd stuff to work i'd be in good shape
[21:51] <stokachu> also i have a snapcraft and a snap directory, can i consolidate and just put my snapcraft/{setup,wrappers} in the snap directory?
[21:56] <sergiusens> stokachu, as soon as I get a PR in, should be doable in snapcraft 2.26
[21:56] <stokachu> sergiusens, thanks
[21:56] <stokachu> sergiusens, im running from master anyway
[22:04] <sergiusens> stokachu, I'll get to you as soon as those are migrated.
[22:07] <mup> PR snapcraft#1053 closed: meta: ensure snap.yaml is desktop free <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1053>
[22:32] <sergiusens> balloons, hey, on https://github.com/juju/juju/blob/master/snapcraft.yaml#L16 why don't you do `source: .`?
[22:32] <sergiusens> no need to double checkout if not, and would be interested in a bug if this was tried and did not work :-)
[22:50] <diddledan> heads'-up I've just released corebird 1.4.1 (corebird-diddledan) :-)
[22:51] <wililupy> kyrofa: The snap builds. I'm tweaking my wrapper script for the service to start, but I keep getting permission denied errors and no extra details as to why it is denied. The library paths are 755 so I'm not sure what to check next....
[22:57] <zyga> wililupy: dmesg | grep DENIED
[23:03] <wililupy> zyga: doesn't return anything
[23:03] <zyga> wililupy: okay, good
[23:04] <zyga> wililupy: can you tell me more about your snap and the service, where does the error occur, what is the actual precise message
[23:04] <wililupy> sure.
[23:05] <wililupy> My snap runs a service through a wrapper script to pass the correct paths to the configs and PID locations, but when it tries to load libraries, it gets Permission Denied Errors in the /var/log/syslog
[23:05] <zyga> how does it load libraries?
[23:05] <zyga> where are the libraries it wants to load
[23:06] <mup> PR snapd#2659 closed: tests: fix path used when debugging <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2659>
[23:06] <wililupy> I tried adding the export LD_LIBRARY_PATH= to the wrapper which fixed the first missing library error I was getting.
[23:06] <zyga> jjohansen: hey, I'm about to go to bead
[23:06] <zyga> bed*
[23:07] <zyga> jjohansen: anything I can do tomorrow to help you out?
[23:07] <wililupy> They are located in $SNAP/usr/lib and $SNAP/usr/lib/x86_64-linux-gnu
[23:07] <zyga> so far so good
[23:07] <zyga> is this a snap with classic confinement?
[23:08] <wililupy> I added the other two paths, but get a permission denied for $SNAP/usr/lib and $SNAP/usr/lib/x86_64-linux-gnu and it says it can't find a shared library in that path.
[23:08] <wililupy> No, it using devmode.
[23:08] <zyga> wililupy: are you aware of the snap execution environment differences, the chroot and other bits?
[23:08] <wililupy> my next step if I couldn't get it to work in devmode was classic and install these libraries in /usr/lib...
[23:08] <zyga> wililupy: did you try snap run --shell yousnap
[23:09] <zyga> wililupy: and explore how the filsystem look like
[23:09] <zyga> wililupy: don't add classic to the mix unless running in classic is your goal, I think it will be significantly easier this way
[23:09] <zyga> wililupy: classic confinement is not without a grain of salt and complexity of its own
[23:10] <wililupy> zyga: I'll try the snap run command to see what happen...
[23:11] <wililupy> will snap run work with daemons?
[23:11] <zyga> wililupy: yes, it runs with anything
[23:11] <zyga> wililupy: daemons run via snap run
[23:11] <zyga> wililupy: snap run --shell is special
[23:12] <zyga> wililupy: it sets up confinement the same way but runs shell instead
[23:14] <wililupy> snap run --shell fboss returns error: cannot find app "fboss" in "fboss"
[23:14] <zyga> you need to run snap.app
[23:14] <zyga> wililupy: try snap run --shell fboss.fboss
[23:14] <zyga> or whatever the application name is
[23:17] <mup> PR snapd#2660 opened: cmd: fix typo (thanks to jdstrand!) <Created by zyga> <https://github.com/snapcore/snapd/pull/2660>
[23:17] <wililupy> hmm. In my snapcraft.yaml I call the app wedge_agent but when I try to run snap run --shell fboss.wedge_agent it says error: cannot find app "wedge_agent" in "fboss"
[23:18] <zyga> the app cannot be called wedge_agent
[23:18] <zyga> can you show me the apps section please
[23:18] <zyga> jdstrand: thanks for spottng the typo
[23:19] <wililupy> zyga: http://pastebin.ubuntu.com/23824832/
[23:19] <zyga> jdstrand: and sorry for messing up any changes in flight
[23:19] <zyga> wililupy: the app name is wedge-agent
[23:19] <zyga> wililupy: try snap run --shell fboss.wedge-agent
[23:20] <wililupy> zyga: damnt typos... thanks.
[23:20] <wililupy> ubuntu@wedge100:/snap$ sudo snap run --shell fboss.wedge-agent
[23:20] <wililupy> support process for mount namespace capture exited abnormally
[23:21] <zyga> check "journalctl -f" please
[23:21] <zyga> wililupy: which version of snap are you on?
[23:21] <zyga> snap --version
[23:21] <wililupy> 2.20
[23:22] <zyga> is this core or classi
[23:22] <zyga> *classic
[23:22] <wililupy> classic
[23:23] <wililupy> zyga: http://pastebin.ubuntu.com/23824848/    journalctl dump.
[23:23] <wililupy> so I think that answers my question. The software was built to look in those hard directories for the libraries...
[23:24] <zyga> Jan 18 23:21:25 wedge100 audit[28539]: AVC apparmor="ALLOWED" operation="getattr" info="Failed name lookup - disconnected path" error=-13 profile="snap.fboss.wedge-agent//null-/bin/journalctl" name="dev/pts/1" pid=28539 comm="journalctl" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[23:26] <wililupy> zyga: so why is that getting denied?
[23:29] <wililupy> zyga: That path doesn't exist on here.
[23:33] <jjohansen> zyga: sorry, I am not sure yet. I will make sure to fill in the bug
[23:37] <zyga> jjohansen: thanks
[23:37] <zyga> wililupy: did you run journalctl from the spawned shell?
[23:37] <wililupy> yes
[23:37] <zyga> wililupy: can you run it from the regular environment instead (then reproduce the problem and see the new messages)
[23:38] <wililupy> Sure.
[23:39] <zyga> wililupy: thanks, I need to sleep now, please leave me a message
[23:39] <wililupy> zyga: will do. thanks!