| === chihchun_afk is now known as chihchun | ||
| Tcab | Can i package a wxpython based app as a snap? | 06:13 |
|---|---|---|
| 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> | 06:27 |
| mup | PR snapd#2397 closed: interfaces: add iio <Created by lpotter> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2397> | 07:12 |
| mup | PR snapd#2529 closed: interfaces: mm: permissions for protocol proxies <Created by alfonsosanchezbeato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2529> | 07:15 |
| zyga | tyhicks: woot, I just read the thead about complain mode for seccomp | 08:03 |
| zyga | nice :) | 08:03 |
| === chihchun is now known as chihchun_afk | ||
| Tcab | Can i package a wxpython based app using snap? | 08:08 |
| zyga | Tcab: hey | 08:16 |
| zyga | Tcab: it should be doable, just enough massaging to fit all of the bits in /snap | 08:16 |
| eduardas_m | hello, is this an appropriate place to write feedback on Ubuntu Core tutorials that are on ubuntu.com? | 08:18 |
| zyga | eduardas_m: I would also recommend https://rocket.ubuntu.com/channel/snapcraft or the snapcraft mailing list | 08:27 |
| 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:29 |
| 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:32 |
| === chihchun_afk is now known as chihchun | ||
| Tcab | Ok thanks | 08:37 |
| Tcab | Would be great if there was a simple examp,e / template for a wxpython app. It could thenbe used by many others | 08:39 |
| Tcab | Wxpthon probably means compiling wxpython ? As part of the build process? | 08:40 |
| 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> | 08:47 |
| mup | PR snapd#2650 opened: also include system-shutdown helper in snapd.install <Created by chipaca> <https://github.com/snapcore/snapd/pull/2650> | 09:09 |
| 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> | 09:51 |
| Person1 | Join | 10:27 |
| mup | PR snapd#2651 opened: interfaces,overlord/ifacestate: small refactor around reference methods <Created by zyga> <https://github.com/snapcore/snapd/pull/2651> | 10:38 |
| tito_ | Hi all | 11:26 |
| tito_ | pedronis: thanks for the yesterday's link to the integration tests | 11:26 |
| tito_ | man. that was a trip... | 11:27 |
| tito_ | I used systemctl edit snapd.service to inject http_proxy for snapd daemon | 11:27 |
| 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:28 |
| tito_ | anyway, here is how /etc/systemd/system/snapd.service.d/override.conf should look like: | 11:29 |
| 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:30 |
| tito_ | without the [Service] section , does not work. | 11:31 |
| 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> | 11:35 |
| 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:11 |
| 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:14 |
| 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:16 |
| 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:21 |
| 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:24 |
| ogra_ | who owns that nowadays ? | 12:25 |
| ogra_ | davidcalle, ^^^ is that still your area ? | 12:25 |
| morphis | ogra_: I guess you can just do a PR against https://github.com/CanonicalLtd/ubuntu-core-docs or file a bug there | 12:27 |
| davidcalle | @ogra_ yes, PR is fine :) | 12:33 |
| nothal | davidcalle: No such command! | 12:33 |
| 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:34 |
| 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:51 |
| 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:52 |
| morphis | eduardas_m: should be ok | 12:53 |
| morphis | eduardas_m: worth running $ snap refresh inside to get the latest updates | 12:54 |
| eduardas_m | the thing is I am trying to follow the snapcraft tutorials word by word... and I found something that works differently | 12:55 |
| 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 |
| === ben_r_ is now known as ben_r | ||
| eduardas_m | bash installs on first go without adding configflags: ["--infodir=/var/bash/info"] | 12:56 |
| eduardas_m | so I thought either the tutorials are outdated or the image is | 12:57 |
| 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 | 12:58 |
| 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:00 |
| 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:02 |
| 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:03 |
| 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:05 |
| eduardas_m | are there pre-build snaps that enable X server + desktop on Ubuntu Core or somehing similar? | 13:06 |
| stokachu | longsleep, yea its from your hosts sources.list | 13:11 |
| longsleep | stokachu: ok great thanks! | 13:11 |
| 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:12 |
| 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:14 |
| 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> | 13:48 |
| 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:05 |
| 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:09 |
| mup | Bug #1649934 changed: USB Auto-mount for assertion import fails <Snappy:Invalid by awe> <https://launchpad.net/bugs/1649934> | 14:11 |
| tyhicks | zyga: I should be done with version 2 of the seccomp patches this week so everything is still looking good | 14:20 |
| 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:25 |
| zyga | tyhicks: and trusty I assume | 14:26 |
| tyhicks | zyga: ah, right... libseccomp changes will go back to trusty | 14:26 |
| 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:36 |
| 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:38 |
| mhall119 | jdstrand: is the new 'dbus' interface in snapd 2.20? | 14:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| mhall119 | jdstrand: which store channel? | 14:51 |
| jdstrand | edge r5 | 14:51 |
| * diddledan pricks his ears up | 14:51 | |
| 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:52 |
| 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 backgoround>? </guess. | 14:53 |
| jdstrand | > | 14:53 |
| mhall119 | is there a way to list dbus session services? | 14:53 |
| jdstrand | install d-feet | 14:54 |
| jdstrand | there are other commands, but I don't know the invocation otoh | 14:54 |
| jdstrand | regardless, if you install r5 from the store then do 'snap interfaces' you should see an interface called ktuberling:session-dbus-interface | 14:55 |
| 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:57 |
| 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 | 14:58 |
| 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:00 |
| 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:01 |
| jdstrand | cool | 15:02 |
| AlbertA | zyga: ping | 15:04 |
| 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:08 |
| 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:16 |
| === JanC_ is now known as JanC | ||
| 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:17 |
| 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:18 |
| === souther_ is now known as souther | ||
| 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:19 |
| 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:20 |
| mup | PR snapd#2655 opened: cmd: switch to non-recursive make <Created by zyga> <https://github.com/snapcore/snapd/pull/2655> | 15:23 |
| 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:25 |
| 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:31 |
| ogra_ | http://paste.ubuntu.com/23822572/ is the unity8 log | 15:33 |
| ogra_ | looks like it misses the gallium driver | 15:34 |
| ogra_ | sadly i need to re-flash the SD so i cant test further ... | 15:35 |
| 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:46 |
| === cmiller_ is now known as qengho | ||
| ogra_ | mterry, i guess it does ... but i think we are missing a mesa driver that kgunn provides in his mir-kiosk snap | 15:49 |
| ogra_ | i cant imagine mesa-kms or mesa-x11 to work on a pi | 15:50 |
| 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:51 |
| 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 | 15:55 |
| === chihchun is now known as chihchun_afk | ||
| === sjn__ is now known as sjn | ||
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| === stgraber_ is now known as stgraber | ||
| mup | PR snapd#2656 opened: spread: refresh apt cache before first install <Created by zyga> <https://github.com/snapcore/snapd/pull/2656> | 16:49 |
| mup | PR snapd#2657 opened: snapmgr, ifacemr: add automatic ubuntu-core -> core transition <Created by mvo5> <https://github.com/snapcore/snapd/pull/2657> | 16:50 |
| === gbisson_ is now known as gbisson | ||
| roadmr | hello folks. I want to build a classic-confinement snap. How do I set the "core_dynamic_linker"? | 17:14 |
| 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:18 |
| roadmr | kyrofa: yes, I just found it by grepping around on snapcraft's source :) installing core now... yay | 17:19 |
| 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:22 |
| roadmr | kyrofa: can't install core while ubuntu-core is installed, but can't remove ubuntu-core :( | 17:24 |
| 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:25 |
| 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:26 |
| roadmr | kyrofa: /o\ not ideal :) but it'll do. Purging! | 17:27 |
| roadmr | kyrofa: my shiny classic snap is ready :) thanks! | 17:32 |
| kyrofa | roadmr, any time, sorry for the inconvenience! | 17:37 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:52 |
| ogra_ | if adding locales adds 3.5MB thats about it ... it wont grow in any way | 17:53 |
| 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:54 |
| ogra_ | ogra@localhost:~$ sudo du -hcs /snap/core/922 | 17:57 |
| ogra_ | 186M/snap/core/922 | 17:57 |
| ogra_ | 186Mtotal | 17:57 |
| ogra_ | ogra@localhost:~$ df -h | grep core/922 | 17:57 |
| ogra_ | that might give you an impression ;) | 17:57 |
| ogra_ | err | 17:57 |
| 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:58 |
| 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 | 17:59 |
| 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:00 |
| kalikiana | ogra_: Impressive indeed. Thanks for enlightening me | 18:01 |
| 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:02 |
| jdstrand | popey: no, XDG_RUNTIME_DIR is correctly set. just do 'mkdir $XDG_RUNTIME_DIR' | 18:03 |
| popey | jdstrand: thanks | 18:03 |
| 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:04 |
| 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:09 |
| kyleN | a long time AGO (I meant) | 18:10 |
| kyleN | none of my local snap keys (snapcraft list-keys) have the same fingerprint as the Account_id listed in the store. | 18:13 |
| Chipaca | pedronis, is the relation between account id and keys documented anywhere? | 18:16 |
| mup | Bug #1657552 opened: [spread] install-sideload:reexec0 failure <Snappy:New> <https://launchpad.net/bugs/1657552> | 18:28 |
| pedronis | kyleN: are you logged in as that SSO account ? | 18:34 |
| 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:42 |
| 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:43 |
| 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:46 |
| kyleN | pedronis, ok. I'll keep looking around. thanks | 18:47 |
| 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:49 |
| pedronis | kyleN: this might print relevant info: python3 -c "import snapcraft.storeapi; print(snapcraft.storeapi.StoreClient().get_account_information().get('account_keys'))" | 18:56 |
| 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:00 |
| stgraber | sergiusens: I believe I commented in it | 19:01 |
| sergiusens | ah, sorry, you have | 19:01 |
| sergiusens | I didn't refresh! | 19:01 |
| 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:04 |
| sergiusens | jdstrand, is there a way to manually connect? | 19:14 |
| 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:27 |
| jdstrand | sergiusens: is snap connect not working for you? | 19:35 |
| 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:36 |
| kyrofa | jdstrand, ah excellent, I misunderstood then | 19:41 |
| 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 | 19:52 |
| 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:05 |
| mup | PR snapd#2658 opened: cmd: add mount / unmount helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2658> | 20:15 |
| 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:17 |
| 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:18 |
| 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:19 |
| zyga | jdstrand: ack | 20:20 |
| zyga | pedronis: checking | 20:20 |
| zyga | hmm | 20:21 |
| zyga | we have real tests for auto-connection, I wonder if they are not that real or is there something else at play | 20:22 |
| * zyga needs a break | 20:23 | |
| zyga | ttyl | 20:23 |
| jdstrand | pedronis: it is weird indeed | 20:30 |
| mup | PR snapcraft#1056 opened: schema: print allowed length for length failures <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1056> | 20:49 |
| === wxl_ is now known as wxl | ||
| 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:25 |
| stokachu | if i run the commands that are generated in the systemd file they work | 21:27 |
| 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:28 |
| kyrofa | stokachu, yeah, snapd does the systemd bits, not snapcraft | 21:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| stokachu | kyrofa, gotcha, thanks | 21:35 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:51 |
| 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 | 21:56 |
| sergiusens | stokachu, I'll get to you as soon as those are migrated. | 22:04 |
| 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:07 |
| 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:32 |
| diddledan | heads'-up I've just released corebird 1.4.1 (corebird-diddledan) :-) | 22:50 |
| 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:51 |
| zyga | wililupy: dmesg | grep DENIED | 22:57 |
| wililupy | zyga: doesn't return anything | 23:03 |
| zyga | wililupy: okay, good | 23:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| wililupy | zyga: I'll try the snap run command to see what happen... | 23:10 |
| 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:11 |
| zyga | wililupy: it sets up confinement the same way but runs shell instead | 23:12 |
| 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:14 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| zyga | is this core or classi | 23:22 |
| zyga | *classic | 23:22 |
| wililupy | classic | 23:22 |
| 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:23 |
| 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:24 |
| wililupy | zyga: so why is that getting denied? | 23:26 |
| wililupy | zyga: That path doesn't exist on here. | 23:29 |
| jjohansen | zyga: sorry, I am not sure yet. I will make sure to fill in the bug | 23:33 |
| 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:37 |
| wililupy | Sure. | 23:38 |
| zyga | wililupy: thanks, I need to sleep now, please leave me a message | 23:39 |
| wililupy | zyga: will do. thanks! | 23:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!